[02:31] infinity: ah, is that why c-m screamed at me? :) === Guest76746 is now known as med_ [05:29] infinity: Hi. Could you please accompany http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/ubuntustudio.artful/revision/1508 by adding the "ship-live" seed to Studio here similar to the Edubuntu one?: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/germinate.py#L371 Thanks! [05:57] i know it's a desktop package, so probably takes some extra checking, but qtbase-opensource-src 5.5.1+dfsg-16ubuntu7.4 has been in the upload queue for almost a month now, does it usually take this long for someone to have a look at it? [05:58] (it fixes this bug i reported: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173 ) [05:58] Ubuntu bug 1598173 in qtbase-opensource-src (Ubuntu Xenial) "Please consider SRU of "xcb: Compress mouse motion and touch update events"" [Undecided,New] [05:59] (note that there's already a 5.5.1+dfsg-16ubuntu7.3 upload there as well, but 5.5.1+dfsg-16ubuntu7.4 includes both those fixes, see dmitri's comment on the bug) [06:02] estan, in large part it is because it is a sync and syncs are a pig to review [06:03] -queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [sync] (xenial-proposed) [5.5.1+dfsg-16ubuntu7.3] [06:15] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.2 => 5.5.1+dfsg-16ubuntu7.4] (kubuntu, qt5, ubuntu-desktop) [06:17] -queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [sync] (xenial-proposed) [5.5.1+dfsg-16ubuntu7.4] [06:24] -queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (xenial-proposed) [5.5.1+dfsg-16ubuntu7.4] [06:58] apw: aha, i see. thanks a lot for taking care of it! [07:20] hello, any AA around for a question= [07:21] that's going to be fun for 6 months ... any AA around to talk about AA :p [07:21] I restricted the architectures where llvm 3.7 is built (because just needed for ghc on arm*, so not really needed to build on other architectures) [07:22] unfortunately I'm not sure I gave the commands correctly, it seems "decruftable" but I need double checking before asking or filing a removal bug [07:25] Looks removable to me. [07:26] thanks! [07:27] LocutusOfBorg: And removed. [07:27] my biggest concern was on the -all packages, because debian has them built, while ubuntu has not [07:28] oh... thanks <3 I was filing a bug lol :) [07:28] now, I have to understand why llvm 4.0 is not migrating [07:28] and fix a build failure on 3.8 :) [07:29] * amd64: libllvm-ocaml-dev [07:29] yep I saw that [07:29] but I have to rmadison a little bit [07:30] indeed [07:30] so the decruft happening in Debian has to happen here too, let me see [07:31] LocutusOfBorg: Looks like llvm-4.0 stopped producing libllvm-4.0-ocaml-dev [07:31] libllvm-4.0-ocaml-dev it probably needs to be removed too? [07:31] exactly [07:31] LocutusOfBorg: Which libllvm-ocaml-dev depends on. [07:31] LocutusOfBorg: Nothing about things needing to be removed. [07:31] LocutusOfBorg: But rather llvm-defaults needing fixing. [07:32] interesting, I got the same conclusion, but meh, not sure why this is happening :) [07:32] let me double check [07:34] LocutusOfBorg: Not sure why it's happening? libllvm-ocaml-dev depends on libllvm-4.0-ocaml-dev, and llvm-toolchain-4.0 doesn't produce libllvm-4.0-ocaml-dev anymore, thus libllvm-ocaml-dev is broken. :P [07:34] the question is "why is not happening in Debian" :) [07:34] LocutusOfBorg: Either llvm-toolchain-4.0 needs to start producing that binary again, or llvm-defaults need to stop producing the unversioned one. [07:34] https://packages.debian.org/unstable/libllvm-ocaml-dev [07:34] LocutusOfBorg: It's not happening in Debian because their llvm-defaults isn't 4.0? [07:35] 3.8 satisfies it [07:35] ... [07:35] Our llvm-defaults points to 4.0. [07:35] indeed, on that page there was a "not alpha, hurd-*" I missed the "not" [07:35] Debian's does not. [07:36] yep, but I didn't parse correctly that page lol [07:36] ENOCOFFEE [07:36] thanks! [07:47] LocutusOfBorg: As for the 3.8/arm64 thing, I have a hunch that related to a gcc regression. At least, it's moderately suspicious that the current gcc's testsuite has a ton of timeouts in asan tests, and llvm-3.8 also times out in sanitizer tests. [07:48] Oh, but that built before gcc-6 did. [07:48] So, weird coincidence, but perhaps unrelated. [07:49] Or the same patches landed in both toolchains. :P [07:49] well, it fails on Debian experimental but not Debian unstable [07:49] so, somewhere we picked up that stuff from experimental I wild guess [07:51] That's not really how I read the Debian build history. [07:51] I read it as "this timeout is just borderline, and sometimes it succeeds, and sometimes it doesn't". [07:51] It's just sbuild killing it for N minutes without stdout, afterall, it's not the package itself throwing a failure. [07:51] well, it failed 3/4 experimental builds, and 0/2 unstable builds [07:52] (there are three kinds of lies, lies, damn lies, and statistics) [07:52] Right, 3/4. Not 4/4. Hence your assertion that "experimental breaks it" is clearly false. [07:52] And 2/2 is hardly a large enough sample size to assert that "unstable fixes" it. [07:53] So I suspect it's just right on the edge of the timeout window. Sometimes a few minutes over, sometimes a few minutes under. [07:53] yep, I fully agree, I was just trying to see if something in the toolchain was different [07:53] and 3/4, VS 0/2 at least is worth a look :) [07:54] anyway, lets see if now it builds [08:01] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (zesty-proposed) [2.2.9-0ubuntu1] [08:03] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.9-0ubuntu1~16.04.1] [08:03] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (yakkety-proposed) [2.2.9-0ubuntu1~16.10.1] [08:04] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.9-0ubuntu1~14.04.1] [08:25] -queuebot:#ubuntu-release- New sync: vine (artful-proposed/primary) [1.1.3+dfsg-2] === maclin1 is now known as maclin [08:27] -queuebot:#ubuntu-release- New binary: healpix-cxx [s390x] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset) [08:28] -queuebot:#ubuntu-release- New binary: healpix-cxx [amd64] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset) [08:28] -queuebot:#ubuntu-release- New binary: case [amd64] (artful-proposed/universe) [1.5.3+dfsg-1] (no packageset) [08:29] -queuebot:#ubuntu-release- New binary: healpix-cxx [ppc64el] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset) [08:33] -queuebot:#ubuntu-release- New binary: healpix-cxx [i386] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset) [08:41] -queuebot:#ubuntu-release- New binary: healpix-cxx [arm64] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset) [08:50] Laney, infinity - have archive reports been adjusted for artful? because i get emails from pitti, that are not visible in http://people.canonical.com/~ubuntu-archive/component-mismatches.txt unless something has moved as well now. [08:53] They should have been [08:53] Laney, ok, in that case i'm emiling ubuntu-release with a question =) [08:54] Someone demoted the unity8 stuff? [08:54] Is that what you're asking about? [08:54] -queuebot:#ubuntu-release- New binary: healpix-cxx [armhf] (artful-proposed/universe) [3.30.0-6ubuntu1] (no packageset) [08:55] Laney, yes | no | maybe. https://launchpad.net/ubuntu/+source/ubuntu-meta/1.380 [08:55] I saw that [08:55] then there was pitti's email stating that everything is a mess now [08:55] I don't see that one [08:55] then i couldn't find the mess [08:55] It looks like someone put it all in universe [08:55] ah, let's check publishing record. [08:55] https://launchpad.net/ubuntu/+source/unity8/+publishinghistory [08:56] but that was bileto landing [08:56] has bileto gone crazy?! [08:56] what was? [08:56] unity8 publishing [08:57] I don't see what that has to do with it [08:57] it does have AA rights, .... or do we not get a publishing entry when things move between components? [08:57] There is an entry there [08:57] just checking that the archive is open for artful uploads before I bombard it with half a hundred uploads? [08:57] jamespage, open :) [08:57] \o/ [08:57] jamespage, enjoy! [08:58] jamespage: you can see the status on https://launchpad.net/ubuntu/artful BTW [08:58] It'll say "Frozen" or something if it's frozen [08:59] Laney: yeah - just making sure [08:59] but Active Development -> go wild [08:59] Laney: it does say something like pre-release freeze until its open (looked last week) [08:59] yep [09:01] I love the fact that I can wildcard with dput :-) [09:02] * jamespage launches a salvo of uploads [09:07] if there is an AA around - most of that's going to depwait until the new sync of vine from Debian gets acked - pretty please :-) [09:11] xnox, i think infinity had "sorted" component missmatches to 0 and is intending to keep it so [09:12] right. now i'm thinking the emails i got was because there was delay between branch updates; and my meta upload. such that once meta cleared things were fine. but someone still demoted things. [09:16] I would assume that someone used the output of component-mismatches to know what to demote [09:16] i am sure that is true [09:17] but presumably if meta now needed things they would be in there as new component-missmatches with MIRs already acked [09:17] c-m-proposed looks believeably and non-empty [09:22] infinity, do you think I have to reupload llvm-3.7 without the examples package? I still see some sadness there, even after your hammer [09:28] -queuebot:#ubuntu-release- Unapproved: linux-firmware (zesty-proposed/main) [1.164 => 1.164.1] (core, kernel) [09:28] -queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (zesty-proposed) [1.164.1] === maclin1 is now known as maclin [11:15] -queuebot:#ubuntu-release- Unapproved: ceph (xenial-proposed/main) [10.2.6-0ubuntu0.16.04.1 => 10.2.7-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync) [11:15] -queuebot:#ubuntu-release- Unapproved: ceph (zesty-proposed/main) [10.2.6-0ubuntu1 => 10.2.7-0ubuntu0.17.04.1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync) [11:15] -queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.6-0ubuntu0.16.10.1 => 10.2.7-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server) (sync) [12:12] -queuebot:#ubuntu-release- Unapproved: accepted mtx [source] (yakkety-proposed) [1.3.12-9ubuntu0.16.10.1] [12:14] -queuebot:#ubuntu-release- Unapproved: accepted mtx [source] (xenial-proposed) [1.3.12-9ubuntu0.16.04.1] [12:17] -queuebot:#ubuntu-release- Unapproved: linux-firmware (zesty-proposed/main) [1.164 => 1.164.1] (core, kernel) [12:20] hehe autopkgtests will take forever to run [12:27] apw, could you please demote these to universe? http://people.canonical.com/~ubuntu-archive/component-mismatches.txt [12:53] remove upstart instead of demote? :) [13:01] LocutusOfBorg, not ready to be removed, demotion is a good start. [13:01] because then we know it's dropping out of tasks. [13:01] and if any remain. [13:04] it was an half joke btw :) [13:04] unity demoted it is also nice [13:07] The requested URL /~ubuntu-archive/proposed-migration was not found on this server. [13:07] is it just me or... [13:08] not just you [13:08] some minutes ago it was giving 403 errors, so I guess sysadm are doing something [13:09] * LocutusOfBorg fights daily against proxies and bad connections [13:09] ... and you work on an IT company! [13:09] this is why I have to fight against it folks blocking everything [13:10] security for some customers means block even irc/ssh/git protocols [13:10] aha. at least it's not just me [13:21] I have to fetch git repos over https and proxy [13:21] it would be quite something if a 404 error were just experienced by one person :) [13:21] and canonical in the last months is disabling https fetch for git repos [13:22] Laney, when your proxy changes what you see... this happens [13:22] -queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.4 => 1.13.4-1ubuntu1.5] (kubuntu, ubuntu-desktop, ubuntu-server) [13:22] -queuebot:#ubuntu-release- Unapproved: sssd (yakkety-proposed/main) [1.13.4-3ubuntu0.3 => 1.13.4-3ubuntu0.4] (kubuntu, ubuntu-desktop, ubuntu-server) [13:22] not probably at this level, but before downloading it downloads the file for you, and redirect you to a download link if the antivirus is happy [13:23] Anyway [13:23] I believe the machine is down atm due to being upgraded to xenial [13:23] nice :) [13:23] ah, that might explain my 503s [13:23] was it on trusty? [13:24] dapper [13:25] -queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (yakkety-proposed) [2.2.4-4ubuntu0.16.10.2] [13:25] (that was a joke) [13:26] (a hilarious one) [13:26] I got it :) [13:26] (please laugh) [13:26] seriously, it was on breezy I gues [13:26] *guess [13:27] * acheronUK wondered at the symbolism of people.ubuntu.com vanishing [13:27] we had dapper machines on buildd for quite some time IIRC, so it might even not be a joke :) [13:27] *canonical [13:28] disabling https fetch for git repos> what do you mean? https fetch from git.launchpad.net works fine ... [13:28] ehm, some repositories I don't remember where [13:29] not git.l.net [13:29] will try to remember [13:29] I think it's more likely that something would be broken that that Canonical would be intentionally disabling it, though perhaps there's some weirdness I'm unaware of [13:30] ok, so I will maybe write here in case I find that link [13:36] LocutusOfBorg, bzr http, git https [13:42] that reminds me that ubuntu-it still has his machine on precise... we should probably complete the preparations for the upgrade... [13:45] mapreri, it can wait, another 4 days [13:45] plenty of time!!! [13:45] ahem :| [13:46] if only software would port itself over new libs :( [13:48] please could an AA accept the sync I did of vine into artful earlier today - that will unblock a number of dep-waits I have in the openstack dependencies for pike-1 [14:08] -queuebot:#ubuntu-release- New binary: libepoxy [ppc64el] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core) [14:09] -queuebot:#ubuntu-release- New binary: libepoxy [amd64] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core) [14:09] -queuebot:#ubuntu-release- New binary: libepoxy [s390x] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core) [14:09] -queuebot:#ubuntu-release- New binary: libepoxy [i386] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core) [14:14] -queuebot:#ubuntu-release- New binary: libepoxy [armhf] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core) [14:14] infinity: what's the next step with https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522 ? [14:14] Ubuntu bug 1685522 in wireguard (Ubuntu) "out of date snapshot" [Undecided,Confirmed] [14:15] -queuebot:#ubuntu-release- New binary: libepoxy [arm64] (artful-proposed/main) [1.3.1-2ubuntu1] (desktop-core) [14:16] zx2c4: according to https://wiki.ubuntu.com/SponsorshipProcess you should subscribe ~ubuntu-sponsors to the bug [14:18] jbicha: thanks just did that [14:20] jbicha: so now what? [14:20] somebody just needs to "sponsor" me? [14:20] seems like most folks are too busy [14:22] let me see [14:22] LocutusOfBorg: thanks! [14:23] LocutusOfBorg: infinity, cjwatson, and i discussed this strategy of using an empty package pretty extensively last night in this channel [14:23] README.Debian file was nice too [14:24] LocutusOfBorg: you want me to add a README.Debian file to it? [14:28] -queuebot:#ubuntu-release- Unapproved: wireguard (zesty-proposed/universe) [0.0.20170214-1 => 0.0.20170214-1ubuntu0.17.04] (no packageset) [14:28] zx2c4, ^^ I had to tweak it a little bit [14:28] LocutusOfBorg: im writing a README.debian and then im going to reupload to the bug, doe sthat sound good? [14:28] nah [14:28] it is fine [14:28] oh, cool, okay [14:28] so when this says "Unapproved: wireguard ..." what does that mean? [14:28] (where can i see your tweaks?) [14:30] https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text= [14:30] http://launchpadlibrarian.net/316831052/wireguard_0.0.20170214-1_0.0.20170214-1ubuntu0.17.04.diff.gz [14:30] here, just look at my debdiff and compare it to your [14:30] (hint: I removed the .pc directory, changed back to quilt) [14:33] LocutusOfBorg: you added back in all those random other files? [14:33] i guess thats fine [14:33] interesting in any case [14:34] debian/ubuntu processes remain mysterious to me [14:34] zx2c4, you changed from quilt to native, so it means the orig tarball is not preserved [14:34] so, patches are not unapplied and a lot of other stuff [14:34] i didnt realize we wanted to keep the original tarball? [14:34] and that .pc was a result for that [14:34] yes zx2c4 [14:34] ahh [14:34] why not? [14:34] security, avoid new tarballs just for fun [14:35] native package is not easy to follow, upstream one is [14:35] because it's code that should _not_ persist [14:35] but in anycaes, its not a big deal [14:35] im just happy that this is in the queue [14:35] we are talking about the upstream package, not the debian changes that prevents it from working [14:35] that version needs to be complete and coherent with what upstream released on that snapshot [14:35] even the upstream package. its not a package. or a release. its just some random code dump from one particular day. which is why it shouldnt have been in ubuntu [14:35] okay i understand [14:36] so what happens next with this queue? [14:36] and your debian/* foo should explain/change that, with patches approach [14:36] somebody else presses the "approve" button, and then we're all set? [14:36] zx2c4, now, somebody on release team should approve yes [14:36] oh cool, so that's where infinity comes in [14:36] somebody will add verification-needed and you will test/change back to verification-done, explaining the testing you did [14:36] https://wiki.ubuntu.com/StableReleaseUpdates [14:37] cool okay [14:38] and all that explanation will happen on the original bug report? [14:42] I hope so :) [14:43] Laney, britney runs off snakefruit right? thus i should not expect anything to migrate, until snakefruit is back up? [14:44] and infinity / slangasek fix it up? [14:44] xnox: correct [14:44] correct [14:44] tah [16:03] -queuebot:#ubuntu-release- New binary: systemd [s390x] (artful-proposed/main) [233-5ubuntu1] (core) [16:07] -queuebot:#ubuntu-release- New binary: systemd [ppc64el] (artful-proposed/main) [233-5ubuntu1] (core) [16:07] -queuebot:#ubuntu-release- New: accepted systemd [s390x] (artful-proposed) [233-5ubuntu1] [16:10] -queuebot:#ubuntu-release- New binary: systemd [i386] (artful-proposed/main) [233-5ubuntu1] (core) [17:32] dear release wizards, [17:32] I have a question regarding SRU's to zesty [17:33] santa_: what is the question? [17:33] we are considering in kubuntu an SRU for plasma (we have 5.9.4 in zesty and we would like to provide 5.9.5 via an SRU) [17:33] we maintainain in kubuntu ~300 packages, so we have some automation tools [17:34] the easier thing for us would be preparing a _complete_ plasma update [17:34] that means we might have some packages providing a 0-diff update [17:34] would be allowed to do that? [17:35] krytarik: You completely broke the ubuntustudio seeds. [17:35] santa_, as long as it will be tolerable to reject all the 0-diff updates?! e.g. things do not depend on the updated version numbers. [17:35] i think SRU team may be ok with rejecting a bunch of things. [17:36] xnox: You might want to not speak for the SRU team. ;) [17:36] * xnox is not ~ubuntu-sru team member [17:36] xnox: we can make it tolerable, yes [17:36] santa_: I have no issues with it conceptually. It certainly has precedent. [17:36] we just need to not bump the buld depends, that's easy to do, we just disable that in the tooling and that's it [17:37] santa_: The bigger issue is findind someone with the time to process it all, since that used to be ScottK. [17:37] plasma are 42 source packages in case you are wondering [17:37] how many of these packages would ... 42 ok [17:38] 42 is a much less scary number than 300. [17:39] santa_: So, yeah. From our POV, even the 0-change uploads are not a huge burden on *us*. But you need to think hard about yourself as well, as you do need to verify all those binary builds. [17:39] santa_: Cause part of the SRU process is not trusting something is okay just because it rebuilt with "no changes". It needs to be installed, run, tested. [17:39] santa_: So, for the 0-change ones, it's probably in your best interest to skip them. [17:40] (For me, I don't much care, it's easy to review sometihng without a change :P) [17:42] infinity: yeah, I get what you mean. a 0-diff is after all a rebuild, so that 'invalidates' somehow the testing we do. I guess we could improve a bit the tooling and the workflow to deal with these kind of things [17:42] santa_: But if you're willing to verify them all and you want the versions to be pretty and match, I'm not going to tell you not to do it. [17:44] regarding the status of artful. I guess we are free to upload now? we already have several things to update [17:44] santa_: archive is open [17:44] plasma 5.9.5 in the first place [17:44] frameworks [17:44] and we also have the kdepim which we couldn't include in zesty, that needs several NEW reviews [17:46] regarding the kdepim this is what we had in zesty: http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_archive/16.12.3_zesty_proposed_migration.pdf [17:48] the kdepim is the bunch of the top, those in dark red are already in the archive, those in grey are not [17:50] so what do you suggest us to do? upload those who are not in the archive first, and then the rest, or just upload them all? we could do any of both with our automation tooling [17:55] oh, people.c.c is back. [17:56] was britney also stopped, by any chance? [17:56] infinity: Is the Artful release schedule good? [17:58] mapreri, yes same machine [17:58] bdmurray: I like it well enough. [17:58] mapreri: people was never gone, but people/~ubuntu-archive is actually a proxy through to another machine (the one that runs britney) [17:59] ic [18:06] infinity: Okay, I was thinking about doing the meta-release file [18:06] bdmurray: Might want to upload u-r-u to artful before you do. [18:11] infinity: well, alright [18:26] infinity: Hurr durr, I was hoping I wouldn't have to duplicate the general 'live' seed file to 'dvd-live' - will do so then.. :/ [18:27] krytarik: Well, I'm not entirely sure what your intent is here. [18:27] krytarik: There's nothing wrong with having a dvd-live, but you deleted it. [18:28] krytarik: Deleting it and still having it listed in STRUCTURE makes germinate very unhappy. [18:29] krytarik: Your STRUCTURE references a lot of seeds that don't exist. :P [18:29] xnox: upstart, cgmanager demoted [18:29] krytarik: live-common and ship-live also aren't a thing in your seeds. [18:31] infinity: Trust me! :P [18:31] krytarik: No? :) [18:33] krytarik: Oh, scratch the live-common bit, that's in platform, so everyone shares it. [18:34] krytarik: So, that's correct. But deleting dvd-live was less correct. :P [18:34] Yes, I see that now. :P [18:34] krytarik: And the bug you were trying to fix, I think, was the lack of ship-live. [18:35] If you even need one. [18:35] Well, that plus referencing a 'dvd' seed that doesn't exist. [18:39] krytarik: Anyhow, I think reverting that entire last commit and then deleting "live" (moving anything from there that you need into dvd-live), and then sorting out a ship-live seed to fix your other bug would get the job(s) done. [18:40] Although... You don't have a LIVE_TASK in livecd-rootfs. How does ANY of this work for you? [18:45] bdmurray: Wow, phased-updater takes an amazingly long time to run. [18:46] bdmurray: Are you doing something very slow there like iterating through all SRUs via LP? [18:57] infinity: Oh meh, I just see Edubuntu, which I've been following for this, has 'include ubuntu.*' rather than just 'platform.*' as we do, so that's why they get away with not having a 'ship-live' seed themselves. So I guess I'll either copy the Ubuntu or the Xubuntu one, which our seed is otherwise based on. Also, I was thinking earlier regarding the 'dvd-live' seed, could I just have it ... [18:57] ... an empty file except the header, and otherwise pull in 'live' as it does now? [18:58] krytarik: An empty file pulling in live would work fine, but we really don't need both "ubuntustudio-live" *and* "ubuntustudio-dvd-live" tasks in the archive. [18:58] krytarik: Just settling on dvd-live and making it behave like edubuntu makes more sense to me. [18:59] krytarik: The only reason to have a split would be if you were producing both size/type images, which you're not. [19:00] I'll note that edubuntu has that same bug. :P [19:00] Not that it's producing images anymore at all. [19:02] And yes, adding a LIVE_TASK for it would be nice then indeed, I see. :P [19:04] I'm not actually sure where dvd-live comes into play for edubuntu, now that I look... [19:06] krytarik: Anyhow, unwinding all of that and sorting out what you actually need/want to do could be some back and forth. [19:06] krytarik: Could you please just revert your last commit (or I will), so it stops breaking infrastructure? :P [19:07] infinity: Sure, asap. Would you be fine with an --overwrite there? :P [19:07] No. [19:07] That'll break anyone who updates with a pull. [19:07] Which icludes the aforementioned infrastructure. [19:08] Never ever go back in time in a shared repository unless you control all the checkouts. [19:13] Alright, if there are copies of it someplace indeed.. And well, it should be easy enough to fix properly now that I know more about it. [19:18] -queuebot:#ubuntu-release- Unapproved: distro-info-data (precise-proposed/main) [0.8ubuntu0.11 => 0.8ubuntu0.12] (ubuntu-server) [19:24] Copying Edubuntu is probably a bad idea. [19:24] It was complicated and weird to set up that way. [19:25] There was some special reason for it that I now forget. [19:33] infinity: Look good to you?: http://paste.openstack.org/show/MpSB7IDbQ03QyYeOgvPD/ [19:35] -queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (precise-proposed) [0.8ubuntu0.12] [19:35] krytarik: I dunno. The surefire way to not mess up a revert is to do a revert. :P [19:36] krytarik: ie: bzr revert -r1507 [19:36] Well, I don't want to go back to where it doesn't have any 'pool/'.. :P [19:38] krytarik: Fair enough, though the actual bug that was meant to be fixed by giving you a pool won't be fixed. [19:38] In that you don't ship grub-efi-whatever anywhere. [19:39] Pretty sure it will..? [19:41] krytarik: How? Your seeds don't reference grub-efi-amd64-signed anywhere. [19:43] Err, look again at the paste? [19:44] krytarik: Oh, in the uncommitted revision, sure. [19:44] krytarik: I was looking at the current and saying that reverting from current to current-1 wouldn't regress anything. [19:45] krytarik: Yes, there's a fair chance that paste will fix things. [19:55] infinity: Done. [20:12] slangasek: https://code.launchpad.net/~brian-murray/apport/lp-retracer-config-artful/+merge/323074 [20:13] bdmurray: is this on the release-opening checklist, or if not could you add it? [20:14] (merged) [20:14] slangasek: it is just slightly wrong [20:16] bdmurray: and I've dropped powerpc for 17.* [20:18] slangasek: noted [20:34] -queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (yakkety-proposed) [1.2.6-0ubuntu1.1] [20:54] infinity: Oh no, now it's moaning at a missing 'dvd' seed file still - not sure what should be in there though.. [20:55] krytarik: The edubuntu dvd file looks useful, minute the ltsp bit. [20:55] krytarik: (ie: all the langpacks) [20:56] krytarik: The edubuntu dvd-langsupport also looks handy. [20:56] I mean, if you care about translations. [21:00] I think the image is bloated enough already as it is.. :P [21:03] krytarik: An empty (well, comment-only) dvd file might do the trick too. Along with the cdimage change you proposed. [21:04] Yeah, just thought the same. [21:10] infinity: ..I'm stuck at the comment part now. :P [21:11] "This seed exists only to gather together all the other dvd seeds." [21:11] See platform/support-common for prior art. :P [21:12] Yes! \o/ [21:14] krytarik: Bonus points for comitting and pushing the fix? [21:16] Sure, am on it. [21:21] infinity: Done. [21:25] slangasek: can we bump distro-info-data out of precise-proposed? [21:26] rcj: do you mean release it or supersede it? [21:26] slangasek: release it, sorry for being imprecise [21:27] That's being super aggressive on the timing but it's blocking image builds and the nature of the change is low-risk. [21:27] rcj: at the moment I'm wondering why it's not showing up on http://people.canonical.com/~ubuntu-archive/pending-sru.html; <-- infinity, snakefruit fallout? [21:28] possibly, last update ~90m ago? [21:28] Also hasn't automatically approved the nominated track in bug #1685055 [21:28] bug 1685055 in distro-info-data (Ubuntu Precise) "Update to add Artful" [Undecided,Fix committed] https://launchpad.net/bugs/1685055 [21:29] rcj: it ignores the nomination and creates the bug task outright, so the nomination is still there [21:29] oh, there is a precise series entry. It's just also showing my nomination message. [21:30] rcj: released [21:30] slangasek: Thank you [21:32] infinity: so what is taking update-germinate so long? [21:36] slangasek: I suspect it might always take this long, I just normally never have something I want to do. :P [21:37] slangasek: But I have a manual archive-reports running too now, since halting the world on update-germinate was apparently not a solid plan. [21:37] infinity: really? why shouldn't this be a no-op for stable releases? [21:37] infinity: you do? does that mean you killed mine, or did it die on its own? [21:37] You had one running? [21:38] infinity: from a minute after I asked you about update-germinate ;) [21:38] slangasek: Mine's been running longer. So, the more interesting question is if you killed mine, or if yours is spinning on a lock, or if you didn't notice it exited. :P [21:39] slangasek: Oh, or mine exited already. [21:40] infinity: ps really thinks mine was the only one running when I checked :) [21:40] Possibly due to the chdist bug I fixed. [21:40] but mine exited non-zero [21:40] slangasek: Yours is running currently? [21:40] no [21:40] wait [21:40] yes [21:40] 30020 pts/5 S 0:00 /bin/sh /home/ubuntu-archive/bin/archive-reports [21:40] 30022 pts/5 S 0:00 \_ /bin/sh /home/ubuntu-archive/bin/run-proposed-migration [21:40] pts/5 is you, so... [21:40] UNIX is hard. [21:41] but it detached from the tty... [21:41] wat [21:41] The background_and_wait stuff probably behaves weirdly with a controlling terminal. [21:41] and $HOME/.archive-reports.lock is absent [21:43] Oh, yay, not whining about SSL certs anymore. [21:52] -queuebot:#ubuntu-release- New: accepted systemd [i386] (artful-proposed) [233-5ubuntu1] [21:53] -queuebot:#ubuntu-release- New: accepted systemd [ppc64el] (artful-proposed) [233-5ubuntu1] [22:01] slangasek: So, have you found anything broken yet? I've only had to fix chdist so far, it seems. [22:02] Hrm, archive-reports is clearly exiting early, cause no component-mismatches. [22:03] infinity: haven't pinpointed the breakage, but yeah, pending-sru is not updated either [22:03] Right, time to -x it. [22:03] And see where it bombs. [22:03] Ideally only one of us. :P [22:03] infinity: go ahead :) [22:04] Watch it succeed this time, since I think I fixed chdist after you started your last run. [22:05] Anyhow, running with much spew. [22:25] slangasek: We have component-mismatches this go around. \o/ [22:26] slangasek: Note that pending_sru doesn't come from archive-reports, it's out of band (and not running because I disabled the whole crontab) [22:26] But it did have one successful run since reboot, I think. [22:31] ok [22:41] slangasek: Oh. When you ran archive-reports, did you run it straight, or with the PYTHONPATH bits from crontab? [22:41] (I ran mine straight and it succeeded) [22:41] * infinity is running every other bit of contrab by hand to see how they fare. [22:41] contrab! [22:41] -queuebot:#ubuntu-release- Unapproved: gnome-calendar (zesty-proposed/main) [3.24.0-0ubuntu1 => 3.24.1-0ubuntu0.1] (desktop-extra, ubuntu-desktop) [22:42] infinity: ah I had grabbed PATH but missed PYTHONPATH [22:42] slangasek: Okay, so we both ran it without the altered PYTHONPATH. Curious. [22:43] (I suspect that's obsoleted by xenial having new enough whatever) [22:45] infinity: there's not much /in/ pythonpath; it's probably lazr that's been updated [22:45] And germinate from git, which we want to keep doing, IIRC. [22:45] yeah [22:45] As Colin's given up on SRUing it. [22:46] lazr in xenial is now newer than the one we have in ~/python [22:46] six should probably go [22:46] the other bits probably still belong [22:47] six is 1.8.0 (~/python) vs. 1.10.0 (xenial) [22:47] Kay, go ahead and whack that, IMO. [22:47] archive-reports clearly ran fine without the downgrade. [22:47] removed the links; keeping the trees until we're sure everything that uses PYTHONPATH is happy [22:48] Almost through crontab. [22:48] Won't restore it until after one more reboot to make systemd stop whining. [22:49] krytarik: I fixed your fix, FWIW. germinate doesn't hate your seed anymore. [22:49] krytarik: (No guarantees it'll do the things you want it to do, but at least it's not exploding) [22:53] slangasek: And have a fresh pending_sru. [22:53] tada [22:54] Two of stgraber's reports running, and if those complete, I'm calling snakefruit done, ish. [22:54] Which turned out to be a lot less painful than I'd thought. [22:56] Oh, hrm. No. old britney (used for /testing/ and /testing-ports/) might be broken. But I can sort that out without holding up everything else. [23:01] slangasek: Ahh, slight stay of execution on some bits that cheat and schroot into the trusty-transitions chroot. Likely because precise was too old. :P [23:02]