[06:09] <pitti> Good morning
[06:12] <cpaelzer> good morning
[06:16] <pitti> mvo: good morning!
[06:16] <pitti> Preparing to unpack .../snap-confine_1.0.30_ppc64el.deb ...
[06:16] <pitti> Unpacking snap-confine (1.0.30) ...
[06:16] <pitti> dpkg: error processing archive /var/cache/apt/archives/snap-confine_1.0.30_ppc64el.deb (--unpack):
[06:16] <pitti>  trying to overwrite '/lib/udev/rules.d/80-snappy-assign.rules', which is also in package ubuntu-core-launcher 1.0.29+1ubuntu1
[06:16] <pitti> mvo: ^ known?
[06:16] <pitti> this serial-kills workers during dist-upgrade, I'll see to turning that into a proper failure
[06:22] <pitti> +Breaks: ubuntu-core-launcher (<< 1.0.29)
[06:22] <pitti> +Replaces: ubuntu-core-launcher (<< 1.0.29)
[06:22] <pitti> ^ this isn't enough, must be << 1.0.30
[07:01] <mvo> pitti: uh, thank you! sorry for this, will fix right away
[07:01] <pitti> I deployed the autopkgtest fix now, should go from "in progress" to "failed" in the next run
[07:03] <mvo> ta
[09:08] <seb128> SRU team, is there any reason the glib/xenial SRU is not copied to updates? it has been marked verification-done at the start of the month and didn't move since ... is that because of the "regression in autopkgtest"?
[09:09] <seb128> Laney, ^ did you look at those/got pinted about them?
[09:09] <Laney> no
[09:15] <Laney> i retried them
[09:17] <seb128> now or before and they failed again?
[09:18] <Laney> 4 minutes ago
[09:18] <seb128> k, let's see if that improves things
[09:18] <Laney> but nobody told me they don't release it because of this
[09:18] <seb128> nobody from the SRU team pinged you saying the SRU was on hold because of that?
[09:18] <seb128> I'm assuming that's why they didn't copy over but I'm not sure
[09:19] <pitti> presumably that, yes; i. e. needs confirmation that the regressions are unrelated and just because of flakiness; some of them might need overides in xenial
[09:33] <rbasak> nacc: I already sent it in Debian bug 825079
[09:35] <cpaelzer> RAOF: rbasak: as last uploaders I wanted to check with you if it is ok if I start a merge of dovecot  2.2.22 -> 2.2.24 and then look again into bug 1524526 as we discussed
[09:36] <rbasak> cpaelzer: go ahead. Thank you!
[09:40] <seb128> pitti, thanks for copying the verified SRUs over!
[09:40] <pitti> no worries!
[09:46] <cpaelzer> rbasak: I asked via mail a while ago, but I can't even find my own mail so no chance to complain :-) - but could you usd-import dovecot for me?
[10:06] <rbasak> cpaelzer: I'm trying. I've not actually done an import before but it's about time that I did. Just figuring out getting a working environment.
[11:02] <cpaelzer> rbasak: any luck with the env to import?
[11:02] <rbasak> Still on it, sorry.
[11:02]  * rbasak is installing usd-import dependencies
[11:03] <cpaelzer> rbasak: not a problem, just needed to check
[11:03] <cpaelzer> I'm prepping myself by parsing through debdiffs - so I'm ready to go then
[11:03] <cpaelzer> already found a "changelof only" change :-)
[11:27] <mdeslaur> chiluk: did you see ted's comment in bug 1592862? could you re-check and see if we can just sync it now?
[11:59] <cpaelzer> rbasak: I'd have my prep by debdiff analysis ready - a lot cruft to clean up in that package already - without git helping me to identify more
[12:00] <cpaelzer> rbasak: I'm going for a bit of soccer with my son which should give you more time to get the import ready - if not when I'm back I'll try to pick something else for the rest of the day
[12:00] <rbasak> cpaelzer: OK. The import's been going for a while. Now up to Natty.
[12:21] <rbasak> cpaelzer: dovecot import pushed
[12:21] <rbasak> nacc: ^^
[12:21] <rbasak> Hope I did it right!
[13:16] <cpaelzer> rbasak: thanks a lot for th eimport
[13:22] <Laney> seb128: it's magically all cleared
[13:22] <Laney> let's see if it more magically gets copied now
[13:22] <seb128> Laney, \o/
[13:35] <cpaelzer> rbasak: nacc: did something on the workflow change dastrically? - I easily able to identify and tag my old/debian, new/debian, old/ubuntu; but when I want to rebase from old/ubuntu to old/debian to start breaking into reconstruct and logical things fail
[13:35] <cpaelzer> rbasak: maybe the history is broken (or other than I expect) - maybe one of the few algo rewrites is not yet in my mental process
[13:37] <cpaelzer> rbasak: in the tree you pushed rebasing from ubuntu/yakkety to import/1%2.2.22-1 (which is old/debian) tries to give me the full history into the rebase -i
[13:39] <rbasak> cpaelzer: use "usd-merge reconstruct old/ubuntu". Not a drastic workflow change but it makes things rebaseable again so the old workflow will still work once that's done.
[13:44] <cpaelzer> rbasak: thanks
[13:45] <cpaelzer> rbasak: I should just forget all old I had in mind and follow the new doc at https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow to ensure I'm not on old tracks
[13:46] <rbasak> cpaelzer: it's very similar. I think "deconstruct" and the need for "usd-merge reconstruct" first are the only major changes.
[14:05] <chiluk> mdeslaur: will do..
[14:24] <pitti> Laney: FYI, in case you check: I disabled the autopkgtest workers on cyclops (armhf Calxeda nodes) on purpose
[14:25] <pitti> Laney: there are now three lxd-armhf[123] arm64 instances on bos01 driven by the autopkgtest-lxd-worker/0 service
[14:25] <pitti> Laney: last week we found some workarounds how to make bug 1531768 a bit less devastating, so I'd like to see how they are holding up
[14:29] <Laney> pitti: okay --- your last post in the bug doesn't sound good though
[14:30] <Laney> will you bring up arm64 workers if this is good now?
[14:30] <pitti> Laney: yeah, but at least with nohz=off they seem to survive for hours instead of minutes, and I have the auto-reboot watch dog in place
[14:31] <pitti> Laney: arm64> this works in principle (I tested it last week)
[14:31] <pitti> Laney: however, we don't have enough capacity ATM
[14:31] <pitti> Laney: and I filed an RT about reboot being broken on arm64
[14:31] <pitti> that's kind of a hard blocker
[14:32] <pitti> well, I commited some workaround to autopkgtest to do "nova reboot --hard" after 5 minutes timeout, but this is both ugly and also utterly slow
[14:32] <Laney> heh
[14:33] <pitti> Laney: but I also want to collect some experience wiht the new lxd runners in general
[14:33] <Laney> surprised nobody else has pressured for reboot to be fixed
[14:33] <pitti> Laney: e. g. this morning I noticed that internet access through proxy was broken (fixed now)
[14:33] <pitti> and there might be some tests that behave differently under lxd than under lxc
[14:34] <pitti> if that works, I'll ask for opening the firewall between PS and the two s390x nodes, and convert them to the new lxd structure
[14:35] <pitti> Laney: not sure if you saw the autopkgtest-lxd-worker/0 service box yet; it's fairly similar to the cloud worker box, except that it talks to LXD remotes instead of nova
[14:36] <pitti> Laney: I just put it onto a new service as autopkgtest-cloud-worker is already fairly loaded with 60 parallel tests
[14:43] <Laney> pitti: I think I saw this before
[14:43] <Laney> how are the SS instances themselves managed?
[14:43] <Laney> cloud-worker starts X and then each one can have Y containers?
[14:44] <pitti> Laney: the three lxd-armhf* SS  instances are created manually by me, by nova boot'ing with userdata https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/tools/armhf-lxd-slave.userdata
[14:45] <pitti> Laney: and then adding their IP and number of parallel LXD containers to credentials/lxd-remotes.conf on wendigo
[14:45] <pitti> Laney: and then juju set autopkgtest-lxd-worker lxd-remotes="$(cat credentials/lxd-remotes.conf)"
[14:45]  * Laney blinks
[14:45] <pitti> Laney: this tells the autopkgtest/lxd-worker instance about the new lxd remote, and it'll start running workers on it
[14:46] <pitti> Laney: (deploy.sh uses this file automatically)
[14:46] <pitti> Laney: I'll wikify all this soon, once it proves itself in production
[14:46] <pitti> and I'm sure we can automate this some more
[14:47] <pitti> Laney: blinks> what's unclear? happy to explain (I don't like bus factor == 1..)
[14:48] <Laney> pitti: Initially all of the configuration in that file - seems painstakingly worked out, and then the list of stpes that I'm not sure I'd get right. :)
[14:48] <Laney> wiki will help
[14:49] <pitti> Laney: yeah, the userdata file is a horrible collection of bug workarounds and lots of black magic to create a btrfs partition
[14:49] <pitti> Laney: we don't have cinder on scalingstack, so no volume-create and friends
[15:13] <LocutusOfBorg> dpkg: error processing archive /var/cache/apt/archives/snap-confine_1.0.30_amd64.deb (--unpack):
[15:13] <LocutusOfBorg>  trying to overwrite '/lib/udev/rules.d/80-snappy-assign.rules', which is also in package ubuntu-core-launcher 1.0.29+1
[15:13] <LocutusOfBorg> wow
[15:13] <pitti> LocutusOfBorg: told mvo this morning, the Breaks/Replaces: has the wrong version
[15:13] <LocutusOfBorg> thanks
[15:14] <LocutusOfBorg> from time to time I upgrade my yakkety machine :)
[15:14] <pitti> LocutusOfBorg: err, you have -proposed enabled?
[15:14] <LocutusOfBorg> yes
[15:14] <pitti> *shrug*, you get to keep both halves
[15:14] <pitti> seriously, never EVAR do this
[15:14] <LocutusOfBorg> pitti, virtual machine
[15:15] <LocutusOfBorg> I'm not *that* crazy
[15:15] <LocutusOfBorg> :)
[15:15] <mvo> hehehe
[15:15] <mvo> thanks, another reminder to fix this silly bug
[15:15] <LocutusOfBorg> sorry for the dup :)
[15:18] <mvo> no worries
[15:29] <coreycb> arges, mind rejecting my dh-python upload to wily?  it has some cruft in it.
[15:29] <pitti> coreycb: done
[15:29] <pitti> arges: ^
[15:29] <coreycb> pitti, thanks
[15:35] <nacc> cpaelzer: ack, that's the major change; it has to, if you care, with the fact that all imports are now git-merge commits. git-rebase will try to replay the merges, which won't work. So we first have to break the git-tree into a 'reconstruct' tree that is a sequence of linear commits with only one parent.
[15:35] <nacc> rbasak: ack, thanks!
[15:48] <nacc> can someone re-trigger the autopkgtests for phpseclib -> php-horde-mapi (new version has landed in yakkety)
[15:49] <pitti> nacc: doing
[15:50] <nacc> pitti: thanks!
[15:50] <nacc> pitti: i think almost all of php has cleared out of excuses now :)
[16:02] <cpaelzer> nacc: yeah thanks for the extra explanations
[16:02] <cpaelzer> nacc: worked fine after I adde the two new stages
[16:03] <cpaelzer> nacc: I'm just starting to build my newly merged package
[16:05] <nacc> cpaelzer: great! sorry for that confusion
[16:07] <cpaelzer> nacc: you are totally innocent for me starting as I did before instead of re-reading the new doc :-)
[16:07] <cpaelzer> s/innocent/unblamable/
[16:08] <nacc> cpaelzer: i hope that's mentioned on the new doc, and if not, i'll go fix that now :)
[16:08] <cpaelzer> nacc: it is there, working fine
[16:08] <nacc> cpaelzer: ok, good :)
[16:08] <cpaelzer> nacc: what is missing thou and I wanted to discuss that - is that if just following the doc you get missing references
[16:09] <cpaelzer> nacc: after the clone at the step of usd-merge tag
[16:09] <cpaelzer> nacc: as soon as you check out or at least fetch those you are good and usd-merge wrks fine
[16:09] <nacc> cpaelzer: ah, that's true, there is aw orkaround
[16:09] <nacc> let's say you named your remote usdi
[16:09] <cpaelzer> nacc: something for that would be nice to be added to the doc
[16:10] <nacc> then you can do `usd-merge tag usdi/ubuntu/yakkety usdi/debian/sid`
[16:10] <nacc> and it will dtrt
[16:10] <nacc> but yes, i'll clarify that! i wrote it from the persepctive of i have the imported trees locally that i'm pushing :)
[16:10] <cpaelzer> nacc: true, I don't mind what way gets added to the doc, also I expect most to find a way around like me - but "something" in the doc would surely be nice
[16:11] <nacc> cpaelzer: yep, fixing now
[16:13] <cpaelzer> nacc: also I tihnk section 7 mght be incomplete subject is "Tag, push and review.", but there is no tagging involved :-)
[16:14] <cpaelzer> nacc: in the long past we called that thing to be tagged archive/version, but I'm sure you have something new matching the remaining tests in a better way
[16:17] <cpaelzer> nacc: maybe just new/ubuntu ?
[16:17] <cpaelzer> until we know it is accepted and uploaded we can't really give it a version tag - that was the discussion back then
[16:17] <nacc> cpaelzer: yep, that's the discussion rbasak and i are still going through
[16:18] <nacc> cpaelzer: but from a MR perspective, that's ok
[16:18] <nacc> cpaelzer: just don't tag (just checkout -b merge or whatever) and push your branch
[16:18] <rbasak> Which tag are you talking about?
[16:18] <nacc> reviewer reviews the branch, and if uploader, they'll tag
[16:18] <nacc> rbasak: i think the 'proposed' new version
[16:18] <nacc> rbasak: as a result of the merge
[16:18] <nacc> proposed strictly from the submitter's perspective, not the archive
[16:19] <rbasak> ATM that appears as the MP's proposed branch, right? So no need to tag, but do need a branch name.
[16:19] <rbasak> In the past, we didn't technically need a branch.
[16:19] <cpaelzer> nacc: I'm fine with a brnach only, just drop the "tag" from the subject in section 7
[16:20] <rbasak> Though "new/ubuntu" is handy.
[16:20] <rbasak> But that'll move upon addressing review comments, so maybe we should stop using it and focus on a branch tip instead.
[16:20] <cpaelzer> nacc: and if you rewrite section 7 you might add to push tags as well, otherwise we don't have to discuss how to name them :-)
[16:22] <cpaelzer> no matter if we follow the branch (which is nice as it moves) or add a tag, uploading tags will surely help for logical/reconstruct and such tags
[16:22] <nacc> cpaelzer: updated, take a look?
[16:22] <nacc> cpaelzer: yep, i forgot to include the tags to push as well, you're right, fixed now
[16:23] <cpaelzer> nacc: a bit wide, but yeah good now
[16:24] <nacc> cpaelzer: yeah, i'll figure that out :)
[16:25] <cpaelzer> nacc: not to say that 99% of screens on the world would have enough screen-estate to jsut display it wide :-/
[16:26] <nacc> cpaelzer: now it's a little scrolly box :)
[16:28] <cpaelzer> nacc: it losts its index as #2 by that
[16:28] <cpaelzer> nacc: I'd vote for \ and indented follow up line
[16:31] <nacc> cpaelzer: check now?
[16:31] <cpaelzer> nacc: I don't want to be a pixel mover, but since we are at it anyway - the distance between "git push" and the line above is too small and the distance to the following line is too huge
[16:32] <cpaelzer> nacc: but feel free to just keep it as-is - it  is good
[16:36] <nacc> doko: question on openjdk-9-jdk (two questions, actually). 1) openjdk-9-jdk is uninstallable in 16.04 because it and openjdk-9-jdk-headless provide the same file (and -jdk depends on -jdk-headless). 2) openjdk-9-{jdk,jre} provide {java*-sdk,java*-runtime}, which causes some dependency issues (LP: #1584118). Any ideas on what the right way to resolve those are?
[16:42] <nacc> cpaelzer: it is a wiki :-P
[16:42] <nacc> cpaelzer: i don't know why the wiki formats that way, but it's not something i'm specifying, fwiw
[19:00] <sil2100> cyphermox, BenC, rbasak: hey guys! I won't be able to make it for todays meeting sadly
[21:40] <nacc> slangasek: could you take a look at LP: #1592890? it will clear out two more excuses entries (php7cc and php-pimple itself)
[21:40] <nacc> slangasek: i've already sent the same patch to Debian, if you want to just wait for that to get accepted and sync
[21:48] <nacc> mdeslaur: you added a patch to php-horde-http during 16.04 which turned a non-fqdn into a fqdn in a test case. But afaict, the test passes w/ or w/o it (and it's not in Debian still). There is no bug report linked, so I'm not sure if you know specifically why/if it's needed?
[22:06] <nacc> jbicha: thanks for the advice and pointers on the zend{,-}framework stuff!
[22:46] <nacc> let's say i'm providing a fix for a package which has received a security update, but my fix is not itself a security update. The current version of the package is 7.0.4-7ubuntu2.1. Would my package be versioned 7.0.4-7ubuntu2.2 or 7.0.4-7ubuntu3 ?
[22:46] <nacc> I guess not the latter, only in case there was a 7.0.4-7ubuntu3 published in the development release that it might conflict with?
[23:12] <mdeslaur> nacc: it was failing it's autopkgtest
[23:12] <mdeslaur> nacc: feel free to drop it if the autopkg test now works without it
[23:30] <jbicha> nacc: using the version numbering recommended on https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation is a good standard regardless of whether the sru is "security" or not
[23:30] <jbicha> 2.2 is fine
[23:31] <nacc> jbicha: ack, thanks!
[23:32] <jbicha> I think there's a little bit of flexibility as long as the number is less than it could be in a future release
[23:32] <nacc> mdeslaur: ok, i'll double-check again and request a sync if it works
[23:32] <nacc> jbicha: ack, that makes sense
[23:32] <jbicha> for instance I gave my https://launchpad.net/ubuntu/+source/abiword SRU 3.0.1-6ubuntu0.16.04.1
[23:33] <jbicha> but strictly following the rules I think it should have been 3.0.1-6ubuntu0.1
[23:33] <nacc> yep, i think i was just clarifying on if those rules applied to non-security updates and then how strictly they were followed :)