[06:35] good morning === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [14:13] * Laney returns from hols [14:13] tumbleweed: did you check that thing out? ;-) [14:15] Laney: no [14:15] fair [14:15] I also haven't looked at the data for seeded-in-ubuntu which has been spamming me for two weeks [14:15] apparently we changed the structure of cdimage... [14:16] * Laney applies the delete hammer to 95% of his new mail [14:16] * tumbleweed has just been pushing through to the end of a work project. it hasn't left much energy [14:19] got a general question here: if i download (or create my own) source package. What is actually the command to build it ?! :-? [14:20] Guest43393: debuild [14:21] (but a lot of the time you want to build in a chroot, rather than on your machine - so look at pbuilder-dist or sbuild too) [14:21] ok. thanks mate. === mitya57 is now known as mitya57_ [19:34] am i still able to get a bugfix into raring for a package in universe? [19:34] (the bug priority is high) [19:38] sure [19:39] jtaylor, i just uploaded the debdiff, and since it's an out-of-the-box-config usability bug, i'm tryin to get this included quickly. https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1162177 [19:39] Launchpad bug 1162177 in nginx (Ubuntu) "nginx-light: invalid parameter "ipv6_only=on"" [High,In progress] [19:39] (there's a duplicate of that bug too, already marked as a dupe_ [19:40] (sponsors already subscribed, I think...) [19:43] ... you know what, i'm surprised I haven't filed for PPU rights for nginx yet... it seems a decent number of the recent debdiffs to fix things've come from me (or been brought in from upstream patches) [19:43] (sorry, minor offtopic, but still :P) [20:06] TheLordOfTime: if you're responsible for preparing most of the recent nginx uploads, you could get PPU rights for nginx. [20:07] Try talking to your sponsors if they think you're ready (and ask them to comment on your PPU application) [20:07] geser, i only prep them for ubuntu, not debian, and most of it's patches, would that still qualify? (note: i'm still only half done with my PPU application xD) [20:08] geser, i've been actively considering. Question though, can security debdiffs and patches count towards that as well, or just standard patches/debdiffs? [20:09] TheLordOfTime: sure, if you want upload right to Ubuntu you need to have uploads in Ubuntu (either directly or sync of your sponsored changes in Debian) [20:09] TheLordOfTime: they count too. [20:11] You need to show that you know enough packaging to handle the package(s) you ask PPU rights for and also that you have some process knowledge (e.g. when not to upload (freezes), how the SRU process works, etc.) [20:11] geser, i don't have any Debian patches for the package, but I've worked with SRU and upload freezes before. [20:11] not just on nginx, so i'm relatively fluent in those. [20:12] geser, and i'm smart enough to check when a freeze is in place to ask whether a bugfix can get in during said freeze(s) (case in point: the bug i referenced) [20:12] * TheLordOfTime yawns [20:12] ... note to self: twenty hours of work in a 12 hour day... bad... [20:12] geser, i assume the PPU procedure is the same as it was a few months ago when I started considering applying for PPU rights for nginx? [20:13] you do you co-maintain the nginx package with Debian or is a complete fork? just curious [20:13] PPU application procedure* [20:13] geser, i don't maintain the Debian side of things, I do most of the patch work for the Ubuntu packages though [20:13] I'm not in the DMB anymore but I doubt the procedures has changed much (if at all) [20:14] my concern is that i don't maintain the Debian packages at all, apparently they dump the Ubuntu stuff (as well as bug management for the nginx package) on me. [20:14] working with Debian isn't a strict requirement, but still nice to see [20:16] there is no requirement to also maintain the package in Debian [20:17] it's enough if you work on the Ubuntu package [20:22] <_hc> I'm a Debian Developer, we recently pushed a critical fix to wheezy and unstable, and I'd like to make sure this fix gets included in raring. The easiest way to do this would just be to update the currently included version 0.6.3-5 to the version in debian/unstable: 0.6.3-6 [20:23] <_hc> shall I file a bug report on this? what should I include on that bug report? I'm new to this particular process, tho I've submitted bugs to launchpad before [20:24] _hc: yes, you can use requestsync from the ubuntu-dev-tools package for it (it's also include in Debian) [20:26] <_hc> thanks, I'll try that, rebooting back to Ubuntu now :) [20:26] it should work from debian too [20:27] <_hc> I'm actually in Mac OS X now… where I spent about 10% of my time. My day-to-day is in Linux Mint, so basically ubuntu. I think there are a number of Debian Developers who work out of Debian-derivs [20:28] <_hc> the Apple Mail program is the last thing that keeps me rebooting, maybe Geary will change that [20:28] <_hc> reboot brb [20:39] <_hc> ok, I got the requestsync posted: https://bugs.launchpad.net/ubuntu/+source/olsrd/+bug/1165191 Is there something like "Release Critical" bug tag in Launchpad? The issue that we fixed was that the program wasn't working on non-i386 platforms, so its severe on those platforms. [20:40] Launchpad bug 1165191 in olsrd (Ubuntu) "Sync olsrd 0.6.3-6 (universe) from Debian unstable (main)" [Undecided,New] === bschaefer_ is now known as bschaefer [22:00] _hc: which versions of ubuntu does it affect? [22:01] _hc: might be worth doing a stable release update https://wiki.ubuntu.com/StableReleaseUpdates [22:03] <_hc> jtaylor: it affects quantal and raring for sure, and probably oneiric and precise [22:04] <_hc> raring is the easiest fix, just take 0.6.3-5 to 0.6.3-6. what's the Ubuntu policy on bigger updates? like for quantal, would it be acceptable to do an SRU for quantal from 0.6.3-3 to 0.6.3-6? [22:04] <_hc> otherwise, I'd have to prepare separate updates for precise, quantal, and raring [22:05] depends on how invasive the changes are [22:06] for quantal we only need the -6 diff it seems [22:06] if precise is affected it might be easier to go over backports [22:07] <_hc> yeah, I think backports makes more sense there [22:07] <_hc> jtaylor: yeah, for quantal, the 5->6 diff should work [22:08] hm good it has no reverse depends [22:08] that makes backports easy [22:08] <_hc> yeah, its a routing daemon [22:09] <_hc> but we're working on all sorts of fun stuff that depends on it, to make mesh networking really easy to use :) [22:09] you can request one with requestbackport if you think its worth it [22:10] <_hc> yeah, I do actually, I haven't done backports on Ubuntu, so it would be interesting. I have for debian. [22:10] its more painful in ubuntu than debian :/ [22:10] much more painful [22:10] if you have rdepends, without its fine [22:10] <_hc> yeah, no rdepends [22:11] ubuntu policy is everything must be tested and nothing must break, not even builds [22:11] <_hc> so to backport, should I wait until 0.6.3-6 is in raring? [22:11] yes [22:11] <_hc> ok [22:11] I'll have a look right now [22:12] <_hc> excellent, thanks :-D [22:12] can you provide a simple testcase that can be used to verify its fixed? [22:13] <_hc> it would require two computers with wifi [22:13] <_hc> basically run '/usr/sbin/olsrd-adhoc-setup wlan0' [22:14] <_hc> actually 'sudo /usr/sbin/olsrd-adhoc-setup wlan0' [22:14] <_hc> then 'sudo /usr/sbin/olsrd -i wlan0 -d 1' [22:15] <_hc> should I add this to a bug report? [22:15] <_hc> its non-trivial, unfortnately, but no too hard [22:16] <_hc> the debian package has been well tested, and we've been testing it on our PPA, so I would be shocked if it didn't work once it becomes an official Ubuntu update [22:16] <_hc> here's the PPA https://launchpad.net/~guardianproject/+archive/commotion/+packages [22:18] weird issue that was fixed [22:18] doesn't the compiler warn about this? [22:18] something like taking adress of temporary [22:19] <_hc> I guess not, it seems like it should have [22:19] <_hc> most of the upstream devs run -Werror... [22:20] which won't help if Wall is not on :/ [22:22] oh it is just no verbose log [22:22] it would be good if the package builds with make VERBOSE=1 [22:23] verbose logs are very helpful when you want to check some issues [22:24] <_hc> it should be now, in the latest version 0.6.3-6 [22:25] oh good, I just looked at the ubuntu build log which is still -5 :) [22:27] _hc: synced, could you verify the fix on quantal? then I#ll do an SRU [22:29] fixing it in precise via an SRU would also be pretty easy, but maybe also not necessary as it has an older compiler [22:56] <_hc> jtaylor: sure, I can verify the fix for quantal, do you mean test the package? [22:57] check if its affected and the patch fixes it [22:57] <_hc> yes, its affected, and yes, the patch fixes it [22:58] <_hc> the bug was introduced upstream before 0.6.2 and was fixed in 0.6.4, and that fix is the patch in 0.6.3-6 [22:58] yes but if its really broken depends on the compiler [22:59] <_hc> it was broken on quantal in my 0.6.3-5 uploads to the PPA and then fixed with the 0.6.3-6 uploads to that PPA [22:59] and in precise? [23:00] <_hc> I haven't specifically tested there [23:00] <_hc> let me double check that, since I'm on precise [23:01] <_hc> I do know that 0.6.3-6 works well on precise, since I use the PPA [23:01] what happens after sudo /usr/sbin/olsrd -i wlan0 -d 1 if its broken? [23:01] <_hc> I'll have to test whether the precise version is affected. But I think a backport would be worthwhile anyway, since there have been big improvements in the packaging [23:02] <_hc> the olsrd on each computer should start talking to each other, and setting up routes on each computer [23:05] <_hc> if the olsrd is affected by the bug, that never happens [23:06] I think the patch is simple enough to be SRU'd to precise in addition to a backport