[00:00] <charlie-tca> no problem, skaet
[00:00] <charlie-tca> I just had to make sure we get the latest one to sync
[00:04] <skaet> :)
[00:20] <skaet> ubuntu desktop 20110921.2 posted
[00:22] <skaet> stgraber, am stepping away for dinner... (really this time),  edubuntu's currently on the builder so should emerge next.
[00:22]  * skaet --> dinner, biab
[00:27] <stgraber> skaet: ok
[01:01] <highvoltage> stgraber: didn't we also get a newer gbrainy?
[01:02] <highvoltage> or is that still in ubuntu by default? even if it's still included in ubuntu by default, it's not explicitely mentioned there so perhaps we should
[01:07] <highvoltage> (I updated the page)
[01:19] <skaet> stgraber, highvoltage  new edubuntu dvd (20110922) posted
[01:20] <ScottK> skaet: Thanks.
[01:20] <skaet> ScottK, kubuntu dvd's building now,  will be next out
[01:20] <ScottK> OK.
[01:21] <highvoltage> thanks skaet
[01:21] <skaet> :)
[01:22] <highvoltage> stgraber: can you bring those images that you downloaded to the office tomorrow? it will be faster for me to sync from them than from my old ones
[01:25] <charlie-tca> and the software center fixed worked. and the images are working
[01:26] <stgraber> highvoltage: sure, I'll have them both on my laptop in the next 10 minutes or so
[01:28] <stgraber> highvoltage: tech overview looks good, thanks for the changes
[01:33] <GrueMaster> skaet: Ubuntu-armel omap/omap4 testing is finished.  I'm leaving the ac100 to ogra and the mx5 to janimo.  Downloading kubuntu omap/omap4 images now, hope to post results in the next couple of hours (slow download).
[01:34] <skaet> GrueMaster,  ok.   There are about to be a new set of images for arm emerging from the builders.   Do you want me posting them?
[01:34] <GrueMaster> Ugh, why?
[01:34] <skaet> GrueMaster, ubiquity fixes.
[01:35] <skaet> just a sec.
[01:35] <GrueMaster> If the sole purpose is to be in sync, then no.  I didn't run into issues with this batch of images.  Or are these kubuntu images?
[01:36] <skaet> it was primarily for kubuntu,  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/855763
[01:36] <ubot4> Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 3) (dups: 1) (heat: 18)" [Critical,Fix released]
[01:36] <skaet> but there was another minor fix that was made at the same time
[01:37] <skaet> We don't have kubuntu arm images built with the fix,  but if you want them, I can add them to the queue.
[01:37] <GrueMaster> So, these images are kubuntu only?
[01:38] <skaet> images coming off are ubuntu right now (with kubuntu fix) for consistency.
[01:40] <skaet> infinity, NCommander - won't be updating the ARM images on the iso tracker based on GrueMaster comments ^^.
[01:40] <GrueMaster> Problem I am having is it is taking me hours to download each image respin, even with zsync.  If I have to test them, I will, but it will take a while.  No guarantees on getting them done before 9am PST (1500 UTC).
[01:41] <skaet> GrueMaster.  understood.  Will let NCommander and infinity voice an opinion if they disagree, otherwise we'll go with what you've tested.
[01:42] <GrueMaster> So, was kubuntu being respun with these fixes?
[01:43] <skaet> GrueMaster, no it wasn't.  ScottK didn't indicate it was needed,  but if your testing indicates it does.  let me know ASAP.
[01:43] <skaet> I'll be monitoring this channel and will start a spin off.
[01:43] <ScottK> GrueMaster: I'm willing to defer to your judgement (and availability to retest, so no one with omap/omap4 has appeared)
[01:44] <ScottK> GrueMaster: If the right answer is respin and release Kubuntu images late after you get a chance to test, I'm fine with that too.
[01:44] <GrueMaster> ScottK: I am still pulling down the images.  zsync was a bit behind on my side, and I'm currently looking at ~1-2 hours before I can test 20110921.
[01:45] <ScottK> OK.
[01:45] <skaet> ScottK, GrueMaster - once the ubuntu arm images come off the builder, I'll proactively start off a Kubuntu set, so the option will be there later tonight.
[01:46] <skaet> your choice or not, to pick it up.  ie. if sniff test yields problems pick up the latest, and get someone awake to post to iso tracker.
[01:46] <GrueMaster> skaet: Sounds good.  Can we keep all of these respins in reserve, just in case we don't need them?
[01:46] <skaet> exactly
[01:46] <GrueMaster> ok
[01:48] <skaet> ScottK,  kubuntu DVD 20110922 posted
[01:48] <ScottK> Thakns.
[01:48] <ScottK> Thanks even
[01:48] <skaet> :)
[02:55] <skaet> ubuntu dvd 20110922 posted
[03:11] <stgraber> 80% of the way through porting qapkgstatus (status.qa.ubuntu.com) to Drupal 7, the code is a lot cleaner, safer and faster :)
[03:12] <stgraber> once I'm done with that one I should be familiar enough with Drupal 7 to port the qatracker relatively easily (still expect it to take a week or so to actually do it)
[03:27] <GrueMaster> ScottK: Testing kubuntu now.  Had a failure on beaglexm (omap) and it seems to have recovered.  No failure on panda (omap4) so far.  May not need the respin.  Will let you know more details on beaglexm as soon as I can.
[03:28] <ScottK> Thanks.
[03:28] <GrueMaster> Beaglexm may be memory related as we apparently turned off making a swap file some time ago.  Could be hitting oom issues.
[03:52] <GrueMaster> As soon as I created a swap file on the beagleXM, the loadaverage started dropping from 4.95 (now around 2.08 and slowly dropping) and swap usage shot up to over 200M.
[03:57] <skaet> GrueMaster, ScottK,  I've started off the kubuntu arm rebuilds IF you need them.   Should be a couple of hours before they're available.
[03:58] <GrueMaster> Ok, this may be interesting.  The beagleXM oem-config crash on initial boot is the same as bug 855763, but I didn't see it in omap4.
[03:58] <ubot4> Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 3) (dups: 1) (heat: 18)" [Critical,Fix released] https://launchpad.net/bugs/855763
[03:58] <GrueMaster> Doublechecking logs on omap4 now.
[04:00] <skaet> GrueMaster, infinity, NCommander, ogra_  - the ubuntu arm pre-installed images are publishing now,  should be available IF you need them under 20110922.
[04:00] <GrueMaster> Nope, not seeing it on omap4, which is odd.
[04:01] <GrueMaster> skaet: Thanks.
[04:01] <GrueMaster> I don't think we will (and with current download speeds I am seeing, they wouldn't be available to me until well after midnight my time).
[04:02] <GrueMaster> As to kubuntu-armel, I don't know what to say.  On omap, I see the bug, on omap4 I don't.  I'll compare manifests to see if they match.
[04:03] <skaet> GrueMaster,  ok.  Sorry about the download speeds. :P
[04:03] <GrueMaster> Both match.  Not sure what to think now.
[04:04] <GrueMaster> Meh, not your fault.  When you have a popular product...
[04:04] <GrueMaster> :P
[04:05] <GrueMaster> Other than the results I have already posted, I haven't seen any other issues.
[04:09] <GrueMaster> On the kubuntu installer bug, I only saw it on beaglexm and it recovered without issue.  Didn't see it on omap4 (Panda).  I don't think a respin is necessary.
[04:10] <skaet> fair enough.   ok,  I think we have the image set we'll be going with on the iso tracker unless jibel raises some flags in the morning.
[04:11] <skaet> pitti,  when you get in, could you go ahead and pre-publish the current images?
[04:12] <skaet> pitti, do NOT update the iso tracker to the latest ARM (ubuntu and kubuntu pre-installed) images, looks like tonights builds of them won't be needed.
[04:12]  * skaet --> time to go do the zzz thing.
[04:12] <skaet> g'nite all.
[04:13] <GrueMaster> Night skaet.
[04:17] <pitti> Good morning
[04:17] <pitti> hey skaet
[04:17] <pitti> skaet: eek, we forgot to do that? doing right now then, we'll have to do a release very late then
[04:17] <pitti> skaet: arm images> understood
[04:19] <pitti> infinity: we have a script "publish-image-set.py" now which figures out all the commands for you, feeding from teh tracker
[04:26] <pitti> infinity: still awake by any chance?
[04:26] <pitti> there is a lubuntu 20110921.2 build, but tracker has 20110921.1
[04:27] <pitti> is that intended?
[04:28]  * pitti also runs cron.source now, it takes ages
[04:33] <pitti> infinity, skaet: images prepublished
[04:33] <pitti> now let the world mirror
[04:33] <stgraber> ok, finally got Drupal 7 to authenticate against LP and grant access rights on my local ISO tracker based on team membership! that's it for tonight, see you all tomorrow.
[04:33] <pitti> sleep well, stgraber
[05:21] <ScottK> GrueMaster: I get a crash in oem-config too (on i386).
[05:28] <ScottK> pitti: Kubuntu i386 alternate is out of date for ubiquity.  The impact is Bug #855763 is still present and so oem-config fails.  I don't think it's worth a respin, but that image won't have oem-config.
[05:28] <ubot4> Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 3) (dups: 1) (heat: 18)" [Critical,Fix released] https://launchpad.net/bugs/855763
[05:30] <pitti> ScottK: ok, so we'll release-note that this image won't have oem-config?
[05:30] <ScottK> Yes, unless there's some other reason to respin.
[06:28] <pitti> ScottK: at this point, do you still see anything in the Kubuntu images which might need a respin?
[06:30] <pitti> looks like edubuntu images didn't get any testing yet
[06:30] <pitti> so better not unfreeze just yet
[06:31] <pitti> s/unfreeze/flush the queue/
[06:31] <pitti> (I just learned we are going to stay frozen)
[06:43] <infinity> pitti: I didn't pre-publish earlier because there was still respinning going on, and then I had to go out. :/
[06:44] <pitti> infinity: ah, np; we'll just have to do the release a little later in the day
[06:45] <pitti> infinity: at some point today we need to decide when we are at the "point of no return" for flushing unapproved; I think due to untested edubuntu that we are at that point yet, but I hope we can get some tests today
[06:45] <pitti> we shouldn't flush unapproved on a friday
[06:45] <infinity> pitti: Friday's the best time to do everything!
[08:13] <pitti> I'm accepting cogl; it'll land in binNEW, so doesn't affect images
[08:13] <pitti> I want to get it built now, so that the other stuff in the queue can already build against it (see bug 856179)
[08:13] <ubot4> Launchpad bug 856179 in mutter (Ubuntu) (and 6 other projects) "[FFe] cogl 1.8.0 with soname bump (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/856179
[08:38] <pitti> jibel: bonjour
[08:38] <jibel> pitti, good morning
[08:38] <pitti> jibel: do you guys test edubuntu as well, or is that done by stgraber only?
[08:39] <pitti> jibel: apparently there was a late respin last night
[08:39] <jibel> pitti, stgraber does it, I can help after ubuntu.
[08:42] <pitti> jibel: wuold it help if I downloaded the kubuntu amd64 image and test that a bit (which will take a while), or is that part of your automatic setup anyway?
[08:42] <pitti> it has zero results right now, and thus I'm a little worried
[08:43] <jibel> pitti, that would help. We only test ubuntu automatically
[08:44] <jibel> I've a couple of bugs to file against ubuntu and I can start testing derivatives in half an hour or so.
[08:44] <pitti> jibel: ok, then how about you start with edubuntu after ubuntu, and I'll test kubuntu amd64 now
[08:45] <jibel> pitti, ok
[09:29] <pitti> ok, first kubuntu amd64 desktop install finished, looking good
[09:30]  * jibel starting edubuntu i386
[09:56] <pitti> infinity: still online or asleep?
[10:16] <pitti> ok, kubuntnu desktop amd64 5/7 pass; can't test wubi, haven't tested netbook
[10:16] <pitti> (although kvm also just has 768 pixels in height)
[10:19] <jibel> pitti, I'll try wubi and netbook after edubuntu. Kubuntu DVDs pass
[10:27] <jibel> edubuntu i386 + LTSP: pass
[10:29] <pitti> yay
[10:29] <jibel> stgraber, I fail at LTSP live, networl-manager tries to manage the secondary interface and shuts it down before the client connects.
[10:29] <jibel> *network
[10:30] <ScottK> pitti: As of when I went to sleep, I wasn't aware of any show stoppers for Kubuntu.
[10:30] <pitti> ScottK: ah, good; I just tested the amd64 desktop one, and it works just fine
[10:31] <ScottK> Great.
[10:31] <pitti> one nitpick is that oem-install mode doesn't install missing langpack
[10:31] <pitti> s
[10:31] <pitti> but that applies to ubuntu just as well, I figure
[10:33] <jibel> pitti, same on ubuntu.
[10:34] <jibel> and there's a problem with the language selector notification when a language is incomplete after installation too. I'll troubleshoot after B2.
[10:34] <pitti> cjwatson: so it seems our b2 images are as good as they are going to be
[10:35] <pitti> jibel ^ any remaining major bugs which have a chance of being fixed?
[10:35] <cjwatson> I'll take your word for it - I've been somewhat out of it this milestone cycle (illness + ADSL problems)
[10:35] <pitti> uh, get well soon then!
[10:36] <pitti> (both you personally and your interweb tube)
[10:36] <pitti> cjwatson: I'm a bit anxious to review/clean unapproved, there's quite some fixes there, and I wouldn't want to flush the whole thing on a Friday
[10:36] <ScottK> I think it would be good for someone to check and see if Bug 856055 is just me/my system or a general problem.
[10:36] <ubot4> Launchpad bug 856055 in memtest86+ (Ubuntu) "Memtest run from DI installer menu never finishes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/856055
[10:36] <pitti> and it requires some coordination for the cogl binNEW
[10:37] <ScottK> pitti: We've got one more week between Beta 2 and final this time, so no rush.
[10:37] <cjwatson> the engineer reckons ADSL is fixed now (and it does look better), and I think the cold is subsiding too
[10:37] <cjwatson> pitti: I can certainly help with unapproved today
[10:37] <cjwatson> ScottK: ok
[10:38] <pitti> I missed last week's meeting due to holiday, but I understand that we'll remain frozen for the whole remaining oneiric time?
[10:38] <cjwatson> so I understand
[10:38] <pitti> that's going to be a lot of handholding, but oh well
[10:39] <ScottK> We are.
[10:39] <pitti> ScottK: I suppose that shouldn't be different between u/kubuntu? I can test the current memtest on my 10v here
[10:39] <ScottK> pitti: It'd be really odd if it were different.
[10:39] <jibel> pitti, no major bug that could be fixed and tested in the next hours.
[10:39] <ScottK> I'd be curious how long it takes to run if it does.
[10:40] <pitti> erk, confirmed; no progress at all
[10:40] <ScottK> OK.
[10:40] <ScottK> That's probably worth a release note.
[10:40] <pitti> I'll try on my workstation, brg
[10:40] <pitti> brb even
[10:42] <ScottK> Looks like amd64+mac testing is minimal this time.
[10:42] <ScottK> (for multiple flavors)
[10:43] <pitti> ScottK: works fine on my X201
[10:43] <cjwatson> works in KVM
[10:43] <pitti> so we can representatively claim that it is broken on 33% of systems out there :-P
[10:43] <ScottK> OK.  Hardware specific then.
[10:44] <pitti> oh, "Informations"? must have been a German who wrote this :)
[10:44] <pitti> although I've heard it from other people as well
[10:44] <ogra_> hmm, so oem-config doesnt get removed after install
[10:44] <pitti> you and your weird singular forms!
[10:45] <ogra_> Sep 22 12:20:32 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
[10:45] <ogra_> hmm, i guess thats the issue
[10:45] <ogra_> everything else in the log looks fine
[10:46] <pitti> ScottK: release ntoed
[10:46] <ScottK> Thanks.
[10:48] <pitti> ogra_: in my recent kubuntu desktop oem install mode that worked, neither oem-config nor ubiquity are installed
[10:48] <jibel> ogra_, similar symptoms then bug 349469
[10:48] <ubot4> Launchpad bug 349469 in debconf (Ubuntu) "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable (affects: 523) (dups: 396) (heat: 3404)" [Medium,Triaged] https://launchpad.net/bugs/349469
[10:48] <ogra_> pitti, well, 820514
[10:48] <ogra_> bug 820514 even
[10:48] <ubot4> Launchpad bug 820514 in ubiquity (Ubuntu Oneiric) (and 1 other project) "oem-config-remove-gtk not found during preinstalled desktop initialization (affects: 1) (dups: 1) (heat: 18)" [High,Incomplete] https://launchpad.net/bugs/820514
[10:48] <ogra_> but that doesnt seem to be actually my issue
[10:51] <ogra_> pitti, your bug talks about people using two package managers at the same time ... i dont even have access to a package manager in ubiquity-dm :)
[10:51] <ogra_> thats an ubiquity homemade issue i think
[10:51] <pitti> "my" bug?
[10:51] <ogra_> 349469
[10:51] <ogra_> oh, sorry, that was jibel
[10:51] <pitti> ah
[10:52] <cjwatson> jibel: please don't do "similar symptoms" with that class of bug
[10:52] <cjwatson> it's not worthwhile and is confusing
[10:53] <cjwatson> because the symptom is "two things tried to talk to debconf at once", and that doesn't come anywhere close to uniquely identifying a cause
[11:00] <jibel> cjwatson, understood.
[11:03]  * ogra_ files bug 856293
[11:03] <ubot4> Launchpad bug 856293 in ubiquity (Ubuntu Oneiric) (and 1 other project) "oem-config not removed after install on preinstalled desktop images due to debconf.dat being locked (affects: 1) (heat: 6)" [Medium,New] https://launchpad.net/bugs/856293
[11:57] <jibel> wubi is broken on kubuntu. filing a bug.
[12:01] <ScottK> Except for desktop amd64+mac, I'm pretty comfortable with where Kubuntu is.
[12:15] <pitti> edubuntu seems fine, too
[12:15] <pitti> and ubuntu
[12:16] <pitti> xubuntu almost complete, mythbuntu has a successful test, lubuntu complete
[12:16] <pitti> I think we can call these "beta-2" and start reviewing unapproved to unblock further development
[12:16] <pitti> cjwatson, ScottK, jibel ^ any objection?
[12:16] <ogra_> arme seems fine as well
[12:17] <ogra_> *arm even
[12:17] <pitti> ogra_: is the oem-config removal bug a race condition, or reproducible? if so, should we release-note it?
[12:18] <ogra_> pitti, we could, it happened every time i tested ac100 but i dont have any debug data
[12:18] <ogra_> apart from that one debconf.dat line there is nothing in the logs
[12:19] <pitti> ogra_: does the installed system actually work? I suspect it breaks late enough that the only effect is the extra packages
[12:19] <ogra_> right, i even guess apt-get autoremove would wipe them
[12:19] <cjwatson> I don't see anything on the iso.qa bug list that I consider a showstopper
[12:20] <cjwatson> so no objection from me
[12:20] <pitti> ok; I'll start with some "safe" ones, just in case
[12:20] <pitti> like clutter, which is only on xubuntu, and not being used for anything but quadrapassel (the game)
[12:20] <ogra_> oh, i think mx5 shouldnt be released, that waits for a missing kernel config option
[12:21] <ogra_> (working fine beyond that, but not supporting ext4 when the images default to it is somewhat a showstopper :) )
[12:21] <pitti> heh
[12:21] <pitti> ogra_: ok, I'll remove it from the tracker then?
[12:21] <pitti> so that publish-image-set doesn't pick it up?
[12:21] <ogra_> ah, i thought it need to be on the tracker
[12:22] <ogra_> i exoplicitly asked jani to add it, if publish-örelease depends on it though, yeah, remove it
[12:22] <pitti> cjwatson: FYI, please keep apt in the queue for now; I accepted pkgbinarymangler which blacklists libapt's translations, that should publish first
[12:23] <pitti> ogra_: not "depend", it'll just publish everything which isn't disabled in the tracker
[12:23] <ogra_> ah
[12:23] <pitti> ERROR: Cannot handle image Ubuntu Core armel (20110920.1)
[12:23] <pitti> oops, I guess that needs fixing, too
[12:24] <ogra_> hmm, i thought adam had added that last milestone
[12:25] <cjwatson> pitti: OK
[12:25] <pitti> fixed in ubuntu-archive-tools
[12:25] <cjwatson> pitti: I asked for that apt upload so I do want it fairly soon mind :-)
[12:25] <pitti> cjwatson: if it's urgent, we can also do another rebuild after wards
[12:26] <ogra_> pitti, where do i find ubuntu-archive-tools (for the next time we add a new image format) ? is that publically accessible fro non ubuntu-archive people ?
[12:26] <cjwatson> nah, xdeb isn't release-critical in any sense
[12:26] <cjwatson> ogra_: bzr co lp:ubuntu-archive-tools
[12:26] <ogra_> thx !
[12:26]  * ogra_ suspects it will not know about .bootimg files yet
[12:29] <ogra_> ah, it doesnt look at file suffixes at all
[12:42] <cjwatson> pitti: are we holding off on kerneloops for a bit?
[12:42] <pitti> cjwatson: disabling it seems a little premature to me
[12:42] <cjwatson> right
[12:42] <pitti> not sure whether the kernel team actually wants to have it stopped already, apw?
[12:42] <pitti> ogasawara: ^
[12:51] <pitti> ok, 'nuff staring at diffs for nwo
[12:51] <pitti> I accepted everything which I trust enough to not break another image build
[12:51] <cjwatson> I'm still going, I'll deal with the rest
[12:51] <pitti> also, I want pkgbinarymanger and vala-0.14 to publish first
[12:51] <cjwatson> ah, heh, I did accept a couple of vala packages ...
[12:51] <pitti> there are some valaish things in the queue which I'd rather build against the current one, just to ensure that they don't ftbfs or so
[12:52]  * cjwatson will avoid those for a while then
[12:52] <pitti> cjwatson: ok; no worries, it didn't change syntax or abi or anythign, it was just being cautious
[12:52] <cjwatson> gnome-games and libgee
[12:53] <cjwatson> yeah, probably best leave most of the rest for now then
[12:53] <cjwatson> the buildds have plenty to chew on
[12:54] <pitti> heh, was just gonna say
[12:55]  * pitti takes a break, lawn needs mowing, and seems we are finally out of catastrophes \o/
[12:55] <cjwatson> actually I think I'll accept binutils too: it looks safe, fixes build failures, and shouldn't break anything if skewed
[12:55] <pitti> cjwatson, infinity, skaet: FYI, my cron.source run finished, so that will be fine for publishing
[12:56] <stgraber> jibel: hmm, that's ltsp live from Edubuntu's DVD?
[12:57] <cjwatson> pitti: good
[12:58] <jibel> stgraber, yes, full installation + ltsp passed with the same network setup.
[12:59] <stgraber> jibel: that's really weird that network manager even tries to touch the interface post-install as the installer generates a /etc/network/interfaces entry for it
[13:00] <stgraber> jibel: oh, ok, I see, post-install is fine but not live
[13:00] <stgraber> jibel: let me try it here quickly, I didn't see any problem yesterday...
[13:00] <jibel> stgraber, yes post-install is fine but not live
[13:04] <ogasawara> cjwatson, pitti: precedence in previous releases indicated we've turned off kerneloops around beta-2 so I told bdmurray to go ahead and disable it
[13:05] <Laney> charlie-tca: I guess bug #836324 is a P-thing now?
[13:05] <ubot4> Launchpad bug 836324 in blueman (Ubuntu) "FFe: Sync blueman 1.22~bzr707-1 (universe) from Debian experimental (main) (affects: 1) (heat: 17)" [Wishlist,New] https://launchpad.net/bugs/836324
[13:05] <ScottK> pitti: Sounds fine.
[13:07] <stgraber> jibel: LTSP live seems fine here. An "LTSP" connection gets added and set to the interface selected in the LTSP live dialog, once the dialog disappears I can boot a thin client just fine.
[13:08] <stgraber> jibel: Just checking, did you use the LTSP live configuration dialog (from the launcher) and selected the right network interface (eth1 in my case), then waited for it to disappear? at this point Network Manager should be happy with both interfaces connected...
[13:08] <stgraber> jibel: unless you're testing on real hardware with a crossover cable, then Network Manager won't like the interface link state changing 10 times during the thin client boot
[13:13] <jibel> stgraber, I used the LTSP live from the launcher but the dialog never disappeared. When I select eth1 (which is the internal NIC) it changes back to eth0. I'm trying again.
[13:14] <stgraber> jibel: oh, that's weird. How much RAM do you have on that system?
[13:15] <jibel> stgraber, 1G, what's the minimum requirement ?
[13:16] <stgraber> jibel: with LTSP, usally 768M though we recommend 1G so you should be fine
[13:17] <charlie-tca> Laney: why? we can't do an FFe now?
[13:18] <Laney> You want to change defaults this late? Also, no progress on the requested testing.
[13:19] <charlie-tca> We may have to change defaults this late, since at this late date, Xubuntu has no bluetooth
[13:20] <Laney> well, consider this a poke then :-)
[13:20] <charlie-tca> Thank you. I do appreciate that.
[13:33] <ogasawara> cjwatson, pitti: after chatting with bdmurray I'm fine if we hold off on disabling kerneloops until around final freeze
[13:33] <ScottK> Laney: Did you request the monodevelop-* syncs?
[13:34] <Laney> not me guv'nor
[13:34] <Laney> probably directhex
[13:34] <ogasawara> cjwatson, pitti: I assume it can just be held in the queue or bdmurray can re-upload
[13:34] <ScottK> Ah, no.
[13:34] <Laney> but I think we want them. Is there a problem?
[13:34] <ScottK> Yeah.  It was.
[13:34] <ScottK> Do they need an FFe?
[13:34] <Laney> nafaik
[13:34] <ScottK> Something like 2.6-1 sounds like a new feature release, but OK.
[13:34] <cjwatson> ogasawara: holding in the queue should be fine
[13:34] <ScottK> Just checking.
[13:35] <Laney> I think we had the prereleases before
[13:35] <ScottK> Accepting based on "Laney said so."
[13:35] <Laney> yeah, 2.5.92 — should be bug fixes then
[13:36] <Laney> ta
[13:36] <ScottK> OK.  Done.
[13:36] <ScottK> pitti: The LO update looks non-trivial, so if it's going in, I think sooner better than later (and no, that doesn't mean I'm volunteering to review it).
[13:52] <pitti> ScottK: yes, I agree; I just didn't want to block the buildds with it just yet
[13:52] <pitti> ogasawara: understood, thanks
[13:52] <ScottK> OK.  Makes sense.
[14:05] <ScottK> BTW, I have a tester lined up for Kubuntu amd64+mac, so we may get to release those.
[14:05] <ScottK> powerpc has no tester ATM, so that's a no go for us.
[14:06] <pitti> hello skaet, good morning
[14:09] <skaet> good morning pitti.   :)
[14:21] <pitti> skaet: so, images look fine, and we started flushing unapproved
[14:23] <skaet> yup, spotted that surge.
[14:45] <pitti> skaet: so, bug 856405 might require some further explanation
[14:45] <ubot4> Launchpad bug 856405 in ubuntu-meta (Ubuntu Oneiric) (and 1 other project) "Add Ubuntu One packages back to default install and CD (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/856405
[14:46] <pitti> skaet: I'd like to do the seed changes now and upload -meta, so that these packages will be on tomorrow's CDs again
[14:46] <chrisccoulson> pitti - gnome-settings-daemon uploaded :)
[14:46]  * chrisccoulson waves goodbye to several seconds of startup time :)
[14:46] <pitti> skaet: in short, there was some back and forth with the U1 team, and they tried to introduce the concept of the u1-installer
[14:46] <pitti> skaet: but all it does is to just install the very packages that we have shipped in natty and before
[14:47] <pitti> skaet: so we don't have these in the default install and in the live session for testing them, for no good reason
[14:47] <pitti> skaet: so we had a phone call last week to clarify what the purpose of these was, and it turned out that it was something between mis-communication, the installer concept not being finished yet, and us wanting them back
[14:48] <pitti> skaet: I was part of the call and have argued for putting them back for weeks, so I feel too biased to making the call now
[14:49] <ScottK> Seems to me like they should either go back right now or not at all.
[14:49] <pitti> yes, that was my thought
[14:49] <pitti> was too late for b2 unfortunately
[14:49] <Laney> ho boy
[14:50] <pitti> but many people (including desktop team) have htese packages installed all the time anyway
[14:50] <Laney> do we revert the disabling U1 patches?
[14:50] <pitti> Laney: what do you mean?
[14:50] <Laney> for example the banshee extension was on the CD by virtue of a recommends
[14:50] <ScottK> I'm not unbiased either as I think integration of proprietary web services isn't appropriate for the default install (I lost that argument long ago), so I'm not one to express an opinion for either way either.
[14:51] <pitti> Laney: it'll be put back through seeds; does anything need to be patched for this? that'd be strange
[14:51] <pitti> as software should certainly work with the package being installed right now, too
[14:51] <Laney> no, seeding will work
[14:52] <Laney> why would you do that rather than having banshee recommend it again though?
[14:52] <pitti> Laney: doesn't matter much, but explicit seeding seems cleaner to me
[14:52] <pitti> also, it avoids having to change packages for this
[14:53] <pitti> also, makes it easier for derivatives to not ship it, etc.
[14:53] <pitti> (cf. ScottK's argument above)
[14:54] <pitti> Laney: so by "patch" you meant the Recommends: removal, not source patch?
[14:54] <Laney> yeah, "change", whatever you want to call it
[14:54] <pitti> ah, ok
[14:55] <skaet> pitti, sorry for the pause,  am checking some things.
[14:58] <stgraber> skaet: Edubuntu looks good to go. Only bug that was found is a ltsp-live problem that jibel found, can't reproduce it for now, will start poking at it now.
[15:06] <Laney> looks like some U1 stuff was re-seeded a few days ago anyway?
[15:06] <skaet> pitti,  agree with you and ScottK,  if its going to go in,  best now.    What will this do to the image space?  (ie. what's going to drop off?)
[15:06] <pitti> skaet: nothing; it's 360 kB
[15:07] <skaet> pitti,  goodness.
[15:07] <pitti> skaet: would you mind sending your formal +1 to the bug, so that we have a paper trail? I just sent my view of the regression potential, etc.
[15:07] <Laney> or supported-desktop-extra is just to keep stuff in main?
[15:07] <skaet> pitti,  will do.
[15:07] <pitti> skaet: that's what I meant with "there was no reason to drop them" :)
[15:07] <pitti> Laney: righht
[15:08] <pitti> Laney: I'll drop it from there again, for cleaning up the redundancy
[15:08] <Laney> ack
[15:09] <Laney> I'm a bit surprised that there was a miscommunication though; the intention seemed quite clear
[15:10] <skaet> pitti, which seeds will be getting the change?  (CD, DVD, ...)  is it going to go on the ARM ones?
[15:11] <pitti> skaet: it's "desktop", so all ubuntu ones: desktop, alternate, preinstalled, DVD
[15:11] <pitti> skaet: doesn't affect any of the derivatives, they have their own seed
[15:11] <skaet> pitti,  ok, just wanted to check if it was going to be consistently applied, so am fine.
[15:19] <ScottK> dnspython and iotop have an FFe that needs review/approval: Bug #856478
[15:19] <ubot4> Launchpad bug 856478 in iotop (Ubuntu) (and 1 other project) "FFe: Let's get python-support off of ScottK's server (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/856478
[15:19] <pitti> ScottK: just accepted
[15:19] <pitti> erm, approved
[15:19] <ScottK> Cool.
[15:19]  * pitti likes the bug title
[15:20] <ScottK> python-central is already gone.
[15:29] <skaet> pitti,  comments added.
[15:30] <pitti> skaet: ah, thanks; -meta uploaded now
[15:43] <pitti> skaet: will we have a meeting tomorrow?
[15:43] <ogra_> oh, gooood question :)
[15:44] <pitti> (not that I'm pushing for one, I'll have a holiday)
[15:44] <skaet> pitti,  yes there will be a meeting tomorrow.
[15:45]  * skaet started on the agenda for it yesterday.  
[15:45] <skaet> pitti,  who's rep from desktop then?
[15:46] <pitti> skaet: seb128 kindly stepped up for questions, etc.
[15:46] <pitti> skaet: I updated https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus with the report, RC bugs, etc.
[15:47] <skaet> pitti,  could you take a pass at the desktop bugs in http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-o-tracking-bugs.html,  and make sure you agree that those listed under the desktop team make sense to be.   I'll cross check with your DesktopTeam/ReleaseStatus later, after the release is out.
[15:48] <skaet> also,  check you agree with the priorities on the desktop ones too.
[15:48] <pitti> skaet: I did actually, most of them are mentioned on our report page
[15:48] <skaet> pitti,  :)  goodness.
[15:49] <skaet> thank you.
[16:11] <Daviey> slangasek: Hmm. Just seen your qemu question..  Are you still planning to do it for qemu-linaro?
[16:11] <slangasek> Daviey: well, I may have mentioned earlier that I was hoping to piggy-back onto your FFe so I didn't have to do the paperwork ;)
[16:11] <Daviey> Whilst the testing proved that it was a viable candidate, we really don't have the time to dedicate to fixing to fallout if it goes bang.
[16:11] <Daviey> For something so core to the server product.
[16:12] <slangasek> I think an update for qemu-linaro would be the best course of action, but I'm not sure we get enough benefit for me to justify going through a proper FFe
[16:12] <Daviey> slangasek: so myself and hallyn did use it from a PPA for over a week, and it did look good.
[16:13] <Daviey> Nothing obviously regressed.
[16:13] <slangasek> Daviey: does that mean if I proposed a qemu-linaro new upstream version for FFe, you would approve it with your ubuntu-release hat on without me going through the upstream changelog?
[16:14] <ScottK> Suddenly the downside of being on the release team emerges ...
[16:14] <ScottK> ;-)
[16:15] <slangasek> well :)
[16:15] <slangasek> he doesn't need to sell *me* on the update, after all :)
[16:15] <ScottK> No, I was thinking for him.
[16:15] <ScottK> Now he's got to sit there and make a decision ...
[16:16] <infinity> Decisions before noon are hard.
[16:17] <Daviey> slangasek: I did go through the changelog, and there are a few nice new features.
[16:17] <Daviey> One reason i was keen for us to consier it - is that t is most likely the release for the LTS.. whilst it's bad karma to test drive it in a release, for server LTS, it would have been useful.

