[02:22] <hyperair> hmm, how do i manually report a bug from a .crash file?
[02:22] <hyperair> i tried running ubuntu-bug on it, but after i checked the checkbox saying send error report and clicked "leave closed", it just put a .upload file in the same directory and didn't do anything.
[02:38] <kirkland> distro-info --devel is failing, and breaking my build scripts
[02:38] <kirkland> ubuntu-distro-info: Distribution data outdated.
[02:38] <kirkland> Please check for an update for distro-info-data.
[02:38] <kirkland> no update available
[02:39] <StevenK> kirkland: It's because there is no devel release currently
[02:39] <StevenK> raring is frozen and marked as such in LP
[02:40] <ScottK> bdrung: ^^^
[02:42] <kirkland> StevenK: understood, but usually we've opened the "s" archive by now
[02:42] <kirkland> StevenK: right?
[02:42] <kirkland> "sexy"?
[02:42] <ScottK> kirkland: No, not until after release, although usually we do know the name ...
[02:43] <StevenK> Right, not until after.
[02:46] <kirkland> ScottK: okay -- and sabdfl hasn't yet given us our sprawling soliloquy settling such specification?
[02:46] <ScottK> Nope.
[02:46] <ScottK> New record.
[02:46] <kirkland> (that took way to long to even write)
[02:46] <kirkland> (and that was only 5 s-words)
[02:47] <kirkland> "I'll take S Words for $200, Alex"
[03:28] <hyperair> xnox: ping. https://code.launchpad.net/~xnox/usb-creator/udisks2 <-- is this complete?
[03:52] <pitti> Good morning
[03:54] <unixpro1970> hi pitti
[06:16] <dholbach> good morning
[08:10] <xnox> hyperair: nope. seg faults python interpreter at tear down.
[08:11] <xnox> kirkland: No Name Yet =)
[08:17] <hyperair> xnox: damn. :(
[08:18] <xnox> someone might open up with "No Name Yet" =)))) quite a reference
[09:03] <seb128> ev, hey
[09:03] <ev> hi
[09:03] <seb128> ev, https://errors.ubuntu.com/problem/4e7901e5fabda4c7b5f81a3999b7d9d3afc92591
[09:04] <seb128> ev, do you know why it managed to take a compiz version for that issue?
[09:04] <seb128> ev, one report has "1:0.9.9~daily13.03.29-0ubuntu1" as version, which is compiz and not unity
[09:04] <seb128> ev, which makes the issue be red on the bugslist since that version is newer than the unity upload that has the fix
[09:05] <seb128> ev, https://errors.ubuntu.com/oops/e3d6ec94-aa94-11e2-9ec1-2c768aafd08c is the instance
[09:05] <seb128> ev, unity is a bit of a special case, because it's compiz which hits the segfault but we use the apport hook to redirect to the right component
[09:06] <seb128> ev, I'm just surprised e.u.c regrouped issues from difference sources packages (which is leading to the version issue)
[09:06]  * ev digs
[09:15] <ev> seb128: looking at source_compiz.py, we only switch over to unity as the binary package in the report if the user selects "yes" in the dialog that asks them if it's a bug in unity
[09:17] <seb128> ev, hum, no, in case of segfaults we return in the first if case
[09:17] <seb128>     if "Stacktrace" in report:
[09:17] <seb128> ...
[09:17] <seb128>                     report.add_package_info(apport.packaging.get_file_package(words))
[09:17] <seb128>                     return
[09:17] <seb128> ev, so we don't ask the question in case of segfaults
[09:17] <ev> ah right
[09:18] <seb128> ev, but even if that was buggy, is that normal that identical bugs on different sources are "merged" together?
[09:18] <seb128> ev, that create the issue with the versions
[09:19] <seb128> wouldn't it be better to have 2 separate bugs in the tracker, one for the compiz source and one for the unity one?
[09:19] <ev> seb128: the problems are keyed based on the crash signature or duplicate signature, the package doesn't come into play
[09:20] <seb128> ev, hum, I see
[09:21] <seb128> ev, could we have the table of versions be a combo source/version in that case?
[09:21] <seb128> ev, or do you have an idea on how to avoid having that bug flagged as regression when it's not?
[09:22] <ev> seb128: yeah, this is definitely worth fixing. I don't mean to suggest that we're operating perfectly in this case.
[09:22] <ev> creating a bug for this now
[09:22] <seb128> ev, thanks
[09:26] <ev> seb128: https://bugs.launchpad.net/daisy/+bug/1172635
[09:26] <seb128> ev, thanks, subscribed
[09:28] <ev> seb128: cool, thanks. And feel free to grab me at the sprint if you want to talk through that one some more, or have anything else you'd like to see changed
[09:29] <ev> seb128: it'd be great if you could spare some time that week so I can understand what your high priority items are
[09:29] <seb128> ev, sure, will do, thanks!
[09:30] <seb128> ev, for that bug, your suggestion of (package, binary package version) makes sense to me
[09:30] <ev> awesome
[09:41] <Laney> oh noes, it's "pull-lp-source is broken" day
[09:42]  * tumbleweed loves those days
[09:42] <tumbleweed> esp when we can't fix them
[09:44] <Laney> tumbleweed: can't we fall back to stable?
[09:47] <tumbleweed> Laney: you can specify a release...
[09:47] <Laney> sure
[09:48] <Laney> rather not have to though - and stable is what you would have got before?
[09:48] <tumbleweed> no, devel is the default
[09:48] <Laney> yes, but there is no devel now
[09:48] <tumbleweed> it doesn't know that there is no devel
[09:48] <Laney> old devel → current stable
[09:48] <tumbleweed> it just knows that it doesn't know
[09:48] <Laney> it knows the info is outdated
[10:11] <xnox> Laney: to be honest s-series is registered so one should be able to use that.
[10:11] <Laney> Now it would be two SRUs though
[10:12] <Laney> Maybe earlier it could have been updated with placeholder data
[10:12] <xnox> so one should fall back to future maybe and if nothing is published fall back to stable.
[10:13] <Laney> I don't think you could pull from S-series currently :-)
[10:16] <Laney> so yeah, even if the data was correct now it would try that probably fail?
[10:18] <cjwatson> Nothing published in it, indeed
[10:43] <Nafallo> cjwatson: so... ubuntu-support-status still shows 18m support. that's not intentional, right? (I think you're the right guy for this question, repoint if not)
[10:44] <stgraber> Nafallo: gah, no, looks like we forgot to fix LP to set Supported: 9m for >=raring
[10:45] <Nafallo> stgraber: the change is needed in servers, not in the package at least? :-)
[10:45] <stgraber> Nafallo: my understanding is that LP needs to be updated to set the field the next time it re-generates the indexes
[10:46] <Nafallo> okidoki :-)
[10:46] <stgraber> the problem is that the series as already been marked as released, so I guess it's too late for raring
[10:46] <Laney> But they're not going to be regenerated for raring now?
[10:46] <Nafallo> oh dear.
[10:46]  * Nafallo invisions a bunch of support requests that will claim support for 18months :-/
[10:47] <Laney> Maybe they /could/ be - I don't know how hard that limit is
[10:48] <Nafallo> bah. get the DBA to change the value on wildberry(?) instead ;-)
[10:49] <stgraber> we usually don't re-generate the index files for the release pocket after having marked the series stable
[10:49] <Laney> It's the Packages file
[10:49] <Nafallo> oh right. it's that part as well...
[10:49] <Laney> so, fixing LP however that needs to be done, deploying it and then regenerating those
[10:49] <Laney> or working around it in the software ...
[10:50] <cjwatson> raring hasn't been marked as released yet
[10:51] <cjwatson> But the 18m is in LP code
[10:51] <wgrant> Easy to change
[10:51] <Laney> quick enough to do today?
[10:51] <cjwatson> wgrant: *So* glad you're awake
[10:52] <wgrant> As long as we're OK with regenning the release pocket indices in an hour or so..
[10:52] <cjwatson> We'd been planning to release in eight minutes :)
[10:52] <cjwatson> But I guess we're not
[10:52] <wgrant> cjwatson: StevenK and I are off today, but I'm around.
[10:52] <cjwatson> Can we cowboy more quickly than an hour?
[10:52] <wgrant> Sure
[10:52] <stgraber> cjwatson: ah sorry, I didn't actually check the series status on LP, some people reported pull-lp-source being broken earlier and I just assumed this was because the series was marked stable (without a new devel series existing)
[10:52] <cjwatson> stgraber: No, that's a "same day of release" thing
[10:52] <wgrant> A few hours earlier than I expected..
[10:53] <cjwatson> Now, I also need to arrange for a publication in raring
[10:53] <cjwatson> Hmm
[10:53] <cjwatson> Maybe a trivial change-override would be easiest
[10:53] <wgrant> Or just be careful
[10:53] <cjwatson> I'm sure I can find a section to change
[10:53] <cjwatson> Yeah, I know that's available but prefer not to do it at short notice
[10:53] <wgrant> True
[10:54] <Laney> stgraber: yeah, that's distro-info-data
[10:54] <cjwatson> It's just http://paste.ubuntu.com/5600690/ isn't it?  I don't see any relevant tests
[10:55] <wgrant> cjwatson: That'll change it for non-release pockets of previous series too, won't it?
[10:55] <Laney> Nafallo: good find(!)
[10:55] <wgrant> There appear to be no tests.
[10:55] <cjwatson> Yeah, it would.  Hmm
[10:55] <stgraber> cjwatson: is that a per-series change? we probably want to make it just >=raring otherwise we'll end up with weird values for SRUs
[10:55] <stgraber> what wgrant said ;)
[10:55] <Nafallo> sorry for blocking release...
[10:55] <wgrant> cjwatson: Let's just add a RaringUbuntuMaintenance
[10:56] <Nafallo> rather do it now than after the fact though :-)
[10:56] <cjwatson> Yeah, we'll have to fix it for > raring too, but we can do that at more leisure
[10:56] <wgrant> Exactly
[10:56] <stgraber> Nafallo: well, we definitely prefer to find that kind of thing before we released as fixing that one post-release would have been impossible (at least in a "clean" way)
[10:57] <cjwatson> wgrant: Can I leave this with you to sort out?
[10:57] <Nafallo> yeah, glad I wasn't 8 minutes later with finding it :-)
[10:57] <wgrant> cjwatson: I think http://pastebin.ubuntu.com/5600696/ should do it, but I'll check.
[10:58] <cjwatson> Yeah, looks promising
[10:58] <cjwatson> Nafallo: Yeah, don't apologise, glad you spotted this now
[10:59] <cjwatson> I'll let the web team know
[11:03] <wgrant> cjwatson: Looks fine on DF. I guess we cowboy the new class, rerun cron.germinate (perhaps hacking it to just run over raring and not actually running germinate), then get the release pocket republished?
[11:03] <cjwatson> We could just let cron.germinate run normally, IMO
[11:03] <cjwatson> It's quick enough these days
[11:03] <wgrant> Ah, true, forgot you fixed that.
[11:03] <wgrant> mawson:/srv/launchpad.net/codelines/current/raring.supported{,2} are the old/new if you want to check
[11:03] <cjwatson> In fact, if the cowboy is mid-publisher-run, it could catch a normal cron.germinate
[11:04] <cjwatson> cjwatson@mawson:/srv/launchpad.net/codelines/current$ diff -u <(sed 's/18m$/9m/' raring.supported) raring.supported2
[11:04] <cjwatson> cjwatson@mawson:/srv/launchpad.net/codelines/current$
[11:04] <cjwatson> promising
[11:04] <wgrant> That's the plan
[11:08] <cjwatson> Of course, the support status in images will be wrong
[11:08] <cjwatson> I think I'm going to Not Care
[11:08] <wgrant> Indeed, but that's a bit harder to fix and less important :)
[11:08] <cjwatson> And if you never connect to the network, then support status is kind of immaterial
[12:06] <Nafallo> nafallo@wolf:~$ ubuntu-support-status
[12:06] <Nafallo> Support status summary of 'wolf':
[12:06] <Nafallo> You have 500 packages (98.0%) supported until January 2014 (9m)
[12:06] <wgrant> :)
[12:06] <wgrant> Thanks for confirming
[12:06] <Nafallo> ^- cjwatson :-)
[12:06] <Nafallo> yw :-)
[12:06] <Nafallo> thanks for fixing it so quickly :-)
[12:11] <pitti> cjwatson, infinity, release team: congratulations!
[12:11] <Nafallo> good work guys! :-D
[12:11] <pitti> so for the first time after a release we don't have the name of the next one
[12:12] <Laney> slippery series
[12:12] <xnox> NoNameYet
[12:12] <ricotz> pitti, right something was missing ;)
[12:13] <Nafallo> pitti: nonameyet.com is still registered, innit? ;-)
[12:13] <pitti> slurpy smoothie!
[12:14] <ricotz> slim snake
[12:14] <Laney> aaaaanyway
[12:14] <sladen> infinity: you're early!  (It's no 13:04 UTC)
[12:14] <Laney> good stuff.
[12:15] <infinity> sladen: Releasing at version time is a silly and short-lived non-tradition.
[12:18] <Nafallo> and will fail after 24.10 as well.
[12:18] <Nafallo> and yeah, we'll still all be here :-P
[12:26] <sladen> Nafallo: simples.  Just release the day after the release day.  *nods*
[12:26] <Nafallo> haha
[12:26] <Nafallo> I'm fine with 24h in a day, thank you very much ;-)
[13:05] <pitti> lool: FYI, I took the liberty of moving the remaining WIs of https://blueprints.launchpad.net/ubuntu/+spec/client-1303-converged-network-stack to ubuntu-13.05 (please feel free to readjust as you see fit, of course)
[13:06] <pitti> lool: I left one for me for 13.04, that's the one I'm currently working on
[13:13] <lool> pitti: all fine; thanks!
[13:38] <bdrung> ScottK: we need the codename for raring+1
[13:38] <ScottK> bdrung: Yes, but it seems it should also deal better with the case of "no devel release exists".
[13:38] <ScottK> Since it happens every cycle.
[13:39] <bdrung> not every cycle (we used to know the codename before the release)
[13:40] <bdrung> ScottK: define "it". which tool should behave better without a devel release?
[13:40] <ScottK> distro-info.
[13:40] <ScottK> No, there's a period where the devel release if frozen, but the new one doesn't exist yet.
[13:40] <ScottK> That happens every cycle.
[13:41] <bdrung> this is impossible. "distro-info --devel" should print the development codename. what should it print if it doesn't know it?
[13:41] <ogra_> ScottK, we usually had the series up on LP before the release
[13:41] <ogra_> this is the first cycle we dont
[13:41] <ogra_> since we didnt get a name early enough
[13:41] <bdrung> is mark working on the name?
[13:42] <ogra_> no idea, he is on the road since weeks
[13:43] <vibhav> Are the supported, lts, etc values in distro-info hardcoded?
[13:43] <cjwatson> bdrung: yes
[13:45] <bdrung> vibhav: no, they are calculated based on the date. distro-info has it's own "database" (see distro-info-data)
[14:41] <mpt> tedg, hi, take a look at the table of contents for <https://wiki.ubuntu.com/Networking>. Is that the kind of structure you had in mind?
[14:43] <tedg> mpt, Yup, thanks!
[14:45] <mpt> tedg, most of the PC stuff is a couple of years out of date, so disregard that for now. :-)
[14:46] <tedg> mpt, Yeah, I've been using it as guidance for a feature list, but not the details of it.
[14:47] <tedg> mpt, I'm curious if anyone uses Bluetooth teathering anymore since most phones have WiFi.
[14:47] <mpt> No idea :-)
[14:47] <mlankhorst> I still use usb tethering from time to time, so tethering itself has to work at least..
[14:48] <tedg> Sure, but I'm guessing most use USB or Wifi.
[14:48] <tedg> Seems like WiFi is becoming the 2.4GHz protocol of choice.
[14:49] <Nafallo> wifi can be protected by WPA... not sure what the deal with Bluetooth would be.
[14:50] <Nafallo> but then again, I tend to get 3G dongles from work places ;-)
[14:50] <stgraber> tedg: I still use bluetooth tethering as it uses around a tenth of the power as a wifi AP would
[14:50] <tedg> stgraber, If you're worried about power, why not use USB?
[14:50] <stgraber> tedg: I do when I remember to bring the cable along with me ;)
[14:50] <tedg> Heh, okay.
[14:51] <ogra_> the bluetooth cable ?
[14:51] <cyphermox> ogra_: :)
[14:51]  * Nafallo smacks ogra_ gently
[14:51] <stgraber> tedg: when on the bus/train, I usually like not having to pull cables out of the bottom of my bag just to get connectivity ;)
[14:51] <tedg> ogra_, It makes your bluetooth faster, I'll sell you one, only $19.99.
[14:51]  * ogra_ grins
[14:52] <ogra_> tedg, can you tweet that  ? swww.ismytwitterpasswordsecure.com
[14:52] <stgraber> I can sell you one that's even better than tedg's because it has gold plated connectors, but that's going to be $99.99
[14:52] <ogra_> oops
[14:52] <ogra_> -s
[14:52] <ogra_> stgraber, oxygen free insulation too ?
[14:53] <stgraber> sure ;)
[14:53] <Laney> bdrung: can haz new distro-info-data?
[14:53] <Laney> tumbleweed: or you
[14:57] <tumbleweed> Laney: it has a name?
[14:57] <Laney> yeah
[14:57] <Laney> I have the csv change - can push if you want?
[14:58] <tumbleweed> phew
[14:58] <tumbleweed> please push, I'll be happy to review and upload
[14:58] <Laney> ok, one minute
[15:00] <ScottK> bdrung: OK.  Now we have the release name.
[15:00] <Laney> ScottK: see immediately above
[15:00] <ScottK> Oh.
[15:02] <Laney> tumbleweed: done
[15:10]  * tumbleweed supposses it's too soon to guess a jessie release date...
[15:23] <ScottK> It's never too soon to guess.  You'll be wrong, but you can always guess.
[15:24]  * tumbleweed left that bit for now. Busy preparing all the SRUs
[15:38] <hl2> http://url9.de/BQW
[15:46] <seb128> roadmr, hey
[15:46] <roadmr> seb128: hello!
[15:47] <seb128> roadmr, re. that checkbox bug, my "quite some users" is based on the errors.ubuntu.com stats, it has over an hundred reports in a week
[15:47] <roadmr> seb128: hm, is there a way to know if they are e.g. kubuntu users? I'm just concerned that I'm unable to reproduce the problem on a vanilla raring install
[15:48] <seb128> roadmr, nothing out of ubuntu-desktop and ubuntu-gnome-desktop is depending on gstreamer1.0-alsa
[15:48] <seb128> roadmr, so yes, any user of xubuntu, kubuntu, lubuntu, etc will have the issue
[15:48] <bdrung> thanks tumbleweed for updating distro-info-data
[15:48] <roadmr> seb128: oh perfect, that makes it easier to come up with a repro case
[15:49] <seb128> roadmr, well, the repro is easy, sudo apt-get remove gstreamer1.0-alsa
[15:51] <roadmr> seb128: oh I tried that and it didn't fail as expected, but I may have been doing things wrong... let me double-check
[15:52] <tumbleweed> bdrung: np
[15:52] <roadmr> seb128: yes, I'm an idiot, I was doing it wrong (tm). I'll update the bug with the repro case
[15:53] <seb128> roadmr, good
[16:47] <Laney> slangasek: we think we found out where the pxgsettings processes were coming from
[16:51] <slangasek> Laney: and you will be killing them with fire now? :-)
[16:51] <Laney> some of them with fire, some maybe a scalpel
[16:57] <Laney> I think maybe signond's usage could go away too
[16:57] <Laney> it copies some code from a Qt merge proposal
[16:57] <slangasek> so the lines on http://reports.qa.ubuntu.com/memory/arch/armhf/ showing 32M of usage on touch... those are the ones where the shell crashed, right? :P
[16:58] <Laney> oops, that was meant to be #-desktop
[16:58] <slangasek> Laney: so reducing use of the process is one thing... having a sensible interface to the process is another.  Do you know why this isn't a dbus service?
[16:59] <Laney> no, seems like it could be
[16:59] <Laney> it's a weird interface
[16:59] <vibhav> Will we be writing "saucy" in all our changelogs?
[17:00]  * vibhav cheers
[17:16] <ScottK> ev: If I give you the specific IDs, can I get copies of reports to errors.ubuntu.com?
[17:16] <ev> ScottK: yup
[17:17] <ev> ScottK: I'm fixing the fact that you can't access them very soon, by the way. We're working through the final parts with Legal.
[17:17] <ScottK> https://errors.ubuntu.com/problem/6c589671ce9751e5bca7a74eff3a21046192b243 https://errors.ubuntu.com/problem/bfe073cd44500dbbe762cd163878a096e16b5c46 https://errors.ubuntu.com/problem/e1974e755b62066bdbd624110262af4d6e0071b1
[17:17] <ScottK> Great.
[17:18] <ScottK> ev: Also, I can con firm that for packages that we don't send the bug reports to bugs.kde.org, the e.u.c reporting is working in Kubuntu 13.04.
[17:18] <ScottK> (you may recall we discussed this at the last UDS)
[17:18] <ev> https://errors.ubuntu.com/problem/6c589671ce9751e5bca7a74eff3a21046192b243 was unsuccessfully retraced - it'll hopefully be reprocessed soon
[17:19] <ev> ScottK: excellent!
[17:19] <ev> same for https://errors.ubuntu.com/problem/bfe073cd44500dbbe762cd163878a096e16b5c46
[17:19] <ev> oddly we don't have a Stacktrace for https://errors.ubuntu.com/problem/e1974e755b62066bdbd624110262af4d6e0071b1 - I'll look into this. I've never seen that before.
[17:19] <ScottK> Fun.
[17:21] <ev> ScottK: here's the not-retraced version, for whatever it's worth: http://paste.ubuntu.com/5601719/
[17:21] <ev> for that last one
[17:21] <ev> presumably you'll want locals and things
[17:21] <ev> I'll try to find time next week to dig at it
[17:22] <ev> let me know if you find any other problems you want access to
[17:22] <ScottK> Thanks.
[17:23] <ScottK> Can you look if there are any other recent crashes against akonadi 1.9.1-0ubuntu1 that might have been retraced?
[17:24] <ev> sure
[17:26] <ev> ScottK: those appear to be the only ones so far
[17:28] <ScottK> thank for looking
[18:51] <ev> cjwatson, bdmurray: given that https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1094777 is coming up quite a lot today from people who have not installed the release upgrader from -updates, I'd like to propose that we force an upgrade (with permission) before we run the release upgrader.
[18:51] <ev> https://errors.ubuntu.com/problem/27a5550c8a96660e9b19630655aa1c613772e29b - confirms this - lots of instances of 0.190.1 for today
[18:52] <ev> ^ mterry if you have thoughts as well
[18:52] <ev> so to clarify, you start update-manager, it says there's a new version of Ubuntu available. It then does an apt-get upgrade (with your permission), then downloads and runs the release upgrader.
[18:53] <mterry> ev, I thought we didn't show the release upgrade if we weren't up-to-date...
[18:53] <ev> if they didn't have -updates enabled, they'd appear as up-to-date
[18:53] <ev> but I doubt that many systems have gone and disabled updates
[18:53] <ev> so perhaps that check is broken
[18:54] <mterry> ev, the flow may have changed in the move from Update Manger -> Software Updater
[18:54] <mterry> ev, I had thought we still prioritized updates over upgrades though
[18:55] <ev> yeah
[18:56] <mterry> ev, how would we force users to get the update?
[18:56] <ev> mterry: ensure that -updates is enabled, then trigger an upgrade
[18:56] <mterry> ev, yeah, but how we would push out an update that did that?
[18:57] <ev> mterry: if you mean for 12.10, I think we're screwed there
[18:57] <ev> but we can make this more robust for future versions
[18:57] <mterry> ev, yeah, OK.  And 13.04 too for any similar problems
[18:57] <xnox> it all depends on how far in the codepath of the downloaded tarball we get into, if any.
[18:57] <xnox> maybe we can sneak something in, in the upgrade tarball. But i would have thought that would be done by now, if it was possible.
[18:58] <xnox> as clearly this problem was known when it was fixed.
[18:58] <mterry> xnox, we don't get as far as the tarball if I recall correctly
[18:58] <xnox> mterry: then well no chance....
[18:59] <xnox> ev: do we know if security is enabled on those machines reporting the error?
[18:59] <ev> xnox: no, but that might be worth recording in the future
[18:59] <ev> feel free to file a bug for that
[18:59] <mterry> I understand that this update is security-level-important if we want users to upgrade, but it's hard to classify in any way as an actual security update
[19:00] <mterry> Is there precedent for similar updates?
[19:46] <georgelappies> hi all, is anybody else experiencing 'ugly' non -anti aliased fonts in QtCreater / UbuntuSDK or any Qt5 based apps in Ubuntu 13.04?
[20:03] <AbsintheSyringe> does anyone have any ideas why my Nautilus won't even start on 13.04?
[20:04] <AbsintheSyringe> I have/had this same problem on Debian Sid with 3.8.x kernel, but as soon as I would move back to 3.2 (wheezy) it would just go back to normal
[20:05] <AbsintheSyringe> tried moving back to 3.5.x on 13.04 but that didn't do anything
[20:05] <AbsintheSyringe> that's the reason I have a feeling it might related to full disk encryption (lvm)
[20:13] <stokachu> is there a way in upstart when doing a 'start on started <service>' to wait a few second before starting its service? basically there is a couple second delay because of some network activity from the relied on service
[20:15] <ScottK> It'd be better if the service on which you're depending didn't emit started until it actually was.
[20:16] <stokachu> ah ok ill read up on the emit section, i briefly glanced over that
[20:18] <slangasek> stokachu: rather, it's the 'expect' stanza of the depended-on service
[20:18] <slangasek> ('emits' is informational only)
[20:18] <stokachu> ok cool, ill read up on that section
[20:20] <stokachu> slangasek: If your daemon has a "don't daemonize" or "run in the foreground" mode, then it's much simpler to use that and not run with fork following. One issue with that though, is that Upstart will emit the started JOB=yourjob event as soon as it has executed your daemon, which may be before it has had time to listen for incoming connections or fully initialize.
[20:21] <slangasek> right
[20:21] <stokachu> is that saying there isn't a good way to wait for the application to be ready for accepting connections?
[20:21] <stokachu> i see where it emits the start job but in my case that doesn't really mean its ready for processing
[20:21] <slangasek> sure there is - make the application daemonize properly (which means, the parent doesn't exit and return control until after it's listening on all appropriate sockets)
[20:23] <stokachu> so ill have to fork to get this to work as expected then
[20:23] <slangasek> hmm, so the cookbook is saying "it's simpler to use foreground mode" - yes it is simpler, but it's almost assuredly not going to give the desired semantics for dependent services
[20:23] <stokachu> yea my app doesn't fork at all
[20:23] <stokachu> i was attempting to let upstart manage it without having to daemonize it
[20:23] <slangasek> stokachu: you could also use 'expect stop', that'd be easier to implement in the app
[20:25] <stokachu> ok ill look into that
[20:25] <stokachu> emitting sigstop looks simple enough :)
[20:25] <stokachu> maybe i can get by with that
[20:25] <slangasek> fwiw, the existence of 'expect stop' is vastly underadvertised... mostly because it's not a common modality among existing software
[20:26] <stokachu> slangasek: but its a viable solution i would think
[20:26] <slangasek> yep, should be
[20:26] <stokachu> as far as the documentation is telling me
[20:26] <stokachu> cool thanks!