[01:16] ScottK, standard "subscribe ubuntu-sponsors" method for bugfixing a raring package, or do I need to follow a different procedure than standard? [01:21] TheLordOfTime: ubuntu-sponsors should be subscribed if there is something to sponsor - like a debdiff or a patch. [01:22] if there is branch merge proposal, it's already subscribed. [01:22] xnox, its a debdiff [01:22] * TheLordOfTime can't use bzr effectively to save his life, so... :P [01:22] subscribe ubuntu-sponsors if the next step ;-) [01:22] xnox, done. :P [01:22] xnox, do they get a notification that they've been subscribed? [01:22] or do I have to say something after subscribing them? [01:22] TheLordOfTime: better, we have a queue: http://reqorts.qa.ubuntu.com/reports/sponsoring/ [01:23] cool [01:23] and we have schedule of daily patch pilots reviewing and uploading patches [01:23] xnox, by priority or just by whatever's at the top of the list? [01:23] xnox, because we've got a case of a Universe package not working out of the box due to a faulty default config file. [01:24] (in Raring) [01:24] TheLordOfTime: bug number? [01:24] xnox, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1132678 [01:24] Launchpad bug 1132678 in nginx (Ubuntu) "nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)" [High,Fix committed] [01:24] easy workaround (add something on a line) [01:24] that "Fix Committed" was done by the debian maintainers [01:25] not but it throws an "emerg" and then doesn't run correctly [01:25] xnox, TBPH i'd like to get this in ASAP, but if there's higher priority stuff then i'll be as patient as I can be with the emails about it. [01:26] bleh, random words on my keyboard, time to check my OS again for bugs... >.> [01:30] TheLordOfTime: Standard. [01:31] ScottK, you were ninja'd by xnox :P [01:31] but *shrugs* [01:31] I saw, but I still like to answer the questions directly asked of me. [01:31] I'll leave this be, apparently my keyboard's being stupid :P [02:20] * xnox checks the pilot schedule, damn it's me again actually. [02:39] xnox: Should I be assigning my Ubuntu FFe bug to ubuntu-sponsor as well? :) Also should I be bugging someone to assign it to Raring? :) [02:40] ESphynx: what FFe bug?! [02:42] xnox: http://bugs.launchpad.net/ubuntu/+source/ecere-sdk/+bug/1153763 this one =) [02:42] Launchpad bug 1153763 in ecere-sdk (Ubuntu) "[FFe] Please update to Ecere SDK 0.44.04 for 64 bit support" [Undecided,New] [02:46] ESphynx: there is no need for FFe, "converted" to a sync request. [02:47] xnox: convoluted? :P [02:49] Does that mean it's more likely to be fixed for Raring or less likely? :) [02:50] thanks for triaging :P [02:53] xnox: You don't think that needs an FFe? Seems to me like it has new features (BTW, needs sponsoring in Debian too before it can be sync'ed) [02:54] all depends on what you can 'features' really, to me that's a very vague term :P [02:54] at any rate I'd really appreciate if it could make it into Raring, as I've invested a great number of overtime hours to the detriment of my health to get this ready =) [02:55] but yeah, the main new 'feature' is 64 bit support... that is really a bug fix if you think about it, but it required fixing the whole SDK including the compiler to support it :) [02:56] Feature includes major invasive changes, so it counts. [02:56] xnox: If you sponsor in Debian, I'll approve the FFe. [02:56] sounds like a deal :) many thanks to both of you ;) [02:57] ScottK: ok. but i do need to read the diff & build it for debian & test, it's not a quick to review & sponsor package =)))) [02:57] xnox: a milestone ahead is 'haste' which will focus on speeding up the compiler, hopefully we'll go from 23 minute build to less :P [02:57] xnox: I have not given it a review. If you sponsor, you're responsible (as usual in Debian). [02:58] xnox: Sorry to have landed on you :( [03:15] xnox: I missed 2 lintian warnings overrides, sorry [03:16] not your fault, I do end up sucked into weird packages all the time. I guess it's karma =) === ripps_ is now known as ripps === Sp4rKy_ is now known as Sp4rKy [07:45] good morning [09:43] are we still using revu for package review/sponsorship seeking? [09:43] or there is similar website [09:47] there's also mentors.debian.net (and we prefer new packages to be added to Debian, not Ubuntu) [09:47] and for changes to packages already in the archive, just stick a debdiff in a LP bug [09:48] tumbleweed: what about a new upstream release in Ubuntu [09:49] freeflying: debdiff restricted to the debian directory? [09:49] or a bzr merge proposal [09:50] tumbleweed: not restricted to debian dir [09:51] freeflying: ? [09:53] tumbleweed: like upstream has a new release, and maintainer has it packaged, which is the best workflow for him to seek for sponsoring upload [09:53] I suggested two: a debdiff filtered on /debian/ or a bzr merge proposal [09:53] both are fine === Zic is now known as Guest32857 [09:53] also, don't forget we are past feature freeze, so getting new releases in is hard [10:14] tumbleweed: indeed === Guest32857 is now known as Zic === Marce_ is now known as Marce === popey_ is now known as popey === almaisan-away is now known as al-maisan [14:00] * xnox ponders to ship a package emacs-os, it will override and replace .desktop files, for example gnome-calculator.desktop Exec=emacs --eval '(calc)' and so on. [14:01] will it overrride the kernel ? === ogra_` is now known as ogra_ === ral_ is now known as ral === al-maisan is now known as almaisan-away === yofel_ is now known as yofel === mitya57 is now known as mitya57_ === maxb_ is now known as maxb [20:37] noooooo [20:37] pbuilder-dist does not take --save-after-login? [20:37] just lost 4 hour scipy compilation I wanted to reuse [20:38] it takes arbitrary arguments [20:38] (IIRC) [20:39] apparently not save-after-login [20:39] in raring [20:39] it does accept bindmounts [20:39] (but not bindmount) [20:40] no, seriously, arguments are passed through unmodified [20:40] why doesn't it work then? [20:41] also does it really pass through? [20:41] that's for you to find out :) [20:41] yes [20:41] it explicitly rejects bindmount [20:41] whereas save-after-loginis just silently ignored [20:42] * tumbleweed can't see any code to reject bindmount [20:42] so at least something is inconsistent [20:42] --debug-echo is your friend btw [20:43] hm [20:43] it only drops save-after-login with powerpc [20:43] not amd64 [20:44] lol [20:44] kind of sucks as its more useful with ppc :/ [20:45] oh no I just overlooked it [20:45] so its a pbuilder issue [20:45] \o/ [20:45] seriously? [20:46] an ordering issue [20:46] ah [20:46] pbuilder-dist puts it to the end of the line [20:46] putting it behind the --login works [20:46] if the ordering matters, we can force the right ordering [20:50] hm no [20:50] its not related to ordering [20:51] its qemu :/ [20:51] if I trigger a unsupported ioctl in the chroot [20:51] the chroot is not stored [20:51] unfortunately triggering it is easy, just press °c [20:51] ^C [20:52] hehe [20:52] how does pbuilder know that you triggered an unsupported ioctl? [20:52] does it get a signal? [20:53] I don't think pbuilder handles that [20:53] pbuilder does the storing of the chroot when you are done with it [20:54] yes I wonder how the ioctl could mess that up [20:54] maybe not the chroot shell gets the ^C but pbuilder itself [20:54] so pbuilder aborts? [20:56] dunno. strace/gdb? [20:56] the one odtity with qemu-user-static chroots is that you can't have setuid binaries, but I can't see how that's relevant here [20:57] s/one/usual/ [20:58] pbuilder is a shells script, not so nice for gdb [20:58] on the other hand I can just put echos in [21:01] yes it gets the signal from the chroot [21:01] it traps that so it cleans up after itself [21:01] but it does not handle save-after-login anymore [21:01] rigth [21:02] schroot++