[05:31] bdmurray: thanks, I'll move it to x-x-v-ati-lts-xenial [05:36] and uploaded ^ === tgm4883_ is now known as tgm4883 === tjaalton_ is now known as tjaalton === popey_ is now known as popey [08:49] hi, anyone can look at the SRU queue of xenial for network-manager? [09:35] any archive admin, please remove gitit on arm64 (will be probably removed in Debian too, to let haskell migrate) same failure here [09:35] and also please accept haskell-yesod-auth-oauth2 [10:21] Hi! unity-system-compositor is blocked in proposed due to autopkgtest build problems in unity8 (http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#unity-system-compositor). The problems are not related to unity-system-compositor. Is there a way to unblock this without waiting for unity8 to fix its test? [11:15] Laney: Hi! Is ^^ something you could help with? [11:17] ^ needs rerun with --all-proposed [11:18] ok [11:18] Laney: Mirv: thanks! [11:18] it is running [14:38] hey bdmurray, are you the vanguard for the verification process today? [14:39] i have this patch siloed with an SRU fix; went through the citrain qa: https://requests.ci-train.ubuntu.com/#/ticket/1669 [14:40] i'm re-running the automated tests for it, after a rebuild and manual check [14:40] my question: do i need a verification-needed tag? or can proceed with -done thanks to citrain/qa ? [14:47] dbarth_: I don't see anything in xenial-proposed fixing that so verification seems premature. [15:26] bdmurray: ok thanks; so it needs to land there; i'll see with the ci process [15:50] I think that one armhf is more like stuck than in progress http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ffmpeg ? [15:50] stuck / stale lock file or such [16:05] hmm it seems I can craft the request url too. I don't know however why the armhf was run with "versionless" package [16:05] a missing dpkg-dev (from the test log) is a bit suspicious too [16:07] Mirv: Rerunning. [16:48] slangasek: Could you review that update-manager upload since its mine? [17:00] bdmurray: yes [17:09] bdmurray: your bug ref is marked as a duplicate of another bug, do you want to swap them in LP? [17:10] hmm probably not swap, probably un-dupe? [17:13] slangasek: yeah, I forgot I'd referenced that bug. [17:18] bdmurray: ok, accepted. the test case should also verify that if you didn't have a libwayland-egl1-mesa before, hwe-support-status doesn't try to pull it in? [17:20] slangasek: yeah, that'd make sense [17:23] ok the webp transition is now complete and ffmpeg works too, which were according to Laney the blockers for migration. could US timezone see to fixing any remaining issues, or at least identifying them? [17:24] or if some extra migration hints for example would be needed. I remember that in the past some manual hinting of "try all of these together" was eventually needed. [17:39] ok one thing at least: please ignore kopete tests for https://launchpad.net/ubuntu/+source/kde-runtime - it's part of the webp transition [17:40] I mean, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-runtime [17:40] maybe kdevelop too but I restarted the ppc64el [17:42] slangasek: ^ [17:48] after those, please stare at the update_output.txt [17:48] good night [17:54] slangasek: there is also an update-notifier SRU for Trusty that could use a review [17:55] Mirv: so I'm not seeing how the webp (which I assume is libwebp) transition is complete, or how kopete should be ignored because it's part of it given that there is no kopete package in yakkety-proposed [18:00] bdmurray: I'm confused by the test case - why wouldn't "log in" be sufficient to get you the updated motd? [18:00] and what is 4) "observe a message" - observe it where? [18:02] slangasek: on the terminal you ran the update in, there is a cat of the stamp file which contains the message [18:02] ah [18:02] fwiw I think you should be able to do just step 5) without 3) or 4) [18:03] anyway, accepted [18:04] slangasek: what would call the hwe-eol script? just the process of logging in? [18:11] slangasek: http://people.canonical.com/~ubuntu-archive/transitions/html/auto-libwebp.html this had four items earlier. so kopete tests under kde-runtime: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-runtime (kde-runtime itself is no-change rebuild) [18:11] bdmurray: yes, pam_motd triggers the call to update-motd [18:12] Mirv: so you're asking to bypass the kopete failure as a least-bad option for unblocking the transition, not because the kopete test is a false-positive caused by the transition? [18:12] slangasek: and we're talking about the transition of ~everything (Qt, KDE, webp, ...) which we've been trying to get done for two weeks now, and it's all interlinked with each other [18:12] slangasek: I'm asking because generally yofel has asked to ignore all failing Kubuntu tests at the moment since they don't have manpower to debug them. it seems like a recompilation error they'd need to investigate latest when they want to upgrade it. [18:13] slangasek: it's not likely that is enough to unblock the transitions, there have been tens of earlier fix uploads and all kde tests ignored that were failing [18:14] but at least it might get a better update_output.txt again [18:14] ugh. ok. [18:16] kopete overridden [18:16] any help in getting the transition done and touch landings for all teams less painful would be appreciated, but we'll continue tomorrow again [18:54] So the libwebp transition page says that it's good, but it is still in proposed. [18:54] Is there something that needs to be done there? [18:54] Or, more importantly, is there a way that I should know something needs to be done there? [19:03] tedg: the transition page tells you that all the binaries have been rebuilt for the new library name in -proposed; for knowing why they're still in -proposed instead of in devel requires parsing http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, which Mirv already did some analysis of. Currently the known blocker is kde-runtime needing to get past some failing [19:03] tests [19:04] (audiocd-kio test got a bit wedged on ppc64el, I've retriggered it now) [19:09] slangasek: Ah, so the deps under a package on excuses are not recursive, just the package itself. Then you have to click on those to see if all their deps are building. [19:10] there's no recursion there, yes. Not sure what you mean wrt "building" though [19:10] I mean passing, not building. Sorry. [20:10] slangasek: remind me...where did we end up on the request to restore the symlink from /etc/motd to the motd? [20:26] slangasek: if you see any kde packages versioned 15.12.3 broken by the migration, please just accept those getting broken. We'll update all applications to 16.04.3 once the current transition patch is done [20:27] and fix any remaining issues at that point [20:27] *transition batch [20:31] kirkland: I think we didn't reach a conclusion because we had a set of mutually incompatible requirements, and the only way to resolve this was by getting a consensus together with Debian? [20:31] yofel: ack [20:31] slangasek: ah, okay [20:31] slangasek: where's the best place to document such a discussion? [20:35] kirkland: a page on wiki.debian.org to document a design, and then a discussion on debian-devel@lists.debian.org, might be the path forward [20:35] slangasek: what could possibly go wrong? :-P [20:36] slangasek: okay, I can do that, and will if that's the right approach. pardon me if it feels heavy handed for, literally creating a symlink, as a distro package :-) [20:37] kirkland: I mean a design for the whole shebang, not just for the symlink :) [20:38] slangasek: ah -- that includes update-motd, or is that already sufficiently designed? [20:38] including update-motd [20:38] slangasek: ah, you mean pam_motd [20:38] which is designed, but not documented for Debian's purposes [20:38] slangasek: defining what pam_motd *should* do [20:38] so Debian people keep changing things on the edges and fraying [20:38] slangasek: got it [20:39] slangasek: okay, let me document my thoughts in a google doc, first [20:39] slangasek: then we can move to debian wiki [20:39] slangasek: reminder, I've got no privs (and probably negative karma) in the Debian community [20:40] kirkland, like everyone in debian community =) in general =) [20:40] xnox: LoL :-) === icey is now known as icey|vacation [21:08] slangasek, valgrind-mpi needs to be placed into universe somehow please =) [21:08] (similar to boost-mpi bits, source in main, most things in main, that package into universe) [21:11] xnox: done [21:12] tah [21:21] hi! any archive-admins around to remove some binaries blocking migration please? LP: #1606469 and LP: #1612180 [21:21] Launchpad bug 1606469 in deal.ii (Ubuntu) "Remove deal.ii binaries from archs where it is missing build-deps" [Undecided,New] https://launchpad.net/bugs/1606469 [21:21] Launchpad bug 1612180 in wine-development (Ubuntu) "Please remove wine-developement binaries on armhf" [Undecided,New] https://launchpad.net/bugs/1612180 [21:28] infinity: Review pending SRUs I notice wily is still active in LP [21:55] thanks slangasek [22:03] slangasek: could we also look at removing all packages that build with free pascal on powerpc? LP: #1562480 [22:03] Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480 [22:06] hmm, I thought someone was working on fixing that [22:12] slangasek: i chatted to infinity briefly about it at debconf; my understanding is that even if the problem did get fixed, fpc would need to be re-bootstrapped and all the packages rebuilt on powerpc anyway - at the moment none of the packages are usable on powerpc [22:12] ah [22:19] bdmurray: Some builders are still on wily (RT#92640), so we need to retain the capability to build updates for them. [22:24] cjwatson: ah, okay