[00:48] <bryceh> 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:50] <bryceh> 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] <bryceh> damn tab completion
[00:50] <bryceh> sorry dobey.
[00:51] <bryceh> doko_, bug #1061969 tracks the sync request for that issue.
[00:53] <bryceh> 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:55] <bryceh> 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] <infinity> bryceh: And by "backport", you mean "stop having an ancient embedded copy of X in vnc"?
[00:58] <bryceh> infinity, no I mean cut and paste the #ifdef arm bits from the shiny new xserver into the antique xserver
[00:59] <infinity> bryceh: Yeah, I knew what you meant, I was just hoping for the other. :P
[00:59] <bryceh> 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] <bryceh> infinity, you and me both.  I had forgotten that was in there, so it was a bit creepy browsing through it
[01:20] <smoser> hey all. looking for some hints.
[01:20] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977 is my bug.
[01:21] <smoser> machine boots with console=ttyS0, generally boots fine until some point an upstart job that has 'console output' fails
[01:21] <smoser> running it through upstart again, will fail
[01:21] <smoser> running the same thing not through upstart will succeed.
[01:23] <smoser> and if we do: echo HELLO | sudo tee /dev/console
[01:23] <smoser> we get
[01:23] <smoser> tee: /dev/console: Input/output error
[01:26] <mwhudson> 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] <mwhudson> which that looks like
[01:26] <smoser> because they're default parameters.
[01:26] <smoser> and in general the target for this is something that is likely to have ipmi serial or logged serial or something.
[01:27] <smoser> as i understood it, the kernel would basically go through console= taking the last valid entry and making that /dev/console
[01:27] <smoser> 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] <mwhudson> ah
[01:28] <mwhudson> no idea then
[01:29] <sarnold> what's cc_keys_to_console.py supposed to do?
[01:31] <sarnold> smoser: "console=tty1 console=ttyS0" ?
[01:33] <smoser> sarnold, supposed to just write the ssh keys for the hsot to the console
[01:34] <sarnold> smoser: does it rely upon any 'odd' terminal escape sequences or termcap/terminfo along the way?
[01:34] <smoser> (on ec2 and other clouds, the serial console is logged and you can collect it)
[01:34] <smoser> nah. just normal text.
[01:35] <sarnold> aha, and I see multiple consoles should be supported. Hrm.
[01:37] <smoser> well, yeah, it *does* work.
[01:37] <smoser> ie, in kvm when i boot i see kernel messages on both, and then user-space messages on the serial
[01:42] <sarnold> smoser: "Read 3 bytes from /home/ubuntu/.ssh/authorized_keys" -- why only 3 bytes?
[01:43] <smoser> i dont knwo. that is strange.
[01:43] <sarnold> (not that this _really_ helps with the /dev/console, but it's odd, and maybe you'll get lucky?)
[01:44] <smoser> i dont think so. i thikn its probably just abug.
[01:44] <smoser> in cloud-init.
[01:44] <smoser> as that file likely doesn't have anything in it.
[01:44] <smoser> as there were no ssh keys imported
[01:46] <sarnold> the logs did say "read 0 bytes" elsewhere though, so it seems prepared to handle zero-byte files alright.
[01:48] <stgraber> hallyn: I'm around now :)
[01:56] <smoser> sarnold, well thanks for the thoughts.
[01:58] <hallyn> stgraber: i went ahead and pushed part of the fix for grub updates to lxc in quantal
[01:58] <hallyn> stgraber: cjwatson will push the other bit to grub tomorrow
[02:03] <stgraber> 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] <hallyn> stgraber: it is.  mounts are done first
[02:12] <stgraber> hallyn: good, so yeah, should be fine. I'll takk a look at github in a sec
[03:40] <micahg> @pilot in
[04:08] <micahg> 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...
[04:34] <infinity> micahg: That's a pretty hopeful "if".
[04:36] <micahg> infinity: I can dream, can't i?
[04:36] <infinity> micahg: Sure, carry on.
[05:24] <darkxst> I have a small accounts services fix, that needs sponsoring https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1059090/comments/4
[05:32] <bkerensa> infinity: any reason xserver-xorg-video-displaylink was deleted from Quantal?
[05:32] <RAOF> bkerensa: I think because it's supported by the kms driver, now?
[05:33] <bkerensa> RAOF: idk I just had a Mozilla colleague indicate that they have zero USB Monitor support since the package was deleted
[05:33] <bkerensa> I will check back with him
[05:33] <RAOF> It should be picked up by the kms driver and then xf86-video-modesetting should kick in.
[05:40] <pitti> Good morning
[05:41] <epikvision> Good evening.
[05:44] <hrw> micahg: when gcc-4.[45] get removed I will post for removal of cross one as well
[05:50] <infinity> 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] <infinity> hrw: If the only reason to keep it around it one package, why make it two?
[05:53] <micahg> @pilot out
[06:01] <hrw> infinity: right
[06:49] <cjwatson> 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.
[07:12] <bryceh> cjwatson, did you see bug #1061969?
[07:13] <cjwatson> 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] <bryceh> cjwatson, any issue if I proceed with the sync?
[07:13] <cjwatson> bryceh: No, go ahead
[07:13] <cjwatson> (Why file bugs for syncs you don't need sponsorship for anyway?)
[07:14] <bryceh> cjwatson, because we're in freeze, for traceability if the package is held
[07:15] <cjwatson> Well, sync it and I'll accept it, anyway
[07:16] <tjaalton> is bug 1017603 valid? it's what I had in mind too
[07:16] <cjwatson> bryceh: accepted
[07:17] <cjwatson> (oops, accepted my -2ubuntu1 as well, but no harm done there)
[07:17] <cjwatson> tjaalton: the principle is valid and the Linaro guys have been working on this
[07:17] <tjaalton> cjwatson: oh cool
[07:17] <cjwatson> triaged the bug
[07:18] <tjaalton> could it be sru'd to precise too, or are such changes not acceptable?
[07:18] <bryceh> 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] <cjwatson> 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] <cjwatson> (the Debian bug system that is)
[07:19] <cjwatson> That way I'd have seen it and moved on :)
[07:19] <cjwatson> aaaaaaargh, why does my right trackpad button randomly stop working
[07:21] <bryceh> 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] <cjwatson> heh
[07:21] <cjwatson> Sorry, glad you fixed it
[07:22] <bryceh> no prob, night.
[07:33] <zyga> pitti: ping
[07:34] <zyga> pitti: two questions, same as before: can we ship python3-pyudev on the CD (for checkbox)
[07:34] <pitti> zyga: (in interview, bbl)
[07:34] <zyga> pitti: and can we upgrade that package (rdepends are empty) from 0.13 to 0.17
[07:34] <zyga> pitti: k, thanks
[07:34] <zyga> 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] <pitti> zyga: so, the marathon guys let me go :)
[07:36] <pitti> zyga: no objections, but I think pyudev is a dead end
[07:36] <pitti> zyga: we have had introspection bindings for years which work very well
[07:37] <zyga> hmm
[07:37] <zyga> so which api should I use/
[07:37] <zyga> gi + gudev?
[07:38] <zyga> pyudev has some pythonic goodness on top of raw udev, I'd rather not loose that
[07:39] <pitti> I think gi.repository.GUdev works very well, but as I said, I don't object to pyudev
[07:39] <pitti> zyga: what goodness, OOI?
[07:39] <pitti> 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] <zyga> pitti: I'll have a look at that
[07:40] <pitti> if you use this in a Qt-ish project, you might not want the additional dependencies
[07:40] <pitti> is this for checkbox?
[07:40] <zyga> pitti: well, I only used it briefly but it has python wrappers for udev devices and attributes
[07:40] <zyga> yes
[07:40] <zyga> sadly we need udev too
[07:40] <zyga> it's not merged in yet
[07:40] <pitti> "udev is not merged"?
[07:41] <zyga> the branch that depends on udev has not landed
[07:41] <zyga> https://code.launchpad.net/~zkrynicki/checkbox/usb3/+merge/127993
[07:41] <zyga> have a look at the brief discussion there
[07:42] <zyga> hmm
[07:42] <zyga> GUdev looks very similar
[07:42] <pitti> zyga: ah, you already use gi.repository.GObject, so you already have all the glib, libgirepository and pygobject dependencies anyway
[07:42] <zyga> that's right
[07:43] <zyga> 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] <pitti> zyga: http://www.freedesktop.org/software/systemd/gudev/ is the C API
[07:45] <pitti> 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] <zyga> I know the idea behing gobject introspection
[07:46] <pitti> mkdir /tmp/gudev; g-ir-doc-tool -o /tmp/gudev/ /usr/share/gir-1.0/GUdev-1.0.gir; yelp /tmp/gudev/
[07:46] <zyga> just never used it in practice
[07:47] <zyga> ohhh
[07:47] <zyga> thanks a lot
[07:47] <pitti> that's still a bit inconvenient, sorry
[07:47] <zyga> I'll try to use that instead
[07:47] <pitti> but you get the class/method name separation instead of the C-style class_name_method()
[07:48] <zyga> pitti: g-ir-doc-tool? where is that from cnf does not know about it
[07:48] <pitti> "gobject-introspection" package
[07:48] <zyga> thanks
[07:49] <pitti> oh, indeed that's not on a default install
[07:52] <zyga> pitti: which package has /usr/share/gir-1.0/GUdev1.0.gir
[07:52] <zyga> it's not in gir-1.2-gudev
[07:52] <pitti> zyga: gir1.2-gudev-1.0 is the typelib, libgudev-1.0-dev has the gir
[07:52] <zyga> ah
[07:52] <zyga> ok
[07:52] <zyga> thanks
[07:52] <pitti> (yay for confusing package names)
[07:53] <zyga> :D
[07:53] <zyga> no, it's okay
[07:53] <zyga> well
[07:53] <zyga> it's not better than anything else
[07:53] <pitti> zyga: at runtime you only need the .typelib, which is the compiled gir (which is XML and human readable)
[07:53] <zyga> I wish something like online apt-file was built into ubuntu by default
[07:53] <zyga> right
[07:56] <pitti> yeah, similar to rmadison
[07:56] <zyga> pitti: hmm it crashes on missing GObject-2.0.gir
[07:57]  * zyga looks for that
[07:57] <pitti> zyga: libglib2.0-dev
[07:58] <seb128> pitti, speaking of gobject-introspection, did you not package 1.34 on purpose?
[07:58] <seb128> (it's one of the few tarballs were we didn't upate to the stable GNOME 3.6 one)
[07:58] <pitti> seb128: oh, it might have been released late
[07:58] <pitti> seb128: doing now
[07:58] <zyga> pitti: no, I already have that
[07:59] <pitti> seb128: I'm currently updating udisks to 2.0.0 final
[07:59] <seb128> pitti, danke
[07:59] <zyga> pitti: there are no .gir files in that package
[07:59] <seb128> zyga, libgirepository1.0-dev
[07:59] <pitti> zyga: whoops, sorry; gobject/glib girs are special, what seb128 says
[08:00] <zyga> thanks
[08:00] <pitti> zyga: (glib2.0 source cannot build its own girs)
[08:09] <zyga> 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] <pitti> zyga: calling .execute() on the enumerator after setting it up will give you an iterable Python array
[08:11] <zyga> ahh, thanks, I've missed that
[08:11] <zyga> pitti: reading the docs on that
[08:11] <zyga> pitti: do I need to worry about gobject references form python?
[08:11] <pitti> no, pygobject does that for you
[08:12] <zyga> ok, cool
[08:12] <zyga> it seems to work, thanks, I'll take it form there
[08:12] <pitti> nice
[08:30] <zyga> 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] <zyga> http://www.freedesktop.org/software/systemd/gudev/GUdevDevice.html#g-udev-device-get-parent
[08:30] <pitti> zyga: indeed, it's marked as non-introspectable; presumably a missing annotation
[08:31] <zyga> ohhh
[08:31] <pitti> zyga: you can use os.path.dirname(path) to get the parent, too; but I'll investigate
[08:31] <zyga> crap
[08:32] <pitti> I'll get this fixed upstream and backport it to our udev
[08:32] <zyga> thanks
[08:51] <zyga> pitti: dirname() on which path? sysfs?
[08:51] <pitti> zyga: right, in sysfs; getting the parent dev is just that
[08:52] <zyga> cool, thanks
[08:53] <wookey> doko_: do you have guesses as to which patches might be responsible for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680439
[08:54] <wookey> don't worry if not - I'll just wait for infinity to wake up
[08:57] <pitti> zyga: ah, it's fixed upstream already, it's just that our udev is really old; I'll backport the fixes
[08:58] <zyga> pitti: good news, thanks
[08:59] <zyga> 193 vs 175
[08:59] <zyga> 194 even
[09:12] <darkxst> 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:22] <hrw> Bug #1062137 filled to get rid of old cross compilers
[09:23] <zyga> pitti: hmm, it seems I cannot just chop the path to traverse devices
[09:24] <zyga> 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] <pitti> yes, it should do that
[09:24] <zyga> 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] <pitti> zyga: (anyway, test-building udev now)
[09:25] <zyga> 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] <pitti> zyga: sure, that's the next parent
[09:25] <zyga> going higher made Client.query_by_sysfs_path() return None
[09:25] <pitti> you have to iterate through all parents
[09:25] <pitti> zyga: libudev's get_parent() really does the same -- just chop off the last path component
[09:25] <cjwatson> hrw: Thanks, I'll process that
[09:26] <zyga> pitti: so until I get all the way up to /sys?
[09:26] <hrw> cjwatson: thanks
[09:26] <cjwatson> hrw: I assume I can reject the corresponding uploads in the unapproved queue?
[09:26] <zyga> ignoring things that don't look like devices?
[09:26] <hrw> cjwatson: yes
[09:26] <cjwatson> OK, done
[09:26] <hrw> cool
[09:26] <cjwatson> Just triple-checking reverse dependencies
[09:26] <pitti> zyga: perhaps you want get_parent_with_subsystem() if you are looking for a particular kind of parent dev
[09:27] <cjwatson> Which is hard with a headache and a toddler talking to me
[09:27] <pitti> zyga: well, in kernel teams all of those are devices
[09:27] <pitti> zyga: you have to specify "what shoudl the device look like" yourself, in terms of subsystem, attributes, and properties
[09:28] <pitti> $ grep introspectable /usr/share/gir-1.0/GUdev-1.0.gir
[09:28] <pitti> $
[09:28] <pitti> zyga: ^ voila :)
[09:29] <zyga> 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] <pitti> ah, right
[09:29] <zyga> pitti: anyway, ignoring stuff that fails to create a udev device they way I said seems to work
[09:30] <pitti> zyga: right, sorry; udev's skips directories without an "uevent" file
[09:30] <pitti> 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] <jtaylor> doko_: do you have objections to syncing poco just to test if bug 903347 is fixed in quantal?
[09:31] <jtaylor> or someone here has the hardware could test it for me :)
[09:31] <zyga> pitti: awesome, thanks for the help! :-)
[09:33] <cjwatson> hrw: all right, all done now
[09:34] <pitti> dholbach, jono, dpm, jcastro_, mhall119: wohoo, > 5000! go, go, go!
[09:34] <dholbach> :-D
[09:35] <mhall119> \o/
[09:35] <jono> pitti, :-)
[09:35] <mhall119> ..zzZZ
[09:35] <dpm> pitti, \m/
[09:36] <ajmitch> jcastro_: live juju demo
[09:39] <pitti> doko_: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.71 :)
[09:40] <pitti> dholbach: who's DJing, you?
[09:41] <dholbach> pitti, very short :)
[09:41] <dholbach> just a bit
[09:49] <cjwatson> 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] <pitti> zyga: If you are anxious for the fixed packages, grab them from https://launchpad.net/ubuntu/+source/udev/175-0ubuntu12
[09:52] <tjaalton> 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] <cjwatson> tjaalton: OK, moved to universe
[09:54] <cjwatson> thanks
[10:01] <mlankhorst> cjwatson: intentional :)
[10:01] <pitti> jono, dholbach: ah, the last few minutes weren't broadcasted any more; anyway, good night! awesome job!
[10:01] <mlankhorst> but tjaalton beat me to it
[10:01] <dholbach> pitti, they were - we had to restart the hangout
[10:01] <jono> thanks, pitti!
[10:02] <jono> thanks for joining us earlier!
[10:02] <pitti> dholbach: right, I tried to reload several times, it always said "will be available soon"
[10:02] <dholbach> hum
[10:02] <pitti> jono: de rien
[10:02] <dholbach> it seems to have worked for others
[10:02] <pitti> *shrug* no biggie
[10:02] <pitti> why are you still online anyway! :)
[10:03] <pitti> james_w: hey James, how are you?
[10:04] <pitti> james_w: who can I bother about pushing buttons for UDD imports these days? (gvfs is out of date)
[10:13] <chrisccoulson> jono, have you started hallucinating yet? ;)
[10:13] <chrisccoulson> i think i would be after 24h
[10:13] <jono> chrisccoulson, getting there :-)
[10:13] <chrisccoulson> hah :)
[10:13] <cjwatson> That usually starts at around 35h for me
[10:13] <cjwatson> Not that I'm much use between 24h and 35h
[10:14] <pitti> jono: for example, you might imagine it was already over :)
[10:15] <ogra_> you guys dont take the day off, do you ? :)
[10:24] <doko_> wookey, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[10:25] <doko_> wookey, my understanding is, that this should be fixed in glibc
[10:36] <doko_> jtaylor, why? is there a fix for GCC?
[10:36] <jtaylor> don't know
[10:50] <doko_> wookey, no, apparently I'm wrong. just drop it for now
[10:58] <pitti> davmor2: FYI, I now added a gvfs test case for recognizing media players as such :)
[10:58] <pitti> davmor2: this broke $DEITY knows how many times already..
[10:59] <davmor2> 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?
[11:01] <pitti> davmor2: yes, very close to gnome bug 631809
[11:01] <davmor2> pitti: I'm just happy that I have my sansa fuse to keep testing it is broken or not hopefully now :)
[11:01] <pitti> davmor2: these bugs apply to any media player, though (same for my xperia mobile)
[11:02] <davmor2> pitti: indeed
[11:03] <davmor2> 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] <pitti> davmor2: my fix from yesterday to detect them at all already went upstream
[11:03] <pitti> icons and volume names still need to be fixed, that's on my list
[11:04] <pitti> (and now that's trivial to test)
[11:04] <davmor2> pitti: cool :)
[11:08] <zyga> pitti: thanks
[11:13] <davmor2> pitti: on a plus side the system thinks I have a music player WooHOO!!!!
[11:29] <ogra_> 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] <cjwatson> That's the exact meaning of Conflicts
[11:30] <ogra_> k
[11:30] <ogra_> no need to use replacess i guess
[11:30] <cjwatson> Not in general but you might want to if one of the two is going away
[11:31] <cjwatson> The policy manual has detailed advice
[11:31] <ogra_> by going away you mean that the other package then comes in as a replacement ?
[11:31] <ogra_> thats definitely not waht i want ...
[11:31] <ogra_> *what
[11:32] <cjwatson> for example
[11:36] <cjwatson> pitti: is the stack of language pack uploads yours?
[11:41] <cjwatson> pitti: Never mind, looks like a straightforward update so I'll just accept it all
[11:42] <pitti> cjwatson: (OTP) presumably from the automatic cronjob
[11:42] <cjwatson> OK
[11:45] <jamespage> @pilot in
[13:19] <pitti> ev: hey Evan
[13:19] <ev> hi Pici
[13:19] <ev> pitti even
[13:19] <pitti> ev: I assigned a bug to you this morning about unpacking xz debs not working any more
[13:19] <ev> yikes, on it
[13:19] <pitti> ev: it seems that none of our three implementations gets it right :(
[13:20] <pitti> 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] <ev> pitti: how does dpkg -x deal with symlinks?
[13:20] <ev> or dpkg -i?
[13:20] <ev> dpkg -i notices that there's something there already and happily carries on
[13:21] <pitti> ev: or whichever bug you wanted to fix by moving to python-debian/apt_inst
[13:22] <cjwatson> dpkg -x should extract symlinks perfectly normally
[13:22] <ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1059621
[13:23] <cjwatson> the random package I have to hand that contains symlinks extracts just fine
[13:23] <ev> 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] <ev> thus the "tar: ./usr/share/doc/gnat-gps: Cannot create symlink to `gnat-gps-common': File exists"
[13:24] <cjwatson> that looks like an outright bug in the package to me, really
[13:25] <cjwatson> gnat-gps-common should put features.gz and known-problems.gz in /usr/share/doc/gnat-gps-common/, not gnat-gps/
[13:25] <cjwatson> the way it is right now, even with dpkg -i it's probably nondeterministic what ends up in gnat-gps/
[13:26] <ev> hmm
[13:26] <cjwatson> Debian #684194
[13:27] <ev> pitti: do you think we should back out the change and consider these unretraceable?
[13:27] <ev> cjwatson: massive, massive thanks
[13:28] <cjwatson> (so fixed in quantal, I believe)
[13:28] <cjwatson> might not be totally insane to SRU that fix
[13:34] <smoser> jodh, around ?
[13:35] <smoser> 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.
[13:35] <smoser> that, in turn, hoses anything that has 'console output'.
[13:36] <smoser> is there any way in upstart to fix that case?  ie, if stdout gives io error when written to, try somewhere else.
[13:46] <pitti> ev: works for me
[13:48] <jodh> smoser: what console= kernel param are you specifying
[13:48] <jodh> smoser: ?
[13:48] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977/comments/4 has more info
[13:48] <smoser> i'm specifying "console=tty1 console=/dev/ttyS0" which tells the kernel to make /dev/console == /dev/ttyS0
[13:49] <smoser> but /dev/ttyS0 might not actually be a device.
[13:49] <ogra_> smoser, sudo in an upstart job ?
[13:50] <smoser> where do you see that?
[13:50] <smoser> ah. that was just an example.
[13:50] <ogra_> ahm, thats only manual test code ?
[13:50] <jodh> smoser: I thought that meant redirect console output to *both* devices? One sec...
[13:50] <smoser> saying /dev/ttyS0 is busted.
[13:50] <smoser> err... /dev/console.
[13:50] <smoser> jodh, it sends kernel messages to both devices
[13:50] <ogra_> hmm, it shoudlnt
[13:50] <smoser> but /dev/console is not a multiplexer. "last one wins"
[13:51] <ogra_> the second console= option is ususally handed to userspace
[13:51] <smoser> ogra_, right.
[13:51] <ogra_> while the first one is used for kernel messages
[13:51] <smoser> no.
[13:51] <ogra_> (if you actually use two)
[13:51] <smoser> kernel messages go to both.
[13:51] <smoser> user space gets the last.
[13:51] <ogra_> they shouldnt
[13:51] <smoser> the doc and experience say otherwise :)
[13:51] <jodh> smoser:
[13:51] <jodh> You can specify multiple console= options on the kernel command line.
[13:51] <jodh> Output will appear on all of them. The last device will be used when
[13:51] <jodh> you open /dev/console.
[13:52] <jodh> smoser: so, trying changing the order.
[13:52] <smoser> jodh, yeah, that will work.
[13:52]  * ogra_ has never seen the kernel output to more than one tty
[13:52] <jodh> smoser: that was from Documentation/serial-console.txt in the kernel fwiw.
[13:52] <smoser> jodh, i liked to that.
[13:52] <smoser> linked to that
[13:53] <smoser> jodh, my problem is that if i do that, i will *never* (well, 98% of never) get /dev/console == /dev/ttyS0.
[13:53] <seb128> 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] <smoser> which is better in the case where there *is* a ttyS0
[13:54] <smoser> 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] <smoser> but upstart could potentially recognize that its stdout is busted.
[13:55] <smoser> and i could potentially tell upstart (configuration or kernel cmdlines) "if your stdout is busted, try others in this order"
[13:55] <jodh> 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] <ogra_> you can surely work around it in /init in the initrd
[13:56] <jodh> smoser: ... where the device is passed in as a job param maybe or config variable?
[13:56] <ogra_> (theoretically it does that already)
[13:56] <smoser> ogra_, well, i sort of could.
[13:56] <jodh> smoser/ogra_: but do you even need an initrd for those cloud images I wonder.
[13:57] <smoser> i could set init's stderr, stdin, stdout to something other than /dev/console if /dev/console was busted, yes.
[13:57] <smoser> and that would be essentially the same as having upstart do it.
[13:57] <ogra_> just easier to hcak it into the shell script :)
[13:57] <smoser> jodh, we like initrd.
[13:58] <ogra_> *hack
[13:58] <smoser> ogra_, right.
[13:58] <ogra_> jodh, you neeed one if they use root=UUID=
[13:58] <ogra_> our kernel cant mount by UUID
[13:58] <jodh> ogra_: I know
[13:58] <smoser> i was hoping that from user space i could tell the kernel "please re-assign /dev/console to be /dev/tty0"
[13:58] <smoser> but it seems not possible.
[13:58] <smoser> ogra_, jodh we like initrd.
[13:59] <smoser> we do clever, valuable things there.
[13:59] <ogra_> ++
[13:59] <ogra_> thats what its for ;)
[13:59] <smoser> (iscsi root, overlayroot, grow a partition)
[13:59] <ogra_> yep
[14:00] <smoser> so, yeah, in the initramfs i coudl change 'exec >/dev/console 2>&1 </dev/console' to be 'exec >$MYDEVICE ... '
[14:00] <smoser> but writes explicitly to /dev/console would still fail.
[14:00] <ogra_> hmm, i would rather look for why you cant write to it and fix that
[14:01] <smoser> hm..
[14:01] <smoser> jodh, one question.
[14:01] <smoser> the doc for upstart says: [console] output: If output is specified, the standard input, standard output and standard error file descriptors are connected  to /dev/console.
[14:01] <smoser> is that really mean "by convention"
[14:02] <smoser> or does upstart explicitly close stdin/stdout/stderr and re-open them from /dev/console
[14:02] <smoser> (in which case i cannot hack in the initramfs)
[14:02] <jodh> smoser: it actually closes and reopens.
[14:02] <smoser> so i can't workaround in initramfs
[14:03] <smoser> ogra_, yeah, i meant where $MYDEVICE is the result of a search.
[14:03] <smoser> but i dont think that will work anyway.
[14:05] <ev> seb128: https://errors.ubuntu.com/bucket/?id=/usr/lib/indicator-datetime/indicator-datetime-service%3A11%3Ae_client_open_sync%3Aupdate_appointment_menu_items%3Ag_closure_invoke%3Asignal_emit_unlocked_R%3Ag_signal_emit_valist
[14:05] <smoser> well, i can't seem to see any solution other than removing console=ttyS0 as a default parameter.
[14:05] <seb128> ev, I wonder why it has 1 instance where launchpad has 6 duplicates, whoopsie is supposed to bring more report than successful launchpad retraces no?
[14:05] <smoser> which means that "by default" systems that would have logged ttyS0 will get no messages written to them at all if they have a vga device.
[14:06] <smoser> :-(
[14:06] <KRF> could someone please have a look at https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1036283 ?
[14:06] <ev> seb128: indeed, I'm curious about that as well. It is *possible* - they might have whoopsie in a stopped state. But it seems unlikely.
[14:06] <ogra_> smoser, oh, coudl it be that you have a job anywhere that has "console owner" ?
[14:06] <smoser> console output
[14:06] <ogra_> console will get detached from the tty for that
[14:07] <ogra_> if any job cals it
[14:07] <ev> seb128: I've made a note to dig into that deeper
[14:07] <smoser> possible. but i have 'console output' on my jobs.
[14:07] <seb128> ev, thanks
[14:07] <ev> sure thing
[14:07] <smoser> which, seems to mean /dev/console even if that is busted.
[14:07] <ogra_> smoser, well there might bew jobs you didnt add :)
[14:07] <smoser> oh well.
[14:07] <smoser> right.
[14:07] <smoser> but why would that matter?
[14:08] <smoser> at least i dont care about those jobs at the moment.
[14:08] <ogra_> i just noticed that my tty's die if console owner is set (and respawn due to their job)
[14:08] <smoser> well, ogra_ jodh thanks for the discussion.
[14:09] <smoser> it seems to me the only way to do this would be to be able to tell the kernel "hey, could you make /dev/console point somewhere else please"
[14:09] <smoser> and have that work even with open filehandles
[14:09] <smoser> well, maybe in the initramfs i could get all /dev/console closed.
[14:16] <smoser> hm.. i guess the other hting i could do is kexec from initramfs.
[14:37] <doko> mvo: can you just black-list pentium-builder for command-not-found? see bug #1062043
[14:41] <mvo> doko: yeah
[15:06] <doko> pitti, seb128: would be nice if somebody could look at libgtk2-perl, bug #1056811. update needed for gtk changes?
[15:08] <pitti> c'est un travail pour l'équipe de desktop :)
[15:09] <pitti> oui, Monsieur Bacher?
[15:09] <pitti> mvo: so we still have libgtk2-perl for debconf?
[15:10] <seb128> pitti, on dirait oui ...
[15:10] <seb128> doko, I will try to have a look, no promise today though, release team meeting just started and it will be 6pm after the meeting
[15:11] <doko> it's the last real build failure in main
[15:12] <pitti> Riddell: ah, so we should remove language-pack-* from quantal, except for the ones you created manually?
[15:12] <seb128> doko, kick a build while the meeting is ongoing, let's see
[15:12] <Riddell> pitti: yes I think so
[15:12] <doko> well, maybe except for webkit on arm
[15:12] <Riddell> pitti: including the base ones
[15:13] <Riddell> I guess
[15:13] <pitti> Riddell: that's all except language-pack-kde-{engb,zhcn,zhtw}?
[15:13] <Riddell> pitti: I've removed language-pack-kde-{engb,zhcn,zhtw} already
[15:14] <Riddell> pitti: here's the ones I make http://paste.kde.org/562928/
[15:14] <pitti> Riddell: ah, thanks; so I'll remove all but those
[15:16] <Riddell> pitti: thanks
[15:17] <mvo> pitti: I think so - if we want to support debconf gtk dialogs
[15:17] <mvo> pitti: still in the suggests line of debconf, but TBH i haven't payed much attention to debconf lately
[15:26] <smoser> can i get someone from SRU team to look at https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=cloud-init please ?
[15:26] <smoser> i have other things in cloud-init that are fairly high priority to get fixed in 12.04 and i need that ximple fix through the queue sooner rather than later.
[15:27] <pitti> Riddell: oh, bloody CRLF line endings on pastebin
[15:28] <pitti> Riddell: I was staring at my join command for 5 minutes, wondering why it didn't work
[15:28] <Riddell> pitti: I know, I really should report that to the kde sysadmins
[15:28] <pitti> Riddell: http://paste.ubuntu.com/1262096/
[15:29] <pitti> command and output, this would be the "to kill" list
[15:29] <Riddell> pitti: looks right
[15:31] <pitti> Riddell: could you add Conflicts to the -base packages to the transitionals, to get them cleaned up on upgrade?
[15:33] <Riddell> pitti: can do
[16:39] <cjwatson> pitti,seb128: if you guys can't figure out the libgtk2-perl failure I expect I'll take a look at it on Monday and see if any of the recent upstream changes help
[16:39] <cjwatson> I hadn't been going to ask you to support it because I know how much you love the perl bindings
[16:40] <seb128> cjwatson, I indeed *love* perl :p
[16:40] <seb128> cjwatson, I started looking at it but the test seems to run fine when ran manually
[16:40] <cjwatson> in an sbuild chroot?
[16:40] <seb128> cjwatson, I will poke a bit longer to it today but I don't figure it out help on monday would be welcome
[16:41] <seb128> cjwatson, no, on my box, but the package build hangs on the same environment
[16:41] <seb128> well "same environment", the package run through fakerook, xvfb, etc
[16:48] <wookey> infinity: libc_extra_config_options = --with-selinux $(extra_config_options) which ends up coming after the --without-selinux in the eglibc stage1 build and turning selinux back on.
[16:49] <wookey> any idea where the right place to fix that is?
[16:49] <wookey> in 2.15 libc_extra_config_options = $(extra_config_options)
[16:49] <wookey> so it worked
[16:54] <infinity> wookey: Oh, has aurel turned on selinux unconditionally in 2.16?
[16:54] <wookey> apparently
[16:54] <wookey> which may well be OK for normal builds, but not bootstrapping
[16:55] <cjwatson> seb128: Yeah, hangs for me too in sbuild, at least
[16:56] <infinity> ifeq ($(DEB_STAGE),stage1)
[16:56] <infinity>     libc_extra_config_options = $(extra_config_options) --without-selinux
[16:56] <infinity> endif
[16:56] <infinity> ?
[16:57] <wookey> seems sensible.
[17:01] <micahg> could someone familiar with objective c binary dependencies take a look at this bug for me and see if my concerns are valid or not?
[17:01] <micahg> Bug #1051389
[17:50] <mlankhorst> who handles apt bugs?
[17:50] <KRF> could somebody take care of https://bugs.launchpad.net/bugs/1036283 please?
[17:51] <KRF> that's a pretty trivial fix
[17:51] <mlankhorst> hitting a weird bug in apt that seems multiarch related
[17:57] <cjwatson> mlankhorst: normally mvo
[18:20] <mlankhorst> ah what time is he on?
[18:20] <mlankhorst> I was hitting a bug switching stacks but it kind of looks like I've hit that one before
[18:30] <slangasek> mlankhorst: Europe/Berlin; but if you can describe the problem perhaps someone else can help
[18:30] <Darxus> A sensors-applet package is "waiting in New for approval".  It got an FFE.  What needs to happen?  Is there any part of that I can see?  Bug 1049343.
[18:32] <mlankhorst> slangasek: basically I am working on q-lts-backport in ~mlankhorst/ppa, but switching between normal and other stack with apt-get install xserver-xorg-lts-quantal libgl1-mesa-{glx,dri}-lts-quantal{,:i386} is broken and dies on swapping out libglapi
[18:32] <slangasek> ok, what's the error?
[18:32] <mlankhorst> just that libglapi-mesa-lts-quantal is extracted for i386, then it dies on trying to extract libgl1-mesa-glx-lts-quantal which requires that package for 64-bits
[18:33] <slangasek> please show the exact apt output
[18:33] <mlankhorst> with problem resolver debug enabled http://paste.ubuntu.com/1262441/
[18:34] <mlankhorst> sadly in dutch but should still be understandable
[18:34] <smoser> infinity, it would appear to me that the last upload of software-properties did not fix
[18:34] <smoser> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060335
[18:34] <infinity> smoser: Erk.  It fixed it when I tested...
[18:35] <smoser> look at the comment there. comment 5. i'm fairly sure i didn't make a user error of some sort.
[18:36] <slangasek> mlankhorst: English (and without the resolver debug) would be helpful, if you can reproduce this easily; the Dutch is slowing me down a bit
[18:36] <infinity> smoser: Yeah, I'm reading.  I'm just stumped as to why my testing went okay.  Maybe it was multiple runs in a row that broke something.
[18:37] <smoser> infinity, so this wasn't 100% instance.
[18:37] <smoser> i had tried once with the old version
[18:37] <infinity> smoser: Anyhow, mvo was going to land something that removed all that code and replaced it with a call into python-apt.  Maybe I should review that and give him an FFe instead of fiddling with it more.
[18:37] <smoser> but you would still need to fix that case anyway, and it surely dodn'st look like it.
[18:38] <infinity> smoser: No, having run it once with the old version shouldn't matter, it just looks like I missed one spot where I needed home-dir, from your log.
[18:38] <slangasek> mlankhorst: fwiw I don't think I've ever seen this bug before
[18:38] <infinity> smoser: (Though, I'm curious where that is...)
[18:38] <slangasek> seems to be a previously-unnoticed apt bug
[18:40] <mlankhorst> slangasek: yeah my q-lts-backports archive kind of hits the limits in many way of apt :)
[18:45] <infinity> smoser: Did you upgrade python3-software-properties as well?
[18:45] <infinity> smoser: That's what actually contains the fix.
[18:45] <smoser> i did not.
[18:45] <smoser> duh.
[18:46] <infinity> smoser: Double-check that for my peace of mind, but it should fix you up.
[18:49] <smoser> well, in a new machine with that installed it is fixed, infinity
[18:49] <mlankhorst> slangasek: but my ppa has the stack I was using, I think it worked before because of a workaround
[18:52] <james_w> pitti, oops, sorry, missed the message, you can poke me, or people from the bzr team should be able to do it
[18:53] <slangasek> mlankhorst: what kind of workaround do you mean?
[18:53] <mlankhorst> i had a conflicts on everything before
[19:00] <mlankhorst> or maybe because i only tested pure 64-bits before mostly
[19:10] <mlankhorst> shall I just file a launchpad bug?
[19:11] <slangasek> mlankhorst: yes, please
[19:25] <james_w> pitti, should be up to date now
[19:32] <mlankhorst> slangasek: bug 1062503 ?
[19:34] <slangasek> mlankhorst: attach the apt output in English, please
[19:34] <mlankhorst> slangasek: tomorrow :P
[19:34] <slangasek> ok
[19:34] <mlankhorst> ah who am I kidding, got nothing better to do, sec breaking my system again
[19:38] <mlankhorst> there
[19:40] <micahg> slangasek: infinity: either of you familiar with binary dependencies for objective C apps?
[19:40] <slangasek> moreso than I would like?
[19:41] <micahg> can you look at Bug #1051389 to tell me if I'm right or wrong?
[19:43] <slangasek> micahg: ok, hmm; I've never heard this before at all
[19:43] <micahg> heh, ok, I don't feel so bad now :)
[19:44] <micahg> but I'm quite unsure of where to go from here as sogo 1.3.16 is already in quantal
[19:45]  * micahg can always punt to release team...
[19:46] <slangasek> micahg: checking a random library, I can confirm that there are only symbols for the classes.  This seems quite horrid.
[19:47] <slangasek> but if sogo is broken without the new sope, seems like it ought to get in as a bugfix
[19:47] <slangasek> I'm sure both our gnustep users will be happier that way. :)
[19:49] <micahg> slangasek: so, do I have a pass from you to sync it or should I make him write an FFe?
[19:49] <ScottK> That sounded like a pass to me.
[19:49] <Laney> Yeah. Paste it in the bug for audit, and do it.
[19:50] <slangasek> yep
[19:52] <micahg> slangasek: thanks