[00:43] <slangasek> SpamapS: so I have an experimental myodbc package now that will build against mysql-5.5 finally
[00:43] <SpamapS> slangasek: !!
[00:43] <SpamapS> slangasek: I've been shunning even looking at that hoping you'd figure it out
[00:43] <slangasek> upon prodding, I've disabled building the testsuite... since we can't run the darn thing anyway at build time :P
[00:44] <slangasek> SpamapS: where did we leave off?  Do I need to sponsor mysql-5.5 in with the _r.so compat fix?
[00:45] <SpamapS> slangasek: for Debian there's additional work needed to push back the stuff I've done for precise.
[00:45] <slangasek> mmk
[00:45] <SpamapS> slangasek: I think actually all of it is legitimate ubuntu-only delta
[00:46] <SpamapS> slangasek: though eventually I'd like to get back in sync.. maybe after precise releases.
[00:46] <SpamapS> slangasek: I am working on preparing 5.1.61 packaging for stable as well.. since we're forced to release that as the security update
[00:47] <SpamapS> slangasek: meanwhile my DD app drips through the process like mollasses on a cold day.
[00:48] <slangasek> heh
[00:50] <broder> from my read of the new livecd-rootfs, it looks like we're not actually using the .iso that live-build generates, but just grabbing the stuff out of binary/ and reusing it somewhere else. is that right?
[00:51] <SpamapS> slangasek: anyway, it would appear that we're down then to just sphinxseach for libmysqlclient..
[00:52] <SpamapS> I believe a new upstream version came out recently that might address the last few issues.
[00:52] <slangasek> broder: yes, we feed live-build artifacts into debian-cd so it can stick a germinated archive on the side
[00:52] <slangasek> SpamapS: ah, ok
[00:53] <slangasek> SpamapS: as for nis, I've dropped a comment on bug #569757... wondering what you think we should do
[00:54] <slangasek> (looking for feedback before I upload this to precise, since if you don't want us to go this route, it makes the SRU upgrade path harder)
[00:55] <SpamapS> slangasek: reviewing
[00:58] <SpamapS> slangasek: just a thought that I keep having.. we should look at patching portmap/rpcbind to use 'start on socket' in the next release. It would make this *much* simpler.
[00:59] <SpamapS> slangasek: same goes for the NFS jobs too.. no more ON_BOOT thingy
[00:59] <slangasek> the NFS stuff isn't going to be that easy
[00:59] <slangasek> in part because it has to wait for /usr
[01:00] <slangasek> I suppose it shouldn't hurt to make portmap 'start on socket'
[01:00] <SpamapS> slangasek: ugh.. I just noticed.. upstart-socket-bridge isn't really built in.. so we'd have to start on started that anyway.. argh.
[01:00] <slangasek> hah
[01:01] <SpamapS> was that one of those TODO's still left on Keybuk's plate?
[01:01] <slangasek> I don't know
[01:01] <SpamapS> Seems like upstart is already watching a few sockets.. :-P
[01:01] <broder> i think it was deliberate that the socket bridge live as a separate binary
[01:01] <broder> you shouldn't have to wait for the socket bridge to start though
[01:02] <broder> err, the thing that wanted to use the socket would have to, though
[01:02] <SpamapS> broder: right, thats the point
[01:02] <slangasek> yes, and that's exactly what has to wait on portmap now :)
[01:02] <slangasek> SpamapS: I'm guessing this was an overlooked bug
[01:02]  * broder promises to stop jumping in mid-conversation without thinking for at *least* the next 5 minutes
[01:03] <SpamapS> :)
[01:03] <SpamapS> broder: at least you *thought* at one point. :)
[01:03] <SpamapS> I'm having a harder and harder time doing that today..
[01:04] <SpamapS> slangasek: your loop in the ypbind post-start hits a bug I recently discovered in polling post-starts ..
[01:04] <slangasek> oh?
[01:04] <SpamapS> slangasek: mysql had it too. If the job respawns or is stopped .. the polling doesn't stop.
[01:04] <slangasek> hmm, I think there's a bug report for that already
[01:05] <slangasek> possibly from you
[01:05] <SpamapS> slangasek: but the respawn doesn't actually get tried until post-start exits
[01:05] <SpamapS> slangasek: yeah there is
[01:05] <SpamapS> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/mysql-5.5/precise/revision/16
[01:05] <SpamapS> bug 711635
[01:06] <SpamapS> slangasek: in the workaround.. you have to drop the respawn limit lower.. because that sleep 1 always gets hit at least one time
[01:06] <slangasek> ah, I meant an open bug on upstart
[01:07] <SpamapS> slangasek: 711635 is also against upstart :)
[01:07] <slangasek> ah right
[01:09] <SpamapS> I don't actually know what upstart should do.. but its definitely confusing the way it works right now.
[01:09] <SpamapS> I'm kind of hoping the 'expect exit' stuff will do away with most of the times where people use post-start to poll like that.
[01:09] <slangasek> oh hah, yes, this is the bit where it will never *hit* the respawn limit because the post-start script takes too long, blah
[01:09] <slangasek> well, none of the usual 'expect's work for ypbind
[01:09] <slangasek> it daemonizes and then goes looking for a directory source
[01:09] <SpamapS> heh, so it also has races already?
[01:10] <slangasek> built in
[01:10] <slangasek> this post-start is copied from the init script
[01:10] <SpamapS> slangasek: are we in danger of breaking shutdown for some daemons by stopping on runlevel [!2345] ?
[01:11] <SpamapS> slangasek: like if a daemon needs to lookup users to run its shutdown..  would we be breaking it?
[01:13] <slangasek> potentially, but that's not a regression vs. pre-lucid or debian so I figured I'd let someone else sort that out
[01:15] <SpamapS> slangasek: agreed. Other than the looping bug I'd say this is good to go.
[01:16] <slangasek> ok
[01:16] <slangasek> looking to see if there's a way I can make the post-start fail faster in the case where ypbind isn't running
[01:17] <SpamapS> slangasek: well you could actually check for respawn before the check for the socket....
[01:17] <SpamapS> slangasek: that would give a better chance at hitting the default 10 respawns in 5 seconds limit
[02:25] <slangasek> SpamapS: hmm? how would I check for respawn within the script?
[04:43] <pitti> Good morning
[04:57] <ajmitch> morning pitti
[05:54] <pitti> stgraber: accepting ltsp-cluster-agent for now, but please convert to dh_python2; it currently b-deps on pycentral, although I'm not sure that it actually uses that
[07:10] <SpamapS> slangasek: status shows it as a status.. start/respawn
[07:28] <slangasek> SpamapS: hmm?  how are you forcing it to respawn, just killing the process?
[07:31] <SpamapS> slangasek: if the process dies, upstart notes that and marks state as "respawn".. but it does not do another state transition until the post-start exits
[07:31] <slangasek> SpamapS: sure - you're seeing this in the wild, or you're testing it by killing the process?
[07:31] <SpamapS> slangasek: so in post-start at any time you can see if the process has died and is going to be respawned, and react
[07:31] <SpamapS> slangasek: I saw this with mysql when it had an invalid configuration
[07:31] <slangasek> oh, you're responding to my earlier question, aren't you :)
[07:32] <slangasek> right, so we could call status to get the info, cool
[07:32] <SpamapS> slangasek: mysql already does this to hasten the reaction time to horribly broken mysql configs
[07:34] <dholbach> good morning
[07:44] <dholbach> geser's merge of vim seems to have been rejected and I can't find an explanation in https://lists.ubuntu.com/archives/ubuntu-archive/2012-February/thread.html or in the mail I received
[07:45] <pitti> dholbach: there is one in unapproved: https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[07:45] <dholbach> aha
[07:45] <dholbach> thanks pitti
[07:46] <micahg> dholbach: there was a sacrilegious removal of a sentimental comment apparently :)
[07:46] <dholbach> :-)
[07:54] <dholbach> pitti, do you think you could move libquvi-scripts to main, so we can get libquvi to build?
[07:54] <pitti> dholbach: I just did
[07:54] <dholbach> ah, sweet :)
[09:23] <geser> dholbach: see this channel around 23:00 (local time), infinity had feelings about the removed changelog entries and re-uploaded my vim merge with complete changelog
[09:25] <geser> dholbach: http://irclogs.ubuntu.com/2012/02/27/%23ubuntu-devel.html#t20:27 and http://irclogs.ubuntu.com/2012/02/27/%23ubuntu-devel.html#t22:25
[09:49] <dholbach> geser, ok, I see
[10:03] <AnAnt> Hello, Debian has a new revision of fribidi which is multi-arch enabled (it should be in testing within a day or two), would it be possible to sync it after beta release ?
[10:04] <tumbleweed> AnAnt: file an FFe
[10:04] <AnAnt> ok
[10:04] <tumbleweed> there are a fair number of reverse-depends, you'll need to check that they don't have hardcoded paths
[10:16] <jokerdino> hey devs, just a question regarding https://bugs.launchpad.net/ubuntu/+source/usermode/+bug/602680
[10:17] <jokerdino> the original assignee has gone awol for quite some time. and I don't mind fixing it. anything that i can do about that?
[10:49] <dholbach> Laney, goocanvas and gda bindings are in now - it looks like the way is clear to get glom in again too
[10:50] <dholbach> I'm going to be a busy in the next days - do you think either you or seb128 could take a look at the current package in the openismus ppa?
[11:11] <pitti> Laney: btw, now would be an excellent time to start a haskell transition -- all buildds are idling
[11:34] <Laney> dholbach: nice, will see if I can get time but others are more than free to do it
[11:35] <Laney> pitti: aye, now would be good indeed to get ghc itself built in time for freeze ending
[11:35] <Laney> iulian is going to do the ghc upload
[11:44] <seb128> Laney, seems you are busy, I will try to have a look, ping me before looking at it in case you do so we don't dup work
[11:44] <seb128> dholbach, ^
[11:44] <janimo`> micahg, chrisccoulson hi, is either of you looking at the armhf chromium ftbfs?
[11:47] <ogra_> janimo`, i think micahg and infinity looked into it recently, seems to be a multiarch/naming issue
[11:47] <ogra_> not sure thesy came to any result, i just saw them discussion the issue
[11:47] <ogra_> *discussing
[11:47] <janimo`> ogra_, ok, indeed looks like an include path not being set to the gnueabihf dir
[11:48] <ogra_> if you have a quick fix, please go ahead ;)
[11:48] <janimo`> no idea if the fix sits committed somewhere though.
[11:48]  * ogra_ thinks then we would have also seen an upload
[11:48] <janimo`> no quick fix, just wondering whether I should start investigating myself, there's no bug discussion
[11:49] <ogra_> i think they planned to revisit it after B1
[11:51]  * dholbach hugs seb128 and Laney
[11:52]  * seb128 hugs back
[12:33] <jokerdino> hmm guys is branching from lp:gedit same as lp:lp:~ubuntu-desktop/gedit/ubuntu
[12:33] <jokerdino> ?
[12:33] <seb128> jokerdino, no
[12:33] <seb128> lp:gedit is an upstream import of full source without packaging
[12:33] <jokerdino> i see.
[12:33] <seb128> lp:~ubuntu-desktop/gedit/ubuntu is the packaging vcs which contains de debian dir only
[12:34] <jokerdino> so, if i want to submit a patch, i will be using the ubuntu-desktop branch..
[12:34] <jokerdino> what if ubuntu is the main stream?
[12:35] <jokerdino> (for software-center, unity, etc)
[12:37] <seb128> jokerdino, you usually want to use debcheckout
[12:37] <seb128> jokerdino, or apt-get source
[12:37] <seb128> jokerdino, i.e
[12:37] <seb128> $ apt-get source gedit
[12:37] <seb128> ...
[12:37] <seb128> NOTICE: 'gedit' packaging is maintained in the 'Bzr' version control system at:
[12:37] <seb128> https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu
[12:38] <jokerdino> ah, i have been doing this incorrectly the whole time :/
[12:38] <seb128> jokerdino, the "standard" location for packages is ubuntu:<source> but if there a vcs in the control you should use this one
[12:38] <seb128> debcheckout has this logic and should give you the right source
[12:40] <jokerdino> hmm, thanks!
[12:40] <jokerdino> so, if i want to patch something, how do i proceed?
[12:40] <seb128> jokerdino, desktop thing?
[12:41] <seb128> jokerdino, https://wiki.ubuntu.com/DesktopTeam/Bzr
[12:41] <jokerdino> i proposed a patch for gedit quicklist earlier.
[12:41] <jokerdino> i branched from lp:gedit and made the changes by branching locally and deriving a diff file
[12:41] <seb128> jokerdino, basically bzr get lp:~ubuntu-desktop/gedit/ubuntu; cd ubuntu; bzr bd-do; edit patch; exit 0
[12:42] <jokerdino> and then i attached the patch to the bug report.
[12:42] <seb128> jokerdino, you can just add a debdiff or diff to a bug if you prefer
[12:42] <seb128> that works fine
[12:42] <seb128> jokerdino, I put those patches review on hold since we are frozen for beta1 and we need to sort of some details on those unity list instructions
[12:43] <seb128> jokerdino, especially we need to sort out what's the standard wording we want and a minor detail with the syntax, I will review your patch in a few days
[12:43] <jokerdino> ah, cool.
[12:43] <seb128> jokerdino, sorry about that, we noticed some issues in consistency when we started reviewing patches, especially on capitalization of the text used
[12:44] <seb128> so we need to sort those out before merging in
[12:44] <jokerdino> i am fine, either way.
[12:44] <jokerdino> and, one small addition.
[12:45] <jokerdino> custom groups in a desktop file should have a X- in front. please do update the unity quicklist api..
[12:45] <seb128> jokerdino, yeah, sorry, the syntax is about to change, I will fix those when merging
[12:46] <seb128> jokerdino, see https://wiki.ubuntu.com/Unity/LauncherAPI?action=diff&rev2=32&rev1=31
[12:46] <seb128> jokerdino, the wiki got updated yesterday
[12:46] <jokerdino> oh awesome, i didn't check it yet.
[12:47] <seb128> jokerdino, it's an accepted xdg spec now, and the syntax has changed a bit, the code supports both though
[12:48] <jokerdino> well yeah the code supports both, but desktop-file-validate invalidates it, as you pointed out in the bug report.
[12:48] <jokerdino> X-Ayatana-Desktop-Shortcuts=X-Screen;X-Window
[12:48] <jokerdino> [X-Screen Shortcut Group]
[12:48] <seb128> jokerdino, right, using the updated way should work fine
[12:48] <jokerdino> should be like that ^
[12:48] <seb128> ie with action groups
[12:51] <jokerdino> so, the proposed way is to do like [Desktop Action Screen], right?
[12:52] <jokerdino> i mean recommended, not proposed.
[12:52] <seb128> jokerdino, yes, what the current wiki describe
[12:58] <jokerdino> seb128: there should be a colon (;) after the last Actions entry.
[12:58] <seb128> jokerdino, thanks, it's a wiki feel free to add it
[12:59] <seb128> i.e you can probably edit the page ;-)
[12:59] <jokerdino> Heh :)
[13:01] <jokerdino> wiki has been updated.
[13:01] <jokerdino> (by adding a single character)
[13:02] <jokerdino> should I then proceed to update my patch?
[13:02] <seb128> jokerdino, yes ;-)
[13:17] <jokerdino> cheers seb128, patch has been updated.
[13:17] <jokerdino> and i have removed the older patches.
[13:17] <seb128> jokerdino, thanks, I will review it a bit later
[13:41] <doko> zul, python-tz tries to test the installed pytz, ... and ftbfs ...
[13:42] <zul> doko: ok ill have a look
[13:59] <larsduesing> Hi together
[14:00] <larsduesing> Short question, how to get a patch I wrote and put to a ppa into ubuntu?
[14:01] <larsduesing> (I think I made some error in launchpad...)
[14:01] <larsduesing> (hopefully, this is the right place...)
[14:02] <ScottK> barry: Would you have time to look at Bug 942408?
[14:03] <ScottK> larsduesing: File a bug (or find an existing one), attach the patch to it, and then subscribe the ubuntu-sponsors team to the bug.  Someone will review it for inclusion.
[14:03] <larsduesing> ah...
[14:03] <larsduesing> thanks ScottK ... #223825
[14:04] <larsduesing> Oh.. 223825 is the bug
[14:04] <larsduesing> (i made it fix released
[14:04] <larsduesing> in error...
[14:05] <larsduesing> hmm... ubottu is not liking me..
[14:05] <apw> jodh, wondering what inotify events upstart uses to monitor its configurations
[14:05] <ScottK> larsduesing: I moved it back to Triaged.
[14:06] <brendand> bug 223825
[14:08] <larsduesing> thanks ScottK
[14:08] <ScottK> You're welcome.
[14:09] <larsduesing> ah you have to add bug in front of the number to get ubottu like you... *learn*
[14:10] <jodh> apw: (IN_CREATE | IN_DELETE | IN_CLOSE_WRITE| IN_MOVE | IN_MOVE_SELF)
[14:11] <apw> jodh, against /etc/init ?
[14:12] <jodh> apw: yes.
[14:16] <stgraber> pitti: thanks
[14:17] <stgraber> highvoltage: saw pitti's comment above on ltsp-cluster-agent* and pycentral?
[14:21] <highvoltage> stgraber: I have now. I was planning on doing that a few weeks back but got hasty when feature freeze approached. (I uploaded them 8s before FF). I can still fix that, right?
[14:29] <barry> ScottK: sure
[14:31] <ScottK> barry: Thanks.
[14:43] <pitti> highvoltage: yes, of course
[14:47] <stgraber> highvoltage: yes, though you may need a FFe for that (easy one to get though) as changing the build system may trigger side effects
[14:47] <highvoltage> stgraber: ok
[14:48] <pitti> is it using pycentral anyway?
[14:48] <pitti> debian/rules had no indication of this
[14:48] <pitti> it might just be an obsolete build depends
[14:50] <stgraber> pitti: I'd have to look at exactly what highvoltage uploaded as I believe he made some changes on my initial packaging. ltsp-cluster-agent definitely ships a python module so it might be using pycentral (was using python-support before) and would need a switch to dh_python2 if that's the case. ltsp-cluster-agent-weblive just ships a bunch of files, no python modules so shouldn't need pycentral/pysupport anyway.
[14:51] <stgraber> (ouch, that was a long line, wondering if it got cut...)
[14:53] <highvoltage> it seems to have made it. last part was "pycentral/pysupport anyway."
[15:21] <barry> is anybody look at the python-tz ftbfs? https://launchpadlibrarian.net/94621468/buildlog_ubuntu-precise-i386.python-tz_2011k-0ubuntu4_FAILEDTOBUILD.txt.gz
[15:29] <ScottK> barry: zul is supposed to look into it.
[15:29] <barry> ScottK, zul: okay
[15:55] <siretart> Is the beta freeze a soft freeze or are all uploads moderated? I've prepared a fix for lightdm and would like to upload it to the archive. I'm OK for it to hit the archive after beta release
[15:59] <ogra_> siretart, all uploads are moderated atm. and i'm not sure putting lightdm into the queue would be a clever thing, in the case wheer we might find a serious bug during testing in lightdm your upload would have to be recected before the fix goes in if we dont want it on the image
[16:00] <ogra_> siretart, but better ask the release manager :) (skaet) in #ubuntu-release
[16:01] <seb128> siretart, what fix?
[16:01] <skaet> siretart, its a hard freeze - we're only letting release critical fixes through for the seeded images.
[16:01] <seb128> siretart, better to get review for lightdm changes, it's not like we didn't have active maintainers
[16:21] <siretart> seb128: https://bugs.launchpad.net/lightdm/+bug/877766
[16:21] <siretart> the patch is obvious, and I have personally tested it on a spare machine at our lab
[16:22] <siretart> and we really should SRU that patch
[16:22] <siretart> the patch is in the linked bzr branch
[16:22] <seb128> siretart, can you put a merge request against lp:lightdm on? I mentioned that to robert_ancell before and he looked at it but I think he had some concerns
[16:23] <seb128> siretart, or it was breaking some tests in the testsuit
[16:23] <seb128> he said he needed to do some work before landing it I think
[16:23] <siretart> seb128: is having the patch as quilt in my packaging branch a problem for requesting a merge for lp:lightdm?
[16:24] <seb128> siretart, yes, can you bzr branch lp:lightdm, apply you patch, bzr commit, bzr push lp:~sirestart/lightdm/nfs and propose it for merging?
[16:24] <seb128> siretart, I'm not sure robert_ancell keeps up with bug emails, he does with merge requests though
[16:24] <siretart> how annoying :/
[16:24] <siretart> I'll put that on my todo list
[16:37] <seb128> siretart, it's not that hard...
[16:37] <seb128> siretart, I will ping him again about the patch
[16:37] <seb128> siretart, but I'm sure review would be easier in a merge request
[16:39] <siretart> let's please don't argue about necessary or silly burocracy
[16:40] <seb128> siretart, it's not "silly burocracy"
[16:40] <seb128> siretart, it's "people don't keep up with thousand of bug emails a week so don't see your comments"
[17:02] <Sweetshark> dammit launchpad! *shaking-angry-grandpa-fist*
[17:03] <Sweetshark> how do I get rid of this stupid duplicate libreoffice (openSUSE) tracker on bug 562027
[17:03] <Sweetshark> ?
[17:04] <ScottK> Sweetshark: I think you want #launchpad.
[17:05] <ScottK> siretart: I'd upload it, but I'm not a fan of silly bureaucray either.
[17:06] <stgraber> Sweetshark: so you want to drop the opensuse task entirely?
[17:08] <Sweetshark> stgraber: at least get rid of the duplicate tracked bug at freedesktop ...
[17:10] <Sweetshark> stgraber: funny thing is: there is a minus button behind almost all the other remote trackers, but not behind baltix and opensuse ....
[17:11] <stgraber> Sweetshark: hmm, yeah, the UI is confusing and forcing it gives me a LP oops ... you'll need #launchpad
[17:45] <ScottK> Anyone having trouble with pbuilder on a oneiric host system.  With --debug, I get "ignoring trap saveaptcache_umountproc_cleanbuildplace_trap exit sighup"
[17:45] <ScottK> (right before it dies with E: Invalide operation)
[18:10] <smoser> slangasek, bug 942788
[18:11] <smoser> slangasek, your hunch on --no-reread is correct. sfdisk is broken-by-design if udev is running and you do not pass --no-reread.
[18:12] <smoser> infinity, ^
[18:12] <slangasek> smoser: does this affects disks other than vda?
[18:12] <smoser> if you're using sfdisk, you need to be using --no-reread.
[18:12] <smoser> slangasek, yes.
[18:12] <slangasek> interesting
[18:12] <smoser> theres a shell snippet in the bug there.
[18:12] <smoser> just run that somewhere and it will fail eventually.
[18:12] <infinity> smoser: I wonder if we're using no-reread in jasper because we ran into that problem, or by sheer luck of cargo-culting from elsewhere. :P
[18:12] <infinity> smoser: And as I mentioned yesterday, we're using no-reread already. :)
[18:12] <smoser> ah.
[18:13] <slangasek> smoser: oh, but your snippet uses /dev/vdb ;)  My question is, does this affect other storage backends or is there something about this driver (virtio?) causing the issue
[18:14] <smoser> slangasek, i think its all backends.
[18:14] <slangasek> tested though?
[18:14] <smoser> (i thought your question about vda was "root")
[18:14] <smoser> well, smb has seen it on xvdb
[18:14] <slangasek> ok
[18:14] <smoser> err.. a xenblock device.
[18:14] <smoser> its very clearly broken.
[18:15] <smoser> basically: blockdev --rereadpt; blockdev --rereadpt;
[18:15] <smoser> the second one is almost certain to fail at some point.
[18:16] <smoser> i dont have a non-virtual system with an un-used block device or i would test
[18:17] <slangasek> smoser: could you do one more test and capture 'udevadm monitor -e' output while you're running sfdisk?
[18:20] <smb> Given that there will be an event for each partition and the main device for remove and then for each partition and the main device after scanning, it could be "worse" the more partitions there are...
[18:21] <slangasek> smoser: n/m, found a usb stick here to test with - confirmed that I get change events on reread even when there are no changes to the table
[18:21] <slangasek> so yeah, it's universal
[18:22] <smb> slangasek, Right, this is not intelligent, it just drops all knowledge and re-iterates
[18:22] <smoser> slangasek, attached to bug.
[18:23] <smoser> slangasek, smb, thank you both for your help.
[18:26]  * smoser goes to fix bug 937352 the right way
[18:29] <smoser> smb, so what do we think about the 'udevadm settle' that we added to growroot before invoking growpart (which in turn invokes sfdisk)
[18:29] <smoser> after the disk is mounted, do we think we need that settle?
[18:30] <smoser> or do we think, since a partition on $DEV has been mounted, that udev events related to it have been finished.
[18:30] <smoser> i guess it might just be safest to leave it there.
[18:30] <smb> smoser, Well, I think it jsut should not hurt much and at least helps to ensure anything that began before has sort of quieted down
[18:30] <smoser> yeah.
[19:02] <kklimonda> is there something in debian policy preventing packages from shipping scripts that meddle with files in /usr/share (creating new ones) in the directories owned by those packages?
[19:02] <kklimonda> for some reason I don't like it ;)
[19:04] <kklimonda> (freeipa server install script configures apache to use /usr/share/ipa/wsgi.py which will serve a custom html file (and some other things)
[19:11] <slangasek> kklimonda: the FHS says /usr is for static files; scripts generating data there are generally non-compliant
[19:21] <iulian> pitti, Laney: Do you want me to upload GHC now? I have it ready, just need to push the button and fire the missiles.
[19:52] <iulian> We'd have to apply the two patches from http://hackage.haskell.org/trac/ghc/ticket/5824 in order to fix the arm{el,hf} build failures.
[20:07] <micahg> janimo`: no, I don't have a fix, if you have one verified, I'm happy to commit it an upload (chromium is seeded in mythbuntu and lubuntu though, so we'd have to be sure that it builds and won't affect the other archs)
[21:00] <janimo`> micahg, no fix here. I touched chromium only once before and its build system is not the easiest to grok. No idea where the cflags are figured out
[21:02] <micahg> janimo`: should be in the gyp files, unfortunately, I have more pressing things to look at ATM, I can poke Debian's build to see if they have a fix (but  don't remember seeing one)
[21:02] <janimo`> micahg, I did not see one either in debian, no prob though
[21:02] <micahg> janimo`: will multiarch allow you to run the armel builds for now?
[21:02] <janimo`> yes
[21:03] <micahg> \o/ progress :)
[21:03] <janimo`> you mean armel chromium on armhf right?
[21:03] <micahg> yes :)
[21:03] <janimo`> then s/yes/probably/. Never tested :)
[21:04] <micahg> I wish armel would build on the stable releases, but that's another story :)
[21:04] <janimo`> I do not particularly need chromium on armhf now, just going through the FTBFS
[21:04] <micahg> janimo`: you have time to bootstrap gnat-4.6? :D
[21:05]  * janimo` runs away in horror
[21:05] <janimo`> infinity is the masochistic one, he should do it
[21:05] <micahg> wow, something more scary than chromium's build system :)
[21:19] <smoser> stgraber, hallyn how bad is this:
[21:19] <smoser> http://paste.ubuntu.com/861085/
[21:20] <smoser> should i even bother checking /proc/1/cgroup ?
[21:20] <smoser> i realize its very limited
[21:21] <hallyn> smoser: well, you might do that *after* the other checks.  i.e. if running-in-container is available, use it.
[21:21] <hallyn> if it isn't available,
[21:21] <hallyn> then chances are init hasn't moved itself toanother cgroup
[21:21] <smoser> k
[21:21] <stgraber> hallyn: +1
[21:21] <hallyn> that's not to say initramfs couldn't be messing with you, so it's not 100%
[21:22] <hallyn> systemd moves itself to /systemd very early on
[21:22] <hallyn> (i think.  maybe not.  maybe it just sets it up for user sessions)
[21:23] <smoser> hallyn,
[21:23] <smoser> i just created a container
[21:23] <smoser> logged in with ubuntu ubuntu
[21:23] <smoser> and then tried sudo
[21:23] <smoser> oh..
[21:23] <smoser> and its prompting me for a password
[21:23] <smoser> (i justrealized i had a password)
[21:23] <smoser> duh
[21:24] <infinity> micahg, janimo`: gnat's being worked on.
[21:25] <micahg> infinity: ah, good :)
[21:39] <doko> infinity, if you build gnat for armhf, you might want to disable multilibs
[21:45] <elmo> where do the modules in a d-i rescuse environment come from?
[21:45] <elmo> and are any more available?
[21:49] <elmo> hmm *-modules-* udebs, butthey're not in Contents
[21:51] <infinity> elmo: They're in main/debian-installer/binary-*/Packages*, I assume.
[21:52] <elmo> infinity: sure, but not the individual files
[21:52] <infinity> Oh, no.
[21:52] <elmo> but a for loop and dpkg -c confirms ipmi isn't any of them
[21:52] <Daviey> elmo: http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/udeb.list ?
[21:52] <elmo> what would be the right package for a bug asking for new modules?  the kernel?
[21:52] <infinity> elmo: If it's kernel modules you're after, yeah.
[21:52] <elmo> infinity: cool, thanks
[21:53] <elmo> Daviey: ta also
[22:02] <bryceh> elmo, can you give me `lspci -vn | grep VGA` on the box you saw the compiz crash on a couple hours ago?  want to verify this is sandybridge specific
[22:04] <elmo> 00:02.0 0300: 8086:0126 (rev 09) (prog-if 00 [VGA controller])
[22:04] <elmo> bryceh: ^--
[22:04] <elmo> bryceh: deej (Canonical) also saw it, FWIW
[22:05] <bryceh> elmo, thanks.  snb-m-gt2+ in your case
[22:05] <bryceh> elmo, also was this with a dual head or external monitor set up by chance?
[22:06] <elmo> bryceh: nope, vanilla laptop display
[22:06] <bryceh> hmm!  interesting
[22:06] <bryceh> elmo, ok thanks.
[22:06] <elmo> bryceh: no prob
[22:15] <mahmoh> are armhf precise containers working? What I'm doing wrong?  If I enter the container it appears to work fine but I'm trying to execute commands externally to get info. from within - http://paste.ubuntu.com/861153/
[22:19] <stgraber> mahmoh: lxc-attach isn't supported by our kernel
[22:19] <stgraber> mahmoh: and lxc-execute is only for single application container, not for system containers
[22:20] <stgraber> mahmoh: in your case you'll want "lxc-console -n <container>" then login and run whatever you want
[22:20] <mahmoh> stgraber: ok, thank you for that info.; is there a plan to support -attach or no?
[22:21] <mahmoh> stgraber: and shouldn't it emit a message like, unsupported kernel feature?
[22:21] <stgraber> mahmoh: we're waiting on the patches to enter the upstream kernel, so that won't be there for 12.04 at least
[22:21] <mahmoh> Daniel's patches?
[22:22] <stgraber> mahmoh: hallyn is working on the new server guide which will mention what commands work and what don't and why, I agree lxc-attach could print something slightly more useful though :)
[22:22] <mahmoh> stgraber: :) thx again
[22:22] <stgraber> mahmoh: yeah, IIRC the pid_ns attach patch is a patch from Daniel and reworked by Eric Biederman
[22:24] <stgraber> mahmoh: http://git.kernel.org/?p=linux/kernel/git/ebiederm/linux-namespace-control-devel.git;a=summary
[22:24] <mahmoh> I saw that for Natty and just imagined it would have been in by now
[22:27] <mahmoh> stgraber: btw, thx for that blog post earlier this month ;)
[23:21] <elmo> bryceh: I have an up to date stacktrace in #942799 but the duplicate checker deleted all the data :)
[23:21] <elmo> bryceh: is there any easy way for me to re-submit the data?
[23:23] <seb128> elmo, tag the "master" bug "apport-request-retrace"
[23:23] <seb128> elmo, that will make the retracer attach the stacktrace of the next duplicate to the master rather than clean it
[23:23] <bryceh> seb128, that was already done
[23:23] <seb128> elmo, well tag the master and then resubmit
[23:23] <seb128> bryceh, and it didn't work?
[23:24] <bryceh> checking
[23:24] <bryceh> doesn't look like it
[23:24] <seb128> bryceh, elmo's bug was retraced before you tagged
[23:24] <seb128> elmo, can you resubmit it?
[23:24] <bryceh> ah
[23:25] <elmo> seb128: as in, just rerun apport and open a new bug?
[23:25] <seb128> elmo, yes
[23:25] <elmo> cool, will do
[23:26] <elmo> thanks
[23:26] <seb128> elmo, the master bug got tagged so next retrace will be attached rather than cleaned
[23:26] <seb128> elmo, thank you
[23:26] <bryceh> seb128, is this a changed behavior?  Seems like it used to do retracing on dupes too, but am I just remembering wrong?
[23:26] <seb128> bryceh, you are remembering wrong
[23:26] <seb128> bryceh, we can't make apport retracing public without checking for password etc
[23:27] <seb128> bryceh, so duplicates always got cleaned and set to public
[23:27] <elmo> damn, apport-bug's tab complete is hella slow
[23:28] <seb128> bryceh, it's not ideal but the alternative is to get somebody to manually review all the duplicates to mark them public if appropriate
[23:28] <seb128> which is often tedious and not that useful
[23:29] <elmo> should I retarget this at mesa?
[23:29] <elmo> it's trying to report it against unity
[23:29] <seb128> elmo, no
[23:29] <elmo> (sorry for all the dumb questions)
[23:29] <elmo> ok
[23:29] <seb128> elmo, worth case it doesn't dup it and you get a new stacktrace anyway :p
[23:30] <bryceh> actually targeting at mesa would be nice; it would collect a lot of the missing X files we're currently missing on this one
[23:31] <elmo> doh
[23:31] <elmo> bryceh: what files do you want?  I'll just add them by hand
[23:31] <seb128> bryceh, I don't think you can do that for segfaults
[23:31] <elmo> ah, I see in your reply to salgado
[23:31] <elmo> adding
[23:31] <seb128> bryceh, like you can change the component once you are on launchpad but that will not change the collecting job
[23:32] <seb128> bryceh, it always collects the infos for the package which did hit the segfault
[23:33] <bryceh> elmo, yep, thanks
[23:34] <bryceh> seb128, you keep making me sadder ;-)
[23:34] <seb128> bryceh, sorry :(
[23:34] <seb128> bryceh, good news is that apport is open source and the maintainer is responsive so we can get it improved ;-)
[23:35] <bryceh> seb128, well seems you're right about dupe crashes having their useful info excised, now that I look.  Probably I'm thinking of gpu lockup bugs where we collect register dumps (that won't ever have passwords or other such stuff.)
[23:36] <bryceh> seb128, that is cold comfort; from what you say most of these issues are policy not lack-of-fix
[23:36] <seb128> bryceh, well that's why we got that tag telling the retracer to get an updated stacktrace
[23:37] <seb128> that should cover most cases, like if you care about the bug it's likely because users still hit it
[23:37] <bryceh> seb128, but yes it's open source.  I've sent in a patch to fix one of our more annoying issues we see but am still waiting (for some months) on the branch to get picked up.
[23:38] <bryceh> seb128, yes, it's good to know about that tag.
[23:38] <seb128> bryceh, on apport?
[23:38] <bryceh> seb128, yeah
[23:38] <seb128> bryceh, https://code.launchpad.net/~bryce/apport/source_lookup/+merge/81172 ?
[23:38] <seb128> bryceh, pitti wrong a long reply, it seems blocked on you to write back ?
[23:39] <bryceh> seb128, no, I spoke to him in person about it at UDS
[23:39] <seb128> oh ok
[23:39] <bryceh> guess it can't hurt to add a comment though.
[23:40] <elmo> bryceh: added to 942966
[23:44] <bryceh> elmo,  thanks.  lp isn't displaying it, but will try again in a bit
[23:45] <elmo> bryceh: meh, publicized
[23:45] <seb128> bryceh, elmo: it's private until retracer picks it up
[23:45] <bryceh> bingo, there we go
[23:46] <bryceh> hoho, and a core dump!  lucky day
[23:46] <seb128> bryceh, get the coredump saved before the retracer gets there if you need it ;-)
[23:47] <elmo> I'd only just booted my machine, there can't possibly be anything interesting in that coredump
[23:47] <elmo> (that would require privacy I mean)
[23:56] <bryceh> seb128, trust me, I know
[23:57] <bryceh> elmo, I have it locally and will not be posting it anywhere.
[23:57] <bryceh> (and it will be deleted when I'm done with it)
[23:59] <seb128> bryceh, elmo: retracing done, it updated the master bug as wanted: https://launchpadlibrarian.net/94731013/Stacktrace.txt