[03:13] <micahg> do we have a way to see who binNEWd something?
[03:13] <ScottK> No.
[03:15] <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:17] <micahg> so, we're only tracking rejects then?
[05:45] <infinity> micahg: We don't track rejects either, except via the email you get.
[05:46] <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:47] <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:48] <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:49] <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:50] <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:51] <infinity> micahg: Depends.  Is the packaging 2, 2+, 3...?
[05:51] <micahg> 2+
[05:51] <infinity> micahg: Yeah, then it's fine.
[05:53] <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:54] <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:55] <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:56] <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:57] <micahg> ok
[05:58] <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:59] <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)
[06:00] <micahg> right, TBH, the thought's not crossed my mind
[06:00] <micahg> it would be a sane thing to check indeed
[09:28] <darkxst> mozjs update has been sitting in the new queue for two months now
[09:29] <darkxst> we really want to get this in for saucy since it brings huge performance improvements for ubuntu GNOME/gnome-shell
[13:04] <infinity> darkxst: Was there a reason for the new source package, instead of revving the current one?
[13:09] <infinity> darkxst: And are there plans to get mozjs17 into Debian too?
=== doko_ is now known as doko
[14:24] <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:25] <infinity> darkxst: Ahh, MPL2.0 has built-in GPL/LGPL compat.  Handy.
=== Ursinha is now known as Ursinha-afk
[21:48] <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:53] <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:54] <darkxst> I imagine it will get into debian eventually but right now there doesnt seem to be much interest from them.
[22:03] <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:05] <infinity> chrisccoulson: You have any opinions on the mosjz17 in saucy/NEW, or any inclination to maintain it in Debian?
[22:13] <jbicha> we've tried pinging Chris before; I didn't get the impression he was at all interested in maintaining mozjs
[22:15] <jbicha> https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036532.html
=== Ursinha-afk is now known as Ursinha
[22:17] <jbicha> I think people are just hoping someone else will review it :|
[22:25] <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:26] <infinity> jbicha: (Maybe Laurent, who filed the bug)
[22:26] <darkxst> infinity, right now gjs is the only project using it
[22:27] <darkxst> and probably it will stay like that until its more widely available
[22:34] <darkxst> well newer polkit supports it as well, but that will still build with old version
[22:37] <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:38] <infinity> Will this need an MIR as well, or is universe fine for now?>
[22:38] <infinity> darkxst, jbicha ^
[22:43] <darkxst> infinity, universe would be fine for now, gjs/gnome-shell are in universe anyway
[22:44] <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:45] <darkxst> infinity, thanks! ;)
=== Ursinha is now known as Ursinha-afk