[00:17] <|Anthony|> what is happening regarding consolekit and udev having been merged into systemd?
[00:56] <jbicha> man, staring at the Dash for too long trying to document it, I see these minor inconsistencies
[00:56] <jbicha> I guess it gives us something to do for 13.04
[05:59] <pitti> Good morning
[07:04] <dholbach> good morning
[07:05] <bkerensa> oh submittodebian Y U crash
[10:31] <alexbligh> If I publish package foo-1.deb that contains /etc/foo/bar and it is installed, then publish and install a new version foo-2.deb which does not contain /etc/foo/bar, should I expect /etc/foo/bar to be deleted? If not, how to I achieve this? (in this particular example it's a file in a run-parts-like directory)
[10:34] <alexbligh> (obviously an rm in postinst will look like a local change, and an rm in preinst isn't good if the installation fails)
[10:39] <pitti> alexbligh: no, it shouldn't be deleted; you need to add a debian/foo.maintscripts for that, see man dpkg-maintscript-helper
[10:39] <pitti> alexbligh: that'll create proper preinst/postinst snippets for you very conveniently and robustly
[10:39] <cjwatson> s/maintscripts/maintscript/
[10:39] <pitti> alexbligh: I mean it shoudln't be deleted by dpkg itself
[10:39] <cjwatson> (and also see 'man dh_installdeb')
[10:39] <pitti> right, thanks cjwatson (see man dh_installdeb)
[10:40] <ogra_> and on a nitpicker sidenote it should be -0ubuntu1.deb .... -0ubuntu2.deb, not -1.deb or -2.deb :)
[10:40] <ogra_> (unless you plan to push to debian first)
[10:42] <alexbligh> hmm, lucid does know of anything with 'maintscript' in, unless I'm missing something
[10:42] <pitti> right, this needs dpkg (>= 1.15.7.2)
[10:43] <pitti> alexbligh: for older releases you need to write the stuff manually, see http://wiki.debian.org/DpkgConffileHandling
[10:45] <pitti> alexbligh: may I ask what you plan to do? changing conffiles in lucid doesn't sound like an obviously right thing to do at this point
[10:45] <alexbligh> pitti, thanks - not such a trivial question.
[10:45] <pitti> if you have leftover conffiles, it's usually easier to clean them up with a precise/quantal upgrade than doing SRUs for leftover conffiles
[10:45] <alexbligh> pitti, oh this is partly down to my complete stupidity in putting something in /etc/ which should have been a symlink to stuff in /var.
[12:17] <doko> ogra_, should we keep the dri2-utils in restricted, or move these to multiverse?
[12:17] <ogra_> doko, does that come out of the libdri2 source package ?
[12:17] <doko> yes
[12:18] <ogra_> i can ask robclark once he is up ...
[12:18] <doko> thanks
[12:18] <ogra_> but given the rest of libdri2 is in restricted ....
[12:18] <ogra_> (and has to stay there)
[12:19] <doko> ok, I'll seed it then
[12:31] <doko> Laney, debfx: about qt4-x11 and webkit ...
[12:31] <doko> in 4:4.7.3-1
[12:31] <doko>   * Drop 91_s390_use_gstabs.diff patch. It's no longer needed as webkit is not
[12:31] <doko>     built from Qt sources anymore.
[12:32] <brendand> anyone here have inside info about pep8 (the tool)?
[12:32] <doko> so this issue did pop up before. but why is qt4-x11 building webkit internally again?
[12:32] <brendand> i'm trying to get the --diff option to work. seems futile atm. using v1.3.3
[12:32] <brendand> i'm piping a bzr diff and it's not really doing what i'd expect
[12:33] <brendand> --help says it needs a unified diff (which is what bzr diff gives, right?)
[12:34] <Laney> doko: interesting
[12:35] <debfx> doko: it always has built qtwebkit in ubuntu
[12:36] <debfx> do you think building with -gstabs instead of -g would help?
[12:36] <doko> debfx, I'll wait on Laney's build with -gstabs, and then we'll know
[12:36] <Laney> doko: I think the patched make will still end up being necessary, btw
[12:37] <doko> and currently timing the link step
[12:37] <cjwatson> My pep8(1) doesn't document a --diff option at all
[12:37] <cjwatson> But that's the version in quantal which is older than the one you're talking about
[12:38] <brendand> cjwatson, hmm. new feature i guess
[12:39] <ahasenack> hi, can someone please sponsor/upload this SRU? https://bugs.launchpad.net/landscape-client/+bug/1053057 I believe I subscribed the right teams
[12:42] <brendand> cjwatson, i believe mine is from pypi
[12:50] <doko> pitti, just noticing https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3833224 ... 10h in the png optimizer :-/
[13:01] <smb> cjwatson, Is it possible that the 12.04 ubuntu-keyring package also needs to be updated to contain the new signing key? Seems I run into problems when trying to pull recent quantal netboot images into my provisioning server
[13:01] <cjwatson> yes and I opened a bug foro it
[13:01] <cjwatson> but the message you get should be harmless
[13:01] <smb> cjwatson, Well the script aborts in that case :/
[13:03]  * xnox mostly harmless =)
[13:03] <cjwatson> smb: -v
[13:03] <cjwatson> it was entirely harmless in my tests
[13:04] <smb> cobbler-ubuntu-import -u quantal-x86_64
[13:04] <smb> failed to verify MD5SUMS via /usr/share/keyrings/ubuntu-archive-keyring.gpg (http://archive.ubuntu.com/ubuntu/dists/quantal/main/installer-amd64/current/images/MD5SUMS)
[13:04] <smb> I can fetch the key manually, though
[13:06] <smb> I guess I should change to use MaaS, too. But it is (was) working well enough to want to touch it
[13:09] <smb> cjwatson, Ok, manually added the keys gets me going for now
[13:09] <zul> doko: ping can you have a look at https://bugs.launchpad.net/ubuntu/+source/pyudev/+bug/1055482 (pyudev MIR)
[13:09] <cjwatson> smb: Hmm, apt has no problem
[13:10] <cjwatson> smb: I suspect (no surprise) a cobbler bug
[13:10] <cjwatson> smb: But yeah, I'll get going on that SRU today then
[13:12] <smb> cjwatson, Sort of hard relies on the keys to be there. Ok, thanks, should hopefully be a little risk change to have additional keys in that ring.
[13:12] <cjwatson> smb: The bug is that it isn't happy with just one of the multiple signatures being valid and the other one having a missing key
[13:12] <cjwatson> Sure, if it sees a single BADSIG it should kick it out, but one GOODSIG and one missing should be just fine
[13:13] <cjwatson> Which it should have
[13:16] <soren> IIRC, that script just relies on gpg to do the right thing. "gpg --verify --keyring=/path/to/ubuntu-archive-keryring.gpg [...]"
[13:16] <soren> fwiw
[13:18] <smb> soren, Yes, it looks like doing that...
[13:18] <cjwatson> You have to be pretty careful about parsing output then
[13:18] <soren> It relies on return code
[13:18] <soren> I think.
[13:18] <cjwatson> Yeah, but it needs to be cleverer
[13:19] <smb> soren, yes
[13:19] <smb> cjwatson, just did a quick test
[13:19] <cjwatson> Yes, so did I
[13:20] <cjwatson> You get return code 2, and detailed explanations on stdout of what's happening
[13:20] <cjwatson> But that doesn't mean cobbler isn't buggy :-)
[13:20] <smb> cjwatson, I would not dare to say that. :)
[13:20] <cjwatson> Anyway, we clearly have to SRU ubuntu-keyring in any event - this is just exposing previously-unnoticed bugs
[13:20] <cjwatson> I would
[13:21] <smb> I meant I would never say cobbler is not buggy
[13:21] <cjwatson> Hah
[13:21] <soren> To be fair, cobbler-ubuntu-import isn't a Cobbler thing. It's an Ubuntu addition.
[13:21] <xnox> cjwatson: SRU or -security, the latter seems better.
[13:21] <soren> Also, that does not mean cobbler isn't buggy :)
[13:22] <cjwatson> xnox: -security isn't up to me
[13:23] <doko> zul, done
[13:24] <doko> zul, what about yui3? I know you did downgrade these recommends to suggests for another package, but maybe that's not the best thing as these pop up again
[13:25] <zul> doko: what about yui3?
[13:25] <doko> zul: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[13:26] <doko> zul: and a MIR for python-babel is missing
[13:26] <zul> doko:  yeah i dropped python-babel for nova its pending right now
[13:27] <zul> doko: javascript-common has nothing to do with me
[13:28] <doko> zul: and yui3? or would that be desktop?
[13:28] <Daviey> doko: that is a MAAS thing.  It is us.
[13:28] <doko> mterry, didrocks: ^^^
[13:28] <doko> ahh, ok
[13:28] <Daviey> (not zul, but yes, server)
[13:28] <zul> doko/Daviey: ah
[13:28] <doko> better call it mess ...
[13:29] <ogra_> mess on aargh64 in R ?
[13:29] <Daviey> doko: You've managed to bring comedy to my otherwise sarcasm less Monday.
[13:32] <Laney> doko: collect2: error: ld returned 1 exit status
[13:32] <Laney> libtool: install: error: relink `libwebkitgtk-1.0.la' with the above command before installing it
[13:32] <zul> doko:  wait you just duplicated the pyudev MIR?
[13:32] <doko> zul, no, just made it a duplicate
[13:33] <doko> Laney, just to double check, there's no -g overwriting -gstable on the command line for the build of the object files?
[13:33] <zul> doko: ah you are going to promote it right? :)
[13:33] <doko> zul: as I did say. it's done :)
[13:34] <zul> doko: cool thanks
[13:35] <stokachu> stupid question,is verification-done-precise needed in order to have the job process it or is just verification-done all thats needed
[13:35] <Laney> doko: no, not that I can see
[13:35] <Laney> it's a different error anyhow
[13:36] <doko> ok
[13:36] <doko> Laney, could you try the link with -B/usr/lib/gold-ld/
[13:37] <smb> stokachu, If it was verification-needed-precise (or so) then it needs ...-done-precise to match it to that release (usually replace the needed by done in the tags)
[13:37] <stokachu> ah ok, so for future just mimick whatever the verification-needed* is
[13:38] <smb> yes
[13:39] <stokachu> and any idea how long it takes bug watcher to process those bugs?
[13:39] <didrocks> doko: ok, thanks for keeping us in touch :)
[13:54] <smb> stokachu, Not for generic packages. For the kernel I believe the bot runs every hour
[13:55] <stokachu> smb: ok thanks, according to one bug it seems to be longer than 12 hours
[13:56] <Laney> doko: looking more promising
[13:56] <Laney> oh, wait what
[13:57] <Laney> *exactly* when I said that it failed collect2: error: ld returned 1 exit status
[13:57] <doko> heh
[13:58]  * Laney gives both pieces back to seb128 :P
[13:58] <doko> Laney, ok, I'll look at it. first trying without the make patch, but using ulimit -s 16384
[13:59] <seb128> Laney, nah, you touched it, it's all yours :p
[14:18] <seb128> ev, hey
[14:19] <seb128> ev, is there known issue with e.u.c? I'm wondering why bug #1053670 is not showing up on the daily or monthly view seeing the list of duplicates from the retracers, whoopsie should at least have the same number and that should be enough to make it displayed on the main page
[14:42] <dholbach> chrisccoulson, micahg: do you think one of you could reply to https://twitter.com/lmukadam/statuses/249471182510882816?
[14:43] <fginther> infinity, ping
[14:43] <micahg> dholbach: I think I'll leave that to chrisccoulson
[14:43] <dholbach> ok cool
[14:43] <seb128> dholbach, what did they announce?
[14:44] <dholbach> seb128, I guess it's about thunderbird having less of a focus on new features
[14:45] <seb128> dholbach, is that something we can do something about?
[14:45]  * micahg doesn't think it should impact us at all
[14:45] <seb128> well, I don't even see what we can say or reply to that
[14:45] <seb128> "good for them?"
[14:45] <seb128> ;-)
[14:45] <dholbach> I just wanted somebody with more of an idea of what's going on to answer the question.
[14:45] <micahg> aside from most of the updates having less regression potential :)
[14:46] <dholbach> @ubuntudev catches all kinds of questions
[14:46] <udevbot> Error: "ubuntudev" is not a valid command.
[14:50]  * micahg isn't even on twitter
[14:54] <xnox> dholbach: wasn't there a blog post on ubuntu-planet after thunderbird announcement from jono or someone like that explain the FUD and effects on ubuntu?!
[14:55] <dholbach> I'm not quite sure
[14:55] <dholbach> ah, this one: http://www.jonobacon.org/2012/07/11/thunderbird-and-ubuntu/?
[14:56] <xnox> dholbach: yeap. gosh my memory is good =)
[14:56] <Daviey> doko: Hey, would you be able to look at python-tx-tftp please?
[14:57] <doko> Daviey, look at what?
[14:59] <Daviey> doko: your recent rebuild uncovered a rebuild-FTBFS.  I wondered if you had capacity to look at it?
[15:02] <doko> Daviey, not today, didrocks is on +1 maintenance too. maybe barry could look at this one too?
[15:03] <barry> Daviey: url?
[15:04] <Daviey> barry: https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3837059
[15:05] <Daviey> barry: I reproduced it... Not sure what would have introduced that... ideas?
[15:06] <barry> Daviey: it's pretty clearly a bug in the code causing the exception during error logging.  my guess is that the error being logged is not expected, otherwise upstream would have surely encountered that bug during the test suite.  unless of course one of our patches introduced the bug.  let me grab the package and take a look
[15:09] <infinity> fginther: G'morning.
[15:18] <fginther> infinity, I sent some private messages, please let me know if you didn't receive
[15:23] <sil2100> slangasek: hi!
[15:24] <sil2100> slangasek: we were able to verify all unity/nux/unity-2d related SRU bug fixes from the pending SRU task queue
[15:24] <sil2100> slangasek: all is green ;)
[15:24] <ogra_> sil2100, properly tested on arm ?
[15:25] <ogra_> :)
[15:25] <sil2100> ogra_: erm ;)
[15:25] <ogra_> and patches updated etc ...
[15:29] <Daviey> barry: it built when last uploaded, so something in the environment has changed.. not the package.
[15:30] <Laney> if only that meant it wasn't a bug in the package
[15:30] <barry> Daviey: doko thinks it may be a twisted update
[15:31] <Daviey> certainly possible :)
[15:31] <barry> Daviey: my suspicion is that, while the test failures are obvious bugs, they aren't the root cause.  i am going to fix the obvious bugs and try another local build.
[15:31]  * xnox twisted update or update to twisted package....
[15:32] <Daviey> barry: thanks
[15:46] <barry> Daviey, doko: well, maybe we got lucky with it.  fixing those obvious bugs fixes the ftbfs, and that's all we care about, right? :)
[15:46] <barry> anyway, i'll upload the fix
[15:54] <Daviey> barry: thanks muchly!!
[15:54]  * zyga has brief connection issues on the regular machine
[15:59] <hrw> doko: iptraf ftfbs fixed by new upload to Ubuntu. patch sent to Debian
[16:00] <hrw> shit. its main not universe
[16:01] <hrw> doko: http://people.linaro.org/~hrw/ubuntu/to-sponsor/ has fixed iptraf
[16:11] <sil2100> ogra_: we don't really have the tools to test unity 3d on arm ;(
[16:12] <sil2100> ogra_: but it builds!
[16:12] <hrw> sil2100: how do you test unity 3d on x86?
[16:12] <ogra_> sil2100, *every* team in the company has pandaboards, if you dont have any yet, please talk to your manager (which will likely have to ask rickspencer3 )
[16:13] <sil2100> hrw: we run it, we run autopilot on it, we run manual tests
[16:13] <ogra_> s/which/who/
[16:13] <sil2100> ogra_: popey !
[16:13] <sil2100> ^
[16:13] <ogra_> sil2100, beyond that you can ask QA for SRU test help
[16:14] <sil2100> ogra_: anyway, thanks for the reminder - when I'm doing typical desktop stuff, I tend to forget the important stuff
[16:14] <sil2100> Like arm!
[16:15] <ogra_> well, its just that someone has to fix it if its brokebn in the end ... the last times we did that it burned a lot of workhours
[16:16] <hrw> I would love to forget about pandaboard (and other cheap boards) existance ;)
[16:16] <ogra_> so pretty please test before uploading if any possible
[16:17] <popey> thanks ogra_
[16:18] <ogra_> hrw, any expesive boards that are better ?
[16:18] <xnox> hrw: actually pandaboards are not that cheap =) it's not like it's raspberry pi.
[16:18] <ogra_> lol
[16:18] <ogra_> you cant compare the two
[16:18] <hrw> xnox: I do not bother with <armv7a boards
[16:18] <ogra_> RPi is as powerful as the beaglebone
[16:18] <ogra_> and costs about the same
[16:19] <hrw> ogra_: problem is that no one wants to produce serious boards
[16:19] <ogra_> (but the bone is an open HW platform, RPi is completely closed)
[16:19] <hrw> ogra_: beaglebone >>>> r/pi ;D
[16:19] <ogra_> yeah
[16:19] <ogra_> but the hype factor is so much lower ;)
[16:20] <hrw> I have to write 2012 edition of 'whats wrong with those cheap developer boards'
[16:20] <hrw> s/developer// anyway
[16:20] <infinity> doko: Ouch, those test-rebuild results aren't comforting.
[16:20] <hrw> anyway so far I do not bother with <armv8a - things may change if popey will request me to care about armv7a again
[16:21] <popey> heh
[16:22] <smoser> anyone around familiar with initramfs?
[16:23] <ogra_> smoser, just ask ?
[16:23] <smoser> i'm looking at open-iscsi, which runs a module at local-top
[16:23] <smoser> init (http://paste.ubuntu.com/1224803/)
[16:23] <smoser> i dont see how it can assume that any modules have been loaded, and thus 'configure_networking' is going to have network devices to configure
[16:23] <smoser> (i know it seems to work for me, but i'm not sure i understand how)
[16:24] <hrw> popey: do not heh :) I am now working on aarch64 for most of my time
[16:24] <infinity> hrw: You forgot update-maintainer(1) on that uptraf upload.
[16:25] <infinity> hrw: (Fixing and sponsoring)
[16:25] <ogra_> smoser, udev should load the module
[16:26] <sarnold> smoser: line 237 runs load_modules, fwiw
[16:26] <hrw> infinity: ops, it was 3-4 iteration of change... one of them had it done ;)
[16:27] <ogra_> sarnold, that only loads from /etc/modules
[16:27] <smoser> sarnold, right. but that is after init-top ran
[16:27] <smoser> ogra_, is correct about udev
[16:27] <smoser> i suppose ther emust be some udevadm settle
[16:27] <smoser> somewhere.
[16:27] <ogra_> smoser, the open-iscsi script should have a PREREQ var at the top
[16:27] <smoser> it does not
[16:28] <smoser> http://paste.ubuntu.com/1224813/
[16:28] <hrw> infinity: tomorrow I hope to find some time to take a look at other ftfbs entries
[16:28] <infinity> hrw: Cool, thanks.
[16:29] <smoser> so, the fact that udev is run at init-top was the bit  i was missing. but it would sure seem that modules should be loaded even before udev.
[16:30] <ogra_> smoser, then you are just lucky that udev ran before (if it actually lives in init-top too)
[16:30] <smoser> udev runs in init-top, openiscsi runs at local-top
[16:30] <smoser> but i think its still lucky
[16:30] <ogra_> no
[16:30] <ogra_> then its fine
[16:30] <smoser> where would a 'settle' be run?
[16:30] <ogra_> local-top runs after init
[16:30] <ogra_> in the udev script i think
[16:31] <smoser> i dont see it there.
[16:32] <ogra_> smoser, /usr/share/initramfs-tools/scripts/functions
[16:33] <smoser> where do you tihnk that gets called from ?
[16:33] <smoser> just curious
[16:34] <hrw> infinity: for most of my foss life I was kind of Build Engineer ;)
[16:34] <infinity> hrw: Sounds familiar. ;)
[16:34] <ogra_> smoser, not from open-iscsi, but you could if you dont want to count on pure luck
[16:35] <ogra_> smoser, see the nfs scripts ...
[16:36] <smoser> right. so its luck.
[16:36] <smoser> realistically, configure_networking should do it.
[16:47] <Laney> barry: do you fancy forwarding the python-tx-tftp fix upstream?
[16:55] <barry> Laney: sure
[16:56] <Laney> cheers
[16:56] <tumbleweed> naughty barry? :)
[16:56] <Laney> Forwarded: no make laney sad
[16:57] <barry> mostly just timing :)
[17:07] <smoser> anyone know what creates the 'netdev' group ?
[17:08] <stgraber> smoser: at least avahi-daemon and wpasupplicant, likely some others
[17:09] <barry> Laney: https://github.com/shylent/python-tx-tftp/issues/8
[17:24] <cjwatson> smoser: user-setup used to, in feisty and gutsy
[17:26] <smoser> cjwatson, i was just trying to figure out why it was there. its been presnt in the cloud-images for all releases i've been involved with (came from vmbuilder and behavior was moved forward).
[17:26] <smoser> hanks.
[17:26] <Laney> barry: thanks muchly
[18:05] <micahg> trism: what's this npapi-sdk.pc you speak of?
[18:09] <trism> micahg: one of the checks in gecko-mediaplayer configure.in is for npapi-sdk (for https://wiki.mozilla.org/NPAPI I imagine), my thought was firefox-dev could just provide npapi-sdk instead of mozilla-plugin since it only has the npapi headers now
[18:09] <trism> micahg: and mozilla-plugin.pc includes stuff we don't have in firefox-dev anymore (like /usr/lib/firefox-devel)
[18:09] <micahg> trism: that would be nice, but it doesn't exist in mozilla-central AFAICT
[18:10] <micahg> mozilla-plugin.pc just includes paths
[18:10] <trism> micahg: yeah it was just a thought, the workaround in gecko-mediaplayer should be fine
[18:10] <trism> micahg: yes paths that don't exist
[18:15] <micahg> trism: both of those directories exist on my sytem
[18:15] <micahg> *sysyem
[18:15] <micahg> *system
[18:15] <trism> micahg: precise? because /usr/lib/firefox-devel isn't in quantal
[18:15] <micahg> ah, right
[18:16] <micahg> yeah, that's a bug
[18:16] <micahg> oops, need to install the package first...
[18:18] <micahg> chrisccoulson: ^^ shouldn't we patch sdkdir out of the mozilla-plugin.pc file since we're not providing it?
[19:04] <SpamapS> hallyn: having trouble with lxc on quantal.. I see a lot of this..
[19:04] <SpamapS> [19878.384552] unregister_netdevice: waiting for lo to become free. Usage count = 1
[19:04] <SpamapS> stgraber: ^^
[19:05] <stgraber> yep, it's known, it's the second time you're affected btw, I already got you to comment on the bug last time ;)
[19:05] <SpamapS> Yes I recall
[19:05] <SpamapS> just wasn't SURE it was the same thing
[19:06] <SpamapS> stgraber: upstream is fixed right? so its just a matter of figuring out how and backporting?
[19:06] <stgraber> ogasawara: any progress on that one? ^ I'm really not looking forward to releasing with that regression
[19:06] <SpamapS> its pretty serious for the juju local dev story :(
[19:06] <stgraber> SpamapS: upstream is apparently fixed (that or the kernel was somehow different) but nobody figured out what to cherrypick yet
[19:06] <stgraber> SpamapS: the kernel team is supposedly on it but doesn't seem to be making a lot of progress lately (based on the comments)
[19:07] <ogasawara> stgraber: I've pinged cooloney for a status update today
[19:07] <stgraber> ogasawara: ok, thanks
[19:07] <ogasawara> stgraber: I won't be fixed for Beta-2, but I want it figured out by kernel freeze.
[19:08] <ogasawara> s/I/It/
[19:08] <stgraber> ogasawara: yeah, wasn't expecting it to be fixed for beta-2 but it's not something I'd like to see miss the release. We had to go through something similar last time with some apparmor issues and I'm still getting e-mails from people running a buggy kernel (original 12.04 release kernel)
[19:09] <stgraber> (apparently you can't assume that people apply updates on their machine...)
[19:11] <hallyn> ogasawara: i don't want to step on coolonely's toes, but if he's short on time should i be changing some other priorities to look into that one (netns refcount bug)?
[19:11] <SpamapS> stgraber: kernels are especially prone to that because some people reboot so seldom.
[19:12] <SpamapS> the bad part about this one is that once it happens, lxc just seems hosed
[19:12] <ogasawara> hallyn: I'll be pulling in smb as backup if cooloney hasn't already got the fix isolated.  I should hear more by morning.
[19:12] <SpamapS> have to reboot :-P
[19:13] <SpamapS> root     29866  0.0  0.0  27532  1028 ?        Ds   12:01   0:00 lxc-start --daemon -n clint-local-ci-u2-0 -l DEBUG -o /home/clint/.juju/data/clint-loc
[19:13] <SpamapS> lxc-starts just go into diskwait (presumably on some cgroup operation)
[19:13] <hallyn> ogasawara: great, thanks
[19:30] <jP_wanN> hello :)
[19:30] <jP_wanN> I recently found a bug in gtkmm ( at least I think so :D ). For which package do I create a bug report?
[19:30] <jP_wanN> libgtkmm-3.0-dev or libgtkmm-3.0.1
[19:32] <sarnold> jP_wanN1: the -dev is really there for compiling other packages against libgtkmm; if you found the problem that way, then the -dev would make more sense to me, lacking any further direction...
[19:34] <jP_wanN1> sarnold: no, I've got a problem using gtkmm in a program I'm programming. so i should file a bug for libgtkmm-3.0.1 ?
[19:35] <jP_wanN1> by the way, why did thunderbird add a "1" to my nick / how to change that? some time before, the authorization worked fine.
[19:35] <sarnold> jP_wanN1: I'd probably file against the -dev package. (Since it's liable to be the same source package in the end, it might not even matter)
[19:35] <jP_wanN1> okay thanks
[19:35] <jP_wanN1> i'll try to reconnect now ^^
[19:44] <jP_wanN> okay now I searched to avoid filing a duplicate of an existing bug
[19:44] <jP_wanN> seems I should have done that before :D
[19:45] <jP_wanN> now that bug report is for gtkmm 2.4 (ubuntu 7.10)
[19:46] <jP_wanN> it's marked as incomplete
[19:46] <jP_wanN> should i file a new bug?
[19:48] <sarnold> jP_wanN: hah, good question :) that's an _old_ bug for a distro that's probably long unsupported...
[19:49] <cjwatson> bugs don't in general go away when the release they were filed on stops being supported ...
[19:50] <jP_wanN> sarnold: Yes I know, Ubuntu 7.10 is quite old :D I'll just open another bug and add a link to the other one I've found.
[19:50] <cjwatson> (http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-02-27-bug-triage-rants.html)
[19:51] <sarnold> thanks cjwatson :)
[19:51] <jP_wanN> cjwatson: I also found out that there was some issue like this (_could_ be the same) that was (should have been) fixed with gtkmm 2.8
[19:51] <stgraber> cjwatson: it's been a while since I last saw you point to that link ;)
[19:51] <jP_wanN> btw, here is the bug report i dounf https://bugs.launchpad.net/ubuntu/+source/gtkmm2.4/+bug/30345
[19:59] <jP_wanN> so here is the new bug report if anyone cares ^^
[19:59] <jP_wanN> https://bugs.launchpad.net/ubuntu/+source/gtkmm3.0/+bug/1055744
[20:00] <jP_wanN> now, can somebody tell me how I can (try to) debug gtkmm myself? :)
[20:04] <jP_wanN> I've already read and completed the tutorial
[20:04] <jP_wanN> http://developer.ubuntu.com/packaging/html/getting-set-up.html
[20:06] <seb128> cyphermox, still around? if you see robert_ancell around later could one of you reupload evolution to quantal-proposed with a build-depends on libgtkhtml4.... > 3.6? the current version built with 3.5 and the shlibs in gtkhtml4 is using a >> << that breaks installability
[20:06] <cyphermox> oops
[20:06] <cyphermox> sure
[20:07] <cyphermox> I wish I could fix the webkit plugin stuff first, then it would be fixing two bugs with one stone
[20:08] <bkerensa> seb128: what day of week are patch pilots done?
[20:08] <seb128> bkerensa, https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
[20:09] <bkerensa> seb128:  grazi
[20:09] <seb128> yw ;-)
[20:12] <seb128> cyphermox, thanks
[21:44] <james_w> any ideas as to why a build in sbuild wouldn't have a debian dir?
[21:47] <james_w> no, that's not it
[21:47] <james_w> make: dpkg-architecture: command not found
[21:48] <mlankhorst> needs dpkg-dev?
[21:48] <james_w> mlankhorst, I'm pretty sure it's installed
[21:51] <mwhudson> james_w: architecture mismatch?
[21:51] <james_w> mwhudson, possibly
[21:52] <james_w> mwhudson, I'm not sure how though, as I'm not seeing it outside the chroot
[21:52] <mwhudson> just because that can lead to arbitrarily confusing error messages ime
[21:52] <mlankhorst> oh right
[21:52] <james_w> I'm starting to think that message doesn't mean "dpkg-architecture command not found"
[21:52] <mlankhorst> try to ldd it? maybe one of the libraries it depends on is missing
[21:52] <mwhudson> james_w: as in running $chroot/usr/bin/dpkg-architecture works?
[21:53] <james_w> mwhudson, as in "dpkg-architecture" works, but "$(shell dpkg-architecture)" in debian/rules doesn't
[21:53] <james_w> just on my base system
[21:53] <mwhudson> oh
[21:58] <slangasek> james_w: that error /should/ mean that the dpkg-architecture command isn't found.  $PATH issue?
[21:58] <slangasek> (strace to debug?)
[21:58] <james_w> oh
[21:58] <james_w> /usr/bin/dpkg−architecture
[21:59] <slangasek> hahaha
[21:59]  * slangasek waves at the emdash
[21:59] <mwhudson> lol
[21:59] <mwhudson> how did you do _that_?
[21:59] <sarnold> cjwatson: re: bug triage, you mention, "Check whether the package is being actively worked on." -- what's the best way to tell if a package is actively being worked on? MOTU vs a developer name in apt-cache output?
[22:00] <james_w> mwhudson, copied from a web page
[22:00] <cjwatson> sarnold: changelog is a reasonable guide
[22:00] <sarnold> cjwatson: say, if it shows more than just "import from debian" entries?
[22:02] <cjwatson> That's one option, though sometimes that means a REALLY active Ubuntu developer who's just also active enough in Debian to push everything there.
[22:02] <cjwatson> You do have to use judgement.
[22:02] <sarnold> cjwatson: aha. :) good point. Thanks!
[22:07] <lamont> why is it that when I lock my screen and go away and come back, I'm thankful that I told it to let ctl-alt-backspace kill X, since I can't get the opportunity to type in my password and unlock the screen?
[22:12] <sarnold> lamont: I wonder if you've hit https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1054198 or similar bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/966744  (probably too polluted)
[22:12] <doko> cjwatson, is the regexp syntax in the seeds regexp or extended regexp?
[22:14] <lamont> 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 18)
[22:14] <lamont> sarnold: ^^
[22:14] <lamont> I get a black screen, and a mouse cursor
[22:14] <lamont> s/mouse//
[22:14] <sarnold> lamont: we may have a winner :)
[22:15] <lamont>         Kernel driver in use: i915
[22:19] <cjwatson> doko: python re
[22:19] <cjwatson> doko: which is closer to extended iirc