[00:04] <xnox> https://launchpad.net/ubuntu/+source/imagemagick version in precise is higher than in quantal.... yet probably the security update should have been pushed to both?
[00:05] <xnox> nevermind I have both...
[00:17] <RAOF> xnox: That looks like it should have been pushed to Quantal, yes.
[00:18] <xnox> RAOF: funny thing in my sources I only have quantal, yet I have 3.1 available
[00:18] <xnox> let me double check
[00:19] <RAOF> I don't have 3.1 available, nor does rmadison show that for quantal.
[00:20] <micahg> yeah, that should've been copied, it was published the first week of may
[00:21] <micahg> the package could use a merge from Debian anyways though
[00:21] <xnox>  libmagickcore-dev : Depends: libmagickcore4 (= 8:6.6.9.7-5ubuntu3) but 8:6.6.9.7-5ubuntu3.1 is to be installed
[00:21]  * xnox just had that a moment ago
[00:21] <xnox> I did apt-get update just now, and it's gone now.
[00:22] <micahg> xnox: that would happen if you had precise installed without the dev package, got the update before updating to quantal, then tried to install the dev package on quantal
[00:22] <xnox> aha =)
[00:22] <xnox> yes, of course.
[00:22] <xnox> yeap, I did upgrade less than 5 weeks ago.
[00:23] <micahg> so, if someone with copy powers can make it so, that would be great
[00:24]  * micahg tries a test build on quantal (if it works, I'll do a no change upload)
[00:35] <micahg> test build worked |)
[00:43] <Daviey> micahg: can you clarify the situation ?
[00:44] <micahg> Daviey: are you AA enough to copy something yet?
[00:44] <Daviey> micahg: i believe so.. but i'd like to clarify the issue :)
[00:44] <micahg> Daviey: this security update pushed on 1 May wasn't copied to quantal as it should've been
[00:45] <Daviey> imagemagick ?
[00:45] <micahg> yes
[00:45] <micahg> I could do a no change upload, but I think a merge from Debian would be more useful
[00:46] <Daviey> micahg: then why not just merge from Debian?
[00:46] <micahg> Daviey: I don't have time ATM :)
[00:53] <skaet> micahg,  any specific issue with Firefox 13 beta 6?  (its for an alpha)
[00:55] <micahg> skaet: there were 2 small bugs fixed in beta 7, but no show stoppers AFAIK
[00:56] <micahg> one is Mac only
[00:57] <micahg> the other is fixing a potential crasher, not a blocker IMHO for an alpha, was mainly wondering about the beta 6 label on the package
[00:59] <skaet> micahg,  beta 6 should be fine for alpha - its all work in progress.   Don't think there should be an issue using beta label,  we release kernel in the milestones with -rc# s.   If others know an issue though I'm overlooking, they're welcome to chime in.  ;)
[00:59] <skaet> when will beta 7 be landing?
[01:02] <micahg> skaet: it won't the next upload would probably be 14 beta 7 (we're on 13 now) after alpha 1 is released
[01:02] <skaet> micahg,  then beta 6 should be fine.
[01:02] <micahg> ok, thanks :)
[01:02] <skaet> Just add the known issues to the TechnicalOverview (which I'm about to create ;) )
[01:03] <micahg> I wouldn't even think it known issue worthy
[01:03] <micahg> but if any come up, I'll be sure to let you know :)
[01:04] <skaet> fair 'nuf.   :)  thanks
[01:04] <tumbleweed> micahg: AFAIK if you can upload a package, you can copy it
[01:04] <micahg> tumbleweed: ORLY?  I thought that was AA only
[01:04]  * micahg tries
[01:10] <micahg> well, u-a-t doesn't seem to have a script that can just copy (this was done server side AFAIK)
[01:10]  * stgraber tries
[01:12] <stgraber> micahg: lp-shell didn't complain at least
[01:12] <micahg> stgraber: right, my lp-shell-foo is lacking :)
[01:12] <stgraber> micahg: yep, worked
[01:12] <micahg> stgraber: thanks, Daviey, you can stand down :)
[01:12] <stgraber> lp-shell production devel
[01:12] <stgraber> archive=lp.distributions['ubuntu'].archives[0]
[01:13] <stgraber> archive.copyPackage(from_archive=archive, include_binaries=True, source_name="imagemagick", to_pocket="release", to_series="quantal", version="8:6.6.9.7-5ubuntu3.1")
[01:13] <stgraber> and that's it :)
[01:18] <Daviey> stgraber: I was just writing a damn script doing that
[01:19] <stgraber> < 5 lines => not worth a script ;)
[01:20] <Daviey> stgraber: well, i disagree.. I was writing something reusable with confirmation.
[01:20] <micahg> Daviey: I think the script exists, it just needed to be moved to u-a-t
[01:20] <micahg> or rewritten to work in the world of non-local AA tasks
[01:20] <Daviey> micahg: no, i don't think there is one that uses the API
[01:21] <micahg> Daviey: right
[01:21] <Daviey> exactly, which is what i was doing.
[01:21] <tumbleweed> sru-accept includes code to do that, if you tell it to
[01:22] <micahg> well, if it's in -proposed (which this never was)
[01:22] <micahg> sru-accept?
[01:22] <tumbleweed> err I mean sru-release
[01:28] <Daviey> load average: 1003.85, 1001.70, 903.73 ... hmm.. what did i do?
[01:29] <stgraber> fork bomb? :)
[01:30] <Daviey> hah, no..
[02:02] <xnox> thanks all for fixing imagemagick =)
[02:04] <stgraber> xnox: np, was fun to finally test copyPackage() ;)
[02:05]  * xnox tries to think of something else to amuse stgraber
[02:05] <xnox> stgraber: do you want to have fun with deleting binaries? =)
[02:06] <stgraber> I don't have access to that kind of fun
[02:06] <xnox> bug 1007970
[02:06] <ubot2`> Launchpad bug 1007970 in bitcoin "please remove powerpc binaries" [Low,Confirmed] https://launchpad.net/bugs/1007970
[02:06] <xnox> stgraber: but I was sure that it was migrated to the new type of tools et al
[02:07] <stgraber> I know cjwatson tested package removals through the API but you still need an archive admin for them
[02:07] <xnox> ah ok.
[02:07]  * xnox no more amusment available for stgraber, please check back later ;-)
[02:08] <stgraber> unless someone decided to allow anyone with upload access to a package to also remove it and its binaries, which might to a certain extent make sense, but I don't think it's what was implemented
[02:09] <xnox> stgraber: sounds to permissive given that the stuff that you do *not* have upload rights for, may have already rebuild against it.
[02:10] <stgraber> true, but you could just as well upload a new version of the package and would also break the same set of rdepends, at some point we have to trust people :)
[02:11] <xnox> stgraber: oh so only at that point you gonna trust people.... =)
[02:11] <xnox> btw, stgraber for Developer Membership Boards, is it 2 application per type, or in total?
[02:11] <xnox> where type is type of developer membership
[02:12] <stgraber> xnox: total
[02:12] <xnox> =(
[02:12] <xnox> ok. So I will have to wait until 18th of June to try my luck
[02:12] <stgraber> we usually ask questions for more than 30min per applicant so we implemented that limit of two applicants to try and have us fit the meeting in our one hour slot
[02:13] <xnox> I see.
[02:13] <stgraber> we could probably ask less questions but it'd be a lot less fun :P
[02:13]  * xnox notes down that stgraber likes to amusement
[02:17] <jbicha> fun for who?
[02:34] <xnox> jbicha: i have started to type 'to amuse himself' then thought it might sound wrong and wanted to change it to "likes amusement"
[02:34] <xnox> obviously I forgot to drop 'to'
[02:34] <xnox> =)
[02:34] <Daviey> xnox: 'binary' right?
[02:35] <xnox> Daviey: well, yeah.... powerpc only ( I did not check if the previous version of the package has actually build one or multiple arch:any packages that succeded on powerpc)
[02:38] <Daviey> they would have been superseeded for free
[02:42] <xnox> Daviey: what do you mean? new package doesn't build for powerpc, long time ago it was, by error, listing powerpc as supported arch, but in fact it was not (builds, but does not run properly)
[02:43] <xnox> so.... even though there is a powerpc binary in the archive, it should not be there.
[02:43]  * xnox that is unless we care about powerpc at all....
[02:45] <Daviey> xnox: you mean prior series? Precise etc?
[02:46] <xnox> Daviey: all as far as I can see
[02:47] <xnox> http://people.canonical.com/~ubuntu-archive/testing-ports/quantal_outdate_all.txt
[02:47] <xnox> bitcoin 0.6.2.2-1ubuntu1 bitcoind(powerpc) 0.3.24~dfsg-1 from 0.3.24~dfsg-1 [universe]
[02:48] <xnox> so package moved from: any -> [i386,amd64,arm-any]
[02:48] <xnox> because all other arches, even if succeed to build, do not work
[02:48] <Daviey> xnox: right.. Perhaps i'm tired.. but we are talking about different things :)
[02:48] <Daviey> src bitcoin produces bitcoind bin, right?
[02:48] <xnox> yeap
[02:49] <Daviey> so, one binary.. How would there be multiple prior versions in the same series?
[02:49] <xnox> Daviey: there is one version per arch, but different arches can have different versions
[02:50] <Daviey> but we are only talking about power, right?
[02:50] <xnox> Daviey: yes.
[02:50] <xnox> so, yeah on powerpc it is stuck at 0.3.24~dfsg-1
[02:51] <Daviey> Right.. so what others could there be?
[02:51] <xnox> on powerpc, none at all.
[02:51] <xnox> marking the package `any` was a mistake from the start.
[02:52] <Daviey> ok.. still not following.. but ok :)
[02:53] <Daviey> Anyway, there seems to b a 24hr delay for removals.. or some other bug.. https://launchpad.net/ubuntu/+source/bitcoin/0.3.24~dfsg-1/+publishinghistory  "Removal requested in 23 hours."
[02:54] <xnox> Daviey: http://bugs.debian.org/650805
[02:54] <xnox> fail wrong link.
[02:54] <xnox> aha http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668868
[02:54] <ubot2`> Debian bug 668868 in src:bitcoin "bitcoind: Assertion failed at startup on mips (big endian)" [Serious,Fixed]
[02:55] <Daviey> OH.. you mean other arches?
[02:55] <stgraber> Daviey: my understanding is that bitcoin (source) produces bitcoind (binary). In the past bitcoin was arch=any so produced bitcoind for powerpc. Nowadays bitcoin is arch=any-but-not-powerpc so no longer produces the bitcoind powerpc binary. Which left us with an outdated (pre-arch-field-change) version of bitcoind in quantal and for powerpc only
[02:56] <ScottK> Which should be removed (on powerpc)
[02:56] <stgraber> right
[02:56] <xnox> Daviey: that request seems to remove the whole source package, which is way too much
[02:56] <Daviey> stgraber: Yeah, i got that.. what confused me is that there seemed to be some doubt as to there being more than one binary to remove.
[02:56]  * xnox sorry about that confusion
[02:57] <Daviey> xnox: no, i'm probably tired. :)
[02:58] <stgraber> tired? it's only 4am on a weekend/bank holiday, perfectly normal time to work ;)
[02:58]  * xnox same here.
[02:58] <Daviey> nah, i'm on 3:00AM.. I work on UTC.
[02:58] <xnox> stgraber: are you based in the UK as well or just happen to have bank holiday as well.
[02:59] <Daviey> If the whole world adopted UTC working hours, life would be much more efficient.
[02:59] <jbicha> Daviey: I don't know, that's a bit early
[03:00] <stgraber> xnox: nah, was just referring to the situation for both Daviey and you. I live in Canada on eastern time, so it's the much more reasonable time of 11pm here :)
[03:00] <xnox> stgraber: Canada, eh?! =)
[03:01] <stgraber> Daviey: I'd definitely be happy with the whole world always using the UTC timezone and dropping the stupid DST, thought I'd still be waking up at 13:00UTC
[03:02] <stgraber> xnox: not hearing much "eh?" around here, mostly some weird french variant ;)
[03:02] <xnox> UTC... and synchronised with Narnia time
[03:02] <xnox> http://xkcd.com/1061/
[03:06] <skaet> https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview <- has framework in place now for Alpha 1 content to be added.
[03:11] <skaet> Also, "Ubuntu Release Calendar"(http://fridge.ubuntu.com/calendars/ubuntu-release-calendar/) now has the key release schedule events on it for the next 6 months (mirrors what's on the wiki page)
[06:49] <jibel> mvo, good morning
[06:49] <jibel> mvo, could you look at update-manager, it failed to build on i386 and as a consequence images are uninstallable
[06:50] <jibel> mvo, there is a recursive build caused by a symlink on ./Distupgrade
[06:50] <jibel> mvo, introduced by this change in r391: Add a DistUpgrade -> . symlink in DistUpgrade/, to make it possible to have compatible imports both in update-manager proper and in dist-upgrader tarballs.
[07:09] <mvo> jibel: I have a look now
[09:22] <mvo> hm, I guess a new apt with a transition for libapt-inst1.4->libapt-inst1.5 is not a good idea at this time? the amount of rebuilds is pretty small as libapt-pkg4.12 is abi compatible
[10:08] <Daviey> mvo: might want to outline reasoning and list of rebuilds. :)
[10:18] <mvo> Daviey: *cough* reasoning? iz new version ;) but seriously, its the merge from debian, it can wait for after a1, it just happens to be read in my bzr repo
[10:27] <jibel> mvo, any news on update-manager ? it'd be nice to have images other than i386 for A1 :)
[10:30] <mvo> jibel: *cough* yes, after lunch
[10:31] <jibel> mvo, k, bon appétit !
[10:46] <Riddell> cjwatson: moving kubuntu bits to universe presumably needs changes to ubuntu-cdimage and livefs to create the images with universe?
[10:46] <Riddell> oh you're on holiday today
[11:16] <ogra_> Riddell, you arent ?!?!
[11:16] <ogra_> oh, Daviey is around too
[11:17] <ogra_> you must all love your queen, eh ?
[11:17] <ogra_> :P
[11:18] <Riddell> ogra_: I have too much kubuntu stuff to do to care about bank holidays just now
[11:19] <ogra_> heh
[11:27] <Daviey> ogra_: I am not around, i'm a hallucination.
[11:27] <ogra_> lol
[11:27]  * ogra_ pust down the crack pipe then, seems i overdid it 
[12:33] <mvo> jibel: new u-m is uploaded, fingers crossed
[12:44] <jibel> mvo, successfully built ! Thanks
[13:00] <mvo> yeeeeeh!
[13:00] <mvo> :)
[13:21] <stgraber> good morning
[13:35]  * infinity wonders when promotion/demotion on component-mismatches was changed to "movement", and why he only just noticed.
[13:37] <skaet> good morning
[13:37] <knome> morning skaet! :)
[13:37] <skaet> :)
[13:38]  * skaet looks at IRC logs, and thank mvo for the fixed update-manager (fingers crossed)
[13:38] <skaet> has anyone kicked off the image rebuilds?
[13:38]  * skaet wondering if stgraber or NCommander are around
[13:39] <stgraber> skaet: I am
[13:39] <skaet> coolio.  :)
[13:39]  * NCommander wakes up
[13:39] <NCommander> Still enjoying morning diet coke
[13:39] <stgraber> skaet: was looking whether the archive is in a consistent enough state to try and kick some rebuilds
[13:40] <stgraber> skaet: already created Alpha 1 on the tracker and changed the config on nusakan to point to it, so anything that builds now will show up on the tracker
[13:40] <skaet> thanks stgraber,  that's what I was trying to figure out.    gap in IRC log and when I logged in ;)
[13:40] <ogra_> dont bother with arm images though
[13:40] <stgraber> ogra_: ok :)
[13:40] <ogra_> we're still waiting for the MIR team
[13:40] <skaet> ogra_, ack.
[13:40] <ogra_> and desktop has compiz issues i'm currently trying to work around
[13:45] <skaet> ogra_,  what's the bug number of the blocking MIR
[13:45] <skaet> ?
[13:46] <ogra_> bug 1006717
[13:46] <ubot2`> Launchpad bug 1006717 in eilt "[MIR] linux-base" [High,New] https://launchpad.net/bugs/1006717
[13:46] <ogra_> i wonder why it picks the eilt project here ... that was surely added later
[13:46] <ogra_> silly bot
[13:47] <skaet> Thanks ogra_ :)
[13:47] <stgraber> skaet: turned off cron
[13:47] <NCommander> ogra_: probably alphabetizes it
[13:47] <NCommander> e > u afterall
[13:48] <NCommander> er
[13:48] <NCommander> e < u
[13:48] <ogra_> heh
[13:48] <skaet> thanks stgraber.
[13:48] <stgraber> skaet: (except for the precise daily builds that can still run without really affecting us)
[13:48] <skaet> good point.  :)
[13:49] <knome> stgraber, who was it to contact about the testcase wiki again?
[13:49] <stgraber> knome: jibel or balloons
[13:50] <knome> jibel, balloons: (since you are already highlighted:) hi! can you ping me once you're available; thanks! :)
[13:50] <knome> stgraber, thanks
[13:51]  * infinity fixes rpm, alien, lsb, (okay, that as all rpm), and linux-image-generic-pae issues, and goes to find some breakfast and ponder why he woke up at 6am.
[13:52] <ogra_> because your brain is still somewhere between china and canada i.e. over europe ?
[13:52]  * infinity adds erlang to the list.
[13:52] <ogra_> infinity, isnt it a bank holiday for you today anyway ?
[13:52] <infinity> ogra_: Is it?
[13:52] <ogra_> qell, there is that queen thing
[13:53] <infinity> Oh, pretty sure only the UK is slacking.
[13:53] <infinity> I've heard nothing about us doing so.
[13:53] <ogra_> i though that applies to all the commonwealth
[13:53] <infinity> We'd all have to have decided so individually.
[13:53] <infinity> The queen can't force law on us.
[13:53] <ogra_> ah
[13:54] <ogra_> poor you then
[13:54] <infinity> But, like I said, I've not heard anything about Canada slacking to party.
[13:54] <ogra_> :)
[13:54] <infinity> Odd reason to party anyway.
[13:54] <infinity> "Good job on being old and rich."
[13:54] <ogra_> heh
[13:58] <infinity> erlang should fix rabbitmq and maas.
[13:58] <infinity> stgraber: So, if you're doing servery respins (maas/rabbit are on server CDs, yes?), you might want to wait for a publisher cycle to see if testing-probs clears up from the fiddling I just did.
[13:58] <infinity> And happy PlusOne month to me.
[13:59] <stgraber> infinity: ok. I'm currently trying a desktop respin to check that amd64 actually builds now. Will avoid server for the next 30min
[14:00] <skaet> infinity,   stgraber,   not sure that Daviey's finished with his changes, so not sure what state its going to be in.  (ie. if its even ready to be spun)
[14:02] <stgraber> skaet: ubuntu-amd64 on kapok.buildd finished at 2012-06-04 14:01:57 (success)
[14:02] <stgraber> yay!
[14:02] <skaet> :D
[14:22] <jibel> knome, pong
[14:39] <skaet> stgraber,  NCommander - http://pad.ubuntu.com/ubuntu-release has been started for Quantal A1.   Image builds still need to be reviewed and edited.
[14:40] <skaet> utlemming, any concerns about getting images ready for A1 this week?
[14:40] <stgraber> skaet: thanks. Still waiing for desktop powerpc to finish building...
[14:40] <utlemming> skaet: no ma'am. They should be good to go this week.
[14:41] <skaet> utlemming,  coolio.  :)
[14:41] <stgraber> oh, I guess I can build core though
[14:41] <skaet> :)
[14:41] <stgraber> hmm, or not, core is also a live image
[14:42] <ogra_> err
[14:43] <ogra_> core is a tarball
[14:43] <ogra_> (or at least should be)
[14:43] <skaet> stgraber,   lubuntu alternate should be ok to build.
[14:43] <stgraber> ogra_: yeah but built with buildlive
[14:43] <ogra_> yes
[14:44] <stgraber> skaet: indeed, triggering that one
[14:44]  * xnox has a highlight for alternate. yes keep building alternate cd's.
[14:44]  * xnox disappears
[14:54] <Laney> skaet: Can we get the alpha soft freezes on the schedule? :-)
[14:54] <stgraber> Laney: hehe, just poked skaet about it too ;)
[14:54] <micahg> skaet: just noticed that the release schedule doesn't seem to be clear at all about when alpha freezes are (we know them to be the Monday before release at 21:00 UTC)
[14:54] <Laney> hahahaha
[14:55] <Laney> there is no secret release schedule scrutinising cabal here
[14:55] <Laney> honst
[14:55] <Laney> honest
[14:55] <stgraber> skaet: right, so as I was telling you in pm, the DMB (^) was discussing it ;)
[14:55] <skaet> lol
[14:55] <micahg> well, 2 of you are in the release team :)
[14:55] <Laney> we don't have any secret channels :(
[14:56] <stgraber> micahg: 3 actually
[14:56] <ScottK> Not that you'll admit to.  They wouldn't be secret then.
[14:56] <stgraber> micahg: oh, you mean, talking in this channel, corect then :)
[14:56] <micahg> :)
[14:57]  * skaet just went to double check and they are on the Ubuntu Release Calendar.    
[14:58] <skaet> however,  yes,  we need to send out the email.
[14:58] <Laney> there's a calendar?
[14:58] <skaet> Laney not sure I want to add them to the wiki pages though, since its another line, and makes things a bit confusing.
[14:59] <Laney> maybe put it in Notes?
[14:59] <Laney> Alpha 1 (Soft freeze Monday 04/06)
[14:59]  * Laney shrugs
[14:59] <skaet> yup,  that should be doable.
[15:05] <skaet> Laney, stgraber, ScottK, micahg - there's http://fridge.ubuntu.com/calendars/ubuntu-release-calendar/
[15:05] <micahg> not linked from https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
[15:05] <micahg> and ^^ is where we generally point people AIUI
[15:05] <skaet> micahg,  oversite,  will fix.
[15:13] <skaet> michag, done
[15:20] <balloons> skaet, I thought we added the freeze to the interlock page?
[15:20]  * balloons looks and sees it's not the case
[15:49] <jdstrand> taking the publisher offline as per https://wiki.ubuntu.com/ArchiveAdministration#Special_case:_update-manager_updates
[15:52] <mvo> jibel: fwiw, I enabled precise->quantal in do-release-upgrade -d mode (normal upgrade mode, not lts upgrade mode)
[15:54] <jibel> mvo, great. server and desktop upgrade will start in 1h13min. We'll see how it goes.
[15:54] <mvo> cool
[15:58] <balloons> skaet, ping
[15:58] <stgraber> gah, who broke ruby? ...
[15:58] <stgraber> both Edubuntu images fail to build because of ruby not being installable
[15:59] <skaet> balloons, otp,  biab
[15:59]  * stgraber starts building lubuntu desktop while investigating the ruby problem
[16:02] <ScottK> stgraber: Debian recently made Ruby 1.9 default.   You didn't get that by sync did you?
[16:03] <infinity> stgraber: The ruby problem is in hand.
[16:04] <stgraber> infinity: good :)
[16:04] <infinity> stgraber: ruby-defaults came in via autosync, required us to rev ruby1.9.1, which I've just done.
[16:13] <jdstrand> publisher back online
[16:13] <infinity> jdstrand: Thanks for the review of linux-base.
[16:13] <jdstrand> np
[16:15] <skaet> ogra_ ^
[16:15] <infinity> jdstrand: Given that our kernel team is probably responsible for the lintian-sadness, and I have a couple of them on loan to me this month for +1, I'll use this as a good object lesson for training. :P
[16:16]  * ogra_ hugs jdstrand 
[16:16] <jdstrand> infinity: cool :)
[16:16]  * infinity wishes doko was around to re-activate him in ~ubuntu-mir.
[16:16]  * jdstrand hugs ogra_ :)
[16:19] <stgraber> well, I guess it's time for lunch. Lubuntu desktop is building (waiting on powerpc), will then continue with Kubuntu and finally Edubuntu which should be buildable again by then
[16:20] <ogra_> compuiz fix is uploaded too ... sadly not to quantal-proposed though, i owe everyone a beer at next UDS for whom that caused trouble
[16:21] <infinity> ogra_: Should be fine.
[16:21] <ogra_> infinity, the beer you mean ? yeah :)
[16:23] <infinity> ogra_: I meant it shouldn't be a problem, but I'm happy to accept beer too.
[16:23] <ogra_> :)
[16:36] <skaet> Riddell,  cjwatson - during the A1 soft-freeze window,  please hold off on doing autosync's from Debian,  and discuss in this channel if an exception is required.
[16:37] <Riddell> skaet: that starts end of tuesday?
[16:37]  * ogra_ wonders if colin will acvtually read IRC before wed. given its a UK holiday
[16:37] <skaet> Riddell,  no today.
[16:38] <Riddell> gotcha
[16:38] <skaet> We've started spinning images now,  and have a lot of cruft to shake down.    So best not introduce any more.
[16:38] <skaet> Softfreeze starts at 2100 UTC.
[16:38] <skaet> but we're effectively in it now.
[16:44] <infinity> ogra_: Compiz happy on arm*, thanks!
[16:44] <ogra_> \o/
[16:44] <infinity> ogra_: I hope you and/or didrocks have taken an action to remember it's been kludged and fix it properly? :P
[16:45] <ogra_> infinity, it will all be different in the next upload anyway (GLES is being merged upstream right now)
[16:45] <ogra_> so the gles patch will be gone, nothing to revert :)
[16:45] <ogra_> (i did the hack inside the patch)
[16:46] <infinity> ogra_: Ahh, shiny.
[17:09] <stgraber> hmm, what happened to the alternates?
[17:09] <stgraber> AFAICS the cronjobs are turned off on nusakan and I already built these a while ago, so not quite sure what/who build them again
[17:23] <jibel> alternate and desktop automated tests passed. upgrades are running
[17:27] <stgraber> slangasek: why are you rebuilding the daily live images? (and was it you who rebuilt the alternates?)
[17:29] <slangasek> stgraber: whoops; failure on my part to coordinate, sorry
[17:29] <slangasek> stgraber: please dump the new builds in favor of the previous ones that were already being tested
[17:29] <stgraber> slangasek: ok
[17:32] <stgraber> slangasek: well, according to the tracker we didn't have any result for the previous alternates, so I guess we can keep the new ones then
[17:32] <slangasek> ok
[17:32] <stgraber> though we have results for the desktop ones, so if you can stop the build it'd be nice, otherwise I'll revert it when it lands on the tracker
[17:32] <slangasek> though, jibel said "alternate and desktop automated tests passed", which might have some bearing?
[17:33] <stgraber> jibel: what version of the desktop and alternate image where these automated tests run against? if that's on 20120604.2 (alternate), I'll revert the builds on the tracker
[17:40] <skaet> stgraber, as the images emerge off of the builds,  can you update http://pad.ubuntu.com/ubuntu-release, so we can keep coordinated a bit better.  ;)
[17:41]  * skaet going in and doing som cleaning now.
[18:35] <skaet> stgraber, NCommander,   afk for a bit,  back on later.
[18:43] <stgraber> removing these from the tracker^
[18:50] <jibel> stgraber, it was 20120604.2
[18:50] <stgraber> jibel: ok, reverting the alternes too then
[18:50] <jibel> 20120604.3 passed too
[18:51] <stgraber> oh, ok, well, if 20120604.3 passed too, we can keep them then :)
[19:06] <stgraber> infinity, ogra_: started building arm desktop now, though I only noticed that mx5 and ac100 aren't candidate after I started the build, so they'll get built, I'll just remove them from the tracker afterwards
[19:37]  * infinity decides that http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html looks much better and rewards himself with a lunch break.
[19:38] <slangasek> infinity works for peanuts
[19:39] <infinity> This isn't the sort of thing one really wants confirmed by one's manager.
[19:39] <slangasek> infinity: we can throw in some jelly, then you can have a whole sandwich
[19:39] <infinity> Too kind.
[20:13] <NCommander> stgraber: I need to go AFK for a bit, I'll be about in ~45 minutes to an hour
[20:14] <stgraber> NCommander: k
[20:31]  * skaet back
[20:32] <stgraber> skaet: arm desktop is still building and so is wubi, everything else is built and posted on the tracker
[20:32] <skaet> stgraber,  coolio.  :)  thank you.
[20:36] <balloons> stgraber, skaet, slangasek what's up with wubi this cycle? I thought wubi was moving to an exe only, non-scheduled release cycle Forgive me if this is a silly question, it's been proven I'm scattered today.
[20:37] <skaet> balloons,  it wasn't clear to me either.  slangasek just confirmed its status quo to last release.
[20:40] <balloons> skaet, what does that mean? Are you trying to say we're going to continue pushing images of it out or ?
[20:40] <stgraber> balloons: don't know the exact plan but even without it being on the CD, the actual .img file used by wubi needs testing
[20:42] <skaet> balloons,  agree we need to get the plan clarified as to what we want tested for it.
[20:44] <slangasek> balloons: I don't know what "exe only" should mean here, but as stgraber says, there's a wubi image that must still be generated and tested
[20:45] <slangasek> balloons: is this question coming from https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-wubi-publishing, or from somewhere else?
[20:45] <slangasek> (btw, it's already status quo that we don't offer a wubi-based install option on the CD in precise)
[20:48] <balloons> slangasek, yes from that blueprint.. I agree, clearly whatever/however we're doing it it needs tested..
[20:49] <balloons> I just want to make sure I understand what the plan is, and if testing needs have changed..
[20:52] <slangasek> balloons: testing should not be changing
[20:52] <balloons> slangasek, ok, that's good.. has the timing changed at all? I suppose for this alpha nothing has changed
[20:52] <slangasek> no... nor am I aware of any reason the timing /should/ change... but I wasn't in the session
[20:53] <slangasek> I'm only going by what was written up in the blueprint - if you think that doesn't reflect what was agreed in the session, please poke the drafter ;)
[20:53] <balloons> slangasek, lol
[20:53] <balloons> fair enough.. please excuse my insanity
[20:54] <balloons> thanks everyone
[21:22] <balloons> bah, my scatteredness.. back on the wubi thing.. there is no exe for quantal.. at least the link we provide is broken: http://people.canonical.com/~evand/wubi/quantal/
[21:25] <stgraber> sounds like someone needs to update it for quantal and upload it
[21:25] <stgraber> ev: ^
[21:25] <stgraber> I guess it's unlikely for ev to be around with the long UK weekend though
[21:25] <ev> hi
[21:25] <ev> ;)
[21:25] <stgraber> oh, or not :)
[21:26] <stgraber> ev: want to do some overtime? :)
[21:26] <balloons> stgraber, when you pushed the builds -- how/why did you do so if the link was broken?
[21:26] <ev> stgraber: on it now
[21:26]  * balloons trying to understand how is got kicked off
[21:26] <balloons> ev, awesome, thanks
[21:26] <ev> balloons: sure thing - it's largely a background task
[21:26] <stgraber> balloons: we're building a .img file that's used by wubi, when that file is built the entry is pushed to the tracker
[21:27] <stgraber> balloons: http://cdimage.ubuntu.com/wubi/20120604.1/
[21:27] <balloons> stgraber, ahh.. so you have that end of it.. but you need to co-ord with ev to get the exe also.. right right, it's coming back now
[21:27] <stgraber> exactly
[21:28] <ev> yeah, I have a work item to push my side of this into the buildds
[21:30] <balloons> ev, yes we were discussing the blueprint above.. I got quite confused on the issue, but I think the lightbulb is on now
[21:32] <ev> balloons, stgraber: http://people.canonical.com/~ev/wubi/quantal/stable is in place
[21:32] <knome> balloons, hey!
[21:32] <knome> ev, hai!
[21:32] <ev> hi
[21:32] <knome> ev, have a moment?
[21:33]  * balloons in my best darth vader voice knome, so we meet again
[21:33] <stgraber> ev: thanks (s/ev/evand/g)
[21:33] <balloons> ev, thank you much for the quick turnaround
[21:33] <ev> knome: I'm actually on a public holiday. Just popped in to quickly help stgraber with a task that blocks on me
[21:33] <knome> balloons, yeah! so, i have a simple (i hope) question for you
[21:33] <knome> ev, ok, i'll send you email
[21:33] <ev> knome: cheers
[21:34] <knome> balloons, we want to add xubuntu-specific testcases to the testcase wiki. is there a structure you'd prefer?
[21:36] <slangasek> balloons: skaet was just asking we about wubi test cases from http://testcases.qa.ubuntu.com/Install/DesktopWubi - case id wdi-001 is now obsolete, and wdi-002 now depends on wdi-004, so maybe these should be reordered?
[21:36] <slangasek> ev: the testcase tracker also has an entry for "CD boot helper", which uses umenu options Demo and Full installation -> CD-booter ... is this still available?
[21:37] <slangasek> (if not, we should ask balloons to drop test case wdi-003 as well)
[21:37] <balloons> knome, yes, we have a structure we'd prefer.. as you know however, we're migrating to using the isotracker to manage them
[21:37] <balloons> I believe stgraber will be able to import any xubuntu specific testcases into the tracker when we move, so I don't think it would be an issue or waiting however
[21:37] <balloons> so, format format.. let me find a link
[21:38] <balloons> slangasek, yes, we have pending work to dive deeper on these testcases this cycle
[21:38] <knome> balloons, i don't ...
[21:38] <balloons> but I am always tweaking them
[21:38] <balloons> since you and ev are the source for wubi, we can do it right now
[21:39] <balloons> knome, ohh.. well, one moment.. that's more to type then.. and some details and fun to share with you
[21:39] <slangasek> balloons: right, I think that's what skaet was looking for :)  wdi-001 is absolutely obsolete, since it refers to the option to run Wubi from CD that we took away last cycle - IMHO best to drop the test case to remove confusion
[21:39] <knome> balloons, PM is okay if you don't want to flood the channel :)
[21:40] <balloons> slangasek, yes.. I was looking at them a moment ago, but hadn't started down the editing train yet.. ok, so drop test 1 (no more cd)
[21:40] <ev> slangasek: that's the one piece we kept. lp:wubi/src/wubi/frontends/win32/cd_menu_page.py:55
[21:40] <slangasek> ok cool
[21:40] <ev> it uses the NT bootloader to get around having to hit F12 and select a boot device.
[21:41] <slangasek> balloons: sounds like that's the only one to be dropped, then... and do we want to renumber wdi-004 to wdi-001 (and move it up)?  otherwise wdi-002 makes no sense
[21:41] <ev> (by writing the contents of the CD to a file on disk and pointing grub at it)
[21:42] <balloons> slangasek, I'm looking at them now.. we need to re-write 3 as well (I think)
[21:42] <balloons> or does the cd still have that ability
[21:42] <balloons> ?
[21:43] <skaet> slangasek,  maybe better just reordering how they show up on the page - rather than change the numbering so, our past data still makes some sense?
[21:43] <balloons> skaet, yes, I'm re-ordering, not changing numbering..
[21:43] <skaet> :)
[21:43] <balloons> fortunately this will be fixed (kind of) by moving to isotracker to manager
[21:47] <knome> i hope the testcases are community-manageable in the isotracker too :)
[21:48] <stgraber> kind of
[21:48] <knome> :|
[21:48] <knome> that scares me.
[21:48] <knome> we wanted to do some moin-including
[21:49] <stgraber> product managers will be able to pick test suites and assign them to their product, the actual test cases will require extra rights that we'll grant on a case by case basis
[21:49] <knome> me me me me
[21:49] <balloons> knome, they will require a trust level (so you don't have people spamming your tests), but community will be able to edit
[21:49] <stgraber> the reason behind these restrictions is that testcases will be sharable between products, so we hopefully won't have any duplication of tests
[21:50] <stgraber> the downside being that we can't delegate rights on a per testcase basis as they affect more than one product
[21:50] <balloons> slangasek, I guess I will have some folks help re-do case #3; should be similar, but likely that menu has changed a bit
[21:51] <knome> stgraber, i agree that's a good thing. i hope that it's possible to combine testcases though... we want our tests to be similar to ubuntu, but in addition, we want our users to run a xubuntu-specific test
[21:51] <balloons> knome, yes you will be able to add in testcases from ubuntu along with your own to form a testsuite that needs run
[21:51] <knome> balloons, great!
[21:52] <balloons> I guess we're kind of talking about it.. I'll forget pm'ing you :-)
[21:52] <slangasek> balloons: 3 was the one ev just responded to above saying that the functionality is still there
[21:52] <bdmurray> slangasek: I'd approve piston-mini-client to precise-proposed
[21:52] <knome> balloons, would you mind if we added our xubuntu-specific tests to the testcase wiki *now*, or is the migration like *really close* ?
[21:52] <slangasek> bdmurray: accepted
[21:53] <stgraber> knome: the code exists and is running on iso.qa.dev.stgraber.org, we're expecting it to land before alpha-2
[21:53] <knome> stgraber, in that case, i'll hold
[21:54] <skaet> stgraber,  ogasawara uploaded the linux kernel they want used for A1 earlier today.   I've gone ahead and put that on the pad, so it gets included in next rebuild.
[21:56] <stgraber> skaet: ok, is it worth respinning for it as soon as it lands or should we wait till tomorrow to get some more fixes?
[21:58] <skaet> stgraber,  if there are not many test results (or ones marked in testing), probably best to get it respun before Europe comes online.     Since its getting late for you and NCommander's helping out on this one too,  may make sense for him to do the repins this evening.
[21:59]  * skaet went to go look...
[21:59] <skaet> hmm,  looks like lubuntu has some momentum as does ubuntu
[22:00] <stgraber> skaet: kernel is apparently stuck in New, we'll also need a d-i upload for it I believe (assuming ABI bump) and armel failed to build
[22:00] <stgraber> so doesn't look like we can easily respin at this point
[22:01] <slangasek> armel FTBFS is ignorable, there are no armel images to be released for a1
[22:01] <slangasek> NEW can be fixed
[22:01] <slangasek> do you want me to fix it?
[22:01] <stgraber> true, wondering if armhf will be affected too (still building)
[22:02] <skaet> slangasek,  yes, please go ahead and fix the d-i upload.
[22:03] <slangasek> well, I have to do the NEW processing first
[22:03] <slangasek> best if someone else can take care of d-i afterwards
[22:03] <skaet> infinity,  ^ you able to help out?
[22:04] <stgraber> we'll also need a new linux-meta I believe
[22:04] <bdmurray> slangasek: I approve of apport for precise-proposed
[22:05] <slangasek> stgraber: correct - though there's no harm in accepting linux now before we have the timeline on that
[22:05] <stgraber> sure
[22:06] <bdmurray> slangasek: I also approve libgrip for precise-proposed
[22:13] <dobey> there are ~24 hours until freeze, right?
[22:13] <bdmurray> slangasek: and quickly for precise-proposed
[22:18] <skaet> dobey,  no,  we're in soft freeze now.    Email went out to ubuntu-devel-announce just after 2100 UTC.
[22:19] <skaet> dobey,  you can upload to quantal-proposed,  see the email for details.
[22:21] <bdmurray> slangasek: and nautilus for precise-proposed
[22:26] <dobey> skaet: i thought the soft freezes happened on tuesday 2100 utc?
[22:26] <dobey> skaet: did that change?
[22:27] <bdmurray> slangasek: and I approve of euca2ools for precise-proposed
[22:28] <slangasek> bdmurray: apport libgrip quickly nautilus euca2ools accepted
[22:28] <bdmurray> slangasek: thanks
[22:29] <skaet> dobey,  it tended to float depending how much churn was going on,  to clear up the confusion, we've added  explicitly to the schedule http://fridge.ubuntu.com/calendars/ubuntu-release-calendar/   However, uploads can still go to -proposed
[22:29] <bdmurray> slangasek: and you are running sru-accept.py too?
[22:30] <dobey> skaet: eep. :-/ it's not on https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
[22:30] <skaet> dobey,  its a soft freeze,   the beta's are the hard ones.
[22:31] <dobey> skaet: i guess FTBFS fix should go to quantal instead of -proposed though, per your e-mail?
[22:33] <skaet> dobey,  what bug and package are we talking about specifically
[22:33] <skaet> ?
[22:35] <dobey> skaet: haven't seen a bug filed about it, but ubuntuone-client-gnome is currently FTBFS in quantal due to glib adding additional #error in some includes.
[22:35] <dobey> and i am about to upload a version with the fix
[22:37] <skaet> dobey,  fair enough,  go ahead and upload to quantal
[22:38] <dobey> skaet: if i upload other stuff to -proposed, i imagine i will have to do that from now on throughout the entire cycle as well, to keep it properly in sync?
[22:39] <skaet> dobey, nope.  just during the freeze window.   At the end all will be merged back into quantal.
[22:39] <dobey> skaet: and if i think the uploads i am making need to be in alpha 1?
[22:40] <skaet> yes,  we're in the prep for alpha 1 right now.
[22:40] <bdmurray> slangasek: I approve of me-tv for precise-proposed too
[22:41] <dobey> skaet: right. but if i upload to -proposed now, will they hang about until after a1, or do i have to poke people to sync them to quantal for a1?
[22:41] <bdmurray> why are there 2 banshees and 2 clutter-1.0s?
[22:43] <jbicha> because it's easier to add than to remove
[22:43] <jbicha> feel free to drop the older clutter-1.0
[22:45] <skaet> dobey,  hmm,  I said upload to quantal,  not quantal-proposed for that fix.    In general,  we're expecting to have tools to do this sort of post a1 move over so no poking,  but for now this is an experiment, so we will all need to keep an eye on the parts we care about.
[22:46] <dobey> skaet: for that yes, i did upload it to quantal
[22:46] <dobey> skaet: i mean for other things i am trying to upload, but aren't that fix, but which i think should be included in the a1 relase
[22:47] <skaet> dobey,  k,  get them uploaded to proposed, and then we can look at pocket copying them over.   Let us know in this channel when things are built, tested and ready.
[22:47] <dobey> ok
[22:48] <dobey> skaet: and what's the cut-off for being able to pocket-copy during the soft freezes?
[22:49] <skaet> dobey,  that depends on QA and community testers, and whether it makes sense to respin images.
[22:49] <skaet> Basically earlier the better, and based on severity.
[22:52] <dobey> ok. thanks
[22:52] <skaet> :)
[22:55] <skaet> infinity,  around?   can you help out on d-i for the new kernel,  ^  (see slangasek's comments in backscroll)
[23:01] <NCommander> infinity: I'll handle it in about 20 minutes if you aren't already on it
[23:02] <slangasek> bdmurray: haven't been running sru-accept.py, assumed you would :)
[23:02] <bdmurray> slangasek: okay, I'll do it
[23:02] <bdmurray> slangasek: I'd also approve mono for p-p
[23:03] <slangasek> bdmurray: me-tv, mono accepted
[23:11] <skaet> NCommander,  am heading out for dinner now,  back later.    Feel free to start the respins before I return if all the missing bits have landed.
[23:11] <NCommander> skaet: kernel seems to have cleared new, doing the d-i bits now
[23:15] <skaet> Thanks NCommander
[23:15]  * skaet --> dinner, biab
[23:23]  * infinity had an interwebs hiccup...
[23:24] <infinity> NCommander: If you haven't done d-i yet, I can do it right now.
[23:24] <NCommander> infinity: I did it, just doing test builds ATM
[23:25] <infinity> NCommander: Ahh, yeah, I see the commit.  Alrighty.
[23:26] <NCommander> infinity: when I upload, feel free to give it the shove into the archive
[23:30] <infinity> NCommander: Actually...
[23:31] <infinity> NCommander: You might want to hold off that upload.
[23:31] <NCommander> ?
[23:31] <infinity> Well, the kernel's still building on some arches. :P
[23:31]  * NCommander shakes a fist
[23:32] <infinity> Oh, based on the FTBFS on armel, I bet it's going to do the same on armhf anyway. :/
[23:32] <infinity> Meh.
[23:32] <infinity> Upload away.
[23:39] <jbicha> is seeded-in-ubuntu broken for anyone else? bug 1008783
[23:39] <ubot2`> Launchpad bug 1008783 in ubuntu-dev-tools "seeded-in-ubuntu crashed with IOError in _read_eof(): CRC check failed 0x282b98f1 != 0xdff779cL" [Undecided,New] https://launchpad.net/bugs/1008783
[23:46] <infinity> NCommander: Updated seeds to match your d-i upload (and added highbank as well)
[23:46] <NCommander> infinity: thanks.
[23:46] <NCommander> amd64 test build passed, doing i386 one now
[23:47] <infinity> That seems a bit overly paranoid.
[23:47] <infinity> If one passed, you're probably good.
[23:47]  * NCommander shrugs, and tags an upload
[23:57]  * infinity notes that's the first time in a long time he's seen the urgency field used on an Ubuntu upload...
[23:58] <infinity> Not sure the extra 200 or so that gets you in the buildd queue really matters. :P