[10:20]  * cjwatson accidentally adds images to the tracker with bogus dates, and fixes
[10:21] <cjwatson> (Ubuntu precise alternate/desktop/server, if anyone's keeping track)
[10:57] <seb128> can a python LGPL 3+ source import a LGPL2.1 .py or is that buggy?
[11:02] <xnox> seb128: i think that's fine. one cannot copy it into their source tree and modify lgpl2.1 only and redistribute the whole thing under lgpl3 though ( i think that's the restriction)
[11:03] <xnox> i.e. patches to lgpl2.1 .py should be licensed under lgpl2.1.
[11:03] <seb128> xnox, can they copy it in the source, not modify it, and ship the source as LGPL3 ?
[11:03] <xnox> seb128: yes, if they do not modify it.
[11:04] <xnox> seb128: in debian/copyright, I'd suggest to spell out that file as lgpl2.1
[11:04] <seb128> hum
[11:04] <seb128> they did modify it
[11:05] <seb128> they imported in source to port in to python3, the time upstream would review/include their patch
[11:05] <seb128> so I guess that doesn't work?
[11:05] <xnox> seb128: then those patches to that file only, should be licensed under 2.1 or (dual-license under 2.1 and 3)
[11:06] <xnox> seb128: it's all fine, as long as 2.1 is still granted on those patches. One can link lgpl2.1, lgpl3 and gpl3 code together.
[11:07] <seb128> xnox, how does that work, if you have sources that are lgpl2.1 (only, not "+") and lgpl3 ... what's the license of the binary?
[11:07] <xnox> the combined work will get the combined licensed in that order.
[11:08] <xnox> seb128: just lgpl2.1 by itself -> binary lgpl2.1, lgpl2.1 + 3 -> lgpl3, lgpl2.1 + 3 + gpl3 -> gpl3
[11:09] <xnox> it's only gpl2-only which is incompatible with gpl3, lgpl2.1-only on the other hand is compatible.
[11:10]  * seb128 opens http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility and look at it again
[11:10] <seb128> xnox, thanks ;-)
[11:11] <seb128> xnox, the tab says to transfert the code to GPLv3 in that case?
[11:11] <xnox> seb128: https://www.gnu.org/licenses/quick-guide-gplv3.html
[11:11] <xnox> is better.
[11:12] <xnox> seb128: sure FSF is pushing everyone to v3 =)
[11:14] <xnox> seb128: it would be easier if it was not modified.....
[11:15] <seb128> xnox, right, well I'm reviewing ibus-cangjie in the sponsoring queue
[11:15] <seb128> their source is LGPL3
[11:15] <seb128> and they need python-canberra which is LGPL2.1
[11:15] <seb128> or that one is not available for python3
[11:15] <seb128> so they did copy it in source and ported it to python3
[11:16] <xnox> thus clearly the only way they could have modified it, under lgpl2.1. Did they change the license headers?
[11:17] <seb128> no they didn't
[11:17] <seb128> xnox, but http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility says you can't ship LGPL2.1 code under LGPL3
[11:17] <xnox> seb128: hence they are all golden -  all modifications to lgpl2.1 code are provided back under lgpl2.1
[11:17] <seb128> so the project can't be redistributed this way
[11:17] <seb128> or I read that wrong...
[11:20] <xnox> seb128: sure but we are not releasing the project under LGPLv3, we are releasing it under mixed lgpl2.1 & 3 (e.g. linking only). The 2.1 bits are staying 2.1 bits, and just like before one is allowed to link against lgpl2.1 in lgpl3 one continious to do so.
[11:21] <seb128> xnox, well, both got mixed in one process no? and the COPYING in that source says LGPL3
[11:21] <xnox> seb128: plus a third-party cannot relicense code to a different. Look at that table the lower part "I want to use a library under LGPLv2.1 only" and it's OK across the board.
[11:21] <seb128> xnox, ok with quite some cases where it says "you need to transfert the code to GPLv3"
[11:21] <xnox> it doesn't matter if I use original lgpl2.1 library, or lgpl2.1 library with lgpl2.1 licensed patches library (they are the same).
[11:22] <xnox> seb128: i'd be using the 'i want to use a library under"
[11:23] <xnox> seb128: as they kept the library separate.
[11:23] <xnox> seb128: that one does not have any convey for lgplv2.1
[11:23] <seb128> ah, right
[11:24] <xnox> seb128: take their patches & sponsor into our canberra package, unapply patches from their packages and upload \o/
[11:24] <seb128> I was considering the python import of a copy as a code change
[11:24] <seb128> ;-)
[11:24] <seb128> that's an idea
[11:24] <seb128> or just push the canberra guys to just take that patch and release and updated version
[11:25] <xnox> seb128: python import is mostly equivalent of shared library linking, it's not for example static library or C++ template....
[11:25] <seb128> except that's a modified copy in source
[11:25] <seb128> so it's a bit the equivalent of copying the source of a shared lib, copying it inline, changing it, and linking against it for building your binary
[11:26] <seb128> that's not really "using a library" at this point, it's "using the code of a library for your private benefit"
[11:26] <xnox>  \o/ /o\
[11:26] <seb128> anyway, I will wave hands and sponsor and see what the archive admin of the day think of the situation ;-)
[11:27] <seb128> xnox, thanks for the discussion
[12:30] <ScottK> seb128: re your comments in https://bugs.launchpad.net/ubuntu/+bug/1055435/comments/22 - I think it's fair to say that if the licensing is clear and it's in common licenses, a missing license is not a reason to reject a package, but I also think it's still a bug that should be fixed.  When was the discussion you refer to because I don't see it in my backscroll?
[12:30] <ubot2> Launchpad bug 1055435 in ubuntu "[FFe][needs-packaging] new package classicmenu-indicator" [Wishlist,Fix committed]
[12:31] <seb128> ScottK, on this channel, around 11am UTC between xnox and me
[12:31] <seb128> oh, sorry
[12:31] <seb128> I'm mixing bugs
[12:31] <ScottK> OK.  Would you please comment again in that one.
[12:33] <seb128> ScottK, sure
[12:33] <seb128> ScottK, http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-release.html#t12:29
[12:33] <seb128> was the discussion
[12:33] <seb128> some "recent" might not be that recent :p
[12:34] <ScottK> Right.
[12:34] <ScottK> "Of course, it might still be a good idea to contact upstream and get them to spell out the licensing more clearly in their tarball - I just don't think it's cause for rejection"
[12:34] <ScottK> That aligns with my thinking on the matter.
[12:35] <ScottK>  !rejected != bug free
[12:35] <ubot2> ScottK: I am only a bot, please don't think I'm intelligent :)
[12:35] <ScottK> Sigh.
[12:35] <seb128> ScottK, sorry, what do you want me to add to the bug? I said that it's not a blocker and that they can upload and that it would still be good to have the issue fixed with the next upload
[12:36] <ScottK> seb128: Your last comment says, in part, "the full license doesn't need to be included in the tarball as long as the intend is clear".
[12:36] <seb128> well, I added "even if it would be good to have in a next update"
[12:36] <seb128> but I can change that to a "please get it fixed for the next update"
[12:37] <ScottK> I think that would be clearer.
[12:37] <seb128> ScottK, https://bugs.launchpad.net/ubuntu/+bug/1055435/
[12:37] <ubot2> Launchpad bug 1055435 in ubuntu "[FFe][needs-packaging] new package classicmenu-indicator" [Wishlist,Fix committed]
[12:37] <seb128> comment #23
[12:37] <seb128> works for you?
[12:38] <ScottK> seb128: perfect.  Thanks.
[12:38] <seb128> yw, thanks for pointing it out ;-)
[12:38] <ScottK> no problem.
[13:07] <cjwatson> infinity: Didn't our buildd chroot configuration use to preseed man-db/auto-update to false in the debconf database, to stop man-db bothering to update its database during builds?
[13:07] <cjwatson> infinity: I certainly put that in there for the benefit of buildds
[13:15]  * xnox ponders if mk-sbuild does that as well?!
[13:21] <plars> cjwatson: psivaa just pointed out to me that the precise jobs are failing because report.html is just in pending, not in current
[13:21] <plars> cjwatson: is it intentional that those are not copied over to current?
[13:22] <plars> I thought it was just going to be a link actually
[13:22] <plars> for example: http://cdimage.ubuntu.com/ubuntu-server/precise/daily/
[13:28] <cjwatson> plars: not entirely intentional, but I'm going to have to regenerate those files - it can't be a simple copy/link because the set of architectures involved isn't necessarily the same
[13:29] <cjwatson> plars: however, you could avoid the job failure by switching the jobs over to look at pending rather than current
[13:29] <cjwatson> plars: which AIUI is the intention anyway
[13:29] <plars> cjwatson: yes, indeed
[14:17] <jamespage> Daviey, ^^ those are the correct new versions for openstack updates; I notice other versions of keystone, nova and cinder in the queue from +1 month ago - those can be rejected please.
[14:18] <jamespage> Daviey, there is also a quantum fix that could also do with accepting if possible
[14:41] <infinity> cjwatson: Probably not.  Happy to twiddle that when I refresh the chroots.
[15:34] <bdrung> hi, what do you think about bug #1158845?
[15:34] <ubot2> Launchpad bug 1158845 in Ubuntu "[FFe] Pseudo sync nemo 1.7.2-1 from Debian unstable (in NEW queue)" [Undecided,New] https://launchpad.net/bugs/1158845
[17:18] <cjwatson> Laney: I'm working on haskell-cryptohash/powerpc - making progress, slightly to my surprise
[17:23] <infinity> Oh hey, look at that, someone's logged into my machine.
[17:24] <xnox> oh, is that how colin gets powerpc hw ? =)
[17:24]  * xnox kept on imagining that there is a garage on greenend in cambridge full of machines of all architectures ever made.
[17:25] <Daviey> jamespage: I think it will have to wait until Monday now.  Don't really want to do anything taxing right now :)
[17:25] <cjwatson> fixed sha3; working on skein256
[17:25] <jamespage> Daviey, thats fine
[17:25] <jamespage> (thought that might be the case)
[17:29] <infinity> xnox: Yeah, he's actually using two of my PPC machines right now...
[17:58] <cjwatson> Laney: https://github.com/vincenthz/hs-cryptohash/pull/13 - I'm tempted to go ahead and upload that to Ubuntu; what do you think?
[17:58] <cjwatson> obviously aiming to get it into experimental too once it's accepted upstream, but I'd like to get our transition chart cleaner
[18:06] <olli> ScottK, ping
[18:06] <ScottK> olli: Yes?
[18:07] <olli> ScottK, thostr_ and I wanted to discuss FFe https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1154229 with you
[18:07] <ubot2> Launchpad bug 1154229 in unity-scope-gdrive "[FFE] New Unity Dash" [Undecided,Triaged]
[18:08] <olli> there are imho 3 issues that we'd need your opinion on
[18:08] <ScottK> OK.
[18:08]  * olli looks for his notes ;)
[18:09] <olli> didrock's ppa has now the scopes changes as well as the in dash payments changes merged (now: for days)
[18:09] <olli> in dash payments FFe https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1154176
[18:09] <ubot2> Launchpad bug 1154176 in unity "[FFE] Add payment preview for music" [Undecided,Fix committed]
[18:10] <olli> the ppa is building against the raring trunk automatically
[18:10] <olli> and updating itself
[18:10] <olli> we still show a few regressions in the integration suite compared to 12.10 results
[18:10] <olli> which the team is working on
[18:11] <olli> (#1^)
[18:11] <olli> issue #2: due to these failing integration tests we didn't get the packages to the -validated ppa to get more community testing
[18:12] <olli> we had a few brave ppl look at it, but not what we'd expect from a proper testing done by balloons
[18:13] <olli> issue #3: we are feature complete, but the overall bug situation is not satisfying (see https://bugs.launchpad.net/unity/+bugs?field.tag=100scopes)
[18:14] <olli> traditionally, we'd now argue with you to just get it in
[18:14] <olli> and fix bugs later
[18:15] <olli> but we'd like to break with that tradition in favor of the user experience
[18:15] <olli> ScottK, the big question is what options (if any) do you see
[18:16] <olli> thostr_, did I miss anything?
[18:16] <thostr_> olli: no
[18:16] <ScottK> I've expressed my opinion that we're well past feature freeze and things like this should have been landed already.
[18:16] <ScottK> What you're telling me reinforces that opinion.
[18:17] <olli> and there is nothing I can say against that, unfortunately
[18:17] <ScottK> I'm not sure what you mean by breaking that tradition.
[18:18] <olli> I don't want to pull the sabdfl card and just push it in the state it is at right now
[18:18] <olli> for Monday
[18:18] <olli> which was our targeted landing date
[18:18] <ScottK> Then I'd suggest waiting until you think it's mature.
[18:18] <thostr_> ... which means a couple of more days or bugfixing
[18:18] <olli> I think the preferred solution is to figure out a date that works for you to land it in a mature state
[18:18] <ScottK> If Mark says it goes in, it goes in, so make sure you're ready for that to happen.
[18:18] <olli> I am not worried about the Mark side
[18:19] <olli> just trying to work with you guys to resolve this situation in the best way
[18:20] <ScottK> I think anything after the end of next week would be insane.
[18:20] <ScottK> However, Mark routinely approves stuff I think is just crazy.
[18:20] <ScottK> So I don't know what to tell you.
[18:21] <olli> well, ok
[18:22] <olli> we are hitting the Easter Holidays in Europe next week and I believe didrocks is gone (he is on the critical path for us to land it)
[18:23] <cjwatson> Laney: I've just gone ahead.  I think this is a fairly obvious improvement - we should be able to overwrite it with a Debian package soon enough
[18:24] <olli> ScottK, we might have hit didrocks' EOD already
[18:24] <didrocks> not yet, writing an email to sum up today's status :)
[18:24] <olli> ha
[18:24] <ScottK> olli: I don't know what to tell you.  We have feature freeze for a reason and now you're running all over the kinds of problems that happen when it gets ignored.
[18:24] <didrocks> ScottK: the thing is that we have some kind of raring + extension right now
[18:25] <didrocks> which is the ppa
[18:25] <didrocks> so, this is giving us a better feeling of what we are actually experiencing
[18:25] <didrocks> and we rebase everytime we land an unity or any component that we touched in the distro
[18:25] <ScottK> didrocks: I understand.  The 100 scopes/Unity next thing is already approved by Mark.
[18:25] <didrocks> ScottK: I would really prefer that we land with a better quality state than what we had in the past
[18:25] <ScottK> The new payments stuff is not.
[18:26] <didrocks> meaning "shipping something half working"
[18:26] <olli> ScottK, my last concern was that dumping it in on Thu and then have everybody gone over the long weekend might not be preferable
[18:26] <didrocks> and then "upload everydays to fix things"
[18:26] <didrocks> I would rather prefer delaying a little bit and be more proud of the first shot
[18:26] <didrocks> does this make sense ^
[18:26] <didrocks> ScottK: oh right, I've taken great care that we can revert the in dash payments
[18:26] <didrocks> ScottK: no worry on that one :) just acting as Mark asked, to get it testing
[18:26] <ScottK> Sure.
[18:27] <didrocks> it will be reverted whenever we ship the 100scopes if there is no +1
[18:27] <olli> sorry if I was ambigous on that one
[18:27] <olli> good catch didrocks
[18:27] <didrocks> no worry ;)
[18:27] <didrocks> ScottK: so now I think we want to have your tought
[18:27] <didrocks> is it better to ship it on a hurry
[18:27] <didrocks> just to "meat the deadline" (meaning what was written in the FFe)
[18:27] <ScottK> And I hate to sound like a broken record, but my answer to "when should we land this" is "two weeks ago before feature freeze".
[18:28] <didrocks> knowing that we will have to rush and get things "somewhat ready" later
[18:28] <didrocks> or just delaying
[18:28] <ScottK> I think it'd be better to plan on landing a mature product by feature freeze.
[18:28] <didrocks> ScottK: we all agree on this, we can't deny it :)
[18:28] <didrocks> so delaying by a few days and ensuring that the first shot will make us more proud of the delivery
[18:29] <ScottK> Right.
[18:29] <olli> scottk that's out preference and if that's ok with you then we'd like to go that way
[18:29] <ScottK> olli: Which way?
[18:29] <olli> what didrocks just said: rather delay and have the experience we want
[18:30] <olli> than to dump something now to meet the deadline
[18:30] <infinity> olli: The bottom line is that you shouldn't knowingly ship broken code *and* if it's a new feature not already approved, you'll need to argue an FFe or sabdfl it in.  How the timing for all of that works isn't really up to us, we're not writing the code.
[18:31] <infinity> olli: The deadling, as Scott said, is "two weeks ago", so you've already missed it.  So, if you're going to get something sabdfled in, please make sure it doesn't suck.
[18:31] <infinity> s/deadling/deadline/
[18:31] <didrocks> which will translate in favor of "wait for some additional days and get the first shot in a better shape"
[18:31] <olli> infinity, alright, that's the statement I was hoping to get
[18:31] <didrocks> (not telling awesome, but better)
[18:32] <cjwatson> For things that haven't been sabdfled, "slip to next release" should be on the table.
[18:32] <infinity> Absolutely, yes.
[18:32] <ScottK> cjwatson: Absolutely.
[18:32] <olli> no such things here though
[18:32] <cjwatson> There absolutely is such a thing in Ubuntu.
[18:33] <olli> here:=on my plate
[18:33] <cjwatson> Oh, I see what you mean.
[18:33] <cjwatson> OK.
[18:34] <olli> alright, well, I wanted to reach out and do some better communication than in the past, thx infinity and scottk for your comments and help
[18:34] <ScottK> Thanks.
[18:34] <olli> I guess it's up to us now to deliver
[18:34] <olli> and work on not having that type of conversation in 6mo
[18:34] <ScottK> I think it's up to you to convince Mark if you think you've delivered.
[18:35] <olli> Mark leaves that decision to me
[18:35] <olli> so, I really wanted to make sure I don't screw up more with the release team
[18:35] <ScottK> It takes him saying he's approved it for him to have approved it.
[18:35] <olli> with an emphasis on "more"
[18:36] <olli> ScottK, which is in place for 1154229, isn't it?
[18:37] <ScottK> olli: Yes, but not for Bug #1154176
[18:37] <ubot2> Launchpad bug 1154176 in Unity "[FFE] Add payment preview for music" [Undecided,Fix committed] https://launchpad.net/bugs/1154176
[18:37] <olli> ScottK, true, that's a different story
[18:37] <ScottK> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1154176/comments/13 in particular.
[18:40] <ScottK> So none of the payment stuff has a sabdfl override at the moment.
[18:44] <jtaylor> hi, I have a question concerning scilab
[18:45] <jtaylor> we had it hanging in proposed because it fails to build with a new matio also in proposed
[18:45] <ScottK> Fixing that doesn't need an FFe.
[18:45] <jtaylor> now a few days ago someone uploaded a snapshot which has new features
[18:45] <jtaylor> which ftbs
[18:46] <jtaylor> should we remove the proposed version and instead fix what we have in release?
[18:46] <jtaylor> or now its to late, skip the ffe and fix what is in proposed?
[18:46] <ScottK> Fix what's in proposed unless that's somehow a lot harder.
[18:47] <jtaylor> its probably easier
[18:47] <jtaylor> k, thx just wanted to check
[18:47] <jtaylor> thx
[18:50] <olli> ScottK, ack at 1154176, will see if I can help that team
[18:51]  * olli waves goodbye
[19:33] <sconklin> is there anyone here who can kill some in-progress builds in the kernel PPA for me? I just uploaded a package that supercedes it and I want to free the build resources
[19:33] <cjwatson> possibly.  links?
[19:34] <sconklin> https://launchpad.net/~canonical-kernel-team/+archive/ppa?field.series_filter=lucid
[19:34] <cjwatson> (in general #webops on internal irc is a quicker/better place to ask, but now that you've asked here ...)
[19:34] <sconklin> 2.6.32-46.106
[19:34] <cjwatson> oh, that's a devirt ppa?
[19:34] <sconklin> 107 is uploading now
[19:34] <sconklin> cjohnston: yes
[19:34] <cjwatson> you have to ask webops then - we don't have a webby/api cancel mechanism for devirt ppas
[19:34] <cjohnston> no
[19:35] <cjohnston> ?
[19:35] <sconklin> cjohnston: thanks
[19:35] <sconklin> I meant cjohnston
[19:36] <sconklin> autocomplete fail
[19:36] <cjohnston> 1 + 2 + 3 + tab :-)
[19:37]  * ogra_ guesses sconklin simply didnt read xnox' blog :)
[19:38] <ogra_> (xchat got a cj<tab> fix) .... but you need to set it manually if you used xchat before already
[21:19] <infinity> Huh.  I learned something new today.  Thanks, NEW queue.
[21:20] <ogra_> no armhf ? :(
[21:20] <infinity> (libcangjie1 immediately made me think of Kanji and, lo and behold, Cangjie and Kanji are etymologically related)
[21:20] <infinity> ogra_: I let amd64 through early intentionally so linux-signed can build while I'm waiting on armhf.
[21:20] <ogra_> ah
[21:20] <ogra_> right, takes longer
[21:36] <slangasek> infinity: is that a pinyin spelling?
[21:36] <slangasek> apparently yes
[21:37] <infinity> slangasek: Yeah, pretty much everything I know about Chinese I know from Japanese, so it's fun to see the parallels in anglicisation of matching concepts.
[21:38] <ogra_> btw, do we now all have to learn chinese ?
[21:39] <ogra_> to read code contribution comments and the like ?
[21:39] <infinity> ogra_: You probably should have been doing so for the last decade or so, if you're keen on remaining relavant.
[21:39] <infinity> relevant, too.
[21:39] <slangasek> ogra_: 没有
[21:39] <ogra_> argh
[21:39] <infinity> If you threw in the character for "horse" again by accident, I'm not reading that.
[21:40] <ogra_> ha !
[21:40] <ogra_> now i know how no looks like
[21:40] <ogra_> slangasek, thanks !
[21:40] <slangasek> :)
[21:41] <infinity> I don't even remember the phrase you munged in the meeting now.
[21:41] <infinity> Was it just short a stroke?
[21:41] <infinity> Whatever it was, it turned out rather.  Uhm.  Wrong.
[21:42] <slangasek> yeah, it was short a stroke :)
[21:42] <slangasek> 吗 vs. 马
[21:43] <infinity> Which IME are you using?
[21:43] <infinity> Do we actually have something non-crap now?
[21:43] <slangasek> ibus-pinyin
[21:43] <slangasek> seems to work well enough
[21:43] <slangasek> though kylin want to avoid ibus altogether in favor of fcitx, I don't know why :)
[21:44] <infinity> I haven't looked at all of this for ~5y or so, since I lost any need to write in Japanese, but it was all pretty unfriendly back then compared to Windows, and Windows was bad enough.