=== NCommander is now known as mcasadevall | ||
=== JanC is now known as Guest35692 | ||
=== JanC_ is now known as JanC | ||
pitti | Good morning | 06:09 |
---|---|---|
cpaelzer | good morning | 06:12 |
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: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.30 | 06:22 |
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:01 |
mvo | ta | 07:03 |
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:08 |
seb128 | Laney, ^ did you look at those/got pinted about them? | 09:09 |
Laney | no | 09:09 |
Laney | i retried them | 09:15 |
seb128 | now or before and they failed again? | 09:17 |
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:18 |
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:19 |
rbasak | nacc: I already sent it in Debian bug 825079 | 09:33 |
ubottu | Debian bug 825079 in icinga2-ido-mysql "Package links against libmysqlclient_r" [Normal,Open] http://bugs.debian.org/825079 | 09:33 |
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:35 |
ubottu | bug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/1524526 | 09:35 |
rbasak | cpaelzer: go ahead. Thank you! | 09:36 |
seb128 | pitti, thanks for copying the verified SRUs over! | 09:40 |
pitti | no worries! | 09:40 |
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? | 09:46 |
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. | 10:06 |
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:02 | |
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:03 |
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:27 |
ubottu | bug 1592862 in e2fsprogs (Ubuntu) "Merge e2fsprogs from Debian 1.43.1-1" [Wishlist,New] https://launchpad.net/bugs/1592862 | 11:27 |
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 | 11:59 |
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:00 |
rbasak | cpaelzer: dovecot import pushed | 12:21 |
rbasak | nacc: ^^ | 12:21 |
rbasak | Hope I did it right! | 12:21 |
=== sil2100_ is now known as sil2100 | ||
cpaelzer | rbasak: thanks a lot for th eimport | 13:16 |
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:22 |
=== inaddy is now known as tinoco | ||
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:35 |
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:37 |
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:39 |
cpaelzer | rbasak: thanks | 13:44 |
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:45 |
rbasak | cpaelzer: 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 | ||
chiluk | mdeslaur: will do.. | 14:05 |
pitti | Laney: FYI, in case you check: I disabled the autopkgtest workers on cyclops (armhf Calxeda nodes) on purpose | 14:24 |
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:25 |
ubottu | bug 1531768 in Auto Package Testing "[arm64] lockups some time after booting" [Medium,Triaged] https://launchpad.net/bugs/1531768 | 14:25 |
Laney | pitti: okay --- your last post in the bug doesn't sound good though | 14:29 |
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:30 |
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
pitti | Laney: I just put it onto a new service as autopkgtest-cloud-worker is already fairly loaded with 60 parallel tests | 14:36 |
=== zul_ is now known as zul | ||
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:43 |
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:44 |
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:45 |
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:46 |
pitti | Laney: blinks> what's unclear? happy to explain (I don't like bus factor == 1..) | 14:47 |
=== jynik_ is now known as jynik | ||
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:48 |
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 | 14:49 |
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:13 |
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:14 |
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:15 |
mvo | no worries | 15:18 |
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:29 |
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:35 |
nacc | can someone re-trigger the autopkgtests for phpseclib -> php-horde-mapi (new version has landed in yakkety) | 15:48 |
pitti | nacc: doing | 15:49 |
nacc | pitti: thanks! | 15:50 |
nacc | pitti: i think almost all of php has cleared out of excuses now :) | 15:50 |
cpaelzer | nacc: yeah thanks for the extra explanations | 16:02 |
cpaelzer | nacc: worked fine after I adde the two new stages | 16:02 |
cpaelzer | nacc: I'm just starting to build my newly merged package | 16:03 |
nacc | cpaelzer: great! sorry for that confusion | 16:05 |
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:07 |
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:08 |
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:09 |
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:10 |
nacc | cpaelzer: yep, fixing now | 16:11 |
cpaelzer | nacc: also I tihnk section 7 mght be incomplete subject is "Tag, push and review.", but there is no tagging involved :-) | 16:13 |
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:14 |
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:17 |
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:18 |
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:19 |
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:20 |
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:22 |
cpaelzer | nacc: a bit wide, but yeah good now | 16:23 |
nacc | cpaelzer: yeah, i'll figure that out :) | 16:24 |
cpaelzer | nacc: not to say that 99% of screens on the world would have enough screen-estate to jsut display it wide :-/ | 16:25 |
nacc | cpaelzer: now it's a little scrolly box :) | 16:26 |
cpaelzer | nacc: it losts its index as #2 by that | 16:28 |
cpaelzer | nacc: I'd vote for \ and indented follow up line | 16:28 |
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:31 |
cpaelzer | nacc: but feel free to just keep it as-is - it is good | 16:32 |
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:36 |
ubottu | 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:36 |
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 | 16:42 |
sil2100 | cyphermox, BenC, rbasak: hey guys! I won't be able to make it for todays meeting sadly | 19:00 |
=== jtaylor_ is now known as jtaylor | ||
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 |
ubottu | Launchpad bug 1592890 in php-pimple (Ubuntu) "Fix autopkgtest failure for php-pimple" [Undecided,New] https://launchpad.net/bugs/1592890 | 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:40 |
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? | 21:48 |
nacc | jbicha: thanks for the advice and pointers on the zend{,-}framework stuff! | 22:06 |
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? | 22:46 |
=== mcasadevall is now known as NCommander | ||
=== NCommander is now known as mcasadevall | ||
=== mcasadevall is now known as NCommander | ||
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:12 |
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:30 |
nacc | jbicha: ack, thanks! | 23:31 |
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:32 |
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 :) | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!