13:00 <@WilliamH> Ok folks, let's get started... 13:00 <@WilliamH> the agenda: https://archives.gentoo.org/gentoo-project/message/c822dd1ae331e33bb2cefe4fd83b9741 13:00 * gyakovlev here 13:01 * ulm here 13:01 <@WilliamH> roll call: 13:01 * slyfox here 13:01 * dilfridge here 13:01 * bonsaikitten here 13:01 * WilliamH here 13:01 * Whissi here 13:02 <@WilliamH> next point: licensing ebuilds as gpl2+ 13:02 <@WilliamH> there were 3 questions submitted for votes: 13:02 <@WilliamH> Let's address the first one. 13:03 <@dilfridge> ok so, fundamental question, do we consider the "+" as desirable? 13:03 <@WilliamH> Can developers individually decide to license their ebuilds as gpl2+ if they meet the licensing requirements? 13:03 <@ulm> dilfridge: I do, but I'm still a but sceptical if it will work in practice 13:03 <@dilfridge> (in our context) 13:04 <@bonsaikitten> imo not desirable: I don't understand gpl3, I can't predict what gpl4 will be, so I don't like agreeing to terms I don't understand 13:04 <@ulm> OTOH, the decision would be easy to revert, going from GPL-2+ to GPL-2 is trivial 13:04 <@gyakovlev> dilfridge: I think it's not, I personally dislike + clause in any license 13:04 <@dilfridge> not once someone has committed gpl3+ 13:04 <@slyfox> https://gentoo.org/get-started/philosophy/social-contract.html says "We will release our contributions to Gentoo as free software, metadata or documentation, under the GNU General Public License version 2 (or later, at our discretion) or the Creative Commons - Attribution / Share Alike version 2 (or later, at our discretion)." 13:04 <@ulm> dilfridge: we won't allow GPL-3+ 13:05 <@dilfridge> ulm: that allows for a big mess 13:05 <@dilfridge> becaus, 13:05 <@dilfridge> imagine someone starts up an overlay, and uses tree ebuilds as basis, but bumps all to gpl3+ 13:05 <@dilfridge> then we can't merge back anymore 13:05 <@bonsaikitten> dilfridge: is that a valid action? 13:06 <@bonsaikitten> ... so much confusion, I'd prefer just not doing that 13:06 <@gyakovlev> ^ 13:06 <@ulm> dilfridge: same as if someone would add an overlay with all ebuilds written from scratch and licensed under CDDL 13:06 <@ulm> so not really anything new 13:07 <@dilfridge> bonsaikitten: if I edit something, I have copyright on my contributions, and if I decide gpl3+ on my contributions, the combination of the previous part and my contributions will also be gpl3+ 13:07 <@dilfridge> "written from scratch" is the difference 13:07 <@WilliamH> ulm: hrm I don't know about the cddl example because ebuilds are source. 13:07 <@bonsaikitten> dilfridge: but the existing bits aren't, so it's not, and I'm getting a headache 13:08 <@ulm> linux seems to get along well with their mixed license model 13:09 <@ulm> but yeah, chances that we would get the whole tree relicensed to + are slim 13:09 <@ulm> and it's not clear with what our ebuilds need to be license-compatible 13:09 <@WilliamH> dilfridge: But, your example of an ebuild coming from an overlay that is gpl3+ is a possible concern. 13:10 <@WilliamH> ulm: is linux mixed license? I thought it was gpl2 only 13:10 <@gyakovlev> some parts are dual-licensed, like most of DRM (graphical) stack is GPL-2/MIT 13:10 <@WilliamH> I always heard Linus doesn't like gpl3 13:10 <@slyfox> it has a lot of dual GPL/BSD code and other flavours 13:10 <@ulm> there are files under GPL-2+ 13:11 <@slyfox> you can frep for SPDX tags 13:11 <@WilliamH> Oh ok, I didn't know about the dual licensing. 13:12 <@ulm> see LICENSES/other/ in the kernel tree 13:12 <@gyakovlev> but do we really want more licensing variations? what's the benefit here? 13:13 <@gyakovlev> I'm not sarcastic, can someone explain in simple terms? 13:13 <@WilliamH> gyakovlev: I'm not sure of the benefit either, but I don't really have a strong opinion either way. 13:13 <@WilliamH> This all started because we have an eclass that is gpl 2+ 13:14 <@ulm> the only benefit I can see is improved compatibility between GPL-3 and CC-BY-SA-4.0 13:14 <@ulm> but it's one-way only 13:15 <@ulm> so you cannot take GPL licensed examples and include them e.g. in the devmanual 13:15 <@WilliamH> Are we ready to vote? 13:15 <@ulm> I am 13:15 <@WilliamH> ok I'll hang out a minute I didn't see your msg ulm until after I asked. 13:15 <@WilliamH> ok. 13:16 <@WilliamH> Let's vote. can developers license their ebuilds under gpl2+? 13:16 * slyfox yes 13:17 <@Whissi> WAIT. You dropped 'individually', not? 13:17 <@WilliamH> Whissi: same thing, the word individually is sort of redundant 13:17 <@ulm> we should vote on the exact wording of a. 13:17 <@WilliamH> ok 13:17 <@WilliamH> one sec. 13:17 <@ulm> "provided that they fulfill relicensing requirements" is also important 13:18 <@WilliamH> a. Can developers individually decide to license their ebuilds as GPL-2+ 13:18 <@WilliamH> rather than 'GPL-2 only' (provided that they fulfill relicensing 13:18 <@WilliamH> requirements)? 13:18 <@WilliamH> vote: 13:18 * slyfox yes 13:19 * dilfridge no 13:19 * gyakovlev no 13:19 * bonsaikitten no 13:19 * Whissi no 13:19 * ulm yes 13:19 * WilliamH abstain 13:19 <@WilliamH> the motion doesn't carry. 13:20 <@WilliamH> The next question: 13:20 <@ulm> hm, what do we do about that one existing eclass that is under GPL-2+ 13:20 <@ulm> ? 13:20 <@ulm> can it stay unchanged? 13:20 <@gyakovlev> contact author and ask for re-license? 13:21 <@WilliamH> agreed 13:21 <@WilliamH> gyakovlev++ 13:21 <@slyfox> which ebuild is that by the way? does it have many users? 13:21 <@ulm> ant-tasks.eclass 13:21 <@slyfox> s/ebuild/eclass/ 13:21 <@gyakovlev> it should be easy to go back like ulm said. 13:21 <@WilliamH> Do we need to vote on the other two points or are they by default no? 13:21 <@WilliamH> I'll post the first one: 13:22 <@WilliamH> b. Should developers be encouraged to use GPL-2+ for new ebuilds 13:22 <@WilliamH> (whenever possible)? 13:22 <@dilfridge> well that's kind of an obvious no now 13:22 <@WilliamH> vote: 13:22 <@WilliamH> yes. 13:22 <@WilliamH> I agree. 13:22 <@ulm> we could only produce a contratiction if we would on it 13:22 <@WilliamH> the next one is as well: 13:22 <@ulm> *contradiction 13:22 <@WilliamH> I'll post it here for the record: 13:23 <@WilliamH> c. Should we start collecting permissions from contributors to relicense 13:23 <@WilliamH> their GPL-2 work as GPL-2+? This will be helpful both to 1. and 2. 13:23 <@WilliamH> another no. 13:23 <@slyfox> *nod* 13:24 <@WilliamH> moving on. 13:24 <@WilliamH> open bugs with council participation. 13:24 <@WilliamH> bug 662982 13:24 <+willikins> WilliamH: https://bugs.gentoo.org/662982 "[TRACKER] New default locations for the Gentoo repository, distfiles, and binary packages"; Gentoo Linux, Current packages; CONF; zmedico:dev-portage 13:24 <@WilliamH> Are the snapshots fixed? 13:25 <@gyakovlev> they are, but last time there was something left to be done for delta users. 13:25 <@ulm> that would be bug 574752 13:25 <+willikins> ulm: https://bugs.gentoo.org/574752 "Rename portage-YYYYMMDD.tar* snapshots with gentoo-YYYYMMDD.tar*"; Gentoo Infrastructure, Other; IN_P; mgorny:infra-bugs 13:26 <@ulm> wait, the name of the top-level dir includes the date now? 13:26 <@Whissi> No. 13:27 <@Whissi> toplevel was changed from portage to gentoo 13:27 <@gyakovlev> yes, it hinders delta computation 13:27 <@ulm> Whissi: https://bugs.gentoo.org/574752#c4 ? 13:27 <@gyakovlev> date was added 13:27 < veremitz> date is indeed addeed/included 13:27 <@ulm> which breaks delta 13:27 < veremitz> iirc robbat2 was doing testing with deltas? 13:28 < veremitz> new algo? 13:28 <@ulm> why must the tld name include the date? 13:28 < veremitz> ¯\_(ツ)_/¯ 13:28 <@ulm> seems it has worked before without it? 13:28 <@Whissi> Sorry, I don't see timestamp in tarball 13:28 <@Whissi> https://mirror.netcologne.de/gentoo/snapshots/portage-20191224.tar.bz2 13:29 < veremitz> Whissi: top level folder 13:29 <@gyakovlev> robbat2 mentioned that xz compression on deltas makes them almost like the old ones, but I don't remember clearly. 13:29 <@Whissi> There's just one single portage folder 13:29 <@Whissi> of course I picked the old portage one 13:29 <@Whissi> :[ 13:29 < veremitz> gentoo-YYYYMMDD iirc :p 13:29 < veremitz> not even THHMMSSZ :P 13:29 <@gyakovlev> Whissi: gentoo-20191224/metadata/md5-cache/dev-db/postgis-9999 13:30 <@gyakovlev> looking into new one 13:30 <@Whissi> yeah, gentoo-latest.tar.xz has it :/ 13:30 <@slyfox> i suggest leaving it to the bug owners to sort the details out 13:30 <@WilliamH> So the question still holds, why does it need the date in the name of the folder? 13:30 <@WilliamH> But yeah we aren't going to fix it here. 13:31 <@dilfridge> who came up with it? 13:31 <@ulm> mgorny, it seems 13:31 <@ulm> rationale, "to match tarball name" 13:32 <@dilfridge> awesoem 13:32 <@WilliamH> not a good rationale 13:32 <@Whissi> Well, the version I tested in January worked and didn't have that changes. 13:32 <@Whissi> So nice that this was changed "lately" 13:32 <@WilliamH> mgorny: ^^ 13:32 <@WilliamH> please fix the folder to just be gentoo 13:32 <+mgorny> WilliamH: so a better solution is when tarballs extract to random unpredictable directories and when you want to compare two snapshots, they just happen to overwrite one another? 13:33 < veremitz> mgorny: wasn't a problem with portage-YYYYMMDD ? 13:33 <@Whissi> mgorny: No, user is supposed to use -x. 13:33 < veremitz> or was it? 13:33 <@WilliamH> If you really want to compare move the old snapshot to anothe name 13:33 <@WilliamH> another :p 13:33 <@Whissi> If you extract tarball you should notice that. We don't need to hold hands all the time. 13:33 <+mgorny> WilliamH: yes, because gentoo is special and users should use custom hacks to workaround it 13:34 <@dilfridge> you break it you fix it :P 13:34 <@Whissi> It's same like stage tarballs. From the beginning we are using -C ... are you going to propose adding a top folder in case someone wants to extract somewhere and compare...? 13:35 < veremitz> fwiw .. the tar --transform option is really useful ;) 13:35 <@slyfox> i suggest to move on 13:36 <+mgorny> Whissi: so it all boils down to 'someone was stupid back in the day so we must not ever fix it' 13:36 <+mgorny> we have new tarballs, it's an opportunity to fix it 13:36 < veremitz> also https://gitweb.gentoo.org/infra/mastermirror-scripts.git/tree/snapshots-create.sh#n317 WRT deltas. 13:36 <+mgorny> if you want the old way, you have to come with a better argument than 'oh no, it broke my workflow' 13:37 <@dilfridge> well, it *did* break something 13:37 <+mgorny> or the more precise gentoo argument 'my eyes don't like it, so it must be changed to fit my preferences' 13:37 <@WilliamH> mgorny: the same thing could be said about your argument. 13:37 <@Whissi> mgorny: But if you introduce such a 'late fix' which is causing 'regressions'... we can't fix world in one step. So let's do the new tarball first if we don't come up will a solution which addresses everything and find a solution for that problem later. 13:37 <@ulm> can we move on please? I think we don't want to micro-manage things at that level 13:38 <@Whissi> *with 13:38 <@slyfox> +1 13:38 <+mgorny> Whissi: so you're asking to revert stuff, break portage AGAIN... 13:38 < veremitz> and emaint sync! 13:38 <@Whissi> mgorny: Let's talk about this later. We will have 4 more weeks until this will come up again ;) 13:38 <@WilliamH> ok 13:38 <@WilliamH> moving on. 13:39 <@WilliamH> bug 700364 13:39 <+willikins> WilliamH: https://bugs.gentoo.org/700364 "License council summaries under CC-BY-SA-4.0"; Gentoo Council, unspecified; IN_P; ulm:council 13:40 <@ulm> proposed README file is here: https://700364.bugs.gentoo.org/attachment.cgi?id=613112 13:40 <@ulm> also sent to council@g.o on 2020-01-20 (same text, except for two typo fixes) 13:40 <@ulm> do you want to vote on it, or can I simply commit it? 13:40 <@dilfridge> do it 13:41 <@WilliamH> go for it. 13:41 <@Whissi> +1 for the fixed README :) 13:41 <@slyfox> no need to vote 13:41 <@ulm> ok :) 13:41 <@gyakovlev> vote yes by no voting =) 13:41 <@WilliamH> moving on.... 13:41 <@ulm> apart from that, should I reassign the bug to myself? 13:41 <@WilliamH> heh 13:41 <@ulm> still waiting for 4 approvals, which can tak a long time 13:42 <@ulm> *take 13:42 * WilliamH is indifferent about that 13:43 <@WilliamH> If it is assigned to council it will come up in the meetings... 13:43 <@ulm> exactly, I can leave it alone for now, but then it will show up again 13:44 <@Whissi> ulm: You also sent private mails, didn't you? Any bounces or can we expect that former council member at least received the mail? 13:44 <@WilliamH> What does everyone else think? 13:44 <@ulm> Whissi: no bounces, but no answer either 13:44 <@Whissi> OK :/ 13:44 <@dilfridge> did vapier reply? 13:44 <@ulm> I've sent private e-mail twice 13:45 <@ulm> dilfridge: https://bugs.gentoo.org/700364#c35 :) 13:45 <@dilfridge> oh wow, that's like a flying pink elephant 13:46 <@WilliamH> He replied so I guess he is ok with it. 13:47 <@ulm> well, I suggest to leave the bug alone, and reassign next month if it's still open then 13:47 <@WilliamH> ok fwm 13:47 <@Whissi> Mh. Wasn't the CC list used as indiciator who still needs to ack? Only calchan left... who are the 4 missing? 13:47 <@slyfox> sounds good. worth adding explicit comment to the bug? 13:47 <@WilliamH> slyfox++ 13:48 <@ulm> Whissi: calchan, dberkholz, scarabeus, tanderson/gentoofan23 13:48 <@ulm> slyfox: will do, when I reassign 13:49 <@slyfox> thank you! 13:49 <@WilliamH> ok, moving on... 13:49 <@WilliamH> open floor 13:49 * WilliamH listens 13:49 * veremitz falls over some saucepans. 13:50 < veremitz> oops, sorry. 13:51 * WilliamH bangs the gavel 13:51 <@WilliamH> meeting closed