[00:29] <nacc> mdeslaur: fyi, the corresponding import tree is present in ~usd-import-team, if you need to reproduce refs/tags along the way
=== dobey_ is now known as dobey
[06:40] <cpaelzer> good morning
[07:11] <pitti> Good morning
[07:11] <pitti> slangasek: thanks! will put that resolved bug on my list
[07:11] <pitti> juliank: the queue doesn't autoreject it; you can upload the same version 10 times; of course only one of them can be accepted
[07:12] <juliank> pitti: Maybe I was not clear: I thought it was an incomplete upload, so it should have had wrong hashes...
[07:13] <pitti> juliank: apparently it made it through :)
[08:04] <ginggs> pitti: morning! node-lex-parser needs to be bootstrapped because of a circular dependency with jison. apparently it needs to be built locally and then uploaded with binaries. can an archive admin do this?
[08:05] <ginggs> i was able to build locally by reverting https://anonscm.debian.org/cgit/pkg-javascript/node-lex-parser.git/commit/?id=01595c51513806cfca489bf191c7c6cb349677e3 and adding a build-dep on nodejs-legacy
[08:06] <ginggs> unfortunately that failed in my PPA with npm could not be installed (i can't see why)
[08:12] <cpaelzer> pitti: thanks for your extra insight on the apparmor change I had
[08:12] <cpaelzer> pitti: do you happen to know if there is something similar for disk devices?
[08:13] <cpaelzer> pitti: I didn't find an abstraction for it, but I have another case where I add /dev/zd, /dev/nvme, ... to the already existing /dev/dm, ...
[08:13] <cpaelzer> pitti: so a similar case on something that could (should?) be covered by an abstraction/blcokdevices or anything like it?
[08:39] <pitti> cpaelzer: no, and that wouldn't make much sense
[08:39] <pitti> cpaelzer: if you can write on block devices, you have unrestricted root
[08:42] <cpaelzer> pitti: oh in that case it is a list of block device denies actually
[08:42] <cpaelzer> pitti: that needed to be extended to silence some log noise
[08:53] <pitti> ah, I see
[08:54] <pitti> cpaelzer: no, I'm not aware of an abstraction there; that's also a bit tricky as there's a great variety of name patterns
[08:54] <pitti> cpaelzer: wouldn't it be easier to deny it CAP_SYS_RAWIO or so?
[08:54] <pitti> ah no, it's not that
[09:02] <cpaelzer> pitti: I just wanted to make sure I'm not overlooking an abstraction again - if there is none I'm ok for the moment
[09:02] <cpaelzer> pitti: thanks!
[11:07] <showaz> mlmmj package without apparmor profile, postfix crash mlmmj-recieve
=== _salem is now known as salem_
[11:24] <showaz> https://lists.opensuse.org/opensuse-bugs/2016-09/msg02847.html
[12:02] <doko> http://autopkgtest.ubuntu.com/packages/r/rpmlint/zesty/armhf
[12:03] <doko> A server error occurred.  Please contact the administrator.
[12:03] <doko> pitti: ^^^
[12:07] <pitti> doko: ? looks fine to me?
[12:08] <pitti> doko: these are new PEP-8 failures from new pep8
[12:08] <doko> awesome, and barry is only handling turkey for a while ...
[12:08] <pitti> doko: oh, you mean you got that when opening that history page -- that's bug 1639847
[12:08] <ubottu> bug 1639847 in Auto Package Testing "web results incomplete/error out on locked DB" [Medium,Triaged] https://launchpad.net/bugs/1639847
[12:09] <pitti> that has bitten a few times, I'll put that higher on my list
[12:09] <doko> well, if it's a known pep8 issue, then please override these test results
[12:10] <pitti> well, it's not an issue with pep8 itself, these are pep-8 issues in rpmlint (but I'll override the current version anyway for that)
[12:12] <pitti> (done)
[12:36] <mdeslaur> nacc: hi! so I looked at your merge. The _only_ change you need to merge is "Drop dependency on libopenjp2-7-dev". Please remove all the patches and debian/rules change
[12:37] <mdeslaur> the other issues have been fixed in the actual code without needing to disable the coders, or have been fixed in a better way
[12:37] <mdeslaur> nacc: that being said, there's a new package in unstable now, so you need to merge that one in
[12:38] <mdeslaur> nacc: thanks!
[13:26] <mdeslaur> cpaelzer: any plans on updating qemu in zesty? I was waiting before pushing all the security patches from yakkety into zesty as perhaps we were going for 2.7 soon...
=== hikiko is now known as hikiko|ln
[13:30] <cpaelzer> mdeslaur: hi, yes there are plans
[13:31] <cpaelzer> mdeslaur: I'm opening a query for all the not-set-in-stone details not going to the log so that I get yelled at later on :-)
[13:41] <caribou> anybody from the SRU team not eating turkey today ?
[13:41] <caribou> rbasak: ^^
[13:42] <caribou> LP: #1584485 is causing regressions
[13:42] <ubottu> Launchpad bug 1584485 in samba (Debian) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [Unknown,New] https://launchpad.net/bugs/1584485
[14:01] <rbasak> bdmurray: we didn't really talk about how to deal with regressions ^
=== hikiko|ln is now known as hikiko
[14:03] <rbasak> I could push a revert, or I noticed that sru-release has a phasing option.
[14:04] <rbasak> "sru-release -z 0 trusty samba" maybe?
[14:05] <rbasak> http://people.canonical.com/~ubuntu-archive/phased-updates.html suggests already done?
[14:05] <rbasak> pitti: ^ help?
[14:08] <pitti> rbasak: right, seems someone/something already set the phasing to 0
[14:09] <rbasak> Should we upload a reverting 2:4.3.11+dfsg-0ubuntu0.14.04.3 and push it through?
[14:09] <pitti> rbasak: but I still think uploading a revert is useful, particularly if there's no obvious solution in sight
[14:09] <rbasak> pitti: OK, thanks. Any particular process? Or just review, accept and release immediately?
[14:10] <pitti> rbasak: basically, yes; the revert should still get some basic testing of course
[14:11] <rbasak> pitti: ack on basic testing - presumably no 7 day aging period though?
[14:11] <pitti> right
[14:11] <rbasak> caribou: could you upload the revert please?
[14:12] <rbasak> pitti: for the future, is one SRU team member +1 for all of that is OK? And would "sru-release -z 0 trusty samba" be the right way for the phasing stop if it had been needed?
[14:12] <caribou> rbasak: sure
[14:12] <pitti> rbasak: yes, and "looks plausible" (I haven't worked with phasing myself yet)
[14:13] <rbasak> OK, thanks :)
[14:37] <caribou> rbasak: pitti: ok, just uploaded a reverted version
[14:38] <rbasak> Thanks, reviewing.
[14:39] <rbasak> caribou: can you reference the regression bug 1644428 in the changelog please? Otherwise we can't track it with our usual tooling.
[14:39] <ubottu> bug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Triaged] https://launchpad.net/bugs/1644428
[14:40] <caribou> rbasak: I thought of it, but didn't want to auto-close it by stating LP: #1644428
[14:40] <caribou> rbasak: is there a prefered syntax for such things
[14:40] <caribou> ?
[14:41] <caribou> rbasak: & can you reject the upload so I can upload it again ?
[14:41] <rbasak> caribou: auto-close would be fine, no? If that bug claims the regression, and we revert the regression, we also believe that reverting the regression fixes the bug I think.
[14:42] <caribou> rbasak: true, didn't see it that way
[14:42] <rbasak> caribou: also I think you should still include the changelog entry from 2:4.3.11+dfsg-0ubuntu0.14.04.2 in the changelog for 2:4.3.11+dfsg-0ubuntu0.14.04.3.
[14:42] <rbasak> So 3 should be the same as 1, except for debian/changelog, which should be the same as 2 with your entry added as 3 to the top.
[14:42] <caribou> oops, true :-/
[14:43] <rbasak> caribou: rejected, but note that you can actually upload another with the same version into the unapproved queue - no need to wait.
[14:47] <caribou> rbasak: uploaded
[14:47]  * rbasak waits for it to appear
[14:50] <rbasak> caribou: c&p error in debian/changelog :-/
[14:50] <rbasak> (caribou had to pop out; I'll fix up)
[14:57] <rbasak> pitti: as caribou had to step away and I fixed up his upload, would you mind sanity checking my fixup please? samba in the trusty queue.
[14:58] <pitti> rbasak: wasn't that SRUed to all releases? or is just trusty affected by the regression?
[14:58] <pitti> (waiting for it to get diffy)
[14:58] <rbasak> pitti: it was only released into trusty. It's still in proposed in the other releases.
[14:58] <rbasak> (never v-d in other releases)
[14:59] <rbasak> Hmm. sru-review still shows me the old diff.
[14:59] <rbasak> The web UI seems up to date now though.
[15:00] <pitti> stgraber, balloons: FYI, bug 1644566 -- please don't backport lxd to stables before this gets fixed
[15:00] <ubottu> bug 1644566 in lxd (Ubuntu) "juju bootstrap hangs forever at "Attempting to connect to 10.0.4.130:22"" [High,New] https://launchpad.net/bugs/1644566
[15:01] <pitti> Laney: ^ my woes, FYI
[15:02] <pitti> and yay for having a working juju again :)
[15:04] <pitti> rbasak: "debdiff samba_4.3.11+dfsg-0ubuntu0.14.04.1.dsc samba_4.3.11+dfsg-0ubuntu0.14.04.3.dsc" is just d/changelog, so LGTM; accepting
[15:05] <rbasak> Thanks!
[15:19] <nacc> mdeslaur: oh excellent
[15:20] <mdeslaur> nacc: thanks for working on that!
[16:20] <Odd_Bloke> Do we have a list of "reserved" user names at all?  Things like "squid", "dnsmasq" etc.?
[16:29] <cjwatson> Odd_Bloke: there's one in user-setup, although it currently includes neither of those
[16:30] <cjwatson> Odd_Bloke: https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-usernames
[16:31] <Odd_Bloke> cjwatson: Thanks. :)
[16:32] <cjwatson> Odd_Bloke: I'll just add those two upstream, they seem reasonable
[16:33] <cjwatson> Odd_Bloke: hmm, doesn't squid actually use the "proxy" user though?
[16:34] <Odd_Bloke> cjwatson: Oh, perhaps; I was (evidently) inventing examples.
[16:34] <cjwatson> proxy is there
[16:35] <cjwatson> I've added dnsmasq
[16:45] <pitti> rbasak: while you are looking at SRUs, any chance you could review my x and y systemd uploads?
[16:57] <rbasak> pitti: I'm not actually looking at SRUs today - my day was yesterday. I just sorted this samba one because it was a regression. I'm actually in the middle of a massive strongswan merge review. I'm not familiar with systemd so a review would involve a full context switch, sorry.
[16:58] <rbasak> I can add it to my list though!
[16:58] <pitti> rbasak: ack, no problem; thanks
[17:07] <stgraber> pitti: well, 2.6 is aleady in xenial-backports, we don't SRU new releases though so that's not going to hit SRUs or anything
[17:14] <Son_Goku> stgraber, what? when was that true?
[17:15] <stgraber> Son_Goku: LXD SRUs stable bugfix releases (2.0.x) to xenial but not new feature releases (2.x), those only hit the dev release + get backported to xenial-backports
[17:15] <Son_Goku> snapd and snapcraft both get SRUs as feature releases
[17:16] <stgraber> I said LXD
[17:16] <Son_Goku> ah
[17:16] <stgraber> pitti: so hmm, why can't I disable systemd-resolved anymore? that's breaking my networking here which breaks LXD and kinda prevents me from looking into your issue.
[17:17] <stgraber> pitti: http://paste.ubuntu.com/23528334/
[17:17]  * stgraber removes the binary from disk for now
[17:20] <pitti> stgraber: not sure, why can't you disable it? just uninstall libnss-resolve?
[17:21] <stgraber> pitti: yeah, not sure what was confusing systemd... it was supposed to be disabled+masked :)
[17:21] <stgraber> anyway, network works again now
[17:22] <pitti> stgraber: there's nothing obviously broken in 2.6 itself -- the container starts etc, and I figure it's not lxd itself that installs the ssh key?
[17:28] <stgraber> pitti: correct, it's cloud-init
[17:29] <stgraber> pitti: juju sets user.user-data in the container config, then cloud-init picks that up and applies it
=== salem_ is now known as _salem
[17:53] <stgraber> pitti: reproduced your issue, looks like something's wrong with the cloud-init seed, all the seed files are empty...
=== _salem is now known as salem_
[18:01] <stgraber> pitti: what storage backend are you using in your test?
[18:14] <stgraber> pitti: so hmm, I'm starting to suspect mwhudson's shared library stuff, because a hand built LXD works fine, a LXD from the archive doesn't.
[18:15] <stgraber> pitti: I'll do two local rebuilds, a no change one to confirm that my sbuild gives me the same result, followed by a rebuild with shlibs disabled, if that's the issue, then I'll upload that
[18:16] <stgraber> and I'll write a new upstream test to validate template rendering because this should have been found by autopkgtest rather than you
[18:17]  * stgraber hopes it's shlibs and not some go source in the archive, because that'd be a PITA to track down
[18:21] <stgraber> pitti: reproduced with a local rebuild of the package, now trying with shlibs disabled
[18:26] <stgraber> pitti: confirmed to be a shlibs regression, closing juju-core and lxd bugs, moving to a golang bug and assigning to mwhudson
[18:26] <stgraber> pitti: I'll upload LXD with shlibs disabled in a minute.
[18:31] <stgraber> pitti: new LXD uploaded
=== salem_ is now known as _salem