[00:38] <cody-somerville> Hey. Are there any fellow DMB members kicking around with a few minutes to spare?
[00:40] <directhex> Laney?
[03:09] <slangasek> pitti: I would be interested in your input on bug #722933
[03:21] <Chipzz> slangasek: if you want my 2c, the correct solution is to walk the dependency chain when creating those symlinks
[03:21] <slangasek> Chipzz: what dependency chain?  You mean look at packages outside the current build?
[03:21] <Chipzz> I mean
[03:22] <Chipzz> libfoo-dev: depends: libfoo
[03:22] <Chipzz> the symlink should be from libfoo-dev to libfoo
[03:23] <slangasek> that's what it already does
[03:23] <slangasek> but it does so inconsistently where arch: all packages are concerned
[03:24] <Chipzz> sorry, rather late here and I didn't think my comment through 100%
[03:24] <Chipzz> probably should have shut up and not wasted your time ;)
[03:24] <slangasek> no worries... :)
[03:25] <Chipzz> trying to recall the difference between arch: all and arch: any at 4AM tends to not be very productive ;p
[03:25] <Chipzz> I always get these 2 mixed up
[03:26] <Chipzz> the similarity between the 2 words is rather unfortunate
[03:39] <ScottK> Chipzz: All means one package works on all archs (~same as rpm noarch).  Arch any means you can build the package for any arch, but you have to built it for that arch.
[03:40] <Chipzz> ScottK: yeah, I can recall when I look it up :) the problem is having to look it up
[03:40] <Chipzz> which I didn't at 4AM ;P
[03:40] <ScottK> Once I started thinking of it like that ^^^ I was finally able to remember it.  YMMV.
[03:41] <Chipzz> I just thought of a better way ;)
[03:42] <Chipzz> .all.deb is sth that exists, .any.deb doesn't
[03:42] <Chipzz> so all refers to the archs it will be able to installed on
[03:42] <Chipzz> +be
[04:43] <poolie> scottk, hi
[04:44] <poolie> thanks for your feedback
[04:44] <ScottK> poolie: Hello.
[04:44] <poolie> i think a debian/control field would work well
[04:44] <poolie> i'm just wondering how that would come to be set on a package: who would decide about it?
[04:45] <ScottK> I think that can be decided on a team by team basis.
[04:46] <ScottK> In my mind there's a huge difference between "Hey, if you don't use UDD someone will come and hunt you down if you didn't have a really good reason" and the package upload is impossible.
[04:46] <poolie> right
[04:46] <ScottK> As long as it's put in debian/control and not hard coded in launchpad somewhere, we can iterate on how best to manage it.
[04:47] <poolie> and, indeed, there's another one to the left of that which is "let's make sure there's a bug explaining why it wasn't or couldn't be used"
[04:47] <ScottK> Perhaps.
[04:47] <poolie> well, it can be on the server and still controllable by teams
[04:48] <ScottK> Perhaps, but I think the package is a more natural place to find it.
[04:48] <poolie> ok
[04:48] <poolie> one draw back is that it would take one update per package to flip it
[04:48] <poolie> perhaps that's not a big deal
[04:48] <ScottK> If it's a package someone wants to set this on, I doubt it's a big deal.
[04:49] <ScottK> It'll be getting uploaded anyway.
[04:49] <ScottK> I don't know about the need for filing a bug.  Most of the reasons I can think of for not using UDD with such a package are very tactical: trying to get an ISO to build and needed to push a quick fix and didn't want to mess with bzr.
[04:50] <poolie> ok
[04:50] <ScottK> For packages where UDD is problematic (e.g. kernels),  the flag won't be set anyway.
[04:50] <poolie> can you tell me more about the "trying to get an iso to build" case?
[04:50] <ScottK> Just an example where time is of the essence.
[04:51] <poolie> ok
[04:51] <poolie> i'll update the lep to suggest that then
[04:51] <ScottK> Thanks.
[04:51] <poolie> should that warning come from dput, or soyuz, or maybe somewhere else?
[05:00] <broder> poolie: do you think it's reasonable to assume that any package that a team wants built solely from branch will also be carrying ubuntu changes?
[05:00] <broder> i guess if you need to build from a branch in the first place you almost certainly have a change of some sort
[05:06] <poolie> broder, it seems likely
[05:07] <poolie> though, i guess, that policy could carry over from one ubuntu cycle to the next even if there are no new changes from debian
[05:07] <broder> oh look, someone beat me to the punch on-list
[05:11] <ScottK> poolie: I'd suggest from dput parsing the .changes file.
[05:20] <poolie> scottk, that seems reasonable
[05:21] <poolie> as i said on the list this is not the first thing we need
[05:21] <poolie> i guess it's good to know there's a way to do it eventually
[05:21] <poolie> perhaps it should have been removed from the lep
[05:21] <ScottK> Right, just recognize that some people are going to go ballistic at anything that smells of making this mandatory.
[05:22] <poolie> i know :)
[05:23] <poolie> i'd almost rather have it out there and answer it than have them suspect though
[05:23] <poolie> success for me here means having people use it and like it, not having them use it at any cost
[05:28] <ScottK> I suspect that for people who tend to touch the same package or a few over and over this is a relatively easy sell.  For people who work on different packages all the time, I think it's going to be harder because branching performance is more important.
[05:29] <poolie> right
[05:29] <poolie> we've worked on that and we'll do more
[05:29] <poolie> the idea that came up in January was basically that for people who _can_ use it, we ought to connect the dots all the way through
[05:30] <ScottK> Which makes sense.
[05:35] <poolie> then we can come back and make things smoother or faster
[06:07] <ohsix> UDD?
[06:07] <StevenK> Ubuntu Distributed Development
[06:55] <pitti> Good morning
[06:58] <pitti> slangasek: as we don't have access to the arch:all binaries on !i386, I don't see another way than the one you proposed
[07:10] <pitti> slangasek: is there any documentation about this "Multiarch: foreign" field? it seems very weird to me that you have to mark an arch:all package with that (regardless of what it does)
[07:22] <slangasek> pitti: https://wiki.ubuntu.com/MultiarchSpec
[07:22] <slangasek> pitti: specifically, https://wiki.ubuntu.com/MultiarchSpec#Dependencies%20involving%20Architecture:%20all%20packages
[07:25] <pitti> ah, thanks; I wonder why this isn't already the implicit default behaviour for arch:all packages then
[07:27] <slangasek> pitti: because of the explanation given there - existing packages can assume that the dependencies of the arch: all package are fulfilled by packages of the same architecture (think python + python extensions)
[07:28] <slangasek> so if we suddenly change the behavior and let the dependencies be satisfied by packages from other architectures, things will break
[07:32] <cdbs> @pilot in
[07:41] <tjaalton> slangasek: you probably want the libx11 multiarch change to ubuntu as well? i've got a merge ready, could pull that in too
[07:42] <tjaalton> oh
[07:42] <tjaalton> it was uploaded already :)
[07:50] <slangasek> tjaalton: yeah; I didn't want to step on anyone's toes by merging, but as I'm going to be looking at quite a lot of the X library stack in the coming days, if there are other libs you'd like me to merge up I'm happy to do so :)
[08:01] <tjaalton> slangasek: there shouldn't be any left, a bunch of them were synced on friday, and only a couple of them have ubuntu changes
[08:01] <tjaalton> so push the changes to debian and then we can sync again
[08:01] <tjaalton> depending on the package
[08:01] <tjaalton> slangasek: http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
[08:02] <tjaalton> that shows which packages have changes
[08:02] <slangasek> tjaalton: right, I'll be pushing these changes directly to Debian first; there probably aren't too many packages I can actually change for this round, most of my work is still staged in ppa
[08:03] <didrocks> good morning
[08:07] <tjaalton> slangasek: okay
[08:20] <dholbach> good morning
[08:21] <kklimonda> 05:49           ScottK | It'll be getting uploaded anyway.
[08:21] <kklimonda> 05:49           ScottK | I don't know about the need for filing a bug.  Most of the reasons I can think of for not using UDD with such a package are very tactical: trying to get
[08:21] <kklimonda>                        | an ISO to build and needed to push a quick fix and didn't want to mess with bzr.
[08:41] <cdbs> @pilot out
[08:47]  * dholbach hugs cdbs
[08:47] <dholbach> patch pilots FTW!
[08:59] <cdbs> thanks dholbach
[09:00] <cdbs> dholbach: probably my last session of patch piloting before my exams :(
[09:00] <dholbach> cdbs, all the best with your exams!
[09:00] <cdbs> thanks dholbach
[09:13] <debfx> RAOF: X doesn't crash anymore with you packages, thanks :)
[09:13] <RAOF> debfx: Awesomeo.
[09:35] <ricotz> bdrung, hi
[09:36] <bdrung> hi
[09:36] <ricotz> bdrung, you looked at the current debian/changelog, and you are not happy with what is looks like?
[09:36] <bdrung> (stupid focus)
[09:38] <ricotz> bdrung, using a new "*" doesnt look right to me
[09:38] <bdrung> ricotz: yes
[09:39] <bdrung> ricotz: why not?
[09:39] <ricotz> has this something to do with make it work with a script?
[09:39] <bdrung> ricotz: no, it's just common practice.
[09:40] <ricotz> i my opinion it is a change to the debian packaging
[09:40] <ricotz> so if there were only one commit you would have been happy with it?
[09:41] <bdrung> no, it's not the number of commits.
[09:41] <bdrung> look for example at http://packages.debian.org/changelogs/pool/main/p/portaudio19/current/changelog
[09:41] <ricotz> since it is going to be merged to the real branch, the commit message can be pretty
[09:42] <ricotz> bdrung, ok, this is done with git-dch?
[09:42] <bdrung> ricotz: it's not about commit messages, it's about what's in debian/changelog
[09:42] <ricotz> there are many styles to list the changes of a package
[09:43] <bdrung> one "*" for every distinct change. you did two: keep the remaining changes from last merge and drop the win32 package
[09:44] <ricotz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gnupg/natty/revision/29/debian/changelog
[09:44] <bdrung> the drop of the win32 package is not a subitem of "remaining change"
[09:45] <bdrung> re the link: that were all remaining changes
[09:45] <ricotz> https://launchpad.net/ubuntu/lucid/+source/gzip/+changelog
[09:46] <ricotz> gzip (1.3.12-9) unstable; urgency=high
[09:46] <bdrung> http://changelogs.ubuntu.com/changelogs/pool/universe/v/vlc/vlc_1.1.7-1ubuntu1/changelog
[09:46] <tkamppeter> pitti, hi
[09:47] <bdrung> ricotz: there we have one old change "build and install the libx264 plugin" and a new one "v4l is gone from the kernel. Build only v4l2."
[09:47] <ricotz> bdrung, have you looked a the gzip one?
[09:48] <ricotz> https://launchpad.net/ubuntu/natty/+source/cpio/+changelog
[09:48] <ricotz> bdrung, ^ this might be the most recent example
[09:49] <ricotz> which is the same thing
[09:50] <bdrung> ricotz: look at cpio 2.9-13ubuntu1 -> http://changelogs.ubuntu.com/changelogs/pool/main/c/cpio/cpio_2.11-6ubuntu1/changelog
[09:50] <bdrung> ricotz: since that version, it is a "remaining change"
[09:51] <ricotz> bdrung,  now i see what you mean
[09:52] <ricotz> bdrung, ok :), i will change this, anything besides that?
[09:52] <bdrung> ricotz: probably not
[09:59] <ricotz> bdrung, done
[10:08] <bdrung> ricotz: uploaded
[10:10] <ricotz> ricotz, thanks
[10:11] <bdrung> soliloquy :)
[10:14] <ricotz> i mean, bdrung, thanks ;)
[10:26] <lifeless> erm
[10:26] <lifeless> 2363 robertc   20   0 1182m 694m 1844 S    0  9.1   4:03.13 gnome-power-man
[10:26] <lifeless> -not cool-
[10:27] <persia> When managing power, the first step is accumulation: only once all power is claimed can it be distributed to others (and even that is risky)
[10:29] <cjwatson> gnome-power-robin-hood
[10:30] <ogra> accumulated power can get risky though (see lybia)
[10:31] <ogra> Riddell, ScottK, so what about QT ? FF is soon and there only seems to be a symbian related bug holding it up, could we get a package before FF ?
[10:33] <persia> ogra: Isn't the difference between 4.7.1 and 4.7.2 covered by the "Upstream microreleases" clause from https://wiki.ubuntu.com/FeatureFreeze ?
[10:34] <ogra> might be, my concern is that we are waiting for a feature we need to test asap
[10:36] <Riddell> ogra: feel free to package a git snapshot, I'll package 4.7.2 when it's out but I don't have time or need to do anything before
[10:37] <ogra> hmm
[10:37] <ogra> k
[10:37] <ogra> Riddell, just be aware that if NEON runtime detection doesnt work and we dont get a fix in by release i will have to turn it off statically again
[10:38] <ogra> to my knowledge it hasnt been tested upstream and the bugfix is only based on assumptions
[10:44] <mok0> I'm looking for a program that will accept input from stdin (from a GTK app) and display it in a window
[10:47] <persia> mok0: zenity?
[10:47] <mok0> persia: hm, don't know that one... let me check it out
[10:47] <persia> (you might have to fiddle a bit with redirects and such, but ...)
[10:48] <mok0> persia: the problem is, this graphical app outputs a lot of error info and such via stdout, but you don't see that if the app is started from the menu
[10:48] <persia> (unless you look in .xsession-errors)
[10:49] <persia> That sounds like the application itself needs to be fixed.  It oughtn't do that.
[10:49] <persia> Wrapping in a display tool doesn't strike me as ideal.
[10:49] <mok0> persia: me neither
[10:50] <mok0> persia: I could pipe the output to a file in the users home dir, but that doesn't strike me as ideal either
[10:50] <persia> That's already implemented: .xsession-errors
[10:50] <mok0> persia: heh I completely forgot about that
[10:51] <mok0> persia: haven't worried about .xsession-errors for years
[10:51] <persia> The application is still buggy, but if you're digging for the output for some reason, it is saved locally.
[10:51] <mok0> persia: I suppose it is partly to help developers
[10:51] <Riddell> ogra: yeah, with KDE not compiling on ARM, Qt on ARM isn't much of a priority for me :(
[10:52] <ogra> tell that to the unity guys
[10:52] <mok0> persia: this program embeds Python, and the user is free to create scripts and so on; these output stuff on stdout
[10:53] <Chipzz> seems like the output is not properly redirected then
[10:53] <persia> Ah, that's a different issue.  That ought be trapped, etc.  File an upstream bug: help them there if you have interest, as this will surely be invasive.
[10:55] <mok0> persia: I am working with them already, but I doubt they would give it any priority. It's quite slow to get even small patches accepted
[10:56] <persia> Well, architecturally, I'd probably approach the solution as follows: 1) trap stdout in the launched python scripts, and redirect to some internal buffer
[10:56] <persia> 2) Add some window or view that allows users to view the internal buffer (or perhaps just some window into it)
[10:56] <mok0> persia: hm, xconsole might do the job
[10:57] <persia> 3) Add some control to show/hide the window/view
[10:57] <mok0> persia: I agree that would be a good solution. But, as I said, I doubt the developer(s) would give it any priority.
[10:58] <persia> xconsole doesn't seem like an ideal solution: you'd still have to trap/redirect stuff to /dev/console rather than inherited STDOUT (.xsession-errors), *AND* you break if someone has an actual device attached to /dev/console
[10:58] <mok0> persia: I think you can run xconsole with a different device, using the --file switch
[11:00] <persia> You're planning to initiate a new pty?
[11:00] <mok0> persia: no, just wondering if it might work using a file
[11:01] <persia> It won't: read the manpage.  "This does not work on regular files ..."
[11:01] <mok0> persia: it actually does
[11:02] <mok0> persia: if I append to the file (using cat >> ) it appears in xconsole
[11:02]  * persia would be very suspicious and check the code path when the manpage says "this does not work" but it appears to work: there's probably N subtle bugs
[11:02] <mok0> but ugghh it's ugly :-)
[11:03] <mok0> persia: yes. It's a bad solution anyway
[11:03]  * mok0 ponders if he could use the notification system :-/
[11:04] <mok0> persia: I would also have to deal with shutting down xconsole when the user quits the program. That would be quite hacky
[11:05] <persia> Not if you write a good wrapper.  Parent opens xconsole child, then opens other child, and waits.  When other child exits, send signal to xconsole.
[11:06] <persia> Annoying in shell, but not hard in other languages.
[11:07] <mok0> Could probably be done in Python ...
[11:12] <persia> http://docs.python.org/library/subprocess.html
[11:12] <pitti> hey tkamppeter
[11:13] <mok0> persia: then I might as well write a wrapper program that opens a nicer window
[11:14] <persia> Indeed :)
[11:15] <mok0> persia: Hm, I'll give it a thought. Seems like a nicer solution. There are other issues as well. The program is designed for users to navigate to their working directory, and then invoke the program from the CLI
[11:16] <mok0> persia: then it tries to read status files in that dir when starting
[11:17] <mok0> persia: but perhaps I can deal with that using python magic :-)
[11:32] <tkamppeter> pitti, around?
[11:34] <pitti> tkamppeter: yes; I was out for some errands and an appointment
[11:40] <tkamppeter> pitti, I succeeded that the Debian maintainer accepted all my Ubuntu changes into the Debian package of foo2zjs (except apport hook). Now I want to merge back the Debian package before FF, but it does not appear on https://merges.ubuntu.com/f/. Will there still be a refresh before FF?
[11:41] <tkamppeter> pitti, if not, is there a program for merging the debian/changelog? I do not want to do this manually.
[11:41] <pitti> tkamppeter: it's supposed to run
[11:41] <pitti> tkamppeter: you could try your luck with the new world's UDD branches
[11:41] <pitti> tkamppeter: i. e. check out lp:ubuntu/fo2zjs and bzr merge lp:debian/foo2zjs
[11:41] <pitti> (if the latter is current)
[11:42] <tkamppeter> pitti, what are the "new world's UDD branches"?
[11:42] <Chipzz> tkamppeter: I don't know how practical this is for merging changelogs, but I have found vimdiff invaluable in the past for merging various other things
[11:42] <pitti> tkamppeter: using bzr merge on the ubuntu/debian imported branches
[11:42] <Chipzz> (if you know how to drive it, which isn't very dificult)
[11:42] <pitti> tkamppeter: "bzr lp-open lp:debian/foo2zjs" -> hm, this looks out of date
[11:44] <pitti> tkamppeter: personally, in these cases I just write a detailled summary of "Remainign Ubuntu changes:" into the changelog, and drop the older stuff
[11:44] <tkamppeter> pitti, packages.debian.org already shows it and AFAIK the upload was Sunday.
[11:44] <pitti> tkamppeter: as this is only the apport hook now, that's easy to do
[11:44] <pitti> tkamppeter: the Debian changelog has the other changes from us already, after all
[11:44] <pitti> and the older changelogs remain on Launchpad as well, so they aren't lost
[11:45] <pitti> tkamppeter: i. e. take the Debian package, add the apport hook, and that's it
[11:45] <pitti> tkamppeter: btw, if you can commit to the debian repo, you could commit the apport hook there as well, and only install it when building under Ubuntu
[11:45] <tkamppeter> pitti, OK, then I will simply do it this way.
[11:46] <pitti> tkamppeter: http://git.debian.org/?p=pkg-utopia/udisks.git;a=blob;f=debian/rules;h=82db4040c633833183d2f42576758ebbdba95152;hb=HEAD
[11:46] <pitti> tkamppeter: line 27 to 29
[11:46] <pitti> erm, 25 - 28
[11:47] <tkamppeter> pitti, what is planned for the future is that I will make packages for Debian where someone at Debian sponsors the upload and after a certain amount of such uploads they want to make me DM, and then one lets all packages auto-sync in Ubuntu. WDYT?
[11:48] <pitti> tkamppeter: that sounds great
[11:48] <pitti> tkamppeter: that's what I do as well with most of my packages
[11:50] <tkamppeter> pitti, so if in some time they will avaluate my DM approval, please add a good word for me.
[11:50] <pitti> my pleasure!
[11:50] <tkamppeter> pitti, thanks for the help.
[12:30] <lamont> ScottK: postfix_2.8.0-1~build1 uploaded to natty
[12:31] <lamont> freshening things to build for sid now
[12:32] <cjwatson> slangasek: I multiarch-foreign-ified binfmt-support in unstable - hope I did it right
[12:32] <cjwatson> will sync into Ubuntu in a bit
[14:01] <mdz> pitti, can you tell me what this retracer error means? https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/720895
[14:06] <seb128> mdz, it means the retracing didn't give a valid stacktrace
[14:07] <mdz> seb128, can we guess why?
[14:07] <mdz> it seems to be happening with a number of bluetooth-applet crashes
[14:07] <pitti> hey mdz
[14:07] <seb128> #2  0x00007ffffe672e70 in ?? ()
[14:07] <seb128> No symbol table info available.
[14:07] <seb128> those symbols are lacking
[14:07] <seb128> let me look at the procmaps
[14:07] <pitti> mdz: that's a bit misleading indeed, as the obsolete package really doesn't contribute to the stack trace being bad
[14:08] <pitti> mdz: but all in all it's better to err on this side rather than keeping bugs with useless stack traces open
[14:08]  * pitti checks the logs
[14:09] <seb128> mdz, the libdbusmenu debug symbols didn't work it seems
[14:09] <pitti> what the heck, it's missing two metric tons of debug symbols
[14:09] <seb128> pitti, the only revelant ones a libdbusmenu-glib3-dbgsym missing
[14:09] <pitti> http://paste.ubuntu.com/570585/
[14:10] <pitti> oh, wait, this is misleading
[14:10] <pitti> that's noise added by a recent patch, that tries to find both -dbg and -dbgsym
[14:12] <seb128> pitti, can you see what libdbusmenu versions were installed?
[14:12]  * pitti fixes that in trunk
[14:13] <seb128> pitti, fix what? the -dbg thing?
[14:13] <pitti> seb128: the confusing warnings about missing -dbg packages
[14:14] <pitti> seb128: I can't see the installed libdbusmenu versions in the log, but it tries to install the one from Dependencies.txt
[14:14] <pitti> libdbusmenu-glib3 0.3.97-0ubuntu3
[14:15] <seb128> pitti, can you see what dbgsym was brough in?
[14:15] <seb128> there was no version changes for some days before that crash
[14:15] <seb128> the ddeb binaries should have been current and working
[14:15] <seb128> or we are back to the gdb failing to load symbols issue we discussed yesterday
[14:16] <pitti> http://ddebs.ubuntu.com/pool/main/libd/libdbusmenu/ even has both still
[14:16] <pitti> seb128: if it's too old gdb, then it's a different breakage; https://i64539621.restricted.launchpadlibrarian.net/64539621/Stacktrace.txt doesn't complain anywhere about DWARF opcodes
[14:17] <seb128> mdz, can you trigger that crash easily?
[14:17] <mdz> seb128, it happens pretty regularly, debugging with cyphermox right now
[14:17] <mdz> but on the phone
[14:17] <seb128> ok
[14:18] <seb128> mdz, can you submit the crash and give me the number before it's retraced if you have a chance?
[14:18] <seb128> mdz, I want to try to retrace it manually to see what's going on
[14:18] <mdz> seb128, it may not be the same one but my most recent crash is https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/723166
[14:18] <seb128> mdz, I was going to suggest opening also a but with a stacktrace, seems a libdbusmenu issue
[14:18] <seb128> but->bug
[14:18] <seb128> then we can ping ted about it
[14:19] <seb128> but if cyphermox is debugging it that works as well
[14:21] <pitti> seb128: just telling him how to get to mdz's unretraced bug and how to use apport-retrace
[14:21] <seb128> pitti, I want to figure why the retracing is failing
[14:22] <seb128> pitti, debug symbols work locally, I've been doing indicator valgrind and gdb logs recently and didn't get issues
[14:22] <pitti> that'd be great; good luck!
[14:22] <seb128> danke
[14:22] <pitti> seb128: you could locally install gdb 6.8 and see whether that makes it fail?
[14:22] <pitti> as a first step for bisecting where the problem is
[14:22] <seb128> pitti, ok
[14:23] <pitti> seb128: if it's 6.8, then I'll move back the gdk-pixbuf and udisks issues that'd be next in my queue, and start debugging that in the fakechroots
[14:29] <seb128> why the heck isn't the apport-retrace auth thing working on the retracers
[14:30] <seb128> ok, let me downgrading gdb locally first
[14:30] <pitti> seb128: apport-chroot login --auth $HOME/.lpcookie chroots/natty.tar.gz
[14:30] <pitti> seb128: --auth needs an absolute path, that's a common trap
[14:30] <seb128> pitti, I did that
[14:30] <seb128> and then apport-retrace --auth /tmp/auth
[14:30] <pitti> right
[14:30] <pitti> cat /tmp/auth works?
[14:30] <pitti> if you use e. g. --auth ../.lpcookie, it'll fail
[14:31] <seb128> pitti, ok, that was it, thanks
[14:32] <pitti> seb128: fixed apport-chroot in bzr for doing os.path.abspath() now
[14:33] <seb128> pitti, thanks
[14:43] <ricotz> pitti, hi, could you look at the libbluray package in upload queue?
[14:47] <pitti> ricotz: which queue?
[14:48] <ricotz> pitti, natty new queue
[14:49] <pitti> seb128: hm, gdk-pixbuf builds just fine here locally..
[14:49] <pitti> ricotz: maybe later today, after meetings
[14:49] <pitti> natty queues are usually done by the archive admins
[14:50] <ricotz> pitti, alright, thanks
[14:50] <seb128> pitti, it might be using system libraries for itself or something?
[14:50] <seb128> pitti, it built fine there as well before I uploaded
[14:50] <pitti> right, that was my idea; I'll try to remove them first
[14:50] <seb128> ricotz, Riddell is archive admin of the day
[14:51] <ricotz> seb128, thx
[14:51] <ricotz> Riddell, could you take a look at the libbluray package in the natty new queue it will be needed to build a bluray-capable mplayer
[14:52] <Riddell> ricotz: I'll be doing New queue reviews shortly
[14:52] <ricotz> Riddell, thanks
[14:53] <pitti> seb128: ah, there; that was it, building against libgdk-pixbuf2.0-dev
[14:53] <seb128> pitti, ok, explains why it works locally
[14:57] <doko_> mterry: about 555901, I opened it myself, I can't review it
[15:00] <mterry> doko_, oh, must have missed that
[15:03] <Riddell> mterry: could bug 718774 get some love?  we have a feature freeze deadline coming
[15:07] <mterry> Riddell, sorry, I've been doing feature freeze stuff of my own.  I can look at it today
[15:07] <raphink> hi there :-)
[15:08] <Riddell> hi raphink
[15:08] <raphink> what's up?
[15:08] <Riddell> feature freeze in two days!
[15:08] <raphink> I know Riddell
[15:09] <raphink> trying to get some people motivated to release augeas 0.8.0 before so I can upload it :-)
[15:29] <Riddell> mpoirier: ** linux-n900 could not be accepted due to The source linux-n900 - 2.6.35-1.1 is already accepted in ubuntu/natty and you cannot upload the same version within the same distribution
[15:30] <mpoirier> persia: ^^^^^^^
[15:30] <Riddell> I accepted the first upload and rejected the second
[15:35] <vila> cjwatson: after banging my head for quite some... time, I finally came across: http://paste.ubuntu.com/570627/
[15:36] <vila> cjwatson: I'm more than willing to add my own thanks but I still don't understand what is going on
[15:37] <vila> cjwatson: are such handlers inherited ? The case at hand is a python process spawning a shell itself spawning a 'yes' process
[15:38] <vila> cjwatson: if I kill the shell, it turns into a zombie but the the parent python process can still read the 'y' sent by the 'yes' process 8-/
[15:38] <siretart> who rejected libbluray in NEW and why?
[15:39] <cjwatson> vila: signal dispositions set to SIG_IGN are preserved across fork and execve
[15:39] <vila> cjwatson: if I use the subprocess_setup in the paste above, the 'yes' dies with the shell... I'm probably close to understanding why but... not there yet
[15:39] <Riddell> siretart: https://lists.ubuntu.com/archives/ubuntu-archive/2011-February/039665.html
[15:39] <cjwatson> vila: meeting, I'll get back to you in a bit
[15:39] <vila> cjwatson: ok
[15:39] <siretart> Riddell: ah, I see. thanks
[15:40] <siretart> ricotz: I guess you are already on it?
[15:41] <ricotz> siretart, hi, actually not, should have looked the copyright file :(
[15:42] <siretart> ricotz: I'm pretty busy today with work stuff. do you have time to have a look?
[15:43] <ricotz> siretart, not sure, was it accepted in debian?
[15:43] <siretart> ricotz: still in NEW
[15:43] <hyperair> DktrKranz: ping. got a moment to look at a NEW banshee-community-extensions? ;-)
[15:44] <siretart> ricotz: if you can, please fix it in our git and upload from there. or ping me or someone to upload
[15:45] <ricotz> siretart, ok, will see if i have some time
[15:46] <ScottK> lamont: Coolness.  Thanks.
[15:46] <mdz> is there a bug open about the excessive U1 notifications in natty? I get them constantly
[15:49] <Riddell> ogra: W: libqtdee2: breaks-without-version libqtdee1
[15:50] <hyperair> DktrKranz: actually forget it, we have new extensions, so wait til 1.9.4
[15:50] <pitti> ? shouldn't different sonames be coinstallable?
[15:50] <lamont> pitti: that is sort of why we have sonames in package names
[15:51] <ogra> Riddell, thanks
[15:52] <Riddell> pitti: the package contains some data files
[15:52] <pitti> ah, that should be moved to a -common package then
[15:52] <seb128> pitti, ok
[15:52] <seb128> pitti, http://paste.ubuntu.com/570635/
[15:52] <seb128> pitti, on the same return process locally with gdb 6.8 and7.2
[15:52]  * ogra is currently busy with libqtbamf, i'll care for qtdee afterwards
[15:54] <pitti> seb128: ok, so I'll sit down and have a deep look at this gdb 7.2 breakage after the TB meeting
[15:56] <pitti> seb128: which bug # were you using for testing again? (in the fakechroots)
[15:57] <seb128> pitti, I didn't find one which fails in today's queue and all the old retracing which failed has their crashdumps cleaned
[15:57] <pitti> seb128: which one were you using for above pastebin?
[15:57] <seb128> pitti, let's wait a bit i'm sure we will receive another crash to play with
[15:57] <seb128> pitti, I just attach gdb to a running indicator and put a breakpoint
[15:57] <pitti> seb128: well, at some point we need to update to gdb 7.2 anyway; it alreayd hurt us with x.org
[15:58] <pitti> seb128: ah
[15:58] <seb128> pitti, I guess you can sig11 an indicator and copy the crashdump to the dc and play with gdb on it
[15:58] <pitti> seb128: I'll find one
[15:58] <pitti> right
[15:58] <pitti> seb128: https://launchpad.net/ubuntu/+source/gdk-pixbuf/2.23.0-1ubuntu3 \o/
[15:58] <seb128> pitti, danke!
[15:58] <pitti> de rien
[15:59] <seb128> wth with the i386 retracer as well
[16:00] <seb128> pitti, oh btw I commented the 10.10 amd64 retracer because I screwed the tarball for it
[16:01] <seb128> I will fix that later on
[16:01] <pitti> seb128: that's ok; it will fail anyway, as maverick's apport is still trying to talk to edge
[16:01] <seb128> (I did Ctrl-C the wrong command and stopped it while it was doing the update)
[16:03] <pitti> seb128: you can "exit 1" (or anything non-zero) in a --save chroot to abort the saving, btw
[16:04] <pitti> that's the "oh sh**" ejection seat
[16:04] <seb128> right, I know, but that was a run of the crash-digger
[16:04] <seb128> i.e same command as the cron
[16:05] <GunnarHj> ScottK: Hi, the lists of backports bugs are alarmingly long. Is there any chance to draw your attention to bug 719815, which I have prepared with branches that should be ready to build from?
[16:06] <ScottK> GunnarHj: For something as central to Ubuntu Desktop as gdm, I'd want someone from the Desktop team like seb128 to review it.
[16:07] <ScottK> If you can get seb128 (or whoever he wants to look into it) to concur with the backport, then ping me.
[16:08] <seb128> no opinion on that one, pitti has been sponsoring the work in natty and is probably better placed to comment
[16:08] <GunnarHj> ScottK: I see. I'll ask Martin P. then, since he sponsored me when uploading the things in Natty.
[16:08] <ScottK> That'd be fine too.
[16:14] <pitti> tseliot, bryce: AFAIR nvidia or nvidia-common now have postinst magic to do the necessary xorg.conf additions; do we still need to do any of them in jockey? We currently set DefaultDepth=24 (all versions) and AddARGBGLXVisuals=True (for version 96)
[16:15] <pitti> and it also disables the dri2 module
[16:15] <pitti> AFAIR the actual driver doesn't need to be set any more, as x.org now autodetects it and prefers nvidia > nv, right?
[16:16] <tseliot> pitti: nvidia-common, in addition to the libraries which Jockey uses, has some debconf magic to handle obsolete drivers but I don't think it deals with xorg.conf in any way
[16:18] <tseliot> pitti: the code that touches xorg.conf files is all in Jockey's handlers. And we definitely need the NoLogo option even though DefaultDepth is now set by default when no xorg.conf is available
[16:18] <pitti> tseliot: ah, ok, thanks; seems I misremembered then
[16:18] <pitti> might have mixed it up with the blacklisting in wl
[16:19] <tseliot> pitti: yes, that's likely (about wl). I keep forgetting about nvidia-common too ;)
[16:25] <slangasek> cjwatson: looks good to me :)
[16:26]  * slangasek giggles at the implications of a multi-arch: foreign binfmt-support
[16:26] <cjwatson> thought you might like it
[16:26] <sebner> tseliot: is the new linux blob beta driver compatible with new xorg already?
[16:27] <tseliot> sebner: nope
[16:27] <sebner> tseliot: :(
[16:31] <sebner> tseliot: well, still 2 months time ^^
[16:31] <tseliot> yep
[16:45] <GunnarHj> ScottK: Martin added a short comment on bug 719815. His remark about l-s not working was made before he realised that I prepared custom branches. (He is in a meeting now.)
[16:45] <kirkland> seb128: pitti: didrocks: hey guys;  you helped me get alt-tab working in Gnome last week;  i'm *trying* to use unity now, and alt-tab is disabled there
[16:45] <seb128> kirkland, try to run unity --reset
[16:45] <ScottK> GunnarHj: OK.  I'm just heading out for a $work meeting.  Please ping me again tomorow.
[16:45] <kirkland> seb128: pitti: didrocks: I went back to compiz settings in unity and enabled application switch and all hell broke loose
[16:46] <kirkland> seb128: okay, i'll do that, but can you tell me what unity --reset does, and why i need to run it daily?
[16:46] <didrocks> kirkland: enabling disabling plugin make compiz crash
[16:46] <seb128> you shouldn't need to run it daily
[16:46] <GunnarHj> ScottK: Ok, will do.
[16:46] <didrocks> kirkland: did you change other plugins?
[16:46] <seb128> kirkland, it reset your compiz unity profile
[16:46] <kirkland> seb128: hmm, well i have to run it every time i ask a question about unity
[16:46] <didrocks> normally, staticswitcher is enabled by default
[16:46] <didrocks> I didn't run it for weeks here
[16:47] <seb128> kirkland, well seems resetting your normal profile worked last time you might have the same issue in your unity profile
[16:47] <didrocks> it's just resetting all your unity and compiz config to default
[16:47] <seb128> kirkland, you shouldn't have to run it again if you don't play with ccsm settings
[16:47] <kirkland> didrocks: seb128: okay, i've run unity --reset, still no alt-tab
[16:47] <kirkland> seb128: i never play with ccsm settings
[16:48] <seb128> ok so you probably have a different issue, I will let didrocks deal with that
[16:48] <kirkland> seb128: thanks
[16:48] <kirkland> didrocks: help?  :-)
[16:48] <kirkland> didrocks: i haven't changed any settings;  any settings that might have been changed can be killed
[16:49] <didrocks> seb128: only dealing with easy answers?  :p
[16:49] <kirkland> didrocks: all i want is alt-tab to work, and i want super-L to push-to-talk in Mumble
[16:49] <seb128> kirkland, what videocard do you have?
[16:49] <didrocks> kirkland: ok, so now that you resetted
[16:49] <didrocks> kirkland: can you try two things
[16:49] <seb128> didrocks, we all need to recon our competence limits :p
[16:49] <didrocks> Super + W
[16:49] <didrocks> seb128: heh :)
[16:49] <didrocks> then, look at ccsm and look if staticswitcher is enabled
[16:50] <kirkland> seb128: intel, in an x201
[16:50] <kirkland> directhex: what is Super + W ?
[16:50] <didrocks> kirkland: it's supposed to trigger the expo mode
[16:50] <directhex> snuh?
[16:50] <didrocks> (same that if you click on the ws switcher button)
[16:51] <didrocks> directhex: I think the question was for me :)
[16:51] <kirkland> directhex: sorry
[16:51] <kirkland> didrocks: right, what keys are Super + W ?
[16:52] <didrocks> what keys? Not super to understand the question
[16:52] <didrocks> sure*
[16:52] <kirkland> seb128: http://pastebin.ubuntu.com/570658/
[16:53] <kirkland> didrocks: what do i press on my keyboard to activate Super + W ?
[16:53] <kirkland> didrocks: ie, I press the Windows key to activate Super + L
[16:53] <kirkland> didrocks: what do i press to do you what you asked me to do, Super + W?
[16:53] <seb128> kirkland, super = windows key
[16:53] <seb128> so super - W = windows_key - W
[16:54] <kirkland> seb128: okay, when i press that, all of my windows zoom out to little thumbnails
[16:54] <didrocks> kirkland: ok, so the expo effect (used by staticswitcher is there)
[16:54] <kirkland> didrocks: ^
[16:54] <pitti> seb128: I sent an RT ticket for the dchroot error message cron spam, FYI
[16:54] <didrocks> kirkland: so, look at ccsm now
[16:54] <didrocks> is staticswitcher enabled?
[16:55] <kirkland> didrocks: hmm, i'm kind of afraid of ccsm right now;  when i changed something in there 10 minutes ago, my whole desktop when bonkers....
[16:55] <kirkland> :-)
[16:55] <kirkland> didrocks: okay, application switcher is not enabled
[16:56] <kirkland> didrocks: i don't see anything called "static switcher"
[16:56] <didrocks> kirkland: right, activating/deactivating plugins make compiz crash
[16:56] <kirkland> didrocks: aint that a shame
[16:56] <didrocks> kirkland: a bug rather
[16:56] <seb128> it will be fixed before natty
[16:56] <didrocks> kirkland: ok, you don't have compiz-plugins-main installed I bet
[16:57] <didrocks> let me look for the exact package name
[16:57] <didrocks> kirkland: compiz-fusion-plugins-main
[16:58] <kirkland> didrocks: right, that wasn't installed
[16:58] <kirkland> didrocks: installing now
[16:58] <kirkland> didrocks: okay, installed, now what?
[16:58]  * kirkland bets he has to unity --reset again
[16:58] <didrocks> kirkland: hum, maybe not :)
[16:58] <robertknight> The blueprint page for the 'ThirdPartyApt' spec states that it has been superseded (https://wiki.ubuntu.com/ThirdPartyApt) but I couldn't see what it was replaced by.
[16:59] <didrocks> kirkland: not sure if compiz changes the keys
[16:59] <kirkland> didrocks: okay, now i have the static switch in compiz config thingy
[16:59] <kirkland> didrocks: and it is enabled
[16:59] <didrocks> kirkland: ok, just restart unity then :)
[16:59] <kirkland> didrocks: how do i do that?
[16:59] <didrocks> launch unity
[17:00] <kirkland> didrocks: logout and log back in?
[17:00] <didrocks> $ unity
[17:00] <didrocks> or logout and log back
[17:00] <didrocks> as you want :)
[17:00] <kirkland> can i launch unity from within unity?
[17:00] <didrocks> yeah :)
[17:00] <kirkland> didrocks: okay, thanks, now i can alt-tab, thanks
[17:01] <kirkland> didrocks: indulge me with one more question ...
[17:01] <didrocks> sure :)
[17:01] <kirkland> didrocks: why do my icons go back and forth, back and forth from colored icons, to the monochrome ones, every day?
[17:01] <kirkland> didrocks: like the ubuntu symbol in the top left?
[17:01] <didrocks> kirkland: when you hover the ubuntu icon?
[17:01] <didrocks> yeah, it's fading
[17:01] <kirkland> no
[17:02] <didrocks> I can ensure you it's fading, I wrote it :p
[17:02] <didrocks> so, basically, the idea is:
[17:02] <kirkland> didrocks: that's not what i mean
[17:02] <kirkland> didrocks: http://people.canonical.com/~kirkland/Screenshot.png
[17:02] <kirkland> didrocks: see how i have the 3-color ubuntu symbol right now?
[17:02] <didrocks> oh
[17:02] <didrocks> gnome-settings-daemon is crashing for you
[17:03] <didrocks> I think there is a known crasher right now, seb128 ? ^
[17:03] <kirkland> didrocks: if i reboot or logout/login later, i might have the colored one, or, i might have the black-and-white monochrome theme
[17:03] <seb128> kirkland, run gnome-settings-daemon
[17:03] <pitti> seb128: purging the launchpadlib cache helped, i386 retracer runs again
[17:03] <kirkland> didrocks: and if i logout/in later, it might be back to the colorful one
[17:03] <seb128> pitti, oh, weird but nice as well
[17:03] <didrocks> yeah, g-s-d in any case
[17:03] <seb128> kirkland, it seems g-s-d is crashing
[17:03] <seb128> didrocks, yes, several known crashers
[17:03] <kirkland> didrocks: seb128: i don't care much which it is;  i'm just kinda tired of the back and forth, back and forth :-)
[17:03] <kirkland> seb128: okay
[17:03] <kirkland> let me run that
[17:04] <seb128> there is a race with the gdm g-s-d which makes the user one try to run before the gdm one exit on modern hardwares
[17:04] <pitti> seb128: ~/.launchpadlib/api.launchpad.net/credentials/ had ".lpcookie       apport-collect  debug", that looked confusing asa well
[17:04] <seb128> in those case it fails to start
[17:04] <kirkland> seb128: http://pastebin.ubuntu.com/570665/
[17:04] <pitti> seb128: I don't restart them yet, though, while I'm debugging
[17:04] <seb128> pitti, that was me trying to figure what ./subscribe... tries to use
[17:04] <seb128> pitti, the directory was empty earlier
[17:05] <pitti> ah, ok; so it was something in the cache then
[17:05] <seb128> pitti, I started by copying the debug one api.edge
[17:05] <seb128> one from api.edge
[17:09] <ogra> Riddell, what data files were you referring to above in libqtdee ?
[17:10] <Riddell> ogra: qml files no?
[17:10] <Riddell> ogra: my issue is that Breaks should be Conflicts (at least that's what lintian said, I'm not too bothered)
[17:11] <ogra> Riddell, /usr/lib/qt4/imports/dee/qmldir which contains the plugin name
[17:11] <ogra> i think its needed by the lib to function properly
[17:12] <ogra> Riddell, yeah, i see that lintian warning, i wonder why a check of the source doesnt reveal it and i'm a bit confused, i thoght all Confilcts are supposed to be replaced by Breaks nowadays
[17:12] <ogra> pitti, ^^^ ?
[17:12] <ogra> wasnt theer a policy change ?
[17:12] <Riddell> not all
[17:12] <ogra> ah
[17:13] <Riddell> http://lintian.debian.org/tags/breaks-without-version.html
[17:13] <pitti> ogra: it needs to be versioned then, if the breakage is only due to a bug (and getting fixed), and not permanent
[17:13] <ogra> well, its mainly just a transition to a new ABI number
[17:13] <pitti> "Conflicts should be used ... in other cases where one must prevent simultaneous installation of two packages for reasons that are ongoing (not fixed in a later version of one of the packages)"
[17:13] <pitti> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
[17:14] <cjwatson> vila: I'm not sure I quite understand the context of your question.  Can you give me some?  An 'strace -f' would help too
[17:14] <pitti> ogra: as this is clearly a bug in the package which should be fixed (and should have been caugth in MIR review, FWIW), Breaks: is actually correct :)
[17:15] <ogra> pitti, it was v1 during MIR review
[17:15] <ogra> ABI bump just happened with recent upload
[17:15] <pitti> ogra: right, but library packages must not ship non-SONAME specific paths
[17:15] <vila> cjwatson: hmm, strace would be tricky there as it's in a test and can't reproduced on demand :-/ but,
[17:16] <ogra> pitti, oh, you mean i need to create a whole package for the one file that tells the lib where to find its plugin ?
[17:16] <ogra> (it wont function without that one file)
[17:16] <vila> cjwatson: roughly it's subprocess.Popen('yes', shell=True, stdout.PIPE, sterr.PIPE)
[17:16] <ogra> that seems a bit overkill
[17:16] <pitti> ogra: that, or make the one file obsolete, or moving it to a subdir which is named after the soname
[17:16] <pitti> ogra: why do you need a file which tells you where to find another file?
[17:16] <ogra> i'm not sure upstream will still work afterwards
[17:17] <cjwatson> vila: ok, and what results are you trying to get?
[17:17] <vila> cjwatson: then os.kill(proc.pid)
[17:17] <ogra> pitti, no idea, i'm just taking upstreams branch and upload it, i have no clue how QML works
[17:17] <vila> cjwatson: and I want both '/bin/sh' and 'yes' to die
[17:17]  * ogra will try to find out
[17:17] <vila> cjwatson: I got that most of the time, but sometimes, I get '/bin/sh' zombie and 'yes' still alive
[17:19] <vila> cjwatson: so the preserved SIG_IGN was at least a valid scenario, but after tens of tests, the zombie is back (not that surprising for a zombie you might say but still)
[17:19] <cjwatson> vila: I would do subp.stdout.close(); subp.wait()
[17:19] <cjwatson> vila: if you've done that subprocess_setup thing to fix python's broken defaults, then that will cause the yes process to get SIGPIPE and die, and then its parent sh will die too
[17:19] <cjwatson> assuming there are no other dups of subp.stdout
[17:20] <vila> cjwatson: that will work for 'yes' but I use it only for tests, I want to capture stderr/stdout until the death in the general case
[17:20] <vila> cjwatson: that's what I thought too, but evidence disagrees :(
[17:20] <cjwatson> your current code has nothing to do with that SIG_IGN thing
[17:21] <cjwatson> you're not sending it SIGPIPE so the disposition of SIGPIPE is at best relevant only by chance
[17:21] <cjwatson> SIGPIPE only happens when a process tries to write to a pipe with no open readeres
[17:21] <cjwatson> *readers
[17:21] <vila> cjwatson: so even if the ssh is a zombie the pipes are still alive between 'yes' and my python 'process' ?
[17:21] <cjwatson> yes
[17:22] <vila> s!ssh!/bin/sh!
[17:22] <cjwatson> the data from yes does not go through the sh process
[17:22] <vila> ok
[17:22] <vila> and but the SIGTERM signal should still be received by 'yes' no ?
[17:22] <cjwatson> no, why would it?
[17:22] <cjwatson> you're only killing the sh
[17:23] <cjwatson> if you want to kill all the subprocesses, then you need to create a new process group
[17:23] <cjwatson> os.setpgrp
[17:23] <cjwatson> then you can os.kill(-proc.pid) (note the -) to send a signal to all the processes in the process group
[17:23] <vila> cjwatson: the group can start at the subprocess level ? (aka the /bin/sh one)
[17:24] <cjwatson> yes, you can do setpgrp in a preexec_fn
[17:24] <vila> haaaa
[17:24] <vila> that's it then
[17:24] <cjwatson> you may still have some other problem; consider races between the kill and your subprocess forking something
[17:25] <cjwatson> it's difficult to fix this if you don't want to close subp.stdout
[17:25] <vila> cjwatson: not in my case
[17:26] <cjwatson> you have at least one fork even in your dummy example
[17:26] <vila> at least if the progress group is inherited
[17:26] <vila> cjwatson: two forks, one for /bin/sh, one for yes, correct ?
[17:26] <cjwatson> yeah, two, and of course you have no control over whether the kernel pauses for a week between scheduling the two of them
[17:27] <cjwatson> you should be OK as long as none of the processes have SIGTERM handlers
[17:27] <cjwatson> you could follow the strategy of SIGTERM, wait a bit, SIGKILL
[17:27] <vila> you mean I can manage to kill /bin/sh while 'yes' is still llimbo ?
[17:27] <vila> s/llimbo/in limbo/
[17:28] <cjwatson> no, in your case it will be OK
[17:28] <cjwatson> it would only be for processes that have "clever" SIGTERM handlers so that they might go on to fork something else even after you've sent SIGTERM
[17:29] <vila> right, out of scope for me indeed
[17:29] <cjwatson> I would say, though, that any and all uses of Python's subprocess module to do anything other than forking another Python process should use that SIGPIPE fragment
[17:29] <cjwatson> I have a bug open to make it the default
[17:29] <cjwatson> I should push that further up the hill at some point
[17:29] <vila> the subprocess aren't supposed to play tricks like that
[17:30] <vila> cjwatson: but then, if the subprocess is a python one, won't it re-install the handler for its own need ?
[17:30] <cjwatson> that's why I said "anything other than forking another Python process", because as you say Python will reinstall the handler
[17:30] <vila> cjwatson: so your fragment can be safely used in all cases
[17:30] <cjwatson> oh, certainly
[17:30] <cjwatson> it's just not mandatory in that exceptional case :)
[17:30] <vila> ok great
[17:30] <cjwatson> (and honestly, who does that ...)
[17:31] <vila> cjwatson: well, I was about to switch to shell=False and stick to python to be honest ;)
[17:31] <cjwatson> shell=True is usually a bad idea anyway
[17:31] <cjwatson> there's no reason for it except in very lazy programs
[17:32] <vila> cjwatson: or very simple tests from an unsuspecting dev :-}
[17:32] <cjwatson> shell=False saves a process, avoids going through the shell's command parsing, and encourages clearer thinking
[17:32] <cjwatson> (and saves kittens)
[17:34] <vila> hehe, well, 'false', 'yes', 'true' are good and simple commands to think about when concentrating on other stuff ;)
[17:35] <vila> cjwatson: thanks a lot anyway (I found this snippet while grepping madly, glad you were the right Colin ;)
[17:37] <cjwatson> heh, yeah, I'm the one obsessed with minutiae of spawning subprocesses
[17:38] <cjwatson> pitti: could you look at utouch-frame in NEW?
[17:39] <cjwatson> needed to fix d-i
[17:39] <ogra> pitti, what does the policy gain us here Kaleo and i are discussing the package, the lib wont work without the dir, QML needs the file ... if i package a -common package with the one file included we wont gain anything
[17:39] <vila> cjwatson: well, we're two ;)
[17:39] <cjwatson> ogra: the purpose of the policy is to simplify future upgrades by ensuring that multiple versions of libraries are coinstallable
[17:39] <Kaleo> ogra: one thing though: the lib works without the QML plugin
[17:39] <Kaleo> ogra: the QML plugin can be made a separate package that depends on the lib
[17:40] <cjwatson> ogra: non-coinstallable libraries create complications for apt
[17:40] <ogra> ah
[17:40] <vila> cjwatson: and I think I found the problem in my test: I was probably killing /bin/sh *before* it could fork 'yes', adding os.setpgrp made it fail at one point highlighting the race
[17:40] <ogra> Kaleo, so should i create a -common package for ./usr/lib/qt4/imports/dee/ then ?
[17:41] <Kaleo> ogra: not really
[17:41] <cjwatson> vila: if you killed it before it forked yes, it wouldn't have forked it, I'd expect
[17:41] <ogra> how else do we solve it ?
[17:41] <Kaleo> ogra: more of a package named libqtdee-qml or libqtdee-declarative
[17:41] <ogra> sigh
[17:41] <cjwatson> vila: perhaps sh has a race where if you kill it just after it forks a subprocess it forgets that it needs to clean it up
[17:42] <ogra> that needs changes in a lot of additional places then
[17:42] <ogra> assuming that libqtdee-qml will now be our toplevel
[17:42] <cjwatson> or perhaps killing sh doesn't reliably kill its subprocesses in the first place; I try to avoid relying on that kind of thing
[17:42] <vila> cjwatson: could be, and tests may not be the best place to ... right
[17:42] <Kaleo> ogra: libqtdee-qml would depend on the libqtdee and unity-2d would depend on libqtdee-qml
[17:43] <ogra> Kaleo, thats what i mean, yeah
[17:43] <bcurtiswx> is there an apt command to view the changelog from a package?
[17:43] <Kaleo> ogra: actually I don't think we use libqtdee-qml in Unity 2D anymore, let me check
[17:43] <vila> cjwatson: sounds like the best option anyway, too many obscure edge cases there that I can safely avoid by sticking to python
[17:43]  * Kaleo has the feeling he is talking shit
[17:43] <ogra> Kaleo, you mean it could go completely ?
[17:43]  * ogra is confused
[17:44] <Kaleo> ogra: well, it *could* go because nobody is using it today; it does not mean it should go: it is a very useful QML plugin on its own
[17:45]  * ogra tries to find an ARM employee to get him access to the coffee bar ... one sec brb
[17:45] <Kaleo> ogra: but in terms of dependency for Unity 2D we don't need it; we can depend as we do today on libqtdee
[17:45] <Kaleo> ogra: and just split out in a separate binary package the qml plugin
[17:45] <Kaleo> ogra: would that be ok?
[17:46] <cjwatson> bcurtiswx: apt-get changelog, as of natty.  not in earlier releases.
[17:46] <Kaleo> ogra: but I am not sure it helps the purpose of the policy
[17:47] <Kaleo> ogra: essentially the QML plugin is a library
[17:47] <bcurtiswx> cjwatson, OK so if I'm on a maverick machine looking for a natty changelog, i should just use packages.ubuntu.com ?
[17:47] <Kaleo> ogra: and right now multiple versions of libraries are not coinstallable
[17:47] <Kaleo> ogra: and it won't help to create another package I am afraid
[17:48] <cjwatson> bcurtiswx: yes, or launchpad
[17:50] <bcurtiswx> thanks
[17:54] <ogra> Kaleo, well, if pitti hadnt complained i wouldnt have been inclined to even think about changing it
[17:54] <ogra> (sorry for the interruption)
[17:54] <Kaleo> ogra: don't worry :)
[17:55] <Kaleo> pitti: what's your take on it? (I was not on the chan before, sorry)
[18:22] <jono> is anyone having playback issues with Banshee in Natty?
[18:22] <jono> I am getting this when running it in the terminal:
[18:22] <jono> [Warn  10:21:46.152] Service `Banshee.MediaEngine.PlayerEngineService' not initialized: Broken pipe [EPIPE].
[18:23] <davidascher> barry: ping
[18:25]  * ogra wonders if jono secretly switched to arm hardware ... we are used to such errors in banshee :)
[18:28] <jono> ogra, strange
[18:28] <jono> I assume my alsasink is not working in gstreamer
[18:28] <ogra> yeah, something like that
[18:28] <ogra> there is a debug flag you can run mono apps with
[18:29] <ogra> see --help of banshee
[18:29] <slangasek> pitti: so do you think we need to worry about package size increases on i386 if I make this cdbs change?
[18:29] <pitti> re
[18:30] <pitti> ogra: we will gain upgradeability
[18:31] <pitti> ogra, Kaleo: as I said, you could store the qml file in a per-SONAME path
[18:31] <pitti> i. e. not /usr/share/myproject/foo.qml, but /usr/share/myproject/0/foo.qml
[18:31] <ogra> pitti, then QML wont work anymore
[18:31] <ogra> it looks in that specific path
[18:32] <pitti> the hackish alternative would be to have all libfooN Replaces: libfoo(N-1), libfoo(N-2), etc.
[18:32] <pitti> but that piles up over time
[18:32] <pitti> ogra: the cleanest solution really is to move the QML file away from the library
[18:32] <ogra> and have a -common package ?
[18:32] <pitti> ogra: why does it need to be in the lib? it could be in unity-2d itself?
[18:32] <pitti> or another one which is suitable
[18:33] <ogra> i think a -common package or a -qml package would be cleaner
[18:33] <pitti> slangasek: alternates will certainly go up a bit, but as the difference to amd64 hasn't gone up significantly, I'm not too worried about this
[18:33] <ogra> instead of tainting unity-2d sources
[18:33] <slangasek> pitti: ok
[18:33] <pitti> slangasek: and anyway, we don't have much choice here, do we?
[18:35] <slangasek> pitti: well, we could defer this change until the beginning of natty+1 and I could use $CDBS_NO_DOC_SYMLINKING for anything I need to touch right now
[18:35] <slangasek> pitti: but I prefer to fix cdbs if that's ok with you :)
[18:43] <tkamppeter> mterry, I have uploaded the ghostscript version which needs gs-cjk-resource now. Can you please move gs-cjk-resource into main before FF? Thanks. Bug 718692.
[18:44] <tkamppeter> pitti, or can you move an approved MIR, too?
[18:44] <mterry> tkamppeter, I'm not an archive admin, so I can't do it
[18:48] <tkamppeter> pitti, I have uploaded ghostscript 9.01~dfsg-1ubuntu1 which depends on gs-cjk-resource at run time, but not during build. Does this cause any problem with gs-cjk-resource being moved to main?
[18:48] <pitti> tkamppeter: it will cause CDs to become uninstallable
[18:48] <pitti> (main dependency to universe)
[18:49] <pitti> does it have an approved MIR?
[18:50] <tkamppeter> pitti, the MIR is filed as bug 718692 and already set to "Fix committed" by the MIR approval team.
[18:50] <pitti> tkamppeter: ah, sweet; let me promote it then, to avoid uninstallability
[18:50] <cody-somerville> Can anyone confirm that marking a bug as incomplete after a bug has been verified and triaged and we're just waiting to confirm a patch fixes the issue is *not* standard process?
[18:50] <tkamppeter> pitti, thanks.
[18:50] <pitti> done
[18:51] <pitti> cody-somerville: I have used "incomplete" in that way -- for me it generally means "the assignee cannot continue working on this bug wwithout further data from the reporter"
[18:51] <pitti> not sure whether that's being frowned upon, though
[18:51] <tkamppeter> pitti, thanks.
[18:53] <cody-somerville> pitti, It seems wrong to me that a bug would get expired because the reporter decided not to build their own kernel to test a patch when clearly the bug had enough information for a developer to come up with a tentative patch.
[18:54] <pitti> cody-somerville: that seems extreme, yes; I usually build a package with a patch in a PPA if I can't reproduce the problem and am unsure whether my patch fixes it
[18:54] <pitti> I think it should be acceptable to ask a bug reporter to try a PPA
[18:54] <pitti> (if you ensure that it has nothing else/crackful in it)
[18:54] <pitti> building kernels with a patch, not so much
[18:56]  * cody-somerville happens to be the reporter who has a kernel bug marked incomplete waiting for him to test a kernel patch <g>.
[18:57] <cody-somerville> pitti, what would you recommend as a status instead? maybe in progress?
[18:57] <pitti> sounds ok, but it would interfere with my bug list
[18:58] <pitti> I'd actually recommend "needs info", but ask for a test kernel in a PPA or some people.c.c. URL :)
[18:59]  * cody-somerville nods.
[18:59] <cody-somerville> pitti, Are you on Maverick?
[18:59] <pitti> no, natty COTD
[19:00] <cody-somerville> pitti, Do you have a usb headset by any chance?
[19:00] <pitti> cody-somerville: I had until a few months ago, then the cable broke, and I threw it away
[19:00] <cody-somerville> ah
[19:00] <pitti> I have an USB sound card, though
[19:00] <pitti> i. e. USB to standard mike/headphone jack
[19:01] <pitti> I found that more flexible, as usually I want to use my laptop's normal jacks
[19:02] <cody-somerville> pitti, not sure if that would trigger it but if I unplug my usb headset while audio is playing my kernel panics - a number of other folks have reported the same issue. Seems like a nasty little regression in maverick. :(
[19:02] <\sh> anyone has a clue how to determine reliable a chroot environment (without tweaking the shell prompt, pls ;))
[19:03] <\sh> cody-somerville: should I unplug my usb headset now to test?
[19:04] <\sh> eventually switching before that to tty0?
[19:05] <cody-somerville> \sh, after saving your work, be my guest. I've gotten a kernel traceback and vmdump but if you do see anything interesting not already in the bug report (LP #715318) feel free to add.
[19:05] <cody-somerville> \sh, If you can reproduce and also happen to enjoy compiling your own kernel, I'd be most grateful if you tested the proposed patch as well :)
[19:06] <pitti> cody-somerville: just tried that here in current natty, works fine
[19:07] <\sh> cody-somerville: the stacktrace is written somewhere while it crashes or should I enable crashdump writing support somehow?
[19:08] <slangasek> pitti: do you want to review my cdbs patch before I upload, or are you happy as long as it passes my shallow testing?
[19:09] <pitti> slangasek: I trust the test suite enough to prevent major damage, but I'm happy to peer review; is it in bzr?
[19:09] <cody-somerville> \sh, I installed 'crash', ran sudo mkdir -p /var/crash/, and tweaked a few files in /etc/defaults/ for good measure turning all the crash related stuff I could find on, lol
[19:09] <pitti> slangasek: hm, nothing new in the branch right now
[19:10] <slangasek> pitti: not yet, let me push it there (gimme 10 minutes, I don't have the branch downloaded yet)
[19:10] <\sh> cody-somerville: ok..will do the same :) just to be sure...but give me a couple of minutes I need to tweak our firewalls first
[19:10] <slangasek> I only looked at the UDD branch, which is out of date ;)
[19:11] <pitti> "Vcs-Bzr:" is the right onw
[19:11] <pitti> one
[19:11] <pitti> (dinner ready, back in a bit)
[19:12] <pitti> slangasek: anyway, feel free to upload; there are enough version numbers :)
[19:12] <slangasek> heh
[19:12] <pitti> but please commit it to bzr as well
[19:12] <cody-somerville> \sh, Note that if you have apport enabled it'll churn over the dump for awhile generating a crash report after crashdump reboots the system for you.
[19:12] <slangasek> pitti: yes, will do
[19:14] <barry> davidascher: hiya!
[19:14] <davidascher> barry: question for you about smtpd.py...
[19:14] <davidascher> although i think i figured out most of what i wanted.
[19:15] <cody-somerville> \sh, I also found apport complained (sadly) about 'TypeError: Incorrect padding' but I just ignored that, downloaded the debug kernel, and used crash to extract the log data myself. A second go at it seemed to work alright but then Launchpad gave apport a server error at the very end of the very long upload :(
[19:15] <barry> davidascher: goforit
[19:15] <davidascher> is there something better?  I don't actually need TLS right now, but it seems that some parts of ESMTP are worth doing.
[19:16] <davidascher> i think i figured out the other q's i was going to ask.
[19:16] <barry> davidascher: there's nothing better in the stdlib.  it's possible twisted has something more feature full.  i do remember a patch to smtpd.py that added a bunch of useful esmtp commands.  i need to dig up where i saw that thow
[19:16] <barry> er, though
[19:19] <slangasek> pitti: my UDD wish of the day: documentation for how to merge a pre-existing bzr packaging branch into a UDD branch without losing any history from either :-)
[19:28] <\sh> cody-somerville: looks like I need to postpone the testing towards tomorrow morning ... real life work haunts me ...
[19:28] <cody-somerville> \sh, no problem :) ty anyways
[19:35] <highvoltage> hey, on the edubuntu daily builds, the packages shipped on the live disk aren't added through apt-cdrom when booting from a live USB disk
[19:35] <ricotz> Riddell, i have fixed the copyright file of libbluray you can take a second look if you dont mind
[19:36] <highvoltage> this used to work on maverick, I'll file a bug on it, but is there anyone I should poke about it?
[19:36] <highvoltage> it seems like the usb disk used to be mounted as /media/cdrom before, but that doesn't seem to be happening anymore for some reason
[19:39] <pitti> slangasek: seconded
[19:48] <slangasek> huh; how do we get a branch format update for a vcs-import branch?
[19:48] <soren> slangasek: There used to be a button on the launchpad web ui.
[19:48] <slangasek> soren: only for branches you have write access to :-)
[19:48] <slangasek> which I don't, for ~vcs-import
[19:48] <soren> Point.
[20:36] <siretart> Riddell: ricotz: libbluray reuploaded
[20:41] <RoAkSoAx> vish: ping
[20:58] <psusi> pitti: I threw in a UDF DVD+RW the other day and it was not being mounted with uid=,gid= options.  Does udisks only add those for fat/ntfs or something?
[21:00] <pitti> psusi: no, they are in udf_defaults[]
[21:00] <pitti> psusi: perhaps you had the drive in /etc/fstab?
[21:01] <psusi> pitti: I'm pretty sure I don't have it in fstab... it's auto mounted when inserted...
[21:01] <psusi> I'll check though
[21:02] <psusi> so it should be adding the options for udf as well then?
[21:02] <pitti> psusi: fstab doesn't preclude automounting, it just overrides udisks' default options
[21:02] <pitti> psusi: yes
[21:03] <psusi> ahh, cool... probably that then.. I'll check and get rid of it.
[21:04] <psusi> I wonder if I should add those options for ext4 too?
[21:04] <pitti> ext4 doesn't have uid/gid
[21:04] <psusi> would be kind of nice to be able to use that for removable media
[21:04] <pitti> it's a real file system
[21:04] <psusi> right... I have been thinking I shuold add it
[21:04] <psusi> be nice to be able to disable permissions for removable media
[21:05] <psusi> udf can store proper ownership, but lets you disable it
[21:05] <psusi> be nice if ext4 did the same
[21:37] <zul> skaet_: is there a way to nominate a bug for a later release?
[21:37] <ogra_> zul, ubuntu-later as milestone ?
[21:37] <ogra_> iirc we had that once
[21:38] <zul> nm i think i figured it out
[21:38] <slangasek> zul: there are pre-populated release series for O, P in launchpad
[22:02] <pitti> ev: got bug 723223 working in trunk now; I have some other refinements to make; do you want me to upload this now, and do the refinements later, or can it still wait a bit?
[22:06] <seb128> pitti, speaking of jockey, bug #712685 seems to have some recent duplicates
[22:07] <seb128> pitti, bug #719523 as well but that might be due to the svg breakage
[22:07] <pitti> seb128: the latter should be fixed now
[22:08] <pitti> should be a dupe of bug 715753)
[22:08] <seb128> pitti, ok, I'm just doing some cleanup of apport-crash bugs
[22:08]  * pitti dupes
[22:08] <seb128> pitti, thanks
[22:08] <pitti> seb128: thanks for pointing out the first one, this looks easy to fix
[22:08] <seb128> yw
[22:11] <cnd> Riddell, I've been working on the multitouch stuff, and I've got a patch to enable multitouch in qt
[22:11] <cnd> I'm cleaning it up and testing it right now
[22:11] <cnd> I'd like to get it in before feature freeze
[22:11] <cnd> what are your thoughts?
[22:11] <pitti> seb128: fixed :)
[22:12] <seb128> pitti, ;-)
[22:12] <seb128> pitti, bug #717776 could be an easy one as well
[22:13] <seb128> not sure if that's a list of nvidia drivers to update?
[22:14] <pitti> that's a bit more tricky, I'm afraid; I'll keep it on the radar, thoug
[22:15]  * pitti waves good nigth
[22:15] <seb128> pitti, ok, there is also bug #710194 and some similars
[22:15] <seb128> but enough for today indeed
[22:15] <seb128> pitti, 'night!
[22:20] <Riddell> cnd: hi
[22:20] <Riddell> cnd: that's interesting
[22:21] <Riddell> cnd: the first question from Kubuntu with regards to patches is always is there a path to getting it upstream
[22:21] <cnd> Riddell, the patch came from a qt developer
[22:21] <cnd> he had to step away from the project
[22:21] <cnd> but it will get into upstream one way or another
[22:21] <cnd> though it may not be in exactly this form
[22:21] <cnd> the patch adds about 600 lines of code
[22:22] <Riddell> lovely
[22:22] <Riddell> cnd: then does it add unstable interfaces?
[22:22] <cnd> Riddell, nope
[22:22] <cnd> api is the same as always
[22:22] <cnd> just that touch events now are possible on linux
[22:23] <cnd> the touch api has been available since qt 4.6, and it works for win and mac
[22:23] <Riddell> ah, I didn't know that
[22:23] <cnd> this patch just hooks up the plumbing from the new xi 2.1 that I've been working on
[22:23] <Riddell> cnd: sounds good then, we should get some packages made
[22:23] <Riddell> cnd: are you into packaging or are you looking for me or something to do it?
[22:23] <cnd> Riddell, in fact, I've already got a package in ppa:utouch-team/xorg-unstable
[22:24] <cnd> I can package it up (just throwing the patch in)
[22:24] <cnd> how do you normally take things?
[22:24] <cnd> bzr merges?
[22:24] <cnd> copy the new source package somewhere?
[22:28] <Riddell> cnd: we use ~kubuntu-members/qt/ubuntu for the packaging
[22:28] <Riddell> so a merge into that would be lovely
[22:28] <cnd> Riddell, ok, I'll work on that
[22:28] <cnd> Riddell, when do you need it by to review and upload for feature freeze?
[22:29] <Riddell> cnd: not sure when feature freeze is going to be declaired but within 24 hours would be sensible
[22:29] <cnd> Riddell, ok, I think I can make that
[22:33] <valavanisalex> Hi All... Packaging query: does the X-Ubuntu-Gettext-Domain key need to go under the [Desktop Entry] group in a .desktop file, or can it just go anywhere?
[22:41] <Riddell> ricotz: ping
[22:43] <Riddell> ricotz: http://thread.gmane.org/gmane.comp.audio.libcanberra.general/199
[22:46] <JontheEchidna> valavanisalex: it's automatically added to .desktop files that need it
[22:46] <JontheEchidna> by the ubuntu build daemons
[22:47] <JontheEchidna> you don't have to worry about that unless it needs to be customized for some reason
[22:49] <ricotz> Riddell, huh? you mean robert_ancell ;)
[22:49] <valavanisalex> JontheEchidna: ah OK.  The Inkscape package currently contains a manual patch to add the line.  However, it appears at the end of the .desktop file inside a different group
[22:50] <valavanisalex> JontheEchidna: Is it best to remove the manual patch then, and allow automatic configuration?
[22:50] <robert_ancell> Riddell, thanks.  That's a very indirect way of contacting the Ubuntu developers :)
[22:50] <JontheEchidna> valavanisalex: if there's a patch manually setting it, there is probably a reason
[22:51] <Riddell> ricotz: I don't think so, your name is down as adding the patch which makes that change
[22:51] <ricotz> robert_ancell, i have upload the g-s package
[22:52] <ricotz> Riddell, where?
[22:53] <Riddell> ricotz: libcanberra debian/changelog says [ Rico Tzschichholz ] - add 90-patch-theme-for-ubuntu.patch
[22:54] <valavanisalex> JontheEchidna: The trouble is that a new dpatch patch has been added recently, which creates a new group in the .desktop file.  The X-Ubuntu-Gettext-Domain key is appended afterwards by debian/rules, so the key ends up being added to the new group rather than [Desktop Entry].  Is this a problem?
[22:54] <ricotz> Riddell, mhh, i see, i think it was an inline patch which i extracted
[22:56] <JontheEchidna> valavanisalex: I don't know, it depends on how gnome's menu implements .desktop file translations from external .po's
[22:56] <JontheEchidna> It shouldn't be a problem for KDE's setup, iirc
[22:57] <Riddell> ricotz, robert_ancell: ok well if one of you could fix that libcanberra issue and e-mail the mailing list he posted to saying it's fixed that would be great
[22:57] <JontheEchidna> valavanisalex: oh, actually that would cause problems
[22:58] <JontheEchidna> pkgbinarymangler should probably be made more smart, and put X-Ubuntu-Gettext-Domain in the right group
[23:00] <ricotz> robert_ancell, could you look into this? perhaps it could be updated to libcanberra 0.27 too
[23:00] <robert_ancell> ricotz, ok
[23:01] <valavanisalex> OK, thanks.  So I guess I could remove the manual patching from debian/rules, and add the key to the dpatch instead?
[23:01] <ricotz> Riddell, did you have time to look at libbluray again? siretart also accidently uploaded again
[23:01] <ricotz> robert_ancell, thanks
[23:03] <Riddell> ricotz: hah I tried looking for that earlier and it wasn't there, turns out blueray isn't spelt proper
[23:03] <ricotz> Riddell, right ;)
[23:06] <Riddell> ricotz: is there anything in here equivalent to libdvdcss?
[23:06] <ricotz> Riddell, yes, but not appropriate for the repo
[23:07] <Riddell> ricotz: so there's a separate bit for the DRM that isn't included in this upload?
[23:07] <ricotz> Riddell, yes, this package makes it possible to read not encrypted blurays
[23:08] <ricotz> Riddell, libaacs would be the drm workaround which also exists
[23:09] <Riddell> ricotz: groovy accepted
[23:10] <Riddell> ricotz: I find "Most commercial Blu-Ray are protected by AACS or BD+ technologies" very biased language though, I'd strongly think that should be changed to "restricted"
[23:12] <ricotz> i see
[23:14] <ricotz> Riddell, thanks for your time
[23:20] <broder> kees: ooc, is patching mountall actually easier than generating a patch to debugfs to take -o mode=?
[23:21] <kees> broder: based on the reception of my upstream patches; yes.
[23:22] <broder> ugh, ok
[23:22] <kees> the other problems is that debugfs is a singleton like /sys so "mode=" would actually take global affect.
[23:23] <kees> so I'm just going with a chmod, and we'll see what shakes out. it's been a frustrating path. :P
[23:49] <kees> bryceh: what triggers the GPU lockup apport hook thing? I want to make sure I'm not smoking crack and breaking that hook
[23:50] <bryceh> kees, it's triggered by code in the kernel intel drm driver
[23:50] <kees> whoa, in the kernel driver?
[23:50] <bryceh> yes
[23:53] <kees> bryceh: do you have a string I can search for? call_usermodehelper_fns() doesn't show up in the drivers/gpu/drm tree
[23:53] <bryceh> specifically, there is code in there that will reset the gpu when it locks up
[23:53] <bryceh> (unfortunately, it seems to rarely work, but...)
[23:54] <bryceh> so there is code in there which also fires off some sort of event.  we register the apport hook to be triggered off that (via an upstart rule)
[23:54] <kees> oh, interesting
[23:55] <kees> upstart, not udev?
[23:55] <bryceh> udev, sorry
[23:55] <bryceh> SUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.py"
[23:55] <bryceh> # Jesse Barnes on ubuntu-devel@lists.ubuntu.com:
[23:55] <bryceh> #   You'll get three events, one when the error is detected, one before the
[23:55] <bryceh> #   reset and one after.  Each has a different environment variable set; the
[23:55] <bryceh> #   initial error has ERROR=1, the pre-reset event has RESET=1 and the
[23:55] <bryceh> #   post-reset event has ERROR=0.
[23:55] <kees> ah-ha!
[23:56] <kees> nice, okay, yeah, that totally runs as root.
[23:57] <Keybuk> (you could also do that with:
[23:57] <Keybuk>  start on drm-device-changed ERROR=1
[23:57] <Keybuk>  exec /usr/share/apport/apport-gpu-error-intel.py
[23:57] <Keybuk> )
[23:57] <Keybuk> :p
[23:59] <kees> Keybuk: don't hurt me too hard for my mountall upload! ;)