[01:08] <sarnold> hello; I'm preparing mysql-5.5 updates. it is my assumption I should prepare the mysql-5.5 for raring in the -security pocket for later release, but I'd like to confirm first that the release team wouldn't rather have it prepared for plain 'raring' for late inclusion.
[01:08] <sarnold> (note that my packages aren't done yet; it's still a hypothetical question at this moment :)
[01:14] <jdstrand> sarnold: let's plan on building in our ppa with raring-security. if the release team says its ok and its worth it, I can copy them to raring-proposed
[01:15] <jdstrand> sarnold: but since they aren't done yet and will need to be tested, this sorta seems like the upload would happen on monday, which is probably too late now that I think about it
[01:16] <sarnold> jdstrand: it does rather push the definition of 'freeze' :)
[01:17] <jdstrand> heh, well, maybe you'll have it ready before then, so I'll let you take it from here (but like I said, I can push to -proposed from the ppa)
[01:33] <ScottK> sarnold: jdstrand's suggestion is good.  If it's ready and we have to respin for other reasons, then it can be copied in.
[01:33] <sarnold> thanks ScottK :)
[01:45] <phillw> ScottK: are the builds planned on the cron the RC's ?
[01:46] <ScottK> We haven't stopped the automatic builds yet, I don't think, plus I think there's a final language pack export to do, so not quite yet I don't think.
[01:46] <ScottK> They are worth testing though so any issues can be identified early.
[01:48] <phillw> ScottK: people do test the dailies, but I do not want to call testers in until RC is ready; I'd rather a delay of 24 hours than the situation of "let's respin the world" :)
[01:49] <ScottK> phillw: I guarantee you there will be respins even after you call for testers.
[01:49] <phillw> ScottK: there always is :D
[01:49] <ScottK> Right, so as long as you say these aren't expected to be final, but close, I think a call for testing wouldn't be a bad idea.
[01:53] <phillw> ScottK: so can I re-phrase that, as my grammer on phasing sentances has been mis understood before (dev-chromium build is one such). when the cron builds tomorrow, will -release team freeze and call them as RC as per http://iso.qa.ubuntu.com/qatracker ?
[01:53] <ScottK> I don't think we've discussed exactly when that is.
[01:53]  * ScottK looks over at infinity.
[01:53] <phillw> 21:00 UTC today.. :)
[01:54] <phillw> but, it's never happened in previous times :D
[02:01] <ScottK> That was the freeze for seeded packages.
[02:01] <ScottK> It's not the time when image building is automatically a candidate.
[02:01] <ScottK> As I mentioned, that's probably a final language pack export to do over the weekend.
[02:02] <phillw> ScottK: okies, so when should we have an RC to test? language pack excepted,
[02:03] <ScottK> It depends on what you mean by that.
[02:03] <ScottK> Up until we stop the cron jobs, it's hard to tell.
[02:03] <ScottK> We aren't going to let seeded package changes in now except for important fixes, so the next build will be close.
[02:04] <phillw> ScottK: okies, the when does -release team expect to alter http://iso.qa.ubuntu.com/qatracker and put on the RC?
[02:04] <ScottK> I don't know.
[02:04] <ScottK> Except there isn't a release candidate milestone.  It'll be release.
[02:05] <phillw> ScottK: so, there is no RC?
[02:05] <ScottK> phillw: It's a candidate until you decide to release it or respin.
[02:05] <phillw> that should be fun to try and test :D
[02:06] <ScottK> It's exactly the way it's been for a couple of years.
[02:06] <ScottK> What we now call beta2, used to be called release candidate, but we changed it because it wasn't a release candidate.
[02:06] <ScottK> No, "release candidate" means exactly what it says.  It's a candidate to be the thing we release.
[02:06] <phillw> ScottK: no, it is not. RC gets put out... it is usually respun a few times, but people are not working on daily.
[02:07] <ScottK> Yes.  A release candidate gets put out and it's either tested good or respun to fix issues.
[02:07] <ScottK> But the milestone is called release
[02:08] <phillw> so, beta2 is now the RC and so any work done on the dailies is useless?
[02:08] <ScottK> No
[02:08] <ScottK> Other way around.
[02:08] <phillw> then, when is the RC released?
[02:08] <ScottK> When we release 13.04.
[02:09] <phillw> ScottK: oh, did they edit https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule without editing it>
[02:09] <phillw> ?
[02:10] <ScottK> No.
[02:10] <ScottK> You're confused about what release candidate means on the schedule.
[02:11] <phillw> ScottK: no, I am not. you guys may be. At what point do you want the maximum amount of testers to land on the RC?
[02:11] <ScottK> Since I'm the one that came up with the current definitions, I'm reasonably certain I understand what I meant.
[02:11] <phillw> ScottK: the rolling release has been dropped, we are back to standard release
[02:12] <ScottK> yes.  We've used what I'm describing for years.
[02:12] <phillw> ScottK: https://wiki.ubuntu.com/ReleaseCandidate
[02:12] <ScottK> Testing soon is good.  There should be an increasing effort over the weekend and then full court press on Monday/Tuesday.
[02:13] <phillw> do read what you wrote>
[02:13] <phillw> I think you will find that was written by Kate.
[02:13] <ScottK> Yes.
[02:14] <ScottK> So?
[02:14] <phillw> So, there is an RC
[02:14] <phillw> when?
[02:15] <ScottK> I give.  You're ignoring what I'm saying and I'm not going to start repeating myself.
[02:17] <phillw> ScottK: okies, let me do the maths backwards?... Release is on 25th of this month? correct?
[02:17] <ScottK> Yes
[02:18] <ScottK> http://www.youtube.com/watch?v=sShMA85pv8M
[02:18] <phillw> ScottK: RC is 7 days before.. https://wiki.ubuntu.com/ReleaseCandidate
[02:18] <ScottK> RC is a milestone in the release process.
[02:18] <ScottK> It's not an image we release.
[02:19] <phillw> https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule
[02:19] <phillw> erm, who edits that page?
[02:20] <ScottK> The release team generally.
[02:20] <phillw> I know for a fact, I cannot
[02:20] <ScottK> You shouldn't.
[02:20] <phillw> then, that is the page which says what the time table is?
[02:21] <phillw> ScottK: I would never dream of doing so.
[02:21] <ScottK> Yes.  That's the page.
[02:21] <phillw> So, what does it say?
[02:22] <phillw> i do not require to watch you-tube. That is the reference page for every one.
[02:23] <ScottK> It says we freeze the archive and start working on release candidates today.
[02:26] <phillw> indeed it does. but you also said that there will be no RC on the iso tracker. I find your answers to be in contadiction and also against the 'rule' that we all know gets broken, which is to give the testers 7 days to crawl all over the RC.
[02:28] <phillw> ScottK: the freeze was 21:00 UTC, we all know that it never 'actually' happens.
[02:28] <ScottK> Of course it does.
[02:28] <ScottK> I just don't think freeze means what you think it means.
[02:29] <ScottK> It doesn't literally mean no more uploads.
[02:31] <phillw> I'm all ears :) By the way, ScottK I'm not giving you a hard time.... I just want to learn this stuff :)
[02:31] <ScottK> It seems like every release you whine about the release team doing last minute respins as if we're just trying to make life difficult for testers.
[02:31] <ScottK> We aren't.
[02:32] <ScottK> After this point we try to constrain updates to seeded packages to those that are really needed for release.
[02:32] <phillw> ScottK: yes, I do. do I have permission to speak freely?
[02:33] <ScottK> Certainly, but you're expectations are not reasonable.
[02:33] <ScottK> Personally, I'm tired of non-constructive criticism.
[02:36] <phillw> ScottK: my expectations are that the release team do not treat testers like mushrooms. things have changed; there is no longer the etherpad for people to look out for up coming re-spins for various bugs. We now are reliant on someone being able to / be bothered to put a note up on the http://iso.qa.ubuntu.com/qatracker
[02:36] <ScottK> I don't recall a respin that wasn't discussed here.
[02:37] <ScottK> It's not a closed channel.
[02:37]  * hyperair wonders what mushrooms are treated like.
[02:37] <ScottK> the Etherpad was a lot of work for little value.
[02:39] <phillw> ScottK: it may come as a shock, but a lot of testers are not logged on here. It is a case of communicating things. In that respect, I can see why ether-pad was not too good, but instead of just dropping it for the discussions, why was it not linked to to "notice" on the iso tracker?
[02:40] <ScottK> There's nothing stopping someone who is here from communicating with testers that aren't.
[02:40] <phillw> We are going to respin xyz, we may respin abc if we get the chance.
[02:41] <ScottK> I can't speak to the mechanics of the ISO tracker and respins since I don't work for Canonical, I don't have access.
[02:43] <phillw> ScottK: you are a tester, I know. just how annoyed would you be if you had spent ~3 hours on various test cases and file them, for them to removed because of a planned re-spin?
[02:43] <ScottK> Sure.  I get it.
[02:44] <ScottK> Someone who wants to figure out how to improve communication should do it.
[02:44] <ScottK> The release team should spoon feed the testers is not a solution.
[02:45] <phillw> ScottK: well, we did have the ether pad, where the release team talked and we could watch. That has been removed. I'm quite sure that the release team still talk, just that the testers have no idea what they are talking about :(
[02:46] <ScottK> I don't understand why following an IRC channel is harder the reading the pad?
[02:49] <phillw> ScottK: not all testers can read everything going on in an IRC area. I certainly will be off-line for most of sunday coming, so cannot even look at IRC logs. On an ether pad, it was always there. As to 'Notice Board' on the iso tracker? Well, I have asked that some one do actually post on there a decision taken on here.
[02:50] <phillw> hyperair: as you will well know... mushrooms are kept in the dark and fed on bull shit.... :P
[02:51] <hyperair> phillw: oh.
[02:51] <hyperair> phillw: i was thinking more along the lines of... eating mushrooms.
[02:51]  * hyperair eats testers for breakfast.
[02:54] <phillw> ScottK: It's late here (nearly 4 am). After the gales last night, me and my dad have been chain-sawing down the trees that blew down from our neighbour to remove further risk..... Which is my way of saying I'm sleepy.
[02:54] <ScottK> I can imagine.
[02:57] <phillw> ScottK: during 13.04 test cycle we have all learned a lot and the testing suite come 13.04 --> 13.10 --> 14.04LTS has made massive strides. Let us not forget the guys and girls who actually take the time out to 'test'. :)
[02:57] <ScottK> I don't.
[03:01] <phillw> ScottK: we may argue like cat and dog. But everyone on this channel actually cares; that is the most important thing :)
[05:31] <infinity> phillw: ReleaseCandidate page on the wiki edited to clear up the confusion and document reality rather than fantasy.
[08:27] <Noskcaj10> half the builds on the iso tracker are for the 19th, half for the 18th. shouldn't they all be up to the 19th now?
[08:28] <stgraber> no
[08:28] <Noskcaj10> ok
[08:31] <cjwatson> The builds run throughout the day; look at etc/crontab in lp:ubuntu-cdimage if you want the full schedule
[08:31] <Noskcaj10> ok, ty.
[08:32] <cjwatson> I might redo this next cycle to be a bit simpler, since we don't have the same builds-must-not-overlap problems we used to, and it ties in with giving the ISO tracker more control over things
[08:32] <cjwatson> ... oh well
[08:32] <cjwatson> 09:32 <cjwatson> I might redo this next cycle to be a bit simpler, since we don't have the same builds-must-not-overlap problems we used to, and it ties in with giving the ISO tracker more control over things
[08:33] <infinity> Comment: NBS
[08:33] <infinity> 307 packages successfully removed.
[08:33] <infinity> ^-- That might be the most I've done in one run.
[08:34] <cjwatson> mm, quite a few flavours there
[10:44] <smartboyhw> Hello Release Team, when will be the first RC images be produced? (Just asking)
[10:48] <stgraber> I don't think we have an answer to that at this time. Currently waiting on langpacks
[10:50] <smartboyhw> Thank you stgraber;)
[13:17] <pitti> hello
[13:17] <pitti> FTR, the network-manager upload in unapproved only adds some new autopkgtests, it doesn't change anything that actually gets built or installed
[13:17] <pitti> (and I verified it with a local VM)
[13:18] <pitti> so that should be safe
[13:26] <jdstrand> fyi, the telepathy-mission-control-5 has an apparmor profile only change which only allows more access for libproxy. I verified it locally
[13:26] <jdstrand> (telepathy-mission-control-5 in unapproved that is)
[14:18] <plars> Do we know when we'll have a release candidate for testing on the iso tracker?
[14:21] <phillw> plars: (11:48:31) stgr@ber: I don't think we have an answer to that at this time. Currently waiting on langpacks
[14:24] <rtg> infinity, re: linux-lts-raring and linux-meta-lts-raring. would you like me to upload them directly to Precise, or would you rather copy them from a PPA (ppa:ubuntu-x-swat/r-lts-backport) ?
[14:24] <balloons> cjwatson can you add the magic to nusakan to ensure the ubuntu touch builds update automatically?
[14:26] <cjwatson> balloons: could you be more specific?
[14:26] <cjwatson> which builds where?
[14:27] <plars> phillw: thanks, missed that
[14:29] <balloons> cjwatson, sure the
[14:29] <balloons> cjwatson, the 'ubuntu touch' family of products; Ubuntu Touch Preinstalled grouper, Ubuntu Touch Preinstalled maguro, Ubuntu Touch Preinstalled mako, Ubuntu Touch Preinstalled manta
[14:30] <cjwatson> balloons: You mean on iso.qa.ubuntu.com?
[14:31] <balloons> cjwatson, yes, I want new builds to be pushed to the isotracker as new builds are created on cdimage
[14:32] <cjwatson> I'll see what I can do
[14:34] <balloons> ty :-)
[14:46] <cjwatson> balloons: we only need this for raring, right?
[14:46] <cjwatson> or $current_development_series I mean
[14:46] <cjwatson> (having both quantal and raring in the same directory is non-standard for cdimage; it would be easier if I only had to deal with raring)
[14:48] <balloons> cjwatson, yes, current development only :-)
[14:50] <cjwatson> ogra_: Could you apply http://paste.ubuntu.com/5721754/ to your sync-phablet-images script, please?  (Patched version in /home/cjwatson/sync-phablet-images if you want to diff against that directly)
[14:50] <cjwatson> ogra_: I'll try the post-qa commands manually
[14:51] <cjwatson> ... seems to work
[14:52] <ogra_> cjwatson, no prob ... given we will likely keep the jenkins builds around for a bit i'll push it to a proper bzr tree too
[14:52] <ogra_> i didnt expect it to last so long :) ... and also didnt expect the sript to gow bigger than 10 lines when i started it
[14:52] <ogra_> *script
[14:52] <cjwatson> I don't want any shell scripts in lp:ubuntu-cdimage though
[14:53] <cjwatson> So if it's going in there it'll need a rewrite in Python
[14:53] <ogra_> no, in its own branch indeed
[14:53] <cjwatson> OK
[14:53] <ogra_> it shouldnt go in there ... it shjould go away :)
[14:53] <ogra_> but as long as we keep jenkins bulds it cant
[14:54] <cjwatson> Yep
[15:30] <bdmurray> I'd like to upload ubuntu-release-upgrader fixing bug 1069745 and it also includes a new base-installer with the highbank / generic change
[15:30] <ubot2> Launchpad bug 1069745 in ubuntu-release-upgrader (Ubuntu) "update-manager fatal error while upgrading from precise to quantal due to Ubuntu.mirrors not being available" [High,In progress] https://launchpad.net/bugs/1069745
[15:33] <stgraber> bdmurray: can't hurt uploading. Do we need this on the release media?
[15:34] <bdmurray> stgraber: no, well except maybe for derivatives that still have an alternate cd
[15:50] <cjwatson> I was expecting to have another run of images anyway ...
[15:54] <stgraber> cjwatson: I'll review ubuntu-release-upgrader now and let it in if it looks good. I'm also planning to do the same for maas unless roaksoax shows some doubts wrt its quality
[15:54] <cjwatson> ack
[15:58] <stgraber> I'm also tempted to accept juju as the changes have already been acked as a FFe and it's unseeded but it'll need an AA to New the binary rename
[16:13] <doko> infinity, once gnat-4.6 migrates, I'll give back the non-superseded builds in the test rebuild
[16:32] <stgraber> above reject was me, I'm not too happy about the way they did the split/rename of the packages (if you were to install juju-0.7 without juju, you wouldn't get any command in the PATH)
[16:35] <slangasek> stgraber: are you also following up with the uploader about getting a proper fix?
[16:56] <stgraber> slangasek: yep, I emailed him
[17:15] <xnox> cjwatson: any idea with respect to git-annex build-failures? I thought it would have just work after completed ghc transition.  Or should we remove armhf & powerpc binaries to transition git-annex?
[17:15] <xnox> Laney: ^
[17:20] <Laney> mmm, dunno, probably worth some investigation
[17:21] <xnox> Laney: "Could not find module `Control.Exception.Extensible'" is really helpful =)
[17:21] <xnox> considering it seems like that is part of base/stadard ghc.
[17:21] <Laney> haskell-extensible-exceptions
[17:22] <Laney> maybe?
[17:25]  * Laney goes away for a bit. We can carry this on in #-motu later if you want.
[17:26] <dobey> can someone approve the rhythmbox-ubuntuone into quantal-proposed and precise-proposed please?
[17:51] <infinity> rtg: If they're coming from a PPA, it should be one that's meant to be used for archive builds (like the kernel PPA).
[17:54] <cjwatson> xnox,Laney: I was in the middle of looking at that.  We shouldn't remove the binaries because it FTBFS on primary arches for exactly the same reason ...
[18:04] <Laney> Alright, cool. I'll make some time to look at it over the weekend if necessary.
[18:04]  * Laney goes out
[18:05] <cjwatson> I'm running the obvious possibility through sbuild now
[18:09] <stgraber> infinity: are you sufficiently awake to look at those fglrx packages?
[18:09] <infinity> stgraber: Yeah, I'll poke them while I pack.
[18:12] <rtg> infinity, then I'll just upload directly to the archive (in a bit)
[18:13] <infinity> rtg: That works too.
[18:27] <cjwatson> Laney: fails with http://paste.ubuntu.com/5722334/
[18:27] <cjwatson> (after adding Build-Depends: libghc-extensible-exceptions-dev)
[19:02] <infinity> rtg: Is the firmware in linux-lts-raring just a temporary measure while you SRU that into linux-firmware?
[19:03] <rtg> infinity, nope, that is a permanent change
[19:03] <infinity> rtg: If they're all new firmware files, why not just have them in linux-firmware, then?
[19:05] <rtg> infinity, getting new files into linux-firmware has been a giant pain in the ass. besides, there are a number of firmware files that are kernel version specific, though they also typically have different file names.
[19:06] <infinity> rtg: But if we ship firmware in the kernel images themselves, those need to be in kernel-versioned directories (to avoid file conflicts), and you end up with multiple copies.
[19:07] <rtg> infinity, they are in /lib/firmware/$(uname -r)
[19:07] <infinity> rtg: And yeah, I realise the SRU process is a bit annoying for completely new firmware files.  We can probably be a bit handwavy about that, since new files don't run the same risks as updating existing ones.
[19:08] <rtg> infinity, did you see my note that these kernel firmware files _are_ in kernel versioned directories ?
[19:09] <infinity> rtg: Yeah, I did.  Doesn't solve the fact that they then end up needlessly duplicated.
[19:09] <rtg> infinity, there is no dupe for the LTS kernels 'cause those files don't exist in the precise linux-firmware package.
[19:10] <infinity> rtg: There's duplication when you have multiple kernels installed.
[19:10] <infinity> And, really, one could make these same arguments about anything we ship in linux-firmware, and I think we'd both agree that moving all the firmware into linux-image would be the wrong thing to do.
[19:10] <infinity> So, doing it selectively still feels suboptimal.
[19:11] <rtg> infinity, compared to the duplication of modules ? we're only talking about a couple of files here, and not all that big to begin with.
[19:11] <infinity> Modules are tied to ABI, firmware isn't.
[19:12] <rtg> infinity, look, I'm fine with adding those files to precise linux-firmware if I can get 'em SRU'd.
[19:12] <infinity> rtg: You can.  Work with me personally on it, and we'll get 'em slipped in.
[19:13] <infinity> rtg: Like I said, *new* firmware files probably shouldn't have the same rigorous SRU validation process, since it usually just comes down to "the file exists" or "the file doesn't exist", rather than testing for regressions.
[19:13] <rtg> infinity, OK, I'll pull those firmware patches from LTS raring once an updated linux-firmware is in place.
[19:14] <rtg> infinity, OK, I'll get started on that.
[19:15] <infinity> Danke.
[19:40] <bdmurray> there is a crash that is first seen with a version of gvfs in quantal -proposed but there isn't a great SRU bug for it as it is a new upstream release
[19:41] <bdmurray> I'd usually just comment on the SRU bug but I'm not sure that's best in this case
[19:42] <rtg> infinity, uploaded precise linux-firmware. I've verified that all are new files since release, except for one BT firmware file fix from an upstream cherry-pick.
[19:42]  * bdmurray talks himself into commenting on the bug
[19:43] <ScottK> bdmurray: That's what I was going to suggest.
[19:43] <ScottK> bdmurray: You might even mark it verification failed.
[19:43] <ogra_> uh, ah .. argh ...
[19:44] <bdmurray> ScottK: I'm going to
[19:44] <ogra_> cjwatson, right after i copied your script over mine i remebered why i didnt use $date
[20:28] <Laney> haha, someone actually did sync that
[20:29] <ScottK> Clearly RC.
[20:29]  * ScottK didn't accept it, but totally would have.
[20:32] <infinity> Laney: I wasn't going to release without it.
[20:33] <Laney> infinity: Indeed. Seeds changed and ubuntu-meta uploaded. Get to promoting.
[20:34] <infinity> Laney: Pfft, we don't need seed changes for me to make it Essential: yes.
[20:36] <phillw> Hi folks, is http://pastebin.com/aV53pqEf okay to send to the testing teams?
[20:37] <infinity> phillw: Pretty much everything from here forward (well, as of today's crons, anyway) could be considered RC material.
[20:38] <infinity> phillw: I'm not sure there's any point in saying "RCs aren't ready yet".  Everything we're producing this week is an RC until we stop spinning and declare a winner.
[20:39] <infinity> phillw: (And the langpacks are in, as of ~8h ago)
[20:39] <phillw> infinity: it is just at each daily, the test results get set back to zero :)
[20:39] <infinity> phillw: Yes, but the goal of testing is to find bugs and fix them, not to pat ourselves on the back for 100% test coverage.
[20:39] <infinity> phillw: If people aren't testing RCs, we won't know if the blessed "final" image sucks.
[20:40] <infinity> phillw: So, I'd rather you just encourage people to test early and often all week, rather than fret over "the RC", of which there is none.
[20:40] <infinity> (Or there are many, depending on how you look at it)
[20:40] <phillw> I agree, but it makes it more difficult to see which ISO's still need testing :)
[20:40] <infinity> All of them.
[20:40] <infinity> And lots.
[20:41] <infinity> Even when something *has* 100% test coverage, it STILL needs testing.
[20:41] <infinity> Because not all testers are created equal, and some do weird things to find new and fun bugs.
[20:41] <infinity> So, really.  Just ask people to beat the crap out of the ISOs over the weekend and file bugs.
[20:41] <phillw> infinity: ooh, don't I know about that!
[20:42] <phillw> infinity: okies, I will do :)
[20:42] <infinity> (This is, really, why I hate blessed milestone images and testing cadences... If more people just performed random abuse of images at random times we wouldn't, for instance, always be scrambling to fix installer bugs at the last minute)
[20:44] <phillw> well, I cannot speak for other teams, but the lubuntu testers constantly test the living daylights out of images :D
[20:45] <phillw> I'll send the email :)
[20:47]  * infinity wonders how he lost his Oyster card...
[20:48] <ScottK> Is that a Canadian thing?
[20:48] <infinity> London.
[22:28] <cjwatson> ogra_: $date> oh?
[22:29] <ogra_> cjwatson, needs to be $date.$counter
[22:30] <ogra_> fixed it already
[22:30] <cjwatson> ogra_: ah yes.  I think that's still better than sed everywhere :)
[22:30] <cjwatson> sorry for missing that
[22:30] <ogra_> thanks for pointing me to it ... :)
[22:31] <cjwatson> balloons: in case ogra_ didn't tell you or you didn't guess, that means that touch images should be posted to iso.qa automatically now
[22:31] <ogra_> there is branches/phablet-sync/ in my home now
[22:34] <ogra_> cjwatson, oh
[22:35] <ogra_> cjwatson, /srv/cdimage.ubuntu.com/log/ubuntu-touch-preview/quantal/phablet-sync-20130419..log
[22:37] <ogra_> ah, crap, i see whats wrong ... my fault, sorry for bothering you
[22:39] <ScottK> I just accepted Block xserver-xorg-video-intel, but put a britney block in place for it.  It looks like a good, but not essential for release fix.  If there's no opportunity to copy it in, then it can be an SRU.
[22:39] <utlemming> inifinity: I think, wtih Windows Azure now GA, we should a tracker item for it
[22:39] <utlemming> infinity: how do we go about getting a Windows Azure item added?
[22:40] <ScottK> utlemming: I'd talk to stgraber.  I think infinity is traveling.
[22:41]  * utlemming feel like an idiot...
[22:41] <utlemming> ScottK: right, I should be talking to stgraber
[22:41] <utlemming> stgraber: around?
[22:41] <cjwatson> ogra_: yeah, looks like $counter is empty ...
[22:42] <ScottK> This is not the release team member you are looking for ....
[22:42] <ogra_> yeah, the mechanism that checks if jenkins has a newer build was tricked
[22:43] <ogra_> since the 19.4 image is actually what 18.1 was ... i had to roll back a few versions on request
[22:43] <ogra_> so indeed the image will always be older now until they build a new one
[22:44] <ogra_> i kind of didnt expect to have to do rollbacks when i wrote the stuff :)
[22:45] <ogra_> (rollbacks with higher version number even)
[22:48] <balloons> cjwatson, :-) ty!