=== doko_ is now known as doko [02:20] ^^ hmm, that wasn't uploaded to oneiric-proposed, it was uploaded to oneiric [02:20] cjwatson: does that mean the -proposed redirect is having an unexpected effect on partner? [02:20] I think somebody may have mentioned that [02:21] Do file an LP bug if it isn't there already [02:21] ok [02:23] cjwatson: bug #1081860 [02:23] Launchpad bug 1081860 in Launchpad itself "uploads to oneiric/partner are redirected to oneiric-proposed/partner" [Undecided,New] https://launchpad.net/bugs/1081860 [02:23] ta [02:23] thank you :) [02:24] in the meantime feel free to copy it to release and delete from proposed once it's fully built [02:24] yep, will do [02:24] actually, I think last time we talked about this we may have concluded it was a feature [02:24] actually, was going to be copying it to several releases :) [02:24] what do you think? [02:24] hmm [02:24] after all, partner is delivered directly to users [02:24] and it's possible that multiarch skew would be bad [02:25] the awkward bit of course is that we have no automatic migration [02:25] well, I don't feel strongly about it either way [02:25] but we could have something in pending-sru as a stopgap, maybe [02:25] there shouldn't be multiarch skew issues for most packages in partner; skype does only because of the pre-multiarch->multiarch upgrade oddity [02:26] M-A: same is quite possible though ... [02:26] And of course there are always the traditional issues of exact dependencies on arch-indep common packages [02:27] M-A: same is highly unlikely in a partner package [02:27] being that most are end-user apps [02:28] anyway, again, I don't feel strongly about it :) [02:28] OK, but I'm sure I've seen common packages [02:28] if you think it's a feature, feel free to leave it as-is [02:29] I've left a comment on the bug and we'll see what others think [02:30] I'm inclined to view it as a feature, as long as we report on it and actually promote things. [05:24] infinity: What would you think about one more armhf builder and one less armel? [05:25] ScottK: That 5 minute long queue is killing you? :) [05:25] Well, you didn't see what's not uploaded yet. [05:25] ScottK: I don't mind right now, but as soon as security builds come through, the balance shifts the other way. [05:26] Right. [05:26] ScottK: Oh, if you have a mess of KDE merges on the way, we can shift a few over. [05:26] * infinity tosses a bunch over. [05:26] First beta of the new KDE series. [05:26] Thus all the New ^^^^ [05:26] Unfortunately I uploaded all those. [05:27] This is going to hurt a bit with sulfur down anyway. [05:27] But such is life. [05:28] Yeah. I rescored the ones that will hit New to go first. [05:28] And if you weren't stuck behind doko and I, that would mean something. [05:28] TIMING. [05:29] yeah. [05:29] doko: Nice empty changelog on gcc-4.6, by the way. :P [05:29] It'll such less in the end, but not for a while. [05:29] such/suck [05:29] doko: "remaining changes:" ... the suspense is killing me. [05:31] ScottK: You should have ross in ~10m, I think. glibc looks nearly done. [05:31] Cool. That will help. [05:33] Oh, wait, it may still have another testsuite to run after this one. [05:33] I take it back. :P [05:34] I so wish I could blame lamont for breaking sulfur, but he did it because I asked him to (it apparently broke when being upgraded to precise) [05:37] Generally I thought newer was better for our powerpc (at least if you aren't moving from dapper to something newer) [05:37] Oh, no, precise will run great on that machine. The upgrade just had an oops, I suspect. [05:37] My *guess* is that it had an ancient yaboot on the bootstrap partition, which doesn't get auto-updated on upgrade. [05:37] And the old yaboot can't boot kernels over a certain size. A size we passed around precise time. [05:38] Right. I remember that now. [05:38] But, not remote console, so all guesses until someone in London can go smack it. [05:38] s/not/no/ [07:48] cjwatson: Accepted ubiquity and livecd-rootfs, holding off on debian-installer as we're in the middle of a kernel SRU cadence transition and omap4 and armadaxp will need an ABI bump too (tomorrow, I hope). [07:48] cjwatson: While I'm waiting on that, maybe I should quickly test a fix for the "omap* netboot images too small" bug and commit that in the morning. [08:09] slangasek: Hrm, not sure what happened with the one skype reject there, but I re-copied it and it's fine now. [08:12] firefox in quantal-updates,security is ahead of raring. [08:12] and thunderbird. [08:12] xnox: I'm sure chrisccoulson is on top of that. [08:14] infinity: ack, but why did it not go into raring first? (which is at beta) [08:14] * xnox is not affected as I have raring + quantal-updates/-security enabled. [08:14] You may be affected by other things, then, like regressing the packaging. :P [08:15] As to why it went to stable releases first, I assume because it was an urgent security push. [08:15] chrisccoulson / micahg: Do we get raring versions of ffox/tbird soon, they're currently older than quantal. [08:17] unless beta6 was final release.... [08:18] Well, older package version. I'm less concerned about the code. [08:19] infinity: If you can be bothered with a little binary New, kdepimlibs would be really nice. [08:19] Oh, nevermind. [08:19] Thanks. [08:19] :) [08:20] Man, that erlang-jiffy FTBFS is a weird one. [08:21] The testsuite SEGVs perl on ppc/mips/s390, but only when running on a 64-bit kernel. [08:21] When I run it on a 32-bit kernel, all is well. [08:30] Riddell: Did you drop a GLES patch from analitza, or did upstream's cmake just get a bit dumber? [08:31] Looks like the latter. [08:32] And why do I feel like I've fixed this exact bug before in another package? [08:52] * ScottK fixed the kalzium FTBFS already [08:52] * ScottK goes off to bed. [09:00] hi, can anybody reject nvidia-graphics-drivers-updates 304.64-0ubuntu0.2 in precise-proposed, please? === mmrazik is now known as mmrazik|otp === mmrazik|otp is now known as mmrazik [09:12] tseliot: Sure. Is the other one (experimental-310) fine? [09:12] infinity: yep [09:12] thanks [09:25] infinity: you are right about security, USN issued against thunderbird & firefox. [09:25] xnox: Well, yes. They were in the security pocket, after all. === mmrazik is now known as mmrazik|otp [09:41] infinity: OK, thanks === mmrazik|otp is now known as mmrazik [10:16] I take it we don't have component-mismatches for proposed currently/ [10:21] No [10:22] So someone synced libnice which BDs on libgstreamer1.0-dev in universe. [10:22] Do we ask for MIRs for stuff like that? [10:22] (The 0.10 series is already in main) [10:26] Laney: Same source? [10:26] no [10:26] Same parent? :P [10:27] We don't need MIRs for new versions of upstream sources unless they're complete rewrites. [10:27] It's separated because it's API incompatible [10:27] all parallel installable, etc [10:28] Sure, but it's the same original source tree, just newer/shinier, yes? [10:28] If so, I'll just promote it. [10:28] I don't know how they branched it technically, but morally it is [10:28] It's still the same upstream [10:29] (I am assuming that this doesn't go down the plugins rabbit hole, yet) [10:30] Laney: promoted. [10:30] cheers === mmrazik is now known as mmrazik|lunch === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik [14:18] infinity: still around? === rsalveti_ is now known as rsalveti === peterm-ubuntu is now known as Peter_in_Turing [15:15] infinity: ok then - also not sure how you wound up needing to do the accept since I thought I did that part; and really not sure how I managed to have a bug in the skype-bin dependency since I'm sure I tested this before upload :P [15:17] slangasek: stgraber's sponsoring a patch from me to fix skype-bin now (#ubuntu-devel) [15:17] ah, ok [15:22] can anybody reject nvidia-graphics-drivers-experimental-310 from precise-proposed, please? [15:22] tseliot: done. [15:22] Daviey: thanks [15:32] cjwatson: ^ [15:39] Eeep! https://launchpadlibrarian.net/123688867/upload_4383759_log.txt [15:41] Should I just upload another pykde4 and see if that happens again or is that something that needs actual investigation? ^^^ [15:47] cjwatson: skype/oneiric-proposed accepted, now that I found some bandwidth [15:53] ScottK: looks scary, as if one of our pandas is busted =/ [15:53] Yes. That's why I asked if someone wanted to investigate. [15:56] ScottK: same buildd is now building konsole, soon we will find out if it's a fluke or not. [15:58] slangasek: ta [17:06] infinity: So, um, d-i - I don't suppose you could reconsider and let this in despite the upcoming kernel changes? Thing is that I've kind of told PES that there'll be SB images ready to test by the end of the week [17:06] And I'm running out of week [17:07] And none of the relevant newer kernels appear to be in the archive yet [17:08] please, respin ubuntu desktop images with initramfs-tools 0.103ubuntu0.3 , it's blocking QA [17:10] running [17:17] cjwatson: incidentally, it was brought to my attention that there are people publishing skype in ppas, which AIUI is not permitted... do you know how/where this should be escalated? (https://launchpad.net/~trebelnik-stefina/) [17:17] slangasek: I was going to sort out sponsoring Adam's appmenu-gtk/precise upload; I see you sponsored it for quantal and raring; was there any particular reason you didn't finish doing so for precise as well, or did you just run out of time? [17:17] slangasek: answers.launchpad.net/launchpad [17:17] cjwatson: ta [17:17] cjwatson: ran out of time, was going to do it this week [17:18] slangasek: ok, want me to take care of it? [17:18] cjwatson: your call; if you don't, I'll get to it today or tomorrow [17:19] slangasek: o [17:19] k [17:25] slangasek: looks like the precise diff is similarly missing the --libdir change you added to the raring diff - double-checking and I expect I'll do the same [17:26] * slangasek nods [17:26] (mentioning it now just in case I do run out of time) [17:43] infinity: re Firefox/Thunderbird raring, I would expect that to be 18b1, but wasn't sure if chrisccoulson was planning on uploading that before Monday in which case, I would think someone should upload 17 final before then, but didn't have a chance to discuss yet [17:45] micahg: hm. I brought it up originally. I decided to enabled quantal-security & quantal-updates on my machine to see how many people are still not fixing stuff in devel first and this was the first big one. [17:45] micahg: also there is a report of uninstallability caused by thunderbird security upload. [17:47] micahg: never mind uninstallability, the uninstallable package is not from the archive. [17:51] xnox: so, devel usually tracks beta until close to the end, so we usually jump to the next beta almost immediately and it doesn't seem worth the extra upload, in this case though, the next beta isn't until early next week, so depending on what chrisccoulson has in mind, it might be worth an upload (which I can do later if need be) [17:52] micahg: copy from quantal-security into raring-security [17:52] * xnox hides [17:53] raring-proposed surely [17:53] however [17:54] if you do that it'll break due to an LP bug induced by having one fewer architecture in raring [17:54] which I've not yet finished fixing [17:55] and -security isn't open for series not in stable or frozen states [17:55] well, I'm not planning on doing the copy, also, it doesn't seem right as there's already builds of Firefox in raring [18:17] * infinity wonders if people having the firefox discussion noticed it was uploaded 3 hours ago. [18:27] infinity: I believe we stayed ignorant of that fact ;-) [18:27] infinity: in the mean time we made initramfs-tools ever so little more diverged ;-) [18:32] ScottK: Why did you reupload pykde4? A failed-to-upload build can just be retried... [18:33] xnox: Yeah, I noticed. I'd explicity asked people not to rev it before I merged, but oh well. If it was blocking QA, that's more urgent than my sense of aesthetics. [18:35] infinity: I'm guessing ScottK reuploaded it to keep the logs. [18:36] infinity: was the upload fail not scary, considering it uploaded a file short of it's total size? [18:36] xnox: That's why it checks the sums. *shrug* [18:37] xnox: (Yes, it's a bit scary, but this isn't a one-off) [18:43] ack. [19:14] cjwatson: One of the two new kernels was just copied to proposed. The other is waiting on QA to finish the previous round of testing, but maybe they're blocked on turkey. :/ [19:18] cjwatson: But, given the urgency, if I see no progress by my EOD, I'll accept your upload, if I do, I'll stack another on top with the new kernels represented. [19:19] If I do see progress, that is. That was an awful attempt at Englishing. [19:26] cjwatson: Right, blocked on turkey it is, I'll review this and push it out, and follow it up with another ABI bump later. [22:06] infinity: Right. Thanks. [23:07] infinity: Because when I looked I didn't recall seeing a retry button. I probably just missed it because i was in a hurry this morning. [23:32] slangasek: your take on bug 1082170 would be welcome; skype/oneiric requires at least two multiarchifications to work properly (one M-A: foreign, so trivial; one M-A: same, so less so) [23:32] Launchpad bug 1082170 in skype (Ubuntu) "skype-bin is not installable on 64bit oneiric due to broken multiarch dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/1082170 [23:32] slangasek: do we want to try to push through emergency SRUs for this, or revert skype? [23:33] cjwatson: hmm :/ [23:33] just double-checking precise no [23:33] w [23:34] note that the libxml2 one only shows up in a minimal chroot if you coinstall skype and ubuntu-desktop [23:34] or at least that's the easiest way to see it [23:34] cjwatson: if it were just the trivial one, I would do the quick SRU... given that it also needs a M-A: same though, I'm wondering if we should revert [23:35] skype and ubuntu-desktop are coinstallable on precise/amd64 [23:35] lucid still hasn't been updated, because they've provided a separate binary build targeting 10.04 but it's not installable with 10.04's ia32-libs [23:35] yep, I had tested on precise and didn't think to test oneiric separately [23:38] At least libxml2's dependencies (libc6, zlib1g) have been converted [23:38] So it could in principle be a more selective backport [23:39] But I tend to think we should revert, do those SRUs at slightly more leisure, and then restore the new skype version later [23:39] At least if that's not too much of a headache with its versioning [23:47] * slangasek nods [23:48] uploaded the easy one (iso-codes) [23:48] so revert with a bumped version number? [23:48] yeah, I think so - though I probably will do the libxml2 SRU tonight anyway [23:48] ok [23:49] I'm beset by family still here, so not sure I'm in a position to help much :/ [23:51] yeah, I have things I need to do too and it's getting late ... [23:51] I'm assuming from the tiny version skew that an oneiric libxml2 upload will essentially be identical to precise, modulo changelog and version numbers. [23:51] That should make it pretty simple to audit. :P [23:52] I'd be okay with fasttracking a literal "backport libxml2 from precise-updates to oneiric-updates with a sane version number". [23:52] I was actually going to make it simpler - we don't need M-A: libxml2-dbg or libxml2-utils AFAICS [23:53] cjwatson: Perhaps not, no, but from a fasttracking perspective, the closer it is to a source package we've already well-tested, the better. [23:53] That involves introducing a new binary though? [23:53] (libxml2-utils-dbg) [23:53] New binaries in post-release pockets happen. [23:55] I am particularly worried about the libxml2-dev M-A change in 2.7.8.dfsg-9, because that was later reverted and then reintroduced [23:55] Debian #674474 [23:55] Debian bug 674474 in libxml2-dev "libxml2-dev: arch-dependent file in "Multi-Arch: same" package" [Important,Fixed] http://bugs.debian.org/674474 [23:56] I'd really prefer to strip that out so we don't have to enter that minefield [23:57] Mind you, I suppose the precise version didn't have any of that [23:57] Yeah... [23:57] * cjwatson digs [23:57] If it's broken in precise, we need to fix it in precise anyway. [23:57] And if it's correct in precise, it makes sense to have correct/tested code in oneiric, instead of trying to cherrypick the bare minimum. [23:58] (Not my usual stance, but in this case, the entirety of the changes from oneiric to precise is multiarching anyway) [23:58] Yeah, OK, I think I'm convinced - looking