[01:46] please mark Ubuntu GNOME 14.04.5 ready for amd64 i386 [05:09] please consider the autopkgtest overriding of the package list gotten from Kubuntu so that we could see about migrating Qt and KDE to release pocket today (we're waiting for silo 73's Unity 8 fix to land only) [05:09] to recap: akonadi-search extra-cmake-modules kconfigwidgets kde-baseapps kde-cli-tools kdelibs4support kdepim-runtime kidentitymanagement kwayland kwin kxmlgui libkscreen marble okteta [07:23] I guess no release team members around this hour now that pitti is away? [07:24] anyway, I've filed bugs for the failing KDE's tests in case some Kubuntu member would want to look at them at some point: https://bugs.launchpad.net/bugs/+bugs?field.tag=kf524 [07:52] infinity: we have a theory of the nvidia breakage.. revert of the maxclients patch (aka avoid newer coreproto which would break older servers). I'll try to rename coreproto for this and revert the patch [07:55] Hi, @cjwatson, I'm the member of Ubuntu Kylin, the ubuntukylin-14.04.5-amd64 iso lack of the casper/filesystem.manifest-remove file , can you help to fix this ? [08:09] infinity, cyphermox, jibel: I think there might be a small issue for 14.04 if someone install with the mac image in that there is no upgrade candidate for 16.04 I think, I'm going to confirm it today though [08:25] davmor2: I see no reason why that would be true. [08:25] davmor2: The amd64 and amd64+mac images have identical contents, it's only the bootloader bits that differ. [08:25] handsome_feng: Err, what? [08:26] tjaalton: Keep me posted... [08:26] tjaalton: If we can come up with a workable fix, I'd like to respin ASAP during EU daytime. [08:26] tjaalton: I'm backwards timezoned just for this. :P [08:26] infinity: I'm staging crap on x-staging [08:26] tjaalton: Kay. [08:27] * infinity goes to download a kylin ISO to see what handsome_feng is on about. [08:27] infinity: yeah the issue I see is if it is looking for amd64+mac image on 16.04 there isn't one I am only guessing though it is just I don't get the there is an upgrade dialogue popup on start up on mac but am everywhere else [08:27] davmor2: Upgrade in update-manager has nothing to do with ISOs. [08:27] infinity: http://cdimage.ubuntu.com/ubuntukylin/trusty/daily-live/current/trusty-desktop-amd64.list [08:28] infinity: cool as I say I'll dig into some more to try and figure out why it isn't happening [08:28] davmor2: Just timing? The check is cronned. [08:29] handsome_feng: Weird. [08:29] infinity: casper/filesystem.manifest-remove disappeared [08:29] handsome_feng: Very weird. [08:29] handsome_feng: We can just respin amd64 so you can test it. [08:30] handsome_feng: There will be a full respin "soon" anyway for the X/nvidia issue. But I'll do yours right now for the manifest thing. [08:30] But also, WTF. :P [08:30] infinity: Thank you very much ! :) [08:53] Mirv: I did those, enjoy [08:55] thank you Laney, now we'll wait for QA's unity8 silo still [09:32] infinity, jibel, cyphermox: Phew sorted it out, it was because the wifi wasn't enabled because of having to install the driver so that meant there was no connection when the cron job checked for updates which is why it didn't trigger before I'm a happy bunny again now :) [09:32] infinity: nvidia works without the revert in xserver, so now I just need to make x11proto-core-dev-lts-xenial installable somehow.. [09:35] tjaalton: Since you have to reupload X stuff for this, can you also remove the broken -legacy package in the process? [09:35] tjaalton: (Low prio compared to fixing nvidia, obviously) [09:35] sure [09:43] infinity: bah, adding C/R/P: x11proto-core-dev isn't enough.. refuses to replace [09:44] packages have versioned depends, and we don't have versioned provides [09:44] Not in trusty, no. [09:44] hmm [09:45] maybe add stuff to the trusty coreproto, import that only in the lts-xenial xserver [09:45] Bundle it with the xserver and use -I? [09:45] or that [09:45] It can't be big. [09:45] That seems the most "sensible", FSVO. [09:45] It guarantees nothing but the xserver will ever pull it in. [09:46] And no user will install it by accident. [09:46] right [09:46] it's just Xpoll.h [09:46] Or package it as lts-thingee, but in a different include subdir, and build-dep on it and, again, use -I [09:47] Oh, if it's literally one file, yeah... [09:47] http://pastebin.com/qK6Xhy7i [09:48] Just bundle it in debian/exclude, and use CFLAGS+=-Idebian/include, IMO. [09:48] I can diff it against the xenial version, call it good, and accept. [09:48] debian/include even. [09:48] Wow, brain. [09:51] hehe [10:41] infinity: server builds, I'll test that if the other drivers now need a rebuild.. [10:41] tjaalton: Ugh. I hope not. [10:42] tjaalton: But if they do, so be it. At least the reviews will be simple. :P [10:43] yeah [10:46] tjaalton: OOI, how do you reliably test if the drivers need rebuilding? [10:46] (And why would they, as long as no external ABI has changed?) [10:50] the boost fun started? [10:51] infinity: just a quick test that things work. the nvidia driver complained about a missing symbol [10:51] oh, i386 sandess [10:53] doko, syncing boost [10:53] this should fix the i386 sadness [11:01] tjaalton: Ahh, I guess you can write an Xorg.conf that loads all the drivers, despite not having their hardware installed? [11:02] tjaalton: And see if they asplode? [11:03] LocutusOfBorg: see boost 1.61.0+dfsg-2 for i386 fix [11:03] ginggs: He knows, hence "syncing boost, this should fix the i386 sadness" [11:03] nothing started [11:06] infinity: when do you need trusty .5 marked by? [11:06] flocculant: There's going to be a respin, so... [11:06] flocculant: But I'll need it all happy and signed off by US Thursday morning (so, EU Thursday afternoon, ish) [11:07] flocculant: Earlier is better, of course. [11:07] flocculant: Anyhow, world will respin once this X bug is sorted. :/ [11:07] infinity: oh great ... what's the respin for? [11:07] oh nvm - should look up ... [11:07] flocculant: X backport hates nvidia binary drivers. [11:08] flocculant: Which, unfortunately, too many people use for me to ignore. [11:08] infinity: ok - tests we've done are just vm ones anyway [11:08] unlikely we'll get real hardware tests done [11:08] and yea ack that :) [11:09] I can try and get at least one hardware test here - with nvidia card [11:09] ginggs, I already syncd a while ago, and so far so good [11:10] flocculant: I'm not fussed about how you test, per se. You guys should know by now that my bar for flavours is "does it boot, install, and reboot successfully", and any bugs beyond that are up to your discretion to care or not. [11:10] doko syncd boost ~7 minutes before the -2 was picked up by lp [11:10] lol [11:10] infinity: yea ofc - depends on when it's respun as to whether I'll get time to do a hardware one [11:11] flocculant: *nod* [11:11] * flocculant goes back to his woefully short lunch break [11:11] flocculant: To be fair, if you've done a reasonable amount of testing on the current image, knowing what's changing in the next (xserver, and possibly grub) lets you focus your testing if you want to. [11:12] infinity: given that it was all vm's - everything was fine [11:15] infinity: meet powersj, our new (replacement) QA person. He's done the mandatory and run-once tests for server for 14.04.5. I see one bug but I suspect that's fallout in the archive from samba's major version bump security update. Perhaps the test case needs updating. [11:16] rbasak: Mmkay. I'm considering letting a grub update in. If I do, there'll be a server respin with all the desktops. [11:18] powersj: So, be prepared to have to do some re-testing. Doing *all* the tests on a respin isn't strictly necessary, but boot/install/reboot certainly is. [11:21] powersj is UTC-6. [11:21] (fyi) [11:23] rbasak: So, next door to me? Kay. [11:23] rbasak: But, arguably, he sleeps normal hours. [11:24] Different country :) [11:24] rbasak: I meant next door, timezone-wise. I can't help it if people live in the wrong country. :) [11:24] :-) [11:24] infinity: maybe your clock is in the wrong country! :) [11:25] jbicha: I can never figure out what country my clock is in. [11:25] jbicha: It's often just drifting in some uninhabited part of an ocean. [11:26] Technically there's always Antarctica. [11:27] rbasak: Well, both poles, and I'm closer to the other one. But despite it making some geometric sense to do so, poles don't observe all timezones at once. :) [11:28] Although, if arctic standard time was, in fact, all times at once, that might explain the Santa speed problem. [11:28] He can deliver to all the boys and girls because he exists at all points in the time-space continuum. [11:28] Go, Santa. [11:29] I think it would depend on your longitude. Perhaps your house is on a pole, so you shift longitudes (and therefore timezone) by walking into the kitchen, etc. That would explain quite a bit :) [11:29] Still doesn't explain how he can eat so many cookies, though... [11:29] * rbasak understands that it doesn't actually work like that, but whatever [11:31] rbasak: It doesn't, but I now want to build my summer home directly on a pole, pie-shaped, with 24 rooms. [11:32] Err, by "pie-shaped", I mean "round, with pie-sliced rooms", but you got that. [11:34] Shame it wouldn't really have the correct effect with the sun, because of the tilt. [11:34] Depends on how big your house is. [11:34] Though walking to the kitchen might take you a while then. You'd probably want to have a few extra bedrooms, kitchens and bathrooms on the way. [11:36] infinity: intel at least is still quite happy. and none of the drivers import resource.h from xserver-xorg-dev [11:36] tjaalton: I'm going to extrapolate that resource.h is the only header that includes that proto header? [11:36] it's the one that got ResourceClientBits() added in 1.18 [11:37] Kay. [11:37] nvidia uses it for "something" [11:37] probably just to piss on us [11:37] Heh. [11:38] so, I'll upload this one, -legacy-lts-xenial is gone as well [11:38] tjaalton: Alright, let's go for the least invasive change we can, and make it happen. I'd like it if you could test loading all the drivers (that must be doable, at least to the point where they probe and bail), before we decide we're good. [11:39] ok [11:43] tjaalton: I assume it should just be a matter of specifying each driver, starting X, and checking the log that it loaded, found no cards, and failed? It's been years since I wrote an X.conf, though. :P [11:43] yeah should be simple, writing it now [11:44] * infinity goes to test that grub SRU so he can slip it in. [11:54] infinity: yeah, they all load [11:54] tjaalton: Excellent. [11:54] tjaalton: Upload away. And thanks. [12:14] tjaalton: Looks good. Accepted. [12:15] tjaalton: I was going to whine about the lack of bug ref, but (a) I don't recall anyone filing a bug for the issue and (b) I have a test setup here to verify, so meh. [12:16] right, haven't seen a bug either [12:48] Ooo. The rain seems to have stopped for a few minutes, going to use this window to make a breakfast/coffee run. [12:48] Will verify and promote that X when I get back, and then respin $world. [12:48] davmor2: Can you try to get the word out to lazy flavours that we're, like, doing a point release? A few haven't done any tests yet. [13:17] infinity: I might be able to there is a listing somewhere of who to ping I'll dig it out after and start pinging them [13:31] davmor2: Also, if you haven't been reading backscroll, there'll be a (hopefully final) respin in an hour or two. [13:43] infinity: what's wrong with x now? [13:43] davmor2: A bad revert broke nvidia. [13:44] jibel: ^ [13:45] infinity: see and then the devs wonder why I hate them, they keep breaking stuff ;) [13:45] davmor2: That's our job. [13:46] infinity: no that's just it breaking it is my job not theirs ;) Their job is fixing all the things I break :D [13:47] davmor2: Nope. It's our job to break, your job to discover, and our job to fix. :) [13:48] If we didn't do the first bit, the next two wouldn't be necessary, and half of us and all of you would be out of jobs. [13:48] infinity: hahaha [13:48] infinity: can we have netboot added to the tracker too please [13:49] davmor2: If I can remember how to do that manually. Not that I pay attention to what the tracker says about it anyway... [13:49] (Since it's already "released" and has been for a week) [13:50] infinity: 14.04.5 has been released for a week what ;) [13:50] davmor2: No, netboot has. Netboot is in no way tied to milestones. At all. [13:50] davmor2: It's just a product of debian-installer builds. [13:52] davmor2: But there it is. [13:53] infinity: ta [13:53] infinity: is that safe to test now while I wait for the other images? [13:53] davmor2: Yeah, it's not changing. [13:53] infinity: awesome [13:56] flocculant: ^ respin for xorg \o/ [14:16] tjaalton: Okay, nvidia-352, nvidia-340, nouveau, and intel tested on this laptop with the new X, all looks good. nvidia-304 doesn't work (the really old one), but that's not X's fault, looks like it's incompatible with the kernel. [14:19] infinity, o/ [14:20] infinity, I saw you and rbasak discuss a possible new respin, what mailing list should I be on to be notified of that? [14:20] ubuntu-release@, perhaps. [14:22] great thx [14:35] infinity: how's it coming? [14:37] davmor2: Waiting on the publisher, respins will commence in about 30m. [14:37] Or less. [14:37] (or your pizza's free) [14:38] * davmor2 makes the internet for the builders slower free pizza sounds fun [14:49] netboot 64 done moving onto 32 [14:52] infinity: excellent, tseliot says his doesn't work but I guess it's still the wrong (old) version :) [14:52] afk -> [15:00] infinity: err... I never seem to get notifications about drivers failing to build... [15:04] davmor2: yea - knew it was happening :) [15:05] infinity: for your info - at the end of the yak cycle akxwi-dave is taking over for me - at least for one cycle - he'll carry on being in here (though I'll not be absent - just being lazy) [15:06] he's in our release team now too btw [15:08] tseliot: It builds, it doesn't insert. [15:09] infinity: do you happen to have the exact error? [15:09] tseliot: Lemme look. [15:10] tseliot: "Unknown symbol mtrr_del" (and mtrr_add on the next line) [15:10] infinity: ok, it looks familiar, thanks [15:11] tseliot: Anyhow, 352 and 340 work. But I assume some old cards need 304. [15:11] (Though, I'd also assume people with ancient cards aren't gaming or running blender and probably mostly use nouveau, but...) [15:11] infinity, tjaalton: also, the new X works here now [15:11] it should be a quick fix (304) [15:13] infinity: yes, the patch is already in xenial. I'll backport that [15:14] tseliot: Ta. [15:22] powersj: at http://iso.qa.ubuntu.com/ if you click through to a test case page, you can subscribe to all the test cases for a flavor [15:22] and it should send you an email when a new image is ready for testing [15:23] jbicha, awesome thx [15:33] infinity: the packages are in -proposed. Here's the SRU: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304-updates/+bug/1609460 [15:33] Launchpad bug 1609460 in nvidia-graphics-drivers-304-updates (Ubuntu) "SRU: nvidia-304 can't be loaded with the lts-xenial kernel" [High,In progress] [15:34] tseliot: Yep, just waiting for the diff to be generated. [15:34] infinity: great, thanks [15:34] Laney: could you override plasma-framework and unity8 still? p-f has known old bug on s390x, and unity8 autopkgtest fix is slightly delayed but it's pretty minor in all of the test suite and the landing will happen pretty soon. we'd like to ease up people's lives by getting the proposed transition done [15:39] Oh my. 14.04.5 to 16.04.1 upgrade sure doesn't work right. [15:39] Gah, and that's why, [15:40] tjaalton: You didn't do the transitional packages from lts-xenial -> xenial. [15:46] infinity: oh? [15:47] (xenial-amd64)root@nosferatu:~# apt-cache search x*lts-wily | wc -l [15:47] 101 [15:47] (xenial-amd64)root@nosferatu:~# apt-cache search x*lts-xenial | wc -l [15:47] 20 [15:47] Seems suspect. [15:48] (Those 20 are the kernel transitional packages) [15:48] so xenial needs something [15:48] Yes, xenial needs the lts-xenial equivalent of those lts-wily transitionals. [15:48] Which I would have assumed would have made it in the release pocket, since we already knew the name of the backport stack, but oh well. :P [15:48] It can be an SRU. [15:49] infinity: I hope that's not another issue now :( [15:49] davmor2: Nothing that affects the 14.04.5 ISO. [15:49] phew [15:49] davmor2: It's a fix needed in xenial for upgrades *from* 14.04.5 [15:50] hrm, I need to put this in git [15:50] tjaalton: The failure mode it pretty spectacular too. I somehow end up with x-driver-*-all removed, and no more input drivers. Get lightdm, and no input devices, which basically means "hung machine" to any normal user. :P [15:50] (like, it'd be better if it broke so bad that X didn't start) [15:51] Oh well. Fun bugs are fun. [15:51] ok, I'll fix that [15:51] Ta. [15:52] Should trivially work if the transitionals are there, I believe. [15:52] It just really doesn't without them. [15:54] tjaalton: Would be nice to get this one landed before I release tomorrow. Cause you just know the first thing people are going to do after the install a fresh 14.04.5 is click on the "upgrade to 16.04 available" button. :P [15:54] Because people aren't smart. [15:54] yean on it now [15:54] *yeah [15:56] the transitionals are only for x86? [15:57] We built the stack for all arches, so transitionals should be too. [15:58] Did we screw that up for u/v/w? [15:58] not historically [15:58] yep [15:58] Oh well. Can fix that in a second pass. [15:58] Clearly not enough people have noticed to complain. [16:01] * infinity takes a break while the world burns^Wbuilds. [16:03] Just a quick question, should http://changelogs.ubuntu.com/meta-release show the 16.04.1 release rather than just 16.04 [16:04] So that 14.04.4 users would be shown that there is new release available to upgrade to? [16:04] DJones: They get shown there's a new release, but yes, the version should be bumped. [16:05] Just had somebody asking in #ubuntu when the release would become available for upgrade, so wondered if it wasn't being offered yet because of that [16:06] DJones: It's definitely being offered, I literally just tested that on a 14.04 machine. [16:07] Right, no worries, must have been a PEBKAC moment for the user [16:07] DJones: Well, the check is cronned, and might be both weekly and staggered, so not everyone sees it right away. [16:07] DJones: To avoid crippling the world. [16:07] Right, that would explain it [16:09] infinity: Thanks for the info & update [16:13] Mirv: Why not do a unity8 with just the fix we need for the tests? [16:13] I'm tired of unity8 needing so much hand holding, we should be able to do better there [16:14] Can we turn off Mythbuntu Trusty ISOs [16:16] Mirv: plasma-framework is already ignored, AFAICS [16:27] infinity: Do the X fixes in the new RCs pertain to the nvidia issue? [16:37] dmj_s76, the latest respin was for nvidia i believe yes [16:38] good...I'll test when it's ready [16:38] appears to still be yesterday's isos [16:40] from the list of builds queubot has reported i don't see Ubuntu Desktop yet [16:50] Laney: since there's a huge silo which has seen a lot of QA. it was supposed to land today but seems not. there's one plasma-framework test that is not ignored at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-framework [16:51] Laney: we can also wait for it still, this was just an idea to not wait for it since there's no big benefit as such from waiting [16:53] Mirv: I'm saying it would have been simpler for the distro if the test fix was uploaded separately rather than entangled in a huge silo [16:53] I bumepd plasma-frameworks [16:57] I agree. it just tends to be that there are so many teams needing unity8 landings, that at the velocity of the landings and their QA take and the deadlines that are wanted to be met, they put many little things like yakkety autopkgtests fix to be part of a bigger feature landing. [16:57] the only problem here is that QA found another thing in that feature to be fixed.. [16:58] Laney: thanks for the plasma-framework bump, that leaves unity8 as the only excuses page blocker [16:58] infinity: there haven't been transitional packages for virtualbox-guest-dkms et al in the past [16:59] wonder if there should [17:35] infinity: managed a hardware trusty with nvidia card [17:55] yay finally [17:57] infinity: keep finding more and more lts-transitional bugs.. [18:16] infinity: the diff would look like this http://pastebin.com/jLe4jtSK [18:17] with a placeholder for virtualbox [18:32] infinity: uploaded, review it from the queue.. [18:52] I've got a firefox update to publish via the security pocket - do I need to wait until 14.04.5 is done? [18:54] hmm, why is Edubuntu still marked as rebuilding [18:54] Ubuntu Studio too [18:54] who's doing autopkg test sanity work while pitti is on vacation? [18:58] infinity: any idea what's going on here? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/edubuntu/+build/71453 [19:01] can anybody please retry curl/systemd autopkgtestsuite? [19:01] "You submitted an invalid request: You are not allowed to upload systemd or curl to Ubuntu, thus you are not allowed to use this service." [19:01] but I did upload curl! :) [19:03] * stgraber cancels the Edubuntu build and re-triggers [19:05] * stgraber cancels the ubuntu studio one too [19:07] stgraber: Thanks :) [19:07] stgraber, Thanks - I was just logging in to do it [19:59] stgraber: We had an error with the amd64 build, it seems (we got the report to our mail list at 21:10). How's the Edubuntu builds coming along? [20:00] infinity: I'm going to test some more, but I believe today's iso fixes the nvidia login loop [20:09] zequence: our images are supposedly still building, I see one of yours succeeded and the other one is still going [20:12] all 3 building images are at the fdupes step. This does seem to take a while typically, will start worrying if none of them finish within 30min or so [20:13] it could be an I/O problem on scalingstack causing this to be super slow for some reason, but we'll see [20:13] (not seeing any report of scalingstack issues anywhere, so hoping those rebuilds will work) [20:13] Only mentioning because we got the build fail log after you had retriggered. [20:13] what's the version on that build failure e-mail? [20:14] what's building now is 20160803.1 [20:14] if the e-mail is about 20160803, then just ignore [20:14] Ah, ok [20:36] doesn't look like things are stuck so far, just slow. Edubuntu 32bit is finishing now. [20:38] Studio 64 bit still sitting on fdupe step [21:21] they all seem to have moved on to something else now, so still making progress [21:28] please mark Ubuntu GNOME ready for amd64 i386 [21:29] jbicha: done [22:59] chrisccoulson: Unless it's urgent, I'd prefer you hold off until tomorrow. [23:01] infinity, that's fine, there's nothing particularly urgent in https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/#firefox48, and it's too late in the evening for me to do it now :)