[00:03] <seb128> slangasek, I've uploaded a new gdm revision with a 2 liners bug fix from brastche
[00:03] <seb128> bratsche
[00:05] <ebroder> Does anybody know why preseeding the Hardy installer with lilo-installer/skip=true isn't working?
[00:21] <tedg> slangasek: Next release :)
[00:26] <kees> pitti: what's the state of apport in Fedora?  I was approached today by a SUSE dev who was interested in it for them as well.
[00:30] <dtchen> jdstrand: / ajmitch: ping, please update your jack-sense bugs when you have a chance. the upstream merge window is very quickly closing.
[00:34] <ajmitch> dtchen: sorry to not catch up with you, I've had problems getting it built
[00:36] <dtchen> ajmitch: where is it ftbfs?
[00:36] <ajmitch> at one point it was in that patch, but subsequent updates from the tree had it failing in other places
[00:37] <ajmitch> I expect that I'm not building the kernel properly
[00:37] <dtchen> ok, i'll take a look at it this weekend
[00:37] <dtchen> in the meantime, can you try with just enable_msi=1?
[00:37] <dtchen> (with whichever Karmic kernel you have access to)
[00:37] <ajmitch> I'll give that a try
[00:45] <dtchen> ajmitch: e.g., sudo /sbin/alsa force-unload && sudo modprobe snd-hda-intel enable_msi=1
[00:46] <ajmitch> dtchen: bad news is that doesn't change anything
[00:46] <dtchen> only in way.
[00:47] <dtchen> good news is that it's already fixed, but you likely need an msi whitelist addition in addition to the model quirk
[00:47] <ajmitch> ok
[00:47] <dtchen> more hacking on the plane, i suppose
[00:47] <ajmitch> do you need anything added to the bug report?
[00:47] <dtchen> not currently, thanks
[00:48] <mdz> slangasek, do you have buildd super powers?
[00:48] <slangasek> mdz: no, sorry
[00:48] <mdz> anyone around who does?
[00:48] <slangasek> kees: do you? ^^
[00:51] <kees> slangasek, mdz: no, sorry.  only the GSAs can get to the buildds, I think.
[00:51] <kees> mdz: check with lamont or pjdc
[00:51] <slangasek> there's the buildd group that lets people manage the build queues, I supposed that's what mdz was asking after
[00:51] <mdz> yes
[00:52] <mdz> I have a PPA build I'm urgently waiting on
[00:52] <kirkland> jono: http://www.youtube.com/watch?v=-0wc4LCSqHI
[00:53] <slangasek> mdz: btw, euca just finished publishing and the server ISO build is starting now
[00:54] <kees> mdz: I do have a non-virtual PPA, if you don't get your build priority sorted out; I could push a karmic PPA build through those if you need.
[00:54] <mdz> slangasek, thanks
[00:55] <maxb> kees: You could rescore the build for mdz too
[00:55] <maxb> :-)
[00:55] <kees> maxb: I don't think I have that ability.
[00:55] <kees> maxb: but if I do, please show me how.  :)
[00:56] <maxb> ~techboard is a member of ~launchpad-buildd-admins
[00:56]  * kees didn't realize he had new super powers, and goes looking
[00:56] <mdz> slangasek, FYI I have the next eucalyptus rev in a PPA right now and plan to hack up a server ISO to test it locally before uploading
[00:57] <maxb> Not that I've ever seen the UI myself, but I'd imagine if you find mdz's build there should be a link to allow you to edit its score
[00:57] <slangasek> mdz: ok
[00:57] <mdz> maxb, there used to be an obvious link for rescoring the build (I'm in techboard as well), but no longer
[00:57] <mdz> anyway, it's started now
[01:04] <slangasek> mdz, kirkland: http://cdimage.ubuntu.com/ubuntu-server/daily/20090925/
[01:05] <kirkland> slangasek: cool, thanks
[01:06] <kirkland> mdz: this is what i'm working with: https://help.ubuntu.com/community/Eucalyptus
[01:06] <kirkland> mdz: but it's very dated (jaunty era)
[01:12] <kirkland> mdz: update -> http://open.eucalyptus.com/wiki/EucalyptusAdministratorGuide_v1.6
[01:13] <mdz> slangasek, can you give me the magic mkisofs options for the official isos?
[01:14] <slangasek> mdz: hrm, digging through the debian-cd config
[01:16] <slangasek> mdz: eh, easier to get it by grepping the log file... pastebinning
[01:16] <slangasek> mdz: http://paste.ubuntu.com/277507/
[01:18] <mdz> slangasek, thanks
[01:19] <mdz> slangasek, sorry, I should have specified amd64
[01:19] <slangasek> mdz: ah, grabbing
[01:19] <slangasek> mdz: here: http://paste.ubuntu.com/277509/
[01:21] <mdz> slangasek, what is boot1?
[01:22] <slangasek> mdz: directory containing the bits that debian-cd puts together for the bootloader...
[01:22] <mdz> slangasek, hmm, I don't remember needing that in the past
[01:23] <mdz> I assume the contents end up in the iso and the ones there will work fine
[01:23] <slangasek> mdz: correct - it's the contents of the isolinux subdir
[01:25] <mdz> slangasek, hmm, it's not cooperating
[01:25] <mdz> genisoimage -r -V Ubuntu-Server\ 9.10\ amd64 -o karmic-server-amd64+plumbers.raw -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /media/cdrom
[01:25] <mdz> I: -input-charset not specified, using utf-8 (detected in locale settings)
[01:25] <mdz> genisoimage: Uh oh, I cant find the boot catalog directory 'isolinux'!
[01:26] <mdz>  /media/cdrom/isolinux exists and contains the usual assortment
[01:32] <slangasek> mdz: mm - really don't know :(
[01:32] <slangasek> mdz: I trust debian-cd to get this right for me
[01:35] <slangasek> mdz: I guess the first thing I would try would be to split the boot stuff out into a separate parent directory and build it the same way debian-cd does (boot1/ CD1/ )
[01:38] <mdz> slangasek, I'm pretty sure it just reads each pathspec in turn, that the first one isn't special
[01:39] <mdz> I'm also using genisoimage rather than mkisofs, because it's what I have here
[01:39] <mdz> and I'm using the karmic version
[01:40] <mdz> strace doesn't even show it reading in the directory
[01:42] <mdz> I wonder if it's simply broken
[01:44] <mdz> slangasek, arrgh, it chokes if the pathspec is a symlink
[01:51] <jono_> jcastro, so Bill has VT capable hardware to test?
[01:51] <jcastro> he's joining in a sec
[01:52] <jcastro> WildBill: ok so you have kvm-capable hardware right?
[01:52] <WildBill> a couple of pieces of gear, yeah
[01:52] <WildBill> laptops mostly LOL
[01:52] <WildBill> but yeah
[01:52] <WildBill> dual core, 2GB RAM
[01:53] <jcastro> jono_: ^
[01:53] <jono_> awesome
[01:53] <jono_> thanks WildBill
[01:53] <WildBill> thank me when we're done LOL
[01:53] <WildBill> it'll be fun tho :)
[01:54] <jono_> WildBill, keep an eye on http://testcases.qa.ubuntu.com/System/Eucalyptus for updates
[01:54] <jono_> WildBill, kirkland is going to add further test instructions there when he is done
[01:54] <WildBill> oh damn, that looks easier than the other stuff I was reading :)
[01:55] <jcastro> WildBill: oh don't worry, this is in addition to
[01:55] <kirkland> WildBill: oh, that's the easy part
[01:56] <WildBill> haha yeah
[02:01] <WildBill> so when does this testing start?
[02:42] <jono> WildBill, they are still working on the ISOs
[03:08] <TheMuso> WildBill: The testing won't start till next week, at least for the beta isos that is.
[03:13] <ScislaC> This is related to development, and just a curiosity... Why does it seem to take substantially longer for the changelogs to be available compared to the packages? (I'm always running a +1 version of Ubuntu, so I've noticed this for a long time)
[03:16] <wgrant> ScislaC: The changelogs are only extracted every few hours, by a process completely separate from the package publishing.
[03:18] <ScislaC> wgrant: ahhh! Is the any reason why they are pulled like that as opposed to being pushed when the builds complete successfully? (not trying to say I know better, just wondering)
[03:19] <wgrant> ScislaC: Not really. They should eventually be extracted by Launchpad once the build completes and made available immediately, but that's not done yet.
[03:20] <ScislaC> wgrant: gotcha... thanks for the info! :)
[04:51] <trip0> so starting jaunty from startx in tty1, the 90consolekit script runs, but my session active = FALSE
[04:51] <trip0> will this still be a problem in karmic?
[05:00] <TheMuso> c
[05:03] <trip0> :(
[06:05] <Keybuk> one day, I'd like to travel *without* either my home DSL, mail server or laptop hard drive dying
[06:07] <liw> should be possible to manage that for one day, perhaps two, but that's not enough time to get very far
[06:36] <Keybuk> yup
[06:36] <Keybuk> my laptop has the unmistakable "click of death"
[06:41] <lifeless> :(
[06:55] <Keybuk> it's all evan's fault
[06:57] <pitti> Good morning
[06:57] <pitti> kees: I didn't hear from Fedora about Apport for a long time; seems they don't like it
[07:04] <jussi01> jcastro: is there some way to confirm UDS applications have gone through?
[07:15] <Keybuk> pitti: aren't they NIHing it?
[07:15] <pitti> Keybuk: Lennart once wrote a script which intercepts core dumps, yes
[07:16] <pitti> but I have no idea how far that got; I just commented on his blog post
[07:16] <pitti> clarifying that apport is FOSS (there were rumours that it's some proprietary code on Canonical's server..)
[07:19] <Keybuk> whose blog post?
[07:20] <pitti> Keybuk: http://0pointer.de/blog/projects/automatic-backtrace.html
[07:21] <Keybuk> right, that was quite a while ago now
[07:22] <pitti> therefore "didn't hear something for a while"
[07:22] <Keybuk> http://fedoraproject.org/wiki/Features/CrashHandling
[07:22] <Keybuk> yes
[07:22] <Keybuk> Fedora plan to NIH apport
[07:23] <Keybuk> also http://fedoraproject.org/wiki/Features/CrashCatcher
[07:24] <TheMuso> nih?
[07:24] <ttx> TheMuso: not-invented-here. In this context I suppose they want to reinvent it just because we wrote it
[07:24] <Keybuk> kinda
[07:24] <Keybuk> more because they *didn't* write it
[07:24] <TheMuso> Right.
[07:25] <Keybuk> RH/Fedora have a real problem with that
[07:25] <TheMuso> Don't they just.
[07:26] <Keybuk> like the time they included screenshots of an Ubuntu tool in their Features/ wiki page, with the comments "make it look and work like this tool in Ubuntu":
[07:43] <pitti> ooh, apparmor in the queue -- I can haz network in live system again?
[08:47] <dpm> pitti: hi, good morning! we currently don't have a way in LP translations of tracking which packages are promoted to main or demoted, and we often find out quite late in the cycle that e.g. we have to disable templates of demoted packages. Do you know if there is a place where MIR or demotions can be tracked, so we can have a look at it?
[08:48] <pitti> dpm: hm, tricky; there's no log of demotions, since they by and large "just happen" when some archve admin cleans up component-mismatches
[08:48] <pitti> dpm: for promotions most packages go through the MIR process, so the ~ubuntu-mir bugs tell them
[08:49] <pitti> dpm: but I think it'd be easier to periodically run a script which compares the packages which Rosetta thinks are in main, and which are actually in main
[08:52] <dpm> pitti: sounds like a good idea, thanks. Which do you think would be the best way to find out which packages are in main?
[08:54] <pitti> dpm: how about
[08:54] <pitti> wget -O - http://archive.ubuntu.com/ubuntu/dists/karmic/main/source/Sources.gz | zgrep ^Package: | cut -f2 -d' '
[08:57] <pitti> dpm: That's the fastest way I know of if you have network
[08:58] <dpm> fantastic, thanks a lot, pitti
[09:13] <cjwatson> ebroder: there's a changelog entry in lilo-installer after hardy indicating that it was fixed; you might want to look at the changelog and chase the bug reference there
[09:16] <cjwatson> TheMuso: testing (your reply to WildBill): this is a special effort to get eucalyptus testing earlier than the beta ISOs
[09:19] <cjwatson> dpm: FWIW if you're doing anything more complicated with Packages or Sources files than that zgrep | cut of pitti's, you'd be well-advised to look at grep-dctrl
[09:22] <dpm> cjwatson: thanks a lot for the info, I didn't know about it and I'm sure it'll be very useful
[09:30] <tseliot> pitti: I think bug #428662 is really a duplicate of bug #364508 however the former seems more specific to karmic while the latter is also about jaunty
[09:30] <pitti> tseliot: oh, it sounded as if it was a recent regression
[09:30] <tseliot> pitti: the upstream report is recent
[09:31] <tseliot> hmm
[09:31] <tseliot> pitti: either way a fix is available :-)
[09:31] <pitti> oooh!
[09:32] <Riddelll> ooh?
[09:32] <lool> pitti: Would you mind kicking moblin-remix-meta out of NEW please?  It was ETARGET   :-(
[09:32] <tseliot> :-)
[09:32] <pitti> lool: you mean "reject"?
[09:32] <lool> Yeah
[09:32] <lool> delete, burn, whatever  :-)
[09:33]  * pitti makes a flush noise
[09:33] <lool> pitti: thanks
[09:33] <lool> pitti: wash your hands
[09:33] <pitti> tseliot: fix to intel, or a workaround in kdm?
[09:33] <tseliot> pitti: a proper fix in the -intel driver
[09:33] <pitti> lool: soyuz is sterile!
[09:33] <pitti> it has no bugz
[09:33] <pitti> tseliot: rockin'
[09:34] <tseliot> :-)
[09:34] <pitti> tseliot: does the fix look harmless enough for beta? or very intrusive?
[09:35] <tseliot> pitti: either we upgrade to the latest driver (we're discussing this with upstream) or I could backport the fix (if possible)
[09:42] <tseliot> pitti: it looks like the fix is trivial to port
[09:57] <pitti> great
[10:01] <geser> metacity --replace
[10:02] <pitti> geser.fix_focus()
[10:09] <geser> pitti: it's hard to type into the right window when you can't see anything (was trying out gnome-shell)
[10:16] <chrisccoulson> geser - so gnome-shell is working well for you then? ;)
[10:17] <geser> chrisccoulson: if you count a black distorted screen to it, then yes
[10:18] <chrisccoulson> heh. i tried it a few days ago as well. i think i probably had a bit more success than that, but it is unbearably slow on my factory-overclocked nvidia 8800gt, which is somewhat surprising
[10:20] <sebner> geser: gnome-shell ftw!
[10:21] <geser> chrisccoulson: does it need 3d acceleration? because I only use the 2d radeon driver and not fglrx
[10:21] <sebner> chrisccoulson: I think that's a driver issue. I can use it (no games though) without problems. glxgears shows me 3-4 times less frames
[10:21] <sebner> geser: imho yes
[10:21] <chrisccoulson> geser - yes, it needs 3d
[10:21] <chrisccoulson> there is no fallback with clutter unfortunately
[10:22] <chrisccoulson> there's been a lot of discussion about this upstream, as a few people disagree with the decision not to include a fallback
[10:22] <chrisccoulson> apparently, the "fallback" will be gnome-panel and metacity;)
[10:23] <sebner> chrisccoulson: haha, how long is the question
[10:24] <geser> at least there will be a fallback for those without 3d or with old hardware (perhaps it's time I switch to fglrx finally)
[10:24] <sebner> geser: FLOSS ftw! but yes, change
[10:24] <sebner> ^^
[10:25] <cjwatson> ArneGoetje: sorry for the delay, replied to you on -devel now
[10:26] <chrisccoulson> sebner / geser - if you're interested in reading about the discussion, it is here: http://www.mail-archive.com/desktop-devel-list@gnome.org/msg15609.html
[10:27] <sebner> chrisccoulson: cool, thx
[10:37] <geser> lool: it should be safe now to give-back cheetah on ia64 to resolve the upload error (as the source in now published in main (and not pending anymore))
[10:38] <lool> geser: thanks
[10:38] <lool> geser: Did you confirm this with bigjools?
[10:39] <geser> lool: no, but I've seen this error several times already and it was always because the source package got promoted at the same time
[10:40] <wgrant> That's right.
[10:40] <wgrant> A give-back after the subsequent publisher run will work fine.
[10:40] <wgrant> The important bit is that the old one is Superseded, not that the new one is Published, although those generally happen at the same time.
[10:40] <lool> geser, wgrant: thanks given back
[10:40] <YokoZar> If I still have audio problems in karmic should I ubuntu-bug alsa-base or pulseaudio?
[11:11] <sladen> welcome to emo-os
[11:14] <highvoltage> hmm, GDM only starts now if you have a working Internet connection when it starts :)
[11:17] <Riddelll> mvo: "AttributeError: 'DistUpgradeQuirks' object has no attribute '_killKBluetooth'
[11:17] <Riddelll> crash in DistUpgrade tool
[11:18] <Riddelll> http://paste.ubuntu.com:80/277786/
[12:07] <mvo> Riddell: thanks, fixing now (and sorry)
[12:18] <sgallagh> mathiaz: I just wanted to give you a heads-up that some major changes are going to be rolling into the SSSD today, in time for our 0.6.0 release. They change the format of the configuration file, but we're also shipping an upgrade script in the tarball, so you may want to roll that into whatever .deb has as a post-install section.
[12:25] <YokoZar> Have most of the games been removed by default?
[12:54] <jdstrand> dtchen: hi. I (finally) tested the patches you asked me to test in bug #400682
[12:54] <jdstrand> dtchen: I updated the bug, but in summary, it FTBFS
[13:04] <MacSlow> tseliot, was there an update to some nvidia-glx-185 (or related package) between yesterday or today?
[13:05] <MacSlow> kenvandine, seb128: Was there an update to libwnck between yesterday and today?
[13:05] <Amaranth> MacSlow: What exploded? :)
[13:06] <MacSlow> Amaranth, hey Travis
[13:06] <Amaranth> howdy
[13:07] <MacSlow> Amaranth, notify-osd causes libwnck assertions and thus failing to display any notification bubbles if I run my setup with two LCDs... yesterday everything was smooth as silk
[13:07] <Amaranth> there was a compiz update
[13:07] <Amaranth> shouldn't have affected anything like that though
[13:09] <MacSlow> Amaranth, not compiz-related I think.. the issue also occurs under metacity (without compositor)
[13:09] <Amaranth> MacSlow: libwnck hasn't been updated since the 22nd and nvidia-glx-185 hasn't been updated since august
[13:09] <MacSlow> gee... what bloody side-effect is hitting me here then I wonder
[13:20] <seb128> MacSlow, no
[13:21] <seb128> it didn't change for weeks
[13:21] <seb128> the recent update was translations only
[13:21] <MacSlow> seb128, somehow a bug was triggered between yesterday and today on my nvidia-based system causing bubbles to no longer appear in a dual-LCD setup
[13:22] <MacSlow> seb128, disabling the second lcd got the rendering back in order again
[13:23] <MacSlow> seb128, dual-LCDs on my nvidia-box worked with notify-osd for months before (even under karmic until this morning)
[13:23] <soren> bubbles?
[13:23] <seb128> soren, how do you call notification rectangles with text?
[13:24] <seb128> soren, it's usually called bubble
[13:24] <soren> Oh, those!
[13:24] <soren> :)
[13:24] <seb128> soren, yes ;-)
[13:24] <soren> I thought this was some sort of compiz effect like the wobbly windows or whatnot :)
[13:24] <MacSlow> soren, the term "bubble" is not official though
[13:25] <MacSlow> soren, just wanted something to differentiate from notifications rendered by notification-daemon
[13:26] <soren> MacSlow: Sure, sure, I follow you now. My mind was elsewhere :)
[13:26] <MacSlow> soren, that's why sometime during the jaunty cycle I refered to them as bubbles
[13:27] <MacSlow> notification-rendition would be the more fitting term I guess
[13:27] <Ng> empathy calls them "bubble notifications", gwibber calls them bubbles ;)
[13:27] <MacSlow> but such long terms are very inconvenient
[13:28] <MacSlow> hey ng
[13:29] <Ng> hey :)
[13:31] <jcastro> jussi01: pm me your name and i can check the system
[13:34] <cjwatson> anyone happen to know why today's desktop CD doesn't automatically switch to vt7?
[13:55] <james_w> anybody else seen anything like bug 436590?
[13:56] <james_w> I guess it would be high priority if it affected more than just me
[13:56] <mvo> james_w: absolutely
[13:56] <mvo> james_w: is it still running?
[13:56] <james_w> yes
[13:57] <james_w> I can gather any information that you need
[13:57] <mvo> james_w: could you mail me the output of ps afx (or attach if it does not contain anything private)
[14:00] <james_w> mvo: mailed
[14:02] <mvo> james_w: thanks, I see if I can reproduce it here
[14:02] <james_w> mvo: great, thanks. I'm going to grab some lunch
[14:02] <james_w> mvo: when was the switch to aptd done?
[14:04] <james_w> oh, I forgot one thing
[14:04] <james_w> added to the bug
[14:06] <pitti> cjwatson: uh, confirmed here
[14:06] <mvo> james_w: was there debconf involved at any time (other than the message printed there)?
[14:07] <glatzor> Hello mvo and james_w, it seems that richard is now open to a conf file conflict and debconf integration into packagekit
[14:07] <james_w> mvo: no prompts, no conffile prompts, nothing
[14:07] <james_w> hello glatzor, I saw, nice work
[14:07] <pitti> cjwatson: the current CD has various problems due to Apparmor being active on the live system; but it seems a weird thing to be triggered by AppArmor..
[14:08] <seb128> pitti, the vt thing is not liveCD specific
[14:08] <james_w> pitti: does "ubuntu-bug <packagename>" do the version checks too?
[14:08] <seb128> I've read comments going on on bugs for some days
[14:08] <pitti> james_w: yes, same mechanics
[14:09] <seb128> but I've no clue about those and Keybuk seems to refuse looking at those and just point it's gdm issues without any clue of why
[14:09] <james_w> pitti: ok. Not ideal for reporting problems with upgrading, but I guess we don't need everyone to do that
[14:09] <mvo> glatzor: yeah, good stuff
[14:09] <pitti> james_w: don't you get automatic reports for that from apt?
[14:10] <james_w> pitti: well, not in this case, there aren't upgrade failures or crashes, I've got a hang in update-manager/aptdaemon
[14:11] <james_w> anyhow, we can manage
[14:12] <tseliot> pitti: are you affected by bug #428662 ?
[14:14] <seb128> pitti, any clue about bug #436515?
[14:18] <pitti> tseliot: no, it only seems to affect kdm
[14:18] <pitti> seb128: looking; missing lo?
[14:19] <seb128> pitti, I'm not sure, I was just wondering
[14:23] <tseliot> ok
[14:38] <hyperair> meh. what does one do when dpkg gets corrupted?
[14:38] <hyperair> is there a way to regenerate the metadata?
[14:41] <hyperair> hmm.. what's in /var/lib/dpkg/updates anyway?
[14:48] <huats> cjwatson: hi
[14:48] <cjwatson> hello?
[14:48] <huats> I've just seen the bug you report on the python webkit binding
[14:48] <huats> (I am the current debian maintener)
[14:48] <cjwatson> that was quick!
[14:48] <huats> :)
[14:49] <huats> I am subscribed to it :)
[14:49] <huats> what can I do to help out ?
[14:49] <hyperair> Kmos: thanks.
[14:49] <cjwatson> well, there's a test case on the bug
[14:49] <cjwatson> the package with the data in it is Ubuntu-specific, but it has no dependencies so it should be easy to install
[14:49] <huats> ok
[14:50] <huats> cjwatson: I know that it is ubuntu specific (I am also a motu :))
[14:50] <cjwatson> I got it to the point where as far as I could see it wasn't a bug in the calling script
[14:50] <cjwatson> but if that's a mistake, obviously feel free to reassign back with my apologies; I'd like to know what we're doing wrong if so, though
[14:50] <huats> I might be good to ask the upstream author about it
[14:50] <huats> he is usually very quick to aswer
[14:50] <huats> answer
[14:51] <smoser> james_w, i think i understand why this is the case, but just wanted to let you know its at least annoying.  http://paste.ubuntu.com/277965/
[14:52] <huats> cjwatson: it might be great also to test that against the new upstream release
[14:52] <huats> I'll try to do that this weekend
[14:52] <huats> I'll let you know before monday
[14:53] <directhex> hmph. i still get funny messages about init on shutdown. i heard rumours of a shutdown splash screen! :(
[14:59] <james_w> smoser: more than a little annoying as well
[15:03] <smoser> james_w, anything can be done ?
[15:03] <smoser> i can open a bug if need be
[15:04] <james_w> smoser: you either have to upgrade/downgrade one of the branches so that they match
[15:04] <james_w> or go through some painful machinations to avoid the default stacking
[15:04] <james_w> I think there is a bug already
[15:04] <smoser> well i can't change the ubuntu/ec2-init, right ?
[15:04] <smoser> so the only option is upgrading the other
[15:11] <james_w> smoser: you could ask soren to change that one, but it's probably easier to change yours
[15:12] <smoser> ah.. you mean downgrade mine ? how would i do that ?
[15:14] <james_w> you can do it using the upgrade command
[15:14] <james_w> "bzr upgrade --format"
[15:15] <james_w> --rich-root-pack is what you would want in this case it seems
[15:17] <smoser> thanks. i was just going to ask you how i de-coded KnitPackRepository to something that --format would like
[15:18] <smoser> james_w, :-( it tells me i can't do that.
[15:18] <smoser> bzr: ERROR: Cannot convert from format Branch format 7 to format <class 'bzrlib.branch.BzrBranchFormat6'>.    No converter
[15:18] <james_w> really?
[15:18] <james_w> man
[15:18] <smoser> well i didn't just make up that error :)
[15:18] <james_w> ok, let's try and trick it
[15:18] <smoser> or if i did, it was convincing wasn't it
[15:18] <james_w> well, it's pretty convincing if you did :-)
[15:19] <james_w> bzr init-repo --rich-root-pack /tmp/testrepo
[15:19] <james_w> bzr init  /tmp/testrepo/trunk
[15:19] <james_w> bzr pull -d /tmp/testrepo/trunk .
[15:20] <james_w> that will create a repository in the desired format, and then try and pull all the data in to it
[15:22] <smoser> hm.. i think i'm missing something.
[15:22] <smoser> what dir should i be in to start that?
[15:24] <james_w> the branch you are trying to push
[15:24] <james_w> "bzr pull -d /tmp/testrepo/trunk ." means pull . from /tmp/testrepo...
[15:24] <james_w> you can cd and bzr pull the path to your current branch instead if you like
[15:25] <smoser> hm... i think it worked.
[15:32] <james_w> who promoted libgnumail-java-doc?
[15:32] <pitti> james_w: me, on error; I put it back to universe
[15:33] <pitti> since it sucks in classpath
[15:33] <james_w> thanks
[15:33] <pitti> we should instead blacklist it in the seeds or so
[15:33] <james_w> I thought I was going crazy
[15:33] <cjwatson> (extra-exclude is what you want)
[15:33] <james_w> that's twice I demoted and it came back
[15:33] <james_w> pitti: what tries to pull it in?
[15:33] <pitti> james_w: it seemed like a simple thing at first (like the other -doc and -dbg that turn up all the time), I checked classpath too late; sorry
[15:34] <pitti> james_w: there's a general seed rule to "rescue" *-dbg and *-doc
[15:34] <james_w> ah
[15:34] <pitti> so that we dno't have to explicitly seed the million -dev/-doc packages for main sources
[15:34] <james_w> clever
[15:35] <pitti> cjwatson: in "supported" for all derivatives, right?
[15:35] <cjwatson> yes :-/
[15:35] <soren> smoser: So you managed to push it in a format I can merge frm?
[15:35] <smoser> james_w, thanks for your help... i dont think it all worked perfectly, as i tried to reproduce but failed.
[15:35] <smoser> soren, i think so.
[15:35] <soren> smoser: Where?
[15:36] <smoser> soren, if not, i'll just manually cherry pick
[15:36] <pitti> james_w: doing the seed changes now
[15:36]  * james_w hugs pitti 
[15:36] <smoser> soren, oh. wait. i hadn't done that yet. let me try
[15:36] <soren> smoser: Where did you push it to?
[15:36] <soren> smoser: Cool, thanks.
[15:37] <pitti> cjwatson: out of interest, why doesn't that work in platform.karmic/supported-common?
[15:37] <soren> smoser: Oh, did you base this on the ubuntu package branch of the ec2-init trunk?
[15:38] <smoser> right
[15:38] <smoser> wait
[15:38] <cjwatson> pitti: it probably could be made to but I haven't tried. check it with germinate if you do
[15:38] <smoser> i started from lp:ubuntu/ec2-init
[15:38] <soren> smoser: Ah, ok.
[15:38] <smoser> is that ok ?
[15:38] <soren> I'm.... not sure.
[15:39] <soren> james_w: Ok, here's the thing..
[15:39] <soren> james_w: I maintain ec2-init in bzr.
[15:39] <soren> james_w: smoser wanted to patch a few things, grabbed the lp:ubuntu/ec2-init branch and made some changes.
[15:39] <soren> james_w: I like the changes, so I want them in the ec2-init trunk.
[15:39] <soren> james_w: What's the magic incantation here?
[15:40] <soren> james_w: If I just try to merge it, it tells me there are no common ancestors.
[15:55] <james_w> soren: yeah, there aren't. It's one of the unfortunate things about the lp:ubuntu/* branches.
[15:56] <james_w> making each of them mergeable with their respective upstream branches is a lot of work, so we deferred that part until later
[15:56] <soren> james_w: There aren't common ancestors or there aren't a way to do this?
[15:56] <soren> I understand the former, fwiw.
[15:56] <mdz> soren, you can't merge them, but you can certainly get the changes from one place to the other. it is just extra work
[15:56] <james_w> if you cherrypick it should work
[15:57] <james_w> oh, no it won't
[15:57] <james_w> the file-ids differ
[15:57] <soren> mdz: Like "bzr log -c revno -p" or some such?
[15:57] <james_w> it's diff and patch I'm afraid
[15:57] <soren> mdz: Or do you have something more clever up your sleeve?
[15:57] <mdz> soren, bzr diff -c revno | patch
[15:57] <soren> Right, exactly.
[15:57] <soren> That's about the same. :)
[15:57] <soren> Only my way gives me the original changelog entry, but meh.
[15:57] <soren> Ok.
[15:58] <mdz> the changelog will probably conflict
[15:58] <soren> mdz: Completely. The "upstream" branch has no debian/ dir.
[15:59] <soren> smoser: I guess the lesson is: If it is expected to be pushed upstream, branch off of the upstream branch and then work downwards from that.
[15:59] <soren> (/me hopes his directional metaphors make sense to other people)
[16:00] <soren> mdz: I see we have a namespace collision :) My "original changelog entry" referred to the bzr one. I presumed you were talking about the debian changelgo?
[16:01] <mdz> soren, I uploaded some (slightly sloppy) changes to eucalyptus overnight, and pushed them to what I guessed was the right branch
[16:01] <mdz> soren, (yes, I was talking about the debian changelog)
[16:01] <smoser> i'm somewhat bringing this up in #bzr... i started there with "how can i do what git-format-patch" and "git-am" do
[16:01] <mdz> soren, have you looked at the changes?
[16:01] <smoser> but of course, i was asked why i want to do that.
[16:02] <soren> mdz: I have not, no. I noticed a new upload, and assumed the changes in bzr were just those, but I guess not.
[16:04] <mdz> soren, the changes in bzr were just those, yes
[16:04] <mdz> soren, or intended to be
[16:04] <mdz> soren, I didn't have time to figure out whatever cdbs patch system variant was in use and just patched directly in the diff
[16:05] <soren> mdz: You're not alone in doing so, fwiw.
[16:05] <ttx> mdz: are you representing the server team in the release meeting or should I ?
[16:05] <cjwatson> mdz: I uploaded a package including your change to the main archive a moment ago
[16:06] <ttx> soren: I've been wondering about the rule to follow, then abandoned and did like the others
[16:06] <cjwatson> mdz: I have to say I was unconvinced about your change, though. I was told that the component name given to --register-* was advertised to remote machines, and thus that "localhost" would actually break
[16:06] <cjwatson> mdz: did you observe this not to be the case?
[16:06] <cjwatson> mdz: (fwiw, "what-patch" is really handy to determine the patch system in use"
[16:06] <cjwatson> )
[16:07] <mathiaz> sgallagh: hi! Thanks for the notice
[16:07] <mdz> cjwatson, in this particular case, we are registering walrus to the CC, and they are both running on the same system, which is why we are using "localhost"
[16:07] <mathiaz> sgallagh: We won't upgrade sssd to 0.6.0 for karmic - this is probably work for lucid (the next version)
[16:07] <mdz> cjwatson, the code forbade using "localhost" in all cases, even that one (which was working fine)
[16:08]  * ttx scrambles to update ServerTeam/ReleaseStatus
[16:10] <cjwatson> mdz,ttx: do we need to address bug 430841 for beta? I haven't noticed it being a problem in recent test passes
[16:10] <ttx> cjwatson: I didn't walk into that one either
[16:11] <ttx> but it's not targeted to beta (as of 30 minutes ago)
[16:40] <ion> mterry: Hi. Please see bug #436323.
[16:41] <ion> mterry: Hi. Please see bug #436323.
[16:41] <ion> Ah, no ubottu link this time. https://launchpad.net/bugs/436323 :-)
[16:45] <YokoZar> ok so nm-applet just crashed, taking my internet connection with it (or possibly the other way around) -- apport was unable to upload the report, but is there a way I can get it again now that I'm back online?
[16:46] <ion> apport-bug /var/crash/reportfile, or sudo touch /var/crash/reportfile
[16:46] <ion> Make sure you have the latest network-manager-gnome package.
[16:47] <YokoZar> ion: hmm it didn't like either of those commands
[16:47] <YokoZar> wait nevermind
[16:47] <YokoZar> mistyped
[16:48] <YokoZar> apport will check for the latest version of that stuff and won't let you submit if you're outdated
[16:48] <YokoZar> which is nice
[16:55] <mdz> pitti, I can't figure out how to request merging of https://code.edge.launchpad.net/~mdz/apport/ec2-uec into the apport ubuntu branch
[16:56] <pitti> mdz: "Propose for merging into another branch" doesn't work for you?
[16:56] <pitti> it does here
[16:56] <mdz> pitti, I don't know what to put in the box
[16:56] <mdz> searching for "apport" finds too many matches, and searching for "apport ubuntu" or "apport karmic" finds nothing
[16:56] <pitti> ah
[16:57] <pitti> interesting problem
[16:57] <mathiaz> slangasek: hi!
[16:57] <tkamppeter> pitti, hi
[16:57] <pitti> hey tkamppeter
[16:57] <mathiaz> slangasek: image-store-proxy failed to build
[16:57] <pitti> mdz: does lp:~ubuntu-core-dev/ubuntu/karmic/apport/ubuntu/ work?
[16:58] <mathiaz> slangasek: https://launchpad.net/ubuntu/+source/image-store-proxy/1.0-0ubuntu1/+build/1258941
[16:58] <dtchen> jdstrand: yes, i've got a fix for that ftbfs; just need to commit it
[16:58] <pitti> mdz: (_everyone_ can type that by heart without errors, right?)
[16:58] <dtchen> jdstrand: i'll ping sunday/monday for more testing
[16:58] <mathiaz> slangasek: I've got fix here (add gnupg to the build dependencies)
[16:58] <cjwatson> mdz: it may be (I'm not sure) that you can't request merge proposals from upstream branches to source package branches? in which case you'd need to push to ~mdz/ubuntu/karmic/apport/ec2-uec
[16:58] <slangasek> mathiaz: then I think you should upload it? :)
[16:58] <tkamppeter> pitti, I have done some fixes on s-c-p this week and they introduced bug 435740 and bug 436218. I have fixed these bug with very simple patches. Should these fixes go into the beta?
[16:58] <cjwatson> probably best to stay in the same namespace if possible anyway ...
[16:59] <mathiaz> slangasek: right - just warning you since the archive is frozen
[17:00] <mdz> pitti, that seemed to work, thank you
[17:00] <pitti> mdz: IMHO, "ubuntu" should just work; it should just look for apport branches with that name, not branches of all projects..
[17:01] <jdstrand> dtchen: ok
[17:01] <jdstrand> dtchen: thanks
[17:02] <pitti> mdz: btw, get_version() throws a ValueError for uninstalled packages
[17:02] <seb128> slangasek, the locking issue is bug #428115?
[17:02] <pitti> or, at least, it's supposed to
[17:02] <pitti> mdz: but I can fix that when merging
[17:02] <seb128> slangasek, can you get specifics? gnome-session and indicator-session should be fixed in current karmic
[17:02] <mdz> pitti, oh, sorry about that
[17:02] <seb128> slangasek, if you still get the issue
[17:02] <mdz> pitti, a simple is_installed check would be handy I think, maybe I should add that to hookutils?
[17:03] <pitti> mdz: it could just go to apport/packaging.py, as a convenience method, indeed
[17:04] <jml> cjwatson, hmmm.
[17:05] <jml> cjwatson, I thought you could do that. I could be wrong though.
[17:06] <jml> sometimes I think really loudly about a thing like that and believe that I did it.
[17:06] <cjwatson> it was wild speculation based on mdz's reported problem :)
[17:07] <cjwatson> but it sounds like he could make the merge proposal after all, it just didn't show up in the search ...
[17:08] <mdz> jml, figuring out how to submit that merge request was really hard :-/
[17:08] <jml> mdz, I'm sorry to hear that!
[17:10] <jml> cjwatson, oh yeah, the "select a branch" widget is terrible.
[17:10] <jml> beuno & I are advocating that we do less features in order to start cleaning up crap like that.
[17:11] <pitti> tkamppeter: pleasea just upload it, we'll review it from the queue; if they are safe patches, they are fine to get into the beta
[17:13] <cjwatson> jml: do less features> amen, in both our projects
[17:23] <YokoZar> Does this https://bugzilla.gnome.org/show_bug.cgi?id=588733  count as a UI freeze nono ?
[17:23] <YokoZar> https://bugs.launchpad.net/ubuntu/+source/wine/+bug/223989  rather
[17:25] <cjwatson> (better late than never)
[17:25] <smoser> generic launchpad question
[17:37] <smoser> a general launchpad/bug question
[17:37] <smoser> bug 423497
[17:38] <smoser> it has vmbuilder task and ubuntu/vm-builder task
[17:38] <smoser> it is fixed in vmbuilder upstream (the vmbuilder task), but that fix has not made it into a bundled release (only in bzr)
[17:39] <smoser> so i think fix-commited is the right state for it
[17:39] <smoser> what state should the ubuntu/vm-builder task be in ?
[17:40] <pitti> smoser: usually, if a suitable fix is available, I set my bugs to "fix committed"
[17:40] <sistpoty|work> it *should* be fix released :P
[17:40] <pitti> it's a bit overloaded with "actually pushed the fix to my packaging branch", though
[17:41] <smoser> pitti, thanks. sistpoty|work i'll work on that
[17:41] <sistpoty|work> :)
[17:45] <tkamppeter> pitti, new s-c-p uploaded, bug 435740 and bug 436218 updated.
[17:47] <zul> can someone approve the ec2-init I just uploaded? thanks
[17:50] <slangasek> seb128: 428115> I wasn't running into it myself, I was setting the correct target based on the description of the bug and the fact that someone else referenced it.  Obviously if it's fixed, the bug should be closed
[17:51] <seb128> slangasek, I've duplicated from the other one for now
[17:51] <seb128> slangasek, if people still get the issue they can comment or reopen
[17:52] <mdz> mathiaz, are you back home now?
[17:52] <pitti> mdz: merged, fixed, uploaded to queue
[17:52] <mdz> pitti, thank you
[17:52] <mdz> pitti, it would be helpful to get that in for beta so that the bug reports are more useful
[17:53] <pitti> right
[17:53] <pitti> but I don't want to approve myself, I'll wait for slangasek to do that
[17:53] <mdz> it only needs to go in the uec images, so it shouldn't cause anything else to be unnecessarily rebuilt
[17:53] <mathiaz> mdz: yop!
[17:53] <pitti> mdz: don't worry, it's not in the critical path; we just NEWed a kernel, still need to accept linux-meta, get a new d-i, etc.
[17:53] <mdz> pitti, ok
[17:54] <cjwatson> kernel NEWing is still in process
[17:54] <cjwatson> d-i change is committed
[17:54] <cjwatson> if somebody wants to do that while I'm out, they can upload what's in bzr, and then change the platform seeds to match
[17:54] <cjwatson> but if nobody does, I'll be back in around four or five hours and will do it then
[17:54] <pitti> I'll be off as soon as the meeting stops, too, sorry
[17:55] <cjwatson> (Friday evening, what's that?)
[17:56] <pitti> lool: why does liblauncher drop gtk-doc build stuff? no docs any more?
[18:03] <sgallagh> mathiaz: ping
[18:03] <mathiaz> sgallagh: hi
[18:04] <lool> pitti: Yeah
[18:04] <lool> pitti: 12:32 < lool> njpatel: dropping doc?
[18:04] <lool> 12:32 < njpatel> lool: we didn't build docs for karmic anyway
[18:04] <sgallagh> mathiaz: Just wanted to give you a heads-up. We're planning to take the current master of the SSSD repository as 0.6.0. I wanted to see if you would be willing to do a test build to make sure we didn't break anything obvious for you guys
[18:04] <pitti> lool: ah, thanks
[18:05] <mathiaz> sgallagh: I can give it a try
[18:05] <mdz> smoser, do you have the ability to push a new version of vmbuilder into the place where it's used for the daily builds?
[18:05] <mdz> or do we need to get you that permission?
[18:05] <sgallagh> mathiaz: I can throw a tarball your way if you want (we fixed the autoreconf issue for you)
[18:05] <mathiaz> sgallagh: although it's low priority for ubuntu as we won't update to 0.6.0 in Karmic
[18:05] <mdz> mathiaz, glad you made it back
[18:05] <smoser> mdz, i do
[18:06] <mathiaz> sgallagh: I have a build infrastructure to build from master
[18:06] <mathiaz> sgallagh: as I don't plan to push 0.6.0 into Karmic I don't need a tarball
[18:06] <mdz> mathiaz, do you have the necessary hardware to install and test eucalyptus?
[18:06] <mdz> mathiaz, and do you have a list of beta-critical issues you're working on, if any?
[18:06] <mathiaz> sgallagh: I'll do a test with the released tarball
[18:07] <smoser> i also recently disabled the nightly builds that were running as soren. now they run as the 'vmbuilder' user.
[18:07] <sgallagh> mathiaz: Ok, if you're not planning on pulling it in (even post-release?), then there's no urgency
[18:07] <mathiaz> mdz: I don't have the hardware at home - but I could ask cr3 if I can get some from the certification lab
[18:08] <mathiaz> sgallagh: nope - we're in FeatureFreeze for now - so we won't update to new upstream releases that have new features
[18:08] <mathiaz> mdz: I'm following up on the image-store-proxy package
[18:08] <sgallagh> mathiaz: Fair enough. Good luck to you :)
[18:08] <cr3> mathiaz: sorry, I wasn't listening, what hardware do you need?
[18:08] <mathiaz> mdz: other than that I can help out with eucalyptus testing
[18:09] <mathiaz> cr3: I'm looking for extra hardware to setup a cloud
[18:09] <cr3> mathiaz: you want to drop by the office to test across a few laptops?
[18:09] <cr3> mathiaz: I could have them imaged with ubuntu-server Karmic within 20 minutes
[18:10] <mathiaz> sgallagh: thanks  - we'll look into the next version of sssd once we talk about the  plans for lucid (we should happen around november)
[18:10] <mathiaz> cr3: how long can I borrowed them?
[18:10] <mdz> cr3, the minimum requirement in two machines, one of which must have VT extensions
[18:10] <sgallagh> mathiaz: When do you expect feature-freeze for Lucid?
[18:11] <mathiaz> sgallagh: Feb 25th 2010 - https://wiki.ubuntu.com/LucidReleaseSchedule
[18:11] <sgallagh> mathiaz: We're aiming for a 1.0.0 release sometime around February (hopefully) that will include FreeIPA client support as well. (There will be a 0.7.0 and 0.8.0 release at least between then and now)
[18:11] <mathiaz> sgallagh: noted.
[18:11] <cr3> mathiaz: how long would you need 'em?
[18:12] <mathiaz> cr3: probably until beta
[18:12] <cr3> mathiaz: I'll have to ask marjo for that
[18:12] <mathiaz> cr3: actually what I really need is a laptop with vt extensions
[18:12] <mathiaz> cr3: ie *one* laptop with VT extensions
[18:13] <cr3> mathiaz: I think marjo will be alright with that, but I'll inform him for good measure
[18:13] <mathiaz> cr3: great - I'll stop by later today and get one of them
[18:14] <mathiaz> mdz: so I should be able to setup a cloud today
[18:14] <cr3> mathiaz: coolio, it'll be imaged by then with a nice bow tie around it
[18:14] <mathiaz> cr3: chocolates and champagne is also very much appreciated
[18:15] <cr3> mathiaz: I think TeTeT brought some chocolates from Germany, so all we're missing is the bubbly
[18:16] <cr3> mathiaz: I didn't realize testing eucalyptus had so many requirements, maybe I should've volunteered for that testing instead of davmor2
[18:16] <pitti> # Automatically added by dh_installinit
[18:16] <pitti> update-rc.d -f gdm remove >/dev/null || exit $?
[18:16] <pitti> oops, sorry
[18:22] <lool> slangasek: bjf told me that kernel team was working on the kernel trees and that ARM kernels had been rebased and probalby three uploads would happen today
[18:22] <ogra> wohoo
[18:22] <lool> slangasek: On EC2 he told me people are currently locked in a room until everything works or death
[18:22] <lool> But not clear on a kernel upload
[18:31] <asomething> hey all, got a couple questions/requests for the archive-admins
[18:31] <asomething> First, could someone explain why lua-gtk_0.9+20090719-1ubuntu2 was rejected.
[18:32] <sladen> asomething: rejected, or just held?
[18:32] <sladen> asomething: universe is in manual mode, but it should get done
[18:32] <asomething> sladen, actually rejected
[18:32] <asomething> only reason given was "Rejected by archive administrator."
[18:33] <asomething> http://paste.ubuntu.com/278110/
[18:34] <pitti> I'm innocent of that
[18:36] <pitti> smoser, soren, zul: just as a heads-up, ec2-init promoted now; due to some soyuz itch it _might_ be possible that the build will become "failed to upload"; in this case, please wait an hour and retry the build (on https://launchpad.net/ubuntu/+source/ec2-init/0.4.999-0ubuntu2/+build/1261482)
[18:36] <zul> pitti: thanks for the heads up
[18:36] <pitti> (details: it sometimes doesn't like when a package gets promoted while it's being built)
[18:36] <pitti> so it thinks the packages should go to universe, but underneath it moved to main
[18:36] <pitti> but the next build will succeed
[18:37] <pitti> zul: I'm about to go out, can you watch this, please? You'll get soyuz mail if it fails
[18:37] <zul> pitti: of course
[18:37] <pitti> thanks
[18:37] <pitti> so, over & out
[18:38] <asomething> it already build-depends on libclutter-1.0-dev not 0.8, so the upload only changes the binary depends from libclutter-0.8-0 to libclutter-1.0-0 (see: (LP: #364630)
[18:42] <smoser> i have a debhelper question.  i have an init script 'ec2-init-user-data'. it is one of 2 in the package. the other is installed by install into /etc/init.d and is recognized by cdbs as an init script, and uses DEB_UPDATE_RCD_PARAMS appropriately
[18:42] <smoser> is it possible for me to have a second init script that is not in debian/ ? and use dh_installinit to install it ?
[18:43] <smoser> ideally i'd add it to the package install system to install into /etc/init.d (like the "main" init script is), and then tell dh_installinit to pick it up there.
[18:45] <lool> Not in debian/?  Dont think dh_installinit can do that
[18:46] <smoser> thats how it appeard to me
[18:46] <smoser> but i thought, maybe since the main script was not there, and was "found" i could use something like that
[18:47] <lool> smoser: I'm not sure of which cdbs feature you mean here
[18:47] <lool> smoser: DEB_UPDATE_RCD_PARAMS is passed to dh_installinit by CDBS
[18:48] <smoser> right
[18:48] <smoser> so right now my package has 1 install script. 'ec2-init'. it is installed by the setup.py into /etc/init.d/ec2-init
[18:48] <lool> Ok
[18:48] <smoser> *something* recognizes that as an init script and magically installs it, using the DEB_UPDATE_RCD_PARAMS
[18:49] <smoser> i want to add a script
[18:49] <smoser> i can add it to debian/my-script and use dh_installinit
[18:49] <Keybuk> NCommander: sorry, but SPARC is quite high on the list of "things I don't care about"
[18:49] <smoser> but i would rather keep it like the first script (installed by setup.py) and then use dh_installinit for it
[18:50] <lool> smoser: Hmm dh_installinit should only do stuff if you pass an init script to install to it
[18:50] <lool> smoser: Do you have a .dsc somewhere?
[18:50] <smoser> (since it would run at different order, i figure i would have to tell dh_installinit of that new order explicitly for it)
[18:50] <ogra> Keybuk, wow, you priorize on that list ?
[18:50] <lool> smoser: Gah it's getting late here -- bath and dinner
[18:50]  * ogra doesnt
[18:50] <ogra> would mean i need to care to much for things i dont actually care for :)
[18:50] <lool> smoser: Do you ming switching to slangasek for sponsoring if I dont get back to you on your next ping?
[18:50]  * lool &
[18:51] <smoser> sure.
[18:51] <smoser> lool, bzr branch lp:ubuntu/ec2-init
[18:51] <NCommander> Keybuk, I realize that, but I filed the bug so at least its a known issue. If I had time, I'd track it down and give you the patch on a silver platter
[18:51] <Keybuk> NCommander: yes, but "High" is not a priority I would have picked ;)
[18:52] <NCommander> Keybuk, I use priority on the impact of the bug; I think preventing systems from booting is High (I almost went to Critical, but I decided that SPARC isn't a large enough userbase to warrant it)
[18:52] <smoser> lool, you're certainly entitled to not paying complete attention to me
[18:52] <Keybuk> that's not what priority is intended for
[18:53] <Keybuk> priority is actually really well defined
[18:53] <ogra> Keybuk, did he milestone it too *grin*
[18:53] <Keybuk> and is based on such factors as how many users are affected
[18:53] <Keybuk> after all, every bug is critical for the user affected by it
[18:53] <Keybuk> or every upstart bug in *some way* affects booting
[18:53] <Keybuk> ogra: he did, yes
[18:53] <ogra> heh
[18:54] <asomething> Request two for an archive-admin is could someone accept exaile in binary NEW? As it's the default music player for Xubuntu, it would be good to get that version on the beta CDs.
[18:54] <NCommander> Keybuk, I'll bump it down to Medium then if you feel High is too High.
[18:54] <ogra> Keybuk, btw, do you have a wikipage or something for people using init=/bin/bash that want to start basic services by hand now that initscripts are gone ?
[18:55] <Keybuk> NCommander: I've set it to Low.  Please leave it there
[18:55] <ogra> its hard to debug things if you cant start the services anymore
[18:55] <sladen> ogra: service foobar moo
[18:55] <ogra> sladen, nope
[18:55] <ogra> requires upstart to run
[18:55] <Keybuk> ogra: you can't do that
[18:55] <sladen> ogra: only I haven't worked out how you're supposed to start upstart, in order for 'service' to work
[18:55] <ogra> right
[18:56] <ogra> that was my prob this week :)
[18:56] <sladen> I meant to file the cyclic loop (hit it during the ultimate black boot of doom)
[18:57] <smoser> mdz, i verified the build of vmbuilder with the seeds patch outputs the same packages as it previously did
[18:57] <Keybuk> sladen: cyclic loop?
[18:57] <sladen> Keybuk: something like  'service upstart start' suggesting you start upstart
[18:57] <Keybuk> sladen: that's already fxied
[18:58] <sladen> Keybuk: or maybe it was  /etc/init.d/upstart start  suggesting to use 'service'
[18:58] <smoser> the only difference is we lost 'curl'.  this is probably due to it being previously only present as a dependency of ec2-ami-tools (which was dropped).  but i think we probably want it. so we need to add that to the seeds.
[18:58] <smoser> err, seed.
[18:58] <ogra> Keybuk, oh, so you can start upstart from init=/bin/bash ?
[18:58] <ogra> good to know
[18:58] <Keybuk> ogra: exec /sbin/init
[18:58] <ogra> ok
[18:58] <Keybuk> ogra: usually I do init=/bin/bash
[18:58] <Keybuk> stick something like
[18:58] <Keybuk>   start on startup
[18:58] <sladen> Keybuk: and then what happens to my console?
[18:59] <Keybuk>   console owner
[18:59] <Keybuk>   exec /bin/bash
[18:59] <Keybuk> and then exec init
[18:59] <Keybuk> so I get a shell
[18:59] <ogra> well, my prob was that upstart hung in my armel VM
[18:59] <ogra> so i couldnt use an upstart job :)
[18:59] <Keybuk> then --debug is your friend
[19:00] <ogra> exec /sbin/init is indeed brilliant :)
[19:00] <sladen> Keybuk: so upstart abolutely, positvely, must be pid=1
[19:00] <Keybuk> sladen: yes
[19:00] <Keybuk> ogra: you can also do
[19:00] <Keybuk> init=/bin/bash
[19:00] <Keybuk> then openvt sulogin
[19:00] <Keybuk> exec /sbin/init --debug
[19:00] <ogra> ok, noted down
[19:00] <Keybuk> you get a bash on vt2 with init as pid 1 and debug on tty1
[19:01] <sladen> Keybuk: so if upstart sees itself being execed (eg. argv[0] == /bin/bash) it should just "do the right thing", start itself and give a kernel back
[19:01] <Keybuk> sladen: I don't follow
[19:01] <Keybuk> if you're saying what I think you're saying, there's reason you can't do that ;
[19:01] <sladen> Keybuk: and if upstart is run from pid != 1 it should print some useful message about "running 'exec $argv[0]'"
[19:01] <Keybuk> :)
[19:03] <sladen> Keybuk: when I have a system that is *so* in a knot that I'm doing /bin/bash, having to cat six lines accurately from memory just to get a shell again seems .. unavoidable
[19:03] <sladen> Keybuk: upstart could just internally know if run that job if I'm running it from init=/bin/bash
[19:03] <sladen> s/if run/to run/
[19:04] <lool> smoser: FYI
[19:04] <lool> E: ec2-init: init.d-script-does-not-implement-required-option /etc/init.d/rightscale-init restart
[19:04] <lool> E: ec2-init: init.d-script-does-not-implement-required-option /etc/init.d/rightscale-init force-reload
[19:04] <Keybuk> if you do init=/bin/bash and exec /sbin/init, both the original bash and init are pid 1
[19:04] <Keybuk> if you run init in a way that means it's *not* pid 1, it behaves as if you ran telinit
[19:04] <Keybuk> for lynx, "init 3" will start outputting a "STOP THAT!" error message but still call telinit
[19:04] <Keybuk> post-lynx, I'll drop support for init-pretends-to-be-telinit
[19:04] <Keybuk> (at least, maybe - I may not be able to ever drop support for that)
[19:04] <Keybuk> now
[19:04] <lool> smoser: and W: ec2-init: script-calls-init-script-directly ./etc/init.d/rightscale-init:74
[19:04] <Keybuk> if init is pid 1
[19:04] <Keybuk> and argv[0] was bash
[19:04] <Keybuk> you might think that you could say "ah, we're being debugged"
[19:04] <Keybuk> and give them a shell back
[19:04] <sladen> eg. with fairly simple heuristics, upstart can tell and/or do what I probably(tm) want to do
[19:04] <lool> smoser: and others  :-/
[19:04] <Keybuk> but that doesn't work
[19:04] <Keybuk> because init is *always* exec'd by /bin/bash
[19:04] <Keybuk> because the initramfs is a shell script
[19:05] <Keybuk> and init is exec'd by the initramfs, not by the kernel
[19:05] <Keybuk> sladen: I'd rather spend the effort making sure that you can't get the system into such a hole
[19:05] <Keybuk> than coming up with creative debugging strategies
[19:05] <smoser> lool, well many of those have been addressed
[19:05] <smoser> for one, rightscale-init is gone
[19:05] <smoser> so that covers all those you listed.
[19:06] <lool> smoser: Ok, just looking at the branch you pointed at
[19:07] <sladen> Keybuk: I'm hopefully that upstart can at least offer a --help to say how to get it up and running (eg. the   start on startup ... owner console  lines above)
[19:07] <lool> smoser: Ok so what's your goal?
[19:07] <Keybuk> sladen: again, I'm uninterested in that
[19:07] <smoser> yeah, it will be updated shortly.
[19:07] <lool> smoser: Or issue?
[19:07] <smoser> i want to add a script 'ec2-add-user-data'
[19:07] <smoser> that runs at init
[19:07] <Keybuk> if upstart itself is so broken that it can't start a single job, it is out of the ability to document for most people to work out how to fix it
[19:07] <smoser> and ideally, not have it in the debian/ directory
[19:07] <Keybuk> if upstart *can* start a single job, then there are better solutions
[19:07] <sladen> Keybuk: right, but the fact that other (reasonably competant) people are asking about it demonstrates the use-case
[19:08] <lool> smoser: Ok; can you do the same thing as the rightscale-init dh_installinit call, but with -o?
[19:08] <Keybuk> e.g. the proposal that kernel command-line options are jobs to be started
[19:08] <smoser> handled just like ec2-init is (installed by setup.py)
[19:08] <Keybuk> so if you booted with "emergency" on the command-line, the /etc/init/emergency.conf job would be started automatically
[19:08] <Keybuk> and that could be shipped by all distributions to give a shell on the console
[19:08] <smoser> lool, yes.
[19:08] <smoser> thank you
[19:08] <smoser> i think thats right
[19:08] <sladen> Keybuk: the probably (eg. black screen of doom) was that jobs *were* being started
[19:08] <lool> smoser: Oh eh np
[19:08] <smoser> sorry for missing that.
[19:08] <sladen> problem
[19:09] <Keybuk> sladen: indeed, so init=/bin/bash wasn't necessary
[19:09] <lool> smoser: I'm going for dinner; good luck on vmbuilder!
[19:09] <lool> slangasek: ^  sorry that I only hanged around for that long
[19:10]  * lool &
[19:10] <ogra> Keybuk, what about initramfs, is that needed for upstart to function ? my VM didnt have one and i thought that might be an issue
[19:10] <sladen> Keybuk: maybe ... but it was the expected low-level debugging approach
[19:10] <ogra> though i couldnt really debug due to lkacking knowledge
[19:11] <sladen> (and I didn't have net access to go googling at that point)
[19:11] <Keybuk> ogra: no
[19:11] <Keybuk> ogra: I test upstart without an initramfs
[19:11] <ogra> ok
[19:11] <Keybuk> (indeed, I have it as a GRUB option on this mini)
[19:12] <ogra> good to know, i wasnt sure it requires anything thats mounted or created in initramfs
[19:12] <Keybuk> it shouldn't do
[19:13] <ogra> Keybuk, thanks for the insight ... :)
[19:13]  * ogra goes to dinner as well now
[19:13] <Keybuk> Upstart does use a few devices in /dev though
[19:13] <Keybuk> so if you're missing those, it gets a bit grumpy
[19:13] <ogra> ah, my VM had only a basic debootstrap run
[19:14] <Keybuk> that should still have /dev/console, /dev/null, /dev/fd, etc. in /dev ;)
[19:14] <directhex> argh. my audio's disappeared
[19:14] <ion> keybuk: This might be a regression with the conversion from an init script to an Upstart job. https://bugs.edge.launchpad.net/ubuntu/+source/rsyslog/+bug/436323
[19:14] <ogra> indeed
[19:14] <directhex> which means either the motherboard's gone haywire, or karmic
[19:14] <Keybuk> ubottu: I think that mterry was already fixing that
[19:14] <Keybuk> ion: I think that mterry was already fixing that
[19:15] <ogra> anyway ... i'm off
[19:15] <Keybuk> ogra: the /dev/fd -> /proc/self/fd is optional though
[19:15] <Keybuk> it can just pass the script to bash directly
[19:15] <Keybuk> likewise accesing /proc is optional
[19:15] <ogra> ok
[19:15] <Keybuk> unless the service has oom_adj set
[19:15] <Keybuk> basically it should be possible to start a job taht mounts /proc and /dev
[19:16] <ogra> right
[19:16] <jdong> hmph, looks like debian bug 540786 afects us too (unsurprisingly)
[19:16] <mterry> Keybuk: i fixed it.  i've been waiting for you(someone) to push it
[19:16] <Keybuk> mterry: oh, I didn't know that
[19:16] <Keybuk> are you not a core-dev?
[19:16] <mterry> Keybuk: sorry.  that's why i brought it up in that meeting.  no you fool.  I just got motu yesterday.  :)
[19:17] <Keybuk> heh
[19:17] <Keybuk> I can't upload anything until next week though
[19:17] <mterry> Keybuk: k, no rush (on my end)
[19:17]  * robbiew finds it funny that mterry was on the MIR team BEFORE making MOTU
[19:18] <mterry> yeah, i got some questions about that during the motu meeting....
[19:22] <NCommander> Keybuk, just as a random sidenote, do you know what in upstart could cause the system to automatically restart after its configured?
[19:23] <Keybuk> NCommander: what system?
[19:23] <Keybuk> after what is configured?
[19:23] <NCommander> Keybuk, my SPARC box restarts automatically when I upgrade or downgrade upstart on SPARC
[19:23] <NCommander> (the behavior been seen on other sparcs in karmic as well)
[19:23] <Keybuk> NCommander: neat
[19:24] <Keybuk> no ida
[19:24] <Keybuk> kernel panic maybe?
[19:24] <NCommander> Keybuk, no, it says "Sending SIGKILL to all processes", which suggests the runlevel was changed to 6
[19:24] <NCommander> (or SIGTERM)
[19:24] <Keybuk> no idea
[19:25] <Keybuk> initctl log-priority debug
[19:25] <NCommander> Keybuk, thanks anyway. If I crack it, I'll fire a patch your way
[19:27] <Keybuk> NCommander: have you tried running "make check" on SPARC?
[19:28] <NCommander> Keybuk, isn't the test suite run at build time? (I remember upstart/sparc was FTBFSing for a long time on that)
[19:29] <Keybuk> NCommander: no, because the buildd environment is quite broken
[19:29] <NCommander> ah
[19:29] <NCommander> I'll do that in a moment then
[19:29] <Keybuk> I run the suite, but it won't fail the build
[19:30] <Keybuk> [19:30] <Keybuk> 4 of 17 tests failed
[19:30] <Keybuk> Please report to upstart-devel@lists.ubuntu.com
[19:30] <Keybuk> [19:30] <Keybuk> and that's just in libnih
[19:30] <sladen> Keybuk: can you fill in the missing "Technobable" sections on  http://upstart.ubuntu.com/wiki/OMGBroken  and check I've got the rest correct
[19:30] <Keybuk> lots of "Bus error"
[19:30] <NCommander> Keybuk, that suggests a compiler or alignment error :-/
[19:31] <Keybuk> sladen: I don't recommend "service"
[19:31] <Keybuk> the canon way to start an Upstart job is using "start"
[19:31] <sladen> Keybuk: groovy
[19:33] <sladen> Keybuk: done
[19:33] <Keybuk> looks like the tests that failed were
[19:33] <Keybuk>  timers
[19:33] <Keybuk>  file reading
[19:33] <Keybuk>  inotify
[19:33] <Keybuk>  main loop handling
[19:33] <Keybuk> they seem pretty critical ;)
[19:35] <mterry> Keybuk: you don't recommend service?  cjwatson was saying we were converging on service and to avoid start...
[19:36] <Keybuk> mterry: I absolutely don't recommend using service
[19:36] <mterry> Keybuk: sigh
[19:36] <sladen> bike-shedding.
[19:36] <Keybuk> what's the point of using a wrapper shell script for our own init daemon?
[19:37] <sladen> Keybuk: an argument might be discoverability
[19:37] <sladen> Keybuk: if you know the word 'service', you can work through the help
[19:37] <Keybuk> if you know the word 'start' you can work through the help
[19:38] <sladen> service has been around longer...
[19:38] <Keybuk> not in Ubuntu
[19:38] <Keybuk> start has been in Ubuntu longer than service
[19:38] <Keybuk> it's fine to *have* service for users that are used to it
[19:39] <Keybuk> but our own documentation, maintainer scripts, etc. that are written knowing that something is an Upstart job should just use the Upstart-native commands
[19:39] <Chipzz> if anyone wants my 2c: start has a heavily overloaded meaning, and I don't think it makes sense to monopolize it for upstart...
[19:39] <Chipzz> but then, that's just my 2c
[19:39] <Keybuk> it's the init daemon
[19:40] <sladen> an implemtnation of
[19:40] <Keybuk> it's the only one we support
[19:40] <Chipzz> Keybuk: but... start what? start a service? start a program? ... ?
[19:40] <Keybuk> in fact, it's the only one that even *works* in Ubuntu
[19:40] <Keybuk> Chipzz: yes, all of the above
[19:40] <Keybuk> case in point
[19:40] <Chipzz> Keybuk: ./someprog is not the same as starting a service :)
[19:40] <sladen> I think we need to do some PR if 'start' is still the preferred;  I had indirectly presumed it was being phased out
[19:41] <Keybuk>  /etc/init/hwclock.conf is a *task* not a service
[19:41] <Keybuk> "start hwclock" will start the task and wait for it to compelte
[19:41] <Keybuk> sladen: I utterly reject that notion; if people are telling you that, tell them to talk to me
[19:42] <mterry> Keybuk: do we care much if things are calling (compatibility) init scripts?  when do we see those going away?
[19:42] <mterry> Keybuk: (i meant init.d scripts)  :)
[19:42] <sladen> Keybuk: nobody had, had just presumed it from seeing emails/documentation etc.  I'll be on the look-out now to correct people who are WRONG, just as vermantly as on Wikipedia!
[19:43] <Keybuk> mterry: sure, you can use service for init scripts
[19:43] <Keybuk> that's certainly more correct than using invoke-rc.d ;)
[19:43] <Keybuk> which is just WRONG
[19:43] <sladen> Keybuk: now, back to http://upstart.ubuntu.com/wiki/OMGBroken  where should this console job snippet be catt'ed to
[19:43] <Keybuk> sladen: /etc/init/somewhere.conf ?
[19:43] <mterry> Keybuk: naw, i meant, something directly calling /etc/init.d/blarg.  when do we see that going away?  when we can do a grep and nothing calls it? :)
[19:44] <mterry> Keybuk: (for something that has been converted to an upstart task)
[19:44] <sladen> Keybuk: /etc/init/bash.conf
[19:44] <Keybuk> mterry: I figure post-lynx for the current set
[19:44] <Keybuk> sladen: I'd use exec openvt sulogin rather than bash
[19:44] <mterry> Keybuk: k
[19:44] <Keybuk> then you don't need the console owner
[19:44] <Keybuk> than you won't break if someone uses (e.g.) cryptsetup
[19:45] <mathiaz> kees: hi!
[19:45] <kees> mathiaz: heya :)
[19:45] <mathiaz> kees: how do you debug build failure that occurs on the buildd but not in your local sbuild?
[19:46] <mathiaz> kees: https://launchpad.net/ubuntu/+source/image-store-proxy/1.0-0ubuntu2/+build/1261481
[19:46] <mathiaz> kees: ^^ this builds correclty in my schroot+sbuild environement
[19:46] <kees> mathiaz: I make my local sbuild as close to the buildd as possible, and compare buildlog output for clues.
[19:46] <kees> mathiaz: you can also try it on the porter machines
[19:46] <mathiaz> kees: ah the porter machines
[19:47] <mathiaz> kees: I was trying to use PPA, but the turn around is a bit... long
[19:47] <kees> heh, yeah
[19:47] <sladen> Keybuk: how to start upstart such that it starts *just* the daemon, but then doesn't bring up any (eg. framebuffer trashing) deafult jobs?
[19:47] <kees> I would also check the specific test failure:
[19:47] <kees>     testCheckImageSignatureWithBadSignature ...                         [ERROR]
[19:47] <mathiaz> kees: right - I know what my be wrong
[19:47] <kees> if that requires external network connectivity, for example, it will fail on buildds but not for your sbuild
[19:47] <mathiaz> kees: but I'd need more output
[19:48]  * kees nods
[19:48] <kees> see if you can make it fail on the porter machine; that's usually one way to get it.
[19:48] <Keybuk> sladen: currently can't, it's on the TODO
[19:52] <sladen> Keybuk: what's a good work-around?
[19:53] <sladen> Keybuk: grep the 'exec' lines out of the job files and then run those in the background?
[19:54] <sladen> Keybuk: but thne upstart won't be running and won't need to be
[19:58] <mathiaz> kees: can you use sbuild on the porter machines?
[19:58] <kees> mathiaz: no, one just builds it manually with debuild inside the chroot
[20:06] <sladen> ogra: append anything you come across to http://upstart.ubuntu.com/wiki/OMGBroken
[20:08] <sladen> Keybuk: http://upstart.ubuntu.com/wiki/Stanzas?highlight=%28%28onalso%29%29  is that intentional?
[20:09] <sladen> Keybuk: http://upstart.ubuntu.com/wiki/Stanzas?highlight=onalso  is that intentional?
[20:11] <slangasek> lool: no worries
[20:17] <slangasek> kirkland: please don't triage freeze exception bugs
[20:17] <kirkland> slangasek: whoops...
[20:17] <slangasek> kirkland: we use the status fields differently for process bugs
[20:17] <kirkland> slangasek: which one is it?
[20:19] <slangasek> kirkland: the eucalyptus UI freeze exception one... I'll fix this one up myself, just letting you know for future reference :)
[20:19] <kirkland> slangasek: thanks, sorry, was inadvertent
[20:19] <kirkland> slangasek: mdz asked me to triage some 60+ eucalyptus bugs
[20:19] <kirkland> slangasek: i got trigger happy
[20:22] <slangasek> kirkland: yep, was aware of that, so if you already know the rules ignore me :-)
[20:24] <kirkland> slangasek: perhaps these should have another task, just associated with Ubuntu
[20:24] <kirkland> slangasek: such that i can triage the bug against the package appropriately
[20:24] <kirkland> slangasek: and you release team guys can have your own status line associated with ubuntu to do what you want with
[20:25] <slangasek> kirkland: I disagree, because a) the bug report exists solely for processing the exception, b) we do often have multiple packages related to a single freeze exception that may need to be reviewed separately
[20:26] <slangasek> kirkland: but if we need to discuss that further, let's please take it to ubuntu-devel (where there've been threads about this recently)
[20:27] <kirkland> slangasek: fair enough; i don't care enough to discuss further, particularly if you've already thought about this :-)
[20:27] <kirkland> slangasek: i'll take my smackdown and get back to work :-)
[20:33] <zul> can someone push through m2crypto as well? Thanks
[20:42] <kees> mvo: uhm "Third party sources disabled" in update-manager seems to remove my local mirror.  In past releases it would just rename rel-1 to rel...
[20:56] <mvo> kees: do you have local-mirror + normal sources.list entires? could you mail me the /var/log/dist-upgrade/main.log when that happend?
[20:57] <kees> mvo: ah, yeah, I did have local + normal (to catch stuff newer than my local mirror)
[20:57] <kees> mvo: I manually worked around it, but I can send logs
[20:57] <mvo> kees: I think that is the problem, if you disable "normal" it will assume you are on a local mirror
[20:58] <mvo> kees: but if its mixed it does not known what is a mirror and what is a third party source. I think this should be made cleverer (but it has not changed in a while)
[20:58] <mvo> (IIRC at least ;)
[20:59] <kees> mvo: okay, well in this case, I will blame it on my crackful sources.list.  :)  sorry for the noise!  sounds like the existing logic is just fine.
[21:02] <mvo> kees: thanks
[21:14] <kirkland> slangasek: uh, oh, i did it again, https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/424368
[21:14] <kirkland> slangasek: moving back to confirmed.  sorry.
[21:16] <sistpoty> anyone got an idea why i get this from pbuilder (when trying to extract the source with dpkg-source): gzip: stdout: Broken pipe
[21:22] <sebner> sistpoty: b0rken archive?
[21:32] <sistpoty> huhu sebner
[21:32] <sistpoty> sebner: I somehow doubt that (or hope that its not true *g*)
[21:32] <mdz> smoser, ping
[21:33] <smoser> here
[21:33] <mdz> smoser, how current is the current uec image on uec-images?
[21:34] <mdz> (20090925)
[21:34] <mdz> does it include the kernel modules, was it built with the seed-using version of vmbuilder, etc.?
[21:35] <sistpoty> sebner: interesting, seems that I just had a broken chroot... works fine now :)
[21:35] <smoser> midnightish utc
[21:36] <smoser> mdz, it does contain kernel modules, but was built without seeds
[21:36] <mdz> smoser, is it worth rolling a new one with the latest vmbuilder + the latest bits from the archive right now?
[21:37] <mdz> slangasek, I would like to get an additional person set up to be able to trigger server ISO builds if that's OK
[21:37] <smoser> i built with the seed changes prior to checking them in. that would have been probably 16:00 UTC. i have a diff of the manifests
[21:38] <smoser> if you want to see them.
[21:38] <smoser> i'm fine to re-spin it if you want, but it'll build automatically at midnight or so utc
[21:38] <mdz> smoser, anything alarming in the diff?
[21:39] <smoser> i sent in mail on UEC images thread.
[21:39] <smoser> shoot
[21:39] <smoser> i realize i didn't hit send
[21:39] <smoser> just now did. i dont know why i postponed it
[21:39] <smoser> but anyway, the only difference that wasn't to be expected was curl and libcurl dropped
[21:40] <mdz> smoser, great, let's spin a new daily
[21:41] <smoser> as in now? or in 4 hours?
[21:46] <smoser> mdz^
[21:50] <sebner> sistpoty: this would have been my next guess :) Glad that it's fine now =)
[21:54] <slangasek> mdz: that means getting them access on antimony; I don't have any objections
[21:57] <mdz> slangasek, so the first step is to file an RT asking for them to get access to antimony?
[21:59] <slangasek> mdz: yes
[22:04] <mdz> smoser, any reason to wait?
[22:04] <mdz> smoser, we could start downloading it right away and use it in our tests here
[22:04] <mdz> smoser, by the way, is it rsyncable?
[22:05] <smoser> it shoudl be, yes.
[22:05] <mdz> slangasek, filed
[22:05] <smoser> and its building now
[22:05] <mdz> slangasek, meanwhile, is our new ISO ready with this morning's eucalyptus?
[22:06] <mdz> smoser, can you give me the URL for the branch of vmbuilder which is used for the daily builds?
[22:06]  * cjwatson returns
[22:06] <smoser> https://wiki.ubuntu.com/UEC/Images/Testing indicates rysncable and as i recall it worked well
[22:06] <smoser> mdz, its trunk. bzr+ssh://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/trunk/
[22:06] <mdz> smoser, thanks
[22:06] <smoser> or lp:~ubuntu-virt/vmbuilder/trunk vmbuilder
[22:07] <slangasek> mdz: yes: http://cdimage.ubuntu.com/ubuntu-server/daily/20090925.2/
[22:07] <mdz> slangasek, thanks
[22:13] <cjwatson> mdz: is there anything I can do that isn't going to cause me to be up into the wee small hours? :)
[22:17] <mdz> smoser, I still don't see that email from you
[22:17] <mdz> cjwatson, we're rsyncing the latest image to test and verify your fixes from earlier today
[22:18] <mdz> cjwatson, dustin has triaged the eucalyptus bug list; I'd appreciate it if you could eyeball it and see if there's anything which jumps out at you
[22:18] <kirkland> cjwatson: sorry to bother, could you take a look at bug #424368, and update accordingly?
[22:20] <smoser> mdz,
[22:20] <smoser> Subject: Re: New seeds for UEC images
[22:20] <smoser> Date: Fri, 25 Sep 2009 16:39:31 -0400 (EDT)
[22:21] <smoser> i have to run. I'll check back in later tonight.
[22:24] <smoser> mdz, build should appear http://uec-images.ubuntu.com/karmic/20090925.1 very soon
[22:24] <mdz> smoser, I don't see it on https://lists.ubuntu.com/archives/ubuntu-devel/2009-September/thread.html
[22:24] <mdz> smoser, are you sure you sent it to ubuntu-devel?
[22:25] <smoser> it did not
[22:25] <mdz> oh, you sent it privately. nm.
[22:25] <smoser> none of that thread did. ijust responded to it.
[22:27] <smoser> mdz, url above is populating now
[22:27] <smoser> i'm out for the night
[22:27] <smoser> will check back in ~ 01:00 utc
[22:28] <cjwatson> kirkland: I suspect that can be closed, unless you're aware of anything more that needs to be added
[22:29] <cjwatson> it's more effectively tracked in separate bugs at this point anyway
[22:30] <mdz> smoser, thanks
[22:31] <mathiaz> slangasek: I've uploaded a new version image-store-proxy that disables the failing tests
[22:31] <mathiaz> slangasek: I've filed bug 436896 as well to fix them later
[22:32] <cjwatson> kirkland: I've closed it now
[22:32] <kirkland> cjwatson: thanks a lot
[22:46] <mdz> smoser, I'd like to get this image tested on EC2 before the weekend
[22:51] <smoser> mdz, i can try to push and register tonight.
[22:51] <smoser> i really, really would like to get that stuff automated from the data center :-(
[22:59] <cjwatson> mdz,kirkland: there's a heck of a lot of unreleased stuff in eucalyptus bzr now due to kirkland being a machine. do we want to get that in for the next CD build, or is it too risky? I haven't looked at all (or even most of) the changes
[22:59] <kirkland> cjwatson: i'm going to build it locally here and test
[23:00] <mdz> cjwatson, it's not tested yet but we do want it in an image as soon as that's done
[23:00] <cjwatson> ok - I committed another minor bug fix since your updates, so update
[23:00] <cjwatson> ok
[23:00] <kirkland> cjwatson: yeah, i just merged/resolved the conflict on that one :-)
[23:00] <mdz> smoser, is there anything you need in order to make that happen (automating) other than time?
[23:00] <kirkland> cjwatson: i also added a Conflicts: apache2-mpm-itk
[23:01] <cjwatson> hah
[23:01] <cjwatson> no harm in both, as the bug says
[23:03] <mdz> cjwatson, I assume there will be a new build once linux-meta is ready?
[23:03] <kirkland> cjwatson: oh, i did have a question for you about Bug #436199
[23:03] <kirkland> cjwatson: i solved that with an update-motd script putting a url in the MOTD
[23:04] <kirkland> cjwatson: i'm using the ip address for the url rather than the hostname
[23:04] <kirkland> cjwatson: i was wondering if you had suggestions on a better way of doing that
[23:04] <kirkland> cjwatson: see debian/80-eucalyptus-url in lp:~ubuntu-core-dev/eucalyptus/ubuntu/
[23:06] <cjwatson> meh, just use IP for now, no time for cosmetics
[23:07] <cjwatson> mdz: I'll be asleep by then, I should think
[23:11] <mterry> cjwatson: dh7 question: let's say I have a simple package for a program.  It used to use cdbs/debhelper.  It has one main package and a -dbg package, didn't use .install files.  cdbs did the -dbg work magically.  Does dh7 have a toggle to allow it?  I tried naively porting the package to dh7, but the dbg stuff wasn't happening.
[23:12] <cjwatson> I think you just need something like:
[23:12] <cjwatson> override_dh_strip:
[23:12] <cjwatson>         dh_strip --dbg-package=foo-dbg
[23:12] <mterry> cjwatson: yup, did that.  But I have to make my own install file then?
[23:13] <slangasek> shouldn't, no
[23:13] <cjwatson> no, that should cause dh_strip to put the files in the appropriate build directory all by itself
[23:13] <mterry> hm
[23:13] <cjwatson> you don't generally need dh_install to act on the results of other debhelper commands
[23:13] <mterry> Maybe I'm doing something stupid then.   But the theory is just the strip override should be enough, it sounds like
[23:13] <cjwatson> DH_VERBOSE=1 is a good general debugging tool
[23:14] <mterry> k
[23:14] <cjwatson> mdz: also waiting for new d-i, if we're having new linux-meta in the next build
[23:41] <hikenboot> can anyone tell me how large the ubuntu 9.04 repositories are i am using apt-mirror to download them
[23:42] <jpds> IIRC, less than 400GB
[23:43] <hikenboot> gee wiz....that might be too much to download comcast might shut me off
[23:44] <jpds> Oh, wait, just 9.04, not sure.
[23:44] <jpds> That was the whole archive.
[23:44] <slangasek> Riddelll: your kdebase-workspace conversion doesn't remove the old conffile in the preinst
[23:59] <wgrant> lamont: I have a smallish launchpad-buildd change that needs to happen at some point soonish. I believe you're the person to which I must talk.