=== NCommander is now known as mcasadevall === JanC is now known as Guest35692 === JanC_ is now known as JanC [06:09] Good morning [06:12] good morning [06:16] mvo: good morning! [06:16] Preparing to unpack .../snap-confine_1.0.30_ppc64el.deb ... [06:16] Unpacking snap-confine (1.0.30) ... [06:16] dpkg: error processing archive /var/cache/apt/archives/snap-confine_1.0.30_ppc64el.deb (--unpack): [06:16] 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] mvo: ^ known? [06:16] this serial-kills workers during dist-upgrade, I'll see to turning that into a proper failure [06:22] +Breaks: ubuntu-core-launcher (<< 1.0.29) [06:22] +Replaces: ubuntu-core-launcher (<< 1.0.29) [06:22] ^ this isn't enough, must be << 1.0.30 [07:01] pitti: uh, thank you! sorry for this, will fix right away [07:01] I deployed the autopkgtest fix now, should go from "in progress" to "failed" in the next run [07:03] ta [09:08] 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] Laney, ^ did you look at those/got pinted about them? [09:09] no [09:15] i retried them [09:17] now or before and they failed again? [09:18] 4 minutes ago [09:18] k, let's see if that improves things [09:18] but nobody told me they don't release it because of this [09:18] nobody from the SRU team pinged you saying the SRU was on hold because of that? [09:18] I'm assuming that's why they didn't copy over but I'm not sure [09:19] 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] nacc: I already sent it in Debian bug 825079 [09:33] Debian bug 825079 in icinga2-ido-mysql "Package links against libmysqlclient_r" [Normal,Open] http://bugs.debian.org/825079 [09:35] 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:35] bug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/1524526 [09:36] cpaelzer: go ahead. Thank you! [09:40] pitti, thanks for copying the verified SRUs over! [09:40] no worries! [09:46] 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] 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] rbasak: any luck with the env to import? [11:02] Still on it, sorry. [11:02] * rbasak is installing usd-import dependencies [11:03] rbasak: not a problem, just needed to check [11:03] I'm prepping myself by parsing through debdiffs - so I'm ready to go then [11:03] already found a "changelof only" change :-) [11:27] chiluk: did you see ted's comment in bug 1592862? could you re-check and see if we can just sync it now? [11:27] bug 1592862 in e2fsprogs (Ubuntu) "Merge e2fsprogs from Debian 1.43.1-1" [Wishlist,New] https://launchpad.net/bugs/1592862 [11:59] 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] 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] cpaelzer: OK. The import's been going for a while. Now up to Natty. [12:21] cpaelzer: dovecot import pushed [12:21] nacc: ^^ [12:21] Hope I did it right! === sil2100_ is now known as sil2100 [13:16] rbasak: thanks a lot for th eimport [13:22] seb128: it's magically all cleared [13:22] let's see if it more magically gets copied now [13:22] Laney, \o/ === inaddy is now known as tinoco [13:35] 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] 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] 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] 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] rbasak: thanks [13:45] 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] cpaelzer: it's very similar. I think "deconstruct" and the need for "usd-merge reconstruct" first are the only major changes. === smoser` is now known as smoser [14:05] mdeslaur: will do.. [14:24] Laney: FYI, in case you check: I disabled the autopkgtest workers on cyclops (armhf Calxeda nodes) on purpose [14:25] Laney: there are now three lxd-armhf[123] arm64 instances on bos01 driven by the autopkgtest-lxd-worker/0 service [14:25] 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:25] bug 1531768 in Auto Package Testing "[arm64] lockups some time after booting" [Medium,Triaged] https://launchpad.net/bugs/1531768 [14:29] pitti: okay --- your last post in the bug doesn't sound good though [14:30] will you bring up arm64 workers if this is good now? [14:30] 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] Laney: arm64> this works in principle (I tested it last week) [14:31] Laney: however, we don't have enough capacity ATM [14:31] Laney: and I filed an RT about reboot being broken on arm64 [14:31] that's kind of a hard blocker [14:32] 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] heh [14:33] Laney: but I also want to collect some experience wiht the new lxd runners in general [14:33] surprised nobody else has pressured for reboot to be fixed [14:33] Laney: e. g. this morning I noticed that internet access through proxy was broken (fixed now) [14:33] and there might be some tests that behave differently under lxd than under lxc [14:34] 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] 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] Laney: I just put it onto a new service as autopkgtest-cloud-worker is already fairly loaded with 60 parallel tests === zul_ is now known as zul [14:43] pitti: I think I saw this before [14:43] how are the SS instances themselves managed? [14:43] cloud-worker starts X and then each one can have Y containers? [14:44] 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] Laney: and then adding their IP and number of parallel LXD containers to credentials/lxd-remotes.conf on wendigo [14:45] Laney: and then juju set autopkgtest-lxd-worker lxd-remotes="$(cat credentials/lxd-remotes.conf)" [14:45] * Laney blinks [14:45] Laney: this tells the autopkgtest/lxd-worker instance about the new lxd remote, and it'll start running workers on it [14:46] Laney: (deploy.sh uses this file automatically) [14:46] Laney: I'll wikify all this soon, once it proves itself in production [14:46] and I'm sure we can automate this some more [14:47] Laney: blinks> what's unclear? happy to explain (I don't like bus factor == 1..) === jynik_ is now known as jynik [14:48] 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] wiki will help [14:49] Laney: yeah, the userdata file is a horrible collection of bug workarounds and lots of black magic to create a btrfs partition [14:49] Laney: we don't have cinder on scalingstack, so no volume-create and friends [15:13] dpkg: error processing archive /var/cache/apt/archives/snap-confine_1.0.30_amd64.deb (--unpack): [15:13] 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] wow [15:13] LocutusOfBorg: told mvo this morning, the Breaks/Replaces: has the wrong version [15:13] thanks [15:14] from time to time I upgrade my yakkety machine :) [15:14] LocutusOfBorg: err, you have -proposed enabled? [15:14] yes [15:14] *shrug*, you get to keep both halves [15:14] seriously, never EVAR do this [15:14] pitti, virtual machine [15:15] I'm not *that* crazy [15:15] :) [15:15] hehehe [15:15] thanks, another reminder to fix this silly bug [15:15] sorry for the dup :) [15:18] no worries [15:29] arges, mind rejecting my dh-python upload to wily? it has some cruft in it. [15:29] coreycb: done [15:29] arges: ^ [15:29] pitti, thanks [15:35] 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] rbasak: ack, thanks! [15:48] can someone re-trigger the autopkgtests for phpseclib -> php-horde-mapi (new version has landed in yakkety) [15:49] nacc: doing [15:50] pitti: thanks! [15:50] pitti: i think almost all of php has cleared out of excuses now :) [16:02] nacc: yeah thanks for the extra explanations [16:02] nacc: worked fine after I adde the two new stages [16:03] nacc: I'm just starting to build my newly merged package [16:05] cpaelzer: great! sorry for that confusion [16:07] nacc: you are totally innocent for me starting as I did before instead of re-reading the new doc :-) [16:07] s/innocent/unblamable/ [16:08] cpaelzer: i hope that's mentioned on the new doc, and if not, i'll go fix that now :) [16:08] nacc: it is there, working fine [16:08] cpaelzer: ok, good :) [16:08] nacc: what is missing thou and I wanted to discuss that - is that if just following the doc you get missing references [16:09] nacc: after the clone at the step of usd-merge tag [16:09] nacc: as soon as you check out or at least fetch those you are good and usd-merge wrks fine [16:09] cpaelzer: ah, that's true, there is aw orkaround [16:09] let's say you named your remote usdi [16:09] nacc: something for that would be nice to be added to the doc [16:10] then you can do `usd-merge tag usdi/ubuntu/yakkety usdi/debian/sid` [16:10] and it will dtrt [16:10] 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] 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] cpaelzer: yep, fixing now [16:13] nacc: also I tihnk section 7 mght be incomplete subject is "Tag, push and review.", but there is no tagging involved :-) [16:14] 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] nacc: maybe just new/ubuntu ? [16:17] 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] cpaelzer: yep, that's the discussion rbasak and i are still going through [16:18] cpaelzer: but from a MR perspective, that's ok [16:18] cpaelzer: just don't tag (just checkout -b merge or whatever) and push your branch [16:18] Which tag are you talking about? [16:18] reviewer reviews the branch, and if uploader, they'll tag [16:18] rbasak: i think the 'proposed' new version [16:18] rbasak: as a result of the merge [16:18] proposed strictly from the submitter's perspective, not the archive [16:19] ATM that appears as the MP's proposed branch, right? So no need to tag, but do need a branch name. [16:19] In the past, we didn't technically need a branch. [16:19] nacc: I'm fine with a brnach only, just drop the "tag" from the subject in section 7 [16:20] Though "new/ubuntu" is handy. [16:20] But that'll move upon addressing review comments, so maybe we should stop using it and focus on a branch tip instead. [16:20] 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] 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] cpaelzer: updated, take a look? [16:22] cpaelzer: yep, i forgot to include the tags to push as well, you're right, fixed now [16:23] nacc: a bit wide, but yeah good now [16:24] cpaelzer: yeah, i'll figure that out :) [16:25] nacc: not to say that 99% of screens on the world would have enough screen-estate to jsut display it wide :-/ [16:26] cpaelzer: now it's a little scrolly box :) [16:28] nacc: it losts its index as #2 by that [16:28] nacc: I'd vote for \ and indented follow up line [16:31] cpaelzer: check now? [16:31] 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] nacc: but feel free to just keep it as-is - it is good [16:36] 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:36] Launchpad bug 1584118 in openjdk-9 (Ubuntu) "16.04 incorrectly installs openjdk-9 to satisfy java8-runtime dependency" [Undecided,Confirmed] https://launchpad.net/bugs/1584118 [16:42] cpaelzer: it is a wiki :-P [16:42] cpaelzer: i don't know why the wiki formats that way, but it's not something i'm specifying, fwiw [19:00] cyphermox, BenC, rbasak: hey guys! I won't be able to make it for todays meeting sadly === jtaylor_ is now known as jtaylor [21:40] slangasek: could you take a look at LP: #1592890? it will clear out two more excuses entries (php7cc and php-pimple itself) [21:40] Launchpad bug 1592890 in php-pimple (Ubuntu) "Fix autopkgtest failure for php-pimple" [Undecided,New] https://launchpad.net/bugs/1592890 [21:40] 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] 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] jbicha: thanks for the advice and pointers on the zend{,-}framework stuff! [22:46] 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] 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? === mcasadevall is now known as NCommander === NCommander is now known as mcasadevall === mcasadevall is now known as NCommander [23:12] nacc: it was failing it's autopkgtest [23:12] nacc: feel free to drop it if the autopkg test now works without it [23:30] 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] 2.2 is fine [23:31] jbicha: ack, thanks! [23:32] 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] mdeslaur: ok, i'll double-check again and request a sync if it works [23:32] jbicha: ack, that makes sense [23:32] for instance I gave my https://launchpad.net/ubuntu/+source/abiword SRU 3.0.1-6ubuntu0.16.04.1 [23:33] but strictly following the rules I think it should have been 3.0.1-6ubuntu0.1 [23:33] yep, i think i was just clarifying on if those rules applied to non-security updates and then how strictly they were followed :)