[00:00] <slangasek> and defeat the purpose of 'console' at all in the case of cryptsetup
[00:00] <slangasek> it only wants it for prompting, not output
[00:00] <slangasek> (rather: if there's no prompting, there's no reason to output either)
[00:01] <Keybuk> does it defeat it?
[00:02] <Keybuk> not sure
[00:02] <slangasek> cryptsetup wants the console for prompting
[00:02] <slangasek> does that work with 'console output'?
[00:02] <Keybuk> yeah, but does it need to have it as the controlling terminal?
[00:03] <Keybuk> sure, the difference between the two is whether you get signals from the console driver
[00:03] <slangasek> ok, then perhaps not
[00:03] <Keybuk> if cryptsetup doesn't need SIGHUP, SIGINT, SIGTSTP, etc. it should be ok
[00:03] <Keybuk> but I still don't like the idea of cryptsetup prompting for a passphrase while X is running
[00:03] <Keybuk> sits badly with me
[00:04]  * jdong watches some funky policykit-gnome-auth-handler-thingie arise out of this discussion...
[00:04] <Keybuk> god know
[00:04] <Keybuk> god no even
[00:04] <jdong> haha joking :)
[00:04] <slangasek> Keybuk: no, I agree, I think we either need cryptsetup to block X until it's done, or die when the dm starts
[00:04] <Keybuk> right
[00:05] <Keybuk> but then I start to wonder whether the same shouldn't really be true of mountall as well
[00:05] <Keybuk> should we really be checking filesystems behind X ?
[00:06] <slangasek> perhaps not... but mountall is trickier because it may be running waiting for remote filesystems and there's no way presently to distinguish that from the "going to fsck" case?
[00:06] <slangasek> I guess it could emit a "no more fsck" signal
[00:07] <slangasek> anyway, is mountall getting fixed to talk to usplash for karmic so people don't get into a reboot loop wondering why their systems have hung at boot?
[00:07] <Keybuk> doesn't cryptsetup use X already?
[00:07] <Keybuk> err
[00:07] <Keybuk> I mean use usplash already?
[00:08] <slangasek> should do
[00:08] <slangasek> but you're the one who added the 'console owner' upstart job, so I don't know :)
[00:09] <Keybuk> yeah I think that was wrong of me ;)
[00:09] <slangasek> heh :)
[00:11] <Keybuk> writing an operating system is *hard&
[00:13] <crypt-0> anyone know how to prevent malicious hardware initialization while im away?
[00:13] <crypt-0> is stopping hald while im good enough?
[00:14] <Keybuk> crypt-0: turn off the machine?
[00:14] <chrisccoulson> i would go one further and unplug it from the wall
[00:15] <chrisccoulson> just in case it switches itself back on again
[00:15] <Keybuk> chrisccoulson: I was being serious ;) rather than just joking
[00:15] <slangasek> right, you only need to disable wake-on-lan for the latter
[00:15] <chrisccoulson> Keybuk - i wasn't sure if you were being serious or not ;)
[00:17] <cjwatson> Keybuk: I wonder if it would make sense to use usplash's bogl backend on KMS
[00:17] <Keybuk> cjwatson: isn't it only 16-colour?
[00:17] <cjwatson> 256
[00:18] <cjwatson> I don't think that's intrinsic anyway, depends on the framebuffer type
[00:18] <Keybuk> hmm
[00:18] <Keybuk> how easy would it be to test? :p
[00:19] <slangasek> is the current problem KMS-specific?
[00:19] <crypt-0> Keybuk, besides turning off the machine
[00:19] <slangasek> or would we need another solution for !KMS cryptsetup users?
[00:19] <Keybuk> current problem?
[00:19] <Keybuk> crypt-0: if you want to avoid attack, powering off the machine is the only solution
[00:19] <slangasek> Keybuk: the bug number I cited 800 lines ago?
[00:19] <cjwatson> Keybuk: I think you just need to nobble uplash_setup_func
[00:19] <Keybuk> I don't think bogl vs. svgalib is relevant here
[00:19] <cjwatson> usplash_setup_funcs
[00:19] <crypt-0> Keybuk, why wont stopping hald work?
[00:19] <cjwatson> apparently my  key is a bit wonky
[00:20] <crypt-0> Keybuk, can i PM you?
[00:20] <Keybuk> crypt-0: no.
[00:23] <Keybuk> crypt-0: seriously though, there's no way to disable things against malicious use short of powering down the box
[00:23] <Keybuk> crypt-0: assumedly you're leaving it up so you can access
[00:23] <Keybuk> crypt-0: well, so can naughty people
[00:24] <Keybuk> (and for the exact question you were asking, hardware configuration and activation is largely performed by the kernel - which you kinda need running <g>)
[00:24] <Keybuk> so my answer was correct
[00:29] <LaserJock> am I supposed to have green check marks on all my files?
[00:29] <TheMuso> LaserJock: Known, its an UbuntuOne bug.
[00:29] <LaserJock> oh
[00:29] <LaserJock> can  I just uninstall UbuntuOne and it'll go away?
[00:29] <TheMuso> I guess so, I don't know for sure./
[00:32] <crypt-0> is there a way to "lock" the kernel?
[00:33] <crypt-0> as in make no hardware initialization possible without x password
[00:34] <sladen> urm.  Don't load the kernel?
[00:35] <Keybuk> bryce, tjaalton: either of you around?
[00:35] <bryce> I am
[00:35] <Keybuk> bryce: how do I make nouveau work?
[00:35] <sladen> crypt-0: you will *require* the kernel have have initialised various bits of hardware in order for you to interact with the machine
[00:36] <bryce> Keybuk, first you must have the right hardware
[00:36] <Keybuk> bryce: I have an nvidia ;)
[00:36] <Keybuk> [    7.994703] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086700a2)
[00:36] <Keybuk> [    7.994981] [drm] Initialized nouveau 0.0.15 v2.6.31-rc6-539-ged53f9fcabd42f004 for 0000:01:00.0 on minor 0
[00:36] <Keybuk> I have that in dmesg
[00:36] <pwnguin> lspci is smarter
[00:36] <bryce> Keybuk, seriously, in my testing I've found so many card-specific bugs that I ended up giving up trying to make it the default driver for us
[00:37] <Keybuk> bryce: I want to try something out with usplash which needs mode setting
[00:37] <pwnguin> Keybuk: right now I use xorg.conf
[00:37] <pwnguin> Driver "nouveau"
[00:38] <bryce> pwnguin, you using any special kernel?  xorg-edgers?
[00:38] <Keybuk> X isn't smart enough to use nouveau automatically?
[00:38] <bryce> Keybuk, re: my comment about defaults on karmic
[00:38] <lifeless> its smart enough not to :P
[00:38] <Keybuk> bryce: even if you've loaded the nouveau module?
[00:38] <pwnguin> Keybuk: smart enough is the wrong phrase. crazy enough is the rgiht one
[00:38] <bryce> there was a patch floating around to make it try nouveau first if installed, then -nv if failed, but don't know the status on that
[00:39] <pwnguin> bryce: honestly, i switched to nvidia a few weeks ago to try out 3d accelleration of unr
[00:39] <bryce> Keybuk, in any case, that's a pretty minor issue, like pwnguin says it's sort of a box of chocolates at the moment
[00:39] <crypt-0> sladen, right but if hald inst running "evil" hardware cant be intilizied right?
[00:39] <pwnguin> bryce: but until then it'd been running nouveau on karmic
[00:39] <Keybuk> bryce: ok
[00:39] <Keybuk> bryce: if I have nouveau modeset=1 will X burn in flames?
[00:40] <pwnguin> no clue
[00:40] <pwnguin> err
[00:40] <bryce> pwnguin, was this stock karmic or were you using one of our special ppas?
[00:40] <Keybuk> crypt-0: evil hardware will still be initialised, the kernel does the initialisation
[00:40] <pwnguin> bryce: i believe it's stock. might have what's his name's ppa
[00:40] <pwnguin> RAOF?
[00:40] <bryce> ah yes
[00:40] <bryce> Keybuk, I'd certainly wear flame retardant underware
[00:40] <pwnguin> anyways, it's at home and im not
[00:40] <bryce> I think it's nouveau.modeset=1 btw
[00:41] <Keybuk> right
[00:41] <pwnguin> its probably time for me to turn off the nouveau hilight on irssi
[00:41] <pwnguin> im not smart enough to handle it
[00:41] <bryce> apw also had a special kernel built for us with updated nouveau bits, although I think by now that's all in the stock kernel
[00:42] <crypt-0> Keybuk, but wont it be "ignored" rendering it useless?
[00:42] <crypt-0> Keybuk, how about killing dbus?
[00:42] <Keybuk> crypt-0: no, it will not be ignored
[00:43] <Keybuk> killing dbus won't help you either
[00:43] <Keybuk> frankly, you're being rude now
[00:43] <Keybuk> you asked us a question, we gave you answer
[00:43] <Keybuk> we're not lying to you
[00:43] <bryce> https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
[00:43] <bryce> that's it... but looks like it's probably way out of date now
[00:44] <crypt-0> Keybuk, so there is no software solution then. Will have ti implement a hardware one
[00:44] <bryce> in any case, was buggy as hell when I tested it on a few cards, but the intro directions might be useful
[00:44] <Keybuk> crypt-0: there's already a hardware solution - it's the plug on the wall
[00:45] <crypt-0> Keybuk, i know, but i like to run my pc 24.7
[00:45] <Keybuk> crypt-0: your electricity supplier loves you
[00:45]  * walters likes the "kill dbus" solution to arbitrary problems
[00:46] <crypt-0> Keybuk, rmod <drivers_for_evil_hardware>
[00:46] <Keybuk> walters: "kill init" works well ;)
[00:47] <crypt-0> Keybuk, correct me if im wrong, but blacklisting and unloading every kernel module for anything hot-swappable excapt for PS/2 should do it , but its a rater crude way of doing it
[00:48] <lifeless> crypt-0: if you don't trust the hardware don't use the machine.
[00:48] <Keybuk> crypt-0: PCI is hot swappable, as is USB
[00:48] <lifeless> crypt-0: its extremely simple.
[00:48] <Keybuk> in fact, Linux supports hot-swappable CPUs
[00:48] <Keybuk> so good luck with *that*
[00:49] <crypt-0> no need for USB. my mobo doenst support PCI hot swap
[00:49] <Keybuk> crypt-0: you'd need a custom kernel though, ours has the USB host drivers built-in
[00:50] <crypt-0> Keybuk, for example with a "live image hack tool" wouldnt you need to root the system?
[00:51] <crypt-0> (no DMA for anything hot-swappable is already applied)
[00:51] <Keybuk> crypt-0: always assume that's possible
[00:51] <crypt-0> Keybuk, but if your sys gets rooted, arent you owned anyway?
[00:56] <slangasek> LaserJock: this edubuntu karmic livefs build failure looks kinda edubuntu-specific, like it doesn't want to install the default kernel or something?
[00:57] <LaserJock> slangasek: for which build?
[00:58] <slangasek> LaserJock: edubuntu/karmic/amd64, email just came in
[00:58] <sladen> crypt-0: r00ted == 0wned.
[00:58] <slangasek> (not on the website yet)
[00:59] <LaserJock> slangasek: k
[00:59] <LaserJock> slangasek: I wouldn't think that'd be edubuntu-specific. Could it be that the build caught the archive at a bad time?
[01:00] <LaserJock> slangasek: we don't do anything with the kernel I don't think
[01:00] <slangasek> LaserJock: possible; let me double-check, then
[01:01] <crypt-0> sladen, i know, there is no point to protecting against any attack if your rooted...
[01:02] <crypt-0> unless the evil hardware is what roots you
[01:03] <sladen> crypt-0: unplug the evil hardware.  It's not forcing you to use it
[01:04] <sladen> crypt-0: if you're running Free Software, you've got the source code and are free to analysis.  If you're choosing to run on hardware you don't have source code for, then that's a risk you are *choosing* to take
[01:05] <slangasek> LaserJock: can't reproduce the problem locally, so I don't know
[01:05] <slangasek> LaserJock: can try to respin in a bit
[01:06] <LaserJock> slangasek: ok
[01:10] <crypt-0> sladen, evil hardware such as in a hackers laptop plugged into my USB port
[01:11] <Keybuk> I go test usplash now
[01:12] <crypt-0> ive seen windows machines rooted from something like a hackers laptop,
[01:14] <sladen> crypt-0: I'd care if somebody had a firewire cable... unsolicated incoming DMA
[01:15] <sladen> crypt-0: if you can't unplug the USB hardware, get some superglue and bung it up
[01:15] <cjwatson> LaserJock: I've committed a cdimage fix which might sort out Edubuntu on the next build, so please shout if it doesn't (unfortunately I'm probably not going to have enough attention to check myself)
[01:16] <LaserJock> cjwatson: no problem, I'll let you know
[01:16] <virtuald> Turn off all ports and DVD etc in BIOS setup then though the computer wouldn't be very useful
[01:17] <virtuald> That includes network
[01:18] <cjwatson> LaserJock: thanks
[01:21] <crypt-0> sladen, i have no firewire, its de-soldered
[01:23] <sladen> crypt-0: cricky.  +1.  That is paranoid
[01:40] <Keybuk> cjwatson: well, this is truly fascinating
[01:42] <crypt-0> sladen, what use is disk crypto if any script kiddie can crack your system wide open with thier laptop?
[01:43] <ion> If you give an attacker physical access, you’re screwed.'
[01:45] <jdong> I still haven't seen any reasonably plausible demonstrations of how SHA1 in this case comprises a major vulnerability
[01:55] <Keybuk> bryce: well, that's nice
[01:55] <Keybuk> usplash uses bogl with noueveau too ;p
[02:05] <Amaranth> Keybuk: are you subscribed to 'boot' bugs just because people like to file boot issues there or do you actually use it? :)
[02:06] <Keybuk> Amaranth: because people like to file boot issues there
[02:06] <Keybuk> I have never knowingly known anything about 'R'
[02:07] <Amaranth> hehe, figured
[02:07] <Keybuk> including why 'R' maintainers think namespaces only happen to other people
[02:08] <ion> Well, R isn’t even a word. “A” would be a better name.
[02:10] <cjwatson> I'm pretty sure I objected to R's namespacing on debian-devel in like 2002 or something
[02:13] <lifeless> the way its packaged, or some internal of its implementation?
[02:15] <Keybuk> slangasek: around?
[02:15] <Keybuk> can you remember why we decided to unconditionally load vesafb?
[02:16] <nixternal> cjwatson: I take it dirk objected to your naming? :)
[02:16] <geofft> is it just me or is packages.ubuntu.com down? (port 80 closed)
[02:17] <nixternal> he sure loves his R
[02:17] <nixternal> geofft: there are a few machines that are experiencing issues...I just ran across a bug report for p.u.c so it is known
[02:17] <geofft> okay, thanks
[02:17] <nixternal> keyserver is another one with issues
[02:18] <cjwatson> lifeless: the binary packages have r-cran-* namespacing; the source packages typically do not, hence 'boot' (binary: 'r-cran-boot')
[02:18] <slangasek> Keybuk: ... was I around when that decision was made?
[02:18] <cjwatson> there was some excuse about "boot" being the upstream name
[02:18] <Keybuk> slangasek: yup
[02:18] <Keybuk> I have a feeling it got noted down somewhere with a ? and the ? got lost, so we force load it
[02:18] <slangasek> Keybuk: well, I don't think I was party to the decision...
[02:18] <Keybuk> I was talking at you :)
[02:18] <slangasek> hmm :)
[02:18] <Keybuk> you were being a teddy bear
[02:19] <Keybuk> I wondered if you could remember *why* I did that
[02:19] <d3xter> hey guys
[02:19] <d3xter> is anyone here?
[02:20] <LaserJock> cjwatson: yeah, I remember when I was doing MOTU Science we got a ton of mis-filed bugs :-)
[02:20] <Keybuk> d3xter: no
[02:20] <d3xter> alright ^^
[02:23] <d3xter> well, one of my friends tryed to install nvidia 185 on 9.04, but the installation messed up, so he tried to get back to 180, but the links libGL and libGLcore still remained at the 185 versions of this libraries
[02:23] <d3xter> is there any way, so that other users dont get stuck with this problem?
[02:24] <Keybuk> usplash hates me
[02:27] <Keybuk> I bet it's pitti's fault
[02:30] <lifeless> cjwatson: ughhhhh
[02:35] <Keybuk> that's interesting
[02:35] <Keybuk> it is *kinda* pitti's fault ;)
[02:36] <Keybuk> the problem isn't that the console is screwed
[02:36] <Keybuk> the problem is that usplash isn't exiting
[02:36] <Keybuk> but you can't tell that, because he's set the entire palette to a trendy black-on-black :p
[02:37] <exarkun> I seem to find the ?no-redirect thing for filing Ubuntu bugs offensive somehow.
[02:38] <exarkun> It doesn't help that it combines with the frequent timeout bug in a way which probably makes it even harder to report bugs against Ubuntu than whoever came up with the idea intended.
[02:38] <exarkun> timeout, hit back, get bounced back to the wiki page asking for people to not report bugs
[02:39] <exarkun> I almost gave up and didn't report this bug that I'm now going to report
[02:39] <ScottK> exarkun: #ubuntu-bugs is probably the best channel for feedback on that decision.
[02:39] <exarkun> I'm sure the average Ubuntu user wouldn't have gotten nearly this far
[02:41] <exarkun> ScottK: This is about barrier to participation.  And as a demonstration, I'm afraid I'm going to have to decline to join #ubuntu-bugs and re-complain about it there.  If no one here cares enough to pass on the message, then I guess the feedback will be lost and the community will suffer.  Or maybe not even notice.  Beats me.  Anyway, this has already taken twice as long as I expected, I'm not going out of my way to find more work.
[02:41] <Keybuk> exarkun: we've been shouting about the message ourselves
[02:42] <ScottK> exarkun: It wasn't anyone here who made that decision.  You are declining then to discuss it with the people that can do something about it.  Not very effective.
[02:43] <exarkun> ScottK: Yes, it's too bad.
[02:43] <exarkun> My bug is filed.  Good night.
[02:45] <LaserJock> hmm
[02:45] <LaserJock> well I wish everything was that easy
[02:49] <Keybuk> :-)
[02:56] <ion> Hereby world peace has been achieved. Good night.
[02:58] <StevenK> Ah ha! 2.6.31-14 did hit universe. Thanks for making that helpful to find out, LP.
[03:06] <Keybuk> ok
[03:06] <Keybuk> so usplash is getting SIGTERM ok
[03:06] <Keybuk> and is exiting
[03:06] <Keybuk> but is not unpainting the screen
[03:06] <Keybuk> or changing the console
[03:06] <Keybuk> or, in fact, anything
[03:08] <hyperair> StevenK: it did?
[03:08] <StevenK> hyperair: Yup
[03:08] <hyperair> er where does it say?
[03:08] <hyperair> i only see it in main
[03:08] <StevenK> I can see the kernels themselves in universe.
[03:08] <hyperair> huh?
[03:09] <hyperair> link?
[03:09] <StevenK> hyperair: I can't give you a link, I'm doing it from a shell on the archive master.
[03:09] <hyperair> aah i see
[03:10] <hyperair> but why are there kernels in universe?
[03:10] <StevenK> They aren't supposed to be
[03:10] <slangasek> Keybuk: do you have a way to reliably reproduce the X+cryptsetup conflict bug?  I've never seen it here and can't reproduce it at all, regardless of what sleeps I put where
[03:11]  * hyperair doesn't understand
[03:11] <Keybuk> slangasek: I can't even get cryptsetup to work for me normally
[03:12] <lifeless> slangasek: whats the bug ?
[03:13] <slangasek> Keybuk: getting cryptsetup to work is orthogonal to reproducing the bug
[03:13] <slangasek> Keybuk: most users complaining about this aren't using crypted disks
[03:13] <StevenK> slangasek, cjwatson: The 2.6.31-14 kernel was accepted to universe, I'm just in the middle of processing it into main.
[03:13] <slangasek> well.  I /hope/ it's orthogonal... maybe you have to not be using cryptsetup to reproduce it :P
[03:14] <slangasek> StevenK: ah, sigh; thanks
[03:14] <lifeless> slangasek: is there a bug # ?
[03:14] <slangasek> lifeless: bug #439138
[03:18] <kirkland> slangasek: hey, i need to move a couple of upstart scripts from one binary package to another
[03:18] <kirkland> slangasek: should i purge it in the old package in a preinst script (conditional on the version)?
[03:19] <Amaranth> kirkland: that's what Conflicts/Replaces is for
[03:19] <kirkland> Amaranth: good call
[03:21] <TheMuso> /c/c
[03:22] <Keybuk> ok bogl is fine
[03:22] <Keybuk> it's the svga backend
[03:22] <Keybuk> which explains why intel people don't see this
[03:26] <lifeless> wow busy bug
[03:28] <Keybuk> the best ones are
[03:53] <Keybuk> hmm
[03:53] <Keybuk> that's the third screwed initramfs in a row
[04:16] <kirkland> what's the recipe for moving a file from one package to another, when both packages are going to be installed at the same time on the same system
[04:17] <kirkland> conflicts/replaces i know, more detail please
[04:17] <kirkland> (it's late)
[04:17] <Keybuk> replaces:
[04:17] <Keybuk> that's all you need
[04:17] <kirkland> Keybuk: okay
[04:17] <Keybuk> I think I just beat usplash
[04:17] <Keybuk> that's like the biggest end-of-level boss ever
[04:17]  * kirkland high fives Keybuk 
[04:18] <Keybuk> in the last four hours, I have learned more about svgalib than any human should have to
[04:18] <kirkland> Keybuk: is it 3:20am for you?
[04:18] <Keybuk> 4:20am
[04:19] <kirkland> Keybuk: prime hacking time
[04:20] <Keybuk> exactly, and this is a *good* bug
[04:20] <Keybuk> one of the ones you can really get your teeth into
[04:21] <Keybuk> ooohohhhhhh yes!
[04:21] <Keybuk> usplash just exited normally with a console flip ;)
[04:21] <Keybuk> and now I just got a getty
[04:22] <Keybuk> now the ultimate test, booting into X
[04:22] <Keybuk> then seeing if C-A-F1 works again
[04:23] <Keybuk> \o/
[04:24]  * TheMuso follows with interest. :p
[04:24] <lifeless> kirkland: replaces says 'when this package is installed take over files from that package'
[04:25] <lifeless> kirkland: so its necessary; sometimes its not sufficient,and in that case 'breaks' is wanted - not conflicts. conflicts is a last resort
[04:25] <kirkland> lifeless: thanks that makes more sense
[04:26] <kirkland> lifeless: replaces is confusing, because only a couple of files are replaced, not the whole package
[04:26] <lifeless> to determine if you need breaks:, consider 'if the old version of the other package is not upgraded will things still work'
[04:27] <lifeless> if the answer is no, you need to either breaks other << VERSION or depend other >= VERSION
[04:27] <lifeless> depending on why things wouldn't work, which is clearly situation specific
[04:27] <lifeless> if you cannot _unpack_ the packages at all at the same time, then you need conflicts: rather than breaks:
[04:29] <Keybuk> TheMuso: https://bazaar.launchpad.net/~ubuntu-core-dev/usplash/ubuntu/revision/323 if you're curious
[04:29] <kirkland> lifeless: great, thanks, that's very helpful
[04:29] <lifeless> anytime
[04:39] <slangasek> Keybuk: why intel> ah, damn, so that's why I can't reproduce it at all here
[04:41] <NCommander> Keybuk, please disregard earlier noise on a possible mountall regression; it was an unfortunate red hearing
[04:42] <Keybuk> NCommander: yes, most mountall bugs that happen before it's even started are ;)
[04:42] <Keybuk> slangasek: right, you had mode setting
[04:42] <Keybuk> mode setting uses the bogl backend
[04:42] <Keybuk> which is fine
[04:43] <slangasek> right, just means that the time I spent trying to reproduce the problem was wasted
[04:43] <slangasek> (AIUI)
[04:43] <Keybuk> yeah we never saw corrupted text on intel
[04:44] <Keybuk> if you added intel.modeset=0 to your command-line you may well have done <g>
[04:44] <NCommander> Keybuk, *cough*. I'm not very familiar with mountall. So sorry for the noise ^ 2
[04:44] <kirkland> Keybuk: what's the upstart debug variable i can set to get more verbose output in syslog?
[04:44] <Keybuk> kirkland: initctl log-priority debug ?
[04:44] <slangasek> well, I also couldn't reproduce the 100% CPU usae
[04:44] <slangasek> usage
[04:45] <Keybuk> slangasek: that's a different issue to this one
[04:45] <slangasek> should that be reproducible on intel?
[04:45] <slangasek> oh
[04:45] <slangasek> what bug # are you working on?
[04:45] <Keybuk> this was the "text consoles always corrupted and unusable, whether or not you start X" bug ;)
[04:46] <slangasek> StevenK: did you get through moving the kernel back to main?  it looks like only amd64+i386 have been fixed, maybe?
[04:46] <StevenK> slangasek: I took the binary names from the ACCEPTed .changes
[04:46] <kirkland> Keybuk: cool; i can put that anywhere in there?
[04:47] <slangasek> StevenK: on all archs?
[04:47] <Keybuk> kirkland: anywhere in where?
[04:47] <slangasek> kirkland: it's a command to be run
[04:47] <StevenK> slangasek: lpia and ia64 should have it that list too
[04:47] <Keybuk> slangasek: what is the 100% bug # ?
[04:47] <kirkland> Keybuk: oh
[04:47] <slangasek> kirkland: so you need to run it before the stuff you care about logging
[04:47] <kirkland> slangasek: thx
[04:47] <StevenK> s/ it/ hit/
[04:47] <slangasek> Keybuk: bug #439198
[04:48] <slangasek> no, that's not it
[04:48] <slangasek> Keybuk: bug #439138
[04:48] <slangasek> better
[04:49] <Keybuk> ok
[04:49] <Keybuk> I shall upload the owner -> output fix
[04:49] <StevenK> slangasek: I can pastebin the entire list of packages I touched, but I can see powerpc, ia64 in that list. Interestingly only -di bits for i386/amd64
[04:49] <Keybuk> and if that makes it go away, we know we isolated the real cause
[04:49] <slangasek> we do?
[04:49] <Keybuk> and can "improve" it later
[04:50] <slangasek> StevenK: ah.  Ok, I've punched the rest into main now; I just did it by source package, and after the next publisher run I'll demote those that aren't supposed to be in main
[04:50] <StevenK> Ah, I did the piecemeal approach.
[04:50] <slangasek> ehm, if there even are any
[04:51] <StevenK> slangasek: I think it's because the publisher hasn't run yet
[04:51] <StevenK> slangasek: Contents generation is running, which has taken over the publisher running this hour
[04:52] <slangasek> StevenK: change-override assured me that there were packages still needing their components updated
[04:52] <StevenK> Curious
[04:52] <StevenK> I'm concerned that I didn't see -di bits for !i386,amd64
[04:53] <slangasek> yeah, that's what I saw being picked up by change-override this time
[05:32] <kirkland> slangasek: i just uploaded eucalyptus_1.6~bzr931-0ubuntu1_source.changes ... should this make it onto tonight's daily CD build?
[06:34] <slangasek> kirkland: server daily build is at 10:30 BST, so yeah
[07:32] <ttx> pitti, slangasek: please trigger a -server daily CD respin
[07:38] <dholbach> good morning
[07:54] <dholbach> lool, paulliu: there's a bunch of sync requests of new packages in the sponsoring queue... did you guys talk to the release team about it?
[07:57] <paulliu> dholbach: not yet. How to do that? We only have an FFE.
[07:58] <dholbach> oh... you have a FFE
[07:58] <dholbach> sorry
[07:58] <dholbach> nevermind me
[07:58] <paulliu> dholbach: Those new packages are already well tested in our PPA for a long time. We are conservative now and not chasing the latest version of Intel's Moblin repo.
[07:58] <dholbach> ok
[08:00] <dholbach> where does libmoblin-panel-dev come from?
[08:01] <paulliu> dholbach: mutter-moblin.
[08:01] <paulliu> dholbach: There are some dependencies. anerley should go first. And then mutter-moblin.
[08:01] <dholbach> looks like they are still waiting in the queue somewhere?
[08:01] <paulliu> dholbach: Yes. In New.
[08:01] <dholbach> ok
[08:03] <lool> dholbach: (Right, we have a LP #425547 as some kind of standing FFE on Moblin packages)
[08:03] <lool> (Morning)
[08:04] <dholbach> ok, super
[08:04] <dholbach> hi lool
[08:06]  * dholbach loves Launchpad's -changes mails that tell us how to spell "non-Standard" letters: ALEFHAHMEEMDAL ALEFLAMMEEMHAHMEEMWAWDALYEH
[08:29] <dpm> pitti, hey good morning. I've tried to provide a fix for bug 449411 (extracting .desktop translations for onboard). Onboard is using the auto module from python-distutils-extra, which should autodetect .desktop.in files. However, it didn't seem to do it, and I had to explicitly list them in a setup.cfg file. I'm just wondering, was that the right way to do it?
[08:38] <ttx> cjwatson: do you have the magic power to respin server ISOs ? My usual helper doesn't seem to be around :)
[08:39] <pitti> Good morning
[08:40] <ttx> pitti: good morning !
[08:42] <pitti> dpm: hm, can you please show me your changes?
[08:42] <pitti> hey ttx
[08:43] <ttx> pitti: see backlog, I need a server CD respin when you have 2 minutes.
[08:43] <nikolam> HI! packages.ubuntu.com does not work again. Who to report that?
[08:43] <slangasek> wgrant: I guess none of the counts on http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html deduct the "superseded source versions"?
[08:43] <pitti> ttx: running (CC: slangasek)
[08:44] <ttx> pitti: great!
[08:44] <dpm> pitti, yes, the changes are here -> http://launchpadlibrarian.net/33487525/make-desktop-files-translatable.debdiff
[08:45] <dpm> (I basically renamed the .desktop files to .desktop.in, marked them for translation and added them to setup.cfg)
[08:46] <wgrant> slangasek: No, they don't. I can easily enough fix that.
[08:46] <pitti> dpm: oh, there are two patches, one for renaming and one for adding the X-Ubuntu-Gettext-Domain one
[08:47] <pitti> dpm: (they could be just merged, but nevermind; just looked confusing)
[08:47] <liw> hm, LP isn't talking to me -- is this happening to anyone else?
[08:47] <dpm> pitti, ah, ok, I'll take that into account for the next time
[08:47] <slangasek> wgrant: would appreciate it, seeing as I noticed this 5 minutes /after/ sending out a mail to u-d-a with some overinflated numbers ;)
[08:48] <pitti> it's not automatically handled since the .desktop file is explicitly mentioned in data_files[]; if you drop it from there completely, does it work?
[08:48] <wgrant> slangasek: Oops. Sorry.
[08:49] <slangasek> hmm, here's a nice NM regression, if a network ever fails to connect then clicking on it again in the applet doesn't retry
[08:49] <dpm> pitti, I'll try. I've also noticed just now that the translations from the .ui files are not extracted, and it might be that's because of this as well (*.ui files are also mentioned as data_files)
[08:49] <slangasek> either that or my driver is really unhappy
[08:57] <Darxus> It's been 11 minutes since I uploaded a (large) package to my ppa, should I be concerned that I haven't gotten a confirmation or rejection from launchpad?
[08:57] <wgrant> Darxus: Yes. But #launchpad is better.
[08:58] <pitti> ttx: image built
[08:58] <wgrant> slangasek: Code should be fixed, but LP is being disagreeable so it's not updating.
[08:59] <Darxus> wgrant: Thanks.
[08:59] <bryce_> "No apport report written because MaxReports is reached already" (on doing apt-get dist-upgrade)
[08:59] <slangasek> wgrant: thanks :)
[08:59] <ttx> pitti: thx. rsyncing and going for a coffee
[09:01] <wgrant> liw: What is the problem you're having with LP?
[09:01] <liw> wgrant, I can't get any page to open
[09:02] <wgrant> It's not processing uploads, and I'm getting 502s and 500s far too often tonight. I think something might be wrong.
[09:03] <wgrant> But normal page views work most of the time.
[09:03] <dpm> pitti, ok, I've dropped the .desktop files from data_files[] in setup.py and I've also removed setup.cfg. That caused translations from the .desktop.in files to be extracted as expected, but the .desktop files don't seem to be then neither generated nor present in the package
[09:08] <\sh> moins
[09:09] <mac_v> kees: hi.. could you file a separate bug for the apport icon? or you could edit your existing bug accordingly
[09:12] <pitti> dpm: I removed 20-add-i18n-setup-cfg.patch and desktop from data_files and applied your patch; 30-make-desktop-files-translatable.patch doesn't apply now
[10:35] <james_w> mvo: would you have a few minutes to chat about bug 449738 today?
[10:36] <mvo> james_w: yes! right after lunch?
[10:36] <james_w> suits me fine
[10:36] <mvo> great, thanks!
[10:46] <andersin> Can someone please point me to the place in shutdown that removes the grub2 environment variable recordfail
[10:47] <andersin> The reason is that in karmic, whenever I come out of hibernate, grub does not have a timeout
[10:47] <andersin> it does when I come back from normal shutdown
[10:49] <cjwatson> andersin: there is no place on shutdown that removes that
[10:49] <andersin> really, then how is that ever removed?
[10:49] <cjwatson> andersin: however, there is a known bug that it is not removed on resume from hibernation
[10:50] <cjwatson> andersin: that bug is fixed in the upload I'm currently testing
[10:50] <cjwatson> andersin: it's removed on boot, not shutdown
[10:50] <cjwatson> the purpose of recordfail is to determine whether the last boot succeeded
[10:50] <andersin> ah, so once the boot is complete, it is removed?
[10:52] <andersin> do you have a bug number for me by any chance, so I can take a look?
[10:55] <cjwatson> andersin: bug 447725
[10:56] <andersin> thanks
[11:13] <walterl> hi
[11:39] <dpm> pitti, re: python-distutils-extra, sorry, I had some breakage after an update, got disconnected and sidetracked. The last thing I got from you was:
[11:39] <dpm> "dpm: I removed 20-add-i18n-setup-cfg.patch and desktop from data_files and applied your patch; 30-make-desktop-files-translatable.patch doesn't apply now"
[11:40] <pitti> dpm: right, I then just noticed that the patch was already applied
[11:40] <pitti> dpm: it's a bit weird, if I do ./setup.py install --root=/tmp/x, the desktop.in files get installed automagically
[11:40] <pitti> dpm: but with a .deb build they aren't
[11:40] <dpm> pitti, what I've done now is to simply drop the 20-* patch, replace it by this -> http://ubuntu.pastebin.com/d352a1a1e and rebuild the package
[11:40] <dpm> ah, ok
[11:41] <pitti> dpm: just keep the setup.cfg for now, seems there's a p-distutils-extra bug somewhere
[11:41] <dpm> pitti, ok, thanks a lot, I'll see if I can file a bug
[11:42] <dpm> pitti, any recommendations on how to extract the translations from the *.ui files? They don't seem to be processed automatically, and I'm not sure how I can specify the .ui files in setup.cfg
[11:43] <pitti> dpm: how do you mean? ui files (as in GTKBuidler) don't have translations
[11:43] <pitti> dpm: oh, you mean extract the translatable strings into the POT?
[11:44] <dpm> pitti, yes, they don't seem to be extracted
[11:44] <dpm> and merged into the POt
[11:44] <dpm> using the p-distutils-extra auto module
[11:44] <pitti> this is all just supposed to happen automatically..
[11:46] <pitti> dpm: you can manually add it to po/POTFILES.in, of course, but then you need to add all the other source files as well
[11:46] <dpm> pitti, yes, that's what I thought, but it doesn't seem to happen with this package, and I couldn't find any other packages that use p-distutils-extra 'auto' instead of 'command', to use as an example
[11:46] <pitti> dpm: jockey and apport
[11:46] <dpm> pitti, ah, ok, I'll have a look at them
[11:46] <pitti> dpm: aah, got it
[11:47] <pitti>                 if '<interface>\n' in contents and '<requires lib="gtk+"' in contents:
[11:47] <pitti>                     files.add('[type: gettext/glade]' + f)
[11:47] <pitti> dpm: ^ that's my check if it's a GTKBuilder file (since Qt also uses *.ui)
[11:47] <pitti> but your's has
[11:47] <pitti> <interface domain="onboard">
[11:49] <pitti> dpm: can you please file a bug about it?
[11:49] <pitti> dpm: I think I can manage to fix it today, and upload a new version
[11:50] <dpm> pitti, about the check? Sure, I can do it
[11:50] <dpm> give me a couple of minutes
[11:50] <pitti> dpm: about not picking up your .ui file
[11:50] <dpm> ok
[11:51] <pitti> dpm: I'm not entirely sure why it doesn't pick you your .desktop.in file for installation automatically
[11:51] <pitti> feel free to file a bug about it as well
[11:51] <dpm> Yes, I was intending to file a separate one :)
[12:09] <dpm> pitti, ok, filed bug 451170 and bug 451175, let me know if you need more information
[12:21] <ogra> cjwatson, could you let the two armel kernels out of NEW ?
[12:27] <cjwatson> ogra: already doing
[12:27] <ogra> thanks :)
[12:46] <cjwatson> ArneGoetje: I've sponsored language-selector 0.4.12. I'm afraid I had to 'bzr upgrade' the ubuntu-core-dev branch to the 2a format in order to work around problems here, so you may find that you likewise have to 'bzr upgrade' your local branches before you can do anything useful
[12:49] <amitk> hmm.. why is my "lock screen" option grayed out in the indicator-applet-session?
[12:50] <seb128> amitk, because you use autologin I guess
[12:50] <seb128> amitk, "design decision", we will change it before karmic with a distro patch though
[12:50] <statik> hi james_w, i wonder if you could take another look at https://code.edge.launchpad.net/~ubuntuone-control-tower/ubuntu/karmic/desktopcouch/snapshots-with-packaging/+merge/13209 ? from what I can tell, chad fixed the review comments
[12:51] <james_w> hi statik
[12:51] <james_w> it's on my list for today
[12:51] <statik> you rock
[12:54] <pitti> dpm: ok, got these two testcase'd and fixed; uploading now
[12:54] <joaopinto> VTs are fixed, great
[12:55] <dpm> pitti, that's awesome, thanks!
[12:57] <amitk> seb128: aah. Thanks for the info.
[13:04] <cjwatson> joaopinto: excellent
[13:09] <\sh> do we have some problems with X + nvidia closed source drivers? I have a very fast blinking console after latest upgrades and a reboot on my ThinkPad R61
[13:10] <ArneGoetje> cjwatson: thanks a bunch
[13:11] <\sh> not an nvidia issue
[13:11]  * Keybuk begins a mental countdown
[13:12] <mterry_> slangasek, I'd like bug 430220 to get pushed before final freeze.  It fixes a buffering issue with rsyslog that prevents kernel messages from being immediately logged.  It also fixes some minor upstart packaging issues, but the buffering is the real win.
[13:15] <joaopinto> cjwatson, tks
[13:17] <\sh> ok...removing old xorg.conf with nvidia driver entry helped...
[13:27] <ArneGoetje> cjwatson: are you going to collectively pull translations from LP and update those packages which don't use language-packs?
[13:28] <cjwatson> ArneGoetje: I normally do
[13:29] <ArneGoetje> cjwatson: :) can you please include language-selector for that? That would save us the sponsoring step. ;)
[13:30] <cjwatson> ok, can do
[13:30] <ArneGoetje> cjwatson: thanks a lot
[13:30] <cjwatson> ArneGoetje: any particular timing?
[13:34] <ArneGoetje> cjwatson: well, deadline for those translations is tomorrow... so, I guess those uploads should happen on Friday?
[13:34] <cjwatson> fine by me, maybe remind me then if you could :)
[13:35] <ArneGoetje> cjwatson: ok.
[13:35] <cjwatson> memory like a ... thing with holes in
[13:35] <ArneGoetje> cjwatson: :)
[13:42]  * Keybuk stops counting
[13:42] <Keybuk> nobody jumped on me
[13:42] <Keybuk> I guess I didn't break anything ;)
[13:42] <StevenK> Keybuk: That we've found ... :-P
[13:44] <Keybuk> StevenK: the thing about things I maintain is ...
[13:44] <Keybuk> well...
[13:44] <Keybuk> if I break things, people notice
[13:44] <Keybuk> quickly
[13:47] <StevenK> Heh, I know :-)
[13:55] <Keybuk> siretart: around?
[14:09] <Notch-1> hi, i'm developing an utility for gnome, but i do not have a samba share right now,so should somebody tell me how the samba mounted filesystem looks like, in ~/.gvfs directory please? i need just the name of the folder, like "smb on 192.168.0.1" or "samba on 192.168.0.1"...
[14:18] <Notch-1> please guys, nobody uses samba? it will take a microsecond to help me :°
[14:20] <TheMuso> Notch-1: For me, its "sharename on server"
[14:20] <ttx> Notch-1: looks like "SHARENAME on SERVERNAME", but localized
[14:21] <chrisccoulson> If you're developing a utility for gnome, then why do you need to know about stuff in ~/.gvfs?
[14:22] <Notch-1> there is not something like "WebDAV on 192.168..."... like for ftp, ftps, dav, davs, etc ? in  other words: is the SHARENAME part fixed?
[14:22] <Keybuk> bryce_: around?
[14:22] <ttx> Notch-1: no, it's the share name, so it's not fixed.
[14:23] <Notch-1> chrisccoulson:  because with gnome is very difficult to use smb://192.... so i'm replacing it with "~/.gvfs/SOMETHING on 192..."
[14:23] <chrisccoulson> why is it difficult to use smb://?
[14:23] <chrisccoulson> just do it all through GIO
[14:23] <Notch-1> ttx: ah well, so i can't get my utility working with samba, only the others protocol...
[14:23] <chrisccoulson> not everyone uses gvfs-fuse...
[14:24] <hyperair> use the gfile functions
[14:24] <hyperair> it'll automatically convert
[14:25] <Notch-1> chrisccoulson: ask python people :D (http://groups.google.com/group/wxpython-users/browse_thread/thread/dafae506fc629087)
[14:25] <Notch-1> hyperair: gfile function, of who?
[14:26] <hyperair> er gio_whatever
[14:26] <hyperair> i remember there was something
[14:26] <hyperair> lemme dig it up
[14:27] <chrisccoulson> Notch-1 - the GIO reference is here: http://library.gnome.org/devel/gio/stable/
[14:27] <hyperair> Notch-1: i think g_file_get_path in C. not sure about the python equivalent
[14:27] <hyperair> or wait.. i think i might know.
[14:27] <hyperair>     path="$(python -c "import gio; print gio.File('$uri').get_path()")"
[14:27] <hyperair> that was in a bash script
[14:28] <Notch-1> thank you very much, i'll check it out
[14:33] <thomas_sch> my friend can't use his sound card (Creative Labs SB Live! EMU10k1) anymore since he updated ubuntu.i modprobed als emu10k* modules and this is the dmesg output is http://nopaste.info/1595709da2.html
[14:33] <thomas_sch> s/my friend/a friend of mine/
[14:34] <seb128> wgrant, what is "superseded" on your ftbfs list?
[14:34] <sistpoty|work> seb128: a new version was already uploaded after the test-build
[14:34] <seb128> sistpoty|work, is there any point to list those?
[14:35] <sistpoty|work> seb128: not too much I gues, unless you want to look at past build failures (funnily I did just this at the moment *g*)
[14:35] <seb128> ok ;-)
[14:35] <seb128> I've enough to do without looking at those I think ;-)
[14:36] <sistpoty|work> heh, you could enjoy knowing how much is fixed already :P
[14:39] <cjwatson> that is actually a useful thing to see
[14:39] <cjwatson> an indication of progress ...
[14:42] <TheMuso> /c/
[14:46] <mdeslaur> tedg: I have a couple of questions about indicator-applet-session: how does it populate the "Guest session" item in it's menu? What does that run?
[14:48] <tedg> mdeslaur: I'm not sure what you mean by "how does it populate" but it runs /usr/share/gdm/guest-session/guest-session-launch
[14:50] <mdeslaur> tedg: that answers my question, thanks. I couldn't figure out what it was launching by looking at the source in the indicator-applet package...
[14:50] <mdeslaur> (still can't...)
[14:51] <tedg> mdeslaur: The code you're looking for is in indicator-session.  bzr branch lp:indicator-session ; cd indicator-session/src ; vi users-service.c
[14:51] <mdeslaur> tedg: thanks!
[14:52] <pitti> Keybuk, cjwatson: oh, now it's quite obvious why usplash fsck integration doesn't work any more -- mountall completely replaced /etc/init.d/check{root,fs}.sh :)
[14:52] <Keybuk> yes ;)
[14:52] <Keybuk> I actually ported your shell to C ages ago
[14:52] <Keybuk> and have it sat here in a branch
[14:52] <Keybuk> but needed to fix usplash first, because every time I tried to debug, I corrupted my console <g>
[14:53] <pitti> Keybuk: you mean the entire /lib/init/usplash-fsck-functions.sh, or just the bits that called it from check*.sh?
[14:53] <Keybuk> most of it
[14:53] <pitti> Keybuk: since bug 451087 is currently assigned to me, should I take this up?
[14:53] <Keybuk> no, I have it
[14:54] <Keybuk> I dup'd your bug against the one assigned to me :p
[14:54] <pitti> ah, awesome
[14:54] <Keybuk> pitti: it's basically done, I just need to do some testing and upload today
[14:54] <pitti> so, off to fixing the next dozen..
[14:54] <pitti> Keybuk: many thanks
[14:54] <Keybuk> it stalled because my Dell laptop died
[14:54] <Keybuk> (which had the Intel card, on which usplash worked)
[14:54] <Keybuk> so I'm on a different laptop, which has nvidia, and usplash didn't work :p
[14:54] <pitti> hm, that means I need to go back to fixing gdm
[14:55] <Keybuk> I fixed usplash early this morning ;)
[14:55] <Keybuk> what's up with gdm?
[14:55] <pitti> Keybuk: https://edge.launchpad.net/~desktop-bugs/+bugs?field.milestone%3Alist=12698 is still full of it
[14:56] <Keybuk> slangasek: I've been staring at the mountall bugs trying to work out why a bug you marked Won't Fix is still in the list
[14:56] <Keybuk> slangasek: just realised, when you Won't Fix a release-targeted task, it puts the master task back!
[14:56] <Keybuk> pitti: eep
[14:56] <cjwatson> yeah, it's the only way to achieve that effect
[14:56] <cjwatson> i.e. Won't Fix for karmic -> previous state for some future release
[14:57] <pitti> Keybuk: yes, in fact that's the only way to throw something off the release monitor
[14:57] <Keybuk> yeah, I think steve actually really intended to Won't Fix the bug though ;)
[15:01] <tormod> pitti: would you be able to look at the debdiff in bug 440852 please?
[15:15] <pitti> tormod: I looked at it :)
[15:15] <pitti> tormod: do we even install that by default?
[15:16] <tormod> pitti, I think so, I did not install it
[15:16] <pitti> tormod: If we do, I'm all for it; but if you have to install it explicitly, I'd rather leave it in TBH
[15:16] <pitti> http://cdimage.ubuntu.com/daily-live/current/karmic-desktop-i386.manifest
[15:16] <pitti> ah, ther it is
[15:16] <pitti> pulled in by hplip
[15:18] <tormod> pitti, maybe you have an opinion (for karmic or not) on 45883 as well?
[15:19] <pitti> wow, a five-digit bug?
[15:20] <tormod> pitti, yes I have been waiting for years :)
[15:20] <pitti> tormod: sane-backends uploaded
[15:20] <tormod> pitti, thanks
[15:21] <pitti> tormod: hm, I seem to remember reading about that in some changelog recently
[15:21] <pitti> tormod: ah, in indicator-session 0.1.7-0ubuntu1
[15:22] <pitti> bug 444391
[15:22] <pitti> erm
[15:22] <pitti> tedg: ^ you clearly referenced the wrong bug in the indicator-session changelog :)
[15:23] <sladen> mpt: suggestions for bug #334544 ?
[15:23] <tedg> pitti: Indicator-session is so good it fixes sound bugs too! ;)
[15:23] <pitti> wow
[15:24] <sladen> indicator session is so awesome that usability is an after-thought
[15:24] <pitti> tormod: hm, I wonder if that will just land in 2.28.1 (which we'll upload anyway); I'm going to ask Richard about it
[15:24] <tormod> pitti, is it on the trunk but not yet in 2.28 branch
[15:25] <pitti> tormod: right, I just checked; that's why I'm asking hughsie
[15:26] <pitti> tormod: either way, thanks for getting that fixed
[15:28] <tormod> pitti, thanks, would love to see it finally fixed in Karmic :)
[15:30] <pitti> tormod: updated; Richard will land it on 2_28
[15:31] <tormod> pitti, alright thanks for checking! that was my last fix in the queue for karmic :)
[15:31] <pitti> nice
[15:31] <mathiaz> cr3: yo!
[15:31] <pitti> I never expected karmic to get that level of polish, given how much new crack went into it..
[15:31] <mathiaz> cr3: how is checkbox 0.8.4 progressing?
[15:32] <cr3> mathiaz: fixed, but I'm looking into removing my existing branch and having one commit instead of the multiple commits I've been done
[15:32] <cr3> err, s/done/doing/
[15:32] <mathiaz> cr3: as you wish
[15:33] <cr3> mathiaz: I should ping you in a moment, when done. I'll go through the same process and create a merge request for you
[15:33] <mathiaz> cr3: awesome
[15:33] <mathiaz> cr3: you don't need to send me an email anymore - just subscribe me as a reviewer
[15:34] <mathiaz> cr3: LP sends out notifications now
[15:34] <cr3> mathiaz: yay!
[15:37] <pitti> tormod: http://git.gnome.org/cgit/gnome-power-manager/commit/?h=gnome-2-28&id=26182959c7fea5aa63a23e57de4cf62b8da5fe54 :)
[15:38] <tormod> pitti, excellent
[15:45] <cr3> mathiaz: all done, I'm pleasantly surprised that I was able to remove a branch and then create another branch with the same name after. sweet!
[15:46] <mathiaz> cr3: has all your natural optimism gone away overnight?
[15:46] <cr3> mathiaz: nope, it is eternal
[15:47] <cr3> mathiaz: if it hadn't worked for some reason, I would've still been optimist that there was a good reason :)
[15:48] <cr3> mathiaz: that reminds me of removing people or teams in launchpad, the name still seems to be kept and there's a good reason for that... which I unfortunatley don't remember :)
[15:49] <liw> cr3, re-use of names leads to opportunities of identity theft
[15:51] <mathiaz> free: hi - could you mark https://code.launchpad.net/~free.ekanayaka/landscape-client/jaunty.fix-347983/+merge/12172 as being merged?
[15:52] <free> mathiaz: hello, sure
[15:53] <free> mathiaz: btw, thanks for the karmic upload of the latest landscape-client, I'll use a bug next time :)
[15:54] <junjun> hi
[15:54] <mathiaz> free: could you have a look at bug 450907?
[15:54] <junjun> any idea on how to install gcc-3.4 (to compile some old apps) on Karmic?
[15:54] <free> mathiaz: we saw it, but didn't quite understand it
[15:58] <zul> pitti: ping
[16:06] <mvo> free: there a few dup on various package with this error, I have no idea yet what causes it
[16:07] <free> mvo: you mean various packages are failing with this error?
[16:07] <james_w> mvo: are these from upgrades with aptdaemon do you know?
[16:08] <mvo> james_w: not sure, that was my first instinct, but there is one kpackagekit as well
[16:08] <mvo> free: yes, including eglibc
[16:08] <james_w> that would still fit I guess
[16:09] <free> mvo: the only thing that comes to my mind is a "usermod -g landscape landscape" in landscape-common.postinst, which makes the script write a "usermod: no changes" to stdout
[16:09] <mvo> but not in a reproducable way
[16:09] <mvo> james_w: my gut feeling is that it is releated to aptdaemon
[16:09] <james_w> I've seen that error a couple of times
[16:09] <free> mvo: it would probably better to "> /dev/null 2>&1"-it
[16:09] <james_w> I put it down to the frontend going away
[16:10] <james_w> as X went away
[16:10] <mvo> james_w: oh? you saw it with PK? or aptdaemon? or both?
[16:10] <james_w> aptdaemon
[16:11] <mvo> cool, any way to reproduce?  ctrl-alt-backspace while it is running?
[16:11] <james_w> I had X die I think
[16:11] <james_w> so that might work
[16:12] <james_w> however, I'm not sure why that would break a pipe to dpkg's stdout?
[16:12] <james_w> I guess the X session going kills D-Bus, which kills aptd?
[16:12] <james_w> no, it's on the system bus isn't it?
[16:14] <mathiaz> cr3: checkbox-cli still failing in a guest - http://paste.ubuntu.com/293187/
[16:15] <mathiaz> cr3: I've run a successful test on my laptop though
[16:16] <mathiaz> cr3: so I'll upload 0.8.4 to the archive
[16:16] <siretart``> Keybuk: yes?
[16:16] <Keybuk> siretart``: I had to smash the cryptsetup repo
[16:16] <mathiaz> cr3: the issue on my virtual guest should still be tracked down - at some point
[16:16] <Keybuk> siretart``: you might have to pull --overwrite
[16:17] <siretart``> I notice that you preferred to overwrite my commit over adding an mkdir -p to debian/rules :-/
[16:18] <mvo> james_w: its on the system bus - the only thing I can think of is that its a bug in aptdaemon. it feed stdout back and forth over the bus for the terminal
[16:18] <james_w> mvo: that could well do it then
[16:18] <siretart``> regarding the cryptsetup branch, it is royally messed up anyway. we should probably just replace it with launchpad's auto imports
[16:19] <mvo> james_w: I have a look
[16:22] <siretart``> besides, I image that apport hook would have been very useful
[16:25] <mathiaz> cr3: could you mark https://code.launchpad.net/~cr3/ubuntu/karmic/checkbox/0.8.4/+merge/13347 as being merged?
[16:26] <siretart``> james_w: has the launchpad package-branch importer been suspended, or is it 'just' slow?
[16:26] <james_w> siretart``: which package are you looking at?
[16:26] <james_w> it's not suspended
[16:26] <james_w> and it is quick :-)
[16:26] <james_w> so it's probably a failure
[16:27] <siretart``> james_w: cryptsetup
[16:28] <james_w> siretart``: yeah, it's a failure, sorry
[16:29] <james_w> bzrlib.errors.DuplicateFileId: File id {tree_root-20090616034229-jktmk6p46y1yuzrw-182} already exists in inventory as InventoryDirectory('tree_root-20090616034229-jktmk6p46y1yuzrw-182', '', parent_id=None, revision='james.westby@ubuntu.com-20070109215306-1r0mkhd5igfx7a8z')
[16:29] <james_w> on fetch
[16:29] <james_w> which is odd
[16:29] <siretart``> no problem, but how could I check if an package import failed myself?
[16:30] <james_w> they are not currently publically accessible, sorry
[16:30] <james_w> I should talk to IS about that
[16:30] <siretart``> OK, just wanted to confirm. no problem
[16:30] <james_w> I was hoping that no-one would need to care ;-)
[16:32] <siretart``> :)
[16:33] <debfx> seb128: ted acked my changes to fix bug #346840, please also read my last comment on that bug in the hope to convince you to apply the workaround for kde
[16:34] <slangasek> Keybuk: heh, yes, that's how wontfix+devel target works :)
[16:35] <seb128> debfx, ok for the workspace thing, I'm still not convinced for kde
[16:35] <slangasek> mterry: right, someone nominated that as a "fix this before release" bug in response to the email announcement... I can take a look at that today
[16:36] <Keybuk> slangasek: yeah I just got confused
[16:36] <Riddell> seb128: if we have a fix for an issue surely we should use it?
[16:36] <seb128> Riddell, yes, a fix, not a random hack to do something non standard depending of an environment variable
[16:38] <Riddell> seb128: how else is this going to get fixed before final freeze?
[16:39] <seb128> Riddell, I don't know, either by somebody wanting to look at what is wrong in the code or not
[16:39] <seb128> Riddell, is pidgin the default kubuntu im client?
[16:39] <seb128> we have thousand of small glitches, I don't see that one as a priority for karmic right now
[16:40] <Riddell> because it's one we have a workaround for
[16:40] <slangasek> ScottK: hrm, it seems emacs23 is still building 'emacs' - debian/control.in :/
[16:43] <james_w> I was once told you could override the version of a single binary package from a source package by putting "Version: whatever" in its binary stanza
[16:44] <james_w> experimentation suggests this was a fib, and intuition suggests it would cause trouble any way
[16:44] <dholbach> james_w: I hope that's one of the best-kept secrets of the world ;-)
[16:44] <james_w> is there any way of doing this?
[16:44] <slangasek> james_w: right, you have to do it with dpkg-gencontrol -v instead
[16:44] <slangasek> and it's a horrible, horrible thing
[16:44] <james_w> we want to provide a transitional package from the new source, but the old source had an epoch
[16:44] <ScottK> slangasek: Sorry.  I'll fix it again
[16:45] <slangasek> which is why the gcc package does it on every single binary it generates :)
[16:45] <slangasek> ScottK: thanks
[16:45] <james_w> so would that be frowned upon?
[16:45] <cr3> mathiaz: done and thanks!
[16:45] <slangasek> james_w: well, that's what I just did in emacs22
[16:46] <james_w> oh, I'll crib then
[16:46] <slangasek> and I did more of the frowning than anyone else ;)
[16:46] <mathiaz> cr3: that's 394 poutines and 5822 beers you owe me now
[16:46] <james_w> heh
[16:47]  * sistpoty|work is sorry for not having checked good enough to make slangasek frown
[16:49] <slangasek> sistpoty|work: I don't think it's really the responsibility of the release team to check for arbitrary craziness in the package when ok'ing freeze exceptions... but I fear the uploader may have been expecting this to happen :/
[16:51] <Keybuk> slangasek: the release team should check every single upload
[16:51] <Keybuk> with an oscilloscope!
[16:53] <sistpoty|work> well, I do have a few oscilloscopes here (at work) :P
[16:54] <LaserJock> I have some lasers
[16:54] <LaserJock> maybe that'd help
[16:57] <ttx> Keybuk: sorry for the lazy upstart assignment. And thanks for the detailed explanation.
[17:00] <mpt> sladen, no, I don't have any
[17:00] <mpt> sorry
[17:00] <mpt> I'm not familiar with keyboard navigation of the panel in general -- is there a help page describing it?
[17:19] <slangasek> wgrant: I'm still not seeing the statistics I would expect to on the rebuild status page; the only summary figure for 'main' is 89, and I can tell at a glance that this doesn't equal 3 ;)
[17:23] <kirkland> jdstrand: do you recognize this?  http://pastebin.ubuntu.com/293242/
[17:25] <jdstrand> kirkland: I've never seen it except for maybe once when you asked me about it before (ie, it seems vaguely familiar, but I've never encountered it in my work)
[17:30]  * Riddell hugs bryce_ for finding the fix for bug 432521
[17:32] <cjwatson> bryce_: this -nr patch that's in your 'red' PPA - are you considering it for karmic?
[17:41] <kirkland> cjwatson: hey, could you rescore https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1292104 ?
[17:41] <kirkland> cjwatson: eucalyptus needs to test that to fix a release critical bug
[17:42] <cjwatson> kirkland: done
[17:42] <mathiaz> zul: why is puppet still in universe?
[17:45] <zul> mathiaz: because of libaugeas-ruby asac hasnt looked at it yet
[17:45] <mathiaz> zul: ok
[17:49] <ccheney> slangasek: hey what did you determine was the cause for it pulling in the other ooo style? I followed up to the bug just now and was wondering why the openoffice.org-gtk, which openoffice.org-gnome depends on would have pulled the proper style without pulling in both?
[17:49]  * zul returns
[17:49] <ccheney> er would not have
[17:50] <slangasek> ccheney: because openoffice.org-gnome depends on openoffice.org-core, openoffice.org-gtk, and the dependencies are traversed depth-first
[17:50] <ccheney> slangasek: oh
[17:50] <slangasek> so it was still seeing -style-default before -human-style
[17:50] <ccheney> oh ok
[17:51] <ccheney> we might run into that same issue on kubuntu then if i understand what you said
[17:51] <ccheney> since it wants -style-oxygen (iirc)
[17:51] <slangasek> right, I haven't checked kubuntu - I noticed Ubuntu because it pushed the CDs oversized
[17:51] <ccheney> ok
[17:52] <slangasek> ccheney: ok, checked now and kubuntu still has -style-oxygen
[17:52] <slangasek> and not -style-galaxy
[17:52] <ScottK> ccheney: IIRC we seed the oxygen style directly as a work around.
[17:53] <ccheney> ScottK: ok
[17:58] <mathiaz> is there a reason why avahi would change the existing ip address configuration when started?
[17:59] <sladen> mathiaz: it fires up a link-local address and attaches to that
[17:59] <mathiaz> I've got a system that uses dhclient. Then I installed eucalyptus-cloud (which starts avahi) - the IP address of the system has changed to 169.254.169.254
[18:00] <mathiaz> the old address (10.153.108.210) is still pingable though
[18:00] <mathiaz> but ifconfig eth0 doesn't list the old address anymore
[18:01] <hyperair> shouldn't it be eth0:avahi having the link-local address?
[18:02] <hyperair> speaking of which network-manager fails to communicate with avahi, iirc
[18:02] <hyperair> avahi will get an address, then nm will timeout and complain that ip config failed or something
[18:02] <hyperair> it can get rather annoying
[18:02] <mathiaz> hyperair: the system doesn't use nm
[18:02] <hyperair> hmm
[18:02] <hyperair> so what does ifconfig say?
[18:03] <sladen> mathiaz: can you pastebin   ifconfig -a
[18:03] <mathiaz> sladen: http://paste.ubuntu.com/293272/
[18:06] <mathiaz> kirkland: hey - do you remember the bug about detecting the wrong ip address for the CC (ie 169.254.169.254) we saw last week
[18:06] <mathiaz> kirkland: has this been fixed?
[18:07] <kirkland> mathiaz: it's been hacked around
[18:07] <mathiaz> kirkland: right - hacked around
[18:07] <mathiaz> kirkland: see above - I may have find another clue
[18:07] <kirkland> mathiaz: my CLC still occasionally thinks its ip address is 169.254x2
[18:08] <mathiaz> kirkland: I've installed eucalyptus-cloud and now eth0 has 169.254.169.254
[18:08] <mathiaz> kirkland: where it used to have 10.153.X.Y
[18:08] <kirkland> mathiaz: right, i'm seeing that occasionally -- that sucks
[18:09] <kees> seb128: I need bug 446395 assigned -- I've been totally unable to reproduce it, but more and more people are hitting it (and we're starting to see some hopefully useful debug output)
[18:15] <pitti> cr3: *hug*
[18:16] <cr3> pitti: right back at you!
[18:18] <seb128> kees, looking
[18:19] <chrisccoulson> kees / seb128 - i wonder if that's related to a gnome-screensaver crasher that's just been submitted
[18:19] <kees> chrisccoulson: I sure hope so, because I've been having a terrible time getting more info about it.  :P
[18:19] <kees> chrisccoulson: which bug # is the new crash?
[18:20] <chrisccoulson> i've just triggered the bug anyway
[18:20] <chrisccoulson> the crash is bug 451345
[18:20] <cr3> pitti: man, you've had a lot on your shoulders this release: policy kit and hal seem to have been big ones
[18:21] <seb128> chrisccoulson, kees: the log has
[18:21] <seb128> "The program 'gnome-screensaver' received an X Window System error.
[18:21] <seb128> This probably reflects a bug in the program.
[18:21] <seb128> The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
[18:21] <seb128>   (Details: serial 11249 error_code 9 request_code 53 minor_code 0)
[18:21] <seb128> "
[18:21] <pitti> cr3: that was quite a large chunk indeed, but it was fun, too; lots of nice upstream development for me :)
[18:21] <kees> seb128: yeah, but they didn't have dbgsym installed, so they couldn't catch the error to get a backtrace
[18:21] <cr3> pitti: oh nice! always feels good to give back
[18:22] <chrisccoulson> right, so they're the same bug then
[18:22] <kees> chrisccoulson: while I certainly want that to be true -- how do you know?  does the helper crashing do this?
[18:23] <chrisccoulson> i need to try and see if i can get a better backtrace then
[18:23] <pitti> cr3: yeah, I was able to port the entire gvfs from hal to DK, and write the udev bits for hotkey management; for the other bits I mainly coordinated and gave some suggestions
[18:23] <pitti> cr3: with the benefit that I can now pretty much ignore all those 500 hal bug reports :-P
[18:23] <pitti> cr3: (which was actually the entire purpose of the show, to get rid of this bug and race condition laden monster)
[18:23] <cr3> pitti: that's an awesome idea: when there are too many bugs, remove the project!
[18:24] <seb128> chrisccoulson, kees: I can confirm that after 5 tries it does from password prompt to screensaver
[18:24] <seb128> chrisccoulson, kees: I can confirm that after 5 tries it does from password prompt to screensaver
[18:24] <seb128> ups
[18:24] <seb128> does -> goes
[18:24] <seb128> so maybe the screensaver hack they use lead to a crash
[18:24] <kees> seb128: right, that's the expected behavior.  they're saying it goes to the desktop.
[18:24] <seb128> seems gnome-screensaver is quite crashing when using nvidia binary drivers and 3d screeensavers
[18:25] <kees> seb128: having a hack crash shouldn't take out the whole screensaver.
[18:25] <seb128> good point
[18:25] <pitti> ScottK: oh, so karmic's emacs is supposed to be 22? I think I installed it for my wife at beta, and she ended up with 23
[18:25] <seb128> let's wait for chrisccoulson to get a debug stacktrace
[18:25]  * kees nods
[18:25] <seb128> chrisccoulson, what videocard do you use?
[18:25] <kees> I will try to create a local crashing hack...
[18:25] <ScottK> pitti: If you want the supported one, 22 is what you want.
[18:25] <pitti> cr3: yes, indeed! and since users don't really see hal, we can actually do it :)
[18:26] <pitti> ScottK: hm, if emacs23 doesn't build "emacs" any more, how can we make sure that the old 22 "emacs" package becomes current again?
[18:26] <seb128> chrisccoulson, you crash was a gnome-screensaver-gl-helper one, what would be useful is a gnome-screensaver stracktrace
[18:27] <ScottK> pitti: I think slangasek had some kind of black magic for this.
[18:27] <pitti> ScottK: I'm not entirely sure whether LP will like us when we rebuild emacs22 with the binary having a lower version number than the previous one
[18:27] <pitti> ScottK: ok; so it's been discussed already then? fine
[18:27] <slangasek> pitti: it won't; we have to do stupid version tricks
[18:27] <pitti> slangasek: ok, so binary specific version number then
[18:27] <chrisccoulson> seb128 - i'm trying to get one but it doesn't happen consistently here
[18:28] <slangasek> pitti: yep
[18:28] <pitti> release times are fun; time for nasty hacks :)
[18:28] <chrisccoulson> and i've no virtual consoles either, which makes debugging a pain
[18:31] <seb128> chrisccoulson, use user switching and a real user?
[18:31] <chrisccoulson> seb128 - yeah, i'll have to do that
[18:31] <kirkland> cjwatson: could I trouble you for a rescore of https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1292274 ?
[18:31] <kirkland> cjwatson: thanks, as always
[18:31] <chrisccoulson> would be nice to have some consoles though:)
[18:37] <chrisccoulson> right, triggered it again in gdb but forgot the sync option
[18:38] <kirkland> pitti: slangasek: hey, do you guys have build rescoring capabilities?
[18:38] <pitti> kirkland: I do
[18:38] <slangasek> not I
[18:38] <kirkland> pitti: https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1292274
[18:38] <kirkland> pitti: could you have that build now?
[18:39] <pitti> kirkland: well, I can't do "now", but I can do "next"
[18:39] <kirkland> pitti: good enough :-)
[18:39] <pitti> kirkland: i. e. only sysadmins can actually cancel build jobs
[18:39] <pitti> but I guess that's not necessary here
[18:39] <pitti> kirkland: (done)
[18:40] <kirkland> pitti: thanks muchly
[18:40] <pitti> np
[18:44]  * pitti discovers grep --color=auto in the guest session (apparently new ~/.bashrc default); nice!
[18:44] <seb128> pitti, same here ;-)
[18:45] <pitti> having used my /home directory since pre-warty, I wonder how much other goodness I have missed
[18:45] <kees> seb128: okay, I can reproduce it with an explicitly crashing hack.
[18:46] <seb128> kees, good
[18:48] <chrisccoulson> kees - you recreated it too right?
[18:48] <kees> chrisccoulson: yeah, but it doesn't always happen.
[18:48] <kees> chrisccoulson: still can't catch a backtrace, though
[18:48] <chrisccoulson> i've got one
[18:48] <chrisccoulson> http://paste.ubuntu.com/293307/
[18:48] <kees> chrisccoulson: I selected antmaze, then replaced it with "sleep 10; kill -SEGV $$" shell script
[18:49] <bryce_> cjwatson, the DX team wanted to test the norootbg patch to see if it'd help with what they were doing.  I never heard back from them on how their testing turned out or if they needed it.  So at this point I do not have plans to put it in.
[18:49] <chrisccoulson> it's calling XFreePixmap with an invalid pixmap somewhere
[18:49] <chrisccoulson> hence the BadDrawable error
[18:49] <seb128> chrisccoulson, kees: I got one too, http://paste.ubuntu.com/293308/
[18:49] <seb128> but I lack libx11 debug symbols
[18:51] <kees> are those different?  chrisccoulson's was a crash through "shake dialog"
[18:51] <kees> seb128's was due to a keypress?
[18:52] <chrisccoulson> was it with --sync?
[18:53] <seb128> new one
[18:53] <seb128> http://paste.ubuntu.com/293308/
[18:53] <seb128> it's by running "gnome-screensaver --sync --no-daemon"
[18:53] <seb128> and attaching gdb from an another session
[18:53] <seb128> and breaking on gdk_x_error
[18:53] <chrisccoulson> hmmm, they look different
[18:53] <seb128> then I do a serie of wrong passwords
[18:53] <seb128> yes, the first one was not a crash
[18:53] <seb128> on the second one I got the "The error was 'BadDrawable (invalid Pixmap or Window parameter)'."
[18:54] <seb128> doh
[18:54] <seb128> the new one is http://paste.ubuntu.com/293311/
[18:54] <seb128> sorry wrong url before
[18:54] <seb128> chrisccoulson, kees: ^ that's the crash one
[18:55] <chrisccoulson> that's better :)
[18:55] <chrisccoulson> XFreePixmap is what throws the error
[18:55] <kees> ok, that one might be the same, some unresolved functions, but the path looks similar
[18:58] <seb128> right
[18:58] <seb128> http://paste.ubuntu.com/293316/
[18:58] <seb128> that one is a debug one
[18:58] <seb128> seems similar to chrisccoulson's one now
[18:58] <seb128> the bug is quite easy to trigger indeed
[18:58] <chrisccoulson> i found it quite hard to trigger :/
[18:59] <kees> hmpf, I hit it once now and not yet since then.  :(
[18:59] <chrisccoulson> it takes a lot of tries before i trigger it
[18:59] <seb128> I set the screensaver hack on random hack there
[18:59] <seb128> and I do enter, wait a second, enter, wait a second, enter, etc
[18:59] <seb128> it takes 6 to 8 tries to get it
[18:59] <seb128> I sometime to esc between to display the screensaver and try again though
[18:59] <seb128> not sure if that makes a difference
[19:00] <kees> the 5th failure shuts down the password prompt dialog, at which point g-ss will sometimes crash
[19:00] <kees> I can't reproduce it under gdb
[19:00] <seb128> I don't always get it on the 5th try I think, but I'm not sure
[19:01] <seb128> kees, run gnome-screensaver --sync --no-daemon and attach gdb from an another vt
[19:01] <seb128> then break on gdk_x_error?
[19:01] <kees> oh, good idea
[19:01] <seb128> that's what I do there
[19:01] <seb128> because otherwise I had no way to go back to gdb to type "bt" there
[19:01] <seb128> since the screensaver was frozen on the session
[19:04] <kees> hrm, I still can't get it to crash now.
[19:13] <kees> tedg, bryce_: either of you working on inkscape pre4 for karmic yet?
[19:15] <tedg> kees: No, I haven't made a package.
[19:15] <chrisccoulson> kees - my eyes are starting to hurt trying to figure out how gnome-screensaver works right now - i'm going to send the bug upstream just in case they come up with some ideas before we do
[19:15] <tedg> kees: It should just be the grab tarball thing, right?
[19:15] <bryce_> kees, I've not looked at it
[19:16] <bryce_> hmm, ought inkscape have released by now?  getting kinda late...
[19:16] <tedg> bryce_: Apparently one planned patch is outstanding.
[19:16] <kees> chrisccoulson: ok
[19:16] <tedg> bryce_: And translation updates.
[19:17] <kees> tedg: yeah, me either.  I'll snag the tarball
[19:17] <tedg> kees: What's the command to grab the tarball, I'm looking, but I never remember it.
[19:18] <kees> tedg: "uscan" (I'm running it now...)
[19:21]  * tedg tries "iscan" but apparently it only works when you tell other people "you scan"  (hmm, pronunciation puns don't work well over IRC)
[19:22] <kirkland> mvo: ping?
[19:22] <kirkland> mvo: I have that qemu-kvm upload ready to go...  did you have that transitional package patch for me?
[19:23] <bryce_> tedg, we all scan
[19:23] <bryce_> (our eyes can)
[19:24] <tedg> bryce_: Heh, you're not convincing me that these type of jokes are good for IRC ;)
[19:24] <kirkland> mvo: okay, i found https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/451508 from james_w
[19:24] <james_w> kirkland: good timing :-)
[19:25] <kirkland> james_w: thanks, man!
[19:25] <seb128> debfx, I've uploaded your debdiff I'm too busy to argue but I will probably not keep the workaround in karmic+1 so you should still look at make things work with KDE correctly
[19:30] <mvo> kirkland: yeah, that the one
[19:31] <kirkland> mvo: perfect, got it!
[19:32] <mvo> cool, thanks
[19:33] <cjwatson> bryce_: I'm experimenting with it now in conjunction with a usplash change Scott suggested
[19:33] <cjwatson> bryce_: apparently it's working nicely for him, and gets us away from an ugly transition that's attracting a lot of attention
[19:33] <cjwatson> bryce_: not got it working for me yet, though, just wanted to check whether I was wasting my time
[19:36] <bryce_> cjwatson, ideally for something like this I'd like to see some good coverage to make sure we're not improving one driver at the expense of others, it's getting kind of late to make a decision on it though
[19:37] <cjwatson> is it all that driver-specific? aside from KMS vs. non-KMS
[19:37] <cjwatson> my plan was to only pass that option if KMS is up; we can't do very much about the non-KMS usplash->xsplash transition anyway
[19:38] <bryce_> cjwatson, well, mainly I'm thinking of an earlier patch that affected how root background was handled, which provided a nice solid performance boost on -fglrx, but after we put it in we found it caused nasty window corruption issues for kde users on a few other video drivers
[19:38] <bryce_> I guess if it's limited to only KMS, that narrows it to one driver effectively (at least for Karmic) so that'd reduce the risk
[19:39] <bryce_> still worth testing at least with ati KMS; folks are starting to use that now even though it's not the default
[19:39] <cjwatson> mm, right
[19:39] <cjwatson> if it isn't obvious, what I'm trying to do is leave the usplash logo on-screen until xsplash gets around to replacing it
[19:39] <bryce_> right
[19:39] <cjwatson> incidentally when testing this sort of thing I REALLY want network-manager to get a command-line interface that we install by default
[19:40] <bryce_> AGREED
[19:40] <bryce_> I run into that problem a lot
[19:40] <mathiaz> kirkland: hey - doing an UEC install - run into this problem: http://paste.ubuntu.com/293351/
[19:40] <cjwatson> having no working X and being unable to apt-get install <last version of stuff that worked> is no fun
[19:40] <bryce_> I suppose if I were less lazy I'd figure out a workaround
[19:40] <mathiaz> kirkland: have you seen this with the current packages?
[19:40] <bryce_> cjwatson, yuppers
[19:40] <mathiaz> kirkland: note that this is not an ISO install
[19:40] <cjwatson> there are a couple of command-line interfaces floating around the internet, but of course I can't download them right now
[19:40] <mathiaz> kirkland: just a package install on a base system
[19:40] <kirkland> mathiaz: i've never seen that on
[19:42] <cjwatson> there was a python one which I contemplated just typing in interactively, but (a) it looked a bit hatstand and (b) it didn't actually support activating connections
[19:43] <bryce_> cjwatson, fwiw I recall noticing asac had a wireless-with-no-x-running setup on his laptop once when I was helping him with an X problem.  I've neglected to inquire what that was, but maybe he knows a good trick
[19:44] <cjwatson> it may depend on the wireless driver
[19:44] <cjwatson> some of them, you can just dhclient
[19:44] <bryce_> ah could be
[19:44] <cjwatson> in fact I'm sure I used to be able to do mine that way, or maybe I had /e/n/i configured
[19:51] <debfx> seb128: ok, thanks
[21:06] <pitti> Riddell: any idea what happened to PyKDE4.kdecore?
[21:07] <pitti> /usr/lib/pyshared/python2.6/PyKDE4/kdecore.so
[21:07] <pitti> hm
[21:07] <pitti> $ python -c 'import PyKDE4.kdecore'
[21:07] <pitti> ImportError: No module named kdecore
[21:09] <mathiaz> http://paste.ubuntu.com/293427/ <- does this mean there are multiple ip addresses for eth0?
[21:10] <pitti> mathiaz: you might have virtual subdevices, such as eth0:avahi?
[21:11] <mathiaz> pitti: probably - how can I tell?
[21:11] <pitti> mathiaz: check "ifconfig eth0"?
[21:11]  * pitti isn't familiar with ip output, sorry
[21:11] <mathiaz> pitti: http://paste.ubuntu.com/293430/
[21:12] <mathiaz> pitti: well - I've seen that a couple of times - dhclient gets the 10.X address and then avahi starts and there is the 169.Y address
[21:12] <pitti> mathiaz: erm, sorry; does "ifconfig" give multiple interfaces for eth0? above looks pretty normal
[21:12] <mathiaz> pitti: nope
[21:12] <pitti> mathiaz: yes, it's supposed to actually
[21:12] <mathiaz> pitti: ifconfig -a only shows one interface for eth0
[21:13] <mathiaz> pitti: the 10.X address has disappeared from ifconfig
[21:13] <pitti> in the past it used to run avahi-autoipd on them which created virtual subdevices for link-local addresses
[21:13] <pitti> but apparenty that changed
[21:13] <mathiaz> pitti: although the system is reachable via the 10.X address
[21:14] <mathiaz> pitti: the problem here is that I'm trying to get the IP address of the system
[21:14] <mathiaz> pitti: and ifconfig shows 169.X which is not working well
[21:15] <Lure> pitti: afaik, due to python-sip4 upgrade (license issue), whole PyQt depends needs to be rebuild
[21:15] <Lure> pitti: so it may be related to this
[21:21] <pitti> Lure: right, but that already happened for kdebindings
[21:21] <pitti> see bug 450851
[21:29] <pitti> ah, got it
[21:30] <pitti> /usr/lib/python2.6/dist-packages/PyKDE4/__init__.pyc still stayed around
[21:41] <pitti> ... only to get the next crash, darn
[21:45] <mathiaz> pitti: bug 441669 <- does that ring a bell?
[21:49] <kees> pitti, slangasek: I'd like to get some eyes on bug 449535 before I upload what I think is the fix.  e.g. I don't want to break it further.
[21:49] <kees> (I'm assuming cjwatson is asleep, and mvo is offline)
[21:54] <slangasek> kees: looking
[22:03] <slangasek> kees: I still get an 'E: The update command takes no arguments'
[22:03] <kees> slangasek: with the evals missing?
[22:04] <slangasek> kees: yes; the eval isn't the cause of that error
[22:04] <slangasek> the 'update' needs to be moved to the end of the commandline, after the -o
[22:04] <kees> hrm
[22:04] <kees> + apt-get -y update -o APT::Update::Auth-Failure::=cp /usr/share/apt/apt-auth-failure.note /var/lib/update-notifier/user.d/
[22:04] <kees> Ign file: karmic/main Translation-en_US
[22:05] <kees> I didn't need that...
[22:05] <slangasek> kees: ah, because you set VERBOSE
[22:05] <slangasek> if it's not set, the command is 'apt-get -qq -y update -o ...', which fails for some reason
[22:06] <slangasek> heh, the apt-get manpage says never to use '-qq update', and that '-qq -y' is redundant :P
[22:06] <kees> with verbose unset, it runs correctly with eval removed...
[22:06] <kees> oh, no, my bad
[22:07] <kees> those evals are still wrong...
[22:07] <slangasek> the evals are wrong, yes
[22:07] <slangasek> I don't know what possessed someone to put those there
[22:08] <kees> + apt-get -qq -y -o 'APT::Update::Auth-Failure::=cp /usr/share/apt/apt-auth-failure.note /var/lib/update-notifier/user.d/' update '2>/dev/null'
[22:09] <kees> E: The update command takes no arguments
[22:09] <kees> hrm
[22:09] <kees> oh, heh, the redirection is getting escaped.  ;)
[22:10] <kees> that's what the eval is for?  madness
[22:10] <slangasek> oh, I suppose it is
[22:10] <slangasek> nice :)
[22:10] <slangasek> so, ok, the eval isn't broken, just CRAAAAAZZY
[22:11] <kees> right, so actually the originally suggested patch is more correct...
[22:34] <chrisccoulson> kees - you had a look at this screensaver issue at all?
[22:35] <kees> chrisccoulson: got side-tracked, sorry
[22:35] <chrisccoulson> no worries ;)
[22:37] <chrisccoulson> i have my suspicions what might be triggering it, but i'm having a hard time trying to figure out how to prove it
[22:40] <kees> chrisccoulson: seems like the "shake" animation somehow?
[22:41] <chrisccoulson> yeah, on each shake iteration, some events are queued on the main loop to realign and redraw the window contents. i suspect what might be happening is that the lock dialog disappears whilst the events are being dispatched (when gnome-screensaver-dialog exits)
[22:42] <chrisccoulson> i'm going to rebuild gnome-screensaver with some extra debug info in, to give me a better idea what order the different events get dispatched in
[22:42] <chrisccoulson> just to see if there is a difference between crashing/not crashing
[22:43] <kees> chrisccoulson: I also noticed that sometimes while validating, the dialog with grey out the "unlock" button and highlight "cancel" for a moment before shaking.  other times, the whole dialog would go grey before the shake.
[22:44] <chrisccoulson> yeah, i'm not too sure why that would be
[22:47] <mdke> pitti: I think probably for the fix to bug 441401 to become available for ubuntu-docs, the langpacks need to be rebuilt? Am I right? The bug is still appearing with ubuntu-docs 9.10.10 which has now been published (ie the symlink is still broken)
[22:47]  * chrisccoulson is thinking xtrace is going to come in handy here for me
[22:48] <mdke> pitti: if I'm right, then I'll just wait for the next langpacks. If not I'll do some more digging :)
[22:52] <slangasek> mdke: why is ubuntu-docs suddenly so much bigger?
[22:52] <slangasek> it looks like the language split has been dropped?
[22:56] <chrisccoulson> kees - the X call which generates the error is actually CreatePixmap (as shown in my xtrace log here: http://paste.ubuntu.com/293501/ )
[22:56] <chrisccoulson> the invalid drawable is 0x05400020, which my log shows was destroyed earlier on
[22:56] <chrisccoulson> which sort-of backs up my suspicion
[22:57] <chrisccoulson> so the fix is probably for gnome-screensaver-dialog to not exit on its own accord after 5 failed auth attempts, but rather wait for gnome-screensaver to kill it after it has done the shake animation
[22:58] <kees> chrisccoulson: yeah
[22:58] <chrisccoulson> i hope that's it anyway
[22:59] <asac> bryce_: connections marked as automatically connect + available to all users should work without X
[23:02] <bryce_> asac, ah 'available to all users'... hadn't seen that option, I'll look for it
[23:14] <ScottK> lamont: What's the status on maven?  ETOOHARD?
[23:26] <slangasek> kees: are you uploading the 449535 fix, then?
[23:26] <kees> slangasek: yeah
[23:26] <slangasek> ok
[23:29] <kees> slangasek: er, no, after looking at the bzr tree, I'd like mvo to do it -- there are a number of changes pending
[23:29] <slangasek> ok
[23:29] <slangasek> seems the bug has been there long enough that one more day won't make much difference
[23:30]  * kees nods
[23:34] <slangasek> mdke, pitti: is the "ubuntu-docs has ballooned" bug known to be linked to bug #441401, or is it a new issue?
[23:43] <lamont> ScottK: EPOSTKARMIC I expect - it's below a few other much more critical activities
[23:46]  * lamont afk
[23:46] <ScottK> lamont: OK.  Would you please comment in the relevant bugs then.
[23:46] <ScottK> slangasek: ^^^ I think we need to remove maven2 then, since it's currently, as I understand it broken.
[23:47] <lamont> gar.  once I read the ticket to see where doko got to with his trying to get something installable for me to use for bootstrapping
[23:47] <ScottK> OK.
[23:49] <TheMuso> /c/c