naccmdeslaur: fyi, the corresponding import tree is present in ~usd-import-team, if you need to reproduce refs/tags along the way00:29
=== dobey_ is now known as dobey
cpaelzergood morning06:40
pittiGood morning07:11
pittislangasek: thanks! will put that resolved bug on my list07:11
pittijuliank: the queue doesn't autoreject it; you can upload the same version 10 times; of course only one of them can be accepted07:11
juliankpitti: Maybe I was not clear: I thought it was an incomplete upload, so it should have had wrong hashes...07:12
pittijuliank: apparently it made it through :)07:13
ginggspitti: 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:04
ginggsi 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-legacy08:05
ginggsunfortunately that failed in my PPA with npm could not be installed (i can't see why)08:06
cpaelzerpitti: thanks for your extra insight on the apparmor change I had08:12
cpaelzerpitti: do you happen to know if there is something similar for disk devices?08:12
cpaelzerpitti: 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
cpaelzerpitti: so a similar case on something that could (should?) be covered by an abstraction/blcokdevices or anything like it?08:13
pitticpaelzer: no, and that wouldn't make much sense08:39
pitticpaelzer: if you can write on block devices, you have unrestricted root08:39
cpaelzerpitti: oh in that case it is a list of block device denies actually08:42
cpaelzerpitti: that needed to be extended to silence some log noise08:42
pittiah, I see08:53
pitticpaelzer: no, I'm not aware of an abstraction there; that's also a bit tricky as there's a great variety of name patterns08:54
pitticpaelzer: wouldn't it be easier to deny it CAP_SYS_RAWIO or so?08:54
pittiah no, it's not that08:54
cpaelzerpitti: I just wanted to make sure I'm not overlooking an abstraction again - if there is none I'm ok for the moment09:02
cpaelzerpitti: thanks!09:02
showazmlmmj package without apparmor profile, postfix crash mlmmj-recieve11:07
=== _salem is now known as salem_
dokoA server error occurred.  Please contact the administrator.12:03
dokopitti: ^^^12:03
pittidoko: ? looks fine to me?12:07
pittidoko: these are new PEP-8 failures from new pep812:08
dokoawesome, and barry is only handling turkey for a while ...12:08
pittidoko: oh, you mean you got that when opening that history page -- that's bug 163984712:08
ubottubug 1639847 in Auto Package Testing "web results incomplete/error out on locked DB" [Medium,Triaged] https://launchpad.net/bugs/163984712:08
pittithat has bitten a few times, I'll put that higher on my list12:09
dokowell, if it's a known pep8 issue, then please override these test results12:09
pittiwell, 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:10
mdeslaurnacc: 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 change12:36
mdeslaurthe other issues have been fixed in the actual code without needing to disable the coders, or have been fixed in a better way12:37
mdeslaurnacc: that being said, there's a new package in unstable now, so you need to merge that one in12:37
mdeslaurnacc: thanks!12:38
mdeslaurcpaelzer: 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...13:26
=== hikiko is now known as hikiko|ln
cpaelzermdeslaur: hi, yes there are plans13:30
cpaelzermdeslaur: 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:31
caribouanybody from the SRU team not eating turkey today ?13:41
caribourbasak: ^^13:41
caribouLP: #1584485 is causing regressions13:42
ubottuLaunchpad 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/158448513:42
rbasakbdmurray: we didn't really talk about how to deal with regressions ^14:01
=== hikiko|ln is now known as hikiko
rbasakI could push a revert, or I noticed that sru-release has a phasing option.14:03
rbasak"sru-release -z 0 trusty samba" maybe?14:04
rbasakhttp://people.canonical.com/~ubuntu-archive/phased-updates.html suggests already done?14:05
rbasakpitti: ^ help?14:05
pittirbasak: right, seems someone/something already set the phasing to 014:08
rbasakShould we upload a reverting 2:4.3.11+dfsg-0ubuntu0.14.04.3 and push it through?14:09
pittirbasak: but I still think uploading a revert is useful, particularly if there's no obvious solution in sight14:09
rbasakpitti: OK, thanks. Any particular process? Or just review, accept and release immediately?14:09
pittirbasak: basically, yes; the revert should still get some basic testing of course14:10
rbasakpitti: ack on basic testing - presumably no 7 day aging period though?14:11
rbasakcaribou: could you upload the revert please?14:11
rbasakpitti: 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
caribourbasak: sure14:12
pittirbasak: yes, and "looks plausible" (I haven't worked with phasing myself yet)14:12
rbasakOK, thanks :)14:13
caribourbasak: pitti: ok, just uploaded a reverted version14:37
rbasakThanks, reviewing.14:38
rbasakcaribou: can you reference the regression bug 1644428 in the changelog please? Otherwise we can't track it with our usual tooling.14:39
ubottubug 1644428 in samba (Ubuntu Trusty) "Unable to log in with AD account after update" [High,Triaged] https://launchpad.net/bugs/164442814:39
caribourbasak: I thought of it, but didn't want to auto-close it by stating LP: #164442814:40
caribourbasak: is there a prefered syntax for such things14:40
caribourbasak: & can you reject the upload so I can upload it again ?14:41
rbasakcaribou: 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:41
caribourbasak: true, didn't see it that way14:42
rbasakcaribou: 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.
rbasakSo 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
caribouoops, true :-/14:42
rbasakcaribou: rejected, but note that you can actually upload another with the same version into the unapproved queue - no need to wait.14:43
caribourbasak: uploaded14:47
* rbasak waits for it to appear14:47
rbasakcaribou: c&p error in debian/changelog :-/14:50
rbasak(caribou had to pop out; I'll fix up)14:50
rbasakpitti: 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:57
pittirbasak: 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
rbasakpitti: 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:58
rbasakHmm. sru-review still shows me the old diff.14:59
rbasakThe web UI seems up to date now though.14:59
pittistgraber, balloons: FYI, bug 1644566 -- please don't backport lxd to stables before this gets fixed15:00
ubottubug 1644566 in lxd (Ubuntu) "juju bootstrap hangs forever at "Attempting to connect to"" [High,New] https://launchpad.net/bugs/164456615:00
pittiLaney: ^ my woes, FYI15:01
pittiand yay for having a working juju again :)15:02
pittirbasak: "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; accepting15:04
naccmdeslaur: oh excellent15:19
mdeslaurnacc: thanks for working on that!15:20
Odd_BlokeDo we have a list of "reserved" user names at all?  Things like "squid", "dnsmasq" etc.?16:20
cjwatsonOdd_Bloke: there's one in user-setup, although it currently includes neither of those16:29
cjwatsonOdd_Bloke: https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-usernames16:30
Odd_Blokecjwatson: Thanks. :)16:31
cjwatsonOdd_Bloke: I'll just add those two upstream, they seem reasonable16:32
cjwatsonOdd_Bloke: hmm, doesn't squid actually use the "proxy" user though?16:33
Odd_Blokecjwatson: Oh, perhaps; I was (evidently) inventing examples.16:34
cjwatsonproxy is there16:34
cjwatsonI've added dnsmasq16:35
pittirbasak: while you are looking at SRUs, any chance you could review my x and y systemd uploads?16:45
rbasakpitti: 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:57
rbasakI can add it to my list though!16:58
pittirbasak: ack, no problem; thanks16:58
stgraberpitti: well, 2.6 is aleady in xenial-backports, we don't SRU new releases though so that's not going to hit SRUs or anything17:07
Son_Gokustgraber, what? when was that true?17:14
stgraberSon_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-backports17:15
Son_Gokusnapd and snapcraft both get SRUs as feature releases17:15
stgraberI said LXD17:16
stgraberpitti: 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:16
stgraberpitti: http://paste.ubuntu.com/23528334/17:17
* stgraber removes the binary from disk for now17:17
pittistgraber: not sure, why can't you disable it? just uninstall libnss-resolve?17:20
stgraberpitti: yeah, not sure what was confusing systemd... it was supposed to be disabled+masked :)17:21
stgraberanyway, network works again now17:21
pittistgraber: 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:22
stgraberpitti: correct, it's cloud-init17:28
stgraberpitti: juju sets user.user-data in the container config, then cloud-init picks that up and applies it17:29
=== salem_ is now known as _salem
stgraberpitti: reproduced your issue, looks like something's wrong with the cloud-init seed, all the seed files are empty...17:53
=== _salem is now known as salem_
stgraberpitti: what storage backend are you using in your test?18:01
stgraberpitti: 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:14
stgraberpitti: 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 that18:15
stgraberand I'll write a new upstream test to validate template rendering because this should have been found by autopkgtest rather than you18:16
* stgraber hopes it's shlibs and not some go source in the archive, because that'd be a PITA to track down18:17
stgraberpitti: reproduced with a local rebuild of the package, now trying with shlibs disabled18:21
stgraberpitti: confirmed to be a shlibs regression, closing juju-core and lxd bugs, moving to a golang bug and assigning to mwhudson18:26
stgraberpitti: I'll upload LXD with shlibs disabled in a minute.18:26
stgraberpitti: new LXD uploaded18:31
=== salem_ is now known as _salem

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