[00:00] <slangasek> heh, doubt it; the sequence leading up to it was non-trivial (and was a result of bugs)
[00:00] <kirkland> mdz: well, i could be just impatient
[00:00] <kirkland> mdz: its still doing stuff
[00:00] <Keybuk> I've tended to see that before with "expect daemon" and SIGCHLD handlers
[00:00] <Keybuk> e.g. avahi
[00:01] <kirkland> mdz: dd, specifically
[00:01] <Keybuk> I guess you could get it with "expect fork" as well in that situation
[00:01] <Keybuk> actually, if you had expect fork, the service daemonised instead of just forking, and put a SIGCHLD handler in - you could probably get that
[00:01] <slangasek> mmk
[00:02] <cjwatson> Keybuk: gdm is stopped due to a runlevel change; it would be nice if that information were passed on
[00:02] <slangasek> let me reboot (I /think/ I haven't broken my own boot sequence... :) and try again
[00:02] <Keybuk> cjwatson: I'm just trying to figure out in my head whether "export RUNLEVEL" in gdm.conf would work ;)
[00:03] <cjwatson> happy to try it at some point
[00:03] <Keybuk> I don't think it would
[00:03] <Keybuk> I think you can only export start environment
[00:03] <Keybuk> so you could know the runlevel gdm was in when it started ;)
[00:03] <cjwatson> useful ;)
[00:04] <kirkland> mdz: keeping a chronicle in https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/439288
[00:04] <Keybuk> though the stop environment stuff is all a bit broken
[00:04] <Keybuk> it seemed like a good idea at the time
[00:05] <Keybuk> (e.g. upstart doesn't even pass the exit code to the post-stop script)
[00:05] <cjwatson> actually, is there any reason why all events shouldn't just come with the current runlevel attached?
[00:06] <Keybuk> yes
[00:06] <Keybuk> upstart doesn't implement runlevels
[00:06] <Keybuk> ;)
[00:06] <cjwatson> you can get the information anyway in a script, but it would allow you to match on them ...
[00:06] <Keybuk> by that, I mean that the init daemon doesn't implement them
[00:06] <Keybuk> it never knows what the runlevel is
[00:06] <Keybuk> or even what *a* runlevel is
[00:06] <cjwatson> yeah
[00:07] <cjwatson> oh well. awkward.
[00:07] <Keybuk> it's all done by the passing of events
[00:07] <cjwatson> I suppose I want to be able to match on runlevel [06] as a state
[00:07] <Keybuk> right, exactly!
[00:07] <Keybuk> and that's definitely going to happen
[00:07]  * cjwatson remembers an old spec with edge-triggered and level-triggered events ... ;-)
[00:08] <Keybuk> it's funny you say that
[00:08] <Keybuk> I remarked only last week how most of the work for upstart 0.10 is putting back in all the things we dropped out of the original design
[00:08] <cjwatson> you're going to tell me I argued you out of including level-triggered events now, aren't you
[00:08] <cjwatson> which is entirely possible, although I've forgotten it if I did :)
[00:08] <Keybuk> no, I think that was mdz
[00:09] <Keybuk> they "confused" people at the original Wiesbaden demo
[00:09] <Keybuk> of course, in practice, we removed the wrong ones <g>
[00:10] <cjwatson> running runlevel is an adequate hack for now, anyway, it's just inefficient
[00:11] <Keybuk> yeah, it is ineffecient - but that's basically all upstart would be doing itself
[00:11] <Keybuk> (until we get a runlevel state to replace the event)
[00:11] <cjwatson> right, until it remembers the state of course
[00:18] <slangasek> hmm
[00:19] <slangasek> Keybuk: how is 'env' supposed to work?  Is there a document I should be looking at that tells me the available commands?
[00:20] <cjwatson> man 5 init ?
[00:20] <slangasek> heh
[00:21] <slangasek> doesn't show up under 'man -k upstart', does it :)
[00:21] <cjwatson> debmany upstart
[00:27] <kirkland> mdz: \o/ \o/ \o/
[00:27] <Keybuk> slangasek: no, but if you read the upstart(7) overview page, it'd tell you :p
[00:27] <kirkland> mdz: RESERVATION     r-31500705      admin   default
[00:27] <kirkland> INSTANCE        i-3BEB06F3      emi-D5871527    192.168.0.250   172.19.1.2      running         mykey   0       m1.xlarge
[00:27] <kirkland> 2009-09-30T22:37:49.042Z        canyonedge      eki-8F0A139D    eri-E64F14E8
[00:28] <Keybuk>        Processes managed by init are known as jobs and are defined by files in
[00:28] <Keybuk>        the /etc/init directory.  See init(5) for more details.
[00:28] <slangasek> heh
[00:32] <Keybuk> just saying <g>
[00:32]  * Keybuk rofls
[00:32] <Keybuk> I just did apropos -h
[00:33] <Keybuk> cjwatson: I think you may have a gettext bug there ;)
[00:33] <Keybuk> _("") does not do what you might think <g>
[00:34] <lifeless> ooo
[00:34] <lifeless> I want to translate that now
[00:34] <Keybuk> lifeless: it's the header of the .po file I assume
[00:35] <Keybuk> probably done
[00:35] <Keybuk> printf ("%s\n, _(""));
[00:35] <lifeless>          ^"
[00:35] <lifeless> damn, one space off
[00:47] <slangasek> Keybuk: ho-hum, seems to be reproducible with both 'fork' and 'daemon'; continuing to debug
[00:47] <slangasek> (in the meantime, fixed my terribly-wrong rpc_pipefs job)
[00:50] <cjwatson> Keybuk: however, the same thing doesn't happen without langpacks in Debian, even with remarkably similar-looking .mo files
[00:50] <cjwatson> Keybuk: so I think it may actually be a bug in our langpack integration
[00:51] <cjwatson> (anyway, the code that's doing _("") is in gnulib, I think, rather than code I wrote directly)
[00:54] <cjwatson> I've seen that before, it was a while back - never got round to tracing it all the way down though
[00:54] <ion> fr.po
[00:54] <ion> msgid ""
[00:54] <ion> msgstr "le "
[00:59] <Keybuk> cjwatson: maybe we're accidentally ending up with that string in the .mo file
[00:59] <Keybuk> dunno whether you ordinarily do or don't
[01:00] <cjwatson> I msgunfmt'ed the two .mo files, it's there in both langpack and non-langpack cases
[01:05] <cjwatson> I do know what's causing it, it's that I have argp doc strings that start with a \v (\v is a separator for pre- and post- doc strings in argp-ese)
[01:05] <cjwatson> but I consider it a bug in the argp implementation in gnulib that it doesn't deal with that properly
[01:05] <cjwatson> one day I'll get round to sending them a fix for that
[01:06] <cjwatson> still mystifying that it only happens with langpacks, though
[01:07] <cjwatson> hmm, though I think I see a workaround
[01:07] <cjwatson> yeah, there we go
[01:09] <slangasek> Keybuk: aha, got it; upstart isn't happy with me if my script spawns a number of short-lived subprocesses, then execs the daemon, which forks
[01:09] <slangasek> so a pre-script fixes this
[01:09] <Keybuk> hah
[01:09] <Keybuk> yes
[01:10] <slangasek> this is probably user error, but OTOH, it would be good for init to not get wedged
[01:10] <Keybuk> indeed
[01:10] <Keybuk> there's no solution to that using ptrace() though
[01:10] <Keybuk> that's why I plan to switch to using proc_connector
[01:11] <cjwatson> Keybuk: worked around, http://bzr.savannah.gnu.org/lh/man-db/trunk/revision/1148
[01:23] <slangasek> Keybuk: <whimper> ok, and in the case of statd, the daemon itself spawns a subprocess before it detaches
[01:24] <slangasek> Keybuk: how do I make /that/ work?
[01:24] <Keybuk> meh
[01:24] <Keybuk> I don't think you can\
[01:24] <Keybuk> not without patching the code
[01:24] <Keybuk> you could make statd raise (SIGSTOP);
[01:25] <Keybuk> and use "expect stop"
[01:25] <Keybuk> instead of making it fork
[01:25] <slangasek> whee
[01:25] <slangasek> or I could pass the -L argument to tell it not to call sm-notify
[01:26] <Keybuk> ;)
[01:26] <Keybuk> so yeah, it probably got fixated on sm-notify
[01:26] <Keybuk> and then never got SIGCHLD for it
[01:27] <evand> anyone have an Ubuntu CD/USB, a SD card, and a willingness to destroy whatever data is on it?
[01:30] <kirkland> evand: sure
[01:30] <kirkland> evand: usb stick
[01:31] <evand> kirkland: cool.  Can you boot from the USB stick and try to install to the SD card with ubiquity?
[01:31] <evand> I probably should've mentioned you'll need at least a 2.3GB SD card
[01:31] <evand> it may explode when it gets to grub-installer.  Either way I'm happy.
[01:32] <slangasek> the SD card may explode?
[01:32] <kirkland> evand: hmm, all i have is 2GB cards
[01:32] <evand> damn
[01:32] <evand> thanks the same
[01:32] <kirkland> evand: sorry
[01:32] <evand> no worries.  Worst case I head to argos/currys tomorrow
[01:36] <evand> err actually, that won't work
[01:41] <yuriy> pitti: ping
[01:42] <TheMuso> yuriy: He is likely not around at the moment. I suggest either emailing him or simply leaving a message for him on IRC and waiting till he responds.
[02:06] <evand> nevermind about the SD card.  I found a machine that can read SDHC.
[02:27] <evand> what's the magic rune for changing the privacy of a bug in the new Launchpad UI?
[02:28] <cjwatson_> edit icon next to "This report is private", top right?
[02:33] <spstarr> hrm, if you build a custom kernel via https://wiki.ubuntu.com/KernelTeam/GitKernelBuild,  you do not see /proc/filesystems show usbfs.. yet ubuntu's kernels do even using ubuntu's .config what gives?
[02:34] <spstarr> is there something broken in make-kpkg?
[02:34] <TheMuso> spstarr: Do your kernels have an initramfs? That might be whats responsible for mounting usbfs, however I am not entirely sure.
[02:34] <spstarr> they do, i do not know what default modules it uses though
[02:35] <spstarr> i can explode the ramfs to check
[02:35] <spstarr> i may need to explicitly mention --added-modules usbcore (even though ubuntu compiles this into kernel anyway)
[02:36]  * spstarr looks at the debian/* dir
[02:37] <spstarr> oooh
[02:37] <spstarr> wait  a second
[02:38] <spstarr> yes i do have one, initrd.img-2.6.31.1-custom it wouldn't boot otherwise
[02:38] <spstarr> but how this is getting built is what im curious about
[02:38] <spstarr> where can I find the default fakeroot for the initramfs images?
[02:41]  * spstarr gets source of ubuntu deb kernel
[02:45] <TheMuso> spstarr: The pieces that get put into the initramfs as well as scripts to copy binaries over are found in /usr/share/initramfs-tools
[02:45]  * spstarr looks
[02:46] <spstarr> aha that's the init i was looking for
[02:46] <spstarr> however.. /proc/filesystems only gets usbfs if usbcore is loaded
[02:46] <spstarr> afaik
[02:48] <spstarr> since usbcore has to register the filesystem to /proc/filesystems
[02:48] <spstarr> so this is why im confused :)
[02:48] <TheMuso> spstarr: Not sure why things aren't working for you sorry
[02:49] <spstarr> if i compile usbcore or leave it compiled into kernel
[02:49] <spstarr> you'd assume /proc/filesystems would have usbfs
[02:49] <spstarr> unless its depending on the machine im building the deb on
[02:53]  * spstarr examines both initramfs
[02:54] <spstarr> and sings the little song "one of these ramdisks is not like the other"
[02:57] <spstarr> my initramfs has usbcore in it
[02:58] <spstarr> even more odd is i did see
[02:58] <spstarr> [    0.229755] usbcore: registered new interface driver usbf]
[02:58] <spstarr> usbfs
[03:16] <spstarr> hmmmmmmmm
[03:16] <spstarr> bug #417748
[03:16]  * spstarr looks at this
[03:17] <spstarr> ewwwww
[03:18] <spstarr> it seems everyone is using the WRONG PATH for usbfs
[03:18] <spstarr> you should be using /sys/bus/usb/drivers now not /proc for it anymore
[03:20] <spstarr>  if you do not enable CONFIG_USB_DEVICEFS doesn't it defer to both /sys/bus/usb/drivers AND /proc/bus/usb??
[03:21] <slangasek> "everyone"?  I'm not aware of anything in Ubuntu using the /proc path anymore
[03:21] <spstarr> aha
[03:21] <spstarr> # CONFIG_USB_DEVICEFS is not set
[03:21] <spstarr> thats why my custom kernel fails
[03:21] <spstarr> karmic has this turned OFF
[03:21] <spstarr> which thus disables usbfs period
[03:22] <spstarr> aha
[03:22] <spstarr> damint
[03:22] <spstarr> config-2.6.31-10-generic:CONFIG_USB_DEVICEFS=y
[03:22] <spstarr> config-2.6.31.1-custom:# CONFIG_USB_DEVICEFS is not set
[03:22] <spstarr> config-2.6.31-9-generic:# CONFIG_USB_DEVICEFS is not set
[03:22] <spstarr> I took -9 :D
[03:22] <spstarr> ahahahaha fsck me
[03:22] <spstarr> you just fixed this issue
[03:23] <spstarr> slangasek: don't you love it when a bug happens JUST like this?
[03:23] <spstarr> :)
[03:25]  * spstarr adds to the bug for anyone else looking
[03:30] <spstarr> there
[03:30] <spstarr> but since buntu enabled the option, nobody will run into this issue again
[03:37] <Darxus> I provided the missing information which caused an LP bug to be marked incomplete.  Can I change its status?  To what?
[03:39] <Darxus> The previous status was Fix Committed.
[03:40] <Darxus> I switched it to confirmed.
[03:40] <lifeless> Darxus: if it was fix committed, then the bug was fixed, wasn't it ?
[03:41] <Darxus> lifeless: I was told that fix committed doesn't mean a new package was uploaded.  And, in fact, a new package was not uploaded.
[03:41] <Darxus> That would be Fix Released.
[03:41] <slangasek> LaserJock: do you have anything you'd like to highlight about Edubuntu 9.10 in https://wiki.ubuntu.com/KarmicKoala/BetaAnnouncement ?
[03:42] <Darxus> #410933
[03:42] <Darxus> https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/410933
[03:43] <slangasek> cody-somerville: are there particulars to Xubuntu 9.10 that you'd like highlighted on https://wiki.ubuntu.com/KarmicKoala/BetaAnnouncement ?
[03:43] <slangasek> superm1: ^^ mythbuntu
[03:43]  * cody-somerville nods.
[03:43] <slangasek> luisbg, TheMuso: ^^ ubuntu studio :)
[03:43]  * cody-somerville grabs the edit lock.
[03:44]  * slangasek grabs the dinner lock
[03:45]  * superm1 doesn't have any locks left to grab
[03:49] <Darxus> Just read through launchpad's definitions of status and I'm happy with "confirmed".
[03:57] <TheMuso> slangasek: Not really, this cycle has not been big for us at all, due to a lack of participation in general from the team.
[03:58] <slangasek> TheMuso: ok; I'll omit the break-out section for US then, rather than asking people to make things up :)
[04:08] <Darxus> A "backtrace" is only available after something crashes, right?
[04:09] <LaserJock> slangasek: maybe let's do the same for Edubuntu. We haven't really changed anything since Alpha6
[04:31] <slangasek> LaserJock: what about changes since jaunty?
[04:32] <LaserJock> slangasek: well, the whole DVD thing is a pretty radical change
[04:33] <LaserJock> slangasek: perhaps also ltsp-cluster might be of note, beyond the usual fixes and updated packages
[04:46] <TheMuso> 6/c
[04:55] <ScottK> LaserJock: I think you have to write for the audience that didn't notice until the beta release.
[05:01] <slangasek> indeed
[05:06] <LaserJock> slangasek: ok, I'll take a crack at it then
[05:16] <Darxus> The version of Debian that will be merged into Karmic is.. what?
[05:16] <lifeless> None
[05:17] <lifeless> karmic is frozen
[05:17] <lifeless> specific packages can be merged by special request, and they can come from anywhere
[05:18] <Darxus> Sorry, I should have used past tense.  Sid / unstable is the answer.
[05:19] <Darxus> Shame, the reasonably current version of hugin didn't make karmic :/
[05:19] <Darxus> I guess there's nothing for me to do though, it'll get merged for Lucid.
[05:20] <Darxus> Ah, the bug wasn't even opened until 2 days after Debian import freeze.
[05:20] <ScottK> Darxus: For a game, a freeze exception is quite possible.
[05:24] <Darxus> It's not a game, it's a photo stitching program.
[05:24] <Darxus> Is that possible?
[05:24] <Darxus> Why is debian import freeze 4 months before final release?
[05:25] <jdong> automatic debian import freeze is so, to start the process of stabilizing things
[05:25] <jdong> during that phase sync requests are quite generously granted IMO
[05:27] <Darxus> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/416101
[05:27] <Darxus> Seems like that should be high priority for karmic.
[05:27] <Darxus> jdong: Cool, thanks.
[05:31] <ScottK> Darxus: Right.  I got my packages mixed up.
[05:31] <ScottK> TheMuso: Do you have an opinion on 416101?
[05:33] <slangasek> cody-somerville: hmm, was hoping for something a bit shorter on Xubuntu; can you pick one or two key features and link off to the Xubuntu page for the rest, please?
[05:34] <cody-somerville> slangasek, aye
[05:49]  * TheMuso looks
[05:50] <spstarr> PA should be pulled, period :p
[05:50] <spstarr> even the PPA builds still spectacularly fail
[05:50] <TheMuso> ScottK: Oh right, will take care of that. Unfortunately pulse still causes a11y issues, but I have work-arounds in place to at least try and lessen the problems.
[05:50] <TheMuso> spstarr: How do they fail? Please file a bug.
[05:50] <spstarr> ALSA finally works with my multiple audio apps
[05:50] <spstarr> TheMuso: i did, but is marked as incomplete and nobody has changed it
[05:51] <spstarr> i gave all the debug crash info
[05:52] <TheMuso> spstarr: Bug number?
[05:52] <TheMuso> spstarr: Its likely because we have been too busy with other bugs.
[05:52] <spstarr> getting
[05:52] <spstarr> TheMuso: well I pulled PA out and now Second Life works, VirtualBox works sharing same audio input/output
[05:52] <spstarr> using ALSA only
[05:53] <TheMuso> spstarr: THats a work around, but it would be good to fix pulseaudio.
[05:53] <TheMuso> spstarr: You have tried the absolute latest version in the ubuntu-audio-dev PPA?
[05:54] <spstarr> well, yeah, but we should be asking, why can't we fix ALSA to do most of what PA wants to do and strip PA down to just a network audio daemon?
[05:54] <spstarr> well, not the newest PPA bug # is
[05:54] <spstarr> bug #424551
[05:55] <TheMuso> spstarr: This discussion has bene covered many times and in many different places. I can't remember where such discussions are on the web atm, but I'll see what I can dig up.
[05:55] <spstarr> TheMuso: well, if ALSA has deficiencies (and it does) time for another audio rewrite for kernel?
[05:56] <spstarr> i mean, we can replace the scheduler subsystem, etc, why not sound? :)
[05:56] <spstarr> IANAKD
[05:57] <TheMuso> Hrm regarding this bug, dtchen is much better at working out whats going on than I am. Feel free to change the status back to new, so it is more likely to be noticed again.
[05:58] <spstarr> the problem i have with PA is the fact it is a userspace daemon
[05:58] <TheMuso> spstarr: As for your arguments re audio, again, I know why, but I am not very good at expalining it ni an understandable way, so I'll have to find you some discussion references.
[05:58] <spstarr> if it keels over there goes ALL your audio
[05:58] <TheMuso> spstarr: Well floating point maths is not allowed in the kernel PERIOD.
[05:58] <spstarr> that's right
[05:58] <TheMuso> spstarr: And other OSs are doing something similar, i.e audio processing in userspace.
[05:59] <spstarr> but PA seems so not ready for production
[05:59] <spstarr> it cannot handle heavy loads
[05:59] <spstarr> i can count how many times PA has burned me so much i ripped it out, now I am not willing to put it back for a least a few years
[05:59] <TheMuso> spstarr: Perhaps you want to take this up with upstream. I suggest going into #pulseaudio and chatting with mezcalero/Lennart when he is around.
[05:59] <spstarr> now that ALSA is cooperating with me finally
[06:00] <spstarr> TheMuso: that could get very messy :)
[06:00] <TheMuso> spstarr: Have you tried other distros, to see if they behave the same?
[06:00] <TheMuso> spstarr: Only if you let it.
[06:00] <spstarr> yep
[06:00] <spstarr> I used Fedora prior, Debian prior that (with a splash of buntu in 2006)
[06:01] <spstarr> now (k)buntu
[06:01] <TheMuso> Well pulse has come a long way since then, so if you can't reproduce these problems in Fedora for example, then we are doing somethnig wrong and need to address it.
[06:01] <spstarr> or as I call it, buntu :)
[06:01] <spstarr> I can reproduce them in Fedora :)
[06:01] <TheMuso> Ok then.
[06:01] <TheMuso> My suggestino still stands. Chat to Lennart on IRC in #pulseaudio when he is around, or email the mailing list.
[06:01] <TheMuso> suggestion even
[06:02] <spstarr> yes
[06:02] <spstarr> but for now, ALSA is working for my needs (amazingly)
[06:04] <spstarr> brb
[06:38] <al-maisan> Good morning!
[06:44] <dholbach> good morning
[06:51] <rgreening> hey dholbach
[06:56] <dholbach> hi rgreening
[07:20] <pitti> Good morning
[07:20] <pitti> hey yuriy
[07:22] <dholbach> james_w: looks like we should be quick for UOW if we don't want a 23 UTC slot for our session: https://wiki.ubuntu.com/UbuntuOpenWeek/Prep - shall we do a double session?
[07:22] <dholbach> james_w: maybe we can still move things around a little bit :)
[08:12] <dholbach> cjwatson: how can I run ubiquity on an installed system just to do a few screenshots?
[08:13] <cjwatson> I'm not going to give advice on that because I consider it very unwise!
[08:13] <dholbach> oh ok
[08:13] <cjwatson> you can install the package and run it, but it may make changes to your system even before the summary screen
[08:13] <dholbach> ok, I see
[08:13] <cjwatson> since it assumes that it's OK to make changes to the live environment
[08:13] <dholbach> I'll use a VM then - no worries
[08:13] <dholbach> it's just to update a few screenshots
[08:13] <cjwatson> yeah, that's much safer and easier
[08:14] <dholbach> example-content still speaks about "espresso" ;-)
[08:15] <florian__> hey guys... Florian from France. Does anyone know when exactly the beta will be released ?
[08:15]  * dholbach fixes that :)
[08:15] <cjwatson> dholbach: hah
[08:15] <cjwatson> florian__: please don't ask that sort of thing
[08:15] <cjwatson> florian__: the people with specific information on exactly what time are also critical-path to getting it out
[08:15] <cjwatson> so we do not encourage bugging them
[08:16] <cjwatson> it will happen at some point, go and enjoy yourself in the meantime :)
[08:16] <cjwatson> if you're a mirror operator, then #ubuntu-mirrors might have more information, or you could arrange to have yourself set up as a push mirror
[08:17]  * cjwatson -> breakfast
[08:17] <florian__> cjwatson: I'm not... I guess i just can't wait... :)
[08:17] <florian__> cjwatson: what do you mean by critical-path ?
[10:09] <dholbach> pitti: uploading an updated example-content now - it should free up 1M! :-)
[10:09] <dholbach> accept whenever it seems suitable
[10:16] <pitti> yay you!
[10:16] <pitti> dholbach: we'll flush the queue after beta release
[10:16] <dholbach> cool
[11:05] <pitti> hrmpf gdm == GodDammit Bugpile
[11:29] <slangasek> Keybuk: shouldn't upstart have respawn rate limiting that would prevent bug #431166?
[11:29] <lidaobing> hello, help check bug #427725, whether we can sync ibus-m17n from debian?
[11:32] <Keybuk> slangasek: gdm restarts X indefinitely
[11:32] <Keybuk> it's not gdm that's restarting
[11:32] <slangasek> oh
[11:32] <slangasek> doh
[11:32] <slangasek> excuse my wayward task opening, then
[11:32] <seb128> the previous gdm had code to avoid that
[11:33] <seb128> yet another thing the new codebase does in a buggy way compared to the previous one
[11:40] <dmart> Slightly related to this, I eventually abandoned trying to get XDMCP connections to work for connecting to Karmic's gdm...  I added a /etc/gdm/custom.conf with [xdmcp]/Enable=true, and added an appropriate entry in hosts.allow, but that isn't adequate.
[11:40] <dmart> I also found I had to set [xdmcp]/DisplaysPerHost > 1 for the querying host to be able to connect at all, and even then I just get a blank display, with gdm appearing to do nothing after the initial connection.
[11:40] <dmart> Any thoughts?  I'm using Cygwin/X here, which may be part of the problem.  Worked with Jaunty though.
[11:41] <Keybuk> seb128: a side conversation at plumbers was that you can *almost* entirely replace gdm with upstart
[11:41] <Keybuk> since new gdm has gotten so basic
[11:42] <pitti> oh, can I stop fiddling with this gdm keyboard mess then? :-)
[11:43] <slangasek> heh
[11:44] <pitti> seb128: ugh, the new gtk theme for gdm is pretty ugly; I already thought I broke something..
[11:44] <pitti> until I realized that bzr head had a newer version
[11:44] <seb128> pitti, hey, rick was wondering if it was not better with the standard one
[11:44] <pitti> bubble help has no contrast any more and looks buggy
[12:26] <Dennis-Beekman> afernoon everyone
[12:26] <Dennis-Beekman> do we have a beta yet ?
[12:26] <davmor2> no
[12:27] <Dennis-Beekman> :-(
[12:27] <Dennis-Beekman> when is it expected ?
[12:27] <Dennis-Beekman> any time indication ?
[12:31] <slangasek> mdke: lp:~vorlon/gnome-user-docs/ubuntu-karmic/ - I can't commit directly to the ubuntu-core-doc branch, so please merge
[12:32] <slacker_nl> Dennis-Beekman: just await the announcement
[12:59] <Dennis-Beekman> https://wiki.ubuntu.com/KarmicKoala/BetaAnnouncement
[12:59] <Dennis-Beekman> it's here !!
[13:00] <Dennis-Beekman> none off the mirror's have the actual image yet though :-(
[13:00] <slangasek> that's an email draft.
[13:01] <alourie> slangasek: I wanted to ask you something about that draft, but didn't want it to make to the maillist...
[13:01] <Dennis-Beekman> yeah.. but it's the actual announcement
[13:01] <slangasek> no, it's not the "actual announcement", it's an email draft.
[13:01] <slangasek> alourie: oh?
[13:01] <alourie> in the "under the hood" section you mentioned python version
[13:02]  * slangasek nods
[13:02] <alourie> slangasek: is it that basic that it should be mentioned? What about, say, perl?
[13:02] <alourie> I mean, is it on the level of kernel/gcc ?
[13:03] <slangasek> alourie: python is central to Ubuntu's development environment; perl less so :)
[13:03] <liw> Dennis-Beekman, when it is announced, there will be an e-mail on ubuntu-devel-announce; until then, it is not announced and it is not released, please be patient
[13:03] <alourie> slangasek: yea, that's what I thought. That's why I didn't send this to the maillilst...
[13:03] <slangasek> liw: ubuntu-announce, actually
[13:04] <alourie> slangasek: thanks, that answers my question. Besides that, I think it's perfect :-)0
[13:04] <slangasek> alourie: ok, great :)
[13:08] <cjwatson> Dennis-Beekman: we appreciate your enthusiasm, but rushing around like this actually consumes time from the people who are responsible for preparing the release, so please don''t
[13:08] <cjwatson> Dennis-Beekman: and when the release manager tells you that something isn't the actual announcement, he probably actually knows better than you ... :-)
[13:10] <yuriy> pitti: any ideas on bug 419501? I'm finding a lot of dupes, and most of them are in apport, but a few in other apps
[13:12] <pitti> yuriy: I'm afraid not; I tried it in Kubuntu as well, but coulnd't reproduce
[13:14] <yuriy> yeah I haven't seen it myself, but was concerned because I was finding so many reports
[13:16] <liw> seb128, about #421318 (totem python crash): I've attached a patch, could you upload once the beta freeze is over?
[13:17] <slangasek> liw: oh cool, you caught that bug?
[13:18] <liw> slangasek, I asked upstream, upstream replied with patch
[13:18] <slangasek> ah
[13:18] <slangasek> :)
[13:18]  * liw is totally innocent of any actual bug fixing here
[13:18] <seb128> liw, thanks, will do, the change is quite easy which is good
[13:18] <seb128> I was not sure if you were going to rewrite half of the code yesterday ;-)
[13:19] <liw> seb128, I still maintain that the proper fix is to not use the combinations gtk+threads or python+threads (or gtk+python+threads), but I'm happy this particular bug got fixed easy :)
[13:19] <liw> seb128, I don't see a bug about this in Debian, but if I missed one, I assume you'll take care of it there as well
[13:20] <seb128> liw, debian doesn't have the bbc change, it's an ubuntu one, it's still being discussed upstream and not accepted there yet
[13:20] <seb128> liw, I will update the upstream bug though
[13:20] <seb128> liw, but nice to see it fixed so quickly ;-)
[13:20] <liw> seb128, ah; otoh, the bug was actually generic for all Python plugins
[13:21] <seb128> liw, right, I was expecting something like that but not sure, contacting upstream was a good idea there
[13:21] <seb128> liw, is there any other python one in the default set?
[13:22] <liw> seb128, coherence_upnp, dbus-service, opensubtitles?
[13:23] <seb128> liw, ok, I didn't look to those, just weird that they didn't crash
[13:23] <seb128> anyway that's fixed so all good now
[13:35] <Darxus> The switch to pulse audio took place in jaunty?
[13:35] <Darxus> Ah, looks like Hardy.
[13:36] <seb128> what do you call switch?
[13:36] <seb128> it's installed since hardy
[13:53] <Guest87434> when will 9.10 beta be out?
[13:53] <cjwatson> please don't ask that here
[13:53] <pitti> for every question like this it'll release an hour later :)
[13:53] <cjwatson> for that matter, please just don't ask it - wait :)
[13:54] <Guest87434> ok :P consider it not asked
[13:54] <Guest87434> BTW, nice work ;)
[13:55] <Pici> Guest87434: If you want somewhere to wait, #ubuntu+1 will be abuzz when its actually released.
[13:58] <Guest87434> Pici: Thnks
[14:01] <pitti> Keybuk: for bug 397734, do you think we can/should change the default in our kernel for karmic?
[14:01] <pitti> Keybuk: default -> CD tray locking state, I mean
[14:18] <Keybuk> pitti: if it's unlikely to introduce regressions
[14:18] <Keybuk> I'd rather it was done by changing the in-kernel default though
[14:18] <Keybuk> adding a config file to run on boot costs time
[14:18] <pitti> Keybuk: yes, that's what I meant
[14:51] <yuriy> pitti: what is now the policy for apport after release? does it get disabled?
[14:52] <pitti> yuriy: we'll disable crash interception right after the release candidate, but of course we'll keep it for bug reporting
[14:52] <pitti> (or for people enabling it manually)
[14:52] <dholbach> yuriy: get too many bug reports for a crash? :)(
[14:54] <yuriy> ok it's the crash interception i'm wondering about.  I'm not sure what to do with it. the way we have it set up now is KDE will fall back to its own crash handler if apport is disabled, which means upstream will get the report if the user chooses to send it, and I don't think we want that (IMO, will bring it up at the next kubuntu meeting) but otherwise apps will just fail silently
[14:54] <yuriy> pitti: do gnome apps just crash silently if apport is disabled?
[14:54] <pitti> s/gnome//, yes
[14:54] <yuriy> s/gnome/non-KDE
[14:57] <Keybuk> wow, O'Reilly are "not publishing books on Linux internals any more"
[14:57] <jdong> Keybuk: what! :( I liked some of those books
[14:58] <jdong> is it only cool to have 1000 page screenshots of GNOME these days?
[15:01] <Keybuk> or books by jono ;)
[15:01] <jdong> haha :)
[15:02] <jono> screw you guys, I'm going home
[15:02] <jdong> hahah :)
[15:03] <dholbach> jono: you're at home already! :)
[15:03] <jdong> hmm are all policykit "Actions" supposed to show up in the Authorizations GUI thingie?
[15:03] <jdong> I'm trying to figure out how to give a user authorization to use update-manager
[15:03] <pitti> yuriy: ah, you keep the KDE crash handler enabled for release?
[15:03] <Keybuk> james_w: your patch needs to be done with git format-patch ;)
[15:04] <james_w> you mean git can't accept normal patches?!?!?
[15:05] <mbiebl> jdong: you mean with policykit-1?
[15:05] <Keybuk> james_w: upstream policy
[15:05] <Keybuk> you have a git clone of dbus already I assume?
[15:05] <jdong> mbiebl: yeah I suppose that's what we use in Karmic
[15:05] <Keybuk> in which case "git commit -s" to commit your patch with a signed-off-by line
[15:05] <yuriy> pitti: it was enabled and untouched until Intrepid.  In Intrepid, we started disabling it if apport is enabled, but never did anything about it after release.
[15:05] <Keybuk> first line of the commit is the "subject"
[15:05] <Keybuk> then blank line
[15:05] <Keybuk> then body explanining change
[15:05] <james_w> I don't have a clone
[15:05] <Keybuk> oh, where did you get the Index: lines from?
[15:06] <james_w> quilt
[15:06] <Keybuk> ah
[15:06] <Keybuk> s'ok, I'll do it for you then ;)
[15:06] <james_w> thanks
[15:07] <mbiebl> jdong: the idea with pk 1 is to use groups again to grant access automatically for certain actions
[15:07] <Keybuk> james_w: you wrote the patch?
[15:07] <james_w> I did
[15:08] <james_w> with my own two hands
[15:08] <jdong> mbiebl: ah, I see; how do  you associate a group with an action then?
[15:08] <Keybuk> ok
[15:08] <mbiebl> jdong: this is an example from the fedora package: http://pastebin.ca/1587773
[15:09] <jdong> mbiebl: aha, that helps
[15:11] <zul> james_w: ping can you place samba in the bzr for distributed development?
[15:12] <Keybuk> james_w: http://cgit.freedesktop.org/dbus/dbus/commit/?id=03cc20707a3e7b2d8629e84d7a766f41edb8b444
[15:12] <james_w> zul: sorry, samba failed, I need to investigate what the fix is, so it's not a two minute job
[15:13] <zul> james_w: ah ok thanks
[15:13] <Chipzz> pitti: or: "Every time someone asks, god kills a kitten" ;)
[15:13] <james_w> thanks Keybuk
[15:14] <zul> pitti: is it done yet is it done yet how about now?
[15:15] <pitti> meeeeeeeeeeeeeeeeeeeoooooooooooowwww!!
[15:17] <BenjaminKreuter> does anyone know if there is a way to monitor all patches that are merged into all ubuntu packages?
[15:17] <ogra> http://patches.ubuntu.com/ probably
[15:18] <joaopinto> check the .diff.gz for each package :) ?
[15:18] <joaopinto> ogra, is that build from debian/patches ?
[15:18] <pitti> lool, doko_: .eh_frame armel> awesome work! do you still want the genTOObuntu OO.o to be built, or shall I reject it from the queue? (you mentioned that an easier workaround was to use -fno-dwarf2-cfi-asm)
[15:19] <ogra> joaopinto, no idea
[15:19] <dholbach> or there's the ubuntu-patches mailing list
[15:19] <ogra> dholbach, stop stating the obvious :P
[15:19] <pitti> Keybuk: want me to do the sysvinit upload to drop the sysvinit binary? Or do you have other changes queued for sysvinit anyway?
[15:20] <BenjaminKreuter> dholbach, ogra: thanks
[15:20] <joaopinto> ubuntu.patches is for ubuntu vs debian
[15:20] <doko_> pitti: good question: I was thinking about turning off the armel buildds until we have the fixed toolchain in place, then rebuild.
[15:20] <BenjaminKreuter> joaopinto: yeah i noticed; that is somewhat useful for what i am trying to do
[15:20] <Keybuk> pitti: I have nothing queued, be my guest
[15:21] <Keybuk> pitti: personally I'd wait until after beta freeze is over for that upload
[15:21] <Keybuk> but I'm more scared of slangasek than you ;)
[15:21] <pitti> doko_: fine for me, too; just asking because OO.o takes so long to build on arm, so we probably don't want to do it in vain
[15:21] <doko_> pitti: when do you plan to open the gates?
[15:21] <pitti> Keybuk: I keep uploading to the queue since Tuesday *shrug*
[15:21] <pitti> doko_: after the beta release :)
[15:22] <pitti> Keybuk: I wasn't meaning to accept it before beta :)
[15:22] <slangasek> yes, uploading to the queue is allowed as long as you don't expect it to get into beta
[15:23] <Keybuk> pitti: but then you potentially block critical fixes
[15:23] <Keybuk> if a patch is necessary for the release
[15:23] <Keybuk> but you've queued a bigger uploade
[15:23] <Keybuk> it becomes difficult
[15:23] <Keybuk> e.g. version numbers already claimed, files already existing, etc.
[15:23] <slangasek> Keybuk: speaking of which, I'd love to have an upstart upload in the queue that fixes the behavior of upstart-job, but don't want to upload if you've got other stuff in progress
[15:23] <slangasek> (oh, and I don't have time to upload it right now anyway :P)
[15:23] <robbiew> heh
[15:23] <Keybuk> slangasek: there's the e8s fix pending
[15:24] <slangasek> Keybuk: nope, unapproved queue doesn't claim the version numbers
[15:24] <slangasek> unless you count bzr history
[15:24] <slangasek> but history is mungible
[15:24] <Keybuk> slangasek: you can't upload two things into it with the same version number without rejecting
[15:24] <slangasek> yes, you can
[15:24] <Keybuk> you can?
[15:24] <slangasek> unapproved is special that way
[15:24]  * Keybuk didn't know that ;)
[15:26] <doko_> pitti, lamont: is there a way to accept single builds for armel only?
[15:26] <Keybuk> so should I upload these dbus and upstart packages to the queue?
[15:26] <ogra> and possibly route them to the marvell buildd :)
[15:26] <pitti> Keybuk: sure, go ahead
[15:27] <pitti> doko_: not for me
[15:28] <ogra> doko_, ask lamont to put all buildds but safou on manual after your upload, so oo.o must build on the speedy buildd :)
[15:28] <ogra> s/after/right before/
[15:28] <ogra> i bet that gains you some hours
[15:28] <doko_> pitti, lamont: proposal to prepare binutils, eglibc and gcc-4.4 uploads, accept these before lifting the freeze, then setting all armel buildds to manual
[15:29] <pitti> doko_: hm, that would mean that we would have to set all buildds for the other arches to manual, too, though?
[15:29] <lool> pitti: Please keep the oo.o we have in the queue, I think we're still testing the rebuild oo.o
[15:30] <pitti> lool: *nod*; just asking :)
[15:30] <doko_> pitti: no
[15:30] <pitti> doko_: or alternatively hack soyuz to drop the build records for !armel
[15:30]  * cjwatson vetoes hacking soyuz right now
[15:30] <cjwatson> bad plan
[15:30] <doko_> pitti: I think that's not necessary
[15:30] <pitti> but then they'd be out of date on all other archies
[15:30] <pitti> it sounds very hackish
[15:31] <pitti> I think we should just wait the few hours until the release
[15:31] <pitti> doko_: private armel PPA and binary copying?
[15:31] <cjwatson> I don't have a problem putting the armel buildds on manual, though I think doko can do that too
[15:31] <pitti> sounds much safer to me
[15:32] <doko_> pitti, cjwatson: does binary copying work? Then I could start the builds now
[15:32] <cjwatson> I would prefer them to be built in the main archive, to be honest
[15:32] <doko_> ok
[15:32] <cjwatson> complicated archive games are not my idea of fun at the moment ...
[15:36] <pitti> Keybuk: sysvinit> oh argh, dh compat 1; that becomes much more intrusive than I thought
[15:39] <lamont> pitti: _1_???  wow
[15:42] <pitti> anyway, uploaded
[16:12] <jdstrand> Keybuk: could an sreadahead segfault interrupt the boot process?
[16:13] <jdstrand> Keybuk: (hi btw)
[16:13] <jdstrand> Keybuk: I just filed filed bug #440046
[16:13] <Keybuk> I don't see how
[16:13] <jdstrand> Keybuk: there are several private bugs that are likely dupes
[16:13] <jdstrand> hmmm
[16:13] <Keybuk> *shrug*
[16:13] <kees> lool: I have tools that scan the archive for all sorts of things (e.g. ELF sections).  How can I help with your ARM stuff?
[16:13] <Keybuk> I ignore all private bugs
[16:13] <Keybuk> well, that's not quite true
[16:14] <Keybuk> private bugs don't end up in my INBOX
[16:14] <Keybuk> so I never see them
[16:14]  * jdstrand wonders if it was the recent gdm change that kept it from starting...
[16:14] <Keybuk> it's like the difference between abstinence and being ugly
[16:14] <jdstrand> heh
[16:15] <jdstrand> Keybuk: if you are interested, I could hook you up on those private bugs ;)
[16:15] <Keybuk> not especially :p
[16:16] <Keybuk> oh, I've seen that stack trace before
[16:16] <lool> kees: That would help a lot
[16:16] <Keybuk> there's zero useful information in it :-/
[16:16] <lool> kees: That's exactly the type of help-ing stuff I was looking for, thanks   :-)
[16:17] <kees> lool: the down-side is that the current tool expects a local mirror.  perhaps it can be run on rookery, though.
[16:17] <lool> kees: It's ok, I'm building one
[16:17] <kees> lool: so what characteristics are you checking for?
[16:18] <lool> kees: It's not entirely in stone yet, it seems we want to look for to scan for R_ARM_RELATIVE in TEXTREL sections
[16:18] <kees> lool: what command line would show that?
[16:18] <lool> kees: It's not clear whether I need to scan for eh_frame sections too
[16:21] <lool> kees: I'm not sure; I shall start with binaries matching readelf -a | grep TEXTREL
[16:21] <kees> lool: do you know of one that matches currently?
[16:22] <lool> kees: I'm still trying to get input on what exact characteristics to look for in the binaries and whether that really implies in all cases that they are borken
[16:22] <lool> kees: libc
[16:22] <lool> lool@dove:~$ readelf -a /lib/libc.so.6 | grep TEXTREL 0x00000016 (TEXTREL)                    0x0
[16:23] <lool> kees: Sorry, after TEXTREL is the output
[16:23] <lool> Output is:
[16:23] <lool>  0x00000016 (TEXTREL)                    0x0
[16:23] <lool> (IRC client being too clever)
[16:30] <jdstrand> cjwatson: hi! so, I'm having a problem with usplash 0.5.39 and gdm 2.28.0-0ubuntu8. I upgraded this morning, dutifully rebooted (as I was told to) and the boot hung and gdm did not start.
[16:30] <jdstrand> cjwatson: this was with usplash 0.5.39 and gdm 2.28.0-0ubuntu8
[16:31] <jdstrand> cjwatson: I downgraded usplash to 0.5.38 (but not libusplash0 as I just noticed) and gdm to 2.28.0-0ubuntu6, rebooted and it worked fine
[16:31] <jdstrand> cjwatson: unfortunately, I am rather notoriously bad at debugging usplash, and not sure where to start
[16:34] <cjwatson> jdstrand: can you find what processes are running?
[16:34] <cjwatson> when it hangs
[16:35] <cjwatson> ps aux | grep usplash is probably a good start
[16:36] <jdstrand> cjwatson: ok, let me upgrade and reboot
[16:37] <kees> lool: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/files/head%3A/repo-tools/  look at "for-archive", and the tools in the "for-archive-tools" directory
[16:38] <kees> lool: the comments at the top of for-archive detail some example runs
[16:38] <kees> lool: it was originally built for scanning source, but it works on binaries too
[16:38] <kees> lool: the execstack one is a good example of that.
[16:39] <kees> lool: the "for-archive-tools/has-execstack" is probably a reasonable starting point for the tool you'll want to create that does the TEXTREL test
[16:40] <lool> kees: Cool thanks
[16:41] <kees> lool: let me know if you have any questions, some of it is a bit non-obvious.  :P
[16:41] <jdstrand> cjwatson: ok. first off-- no splash screen at all
[16:41] <jdstrand> cjwatson: second, ps auxww|grep usplash shows usplash is not running
[16:42] <lool> kees: Ok
[16:43] <cjwatson> jdstrand: ok, are there any usplash-related processes running, such as usplash_write?
[16:43] <jdstrand> cjwatson: I see output from the last script in /etc/rc2.d
[16:43] <cjwatson> jdstrand: also, | grep initctl
[16:44] <jdstrand> cjwatson: the new initctl emit you added is present
[16:44] <cjwatson> jdstrand: can I see a complete ps auxfww?
[16:44] <jdstrand> initctl emit starting-dm DM=gdm
[16:44] <jdstrand> hold on
[16:44] <cjwatson> right, I expect it's blocked on something, but would like to find out what
[16:47] <jdstrand> cjwatson: http://paste.ubuntu.com/283083/
[16:53] <jdstrand> initctl emit and found it sometimes would hang...
[16:53] <jdstrand> err
[16:54] <jdstrand> I totally lost the first part of that sentence
[16:55] <jdstrand> cjwatson: fyi, in my recent foray into upstart I played with 'initctl emit' and found it would hang. I figured I was doing something wrong and abandoned using it
[16:55] <Keybuk> jdstrand: what does "status usplash" say?
[16:55] <jdstrand> Keybuk: usplash stop/killed, process 439
[16:55] <Keybuk> and you have no process 439?
[16:55] <jdstrand> Keybuk: correct
[16:56] <Keybuk> don't suppose, before the call to initctl emit, you could add a ps dump and status usplash command
[16:56] <Keybuk> log them somewhere
[16:56] <Keybuk> and reboot until you get the hang again?
[16:56] <jdstrand> sure I could
[16:56] <Keybuk> then we'd have a log of what the usplash pid really was
[16:56] <Keybuk> what upstart thought it was
[16:56] <Keybuk> etc.
[17:00] <cjwatson> jdstrand: initctl emit blocks until any jobs that hook off that event are done
[17:01] <jdstrand> Keybuk: http://paste.ubuntu.com/283095/
[17:02] <Keybuk> interesting
[17:02]  * Keybuk wonders whether that pid is even right
[17:03] <jdstrand> I have 'quiet splash' on the kernel line
[17:03] <slangasek> it must be right, pid 1 isn't allowed to be wrong :P
[17:05] <cjwatson> maybe this is a consequence of my stupid 'exec true' hack
[17:05] <cjwatson> I bet it works if you put USPLASH=y in /etc/initramfs-tools/initramfs.conf
[17:05] <cjwatson> because that pid is higher than all the processes started in the initramfs, so it must have been started later
[17:06] <jdstrand> I don't have a USPLASH=... line in there at all
[17:06] <jdstrand> shall I add it?
[17:06] <cjwatson> it should work as a workaround, but (a) it's not the desired distro default and (b) Keybuk may want to debug more first
[17:07] <cjwatson> oh, hmm, maybe it isn't higher than all the initramfs processes, I can't read
[17:07] <cjwatson> line numbers != pids
[17:07] <jdstrand> ok, wasn't sure if maybe my file should've had it
[17:08] <cjwatson> no
[17:08] <cjwatson> Keybuk: I'm properly stumped now as to what it's blocked on, though, since apparently usplash_write wasn't running
[17:08] <Keybuk> upstart thinks it is
[17:08] <Keybuk> with pid 439
[17:08] <Keybuk> so it's waiting for SIGCHLD with that pid
[17:09] <Keybuk> since that pid doesn't exist, that will never happen
[17:09] <Keybuk> could be maybe usplash exited before the initramfs?
[17:09] <jdstrand> I might say that usplash has been wonky on this machine in the past
[17:09] <mdz> kirkland, I have cleaned up some of the upstart scripts based on the earlier discussion with Keybuk.  I've eyeballed the changes, but can't quite test them at the moment.  is it ok if I push to the ubuntu branch anyway, and you bring them into your next upload?  if I made any mistakes, they should be easy to spot and correct
[17:09] <Keybuk> jdstrand: when do you see it vanish?
[17:09] <jdstrand> I'd see it on boot, and then it would go away and I'd see text
[17:10] <jdstrand> Keybuk: currently, I never see it. if I downgrade usplash/gdm, I can check
[17:10] <Keybuk> hmm
[17:10] <cjwatson> it's possible for it to time out before the initramfs of course ...
[17:10] <Keybuk> cjwatson: sounds like jdstrand's bug is that a usplash pid is being written, but when upstart starts, there's nothing with that pid
[17:10] <cjwatson> (in general, presumably not for jdstrand)
[17:11] <Keybuk> the hack could probably do with more safeguards
[17:11] <jdstrand> Keybuk: would it be helpful to downgrade usplash and let you know where I stop seeing it?
[17:11] <Keybuk> (pid exits, parent is 1, etc.)
[17:11] <cjwatson> this *might* be fixed by the --pidfile thing I'm working on
[17:11] <Keybuk> cjwatson: indeed
[17:11] <cjwatson> haven't had an opportunity to reboot since I put that together
[17:11] <cjwatson> should I make usplash remove the pidfile if it exits too?
[17:11] <cjwatson> with the caveat that it might not get the chance to do so
[17:11] <cjwatson> I can't remember if that's standard practice; I thought not, though
[17:12] <Keybuk> I guess
[17:13] <jdstrand> cjwatson, Keybuk: do you guys need more debugging on this machine in the current state?
[17:13] <cjwatson> start-stop-daemon never removed it
[17:13] <Keybuk> upstart-wise I understand the problem
[17:14] <Keybuk> cjwatson: leaving an invalid pid file is bad though in this case
[17:14] <Keybuk> e.g. what if the pid is 1 ? :)
[17:14] <Keybuk> you'll always get an indefinite hang
[17:14] <cjwatson> we can't guarantee to always remove it
[17:15] <cjwatson> so I think we need to ensure that the initial pid is sane (not 1!), but otherwise rely on upstart to notice if the pid has vanished
[17:15] <cjwatson> this fails if pids manage to wrap round in the initramfs, I agree
[17:15] <cjwatson> but that seems like a problem sufficiently unlikely that we can live with it until upstart is managing the initramfs too? :)
[17:16] <slangasek> aww, but I wanted to run usplash+upstart on my 8-bit processor
[17:17] <jdstrand> cjwatson: is there any more I can do to help atm?
[17:17] <cjwatson> jdstrand: not for me, Keybuk might have something else
[17:20] <jdstrand> have you filed a bug yet? if not, I weill
[17:20] <jdstrand> will
[17:21] <fale> hi
[17:22] <cjwatson> I have not
[17:26] <mdz> slangasek, are there logs available for the UEC image build process?
[17:26] <mdz> slangasek, I asked recently if it used gzip --rsyncable, and was told yes, but experimentally I'm not seeing it rsync properly
[17:27] <LaserJock> when is the deadline for Beta .iso testing?
[17:27] <jdstrand> cjwatson: fyi-- bug #440071
[17:28] <jdstrand> cjwatson: I nominated for release and added the regression-potential tag, but otherwise did no triaging
[17:28] <slangasek> mdz: logs don't offer detail on gzip invocation, only on the vmbuilder run itself
[17:28] <slangasek> mdz: confirmed in the source that it's calling --rsyncable, though
[17:29] <jdstrand> cjwatson, Keybuk: I killed of the initctl process which allowed gdm to start. please feel free to ping me if you need anything else
[17:29] <jdstrand> killed *off*
[17:31] <cjwatson> jdstrand: it's unequivocally not a gdm bug
[17:31] <cjwatson> jdstrand: it has a usplash component, and an upstart component
[17:31] <jdstrand> yeah, I realized that after I filed it
[17:31] <cjwatson> I don't have a functional browser right now since I'm testing the usplash part of the fix
[17:31] <jdstrand> I'll adjust
[17:32] <Keybuk> cjwatson: I don't think it's strictly an upstart bug
[17:32] <Keybuk> because it's just doing what it's told
[17:33] <Keybuk> that's always the dangerous thing about a "pretend you know about $PID" hack
[17:33] <Keybuk> if you get $PID wrong, you're inherently violating assertions that upstart makes true
[17:33] <Keybuk> but as you say, this is probably trivially fixed ;)
[17:33] <cjwatson> sure, but do you agree with me that there's no way for a process starting in the initramfs to be certain about removing the pidfile if it crashes?
[17:33] <cjwatson> I mean, it can do its best
[17:33] <Keybuk> I do
[17:33] <Keybuk> but there's no fix for that
[17:34] <Keybuk> if that happens, you're screwed
[17:35] <cjwatson> if the pid just plain doesn't exist when upstart tries to import that pidfile, there is no sense in it waiting for SIGCHLD for it, is there?
[17:35] <cjwatson> I agree and understand that there are corner cases
[17:35] <jdstrand> well, changed to have upstart and usplash. usplash marked as Triaged. upstart untriaged (I'll let you decide). I have not milestoned it
[17:35] <cjwatson> but I don't see how they're worse
[17:37] <cjwatson> I don't suppose I'm saying that it's an upstart *bug* as such, but in the sense of a Launchpad bug task, i.e. a to-do item to add a sanity check, I don't think it's too unreasonable?
[17:41] <cjwatson> Keybuk: of course, now I look at it, our previous conjecture about usplash_write QUIT was entirely bogus
[17:42] <cjwatson> Keybuk: if no process has a FIFO open for writing, then open() returns ENXIO
[17:42] <cjwatson> and usplash_write just exits zero
[17:44] <jcastro> Lots of slots left, get em while they're hot! https://wiki.ubuntu.com/UbuntuOpenWeek/Prep
[17:45] <jcastro> Missing lots of foundations talks (hint hint!)
[17:46] <slangasek> "how to write an upstart job that will hang on reboot"
[17:46] <slangasek> :-)
[17:56] <kirkland> mdz: yes, please do push your upstart fixes
[17:58] <mdz> kirkland, just to be clear, I don't think they fix anything (the behavior should not change), but they're more correct based on what I learned
[17:59] <kirkland> mdz: right, it's good to have those, as it slightly increases the probability that Keybuk might help us debug future issues with them ;-)
[18:03] <mdz> kirkland, done
[18:04] <kirkland> mdz: thanks
[18:14] <kees> Riddell: so, uhm, koffice 1.x is unsupported by KDE now.  Was there some kind of plan to move to koffice2?
[18:16] <Keybuk> slangasek: the point is that it isn't an upstart job
[18:17] <Keybuk> it's pretending that something an initramfs script was *really* an upstart job all along
[18:17] <Keybuk> despite upstart having nothing to do with it
[18:17] <slangasek> Keybuk: sorry, I'm talking about a *different* way to hang on reboot
[18:17] <Keybuk> lying, in this case, results in a severe penalty card
[18:17] <Keybuk> oh :p
[18:46]  * cjwatson remembers that _exit is kind of a good idea in processes involving atexit
[18:53]  * LaserJock gives davmor2 a hug
[19:02] <davmor2> LaserJock: you need to look at postgresql backend to moodle and ltsp
[19:03] <davmor2> LaserJock: out of interest why is there only ubuntu-desktop and edubuntu-server as default seeds on the dvd for debian-installer?  It means you don't get the edubuntu desktop on the installed system, which seems counter intuitive some how
[19:10] <cjwatson> davmor2: that's a bug which I fixed in debian-cd not long ago
[19:10] <cjwatson> davmor2: debian-cd was preseeding edubuntu-desktop-addon, but the task name changed to edubuntu-desktop-gnome
[19:10] <cjwatson> and we hadn't kept track
[19:11] <davmor2> ah
[19:12] <mdz> slangasek, thanks for checking re: vmbuilder and --rsyncable
[19:13] <slangasek> mdz: sure
[19:22] <kees> jcastro: hey, sign me up for a "writing secure code" session, if you've still got room. 1900 or later is best.
[19:27] <jcastro> kees: awesome, on it
[19:28] <kees> cool
[19:31] <didrocks> MacSlow: Can you pease try my patched anjuta available in my ppa? (https://launchpad.net/~didrocks/+archive/ppa). I think the crash is specific to amd64.
[20:02] <Lazy> hi, is my bug report in wrong category? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/437087
[20:02] <Lazy> If the beta is released today there might be lots of people who can't upgrade if this is a common case
[20:29] <Riddell> kees: who says it's unsupported?  we're sticking with KOffice 1 reluctantly because they want us not to switch to KOffice 2 yet
[20:30] <kees> Riddell: KDE emailed ubuntu security and said it's unsupported.  :(
[20:31] <Riddell> kees: who from KDE?
[20:32] <kees> Riddell: David Faure
[20:32] <Riddell> kees: and what's the issue you were asking him?
[20:35] <kees> Riddell: we had asked koffice about xpdf issues in koffice 1.x.  they just got back to us today with "koffice 1.x is unsupported, and xpdf isn't used in koffice 2.x"
[20:36] <Riddell> ooh!
[20:38] <slangasek> superm1: please go live with http://mythbuntu.org/9.10/beta
[21:01] <pitti> ogasawara: I see a lot of reports that people in karmic have problems with CDs/DVDs (lots of I/O errors in dmesg, like bug 435237 or bug 438065; did you see other reports about that? is there a master bug?
[21:01] <pitti> slangasek: wohoooo! congratulations!
[21:02] <MacSlow> didrocks, just downloaded them...
[21:02] <pitti> ogra: I also saw "[sr0] unaligned transfer" a lot
[21:04] <robbiew> slangasek: nice job on Beta...as usual ;)
[21:05] <superm1> slangasek, it's available now
[21:06] <MacSlow> didrocks, still segfaults here -> http://paste.ubuntu.com/283271
[21:14] <didrocks> MacSlow: ok thanks, i'm still working with upstream on this
[21:15] <didrocks> MacSlow: I'll try to grab a new amd64 machine to confirm that the issue is architecture related
[21:15] <MacSlow> didrocks, great... thanks for the effort!
[21:15] <MacSlow> didrocks, I'm still fine with the older anjuta for the time being.
[21:16] <didrocks> MacSlow: yep, but I'll prefer to fix this the sooner, the better :)
[21:16] <MacSlow> didrocks, of course
[21:17] <seb128> the queued uploads are still hold for a reason?
[21:18] <seb128> oh, I guess it's in the topic
[21:18] <seb128> annoying I wanted to make sure nothing was too broken when everything is built
[21:19] <ogasawara> pitti: we're tracking a similar bug where blank cd's were failing to be recognized and indeed has I/O errors in the logs, but we do not have one master bug
[21:20] <pitti> ogasawara: ok, these reports are all for data CDs (not blank)
[21:20] <ogasawara> pitti: I'd would like to look into bug 438065 more since it noted it's not an issue with 2.6.32-rc1
[21:20] <pitti> ogasawara: also, dtchen reported that he could reproduce, and it was fixed in 2.6.32rc1, so perhaps there's a patch we should cherrypick
[21:21] <pitti> heh, right :)
[21:21] <pitti> ogasawara: thank you
[21:21] <ogasawara> pitti: I'll make sure it gets on our list of bugs to track
[21:25] <rrva> hi.. trying to figure out how to solve http://bugs.launchpad.net/bugs/438962 blocks me from booting
[21:28] <seb128> is there any estimation for when uploads will be accepted?
[21:28] <seb128> ie is that worth hanging around waiting for that or that's not going to be tonight?
[21:28] <slangasek> seb128: not tonight
[21:28]  * seb128 is not there tomorrow and would like to flush all the things he has pending today
[21:28] <seb128> :-(
[21:29] <slangasek> that doesn't mean you can't upload, though?
[21:29] <seb128> there is quite some syncs I want to do
[21:29] <seb128> and I want to be around in case there is an issue
[21:29] <slangasek> ah
[21:29] <seb128> I guess I will have to work tomorrow
[21:29] <seb128> *shrug*
[21:30] <seb128> thanks anyway
[21:30] <pitti> seb128: just mail me a list of syncs, I'll do them for you
[21:30] <seb128> pitti, no, I want to be around and not sync a new gtk on friday before everybody goes away
[21:30] <pitti> heh
[21:30] <seb128> but thanks
[21:30] <pitti> oh, we can sync gtk now? nice
[21:30] <seb128> yes ;-)
[21:31] <seb128> I guess there is no way to just tell the armel builders to not build?
[21:31] <seb128> so people could get work done on other arches ;-)
[21:35] <cjwatson> seb128: actually, I was thinking that myself - we have them on manual anyway
[21:36] <cjwatson> slangasek: any reason you can think of why we shouldn't just flush the queue and just gradually filter stuff through on armel?
[21:37] <cjwatson> I can force the ordering by way of scores
[21:42] <Nivex> I'm trying to do an iSCSI install of Karmic Server Beta in a VM.  The VM has no hard disks defined.  I am not being prompted for iSCSI targets as the tech overview says I should be.  I don't even know where to begin so I can file a useful bug report.
[21:44] <rrva> how can i roll back upstart to sysvinit ?
[21:53] <LaserJock> how is the d-i tasksel task list populated? is it based on the packages on the disk?
[22:11] <mdke> slangasek: will do, thanks very much
[22:15] <mdke> slangasek: shall I upload? I guess it can sit in the queue happily until after beta?
[22:17] <sbasuita> It seems there is a problem with the beta torrents: "ubuntu.com: Error: Requested download is not authorized for use with this tracker." (from deluge on the amd64 desktop). I saw a forum post with the same issue on the i386 one as well. Is this known?
[22:58] <cjwatson> rrva: you can't, not in karmic
[22:58] <cjwatson> LaserJock: yes, Task-Key fields
[23:06] <mdke> slangasek: got the answer from the topic, uploaded. Congrats on the beta and thanks again
[23:10] <TheMuso> killall speech-d
[23:10] <TheMuso> woops
[23:14] <Darxus> There's no chance of a new major revision of hugin making it into karmic at this point, without a security fix, right?
[23:15] <Darxus> Somebody is trying to get me to test his package because he thinks he can get it in karmic.
[23:16] <cjwatson> Darxus: depends, https://wiki.ubuntu.com/FreezeExceptionProcess
[23:16] <cjwatson> and https://wiki.ubuntu.com/FeatureFreeze
[23:22] <Darxus> cjwatson: Thanks.  This doesn't seem to meet the requirements during Beta Freeze.
[23:22] <Darxus> As much as it sucks for this package to be so far behind in karmic.
[23:23] <cjwatson> we are not in beta freeze
[23:23] <cjwatson> beta freeze is the period between a week before beta release and the beta release
[23:23] <cjwatson> after the beta release (which just happened) we return to feature freeze
[23:23] <cjwatson> the purpose of beta freeze is to stabilise things so that we can get the beta out
[23:24] <Darxus> cjwatson: What?  The karmic release schedule says beta freeze started on september 24th?
[23:25] <cjwatson> Darxus: yes, and it ends when the beta releases, which just happened
[23:25] <Darxus> Oh.  I didn't realize... I object to things being allowed in more permissibly after the beta release :P
[23:25] <Darxus> Thanks.
[23:25] <cjwatson> Darxus: if you follow the link to BetaFreeze from the schedule, you will see this described
[23:26] <Darxus> Thanks.
[23:27] <Darxus> Oh, that's what FFE stands for :P
[23:28] <Darxus> I still don't think testing by just me and the packager would be sufficient?
[23:29] <cjwatson> dunno, certainly not going to look at this time of night :)
[23:29] <Darxus> Heh.
[23:29] <cjwatson> it's less testing and more the quantity and type of changes
[23:29] <cjwatson> though obviously testing is important
[23:35] <Darxus> Well, it's a major revision of hugin, so I expect the changes to be substantial.
[23:38] <sharms> pitti: did you get my message about usblp
[23:40] <sharms> pitti: by disabling usblp by default people using the usb-parallel adapters for a variety of tasks will no longer be able to use them, is there is work around, and if not how do I get that added to the release notes?
[23:45] <sharms> or anyone for that matter, since blacklist usblp is in /etc/modprobe.d/blacklist-cups.conf, these adapters will stop working unless they all get userspace drivers for them right