[00:31] <slangasek> debfx: you've tested this fix yourself, right?  I don't have a kubuntu setup here to test it on, so I can only check that the code looks right
[00:34] <slangasek> debfx: is the 'su -' actually needed? acpi-support runs as root, so shouldn't it have access to the dbus session bus anyway?
[00:34] <slangasek> (or is this done to isolate the dbus process from root privs?)
[00:36] <slangasek> debfx: btw, I don't think I received a notice of this merge proposal, in the future you might want to check that your merge proposal was requesting a review from whoever you're looking to have review it
[00:45]  * directhex invokes a release manager
[00:56] <debfx> slangasek: yeah I tested it on my kubuntu installation
[00:57] <debfx> the "su" is necessary, it doesn't work otherwise (not sure why though)
[00:58] <slangasek> ok
[00:58] <slangasek> debfx: uploaded, thanks :)
[01:01] <directhex> slangasek, do i subscribe a release manager then sponsor, or the other way round?
[01:01] <slangasek> directhex: either way is ok with me
[01:02] <directhex> (lp: #449970 FYI)
[01:04] <debfx> slangasek: ok, glad I could help :)
[01:08] <directhex> i'm all sleepy now. that's the first hard debugging session in an alien API i've had for a very long time
[01:09] <Riddell> debfx: what's this fix?
[01:11] <debfx> Riddell: powerdevil detection in acpi-support http://bazaar.launchpad.net/~ubuntu-core-dev/acpi-support/trunk/revision/163
[01:12] <Riddell> oh cool
[01:16] <YokoZar> doko_: Mind if I poke you ~ ftlk1.1 ?  https://launchpad.net/ubuntu/+source/fltk1.1  has it still FTBFS and the mismatch is blocking me from updating ia32-libs
[01:23] <directhex> YokoZar is the poor sod who looks after the most unmaintainable package ever?
[01:25] <YokoZar> directhex: mostly because I'm the biggest (ab) user of it
[01:25] <YokoZar> directhex: but yes it seems that way
[02:03] <Laibsch> Does http://packages.ubuntu.com/ubuntu-laptop-mode still serve a purpose?  It hasn't been updated for ages and there is the generic laptop-mode-tools package available.  Time for removal?  Where to request?
[02:14] <johanbr> Laibsch, I think the answers are "no, yes, file a bug" respectively
[02:14] <Laibsch> OK
[02:14] <Laibsch> Thanks
[02:15] <Laibsch> Will do
[02:15] <johanbr> you're welcome
[02:28] <Laibsch> bug 450004
[05:28] <spstarr> any reason libasound-plugins is not built with jack output?
[05:28] <spstarr> [AO_ALSA] alsa-lib: pcm.c:2171:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_jack.so
[05:28] <TheMuso> spstarr: Because jack is not in main.
[05:29] <spstarr> license problem?
[05:29] <TheMuso> No
[05:29] <spstarr> does debian build it?
[05:29] <TheMuso> If there was a license problem, it wouldn't be in the archive
[05:29] <TheMuso> spstarr: I believe so.
[05:29] <ScottK> archive/universe
[05:29] <spstarr> so then why is ubuntu turning it off(?)
[05:30] <ScottK> spstarr: Do you understand the difference between Main and Universe?
[05:31] <spstarr> not really
[05:31] <spstarr> I just want what debian provides, not isolating this from that
[05:31] <ScottK> The most relevant bit here is that Main needs to be self-contained complete, so packages in Main cannot build-depend on packages in Universe.
[05:31] <TheMuso> spstarr: If you want what debian provides, use Debian.
[05:31] <spstarr> so then move jack to Main?
[05:32] <ScottK> Part of the original plan for Ubuntu was that it would focus on an subset of the Debian archive and try to make that really shine and provide security support for it.
[05:32] <ScottK> So every time you move stuff to main, there has to be a good rationale as it ups was has to be officially supported by Canonical.
[05:32] <ScottK> There was some discussion about that this cycle, but it didn't get done.
[05:33] <spstarr> i'll just get the src deb and turn it on myself.
[05:33] <ScottK> Since TheMuso is an Ubuntu Studio dev, you're probably talking to one of the people that wants that more than most.
[05:33] <spstarr> my audio card has no PCM capture (DRM likely) and I cant record any output from it
[05:33] <spstarr> so thus I need workarounds that Ubuntu is turning off ;(
[05:34] <TheMuso> ScottK: This cycle has seen a push to get jack into main to solve just this problem, as it would allow firewire audio interface users to use their cards with alsa, if in a somewhat round-about way. But there are other reasons as well.
[05:34] <TheMuso> However, it didn't happen due to lack of time by those involves
[05:34] <TheMuso> s/involves/involved/
[05:34] <ScottK> Right.  So maybe for Lucid.
[05:35] <TheMuso> I am thinking that archive reorganisation may help resolve this problem/
[05:35] <TheMuso> ScottK: Right.
[05:36] <spstarr> im not happy at all my new laptop conveniently disables PCM capture
[05:36] <spstarr> DRM shit
[05:36] <TheMuso> spstarr: I don't think its to do with the laptop, its to do with the Linux driver, depending on what audio hardware you have.
[05:36] <jdong> I'd say you're too quick to jump to conclusions!
[05:37] <spstarr> jdong: from what I read, there is no capture on these cards at all
[05:37] <TheMuso> these cards being?
[05:38] <spstarr> │ Card: HDA Intel                                                                                                   │
[05:38] <spstarr> │ Chip: Conexant CX20561 (Hermosa)
[05:38] <TheMuso> ah ok
[05:38] <spstarr> Conexant isn't eactly FLOSS friendly at ALL
[05:38] <spstarr> with that old linuxant shit
[05:38] <spstarr> thanks Lenovo!
[05:39] <jdong> how was linuxant Conexant's fault per se?
[05:39] <spstarr> its not
[05:39] <jdong> the whole issue with a software modem is that the modem is just physically two wires
[05:39] <spstarr> but this company 'Conexant' is making things difficult for me now in Audio
[05:39] <spstarr> nevermind models
[05:39] <jdong> linuxant was a third party attempt to reimplement the modem part in software :)
[05:40] <lifeless> uhm, linuxant licensed the IP didn't they?
[05:41] <jdong> lifeless: ah yes that may have been; at least licensed some part of the IP
[05:41] <jdong> considering the DIL tone was the same as the original Conexant drivers probably more or less the entire modem software :)
[05:47] <spstarr> ooh i got it working.. almost
[05:47] <spstarr> until the audio just hangs :(
[06:50] <spstarr> hah I got it working with jack
[06:50] <spstarr> evil
[06:51] <spstarr> I can record audio from jackd via jack_capture (obscure tool)
[07:15] <pitti> Good morning
[07:16] <pitti> mdke: thanks
[07:16] <pitti> tkamppeter_: hih
[07:16] <pitti> erm, "hi"
[07:22] <mdke> pitti: it didn't work to remove the fdupes script - something else has run a similar script anyway in the package build - http://paste.ubuntu.com/292122/
[07:22] <mdke> pitti: I don't know where that has come from though, it isn't in debian/rules
[07:24] <mdke> ah, it's in /usr/share/cdbs/1/rules/debhelper.mk
[07:27] <mdke> perhaps someone can tell me how to exclude that script?
[07:29] <geofft> ... wait, do you just want to set CDBS_NO_GNOME_HELP_SYMLINKING=1?
[07:29] <mdke> geofft: yes
[07:31] <pitti> mdke: right, we do that by default now, but these aren't meant to interfere; hm
[07:31] <pitti> mdke: seems like the symlinking to help-langpacks/ is buggy then :-(
[07:32] <mdke> pitti: can't I just disable it by setting CDBS_NO_GNOME_HELP_SYMLINKING?
[07:32] <pitti> mdke: you can
[07:32] <mdke> that should work, no?
[07:32] <mdke> the help-langpack thing isn't interfering because this is a local build without that
[07:32] <pitti> it works around the problem, yes
[07:32] <mdke> I suppose all packages with Gnome documentation should be setting CDBS_NO_GNOME_HELP_SYMLINKING, not just ubuntu-docs
[07:33] <mdke> otherwise the same bug will appear in those packages, maybe
[07:37] <pitti> mdke: I should probably just disable it for now, since with stripping them out we don't need to symlink them any more
[07:37] <pitti> oh, wait, we do
[07:38] <pitti> they only point to the C version, which is already installed with the package
[07:38] <pitti> mdke: would you mind reporting a bug against cdbs with the particular failure you see, and assign it to me?
[07:38] <pitti> mdke: I'm interested in what actually goes wrong
[07:39] <dholbach> good morning
[07:40]  * mneptok waves to various .de peoples
[07:40] <mdke> pitti: ok. should I disable this in ubuntu-docs and gnome-user-docs anyway? if so, could you show me how to do it? :p
[07:41] <pitti> mdke: if it wreaks havoc, just disable it, yes
[07:41] <pitti> export CDBS_NO_GNOME_HELP_SYMLINKING=1
[07:41] <pitti> mdke: sorry, without the "export"
[07:42] <mdke> just somewhere at the top of debian/rules?
[07:42] <pitti> yes
[07:42] <mdke> ok, thanks
[07:43] <mdke> pitti: I think we can use the same bug and just open a cdbs task
[07:48] <mdke> pitti: ok, so it's bug 441401 - thanks for the help
[07:51] <pitti> mdke: thanks
[08:08]  * mvo_ hugs doko__ for his super fast python fix
[08:24] <tkamppeter> pitti, hi
[09:05] <doko> mvo_: do you have an idea about bug #448140? I do see this with other packages as well.
[09:06] <seb128> dholbach, you should stop using pbuilder for every build ;-)
[09:12] <mvo_> doko: looking
[09:12] <doko> mvo_: no info in the log, but the subject "error writing to '<standard output>': Input/output error" repeats
[09:15] <mvo_> doko: odd, nothing in the log - I will followup and move away from python (that is most certainly not a python issue)
[09:17] <mvo_> doko: there seems to be a lot of those reports
[09:17] <mvo_> hey glatzor!
[09:17] <glatzor> morning mvo_ !
[09:18] <doko> mvo_: when do these start?
[09:20] <mvo_> doko: the earliest so far is 2009-09-28, but LP is not that great for bug searches, I look further
[09:21] <mvo_> doko: my initial guess is that its packagekit releated, but I'm not sure yet
[09:22] <mvo_> hm, no. there is one report about the software-center
[09:24] <glatzor> mvo_, reports that affect me too?
[09:32] <mvo_> glatzor: I don't think so, but I'm not sure yet, its inconclusive at this point
[09:52] <AnAnt> Hello, can some sponsor this: http://revu.ubuntuwire.com/details.py?upid=6920 ? It's FFe request has been approved (LP 440153)
[10:10] <seb128> dholbach, will you sponsor that gdm update?
[10:10] <dholbach> seb128: it didn't build for me - does it build for you?
[10:12] <seb128> dholbach, I didn't try but there is no change in the build system so no reason for it to start breaking
[10:12] <seb128> dholbach, I would rather blame your pbuilder ;-)
[10:12] <seb128> let me try
[10:14] <pitti> tkamppeter: hm, seems your host name->ip change now causes build failures :-( (http://launchpadlibrarian.net/33580906/buildlog_ubuntu-karmic-i386.cups_1.4.1-5_FAILEDTOBUILD.txt.gz)
[10:16] <seb128> dholbach, build fine there, I will upload
[10:17] <seb128> is there any known libssl issue?
[10:17] <seb128> I got some gnome builds failing on -lssl not being there
[10:17] <seb128> ie some .pc or .la or something listing but not having the corresponding depends
[10:24] <dholbach> seb128: thanks
[10:33] <dholbach> shouldn't ubuntu-xplash-artwork be Arch:all?
[10:34] <seb128> dholbach, it should
[10:35] <dholbach> kenvandine: ^ :)
[10:41] <directhex> thanks ttx
[10:41] <ttx> directhex: np
[10:42] <directhex> ttx, quite embarrassing issue - but it was news to upstream (and is now my first proper upstream patch for mono, svn r143994)
[10:54] <taavikko> just wondering why I have the "vitruvian man" on my notification-area, while there's no accessibility features enabled?
[10:57] <apw> cjwatson, the _all packages, am i correct in understanding that they are actually constructed on all architecture builds, but they are only taken from i386?
[10:58] <maxb> apw: They aren't even built on any arch but i386
[10:58] <maxb> It's the difference between dpkg-buildpackage -B and -b
[10:59] <apw> so the buildd's do -B ?
[10:59] <maxb> Pretty sure they do, yes
[11:01] <apw> maxb, thanks ... makes much more sense here now ...
[11:03] <cjwatson> apw: yes, what maxb said. i386 buildds do -b and everything else does -B.
[11:03] <apw> now getting _all out of my armel builds makes sense
[11:03]  * apw mutters as he wanders off to get a bigger brain fitted
[11:34] <debfx> seb128: could you please have a look at my pidgin debdiff at bug #346840
[11:34] <debfx> it fixes that bug and provides a workaround for wrongly sized tray icon on kde
[11:36] <Riddell> yay
[11:37] <seb128> debfx, what is the rational for the scrollbar value change?
[11:39] <seb128> debfx, the kde hack looks weird too, what about fixing kde rather than adding weird hacks to pidgin?
[11:39] <seb128> debfx, I'm not sure about any of those 3 changes...
[11:40] <debfx> seb128: the preferences dialog got bigger, it needs around 700px
[11:42] <seb128> debfx, the purpose of the patch is to add scrollbars to fit on screen though no?
[11:42] <seb128> that value should match netbook resolution
[11:43] <debfx> seb128: afaik kde says the system tray specification is broken regarding to icon size and I'm not sure if it affects other desktop environments as well, but kde always uses 22x22 tray icons so the patch doesn't have negative effects on kde
[11:43] <seb128> debfx, could you upstream that workaround just to get their opinion?
[11:44] <debfx> I hope the problems are gone when pidgin switches from eggtrayicon to gtkstatusicon
[11:44] <seb128> there is no such hack in other softwares, ie rhythmbox
[11:44] <seb128> I think adding one there is not the way to go
[11:45] <debfx> are they using eggtrayicon?
[11:45] <seb128> no
[11:45] <\sh> grmpf...Karmic you have a problem
[11:45] <seb128> why is pidgin still using that?
[11:45] <seb128> the correct fix would be to port pidgin to modern apis ther
[11:45] <debfx> because they don't want to depend on higher gtk versions
[11:45] <seb128> there
[11:46] <debfx> they want to raise the gtk requirement in pidgin 2.7
[11:46] <seb128> well so if that works in gtkstatusicon there is a bug in pidgin
[11:46] <seb128> and the way to go is to fix it
[11:49] <debfx> true, but I doubt anyone will fix eggtrayicon
[11:49] <debfx> especially not in time for karmic
[11:50] <seb128> I'm not qualified to judge that hack since I've no clue about how kde is buggy there
[11:50] <seb128> and why it doesn't handle correctly icons
[11:50] <seb128> so I will not upload that hack
[11:50] <seb128> I will wait on ted's comment about the focus issue though
[11:51] <seb128> thanks for you work on that
[11:52] <debfx> regarding the scrollbars: don't we want the preference window to display correctly on 7XX resolutions?
[11:52] <Riddell> seb128: it would be polite to assume that KDE isn't buggy since every other app works fine
[11:52] <seb128> I've to go for lunch bbl
[11:52] <seb128> Riddell, and pidgin works fine in any other de too
[11:54] <seb128> debfx, we want but we want those to be displayed correctly on netbooks too
[11:54] <Riddell> seb128: so there's no reason to think which side is at fault and it's probably as debfx says the spec which is buggy and incomplete
[11:54] <seb128> the change will make it not fit on smaller screen no?
[11:55] <seb128> Riddell, whatever I don't care, I'm just not going to upload that workaround since it seems wrong, if the code is buddy fix it, that works with other applications now
[11:55] <seb128> really have to go for lunch
[11:55] <seb128> bbl
[12:03] <apw> pitti, i think we have found the FAT slow mount issue, and i've pushed some test kernels (linked in the bug) ... if we want to get it in before  kernel freeze we need to get it tested pronto
[12:04] <pitti> apw: my hero!
[12:04] <pitti> I'm happy to test them
[12:04] <apw> wicked
[12:04] <apw> it was a long old day finding that one
[12:14] <\sh> if someone could do me a favour, please review debdiff from bug #401982 and push it to the buildds? Thx :)
[12:15] <amitk> apw: so what was the issue?
[12:15] <apw> readahead requests were not merging in the elevator at all, leading to sychronous 512 byte reads of the FAT
[12:16] <\sh> brb lunch
[12:20] <amitk> apw: at the VFS layer?
[12:28]  * pitti hugs magic Andy
[12:28] <pitti> apw: it works perfectly, thanks
[12:30] <apw> pitti, wicked thanks ...
[12:31] <apw> anyone know if we are expecting fsck to trigger usplash like it used to atm?
[12:33] <pitti> apw: I think we resorted to always starting usplash onw
[12:33] <pitti> s/onw/now/
[12:33] <pitti> but in lucid, it's supposed to
[12:34] <apw> yeah i had usplash, the new sexy logo
[12:34] <apw> but then it went into 20 mounts without fsck, fsck
[12:34] <apw> and usplash said nothing then timed out and showed it to me behind
[12:34] <apw> but no sexy progress bar, no hit esc option
[12:35] <apw> pitti, ^^
[12:35] <apw> i presume that that is a bug then
[12:35] <pitti> right, looks like
[12:35] <pitti> I'll have a look at it, noted on my TODO list
[12:36] <apw> pitti, thanks
[12:36] <debfx> seb128: for netbooks nothing will change, if the screen resolution is 1024x600 it doesn't matter if I check <=600 or <=700
[12:36] <seb128> debfx, I've to read what the change do then, would be nice to give explanation in the bug next time
[12:43] <seb128> debfx, ok, the 700 change makes sense after looking at the dialog geometry in karmic, sorry about the too quick replies but I've a zillion things on my list and not always time to look at what other people wanted to do and why if there is no explanation in bugs
[12:44] <seb128> debfx, I will wait for ted to reply before sponsorting that though just to know if the other change is worth uploading too
[12:44] <seb128> debfx, I'm not sure we should change the behaviour now just before karmic, ted added that to workaround other issues
[12:49] <cjwatson> apw: you're not the first one to report that ...
[12:49] <apw> cjwatson, ok ... so i'll wait for a fix :)
[12:50] <debfx> seb128: I know but that particular calls I removed don't really help the pidgin window to appear in the front
[12:52] <seb128> debfx, ted probably added it for a reason though, it might workaround some wm behaviours or something
[12:56] <debfx> seb128: to me that patch seems like a "try everything that might help" approach, but you're right we should wait for a response from ted
[12:56] <seb128> debfx, it's sort of that yes since standard calls were not doing what is expected
[13:02] <zul> pitti: ping
[13:26] <pitti> zul: pong
[13:27] <zul> pitti: i been working on the m2crypto testsuite failure and its still not building properly
[13:27] <zul> i tried updating it my ppa and it still suffers from the same problem but it builds fine locally
[13:27] <pitti> zul: I guess it needs network of some sort?
[13:28] <zul> pitti: it looks like it but it says its connecting to a localhost
[13:28] <Hattory> Hi all is it possible that all icons and folders, after the last update in karmic, have the <ubuntuone-synchronized> emblem applied?
[13:29] <zul> pitti: i was thinking of opening up a bug in the upstream bug tracker and trying to get it fixed for lucid
[13:29] <pitti> zul: yeah, makes sense
[13:29] <pitti> zul: I think for karmic you should just || true the test suite, so that the results are in teh build logs, but it doesn't fail the build
[13:30] <zul> pitti: ok i can do that ill let you know when I uploaded it
[13:30] <pitti> apw: I like your definition of "obvious fix" :-)
[13:35] <apw> pitti, i think the fix is obviously correct even to those not looking at the rest of the code, now finding the issue ...
[13:36] <pitti> apw: I was just kidding; I didn't understand a word of your bug explanation :)
[13:36] <apw> :)
[13:39] <\sh> re
[13:48] <liw> I seem to be totally unable to track down bug #420307 -- mysterious segfaults in computer-janitor for some people. My best guess it's a python/pygtk/threading problem, but I can't see where, and I can't reproduce either. Any ideas?
[13:48] <tgpraveen> lool:  https://bugs.launchpad.net/ubuntu/+source/humanity-icon-theme/+bug/436462 can you please upload the changes for this
[13:49] <tgpraveen> it would really increase usability/visibility and is something
[13:49] <seb128> liw, get a valgrind log for the crash?
[13:49] <tgpraveen> that many people have asked for on different bugs and the change is already on upstream and has very little chance of breaking anything
[13:50] <liw> seb128, I'll ask bug submitters for that... how would they do that?
[13:50] <seb128> liw, https://wiki.ubuntu.com/Valgrind
[13:51] <seb128> liw, for python software you need to run valgrind python binary
[13:51] <seb128> not valgrind binary directly I think
[13:52] <mterry> cjwatson, it looks like you looked into sponsoring bug 430220 at some point in the past.  Can you (or Keybuk) look at it again?  I'd like to get this in before release.  It prevents delays in logging messages due to buffering (and has some cleanup as well)
[13:52] <liw> seb128, thanks, let's see what happens
[13:56] <seb128> ok
[13:56] <seb128> so the build failures in rhythmbox and totem are doko's fault
[13:57] <seb128> /usr/lib/python2.6/config/Makefile: LOCALMODLIBS=                       -lssl -lcrypto  -lssl -lcrypto      -L$(exec_prefix)/lib -lz
[13:57] <seb128> but python2.6 doesn't install those libs
[13:58] <seb128> doko, ^ do you know about that? is that something which changes recently?
[13:58] <lool> tgpraveen: I was told it's not release critical and will only consider it if I update h-i-t for another reason; it took me hours to understand + review the last icon changes I had to upload, so I'd prefer avoiding that happening again
[13:59] <doko> seb128: yes, that was a bug fix for python2.6. It's a mistake to link extensions with LOCALMODLIBS, just remove it
[13:59] <seb128> doko, it makes several packages ftbfs out of the blue, will we do an archive rebuild test to spot those now?
[13:59] <seb128> doko, otherwise I would argue to wait until karmic+1 for the fix since it breaks things which were working
[13:59] <cjwatson> 0/wg 166
[13:59] <cjwatson> (sorry
[14:00] <lool> Does someone know how to fix a non-booting system like this onw http://people.canonical.com/~lool/IMG_2345.JPG?
[14:00] <lool> One error is binfmt misc being missing in the dove kernel, not sure if that's the reason for the failure
[14:03] <seb128> doko, ?
[14:03] <doko> seb128: that was the fix for #445540
[14:03] <doko> #445530
[14:04] <seb128> bug #445540
[14:06] <seb128> bug #445530
[14:07] <seb128> doko, any reason you couldn't add the lib as python-dev depends?
[14:08] <doko> seb128: I'll look at it tonight, but it would just hide the problem.
[14:09] <seb128> doko, what problem? rhythmbox and totem and some other things fail to build right now...
[14:09] <seb128> would be nice to get that fixed quickly
[14:09] <seb128> those software have not changed and building them works fine on other distros or karmic before your change
[14:10] <doko> seb128: the correct fix is not to link with LOCALMODLIBS; I'll look at a workaround later today
[14:10] <seb128> doko, thanks
[14:11] <seb128> doko, could be but it's late now in the cycle to break all software doing that
[14:12] <doko> seb128: no, it was a fix for another bug which obviously has side effects
[14:13] <seb128> doko, ok, thanks for looking into it
[15:10] <lool> Keybuk: hey, I get http://people.canonical.com/~lool/IMG_2345.JPG with a mountall from a couple of days ago; there's notably a binfmt misc missing error (reported already) but I'm not sure what's failing the boot exactly nor how to recover
[15:10] <lool> Keybuk: I can remount / rw and mount /boot but if I ^D, only the network comes up and not gdm etc.
[15:10] <Keybuk> did you update mountall today?
[15:10] <lool> I cant find that /forcefsck thing on any fs
[15:10] <lool> Keybuk: No, I'd like to...
[15:11] <Keybuk> right, that one's fixed
[15:11] <lool> Keybuk: It's the one from one or two days ago
[15:11] <lool> Keybuk: What shall I do to resume boot?
[15:12] <lool> I have a /, a /boot, swap, all with UUID in fstab; I only have proc in fstab apart of that IIRC
[15:14] <lool> Keybuk: Do I have to manually dpkg -i mountall from an USB stick or smth?
[15:15] <mvo__> kirkland, hi - I noticed that that kvm got replaced by qemu-kvm. could you please add a transitional package to ensure that it upgrades smoothly? currently its considered obsolete and removed after a upgrade (apt is unfortunately not very clever when it comes to understand that it really should install qemu-kvm instead)
[15:16] <mvo__> kirkland, I'm happy to report a bug and/or do that myself (should be quick and easy)
[15:16] <zul> asac: yes I need tht review for libaugeas-ruby
[15:17] <mathiaz> mvo__: hi!
[15:17] <mathiaz> mvo__: thanks for adding some upgrade logic to update-manager to handle the mysql upgrade
[15:17] <mathiaz> mvo__: IIUC a plain dist-upgrade won't work in karmic
[15:18] <mathiaz> mvo__: however a do-release-upgrade will correclty update mysql-server from 5.0 to 5.1
[15:19] <mvo__> mathiaz, correct - sorry that I haven't found a good way for the plain dist-upgrade
[15:20] <mvo__> mathiaz, we should just release note it, it should be simple enough to fix for people faimilar with apt-get
[15:20] <mathiaz> mvo__: that's fine. We can document it in the release notes as well
[15:20]  * mvo__ nods
[15:20] <mathiaz> mvo__: something related to the mysql upgrade
[15:20] <mathiaz> mvo__: 5.0 supports cluster, while 5.1 doesn't
[15:21] <mathiaz> mvo__: so there is a check in the preinst script - if cluster is enabled the package upgrade fails
[15:21] <mathiaz> mvo__: I was wondering if we could some logic to update manager
[15:22] <mathiaz> mvo__: if there is a cluster configured, remove the mysql-server package (but leave mysql-server-5.0
[15:22] <mathiaz> )
[15:22] <mvo__> mathiaz, yes, we should
[15:22] <mvo__> mathiaz, how hard/reliable is it to detect ?
[15:23] <mathiaz> mvo__: reliable - it's a grep in some configuration files
[15:23] <mathiaz> mvo__: the logic is already in the preinst script
[15:23] <mathiaz> mvo__: right now the package fails with an error message
[15:23] <mvo__> mathiaz, ok cool - I can add that to the upgrade, thats pretty easy. could you just add a bug and target for 9.10 ? I will do it today
[15:24] <mathiaz> mvo__: ok - I'll file a bug
[15:24] <mvo__> mathiaz, thanks
[15:25] <lamont> so how do I get something wider than 1 pixel borders on my windows again?  grabbing the little beggars with the thumbpad is kinda challenging
[15:32] <Gp> i ma getting Invalid execution envioroment at grub
[15:32] <Gp> i ma getting Invalid execution envioroment at grub
[15:35] <cjwatson> Gp: I don't think you are; I think you're more likely to be getting the message "invalid: environment block"
[15:35] <cjwatson> Gp: see bug 439784
[15:37] <scoop21> Einen wunderschönen Tag zusammen
[15:41] <lamont> Well, this is embarrassing.  <-- yay for firefox. :-(
[15:42] <wolfe> ?
[15:42] <lamont> amusingly, leaving all the tabs selected and choosing 'restore' gets me a working firefox
[15:42] <lamont> wolfe: firefox can't restore the session
[15:43] <wolfe> :) oh how I know that too well
[15:43] <lamont> I wonder if it has anything to do with needing passwords to loginto stuff
[15:43] <wolfe> I've disabled much of the bloat which causes firefox to mess up
[15:43] <lamont> wolfe: execpt for the part where the session restores just fine when you say "oh, try anyway, kthx"
[15:43] <wolfe> yeah... isn't that nice?
[15:44] <wolfe> it crashed on me twice yesterday when I had all the default bloat enabled, and FF actually apologized asking which session to restore
[15:44] <scoop21> Hi guys in the house
[15:44] <sistpoty|work> maybe a procrastination avoidance feature? :P
[15:44] <wolfe> heh
[15:49] <lamont> I do hate it when coders think their program should apologize.  just wrong.
[15:50] <LaserJock> lamont: I suppose it's better than having them insult you
[15:50] <lamont> LaserJock: pretty much the same, actually
[15:50] <LaserJock> it's more like an insult with a smile
[15:51] <liw> lamont, my most sincere and humble apologies for having written a program that apologized, please let me assure in the strongest possible way that this will not be a unique instance
[15:51] <lamont> liw: meh
[15:51] <liw> :)
[15:52] <lamont> window panel bar is totally weird, too.
[15:52] <lamont> so if anyone asks, no, you many not like the results of running a jaunty kernel with your karmic system
[15:52] <scoop21> does anybody tried to install karmic on a laptop?
[15:53] <lamont> scoop21: aside from loosing support for winxppro sp>=2 in kvm, it's been working pretty OK for me
[15:53] <lamont> some _might_ see that as a feature
[15:53] <scoop21> lamont: do you tried to plugging ac/battery?
[15:54] <lamont> liw: long ago I came to realize that parts of the kernel have gender.  Then I realized that gender  was based on who owned that component in the OS I  was working on a the time.
[15:54] <lamont> scoop21: suspend/resume even works much of the time - big improvement over the last time I tried it.
[15:54] <lamont> and yeah, AC and battery op both happy
[15:54] <kirkland> mvo: hi
[15:55] <lamont> haven't tried hibernaet yet
[15:55] <Gp> https://bugzilla.mozilla.org/show_bug.cgi?id=439784 not opening
[15:55] <kirkland> mvo: would you mind sending me a quick debdiff for the transitional package?
[15:55] <kirkland> mvo: i'm working on a couple of other high priority things at the moment :-/
[15:55] <kirkland> mvo: including adding a critical patch to qemu-kvm
[15:55] <mvo> kirkland: sure, I can also do the upload
[15:55] <mvo> kirkland: oh, ok
[15:56] <kirkland> mvo: i'd like to fix both with the same upload
[15:56] <mvo> kirkland: yeah, I file a bug with patch then - or is there a vcs I should use?
[15:56] <scoop21> lamont: mhh, tried to boot with both ac and battery and than plugged ac out and so?
[15:56] <kirkland> mvo: bug with patch is best for now
[15:56] <spaetz> scoop21, works like a charme here
[15:57] <mvo> kirkland: thanks
[15:57] <lamont> scoop21: booted with and without AC, plugged and unplugged, even suspended.. all with good happiness.
[15:57] <kirkland> mvo: thank you :-)
[15:57] <lamont> OTOH, networkmangler has decided that eth0 is non-existant
[15:57] <lamont> brb
[16:02] <scoop21> lamont: which label do you have?
[16:03] <lamont> scoop21: label?
[16:03] <lamont> the laptop is a dell inspiron 1520 with an ubuntu label. :-)
[16:04] <lamont> gory details of the machine in bug 445456
[16:04] <scoop21> lamont: haha, yes i meant the producer
[16:12] <liw> mvo, there's at least two instances of openoffice packages being corrupted (uno and ure packages)... update-manager does check the checksums, so that's worrying
[16:13] <scoop21> lamont: you hasn't that bug too? -> https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/432838
[16:13] <mvo> liw: it is - my theory is currently that it arrives ok from the net and gets corrupted when writing out to disk - i have test code that tries to download files with invalid checksums and that errors out
[16:13] <mvo> liw: but I'm still worried because its just so scary
[16:13] <LaserJock> james_w: is http://jameswestby.net/bzr/builddeb/user_manual/ an authoritative place to get info on using bzr-builddeb?
[16:15] <liw> mvo, given that oo.o files tend to be a bit large, I guess it's possible that two people would have problems with them, but it's still a bit of a coincidence
[16:15] <zul> pitti: it still fails if I add the || true
[16:15] <mvo> liw: it calculates the checksum from the network data, not from the on-disk data (maybe it should)
[16:15] <mvo> liw: absolutely!
[16:17] <lamont> scoop21:  sounds like you have ntp coming up and snapping your clock forward far enough for gnome to go "ZOMG long time idle -> suspend"
[16:17] <lamont> go edit things to not suspend for a couple hours or more of idle, and see if that makes it go away
[16:19] <mathiaz> cr3: hi
[16:20] <mathiaz> cr3: re checkbox sponsorship request - there are some new strings in there
[16:20] <cr3> mathiaz: yo
[16:20] <mathiaz> cr3: and we're in String Freeze
[16:20] <cr3> mathiaz: new strings?
[16:20] <scoop21> lamont: i tried to change something but there are no much possiblity
[16:20] <mathiaz> cr3: po/checkbox.pot
[16:21] <mathiaz> cr3: some new strings, some have been removed
[16:22] <mathiaz> cr3: 'Fixed backend to use dbus instead of policykit' <- how is that a bug fix rather than a new feature?
[16:22] <cr3> just the string "Info" has been added, maybe I could remove that
[16:23] <cr3> mathiaz: I needed to either migrate to polkit-1 or just use dbus, pitti and I agreed it would be preferable to just use dbus
[16:23] <mathiaz> cr3: and this is acceptable for karmic?
[16:24] <pitti> mathiaz: the old policykit is deprecated, and it's not even installed any more
[16:24] <pitti> mathiaz: which means that checkbox doesn't work at all ATM
[16:24] <mathiaz> pitti: ok
[16:24] <pitti> mathiaz: so at the very least, it needs to grow a policykit dependency to work at all
[16:24] <pitti> but it'd be the only thing which needs it
[16:25] <cr3> mathiaz: fyi, pitti also reviewed my change and he approved the dbus part
[16:25] <pitti> mathiaz: the actual PK changes in that branch are essentially "remove all PK code"; there are other (unrelated) code changes which I couldn't assess
[16:25] <lamont> right.. back to a karmic kernel
[16:26] <cr3> mathiaz: the other unrelated code changes were because the old policykit wasn't even working before and had been neglected, so I needed to update the code accordingly
[16:26] <james_w> LaserJock: /usr/share/doc/bzr-builddeb or there
[16:27] <LaserJock> james_w: k
[16:27] <cr3> mathiaz: this problem had been worked around by using gksudo instead of using the dbus backend, but that was an unfortunate hack
[16:36] <Aji-Dahaka> fellas, I reported a bug (449935) which was marked duplicate of a non-public bug (443340) by apport service.  The message asks me to look at the other bug report, though I can not.  What does one do to address this situation?
[16:36] <Aji-Dahaka> (if this is actually a #ubuntu question, let me know and I'll migrate it there)
[16:36] <Aji-Dahaka> join #ubuntu
[16:36] <Aji-Dahaka> (sorry, missed the / *sigh*)
[16:36] <kirkland> mvo: would you ping me here when you file that bug/patch?
[16:37] <kirkland> mvo: i'm building/testing my other changes now
[16:37] <mvo> kirkland: sure, I'm test-building (to be sure its all good) currently
[16:38] <kirkland> mvo: cool, thanks
[16:39] <mvo> liw: I just created a fault-injecting proxy and get a error (as expected) - not only one, loads of them .)
[16:40] <liw> mvo, whee
[16:40] <mvo> (checksum mismatch)
[16:40] <liw> I'd expect checksum mismatches if packages got garbled on the wire
[16:40] <mvo> liw: yes, that is whats happening
[16:41] <mvo> liw: the file does not make it on disk
[16:41] <Keybuk> mvo: I keep seeing lots of duplicates of "standard output: No such file or directory" errors from apport about upgrades
[16:41] <liw> mvo, but the bug reports had errors at a later stage, so your theory of corruption happening while writing to disk seems fair
[16:41] <mvo> Keybuk: I looked into that briefly this morning without much success, no pattern yet afaics
[16:42] <mvo> liw: it may well be something in the apt http downoader that write the data out wrongly
[16:42] <Keybuk> mvo: indeed
[16:43] <Keybuk> I've had that reported for a number of different packages
[16:43] <Keybuk> including mountall, which has no maintainer scripts *at all*
[16:43] <mvo> Keybuk: I have done a LP search and see about ~30 or so of them
[16:43] <mvo> Keybuk: yeah, eglibc
[16:43] <mvo> and the like, initially it looked like kpackagekit, but I got one report from software-center too
[16:43] <Keybuk> right, I initially thought kpackagekit too
[16:43] <Keybuk> in fact, I started assigning them there to begin with
[16:44] <mvo> oh, that was you then :P
[16:44] <Keybuk> the two more recent ones weren't with that though
[16:44] <Keybuk> :p
[16:44] <Keybuk> mvo: I've probably had more reasons than most to be on top of my bugs folder these last couple of weeks
[16:44] <mvo> there is/was a similar bug in kpackagekit
[16:45] <mvo> don't talk to me about my bug folder, that makes me cry
[16:45] <Keybuk> mine has zero unread ;P
[16:45] <mvo> Keybuk: heh :) because of the upstart changes?
[16:45] <mvo> zero? impressive!
[16:45]  * mvo hands Keybuk a virtual cup of finest green tea
[16:46] <Keybuk> all bugs are either in "know what causes it, it's in my notebook to fix" ... "know what causes it, I'll fix it later" ... "no idea, too low priority to care about" ... or ... "needs more info" stages :p
[16:46] <Keybuk> mvo: I still can't beat seb on the bug traffic volume though
[16:47] <mvo> haha - he got *years* of experience and probably a twin brother that he hides from us
[16:48] <Keybuk> wasn't it you that had the twin brother? :p
[16:48] <davmor2> Keybuk: No he has a clone :D
[16:49] <liw> I'm convinced seb128 is just a front for a secret French government agency that processes bug reports on the same supercomputer Lucas uses
[16:49] <Keybuk> cjwatson: so I think there must be still a usplash b ug
[16:49] <Keybuk> if I boot with "splash" my consoles are corrupted when I switch away from X
[16:50] <liw> mvo, bug #412806 seems weird... we've not had to start update-manager as root for several releases, have we?
[16:51] <mvo> liw: *weh* it was noever setuid
[16:51] <mvo> liw: and yeah, no need to run it as root since ages
[16:51] <cjwatson> Keybuk: hmm, I had that until I arranged to be more careful about tearing down usplash before X starts
[16:51] <cjwatson> Keybuk: can you tell whether that's happening?
[16:51] <cjwatson> I guess an upstart debug log might be handy
[16:51] <Keybuk> cjwatson: "more careful" ?
[16:51] <mvo> Keybuk: a twin sister, but she refuses to do work for me :P
[16:52] <Keybuk> mvo: ah, that was it! :)
[16:52] <Keybuk> cjwatson: yeah, was going to stick a log-priority debug in there somewhere and see if I could capture the job transitions
[16:52] <liw> I haven't had this many false highlights since twin peaks went out of style
[16:53] <cjwatson> Keybuk: I think I cavalierly tried to start X without tearing down usplash at one point during testing :-)
[16:53] <liw> mvo, but in very ancient times it was necessary to start u-m with sudo, wasn't it? anyway, I'll note that it shouldn't be needed in the bug
[16:53] <mvo> liw: yeah, a long time ago
[16:54] <Keybuk> cjwatson: yeah, the whole starting-dm thing should be enough
[16:54] <PedroLeKoi> Riddell: I wrote the iso file on a CD and I am trying to run that CD now one way or the other.
[16:54] <Keybuk> there won't be a usplash process when that finishes, etc.
[16:54] <PedroLeKoi> Riddell: Thing is that the boot process is interrupted pretty early.
[16:54] <PedroLeKoi> Riddell: Error message:
[16:54] <PedroLeKoi> Riddell: (initramfs) ata2.0: revalidation failed (errno=-5)
[16:54] <PedroLeKoi> Riddell:     ata2: COMRESET failed (errno=-16)
[16:54] <PedroLeKoi> Riddell:     ata2: exception Emask 0x1 SAct 0x0 action 0x0 t4
[16:54] <PedroLeKoi> Riddell:     ata2: irq_stat 0x40000008
[16:54] <Keybuk> I wonder whether this is actually something to do with the nvidia agpgart or driver
[16:54] <mvo> liw: it looks like for some reaosn his permissions are (very) wrong
[16:55] <Riddell> PedroLeKoi: it doesn't boot up into a running live CD system?
[16:55] <PedroLeKoi> Riddell: Right.
[16:56] <Riddell> PedroLeKoi: maybe the CD did not burn properly, do you have another CD you could burn to?
[16:57] <PedroLeKoi> Riddell: What is the meaning of 'ata2'. Does it mean the (sata) hdd, partition 2?
[16:58] <Riddell> PedroLeKoi: I don't honestly know.  it's possible your hardware is too new for hardy so it's not possible to run the install at all
[16:59] <PedroLeKoi> Riddell: Maybe it's just because I formatted the hdd with 'ext3'?
[17:00] <PedroLeKoi> Riddell: If that is the reason I can take an other live CD to reformat the partition.
[17:00] <cjwatson> ata2 is more likely to mean the third disk the kernel has seen on the ata bug
[17:00] <cjwatson> bus
[17:01] <Riddell> PedroLeKoi: your hard disk formatting doesn't matter, it's not using the hard disk
[17:02] <Riddell> PedroLeKoi: try burning another CD and if that doesn't work we can use a chroot instead for the install
[17:02] <PedroLeKoi> cjwatson: So it's maybe a question of the amount of data? sda0: swap, 4GB; sda1: /, 40GB; sda2: /home, 150GB.
[17:03] <Riddell> PedroLeKoi: no that won't be a problem
[17:03] <liw> do we support direct upgrades from LTS to each release before the next LTS? or should the upgrades go through intermediate releases? i.e., hardy->karmic or hardy->intrepid->jaunty->karmic?
[17:04] <Riddell> PedroLeKoi: please join #kubuntu-devel, this channel is a bit too general
[17:04] <PedroLeKoi> Riddell: I am working on my second laptop right now. This one is much older than the former one. So I am going to try to run the live CD on that one first. I am pretty sure that the CD is allright.
[17:08] <liw> heh, a bug report with a video of the bug as the attachment
[17:08] <Riddell> malone will soon be replaced with youtube
[17:08] <mvo> much more fun this way too
[17:08] <liw> (#450451)
[17:09] <liw> mvo, and he's using a funny font, too
[17:11] <davmor2> liw: sometimes it's easier to describe it and have the dev understand what your on about too :)
[17:12] <liw> davmor2, sure, it's an excellent idea
[17:15] <liw> only problem is... after I mentioned the bug number, LP stopped talking to me :P
[17:17] <mvo> liw: he does :)
[17:19] <debfx> tedg: could you please have a look at bug #346840, it seems to be caused by your buddy_list_really_show patch
[17:25] <joaopinto> Keybuk, I also have corrupted VTs with ATI, so it's not nvidia related
[17:26] <cjwatson> s/not/not only/
[17:26] <cjwatson> (I'm on Intel here and it works fine ... of course this could be a red herring)
[17:27] <Keybuk> indeed, it's just a wild guess
[17:29] <davmor2> Keybuk: I can confirm on ati on nvidia on both nv and nvidia, radion and fglrx drivers if that helps.  In fact intel is the only one without the issue
[17:32] <joaopinto> aren't we a bitt advanced on the dev cycle to be experimenting boot changes ?
[17:34] <cjwatson> joaopinto: consequence of boot changes made at alpha 6
[17:49] <superm1> mvo, re bug 413789, how will someone know if they have the update manager with this fix in it?
[17:50] <kirkland> cjwatson: around?
[17:51] <kirkland> cjwatson: i think this is a typo, want to check with you though
[17:51] <kirkland> cjwatson: $ grep -n configure_interface eucalyptus-udeb.finish-install
[17:51] <kirkland> 156:configure_interface () {
[17:51] <kirkland> 235:    configure_interfaces
[17:51] <cjwatson> kirkland: yes, that's a typo
[17:51] <cjwatson> should be configure_interfaces in both places
[17:52] <cjwatson> nice catch
[17:52] <kirkland> cjwatson: i wonder if that might help our dhcp/static issue
[17:52] <cjwatson> worth a go
[17:52] <kirkland> cjwatson: i was just fixing that with some nasty grepping and sedding
[17:53] <kirkland> cjwatson: what's the best way for me to inject this change into an install?
[17:53] <joaopinto> superm1, once the package which fixs that bug get's built it will set the bug to fix released and will display the version
[17:53] <kirkland> cjwatson: build the udeb and copy into the install ?
[17:53] <superm1> joaopinto, there is no update-manager task for it
[17:54] <joaopinto> superm1, ah :|
[17:55] <statik> hi slangasek, do you have 10 minutes for a phone call? I'd like to get some advice/guidance from you on evaluating the risk of a couchdb update
[17:56] <cjwatson> kirkland: nah, just edit /usr/lib/finish-install.d/whatever with nano
[18:03] <kirkland> cjwatson: perfect; willd o
[18:03] <kirkland> will do
[18:07] <Keybuk> joaopinto: I'd still rather play around now than before LTS beta ;)
[18:09] <joaopinto> Keybuk, sure, but still it's an high risk change during post beta :P
[18:10] <Keybuk> which are you talking about?
[18:10] <joaopinto> Keybuk, broken VTs
[18:10] <cjwatson> the change wasn't "break people's VTs, we'll fix it up later"
[18:10] <Keybuk> joaopinto: well, that kind of change would be a "bug fix" :)
[18:10] <cjwatson> the change was to fix other high-priority bugs
[18:11] <cjwatson> and whatever this is appears to have been an unforeseen consequence
[18:11] <joaopinto> ah ok, so it's a fix, sorry
[18:11] <cjwatson> assuming of course that this was caused by usplash changes
[18:13] <Keybuk> bugs are a bit like bubbles in wallpaper
[18:13] <Keybuk> when you push one out, another one appears somewhere else
[18:13] <Keybuk> the aim of the release is to make sure that they're all hidden behind bits of furniture
[18:14] <robbiew> fwiw, I have the no VTs issue on my nvidia box, if you guys need some debugging or testing...just let me know
[18:15] <Keybuk> well, the first obvious test will be to stick "sleep 10" in between usplash exiting and gdm starting ;)
[18:21] <free> mathiaz: hey
[18:22] <robbiew> Keybuk: and where would I put that sleep
[18:23] <Keybuk> robbiew: in /etc/init/gdm.conf after the initctl emit
[18:24] <robbiew> l
[18:24] <robbiew> k
[18:28] <robbiew> Keybuk: no change
[18:28] <Keybuk> that's interesting
[18:28] <Keybuk> that tells us that this is a pure usplash bug
[18:28] <Keybuk> and it's not racing with gdm
[18:31] <Keybuk> robbiew: here's another fun experiment
[18:31] <Keybuk> remove that sleep
[18:31] <Keybuk> but then comment out the "start on" lines of the gdm.conf
[18:31] <Keybuk> then boot
[18:32] <robbiew> ok...back in a min
[18:33] <oroz> can someone help me turn off "Emulate3Buttons"?
[18:37] <robbiew> Keybuk: that was worse, as there was no tty or gdm sessions..I had to remote login and start
[18:37] <Keybuk> ok
[18:37] <Keybuk> definitely just a usplash bug then
[18:37] <Keybuk> was the display black or corrupted?
[18:38] <robbiew> black...and nothing happened when I tried switching VTs
[18:38] <stefanlsd> who would be the right channel or person to help me with access to people.ubuntu.com?
[18:38] <Keybuk> cool
[18:38] <Keybuk> that fits what I've seen too
[18:41] <joaopinto> the VT problem was introduced with the latest usplash update right ?
[18:46] <cjwatson> joaopinto: we don't know for sure
[18:47] <Keybuk> I'm out for a bit, will look into this when I get back unless someone beats me
[18:47] <Keybuk> just confirmed both of robbie's tests, so I should be able to debug
[18:50] <mathiaz> free: hi!
[18:56] <free> mathiaz: I just sent you an email about the landscape-client
[18:56] <mathiaz> free: right
[18:56] <mathiaz> free: I'll look into that later
[18:56] <free> mathiaz: awesome! thank you
[19:10] <joaopinto> virtualbox VTs gets a funny (wide) resolution
[19:10] <kirkland> cjwatson: okay, that one-char fix didn't solve the static ip bug, but I have about 5-lines that does
[19:10] <kirkland> cjwatson: let me pastebin that for you...
[19:23] <kirkland> cjwatson: http://paste.ubuntu.com/292543/
[19:23] <kirkland> cjwatson: i think that should do it; i'm testing now
[19:25] <NCommander> mterry, ping? You around?
[19:28] <mterry> NCommander: yes
[19:29] <NCommander> mterry, I need a promotion for partman-uboot which is a minor installer component which is only present in the live system. Do I really need a full blown MIR for it?
[19:33] <mterry> NCommander: I assume so.  It can be a somewhat brief MIR.  I'm not comfortable enough with my MIR role to start blessing corner-cutting.  :)
[19:38] <cjwatson> kirkland: if that works with busybox sed (and, well, generally works), then it's cool by me!
[19:38] <kirkland> cjwatson: the backreferences work, yes
[19:38] <kirkland> cjwatson: i'm installing end-to-end now to test
[19:41] <NCommander> mterry, I should be done with the MIR in another 10-15 minutes, if your still around, mind handling it?
[19:42] <mterry> NCommander: sure
[19:43] <LaserJock> cjwatson: were you able to find the issue with the d-i on the Edubuntu DVD?
[19:44] <kirkland> cjwatson: works like champ!
[19:44] <kirkland> ttx: the static/dhcp network configuration issue is solved!
[19:45] <ttx> kirkland: yay
[19:47] <NCommander> mterry, https://bugs.edge.launchpad.net/ubuntu/+source/partman-uboot/+bug/450605
[19:47]  * mterry reads
[19:53] <kirkland> cjwatson: ttx: i'm regression testing the diff against dhcp nodes
[19:53] <mterry> NCommander: this is just a split package from something that was already in main?
[19:56] <NCommander> mterry, no, the original is in universe(?)
[19:56]  * NCommander isn't sure if it sync'ed across because Soyuz used to reject packages that had no build candidates
[19:56] <mterry> NCommander: ah
[19:57] <slangasek> superm1, cody-somerville: are things working better with the latest dailies?  the dbus problem should be fixed now
[19:57] <cody-somerville> slangasek, it is indeed fixed
[19:57] <slangasek> and the updated mountall is included in all ISOs
[19:57] <slangasek> ok, cool
[19:57] <cody-somerville> kudos
[20:00] <kenvandine> robbiew, ping
[20:00] <robbiew> pong
[20:00] <kenvandine> robbiew, when you had that crash in empathy doing audio/video
[20:00] <superm1> slangasek, yes much better wrg to that problem
[20:01] <kenvandine> robbiew, did you see a spike in cpu load by chance?
[20:01] <robbiew> kenvandine: I honestly don't remember, sorry.  Do you need me to try another call and let you know
[20:01] <robbiew> ?
[20:01] <kenvandine> nah
[20:01] <kenvandine> let me ask around
[20:01] <kenvandine> :)
[20:02] <kenvandine> i think i have an idea where the problem is
[20:03] <robbiew> ok
[20:06] <superm1> slangasek, i did come across bug 448988 though, which i've milestoned since that was explicitly added functionality
[20:14] <mathiaz> cr3: is checkbox documented?
[20:15] <mathiaz> cr3: are there any reference to checkbox in the Ubuntu documentation?
[20:15] <cjwatson> LaserJock: remind me what it was?
[20:16] <cr3> mathiaz: not as far as I know, is there any particular consideration you had in mind?
[20:16] <LaserJock> cjwatson: I get something about multiverse Packages file can't be found
[20:16] <mathiaz> cr3: the changes in debian/checkbox.pot
[20:17] <mathiaz> cr3: the addition of the Info string
[20:17] <mathiaz> cr3: it may have an impact on documentation and translation
[20:17] <LaserJock> cjwatson: and then in the other VT it says it can't find libnewt0.52, libuuid1, ext2-modules, and efi-modules
[20:19] <kirkland> cjwatson: ttx: fix looks good, working on both static and dhcp networking
[20:19] <kirkland> cjwatson: ttx i'm committing
[20:19] <cr3> mathiaz: I'm quite positive this level of detail about checkbox is not documented, I'm willing to bet my non-existent reputation on it :)
[20:19] <cjwatson> LaserJock: oh, right, that was a cdimage bug
[20:20] <cjwatson> LaserJock: not yet but on the list, sorry I haven't managed it yet
[20:20] <LaserJock> cjwatson: np, just trying to keep an eye on it
[20:20] <ttx> kirkland: ok
[20:21] <cjwatson> hmm, scanpackages is kind of unconditional
[20:21] <mathiaz> cr3: what kind of testing did you do on 0.8.4?
[20:24] <cr3> mathiaz: I just tested upgrading and running it, but I've also asked davmor2 and fader to kick the tires. one moment, I'll see what was their feedback
[20:26] <simon-o> fabrice_sp_: bug 447245 has a branch attached which contains the fix. If you need a debdiff I can surely provide it, but imho merging the branch is easier
[20:28] <mdke> pitti: around?
[20:30] <fabrice_sp_> simon-o, I still have to learn how to deal with branch and merging... I'm used to debdiff :-/
[20:30] <simon-o> fabrice_sp_: ok, no problem I'll attach a debdiff
[20:30] <simon-o> fabrice_sp_: thanks for sponsoring :)
[20:30] <fabrice_sp_> thansk ;-)
[20:30] <fabrice_sp_> thanks for taking care of the bug ;-)
[20:31] <simon-o> fabrice_sp_: Here is the diff from the merge proposal, is that ok? https://launchpadlibrarian.net/33593085/uIn3Ug7FHgtr2ECEckVu5bKom4a.txt
[20:32] <fabrice_sp_> seems good
[20:32] <fabrice_sp_> simon-o, ^
[20:33] <simon-o> fabrice_sp_: great.
[20:36] <simon-o> it would be really cool if someone could sponsor bug 428104 for main. This is a regression and should make it into karmic.
[20:41] <kees> cody-somerville: want to use your new super-power for 428104?  :)
[20:41] <mathiaz> cr3: hm - I've tried to run checkbox-cli
[20:41] <mathiaz> cr3: and selected network test (f)
[20:42] <mathiaz> cr3: I was then prompted for two fingerprint reader tests, and a firewire tests
[20:42] <mathiaz> cr3: which I've skipped - and then a report has been generated
[20:42] <cody-somerville> kees, sure thing :)
[20:42] <mathiaz> cr3: is this normal?
[20:42] <cr3> mathiaz: I'm trying to figure out whether this problem was there before
[20:42] <cr3> mathiaz: there may still be a bug or two, this candidate release doesn't necessarily fix everything
[20:43] <mathiaz> cr3: I saw something similar with the fingerprint reader a couple of months ago
[20:43] <mathiaz> cr3: I was never prompted for the firewire test though
[20:43] <simon-o> cody-somerville, kees: thanks
[20:44] <mathiaz> cr3: http://paste.ubuntu.com/292588/
[20:44] <mathiaz> cr3: is there a prompt missing here somewhere?
[20:44] <mathiaz> cr3: I was never prompted for an email adresse
[20:45] <kklimonda> kees, would it be possible to get a micro release exception for Django? Upstream has a strict API policy and lots of regression tests..
[20:45] <mathiaz> cr3: http://paste.ubuntu.com/292590/
[20:46] <mathiaz> cr3: ^^ this is when I tried to enter an email address when nothing was happening
[20:52] <slangasek> does someone know what changed recently to pull ibus-qt4 into the Ubuntu CDs?
[20:52] <slangasek> was ibus-qt4 recently promoted to main?
[20:53] <cr3> mathiaz: looking into that problem and I just fixed bug #450673 at the same time
[20:54] <slangasek> mm, indeed it was
[20:54] <cr3> mathiaz: that problem was there before, just thought I'd fix while we're at it
[20:54] <pitti> slangasek: hm, should we fix "Recommends: ibus-gtk, ibus-qt4" to have s/,/|/ ?
[20:55] <slangasek> pitti: yes; do you want to take care of it?  If not, I was about to
[20:55] <pitti> can do
[20:55] <slangasek> bug #449966
[20:57] <cjwatson> might want to seed one or the other in each desktop seed, if that hasn't been done already?
[20:57] <pitti> kubuntu does already (both desktop and netbook)
[20:59] <pitti> uploaded
[20:59] <slangasek> pitti: thanks!
[20:59] <slangasek> now for the other problem, why is a new 4MB openoffice.org style package being pulled in
[21:02] <pitti> cjwatson, Keybuk: can you please point me to what you changed to have usplash not QUITed on shutdown? (the change that caused the fade-out effect to disappear); I'd like to split QUIT into the old QUIT and a FADEOUT command, so that we'll just send the latter
[21:02] <slangasek> ... because the latest openoffice.org upload has changed the dependencies of openoffice.org-common, nice
[21:03] <pitti> slangasek: ccheney plans a final upload on Thursday or Friday FYI
[21:03] <slangasek> pitti: the question is, why are random parts of the Ubuntu delta dropped in this merge?
[21:06] <cjwatson> pitti: r310
[21:06] <pitti> cjwatson: ah, thank you
[21:06] <kirkland> could a build admin please bump https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1290730 to build ASAP ?
[21:07] <kirkland> cjwatson: ^
[21:07] <pitti> doing
[21:07] <pitti> kirkland: there
[21:07] <kirkland> pitti: cheers, thanks
[21:07] <mathiaz> cr3: so are you planning a new merge proposal?
[21:08] <kirkland> pitti: re http://bugs.freedesktop.org/show_bug.cgi?id=23196
[21:08] <kirkland> pitti: i've had no time whatsover for ecryptfs
[21:08] <cr3> mathiaz: I think that would be the right thing to do, although I suspect the problems you are reporting might already exist in 0.8.3
[21:08] <kirkland> pitti: eucalyptus has totally swallowed my life
[21:08] <pitti> kirkland: understandably :) but it's not a regression really
[21:09] <mathiaz> cr3: well - it makes testing complicated
[21:09] <cr3> mathiaz: however, I'm quite pleased to fix those problems right away and submit another merge proposal so that you only have to do one
[21:09] <mathiaz> cr3: as I can't validate a full test
[21:09] <cr3> mathiaz: good point
[21:09] <mathiaz> cr3: I think it would be great to fix this bugs
[21:09] <mathiaz> cr3: otherwise checkbox-cli doesn't work
[21:09] <mathiaz> cr3: hm - well - it works
[21:10] <mathiaz> cr3: you could always submit the report afterwards
[21:10] <mathiaz> cr3: since it's saved on the system
[21:17] <mdke> perhaps someone could give me a hand. I tried to set a cdbs setting in debian/rules but it doesn't seem to have worked. debian/rules is at http://paste.ubuntu.com/292579/ (line 8) and the build log is at http://paste.ubuntu.com/292580/ - any ideas welcome!!
[21:18] <pitti> mdke: ah, sorry, forgot that; debhelper.mk checks an environment variable, not a make variable
[21:19] <LaserJock> is postinst run on a package ugprade?
[21:20] <pitti> mdke: so, you do need to do "export CDBS_NO_GNOME_HELP_SYMLINKING=1" after all
[21:20] <pitti> LaserJock: yes, with "configure <previously configured version>"
[21:22] <mdke> pitti: I can just do a straight swap in line 8 for that?
[21:23] <pitti> mdke: just prepend "export "
[21:23] <mdke> pitti: awesome, thanks. Ok - will try the build again
[21:48] <beuno> pitti, hi. Would you now who can look at bug 431023?
[21:48] <beuno> it's been happening more frequently lately, and it seems to get a lot of dupes
[21:52] <simon-o> james_w: Hi, I had a merge proposal for a bug, but it was sponsored the "traditional way" (with a debdiff) what do I do now with the MP? Delete it or keep it open?
[21:53] <james_w> hey simon-o
[21:53] <simon-o> hi
[21:53] <james_w> simon-o: you can delete it
[21:53] <simon-o> james_w: ok, but how gets the branch updated?
[21:54] <james_w> there is a bot running that sees the upload and updates the branch
[21:54] <james_w> your branch won't be merged, but your changes will get in to the branch, with you recorded as the author
[21:54] <james_w> what package was it?
[21:54] <seb128> chrisccoulson, ^ in case you fancy looking to a gpm crasher rather
[21:54] <simon-o> james_w: basket
[21:55] <simon-o> james_w: that was the information I was looking for. I sometimes see packages where the branches are outdated, so I guess the bot failed there
[21:55] <lifeless> james_w: hi
[21:56] <chrisccoulson> heh, lots of crashers to look at.
[21:56] <pitti> beuno: can you reproduce it?
[21:56] <chrisccoulson> so, the g-p-m crasher is triggered on a signal from dk-power
[21:56] <chrisccoulson> gpm_manager_client_changed_cb
[21:57] <pitti> beuno: I looked at the code, and it seems that there's one possible code path which could trigger this
[21:57] <pitti> chrisccoulson: looking at 431023 ?
[21:57] <chrisccoulson> pitti - i just took a very quick glance at the stacktrace
[21:57] <beuno> pitti, not on demand, no. It happens once or twice a day, usually when I unplug the powewr adaptor or resume
[21:57] <james_w> simon-o: yeah, it's not as robust as I would like yet
[21:57] <james_w> hi lifeless
[21:57] <pitti> chrisccoulson: right, I downloaded that older version and checked, but line 101 isn't correct
[21:58] <pitti> chrisccoulson: my best guess is that disks->priv->cookie == NULL, and it segfaults in the last egg_debug
[21:58] <simon-o> james_w: thanks. I'll have a look next time I see an outdated branch, maybe there's some way to fix it.
[21:58] <chrisccoulson> yeah, i've not had a look in any detail yet
[21:58] <pitti> chrisccoulson: it checks for NULL in the first if, but not in the last egg_debug
[21:58] <seb128> pitti, <pitti> chrisccoulson: right, I downloaded that older version and checked, but line 101 isn't correct
[21:58] <james_w> simon-o: when you see one if you can drop me a message that would be great
[21:58] <simon-o> james_w: sure, I'll do. thanks
[21:58] <seb128> pitti, how come that we don't source stacktrace? did that break again in karmic cycle?
[21:59] <james_w> simon-o: the failure reasons aren't publically accessible currently, but I can look for you no trouble
[21:59] <pitti> seb128: no deb-src lines apparently; I think we disabled them back then when xulrunner did weird stuff on "patch" and hung them
[21:59] <seb128> pitti, oh, that xulrunner thing again, right
[21:59] <seb128> pitti, thanks
[22:00] <pitti> chrisccoulson: humm, no, "ret = 0", so the last egg_debug shouldn't trigger
[22:01]  * chrisccoulson should probably download the latest source:)
[22:01] <simon-o> james_w: lftp is the first outdated branch I remember
[22:01] <simon-o> it's some months old
[22:01] <pitti> chrisccoulson: so I think it fails in gpm_disks_register(), and the compiler optimized it away and inlined it
[22:01] <pitti> chrisccoulson: oh, can it be that ret == FALSE, and error is NULL?
[22:02] <pitti> chrisccoulson: i. e. that the DriveSetAllSpindownTimeouts() call didn't set error?
[22:02] <chrisccoulson> hmmm, that shouldn't happen though
[22:02] <chrisccoulson> (at least i don't think it should)
[22:06] <pitti> beuno: got a minute to try something? are you on a laptop right now, and can go on battery?
[22:07] <pitti> mine is currently docked, and I can't shutdown right now
[22:07] <beuno> pitti, yeap
[22:07] <beuno> I suspect that the bug is triggered when the battery is full and I unplug, but I'll need about 40min to verufy it
[22:08] <pitti> beuno: I have another suspicion
[22:08] <pitti> beuno: please do "sudo killall devkit-disks-daemon", then unplug AC and let it run on battery
[22:08] <beuno> pitti, devkit-disks-daemon: no process found
[22:09] <pitti> beuno: ps aux | grep devkit-disks doesn't give anything?
[22:09] <beuno> the only thing with devkit is: /usr/lib/devicekit-power/devkit-power-daemon
[22:09] <beuno> nope
[22:11] <pitti> beuno: ok, perfect; if you pull the plug, does it crash?
[22:11] <beuno> pitti, not at the moment, no
[22:11] <beuno> I did bring it back up again manually
[22:11] <pitti> beuno: killall gnome-power-manager
[22:11] <chrisccoulson> you have some idea whats causing it then pitti?
[22:12] <pitti> gnome-power-manager --verbose 2>&1 | tee /tmp/gpm.log
[22:12] <pitti> chrisccoulson: my best theory is still error == NULL
[22:12] <chrisccoulson> yeah, that seems to be the case, but i'm not sure why
[22:13] <pitti> beuno: if you pull the plug with this running in debug mode, what are the lines that you see right after unplugging? do you see something like "on_battery:" and then "registered 0xDEADBEEF (60)"?
[22:13] <pitti> chrisccoulson: dk-disks always returns true, it might be the d-bus call itself that fails?
[22:14] <beuno> pitti, this is the full output: http://paste.ubuntu.com/292648/
[22:14] <beuno> I can't find that specific line
[22:16] <pitti> beuno: I don't even see a "discharging there; did you pull AC actually?
[22:16] <chrisccoulson> pitti - does the value returned from devkit_disks_daemon_drive_set_all_spindown_timeouts in dk-disks correspond to the value returned from dbus_g_proxy_call in g-p-m?
[22:16] <beuno> pitti, I did
[22:16] <chrisccoulson> the documentation suggests that dbus_g_proxy_call only returns false if an error is set
[22:16] <pitti> chrisccoulson: can't say for sure
[22:17] <pitti> chrisccoulson: oh, ok
[22:17] <chrisccoulson> i could be wrong though
[22:17] <beuno> pitti, http://paste.ubuntu.com/292649/
[22:17] <beuno> that's the output when pulling it and plugging in again
[22:18] <pitti> chrisccoulson: ooh, hang on!
[22:18] <pitti> chrisccoulson: gpm-disks.c 101 is indeed
[22:18] <pitti>                 egg_warning ("failed to set spindown timeout: %s", error->message);
[22:18] <pitti> chrisccoulson: I was misled first and thought that 101 was wrong, because it's in gpm_disks_register() and not in gpm_disks_set_spindown_timeout() as the stack trace claims
[22:19] <pitti> but I guess that's just because gpm_disks_register() is just called in set_spindown_timeout, and once, and is static, so it was optimized/inlined
[22:19] <pitti> chrisccoulson: and since %s with NULL works fine, we can conclude that error is NULL
[22:19] <chrisccoulson> yeah, that seems to be the case
[22:19] <pitti> beuno: nevermind then
[22:20] <chrisccoulson> it's confusing when the compiler optimises things out and messes up the trace
[22:20] <beuno> pitti, ok. Let me know if there's anything else I can do to help debug it
[22:20] <pitti> beuno: I'll upload a fix, would be nice if you can test it and verify that it's gone?
[22:21] <beuno> pitti, absolutely
[22:21] <beuno> I'll install, reboot, and watch out for it
[22:21] <seb128> chrisccoulson, I think alex (nautilus upstream) had some blog post about how to read optimized stacktrace some time ago and some tools to make that easier
[22:21] <chrisccoulson> seb128 - would be interesting to look at. i just tend to look at the line numbers to figure out where it crashes
[22:21] <pitti> I should have just trusted the line number
[22:21] <seb128> same here
[22:22] <chrisccoulson> so the next thing to figure out is why the error is NULL
[22:23] <pitti> chrisccoulson: http://library.gnome.org/devel/dbus-glib/unstable/dbus-glib-DBusGProxy.html#dbus-g-proxy-call
[22:23] <pitti> chrisccoulson: so what you said, it shouldn't be FALSE and error == NULL
[22:24] <chrisccoulson> yeah, thats how i read it. which is confusing ;)
[22:24] <chrisccoulson> so it could be something wierd in dk-disks then
[22:26] <seb128> chrisccoulson, http://blogs.gnome.org/alexl/2005/08/26/the-art-of-decoding-backtraces-without-debug-info/ is the blog post I though about I think
[22:35] <mathiaz> cr3: still not able to run checkbox-cli: http://paste.ubuntu.com/292655/
[22:35] <mathiaz> cr3: this time I ran checkbox-cli as a normal user
[22:36] <mathiaz> cr3: However I do understand now how to (un)select tests
[22:36] <cr3> mathiaz: can you send me the logfile: ~/.cache/checkbox/checkbox.log
[22:37] <elops> do you suppose 4gb is enough for a basic media install of ubuntu?
[22:37] <mathiaz> cr3: http://people.canonical.com/~mathiaz/checkbox.log
[22:38] <elops> or am I going to get screwed trying to run updates?
[22:38] <kirkland> Keybuk: question about "start on ..."
[22:38] <kirkland> Keybuk: what's the expected behavior if we're starting on $something being started/stoped and $something doesn't exist?
[22:38] <kirkland> Keybuk: is it possible to use some best effort logic?
[22:39] <kirkland> Keybuk: ie, start on $something started if $something even exists
[22:39] <slangasek> kirkland: the condition is never satisfied if $something isn't known
[22:39] <slangasek> (I've had this problem as well, and haven't found a solution w/ the current upstart)
[22:39] <elops> anyone?
[22:39] <cr3> mathiaz: you're running from the branch rather than an installed package, right?
[22:40] <elops> thank you kmos
[22:40] <mathiaz> cr3: nope - it's a package install
[22:40] <kirkland> slangasek: ugh; that's highly unfortunate
[22:40] <slangasek> kirkland: in some cases, you can flip it around and have the optional service do 'start on starting' instead
[22:41] <cr3> mathiaz: might you be able to explain why you're getting this: DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[22:41] <cr3> mathiaz: do you have dbus running?
[22:41] <mathiaz> cr3: nope
[22:41] <kirkland> slangasek: right, but the optional service may not even be installed
[22:41] <mathiaz> cr3: it's a base system image
[22:41] <mathiaz> cr3: not a desktop
[22:41] <cr3> mathiaz: ok, that will only prevent tests which require root from running, I fixed that recently :)
[22:42] <cr3> mathiaz: now, you're experiencing another problem because of an unrelated bug
[22:42] <slangasek> kirkland: yes, in which case said optional service's upstart job doesn't exist and it's not a problem
[22:42] <mathiaz> cr3: ie: ubuntu-standard is installed
[22:42] <kirkland> slangasek: hmm, then i'm misunderstanding your statement
[22:42] <mathiaz> cr3: well - this is the latest code you've asked for merging
[22:42] <kirkland> slangasek: in eucalyptus upstart ....
[22:42] <kirkland> slangasek: we have eucalyptus-sc-registration
[22:42] <kirkland> slangasek: which has:
[22:43] <elops> can I just install a clean install, and then copy another install over the top of it?
[22:43] <kirkland> start on (started eucalyptus-sc and started eucalyptus-cloud and stopped eucalyptus-cc-registration)
[22:43] <kirkland> slangasek: eucalyptus-cloud may, or may not exist at all on this system
[22:43] <elops>  my kiosk install is only 2.6gb
[22:43] <elops> but I don't have xbmc or anything on there
[22:43] <elops> and that's on an 80gb drive
[22:43] <cr3> mathiaz: could you send me the output of udevadm info --export-db
[22:43] <kirkland> slangasek: in which case, will this condition ever be satisfied?
[22:43] <slangasek> elops: this is not a help channel; I think you'll find #ubuntu better suited to such questions
[22:44] <slangasek> kirkland: it won't be satisfied when eucalytpus-cloud is not installed, no
[22:44] <slangasek> kirkland: but what you can do is this:
[22:44] <slangasek> eucalyptus-sc-registration: start on (started eucalyptus-sc and stopped eucalyptus-cc-registration)
[22:44] <slangasek> eucalyptus-cloud: start on starting eucalyptus-sc-registration
[22:44] <mathiaz> cr3: http://people.canonical.com/~mathiaz/udevadm.info.txt
[22:45] <cr3> mathiaz: thanks for your patience, this is helping a lot
[22:45] <slangasek> kirkland: that ensures that, *if* eucalyptus-cloud is installed, it's always started before eucalyptus-sc-registration is started
[22:45] <kirkland> slangasek: really?  i would have thought "starting" implies parallel execution
[22:46] <mathiaz> cr3: sure - you owe me 278 poutines and 4242 beers
[22:46] <slangasek> kirkland: nope, it's "do this first whenever this other thing is about to be started"
[22:46] <kirkland> slangasek: interesting
[22:46] <kirkland> slangasek: i'll give this a go
[22:47] <slangasek> kirkland: feel free to use the nfs-common package as an example, I think I've used all possible combinations there ;)
[22:47] <cr3> mathiaz: damnation, virtio-pci is exposing itself as an incomplete pci class, no wonder I hadn't encountered this before
[22:47] <mathiaz> cr3: right - this is a virtual guest running virtio network devices
[22:48] <mathiaz> cr3: and virtio block devices
[22:54] <kirkland> slangasek: http://paste.ubuntu.com/292665/
[22:54] <kirkland> slangasek: see if that looks reasonable to you
[22:55] <kirkland> slangasek: i'm concerned about the huge or-statement in eucalyptus-cloud.upstart
[22:55] <kirkland> slangasek: that it might start over and over and over again
[22:55] <pitti> beuno: uploaded
[22:56] <slangasek> kirkland: what do the dependencies of the 'eucalyptus' job look like?
[22:57] <beuno> pitti, updating apt, will install and reboot. If it comes up again, I'll re-open the bug. THANK YOU
[22:57] <kirkland> slangasek: http://paste.ubuntu.com/292668/
[22:57] <kirkland> start on runlevel [23]
[22:57] <pitti> beuno: it still needs 2 hours to get built and published
[22:57] <slangasek> kirkland: the way to ensure eucalyptus-cloud doesn't start over and over again is to make it a job that winds up in state 'started' when it's done; eyeballing the diff I think that would be the case here, but it's easy enough for you to check this
[22:58] <slangasek> (if you have a running system, I mean)
[22:58] <kirkland> slangasek: okay
[22:58] <beuno> pitti, I just figured that out. On the bright side, I'm pulling in updates  :)
[22:58] <pitti> beuno: always a good thing to collect the latest breakage
[22:58] <kirkland> slangasek: i'll build a package and test
[22:58] <slangasek> kirkland: ok, given that eucalyptus job I think it looks fine
[22:58] <kirkland> slangasek: just passing by you to make sure that it's not doa
[22:59] <beuno> pitti, I appreciate the quick turnaround
[22:59] <kirkland> slangasek: related question ...  i need some logic in these init scripts that take different actions based on what's installed
[22:59] <kirkland> CC_PKG_INSTALLED=$(dpkg -l eucalyptus-cc | grep -c "^ii")
[22:59] <kirkland> slangasek: is that sufficient?
[22:59] <kirkland> slangasek: is there a better way?
[22:59] <slangasek> sufficient, but expensive - surely there's some sentinel file you can check for the presence of?
[22:59] <slangasek> (something the package ships which is not a conffile, that you can check for the existence of)
[23:00] <kirkland> slangasek: okay, i'll find something like that
[23:13] <cr3> mathiaz: pushed fix to support virtio-pci devices, updated merge proposal and bug correspondingly
[23:15] <lifeless> james_w: still around?
[23:16] <lifeless> james_w: I want to do on-demand builds of some upstreams; you were saying that the bzr nightly stuff wasn't all that reusable yet?
[23:18] <Keybuk> kirkland: here's another way of looking at it
[23:18] <Keybuk> if the optional service does not exist, what would start it?
[23:20] <kirkland> Keybuk: nothing; it doesn't exist
[23:21] <Keybuk> no, I mean
[23:21] <Keybuk> let's say that you have a process
[23:21] <Keybuk> we'll call it gandalf, because the Upstart test suite is full of references to The Hobbit and Lord of the Rings
[23:22] <Keybuk> now, the quest depends on gandalf
[23:22] <Keybuk> so
[23:22] <Keybuk> /etc/init/quest.conf:
[23:22] <Keybuk>   start on gandalf
[23:22] <kirkland> slangasek: duh, look for [ -f /etc/init/eucalyptus-cloud.conf ]  :-)
[23:22] <Keybuk> but the quest also depends on thorin
[23:22] <Keybuk> so
[23:22] <kirkland> Keybuk: okay
[23:22] <Keybuk>   start on gandalf and thorin
[23:22] <slangasek> kirkland: no, that's a conffile
[23:22] <Keybuk> following me so far?
[23:22] <kirkland> Keybuk: with you, yup
[23:23] <Keybuk> ok
[23:23] <Keybuk> now the quest optinally depends on bilbo
[23:23] <Keybuk> but we can go without him
[23:23] <slangasek> kirkland: my stipulation that it not be a conffile was not idle :)
[23:23] <Keybuk> in this model, how do we know we have to wait for bilbo
[23:23] <Keybuk> if we say
[23:23] <Keybuk>   start on gandalf and thorin and bilbo
[23:23] <Keybuk> then we'll wait for bilbo
[23:23] <Keybuk> if we say
[23:23] <Keybuk>   start on gandalf and thorin
[23:24] <Keybuk> then we won't wait at all, and won't know what bilbo is wearing
[23:24] <mathiaz> cr3: great thanks. I'll find another bug now
[23:24] <Keybuk> if we say
[23:24] <Keybuk>   start on (gandalf and thorin)
[23:24] <Keybuk>     or (gandalf and thorin and bilbo)
[23:24] <Keybuk> then we'll pick bilbo up as long as he arrives before gandalf or thorin
[23:24] <Keybuk> but if he's late we won't
[23:24] <Keybuk> but none of these is what you're after
[23:24] <kirkland> Keybuk: right
[23:25] <Keybuk> you want to know, in advance to either gandalf or thorin showing up, whether bilbo is coming
[23:25] <Keybuk> so you need some kind of signal from bilbo the night before
[23:25] <ia> hello. I've found out about this bug - https://bugs.edge.launchpad.net/ubuntu/+source/usplash/+bug/439138?comments=all (discussion really very intresting); and (just for curiosity) i would like to know - do ubuntu core developers have some plans about fixing this bug?
[23:25] <Keybuk>   start on ((gandalf and thorin)
[23:25] <Keybuk>     or (gandalf and thorin and bilbo-is-coming and bilbo))
[23:26] <kirkland> Keybuk: yeah, that sounds a bit closer
[23:26] <Keybuk> but that only works if bilbo tells you he's coming before gandalf and thorin arrive
[23:27] <Keybuk> but that's probably ok
[23:27] <kirkland> Keybuk: basically, if we are to expect bilbo, wait for him; but if he's not around at all, don't wait for him
[23:27] <Keybuk> so you can emulate this pretty easily with events
[23:27] <Keybuk> initctl emit have-eucalyptus-cloud
[23:28] <kirkland> slangasek: http://pastebin.com/f7b88450c
[23:28] <kirkland> slangasek: the copyright file?
[23:29] <kirkland> slangasek: i was hoping for something with a bit more meat as to the functionality of the package
[23:29] <slangasek> kirkland: if [ -d /usr/share/doc/eucalyptus-cloud ] ? :)
[23:29] <slangasek> kirkland: but your earlier example was the eucalyptus-cc package, not eucalyptus-cloud?
[23:30] <kirkland> slangasek: my stipulation that it be core to the functionality was not idle ;-)
[23:30] <kirkland> slangasek: :-P
[23:30] <Keybuk> kirkland: what's missing from upstart is a state that says a job exists, but isn't running
[23:30] <kirkland> slangasek: i suppose that'll do
[23:30] <kirkland> slangasek: right, i'm attacking this from a slightly different angle
[23:31] <kirkland> Keybuk: okay, cool; i think i might be able to solve it with "starting ..." from slangasek
[23:31] <kirkland> Keybuk: i'll poke you if that doesn't do what we need
[23:32] <pitti> chrisccoulson: moving here, since meeting is in place
[23:32] <chrisccoulson> ah, i didn't realise ;)
[23:32] <pitti> chrisccoulson: I can't commit, but Richard is usually fast with that; if not, we can also ask seb128 to apply them
[23:32] <chrisccoulson> i should pay more attention!
[23:32] <chrisccoulson> pitti - i can commit now, but i generally prefer to wait for the maintainer to tell me it's ok
[23:33] <pitti> chrisccoulson: oh, nice to know
[23:33] <chrisccoulson> i don't know if i'm just paranoid though ;)
[23:33] <pitti> chrisccoulson: Richard says that we should just go ahead and commit obvious fixes, and just wait for him if it changes UI/behaviour
[23:33] <chrisccoulson> ah, ok
[23:33] <pitti> chrisccoulson: so I'd say, go ahead; he can still change/revert in the very unlikely case that he disagrees
[23:34] <pitti> chrisccoulson: I still think we should apply all three patches, though
[23:34] <pitti> (well, the first one is really obvious)
[23:34] <NCommander> Keybuk, lool, so mountall 0.2.2 doesn't fix the regression on armel+dove; the image still hangs :-/
[23:34] <Keybuk> NCommander: "the regression"
[23:34] <Keybuk> pretend nobody's told me about that ;)
[23:34] <Keybuk> kirkland: I do plan to fix this in Upstart ;)
[23:34] <Keybuk> kirkland: part of the whole point of the exercise this cycle was to find out what we still needed from it
[23:35] <kirkland> Keybuk: righto
[23:35] <NCommander> Keybuk, hrm. armel+dove is failing to boot with both mountall 0.2.1 and 0.2.2. the board hangs hard in initramfs
[23:35] <cjwatson> kirkland: in response to the exact same problem, the eucalyptus-cloud init script checked for /usr/share/eucalyptus/eucalyptus-cloud-@EUCA_VERSION@.jar
[23:35] <cjwatson> kirkland: though of course that requires generating the upstart job
[23:35] <NCommander> Keybuk, nothing useful on the console (I'll grab the output of that in a minute)
[23:36] <Keybuk> NCommander: if it hangs hard in the initramfs, I'll be elsewhere ;)
[23:37] <chrisccoulson> pitti - i just had a quick look at the patch. there's no need to change the DriveUnsetAllSpindownTimeouts call though, as the parameter is going in the other direction there (ie, it's not a return value)
[23:37] <chrisccoulson> so that call is already correct
[23:37] <pitti> chrisccoulson: ah, I see
[23:37] <pitti> sorry
[23:37] <chrisccoulson> heh, no worries:)
[23:37] <NCommander> Keybuk, :-P
[23:38] <pitti> chrisccoulson: can you please just commit the right version, and then under your name?
[23:38] <chrisccoulson> pitti - yeah, can do
[23:39] <slangasek> Keybuk: do you have any thoughts on https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/439138/comments/98 ?
[23:39] <slangasek> Keybuk: I think that comment got lost among the thread of people repeating themselves :P
[23:40] <NCommander> Keybuk, I'll file a bug and debug some more
[23:40] <slangasek> Keybuk: specifically: cryptdisks-enable stop on starting-dm - madness or inspired?
[23:44] <Keybuk> slangasek: the question I guess is how cryptsetup should prompt
[23:44] <Keybuk> if usplash is running it can use usplash
[23:44] <Keybuk> if usplash is not running, maybe it should start usplash and use it
[23:44] <Keybuk> if X is running, should it not use X?
[23:44] <Keybuk> etc.
[23:45] <pitti> chrisccoulson: new g-p-m uploaded
[23:45] <slangasek> so if usplash is not running and X is not running and it needs to prompt, it starts usplash, tries to prompt, and hopes X doesn't start in the meantime and kill X?
[23:45] <slangasek> kill X -> kill usplash
[23:45] <Keybuk> slangasek: well, that's a big thorny mess
[23:45] <chrisccoulson> pitti - thanks
[23:45] <Keybuk> thinking about the big thorny mess while stuck in the middle of it is not going to solve it ;)
[23:46] <slangasek> as for "should it not use X" - no, I don't think it should
[23:46] <slangasek> since the X session belongs to an arbitrary user, and the decryption prompt belongs to the admin
[23:47] <Keybuk> ok
[23:47] <Keybuk> so let's look at the pieces here
[23:47] <Keybuk> we have a process that needs to interact with the user on the system console
[23:47] <mathiaz> cr3: yo - still failing - http://paste.ubuntu.com/292686/
[23:47] <Keybuk> (cryptsetup isn't the only one, the same is arguably true for fsck, and a future system recovery app, etc.)
[23:48] <Keybuk> but thinking about "the system console" like that is dangerous
[23:48] <Keybuk> because anything can be running there (especially X)
[23:48] <Keybuk> so we really need to think "how do we interact on the console in an output-independant way"
[23:48] <Keybuk> we can do it with text
[23:48] <Keybuk> we can do it via a graphical program like usplash
[23:48] <Keybuk> and we can do it via X
[23:48] <Keybuk> and, depending where we are, any of the above may be running
[23:49] <Keybuk> if we need to prompt while X is running, what do we do?
[23:49] <mathiaz> cr3: http://people.canonical.com/~mathiaz/checkbox.log
[23:49] <Keybuk> the start usplash approach is actually kinda ingenious I thought ;)
[23:49] <Keybuk> it switches to VT8 to prompt
[23:50] <Keybuk> and when done switches back to whatever VT you were on before
[23:50] <Keybuk> so it can still prompt while X is running
[23:50] <Keybuk> bit of a experience jump, but kinda cute
[23:51] <Keybuk> this stuff is actually easier with Plymouth - because plymouth can run on a VT that's not the active one
[23:51] <slangasek> so there are no problems with usplash and X running at the same time?
[23:51] <Keybuk> (unlike the svgalib mess that is usplash)
[23:52] <Keybuk> there are no problems that I'm aware of
[23:52] <Keybuk> usplash cannot run if it's not on the active vt
[23:52] <Keybuk> but there's code in usplash to deal with that
[23:52] <Keybuk> this is why usplash switches to a new vt
[23:52] <slangasek> cjwatson: ^^ can you confirm?  I thought this was a consideration for stop on starting-dm in usplash?
[23:53] <chrisccoulson> pitti - i've committed the change now
[23:53] <Keybuk> slangasek: that's there because X can't start on a VT which is ruined by svgalib
[23:53] <Keybuk> once X has started, it's fine
[23:53] <Keybuk> (X can start on a VT which has plymouth running on it
[23:53] <slangasek> so we have to somehow ensure that cryptsetup doesn't start usplash during a critical X startup period
[23:53] <Keybuk>  sorry I'm merging an e-mail thread with this, but I have a feeling we're going to have to use plymouth for lynx)
[23:54] <Keybuk> slangasek: right, that's the only issue
[23:54] <Keybuk> (that I know of)
[23:54] <slangasek> well, and how do we solve that?
[23:54] <Keybuk> dunno :P
[23:54] <Keybuk> haven't got that far yet
[23:55] <cr3> mathiaz: ok, I thought I had worked around running checkbox when dbus is not running, I will look into this problem tomorrow and either fix or add a dependency
[23:57] <Keybuk> slangasek: having the same issue with mountall
[23:57] <Keybuk> a simple option might be to use usplash if it's running
[23:57] <Keybuk> if it's not running, assume X has been started, and don't bother?
[23:58] <slangasek> and doing that would mean we could drop the 'console owner' from the job?
[23:59] <Keybuk> yes
[23:59] <Keybuk> a quick fix could be just to make it "console output" for now ;)
[23:59] <Keybuk> that'd break ^C and things though