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] zmedico: which portage version first supported the "deep mirror layout" for distfiles? 14:27 <@dilfridge> [21:22:30] dilfridge: first version was portage-2.3.78 and first stable was portage-2.3.79, bug 701106 14:27 <@dilfridge> [21:22:31] 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] ++ 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> 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