[00:28] <SudoKing> :)
[01:19] <skaet> ubuntu desktop ( amd64, amd64+mac, i386, powerpc) posted - 20110412 image
[01:35] <doko> lamont: still http://people.canonical.com/~doko/tmp/fpc-armel-mav-stage2/ from Sep 2010
[01:43] <skaet>  Riddell, ScottK - kubuntu desktop (amd64, amd64+mac, i386, powerpc) posted - 20110413 image
[02:05] <skaet> ogra_, GrueMaster,  ubuntu netbook pre-installed (omap3, omap4) posted - 20110413 image
[02:33] <skaet> Riddell, ScottK,  kubuntu-mobile daily-live (i386) posted
[02:38] <skaet> slangasek, around?
[02:39] <skaet> looks like there's been some failures with xubuntu, mythbuntu on the desktop images.
[02:40] <skaet> after the dvd's finish, I'll try kicking them off again to see what's happening.   Haven't seen any error messages though.   Is there som log location I can look?
[02:41] <skaet> also,  doesn't look like the alternates have triggered....hmm...
[02:45] <charlie-tca> I got an email earlier about a file lock causing a fail to build
[02:46] <charlie-tca> but I deleted it already
[02:49] <charlie-tca> skaet: I don't know if this helps, but this is where cjwatson has me look when I tell him by images did not build
[02:49] <charlie-tca> http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/natty/daily-live-20110413.log
[02:49] <skaet> thanks charlie-tca
[02:49]  * skaet looking
[02:49] <charlie-tca> There are several things towards the end
[02:52] <skaet> charlie-tca, yeah those failures to fetch files and has sum mismatches look suspicious.
[02:52] <skaet> I suspect this will be a learning exercise for me :-/
[02:52] <charlie-tca> Hoping they didn't. sometimes it just means you have to release a lock and tell it to run aagt
[02:53] <skaet> As soon as the dvd images finish off,  I'll try them individually and see what happens from a command line perspective.
[02:53] <charlie-tca> again, but I am not very good at reading these things, either.
[02:53] <skaet> thanks for pointing me to the logs though... :)
[02:55] <charlie-tca> You are welcome
[02:55] <charlie-tca> I don't get to help you very often
[02:58] <skaet> mythbuntu desktop (amd64, i386) - posted 20110413 image
[03:43] <skaet> ubuntu dvd (i386, amd64) posted
[03:43] <skaet> 20110413 image
[03:44] <stgraber> skaet: any news on alternte ?
[03:44] <stgraber> *alternate
[03:45] <skaet> stgraber,  they don't seem to have been triggered,  am going in and trying them manually now.
[03:45] <skaet> package they were waiting for is in the pool, so, ... fingers crossed.
[03:46] <stgraber> ok. I don't think I'll still be around to test them tonight but will test LTSP first thing tomorrow morning (eastern time)
[04:06] <skaet> kubuntu desktop arm (preinstalled omap, omap4) posted - 20110413
[04:07] <stgraber> seems like alternates are ready too
[04:10] <skaet> ubuntu alternate (i386, amd64, amd64+mac, powerpc) posted - image 20110413
[04:10] <skaet> stgraber,  yup
[04:10] <skaet> just came off the builds
[04:16] <skaet> kubuntu dvd (i386, amd64) posted - 20110413
[04:32] <skaet> kubuntu mobile (omap, omap4) posted 20110413
[05:03] <lamont> doko_: I'll see if that does any better for me.
[05:06] <skaet> ubuntu headless (omap3, omap4) posted - 20110413
[05:06] <skaet> GrueMaster, ogra_ - that should be all the arm images available now.
[05:12] <skaet> ubuntu-server (i386, amd64) posted  - 20110413
[05:29] <lamont> skaet: we're hard-frozen the next couple days, yes?
[05:29] <skaet> lamont, yes
[05:30] <skaet> lamont,  what's pending?
[05:30] <lamont> ok.  on the off chance these bits actually build, I'll wait for the unfreeze before I bounce around the arm chroot tarball to bootstrap fpc
[05:31] <lamont> also, I'll build a fresh tarball tomorrow and then make it the current tarball once we unfreeze
[05:31] <skaet> cool,  thanks.   window may open on Thursday,   depends on how this set of builds looks.
[05:31] <lamont> thereby making the dist-upgrade step a no-op for the first few minutes
[05:31] <lamont> doko_: same error.
[05:31] <lamont> skaet: so I can skip that part :(
[05:34]  * skaet nods
[05:35] <skaet> ubuntu studio (amd64, i386) posted - 20110413
[05:39] <lamont> skaet: so in the unlikely event that the current archive proves to be useless for building packages, let me know,eh?
[05:41] <lamont> (highly unlikely, I warrant)
[05:41] <lamont> anyway, sleep for this one
[05:42] <skaet> lamont,  will do.  (me thinking sleep too is a good idea)
[05:45] <skaet> pitti, cjwatson, jibel,  all images except xubuntu daily live are posted now.   langasek has that building now.
[06:14] <slangasek> xubuntu live posted
[08:06] <pitti> Good yawning
[08:06] <pitti> skaet, slangasek: excellent
[08:08] <pitti> hm, edubutu DVD on cardamon failed to build
[08:16] <ScottK> pitti: I'm about to go to sleep myself, but if you can squeeze that KDE SRU in, I'll be around in a few hours to keep an eye on it and manage any retries due to archive skew.
[08:29] <pitti> ScottK: KDE SRU> right, was planning on looking at that today, now that the urgent uploads are settled
[08:29] <pitti> hmm, mythbuntu uploads in the queue?
[08:29] <ScottK> Great.  Thanks.
[08:33] <pitti> the mythtv upload looks relevant, accepting that (fixing oversizedness)
[08:33] <pitti> I pinged superm1 about the other ones
[08:34] <pitti> skaet: did superm1 happen to talk to you about the mythbuntu related uploads?
[08:57] <mvo> in case someone wonders, main-all in the auto-upgrade-tester looks pretty good, the only failure left is bug #655533 - likewise-open I was not able to reproduce in a clean vm, so its something that is installed along with it
[08:57] <ubot4> Launchpad bug 655533 in likewise-open (Ubuntu Natty) (and 1 other project) "[master] package likewise-open 5.4.0.42111-2ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (affects: 4) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/655533
[09:04] <ev> fix for 759401 incoming
[09:14] <Daviey> mvo: Eucalyptus passed ok?
[09:16] <mvo> Daviey: I don't think its installed on this image, the algorithm is greedy so if euca caused more removals than it added it will be rejected from the image. I can add a profile for this or manually add it, probably a good fit for the server-tasks image
[09:17] <mvo> Daviey: what packages/metapackage should I install? eucalythus-cloud?
[09:17] <Daviey> mvo: Odd... i thought you identified a regression some months ago.
[09:18] <Daviey> mvo: It probably needs two different scenarios tbh.. one being eucalyptus-cloud eucalyptus-cc eucalyptus-walrus eucalyptus-sc
[09:19] <Daviey> the other being eucalyptus-nc
[09:19] <mvo> Daviey: some of euca is installed on the python-all image, but not much afaict
[09:20] <mvo> ok, let me add that, we got a new disk so there is plenty of space to fill with tests :)
[09:20] <Daviey> mvo, w00t
[09:23] <pitti> for the record, I switched two buildds to manual for urgent natty builds, so that I can keep the rest busy with SRUs
[09:25] <mvo> Daviey: the eucalyptus-nc one has just this additional package? and the other 4 euca packages (just to ensure I get the profile right)?
[09:27] <Daviey> mvo, Yeah... the -nc package is the individual nodes - and normally exists on it's own.  The other scenario is all the components on the same machine (minus -nc).
[09:27] <ev> ^ right, so the stitch is that all CDs with ubiquity will exhibit that bug, but it's non-fatal.  The error message will show but the install should complete successfully.
[09:35] <pitti> ev: hm, I wonder why that didn't come up in the testing since Monday
[09:35] <ev> pitti: it broke with a change from yesterday
[09:36] <ev> my fault for testing syntax but not the whole thing in the context of a full install
[09:36] <ev> apols
[09:36] <pitti> jibel: hm, do we have time for a respin/test?
[09:37] <pitti> maybe not the DVDs (we can document that), but at least the desktops?
[09:37] <pitti> ev: on xubuntu etc. as well, I take it?
[09:37] <ev> correct
[09:38] <pitti> ev: kubuntu as well? (since this does some gnome-keyring bits)
[09:38] <ev> anything with ubiquity, though oem-config is unaffected since it exits that function immediately
[09:38] <ev> correct, kubuntu as well
[09:39] <jibel> pitti, which images ? all or only ubiquity based images ?
[09:39] <pitti> I accept it for now to let it buildl
[09:39] <pitti> jibel: yes, all desktop images (not alternate/server/etc.)
[09:39] <pitti> nor the preinstalled armel ones
[09:41] <jibel> pitti, okay, only desktop i386 and powerpc are well covered yet.
[09:41] <pitti> jibel: ok, scheduling a rebuild then
[09:41] <jibel> I'm marking desktop images as rebuilding
[09:41] <pitti> we need a mythbuntu respin anyway, so at least for that it doesn't matter
[09:41] <pitti> jibel: thanks
[09:43] <ev> pitti: thanks
[10:40] <mvo> Daviey: euca-nc just upgraded successfully, euca-cloud is still running, it should show up tomorrow on the regular qa dashboard page
[10:41] <Daviey> mvo, Well that is odd.. i was expecting a failure :P
[10:41] <Daviey> mvo, I appreciate that, thanks.
[10:41] <Daviey> mvo, Is there any way i can get the result as soon as it comes in, instead of waiting for tomorrow?
[10:45] <mvo> Daviey: sure, here is the raw log of euca-nc http://people.canonical.com/~mvo/tmp/euca-nc-mav-natty-upgrade.log
[10:46] <mvo> Daviey: its based on the minimal server image (just ubuntu-minimal,standard plus euca)
[10:49] <Daviey> mvo, That is great - thanks.
[10:49] <mvo> Daviey: it has a FAILED for the debsums_lite test, but that is expected, I disabled this test on the real upgrade tester as the locale bits always fail
[10:49] <Daviey> ah
[10:51] <mvo> Daviey: here is the other one http://people.canonical.com/~mvo/tmp/euca-cloud-mav-natty-upgrade.log
[10:59] <Daviey> thanks mvo, big help.
[10:59] <mvo> yw
[11:33] <pitti> jibel: I'm queueing new desktop and DVD builds now, once ubiquity has published, shoudl start in about 15 minutes
[11:33] <pitti> jibel: I will rebuild DVDs as well; we can then decide whether or not to add them to the tracker
[11:33] <pitti> i. e. whether we have time to test them, or use the current images with the bad error message
[11:35] <jibel> pitti, current DVD builds are untested, when will the new builds be available ?
[11:36] <Riddell> pitti: new kubuntu too?
[11:36] <pitti> jibel: hm, perhaps 4 hours or so?
[11:36] <pitti> Riddell: ev said it affects Kubuntu as well, yes
[11:36] <jibel> pitti, ok.
[12:34] <pitti> jibel_, all: new Ubuntu desktops posted (20110413)
[12:36] <pitti> jibel_: FYI, I marked the DVDs as rebuilding as well, they only got 1 test in total
[12:36] <pitti> (which revealed the very bug that got fixed now)
[13:08] <pitti> Kubuntu images should land in the next ~ 10 minutes; I'm off for lunch and will add them when I get back, unless someone beats me to it
[13:09] <pitti> ah, already trickling in, adding now
[13:10] <pitti> Riddell, all: http://cdimage.ubuntu.com/kubuntu/daily-live/20110413.1/ added to tracker
[13:17] <ogra_> netbook preinstalled omap4 doesnt look good
[13:17]  * ogra_ prays its a bad SD or some such
[13:18] <jibel> what's the ETA for xubuntu desktop images ?
[13:52] <pitti> re
[13:52] <pitti> jibel: should be there now, I'll catch up on adding
[13:52] <jibel> pitti, I added them. thanks
[13:52] <pitti> jibel: http://cdimage.ubuntu.com/xubuntu/daily-live/20110413.2/
[13:52] <pitti> ah
[13:54] <pitti> mythbuntu added
[13:55] <pitti> kubuntu-mobile i386 added
[13:55] <pitti> jibel: ubuntu DVD is building now, FYI
[13:58] <jibel> pitti, why there's no livefs-build log and cd-build log for xubuntu 20110413.2 on http://people.canonical.com/~ubuntu-archive/{cd-build-logs,livefs-build-logs}/xubuntu/natty/ ?
[13:59] <pitti> jibel: hm, I'm not sure, their mirroring might lag a bit?
[14:00] <pitti> jibel: CD build log does exist: http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/natty/daily-live-20110413.2.log
[14:00] <cjwatson> mirroring is hourly
[14:00] <ogra> phew, seems it was a bad dd write
[14:01] <jibel> ah okay, thanks
[14:04] <ogra> hmm, do we have a trigger for update-gconf-defaults ?
[14:05]  * ogra doesnt want to use a postinst if he can solve the issue with one trigger line
[14:05] <highvoltage> like everyone should!
[14:05] <ogra> highvoltage, well, only if the respective trigger exists :)
[14:06] <Daviey> Can we consider the current iso a candidate yet?  Has anyone expressed a need for a respin affecting server?
[14:10] <cjwatson> I've not seen one yet
[14:10] <pitti> neither have I
[14:11] <pitti> Daviey: IOW, with the information currently available, "yes"
[14:11] <Daviey> groovy, thanks.
[14:18] <stgraber> what's the ETA for Edubuntu ?
[14:19] <ogra> all ubuntu armel images look good
[14:20] <ogra> (minor issues that can be fixed before final)
[14:26] <ogra> pitti, hmm,. the tracker is weird, it shows "Ubuntu ARM Preinstalled" as well as "Ubuntu Netbook Preinstalled" for armel, i think there is some duplication
[14:30] <pitti> ogra: right, the ubuntu netbook armel+... should be dropped, right?
[14:30] <pitti> ogra: at least our publishign scripts expects "ubuntu arm preinstalled"
[14:30] <ogra> thats weird
[14:31] <ogra> given we never use the arch name as flavour
[14:31] <pitti> we can also drop ubuntu ARM preinstalled
[14:31] <ogra> flavour should be headless or netbook
[14:31] <pitti> I'm not sure who added it
[14:31] <ogra> let me see where the mail link gets me
[14:31] <cjwatson> apparently it needs care to change at the iso.qa side
[14:32] <pitti> but yes, anything which brings some more consistency into the naming schema is greatly appreciated
[14:32] <cjwatson> the last time I tried it broke some bit of Tobin's workfloww
[14:32] <ogra> Ubuntu ARM Preinstalled omap4
[14:32] <cjwatson> see discussion on this channel before beta-1
[14:32] <cjwatson> and #ubuntu-testing
[14:33] <ogra> well, we definitely shouldnt use the arch in the flavour description
[14:33] <ogra> but "ubuntu arm preinstalled" is what the tracker uses atm
[14:34] <ogra> shoudl be s/arm/headless/ or s/arm/netbook/ imho
[14:34] <ogra> anyway, to report my results at the right place i guess i have to use "Ubuntu ARM Preinstalled" atm
[14:45] <stgraber> pitti: any guess as to when Edubuntu will be done rebuilding ?
[14:45] <jibel> cjwatson, I updated the tracker last week, and moved the iso path matching logic to the database. Now the names of the products are less tightly linked and we can change them without breaking the paths to the isos.
[14:46] <jibel> which means no more hardcoded product name in the tracker code.
[14:46] <stgraber> jibel: yeah !
[14:47] <cjwatson> aha
[14:47] <jibel> and that should work for dot releases too
[14:51] <stgraber> jibel: bug 148944 should have made it easier to watch cdimage and improve the guessing logic. But that's been around for a while and that part of the code was probably the biggest issue of the tracker ;) thnaks for fixing it
[14:51] <ubot4> Launchpad bug 148944 in ubuntu-cdimage "File list on cdimage for the Ubuntu QA Tracker" [Undecided,Confirmed] https://launchpad.net/bugs/148944
[15:03] <pitti> stgraber: it should start in about 15 minutes, ETA 1 h
[15:03] <stgraber> pitti: ok, thanks
[15:20] <pitti> oh oh, do I smell a rebuild there? ^ ogra
[15:21] <pitti> jibel: ubuntu dvd posted
[15:23] <ogra> pitti, nope, only fixes for the bugs i found
[15:23] <ogra> nothing thats serious
[15:23] <skaet> morning all,   just went through the backscroll.    Looks like a bit more rebuilding was needed.... but all seems under control now (arm rebuilds being the question).
[15:23] <ogra> if we get a rebuild i'd love to have them in, but its also fine post beta
[15:24] <pitti> hey skaet
[15:24] <skaet> hey pitti,   busy morning for you looks like.
[15:24] <pitti> ogra: the description fix seems trivial, the sources.list bug a bit harder to fix on upgrade
[15:24] <pitti> skaet: heh, yes :)
[15:25] <ogra> pitti, yes, the fixes both need to be in at image build time
[15:27] <ogra> anyway, all armel images seem good to go as they are atm
[15:40] <jibel> skaet, there's no ec2 on the tracker?
[15:40] <skaet> jibel,  haven't heard from smoser about them yet.
[15:40] <jibel> skaet, k
[15:41] <skaet> thanks for the reminder - will go ping...
[15:41] <smoser> well, uec images dont build right now :-(
[15:41] <smoser> working on that fix
[15:41] <skaet> smoser,  ok,  good luck.
[15:55] <pitti> kubuntu DVDs posted
[15:55] <pitti> Riddell, jibel ^
[15:57] <Riddell> yay
[16:07] <ogra_> stgraber, your python-apt fix doesnt seem to work
[16:08] <stgraber> ogra_: hmm, that seems weird. Worked fine with both commented and non-commented line here. Currently in a meeting, can you pastebin your sources.list before and after your run your script ?
[16:09] <ogra_> thats a bit tricky since its run in initramfs, but i'll try my best
[16:10] <ogra_> in any case the python-apt package is the latest and the sources.list looks exactly like what i filed on the bug
[16:23] <smoser> i need someone from the release team to acl https://launchpad.net/ubuntu/natty/+queue?queue_state=1&queue_text=cloud-init
[16:28] <pitti> (done FTR)
[16:35] <stgraber> ogra_: I'm wondering if that may be a ports vs archive kind of issue. I'm updating my pandaboard now so I'll have a good test environment. Should have more this afternoon.
[16:38] <GrueMaster> In my testing of the source.list, I found that software-properties-gtk seems to work properly as far as commenting or uncommenting the sources.list entries.  There may be something missing in the setup to the function call.
[16:44] <smoser> ok. build of uec images is now polling, waiting for grub-legacy-ec2 at 0.6.1-0ubuntu7 to get into archive and will build 20110413.1 when it arrives.
[17:01] <pitti> stgraber: edubuntu DVDs posted
[17:01] <pitti> http://cdimage.ubuntu.com/edubuntu/dvd/20110413.1/ (still syncing, though)
[17:01] <pitti> rebuilding mythbuntu now to fix oversizedness
[17:01] <pitti> then we are done
[17:02]  * skaet crosses fingers ....;)
[17:32] <stgraber> ogra_: ok, I reproduced the issue on my pandaboard. Looking at python-apt now to fix it. It's very likely a different issue though giving the same result :(
[17:35] <stgraber> highvoltage: ^ (in case you missed it, edubuntu is ready for testing)
[17:36] <stgraber> mvo: so we have another python-apt upload scheduled before final right ?
[17:45] <stgraber> ogra_: ok, the issue is that python-apt is considering these sources.list entries as invalid or non-official (for some reason), so really a completely different bug
[17:50] <ogra_> stgraber, weird, since it considers the deb ones valid
[17:51] <stgraber> ogra_: yeah, I'm currently adding some debug to it so it logs why each line is being skipped
[18:00] <highvoltage> stgraber: I'm rsyncing those images so long, but I might only be able to test them tonight
[18:04] <pitti> mythbuntu posted
[18:07] <pitti> skaet: all images built and posted now, I'm not aware of necessary rebuilds ATM
[18:09] <skaet> pitti, excellent!  thanks.
[18:09] <jibel> Woohoo no more rebuilds, thanks!
[18:09] <jibel> we can start testing then ?
[18:09] <jibel> j/k
[18:10]  * pitti hugs jibel
[18:14] <stgraber> mvo: ping
[18:14] <stgraber> mvo: I'd need someone who's familiar with python-apt's templates ;) I'm pretty sure that's ogra_'s issue
[18:15] <stgraber> mvo: if I read the Ubuntu template correctly it says that for != i386 and != amd64, we must use http://ports.ubuntu.com/ubuntu-ports/ to have it marked as an "official" entry in sources.list
[18:15] <stgraber> mvo: what I can't find is how to update the template to say that it's fine using archive.ubuntu.com on != i386 and != amd64 for deb-src entries
[18:16] <stgraber> ogra_: ^ that's why I didn't get the issue on amd64 btw
[18:16] <ogra_> ah
[18:17] <stgraber> ogra_: if I use "deb-src http://ports.ubuntu.com/ubuntu-ports" instead of archive, then python-apt works properly
[18:18] <ogra_> well, i didnt add a.u.c there its a default coming from somewhere in the image build process
[18:21] <stgraber> I'm not sure if we want whatever adds a.u.c to be changed to use p.u.c or if we want python-apt to be modified to accept a.u.c as a valid deb-src source on ports architectures
[18:22] <ogra_> well, a.u.c is totally valid for sources
[18:26] <stgraber> ogra_: I closed your old bug report again as that issue is fixed and opened a new one: bug 760035
[18:26] <ubot4> Launchpad bug 760035 in python-apt (Ubuntu) "Ubuntu.info template doesn't allow deb-src lines using archive.ubuntu.com on ports architectures (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/760035
[18:27] <stgraber> mvo: ^
[18:30] <mvo> oh, indeed
[18:30] <mvo> thanks for this one
[18:32] <stgraber> mvo: just looking at the template, it's not obvious if there's a non-hackish way of overriding for source entries. I guess "source" could be considered as an architecture but it doesn't look like it's at the moment
[18:33] <mvo> stgraber: yeah, I think that is a valid approach
[18:35] <pitti> skaet: do you need me for anything else? if not, I'd toddle off to Taekwondo
[18:36] <skaet> pitti,  looks like UbuntuStudio is having problems
[18:36] <skaet> build dependencies,  in discussion on u-testing now
[18:36] <skaet> s/build/install/
[18:36] <skaet> sigh
[18:36] <superm1> i was working with pitti to get amd64 mythbuntu cd's down in size, just committed some seed changes to make the on media pool smaller.  can someone queue a rebuild?
[18:37] <skaet> pitti,  you want me to?  or will you?  re:  mythbuntu?
[18:37] <pitti> skaet: if you can?
[18:37] <skaet> pitti,  sure.
[18:38] <pitti> superm1: ah, just "ship"? that shouldn't need publisher runs
[18:39] <pitti> skaet: http://cdimage.ubuntu.com/ubuntustudio/daily/20110413/report.html <- eek
[18:39] <superm1> pitti, well ship-live, but yeah, i wasn't sure if it needed publisher run or not
[18:39] <pitti> I bet it's trying to pull in libavcodec
[18:39] <pitti> superm1: I don't think so, only for live
[18:39] <skaet> superm1, pitti - have kicked it off,  but if its not needed,  will not post.
[18:40] <pitti> skaet: these aren't refelected on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html, so I guess it's due to libavcodec
[18:40] <pitti> skaet: the rebuild is needed, we just don't need a publisher run after the seed change
[18:40] <skaet> pitti,  thanks for the explanation.  :)
[18:41]  * pitti waves good bye then; I'll check in again when I'm back in ~ 3.5 h
[18:50] <cjwatson> debootstrap upload (appearing shortly) isn't needed for beta-2
[18:51]  * skaet thanks cjwatson for that qualification ;)
[18:52] <skaet> ScottL,  around?
[18:52] <jibel> ScottL, ubuntu-studio is broken, bug 760008
[18:52] <ubot4> Launchpad bug 760008 in debian-installer (Ubuntu) "amd_64 studio install fails (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/760008
[18:52] <jibel> there's a dependency of ubuntustudio-desktop on hal which is not satisfied.
[18:53] <cjwatson> the libavcodec stuff might go away once the other is fixed ...
[18:53] <cjwatson> we at least tried to work around that at the seed level
[18:53] <cjwatson> (ubuntustudio.natty r1254)
[18:54] <cjwatson> though, hmm, the metapackages don't look right
[18:54] <cjwatson> I'm going out, will have a look when I get back if nobody else has
[19:03] <scott-work> hi, project lead for ubuntu studio here
[19:03] <scott-work> how much more time do we have to test images for beta 2
[19:03] <scott-work> ?
[19:17] <charlie-tca> scott-work: <jibel> there's a dependency of ubuntustudio-desktop on hal which is not satisfied.
[19:17] <stgraber> skaet: ltsp alternate amd64 is broken due to yesterday's fix (and me assuming that chmod -f would always return 0 ...). I don't think we can/want to fix that for beta2. I have a one line fix that I'm going to push upstream now and once again release a new upstream and upload.
[19:18] <charlie-tca> Trying to get all the tests done today. Beta 2 release is tomorrow
[19:19] <charlie-tca> scott-work: bug 760008
[19:19] <ubot4> Launchpad bug 760008 in debian-installer (Ubuntu Natty) (and 1 other project) "amd_64 studio install fails (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/760008
[19:20] <stgraber> skaet: bug 759965
[19:20] <ubot4> Launchpad bug 759965 in ltsp "ltsp installation fails on Build LTSP chroot step (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/759965
[19:20] <stgraber> patrickmw: ^
[19:21] <skaet> stgraber,  ok,  so I'm clear.  we'll be documenting it, rather than trying for another set of images?
[19:21] <skaet> or are we going for a fresh set of images?
[19:22] <stgraber> skaet: I don't know what else you have pending and how critical it's to have LTSP work on amd64 for beta2
[19:22] <skaet> stgraber,  is it only on amd64?
[19:22] <stgraber> skaet: yep, i386 is fine
[19:24] <stgraber> I fixed the bug manually in my VM and am continuing the install with the fix, just to make sure nothing else breaks with LTSP on 64bit. Should have that done in the next 5 minutes or so
[19:24] <stgraber> if that's fine, I already have a new ltsp release ready to be pushed on my laptop with the one-line fix
[19:24] <skaet> stgraber,  get the fix ready,  and I'll do some asking.   which amd64 images will need respinning.
[19:25] <highvoltage> stgraber: is the workaround big? would be nice to have it in the beta2 release notes along with the problem note
[19:25] <highvoltage> (or at least have it in the bug report it's linked to)
[19:26] <stgraber> highvoltage: workaround is "wait for it to fail in the installer", chroot to /target, modify /usr/sbin/ltsp-update-kernels, look for chmod line, add || true, restart installer step
[19:26] <stgraber> highvoltage: that's really quite hackish :)
[19:26] <stgraber> skaet: AFAIK, only ubuntu alternate amd64 would need respinning. Edubuntu also ships LTSP but shouldn't be affected as we ship i386 LTSP on our amd64 DVD
[19:27] <skaet> superm1,  jibel  mythbuntu (i386, amd64) posted - 20110413.3
[19:28] <highvoltage> stgraber: indeed.
[19:28] <skaet> stgraber,   ok,  will start getting it ubuntu alternate amd64 queued up for when you give the signal.
[19:28] <stgraber> skaet: ok, my ltsp 64bit install just finished and works fine with my fix. I'll have the new package uploaded in the next 5 minutes
[19:29] <stgraber> hehe, first time I release a new upstream LTSP with a diff of just one line ;)
[19:29] <stgraber> well, technically, 6 chars ;)
[19:36] <stgraber> debdiff for ltsp 5.2.7-0ubuntu1 to 5.2.8-0ubuntu1: http://paste.ubuntu.com/593691/
[19:36] <stgraber> (it's uploaded)
[19:45] <scott-work> charlie-tca:   forgive my ignorance, is this just a matter of removing the dependency on hal?
[19:46] <scott-work> charlie-tca: would we be able to delay the beta 2 release for ubuntu studio ?  i don't think the studio team would mind, but i realize it might make it difficult for others
[19:47] <mvo> http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ <- woah, mostly green (white), amazing. main-all also has a amazing runtime
[19:57] <superm1> skaet, yay, finally no longer oversized! :)
[19:57] <superm1> it's still weird that amd64 is 50mb bigger, but not a big deal anymore
[19:58] <skaet> superm1,  yay!
[20:04] <stgraber> pitti, slangasek: Can one of you review that ltsp upload ?
[20:04] <stgraber> or anyone else who has that power :)
[20:10] <skaet> stgraber,  am looking for one of the archive admins to see if they can help... pitti and cjwatson are offline right now.
[20:12] <seb128> skaet, what do you need exactly?
[20:13] <jdstrand> I am here
[20:14] <jdstrand> seb128: ^
[20:14] <seb128> ok, I'm here as well ;-)
[20:14] <jdstrand> seb128: skaet pinged me privately. I've got it. thanks!
[20:14] <seb128> ok
[21:01] <jibel> skaet, ^ scott-work> charlie-tca: would we be able to delay the beta 2 release for ubuntu studio ?  i don't think the studio team would mind, but i realize it might make it difficult for others
[21:01] <charlie-tca> I misseed that
[21:02] <charlie-tca> Sorry, must have been fighting with screen-reader then
[21:02] <charlie-tca> jibel: glad you caught that!
[21:03] <skaet> jibel,  scott-work,  charlie-tca;  depends on degree of holding up.  We have some flex.
[21:03] <skaet> but not a lot
[21:03] <charlie-tca> I seem to be a go-between
[21:03] <skaet> thanks for flagging jibel,  am bouncing between too many windows today.
[21:03] <charlie-tca> He asked when the images needed to be tested by. I tried to answer and told him about the bug
[21:04] <skaet> charlie-tca, what's the outlook on a fix?  and the time for retest?
[21:05] <charlie-tca> I don t know
[21:05] <charlie-tca> I think he just has to remove the dependency on hal from the seed, doesn't he?
[21:06] <charlie-tca> I don't know if anything in -studio actually requires hal, but I don't think so
[21:08] <highvoltage> stgraber: 84% at 68KB/s, 1:57:14 est.
[21:08] <charlie-tca> We don't actually have anyone available that can authorize any changes to the image right now.
[21:09] <scott-work> charlie-tca: sorry, my webchat dropped the connection, if you responded earlier i missed it
[21:09] <charlie-tca> scott-work: As far as I know, yes, it is simply removing the hal dependency
[21:09] <charlie-tca> I don't believe you have anything requiring it, do you?
[21:10] <scott-work> charlie-tca: righty-o, i don't believe so, but i would like to check with luke or persia first to make sure there's nothing i'm missing
[21:10] <charlie-tca> We were just talking ablut you
[21:10] <scott-work> charlie-tca: about me?
[21:10] <stgraber> highvoltage: I started another transfer in the mean time (rsync against ubuntu DVD that I already had around), 37s remaining
[21:10] <charlie-tca> scott-work: yup
[21:10] <charlie-tca> scott-work: <skaet> charlie-tca, what's the outlook on a fix?  and the time for retest?
[21:11] <scott-work> charlie-tca: if luke is amenable we can update the seeds tonight i would expect
[21:11] <charlie-tca> scott-work: hal was moved from main to universe
[21:11] <charlie-tca> skaet: ^ ^
[21:12] <scott-work> but i believe luke is currently asleep, i usually try to catch him aroud five hours from now
[21:12] <jibel> skaet, smoser what's the news about ec2 ? anything ready for testing or is it still building ?
[21:12] <skaet> charlie-tca, scott-work,  how long to retest once the images are biuldt.
[21:13] <jibel> skaet, ~ 40mn for an arch
[21:14] <skaet> jibel, thanks.
[21:14] <charlie-tca> fast connections help; mine are about 45 minutes each test
[21:15] <skaet> jibel, re: smoser should speak for himself, but the impression I've gotten is that the bug fix was found, and they're building.   Should be going up in a few hours, but I haven't seen any further details about an actual ETA.  :(
[21:16] <smoser> probably 7 hours-ish from 17:55:15 +0000
[21:16] <smoser> (that was start time)
[21:16] <smoser> so another 4.5 hours probalby. they're being published.
[21:17] <jibel> smoser, thanks
[21:23] <skaet> scott-work,  as soon as you have a fix ready, ping me or pitti (depending on the time ;) ),  and if we can generate images and you can get them tested in time, we'll include them.  Otherwise they'll need to go out after the announce.
[21:25] <scott-work> skaet: copy that
[21:30] <stgraber> skaet: any ETA on the alternate rebuild (if we're still rebuilding ubuntu alternate amd64) ?
[21:30] <skaet> stgraber,  waiting for the publisher to land the updates into the archive,  then willl kick it off.
[21:31] <stgraber> ok, cool. I probably won't have time to test it before I leave the office but will do so when I get back home (probably 10-11pm EDT). Only takes me ~20 minutes to test LTSP.
[21:31] <cjwatson> charlie-tca: how about I just do it?
[21:31] <cjwatson> would that be dreadful?
[21:32] <charlie-tca> It's up to scott-work, I don't have anything to do with studio
[21:32] <cjwatson> 'bzr blame' says that that seed entry dates from a 2006 commit by mdz
[21:32] <cjwatson> which was just comment removal actually
[21:32] <scott-work> cjwatson: if you want to remove the hal dependency i wouldn't view that as dreadful at all :)
[21:32] <Daviey> Does anyone here have an VMWare-ESX setup?
[21:32] <cjwatson> and before that, back to revision 1 when I imported the Ubuntu seeds from the wiki
[21:33] <cjwatson> so it doesn't look like it was ever explicitly added for ubuntustudio
[21:33] <cjwatson> scott-work: OK, I'm going to go ahead and seek forgiveness rather than permission then
[21:33] <charlie-tca> Teach me to answer questions here, huh?
[21:33] <stgraber> Daviey: that can be arranged. I no longer have access to it but I'm still in a building where we have one ;) (highvoltage has access)
[21:33] <stgraber> Daviey: VMWare ESXi 4.1 enterprise plus IIRC
[21:33] <cjwatson> heh
[21:34] <Daviey> stgraber, Well i wouldn't want to get you in trouble, but would you be able to do the server test case for that?
[21:34] <stgraber> highvoltage: ^ can you start a server install on verdi ?
[21:34] <highvoltage> stgraber: maybe mjeanson would do it :)
[21:34] <highvoltage> well, I wouldn't mind either...
[21:35] <Daviey> highvoltage, \o/
[21:35] <Daviey> highvoltage, http://iso.qa.ubuntu.com/qatracker/result/5442/267
[21:36] <stgraber> highvoltage: rdesktop to cooper.appsrv.sherb.rlnx.com, open VMWare vsphere, connect to verdi.dev.sherb.rlnx.com as root (the vcenter seems to be down)
[21:37] <stgraber> highvoltage: it's access to the same shared directory as chopin, so you'd just need to wget the image to chopin's shared directory first
[21:40] <highvoltage> Daviey: 64bit or 32bit?
[21:40] <Daviey> highvoltage, either|both :)
[21:41] <Daviey> I'm a bad man, because i care more about amd64.
[21:42] <highvoltage> I'll start with amd64 then
[21:44] <cjwatson> so this ubuntustudio-meta change is going to be kind of guesswork; it's hard to test in advance
[21:44] <cjwatson> I can try
[21:45] <cjwatson> (and I'm probably best-placed to fix this particular category of bug, in all honesty)
[21:45] <skaet> cjwatson,  thank you.  (and I agree.... )
[21:47] <cjwatson> I've removed hal, and rejigged the Task-Seeds fields to match the STRUCTURE inheritance - the ffmpeg-common seed was what was supposed to make all those libavcodec dependencies behave consistently
[21:47] <cjwatson> regenerating ubuntustudio-meta based on that now
[21:48] <pitti> charlie-tca, scott-work: why do you think it's the hal dependency?
[21:48] <pitti> are we talking about the ustudio uninstallability here?
[21:49] <pitti> http://cdimage.ubuntu.com/ubuntustudio/daily/20110413/report.html doesn't look like it would be due to hal, as that would reflect on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html as well
[21:49] <charlie-tca> pitti: yes, since the error was hal unavailabl
[21:49] <pitti> my first suspicion would be that it's because something tries to pull in libavcodec?
[21:49] <cjwatson> see above
[21:49] <cjwatson> I suspect it may well be that and that hal is just a casualty
[21:50] <pitti> aah
[21:50] <cjwatson> but if anything in ubuntustudio-desktop needed hal, shouldn't it be an explicit dependency?
[21:50] <charlie-tca> bug 760008
[21:50] <ubot4> Launchpad bug 760008 in ubuntustudio-meta (Ubuntu Natty) (and 1 other project) "amd_64 studio install fails (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/760008
[21:50] <cjwatson> when I went through bzr blame, it looked like it was just left over from ancient Ubuntu seed entries
[21:50] <pitti> cjwatson: ideally yes; a lot of old packages still just assume that it's there unfortuantely
[21:50] <cjwatson> oh
[21:50] <cjwatson> do you think I should put it back then?
[21:50] <pitti> the ones which could need it would  have a libhal1 dependency, though
[21:51] <cjwatson> I can check germinate output for that
[21:51] <pitti> cjwatson: no idea, I'm afraid; I know that e. g. pitivi still can use it for some features, but it's usually not critical
[21:52] <pitti> a good test is to start the main things in u-studio and then check if "hald" is running
[21:52] <pitti> as it's triggered via dbus-activation, this should tell whether anything needs it
[21:52] <cjwatson> is libhal1 a reliable test?
[21:53] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.natty/rdepends/hal/libhal1 says that the only thing pulling it onto images is hal itself
[21:53] <pitti> cjwatson: positively reliable, but not negatively
[21:53] <pitti> i. e. you can also talk to hal directly via dbus
[21:53] <cjwatson> ah
[21:53] <pitti> (which is usually what python programs do)
[21:53] <cjwatson> OK, I'll revert that seed change then
[21:54] <pitti> I certainly hope it's just cruft, but I can't really tell without actually examining the programs
[21:55] <pitti> my preferred fix for this would certainly be to explicitly add hal dependencies
[21:55] <pitti> it's not something that should be seeded; but I realize that it's a little late for that in natty
[21:56] <cjwatson> OK, reverted with a mini-essay in the commit log
[21:56] <cjwatson> and generating ubuntustudio-meta again
[21:57] <stgraber> pitti: "grep -r hal /" then filter out the false positives :)
[21:57] <pitti> stgraber: and org.freedesktop.Hal
[21:58] <pitti> stgraber: actually, that or a dependency to libhal1 should be quite sufficient
[21:58] <pitti> programs either use libhal1 or open a d-bus connection to org.fd.Hal
[21:59]  * pitti wonders how often we need to stab this beast before it's dead for good
[22:01]  * skaet keeps looking to see if ltsp_5.2.8 has landed.... grrr not there yet.
[22:03]  * charlie-tca tried to kill it again
[22:05] <stgraber> pitti: on my laptop (so, mostly standard ubuntu), I get: libnet-dbus-perl, pitivi, pm-utils, python-apport, checkbox, gnome-power-manager and virt-manager
[22:05] <Riddell> skaet: it presumably won't get in until this publisher run has finished
[22:05] <stgraber> pitti: I can easily run the same check on studio to check the difference if that helps
[22:06] <skaet> RIddell, yup, waiting for the publisher run started over an hour ago to finish....
[22:07] <pitti> stgraber: e. g. pm-utils has a fallback if /sys doesn't work (mostly for BSD right now)
[22:07] <pitti> stgraber: python-apport?!?
[22:07] <pitti> stgraber: ah, haha! it's an example stack trace in the test cases :)
[22:07] <pitti> guess when I wrote that code..
[22:08] <pitti> stgraber: I'm just afraid I can't modernize that, because of course udev, udisks, upower etc. never crash!
[22:08] <pitti> *cough*
[22:08] <stgraber> pitti: yeah right :)
[22:09] <pitti> stgraber: but anyway, I doubt that merely having hal installed causes any problems; it won't even start by default
[22:09] <pitti> I don't think we should rip it out that lalte
[22:10] <pitti> "late"
[22:10] <stgraber> yeah, that's the kind of things you usually want done before Feature Freeze, so you have enough time to find and fix whatever breaks
[22:11] <pitti> cjwatson: just to ensure that I understand http://launchpadlibrarian.net/69309093/ubuntustudio-meta_0.83_source.changes, will that install alternative dependencies which lead to not pulling in libavcodec?
[22:12] <scott-work> pitti: blender was uninstallable i believe due to libavcodec
[22:12] <skaet> pitti, cjwatson, stgraber - ARCHES='amd64' for-project ubuntu cron.daily kicked off
[22:13] <ScottK> pitti: Not that it's relevant for Ubuntu Studio, but we do have a problem in KDE where if hal is present, KDE solid will start it and use a mixture of data from it and upower with unfortunate results.  So there are cases where installing it can cause problems.
[22:14] <cjwatson> pitti: so libavcodec is odd
[22:14] <cjwatson> (and friends)
[22:14] <cjwatson> pitti: there are a bunch of libfooN, and then a bunch of libfoo-extra-N
[22:14] <cjwatson> pitti: they conflict - you have to consistently select one set or the other
[22:15] <cjwatson> pitti: normally, we use libfooN; but a few things in ubuntustudio need libfoo-extra-N, so ubuntustudio needs to consistently select that throughout
[22:15] <pitti> and libavcodec-extra-52 is sufficiently patent-free to allow it on media?
[22:15] <cjwatson> pitti: convincing the package management toolchain to do that is most easily done by seeding the lot further down
[22:15] <pitti> or do we basically ignore the libavcodec patent issue on u-studio?
[22:15] <cjwatson> I *think* the latter
[22:16] <pitti> it makes sense as we don't press CDs for that, anyway
[22:16] <cjwatson> because we've shipped libavcodec52 before, and we avoid even that for Ubuntu
[22:16] <pitti> cjwatson: thanks for the heads-up
[22:17] <pitti> I'd like to accept shared-mime-info and xdg-utils (translation updates only), objections?
[22:17] <pitti> erm, xdg-user-dirs
[22:18] <pitti> mostly as an opportunistic improvements for any rebuild we might need to maek
[22:18] <cjwatson> I don't mind
[22:20] <pitti> cjwatson: what is lxc? do we need the debootstrap upload for b2 for anything?
[22:20] <cjwatson> 18:50 <cjwatson> debootstrap upload (appearing shortly) isn't needed for beta-2
[22:20] <pitti> thansk
[22:20] <skaet> jibel, stgraber,  ubuntu alternate amd64 posted  (ltsp fix)
[22:20] <cjwatson> lxc => containers.  the bug in question has been worked around in lxc already, but fixing it properly in debootstrap is IMO the right thing to do
[22:21] <scott-work> pitti, cjwatson, charlie-tca, skaet :  i am going home, if you need me for any ubuntu studio issues you can reach me at ScottL in about 30 minutes
[22:21] <cjwatson> scott-work: ok, it'll need retesting after metapackage lands and CDs rebuild
[22:21] <scott-work> cjwatson: aye
[22:25] <highvoltage> Daviey: this is just creepy :) http://irc.jonathancarter.org/files/dump/esxi-aubergine.png
[22:27] <cjwatson> off for a bit
[22:30] <Daviey> highvoltage, Sorry, i don't follow.
[22:30] <highvoltage> Daviey: it failed :( ubuntu-standard is installed and the virtual kernel not, I'm *quite* sure I chose install minimal server from gfxboot, but I'll double-check now just to be sure
[22:31] <Daviey> highvoltage, oh dear... thanks.
[22:31] <stgraber> skaet: downloading
[22:31] <highvoltage> Daviey: an aubergine debian-installer with a windows task bar? maybe it's just me then
[22:31] <Daviey> highvoltage, OIC :)
[22:36] <highvoltage> this time d-i seems to get confused when I enter my password
[22:37] <highvoltage> I get a blue screen then a red screen telling me my password is blank and when I press enter it doesn't give me a chance to go back
[22:37] <highvoltage> (eventually it worked, weird)
[22:38] <Daviey> highvoltage, yeah, i noticed on error it seems to present traditional blue.
[22:38] <Daviey> I'm not sure we need to fiddle with the colours anymore this cycle :)
[22:39] <pitti> skaet: want me to set up a triggered rebuild for ubuntustudio, or want to kick it off yourself?
[22:39] <pitti> bbiab
[22:41] <skaet> pitti,  i'm fine with kicking it off, once things are ready.   What should I be triggering on?
[22:41]  * skaet likes to be able to see directly when its done.... ;)
[22:49] <highvoltage> Daviey: this time it did ok, but it's oversized (>500M)
[22:50] <Daviey> highvoltage, yeah... someone else found that on KVM... technically it's failed the test case - can you mark it so?
[22:50] <Daviey> I think we are OK with it (i think maverick released with the same)
[22:50] <Daviey> highvoltage, really appreciate your help with this.
[22:51] <Daviey> highvoltage, RoAkSoAx is raising a bug for it as we speak.
[22:53] <highvoltage> Daviey: I just finished filing a bug for it
[22:53] <highvoltage> https://bugs.launchpad.net/ubuntu/+bug/760288
[22:53] <ubot4> Launchpad bug 760288 in ubuntu "JeOS is oversized (affects: 1) (heat: 6)" [Undecided,New]
[22:53] <Daviey> highvoltage, ah perfect, thanks
[23:02] <pitti> skaet: when ubuntustudio-meta 0.83 binaries are available on antimony, i. e. wait-for-package ubuntustudio-desktop_0.83
[23:03] <skaet> pitti,  yup that's what I was looking to know.:)
[23:03] <pitti> skaet: cool; then I think I'll head bedwards :)
[23:04] <pitti> skaet: btw, on TechOverview do you actually like the sections which just say "Shotwell has been updated to 0.9.1."?
[23:04] <pitti> TBH I think we should remove them; version numbers aren't very interesting IMHO
[23:05] <skaet> pitti, well some folks care about versions (kernel folk for instance ;) )
[23:06] <Daviey> skaet, When do you need TechOverview done by?
[23:06] <skaet> pitti,  I'll get the known bugs put into the tech overview tonight,  and if you could take a pass in the morning to sanity (delete the uninteresting ones) that would be great.
[23:06] <skaet> Daviey,  EOD today...
[23:06] <pitti> skaet: sounds great
[23:07] <pitti> beta-2 will be a nice bday present tomorrow \o/
[23:07] <Daviey> skaet, great... now - 5 hours. ;)
[23:07] <pitti> so, good night everyone!
[23:07] <skaet> Daviey,  today being 3/13.
[23:07] <skaet> Daviey,  yup.
[23:07] <skaet> sleep well pitti
[23:07] <Daviey> jolly good.