| cjwatson | infinity: 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 guest | 00:15 |
|---|---|---|
| infinity | cjwatson: 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 |
| cjwatson | Righto | 00:16 |
| hallyn | hi - has anyone looked into authorizing FFE for bug 1167939 ? | 02:19 |
| ubot2 | Launchpad bug 1167939 in libvirt (Ubuntu) "FFE for libvirt 1.0.4" [Undecided,New] https://launchpad.net/bugs/1167939 | 02:19 |
| infinity | hallyn: The 12MB debdiff attached to that bug is dedicedly unhelpful. | 03:06 |
| hallyn | infinity: yeah it's two releases past what's in raring now. But it also fixes qemu migration, even breakages in precise | 03:08 |
| hallyn | also has passed all regression tests | 03:08 |
| hallyn | the 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 |
| hallyn | and leave the fix for first day that r+1 is open | 03:09 |
| infinity | If there's a fix that can be cherrypicked, that might be favourable... | 03:09 |
| hallyn | for 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 |
| hallyn | i do wish zul were here to speak up :) | 03:12 |
| infinity | I meant cherrypicks for libvirt. | 03:13 |
| infinity | Since this is working around a qemu bug, right? | 03:13 |
| infinity | Surely, that massive diff and changelog isn't all for the one bug. | 03:13 |
| hallyn | it's for 2 releases worth of diff | 03:15 |
| infinity | Well, 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 |
| hallyn | yeah when i was first workign on it it still seemed early enough to push the whole thing. at this point not | 03:17 |
| hallyn | i'll test the fix backport tomorrow | 03:18 |
| Mirv | hi. 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 |
| Mirv | the 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 | ||
| didrocks | whoever 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 |
| cjwatson | so, 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 API | 09:30 |
| Laney | excellent | 09:30 |
| didrocks | cjwatson: oh nice! | 09:30 |
| didrocks | Laney: btw, the unity+music lens contains what we discussed yesterday ^ | 09:31 |
| Laney | ok, looking | 09:31 |
| cjwatson | diffs are going to be a bit harder to fix | 09:31 |
| Laney | much easier to construct that yourself now though | 09:32 |
| cjwatson | yeah, I think it should be possible to have queue/queuediff automate it | 09:33 |
| cjwatson | (though slowly, if you have a narrow pipe) | 09:33 |
| apw | infinity, linux{-meta,}-lowlatency should now both be in the queue for you delecation and delight | 09:34 |
| infinity | cjwatson: 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 | |
| cjwatson | ok | 09:39 |
| infinity | cjwatson: 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 |
| infinity | If the glibc testsuite wasn't so effin' sensitive to tiny kernel bumps and moon phase... | 09:40 |
| Laney | are we sitting on fglrx-installer* for a reason? | 09:53 |
| Laney | didrocks: will the daily release machinery be fine with me rejecting nux since it has no changes over the archive version? | 09:58 |
| infinity | I 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 |
| Laney | I'm guessing manual mode makes this ok? | 09:58 |
| infinity | s/what that/with that/ | 09:58 |
| infinity | Which I should do with a fresh slightly-napped brain in the morning. | 09:59 |
| didrocks | Laney: you will need to tweak nux trunk to remove the changelog though | 09:59 |
| Laney | Would it cause problems to have it there next time? | 10:00 |
| didrocks | Laney: yeah, there is a change from the version in distro, so it will try to rerelease | 10:00 |
| Laney | even on manual mode? | 10:00 |
| Laney | when you push a whole stack I suppose | 10:01 |
| didrocks | Laney: well, in manual mode, it will be block before publishing | 10:01 |
| didrocks | Laney: but it will still build daily | 10:01 |
| didrocks | to know the current trunk state, running tests… | 10:01 |
| didrocks | Laney: so the best way is to remove the changelog entry in nux trunk | 10:01 |
| infinity | I don't imagine there is/was a plan to do a final release upload of these bits without all the silly versioning? | 10:01 |
| didrocks | infinity: we will still have daily release and some manual publishing for SRU, so it will still continue to use the same versioning scheme | 10:02 |
| infinity | (Not that versions matter that much, it just looks a bit icky to have VERdailyDATE-MOREVER for everything. | 10:02 |
| didrocks | infinity: better suggestion welcomed at the sprint to have an easier versioning that covers all the cases :) | 10:03 |
| infinity | If 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 |
| Laney | Hmm, it doesn't build daily anyway? | 10:03 |
| === smartboyhw_ is now known as smartboyhw | ||
| didrocks | Laney: it's still building daily if there are changes, and running tests | 10:03 |
| infinity | 4.0.1.13.04.15-0ubuntu1 is almost readable. | 10:03 |
| didrocks | Laney: it's just not published to distro without a manual intervention | 10:03 |
| didrocks | infinity: hard to tell the "upstream" version from the date though | 10:04 |
| didrocks | infinity: but yeah, that's an option | 10:04 |
| infinity | didrocks: 4.0.1+13.04.15 then. :P | 10:04 |
| didrocks | it will be 4.0.1.13.04.15~13.04-0ubuntu1 btw | 10:04 |
| infinity | Ew. | 10:04 |
| infinity | Oh well. I guess I should stop thinking of version numbers as something I want to read. :) | 10:05 |
| infinity | Either way, the "daily" string is entirely redundant if it's now in every upload. | 10:05 |
| didrocks | infinity: agreed, I wanted to make clear automated upload, but I think we can remove it | 10:05 |
| infinity | didrocks: 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 |
| didrocks | infinity: and the + fixes the issue that the . doesn't: dpkg --compare-versions 4.0.1 gt 4.0+13.04 | 10:07 |
| didrocks | so + can be acceptable :) | 10:07 |
| didrocks | Laney: going to propose a branch to nux then? | 10:07 |
| infinity | Or, someone can accept that prematurely. That works too. :P | 10:08 |
| * infinity shrugs and figures it's probably fine anyway. | 10:08 | |
| Laney | didrocks: I suppose so. Feels quite heavyweight though. | 10:10 |
| didrocks | Laney: well, what would you propose? :-) | 10:10 |
| Laney | Automation ;-) | 10:10 |
| didrocks | Laney: like, a reject remove the commit string? | 10:11 |
| Laney | Something like that | 10:11 |
| Laney | makes it stop publishing until someone resolves it maybe | 10:11 |
| didrocks | Laney: it seems you want to ack on launchpad ;) | 10:11 |
| didrocks | Laney: stop publishing? | 10:11 |
| didrocks | Laney: we can have manual uploads to ppas meanwhile | 10:12 |
| didrocks | Laney: so additional entry changelog | 10:12 |
| didrocks | we can't force "top entry" == "distro" | 10:12 |
| Laney | the 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 |
| didrocks | Laney: right | 10:12 |
| didrocks | because there is one | 10:13 |
| cjwatson | infinity: wasn't me :-/ | 10:13 |
| infinity | cjwatson: 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 |
| Laney | didrocks: Sorry, I can't really come up with an implementation other than to detect rejections and unilaterally block publishing until someone clears it | 10:17 |
| Laney | or automatically create an MP with the reverse diff, or something | 10:18 |
| didrocks | Laney: 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 |
| didrocks | Laney: let's just do a revert MP, ping me, I'll approve it | 10:18 |
| Laney | will do | 10:19 |
| didrocks | thanks :) | 10:19 |
| Laney | I 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 those | 10:19 |
| seb128 | Laney, or just approve the most recent upload and be done with it? :p | 10:20 |
| didrocks | seb128: that would have been way easier ;) | 10:21 |
| didrocks | seb128: but I guess, it's too late now :p | 10:21 |
| Laney | in general there might be cases where you want to reject an upload though | 10:21 |
| seb128 | Laney, it's already built, it's not even going to waste builder time... | 10:21 |
| seb128 | Laney, right, in which case you get to do the extra work | 10:21 |
| seb128 | Laney, which you could easily spare here ;-) | 10:21 |
| Laney | Ideally I wouldn't have to treat these packages any differently to any other upload | 10:22 |
| stgraber | infinity: 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 |
| infinity | stgraber: 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 |
| seb128 | Laney, I've issue with people who only accept one of the uploads in the queue, it made me have some bugs not autoclosed this week | 10:24 |
| seb128 | Laney, what's the issue with just accepting 2 versions together when they are stacked in the queue? the publisher should deal just fine with those | 10:24 |
| Laney | It's pointless to have it in the history of the package | 10:25 |
| stgraber | infinity: ah, sorry missed that one as it was directed at cjwatson and before queuebot registered the upload. | 10:25 |
| seb128 | Laney, well, it's part of the upload history... | 10:25 |
| infinity | Not to the archive, it isn't. | 10:25 |
| seb128 | like it's tagged etc in the vcs | 10:25 |
| infinity | And, 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 |
| stgraber | infinity: anyway, looks like ppc succeeded | 10:26 |
| seb128 | infinity, what's the cost of accepting 2 versions together? is there any side effect? | 10:26 |
| cjwatson | seb128: err, remember that people looking at the queue may not necessarily be immediately aware that uploads are "stacked" | 10:26 |
| infinity | stgraber: Indeed. <3 sagari. | 10:26 |
| cjwatson | I 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 it | 10:26 |
| infinity | stgraber: Shame the archive build will take 10 times as long. :P | 10:27 |
| seb128 | cjwatson, 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 |
| cjwatson | and bugs not being autoclosed for all intermediate versions is an LP bug which you should report, IMO | 10:27 |
| cjwatson | hm, well, maybe. complex. | 10:28 |
| cjwatson | seb128: the rules are unclear | 10:28 |
| seb128 | cjwatson, well, closing is done from the .changes, so in theory whoever upload should -v from the current archive version I guess | 10:28 |
| stgraber | infinity: 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 |
| seb128 | cjwatson, but in practice when people work from a Vcs they just work and upload without checking the queue to see if they need -v | 10:28 |
| cjwatson | seb128: but you saying you have an issue "with people who ..." is unhelpful | 10:28 |
| infinity | stgraber: For small packages, they're actually faster than sagari, due to sagari's crap bandwidth in Boston. | 10:29 |
| infinity | stgraber: So, it's a crap shoot until that gets resolved. | 10:29 |
| infinity | stgraber: (But if we need an emergency linux-ppc or gcc or libreoffice or whatever, I'll aim it at sagari, yeah) | 10:29 |
| cjwatson | I cleaned up most of the reasons why -v is necessary for SRUs; it would probably be worth looking at it for dev-series uploads too | 10:29 |
| seb128 | cjwatson, 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 |
| stgraber | infinity: 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 all | 10:29 |
| seb128 | cjwatson, e.g just "queue accept <source>" | 10:30 |
| cjwatson | seb128: I can understand why people don't want to default to that behaviour, because it can be a considerable amount of build time | 10:30 |
| cjwatson | it's not something you can always do | 10:30 |
| infinity | stgraber: Exactly. I'm using that very thing as leverage to get that ticket looked at a bit harder. | 10:30 |
| seb128 | cjwatson, builders are smart enough usually, from what I saw, to not try to build old versions when there is a new one accepted | 10:30 |
| cjwatson | hahahahahahaha | 10:30 |
| cjwatson | no they aren't | 10:30 |
| infinity | They really aren't. | 10:31 |
| seb128 | ok, wrong observation then ;-) | 10:31 |
| Laney | is that even guaranteed to work, given proposed-migration? | 10:31 |
| infinity | They won't build for source that's marked "superseded", but that only happens AFTER the new one is published. | 10:31 |
| cjwatson | and 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 builds | 10:31 |
| infinity | So there's a massive window there where you can build seven versions of the same source. :P | 10:31 |
| === ara_ is now known as ara | ||
| cjwatson | so it's really not as simple as "just accept both | 10:31 |
| cjwatson | " | 10:31 |
| cjwatson | I'd rather try to make -v unnecessary | 10:31 |
| seb128 | cjwatson, I guess the best fix then would be to teach launchpad to close... what you are saying | 10:31 |
| seb128 | should I open a bug about that against launchpad? | 10:32 |
| cjwatson | but it does interact in a complicated way with the semantics of Launchpad-Bugs-Closed | 10:32 |
| Laney | Say both are built/published in proposed at the same time, I assume that proposed-migration will ignore the older version | 10:32 |
| infinity | Laney: Two can't be published together. | 10:32 |
| cjwatson | perhaps the right approach is to supersede old versions earlier or something | 10:32 |
| Laney | infinity: what happens? | 10:32 |
| infinity | Laney: If both build in the same publisher cycle, only the newer one will get published. | 10:33 |
| Laney | So, same effect then | 10:33 |
| cjwatson | seb128: 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 thought | 10:33 |
| Laney | Only the newer LP-Bugs-Fixed gets considered | 10:33 |
| infinity | Laney: But none of that prevents the build from happening, just gurantees archive sanity after the fact. | 10:33 |
| cjwatson | we might want to talk about this at the release team sprint if that ever happens | 10:33 |
| Laney | I'm trying to argue that it doesn't even work in most cases, buildd time wasting notwithstanding | 10:33 |
| infinity | cjwatson: AFAIK, it's happening, though we've failed to set a date. | 10:34 |
| Laney | Aaaaaaaaanyway. | 10:34 |
| infinity | Laney: Oh, I see what you're driving at. Since source copies from proposed to release are what triggers bug closures. | 10:34 |
| Laney | right | 10:34 |
| cjwatson | no, it works a bit better than that | 10:34 |
| infinity | Though that should be the same flow/usecase that Colin fixed for SRUs. | 10:34 |
| infinity | In theory. | 10:35 |
| Laney | Unless it unions LP-Bugs-Fixed | 10:35 |
| cjwatson | it does | 10:35 |
| cjwatson | on copy from proposed to release, it walks back through the ancestry to the most recent version in release and looks at all the .changes files | 10:35 |
| Laney | shiny | 10:36 |
| cjwatson | I think | 10:36 |
| cjwatson | actually, I think on copy it might reparse the changelog, which is arguably wrong ... | 10:36 |
| cjwatson | but in practice mostly has the same effect | 10:36 |
| cjwatson | I think some confusion about semantics has crept in along the way | 10:37 |
| infinity | Tsk, tsk, parsing the changelog... | 10:37 |
| cjwatson | Yeah. But it *could* walk the .changes. :-P | 10: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 | |
| infinity | s/twiddles/twiddled/ | 10:38 |
| cjwatson | You're supposed to be allowed to do that :) | 10:38 |
| infinity | I've also done that with Debian fakesyncs, adding LP bug closures to .changes where they weren't previously. | 10:38 |
| infinity | That was back when I was far less lazy than I am now. | 10:38 |
| * Laney accepts compiz despite the slightly borked changelog | 10:38 | |
| Laney | claiming to close a bug that it actually reopens | 10:38 |
| cjwatson | Anyhow, 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 them | 10:39 |
| seb128 | cjwatson, https://bugs.launchpad.net/launchpad/+bug/1170301 | 10:39 |
| ubot2 | Launchpad 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 |
| infinity | We need syntax for "reopens:" (Debian) and "UNLP:"... | 10:39 |
| infinity | cjwatson: 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 that | 10:40 | |
| infinity | (Though, right now, I think they'd just fall into a reject/fail loop if you went in that order) | 10:40 |
| infinity | Laney: 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 |
| Laney | Oh crap, I was joking. /me goes dark | 10:41 |
| cjwatson | infinity: 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 builds | 10:42 |
| infinity | cjwatson: I can make (b) one of my top priorities right after release. | 10:42 |
| cjwatson | please do :) | 10:42 |
| cjwatson | I'd love to have that | 10:42 |
| infinity | cjwatson: (a) seems unlikely, given that we kinda want to make things faster, not slower. | 10:42 |
| infinity | Totally time for a new buildd-manager rewrite. | 10:43 |
| cjwatson | Yeah, though it's probably the common case right now | 10:43 |
| Laney | Do you mean automatically cancelling builds when the source becomes superseded? | 10:43 |
| cjwatson | Yes | 10:43 |
| infinity | Yeah. | 10:43 |
| infinity | And that's valuable regardless. | 10:43 |
| cjwatson | Which depends on the ability to cancel builds at all without ops intervention | 10:43 |
| Laney | That would be suhweeeeeeeeeeeeeet | 10:43 |
| cjwatson | (non-PPA builds, that is) | 10:43 |
| infinity | Anyhow, 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 |
| infinity | So I just need to hook it into the right spots. | 10:44 |
| infinity | And unbugger buildd-manager to not be so mind-numbingly stupid. | 10:44 |
| cjwatson | Is that the sbuild kill-all-children approach? | 10:44 |
| infinity | cjwatson: That approach no workie, misses processes that get reparented. | 10:44 |
| infinity | cjwatson: This is the "walk /proc and slaughter everything in the chroot" approach. | 10:45 |
| infinity | Aaanyway. 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 |
| infinity | Jerk sun. | 10:46 |
| cjwatson | ah yes ok | 10:48 |
| cjwatson | we should start accumulating things to do at the release sprint in a more structured way than "in our heads" | 10:48 |
| infinity | Start a google doc and lose the URL. | 10:49 |
| infinity | Alternately, start a mail thread. I hear those used to work back in the dark ages of last year. | 10:49 |
| cjwatson | or I hear we have a wiki | 10:57 |
| cjwatson | Can somebody look at localechooser in NEW? I'd like to upload a ubiquity containing it. | 13:20 |
| cjwatson | Er, in UNAPPROVED that is | 13:20 |
| stgraber | looking | 13:23 |
| cjwatson | Thanks | 13:25 |
| * cjwatson grabs another translation export | 13:25 | |
| seb128 | tjaalton, slangasek, Laney: the libgl1-mesa-dri update makes unity segfault on start in vms | 13:37 |
| seb128 | go for new versions just before hard freeze :/ | 13:37 |
| cjwatson | does that include the one in the queue? | 13:40 |
| seb128 | cjwatson, no, current raring | 13:42 |
| seb128 | cjwatson, I can try building the one in the queue | 13:43 |
| cjwatson | I asked on #ubuntu-devel | 13:43 |
| cjwatson | but would be good to know | 13:43 |
| * cjwatson goes for lunch | 13:43 | |
| seb128 | cjwatson, trying a build, thanks | 13:44 |
| seb128 | libgl1-mesa-dri_9.1.1-0ubuntu3~ppa1_i386.deb from https://launchpad.net/~mlankhorst/+archive/ppa/+build/4501757 fixes the issue | 13:47 |
| didrocks | Laney: you didn't review unity-lens-music on purpose? | 13:48 |
| didrocks | Laney: as it's the second part for the FFe/UIFe :) | 13:49 |
| Laney | perhaps I missed it or it appeared after I did the otehrs | 13:49 |
| didrocks | Laney: should have been at the same time than the rest :) | 13:49 |
| Laney | anyway, give me 5 | 13:51 |
| didrocks | Laney: high five! :) | 13:54 |
| kenvandine | Laney, can you please reject ubuntu-ui-toolkit 0.1.42 and take a look at 0.1.43? | 14:28 |
| kenvandine | it has some important fixes | 14:28 |
| Laney | yes and no(t immediately) - going for lunch now | 14:28 |
| kenvandine | sure :) | 14:28 |
| kenvandine | enjoy your lunch :) | 14:28 |
| Laney | stgraber: ↑? :-) | 14:28 |
| * Laney runs | 14:28 | |
| stgraber | Laney: in a meeting but I'll try to take a look during/after it | 14:30 |
| kenvandine | stgraber, thanks | 14:31 |
| stgraber | kenvandine: do you have some kind of standing freeze exception for ubuntu-ui-toolkit? | 15:06 |
| kenvandine | Mirv, ^^ | 15:07 |
| stgraber | kenvandine: 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 |
| kenvandine | oh, yeah i thought that got stripped | 15:09 |
| kenvandine | stgraber, i pulled bug fixes in from trunk since 0.1.42, which had been sitting in the queue | 15:10 |
| kenvandine | but there are features before that | 15:10 |
| kenvandine | and since last upload... | 15:10 |
| stgraber | right, 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 freeze | 15:12 |
| Laney | I don't think there was | 15:18 |
| kenvandine | stgraber, there was a FFe bug 1157191 | 15:20 |
| ubot2 | Launchpad bug 1157191 in ubuntu-ui-toolkit (Ubuntu) "[FFe] API updates for MainView, PageStack and Tabs " [Medium,Fix released] https://launchpad.net/bugs/1157191 | 15:20 |
| kenvandine | and part of those changes include fixes related to that | 15:20 |
| kenvandine | a couple bugs and documentation fixes | 15:20 |
| kenvandine | it looks like the only real feature in there is the Icon component | 15:20 |
| kenvandine | in 0.1.39 | 15:20 |
| kenvandine | oh, theming engine too | 15:21 |
| kenvandine | but that actually fixed a pile of style bugs... | 15:21 |
| stgraber | yeah, there's also: | 15:30 |
| stgraber | + - Added "make license" target | 15:30 |
| kenvandine | stgraber, that is just for adding a test in the build | 15:32 |
| kenvandine | i don't think that changes the resulting packaging | 15:32 |
| stgraber | ah ok, that wasn't clear from the changelog | 15:32 |
| kenvandine | sorry :) | 15:32 |
| kenvandine | it is for a checklicense test that CI does | 15:32 |
| kenvandine | makes sure all the files have the right copyright and license in the header | 15:33 |
| rbasak | Is 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 |
| stgraber | so, who exactly is using that package at the moment? I see it's not shipped on any of our media | 15:34 |
| stgraber | rbasak: we're still interested in FTBFS fixes. You can use seeded-in-ubuntu to check if it's seeded or not | 15:34 |
| kenvandine | stgraber, it is in universe and the only package that uses it is friends-app | 15:34 |
| stgraber | rbasak: 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 |
| rbasak | stgraber: OK, great. And I didn't know about seeded-in-ubuntu - thanks! | 15:34 |
| rbasak | Ah - good point. | 15:35 |
| dtchen | rbasak: yeah, i could really use some help with them :) | 15:35 |
| stgraber | kenvandine: ok, and is friends-app broken without the new version? | 15:35 |
| kenvandine | stgraber, so very low risk and most of the fixes in 0.1.43 fix bugs reported in friends-app | 15:35 |
| kenvandine | yeah, there are some textinput bugs | 15:35 |
| kenvandine | which this fixes | 15:35 |
| kenvandine | and the theming change too | 15:36 |
| kenvandine | that fixes bugs found in friends-app | 15:36 |
| stgraber | ok, 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 |
| kenvandine | great | 15:37 |
| kenvandine | :) | 15:37 |
| kenvandine | stgraber, thx | 15:38 |
| === smartboyhw is now known as Guest42028 | ||
| hallyn | stgraber: infinity: ok, it seems the tiny debdiff at http://people.canonical.com/~serge/libvirt-migrate.debdiff fixes the libvirt-qemu migration bug 1157626 | 16:14 |
| ubot2 | Launchpad bug 1157626 in qemu (Ubuntu) "Unable to use "virsh migrate" on two hosts after moving to raring" [High,Triaged] https://launchpad.net/bugs/1157626 | 16:14 |
| hallyn | I'm startign a set of regression tests, which should be done in an hour... but i don't expect failures from that | 16:14 |
| hallyn | that would replacethe (obviously now too late) FFE request for libvirt version 1.0.4 for raring | 16:15 |
| smartboyhw_ | Just asking: Is FinalFreeze on 21:00 UTC today? | 16:16 |
| hallyn | yup | 16:17 |
| * hallyn back in a bit | 16:18 | |
| stgraber | hallyn: 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 raring | 16:19 |
| doko | Daviey, some weeks ago you did promise to look at the server related ones here ... http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 16:31 |
| slangasek | doko: Daviey is at ODS this week, so you probably won't get much of a response | 16:41 |
| doko | ahh, ok | 16:41 |
| hallyn | stgraber: http://people.canonical.com/~serge/libvirt-migrate-v2.debdiff all tests passed | 17:11 |
| stgraber | hallyn: cool, go ahead with the upload | 17:14 |
| hallyn | stgraber: great, thanks | 17:14 |
| hallyn | pushed | 17:14 |
| infinity | hallyn: 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 |
| rsalveti | yeah \o/ | 19:09 |
| ogra_ | infinity, that was sergiusens adding the touch image testcases ... seems the netboot shouldnt really be there | 19:10 |
| sergiusens | infinity: that was balloons creating a tag for us to test the Ubuntu Touch builds | 19:10 |
| sergiusens | on isotracker | 19:10 |
| balloons | I don't know who added netboot | 19:10 |
| balloons | that was random.. | 19:10 |
| * ogra_ shakes his fist at Mr. random | 19:12 | |
| ogra_ | evil guy you ! | 19:12 |
| ogra_ | :) | 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 | |
| ogra_ | :) | 19:13 |
| stgraber | balloons: 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 yet | 19:15 |
| balloons | stgraber, I figured as much :-) | 19:22 |
| stgraber | ogra_: 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 stuff | 19:22 |
| ogra_ | stgraber, yeah | 19:23 |
| infinity | stgraber: 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 |
| stgraber | infinity: sure, taking a look now | 19:32 |
| infinity | It probably instills very little confidence that I'm always pleasantly surprised when one of my glibc upgrades goes smoothly, doesn't it? | 19:35 |
| stgraber | infinity: are you sure we're not using that nfs4/nfs alias? | 19:35 |
| infinity | stgraber: We're not using that alias file at all, so no. :P | 19:35 |
| infinity | (Not using is it part of our delta elsewhere in debian/rules) | 19:36 |
| stgraber | infinity: good ;) | 19:36 |
| infinity | s/is it/it is/ | 19:36 |
| infinity | We 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 |
| stgraber | infinity: and you didn't feel like listing our delta in the changelog of the merge? (would have saved you the question) :) | 19:37 |
| infinity | For 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 |
| infinity | stgraber: I have a severe distaste for reiterating "merged; remaining changes:" on every 5-line-change upload. | 19:39 |
| infinity | stgraber: 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 |
| infinity | Hrm, freeze in 1:19. | 19:41 |
| infinity | Here's hoping everyone's happy with their packages. | 19:41 |
| stgraber | I still have a last minute lxc upload to do, waiting for a quick review by barry though | 19:42 |
| balloons | stgraber, ty. just make sure the builds are still being pushed for touch :-) | 19:46 |
| barry | stgraber: ha! i just sent the ack | 19:48 |
| infinity | I still have a last-minute d-i upload to do, I need to get to mangling that. :/ | 19:49 |
| barry | bdmurray: needs to upload ubuntu-release-upgrader | 19:50 |
| bdmurray | speaking of that could someone have a look at bug 457221? I was just gonna remove cups-pdf from ForcedObsoletes | 19:51 |
| ubot2 | Launchpad 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/457221 | 19:51 |
| bdmurray | although its not that important | 19:52 |
| bdmurray | stgraber, infinity: ^ | 19:54 |
| infinity | bdmurray: Huh. ForcedObsolete seems a bit heavyhanded if it was just unseeded. I wonder what the rationale was. | 20:05 |
| infinity | If 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 |
| bdmurray | maybe there was some thing else wrong with it? | 20:06 |
| infinity | Well, if it's fundamentally asplodey broken, it shouldn't be in the archive, IMO. | 20:06 |
| bdmurray | Right, I meant the Intrepid version of it. | 20:06 |
| infinity | But 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 |
| infinity | bdmurray: Anyhow, ACK on fixing that in your next release-upgrader upload. | 20:07 |
| stgraber | so if someone is actually reading through the lengthy python patch in lxc, it's a cherry-pick of the following upstream commits: | 20:51 |
| stgraber | https://github.com/lxc/lxc/commit/33892746e373449a8a69a4265d783bf701cb5784 | 20:51 |
| stgraber | https://github.com/lxc/lxc/commit/e649c8032f84b488cac8ea6c8fb9a77c424a0419 | 20:51 |
| stgraber | https://github.com/lxc/lxc/commit/2ebec36f271d4ee943281e32feb3552745115347 | 20:51 |
| stgraber | https://github.com/lxc/lxc/commit/6c5db2af1f706e8f21f2a5f074bada96e9011052 | 20:51 |
| phillw | stgraber: 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 |
| balloons | you can edit to just http://lxc.sourceforge.net/ | 21:12 |
| phillw | balloons: 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 |
| stgraber | infinity: any chance you can review lxc? | 21:19 |
| infinity | stgraber: Too bad, we're frozen. | 21:19 |
| infinity | stgraber: (Yeah, I'll look in a second) | 21:19 |
| stgraber | hehe, we may have sucky audit trail on that stuff, but we at least have a timestamp ;) | 21:20 |
| stgraber | (thanks) | 21:20 |
| stgraber | I'm looking at the nexus7 kernel | 21:21 |
| stgraber | *nexus4 | 21:21 |
| stgraber | hmm, 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!