[00:28] cjwatson, back in june I tinkered with ureadahead to have it use the pipe method instead of the log file method for ftrace... this eliminated the need to preallocate a buffer to hold the full trace, and instead has ureadahead parse the trace log in real time. would you be interested in it if I rebased it and proposed merging? [00:30] cjwatson, err, nevermind, I meant keybuck [00:31] Keybuk, back in june I tinkered with ureadahead to have it use the pipe method instead of the log file method for ftrace... this eliminated the need to preallocate a buffer to hold the full trace, and instead has ureadahead parse the trace log in real time. would you be interested in it if I rebased it and proposed merging? [00:47] ohh, you've merged that fragraph.py.. I couldn't remember who gave me that === mtaylor|afk is now known as mtaylor [02:36] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [06:56] good morning! === vila is now known as vila-afk [10:00] hi [10:00] django has released security releases for all production branches, are we going to get that in lucid + ? [10:00] two security bugs were fixed [10:25] dholbach, morning [10:25] hey apw [10:25] anyone else seeing gdm greeter repeatedly crashing before it prompts ? [10:25] dholbach, nothing works for me today its most depressing [10:26] hum... is anything in /var/log/Xorg.0.log or /var/log/gdm/* about that? [10:27] apw, it certainly works for me (in a vm) [10:27] maybe the #ubuntu-desktop mafia can help? [10:28] dholbach, yeah continius errors about window==NULL [10:28] hum, no idea what that is about [10:30] dholbach, will ask the #u-d mafia, but i bet they are all gone [10:31] ^ RAOF, bryceh? [10:31] (only ones I could find :-)) [10:32] heh both in other timezones tho ... sigh [10:33] dholbach, that will teach me to dogfood, we cannot be trusted to not push poo before a break [10:33] this is a problem with the gtk+ packages [10:34] ricotz, yeah you seeing it too? [10:35] yes [10:35] ok, I see it too :) [10:35] i am not sure yet, what the real cause is, but the gtk+3.0 dev is broken [10:36] also the gobject-introspection packaging it messed up :( [10:37] * apw wonders who to slap [10:37] I don't see anything obvious in http://launchpadlibrarian.net/61126003/gtk%2B3.0_2.91.7-0ubuntu1_2.91.7-1ubuntu1.diff.gz [10:37] dholbach, it is 2.91.7 the tarball doesnt ship all needed *.pc files [10:39] aha [10:39] dholbach, doesn't seem robert is on IRC, at least if his IRC entry is accurate anyhow [10:40] no seems like he's not around [10:41] * apw thinks we need a word about shipping upgrades and then going on holiday before they are even built [10:42] ricotz, does it help if i downgrade to .6 ... as confirmation that is the broken component? seems i have them in my cache [10:43] apw, i think this could help, but the gtk+2.0 update might have a problem too [10:43] ricotz, gurgle, ok i'll try that downgrade and report back [10:44] i uploaded a git snapshot of gtk+3 to my ppa, it might fix some problems for me [10:44] ricotz, ok downgrading the 3.0 stuff did not help [10:45] apw, so if the problem persists i can try to downgrade gtk+2.0 too [10:46] ricotz, ok downgrading the 2.0 as well seems to get me a gdm prompt at least [10:46] dholbach, a nice mess and no mistake [10:47] apw, you might want to go back to gtk+2.0 2.23.2 [10:47] ah, nevermind [10:47] ricotz, i think thats the version i had before, yes [10:48] ricotz, thanks for your help finding the errant packages so quick [10:48] apw, oh another thing [10:49] apw, are there known problem with 2.6.37-11 and nvidia blob [10:49] ricotz, https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html? [10:49] ricotz, not that i've heard about, but the binary blobs normally explode when we change the kernel [10:50] apw, I agree it's not nice to be stuck with a problem like that, but I'm sure Robert really didn't mean to sabotage you [10:50] (or whoever else uploaded the change that made things break) [10:50] dholbach, i know he didn't do it deliberatly :) but shipping a primary library change as a break starts is asking for trouble [10:51] thats why we did our last kernel update 4 days before we went offline :) [10:51] dholbach, alright, that might be it [10:51] ricotz, I filed a bug about mine [10:52] ricotz, cirtainly you cannot have =keep turned on with those binary blobs, they do not cope with the card being initialised [10:52] ricotz, which is pretty crap given they are from the vendors of the devices and they have the manuals for the chipsets and everything [10:53] ricotz, is there a bug on this gtk stuff yet? [10:53] apw, yeah, i want to try the nvc0 nouveau branches at some time, but right now i need to use the blob :( [10:53] apw, i havent filed one, so maybe not [10:53] dholbach, you ? [10:54] I didn't file a bug on the gtk stuff [10:54] * apw will file one [10:54] ricotz, did you say it was missing the .pc files ? [10:55] yes, the gtk+3 one but that is an upstream issue which is fixed [10:58] ricotz, ok i will leave the description plain without that and just include the work around [10:58] https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/693737 [10:58] Ubuntu bug 693737 in gtk+2.0 (Ubuntu) "gtk+2.0 update 2.23.3-1ubuntu2 update triggers repeated gdm greeter crashes" [Undecided,New] [10:59] dholbach, this machine is turning into a right frankenstein, udev and gtk held back now to get a clean boot ... sigh, at least the kernel works [11:00] apw, there's times that have been worse I think :-) [11:02] dholbach, that i can believe, no chance of working CDs over the break sadly [11:02] that will upset cert [11:45] zyga: ask on #ubuntu-hardened [11:49] thanks === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan [12:45] cjwatson: hi, regarding Bug #548981 , I'd marked the dpkg task as fixed, since tedg mentioned in the session that it was fixed in dpkg. I dont know the commit# though. Maybe we can ask tedg when he returns from his vacation.. [12:45] Launchpad bug 548981 in indicator-session (Ubuntu) "Indicator should only turn red after the last package has been installed" [Low,Triaged] https://launchpad.net/bugs/548981 === freeflyi1g is now known as freeflying [13:23] vish: *shrug* as far as I know he was mistaken, since this is plain-and-simple not a problem in dpkg itself, but I don't know that it matters all that much. I was just trying to stop people searching for a non-existent fix. [13:24] vish: (I upload dpkg to Ubuntu, tedg doesn't ;-) ) [13:24] cjwatson: yea, i know.. :) [14:16] Does anyone have experience with nfs root mounted systems? I'm specifically curious about how sm-notify works without any local storage to tell us who to notify. [14:32] hrm, seems like one would need a dedicated /var for each client or reboot notification isn't going to happen. [15:18] :> [15:28] cjwatson: is sync tor on todo archive admins? [15:30] ari-tczew: yes === dholbach_ is now known as dholbach === akshatj is now known as akshatj|study [16:35] SpamapS: re bug 690401 - apologies: your RLEVEL logic is of course correct: seemingly my [16:35] Launchpad bug 690401 in nfs-utils (Ubuntu Lucid) "statd startup races with / becoming writable (dup-of: 581941)" [High,Confirmed] https://launchpad.net/bugs/690401 [16:35] brain doesn't parse shell syntax as well as the shell! [16:35] Launchpad bug 581941 in nfs-utils (Ubuntu Lucid) "statd does not start automatically when needed nor can be forced to start on boot" [Medium,Triaged] https://launchpad.net/bugs/581941 [16:37] SpamapS: I'm still confused by the whole runlevel thing though. Keybuk has pointed out that "there be demons" with the "start on... runlevel" logic proposed. [16:39] jhunt: it does indeed feel as if I've set off on a voyage destined for the edge of the map, not down the coastline ;) [16:40] jhunt: the problem is, if we just drop the 'start on started portmap' then when portmap is restarted, we won't start back up.. and if we drop both.. then we won't pick up the new portmap [16:41] jhunt: so I truly want to express "start on started portmap and run level is one of [2345]" [16:42] it may be better to simply do a check for /var being writable. [16:43] okay, who did an upload today and turned GDM into a 1 Hz flashing rectangle of white ? [16:44] sladen: santa's little helper? [16:46] SpamapS: the timing is excellent [16:46] * SpamapS was just about to do-release-upgrade -d .. will hold off ;) [16:46] bryceh: ^^ would the failsafe change to xorg yesterday have made login impossible? [16:47] sladen: Probably either a security feature or trying to make training simpler for corporate clients. [16:49] ScottK: there's certainly no risk of a GUI login, accidental, malicious, or intended [16:50] sladen: Right. Thus it's secure and training costs are minimal. [16:51] ScottK: the wonderful thing is I can't file a but from lynx about not being able to file bugs from lynx either :) [16:52] sabdfl keeps asking me for a get-out-of-jail pen-drive image ... could do with it now [16:53] SpamapS: err [16:53] SpamapS: even with the portmap, when portmap is restarted, that job won't start back up again [16:53] so you're already putting diesel in the tank [16:54] and worrying about your mileage varying [16:54] Keybuk: can you explain further? [16:56] sure [16:56] so you've done: [16:57] start on one-thing and another-thing [16:57] right? [16:57] that doesn't work the way anyone thinks it does [16:57] and while it works as designed, the design is wrong [16:57] "and" means both events must happen for the job to be started [16:57] I did do that, however slangasek pointed out that it will cause a deadlock so I think I have to remove the and [16:57] but, it also means, once the job is stopped, BOTH events MUST happen AGAIN [16:58] so if you do [16:58] start on started portmap and net-device-up lo [16:58] then restarting portmap will stop statd [16:58] but won't start it back up again [16:58] because it's waiting for the network device to come up [16:58] the logic I've proposed is start on started portmap OR mounting TYPE=nfs OR runlevel [2345] [16:59] it was "AND" last time I looked ;-) [16:59] the one that steve took issue with was start on started portmap OR (local-filesystems and mounting TYPE=nfs) [16:59] yeah, basically avoid and unless you really know what you're doing [16:59] if you have a problem, and doesn't solve it [16:59] it gives you new and worse problems [17:00] so [17:00] winding back a bit [17:00] I'm trying to understand what you're trying to change [17:00] right, some of the discussion has been going on in a merge proposal.. === jelmer_ is now known as jelmer [17:00] well, that, and all the discussion is filed under TL;DR at this point [17:01] I assume you're working on a fix for that fact that statd doesn't get started on boot if you don't mount an NFS share? [17:01] right, well I've got you now so.. to answer your bigger question.. I just want to make sure that we *don't* try to start statd before /var is writable... [17:01] why before /var ? [17:02] sm-notify has to write to /var/lib/nfs [17:02] ok, so why not: [17:02] start on local-filesystems [17:02] thinking [17:03] is that event emitted on nfsroot only setups? [17:03] no idea [17:03] I've never tested nfsroot [17:03] it's emitted by mountall [17:04] and I think mountall has always had issues with nfsroot setups ;) [17:04] Also it would require that all local filesystems are mounted before nfs.. but.. that actually is what I'm looking at doing anyway.. just documenting that fact. [17:05] Keybuk: it's not "start on local-filesystems" because it will race portmap, which only depends on virtual-filesystems [17:05] will it race portmap? [17:05] someone's stuck start portmap in the statd pre-start [17:05] right [17:05] hm [17:05] there may not be an ideal solution for this today [17:05] but I'd like to at least know what the ideal solution should be so I can test that works in upstart2 [17:05] right, I suppose that should work then [17:06] will start block if a job is already goal==start but not running? [17:06] while advising on a hack to solve the bug that is open today [17:06] SpamapS: no, but then there's a status portmap right after the start portmap ;-) [17:06] Keybuk: which will fail the pre-start .. which means we then don't start statd right? or does it mean it will be tried again? [17:07] there's a small race there that may mean it won't be tried again [17:07] if portmap gets started between the point the status call gets told it's not running and stops the job [17:07] well this is handled by the OR started portmap [17:07] right, but there's a race there [17:08] if we just add a check to either sm-notify, or the pre-start, that makes sure /var is writable before we try to run sm-notify [17:08] I think the problem is with the NFS shebang is that too many start conditions are trying to be encoded [17:08] you want to start on boot [17:08] but simultaneously before and after some event [17:08] Its ok to try it when portmap is started and on local-filesystems, as long as we only go forward after /var/lib/nfs is writable. [17:08] and if the event doesn't happen [17:09] SpamapS: I don't think you can encode that today [17:10] Right it does seem like there is a singular sync point that we want to hit [17:10] after portmap, after local filesystems, before mounting any nfs mounts [17:10] maybe the right thing to do is to try and draw the conditions [17:10] if we can see the possible timelines, it may be more obvious [17:12] Right.. as I'm drawing.. is local-filesystems ever emitted before virtual-filesystems? [17:12] no, I think that's an invariant in mountall [17:12] it always does virtual, local, remote [17:12] ok, checked [17:12] it enforces virtual before local [17:12] and enforces virtual before remote [17:12] but you may get [17:13] virtual, local, remote [17:13] OR virtual, remote, local [17:13] it is.. [17:13] one of the conditions for firing local-filesystems is virtual_triggere [17:13] d [17:13] yes [17:13] so start on local-filesystems hits the mark exactly [17:14] you might want: [17:14] start on local-filesystems or started portmap [17:14] Its still possible that this will be too late for statd, but that is something that people configuring systems must be conscious of. [17:14] to pop up the restart on upgrade case [17:14] mop up, sorry [17:15] but then the 'or started portmap' races the rw mount of /var/lib in the on-boot case? [17:15] Right, unless we say either "but not during bootup" or "but only if /var is writable" [17:15] which I think is ok for a pre-start .. no? [17:16] and if local-filesystems isn't handled synchronously, the whole thing can still race an attempt to mount an nfs shar [17:16] e [17:16] at boot [17:16] slangasek: indeed, local-filesystems is not waited on.. however [17:16] start on mounting TYPE=nfs *is* [17:17] right, local-filesystems is a signal [17:17] mounting is a hook [17:17] this is why I'm trying to get thinking in terms of a timeline [17:17] SpamapS: which doesn't help us if you can't mention 'mounting' in the job because we can't use AND :) [17:17] v | <-----> (portmap) [17:18] | l [17:18] vs [17:18] v | <-----> (portmap) [17:18] | l [17:18] slangasek: we don't need AND [17:18] in those two cases, where should this go? [17:19] SpamapS: what we need is: statd started after portmap, after /var/lib is mounted rw, and before any attempts to mount an nfs filesystem [17:19] do you need statd to mount an nfs filesystem? [17:19] yes [17:19] I thought statd was for when someone was mounting yours [17:20] because you definitely also need statd for when someone is mounting *your* NFS filesystems [17:20] it's also needed on the client side [17:20] which means it's much more complicated than what you just said [17:20] because then it's [17:20] statd started after portmap, after /var/lib is mounted rw, before any attempts to mount an nfs filesystem and if there are no nfs filesystems [17:20] Keybuk: "when someone is mounting your NFS filesystems" comes later; nfs-kernel-server isn't even converted to upstart yet [17:20] slangasek: statd doesn't get started in that case ;- [17:21] Keybuk: right, sorry, I was implying that part [17:21] you realise of course that upstart will only stop the *first* attempt to mount an nfs filesystem > [17:21] yep :/ [17:21] (which I guess is ok, because mountall waits anyway) [17:21] so that looks something like: [17:21] start on started portmap \ [17:22] and local-filesystems \ [17:22] and mounting TYPE=nfs [17:22] slangasek: maybe portmap should start on a mounted, rather than virtual-filesystems .. [17:22] nope [17:23] there's no way to use 'mounted' to describe what you want in the general case [17:23] because fstabs are varied [17:24] and if you do an and.. kittens suffer capital punishment.. [17:24] not always, it just pays to think [17:24] well wait [17:25] it will fail to start if portmap isn't started yet right? [17:25] in the above case, for example, it will all go very badly wrong [17:25] so the OR still works.. the second attempt will succeed [17:25] SpamapS: no [17:25] SpamapS: unfortunately you have a race [17:25] again, think in terms of timelines [17:25] I'm drawing it right now.. ;) [17:26] | <--> : (status, portmap is not started) [17:26] | : (portmap is started ) [17:26] | (job is stopped) [17:27] it's possible for started portmap to happen while the result of start portmap/status portmap being still in transit back to the job [17:27] in which case the job is in JOB_START when it gets told "portmap started" [17:27] how about: start on started portmap $post_boot or (started portmap $at_boot and local-filesystems) or mounting TYPE=nfs? Or was the magic to distinguish between boot-time and post-boot start of portmap rejected when I wasn't looking? [17:27] slangasek: hmm, that's quite a nice idea - though how would you put the magic in? [17:28] Keybuk: it was SpamapS's idea to get the portmap job to export some appropriate variables; neither of us had quite worked out yet what the mechanism for that was [17:29] you can export variables from events that started you [17:29] so if you did something like: [17:29] start on virtual-filesystems and net-device-up IFACE=lo [17:29] exec initctl emit start-portmap ON_BOOT=yes [17:29] then in portmap.conf [17:29] start on start-portmap [17:29] export ON_BOOT [17:29] you can do elsewhere [17:29] start on started portmap ON_BOOT=... [17:30] (you need the middle-man job to start portmap, rather than portmap having its own condition) [17:30] ah so you can only export from events.. not from the environment [17:30] tbh, I suspect this NFS stuff would get a lot easier to understand if we just had all the NFS-y things having [17:30] start on NEED_NFS=y [17:30] and something else actually emitting those events ;) [17:30] err [17:30] start on need-nfs ;-) [17:30] SpamapS: upstart doesn't know the environment of its children [17:30] SpamapS: only the environment it gave to its children [17:30] (UNIX 101, dear) [17:31] * SpamapS was obviously a bit hung over that day. :/ [17:32] . o O { of course, upstart could look at /proc/$PID/environ at the point of the started event and re-import that } [17:32] so that gives us 'start on started portmap ON_BOOT= or (started portmap ON_BOOT=yes and local-filesystems)' ? [17:33] I think so [17:33] Makes sense to me. [17:34] so then just add a portmap-boot.conf that sets that [17:34] ... plus the 'or mounting TYPE=nfs' which fell off the end of my cut'n'paste [17:35] slangasek: wait, or? I thought it was and. [17:35] strike that [17:35] k [17:35] what about the timeline where portmap is not started yet, but we hit mounting TYPE=nfs [17:36] SpamapS: we keep the 'start portmap' in the pre-start script for that [17:36] Which won't block if its start/pre-start, or will it? [17:36] I've seen evidence to suggest that it might not block in that case, but if so that might be an upstart bug [17:39] checking === vila-afk is now known as vila [17:40] no [17:40] http://paste.ubuntu.com/546986/ [17:40] you will just get an error "job is already running" [17:40] even though its not, its in pre-start [17:41] slangasek: it does not block, and it is considered an upstart bug [17:42] Keybuk: fixable in the near-term? [17:42] (it's one I have a solution for I'm very proud of :p) [17:42] uhoh ;) [17:42] slangasek: it's not on the natty list [17:42] SpamapS: so anyway, there would still be a race condition there as a result of the upstart bug; but it would be a smaller race window than what we have now, and it needs to be fixed in upstart [17:43] quite a bit yes I agree [17:43] so we might try this route and see how close that gets us to something usable? [17:43] quite a bit smaller I mean [17:44] Yes, it seems a very tiny window. We should probably do a best-effort check for things that may cause portmap to start slowly. [17:45] you could also just do a loop in the pre-start checking the result of status [17:45] I didn't write it that way initially because of a conversation we had where you were very vehement about not doing that ;) [17:45] oh, I may have been vehemently misunderstanding your intentions [17:46] so, while ! status portmap | grep -q start/running; do sleep 1; done [17:47] sladen, oh I would highly doubt it [17:47] slangasek: should also have the start in there.. what if it failed, we'd spin forever without even trying to rectify the situation. [17:49] Keybuk: thanks for taking time to help out. :) [17:49] slangasek: ^ you too. :) [17:49] * SpamapS will bbiab === dendrobates is now known as dendro-afk [18:11] bryceh: seems to be somewhere in the asychronous DBusy soup [18:14] sladen, ah === dendro-afk is now known as dendrobates [18:22] SpamapS: yes, wasn't suggesting removing the 'start' line, just fixing the line after it === tkamppeter_ is now known as tkamppeter === sladen changed the topic of #ubuntu-devel to: Archive: Open | Natty GDM Login broken: Bug #693737 | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [18:56] any archive admins around? I'm trying to figure out why "tor" hasn't appeared in natty yet. [18:56] kees: +1 [18:56] I asked today about this case [18:57] yeah, I though it was stuck in NEW, but I don't see it. [18:58] kees: my guess is the AAs were finishing up EOY tasks [19:01] hm, actually, in looking at natty-changes, it seems there hasn't been a Debian sync in a while. [19:02] right, hence my theory :) [19:02] * kees scratches his head [19:02] maybe the auto syncs don't show up. [19:02] kees: no, they show up as Ubuntu Installer [19:02] I was thinking those were requested syncs, not auto syncs [19:03] kees: requested syncs show up with the name of the requestor [19:05] hm, no, it looks like auto sync doesn't show up. e.g. libdisasm does not appear in maverick-changes even though it was updated in maverick during an autosync [19:06] is there a document on the wiki that explains how to go about getting new binary packages added to the default install/cd? i'm having trouble finding one if so, and trying to find some clear explanation of that process [19:09] kees: it seems you're correct, I apologize for the wrong information :) [19:09] micahg: heh, no worries. I guess it was turned off due to the flood it would create. [19:09] unfortunately, I'm back to wondering when the last autosync was. :P [19:10] (and where tor ran off to) [19:10] kees: well, the bug's not closed, so it probably just hasn't been processed yet [19:10] * kees nods [19:10] and almost everyone's on vacation at this point [19:11] * micahg thinks there will be one last huge auto-sync on Jan 3 when everyone comes back [19:11] dobey: I think http://wiki.ubuntu.com/SeedManagement but for extra comedy that page is crashing at the server end [19:12] so it seems :-/ [19:15] kees: the delay gets us a couple extra bug fixes :) [19:16] micahg: hehe :) [19:20] kees: got "tor" synced? I see the sync request still open (bug 413657) [19:20] Launchpad bug 413657 in tor (Ubuntu) "Please sync tor 0.2.1.26-4 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/413657 [19:22] geser: that's old, IIUC. it had been on the autosync blacklist, but it got removed, so I've been trying to figure out why it didn't get autosynced [19:31] maybe nobody has done a new-source (or whatever it's called) run since [19:36] might be, auto-sync only syncs "existing" packages [19:37] import new packages is another script which gets run less frequently than the auto-sync script [19:37] geser: there's also a sync request filed for it [19:38] that was only recently acked [19:39] Laney: last week [19:40] was the queue processed since? [19:40] * micahg test builds the new version of tor [19:40] Laney: does not appear so [19:44] zyga: if you were subscribed to the D-Bus list right now, you'd understand the rationale for doing those D-Bus activation patches :-) [19:44] it has forced the desired discussion [19:44] well, shouting from Lennart anyway [19:50] Keybuk, hmm, dbus on freedesktop? [19:50] Keybuk, I'll check the archive, thanks for the hint [19:50] zyga: http://lists.freedesktop.org/archives/dbus/2010-December/013868.html is the link you want - it's buried in the thread view [19:54] ebroder, thanks [20:14] slangasek: actually I was suggesting moving the start into the loop, it may fail. But while disconnected, I thought of another thing we could try. What about making portmap start on ... whatever it has now .. or starting statd ? [20:14] zyga: http://lists.freedesktop.org/archives/dbus/2010-December/thread.html was an interesting read [20:14] slangasek: that would make sure statd never actually starts until portmap is started [20:15] sladen, I actually read most of the archive from that month [20:22] SpamapS: ah; I wouldn't move the start into the loop, because aside from the "already starting" race, the only reasons it should fail would seem to be fatal and shouldn't cause the statd job to be left looping [20:23] SpamapS: and portmap 'start on ... or starting statd' only ensures portmap is started first *if* portmap isn't already being started, which by all rights it should be === dendrobates is now known as dendro-afk [20:30] sladen: I wish that someone would fix the fd.o pipermail [20:30] it's annoying the way it doesn't correctly line up threads [20:41] slangasek: leaving the statd looping means never mounting nfs filesystems. [20:41] slangasek: and means never emitting 'filesystems' [20:42] slangasek: so at the very least, we should only wait for a little while.. hence my thought that we should make a best effort attempt to identify the longest we think it should ever take for portmap to be up and serving. [20:45] slangasek: another thought for the longer term.. socket activation for portmap would seem to alleviate this problem entirely wouldn't it? === ximion1 is now known as ximion [20:55] bryceh: narrowed down to today's libgtk2.0-bin (>2.32.2-0ubuntu4) robert.ancell might be around in an hour (Sydney time) [20:58] robert_ancell: bug #693737 [20:58] Launchpad bug 693737 in gtk+2.0 (Ubuntu) "gtk+2.0 update 2.23.3-1ubuntu2 update triggers repeated gdm greeter crashes" [Critical,Confirmed] https://launchpad.net/bugs/693737 [20:59] SpamapS: I still don't think we should be second-guessing other conditions that cause portmap to fail to start until we actually encounter one [21:00] sladen, aha excellent [21:00] slangasek: 100% agree, lets not put start in the loop. But does it make sense that it should give up after a while? [21:01] slangasek: essentially.. I'd rather move on to a failure because nfs can't be mounted than wait indefinitely for portmap and give users no clue as to what is going on. [21:01] SpamapS: oh, I don't know. Any filesystems waiting on statd won't mount without it anyway, so I'm not sure it gains us anything [21:01] right [21:02] but how do you calculate how long is too long? [21:02] slangasek: waiting forever means never triggering filesystem [21:02] slangasek: I am reviewing portmap's code now.. its been carefully written not to depend on much.. so probably "not very long" [21:05] still, it's a function of the system speed and of how much else might be running in parallel [21:05] I don't have a good way to calculate a worst-case timeout for this [21:06] Well if all it does is exec, and listen.. then even the busiest booting system shouldn't take longer than 5s to pull that off. [21:07] if you say so :) [21:07] I don't feel strongly enough about it, really; we're obviously well into "that's not event-driven" territory [21:07] I don't want to guess about it either. [21:08] slangasek: indeed :( [21:12] sladen, I'm not getting the gdm bug, but the last commit in git looks like it might be a good candidate for fixing the applets. Building with that now [21:13] robert_ancell: I can reproduce it here and can test things for the next ~3-4 hours [21:14] sladen, thanks [21:20] slangasek: even more fun, portmap forks then listens .. so there's nothing we can do to completely avoid the race. :-P [21:20] SpamapS: hngh [21:20] SpamapS: we can fix portmap? [21:22] slangasek: s/nothing/nothing simple/ [21:22] right :) [21:23] so I'd say just spin for 3 seconds. There is code in portmap that would cause blocking, but none of it is built into the ubuntu or debian portmaps. [21:23] It doesn't lookup hostname, or username, or anything. With our without the fork/listen race.. that window is really, really tiny. [21:24] s/our/or/ [21:24] hi all. I used https://wiki.ubuntu.com/Testing/EnableProposed to work around https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/672352 , but the same procedure fails on a user's machine for some reason (config looks good but aptitude doesn't show the package version from -proposed). When is this likely to move from proposed to maverick ? [21:24] Ubuntu bug 672352 in eglibc (Ubuntu Maverick) "Assertion `_rtld_global_ro._dl_pagesize != 0' failed" [Undecided,Fix released] [21:37] slangasek, SpamapS: so it'd be good to know when you're done what I need to change to make this much easier ;-) [21:39] Keybuk: fixing 'start' to block when the job is already starting would help, of course; there does seem to be a general problem of processes that fork() before listen() not being properly trackable; oh, and fix 'and' :) [21:41] SpamapS: btw, bug #525154 was the existing bug on nfs-utils for tracking this; can you merge those other bugs over? [21:41] Launchpad bug 525154 in nfs-utils (Ubuntu) "mountall for /var races with rpc.statd" [Undecided,Triaged] https://launchpad.net/bugs/525154 [21:45] slangasek: right, ideally you'd want Upstart to not say it was started until it was listening [21:46] though if it's got a fixed socket, would it not be easier to support socket activation for that case? [21:46]