[00:01] <virtuald> d- as in cd-rom? it's just another acronym nobody understands
[00:03] <Pici> disk-bus
[00:05] <jdong> desktop bus.
[00:05] <jdong> or probably just the D bus these days
[00:07] <chrisccoulson> james_w - do the reporters get a dialog with what looks like a D-Bus error in them?
[00:08] <lamont> cjwatson: bug 442480 closed
[00:13] <cjwatson> lamont: thanks
[00:14] <lamont> cjwatson: you OK with a mass-giveback?
[00:14] <cjwatson> mass give-back as long as it's zero-score would be fine, I think. The queue was kinda long last I checked
[00:25] <lifeless> what package should rfkill switch bugs be filed on? my D430 kill switch kills the bluetooth & wifi, but when the normal position is restored it doesn't re-enable them
[00:26] <lifeless> so, one needs to do "echo 1 | sudo tee /sys/devices/virtual/rfkill/rfkill1/state" which is a little kludgy
[00:28] <ScottK> lifeless: Works here (also D430)
[00:28] <ScottK> lifeless: 32 bit or 64 bit?
[00:28] <lifeless> ScottK: 64
[00:28] <superm1> lifeless, there is a bug already opened on that
[00:28] <ScottK> Hmmm.  I'm on 32
[00:28] <lifeless> superm1: ok, cool
[00:28] <superm1> it's a kernel bug against the dell-laptop kernel module
[00:28] <lifeless> superm1: for the record, where should I have looked?
[00:28] <lifeless> superm1: thanks
[00:31] <superm1> lifeless, bug 430809
[01:13] <lamont> Preparing to replace texlive-latex-base 2007.dfsg.2-4ubuntu1 (using .../texlive-latex-base_2007.dfsg.2-4ubuntu1_all.deb) ...
[01:13] <lamont> Reinstalling deleted mandatory conffile color.cfg
[01:13] <lamont> cp: cannot stat `/usr/share/texlive-base/color.cfg': No such file or directory
[01:13] <lamont> dpkg: error processing /srv/royal.buildd/home/buildd/build-karmic-autotest/chroot-karmic-autotest/var/cache/apt/archives/texlive-latex-base_2007.dfsg.2-4ubuntu1_all.deb (--unpack):
[01:13] <lamont>  subprocess pre-installation script returned error exit status 1
[01:13] <lamont> dear texlive.  DIEDIEDIE
[01:14] <lamont> was that my outside voice?  sorry
[01:26] <lamont> meh.  nm
[02:06] <qw30> Gnometris 2.28.0 is a PIECE OF SHIT!
[02:07] <qw30> it doesn't do SHIT
[02:08] <Amaranth> !ohmy
[02:09] <qw30> the game area
[02:09] <qw30> doesn't do
[02:09] <qw30> SHIT
[02:10] <hyperair> heh what's this about?
[02:10] <qw30> in the terminal I get
[02:10] <qw30> (gnometris:8489): ClutterGLX-CRITICAL **: Unable to make the stage window 0x4400042 the current GLX drawable
[02:11] <qw30> Does anyone know what this shit means?
[02:15] <Kalifa> '-'
[02:16] <qw30> OH BOB SAGET!
[02:21] <jdong> O_O
[02:50] <LaserJock> so gwibber seems quite messed up these day :/
[02:50] <LaserJock> is it going to make it into the final release as default?
[03:00] <LaserJock> and I'm not understanding the gwibber-daemon thing
[04:09] <superm1> dtchen, when you get a min can you pop in #mythtv to chat a little about the current situation with pulseaudio w/ mythtv and karmic.  see http://svn.mythtv.org/trac/browser/trunk/mythtv/libs/libmyth/audiopulseutil.cpp for what's currently being done about it
[05:10] <geofft> any ~ubuntu-sru people here? I'm waiting for an SRU for... almost two months? :-(
[05:21] <m4t> hi. im in the process of compiling an older cross compilation toolchain. several things fail with gcc-4, so i installed gcc-3.4 and have been passing it via CC=gcc-3.4
[05:22] <m4t> i'm wondering though, if there is a way to manage symlinks in /usr/bin, eg, to have gcc point to 3.4 then be able to switch it back to 4.x
[05:22] <m4t> update-alternatives doesn't seem to recognize 3.4 as a provider of 'cc'
[05:23] <geofft> Mine is a symlink to gcc-4.3 directly; it doesn't use update-alternatives (/etc/alternatives/gcc)
[05:23] <geofft> so I'd just change the symlink by hand.
[05:23] <m4t> actually you're right about it not using that
[05:23] <m4t> i forgot about the symlink chain that would point to an intermediate link in /etc
[05:26] <somebody__> Hi, is it possible to catch N-key rollovers and have them passed to an application?
[05:26] <somebody__> Please
[05:26] <somebody__> By the way
[05:26] <somebody__> Hello
[05:32] <sharms> somebody__: wrong channel for that question, I would find a programming related channel
[05:35] <somebody__> They said in #perl that it depends on the OS's handling
[05:35] <somebody__> I've been to programming and back
[05:36] <m4t> cool wel the toolchain built
[05:36] <m4t> thanks
[05:36] <jdong> somebody__: Ubuntu OS related questions still don't go here...
[05:37] <jdong> this is for development OF Ubuntu, not ON Ubuntu or FOR Ubuntu
[05:40] <somebody__> I'm trying to add this application to my official stack for Ubuntu
[05:40] <somebody__> It will help the many that use Ubuntu
[05:40] <jdong> well once you are ready to begin packaging of the software, #ubuntu-motu would be glad to help
[05:41] <jdong> but this place is not the right place to ask Ubuntu related programming questions; the topic is for coordination of the development of ubuntu itself
[05:41] <jdong> developers tend to read everything that's said in here and would appreciate a better signal to noise ratio
[05:43] <somebody__> For goodness sakes. The other channel is noisy and being of no help
[05:43] <geofft> besides, people in here probably don't know as much about GUI stuff with perl as they do about systems programming :)
[05:43] <somebody__> Do you have any idea what kind of noise a screen reader can generate when in an IRC room
[05:44] <somebody__> ?
[05:44] <somebody__> I am trying to improve Ubuntu as a whole for those in my comunity
[05:45] <jdong> that isn't the topic of this channel either.
[05:45] <somebody__> Is that really a crime
[05:45] <somebody__> ?
[05:45] <ScottK> somebody__: It's not a crime, but trouble getting help elsewhere doesn't magically put your question on topic for this channel.
[05:47] <somebody__> Which channel is it on topic for then?
[05:47] <somebody__> I'm not here to cause trouble
[05:48] <somebody__> I've been Googling for some time now and this is my last resort
[05:48] <somebody__> If you have a lead for me to follow, by all means post it here
[05:52] <nixternal> somebody__: I would look at handling via xorg input for the keyboard..also find the source for 'stickey support' in KDE as it has rollover stuff in there but I am sure is probably used via the Solid library for KDE...I don't know of any floss apps that support it to even look at...maybe find some old games that have since been open sourced that might have supported it...but ya, I have to agree a bit, this chan isn't best suited for this 
[06:00] <somebody__> Thanks fo your help
[07:09] <dholbach> good morning
[07:13] <dholbach> slangasek: did you have a chance to check out the acpi-support sponsoring bugs?
[07:15] <dholbach> 425155 and 432578
[07:26] <pitti> Good morning
[07:35] <stvo> pitti: good morning
[07:36] <pitti> hey stvo
[07:41] <pitti> kees: xsplash> yes, both you and lool ignored Vcs-Bzr:; I'm committing both of your changes now, but please do respect it in the future, otherwise we'll continue to drop patches
[07:47] <pitti> kees: why is setresuid() any better than setuid()? I find the latter easier to use, and it should do the same for a root process
[07:48] <dholbach> what does the release team say about bug 440203
[07:48] <lool> pitti: Yeah sorry, I realized there was one when kees mentionned it in a random other bug; I think I was too stressed by the beta critical issue and just uploaded
[07:49] <pitti> don't worry, committed now
[07:50] <lool> thanks
[08:23] <ebroder> Anybody from ubuntu-sru around who could ACK bug #330766? It's affecting our site deployment, and we've already tested the fix
[08:37] <hyperair> hmm lyx seems to fail miserably with ibus
[08:37] <hyperair> at least, with ibus active, the open/save dialogs don't work
[08:42] <al-maisan> Good morning!
[08:46] <chrisccoulson> hey dholbach - about bug 406077:
[08:46] <chrisccoulson> i've done a MIR already for this one - bug 432715
[09:15] <sianis> hi
[09:42] <dholbach> chrisccoulson: ah ok
[09:42] <dholbach> chrisccoulson: I'll let seb128 decide :)
[09:42] <dholbach> or somebody else desktop-y
[09:42] <seb128> dholbach, what?
[09:42] <seb128> dholbach, ETOOMUCHTODO
[09:42] <chrisccoulson> dholbach - thanks:)
[09:42] <dholbach> seb128: python-gda built from gnome-python-extras
[09:43]  * seb128 fighting over 1000 bug emails from the weekend
[09:43] <seb128> dholbach, I let you decide ;-)
[09:43] <dholbach> so glom can be built
[09:43] <dholbach> bah
[09:43] <seb128> what is to decide?
[09:43] <seb128> doit?
[09:43] <dholbach> yeah, doit probably
[09:43] <dholbach> I didn't review too closely
[09:46] <seb128> did anybody see bug #442348 before?
[09:46] <seb128> dholbach, the changes looked fine to me when I reviewed those some days ago
[09:49] <darkham> please change the splash...
[09:50] <darkham> i know you can do MUCH better...
[09:50] <darkham> :)
[09:56] <Amaranth> darkham: Unless you have an alternative you want us to look at this is the wrong place
[09:57] <dholbach> bug-report-via-irc is not supported yet :)
[09:59] <darkham> Amaranth, http://www.youtube.com/user/madsrosendahl#play/uploads/3/XlCVrtgxVcI
[10:00] <darkham> please contact him, they've many good ideas
[10:00] <Amaranth> darkham: We don't know how long the boot will take so that animation is impossible
[10:00] <Amaranth> and way too over the top
[10:01] <darkham> the animation can't be in syncro withn boot?
[10:02] <darkham> it can't be clocked?
[10:23] <AnAnt> Hello, I have a question about texlive
[10:23] <AnAnt> I see ubuntu did a change to texlive-base
[10:23] <AnAnt> http://changelogs.ubuntu.com/changelogs/pool/main/t/texlive-base/texlive-base_2007.dfsg.2-4ubuntu1/changelog
[10:23] <AnAnt> I suspect that Debian recently fixed this bug in texlive-bin instead: http://packages.debian.org/changelogs/pool/main/t/texlive-bin/texlive-bin_2007.dfsg.2-7/changelog
[10:25] <AnAnt> the bug is something to do with "5-years is too old"
[10:26] <cjwatson> presumably it's not that important exactly where it's fixed, and we can just resync in lucid?
[10:27] <AnAnt> ok
[10:28] <AnAnt> another thing, I filed a bug LP 438031
[10:28] <AnAnt> I suspect that luatex too won't compile against libpoppler 0.12, since it has the same problematic code portion that is in texlive-bin
[10:29] <AnAnt> but I didn't try yet
[10:43] <pitti> Riddell: can you ack/nack bug 442571?
[10:44] <Riddell> I can, he's got another one coming up too
[10:47] <Amaranth> Riddell: So how many bug reports did you get about amarok not being installable? :)
[10:48] <pitti> Keybuk, cjwatson: does https://code.edge.launchpad.net/~tormodvolden/casper/inspect-dm/+merge/11423 look sensible to you? I'm afraid I don't know too much about the boot mount process to see possible regressions
[10:48] <cjwatson> pitti: I was already in the middle of reviewing that
[10:48] <pitti> nice timing, thanks
[10:49] <ebroder> Can someone from ubuntu-release look at bug #429445?
[10:58] <lucas> siretart: gah, I meant ruby1.9, not 1.9.1...
[10:59] <lucas> could someone give-back ruby1.9 on i386? it failed in an unexpected way, and built fine everywhere else
[11:10] <pitti> lucas: done
[11:10] <pitti> hi tkamppeter
[11:15] <Riddell> Amaranth: havn't noticed any, what's wrong with it?
[11:16] <Amaranth> Riddell: Last time I checked it depended on amarok-common which doesn't seem to exist
[11:18] <tkamppeter> pitti, hi
[11:21] <Amaranth> Riddell: weird, must have been an archive issue because the source package says it should exist and it does now without any changes to the package
[11:21] <Amaranth> But all weekend people were popping into #ubuntu+1 asking about it
[11:22] <cjwatson> maybe it was in universe
[11:22] <cjwatson> or maybe it was in the NEW queue
[11:22] <cjwatson> the latter's actually quite plausible - since it's an architecture: all binary package, non-i386 users would have seen amarok being uninstallable until amarok-common passed through NEW
[11:24] <Amaranth> cjwatson: That would be exactly it
[11:24] <Riddell> nothing new about it, probably amd64 buildds were ahead of i386
[12:27] <pitti> tkamppeter: did you recently see bug reports about graphics in PDF files not being printed? I just filed bug 443026, and wondered how widespread the regression is
[12:43] <tkamppeter> pitti, I see this for the first time now. The only way to discover what is happening is to run the filters one by one to find the culprit. PDF handling software seems to be EXTREMELY fragile and doing one change seems to introduce 20 regressions. Here a good regression testing infrastructure needs to be introduced.
[12:50] <cjwatson> pitti: I can't seem to get the fix for bug 395079 working. I'm trying http://paste.ubuntu.com/286135/, but gnome-mount -o locale=en_GB.UTF-8 still seems to be just ignored; and I don't understand how volume.fstype.alternative gets used, given that in Ubuntu we want ntfs-3g to be the default NTFS implementation (indeed, it clearly is, by virtue of being /sbin/mount.ntfs)
[12:55] <seb128> hum, bug #442742
[12:55] <chrisccoulson> cjwatson - that won't work in karmic, as HAL doesn't do the mounting anymore
[12:56]  * seb128 kicks launchpad which timeout on bug reassign
[12:57] <chrisccoulson1> grrr, stupid 3g connection again
[13:01] <chrisccoulson1> cjwatson - there is also already a fdi file in the source, which i wrote last cycle - debian/25-ntfs-3g-policy.fdi
[13:01] <chrisccoulson1> it just isn't installed at the moment
[13:04] <ion> Hi zul. Online?
[13:04] <zul> ion: yes will get to your debdiff today
[13:04] <ion> zul: Alright :-)
[13:05] <cjwatson> chrisccoulson1: whoops, so there is, but it doesn't use the new scheme pitti linked to
[13:05] <cjwatson> oh, hmm
[13:05] <cjwatson> I hate fdi files
[13:06] <cjwatson> chrisccoulson1: so what's ntfs-3g supposed to do now? I'm thoroughly lost ...
[13:07] <chrisccoulson1> cjwatson - me too. i'm not sure what happens in KDE now
[13:07] <chrisccoulson1> is it still using HAL for mounting?
[13:07] <cjwatson> search me
[13:07] <chrisccoulson1> if all ubuntu flavours are using DK-disks, then the fdi file should not be needed
[13:08] <chrisccoulson1> it's not needed for ubuntu, but i really don't know about kubuntu
[13:08] <cjwatson> where does dk-disks get its mount option lists?
[13:08] <chrisccoulson1> i hate fdi files too. HAL mounting is horrendously over-complicated ;)
[13:09] <chrisccoulson1> cjwatson - the mount options are currently hard-coded in dk-disks
[13:09] <cjwatson> ok
[13:09] <cjwatson> Riddell: above conversation - can you shed any light?
[13:09] <chrisccoulson1> they're not configurable yet, so if the mount options are wrong, you'll need to patch dk-disks
[13:11] <cjwatson> locale= will deal with 90% of the complaints
[13:11] <Riddell> KDE isn't using devicekit
[13:11] <Riddell> it's still using HAL
[13:11] <chrisccoulson1> ah, so it defaintely needs a fdi file then
[13:12] <chrisccoulson1> s/defaintely/definately
[13:13] <cjwatson> chrisccoulson1: so if I just revert your ntfs-3g change that stopped installing the fdi file, that should be good enough and won't break gnome?
[13:14] <chrisccoulson1> cjwatson - possibly. it shouldn't have any effect in gnome, as we're not using HAL for that anymore
[13:17] <cjwatson> I think at this point that stands a good chance of making it Somebody Else's Problem which will make me happy. :)
[13:18] <pitti> re
[13:19] <pitti> cjwatson, chrisccoulson1: KDE still uses hal for mounting, through solid
[13:21] <pitti> cjwatson: GNOME does not use hal at all any more, so changing FDI files is fine from Ubuntu's perspective
[13:21] <pitti> chrisccoulson1 already said that, sorry
[13:37] <simon-o> james_w: Hi, is there anything I can do to get bug 428254 sponsored?
[13:38] <liw> I'm worried about two seemingly random crashes within the Python interpreter with computer-janitor, bug 420307 and bug 435580 -- any suggestions? ideas?
[14:10] <tseliot> Keybuk: any ideas on bug #439138 ?
[14:10] <tseliot> Keybuk: strace reports repeated (failing) calls to ioctl(5, TCFLSH, 0x2) = -1 EIO (Input/output error) where fd 5 is /dev/tty7.
[14:13] <james_w> simon-o: I'll get to it
[14:13] <james_w> simon-o: sorry for the delay
[14:14] <ebroder> Can anybody from ubuntu-release look at bug #429445?
[14:14] <simon-o> james_w: thanks. I wasn't sure if there was something missing from me.
[14:19] <pitti> ebroder: you're better off with just subscribing u-r to the bug
[14:32] <tkamppeter> pitti, did you see my last message and my comment on bug 443026?
[14:39] <pitti> tkamppeter: is there a way to display a cups raster file?
[14:39] <pitti> tkamppeter: would it help if I revert cups/evince/splix/gs to the jaunty version and see in which particular package the regression is?
[14:43] <doko_> seb128: did you see this python2.6 error "error writing to ..." yourself?
[14:43] <seb128> doko_, no
[14:51] <ttx> kirkland, nurmi: ok, I'll file bugs for the issues I found and comment on the already-filed
[14:51] <kirkland> ttx: cool
[14:51] <nurmi> great
[14:53] <tkamppeter> pitti, CUPS Raster files can be visualized with RasterView: http://www.easysw.com/~mike/rasterview/index.html
[14:54] <pitti> nice, thanks
[14:54] <pitti> tkamppeter: that saves a lot of paper :-)
[14:55] <tkamppeter> I cannot imagine that SpliX is the culprit, if the rasterization by pdftoraster conserves the drawing, SpliX, which converts CUPS Raster to the printer's raster format should not loose the drawing.
[14:56] <pitti> tkamppeter: so it seems it's most likely an evince bug?
[14:58] <tkamppeter> Only filters which can loose the drawing are pdftopdf and pdftoraster.
[14:59] <nurmi> dustin,ttx: can we work with revno 911 today (i.e. use a package based on r911)?
[14:59] <tkamppeter> pitti, for me it really looks more like an evince problem, as Ghostscript and my PDF printers have problems wityh the file.
[14:59] <ttx> nurmi: would that one fix the DB borkage issue ?
[15:00] <nurmi> dustin,ttx: there was a problem with database startup < 911, introduced by an SSL database connection fix
[15:00] <nurmi> ttx: i believe so, yes
[15:00] <ttx> kirkland: could you update your merge to that version, and publish in PPA ?
[15:00] <kirkland> nurmi: are you working on this credentials lost fix?
[15:01] <kirkland> ttx: i can do that; i'll also try to fix the orig.tar.gz too
[15:01] <nurmi> trying to reproduce
[15:01] <tkamppeter> pitti, another problem is that from the PDF of evince the filters are not able to produce a PostScript which PostScript printers understand, see bug 419143. The PostScript files get embedded fonts which the printers cannot parse.
[15:01] <kirkland> nurmi: you're trying to reproduce this credentials issue?
[15:01] <nurmi> kirkland: yes
[15:01] <kirkland> nurmi: cool
[15:02] <kirkland> nurmi: i'll cherrypick that one, once you have something for me
[15:02] <kirkland> nurmi: ttx: i need to reboot and make a pot of coffee before i tackle this new merge; give me 15 minutes
[15:02] <ttx> sure
[15:02]  * kirkland reboots
[15:02] <nurmi> kirkland: same here (coffe, at least :)
[15:13] <ttx> nurmi, kirkland: DB borkage on upgrade issue is bug 443125
[15:13] <ttx> nurmi, kirkland: No autoregistration if first startup is at boot-time is bug 443118
[15:14] <jcastro> https://wiki.ubuntu.com/UbuntuOpenWeek/Prep <-- still looking for speakers for openweek!
[15:14] <ttx> + I added a comment about the 16-minute timeout on bug 439251
[15:15] <ttx> nurmi: which ones of these should a merge at level 911 fix ? just 439251 ? or also 443125 ?
[15:16] <nurmi> ttx: i havn't been able to reproduce 443125 yet, and so i'm not sure what is going wrong
[15:17] <nurmi> ttx: however, it should fix 439251
[15:17] <ttx> anyone: what would be the right way to specify that an upstart script should start when all networking is up and running ? I don't mind if it starts after everything else.
[15:22] <ScottK> lamont: Was libmaven-clean-plugin-java on your maven bootstrapping list?  I have users screaming the world as we know it will end if maven doesn't get updated and we need that one.
[15:28] <dholbach> uery pitti
[15:30] <simon-o> ScottK: If you need help on the Maven update, just ping me. I use Maven fairly often.
[15:30] <slacker_nl> hello, against which package do I need to report a bug for packages installed by the minimal installation CD?
[15:31] <ScottK> simon-o: The biggest problem is the manual bootstrapping.  Because we don't allow binary uploads like Debian does, it's more complex for us.
[15:31] <pitti> /msg dholbach thanks for that s3kr1t information!
[15:31] <ScottK> Mostly just waiting for lamont
[15:32] <kirkland> nurmi: ttx: okay, i'm redoing the merge now
[15:32] <kirkland> nurmi: ttx: let's make sure that we resolve the two conflicts properly
[15:32] <kirkland> http://paste.ubuntu.com/286252/
[15:32] <kirkland> http://paste.ubuntu.com/286253/
[15:33] <kirkland> nurmi: ttx: for http://paste.ubuntu.com/286252/, i'm going to take upstream's change
[15:33] <kirkland> nurmi: ttx: ie, the second stanza in the conflict
[15:33] <kirkland> nurmi: ttx: agreed?
[15:33] <seb128> mdke, hey
[15:33] <seb128> mdke, got a minute to discuss menu items naming?
[15:34] <ttx> kirkland: sounds sane
[15:34] <nurmi> kirkland: nod
[15:35] <kirkland> nurmi: ttx: and http://paste.ubuntu.com/286253/ ?
[15:36] <nurmi> kirkland: in the eucalyptus-cc.in diff, we want the 'sed' line that has 'ThreadsPerChild 1', but the preseed stuff should also remain
[15:36] <ttx> first line of MERGESOURCE and the rest of TREE
[15:36] <nurmi> ttx: nod
[15:36] <kirkland> ttx: nurmi: ack
[15:37] <ttx> kirkland: also see my remark about the boot-order patch
[15:37] <ttx> nurmi: would upgrading from 854 need to rebuild to wsdl stubs ?
[15:37] <kirkland> ttx: nurmi: http://paste.ubuntu.com/286256/
[15:39] <rcaskey> hey all, any tips for a gnome-session that does not run metacity, gnome-panel, or fail in any obvious way? I'm wondering if the root cause is perhaps gnome-settings-daemon?
[15:39] <kirkland> nurmi: can you take this difference and apply upstream, to remove the conflict for the next time we merge?
[15:40] <rcaskey> dist-upgraded to karmic at the beta, and then started having problems
[15:41] <nurmi> kirkland: i'll give it a try; i want to see what happens when that file doesn't exist (node-preseed.conf) as it will only be there on ubuntu installs
[15:42] <rcaskey> ** (gnome-settings-daemon:3019): WARNING **: Failed to acquire org.gnome.SettingsDaemon
[15:42] <rcaskey> ** (gnome-settings-daemon:3019): WARNING **: Could not acquire name
[15:42]  * rcaskey is a sad boy
[15:42] <kirkland> nurmi: okay, one more thing ...
[15:43] <seb128> rcaskey, you have one already running?
[15:43] <kirkland> nurmi: could you go through https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus, and update any bugs that you expect to be solved in this r911 upload
[15:44] <kirkland> nurmi: please assign them to me (kirkland) and mark them "in progress"
[15:44] <rcaskey> seb128, yes, hrmm, wasn't before the reboot though
[15:44] <rcaskey> gnome-session is still failing silently though
[15:44] <nurmi> kirkland: will do, looking now
[15:45] <ttx> Keybuk: about upstart not reloading /etc/init/*.conf on "restart" (see https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/430883/comments/1): was that behavior changed by the 0.6.3-6 update ?
[15:45] <nurmi> kirkland: if the bug is already 'in progress' and assigned to you, leave it be?
[15:46] <kirkland> nurmi: yes; i'm doing this same thing in parallel :-)
[15:46] <kirkland> nurmi: i want double coverage on it, though; as I'm documenting this in the changelog
[15:47] <rcaskey> seb128, killing that old copy and rerunning gnome-session produces the same results
[15:47] <rcaskey> (polkit-gnome-authentication-agent-1:3236): GLib-GObject-WARNING **: cannot register existing type `_PolkitError'
[15:51] <rcaskey> or more to the point, if you killal gnome-settings-daemon and then rerun gnome-session you get (gnome-settings-daemon:3449): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
[15:52] <nurmi> kirkland: done
[15:53] <kirkland> nurmi: rock, thanks
[15:58] <kees> pitti: actually, you're right -- setuid() when called by root is the same as setresuid().
[15:59] <kirkland> nurmi: glad i asked; you had a few on your list that i didn't
[15:59] <kees> pitti: I'm used to using it on set-uid-root processes, though, where that does not happen.  (i.e. real-root setuid==setresuid, effective-root setuid!=setresuid)
[16:02] <kirkland> nurmi: https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/439251
[16:02] <kirkland> nurmi: any idea what revno fixes that?
[16:03] <nurmi> if I'm correct, it should be 892
[16:03] <nurmi> kirkland: i believe this was a symptom of the database race problem
[16:03] <kirkland> nurmi: cool
[16:04] <nurmi> kirkland: i have a proposed general solution to the preseed stanza: http://paste.ubuntu.com/286274/
[16:04] <nurmi> kirkland: line 128
[16:05] <nurmi> if both the module (mod_alias) and the node-preseed.conf files are there, it will add the configuration to httpd-cc.conf
[16:05] <nurmi> otherwise, it will skip
[16:05] <kirkland> nurmi: is this already in this merge?
[16:06] <kirkland> nurmi: or are you asking me to add that?
[16:06] <nurmi> kirkland: no, i'm proposing it for the next, unless you would like me to commit this now as 912
[16:07] <kirkland> nurmi: if you think it's safe, please go ahead and commit
[16:07] <kirkland> nurmi: i'll just merge again
[16:09] <nurmi> kirkland: it is safe (tested) from a eucalyptus init script perspective, but I don't know how to test the upstart conversion part
[16:09] <nurmi> kirkland: at some point, the init scripts must be getting converted to upstart scripts
[16:11] <nurmi> kirkland: if you think that adding this bit to the regular init script will translate properly to /etc/init/eucalyptus-cc.conf, then I'll commit
[16:12] <kirkland> nurmi: let me think on it for a minute
[16:14] <lamont> ScottK: yeah - I wanted to get the chroots happy and such - then I had intarwebs issues at home this weekend
[16:14] <lamont> so... today/tomorrow for maven - the downside is that it means a crowbar for i386 buildds (--> manual)
[16:15] <lamont> ScottK: otoh, i386 is down to almost nothing left in the queue
[16:15] <ScottK> lamont: I understand.  I'd appreciate that one.  I could always boot strap it locally and do an upload with an embedded binary if you'd prefer?
[16:18] <kirkland> nurmi: ttx: okay, testing the local build now
[16:18] <kirkland> nurmi: let's hold off on merging that hypotetical r912 at the moment
[16:19] <kirkland> ttx: oh, wait, there was a patch you told me that I should drop...
[16:19] <kirkland> ttx: where was that?  email or in irc?
[16:19] <ttx> kirkland: email, ubuntu-devel. boot-order.patch
[16:20] <ttx> applies to old init scripts, iirc
[16:23] <kirkland> nurmi: also, do we need to refresh the WSDL stubs?
[16:25] <nurmi> kirkland: nope
[16:25] <kirkland> nurmi: good
[16:25] <kirkland> mdz: around?
[16:25] <kirkland> mdz: i have a couple of questions about your eucalyptus upstart scripts
[16:25] <mdz> kirkland, yes, but on the phone. what can I do for you?
[16:25] <lamont> ScottK: the trick is to add the debs to the chroot, manual everything, build them, upload them, and then put the old chroot back and auto-mode
[16:25] <mdz> kirkland, I can answer asynchronously
[16:26] <kirkland> mdz: that's fine
[16:26] <ScottK> lamont: Yes.  Please.  It's more than just the one package (I assume you know this already)
[16:26] <kirkland> mdz: 1) eucalyptus-cc.upstart:exec apache2 -f /var/run/eucalyptus/httpd-cc.conf -D FOREGROUND
[16:27] <kirkland> mdz: nurmi asked why this was being started in the foreground...  is this linked to some upstart logging, or some such?
[16:27] <lamont> yeah - I have a lizt
[16:27] <lamont> list, too
[16:28] <kirkland> mdz: i'
[16:28] <mdz> kirkland, that's by design
[16:28] <mdz> kirkland, upstart expects that
[16:28] <kirkland> mdz: okay, thanks; glad I checked; i was inclined to drop that
[16:28] <mdz> it lets it monitor and stop the process
[16:28] <cjwatson> mdz: unless you use 'expect fork' or 'expect daemon' or whatever ...
[16:29] <cjwatson> you don't *have* to run upstart jobs in the foreground
[16:29] <kirkland> mdz: 2) ttx and I were wondering if perhaps we're attempting registration too soon, before the tcp/ip stack is functional; wondering if we should push registration back (or have it depend) on networking
[16:32] <kirkland> mdz: i was curious if you had an opinion or input on (2)
[16:32] <kirkland> mdz: i don't have proposed changes on that one yet
[16:35] <ttx> kirkland: if you are in them, fix /etc/init/eucalyptus-walrus-registration.conf so that it uses ipaddrs.conf as the others do
[16:36] <ttx> kirkland: can't seem to reproduce first-boot registration failure on subsequent boots, maybe some DHCP racing is involved here
[16:38] <kirkland> ttx: okay, can do
[16:38] <ttx> kirkland: do you have an ETA for a r911-based package in PPA ?
[16:38] <kirkland> ttx: i'm building locally right now, should be done with that in 2-3 minutes
[16:38] <ttx> I'd like to test if the admin credentials lost on upgrade issue is still there
[16:38] <kirkland> ttx: i'm pushing to ppa as soon as my local build succeeds
[16:38] <ttx> kirkland: ok
[16:39] <kirkland> ttx: though i'll add your ipaddrs.conf change too, if you like
[16:39] <kirkland> ttx: that shouldn't affect the build
[16:39] <ttx> kirkland: that's cosmetic, the key to upgrading to r911 is that db upgrade issue
[16:40] <ttx> kirkland: so the sooner I get a r911 package, the better ;)
[16:40] <kirkland> ttx: local build done; attending your ipaddrs.conf
[16:41]  * ttx reinstalls from CD to get prstine state and one more autoregistration test
[16:41] <kees> slangasek: on upgrades, libpam0g prompts for service restarts.  should we adjust that (as done for libc, I think) to not prompt in update-manager ?
[16:42] <ScottK> +1 for that
[16:42] <OberonKing> sorry folks, i'm have a issue with the last 2 livecd, alpha 6 and beta don't boot, make the boot process but freeze... can't even enter to a console (ctrl+f1)
[16:43] <OberonKing> i try noapic, nolapic, ....etc and nothing
[16:44] <mdz> kirkland, I committed a patch to get rid of the error redirect for euca_conf during registration.  that should make it obvious if that's what's happening
[16:44] <OberonKing> ohh, i forget, in virtualBox work without problems.
[16:44] <mdz> kirkland, my gut reaction is, let's test that hypothesis before we try to fix it that way
[16:44] <kees> slangasek: oh, nevermind, I'm reading 278117 now; it seems like this is only done if the services are non-default
[16:45] <kirkland> mdz: ack, that sounds perfectly reasonable
[16:45] <kirkland> ttx: uploaded to my ppa
[16:45] <kirkland> ttx: also, pushed to bzr+ssh://bazaar.launchpad.net/~kirkland/eucalyptus/r911/
[16:50] <ScottK> kees: Since there is no other option that "OK" and there's no way to go back at that point, asking seems somewhat pointless to me.
[16:51] <kees> ScottK: well, you can change the list of services, but it should only appear when non-default services are installed
[16:51] <mdz> kirkland, do you have an ETA for the new snapshot of eucalyptus landing in karmic?
[16:52] <kirkland> mdz: i just pushed to my PPA; i plan on testing that there, and then uploading to karmic, and asking for an ISO respin immediately thereafter
[16:52] <ScottK> kees: I supose.  I upgraded a server over the weekend and was somewhat disappointed to find it waiting for me to OK when I got back to it.
[16:52] <kirkland> mdz: i expect all of that to happen within my workday
[16:52] <ttx> mdz: there is a regression in there
[16:52] <mdz> ttx, bug#?
[16:52] <ttx> bug 443125
[16:52] <kirkland> mdz: right, pending the fixage of that regression, of course
[16:53] <kirkland> mdz: as we understand it, nurmi and team are working on that in the upstream code right now
[16:53] <ttx> mdz: I also hit  bug 443118 on current dailies
[16:53] <ttx> which is the ont that prompted kirkland's query about eucalyptus boot order
[16:54] <mdz> kirkland, if nurmi is working on it, please assign the bug to him
[16:54] <ttx> mdz: I reinstall now to test upgrade to r911
[16:54] <kirkland> mdz: done; actually, he's trying to reproduce it at the moment
[16:55] <mdz> kirkland, are you holding off pushing to /ubuntu until all known issues are resolved?
[16:56] <kirkland> mdz: yes
[16:56] <ttx> mdz: I would hold until bug 443125 is fixed.
[16:56] <kirkland> mdz: i have lp:~kirkland/eucalyptus/ubuntu in the mean time
[16:56] <kirkland> mdz: unless you'd like me to push there?
[16:56] <ttx> the others (autoregistration stuff) will need some iterations
[16:56] <kirkland> mdz: i suppose at this point we're committed to merging up to r9xx anyway
[16:57] <mdz> kirkland, if we're committed anyway, then I see no harm in pushing ahead
[16:57] <dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
[16:57] <dupondje> could somebody give this bug a look ? Its like the most annoying bug in Karmic :(
[16:57] <kirkland> mdz: okay; i was concerned about pushing something with a suspected regression; though I guess pushing to bzr is very different than uploading a broken package (which we won't do of course)
[16:58] <ttx> kirkland: ack
[16:58] <nurmi> mdz: kirkland: ttx: we believe we have diagnosed and fixed #443125
[16:58] <mdz> kirkland, if you're unsure about merging to /ubuntu, you could create a new branch under ~ubuntu-core-dev
[16:58] <kirkland> $ bzr push lp:~ubuntu-core-dev/eucalyptus/ubuntu
[16:58] <kirkland> Pushed up to revision 649.
[16:58] <mdz> kirkland, I ask because it's not ideal that the current working tree is only writable by you
[16:58] <ttx> nurmi: you mean in >=r911 ?
[16:58] <kirkland> mdz: ah, right; that makes perfect sense
[16:58] <kirkland> mdz: will do that in the future
[16:59] <kirkland> mdz: this time, i've pushed our main tree up to r649
[17:00] <mdz> kirkland, does that match what's currently in your PPA?
[17:00] <ttx> confirming bug 443118 for the third install today
[17:00] <nurmi> ttx: yes, the bug was still in 911.  912 has the fix.  911 has fixes for many of the other bugs, though, and so i think it is worth a try (as long as we're not upgrading from 854, but instead installing package from scratch)
[17:00] <kirkland> mdz: yes
[17:00] <mdz> ttx, your ISO is still using r854, right?
[17:01] <ttx> mdz: yes.
[17:01] <ttx> mdz: testing the latest with some purge/start-restart-diversion/install/reboot setup didn't exhibit the bug
[17:02] <kirkland>     *   Start in 7 hours (2505) What's this?
[17:02] <mdz> ttx, I would be interested to see what shows up in the logs once euca_conf-error-output.diff is applied
[17:02] <mdz> ttx, maybe you could patch that in post-install and pre-reboot as a test?
[17:02] <kirkland> ttx: mdz: without a build priority bump, it will be a long time before my eucalyptus ppa packages build
[17:02] <mdz> kirkland, ->lamont
[17:02] <ttx> kirkland: could you bump to 912 ? then I'll test that the regression is gone
[17:03] <kirkland> ttx: i don't see r912 yet
[17:04] <ttx> I hold my upgrade, non need in testig if the regression is gone in 911 if nurmi says it's fixed in 912
[17:04] <cjwatson> kirkland: I'll bump prio
[17:04] <kirkland> lamont: could you give my PPA eucalyptus builds a shot of amphetamines?
[17:04] <kirkland> cjwatson: cheers, thanks (lamont -> nevermind)
[17:04] <ttx> cjwatson, kirkland I'd prefer you to bump 912
[17:04] <kirkland> cjwatson: okay, hold a sec
[17:04] <ttx> since I have no use for the 911-based
[17:04] <nurmi> kirkland: should be pushed, sometimes it takes LP a few minutes to update
[17:04] <kirkland> ttx: r912 doesn't exist yet
[17:05] <kirkland> ttx: nurmi: okay, i got it
[17:05] <kirkland> re-uploading
[17:06] <ttx> mdz: my test setup is on the regression issue right now, since it's the one blocking the new version to reach the ISO
[17:07] <kirkland> ttx: nurmi: what bug number does r912 close?
[17:07] <ttx> kirkland: bug 443125
[17:07] <nurmi> https://launchpad.net/bugs/443125
[17:09] <kirkland> ttx: mdz: uploaded to my ppa
[17:09] <kirkland> cjwatson: i'll ping you in a minute, when LP figures out it needs to build a eucalyptus ppa package for me
[17:11] <kirkland> mdz: my merge changelog last week was a bit of a stub; here's what we're working with now: http://pastebin.ubuntu.com/286320/
[17:12] <cjwatson> kirkland: ok, I'm on a call so expect a bit of latency
[17:12] <kirkland> cjwatson: okay eucalyptus 1.6~bzr912-0ubuntu1~ppa1 in https://edge.launchpad.net/~kirkland/+archive/ppa is waiting to build
[17:13] <ttx> kirkland: my test setup is ready to test the new upgrade. I'll be afk for a few waiting for your PPA to publish a 912-based one
[17:13] <ttx> kirkland: just ping me when done.
[17:15] <cjwatson> kirkland: bumped
[17:15] <kirkland> ttx: cool
[17:15] <kirkland> cjwatson: thanks man
[17:22] <cyphermox> I'm looking at bug #404616 which we identified and possibly fixed during the global jam here. I fixed the bug in a bzr branch in my lp user, but what is the correct workflow from there? Should I still be creating a debdiff and subscribing ubuntu-main-sponsors, or is a merge proposal for the bzr branch that holds its packaging code enough?
[17:26] <lamont> kirkland: actually, no, I can't.
[17:26] <lamont> that's a losa thing
[17:26] <lamont> keytool: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
[17:26] <lamont> dear java.  why do you hate me?
[17:26] <lamont> doko_: where does that library live?  and can someone fix ca-certificates-java to actually DEPEND on that package?
[17:26] <lamont> ScottK: maven will be much easier to build if the packages were installable...
[17:27] <kirkland> ttx: nurmi: mdz: build done, available at https://edge.launchpad.net/~kirkland/+archive/ppa
[17:28] <nurmi> kirkland: trying
[17:28] <doko_> lamont: is this in a chroot without mounted /proc?
[17:31] <ttx> kirkland: trying
[17:32] <kees> slangasek: for your consideration, logwatch FFe: 443252
[17:35] <lamont> doko_: sigh
[17:35] <lamont> yeah
[17:35] <lamont> &)^*^&(^%(&^) java
[17:35] <lamont> and the rest that need /proc
[17:36] <ttx> kirkland: bug 443125 is *not* fixed in 1.6~bzr912-0ubuntu1~ppa1
[17:37] <kirkland> nurmi: ^
[17:37] <nurmi> kirkland: still trying the upgrade
[17:37] <nurmi> ttx: kirkland: we could reproduce with 911, but not with 912 (should have fixed)
[17:37] <kirkland> ttx: nurmi: FYI, i'm installing from today's iso
[17:37] <YokoZar> Wow, I just confirmed a bug and assigned it to myself.  I said that it affects me too, and I'll take care of it.  I then realized I was the reporter about 2 months ago.
[17:38] <lamont> doko_: if it _NEEDS_ /proc, it should better assert that in preinst, no?
[17:38] <ttx> kirkland, nurmi: installed todays ISO, test the euca-* commands work, upgrade to 1.6~bzr912-0ubuntu1~ppa1, and that same command no longer works.
[17:39] <ttx> and sudo euca_conf --get-credentials returns an empty file.
[17:39] <lamont> http://paste.ubuntu.com/286342/ <-- doko
[17:39] <doko_> lamont: I can do that, but maybe after karmic
[17:39]  * ttx will be back in a few hours
[17:43] <kees> Riddell: who maintains skim?
[17:43] <lamont> nm
[17:44] <Riddell> kees: you're making an assumption
[17:46] <kees> Riddell: hrm.  well, it currently ftbfs and it's in main.  should I assign it to ubuntu-desktop?
[17:47] <Riddell> kees: assign  to me if  you  like,  "jr"
[17:47] <kees> Riddell: ok, cool.  thx!
[17:48] <Riddell> kees: for koffice the upstream insists 1.6 is supported and have proved it by supplying  a  patch to disable the xpdf stuff, so I guess we'll go with that
[17:50] <fbond> statik: Hey, FYI, python-spawning (in your PPA) does not depend on python-greenlet (but should).
[17:51] <statik> hi fbond: you are correct. rmcbride had taken over working on that package, he may even have a corrected version in REVU right now
[17:51] <statik> i should delete the old stuff out of my ppa though
[17:52] <statik> or even better, i'll copy rmcbrides newer package there
[17:56] <rmcbride> statik: the version I have in REVU has corrected deps, but I'm uploading the 0.8.12 version to REVU now, since the previous one is still in queue and needs to be replaced
[17:58] <fbond> statik: Okay, thanks.  If you put the updated package in your PPA I would be thankful.
[17:58] <fbond> rmcbride: Does spawning have VCS somewhere?
[17:59] <nurmi> ttx: kirkland: mdz: strangeness - if I use the 912 'cloud' package, i'm seeing ttx's problem (admin creds don't last through the upgrade).  If i use eucalyptus*.jar that are built from 912 source, i am not seeing the problem
[18:00] <kirkland> nurmi: we need to diff that
[18:01] <nurmi> kirkland: i'm going to need some time to track this down
[18:01] <kirkland> nurmi: okay
[18:01] <kirkland> nurmi: what's your approach?
[18:01] <kirkland> nurmi: i recommend starting with the source we're using for the jar in the package, versus what you're using where you don't see the problem
[18:04] <nurmi> kirkland: nod
[18:05] <nurmi> kirkland: i want to start with a clean 854 install, then build 912 upstream and confirm that the bug is fixed
[18:05] <kirkland> nurmi: where are the source files in question?
[18:05] <nurmi> kirkland: then, from 854 install, i want to try the 912 used to create packages
[18:06] <nurmi> clc/modules/authentication/src/main/java/com/eucalyptus/auth/CredentialEntities.groovy
[18:06] <nurmi> clc/modules/authentication/src/main/java/com/eucalyptus/auth/CredentialProvider.java
[18:06] <lamont> i386 buildds on manual for a bit
[18:06] <nurmi> clc/modules/msgs/conf/scripts/startup.groovy
[18:07] <rmcbride> fbond: I'll have to go look. I got the stuff I worked from from pypi and it's been a few days
[18:08] <mdz> kirkland, lamont, did you sort out how to get that build reprioritized? we'll need to do that more times before we're done
[18:08] <kirkland> mdz: cjwatson did it for me
[18:09] <kirkland> mdz: lamont said he couldn't
[18:09] <cjwatson> surprised lamont couldn't
[18:09] <kirkland> mdz: yes, it's built now, regression still in the subject package
[18:09] <cjwatson> anyone in launchpad-buildd-admins should be able to
[18:09] <mdz> lamont, who in a US time zone can do that for kirkland the next time?
[18:09] <kirkland> mdz: nurmi is sorting that out, as he's not seeing it in his upstream build of r912, but is seeing it in the ubuntu build thereof
[18:09] <cjwatson> mdz: kees can
[18:09] <kirkland> mdz: i'm parsing the diff now
[18:09] <cjwatson> (by virtue of TB membership)
[18:10] <kees> just let me know which and when
[18:10] <jcole> hi guys, package evolution-mapi in karmic is currently unusable and does not work... it look like debian has a newer version (requires a newer evolution so i couldnt install)... how do i go about requesting a working version of evolution-mapi?
[18:11] <mdz> kirkland, can you explain 01-wsdl-stubs.patch to me?
[18:11] <lamont> well.   they will be manual shortly
[18:12] <kirkland> mdz: no, I cannot.  soren, nurmi: can either of you guys help here?  what's with:
[18:12] <kirkland> -rw-r--r-- 1 kirkland kirkland 14M 2009-10-05 09:31 debian/patches/01-wsdl-stubs.patch
[18:12]  * kirkland notes the *14M*
[18:12] <mdz> kirkland, based on earlier comments, I think ttx is more familiar with it
[18:13] <lamont> mdz/kirkland/cjwatson: rescoring is me or any duck.  permanently blessing a ppa (if doable) would be losa/gsa
[18:13] <kirkland>  351 files changed, 322953 insertions(+)   <---- that's scary
[18:14] <kirkland> lamont: oh, definitely don't need a permanent blessing
[18:14] <kirkland> lamont: just a couple of rescores
[18:14] <cjwatson> lamont: rescoring is any launchpad-buildd-admins member, since I can do it and don't have a duck
[18:14] <slacker_nl> if you see some random string coming from me, my cats are jumping on my keyboard btw
[18:15] <slacker_nl> ahh, they changed the channels already
[18:15] <statik> fbond, spawning is on bitbucket: http://bitbucket.org/fzzzy/spawning/overview/ also donovan recently started actively hacking on it and merging patches recently
[18:15] <slacker_nl> cats :/
[18:15] <kirkland> sudo killall cat
[18:16] <highvoltage> -9
[18:17] <pitti> doesn't work
[18:17] <pitti> remember, you have to do
[18:17] <pitti> for i in `seq 7`; do killall cat; done
[18:17] <ScottK> doko_: Any suggestions on http://paste.ubuntu.com/286360/ ?
[18:18] <mdz> kirkland, it's a bunch of autogenerated code from the looks of it
[18:18] <mdz> not sure why it's patched in
[18:18] <ogra> lool, the display properties notification icon is still completely coloured (testing your icon-theme package)
[18:18] <mdz> pitti, haha
[18:20] <kirkland> pitti: LoL :-)
[18:21] <jcole> ill just "apt-get source evoltion-mapi" from debian unstable, "apt-get build-dep evoltion-mapi; dpkg-build-package" and see if i get luck... ill add it to the internal repos if success
[18:23] <doko_> ScottK: doesn't look like a valid module name, no not on first look
[18:23] <ScottK> doko_: The confusing part is this is a rebuild, so something has changed.
[18:23] <ScottK> The only change is build-dep libode0-dev -> libode-dev
[18:24] <ScottK> So something is getting confused somewhere....
[18:24] <ScottK> doko_: ^^
[18:24] <nurmi> kirkland: okay, it looks like the newest package isn't installing some code from r912
[18:24] <kirkland> nurmi: oh?
[18:25] <nurmi> kirkland: on my system, the /etc/eucalyptus/cloud.d/scripts/startup.groovy is not the same as the one from the source tarball
[18:26] <doko_> ScottK: I try to have a look this week ...
[18:26] <rmcbride> fbond: I dont see a reference to any sort of VCS for python-spawning at pypi.
[18:26] <ScottK> doko_: Thanks.
[18:26] <ScottK> doko_: I have a vague hunch that the axiom FTBFS may be related.
[18:27] <doko_> persia, ttx: see bug #443292, any help appreaciated
[18:31] <kirkland> nurmi: can you pastebin a diff of those two?
[18:32] <nurmi> kirkland: i'm trying a new install, i can get the diff back in a moment...
[18:33] <nurmi> it looked like the file from 854
[18:33] <lool> ogra: Ok; I am not sure how that one is considered; would you mind filing a bug against humanity-icon-theme?
[18:34] <lool> ogra: thanks for testing!
[18:34] <kirkland> nurmi: hmm, i might have screwed up the merge
[18:35] <ogra> lool, will do, ibus is also coulored, but i dont think it is handled by any theme (though probably more often used than the display properties in the notification area)
[18:35] <nurmi> kirkland: not sure if this is related, but last time i tried a 'bzr builddeb', i did notice that it was grabbing a source tarball from the toplevel directory, instead of using the source from the bzr co itself
[18:35] <ogra> hmm, is my gdm supposed to be all black nowadays ?
[18:36] <ogra> looks quite ugly
[18:37] <nurmi> kirkland: http://pastebin.ubuntu.com/286372/
[18:37] <nurmi> kirkland: diff of the two
[18:37] <nurmi> kirkland: startup.groovy s
[18:37] <kirkland> nurmi: cool, i think i see what i did wrong
[18:38] <kirkland> nurmi: looks like it was my fault; i only have merged r912
[18:38] <kirkland> nurmi: whereas i did r911 correctly
[18:38] <kirkland> nurmi: i did that last bit asleep at the wheel
[18:39]  * nurmi is motivated to get more coffee, right back :)
[18:39]  * lamont kicks the intarwebs
[18:39] <lamont> kirkland: ah ok... it sounded like you wanted something more earlier
[18:39] <kirkland> lamont: nope, just a build bump
[18:40] <kirkland> lamont: i'm about to need another one
[18:43] <fbond> statik: Thanks.
[18:43] <fbond> rmcbride: Thanks.
[18:46] <kirkland> lamont: please bump these 3:
[18:46] <kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276910
[18:46] <kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276911
[18:46] <kirkland> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276912
[18:49] <ogra> lool, what about vino, do you want a bug for it too (also completely coulored)
[18:51] <james_w> Riddell: the description of qt-sdk is truncated
[18:51] <lool> ogra: Sure
[18:51] <lool> ogra: kind of depends whether it's an app or a system service
[18:51] <lool> Again not entirely clear in the case of vino
[18:51] <james_w> Riddell: would you like to fix it later or before it gets out of the queue?
[18:51] <ogra> well, its installed by default
[18:51] <lool> rhythmbox, banshee, tomboy are clearly in the app camp
[18:51] <ogra> and it uses the notification area by default
[18:51] <kirkland> nurmi: this one should be better
[18:51] <lool> ogra: Yes but we only care about system services for b&w icons
[18:51] <ogra> indeed
[18:52] <kirkland> nurmi: as soon as lamont ushers it up in the build queue
[18:52] <Riddell> james_w: in debian/control  ?
[18:52] <james_w> Riddell: yeah
[18:52] <Riddell> james_w: I see, please reject
[18:53] <james_w> done
[18:54] <kirkland> lamont: just curious if you caught those last few messages from me; i see you just rejoined
[18:56] <lamont> through :39, yes
[18:56] <lamont> after that, no.
[18:56] <lamont> and in about an hour, I'm goona head home to beat the intarwebs up
 lamont: please bump these 3:
 https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276910
 https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276911
 https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276912
[19:01] <lamont> kirkland: rescored
[19:01] <kirkland> lamont: thanks
[19:08] <kirkland> nurmi: okay, i'm testing the latest package
[19:08] <kirkland> nurmi: ubuntu@cluster:~$ sudo euca_conf --get-credentials mycreds.zip
[19:08] <kirkland> [sudo] password for ubuntu:
[19:08] <kirkland> ERROR: you need to be on the CLC host and the CLC needs to be running.
[19:08] <kirkland> nurmi: oh, wait
[19:08] <kirkland> it just came
[19:14] <free> pitti: hi!
[19:14] <free> pitti: have a minute to talk about #347983?
[19:15] <nurmi> kirkland: are the amd64 packages built?  I'm still seeing them as 'needs building' but i might be looking in the wrong place
[19:15] <nurmi> kirkland: https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1276910
[19:18] <lamont> nurmi: you're looking in the right place -
[19:18] <lamont> OTOH, already running builds kinda win, and the dispatcher seems a tad slow
[19:19] <nurmi> lamont: great thank you
[19:21]  * lamont needs to look at the right architecture - i386 is the one with an idle ppa buildd - the amd64 buildds are all happily building along.
[19:21] <lamont> once they finish their current builds, kirkland's builds will win
[19:35] <kirkland> nurmi: okay, i've tested the new upload
[19:36] <kirkland> nurmi: i'm not able to run instances
[19:36] <kirkland> nurmi: http://rookery.canonical.com/~kirkland/cloud-output.log
[19:37] <nurmi> does that ssh key exist? (mykey)
[19:38] <nurmi> kirkland: i.e. does euca-describe-keypairs show it?
[19:39] <kirkland> nurmi: my fault, i found it
[19:39] <nurmi> btw, is this from an upgrade from 854?
[19:43] <kirkland> nurmi: yes
[19:43] <kirkland> nurmi: okay, i have a running instance on 1.6~bzr912-0ubuntu1~ppa2 (!!)
[19:43] <nurmi> kirkland: aw yeah
[19:43] <kirkland> nurmi: give it a poke, let me know if you see any obvious regressions
[19:44] <nurmi> i'll be running through our full QA here in a second
[19:44] <kirkland> nurmi: i'm going to eat a bite of lunch, and upload to karmic thereafter, assuming we don't detect any regressions
[19:44] <nurmi> kirkland: and this is as an upgrade from 854 (iso)?
[19:44] <nurmi> kirkland: wait you already answered that, nvm
[19:44] <kirkland> nurmi: yes, today's iso (854) upgraded to these PPA packages
[19:44] <kirkland> nurmi: it's not DoA, which is good
[19:45] <kirkland> nurmi: ETA on your QA testing?
[19:45] <kirkland> nurmi: ideally, i'd like to wait for that before pushing to karmic
[19:45] <nurmi> assuming this works out of the box, i can be done with short-term testing in an hour
[19:45] <kirkland> nurmi: assuming that'll be done in ~1 hour or so
[19:45] <kirkland> nurmi: par-fect
[19:46] <kirkland> nurmi: i'll cross my fingers and get something to eat
[19:46] <nurmi> kirkland: awesome, thanks dustin
[19:46] <kirkland> mdz: fyi, initial testing on r912 looks good, i have running instances here
[19:46] <mdz> kirkland, good good
[19:46] <kirkland> mdz: upgraded from r854, anyway
[19:46] <kirkland> mdz: nurmi is putting it through the Eucalyptus Systems QA suite
[19:47] <kirkland> mdz: that should conclude in roughly an hour
[19:47] <kirkland> mdz: i'll upload to karmic thereafter, and ask for an iso respin
[19:47] <kirkland> mdz: unless you want that in progress in parallel
[19:47] <kirkland> mdz: i have not detected any regressions, have seen ttx's issues solved
[19:47] <kirkland> mdz: this upload is thought to fix ~12 bugs
[19:48] <mdz> kirkland, whatever is best in your judgement
[19:48] <kirkland> mdz: i will wait for nurmi
[19:51] <nurmi> kirkland: mdz: doing eucalyptus tests now
[19:51] <kirkland> nurmi: hunting for leftovers now
[19:52] <mdz> nurmi, do you have a separate bug number for 443125 upstream or are you using the same one?
[19:52] <nurmi> mdz: same one, we learned about this bug this morning
[19:54] <mdz> nurmi, and it's meant to be fixed by r912? I don't see a bug number in the commit message
[19:55] <nurmi> mdz: it is, the committer did not put in a bug number into the revision
[19:55] <mdz> nurmi, understood, I'll just update the bug accordingly
[19:57] <arand> Can I view the security queue for ubuntu, or is it non-public?
[19:58] <jdstrand> arand: as in what is in our build queue? that is non-public
[19:59] <nurmi> mdz: thank you, appreciated
[20:06] <arand> jdstrand: so that is a separate section compared to the public https://launchpad.net/ubuntu/jaunty/+queue ?
[20:10] <jdstrand> arand: yes, we build in a private ppa
[20:11] <arand> Okay, one learns something new...
[20:20] <ttx> kirkland: why did you reopen bug 436313 ? It was fixed, the merge just confirms the fix ?
[20:21] <kirkland> ttx: then i misunderstood your comments
[20:21] <kirkland> ttx: i assumed this was fixed in a revision >> 854
[20:21] <kirkland> ttx: i found that revision in the upstream commit log
[20:21] <ttx> kirkland: yes, it was fixed in a rev>>854, but applied to our branch
[20:22] <mdz> ttx, can you explain about 01-wsdl-stubs.patch?
[20:22] <kirkland> ttx: cool, i'll close it then
[20:23] <ttx> mdz: there is a trick because eucalyptus needs some C code generated from wsdl descriptions
[20:23] <ttx> mdz: it uses wsdl2c which uses some unpackaged axis2 java code
[20:24] <ttx> so if upstream changes wsdl descriptions, the patch needs to be refreshed
[20:24] <mdz> ttx, is there any kind of check in place so that we notice when that happens? it should probably fail the build
[20:25] <ttx> mdz: I don't think there is, it bit soren once already
[20:25] <ttx> mdz: more info with soren
[20:51] <nurmi> mdz: ttx: the trigger for that (C auto-gen stuff) would be if any of the wsdl files changes (<eucalyptus-src>/wsdl/*)
[20:57] <nurmi> ttx: mdz: kirkland: okay, our short-term tests have passed with the latest package from this morning (1.6~bzr912-0ubuntu1~ppa2)
[20:58] <kirkland> nurmi: cool
[20:58] <kirkland> nurmi: i'm uploading to karmic then
[20:58] <kirkland> nurmi: as I'm happy with the prodding i've done
[20:58] <kirkland> nurmi: i'll ping you again as soon as we get a new ISO
[20:59] <LLStarks> hi.
[20:59] <nurmi> kirkland: great!
[20:59] <LLStarks> i find it infuriating that i need to have a genuine package installed to file a bug against it.
[20:59] <hyperair> ..this is just great. now i can't file bugs on launchpad manually?
[20:59] <hyperair> what's the big idea?
[20:59] <LLStarks> what if i am using a ppa version but i need to use ubuntu-bug?
[21:00] <hyperair> my my, looks like we're both ranting about the same issue
[21:01] <LLStarks> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/443961
[21:26] <doko_> lucas: do you understand the ruby1.9 build failure on i386?
[21:27] <lucas> doko_: there was an upstream bug + patch
[21:27] <lucas> doko_: bug #443044
[21:28] <doko_> lucas: thanks! I'll upload
[21:29] <kirkland> crap
[21:29] <kirkland> mdz: eucalyptus build failed
[21:29] <kirkland> The following packages have unmet dependencies:
[21:29] <kirkland>   default-jdk: Depends: default-jre (= 1.6-30ubuntu5) but it is not going to be installed
[21:29] <kirkland>                Depends: openjdk-6-jdk (>= 6b11) but it is not going to be installed
[21:32] <kirkland> doko_: hey
[21:32] <mdz> kirkland, on which arch(es)?
[21:32] <kirkland> mdz: all
[21:32] <kirkland> doko_: is our jdk/jre in flux right now?
[21:32] <kirkland> https://edge.launchpad.net/ubuntu/+source/eucalyptus/1.6~bzr912-0ubuntu1
[21:32] <kirkland> mdz: ^
[21:34] <doko_> kirkland: no, java-access-bridge was uploaded, but that did add only a dependency. I don't know of anything else
[21:35] <kirkland> doko_: http://launchpadlibrarian.net/33058735/buildlog_ubuntu-karmic-amd64.eucalyptus_1.6~bzr912-0ubuntu1_FAILEDTOBUILD.txt.gz  <---- any ideas?
[21:37] <mdz> kirkland, doko,   openjdk-6-jre: Depends: libaccess-bridge-java-jni but it is not going to be installed
[21:38] <doko_> kirkland: http://people.canonical.com/~ubuntu-archive/testing/karmic_probs.html
[21:38] <mdz>   libaccess-bridge-java-jni: Depends: libaccess-bridge-java (>= 1.26.2-1ubuntu1) but it is not installable
[21:38] <mdz> E: Package libaccess-bridge-java has no installation candidate
[21:39] <doko_> ahh, it's in universe, please promote
[21:40] <kirkland> doko_: ah
[21:40] <doko_> ubuntu-archive: ^^^
[21:40] <kirkland> doko_: one minute, i'll push
[21:40] <cjwatson> done
[21:40] <kirkland> cjwatson: thanks
[21:40] <kirkland> cjwatson: do i need to re-upload to retrigger the build?
[21:40] <mdz> doko_, what bug is that change meant to fix? I don't see a bug reference in the changelog
[21:40] <cjwatson> kirkland: no
[21:41] <cjwatson> kirkland: there's a retry button in launchpad
[21:41] <kirkland> cjwatson: awesome, thanks
[21:41] <doko_> mdz: the jni bindings require the java files, or else the bridge doesn't work
[21:41] <kirkland> cjwatson: cool, never noticed taht!
[21:41] <doko_> kirkland: only for buildd admins
[21:41] <cjwatson> kirkland: wait an hour for the main promotion to take effect, of course
[21:41] <cjwatson> doko_: false
[21:42] <kirkland> cjwatson: okay
[21:42] <cjwatson> doko_: if you're able to upload a package, you're able to retry a build too
[21:42] <doko_> cjwatson: then it did change
[21:42] <cjwatson> doko_: a year or two ago, yeah. rescoring is still restricted
[21:42] <doko_> ahh, ok
[21:42] <cjwatson> which might be what you're thinking of
[21:42] <doko_> yep
[21:42] <mdke> seb128: I'm around now if you can
[21:42] <kirkland> mdz: okay, as this stands, i will be several hours before I'm able to receive and test a new ISO
[21:44] <seb128> mdke, hey
[21:44] <mdke> hiya
[21:44] <seb128> mdke, so what is your issue with the gedit naming?
[21:45] <mdke> seb128: I was just putting the thought out there, that it is inconsistent with the other menu entries which don't use the application name, also it seems to me that it looks ugly to start a menu entry with a small letter
[21:45] <mdke> seb128: but it's an issue for the desktop team to decide, as the docs team we'll just adapt to the decision, whatever it is
[21:45] <mdke> but we'll need to make string changes to update the docs
[21:46] <seb128> mdke, we have quite some applications using "software name function"
[21:46] <mdz> kirkland, I understand, it's not your fault
[21:47] <mdke> seb128: I was comparing it with the other basic applications in the Accessories menu, like Calculator, Terminal etc
[21:48] <mdke> seb128: but yeah, it's true for the Internet menu
[21:48] <mdke> (and others)
[21:48] <seb128> we are in a situation were it's mixed and they are trying to fix it now I think
[21:48] <seb128> I agree it's a bit late for this cycle
[21:48] <seb128> I'm not strongly opposed to delay the gedit change to next cycle
[21:51] <mdke> seb128: it's not a huge issue from a docs point of view either, I've checked and I think we only have one string which uses "Text Editor". I suppose the easiest is to go with upstream and hope that they fix the inconsistency in future cycles
[21:54] <seb128> mdke, you are not the first on to mention than having the title starting with a small letter is weird though so I'm not sure, I will think about it until tomorrow
[21:55] <mdke> seb128: ok - as long as you post to the bug report, we'll pick it up
[21:55] <mdke> seb128: thanks
[21:55] <seb128> thank you for bringing the issue!
[21:55] <mdke> anytime. I'm good at bringing issues :(
[22:11] <slangasek> cjwatson: so, I guess ubuntu-desktop is being held back here due to the libgd2-(no)?xpm conflict... any thoughts on how to resolve this?
[22:13] <cjwatson> hmm, I guess I'll tell you once it filters down to my mirror :)
[22:13] <cjwatson> we could try dropping -noxpm's priority, ISTR apt pays some attention to that
[22:15] <slangasek> ok, lowering to extra
[22:49] <kirkland> kees: can you make https://edge.launchpad.net/ubuntu/+source/eucalyptus/1.6~bzr912-0ubuntu1/+build/1277101 build now?
[22:49] <kees> kirkland: one moment...
[22:50] <kees> kirkland: when palmer, rothera, or vernadsky finish, eucalyptus will build.  I don't have the ability to cancel a running build.
[22:50] <kirkland> kees: cool, thanks.
[22:50] <kees> kirkland: (I've scored it high to build next...)
[22:51] <kirkland> great, thanks
[22:53] <kees> kirkland: now building
[22:53] <kirkland> kees: outstanding
[22:54] <kees> that was fun! first time I've used that super-power.  ;)
[22:55] <kirkland> kees: oh, we can exercise that some more, if you want more fun in your superhero life
[23:10] <kirkland> slangasek: okay, could you push a server ISO build for me, with eucalyptus 1.6~bzr912-0ubuntu1 ?
[23:10] <kirkland> slangasek: please, and thanks!
[23:11] <slangasek> kirkland: queued
[23:11] <kirkland> slangasek: cheers
[23:29] <jono> directhex, around?
[23:32] <directhex> jono, give or take, sure
[23:37] <nurmi> kirkland: regarding lp bug 439364 - trying to register 'localhost' with walrus is not valid (for the reasons we've discussed).  the bug is currently marked 'high/incomplete', should it be closed or do you feel that there is further action here?