[01:16] <wgrant> lamont: Around to talk a bit about fairly important buildd changes?
[01:26] <spm> wgrant: fyi. he may answer anyway; but he eod' about 90 mins ago.
[01:30] <wgrant> spm: Oops, I thought it was closer than that, but I forget that DST switched off a few days ago.
[03:11] <lamont> wgrant: heading out to dinner with my sister - catch me tomorrow PST work hours?
[03:12] <wgrant> lamont: OK, I'll try to catch you late in that interval.
[03:13] <lamont> sounds good - when do you come online?  (UTC fine)
[03:14] <wgrant> lamont: I'm +11 at the moment, and am normally around from about 2100 UTC.
[03:15] <lamont> so yeah - I'm generally wrapping things up and getting ready to run by 2200-2300UTC
[03:15] <wgrant> Right.
[03:17] <lamont> and this week, I'm -8, and trying to be done by 3PM local --> 2300... so not too bad
[03:54] <exewmt> Just watched karmic boot cd fry a monitor
[03:54] <exewmt> On first boot, i386
[03:56] <hyperair> fry a monitor?
[03:56] <hyperair> that's pretty interesting. i wanna see too
[03:57] <exewmt> Yep, booted until modesetting for 2nd splash
[03:57] <exewmt> Flashing light now
[03:57] <exewmt> Can't even display post
[03:57] <exewmt> Dead
[03:58] <hyperair> do you smell anything? =p
[03:58] <exewmt> Not my pc either, after installing ubuntu for people for 4 years, I get to buy a monitor
[03:58] <exewmt> No
[03:58] <exewmt> No burning, nothing of the sort
[03:59] <hyperair> heh
[03:59] <hyperair> well, if it can burn from improper settings, it sure as hell has to be very old =p
[03:59] <hyperair> about time, i'd say
[03:59] <wgrant> I think that monitor is disobeying some fairly important common sense.
[03:59] <hyperair> i agree
[03:59] <exewmt> Yeah, Dell 15" , veery common
[03:59] <exewmt> Scary how common actually
[04:00] <exewmt> For legacy desktop stuff
[04:00] <exewmt> About time? It's now on me to replace it, way to go
[04:01] <exewmt> Just figured I'd tell you, but I guess it's just on everyone to upgrade
[04:03] <jcastro> ScottK, around?
[04:03] <exewmt> I really hope that isn't the stance shuttlesworth wants .com take
[04:03] <ScottK> jcastro: Yep
[04:03] <jcastro> ScottK, pretend I want to run -proposed to be a good citizen so I can find bugs before they hit -updates
[04:03] <MsMaco> exewmt: this isnt where bugs get reported
[04:03] <ScottK> exewmt: I think it's worth a bug report, although I think it's unlikely it's anything other than coincidental.
[04:04] <exewmt> There should be a big red banner until that gets fixed though, because Dell has sold millions of these models in the us
[04:04] <jcastro> ScottK, is there a bug list or tag I can follow?
[04:04] <ScottK> jcastro: There is.  Let me find it.
[04:04] <MsMaco> "warning: using the wrong mode is bad for screens"?
[04:04] <LaserJock> jcastro: ;-)
[04:04] <exewmt> Scott: I watched it, it booted to splash
[04:04] <ScottK> jcastro: Did the OpenWeek PDF get fixed.
[04:04] <jcastro> I don't think it did
[04:04] <exewmt> MsMaco: It's Automaticc
[04:04] <wgrant> MsMaco: The thing is, it hasn't been bad for them for like 15 years.
[04:05] <MsMaco> wgrant: wow
[04:05] <ScottK> exewmt: I'm not saying it didn't fry when you booted it, I'm just saying I think it's unlikely it was caused by a bug.
[04:05] <jcastro> ScottK, I can check it now
[04:05] <ScottK> I still think it's worth filing, just in case.
[04:05] <exewmt> ScottK: Thing is.... It won't even go to amber led
[04:06] <ScottK> exewmt: I don't doubt it died.
[04:06] <exewmt> Now just the same flashing green that first occurred when mode changes to grey screen w bar in boot seuence
[04:06] <exewmt> like, right when the mode changes to 2nd booting splash
[04:06] <ScottK> jcastro: http://people.canonical.com/~ubuntu-archive/pending-sru.html - I don't recommed 'running proposed' however.  I recommend enabling it, installing just the package you want to test, and then disabling it.
[04:07] <exewmt> That is why I don't think it was purely coincidence
[04:07] <exewmt> I have a few more, should I fry another!
[04:07] <exewmt> ? (sorry touchtyping$
[04:07] <wgrant> Oh, right, I forget about the DIEMONITORDIE command that xsplash sends on startup.
[04:08] <serialorder> is debootstrap ready so i can set up a chroot for Lucid? I was looking at it and noticed its the same one as used in Karmic
[04:08] <exewmt> wgrant: Just saying that between every other ver of xsplash used
[04:09] <exewmt> Maybe t's a bug affecting the ver bundled in the cd
[04:09] <ScottK> exewmt: What's in the CD and in the archive is the same.
[04:09] <ScottK> serialorder: I think they added lucid to the karmic one before release.
[04:10] <jcastro> ScottK, I've always just thought we're supposed to run -proposed and report bugs.
[04:10] <exewmt> k, But should I test w an identical monitor and see if it bricks it?
[04:10] <ScottK> exewmt: Your call.  If it did, it would be pretty conclusive.  I think it's unlikely to.
[04:11] <ScottK> jcastro: I know people do that, but I don't recommend it nor do it myself.  The point is that we put stuff in proposed to test it and it doesn't always work out well.
[04:11] <wgrant> jcastro: That can cause problems when something is copied from -proposed to -updates, and all the testers use -proposed in its entirety. It could be broken with versions in -updates.
[04:11] <exewmt> ScottK: We have a running bet then
[04:11] <exewmt> I'll be back tomorrow to report
[04:11] <wgrant> So it's important to get people to test each -proposed package with everything else in -updates.
[04:12] <ScottK> jcastro: I've personally seen more problems with running -proposed than with -backports.
[04:12] <ajmitch> ScottK: that doesn't sound positive
[04:12] <MsMaco> i usually run with proposed enabled
[04:12] <ScottK> ajmitch: Thus my recommendation.
[04:12] <jcastro> wow
[04:12] <ScottK> I've also almost never seen a problem with backports.
[04:13] <hyperair> has anyone noticed any issue with the recent udev SRU?
[04:13] <MsMaco> ScottK: i can think of one problem with backports :P
[04:13] <ajmitch> I hadn't noticed there was a udev SRU
[04:13] <ScottK> I remember that one.
[04:13] <jcastro> ScottK, I only noticed this problem now when LaserJock told me his empathy was crashing and I asked him to enable -proposed and he was wary of enabling the whole thing
[04:13] <serialorder> ScottK, thanks
[04:14] <jcastro> ScottK, has someone talked about this with like pitti or something?
[04:15] <ScottK> jcastro: It gets discussed every now and then.
[04:15] <MsMaco> well the point of proposed is to catch bugs...
[04:15] <LaserJock> it seems like we had some threads about this like a year ago
[04:15] <ScottK> So far the "If we have people enable everything, we get more testers" has won the day.
[04:15] <ScottK> LaserJock: We did.
[04:15] <LaserJock> something about when the desktop team was thinking of having a staging PPA or something
[04:17] <LaserJock> for me a lot of the -proposed vs -backports issue stems from a lot of -proposed packages being pretty core things
[04:17] <LaserJock> I don't often get a whole new kernel, Xorg, evolution, etc. from -backports
[04:18] <LaserJock> :-)
[04:18] <jcastro> well, backports are new upstream releases
[04:19] <LaserJock> yep, but in my experience new upstream releases of low-risk packages
[04:19] <ScottK> Or when we do backport risky stuff, we do actually test it a lot before putting it in.
[04:19] <ScottK> Backports is often more tested than Proposed, but generally less tested than Updates.
[04:20] <jcastro> proposed is supposed to be the staging area for updates afaik
[04:20] <wgrant> Right.
[04:20] <wgrant> And sometimes stuff gets in there with very, very little testing.
[04:20] <wgrant> Which is why very few people should run -proposed.
[04:20] <LaserJock> right, there's no real check on what goes in to -proposed other than pitti's quick check
[04:21] <jcastro> do you have examples of little tested things that hit proposed?
[04:21] <wgrant> I sense that this is turning into that ML thread.
[04:22] <MsMaco> i thought the point of proposed was to do testing
[04:23] <ScottK> jcastro: We had a bad svn regression in -proposed that I recall.
[04:23] <MsMaco> i mean, the uploader should test yeah, but...if it was perfectly tested before upload, we wouldnt need proposed
[04:23] <jcastro> MsMaco, yeah but in some cases (like hardware stuff) there's only some testing an uploader can do
[04:23]  * ScottK recalls a MOTU who was unaware udpates should be tested before uploading to proposed.
[04:24] <ScottK> I asked him how to test the fix and the response I got was, "I don't know".
[04:24] <jdong> b/i/r in pre... oh wait wrong process
[04:24] <MsMaco> jcastro: right so...proposed is for testing...
[04:24] <MsMaco> im confused by whats surprising about that
[04:24] <ScottK> Which is why you should just install stuff from it you plan to test, IMO.
[04:25] <MsMaco> ok i should just shush since im obviously the weird one in this bunch
[04:26] <jcastro> I don't think it's weird
[04:26] <MsMaco> if i run stable, its with proposed enabled. though i rarely run stable.
[04:26] <MsMaco> "production" system or not
[04:27] <MsMaco> (read "production" as "the only computer i have")
[04:27] <jdong> well IMO if you install a package from -proposed, it should be to contribute to the verification process
[04:29] <ScottK> The theory last time we went around on this was more peole just running proposed would increase the odds of catching an odd regression.
[04:30] <MsMaco> there were a few odd evolution regressions on hardy-proposed, i remember
[04:31] <johanbr> it worked the way it was supposed to? :)
[06:53] <wgrant> pitti: You might want to copy jaunty-updates' tzdata to karmic-updates and lucid. We're seeing a few people confused by bug #467165.
[07:27] <dholbach> good morning
[07:36] <ebroder> Hmm...am I supposed to be poking somebody to get lilo-installer accepted into hardy-proposed?
[07:44] <stooj> Morning Daniel
[07:44] <dholbach> hi stooj
[07:45] <stooj> I feel sorry for you - 9.10 is awesome, and you have to move straight on to Lucid already!
[07:45] <wgrant> But Slashdot and The Register say that 9.10 sucks. They must be right.
[07:46] <stooj> Grr @ elReg: "60% of people hate Karmic in a poll on ubuntuforums" == News
[07:47] <wgrant> Yup.
[07:50] <dholbach> stooj: karmic development slowed down a lot in the last weeks, so some of us got a bit of a break :)
[07:51] <stooj> Glad to hear it
[07:51] <stooj> Going home - later all
[08:07] <highvoltage> well they say there's no such thing as bad publicity
[08:08] <user_> hi guys.. i'm manipulating init scripts on my machine - I want service 1 to be stopped only AFTER service 2 is stopped. Do I use "Should-Stop 2" for this ?
[08:17] <primes2h> apw: Hello, any news about this bug #446146?
[08:17] <jsgotangco> hello sabdfl
[08:50] <apw> primes2h, the fix for that is committed and will be rolled out in the first kernel SRU which is expected pretty soon.  likely thursday currently
[09:01] <pitti> Good morning
[09:03] <pitti> wgrant: ah, because of the +repack thing
[09:03] <pitti> wgrant: yeah, will do; thanks
[09:03] <wgrant> pitti: Thanks.
[09:04] <pitti> wgrant: ah, no, can't do; the packaging changed slightly, and it would be a regression to move the jaunty one to karmic
[09:05] <pitti> wgrant: what I'll do instead is to update the entire squad to 2009q, which was just released
[09:05] <wgrant> pitti: Even better.
[09:16] <primes2h> apw: Oh, that's nice. At least users would stop changing status to "fix released" on their own. ;)
[09:59] <slangasek> pitti: you marked bug #441638 as assigned to you; still working on it?  it seems there are a fair number of users for whom having bulletproof-X available would be a particular help right after upgrade
[10:00] <pitti> it's still on my list; although I didn't really intend to implement bulletproof X, just to stop the eternal auto-respawning
[10:00] <pitti> but if someone else wants to beat me to it, be my guest, of course :)
[10:01] <slangasek> pitti: ah - then per https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/441638/comments/20, I'll take it if you won't
[10:02] <pitti> oh, thank you
[10:08] <slangasek> siretart: hum, your cryptsetup apport hook change makes the package ftbfs in bzr
[10:09] <slangasek> siretart: though I have yet to figure out why
[10:10] <siretart`> slangasek: I thought keybuk uncommitted it? - anyway, I think there is just a 'mkdir' missing in debian/rules
[10:10] <slangasek> well, or an entry missing from debian/dirs
[10:10] <slangasek> (though why does this package not use dh_install, sigh)
[10:10] <siretart`> ah, right. that'd be easier
[10:10] <slangasek> anyway, no, not uncommittd
[11:22] <NCommander> superm1, ping? (I'd like to talk to you about recovery partitions if you have a moment soonish)
[13:03] <Laney> Could someone rescore https://launchpad.net/~laney/+archive/ppa/+build/1319012 for me, pretty please?
[13:05] <Laney> (testing an ftbfs fix for lucid)
[13:12] <Laney> never mind, someone else did it :)
[13:13] <pitti> cjwatson: could we have http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid ?
[13:32] <seb128> do we know when autosyncs should start? they are blocked on source format changes too?
[13:32] <ogra> doko, is the gcc in the archive already using ARMv7 and thumb2 ? or is that only the one in your ppa ?
[13:32] <wgrant> seb128: The autosyncer will crash at the moment due to the new source formats.
[13:32] <james_w> seb128: the autosyncer is currently pointing at unstable
[13:33] <james_w> that will be fixed in the LP rollout scheduled for tomorrow morning I believe
[13:33] <seb128> is there anything stopping me to sync the desktop things I want if they are in good old source format still?
[13:33] <wgrant> seb128: I have a LP branch waiting for RC approval which will stop it from crashing, however it will not be able to sync v3 packages until somebody from the distro world convinces LP that it is important.
[13:33] <pitti> seb128: no, that works fine
[13:33] <james_w> specific syncs in the old format are fine as far as I know
[13:33] <seb128> ok thanks
[13:33] <wgrant> That will work fine, right.
[13:33] <pitti> I did several syncs and they work well
[13:34] <seb128> I just wanting to make sure before stepping where I should not ;-)
[13:34] <pitti> seb128: if Soyuz breaks, we'll blame you :)
[13:34] <seb128> I knew it!
[13:34] <seb128> ;-)
[13:36] <sebner> slangasek: is the ext4 corruption bug already fixed? LP says no so I'm wondering if it's the same issue linus closed with new -rc kernel. http://lkml.org/lkml/2009/11/3/377
[14:16] <siretart`> james_w: if some package branch is not available, does it make sense to report it as a bug, nag you on irc, or should I rather ignore it and just merge the package it in the "traditional" way?
[14:20] <smoser> does anyone know why ppa builds are taking so long ? https://launchpad.net/~smoser/+archive/ppa/+build/1318926 has been uploaded for 17 hours, it is to "start in 9 hours"
[14:21] <ScottK> smoser: Look at the number of actively PPA buildds currently.
[14:22] <Laney> apparently they were taken out to be release mirrors
[14:24] <smoser> ScottK, where is that info?
[14:25] <smoser> ah.
[14:25] <smoser> but, just wondering, where can you see that?
[14:25] <ScottK> smoser: https://launchpad.net/builders/
[14:26] <james_w> siretart`: yes, yes and yes :-)
[14:26] <soren> I'm still somewhat surprised that computing power is the bottleneck rather than bandwidth :)
[14:26] <smoser> thanks ScottK .
[14:27] <james_w> if you want me to take a look then I will, but it is often more than a 5 minute thing, so if it is urgent doing it another way would probably be wise
[14:28] <siretart`> no, it is not urgent. I'm just experimenting with merging package with bzr and I am making great experiences
[14:28] <smoser> more wondering, if "Architecture: all" then it gets built on i386 ?
[14:29] <ScottK> smoser: Yes
[14:37] <sgallagh> mathiaz: A few months ago, you reported a set of unused dependencies in the SSSD. I didn't have time to look into them until now. I saw that you guys pulled in 0.7.1 recently. Would it be possible for you to point me to the build log, so I can see the set of unused dependencies?
[14:37] <sgallagh> /set/updated set/
[14:38] <mathiaz> sgallagh: sssd is still at 0.5.0 in the developement  version (lucid)
[14:38] <mathiaz> sgallagh: there is a bug to update it to 0.7.1 though
[14:39] <sgallagh> mathiaz: Oh ok, so it hasn't been run yet. I was just trying to get the updated set of dependencies so I can fix them all in one go.
[14:42] <mathiaz> sgallagh: ok - I'll try to get a test build run
[14:42] <mathiaz> sgallagh: and file a bug report about it
[14:44] <sgallagh> mathiaz: That would be fantastic. Thank you.
[14:55] <davmor2> pitti: I've done a bunch of upgrade tests and I can't reproduce the issues people are having with the kernel being the jaunty one.  Also only issue I did come across was one on audio where the gfx card has hdmi out.  But once I'd told pulse which card to use and unmuted it was fine.
[14:56] <pitti> davmor2: thanks; perhaps it's related to using apt-get dist-upgrade?
[14:56] <davmor2> pitti: I can run one and see for you if you want?
[14:57] <pitti> if you want, would be interesting to see if we have a bug there; but it should all be covered by the metapackages, I'd think?
[14:57] <pitti> davmor2: it wouldn't work if they removed the linux meta packages, of course
[14:58] <mvo> the upgrader will take care of a linux meta-package automatically, only apt-get users can be hit by that
[14:59] <davmor2> I'll try an apt-get upgrade and see how it does
[14:59] <davmor2> dist-upgrade even
[15:02] <pitti> davmor2: thank you!
[15:03] <doko> kees: online?
[15:10] <kees> doko: I am now, hi!
[15:20] <cjwatson> pitti: oops, forgot about that. It'll generate next time the cron job fires
[15:20] <seb128> doko, could you unbreak python in lucid too for the -lssl issue?
[15:20] <pitti> cjwatson: thanks
[15:21] <doko> seb128: no, please fix the apps
[15:21] <seb128> doko, there is a ton to do, could you be help having smooth transitions?
[15:22] <seb128> doko, that breaks a good part of GNOME
[15:22] <seb128> and I will not be able to look at those before uds
[15:22] <doko> it's not breaking a running a system, so we should fix these during merges
[15:22] <seb128> between vac, travelling and sprint next week
[15:23] <seb128> I don't know how to fix those
[15:23] <seb128> could you send patches please?
[15:24] <seb128> doko, I guess I will just add libssl depends everywhere for now
[15:24] <doko> not this week, and maybe not next week. if such a package is on my merge list, I'll fix it of course
[15:24] <doko> seb128: don't do that, the bug report is concise about the exact fix
[15:25] <seb128> doko, could be clear to you but it's not to me and I said I don't want to get things blocked until after uds
[15:25] <doko> seb128: what exactly is unclear?
[15:25] <seb128> the same packages is working in debian and those build fine in any other distro
[15:26] <seb128> I've no time to deal with autotools changes and convincing upstream of why ubuntu need that now
[15:26] <doko> seb128: no, it's not in experimental
[15:26] <seb128> it's a compatibility breakage on your side imho
[15:26] <seb128> but whatever I don't want to argue now
[15:27] <seb128> I will add the depends so I get things to build
[15:27] <seb128> thanks
[15:27] <jcastro> Riddell, pitti, you have scheduling powers in the summit system now
[15:27] <pitti> jcastro: thanks
[15:27] <pitti> jcastro: rickspencer3 as well?
[15:27] <jcastro> yep
[15:32] <doko> seb128: I'm a bit pissed about your attitude to work around a known bug; it'll just be extra work later in the cycle
[15:35]  * Riddell feels the power
[15:36] <seb128> doko, looks like a compatibility breakage on your side and not a known bug to me but I don't think arguing will bring you somewhere
[15:36] <seb128> doko, so let's agree to disagree
[15:36] <doko> seb128: no, it has nothing to do about "compatibility"
[15:36] <seb128> doko, the python package should not those public if they are not meant to be used and if they are public you should install enough to get it working
[15:36] <pitti> what is the actual issue?
[15:36] <seb128> it's like shipping a .pc and saying to not use it
[15:37] <seb128> pitti, some python flag bringing -lssl without depends on libssl-dev
[15:37] <seb128> pitti, let me look again to the exact build failure
[15:39] <seb128> pitti, /usr/lib/python2.6/config/Makefile: LOCALMODLIBS=                       -lssl -lcrypto  -lssl -lcrypto      -L$(exec_prefix)/lib -lz
[15:40] <seb128> pitti, that is shipping with python2.6
[15:40] <seb128> and GNOME softwares use it
[15:40] <seb128> but python doesn't have the depends corresponding to the -l<nnn>
[15:41] <pitti> seb128, doko: are LOCALMODLIBS meant to get linked to external softare?
[15:41] <doko> it is wrong that an extension links with LOCALMODLIBS
[15:41] <seb128> what should be used instead?
[15:41] <seb128> I just feel that I understand the issue enough to argue upstream or open a bug there
[15:41] <seb128> +don't
[15:42] <pitti> can't we just stop the affected packages from including LOCALMODLIBS into their linkage list?
[15:42] <pitti> that would also avoid extra dependencies and make transitions easier
[15:42] <doko> don't use LOCALMODLIBS at all
[15:42] <seb128> why did they start using it in the first place?
[15:43] <doko> the jaunty and karmic behaviour always links these libs with -lz, which is wrong as well. just by chance, or because zlib-dev is installed, lets you get away with it
[15:44] <seb128> ok, let me try to just drop that from the configure
[15:44] <doko> what was the bug number?
[15:45] <seb128> do you have any pointer saying why those should be used to use for upstream bug reference?
[15:45] <seb128> doko, bug #450355
[16:03] <doko> seb128: at least for rhythmbox this is code which pre-dates distutils (i.e. python1.5). upstream is removing more and more of this old build stuff in every release, so an application/extension shouldn't rely on it. This code in gnome is really, really old. either distutils should be used, or at least python-config
[16:05] <doko>         PYTHON_CFLAGS="-I$PY_PREFIX/include/python$PYTHON_VERSION"
[16:05] <doko>         PYTHON_LOCALMODLIBS=`sed -n -e 's/^LOCALMODLIBS=\(.*\)/\1/p' $PYTHON_MAKEFILE`
[16:05] <doko>         PYTHON_BASEMODLIBS=`sed -n -e 's/^BASEMODLIBS=\(.*\)/\1/p' $PYTHON_MAKEFILE`
[16:05] <doko>         PYTHON_OTHER_LIBS=`sed -n -e 's/^LIBS=\(.*\)/\1/p' $PYTHON_MAKEFILE`
[16:05] <doko>         PYTHON_EXTRA_LIBS="$PYTHON_LOCALMODLIBS $PYTHON_BASEMODLIBS $PYTHON_OTHER_LIBS"
[16:07] <doko> pitti, seb128: for a quick fix, just remove the lines about PYTHON_LOCALMODLIBS and PYTHON_BASEMODLIBS. PYTHON-CFLAGS should use the output of python-config --includes to pick up the correct headers for debug builds, but apparently is not necessary in that package
[16:08] <doko> anyway, afk now
[16:23] <seb128> doko, ok thanks
[16:41] <Riddell> doko: word reaches me that gdb 7.0 is broken for c++, do you know anything about it?
[16:41] <Riddell> http://lists.trolltech.com/pipermail/qt-creator/2009-November/004963.html
[16:41] <davmor2> pitti: apt-get dist-upgrade seems to be correct just confirming now
[16:41] <Riddell> ScottK: what does your backports hat say to having a gdb-6.8 in backports and having qt-sdk depend on that?
[16:41] <davmor2> pitti: it is in fact correct
[16:43] <ScottK> Riddell: I don't understand.  We already have 7.0 in Karmic?
[16:44] <Riddell> ScottK: and I'm told it's broken
[16:44] <Riddell> for c++
[16:45] <ScottK> Riddell: So you're thinking introduce a new gdb-6.8 package?
[16:45] <Riddell> ScottK: yes
[16:45] <ScottK> If so, I'd say get it into Lucid and a backport of a new package is no problem at all.
[16:46] <Riddell> doko: got an opinion on that?
[16:46] <ScottK> It might not be a bad idea to have a non-broken with C++ gdb in the development series either.
[16:56] <davmor2> pitti: anything else you'd like me to try?
[17:03] <pitti> davmor2: thanks; so I guess it's a customized /boot/grub/menu.list or something such
[17:03] <davmor2> pitti: it certainly sounds it, that or a modded kernel
[17:14] <jdstrand> soren: is there a vmbuilder somewhere that let's me build a lucid vm?
[17:14] <jdstrand> soren: hi btw!
[17:21] <tag> I've been having trouble with a segfault in libc since one of the Karmic beta releases and it has continued even on a fresh install of the official karmic release.
[17:21] <tag> It appears to be related to catgets, now I'm not sure if it has anything to do with localization files somehow.
[17:24] <tag> I know that's what catgets/catopen is used for.  When javac segfaults:
[17:24] <tag> or java, rather
[17:24] <tag> # C  [libc.so.6+0x31b08]  catgets+0x18
[17:24] <tag> I'm having trouble with both swing apps and some SDL apps, but specifically *all* java swing apps and the fancy-terminal tilda.
[17:37] <tag> I can't seem to recreate the segfault by simply exercising catgets()
[17:47] <mathiaz> robbiew: hi - are there any guidelines for naming blueprints for lucid uds?
[17:47] <mathiaz> robbiew: for karmic we used to have karmic-$track-foo as a template
[17:48] <mathiaz> robbiew: has this changed for Lucid UDS?
[17:48] <robbiew> not that I know of
[17:48] <robbiew> as long as you are consistent
[17:49] <robbiew> it really doesn't matter
[17:49] <robbiew> just helps with finding the blueprints quickly for scheduling
[18:02] <mpt> robbiew, is mvo's reply enough info for you to schedule UDS sessions on Ubuntu Software Center stuff?
[18:03] <robbiew> yeah...I'll be doing the scheduling
[18:03] <robbiew> this week
[18:03] <mpt> ok, thanks
[18:18] <slangasek> sebner: no, it's completely unrelated to the problem Linus is seeing in 2.6.32.
[18:19] <sebner> slangasek: oh, I'm sorry than
[18:34] <kirkland> https://bugs.launchpad.net/bugs/458549  <--- most entertaining bug report in a while
[18:52] <buxy> Unfortunately merge-o-matic is down due to Debian's change of source package format.
[18:52] <buxy> anyone knows for how long? unfortunately the PTS mails me every 6 hours when http://patches.ubuntu.com/PATCHES can't be downloaded
[18:53] <buxy> slangasek: ^ (ping someone random that I know :))
[18:53] <slangasek> buxy: until someone can update the merge-o-matic code to cope with the new packages; I think next week at the earliest
[18:54] <ScottK> buxy: It's actually down due to Ubuntu not planning for the new source format.  Debian didn't do this by suprise.
[19:09] <james_w> ScottK: bear in mind you are speaking to someone that is intimately familiar with how Debian did it ;-)
[19:11] <buxy> heh :)
[19:21] <kirkland> pitti: hi there
[19:21] <kirkland> pitti: around? procedure question for you
[19:21] <kirkland> pitti: order of operations, really
[19:35] <mathiaz> sgallagh: hi - the current code in sssd trunk is supposed to be named 0.7.2 or 0.8.0?
[19:35] <mathiaz> sgallagh: making sure to have the right upstream version number in the snapshot I'm preparing
[19:40] <kirkland> mathiaz: okay, i have *fixed* https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/404394  :-)
[19:40] <kirkland> mathiaz: i just uploaded to -proposed for SRU ification
[19:40] <kirkland> mathiaz: i also uploaded the fix to hardy-backports and intrepid-backports, as it needs to be fixed there too
[19:40] <mathiaz> kirkland: as in: a SRU for -backports?
[19:41] <kirkland> mathiaz: right, sort of
[19:41] <mathiaz> kirkland: out of curiosity - do you plan to do a backport of karmic kvm to hardy?
[19:41] <jdong> bugfix on top of backports (tm) :)
[19:41] <kirkland> mathiaz: no
[19:41] <mathiaz> kirkland: virtio doesn't work on hardy host + karmic guests
[19:41] <kirkland> mathiaz: the kvm-84 backport took a *lot* of effort
[19:41] <mathiaz> kirkland: agreed.
[19:41] <kirkland> mathiaz: how so?
[19:41] <kirkland> mathiaz: i think this new upload might fix that for you...
[19:42] <kirkland> mathiaz: you want a ppa package to test?
[19:44] <mathiaz> kirkland: hm - I don't find the bug right now :/
[19:44] <mathiaz> kirkland: it had to do with disk errors
[19:44] <kirkland> mathiaz: that's this
[19:44] <mathiaz> kirkland: you'd see them in the guest - like I/O errors
[19:44] <kirkland> mathiaz: right
[19:44] <mathiaz> kirkland: ok - then it's good news :)
[19:44] <kirkland> mathiaz: i believe this upload fixes your problem
[19:44] <kirkland> mathiaz: you want to grab the patch and test, or you want a ppa build?
[19:45] <kirkland> mathiaz: ppa build will take a while
[19:45] <mathiaz> kirkland: it will cut down iso testing from 4 hours to 2 h and 42 minutes
[19:45] <mathiaz> kirkland: I can wait for the PPA build
[19:45] <kirkland> mathiaz: https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/404394/comments/16
[19:45] <kirkland> mathiaz: that's the hardy patch
[19:45] <mathiaz> kirkland: ok - I may have a look at it later
[19:54] <kirkland> mathiaz: is your hardy kvm server amd64 or i386 ?
[19:54] <mathiaz> kirkland: amd64
[20:00] <superm1> hi NCommander, what's up?
[20:01] <KEBA1> considering the new gnome features (gnome shell and gnome zeitgeist) will come september 2010, is it possible that 10.10 will be a lts version instead of 10.04?
[20:01] <KEBA1> because mabye the old gnome wont be supported a long time
[20:01] <MsMaco> 10.04 wasnt going to get gnome 3 anyway
[20:03] <kirkland> popey: outstanding blog post on upgrading
[20:03] <popey> thanks kirkland
[20:06] <MsMaco> popey++
[20:07] <KEBA1> MsMaco: ah ok, because it might be to unstable?
[20:07] <KEBA1> like kde 4.0
[20:08] <MsMaco> i guess so
[20:08] <MsMaco> lessons learned?
[20:08] <nxvl> james_w: did you know why lp:ubuntu/hardy-security/firefox-3.0 is firefox 3.0.14 and not 3.0.15?
[20:08] <nxvl> i mean the branch
[20:08] <nxvl> james_w: isn't it updated automagically after upload?
[20:08] <james_w> yes
[20:09] <james_w> I've been working out some kinks that meant it sometimes fell over though
[20:12] <nxvl> james_w: mm, so i just need to wait?
[20:12] <nxvl> james_w: it has been 2 days
[20:14] <james_w> nxvl: forced a check of that package
[20:15] <nxvl> james_w: thank you
[20:16] <james_w> nxvl: damn
[20:16] <james_w> hit a bzr bug
[20:16] <james_w> let me see if I can do anything about that
[20:16] <nxvl> james_w: my problem isn't exactly now
[20:17] <nxvl> james_w: i'm already late and doing some workarounds to make it work, so don't worry
[20:17] <nxvl> james_w: what i'm worried is about it becaming my primary process
[20:17] <nxvl> james_w: maybe we can discuss this better at UDS
[20:17] <james_w> yes
[20:18] <kirkland> mathiaz: build done -> https://edge.launchpad.net/~kirkland/+archive/ppa/+build/1320609
[20:18] <kirkland> mathiaz: could you grab that .deb, try it out and let me know?
[20:20] <mathiaz> kirkland: sure - when do you need an answer?
[20:41] <wgrant> lamont: Around?
[20:42] <kirkland> mathiaz: today'ish?
[20:42] <kirkland> mathiaz: i figure pitti will accept the upload for -proposed tonight
[20:42] <kirkland> mathiaz: i'd like to have your feedback before then, if possible
[20:43] <mathiaz> kirkland: okoidoikoi
[20:44] <sebastien_> Hello tous le monde
[20:44] <james_w> nxvl: I appreciate the testing, I'm working to iron out the kinks as you find them. Thanks.
[20:44] <sebastien_> what is the chan for the ubuntu dev web ?
[20:47] <nxvl> james_w: thank you for making my life easier :D
[21:00] <mathiaz> james_w: seems that the karmic checkbox branch is not up-to-date
[21:02] <mathiaz> cr3: ^^ this is why it generates these huge diff
[21:02] <mathiaz> cr3: when you ask the review
[21:02] <james_w> mathiaz: queued an import, thanks
[21:03] <mathiaz> james_w: great - thanks
[21:03] <james_w> I took the opportunity of the release to do some infrastructure work, so downtime was longer than desirable
[21:12] <lifeless> james_w: hi
[21:12] <james_w> hi lifeless
[21:12] <lifeless> you have mail
[21:13] <lifeless> I think I mailed you about this some months ago
[21:13] <lifeless> but I was reminded recently
[21:14] <james_w> don't see it yet, give me a clue?
[21:16] <lifeless> pristine tar
[21:16] <lifeless> bzr
[21:18] <wgrant> slangasek: I slipped that autosync crasher fix into 3.1.10, as it has been delayed.
[21:19] <slangasek> has it?
[21:19] <wgrant> Yeah, by 24 hours -- 2009-11-05 0900
[21:19] <james_w> lifeless: the answer is still the same as before
[21:20] <lifeless> james_w: I don't recall what it was, sorry
[21:26] <slangasek> wgrant: ah, ok
[21:26] <slangasek> wgrant: that must be why the announcement mail didn't look right to me :)
[21:28] <ScottK> Fortunately someome pointed out they'd neglected to announce their planned outage, so they rescheduled and announced.
[21:29] <fta> do we already know if lucid will use gcc 4.5 or stick with 4.4?
[21:31] <slangasek> fta: 4.4
[21:31] <fta> ok, thanks
[21:31] <mathiaz> cr3: http://bazaar.launchpad.net/~cr3/ubuntu/karmic/checkbox/0.8.5-0ubuntu1/revision/13
[21:31] <mathiaz> cr3: is this^^ the diff to apply to checkbox?
[21:32] <mathiaz> cr3: (except for the revision number - that I can fix)
[21:35] <mathiaz> kees: hm - trying to do a SRU for a native package (checkbox)
[21:36] <mathiaz> kees: the new revision number is 0.8.5-0ubuntu0.1 as suggested by https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging
[21:36] <mathiaz> kees: however debuild -S complains about a missing .orig.tar.gz file
[21:36] <james_w> I don't think that recommendation applies to native
[21:37] <mathiaz> kees: http://paste.ubuntu.com/309940/
[21:37] <kees> mathiaz: hrm, yeah, that suggestion in the wiki may be wrong.
[21:37] <slangasek> honestly, I think it's better to ignore the debuild complaint
[21:37] <kees> mathiaz: I would have said 0.8.5ubuntu0.1 or 0.8.5~0.1 .... native packages are weird.
[21:38] <mathiaz> slangasek: doing that create a checkbox_0.8.5-0ubuntu0.1.tar.gz
[21:38] <kees> slangasek: that works too :)
[21:38] <slangasek> mathiaz: I don't see a problem with this :)
[21:38] <slangasek> 0.8.5~0.1 doesn't work, that would sort earlier than 0.8.5
[21:38] <mathiaz> kees: ok - so what do you suggest?
[21:39] <kees> slangasek: it won't?  I thought that's what ~ did.
[21:39] <kees> mathiaz: 0.8.5-0ubuntu0.1 without an orig should be fine
[21:39] <slangasek> kees: ~ sorts before null
[21:39] <slangasek> so if you're already at 0.8.5, 0.8.5~0.1 means going backwards
[21:39] <mathiaz> kees: ok - thanks.
[21:40] <kees> slangasek: right, i assumed 0.8.5 did not yet exist (i.e. SRU)
[21:40] <kees> I see, however, that this is not true.  :)
[21:40] <mathiaz> kees: oh - 0.8.5 is already in the archive
[21:40] <kees> mathiaz: how about 0.8.5.1 then?  :)
[21:41] <mathiaz> kees: that's possible as well
[21:41] <mathiaz> kees: I was just following https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Packaging
[21:41] <slangasek> well, given that it's a native package anyway, 'ubuntu' in the version number seems redundant
[21:41] <slangasek> 0.8.5+nmu1?
[21:41] <kees> nooo
[21:41] <slangasek> or 0.8.5+nmu0.1
[21:41] <slangasek> or 0.8.5-0.1
[21:41] <slangasek> or flog cr3 and make him stop using native version numbers
[21:42]  * kees likes the latter
[21:44] <mathiaz> kees: "flog cr3 and make him stop using native version numbers" ?
[21:45] <kees> mathiaz: yup.  there's rarely a reason to use native numbers.  he should release proper tar balls, and use -0ubuntuN package versions
[21:45] <mathiaz> kees: well - we've discussed this.
[21:46] <mathiaz> kees: he used to do that (release tarballs)
[21:46] <mathiaz> cr3: we should probably revisit that at the next UDS then
[21:50] <james_w> mathiaz, cr3: checkbox branches up to date
[21:50] <mathiaz> james_w: awesome - thanks
[21:52] <lifeless> james_w: is there a command to export a tarball from a bzr branch [with pristine-tar magic]
[21:52] <james_w> no
[21:53] <lifeless> ok. I think thats what I'm basically looking for
[21:53] <lifeless> I have use cases beyond debs
[21:53] <lifeless> which is perhaps why you've been answering diferent questions than I've thought I had been asking
[21:56] <siretart> james_w: if you have a free minute, you might want to review the imports for the devscripts package. I've just finished merging it with debian using bzr branches, but noticed that there are tons on conflicts, and most of them are spurious...
[21:57] <james_w> siretart: from sid?
[21:58] <siretart> it doesn't really matter if I merge the sid branch into the karmic one or the other way round
[21:59] <siretart> generally, merges seem easier if you merge the ubuntu branch into the debian one
[22:01] <Laney> semantically that's what you are doing, right?
[22:01] <james_w> yeah
[22:03] <james_w> siretart: it's because unfortunately the latest shared ancestor we have is ages old
[22:04] <james_w> we don't have a full debian history, and so in some cases there have been huge changes since we can last infer a merge
[22:04] <james_w> hang on, that's not quite right
[22:17] <mathiaz> kirkland: seems that your kvm backport is working well here
[22:17] <james_w> it's a bug that has been fixed in the meantime
[22:18] <mathiaz> kirkland: I'm able to perform a successfull install of a karmic guest using a qcow2 file via virtio on a hardy host
[22:18] <mathiaz> kirkland: which is failing with the version from hardy-backport
[22:25] <kirkland> mathiaz: \o/
[22:25] <kirkland> mathiaz: okay, please provide feedback in that bug
[22:25] <mathiaz> kirkland: commented in the bug
[22:25] <kirkland> mathiaz: that'll help get the uploads approved
[22:25] <kirkland> mathiaz: great
[22:25] <kirkland> mathiaz: sorry about that in the meantime
[22:26] <mathiaz> kirkland: now the question I have is: are there any side effects on other configuration?
[22:26] <mathiaz> kirkland: like raw+virtio
[22:26] <mathiaz> kirkland: or qcow2+ide
[22:26] <mathiaz> kirkland: or block device+virtio?
[22:26] <kirkland> mathiaz: good question; i'm not sure.  but this code is upstream
[22:26] <kirkland> mathiaz: and was released in RHEL5
[22:27] <mathiaz> kirkland: right - so IIUC the patch is against block-qcow2.c
[22:29] <mathiaz> kirkland: so it would only affect qcow2 files right?
[22:29] <mathiaz> kirkland: why would qcow2+virtio fail and not qcow2+ide?
[22:29] <kirkland> mathiaz: it should only affect qcow2+virtio
[22:30] <kirkland> mathiaz: the affected code is in the qcow2 block driver
[22:30] <mathiaz> kirkland: so qcow2+scsi uses a different block driver?
[22:30] <kirkland> mathiaz: http://paste.ubuntu.com/309969/
[22:30] <mathiaz> kirkland: so qcow2+*ide* uses a different block driver?
[22:31] <kirkland> mathiaz: qcow2 is one block driver
[22:31] <kirkland> mathiaz: raw is another
[22:32] <mathiaz> kirkland: ok - so why does virtio trigger the bug and not ide?
[22:32] <kirkland> mathiaz: ide, scsi, virtio are different interfaces
[22:32] <kirkland> mathiaz: i'm not exactly sure
[22:33] <mathiaz> kirkland: there's another comment added in the diff - probably related to the issue
[22:33] <mathiaz> kirkland: does that mean that IDE doesn't do multiple writes while virtio does?
[22:34] <kirkland> mathiaz: that sounds plausible; i don't know this code well enough to say for sure
[22:35] <kirkland> mathiaz: thanks for the reminder to fix this issue in this morning's meeting
[22:35] <kirkland> mathiaz: i had mostly forgotten about it
[22:35] <mathiaz> kirkland: np - that's what bug lists (and LP fwiw) are for :)
[22:37] <sgallagh> mathiaz: Sorry for the delay. We haven't officially decided what we're numbering the next release of SSSD. It's supposed to be a 1.0 release candidate. We might call it 0.8.0, 0.9.0 or 1.0.0rc (I'm leaning towards the latter)
[22:37] <mathiaz> sgallagh: ok thanks for the update. It's not that important for now. Just making sure the release number are working correclty for package upgrades.
[22:38] <mathiaz> sgallagh: so I'll use 0.8.0 and the version number could always be bumped for the final version
[22:38] <sgallagh> mathiaz: Thank you for reporting the build failure. I'll look into that first thing tomorrow
[22:38] <sgallagh> mathiaz: Yeah, I'm using 0.8.0 for our internal builds right now, with the same reasoning
[22:38] <mathiaz> sgallagh: great. Probably a linking issue
[22:39] <sgallagh> mathiaz: Yes, I suspect that the way we determine SELINUX_LIBS is probably coming up with the wrong set of flags on Ubuntu.