[00:32] <directhex> anyone else have broken colorspace issues on video files using nvidia on karmic?
[00:33] <chrisccoulson> how broken? i know there is an issue with totem and nvidia users having to adjust the hue when they first run it
[00:40] <TheMuso> directhex: I used to have weird colour issues when viewing flv/youtube videos in mplayer/totem/xine earlier in the cycle, although after a fresh install, that went away.
[00:40] <directhex> chrisccoulson, adjust it where? the weird thing is it's fine for the duration of having nvidia-settings running
[00:41] <chrisccoulson> directhex - that's wierd. i had to adjust the hue slider to the center in totem preferences when i did a fresh install
[00:41] <directhex> hm, not anymore. worked last week
[00:42] <directhex> wow, wait, what? chrisccoulson, well spotted! why is that randomly so low?
[00:42] <chrisccoulson> directhex - that's likely the same issue as bug 395476
[00:43] <directhex> low priority?
[00:44] <chrisccoulson> heh, i'm not sure who set that
[00:44] <directhex> YokoZar i guess
[00:55] <LaserJock> dailies up in ~ 1 hr?
[01:00] <kees> Keybuk: bug 452503 -- both "file" and older "blkid" worked correctly.
[01:01] <Keybuk> kees: did older vol_id work correctly?
[01:01] <Keybuk> actually, the argument is that file is working *in*correctly
[01:01] <kees> or blkid should say "LUKS" but it doesn't
[01:01] <Keybuk> blkid should say neither
[01:01] <Keybuk> it has BOTH metadata
[01:01] <kees> the main point is that it _is_ a valid swap partition.  the kernel can use it, etc
[01:02] <Keybuk> it could be either, you can't pick one without risking corrupting the other
[01:02] <Keybuk> yes, but blkid doesn't know it's *not* a valid LUKS partition
[01:02] <Keybuk> that's the point
[01:02] <kees> ok, that's reasonable.
[01:02] <kees> it'd be nice to have a --verbose :)
[01:02] <Keybuk> if blkid tells you it's swap, and you really meant LUKS, you just trashed your LUKS
[01:02] <Keybuk> if blkid tells you it's LUKS, and you really meant swap, you just trashed your swap
[01:02] <Keybuk> now
[01:02] <Keybuk> replace LUKS and swap in those with
[01:02] <Keybuk> say
[01:02] <Keybuk> ext4 and vfat
[01:02]  * kees nods
[01:02] <Keybuk> (which are the other common pairs)
[01:02] <Keybuk> that's why this is a Won't Fix
[01:02] <kees> almost seems like a bug in mkswap then...
[01:03] <Keybuk> indeed, I'm surprised mkswap didn't wipe
[01:03] <Keybuk> that is certainly a bug
[01:03] <Keybuk> especially given ff3bed806863d1c2075d0efda70b39ea6af9ecba
[01:03] <Keybuk> which is the code in mkswap to explicitly wipe things out
[01:04]  * kees changes the bug title's name
[01:04] <kees> er, bug's title
[01:05] <AdamSchackart> quick question, what VCS are you guys using?
[01:06] <LaserJock> AdamSchackart: all kinds but mostly bzr is what you'll find in Ubuntu
[01:06] <Keybuk> AdamSchackart: bzr and git
[01:06] <AdamSchackart> cool
[01:08] <mathiaz> Keybuk: hey - upstart job question
[01:08] <mathiaz> Keybuk: http://people.canonical.com/~mathiaz/eucalyptus.conf
[01:08] <mathiaz> Keybuk: ^^ will the opts variable be passed to the exec?
[01:08] <Keybuk> mathiaz: no.
[01:08] <mathiaz> Keybuk: ah!
[01:08] <mathiaz> Keybuk: how should this be done?
[01:08] <ion> script
[01:08] <Keybuk> mdz has some weird things elsewhere to output that stuff to a file, then source the file in the exec line
[01:08] <ion>   opts=foo
[01:09] <ion>   exec $opts
[01:09] <ion> end script
[01:09] <Keybuk> alternatively just put the whole lot of pre-start and exec into one script
[01:09] <Keybuk> as ion just demo'd :p
[01:09] <mathiaz> Keybuk: great - thanks
[01:09] <mathiaz> ion: thanks as well
[01:10] <Keybuk> holy crap, I just read the moblin sreadahead pack
[01:10] <Keybuk> and really wish I hadn't
[01:10] <Keybuk> this thing really is SSD optimised ;)
[01:10] <Keybuk> find / | make-pack
[01:11] <ion> Hehe
[01:11] <Keybuk> oh, I see
[01:11] <Keybuk> then that mincore()s it
[01:11] <Keybuk> so it's not quite as crazy
[01:11] <ion> Ah
[01:12] <slangasek> Keybuk: so if you call 'stop' in a script instead of a pre-start script, does it still work?
[01:14] <slangasek> (i.e., the only thing you don't want to do in a script is fork another process that's not the one to be supervised?)
[01:17] <mathiaz> Keybuk: exec . /var/run/eucalyptus/eucalyptus.options && eucalyptus-cloud $opts
[01:17] <mathiaz> Keybuk: would something like this ^^ work?
[01:17] <mathiaz> Keybuk: (provided that the opts are dumped correctly in /var/run/eucalyptus/eucalyptus.options in the pre-start part of the job)
[01:18] <chrisccoulson> is kees likely to be about this evening?
[01:19] <kees> chrisccoulson: he is! :)
[01:20] <slangasek> mathiaz: a) should be in a script instead; b) really would be better to not need the tmp file
[01:20] <mathiaz> slangasek: ok
[01:21] <chrisccoulson> kees - i'm confused - i don't see you on the list of users ;)
[01:21] <slangasek> mathiaz: I think the current script has a bug anyway, because calling "exit 0" from pre-start doesn't stop the job from running, which I think is what the goal was there?
[01:21] <mathiaz> slangasek: should I exec in the script?
[01:21] <chrisccoulson> must be empathy playing up!
[01:21] <slangasek> mathiaz: yes
[01:22] <chrisccoulson> kees - i have a patch for the screensaver issue. not sure if you want to take a quick look at it (or test it)?
[01:22] <chrisccoulson> it seems to be working ok here
[01:22] <kees> chrisccoulson: sure!
[01:23] <chrisccoulson> kees - the patch is here: http://pastebin.com/m239703a2
[01:23] <slangasek> mathiaz: do you want the job to fail, or just not stop, if eucalyptus is not configured yet?
[01:23] <mathiaz> slangasek: hm - what does "just not stop" mean?
[01:24] <slangasek> mathiaz: it means "just not start" :-)
[01:24] <slangasek> mathiaz: modulo the answer to the above question, I think what you really want is this: http://people.canonical.com/~vorlon/eucalyptus.conf
[01:25] <mathiaz> slangasek: exit 1 will make the job fail?
[01:25] <slangasek> mathiaz: if you want the job to stop instead of failing, you can replace 'exit 1' with 'stop'; and then you can also mark the job as 'respawn'...
[01:25] <slangasek> mathiaz: yes
[01:25] <mathiaz> slangasek: exit 0 will make the job not start ?
[01:25] <slangasek> no
[01:25] <kees> chrisccoulson: nice!
[01:26] <slangasek> mathiaz: exit 0 called from the pre-start script just says "the script is done, exited successfully" and the job will still start
[01:26] <kees> chrisccoulson: can you attach that to the bug, and I can get it built and get a freeze exception.
[01:26] <mathiaz> slangasek: what does script+respawn do then?
[01:26] <mathiaz> slangasek: it reruns the script until it's successfull?
[01:27] <slangasek> mathiaz: 'exec foo' is shorthand for 'script exec foo end script'
[01:27] <slangasek> mathiaz: for a normal job, the definition of "successful" is "running"
[01:28] <slangasek> mathiaz: "respawn" says "if the job dies for any reason, respawn it"
[01:28] <chrisccoulson> kees - yeah, no worries. i can push it to ubuntu-desktop bzr if you're happy with the change
[01:28] <mathiaz> slangasek: ok
[01:28] <slangasek> mathiaz: updated the script a little, to use the Keybuk-approved 'stop' runes
[01:28] <kees> chrisccoulson: if it works, yeah!  :)
[01:29] <mathiaz> slangasek: { stop; exit 0; }
[01:29] <mathiaz> slangasek: ^^ that will mark the job as stopped
[01:29] <slangasek> mathiaz: yes
[01:29] <mathiaz> slangasek: if euca_conf is not there
[01:30] <mathiaz> slangasek: however exit 1 will make the job fail if it's not configured
[01:30] <slangasek> mathiaz: right - hence, asking what you want the behavior to be :)
[01:30] <mathiaz> slangasek: ok - just making sure I understand the semantics :)
[01:33] <mathiaz> slangasek: hmmm... so what's the difference between a failed job and a stopped job?
[01:33] <mathiaz> slangasek: the default configuration after package installation should be a working one
[01:33] <slangasek> mathiaz: whether or not 'respawn' will try to start it again :)
[01:33] <slangasek> (and what gets logged, etc)
[01:33] <slangasek> I would expect eucalyptus-cloud to be a normal service, where you want init to be the process supervisor and respawn it if needed
[01:34] <mathiaz> slangasek: yes
[01:34] <slangasek> so I think you want to change that 'exit 1' to a 'stop; exit 0' and then add 'respawn'
[01:34] <mathiaz> slangasek: even if there isn't any respawn option?
[01:34] <mathiaz> slangasek: ok
[01:34] <slangasek> mathiaz: updated again, have a look there
[01:34] <mathiaz> slangasek: what would 'exit 1' + no respawn option do?
[01:35] <mathiaz> slangasek: in the case of a non-configured system
[01:35] <slangasek> mathiaz: result in the job being marked failed, with upstart not trying to restart it
[01:36] <slangasek> but, if you want upstart to *ever* restart your job for you when it dies, you need 'respawn', and then you want to write your job to avoid upstart getting into a busy loop
[01:37] <mathiaz> slangasek: busy loop meaning that the job would always fail and upstart would always restart it?
[01:40] <ion> Upstart will stop trying if it’s respawning too fast for a while.
[01:41] <Keybuk> the difference between exit 1 and { stop ; exit 0; } is, basically, in the return code ;)
[01:41] <Keybuk> a job that just does exit 1 is marked failed
[01:42] <Keybuk> the event tells everybody that you failed
[01:42] <Keybuk> and that it was your pre-start that failed
[01:42] <Keybuk> the user who runs "start" gets told it failed, and gets a "1" return code
[01:42] <Keybuk> etc.
[01:42] <Keybuk> { stop; exit 0; } means you're not marked failed
[01:42] <Keybuk> you just stopped again
[01:42] <Keybuk> the event says you stopped normally
[01:42] <chrisccoulson> kees - i've pushed the change to bzr now. do you want me to subscribe u-m-s or will you handle this?
[01:43] <kees> chrisccoulson: I can handle that, thanks!
[01:43] <Keybuk> the user gets told (basically) that the job they wanted started, stopped again
[01:43] <Keybuk> etc.
[01:43] <chrisccoulson> kees - thank you too:)
[01:43] <Keybuk> probably the biggest difference is that you don't get a console message ;)
[01:44] <mathiaz> Keybuk: so for the use case of: 'service not configured' what is the option to tell the user to first configuring the service before retrying to start?
[01:45] <Keybuk> mathiaz: there's no method to do that right now
[01:45] <mathiaz> Keybuk: failed job or start/stopped job?
[01:45] <mathiaz> Keybuk: which are the existing options for now
[01:46] <Keybuk> as slangasek says, we've settled on stop
[01:46] <mathiaz> Keybuk: ok
[01:46] <Keybuk> in the next version of Upstart, you won't need that at all
[01:46] <slangasek> mathiaz: are you assuming that the output of the pre-start script will be passed to the user calling 'start'?
[01:46] <Keybuk> you can just ship your package in manual mode
[01:47] <Keybuk> (then it won't be automatically started - but will be started if the sysadmin starts it by hand)
[01:47] <ion> Keybuk is planning to implement output logging for jobs. With it, it would be easy to print what the script said when e.g. the start command fails.
[01:47] <mathiaz> slangasek: hm not really.
[01:47] <slangasek> mathiaz: ok good ;)
[01:47] <mathiaz> slangasek: I'm just asking questions about how upstart works :D
[01:48] <Keybuk> mathiaz: the problem is I tend to answer such questions with the question "how do you think it should work?"
[01:49] <Keybuk> ion: yes, but Keybuk is also planning to implement manual mode - which will do away with the need to say "aha! you didn't enable it"
[01:49] <mathiaz> Keybuk: ah ok. Than I'd like to be able to tell the user to configure the service by editing this file before attempting to restart the job
[01:49] <Keybuk> mathiaz: you can't do that
[01:50] <LaserJock> so ... how bad is it to do a Pre-Depends if you can't see a reasonable way without it?
[01:50] <mathiaz> Keybuk: right - I understand that. I'll use the stop+exit0 for now
[01:50] <Keybuk> personally I strongly dislike that kind of message anyway
[01:50] <Keybuk> "start foo" ... "but you didn't enable foo"
[01:51] <Keybuk> "yes, but I just told you to start it, stop being stupid and do what I told you"
[01:52] <slangasek> Keybuk: the use case here isn't /enabling/ foo, it's /configuring/ foo
[01:52] <Keybuk> slangasek: well, that's different ;)
[01:52] <mathiaz> Keybuk: so you don't consider that upstart could help the sysadmin in diagnosing wrong configuration?
[01:52] <slangasek> yes, it is
[01:52] <slangasek> :)
[01:52] <mathiaz> Keybuk: a similar use case is to check for incompatible options
[01:53] <Keybuk> in that case, you probably *do* want to exit 1
[01:53]  * Keybuk misunderstood, sorry
[01:53] <mathiaz> Keybuk: right - that's a good use of failed job
[01:54] <mathiaz> Keybuk: IIUC there isn't for now good logging?
[01:54] <slangasek> Keybuk: "respawn" only affects the main script, not pre-start, yes?
[01:54] <Keybuk> slangasek: we don't respawn pre-start scripts ;)
[01:54]  * slangasek nods
[01:54] <mathiaz> Keybuk: like being able to say: your job has failed because foo option is incompitble with bar
[01:54] <Keybuk> but a pre-start script failed stops the job in a way that won't be respawned
[01:55] <slangasek> who here knows how to grab translations out of rosetta for, e.g., ubiquity?
[01:56] <mathiaz> slangasek: seems like your eucalyptus job is doing what it's supposed to then
[01:56] <slangasek> mathiaz: except Keybuk suggests 'exit 1' is better for the unconfigured case
[01:56] <slangasek> instead of stop ; exit 0
[01:56] <mathiaz> huh?
[01:56] <LaserJock> slangasek: mind if I upload this: http://launchpadlibrarian.net/33762653/moodle_1.9.4.dfsg-0ubuntu3.debdiff ?
[01:56] <Keybuk> if it's unconfigured, or the configuration is wrong, that's a failure
[01:57] <Keybuk> you want that communicated
[01:57] <Keybuk> it's not the same as "you didn't put splash on the kernel command-line" (which is a normal condition meaning the job is disabled)
[01:57] <mathiaz> Keybuk: ok - gotcha now.
[01:59] <slangasek> LaserJock: <blink> what's the libc6 change that makes this necessary?
[01:59] <slangasek> LaserJock: oh, it's doing IPv6
[02:00] <LaserJock> slangasek: yep
[02:00] <LaserJock> slangasek: you get a 403 when trying to configure moodle without that patch
[02:00] <slangasek> LaserJock: I think you probably want to list both values, then?  Otherwise, you'll also be denying connections to <hostname> on systems that have dynamic IPs, which is arguably a regression?
[02:00] <LaserJock> slangasek: ok, makes sense
[02:00] <slangasek> (since /etc/hosts is set up with 127.0.1.1 <hostname>, and users may expect that to work)
[02:01] <mathiaz> kees: has eucalyptus 1.6~bzr931-0ubuntu4 been already uploaded?
[02:01] <mathiaz> kees: the bzr branch still show UNRELEASED
[02:01] <LaserJock> slangasek: but good to go with that change?
[02:01] <Keybuk> damnit, fingers, remember how GRUB1 works
[02:02] <slangasek> LaserJock: I think so, yes
[02:20] <Keybuk> oh
[02:20] <Keybuk> that's neate
[02:21] <Keybuk> echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink
[02:27] <Keybuk> slangasek: would you have any objection if we did something like
[02:27] <Keybuk> tty1 - boot messages, then a getty
[02:27] <Keybuk> tty2 - splash, then X
[02:27] <Keybuk> tty3+ - more gettys, if configuration allows
[02:29] <Keybuk> (lynx obviously)
[02:30] <Amaranth> Where do the other Xes go?
[02:30] <Keybuk> that's what I mean
[02:31] <Keybuk> ie. we hardcode something to own tty1
[02:31] <Keybuk> we make usplash appear on tty2, then move it out of the way for X
[02:31] <Keybuk> X will claim the first free tty (taking out the tty7 hardcode), which will be tty2
[02:31] <Keybuk> then tty3+ will be gettys and Xs depending on configuration
[02:31] <Keybuk> each taking the first free
[02:32] <Keybuk> if we don't boot with splash, you stay on tty1 until X chvts
[02:32] <Keybuk> and then you see useful messages
[02:32] <Amaranth> ah, neat
[02:33] <Keybuk> if boot appears to hang while usplash is up Ctrl-Alt-F1 will take you to useful messages
[02:33] <Keybuk> (Alt-F1 even)
[02:33] <Keybuk> Ctrl-Alt-F1 will still work in X
[02:35] <Keybuk> we could use tty7 for splash/X but then we need to keep the ugly hack that makes it go there
[02:35] <Keybuk> the hack that I keep breaking by accident :p
[02:36] <Keybuk> and then if you had only one getty configured, you'd have the weird thing where the second X login would be on tty2 ;P
[02:48] <docro> HI! I was wondering if anyone has noticed the default netcat behavior for waiting on STDIN has been changed. It appears that it indefintely waits on stdin, whereas the default use to be to terminated immediately upon EOF
[02:49] <docro> this seems to be a result of the addition of the -q flag, but I can't be entirely sure
[02:52] <Keybuk> docro: I don't think that's changed
[02:52] <Keybuk> netcat has always been a bit weird about EOF
[02:53] <docro> I know at least in suse distros it termiantes immediately on stdin closing
[02:53] <docro> echo "foo" | netcat server.com
[02:53] <docro> will close once foo is written
[02:53] <docro> let me grab the version #s real quickl
[02:55] <docro> ubuntu: [v1.10-38] ... SLES 11: [v1.10]
[02:55] <docro> SLES11 does not offer the -q option in its version of netcat
[02:56] <Keybuk> docro: suse could have patched it
[02:56] <docro> Keybuk are you running ubuntu right now?
[02:56] <docro> I doubt they would patch functionality OUT of netcat
[02:56] <Keybuk> docro: yes.
[02:57] <docro> what version? if not 9.04 can you test the behavior
[02:57] <Keybuk> 9.10
[02:57] <docro> what version of netcat? netcat -h will show
[02:57] <Keybuk> as you say, v1.10-38
[02:58] <docro> hmmm I guess I would need to troll through commits to netcat in both distro to figure it out
[02:58] <Keybuk> the documentation says without -q, it will not quit on EOF on STDIN
[02:58] <docro> for now I have juas aliased netcat to netcat -q 0
[02:58] <docro> Keybuk: the ubuntu documentation, yes
[03:00] <Keybuk> docro: just about every tool has minor differences between distros
[03:00] <docro> Keybuk: agreed, it's just causing me grief :) I was wondering if ubuntu ever worked the other way
[03:00] <Keybuk> I don't think so, we inherit from Debian
[03:01] <docro> not closing on EOF is not really a minor difference
[03:01] <Keybuk> according to the changelog, -q isn't even *in* the upstream netcat ;)
[03:01] <Keybuk> it looks like netcat is one of those "maintained by patches" tools
[03:02] <docro> I have lots of code that depends on netcat closing upon EOF to gather results
[03:02] <docro> because that is how it works in red hat and suse
[03:02] <Keybuk> it looks like there's netcat-bsd and netcat-traditional in Ubuntu as well
[03:02] <docro> hmm
[03:02] <docro> Maybe I will try those
[03:02] <docro> thanks :)
[03:02] <Keybuk> docro: and just as many people (more in fact, we have more users <g>) have code that depends on netcat not closing on EOF
[03:03] <docro> Keybuk: you have more desktop users maybe :P
[03:03] <docro> enterprise is dominated with RH and SUSE
[03:03] <Keybuk> so? :)
[03:03] <docro> who pays the bills :)
[03:03] <Keybuk> they don't pay our bills
[03:04] <docro> not yet hehehe
[03:05] <docro> Thanks for your help though, I will try the traditional package. Otherwise I will just leave my alias in
[03:05] <sladen> docro: think OEMs, ODMs, SoC chip/CPU designers (... companies that actually have *serious* amounts of money)
[03:06] <docro> sladen i work for a company with serious amounts of money
[03:06] <docro> not that my nagging would make them pay up!
[03:06] <sladen> docro: I'd approach Canonical for a support contract :)
[03:07] <docro> sladen: currently one of the lone wolves moving towards desktop ubuntu for dev box and trying to get our tools working :) Doubtful our servers will ever go that way :(
[03:08] <docro> alright good night, thanks for the help again
[03:10] <Keybuk> he was pleasant
[03:10] <Keybuk> normally there's more depramming of toys
[03:11] <LaserJock> heh, depramming of toys, I like that
[03:39] <mathiaz> kirkland: have you seen https://code.launchpad.net/~mathiaz/eucalyptus/karmic-fix-cloud-upstart-job/+merge/13452?
[03:39] <mathiaz> kirkland: for https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/452665
[03:39] <kirkland> mathiaz: the upstart fixes?
[03:39] <kirkland> mathiaz: yeah
[03:39] <kirkland> mathiaz: why the respawn?
[03:41] <mathiaz> kirkland: if eucalytpus-cloud dies, you wanna get it restarted no?
[03:41] <kirkland> mathiaz: i think so; just didn't see a note about that in the changelog
[03:43] <kirkland> mathiaz: ifconfig eth0:1 169.254.169.254 netmask 255.255.255.255
[03:43] <kirkland> mathiaz: that looks to be working for me
[03:44] <mathiaz> kirkland: you may wanna call it differently
[03:44] <mathiaz> kirkland: like eth0:eucalocal
[03:44] <kirkland> mathiaz: i couldn't get it to work with a string
[03:44] <kirkland> mathiaz: only with an int
[03:44] <mathiaz> kirkland: avahi creates an eth0.avahi
[03:44] <mathiaz> kirkland: IIRC
[03:45] <mathiaz> kirkland: hm - may be you don't wanna have a virtual interface
[03:45] <kirkland> mathiaz: i couldn't get it to work with the ip command either
[03:45] <kirkland> mathiaz: had to use ifconfig
[03:46] <sladen> kirkland: ip ... label xyz
[03:48] <kirkland> sladen: hmmm
[03:48] <kirkland> sladen: sudo ip addr add 169.254.169.254/32 scope link dev eth0 label eth0:1 ?
[03:49] <sladen>  ... dev eth0:myfoo label eth0:myfoo
[03:50] <j1mc> ScottK: ping
[03:50] <kirkland> sladen: ubuntu@cluster:~$ sudo ip addr add 169.254.169.254/32 scope link dev eth0:9 label eth0:9
[03:50] <kirkland> RTNETLINK answers: File exists
[03:50] <sladen> kirkland:
[03:50] <sladen> j1mc:
[03:51] <mathiaz> kirkland: have you removed the existing 169.254.169.254/32 ?
[03:51] <sladen> kirkland: try adding an address that isn't in-use, eg   .169.253
[03:51] <kirkland> sladen: mathiaz; bingo
[03:54] <kirkland> mathiaz: would you like me to merge and upload your upstart changes?
[03:54] <kirkland> mathiaz: i have no objections
[03:54] <mathiaz> kirkland: yes please
[03:55] <slangasek> Keybuk: I would object to us changing that in karmic ... :)
[04:06] <kirkland> mathiaz: how much longer are you online
[04:06] <mathiaz> kirkland: don't know
[04:06] <mathiaz> kirkland: why?
[04:07] <mathiaz> kirkland: are you off tomorrow?
[04:07] <kirkland> mathiaz: i was thinking about it, but i didn't hear from alice
[04:07] <kirkland> mathiaz: i wanted you to review my eth device labeling
[04:07] <mathiaz> kirkland: why - do you have a fix to test?
[04:08] <kirkland> mathiaz: i'm testing it now
[04:08] <mathiaz> kirkland: sure - send a branch
[04:08] <kirkland> mathiaz: k
[04:09] <kirkland> mathiaz: the lintian output for eucalyptus is a mess
[04:16] <kirkland> mathiaz: brilliant!
[04:16] <kirkland> sladen: thanks for the pointer!
[04:16] <mathiaz> kirkland: I know - thanks :)
[04:28] <kirkland> mathiaz: lp:~kirkland/eucalyptus/eth-label
[04:35] <kirkland> mathiaz: looks like it's working to me
[04:36] <mathiaz> kirkland: I'll build a local version here and run through my tests
[04:38] <Teddy_> Hi there.  My package needs updating from Debian testing.  Is this the right place?
[04:51] <kirkland> kirkland: 1, scorpion: 0
[04:52] <kirkland> http://rookery.canonical.com/~kirkland/CIMG0097.jpg
[04:52] <kirkland> back to eucalyptus
[04:53] <mathiaz> kirkland: hm - build your branch
[04:53] <mathiaz> kirkland: upgraded packages - still 169.X on eth0
[04:53] <kirkland> mathiaz: i had to reboot
[04:54] <kirkland> mathiaz: restarting networking and eucalyptus might do it, though
[04:54] <mathiaz> kirkland: does this mean that on shutdown eucalyptus-cloud doesn't remove its ip address?
[04:54] <kirkland> mathiaz: probably
[04:54] <mathiaz> kirkland: well - the package upgrade should restart eucalyptus-cloud
[04:55] <mathiaz> kirkland: well - I've just rebooted my CC
[04:56] <kirkland> mathiaz: i'm fixing it to handle the pub and priv addresses too, with a label
[04:56] <kirkland> mathiaz: eth0:pub and eth0:priv
[04:56] <kirkland> mathiaz: for the guest ip's
[04:56] <kirkland> mathiaz: which are also stacked on eth0
[04:56] <mathiaz> kirkland: hm
[04:56] <mathiaz> kirkland: are you using multiple addresses?
[04:56] <kirkland> mathiaz: ?
[04:57] <mathiaz> kirkland: there can be more than one public IP assigned to the CC
[04:57] <mathiaz> kirkland: like .2 .3 .4 .5
[04:57] <mathiaz> kirkland: all assigned to the CC
[04:57] <kirkland> mathiaz: i'm not using an enumerator right now
[04:57] <kirkland> mathiaz: that's more complex
[04:57] <kirkland> mathiaz: mainly, i'm getting the superflous addresses off of eth0
[04:57] <mathiaz> kirkland: right - just saying - multiple public IPs are common
[04:57] <kirkland> mathiaz: and onto their own label
[04:58] <mathiaz> kirkland: right - so eth0:pub would have multiple public IPS
[04:58] <kirkland> mathiaz: i'm just fixing the ones that eucalyptus creates for vm guests
[04:58] <kirkland> mathiaz: right
[04:58] <mathiaz> kirkland: ok - if that works well that's great
[04:59] <kirkland> mathiaz: i'm pushing an update now
[04:59] <kirkland> mathiaz: did your CC come back up?
[04:59] <mathiaz> kirkland: yop
[04:59] <kirkland> mathiaz: actually, pushing to lp:~kirkland/eucalyptus/eth-label2
[04:59] <kirkland> mathiaz: and?  ifconfig says?  and ip addr says?
[05:00] <mathiaz> kirkland: the eht0:metadata is there :)
[05:00] <kirkland> mathiaz: nice
[05:00] <mathiaz> kirkland: let me check if instances are working correclty
[05:00] <kirkland> mathiaz: please
[05:00] <mathiaz> kirkland: http://paste.ubuntu.com/294367/
[05:01] <kirkland> mathiaz: looks good
[05:01] <kirkland> mathiaz: and ifconfig?
[05:01] <mathiaz> kirkland: well - there is still 169.X in there
[05:01] <mathiaz> kirkland: ifconfig properly shows eth0 and eth0:metadata
[05:01] <kirkland> mathiaz: pastebin that
[05:02] <mathiaz> kirkland: http://paste.ubuntu.com/294368/
[05:02] <kirkland> mathiaz: good
[05:02] <kirkland> mathiaz:           inet addr:192.168.12.118  Bcast:192.168.12.255  Mask:255.255.255.0
[05:02] <kirkland> mathiaz: that's the key one
[05:02] <mathiaz> kirkland: yes
[05:02] <kirkland> mathiaz: i'm please with that
[05:03]  * mathiaz nods
[05:03] <kirkland> mathiaz: okay, branch lp:~kirkland/eucalyptus/eth-label2
[05:03] <kirkland> mathiaz: sorry, had to push a new branch
[05:03] <kirkland> mathiaz: i uncommitted something, and things diverged
[05:03] <mathiaz> kirkland: now eucalyptus-ipaddr.conf uses ip addr
[05:03] <mathiaz> kirkland: ok
[05:03] <kirkland> mathiaz: yeah, i think it should use ifconfig
[05:03] <kirkland> mathiaz: but that's just my preference
[05:03] <kirkland> mathiaz: i'm not going to change it, but i would support someone else in doing so
[05:03] <mathiaz> kirkland: so I was poking around the configuration and found something interesting in /etc/eucalyptus/eucalyptus.conf
[05:04] <kirkland> mathiaz: ?
[05:04] <mathiaz> kirkland: VNET_PUBINTERFACE="eth0"
[05:04] <mathiaz> VNET_PRIVINTERFACE="eth0"
[05:04] <mathiaz> kirkland: seems that we already know which interface should be used for private /public interface
[05:04] <kirkland> mathiaz: i suspect that's intended for servers with multiple eth cards
[05:04] <kirkland> mathiaz: so you could put eth0 in one, and eth1 in the other
[05:05] <mathiaz> kirkland: so we wouldn't need to do the ip route default thingy
[05:05] <kirkland> mathiaz: oh!
[05:05] <mathiaz> kirkland: right - one of my setup is like that
[05:05] <kirkland> mathiaz: you mean to get the default interface
[05:05] <mathiaz> kirkland: yes
[05:05] <kirkland> mathiaz: yeah, good idea
[05:05] <mathiaz> kirkland: and in that setup the ip was wrong
[05:06] <mathiaz> kirkland: ie the avahi_publish process was using the wrong ip
[05:07] <mathiaz> kirkland: that being said things weren't working afterwards
[05:08] <mathiaz> kirkland: the NC was using the wrong IP address to access walrus
[05:09] <kirkland> mathiaz: ip addr show label eth0
[05:09] <kirkland> mathiaz: ;-)
[05:09] <kirkland> mathiaz: that drops the metadata labeled interfaces
[05:09] <mathiaz> kirkland: nice
[05:11] <mathiaz> kirkland: instances seem to be running correclty
[05:11] <kirkland> mathiaz: http://paste.ubuntu.com/294373/
[05:12] <mathiaz> kirkland: http://paste.ubuntu.com/294374/
[05:12] <mathiaz> kirkland: ^^ this is with a running instance
[05:13] <mathiaz> kirkland: with a public IP
[05:13] <kirkland> mathiaz: right, that's without my latest patch
[05:13] <mathiaz> kirkland: yop - I'm building your label2 branch
[05:21] <fabrice_sp> Hi. I've found a problem with binutils libs: the soname does no match the shlibs file. Is it still possible to get it fixed for Karmic, or it has to go though SRU, and will be fixed after release?
[05:26] <kirkland> mathiaz: http://pastebin.ubuntu.com/294379/
[05:27] <mathiaz> kirkland: 2x nice
[05:27] <kirkland> mathiaz: i'm quite happy with this
[05:27] <kirkland> mathiaz: perhaps would be better if there was an interator on :pub
[05:27] <kirkland> mathiaz: but, meh, this is easy, clean
[05:27] <mathiaz> kirkland: did you try to boot two instances?
[05:27] <mathiaz> kirkland: and see if two IPs can be added to the labeled interfaces?
[05:28] <kirkland> mathiaz: this is 2 instances
[05:28] <kirkland> mathiaz: see lines 49 and 50
[05:28] <mathiaz> kirkland: ah right
[05:29] <mathiaz> kirkland: I was looking at the ifconfig output
[05:29] <kirkland> mathiaz: and both can communicate
[05:29] <kirkland> mathiaz: right, that's what i mean by an iterator on :pub
[05:29] <mathiaz> kirkland: which only supports one IP
[05:29] <kirkland> mathiaz: yeah
[05:29] <kirkland> mathiaz: we could add the last octet of the ip address to that
[05:29] <kirkland> mathiaz: so mine would be eth0:pub30 and eth0:pub31
[05:29] <mathiaz> kirkland: can you log on both guests via their public IP address?
[05:29] <kirkland> mathiaz: yup
[05:30] <mathiaz> kirkland: well - you can necessarly use the last octet only
[05:30] <mathiaz> kirkland: what happens if you have a /16 network?
[05:31] <kirkland> mathiaz: eucalyptus only supports /24 networks
[05:31] <kirkland> mathiaz: dan told me that last week, while you were dozing in the car :-)
[05:31] <mathiaz> kirkland: :o
[05:31] <kirkland> mathiaz: for the public ip's
[05:31] <mathiaz> kirkland: hm well. I think for the time being the current solution is enough
[05:32] <kirkland> mathiaz: i agree
[05:32] <mathiaz> kirkland: we'll have to get upstream opinion on this
[05:32] <kirkland> mathiaz: we could also add a random string
[05:32] <mathiaz> kirkland: it's cleaner - is it worth putting in the release?
[05:32] <kirkland> mathiaz: i think it is
[05:32] <kirkland> mathiaz: i was going to roll all of this
[05:32] <kirkland> mathiaz: i could put it into a ppa right now
[05:32] <kirkland> mathiaz: until we get approval
[05:32] <mathiaz> kirkland: let me do more testing of label2
[05:33] <kirkland> mathiaz: agreed
[05:33] <mathiaz> kirkland: I don't think putting in a PPA is helpfull at this tage
[05:33] <mathiaz> kirkland: stage
[05:33] <kirkland> mathiaz: what more testing do you suggest?
[05:33] <kirkland> mathiaz: do you have it running yet?
[05:33] <mathiaz> kirkland: well - it's more that noone is using a PPA
[05:33] <mathiaz> kirkland: I'm upgrading
[05:33] <kirkland> mathiaz: eucalyptus has been using my ppa every day
[05:34] <kirkland> mathiaz: i meant ppa it for us + euca to test
[05:34] <mathiaz> kirkland: oh ok.
[05:34] <mathiaz> kirkland: I guess it could help then
[05:34] <kirkland> mathiaz: for the ~12 hours it would take to get an upload approved
[05:35] <kirkland> mathiaz: i think dan will gladly take this change
[05:35] <kirkland> mathiaz: it doesn't affect the actual networking, which was dan's concern
[05:35] <mathiaz> kirkland: so IIUC the 169.X address is not deleted when eucalyptus is stopped?
[05:35] <kirkland> mathiaz: the diff only adds a label argument
[05:36] <mathiaz> kirkland: right - which is a good thing
[05:36] <kirkland> mathiaz: that's probably true; and a bug
[05:36] <mathiaz> kirkland: right - priv and pub addresses are removed correctly
[05:37] <mathiaz> kirkland: what does happen to the :pub and :priv when there are no more instances running?
[05:37] <kirkland> mathiaz: let's find out!
[05:38] <kirkland> mathiaz: http://pastebin.ubuntu.com/294382/
[05:39] <kirkland> mathiaz: pub removed, priv not
[05:39] <mathiaz> kirkland: right - probably make sense
[05:40] <mathiaz> kirkland: the remaining address is the private gw IIRC
[05:40] <kirkland> mathiaz: ack
[05:41] <kirkland> mathiaz: did you see the fun you missed here tonight?  http://rookery.canonical.com/~kirkland/CIMG0097.jpg
[05:41] <kirkland> mathiaz: i had to take a 10 minute catch-the-scorpion-without-getting-stung-break
[05:41] <mathiaz> kirkland: well - fun - like you life was at stake?
[05:41] <mathiaz> kirkland: sounds like fun
[05:41] <kirkland> mathiaz: :-)
[05:42] <mathiaz> kirkland: who won?
[05:42] <kirkland> mathiaz: i'll save him in a jar for you
[05:42] <kirkland> mathiaz: it was a very close battle
[05:42] <kirkland> mathiaz: but i bested him with my wit, and stunning looks
[05:42] <mathiaz> kirkland: so you caught him alive?
[05:42] <kirkland> mathiaz: yessir.  in a jar now
[05:42] <kirkland> mathiaz: i'll save him for you
[05:43] <mathiaz> kirkland: tya
[05:43] <mathiaz> kirkland: will it survive 3/4 weeks?
[05:43] <kirkland> mathiaz: absolutely
[05:43] <kirkland> mathiaz: they can go a month without water
[05:43] <kirkland> mathiaz: i'll treat him better than that, though
[05:44] <kirkland> mathiaz: okay, what else should we do tonight?
[05:44] <kirkland> mathiaz: after the scorpion battle, i'm ready to turn in
[05:44] <kirkland> mathiaz: i think i'm going to commit this to the core-dev branch
[05:44] <mathiaz> kirkland: right
[05:44] <kirkland> mathiaz: push to my ppa
[05:44] <mathiaz> kirkland: I'd still ask upstream for their opinion
[05:44] <kirkland> mathiaz: email the relevant parties
[05:45] <kirkland> mathiaz: we need to get a release team member's approval to upload, right?
[05:45] <mathiaz> kirkland: well - you can upload - they will review it anyway
[05:45] <kirkland> mathiaz: ah
[05:45] <mathiaz> kirkland: it's actually easier for them
[05:46] <mathiaz> kirkland: as they will see the diff directly
[05:46] <mathiaz> kirkland: it just won't get in
[05:46] <kirkland> mathiaz: okay, should we wait to do that, until after we get upstream's opinion?
[05:46] <mathiaz> kirkland: yes - I'd wait for upstream's opinion
[05:46] <mathiaz> kirkland: if you push it to your PPA
[05:46] <kirkland> mathiaz: ack
[05:46] <mathiaz> kirkland: upstream can easily test it and give feedback
[05:47] <kirkland> mathiaz: should i upload the rest, minus my network change?
[05:47] <mathiaz> kirkland: if they're happy with it and accept the change, we can push into the archive
[05:47] <kirkland> mathiaz: okay, cool
[05:47] <mathiaz> kirkland: I wouldn't do two uploads
[05:47] <kirkland> mathiaz: cool
[05:47] <mathiaz> kirkland: I'll ask in the release meeting tomorrow morning
[05:48] <mathiaz> kirkland: the diff is not that big
[05:49] <kirkland> mathiaz: cool
[05:49] <kirkland> mathiaz: i think i have it
[05:50] <kirkland> mathiaz: pushed to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu/
[05:50] <kirkland> mathiaz: uploading to PPA
[05:51] <kirkland> mathiaz: uploaded
[05:51] <kirkland> mathiaz: emailing upstream
[06:03] <kirkland> mathiaz: mail sent, you're on cc
[06:21] <kirkland> mathiaz: nurmi likes it :-)
[06:22] <Laibsch> ArneGoetje: The information you asked for in bug 338217 has been given.  What now?
[06:22] <Laibsch> That ticket is receiving dupes almost daily now.
[06:33] <Laibsch1> @all, can we please see a sync to fix bug 444883?
[06:33] <Laibsch1> bug 444883
[06:47] <pitti> Good morning
[06:47] <ScottK> Good morning pitti.
[06:47] <pitti> hey ScottK, how are you ?
[06:48] <ScottK> Tired.
[06:48] <ScottK> I should be asleep.
[06:48] <ScottK> pitti: Do you still have your Latitude D430?
[06:48] <pitti> ScottK: yes, I do; you as well?
[06:48] <ScottK> Yes.
[06:49] <ScottK> I've been having trouble the last couple of days with lid opening not being recognized.
[06:49] <pitti> weird
[06:49] <pitti> ScottK: works quite well her
[06:49] <pitti> e
[06:49] <ScottK> So if I close the lid, it never notices it opens and so never turns the display back on.
[06:49] <ScottK> OK.
[06:50] <ScottK> I tried the previous intel driver, just to make sure and it's not that.
[06:50] <pitti> ScottK: could you do the following: install input-utils, then "sudo lsinput" and find the event number of the lid switch, then do "sudo input-events N" with that number and close/open the lid?
[06:50] <ScottK> I guess I'd have to ssh into the machine
[06:50] <liw> I had trouble once with the open/close sensor being wonky (it was a pin that got pushed in to indicate close, and the spring that pushed it back out went bad and didn't push it out enough)
[06:50] <ScottK> Because I won't have a working X
[06:50] <ScottK> It's not hardware
[06:51] <ScottK> Coming back from suspend on lid open works fine.
[06:52] <Laibsch1> I think ubuntu-laptop-mode should be removed: bug 450004
[06:54] <ArneGoetje> Laibsch: I can't fix the bug. In related (if not the same) bug #199592 Zhengpeng Hou has asked for testing his PPA package, so far no reply on that. As I cannot reproduce this issue at all anyways I'm afraid I'm unable to help on this issue. From the comments it seems to appear at random for some users.
[06:54] <Laibsch> OK
[06:55] <Laibsch> Why did you ask for removing the config files and reinstallation of the package?
[06:55] <ArneGoetje> Laibsch: sometimes old config data can cause such things... it happened in the past.
[06:59] <Laibsch> Can you read stack traces?
[06:59] <ArneGoetje> Laibsch: no. I'm not a programmer.
[06:59] <Laibsch> If those two are indeed dupes with a certain degree of certainty, it would be nice to mark them as such
[06:59] <Laibsch> OK
[06:59] <Laibsch> Bummer
[06:59] <Laibsch> Neither am I
[07:02] <ScottK> pitti: I'm going to wait until my kdelibs build finishes to close the lid (I have a theory about the Kubuntu netbook RC bug you assigned to Riddell today), so that'll probably be after I sleep.
[07:23] <dholbach> good morning
[07:28] <Laibsch> ArneGoetje: I'll ask for help in #ubuntu-bugs with reading the stacktraces
[07:29] <mvo> hey dholbach
[07:29] <dholbach> hi mvo
[07:29] <ArneGoetje> Laibsch: thanks
[07:47] <slangasek> Keybuk: no bug numbers in this usplash upload?  What's broken if we don't do this?
[09:12] <Laibsch> slangasek: Are you aware that the latest change to the emacs package now forces the installation of emacs22 again?
[09:12] <Laibsch> From what I can see it's a step back, not a step forward
[09:13] <Laibsch> towards the migration to emacs23
[09:16] <pitti> Laibsch: emacs22 is in main, 23 is in universe, so the default should be 22
[09:16] <pitti> it wasn't considered for main early enough before FF
[09:16] <Laibsch> ic
[09:20] <dholbach> lool, paulliu: what happened to mutter-moblin now?
[09:24] <paulliu> dholbach: Can I upload the new package to Debian and then request sync again?
[09:24] <paulliu> dholbach: Just fix the things you mentioned yesterday.
[09:24] <dholbach> sure, but the earlier the better
[09:24] <paulliu> dholbach: OK. I do it now.
[09:24] <dholbach> rock on
[09:26] <dpm> hi slangasek
[09:26] <dpm> re: bug 447383, and since the string freeze break was granted after NonLanguagePackDeadline, thus not leaving translators time to do their work, would it be possible to have an exception on ubiquity-slideshow-ubuntu so that translations are exported by LanguagePackDeadline on the 22nd and still used in the LiveCD?
[09:27] <dpm> If so, how could I request this exception?
[09:30] <pitti> dpm: we can't upload it _on_ the 22nd, since that's the day when we release RC
[09:30] <pitti> dpm: but we can do/accept an upload next Friday, after RC, so that they'll be in final
[09:33] <dpm> pitti, that would be perfect. How do I go about requesting this?
[09:33] <pitti> dpm: best would be to open a bug against it and subscribe ubuntu-release, then nominate it for karmic
[09:34] <pitti> dpm: please point me at it, then I'll approve/milestone
[09:34] <pitti> dpm: then it'll be on the release radar and we won't forget about it
[09:34] <dpm> pitti, ok, I'll do that now, thanks a lot!
[09:38] <pitti> I'm off for ~ 2 hours for a doctor appt.
[09:48] <cjwatson> kees: re that mkswap/luks thing you were discussing with Keybuk, I think it would be worth filing a bug on busybox; I don't think its mkswap clears out the bootbits
[09:48] <cjwatson> kees: (but unfortunately I also don't think it's safe to try to do that for release; util-linux mkswap has several checks in there that aren't trivial to implement in busybox)
[10:12] <dpm> pitti, (when you're back), here it is -> bug 452889, please feel free to approve/milestone if appropriate
[10:12] <geser> pitti: do you have time to sponsor the diff in http://paste.ubuntu.com/294525/? it fixes the upload failure for your openthesaurus upload
[10:17]  * ogra is looking at the gltk FTBFS ... if i refresh the .symbols file with the 1.1.9 symbols added, it works error free with fakeroot debian/rules binary ... as soon as i build it in pbuilder it fails with differences in the .symbols file ... 
[10:17] <ogra> *the fltk FTBFS
[10:41] <mdz> mathiaz, what's wrong with the script as written? the weird temporary file stuff that Keybuk was referring to was fixed ages ago, and it now has the logic in a start script as he suggested
[10:41] <mdz> (the eucalyptus upstart job)
[11:16] <pitti> dpm: done
[11:16] <pitti> geser: oh, that was still on my list, thanks!
[11:17] <pitti> geser: any idea why it does that hackery at all?
[11:18] <geser> pitti: no idea
[14:01] <jdstrand> mdeslaur: is 'Low' the right priority for bug #446524? as I read it, aa-logprof is busted for everything. is that an incorrect assessment?
[14:04] <mdeslaur> jdstrand: no, I'll change it to high
[14:05] <jdstrand> mdeslaur: can you add a regression-potential tag as well?
[14:06] <mdeslaur> jdstrand: If I can ever figure out how to add a tag, sure!
[14:06] <mdeslaur> jdstrand: oh, found it
[14:06] <mdeslaur> d'uh
[14:06] <jdstrand> :)
[14:07] <ogra> pitti, what exactly does devicekit disks do with usb disks when i fire up gnome-session
[14:09] <ogra> pitti, trying to debug bug 431963 i found a weird issue ... it doesnt boot into graphical mode at all. i can set text on the cmdline and properly boot into a text console though ... creating ~/.xsession that only fires up xterm i can even startx ...
[14:10] <ogra> as soon as i fire up gnome-session from that xterm, the system hangs and i see the following in dmesg ... http://paste.ubuntu.com/294674/
[14:11] <ogra> i suspect one of the gdu monitors or devicekit-disks to be the issue here, the disk is sitting on a special SATA->USB controller that lives on the board
[14:24] <Chipzz> ~..
[14:28] <mnemonikk> Chipzz: flaky ssh connection? 8-)
[14:31] <pitti> cjwatson: do you happen to know if usplash uses bogl insead of svgalib when running under KMS? (if you don't know, nevermind)
[14:31] <cjwatson> yes, it does
[14:31] <pitti> aaaah
[14:31] <cjwatson> this is a feature :)
[14:31] <pitti> ok, then I know why bug 448988 happens
[14:32] <pitti> and usplash sets an entirely black palette
[14:32] <pitti> cjwatson: thanks
[14:32] <cjwatson> beware, Scott's last upload doesn't seem to be in bzr ...
[14:32] <ion> mnemonikk: Whenever i have to do ~.enter and irssi is active, i try to create a new screen window first before typing that, in case the input actually reaches the box. :-)
[14:32] <ion> enter~., that is.
[14:32]  * cjwatson tends to hit C-u first
[14:33] <pitti> cjwatson: I know, Steve had a question about it; thanks for the warning
[14:33] <pitti> ogra: highvoltage
[14:33] <pitti> oops, meant to say "hi"
[14:33] <ogra> ?
[14:33] <ogra> heh
[14:33] <mnemonikk> ion: 8;-)
[14:33]  * ogra feels shocked
[14:33] <cjwatson> DANGER DANGER HIGH VOLTAGE
[14:33] <ogra> hehe
[14:33] <pitti> bzzzzzt
[14:34]  * cjwatson puts on his stovepipe hat
[14:34] <pitti> ogra: dk-disks itself doesn't do anything by itself, but vfs currently has a bug that it (sometimes) automounts all internal hard disks at startup
[14:34]  * sistpoty|work tried tab-completion for his password once :P
[14:34] <pitti> ogra: bug 451613
[14:35] <cjwatson> oh wait, that was a different Electric Six video :)
[14:35] <ogra> pitti, hmm, any way to disable that to prove it's actually at fault ?
[14:35] <Chipzz> mnemonikk: flakey wireess connection :S
[14:36] <Chipzz> think someone is trying to hack my wireless
[14:36] <ogra> pitti, mounting shouldnt trigger a device reset though
[14:40] <paulliu> dholbach: I've pushed new mutter-moblin into sid few hours ago. It still needs some time to appeared for requestsync.
[14:43] <pitti> ogra: uninstall dk-disks temporarily? or move aside devkit-disks-daemon
[14:43] <dholbach> paulliu: just file the bug manually then?
[14:43] <dholbach> if necessary we can sync from incoming
[14:43] <paulliu> dholbach: ok. I'll do that now.
[14:44] <paulliu> dholbach: sorry. Which package/target should I report to?
[14:44] <dholbach> ubuntu
[14:44] <paulliu> ok
[14:44] <dholbach> https://launchpad.net/ubuntu/+filebug?no-redirect I think
[14:44] <paulliu> dholbach: thanks.
[14:44] <ogra> pitti, will try ...
[14:45] <ogra> i removed everything in /etc/xdg/autostart already but that doesnt seem to help
[14:47] <paulliu> dholbach: oops. Launchpad timeout error.
[14:47] <sivang> anybody know where the group photo from UDS paris is ?
[14:47]  * sivang admits a rather odd question at this time of year
[14:47] <dholbach> paulliu: without edge. maybe?
[14:52] <paulliu> dholbach: I disabled beta tester for 2 hours but still Timeout.
[14:52] <paulliu> dholbach: strange.
[14:53] <sivang> hmm, close to release time, I'm being ignored, granted :)
[15:14] <ogra> seb128, is there any code in gnome-session that could trigger something like that: http://paste.ubuntu.com/294674/
[15:15] <ogra> i have cut down all preipherial apps to nearly zero, starting gnome-session or gdm (which spawns gnome-session) makes the root disk disappear
[15:16] <seb128> not that I know about no
[15:16] <seb128> gnome-session is mainly starting other things
[15:16] <ogra> if i use ~/.xsession, install xfce and put startxfce4 in there it works fine with startx
[15:16] <ogra> i have removed everything from /etc/xdg/autostart
[15:16] <ion> Those look like USB problems.
[15:16] <seb128> it's probably devicekit-disks
[15:16] <ogra> i wouldnt know what else to remove
[15:17] <ogra> ion, its a SATA drive :P
[15:17] <seb128> ther are quite some things dbus activated
[15:17] <seb128> ie gvfs, devicekit-disks
[15:17] <seb128> you can move the binaries to try
[15:17] <ogra> hmm, how do i disable them
[15:17] <seb128> move the binaries away
[15:17] <ogra> i removed devkit-disks-daemon, that didnt help yet
[15:18] <seb128> or dbus .service
[15:18] <seb128> dunno then
[15:19] <LaserJock> cjwatson: do you think you'll have time to look at my cdimage merge request today?
[15:21] <james_w> Ng: I think there's a chance that you could get the latest bash-completion synced from Debian. You'd have to talk to a release manager though
[15:22] <Ng> james_w: I've had it installed since lunch and I'm pretty much on the verge of retracting what I said. It's nice not having the regression, but the new avahi stuff is driving me crazy ;)
[15:22] <Ng> avahi-browse takes 5 seconds to complete
[15:22] <james_w> heh
[15:24] <cjwatson> LaserJock: I don't know, I'll try
[15:25] <LaserJock> cjwatson: k, thanks, I know you're busy
[15:38] <ccheney> mvo: ping
[15:47] <mvo> ccheney: pong
[16:01] <kees> cjwatson: yeah, the checks util-linux's mkswap does depend on the libraries, etc.  are we using the busybox mkswap for installs?
[16:03] <kees> kirkland: oooh, I'd never seen "label" from ip before.  nice.
[16:04] <kirkland> kees: it was new to me too
[16:04] <kirkland> kees: sladen showed it to me
[16:04] <pitti> elmo, james_w: btw, bug 395302 is another report of this
[16:04] <pitti> (at the bottom)
[16:05] <cjwatson> kees: yes
[16:05] <cjwatson> always have
[16:07] <kees> cjwatson: oh, I thought the liveCD and alt have util-linux?
[16:08] <cjwatson> kees: live CD uses util-linux mkswap
[16:08] <cjwatson> kees: alternate CD *installs* util-linux, but doesn't have it in the installation environment
[16:08] <kees> ah-ha.
[16:27] <mathiaz> mdz: re eucalyptus job start: the pre-start script was setting up the correct opts variable - however eucalyptus-cloud was using an exec statement with an opts variable
[16:28] <mathiaz> mdz: and variables are *not* propagated from the pre-start block to the exec block
[16:30] <mathiaz> mdz: the fix was to move all the code that deals with updating the opts variable within a script statement instead of an exec statement
[16:42] <ccheney> doko: ping
[16:42] <ccheney> doko: are you doing that new binutils upload?
[16:43] <bdrung> TheMuso, dtchen: is bug #453158 a alsa or pulseaudio bug?
[16:43] <kirkland> pitti: looks like richard hughes has a fix for the encrypted-swap/hibernate problem
[16:43] <kirkland> pitti: you think this is SRU-able?
[16:43] <pitti> kirkland: I saw the bug mail
[16:44] <ccheney> slangasek: or do you happen to know if he is doing it? I'm trying to determine when I should do the OOo upload
[16:44] <pitti> kirkland: looked quite complex, so I wouldn't like to upload it now; but if we tested it a bit in lucid, we can consider that
[16:44] <kirkland> pitti: okay, cool
[16:44] <kirkland> pitti: i'll leave this with you
[16:44] <kirkland> pitti: cheers
[16:44] <pitti> thanks!
[16:45] <kirkland> pitti: there's a dozen or so bugs in launchpad related to this
[16:45] <kirkland> pitti: filed against linux, hal, acpi, gnome, cryptsetup, pm-utils
[16:46] <mathiaz> which component is responsible for the fsck on boot?
[16:46] <mathiaz> I've run into a fsck check this morning but couldn't cancel it
[16:47] <jcastro> http://www.fewt.com/2009/10/i-give-up.html <-- anyone know anything about this?
[16:47] <pitti> mathiaz: known bug, Keybuk has a branch ready
[16:47] <jcastro> specifically the part about being ignored by ubuntu developers?
[16:47] <mathiaz> pitti: great thanks
[16:47] <doko> ccheney: will reply on email. are all planned changes now really included in the upload? ,P
[16:49] <ccheney> doko: the ppc fix and the kde4 fixes will be in, not sure if there were any other planned ones?
[16:50] <ccheney> the kde4 fixes didn't even exist when i did the previous upload
[17:02] <xan_> Hi, sorry for the inconvenience but I can't get information via web. Anyone know if it's planning to improve the UNR with the "speed" of the ubuntu moblin remix?
[17:18] <ccheney> doko: ok will get the upload staged for you today
[17:18] <EvanCarroll> This very big perl-xml-sax bug is set to plague the jaunty upgrade
[17:19] <EvanCarroll> https://bugs.launchpad.net/ubuntu/+source/libxml-sax-perl/+bug/13917
[17:19] <doko> ccheney: thanks
[17:20] <EvanCarroll> like 20 dupes of the bug now, with 2 of them being posted since karmic beta
[17:20] <EvanCarroll> I wish i could change the importance
[17:21] <EvanCarroll> I talked to the debian guys about the bug and the changes need to fix it, they're pretty perl retarded though
[17:21] <EvanCarroll> I'd say the best of them has 2 credit hours and no real life experience with the language.
[17:22] <james_w> EvanCarroll: insulting our colleagues isn't likely to be a good strategy to get us to help you
[17:23] <james_w> please try and state your concern without the unnecessary editorialising
[17:23] <pitti> james_w, mvo: with u-m switched back to synaptics, is bug 445303 still an issue for karmic then?
[17:24] <james_w> pitti: it's seen in other polkit using things, so I would say yes
[17:24] <EvanCarroll> I'm not needing help -- this was more of an informative message if anyone cares to do some work on the issue moving away from debian. They simply do not undersatnd perl, I've written letters filed bugs, and fixed both launchpad and their tracker marking dupes of this issue as appropriate -- they don't get it.
[17:24] <pitti> james_w: but the crashes in NM for example were fixed in today's uploada
[17:24] <EvanCarroll> I'm thinking about requesting permissions from XML::SAX author to send a request to cease and decist.
[17:25] <pitti> james_w: right now I'm a bit puzzled what to do with this bug, if it's not even reproducible in karmic any more? (since u-m switched backend)
[17:25] <james_w> pitti: I don't think they are the same bug are they?
[17:25] <pitti> james_w: not originally, I just asked to test the new PK again because 445303 is obviously also a crash
[17:25] <pitti> d-bus timeouts usually mean that the backend has crashes
[17:25] <EvanCarroll> they hack code into the module in an unsupported fashion, without subclassing, and it litterally breaks everything when you upgrade that module outside of dpkg.
[17:25] <pitti> s/crashes/crashed/
[17:26] <james_w> pitti: oh, I see
[17:26] <EvanCarroll> their answer is, "CPAN is not supported on debian systems"
[17:26] <EvanCarroll> which is laughable.
[17:26] <ScottK> EvanCarroll: It's not.
[17:26] <pitti> james_w: it was worth a shot, anyway
[17:26] <james_w> EvanCarroll: please desist
[17:26] <ScottK> We have a package management system and people should use it.
[17:27] <james_w> pitti: I suspect that fix will not have made this go away, but it would be good to know.
[17:27] <cjwatson> we should do a better job of it, and I don't think CPAN should be declared as unsupported since it is very useful for admins using Perl
[17:27] <james_w> pitti: as for tracking the bug, I suggest we still do for software-center etc.
[17:27] <EvanCarroll> Nothing should /have/ to use it for modules, Firefox (add-ons) doesn't use it, ruby (gems), and even python (pypi), php (pear) don't have to use it -- why should perl.
[17:28] <cjwatson> but I don't see the point of discussing it here - I believe I commented on the patronising attitude last time too!
[17:28] <james_w> jdong: did you have a chance to test the policykit changes I made?
[17:28] <pitti> james_w: ah, right; that uses aptdaemon, too
[17:28] <cjwatson> it needs to be fixed in Debian
[17:43] <jdong> james_w: no; sorry, got caught up in back-to-back midterms...
[17:44] <james_w> jdong: no problem
[17:44] <james_w> jdong: don't worry if you have more important things to be doing
[17:46] <jdong> I'll try to make some time tonight to get that info back to you
[17:47] <jdong> james_w: haha admittedly I wasted some time earlier in the week converting to a btrfs root... ended in tragedy ;-)
[17:47] <james_w> jdong: sounds like a sensible thing to be doing ;-)
[17:47] <jdong> :)
[17:48]  * jdong views "EXPERIMENTAL" as an empty threat ;-)
[17:48] <james_w> heh
[17:48] <ScottK> pitti: I got the event information for lid close/open on my D430 that we discussed early this morning.
[17:50] <ScottK> http://paste.ubuntu.com/294833/
[18:12] <jcole> fyi guys, seems to be another problem with flash on 64 bit firefox again... reddit users are starting to complain (they suggest to just get the 64 bits from adobe directly) -> http://www.reddit.com/r/linux/comments/9tr3d/the_ubuntu_flash_flu/
[18:13] <jcole> ive also got my own strange "white box" problem happening lately
[18:20] <JanC> jcole: AFAIK Adobe forbids Canonical to distribute the 64-bit alpha plugin...  :-(
[18:24] <jcole> JanC: maybe "someone" should throw some "support" towards the swfdec developers ;)
[18:25] <JanC> both swfdec & gnash work for some sites and not for others, maybe they should start working together first...
[19:10] <kees> chrisccoulson: so, I'm trying to force the g-s-s crash by adding delays, etc, so I can "prove" that your patch fixes the problem (also so I can test jaunty and earlier).  I'm not having much luck.
[19:11] <chrisccoulson> kees - i tried to force it by adding delays too, but i don't think delays make it any worse
[19:11] <chrisccoulson> you just need to be unlucky with the timing
[19:11] <chrisccoulson> i've not had a look at older versions of g-s-s yet
[19:11] <kees> chrisccoulson: but where is the actual problem...
[19:12] <kees> chrisccoulson: I'm trying to figure out at which line of code having the dialog vanish causes the problem.
[19:13] <kees> chrisccoulson: the shake_dialog even checks window->priv->lock_box before the alignment_set_padding call..
[19:13] <kees> chrisccoulson: I assume it's during the gtk_main_iteration(), but it's not clear what
[19:14] <kees> shake_dialog is called via lock_command_watch.
[19:14] <chrisccoulson> kees - yeah, it will occur once gtk_main_iteration is called. gtk_alignment_set_padding registers some sources on the event loop
[19:14] <chrisccoulson> and then those events are dispatched with gtk_main_iteration
[19:15] <kees> so at what point are those sources unmapped?
[19:15] <chrisccoulson> the issue will occur if the dialog exits after dispatching an event that accesses the resource at some point
[19:15] <kees> lock_command_watch is called on pipe input
[19:16] <chrisccoulson> because once the event has been dispatched, the main process cannot notice the dialog has disappeared until execution has returned back to the main loop
[19:16] <kees> chrisccoulson: right, but doesn't that mean everything stays allocated?  I'm not clear what's tearing down the allocation.
[19:17] <chrisccoulson> i'm not 100% sure how XEmbed works, but i'm fairly sure it is the gnome-screensaver-dialog process which allocated the resources on the server
[19:19] <kees> chrisccoulson: so, some event happens between gtk_alignment_set_padding and gtk_main_iteration in shake_dialog that causes gtk_container_idle_sizer to die?
[19:21] <chrisccoulson> kees - yeah, that's likely. it could also happen at any point in the while loop too
[19:23]  * kees tries adding more delays...
[19:32] <jdstrand> kirkland: hi! can you explain to me the issue with pulseaudio and qemu-kvm?
[19:32] <kirkland> jdstrand: "the issue"?
[19:33] <jdstrand> kirkland: yes-- debian/patches/10_qemu-allow-pulseaudio-to-be-the-default.patch
[19:33] <kirkland> jdstrand: i reverted that one
[19:34] <kirkland> jdstrand: i had cherry-picked it from fedora, thinking that might be a good thing
[19:34] <jdstrand> kirkland: something is not right. specifically, on a brand new vm I hit bug #453329
[19:34] <kirkland> jdstrand: the initial bug reporter just wanted kvm to "prefer" pa over oss and alsa
[19:35] <jdstrand> kirkland: (fine). so I go to fix the apparmor profile, and now when I start the vm, it hangs
[19:35] <jdstrand> kirkland: in other words, now that the apparmor profile isn't denying access to pulseaudio, the vm won't start
[19:35] <chrisccoulson> kees - you might have more luck recreating the issue by ignoring the "destroy" and "plug_removed" signals from the GtkSocket in gs-window-x11.c, but i can't predict what other wierd effects that would have
[19:35] <chrisccoulson> perhaps delay executing the callbacks?
[19:37] <chrisccoulson> you could maybe use those signals to trigger a callback which just registers the real callback to be executed after a delay with g_timeout_add
[19:38] <chrisccoulson> i need to go for dinner shortly, but i may try that afterwards
[19:38] <kees> chrisccoulson: ok, cool.
[19:38] <jdstrand> kirkland: let me rephrase-- it starts just fine, but during boot it hangs
[19:38] <kirkland> jdstrand: hmm, i'm not sure what to say ...  i added that patch, and then reverted it
[19:39] <kirkland> jdstrand: guest kernel hangs?
[19:39] <jdstrand> kirkland: I don't know
[19:39] <kirkland> slangasek: i just uploaded eucalyptus for exception approval; please let me know if you need anything of me
[19:39] <jdstrand> kirkland: but if I do:
[19:39] <jdstrand> echo autospawn = no|tee -a ~/.pulse/client.conf
[19:39] <kirkland> jdstrand: okay, let me install a new deskto vm
[19:39] <jdstrand> killall pulseaudio
[19:40] <jdstrand> actually, strike that
[19:40] <jdstrand> kirkland: if I remove the sound device from the libvirt xml, it starts fine
[19:41] <jdstrand> kirkland: it showed up by default as an es1370 iirc
[19:41] <jdstrand> kirkland: yeah, es1370
[19:41] <jdstrand> kirkland: you won't reproduce it without a patch to the apparmor profile
[19:42] <jcole> big windows 7 releases and promotions happening all over this weekend and next few weeks... so, hold onto your hats... apparently, windows 7 can cure cancer and create world peace
[19:42]  * jdstrand goes to get it
[19:42] <kirkland> jdstrand: ?
[19:42] <kirkland> jdstrand: you're seeing this on a package that's not in karmic right now?
[19:42] <jdstrand> kirkland: no
[19:43] <jdstrand> kirkland: like I said, the apparmor profile denies access to pulseaudio
[19:43] <jdstrand> kirkland: that is a bug I was trying to fix
[19:43] <kirkland> jdstrand: oh
[19:43] <kirkland> jdstrand: okay, and in trying to fix that, you're getting a hanging vm
[19:43] <jdstrand> kirkland: when I fixed the bug (ie, kvm has access to pa), then I saw this issue
[19:44] <jdstrand> kirkland: simply put. pulseaudio doesn't work with libvirt/kvm due to apparmor. however, when I fix that, you will find that kvm and pulseaudio aren't getting along
[19:45] <jdstrand> kirkland: http://paste.ubuntu.com/294893/
[19:45] <kirkland> jdstrand: http://cvs.fedoraproject.org/viewvc/F-12/qemu/qemu-allow-pulseaudio-to-be-the-default.patch?revision=1.3&view=markup
[19:45] <kirkland> jdstrand: that *was* the patch I had cherry picked
[19:45] <kirkland> jdstrand: i periodically do a sweep over fedora's patches, and pick ones that look tasty
[19:46] <kirkland> jdstrand: i thought that one looked good, but as soon as I applied it and uploaded, i got a complaint from a user whose bug I had previously fixed, and he said my upload regressed his fixed
[19:46] <kirkland> jdstrand: tbh, I didn't really dig too deeply into his issue
[19:46] <jdstrand> kirkland: apply my diff to /etc/apparmor.d/abstractions/libvirt-qemu, then try to install karmic off the livecd in a new vm
[19:47] <jdstrand> kirkland: using virt-manager
[19:47] <jdstrand> kirkland: assuming pulseaudio is running on your machine, the vm will hang somewhere during boot
[19:50] <kirkland> jdstrand: what's your command line say?
[19:50] <kirkland> jdstrand: -soundhw ?
[19:51] <jdstrand> kirkland: -soundhw es1370
[19:51] <jdstrand> kirkland: http://paste.ubuntu.com/294897/
[19:53] <kirkland> jdstrand: hmm
[19:53] <jdstrand> kirkland: are you seeing it with straight kvm?
[19:57] <kirkland> jdstrand: i was able to get sound okay, with straight kvm
[19:57] <kirkland> jdstrand: i'm syncing the daily desktop iso now
[19:57] <kirkland> jdstrand: i should be able to reproduce it with just that, right?
[19:58] <jdstrand> kirkland: well, my desktop-iso was old. I used virt-manager with generic/generic, kvm/i686 and an i386 desktop livecd
[19:59] <kirkland> jdstrand: hmm...  there could be any one of a number of kernel problems with an old iso ....
[19:59] <kirkland> jdstrand: i'm rsyncing now
[20:00] <jdstrand> kirkland: related to sound specifically? like I said, if I don't use -soundhw es1370 it works fine
[20:00] <kirkland> jdstrand: so no -soundhw at all, or a different -soundhw ?
[20:00] <kirkland> jdstrand: when it works ^
[20:01] <jdstrand> kirkland: no -soundhw at all (I removed the sound device from the xml)
[20:01] <kirkland> jdstrand: and sound works?
[20:02] <kirkland> jdstrand: or it's just able to boot?
[20:02] <jdstrand> kirkland: no. the vm boots to the desktop
[20:02]  * kirkland would not expect sound to work
[20:02] <jdstrand> kirkland: with -soundhw es1370 it hangs during the boot
[20:02] <kirkland> jdstrand: okay ....
[20:02] <kirkland> jdstrand: i'm applying your patch
[20:04] <kirkland> jdstrand: actually, i'm going to first boot today's desktop iso with sound, without your patch
[20:04] <kirkland> /usr/bin/kvm -m 512 -smp 2 -usb -usbdevice tablet -net nic,model=virtio -net tap,script=/home/kirkland/bin/bridge.sh -soundhw es1370 -cdrom karmic-desktop-amd64.iso
[20:04] <jdstrand> kirkland: you should then see apparmor denied messages in kern.log (or /var/log/autit/audit.log if you use auditd)
[20:05] <kirkland> jdstrand: okay, here's what I have ...
[20:05] <kirkland> jdstrand: my desktop hardware is running pulse audio
[20:05] <kirkland> jdstrand: i have not applied your patch yet
[20:06] <kirkland> jdstrand: i booted today's desktop iso using bare qemu-kvm
[20:06] <kirkland> jdstrand: with the command line above (with es1370)
[20:06] <kirkland> jdstrand: i did get the startup sound, though it was a little garbled
[20:07] <kirkland> jdstrand: okay, so i assume applying your patch won't have any affect, unless i run through libvirt, right?
[20:07] <kirkland> jdstrand: i'll try virt-manager
[20:08] <jdstrand> kirkland: the apparmor protection does not apply to kvm on its own, no. you must use libvirt
[20:08] <jdstrand> kirkland: use generic/generic with kvm/i686 (that is what I did)
[20:08] <jdstrand> I'm rsyncing the image now too
[20:09] <kirkland> jdstrand: okay, i'm using amd64, ubuntu/karmic
[20:09] <kirkland> jdstrand: and i'm setting a placebo using virt-manager, without your patch
[20:09] <kirkland> jdstrand: will apply it in a moment
[20:09] <jdstrand> I too use amd64/karmic
[20:10] <kirkland> jdstrand: http://pastebin.ubuntu.com/294909/
[20:10] <kirkland> jdstrand: okay, no startup sound
[20:10] <jdstrand> kirkland: what version of libvirt do you have?
[20:10] <kirkland> ii  libvirt-bin                              0.7.0-1ubuntu11                            the programs for the libvirt library
[20:10] <kirkland> jdstrand: ^
[20:11] <jdstrand> ok
[20:11] <kirkland> jdstrand: okay, so i didn't have sound working ... is this expected at this point?
[20:11] <jdstrand> I wonder why it is looking in /home/kirkland/.pulse-cookie
[20:12] <jdstrand> kirkland: yes, but I have a feeling you'll get another denied message after the patch, but let's see what happens
[20:15] <kirkland> jdstrand: http://pastebin.ubuntu.com/294913/
[20:16] <jdstrand> kirkland: a blank line may have crept in. can you eyeball the result to make sure it applied right
[20:17] <kirkland> jdstrand: okay, looks right
[20:17] <kirkland> jdstrand: do i need to restart libvirt?
[20:17] <jdstrand> kirkland: no
[20:18] <jdstrand> kirkland: just try a new VM
[20:19] <kirkland> jdstrand: http://pastebin.ubuntu.com/294916/
[20:19] <kirkland> jdstrand: it booted to the desktop
[20:19] <jdstrand> kirkland: ok good-- apparmor is not denying access anymore
[20:19] <jdstrand> kirkland: do you have sound?
[20:20] <kirkland> jdstrand: no
[20:21] <jdstrand> kirkland: do you have the sound device?
[20:21] <kirkland> jdstrand: yes
[20:22] <kirkland> jdstrand: http://pastebin.ubuntu.com/294918/
[20:22] <kirkland> jdstrand: that's what i get when i try to run the same command by hand
[20:22] <kirkland> jdstrand: no libvirt
[20:22] <jdstrand> kirkland: well, at least it booted. I'll try with a new vm. sounds like there may be a bug somewhere between how you start it with kvm and how libvirt starts it
[20:22] <kirkland> jdstrand: not sure it's related
[20:22] <kirkland> jdstrand: have you tried with the latest iso yet?
[20:23] <jdstrand> kirkland: still downloading
[20:24] <jdstrand> kirkland: is 'sound' the name of your vm?
[20:24] <kirkland> jdstrand: yeah
[20:24] <jdstrand> kirkland: that is unrelated
[20:25] <kirkland> jdstrand: okay, i've simplified the command line
[20:25] <jdstrand> kirkland: 0.7.0 started using a monitor socket
[20:25] <jdstrand> kirkland: Switch to using a unix socket for the qemu monitor (Mark McLoughlin)
[20:25] <jdstrand> (from the NEWS file)
[20:26] <Chipzz> Mark McLoughlin, now there's a name that sounds familiar :)
[20:26] <jdstrand> kirkland: are you running the barebones kvm as root? that is how libvirt starts it when using qemu:///system
[20:26] <Chipzz> be it from GNOME and not qemu :P
[20:27] <kirkland> jdstrand: no, as non-priv user
[20:27] <kirkland> jdstrand: i'm trying it with sudo now
[20:32] <jdstrand> kirkland: dude, it is taking *forever* to get the iso...
[20:32] <kirkland> jdstrand: where are you pulling it from?
[20:32] <kirkland> jdstrand: and at what rate?
[20:32] <jdstrand> cdimage.ubuntu.com
[20:32] <kirkland> jdstrand: i have pretty good upload
[20:32] <jdstrand> 61.06kB/s
[20:32] <kirkland> jdstrand: private link coming
[20:33] <walters> Chipzz: he's on the Red Hat virt team now
[20:34] <kirkland> jdstrand: sounds works if i don't use libvirt
[20:36] <jdstrand> kirkland: let's try this
[20:36] <jdstrand> kirkland: can you do:
[20:37] <jdstrand> sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd && sudo /etc/init.d/libvirt-bin restart
[20:37] <jdstrand> kirkland: then do 'virsh capabilites | grep apparmor'
[20:38] <jdstrand> kirkland: what this does is start libvirt without the apparmor security driver. if you can't get sound to work there, it is clearly a problem between libvirt and kvm
[20:39] <jdstrand> kirkland: it is also temporary, so on the next reboot (or profile load and restart of libvirt) you'll have the standard, default libvirt configuration
[20:39] <kirkland> jdstrand: how urgent is all of this sound business?
[20:39] <mdke> Riddell: something seems to have gone wrong with https://help.ubuntu.com/community/KarmicUpgrades - did you overwrite the page somehow? I can't see the old page history to revert it
[20:40] <kirkland> jdstrand: i don't particularly care about it, tbh ... i think i have some higher priorities
[20:40] <jdstrand> kirkland: well, I only brought it up to you because I plan to fix the apparmor issue. if this then exposes a pulseaudio/kvm/libvirt bug that causes a massive regression, I thought it be best to let you know about it first :)
[20:40] <kirkland> jdstrand: i have working sound when i use qemu-kvm; non-working sound when i use libvirt
[20:40] <jdstrand> kirkland: I don't care about sound working
[20:41] <jdstrand> kirkland: I care about the vm not starting
[20:41] <kirkland> jdstrand: right; i haven't reproduced that
[20:41] <jdstrand> kirkland: err, not booting to the desktop
[20:41] <kirkland> jdstrand: i suspect you won't either, when you get an up-to-date iso
[20:41] <jdstrand> kirkland: feel free move on. If I continue to have problems with the newer iso, I'll let you iknow
[20:41] <kirkland> jdstrand: and if the vm is still hanging, i'd start looking at the guest's kernel's dmesg
[20:42] <kirkland> jdstrand: okay, thanks;  sorry to be abrupt :-)
[20:42] <kirkland> jdstrand: i don't mean to be rude
[20:42] <jdstrand> kirkland: it isn't rude. I just don't want to catch you off guard with my upload
[20:45] <kirkland> jdstrand: right; vm not booting, that would be a regression.  vm without sound...well, i don't have sound right now through libvirt
[20:45] <kirkland> jdstrand: which i'm sure people will complain about
[20:45] <kirkland> jdstrand: but i'm not that bothered right now
[20:45] <Riddell> mdke: there was nothing there before
[20:48] <chrisccoulson> kees - any luck trying to trigger the g-s-s crash reliably?
[20:49] <chrisccoulson> i had a look through my xtrace log again, and that shows that it is the gnome-screensaver-dialog process which creates the resource which gnome-screensaver tries to access after it is destroyed
[20:49] <kees> chrisccoulson: no.  :(
[20:49] <kees> chrisccoulson: I can see the child defunct while I wait.
[20:49] <kees> chrisccoulson: it must be a very specific order of events
[20:49] <chrisccoulson> kees - i agree. i could only recreate it occasionally before
[20:50] <chrisccoulson> but i've tried and tried to trigger it with the patch, and i don't get it any more
[20:50] <chrisccoulson> i tried for 20 minutes continuously entering the wrong password last night, with the change in, and i didn't make it crash
[20:50] <jdstrand> kirkland: fyi, I tried with an intrepid desktop livecd. I disables 'splash and quiet' and it booted all the way
[20:51] <chrisccoulson> and i tried again today too
[20:51] <kirkland> jdstrand: excellent
[20:51] <jdstrand> kirkland: there may be a race, I don't know
[20:51] <jdstrand> kirkland: oh, I left out part of it
[20:51] <kirkland> jdstrand: for your iso woes ...  i just realize that we're not building qemu-kvm against libcurl
[20:52] <jdstrand> kirkland: I tried with an intrepid desktop livecd. the first time, it hung. the second time I disabled 'splash and quiet' and it booted all the way
[20:52] <kirkland> jdstrand: if we did, you could -cdrom http://...iso and stream over the internet :-)
[20:53] <chrisccoulson> kees - want me to put it in my PPA and ask some of the reporters to test it?
[20:53] <kees> chrisccoulson: I'm nearly 100% sure your patch is correct, but I'm mostly after trying to prove that Jaunty and earlier are/aren't affected.
[20:53] <mdke> Riddell: hmm, that used to be quite an important page. not sure what happened to it then
[20:54] <mdke> Riddell: but I hear the release managers are working on getting it back
[20:54] <kees> chrisccoulson: PPA> sure, yeah, can't hurt
[20:54] <ccheney> grr is the a way to make chroots work now that we use upstart?
[20:54] <ccheney> i'm getting stuff like: start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
[20:54] <ccheney> causing package installation in a chroot to fail
[20:55] <chrisccoulson> kees - i had a look at the code for the jaunty version, and not much has changed in that area, so i can't see why jaunty wouldn't have the same issue. but then, there might be a GTK change in karmic that exposes the underlying issue
[20:55] <kees> chrisccoulson: yeah, that's what I was thinking
[20:56] <chrisccoulson> kees - if i get some time, i will test my jaunty VM and see if i can trigger it there
[20:56] <chrisccoulson> but i could do with a more automated way of testing it really:(
[20:56] <Riddell> mdke: well it's never existed for karmic
[20:56] <Riddell> mdke: I thought ubuntu desktop used a page on ubuntu.com now
[20:57] <kees> chrisccoulson: does dogtail or the other thing let someone automate hitting enter on that dialog?
[20:59] <chrisccoulson> kees - i'm not sure. i was thinking that i could maybe do a special jaunty build which bypasses all the pam stuff in the dialog process, and instead just loops and sends auth failure message back to gnome-screensaver, to simulate a user repeatedly entering the wrong password
[20:59] <chrisccoulson> and then just leave that running for a while
[20:59] <kees> chrisccoulson: oh, heh
[21:00] <chrisccoulson> but perhaps there is a way of faking the enter keypress event
[21:01] <jdstrand> kirkland: well, 1 out of 10 times in hung. I think I'm done poking at this for now.
[21:01] <kirkland> jdstrand: ugh, that does sound racy
[21:01] <kirkland> jdstrand: i think we actually do need qemu-allow-pulseaudio-to-be-the-default.patch
[21:01] <kirkland> jdstrand: i thing i was too quick to revert that patch
[21:01] <kirkland> jdstrand: and i think the user/bugreporter may have been wrong
[21:02] <sebner> mighty Riddell, any plans to update k3b?
[21:02] <jdstrand> kirkland: it *really* feels like a too many resources accessing the sound card issue
[21:02] <kirkland> jdstrand: i have had working sound at various times duing karmic
[21:02] <jdstrand> kirkland: eg, one time I was listening to rhythmbox (ie pa was using the soundcard) and no sound in the vm
[21:02] <jdstrand> kirkland: other times sound in the vm
[21:02] <jdstrand> kirkland: and then the one time it hung
[21:03] <mdke> Riddell: ah, possibly I may be out of touch
[21:03] <mdke> Riddell: false alarm maybe
[21:03] <Riddell> sebner: update to what?
[21:04] <jdstrand> kirkland: can I hand this off to you for investigation whenever you see fit?
[21:04] <sebner> Riddell: alpha3
[21:05] <kirkland> jdstrand: you can hand off the non-libvirt, non-apparmor piece to me, yes
[21:05] <sebner> Riddell: 1.68.0 alpha3 > 1.66.0~alpha2-0ubuntu7
[21:05] <kirkland> jdstrand: i really won't be able to efficiently debug the libvirt or the apparmor aspects
[21:05] <jdstrand> kirkland: this was all with apparmor disabled
[21:05] <jdstrand> kirkland: it is not an apparmor issue. it hung without it
[21:06] <kirkland> jdstrand: i'll own the getting bare qemu-kvm to work with audio
[21:06] <jdstrand> kirkland: I'll just file a bug then
[21:06] <kirkland> jdstrand: oh, the hang?
[21:06] <kirkland> jdstrand: file that against the linux package
[21:06] <Riddell> sebner: guess I'll add it to my evening's todo list :)
[21:06] <kirkland> jdstrand: if the guest kernel is hanging, that's not a qemu-kvm issue, i don't think
[21:06] <jdstrand> kirkland: I don't think it is a 'linux' issue
[21:06] <sebner> Riddell: cool! (I'm not using kde or k3b though, just let you know because of your users sake ;-D)
[21:06] <jdstrand> kirkland: I think the kvm process hung cause it was trying to access the soundcard
[21:07] <kirkland> jdstrand: okay, sure file the bug, i probably won't look at it until after karmic
[21:07] <jdstrand> kirkland: I believe this to be true because all of libvirt hung and I could use 'virsh list' until I killed off the kvm process trying to access the soundcard
[21:08] <kirkland> jdstrand: did you strace -p the kvm process?
[21:08] <kirkland> jdstrand: attach that to the bug
[21:08] <jdstrand> no
[21:08] <kirkland> jdstrand: that would help a lot
[21:08] <jdstrand> I can
[21:08]  * jdstrand tries to get another hang...
[21:12] <kees> slangasek: I've just uploaded m2crypto for bug 451998.  no changes to the installed package -- just enables the testsuite and works around a weird issue on the builders.
[21:13] <kees> chrisccoulson: heh, I've gotten as far as getting these, but no crashes:
[21:13] <kees> (gnome-screensaver:20207): Gtk-CRITICAL **: gtk_alignment_set_padding: assertion `GTK_IS_ALIGNMENT (alignment)' failed
[21:15] <chrisccoulson> kees - those would suggest that the dialog has exitted at a point where gnome-screensaver has noticed it, and freed some client-side resources
[21:15] <dobey> anyone around that can sponsor an upload for karmic main?
[21:16] <kees> chrisccoulson: yeah.  I'm more and more convinced this is an internal gtk change.  anyway, I'm going to upload your fix, as I think it is good for karmic, and I want to keep the late churn for RC down.  :)
[21:16] <chrisccoulson> kees - thanks. i'll try and come up with a way of automatically testing this on a jaunty machine too
[21:16] <chrisccoulson> i don't want to sit here for hours hitting my enter key ;)
[21:17] <kees> hehe
[21:23] <kirkland> jdstrand: question for you about your hang ....
[21:23] <kirkland> jdstrand: what cpu do you have?
[21:23] <kirkland> jdstrand: and do you have cpu freq scaling enabled?
[21:24] <kirkland> jdstrand: there are some known, non-deterministic hangs related to some AMD rev-F or old CPUs, when freq scaling is enabled
[21:24] <jdstrand> kirkland: dual core Intel. model name: Genuine Intel(R) CPU 3.00GHz
[21:25] <kirkland> jdstrand: okay, should not be affected
[21:25] <jdstrand> kirkland: it also hung in the same place in usplash each time
[21:25] <jdstrand> kirkland: 3 'ticks' in
[21:25] <kirkland> jdstrand: k
[21:25] <jdstrand> kirkland: fyi, bug #453453
[21:26] <jdstrand> kirkland: I don't have the strace, but will attach when I see another hang
[21:38] <kirkland> jdstrand: thanks
[21:57] <kirkland> kees: could you throw some build super powers at https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1295329 ?
[21:57] <kees> sure, one sec
[21:58] <kees> kirkland: "Start in 1 minute"
[21:58] <kirkland> kees: beautiful
[22:00] <elleuca>  hi, could someone try to check this bug? https://bugs.launchpad.net/bugs/451974
[22:21] <jdstrand> kirkland: fyi-- bug #453495
[22:21] <jdstrand> kirkland: I haven't looked to the why, but thought it might have had something to do with the qemu-kvm packaging
[22:23] <jdstrand> kirkland: that title was misleading. this is more accurate (bug #453495)
[22:23] <jdstrand> meh
[22:23] <jdstrand> virt-manager does not honor other architectures when using qemu
[22:23] <kirkland> jdstrand: perhaps... other arches are in qemu-kvm-extras
[22:23] <jdstrand> kirkland: see the bug. it's installed
[22:36] <mathiaz> mvo: hi tried a mysql cluster bug upgrade - run into bug 453513
[22:37] <mathiaz> mvo: mysql-server-5.0 is removed on upgrade because it became an unused dependency (mysql-server being removed)
[23:09] <cjwatson> ccheney: link /sbin/initctl to /bin/true; this will be in the release notes
[23:09] <cjwatson> (you'll probably want to move it aside rather than just blatting it)
[23:09] <cjwatson> (or maybe dpkg-divert)
[23:34] <kirkland> jdstrand: okay, i think i'm seeing your virt-manager hang
[23:35] <kirkland> jdstrand: so when i run kvm by hand, i see in my sound mixer qemu under the processes that pulse audio is attached to
[23:35] <kirkland> jdstrand: that's when sound works
[23:39] <chrisccoulson> kees - i have an automated screensaver test up and running on jaunty now
[23:39] <chrisccoulson> so i'll leave that going overnight and see what happens
[23:55] <kees> chrisccoulson: oh, cool; does it work in karmic?
[23:58] <chrisccoulson> kees - i've not tried it in karmic yet, as it's implemented as a patch in gnome-screensaver
[23:59] <chrisccoulson> it just repeatedly fakes keypresses