[16:19] <Daviey> It's had very little exposure in Debian, with rc2 still in experimental and nothing in Sid.. didn't hep confidence.
[16:20] <Daviey> hallyn, our qemu guru wouldn't have been able to dedicate time to fixing an explosion.
[16:20] <Daviey> ... not to mention, everything is broken enough already :)
[16:20] <slangasek> sure, I understand
[16:20] <slangasek> but for qemu-linaro, what do you think?
[16:21] <Daviey> slangasek: I don't think that is a bad idea, really.  I don't know that people use qemu-linaro for anything other than experimetal stuff, do they?
[16:21] <slangasek> it's used for all the arm emulation people are doing
[16:21] <Daviey> As in, is it at the core of anyones deployment?
[16:22] <slangasek> certainly not "experimental" - but probably development-only
[16:22] <Daviey> Yeah.. That sounds like a reasonable target audience to through something less tested, than the rest of it.
[16:22] <Daviey> Perhaps i'm being maverick.
[16:24] <Daviey> slangasek: I wish there was a 'decent' qemu-system-arm machine, something with plenty of RAM.
[16:25] <Daviey> Using it during this cycle, all the options seemed to be balancing fail.
[16:25] <slangasek> I personally only use it in user emulation mode
[16:25] <slangasek> because the system emulation overhead is irrelevant for my needs
[16:25]  * Daviey continues going OT, and asks if upstart works with tat now.
[16:26] <slangasek> no idea
[16:26] <cjwatson> speaking of late updates, what do people think about a significant xdeb update?
[16:27] <cjwatson> http://paste.ubuntu.com/695191/ so far
[16:27] <cjwatson> I haven't actually checked but I have a rather strong suspicion that it's basically busted in oneiric right now anyway
[16:27] <cjwatson> and AFAIK it's only used by a small community of people working on cross-building, who want to be current anyway
[16:30] <slangasek> cjwatson: yeah, I think xdeb is an easy decision on that basis
[16:31] <Daviey> cjwatson: universe and popcon is reporting 153 installs.
[16:31] <slangasek> if the new version works for the 4 people using it, we should take that one :)
[16:31] <stgraber> Daviey: you mean running upstart using qemu's userspace emulation?
[16:31] <stgraber> Daviey: if so, it doesn't and very likely won't for quite a while still
[16:31] <cjwatson> Daviey: boggle
[16:31] <cjwatson> that's 149 more than I expected
[16:31] <Daviey> stgraber: tah
[16:32] <stgraber> Daviey: that's because upstart uses ptrace() to follow the forks of the process and qemu-arm uses ptrace to catch the syscalls made by the binaries you're running
[16:32] <Daviey> cjwatson: That is probably GrueMaster turn-and-burning fresh installs 145 times. :)
[16:32] <stgraber> Daviey: and you can't ptrace something twice, so upstart fails
[16:32] <cjwatson> Daviey: ... with xdeb?
[16:32] <cjwatson> that would be astonishing
[16:32] <stgraber> Daviey: though one hack I've done that works relatively well is to run an x86 upstart in an ARM container and then have everything else being armel
[16:33] <slangasek> cjwatson: 150 machines sitting at TI that they don't know are phoning home? :)
[16:33] <Daviey> That popcon is based on ALL, so goes back to Maverick.
[16:34]  * GrueMaster hears his name
[16:34] <stgraber> slangasek: btw, any plan on making libnih multi-arch? :) that'd make it a lot easier to run armel containers on x86 (as we can then simply install upstart:amd64 in the container and be done with it)
[16:35] <stgraber> (not that I actually need that, I have arm boards where I can run actual arm containers, but would probably be fun to have for some people)
[16:35] <slangasek> stgraber: why do you need it multiarched to install upstart:amd64?  Can't you just install upstart:amd64 + libnih:amd64?
[16:35] <slangasek> (no, no plans currently)
[16:36] <slangasek> ah, ureadahead and mountall also need it; is that the issue?
[16:36] <stgraber> slangasek: yep, that'd be the issue
[16:36] <stgraber> though I guess I could use the x86 version of these as well, but the goal is to have as little of these as possible...
[16:39] <slangasek> stgraber: well, then you get into plymouth depending on mountall, and, and...
[16:39] <slangasek> so yeah, libnih ought to get multiarched
[16:39] <slangasek> feel free :)
[16:49] <skaet> ScottL,  what's the status on the testing of Ubuntu Studio Alternate?   do we know the images are good?
[16:50] <skaet> stgraber,  does Edubuntu upgrade ok?
[16:56] <pitti> good night everyone!
[16:56] <pitti> good luck with the rest of the release
[16:57] <skaet> thanks for your help pitti.   good night.
[17:00] <charlie-tca> skaet: I tested studio 64, then the tracker updated, but the image had not changed.
[17:01] <charlie-tca> updating tracker for it
[17:01] <skaet> charlie-tca, if image didn't change we shouldn't have lost results.  weird.    Ok,  thanksfor confirming its ok.  :)
[17:02] <charlie-tca> I agree. But at least the 64bit image worked
[17:06] <skaet> :)
[17:13] <Laney> I'd like to approve bug 856579; would anyone mind reviewing in binNEW?
[17:13] <ubot4> Launchpad bug 856579 in banshee-community-extensions (Ubuntu) "[FFe] Merge banshee-community-extensions 2.2.0-1 from Debian Unstable (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/856579
[17:14] <Laney> (new packages from Debian)
[17:34] <Laney> ScottK: ^ since you offered (for unapproved, but ...) :-)
[17:37] <ScottK> Laney: If it's just bug fixes, it doesn't need FFe.
[17:38] <Laney> it adds new packages
[17:38] <ScottK> Oh
[17:38]  * ScottK reads again
[17:38] <Laney> I want to ack it, just need someone for NEWing
[17:38] <ScottK> Yeah.  That's fine.
[17:39] <Laney> ty
[17:52] <ogra_> did anyone else get 4 mails for each upload that was released from the queue or is my evo wonky ?
[17:52] <ogra_> (mails to -changes i mean)
[17:59] <stgraber> skaet: not sure someone actually tested upgrades. I can start one in a VM now though.
[18:00] <skaet> stgraber,  thanks.
[18:02] <slangasek> is this changed recommends in deja-dup expected / approved?
[18:02] <slangasek> (components-mismatches)
[18:48] <stgraber> skaet: ETA for upgrade testing is at > 3 hours (takes a while to grab the images, then upgrade, then dist-upgrade). Will report in the tracker anyway.
[18:48] <skaet> stgraber,  ok,  we'll update the release notes if there are issues after.
[19:03] <Daviey> Desktop has no known-issues?
[19:16] <ScottK> kde-baseapps is mine ^^^, so I'd appreciate if someone else could review/approved.
[19:25] <skaet> Daviey,  pitti didn't add any, but I agree there are some that need mentioning.   I'll be adding those after jibel finishes his edits.
[19:29] <jibel> skaet, done
[19:31] <skaet> jibel thanks.
[19:31] <charlie-tca> skaet: studio does install; ran encrypted LVM, now doing entire disk
[19:32] <skaet> charlie-tca,  ScottL owes you several beverages of your choice.
[19:32] <jibel> skaet, for desktop there is bug 832603, bug 852012, bug 854124
[19:32] <charlie-tca> Yeah, maybe. Sometimes help is good
[19:32] <ubot4> Launchpad bug 832603 in gnome-settings-daemon (Ubuntu Oneiric) (and 2 other projects) "gnome-settings-daemon crashed with SIGSEGV in g_simple_async_result_complete() (affects: 641) (dups: 88) (heat: 2980)" [Critical,Triaged] https://launchpad.net/bugs/832603
[19:32] <ubot4> Launchpad bug 852012 in unity-2d (Ubuntu Oneiric) (and 2 other projects) "unity-2d-panel assert failure: *** glibc detected *** unity-2d-panel: corrupted double-linked list: 0x094bc9b0 *** (affects: 21) (dups: 21) (heat: 178)" [Critical,Triaged] https://launchpad.net/bugs/852012
[19:32] <ubot4> Launchpad bug 854124 in glib2.0 (Ubuntu Oneiric) (and 2 other projects) "opening the system settings preferred application dialog breaks the defaults (affects: 2) (dups: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/854124
[19:33] <skaet> jibel,  ack.  There are some critical DX ones I'll probably add as well.
[19:37] <jibel> skaet, if you go this way its worth mentioning the windows stacking issue in unity (bug 805087) and bug 850320
[19:37] <ubot4> Launchpad bug 805087 in unity (Ubuntu Oneiric) (and 2 other projects) "Dash and launcher appear underneath windows (affects: 91) (dups: 21) (heat: 430)" [Critical,Fix committed] https://launchpad.net/bugs/805087
[19:37] <ubot4> Launchpad bug 850320 in unity-2d (Ubuntu Oneiric) (and 2 other projects) "bad memory leak in unity-2d-panel (affects: 5) (dups: 1) (heat: 28)" [Critical,Fix released] https://launchpad.net/bugs/850320
[20:11] <doko> accepted glance. one more step for the MIR
[21:33] <Daviey> can a AA please promote glance, based on bug 801299
[21:33] <ubot4> Launchpad bug 801299 in glance (Ubuntu) "[MIR]glance (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/801299
[21:33] <Daviey> hanks
[21:33] <Daviey> thanks
[22:04] <ScottK> skaet: If we can save the Kubuntu amd64+mac image, I have someone who may test it.
[22:04] <skaet> infinity, jibel, ^^
[22:08] <infinity> ScottK: Oh, I may have published it anyway... I didn't even notice the 1 missing test.
[22:17] <skaet> ScottK, infinity,  it is published.
[22:31] <ScottK> amd64+mac desktop got ~no testing for Ubuntu or Kubuntu.
[22:31] <ScottK> I don't think we should be publishing then.
[22:31] <ScottK> then/them
[22:31] <ScottK> Oh, wait.
[22:31] <skaet> ScottK,  amd64+mac got testing for Ubuntu
[22:32] <ScottK> Kubuntu did too since I last looked
[22:32] <skaet> heh, that's ok then.
[22:32] <ScottK> skaet: Nevermind. I think both Kubuntu and Ubuntu are OK to go.
[22:32] <ScottK> Yes.
[22:32] <ScottK> Sorry for the confusion.
[22:59] <slangasek> infinity: where do the package lists for the preinstalled desktop images live?  (bug #820514)
[22:59] <ubot4> Launchpad bug 820514 in ubiquity (Ubuntu Oneiric) (and 1 other project) "oem-config-remove-gtk not found during preinstalled desktop initialization (affects: 1) (dups: 1) (heat: 18)" [High,Incomplete] https://launchpad.net/bugs/820514
[22:59] <slangasek> skaet: hurrah!
[23:00] <charlie-tca> Thank you for all your time, skaet
[23:01] <skaet> Thank you all!   Team effort indeed.  :)
[23:01] <charlie-tca> Should also say thank you greatly to the rest of these people, too!
[23:02] <charlie-tca> All your hard work is appreciated!
[23:05] <skaet> Thanks to infinity who got all the bits out the door, welcome back to the release team!    :)
[23:12] <ScottK> doko: ^^^ should fix python-omniorb.
[23:14] <infinity> slangasek: Same place as everyone else's?
[23:14] <slangasek> infinity: which is the seed being used?
[23:16] <infinity> I think it's the same as everyone else now.  But let me double-check that.
[23:18] <infinity> slangasek: Yeah, it's just ubuntu-live.
[23:18] <infinity> Or, should be. :P
[23:19] <infinity> slangasek: Stopped forking long ago.
[23:21] <infinity> slangasek: We bring in oem-config via jasper.  But I'm not sure I agree with the assessment that oem-config should be blindly trying to run oem-config-remove-gtk just 'cause some other GTK package exists. :P
[23:23] <slangasek> infinity: excellent!  You disagree, you can follow up on the bug instead of it remaining incomplete indefinitely :-)
[23:23] <infinity> If by "follow up", you mean "reassign to ubiquity", you bet!
[23:24] <slangasek> well, as long as it's not hanging in incomplete :)
[23:27] <infinity> We need a "very complete" status.
[23:28] <charlie-tca> Isn't that "Triaged"?
[23:28] <infinity> "So confirmed, that I just broke something unrelated."