[01:31] <goodwill> pardon me ...
[01:31] <goodwill> when I build my own ppa package from an existing package on a system I get this
[01:31] <goodwill> the current version (1.4.1-1~ppa1) is earlier than the previous one (1.4.1-1)
[01:32] <sarnold> goodwill: ~ is "special" -- it means "earlier than"...
[01:32] <cjwatson> That's ignorable if you're aware that anyone with your package installed will by default be upgraded to the newer version
[01:32] <cjwatson> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning
[01:32] <goodwill> so I want my package to supercede it
[01:32] <cjwatson> the URL I just gave has advice
[01:32] <goodwill> I've read it
[01:33] <goodwill> before
[01:33] <sarnold> goodwill: (think of it as an easy way to take version 1.2 from a newer release and then package 1.2~12.04, 1.2~12.10, 1.2~13.04, and be certain that they will be upgraded to '1.2' when the distribution is upgraded...)
[01:33] <cjwatson> goodwill: but you haven't followed its advice
[01:33] <cjwatson> goodwill: so read it again :)
[01:33] <goodwill> I think I am not understanding it
[01:33] <cjwatson> goodwill: in one sentence: delete the ~
[01:33] <goodwill> oh damn
[01:33] <goodwill> that right
[01:33] <goodwill> so blind
[01:33] <goodwill> did not see
[01:33] <goodwill> thank you
[01:34] <goodwill> sorry to be a bother
[01:34] <cjwatson> np
[01:35]  * goodwill headdesks for pebcac
[05:16] <pitti> Good morning
[05:17] <pitti> sarnold: they look fine from here
[05:51] <pitti> infinity: hey Adam, how are you?
[05:52] <infinity> pitti: Alive.  You?
[05:52] <pitti> infinity: I just filed an FFE which I hope should be mostly formal/trivial (bug 1236708), WDYT?
[05:52] <pitti> infinity: much better after a good night's sleep :) didn't get much over the long weekend with these French guys/girls and their wine
[05:53] <infinity> pitti: Yeah, looked like a good time.
[05:54] <infinity> pitti: As for ofono-phonesim, it's unseeded, so not subject to FF anyway.  But approved nonetheless.
[05:54] <pitti> infinity: oh, is that so? I thought FF applied to the whole archive, just the barrier was much lower for unseeded
[05:54] <pitti> anyway, thanks
[05:54] <infinity> pitti: Unseeded stuff is auto-accepted.
[05:55] <infinity> pitti: Anyhow, close your bug in your changelog (or by hand), etc.
[05:55] <pitti> *nod*
[06:07] <sarnold> pitti: good morning :) see e.g. https://bugs.launchpad.net/bugs/1235927 and https://bugs.launchpad.net/bugs/1235597 -- roughly one day and two days old, coredumps are still attached and no tracing
[06:09] <pitti> sarnold: ah yes, it seems there is a bad ddeb which it keeps trying to download
[06:12] <sarnold> pitti: excellent; I'm curious about the empathy-chat one, that might represent something more than the usual busted software. hehe. :)
[06:13] <sarnold> pitti: thanks for investigating
[06:14] <pitti> I twiddled the Packages.gz on ddebs, let's see how it works now
[06:20] <pitti> sarnold: seems happier now, 474 crashes to catch up with..
[06:20] <pitti> sarnold: thanks for pointing out!
[06:21] <sarnold> pitti: oh man, my email in the morning is going to be something impressive. heheh. :) thanks!
[07:17] <dholbach> good morning
[07:24] <rbasak_> xnox: hey, any chance you could take a look at bug 1209493 for me please? It's a straightforward merge with a dep8 test added. Just pushing it for final freeze.
[07:42] <infinity> rbasak: Oh, I missed my pilot day yesterday, I can do it.
[07:42] <rbasak> infinity: thanks!
[07:42] <infinity> @pilot in
[07:42] <infinity> @pilot out
[07:42] <infinity> There, now the stats bot will be happy. ;)
[07:43] <infinity> A changelog delta that goes all the way back to hoary.  Not bad.
[07:45] <infinity> rbasak: Nice dep8 test, too.
[07:45] <rbasak> infinity: thanks. I just noticed one minor mistake though (though it'll still pass I think).
[07:45] <rbasak> It's needs-root, but I used sudo. Do you mind dropping the sudos, please?
[07:46] <infinity> Sure.
[07:46] <infinity> It would fail to pass if sudo wasn't installed.
[07:46] <rbasak> Right
[07:46] <infinity> Otherwise, would be a no-op and work fine.
[07:46]  * rbasak tested the test with adt-virt-lxc on a cloud image, where sudo is installed
[07:46] <rbasak> I think our infrastructure uses cloud images too. But it shouldn't be there really.
[07:47] <infinity> rbasak: I like that it tests svnadmin, svn, and the apache module all in one go, though.
[07:47] <rbasak> It's a happy consequence. I didn't feel that I could test the apache module without testing both checkouts, commits and plain HTTP. And that involved the other pieces ;)
[07:47]  * infinity has never seen the trailing-dot chown notation.  Does that actually work?
[07:48] <rbasak> It works, though the manpage seems to refer to colons only
[07:49] <infinity> rbasak: Yeah, I mean "user." as opposed to "user.group" or "user"
[07:49] <rbasak> user: is documented
[07:49] <infinity> Looks like user. sets group to the user's primary group?  Maybe.
[07:49] <rbasak> Right
[07:49] <infinity> Learn something new every day.
[07:49] <rbasak> Though I never realised that "." was non-standard as opposed to ":".
[07:49] <slangasek> I thought there used to be a 'user:.' syntax, but that seems to have gone away
[07:49] <slangasek> (and it meant the same thing anyway, IIRC)
[07:50] <infinity> rbasak: . can be ambiguous on systems where people use . in usernames.
[07:50] <rbasak> Given that . isn't mentioned on the manpage, I shall start using : instead
[07:50] <infinity> rbasak: Hence :
[07:50] <rbasak> Ah, that makes sense. Thanks.
[07:50]  * slangasek nods
[07:50]  * infinity will change your . to a : in this test too.
[07:50] <rbasak> Thank you!
[07:51] <infinity> .. And reference the FFe in the changelog.
[07:51] <rbasak> +  * Includes changes from Debian nmu5 and nmu6 to restore the Apache module
[07:51] <rbasak> +    (LP: #1209493). Thanks to James McCoy for the Debian NMUs.
[07:51] <infinity> Oh, you did further down.
[07:52] <infinity> Yeah.
[07:54] <infinity> rbasak: I can trust that you test-built this a few dozen times and not do it myself? :P
[07:54] <rbasak> I have test built it, yes. And the dep8 test passes in my environment at least.
[07:55] <infinity> Alrighty, up she goes.
[07:55] <rbasak> Oh, one note. The tests failed in a PPA build, but pass in sbuild and (presumably) the buildds.
[07:55] <rbasak> (the "nocheck" tests, that is)
[07:55] <rbasak> I didn't investigate that further. I presume it's OK.
[07:56] <infinity> Why allow-stderr?
[07:56] <infinity> I mean, other than your test using set -x
[07:56] <rbasak> I find "set -x" really handy for writing these tests
[07:56] <infinity> Mmkay.
[07:56] <rbasak> To remove allow-stderr I have to drop "set -x" and then debugging gets really tedious
[07:56] <infinity> Yeah, I'm all for verbose (ish) logs, so whatever works for you.
[07:57] <rbasak> Thank you!
[07:58] <slangasek> rbasak: exec 2>&1; set -x ?
[07:58] <slangasek> though perhaps that gives no practical difference from allow-stderr :)
[07:58] <infinity> Yeah, not really.
[07:58] <slangasek> (if the bit that's set -x is at the top level)
[07:58] <infinity> Just confuses people who don't grasp FD redirection.
[07:59] <infinity> Which is, like, everyone who hasn't hacked on something joeyh or I wrote.
[07:59] <rbasak> I never considered that might work. I wasn't aware of where the "set -x" output came out from. I always presumed that it was at a higher level and not affected by redirection in the same shell.
[08:00] <slangasek> rbasak: shell fd redirection is actually a very thin syntax on top of the C fd interfaces :)
[08:00] <mlankhorst> can someone approve mesa to raring-proposed?
[08:00] <ogra_> slangasek, i heard rumours that you wanted to take a look at bug 1235649 ? did you do anything in that direction already (any info that the europe shift could pick up from you ?)
[08:00] <rbasak> That makes sense
[08:01] <rbasak> It would take extra work to make "set -x" independent I suppose
[08:02] <slangasek> infinity: didn't Tollef write the debconf fd redirection madness?
[08:03] <infinity> slangasek: I suppose he might be to blame.
[08:03] <infinity> slangasek: There are any number of us silly enough to have done such a thing.
[08:03] <slangasek> ogra_: just synced with jodh on that, actually; unfortunately I didn't get a chance to look at it today
[08:03] <ogra_> ok
[08:03] <slangasek> infinity: well, Tollef at least recanted afterwards ;)
[08:03] <slangasek> that whole "you can accidentally break the debconf frontend by writing to stderr" thing...
[08:05] <Caelum> Hello, I added a comment to this bug https://bugs.launchpad.net/ubuntu/+source/gedit-plugins/+bug/1165742 it's marked as 'fix released' but it's not fixed, could someone please change the status?
[08:08] <infinity> Caelum: Set back to confirmed.
[08:08] <Caelum> infinity: thank you very much!
[08:16] <infinity> Caelum: So, it looks like (for gedit-plugins), this should be fixed in saucy.
[08:16] <Caelum> excellent
[08:27] <infinity> init: /home/buildd/build-PACKAGEBUILD-4962761/chroot-autobuild/etc/init: Configuration directory deleted
[08:27] <infinity> I thought that was fixed...
[08:27] <infinity> Silly upstart mucking about in my buildd chroots.
[08:28] <FourDollars> xnox: Hi, I made https://code.launchpad.net/~fourdollars/ubuntu/precise/upower/fix-lp-bug-1153488 for https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1153488. Could you help me to review it?
[08:31] <slangasek> infinity: I thought we only fixed the bit where pid 1 would crash after mucking ;p
[08:31] <slangasek> infinity: I think I have this fixed in the Debian packaging branch, which I haven't uploaded yet because I'm waiting for a maintainer upload of libnih...
[08:31] <xnox> FourDollars: But description should be changed to include information as required for StableReleaseUpdates, you can use a handy template as a starting point https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template . The testcase is the most important bit.
[08:31] <xnox> FourDollars: the bug is not nominated for Precise series, I'll do that for you.
[08:32] <FourDollars> xnox: I see. Thanks.
[08:32] <xnox> FourDollars: the proposed branch, seems to have more patches than to simply fix the bug in question. E.g. there are no pygtk depreciations in precise and etc. (but that's at first glance only). Is there only the minimal patch you can pick up for the SRU to fix the bug in question (and nothing else?!)
[08:33] <xnox> FourDollars: your branch proposal should end up in the sponsorship queue http://reqorts.qa.ubuntu.com/reports/sponsoring/ and patch pilots should pick it up.
[08:33] <xnox> Oh............
[08:34]  * xnox realises I've been piloting for a week now?!
[08:34] <xnox> @pilot out
[08:34] <mlankhorst> lol
[08:34]  * Laney gives xnox a World's Best Sponsor mug
[08:34] <xnox> dholbach: do you think we can make udevbot to automatically do "@pilot out" 8 hours later on the person, and ping them if they wish to continue?
[08:35] <xnox> Laney: will you be in London next week? =)
[08:35] <Laney> no
[08:35] <slangasek> xnox: amazing you didn't run out of fuel
[08:35] <dholbach> tsimpson, ^ do you know if what xnox asked can be done?
[08:35] <Laney> not cool enough for that :P
[08:36] <seb128> xnox, hey, is that apturl still on your todolist?
[08:36] <tsimpson> dholbach: hmm, it may be possible. but it would require a complete redesign of the code (it's very simple right now)
[08:36] <dholbach> xnox, ^
[08:38] <infinity> slangasek: I suspect the maintainer of libnih isn't willing to admit he's MIA? :P
[08:38] <xnox> infinity: no.
[08:38] <xnox> he is not admitting that =)
[08:38] <Laney> do some salvaging :P
[08:39] <xnox> infinity: but then again, i'm not sure a MIA ping was officially filed.
[08:39] <slangasek> infinity, xnox: well, I haven't filed the bug against the Debian package for this either
[08:39] <slangasek> so I should maybe do that
[08:40] <tsimpson> http://bazaar.launchpad.net/~tsimpson/+junk/udevbot/view/head:/plugin.py is the code (if anyone's interested in working on it)
[08:42] <FourDollars> xnox++ LOL
[08:47] <xnox> seb128: yes, but not highest priority.
[08:47] <seb128> xnox, shrug, should we try to ask help to somebody else for it?
[08:47] <xnox> seb128: you could, yes.
[08:47] <seb128> it sucks to have apturl and package installs though it not working
[08:47] <xnox> seb128: true, but that could be SRUed, even 0-day SRU.
[08:48] <seb128> slangasek, hey, is there anyone in foundation that could help on 1200775 (some update-manager refactoring created issue for apturl and installing packages doesn't work anymore in saucy, which impacts e.g samba install from nautilus-share, or codec installs)?
[08:49] <xnox> =)
[08:57] <cjwatson> slangasek: I'm pretty sure the debconf fd redirection madness is joeyh's fault
[08:57] <cjwatson> slangasek: Also pretty sure it's writing to stdout that can break it, not writing to stderr :)
[09:02] <Laney> https://launchpadlibrarian.net/152824149/buildlog_ubuntu-saucy-arm64.gstreamer0.10_0.10.36-1.2ubuntu1_FAILEDTOBUILD.txt.gz
[09:02] <Laney> is that some known arm64 failure mode?
[09:14] <cjwatson> Laney: Yes, the APM hardware (or kernel, we're not 100% sure) isn't absolutely reliable - but the failures are AFAWCT always accompanied by dmesg indications, so infinity hacked launchpad-buildd to grep for those
[09:14] <cjwatson> Laney: I gather that one's gone wrong a few times so it may need to be built on the very-slow-but-eventually-reliable sim
[09:15] <Laney> That's the first FTBFS mail I've had about it
[09:17] <Laney> False
[09:17] <Laney> I got two at once so mentally disregarded one of them
[09:17] <wgrant> There should have been three :/
[09:18] <Laney> I'd trust your logging over my mail client
[10:39] <apachelogger> mh, could bug 1209031 be an ubuntu-desktop bug maybe? doesn't apply to any of the kde printer setup tools it seems
[10:41] <Riddell> apachelogger: I'll remove printer-applet shortly
[10:41] <apachelogger> \o/
[12:57] <ogra_> pitti, do you happen to know a way to tell dbus to ignore certain events (specifically a uevent on the system bus)
[13:00] <seb128> ogra_, what are you trying to do?
[13:00] <seb128> ogra_, do you debug/dbus-monitor or do you code?
[13:01] <ogra_> seb128, trying hard to be less desparate over bug 1234743
[13:01] <pitti> ogra_: hang on, are we talking uevents or dbus signals here?
[13:01] <pitti> (not that you could ignore either)
[13:01] <ogra_> (this isnt related to mp4 at all its happening constantly and kills the Mir sessions)
[13:01] <pitti> ogra_: uevents are emitted from the kernel through netlink, you can't really ignore them I'm afraid
[13:01] <ogra_> pitti, well do you happen to have a maguro ?
[13:01] <pitti> ogra_: no, mako
[13:02] <ogra_> ah, sad
[13:02] <ogra_> the system bus is saturated with VSYNC events from the graphics driver
[13:03] <pitti> ogra_: hm, dbus doesn't directly relay uevents
[13:03] <ogra_> and i fear the driver communication actually uses the uevents internally which means we cant disable them on the lowest level
[13:03] <pitti> ogra_: is that being done by some service, like perhaps upstart?
[13:03] <ogra_> i guess upstart guides them onto the bus yeah
[13:03] <pitti> i. e. something which listens for uevents and sends them via dbus
[13:04] <pitti> as you can use uevents as upstart conditions, that might happen; aside from that I only know the subsystem specific ones like for "block" or "power_supply" which are getting (kind of) repeated on dbus
[13:04] <diwic> seb128, hi, I'm doing some experiments with indicator-sound and I'm wondering if you know where to read debug output (or similar) from that service?
[13:04] <ogra_> http://paste.ubuntu.com/6209230/
[13:04] <ogra_> about 100/sec of these i'd say
[13:05] <pitti> ogra_: ah, so it's upstart indeed
[13:05] <ogra_> yeah :/
[13:05] <pitti> ogra_: but 100/s is a kernel bug; it will cause loads of wakeups and never let the device sleep, so I'm afraid we can't really work around that in userspace
[13:06] <ogra_> pitti, it stops as soon as the screen blanks
[13:06] <ogra_> it might only be 60/s
[13:06] <seb128> diwic, ~/.cache/upstart/dbus.log I would guess, since it's dbus activated
[13:06] <ogra_> since i think thats the vsync frequency thats hardcoded in the driver
[13:06] <pitti> ogra_: you see the same in "udevadm monitor -e --kernel" I suppose?
[13:06] <pitti> ogra_: eek, emitting a change uevent on every frame? at least that explains the frequency
[13:06] <seb128> diwic, or you can "stop unity-panel-service", stop indicator-sound-service, run it by hand and start unity-panel-service
[13:07] <ogra_> pitti, yeah, less cruft around the single message though
[13:07] <seb128> diwic, you need to stop/start ups otherwise it's going to respawn the service before you manage to run it by hand
[13:07] <ogra_> pitti, right, and i fear the binary PVR driver actually needs that
[13:07] <pitti> ogra_: that started happening with a recent kernel?
[13:07] <seb128> diwic, oh; export INDICATOR_ALLOW_NO_WATCHERS=1 if you do run by hand
[13:08] <pitti> ogra_: that would be evil, bad, and wrong.. did that just not occur to anyone else before, or did that just start recently?
[13:08] <seb128> diwic, otherwise indicator services do exit
[13:08] <diwic> seb128, thanks
[13:08] <infinity> pitti: I suspect it was done on devices that don't run udev, and no one thought of the insanity this would cause on a real Linux userspace.
[13:09] <infinity> pitti: (Not that that excuses the abuse of the interface in that manner)
[13:09] <diwic> seb128, your advice seems to work
[13:09] <ogra_> pitti, it was always there but recently got heavily exposedthrough bug 1235649
[13:09] <seb128> diwic, great
[13:09] <seb128> diwic, yw ;-)
[13:10] <pitti> ogra_: hm, so we never ran power tests on that device then, and saw that udev and upstart were spinning all the time then?
[13:10] <pitti> ogra_: *sigh* @ driver devs :/ But I honestly have no idea how to workaround it
[13:10] <diwic> seb128, my experiments, at a later stage, might need some design input before being merged, do you know who I should talk to when I get that far?
[13:11] <infinity> ogra_: have you actually tried removing the offending kernel code that omits the event to see if the PVR driver explodes?  Or are you just assuming it will?
[13:11] <seb128> diwic, try mpt I would say
[13:12] <ogra_> infinity, colin king did ... bug 1234743
[13:12] <xnox> pitti: ogra_: i thought one can apply netlink filters. And don't we simply need to filter/ignore that one in upstart-udev-bridge => and thus it will not be re-emitted as :sys:udev-event.
[13:12] <diwic> seb128, ok, thanks!
[13:12] <seb128> diwic, yw!
[13:12] <ogra_> xnox, that might be enough thats why i was asking pitti for a filter to dbus :)
[13:12] <pitti> xnox: we'd also need to ignore it in udev itself, to keep that from spinning
[13:13] <pitti> otherwise udev would constantly keep processing rules
[13:13] <pitti> that's assuming that we care even a little bit about power usage, of course
[13:13] <ogra_> infinity, my suspicion is that PVR uses the uevent to actually do syncs, which is why i look for an alternative solution
[13:14] <xnox> pitti: we care about power usage, but chopping off at udev-dridge, will save us upstart event in pid1 and re-emit over dbus to session-upstart and event there.
[13:14] <pitti> xnox: I think netlink allows you to filter by subsystem etc., but not sure it can filter out particular drivers
[13:14] <xnox> pitti: at least that should be a chunk.
[13:14] <pitti> xnox: yes, but that leaves everything else that actually listens to uevents
[13:15] <ogra_> subsystem would be rather bad
[13:15] <xnox> pitti: my impression from "documentation" by keybuk was that it's fairly flexible http://netsplit.com/2011/02/09/the-proc-connector-and-socket-filters/
[13:15] <ogra_> given the vsync comes from a platform device
[13:15] <pitti> no, we can't quiesce everything from platform
[13:16] <pitti> xnox: yeah, hence the "I'm not sure"
[13:17] <xnox> pitti: well, i haven't coded socket filters yet =) so i am also hypothetical.
[13:17] <pitti> we'd need to tell udev's netlink socket "get all uevents except that one"
[13:17] <xnox> pitti: keybuk starts with filter of "pass through nothing", then "pass through everything" and then "pick one"
[13:21] <TJ-> Can someone review the merge proposal for bug #1235162 ?
[13:23] <pitti> TJ-: can do, just not right now (queueing)
[13:23] <TJ-> pitti: Many thanks
[13:31] <ritz> cyphermox hi, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1186273
[13:31] <ritz> could this be pushed into precise
[13:34] <xnox> pitti: doesn't mir listen to that vsync udev event and needs it? thus we shouldn't be removing it at udev level? or does mir directly subscribe to kernel events (not udev events)
[13:34] <xnox> ?
[13:35] <pitti> xnox: err, what?
[13:36] <pitti> xnox: last time I talked to the mir developers they didn't even know about uevents; they do input device detection with inotify on /dev/ (!), which causes "nice" race conditions
[13:37] <xnox> pitti: interesting. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1234743/comments/11
[13:38] <xnox> pitti: unless that was fixed in powerd.
[13:38] <xnox> upload.
[13:39] <ogra_> Mir needs VSYNC
[13:39] <ogra_> but not via dbus or upstart
[13:40] <ogra_> xnox, mako does not spill these uevents (thanks to a likely saner driver) and Mir works fine there
[13:41] <pitti> ogra_: well, but I hope Mir doesn't expect VSYNC messages as uevents?
[13:41] <ogra_> no, then mako wouldnt work
[13:41] <ogra_> the dbus-monitor --system log there is pretty quiet
[13:41] <ogra_> (just some cpufreq noise)
[13:45] <pitti> tvoss: ^ any idea here? I hope Mir doesn't actually expect vsync uevents, and that's just a quirk of the maguro driver?
[13:45] <sforshee> pitti: I think it's the userspace side of the android graphics driver that's expecting the events
[13:46] <xnox> sforshee: then why is it needed with Mir?
[13:46] <xnox> sforshee: (sure it might be needed for surfaceflinger)
[13:46] <pitti> sforshee: ok; that would explain why mako doesn't have that problem, but maguro does
[13:46] <sforshee> isn't mir still using the android drivers?
[13:46] <pitti> yes, I believe it does
[13:46] <xnox> sforshee: ah, I see.
[13:46] <xnox> never mind me then.
[13:47] <sforshee> pitti, xnox: look at hardare/ti/omap4xxx/hwc/hwc.c in the android sources
[13:56] <tvoss> pitti, not really, let's cross-check with kdub once he is online, though
[14:08] <cyphermox> ritz: ack, will do soon
[14:08] <ritz> thank you
[14:17] <xnox> pitti: updated bug report with help by ogra_'s testing. Dropping that event in upstart-udev-bridge - reduces init/session-init memory usage, but systemd-udev is still spinning at like 5% CPU usage, whilst the screen is on.
[14:42] <jodh> xnox: I don't think that patch belongs in upstream as it is entirely ubuntu-specific.
[14:46] <xnox> jodh: sure, ok. i will probably have to write one for udev as well and then we will pick one.
[14:47] <jodh> xnox: I discussed yesterday a plan to allow filtering for the udev bridge, but that is somewhat unlikely to be happening in the next couple of days :)
[14:47] <lesshaste> hi..
[14:49] <lesshaste> hi
[14:49] <lesshaste> what is happening with xpdf? It is 100% broken in 13.04  but this doesn't seem to be urgent
[14:49] <lesshaste> is it now deprecated as a pdf viewer?
[14:51] <xnox> jodh: it would be nice, if we could drop some kind of udev.rules file that would do the matching and not emit the event to us.
[14:52] <jodh> xnox: yeah
[14:52] <soren> lesshaste: It was moved from main to universe in Edgy.
[14:52] <lesshaste> ah.. and universe is not supporteD?
[14:52] <xnox> jodh: replace upstart-udev-bridge with udev.rules that do initctl emit ?
[14:52] <lesshaste> I should know that
[14:52] <ritz> dobey hi, https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/926763
[14:52] <soren> lesshaste: It's sort of supported.
[14:52] <lesshaste> soren, ok.. so never working at all seems bad :)
[14:52] <ritz> could you please look this up
[14:53] <lesshaste> soren, I mean, it's not like it works for some people
[14:53] <soren> lesshaste: It comes with no guarantees. If someone feels like it, they can work on it.
[14:53] <lesshaste> soren, ok but surely it should just be removed if it is never works for anyone?
[14:53] <lesshaste> it doesn't seem good QA otherwise
[14:53] <soren> lesshaste: Sure.
[14:54] <soren> Man... I haven't used xpdf for over 6 years, probably.
[14:54] <jodh> xnox: it's a though :)
[14:55] <soren> lesshaste: Hm.. Someone seems to care about it.
[14:55] <lesshaste> ah.... https://bugs.launchpad.net/ubuntu/+source/xpdf/+bug/943195   .. status triaged for raring
[14:55] <soren> lesshaste: It's been updated half a dozen times this year.
[14:55] <lesshaste> which I assume is a precursor to actually releasing it
[14:55] <lesshaste> soren, well.. as I say.. I don't think the 13.04 version works for anyone
[14:55] <soren> lesshaste: I just tested it. It works for me.
[14:56] <lesshaste> soren, the 13.04 version?
[14:56] <soren> Oh, wait. I'm on 13.10.
[14:56] <lesshaste> aha
[14:56] <lesshaste> it would be nice if there were tests before release
[14:56] <lesshaste> it might involve some imagination for how to do that automatically I suppose
[14:56] <soren> It certainly would.
[14:56] <lesshaste> or even tests after release :)
[14:57] <soren> Oh, there were.
[14:57] <soren> You did them. Just now.
[14:57] <lesshaste> right but 13.04 is not new
[14:57] <lesshaste> it just looks bad
[14:57] <lesshaste> the report seems to be from 2012-02-29
[14:57] <lesshaste> unless I am reading the wrong date
[14:59] <lesshaste> ok so now I just need to ask someone to get it past Triage :)
[15:00] <lesshaste> where someone is Dmitry Shachnev
[15:00] <lesshaste> I think
[15:01] <lesshaste> soren, thanks in any case.. out of interest was " It certainly would." in reply to the tests before release or the imagination comment?
[15:01]  * mitya57 reads
[15:02] <mitya57> lesshaste: it's in review queue, https://launchpad.net/ubuntu/raring/+queue?queue_state=1
[15:02] <mitya57> someone from the SRU team should approve it
[15:02] <soren> lesshaste: Both, I guess.
[15:03] <lesshaste> mitya57, ok, thanks.
[15:03] <lesshaste> soren, well crashing on startup shouldn't be too  hard to test
[15:03] <lesshaste> although clearly easier for some applications than other
[15:03] <lesshaste> s
[15:04] <smartboyhw> Is somebody willing to sponsor https://launchpad.net/bugs/1236111 SRU?
[15:07] <soren> lesshaste: If xpdf was the only package in the archive, sure. There's just more than 20000 other packages to worry about.
[15:07] <mitya57> smartboyhw: shouldn't it be Type=Link instead of Type=Application?
[15:07] <soren> lesshaste: And each flavour of Ubuntu has its own recommended pdf viewer. Neither use xpdf.
[15:16] <smartboyhw> mitya57, in the current version of such line it is Application also...
[15:17] <mitya57> smartboyhw: that's wrong and it's a hack, i.e. exo-open can be not always available
[15:17] <mitya57> see http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
[15:17] <mitya57> (I've just posted that link to the bug as well)
[15:18] <smartboyhw> mitya57, what should be the correct fix then?
[15:18] <smartboyhw> Not quite getting the idea, since we've been using it...
[15:19] <lesshaste> soren, sure but does every package have at least one person who cares about it?
[15:19] <lesshaste> soren, I mean doesn't...
[15:19] <mitya57> smartboyhw: Type=Link, URL=...
[15:19] <smartboyhw> mitya57, OK
[15:20] <mitya57> Also I can't find that file in the current bzr branch
[15:20] <mitya57> Was it renamed?
[15:20] <smartboyhw> mitya57, yes, renamed to ubuntustudio-help.desktop (same dir)
[15:20] <lesshaste> soren,   you make it sound like one person would have to write a test for all the packages which I agree would not be realisttic
[15:22] <mitya57> smartboyhw: http://paste.ubuntu.com/6209737/
[15:22] <mitya57> that's lp:ubuntustudio-default-settings
[15:22] <smartboyhw> mitya57, ok, I mean the quantal version-.-
[15:22] <smartboyhw> Saucy version moved to another pacakge
[15:22] <smartboyhw> (ubuntustudio-menu)
[15:22] <smartboyhw> (Same thing still, anyhow)
[15:23] <mitya57> Ah, well, anyway from changelog I see we should ask Len Ovens if there was any reason for using exo-open
[15:26] <smartboyhw> mitya57, please check the new debdiff
[15:26] <smartboyhw> mitya57, I'll talk to OvenWerks on this
[15:26] <mlankhorst> ping, can anyone accept my mesa 9.1.7 uppload to raring-proposed?
[15:27] <mitya57> smartboyhw: thanks, better now. Does it work?
[15:27] <smartboyhw> mitya57, wait, need to boot up a VM...
[15:27] <mitya57> yes, it would be nice if you tested it before I upload it :)
[15:30] <smartboyhw> mitya57, doesn't work, it says it can't execute the child process
[15:30] <mitya57> what's the error message?
[15:30] <smartboyhw> (no such file or directory!?)
[15:30] <smartboyhw> Probably need a url prefix
[15:31] <smartboyhw> (or that sort of thing)
[15:31] <smartboyhw> mitya57, ah, my fault
[15:31] <smartboyhw> mitya57, ACK, tested
[15:32] <lesshaste> soren, just in case it is interesting.. it seems you can test things using http://mywiki.wooledge.org/BashFAQ/068 plus echo $?
[15:32] <mitya57> smartboyhw: uploaded
[15:32] <lesshaste> 139 means SIGSEGV
[15:36] <roaksoax> jdstrand: howdy! quick question about apparmor. So a package postinst is running apparmor_parser, however, installing this package from the installer fails with a message: "Warning: unable to find a suitable fs in /proc/mounts, is it mounted?"
[15:36] <roaksoax> any ideas?
[15:37] <jjohansen> roaksoax: apparmor uses securityfs
[15:37] <jjohansen> so you need to mount securityfs to be able to load policy
[15:37] <smartboyhw> mitya57, thank you
[15:37] <roaksoax> jjohansen:
[15:37] <roaksoax> jjohansen: right, but obviously during the install we don't do that.. do we?
[15:37] <smartboyhw> And thank you for the guidance:)
[15:38] <roaksoax> jjohansen: is there any other package that you know of that does that on install? (uses apparmor_parser)
[15:39] <jdstrand> roaksoax: anything that ships apparmor policy. cups, mysql, bind, etc
[15:40] <jdstrand> roaksoax: most use dh_apparmor to run apparmor_parser in postinst
[15:41] <roaksoax> jdstrand: so I guess a apparmor_parser XYZ || true would solve my issue during install
[15:41] <roaksoax> jdstrand: so I guess a "apparmor_parser XYZ || true" (adding the || true) would solve my issue during ISO install
[15:42] <roaksoax> jdstrand: and on reboot, the profile will be loaded?
[15:43] <jdstrand> roaksoax: that would, yes. what are you adding a profile to?
[15:44] <roaksoax> jdstrand: maas-dhcp has the apparmor profile, and since it is now being installed on CD install, it was failing due to the lack of the "|| true
[15:45] <jdstrand> roaksoax: take a look at /var/lib/dpkg/info/tcpdump.postinst and /var/lib/dpkg/info/tcpdump.postrm for what dh_apparmor does
[15:45] <jdstrand> roaksoax: I might suggest just using dh_apparmor
[15:46] <roaksoax> jdstrand: will do! thanks!
[16:03] <slangasek> zyga: hey, any luck with that new mountall?
[16:04] <zyga> slangasek: hey, I was busy all day with Qt, I'll finish my daily work and try mountall soon
[16:04] <zyga> slangasek: I wanted to wait till you're around anyway :)
[16:04] <slangasek> ok
[16:21] <roaksoax> jdstrand: so does this make sense to you? http://paste.ubuntu.com/6209989/
[16:24] <doko> pitti, https://launchpadlibrarian.net/152857384/buildlog_ubuntu-saucy-arm64.postgresql-9.1_9.1.9-5_FAILEDTOBUILD.txt.gz   I thought I did update that, could you have a look (out of date config.*)
[16:27] <jdstrand> roaksoax: without testing it, it does, however, I think that /etc/apaprmor.d/usr.sbin.dhcpd is already shipped by isc-dhcp-server
[16:28] <roaksoax> jdstrand: yeah it is, we only install something in /etc/apparmor.d/dhcpd.d/maas
[16:28] <roaksoax> jdstrand: and rerung the dhcpd profile
[16:28] <roaksoax> so maybe no need to use dh-apparmor
[16:29] <jdstrand> roaksoax: ah, yes. dh_apparmor is for a full profile, not a profile snippet
[16:29] <jdstrand> roaksoax: sorry, I didn't realize
[16:29] <roaksoax> jdstrand: no worries :) thanks though!
[16:29] <jdstrand> roaksoax: using '|| true' with apparmor_parser is reasonable though-- that is what dh_apparmor does
[16:31] <roaksoax> jdstrand: yup! that's what I did! thanks
[17:37] <slangasek> seb128: 1200775> sorry, I don't think we have any spare cycles to work on that right now :/
[17:38] <seb128> slangasek, :-(
[17:38]  * seb128 misses mvo
[18:02] <seb128> speaking of mvo ;-)
[18:02] <seb128> mvo, hey!
[18:02] <mvo> hey seb128!
[18:02] <seb128> mvo, wie gehts?
[18:03] <mvo> seb128: great, thanks! just optimized a "program" with a student of mine, we got from 37min runtime to 3sec :P and now I relax with some apt merges
[18:03] <seb128> ahah
[18:03] <mvo> seb128: and you?
[18:03] <seb128> mvo, I'm good thanks! things are bit crazy before release, as usual
[18:03] <mvo> seb128: I vaguely remember that, indeed !
[18:04] <seb128> mvo, I was trying to see if slangasek had somebody to look at bug #1200775 (update-manager changes that made apturl unhappy)
[18:04] <mvo> seb128: but it looks very good AFAICT, all my machines run saucy since days
[18:04] <mvo> (eh, weeks/months depending on the machine)
[18:04] <mvo> seb128: let me see
[18:04] <seb128> mvo, but there isn't anyone, which lead me to say "/me misses mvo", just before you joined ;-)
[18:04] <seb128> mvo, danke
[18:22] <mvo> seb128: hrm, more tricky than i had hoped, but I make some progress
[18:23] <seb128> mvo, ;-)
[18:53] <stgraber> dobey: so is that waste of buildd time really necessary?
[18:54] <dobey> yes
[22:54] <wolter> Any software-properties developer here? I am trying to modify add-apt-repository to accept comments but I am running into problems with sys.stdout.detach (file object has no method detach)
[22:56] <sarnold> wolter: oof, looks like a python2 vs python3 deal: https://wiki.python.org/moin/PortingPythonToPy3k
[23:10] <wolter> sarnold: sure that was the problem! Thanks. I couldn't test it anyway because the trunk version seems to be very different and incompatible with my current system
[23:11] <sarnold> wolter: woo :)
[23:11] <wolter> (I will just upload a branch and have the devs test it if they will.)
[23:11] <wolter> For enthusiasts, lp:~wolterh/+junk/add-apt-repository-comments