Add 2021/12 meeting log

Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>

2 files changed, 321 insertions, 0 deletions

diff --git a/meeting-logs/20211212.txt b/meeting-logs/20211212.txt
new file mode 100644
index 0000000..3b0aff0
--- /dev/null
+++ b/meeting-logs/20211212.txt
@@ -0,0 +1,302 @@
+[20:00:26] <dilfridge> !proj council
+[20:00:28] <willikins> (council@gentoo.org) dilfridge, gyakovlev, marecki, mattst88, mgorny, sam, ulm
+[20:00:31] <dilfridge> meeting time! 
+[20:00:46] <sam_> wee!
+[20:00:52] -*- dilfridge waves around for agenda item 1, roll call
+[20:01:11] -*- mgorny here
+[20:01:18] -*- ulm here
+[20:01:22] <dilfridge> https://archives.gentoo.org/gentoo-project/message/c40ae223363f5f92e98fa997fe642a92 <-- agenda link
+[20:01:37] -*- dilfridge here, obviously
+[20:01:47] -*- sam_ here
+[20:01:51] -*- gyakovlev here
+[20:02:54] <dilfridge> ok let's wait a moment, reaction time is a bit longer in switzerland :P
+[20:02:56] <gyakovlev> is my internet down?
+[20:03:03] <dilfridge> no
+[20:03:20] <Marecki> Wait, it's not already?
+[20:03:21] -*- Marecki here
+[20:03:31] <sam_> soap: ^^
+[20:04:09] <-- josef64 (~quassel@user/josef64) hat das Netzwerk verlassen
+[20:04:29] <dilfridge> ok anyway
+[20:04:42] <dilfridge> 2) Disabling APNG patches to libpng by default [1,2]
+[20:04:48] <dilfridge> > > [1] https://bugs.gentoo.org/824018
+[20:04:48] <dilfridge> > > [2] https://archives.gentoo.org/gentoo-project/message/0dd4a4a92a99c1aba7101b9b38437552
+[20:05:06] <dilfridge> mgorny: do you want to explain a little bit please?
+[20:05:10] <soap> here
+[20:05:13] -*- soap here
+[20:05:16] <dilfridge> \o/
+[20:05:26] --> josef64 (~quassel@user/josef64) hat #gentoo-council betreten
+[20:05:37] <mgorny> ok, so we're applying a set of non-standard patches to media-libs/libpng via USE=apng that's on by default
+[20:05:50] <mgorny> these patches are required to build mozilla progs against system-libpng
+[20:06:06] <mgorny> however, they are known to break webkit and according to our research "fixing" webkit would be really hard
+[20:06:31] <mgorny> all mozilla packages support building against bundled patched libpng but our mozilla team doesn't want to add the flag for that
+[20:06:42] <mgorny> (for some reason, they don't mind using half a dozen other bundled libraries)
+[20:07:20] <mgorny> Whissi claims that disabling APNG in libpng causes it to lose RGBA8888 color space and possible some other features
+[20:07:25] <gyakovlev> well I personally did some tests on that just to be sure and can't say USE=-apng removes alpha channel support
+[20:07:46] <mgorny> i've asked a lot of people to test this, i've checked specs, code and can't find anything to support that claim
+[20:08:17] <mgorny> plus, apps that don't explicitly use the additional API provided by APNG patches shouldn't change behavior in any way
+[20:08:22] <ulm> I stil don't understand how the patch can break things. apng support is via new chunk types, right?
+[20:08:26] <ulm> *still
+[20:08:34] <gyakovlev> just to be clear - it's about disabling USE=apng by default in IUSE/profiles right?
+[20:08:38] <sam_> the issue is that it's not standardised that libpng will try decode apng for you
+[20:08:43] <Marecki> Me neither, that said I couldn't exactly reproduce Whissi's scenario because he used proprietary software I don't have as source of PNGs.
+[20:08:45] <sam_> hence you get double-decoding in e.g. webkit.
+[20:08:49] <mgorny> e.g. if you open APNG file in a program that doesn't support APNG and then save it, you lose extra frames either way
+[20:09:32] <dilfridge> ok
+[20:09:35] <mgorny> sec, i'm looking for the PR
+[20:09:35] <sam_> for me, one of the key points here is: is this ever going to get resolved upstream? the answer is pretty clearly no for the foreseeable future. it's been rejected and nobody at Mozilla (or seemingly anywhere else) is reviving it.
+[20:09:48] <mgorny> roughly this: https://github.com/gentoo/gentoo/pull/23005
+[20:10:05] <mgorny> i.e. it's about adding system-png to Mozilla packages, and changing the default to USE=-apng
+[20:10:19] <mgorny> FIN
+[20:10:39] <dilfridge> sounds like a reasonable thing to do
+[20:11:03] <dilfridge> somewhere in my guts I hate it that chromium does the decent and mozilla the ugly thing, but that's not under discussion ehre
+[20:11:05] <mgorny> to the best of my knowledge, the last attempt to upstream APNG patches again got no reply from libpng upstream
+[20:11:09] <mgorny> a few years ago
+[20:11:40] <dilfridge> then again, unfortunately mozilla does everything possible to make itself obsolete
+[20:11:43] <mgorny> APNG is still a "de facto" standard maintained by mozilla
+[20:11:58] <Marecki> Personally, I do not like the fact any one large package forcing either USE=apng or USE=-apng. That said, we have got users to think of and if we've got one package requiring the former and several requiring the latter, the option's pretty clear...
+[20:12:03] <mgorny> part of the problem is that PNG Group is pushing for MNG instead
+[20:12:13] <dilfridge> Marecki: yup
+[20:12:18] <sam_> Marecki: aye
+[20:12:23] -*- soap == libmng maintainer
+[20:12:34] <gyakovlev> so basically users will have a choice of installing mozilla-product[system-png] alongside with webkit/chromium which will require libpng[-apng], is that right?
+[20:12:38] <ulm> mgorny: which is way cleaner
+[20:12:39] <dilfridge> and the point is, patches didnt get accepted upstream, and we pride ourselves to stick to upstream too
+[20:12:41] <Marecki> Especially given the fact APNG is, as already mentioned by the others, extremely unlikely to ever get upstreamed.
+[20:12:51] <ulm> keep formats for images and videos separate
+[20:13:19] <mgorny> gyakovlev: mozilla[system-png] will collide with webkit-based[system-png]
+[20:13:24] <Marecki> And Mozilla's "well FU we will keep using APNG for several more decades" approach is a bit childish.
+[20:13:29] <sam_> Marecki++
+[20:13:32] <mgorny> but the default will be USE=-system-png on mozilla to avoid that
+[20:13:33] <sam_> that's genuinely how I've viewed this
+[20:13:47] <sam_> feels like not much care has been given to the ecosystem or downstreams 
+[20:13:49] <dilfridge> for the record, I'd like to state as chair that Whissi had a lot of time to verify/validate his claims, but not much happened
+[20:14:18] <mgorny> the biggest problem with APNG to my knowledge is that software that doesn't support APNG just shows some selected frame without even indicating to the user that there could be more content
+[20:14:22] <ulm> mozilla's argument against mng was that they wanted to save 300 kB of memory for the decoder :)
+[20:14:26] <mgorny> and this is why it was rejected by the PNG Group
+[20:14:26] <Marecki> Of course we ARE talking about upstream which, for all that it has brought to the FOSS world over the years, hasn't exactly got the best reputation as long as co-operation is concerned.
+[20:14:42] <dilfridge> who? google or mozilla? :D
+[20:14:47] <soap> ahahaha
+[20:15:01] <Marecki> Both, sadly.
+[20:15:14] <sam_> ok
+[20:15:17] <dilfridge> so
+[20:15:17] <Marecki> As the whole "phasing out python2" situation last year showed.
+[20:15:20] <sam_> ... do any of us actually need to discuss this?
+[20:15:24] <sam_> it feels like everyone is sort of clear here
+[20:15:33] <sam_> if not, that's fine, but i get the impression everyone sort of gets the picture
+[20:15:39] <mgorny> well, i'm open to questions if anyone has any
+[20:15:40] <dilfridge> I guess we should vote for mgorny's proposal now. Let me summarize it:
+[20:15:47] <dilfridge> s/for/about/
+[20:15:50] <sam_> (discuss this further)*
+[20:15:59] <Marecki> For me it will be choosing the lesser evil rather than making a good choice - but IMHO it's clear which way to go
+[20:16:36] <Marecki> Or at least clear enough for me which way I will vote
+[20:16:47] <dilfridge> proposal: 1) mozilla / firefox gets a system-png flag, and 2) apng useflag is turned off by default
+[20:16:59] <dilfridge> mgorny: is that the gist of it?
+[20:18:00] <mgorny> dilfridge: to be more precise 1) is about firefox, thunderbird and seamonkey (but my PR doesn't include seamonkey since the package does not build and our maintainer doesn't want to fix it because new enough system sqlite is not yet available in Gentoo)
+[20:18:11] <dilfridge> ack
+[20:18:27] <mgorny> and 2) means removing this:
+[20:18:29] <mgorny> profiles/targets/desktop/package.use:media-libs/libpng apng
+[20:18:53] <dilfridge> 1) mozilla products get a system-png useflag where applicable, 2) apng useflag enabling is removed from desktop profiles
+[20:19:02] <mgorny> ACK
+[20:19:02] <dilfridge> ^ please vote on this proposal
+[20:19:13] -*- Marecki yes
+[20:19:14] -*- gyakovlev yes
+[20:19:17] -*- dilfridge yes
+[20:19:23] -*- mgorny yes
+[20:19:28] -*- sam_ yes (same as Marecki; wish we weren't in this situation, but this is the better choice out of the two.)
+[20:19:34] -*- soap yes
+[20:19:41] -*- ulm abstains (for the personal reason mentioned in my devaway, I haven't found the time to verify the different claims myself)
+[20:19:51] <dilfridge> thank you
+[20:20:01] <dilfridge> that makes 6 yes, 1 abstention, 0 no, motion passed
+[20:20:17] <dilfridge> next item
+[20:20:19] <dilfridge> 3) Infra shopping list, request for proposals [3,4]
+[20:20:24] <dilfridge> > > [3] https://archives.gentoo.org/gentoo-project/message/d65e2b67bb97dbb5de5ff4c1fcaab857
+[20:20:24] <dilfridge> > > [4] https://wiki.gentoo.org/wiki/Project:Infrastructure/Shopping_list
+[20:21:01] <dilfridge> as far as I understand it this is more of a request for discussion and opinions than for a decision now
+[20:21:35] <soap> antarus: this discussion is orthogonal to the one about the HPPA boxes, right?
+[20:21:36] <dilfridge> anyone got some input / output ?
+[20:21:46] <dilfridge> the hppa comes next
+[20:21:56] <sam_> i'd missed the latest update to that page (it was just about switches before) but i don't think i've got anything to add at this point to that, other than "go ahead with figuring out what you want"
+[20:22:34] <sam_> not sure if antarus had something specific in mind
+[20:22:36] <ulm> these shipping costs seems rather large
+[20:22:52] <ulm> what's the size/weight we're talking about for that hppa system?
+[20:22:53] <mgorny> i'm a bit worried about the ecological aspect but i guess that's a good way to spend Foundation money
+[20:23:02] <dilfridge> ulm: later please
+[20:23:06] <dilfridge> let's not mix it up yet
+[20:23:37] <dilfridge> from my side, similar, "go ahead with figuring out what you want"
+[20:24:00] <dilfridge> if there's money, then that's a good chance to get away from anythign close to collaps
+[20:24:13] <soap> I think it's pretty obvious that an opteron 6272 should be replaced in 2022
+[20:24:22] <dilfridge> yup
+[20:24:30] <dilfridge> and not with a raspi either
+[20:24:48] <mgorny> though it might be worthwhile for infra to consider if we actually have any use for that many machines
+[20:25:10] <sam_> i've wondered before if it should be consolidated a bit with beefier machines
+[20:25:11] <mgorny> maybe we should replace N old machines with one beefier, and try to figure out how to load them reasonably
+[20:25:19] <Marecki> Aye. And having worked with a group which ran a cluster based on systems with similar specs as jacamar, I can very much believe in the "sucks power" claim
+[20:25:21] <sam_> (although you could do beefier and more which is better than the status quo)
+[20:25:22] <dilfridge> N old with 2-3 beefy ones
+[20:25:26] <mgorny> and/or reuse some of them as devboxes
+[20:25:32] <dilfridge> let's keep some redundancy
+[20:25:45] <sam_> so i think in terms of actionable items, there's not much here
+[20:25:49] <dilfridge> ok 
+[20:25:55] <sam_> although i'd really like to suggest the idea of a devbox which is beefy for devs to use/test on
+[20:26:00] <dilfridge> gonna be fun to summarize
+[20:26:03] <dilfridge> then 
+[20:26:07] <sam_> i'll propose that on the ML or something though, not relevant for now here.
+[20:26:12] <dilfridge> yes
+[20:26:17] <dilfridge> next item, now for real
+[20:26:23] <Marecki> I'd suggest switching most of our systems to OpenStack for ease of resource distribution but I think Infra will kill me if I do :-)
+[20:26:36] <Marecki> In all seriousness though, no red flags with the current proposal.
+[20:26:40] <gyakovlev> Marecki: please no =)
+[20:26:48] <dilfridge> 4) Minor financial issues: HPPA shipping  https://bugs.gentoo.org/828113
+[20:27:08] <mgorny> i'm a bit confused why dwfreed's calculation uses different weight/dimensions than the other ones
+[20:27:35] <mgorny> but i suppose they don't know yet how exactly it's going to be packaged
+[20:27:42] <Marecki> Two questions here:
+[20:28:04] <mgorny> it basically looks like dwfreed crossed some boundary in one dimension that caused the costs to skyrocket
+[20:28:08] <Marecki> 1) how much improvement will the new system(s) be?
+[20:28:28] <dilfridge> shipping is a general problem these days (I just ordered a big box from the foggy north sea island, and EXW versus DAP made a huge difference)
+[20:28:33] <Marecki> (some input from HPPA arch testers might be good here)
+[20:28:39] <mgorny> Marecki: amiga can beat our current hardware
+[20:28:40] -*- sam_ chimes in
+[20:28:55] <sam_> so I'm actually using the box that we are discussing receiving here
+[20:29:02] <sam_> it's actually usable, which is.. the key thing here
+[20:29:05] <gyakovlev> re shipping cost
+[20:29:05] <gyakovlev> I often ship from US to EU, $150 is minimum one is looking just to send something box-sized with 0 weight. I've sent something about ~12kg, size of a typical desktop tower. which cost me $550, and that was USPS, not an express service, with no customs fees. 
+[20:29:05] <mgorny> and i suppose it runs on a dedicated nuclear reactor
+[20:29:05] <Marecki> 2. Do we really have no reasonably priced option for running this machine on this side of the Atlantic?
+[20:29:07] <dilfridge> so I would not be surprised by fairly high shipping costs
+[20:29:09] <sam_> hake is painfully slow, and I'm not exaggerating
+[20:29:27] <sam_> terminator (this box) makes arch testing practical, which is all I can ask for
+[20:29:36] <dilfridge> ++
+[20:29:58] <soap> ++
+[20:30:13] <sam_> Marecki: 2. is a good question. sadly AFAIK we have no real options for that in Europe
+[20:30:23] <mgorny> Marecki++
+[20:30:24] <sam_> we only have sponsored boxes, no colo space, I think
+[20:30:34] <sam_> i would really like to keep more in Europe, not just putting it all at OSUOSL
+[20:30:42] <sam_> (in future, we should really have infra around for these items...)
+[20:30:57] <sam_> !proj infra
+[20:30:58] <willikins> sam_: (infra@gentoo.org) alicef, antarus, arzano, blueknight, bman, grknight, jmbsvicetto, maffblaster, mgorny, prometheanfire, robbat2, slashbeast, zlogene
+[20:30:58] <sam_> ^^^
+[20:31:09] <mgorny> i don't think there's a need to make any decision today
+[20:31:11] <sam_> but that's neither here nor there for now. GMsoft needs this box gone now
+[20:31:14] <sam_> there is a need
+[20:31:18] <sam_> he's moving shortly and will be throwing it out otherwise
+[20:31:30] <mgorny> ah
+[20:31:43] <sam_> (otherwise I'd agree with exploring options in .eu)
+[20:31:56] <Marecki> Seeing as the capabilities of current HPPA systems have been one of the reasons for me to suggest dropping stabilisation on this arch, and that I am far from suggesting dropping HPPA support altogether, if the new box helps then it definitely makes sense. And if we have to get it now or not at all, oh well.
+[20:32:08] <dilfridge> so basically my suggestion would be, we vote on our assent to the foundation motion from bug comment 3
+[20:32:08] <soap> he can get it shipped to me or someone else in the EU for safekeeping right now?
+[20:32:28] <mgorny> soap: but that doubles the costs, doesn't it?
+[20:32:34] <sam_> problem is, when I've asked before, AFAIK we have no capacity / contacts for colo in the EU right now
+[20:32:41] <soap> mgorny: shipping LU->Germany should be a lot cheaper
+[20:32:43] <sam_> so I don't think it's realistic we'd get something stood up anytime soon
+[20:32:47] <mgorny> unless you go grab it ;-P
+[20:32:52] <soap> no customs, ground shipping bla
+[20:33:07] <dilfridge> soap: what's the point of it, why not decide now?
+[20:33:13] <Marecki> soap: You're not in the EU :-P Seriously though, it might be an option... Shipping to/from the States has got ridiculously expensive in the last 5 years or so.
+[20:33:16] <sam_> soap: it'd still likely end up in the US if we wanted HPPA stuff working any time soon though, unless you wanted to run it for the time being, and exert pressure to setup proper EU colo?
+[20:33:23] <sam_> would that be something you're willing to do?
+[20:33:30] <soap> ulm could drive to LU and pick it up :P
+[20:33:40] <soap> dilfridge: no lets do it,
+[20:33:48] <soap> just saying, would be a shame to lose these
+[20:33:52] -*- dilfridge checks if LU is high risk area
+[20:34:03] <ulm> soap: 220 km
+[20:34:07] <Marecki> As a matter of fact I'll be passing by in early January...
+[20:34:08] <ulm> that's doable
+[20:34:18] <sam_> fwiw I'm also trying to get one of the boxes from gmsoft to keep in the house although I doubt I could afford to keep it on 24/7
+[20:34:19] <mgorny> soap: just wanted to suggest that ;-D
+[20:35:00] <Marecki> Normally I drive E-W somewhat further to the north but could make a detour via LU if need be. Can't keep it at home for more than a week though, as I will be moving.
+[20:35:16] <soap> so lets ACK?
+[20:36:01] <dilfridge> so what now, pick-up or shipping?
+[20:36:01] <sam_> correction by the way: the box I'm using (terminator) is a C8000 which I'm trying to get here. the one mattst88 proposed here for the US / OSUOSL is a rp3440. comparable speed
+[20:36:10] <mgorny> soap: how does gmsoft's box compare to the ebay thing?
+[20:36:34] <soap> mgorny: it's pretty much the same box?
+[20:36:39] <mgorny> ah, ok
+[20:36:59] <mgorny> well, i'm for either paying for shipping or paying ulm for gas to go grab it ;-)
+[20:37:22] <sam_> the blocker here is "do we think there's a realistic chance of setting it up in .eu anytime soon?"
+[20:37:24] <soap> or jstein if he fancies a trip to LU ;)
+[20:37:29] <sam_> we have no infra input right now
+[20:37:29] <soap> bonn is probably even closer
+[20:37:47] <sam_> we can approve with the proviso that it should be housed in the .eu if feasible within the next few months, but otherwise ship to US
+[20:37:54] <Marecki> Hah, I completely forgot ulm is in MAINZ!
+[20:38:05] <sam_> (so that infra can chime in, but i feel like it's not doable right now.)
+[20:38:18] <dilfridge> let's do that
+[20:38:27] <mgorny> how about we ask infra for a quick clarification, and then vote on the bug?
+[20:38:28] <sam_> ack
+[20:38:30] <sam_> ok
+[20:38:35] <sam_> either works for me. up to dilfridge as chair
+[20:38:41] <dilfridge> proposal: approve with the proviso that it should be housed in the .eu if feasible within the next few months, but otherwise ship to US
+[20:38:49] <sam_> i would like to try the infra angle if we can, just because it's better for decentralisation + environment + costs
+[20:38:58] -*- sam_ yes
+[20:39:03] <Marecki> Let me clarify, then: I'll be driving from northern France to Heidelberg in early January. Could in principle pick the box up in LU and leave it with ulm some time within the week that follows.
+[20:39:14] -*- Marecki yes
+[20:39:17] -*- dilfridge yes
+[20:39:21] -*- soap yes
+[20:39:25] -*- mgorny yes
+[20:39:34] -*- ulm yes
+[20:39:49] -*- gyakovlev yes
+[20:40:02] <dilfridge> excellent that makes 7 yes, 0 no, 0 abstentions
+[20:40:06] <sam_> soap: actually you're supposed to abstain :D
+[20:40:19] <dilfridge> too late now :P
+[20:40:36] <soap> oh noes!
+[20:40:38] <soap> :D
+[20:40:41] <dilfridge> 5) Open bugs with council participation
+[20:41:09] <dilfridge> bug 821553
+[20:41:10] <willikins> dilfridge: https://bugs.gentoo.org/821553 "Document upgrade path policy"; Documentation, Devmanual; CONF; sam:devmanual
+[20:41:35] <dilfridge> as far as I can see this is mostly somthing to be figured out by docs writers
+[20:41:50] <Marecki> We're just waiting for implementation here, aren't we.
+[20:41:57] <dilfridge> yup
+[20:42:11] <dilfridge> bug 824018
+[20:42:12] <willikins> dilfridge: https://bugs.gentoo.org/824018 "media-libs/libpng: dropping "apng" patches"; Gentoo Linux, Current packages; CONF; juippis:base-system
+[20:42:18] <dilfridge> we dealt with this already
+[20:42:24] <Marecki> Si
+[20:42:28] <dilfridge> bug 823762
+[20:42:29] <willikins> dilfridge: https://bugs.gentoo.org/823762 "[TRACKER] ~ only candidate arches"; Gentoo Council, unspecified; CONF; gyakovlev:council
+[20:42:41] <-- xgqt (~xgqt@gentoo/developer/xgqt) hat das Netzwerk verlassen (Ping timeout: 250 seconds)
+[20:42:49] <dilfridge> no news here I guess, so nothing actionable
+[20:42:57] <gyakovlev> from ppc side we made some progress
+[20:43:02] <dilfridge> \o/
+[20:43:04] --> xgqt (~xgqt@gentoo/developer/xgqt) hat #gentoo-council betreten
+[20:43:04] *** Modus #gentoo-council +v xgqt by ChanServ
+[20:43:16] <gyakovlev> but since we got more bodies working on it - it's so much quicker now
+[20:43:39] <gyakovlev> but I de-keyworded something on ppc, still trying to install dedicated box for ppc32 only.
+[20:43:52] <dilfridge> I want to poke catalyst a bit over christmas, maybe find a better way to make alpha and m68k builds (these have both problems with qemu usermod emulation)
+[20:43:56] <gyakovlev> we have a bit of more users lately due to couple distros dropping support
+[20:43:57] <sam_> tbh I think we're doing pretty well on most fronts: https://www.akhuettel.de/gentoo-bugs/arches.php
+[20:44:19] <sam_> (the spike in the graphs is from when I dumped a load of Perl bugs the other day)
+[20:44:26] <dilfridge> hrhr
+[20:44:49] <dilfridge> mostly out of curiosity, is anyone here interested in mips?
+[20:45:03] <sam_> jsmolic mentioned a possible interest to me
+[20:45:21] <sam_> i'm not really sure if like, the issue is no stages -> less interest, or less interest -> no real stages
+[20:45:28] <dilfridge> yup
+[20:45:29] <gyakovlev> yes
+[20:45:30] <sam_> i very rarely see anyone asking about it?
+[20:45:37] <sam_> but mips is still a thing
+[20:45:47] <soap> my feeling is that even the most powerful MIPS hardware is quite a bit slower than say hppa?
+[20:45:47] <dilfridge> stages are comparatively easy
+[20:46:25] <dilfridge> soap: but there's also loongarch coming :P
+[20:46:37] <dilfridge> (seriously the code is going into the gnu toolchain)
+[20:46:45] <gyakovlev> loooooooooong story
+[20:46:56] <soap> dilfridge: but that isnt mips? or more like, a mips abomination?
+[20:46:59] <Marecki> soap: I guess the fact MIPS hardware seems to be a bit easier to get hands on offset this, at least to some degree?
+[20:47:05] <soap> I thought its a new ISA (the world doesnt need)
+[20:47:06] <dilfridge> it's a mips extension, yes
+[20:47:18] <dilfridge> anyway
+[20:47:21] <dilfridge> bug 824018         
+[20:47:22] <willikins> dilfridge: https://bugs.gentoo.org/824018 "media-libs/libpng: dropping "apng" patches"; Gentoo Linux, Current packages; CONF; juippis:base-system
+[20:47:29] <dilfridge> err sorry
+[20:47:38] <dilfridge> bug 828113
+[20:47:39] <willikins> dilfridge: https://bugs.gentoo.org/828113 "Proposal to ship donated HPPA development system from Europe to OSUOSL"; Gentoo Foundation, Proposals; IN_P; mattst88:trustees
+[20:47:44] <Marecki> At least half of my employers over the last 20 years have had MIPS servers lying around.
+[20:47:44] <dilfridge> we dealt with that already too
+[20:47:47] <Marecki> Also done
+[20:47:56] <dilfridge> which brings us to 
+[20:47:59] <dilfridge> 6) open floor
+[20:48:01] <dilfridge> anyone?
+[20:48:06] <sam_> one last thing
+[20:48:10] <sam_> let's consider putting out a call on the ML 
+[20:48:11] <sam_> re MIPS
+[20:48:15] <sam_> i'm really interested if anyone cares
+[20:48:43] <dilfridge> sure why not
+[20:48:54] <sam_> cool
+[20:48:59] <sam_> ok, nothing more from me
+[20:49:35] <dilfridge> that's it then
+[20:49:38] <dilfridge> meeting closed
diff --git a/meeting-logs/20211212.txt.asc b/meeting-logs/20211212.txt.asc
new file mode 100644
index 0000000..3fcca9d
--- /dev/null
+++ b/meeting-logs/20211212.txt.asc
@@ -0,0 +1,19 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v2
+
+iQKTBAABCgB9FiEE6W4INB9YeKX6Qpi1TEn3nlTQogYFAmG2U41fFIAAAAAALgAo
+aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU5
+NkUwODM0MUY1ODc4QTVGQTQyOThCNTRDNDlGNzlFNTREMEEyMDYACgkQTEn3nlTQ
+ogbgbhAAnwAIXaNV2vCfCrMmUwbpwOEylGBi9EQTv0jkQTXWbaS6T9PjWpox9gVN
+hsPmJ9HdKA/S0fVKm+kYOrLX2L35DO8TiAFMWDGoKUirWg4aj4qSTn7f4Ii9V49q
+qZX34NeYrJPBsY0fpZD69KtUbQnBJTt7YZj8bX4Y5ssidVke5H71KGVAIV5B73Oe
+dIZVwoqSmcluFrYXyZR+YRR+zHHVVZjB+dJTjpV94lTspemKOEEJzxu0tP/oNC0s
+nPjvtl2OyCpLun2ZQdZRvm72N7fSkKCqMDhPUtXMDQ9sAwyZdwmjaEwMp+ilyjP4
+TeSbHpE76R4bC63WS7oWvIndGJenBxqjXhCqGgsiyPu+r5Ok0uYASeNGlOi7TfIc
+6xNcuqXCstgkAHhDjMtmc2aACNOXIdQJSfyOEE2xs/uLOynekjT8ywGkXN8hwz/q
+JNL90R6UjtmcBOqXTMpa49ITMs05fECfI4I+wxafj1N93Wy0Ix9Aq/kJEF7Haslw
+tjcDE0OOXglfOT3daO15uj5kHEG8B0F3HnI/3eg3dRKkVbp0nafKU7FHSsDx57Sp
+cOSLgg/N+vUEa1yEU+W2ZUci2BBKDyQMm7t281L4+4dvQa5CEaN9xqTIW2KBKEYF
+EUUvltCfqUA+QlavqkcrEUbLUfky7LTIubZKLuv25u+yFcHHWW0=
+=JYSU
+-----END PGP SIGNATURE-----