diff options
authorWilliam Hubbs <>2021-05-09 21:27:27 -0500
committerWilliam Hubbs <>2021-05-09 21:29:00 -0500
commit08225b32407b935e4dadfe759d3a638ea8cd6401 (patch)
parentmeeting-logs/README: Update date (diff)
add meeting log for 20210509HEADmaster
Signed-off-by: William Hubbs <>
2 files changed, 442 insertions, 0 deletions
diff --git a/meeting-logs/20210509.txt b/meeting-logs/20210509.txt
new file mode 100644
index 0000000..04b10f2
--- /dev/null
+++ b/meeting-logs/20210509.txt
@@ -0,0 +1,426 @@
+14:01 <@WilliamH> Ok let's get started.
+14:01 <@dilfridge> \o\ \o/ /i/
+14:01 <@WilliamH> agenda:
+14:02 <@WilliamH> 1. Roll call
+14:02 * gyakovlev here
+14:02 * slyfox here
+14:02 * ulm here
+14:02 * Whissi here
+14:02 * dilfridge here, holleri-di-dodl-dö
+14:02 * WilliamH here
+14:02 * gyakovlev pokes mattst88
+14:02 * mattst88 here
+14:03 <@gyakovlev> WilliamH: all here.
+14:03 <@WilliamH> 2. set date to remove sha512 hash from ::gentoo manifests.
+14:03 <@WilliamH> bug 784710
+14:04 <+willikins> WilliamH: "Remove SHA512 hash from Manifests"; Gentoo Council, unspecified; CONF; mgorny:council
+14:04 <@Whissi> I want to say something to his/have a question.
+14:04 <@Whissi> The idea of having multiple hashes was and still is, to have a backup in case we have to disable one hash because the algorithm isn't secure anymore.
+14:04 <@WilliamH> Whissi: go for it.
+14:04 <@Whissi> This is still valid for me.
+14:04 <@Whissi> So unless there is a reason to drop SHA512 (maybe because it requires an additional dependency which is causing problems or something like that), I want to keep two algorithms.
+14:04 <@Whissi> There's also the argument from robbat2, having an algorithm used by upstream to compare against.
+14:04 <@WilliamH> mgorny: ^^
+14:05 <@Whissi> So my question is: What's the reason to drop SHA512? What's the benefit?
+14:05 <@ulm> IIUC it would speed up things
+14:06 <@WilliamH> That's all I can think of, is it a significant speedup?
+14:06 <@dilfridge> I would just keep things as they are now... it's not that much of a slowdown
+14:07 <@dilfridge> in a year or so we can revisit whether we want to replace one of the two hashes with a newer one (like sha3)
+14:07 <+robbat2> if you're concerned about a slowdown, at verification time, just verify one of the hashes for a given file rather than all
+14:07 * dilfridge is happy with SHA512 + BLAKE2B
+14:07 <@ulm> about the argument about upstream hashes: if we really wanted that, then we'd have to add specific hash types depending on the package
+14:08 <@slyfox> I would defer to security@ for best practices and hash rotation
+14:08 <@ulm> a fixed set of hashes won't help much with it I think
+14:08 <@dilfridge> for that we also already have mgorny's pgp signature verification project
+14:08 <@WilliamH> slyfox: that's probably a good idea.
+14:08 <@mattst88> I'm happy to punt on this for now
+14:09 <@WilliamH> mattst88: I'm ok with punting on this as well.
+14:09 * dilfridge checks for strawberries and gramophone
+14:09 <@Whissi> I am more concerned about droping existing SHA512 hash now. Remember how much work it was to get tree updated for Blake2B... if we are in _need_ to migrate to a new algorithm... at the moment we have to competing hashes and it is unlikely that both will fall in the same moment.
+14:09 <@Whissi> *two
+14:10 <@mattst88> It's unlikely that one will fail, period.
+14:11 <@WilliamH> So are we agreeing to punt on this for now?
+14:11 <@slyfox> sounds good for me
+14:11 <@mattst88> yes
+14:11 <@Whissi> yes
+14:11 <@dilfridge> yes, no changes.
+14:11 <@dilfridge> (probably for different reasons, but the outcome is what counts.)
+14:11 <@ulm> +1
+14:11 <@WilliamH> moving on:
+14:12 <@WilliamH> 3. Set date to remove flat layout from official gentoo mirrors
+14:12 <@WilliamH> bug 784713
+14:12 <+willikins> WilliamH: "Remove old distfile mirror layout"; Gentoo Council, unspecified; CONF; mgorny:council
+14:12 <@gyakovlev> question: before we do that, local layout in $DISTDIR says the same, right?
+14:12 <@gyakovlev> flat, not nested
+14:13 <@slyfox> yes, the bug is only about mirror layout
+14:13 <@WilliamH> gyakovlev: Right, I haven't seen this affect local distdir.
+14:13 <@Whissi> I don't see a problem with that. It only affects our master mirror. It shouldn't cause an effect for anybody.
+14:13 <@Whissi> So let's say 2021-10-01 for example
+14:13 <@dilfridge> it affects people with old portage. then again, whose portage is older than 2019-10 will probably want to update portage first.
+14:14 <@Whissi> dilfridge: But they can still download from mirrors using old layout
+14:14 <@slyfox> fallback to upstream url shoould also work
+14:14 <@mattst88> Whissi: how about 2021-10-18 for exactly 2 years? :)
+14:14 <@Whissi> mattst88: wfm
+14:14 <@dilfridge> Whissi: no
+14:14 <@gyakovlev> mattst88: nah, let's give it a 10-15 years like usual.
+14:15 <@mattst88> heh
+14:15 <@ulm> 2019-10 is the _stable_ portage date?
+14:15 <@dilfridge> mirrors "mirror" our directory structure, i.e. mirrors will have the same deep structure then
+14:15 <@dilfridge> if portage doesnt support that, it wont find the files
+14:15 <@mattst88> ulm: no, AFAIK 2019-10 is when the new mirror layout went live. not sure how that correlates with portage
+14:15 <@gyakovlev> 1 year from stabling capable portage seems sane imo.
+14:16 <@WilliamH> gyakovlev++
+14:16 <@Whissi> dilfridge: No, there are still old mirrors with flat design out there.
+14:16 <@WilliamH> When was that portage stabled?
+14:16 <@Whissi> And portage not aware of this change should work with them
+14:16 <@ulm> make it 2 years, because it will break the upgrade path
+14:16 <@dilfridge> Whissi: how so? I mean, right now there are both sets of files on our master...
+14:16 <@slyfox> +1 for 2 years since portage's feature stable support
+14:16 <@dilfridge> +1
+14:17 <@Whissi> 2 years, wfm
+14:17 <@mattst88> looks like 6a539b7c5163899db1d58cf152aeab1b2b4f9be4 is the portage.git commit for adding the new layout, first in portage-2.3.77
+14:17 <@ulm> we need not figure out that date during the meeting
+14:17 <@slyfox> also, even if no mirrors are available portage should still be able to fetch sources from upstream URLs (I hope Gentoo still hosts up-to-date portage source)
+14:18 <@WilliamH> Yeah it should be able to hit upstream sources so I don't see how this will break the upgrade path.
+14:19 <@gyakovlev> 2019-10-14 - capable portage got into tree.
+14:19 <@gyakovlev> 2019-11-25 - fist capable became stable.
+14:19 <@mattst88> FWIW, looks like portage-2.3.79 was stabilized in Nov 2019
+14:19 <@mattst88> and I think that was the first version stabilized after the commit I mentioned
+14:19 <@dilfridge> Tue Nov 26 13:24:45 2019
+14:19 <@gyakovlev> make in 2021-12-01 then
+14:19 <@dilfridge> on amd64
+14:19 <+robbat2> if there are further concerns about dropping the support, i had pitched that we could have a fallback URL service that generated redirects
+14:19 <@ulm> 2019-12-04 on last arch
+14:19 <@WilliamH> That would mean 2021-12-04
+14:20 <@ulm> but yeah. 2021-12-01 sounds good
+14:20 <@dilfridge> robbat2: imho that's overkill, the fallback is the upstream URL
+14:20 <@WilliamH> dilfridge++
+14:20 <@Whissi> In worst case, all you have to do is fetching portage distfiles to $DISTDIR, not? Once portage was upgraded...
+14:20 <+robbat2> until upstream no longer provides the distfiles
+14:20 <+robbat2> but yes, also manual downloads are an option
+14:21 <@dilfridge> yes, or cloning portage.git
+14:21 <@gyakovlev> portage is even on pypi now. installable via pip =)
+14:21 <@WilliamH> gyakovlev: cool.
+14:21 <@ulm> portage's dependencies could be a problem, not portage itself
+14:22 <@mattst88> the potential for breakage here really doesn't seem like a big deal to me
+14:22 <@WilliamH> ulm: if it is installable via pip that covers the dependencies?
+14:22 <@Whissi> ACK.
+14:22 <@gyakovlev> still, 2 years is a lot of time. we all know how much pain is to update a system THAT behind
+14:22 <@mattst88> indeed
+14:23 <@gyakovlev> so caring about something that has 5% chance of success
+14:23 <@gyakovlev> idk
+14:23 <@Whissi> And if it turns out that many people will hit this problem, we can still take actions...
+14:23 <@mattst88> ulm: heh, the last arch to stabilize that portage version was alpha, and I dropped stable keywords soon after
+14:23 <@dilfridge> works for me
+14:23 <@ulm> mattst88: true
+14:23 <@gyakovlev> it's literally more time consuming to update such system than reinstall/recompile/reconfigure
+14:23 <@ulm> ppc64 was before that on 2019-11-28
+14:23 <@mattst88> I suggest we just pick Nov 25 2021 and be done with it :)
+14:24 <@dilfridge> it's perfectly doable, but more like a trick puzzle than a useful occupation
+14:24 <@gyakovlev> mattst88: cmon, let's make it a round date
+14:24 <@gyakovlev> 1 dec sounds nice
+14:24 <@dilfridge> ++
+14:24 <@mattst88> sure
+14:24 <@ulm> +1
+14:24 <@WilliamH> Do we need to vote on this or should I update the bug and say that we set the date to 2021-12-01?
+14:24 <@slyfox> Let's vote
+14:24 <@ulm> quick vote please
+14:24 * dilfridge yes
+14:24 * mattst88 yes
+14:24 * slyfox yes
+14:24 * Whissi yes
+14:24 * ulm yes
+14:24 * gyakovlev yes for 2021-12-01
+14:24 * WilliamH yes
+14:25 <@slyfox> \o/
+14:25 <@WilliamH> one sec I'll update the bug.
+14:26 <@WilliamH> done. moving on.
+14:26 <@ulm> gyakovlev: that's portage-2.3.79, right?
+14:26 <@ulm> i.e. -r0?
+14:27 <@gyakovlev> ulm: 2.3.77 was the version but .79 got stable yeah
+14:27 <@ulm> k
+14:27 <@WilliamH> 4. Begin discussion about whether lto should be supported
+14:27 <@dilfridge> [21:17:42] <dilfridge> zmedico: which portage version first supported the "deep mirror layout" for distfiles?
+14:27 <@dilfridge> [21:22:30] <zmedico> dilfridge: first version was portage-2.3.78 and first stable was portage-2.3.79, bug 701106
+14:27 <@dilfridge> [21:22:31] <willikins> "sys-apps/portage-2.3.79 stablereq"; Gentoo Linux, Stabilization; RESO, FIXE; zmedico:dev-portage
+14:27 <@dilfridge> [21:22:43] <dilfridge> ++ thanks
+14:27 <+willikins> dilfridge: "sys-apps/portage-2.3.79 stablereq"; Gentoo Linux, Stabilization; RESO, FIXE; zmedico:dev-portage
+14:27 <@dilfridge> k
+14:28 <@dilfridge> my baby
+14:28 <@WilliamH> dilfridge: I believe you mentioned lto originally.
+14:28 <@WilliamH> My immediat thought is, should this go to the -dev list first?
+14:28 <@mattst88> I think we should consider LTO supported. Binary distros are doing it, so if *we're* not, what are we doing here? :)
+14:28 <@dilfridge> so mostly I brought this up because I got annoyed...
+14:28 <@dilfridge> we keep telling people "lto is dangerous", but at the same time fedora ubuntu suse... have it as default
+14:29 <@Whissi> What do you expect from this topic? I mean, what will change?
+14:29 <@gyakovlev> We definitely should support it at least on best-effort basis, not as a mandatory thing. it can still weak complete havoc on many many things.
+14:29 <@mattst88> GCC/clang's LTO support is very good these days, and lots of fixes have gone into upstream packages in recent years
+14:29 <@WilliamH> Do we actively block lto support?
+14:29 <@gyakovlev> Whissi: not closing lto ricing bugs as INVALID WONTFIX for starters =)
+14:29 <@dilfridge> Whissi: I want us to provide direction... "let's strive to have lto work out of the box"
+14:29 <@ulm> people will complain about build time and memory requirement for even more packages :/
+14:29 <@gyakovlev> not implying anyone specific, just general approach
+14:29 <@mattst88> gyakovlev: right. We should consider an LTO-failing bug like we consider "ignores CFLAGS" bugs, etc
+14:30 <@dilfridge> nobody will be forced to use it, but we should consider such failures as real bugs
+14:30 <@mattst88> i.e., something to be fixed but probably not top priority
+14:30 <@ulm> so yes for supporting it, but I'd rather think twice before making it the default
+14:30 <@gyakovlev> mattst88++
+14:30 <@slyfox> default? haha :)
+14:30 <@gyakovlev> we have too many variables to make it default
+14:31 <@gyakovlev> bin distros have pretty static build env with way less variation.
+14:31 <@dilfridge> yeth
+14:31 <@WilliamH> Did the council make a decision that closing lto bugs as wontfix/invalid is what we should be doing? I don't recall us doing that.
+14:31 <@dilfridge> no
+14:31 * Whissi is still confused what will change vs. status quo :)
+14:31 <@gyakovlev> WilliamH: sometimes such bugs are met with a bit of hostility
+14:31 <@gyakovlev> we need to discourage that
+14:31 <@gyakovlev> and encourage support.
+14:32 <+mgorny> i'm around now if anybody needs me
+14:32 <@dilfridge> mgorny: seems we dont need you until 1/Dec
+14:32 <@dilfridge> :P
+14:32 <@slyfox> Whissi: i think clear signal to most devs can move the needle for some devs that hesitate
+14:32 <+mgorny> then i get back to fixing pkgcore
+14:33 <@WilliamH> gyakovlev: that's a maintainer issue really.
+14:33 <@dilfridge> imho, filtering out lto flags is perfectly fine if it doesnt work somewhere
+14:33 <@WilliamH> dilfridge++
+14:33 <@slyfox> same as for any other flags
+14:33 <@mattst88> quick vote to state that LTO should be considered a valid configuration?
+14:33 <@dilfridge> we should just make clear, we want people to be able to use it
+14:33 <@dilfridge> mattst88++
+14:33 * dilfridge yes
+14:34 <@gyakovlev> dilfridge: maybe you could drop an email to -dev with short encouragement not to close such bugs with some mythbusting and clarifications to raise awareness?
+14:34 <@dilfridge> can do
+14:34 <@gyakovlev> that's gonna be a good start
+14:34 * slyfox yes
+14:34 * mattst88 yes
+14:34 <@WilliamH> mattst88: to clarify is that a motion?
+14:34 <@ulm> yeah, are we voting? on what motion?
+14:34 <@mattst88> WilliamH: well, I was asking if we should do a motion, but sure :)
+14:35 <+mgorny> mattst88: tbh, i think you need a more specific motion
+14:35 <@gyakovlev> agenda item says it's a discussion. idk if it's votable.
+14:35 <@Whissi> But wait. I have a question before, just to make sure I understand:
+14:35 <@mattst88> Motion: Consider LTO compiler flags to be a valid configuration
+14:35 <@WilliamH> Whissi: go for it.
+14:35 <@Whissi> There's dev-db/mysql... LTO/PGO is broken and not supported upstream.
+14:36 <@Whissi> I am not going to carry a custom patch for example, because this is Oracle
+14:36 <@Whissi> To get this upstream, I would have to sell my soul.
+14:36 <@Whissi> And upstream isn't interested
+14:36 <@gyakovlev> Whissi: it's perfectly ok to filter it out in such case imo
+14:36 <@slyfox> it's not different from any other compiler flags
+14:36 <@dilfridge> filtering out lto flags is perfectly fine if it doesnt work somewhere
+14:36 <@WilliamH> Why not then:
+14:36 <@Whissi> Can I still say, "Sorry, I can't do anything. Even if you provided a patch which works for this specific version but will break on next Oracle patch day in 3 months?"
+14:36 <@WilliamH> motion: lto can be supported at the maintainer's discression.
+14:37 <@Whissi> Ok, wfm
+14:37 <@WilliamH> Then dilfridge you send out your email about lto to the dev ml.
+14:37 <@ulm> also keep the qa lead's posting of today in mind
+14:37 <@gyakovlev> WilliamH: it is how it is right now
+14:37 <@dilfridge> we're telling people "We try to give you a good system if you set lto flags in make.conf"
+14:37 <+mgorny> again, please make the motion more specific
+14:38 <+mgorny> like, are the developers expected to actively test lto scenarios?
+14:38 <+mgorny> or are we happy with just reacting to bugs?
+14:38 <@mattst88> Happy to react to bugs, like with dev-lang/python-exec[-native-symlinks], I think
+14:39 <@gyakovlev> I think only packages that provide USE=lto should be actively tested
+14:39 <@ulm> if we don't test it then we can't consider it supported?
+14:39 <@WilliamH> Or maybe, are LTO flags considered safe?
+14:39 <@gyakovlev> packages using FLAGS are optionally tested
+14:39 <@gyakovlev> and bugs reacted to
+14:39 <@Whissi> Of course, what you expose via USE flags should be tested.
+14:40 <@WilliamH> gyakovlev: there is a group of cflags that are not considered saffe and we close bugs as invalid/wontfix for them.
+14:40 <@WilliamH> safe *
+14:40 <@gyakovlev> WilliamH: yeah that's the point, some treat lto flags like this
+14:40 <@mattst88> ulm: remember how we started using -Wl,--as-needed, and tinderbox runs tested things? I think we can just do that without getting philosoplical
+14:40 <@WilliamH> gyakovlev: Are we saying they shouldn't?
+14:40 <@gyakovlev> and this discussion is to prevent people from doing that for starters
+14:40 <+mgorny> gyakovlev: packages shouldn't be using USE=lto, really
+14:40 <+mgorny> they should just work™ when you pass -flto
+14:41 <@gyakovlev> mgorny: some build systems want to control that, it's a one-by-one case.
+14:41 <@WilliamH> mgorny: there are some packages that change dependencies when use="LTO"
+14:41 <@ulm> mattst88: sure, if the tinderbox will catch such errors. does it with lto?
+14:41 <+mgorny> gyakovlev: we probably should have some toolchain-func to detect LTO being enabled
+14:41 <@Whissi> But the -O3 stuff Soap__ mentioned is valid... /me still remembers that LTO/-O3 bug with GCC-10 because tree-loop-vectorize is broken, bug 758446
+14:41 <+willikins> Whissi: "www-client/firefox breaks under GCC 10 when using -O3"; Gentoo Linux, Current packages; CONF; esteve.varela:mozilla
+14:42 <@mattst88> ulm: what do you mean? the tinderbox catches build errors, so why wouldn't it?
+14:42 <+Soap__> most LTO errors arent build-time
+14:42 <@gyakovlev> is-flagq not enough? or you mean make a generic wrapper like is_lto_build && do something ?
+14:42 <+Soap__> (and those are easy to fix)
+14:42 <+Soap__> it's the UB LTO bugs that are nasty :/
+14:42 <+mgorny> gyakovlev: yes, generic. i think there's -O level that enables lto in clang
+14:43 <@WilliamH> Whissi: Soap__: Is -O3 now considered a safe flag?
+14:43 <+Soap__> WilliamH: not that I'm aware of
+14:43 <@WilliamH> Soap__: ah ok. I didn't think it was.
+14:43 <@Whissi> I hope not. I mean, I am happy to fix stuff if I can, but I will not actively spend my time on -O3
+14:43 <@slyfox> will you on -flto? :)
+14:43 <+Soap__> to me -O3 and LTO are about equally risky, with LTO being somewhat less
+14:43 <@gyakovlev> he does, at least for FF =) a lot.
+14:44 <@Whissi> If I _can_ sure. ;)
+14:44 <@mattst88> Whissi does maintain a few large packages with IUSE=lto already :)
+14:44 <@WilliamH> So it sounds like lto is basically unsafe.
+14:45 <@WilliamH> Soap__: right?
+14:45 <@slyfox> Everything is unsafe that is not an upstream default.
+14:45 <@Whissi> True.
+14:45 <@gyakovlev> the safest computer is one that does not even exits, or at least never powered on.
+14:45 <@slyfox> Yet the question is not about get the ideal result, but having something that is expected to work most of the time.
+14:46 <@dilfridge> gyakovlev: that is probably also true about the universe
+14:46 <@Whissi> Was an interesting lesson when I once had to switch to a new Intel processor to build firefox and suddenly I was unable to build firefox and thought everything is broken and it just failed because this processor supported AVX512 which had a bug in GCC :p
+14:46 <@mattst88> Motion: Gentoo Developers should not reflexively close bugs involving CFLAGS=-flto ? :)
+14:46 <@mattst88> I think we're getting into the weeds
+14:46 <+mgorny> mattst88: add a sentence that it's fine to resolve them by forcing -fno-lto
+14:47 <@slyfox> I would say -march=native is a lot worse than -O3 WRT being able to hit unique bugs
+14:47 <+mgorny> mattst88: and maybe just to be sure, a note to the users that it's not currently safe to enable it globally
+14:47 <@mattst88> Motion: Gentoo Developers should not reflexively close bugs involving CFLAGS=-flto. Stripping -flto and/or appending -fno-lto is an acceptable solution
+14:48 <+mgorny> mattst88: scratch the 'stripping -flto'
+14:48 <+mgorny> that's not guaranteed to disable LTO
+14:48 <@mattst88> Motion: Gentoo Developers should not reflexively close bugs involving CFLAGS=-flto. Appending -fno-lto is an acceptable solution.
+14:48 <+mgorny> basically, if you know a package is broken with lto, unconditionally append -fno-lto and you should be relatively safe
+14:49 <@WilliamH> I also like the idea of notifying users that lto should not be enabled globally
+14:49 <@dilfridge> that is precisely what I *not* want to do.
+14:49 <@dilfridge> mattst88: looks good
+14:49 <@mattst88> I think we want to work towards being able to build the whole distro with -flto in CFLAGS
+14:50 <@dilfridge> exactly
+14:50 <@slyfox> DId you try? :)
+14:50 <@dilfridge> emphasis on "work towards"
+14:50 <@gyakovlev> slyfox: I did, was fun =)
+14:50 <@dilfridge> I have at least a -flto chroot.
+14:50 <@slyfox> *nod*
+14:51 <@WilliamH> Do we want to vote on mattst88's motion?
+14:51 <@dilfridge> <mattst88> Motion: Gentoo Developers should not reflexively close bugs involving CFLAGS=-flto. Appending -fno-lto is an acceptable solution.
+14:51 <@slyfox> sounds good to me
+14:51 * slyfox yes
+14:51 * mattst88 yes
+14:51 * dilfridge yes
+14:51 * Whissi yes
+14:51 * gyakovlev yes ( as a first step in general LTO effort )
+14:51 * ulm yes
+14:51 * WilliamH yes
+14:52 <+mgorny> dilfridge, mattst88: what i meant is that we don't want to confuse users into thinking that this motion means it's safe to turn it on today
+14:52 <@mattst88> right
+14:52 <@dilfridge> yeah
+14:52 <@dilfridge> though I suppose there will be enough build errors before people even hit runtime errors
+14:53 <@WilliamH> moving on:
+14:53 <@WilliamH> 5. discuss handling of shared infra resources which can incur cost
+14:53 <@gyakovlev> oof
+14:53 <@WilliamH> dilfridge: this is yours also afaik
+14:53 <@dilfridge> yeah
+14:53 <@dilfridge> ok so
+14:54 <@dilfridge> to be honest, after discussions with antarus I'm fairly happy with what came out there
+14:54 <@WilliamH> dilfridge: ok, so dhould we punt then?
+14:54 <@mattst88> me too :)
+14:54 <@WilliamH> should *
+14:54 <@dilfridge> we can, let me just briefly explain
+14:55 <@WilliamH> dilfridge: go for it.
+14:55 <@dilfridge> I got worried that we spend AWS credits way too fast and will have a period at the end of the year where we'll have to improvise
+14:55 <@dilfridge> but then, his valid argument was, the foundation could easily pay for services long enough to migrate away from AWS
+14:56 <@dilfridge> so, no real problem there, and it's true that we should use up all the credits we get
+14:57 <@dilfridge> also, as far as I understand it, he / the foundation is looking for things to fund
+14:57 <@dilfridge> so, as far as I'm concerned this is clarified
+14:57 <@WilliamH> Cool, that sounds good to me.
+14:58 <@WilliamH> moving on:
+14:58 <@Whissi> My concerns would be: Are there better services to spend AWS credits on and move tinderboxing to dedicated systems (cloud isn't cheap for this) but...
+14:58 <@WilliamH> Whissi: I don't think aws credits can be moved to other services.
+14:58 <@dilfridge> yes, but we need to find these better applications first :)
+14:58 <@Whissi> No, better AWS services.
+14:58 <@mattst88> yeah, honestly if we don't get more credits we should probably move to a dedicated system for tinderboxing
+14:59 <@dilfridge> I mean, it's all fine to discuss about this, but let's find the applications first and then...
+14:59 <@WilliamH> dilfridge++
+14:59 <@Whissi> Sure.
+14:59 <@WilliamH> 6. open bugs with council participation
+15:00 <@WilliamH> bug 779451
+15:00 <+willikins> WilliamH: "Request to add Gentoo developer business card to Gentoo Artwork"; Gentoo Foundation, Artwork approval; UNCO; alicef:artwork
+15:00 <@dilfridge> sigh
+15:00 <@dilfridge> no
+15:01 * dilfridge already feels important enough
+15:02 <@Whissi> I wonder why this is council topic. I mean, create whatever artwork you like? Make artwork available for others because you used a free license?
+15:02 <@Whissi> Nobody can ban you from creating such business cards.
+15:03 <+mgorny> i think it falls into whether random people should be permitted to claim they represent Gentoo
+15:03 <@mattst88> I was kind of baffled by jstein's objections to the business card, tbh
+15:03 <@mattst88> mgorny: 'permitted' is a weird word. alicef is a gentoo developer after all, so she kind of does represent gentoo
+15:03 <@mattst88> other people outside of gentoo... we can't really control what they do
+15:03 <@Whissi> I understand his objections after a long talk. But yet I don't see a way to control/prevent this. You are free to use such a stuff.
+15:03 <@WilliamH> Wouldn't this be more a foundation issue though?
+15:03 <@mattst88> unless we want to sue them for having a stylized g on their business card or whatever
+15:04 <@Whissi> If you will use it and make public statements in the name of Gentoo, this is a different topic.
+15:04 <@dilfridge> Whissi: what were his objections?
+15:04 <+Soap__> mattst88: I guess this boils down to corporate identity and such
+15:04 <+Soap__> how protected it is, brand awareness blabla
+15:04 <@Whissi> That non-devs would create such a business card and show them around
+15:04 <@WilliamH> That's more a trustee topic isn't it?
+15:04 <@Whissi> Giving others the impression they are Gentoo devs
+15:04 <@Whissi> if they aren't
+15:04 <@dilfridge> joking aside, I know business cards are a big deal in japan
+15:05 <+mgorny> mattst88: yes, i realize that's a problem but it's not easy to fix
+15:05 <+Soap__> also, the fact that someone still hands out business says more about them than the actual designs on the business card :P
+15:05 <+Soap__> business cards*
+15:05 <@dilfridge> so how about we ask trustees(!) or infra to do this similar as the confirmation of developer status, they keep a template and make one with name if needed
+15:06 <@Whissi> This is silly. Everyone could create one. You cannot protect the design ;)
+15:06 <@mattst88> so, for sake of argument, let's assume this is within our purview: what is there for us to decide? Seems like just stating (to jstein) that yes it's okay for someone to make a business card?
+15:06 <+Soap__> Whissi: IP?
+15:06 <@WilliamH> Whissi: the trustees own the trademark, so they could sue someone for using it outside their guidelines.
+15:06 <@Whissi> Soap__: The Gentoo logo is free to use
+15:06 <+Soap__> you couldnt put the gentoo logo on there?
+15:06 <@Whissi> You cannot restrict, "But don't use for business cards"
+15:07 <+mgorny> Whissi: but you're aware that we have 'Gentoo logo usage guidelines', right?
+15:07 <@mattst88> (
+15:08 <@Whissi> Also, I wouldn't tell you that I am using the Gentoo business card to fake being Gentoo dev. In the end we are talking about people committing a crime. Faking identity. If we will learnt hat someone will do that, we can take action against that single individual. But we cannot prevent that from happening.
+15:08 <+mgorny> that's not faking identity but misrepresenting a trademark
+15:09 <@WilliamH> Whissi:
+15:09 <@WilliamH> The trustees control those.
+15:09 <+mgorny> i would put the question otherwise
+15:09 <+mgorny> let's say someone makes a business card with your company's name and logo on it
+15:10 <+mgorny> would the company mind? for small scale things, they probably wouldn't but they wouldn't allow it officially either
+15:10 <+mgorny> and if stuff got out of hand, i.e. they would actually feel like they're losing customers because of someone misrepresenting their company, they would start caring
+15:11 <+mgorny> (and that's why they wouldn't allow even small scale because then they'd lose the argument)
+15:11 <@Whissi> You can use the Gentoo logo for free. If you use it for commercial use, you would have to request permission. But if some dude will create such card, add his name and go to some events even wearing an official Gentoo shirt bought from our shop, we cannot prevent this. All of this is legal. It will become illegal if he will claim "I am a developer" but this is nothing you can prevent via IP
+15:12 <@WilliamH> It seems like there's nothing we can do here.
+15:13 <@WilliamH> Does anyone disagree?
+15:13 <+mgorny> Whissi: still wrong. please read the usage guidelines
+15:13 <+mgorny> (but that's really outside the point)
+15:15 <@WilliamH> mgorny: do you agree? This bug doesn't seem like a council issue.
+15:15 <@Whissi> YEs. We can continue this outside of this meeting.
+15:15 <@mattst88> how about we just say that we don't have a problem with Gentoo Developers using the gentoo logo on business cards, but it's probably something for trustees?
+15:16 <@WilliamH> mattst88: fwm
+15:16 <@Whissi> Just re-assign bug to trustees?
+15:16 <+mgorny> WilliamH: i'd prefer if council started taking up more duties but sure, logo guidelines say trustees decide
+15:16 <@WilliamH> Whissi++
+15:16 <@slyfox> +1
+15:16 <@mattst88> I don't actually know when trustees make any decisions these days, since they don't have regular meetings
+15:17 <@WilliamH> moving on:
+15:17 <@Whissi> I guess they are still business checking OpenSSL bindist stuff *duck*
+15:17 <@Whissi> *busy
+15:17 <@WilliamH> bug 751010
+15:17 <+willikins> WilliamH: "Missing log and summaries for 20191110, 20191208, 20200412, 2021-03-xx, 2021-04-xx council meetings"; Gentoo Council, unspecified; CONF; ulm:council
+15:17 <+mgorny> right, the thing whissi blocked 4 months ago
+15:18 <@WilliamH> Get your logs and summaries in ;-)
+15:18 <@gyakovlev> as for missing summaries - I literally now SSHed into my old machine with logs. finally got it running and restored data.
+15:18 <@gyakovlev> so will finally upload soon.
+15:18 <@slyfox> \o/
+15:19 <@WilliamH> moving on:
+15:19 <@Whissi> mgorny: Bug 729062 was moved away for now because the upcoming proposal depends on a GSoC project but we don't know yet if it will get accepted.
+15:19 <+willikins> Whissi: "Services and Software which is critical for Gentoo should be developed/run in the Gentoo namespace"; Gentoo Council, unspecified; IN_P; jstein:whissi
+15:20 <@WilliamH> bug 774489
+15:20 <+willikins> WilliamH: "GLEP 67: add proxied-maint="" attribute"; Documentation, GLEP Changes; CONF; mgorny:glep
+15:20 <@WilliamH> mgorny: I have a question about this one. Isn't a non-gentoo maintainer always proxied by a dev?
+15:21 <+mgorny> WilliamH: yes but we have gentoo devs without commit access who are proxied maintainers then
+15:21 <+mgorny> WilliamH: but that is done already, so it can be closed
+15:22 <@WilliamH> ok.
+15:22 <@WilliamH> I'll close it after the meeting.
+15:22 <@WilliamH> moving on;:
+15:22 <@WilliamH> bug 736760
+15:22 <+willikins> WilliamH: "Application to Software Freedom Conservancy"; Gentoo Foundation, Proposals; CONF; mgorny:trustees
+15:23 <+mgorny> nothing new
+15:23 <@dilfridge> we also forgot bug 729062
+15:23 <+willikins> dilfridge: "Services and Software which is critical for Gentoo should be developed/run in the Gentoo namespace"; Gentoo Council, unspecified; IN_P; jstein:whissi
+15:23 <@WilliamH> dilfridge: one sec.
+15:23 <@mattst88> so bug 729062 was assigned to council, but was reassigned like I suggested a while ago :)
+15:23 <+willikins> mattst88: "Services and Software which is critical for Gentoo should be developed/run in the Gentoo namespace"; Gentoo Council, unspecified; IN_P; jstein:whissi
+15:23 <@slyfox> *nod*
+15:23 <@WilliamH> dilfridge: it wasn't on the list.
+15:24 <@Whissi> like said, I moved it away for now. We are waiting for feedback from GSoC project
+15:24 <@WilliamH> moving on:
+15:25 <@WilliamH> 7. open floor
+15:25 * WilliamH listens
+15:27 <@dilfridge> no, the chinese rocket already went down.
+15:27 <@WilliamH> lol
+15:27 * WilliamH bangs the gavel
+15:27 <@slyfox> \o/
+15:27 <@WilliamH> meeting closed
diff --git a/meeting-logs/20210509.txt.asc b/meeting-logs/20210509.txt.asc
new file mode 100644
index 0000000..8eea8ae
--- /dev/null
+++ b/meeting-logs/20210509.txt.asc
@@ -0,0 +1,16 @@