=== jjohansen is now known as jj-afk [01:45] anyone know how to get emacs to find the right source file when using gdb? it doesn't seem to have the right search path for the file names gdb is emitting and the info page is useless. [02:02] The Maverick Me Menu currently enforces one character tweets. Because 140 is way too many ;) [02:08] That's where it was bound to end up eventually anyway. [03:00] cjwatson, was it you that I talked with several months back about dropping the Ubuntu deviations to parted and dmraid that strip the 'p' character separating the base device from the partition number for dmraid devices? [04:53] hi, i have a package who's postinst is failing [04:54] is there some way i can lie to my system and say that it's configured ok, so that it doesn't fail every time i run apt? [04:54] you can be evil & edit the postinst in /var/lib/dpkg/info/package.postinst, just start it off with an exit [04:55] this won't stick around when you upgrade it, but will get you past the failing postinst [04:55] in the land of kernel bugs, evil is king [04:55] or something [04:55] thanks anyway :) [05:03] what sort of kernel bug? :) [05:04] slangasek: one that causes partitions from the sd card to be mounted read only on beagle boards [05:05] ah, fun [05:05] which specifically makes update-initramfs' postinst not happy [05:05] * slangasek nods [06:02] are there any mirrors of ports.ubuntu.com ? [06:20] featurefreeze?? why!? [06:26] oracle: because. https://wiki.ubuntu.com/MaverickReleaseSchedule [06:30] my battery was lasting a great deal shorter on fedora 11 than this ubuntu 10, did someone improve something? [06:32] Good morning [06:46] SpamapS: I just added you to the WI tracker team, so you can commit directly [06:54] pitti: thanks! :) Any way you can have the errors cc'd to the team mailing list? [06:54] pitti: btw, I don't do Tae Kwon Do, I do Kenpo Karate.. but they're very similar. :) [06:55] SpamapS: oh, right, I should set up a ML for that team [07:05] SpamapS: ML created, I need to wait for a few minutes until it works === almaisan-away is now known as al-maisan [07:16] pitti: how long have you been training in TKD? [07:17] SpamapS: since about 2001 [07:17] SpamapS: with about 1.5 years of break in between [07:18] SpamapS: but I'm not that much of a fighter :) we don't do a lot of sparring [07:18] pitti: I've been doing Kenpo for 3 years now. Great fun. [07:18] SpamapS: we should exchange experiences over a beer in Orlando! [07:18] pitti: yes for sure. :) [07:20] I can add some aikido yoshinkan in there [07:20] (more talk -> longer discussion -> moah beer) [07:21] lifeless: sounds like a good plan [07:21] pitti: hey how are the retracers [07:21] SpamapS: you should see it now on https://edge.launchpad.net/people/+me/+editemails [07:21] lifeless: haven't checked again yet [07:21] * pitti restarts them [07:21] pitti: please do? [07:22] thanks [07:22] SpamapS: cronjob updated to mail the ML [07:23] beer + martial arts + code == the beginnings of an awesome game engine? ;) [07:23] pitti: sweeeet [07:24] lifeless: seems the amd64 one is quite happy, it's been running since about midnight [07:24] lifeless: I'd like to echo the sentiments of whoever said "launchpad seems faster today" .. I feel a bit more productive in bug management in general lately. :) [07:24] ok great [07:24] SpamapS: thanks! [07:24] SpamapS: (you could send it to the list, I'm sure the other devs would love to hear that) [07:27] lifeless: will do :) [07:55] argh, could LP please stop importing bug comments from 3 years old closed bugs which nobody ever looks at any more.. [07:55] or at least, stop telling about them [07:56] pitti: does LP import bug comments from other trackers? really? [07:57] apparently so === tm_ is now known as tm [08:45] SpamapS, pitti, [08:45] how is the tracker today === jj-afk is now known as jjohansen [08:53] tkamppeter: is there a bug about smbd not waiting for cups? === diwic is now known as diwic_afk [09:03] SpamapS, just did a local run of the generators and its not regenerating the older svgs [09:04] apw: you might need to run with -a for that [09:04] I think it's not regenerating older milestone charts by default [09:04] (to save cycles) [09:04] pitti, would the installed version also be -a or not -a [09:04] not -a by default [09:04] as i think we need an expensive run to fix the older graphs [09:04] due to the per-user charts, it currently takes aaages [09:04] yes, we can run it once with -a for taht [09:05] i'll run it now to confirm they are fixed [09:05] cheers [09:34] pitti, yeah that fixed the broken lines for me (-a) [09:34] pitti, do we do one -a per day still ? [09:41] what is the better place to put gconf based customizations (let's say I want to build a custom ubuntu variant) so that they are kept over updates? is /usr/share/gconf/defaults dir meant for this kind of job? [09:45] apw: http://bazaar.launchpad.net/~work-items-tracker-hackers/launchpad-work-items-tracker/trunk/revision/225 [09:46] pitti, looks good [09:50] tkamppeter: I committed upstartification into cups trunk, if you want to test === apachelogger_ is now known as apachelogger === amitk is now known as amitk-afk [09:55] pitti, great. will try. [09:56] tkamppeter: it still causes smbd to hang if I stop/start it manually (will discuss with Keybuk), but on a normal boot, both are running [10:01] pitti, some questions: [10:02] pitti, is the "author" field really for the upstream author of the program to be started? Or is it for the author of the upstart script? [10:03] tkamppeter: not sure; gdm uses the upstream one, smbd has slangasek [10:03] pitti, the "pre-start script" (I assume that this is a shell (sh) script) has [10:03] [ -x /usr/sbin/cupsd ] [10:03] tkamppeter: right, it's a sh -e script [10:03] for preparing the environment, see man 5 init [10:04] as first line. does this really make sense? Should it not be something like [10:04] tkamppeter: that'll fail the job if cupsd doesn't exist [10:04] tkamppeter: since the script is set -e [10:04] [ -x /usr/sbin/cupsd ] || exit 1 [10:05] That’s just redundant [10:05] OTOH, it documents itself better. [10:05] OTOH, anyone editing the code should be familiar with the semantics of sh and set -e anyway. :-P [10:06] OK. === diwic_afk is now known as diwic [10:16] pitti, I have looked into the upstart script now and it looks much simpler than an init script. Looks like upstart takes a lot of repeated stuff away from the developer or admin. [10:18] right, I could drop all the pidfile and status handling === doko_ is now known as doko [10:35] pitti, in the init script there are code sections "Get the timezone set" and "restart xprint". They are not in the upstart script. Are they obsolete? [10:35] tkamppeter: I tested logs and jobs, and they have teh correct timezone without setting $TZ [10:36] tkamppeter: I dropped xprint because handling it there would also require upstartification of xprint, and we don't really support xprint in Ubuntu anyway [10:37] pitti, the init script also contains [10:37] chown root:lpadmin /usr/share/ppd/custom 2>/dev/null || true [10:37] chmod 3775 /usr/share/ppd/custom 2>/dev/null || true [10:37] Is this not needed any more? [10:37] that should go into the postinst; no need to do it on every start [10:39] tkamppeter: (it's in bzr now) [10:42] pitti, the debian/changelog has a small bug: The first item of my changes should start with debian/patches/default-ripcache-size-auto.dpatch. We had the patch before, we do not "Add" it. [10:43] tkamppeter: ah, thanks; fixed [10:44] tkamppeter: I merged the two maverick changelogs, since these aren't appropriate for a Debian upload === diwic is now known as diwic_lunch [10:55] pitti, upstartification of CUPS seems to work well for me. There is even a backward compatibility interface, to comply with the LSB (very important for LSB-based driver packages). [10:56] right [10:57] tkamppeter: I added some preinst code to clean up the old init script; you shouldn't have any /etc/rc*/*cups* any more, and /etc/init.d/cups should be a symlink === Kmos_ is now known as Kmos === ivoks-afk is now known as ivoks [11:14] pitti, clean-up works. Only thing to be done is now to coordinate with Keybuk so that the smbd script does not hang on manual operation. [11:14] right, I'm waiting for him === smb is now known as smb-afk [11:22] diwic_lunch, do you need help to push new fluidsynth release to git? [11:23] pitti, are my Jockey patches OK? [11:23] still no time to look at them, sorry === diwic_lunch is now known as diwic [11:24] quadrispro, hi there! [11:24] quadrispro, if you want to do something, be my guest :-) [11:25] diwic, well, you'll see my changes soon [11:26] quadrispro, should we try to get the LADSPA stuff up and working again? If so, you should pull changeset 360-363 [11:27] quadrispro, so you're a DD now? Congratulations! [11:27] lucidfox, yep, get my new status on May, thanks! :) [11:27] May? o_O [11:27] diwic, well, having a look [11:28] and only just changed fluidsynth? [11:29] lucidfox, no, did a lot of stuff :) [11:33] mvo: could you have a look at bug 637517? [11:33] Launchpad bug 637517 in OEM Priority Project "oem-config-remove-gtk crashed with AttributeError in _run_transaction()" [High,Confirmed] https://launchpad.net/bugs/637517 === ivoks is now known as ivoks-afk [11:37] diwic, I've switched the packaging to the 3.0 (quilt) format, so remember to run quilt pop -a after git-build'ing the package [11:39] hello archive admins, can you please sync https://bugs.launchpad.net/bugs/636822 as users like this package to be in sync with upstream as possible and personally I would like to see updated networks support in maverick [11:39] Launchpad bug 636822 in mobile-broadband-provider-info (Ubuntu) "Please sync mobile-broadband-provider-info 20100910-1 (main) from Debian unstable (main)." [Wishlist,New] [11:42] quadrispro, okay [11:43] quadrispro, thanks for your contribution :-) [11:43] cjwatson: I might sync f-spot manually in lieu of an immediate fix to that bug, if that's OK? Or would you rather use it as a test case? [11:44] diwic, we should move talking about fluidsynth in #debian-multimedia chan (on OFTC) [11:47] Laney: I have another test case, though was sort of hoping to build up pressure on that bug ;-) [11:47] cjwatson: final freeze is building up pressure on me ;) [11:47] coolbhavi: I've been doing sync runs daily; there's no need to ask [11:47] coolbhavi: get a sponsor to ack it and it will be done [11:48] cjwatson, okay! [12:06] cjwatson: sure, will do === hunger_ is now known as hunger|work [12:17] cjwatson, my proposed fix would work. all we need is for Mike Gemünde to legally change his name to an ascii-only one, then the problem goes away. [12:18] cjwatson, when one boots the maverick beta image, let the burning man be, and then chose try ubuntu from the subsequent menu, the machine seems to hang for several minuts (about 3 on an atom) and apparently there is a large lzma running then, is this expected? === amitk-afk is now known as amitk [12:19] apw: I don't know really [12:19] apw: the initrd is lzma-compressed for space reasons [12:19] do you mean that early? [12:19] i mean that early and for that long yeah [12:19] not really much I can do [12:19] i have the try/install dialog for several minutes there [12:20] seems to be new behaviour is all [12:20] it's been lzma-ed for a while [12:20] get a faster CPU :) [12:20] ogra, you can talk! [12:20] use ARM ! [12:20] if an atom is struggling i don't see an arm finding it easy [12:20] I'm not going to have time to look into it, I'm afraid; if you do and find something untoward, I'd be happy to look at fixing it [12:21] apw, you havent used omap4 yet :) [12:21] but I have my hands full with EFI [12:21] ogra, noone has :) [12:21] cjwatson, fair enough, will see if i can determine what its doing it do and whether it is necessary === al-maisan is now known as almaisan-away === smb-afk is now known as smb === ivoks-afk is now known as ivoks [13:58] pitti, ping. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/634102 is ready for sru review. I don't think i've left anything un-done. could you, or someone on the sru review team, please review ? [13:58] Launchpad bug 634102 in cloud-init (Ubuntu Lucid) "t1.micro EC2 instances hang on reboot" [High,Triaged] === almaisan-away is now known as al-maisan [14:02] hello [14:03] does anyone speak english? [14:03] kristian014: that would be the default language [14:03] i need somebody to translate for me [14:03] isn't this a polish chat? [14:03] it isn't a polish channel [14:04] ooohh ok [14:04] sorry [14:04] so does anyone speak polish??? lol [14:05] try #ubuntu-pl [14:05] ok [14:05] thanks [14:16] cjwatson, ev: hi, how is ubiquity installing translations? [14:16] does it use aptdaemon? [14:16] seb128: langpacks? [14:17] yes [14:17] ev: bug #630924 [14:17] Launchpad bug 630924 in Ubuntu Translations "Language packs are not downloaded during installation" [Critical,Triaged] https://launchpad.net/bugs/630924 [14:17] indeed, it's on my list [14:17] I'm wondering if you need a change similar to bug #612825 [14:17] Launchpad bug 612825 in language-selector (Ubuntu Maverick) "can't install new languages (nothing happen)" [High,Fix released] https://launchpad.net/bugs/612825 [14:18] ev: ie http://bazaar.launchpad.net/~ubuntu-core-dev/language-selector/ubuntu/revision/380 [14:18] dpm, ^ [14:19] ah, thanks seb128, ev [14:20] ev: well I just wanted to point the language-selector change in case that was useful [14:20] hello smoser; I'll do an SRU round at some point this week, yes [14:20] seb128: no, it doesn't use aptdaemon. It uses python-apt with Dir set to /target. [14:20] ev: ok, ignore me then ;-) [14:20] heh [14:20] thanks for the pointer though [14:20] pitti, thanks. === cking is now known as cking-afk [14:22] bad seb128 uploaded b0rken nautilus :P [14:22] sebner, how broken? [14:23] seb128: pretty, https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/637704 [14:23] sebner, it works for me at least [14:23] Launchpad bug 637704 in nautilus (Ubuntu) "nautilus not starting" [Undecided,Confirmed] [14:23] sebner, wfm [14:23] :\ [14:24] we didn't get any complain on #ubuntu-desktop or other bugs [14:24] seb128: well, at least 5 people seem affected [14:24] 8 even [14:25] I guess one of those 8 people need to debug the issue [14:26] seb128: /me offers himself if you provide guidance [14:26] sorry but ENOCLUE about that [14:26] seems a libunique issue [14:27] meh [14:27] did you restart your session since the upgrade?* [14:27] or nautilus? [14:28] seb128: let me check === mathiaz_ is now known as mathiaz [14:29] seb128: wuhhh, the magic of open source strikes again :D [14:30] cjwatson, doko: How can I find out whether a particular package has an archive override? (fonttools and fonttools-eexecop are the two packages I'm interested in) [14:30] sebner, works after restart? [14:30] seb128: yep, sorry for the noice [14:30] *noise [14:31] pedro_, ^ [14:31] cool! [14:31] can't nautilus arrange to bring that service up? [14:31] thanks for the info sebner [14:32] Laney, it will be a non issue for upgrade from lucid [14:32] Laney, the port to gapplication was only during the unstable cycle and reverted [14:32] oh ok [14:33] Laney: :) [14:39] hi i want to try develop a application that lets you uncharge and recharge the battery/ specify min. battery level on which to start charging. [14:40] change show a road for development i dont now where i must start [14:43] summury how can i control charing on ubuntu [14:43] ? [14:48] how can i control charging on ubuntu ? [14:57] mpt: all packages have overrides [14:57] mpt: you can look at what the overrides say by looking in the /ubuntu/indices/ directory on mirrors [14:58] talat: the upower daemon (talk to it via dbus) tracks the charge level of the laptop battery, and also from devices [14:58] talat: you can connect to it with the libupower-glib library, or via dbus directly, and listen to charge change signals [14:58] talat: check "upower --monitor-detail" whether it knows about your's === dendrobates is now known as dendro-afk [14:59] cjwatson, excellent, found just what I wanted, thanks. Now where do I report a bug that an override is incorrect? On the package itself, or somewhere else? [15:00] mpt: doesn't matter exactly where (on the package itself is as good as any), but the important thing is to subscribe ubuntu-archive to the bug [15:00] ok, thanks [15:02] pitti, upower give me some information. But how can disable charing ? [15:02] you can't [15:02] talat: assuming that you mean "charging" [15:02] that's done by the hardware [15:02] well, and BIOS, I assume [15:03] there might be some machine specific tricks how to control it, but if there are, they aren't supported or known to me [15:03] some hardware will have a hotkey to do it, but when it does, generally the BIOS is responsible and only sends a notification to the OS that it did it === cking-afk is now known as cking === dendro-afk is now known as dendrobates [15:06] superm1, pitti very interseting i dont think why i cant control my charger status. I guess electronical reponse. [15:07] cjwatson: got a moment to talk about grub2, dmraid, and the ubuntu specirfic patches to remove the 'p' character from the names to separate the partition number from the base name? [15:12] psusi: so, mostly I was just trying to avoid changing things, having only been reminded of this last week [15:13] seems a bit late for a transition [15:13] psusi: if you think it's actively important for some reason, we can do it, but I do know dmraid seems to be rather undertested just now [15:13] figuring out what's wrong with grub2 on dmraid is on my to-do, since I've had a number of reports of problems and I suspect some of them are upstream [15:13] cjwatson: I started looking at it again because ther was a post on the forums about grub failing to install now on dmraid.. so I started testing it last night, figuring it was because of the p... that grub-probe was getting confused by the device name when trying to identify the underlying device and partition number without the p [15:14] so I dropped the patch to dmraid, and modified a patch to parted that had the same effect, and got the p showing up in the device name again, and the install worked up until it tried to install grub, where grub-probe still fails === ivoks is now known as ivoks-afk [15:15] right, I can't offer specific advice there although I will be able to fix it once I have a chance to sit down and reproduce it ... [15:15] the purpose of grub-probe is what exactly? to map the kernel device you are trying to install on to a bios disk, partition, abstraction module, and fs? [15:15] roughly yes [15:16] also determines whether the boot loader will be able to read a particular file [15:16] and how can it possibly do that with dmraid? ;) [15:16] other than just assuming a dmraid device is hd0? [15:16] grub has a certain amount of raid support [15:16] which can be extended to dmraid [15:16] but in any case it can probably just pick a disk and read off it [15:17] well that's the thing... with dmraid you DON'T use a raid abstraction module, since the bios takes care of it [15:17] well then, there should be little problem [15:17] it just needs to know that at the right time, that's all [15:18] yea, so I think grub-probe needs to notice it's a dmraid device, split the partition number off, and assume the base device is hd0... I think... hrm... [15:18] I don't expect that there's a particular boot-time problem - it'll just be a matter of tedious OS device manipulation [15:19] this is stuff I've done before [15:19] in fact I *did* get it working at one point [15:19] it has obviously bitrotted a bit [15:19] yea, it worked in lucid [15:20] but if you look at e.g. util/deviceiter.c you'll see a good deal of dmraid-specific code, written by me [15:20] it just needs to be debugged back into a working state, that's all [15:20] ahh [15:20] * psusi reads on [15:20] so did you just have it assume a dmraid device is hd0 or did you come up with some magic to figure it out? [15:21] forget about hd0 [15:21] the drive ordering doesn't particularly matter these days anyway [15:21] it just sticks any dmraid arrays on the end of the enumeration [15:21] the mbr needs a bios disk number to read in the core doesn't it? [15:21] nope [15:21] how does it manage that? [15:22] in the Unix-land utilities, we need a drive number in order to have a consistent bidirectional mapping, and otherwise it's irrelevant nowadays [15:22] at boot-time, two things === ivoks-afk is now known as ivoks [15:23] firstly, the core image is normally embedded right after the MBR, on the same disk, so it can just use %dl which the BIOS gives it [15:23] secondly, the core image finds everything else using UUIDs [15:23] (actually, if /boot is on the same disk as the core image, that's optimised away, and we just store the partition number) [15:23] theoretically the bios is supposed to pass the mbr the bios disk number it was loaded from in the CL register, but I learned from working on the ReactOS boot loader that not all bioses do, which is why dos etc always hard code it to 80 in the mbr [15:24] what usually happens is that the disk you boot from magically becomes 0x80 for that boot [15:24] apw: add --all-milestones to generate the old milestones [15:24] was it dl? hrm... thought it was cl... either way [15:24] but grub's mbr does have some sanity checks for things going wrong [15:24] it's dld [15:24] dl [15:24] anyway, none of that is dmraid-specific [15:25] yea, that's the other industry standard kludge... since does hard codes 80, the bios just makes whichever disk you boot from 80 ;) [15:25] we set dl to 0x80 if it looks wrong, and otherwise use what we're given [15:25] if it has the top bit set, it's generally right [15:25] what's the process for requesting a binary only pocket change for a package? libgl1-mesa-dri-experimental (which contains nouveau dri) is completely unsupported by upstream and is in main currently [15:25] I see... [15:26] Sarvatt: file bug, subscribe ubuntu-archive, we'll figure it out from there and ask you for more if need be [15:26] thanks! [15:27] there was a patch on grub-devel recently for some dmraid issue, I think, which I haven't reviewed yet [15:27] that's another oddity I've noticed... grub sets the device by name in the cfg, then uses the search command to search by uuid... seems redundant doesn't it? === joshua__ is now known as Jsvcycling1 [15:28] but that's neither here nor there... I'll go read code [15:28] ohh, but you think it is too late then to drop the 'p' removal for mav? [15:29] the 'set root' + search --fs-uuid is really just insurance [15:29] yes, it's redundant, it's a just-in-case kind of thing. occasionally it helps and it doesn't hurt [15:29] dropping 'p'> I'd say only if it's needed to fix installation [15:30] if it's needed, fine, we can do it [15:30] heh, actually I ran into a situation where it does hurt... if you have multiple devices with the same uuid... like if you have an lvm snapshot ;) [15:30] otherwise, sorry for forgetting it until now; I had incorrectly been thinking that it was bound up with lvm2, and it wasn't until I went to update lvm2 that I remembered that was wrong [15:30] psusi: what I mean is that the 'set root' doesn't hurt [15:30] LVM snapshots should be explicitly avoided in maverick [15:31] if you can demonstrate this not happening correctly, it is a bug [15:31] speaking of lvm2... when I installed it on the daily livecd last night, I got a bunch of errors... it seemed to be a result of it pulling in watershed and/or trying to rebuild the initrd [15:31] but GRUB's LVM code definitely tries to avoid snapshots [15:31] installing things that update the initramfs on the live CD is generally tricky [15:32] I thought the trigger noticed it was on livecd and just bailed out [15:32] FWIW, in general, anything that tries to use (hd0) or (hd0,1) type addressing at boot time in GRUB these days, without having a UUID search as well, is deprecated [15:32] it's still supported because there'll be user configuration using it [15:33] and it's easier to type at rescue mode or whatever [15:33] but long-term it isn't reliable and can't really be made reliable [15:34] there's somebody who sits spamming grub2 bugs on LP about how GRUB doesn't match BIOS drive ordering, missing the point that (a) there's no way for it to do so and (b) if it matters then it's a bug [15:34] heh [15:34] (yes, there's EDD. it's supported on a subset of hardware, and the contortions required to get at it from userspace and do anything useful with it are moderately hideous) [15:36] yea, reminds me of floppy detection... technically the drives were supposed to respond to a detect command to find out their size and capacity... but nobody bothered implementing that part of the spec, which is why you had to go into the bios and tell it what kind you plugged in... and the os has to get that from the bios and trust it... leading to idiots complaining that Ubuntu shows them a... [15:36] ...floppy when they don't have one... [15:37] who then complain when told to stop telling their bios they have one === jono is now known as jono-phone [16:11] Keybuk: hello, how are you? [16:11] Keybuk: I have a question about cups upstartification; do you have a minute for that? [16:11] for you, I have ten [16:13] and I do apologise, my brain has a lot of "new upstart" in it, so I might have to think how the current version behaves [16:20] pitti: FWIW, I understood that the chmod/chown in the cups init script was because admins might drop local files in this directory (ignoring the FHS); but maybe this was just wishful thinking on my part :) [16:23] Keybuk: I created an upstart script and added the necessary transition bits (http://bazaar.launchpad.net/~pitti/cups/debian-trunk/revision/893); starting/stopping cups works, and booting works as well (both smbd and cups are running) [16:24] Keybuk: but if I "stop cups; stop smbd", and "start smbd", (or even manually start cups), the start smbd keeps hanging forever, and "status smbd" says "smbd stop/starting" [16:24] Keybuk: do you have a hint how I can debug that? [16:26] right [16:26] you'd need to restart dbus too [16:26] and restart the filesystem ;-) [16:27] I don't understand [16:28] so smbd blocks on what exactly? [16:28] status cups says "started" [16:28] so smbd could just go? [16:28] ok [16:28] let me work it through with you [16:28] so you've just run stop cups; stop smbd [16:28] and everything looks fine [16:28] now you run [16:28] # start smbd [16:28] upstart will begin starting that job [16:28] the first thing it emits is the "starting smbd" event [16:28] and it will _WAIT_ for that event to complet [16:28] -- [16:29] so upstart looks for jobs with "on starting smbd", in this case cups [16:29] cups isn't running (you stopped it), so cups will take the event [16:29] but cups needs (you used "and") started dbus and filesystem too [16:29] so cups isn't ready to start yet [16:29] but because cups is holding the event, smbd isn't ready to start yet either [16:30] it's a great example of bug #447654 [16:30] Launchpad bug 447654 in upstart "init: using 'and' operators can cause hangs" [High,Triaged] https://launchpad.net/bugs/447654 [16:31] Keybuk: hm, but that even happens if I start cups before [16:31] sure [16:31] let's work that one [16:31] -- [16:31] back at stop cups; stop smbd and everything is ok [16:32] now you start cups, and cups *finishes starting* [16:32] once again, it's in a reset state (the start on bit has been cleared) [16:32] so start smbd, will cause "starting smbd", which will get picked up by the cups job for the next time it's started [16:32] right, we are at [16:32] $ status cups; status smbd [16:32] so it's still blocked [16:32] cups start/running, process 1751 [16:32] smbd stop/starting [16:32] here [16:32] right [16:32] # initctl emit started dbus [16:32] # initctl emit filesystem [16:32] err [16:32] sorry [16:32] # initctl emit stopped udevtrigger [16:32] not filesystem [16:33] not sure why I had filesystem in my brain here [16:33] ah, because it literally is "start cups when smbd starts", not really "cups needs to be started in order for smbd to start" [16:33] yes [16:33] basically [16:33] what you've said there is [16:34] argh, meeting now, back in 20 mins or so (sorry) [16:34] "if smbd starts, wait for dbus and udevtrigger, then start cups" [16:34] (and let smbd start) [16:34] that can also work in the other order [16:34] "after dbus and udevtrigger, when smbd starts, start cups then let smbd start" [16:34] the problem is that once cups has started, it forgets that dbus and udevtrigger have been [16:35] so if you ever "stop cups" you'll have to restart all those other things [16:36] Keybuk, is there no possibility for "make sure that the cupsd is running when smbd is started"? [16:37] not currently, Upstart doesn't work that way [16:37] in fact, if anything, it's designed to stop you doing that [16:37] because "what if the user doesn't *want* cups running?" [16:37] and "what if the user has disabled the init script?" [16:37] and "what if the init script is still there, but the package is uninstalled?" [16:37] etc. [16:37] this all became much easier for me to think about when I realised that upstart start* and stop* events are events which are emitted at certain times and which block until all the jobs hung off them have reached their desired state [16:38] rather than some kind of different abstraction [16:38] well, that's all they are :p [16:38] it was a bit like the epiphany where I realised that Verilog (a VHDL) was NOT NOT NOT procedural despite looking like it was [16:38] few people realise that's how Upstart works [16:38]