[02:20] <jbicha> doko: Debian #862425 is "fixed"
[08:45] <doko> LocutusOfBorg: you sponsored gdbm to experimental. are you going to do the transition?
[08:46] <doko> jbicha: right, that's what I feared
[08:55] <Unit193> doko: I enjoyed the bug against bzr to move to py3, btw. :)
[08:58] <doko> Unit193: and I would enjoy your insights on bittornado
[08:59] <doko> but well, hot air ...
[09:01] <Unit193> Gah, right.  That.  I've been using it since 2015, or at least had it installed.  Talked to a couple in #debian-devel but none yet were interested in co-maintaining.  I should really note the new upstream on your bug though.
[09:02] <doko> that would be nice
[09:08] <LocutusOfBorg> doko, I can do probably, maybe after updating to 1.13
[09:09] <LocutusOfBorg> I was waiting for kaction to be back :(
[09:09] <Unit193> Done, doko.
[09:23] <jamespage> morning all
[12:03] <juliank> jjohansen: (someone in Debian) was wondering what the status on upstreaming dbus mediation is, can you tell me anything? :)
[12:41] <doko> Unit193: co-maintaining ... the package should be orphaned. last maintainer upload in 2010 ...
[12:45] <juliank> lol efitools specifies i -I/usr/include/efi/$(ARCH) in its Make.rules, leading to i -I/usr/include/efi/i686 where it should be -I/usr/include/efi/ia32
[12:46]  * juliank should update that to 1.7.0
[12:47] <juliank> Summary of gnu-efi 3.0.6 rebuilds: Only refind and efitools FTBFS, the others are fine :)
[12:48] <juliank> refind defines CatPrint() with a conflicting prototype, should be easy to fix
[12:49] <juliank> I expected things to to be worse
[13:59] <pitti> xnox: http://autopkgtest.ubuntu.com/running#queue-upstream-artful-arm64 doesn't seem to get picked up? or is that just starvation?
[13:59] <pitti> (ENOLANEY)
[14:10] <xnox> pitti, i think we do starve upstream on purpose; wait until after arm64 is clear on ubuntu & huge.
[14:10] <pitti> xnox: ah ok; so not yet the time to enable it
[14:10] <xnox> pitti, we are also working on a KPI dashboard to monitor this better and have accurate historical data for capacity planning.
[14:11] <xnox> pitti, unless arm64 workers are not listening on upstream arm64 queue =/
[14:11] <pitti> I actually deliberately used separate upstream queues back then so that we don't starve non-ubuntu projects
[14:11] <pitti> but I suppose with arm64 we don't have that much capacity yet
[14:11] <xnox> pitti, but i think it was round robin; but now it's like sequenced after; e.g. no upstream until after ubuntu is fully drained.
[14:12] <xnox> but i may be wrong
[14:12] <xnox> ENOLANEY it is
[14:12] <pitti> ok; that works as a kind of "first time bootstrap" policy,  but not in general
[14:13] <xnox> pitti, yeah, and i do not know if arm64 is fully bootstrapped or not, i thought it was.
[14:14] <infinity> xnox: You're wrong.
[14:14] <xnox> infinity, please enlighten me
[14:15] <infinity> upstream is given a quota that prevents it from starving Ubuntu (and that quota was lowered a while back).
[14:15] <infinity> As for the arm64 situation, I'm not sure, it may just literally not be hooked up.
[14:15] <infinity> Or the quota was dialed down to 0 there.
[14:15] <infinity> I'd have to figure out where to look first. :P
[14:15] <pitti> right, I remember Laney disabling the quota
[14:16] <pitti> two weeks ago or so we hardly had any upstream test running despite all the queues being empty
[14:16] <pitti> so that was buggy
[15:35] <jjohansen> juliank: so their are two parts needed
[15:35] <jjohansen> the apparmor extension to do dbus mediation went into the dbus daemon quite a while ago (I would have to go look up the release)
[15:35] <jjohansen> the upstreaming on the kernel side hit a bump in 4.14 due to the revert that got done, and now the earliest we are going to be able to get that in would be 4.16
[16:39] <ahasenack> hi, does anybody have a tip on how I could proceed with trying to reproduce this armhf dep8 test failure: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/armhf/c/chrony/20171130_162939_de853@/log.gz
[16:39] <ahasenack> in other words, how to either run arm on my laptop (qemu-system-arm?) or if there is some canonical cluster I could use perhaps
[16:52] <juliank> jjohansen: is that kernel code the net.c code?
[16:52] <juliank> I also see some af_unix.c in the ubuntu trees, but none in the for upstream apparmor trees
[17:43] <jjohansen> juliank: it needs the net code but it also needs af_unix.c and a small patch to apparmorfs
[17:43] <juliank> jjohansen: OK, thanks for the details :)
[20:44] <Unit193> doko: Right, I would be interested in half-maintaining it. :)