[02:14] so do we have a progress update since I was last on? or is it pretty obvious? [04:30] infinity: ddebs should set themselves up, retracers and autopkgtests coming now [04:30] http://ddebs.ubuntu.com/dists/xenial/ -- yup [04:33] infinity: there's no britney for xenial yet either [06:31] infinity: xenial autopkgtest queues ready for business; but I stopped the ppc64el workers, see #u-devel [06:34] infinity: are you going to switch $DEFAULT_SERIES in britney1-ubuntu and set up britney, or want me to walk through it? [08:24] slangasek: hi - could you look at the xubuntu core MP again, there are changes following your disapprove, we really want to get this in as soon as possible so we get as much cycle as poss to test it https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 [08:24] thanks :) [08:56] adios chicos, it's been a pleasure working with you, I don't expect I'll be going too far https://kubuntu.org/news/jonathan-riddell-stands-down-as-release-manager-of-kubuntu/ [08:59] infinity, Laney: do you have a magic script to move over wily's proposed packages (except the new ones which got accepted today) over to xenial? [08:59] * pitti bbl [08:59] pitti: I don't have a magic script, I do it by hand, ish. [09:49] Riddell: Good luck [09:51] just filed the ticket (#38) to create new chroots on the developer boxes [09:53] thanks cjwatson :) === lordieva1er is now known as lordievader === lan3y is now known as Laney === [BNC]flocculant is now known as flocculant === pietroalbini_ is now known as pietroalbini === rsalveti_ is now known as rsalveti === flocculant is now known as Guest98685 === plars_ is now known as plars === broder_ is now known as broder === \b is now known as benonsoftware [10:14] grep: /home/ubuntu-archive/public_html/proposed-migration/xenial/update_excuses.html: No [10:14] +such file or directory [10:14] cjwatson, infinity: ^ should I just go ahead and create that dir, or is there something more to it? [10:14] (cron mail on snakefruit) [10:15] * pitti mkdirs, what could possibly go wrong :) [10:16] will need to update the symlinks too [10:16] ah, is that manual? ok [10:16] AFAIK [10:16] but I'll wait with that until we actually have a report === Guest98685 is now known as flocculant [10:17] Laney: I had assumed DEFAULT_SERIES=wily → DEFAULT_SERIES=xenial would do that [10:17] * pitti commits that [10:18] hah, infinity just beat me to it [10:19] pitti: Did your pkg-create-dbgsym upload break me? :P [10:19] https://launchpadlibrarian.net/222260532/buildlog_ubuntu-xenial-armhf.vim_2%3A7.4.826-1ubuntu1_BUILDING.txt.gz [10:19] infinity: wut? [10:19] ^-- That seems weird. [10:20] mkdir was unnecessary, p-m would've done that once it started running for the right series. [10:20] cjwatson: ah, ok [10:20] infinity: apparently so, meh; let me upload a revert, then I'll investigate [10:22] pitti: I removed 0.70 as well to hurry the process along. [10:22] infinity: ah, even better; then I don't even need to upload a revert, right? [10:22] ood, there's no python* package involved at all, which was the only case that this changed [10:22] pitti: That vim build concerns me, given that it succeeded on most arches, but not all, seems likely there's some sensitivity to parallelism or other raciness going on. [10:23] it smells more like this bug has been there for quite some time, and we've just been lucky (or retried the builds without much investigation) [10:23] pitti: Possibly. [10:23] pitti: Are we almost ready to move to the debhelper-based implementation and scrap ours? [10:24] infinity: I didn't look at that yet [10:24] infinity: but the debhelper one spits out *.debs, not *.ddebs, so I figure before we do that we need some rework in LP and ddeb-retriever [10:24] (which won't be a "ddeb"-retriever any more then) [10:24] pitti: Err, really? I thought there was some back and forth on that and then it ended up being ddebs? [10:25] infinity: hm, then I didn't get that; I saw the discussion and had the impression they sticked to *.deb [10:25] pitti: I'm somewhat opposed to a non-policy-compliant deb-like thing being .deb [10:25] me too, but I think the argument was something like "similar to -dbg.deb" or so [10:28] pitti: Anyhow, if you're sure this bug can't possibly relate to 0.70, I can just copy it back in place. [10:28] I'm retrying that build with 0.70 right now. [10:28] infinity: it's very unlikely; the effective diff was [10:28] if [ "$pkgname" != "${pkgname#python}" ]; then [10:28] [10:28] but there is no python* binary in that vim build [10:30] infinity: indeed it looks like dh_strip and dh_gencontrol run in parallel for the same packages [10:30] pitti: Well, it should succeed/fail in ~7m. [10:31] indeed pkg-c-d is currently assuming that dh_strip runs before dh_gencontrol === tjaalton_ is now known as tjaalton [10:31] pitti: Could be a parallelisation error in dh or vim, but I've never seen this before, so weird. [10:32] hm, debian/rules looks okay [10:32] Yeah, it looks pretty serial. [10:32] It exports MAKEFLAGS=-j, but that shouldn't suddenly mangle recipes within a target. :P [10:35] infinity: submitted bug 1509299 and attached the build log to it, as they tend to disappear on retries [10:35] bug 1509299 in pkg-create-dbgsym "parallel build race condition between dh_gencontrol and dh_strip" [Undecided,New] https://launchpad.net/bugs/1509299 [10:36] pitti: Ta. The weird thing is that this wasn't isolated, that build failed on armhf *and* powerpc (succeeded on ppc on retry, armhf is still building). [10:36] pitti: Which seems weirdly frequent for a rare race we've never noticed before. [10:36] pitti: But maybe I'm just having an unlucky Friday. [10:39] ok, treating that as medium for now; /me looks at broken ddebs.u.c. indexes then [10:45] infinity, pitti: it's a rules error [10:45] the indep and arch targets are run in parallel [10:46] I don't know if it's a make issue, or a rules issue, the export of the different DH_OPTIONS goes wrong. yeah for -j as the default in dpkg :-/ [10:47] ah, that's why all the lines appear twice [10:48] Probably not dpkg's fault, he's setting MAKEFLAGS. [10:48] I can turn that into a PARALLELFLAGS and pass it explicitly just to the build target makes. [10:48] yep, "because it should work", done without testing [10:49] ah, it never sets DH_OPTIONS=-a or -s [10:49] just -i [10:51] anybody working on a dpkg merge? [10:51] I will, yes. [10:51] s/will/am/ [10:51] ta [10:53] pitti: Copying your package back in. [10:54] infinity: cheers [10:54] infinity: OOI, where do you copy it from? [10:54] copy-package -s xenial-proposed --to-suite=xenial-proposed --force-same-destination --silent --auto-approve -e 0.70 -b pkg-create-dbgsym [10:54] wow [10:54] you can copy deleted packages? [10:55] Yup. [10:55] sure can [10:55] neat [10:55] hm, britney still doesn't run, wth [10:56] I got another mail about the missing /home/ubuntu-archive/public_html/proposed-migration/xenial/update_excuses.html, so archive-reports clearly ran [10:56] but proposed-migration/code/b1/ wasn't pulled yet === davmor2_ is now known as davmor2 [11:05] * pitti pulls it manually and sees if that helps somehow [11:06] run-proposed-migration is supposed to do that [11:06] yeah, that's what I thought too [11:06] * Laney can see it right there [11:07] * pitti tries DISTRIBUTION=ubuntu SERIES=xenial run-proposed-migration [11:07] and sure enough that immediately exits [11:08] the STOP file [11:08] ah! proposed-migration/STOP exists [11:08] :) [11:08] I guess leftover from yesterday? [11:08] Yep. [11:09] tail -f proposed-migration/log/xenial/2015-10-23/11\:08\:46.log [11:09] muuuc better [11:09] * pitti tosses in a 'h' [11:09] betterh [11:09] Laney: no; "better, haha!" [11:14] Right, I touched STOP yesterday to stop it doing stuff with wily [11:14] yay, 238 xenial test requests on all three arches [11:15] that'll keep stuff busy over the weekend :) [11:15] Hopefully it'll migrate base-files soon so that people stop complaining about launchpad-buildd recipes producing wrong versions [11:15] Not touching package due to block request by freeze (contact #ubuntu-release if update is needed) [11:16] (also, outstanding tests, but this needs unblocking too I figure) [11:16] Yeah, we might want to keep the block there for now, but unblocking base-files is sane. [11:16] * infinity does that. [11:16] Removing block-all source is on NRCP [11:16] * infinity does that after checking the diff. [11:17] infinity: looks like you did branch-livefses? [11:17] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and *.yaml etc. is still wily, I'll adjust the symlinks [11:17] I did yesterday, yes. [11:18] doko: Your base-files merge dropped os-release from conffiles. [11:19] infinity, intended [11:19] doko: ? [11:19] moved to /usr/lib [11:19] or is there a mistake? [11:19] oh, and /etc/os-release becomes a symlink? [11:20] http://bugs.debian.org/753658 [11:20] Debian bug 753658 in base-files "/etc/os-release has moved" [Normal,Fixed] [11:20] shoudln't it move to /lib then, as long as we still have separate /usr ? [11:20] Probably. [11:20] Eh, whatever; we have separate /usr but it's always mounted [11:20] AIUI [11:21] * Moved /etc/os-release to /usr/lib/os-release. Put a symlink pointing to [11:21] the new place. Thanks to Marco d'Itri for the report. Closes: #753658. [11:21] I got debian bug reports from people with separate /usr who didn't have an initramfs; not that I think that this is even remotely sane/supported, but just saying [11:21] yay for not being a conffile any more, though [11:22] doko: Also dropped a newline from /etc/issue accidentally. [11:22] ouch [11:24] pitti, so should that be move to /lib/os-release? is there a spec / documentation referencing /usr/lib/os-release? [11:24] doko: I read the debian bug now, should be fine [11:24] doko: indeed we mount /usr in the initramfs, so that's fine [11:25] doko: man os-release [11:30] Hrm. Not convinced that symlink should be shipped in the package. [11:30] Seems like it should be written once in postinst. [11:30] So users can replace it with a file. [11:31] why do you want it to be replacable? [11:31] Because /etc/os-release is for user overrides of /usr/lib/os-release [11:31] There's no point in having both locations if they're always identical. [11:32] The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should [11:32] check for the former, and exclusively use its data if it exists, and only fall back to [11:32] /usr/lib/os-release if it is missing. [11:32] "/etc/os-release should be a relative symlink to /usr/lib/os-release, to provide [11:32] compatibility with applications only looking at /etc." [11:32] Yeah, I read that as "it should default to being a symlink", but I agree the doc is ambiguous between my paste and yours. :P [11:33] There's not much point in defining precedence, if they're always the same. [11:34] They don't seem to have provided any rationale for having it available in the tree in both places. [11:35] rbasak: Except for the usual systemd/coreos rationale of [11:35] "/usr is immutable default configs, /etc is overrides" [11:35] Likely the only reason for os-release to also ship the symlink is because it used to live in /etc, so it needs backward compat with software that only looks there. [11:36] Unlike systemd units, etc, which we've expected in /lib from day one. [11:36] It was supposed to be yet-another-standard-to-rule-them-all, and now we have two of them? [11:37] * rbasak is feeling grumpy [11:37] Never believe such claims. [11:37] Then you can be grumpy all the time rather than having your hopes inevitably dashed. [11:38] Well, I never particularly believed it in the first place. But it would have been nice if they had thought of this before changing it and making everyone leave cruft everywhere. [11:39] Given that moving it to /usr/lib won't benefit Debian, why move it at all? [11:39] Might as well just keep it in /etc. [11:39] (not that it matters as it's moved now) [11:39] Then we could just skip straight to their fifth iteration when they decide on it. [11:40] * rbasak will stop ranting now. === popey_ is now known as popey [12:12] rbasak: in clearlinux, we don't have /etc/os-release and have been fixing everything to start checking both locations. E.g. last discovery was docker, and the merge proposal to fix it is not yet upstream nor released. [12:12] infinity: systemd accepts units from /usr/lib, even on /lib enabled systems.... it's kind of freaky. [12:13] rbasak: i don't think os-release was for debian benefit... [12:37] xnox: it's to have one standard everywhere. But now we have two standards everywhere. If /etc/os-release is the one required and more universally available, then I don't see any need to do anything different now. [12:37] rbasak: the os-release spec says: use /etc/os-release if present, otherwise check /usr/lib/os-release as well. [12:37] (well the updated spec, original only had /etc) [12:38] xnox: deciding it should be somewhere else now doesn't necessarily mean that the spec has to be changed like it has been done. [12:39] rbasak: the change enables "thin" derivatives. With mostly identicaly /usr (read-only / atomic), yet enough custom stuff in /etc & e.g. /opt to warrant a change in os-release. [12:39] xnox: the change goes beyond that. It only needed to be changed to say that /etc/os-release may be a symlink. [12:40] there is no requirement for it to be a symlink.... and in practice it shouldn't be a symlink. it should either be a different thing, or not exist at all. [12:40] and not everything supports symlinks.... [12:40] xnox: I didn't say that there was a requirement for it to be a symlink. Read what I said. [12:41] rbasak: sorry, then i don't understand. both old and new standard say nothing about whether or not it's a real file, or symlink somewhere else. [12:41] rbasak: and the change was not about symlinks, or moving locations. but splitting immutable & configurable parts. Previously it wasn't like that and rpm doesn't have sensible config file handling ;-) [12:42] xnox: "both old and new standard say nothing". No, that's wrong. It says "/etc/os-release should be a relative symlink to /usr/lib/os-release..." [12:43] xnox: I'm saying that this "should" is unnecessary. The spec only needed to be amended to say that /etc/os-release may be a symlink, and no changes in "shoulds" for OS implementors or changes in "shoulds" in how apps should read the file would have been necessary. [12:44] rbasak: the goal is to drop file from /etc. and make it muitable. what you are proposing whould not achieve that, especially on rpm systems which have broken config handling. [12:44] rbasak: as in on upgrade /etc/os-release.rpmNEW was written out without updating /etc/os-release -> not good =) [12:44] rbasak: at the moment we are in a transition period. [12:45] rbasak: this is /etc -> /lib mistake, as have been seen e.g. with udev.d rules. one would think, that history would be learned. [12:46] xnox: how so? [12:48] tsimonq2: how so, what? udev past mistake? initially udev rules were only loaded from /etc cause it needs to be customizable and at early boot. Later, people did modify these, upstreams/upgrades rename things resulting in an utter mess. Hence udev rules got moved to [/usr]/lib location and /etc became just an overlay, for admin customizations. Segregating system defaults from admin customizations. If one doesn't segregate system & admin defaults, [12:48] there is no easy upgrade path. [12:48] tsimonq2: http://blog.surgut.co.uk/2015/03/boiling-frog-or-when-did-we-loose-it.html [12:54] xnox: no, 07:44:47 AM < xnox> rbasak: at the moment we are in a transition period. [12:55] xnox: first time seeing this end of things, so I am curious. [12:56] tsimonq2: once one no longer wants to support old tooling parsing /etc/os-release, one can and will drop such symlink. [12:56] tsimonq2: read the os-release man page. it does state said symlink is for backwards compat only. [12:57] xnox: I didn't want to know about that issue at all :) [12:57] =) [12:57] xnox: I just wanted to know where we are at [12:58] xnox: what step are you guys on? https://wiki.ubuntu.com/NewReleaseCycleProcess [13:01] tsimonq2: i'm not doing it. wait for "open for development" email to ubuntu-devel-announce. [13:01] like last one, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-May/001134.html [13:02] oh [13:03] xnox: so is that step 28? Inform #ubuntu-devel and ubuntu-devel-announce that the new release is now open for uploads, pointing to merge-o-matic output. [13:03] tsimonq2: no. [13:04] tsimonq2: i said, i do not know. hence assuming it is not open. it will be open for development, once the email is out. so wait for that. [13:05] ok :) [13:13] tsimonq2: Waiting to make sure that autopkgtests have their lives sorted out sufficiently to be able to let stuff migrate to xenial, I think. [13:13] infinity: I guess once we see base-files migrate successfully, we can unblock the world and open? [13:14] cjwatson: I know I am (maybe) gonna irk you, but what step is that? [13:14] tsimonq2: I don't remember. [13:14] It's not completely linear. [13:15] A lot of it is "make sure not to forget this stuff", not "must be done in exactly this order". [13:15] ok :) [13:16] cjwatson: so after xenial is unblocked, is that when it is marked as Development in Launchpad? [13:16] Yes [13:16] cjwatson: and when the announcement is sent out? [13:17] I would assume so. [13:17] * tsimonq2 whispers to himself, "step 28" [13:18] ◔ ⌣ ◔ [13:41] infinity: AFAICS everything on http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.yaml should be moved to xenial; want me to do that? [13:41] (I thought I saw some "real" wily SRUs being accepted, but openjdk-9 is the most recent one and not an SRU) [14:11] * pitti moves wily-proposed cruft to xenial-proposed, to clear up the way for SRUs [14:19] pitti: I'm doing it now. [14:19] ^- log4cxx should help base-files migrate [14:20] cjwatson: Also, I'm reminded every 6 months that I really want a copy-package --with-or-without-binaries-yknow-whatever option. :P [14:21] infinity: already copied to xenial [14:21] pitti: Oh. [14:21] infinity: I'm removing them from wily-proposed now [14:21] infinity: xenial-proposed of course, sorry [14:21] pitti: Did you watch carefully to make sure they all succeeded? [14:21] pitti: In that ones with binaries need -b and ones without will fail with -b. [14:22] I ran with -b, and got "1 package successfully copied." on the FTBFS ones [14:22] * infinity raises brow. [14:22] but Laney says there are some rejections, checking [14:22] Did someone fix that since wily opening? [14:22] Copy candidates: [14:23] node-srs 0.4.8+dfsg-2 in wily [14:23] pitti: Oh. copy-package told you that. [14:23] Candidate copy target: https://api.launchpad.net/devel/ubuntu/+archive/primary [14:23] 1 package successfully copied. [14:23] e. g. that [14:23] pitti: copy-package lied. [14:23] yeah, it might be lying [14:23] pitti: You probably have a ton of mail. [14:23] pitti: Also, you might want to use --silent, no need to spam the world with this. :P [14:24] pitti: But I'll let you sort the mess now that you started. [14:25] (Welcome to "things that look simple when someone else does them") [14:25] yep [14:25] heh :) [14:25] yeah, will use --silent next time, sorry [14:27] I've made copy-package's output a little less misleading. [14:27] (It'll say "1 copy requested." now) [14:27] thanks [14:28] so I'll re-copy the rejected ones with --silent and without -b [14:28] And yeah, I should fix the copier at some point ... [14:29] pitti: I'm sure http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#base-files should be showing log4cxx/amd64 has "Always failed" by now - it's been at least a few cycles [14:29] Oh, though I guess it could have been requested again [14:30] pitti: Do you have any way to push dict-foldoc and log4cxx up the queue? I believe we're only waiting for those to get base-files migrated. [14:30] And then hopefully we can unblock and open. [14:32] cjwatson: no, didn't run yet (click on the individual packages, you won't see a result from yesterday or today), e. g. http://autopkgtest.ubuntu.com/packages/d/dict-foldoc/xenial/amd64/ [14:32] the older ones are the latest successful ones I copied from wily [14:32] to be able to continue to track "regression" vs. "always failed" [14:32] queues are 181 on amd64, 194 on i386 [14:33] and lcy01 is still only running with max 5 instances, as with anything more it keeps falling over :( [14:33] ok, copied the FTBFS ones [14:34] e. g. https://launchpad.net/ubuntu/+source/mpdris2/+publishinghistory [14:36] pitti: Kay. I have a script here to check both match. So, after a publisher run, I can verify that, then we can go on a deleting spree. [14:36] pitti: Unless you trust yourself enough that you've started deleting already. :P [14:36] infinity: err, sorry, I already did [14:36] Heh. [14:36] I spot-checked some 5 packages, and they looked ok [14:37] we'll get almost all of them back during autosyncs too, but there are a few -ubuntuN ones, so I mostly checked those [14:37] but also e. g. https://launchpad.net/ubuntu/+source/bup/+publishinghistory [14:38] pitti: I'll double-check for paranoia in a bit. [14:38] infinity: http://paste.ubuntu.com/12903087/ is the package list of everything that was in wily-proposed [14:38] pitti: log4cxx ran today, but a bit earlier perhaps. [14:38] So maybe your copies. [14:38] pitti: Yup, I have the same list. [14:39] cjwatson: no, I only copied the latest successful result, no failed ones (as they don't serve any purpose) [14:39] cjwatson: the point is just that if we get a failure as the first "real" xenial run we need to tell apart regression vs "always failed", so I "seeded" xenial with the latest "pass" [14:40] infinity: let's see for how much longer we'll drag cairo-5c along :) [14:40] I'm failing to wrap my head around that today, but I guess I don't in fact need to know :) [14:41] cjwatson: ok, sorry; indeed http://autopkgtest.ubuntu.com/packages/l/log4cxx/xenial/i386/ is a valid run and britney should consider it [14:41] pitti: I feel like it's the real champion here. [14:41] * pitti checks [14:41] Oh. Did someone bring forward the britney history? [14:41] infinity: how do you mean? [14:41] Erk. [14:42] infinity: we didn't copy the wily autopkgtest results if you mean that, which is probably the reason for a good chunk of the ~ 300 test requests that we got after opening [14:42] infinity: but at least python3-defaults, debhelper etc. are genuine new requests [14:42] Oh, Dates ... [14:43] cjwatson: Fixed. [14:43] infinity: you fixed Dates, or something else? [14:43] Dates. [14:43] That was quick. [14:43] I have a way with shells? [14:43] oh, for keeping the 523 days or whatnot of cairo-5c? :-) [14:43] can't lose that record! [14:44] Well, I assumed it couldn't just be a copy, because we've had uploads since opening. [14:44] Hopefully, the run in progress doesn't undo my handiwork. [14:44] cjwatson: I concatenated and sorted wily and xenial into a new xenial. [14:45] Cool. [14:45] oh, wth [14:46] Oh, hrm. That has some dupes, though. Might need to be more clever. [14:46] cjwatson: ah, that's it -- teh result is for base-files/9.4ubuntu1 (and that's already in britney's cache) [14:46] cjwatson: but there was another upload ubuntu2 to fix the missing newline [14:46] If britney doesn't rewrite it to fix it. [14:46] and that's still in the queue [14:47] cjwatson: so, I have a really awful way of expediting this, if desired [14:47] I could flush the entire queue, stuff these 4 tests back in, and then let britney re-create the other test results [14:47] can't directly reorder an AMQP queue, sorry [14:48] while I'm at screwing up things, let's do that :) [14:50] infinity: britney should fix it, I think [14:50] cjwatson: S'ok, I just learned a new shell trick. [14:50] (haven't checked, I'm knee-deep in twisted code) [14:50] sort -u -k1,1 Dates > Dates.new [14:50] (To sort on only the first field) [14:50] ok, base-files tests are now at the front of the queue [14:52] all four running on http://autopkgtest.ubuntu.com/running.html now [15:00] infinity: turns out I didn't actually remove yet as it stumbled over openjdk-9 which you already removed [15:00] infinity: I have the Remove [y|N] prompt now; do you still want to run your script first? [15:01] (it takes ages to even get to that point) [15:02] pitti: I'll check right now, yeah. [15:02] Looks like my Dates hacking worked. [15:04] pitti: I see some still missing, so either snakefruit's mirror is behind, or you missed a few. [15:04] pitti: Waiting and trying again/ [15:04] infinity: ah, you're checking on archive.u.c., not LP publishing [15:05] pitti: Well, snakefruit, but yes. [15:05] (ie: rmadison) [15:05] ok; /me cancels this and stashes the remove-package command for later [15:06] slangasek: ^ fwupdate. [15:07] pitti: No, you really did miss some. Spot-checking my list against publishing records, there are some xenial records missing. [15:07] pitti: http://paste.ubuntu.com/12903342/ [15:08] pitti: thanks [15:12] infinity: fun; thanks for the pastebin, copying those again then [15:13] pitti: Most of those have binaries, I think, so need -b, but I didn't check them all. It might be a mix. [15:17] infinity: hm, so maybe it stops at the first error or so [15:18] * pitti might need to re-do the loop to call copy-package individually on each one, instead of a big batch [15:21] ok, plastimatch, ruby-gsl, and statsmodels worked now [15:21] pitti: When you think you've cleaned it all up, lemme know and I'll double-check again. :P [15:23] meh, --silent also disables rjection mails [15:23] * pitti throws hands in the air, mumble ridiculously complicated mumble [15:25] pitti: Sometimes, it's best not to look behind the curtain. [15:25] But, y'know, welcome back here. We have tea and cakes. [15:30] And snakes [15:30] infinity, cjwatson: https://launchpad.net/ubuntu/+source/base-files/9.4ubuntu2 promoted [15:31] pitti: I think --silent disabling rejection mails could be argued to be a bug - the main purpose was to have a way to not spam with success mails in some cases [15:31] pitti: base-files> excellent, thanks [15:31] infinity: anything more before we open? [15:32] infinity: I did the next round of copies (both with binaries and without -b for the FTBFS ones) [15:32] but due to the complete lack of error messages I guess that again some packages might just silently have failed; so I guess it's waiting for pulisher now and rmadison again [15:33] pitti: Yeah, we'll see shortly, yes. You could check pending publishing records for all of them, but I'd rather see the archive consistent anyway. [15:33] infinity: yeah, doing that would need a script; too much effort/error prone in firefox [15:33] * pitti -> dinner, will check again after that [15:34] cjwatson: Whoever's writing the email, and maybe confirming pitti's copies are sane. [15:35] cjwatson: But we're pretty much thereish. [16:06] infinity: can you re-run your script? I checked with rmadison again, and it seems to be ok now [16:07] rmadison -s xenial-proposed $(cat remove-from-wily-proposed) > /tmp/out [16:07] for p in $(cat remove-from-wily-proposed); do grep -q $p /tmp/out || echo $p; done [16:07] where remove-from-wily-proposed is the above pastebin (i. e. packages from http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html) [16:08] wow, e. g. https://launchpad.net/ubuntu/+source/jruby/1.7.22-1ubuntu1 actually built in xenial, but not in wily [16:10] pitti: Confirmed, LGTM. [16:10] indeed a surprise [16:10] pitti: Delete away. [16:10] * pitti pushes the delete button and calls it a day/week [16:11] infinity: safe travels back home! [16:11] infinity: and congrats for the release [16:13] pitti: Not going home for another two weeks, but I'll see you in Austin. [16:13] infinity: oh, ok; you stay in London? [16:14] pitti: Detour on the way home for a week, plus VAC. [16:14] s/home/to Austin/ [16:15] bye pitti! [16:15] Laney: bye, enjoy the weekend! [16:15] * Laney is coming to .de ;-) [16:15] ^ BTW, none of these syncs are urgent in any way, just stashing them after reviewing my merges [16:15] ah yes, they made polkit support the old syntax [16:15] or backported new stuff, or something [16:16] Laney: no, new polkit is just a lot of backported bug fixes, and getting back in sync [16:16] same for our ppolkit-qt-1 vs. polkit-qt5-1 split [16:17] they are both in Debian's ppolkit-qt-1 package now, and we can remove polkit-qt5-1 source once built [16:17] pitti: indeed, I remember that we (and debian) were blocked because of the JS stuff [16:17] Laney: yeah, and I don't see that change anytime soon [16:17] but smcv or someone backported a load of good stuff [16:17] which is nice [16:17] nanyway [16:17] get going :) [16:18] these poor test machines now won't have any free time on the weekend :) [16:18] debci-xenial-amd64 465 [16:18] debci-xenial-armhf 321 [16:18] debci-xenial-i386 458 [16:19] did you get some more capacity? [16:19] or still on 5? [16:19] Laney: no, lcy01 is still brittle, only 5 on that; 8 on lgw01 [16:19] and of course 16 armhf LXC ones as usual [16:20] mmm [16:20] Laney: I had to disable ppc64el, as that's power7, and xenial is power8 now [16:20] yeah I heard [16:20] hope we can get scalingstack bos soon [16:20] I have a spare machine and I was wondering if I could use that to help somehow, maybe automated build machine, or somethibg of that nature...any ideas? [16:20] * pitti waves, have a nice weekend everyone! [16:22] bai [16:23] spam much? XD [16:37] infinity, seb128, slangasek: hey! If anyone of you guys has a minute, we have a silo that introduces a new binary package to the qtmir source - qtmir-tests [16:37] https://ci-train.ubuntu.com/job/ubuntu-landing-022-2-publish/46/ [16:50] infinity: I imagine I could copy and paste an email if you like. [16:50] cjwatson: I expected doko might want to do one, but if he's not... [16:50] doko: Did you have a "welcome to Xenial" mail drafted? [16:51] I think we could unfreeze, since all this stuff going through the queue isn't exactly toolchain. [16:51] Yep. [16:51] We can thaw both the queue and britney, I think. [16:51] Lemme do the former. === infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Wily 15.10 | Archive: open | Wily Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis [16:54] infinity, cjwatson: yep, wanted to wait until the queues cleared up, and send it tomorrow. afk now [16:54] All right, how about I turn on auto-sync? [16:55] then the queues will be busy with main, but anyway, they can do something over the weekend [16:56] cjwatson: auto-sync on sounds fine by me. [16:56] And I think I'll clear the britney block, if no one has any objections? [16:56]