[00:00:00] - {Tageswechsel: Sonntag, 9. Juni 2024}
[21:00:35] <dilfridge> !proj council
[21:00:36] <willikins> (council@gentoo.org) ajak, dilfridge, mattst88, mgorny, sam, soap, ulm
[21:00:40] <dilfridge> meeting now! :)
[21:00:56] -*- ajak here
[21:00:57] <dilfridge> let's start with the roll call 
[21:00:59] -*- dilfridge here
[21:01:04] -*- sam_ here
[21:01:14] -*- mgorny here
[21:01:18] -*- ulm here
[21:01:18] -*- soap here
[21:01:49] -*- ajak guesses sandwich wasn't made in <4 minutes
[21:01:56] <dilfridge> let's hope it's a good sandwich
[21:01:59] -*- mattst88 here
[21:02:05] <ajak> :)
[21:02:05] <dilfridge> excellent
[21:02:14] <dilfridge> 2. 
[21:02:26] <dilfridge> Proposed item: Enable GitHub sponsorship using SPI Fiscal Host
[21:02:32] <dilfridge> https://marc.info/?l=gentoo-project&m=171676255409548&w=2
[21:02:46] <dilfridge> robbat2: want to say something?
[21:03:27] <ulm> can we do this ourselves, or do we have to ask SPI to enable it for us?
[21:03:40] <mattst88> AFAIU this is just enabling github sponsors for Gentoo, which will direct money to SPI for us, right?
[21:03:53] <ajak> i think it's fine; even if robin did it unilaterally i wouldn't have whined
[21:03:59] <dilfridge> so I tried to read up on this, and it seems to be connected to github accounts ... cause you usually sponsor a person
[21:04:05] <soap> yeah, I'm fine with it too
[21:04:15] <mattst88> yeah, makes sense to me
[21:04:18] <dilfridge> accordingly I'm not really sure how it's going to work for us, but I have no general objections
[21:04:18] <ajak> mattst88: that's my understanding yeah
[21:04:39] <dilfridge> yup, works for me
[21:05:05] <dilfridge> so we should probably vote about something
[21:05:13] <ulm> yes please :)
[21:05:19] -*- ulm yes
[21:05:26] <dilfridge> Proposed item: Enable GitHub sponsorship using SPI Fiscal Host
[21:05:28] -*- dilfridge yes
[21:05:30] -*- sam_ yes
[21:05:31] -*- ajak yes
[21:05:32] -*- ulm yes
[21:05:38] -*- soap yes
[21:05:38] -*- mattst88 yes
[21:05:46] <dilfridge> that makes 7 yes, unanimous
[21:05:50] <dilfridge> next
[21:05:52] <dilfridge> 3. 
[21:05:54] <dilfridge> arch status
[21:06:00] <arthurzam> wait, mgorny vote?
[21:06:12] -*- mgorny yes
[21:06:26] <dilfridge> ah 
[21:06:27] <dilfridge> ok
[21:06:29] <dilfridge> still 7 yes
[21:06:39] <dilfridge> shouldnt count ulm double :P
[21:06:46] <dilfridge> https://gentoo.akhuettel.de/bugs/arches.php
[21:06:49] <arthurzam> So about arch status, I want to talk about ia64 & hppa
[21:06:51] <dilfridge> sorry for the white margin
[21:07:13] <arthurzam> ia64 is close to death (kernel and glibc dropped)
[21:07:42] <arthurzam> hppa is in sad state because issues with devbox, and once again, do we really want stable hppa at all?
[21:08:24] <sam_> my position on it is the same as usual really, i still believe stable for some arches is useful because otherwise you can't really keep them up to date at all, and we'd end up with problems with no devbox anyway if we can't rekeyword things (albeit less, yes)
[21:08:46] <ulm> dilfridge: didn't you have plots for number of keywords too?
[21:08:52] <mattst88> I mentioned this yesterday in another channel, but I think we should drop the 32-bit userland sparc profiles
[21:08:55] <dilfridge> ulm: still broken
[21:09:01] <ulm> I see
[21:09:07] <arthurzam> I agree with mattst88 
[21:09:17] <sam_> yeah 32-bit ul sparc should go as the kernel support is going and afaik the hw (matt explained this to me ages ago) basically doesn't exist in terms of anything anyone would use 
[21:09:23] <sam_> it's always people running 32-bit-on-64-bit hw
[21:09:31] <arthurzam> SHould we also drop s390, not x variant?
[21:09:39] <sam_> dilfridge has been working towards that 
[21:09:50] <sam_> i'll let him explain
[21:10:07] <dilfridge> well, we can do that at any time, but right now also keeping s390 (without x) doesnt cost us anything
[21:10:11] <dilfridge> (in a chroot)
[21:10:23] <sam_> ah I forgot we could do that :)
[21:10:46] <sam_> I actually do think we should remove it because IBM didn't seem to even realise anyone supported it 
[21:10:50] <sam_> but I agree it costs very little too
[21:11:28] <dilfridge> we should definitely drop s390 boot media because they are pointless
[21:11:45] <dilfridge> (kernel is s390x only for ages already)
[21:11:48] <sam_> i suppose killing s390 will speed up CI a tiny bit or something 
[21:11:56] <sam_> plus it's also rustless, unlike s390x
[21:12:14] <arthurzam> It would make the profiles mess with keywords simpler
[21:12:26] <dilfridge> there#s of course also ppc32 and the elephant in the room, x86 
[21:12:30] <mgorny> btw do we expect rust to come to more arches soon?
[21:12:45] <arthurzam> mgorny: not long ago I've added mips
[21:12:58] <mgorny> ...which mips? xD
[21:13:09] <sam_> rustc_codegen_gcc (rustc + libgccjit) got more integrated into the Rust repo recently so I think there is progress there
[21:13:16] <dilfridge> BE or LE? and which ABI?
[21:13:17] <sam_> gccrust is slower moving because it's a full frontend reimplementation
[21:13:31] <soap> I love how "mips" is the most overloaded keyword in gentoo
[21:13:32] <mattst88> yeah, I think just dropping stuff that provides no value is the right thing to do, even if it doesn't appear to cost much
[21:13:45] <sam_> matoro also worked on making building rustc via cross work so it's easier to do dist tarballs now (bootstrap tarballs we do for sparc&mips)
[21:13:54] <arthurzam> mgorny: dilfridge: I don't know, see here: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/rust-bin/rust-bin-1.78.0.ebuild#n20
[21:13:56] <sam_> so I think the rust coverage is going to get better
[21:13:59] <dilfridge> building stages is fairly easy, keeping up with boot media is harder
[21:14:09] <sam_> soap: yes
[21:14:18] <sam_> soap: this is part of why killing s390 is good (as arthur pointed out), i'd forgot about this
[21:14:21] <dilfridge> arthurzam: that is fairly good coverage
[21:14:24] <sam_> soap: if we added s390 (no x) today, we wouldn't overload the kw
[21:14:40] <dilfridge> hrhr... how about riscv32`?
[21:14:49] <sam_> that one should probably really be split too
[21:15:00] <sam_> ultimately bitness is such a huge characteristic
[21:15:02] <dilfridge> no objection but someone needs to do the work
[21:15:14] <dilfridge> (and yes I suggested that at the start)
[21:15:31] <arthurzam> sam_: so what about ia64 & hppa?
[21:15:31] <arthurzam> (before we jump to ppc & x86)
[21:15:38] <dilfridge> ok
[21:15:40] <dilfridge> so 
[21:15:42] <dilfridge> chair statement
[21:15:53] <dilfridge> we can't really decide anything without discussion on the lists
[21:15:54] <dilfridge> but
[21:15:57] <sam_> hppa is what I said above, I'd like to leave it alone for now and maybe setup my home machine doing AT until we can get the devbox repaired (we got given bad ram by a supplier)
[21:16:05] <dilfridge> we can come up with things to propose there and decide next time
[21:16:05] <sam_> i have personal affection for it though
[21:16:14] <mgorny> is there anything to actually decide council-wise?
[21:16:21] <mgorny> i think dropping some old profiles is within arch team scope
[21:16:36] <dilfridge> !proj ia64
[21:16:36] <willikins> dilfridge: (ia64@gentoo.org) ago, hattya, vapier
[21:16:39] <sam_> LOL
[21:16:50] <arthurzam> lol
[21:16:52] <dilfridge> !proj hppa
[21:16:52] <willikins> dilfridge: (hppa@gentoo.org) arthurzam, jsmolic, sam, vapier
[21:16:54] <ajak> ... that might be that
[21:17:13] <mgorny> ah, sorry, ia64, right
[21:17:33] <arthurzam> council: Yeah here is the decision, so what about making x86 and ppc ~arch only? I don't see a good future for them as stable arch
[21:17:39] <sam_> hppa is kind of my guilty pleasure and my favourite alt-arch even if it's not rational so unless it's hugely problematic i'd like it to not go
[21:17:42] <sam_> meh
[21:17:51] <sam_> this is again the question of what a stable arch is for
[21:18:00] <sam_> the x86 and ppc hw is usually crap and slow 
[21:18:04] <sam_> there *are* still x86 users out there
[21:18:11] <sam_> I know this because I broke Perl last month for them
[21:18:18] <ulm> what's the status of m68k?
[21:18:18] <sam_> more people noticed than I thought!
[21:18:28] <dilfridge> also glibc broke for them and barely anyone noticed
[21:18:45] <sam_> to be fair, that's explicitly the no-SSE2 ones which is less so, but yeah
[21:18:50] <mgorny> is woodpecker still x86?
[21:18:57] <mattst88> yes, woodpecker is still x86
[21:19:08] <sam_> re x86, a lot of problems are either fp related or time_t
[21:19:10] <arthurzam> But it runs on the new amd64 infra server
[21:19:20] <ajak> i think only because it was migrated from some old x86 host
[21:19:20] <sam_> the fp problems should be solved by mgorny's mfpmath=sse thing we implemented
[21:19:28] <sam_> time_t is a global 32-bit arch thing we need to fix
[21:19:33] <mgorny> did we finally get it into stages?
[21:19:44] <sam_> good question
[21:19:45] <dilfridge> yes, that also affects arm, mips, m68k, ...
[21:19:52] <dilfridge> not yet I think
[21:19:57] <sam_> ulm: m68k is ok but it needs a big transition (alignment change)
[21:21:06] <dilfridge> ok, so, imho, we should downgrade ppc(32) to ~arch, but keep x86 stable for now (more users)
[21:21:25] <dilfridge> ~arch only things are usually not so much of a problem
[21:21:25] <ulm> sam_: that was kernel? or glibc?
[21:21:32] <sam_> i'd still prefer the stable base for ppc32 be reduced instead but i know it's easy for me to say that and it requires work to determine what we do there 
[21:22:03] <dilfridge> well
[21:22:16] <dilfridge> on the whole things are working right now (except for guppy :P)
[21:22:21] <mattst88> what is the value of a stable base for ppc32?
[21:22:27] <sam_> i already said it above a few times
[21:22:47] <sam_> we also do have a fair influx of people into #gentoo-powerpc installing on 32-bit macs still
[21:23:12] <mattst88> sorry, I must have missed it
[21:23:25] <sam_> it's ok i just didn't want to repeat it again for no reason 
[21:23:28] <mattst88> the systems are slow, so keeping up with ~arch is hard?
[21:23:30] <sam_> the issue is like, what is a stable arch for
[21:23:42] <sam_> it's nice to be able to keep a machine up to date, and this hw is usually slow
[21:23:57] <sam_> and also, if something is chronically broken, it's easier for it to get bricked (but i appreciate this is a more niche point)
[21:24:01] <sam_> *critically
[21:24:03] <arthurzam> sam_: we have the binpkg host for the base stable
[21:24:12] <dilfridge> I can confirm that slow hardware + continuous rebuidls are a pain
[21:24:19] <mattst88> IMO stable is for saving users time by preventing them from running into bugs that we can prevent from reaching them by the stabilization process
[21:24:21] <sam_> like even gcc ends up killing these builders 
[21:24:58] <sam_> I have to avoid keywording gcc as much as I'd like to sometimes because I hear dilf in my ear about building gcc for a million mips ABIs because it's ~arch
[21:25:04] <mattst88> when it's just a for-fun architecture, I don't think this is a particularly compelling reason for stabilization
[21:25:07] <sam_> but I get your point too 
[21:25:11] <sam_> it's a good one
[21:25:25] <sam_> oh, there's one other thing but it's related to yours
[21:25:32] <dilfridge> sam_: is much better now, new machine
[21:25:41] <sam_> with stabilisation, we run tests regularly for packages and at least it's fairly easy to tell when they broke
[21:25:54] <sam_> when you stop doing that, it becomes really hard to know if they're broken because nobody is running them as a matter of course
[21:26:07] <sam_> that's not a reason to keep stable kws forever, it's just a point i've made in the past
[21:26:15] <mattst88> yeah
[21:26:27] <sam_> i find your point quite compelling and hard to reconcile with how i feel about it :(
[21:26:32] <mattst88> at the same time, I'm reminded of how long gdb was broken on sparc with no one noticing until I actually tried to use it
[21:26:41] <dilfridge> so we have a couple of things we can do 
[21:26:46] <dilfridge> 1) reduce stable set
[21:26:55] <dilfridge> 2) drop stable set entirely
[21:27:22] <dilfridge> 3) in some cases, remove specific profiles (32bit s390,sparc)
[21:27:41] <sam_> (the nuclear option for 1) if we're finding candidates hard is to just go back to roots like mattst88 did before for hppa (and other arches I think too?) and just re-stable stuff where it makes sense, too. that might even be worth it for ppc because it has loads of legacy kws. maybe even x86 as well)
[21:27:56] <sam_> there's stuff out there with ~amd64 ppc x86 (!!!!)
[21:28:09] <mattst88> yeah, that's a bad sign
[21:28:42] <soap> any package with ppc but not ppc64 is likely just being dragged along
[21:28:44] <ulm> sam_: these keywords must be at least 15 years old
[21:28:50] <mattst88> alright, I don't think we need to decide anything here. let's move on?
[21:29:04] <dilfridge> here's yet another thing, I would really love to have consistent deptrees everywhere (see mips)
[21:29:21] <dilfridge> consistent as enforced by ci
[21:29:32] <dilfridge> but yes
[21:29:56] <dilfridge> my suggestion would be, we can talk informally over the next weeks, and maybe push some ideas on the lists
[21:30:09] <dilfridge> for possible decisions in later meetings
[21:30:15] <dilfridge> anyway
[21:30:35] <dilfridge> 4. open bugs with council participation
[21:31:05] <dilfridge> bug 925014
[21:31:06] <willikins> dilfridge: https://bugs.gentoo.org/925014 "PR services lacking developer redundancy"; Community Relations, User Relations; CONF; ajak:pr
[21:31:08] <dilfridge> any news?
[21:31:44] <dilfridge> seems like not, further discussion would be redundant
[21:31:57] <dilfridge> bug 801499
[21:31:57] <willikins> dilfridge: https://bugs.gentoo.org/801499 "Approach Nitrokey for Nitrokey 3 upgrade"; Gentoo Foundation, Proposals; CONF; sam:trustees
[21:32:28] <dilfridge> ulm, soap, and me got nitrokeys 3 to test them out
[21:32:45] <ajak> i don't think i knew that people got them for testing before robin's comment but maybe you guys could comment on them?
[21:32:45] <soap> yeah and they're not great :/
[21:33:02] <ajak> how so?
[21:33:07] <dilfridge> I havent really touched it yet myself, it looks like the flimsiest usb stick ever
[21:33:24] <sam_> the previous generation (not these, no idea) were so unreliable 
[21:33:26] <ulm> the gnupg part is ok IMHO, but mechanical quality is as it was for Nitrokey 2
[21:33:30] <sam_> i really think we should just do yubikey 
[21:33:36] <sam_> they're reliable, actually work
[21:33:41] <soap> sam_: social contract blabla
[21:33:49] <sam_> this is such a weak argument
[21:33:51] <ulm> sam_: the previous generation was just an adapter for a ZeitControl card
[21:34:01] <soap> personally, I would vote to overrule the social contract
[21:34:03] <sam_> ah, so it's their own HW now?
[21:34:03] <ulm> that issue should be fixed
[21:34:16] <sam_> ajak and my's keys died after not very long
[21:34:19] <dilfridge> and it does the fancy curve
[21:34:38] <soap> there's no GUI app for FIDO2/admin yet, it's all a bunch of python scriptlets
[21:34:46] <ajak> yeah mine's dead after a little while of not using it after switching to my yubi full time
[21:34:56] <soap> the TOTP app isnt available yet
[21:34:57] <arthurzam> My nitrokey 2 also dies like a month ago. I was copying from printed base64 page the backup for some hours
[21:35:03] <sam_> i'm skeptical but i am open to trying them again, though soap is who I'd defer to on this 
[21:35:06] <sam_> arthurzam: :(
[21:35:11] <ulm> I think yubikey is out of the question because it's proprietary
[21:35:15] <soap> the USB-C connector is just padded out for the USB-A connector
[21:35:16] <sam_> i don't believe that, sorry
[21:35:19] <sam_> it's just nonsense
[21:35:22] <sam_> are we doing that for infra servers?
[21:35:27] <sam_> it doesn't scale at all
[21:35:45] <sam_> do all infra servers need to run coreboot?
[21:35:57] <sam_> i believe in the social contract, i don't believe it even applies here if the "social contract"-compatible option is terrible
[21:36:06] <ajak> or our sponsors? :p
[21:36:18] <sam_> we should try to comply with it even when we don't have to, but in this case, i think it's genuinely to our detriment
[21:36:29] <sam_> ajak: right
[21:36:49] <ajak> i don't think it's sustainable to prefer the obviously worse hardware especially when it's (supposed to be) such a vital part of our security posture
[21:37:09] <ajak> the sheer incidence of hardware failures even among this small group is horrific
[21:37:16] <sam_> (also, aren't yubikeys FSF RYF compliant anyway because you can't flash the firmware? :D)
[21:37:32] <soap> hahahah
[21:37:33] <ulm> ajak: hardware failure? that was for Nitrokey 2
[21:37:37] <soap> thats actually a good point
[21:37:57] <sam_> I just don't know what nitrokey have done to deserve our business again after such a terrible experience
[21:38:01] <sam_> keep in mind the order form kept breaking, too
[21:38:19] <dilfridge> the ordering experience was somewhat painful, yess
[21:38:23] <ajak> yeah i'm not sure we have any obligation to trust that the nitrokey 3 is better
[21:38:25] <sam_> I am open to trying them one more time but I want this discussion to be remembered when we revisit it on the next cycle if so
[21:38:36] <sam_> (that it was a "last chance")
[21:39:00] <sam_> dilfridge: I actually don't think I ever even got my nitrokey from them
[21:39:04] <ajak> any reason we couldn't do both? offer nitrokeys and yubikeys?
[21:39:06] <sam_> dilfridge: a developer donated some spare ones to me lol
[21:39:08] <dilfridge> yubikey 5 now also does ED25519
[21:39:17] <ajak> that's important too, yeah
[21:39:18] <ulm> if you want I'll crack my sample open and post some photos :)
[21:39:33] <dilfridge> un-cracked is sufficient
[21:39:57] <ulm> comparison Nitrokey 2 vs 3 I mean
[21:40:21] <sam_> I also do wish that we'd discussed this *before* approaching nitrokey again
[21:40:29] <sam_> I was taken by surprise when robbat2 contacted them
[21:40:32] <ajak> i don't think the comparison between the two is particularly useful
[21:40:38] <ajak> yeah me too
[21:40:50] <dilfridge> well, yes, that was a tad surprising
[21:40:51] <ulm> no harm done I think? we don't have any obligation
[21:41:05] <sam_> well, it's just a bit unprofessional if we were going to then vote against it or something
[21:41:11] <sam_> it would've been worth speaking about it
[21:41:28] <dilfridge> well, if you can't say no, there is no point in getting samples
[21:41:34] <sam_> yeah good point
[21:41:43] <ulm> dilfridge: +1
[21:41:49] <arthurzam> You also wrote about it bad stuff in the bug
[21:41:54] <arthurzam> So not a surprise
[21:42:02] <sam_> honestly it was so long ago that I forgot what I wrote ;)
[21:42:06] <ulm> USB-C form factor is simewhat unfortunate
[21:42:14] <ulm> *somewhat
[21:42:17] <soap> because USB-C was an afterthought
[21:42:37] <ulm> yeah, looks like
[21:43:04] <dilfridge> in the time they took to develop it, whole usb generations passed by
[21:43:15] <sam_> anyway I won't stand in the way, to be clear
[21:43:16] <ajak> i'm not sure we have any consensus here, do we?
[21:43:19] <sam_> not sure if we should vote on it or what
[21:43:36] <dilfridge> well, who else
[21:43:47] <ulm> we could do an informal vote at least
[21:44:00] <dilfridge> ok
[21:44:04] <ulm> to get a picture of opinions
[21:44:27] <arthurzam> I think it is a 3 way vote (only A, only B, both)
[21:44:28] <sam_> also to be clear, am grateful to robbat2 for doing the work, I just meant I felt mixed about it because of my poor experiences with them and wanted to lobby for adopting yubikey, but if there's no obligation (as proven by e.g. samples), it's fine to me
[21:44:41] <dilfridge> motion: approach nitrokey for a renewal of keys for developers with nitrokey 3: yes, no, abstain
[21:44:51] <ulm> I'd vote against Yubikey
[21:44:59] -*- soap no
[21:45:03] -*- sam_ no
[21:45:06] -*- dilfridge abstain
[21:45:09] -*- ulm abstain
[21:45:22] -*- mgorny abstain
[21:45:28] -*- ajak no (but wouldn't mind seeing both foundation-provided yubis + nitrokeys)
[21:45:41] <sam_> ulm: you didn't respond to my arguments above though regarding yubikey? I just don't see how it violates the social contract? And supposing it did, if they're unreliable, how is that okay?
[21:45:57] <sam_> ulm: there's no real third game in town for these
[21:45:59] <ajak> maybe that can be a research project for next meeting (/council)
[21:46:01] <dilfridge> mattst88: ^
[21:46:13] <ulm> sam_: IMHO the choice between open and closed hardware is clear
[21:46:15] <sam_> there's the google tokens but they're limited
[21:46:31] <ajak> must be a very good sandwich :D
[21:46:31] <soap> ulm: that still hasnt engaged with sam's argument
[21:47:10] <dilfridge> ok that's 3 no, 3 abstain, 1 missing
[21:47:16] <ulm> soap: that one cannot flash the firmware?
[21:47:17] <sam_> I'm all for open hardware and software, but the hardware doesn't work, and I don't see how it even violates the social contract
[21:47:21] <soap> si
[21:47:25] <dilfridge> we should probably attach another motion
[21:47:25] <sam_> as I said, it's arguably even RYF compliant
[21:47:43] <dilfridge> motion: approach yubikey and try to establish a similar deal, yes no abstain
[21:47:47] <sam_> but hell, what does the freedom matter for a yubikey or nitrokey given you can't flash either?
[21:47:48] -*- sam_ yes
[21:47:51] -*- ulm no
[21:47:51] -*- ajak yes
[21:47:53] -*- soap yes
[21:48:01] -*- dilfridge abstain
[21:48:08] -*- mgorny yes
[21:48:21] <dilfridge> mattst88: ?
[21:48:48] -*- ajak doesn't think a "similar deal" should be a prereq to establish a similar gentoo<->developer deal though
[21:49:16] <dilfridge> anyway, that's 4 yes, 1 no, 1 abstain, 1 missing, motion in all its vagueness carried
[21:49:27] <ajak> ie they might just say "just buy like everyone else" and that should be fine, foundation or whatever can still buy and send to devs
[21:49:44] <sam_> yeah, fair point
[21:49:45] <dilfridge> sure
[21:49:51] <dilfridge> but everyone likes sponsors :P
[21:49:54] <sam_> :)
[21:49:57] <sam_> tbh I think we should do more there
[21:50:01] <sam_> you don't ask, you don't get...
[21:50:12] <dilfridge> ok
[21:50:19] <dilfridge> let's leave it with that for the moment
[21:50:25] <sam_> i know this was a long 'un but i feel like this was overall quite useful
[21:50:29] <dilfridge> 5.
[21:50:32] <dilfridge> open floor
[21:50:35] -*- mattst88 yes
[21:50:40] <mattst88> (sorry)
[21:50:42] <sam_> just to say I've got my new laptop and will be doing my summaries shortly
[21:50:43] <dilfridge> (for what?)
[21:51:03] <mattst88> yes for approaching yubikey
[21:51:07] <dilfridge> oh yeah right summaries
[21:51:15] -*- dilfridge summons a summary
[21:51:22] <arthurzam> Can I request council members reply to election nominations?
[21:51:54] <dilfridge> I'm sorry, but as an AI language model I cannot ... wait
[21:52:01] <arthurzam> And I would like to also thank all council members for the good year of counseling - this council did a lot
[21:52:45] <dilfridge> thanks arthur
[21:53:03] <dilfridge> time to get into the mood for next year :D
[21:53:20] <ulm> I'm a little disappointed about progress of the transition to SPI
[21:53:33] <ulm> maybe the next council should take the initiative there
[21:54:02] -*- mattst88 recalls the first meeting of this council where he suggested we take the initiative
[21:54:03] <dilfridge> ulm: without intending to overestimate my influence there, once we got as far as we are now, I was very glad to have a bit of time for other stuff again
[21:54:04] <ajak> we made more progress this year than in previous years :)
[21:54:07] <ulm> e.g. transfer of copyrights and trademarks is still pending
[21:54:17] <dilfridge> ulm: so, I did not mind that it slowed down
[21:54:40] <ulm> dilfridge: yeah, but keeping some momentum would be good :)
[21:54:59] <dilfridge> time to go back into first gear, push the pedal to the metal and see the gravel fly
[21:56:05] <dilfridge> right
[21:56:09] <dilfridge> anything else?
[21:56:57] <dilfridge> apparently not. then <bang> meeting closed. we meet again for the sentencing... oh wait, different story...
[21:57:09] <ajak> thanks for chairing!
[21:57:27] <sam_> thanks!
[21:57:33] <dilfridge> thanks all
[21:57:35] <mgorny> thanks and gn