=== Cythraul is now known as WelshDragon === mbiebl_ is now known as mbiebl [00:48] doko_, I've chased down fixes for the three nvidia build failures you mentioned a while back. Two are basically due to unresolved differences in packaging strategy between us and debian (see bug #950963), but the packages in question have been fixed to work with ubuntu, and now build. [00:48] Launchpad bug 950963 in viennacl (Ubuntu) "nvidia-graphics-drivers needs to provide separate packages such as libcuda1" [High,Confirmed] https://launchpad.net/bugs/950963 [00:50] dobey, the third build failure I located a fix and worked with debian on getting a fix. Debian's 2.0.8-1+dfsg-3 includes this fix, and I'll sync it to quantal once LP picks it up. [00:50] damn tab completion [00:50] sorry dobey. [00:51] doko_, bug #1061969 tracks the sync request for that issue. [00:51] Launchpad bug 1061969 in nvidia-texture-tools (Ubuntu) "Sync 2.0.8-1+dfsg-3 to fix FTBS" [Undecided,New] https://launchpad.net/bugs/1061969 [00:53] doko_, you also asked me to look into the vnc4 issue. I investigated this and figured out what's wrong. Looks like the fix is to backport some of the arm support from xorg-server to vnc4's embedded copy of xserver. See bug #945368 in ubuntu and debian #621409. [00:53] Launchpad bug 945368 in vnc4 (Ubuntu) "vnc4 version 4.1.1+xorg4.3.0-37ubuntu4 failed to build on armhf" [High,Confirmed] https://launchpad.net/bugs/945368 [00:53] Debian bug 621409 in src:vnc4 "vnc4: FTBFS on armel: macro 'in' not recognized -- ignoring" [Important,Open] http://bugs.debian.org/621409 [00:55] doko_, unfortunately I'm starting another project and won't have further time to work on it. I think the porting work should be straightforward C hacking, so really anyone could do it. I was hoping Debian would take care of it for us since it's a bug on their end, but not so far. [00:57] bryceh: And by "backport", you mean "stop having an ancient embedded copy of X in vnc"? [00:58] infinity, no I mean cut and paste the #ifdef arm bits from the shiny new xserver into the antique xserver [00:59] bryceh: Yeah, I knew what you meant, I was just hoping for the other. :P [00:59] but the two files are vastly different so it's a little unclear where exactly to paste. It'll take some care to make sure it doesn't break some other random obscure hardware... [01:01] infinity, you and me both. I had forgotten that was in there, so it was a bit creepy browsing through it [01:20] hey all. looking for some hints. [01:20] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977 is my bug. [01:20] Launchpad bug 1061977 in MAAS "Machine fails to commission when console=ttyS0 is present on kernel opts" [Critical,Triaged] [01:21] machine boots with console=ttyS0, generally boots fine until some point an upstart job that has 'console output' fails [01:21] running it through upstart again, will fail [01:21] running the same thing not through upstart will succeed. [01:23] and if we do: echo HELLO | sudo tee /dev/console [01:23] we get [01:23] tee: /dev/console: Input/output error [01:26] smoser: i ask this from a position of ignorance, but why have console=ttyS0 in the kernel arguments if that's not the correct value? [01:26] which that looks like [01:26] because they're default parameters. [01:26] and in general the target for this is something that is likely to have ipmi serial or logged serial or something. [01:27] as i understood it, the kernel would basically go through console= taking the last valid entry and making that /dev/console [01:27] but it seems to be convinced that /dev/ttyS0 is "good enough" and then croaks later when user space writes a bunch more data there. [01:28] ah [01:28] no idea then [01:29] what's cc_keys_to_console.py supposed to do? [01:31] smoser: "console=tty1 console=ttyS0" ? [01:33] sarnold, supposed to just write the ssh keys for the hsot to the console [01:34] smoser: does it rely upon any 'odd' terminal escape sequences or termcap/terminfo along the way? [01:34] (on ec2 and other clouds, the serial console is logged and you can collect it) [01:34] nah. just normal text. [01:35] aha, and I see multiple consoles should be supported. Hrm. [01:37] well, yeah, it *does* work. [01:37] ie, in kvm when i boot i see kernel messages on both, and then user-space messages on the serial [01:42] smoser: "Read 3 bytes from /home/ubuntu/.ssh/authorized_keys" -- why only 3 bytes? [01:43] i dont knwo. that is strange. [01:43] (not that this _really_ helps with the /dev/console, but it's odd, and maybe you'll get lucky?) [01:44] i dont think so. i thikn its probably just abug. [01:44] in cloud-init. [01:44] as that file likely doesn't have anything in it. [01:44] as there were no ssh keys imported [01:46] the logs did say "read 0 bytes" elsewhere though, so it seems prepared to handle zero-byte files alright. [01:48] hallyn: I'm around now :) [01:56] sarnold, well thanks for the thoughts. [01:58] stgraber: i went ahead and pushed part of the fix for grub updates to lxc in quantal [01:58] stgraber: cjwatson will push the other bit to grub tomorrow [02:03] hallyn: is fstab processed before the /dev/lxc/* entries are created? if not, I'd expect that fstab entry to hide them and start giving direct access to the host devices which would be kinda bad [02:07] stgraber: it is. mounts are done first [02:12] hallyn: good, so yeah, should be fine. I'll takk a look at github in a sec [03:40] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg === cyphermox_ is now known as cyphermox [04:08] hrw: BTW, if we can get wine ported to use a different gcc before release, gcc-4.5 will be removed from quantal [04:11] * micahg decides to stop trying to UDD merge when people aren't using the VCS as a VCS... === mhall119_ is now known as mhall119 [04:34] micahg: That's a pretty hopeful "if". [04:36] infinity: I can dream, can't i? [04:36] micahg: Sure, carry on. [05:24] I have a small accounts services fix, that needs sponsoring https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1059090/comments/4 [05:24] Launchpad bug 1059090 in accountsservice (Ubuntu) "Unable to autologin" [Undecided,In progress] === dendrobates is now known as dendro-afk [05:32] infinity: any reason xserver-xorg-video-displaylink was deleted from Quantal? [05:32] bkerensa: I think because it's supported by the kms driver, now? [05:33] RAOF: idk I just had a Mozilla colleague indicate that they have zero USB Monitor support since the package was deleted [05:33] I will check back with him [05:33] It should be picked up by the kms driver and then xf86-video-modesetting should kick in. [05:40] Good morning [05:41] Good evening. [05:44] micahg: when gcc-4.[45] get removed I will post for removal of cross one as well [05:50] hrw: We may as well just remove the cross 4.5 now, to be honest, we don't want to encourage people to be using old toolchains. [05:50] hrw: If the only reason to keep it around it one package, why make it two? [05:53] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [06:01] infinity: right === lifeless_ is now known as lifeless [06:49] bryceh: nvidia-texture-tools - FWIW it would have been great if you'd filed a bug about that somewhere (Debian or Ubuntu) in advance. I spent half an hour or so on it only to find you'd been dealing with it already out of public view. === sabdfl is now known as sabdfls-got-root [07:12] cjwatson, did you see bug #1061969? [07:12] Launchpad bug 1061969 in nvidia-texture-tools (Ubuntu) "Sync 2.0.8-1+dfsg-3 to fix FTBS" [Undecided,New] https://launchpad.net/bugs/1061969 [07:13] bryceh: That was filed after I spent some time working on it (having checked all the bug lists first) only to have the Debian maintainer tell me you already had. [07:13] cjwatson, any issue if I proceed with the sync? [07:13] bryceh: No, go ahead [07:13] (Why file bugs for syncs you don't need sponsorship for anyway?) === smb` is now known as smb [07:14] cjwatson, because we're in freeze, for traceability if the package is held [07:15] Well, sync it and I'll accept it, anyway [07:16] is bug 1017603 valid? it's what I had in mind too [07:16] Launchpad bug 1017603 in perl (Ubuntu) "perl needs to be multiarch" [Undecided,New] https://launchpad.net/bugs/1017603 [07:16] bryceh: accepted [07:17] (oops, accepted my -2ubuntu1 as well, but no harm done there) [07:17] tjaalton: the principle is valid and the Linaro guys have been working on this [07:17] cjwatson: oh cool [07:17] triaged the bug [07:18] could it be sru'd to precise too, or are such changes not acceptable? [07:18] cjwatson, doko had asked me to look at the build issue, but there wasn't a bug report. didn't realize there was a protocol for how to work on build failures. [07:19] bryceh: Well, I would suggest that if you're working with Debian you should do it through the bug system rather than by e-mailing the maintainer directly [07:19] (the Debian bug system that is) [07:19] That way I'd have seen it and moved on :) [07:19] aaaaaaargh, why does my right trackpad button randomly stop working [07:21] cjwatson, well don't ask me for help with that button, I might fix it but fail to file a bug report on it. ;-) [07:21] heh [07:21] Sorry, glad you fixed it [07:22] no prob, night. [07:33] pitti: ping [07:34] pitti: two questions, same as before: can we ship python3-pyudev on the CD (for checkbox) [07:34] zyga: (in interview, bbl) [07:34] pitti: and can we upgrade that package (rdepends are empty) from 0.13 to 0.17 [07:34] pitti: k, thanks [07:34] pitti: (debian does not have updated versions but it's pure python so it should be trivial to do) [07:34] * zyga looks into the new source package [07:35] zyga: so, the marathon guys let me go :) [07:36] zyga: no objections, but I think pyudev is a dead end [07:36] zyga: we have had introspection bindings for years which work very well [07:37] hmm [07:37] so which api should I use/ [07:37] gi + gudev? [07:38] pyudev has some pythonic goodness on top of raw udev, I'd rather not loose that [07:39] I think gi.repository.GUdev works very well, but as I said, I don't object to pyudev [07:39] zyga: what goodness, OOI? [07:39] if you use this in a GLib-ish project already, then gudev is certainly the way to go; you have automatic main loop integration, signal support, etc. [07:39] pitti: I'll have a look at that [07:40] if you use this in a Qt-ish project, you might not want the additional dependencies [07:40] is this for checkbox? [07:40] pitti: well, I only used it briefly but it has python wrappers for udev devices and attributes [07:40] yes [07:40] sadly we need udev too [07:40] it's not merged in yet [07:40] "udev is not merged"? [07:41] the branch that depends on udev has not landed [07:41] https://code.launchpad.net/~zkrynicki/checkbox/usb3/+merge/127993 [07:41] have a look at the brief discussion there [07:42] hmm [07:42] GUdev looks very similar [07:42] zyga: ah, you already use gi.repository.GObject, so you already have all the glib, libgirepository and pygobject dependencies anyway [07:42] that's right [07:43] pitti: so it's my first time with using gi.repository magic, where do I find docs on the GUdev module, in the upstream C version? [07:45] zyga: http://www.freedesktop.org/software/systemd/gudev/ is the C API [07:45] it translates to the Python API in a straightforward way, but if you prefer a really Python-ish doc, you can get that as well [07:46] I know the idea behing gobject introspection [07:46] mkdir /tmp/gudev; g-ir-doc-tool -o /tmp/gudev/ /usr/share/gir-1.0/GUdev-1.0.gir; yelp /tmp/gudev/ [07:46] just never used it in practice [07:47] ohhh [07:47] thanks a lot [07:47] that's still a bit inconvenient, sorry [07:47] I'll try to use that instead [07:47] but you get the class/method name separation instead of the C-style class_name_method() [07:48] pitti: g-ir-doc-tool? where is that from cnf does not know about it [07:48] "gobject-introspection" package [07:48] thanks [07:49] oh, indeed that's not on a default install [07:52] pitti: which package has /usr/share/gir-1.0/GUdev1.0.gir [07:52] it's not in gir-1.2-gudev [07:52] zyga: gir1.2-gudev-1.0 is the typelib, libgudev-1.0-dev has the gir [07:52] ah [07:52] ok [07:52] thanks [07:52] (yay for confusing package names) [07:53] :D [07:53] no, it's okay [07:53] well [07:53] it's not better than anything else [07:53] zyga: at runtime you only need the .typelib, which is the compiled gir (which is XML and human readable) [07:53] I wish something like online apt-file was built into ubuntu by default [07:53] right [07:56] yeah, similar to rmadison [07:56] pitti: hmm it crashes on missing GObject-2.0.gir [07:57] * zyga looks for that [07:57] zyga: libglib2.0-dev [07:58] pitti, speaking of gobject-introspection, did you not package 1.34 on purpose? [07:58] (it's one of the few tarballs were we didn't upate to the stable GNOME 3.6 one) [07:58] seb128: oh, it might have been released late [07:58] seb128: doing now [07:58] pitti: no, I already have that [07:59] seb128: I'm currently updating udisks to 2.0.0 final === dendro-afk is now known as dendrobates [07:59] pitti, danke [07:59] pitti: there are no .gir files in that package [07:59] zyga, libgirepository1.0-dev [07:59] zyga: whoops, sorry; gobject/glib girs are special, what seb128 says [08:00] thanks [08:00] zyga: (glib2.0 source cannot build its own girs) === spm` is now known as spm_ === spm_ is now known as spm === henrix_ is now known as henrix [08:09] pitti: I'm trying to use that, how do I enumerate devices, Enumerator is not really iterable and there are no other methods that look like something accessing a collection [08:10] zyga: calling .execute() on the enumerator after setting it up will give you an iterable Python array [08:11] ahh, thanks, I've missed that [08:11] pitti: reading the docs on that [08:11] pitti: do I need to worry about gobject references form python? [08:11] no, pygobject does that for you [08:12] ok, cool [08:12] it seems to work, thanks, I'll take it form there [08:12] nice === dendrobates is now known as dendro-afk [08:30] pitti: Device.get_parent() does not exist, I need that method, could this be a bug in gir? (it's documented that this method exists) [08:30] http://www.freedesktop.org/software/systemd/gudev/GUdevDevice.html#g-udev-device-get-parent [08:30] zyga: indeed, it's marked as non-introspectable; presumably a missing annotation [08:31] ohhh [08:31] zyga: you can use os.path.dirname(path) to get the parent, too; but I'll investigate [08:31] crap [08:32] I'll get this fixed upstream and backport it to our udev [08:32] thanks === Sweetsha1k is now known as Sweetshark === henrix is now known as henrix_ === henrix_ is now known as henrix [08:51] pitti: dirname() on which path? sysfs? [08:51] zyga: right, in sysfs; getting the parent dev is just that [08:52] cool, thanks [08:53] doko_: do you have guesses as to which patches might be responsible for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680439 [08:53] Debian bug 680439 in gcc-snapshot "gcc-4.7: Fails to build glibc (git master) [amd64]: '__EI___isnan' aliased to external symbol '__GI___isnan'" [Important,Open] [08:54] don't worry if not - I'll just wait for infinity to wake up === dendro-afk is now known as dendrobates [08:57] zyga: ah, it's fixed upstream already, it's just that our udev is really old; I'll backport the fixes [08:58] pitti: good news, thanks [08:59] 193 vs 175 [08:59] 194 even === EyesIsMine is now known as EyesIsServer [09:12] we need to drop an old debian patch in accounts services to make the autologin toggle work in user accounts on ubuntu gnome remix. I attached a debdiff to this bug, if anyone is able to sponsor it. https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1059090/comments/4 [09:12] Launchpad bug 1059090 in accountsservice (Ubuntu) "Unable to autologin" [Undecided,In progress] [09:22] Bug #1062137 filled to get rid of old cross compilers [09:22] Launchpad bug 1062137 in gcc-4.5-armhf-cross (Ubuntu) "Remove from quantal" [Undecided,New] https://launchpad.net/bugs/1062137 [09:23] pitti: hmm, it seems I cannot just chop the path to traverse devices [09:24] pitti: for /dev/sdb1 I got /dev/sdb but then stop -- I wanted to traverse all the way up to the USB hub device (it's a thumb drive) [09:24] yes, it should do that [09:24] pitti: starting from /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/sdb/sdb1 [09:24] zyga: (anyway, test-building udev now) [09:25] it only got to /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/sdb [09:25] zyga: sure, that's the next parent [09:25] going higher made Client.query_by_sysfs_path() return None [09:25] you have to iterate through all parents [09:25] zyga: libudev's get_parent() really does the same -- just chop off the last path component [09:25] hrw: Thanks, I'll process that [09:26] pitti: so until I get all the way up to /sys? [09:26] cjwatson: thanks [09:26] hrw: I assume I can reject the corresponding uploads in the unapproved queue? [09:26] ignoring things that don't look like devices? [09:26] cjwatson: yes [09:26] OK, done [09:26] cool [09:26] Just triple-checking reverse dependencies [09:26] zyga: perhaps you want get_parent_with_subsystem() if you are looking for a particular kind of parent dev [09:27] Which is hard with a headache and a toddler talking to me [09:27] zyga: well, in kernel teams all of those are devices [09:27] zyga: you have to specify "what shoudl the device look like" yourself, in terms of subsystem, attributes, and properties [09:28] $ grep introspectable /usr/share/gir-1.0/GUdev-1.0.gir [09:28] $ [09:28] zyga: ^ voila :) [09:29] pitti: for me /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/ is empty apart form the 'sdb' directory, there are no attribute files there [09:29] ah, right [09:29] pitti: anyway, ignoring stuff that fails to create a udev device they way I said seems to work [09:30] zyga: right, sorry; udev's skips directories without an "uevent" file [09:30] zyga: I uploaded the fixed udev, now waiting for a release team member to review, then you'll have it an hour after that [09:30] doko_: do you have objections to syncing poco just to test if bug 903347 is fixed in quantal? [09:30] Launchpad bug 903347 in poco (Ubuntu Precise) "[armel/armhf] file fails to compile (indefinite loop?)" [Medium,Triaged] https://launchpad.net/bugs/903347 [09:31] or someone here has the hardware could test it for me :) [09:31] pitti: awesome, thanks for the help! :-) [09:33] hrw: all right, all done now [09:34] dholbach, jono, dpm, jcastro_, mhall119: wohoo, > 5000! go, go, go! [09:34] :-D [09:35] \o/ [09:35] pitti, :-) [09:35] ..zzZZ [09:35] pitti, \m/ [09:36] jcastro_: live juju demo [09:39] doko_: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.71 :) [09:40] dholbach: who's DJing, you? [09:41] pitti, very short :) [09:41] just a bit [09:49] mlankhorst,tjaalton: so, I notice you removed xserver-xorg-video-geode from xserver-xorg-video-all, which has caused it to be listed for movement to universe on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; was it intentional to drop it out of main, or just out of the default set? [09:51] zyga: If you are anxious for the fixed packages, grab them from https://launchpad.net/ubuntu/+source/udev/175-0ubuntu12 [09:52] cjwatson: move to universe is fine, it's not that useful anymore since the kernel requires PAE support. but keep it there for now if some folks want to use their own kernels.. [09:54] tjaalton: OK, moved to universe [09:54] thanks === mcclurmc is now known as mcclurmc_away [10:01] cjwatson: intentional :) [10:01] jono, dholbach: ah, the last few minutes weren't broadcasted any more; anyway, good night! awesome job! [10:01] but tjaalton beat me to it [10:01] pitti, they were - we had to restart the hangout [10:01] thanks, pitti! [10:02] thanks for joining us earlier! [10:02] dholbach: right, I tried to reload several times, it always said "will be available soon" [10:02] hum [10:02] jono: de rien [10:02] it seems to have worked for others [10:02] *shrug* no biggie [10:02] why are you still online anyway! :) [10:03] james_w: hey James, how are you? [10:04] james_w: who can I bother about pushing buttons for UDD imports these days? (gvfs is out of date) [10:13] jono, have you started hallucinating yet? ;) [10:13] i think i would be after 24h [10:13] chrisccoulson, getting there :-) [10:13] hah :) [10:13] That usually starts at around 35h for me [10:13] Not that I'm much use between 24h and 35h [10:14] jono: for example, you might imagine it was already over :) [10:15] you guys dont take the day off, do you ? :) === henrix_` is now known as henrix [10:24] wookey, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 [10:24] gcc.gnu.org bug 33763 in c "[4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining" [Normal,New] [10:25] wookey, my understanding is, that this should be fixed in glibc [10:36] jtaylor, why? is there a fix for GCC? [10:36] don't know [10:50] wookey, no, apparently I'm wrong. just drop it for now [10:58] davmor2: FYI, I now added a gvfs test case for recognizing media players as such :) [10:58] davmor2: this broke $DEITY knows how many times already.. [10:59] pitti: just tested it, S3 works correctly although the system thinks it's a tablet and the music player is detected however the icon in the launcher isn't a music player but a usb stick is this a change in behaviour? === dmart_ is now known as dmart [11:01] davmor2: yes, very close to gnome bug 631809 [11:01] Gnome bug 631809 in gdu volume monitor "Nautilus should use the media-player name from media-player-info if available" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=631809 [11:01] pitti: I'm just happy that I have my sansa fuse to keep testing it is broken or not hopefully now :) [11:01] davmor2: these bugs apply to any media player, though (same for my xperia mobile) [11:02] pitti: indeed [11:03] pitti: mine just happens to be a sansa fuze that I've had for a while so seem to keep finding the breakage with it :) I'm happy to here that there could be an upstream fix for it now though :) [11:03] davmor2: my fix from yesterday to detect them at all already went upstream [11:03] icons and volume names still need to be fixed, that's on my list [11:04] (and now that's trivial to test) [11:04] pitti: cool :) [11:08] pitti: thanks [11:13] pitti: on a plus side the system thinks I have a music player WooHOO!!!! === MacSlow is now known as MacSlow|lunch === doko_ is now known as doko [11:29] hmm, i have two packages that should never be unpacked on the same system at the same time, can i just use Conflicts here ? [11:30] That's the exact meaning of Conflicts [11:30] k [11:30] no need to use replacess i guess [11:30] Not in general but you might want to if one of the two is going away [11:31] The policy manual has detailed advice [11:31] by going away you mean that the other package then comes in as a replacement ? [11:31] thats definitely not waht i want ... [11:31] *what [11:32] for example [11:36] pitti: is the stack of language pack uploads yours? === cpg is now known as cpg|away [11:41] pitti: Never mind, looks like a straightforward update so I'll just accept it all [11:42] cjwatson: (OTP) presumably from the automatic cronjob [11:42] OK [11:45] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Quantal Quetzal development | Beta 2 released! | Archive: Frozen | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage === mcclurmc_away is now known as mcclurmc === cpg|away is now known as cpg === MacSlow|lunch is now known as MacSlow === _salem is now known as salem_ === cpg is now known as cpg|away [13:19] ev: hey Evan [13:19] hi Pici [13:19] pitti even [13:19] ev: I assigned a bug to you this morning about unpacking xz debs not working any more [13:19] yikes, on it [13:19] ev: it seems that none of our three implementations gets it right :( [13:20] ev: but I'm really concerned about dpkg-deb -x having that bug; how does it deal with symlinks in the actual system? [13:20] pitti: how does dpkg -x deal with symlinks? [13:20] or dpkg -i? [13:20] dpkg -i notices that there's something there already and happily carries on [13:21] ev: or whichever bug you wanted to fix by moving to python-debian/apt_inst [13:22] dpkg -x should extract symlinks perfectly normally [13:22] https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1059621 [13:22] Launchpad bug 1059621 in apport (Ubuntu) "Sandbox option breaks on extraction of precise gnat-gps and gnat-gps-common" [Undecided,New] [13:23] the random package I have to hand that contains symlinks extracts just fine [13:23] cjwatson: it extracts symlinks fine. But while dpkg -i notices that the symlink it's trying to create already exists as a directory and skips it, dpkg -x does not. [13:23] thus the "tar: ./usr/share/doc/gnat-gps: Cannot create symlink to `gnat-gps-common': File exists" [13:24] that looks like an outright bug in the package to me, really [13:25] gnat-gps-common should put features.gz and known-problems.gz in /usr/share/doc/gnat-gps-common/, not gnat-gps/ [13:25] the way it is right now, even with dpkg -i it's probably nondeterministic what ends up in gnat-gps/ [13:26] hmm [13:26] Debian #684194 [13:27] Debian bug 684194 in gnat-gps "gnat-gps: /u/s/d/gnat-gps is empty after upgrade from squeeze" [Serious,Fixed] http://bugs.debian.org/684194 [13:27] pitti: do you think we should back out the change and consider these unretraceable? [13:27] cjwatson: massive, massive thanks [13:28] (so fixed in quantal, I believe) [13:28] might not be totally insane to SRU that fix === salem_ is now known as _salem [13:34] jodh, around ? [13:35] i'm running into a problem where getting the "right" console= parms is not easily done. and as a result, /dev/console (stdout for upstart) is hosed. === _salem is now known as salem_ [13:35] that, in turn, hoses anything that has 'console output'. [13:36] is there any way in upstart to fix that case? ie, if stdout gives io error when written to, try somewhere else. [13:46] ev: works for me [13:48] smoser: what console= kernel param are you specifying [13:48] smoser: ? [13:48] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977/comments/4 has more info [13:48] Launchpad bug 1061977 in MAAS "Machine fails to commission when console=ttyS0 is present on kernel opts" [Critical,Triaged] [13:48] i'm specifying "console=tty1 console=/dev/ttyS0" which tells the kernel to make /dev/console == /dev/ttyS0 [13:49] but /dev/ttyS0 might not actually be a device. [13:49] smoser, sudo in an upstart job ? [13:50] where do you see that? [13:50] ah. that was just an example. [13:50] ahm, thats only manual test code ? [13:50] smoser: I thought that meant redirect console output to *both* devices? One sec... [13:50] saying /dev/ttyS0 is busted. [13:50] err... /dev/console. [13:50] jodh, it sends kernel messages to both devices === dpb_ is now known as Guest72485 [13:50] hmm, it shoudlnt [13:50] but /dev/console is not a multiplexer. "last one wins" [13:51] the second console= option is ususally handed to userspace [13:51] ogra_, right. [13:51] while the first one is used for kernel messages [13:51] no. [13:51] (if you actually use two) [13:51] kernel messages go to both. [13:51] user space gets the last. [13:51] they shouldnt [13:51] the doc and experience say otherwise :) [13:51] smoser: [13:51] You can specify multiple console= options on the kernel command line. [13:51] Output will appear on all of them. The last device will be used when [13:51] you open /dev/console. [13:52] smoser: so, trying changing the order. [13:52] jodh, yeah, that will work. [13:52] * ogra_ has never seen the kernel output to more than one tty [13:52] smoser: that was from Documentation/serial-console.txt in the kernel fwiw. [13:52] jodh, i liked to that. [13:52] linked to that [13:53] jodh, my problem is that if i do that, i will *never* (well, 98% of never) get /dev/console == /dev/ttyS0. [13:53] ev, do you know when bug #1061867 is not registering on the front page of e.u.c ... it's a recent issue and it has been ranking high on the launchpad retracer, that's reality the sort of issues we need to know about, it's a bit disturbing that the error tracker doesn't catch those [13:53] Launchpad bug 1061867 in indicator-datetime (Ubuntu) "indicator-datetime-service crashed with SIGSEGV in e_client_open_sync()" [High,Confirmed] https://launchpad.net/bugs/1061867 [13:53] which is better in the case where there *is* a ttyS0 [13:54] jodh, the reason i bothered you, is that there seems no [easy] way to change /dev/console, and whatever is the last 'console=' parm will become /dev/console. [13:54] but upstart could potentially recognize that its stdout is busted. [13:55] and i could potentially tell upstart (configuration or kernel cmdlines) "if your stdout is busted, try others in this order" [13:55] smoser: that's kernel behaviour I'm afraid :) You could try playing tricks likehttp://upstart.ubuntu.com/cookbook/#versions-of-upstart-older-than-1-4 maybe? [13:56] you can surely work around it in /init in the initrd [13:56] smoser: ... where the device is passed in as a job param maybe or config variable? [13:56] (theoretically it does that already) [13:56] ogra_, well, i sort of could. [13:56] smoser/ogra_: but do you even need an initrd for those cloud images I wonder. [13:57] i could set init's stderr, stdin, stdout to something other than /dev/console if /dev/console was busted, yes. [13:57] and that would be essentially the same as having upstart do it. [13:57] just easier to hcak it into the shell script :) [13:57]