[00:06] <mathiaz> mdz: hm..well - purging the eucalyptus* packages doesn't work
[00:07] <mathiaz> mdz: it gets stuck on Removing eucalyptus-common
[00:07] <mathiaz> mdz: processes look like this: http://paste.ubuntu.com/281724/
[00:08] <mathiaz> mdz: http://paste.ubuntu.com/281725/ <- better
[00:11] <mathiaz> mdz: hm - it worked - after 10 mn
[00:19] <slangasek> kirkland, mathiaz: updated server ISO posted
[00:22] <mathiaz> mdz: hm - on package reinstalltion everything works as expected
[00:22] <mathiaz> mdz: clusters, sd and walruses are all registered and correctly listed
[00:39] <kirkland> slangasek: thanks, i'm grabbing
[01:41] <TheMuso> Does anybody happen to know of any particular cdimage mirror/machine that is not loaded with downloads? i.e is there a machine I could use to sync images a little quicker?
[01:41] <slangasek> blink, is cdimage being flooded already?
[01:43] <TheMuso> Well it feels slower for me compared to even a week ago.
[01:43] <TheMuso> And this is after syncing once every day or two.
[01:46] <kirkland> nurmi: ping, when you come back around
[01:46] <kirkland> nurmi: i think i found a problem with node registration
[01:46] <kirkland> nurmi: i want to sanity check this patch
[02:40] <mathiaz> kirkland: did you file a bug for booting from a degraded raid1 array not working in karmic?
[02:40] <kirkland> mathiaz: Bug 427048
[02:41] <mathiaz> kirkland: ok
[02:41] <mathiaz> kirkland: and how do I boot the system once I'm in the initramfs shell?
[02:42] <kirkland> mathiaz: boot from the first disk
[02:42] <kirkland> mathiaz: that should work
[02:42] <mathiaz> kirkland: yes - it works - it drops to a initramfs shell since one of the disk is missing
[02:46] <kirkland> mathiaz: you should get a prompt asking you if you want to boot from the degraded raid
[02:46] <mathiaz> kirkland: I may have missed that prompt (which times out IIRC)
[02:47] <mathiaz> kirkland: booting with bootdegraded=true on the kernel command line still fails though
[02:48] <mathiaz> kirkland: http://people.canonical.com/~mathiaz/degraded_raid1.png
[02:49] <kirkland> mathiaz: that sucks
[03:57] <kirkland> anyone else here besides keybuk can help debug a hard upstart problem?
[04:04] <slangasek> kirkland: one other than the one I already worked on and declared it to be an upstart bug? :)
[04:04] <kirkland> slangasek: nope, same one
[05:57] <TheMuso> c
[06:57] <pitti> Good morning
[06:58] <al-maisan> Good morning
[06:59] <pitti> slangasek: art-pkg is a member of ubuntu-desktop, which is a member of ubuntu-core-dev, so yes; these branches are meant to match the archive; kwwii tends to not use UNRELEASED, so it might be that the branch is ahead
[06:59] <slangasek> pitti: okie-day
[07:08] <dholbach> good morning
[07:09] <mdke> morning
[07:13] <nixternal> good morning dholbach
[07:14] <dholbach> hey mdke, hey nixternal!
[07:16] <mdke> :)
[07:42] <YokoZar> I'm trying to trace a nautilus crash but I keep getting (no debugging symbols found)...done.  even though I have nautilus-dbg installed
[07:43] <mdke> pitti: how does UNRELEASED work?
[07:44] <mdke> perhaps we should use that in the ubuntu-docs branches
[07:52] <pitti> mdke: when you do changes to a package, you always keep the target as "UNRELEASED" (not karmic); this shows everyone looking at the branch that the next change will be documented in the same changelog record, and that the package needs uploading
[07:52] <pitti> mdke: when you upload, you do "dch -r" (changes UNRELEASED to "karmic"), and "debcommit -r" (commits that change and tags it with the version number)
[07:53] <pitti> mdke: so when you see a branch with "karmic", you know it's uploaded and you need to start a new changelog entry
[07:53]  * pitti pats "DEBCHANGE_RELEASE_HEURISTIC=changelog" in ~/.descripts
[07:53] <pitti> ^ this causes "dch" to automatically start a new entry if the target is not UNRELEASED
[07:55] <YokoZar> pitti: relatedly, dch --create will also use UNRELEASED
[07:56]  * hyperair uses C-c C-v in emacs
[07:56] <hyperair> no more debchange for me. heheh
[07:59] <mdke> pitti: ah, that's very useful to know, thanks
[08:00] <pitti> hyperair: that opens a new buffer with debian/changelog, and calls dch?
[08:00] <hyperair> pitti: no it doesn't. it just adds a new changelog entry on top
[08:00] <pitti> ah
[08:00] <hyperair> if there was anything i used dch for, it was for automatically generating -- line
[08:01] <hyperair> the one with the timestamp
[08:01] <hyperair> but that was when i used vim
[08:19]  * pitti starts the karmic upgrade of his wife's computer and gets the asbestos pants
[08:20] <StevenK> pitti: With, or without permission? :-P
[08:20] <pitti> with :)
[08:20] <pitti> but if it breaks, I still have to fix it, of course
[08:22] <mvo> wehhh
[08:23] <mvo> good luck!
[08:23] <pitti> mvo: if update-manager breaks, I'll blame you :)
[08:23]  * mvo hiddes
[08:23] <mvo> pitti: the desktop upgrade tests look good but I did not test as much this time :/
[08:24] <mvo> (as in previous cycles)
[08:36] <robert_ancell_> Can someone explain this to me, if I look on http://git.gnome.org/cgit/gdm/log/daemon/gdm-display.c at the last change it shows modifications to gdm_display_real_get_timed_login_details() but if I look at the master version the changes arent there (http://git.gnome.org/cgit/gdm/tree/daemon/gdm-display.c). ???
[08:48] <alexmurray> @robert_ancell: works for me - the change removed the FIXME comment and the comment isn't there from what I can see in the second link you posted
[08:49] <robert_ancell> alexmurray, what about the branch "if (usernamep != NULL && *usernamep != NULL) {"
[08:50] <alexmurray> I can't see that in the diff for the commit..
[08:51] <alexmurray> thats in gdm-slave.c
[08:51] <robert_ancell> alexmurray, ah, thanks.  I knew I was going mad :)
[09:35] <dholbach> cjwatson, james_w: just FYI: ubuntu-reviews@ was created
[09:35] <dholbach> I don't know how we could route merge proposals and stuff that way
[09:37] <YokoZar> If I'm splitting a package should I wait for the child to be out of the new queue before uploading the parent version that depends on it?
[09:38] <MacSlow> didrocks, ping
[09:40] <slytherin> YokoZar: yes
[09:43] <didrocks> MacSlow: pong
[09:43] <MacSlow> didrocks, greetings
[09:44] <slytherin> if I have uploaded a bug fix revision for a package which is waiting in 'unapproved' queue, when is it like to get approved? after beta?
[09:44] <MacSlow> didrocks, do you have any idea how to work-around https://bugs.edge.launchpad.net/ubuntu/+source/anjuta/+bug/438792 until there's proper fix? (trying to downgrade anjuta atm)
[09:45] <slytherin> tseliot: Are you handling -ati driver packages currently?
[09:46] <tseliot> slytherin: yes, I am
[09:46] <didrocks> MacSlow: yeah, seb128 ping me about this one. It was working when testing it in an unclean box. So, I'm preparing a new version just now, but I don't have a box to test before tonight
[09:47] <slytherin> tseliot: is the problem described in the bug likely to be caused by bad driver - bug 422807
[09:47] <tseliot> let me check
[09:47] <MacSlow> didrocks, ah cool that you're on it already. For the time being I'll stick to the downgraded version (hope that works out as planned). Thanks!
[09:48] <didrocks> MacSlow: can you tell me about the downgrade result? I guess libgdl is maybe guilty
[09:49] <tseliot> slytherin: are you using Karmic? What card are you using?
[09:50] <slytherin> tseliot: Yes I am using karmic. The card is Radeon 7000. The reason I suspect it is driver problem is because I get garbled display in notify-osd notifications as well.
[09:50] <MacSlow> didrocks, seems to have worked... sofar. No segfault for using anjuta_2%3a2.27.5.0-0ubuntu2_amd64.deb and anjuta-common_2%3a2.27.5.0-0ubuntu2_all.deb
[09:51] <tseliot> slytherin: I think I have a bug report about radeon 7000 and notify already
[09:51] <slytherin> tseliot: can you please tell me bug number when you find it? I will see if I can add more info to it.
[09:51] <tseliot> slytherin: I'll put the final release of mesa in a PPA. That might help
[09:52] <didrocks> MacSlow: thanks for the feedback
[09:52] <slytherin> tseliot: That will be great. I can test it anytime this week.
[09:53]  * tseliot looks for the bug report
[09:58] <tseliot> slytherin: bug #429295
[09:59] <mvo> Riddell: do you have a opinion what to do in app-install-data with applications available for both kde3 and kde4 - should we just display both (that is what is done now) or should there be some cleanup for karmic-final?
[10:00] <slytherin> tseliot: Right. Same behaviour on my PC.
[10:01] <tseliot> slytherin: it looks similar to bug #416001
[10:01] <tseliot> even though the corruption is orange in the 2nd case
[10:02] <tseliot> (it might depend on the background colour)
[10:02] <slytherin> I don'r remember what is colour of the corruption in my case. But the behaviour is same for notify-osd.
[10:12] <tseliot> ok
[10:21]  * hyperair stabs nm-connection-editor
[10:22] <hyperair> accept my settings already damnit!
[10:22] <hyperair> what the hell's wrong with this thing?!
[10:28] <Riddell> mvo: got examples of kde 3 and 4 apps? there shouldn't be too many
[10:30] <mvo> Riddell: kspread , kxsldbg, koffice, klinkstatus, mailody, kimagemaeditor, klpato - that seems to be aobut it
[10:35] <cjwatson> pitti: did you upgrade lp:~ubuntu-core-dev/usplash/ubuntu?
[10:36] <cjwatson> as in bzr upgrade
[10:36] <pitti> cjwatson: yes, I did; did it break?
[10:36] <pitti> (it still has the backup)
[10:36] <pitti> bzr complained that it couldn't push there
[10:36]  * pitti recently upgraded his local branches to 2a
[10:37] <cjwatson> that's ok, I just wanted to know. bzr gets upset about mixed 2a and non-2a branches so it just means I have to upgrade too
[10:37] <cjwatson> (I have a local non-2a repository in the directory above my usplash checkout, which I'm upgrading now)
[10:37] <cjwatson> better now
[10:38] <tkamppeter> pitti, hi
[10:38] <pitti> hey tkamppeter
[10:38] <pitti> tkamppeter: FYI, I fixed the raw printer usb device permissions in udev trunk, so that lsusb will work again
[10:38] <cjwatson> I'm thinking that usplash really needs options to daemonise itself and write a pidfile
[10:38] <cjwatson> this business with backgrounding usplash in the initramfs script is racy
[10:39] <tkamppeter> pitti, I have patched the CUPS usb backend to support both usblp and libusb, including tolerating the URIs of method B when printing via method A.
[10:40] <mvo> pitti: how is the release upgrade going?
[10:48] <tkamppeter> pitti, what change did you exactly do on the usb device permissions? Simply made them world-readable?
[10:50] <tkamppeter> pitti, here is the patch: http://pastebin.ubuntu.com/282020/
[10:50] <tkamppeter> pitti, it has the following functionality:
[10:52] <tkamppeter> pitti: It uses both libusb and usblp for discovery, I have done some fixes that at least the make/model part of the URIs is the same, extra info in the libusb URIs which can only be obtained via libusb I leave in the URIs.
[10:53] <tkamppeter> pitti: For printing at first usblp is tried and if the device is not found libusb. If the device is not found there, too, the procedure is repeated after 5 seconds.
[10:55] <tkamppeter> When printing the device is identified by matching the queue's URI with the discobvered URIs. I have modified this matching that libusb-generated URIs can be matched against usblp-generated ones and vice versa.
[10:57] <tkamppeter> pitti: This allows loading and unloading the usblp kernel module between queue setup and printing or between print jobs in general. It also should make queue set up with Jaunty work under Karmic's CUPS, both with blacklisted usblp or usblp being loaded normally.
[11:01] <slytherin> are we still processing package removals in sync with Debian?
[11:02] <cjwatson> not in general, request ones you need
[11:02] <cjwatson> continuing to process package removals after ceasing to process automatic syncs is a recipe for stuff going wrong :)
[11:04] <slytherin> cjwatson: Ok. I want vecmath1.2 to be removed, but before that cdk needs to be synced. There is already a sync bug for cdk, no bug for vecmath1.2 removal.
[11:04] <pitti> mvo: just finished, mostly ok; I have a short list of issues
[11:05] <slytherin> cjwatson: The bug for cdk sync is bug #438525.
[11:05] <cjwatson> slytherin: um, sorry, request -> in a bug report please - we won't be doing much extraneous archive admin until after beta
[11:05] <slytherin> cjwatson: Ok. I will file bug for vecmath1.2 removal after cdk is synced.
[11:05] <cjwatson> and I certainly won't in general process archive admin requests on IRC since that gets us into a world of pain :)
[11:05] <pitti> cjwatson: on jaunty->karmic ugprade is it expected to stay with grub 1?
[11:05] <cjwatson> yes
[11:06] <sladen> cjwatson: FWIW, I haven't seen usplash during boot for a couple of weeks
[11:06] <sladen> cjwatson: should it still be there (instead of the scrolling text)
[11:06] <cjwatson> sladen: correct
[11:06] <cjwatson> it was intentionally turned off; the intention is to get X up fast enough that we don't need it
[11:07] <cjwatson> usplash actually slows that down
[11:07] <cjwatson> so we use usplash only when it's needed (e.g. interaction like cryptsetup, known slow boot scenarios, etc.)
[11:07] <pitti> mvo: biggest problem is that the cleanup stage removes all the language-support stuff (gimp and OO.o help and translations, etc.)
[11:07] <pitti> mvo: we dropped language-support-translations-* in favor of a language-selector approach
[11:07] <cjwatson> if you want it on your system, put USPLASH=y in /etc/initramfs-tools/initramfs.conf
[11:07] <pitti> but the upgrade removes all of them
[11:11] <sladen> cjwatson: I try to stick with the defaults, however four variants text scroll (font change, mode change, font change (again)) does look crap (total of 30.0 seconds spent in text mode)
[11:11] <cjwatson> you're aware that you're looking at a work in progress
[11:12] <sladen> cjwatson: I'd prefer a timer, and then fire up usplash after ~3 seconds.  A netbook will have got past that stage by then, hopefully
[11:12] <cjwatson> talk to Keybuk
[11:12] <cjwatson> (when he's around)
[11:13] <slytherin> sladen: look at the positive side. You get to see error messages at boot time (if any) that you won't see otherwise unless you checked dmesg log. :-)
[11:13] <ogra> sladen, echo "USPLASH=y" | sudo tee -a /etc/initramfs-tools/conf.d/mysplash && sudo update-initramfs -u
[11:14] <cjwatson> any display of messages on the console by default before X starts is a bug, and I'd hope we can fix all that for final
[11:14] <ogra> heh, you havent seen imx51 :P
[11:14] <cjwatson> for x86 anyway
[11:14] <ogra> but i hope that too
[11:14] <ryanakca> cjwatson: /query ?
[11:14] <cjwatson> ryanakca: if you want to /query me, just do so, don't ask
[11:15] <ogra> cjwatson, what will be done about fsck then ?
[11:15] <cjwatson> ogra: I *think* that if fsck needs to do anything non-trivial then we need to start up usplash for it
[11:15] <cjwatson> but Keybuk may have other thoughts
[11:16] <StevenK> As well as prompting for things like mount passphrases?
[11:16] <cjwatson> I believe that's already done
[11:16] <cjwatson> if you use cryptsetup then that's supposed to cause the USPLASH option to be turned on when generating the initramfs
[11:16] <pitti> tkamppeter: dev permissions> yes, 0664 now
[11:16] <cjwatson> well, at least for /, it may not be hooked up for other things yet
[11:18] <pitti> tkamppeter: nice! great work
[11:18] <tkamppeter> pitti, I am going to upload it to BZR.
[11:18] <pitti> tkamppeter: did you already propose that to Mike? it seems to be much better than having to decide at compile tie
[11:18] <pitti> tkamppeter: then we'll drop the blacklisting again, right?
[11:18] <tkamppeter> pitti, not yet.
[11:19] <tkamppeter> pitti, I have prepared the commit, I will commit now, then you can drop the blacklisting.
[11:19] <ogra> hrm
[11:20] <tkamppeter> pitti, committed.
[11:59] <ogra> mat_t, the xsplash image is loaded dynamically and based on the name, right ? i'll do some tests if other formats change anything wrt "tree rings" once i'm done with my beta install tests
[12:02] <mvo> pitti: language-support> hm, that stuff is not in the "translations" section? stuff from that section is not removed (or should not get removed)
[12:03] <mvo> pitti: I'm curious about the other issues too
[12:03] <mat_t> ogra: great, thanks!
[12:03] <pitti> mvo: no, it's in doc (gimp-help-de, openoffice.org-help-de) or editors (openoffice.org-l10n-de) or whatnot
[12:04] <mat_t> ogra: not sure how it's loaded, probably best to ask bratsche
[12:04] <pitti> mvo: there are some difficulties with fvwm and xsplash (not upgrade specific, and not supported)
[12:04] <ogra> mat_t, though i doubt i can easily change jpeg to svg
[12:04] <pitti> mvo: the other main issue was that DNS hangs/times out for 10 seconds
[12:04] <pitti> I first got that in karmic some months ago
[12:04] <ogra> but i'll try png and whatever else comes to my mind
[12:04] <pitti> it doesn't happen with jaunty, does happen with karmic, on the same router/ethernet
[12:04] <mat_t> ogra: you could just create a simple svg with a gradient I guess
[12:04] <pitti> but nobody else seems to have this problem
[12:05] <pitti> I already played around with nssswitch, no change (to rule out avahi stuff)
[12:05] <ogra> mat_t, oh, indeed, i thought you wanted me to use the jpeg as base
[12:05] <mat_t> ogra: I can create one if that would help
[12:05] <ogra> nah, i know my way around inkscape :)
[12:05] <mat_t> :)
[12:05] <mvo> pitti: hm, I look into the translation stuff today and add some transition code
[12:05] <pitti> mvo: so for upgrade specific stuff, the translation stuff was the main issue
[12:06] <pitti> mvo: ArneGoetje wrote a script to display missing packages for a language; perhaps this can be modified also to show required packages (even if they are still installed)
[12:06] <pitti> without language-selector code it's not really easy to tell which are translation related
[12:07] <mvo> pitti: yeah, I think it needs to include some code from the karmic l-s to ensure that it does the right thing
[12:07] <pitti> mvo: the script is in the l-s tree now, but I guess it needs some tweaks to be useful for this case
[12:07] <pitti> mvo: I'll file a bug to track and discuss this
[12:07] <mvo> pitti: thanks
[12:09] <pitti> mvo: the other option would be to collect the l-s-translations-* dependencies beforehand and substract them from the cleanup list?
[12:09] <pitti> well, I'll elaborate in the bug
[12:12] <mvo> pitti: that would work as well
[12:15] <pitti> done in bug 439296
[12:35] <pitti> tkamppeter: thanks; I removed the blacklisting (also on upgrade) and fixed the changelog; building now, will upload to sid later
[12:41] <joaopinto> sox is not installable, because libgsm1 is not available, is this a temporary building problem or should I file a bug report ?
[12:43] <joaopinto> hum, sox is in universe, better ask on motu :P
[12:48] <tkamppeter> pitti, thanks. Now the only thing is that USB printing will more or less continue the old way: A printer is plugged and usblp automatically loaded. Then all printing goes automatically through usblp. This way all legacy add-ons (foo2zjs firmware load, escputil without print queue, libinklevel, ...) and also several manufacturer backends will continue working, but on the other side printers will not get accessed in libusb mode making us
[12:48] <tkamppeter> e of the advantages of libusb-based access.
[12:51] <tkamppeter> pitti, at least a program can detach a printer from the kernel module now (like HPLIP) and a queue based on the usb CUPS backend stays working.
[13:06] <mdz> kirkland, did your localhost->lan IP change fix the registration issue?
[13:11] <seb128> hum bug #439316
[13:22] <ogra> hmm, if i select an encrypted homedir during install i get usplash ?
[13:23] <ogra> even though it doesnt ask me anything ?
[13:27] <cjwatson> Keybuk: ^- bug 439316 - did I break something when I added that?
[13:27] <cjwatson> that "start: Unknown job: S04kdm" bit is a bit suspicious too, I wonder what's causing that
[13:28] <cjwatson> leftover rc.d symlink to something that's now an upstart job?
[13:28] <didrocks> MacSlow: seb128 confirmed that he doesn't have anjuta crashing either. I pinged upstream about the issue but nobody's present today. I'll still update anjuta to 2.28.0 as the work is done :-)
[13:33] <ogra> mat_t, hmm, opening the existing xsplash wallpaper in gimp pops up a message about an embedded color profile ... could that be our issue ?
[13:34] <mat_t> ogra: I'd be surprised if it was
[13:35] <mat_t> ogra: app that does not deal with profiles would simply disregard it
[13:36] <mat_t> ogra: I can give you a version without the profile if you have time to test it
[13:37] <ScottK> mvo: I didn't see where you got an answer to your kde3/4 question.  My opinion would be show them both.  In all those cases the KDE3 versions are generally preferred because the KDE4 versions have maturity issues, but there will be people who want the KDE4 one anyway.
[13:37] <ogra> i'm done with beta image tests for now, so i have time to look into xsplash
[13:38] <slacker_nl> anyone else having troubles with the keyserver, unable to upload my key, keeps timing out
[13:39] <Keybuk> cjwatson: reading
[13:39] <Keybuk> (sorry, bit lagged, my laptop is a bit screwed so just trying to get set up on another)
[13:39] <Keybuk> on the bright side, this means I'm actually doing CD testing ;)
[13:40] <slacker_nl> lol
[13:40] <Keybuk> cjwatson: what did you change?
[13:40] <mvo> ScottK: ok, thanks. that is fine with me, its a bit ugly in the U Icurrently because the only difference in the description is the package name
[13:40] <pitti> hey Keybuk, welcome back
[13:40] <cjwatson> Keybuk: I upstartified usplash so that we could actually reliably make it go away when gdm starts
[13:41] <Keybuk> cjwatson: oh, I had some packages for that
[13:41] <cjwatson> this included making gdm emit a starting-dm event
[13:41] <Keybuk> why not just use "starting gdm" ?
[13:41] <cjwatson> or starting kdm or ... besides, I couldn't find a way to make that work with "text"
[13:41] <Keybuk> fair point
[13:41] <Keybuk> I'll need to look at what you did
[13:42] <Keybuk> and compare it with what I was doing
[13:42] <cjwatson> the thing that seems to be hanging is the initctl emit, but presumably that blocks until all the stuff hung off that event has finished
[13:42] <Keybuk> exactly
[13:42] <Keybuk> which is what you want
[13:42] <cjwatson> yeah
[13:42] <cjwatson> I don't see anything in the usplash job I added that could block indefinitely
[13:43] <cjwatson> hmm, unless it's the usplash_write
[13:43] <Keybuk> once I'm back up, I'll take a look
[13:43] <cjwatson> that might block if nothing's on the other end of the fifo
[13:43] <Keybuk> did you write the pid of usplash from the initramfs to /dev/.initramfs/usplash.pid ?
[13:43] <cjwatson> yes
[13:43] <Keybuk> neat :p
[13:43] <cjwatson> that's a lovely upstart hack BTW
[13:43] <Keybuk> yes, I thought so
[13:44] <Keybuk> it's great because it means you can put all the "start on" stuff in the actual job
[13:44] <Keybuk> so without-initramfs works too
[13:44] <cjwatson> or, in this case, we can actually stop usplash on "stop"
[13:44] <Keybuk> right
[13:44] <cjwatson> yeah, I didn't do start stuff for this - I probably ought to have done
[13:44] <Keybuk> I did start for the shutdown case
[13:44] <cjwatson> I figured it wasn't the end of the world if without-initramfs didn't have usplash for the moment
[13:44] <cjwatson> oh, I made that a separate job because I found that less confusing
[13:46] <cjwatson> I fully expected you to tear it apart when you got back though :-) My bits do seem to work for a respectable number of people, but there's obviously the odd case where they don't
[13:46] <cjwatson> it may be that the only reliable fix is to fix usplash's main loop so that we can just send it SIGTERM
[13:46] <ogra> mat_t, ok, testing an svg i ran into something intresting ... apparently xsplash is not using the 1024x768 picture on my 1024x768 screen ...
[13:46] <cjwatson> I had to nobble that in a really nasty way for the time being
[13:46] <Keybuk> oh
[13:46] <Keybuk> I didn't commit the SIGTERM patch? :)
[13:47] <cjwatson> not so I noticed; the main loop is still a horrible bodge
[13:47] <cjwatson> needs to be a proper select loop
[13:47] <ogra> mat_t, i see the tree rings on the svg as well though, but that might be caused by scaling the image actually
[13:47] <cjwatson> doing it in the current loop didn't seem possible in a non-racy way
[13:47] <cjwatson> (may actually need to be pselect)
[13:47] <ScottK> mvo: I agree about the ugliness, it's just that the ones that have both KDE3 and KDE4 versions have both for a good reason, so there's no way to really pick which to show.
[13:48] <Keybuk> oh, I didn't bother about that
[13:48] <mvo> ScottK: yeah, its a tiny amount, for the next cycle I think I will try to come up with some generic way to annotate if two names are identical
[13:48] <Keybuk> I just changed "for (;;)" to "while (! exit_loop)"
[13:49] <cjwatson> and if usplash just gets SIGTERM/SIGKILLed without cleaning up properly, then you get stuck at a console with no way to get out
[13:49] <Keybuk> then select() returns -EINTR
[13:49] <Keybuk> and all is fine
[13:49] <cjwatson> at least that's what happened to me
[13:49] <mat_t> ogra: did you create a new svg?
[13:49] <Keybuk> it looks the same as a timeout then
[13:49] <cjwatson> sorry, stuck at the splash screen
[13:49] <mvo> mpt: actually - what do you think about adding the packagename behind the app name if there are multiple apps with the same name (happens e.g. for System Monitor - gnome-system-monitor and ksysguard) and also for kspread (kde3, kde4 version)
[13:49] <ogra> mat_t, yup ...
[13:50] <ogra> and it apparently uses 1280x1024 on a 1024x768 framebuffer
[13:50] <mat_t> ogra: ok, so there's nothing wrong with the image then
[13:50] <mpt> mvo, in brackets, that makes sense
[13:51] <mpt> mvo, e.g. "System Monitor (ksysguard)"
[13:51] <cjwatson> Keybuk: BTW, spotted a fun gotcha while using the initramfs import hack - totally doesn't work if your job doesn't have a main process defined :)
[13:51] <cjwatson> hence my "exec true" hack for the time being
[13:51] <Keybuk> right, indeed it deliberately checks for that ;)
[13:51] <Keybuk> oh
[13:51] <Keybuk> why do you have an "exec true"?
[13:52] <Keybuk> why not just have *usplash* as the main process?
[13:52] <Keybuk> then "status usplash" returns its pid and stuff
[13:52] <cjwatson> that would be more correct, but I was up against beta CD rolling
[13:52] <cjwatson> I think status usplash does work
[13:52]  * Keybuk would have just left usplash off ;)
[13:52] <ogra> mat_t, nope, gdm now uses the bg image too and it displays it just fine during boot ... which for me results in a "tree rings on, rings off, rings on, rings off, yay i see the desktop" effect
[13:52] <cjwatson> I thought about that, but it's damnably ugly on live CDs
[13:53] <Keybuk> working > ugly
[13:53] <cjwatson> and we already force it on for cryptsetup
[13:53] <cjwatson> do we not?
[13:53] <Keybuk> true
[13:53] <cjwatson> so had to make it go away somehow
[13:54] <mpt> mvo, also, danilo just showed me how to generate a .pot file from the help .xml file. When would be a good time to go over that with you?
[13:55] <ubuntu0ath1> What does staging drive mean ? I am talking about the rt2860 module and when will it become normal?
[13:56] <cjwatson> in fact, FWIW, I don't think there's any way that 'exec true' could break 'status usplash', unless upstart is wrong :) by definition, if it's imported a running job from the initramfs, it shouldn't start it again
[13:56] <cjwatson> and certainly it gets stopped correctly, which was what I was mainly concentrating on
[13:57] <cjwatson> well, modulo this weird bug
[13:58] <mvo> mpt: well, it needs to be done in both ways and we clarify if we can ship that via a update, otherwise I think its not that useful
[13:58] <mvo> mpt: re multiple apps with the name name> I have a look at the code to see what can be done
[13:59] <cjwatson> Keybuk: if you have that SIGTERM patch handy, I can probably run with it
[13:59] <cjwatson> though probably leave it the way it is for beta now
[13:59] <Keybuk> if things are working for you, I'd leave it alone
[13:59]  * Keybuk would only break it again
[14:00] <cjwatson> well, we know they aren't working for everyone, and I'm not actually *happy* with the current state
[14:06] <mpt> mvo, ok, I reported bug 439353 with the details
[14:08] <mat_t> ogra: right, not  a great experience then
[14:08] <ogra> yup
[14:08] <ogra> i'm looking at the xsplash code now to find out what kind of rednering it does
[14:08] <mat_t> ogra: cool
[14:09] <mat_t> ogra: keep in touch with Cody, he's assigned to the bug I think atm
[14:09] <ogra> i'll report everything i can figure out there
[14:09] <mat_t> great
[14:11] <pitti> tkamppeter: tested it on my wife's computer, works fine again (was pretty broken before)
[14:23] <mvo> mpt: thanks
[14:27] <tkamppeter> pitti, CUPS usb patch is submitted upstream now: http://www.cups.org/str.php?L3357
[14:27] <pitti> tkamppeter: nice, thanks
[14:39] <mvo> mpt: I commited the multiple apps detection, that should be good enough for karmic, I think we could consider writing a "adopt app-install-data" position for someone (or a team) who has fun going over the apps in app-iinstall-data and checking what is appropriate, what is duplicated, what has a bad description etc
[14:40] <mpt> mvo, I've just been discussing with bigjools and sinzui on the Launchpad team how to make that metadata user-editable
[14:40] <mpt> so that package maintainers can say "ooh, I like that description better" -> ( Merge )
[14:45] <Keybuk> pitti: usplash 40 ... did you upload yet?
[14:47] <pitti> Keybuk: yes, it's in the queue; but we can just upload another one, or I reject that one and we un-tag
[14:48] <Keybuk> pitti: it's ok - have some patches but we can do a .41
[14:48] <pitti> sounds good; I just wanted to fire & forget
[14:48] <pitti> so if it's not for beta, .41 seems easier
[14:50] <cgregan> Anybody out there have a sec to talk about start-up applications and Gnome-do?
[14:53] <Hatl> hi! i updated my kubuntu to 9.10. now i have the following error: http://pastebin.com/m25361f7b any suggestions?
[14:58] <kirkland> mdz: it certainly caused the messages in all 3 of the registration logs to say "SUCCESS: ...successfully registered"
[14:58] <kirkland> ttx: yo
[14:58] <kirkland> ttx: i'm back from running now, syncing the .2 iso's
[14:58] <ttx> kirkland: hey.
[14:58] <kirkland> ttx: can you quickly bring me up to speed?
[14:58] <ttx> the .2 is -0ubuntu12
[14:58] <ttx> the one with the /var/run fix
[14:59] <kirkland> ttx: and dropped the localhost fix?
[14:59] <slytherin> cgregan: gnome-do is in universe repository. #ubuntu-motu is he ideal channel to discuss it.
[14:59] <ttx> We need to revert the chages and upload a 0ubuntu14 that is code-equivalent to 0ubuntu12
[14:59] <ttx> then take our time to understand what went wrong with 0ubuntu13
[14:59] <ttx> except the unlucky number.
[15:00] <ttx> kirkland: its -0ubuntu12. With all its known issues.
[15:00] <ttx> so We document manual registration for beta
[15:00] <cgregan> thanks slytherin
[15:00] <kirkland> ttx: what does manual registration look like?
[15:00] <ttx> kirkland: sorry for the total reversion but given how many people can actually test the whole process we don't have enough time left now
[15:01] <slytherin> Hatl: Bug directx on #ubuntu-motu
[15:01] <ttx> kirkland: http://testcases.qa.ubuntu.com/Install/ServerECluster
[15:01] <ttx> kirkland: yes, I know, it's troubling.
[15:01] <ttx> kirkland: especially since I ran those commands to try to "fix" 0ubuntu13 and it was still failing.
[15:02] <kirkland> ttx: so IPADDRESSOFTHECLUSTER is the real IP, not "localhost" and not "127.0.0.1"
[15:02] <ttx> kirkland: the NC seemed stuck on 127.0.0.1 no matter how much effort I put into it to make him forget it
[15:02] <ttx> yes.
[15:02] <kirkland> ttx: that bothers me
[15:03] <kirkland> ttx: that's precisely the change i made in the code
[15:03] <ttx> kirkland: yes, it's exactly what you do.
[15:03] <kirkland> ttx: which i think is a good, necessary change
[15:03] <ttx> kirkland: I couldn't make it work. It fails to start an instance on the NC
[15:03] <ttx> for some very weird reason, I'm sure
[15:04] <ttx> kirkland: do you have a full UEC setup at your disposal now ?
[15:04] <ttx> kirkland: oe tat you can test the instance run on ?
[15:04] <ttx> s/oe tat/one on which/
[15:04] <kirkland> ttx: i will shortly
[15:05] <kirkland> ttx: i suppose i need the .1 iso?
[15:05] <ttx> kirkland: at this point we need to revert the changes and upload a ubuntu14 so that people that upgrade after beta don't run into 13
[15:05] <ttx> kirkland: 20090930.1 = 13
[15:06] <ttx> kirkland: 20090930.2 = 12
[15:06] <ttx> I really was hoping that 13 would cure it all, it seemed very reasonable and conservative
[15:06] <kirkland> what a mess
[15:07] <ttx> kirkland: I hope its not a glitch in my test env, but since I'm the only one to test it from A to Z, we don't really have a choice
[15:33] <Keybuk> kirkland: I hear you've been casting aspersions on Upstart? :)
[15:35] <ogra> Keybuk, hey ... is there a way i could make a udev rule inject a property into /sys/devices/virtual/net/eth0 ?
[15:35] <Keybuk> ogra: no.
[15:35] <ogra> :(
[15:35] <Keybuk> ogra: actually, what do you mean "inject a property" ?
[15:35] <ogra> bug 438687
[15:35] <Keybuk> if DRIVER is not set, it means that the driver isn't bound to the device
[15:35] <ogra> NM doesnt like our NIC driver because it doesnt expose "DRIVER"
[15:36] <ogra> well, it works fine
[15:36] <ogra> its just NM that doesnt recognize it because of that
[15:36]  * Keybuk thought DRIVER was set by the pci subsystem
[15:36] <ogra> there is no pci subsystem :)
[15:36] <ogra> well, no visible one
[15:36] <Keybuk> oh, fix your stupid architecture then <g>
[15:36] <ogra> pfft
[15:37] <liw> the totem BBC plugin is only useful for people in the UK, right?
[15:37] <ogra> most arm arches dont expose the PCI bus, even if they have one
[15:37] <Keybuk> so fix that
[15:37] <ogra> liw, there are some free stations you cen get in other countries
[15:37] <Keybuk> or fix whatever subsystem you do use
[15:37] <ogra> Keybuk, can i broow your soldering iron ?
[15:38] <Keybuk> if your kernel isn't setting DRIVER, that's a kernel bug
[15:38] <ogra> its not visibly exposed by the HW
[15:38] <Keybuk> so?
[15:38] <Keybuk> visibly exposed doesn't make a difference
[15:38] <Keybuk> DRIVER is set by a subsystem to indicate the subsystem driver being used
[15:38] <ogra> so how should i invent a virtual PCI bus then
[15:38] <Keybuk> you're being deliberately stupid, right?
[15:38] <ogra> well, thats different on a SoC
[15:39] <Keybuk> you still have kernel drivers
[15:39] <Keybuk> and you still have kernel subsystems
[15:39] <ogra> right, but often no subsystems at all ...
[15:39] <Keybuk> you have subsystems
[15:39] <Keybuk> even it
[15:39] <Keybuk> even if the subsystem is "arm"
[15:39] <ogra> the drivers often dont use the subsystems which makes merging the patches so hard
[15:39] <Keybuk> they have to
[15:39] <Keybuk> you can't have a driver outside of a subsystem
[15:40] <ogra> right, might be arm
[15:40] <MacSlow> popey, ping
[15:40] <ogra> or in case of that board mxc
[15:40] <popey> MacSlow: pong
[15:40] <Keybuk> exactly
[15:40] <Keybuk> so fix that subsystem to expose DRIVER
[15:40] <pitti> liw: well, people from other nations might watch it, too; why?
[15:40] <ogra> not the driver itself then ?
[15:40] <pitti> liw: but I guess it's very UK centric indeed
[15:40] <MacSlow> popey, hey Alan... can you revisit https://bugs.edge.launchpad.net/notify-osd/+bug/334863 again... this should not happen anymore.
[15:40] <Keybuk> ogra: no, the way driver core works is that most of this stuff is subsystem owned
[15:41] <popey> MacSlow: sure
[15:41] <ogra> Keybuk, ok
[15:41] <MacSlow> popey, cool thanks
[15:41] <Keybuk> otherwise you'd have to fix every driver
[15:41] <liw> pitti, just curious, #421318
[15:41] <ogra> well, thats what freescale likes to do apparently :)
[15:41] <pitti> liw: oh, is it the bbc plugin which causes the totem crash?
[15:41] <ogra> by working around as many subsystems as they can
[15:42] <liw> pitti, there is crash if bbc is only plugin enabled; disabling it removes crash
[15:42] <pitti> liw: this one is stupidly hard to track down apparently (seb128 and robert_ancell already beat on it for hours)
[15:42] <liw> the proper fix is to stop using threads, but that's a bit of a non-intrusive change
[15:42] <Keybuk> ogra: you're going to find that there are increasingly more things that expect the kernel to work a particular way
[15:42] <ogra> Keybuk, in any case thats amitk country ... i was just looking for a quickfix through faking something via udev
[15:42] <Keybuk> so hacked around or buggy drivers are going to simply not work
[15:43] <seb128> liw, the bbc code didn't change at all since jaunty and that used to not crash
[15:43] <ogra> yes, i know, i use that hardware every day and discover issues every day :)
[15:43] <liw> seb128, that doesn't mean it isn't buggy
[15:43] <seb128> liw, right, it's just weird that it started crashing where it was not beofre
[15:44] <Keybuk> we have a hard enough problem making the things that work right work ;)
[15:44] <liw> seb128, I've become convinced that any Python code that uses threads is inherently buggy; perhaps this just didn't happen to show earlier...
[15:44] <liw> seb128, but it might be something in totem itself that just gets hit by the bbc plugin
[15:44] <ogra> Keybuk, dont tell me ... :)
[15:45] <pitti> seb128, liw: we also have new compiler options in karmic, etc., don't we?
[15:46] <liw> pitti, yes; also, new kernel, and new libc, and ... anything might affect this
[15:46] <liw> hm, epiphany has changed the default home page from what I had configured earlier to http://www.debian.org
[15:47] <seb128> that's probably the switch to epiphany-webkit default
[15:47] <liw> right
[15:47] <liw> (it's still impolite of it)
[15:48] <seb128> yeah, not discussing that there is a bug there
[15:49] <Amaranth> doko__: for bug 300948 isn't the fix to just add compiz to the check? current it checks for metacity or kwin, right?
[15:51] <slytherin> seb128: Hi. totem-plugins-extra depends on a obsolete package (coherence), the package has been renamed to python-coherence. Should I file a bug about this or will you fix it in next upload (whenever it happens).
[15:52] <seb128> slytherin, look if there is a bug open an file one if that's not the case
[15:52] <seb128> it will be easier to track this way
[15:53] <liw> hmm, totem-python-module.c calls PyEval_SaveThread but not PyEval_InitThreads, I wonder if that's a problem
[15:53] <slytherin> seb128: ok
[15:54] <liw> oh, the thread module calls is automatically, never mind
[15:56] <pitti> liw: hang on, is it using gtk with threads?
[15:56] <liw> pitti, totem uses gtk, the bbc plugin uses python threads, at least
[15:56] <pitti> liw: I use threads in apport, and I noticed that Qt spectacularly fails if you have qt code in more than one thread
[15:57] <pitti> I didn't quite get those crashes in apport-gtk, but still gtk is not thread safe
[15:57] <pitti> if it works, it's sheer luck
[15:57] <liw> indeed
[15:57] <pitti> before I actually used two mainloops in two threads
[15:57] <pitti> now I cleaned it up using some IPC to only have one main loop
[15:57] <MacSlow> popey, btw... on which GPU/driver combo is this LP: #334863?
[15:58] <liw> and indeed, the bbc plugin uses _both_ threads and gtk
[15:59] <doko__> Amaranth: yes, somebody has to either dig out the upstream patch, or patch our jdk build
[16:00] <Amaranth> doko__: I don't think I have enough RAM to build openjdk :P
[16:01] <doko__> Amaranth: swap space is cheap ;p
[16:02] <cjwatson> liw: the intention was that the bbc plugin would be useful outside the UK too, although with a restricted range of content
[16:02]  * ogra offers some nbd swapspace to Amaranth 
[16:03] <slytherin> Are alternate CD images for ports architectures likely to be recreated for beta? The images for powerpc and ia64 are oversized.
[16:03] <kirkland> Keybuk: potentially; mathiaz investigated that more deeply while i looked for other solutions
[16:03] <ogra> unlikely unless someone fixes them
[16:03] <kirkland> Keybuk: any chance you can sanity check our eucalyptus upstart configuration?
[16:04] <ogra> someone being community
[16:04] <kirkland> Keybuk: one thing I don't understand is that there are several that we need to run in series, and it seems they're executing in parallel
[16:04] <kirkland> Keybuk: which is causing non-deterministic behavior
[16:05] <cjwatson> slytherin: do they actually build at the moment? I saw some build failures ...
[16:05] <Keybuk> kirkland: if you tell me what packages to look at
[16:05] <liw> hm, I see the same problem with the BBC plugin on jaunty
[16:06] <kirkland> Keybuk: bzr branch lp:~ubuntu-core-dev/eucalyptus/ubuntu
[16:06] <kirkland> Keybuk: they're all in the debian directory
[16:07] <slytherin> cjwatson: they were built last on 29th September which is same as non-ports arch. - http://cdimages.ubuntu.com/ports/daily/current/
[16:09] <cjwatson> slytherin: ok, somebody in the community will have to fix the oversizedness then, as ogra says
[16:09] <cjwatson> (or tell us what to do)
[16:10] <slytherin> cjwatson: Any hints where to look for root cause?
[16:11] <Keybuk> kirkland: wow, messy
[16:11] <Keybuk> I suspect you need "task" in some of them
[16:11] <cjwatson> slytherin: not really, you just have to plug through the package list and work out what's unnecessary
[16:11] <slytherin> hmm
[16:11] <Keybuk> e.g. eucalyptus-cc-publication looks more tasky to me
[16:12] <Keybuk> as does eucalyptus-cc-registration
[16:12] <Keybuk> eucalyptus-cloud is just freaky
[16:12] <Keybuk> no idea why that's done the way it is
[16:12] <Keybuk> not even entirely sure that *works* :p
[16:12] <Keybuk> eucalyptus-sc-registration looks tasky
[16:13] <Keybuk> eucalyptus-walrus-registration looks freaky
[16:13] <Keybuk> as does eucalyptus-walrus
[16:16] <highvoltage> wow.
[16:17] <crescendo> Is there a place I can see the reasons for package inclusion decisions in each release of Ubuntu?  For example, I'd like to see why xchat-gnome was chosen over xchat.
[16:19] <popey> MacSlow: intel
[16:19] <MacSlow> popey, ok
[16:21] <seb128> crescendo, how chosen? it's not installed by default
[16:22] <crescendo> seb128: Err, I suppose that package is a bad example, but xchat-gnome is now the only on in the "supported" repos, but xchat is not.  There are other packages that I'm interested in.
[16:22] <seb128> I don't think there is one summary for those
[16:23] <crescendo> seb128: mainly, to discern the differences between package distributions and come to a decision on which package I should use personally
[16:23] <seb128> it's often mailing list or uds discussions ie blueprints
[16:23] <crescendo> seb128: have a link, or is it non-centralized?
[16:23] <seb128> as said there is not one location for those
[16:23] <seb128> it depends of the software
[16:23] <crescendo> Oi. Who manages the Ubuntu repos?  Maybe I could start there
[16:23] <seb128> it's usually discussed by the group of people concerned
[16:23] <directhex> or irc meeting logs
[16:24] <seb128> ie ubuntu-desktop for desktop choices
[16:24] <slytherin> cjwatson: Is there any way to create a local image so that I can compare it with the official one to check what is causing problem?
[16:24] <cjwatson> slytherin: that's a lot of work and not actually very helpful in this kind of case, IME
[16:24] <seb128> crescendo, the discussions come usually from teams working on those
[16:24] <seb128> ie xchat-gnome is an #ubuntu-desktop topic
[16:25] <seb128> the rational for this one is that it's using GNOME infrastructures, cleaner ui, etc
[16:25] <cjwatson> the ubuntu-archive team manages the Ubuntu repositories, but we don't as a general rule take executive decisions on what to include or what not to include - we're an operational team
[16:25] <slytherin> cjwatson: I wondered why we shipped both 32 bit and 64 bit kernels but that doesn't seem to have caused problem before this.
[16:25] <cjwatson> as seb128 says, executive decisions are up to the teams with most direct knowledge
[16:25] <cjwatson> slytherin: we have to, but it certainly puts more pressure on powerpc
[16:26] <cjwatson> slytherin: there's no one kernel that boots on both powerpc32/64, although the userspace is the same
[16:26] <crescendo> @cjwatson: is there a log kept anywhere as to who made what changes?
[16:26] <cjwatson> crescendo: there's the seeds, https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.karmic et al
[16:26] <cjwatson> crescendo: that's not everything, but it sounds closest to what you want
[16:27] <cjwatson> also .../platform.karmic
[16:27] <crescendo> aha, this is perfect. I have enough to chew on for a while now, thanks
[16:28] <cjwatson> also http://wiki.ubuntu.com/SeedManagement
[16:28] <cjwatson> and the germinate(1) manual page for the technical structure involved there
[16:32] <MacSlow> popey, I can verify LP: #334863 to be fixed with the latest notiy-osd 0.9.22 under Karmic
[16:34] <cjwatson> slytherin: ia64 would be a different problem, presumably, since I'm fairly sure it only has one kernel these days
[16:35] <slytherin> cjwatson: I found one problem but that may not explain oversize. It just explains the uninstallability of many packages (http://cdimages.ubuntu.com/ports/daily/current/report.html). Older synaptic version (ubuntu4 instead of ubuntu5).
[16:37] <cjwatson> slytherin: is the package out of date in the archive too?
[16:37] <cjwatson> apparently not, presumably it was just slow to build
[16:38] <cjwatson> slangasek: ok if I trigger a new ports/alternate build?
[16:38] <slytherin> cjwatson: No. Looks like the ports images were built long before non-ports images. Hence this inconsistency.
[16:38] <slangasek> cjwatson: go for it
[16:38] <cjwatson> slytherin: not unusual

[16:40] <slytherin> cjwatson: may be the cron job time modified and not reverted later.
[16:41] <slangasek> Keybuk: hmm, I was just going to call the job 'statd' actually; do you have a preference for 'rpc.statd'?
[16:41] <cjwatson> slytherin: no, they're normally at different times
[16:41]  * slangasek thinks the latter is ugly :)
[16:41] <cjwatson> slytherin: they're intentionally independent cron jobs
[16:42] <slytherin> cjwatson: That's all for now. I will take another look later for more analysis.
[16:45] <Keybuk> slangasek: no preference
[16:48] <slangasek> Keybuk: ok.  so, one outstanding corner case with the nfs-common stuff: pre-upstart, it was possible to have a system work reliably with /usr on an NFSv3 filesystem and /home on NFSv4 w/ gss; now, our choices are to wait for "FHS" (including /home) before starting gssd, or to assume /usr is local - any thoughts on that?
[16:49] <slangasek> I think I'm going to go with "assume /usr is local", but it doesn't feel correct to me :)
[16:50] <slangasek> conveniently, if /usr is on NFSv3, we don't /need/ rpc.gssd or rpc.idmapd, so it also doesn't hurt if they fail to start
[16:51] <Keybuk> I'm not sure I'm following
[16:51] <Keybuk> why doesn't it work?
[16:51] <slangasek> Keybuk: rpc.gssd and rpc.idmapd are in /usr/sbin
[16:51] <Keybuk> ok, so why can't you have them "start on filesystem" ?
[16:51] <slangasek> to properly ensure /usr is available, we should start on filesystem
[16:51] <slangasek> which precludes using NFSv4 for mounting /home
[16:52] <slangasek> since 'filesystem' doesn't get signaled unless /home is mounted
[16:52] <Keybuk> why does it preclude it?
[16:53] <slangasek> "since 'filesystem' doesn't get signaled unless /home is mounted" - that's true, isn't it?  I know I saw bugs about that
[16:53] <Keybuk> yes
[16:53] <Keybuk> but why does it preclude it?
[16:53] <Keybuk> if rpc.statd and rpc.nfsd are on /
[16:53] <slangasek> if you want /home to be an NFSv4 mount?
[16:53] <Keybuk> they are started on local-filesystems
[16:54] <slangasek> you need idmapd (and possibly gssd) to do the NFSv4 mount
[16:54] <Keybuk> oh, I see what you mean
[16:54] <Keybuk> there's no event for "I have some of the filesystem but not /home"
[16:54] <slangasek> right
[16:54] <Keybuk> if we need that, we could add that ;)
[16:54] <slangasek> I think it'd be a good thing to have
[16:55] <slangasek> in the meantime, I'll wire it to use 'local-filesystems', I think that's closest
[16:55] <Keybuk> *nods*
[17:05] <Keybuk> kirkland: ignoring the "wow, I didn't know you could do that" and "I don't even know why you would want to do that" pieces of the scripts
[17:05] <Keybuk> http://people.canonical.com/~scott/eucalyptus.png
[17:05] <Keybuk> ^ that's how I think Upstart will run those
[17:06] <Keybuk> if the aim is not to run things in parallel, fail appears to have happened <g>
[17:07] <kirkland> Keybuk: :-)
[17:07] <Keybuk> kirkland: what about that graph strikes you as wrong?
[17:07] <Keybuk> without deeper understanding, I can't tell whether that's what's intended or not
[17:08] <kirkland> Keybuk: well that's cool
[17:08] <Keybuk> there are up to 5 parallel paths
[17:08] <kirkland> Keybuk: let me check with euca-guys
[17:09] <Keybuk> I should so write a Perl script to do that
[17:10] <Keybuk> in fact, I'm going to!
[17:12] <cjwatson> Keybuk: point of information: e8s ;-)
[17:12] <cjwatson> "point of arithmetic", perhaps
[17:13] <Laney> Keybuk: hey, that util-linux/udev bug (by-uuid symlinks pointing to block devices instead of mdadm partitions) seems fixed, is that right?
[17:13] <Laney> http://dpaste.com/100429/
[17:14] <slangasek> cjwatson: hah, you took the time to count? :)
[17:15] <Darxus> I need a karmic live cd containing a package that went into the archive today to test a bug fix.  How do I get that?
[17:15] <cjwatson> slangasek: my subconscious mind does it for me for words under about 12 letters, I think
[17:17] <Darxus> Looks like my best option may be to wait for the next time this file is rebuilt?  http://cdimage.ubuntu.com/daily-live/current/karmic-desktop-i386.iso
[17:19] <Keybuk> cjwatson: see, I can'
[17:19] <Keybuk> cjwatson: see, I can't even figure out how many letters there are in that word!
[17:19] <Keybuk> Laney: it should be fixed
[17:20]  * ogra hands Keybuk a keyb-uk :)
[17:21] <cjwatson> chrisccoulson: offhand, do you have any idea what happened to the syncio option in ntfs-3g, that we used to carry as an Ubuntu patch?
[17:21] <Laney> Keybuk: good stuff
[17:21] <Laney> thanks
[17:21] <chrisccoulson> cjwatson - i'm not sure about that
[17:21] <cjwatson> Darxus: if there isn't anything new enough in that location, then waiting (unfortunately until after beta) is probably your best option, yes
[17:21] <chrisccoulson> i don't remember removing any patches
[17:21] <cjwatson> chrisccoulson: I'm speculating whether it might be the cause of Wubi instability we're seeing
[17:22] <Darxus> cjwatson: After beta?
[17:22] <cjwatson> Darxus: yes, http://wiki.ubuntu.com/KarmicReleaseSchedule
[17:22] <cjwatson> Darxus: what fix, out of interest?
[17:22] <Darxus> cjwatson: https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/410933
[17:23] <Darxus> Sound doesn't work by default on some hardware.
[17:23] <Darxus> cjwatson: Oh, beta is tomorrow?  Why is that unfortunate?
[17:23] <Darxus> Just because it would've been better to get the fix in before beta?
[17:24] <cjwatson> Darxus: um, so
[17:24] <cjwatson> Darxus: nobody claimed in that bug that any particular fix had gone into the archive
[17:24] <slangasek> Darxus: there haven't been any alsa-utils changes accepted into the archive that aren't on that CD
[17:24] <cjwatson> Darxus: Daniel just asked you to test with the most current thing
[17:24] <Darxus> Ahh, thanks.
[17:24] <Darxus> I can do that.
[17:24] <Darxus> The bug will still be there though :P
[17:24] <chrisccoulson> cjwatson - from a first glance, it looks like it might have been dropped off during a merge
[17:25] <cjwatson> chrisccoulson: that's what it looked like to me; I was wondering if there was a reason you knew about, as the merger
[17:25] <Darxus> I'm going to grab the iso I previously mentioned then....
[17:25] <cjwatson> of course wubi passes it in such a way that I'm pretty sure it won't actually make it to mount
[17:25] <cjwatson> but ANYWAY, I can fix that bit
[17:25] <chrisccoulson> cjwatson - no, i don't remember dropping it off deliberately.
[17:26] <Darxus> The fact that, at least briefly, the status was changed to "Fix Committed" was confusing.
[17:26] <chrisccoulson> but that was sometime last cycle
[17:26] <slangasek> Darxus: how do you know the bug will still be there?  The only information on the bug report is about jaunty, not karmic
[17:26] <cjwatson> chrisccoulson: ok, thanks; I'll look at restoring it, so that at least we can eliminate that as a cause
[17:27] <Darxus> slangasek: I'm just being pessimistic.
[17:28] <kirkland> Keybuk: would you mind making a once-over pass across our upstart scripts, and making some suggestions?
[17:28] <kirkland> Keybuk: sounds like you took a quick look and saw somethings that were non-standard
[17:29] <cjwatson> chrisccoulson: we're seeing various symptoms, but at least one of them is consistent with stuff just not being synced to disk, hence this hunch
[17:30] <Darxus> cjwatson: Could you clarify why you said that being after beta would be unfortunate?
[17:31] <cjwatson> Darxus: it's irrelevant now, since you're not actually waiting for a fix that's in the archive; but if you had been, it would presumably be unfortunate for you that you would have needed to wait
[17:32] <cjwatson> Darxus: FWIW Fix Committed never means fix-in-the-archive, in any case - that's Fix Released
[17:33] <Darxus> cjwatson: Why would I have needed to wait?  Isn't beta tomorrow?
[17:33] <cjwatson> ys
[17:33] <cjwatson> yes
[17:33] <cjwatson> but quite possibly late tomorrow
[17:34] <Darxus> cjwatson: I'm not that impatient :)  Thanks for the clarification.
[17:44] <seb128> cjwatson, in what templates are the ubiquity translations usually?
[17:44] <seb128> cjwatson, ie the bootloader option screen
[17:45] <cjwatson> seb128: which screen exactly? what's the text
[17:45] <seb128> cjwatson, "Install boot loader" for example
[17:45] <seb128> the whole screen is not translated in french there which seems weird
[17:46] <cjwatson> that *is* odd, that string is translated in the source
[17:46] <cjwatson> ubiquity/ubiquity-debconf, BTW
[17:48] <cjwatson> I think the dialogs just aren't translated
[17:49] <cjwatson> seb128: please file a bug on ubiquity about this specific thing
[17:49] <seb128> cjwatson, ok, thanks
[17:49] <Keybuk> kirkland: didn't I just do that?
[17:50] <Keybuk> they look absolutely crazy to me
[17:50] <Keybuk> like even just the first one
[17:50] <Keybuk> you have a pre-start script to pick up options and write them to a file that the exec line picks up?
[17:50] <Keybuk> WHY?!
[17:51] <Keybuk>   script
[17:51] <Keybuk>           . /etc/eucalyptus/eucalyptus.conf
[17:51] <Keybuk>           exec avahi-publish -s $(hostname) _eucalyptus._tcp $CC_PORT txtvers=1 protovers=1.5.0 type=cluster\
[17:51] <Keybuk>   end script
[17:51] <Keybuk> etc.
[17:52] <Keybuk> I'm entirely unsure why you need a post-start script, and can't just make apache daemonise
[17:52] <Keybuk> (I don't think it detaches until it's listening, no?)
[17:52] <Keybuk> there are scripts that only seem to exist to poll
[17:53] <cjwatson> I think we do need to poll, there's a gap between eucalyptus listening on the port and actually working, AIUI
[17:53] <mathiaz> Keybuk: ^^ yes
[17:53] <Keybuk> so yes, I'm afraid of reviewing these in case
[17:53] <Keybuk>  a) they eat me
[17:53] <Keybuk>  b) it somehow results in me getting some kind of responsibility to fix them
[17:53] <slangasek> one of those is polling apache; is that actually needed?
[17:54] <maco> haha
[17:54] <kirkland> Keybuk: alrighty, thanks
[17:54] <kirkland> Keybuk: can you tell me how to figure out what this means:
[17:54] <kirkland> Sep 30 11:45:40 cluster init: job_process_handler: Ignored event 1 (0) for process 844
[17:55] <mathiaz> slangasek: well - apache2 is started with axis, which needs to deploy jar files
[17:56] <mathiaz> slangasek: IIUC polling is necessary to know when the java services are actually operational
[17:56] <Keybuk> kirkland: it means that process 844 exited
[17:56] <Keybuk> and that Upstart didn't know about process 844
[17:56] <Keybuk> well
[17:57] <Keybuk> *maybe* didn
[17:57] <Keybuk> 't know about it
[17:57] <Keybuk> depends whether you see a message on the following line
[17:57] <mathiaz> kirkland: are you still tracking down why the cc-registration job isn't started by upstart?
[17:57] <Keybuk> well
[17:58] <Keybuk> that could be because of the wacky way in which e8s cloud is written
[17:58] <kirkland> mathiaz: yes, nurmi and i are looking at that right now
[17:58] <kirkland> mathiaz: we're walking the verbose syslog line by line
[17:58] <Keybuk> kirkland: may I see it?
[17:59] <kirkland> Keybuk: http://pastebin.com/f10933e19
[17:59] <kirkland> Keybuk: basically, the eucalyptus-walrus-registration *is* running
[17:59] <kirkland> Keybuk: but eucalyptus-cc-registration and eucalyptus-sc-registration *are not*
[18:00] <kirkland> Keybuk: we're trying to get to the bottom of why
[18:00] <mathiaz> kirkland: in my testing sc-registration will run once cc-registration has run
[18:01] <mathiaz> kirkland: I tested it by doing: sudo start eucalyptus-cc-registration
[18:01] <mathiaz> kirkland: that run both the cc and the sc registration jobs
[18:03] <Keybuk> maybe they timed out?
[18:03] <Keybuk> if you comment out the "start on" in the dbus-reconnect.conf, do they work?
[18:03] <Keybuk> (eventually)
[18:04] <kirkland> Keybuk: checking
[18:04] <Keybuk> e8s-cloud isn't started
[18:04] <Keybuk> its post-start is still running
[18:05] <cjwatson> seb128: confirmed that it's busted for ubiquity dialogs in general
[18:05] <Keybuk> ah, right
[18:05] <Keybuk> it finishes after dbus-reconnect
[18:05] <Keybuk> you hit *that* bug ;)
[18:06]  * Keybuk bets that disabling that job will make it work for you
[18:11] <Riddell> mvo: the dist-upgrade tool still doesn't have the kbluetooth4 fix in it?
[18:11] <seb128> cjwatson, it's weird, the dialog is displayed if I run ubiquity again
[18:11] <seb128> displayed -> translated
[18:13] <kirkland> Keybuk: disabling which job?
[18:13] <kirkland> Keybuk: dbus-reconnect?
[18:14] <Keybuk> eys
[18:14] <kirkland> Keybuk: how do i disable a job properly?
[18:14] <Keybuk> just comment out the "start on" line
[18:17] <cjwatson> seb128: yep, that makes sense from the bug
[18:17] <cjwatson> seb128: no need to file it if you haven't already, I'm fixing it now
[18:17] <cjwatson> the bug is in the thing that translates widgets on the fly after you change the language on the first screen
[18:17] <seb128> cjwatson, ok, no I didn't yet I was busy on something else, I just looked if there was one filed and I didn't find one
[18:18] <seb128> cjwatson, ah ok, thanks for the quick fixing ;-)
[18:18] <cjwatson> somebody on the translators list was complaining about something that sounded similar
[18:21] <cjwatson> there we go, much better. just need to check Kubuntu too
[18:21] <dpm> cjwatson, seb128: I think what was mentioned on the translators list was a problem with the slideshow, not with bootloader; bug 430719
[18:22] <cjwatson> dpm: not that, the stuff Timo Jyrinki was asking about
[18:23] <dpm> cjwatson: ah, ok, sorry, I was following the wrong conversation
[18:23] <cjwatson> he mentioned the partition create/edit dialogs not being translated, iirc, which is the same bug as seb128's
[18:24] <dpm> ah, yes, thanks
[18:31] <cjwatson> seb128: fix committed, thanks again
[18:32] <avb> guys, seems update-initramfs has an issue. update-initramfs -u -k all doesnt pack usplash for me because its not processing framebuffer hook.
[18:32] <kirkland> Keybuk: commenting out dbus-reconnect did seem to help quite a bit
[18:33] <kirkland> Keybuk: what bug number is that, so that we can track it?
[18:33] <avb> it has OPTIONS=USPLASH there and seems i dont have this option defined somewhere. I was upgrating from jaunty to karmic with apt-get
[18:33] <cjwatson> avb: usplash isn't included by default any more except in certain situations. Put USPLASH=y in /etc/initramfs-tools/initramfs.conf if you want to force it on
[18:33] <cjwatson> this is an intentional change documented in the changelog
[18:34] <Riddell> cjwatson: what needs checked in kubuntu?
[18:34] <avb> cjwatson: how is splash screen ought to work now?
[18:34] <avb> cjwatson: thing is that im not getting splash at all. or it was designed like this?
[18:36] <avb> another thing will release include 2.28.1 or it will be released with 2.28.0?
[18:36] <cjwatson> Riddell: nothing, I checked it
[18:36] <cjwatson> avb: the intent is to get to xsplash as quickly as possible; running usplash slows that down
[18:36] <avb> i see
[18:36] <Riddell> ok, thanks, for whatever it was :)
[18:36] <cjwatson> avb: it's not quite all as neat as intended yet
[18:36] <cjwatson> Riddell: translation bug that was only in the GTK frontend
[18:37] <avb> :) i agree
[18:37] <avb> thing is that gnome-display-properties has a bug with mirroring displays with a different resolution. and it will be fixed only in 2.28.1
[18:37] <cjwatson> we've always included gnome point releases
[18:37] <cjwatson> for some value of "always" anyway
[18:37] <avb> now if you going to mirror 2 displays with diff resolutions, it will crash application
[18:38] <avb> there is a patch in bugzilla, so i wonder if its needed to be backported
[18:38] <cjwatson> 18:37 <cjwatson> we've always included gnome point releases
[18:38] <avb> yeh. okay
[18:38] <avb> thanks
[18:46] <Keybuk> kirkland: it's more of a meta-bug
[18:48] <kees> james_w: where are the distro-tracking bzr trees again?
[18:48] <james_w> code.launchpad.net/ubuntu
[18:48] <kees> james_w: ah-ha, thanks!
[18:48] <james_w> with +source and /karmic/ etc. as usual
[18:49] <james_w> sometimes things are where you would expect :-)
[18:49] <kees> lp:ubuntu/$release/$source/$release ?
[18:52] <mathiaz> kees: lp:ubuntu/karmic/openldap
[18:55] <james_w> where "karmic" can be any suite
[18:55] <james_w> e.g. jaunty-security
[18:56] <james_w> if there was nothing uploaded to said suite then you will get "not a branch"
[18:56] <seb128> cjwatson, thanks for fixing the issue ;-)
[18:57] <kirkland> Keybuk: is it tracked in launchpad?
[18:57] <Keybuk> kirkland: no
[18:58] <Keybuk> unless you count a spec/
[18:58] <Keybuk> https://blueprints.edge.launchpad.net/upstart/+spec/states
[18:58] <mvo> Riddell: no, its still in the queue but its upload
[18:58] <mvo> Riddell: you mean the kbluetooth -> kbluetooth4 fix, right?
[18:59] <Keybuk> though that
[18:59] <Keybuk> though that's a _very_ old draft ;)
[19:02] <kees> james_w: aaah, cool
[19:02] <james_w> haven't quite worked out the best way to say "latest in any pocket of series X" yet though
[19:03] <mathiaz> james_w: lp:ubuntu/jaunty-latest/srcpkg ?
[19:10] <mathiaz> kirkland: IIRC once you've aggreed to boot a degraded raid array, subsequent reboots should'd ask whether to boot from a degraded array - it should be automatic?
[19:11] <kirkland> mathiaz: if you agreed in debconf, that's true
[19:11] <mathiaz> kirkland: ah - in debconf
[19:11] <kirkland> mathiaz: if you mean in the initramfs, that's true for your "current degraded event"
[19:11] <mathiaz> kirkland: I aggreed in the initramfs - the first time
[19:12] <kirkland> mathiaz: right, you only get that question in initramfs when mdadm detects that the raid has just become degraded
[19:12] <kirkland> mathiaz: if you tell mdadm to boot it, then it says "okay, cool, so now you expect this raid to be degraded, i won't ask you again"
[19:12] <mathiaz> kirkland: ok - so on the next reboots, it shouldn't ask?
[19:12] <mathiaz> kirkland: ok - that's not happening then
[19:13] <mathiaz> kirkland: I'm still asked what I wanna do
[19:13] <kirkland> mathiaz: right; until you re-add the disk, and the raid is sync'd again
[19:13] <kirkland> mathiaz: and you're not creating new degraded events in between boots?
[19:13] <mathiaz> kirkland: hm wait - now it works as expected
[19:14] <kirkland> mathiaz: right, the logic is slightly complicated
[19:20] <mathiaz> kirkland: hm - missing drives aren't supposed to be automatically added to a degraded raid array, right?
[19:20] <Keybuk> kirkland: can you file an ubuntu bug specifically about the dbus issue?
[19:21] <Keybuk> there's a trivial fix for that I can do after beta
[19:32] <slangasek> Keybuk: wrt sreadahead profiling automatically on boot - is there no need to have a "default" profile for the liveCD itself?
[19:33] <Keybuk> slangasek: did we ever use readahead on the live cd?
[19:33] <Keybuk> dunno ;)
[19:33] <slangasek> it's installed in the livefs
[19:34] <Keybuk> that probably means that sreadahead profiles the live cd right now? :)
[19:34] <slangasek> but only on "first boot", so it doesn't help? :)
[19:35] <slangasek> anyway, if the answer is that this isn't worth the effort, that's fine
[19:35] <Keybuk> the problem was generating one for every single image
[19:35] <Keybuk> otherwise you end up with kubuntu using a ubuntu profile
[19:35] <Keybuk> and they whine
[19:36] <slangasek> ah
[19:36] <davmor2> Keybuk: no surely a whine profile would install windows ;)
[19:47] <slangasek> Keybuk: I'm trying to work through the fact that upstart 'restart' doesn't have the same semantics as policy requires for init scripts... the only thing causing performance problems on boot is the /etc/rc*.d/ symlinks, right?  So if we don't have /those/, then an upstart-job symlink in /etc/init.d doesn't hurt; so we could arguably use the same invoke-rc.d handling for maintainer scripts in dh_installinit if we added those symlinks?
[19:48] <slangasek> (reducing the debhelper delta, making it easier to get certain packages to dtrt - such as nfs-common, which needs to use restart-after-upgrade)
[19:49] <Keybuk> but then what happens when we *do* what the right semantics?
[19:49] <Keybuk> e.g. from debhelper
[19:50] <Amaranth> I thought apparmor loading got moved into initramfs
[19:50] <slangasek> well, that's a policy change that hasn't been worked through yet
[19:50] <slangasek> but currently, we silently ignore all failures to start jobs
[19:50]  * Amaranth still has an init script running for it too
[19:50] <Keybuk> sure, there's bugs here and work items
[19:50] <Keybuk> that's the side effect of developing things as we go ;)
[19:51] <slangasek> and the reason restart-on-upgrade breaks for nfs-common is that the postinst snippet does "restart" if [ -n "$2" ] - so you can't use that when /upgrading/ from a pre-upstart version
[19:51] <Keybuk> so that should be start
[19:51] <Keybuk> ?
[19:52] <slangasek> it should be start when upgrading from pre-upstart, yes
[19:52] <slangasek> and restart otherwise
[19:52] <slangasek> but the preceding debhelper snippet would have dtrt with "restart" anyway, by design
[19:53] <slangasek> (for values of "dtrt" including "start the service on upgrade if it wasn't previously started", which is the behavior currently expected based on policy)
[19:53] <Keybuk> it would have also started the service if it wasn't already running
[19:53] <Keybuk> which is broken by design
[19:54] <Keybuk> after all, half the bonus of designing a new init system is that you get to design a new policy at the same time
[19:54] <Keybuk> and fix problems with the old
[19:54] <Keybuk> it seems backward to tie ourselves to the old policy with the new init system
[19:54] <Keybuk> especially the old policy isn't compatible with it
[19:55] <slangasek> broken, perhaps; but known and consistent, and I'm not convinced that the new isn't also broken in ways that haven't been identified yet
[19:55] <Keybuk> the point is that if we figure out ways in which the new is broken, we fix them ;)
[19:56] <slangasek> and "can't use restart-on-upgrade for existing packages" isn't broken enough?
[19:56] <slangasek> or do you have some other way to fix this?
[19:56] <slangasek> having to write dozens of lines of postinst code by hand irks me
[19:57] <Keybuk> I can't think of a way off hand to fix it
[19:57] <Keybuk> but it's something we should figure out
[19:57] <Keybuk> otherwise you're in a strange state where the old sysv service is still running
[19:57] <Keybuk> but has no init.d script or rc0.d symlink to bring it down on shutdown
[19:57] <slangasek> nah, I already wrote the code to stop the job by hand too
[19:57] <Keybuk> this was why we talked about using invoke-rc.d for maintainer scripts that aren't upstart-only though right?
[19:58] <Keybuk> as a temporary measure
[19:58] <slangasek> well, that's exactly what I was proposing
[19:58] <Keybuk> since the non-upstart-only ones have symlinks in /etc/init.d
[19:58] <Keybuk> oh
[19:58] <Keybuk> ;)
[19:58] <Keybuk> right, I didn't have any objections to that
[19:59] <slangasek> well, ok, not exactly - I'm also wondering if upstart-only shouldn't also provide the symlink in /etc/init.d and use invoke-rc.d in the maintainer script
[19:59] <Keybuk> my objection has only ever been to things that didn't exist as init scripts before
[19:59] <slangasek> right, ok
[19:59] <Keybuk> because those are going to be written with upstart in mind
[19:59] <Keybuk> so it's proper that they obey upstarty semantics
[19:59] <slangasek> nfs-common has a pre-existing init script, but splits to 4 upstart jobs... so there's no good fit
[20:00] <Keybuk> if it never existed in the sysv world, it's confusing to expect it to behave that way
[20:00] <slangasek> anyway, --restart-after-upgrade --upstart-only is also broken for any package which adds a new upstart job
[20:01] <Keybuk> is it?
[20:01] <Keybuk> it won't result in it being started
[20:01] <Keybuk> but it should also not result in it failing
[20:01] <slangasek> yes, that's broken :)
[20:01] <Keybuk> which is correct behaviour
[20:01] <Keybuk> no, it's correct behaviour
[20:01] <slangasek> it's "correct" behavior because you've specified this is what it will do, but I don't believe that's actually the behavior anyone wants
[20:02] <Keybuk> really?  one of the biggest complaints I ever hear about Debian init script policy is that if you stop a service, it gets started again by apt-get upgrade
[20:02] <slangasek> yes, I'm talking about a *new* upstart job
[20:02] <slangasek> added to an existing package, and it needs to get started on upgrade
[20:02] <Keybuk> then it wouldn't use restart? :)
[20:02] <Keybuk> it'd use ordinary postinst scripts
[20:03] <slangasek> if you're using --restart-on-upgrade --upstart-only, it would call restart and ignore the failure
[20:03] <Keybuk> restart-after-upgrade itself is a workaround for brokenness in initscripts
[20:04] <Keybuk> upstart will have quite different behaviours for this stuff
[20:04] <Keybuk> I'm quite happy to work out what those should be in a way that makes sense though :)
[20:04] <Keybuk> however if someone hands me a copy of Debian Policy as the "right" way, I shall burn it
[20:04] <Keybuk> ...and them :p
[20:04] <slangasek> if we don't use restart-after-upgrade, then we're calling "start", which doesn't restart the job if already running, right?
[20:04] <Keybuk> slangasek: right
[20:04] <slangasek> I'm flame-retardant :P
[20:04] <Keybuk> but then restart doesn't do what you think either :p
[20:05] <slangasek> Keybuk: so what ensures that we re-exec the newly-installed binary?
[20:05] <Keybuk> stop && start
[20:05] <slangasek> Keybuk: so the current init script snippets don't do that, either
[20:05] <Keybuk> restart doesn't reload the *.conf file
[20:05] <Keybuk> it restarts the service with the configuration it currently has
[20:05] <Keybuk> one assumes after an upgrade that will have changed
[20:06] <slangasek> so to get sensible package behavior (after upgrade, the right binary is running with the right config), we have to call stop && start, and that's not happening today
[20:06] <Keybuk> stop ; start has the benefit of starting the service ;)
[20:07] <Keybuk> (if it wasn't already running)
[20:07] <slangasek> so that's what --restart-after-upgrade should actually be calling
[20:07] <Keybuk> it does start sysadmin-stopped services
[20:07] <Keybuk> but so does stop-in-prerm/start-in-postinst which most packages still do
[20:07] <Keybuk> this is better fixed with the "mark for upgrade" functionality
[20:07] <slangasek> is that available yet? :)
[20:07] <Keybuk> lol, no
[20:08] <slangasek> then I think it's important to fix the debhelper snippets to give behavior consistent with what we expect of sysvinit-using services on upgrade
[20:08] <Keybuk> so stop ; start is probably right for that case
[20:08] <Keybuk> sure, not disagreeing :)
[20:17] <Keybuk> (you can tell when I disagree because I don't suggest workarounds :p)
[20:19] <mathiaz> slangasek: I'd like to document bug 427048 for Beta - is https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#Known%20issues the right place?
[20:20] <slangasek> mathiaz: yes, please!
[20:24] <mathiaz> kirkland: is there a workaround for bug 427048?
[20:24] <kirkland> mathiaz: manually install to each disk in the array
[20:24] <mathiaz> kirkland: how do you do that? grub-install /dev/sdb?
[20:25] <kirkland> mathiaz: up
[20:25] <kirkland> yup
[20:26] <Keybuk> if we put the boot loader in the partition instead of the mbr ...
[20:26] <Keybuk> </age old whine of mine>
[21:01] <kirkland> ttx: ping
[21:02] <kirkland> ttx: how much disk space do you have on your cluster machine?
[21:03] <ttx> kirkland: 160Gb
[21:03] <kirkland> ttx: okay
[21:03] <ttx> -6 swap
[21:04] <kirkland> ttx: and on your node?
[21:04] <ttx> node is 300Gb -6swap
[21:04] <kirkland> k
[21:05] <ttx> kirkland: how is it going ? did you reproduce it when starting an instance ?
[21:05] <slacker_nl> anyone familiar with apprt, i cannot find the ubuntu-bug file in there
[21:05] <kirkland> ttx: so the localhost/ipaddr change is "good", that results in successful walrus, sc, and cc registration *every* time
[21:06] <kirkland> ttx: i wasn't able to reproduce the situation you had, where you had to restart the cloud
[21:06] <kirkland> ttx: i just waited a few minutes, and everything was registered, and available just fine
[21:06] <kirkland> ttx: i just tried to run an instance
[21:06] <kirkland> ttx: that failed, but it's because I filled up my small hard disk (32G SSD)
[21:06] <kirkland> ttx: so i'm starting over, with a bigger disk
[21:07] <ttx> kirkland: did you check if the nc got polled ?
[21:07] <ttx> nc.log should show stuff every 8 sec or so
[21:07] <ttx> without a restart it never gets polled
[21:07] <ttx> (at least in my case)
[21:08] <kirkland> ttx: yes, nc polling is working like a champ
[21:08] <kirkland> ttx: no restart
[21:08] <ttx> beh
[21:09] <ttx> did Dan confirm that it should not be needed ?
[21:09] <ttx> (he always added it on his own testlogs)
[21:09] <kirkland> ttx: he said he was surprised that i didn't have to restart
[21:10] <kirkland> ttx: he says they have a fix upstream that we need to take to fix that
[21:10] <ttx> kirkland: hm, I always had to as well.
[21:10] <ttx> you should be able to confirm with your next run
[21:11] <ttx> kirkland: did you test from ISO install or from package install ?
[21:12] <kirkland> ttx: iso, purged 12, installed 13
[21:12] <ttx> kirkland: I was wondering if that would not introduce a difference, the fact that you don't start up things during the iso install/postinsts
[21:15] <ttx> kirkland: maybe it's possible to fake an ISO run by rebundling it
[21:15] <kirkland> ttx: mdz did that a few times, with much error and great pain, last week
[21:16] <ttx> kirkland: what we could do...
[21:17] <ttx> kirkland: test that 13 is alright, test that installing beta (with workaround) + upgrading to 13 is alright
[21:17] <ttx> releasing with what we have
[21:17] <ttx> and then validate daily ISOs starting beta+1
[21:18] <ttx> beta would be 12, users would upgrade to 13, and then we can take time to make sure daily ISOs with 13 are ok
[21:18] <Keybuk> bzr: ERROR: 77afdcdf611d88cf3e8b0806fd04c56c.tix is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.
[21:18] <Keybuk> W. T. F.
[21:19] <ttx> kirkland: how does that sound ?
[21:20] <kirkland> ttx: that's what i've liked all along
[21:20] <kirkland> ttx: i think 13 is the direction we need to go
[21:20] <kirkland> ttx: though there are still bugs to be fixed
[21:21] <ttx> kirkland: I'm concerned by the difference we experience in testing though
[21:21] <ttx> (wrt the need to restart)
[21:21] <kirkland> i'm going to leave my test env in my dmz for now
[21:21] <kirkland> if you'd like to ssh in and watch along, let me know
[21:21] <kirkland> i'll drop your ssh key on those boxes
[21:21] <kirkland> ttx: nurmi and i are on it now
[21:23] <ttx> please do the full run with 13, up to running instances. Ideally by setting up 12 with workaround first, then upgrade to 13
[21:23] <ttx> if that works, we know we can leave 13 in
[21:23] <ttx> I'll validate that as well tomorrow morning
[21:24] <ttx> kirkland: what did you exactly do on the node side ?
[21:24] <kirkland> ttx: on the node side?
[21:25] <kirkland> ttx: i install byobu, and tail -f a bunch of log files
[21:25] <kirkland> ttx: daz it
[21:25] <ttx> kirkland: on the nc, you also installed 12, purged, and installed 13 ?
[21:25] <kirkland> ttx: yes
[21:26] <ttx> please also validate the beta+upgrade scenario on that side
[21:26] <ttx> (I don't think it would change anything, but...)
[21:26] <kirkland> ttx: okay, i'll do that
[21:26] <kirkland> ttx: i'm reinstalling my cloud now
[21:26] <ttx> kirkland: welcome to the club
[21:26] <kirkland> ttx: how much longer are you around?
[21:26] <ttx> a few minutes
[21:28] <ttx> kirkland: please summarize your findings at the end in an email, saying that keeping 13 is apparently non-harmless for users to upgarde to, and allows to have dailies to debug the rest
[21:28] <ttx> (of course if you manage to make it fully work in a 12 + manual reg + upgrade to 13 scenario :)
[21:29] <ttx> I wish I had Dan in my box in my morning.
[21:31] <kirkland> ttx: yikes
[21:35] <kirkland> ttx: okay, will do
[21:46]  * ttx shuts down
[21:48] <cjwatson> Keybuk: for a long time we weren't putting it in a partition largely through inertia; but one problem that's become evident relatively recently is that if you put it in a partition boot record then you generally have to use blocklists, i.e. grub has to remember the location of all the blocks comprising what used to be called its stage1.5 (fs handling, etc.)
[21:48] <Keybuk> why?  it shouldn't make any difference
[21:48] <cjwatson> Keybuk: because most filesystem types don't leave significant enough space for a boot loader
[21:49] <Keybuk> you have the same number of bytes as you do in the MBR no?
[21:49] <cjwatson> no, not true
[21:49] <Keybuk> ah
[21:49] <cjwatson> if you put it in the MBR, there's normally 32KB or so space after it where the bootloader can be embedded
[21:49] <cjwatson> which isn't used by any filesystem
[21:49] <Keybuk> see, this is why we should just have a small FAT partition at the front of the disk, with all kernels and bootloaders and initramfses and stuff on them
[21:49] <Keybuk> then you can write a trivially tiny bootloader to pick one
[21:50] <Keybuk> someone should write a standard that requires that
[21:50] <cjwatson> so, today, putting it in a filesystem means that more or less random filesystem changes (e.g. defragmentation in the case of ext4) can cause you to have to reinstall grub
[21:50] <Keybuk> and then fail to get any OS developer or OEM to actually embrace it
[21:50] <Keybuk> except Apple
[21:50] <cjwatson> shame the EFI standard is a right pain in other areas really ...
[21:50] <cjwatson> BIOS designed by committee, hooray
[21:50] <cjwatson> or BIOS with big long method names for everything
[21:50] <cjwatson> GPT is really the only good bit of it, and you don't need EFI for GPT
[21:51] <Keybuk> aye, *sigh*
[22:01] <bluefoxicy> whatthe friggin hell?
[22:01] <bluefoxicy> plugging in a wire is fatal
[22:01] <bluefoxicy> okay.
[22:01] <bluefoxicy> that's retarded.
[22:03] <bluefoxicy> okay
[22:03] <bluefoxicy> there's actually a bug for this.
[22:04] <mdz> kirkland, how goes it?
[22:05] <bluefoxicy> okay what do i do about a "Fix Released" bug that's still a bug?  Remove "Fix Released" and see who gets pissed off?
[22:05] <kirkland> mdz: testing again
[22:05] <bluefoxicy> (double-bug because the "Fix" is idiotic, and the person who marked it as "Fix Released" made note of this explicitly)
[22:06] <kirkland> mdz: i got to the point where i deployed an image last time around
[22:06] <kirkland> mdz: and my 32GB disk filled up
[22:06] <kirkland> mdz: so i've done a hardware swap-a-roo
[22:06]  * kirkland realizes he should note that in the test wiki
[22:06] <mdz> kirkland, filled 32GB, really? that's surprising
[22:07]  * bluefoxicy unmarks #278485 and sees who bitches.
[22:07] <kirkland> mdz: image was 10GB unzipped
[22:07] <mdz> kirkland, what consensus did you and ttx come to with regard to the registration problems?  he said he could reproduce a problem, but it worked for you
[22:07] <kirkland> mdz: i'm making sure that upgrading to my ubuntu13 doesn't break things in nasty ways
[22:07] <kirkland> mdz: so far it's not; it's succeeding in auto registering the components
[22:08] <kirkland> mdz: i'm trying to get back to the point where i reproduce ttx's failure to deploy the image
[22:08] <bluefoxicy> uh  huh.
[22:09] <bluefoxicy> It doesn't work because nm crashes.
[22:10] <Keybuk> kirkland: just uploaded an upstart & dbus package to ubuntu-boot PPA ... appreciate some testing
[22:11] <kirkland> Keybuk: okay
[22:11] <kirkland> mdz: unfortunately, i'm at the part that takes a *really* long time
[22:12] <kirkland> mdz: image preparation takes 20+ minutes
[22:13] <kirkland> Keybuk: to fix the dbus-reconnect problem?
[22:13] <Keybuk> yup
[22:13] <kirkland> mdz: up to step 5 on http://testcases.qa.ubuntu.com/Install/ServerEConfig is working like a champ
[22:14] <kirkland> mdz: with auto registration, etc.
[22:14] <kirkland> mdz: step 6 is about a 45 minute process
[22:27] <bluefoxicy> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[22:27] <bluefoxicy> and apport refuses to report it
[22:32] <slangasek> why does apport refuse?
[22:33] <bluefoxicy> it said I had outdated libraries
[22:33] <bluefoxicy> so I ran apt-get update/upgrade
[22:33] <bluefoxicy> it doesn't bother telling me stuff crashed anymore
[22:33] <bluefoxicy> i.e. "This crashed because it's out of date" and when I update it it doesn't care anymore because it's already decided it's out of date.
[22:34] <slangasek> did it crash again while you were up-to-date?
[22:34] <bluefoxicy> yes
[22:34] <ScottK> My favorites are the crashes during the process of updating that can't be reported because you are out of date
[22:46] <kirkland> mdz: arg
[22:47] <kirkland> mdz: i think i'm confirming ttx's "instance don't run" bug
[22:47] <kirkland> troubleshooting now
[22:47] <kirkland> mdz: i notice that you didn't upstart the eucalyptus-nc job... any reason why?
[23:18] <slangasek> Keybuk: hrm, you stomped on my upstart changes in the bzr repo
[23:18] <Keybuk> I did?
[23:18] <Keybuk> bzr has totally fucked up that repo
[23:18] <Keybuk> so it's entirely possible that your changes were never committed
[23:18] <slangasek> ok
[23:18]  * slangasek re-pushes
[23:19] <Keybuk> you can't even branch it via the smart-server right now
[23:19] <slangasek> ah, yay
[23:19] <Keybuk> what's your local revno?
[23:19] <Keybuk> (pre-merge)
[23:19] <slangasek> 1224
[23:20] <Keybuk> right, so your change never made it into lp
[23:20] <slangasek> it's let me push without warnings
[23:20] <Keybuk> yeah it does
[23:20] <slangasek> that's interesting, I see linear history here that shows your change on top of mine :)
[23:20] <Keybuk> on top?
[23:20] <slangasek> do you get my changes w/ bzr pull?
[23:20] <Keybuk> that's weird
[23:20] <Keybuk> bzr pull from you duplicates your change twice into the log
[23:21] <lifeless> add nosmart+
[23:21] <slangasek> yeah, the "telinit q" change shows up as a descendent of my last commit
[23:21] <lifeless> or prefix rather
[23:21] <slangasek> nosmart+bzr+ssh?
[23:21] <Keybuk> lifeless: your revision control system is making me cry
[23:21] <lifeless> slangasek: yes; bug filed on it this morning
[23:21] <lifeless> Keybuk: I'm sorry!
[23:21] <Keybuk> ;)
[23:23] <Keybuk> it's ok
[23:23] <Keybuk> I'm sure it's really an Upstart bug
[23:23] <Keybuk> everything else is ;)
[23:23] <lifeless> :)
[23:27] <slangasek> Keybuk: oh, another case broken by dh_installinit not providing /etc/init.d/ symlinks for native jobs - third-party packages that rely on restarting services for key library upgrades using invoke-rc.d...
[23:27] <Keybuk> how does that break?
[23:27] <Keybuk> if they weren't there before, they won't be looking for them
[23:27] <mdz> kirkland, I couldn't test -nc at all, I left it alone
[23:27] <slangasek> Keybuk: oh right
[23:27] <slangasek> Keybuk: just breaks my brain then, nothing to see here
[23:27] <Keybuk> :D
[23:30] <kirkland> mdz: i'm still fighting it
[23:30] <kirkland> mdz: RESERVATION     r-39720716      admin   default
[23:30] <kirkland> INSTANCE        i-38A7070E      emi-D5871527    192.168.0.250   172.19.1.2      pending         mykey   0       m1.xlarge
[23:30] <kirkland> 2009-09-30T22:27:50.269Z        canyonedge      eki-8F0A139D    eri-E64F14E8
[23:30] <kirkland> mdz: i can make the reservation
[23:30] <mdz> kirkland, but the instance never starts up?
[23:30] <kirkland> mdz: and I can see the nc trying to spin it up
[23:30] <kirkland> mdz: i waited 30 minutes last time
[23:30] <kirkland> mdz: no good
[23:32] <slangasek> Keybuk: so wrt portmap / nfs-common... what's the correct stop policy to be setting here?
[23:33] <slangasek> is there a particular teardown upstart job for unmounting remote filesystems that we should use?
[23:34] <slangasek> (and is there not a way to express "always start this job first when I've asked to start that job", that's honored for sysadmin-started jobs?)
[23:38] <Keybuk> no & no
[23:38] <Keybuk> but we can invent one ;)
[23:38] <slangasek> Keybuk: mmk :)
[23:38] <slangasek> Keybuk: yet another question... I have a task that is a dependency of other jobs, but it really should only be run *if* those other jobs are being started... :)
[23:39] <Keybuk> that's quite easy
[23:39] <slangasek> I could just run it twice in each job, I guess, but I was trying to remove that duplication
[23:39] <Keybuk> start on starting
[23:39] <Keybuk> stop on stopped
[23:39] <slangasek> oh
[23:39] <Keybuk> a service can insert itself as the dependency of another service that way
[23:39] <Keybuk> e.g.
[23:39] <Keybuk> bunny:
[23:39] <slangasek> ok, cool
[23:40] <Keybuk>   start on starting pie
[23:40] <Keybuk>   stop on stopped pie
[23:40] <Keybuk> then
[23:40] <Keybuk> start pie
[23:40] <Keybuk> will first start bunny, wait for bunny to be started, and then start pie
[23:40] <Keybuk> likewise if you stop pie, once pie has stopped, bunny would be stopped
[23:42] <cjwatson> which indeed is more or less how usplash does it
[23:42] <cjwatson> except with that custom event
[23:42] <Keybuk> right
[23:42] <Keybuk> it might be nice to get those custom events hardwired into upstart in some interesting way
[23:42] <Keybuk> so you don't have to jump through hoops
[23:42] <cjwatson> maybe. OTOH it's a good demonstration of custom events? :)
[23:42] <cjwatson> or is that not what you meant?
[23:43] <Keybuk> I mean making it easy to add custom events to jobs that effectively replace things like starting
[23:43] <Keybuk> adding information
[23:43] <Keybuk> "provides" I guess is what I mean
[23:44] <cjwatson> oh, this reminds me, in the usplash-down job I couldn't find a way to tell what runlevel it's in when it notices gdm being stopped, short of actually calling runlevel
[23:44] <cjwatson> I wanted to distinguish "somebody ran 'stop gdm'" from "system shutdown", but there was no RUNLEVEL key in the stopped environment
[23:44] <cjwatson> was I missing something obvious?
[23:46] <Keybuk> do you do stop on runlevel?
[23:46] <cjwatson> no, 'start on (stopped gdm or stopped kdm or stopped xdm)'
[23:46] <cjwatson> (dunno why I bothered to include xdm there)
[23:47] <cjwatson> it does explicitly need to stop after X has handed the console back at the moment, I believe
[23:47] <cjwatson> I'm pretty sure just stop on runlevel would break racily
[23:47] <cjwatson> certainly, pre-upstart, running usplash_down before gdm stop broke
[23:55] <slangasek> Keybuk: oh argh, 'status' returns a pid when the job is stopped?  how unintuitive
[23:56]  * slangasek thinks upstart-job is completely broken right now, then
[23:56] <Keybuk> slangasek: varies
[23:57] <Keybuk> cjwatson: right, so you have no $RUNLEVEL environment because none of that infers a runlevel ;)
[23:57] <Keybuk> slangasek: if the job is being stopped, but isn't yet stopped, it'll still return a pid
[23:57] <Keybuk> ie. the pid is still in ps
[23:57] <Keybuk> if the job has a post-stop script, it'll return that pid too
[23:57] <slangasek> Keybuk: oh, then I found an upstart bug ;)
[23:57] <Keybuk> it does tell you in detail which pid it's returning
[23:57] <Keybuk> in a machine-parseable form
[23:57] <Keybuk> slangasek: oh?
[23:58] <slangasek> Keybuk: the pid it's returned isn't there
[23:58] <slangasek> gssd stop/killed, process 20582
[23:58] <slangasek> $ ps 20582
[23:58] <slangasek>   PID TTY      STAT   TIME COMMAND
[23:58] <slangasek> $
[23:58] <Keybuk> and it's stuck in that state?
[23:58] <Keybuk> are you using "export fork" or "export daemon" ?
[23:58] <Keybuk> err, expect
[23:58] <slangasek> expect fork
[23:59] <Keybuk> ok, that's odd then
[23:59] <Keybuk> usually daemon can produce that particular bug
[23:59] <slangasek> (what's the difference between the two?)
[23:59] <Keybuk> expect fork expects one fork()
[23:59] <slangasek> yeah, it's stuck in that state, can't start it with start
[23:59] <Keybuk> expect daemon expects two
[23:59] <Keybuk> slangasek: weird, that implies that upstart didn't get the SIGCHLD
[23:59] <Keybuk> don't suppose you can replicate that with initctl log-priority debug set?