[01:16] <TheLordOfTime> ScottK, standard "subscribe ubuntu-sponsors" method for bugfixing a raring package, or do I need to follow a different procedure than standard?
[01:21] <xnox> TheLordOfTime: ubuntu-sponsors should be subscribed if there is something to sponsor - like a debdiff or a patch.
[01:22] <xnox> if there is branch merge proposal, it's already subscribed.
[01:22] <TheLordOfTime> xnox, its a debdiff
[01:22]  * TheLordOfTime can't use bzr effectively to save his life, so... :P
[01:22] <xnox> subscribe ubuntu-sponsors if the next step ;-)
[01:22] <TheLordOfTime> xnox, done.  :P
[01:22] <TheLordOfTime> xnox, do they get a notification that they've been subscribed?
[01:22] <TheLordOfTime> or do I have to say something after subscribing them?
[01:22] <xnox> TheLordOfTime: better, we have a queue: http://reqorts.qa.ubuntu.com/reports/sponsoring/
[01:23] <TheLordOfTime> cool
[01:23] <xnox> and we have schedule of daily patch pilots reviewing and uploading patches
[01:23] <TheLordOfTime> xnox, by priority or just by whatever's at the top of the list?
[01:23] <TheLordOfTime> 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] <TheLordOfTime> (in Raring)
[01:24] <xnox> TheLordOfTime: bug number?
[01:24] <TheLordOfTime> xnox, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1132678
[01:24] <TheLordOfTime> easy workaround (add something on a line)
[01:24] <TheLordOfTime> that "Fix Committed" was done by the debian maintainers
[01:25] <TheLordOfTime> not but it throws an "emerg" and then doesn't run correctly
[01:25] <TheLordOfTime> 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] <TheLordOfTime> bleh, random words on my keyboard, time to check my OS again for bugs... >.>
[01:30] <ScottK> TheLordOfTime: Standard.
[01:31] <TheLordOfTime> ScottK, you were ninja'd by xnox :P
[01:31] <TheLordOfTime> but *shrugs*
[01:31] <ScottK> I saw, but I still like to answer the questions directly asked of me.
[01:31] <TheLordOfTime> 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] <ESphynx> 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] <xnox> ESphynx: what FFe bug?!
[02:42] <ESphynx> xnox: http://bugs.launchpad.net/ubuntu/+source/ecere-sdk/+bug/1153763 this one =)
[02:46] <xnox> ESphynx: there is no need for FFe, "converted" to a sync request.
[02:47] <ESphynx> xnox: convoluted? :P
[02:49] <ESphynx> Does that mean it's more likely to be fixed for Raring or less likely? :)
[02:50] <ESphynx> thanks for triaging :P
[02:53] <ScottK> 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] <ESphynx> all depends on what you can 'features' really, to me that's a very vague term :P
[02:54] <ESphynx> 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] <ESphynx> 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] <ScottK> Feature includes major invasive changes, so it counts.
[02:56] <ScottK> xnox: If you sponsor in Debian, I'll approve the FFe.
[02:56] <ESphynx> sounds like a deal :) many thanks to both of you ;)
[02:57] <xnox> 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] <ESphynx> 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] <ScottK> xnox: I have not given it a review.  If you sponsor, you're responsible (as usual in Debian).
[02:58] <ESphynx> xnox: Sorry to have landed on you :(
[03:15] <ESphynx> xnox: I missed 2 lintian warnings overrides, sorry
[03:16] <xnox> not your fault, I do end up sucked into weird packages all the time. I guess it's karma =)
[07:45] <dholbach> good morning
[09:43] <freeflying> are we still using revu for package review/sponsorship seeking?
[09:43] <freeflying> or there is similar website
[09:47] <tumbleweed> there's also mentors.debian.net (and we prefer new packages to be added to Debian, not Ubuntu)
[09:47] <tumbleweed> and for changes to packages already in the archive, just stick a debdiff in a LP bug
[09:48] <freeflying> tumbleweed: what about a new upstream release in Ubuntu
[09:49] <tumbleweed> freeflying: debdiff restricted to the debian directory?
[09:49] <tumbleweed> or a bzr merge proposal
[09:50] <freeflying> tumbleweed: not restricted to debian dir
[09:51] <tumbleweed> freeflying: ?
[09:53] <freeflying> 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] <tumbleweed> I suggested two: a debdiff filtered on /debian/ or a bzr merge proposal
[09:53] <tumbleweed> both are fine
[09:53] <tumbleweed> also, don't forget we are past feature freeze, so getting new releases in is hard
[10:14] <freeflying> tumbleweed: indeed
[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] <ogra_`> will it overrride the kernel ?
[20:37] <jtaylor> noooooo
[20:37] <jtaylor> pbuilder-dist does not take --save-after-login?
[20:37] <jtaylor> just lost 4 hour scipy compilation I wanted to reuse
[20:38] <tumbleweed> it takes arbitrary arguments
[20:38] <tumbleweed> (IIRC)
[20:39] <jtaylor> apparently not save-after-login
[20:39] <jtaylor> in raring
[20:39] <jtaylor> it does accept bindmounts
[20:39] <jtaylor> (but not bindmount)
[20:40] <tumbleweed> no, seriously, arguments are passed through unmodified
[20:40] <jtaylor> why doesn't it work then?
[20:41] <jtaylor> also does it really pass through?
[20:41] <tumbleweed> that's for you to find out :)
[20:41] <tumbleweed> yes
[20:41] <jtaylor> it explicitly rejects bindmount
[20:41] <jtaylor> whereas save-after-loginis just silently ignored
[20:42]  * tumbleweed can't see any code to reject bindmount
[20:42] <jtaylor> so at least something is inconsistent
[20:42] <tumbleweed> --debug-echo is your friend btw
[20:43] <jtaylor> hm
[20:43] <jtaylor> it only drops save-after-login with powerpc
[20:43] <jtaylor> not amd64
[20:44] <tumbleweed> lol
[20:44] <jtaylor> kind of sucks as its more useful with ppc :/
[20:45] <jtaylor> oh no I just overlooked it
[20:45] <jtaylor> so its a pbuilder issue
[20:45] <tumbleweed> \o/
[20:45] <tumbleweed> seriously?
[20:46] <jtaylor> an ordering issue
[20:46] <tumbleweed> ah
[20:46] <jtaylor> pbuilder-dist puts it to the end of the line
[20:46] <jtaylor> putting it behind the --login works
[20:46] <tumbleweed> if the ordering matters, we can force the right ordering
[20:50] <jtaylor> hm no
[20:50] <jtaylor> its not related to ordering
[20:51] <jtaylor> its qemu :/
[20:51] <jtaylor> if I trigger a unsupported ioctl in the chroot
[20:51] <jtaylor> the chroot is not stored
[20:51] <jtaylor> unfortunately triggering it is easy, just press °c
[20:51] <jtaylor> ^C
[20:52] <tumbleweed> hehe
[20:52] <tumbleweed> how does pbuilder know that you triggered an unsupported ioctl?
[20:52] <tumbleweed> does it get a signal?
[20:53] <jtaylor> I don't think pbuilder handles that
[20:53] <tumbleweed> pbuilder does the storing of the chroot when you are done with it
[20:54] <jtaylor> yes I wonder how the ioctl could mess that up
[20:54] <jtaylor> maybe not the chroot shell gets the ^C but pbuilder itself
[20:54] <jtaylor> so pbuilder aborts?
[20:56] <tumbleweed> dunno. strace/gdb?
[20:56] <tumbleweed> 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] <tumbleweed> s/one/usual/
[20:58] <jtaylor> pbuilder is a shells script, not so nice for gdb
[20:58] <jtaylor> on the other hand I can just put echos in
[21:01] <jtaylor> yes it gets the signal from the chroot
[21:01] <jtaylor> it traps that so it cleans up after itself
[21:01] <jtaylor> but it does not handle save-after-login anymore
[21:01] <tumbleweed> rigth
[21:02] <tumbleweed> schroot++