[00:50] <slangasek> powersj, smoser: I think I would like to require that, in cases where curtin's behavior is changing backwards-incompatibly, that the SRU template explicitly explain how the effects will be mitigated (e.g., appropriate versioned Breaks: ?).  Does that sound reasonable here?
[00:51] <slangasek> powersj, smoser: also it's not clear to me that "vmtest" encompasses end-to-end testing through MAAS; is that part of the test plan?  (Also, going forward: subiquity?)
[01:09] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (yakkety-proposed) [10.2.6-0ubuntu0.16.10.1]
[01:11] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (xenial-proposed) [10.2.6-0ubuntu0.16.04.1]
[02:18] <smoser> slangasek, vmtest does not include tests driven by maas.
[02:18] <smoser> curtin's interaction with maas is limited to essentially 2 things
[02:18] <smoser> a.) maas sending config
[02:19] <smoser> b.) that config including config that defines "reporting" that should be done (http posts of events... description timestamp..)
[02:20] <smoser> for 'a', we feed plenty of config to curtin almost identically to how maas does it (using curtin's "pack")
[02:20] <smoser> for 'b', we actually do have a http process that listens and we post messages to it and it records them.
[02:20] <smoser> the shortcoming in 'b' is we do not do oauth there.
[02:21] <slangasek> smoser: "almost identically to how maas does it" - but if the specific configs change, there's no integration test to ensure that what maas sends is still handled correctly by curtin?
[02:21] <slangasek> that's the bit that I'm concerned about and would like to understand how we guard against it
[02:21] <smoser> well, we send dozens of configs
[02:22] <slangasek> "we" being in the curtin test suite?
[02:22] <smoser> and we do test forward and backward compatibility.
[02:22] <smoser> ie, there are 2 ways that you can declare apt configuration, and we do test them both.
[02:22] <smoser> curtin test suite, yes.
[02:22] <slangasek> right
[02:22] <nacc> smoser: does the 'almost identically' refer to the configs themselves or the method of sending the config?
[02:22] <smoser> method.
[02:22] <slangasek> so if it's in the curtin test suite, I don't see anything that, structurally, guards against skew between curtin and maas
[02:23] <nacc> smoser: ok, that's what i thought -- which might allay slangasek
[02:23] <slangasek> well, but I understand the specific configs being tested are in the curtin test suite
[02:23] <slangasek> not provided by maas
[02:23] <smoser> not specifically. however, as input formats change/adapt, we're not adjusting old configs but rather adding new ones.
[02:24] <slangasek> so they checkpoint a single point in time, when someone created those tests on the curtin side, of what they believed maas would be sending
[02:24] <nacc> slangasek: right, so it would be 'better' if we also kept a cache of those checkpointed configs in the test suite :)
[02:25] <nacc> slangasek: *or* used the configs from the old curtin testsuite somehow
[02:25] <smoser> well we essentially *do* use configs from the old curtin testsuite.
[02:25] <smoser> by... not removing existing tests.
[02:25] <nacc> smoser: right and do we not change any existing tests?
[02:25] <nacc> smoser: or any existing configs, i guess, more importantly
[02:26] <slangasek> nacc: not sure I understand what you mean; I'm arguing that having the testsuite owned by curtin, and not live testing (w/ version matrix) of maas, means the integration testing is incomplete and possibly subject to drift
[02:26] <smoser> in general, we add new things we don't remove old things.
[02:26] <slangasek> drift between maas and curtin
[02:26] <smoser> slangasek, you're correct.
[02:26] <nacc> smoser: but that means you might mean you miss a case where you are now dependent on a new thing and the case where that isn't passed is no longer verified to work (and would be used by old maas)?
[02:26] <nacc> slangasek: right, i follow what you mean
[02:27] <slangasek> if the process is 1) look at what maas sends 2) add it to curtin test suite 3) make sure test suite doesn't regress, then this misses 2.5) maas changes what it sends, 2.6) curtin changes how it interprets thing maas sent
[02:27] <smoser> i'm arguing that we're doing a better job of config/api testing than most existing ubuntu products, including those with a micro release exception.
[02:27] <smoser> i'm not arguing that it is perfect.
[02:27] <smoser> for example.... firefox doesn't test all possible addons
[02:27] <smoser> (and in fact breaks them)
[02:27] <slangasek> firefox does not have a micro release exception
[02:27] <slangasek> firefox has an "I can't even" exception
[02:27] <smoser> ?
[02:28] <nacc> and also curtin's primary consumer is maas, aiui -- so it seems like verifying cross-compatibility in the SRU is rather important
[02:28] <smoser> maas does test with -proposed
[02:28] <smoser> i believe that is written in the documentation
[02:28] <smoser> and they can and do test with our daily ppas
[02:28] <smoser> which contain stuff as it would go into -proposed before it does
[02:29] <slangasek> smoser: there is no mention of maas testing in https://wiki.ubuntu.com/CurtinUpdates
[02:29] <slangasek> if what you're saying is that the maas autopkgtests will ensure compatibility doesn't break, great - then please document that in the exception
[02:30] <smoser> slangasek, ok. we can get a statement to that affect.
[02:30] <slangasek> if what you're saying is that maas tests with -proposed /outside/ of autopkgtests, and will somehow signal to stop the SRU if it breaks, then /definitely/ document that in the exception :-)
[02:30] <slangasek> smoser: sounds good, thanks :)
[02:30] <smoser> no. maas autopackage tests do not exist to my knowledge
[02:31] <smoser> maas has c-i that runs with different curtins
[02:31] <slangasek> right; if it's not done via autopkgtest, the SRU process has no built-in way to stop the line and so it should be called out as part of the test plan
[02:34] <smoser> fair.
[02:34] <smoser> slangasek, what would you suggest to get the coverage you are after?
[02:37] <smoser> i have to run, slangasek thank you for your time. you can leave comments here , or email or anywhere and i'll get to them tomorrow. powersj will see them here too it looks like.
[02:38] <powersj> I will :)
[02:41] <nacc> i think the best thing to do would be to document the matrix that is tested, both via autopkgtest and manually by the MAAS team
[02:50] -queuebot:#ubuntu-release- New source: peony (zesty-proposed/primary) [1.0.0-0ubuntu3]
[03:21] <dx> hi, out of curiosity, if i wanted to upload a new upstream version of a thing to zesty, would that be as hard as it is to upload things to debian stretch?
[03:25] <dx> nevermind found the wiki pages answering it, sorta. i'm under the impression that it's slightly softer than debian's freeze
[03:29] <dx> so what are the chances of pidgin 2.12.0 in? https://bitbucket.org/pidgin/www/src/tip/htdocs/ChangeLog - it's mostly removal of broken protocols and some rather important bugfixes
[03:30] <dx> ...ignoring the fact that the debian maintainer is half-afk and probably not going to package it any time soon
[03:33] <jbicha> dx: I'm not on the Release Team, but those changes look fine to me; bugfix updates are still welcome for zesty
[03:40] <Ukikie> Heh, I was just looking at that too.
[04:04] <dx> Ukikie: that's a really nice combination of words to hear from you! (also, how often do you change nicks?)
[04:07] <dx> oh another unrelated but release-relevant thing: zesty has mosh 1.3.0~rc2-1, a release candidate that was migrated from debian unstable accidentally
[04:09] <dx> release candidate 3 was released since then (a month after rc2). don't know about any ETAs for a final release
[04:50] <jbicha> dx: did you see https://lists.debian.org/debian-devel-changes/2017/03/msg00481.html
[04:50] <dx> WHOA
[04:51] <dx> amazing
[04:55] <slangasek> smoser, powersj: at least for starters I'd like documentation of what maas testing will be done against the curtin in -proposed, and for this to be included in the test plan so that we don't accidentally release any SRUs without verifying the results of those tests
[04:56] <powersj> jgrimm: ^
[05:06] <Ukikie> dx: Hah, I've got no super powers at all, not even MOTU.  And not that often, only around christmas (You'll note I'm not in #irssi with the normal nick, it'll be back.) :)
[05:08] <dx> Ukikie: ...i'm not sure i get what you mean. but, uh, don't we need someone to upload to zesty-proposed and they ask very politely for a freeze exception?
[05:09] <dx> s/and they/and then/
[06:41] <cpaelzer> Hi, we worked with IBM on a few dpdk fixes for ppc64el. Pushing them to zesty-proposed would be really great for dpdk on ppc64el.
[06:41] <cpaelzer> But then it is late enough to be at least discussion worthy, therefore I made them an FFE
[06:41] <cpaelzer> IBM completed extra tests on ppc64el, as well as myself doing various tests on x86
[06:42] <cpaelzer> Also all patches are now upstream
[06:42] <cpaelzer> before pushing I wanted to ask if one of the release Team could read into bug 1670686 and bug 1670689 and consider acking it as FFE
[06:42] <ubot5> Error: Could not gather data from Launchpad for bug #1670686 (https://launchpad.net/bugs/1670686). The error has been logged
[06:42] <ubot5> Error: Could not gather data from Launchpad for bug #1670689 (https://launchpad.net/bugs/1670689). The error has been logged
[06:52] <apw> cpaelzer, presumably there is little regression potential for applying those given the packages do not exist (if i am reading the bugs right) for ppc64el currently and the code is arch specific?
[07:20]  * apw notes there was some clarification discussion offline
[07:21] <apw> cpaelzer, those looks good to me, simple self contained very low risk.  approved.  details in the bug
[07:21] <cpaelzer> thanks apw
[08:40] <LocutusOfBorg> dx, it is on my way (pidgin)
[08:41] <LocutusOfBorg> I'm the usual merger of the package, you can just talk to me directly
[08:41] <LocutusOfBorg> (I discovered this conversazion just by luck, when reading irclogs trying to find mentions of the spam I got tonight, wrt zesty-proposed packages)
[08:49] <ginggs> LocutusOfBorg: it's not all spam ;) you can't upload and forget, you need to help your packages migrate
[08:52] <Ukikie> LocutusOfBorg: If you're itching for updates, http://dev.deluge-torrent.org/wiki/ReleaseNotes/1.3.14 looked somewhat important.
[08:54] <LocutusOfBorg> ginggs, receiving 10 times a mail "hey systemd didn't migrate" is spam 9 times, and good 1
[08:54] <LocutusOfBorg> specially when you get all of them in ~3 h
[08:54] <LocutusOfBorg> I got ~100 emails tonight
[08:54] <LocutusOfBorg> and 14 in the last few minutes
[08:54] <ginggs> LocutusOfBorg: how many different packages?
[08:55] <LocutusOfBorg> around 20 I would wild guess
[08:55] <LocutusOfBorg> wrt systemd:
[08:56] <LocutusOfBorg> yesterday at 7.23 9.51 today at 4.31 6.36 6.36 8.57
[08:56] <ginggs> LocutusOfBorg: I think you are the winner!
[08:56] <LocutusOfBorg> 6 mails in 10 hours?
[08:57] <ginggs> 20 stuck packages :)
[08:57] <LocutusOfBorg> Ukikie, prod the debian maintainer, and I'll be happy to merge it :p
[08:59] <caribou> Hi, the clamav sync is stucked in -proposed on the MIR for tomsfastmath. MIR is apparently completed so is there anything else to be done to get this sync finalized ?
[09:00] <LocutusOfBorg> and ginggs lots of them are stuck because of -ocaml broken packages (demoted) -haskell broken packages (demoted) and imagemagick stuck transition due to emacs25
[09:00] <LocutusOfBorg> that emacs25/arm64 needs some care, but I don't know how to solve
[09:10] <LocutusOfBorg> oh activity on LP: #1656474
[09:10] <ubot5> Launchpad bug 1656474 in emacs25 (Ubuntu) "FTBFS on arm64: make[4]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Segmentation fault (core dumped)" [High,Confirmed] https://launchpad.net/bugs/1656474
[09:16] <Laney> haha
[09:20] <LocutusOfBorg> nacc, merge imagemagick?
[11:08] -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (yakkety-proposed) [1.13.4-3ubuntu0.2]
[11:09] -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.3]
[11:12] <Laney> apw: thinking about copying that glib2.0 from the other day into z-proposed, any objections?
[11:12] <Laney> only asking you because I think you eyeballed it slightly
[11:12] <apw> Laney, i don't recall being upset about it at the time
[11:13] <Laney> it switches from static -dbg to ddebs, but I think that's ok
[11:14] <Laney> well, Friday morning, what could possibly go wrong? :-)
[11:18] <Laney> . o O ( zesty/debug debug/main main/debug, aha!)
[11:19] <apw> there is no possibilty of confusion there
[11:19]  * Laney just tried them until they worked
[11:19] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-42.45~16.04.1] (no packageset)
[11:20] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-42.45~16.04.1]
[11:20] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-67.88~14.04.1] (kernel)
[11:28] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-67.88~14.04.1]
[12:37] <mdeslaur> could someone please push gnutls28 and pcsc-lite out of proposed, please? The failing tests are unrelated.
[13:22] <jackyu> hi
[13:25] <apw> mdeslaur, looking ...
[13:26] <mdeslaur> apw: Laney retried it with --all-proposed
[13:26] <mdeslaur> apw: but pushing them through would be nice
[13:26] <apw> mdeslaur, as in those are ongoing runs ?
[13:27] <mdeslaur> he just retried them, so I guess yes
[13:27] <apw> mdeslaur, ack thanks ...
[13:27] -queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-113.160~precise1] (kernel)
[13:28] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-113.160~precise1]
[13:38] <handsome_feng> Hi, apw, seb128, can you help to approve the UKUI packages? bug:1663477, bug:1664229, bug:1664232, bug:1664235, bug:1664244, bug:1664247, bug:1664256, or one of them first? Thank you in advance!
[13:39] <handsome_feng> bug:#1663477, bug:#1664229, bug:#1664232, bug:#1664235, bug:#1664244, bug:#1664247, bug:#1664256
[13:40] <handsome_feng> sorry, bug: #1663477, bug: #1664229, bug: #1664232, bug: #1664235, bug: #1664244, bug: #1664247, bug: #1664256
[13:40] <ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
[13:40] <ubot5> bug 1664229 in Ubuntu "[FFe] ukui-menu" [Wishlist,In progress] https://launchpad.net/bugs/1664229
[13:40] <ubot5> bug 1664232 in Ubuntu Kylin "[FFe] ukui-indicators" [Critical,Fix committed] https://launchpad.net/bugs/1664232
[13:40] <ubot5> bug 1664235 in Ubuntu "[FFe] peony" [Wishlist,In progress] https://launchpad.net/bugs/1664235
[13:40] <ubot5> bug 1664244 in Ubuntu "[FFe] ukui-control-center" [Wishlist,In progress] https://launchpad.net/bugs/1664244
[13:43] <jackyu> There are seven packages need to be approved:)
[16:36] -queuebot:#ubuntu-release- Unapproved: network-manager-applet (xenial-proposed/main) [1.2.6-0ubuntu0.16.04.2 => 1.2.6-0ubuntu0.16.04.3~jdstrand1] (kubuntu, ubuntu-desktop)
[16:48] -queuebot:#ubuntu-release- Unapproved: rejected network-manager-applet [source] (xenial-proposed) [1.2.6-0ubuntu0.16.04.3~jdstrand1]
[18:21] <nacc> well, LocutusOfBorg is already offline, but imagemagick does not need a merge
[18:21] <nacc> teh version in z-p is good
[18:21] <nacc> but the emacs25 that is in z-p is needed to migrate with it
[18:22] <nacc> as there is a packaging transition
[18:25] <nacc> slangasek: --^ i really have no idea how to fix the arm64 build failure of emacs25 in z-p
[18:25] <nacc> jbicha: --^ it's your upload, but afaict, it shouldn't have broken the arm64 build on its own, right?
[18:26] <jbicha> yes, emacs25 and emacs24 has been broken for a while in zesty
[18:26] <jbicha> I hope I don't get blamed for it!
[18:26] <nacc> emacs24 seems fine?
[18:27] <nacc> well, i mean they are all hung up on each other
[18:27] <nacc> but emacs25 does not build on arm64 "all of a sudden"
[18:27] <nacc> so the big ratking is stuck :/
[18:27] <jbicha> oh, just emacs25
[18:28] <nacc> i just checked the build-logs and the updated emacs25 in z-p (which ahppened to build against the newer imagemagick) will migrate imagemagick too
[18:28] <jbicha> nacc: I think LocutusOfBorg was referring to all the CVEs at https://tracker.debian.org/media/packages/i/imagemagick/changelog-8%3A6.9.7.4%2Bdfsg-2
[18:29] <jbicha> since the zesty-proposed version is 6.9.7.0+dfsg-2
[18:29] <nacc> jbicha: ah, i could merge but then i'd also probably need to go look at the FFe if needed for the change in upstream
[18:29] <nacc> as i don't trust imagemagick not to change features on their bumps
[18:30] <nacc> "make[4]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Segmentation fault (core dumped)"
[18:31] <jbicha> yes I looked at imagmagick's git repo recently :(
[18:31] <nacc> jbicha: yep, makes your eyes bleed :/
[18:32] <nacc> mdeslaur: would you prefer i update the imagemagick in z-p now? rather than having to do a security update right away
[18:33] <mdeslaur> nacc: oh, that would be great
[18:33] <nacc> mdeslaur: ok, i'll put it on my list; the problem is it'll get stuck in z-p anyways right now on emacs25 afaict. So let me spend some time seeing if i can get that to migrate first
[18:33] <mdeslaur> sure, thanks
[18:33] <nacc> jbicha: hrm, and emacs25 on arm64 built in debian at the same version
[18:35] <nacc> and dannf said that he couldn't reproduce it with upstream source
[18:35] <nacc> dannf: but you reproduce the pkg build failure on the same system?
[18:36] <dannf> nacc: right. and emacs25 can build fine in ubuntu, it's just flaky - and scaling stack seems to really hate it. i think it's triggered by a gc
[18:36] <dannf> nacc: i suspect it could FTBFS in debian too, in the right environment
[18:37] <nacc> dannf: harrumph, super annoying :)
[18:37] <dannf> i'll try that w/ a debian VM and see - we can at least get a debian bug filed if so
[18:38] <nacc> dannf: is it calling flockfile with a NULL pointer?
[18:38] <nacc> dannf: just trying to parse the backtrace
[18:38] <nacc> oh that's the sigsegv handler, nm
[19:19] <nacc> slangasek: would be able to review LP: #1671905 -- trying to make the security team's life easier
[19:19] <ubot5> Launchpad bug 1671905 in imagemagick (Ubuntu) "[FFe] Please merge with imagemagick 8:6.9.7.4+dfsg-2 from Debian unstable." [Undecided,In progress] https://launchpad.net/bugs/1671905
[19:22] <nacc> mdeslaur: the bug, for reference --^
[19:23] <nacc> dannf: that would be great (repro in a debian VM), let me know if there's anything i can do to h elp
[19:24] <mdeslaur> nacc: thanks!
[20:23] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-13.15] (core, kernel)
=== zul is now known as zulVacation
[20:51] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-13.15]
[20:55] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-113.160] (core, kernel)
[20:57] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-113.160]
=== santa is now known as Guest84878
[21:34] -queuebot:#ubuntu-release- New source: switcheroo-control (zesty-proposed/primary) [1.1-0ubuntu1]
=== Guest84878 is now known as santa_
[23:02] -queuebot:#ubuntu-release- New: accepted libosl [amd64] (zesty-proposed) [0.8.0-1]
[23:20] <tyhicks> hello - would it be possible for someone to allow the docker.io zesty upload through migration?
[23:21] <tyhicks> it is blocked by an armhf test failure
[23:21] <nacc> tyhicks: is it a bad test on armhf?
[23:21] <tyhicks> it is not a regression and is an expected failure according to xnox's changelog entry here: https://launchpad.net/ubuntu/+source/docker.io/1.12.6-0ubuntu2
[23:21] <nacc> not that i can change the hints, just wondering
[23:22] <tyhicks> nacc: yes, the changelog entry sheds some light on it
[23:22] <nacc> tyhicks: ah ok
[23:22] <nacc> tyhicks: you could possible also subscribe ubuntu-archive to that bug and file a request in there (LP: #1658150)
[23:22] <ubot5> Launchpad bug 1658150 in runc (Ubuntu) "adt test was insufficient to catch failed docker.io on s390x" [High,Confirmed] https://launchpad.net/bugs/1658150
[23:22] <nacc> although it doens't really mention armhf there
[23:23] <nacc> ideally that way the hint (if added) gets a link to that bug or so, which is tied to that upload
[23:23] <nacc> just my opinion, i guess :)
[23:24] <tyhicks> nacc: is it ubuntu-archive members that can add the hints?
[23:24] <nacc> i think it's AAs (members of that team, aiui) -- but I might be wrong
[23:24] <tyhicks> I guess that makes sense but I had never considered what LP team has that power
[23:24] <nacc> tyhicks: --^
[23:24] <tyhicks> ok
[23:26] <tyhicks> comment left
[23:26] <tyhicks> thanks
[23:48] <cjwatson> hints are ~ubuntu-release
[23:49] <nacc> cjwatson: ah ok
[23:49] <nacc> tyhicks: --^ correction, then :)