[00:03] <GrueMaster> Sorry, got pulled away just after I typed that.
[00:03] <GrueMaster> I'm not seeing anything in my notes.  THought I had.
[00:44] <jono> hey all
[00:44] <jono> which package should I file a gtk bug against?
[00:45] <micahg> jono: which version of GTK?
[00:45] <jono> ahh gir1.2-gtk-3.0
[00:45] <jono> GTK3
[00:45] <jono> thanks micahg
[01:13] <silvio> hi. i have been running some automated scans checking that embedded libraries are being licensed correctly. which channel should i join to ask some license related questions for packages? (specifically, i have some questions about libjpeg8)
[01:15] <micahg> silvio: if it's about in archive stuff, you can ask here
[01:17] <silvio> ok. if package X depends on Y,Z and is just a dummy package to pull in those extra packages.. and Y,Z are BSD'ish licenses.. what license should X be?
[01:17] <micahg> anything compatible...
[01:18] <silvio> ok.. so libjpeg8 is licensed under GPL, but it's a dummy package to pull in permissively licensed jpeg code... and  libjpeg8 has packages dependant on it which are non GPL compatable
[01:18] <silvio> err. libjpeg8 is LGPL
[01:22] <silvio> i am wondering ig libjpeg8 is licensed incorrectly.
[01:23] <micahg> we're not using libjpeg8, but libjpeg-turbo
[01:23] <silvio> libjpeg8 is a dummy package that pulls in libjpeg-turbo
[01:23] <silvio> as far as i can tell
[01:23] <micahg> yes
[01:23] <JontheEchidna> right, and the dummy package is not the original work
[01:24] <JontheEchidna> since it is empty
[01:24] <silvio> how should dummy packages be licensed?
[01:24] <JontheEchidna> the packaging itself is licensed, using the license specified in debian/copyright of the source package
[01:25] <slangasek> though honestly, if there's anything in the libjpeg8-empty source package that one can legitimately assert copyright over, I think they're doing it wrong. ;)
[01:25] <JontheEchidna> right, and no derivative work would actually be linking against anything in there
[01:26] <silvio> ok, that makes sense. i wasn't sure if that was the case or not. so not an issue. i have been running a scan checking embedded-code-copies.txt and making sure embedded libraries that are GPL are embedded in GPL compatable packages.
[01:26] <silvio> i don't think i've seen anything else that presented as an issue so far.
[01:27] <silvio> ok. thanks guys. cya
[05:52] <robert_ancell_> @pilot out
[05:53] <robert_ancell_> @pilot off
[05:53] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[05:53] <robert_ancell_> @pilot out
[05:54] <robert_ancell> @pilot out
[07:07] <dholbach> good morning
[07:11] <didrocks> hey dholbach
[07:12] <dholbach> hey didrocks
[07:24] <xnox> Guten Morgen ;-) =)
[07:41] <ogra_> Riddell, if you want kubuntu on nvidia tegra arm to run, adding this patch to kwin would be good https://git.reviewboard.kde.org/users/griffais
[07:41] <ogra_> s/this patch/these patches/
[08:15] <Riddell> ogra_: those patches have been in kwin for 9 months now
[08:16] <ogra_> Riddell, oh, ok, i didnt know someone just dropped tzhem on my lap right now :)
[08:47] <tjaalton> infinity: I see that -omapfb is basically abandoned, and that -omap replaces it (uploaded a new upstream release to quantal-proposed). agreed?
[08:49] <seb128> ev, hey
[08:49] <seb128> ev, when do you think we will get the "month" view of e.u.c working again?
[08:56] <ev> seb128: it was working fine again up until yesterday's deployment. It seems the Launchpad integration is causing some timeouts. I'm in the process of looking into it.
[08:56] <seb128> ev, ok, thanks, it doesn't work here (or I got unlucky)
[09:11] <dholbach> @pilot in
[09:11]  * seb128 hugs dholbach
[09:12]  * dholbach hugs seb128 back :)
[09:12] <seb128> ;-)
[09:14] <dholbach> can somebody please reject https://code.launchpad.net/~cldunlap1/ubuntu/quantal/ciderwebmail/typo-fix/+merge/119413 (typo fix already forwarded to Debian)
[10:10] <dholbach> slomo, hey - how are you doing?
[10:10] <dholbach> any idea what could be done with https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad0.10/+bug/973014?
[11:10] <melodie_> hi
[11:11] <melodie_> I have a general question about develpment, but non-tech : where should I ask, please ?
[11:11] <melodie_> s/develpment/development/
[11:12] <dholbach> micahg, bdrung, regarding the ubuntu-branches timeout: it seems if we use the anonymous login we can get a list of open merge proposals from LP - I know it's a dirty workaround, but we could use a second LP login to get the list for now
[11:12] <dholbach> if I have a bit of time later on, I'll look into it - otherwise feel free to go ahead with this :)
[11:59] <dholbach> http://reqorts.qa.ubuntu.com/reports/sponsoring/ has merge proposals again! go wild!
[13:30] <shadeslayer> ev: ping
[13:35] <shadeslayer> ev: I'm trying to merge live-build from debian, and there's a ubuntu specific patch that adds a framebuffer to initramfs, is that patch still valid for quantal?
[13:35] <shadeslayer> i.e. are wubi installs still supported?
[13:36] <cjwatson> If you're merging live-build, keep all our custom patches.
[13:36] <ev> shadeslayer: yes
[13:36] <ev> yes they are
[13:36] <shadeslayer> cjwatson: some of them have been applied upstream
[13:36] <cjwatson> It's not worth dropping things in a merge only to discover that we needed them.
[13:36] <cjwatson> Well, that's not dropping them then, is it :-)
[13:36] <shadeslayer> ofcourse :P
[13:36] <shadeslayer> cjwatson: btw, could you look into ubuntu-armhf-support.patch and ubuntu-kernel-img-conf.patch
[13:36] <cjwatson> Not today or tomorrow.
[13:37] <shadeslayer> for armhf, live build upstream does a special case ... but it's different from armel
[13:37] <shadeslayer> oh ok
[13:37] <shadeslayer> I'll disable it for now, since I'm not aiming at armhf
[13:37] <cjwatson> Then your merge needs to not go to the Ubuntu archive.
[13:37] <shadeslayer> ofcourse
[13:37] <cjwatson> We have to keep armhf working.
[13:37] <shadeslayer> I don't have upload rights anyway :P
[13:38] <shadeslayer> plus, I wasn't planning on uploading to archive anyway
[13:38] <cjwatson> Right, but you might have been planning to propose it for review.
[13:38] <shadeslayer> nope
[13:38] <shadeslayer> I wanted to consult you before even uploading for review
[13:39] <shadeslayer> cjwatson: could you let me know when we can discuss this?
[13:39]  * shadeslayer can plan accordingly
[13:39] <cjwatson> Personally I'm afraid I find reviewing merges much harder than just doing them.
[13:39] <shadeslayer> haha :D
[13:39] <cjwatson> Because I generally have to basically do the merge in order to review it effectively.
[13:39] <shadeslayer> I understand :)
[13:40] <cjwatson> So I'd certainly be happy (well, more or less) to do the merge later this week - but I only have a couple of hours left today, and a funeral to attend tomorrow
[13:40] <shadeslayer> cjwatson: I'll probably upload this to my ppa for now, and I'll give you the link :)
[13:46] <seb128> tseliot, hey, what's the status of bug #1026518
[13:46] <seb128> ?
[13:47] <tseliot> seb128: that's a good question. The package still seems to live in precise-proposed
[13:49] <seb128> tseliot, right, that's why I'm asking, can you verify it? it needs to be verified so it can go to updates or rejected at this point (.1 getting close)
[13:49] <tseliot> seb128: sure
[13:49] <seb128> tseliot, thanks
[13:56] <melodie_> bye
[14:03] <dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/quantal/openvswitch/debian-merge/+merge/118037 (based on the comment in the MP)
[14:05] <stgraber> dholbach: done
[14:13] <dholbach> @pilot out
[14:13] <dholbach> thanks stgraber
[14:13] <dholbach> stgraber, can you please reject https://code.launchpad.net/~cldunlap1/ubuntu/quantal/ciderwebmail/typo-fix/+merge/119413 (typo fix already forwarded to Debian) too?
[14:19] <mdeslaur> ev: so, on my tablet, I have two cameras, a forward facing one, and a rear one...ubiquity selects the rear one by default...is there a bug open for that?
[14:20] <ev> mdeslaur: not that I'm aware of, though I haven't kept track of the ubiquity bugs this cycle at all, what with the errors.ubuntu.com work
[14:20] <mdeslaur> ev: ok, cool...wanted to see if you knew of one before opening a new one, thanks
[14:20] <ev> sure thing
[14:20] <ev> thanks for filing
[14:25] <stgraber> dholbach: done
[14:25] <dholbach> thanks stgraber
[15:12] <micahg> dholbach: I think we specifically want an unprivileged account for the sponsorship queue, anonymous sounds better :)
[15:12] <dholbach> micahg, we can't - to get information about who can upload what we need to be logged in
[15:13] <dholbach> but if that wasn't the case, I'd totally agree
[15:15] <micahg> dholbach: well, it still needs to be an unprivileged authenticated user then
[15:15] <dholbach> yes, we need authentication for that bit at least
[16:22] <micahg> tjaalton: /me is puzzled by an upload for a -dbg package, don't we have dbgsym packages automatically?
[16:23] <infinity> micahg: We don't intentionally strip them out when the Debian packaging includes -dbg packages, it's a pointless delta.
[16:25] <micahg> infinity: yes, but I thought we don't specifically add those to in archive packages since we have the ddebs
[16:33] <infinity> micahg: I'm likely missing the upload where that happened.  But I would, generally, assume it was the result of a merge or other convergence with Debian...?
[16:36] <micahg> infinity: https://launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/1.6.2-1ubuntu4
[16:39] <infinity> micahg: Ahh, indeed.  Well, the Debian package will have a -dbg "soon", if 652992 is to be believed, so maybe it's pre-emptive convergence? ;)
[16:50] <xnox> M-A: same; must be co-installable, must not install /usr/lib/libda.so, but should install /usr/lib/$(DEB_HOST_MULTIARCH)/libda.so
[16:51] <xnox> in the -dev package that is for example
[16:51] <xnox> ?
[16:51] <xnox> or did I get it wrong...?
[16:53] <infinity> xnox: I've never multiarched a -dev package but, yes, that seems like a reasonable interpretation of how one would do it.
[16:53] <xnox> infinity: ok. reality check with infinity passed, I am on the right track then.
[16:58] <xnox> infinity: i am merging lvm2 which is now multiarched. what possibly can go wrong? =)
[16:59]  * stgraber makes a note not to update his quantal systems for another week or so ;)
[17:00]  * xnox pinned all filesystem packages long time ago on all of my hosts/servers/friends etc.
[17:01] <infinity> xnox: That's a serious vote of confidence in your own work...
[17:01] <xnox> i did upload e2fsprogs today... upstream broke linking the whole package in a micro-point release =) was marvellous 20 minutes of fun
[17:01] <xnox> I wish it used automake....
[17:02] <xnox> infinity: oh It's pinned to quantal-proposed on all precise&quantal machines ;-)
[17:12] <hyperair> hmm, how do i get apt-get dist-upgrade to follow an upgrade path that involves (on an amd64 machine) replacing foo (which depends on libc-i386) with foo:i386?
[17:12] <hyperair> i've got a package bar which is arch:all that depends upon foo, but apt-get just marks that package under kept back, even with dist-upgrade
[17:13] <hyperair> and foo is marked multi-arch: foreign
[17:29] <green7> I've to download libreoffice source code to work on a bug. Is there any other method instead of bzr? bzr is horrendously slow.
[17:30] <stokachu> jamespage: hi, do you have the ability to sponsor userspace?
[17:30] <stokachu> i can't remember if you were the one that only did kernel
[17:30] <ScottK> green7: apt-get source $packagename
[17:31] <jamespage> stokachu, not me I'm afraid
[17:31] <green7> ScottK: There'll be no problems while submitting the patch, right?
[17:31] <stokachu> jamespage: sorry :) was that a not me to userspace?
[17:32] <jamespage> stokachu, I don't do kernel - what do you want sponsored?
[17:33] <stokachu> jamespage: https://code.launchpad.net/~louis-bouchard/ubuntu/precise/kexec-tools/lp988512-no-vmcoreinfo/+merge/112086
[17:33] <stokachu> this merge proposal has been approved just needs to make it into proposed
[17:33] <stokachu> its the userspace portion of kdump
[17:34] <jamespage> stokachu, TBH thats a little outside my comfort zone; I'd prefer someone more knowledgeable review/sponsor
[17:35] <stokachu> jamespage: any recommendations?
[17:35] <xnox> green7: regular patches are excepted just fine. create a bug + attach a patch + subscribe ~ubuntu-sponsors team.
[17:36] <stokachu> ooo xnox :D
[17:36] <xnox> stokachu: Hola! =)
[17:36] <stokachu> hey there!
[17:36] <xnox> stokachu: it sounds like you want me to do something for you right?
[17:36] <stokachu> lol you know me so well
[17:36] <stokachu> xnox: https://code.launchpad.net/~louis-bouchard/ubuntu/precise/kexec-tools/lp988512-no-vmcoreinfo/+merge/112086 <-- is this something you dont mind reviewing?
[17:37] <infinity> stokachu: The changelod mess doesn't give me a bunch of confidence that the rest of the patch is complete. :P
[17:38] <infinity> Nor the changelog.
[17:38] <infinity> Dear irony, go away.
[17:38] <stokachu> yea he's pretty new at this, though oddly the revisions are clean its just that preview diff for some reason
[17:39] <xnox> stokachu: revisions are clean ... against precise, not quantal changelog
[17:39] <stokachu> ahh.. well there's the problem
[17:39] <infinity> (This is, actually, one of the reasons why I prefer diffs to MPs)
[17:40] <stokachu> ok so ill have him redo the diff against quantal
[17:40] <stokachu> then backport to precise
[17:40] <infinity> stokachu: Nah, I can sponsor to both and tidy up the changelog myself.  Just rap him on the nose with a newspaper.
[17:40] <xnox> stokachu: it's fine, manually fix up the version string.
[17:40] <stokachu> awesome thanks guys, ill make sure to have a writeup for the rest of the team
[17:41] <xnox> stokachu: it's not his fault that from the time he proposed the merge and by the time we review it (i) precise got released (ii) a merge happened in quantal.
[17:41] <stokachu> some "guidelines" in order to not lose limbs
[17:41] <stokachu> xnox: ah gotcha
[17:42] <xnox> stokachu: it looks fine, but i don't know what vmcoreinfo is/was
[17:42] <stokachu> xnox: i think it was previously used by kdump when dumping the kernel's memory to a core
[17:42] <stokachu> xnox: i think now it just uses vmlinux
[17:43] <stokachu> or /proc/vmcore
[17:45] <stokachu> xnox: https://bugs.launchpad.net/ubuntu/precise/+source/kexec-tools/+bug/988512/comments/19
[17:45] <stokachu> that explains the reasoning behind it
[17:45] <barry> @pilot in
[17:46] <barry> @pilot in
[17:46] <barry> that's better
[17:46] <barry> (are jamespage and robert_ancell actually piloting today?)
[17:46] <ScottK> green7: Submissions can be done either as a patch or a bzr branch, so it should be fine.
[17:46] <jamespage> barry, no - just forgot to pilot out yesterday
[17:47] <barry> jamespage: np.  it looked like the bot was broken anyway
[17:47] <jamespage> barry, ta - have fun...
[17:47] <infinity> barry: Seems unlikely that Robert's piloting, since he's not even here. ;)
[17:47] <barry> ;)
[17:48] <stgraber> barry: I don't think the bot was really broken, looked like people forgeting to @pilot out and the topic overflowing (explaining why it only managed to append a , and not your name)
[17:49] <stokachu> stgraber: its easier to blame the children though
[17:49] <stokachu> :D
[17:58] <tjaalton> micahg: right, it was merged from debian git. and ddebs are not that easy to use, unlike -dbg packages which are always available
[18:56] <rsalveti> tjaalton: any idea when we'll be pushing the new xorg packages from proposed?
[18:56] <rsalveti> tjaalton: I'm working no on checking and testing the omap x11 driver, to see if the support for sgx will still work fine with the latest xorg release
[18:58] <rsalveti> seems upstream is still at xorg-server-1.12.99.904
[18:58] <rsalveti> and I know feature freeze will happen during next week
[18:59] <rsalveti> so just wanted to have an idea of when the new packages will actually land at quantal
[19:16] <green7> how do I submit my patch without using bzr?
[19:19] <slangasek> rsalveti: they're supposed to be getting pushed this week once we have a full set of driver packages built
[19:20] <rsalveti> slangasek: great
[19:22] <green7> can anyone help me out?
[19:25] <green7> how do I submit my patch without using bzr?
[19:25] <ScottK> green7: Make a debdiff or just a regular diff and attach the file to the bug. Then subscribe ubuntu-sponsors to the bug.
[19:26] <stokachu> barry: do you mind reviewing https://code.launchpad.net/~adam-stokes/ubuntu/precise/tzdata/tzdata-2012d-1/+merge/119613
[19:27] <green7> ScottK: I've added binary files
[19:27] <ScottK> Needs to be source
[19:27] <barry> stokachu: sure thing
[19:27] <stokachu> thanks
[19:28] <barry> c'mon diffy diff
[19:28] <stokachu> ah still updating
[19:30] <green7> what am i supposed to do?
[19:32] <stokachu> barry: hmm i guess this is a good time to refill the coffee
[19:32] <barry> stokachu: i'll come back to it
[19:33] <stokachu> barry: ok no worries ill keep an eye on it and ping you when it shows up if thats cool
[19:33] <barry> stokachu: np
[19:33] <stokachu> thanks
[19:34] <christoffer> Is there any cost for the UDS in Copenhagen?
[19:35] <slangasek> christoffer: UDS is always free to attend
[19:35] <christoffer> awesome =)
[19:35] <christoffer> flight is booked
[19:36] <stokachu> i hear copenhagen has great gluten free bakeries/restaurants
[19:36] <stokachu> im excited
[19:36] <barry> \o/
[19:39]  * xnox is pondring sleeper train or flying
[19:39] <slangasek> taxi on a ferry
[19:40] <stokachu> may take you a year but what a trip!
[19:40] <slangasek> nah, it's a much more direct route :)
[19:40] <slangasek> (well, no, not really)
[19:40] <stokachu> lol
[19:41] <green7> should I attach both the binary files, and the patch?
[19:41] <xnox> stokachu: 17 hours. Eurostar to brussels, train to Cologne & sleeper train to copenhagen =)
[19:42] <slangasek> green7: what binary files are you attaching?
[19:42] <green7> there were some icons missing, i added them
[19:42] <stokachu> xnox: nice.. ill probaby be flying for 10 hours
[19:42] <slangasek> ok.  So you can attach those separately from the patch, yes
[19:43] <green7> in a tar.gz file?
[19:44] <barry> stokachu: with how long a layover? ;)
[19:44] <stokachu> barry: they haven't sent me the flight info yet :(
[19:45] <stokachu> but from what i saw it ranged from 2-3 at LHR
[19:45] <slangasek> green7: probably individually?
[19:45] <barry> sigh, my email's been down for 2 days
[19:45] <green7> all right
[19:45] <xnox> stokachu: 1.5 hours to the airport, 2 hours in the airport, 2 hours flying, 1 hour arrivals, 1 hour ground transportation. 8.5h so couple of hours on the train + a sleeper sounds nice actually
[19:45] <slangasek> green7: but I wonder why you're asking how to do this *without* using bzr, since bzr makes this case much easier
[19:45] <stokachu> xnox: definately, i personally would take a train if possible
[19:46] <stokachu> i have this thing about flying over large bodies of water for 90% of the trip
[19:46] <green7> slangasek: I had to download the source. bzr was very slow, so I downloaded using apt-get source. By the way, I'm working on LibreOffice.
[19:47] <slangasek> green7: oh... that's a good reason. ;)
[19:47] <slangasek> stokachu: I do too... it means there's no in-flight Internet!
[19:47] <green7> slangasek: thanks for the help.
[19:48] <stokachu> slangasek: i know right! still makes me wonder how i survived the dialup/bbs days
[19:48] <stgraber> stokachu: bah, just do like sladen did back in Orlando and spend a week on a boat ;)
[19:48] <micahg> green7: did you chat with Sweetshark yet?
[19:49] <green7> yes, once
[19:49] <stokachu> stgraber: haha, i tried to see if disney cruises had a line there but i was let down
[19:49] <xnox> stokachu: you survived... because you didn't know broadband!
[19:49] <stokachu> xnox: lol kids dont know how good they have it these days
[19:49] <xnox> stokachu: i always check the live jacket "under your seat" in case it's not ther
[19:49] <stokachu> haha
[19:50] <stokachu> i think all flights should come packaged with those paratroopere halo jump suits.
[19:51] <stokachu> worse case scenario i could batwing it halfway there
[19:51] <green7> micahg: Okay , I uploaded the patch. Now should I just wait? Or how can I send it for a review?
[19:51] <micahg> @pilot in
[19:51] <micahg> green7: subscribe ubuntu-sponsors or I can take a look at it
[19:51] <slangasek> xnox: you mean you know how to find the life jacket?
[19:52] <slangasek> I've tried and never succeeded in identifying the jacket :)
[19:52] <green7> micahg: Here is the bug https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/923932
[19:52] <green7> micahg: subscribing ubuntu-sponsors means subscribing to ubuntu-sponsors mailing list?
[19:52] <xnox> slangasek: yes.
[19:52] <micahg> green7: no, it means clicking subscribe someone else and adding ubuntu-sponsors
[19:52] <slangasek> xnox: please tell me the secret :)
[19:53] <green7> micahg: Oh, thank you
[19:53] <xnox> slangasek: i once had a children jacket instead of adult one =/
[19:53] <slangasek> heh
[19:54] <micahg> green7: binary diffs don't work too well, I think this is something that should go upstream as I originally mentioned to you
[19:54] <xnox> slangasek: if it's under the seat it has velcro fabric around it, take that off and it's there a bit deep than one would think it is.
[19:54] <micahg> green7: what did Sweetshark say about upstreaming this?
[19:54] <xnox> unless it's hidden in the 'overhead' compartment, which is meant to 'open automatically' =/
[19:54] <green7> micahg: he said me to go on with it.
[19:58] <micahg> Sweetshark: I'd like to chat with you about lp923932 if you're still around
[20:00] <stokachu> barry: looks like the diff is there now
[20:00] <micahg> barry: can I assume you're working on branches and I can safely work on debdiffs?
[20:01] <barry> micahg: +1
[20:01] <barry> stokachu: k, let me finish this current review
[20:01] <stokachu> barry: cool man thanks
[20:11] <barry> stokachu: i'll make you a deal.  i'll review this if you fix lp to only show me the debian/ directory on source branch diffs ;)
[20:12] <stokachu> hahah
[20:12] <stokachu> i mean.. sure ill see what i can do :)
[20:12] <barry> stokachu: not that it isn't fun to review a 4023 line diff, mind you
[20:13] <stokachu> lol my bad, however, the majority of it is translation
[20:13] <slangasek> stokachu: kexec-tools uploaded
[20:13] <stokachu> i think those should be ignored
[20:13] <stokachu> slangasek: awesome thanks so much
[20:13] <barry> stokachu: having my middle finger caress the scroll wheel as it points to the lp page does seem rather poignant
[20:14] <slangasek> oh, but it didn't like my upload to precise-proposed, let's see
[20:15] <stokachu> barry: lol i love the romantic spin you put on it
[20:16]  * barry ♡ lp
[20:26] <stokachu> barry: is it bad that it takes me a full 3 seconds to page up from the bottom of that MP :P
[20:26] <barry> stokachu: probably not a *good* sign
[20:26] <stokachu> lol
[20:27] <xnox> barry: X can rotate screen 90 degrees... for a reason!
[20:27] <barry> :)
[20:30] <barry> stokachu: isn't tzdata is a special sru case?  i'm not exactly sure what the rules for it are
[20:32] <xnox> stokachu: as in it's installer component, and we will need to refresh all of them before final image respin type of thing?
[20:34] <ScottK> Also it's got a micro-release exception, IIRC.
[20:37] <stokachu> barry: im under the impression tzdata policy is pretty relaxed
[20:38] <stokachu> xnox: its probably a good idea to do that if its not to late
[20:38] <barry> slangasek: do you know what the scoop is for tzdata sru?
[20:39] <slangasek> barry: it's data, and if it's not up to date it's a bug by definition; so we take the full upstream bump as an SRU for all releases
[20:39] <slangasek> not sure if this is documented anywhere, let me check and fix if not
[20:39] <infinity> barry: With tzdata SRUs, we just take the upstream data, and do a bit of verfication that it (a) fixes specific bugs we wanted fixed and (b) doesn't horribly regress and make everyone appear to be in Tanzania.
[20:39] <slangasek> https://wiki.ubuntu.com/StableReleaseUpdates#tzdata
[20:39] <slangasek> yes, it's documented :)
[20:39] <barry> slangasek: does it still go through -proposed?
[20:39] <slangasek> barry: yes
[20:40] <xnox> infinity: i bet it did once make everyone appear in Tanzania
[20:40] <stokachu> haha
[20:41] <dobey> anyone know how to get a -dbg package that's not empty, for a package using cmake to build a library?
[20:41]  * barry appeared in tanzania once, but it was blamed on the kombucha mold
[20:42] <barry> slangasek: so then stokachu needs to change his changelog entry to precise-proposed
[20:42] <slangasek> barry: correct
[20:42] <stokachu> ah ok
[20:42] <barry> and i suppose also file an sru bug
[20:42] <stokachu> so does my name appear on the changelog?
[20:42] <barry> stokachu: and link the bug to your branch
[20:43] <stokachu> so a normal sru process where i update the changelog and link related branch
[20:43] <barry> stokachu: i think it would be fine to include the above url to the verification procedure
[20:43] <barry> stokachu: i think so
[20:44] <stokachu> barry: as the test case you mean?
[20:44] <barry> right
[20:44] <stokachu> ok gotcha
[20:44] <stokachu> ill do that now
[20:44] <barry> thanks
[20:45] <stokachu> barry: do you mind accepting the series nomination for precise in the bug?
[20:45] <stokachu> pad.lv/1031836
[20:46] <barry> stokachu: done!
[20:49] <stokachu> so for this since there was no ubuntu version im starting at 0.1? tzdata (2012d-1ubuntu0.1) precise-proposed; urgency=low
[20:49] <stokachu> or just ubuntu1
[20:51] <micahg> stokachu: it needs to go to all releases, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging for versioning suggestions
[20:54] <stokachu> micahg: cool thanks that helps a lot
[20:54] <barry> stokachu: and "dpkg --compare-versions" can help
[20:54] <infinity> stokachu: Traditionally, we've gone with something like -0ubuntu0.11.10 -0ubuntu0.10.04, and such.
[20:55] <infinity> stokachu: FTR, given that this is done by glibc maintainers in Debian, I don't mind if you pass this off to me for Ubuntu as well (I've done it in the past).
[20:56] <slangasek> it's probably worth plucking a previous SRU bug out of the changelog and looking at how it's been done in the past
[20:57] <infinity> Or looking at https://launchpad.net/ubuntu/+source/tzdata/+publishinghistory
[20:57] <infinity> Which shows fairly consistent versioning.
[20:57] <stokachu> i dont think there is one in the changelog
[20:57] <infinity> (Except for hardy, which requires a repack...)
[20:57] <stokachu> lol lp times out
[20:58] <slangasek> infinity: I meant for a template for the SRU bug
[20:58] <infinity> Ahh.
[20:58] <slangasek> blah, are we still not done with hardy? :)
[20:58] <infinity> Well, that would also aim him at those. ;)
[21:00] <infinity> https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/881250
[21:00] <infinity> For instance.
[21:00] <infinity> Or, the most recently-fixed:
[21:00] <infinity> https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/948328
[21:01] <stokachu> ah i see the version there
[21:02] <stokachu> barry: ok i updated the MP, wrote the sru template, and linked the branch
[21:04] <stokachu> though i followed the link micahg sent about the versioning and appended 0.1
[21:04] <micahg> stokachu: hrm, that's not quite right...it has to go to all releases
[21:04] <infinity> stokachu: Following what we've done with the packages in the past might be nice.
[21:06] <micahg> I guess that doc doesn't make it clear in the uncommon case where you want to push a new upstream version to all releases
[21:06]  * micahg fixes
[21:07] <stokachu> yea i think im confused by what you mean on how to push to all releases
[21:07] <stokachu> or the proper way
[21:07] <barry> stokachu: also the 2012d-1 changelog entry looks weird (i did a bzr pull of your branch)
[21:08] <infinity> stokachu: You looked at the publishing history, right?
[21:08] <stokachu> infinity: ok i can do that, something like 0.12.04.1?
[21:08] <stokachu> or leave off the .1
[21:08] <infinity> stokachu: -0ubuntu0.12.04
[21:08] <infinity> stokachu: And every other release.
[21:08] <infinity> stokachu: It needs to go to all of them.
[21:09] <infinity> stokachu: Plus, hardy needs a repack, as hardy's dpkg-dev can't deal with the source format in later releases.
[21:10] <stokachu> i tried looking at the publishing history but lp was timing out with a oops
[21:11] <infinity> stokachu: Right, so, the publishing history would show you that when $devel_release has 1.2.3-1, then we backport to older releases as 1.2.3-0ubuntu0.12.04, etc.
[21:11] <infinity> stokachu: With the exception of hardy, which we can discuss after that bit's done. ;)
[21:11] <infinity> stokachu: Cause tzdata in hardy is a bit icky.
[21:11] <slangasek> stokachu: are you using this link?: https://launchpad.net/ubuntu/+source/tzdata/+publishinghistory
[21:12] <slangasek> loads for me
[21:12] <infinity> stokachu: And, as much as merge proposals are fun and all, I highly recommend you just backport quantal's package with nothing more than a changelog entry with the new version, and dump the sources somewhere for someone to verify and sign.
[21:12] <stokachu> yea it just came up now
[21:13] <infinity> stokachu: Cause, well.  A bazillion line MP is pointless.  Something I can diff against quantal and say "yeahp, that's identical except for the changelog", is easier.
[21:13] <stokachu> infinity: ah, understood ill do that from now on
[21:13] <micahg> infinity: umm, unless there were packaging changes to make it work, wouldn't it just be better to use the new upstream tarball + changelog entry?
[21:14] <infinity> micahg: Actually, I may have uupdated with the new tarball (minus the hardy abomination) in the past.  Good point.
[21:14] <infinity> micahg: Easy enough to verify that theory. :P
[21:15] <infinity> micahg: Hrm.  Well, it's hard to say how I did my last update in 2011, but my diffs sure were readable. :P
[21:16]  * infinity grabs the sources.
[21:17] <micahg> infinity: seems that's what pitti did on the last update
[21:17] <micahg> tarball + changelog
[21:17] <stokachu> infinity: do you actually mind doing this one so i can see how it is done? that way i can get it right next time
[21:17] <infinity> micahg: Yeah, looks like it was a straight uupdate.  That said, the end result was no different from what I outlined above, except that the changelog ends up a bit odd, and that debian/copyright is wrong. :P
[21:17] <infinity> micahg: So, I'd argue that the "backport quantal's version" method is actually more correct.
[21:19] <micahg> infinity: you have to be careful about that for earlier stable releases in case the packaging changed, but in the case of precise, sure, it works :)
[21:19] <infinity> micahg: Diffing for packaging changes isn't rocket surgery.
[21:19] <infinity> micahg: We know hardy breaks and needs special treatment, but that's true no matter how you approach it.
[21:19] <micahg> infinity: sure, but once you say backport, not everyone will know to do that :)
[21:19] <infinity> micahg: (Since the orig is a tar.xz, which don't work so smashingly well in hardy)
[21:20] <infinity> micahg: Even if I don't say backport, people will screw that part up. :P
[21:20] <infinity> micahg: Until they know why.
[21:20] <micahg> yes, we got xz source support in lucid, just not xz binary support
[21:20] <barry> infinity, stokachu maybe update that sru page #tzdata section with more details on the best way to handle the package?
[21:21] <infinity> barry: Yeah, I'll continue my debate with micahg in my head, and then write up a slightly better bit in the docs.
[21:21] <stokachu> that would be awesome
[21:21] <barry> thanks!
[21:21] <micahg> stokachu: and I've updated that wiki for versioning tips for a new upstream release
[21:22] <infinity> It sort of goes both ways, of course.  "backport what's in $devel" means that if we change packaging in devel due tp upstream format changes, etc, it'll DTRT.  But it also, as micahg points out, has the chance that new packaging changes might blow up on old releases.
[21:22] <stokachu> micahg: awesome, im reading that now
[21:22] <infinity> So, there's a bit of common sense "diff against old release and make sure nothing weird  happened" in there.
[21:22] <infinity> No matter which route you go, you need to "diff old release with $devel to see what changed in packaging, if anything".
[21:23] <infinity> Thankfully, tzdata isn't wildly complex, and other than the orig format changing, the packaging hasn't really changed in eons for any meaningful reason.
[21:29] <stokachu> micahg: so your example shows for new upstream release would be something like 2012d-1ubuntu0.12.04.1?
[21:30] <infinity> stokachu: I'll update the tzdata bit on the wiki specifically.
[21:30] <infinity> stokachu: And no, that version would be wrong, as it would be higher than quantal.
[21:30] <micahg> stokachu: if you're basing it on the Debian package, yes, otherwise -0ubuntu0.12.04.1, but that has the unfortunate side effect of being higher than quantal, so you'd want to do 2012d-1~ubuntu12.04.1 if you're basing it on the quantal package
[21:30] <stokachu> ah ok
[21:31] <infinity> Ahh, dangit, we have different debconfiscation in older versions.  Yeah, uupdate is going to be the way to go.
[21:31] <infinity> But I will update debian/copyright on this update, since it's wrong.
[21:32] <stokachu> ah uupdate yet another tool i need to be familiar with
[21:38]  * micahg added a note to the version page about it being for an upstream only update
[21:48] <goddard> anyone know what the clock is called in the system tray?
[21:48] <goddard> I wanna check out the code
[21:49] <infinity> goddard: indicator-datetime
[21:50] <goddard> ok thanks
[21:54] <infinity> Hrm.  I wonder if we should update to 2012e while we're at it.
[21:56] <micahg> if there's something useful in there, why not?
[21:56] <infinity> Yeah, grabbing it to diff.
[21:58] <infinity> A formatting change, a lot of updated comments, and one updated zone.
[21:58] <infinity> May as well.
[22:02] <barry> @pilot out
[22:03] <barry> micahg: the ship is all yours now
[22:35] <infinity> stokachu: Still around?
[22:35] <infinity> stokachu: Two things.  Can you tell me if https://wiki.ubuntu.com/StableReleaseUpdates#tzdata seems clear enough to you?
[22:36] <infinity> stokachu: And, at http://lucifer.0c3.net/~adconrad/tz.tgz you'll find a tarball of what I just uploaded, so you can have a quick look at the final product and compare with the wiki instructions and see if the two seem to mesh and make sense.
[22:38] <infinity> stokachu: To be fair, like I said, I don't mind owning tzdata anyway, but I always want to make sure that the "I'm on vacation being hit by several busses" instructions are sane, and that you've learned something from it all. :)
[22:41] <micahg> infinity: for the hardy instructions, shouldn't the first copy be for an .orig.tar.xz?
[22:42] <micahg> oh, hrm
[22:42]  * micahg doesn't get why a repack is needed then...
[22:43] <infinity> micahg: It used to do tarball-in-tarball, then switched to 3.0(quilt)
[22:44] <infinity> micahg: It's not xz that's the problem, I was miremembering, it's dpkg-source 3.0
[22:44] <micahg> infinity: why not just switch it to not use tarbal and tarball to skip the repacks?
[22:44] <micahg> * tarball in tarball
[22:44] <micahg> that's fine, as long as you're not updating the packaging, that should be irrelevant
[22:44] <infinity> micahg: Did hardy do 3.0?
[22:44] <micahg> no
[22:45] <infinity> Well, then.  That's why...
[22:45] <micahg> but who cares, it's an .orig.tar.gz
[22:45] <ScottK> And tarball in tarball is awful.
[22:45] <infinity> I mean, okay, someone could change the hardy packaging violently to neither match later releases nor previous, but who cares?
[22:45] <micahg> ScottK: yes, chrisccoulson finally rid the Mozilla stuff of that (don't think it's hit stable yet though)
[22:46] <micahg> infinity: well, make the change once and make future updates sane?
[22:46] <micahg> infinity: I guess if we're not doing it every month, it doesn't matter much anymore with 8 months of support left
[22:46] <infinity> There's nothing sane about it. :P
[22:46] <BenC> Laney: are you babysitting the dep-waits and ftbfs on powerpc ghc updates?
[22:46] <slangasek> anyone here seen problems with upgrading the latest libnspr4 SRU on precise?
[22:47] <micahg> slangasek: worked for me when it hit proposed
[22:47] <Laney> BenC: I'm not aware of any issues that require specific action beyond the normal transition stuff
[22:47] <Laney> I've had some arm ftbfs but nothing for ppc yet
[22:48] <infinity> Laney: What sorts of ARM FTBFS?
[22:48] <BenC> Laney: ghc has a ton of ftbfs and depwaits for powerpc that aren't the same as i386 and x86_64 (which it should match up not that it has ghci)
[22:48] <Laney> the compiler segfaults, haven't investigated
[22:48]  * micahg had an armhf failure actually on something
[22:48] <BenC> *now
[22:48] <Laney> BenC: example?
[22:48] <Laney> something that's already been uploaded?
[22:49] <BenC> Laney: http://qa.ubuntuwire.org/ftbfs/
[22:49] <Laney> infinity: try to rebuild e.g. haskell-cmdargs on armhf
[22:49] <BenC> Scan down the powerpc column for haskell-*
[22:49] <Laney> not sure that's anything that has been rebuilt for this round
[22:50] <Laney> in other words I expect those to shake out
[22:50] <infinity> Laney: And only broken on armhf?  FUN.
[22:50] <Laney> some el too IIRC
[22:50] <BenC> Laney: I had powerpc way down near i386 and x86_64, and now it's all a mess again :(
[22:50] <infinity> BenC: Welcome to haskell.
[22:50] <Laney> be calm, it's just the way these transitions go
[22:51] <Laney> if you want to help then grind out some rebuilds: http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
[22:51] <Laney> i'm not doing any tonight so you won't collide with me
[22:52] <ajmitch> Laney: it's not helped by some rebuilds still mysteriously failing
[22:53] <Laney> infinity: some armel too, same symptoms, see https://launchpadlibrarian.net/112621651/buildlog_ubuntu-quantal-armel.haskell-chell_0.3-1build1_FAILEDTOBUILD.txt.gz
[22:53] <Laney> still way better than it has been
[22:53] <ajmitch> I see haskell-cmdargs has been retried yet again, that's one that appear to be segfaulting during build
[22:54] <infinity> Laney: I tossed one back to see if it's reproducible.
[22:54] <infinity> ajmitch: That was me.
[22:54] <ajmitch> aha
[22:54] <Laney> it is, I built it on my panda (but nothing more)
[22:54] <ajmitch> when I checked it an hour ago, it failed at the same place as yesterday
[22:54] <Laney> built → reproduced the failure
[22:54] <infinity> Bizarre that it would only sometimes hit armel, sometimes armhf, but reproducibly on the same code.
[22:55]  * Laney sleeps
[22:55]  * infinity removes ghc and its rdeps from the archive.
[22:55] <xnox> infinity: why do you hate greek alphabet? =)
[22:56] <ajmitch> infinity: I'm sure you'd make a few people happy if you did so
[22:56] <infinity> ajmitch: I'd make myself happy, that's clearly all that matters.
[23:00] <slangasek> xnox: βεκαυζ ηζ α εαθεν
[23:00] <infinity> slangasek: Ow.
[23:01] <slangasek> apologies for the lack of breath marks, I seem to have misplaced them on my keyboard
[23:02] <infinity> I'm convinced that lowercase zeta is a pictographic representation of an aneurysm.
[23:03] <slangasek> ἑαθεν
[23:03] <slangasek> right, there are my breath marks
[23:21] <slangasek> jcastro: http://askubuntu.com/questions/175722/unmet-dependencies-for-libnspr4/175920 corresponds to the top-reported failure on errors.ubuntu.com today, an issue that's been introduced by an SRU of libnspr4... that we can't reproduce.  is there anything you can do to help us get a useful bug report out of someone?