=== xymox_ is now known as xymox === xymox is now known as xymox_ === xymox_ is now known as xymox === alexlist` is now known as alexlist [00:56] hi [00:56] * adie huggles TingPing [00:58] hi #ubuntu dev people, I have a problem in unity launcher API stuff, and I was wondering if you can help me out :O [00:59] I am trying to set a msg count number in hexchat with python launcher.set_property ('count', count), and it works the first time, but if I reload the script is breaks like this: http://pastebin.com/raw.php?i=eudXgAcG [01:00] I was wondering if there was something I can do to clear out whatever is preventing the script from working upon second launch [01:09] adie: you didn't miss any responses while gone.. [01:09] okay, ty :| [01:24] :< [01:25] adie: still nothing while you were gone. perhaps try in twelve-sixteen hours, more people will be around [01:26] :D maybe [01:26] sorry for quit/join [01:26] have to restart the client to make the script work :D [01:26] ah :) hehe [01:26] adie, if only it were possible to have two clients open at the same time.. hmm [01:31] TingPing, I wouldn't be surprised if this script would interfere with two client instances [01:33] targeting the same external resource [01:33] adie, well you would be wrong [01:33] Isn't that the rule? [01:33] "Adie is always wrong" [01:34] the error has something to do with loading the glib library from the the same python library twice i guess [02:12] adie: #ubuntu-unity might be of some help [02:13] okay === Nisstyre-laptop is now known as Nisstyre === Kk2 is now known as kk2 [05:07] Snow-Man: yes, unfortunately there is no way to ship a logrotate file which works on both < 3.8 and >= 3.8, so during package build we have to create a file for a particular version [05:07] Snow-Man: FYI, unstable will switch to 9.3 as soon as it gets released (beta2 just came out) [05:07] Good morning [05:08] mornin === jamesh_ is now known as jamesh [07:42] hi [07:42] apache2-mpm-worker-dbgsym seems to be uninstallable [07:43] good morning [08:10] https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1196440 [08:10] Launchpad bug 1196440 in apache2 (Ubuntu) "apache2-mpm-worker-dbgsym is uninstallable" [Undecided,New] === doko_ is now known as doko === tkamppeter__ is now known as tkamppeter === oSoMoN__ is now known as oSoMoN === MacSlow is now known as MacSlow|lunch [11:23] cjwatson: ping [11:24] maxoiaojun: just leave your message directly, please [11:25] cjwatson: I believe pad.lv/1035136 is not fixed even on saucy, please try "/usr/lib/lsb/install_initd" if you have saucy box === oSoMoN_ is now known as oSoMoN [11:36] bug #1035136 [11:36] bug 1035136 in lsb (Ubuntu Raring) "install_initd crashed with SyntaxError in __main__: invalid syntax" [Medium,Triaged] https://launchpad.net/bugs/1035136 [11:38] maxoiaojun: I've followed up in the bug. [11:41] thanks, i'm firing a saucy vm [11:42] maxoiaojun: A chroot should be enough. === sraue_ is now known as sraue [12:08] hallyn, stgraber with kernel 3.10 I get the following error when I create an LXC container [12:08] lxc-start 1372673552.852 ERROR lxc_cgroup - Invalid argument - write /sys/fs/cgroup/devices/lxc/saucy-i386-20130701-1012/devices.deny : Invalid argument [12:09] hallyn, stgraber does this kernel requires a config change of the containers? [12:10] I don't see this error with 3.9.0-7 [12:10] a bit confused now [12:10] https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lsb/saucy/files and what installed on saucy box is different? [12:12] maxoiaojun: the new lsb is not in release pocket yet, above imports from release pocket with a propagation delay. [12:13] jibel: no, nothing like that should have changed. [12:14] xnox: but the bzr branch is behind what is actually installed [12:14] hallyn, okay, I'll report a bug [12:15] I ignored the branch [12:15] Also, in any case, the files you're probably talking about are modified in debian/rules [12:15] (Looks like the branch is up to date otherwise) [12:16] maxoiaojun: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lsb/saucy/view/head:/debian/rules [12:16] $(twotothree) -n -w debian/lsb-core/usr/lib/lsb/* [12:17] i see [12:18] Not the way I prefer to do things myself, but whatever [12:20] how about raring and quantal then, I propose that we just change rules so that /usr/lib/usb will continue to use python 2 [12:21] I'd rather we backported the fixes [12:23] because it's all rules magic [12:24] i guess just remove the python => python3 magic for /usr/lib/lsb/ is enough [12:25] https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/lsb/raring-proposed/view/head:/debian/rules#L104 [12:25] Well, whatever. I'm not going to do the work here. But I think it'd be wiser to bring quantal/raring more into line with saucy rather than going backwards, as a general principle of SRUing [12:25] https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/lsb/quantal-proposed/view/head:/debian/rules#L104 [12:26] It's already running 2to3 over things there so it's not that big a change to expand that [12:26] And it would be a more direct backport [12:26] See bug 798192 [12:26] bug 798192 in lsb (Ubuntu) "install_initd fails" [Undecided,Fix released] https://launchpad.net/bugs/798192 [12:27] In fact this bug is a dup of that one, I think [12:30] indeed, but 2to3 is not enough for the scripts in quantal and raring I guess === MacSlow|lunch is now known as MacSlow [12:32] as someone mentioned "sudo sed -i "s/python3/python/" /usr/lib/lsb/install_initd" as a workaround [12:32] maxoiaojun: The bug fixed in 4.1+Debian9ubuntu1 was that 2to3 wasn't run over the proper files. Backport that [12:32] i see using tested python 2 code better than using untested 2to3 generated python 3 code [12:34] I'm concerned about pulling python (2) back into environments where it wasn't needed before; and in general I prefer straight backports of what's in the development release for SRUs, where at all possible [12:35] also testing happens in saucy anyway, if there are bugs, fices can be backported easily [12:35] *fixes [12:35] hallyn, I filed bug 1196518 [12:35] But, as I say, I'm not the one who's going to be doing the work here, so you don't have to persuade me [12:35] bug 1196518 in lxc (Ubuntu) "lxc-start failed with lxc_cgroup - Invalid argument - write /sys/fs/cgroup/devices/lxc//devices.deny : Invalid argument with kernel 3.10" [Undecided,New] https://launchpad.net/bugs/1196518 [12:35] apw, ^ [12:35] diverging further increases maintenance cost as the next fix will have to be written twice.... [12:36] xnox, ++ [12:37] but the python 2 code is well tested by debian i guess === maxoiaojun is now known as maxiaojun [12:37] jibel, oh goodie [12:38] maxiaojun, that doesnt make maintaining two patchesets less work [12:38] -e [12:39] but the lsb package is already in different versions anyway [12:39] you can check the rules file, saucy one is very different from quantal/raring one [12:40] you know, saucy contains lsb4.1-blah while older releases all lsb4.0 [12:42] jibel: thanks [12:44] barry: I see that socket.error is now deprecated: http://www.python.org/dev/peps/pep-3151/ - Is it deprecated, but won't be dropped for a long time because it's widely used or deprecated and I better make sure I don't use it because it's going away soon? [12:45] ScottK: the former, most likely. i wouldn't expect it to go away before 3.5 at the earliest, if ever [12:48] barry: Thanks. [12:55] jibel: LXC appears to work fine here, can you pastebin your container config? === _salem is now known as salem_ === oSoMoN_ is now known as oSoMoN === Sweetsha1k is now known as Sweetshark [13:22] jibel: nevermind, just saw the bug report now [13:32] xnox: ping [13:32] barry: hola =) [13:33] xnox: hi! there's a comment in emacs24 24.3+1-1ubuntu1: - debian/emacsVER.desktop: Also set StartupWMClass for bamf and gnome-shell. have you by any chance seen the icon break for tab completion after this? [13:33] [13:35] https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1035136 branches linked [13:35] Launchpad bug 1035136 in lsb (Ubuntu Raring) "install_initd crashed with SyntaxError in __main__: invalid syntax" [Medium,Triaged] [13:35] barry: define break? after this patch the icon has become a beautiful svg emacs bubble with a fountain pen; before this patch it was an ugly pixalated xmp icon instead. [13:35] barry: what DE do you use? [13:35] xnox: unity [13:36] same [13:36] xnox: i get a nice big question mark on a beautiful gray background [13:36] stgraber, sorry was otp. The setup is a bit special because it uses 2 loop-mounted devices + an overlay [13:36] barry: i can quickly test in a clean / new environment. [13:36] xnox: great, thanks. i see it on two saucy desktops now [13:37] stgraber, but downgrading to 3.9.0-7 clearly fixed the problem and we could dozens of test without any issue. [13:50] barry: all works correctly in a saucy VM. Do you have custom .desktop files? are you launching emac24 or emacs which happens to be update-alternatives launching emacs24? are you starting emacs via upstart or some-such? [13:50] hallyn, i need to link a dir across from the containers /dev to the hosts /dev (there are sockets the binary android blobs create) ... i used to use a link from /dev/socket into /proc/$lxc_pid/root/dev/socket but seems a normal user cant access that, any idea how to do that more elegant and with permission for normal users ? [13:51] xnox: launching emacs via gnome do. i wonder if that would matter [13:51] xnox: nope [13:52] barry: emacs (symlink) or emacs24 ? can you type "emacs24" in gnome-do? [13:52] xnox: so i see the right icon in both the hud when i use the launcher to start it, and in gnome do when i use that to start it [13:52] xnox: but either of those, and starting from the shell, all give me broken icons [13:53] weird. no idea. [13:53] dang [13:53] not that it's a huge deal of course === wedgwood_away is now known as wedgwood [14:02] xnox, jodh there is a regression in upstart 1.8-0ubuntu1.1 in Raring and bug exists in Saucy (bug 1124384 and bug 1195955) [14:02] bug 1124384 in cloud-init (Ubuntu Saucy) "Configuration reload clears event that others jobs may be waiting on" [High,Confirmed] https://launchpad.net/bugs/1124384 [14:02] bug 1195955 in upstart (Ubuntu) "Setting up upstart (1.8-0ubuntu1.1) ... dpkg: error: unknown option --compare-version" [Undecided,Confirmed] https://launchpad.net/bugs/1195955 [14:03] ogra_: well you should be able to get around the permission issue by doing a bind mount instead of a link [14:03] ogra_: probably the more robust way would be to use mounts propagation to cause the contaienr's / or /dev to be mounted someplace where the host can see it [14:04] ogra_: is the container's /dev a static dir, or a tmpfs? [14:05] jibel: yeah, looks like a typo from the last uploader [14:05] hallyn, android uses a tmpfs for /dev [14:05] and we hold our boot until thats propagated [14:06] ogra_: what do you mean by propagated? [14:06] populated, or are you actually propagating the mount already? [14:06] hallyn: IIRC you can't bind-mount /proc//root/ (or at least it wouldn't let me do that the last time I tried) [14:07] jibel: that's mine. [14:07] hallyn, like ubuntu has udev, android uses ueventd to propagate the tmpfs /dev [14:07] stgraber, right, i had the samme issue, thus the link [14:08] which worked fine until rsalveti came around :P [14:08] (trying to access it as normal user) [14:08] ogra_: btw, you mean "populate" not "propagate" :) [14:08] errr, yeah [14:09] ogra_: ok, i think you should make the container's rootfs --make-rshared [14:09] what does that chare and how ? [14:09] *share === a16g_ is now known as ypwong [14:09] set lxc.rootfs.mount to /container/rootfs in the container config, [14:10] hallyn: won't help much as the final setup (once we're fully flipped and loop-mounted) uses a tmpfs rootfs mounted from the container ns [14:10] we want the container to stay haf way safe ... [14:10] and on the host do mount --bind /container/rootfs /container/rootfs; mount --make-rshared /container/rootfs [14:10] hallyn: so the rootfs isn't visible outside of the container mountns [14:10] stgraber: I think I might need a pic :) [14:11] hallyn: basically /var/lib/lxc/android/rootfs is empty (or in ogra's case doesn't even exist), at boot time we have a pre-start which mounts a tmpfs on top, then unpack a cpio initrd, then does a bunch of stuff and finally boots that as rootfs [14:11] stgraber: that shouldn't matter [14:12] stgraber: so long as you make lxc.rootfs.mount = /container/rootfs, then the actualy rootfs that you pivot-root into will be /container/rootfs [14:12] hallyn: but as all of this happens in pre-start, we're already in the container mountns so the rootfs isn't visible from the host, which means that if we were to use rshared, we still wouldn't be able to see it [14:12] and if you make that rshared, then the mounts from the child container should be reflected on the host [14:12] stgraber: the rootfs you're building isn't visibile in the host, [14:12] but when you mount that onto /container/rootfs to pivot-root to it, you should see that on the host [14:13] * ogra_ thinks he slowly gets it [14:13] i coudl be wrong, as this is being held together by duct tape, but that's what I"d expect :) [14:13] ah, let me try that [14:13] (duct tape == bind mounts :) [14:13] :) [14:13] cool. meanwhile i've got someone telling me they can't provide apport info bc the bug is happening on fedora. === oSoMoN_ is now known as oSoMoN [14:21] hallyn, so adding "lxc.rootfs.mount = /var/lib/lxc/android/rootfs" .... makes the container sigsev [14:22] nothing further in the logs [14:25] (or did you mmean literally /container/rootfs ?) [14:25] ogra_: yeah :) [14:25] doesnt work either [14:25] does that directory exist? [14:26] do i need to create /container soemwhere ? [14:26] heh, snap :) [14:26] mind you i wouldn't expect /var/lib/lxc/android/rootfs to segv... it should just bind mount that onto itself then pivot to it. [14:26] ogra_: and after you create /container/rootfs, remember to make it rshared [14:27] so mkdir -p /container/rootfs; mount --bind /container/rootfs /container/rootfs; mount --make-rshared /container/rootfs [14:27] heya, any kernel guys around? [14:28] hallyn, well, the container doesnt start [14:30] i can't reproduce quite your setup, but let me try a simpler case here [14:30] ogra_: which release is this on, and which lxc package? [14:30] apt-get source lxc-android-config ... [14:31] * stgraber fights with make-rshared being a bit stupid [14:31] hallyn, saucy latest lxc package indeed [14:31] k [14:31] stgraber, does your container start at all ? [14:32] ogra_: yes, mine is fine because I'm using my loop-mounted images which have a saner lxc setup [14:32] why didnt you pull that into the non loop one :P [14:32] * ogra_ wants sanity too ! [14:32] no point we'll get rid of those eventually and I have no way of testing them :) [14:32] phablet-flash --flipped [14:32] :P [14:33] easy to test [14:34] jibel: so just to be clear, you created that container completely by hand, writing your own config? If not, can you add steps including lxc-create command to the bug? [14:35] stgraber, point is that we need a fix for flipped atm, it doesnt help if it works for you in the loop case [14:35] (we want to swtich to flipped by default today, that one is a blocker) [14:36] ogra_: well, my container works with a lxc.rootfs set, rshared still doesn't so getting you past the lxc.rootfs won't help much [14:36] bug 1196363 [14:36] bug 1196363 in network-manager (Ubuntu) "network-manager is breaking my wireless during "Stage 5 of 5 (IPv6 Configure Timeout)"" [Undecided,New] https://launchpad.net/bugs/1196363 [14:37] ^ this is saucy, 100% reproduceable [14:37] stgraber, hmm, k [14:37] * ogra_ would at least like to know what keeps his container from starting at all :( [14:38] ogra_: can you do lxc-start -l info -o outout and pastebinit outout? [14:38] i'm still waiting for my testbed to install saucy... [14:39] root@ubuntu-phablet:/# cat outout [14:39] lxc-start 947224102.538 INFO lxc_start_ui - using rcfile /var/lib/lxc/android/config [14:40] uh [14:40] dat not good [14:40] ogra_: in that case can you strace it? (strace -f -ooutout2 lxc-star ...) [14:40] we start from an upstart job btw ... [14:40] (on which other boot bits depend) [14:41] bah, sigh, cant install strace without NM running [14:42] ogra_: wget http://ports.ubuntu.com/ubuntu-ports/pool/main/s/strace/strace_4.5.20-2.3ubuntu2_armhf.deb + adb push strace_4.5.20-2.3ubuntu2_armhf.deb /tmp/ + dpkg -i /tmp/strace_4.5.20-2.3ubuntu2_armhf.deb [14:42] stgraber, :P i know, i'm lazy [14:43] * ogra_ just rebooted with reverted container config [14:43] hallyn: ok, finally got /var/lib/lxc/android/rootfs mounted rshared here, pivot_root fails [14:44] hallyn, http://paste.ubuntu.com/5816923/ [14:45] not really informative, it seems to die when reading the fist line of the config [14:46] slangasek: hey, with all the /run talks a while back, do you ever remember someone mentioning /etc/mtab? just noticed that one being an obvious candidate for /run and pretty annoying when /etc is read-only [14:47] stgraber, didnt we always follow the "link to /proc/mounts" directive for readonly rootfs ? [14:48] stgraber: no, /var/lib/lxc/android/rotofs is not to be rshared, [14:48] stgraber: /container/rootfs is [14:48] stgraber: in other words, /var/l/ib/lxc/android/rootfs is the *source* of the mount, but you want the target to be rshared - the dir you end up pivot_rooting into [14:49] ogra_: yeah and that's what I'm doing here, though /run may make more sense (so that things like mount -n work) [14:50] yeah. /proc/moounts definiely isnt 100% equal [14:50] hallyn: hmm, right, that'll be even trickier because of mount's silly restriction of having the target be in /etc/mtab... [14:50] hallyn, I don't use the ubuntu template but scripts from https://code.launchpad.net/otto if that's what you mean by "by hand". The default config is a modified version of an install on Saucy months ago. [14:51] hallyn, the major difference being the hooks, and lxc.cgroup.devices.allow on snd, dri, input and tty [14:52] and the memory limits [14:52] holy schnickities [14:52] hallyn, I also noticed +lxc.hook.mount = /usr/share/lxc/hooks/mountcgroups which is not there with latest template [14:52] I'll add steps to reproduce [14:53] jibel: thanks [14:54] stgraber: holy schnickities, bug in saucy's lxc with lxc.rootfs.mount set. oh! i think i knew about that one [14:54] hallyn: so I added: [14:54] mount --bind $LXC_ROOTFS_PATH $LXC_ROOTFS_PATH > /tmp/debug 2>&1 [14:54] mount --make-rshared $LXC_ROOTFS_PATH > /tmp/debug 2>&1 [14:54] hallyn: to the pre-start, was that what you were saying? [14:54] stgraber: yeah [14:54] hallyn: because if it's, then pivot_root still fails [14:55] d'oh [14:55] right, kernel won't allow that will it [14:55] yeah, same thing we had with UFA I think, kernel won't let us do it [14:56] ok, new plan :) [14:56] mkdir /junk; mount --bind /junk /junk; mount --make-rshared /junk [14:56] start the container as per usual [14:56] oh no, I guess bind-mount /junk into the container with lxc.mount.entry [14:57] then, mkdir /junk/console; lxc-attach $container mount /dev/console /junk/console [14:57] hallyn: we're on old kernels, can't rely on lxc-attach :) [14:57] hallyn: but I have an idea for our specific case [14:58] ogra_: how about we create /dev/sockets on the host (ubuntu), then bind-mount that to /sockets in the container and then have init.rc mount --move it to /dev/sockets right after /dev is mounted in android? [14:58] stgraber: then just ssh $container mount /dev/console /junk/cnosole :) [14:58] hallyn: no ssh or getty either :) [14:58] stgraber, not sure how the blobs will cope with that ... [14:59] we try to not change anything on the android side that could affect the binary blob functionallity (we already have way to many intrusive changes in the android setup) [14:59] stgraber: club it over the head and shout? [14:59] * hallyn will wait to hear what stgraber is trying and whether it worked :) [15:00] ogra_: they won't have to, it's just an extra line in the init.rc to make /dev/sockets a mount instead of a standard dir [15:00] ogra_: unless the blobs start checksuming /proc/mounts or something, they won't notice and if they're looking at /proc/mounts, they'd already fail today :) [15:01] stgraber, ok, lets try it [15:02] ogra_: ok. I'm stuck in meetings for the next 2 hours at least but will try to do some tests in parallel [15:02] * ogra_ is in a call now as well [15:05] jibel: uploaded a fix into raring-proposed unapproved queue and pinged about it on #ubuntu-release. Also committed a fix for the next upstart upload into saucy. [15:07] mpt: I don't think using the rate of errors is going to work for determining whether the architecture is significant. [15:07] As an example, if we have 1,000 errors from 1,000 am64 machines in a day, the error rate is 1. If we have 1 error from 1 machine in that same day, the error rate is also 1. [15:10] ev: but if on adm64 for a particular crash error rate is 0.98, whilst i386 error rate is 0. it does imply an arch specific bug. And a single error from a single i386 machine instantly makes the bug report "not arch specific, yet triggered easier on amd64" [15:10] xnox: the error rate would be 1 on both cases [15:12] or am I missing something? [15:12] ev: i see what you mean, as we only collect crashes. [15:12] ev: i guess what matters is proportion of architectures within a given crash report, and whether it's statistically significant disproportion. [15:12] xnox: as opposed to machines that were out there running a particular version, package, and architecture? [15:13] that's overly specific, but yeah =) [15:14] xnox: yeah, proportion seems to be more helpful at least for architecture differences [15:14] if foo is 50/50 amd64-i386 yet one crash of foo is 90/10 amd64-i386 it does hint arch-specific bug or "... easier to trigger on amd64" [15:15] I've been using >= 75% in my tests [15:15] ev: but even comparing with overall architecture split of all machines reporting any errors would be fine. As anything within 20% of a split can be accounted to random. [15:16] ev: 75 sounds good, but what's the current split between amd64/i386 reporters? 50/50? 60/40? 70/30? [15:16] (across all crashes ever uploaded) [15:16] that's a good question, and an interesting thing to start monitoring [15:17] it's not true indication of install base, but for the purpose of hinting arch-specific bugs that's the only baseline we can go by. [15:17] ev: don't forget about multi-arch though, just because my machine is :amd64 a crash in :i386 package should still count towards i386..... [15:18] oh ew. [15:18] I had not considered that. [15:18] I've been going off the Architecture field in the report. [15:18] ev: all skype crashes are i386 binaries & libraries & dependancies. As there is no amd64 skype. [15:18] yeah [15:20] ev: if the Architecture field from the report comes from the dpkg Architecture filed, all is fine. If it comes from machine/kernel then it's not so useful for this exercise. [15:20] ev: of course there are kernel bugs that only matching i386 kernel + i386 userspace binary will trigger, but those are rare. [15:20] and given enough reporters should still generate significant arch bias. [15:21] ev, if we have 1000 errors from 1000 amd64 machines in a day, that would be a fluke unless the error is clock-based. Nonetheless, the calculated error rate wouldn't be 1000/1000, it would be 1000/(weighted count of AMD64 machines). [15:22] Which, at the moment, is 1000/(number of AMD64 machines that reported any error in the past 90 days). [15:23] But would become more sophisticated once bug 1077122 is fixed. [15:23] bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122 [15:23] why would 1,000 errors from 1,000 amd64 machines be a fluke? [15:24] It would be a fluke that every single machine that had the error had it only once in that 24 hours -- that none of them had it twice or thrice. [15:25] (And thank you for giving me an opportunity to use the word "thrice". I was beginning to lose hope of using it at all in 2013.) [15:25] you could start listening to the band. That would give you plenty of opportunity [15:27] I'm not convinced this solves the problem though. The frequency an error occurs at is not what makes the architecture interesting. The percentage of instances that occurred on said architecture is though. [15:28] mpt: You may have an error that, on average, happens twice a day for i386 and twice a day for amd64, but is significantly more prevalent on amd64. [15:28] ogra_: early-init is pretty much the first thing to be called right? [15:28] even when factoring in the population of systems seen in the past 90 days [15:28] ogra_: (talking of init.rc targets) [15:29] stgraber, hmm, yeah, i think so [15:29] ogra_: ok, I'll try to dump my extra mount line as the first thing it does, that seems to be the easiest to do with sed and should avoid any potential race [15:34] stgraber: current util-linux supports /run/mount/utab; however, the implementation is only half-finished despite having been rolled out in Debian, Debian bug #702935 [15:34] Debian bug 702935 in mount "'mount -f' does not update /run/mount/utab" [Serious,Open] http://bugs.debian.org/702935 [15:37] slangasek: ok, good to hear someone's working on that. I indeed noticed /run/mount/utab in the strace output but the file ended up empty so wasn't of much use (which appears to be exactly the bug you mentioned) [15:38] ev, if you're controlling for the proportion of machines that have that architecture, you'll end up with exactly the same result starting from the proportion of errors coming from an architecture as if you start from the error rate for the architecture. They're just two routes to the same formula: (errors(amd64)*count(all arches))/(count(amd64)*errors(all arches)). [15:41] stgraber: right; it's meant to be supplemental to /proc/mounts, so it's assumed that /etc/mtab is a symlink there first of all - but it still fails in various scenarios === kk2 is now known as Kk2 [15:55] Daviey, zul: can I pass you the system-config-cluster merge? [15:56] doko: I think that one is better handled by either roaksoax or ivoks TBH [15:56] roaksoax, ivoks: ^^^. thanks for the pointer [15:58] sigh [15:58] that thing is still alive? [15:58] mpt: so we don't actually keep a count of the number of unique machines over a 90 day period per architecture, yet. [15:59] mpt: we never did return to the denominator question. Is this "count of machines (eventually weighted)" for the bucket in question, or for all problems seen that day? [15:59] ev, remember it's not just per-architecture: That's just one of the most interesting variables. [15:59] Package versions being another, locale settings, upgrade vs. fresh install, etc. [16:00] sure, I was just doing architecture first as it seemed easiest [16:00] "c(amd64)" implies an architecture-specific count of machines [16:00] Okay, just as long as you don't fix that problem in a way that works for architecture and nothing else [16:01] I can't envision a way in which I would, but I'll keep that in the back of my mind [16:01] ev, re. denominator: Neither. It's the count of machines that are using Ubuntu. [16:01] doko: i can take care of it [16:05] roaksoax, thanks === Claudinux_ is now known as Claudinux [16:09] mpt: yeah, we don't keep a count of the number of unique systems in the past 90 days for a given architecture. I'll work on a branch to add this to both the current approach and the weighting code [16:45] ogra_: ok, I have an updated pre-start.sh that fixes /dev/socket (triple testing it now) [16:45] yay [16:46] ogra_: had to read android's init source code to figure out exactly how those commands work... they look like shell but they're not at all... [16:47] heh, no, its its own language [16:47] after reading builtins.c it's much clearer what's allowed and what's not :) [16:49] ogra_: I guess I should probably fix cpuctl too while I'am at it? [16:49] i'm not even sure we access it [16:50] but yeah, all subdirs in /dev should eb available in the hosts /dev preferably [16:50] we can drop them still if we find we dont need them === fabo_ is now known as fabo [16:50] ogra_: ok. I'll do the right thing for it which is to bind-mount /sys/fs/cgroup/cpu to /dev/cpuact (we already have it in the host, just not at the same place as Android) [16:51] stgraber, err, with the same permissions ? [16:51] or rather, have it symlinked when booting the current flipped images and have it bind-mounted when booting the loop-mounted images (much simpler to implement) [16:52] i took the /dev nodes because i know everything is already processed there and listening processes are in place proper [16:52] ogra_: yep, the permissions are identical as the cgroupfs isn't namespace aware and so any change from android or from ubuntu will show up on the other side [16:53] ah, good === sabdfl_ is now known as sabdfl [16:59] cjwatson, just FYI, maguro and grouper images work fine from the new build [17:03] ogra_: please test http://paste.ubuntu.com/5817323/ [17:04] ogra_: tested here and I get /dev/socket and /dev/cpuctl working as expected (and no more /proc/ black magic) [17:07] stgraber, i think the cpuctl stuff should become a udev rule instead [17:08] * ogra_ reboots with the changes [17:10] ogra_: that'd trigger on what? you need to wait until cgroup-lite is started before it can be bind-mounted so it can't be a reaction to a uevent [17:10] ogra_: Brilliant [17:12] stgraber, hmm, i was thinking to just match on sysfs node creation ... but that might indeed not work then [17:12] stgraber, the change doesnt work [17:12] Jul 1 17:12:07 ubuntu-phablet ofonod[868]: Excluding AT modem driver [17:12] Jul 1 17:12:07 ubuntu-phablet ofonod[868]: create_ril: can't connect to RILD: Connection refused (111) [17:12] Jul 1 17:12:07 ubuntu-phablet ofonod[868]: Exiting... [17:13] ogra_: what do you have in /dev/socket on Ubuntu? [17:13] the right files [17:14] but apparently the connnection between rild and the socket on the android side isnt working [17:14] Jul 1 17:03:35 ubuntu-phablet ofonod[1253]: [UNSOL]< UNSOL_RIL_CONNECTED [17:14] Jul 1 17:03:35 ubuntu-phablet ofonod[1253]: No SIM card present. [17:14] I have that on mine [17:14] weird [17:14] i have ofono just adly respawning on maguro [17:14] *madly [17:16] stgraber, out of ten reboots one worked [17:16] stgraber, so the race got a lot worse than without the change [17:17] (it was one out of 20 or so that failed before) [17:17] and the boot seems to have gotten slower [17:17] but thats a subjective feeling [17:17] (at with an 1.5min boot probably even not a real issue :P) [17:18] ogra_: not sure what would make boot slower, we're doing less stuff now :) [17:18] ogra_: can you get: lsof -n -p 2>/dev/null [17:18] yeah [17:23] ogra_: to avoid a respawn loop we could have a start on starting upstart-file-bridge job create /dev/socket, then have ofono.override use FILE=/dev/socket/rild [17:24] doesnt work [17:24] :) [17:24] * ogra_ spent days on that bit already ... just to find that inotify doesnt seem to operate on sockets [17:24] so the file bridge doesnt work [17:25] stgraber, i think having it respawn properly is the solution... just add that upstart fix so ofono doesnt die on respawns :) [17:26] ogra_: well, upstart as a respawn limit, so on fast phones we may hit it, then ofono won't start... [17:26] oh, we actually want the limit being used [17:26] but we dont want it to die on the second one already :) [17:27] actually we should just have a wait loop in pre-start, that'd be much simpler :) [17:27] oh, just like we do, nevermind [17:28] oh, 8s sleep is a bit excessive isn't it? it's basically the time the phone takes to do a full reboot here [17:29] lol [17:29] yeah, mako isnt our target arch [17:29] a reboot on maguro takes about 2-3min [17:29] the boot lies between 50sec and 1.5min alone [17:30] * ogra_ would really like to get rid of the shutdown process ... having the shell thell the apps to save the UI realted data, calling sync and reboot -f would be so much more effective) [17:30] ogra_: anyway, got that lsof output? [17:31] stgraber, the 8s was already in ... i think telepathy required it in unflipped [17:32] stgraber, stop sending me copy paste lines with 2>/dev/null ... then i can easier find out that lsof isnt installed :P [17:33] ogra_: ah yeah, should have told you you'd need to install it first ;) [17:33] heh, i thought it was in -minimal [17:33] ogra_: the 2>/dev/null will be useful once you have it though (otherwise it spits out errors about unknown uids) [17:34] http://paste.ubuntu.com/5817408/ [17:34] looks ok [17:34] this boot also has found the socket in time [17:35] stgraber, so your idea is to loop over lsof until it connected ? [17:39] ogra_: can you get me the same thing from a boot where the socket doesn't work? === kirkland_ is now known as kirkland [17:40] ogra_: well, I'm not sure why it doesn't connect... to me it seems like if the socket exists it should work, so I'd like to see exactly what rild is listening on when it doesn't work [17:40] if i only could get one now [17:40] the first ten were all broken ... the next ten werent [17:41] I first thought it was a race in my init.rc change but I triple-checked and early-init runs before everything else including ueventd so there's no way that rild can be spawned before that and listen to the wrong /dev/socket (the one under my bind mount) [17:41] stgraber: race between the bind() and listen() calls? [17:41] well, not a race /between/ those calls; but a race because bind+listen is not atomic [17:41] stgraber, http://paste.ubuntu.com/5817423/ [17:42] stgraber, nah, the race is oldm nothing you caused ... but the timing of the startup indeed changed a bit [17:42] ofono used to come up later before [17:43] slangasek, well, likely something inside rild ... [17:43] not much we can do about it [17:43] Can anyone unpick https://jenkins.qa.ubuntu.com/job/saucy-adt-apt-clone/7/ARCH=amd64,label=adt/artifact/results/log ? It doesn't happen for me locally, and I don't think acpi-support has changed. Although I suppose it relies on archive state so maybe it's inherently chancy ... [17:43] ogra_: that second lsof shows that it's listening twice [17:43]