=== freeflying_away is now known as freeflying [01:06] tomreyn: making 64-bit the default has been proposed many times. i thought it might happen this cycle... guess it didn't [01:14] hallyn: the cycle's not over yet [01:16] i remember there were limitations regarding 64-bit releases in the past, as mentioned on the release notes [01:16] but maybe those could just be shifted if maintaining stuff for both archs involves too much effort [01:17] i bet people looked into this already... [01:18] I think it's more to do with end-user confusion and success-rates for not knowing much about their computer when they download something to burn to disc. [01:21] slangasek: here's hopin' :) === _salem is now known as salem_ === salem_ is now known as _salem === Ghoul__ is now known as \t === \t is now known as Guest88757 === Guest88757 is now known as Ghoul_ [05:35] Good morning [06:59] good morning [07:00] morning [07:00] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mlankhorst [07:05] * dholbach hugs mlankhorst [07:45] jdstrand: apparmor's Vcs-Bzr: is 6 versions behind, are we not using this any more? [07:47] jdstrand: I'm about to do an upload for bug 1227520, so I'll just use the UDD branch [07:47] bug 1227520 in apparmor (Ubuntu) "Timezone changes are not working due to ro /etc and bind mounts" [High,In progress] https://launchpad.net/bugs/1227520 [07:49] doko_: good morning, how are you? [07:49] doko_: does the patch in bug 1233185 look okay to you? [07:49] bug 1233185 in gdb (Ubuntu) "gdb-multiarch cannot read ARM cores: "wrong size gregset struct in core file"" [Undecided,New] https://launchpad.net/bugs/1233185 [07:52] pitti: That looks sane, except that it might be nice to see what "all" evaluates to currently, to see if you're leaving anything out. [07:54] cjwatson, classmate-tools ? [07:54] i wasnt aware thats still in the archive [07:58] pitti: Either way, regressing for some random arch we don't ship in favour of fixing things on ARM seems a safe option for today. === psivaa-afk is now known as psivaa [08:00] infinity: I'll have a look how I can find out what "all" does; hopefully it's just some kind of static macro that will get expanded in config.h or so [08:04] pitti: Looks like it ends up with ALL_64_TARGET_OBS + ALL_TARGET_OBS = \ [08:04] pitti: From gdb/Makefile.in [08:04] pitti: But then I'm not sure why ARM wouldn't work, as arm-linux is in there. [08:07] infinity: but maybe not arm-linux-gnueabihf/arm-linux-gnueabi ? [08:08] pitti: Not sure gdb has such a distinction there. [08:12] pitti: All the same objects included in 'arm*-*-linux*)' in configure.tgt are also included in ALL_TARGET_OBS, so it's a bit confusing why this change would work. [08:13] pitti: Unless what's actually happening is that including some OTHER targets (like arm-symbian, etc) ends up breaking arm-linux. [08:13] infinity: I don't know, I'm afraid; I bisected it down from "broken since precise" to that change, but I have no idea how gdb works internally or what that "wrong size of gregset" thingy wants to tell me :( [08:13] pitti: Anyhow, disabling a bunch of targets we don't deeply care about seems like the path of least resistence for now, until someone can unwind this further. [08:14] infinity: ah, so now one could bisect the targets to see whether/which one breaks arm-linux, or whether something with "all" is broken in general? [08:15] pitti: Yeah. My hunch is that if you keep adding new arm* targets (armbsd, arm-symbian, etc), you'll find that one of them blows up your arm-linux support. [08:15] pitti: And then maybe we could just patch that target out of all in Makefile.in [08:15] pitti: But, like I said, I doubt anyone deeply cares about debugging Solaris binaries on Ubuntu and, since they couldn't do so in precise either, meh. [08:16] pitti: Your fix should work for now, and an upstream and/or Debian bug on the matter should probably happen. [08:16] infinity: right, I was going to forward it to Debian [08:16] * pitti uploads for now [08:22] pitti: Can you do me a favour and copy and paste the above conversation into the bug, so context doesn't get lost the next time someone wants to look into it? [08:22] I need to pretend I'm sleeping. [08:22] infinity: yes, I will [08:22] infinity: so, good night! [08:23] pitti: Oh, and rejecting. Please add aarch64 to your static list. [08:24] pitti: We should probably at least support all the arches in the archive, after all. :) [08:24] infinity: I guess that's not the literal value? [08:24] ack [08:25] * pitti still has trouble grepping for what "all" does, even greppign for "arm-linux" is rather unhelpful [08:25] 'aarch64*-*-linux*)' is the case. aarch64-linux-gnu should work. [08:25] infinity: thanks; doing a test build with that, and reuploading [08:27] pitti: Grepping your build log for aarch64-linux-tdep.o should probably show if it's being built and linked in. [08:27] infinity: still, I want to test it; it might be that aarch64 is the very thing that breaks armhf, after all [08:27] pitti: Could be. That would be a shame. [08:28] But indeed not implausible, if aarch64 was a cargo-cult from arm, and linking both arm.o and aarch64.o ends up overloading some rather useful symbol. [08:34] infinity: *phew*, build with aarch64 still works [08:34] pitti: I was almost hoping it wouldn't, as we would have found our culprit. :P [08:34] pitti: But yay. [08:34] uploaded [08:34] submitted to Debian [08:38] Tempted to say we probably want to update to 7.6.1 too, but it might be a bit late to validate that. [08:38] It looks like almost entirely bugfixes, some of which looks nice. [08:38] Actually, no almost about it, it's nothing but bugfixes. [08:39] Maybe I'll mull that over in the morniing. [08:39] But I see no mention of your bug, so it's probably still an issue. [08:39] infinity: you could keep it in -proposed for a few days and send a call for testing? [08:42] pitti: https://sourceware.org/bugzilla/show_bug.cgi?id=15415 in particular is a bug that drives me batty and is fixed in 7.6.1 [08:42] sourceware.org bug 15415 in gdb "gdb resolves symbolic links when passing argv[0]" [Normal,Resolved: fixed] [08:42] pitti: Yeah, I'll give some thought to an update tomorrow. And ping you to test a build with and without 'all' for curiosity, though I expect it to be broken still. [08:44] ogra_: Generally when something is broken I prefer fixing it over arguing whether it should still be there. The latter can be done separately. :-) [08:47] cjwatson, yeah, i just wasnt aware it is still there :) [08:48] i'll file a removal bug [08:48] hey, supposedly there is a bug somewhere around mounting nfs on boot that affects 12.04, what would be the best way to try to debug that? [08:49] I use a few nfs mounts on my box, including /home and a few with bootwait [08:50] my boot success rate is about 30%, the rest fails on one of the remote volumes not mounting (and basically hanging the box on plymouth) [08:50] zyga: and you are not hitting bug #1217041 ? [08:50] bug 1217041 in initramfs-tools (Ubuntu Saucy) "initramfs-tools: please include separated nfs modules" [Undecided,Fix released] https://launchpad.net/bugs/1217041 [08:50] looking [08:50] zyga: ah, if you do succeed it's probably not that. [08:50] xnox: no, I'm on 3.2 here [08:51] xnox: I found too many issues with backported kernels overall and I've decided to stick with 3.2 [08:51] zyga: in that case mountall debug output would be useful. In saucy it's as easy as booting with "--debug" in the kernel cmdline, but in precise you need to modify mountall.conf job to add "--debug" [08:52] so generally, i have a freenas box with a bunch of nfs shares and a 12.04 desktop wired together, the network is flawless, no packet loss or anything, networking is via network manager (but I tried with static for the same effect) [08:52] xnox: ok, let me try that [08:55] xnox: if I get a hang, what can I do to look at logs or just poke around? [08:55] xnox: I recall M or S used to work but I don't see those anymore (maybe it's just not displayed) [08:56] zyga: those key-combos should work. pressing Esc should show boot messages (or boot without quiet). Plus will you have a local /var available? in that case logs will be saved in /var/log/upstart/mountall.log. [08:56] ok, it seems like it has hanged again, I see (after hitting esc on the early boot screen) [08:56] local 2/2 remote 0/3 virtual 11/11 swap 0/0 [08:57] xnox: could it be a bug in my nfs setup? like /home/ and /home/zyga/source being both mounted in the wrong order/causing stalls === ejat- is now known as ejat [08:57] xnox: note, I cannot use either M or S to jump to any console, [08:58] zyga: stgraber recently had a problem, how does your fstab look like? [08:58] xnox: yeah, /var is local [08:58] xnox: I'll try to pastebin it in a sec, I cannot tell from memory [08:58] zyga: stgraber did a bind-mount by UUID, instead of proper LVM names. [08:59] xnox: also the output from mountall/upstart is very confusing -- I see 'mount /home [495] zakńczone normalnie' (finished normally), then, 'mounted event handled for /home' but then, confusingly 'local 2/2 remote 0/3 ...' (as if nothing remote was mounted yet) [08:59] xnox: I don't use LVM here, just a small SSD with large nfs mounts === brainwash_ is now known as brainwash === d1b_ is now known as d1b [09:03] so still hanged, no way to get to a shell, should I just reboot? [09:07] xnox: fstab http://paste.ubuntu.com/6178860/ [09:07] xnox: no mountall logs as far as I can see [09:08] xnox: modified mountall.conf http://paste.ubuntu.com/6178865/ [09:10] zyga: i usually do without "--daemon" to get logs. [09:10] ah, ok [09:11] xnox: should I also remove 'expect daemon' theh? [09:13] zyga: yes. [09:14] ok, trying again [09:18] xnox: rebooted ok, no mountall logs in /var/log/upstart [09:19] =/ hm. [09:20] http://paste.ubuntu.com/6178893/ mountall.conf just to be sure [09:34] zyga: try changing /etc/init/tty6.conf to specify 'start on startup' so that you can login to a shell. I wonder if mountall is crashing (ls /var/crash/? ) [09:37] jodh: thanks, worth checking! [09:40] * zyga reboots to try again [09:41] ok, given the tty now, I'll reboot till it hangs [09:42] jodh: so mountall isn't crashing [09:43] I'm in a shell now, with the boot hanged as before [09:43] network is up and working [09:43] http://pastebin.com/f5xxu3Xu [09:43] that's ps aux [09:44] zyga: Still no mountall.log? What does /var/log/boot.log show? [09:45] jodh: no mountall.log, nope [09:45] zyga: ah - you need to change mountall.conf to include "console log". [09:45] jodh: doh :) right, I'll patch that [09:45] quick question, how can I change early boot to english so that everyone can read it? [09:45] jodh: boot.log http://pastebin.com/tkMD5qxz [09:46] ok, rebooting [09:47] * zyga thinks of a magic key sequence that starts tty6 [09:47] jodh: ^^ :) [09:48] ok, stuck again [09:48] inspecting logs [09:49] jodh: so _no_ mountall logs again, no idea why though [09:49] mountall is _not_ running [09:50] jodh: initctl list -> http://paste.ubuntu.com/6178962 [09:50] note that I have my pastebin conf and that home has mounted [09:50] I actually wonder why it is stuck, it seems _everything_ is mounted now [09:51] mount -> http://paste.ubuntu.com/6178964 [09:54] xnox, jodh, any idea on why it's not proceeding now? I'm looking at initctl list and I have no idea what might be wrong === freeflying is now known as freeflying_away [09:57] jodh: having commented out 'expect daemon' from /etc/init/mountall.conf, and removed '--daemon' from 'script' below, should that job work okay? [09:57] jodh: I just noticed that mountall.conf has 'console output' already with a funny comment above ti [09:58] jodh: my console log was _above_ the pre-existing console output so we probably didn't get any logs because of that [09:58] zyga: do you get logs without "console output" [09:58] xnox: checking now, I'll reboot again [09:58] * xnox should check how i used to get logs from mountall [09:58] (it's quite interesting why the failure rate is now 100%) [09:58] rebooting [09:58] xnox: I think we'll get logs now [09:59] * zyga would like to switch to platform team for a cycle and work on mir early boot and upstart-and-friends verbose development boot monitoring support [09:59] xnox: mountall.log \o/ [10:00] mountall.log <- http://pastbin.com/F7tBU1mi [10:00] (note, I type-copy each pastebin URL, if they don't work please tell me) [10:01] zyga: that pb doesn't work for me. [10:02] http://pastebin.con/RzNZHRz1 [10:02] jodh: I think I made a typo in pastebin.com above (forgot one 'e'), this is a fresh one now [10:02] http://pastebin.com/RzNZHRz1 [10:03] how do I switch locale to C.UTF-8 or something like that? [10:03] zyga: that seems to show everything is ok. [10:03] xnox: so indeed I have all the things mounted [10:03] xnox: but ... no desktop [10:03] xnox: fallback graphics is curious [10:03] well then =) [10:03] could it be the case [10:03] that fallback graphics kicks in somehow [10:03] (because of nfs boot delay) [10:03] and somehow stops my normally working graphics? [10:04] * xnox installed nvidia by accident (i have intel) and that breaks dekstop / lightdm. Also installing ubuntu-touch / surface-flinger breaks things. [10:04] udev-fallback-graphics.log is full of vesafb insertion errors [10:04] xnox: I don't have those installed here [10:05] zyga: anything interesting in lightdm logs? [10:05] I've adde manual to fallback grapics [10:06] xnox: aww, I just rebooted, IIRC lightdm didn't start though [10:06] xnox: (I moved all old logs aside and i dind't see any lightdm logs this time) [10:06] zyga: they are under /var/log/lighdm/* [10:06] ah [10:06] *lightdm [10:07] ok, cleared logs and trying again [10:07] and it does hang each time now [10:07] I wonder if I made it worse [10:07] or are we just lucky for debugging [10:08] xnox: lightdm doesn't start at all, no logs [10:09] xnox: upstart/plymount-ready-startup.log has just one line "Terminated" [10:10] jodh: so why does mountall.log claim that remote 0/3 is mounted: I have many more filesystems _and_ they are mounted [10:11] zyga: well at the end it claims "local 2/2 remote 2/3 virtual 11/11 swap 0/0" [10:11] xnox: now it claims 0/3 [10:11] if that's a full pastebin that is, and there is nothing that was after. [10:11] hm [10:12] I keep rebooting after changing something to see if it helps [10:12] zyga: can you remove "--verbose" from mountall.conf as it's overriding "--debug" I think. [10:12] xnox: http://pastebin.com/W3BxKFSY [10:12] jodh: ok [10:13] rebooting [10:13] * zyga wants to rewrite mountall into rust/go/python [10:14] C is great but after a few years in python C feels like middle ages :/ [10:14] jodh: http://pastebin.con/iuv4XtEv [10:14] zyga: *shrug* all of those are too heavy and too big that early in the boot process. [10:15] xnox: heavy? big? [10:15] xnox: python, yeah, rust/go [10:15] zyga: and with libnih, C looks quite neat. [10:15] xnox: and python would be easier to maintain probably (if having access to all glibc stuff wasn't a probleM) [10:15] anyway [10:15] xnox: true [10:15] xnox: libnih is very nice [10:15] hey, note that I seem to randomly get pastebin.com pastebin.ubuntu.com, it's still a random mount or not here [10:16] zyga: looks like you fstab is invalid - you have specified "1" the fsck field for /home/zyga/source, but "1" is reserved for the root FS. Change it to "2" (or "0" like the rest). [10:16] and it's mounted now (/home) [10:16] oh [10:16] cool [10:16] jodh: fixed, trying again [10:16] what are the last two fields for? [10:16] dump and pass [10:17] (I used 0 this time) [10:17] zyga: man fstab [10:17] ah [10:17] ok, same result [10:17] zyga: last pb also invalid [10:18] jodh: com not con, it should work, sorry [10:18] jodh: [10:18] \o/ desktop up, after a slight delay [10:18] let's retry [10:18] zyga: try commenting out the nfs entries in fstab starting with /home/zyga/source to see if they are causing the problem. [10:20] jodh: ok, rebooting, commented out 'source' and switched locale to C.UTF-8 [10:20] jodh: could the wrong value of pass cause the problem? [10:21] mountall.log (nothing mounted yet) pastebin.com/rmsTYkf1 [10:22] jodh: desktop up, everyting got mounted [10:22] jodh: mountall.log just a moment later, pastebin.com/q21qQrbW === doko_ is now known as doko [10:23] pitti: any opinion on an FFe for subversion for bug 1209493? This is to enable libapache2-svn again after it got dropped from the Apache 2.4 transition. It just got an NMU upload to DELAYED/5 to Debian and the diff looks sensible (presumably we'd want to wait for it to land first, certainly). [10:23] bug 1209493 in subversion (Ubuntu) "libapache2-svn missing in saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1209493 [10:23] rebooting, I'll keep trying to see if I can hang it [10:23] Some days I hate optipng [10:24] rbasak: sounds good to me (although please note that I don't have formal u-release powerrs) [10:24] pitti: understood. Thanks! [10:24] rbasak: but it was obviously a temporary dropping of the package, so bringing it back seems right if it builds now [10:25] Perhaps I misunderstand what we do with optipng, but where it is effective, can we send the optimised png back upstream? And then perhaps keep a list of hashes for pngs that we already know are optimised. [10:26] zyga: great. Please can you raise a bug on this (with details of when this stopped working if possible). [10:26] jodh: hmm, wait, I'm not yet sure what the problem is, I can only report that I had a problem and commenting out that nfs share (and fixing pass value on it) made it go away [10:27] pitti, I'm fine with it. I think that was introduced by lool some time ago. but then we need aarch64-linux-gnu too in this list [10:27] jodh: let me reboot a number of times again to check if it's the same [10:27] doko: yes, infinity already brought that up, and I added it [10:27] jodh: also, I'd like to get that share back there, I mean, if it's the root cause the I can manage but I don't know that yet [10:27] doko: thanks [10:28] zyga: that's prolly enough for now if we can recreate the bug with a setup similar to yours. When did this problem first start? Has a recent update caused the breakage? [10:29] jodh: no, it was bugging me ever since I started using nfs about a year ago [10:29] jodh: I was just not rebooting [10:29] jodh: I didn't have 'bootwait' before [10:29] jodh: and I manually started mounting after (rare) reboots [10:29] jodh: the only thing I made now (recently) was to put /home on nfs [10:29] jodh: but that's the equivalent of bootwait [10:29] jodh: and I had that for a while earlier after reading mountall to find out about it (I don't think it is documented) [10:32] * zyga thinks he spoke too soon, rebooted, it seems to have hanged (no changes made) [10:33] http://paste.ubuntu.com/6179062 [10:33] yup, stuck [10:40] zyga: upstart appends to its logs files. would be clearer if rotate/delete the existing files each boot. [10:41] jodh: ah, true, thanks [10:41] zyga: unclear what the problem is atm, but please raise the bug as slangasek is the nfs guru. [10:41] ok [10:42] thanks for the help jodh, xnox! [10:46] jodh: on mountall? [10:47] zyga: nfs and mountall =) [10:47] zyga: bug against mountall. [11:06] jodh: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1233610 [11:06] Ubuntu bug 1233610 in mountall (Ubuntu) "boot process hangs very often when NFS shares are used" [Undecided,New] [11:06] jodh: does that look good? === MacSlow is now known as MacSlow|lunch [11:10] pitti: it is used, we are just horrible at keeping it up to date. I saw the change, we'll update the branch [11:16] If a package provides a daemon, would it be considered a requirement that the daemon is listening (in this case on a Unix socket) when the package postinst finishes? I have a race with another package that depends on this, and it seems that the daemon is taking a little while longer to start up. [11:17] rbasak: well, does it have an upstart job? [11:17] I don't know about a requirement but I would consider it good software engineering. I suggest that you fix the upstart job to wait properly [11:17] (You might find "expect stop" useful) [11:17] This is libvirt-bin starting libvirtd. It does have an upstart job. [11:18] I'm not sure how to amend the upstart job though. I think it's waiting until the daemon forks, so upstart considers it "started". [11:18] Like I say, "expect stop" is handy [11:18] I'm patching libvirt with a sleep to test that hypothesis now, as it's a bit tricky to reproduce [11:18] You need to arrange to run without forking to use that, but it lets you cause upstart to consider the job started at the exact point of your choosing [11:19] With a patch to the daemon, typically, but a trivial one [11:19] Ah - I see. So the daemon needs to send SIGSTOP to pid 1? [11:19] No [11:19] The daemon needs to send SIGSTOP to itself [11:20] Pid 1 will send it SIGCONT once it's noticed [11:20] I get it - thanks. This would be an Ubuntu-only patch, then? [11:20] It's fairly crude, but effective :) [11:20] Could be pushed to Debian [11:20] This is of course assuming there isn't some other way, but if it doesn't listen until after it daemonises ... [11:21] Wouldn't it break the daemon using another init system? I guess I'd need a command line option to enable that. Would you consider such an option mandatory for an Ubuntu patch? [11:24] rbasak: you can check if there is UPSTART_JOB in the environment ;-) [11:24] xnox: that feels even worse! :) [11:24] Thanks for the discussion. I'm investigating the code in more detail now. [11:25] jodh: shouldn't upstar texport UPSTART_EXPECTS_STOP in the environment, when launching expect stop jobs? [11:31] It looks like there's code in libvirtd to not exit the foreground (pre-fork) process until the second child has start listening on the socket. But my understanding of upstart's docs is that it waits for the second fork only with "expect daemon". So I guess I need a script stanza that does daemonize but then kill -STOP $$ or something instead of an exec, and then "expect stop" instead? [11:35] Hmm. But then upstart won't be tracking the correct pid. [11:57] rbasak: I used an environment variable when I did this in openssh [11:58] * rbasak looks [11:59] rbasak: It's not in the archive yet, but http://anonscm.debian.org/loggerhead/pkg-ssh/openssh/trunk/revision/3578 [12:00] sshd's upstart job already arranges not to fork [12:00] not on startup anyway [12:00] rbasak: with the code in libvirtd you describe, maybe "expect daemon" is all you need [12:01] rbasak: that pattern isn't a totally unusual one, and should be manageable; "expect stop" is for when the daemonising isn't quite lined up with "ready to operate" [12:02] cjwatson: thanks. I'll use that as a model. libvirt-bin already uses "expect daemon". I think the problem is that on the fork itself, we aren't at "ready to operate". The code signals instead by the first process exiting. But I think that upstart uses the second fork instead of additionally wait()ing on the top level process. [12:02] Would there be any harm if upstart also waited on the top level process for "expect daemon" or "expect fork"? [12:10] slangasek: ping? [12:17] mvo, if you have some time, i'd appreciate thoughts on bug 1233486 [12:17] bug 1233486 in software-properties (Ubuntu) "add support for 'cloud-archive:' like 'ppa:' but for cloud archive" [Undecided,New] https://launchpad.net/bugs/1233486 [12:18] if there is someone more appropriate to request from let me know that too [12:18] smoser: sure, I should find some time to look at this today - btw, what ever happended to the by-hash requirement for apt? is this still a issue or was this solved in a different way? [12:19] its still an issue. [12:19] rbasak, has just not gotten around to fixing it. [12:19] i think the biggest reason that it becaame much less problematic was that canonical IS changed a setting in the mirrors that made squid happier. [12:19] but i dont recall the details of that. [12:20] I would still like to fix it. But I find working on apt very time consuming, needing me to disappear in a corner for a week at a time, and I haven't had time to do that recently :( [12:20] That part of apt's source is very spaghetti-like. [12:21] rbasak, be nice :) [12:24] I've filed bug 1228210. [12:24] bug 1228210 in uvtool "libvirt-bin upstart job considers service "started" before it is ready" [High,New] https://launchpad.net/bugs/1228210 [12:25] I've written up everything I know right now and I'd appreciate comment. [12:26] rbasak, smoser thanks for the update and yes, its unfortunately relatively ugly code that deals with that part in apt [12:28] mvo: yeah it's unfortunate. I don't mean to criticise anyone specifically there - it's quite obvious how it's come about - a pile of needed features (security, compression, etc) without anybody having the time to refactor it. [12:33] rbasak, i knew you weren't *actually* being mean, and i think mvo did too. [12:33] yeah, no worries :) [12:34] Phew :) [12:48] Can someone accept mesa, xorg-server and glamor-egl? A few bugs popped up after the introduction of egl and after some testing I believe those are fixed now with the uploads. :) === freeflying_away is now known as freeflying === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [13:30] zequence-work, ping, do you have upload rights for ubuntu-studio packages? [13:32] diwic, zequence-work and OvenWerks are trying to get upload rights, but they currently don't. [13:32] ok [14:10] diwic: i did a few uploads for ubuntu-studio lately. what's up? [14:13] slangasek: Could you please merge multistrap to make pdebuild-cross installable in saucy? [14:13] xnox, wanna sponsor a ftbfs ? [14:14] diwic: do you have URL? [14:14] diwic: Wouldn't sponsoring something that builds be better? :) [14:15] xnox, http://pad.lv/1233685 [14:15] Launchpad bug 1233685 in ardour (Ubuntu) "Ardour FTBFS on saucy" [Undecided,New] [14:15] infinity, nah, I don't think you have enough work already. :-) === hatch_ is now known as hatch [14:18] bigon,kenvandine,dholbach: Is there any point in keeping the meta-telepathy source package in the archive? It has never been in Debian, has no reverse dependencies, seems to attract bugs that should live somewhere else, and apparently telepathy-devel-gtk has been uninstallable since lucid without anyone noticing or caring [14:18] xnox, hold it [14:19] xnox, actually, it still fails, when you start it. *facepalm* [14:19] cjwatson, no, very likely not - I don't know anyone using it - it stems from a time when the telepathy stack was just a 5-10 not-very well interconnected pieces of software [14:19] cjwatson, shall I file a bug for that? [14:19] Please [14:20] * kenvandine agrees [14:20] i forgot it even existed [14:21] cjwatson, bug 1233702 [14:21] bug 1233702 in meta-telepathy (Ubuntu) "Please remove meta-telepathy from the archive" [Undecided,New] https://launchpad.net/bugs/1233702 [14:21] thanks for bringing it up [14:21] cjwatson: +1 [14:24] removed, thanks [14:25] great [14:35] xnox, ok, so the ardour interface seems to start as it should. So probably an improvement after all, compared to not building at all. But there are more linker failures to sort out too... [14:56] zyga: hi, so what's the symptom you're experiencing with nfs? [14:56] cjwatson: ack [15:02] slangasek: hey [15:02] slangasek: I've tried to do my best to describe it in a bug report, let me pull it up [15:04] slangasek: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1233610 [15:04] Ubuntu bug 1233610 in mountall (Ubuntu) "boot process hangs very often when NFS shares are used" [Undecided,New] === kentb-out is now known as kentb === freeflying is now known as freeflying_away === hatch_ is now known as hatch === freeflying_away is now known as freeflying [15:40] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:40] bb === sraue_ is now known as sraue [16:02] xnox: more useful than a /var/log/mountall.log from a successful boot would be one from a failed boot... [16:02] er, sorry [16:02] zyga: more useful than a /var/log/mountall.log from a successful boot would be one from a failed boot... [16:12] doko, any chance you could do the honours on bug 1213915 [16:12] bug 1213915 in ceph (Ubuntu Saucy) "Please demote ceph-mds and ceph-fs-common to universe" [High,New] https://launchpad.net/bugs/1213915 [16:32] xnox: do you know of a bug or blueprint to track EXITED in upstart, please? If not, should I add a wishlist bug for that? I figure that if something is planned then a minimal workaround in the meantime would be best, which in this case could be a simple wait-for-the-socket in uvtool-libvirt.postinst. [16:33] slangasek: I'll provide one to the same bug report as soon as I can, we have an important release today [16:42] rbasak: combination of https://bugs.launchpad.net/upstart/+bug/530779 and https://bugs.launchpad.net/upstart/+bug/406397 [16:42] Ubuntu bug 530779 in upstart (Ubuntu Precise) "init: does not wait for parent to exit when following forks" [Medium,Triaged] [16:42] Ubuntu bug 406397 in upstart "init: job stuck with expect fork/daemon when parent reaps child" [Medium,Triaged] [16:43] slangasek: what's the new mechanism that keybuk keeps on talking in those bug reports? This - http://netsplit.com/2011/02/09/the-proc-connector-and-socket-filters/ ? [16:45] xnox: thanks! [16:45] xnox: the proc connector is a netlink facility, but it doesn't work in containers. [16:46] jodh: i'm not sure what netlink is, and define containers - doesn't work in lxc? [16:46] xnox: you mean "proc connector"? It's... proc connector :) [16:47] xnox: kernel socket thing. yes, it fails in lxc. [16:47] fails in lxc> boo [16:47] even with user namespaces? [16:48] slangasek: haven't tried that. [16:48] well, they're fairly new AIUI [16:49] slangasek: well keybuk in those bugs doesn't say that he was planning to use "proc connector", only some random commenter said that. [16:50] xnox: https://lists.ubuntu.com/archives/upstart-devel/2011-August/001707.html === mitya57_ is now known as mitya57 [16:52] jodh: ah, thanks. That's from before my time =) [16:56] jodh: `* Introduce "expect exit " syntax.' sounds highly unreliable, if there is a variable amount of exits. [16:56] xnox: ah, misread your original question and didn't look at the bugs, sorry. Yes, I think proc connector was his long-term vision for fixing this problem [16:57] xnox, jodh: yeah, I don't like 'expect exit '. People can fix their code to daemonize sensibly, or not at all + SIGSTOP. [16:58] xnox: the link was primarily for you wrt the proc connector; we're not now planning to implement 'expect exit' :) [16:58] slangasek: ack === bfiller is now known as bfiller_afk [17:08] slangasek: with respect to tracking exits, we'd need to build a tree of all forked processes (and forks of thereof) and monitor both FORK and EXIT and mark off in the the tree those that exited, and then what? -> for expect fork, take the first fork that is still running after the parent has exited? -> for expect daemon, take the first double fork that is still running after the parent has exited? and if there are no such declare defeat. [17:11] xnox: I don't think you actually need a tree; you just track parent + child, and if the child exits before the parent, you scratch that pid off the list and wait for the next child [17:11] yay, lots of autopkgtest failures due to uninstallable X on amd64 [17:11] jibel: ^ FYI; can retry tomorrow morning, or if you are still around later tonight, maybe you can [17:11] plars: ^ or you [17:14] slangasek: well, what if the child[2] is the one that ultimately does the double fork? for "expect fork" yeah one can use list(parent, child1, child2, child3) and simply take the first still alive child after parent has exited. [17:14] * xnox somehow thinks for "expect daemon" we need "grand-children" [17:15] pitti: is there a process you normally follow for identifying when it's ready to retry, and which ones to retry? [17:16] xnox: we can assume a daemon has certain characteristics, such as the fact that the "grandparent" doesn't exit until its currently lead child is the one that's going to fork again to give us the daemon [17:16] infinity: you could keep it in -proposed for a few days and send a call for testing?http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html stops spitting out a gazillion xorg packags [17:16] WTF [17:16] infinity: ^ sorry about that, that was an utter paste fail [17:16] xnox: we don't need to support all crazy combinations of fork+exit, only the ones that make sense for a daemon - and for other cases, we just need upstart to not get wedged [17:17] plars: as soon as http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html stops spitting out a gazillion xorg failures [17:17] * pitti waves good night [17:17] hmm, we are down to two amd64 builders, of which one is offline :/ [17:18] rbasak: ah, nice post on upstart-devel, are you the one who triggered this current discussion? ;) [17:18] slangasek: I see, i keep fearing that "leading child" is "pre-warm cache long task" which eventually dies after the parent has exited, with the second child (untracked) which did the double fork. [17:18] slangasek: thanks. Yes. I was chasing a race and wasn't aware of the previous discussion on this. [17:18] * pitti bumps https://launchpad.net/ubuntu/+source/xorg/1:7.7+1ubuntu5/+build/4970241 but it seems it doesn't even get an ETA [17:18] anyway, waaay past my EOD time, cu all [17:18] slangasek: yes, rbasak triggered this irc -> email -> irc discussion. [17:20] xnox: it's possible that such things exist, but I don't see any way to make that work with 'expect daemon' anyway - how is upstart supposed to know that child[1]->grandchild[1][0] is the real daemon, and child[0] is the long task, instead of child[0] being the daemon still starting up and grandchild[1][0] being the task which happens to have double-forked? [17:21] we have to have some assumptions [17:22] I found https://blueprints.launchpad.net/upstart/+spec/return-pid-from-exec when I was googling earlier. Did that prompt any further discussion, and could it be useful for the really obscure cases? [17:22] (as a generic catch-all) [17:22] Effectively allowing complex cases to deal with the required logic themselves [17:45] slangasek: well, in that case doesn't this reduce to: keep tracking forks as we do + track parent (patient0) exit => declare started when we found our fork + patient0 has exited? [17:46] xnox: yes [18:50] pitti: The one that's disabled isn't actually amd64, it's just temporarily faking it so that we still see the amd64 queue length even when all the builders are assigned to i386 to clear the test rebuild queue there faster. [18:51] pitti: I've given amd64 another builder for a bit, but the non-test-rebuild saucy queues are still strongly imbalanced (i386: 75, amd64: 16) so I think 6:2 is about as much towards amd64 as we ought to go for now [18:52] pitti: And the problem isn't the amd64 queue anyway, it's the build failure on i386 ... [18:53] Hmm, unexplained abort in the test suite [18:53] * cjwatson retries it in the hope that it might stick [18:54] pitti: https://launchpad.net/ubuntu/+source/xorg/1:7.7+1ubuntu5/+build/4970241 is arm64, not amd64 [18:54] pitti: arm64 isn't going to build for a while :-) [18:56] pitti: I've scored that back down - it's not appropriate for it to be second in the arm64 queue [18:57]