[00:03] walinuxagent binaries in precise/NEW heading to main, I assume? [00:05] infinity: yawp [00:06] * infinity pokes the debs for sanity first. [00:07] The linux-image-extra-virtual dependency is kinda icky... [00:07] Given that we don't normally depend on kernels at all. [00:09] Means installing that will pull in a different kernel if you had, say, generic installed. [00:09] Are we okay with that? [00:12] slangasek: ^-- Thoughts? [00:13] I suppose that, given that it's meant to be installed in Azure VMs, which should be built with linux-image-virtual anyway, it might be mostly a non-issue, but it still feels "wrong". [00:55] And I think my eyes just crossed at the 50ish or so emails from soyuz about all the kernel SRUs I just mangled... === mdeslaur_ is now known as mdeslaur [01:43] * skaet has kicked off a chinese image build for precise [02:02] Aww, crap, I missed one eglibc bug. [02:02] * infinity fixes. [02:03] infinity: just one, that's amazing :) [02:06] infinity: well, this has already passed NEW once in quantal, so I don't see much point in pushing back on the dep [02:15] slangasek: Mmkay. [02:15] micahg: Okay, lots, but one that I meant to fix in this batch. :P [02:50] infinity: thanks for the update on eglibc. [02:51] infinity: I uploaded live-build with the recommended change (and filed a bug for tracking). [02:51] Would be great if someone could review and let it through when it lands. I haven't tested it, but the easiest way to test it is to have it deployed on the buildds... [02:52] Do you have any someones in mind? :P [02:55] the usual workaholics, so you, ScottK, slangasek or cjwatson now that he's back on some kind of internet :) [02:56] though you're the only one with a livefs setup to test my fix before it lands on the buildd :) [02:56] * infinity gives it some time to get diffy wit' it. [02:56] And yeah, I can test locally. [02:57] my quick look through live-build suggests that the autoremove run will be done before that cleanup call. So in theory if any of the packages brought extra no-longer-needed dependencies, they won't be cleared. But I doubt that's the case. [02:57] Oh, actually. [02:57] You're doing it in chroot-hacks? [02:58] Which means the langpack will still be in the manifest. [02:58] Or... [02:58] Wait. [02:58] langpacks are in the live seed, or desktop? [02:58] * infinity looks. [02:59] Oh, live. [03:00] In that case, nevermind my babble, cause hacks runs before the live manifest is generated. [03:01] (One could, perhaps, argue that the hack belongs in a local-hook provided by livecd-rootfs, though. [03:01] ) [03:01] yeah, I wasn't aware of when the manifest is built, but it's apparently built at the beginning of lb_binary and the hacks are applied in lb_chroot, so before that [03:01] The manifest is done in lb_chroot too. [03:01] It's just that hacks happens between the two manifests. :P [03:01] As do hooks. [03:02] really? grep doesn't seem to agree so it must be called something else than "manifest" ;) [03:02] Chroot chroot "dpkg-query -W" > binary.packages.live [03:02] ah, ok, explains why grep didn't find it [03:02] grep is a cruel mistress. [03:03] Well, I'm going to reject that anyway. [03:03] For two reasons. [03:03] Possibly three. [03:04] I should have reviewed it better last time. :P [03:04] For starters "apt-get --purge -y " isn't a valid apt-get command. [03:04] doh, indeed [03:05] On top of that, while you do attempt to guard it with i386/precise, on the off chance those packages aren't installed, do we want it hard failing, or do we want a || true? [03:05] And then, on top of it, it might be less icky as a local hook. But I'm less picky about that, a hack is a hack, and we're not maintaining it for Q+ [03:06] hmm, not too sure about that one, I think it'd like to know if the project/arch match matches something else than what I want [03:06] as it'd mean it might also remove the langpack from an image where we want it (like some flavours) [03:06] Actually, I didn't look at the guard closely. [03:06] What does it match? [03:06] (I rejected it already, can't see the diff anymore...) [03:06] PROJECT = precise and ARCH = i386 [03:07] which is put in the environment by BuildLiveCD [03:07] precise isn't a PROJECT. [03:07] good point [03:07] And if you're matching release, then you've broken every non-ubuntu-desktop build. [03:08] yeah, I want PROJECT = ubuntu [03:08] Especially the ones that don't have that langpack in the first place (see the bit about the guard). [03:08] which should get my just the ubuntu desktop livefs [03:10] added a || warning, that should be enough to not break the world while still letting me verify that the check is correct [03:10] Kay. [03:10] And yeah, PROJECT=ubuntu should do. [03:11] It'll actually match wubi too, but I doubt anyone cares. [03:11] In fact, we tend to want wubi to have an identical package set. [03:11] So... [03:12] infinity: http://paste.ubuntu.com/1138924/ [03:14] ARCH might be randomly overloaded. [03:14] You might want $LB_ARCHITECTURES [03:20] * infinity tests the above diff, but with LB_ARCHICTECTURES, and with es instead of de and amd64 instead of i386, since his builder is amd64... [03:32] The following packages will be REMOVED: [03:32] firefox-locale-es* language-pack-es* language-pack-es-base* [03:32] language-pack-gnome-es* language-pack-gnome-es-base* [03:32] 0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded. [03:32] I call that success. [03:36] es? [03:37] oh, I guess you tried against an amd64 build so had to pick -pt or -es [03:37] Right. [03:37] I'd rather keep de anyway. [03:46] stgraber: Deploying to both kapok and cardamom, so you can verify it DTRT on i386, and does nothing on amd64. [03:48] infinity: perfect, thanks [03:52] stgraber: All done. [03:57] infinity: ok, started a respin of desktop (for live-build) + alternate (for update-manager) [04:13] infinity: resulting images look good, no more oversize [04:13] stgraber: Shiny. And logs look reasonable? [04:16] waiting for them to show up on lillypilly, checked the manifests of all images and it's as expected [04:17] lftp http://cardamom.buildd/~buildd/LiveCD/precise/ubuntu/latest [04:17] less *out [04:18] Profit. [04:18] Well, except that globbing doesn't work. :P [04:18] yeah, just checked these as I got tired of waiting, looks good, no mention of my warning on there [04:19] grabbed ~buildd/BuildLive.out. AFAICS nothing started building after my builds, so I think I checked the right ones ;) [04:20] Yeah, I just checked both, looks good. [04:20] marked the bug verification-done [04:21] Released. [04:21] Argh. [04:21] NBS report just went empty again. [04:21] Stupid cache. [04:23] * infinity decides to not care and have a nap instead. [06:43] hey, the sru's in bug 1031784 are critical for .1. Would someone ack the uploads to -proposed? [06:43] Launchpad bug 1031784 in xserver-xorg-video-intel "Artifacts on screen with ivy bridge" [Critical,In progress] https://launchpad.net/bugs/1031784 [09:41] sorry for lack of automatic security->updates copying for expat; fixed now [09:45] so, we now have pocket queue admin permissions in Launchpad, although per-series versions of those will have to wait for another landing/deployment (I got my first version a bit wrong) [09:45] I have done this to start with: [09:45] $ ./edit-acl -p ubuntu-security --pocket security -t admin add [09:45] Added: [09:45] Queue Administration Rights for ubuntu-security: archive 'primary', pocket 'Security' === yofel_ is now known as yofel [09:47] jdstrand: ^- I think the above should allow you to use 'unembargo --copy' directly, with no need for ubuntu-archive to approve; I suggest that you apply http://paste.ubuntu.com/1139300/ so that your copies go straight through without you needing to approve them manually either [09:47] do we want that for backports? [09:47] also, yay for that [09:47] jdstrand: I'd appreciate you folks doing this for your next security update, and if it works, I think we can totally decommission the old system [09:48] Laney: Probably, but perhaps that should be stable releases only? [09:48] Which will require me to get per-series permissions working [09:48] Mind you, -backports doesn't work in the development series anyway ... [09:48] I think we can be trusted not to mess with it in the brief interim ... [09:48] And if -backports started working in the development series, we'd want to let you use it anyway [09:49] I don't know how it's broken atm, straight reject? [09:49] Straight reject [09:49] $ edit-acl -p ubuntu-backporters --pocket backports -t admin add [09:49] Added: [09:49] Queue Administration Rights for ubuntu-backporters: archive 'primary', pocket 'Backports' [09:49] nice [09:49] Give that a try then next time you have a chance? [09:50] I think I have one to try now-ish [09:50] You should be able to use either the web UI or the queue client in u-a-t [10:03] cjwatson: I see checkboxes for all queue entries, is that expected? [10:05] Ish, if you actually try to do anything with those it'll refuse [10:05] (or should ...) [10:05] ok [10:05] It's sort of a bug that you get checkboxes, but annoyingly tedious to fix [10:05] Maybe we should verify this though [10:06] Laney: wanna try rejecting build-essential/precise-proposed? [10:06] (I choose reject because the permissions are equivalent, but it's fairly harmless if it goes wrong) [10:07] FAILED: build-essential (You have no rights to reject component(s) 'main') [10:07] Good [10:07] strange that it refers to a component [10:07] also: ^ that was me [10:08] It doesn't know which of the several possible rights you don't have but should ;-) [10:08] possibly worth adding the pocket to that message, but meh [10:08] I see, I didn't know that per-component permissions existed [10:09] let's try doing lucid with the tool [10:09] Per-component queue admin permissions were all we had before [10:13] queue -s lucid -Q unapproved info ← is that right? [10:14] -s lucid-backports [10:14] that works [10:16] anyone on sru rotation today? [10:18] nice [10:19] * cjwatson wonders if there was a WI for that somewhere [10:21] Don't see one [10:27] it would be important to get the fixes in bug 1031784 in 12.04.1 installer, is it too late already? [10:27] Launchpad bug 1031784 in xserver-xorg-video-intel "Artifacts on screen with ivy bridge" [Critical,In progress] https://launchpad.net/bugs/1031784 [10:28] not installer, but the image [10:29] tjaalton: Friday is slangasek's day, so you should wait until a bit later [10:29] Laney: ok, thanks [10:29] SRU team is a bit thin on europeans, actually === mdeslaur_ is now known as mdeslaur [12:27] cjwatson: awesome, thanks. I had tyhicks (a non-core-dev) try to use --copy yesterday and it worked great for him (still needed AA approval at the time) [12:27] cjwatson: (expat) [12:28] cjwatson: I'll make the change to our script, but we probably won't push anything until next week (we typically only push high priority updates on fridays) [12:31] (change committed) [12:31] Right, the per-pocket upload permissions would have handled his case [13:15] tjaalton: that package is already in the queue right? [13:17] stgraber: which one? there are two uploads [13:18] tjaalton: ivy bridge fix in xserver-xorg-video-intel [13:21] stgraber: don't see any email about it being accepted [13:22] xserver-xorg-video-intel (2:2.17.0-1ubuntu4.1) in the queue seems reasonable, diff is small, looks pretty obvious, so I'm happy with an exception for that one [13:23] thanks [13:23] slangasek: can you take a look at xserver-xorg-video-intel when you're around? [13:24] mesa is kinda problematic since it's on top of an existing sru in proposed, which is also anew upstream stable release [13:25] skaet: all the Ubuntu images now fit on their media, I'm now doing yet another test run of the alternate upgrade to make sure that the new update-manager fixed the remaining issues [13:25] but the new patch is small just like -intel [13:27] ok, let me check if there's something I can do to get the current mesa into -updates so we can then get your new one in -proposed [13:28] though that may have to wait till Monday as releasing updates to users on a Friday is usually considered a bad idea [13:29] tjaalton: one of the bugs related to the mesa currently in -proposed is bug 1031821. Can you have a look to see what's going on? [13:29] Launchpad bug 1031821 in mesa "package libgl1-mesa-dri 8.0.3-0ubuntu0.1 failed to install/upgrade: libgl1-mesa-dri:amd64 8.0.3-0ubuntu0.1 cannot be configured because libgl1-mesa-dri" [Undecided,New] https://launchpad.net/bugs/1031821 [13:30] looking. has worked for me though [13:32] it's currently the only potential regression from the SRU in -proposed, so if it can be confirmed that this isn't something introduced by the SRU and someone can confirm the tests (piglit) pass as expected, then it should be ready to be copied (per MRE criteria) [13:33] looks like he had mismatched versions of i386/amd64 binaries for some reason [13:35] the i386 version lagging behind [13:36] so, not caused by upstream code :) [13:52] jibel: can you test the offline upgrade again with the latest alternate? it seems to work here (10.04.4 up to date using the latest amd64 media as upgrade source) [13:53] stgraber, sure, I can do that. [14:00] stgraber, WOOT! glad to hear they all fit. :) [14:03] skaet: looking at the flavours, kubuntu dvd is the only oversized I noticed and they're not releasing it, so looks like we're fine there too [14:05] stgraber, goodness. Switch over to building from -updates now? [14:14] skaet: I think I'd prefer to still have -proposed enabled for the weekend, try to get people to do as much verification as possible until Monday, then on Monday copy as much as we can to -updates and THEN switch to -updates [14:14] Laney: You should be using queue from ubuntu-archive-tools anyway so you don't need to care about check boxes... [14:16] ScottK: I did; it was just to test both interfaces. [14:16] OK. [14:19] skaet: some bits need to move to -updates before we can start building without -proposed anyway (like debian-installer, nspr, openoffice.org, update-manager, update-notifier, launchpad-integration and apt-clone) [14:20] stgraber, ok. But want to do a full respin on monday as soon as we switch over, rather than wait for the dailies that night. [14:20] skaet: yep [14:24] hum [14:25] NBS is empty again [14:25] cjwatson, I think you said it was some corrupted datas to rm? can you do it again? [14:30] stgraber, the result of the resolver is odd. it removes and holds back a lot of stuff. especially the removal list is surprisingly long with 233 packages [14:31] jibel: well, it was kind of expected that this upgrade mode would remove quite a few more stuff from the system than an online upgrade [14:33] stgraber, I'll upgrade anyway, and we'll see the result. [14:33] I saw one package having a preinst issue trying to do some apporty stuff, ignored it for now to see if the rest works [14:34] looks like the preinst tried to call one of the apport scripts and failed because apport was in the middle of an upgrade [14:34] seb128, cjwatson: removed the cache, rerunning the report [14:35] slangasek, thanks [14:35] slangasek, is that something I've access to? where is it? [14:35] hm, evolution is removed, all of the mono stack :/ [14:35] seb128: lillypilly:~ubuntu-archive/.launchpadlib/ [14:35] infinity, thanks [14:35] seb128: (.../cache/) [14:37] jibel: sure, we don't have evolution on the media, so the upgrader is removing it and replacing by thunderbird [14:38] jibel: same thing for mono, we don't ship it anymore, so it can't get upgraded, causing anything that depends on it to be removed [14:38] jibel: if you were hoping to get the same result as an internet-enabled upgrade, prepare to be very disappointed ;) I'm currently hoping the system still boots and lets me login [14:39] stgraber: You're setting an awfully high bar there. [14:39] stgraber, no, I'm just hoping that the result is usable [14:40] jibel: in theory the upgrader is enforcing that unity is present and some other parts of ubuntu-desktop, so we should be getting some kind of desktop [14:40] :) [14:41] "In theory we should have a desktop", this bar is just getting higher and higher. [14:41] the good news is that in theory it's going to be the last release where we "support" this [14:41] infinity: depends on definition of "desktop", we might be able to stretch that to "X + xterm = desktop" :) === doko__ is now known as doko [15:27] slangasek: I'm trying a restore + upgrade using the tarball attached a week ago by bdmurray, maybe I'll get lucky this time around... [15:28] stgraber, the result of the upgrade looks like a desktop. I had a crash in libxml-sax-expat-perl during upgrade, I ignored it and upgrade finished. [15:28] jibel: ok, I believe it's the same that crashed for me, giving me a python stacktrace in the terminal window [15:29] jibel: will take a look see if that's easily fixable [15:29] but yeah, besides that I'm getting a bootable system with lightdm and unity, so doesn't look too bad [15:30] jibel: confirmed, there's no way of removing libxml-sax-expat-perl... that's what's causing the failure [15:31] jibel: the postinst depends on update-perl-sax-parsers which doesn't exist on the system [15:31] s/postinst/prerm/ [15:32] stgraber, bug 990256 [15:32] Launchpad bug 990256 in libxml-sax-expat-perl "package libxml-sax-expat-perl 0.40-2 failed to install/upgrade: ErrorMessage: subprocess installed pre-removal script returned error exit status 2" [Undecided,Confirmed] https://launchpad.net/bugs/990256 [15:33] right, that's the one... so looks like we need a 10.04 SRU to get out of that one [15:34] I'll check in a few minutes, multi-tasking quite a bit at the moment [15:55] release team: please leave newly uploaded unity stack in -proposed over the weekend. seb128 will give explicit ok before it should be moved over. [15:56] stgraber, skaet: I've reviewed xserver-xorg-video-intel in the queue and confirmed that it looks like a safe, targeted hardware-enablement change. Should I accept this? [15:56] slangasek: yes [15:57] slangasek: ideally, we'd also need mesa for the same issue, though we'd first need to clear the one currently in -proposed [15:58] skaet: quantal-proposed? Why is seb128 wanting it held off? [15:58] that's contrary to the stated policy for $devel-proposed [15:59] slangasek, that was the request at the end of the meeting. Am assuming he wants more testing done on it. [15:59] quantal-proposed is not for testing [15:59] seb128: ^^ [15:59] seb128: if it hasn't already been tested, it shouldn't be uploaded to quantal-proposed. quantal-proposed is only for assuring archive consistency. [16:00] slangasek, usual w.e paranoia [16:00] it has been tested and went through automatic and manual testing [16:01] so no concrete or valid reason ;-) [16:01] slangasek, same reason you don't copy SRU to -updates on friday :p [16:02] slangasek, http://launchpadlibrarian.net/111795520/xserver-xorg-video-intel_2%3A2.17.0-1ubuntu4_2%3A2.17.0-1ubuntu4.1.diff.gz ? if so, yes, agree. [16:02] seb128: ok. so it doesn't really need an explicit sign-off, does it, it just needs us to not copy it until monday? [16:02] skaet: yep [16:03] That's still not why we're supposed to be using -proposed in the development release. [16:03] Remember that, once we have automation, the automation is very unlikely to care whether it's the weekend or not. [16:04] slangasek, yeah, I didn't ask for sign off, I just said 'better to copy it on monday so we have a relaxed w.e' [16:04] ScottK, we use it because otherwise amd64 users get unity removed while it's not built there yet [16:04] Yes. This is what it's for. [16:05] seb128: would you have uploaded today if you didn't have -proposed? [16:05] It's the don't copy it until Monday part that's out of scope. [16:05] slangasek, seb128, yeah my bad for asking for the explicit check. [16:05] slangasek, yes, I just don't want the copy to land to the archive on sunday when I'm not around [16:05] jibel: did you test oneiric to precise upgrades without network? I'm wondering if you'd be hitting the same libxml-sax-expat-perl issue. [16:05] seb128: how about if it lands in 2 hours when you're not around? ;) [16:06] slangasek, I will still be around tonight and looking at stuff tomorrow morning [16:06] so the upload timing works [16:06] having a copy on saturday evening or sunday doesn't work [16:06] ok [16:06] so it's "copy tonight or monday please" [16:06] not sunday :p [16:07] yep, understood [16:07] though it's mostly paranoia [16:07] stgraber, I think I did, but now I have a doubt. Let me try that quickly. [16:07] there are all chances the update is fine [16:07] as cjwatson says, once we're automated you shouldn't rely on this kind of schedule accomodation from the server [16:07] Though we'll probably have to have some kind of equivalent of filing RC bugs to inhibit propagation [16:08] I have another paranoia and that's that all this "let's used -proposed" stuff ends up reproducing Debian Testing/Unstable. [16:08] Which cjwatson isn't helping. [16:08] ScottK: not reproducing testing/unstable is precisely *why* I'm adamant that people not put stuff into -proposed for testing :) [16:08] Agreed. [16:16] to be clear those are not in proposed for testing [16:16] they have been testing in a week in a ppa [16:16] and went through automated and manual testing process [16:16] it's just me being paranoid [16:16] seb128: understood - thanks :) [16:16] just forget about the whole thing and copy on sunday if you feel like doing it ;-) [16:20] Speaking of, is all this X stuff copyable? [16:20] It's been there for >1week [16:20] stgraber, no crash on upgrade from Oneiric, the package is not installed by default. [16:20] tjaalton: Que pasa with the xorg transition? [16:21] jibel: ah, that'd explain it then [16:21] cjwatson, I'm not sure, ted just got bitten badly by the nvidia drivers not working with the quantal-proposed stack [16:21] so I might get away with just fixing it in lucid then, though I suppose we should SRU to the rest just to be safe [16:21] like they would segfault X after using a GL app [16:22] Again, though - not what -proposed is for ... [16:22] I don't think that's what it was used for [16:23] I think it was used to get the abi transition complete before copy [16:23] I'm just pointing that I know about an issue with the new stack though [16:23] tjaalton should comment though [16:25] cjwatson: as of infinity's last check, there were some !x86 drivers still missing [16:25] and we were waiting for an nvidia drop that was supposed to have landed already [16:25] s/was supposed/is supposed/ [16:25] it landed and seems to run fine until you use GL [16:25] or at least for ted [16:25] Question about .changes files and moves to -updates .. [16:25] SpamapS: ? [16:25] openvswitch had a minor change uploaded but did not re-gen the changes back to pre-updates [16:26] thusly, bug 1021530 fell off our sru report [16:26] Launchpad bug 1021530 in openvswitch "[SRU] update to include stable fixes for OVS 1.4" [Medium,Fix committed] https://launchpad.net/bugs/1021530 [16:26] SpamapS: Would be nice if it had been reuploaded with a proper -v .. [16:26] can we get http://launchpadlibrarian.net/112417114/ubuntu-sso-client_3.0.2-0ubuntu2_source.changes reviewed for 12.04.1 [16:26] it's one of the top errors.ubuntu.com issues [16:27] Other than us having to manually mark the bug fix released, will the lack of the -v cause any issues if it is released to -updates ? [16:27] bug #937132 [16:27] Launchpad bug 937132 in ubuntu-sso-client "ubuntu-sso-login crashed with RuntimeError in /usr/lib/python2.7/dist-packages/gi/overrides/Gdk.py: Gdk couldn't be initialized" [High,Confirmed] https://launchpad.net/bugs/937132 [16:27] SpamapS: fwiw, the tooling doesn't currently support us very well in this; in cases where there's an existing -proposed upload, I manually download and check the .changes [16:27] SpamapS: No, it causes no actual issues, just that it requires manual paperwork and tracking, which is a hassle (and error-prone, if the missed bugs don't end up verified correctly) [16:27] slangasek: seems like queuediff could give us a heads up [16:27] queuediff only looks at the diff [16:27] this is "tooling doesn't support us well in this" :) [16:28] queuediff also looks at whether or not there's already an upload in -proposed [16:28] and warns us [16:28] so it seems like it could go one step further, and look at the changes file, and flag it [16:28] I want the whole thing to go a lot more than one step further [16:28] "changes file missing versions already uploaded to -proposed but not in -updates [16:29] I want an interactive tool that I can say y/n in that will run sru-accept and q accept for me ;) [16:29] I agree that better .changes sanity checking should be part of this [16:29] seb128: looks reasonable, diff only contains the bugfix we want, bug is missing a testcase/rational/regression potential though, but with that fixed, I think it's doable [16:33] slangasek: agreed, however we both know incrementally better today is better than perfection never [16:34] SpamapS: absolutely [16:34] I'm just sayin', if someone feels like doing the work, I have a wishlist too ;) [16:35] ok so to the more accute problem of openvswitch.. [16:35] its not on the list of "all green +7 days" bugs .. but I think it should go to -updates [16:35] its not on any CDs either [16:36] cjwatson, infinity: yeah nvidia is badly busted, and i wanted to wait for vbox upstream to try fixing their driver. also, the arm video drivers still need to be updated [16:36] (universe) [16:37] we talked about the stack on #ubuntu-x, and thought that it shouldn't hurt to keep it in proposed until most issues are shaken out, but still copy it before the FF [16:37] SpamapS: provided that whoever copies it over is happy to be on the hook in case of regressions this weekend... [16:38] tjaalton: so in case you missed the discussion above, quantal-proposed is *not* supposed to be used for testing, it's only supposed to be used for getting packages into a consistent installable state so that quantal remains installable; this is effectively a misuse of quantal-proposed [16:38] there's also a showstopper mesa bug affecting unity, which makes it difficult to update it to 8.1 series at the same time [16:39] slangasek: oh [16:39] tjaalton: it happens that in this case having it stay in -proposed isn't going to mess us up because it's a self-contained set of related server packages... but please don't make a habit of this [16:39] testing should happen before upload to -proposed, in a ppa if appropriate [16:40] slangasek: No I was thinking Monday [16:40] SpamapS: right, perfectly ok then [16:40] slangasek: I just want to let the bug subscribers know whats up [16:40] well the problem is the changed video abi that means updates to drivers the x-tem (or debian xsf) doesn't control [16:40] *team [16:41] i guess x-x-video-all isn't installable on arm, x86 is fine [16:42] that's the real showstopper, rest is details then [16:42] archive-wise [16:42] tjaalton: Using it to transition the ABI is fine, using it to test that the software doesn't suck isn't. [16:42] tjaalton: That was sort of the point. ;) [16:43] understood, and it doesn't suck :) [16:43] just that it would break nvidia that's in quantal.. [16:43] tjaalton: So, in this case, as soon as the ARM drivers (and whatever else is missing) are uploaded and built, it should be ready to transition. [16:43] yep [16:43] next week! :) === henrix_ is now known as henrix [16:57] infinity, slangasek: I see that you either uploaded or are listed in the cedarview packages. They are currently both in depwait waiting for libwsbm that'd need promotion to satisfy the dependency. [17:00] stgraber: It's in universe in quantal too, some sort of MIR for that would be nice. And we can't promote it in precise-release, so it would also need a version bump in precise-proposed, just so we could promote the new one. [17:00] (None of this has to do with me, I just re-signed one of the uploads after I jacked it in the queue) :P [17:02] ok :) [17:04] slangasek: hmm, I must be missing something very obvious here... so we have that crash on 10.04 => 12.04 upgrade when removing libxml-sax-expat-perl because its prerm is calling update-perl-sax-parsers which is provided by libxml-sax-perl. BUT libxml-sax-perl is a dependency of libxml-sax-expat-perl. So how is it possible for it to have been uninstalled (rc state) BEFORE libxml-sax-expat-perl was removed? [17:10] stgraber: Is there a dependency loop being broken somewhere? [17:10] stgraber: Depends is meant to guarantee that the depended-on package is there for prerm invocation, but only if there are no loops (same rules as depends and postinst configure) [17:13] infinity: hmm, that's probably the problem. Will have to go read apt.log to try and figure it out then [17:15] infinity: misisng libxml-namespacesupport-perl seems to be the cause of it [17:15] infinity: will try the easy fix by just seeding it... [17:15] it doesn't depend on anything but perl and it's in main, so that's a 15K fix in theory [17:16] and respinning... [17:16] * cjwatson has a second go at landing the Archive.getAllPermissions work for stgraber [17:17] You might get that early next week if I'm lucky [17:17] * infinity ponders some sort of brunch. [17:17] cjwatson: that'd be great, thanks! [17:17] 17436 tests run in 4:02:52.873891, 1 failures, 0 errors [17:17] ^- frustrating [17:17] cjwatson: Close enough. [17:18] jibel: I'll ask you to run the test with the new alternates when they're done building. Looks like your test setup is faster than mine (I don't have a 10.04.4 snapshot, so I need to reinstall and re-upgrade...) [17:19] that's if you're still around. If not, I'll do it here [17:30] jibel: images are done building [17:38] stgraber: "that crash"> link, please? [17:40] slangasek: bug 990256 [17:40] Launchpad bug 990256 in libxml-sax-expat-perl "package libxml-sax-expat-perl 0.40-2 failed to install/upgrade: ErrorMessage: subprocess installed pre-removal script returned error exit status 2" [Undecided,Confirmed] https://launchpad.net/bugs/990256 [18:05] ev, seb128: btw, bug #1024806 is a great example of an SRU regression detected by virtue of errors.u.c ;) [18:05] sorry, bug #1034806 [18:05] Launchpad bug 1034806 in aptdaemon "aptd crashed with UnicodeDecodeError in _emit_acquire_item(): 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/1034806 [18:12] stgraber: this is the perl / perl-modules skew issue. The problem isn't that the dependency has been /removed/, it's that a transitive dependency has been /upgraded/ [18:12] i.e., /usr/bin/update-perl-sax-parsers isn't missing - it fails to compile [18:13] stgraber: see the perl changelog entry for 5.14.2-9 for guidance [18:13] slangasek: hmm, ok. Weird that libxml-sax-perl is marked as rc according to dpkg then [18:13] hrm, that sqlite tracker is wrong, I'll fix it [18:14] stgraber: it wouldn't have been rc at the time libxml-sax-expat-perl failed; it was probably removed in a second clean-up run of apt, not shown in this log [18:15] stgraber, sorry dinner time, syncing now [18:21] do negative lookaheads work in the transition tracker? [18:54] cjwatson: Any idea why this explodes? [18:54] cjwatson: change-override -x optional libxml2 sgml-base xml-core [18:54] cjwatson: Other than the part where I'm setting section instead of priority. Ignore me. [18:55] sucky error message from LP mind [18:55] Quite. [18:58] can someone from the release team please merge https://code.launchpad.net/~micahg/%2Bjunk/transition-tracker/ into the transition tracker if it looks sane? [19:02] slangasek: right, so that's indeed the problem. As it's also a case of using File::Basename, I guess applying the same trick as for mono-gac should work? [19:04] slangasek: as today is your day I thought you'd like to know the sru report has text on mouseover now [19:07] stgraber: without digging further into it, I couldn't say for sure. mono-gac was especially complicated, this one might only require a Breaks: on the old libxml-sax-perl? [19:08] slangasek: http://paste.ubuntu.com/1139826/ is what I get during an upgrade [19:08] try doc-base [19:08] which I think had a relatively simple workaround [19:09] ok, perl-base as a versioned conflict against doc-base (<< 0.10.3) [19:10] hm, maybe it wasn't that [19:10] bdmurray: mouseover> nice, thanks :) [19:10] versioned conflicts are relatively simple [19:10] stgraber: caution; I vaguely recall that in past iterations of this problem, no package metadata was good enough [19:10]