[00:00] @pilot in === udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox [00:21] is there any about who would be willing to sponsor an upload? [00:25] balloons: cyphermox has just signed in as patch pilot :) [00:25] yo! [00:25] ahh.awesome [00:25] balloons: shoot :) [00:25] so I'm new to this, but I need something uploaded to precise-release so it can be reviewed [00:26] bzr branch lp:~nskaggs/checkbox/checkbox-app-testing-qt [00:26] kees, I see you're a MIR approver, could you take a look at bug 949575? [00:26] Launchpad bug 949575 in gtest (Ubuntu) "[MIR] gtest" [Undecided,New] https://launchpad.net/bugs/949575 [00:27] cyphermox: checkbox-app-testing is a new package; I've agreed to do the archive review [00:29] slangasek: ok [00:29] cnd: sure, done. someone else need to actually promote it, though. [00:30] kees, yeah [00:30] thanks for approving :) [00:31] cyphermox, let me know if you need anything else [00:31] balloons: I wish the extended description was longer, anything we can add now? :) [00:32] np :) [00:32] sure.. umm, what else would you like.. a bigger description of the package? [00:33] yeah, just more meat around it, it's not a big deal just would be nicer [00:33] balloons: also, debian/pycompat isn't required afaik, it can just be dropped [00:34] ok, I'll drop it and extend the descrip a bit [00:34] one sec [00:37] 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 === albrigha is now known as Guest67837 [00:39] cyphermox, pushed the changes [00:40] cool. I'll pull in a second, I'm running it through sbuild just now [00:40] thanks [00:48] balloons: thanks for the changes [00:53] cyphermox, np [00:56] balloons: slangasek: seems to me like much of the qt stuff should be in /usr/lib, not /usr/share [00:57] (at least) [00:58] 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] yeah, that's what bothers me, I have reviewed the last few checkbox uploads and didn't clue in :) [01:00] ahh.. so they are the same then? [01:00] i was going to say i did mod some stuff so it's possible I changed it [01:02] nah, it's the same [01:03] kk.. I would offer to leave it the same.. but your argument is sound :-) [01:06] 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] ok.. sounds fine [01:07] let's have at it [01:09] so basically I need to move qt stuff to /usr/lib [01:12] yeah, but that's going to break a few things [01:13] I'm looking through it now, some of it needs to stay in /usr/share [01:13] you'll want to at least adjust the default value of CHECKBOX_APP_TESTING_{SHARE,FRONTEND} [01:17] kk [01:25] balloons: I think I got it, shuffled files around a bit; hopefully it will solve this and still work :) [01:26] :-) the important part, yes :-) [01:35] the important part? [01:35] changes are actually pretty simple, I guess [01:36] ok.. do you have a patch or just want to descibre? [01:53] w 26 [01:53] bah [01:59] cyphermox, ? [01:59] balloons: ah, sorry [01:59] I'll have a patch soon, it mostly works [01:59] no worries :-) [02:00] kk.. just wondering what was up :-) [02:03] having an issue with dealing with upgrades, at least [02:04] 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] ahh.. I'll have to check it tonight unless he's around [02:06] I don't want to shorten slangasek's timeframe anymore than I have to :-) [02:11] balloons: lp:~mathieu-tl/checkbox/app-testing-move-to-usr-lib [02:11] I think it pretty much fixes everything [02:12] maybe just review the changes and if you think it's reasonable we'll upload that? [02:13] kirkland: Yes. opendkim. [02:14] kirkland: opendkim is a fork of dkim-milter done by the same author when he changed employers. dkim-milter is dead. [02:15] ok.. I'll merge and review now [02:24] 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] cyphermox, yes.. that's fine [02:24] they are the same :-) [02:24] ok [02:25] is it likely to ever be different? if not maybe it's not worth including [02:26] umm.. yea.. it depends on how checkbox-qt works out [02:27] ideally i wouldn't ship it [02:27] let's see how she runs [02:31] 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] ok, thanks [02:31] building.. building [02:33] ohhh [02:33] 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] yes.. I was going to ask [02:34] I just noticed them before asking you to take a look if they were needed or not [02:34] thanks [02:34] that's why upgrades of the package will fail until you reach a version of about 0.10 or so :) [02:35] lol [02:35] this is still new for me [02:35] so.. feel free to point out the obvious :-) [02:35] just make sure after that things still behave correctly, in case some changes are missing from the .ini file shipped [02:36] ok.. so explain the patches a bit more to me [02:37] if I kill the folder it will be as a new package [02:37] but i have to adjust my build too or it will fail right? [02:47] balloons: just empty the folder is fine. [02:48] 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] cyphermox, right.. but now the build is failing because it's looking for then [02:50] so I'm confused [02:51] balloons: then edit setup.py to avoid installing these files [02:51] rofl [02:51] another easy way could have been to make the initial version a 0.10.something [02:51] ahh.. i was looking in all the wrong places [04:27] Hm. I wonder how easy it is to exploit a root-permissioned libsane-using daemon. [05:01] You could probably do something interesting with a specially programmed USB device, I guess… [05:02] @pilot out === udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [05:08] Good morning [05:09] pitti: Aloha. [05:11] ScottK: thanks [05:13] morning pitti [05:29] 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] or alternatively close it manually after the freeze [05:37] jibel: FYI, filed bug 966845 for the last lucid-precise-universe upgrade failure [05:37] Launchpad bug 966845 in update-manager (Ubuntu Precise) "lucid->precise upgrade wants to remove ubuntu-desktop" [High,In progress] https://launchpad.net/bugs/966845 [05:42] 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] slangasek: nevermind, I'll close the bug manually [06:38] @pilot in === udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks [07:01] 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] didrocks: the latter usually [07:02] didrocks: there's plenty of stuff in unapproved which is for after beta-2 [07:02] ok, wasn't sure for main components though ;) [07:02] thanks pitti! [07:02] it's fine as a general fire&forget approach [07:03] didrocks: de rien, enjoy the flight :) [07:03] thanks ;) [07:06] good morning [07:07] hey dholbach ;) [07:07] hey didrocks [07:44] pitti, guten Morgen. thanks for reporting the failure. [07:45] jibel: TheMuso and I discussed it, should be fixed tomorrow [07:45] pitti, the error for lucid main is really weird. I'll have a look. [07:48] jibel: merci [08:51] 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] 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] dholbach: I rejected your auto-complete-el sync, since didrocks beat you to it. [09:08] cjwatson, ah ok :) === dholbach_ is now known as dholbach [09:15] 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] didrocks: done [09:16] pitti: thanks :) [09:20] (will they ever fix launchpad to let any dev do that?) [09:22] dholbach: still on sponsoring mood? I spent more than 2 hours here to build inkscape ;) [09:23] didrocks, really? it just took me a few minutes [09:23] 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] I'll stop now - sorry :) [09:23] dholbach: no no, I'm at the end of my shift [09:23] * dholbach hugs didrocks [09:23] dholbach: at least, confirming it looks good to me :) [09:23] * didrocks hugs dholbach [09:24] dholbach: I beat you at the syncing race! 1-1 I guess : p [09:24] haha [09:28] roaksoax: are you still intending to fix bug 840406? It's milestoned for beta-2 at the moment [09:28] Launchpad bug 840406 in powernap (Ubuntu Precise) "powerwaked crashed with ImportError in /usr/lib/python2.7/dist-packages/powerwake/monitors/ARPMonitor.py: No module named scapy.all" [High,Triaged] https://launchpad.net/bugs/840406 [09:30] 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] 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] rbasak: sounds like you've got a job that has "start on rabbitmq-server-running" and *that* is hanging. [09:32] 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] rbasak: check out http://upstart.ubuntu.com/cookbook/#establish-blocking-job [09:34] didrocks: will look at that now... [09:34] jodh: thanks, ping me once done, I'll sponsor them :) [09:34] hen* [09:34] then* [09:34] didrocks: thank you [09:34] 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 ubuntu1 becomes ubuntu1.1. But I thought to remember some variant making use of the release name. [09:40] smb: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging [09:41] cjwatson, Yeah, that was the one. Thanks. [09:41] linked to from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure [09:41] * smb bookmarks this time [09:50] 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] jodh: hum, I apt-get source upstart here [09:51] look at the changelog in 1.5-0ubuntu1 [09:51] and it's not here [09:51] didrocks: yes, the distro changelog is wrong - it doesn't reflect the bzr history. [09:52] jodh: well, the change in debian/conf/flush-early-job-log.conf is not in the distro either [09:52] so the change is not referenced, nor present in the current 1.5-0ubuntu1 in precise [09:53] didrocks: hmm, that's not supposed to happen :) [09:53] jodh: not sure how, but I checked twice ;) [09:53] jodh: not a biggie, you can add it to 1.5-0ubuntu2, just reference in debian/changelog from there [09:56] didrocks: thanks - and good catch! [09:57] jodh: just ping me once you've done the change :) [09:57] yw [10:04] 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] didrocks: I've re-pushed that branch now. [10:08] jodh: thanks! looking [10:09] rbasak: what state is that job in? Can you pb the job? [10:13] Can anybody tell me how do I apply this patch : http://git.gnome.org/browse/evolution-exchange/commit/?id=a78cf5169ed46f5d53412290dbb3fe862f201500 [10:13] jodh: http://paste.ubuntu.com/903663/ [10:15] rbasak: I think you'll find the pre-start is the problem - "initctl emit" is going to block until that completes. [10:16] patch always returns invalid patch format [10:16] rbasak: try putting the pre-start block into a shell script run with "/bin/sh -e" and see what happens. [10:16] 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] 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] Or is there any way to download the patch? [10:18] rbasak: the other possibility is that "initctl emit" is blocking because the 'start on' condition for that job isn't fully satisfied. [10:18] vibhavp: click 'patch' on that very page. [10:18] rbasak: again, try "sudo initctl emit net-device-up" (or filesystem) and see what happens [10:19] Daviey: Should that patch work? [10:19] vibhavp: No idea. [10:19] Seems that I will have to commit them manually :( [10:20] 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] 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] 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] 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] Emitting an event blocks until anything that starts on that event has completed. [10:28] That includes things that won't start until some other event has been emitted, due to 'and'. [10:29] There's 'initctl emit --no-wait', although I don't know whether that's appropriate here. [10:30] 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] 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] @pilot out === udevbot changed the topic of #ubuntu-devel to: Precise Beta 2 Freeze in Effect. Archive: pre-release freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/xmGdCW | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [10:32] rbasak/cjwatson: I'll make this point clearer in the Upstart Cookbook... [10:33] cjwatson, jodh: OK, my misunderstanding, thanks. I need to study the docs more. === wgrant_ is now known as wgrant [10:44] 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] 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] 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] rbasak: I'd look at your network config. [10:46] rbasak: did you check if running the pre-start blocked, in shell by hand? [10:46] jodh: the postinst isn't emitting the events - it's just calling "/bin/sh /usr/sbin/invoke-rc.d rabbitmq-server restart" [10:47] jodh: I've not messed with my network config. It's a fresh netinst. [10:48] Aha [10:49] rabbitmq-server isn't an upstart job, but /etc/init.d/rabbitmq-server calls "initctl emit rabbitmq-server-running" [10:49] Is this allowed? [10:49] Or should this be --nowait? [10:52] Remember that net-device-up is not a state. [10:52] It is an event. Once it has been emitted and completely processed at boot time, it goes away. [10:53] 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] Even with --no-wait, you're asking Upstart to keep track of an event that will never complete. [10:54] 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] Dependencies aren't a concept Upstart has. I recommend thinking only in terms of events. [10:54] The key thing to realise here is that net-device-up is not a state. [10:54] 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] 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] But from the next reboot, we want that. [10:55] No, it doesn't. You probably need to redesign. [10:55] This whole arrangement is prone to hangs. [10:55] 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] Some of them may be wrong, and some of them may know what they're doing! [10:56] But you're not talking about a job anyway, you're talking about an init script. [10:56] What are you trying to achieve by this rabbitmq-server-running event? [10:57] And why isn't rabbitmq-server a native Upstart job if you need to have things depend on it starting at boot? [10:57] cjwatson: check that something which depends on rabbit has a valid user, and if not, create one. Yes, it's a hack. [10:58] 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] Whoa [10:58] I can't see how you get from the premise to the conclusion there, given that d-i doesn't use Upstart [10:58] You're running rabbitmq in d-i? [10:58] rbasak: no. [10:59] This user creation: does it need to happen more than once per boot? Does it need to happen only once ever? [10:59] cjwatson: No, the issue is that running rabbit in d-i seemed to uncover many more issues within the rabbitmq package. [10:59] So, making the app that talks to rabbit, would traditionally have the logic in the app's postinst. [10:59] Well obviously you shouldn't start daemons during installation, but there's no need to solve that with arcane arrangements of events. [11:00] cjwatson: I get that.. but what do you suggest? === MacSlow is now known as MacSlow|lunch [11:00] I'm trying to understand your problem before making any concrete suggestions, hence my two questions above [11:00] cjwatson: Okay, it should be a once only action. [11:00] So it really has no place being in an upstart job. [11:01] But it's a once-only action that requires rabbitmq to be running? [11:01] 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] cjwatson: yep [11:01] Where is the code for this action? [11:01] one moment [11:01] I'm confused. [11:01] we know [11:02] I think I might actually understand it now! [11:02] infinity: I think I'm reasonably close to being able to make a non-broken recommendation [11:02] 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] infinity: because postgres for example, can runin d-i [11:02] They probably don't work during OS installation. [11:02] rabbit seems to not like that situation [11:03] how about fixing that ? [11:03] http://pb.daviey.com/rhGN/ [11:03] Does this relate to the outstanding rabbit bug that it uses su to start and creates a PAM session? [11:03] Daviey: That would be rather astonishing given that d-i tries extremely hard to suppress any daemon startup. [11:03] infinity: potentially.. one of those issues was resolved.. but there is still another su that didn't seem to have been addressed [11:04] Howeever, with that su removed in a testing environment, it still didn't unblock rabbitmq starting in d-i [11:04] cjwatson: Yep.. and hard to try astonishingly hard to circumvent that :/ [11:04] cjwatson: Yes.. ignoring policy.d. [11:05] I'm not going to pretend this is graceful handling. [11:06] Why does this need net-device-up [11:06] ? [11:06] I'm not sure why that was added.. [11:06] Cargo-culted from another job, I'd guess. [11:06] Ah, the actual daemon it's running needs to be network addressable [11:06] if it is somehow needed, it should probably be 'static-network-up' anyway [11:07] Daviey: Really? rabbitmqctl can't operate on, say, a UNIX socket? [11:07] net-device-up is prolly wrong then as that'll match 'lo' [11:07] infinity: no, you aren't looking at the job, are you? [11:08] jodh: Yeah, it would seem it needs IFACE handling [11:08] static-network-up bypassed that though [11:08] Daviey: I'm not? [11:08] Perhaps the simplest answer is that you should only emit rabbitmq-server-running during boot. [11:08] I smell a UDS session coming out of all this. [11:09] i.e. test RUNLEVEL [11:09] cjwatson: So if i apt-get install package.. the emit wouldn't happen.. i'd need to reboot? [11:10] txlongpoll's postinst could always do this rabbitmqctl thing if and only if rabbitmq is running. [11:10] 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] Daviey: The job doesn't make that particularly clear, so your previous comment was unhelpful. [11:11] 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] Or you could patch the daemon itself to attempt it at startup. [11:11] ++ [11:12] cjwatson: That sounds like a rabbithole.. It means priv drop logic would have to be added aswell, i imagine [11:12] To start as root. [11:12] Oh? The Upstart job you pointed to seems to start it as root already. [11:12] ^ [11:12] daemon starts, cannot authenticate, so creates a user, then authenticates.. feels more ugly [11:13] 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] Well, up to you, either works [11:13] micahg: around? [11:13] Daviey: shall I leave this with you, then? [11:14] rbasak: Unless you want it? :) [11:14] micahg: i have a fix prepared for vlc that i like get tested by you [11:14] rbasak: I need to put a peg on my noise if i'm going to touch this. [11:14] cjwatson: thanks. [11:15] Daviey: :) [11:15] Hmm.. If a job is conditional on two events, and the events happen at massively different times.. is this an issue? [11:16] ie, custom event AND a networking one? [11:16] No. [11:17] Once an event is emitted, it doesn't un-emit. [11:17] (It can re-emit, mind you) [11:17] Depends how massively different we're talking about, though. Boot vs. later package installation is not a good sign. [11:17] no, i mean.. is the blocking of an event's return an issue [11:18] Not normally for brief periods during boot. [11:18] ok, thanks [11:18] Unless you deadlock. [11:18] 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] Well yes, that seems viable in other situations.. thankfully i think a deadlock isn't possible in this crappy situation [11:18] 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] yeah, groovy! [11:20] infinity: If you want to work on rabbit using start-stop-daemon in place of su.. there is a lovely entry point. :) [11:20] rbasak: Perhaps with a semaphore (/var/lib/txlongpoll/user_created or such), so you don't retry every damned start. ;) [11:20] $ pastebinit /usr/sbin/rabbitmq-server [11:20] http://pb.daviey.com/fFSI/ [11:21] infinity: ^^ yes, a sbin script.. [11:21] Daviey: Love the ghetto input validation... [11:22] Your problem is not that shell is revolting. Your problem is that su has an appalling interface. [11:22] You wouldn't need that if you were using a more sensible tool. [11:22] cjwatson: yep.. not our code! [11:23] cjwatson: I started writing a start-stop-script drop in, but it started to become traumatic.. [11:23] It ought to mostly consist of deleting code. [11:23] it needs to accept start / stop init.d style.. but also arbitrary input aswell. [11:23] The whole thing is crappy. [11:23] Er you could just make the current script better without trying to add lots to it [11:24] So, basically, it needs to be a sysv init script. [11:24] infinity: right! [11:24] Turns out there are still lots of examples of sysv init scripts using start-stop-daemon in /etc/init.d ;) [11:24] which is why having what is near enough, but not compliant init script in sbin is awesome. [11:24] For now, anyway. [11:24] But then, it's also a sunny day. [11:25] infinity: that isn't the issue.. [11:25] I'm not actually sure what the issue is. [11:25] You just need to replace su with s-s-d and pass $@ wholesale. [11:25] start-stop-daemon --start --pidfile /dev/null --startas "/usr/lib/rabbitmq/bin/${SCRIPT}" --chuid rabbitmq -- "$@" [11:25] Or some such. [11:25] Like so. [11:25] And delete all the quoting nonsense. [11:26] cjwatson: right.. and $@ contains start, stop, or other things we don't know [11:26] Daviey: So? [11:26] so $something needs to be --$start to rperesent --start [11:26] How's that a problem? The script you gave us just passes all that stuff through. [11:26] Daviey: Passing $@ is exactly what it does now. [11:27] cjwatson: it's not conditional on matching for start/stop commands, to pass outside of $@ [11:27] Nor is the script you gave us. [11:27] elif [ `id -u` = `id -u rabbitmq` ] ; then [11:27] /usr/lib/rabbitmq/bin/${SCRIPT} "$@" [11:27] else [11:27] 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] All the script does is call rabbitmq $@ [11:27] I'm saying that this is unilaterally better and easily testable. [11:28] cjwatson: ${CMDLINE} is handled within the line... but it needs extracting to be part of start-stop-daemon --start, right [11:28] No [11:28] Daviey: No. [11:28] Daviey: --start isn't what you think it is. [11:28] CMDLINE is deviant garbage that should be discarded. [11:28] Daviey: It just means "run this command". [11:29] Hmm.. are you both sure? [11:29] Yes, quite sure. [11:29] Daviey: Very. [11:29] ok [11:29] CMDLINE is an abomination that messes around quoting "$@" in order to cope with the abysmal su interface. [11:29] The correct answer is to not use su, after which you don't need any of this stuff. [11:29] (--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] Right. [11:30] There are other ways; you could use a tiny perl wrapper, for instance. [11:30] But s-s-d does the job as long as it doesn't need to run within the installere. [11:30] *installer [11:30] but i'll potentially be calling rabbit with stop on the cmdline.. but --start in start-stop-daemon ? [11:30] That doesn't matter. [11:30] Daviey: Yes. [11:30] Daviey: --start means "run this". [11:30] ok [11:31] Daviey: And what you want it to run is "rabbitmq stop". [11:31] Which is all good. [11:31] ok, thanks [11:31] 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] Daviey: --stop doesn't run commands at all, it looks for pidfiles and kills with fire. [11:31] it's not as complex as i thought it was. [11:31] Daviey: And since rabbit has its own stopping, no need to ask s-s-d to do that. [11:31] 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] tumbleweed: time to do another u-d-t upload? === Guest86790 is now known as Zic === _salem is now known as salem_ [11:51] bdrung: seems like a good idea. I'll have a look through open bugs [12:08] tumbleweed: should we split bug #964731? [12:08] Launchpad bug 964731 in ubuntu-dev-tools (Ubuntu) "pull-debian-source wildcard support" [Medium,Triaged] https://launchpad.net/bugs/964731 [12:09] 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 === MacSlow|lunch is now known as MacSlow === bladernr_afk is now known as bladernr_ [12:44] Fetched 1003 MB in 6s (3684 kB/s) [12:44] Thats fast ... :) [12:45] I don't want to swear, really. [12:45] No one's forcing you to. [12:45] :) [12:46] Fetched 1003 MB in 6s (3684 kB/s). Got this when do-release-upgrade, file a bug on apt ? [12:47]