nacc | mdeslaur: fyi, the corresponding import tree is present in ~usd-import-team, if you need to reproduce refs/tags along the way | 00:29 |
---|---|---|
=== dobey_ is now known as dobey | ||
cpaelzer | good morning | 06:40 |
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:11 |
juliank | pitti: Maybe I was not clear: I thought it was an incomplete upload, so it should have had wrong hashes... | 07:12 |
pitti | juliank: apparently it made it through :) | 07:13 |
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:04 |
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:05 |
ginggs | unfortunately that failed in my PPA with npm could not be installed (i can't see why) | 08:06 |
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:12 |
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:13 |
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:39 |
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:42 |
pitti | ah, I see | 08:53 |
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 | 08:54 |
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! | 09:02 |
showaz | mlmmj package without apparmor profile, postfix crash mlmmj-recieve | 11:07 |
=== _salem is now known as salem_ | ||
showaz | https://lists.opensuse.org/opensuse-bugs/2016-09/msg02847.html | 11:24 |
doko | http://autopkgtest.ubuntu.com/packages/r/rpmlint/zesty/armhf | 12:02 |
doko | A server error occurred. Please contact the administrator. | 12:03 |
doko | pitti: ^^^ | 12:03 |
pitti | doko: ? looks fine to me? | 12:07 |
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:08 |
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:09 |
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:10 |
pitti | (done) | 12:12 |
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:36 |
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:37 |
mdeslaur | nacc: thanks! | 12:38 |
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... | 13:26 |
=== hikiko is now known as hikiko|ln | ||
cpaelzer | mdeslaur: hi, yes there are plans | 13:30 |
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:31 |
caribou | anybody from the SRU team not eating turkey today ? | 13:41 |
caribou | rbasak: ^^ | 13:41 |
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 | 13:42 |
rbasak | bdmurray: we didn't really talk about how to deal with regressions ^ | 14:01 |
=== hikiko|ln is now known as hikiko | ||
rbasak | I 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 |
rbasak | http://people.canonical.com/~ubuntu-archive/phased-updates.html suggests already done? | 14:05 |
rbasak | pitti: ^ help? | 14:05 |
pitti | rbasak: right, seems someone/something already set the phasing to 0 | 14:08 |
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:09 |
pitti | rbasak: basically, yes; the revert should still get some basic testing of course | 14:10 |
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:11 |
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:12 |
rbasak | OK, thanks :) | 14:13 |
caribou | rbasak: pitti: ok, just uploaded a reverted version | 14:37 |
rbasak | Thanks, reviewing. | 14:38 |
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:39 |
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:40 |
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:41 |
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:42 |
rbasak | caribou: rejected, but note that you can actually upload another with the same version into the unapproved queue - no need to wait. | 14:43 |
caribou | rbasak: uploaded | 14:47 |
* rbasak waits for it to appear | 14:47 | |
rbasak | caribou: c&p error in debian/changelog :-/ | 14:50 |
rbasak | (caribou had to pop out; I'll fix up) | 14:50 |
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:57 |
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:58 |
rbasak | Hmm. sru-review still shows me the old diff. | 14:59 |
rbasak | The web UI seems up to date now though. | 14:59 |
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:00 |
pitti | Laney: ^ my woes, FYI | 15:01 |
pitti | and yay for having a working juju again :) | 15:02 |
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:04 |
rbasak | Thanks! | 15:05 |
nacc | mdeslaur: oh excellent | 15:19 |
mdeslaur | nacc: thanks for working on that! | 15:20 |
Odd_Bloke | Do we have a list of "reserved" user names at all? Things like "squid", "dnsmasq" etc.? | 16:20 |
cjwatson | Odd_Bloke: there's one in user-setup, although it currently includes neither of those | 16:29 |
cjwatson | Odd_Bloke: https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-usernames | 16:30 |
Odd_Bloke | cjwatson: Thanks. :) | 16:31 |
cjwatson | Odd_Bloke: I'll just add those two upstream, they seem reasonable | 16:32 |
cjwatson | Odd_Bloke: hmm, doesn't squid actually use the "proxy" user though? | 16:33 |
Odd_Bloke | cjwatson: Oh, perhaps; I was (evidently) inventing examples. | 16:34 |
cjwatson | proxy is there | 16:34 |
cjwatson | I've added dnsmasq | 16:35 |
pitti | rbasak: while you are looking at SRUs, any chance you could review my x and y systemd uploads? | 16:45 |
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:57 |
rbasak | I can add it to my list though! | 16:58 |
pitti | rbasak: ack, no problem; thanks | 16:58 |
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:07 |
Son_Goku | stgraber, what? when was that true? | 17:14 |
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:15 |
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:16 |
stgraber | pitti: http://paste.ubuntu.com/23528334/ | 17:17 |
* stgraber removes the binary from disk for now | 17:17 | |
pitti | stgraber: not sure, why can't you disable it? just uninstall libnss-resolve? | 17:20 |
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:21 |
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:22 |
stgraber | pitti: correct, it's cloud-init | 17:28 |
stgraber | pitti: juju sets user.user-data in the container config, then cloud-init picks that up and applies it | 17:29 |
=== salem_ is now known as _salem | ||
stgraber | pitti: 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_ | ||
stgraber | pitti: what storage backend are you using in your test? | 18:01 |
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:14 |
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:15 |
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:16 |
* stgraber hopes it's shlibs and not some go source in the archive, because that'd be a PITA to track down | 18:17 | |
stgraber | pitti: reproduced with a local rebuild of the package, now trying with shlibs disabled | 18:21 |
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:26 |
stgraber | pitti: new LXD uploaded | 18:31 |
=== salem_ is now known as _salem |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!