[00:00] -queuebot:#ubuntu-release- Unapproved: gnome-devel-docs (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra) [00:02] sarnold: around? I'd like to get bug 1630700 fast-tracked through [00:02] bug 1630700 in kcoreaddons (Ubuntu Precise) "CVE - KMail - HTML injection in plain text viewer" [Undecided,In progress] https://launchpad.net/bugs/1630700 [00:03] -queuebot:#ubuntu-release- Unapproved: ansible (xenial-proposed/universe) [2.0.0.2-2 => 2.0.0.2-2ubuntu1] (no packageset) [01:15] wgrant: If a custom kernel will get us over the hump Right Now, let's do it. [01:15] wgrant: Agreed it's a terrible long-term solution, but not being able to build things we want on images today is also pretty ungood. [01:17] infinity: Absolutely. [01:17] wgrant: Other than kernel build time, which I'm intimately familiar with, what kind of turnaround could we get on that? [01:18] infinity: Soon™ [01:18] (And said kernel could be neutered in debian/rules to exit 1 on DPKG_BUILD_ARCH != arm64, arm64 actually builds pretty fast compared to most) [01:18] Err, HOST_ARCH. [01:18] Though either would work in a non-cross env. :P [01:20] infinity: We can get new images out in less than half an hour one the packages are available. [01:20] Usually well less than half an hour, now that arm64 VMs aren't silly :) [01:21] -queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (xenial-security/universe) [4.4.0.1030.22 => 4.4.0.1030.22] (kernel) (sync) [01:22] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (xenial-security) [4.4.0.1030.22] [01:23] wgrant: Need any help wrangling kernel packaging, or are you good there? [01:23] infinity: I'm reasonably competent, particularly when not changing ABI :) [01:23] -queuebot:#ubuntu-release- Unapproved: rejected linux-meta-snapdragon [sync] (xenial-security) [4.4.0.1030.22] [01:23] wgrant: Heh. When not changing ABI, the best trick is to append to the current changelog entry and NOT MAKE A NEW ONE. [01:23] Then no ABI checker invoked, and magic. [01:24] Precisely. [01:24] wgrant: Right, then I'll keep out of your hair. [01:24] It took me a couple of years to work that hack out. [01:24] wgrant: Lemme know when you think it's ready for a spin, and I'll lob things at it. [01:25] I should be up for a Very Long While still. [01:25] In the process of reversing my clock. [01:25] Well, inverting, not reversing. [01:25] infinity: It'll be a good while, currently in a couple of meetings. [01:25] Though hopefully wrapping up now, then will get onto it properly. [01:25] wgrant: All good. I intend to be awake all through London work day. [01:25] wgrant: TO set a trend for the rest of the week. [01:26] How I plan to do this, given that I woke up at 7am Calgary time, I'm not yet sure. [01:26] But I suspect caffeine might come into play. [01:29] -queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu481 => 20101020ubuntu482] (core) [01:30] infinity: Staying on UK time zones are fun, I did that over my summer vacation for a few weeks. :P [01:30] tsimonq2: I do it all the time, but it's always harder to shift one's clock on purpose rather than by accident. :P [01:31] infinity: I can agree with that. [01:31] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu482] [01:31] -queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu2] [01:32] -queuebot:#ubuntu-release- Unapproved: accepted gnome-devel-docs [source] (yakkety-proposed) [3.22.1-0ubuntu1] [01:34] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (yakkety-proposed) [340.98-0ubuntu1] [01:46] infinity: logging off for some sleep. use ancient communication methods should you really need me for some reason. [01:47] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161011) [01:47] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161011) [02:30] -queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Final] (20101020ubuntu482) has been added [02:30] -queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Final] (20101020ubuntu482) has been added [02:30] -queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Final] (20101020ubuntu482) has been added [02:30] -queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Final] (20101020ubuntu482) has been added [02:31] -queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Final] (20101020ubuntu482) has been added [02:31] -queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Final] (20101020ubuntu482) has been added [02:31] -queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Final] (20101020ubuntu482) has been added [03:47] cjwatson, normally in 64bit all of physical memory is "direct mapped" so if the h/w is using a large physical space then we will chew a large chunk of KVA for the direct map [03:50] still not clear as to why that is visible in userspace in any sense === maclin1 is now known as maclin [06:01] -queuebot:#ubuntu-release- New sync: openfoam (yakkety-proposed/primary) [4.0+dfsg1-3] [06:12] -queuebot:#ubuntu-release- Unapproved: python3.6 (yakkety-proposed/universe) [3.6.0~b1-1ubuntu2 => 3.6.0~b2-1] (no packageset) [06:13] -queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (yakkety-proposed) [3.6.0~b2-1] [06:18] -queuebot:#ubuntu-release- New: accepted linbox [arm64] (yakkety-proposed) [1.4.2-1~build1] [06:18] -queuebot:#ubuntu-release- New: accepted linbox [i386] (yakkety-proposed) [1.4.2-1~build1] [06:19] -queuebot:#ubuntu-release- New: accepted linbox [armhf] (yakkety-proposed) [1.4.2-1~build1] [06:19] -queuebot:#ubuntu-release- New: accepted linbox [ppc64el] (yakkety-proposed) [1.4.2-1~build1] [08:19] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-304 (yakkety-proposed/restricted) [304.131-0ubuntu5 => 304.132-0ubuntu1] (ubuntu-desktop) === jamespag` is now known as jamespage === santa is now known as Guest77141 === michihenning is now known as michi [09:15] infinity, apw: I'm going to kill the currently running linux tests again, as they still keep breaking the testbed and are stuck in an eternal retry loop; but I'll try to collect the console-log this time === marcusto_ is now known as marcustomlinson [09:27] apw: filed bug 1632252 with some logs/details [09:27] bug 1632252 in linux (Ubuntu) "linux autopkgtest kills sshd in testbed" [Undecided,Confirmed] https://launchpad.net/bugs/1632252 [09:27] apw: sounds like sshd gets OOM-killed [09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Final] has been updated (20161011) [09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Final] has been updated (20161011) [09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Final] has been updated (20161011) [09:55] -queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core) [09:56] infinity, slangasek: ^ this drops the hard python3-launchpadlib dependency again (from http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz) and adds a graceful fallback [09:56] this should clean up most of http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt [10:03] which will mean that the PPA changelog handling randomly doesn't work for users depending on whether they happen to have python3-launchpadlib installed? [10:04] I mean, I guess I see why you're doing it, but avoiding this was why I asked in review of that feature for it to be just made a dependency rather than conditional [10:04] cjwatson: I'd rather seed python3-launchpadlib on desktop then, TBH [10:05] maybe the feature can also be reworked to do a single REST call via urllib, but I don't want to do this "under the gun" [10:05] pitti: seeding in desktop seems like a reasonable compromise, if people are OK with that [10:05] it doesn't do anything authenticated, so I guess getting a changelog with plain urllib should be fairly easy [10:05] maybe as a Recommends [10:05] *nod* [10:06] not sure who has the last word on that, but I'm happy to make the seed changes and update ubuntu-meta if we want to go ahead with this [10:06] It should be relatively easy to redo by-hand without lplib, indeed [10:06] One problem with seeding in desktop is, which desktops [10:08] hm -- how about we move the Depends: to update-manager? [10:08] (it previously was on python3-update-manager which is in standard) [10:08] update-manager is optional [10:09] then we don't need seed changes, and this conceptually sounds "more correct" [10:09] and to u-m-kde [10:10] * pitti self-rejects and reuploads, that's better than fiddling with seeds [10:10] Seems reasonable if you retain the optionality in the code [10:11] This is how to do what u-m does by hand: [10:11] $ curl -s 'https://api.launchpad.net/devel/archives?ws.op=getByReference&reference=%7Ecjwatson/ubuntu/ppa' | jq .self_link [10:11] "https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa" [10:11] $ curl -s 'https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa?ws.op=getPublishedSources&source_name=ant&exact_match=true&version=1.9.7-3ppa1' | jq '.entries[0].self_link' [10:11] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (yakkety-proposed) [1:16.10.7] [10:11] "https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285" [10:11] $ curl -s 'https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285?ws.op=changelogUrl' | jq [10:11] "https://launchpad.net/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285/+files/changelog" [10:11] but you do have to make sure that all the quoting is correct [10:12] yeah, TBH that sounds more like a z thing [10:12] https://api.launchpad.net/devel/archives is a hardcoded base, and all of reference, source_name, and version are inputs that must be URL-escaped [10:13] Easy enough, but yeah, can be done in z [10:14] (Do we have a name yet?) [10:15] for the Zealous Zombie? [10:16] Zenial Zebra. [10:16] -queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core) [10:17] some have been guessing at Zazzy Zorilla [10:17] infinity, slangasek: ^ updated update-manager as per discussion with cjwatson; this is now self-contained (does not need seed changes) [10:18] I think we can drop xml-core's Depends: perl, to clean up that from "standard" as well (only using modules from perl-base); will confirm and then upload/file Debian bug [10:19] with these two, the remaining priority-mismatch items should be valid [10:20] acheronuk: Yeah, I'm ignoring guesses because they're ~never right [10:21] pitti: the changelog seems a bit wrong now? [10:21] pitti: wait, maybe I'm suffering from caching [10:21] cjwatson: ah, it should probably say "lower .. from python3-update-manager's Depends"? [10:22] cjwatson: http://launchpadlibrarian.net/289188605/update-manager_16.10.7_source.changes is the current version that I uploaded [10:22] no, I'm OK with it once I avoid looking at the old cached version [10:22] (but am no longer release team, so not accepting) [10:24] cjwatson: yep, my guess always seems wrong [10:54] -queuebot:#ubuntu-release- Unapproved: xml-core (yakkety-proposed/main) [0.15 => 0.15ubuntu1] (core) [10:55] ^ will fix the perl priority-mismatches. This was a recent regression from https://anonscm.debian.org/git/debian-xml-sgml/xml-core.git/commit/?id=fed34e0 [10:56] i. e. accidentally dropping the dh_perl -d option [10:56] (also filed as Debian bug 840410) [10:56] Debian bug 840410 in xml-core "xml-core: Drop perl dependency" [Wishlist,Open] http://bugs.debian.org/840410 [10:56] Laney: ^ as this is quite straightforward, mind reviewing/accepting this? [10:57] reviewing u-m is also appreciated of course, to clean up most of priority-mismatches so that we can get it release-ready [11:06] pitti: sure [11:13] cjwatson: I'm still voting for Zealous Zebu :P [11:13] s/voting/hoping/ [11:16] tsimonq2: lol. you changed your mind AGAIN? [11:17] acheronuk: no I only said Zazzy Zorilla because I thought Barry Warsaw leaked the codename, turns out he made it up... :P [11:18] tsimonq2: I swear there is a subtle disinformation plot by canonical each year to keep the real one under wraps [11:19] -queuebot:#ubuntu-release- Unapproved: accepted xml-core [source] (yakkety-proposed) [0.15ubuntu1] [11:19] acheronuk: cjwatson linked me to a graph yesterday... [11:20] * tsimonq2 finds it [11:20] acheronuk: http://people.canonical.com/~cjwatson/tmp/release-name-notice.png [11:22] interesting [11:32] pitti: unorthodox syntax on Suggests there [11:32] * Laney built it to check it works (it does) [11:33] * rbasak believes he predicted Yakkety Yak before it was named [11:33] Though in hindsight it was obvious I guess [11:33] and argh at all the trailing spaces in update-manager/d/control [11:34] (not new) === Guest77141 is now known as santa_ [11:35] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (yakkety-proposed) [1:16.10.7] [11:44] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (yakkety-proposed/universe) [10.2.7-2 => 10.2.7-3] (no packageset) (sync) [11:44] -queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [sync] (yakkety-proposed) [10.2.7-3] [11:46] Laney: you mean trailling commas? [11:47] Laney: trailing spaces> yeah, my vim loudly complains too, but minimal diff for review, etc. [11:49] pitti: It's like [11:49] Suggests: [11:49] python3-... [11:57] -queuebot:#ubuntu-release- Unapproved: congress (yakkety-proposed/universe) [4.0.0~rc1+dfsg1-1 => 4.0.0+dfsg1-2] (no packageset) (sync) [11:57] -queuebot:#ubuntu-release- Unapproved: accepted congress [sync] (yakkety-proposed) [4.0.0+dfsg1-2] [12:31] -queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu2.16.10.1 => 2.0~rc3-0ubuntu3.16.10.1] (ubuntu-server) [12:32] good morning [12:33] Laney: oh, oops [12:33] Laney: fixed in bzr [12:33] hey cyphermox [12:34] -queuebot:#ubuntu-release- Unapproved: designate-dashboard (yakkety-proposed/universe) [3.0.0~rc1-1 => 3.0.0-2] (no packageset) (sync) [12:35] -queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [sync] (yakkety-proposed) [3.0.0-2] [12:36] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu3.16.10.1] [12:37] apw: do you know about the fate of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux ? [12:37] I suppose we should release that RSN so that we can rebuild images? [12:41] pitti as far as i can tell it is as good as the previous one, so i guess as those tests are not going to ever come in we'll need to hint it [12:43] apw: oh right -- I was blindly assuming they would use a tracking bug [12:43] apw: hinting [12:45] seb128, jbicha: do we want to let bug 1631955 into yakkety, or remain as an SRU? [12:45] bug 1631955 in evolution-data-server (Ubuntu Yakkety) "Update e-d-s to 3.22.1" [Medium,Fix committed] https://launchpad.net/bugs/1631955 [12:46] (seb128, jbicha: we still have a kernel and two other packages to land before respinning images) [12:46] pitti, letting jbicha comment, I didn't look at this update [12:46] pitti, we don't plan respins after that? [12:47] seb128: I don't know; just saying that the current images can't possibly be final [12:47] pitti, it's a bit suboptimal that we have the current firefox blocked in proposed but I guess it is what it is now? [12:47] k [12:47] seb128: well, firefox is FTBFS, not much that we can do other than fixing it [12:48] but that's fine as an SRU [12:48] not optimal though [12:49] there might be some security issues in the previous verison [12:49] oh, also that's using an google api key that we revocated [12:49] the new key was added in https://launchpad.net/ubuntu/+source/firefox/49.0+build4-0ubuntu1 [12:49] well, if we have a fix now/today, I'm sure everyone would be happy to get it in :) [12:49] chrisccoulson, ^ [12:50] pitti, or we could declared firefox unsupported on ppc64el like it is on powerpc and s390x and delete the binaries like we did for those... [12:51] I don't think I'll be able to spend time investigating a ppc64el-specific startup crash in Firefox tbh [12:51] pitti: I'm ok with letting e-d-s in now, it worked fine for me [12:51] (which is what the build failure is) [12:51] the new e-d-s apparently doesn't actually fix the google authentication problem [12:54] I guess we can point ppc users to epiphany? since chromium isn't supported there either [12:58] -queuebot:#ubuntu-release- Unapproved: python-pycadf (yakkety-proposed/main) [2.2.0-2 => 2.4.0-1] (ubuntu-server) (sync) [13:11] seb128, have you used firefox in proposed btw? [13:11] chrisccoulson, not really, but I can give it a try if you want ... anything in particular? [13:11] chrisccoulson, did you see the ping from rico early on ubuntu-devel btw? [13:12] seb128, well, I just thought - the build in the release pocket is now so ancient that it was built with the old compiler [13:12] I didn't see a ping earlier, let me check [13:13] chrisccoulson, it was at 8:25 u.k [13:13] ahh [13:13] so, firefox has the same issue as https://bugs.chromium.org/p/v8/issues/detail?id=3782 which already affected chromium and oxide [13:14] Firefox really needs a maintainer that cares about it ;) [13:17] oh, apparently firefox doesn't have this problem, and the bug ricotz linked is thunderbird specific === barry` is now known as barry [13:22] chrisccoulson: I've been using firefox from y/proposed for several days and it seems ok [13:35] and the one from release is dire :/ [13:42] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.5 (yakkety-proposed/universe) [1:3.5.2-3ubuntu1 => 1:3.5.2-5] (no packageset) (sync) [13:43] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.5 [sync] (yakkety-proposed) [1:3.5.2-5] === medberry is now known as med_ === jgrimm-out is now known as jgrimm [14:02] pitti, nothing is running in autopkgtest? [14:07] -queuebot:#ubuntu-release- Unapproved: xfsprogs (yakkety-proposed/main) [4.3.0+nmu1ubuntu2 => 4.3.0+nmu1ubuntu3] (core) [14:07] ^ fixes fallout from v4.8 kernel headers ... [14:14] cyphermox: how are we looking for the new shim do you know anything yet? [14:30] -queuebot:#ubuntu-release- Unapproved: openorienteering-mapper (yakkety-proposed/universe) [0.6.3-2build1 => 0.6.5-1] (no packageset) (sync) [14:31] -queuebot:#ubuntu-release- Unapproved: accepted openorienteering-mapper [sync] (yakkety-proposed) [0.6.5-1] [14:36] balloons: no, we are in freeze :) [14:37] balloons: juju is, actually (i386 and amd64 failed already) [14:37] -queuebot:#ubuntu-release- Unapproved: gdb (yakkety-proposed/main) [7.11.90.20161005-0ubuntu1 => 7.12-0ubuntu1] (core) [14:37] pitti, right it was of course what I was looking for. I saw amd64 failed, but I can't see the log proper until it finishes -- unless there's something I don't know [14:38] -queuebot:#ubuntu-release- New: accepted openfoam [sync] (yakkety-proposed) [4.0+dfsg1-3] [14:39] davmor2: sorry, no news to be given [14:40] apw: xfsprogs> cheers! is that an upstream backport? [14:41] -queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (yakkety-proposed) [4.3.0+nmu1ubuntu3] [14:41] pitti, no that is allll me [15:04] -queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [7.12-0ubuntu1] [15:04] -queuebot:#ubuntu-release- Unapproved: vlan (xenial-proposed/main) [1.9-3.2ubuntu1 => 1.9-3.2ubuntu1.16.04.1] (core) [15:05] -queuebot:#ubuntu-release- Unapproved: vlan (precise-proposed/main) [1.9-3ubuntu6 => 1.9-3ubuntu6.1] (kubuntu, netbook, ubuntu-desktop, ubuntu-server, unr) [15:05] -queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10 => 1.9-3ubuntu10.1] (core) [15:16] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20160913.1-0ubuntu1 => 1:20161011.1-0ubuntu1] (no packageset) [15:21] chrisccoulson, seb128: removing current ppc64el firefox binaries seems reasonable to me; Laney, infinity, opinions? [15:22] pitti, I should point out, we don't block firefox security updates for build failures on those 3 architectures anyway [15:22] And the updates are never tested on those architectures in any case [15:23] pitti, +1 from me, it might require to delete/tweak a bit more due to rdepends, whoever handled the drop of powerpc earlier in the cycle should know the details of what is needed though [15:23] firefox | 49.0+build4-0ubuntu0.16.04.1 | xenial-security | source, amd64, arm64, armhf, i386, ppc64el [15:24] chrisccoulson: I was wondering because it apparently did build for xenial still -- gcc 6, presumably? [15:24] pitti, I uploaded thunderbird with a build failure fix, but I've since been made aware of https://bugzilla.mozilla.org/show_bug.cgi?id=1251576, so it won't run anyway (it's a similar issue to https://bugs.chromium.org/p/v8/issues/detail?id=3782, which we already worked around in chromium and oxide) [15:24] Mozilla bug 1251576 in General "GCC6 - TB crashes due to removed null pointer checks for "this"" [Normal,New] [15:24] pitti, yeah, most likely [15:25] -queuebot:#ubuntu-release- Unapproved: libreoffice (yakkety-proposed/main) [1:5.2.2-0ubuntu1 => 1:5.2.2-0ubuntu2] (kubuntu, ubuntu-desktop) [15:25] pitti: We forced it last time [15:26] Laney: you mean with a britney hint, not removing packages? [15:26] yep [15:26] that seems a bit awkward [15:26] why? [15:26] Laney: hm, does that still turn up at NBS? [15:27] our report doesn't show that, AFAIK it only runs for amd64 [15:28] Firefox shows up at the bottom of /update_output.txt [15:28] List of old libraries in testing (2): [15:28] firefox: s390x powerpc [15:28] oh, this? [15:28] well, we really should remove the old binaries properly [15:29] * pitti → meeting, bbl [15:49] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-proposed/main) [0.92 => 0.92ubuntu1] (desktop-core, ubuntu-server) [16:00] -queuebot:#ubuntu-release- Unapproved: python-tornado (yakkety-proposed/universe) [4.4.1-2ubuntu1 => 4.4.2-1ubuntu1] (ubuntu-desktop) [16:01] pitti, balloons, stokachu: seems that juju-core is still failing autopkgtests, has this been analyzed? [16:01] slangasek: yes, balloons and I just debugged it [16:01] slangasek: ballons is preparing a new .dsc, I'll sponsor [16:01] slangasek, yes it's sorted. ^^ [16:01] -queuebot:#ubuntu-release- Unapproved: accepted python-pycadf [sync] (yakkety-proposed) [2.4.0-1] [16:01] building from bzr doesn't work (source and pristine-tar disagree), so I'll let him sort out the source build [16:01] and sorry pitti, re-setting up vpn to upload dsc [16:02] balloons: that or pastebin a debdiff if that's easier [16:18] hi. i'm trying to upgrade an eol install [15.04] to 15.10 [this is all just to upgrade to 16.04]. but if i'm not mistaken, the old-releases repo doesn't have packages/indexes for 15.10 published, so i'm stuck, it seems. [16:18] however, us.archive.ubuntu.com still does. so i'm a little confused as to how to go about upgrading. [16:18] lunaphyte: #ubuntu for support. [16:19] [and, if this is the wrong channel, apologies] [16:19] wxl: i actually came here from #ubuntu-server [16:20] lunaphyte: they suggested to come here? because that's strange. this channel exists to coordinate upcoming releases. [16:20] it seems though that vivid package indexes aren't listed at old-releases, yet they should be, hence my question here [16:20] wxl: no, they didn't suggest. i spent time there troubleshooting, that's all. [16:20] lunaphyte: i'd personally advice you grab /home and maybe /etc and do a fresh install re-using those [16:21] honestly, i'd just like to know who i can ask about 15.04 missing from old-releases [16:24] lunaphyte: vivid and wily are both at archive.ubuntu.com [16:25] -queuebot:#ubuntu-release- Unapproved: accepted maas [source] (yakkety-proposed) [2.1.0~beta2+bzr5454-0ubuntu1] [16:26] -queuebot:#ubuntu-release- Unapproved: networking-hyperv (yakkety-proposed/universe) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (no packageset) [16:26] i thought since vivid is eol, it would be at old-releases. [16:26] it will get there eventually, i'm sure [16:26] -queuebot:#ubuntu-release- Unapproved: accepted networking-hyperv [source] (yakkety-proposed) [3.0.0-0ubuntu1] [16:27] inex retrieval at archive.ubuntu.com does work for vivid, yes, but upgrading fails, because it tries to upgrade to 16.04, but do-release-upgrade doesn't support it, of course. [16:27] so like i said, fresh install [16:27] wxl: thanks, yeah, i guess that's my question, is what typically defines when that happens? [16:28] pitti, are you able to approve partner uploads? [16:28] wxl: it's ok, i'll let the channel get back to the /topic [16:28] infinity: could you answer lunaphyte's question as to why vivid and wily are not in old-releases but are instead still on archive? [16:29] hopefully my question isn't interpreted as "when will this be" - just would like to understand what the transition is based on [16:30] many activities in release require manual activity (for example, turning dailies on and off in response to milestone testing) [16:30] lunaphyte: Can't give you an accurate answer as to why it's not done yet (I suspect not-got-round-to-it for wily, and complicated stuff involving the Ubuntu phone codebase for vivid), but the process doc is https://wiki.ubuntu.com/EndOfLifeProcess [16:30] that said, sometimes they just get temporarily forgotten or put off [16:31] There is no definite schedule. The EOL date is one bound. [16:31] tl;dr lesson learned: upgrade BEFORE EoL :) [16:31] cjwatson: ah, thanks, that's informative [16:31] wxl: yeah, for sure. life sometimes has other plans, unfortunately. :) [16:31] it's all good though. [16:32] well before EOL of the release which follows :) [16:32] I'd probably just upgrade by frobbing sources.list and doing a dist-upgrade. [16:32] apw: hahahah indeed [16:32] Sure, do-release-upgrade helps, but it isn't mandatory. [16:32] if the end result is that eventually it will make it's way to old-releases, and then the nominal eol upgrade path will work as expected, that's fine [16:32] Somebody should figure out and document how to handle this better on the existing wiki page. [16:33] chrisccoulson: technically, yes; procedurally I have no idea what to do with them/what to check, etc. [16:33] cjwatson: does frobbing sources.list mean switching from vivid to wily, in my case? [16:33] https://help.ubuntu.com/community/EOLUpgrades [16:36] i'm but a visitor here, but would a note somewhere there along the lines of "if you are doing an eol upgrade of a relatively recent release, it's possible that it may not work, until various transitions have fully occured - please try again later" be of any value? [16:36] pitti, ah. I need adobe-flashplugin approving (I've uploaded yakkety so far, I normally wait until that's approved before uploading the other releases) [16:37] pitti, the procedure is basically 1) approve, 2) I verify they're ok, 3) Copy to release pocket. Not sure if that helps you though :) [16:38] -queuebot:#ubuntu-release- Unapproved: casper (xenial-proposed/main) [1.376.1 => 1.376.2] (desktop-core, ubuntu-server) [16:38] -queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu3.16.10.1 => 2.0~rc3-0ubuntu4.16.10.1] (ubuntu-server) [16:39] slangasek, balloons ^ now with 10% more testing love! [16:39] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu4.16.10.1] [16:41] -queuebot:#ubuntu-release- New binary: openfoam [s390x] (yakkety-proposed/universe) [4.0+dfsg1-3] (no packageset) [16:41] -queuebot:#ubuntu-release- Unapproved: indicator-network (yakkety-proposed/main) [0.8.0+16.10.20160930.5-0ubuntu1 => 0.8.0+16.10.20160930.5-0ubuntu2] (no packageset) [16:41] lunaphyte: Yeah [16:41] ^- fix for the live session [16:45] -queuebot:#ubuntu-release- New binary: openfoam [ppc64el] (yakkety-proposed/universe) [4.0+dfsg1-3] (no packageset) [16:45] chrisccoulson, Laney: I removed firefox ppc64el binaries; there are also some orphaned powerpc/s390x ones from 46.0.1+build1-0ubuntu1 and 47.0+build3-0ubuntu1, cleaning those too (this is why I don't like forcing without binary removal) [16:46] pitti, thanks [16:48] cjwatson: thanks. i suppose it's not necessarily kosher/supported, but your experience has been largely successful doing that? [16:50] lunaphyte: please do edit https://help.ubuntu.com/community/EOLUpgrades to make it better. [16:50] (you asked about adding a note?) [16:51] rbasak: oh, ok, will do [16:51] Looks like you have to ask to join the team, but contributors are welcome [16:51] https://help.ubuntu.com/community/WikiGuide [16:51] That's presumably to avoid spam. [16:51] sure, understood [16:52] lunaphyte: or you could just become an ubuntu member and then you don't have to worry about that at all :) [16:52] wxl: hah! that sounds like more responsibility :) [16:53] lunaphyte: not necessarily. just need to sustain relevant contributions to the project [16:53] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1] [16:53] Fixing the doc sounds like a relevant but circular contribution :-) [16:53] !membership | lunaphyte [16:53] lunaphyte: Ubuntu Membership means recognition of a significant and sustained contribution to Ubuntu and the Ubuntu community. For more info see https://wiki.ubuntu.com/Membership/NewMember [16:53] Laney: indicator-network> eek [16:54] wxl: thanks [16:54] Laney: do any of the other unity8 upstart jobs now unexpectedly start in the unity7 session? it appears to me that this chagne needs to be replicated to all of those? [16:54] lunaphyte: i'm on the membership board if you have other questions about it [16:54] -queuebot:#ubuntu-release- Unapproved: accepted indicator-network [source] (yakkety-proposed) [0.8.0+16.10.20160930.5-0ubuntu2] [16:55] lunaphyte: Yes, but I've been doing the general equivalent since well before Ubuntu existed so I'm not a good sample case. [16:55] Laney: I thought upstart had a less ugly way to do that, like start on starting DESKTOP_SESSION="unity8" or so? [16:55] unity-panel-service.conf:start on desktop-start DESKTOP_SESSION=ubuntu [16:56] Laney: ^ like this? [16:56] Laney: (accepted, as this is just bikeshedding, but I wonder if that affects other services too0 [16:56] I copied it from the other job in the same source package which definitely works [16:56] unity-panel-service.conf:# start on started unity7 [16:56] or even just that [16:56] wxl: well, i really do appreciate all of the info, but if i'm honest, it's probably not in the cards for me these days. hopefully that doesn't come across as dismissive! [16:56] I don't want to mess around at this point [16:56] cjwatson: understood, thanks [16:57] lunaphyte: np. it will be there in the future. [16:57] gracias [16:57] de nada [16:57] maybe you could do desktop-start DESKTOP_SESSION=... and indicator-services-start [16:57] Seems risky to me to experiment now [16:58] Laney: "start on started unity7" (like unity-panel-service.conf) seems like the equivalent of WantedBy=unity7-session.target [16:58] Laney: but yes, if it works, it's ok; as I said I mostly just wondered if that affects other unity8 services too [16:59] It's waiting for some event, not just that unity8 is started [16:59] and I don't know - at least I haven't heard that any of those actually crash like this one does ... [17:00] -queuebot:#ubuntu-release- Unapproved: thunderbird (yakkety-proposed/main) [1:45.3.0+build1-0ubuntu2 => 1:45.3.0+build1-0ubuntu3] (mozilla, ubuntu-desktop) [17:00] I have something called indicator-transfer-service running, not sure if that's necessary or not [17:06] seb128 / tedg: do you know if indicator-transfer is used or useful on unity 7? [17:06] Laney, it's not used and probably not going to be useful [17:06] it's supposed to indicate ongoing downloads [17:07] but classic apps don't use the api to talk to it [17:07] so probably not that useful [17:10] thanks [17:10] I'll give it the same love, but this is lower priority [17:14] I'm being arm twisted with beer, for some last minute universe FFes :) [17:23] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (yakkety-proposed/main) [117 => 118] (kubuntu, ubuntu-desktop) [17:25] -queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu3] [17:26] -queuebot:#ubuntu-release- Unapproved: indicator-transfer (yakkety-proposed/main) [0.2+16.10.20160808.1-0ubuntu1 => 0.2+16.10.20160808.1-0ubuntu2] (no packageset) [17:29] infinity, pitti: do we have a target time for the start of image respins, to guide evaluating the uploads in the queue? [17:29] pitti: ^- same fix - this one is "just" a waste of resources [17:30] I'm a waste of resources ;( [17:30] urgh, there's a waste of resources in my changelog [17:30] slangasek: I was shooting for "very soon". But will take another round of fixes if they don't need 4h to get through the sausage factory. [17:31] slangasek: I was personally waiting on the arm64 buildd kernel hack (done), and ubuntu-system-settings building successfully (in progress) and migrating. [17:31] I'm also curious to see what the fallout is from the firefox and thunderbird removals. [17:32] I bet component-mismatches explodes. [17:32] infinity: what is "soon", realistically? we have maas which is currently publishing [17:32] -queuebot:#ubuntu-release- Unapproved: indicator-transfer (yakkety-proposed/main) [0.2+16.10.20160808.1-0ubuntu1 => 0.2+16.10.20160808.1-0ubuntu2] (no packageset) [17:32] slangasek: After that maas, since it'll beat u-s-s to the release pocket. [17:32] ok [17:33] slangasek: I dunno. More than an hour, less than several. [17:33] I hope. [17:34] infinity: it seems for some reason a gdb was accepted, which is seeded everywhere and needs 4 more hours to build on armhf [17:34] (appx) [17:34] -queuebot:#ubuntu-release- Unapproved: rejected indicator-transfer [source] (yakkety-proposed) [0.2+16.10.20160808.1-0ubuntu2] [17:34] slangasek: Whee. [17:34] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-304 [source] (yakkety-proposed) [304.132-0ubuntu1] [17:34] so maybe someone wants to speak up and explain why that was accepted [17:34] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (yakkety-proposed) [118] [17:35] pitti: ? [17:35] or Laney or apw or tumbleweed or stgraber ? [17:36] nope [17:36] doko: or did you happen to accept this gdb yourself? [17:36] I accepted thunderbird though, which needs quite a while on armhf [17:36] Apparently the current one fails to start [17:37] Laney: ah, well, thunderbird is seeded in only half the places that gdb is [17:37] Which is still many places. :P [17:37] block-all source time? [17:37] Not all. [17:37] only ubuntu-mate, ubuntu desktop, ubuntukylin FWIW [17:37] But getting close to block all seeded. [17:38] oh. but also ubuntustudio + xubuntu, so that's fine [17:39] infinity, Laney: I suggest forcing thunderbird in before armhf is built, to unblock the image builds / tests on other archs and let armhf binaries catch up on their own time [17:40] We'll see how the other arches fare. [17:40] (since I don't think any of those projects are building armhf images currently) [17:40] ubuntu2/armhf actually FTBFSed [17:40] So we'll see how this one does [17:42] It'll need some forcing or removals in any event since arm64/ppc64el have regressed [17:42] Might be one to punt [17:42] Dunno how crap 38 is [17:42] Has anyone looked into *why* they regressed? [17:43] They build fine in xenial with the same upstream version. [17:45] chrisccoulson: ^- (I'm guessing "no") [17:45] u-s-s worked [17:47] i didn't notice that ubuntu2 had been approved actually [17:48] the armhf is a race condition that we keep seeing in the build. It'll probably work fine if it's retried [17:48] the arm64 build failure is a crash when compiling the startup cache [17:49] it most likely builds fine on xenial because it's not using gcc6 [17:52] * infinity notes that gcc-5 is still in yakkety. [17:52] Not that that fixes the bugs, but it would defer the issue. [17:54] -queuebot:#ubuntu-release- Unapproved: gcr (yakkety-proposed/main) [3.20.0-2ubuntu1 => 3.20.0-2ubuntu2] (kubuntu, ubuntu-desktop) [18:03] pitti: Are you on top of this indicator-transfer thing? [18:03] * infinity eyes libreoffice suspiciously in the queue. [18:03] -queuebot:#ubuntu-release- Unapproved: accepted gcr [source] (yakkety-proposed) [3.20.0-2ubuntu2] [18:04] -queuebot:#ubuntu-release- Unapproved: accepted python-tornado [source] (yakkety-proposed) [4.4.2-1ubuntu1] [18:06] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20161011.1-0ubuntu1] [18:10] oh, who just approved flash? [18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20160913.1-0ubuntu0.12.04.1 => 1:20161011.1-0ubuntu0.12.04.1] (no packageset) [18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20160913.1-0ubuntu0.16.04.1 => 1:20161011.1-0ubuntu0.16.04.1] (no packageset) [18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20160913.1-0ubuntu0.14.04.1 => 1:20161011.1-0ubuntu0.14.04.1] (no packageset) [18:12] chrisccoulson: Moi. [18:12] infinity, ah, thanks. I've just uploaded the rest of them now :) [18:34] -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (yakkety-proposed/main) [3.22.0-1ubuntu1 => 3.22.1-0ubuntu1] (ubuntu-desktop) [18:35] jbicha: ^^ this impacts images across 4 flavors, for which image spins are supposed to start imminently; why is it uploaded now? [18:36] slangasek: it can be an SRU right? [18:37] jbicha: if it meets SRU requirements; ok I see the SRU template in the one bug, thanks [18:38] it's not needed in the release images [18:38] jbicha: I'm asking because it's hard to coordinate across all the release team working the queue in parallel, so it's important to have clarity about the target for these uploads [18:38] ok [19:00] infinity, Is the release going to be delayed? [19:01] flexiondotorg: I shouldn't think so. [19:01] OK [19:01] The rumour mill is speculating. I'll pour water on that. [19:01] flexiondotorg: Rumour mills are special. [19:02] Indeed. [19:03] flexiondotorg: Perhaps the rumour mill should be harder at work on testing, reporting, and fixing. :P [19:03] That too. [19:19] thanks everyone for entertaining my questions, etc. [19:21] does a binary removal of an arch: all package on a specific arch DTRT? :P [19:22] slangasek: no. [19:22] ok cool [19:22] so how do we get juju in? [19:22] I guess I can 'force' it [19:23] No. [19:24] infinity: I hope you're planning on elaborating / presenting an alternative :) [19:24] I'm looking at the situation first. [19:24] ok [19:25] summary from my side: juju dropped 32-bit arch supports, with my sign-off; no transitional packages for this in yakkety because the drop is retroactive to xenial so for 16.10 we just want the packages gone; in the process that means juju is migrating from an (uninstallable) arch: all package to an arch: some package; and britney doesn't want to let it in [19:25] Check, and rmadison confirms. [19:26] and I guess, from the output, that the arch: all-> arch: some change was made only in the latest release, since previous release was getting autopkgtest results [19:26] Okay, in that case, your propose arch-some removal might work. [19:26] ok [19:26] The reason I said it doesn't is because all copies in LP are source-based, so binary removals always come back. [19:26] did that, let's see what happens - thanks [19:26] And, thus, should be avoided. [19:26] (And definitely avoided for arch:all, which is just confusing) [19:27] But as a temp solution, it might DTRT. [19:27] If it doesn't, just remove juju from the release pocket entirely. [19:27] Still beats a force. [19:32] Okay, and juju's not in any metapackages, so don't need a refresh. [19:32] Though after the current things all settle, I'll do a world refresh of meta locally to see if any changes got missed. [19:37] slangasek: I didn't accept it; it seemed a bit dubious/too intrusive to me [19:37] -queuebot:#ubuntu-release- Unapproved: wine-development (yakkety-proposed/universe) [1.9.19-1ubuntu1 => 1.9.20-1ubuntu1] (no packageset) [19:37] -queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (yakkety-proposed) [1.9.20-1ubuntu1] [19:38] infinity: do you want everyone else to stay away from unapproved now? [19:38] or still want me to review the indicator-transfer thing? [19:38] (I have a hunch that's going to be needed for the ubuntu desktops at least, but not blocking all other flavors) [19:39] urgh, a LibO upload? [19:39] dear http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt, pretty please update [19:39] pitti: GO ahead and sort that, please. [19:40] Laney: running these shell scripts is a nice waste of resources too, but hopefully a bit less :) [19:41] -queuebot:#ubuntu-release- Unapproved: accepted indicator-transfer [source] (yakkety-proposed) [0.2+16.10.20160808.1-0ubuntu2] [19:42] jbicha: do you want that g-s-d on the images? diff looks sane enough to me, but at this point there's little margin for errors [19:43] jbicha: did you test this on real hw with a battery? screen saver works ok? [19:43] pitti: did you see s_langasek's comment above about it ^ [19:43] no, /me reads backscroll [19:44] meh, somehow my firefox/ppc64el removal didn't work? [19:45] I'd rather g-s-d just be an SRU actually; the bug fixes in it are fairly minor [19:45] ack, they don't seem image-critical, unlike the indicator thing [19:45] (relevant for live image) [19:46] infinity: I guess you should put a propagation block in place now, so that we have more control over this? [19:46] pitti: Yeahp. Doing that now. [19:46] infinity, slangasek: are you on top of the juju 32 bit removals so that this can land, or want me to? [19:46] pitti: Steve's on the juju case. [19:46] the transitional moved from arch: all to arch: [list] [19:46] ack [19:47] infinity: so I can deal with firefox; 46.x and 47.x are gone, but 48.x ppc binaries still exist [19:47] pitti: The easier way to do that is just to remove source package by version. [19:47] pitti: remove-package -e 48.blah firefox [19:48] pitti: Way simpler than trying to hunt down the mismatched bits. [19:48] infinity: that would entirely remove it from yakkety for a short blip of time, though? [19:48] pitti: Do you care? [19:48] I ran http://paste.ubuntu.com/23309737/ earlier, apparently that didn't work [19:48] If the goal is to get 49 in ASAP. [19:48] ok [19:49]