| TheMuso | @pilot in | 00:00 |
|---|---|---|
| === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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: TheMuso, jdstrand | ||
| jdstrand | @pilot out | 00:16 |
| === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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: TheMuso | ||
| === _salem is now known as salem_ | ||
| === dannf` is now known as dannf | ||
| igor | hi all | 02:25 |
| igor | is this the rigth place to seek support with xubuntu? | 02:25 |
| igor | I have a problem with very high power consumption on a laptop running xubuntu, that hasn't had this probem running ubuntu | 02:26 |
| igor | the power consumption with xubuntu 12.04 is more than twice than with ubuntu 12.04 | 02:27 |
| igor | same hardware | 02:27 |
| igor | perhaps one of the developers has an idea what could be the cause? | 02:28 |
| cjohnston | igor: try #xubuntu | 02:28 |
| igor | @cjohnson I did | 02:29 |
| udevbot_ | Error: "cjohnson" is not a valid command. | 02:29 |
| cjohnston | That is where you would seek support, this is not a support channel. | 02:30 |
| igor | I understand | 02:30 |
| igor | thank you | 02:30 |
| cjohnston | :-) | 02:30 |
| igor | bye | 02:32 |
| === salem_ is now known as _salem | ||
| pitti | Good morning | 03:32 |
| pitti | cjwatson: thanks | 03:32 |
| === Logan_ is now known as Guest88047 | ||
| === Logan__ is now known as Logan_ | ||
| === Guest88047 is now known as Logan_ | ||
| === Logan_ is now known as Guest40941 | ||
| === Guest81189 is now known as Logan_ | ||
| === Logan_ is now known as Guest83934 | ||
| TheMuso | @pilot out | 04:03 |
| === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | 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: | ||
| pitti | smb`: hm, so I installed current saucy server with 4 PVs, 1 VG, and 8 LVs, with a separate /boot directly on sda1, and booted a gazillion times | 04:58 |
| pitti | smb`: I also used break=top to investigate the initramfs, this looks quite fine to me :/ so I'm afraid I'll need a core dump | 04:58 |
| dholbach | good morning | 06:42 |
| === smb` is now known as smb | ||
| smb | pitti, Ok, I'll try to come up with one | 07:06 |
| slomo | doko_: are you aware of new 4.8 compiler errors since the last upload? /tmp/ccYcKg19.s:101: Error: expecting string instruction after `rep' | 07:55 |
| === wedgwood_away is now known as wedgwood | ||
| === gusch is now known as gusch|away | ||
| xnox | slomo: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710142 | 09:42 |
| ubottu | Debian bug 710142 in gcc-4.8 "FTBFS "Assembler messages: Error: expecting string instruction after `rep'"" [Important,Open] | 09:42 |
| smb | pitti, apw Some more info on my udev problem: when I add a "ps; sleep 20" to /usr/share/initramfs-tools/scripts/init-bottom/udev right after "udevadm control --exit ..." I can still see many systemd-udevd and blkid (as well as about 3 watershed processes doing the vgscan/vgchange, one vgchange being active). | 09:45 |
| smb | pitti, Beside the blkid's which I thought you said should not be run anymore. This might explain the segfaults and missing /dev/null or other things, because normally /dev gets moved right after this | 09:46 |
| pitti | yes, that's expected | 09:46 |
| pitti | the initramfs does a trigger for all devices, the workers will take a while | 09:46 |
| smb | With the large delay this also boots without issues | 09:46 |
| pitti | smb: they should all be gone after 20 seconds, though; i. e. ps; sleep 5; ps ? | 09:47 |
| smb | They seem to be after 20s, I can take a ps after 5s in another go | 09:47 |
| pitti | smb: yeah, udev itself doesn't call blkid any more | 09:47 |
| slomo | xnox: thanks | 09:48 |
| pitti | but apparently our dmsetup/mdadm packages still do (that should still work, but it's much less efficient) | 09:48 |
| smb | pitti, The symptoms look like something is not ended as you thing (so some systemd-udevd processes do not stop but /dev gets emptied while they run) | 09:49 |
| smb | *think | 09:49 |
| pitti | smb: after moving the /dev mount we add a compat /dev symlink, for this case | 09:49 |
| pitti | smb: not ended> yes, very likely | 09:50 |
| smb | pitti, apw was wondering about -TERM signals being propagated to childs of workers | 09:51 |
| smb | pitti, Hm, so with the delay of the ps moved to "sleep 5; ps; sleep 15". (boot ok) the ps shows 3 systemd-udevd processes which match up with 3 watershed workers (likely still waiting for the one vgchange to finish) | 09:55 |
| pitti | hm, I wonder if that's bug 802626 again | 09:56 |
| ubottu | bug 802626 in udev (Ubuntu Precise) "vgchange may deadlock in initramfs when VG present that's not used for rootfs" [High,Fix released] https://launchpad.net/bugs/802626 | 09:56 |
| pitti | I ported the patch for that, but that was quite intrusive | 09:57 |
| smb | It does not seem to deadlock as waiting the 20s there at least gives me all the lvs, but yes, my rootfs is not part of any vg | 09:57 |
| pitti | ah, you don't have root on LVM? | 09:57 |
| pitti | in my test install from this morning I put everything except /boot on lvm | 09:57 |
| smb | right no | 09:58 |
| pitti | smb: any chance you could build the current version without 0024-avoid-exit-deadlock-for-dm_cookie.patch, just to compare? | 09:59 |
| pitti | smb: (i. e. disable it in debian/patches/series) | 09:59 |
| smb | pitti, sure I can do that | 10:00 |
| pitti | I'll do my test reinstall again, with root on a normal partition and lots of LVs | 10:00 |
| pitti | smb: how many VGs do you have? I just created one | 10:00 |
| pitti | (with 8 LVs) | 10:00 |
| smb | pitti, Maybe one thing my /home is in a LVM VG (but a different VG)... and then there is another mount from the second VG into /home/isos... | 10:01 |
| smb | That system evolved a bit. :/ | 10:01 |
| jamespage | jodh, I've read the manpage for the 'startup' event - but I'm still a bit unclear as to what type of job should kickoff that early | 10:01 |
| pitti | smb: ack, I'll try to replicate this | 10:02 |
| pitti | smb: so /boot and / on /dev/sda*, /home on VG1, some other LVs on VG2? | 10:02 |
| jamespage | jodh, I think I need the openvswitch userspace daemons to start that early so that I can use ovs style syntax in /etc/networking/interfaces but wanted to get your opinion before i uploaded | 10:02 |
| pitti | smb: I guess you don't need a separate /boot then, do you have that? | 10:02 |
| smb | pitti, [/ on /dev/sdaX; /home on /dev/vg1/lv1; /home/isos on /dev/vg2/lv1] /boot is in / | 10:02 |
| jodh | jamespage: startup is emitted as soon as upstart starts. You really don't want to use that event. | 10:03 |
| smb | and vg2 has 30 other lvs that are not mounted directly (containing vms) | 10:03 |
| jamespage | jodh, how about starting networking? | 10:03 |
| jodh | jamespage: possibly (I know nothing about openvswitch). | 10:04 |
| === ckpringle_ is now known as ckpringle | ||
| jamespage | jodh, well my requirement is that the ovs daemons are running prior to 'ifup -a' | 10:08 |
| jamespage | so that when the ovs configuration is parsed in /etc/network/interfaces, the daemon is there for the ifup/down hooks to talk to | 10:08 |
| === mmrazik is now known as mmrazik|lunch | ||
| doko_ | slomo, bug report? | 10:14 |
| slomo | doko_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710142 already there :) just wanted to check if it's a known problem before spamming you and everybody else with bug reports | 10:17 |
| ubottu | Debian bug 710142 in gcc-4.8 "FTBFS "Assembler messages: Error: expecting string instruction after `rep'"" [Important,Open] | 10:17 |
| jodh | jamespage: I'd go for the start on condition in network-interface-security.conf in that case. | 10:17 |
| jodh | jamespage: note that you'll need to use 'instance' as that job does. | 10:17 |
| Laney | xnox: what is the rebuilds team? | 10:17 |
| doko_ | slomo, debian only? | 10:18 |
| slomo | doko_: don't know, i'm not running any recent ubuntu anywhere | 10:19 |
| doko_ | slomo, so why do you post here? | 10:20 |
| === doko_ is now known as doko | ||
| slomo | doko: good question, probably because it's the only channel we're both in. nevermind then, i'll just go the "official" way of bug reports then in the future | 10:23 |
| pitti | smb: does that look reasonably similar? (sorry, had to do it twice, messed up teh first time) http://people.canonical.com/~pitti/tmp/lvm.png | 10:23 |
| smb | pitti, Yes, looks similar enough to me | 10:25 |
| pitti | smb: vdb has two partitions (both PVs), that scrolled off | 10:26 |
| * pitti installs then | 10:26 | |
| smb | pitti, I mostly looked that there are two VGs and /home is on one of them and the other mount on the other | 10:27 |
| smb | pitti, systemd seems to be one of those "evil" packages where I cannot shortcut of building the source package while ignoring builddeps | 10:28 |
| pitti | smb: how so? debuild -S -nc should always work? | 10:29 |
| pitti | and -d | 10:29 |
| pitti | smb: did you unapply the patch before commenting it out of series? | 10:29 |
| smb | pitti, it needs some stuff to do the make clean | 10:30 |
| pitti | -nc :) | 10:30 |
| smb | pitti, yes | 10:30 |
| pitti | splendid | 10:30 |
| smb | Bah | 10:30 |
| smb | :) | 10:30 |
| jamespage | jodh, hmm - I'll take a look | 10:32 |
| pitti | smb: ok, 10/10 successful reboots | 10:51 |
| === tvoss is now known as tvoss|afk | ||
| * smb cries | 10:51 | |
| pitti | smb: if I do break=bottom, I see two handfuls of udev workers when I immediately do "ps", and they are gone after one or two seconds | 10:52 |
| pitti | smb: I'll add some ps after the --exit to check which are still running (I think that's what said patch does) | 10:52 |
| smb | pitti, I just wonder why my processing of vgchange is taking exceptionally long | 10:52 |
| pitti | smb: where is that called? | 10:53 |
| smb | pitti, indirectly through one of the udev rules | 10:53 |
| pitti | smb: I could replace it with a shell script that sleeps 5 seconds and then calls the real one | 10:53 |
| smb | I think 85-lvm* | 10:53 |
| pitti | oh, in 85-lvm2.rules | 10:53 |
| pitti | I don't have that on my workstation, sorry; but I see it in the VM | 10:54 |
| smb | Comes through lvm2 I would guess | 10:54 |
| pitti | ah, that rule is already shell; I'll just add a sleep | 10:57 |
| pitti | smb: meh, still boots perfectly fine :/ | 10:59 |
| pitti | oh, I didn't update initramfs | 10:59 |
| smb | Knowing my luck that does not change anything | 10:59 |
| pitti | now it hangs (as expected) for several seconds, but still boots; argh | 11:00 |
| mitya57 | ScottK, xnox: do we (still) need python 2 packages for pyqt5? | 11:00 |
| === MacSlow is now known as MacSlow|lunch | ||
| pitti | ok, so break=bottom interrupts before scripts/init-bottom/udev; so it's ok to see some udev processes still | 11:02 |
| === mmrazik|lunch is now known as mmrazik | ||
| xnox | mitya57: it's very tempting to have them python3 only. A few people ported (python2 -> python3) together with (pygtk2 -> py-gi & gtk3), although some did choose to do it in locksteps. | 11:02 |
| mitya57 | yes, and py-gi & gtk3 porting was happening two years ago, so I don't want to contribute to making python2 life longer :) | 11:05 |
| === gusch|away is now known as gusch | ||
| smb | pitti, So with the udev that has the lvm cookie patch removed, I did not see the /dev/null messages and systemd crash but later a message about failing to kill watershed (but this is just 1/1). The second vg has 25 of its 31 lvs with symlinks | 11:10 |
| pitti | smb: I added the sleep 5 to the rules, and some ps output to udev's initramfs-bottom; no processes left for me after udev --exit | 11:11 |
| pitti | smb: oh, is it just the symlinks that are missing or the actual vgchange setup (i. e. /dev/dm-NN)? | 11:12 |
| ogra_ | pitti, oh, btw, did you test what happens when booting without initrd after your removal of /dev/pts mounting in udev ? | 11:12 |
| smb | pitti, Usually only the symlinks to the dm-xx devices | 11:12 |
| ogra_ | the initramfs /init script explicitly has ||true to handle that case | 11:12 |
| pitti | ogra_: no, I didn't; but we haven't had that for years, it just slipped in for a few days due to the debian merge | 11:13 |
| ogra_ | pitti, we have quite a afew arm users that run without initrd | 11:13 |
| pitti | ogra_: initramfs init comes before udev's top script, though? | 11:13 |
| smb | pitti, dmsetup ls sees things and I can get a propper setup by dmsetup remove the lv and then calling vgchange -ay again (after boot) | 11:13 |
| ogra_ | ah, was it only the initrd content you changed ? | 11:13 |
| pitti | ogra_: yes | 11:13 |
| ogra_ | great | 11:14 |
| pitti | ogra_: for non-initramfs, it should be handled by /lib/init/fstab | 11:14 |
| ogra_ | then i misread | 11:14 |
| ogra_ | sorry for the noise | 11:14 |
| pitti | ogra_: no worries; double-checking greatly appreciated! | 11:14 |
| ogra_ | :) | 11:14 |
| pitti | smb: ah, I guess that triggers all the udev rules again, but this time uninterrupted by the --exit | 11:15 |
| pitti | smb: I modified /usr/share/initramfs-tools/scripts/init-bottom/udev like this: http://paste.ubuntu.com/5713055/ | 11:17 |
| pitti | smb: similar to your's? | 11:17 |
| pitti | smb: I see no udev processes after the --exit | 11:17 |
| pitti | smb: so you still see some? | 11:17 |
| smb | pitti, I now did 3 reboots with the self-compiled udev and all of them came up and complain about being unable to kill some watershed process. varying amounts of lvs are finished on setup | 11:18 |
| smb | pitti, need to remodify the script after installation | 11:19 |
| pitti | smb: so I guess the point of that patch was to fix that "varying" | 11:19 |
| smb | right, but it seems to now have different issues | 11:19 |
| smb | (in the way that some udevd gets a segfault and some seem to run on the emptying /dev) | 11:20 |
| pitti | RIGHT | 11:21 |
| pitti | sorry, caps lock | 11:21 |
| smb | Its a useless keybinding. :) | 11:22 |
| pitti | hm, I added ls -l /dev and ls -l /dev/null after the mount --move, and it looks ok | 11:22 |
| pitti | (we install a compat symlink to /root/dev/ after the move) | 11:22 |
| smb | pitti, Could be that a new ls gets the current mount namespace but a running process keeps looking at the old one | 11:26 |
| pitti | smb: hmm, could be; that compat symlink is new, but I don't see how things should be worse off with it | 11:27 |
| pitti | smb: but for opening a new file it should see the moved mount/symlink, and for an already opened /dev/null it shouldn't matter at all | 11:28 |
| smb | pitti, I am not sure whether I may talk nonsense here (maybe apw can correct me) but I thought a child process keeps seeing the mounts as they where before... | 11:37 |
| pitti | smb: I thought only if it sets unshare(CLONE_FS)? | 11:38 |
| mitya57 | cjwatson: do you know why your nginx upload didn't migrate to -release? | 11:38 |
| pitti | smb: but either way, it ought to work? if children do see the non-moved /dev still, so much the better | 11:38 |
| Laney | mitya57: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html - it's caught up with libgd2 | 11:38 |
| smb | pitti, But later there is that rm -rf /dev | 11:39 |
| * mitya57 bookmarks that page | 11:39 | |
| Laney | mitya57: s/excuses/output/ is useful too | 11:39 |
| smb | mah that s in the new layout | 11:39 |
| smb | sorry | 11:39 |
| Laney | if something is a "Valid candidate" on excuses but isn't migrating, check output to see why | 11:39 |
| Laney | that's output.txt, sorry | 11:40 |
| pitti | smb: so, some more ideas: (1) add a ps | grep ... wait loop into the hook until really all udev processes are gone | 11:40 |
| pitti | smb: that would confirm that the child processes actually run into the /dev issue | 11:40 |
| mitya57 | Laney: http://people.canonical.com/~ubuntu-archive/proposed-migration/output.txt — 404 | 11:40 |
| pitti | smb: (2) some ulimit -c unlimited and copying core dumps to /run/udev/ | 11:40 |
| Laney | update_output | 11:40 |
| mitya57 | that's better, thanks | 11:41 |
| pitti | smb: so that we can check what's actually going wrong there, and where (I'd like to fix that) | 11:41 |
| pitti | smb: (3) move 60-persistent-storage-dm.rules from IMPORT{program}="/sbin/blkid -o ... to IMPORT{builtin}="blkid --offset..., to see whether it's the external program which causes trouble | 11:42 |
| smb | pitti, Yep sounds good. Just need to move back to the version with that patch applied because currently I see no crash | 11:42 |
| pitti | smb: and (4) it would be helpful if you could confirm that you have udev processes running after the udevadm control --exit (wiht http://paste.ubuntu.com/5713055/) | 11:42 |
| pitti | smb: I need to leave in 5 mins, will be back on Monday; perhaps you can open a bug and attach results there, so that they don't drown in the mists of IRC? | 11:43 |
| pitti | (I'll log out of IRC for that time, too) | 11:43 |
| smb | pitti, ACK, I wont be around the next few days either | 11:43 |
| smb | pitti, But have some time on today left | 11:44 |
| pitti | smb: ah, right, Fronleichnam for you as well? :-) | 11:44 |
| smb | pitti, yup, we lazy Germans | 11:44 |
| pitti | smb: ok, thanks; with these four things we should have a clearer idea | 11:44 |
| halfie | Hi, the security wiki page says that PIE will be made default at some point. Any ideas about what's the progress on this is? | 11:46 |
| halfie | kees, the security wiki page says that PIE will be made default at some point. Any ideas about what's the progress on this? | 11:50 |
| === wedgwood is now known as wedgwood_away | ||
| Cimi | hi there, /me stupid has just run sudo rm /etc/default/* | 11:56 |
| Cimi | you know of any way of getting them back? | 11:56 |
| sladen | Cimi: sudo mount -o remount,ro / and then you can try undeleting stuff at your leisure | 11:59 |
| ogra_ | a backup usually helps :) | 11:59 |
| === tvoss|afk is now known as tvoss | ||
| sladen | Cimi: your homedirectory will be encrypted, but / probably won't be | 11:59 |
| Cimi | sladen, hey paul :) | 11:59 |
| Cimi | sladen, how do I restore the deleted files? | 12:00 |
| sladen | Cimi: you can try e2undel or recover on the partition, and if you're lucky it'll find them referenced via another superblock | 12:01 |
| sladen | Cimi: however, if it's a fairly fresh machine, you may just find it easier to grab the contents of /etc/default/* off another machine | 12:02 |
| Cimi | might indeed create a vm for that | 12:03 |
| sladen | Cimi: they can also be repopulated from the .debs that are installed, but as they're conf files they maybe populated dynamically, in which case you want somebody like cjwatson for clarity on whether it's possible just to dpkg-reconfigure everything and have them repopulated | 12:03 |
| geser | Cimi: "grep /etc/default /var/lib/dpkg/info/*.list" and "apt-get install --reinstall" the found packages (but wait till someone more knowledgable agrees that it's a good idea) | 12:06 |
| Cimi | will wait with a good lunch in the meanwhile :) | 12:07 |
| Cimi | I was on low sugar levels when I did that :) | 12:07 |
| mitya57 | xnox: did qt4 with disabled pch build? | 12:33 |
| xnox | mitya57: didn't run it. let me run it now, before I forget again =) | 12:35 |
| xnox | mitya57: running. | 12:38 |
| mitya57 | xnox: please let me know when^W if it fails | 12:44 |
| === _salem is now known as salem_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === mmrazik is now known as mmrazik|afk | ||
| sil2100 | oSoMoN: ping! | 13:02 |
| sil2100 | oSoMoN: hello, were you able to resolve the AP issue? | 13:04 |
| oSoMoN | sil2100: yes, now tests are failing but for a different reason, there’s a regression in the UITK | 13:11 |
| === ckpringle_ is now known as ckpringle | ||
| oSoMoN | sil2100, didrocks: the failing autopilot tests (at least those for the browser) are caused by bug #1185397 | 13:11 |
| ubottu | bug 1185397 in Ubuntu UI Toolkit "[regression] The panel doesn’t hide when tapping outside it" [Undecided,Confirmed] https://launchpad.net/bugs/1185397 | 13:12 |
| sil2100 | oSoMoN: ok, thanks, so a real regression | 13:14 |
| oSoMoN | yup, a nasty one | 13:14 |
| zul | can an archive admin promote d2t1o (#1183825) and python-pbr (#1183826) please we have a couple of packages that are dep-waited because of them | 13:20 |
| hallyn_ | stgraber: lxc bzr tree - already out of sync... <sigh> | 13:26 |
| hallyn_ | cjohnston: bug 1185364 - is that due to debhelper again (not installing the fallback sysvinit job)? | 13:27 |
| ubottu | bug 1185364 in lxc (Ubuntu) "dist-upgrade raring to saucy: package lxc 0.9.0-0ubuntu12 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 100" [High,Confirmed] https://launchpad.net/bugs/1185364 | 13:27 |
| stgraber | hallyn_: yeah, I'm not expecting the importer to work with it, we need to make sure to always push our changes (and tags) to it | 13:28 |
| stgraber | but that's not different from what we had in raring IIRC (we broke the importer at some point) | 13:28 |
| stgraber | except that I was maybe a bit quicker at manually importing any missing change so you never noticed ;) | 13:28 |
| hallyn_ | stgraber: no, it was always out of date so i always just worked with the package. as i do with qemu-kvm and libvirt... | 13:31 |
| stgraber | hallyn_: so it looks like you pushed 0.9.0-0ubuntu12 to the branch but didn't debcommit? | 13:31 |
| hallyn_ | oh does that piss it off? | 13:33 |
| stgraber | hallyn_: usually with UDD branch you need to: do your changes, commit with a changelog entry but UNRELEASED, dch -r, debcommit, bzr push | 13:33 |
| stgraber | hallyn_: yep, if you don't use debcommit we don't have the tag and without the tag it's out of sync | 13:33 |
| hallyn_ | i assumed it would diff the new and old and apply the (one-line or 0-line) diff | 13:34 |
| hallyn_ | stgraber: for my clarity - is "debcommit -r" the same as "dch -r; debcommit" ? | 13:34 |
| hallyn_ | or not? | 13:34 |
| hallyn_ | (i was doing all that for awhile but things still broke :) | 13:35 |
| === mmrazik|afk is now known as mmrazik | ||
| stgraber | hallyn_: ah right, you want "debcommit -r" for it to actually tag the branch, but you need "dch -r" before to change the UNRELEASED into the right release name and to update the changelog entry's timestamp | 13:36 |
| stgraber | hallyn_: so actually, you usually want: | 13:36 |
| stgraber | - first change for a new version => dch -i + bzr commit | 13:36 |
| stgraber | - next changes for the same version => dch -a + bzr commit | 13:36 |
| hallyn_ | stgraber: i'll go bzr-import the newest .dsc and push if you haven't | 13:37 |
| stgraber | - when ready (no change pending to commit) => dch -r + debcommit -r + bzr push + bzr bd -S + dput | 13:37 |
| stgraber | hallyn_: I fixed it | 13:37 |
| hallyn_ | stgraber: btw ^ do you know on bug 1185364 ? | 13:37 |
| ubottu | bug 1185364 in lxc (Ubuntu) "dist-upgrade raring to saucy: package lxc 0.9.0-0ubuntu12 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 100" [High,Confirmed] https://launchpad.net/bugs/1185364 | 13:37 |
| hallyn_ | stgraber: thx | 13:37 |
| stgraber | hallyn_: that looks a lot like the bug slangasek fixed yesterday. I saw a few people mentioning similar errors and I vaguely remember seeing a sysvinit upload (or some other package) that was supposed to fix this | 13:38 |
| stgraber | hallyn_: hmm, or not. The bug that was fixed is described in https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-41ubuntu2 but I see no evidence that the failure above was in a chroot | 13:40 |
| stgraber | hallyn_: I think we had a few fixes over the past few days for cases like this one (package shipping only upstart jobs). I'll create a raring container and try an upgrade, see if this got fixed | 13:42 |
| alexbligh1 | infinity, are you about? | 13:43 |
| === wedgwood_away is now known as wedgwood | ||
| barry | jtaylor: looks like you got your sync of cython, right? all is good? | 13:47 |
| stgraber | hallyn_: a dist-upgrade raring => saucy with LXC installed worked fine here, so maybe the bug has already been fixed | 13:51 |
| mardy | kenvandine: hi! dpm was asking me about this: https://bugs.launchpad.net/signon-ui/+bug/1171853 | 13:52 |
| ubottu | Launchpad bug 1171853 in signon-ui (Ubuntu Raring) "Cannot log in to Google apps domain + Ubuntu SSO" [Undecided,New] | 13:52 |
| mardy | kenvandine: do you know why it's not released? | 13:52 |
| kenvandine | mardy, no.... we need to do that SRU | 13:54 |
| kenvandine | i'll do it today | 13:54 |
| hallyn_ | stgraber: hm, but he was on the current version... weird. /me re-looks at the logs | 13:56 |
| hallyn_ | stgraber: and you have /etc/init.d/lxc ? | 13:57 |
| hallyn_ | Wondering whether some package other than lxc made a difference | 13:57 |
| mardy | kenvandine: thanks! | 13:58 |
| hallyn_ | stgraber: yeah he installed an older sysvinit | 13:59 |
| hallyn_ | hm, that's the "in a chroot" fix. | 14:00 |
| hallyn_ | i'll ask | 14:00 |
| xnox | mitya57: the build did pass the point where it fails on buildds. I actually need my machine for something else at the moment. I will kill the local build and upload your change on to buildds. | 14:07 |
| ev | mpt: on https://wiki.ubuntu.com/ErrorTracker#A.2BIBw-What.2BIBk-s_unusual_about_this_error.2BIB0- is the "rate for {matching,all other} machines" the average rate per calendar day across all days, or just the current day, or some other value? | 14:08 |
| mitya57 | xnox: thanks, and please push it to kubuntu-packagers bzr then | 14:09 |
| === salem_ is now known as _salem | ||
| mpt | ev, I hadn't thought about that. I don't know. What do you think? | 14:14 |
| === _salem is now known as salem_ | ||
| ev | I was afraid you'd ask that. | 14:15 |
| mpt | I’m trying to ask it more often. | 14:15 |
| ev | :) | 14:16 |
| ev | I'm tempted to say the current day is a reasonable sample, but I'm giving it some thought. | 14:17 |
| mpt | ev, maybe that is the best overall, but it wouldn't have illuminated the OpenOffice-doesn't-print-on-Tuesdays bug. | 14:18 |
| mpt | ("Variables should include ... day of the week.") | 14:18 |
| ev | yeah, so that would go to 0 on any day but Tuesday. Averaging out across all days would wouldn't work there either though. | 14:20 |
| ev | this office needs more whiteboards | 14:21 |
| davmor2 | ev: or you need to move away from design so there is an empty one :D | 14:23 |
| ev | mpt: the advantage of using the difference between "rate for matching machines" and "rate for all other machines" instead of just "percentage of instances that have this field and value" is what? I can see that it doesn't let a single machine overly influence the result, but beyond that I'm not sure. It wouldn't be any better at dealing with "everyone that has this crash has libc! Lets show that." | 14:26 |
| ev | just trying to whittle this down to its most basic and build up from there | 14:27 |
| mpt | ev, the point is to make a comparison. The reason you can tell that having libc installed isn't interesting is that the frequency is the same for machines with the error and machines without. | 14:29 |
| mpt | Whereas if 100% of the machines with an error have overlay-scrollbar installed, and 99% of machines without it don't, that's a big clue. | 14:30 |
| ev | so when you say "rate for matching machines" you mean the total error rate, for all errors that machine is seeing, not just the one on the problem page | 14:30 |
| ev | sans a comma | 14:31 |
| mpt | ev, no, the rate of that error in particular. | 14:31 |
| mpt | Though, comparing overall error rate might be interesting for the case where an error is caused by a library. | 14:31 |
| ev | mpt: I think I've finally got that part. So if 75% of the instances of the problem are using libc6 2.17 and 25% are using libc6 2.16, that might look like a bug in libc6 2.17. But if we look at the error rates for both of those versions, we'd see that they're roughly the same. | 14:42 |
| ev | As they might both come out to about twice a day. | 14:42 |
| ev | So much is hinged on getting that front page calculation right. | 14:42 |
| ev | (still blocked on webops sprinting for that) | 14:44 |
| mpt | ev, because it's just that 75% of machines-in-general are running libc6 2.17? | 14:44 |
| ev | exactly | 14:44 |
| mpt | What we need right now is a Bayesian. | 14:44 |
| mpt | ev, but then it wouldn't show up in the table at all, *because* the error rates are roughly the same. | 14:47 |
| mpt | Except for extremes to stop noise at the low end, it doesn't matter what proportion of machines are running each version. | 14:49 |
| ev | hm | 14:50 |
| ev | mpt: would it not be a good thing that the above example didn't show up in the table at all? If the error rates are roughly the same, the problem probably isn't in libc6. The percentage distribution of the versions for the instances of a problem might just map to how many machines in general are using a version, as you point out. | 14:53 |
| mpt | ev, exactly | 14:53 |
| ev | ah okay, for a moment there I thought you were calling into question using the rate of matching machines | 14:54 |
| ev | but clearly not :) | 14:54 |
| ev | mpt: why do you think a Bayesian filter would help us? Assuming Hadoop, we could lean on Mahout: https://cwiki.apache.org/confluence/display/MAHOUT/Algorithms | 15:04 |
| mpt | ev, I meant a Bayesian statistician, not Bayesian filtering | 15:07 |
| ev | mpt: oh, I think I know how to get one of those | 15:07 |
| ev | all we need is a burlap sack, a van, and some time around England's prestigious universities | 15:07 |
| ev | but yes, jcastro was asking if we still needed a mathematician the other day | 15:08 |
| ev | I believe he was going to do a call out on the Stack Exchange podcast thing | 15:08 |
| jcastro | I tried, but I never got around to it. :-/ | 15:11 |
| jcastro | I mentioned the errors. stuff though | 15:12 |
| === ckpringle_ is now known as ckpringle | ||
| ogra_ | could someone score up https://launchpad.net/ubuntu/+source/livecd-rootfs/2.142/+build/4623577 please | 15:30 |
| stgraber | looking | 15:30 |
| stgraber | Start in 38 seconds | 15:31 |
| ogra_ | thx | 15:31 |
| ogra_ | it was 1h | 15:31 |
| stgraber | so either someone beat me to it or it doesn't need rescoring :) | 15:31 |
| ogra_ | heh | 15:31 |
| ogra_ | it was already sitting 30min | 15:31 |
| stgraber | ogra_: you really need to setup a few livefs buildds and a clone of nusakan at home so you can test that stuff without all those uploads ;) | 15:32 |
| ogra_ | stgraber, well | 15:32 |
| ogra_ | i would like the real env around me | 15:32 |
| ogra_ | but i guess you are right at least for generic stuff | 15:33 |
| ogra_ | i'm also failing in the cleanup stage ... i am not even sure i need to clean up (could well be thatthe tarball is already created) | 15:34 |
| ogra_ | if this next build doesnt work i'll just drop the whole chunk, that will definitely make it work | 15:37 |
| === kentb-out is now known as kentb | ||
| === mmrazik is now known as mmrazik|afk | ||
| jcastro | slangasek: here are the three bugs for MAAS SRU, and it's deps: http://paste.ubuntu.com/5713778/ | 15:50 |
| === ckpringle_ is now known as ckpringle | ||
| === Sweetsha1k is now known as Sweetshark | ||
| bdmurray | ev: that crash-in-postinst package should create an apport-package crash report? | 16:40 |
| ev | bdmurray: apport-test-crashes consumes it during build to create a .crash file to include in the apport-test-crashes package | 16:40 |
| ev | (hopefully) | 16:40 |
| ev | that's then consumed by test/integration-test in lp:error-tracker-deployment | 16:41 |
| bdmurray | ev: okay, I was just trying to install it for SRU'ing the new apport-package crash signature stuff | 16:41 |
| ev | ah, then yes, you should have a /var/crash/crash-in-postinst.0.crash | 16:42 |
| ev | if you installed it via apt | 16:42 |
| ev | dpkg alone wont do it | 16:42 |
| ev | I also had to set MaxReports - which may itself be a bug | 16:42 |
| bdmurray | oh right, thanks | 16:42 |
| bdmurray | I've seen some weird stuff with MaxReports and ubiquity / live media bugs | 16:43 |
| bdmurray | I haven't looked into it yet | 16:43 |
| === dosaboy_ is now known as dosaboy | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === deryck is now known as deryck[lunch] | ||
| === nigelb_ is now known as nigelb | ||
| === danjared_ is now known as danjared | ||
| === wedgwood is now known as wedgwood_away | ||
| === deryck[lunch] is now known as deryck | ||
| === mnepton is now known as mneptok | ||
| === salem_ is now known as _salem | ||
| alexbligh1 | infinity, are you about? | 20:26 |
| infinity | alexbligh1: Vaguely. | 20:26 |
| alexbligh1 | yesterday you eveninced an interest in modules-init-tools supporting compressed modules. | 20:27 |
| alexbligh1 | https://github.com/abligh/module-init-tools | 20:27 |
| alexbligh1 | your method works | 20:27 |
| alexbligh1 | It's a 2 line patch | 20:27 |
| infinity | alexbligh1: Well, not so much an interest as a curiosity as to why this is a desirable feature. | 20:27 |
| alexbligh1 | It adds 3 x 76k to 3 /sbin binaries which are statically linked | 20:27 |
| alexbligh1 | and reduces the size of the initrd by 100MB (150MB to 50MB) | 20:27 |
| alexbligh1 | also supports uncompressed modules | 20:27 |
| infinity | alexbligh1: You mean it reduces the unpacked size, I assume? | 20:27 |
| alexbligh1 | the reduction in size is irrelevant if you drop initrd | 20:28 |
| infinity | alexbligh1: Since it shouldn't affect the compressed size at all. | 20:28 |
| alexbligh1 | yes | 20:28 |
| alexbligh1 | indeed | 20:28 |
| alexbligh1 | but if you run from RAM - i.e. your root IS initrd and in RAM, it's very useful. | 20:28 |
| infinity | alexbligh1: And probably increases boot time, due to uncompressing twice. | 20:28 |
| infinity | alexbligh1: Sure, okay, I can see the "run from RAM" case, but that likely doesn't affect us. So, perhaps I'll stop being curious. | 20:29 |
| alexbligh1 | Well, most people would not compress the modules, so that's a NOP | 20:29 |
| infinity | alexbligh1: Plus, statically linked is definitely not the way to go there. | 20:29 |
| alexbligh1 | It's a NOP bar a tiny amount of disk space for most people | 20:29 |
| infinity | (or anywhere) | 20:29 |
| alexbligh1 | I think it has to be statically linked. insmod is used very very early IIRC | 20:29 |
| alexbligh1 | TBH I just changed the setting from disabled to enabled. | 20:30 |
| alexbligh1 | But I think debian/rules has something there to support dynamic linking | 20:30 |
| alexbligh1 | I just presumed the maintainer knew what they were doing ... | 20:31 |
| alexbligh1 | I presume it would help (e.g.) live CD | 20:31 |
| alexbligh1 | If LiveCD on a minimal memory system (e.g. Raspberry Pi) is even useful! | 20:31 |
| alexbligh1 | Anyway, it's about if you want it on github. It's a 2 line patch | 20:32 |
| infinity | alexbligh1: There's no reason it would need to be statically linked, insmod itself isn't. | 20:33 |
| infinity | alexbligh1: As for the livecd case, it would actually slow it down a tiny bit, as double-decompressing slows things down, and we then discard the initramfs root when we pivot. | 20:34 |
| alexbligh1 | except that the IO to read the modules themselves would be smaller | 20:34 |
| infinity | alexbligh1: I/O in RAM tends to be quick anyway. | 20:35 |
| alexbligh1 | I am betting a CD reads slower than zlib can uncompress | 20:35 |
| infinity | alexbligh1: Now, if it was dynamically linked, and if a default initrd already has zlib (which it might), turning on the ability to use the feature, but not using it by default in Ubuntu could be a win for everyone. | 20:35 |
| alexbligh1 | I thought livecd was ISO9660+AUGS | 20:35 |
| alexbligh1 | Let me have a poke around to see if I can get it dynamically linked | 20:35 |
| infinity | And, indeed, my initramfs here has libz.so.1 in it already. | 20:36 |
| infinity | alexbligh1: This isn't about reading from the CD. You read the compressed initrd.gz (or initrd.lz, in our case, I believe) from the ISO into RAM, then you do your insmods from there. | 20:36 |
| alexbligh1 | Oh sure, for stuff you need to insmod at boot. | 20:37 |
| infinity | alexbligh1: So, if you grow that initrd a tiny bit (which double-compressing has a tendency to do), you slow down the load time a teeny bit (not by any meaningful amount), and then you end up decompressing again when you read the modules. | 20:37 |
| alexbligh1 | Not stuff (e.g. iptables rules) that gets loaded post pivot root | 20:37 |
| alexbligh1 | double compressing actually shrunk initrd a bit (yes I was surprised too) | 20:38 |
| infinity | alexbligh1: Oh, yeah, it could be a win to ship all our modules compressed. Maybe. If I/O is really a bottleneck there. I doubt we'd do it, but giving people the option in the tools if it doesn't impact people who don't use it sounds like an alright deal to me. | 20:38 |
| alexbligh1 | yeah I wouldn't suggest you compressed by default without a pretty thorough performance check. | 20:38 |
| alexbligh1 | OK I will take a look at seeing if I can get it to link dynamically. You don't think there are any circumstances where initrd does not have zlib in /lib? | 20:39 |
| infinity | alexbligh1: Hrm, it might only be in mine because I have plymouth in there, but I'll dig a bit deeper. | 20:44 |
| infinity | alexbligh1: I don't have massive issues with pulling libz into the initrd by default even if it isn't there, though. | 20:44 |
| alexbligh1 | infinity, If zlib is required, libz must be linked static, modprobe is in | 20:45 |
| alexbligh1 | # /sbin, libz is in /usr/lib and may not be available when it is run. | 20:45 |
| alexbligh1 | So says configure.ac | 20:45 |
| alexbligh1 | So I guess it's not just initrd, but about what's in /lib before /usr is mounted. | 20:47 |
| alexbligh1 | at least on my system libz is in /lib and configure.ac is wrong | 20:48 |
| infinity | alexbligh1: Yeah, configure is wrong for at least Debian/Ubuntu there. libz is in /lib | 20:57 |
| alexbligh1 | infinity, fortunately there is a --enable-zlib-dynamic option I didn't spot earlier. So this is still a 2 line patch :-) | 20:58 |
| === _salem is now known as salem_ | ||
| lifeless | stgraber: got a url for your current bindmount script ? | 22:05 |
| stgraber | lifeless: it's currently a local hack I have in an lxc pre-start script here. I just have 4 files bind-mounted for my test setup, /etc/hostname, /etc/hosts, /etc/fstab and /etc/network/interfaces. I also mount tmpfs on /var/log and /tmp | 22:07 |
| === kentb is now known as kentb-out | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
