/srv/irclogs.ubuntu.com/2016/06/20/#ubuntu-devel.txt

=== NCommander is now known as mcasadevall
=== JanC is now known as Guest35692
=== JanC_ is now known as JanC
pittiGood morning06:09
cpaelzergood morning06:12
pittimvo: good morning!06:16
pittiPreparing to unpack .../snap-confine_1.0.30_ppc64el.deb ...06:16
pittiUnpacking snap-confine (1.0.30) ...06:16
pittidpkg: 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+1ubuntu106:16
pittimvo: ^ known?06:16
pittithis serial-kills workers during dist-upgrade, I'll see to turning that into a proper failure06:16
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.3006:22
mvopitti: uh, thank you! sorry for this, will fix right away07:01
pittiI deployed the autopkgtest fix now, should go from "in progress" to "failed" in the next run07:01
mvota07:03
seb128SRU 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:08
seb128Laney, ^ did you look at those/got pinted about them?09:09
Laneyno09:09
Laneyi retried them09:15
seb128now or before and they failed again?09:17
Laney4 minutes ago09:18
seb128k, let's see if that improves things09:18
Laneybut nobody told me they don't release it because of this09:18
seb128nobody from the SRU team pinged you saying the SRU was on hold because of that?09:18
seb128I'm assuming that's why they didn't copy over but I'm not sure09:18
pittipresumably that, yes; i. e. needs confirmation that the regressions are unrelated and just because of flakiness; some of them might need overides in xenial09:19
rbasaknacc: I already sent it in Debian bug 82507909:33
ubottuDebian bug 825079 in icinga2-ido-mysql "Package links against libmysqlclient_r" [Normal,Open] http://bugs.debian.org/82507909:33
cpaelzerRAOF: 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 discussed09:35
ubottubug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/152452609:35
rbasakcpaelzer: go ahead. Thank you!09:36
seb128pitti, thanks for copying the verified SRUs over!09:40
pittino worries!09:40
cpaelzerrbasak: 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?09:46
rbasakcpaelzer: 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.10:06
cpaelzerrbasak: any luck with the env to import?11:02
rbasakStill on it, sorry.11:02
* rbasak is installing usd-import dependencies11:02
cpaelzerrbasak: not a problem, just needed to check11:03
cpaelzerI'm prepping myself by parsing through debdiffs - so I'm ready to go then11:03
cpaelzeralready found a "changelof only" change :-)11:03
mdeslaurchiluk: did you see ted's comment in bug 1592862? could you re-check and see if we can just sync it now?11:27
ubottubug 1592862 in e2fsprogs (Ubuntu) "Merge e2fsprogs from Debian 1.43.1-1" [Wishlist,New] https://launchpad.net/bugs/159286211:27
cpaelzerrbasak: 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 more11:59
cpaelzerrbasak: 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 day12:00
rbasakcpaelzer: OK. The import's been going for a while. Now up to Natty.12:00
rbasakcpaelzer: dovecot import pushed12:21
rbasaknacc: ^^12:21
rbasakHope I did it right!12:21
=== sil2100_ is now known as sil2100
cpaelzerrbasak: thanks a lot for th eimport13:16
Laneyseb128: it's magically all cleared13:22
Laneylet's see if it more magically gets copied now13:22
seb128Laney, \o/13:22
=== inaddy is now known as tinoco
cpaelzerrbasak: 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 fail13:35
cpaelzerrbasak: maybe the history is broken (or other than I expect) - maybe one of the few algo rewrites is not yet in my mental process13:35
cpaelzerrbasak: 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 -i13:37
rbasakcpaelzer: 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:39
cpaelzerrbasak: thanks13:44
cpaelzerrbasak: 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 tracks13:45
rbasakcpaelzer: it's very similar. I think "deconstruct" and the need for "usd-merge reconstruct" first are the only major changes.13:46
=== smoser` is now known as smoser
chilukmdeslaur: will do..14:05
pittiLaney: FYI, in case you check: I disabled the autopkgtest workers on cyclops (armhf Calxeda nodes) on purpose14:24
pittiLaney: there are now three lxd-armhf[123] arm64 instances on bos01 driven by the autopkgtest-lxd-worker/0 service14:25
pittiLaney: 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 up14:25
ubottubug 1531768 in Auto Package Testing "[arm64] lockups some time after booting" [Medium,Triaged] https://launchpad.net/bugs/153176814:25
Laneypitti: okay --- your last post in the bug doesn't sound good though14:29
Laneywill you bring up arm64 workers if this is good now?14:30
pittiLaney: 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 place14:30
pittiLaney: arm64> this works in principle (I tested it last week)14:31
pittiLaney: however, we don't have enough capacity ATM14:31
pittiLaney: and I filed an RT about reboot being broken on arm6414:31
pittithat's kind of a hard blocker14:31
pittiwell, I commited some workaround to autopkgtest to do "nova reboot --hard" after 5 minutes timeout, but this is both ugly and also utterly slow14:32
Laneyheh14:32
pittiLaney: but I also want to collect some experience wiht the new lxd runners in general14:33
Laneysurprised nobody else has pressured for reboot to be fixed14:33
pittiLaney: e. g. this morning I noticed that internet access through proxy was broken (fixed now)14:33
pittiand there might be some tests that behave differently under lxd than under lxc14:33
pittiif that works, I'll ask for opening the firewall between PS and the two s390x nodes, and convert them to the new lxd structure14:34
pittiLaney: 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 nova14:35
pittiLaney: I just put it onto a new service as autopkgtest-cloud-worker is already fairly loaded with 60 parallel tests14:36
=== zul_ is now known as zul
Laneypitti: I think I saw this before14:43
Laneyhow are the SS instances themselves managed?14:43
Laneycloud-worker starts X and then each one can have Y containers?14:43
pittiLaney: 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.userdata14:44
pittiLaney: and then adding their IP and number of parallel LXD containers to credentials/lxd-remotes.conf on wendigo14:45
pittiLaney: and then juju set autopkgtest-lxd-worker lxd-remotes="$(cat credentials/lxd-remotes.conf)"14:45
* Laney blinks14:45
pittiLaney: this tells the autopkgtest/lxd-worker instance about the new lxd remote, and it'll start running workers on it14:45
pittiLaney: (deploy.sh uses this file automatically)14:46
pittiLaney: I'll wikify all this soon, once it proves itself in production14:46
pittiand I'm sure we can automate this some more14:46
pittiLaney: blinks> what's unclear? happy to explain (I don't like bus factor == 1..)14:47
=== jynik_ is now known as jynik
Laneypitti: 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
Laneywiki will help14:48
pittiLaney: yeah, the userdata file is a horrible collection of bug workarounds and lots of black magic to create a btrfs partition14:49
pittiLaney: we don't have cinder on scalingstack, so no volume-create and friends14:49
LocutusOfBorgdpkg: 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+115:13
LocutusOfBorgwow15:13
pittiLocutusOfBorg: told mvo this morning, the Breaks/Replaces: has the wrong version15:13
LocutusOfBorgthanks15:13
LocutusOfBorgfrom time to time I upgrade my yakkety machine :)15:14
pittiLocutusOfBorg: err, you have -proposed enabled?15:14
LocutusOfBorgyes15:14
pitti*shrug*, you get to keep both halves15:14
pittiseriously, never EVAR do this15:14
LocutusOfBorgpitti, virtual machine15:14
LocutusOfBorgI'm not *that* crazy15:15
LocutusOfBorg:)15:15
mvohehehe15:15
mvothanks, another reminder to fix this silly bug15:15
LocutusOfBorgsorry for the dup :)15:15
mvono worries15:18
coreycbarges, mind rejecting my dh-python upload to wily?  it has some cruft in it.15:29
pitticoreycb: done15:29
pittiarges: ^15:29
coreycbpitti, thanks15:29
nacccpaelzer: 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
naccrbasak: ack, thanks!15:35
nacccan someone re-trigger the autopkgtests for phpseclib -> php-horde-mapi (new version has landed in yakkety)15:48
pittinacc: doing15:49
naccpitti: thanks!15:50
naccpitti: i think almost all of php has cleared out of excuses now :)15:50
cpaelzernacc: yeah thanks for the extra explanations16:02
cpaelzernacc: worked fine after I adde the two new stages16:02
cpaelzernacc: I'm just starting to build my newly merged package16:03
nacccpaelzer: great! sorry for that confusion16:05
cpaelzernacc: you are totally innocent for me starting as I did before instead of re-reading the new doc :-)16:07
cpaelzers/innocent/unblamable/16:07
nacccpaelzer: i hope that's mentioned on the new doc, and if not, i'll go fix that now :)16:08
cpaelzernacc: it is there, working fine16:08
nacccpaelzer: ok, good :)16:08
cpaelzernacc: what is missing thou and I wanted to discuss that - is that if just following the doc you get missing references16:08
cpaelzernacc: after the clone at the step of usd-merge tag16:09
cpaelzernacc: as soon as you check out or at least fetch those you are good and usd-merge wrks fine16:09
nacccpaelzer: ah, that's true, there is aw orkaround16:09
nacclet's say you named your remote usdi16:09
cpaelzernacc: something for that would be nice to be added to the doc16:09
naccthen you can do `usd-merge tag usdi/ubuntu/yakkety usdi/debian/sid`16:10
naccand it will dtrt16:10
naccbut yes, i'll clarify that! i wrote it from the persepctive of i have the imported trees locally that i'm pushing :)16:10
cpaelzernacc: 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 nice16:10
nacccpaelzer: yep, fixing now16:11
cpaelzernacc: also I tihnk section 7 mght be incomplete subject is "Tag, push and review.", but there is no tagging involved :-)16:13
cpaelzernacc: 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 way16:14
cpaelzernacc: maybe just new/ubuntu ?16:17
cpaelzeruntil we know it is accepted and uploaded we can't really give it a version tag - that was the discussion back then16:17
nacccpaelzer: yep, that's the discussion rbasak and i are still going through16:17
nacccpaelzer: but from a MR perspective, that's ok16:18
nacccpaelzer: just don't tag (just checkout -b merge or whatever) and push your branch16:18
rbasakWhich tag are you talking about?16:18
naccreviewer reviews the branch, and if uploader, they'll tag16:18
naccrbasak: i think the 'proposed' new version16:18
naccrbasak: as a result of the merge16:18
naccproposed strictly from the submitter's perspective, not the archive16:18
rbasakATM that appears as the MP's proposed branch, right? So no need to tag, but do need a branch name.16:19
rbasakIn the past, we didn't technically need a branch.16:19
cpaelzernacc: I'm fine with a brnach only, just drop the "tag" from the subject in section 716:19
rbasakThough "new/ubuntu" is handy.16:20
rbasakBut that'll move upon addressing review comments, so maybe we should stop using it and focus on a branch tip instead.16:20
cpaelzernacc: 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:20
cpaelzerno 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 tags16:22
nacccpaelzer: updated, take a look?16:22
nacccpaelzer: yep, i forgot to include the tags to push as well, you're right, fixed now16:22
cpaelzernacc: a bit wide, but yeah good now16:23
nacccpaelzer: yeah, i'll figure that out :)16:24
cpaelzernacc: not to say that 99% of screens on the world would have enough screen-estate to jsut display it wide :-/16:25
nacccpaelzer: now it's a little scrolly box :)16:26
cpaelzernacc: it losts its index as #2 by that16:28
cpaelzernacc: I'd vote for \ and indented follow up line16:28
nacccpaelzer: check now?16:31
cpaelzernacc: 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 huge16:31
cpaelzernacc: but feel free to just keep it as-is - it  is good16:32
naccdoko: 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
ubottuLaunchpad bug 1584118 in openjdk-9 (Ubuntu) "16.04 incorrectly installs openjdk-9 to satisfy java8-runtime dependency" [Undecided,Confirmed] https://launchpad.net/bugs/158411816:36
nacccpaelzer: it is a wiki :-P16:42
nacccpaelzer: i don't know why the wiki formats that way, but it's not something i'm specifying, fwiw16:42
sil2100cyphermox, BenC, rbasak: hey guys! I won't be able to make it for todays meeting sadly19:00
=== jtaylor_ is now known as jtaylor
naccslangasek: could you take a look at LP: #1592890? it will clear out two more excuses entries (php7cc and php-pimple itself)21:40
ubottuLaunchpad bug 1592890 in php-pimple (Ubuntu) "Fix autopkgtest failure for php-pimple" [Undecided,New] https://launchpad.net/bugs/159289021:40
naccslangasek: i've already sent the same patch to Debian, if you want to just wait for that to get accepted and sync21:40
naccmdeslaur: 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?21:48
naccjbicha: thanks for the advice and pointers on the zend{,-}framework stuff!22:06
nacclet'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
naccI guess not the latter, only in case there was a 7.0.4-7ubuntu3 published in the development release that it might conflict with?22:46
=== mcasadevall is now known as NCommander
=== NCommander is now known as mcasadevall
=== mcasadevall is now known as NCommander
mdeslaurnacc: it was failing it's autopkgtest23:12
mdeslaurnacc: feel free to drop it if the autopkg test now works without it23:12
jbichanacc: using the version numbering recommended on https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation is a good standard regardless of whether the sru is "security" or not23:30
jbicha2.2 is fine23:30
naccjbicha: ack, thanks!23:31
jbichaI think there's a little bit of flexibility as long as the number is less than it could be in a future release23:32
naccmdeslaur: ok, i'll double-check again and request a sync if it works23:32
naccjbicha: ack, that makes sense23:32
jbichafor instance I gave my https://launchpad.net/ubuntu/+source/abiword SRU 3.0.1-6ubuntu0.16.04.123:32
jbichabut strictly following the rules I think it should have been 3.0.1-6ubuntu0.123:33
naccyep, i think i was just clarifying on if those rules applied to non-security updates and then how strictly they were followed :)23:33

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!