[00:39] <g2> Exciting election talk and debate in #debate2016
[06:34] <cpaelzer> good morning
[06:49] <pitti> Good (well, "some") morning!
[10:29] <LocutusOfBorg> TheMuso, hi, you there?
[10:31] <LocutusOfBorg> question about Tascam US-122L
[10:32] <LocutusOfBorg> should I just add a new profile in libasound2-data to make it work?
[11:42] <pitti> stgraber: if you get pings about lxc being broken in zesty: this is https://github.com/lxc/lxc/issues/1280 and I reverted the usage of the unified hierarchy in systemd 232-3 (will hit zesty ~ tomorrow); local workaround is to boot with systemd.legacy_systemd_cgroup_controller
[12:25] <stgraber> pitti: ok, thanks. I heard about it through Debian and assumed it'd affect us shortly after too and that you'd do the right thing on both :)
[12:26] <pitti> stgraber: ah, ok; I just wanted to ensure that you don't have to do duplicate work; sorry for the hiccup
[12:26] <pitti> nevertheless, it was useful to find these bugs
[12:26] <pitti> but we shoudln't have to fix them under pressure
[12:29] <stgraber> pitti: well, we knew about that issue and some others, the problem is that since the kernel won't let you mount cgroupv1 AND cgroupv2 for the same controller, even in separate namespaces, there is effectively no way to fix this...
[12:29] <stgraber> pitti: other than convince Tejun that we do need to be able to mount cgroupv2 on the host and cgroupv1 in containers and have him allow that in the cgns code
[12:29] <stgraber> or fake all that stuff with fuse, but that'd suck...
[12:30] <stgraber> we mentioned all of this last week at Kernel Summit + Plumbers, with both Tejun and Lennart in the room, so neither of them can say they didn't know this would happen...
[12:30] <stgraber> tych0, hallyn: ^
[12:32] <tych0> in fact i had a big argument with tejun and he said he wouldn't fix it :)
[12:36] <pitti> stgraber: ack; at least it shouldn't segfault, I see the difficulty in supporting v1 containers with v2 on the host, but I thought with cgroup namespaces you could actually do that? so that's not the case?
[12:38] <tych0> pitti: right, it's global
[13:05] <doko> seb128, Laney: is the desktop team caring about all the spell checkers? looks like hunspell-bo is seeded now, and would need a MIR
[13:06] <seb128> hey doko, I don't think we are ... is that due to libreoffice?
[13:06] <doko> seb128: I see it at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[13:12] <Laney> doko: There's a regex which puts them all in supported
[13:12] <Laney> others have this https://launchpad.net/~translators-packages team subscribed
[13:13] <doko> one member team ...
[13:15] <Laney> I don't think they require any real maintenance on our side
[14:51] <smoser> cyphermox, mostly unrelated to the discussion in #ubuntu-release, so i've moved it here instead (and i'd also like pitti's input)
[14:51] <smoser> http://paste.ubuntu.com/23374663/
[14:52] <smoser> please do read https://git.launchpad.net/~smoser/ubuntu/+source/open-iscsi/tree/debian/tests/README-boot-test.md?h=diglett-master along with it and especially the Caveats there.
[14:53] <smoser> i'm not sure where we should ultimately be running these tests, but we need to be running them somewhere for sure.
[14:55] <cyphermox> heh, if it works in open-iscsi, that should be fine
[14:55] <cyphermox> and hopefully doesn't break when at the start of a new release and there are no images, or something like that
[14:56] <smoser> well, but what is the correct behavior in that case?
[14:56] <cyphermox> what do you mean?
[14:56] <smoser> if there is no image, what should it do ?
[14:56] <cyphermox> I'm all for fixing those tests, they're broken in lots of fun ways, I only did enough for them to pass
[14:56] <cyphermox> I suppose they should fail, but in a way that makes it obvious that it is a transient failure.
[14:57] <smoser> and (see caveat 1), how should you patch an image in a dep8 test to include only the dependency that its attempting to verify
[14:57] <smoser> ie, i can't just add -proposed and apt-get upgrade the image
[14:57] <cyphermox> why not?
[14:57] <smoser> as that will get everything in -proposed
[14:58] <smoser> and no 'control'
[14:58] <cyphermox> we probably could just install the new initramfs-tools, it's likely good enough
[14:58] <smoser> does the environment have information on which package it is running to test ?
[14:59] <cyphermox> I don't know
[14:59] <smoser> this is what i'm saying... and even if it did, how do i get the right set of packages to update the image with ?
[14:59] <cyphermox> I think that's the problem with running images like that though, not much of a way around it
[15:00] <cyphermox> unless pitti has some idea
[15:00] <cyphermox> otherwise I suppose the boot tests could be moved to the image promotion logic
[15:00] <pitti> just here with ½ a brain cell (deep in debugging), but the test does know which package it's running for: it's in $ADT_TEST_TRIGGERS
[15:01] <smoser> the source package..
[15:02] <smoser> you'd still have to tthenupgrade the image with the packages that were created from that and only those (i think )
[15:02] <pitti> but, it seems much easier to look at the current package versions that are installed
[15:02] <smoser> ?
[15:02] <pitti> autopkgtest already install the minimal set of -proposed packages to verify that
[15:02] <smoser> but they install them in the host
[15:02] <pitti> (IOW: don't try to be clever)
[15:03] <smoser> and i basically have to copy that set of things to the guest
[16:17] <xnox> barry, is claws-mail python plugin written with boost-python at all?
[16:18]  * xnox has no idea about claws codebase
[16:19] <barry> xnox: it's not explicitly declared to, but otoh, the build log does pull it in
[16:19] <barry> libboost-filesystem1.62.0
[16:20] <barry> libboost-system1.62.0
[16:22] <barry> xnox: otoh, python.so does not link against it afaict
[16:25] <xnox> barry, in zesty? using old boost1.62? could you try rebuilding with 1.62.0+dfsg-2ubuntu1? and is it python2 or python3 that fails?
[16:25] <barry> xnox: the plugin is a python2 plugin
[16:26] <xnox> -2 had python3 broken; -2ubuntu1 should have python3 fixed; but maybe python2 is borked now.
[16:27] <barry> xnox: and it does look like it picked up 1.62.0+dfsg-2ubuntu1 (this was a zesty schroot as of yesterday)
[16:27] <xnox> not good if i broke python2 now.
[16:27] <barry> xnox: so yeah, maybe python2 is broken (i don't know whether upstream supports python3, but i should look into that)
[16:28] <xnox> barry, it's a double edge sward. these sort of plugins process user scripts and hooks and stuff; which is most likely written in python2.
[16:28] <barry> xnox: like other plugins, it should build two versions and let the user decide
[16:29] <xnox> if you can somehow make python2 & python3 plugins that would be great.... but i daubt one will be able to load and run, user scripts/hooks with python2 and 3 simultaniously.
[16:29] <barry> i see that it pulls in both py2 and py3, but ldd shows it's linked only against py2
[16:29] <pitti> stgraber: seems tejun and h_allyn figured this out in https://github.com/systemd/systemd/pull/3965
[16:29] <barry> xnox: oh for sure, it will be a binary choice, but the user could decide which one they want
[16:29] <xnox> pitti, \o/
[16:34] <stgraber> pitti: based on discussion in #lxc-dev, it sounds like this only works if the container manager pre-mounts things instead of having systemd mount things itself
[16:34] <stgraber> pitti: so not exactly perfect because LXD doesn't know what distro you're running, whether you want those mounts or not and where they should be
[16:34] <pitti> stgraber: right -- like nspawn/lxc etc. mount a new hierarchy root "container" and then the guest does whatever it likes with it?
[16:34] <stgraber> pitti: instead we much prefer the init systemd (or whatever else) in the container just do the mount
[16:35] <pitti> ok; I'll leave it between h_allyn and tejun to continue discussing this, I don't know enough about the details
[16:35] <stgraber> pitti: well, right now lxc doesn't mount anything, it creates the cgroups, moves you to them and unshares a cgroup namespace. the mounts are entirely done by systemd as it would on a normal system
[16:35] <stgraber> pitti: and that part fails
[16:36] <pitti> stgraber: oh, I understood it like the only thing that lxd needs to do is to create the new cgroup namespace, not any actual mounts
[16:37]  * pitti bbl
[16:37] <stgraber> pitti: yeah no, Tejun is talking about actual mounts
[16:43] <juliank> pitti: Seems like apt/xenial failed on s390x. Is there a button for me to retry that?
[16:44] <juliank> Ah found it
[16:44] <Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#apt
[16:44]  * Laney too slow
[16:45] <juliank> Well, not sure it likes me: A server error occurred.  Please contact the administrator.
[16:46] <juliank> There are some regressions from autopkgtest and sbuild, but I'm not sure they are related.
[16:47] <juliank> That is, sbuild seems to fail ever since yakkety and now zesty became devel
[16:49] <juliank> And autopkgtest also similarly seems to fail regardless of apt triggering the test or not
[16:50] <juliank> Anyway, gtg now
[19:19] <bdmurray> barry: could you have a look at this merge proposal for aptdaemon? https://code.launchpad.net/~flexiondotorg/aptdaemon/aptdaemon-lp1623856/+merge/309871
[19:19] <flexiondotorg> bdmurray, Not yet.
[19:19] <flexiondotorg> I've got an update in the works for it.
[19:19] <flexiondotorg> Should be done tomorrow.
[19:20] <bdmurray> flexiondotorg: The aptdaemon fix is incomplete?
[19:21] <flexiondotorg> Actually no, the aptdaemon fix should be fine. There are some additions for update-manager.
[19:21] <flexiondotorg> But both should be tested together.
[19:22] <bdmurray> I don't see how that should block reviewing the upstream merge proposal.
[19:22] <flexiondotorg> OK
[19:32] <barry> bdmurray: commented
[19:33] <bdmurray> barry: do you not want to merge it?
[19:35] <barry> bdmurray: oh, i thought you were just looking for a review.  you want me to merge and upload?
[19:36] <bdmurray> barry: please!
[19:36] <barry> bdmurray: ok.  i need to finish up a few other things first.
[19:40] <bdmurray> barry: Sure, not a huge hurry - I just saw you in the aptdaemon developers group
[19:40] <barry> bdmurray: betrayed again!
[20:35] <doko> bdmurray: is translators-packages a team which is ok for bug subscriptions?
[20:35] <doko> only has one member
[20:36] <bdmurray> doko: yes, its a placeholder for reports
[20:37] <doko> bdmurray: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg please could you add hunspell-bo? then I'll promote it
[20:38] <bdmurray> doko: translators-packages is now subscribed to all bugs about hunspell-bo.
[20:38] <doko> hta
[20:40] <doko> promoted
[20:41]  * doko wonders why bo is selected for Tibetan ...
[20:45] <cjwatson> doko: https://en.wikipedia.org/wiki/Bodish_languages
[20:46] <cjwatson> The word for Tibet in Classical Tibetan was "Bod", apparently
[20:59] <doko> cjwatson: ta for the pointer :)
[21:11] <barry> bdmurray: do we want to sru this into yakkety or just fix it in zesty?
[21:13] <bdmurray> barry: It sounded like flexiondotorg had some more update-manager work to do so lets wait for him to get that squared away for the SRU.
[21:16] <barry> bdmurray: okay.  what i don't really remember is how to do aptdaemon releases.  we currently have deltas from debian, so i'm trying to decide whether to just upload this to zesty (furthering our delta).  i might contact upstream and see if we can get that merged there with an eventual merge to zesty
[21:18] <bdmurray> barry: okay
[21:22] <barry> bdmurray: i'm not even sure aptdaemon is still a thing in debian.  in any case, i've contacted upstream so we'll see
[21:33] <coreycb> bdmurray, hello, if you have a chance this week could you review neutron in the trusty queue?
[21:36] <bdmurray> coreycb: releasing neutron into -updates or accepting a new one into -proposed?
[21:38] <coreycb> bdmurray, so many neutrons...  :) for trusty, just accepting into proposed would be great.  the xenial neutron should be ready to promote to updates.
[21:38] <bdmurray> coreycb: got it
[21:39] <coreycb> bdmurray, thanks
[23:45] <nacc> jgrimm: sorry for the long delay, i'm re-running hte at import now
[23:46] <nacc> jgrimm: smoser: rbasak: i just pushed up my local changes; i'm still testing them, but they seem stable, please ping if you find breakages (it was a ton of reorganizing)