[02:20] doko: Debian #862425 is "fixed" [02:20] Debian bug 862425 in pcre2 "pcre2: Please switch to 3.0 (quilt) or use dgit-maint-merge(7)" [Wishlist,Fixed] http://bugs.debian.org/862425 === rbalint_ is now known as rbalint === led_ir23 is now known as led_ir22 === Guest27466 is now known as RAOF [08:45] LocutusOfBorg: you sponsored gdbm to experimental. are you going to do the transition? [08:46] jbicha: right, that's what I feared [08:55] doko: I enjoyed the bug against bzr to move to py3, btw. :) [08:58] Unit193: and I would enjoy your insights on bittornado [08:59] but well, hot air ... [09:01] 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] that would be nice [09:08] doko, I can do probably, maybe after updating to 1.13 [09:09] I was waiting for kaction to be back :( [09:09] Done, doko. [09:23] morning all === Zic_ is now known as Zic [12:03] jjohansen: (someone in Debian) was wondering what the status on upstreaming dbus mediation is, can you tell me anything? :) === mhcerri_ is now known as mhcerri [12:41] Unit193: co-maintaining ... the package should be orphaned. last maintainer upload in 2010 ... [12:45] 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] Summary of gnu-efi 3.0.6 rebuilds: Only refind and efitools FTBFS, the others are fine :) [12:48] refind defines CatPrint() with a conflicting prototype, should be easy to fix [12:49] I expected things to to be worse === tomreyn_ is now known as tomreyn [13:59] xnox: http://autopkgtest.ubuntu.com/running#queue-upstream-artful-arm64 doesn't seem to get picked up? or is that just starvation? [13:59] (ENOLANEY) [14:10] pitti, i think we do starve upstream on purpose; wait until after arm64 is clear on ubuntu & huge. [14:10] xnox: ah ok; so not yet the time to enable it [14:10] pitti, we are also working on a KPI dashboard to monitor this better and have accurate historical data for capacity planning. [14:11] pitti, unless arm64 workers are not listening on upstream arm64 queue =/ [14:11] I actually deliberately used separate upstream queues back then so that we don't starve non-ubuntu projects [14:11] but I suppose with arm64 we don't have that much capacity yet [14:11] 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] but i may be wrong [14:12] ENOLANEY it is [14:12] ok; that works as a kind of "first time bootstrap" policy, but not in general [14:13] pitti, yeah, and i do not know if arm64 is fully bootstrapped or not, i thought it was. [14:14] xnox: You're wrong. [14:14] infinity, please enlighten me [14:15] upstream is given a quota that prevents it from starving Ubuntu (and that quota was lowered a while back). [14:15] As for the arm64 situation, I'm not sure, it may just literally not be hooked up. [14:15] Or the quota was dialed down to 0 there. [14:15] I'd have to figure out where to look first. :P [14:15] right, I remember Laney disabling the quota [14:16] two weeks ago or so we hardly had any upstream test running despite all the queues being empty [14:16] so that was buggy [15:35] juliank: so their are two parts needed [15:35] 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] 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] 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] 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] jjohansen: is that kernel code the net.c code? [16:52] I also see some af_unix.c in the ubuntu trees, but none in the for upstream apparmor trees [17:43] juliank: it needs the net code but it also needs af_unix.c and a small patch to apparmorfs [17:43] jjohansen: OK, thanks for the details :) === ScriptRipp is now known as ScriptRipper [20:44] doko: Right, I would be interested in half-maintaining it. :)