path: root/meeting-logs/20210509.txt

14:01 <@WilliamH> Ok let's get started.
14:01 <@dilfridge> \o\  \o/  /i/
14:01 <@WilliamH> agenda: https://archives.gentoo.org/gentoo-project/message/028b5a4dd30d8985b931250eeeadbd8c
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: https://bugs.gentoo.org/784710 "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: https://bugs.gentoo.org/784713 "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> https://bugs.gentoo.org/701106 "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: https://bugs.gentoo.org/701106 "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: https://bugs.gentoo.org/758446 "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: https://bugs.gentoo.org/779451 "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> (https://www.gentoo.org/inside-gentoo/foundation/name-logo-guidelines.html)
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: https://www.gentoo.org/inside-gentoo/foundation/name-logo-guidelines.html
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: https://bugs.gentoo.org/751010 "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: https://bugs.gentoo.org/729062 "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: https://bugs.gentoo.org/774489 "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: https://bugs.gentoo.org/736760 "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: https://bugs.gentoo.org/729062 "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: https://bugs.gentoo.org/729062 "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