cjwatsoninfinity: d-i changes for linux and linux-ppc in bzr, but I'm not going to upload now since I won't be able to coordinate seed changes overnight; if you feel like doing so then be my guest00:15
infinitycjwatson: There's an incoming linux-ti-omap4 too, plus the better-late-than-never s/omap/generic/ madness, so I'll get it.00:16
hallynhi - has anyone looked into authorizing FFE for bug 1167939 ?02:19
ubot2Launchpad bug 1167939 in libvirt (Ubuntu) "FFE for libvirt 1.0.4" [Undecided,New] https://launchpad.net/bugs/116793902:19
infinityhallyn: The 12MB debdiff attached to that bug is dedicedly unhelpful.03:06
hallyninfinity: yeah it's two releases past what's in raring now.  But it also fixes qemu migration, even breakages in precise03:08
hallynalso has passed all regression tests03:08
hallynthe alternative to fix migration is a qemu update, of course we could just say migration isn't terribly important for the release cd,03:09
hallynand leave the fix for first day that r+1 is open03:09
infinityIf there's a fix that can be cherrypicked, that might be favourable...03:09
hallynfor qemu there is a set that can be cherrypicked (plus my own one-liner which also fixes it :).  though i've only tested a 50-set fix, not the 4 or 6 patches which are supposedly all that is needed.  I point that out bc depending on context, porting 4 qemu patches can take days, or could be 30 secs.03:12
hallyni do wish zul were here to speak up :)03:12
infinityI meant cherrypicks for libvirt.03:13
infinitySince this is working around a qemu bug, right?03:13
infinitySurely, that massive diff and changelog isn't all for the one bug.03:13
hallynit's for 2 releases worth of diff03:15
infinityWell, yes.  I get that.  I'm saying that if the goal here is to fix a bug, that's a whole lot of diff for that.03:16
hallynyeah when i was first workign on it it still seemed early enough to push the whole thing.  at this point not03:17
hallyni'll test the fix backport tomorrow03:18
Mirvhi. could the ubuntu-ui-toolkit 0.1.42 be approved? we'd like to have as up-to-date toolkit in raring archives as possible, and it's also now in sync with the upstream (from which there is a changelog inoptimality, ubuntu-sdk package was already dropped from raring)06:35
Mirvthe documentation updates are probably the most important stuff in addition to marking some API deprecated. the documentation is erronous in the current raring package.06:37
stgraber^ as usual, this one looks way harder to review than it's, just ignore the translation update and the diff will be easy to read ;)08:05
=== doko_ is now known as doko
didrockswhoever reviewed nux, there is the new stack of the day just comming (you can approve both or just one) ^09:16
didrocks(well, one == the latest)09:16
cjwatsonso, after the next LP deployment, there'll be links to the source archive for syncs in the web UI, and a new copy_source_archive property on package_upload objects in the API09:30
didrockscjwatson: oh nice!09:30
didrocksLaney: btw, the unity+music lens contains what we discussed yesterday ^09:31
Laneyok, looking09:31
cjwatsondiffs are going to be a bit harder to fix09:31
Laneymuch easier to construct that yourself now though09:32
cjwatsonyeah, I think it should be possible to have queue/queuediff automate it09:33
cjwatson(though slowly, if you have a narrow pipe)09:33
apwinfinity, linux{-meta,}-lowlatency should now both be in the queue for you delecation and delight09:34
infinitycjwatson: New eglibc uploaded.  Should be a simple/quick review.  But can you do me a favour and not accept it until at least one arch (ppc will likely win) succeeds at https://launchpad.net/~adconrad/+archive/ppa/+packages ?09:37
* infinity needs to attempt a short nap.09:38
infinitycjwatson: I disabled the testsuite in the archive version of the upload (to reduce security team pain), so I'm relying on the PPA to tell me that the world is still vaguely okayish.09:40
infinityIf the glibc testsuite wasn't so effin' sensitive to tiny kernel bumps and moon phase...09:40
Laneyare we sitting on fglrx-installer* for a reason?09:53
Laneydidrocks: will the daily release machinery be fine with me rejecting nux since it has no changes over the archive version?09:58
infinityI was sitting on it while I had a lively debate with tseliot about it.  I think the debate was mostly resolved, but I might want to re-review it what that in mind.09:58
LaneyI'm guessing manual mode makes this ok?09:58
infinitys/what that/with that/09:58
infinityWhich I should do with a fresh slightly-napped brain in the morning.09:59
didrocksLaney: you will need to tweak nux trunk to remove the changelog though09:59
LaneyWould it cause problems to have it there next time?10:00
didrocksLaney: yeah, there is a change from the version in distro, so it will try to rerelease10:00
Laneyeven on manual mode?10:00
Laneywhen you push a whole stack I suppose10:01
didrocksLaney: well, in manual mode, it will be block before publishing10:01
didrocksLaney: but it will still build daily10:01
didrocksto know the current trunk state, running tests…10:01
didrocksLaney: so the best way is to remove the changelog entry in nux trunk10:01
infinityI don't imagine there is/was a plan to do a final release upload of these bits without all the silly versioning?10:01
didrocksinfinity: we will still have daily release and some manual publishing for SRU, so it will still continue to use the same versioning scheme10:02
infinity(Not that versions matter that much, it just looks a bit icky to have VERdailyDATE-MOREVER for everything.10:02
didrocksinfinity: better suggestion welcomed at the sprint to have an easier versioning that covers all the cases :)10:03
infinityIf the intent is for *all* uploads of these items to happen via daily automagic, dropping the "daily" from that string would make it much less icky.10:03
LaneyHmm, it doesn't build daily anyway?10:03
=== smartboyhw_ is now known as smartboyhw
didrocksLaney: it's still building daily if there are changes, and running tests10:03
infinity4. is almost readable.10:03
didrocksLaney: it's just not published to distro without a manual intervention10:03
didrocksinfinity: hard to tell the "upstream" version from the date though10:04
didrocksinfinity: but yeah, that's an option10:04
infinitydidrocks: 4.0.1+13.04.15 then. :P10:04
didrocksit will be btw10:04
infinityOh well.  I guess I should stop thinking of version numbers as something I want to read. :)10:05
infinityEither way, the "daily" string is entirely redundant if it's now in every upload.10:05
didrocksinfinity: agreed, I wanted to make clear automated upload, but I think we can remove it10:05
infinitydidrocks: I think the datestamp makes it clear it's a snapshot of a VCS, how that snapshot got to the archive is less interesting (though the changelog tells the story).10:06
didrocksinfinity: and the + fixes the issue that the . doesn't: dpkg --compare-versions 4.0.1 gt 4.0+13.0410:07
didrocksso + can be acceptable :)10:07
didrocksLaney: going to propose a branch to nux then?10:07
infinityOr, someone can accept that prematurely.  That works too. :P10:08
* infinity shrugs and figures it's probably fine anyway.10:08
Laneydidrocks: I suppose so. Feels quite heavyweight though.10:10
didrocksLaney: well, what would you propose? :-)10:10
LaneyAutomation ;-)10:10
didrocksLaney: like, a reject remove the commit string?10:11
LaneySomething like that10:11
Laneymakes it stop publishing until someone resolves it maybe10:11
didrocksLaney: it seems you want to ack on launchpad ;)10:11
didrocksLaney: stop publishing?10:11
didrocksLaney: we can have manual uploads to ppas meanwhile10:12
didrocksLaney: so additional entry changelog10:12
didrockswe can't force "top entry" == "distro"10:12
Laneythe problem now is that it'll keep uploading/building because it thinks there's a difference to distro?10:12
didrocks(hence it's using -V)10:12
didrocksLaney: right10:12
didrocksbecause there is one10:13
cjwatsoninfinity: wasn't me :-/10:13
infinitycjwatson: Meh.  The diff itself was entirely harmless and really shouldn't have caused regressions.  I was just being paranoid because I haven't built glibc on the buildds with the current toolchain in a while.10:14
Laneydidrocks: Sorry, I can't really come up with an implementation other than to detect rejections and unilaterally block publishing until someone clears it10:17
Laneyor automatically create an MP with the reverse diff, or something10:18
didrocksLaney: yeah, maybe we can create an MP for the reverse diff, but I just want to hilight that process-wise, it's tricky :)10:18
didrocksLaney: let's just do a revert MP, ping me, I'll approve it10:18
Laneywill do10:19
didrocksthanks :)10:19
LaneyI get that there's a load of hairy stuff here but we should try to identify areas where it's more work than the normal process and try to optimise those10:19
seb128Laney, or just approve the most recent upload and be done with it? :p10:20
didrocksseb128: that would have been way easier ;)10:21
didrocksseb128: but I guess, it's too late now :p10:21
Laneyin general there might be cases where you want to reject an upload though10:21
seb128Laney, it's already built, it's not even going to waste builder time...10:21
seb128Laney, right, in which case you get to do the extra work10:21
seb128Laney, which you could easily spare here ;-)10:21
LaneyIdeally I wouldn't have to treat these packages any differently to any other upload10:22
stgraberinfinity: I did the accept for eglibc as I didn't see any "don't accept" message on IRC. The diff looked good, matched the changelog and the diffs linked on those bugs. If you don't want stuff accepted, don't upload them ;)10:22
infinitystgraber: A little under an hour ago in scrollback, but not a big deal.  I was just being overly paranoid combined with wanting it built while I was asleep.10:23
seb128Laney, I've issue with people who only accept one of the uploads in the queue, it made me have some bugs not autoclosed this week10:24
seb128Laney, what's the issue with just accepting 2 versions together when they are stacked in the queue? the publisher should deal just fine with those10:24
LaneyIt's pointless to have it in the history of the package10:25
stgraberinfinity: ah, sorry missed that one as it was directed at cjwatson and before queuebot registered the upload.10:25
seb128Laney, well, it's part of the upload history...10:25
infinityNot to the archive, it isn't.10:25
seb128like it's tagged etc in the vcs10:25
infinityAnd, more to the point, saying that an AA who has a valid reason to reject something is then responsible for doing extra work to propose an MP to revert the thing he was rejecting for is silly.10:26
stgraberinfinity: anyway, looks like ppc succeeded10:26
seb128infinity, what's the cost of accepting 2 versions together? is there any side effect?10:26
cjwatsonseb128: err, remember that people looking at the queue may not necessarily be immediately aware that uploads are "stacked"10:26
infinitystgraber: Indeed.  <3 sagari.10:26
cjwatsonI often contribute small amounts of effort at a time to queue review; if you tell me that I have to assess the entire queue before accepting anything, I just won't do it10:26
infinitystgraber: Shame the archive build will take 10 times as long. :P10:27
seb128cjwatson, well, if there are e.g 2 nautilus revision in the queue and you review the most recent one and ack it, what happen to the older one?10:27
cjwatsonand bugs not being autoclosed for all intermediate versions is an LP bug which you should report, IMO10:27
cjwatsonhm, well, maybe.  complex.10:28
cjwatsonseb128: the rules are unclear10:28
seb128cjwatson, well, closing is done from the .changes, so in theory whoever upload should -v from the current archive version I guess10:28
stgraberinfinity: it's almost tempting to switch the other ppc builders to manual once we hit final freeze so that anything that needs to get built will at least build quickly ;)10:28
seb128cjwatson, but in practice when people work from a Vcs they just work and upload without checking the queue to see if they need -v10:28
cjwatsonseb128: but you saying you have an issue "with people who ..." is unhelpful10:28
infinitystgraber: For small packages, they're actually faster than sagari, due to sagari's crap bandwidth in Boston.10:29
infinitystgraber: So, it's a crap shoot until that gets resolved.10:29
infinitystgraber: (But if we need an emergency linux-ppc or gcc or libreoffice or whatever, I'll aim it at sagari, yeah)10:29
cjwatsonI cleaned up most of the reasons why -v is necessary for SRUs; it would probably be worth looking at it for dev-series uploads too10:29
seb128cjwatson, it's maybe not rightly phrased, but what would be wrong saying "if you accept the most recent revision on a package in the queue, accept the previous revision for it that are in the queue at the same time"10:29
stgraberinfinity: hopefully the shiny new calxeda hardware being installed in Lexington will make the priority of that RT even higher, because having to wait 30min for every armhf upload won't be fun at all10:29
seb128cjwatson, e.g just "queue accept <source>"10:30
cjwatsonseb128: I can understand why people don't want to default to that behaviour, because it can be a considerable amount of build time10:30
cjwatsonit's not something you can always do10:30
infinitystgraber: Exactly.  I'm using that very thing as leverage to get that ticket looked at a bit harder.10:30
seb128cjwatson, builders are smart enough usually, from what I saw, to not try to build old versions when there is a new one accepted10:30
cjwatsonno they aren't10:30
infinityThey really aren't.10:31
seb128ok, wrong observation then ;-)10:31
Laneyis that even guaranteed to work, given proposed-migration?10:31
infinityThey won't build for source that's marked "superseded", but that only happens AFTER the new one is published.10:31
cjwatsonand if the intermediate version was broken and you get unlucky with builder speeds, you can end up introducing broken stuff into -proposed which breaks other builds10:31
infinitySo there's a massive window there where you can build seven versions of the same source. :P10:31
=== ara_ is now known as ara
cjwatsonso it's really not as simple as "just accept both10:31
cjwatsonI'd rather try to make -v unnecessary10:31
seb128cjwatson, I guess the best fix then would be to teach launchpad to close... what you are saying10:31
seb128should I open a bug about that against launchpad?10:32
cjwatsonbut it does interact in a complicated way with the semantics of Launchpad-Bugs-Closed10:32
LaneySay both are built/published in proposed at the same time, I assume that proposed-migration will ignore the older version10:32
infinityLaney: Two can't be published together.10:32
cjwatsonperhaps the right approach is to supersede old versions earlier or something10:32
Laneyinfinity: what happens?10:32
infinityLaney: If both build in the same publisher cycle, only the newer one will get published.10:33
LaneySo, same effect then10:33
cjwatsonseb128: I'd like a bug about the general situation please, but it might be best not to suggest a single solution to it, as I think a proper solution will require some thought10:33
LaneyOnly the newer LP-Bugs-Fixed gets considered10:33
infinityLaney: But none of that prevents the build from happening, just gurantees archive sanity after the fact.10:33
cjwatsonwe might want to talk about this at the release team sprint if that ever happens10:33
LaneyI'm trying to argue that it doesn't even work in most cases, buildd time wasting notwithstanding10:33
infinitycjwatson: AFAIK, it's happening, though we've failed to set a date.10:34
infinityLaney: Oh, I see what you're driving at.  Since source copies from proposed to release are what triggers bug closures.10:34
cjwatsonno, it works a bit better than that10:34
infinityThough that should be the same flow/usecase that Colin fixed for SRUs.10:34
infinityIn theory.10:35
LaneyUnless it unions LP-Bugs-Fixed10:35
cjwatsonit does10:35
cjwatsonon copy from proposed to release, it walks back through the ancestry to the most recent version in release and looks at all the .changes files10:35
cjwatsonI think10:36
cjwatsonactually, I think on copy it might reparse the changelog, which is arguably wrong ...10:36
cjwatsonbut in practice mostly has the same effect10:36
cjwatsonI think some confusion about semantics has crept in along the way10:37
infinityTsk, tsk, parsing the changelog...10:37
cjwatsonYeah.  But it *could* walk the .changes. :-P10:37
* infinity doesn't want to admit that he's manually twiddles .changes to fix a bug closure on a source package he didn't want to re-pack.10:37
cjwatsonYou're supposed to be allowed to do that :)10:38
infinityI've also done that with Debian fakesyncs, adding LP bug closures to .changes where they weren't previously.10:38
infinityThat was back when I was far less lazy than I am now.10:38
* Laney accepts compiz despite the slightly borked changelog10:38
Laneyclaiming to close a bug that it actually reopens10:38
cjwatsonAnyhow, I think the only way to get to what seb128 wants while preserving correct Launchpad-Bugs-Fixed semantics would be to accept all the intermediate uploads and arrange not to build them10:39
seb128cjwatson, https://bugs.launchpad.net/launchpad/+bug/117030110:39
ubot2Launchpad bug 1170301 in Launchpad itself "It would be nice to have bugs-autoclosing working for intermediate revisions non accepted to the archive but included in a new upload" [Undecided,New]10:39
infinityWe need syntax for "reopens:" (Debian) and "UNLP:"...10:39
infinitycjwatson: That only works if you accept the newest first, then you could immediately superses the others as you accept.10:40
* Laney claims a DEP number for that10:40
infinity(Though, right now, I think they'd just fall into a reject/fail loop if you went in that order)10:40
infinityLaney: Go for it.  It's annoyed me for a while that you just have to do an intentionally broken-syntax bug reference in your changelog and manually reopen.10:41
LaneyOh crap, I was joking. /me goes dark10:41
cjwatsoninfinity: Works the other way round too if either (a) you manage to accept them all before the first starts building or (b) we have the ability to reliably cancel builds10:42
infinitycjwatson: I can make (b) one of my top priorities right after release.10:42
cjwatsonplease do :)10:42
cjwatsonI'd love to have that10:42
infinitycjwatson: (a) seems unlikely, given that we kinda want to make things faster, not slower.10:42
infinityTotally time for a new buildd-manager rewrite.10:43
cjwatsonYeah, though it's probably the common case right now10:43
LaneyDo you mean automatically cancelling builds when the source becomes superseded?10:43
infinityAnd that's valuable regardless.10:43
cjwatsonWhich depends on the ability to cancel builds at all without ops intervention10:43
LaneyThat would be suhweeeeeeeeeeeeeet10:43
cjwatson(non-PPA builds, that is)10:43
infinityAnyhow, I've been experimenting with webops to make sure that my proposed method for build killery is vaguely foolproof, and it should be.10:44
infinitySo I just need to hook it into the right spots.10:44
infinityAnd unbugger buildd-manager to not be so mind-numbingly stupid.10:44
cjwatsonIs that the sbuild kill-all-children approach?10:44
infinitycjwatson: That approach no workie, misses processes that get reparented.10:44
infinitycjwatson: This is the "walk /proc and slaughter everything in the chroot" approach.10:45
infinityAaanyway.  I was meant to be napping an hour ago.  I should get to that before the sun comes up and says mean things to me.10:46
infinityJerk sun.10:46
cjwatsonah yes ok10:48
cjwatsonwe should start accumulating things to do at the release sprint in a more structured way than "in our heads"10:48
infinityStart a google doc and lose the URL.10:49
infinityAlternately, start a mail thread.  I hear those used to work back in the dark ages of last year.10:49
cjwatsonor I hear we have a wiki10:57
cjwatsonCan somebody look at localechooser in NEW?  I'd like to upload a ubiquity containing it.13:20
cjwatsonEr, in UNAPPROVED that is13:20
* cjwatson grabs another translation export13:25
seb128tjaalton, slangasek, Laney: the libgl1-mesa-dri update makes unity segfault on start in vms13:37
seb128go for new versions just before hard freeze :/13:37
cjwatsondoes that include the one in the queue?13:40
seb128cjwatson, no, current raring13:42
seb128cjwatson, I can try building the one in the queue13:43
cjwatsonI asked on #ubuntu-devel13:43
cjwatsonbut would be good to know13:43
* cjwatson goes for lunch13:43
seb128cjwatson, trying a build, thanks13:44
seb128libgl1-mesa-dri_9.1.1-0ubuntu3~ppa1_i386.deb from https://launchpad.net/~mlankhorst/+archive/ppa/+build/4501757 fixes the issue13:47
didrocksLaney: you didn't review unity-lens-music on purpose?13:48
didrocksLaney: as it's the second part for the FFe/UIFe :)13:49
Laneyperhaps I missed it or it appeared after I did the otehrs13:49
didrocksLaney: should have been at the same time than the rest :)13:49
Laneyanyway, give me 513:51
didrocksLaney: high five! :)13:54
kenvandineLaney, can you please reject ubuntu-ui-toolkit 0.1.42 and take a look at 0.1.43?14:28
kenvandineit has some important fixes14:28
Laneyyes and no(t immediately) - going for lunch now14:28
kenvandinesure :)14:28
kenvandineenjoy your lunch :)14:28
Laneystgraber: ↑? :-)14:28
* Laney runs14:28
stgraberLaney: in a meeting but I'll try to take a look during/after it14:30
kenvandinestgraber, thanks14:31
stgraberkenvandine: do you have some kind of standing freeze exception for ubuntu-ui-toolkit?15:06
kenvandineMirv, ^^15:07
stgraberkenvandine: also you appear to have included debian/bzr-builddeb.conf in that source package. I thought this was being sripped when using "bzr bd -S". Won't cause any problem, just noticed it in the review.15:08
kenvandineoh, yeah i thought that got stripped15:09
kenvandinestgraber, i pulled bug fixes in from trunk since 0.1.42, which had been sitting in the queue15:10
kenvandinebut there are features before that15:10
kenvandineand since last upload...15:10
stgraberright, 0.1.43 on its own would be fine, 0.1.42 not so much, unless there was some kind of agreement that this package wasn't subject to feature freeze15:12
LaneyI don't think there was15:18
kenvandinestgraber, there was a FFe bug 115719115:20
ubot2Launchpad bug 1157191 in ubuntu-ui-toolkit (Ubuntu) "[FFe] API updates for MainView, PageStack and Tabs " [Medium,Fix released] https://launchpad.net/bugs/115719115:20
kenvandineand part of those changes include fixes related to that15:20
kenvandinea couple bugs and documentation fixes15:20
kenvandineit looks like the only real feature in there is the Icon component15:20
kenvandinein 0.1.3915:20
kenvandineoh, theming engine too15:21
kenvandinebut that actually fixed a pile of style bugs...15:21
stgraberyeah, there's also:15:30
stgraber+    - Added "make license" target15:30
kenvandinestgraber, that is just for adding a test in the build15:32
kenvandinei don't think that changes the resulting packaging15:32
stgraberah ok, that wasn't clear from the changelog15:32
kenvandinesorry :)15:32
kenvandineit is for a checklicense test that CI does15:32
kenvandinemakes sure all the files have the right copyright and license in the header15:33
rbasakIs there still interest in FTBFS fixes for unseeded packages in Raring? Or shall I leave these now? And is there an easy way of determining if a given source package is unseeded?15:33
stgraberso, who exactly is using that package at the moment? I see it's not shipped on any of our media15:34
stgraberrbasak: we're still interested in FTBFS fixes. You can use seeded-in-ubuntu to check if it's seeded or not15:34
kenvandinestgraber, it is in universe and the only package that uses it is friends-app15:34
stgraberrbasak: if you find out that a package that FTBFSed is actually seeded, then it's a reason to fix it ASAP, not to ignore it because we're about to freeze ;)15:34
rbasakstgraber: OK, great. And I didn't know about seeded-in-ubuntu - thanks!15:34
rbasakAh - good point.15:35
dtchenrbasak: yeah, i could really use some help with them :)15:35
stgraberkenvandine: ok, and is friends-app broken without the new version?15:35
kenvandinestgraber, so very low risk and most of the fixes in 0.1.43 fix bugs reported in friends-app15:35
kenvandineyeah, there are some textinput bugs15:35
kenvandinewhich this fixes15:35
kenvandineand the theming change too15:36
kenvandinethat fixes bugs found in friends-app15:36
stgraberok, so on the basis that the theming engine change makes it work for you (as opposed to breaking the world), I think I'm fine with this. Letting it through.15:37
kenvandinestgraber, thx15:38
=== smartboyhw is now known as Guest42028
hallynstgraber: infinity: ok, it seems the tiny debdiff at http://people.canonical.com/~serge/libvirt-migrate.debdiff fixes the libvirt-qemu migration bug 115762616:14
ubot2Launchpad bug 1157626 in qemu (Ubuntu) "Unable to use "virsh migrate" on two hosts after moving to raring" [High,Triaged] https://launchpad.net/bugs/115762616:14
hallynI'm startign a set of regression tests, which should be done in an hour...  but i don't expect failures from that16:14
hallynthat would replacethe (obviously now too late) FFE request for libvirt version 1.0.4 for raring16:15
smartboyhw_Just asking: Is FinalFreeze on 21:00 UTC today?16:16
* hallyn back in a bit16:18
stgraberhallyn: maybe expand the changelog entry a bit, but if that's confirmed to work and not cause any regression, I'm happy to accept this into raring16:19
dokoDaviey, some weeks ago you did promise to look at the server related ones here ... http://people.canonical.com/~ubuntu-archive/component-mismatches.txt16:31
slangasekdoko: Daviey is at ODS this week, so you probably won't get much of a response16:41
dokoahh, ok16:41
hallynstgraber: http://people.canonical.com/~serge/libvirt-migrate-v2.debdiff    all tests passed17:11
stgraberhallyn: cool, go ahead with the upload17:14
hallynstgraber: great, thanks17:14
infinityhallyn: Ahh, thanks for that cherrypick.  A 5-line diff seems slightly less scary than a 12MB one. :)17:23
=== mmrazik is now known as mmrazik|afk
* infinity raises his brow at queuebot.19:03
ogra_oh, cool, we have netboot touch images !19:09
rsalvetiyeah \o/19:09
ogra_infinity, that was sergiusens adding the touch image testcases ... seems the netboot shouldnt really be there19:10
sergiusensinfinity: that was balloons creating a tag for us to test the Ubuntu Touch builds19:10
sergiusenson isotracker19:10
balloonsI don't know who added netboot19:10
balloonsthat was random..19:10
* ogra_ shakes his fist at Mr. random 19:12
ogra_evil guy you !19:12
ogra_stgraber, ^^^ can you probaby filter that from queuebot ?19:12
ogra_(i guess all touch images , not only netnboot)19:13
* balloons took care of netboot and mr. random (he hopes)19:13
stgraberballoons: netboot is autoadded by my script, I need to make it aware of touch images ;)19:14
ogra_better make it unaware ... i doubt to want to spam release with it yet19:15
balloonsstgraber, I figured as much :-)19:22
stgraberogra_: well, it's two things. I had to make my d-i monitoring script unaware of Touch so that it doesn't automatically add Netboot images to that milestone, then patch queuebot to stop spamming #ubuntu-release with the touch stuff19:22
ogra_stgraber, yeah19:23
infinitystgraber: Want to poke at that kmod?  It's just swapping our patches for upstream's.19:26
infinity(And taking back TILM, so I don't misplace it later... *cough*)19:27
stgraberinfinity: sure, taking a look now19:32
infinityIt probably instills very little confidence that I'm always pleasantly surprised when one of my glibc upgrades goes smoothly, doesn't it?19:35
stgraberinfinity: are you sure we're not using that nfs4/nfs alias?19:35
infinitystgraber: We're not using that alias file at all, so no. :P19:35
infinity(Not using is it part of our delta elsewhere in debian/rules)19:36
stgraberinfinity: good ;)19:36
infinitys/is it/it is/19:36
infinityWe probably should look at that at some point, but my kmod packaging goal in R was to make it look as close to identical to our m-i-t packaging as possible.19:37
stgraberinfinity: and you didn't feel like listing our delta in the changelog of the merge? (would have saved you the question) :)19:37
infinityFor S, I may revisit our delta with Debian (and Debian's with upstream) and see what we're intentionally missing that might be of value.19:38
infinity(Like the 1700 foo.d directories littered all over the FHS namespace)19:38
infinitystgraber: I have a severe distaste for reiterating "merged; remaining changes:" on every 5-line-change upload.19:39
infinitystgraber: I do it at what feels like natural reset points (like new upstream versions, or whatever... Basically, when all the patches get mangled and the delta needs reviewing)19:39
infinityHrm, freeze in 1:19.19:41
infinityHere's hoping everyone's happy with their packages.19:41
stgraberI still have a last minute lxc upload to do, waiting for a quick review by barry though19:42
balloonsstgraber, ty. just make sure the builds are still being pushed for touch :-)19:46
barrystgraber: ha! i just sent the ack19:48
infinityI still have a last-minute d-i upload to do, I need to get to mangling that. :/19:49
barrybdmurray: needs to upload ubuntu-release-upgrader19:50
bdmurrayspeaking of that could someone have a look at bug 457221?  I was just gonna remove cups-pdf from ForcedObsoletes19:51
ubot2Launchpad bug 457221 in ubuntu-release-upgrader (Ubuntu) "cups-pdf always classed as OBSOLETE and removed during update-manager process." [Medium,Triaged] https://launchpad.net/bugs/45722119:51
bdmurrayalthough its not that important19:52
bdmurraystgraber, infinity: ^19:54
infinitybdmurray: Huh.  ForcedObsolete seems a bit heavyhanded if it was just unseeded.  I wonder what the rationale was.20:05
infinityIf it works and doesn't horribly conflict with other things and is still in the archive (the latter is at least true), that seems silly.20:06
bdmurraymaybe there was some thing else wrong with it?20:06
infinityWell, if it's fundamentally asplodey broken, it shouldn't be in the archive, IMO.20:06
bdmurrayRight, I meant the Intrepid version of it.20:06
infinityBut it looks like it was just removed from desktop seeds, and someone decided that meant no one should ever have it installed EVAR.20:07
infinity(Which is silly, since the upgrader already does the "here's a list of stuff no longer supported" check)20:07
infinitybdmurray: Anyhow, ACK on fixing that in your next release-upgrader upload.20:07
stgraberso if someone is actually reading through the lengthy python patch in lxc, it's a cherry-pick of the following upstream commits:20:51
phillwstgraber: I'll have to have a read up on lxc, I'm very interested in learning it! FYI, on https://help.ubuntu.com/community/LXC the 2nd link gives a 404 error.21:09
balloonsyou can edit to just http://lxc.sourceforge.net/21:12
phillwballoons: as it seems stgraber knows about lxc and has made the 3 most recent edits. I use my 'do not edit stuff on wiki's you do not understand' clause :)21:14
stgraberinfinity: any chance you can review lxc?21:19
infinitystgraber: Too bad, we're frozen.21:19
infinitystgraber: (Yeah, I'll look in a second)21:19
stgraberhehe, we may have sucky audit trail on that stuff, but we at least have a timestamp ;)21:20
stgraberI'm looking at the nexus7 kernel21:21
stgraberhmm, I wonder why rtg removed all the content of an old UNRELEASED changelog entry but not the entry itself...21:23
=== hggdh_ is now known as hggdh

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!