[00:00] <cyphermox> @pilot in
[00:21] <balloons> is there any about who would be willing to sponsor an upload?
[00:25] <RAOF> balloons: cyphermox has just signed in as patch pilot :)
[00:25] <cyphermox> yo!
[00:25] <balloons> ahh.awesome
[00:25] <cyphermox> balloons: shoot :)
[00:25] <balloons> so I'm new to this, but I need something uploaded to precise-release so it can be reviewed
[00:26] <balloons> bzr branch lp:~nskaggs/checkbox/checkbox-app-testing-qt
[00:26] <cnd> kees, I see you're a MIR approver, could you take a look at bug 949575?
[00:27] <slangasek> cyphermox: checkbox-app-testing is a new package; I've agreed to do the archive review
[00:29] <cyphermox> slangasek: ok
[00:29] <kees> cnd: sure, done. someone else need to actually promote it, though.
[00:30] <cnd> kees, yeah
[00:30] <cnd> thanks for approving :)
[00:31] <balloons> cyphermox, let me know if you need anything else
[00:31] <cyphermox> balloons: I wish the extended description was longer, anything we can add now? :)
[00:32] <kees> np :)
[00:32] <balloons> sure.. umm, what else would you like.. a bigger description of the package?
[00:33] <cyphermox> yeah, just more meat around it, it's not a big deal just would be nicer
[00:33] <cyphermox> balloons: also, debian/pycompat isn't required afaik, it can just be dropped
[00:34] <balloons> ok, I'll drop it and extend the descrip a bit
[00:34] <balloons> one sec
[00:37] <cyphermox> balloons: afaik it otherwise looks fine. since the package is probably not in debian you could also get away without the "ubuntuX" suffix for the version number, I think. not that it makes a real difference
[00:39] <balloons> cyphermox, pushed the changes
[00:40] <cyphermox> cool. I'll pull in a second, I'm running it through sbuild just now
[00:40] <balloons> thanks
[00:48] <cyphermox> balloons: thanks for the changes
[00:53] <balloons> cyphermox, np
[00:56] <cyphermox> balloons: slangasek: seems to me like much of the qt stuff should be in /usr/lib, not /usr/share
[00:57] <cyphermox> (at least)
[00:58] <balloons> cyphermox, I'm happy to make any changes needed :-) It's modeled after the checkbox package as an fyi.. so likely checkbox places them in the same location
[00:59] <cyphermox> yeah, that's what bothers me, I have reviewed the last few checkbox uploads and didn't clue in :)
[01:00] <balloons> ahh.. so they are the same then?
[01:00] <balloons> i was going to say i did mod some stuff so it's possible I changed it
[01:02] <cyphermox> nah, it's the same
[01:03] <balloons> kk.. I would offer to leave it the same.. but your argument is sound :-)
[01:06] <cyphermox> I think it needs to be fixed in both, it should be simple and pretty safe to change in checkbox-app-testing-qt now
[01:07] <balloons> ok.. sounds fine
[01:07] <balloons> let's have at it
[01:09] <balloons> so basically I need to move qt stuff to /usr/lib
[01:12] <cyphermox> yeah, but that's going to break a few things
[01:13] <cyphermox> I'm looking through it now, some of it needs to stay in /usr/share
[01:13] <cyphermox> you'll want to at least adjust the default value of CHECKBOX_APP_TESTING_{SHARE,FRONTEND}
[01:17] <balloons> kk
[01:25] <cyphermox> balloons: I think I got it, shuffled files around a bit; hopefully it will solve this and still work :)
[01:26] <balloons> :-) the important part, yes :-)
[01:35] <cyphermox> the important part?
[01:35] <cyphermox> changes are actually pretty simple, I guess
[01:36] <balloons> ok.. do you have a patch or just want to descibre?
[01:53] <mhall119> w 26
[01:53] <mhall119> bah
[01:59] <balloons> cyphermox, ?
[01:59] <cyphermox> balloons: ah, sorry
[01:59] <cyphermox> I'll have a patch soon, it mostly works
[01:59] <balloons> no worries :-)
[02:00] <balloons> kk.. just wondering what was up :-)
[02:03] <cyphermox> having an issue with dealing with upgrades, at least
[02:04] <cyphermox> I'm finishing up testing this then I think I'll leave it to you to figure out (or we should ask cr3 tomorrow or something)
[02:06] <balloons> ahh.. I'll have to check it tonight unless he's around
[02:06] <balloons> I don't want to shorten slangasek's timeframe anymore than I have to :-)
[02:11] <cyphermox> balloons: lp:~mathieu-tl/checkbox/app-testing-move-to-usr-lib
[02:11] <cyphermox> I think it pretty much fixes everything
[02:12] <cyphermox> maybe just review the changes and if you think it's reasonable we'll upload that?
[02:13] <ScottK> kirkland: Yes.  opendkim.
[02:14] <ScottK> kirkland: opendkim is a fork of dkim-milter done by the same author when he changed employers.  dkim-milter is dead.
[02:15] <balloons> ok.. I'll merge and review now
[02:24] <cyphermox> balloons: please test it too, make sure it behaves as you expect, the general UI look might have changed since now it would actually use the UI you ship instead of what comes from checkbox-qt
[02:24] <balloons> cyphermox, yes.. that's fine
[02:24] <balloons> they are the same :-)
[02:24] <cyphermox> ok
[02:25] <cyphermox> is it likely to ever be different? if not maybe it's not worth including
[02:26] <balloons> umm.. yea.. it depends on how checkbox-qt works out
[02:27] <balloons> ideally i wouldn't ship it
[02:27] <balloons> let's see how she runs
[02:31] <cyphermox> balloons: if you're looking for what to add to changelog for my changes, check the commit message. it's there but you'll want to adjust it for debian/changelog
[02:31] <balloons> ok, thanks
[02:31] <balloons> building.. building
[02:33] <cyphermox> ohhh
[02:33] <cyphermox> balloons: please drop the files in patches/, they clash with your package version and aren't needed since this is a new package.
[02:34] <balloons> yes.. I was going to ask
[02:34] <balloons> I just noticed them before asking you to take a look if they were needed or not
[02:34] <balloons> thanks
[02:34] <cyphermox> that's why upgrades of the package will fail until you reach a version of about 0.10 or so :)
[02:35] <balloons> lol
[02:35] <balloons> this is still new for me
[02:35] <balloons> so.. feel free to point out the obvious :-)
[02:35] <cyphermox> just make sure after that things still behave correctly, in case some changes are missing from the .ini file shipped
[02:36] <balloons> ok.. so explain the patches a bit more to me
[02:37] <balloons> if I kill the folder it will be as a new package
[02:37] <balloons> but i have to adjust my build too or it will fail right?
[02:47] <cyphermox> balloons: just empty the folder is fine.
[02:48] <cyphermox> IIRC that directory is supposed to contain "patches" or scripts that will act on the .ini files shipping by checkbox to change settings, for things like blacklists and such
[02:50] <balloons> cyphermox, right.. but now the build is failing because it's looking for then
[02:50] <balloons> so I'm confused
[02:51] <cyphermox> balloons: then edit setup.py to avoid installing these files
[02:51] <balloons> rofl
[02:51] <cyphermox> another easy way could have been to make the initial version a 0.10.something
[02:51] <balloons> ahh.. i was looking in all the wrong places
[04:27] <RAOF> Hm.  I wonder how easy it is to exploit a root-permissioned libsane-using daemon.
[05:01] <RAOF> You could probably do something interesting with a specially programmed USB device, I guess…
[05:02] <cyphermox> @pilot out
[05:08] <pitti> Good morning
[05:09] <RAOF> pitti: Aloha.
[05:11] <kirkland> ScottK: thanks
[05:13] <ajmitch> morning pitti
[05:29] <pitti> slangasek: I'll reject your language-selector upload and reupload with a couple of additional fixes, if that's alright with you? I want to add the LP# task to your conffile fix, too
[05:30] <pitti> or alternatively close it manually after the freeze
[05:37] <pitti> jibel: FYI, filed bug 966845 for the last lucid-precise-universe upgrade failure
[05:42] <pitti> jibel: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-main/lastFailedBuild/ARCH=i386,LTS=lts,PROFILE=main-all,label=upgrade-test/console crashes on a missind dir or file, could you please have a look?
[06:05] <pitti> slangasek: nevermind, I'll close the bug manually
[06:38] <didrocks> @pilot in
[07:01] <didrocks> pitti: do you think: should I sponsor in -proposed, don't do anything for packages in main until beta freeze is lifted? (or just upload in main and the release team won't approve it until the freeze is lifted)
[07:01] <pitti> didrocks: the latter usually
[07:02] <pitti> didrocks: there's plenty of stuff in unapproved which is for after beta-2
[07:02] <didrocks> ok, wasn't sure for main components though ;)
[07:02] <didrocks> thanks pitti!
[07:02] <pitti> it's fine as a general fire&forget approach
[07:03] <pitti> didrocks: de rien, enjoy the flight :)
[07:03] <didrocks> thanks ;)
[07:06] <dholbach> good morning
[07:07] <didrocks> hey dholbach ;)
[07:07] <dholbach> hey didrocks
[07:44] <jibel> pitti, guten Morgen. thanks for reporting the failure.
[07:45] <pitti> jibel: TheMuso and I discussed it, should be fixed tomorrow
[07:45] <jibel> pitti, the error for lucid main is really weird. I'll have a look.
[07:48] <pitti> jibel: merci
[08:51] <Mirv> does anyone happen to know a bug number (or even the component that should be fixed) for "terminal quickly shown on the screen when logging out or shutting down, before splash screen shows"?
[08:52] <Mirv> it's a small detail but quite visible, and at least I'm having it on all my 3 intel graphics laptops and radeon graphics desktop
[08:58] <cjwatson> dholbach: I rejected your auto-complete-el sync, since didrocks beat you to it.
[09:08] <dholbach_> cjwatson, ah ok :)
[09:15] <didrocks> anyone can reject this branch https://code.launchpad.net/~happyhouse19/ubuntu/oneiric/spyder/fix-for-890243/+merge/99579? (wrong target, sponsored the fix fixed to precise)
[09:15] <pitti> didrocks: done
[09:16] <didrocks> pitti: thanks :)
[09:20] <seb128> (will they ever fix launchpad to let any dev do that?)
[09:22] <didrocks> dholbach: still on sponsoring mood? I spent more than 2 hours here to build inkscape ;)
[09:23] <dholbach> didrocks, really? it just took me a few minutes
[09:23] <didrocks> dholbach: I hope you removed the bug # from debian/changelog? (they are just copy and paste and was already mergedpar ot the merge ;)
[09:23] <dholbach> I'll stop now - sorry :)
[09:23] <didrocks> dholbach: no no, I'm at the end of my shift
[09:23]  * dholbach hugs didrocks
[09:23] <didrocks> dholbach: at least, confirming it looks good to me :)
[09:23]  * didrocks hugs dholbach
[09:24] <didrocks> dholbach: I beat you at the syncing race! 1-1 I guess : p
[09:24] <dholbach> haha
[09:28] <cjwatson> roaksoax: are you still intending to fix bug 840406?  It's milestoned for beta-2 at the moment
[09:30] <rbasak> jodh: is there any reason why "initctl emit rabbitmq-server-running" would hang, or is this an upstart bug? I'm on arm.
[09:31] <didrocks> jodh: on https://code.launchpad.net/~jamesodhunt/ubuntu/precise/upstart/big-upstart-events-man-page-updates/+merge/99687, you still have debian/conf/flush-early-job-log.conf listed in an older changelog (1.5-0ubuntu1) which is not in 1.5-0ubuntu1 distro version
[09:31] <jodh> rbasak: sounds like you've got a job that has "start on rabbitmq-server-running" and *that* is hanging.
[09:32] <didrocks> jodh: so if you want to add it to 1.5-0ubuntu2 (which seems to be the case), can you list it at the right place?
[09:33] <jodh> rbasak: check out http://upstart.ubuntu.com/cookbook/#establish-blocking-job
[09:34] <jodh> didrocks: will look at that now...
[09:34] <didrocks> jodh: thanks, ping me once done, I'll sponsor them :)
[09:34] <didrocks> hen*
[09:34] <didrocks> then*
[09:34] <jodh> didrocks: thank you
[09:34] <didrocks> grrr ECANTTYPE
[09:39]  * smb would love to find again the documentation explaining the preferred version format for SRU packages. There seems to be cases where <ver>ubuntu1 becomes <ver>ubuntu1.1. But I thought to remember some variant making use of the release name.
[09:40] <cjwatson> smb: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[09:41] <smb> cjwatson, Yeah, that was the one. Thanks.
[09:41] <cjwatson> linked to from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[09:41]  * smb bookmarks this time
[09:50] <jodh> didrocks: that changelog entry does belong in 1.5-0ubuntu1 (I added it in revno 1382). It somehow got dropped when the branch was tagged and uploaded, so what's in the MP is actually correct.
[09:51] <didrocks> jodh: hum, I apt-get source upstart here
[09:51] <didrocks> look at the changelog in 1.5-0ubuntu1
[09:51] <didrocks> and it's not here
[09:51] <jodh> didrocks: yes, the distro changelog is wrong - it doesn't reflect the bzr history.
[09:52] <didrocks> jodh: well, the change in debian/conf/flush-early-job-log.conf is not in the distro either
[09:52] <didrocks> so the change is not referenced, nor present in the current 1.5-0ubuntu1 in precise
[09:53] <jodh> didrocks: hmm, that's not supposed to happen :)
[09:53] <didrocks> jodh: not sure how, but I checked twice ;)
[09:53] <didrocks> jodh: not a biggie, you can add it to 1.5-0ubuntu2, just reference in debian/changelog from there
[09:56] <jodh> didrocks: thanks - and good catch!
[09:57] <didrocks> jodh: just ping me once you've done the change :)
[09:57] <didrocks> yw
[10:04] <rbasak> jodh: there is a job that starts on rabbitmq-server-running, but find_blocked_job.sh does not report anything, and I don't see any child processes of "initctl emit rabbitmq-server-running"
[10:08] <jodh> didrocks: I've re-pushed that branch now.
[10:08] <didrocks> jodh: thanks! looking
[10:09] <jodh> rbasak: what state is that job in? Can you pb the job?
[10:13] <vibhavp> Can anybody tell me how do I apply this patch : http://git.gnome.org/browse/evolution-exchange/commit/?id=a78cf5169ed46f5d53412290dbb3fe862f201500
[10:13] <rbasak> jodh: http://paste.ubuntu.com/903663/
[10:15] <jodh> rbasak: I think you'll find the pre-start is the problem - "initctl emit" is going to block until that completes.
[10:16] <vibhavp> patch always returns invalid patch format
[10:16] <jodh> rbasak: try putting the pre-start block into a shell script run with "/bin/sh -e" and see what happens.
[10:16] <Daviey> jodh: I wonder if the pre-start is happening too quickly, directly as the event is emitted.. but before rabbit is /really/ ready?
[10:17] <rbasak> jodh: I'll do that, thanks. How does upstart run the jobs normally? Pipe them into a shell or something? SHouldn't I be seeing a shell process somewhere that is running the pre-start?
[10:18] <vibhavp> Or is there any way to download the patch?
[10:18] <jodh> rbasak: the other possibility is that "initctl emit" is blocking because the 'start on' condition for that job isn't fully satisfied.
[10:18] <Daviey> vibhavp: click 'patch' on that very page.
[10:18] <jodh> rbasak: again, try "sudo initctl emit net-device-up" (or filesystem) and see what happens
[10:19] <vibhavp> Daviey: Should that patch work?
[10:19] <Daviey> vibhavp: No idea.
[10:19] <vibhavp> Seems that I will have to commit them manually :(
[10:20] <jodh> rbasak: it uses a number of different techniques (3) to run jobs. If you're not seeing any shells though, it must be the 'start on' that's the problem.
[10:24] <rbasak> jodh, Daviey: looks like running both "sudo initctl emit net-device-up" and "sudo initctl emit filesystem" seems to fix it. I need both though. The order doesn't matter (I tried both orders concurrently on two different boards). But now the "emit filesystem" call is hung.
[10:25] <jodh> rbasak: that'll be because other jobs have 'start on's including filesystem. So it's looking like net-device-up is the issue.
[10:26]  * rbasak is definitely confused now
[10:27] <rbasak> maas-txlongpoll has "start on filesystem and net-device-up and rabbitmq-server-running". If net-device-up hasn't happened (it should have!), then why does "initctl emit rabbitmq-server-running" hang? Surely the job's start conditions haven't been met?
[10:28] <cjwatson> Emitting an event blocks until anything that starts on that event has completed.
[10:28] <cjwatson> That includes things that won't start until some other event has been emitted, due to 'and'.
[10:29] <cjwatson> There's 'initctl emit --no-wait', although I don't know whether that's appropriate here.
[10:30] <jodh> rbasak: from initctl(8): "For the emit command, finishing means that all of the jobs affected by the event are running (or have finished for tasks) or have been fully stopped."
[10:31] <cjwatson> In fact, I found that realising that emission blocked this way was the key to understanding Upstart's entire model, and especially the problems with mixing 'and' and 'or'.
[10:32] <didrocks> @pilot out
[10:32] <jodh> rbasak/cjwatson: I'll make this point clearer in the Upstart Cookbook...
[10:33] <rbasak> cjwatson, jodh: OK, my misunderstanding, thanks. I need to study the docs more.
[10:44] <jodh> rbasak: I've added a warning to the Cookbook with links to the appropriate sections here: http://upstart.ubuntu.com/cookbook/#initctl-emit
[10:44] <rbasak> So how should I debug this problem? I'm now lost again. The original issue was that "initctl emit rabbitmq-server-running" hangs. I know it's freed by "initctl emit filesystem" AND "initctl emit net-device-up", but the "initctl emit filesystem" then hangs. What does this mean and where should I look?
[10:45] <jodh> rbasak: the point is, you shouldn't need to emit these events yourself: 'filesystem' is emitted by mountall and net-device-up is emitted by either /etc/init/network-interface.conf or ifupdown all as documented in upstart-events(7).
[10:46] <jodh> rbasak: I'd look at your network config.
[10:46] <Daviey> rbasak: did you check if running the pre-start blocked, in shell by hand?
[10:46] <rbasak> jodh: the postinst isn't emitting the events - it's just calling "/bin/sh /usr/sbin/invoke-rc.d rabbitmq-server restart"
[10:47] <rbasak> jodh: I've not messed with my network config. It's a fresh netinst.
[10:48] <rbasak> Aha
[10:49] <rbasak> rabbitmq-server isn't an upstart job, but /etc/init.d/rabbitmq-server calls "initctl emit rabbitmq-server-running"
[10:49] <rbasak> Is this allowed?
[10:49] <rbasak> Or should this be --nowait?
[10:52] <cjwatson> Remember that net-device-up is not a state.
[10:52] <cjwatson> It is an event.  Once it has been emitted and completely processed at boot time, it goes away.
[10:53] <cjwatson> I would say that it is unwise to emit events at all at restart (i.e. other than at boot) that are likely to block on events that only arrive at boot time.
[10:53] <cjwatson> Even with --no-wait, you're asking Upstart to keep track of an event that will never complete.
[10:54] <Daviey> cjwatson: The issue is that one job is dependant on another job running.. I think we thought events was the way to do this?
[10:54] <cjwatson> Dependencies aren't a concept Upstart has.  I recommend thinking only in terms of events.
[10:54] <cjwatson> The key thing to realise here is that net-device-up is not a state.
[10:54] <Daviey> The old way i used to see was a crappy sleep loop that progressed to the job when it's requirement was satisfied.. that is really ugly.
[10:55] <rbasak> What about when we want to start a job from a postinst? In this case, waiting for net-device-up doesn't make sense.
[10:55] <rbasak> But from the next reboot, we want that.
[10:55] <cjwatson> No, it doesn't.  You probably need to redesign.
[10:55] <cjwatson> This whole arrangement is prone to hangs.
[10:55] <Daviey> cjwatson: Okay.. Other jobs do seem to emit events to use as dependencies.. not saying this is right... but how do we solve this issue?
[10:56] <cjwatson> Some of them may be wrong, and some of them may know what they're doing!
[10:56] <cjwatson> But you're not talking about a job anyway, you're talking about an init script.
[10:56] <cjwatson> What are you trying to achieve by this rabbitmq-server-running event?
[10:57] <cjwatson> And why isn't rabbitmq-server a native Upstart job if you need to have things depend on it starting at boot?
[10:57] <Daviey> cjwatson: check that something which depends on rabbit has a valid user, and if not, create one.  Yes, it's a hack.
[10:58] <Daviey> cjwatson: The issue is that running rabbitmq in d-i is harder.. which means that logic from postinst was moved to an upstart job.
[10:58] <rbasak> Whoa
[10:58] <cjwatson> I can't see how you get from the premise to the conclusion there, given that d-i doesn't use Upstart
[10:58] <rbasak> You're running rabbitmq in d-i?
[10:58] <Daviey> rbasak: no.
[10:59] <cjwatson> This user creation: does it need to happen more than once per boot?  Does it need to happen only once ever?
[10:59] <Daviey> cjwatson: No, the issue is that running rabbit in d-i seemed to uncover many more issues within the rabbitmq package.
[10:59] <Daviey> So, making the app that talks to rabbit, would traditionally have the logic in the app's postinst.
[10:59] <cjwatson> Well obviously you shouldn't start daemons during installation, but there's no need to solve that with arcane arrangements of events.
[11:00] <Daviey> cjwatson: I get that.. but what do you suggest?
[11:00] <cjwatson> I'm trying to understand your problem before making any concrete suggestions, hence my two questions above
[11:00] <Daviey> cjwatson: Okay, it should be a once only action.
[11:00] <Daviey> So it really has no place being in an upstart job.
[11:01] <cjwatson> But it's a once-only action that requires rabbitmq to be running?
[11:01] <Daviey> However, because doing that logic in d-i wasn't viable.. it was the best of two bad situations, that seemed to work.
[11:01] <Daviey> cjwatson: yep
[11:01] <cjwatson> Where is the code for this action?
[11:01] <Daviey> one moment
[11:01] <infinity> I'm confused.
[11:01] <ogra_> we know
[11:02] <rbasak> I think I might actually understand it now!
[11:02] <cjwatson> infinity: I think I'm reasonably close to being able to make a non-broken recommendation
[11:02] <infinity> There are lots of postinst actions that require daemons to be running (ie: anything that populates *sql databases).  How is this new ground?
[11:02] <Daviey> infinity: because postgres for example, can runin d-i
[11:02] <cjwatson> They probably don't work during OS installation.
[11:02] <Daviey> rabbit seems to not like that situation
[11:03] <ogra_> how about fixing that ?
[11:03] <Daviey> http://pb.daviey.com/rhGN/
[11:03] <infinity> Does this relate to the outstanding rabbit bug that it uses su to start and creates a PAM session?
[11:03] <cjwatson> Daviey: That would be rather astonishing given that d-i tries extremely hard to suppress any daemon startup.
[11:03] <Daviey> infinity: potentially.. one of those issues was resolved.. but there is still another su that didn't seem to have been addressed
[11:04] <Daviey> Howeever, with that su removed in a testing environment, it still didn't unblock rabbitmq starting in d-i
[11:04] <Daviey> cjwatson: Yep.. and hard to try astonishingly hard to circumvent that :/
[11:04] <Daviey> cjwatson: Yes.. ignoring policy.d.
[11:05] <Daviey> I'm not going to pretend this is graceful handling.
[11:06] <cjwatson> Why does this need net-device-up
[11:06] <cjwatson> ?
[11:06] <Daviey> I'm not sure why that was added..
[11:06] <infinity> Cargo-culted from another job, I'd guess.
[11:06] <Daviey> Ah, the actual daemon it's running needs to be network addressable
[11:06] <jodh> if it is somehow needed, it should probably be 'static-network-up' anyway
[11:07] <infinity> Daviey: Really?  rabbitmqctl can't operate on, say, a UNIX socket?
[11:07] <jodh> net-device-up is prolly wrong then as that'll match 'lo'
[11:07] <Daviey> infinity: no, you aren't looking at the job, are you?
[11:08] <Daviey> jodh: Yeah, it would seem it needs IFACE handling
[11:08] <jodh> static-network-up bypassed that though
[11:08] <infinity> Daviey: I'm not?
[11:08] <cjwatson> Perhaps the simplest answer is that you should only emit rabbitmq-server-running during boot.
[11:08] <jodh> I smell a UDS session coming out of all this.
[11:09] <cjwatson> i.e. test RUNLEVEL
[11:09] <Daviey> cjwatson: So if i apt-get install package.. the emit wouldn't happen.. i'd need to reboot?
[11:10] <cjwatson> txlongpoll's postinst could always do this rabbitmqctl thing if and only if rabbitmq is running.
[11:10] <Daviey> infinity: The daemon which is being discussed needs rabbit and also needs to be network addressable... External web browsers don't work well with unix sockets :)
[11:10] <infinity> Daviey: The job doesn't make that particularly clear, so your previous comment was unhelpful.
[11:11] <Daviey> cjwatson: Hmm, okay.. that makes sense.. Have the logic in postinst for the package install situation, and in upstart if it's d-i, so satisfied on first boot.
[11:11] <cjwatson> Or you could patch the daemon itself to attempt it at startup.
[11:11] <ogra_> ++
[11:12] <Daviey> cjwatson: That sounds like a rabbithole.. It means priv drop logic would have to be added aswell, i imagine
[11:12] <Daviey> To start as root.
[11:12] <cjwatson> Oh?  The Upstart job you pointed to seems to start it as root already.
[11:12] <infinity> ^
[11:12] <Daviey> daemon starts, cannot authenticate, so creates a user, then authenticates.. feels more ugly
[11:13] <Daviey> cjwatson: Yes it does at the moment.. but i'm sure by release it will have to be done by a system user.
[11:13] <cjwatson> Well, up to you, either works
[11:13] <bdrung> micahg: around?
[11:13] <rbasak> Daviey: shall I leave this with you, then?
[11:14] <Daviey> rbasak: Unless you want it? :)
[11:14] <bdrung> micahg: i have a fix prepared for vlc that i like get tested by you
[11:14] <Daviey> rbasak: I need to put a peg on my noise if i'm going to touch this.
[11:14] <Daviey> cjwatson: thanks.
[11:15] <rbasak> Daviey: :)
[11:15] <Daviey> Hmm.. If a job is conditional on two events, and the events happen at massively different times.. is this an issue?
[11:16] <Daviey> ie, custom event AND a networking one?
[11:16] <infinity> No.
[11:17] <infinity> Once an event is emitted, it doesn't un-emit.
[11:17] <infinity> (It can re-emit, mind you)
[11:17] <cjwatson> Depends how massively different we're talking about, though.  Boot vs. later package installation is not a good sign.
[11:17] <Daviey> no, i mean.. is the blocking of an event's return an issue
[11:18] <cjwatson> Not normally for brief periods during boot.
[11:18] <Daviey> ok, thanks
[11:18] <cjwatson> Unless you deadlock.
[11:18] <rbasak> Daviey: I'm not sure I understand upstart well enough yet. This is a complex issue. Happy to learn it but I may not get to a good solution quickly.
[11:18] <Daviey> Well yes, that seems viable in other situations.. thankfully i think a deadlock isn't possible in this crappy situation
[11:18] <rbasak> Daviey: I'd start by having a separate script that does the setup. Then it's just a question of where that script gets called from.
[11:19] <Daviey> yeah, groovy!
[11:20] <Daviey> infinity: If you want to work on rabbit using start-stop-daemon in place of su.. there is a lovely entry point. :)
[11:20] <infinity> rbasak: Perhaps with a semaphore (/var/lib/txlongpoll/user_created or such), so you don't retry every damned start. ;)
[11:20] <Daviey> $ pastebinit /usr/sbin/rabbitmq-server
[11:20] <Daviey> http://pb.daviey.com/fFSI/
[11:21] <Daviey> infinity: ^^ yes, a sbin script..
[11:21] <infinity> Daviey: Love the ghetto input validation...
[11:22] <cjwatson> Your problem is not that shell is revolting.  Your problem is that su has an appalling interface.
[11:22] <cjwatson> You wouldn't need that if you were using a more sensible tool.
[11:22] <Daviey> cjwatson: yep.. not our code!
[11:23] <Daviey> cjwatson: I started writing a start-stop-script drop in, but it started to become traumatic..
[11:23] <cjwatson> It ought to mostly consist of deleting code.
[11:23] <Daviey> it needs to accept start / stop init.d style.. but also arbitrary input aswell.
[11:23] <Daviey> The whole thing is crappy.
[11:23] <cjwatson> Er you could just make the current script better without trying to add lots to it
[11:24] <infinity> So, basically, it needs to be a sysv init script.
[11:24] <Daviey> infinity: right!
[11:24] <infinity> Turns out there are still lots of examples of sysv init scripts using start-stop-daemon in /etc/init.d ;)
[11:24] <Daviey> which is why having what is near enough, but not compliant init script in sbin is awesome.
[11:24] <infinity> For now, anyway.
[11:24] <Daviey> But then, it's also a sunny day.
[11:25] <Daviey> infinity: that isn't the issue..
[11:25] <infinity> I'm not actually sure what the issue is.
[11:25] <infinity> You just need to replace su with s-s-d and pass $@ wholesale.
[11:25] <cjwatson> start-stop-daemon --start --pidfile /dev/null --startas "/usr/lib/rabbitmq/bin/${SCRIPT}" --chuid rabbitmq -- "$@"
[11:25] <cjwatson> Or some such.
[11:25] <infinity> Like so.
[11:25] <cjwatson> And delete all the quoting nonsense.
[11:26] <Daviey> cjwatson: right.. and $@ contains start, stop, or other things we don't know
[11:26] <infinity> Daviey: So?
[11:26] <Daviey> so $something needs to be --$start to rperesent --start
[11:26] <cjwatson> How's that a problem?  The script you gave us just passes all that stuff through.
[11:26] <infinity> Daviey: Passing $@ is exactly what it does now.
[11:27] <Daviey> cjwatson: it's not conditional on matching for start/stop commands, to pass outside of $@
[11:27] <cjwatson> Nor is the script you gave us.
[11:27] <infinity> elif [ `id -u` = `id -u rabbitmq` ] ; then
[11:27] <infinity>     /usr/lib/rabbitmq/bin/${SCRIPT} "$@"
[11:27] <infinity> else
[11:27] <Daviey> I'm not saying it's a big deal, i'm sayin that i'm reluctant to change it at this stage in the cycle.
[11:27] <infinity> All the script does is call rabbitmq $@
[11:27] <cjwatson> I'm saying that this is unilaterally better and easily testable.
[11:28] <Daviey> cjwatson: ${CMDLINE} is handled within the line... but it needs extracting to be part of start-stop-daemon --start, right
[11:28] <cjwatson> No
[11:28] <infinity> Daviey: No.
[11:28] <infinity> Daviey: --start isn't what you think it is.
[11:28] <cjwatson> CMDLINE is deviant garbage that should be discarded.
[11:28] <infinity> Daviey: It just means "run this command".
[11:29] <Daviey> Hmm.. are you both sure?
[11:29] <cjwatson> Yes, quite sure.
[11:29] <infinity> Daviey: Very.
[11:29] <Daviey> ok
[11:29] <cjwatson> CMDLINE is an abomination that messes around quoting "$@" in order to cope with the abysmal su interface.
[11:29] <cjwatson> The correct answer is to not use su, after which you don't need any of this stuff.
[11:29] <infinity> (--start means special things when combined with, say --make-pidfile, but since rabbit handles its own start/stop, you're only using s-s-d as a better su)
[11:29] <cjwatson> Right.
[11:30] <cjwatson> There are other ways; you could use a tiny perl wrapper, for instance.
[11:30] <cjwatson> But s-s-d does the job as long as it doesn't need to run within the installere.
[11:30] <cjwatson> *installer
[11:30] <Daviey> but i'll potentially be calling rabbit with stop on the cmdline..  but --start in start-stop-daemon ?
[11:30] <cjwatson> That doesn't matter.
[11:30] <infinity> Daviey: Yes.
[11:30] <infinity> Daviey: --start means "run this".
[11:30] <Daviey> ok
[11:31] <infinity> Daviey: And what you want it to run is "rabbitmq stop".
[11:31] <infinity> Which is all good.
[11:31] <Daviey> ok, thanks
[11:31] <cjwatson> This is in some sense abusing start-stop-daemon to do something that isn't starting or stopping a daemon.  But it works.
[11:31] <infinity> Daviey: --stop doesn't run commands at all, it looks for pidfiles and kills with fire.
[11:31] <Daviey> it's not as complex as i thought it was.
[11:31] <infinity> Daviey: And since rabbit has its own stopping, no need to ask s-s-d to do that.
[11:31] <bdrung> micahg: i don't need your help. i reconstructed your setup and tested the fix here. i am going to upload 2.0.1-3 to debian
[11:37] <bdrung> tumbleweed: time to do another u-d-t upload?
[11:51] <tumbleweed> bdrung: seems like a good idea. I'll have a look through open bugs
[12:08] <bdrung> tumbleweed: should we split bug #964731?
[12:09] <tumbleweed> bdrung: just looking at it now. It casuses DDE to throw an exception, returning invalid json. I'm about to commit something returning a saner error message
[12:44] <dupondje> Fetched 1003 MB in 6s (3684 kB/s)
[12:44] <dupondje> Thats fast ... :)
[12:45] <jokerdino> I don't want to swear, really.
[12:45] <highvoltage> No one's forcing you to.
[12:45] <jokerdino> :)
[12:46] <dupondje> Fetched 1003 MB in 6s (3684 kB/s). Got this when do-release-upgrade, file a bug on apt ?
[12:47] <vibhavp> 1GB in 6 seconds!?
[12:47] <dupondje> its wrong indeed :)
[12:47] <vibhavp> Then you should file a bug
[12:47] <dupondje> guess it takes the download time from the last file download
[12:49] <vibhavp> must be
[13:18] <roaksoax> cjwatson i did a new upload couple days ago that was waiting for approval
[13:22] <cjwatson> roaksoax: Oh, so you did.  That's on the server images and AFAICR nobody flagged it as needing a respin - can we push that bug to final?
[13:35] <astraljava> cjwatson: Sorry to bug you on this small detail, but we're a little stumped on the matter. The issue concerns branding of Studio, and can be seen in this screenshot: http://astraljava.kapsi.fi/us_precise_dash-and-xubuntu-logo.png
[13:36] <astraljava> There's a dash between the words, and we'd like to get rid of it. But I can't find it as a string in any obvious package sources.
[13:36] <cjwatson> could you file a bug about it for me?
[13:37] <astraljava> cjwatson: Sure, I can. Thanks!
[13:37] <cjwatson> it comes from cdimage, I need to consider the consequences of changing it
[13:37] <astraljava> cjwatson: Alright, no problem. If it can be done, great, if not, not a big deal.
[13:37] <astraljava> cjwatson: What should I file it on?
[13:38] <cjwatson> astraljava: the ubuntu-cdimage project
[13:39] <astraljava> cjwatson: Excellent. Thanks so much! And really, if it proves to be difficult, don't worry about it. I didn't know it's got such direct consequences.
[13:40] <roaksoax> cjwatson sure!
[13:56] <astraljava> cjwatson: I filed bug 967140, but I'd like to stress it's not _that_ big a deal, if it proves to be difficult.
[14:28] <slangasek> pitti: oh, didn't realize there was a bug opened for the language-selector conffile issue, sorry
[14:30] <pitti> slangasek: no problem, I just closed it manually
[14:41] <Riddell> ev: presumably ubiquity isn't expected to work at 640x480 resolution?
[14:43] <stgraber> Riddell: correct, IIRC the minimal resolution is 1024x600, might work on 800x600 (I think VMWare uses that)
[14:43] <stgraber> well, it should "work", just won't fit on the screen
[14:43] <Riddell> there was a fix recently for 800x600 in gtk frontend
[14:44] <Riddell> I have a bug in arm which means I get 640x480 so kubuntu works fine but ubuntu desktop doesn't, but I'll not report another bug
[14:44] <Riddell> or as you say works but won't show on screen
[15:13] <micahg> bdrung: re vlc> great, thanks
[15:13] <micahg> /back
[15:21] <bdrung> micahg: you're welcome. you're ls output helped to understand the issue
[15:24] <bdmurray> pitti: there is an issue with apport and kerneloops bug reports not getting the sourcepackage hook for linux run at all
[15:34] <pitti> bdmurray: hm, any details about this?
[15:34] <pitti> an apport linux bug seems to work fine here
[15:34] <bdmurray> pitti: kerneloops ones
[15:34] <bdmurray> bug 963142 is an example
[15:38] <bdmurray> it seems that add_hooks_info isn't geting run and I looked around but didn't see why
[15:48] <Sweetshark> tumbleweed: I heard in a recent #ubuntu-meeting you want more reviewers for libreoffice packaging. Heres your chance to get started: find the libreoffice-3.5.1-1ubuntu2 upload on chinstrap.
[15:48] <Sweetshark> tumbleweed: pitti sure will help you out.
[15:48] <tumbleweed> Sweetshark: what's chinstrap, and also I'm not a core-dev
[15:50] <Sweetshark> tumbleweed: oh, I can post on people.canonical.com if you prefer.
[15:52] <bdrung> tumbleweed: you don't have to be core-dev to review a package ;)
[15:53] <tumbleweed> of course not, but it might be wasted time
[15:55] <tumbleweed> Sweetshark: sure, you wanted more review, if nobody else is going to do it, I'm happy to look at it, as long as I don't kill myself in the process :P
[15:55] <tumbleweed> so yes, stick it somewhere I can see it
[15:55] <Sweetshark> http://people.canonical.com/~bjoern/libreoffice_3.5.1-1ubuntu2/
[15:56] <tumbleweed> I'll be home in an hour or two and have a look...
[15:56] <micahg> Sweetshark: FYI, apparently, ubuntu-desktop and kubuntu-desktop can upload as well FWIW
[15:56] <Riddell> micahg: pardon?
[15:57] <micahg> Riddell: for libreoffice :)
[15:57] <Riddell> oh you mean kubuntu-dev I think
[15:57] <micahg> yes, kubuntu-dev
[16:08] <Sweetshark> micahg, tumbleweed: well, please coordinate with pitti, who is quite eager to get this is in for bug 916291.
[16:09] <micahg> Sweetshark: I don't have time to look at it ATM, was just referring you to other people who might be able to help
[19:14] <hallyn> so, when i do 'pull-lp-source lxc natty-proposed' (where lxc does not exist in natty-proposed), i end up with a crash report and apport popup.
[19:16] <ahasenack> is there a way to conditionally build-depends on a package depending on the ubuntu release it is being built on?
[19:17] <ahasenack> for example, python-fixtures is not available in lucid, but it is in precise
[19:23] <slangasek> ahasenack: by maintaining VCS branches for the different releases
[19:23] <slangasek> otherwise no
[19:23] <slangasek> well, to be fair, you could also do something like this
[19:24] <micahg> ahasenack: there's a way to do it in packaging, but it needs to be generated before the upload happens (not automatic) with a control.in and a rule to regenerate, openjdk works like this
[19:24] <slangasek> Build-Depends: python-dev, python-dev (<< 2.7) | python-fixtures
[19:25] <slangasek> supposing that python-fixtures is new and only relevant for python 2.7 or so
[19:25] <ahasenack> slangasek: yeah, I thought about a dummy |
[19:25] <ahasenack> slangasek: but I think the ppa builders don't honor |
[19:25] <micahg> ahasenack: they do as long as it's not a versioned dependency
[19:25] <slangasek> they "honor" them, but the semantics are somewhat opaque
[19:26] <slangasek> actually, I think python-fixtures | python-dev (<< 2.7) is the better way around
[19:26] <slangasek> because if the first alternative is unavailable, LP will try the next one
[19:26] <micahg> bug 594916
[19:26] <slangasek> (and find it already satisfied)
[19:26] <ahasenack> when I tried it downloaded more than it should
[19:26] <ahasenack> I had this once:
[19:26] <ahasenack> python-dev (>= 2.6.6-3~) | python-central | python-support
[19:27] <ahasenack> it downloaded natty/main python-dev all 2.7.1-0ubuntu5
[19:27] <ahasenack> and then  python-central all 0.6.15ubuntu5
[19:27] <ahasenack> so that falls into that bug? Let me check
[19:28] <ahasenack> my case looks diferent, the first package was found and downloaded
[19:28] <ahasenack> but it continued and downloaded the second one
[19:30] <ahasenack> slangasek: I will try your idea, thanks
[20:22] <slangasek> chrisccoulson: hi, have you gotten other reports of bug #967469?  I haven't heard anyone making noise about it, so I'm wondering if it's just me
[20:23] <chrisccoulson> slangasek, bug 801699
[20:24] <marsfligth> Why don't offer the choice to use Unity/Gnome 3 or a full futured desktop environment that respect the usage, behavior, system requirements, stability, debugged and fully compatible desktop environment in use since 20 years? Why impose only the new one that in more its totally different than previoous?
[20:24] <slangasek> chrisccoulson: does that really explain it entirely, though?  Note that I'm not trying to *interact* with any menus here, so shouldn't it eventually settle down?
[20:25] <chrisccoulson> slangasek, yeah, it's the same issue. hud-service mines the menus in firefox, which causes high CPU usage
[20:25] <seb128> slangasek, does it do it all the time? do you have lot of bookmarks or nested ones?
[20:25] <seb128> chrisccoulson, the description seems not similar though, it suggests it happens sometimes, not always there
[20:26] <seb128> we got bugs like bug #965493
[20:26] <slangasek> seb128: how many is "a lot"?  I count 15 bookmarks with one submenu, not counting ones that were autocreated for me by one generation of ff or another
[20:26] <seb128> chrisccoulson, ^ I think it's not the bug you listed
[20:26] <slangasek> chrisccoulson: ok, so, shouldn't hud-service mine firefox /less/?
[20:26] <chrisccoulson> slangasek, can you get a backtrace then?
[20:27] <seb128> slangasek, can you try pinging desrt on #gnome-desktop to see if he wants to help you debugging it?
[20:27] <slangasek> I mean, what's causing it to poll it *constantly*?
[20:27] <seb128> ups
[20:27] <seb128> #ubuntu-desktop
[20:27] <slangasek> chrisccoulson: of FF?  I imagine I could
[20:27] <chrisccoulson> slangasek, it doesn't it polls when the window comes in to focus, which is triggering a lot of CPU for some people
[20:27] <seb128> chrisccoulson, slangasek: please move on #ubuntu-desktop
[20:28] <seb128> desrt is maintaining hud-service and could be useful to include in that discussion
[21:21] <YokoZar> Can I ask why p11-kit is in universe when gnutls26 seems to depend on it?
[21:21] <YokoZar> and by "depend" I mean "throw warnings every time it's used when it's missing"
[21:25] <slangasek> YokoZar: it shouldn't depend on it at all. What warning are you getting?
[21:48] <YokoZar> slangasek: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/957931
[21:49] <YokoZar> on further testing installing p11-kit doesn't actually fix this...but the warnings appear to be spurious and are generated whether or not p11-kit is installed
[21:50] <slangasek> YokoZar: they're not spurious; /etc/pkcs11/modules/gnome-keyring-module exists and refers to gnome-keyring-pkcs11.so, but this is a multiarch install on amd64 and the i386 version of the module is not installed
[21:50] <slangasek> the p11-kit message refers to *lib*p11-kit
[21:51] <YokoZar> slangasek: I have that installed too (for both arches)
[21:51] <slangasek> you definitely do not have gnome-keyring-pkcs11.so installed for both arches
[21:53] <YokoZar> slangasek: ahh it's in the gnome-keyring package
[21:53] <slangasek> yep
[21:54] <YokoZar> ...which isn't a multiarch package
[21:55] <YokoZar> So there doesn't seem to be any solution here
[21:56] <slangasek> nothing that should be done this cycle, no
[21:56] <YokoZar> i'll retarget it to gnome-keyring and tag multiarch
[21:57] <slangasek> already done
[21:57] <YokoZar> hah, thanks
[21:58] <YokoZar> man wine really is the major test case for all things multiarch