micahg | do we have a way to see who binNEWd something? | 03:13 |
---|---|---|
ScottK | No. | 03:13 |
micahg | great, I just got a notice that something that was rejected in Debian by ftpmasters seems to have passed Ubuntu review, do we allow packaging to be licensed under a conflicting license with the upstream source (which might result in trouble is upstream needs patching)? | 03:15 |
micahg | so, we're only tracking rejects then? | 03:17 |
infinity | micahg: We don't track rejects either, except via the email you get. | 05:45 |
infinity | (This is all being worked on actively right now, mind you) | 05:46 |
micahg | ok | 05:46 |
infinity | micahg: Anyhow, if you could be a bit more explicit about "the thing that Debian rejected and we didn't", maybe we could look into it. Positing hypothetical scenarios is less helpful. | 05:46 |
micahg | sorry | 05:46 |
micahg | python-warlock apache 2 (source) + GPL (packaging) | 05:47 |
infinity | That said, if it's just mismatched source/package licensing, that's not a legal problem, just a style issue, as you need to explicitly license your patches, OR get hunted down later when someone wants to submit them upstream. | 05:47 |
infinity | (I agree that it's a valid reason for Debian to reject on the basis of teaching maintainers to not be silly) | 05:47 |
micahg | hrm, so debian/* in d/copyright doesn't really mean that? | 05:48 |
infinity | Erm, also, python-warlock has been in Ubuntu since Quantal...? | 05:48 |
micahg | right, it seems the new python3 package | 05:48 |
infinity | micahg: No, it means what you think it means. | 05:49 |
infinity | micahg: I meant that it doesn't make the package itself a legal issue, it just makes things a hassle if someone wants to forward patches later. | 05:49 |
micahg | oh, patching an apache license package with gpl code is not a problem? | 05:50 |
infinity | micahg: Anyhow, I assume ftpmaster's rejection will lead to a relicensing by the maintainer, and the world will be sunshine and kittens. | 05:50 |
infinity | micahg: Depends. Is the packaging 2, 2+, 3...? | 05:51 |
micahg | 2+ | 05:51 |
infinity | micahg: Yeah, then it's fine. | 05:51 |
micahg | ah, apache 2.0 + GPL 3 is fine, so GPL-3 is implicitly used in that case | 05:53 |
infinity | micahg: Of course, it has the weird side-effect of making the whole package be relicensed as GPL-3. Probably not the desired effect. ;) | 05:53 |
micahg | hrm...sorry for the noise I guesss | 05:53 |
infinity | micahg: It's still a problem, I agree with Debian ftpmasters, but I imagine it'll now get fixed and we'll get the trickle-down, so I'm not too concerned. | 05:54 |
micahg | ok | 05:54 |
infinity | micahg: It's not something we can't legally distribute, so I'm fine with waiting on Debian to fix. | 05:54 |
micahg | I was just wondering if we're missing a check on our side so stuff like this doesn't make its way into the Ubuntu archive | 05:55 |
micahg | (more hypothetical) | 05:55 |
infinity | micahg: As a general rule, binNEW doesn't trigger people to do a full source audit. The Debian ftmaster that did so must have been either (a) a keener, or (b) had a nitpick about something in the binary package he was looking at, and dug deeper. | 05:55 |
infinity | micahg: binNEW for me usually consists of looking at the file lists for sanity, and if there's some funky migration business going on, conflict/replaces and maintainer scripts. I tend to trust that souce new caught the glaring badness in the rest of the source. | 05:56 |
micahg | ok | 05:57 |
infinity | micahg: Though, now that debian/copyright is occasionally machine parseable, Debian might be running a tool that looks for obvious things (like upstream/package license mismatch) and warn on it whenever something's in NEW. Dunno. | 05:58 |
infinity | I wish it was just policy for all debian/* packaging to always be in X11/MIT/Expat or similar. | 05:59 |
micahg | it would make sense | 05:59 |
infinity | Cause I really doubt people check the debian/* licensing before cargo-culting from package A to package B anyway. | 05:59 |
infinity | (And I also really doubt anyone cares about their precious debian/* copyleft) | 05:59 |
micahg | right, TBH, the thought's not crossed my mind | 06:00 |
micahg | it would be a sane thing to check indeed | 06:00 |
darkxst | mozjs update has been sitting in the new queue for two months now | 09:28 |
darkxst | we really want to get this in for saucy since it brings huge performance improvements for ubuntu GNOME/gnome-shell | 09:29 |
infinity | darkxst: Was there a reason for the new source package, instead of revving the current one? | 13:04 |
infinity | darkxst: And are there plans to get mozjs17 into Debian too? | 13:09 |
=== doko_ is now known as doko | ||
infinity | darkxst: Also, it looks like a ton of files have changed their license headers from MPL/GPL/LGPL to just MPL. Is that going to be a problem for GNOME? | 14:24 |
infinity | darkxst: Ahh, MPL2.0 has built-in GPL/LGPL compat. Handy. | 14:25 |
=== Ursinha is now known as Ursinha-afk | ||
darkxst | infinity, it is not backwards compatible with old one. it would be quite a ton of work to port all the rdepends, and atleast couchdb can't work with the new mozjs | 21:48 |
darkxst | infinity, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709434 | 21:53 |
ubot2` | Debian bug 709434 in src:mozjs "mozjs: Please upgrade to last release (mozjs17.0.0)" [Wishlist,Open] | 21:53 |
darkxst | I imagine it will get into debian eventually but right now there doesnt seem to be much interest from them. | 21:54 |
infinity | darkxst: Well, Chris maintains the Debian mozjs, no? Would make sense for him to get this one in too. | 22:03 |
infinity | darkxst: I mostly just don't want to see it done independently in Ubuntu and Debian and have you guys shoot yourselves in the foot with a painful migration later to sync up. | 22:03 |
infinity | darkxst: Other than that, it looks fine, and I'm inclined to let it in. Just trying to look out for overall archive health on that point. | 22:03 |
infinity | chrisccoulson: You have any opinions on the mosjz17 in saucy/NEW, or any inclination to maintain it in Debian? | 22:05 |
jbicha | we've tried pinging Chris before; I didn't get the impression he was at all interested in maintaining mozjs | 22:13 |
jbicha | https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036532.html | 22:15 |
=== Ursinha-afk is now known as Ursinha | ||
jbicha | I think people are just hoping someone else will review it :| | 22:17 |
infinity | jbicha: I'm happy to review it in Ubuntu, I just don't want to see Debian go another route and cause a massice headache while people migrate packaging to match. | 22:25 |
infinity | jbicha: If there's a strong commitment to maintain it in Ubuntu and no current interest in doing so in Debian, I'm sure you could find a sponsor. | 22:25 |
infinity | jbicha: (Maybe Laurent, who filed the bug) | 22:26 |
darkxst | infinity, right now gjs is the only project using it | 22:26 |
darkxst | and probably it will stay like that until its more widely available | 22:27 |
darkxst | well newer polkit supports it as well, but that will still build with old version | 22:34 |
jbicha | I don't think the Debian packaging will diverge significantly and the Ubuntu GNOME maintainers will take care of fixing things if it does | 22:37 |
infinity | Mmkay. | 22:37 |
infinity | Will this need an MIR as well, or is universe fine for now?> | 22:38 |
infinity | darkxst, jbicha ^ | 22:38 |
darkxst | infinity, universe would be fine for now, gjs/gnome-shell are in universe anyway | 22:43 |
infinity | darkxst: Accepted, then. | 22:44 |
infinity | And now I need to go file my own MIR for the new eglibc build-deps. Grr. | 22:44 |
darkxst | infinity, thanks! ;) | 22:45 |
=== Ursinha is now known as Ursinha-afk |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!