=== cpg|away is now known as cpg [00:03] Sorry, got pulled away just after I typed that. [00:03] I'm not seeing anything in my notes. THought I had. [00:44] hey all [00:44] which package should I file a gtk bug against? [00:45] jono: which version of GTK? [00:45] ahh gir1.2-gtk-3.0 [00:45] GTK3 [00:45] thanks micahg === emma is now known as em [01:13] 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] silvio: if it's about in archive stuff, you can ask here [01:17] 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] anything compatible... [01:18] 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] err. libjpeg8 is LGPL [01:22] i am wondering ig libjpeg8 is licensed incorrectly. [01:23] we're not using libjpeg8, but libjpeg-turbo [01:23] libjpeg8 is a dummy package that pulls in libjpeg-turbo [01:23] as far as i can tell [01:23] yes [01:23] right, and the dummy package is not the original work [01:24] since it is empty [01:24] how should dummy packages be licensed? [01:24] the packaging itself is licensed, using the license specified in debian/copyright of the source package [01:25] 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] right, and no derivative work would actually be linking against anything in there [01:26] 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] i don't think i've seen anything else that presented as an issue so far. [01:27] ok. thanks guys. cya === cpg is now known as cpg|away === cpg|away is now known as cpg [05:52] @pilot out [05:53] @pilot off [05:53] (pilot (in|out)) -- Set yourself an in or out of patch pilot. [05:53] @pilot out [05:54] @pilot out === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage === tkamppeter_ is now known as tkamppeter === kornbluth.freenode.net changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell, jamespage === wzssyqa is now known as Guest66197 [07:07] good morning === smb` is now known as smb [07:11] hey dholbach [07:12] hey didrocks [07:24] Guten Morgen ;-) =) [07:41] 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] s/this patch/these patches/ === amitk is now known as amitk-afk [08:15] ogra_: those patches have been in kwin for 9 months now [08:16] Riddell, oh, ok, i didnt know someone just dropped tzhem on my lap right now :) [08:47] infinity: I see that -omapfb is basically abandoned, and that -omap replaces it (uploaded a new upstream release to quantal-proposed). agreed? [08:49] ev, hey [08:49] ev, when do you think we will get the "month" view of e.u.c working again? [08:56] 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] ev, ok, thanks, it doesn't work here (or I got unlucky) === doko_ is now known as doko [09:11] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell, jamespage, [09:11] * seb128 hugs dholbach [09:12] * dholbach hugs seb128 back :) [09:12] ;-) [09:14] can somebody please reject https://code.launchpad.net/~cldunlap1/ubuntu/quantal/ciderwebmail/typo-fix/+merge/119413 (typo fix already forwarded to Debian) === cpg is now known as cpg|away === seb128_ is now known as seb128 [10:10] slomo, hey - how are you doing? [10:10] any idea what could be done with https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad0.10/+bug/973014? [10:10] Launchpad bug 973014 in gst-plugins-bad0.10 (Ubuntu) "gstreamer0.10-plugins-bad, (libgstvideoparsersbad.so), causes a failure to decode many common video files encoded as AVC 1 Baseline - L2.1, Baseline - L1.1 & others" [Undecided,Confirmed] === MacSlow is now known as MacSlow|lunch === yofel_ is now known as yofel [11:10] hi [11:11] I have a general question about develpment, but non-tech : where should I ask, please ? [11:11] s/develpment/development/ [11:12] 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] if I have a bit of time later on, I'll look into it - otherwise feel free to go ahead with this :) === Beret- is now known as Beret === Quintasan_ is now known as Quintasan [11:59] http://reqorts.qa.ubuntu.com/reports/sponsoring/ has merge proposals again! go wild! === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [13:30] ev: ping [13:35] 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] i.e. are wubi installs still supported? [13:36] If you're merging live-build, keep all our custom patches. [13:36] shadeslayer: yes [13:36] yes they are [13:36] cjwatson: some of them have been applied upstream [13:36] It's not worth dropping things in a merge only to discover that we needed them. [13:36] Well, that's not dropping them then, is it :-) [13:36] ofcourse :P [13:36] cjwatson: btw, could you look into ubuntu-armhf-support.patch and ubuntu-kernel-img-conf.patch [13:36] Not today or tomorrow. [13:37] for armhf, live build upstream does a special case ... but it's different from armel [13:37] oh ok [13:37] I'll disable it for now, since I'm not aiming at armhf [13:37] Then your merge needs to not go to the Ubuntu archive. [13:37] ofcourse [13:37] We have to keep armhf working. [13:37] I don't have upload rights anyway :P [13:38] plus, I wasn't planning on uploading to archive anyway [13:38] Right, but you might have been planning to propose it for review. [13:38] nope [13:38] I wanted to consult you before even uploading for review [13:39] cjwatson: could you let me know when we can discuss this? [13:39] * shadeslayer can plan accordingly [13:39] Personally I'm afraid I find reviewing merges much harder than just doing them. [13:39] haha :D [13:39] Because I generally have to basically do the merge in order to review it effectively. [13:39] I understand :) [13:40] 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] cjwatson: I'll probably upload this to my ppa for now, and I'll give you the link :) [13:46] tseliot, hey, what's the status of bug #1026518 [13:46] ? [13:46] Launchpad bug 1026518 in ubuntu-drivers-common (Ubuntu) "Add support for the Cedarview graphics driver" [High,Triaged] https://launchpad.net/bugs/1026518 [13:47] seb128: that's a good question. The package still seems to live in precise-proposed [13:49] 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] seb128: sure [13:49] tseliot, thanks === deryck is now known as deryck[afk] [13:56] bye [14:03] 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] dholbach: done [14:13] @pilot out === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage,, robert_ancell [14:13] thanks stgraber [14:13] 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] 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] 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] ev: ok, cool...wanted to see if you knew of one before opening a new one, thanks [14:20] sure thing [14:20] thanks for filing [14:25] dholbach: done [14:25] thanks stgraber === deryck[afk] is now known as deryck === lynxman- is now known as lynxman [15:12] dholbach: I think we specifically want an unprivileged account for the sponsorship queue, anonymous sounds better :) [15:12] micahg, we can't - to get information about who can upload what we need to be logged in [15:13] but if that wasn't the case, I'd totally agree [15:15] dholbach: well, it still needs to be an unprivileged authenticated user then [15:15] yes, we need authentication for that bit at least === rbelem_ is now known as rbelem === dendro-afk is now known as dendrobates [16:22] tjaalton: /me is puzzled by an upload for a -dbg package, don't we have dbgsym packages automatically? [16:23] micahg: We don't intentionally strip them out when the Debian packaging includes -dbg packages, it's a pointless delta. [16:25] infinity: yes, but I thought we don't specifically add those to in archive packages since we have the ddebs [16:33] 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] infinity: https://launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/1.6.2-1ubuntu4 [16:39] 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] 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] in the -dev package that is for example [16:51] ? [16:51] or did I get it wrong...? === cpg|away is now known as cpg [16:53] xnox: I've never multiarched a -dev package but, yes, that seems like a reasonable interpretation of how one would do it. [16:53] infinity: ok. reality check with infinity passed, I am on the right track then. [16:58] 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] xnox: That's a serious vote of confidence in your own work... [17:01] i did upload e2fsprogs today... upstream broke linking the whole package in a micro-point release =) was marvellous 20 minutes of fun [17:01] I wish it used automake.... [17:02] infinity: oh It's pinned to quantal-proposed on all precise&quantal machines ;-) === cpg is now known as cpg|away [17:12] 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] 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] and foo is marked multi-arch: foreign [17:29] 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] jamespage: hi, do you have the ability to sponsor userspace? [17:30] i can't remember if you were the one that only did kernel [17:30] green7: apt-get source $packagename [17:31] stokachu, not me I'm afraid [17:31] ScottK: There'll be no problems while submitting the patch, right? [17:31] jamespage: sorry :) was that a not me to userspace? [17:32] stokachu, I don't do kernel - what do you want sponsored? [17:33] jamespage: https://code.launchpad.net/~louis-bouchard/ubuntu/precise/kexec-tools/lp988512-no-vmcoreinfo/+merge/112086 [17:33] this merge proposal has been approved just needs to make it into proposed [17:33] its the userspace portion of kdump [17:34] stokachu, TBH thats a little outside my comfort zone; I'd prefer someone more knowledgeable review/sponsor [17:35] jamespage: any recommendations? [17:35] green7: regular patches are excepted just fine. create a bug + attach a patch + subscribe ~ubuntu-sponsors team. [17:36] ooo xnox :D [17:36] stokachu: Hola! =) [17:36] hey there! [17:36] stokachu: it sounds like you want me to do something for you right? [17:36] lol you know me so well [17:36] 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] stokachu: The changelod mess doesn't give me a bunch of confidence that the rest of the patch is complete. :P [17:38] Nor the changelog. [17:38] Dear irony, go away. [17:38] yea he's pretty new at this, though oddly the revisions are clean its just that preview diff for some reason [17:39] stokachu: revisions are clean ... against precise, not quantal changelog [17:39] ahh.. well there's the problem [17:39] (This is, actually, one of the reasons why I prefer diffs to MPs) [17:40] ok so ill have him redo the diff against quantal [17:40] then backport to precise [17:40] stokachu: Nah, I can sponsor to both and tidy up the changelog myself. Just rap him on the nose with a newspaper. [17:40] stokachu: it's fine, manually fix up the version string. [17:40] awesome thanks guys, ill make sure to have a writeup for the rest of the team [17:41] 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] some "guidelines" in order to not lose limbs [17:41] xnox: ah gotcha [17:42] stokachu: it looks fine, but i don't know what vmcoreinfo is/was [17:42] xnox: i think it was previously used by kdump when dumping the kernel's memory to a core [17:42] xnox: i think now it just uses vmlinux [17:43] or /proc/vmcore [17:45] xnox: https://bugs.launchpad.net/ubuntu/precise/+source/kexec-tools/+bug/988512/comments/19 [17:45] Launchpad bug 988512 in kexec-tools (Ubuntu Quantal) "Missing /boot/vmcoreinfo-{version} file is breaking kdump" [Medium,In progress] [17:45] that explains the reasoning behind it [17:45] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage,, robert_ancell, === barry changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [17:46] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry [17:46] that's better [17:46] (are jamespage and robert_ancell actually piloting today?) [17:46] green7: Submissions can be done either as a patch or a bzr branch, so it should be fine. [17:46] barry, no - just forgot to pilot out yesterday [17:47] jamespage: np. it looked like the bot was broken anyway [17:47] barry, ta - have fun... [17:47] barry: Seems unlikely that Robert's piloting, since he's not even here. ;) [17:47] ;) [17:48] 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] stgraber: its easier to blame the children though [17:49] :D [17:58] micahg: right, it was merged from debian git. and ddebs are not that easy to use, unlike -dbg packages which are always available === lifeless_ is now known as lifeless [18:56] tjaalton: any idea when we'll be pushing the new xorg packages from proposed? [18:56] 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] seems upstream is still at xorg-server-1.12.99.904 [18:58] and I know feature freeze will happen during next week [18:59] so just wanted to have an idea of when the new packages will actually land at quantal [19:16] how do I submit my patch without using bzr? [19:19] rsalveti: they're supposed to be getting pushed this week once we have a full set of driver packages built [19:20] slangasek: great [19:22] can anyone help me out? [19:25] how do I submit my patch without using bzr? [19:25] 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] barry: do you mind reviewing https://code.launchpad.net/~adam-stokes/ubuntu/precise/tzdata/tzdata-2012d-1/+merge/119613 [19:27] ScottK: I've added binary files [19:27] Needs to be source [19:27] stokachu: sure thing [19:27] thanks [19:28] c'mon diffy diff [19:28] ah still updating [19:30] what am i supposed to do? [19:32] barry: hmm i guess this is a good time to refill the coffee [19:32] stokachu: i'll come back to it [19:33] barry: ok no worries ill keep an eye on it and ping you when it shows up if thats cool [19:33] stokachu: np [19:33] thanks [19:34] Is there any cost for the UDS in Copenhagen? [19:35] christoffer: UDS is always free to attend [19:35] awesome =) [19:35] flight is booked [19:36] i hear copenhagen has great gluten free bakeries/restaurants [19:36] im excited [19:36] \o/ [19:39] * xnox is pondring sleeper train or flying [19:39] taxi on a ferry [19:40] may take you a year but what a trip! [19:40] nah, it's a much more direct route :) [19:40] (well, no, not really) [19:40] lol [19:41] should I attach both the binary files, and the patch? [19:41] stokachu: 17 hours. Eurostar to brussels, train to Cologne & sleeper train to copenhagen =) [19:42] green7: what binary files are you attaching? [19:42] there were some icons missing, i added them [19:42] xnox: nice.. ill probaby be flying for 10 hours [19:42] ok. So you can attach those separately from the patch, yes [19:43] in a tar.gz file? [19:44] stokachu: with how long a layover? ;) [19:44] barry: they haven't sent me the flight info yet :( [19:45] but from what i saw it ranged from 2-3 at LHR [19:45] green7: probably individually? [19:45] sigh, my email's been down for 2 days [19:45] all right [19:45] 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] green7: but I wonder why you're asking how to do this *without* using bzr, since bzr makes this case much easier [19:45] xnox: definately, i personally would take a train if possible [19:46] i have this thing about flying over large bodies of water for 90% of the trip [19:46] 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] green7: oh... that's a good reason. ;) [19:47] stokachu: I do too... it means there's no in-flight Internet! [19:47] slangasek: thanks for the help. [19:48] slangasek: i know right! still makes me wonder how i survived the dialup/bbs days [19:48] stokachu: bah, just do like sladen did back in Orlando and spend a week on a boat ;) [19:48] green7: did you chat with Sweetshark yet? [19:49] yes, once [19:49] stgraber: haha, i tried to see if disney cruises had a line there but i was let down [19:49] stokachu: you survived... because you didn't know broadband! [19:49] xnox: lol kids dont know how good they have it these days [19:49] stokachu: i always check the live jacket "under your seat" in case it's not ther [19:49] haha [19:50] i think all flights should come packaged with those paratroopere halo jump suits. [19:51] worse case scenario i could batwing it halfway there [19:51] micahg: Okay , I uploaded the patch. Now should I just wait? Or how can I send it for a review? [19:51] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open (DIF) | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry, micahg [19:51] green7: subscribe ubuntu-sponsors or I can take a look at it [19:51] xnox: you mean you know how to find the life jacket? [19:52] I've tried and never succeeded in identifying the jacket :) [19:52] micahg: Here is the bug https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/923932 [19:52] Launchpad bug 923932 in gnome-panel (Ubuntu) "[Classic session] LibreOffice icons are larger than other app's icons" [Undecided,Confirmed] [19:52] micahg: subscribing ubuntu-sponsors means subscribing to ubuntu-sponsors mailing list? [19:52] slangasek: yes. [19:52] green7: no, it means clicking subscribe someone else and adding ubuntu-sponsors [19:52] xnox: please tell me the secret :) [19:53] micahg: Oh, thank you [19:53] slangasek: i once had a children jacket instead of adult one =/ [19:53] heh [19:54] 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] 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] green7: what did Sweetshark say about upstreaming this? [19:54] unless it's hidden in the 'overhead' compartment, which is meant to 'open automatically' =/ [19:54] micahg: he said me to go on with it. [19:58] Sweetshark: I'd like to chat with you about lp923932 if you're still around [20:00] barry: looks like the diff is there now [20:00] barry: can I assume you're working on branches and I can safely work on debdiffs? [20:01] micahg: +1 [20:01] stokachu: k, let me finish this current review [20:01] barry: cool man thanks [20:11] 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] hahah [20:12] i mean.. sure ill see what i can do :) [20:12] stokachu: not that it isn't fun to review a 4023 line diff, mind you === jdstrand_ is now known as jdstrand [20:13] lol my bad, however, the majority of it is translation [20:13] stokachu: kexec-tools uploaded [20:13] i think those should be ignored [20:13] slangasek: awesome thanks so much [20:13] stokachu: having my middle finger caress the scroll wheel as it points to the lp page does seem rather poignant [20:14] oh, but it didn't like my upload to precise-proposed, let's see [20:15] barry: lol i love the romantic spin you put on it [20:16] * barry ♡ lp [20:26] barry: is it bad that it takes me a full 3 seconds to page up from the bottom of that MP :P [20:26] stokachu: probably not a *good* sign [20:26] lol [20:27] barry: X can rotate screen 90 degrees... for a reason! [20:27] :) [20:30] stokachu: isn't tzdata is a special sru case? i'm not exactly sure what the rules for it are [20:32] 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] Also it's got a micro-release exception, IIRC. [20:37] barry: im under the impression tzdata policy is pretty relaxed [20:38] xnox: its probably a good idea to do that if its not to late [20:38] slangasek: do you know what the scoop is for tzdata sru? [20:39] 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] not sure if this is documented anywhere, let me check and fix if not === morphis|away is now known as morphis [20:39] 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] https://wiki.ubuntu.com/StableReleaseUpdates#tzdata [20:39] yes, it's documented :) [20:39] slangasek: does it still go through -proposed? [20:39] barry: yes [20:40] infinity: i bet it did once make everyone appear in Tanzania [20:40] haha [20:41] 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] slangasek: so then stokachu needs to change his changelog entry to precise-proposed [20:42] barry: correct [20:42] ah ok [20:42] and i suppose also file an sru bug [20:42] so does my name appear on the changelog? [20:42] stokachu: and link the bug to your branch [20:43] so a normal sru process where i update the changelog and link related branch [20:43] stokachu: i think it would be fine to include the above url to the verification procedure [20:43] stokachu: i think so [20:44] barry: as the test case you mean? [20:44] right [20:44] ok gotcha [20:44] ill do that now [20:44] thanks [20:45] barry: do you mind accepting the series nomination for precise in the bug? [20:45] pad.lv/1031836 [20:46] stokachu: done! [20:49] so for this since there was no ubuntu version im starting at 0.1? tzdata (2012d-1ubuntu0.1) precise-proposed; urgency=low [20:49] or just ubuntu1 [20:51] stokachu: it needs to go to all releases, see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging for versioning suggestions [20:54] micahg: cool thanks that helps a lot [20:54] stokachu: and "dpkg --compare-versions" can help [20:54] stokachu: Traditionally, we've gone with something like -0ubuntu0.11.10 -0ubuntu0.10.04, and such. [20:55] 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] 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] Or looking at https://launchpad.net/ubuntu/+source/tzdata/+publishinghistory [20:57] Which shows fairly consistent versioning. [20:57] i dont think there is one in the changelog [20:57] (Except for hardy, which requires a repack...) [20:57] lol lp times out [20:58] infinity: I meant for a template for the SRU bug [20:58] Ahh. [20:58] blah, are we still not done with hardy? :) [20:58] Well, that would also aim him at those. ;) [21:00] https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/881250 [21:00] For instance. [21:00] Launchpad bug 881250 in tzdata (Ubuntu Precise) "Clocks in Ukraine move back October 30, 2011" [High,Fix released] [21:00] Or, the most recently-fixed: [21:00] https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/948328 [21:00] Launchpad bug 948328 in tzdata (Ubuntu Precise) "update database due to a change in Chilean timezone" [High,Fix released] [21:01] ah i see the version there [21:02] barry: ok i updated the MP, wrote the sru template, and linked the branch [21:04] though i followed the link micahg sent about the versioning and appended 0.1 [21:04] stokachu: hrm, that's not quite right...it has to go to all releases [21:04] stokachu: Following what we've done with the packages in the past might be nice. [21:06] 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] yea i think im confused by what you mean on how to push to all releases [21:07] or the proper way [21:07] stokachu: also the 2012d-1 changelog entry looks weird (i did a bzr pull of your branch) [21:08] stokachu: You looked at the publishing history, right? [21:08] infinity: ok i can do that, something like 0.12.04.1? [21:08] or leave off the .1 [21:08] stokachu: -0ubuntu0.12.04 [21:08] stokachu: And every other release. [21:08] stokachu: It needs to go to all of them. [21:09] stokachu: Plus, hardy needs a repack, as hardy's dpkg-dev can't deal with the source format in later releases. [21:10] i tried looking at the publishing history but lp was timing out with a oops [21:11] 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] stokachu: With the exception of hardy, which we can discuss after that bit's done. ;) [21:11] stokachu: Cause tzdata in hardy is a bit icky. [21:11] stokachu: are you using this link?: https://launchpad.net/ubuntu/+source/tzdata/+publishinghistory [21:12] loads for me [21:12] 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] yea it just came up now [21:13] 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] infinity: ah, understood ill do that from now on [21:13] 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] micahg: Actually, I may have uupdated with the new tarball (minus the hardy abomination) in the past. Good point. [21:14] micahg: Easy enough to verify that theory. :P [21:15] 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] infinity: seems that's what pitti did on the last update [21:17] tarball + changelog [21:17] 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] 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] micahg: So, I'd argue that the "backport quantal's version" method is actually more correct. [21:19] 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] micahg: Diffing for packaging changes isn't rocket surgery. [21:19] micahg: We know hardy breaks and needs special treatment, but that's true no matter how you approach it. [21:19] infinity: sure, but once you say backport, not everyone will know to do that :) [21:19] micahg: (Since the orig is a tar.xz, which don't work so smashingly well in hardy) [21:20] micahg: Even if I don't say backport, people will screw that part up. :P [21:20] micahg: Until they know why. [21:20] yes, we got xz source support in lucid, just not xz binary support [21:20] infinity, stokachu maybe update that sru page #tzdata section with more details on the best way to handle the package? [21:21] 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] that would be awesome [21:21]