| TheLordOfTime | ScottK, standard "subscribe ubuntu-sponsors" method for bugfixing a raring package, or do I need to follow a different procedure than standard? | 01:16 |
|---|---|---|
| xnox | TheLordOfTime: ubuntu-sponsors should be subscribed if there is something to sponsor - like a debdiff or a patch. | 01:21 |
| 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:22 |
| 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:23 |
| TheLordOfTime | (in Raring) | 01:24 |
| xnox | TheLordOfTime: bug number? | 01:24 |
| TheLordOfTime | xnox, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1132678 | 01:24 |
| ubottu | Launchpad bug 1132678 in nginx (Ubuntu) "nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)" [High,Fix committed] | 01:24 |
| TheLordOfTime | easy workaround (add something on a line) | 01:24 |
| TheLordOfTime | that "Fix Committed" was done by the debian maintainers | 01:24 |
| 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:25 |
| TheLordOfTime | bleh, random words on my keyboard, time to check my OS again for bugs... >.> | 01:26 |
| ScottK | TheLordOfTime: Standard. | 01:30 |
| 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 | 01:31 |
| * xnox checks the pilot schedule, damn it's me again actually. | 02:20 | |
| 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:39 |
| xnox | ESphynx: what FFe bug?! | 02:40 |
| ESphynx | xnox: http://bugs.launchpad.net/ubuntu/+source/ecere-sdk/+bug/1153763 this one =) | 02:42 |
| ubottu | Launchpad bug 1153763 in ecere-sdk (Ubuntu) "[FFe] Please update to Ecere SDK 0.44.04 for 64 bit support" [Undecided,New] | 02:42 |
| xnox | ESphynx: there is no need for FFe, "converted" to a sync request. | 02:46 |
| ESphynx | xnox: convoluted? :P | 02:47 |
| ESphynx | Does that mean it's more likely to be fixed for Raring or less likely? :) | 02:49 |
| ESphynx | thanks for triaging :P | 02:50 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| ESphynx | xnox: Sorry to have landed on you :( | 02:58 |
| ESphynx | xnox: I missed 2 lintian warnings overrides, sorry | 03:15 |
| xnox | not your fault, I do end up sucked into weird packages all the time. I guess it's karma =) | 03:16 |
| === ripps_ is now known as ripps | ||
| === Sp4rKy_ is now known as Sp4rKy | ||
| dholbach | good morning | 07:45 |
| freeflying | are we still using revu for package review/sponsorship seeking? | 09:43 |
| freeflying | or there is similar website | 09:43 |
| 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:47 |
| freeflying | tumbleweed: what about a new upstream release in Ubuntu | 09:48 |
| tumbleweed | freeflying: debdiff restricted to the debian directory? | 09:49 |
| tumbleweed | or a bzr merge proposal | 09:49 |
| freeflying | tumbleweed: not restricted to debian dir | 09:50 |
| tumbleweed | freeflying: ? | 09:51 |
| 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 |
| === Zic is now known as Guest32857 | ||
| tumbleweed | also, don't forget we are past feature freeze, so getting new releases in is hard | 09:53 |
| freeflying | tumbleweed: indeed | 10:14 |
| === 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 | ||
| * 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:00 | |
| ogra_` | will it overrride the kernel ? | 14:01 |
| === 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 | ||
| 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:37 |
| tumbleweed | it takes arbitrary arguments | 20:38 |
| tumbleweed | (IIRC) | 20:38 |
| 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:39 |
| tumbleweed | no, seriously, arguments are passed through unmodified | 20:40 |
| jtaylor | why doesn't it work then? | 20:40 |
| 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:41 |
| * 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:42 |
| jtaylor | hm | 20:43 |
| jtaylor | it only drops save-after-login with powerpc | 20:43 |
| jtaylor | not amd64 | 20:43 |
| tumbleweed | lol | 20:44 |
| jtaylor | kind of sucks as its more useful with ppc :/ | 20:44 |
| jtaylor | oh no I just overlooked it | 20:45 |
| jtaylor | so its a pbuilder issue | 20:45 |
| tumbleweed | \o/ | 20:45 |
| tumbleweed | seriously? | 20:45 |
| 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:46 |
| jtaylor | hm no | 20:50 |
| jtaylor | its not related to ordering | 20:50 |
| 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:51 |
| tumbleweed | hehe | 20:52 |
| tumbleweed | how does pbuilder know that you triggered an unsupported ioctl? | 20:52 |
| tumbleweed | does it get a signal? | 20:52 |
| 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:53 |
| 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:54 |
| 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:56 |
| tumbleweed | s/one/usual/ | 20:57 |
| jtaylor | pbuilder is a shells script, not so nice for gdb | 20:58 |
| jtaylor | on the other hand I can just put echos in | 20:58 |
| 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:01 |
| tumbleweed | schroot++ | 21:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!