[04:28] <pitti> Good morning
[05:34] <pitti> doko: are you okay with dropping python3-ldb again? it has no rdepends, is an Ubuntu specific delta, and needs the NBS python3-talloc to build (see http://people.canonical.com/~ubuntu-archive/nbs.html)
[05:43] <jbicha> pitti: if you're processing nbs, libwebkit-dev is only an alternate build-depends for those packages
[05:43] <pitti> jbicha: thanks!
[06:05] <doko> pitti: sure, we can do that
[08:17] <pitti> !op @ dinger-donger
[08:18] <dinger-donger> lol
[08:18] <pitti> dinger-donger: please leave the topic alone, this is vandalism
[08:18] <dinger-donger> pitti: fuck that
[08:19] <pitti> dholbach: what's the magic incantation to ping IRC ops? dinger-donger needs to be kickbanned
[08:19] <pitti> Unit193: cheers
[08:20] <dholbach> thanks Unit193 and pitti
[08:21] <Unit193> Sure thing.
[08:21] <dholbach> I don't know of any magic incantations
[08:21] <dholbach> but I'm sure there are :)
[08:21] <pitti> I thought we had some kind of !ops or so
[08:21] <dholbach> yeah, I was about to suggest the same
[08:21] <pitti> and I'm sure I've seen it before, I just forgot
[08:21] <pitti> !help
[08:22] <pitti> !commands
[08:22] <dholbach> haha
[08:22] <pitti> !nocookies
[08:23] <Unit193> pitti: Use it like: !ops | bar is spamming the topic
[08:23] <pitti> Unit193: ah, so my "!op @ bar" was close :)
[08:23] <Unit193> Yep.
[08:23] <pitti> !ops @ dholbach needs a hug
[08:23] <pitti> err
[08:23] <pitti> !ops | dholbach needs a hug
[08:24] <pitti> sorry, unping -- already sorted out
[08:24]  * pitti hugs dholbach anyway
[08:24] <ikonia> pitti: can you stop that please
[08:24]  * pitti notices that this list of people is *very* outdated
[08:25] <pitti> Unit193: do you know how to update that list?
[08:26] <ikonia> it's just a bot factoid
[08:26] <ikonia> it can be updated pretty easy
[11:15] <Mirv> 1.5h of waiting publisher run so far, doh.
[11:15] <pitti> yeah, the entirety of LP and the DC have felt like tar since ~ yesterday :/
[11:16] <ogra_> someone sitting on a cable ?
[11:17]  * pitti blames the brexit, apparently lost fast connections to the UK :)
[11:18] <ogra_> we should temporary redirect to the US then ... at least until trump is elected
[11:49] <JanC> why not move it to Germany instead?  :)
[11:50] <ogra_> :)
[11:52] <pitti> infinity: let there be Testsuite-Triggers: in britney! https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu/commit/?id=4d7522ddb8
[11:52] <pitti> apw: ^ you were interested in this as well
[11:59] <ogra_> adam is off this week
[12:04] <apw> pitti, i am interested indeed.  I assume this is going to let me suck some of the random lists out into my packages ?
[12:04] <pitti> apw: yes
[12:04] <apw> pitti, like the link between the kernel and lxc ?
[12:05] <pitti> apw: for example, we should now make lxc or lxd grow a test dependency on linux-libc-dev or linux-generic or similar
[12:05] <pitti> lxc *and* lxd
[12:06] <apw> pitti, so lxd would say Test-Triggers: foo in its main debian/control file and that would mean changes to package foo will trigger that package's tests
[12:07] <apw> s/that package/lxd
[12:07] <pitti> correct
[12:07] <pitti> except that you shouldn't really set T-T: manually; if not present it gets computed from debian/tests/control in a reasonable way
[12:07] <infinity> pitti: Oh, yeah.  I forgot about that part of the implementation.  Did you implement merging of T-T and tests/control?
[12:08] <infinity> pitti: Cause I disagree.  Setting artificial test deps to get them in T-T is wrong. :P
[12:08] <infinity> (Even if I just did it in glibc...)
[12:08] <pitti> infinity: no, that is not yet implemented, it's still the initial debian implementation
[12:08] <pitti> (also, that's dpkg again, not britney)
[12:08] <infinity> pitti: Yeah, I meant the dpkg implementation.  I didn't read it.
[12:09] <infinity> pitti: Definitely should be merging debian/control and debian/tests/control, IMO.
[12:09] <pitti> infinity: well, linux-generic is not conceptually an artificial test dependency -- so far it's just been an implied one
[12:09] <infinity> pitti: Feels "dirty" to put manual deps on build-essential packages just to get triggers.
[12:09] <apw> pitti, and how do i say "all valid kernels"
[12:10] <infinity> Triggering on all kernels is trickier.
[12:10] <infinity> Right now, it would just be "list them all".
[12:10] <pitti> yeah, you can't right now, unless they all build a common binary
[12:10] <infinity> pitti: Which they can't, for obvious reasons.
[12:10] <pitti> for linux-* in particular the code in britney is still necessary/easiesr
[12:11] <pitti> this will mostly help for everything !linux so far
[12:11] <pitti> we often get regressions which are due to a changed test dep
[12:11]  * apw goes back to being interested (rather than excited)
[12:11] <infinity> Heh.
[12:11]  * infinity goes back to being on vacation.
[12:12] <pitti> infinity: heh, do that; let's talk about details of merging T-T when you are back
[12:12] <infinity> pitti: *nod*
[12:12] <infinity> pitti: It's not urgent by any means.  If people choose to use the feature as it is, it works to put things in test-deps, and they can move them later if they feel the urge.
[12:12] <infinity> pitti: Mostly, I think it'll be "prettier" for essential and build-essential, basically.  But my taste isn't everyone's.
[12:13] <pitti> infinity: right now the goal is to trigger on the actual real test deps
[12:13] <infinity> pitti: Yeahp, but essential are deps of *all* tests, and build-essential is a magic dep.
[12:13] <pitti> we can *also* use this to reduce the hardcoded trigger lists in britney, but that's more of a side result
[12:13] <infinity> pitti: And if you want explicit testing when shadow changes, do you list shadow in your deps, or as a trigger in debian/control?
[12:13] <infinity> pitti: Both work, but the latter seems more "right".
[12:14] <pitti> infinity: you can set T-T: manually of course; you just (right now) lose the automatic value computed by dpkg
[12:14] <infinity> pitti: Or, in the glibc case, I have "build-essential, binutils, gcc, linux-libc-dev" (well, a bit more complex, but basically that) which is equally weird. ;)
[12:14] <pitti> infinity: but yes, if you explicitly test shadow, then adding shadow into d/t/c Depends: would do it
[12:15] <infinity> pitti: Right, I don't think it makes sense to set it manually until it merges.
[12:15] <infinity> pitti: But, as I said, people can just use test-deps and ignore T-T in debian/control entirely for now, so the feature works.
[12:15] <infinity> (Which is what I'm doing)
[12:16] <infinity> Off to find breakfast to fuel more vacation gaming.
[12:16] <infinity> Toodles.
[12:16] <pitti> apw: so to your question: "all linux kernels" isn't declarative, we always need a piece of code to answer that
[12:16] <pitti> apw: so I think this part will stay in britney for a while
[12:16] <pitti> (or forever)
[12:16] <infinity> apw: Yeah, I think the only way to make "all kernels" declarative would be to have an all kernels meta that pulls in all kernels for each platform. :P
[12:16] <infinity> Which probably isn't what you really want either.
[12:17] <infinity> Cause what you really want is to test foo-on-raspi2 *running* raspi2 on a raspi2 device.
[12:17] <infinity> Installing the raspi2 kernel in an lxc on a -generic device tells you nothing about runtime deps.
[12:17] <infinity> s/deps/tests/
[12:17] <infinity> Though it works for testing build-time dkms stuff, I guess.
[12:18] <infinity> apw: Like, ideally, we should sort out a way to run x86 tests twice, once with -generic installed and once with -lowlatency.
[12:19] <infinity> apw: And it just gets way trickier for ARM, cause we may also need to target kernel foo to worker bar to match hardware.
[12:19] <infinity> apw: Considerations for a future iteration. :P
[12:22] <pitti> infinity: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-autopkgtest-test-classes FYI
[12:22] <pitti> apw and I discussed/designed this a while ago, but it didn't get implemented yet
[12:25] <infinity> pitti: Fancy.  I will avoid reading it until next Tuesday. ;)
[14:22] <ddellav> can i get an archive admin to promote python-yaql and python-monascaclient to main please? There were approved MIR's but no promotion: https://bugs.launchpad.net/ubuntu/+source/python-yaql/+bug/1586069 https://bugs.launchpad.net/ubuntu/+source/python-monascaclient/+bug/1590836
[14:59] <kgunn> tjaalton: ping
[15:00] <kgunn> ug this network
[15:00] <kgunn> tjaalton: ping
[15:06] <brendand> is there anything i can do to allow nested vms when using adt-virt-qemu?
[15:06] <brendand> with autopkgtest
[15:22] <pitti> brendand: it should mostly Just Work™
[15:22] <brendand> pitti, the thing is i'm getting 'ERROR    Host does not support any virtualization options' from virt-install
[15:22] <pitti> brendand: as a convenience there is /dev/baseimage which is the (read-only) block device of the image you passed to autopkgtest-qemu
[15:24] <pitti> brendand: can you run "-- qemu -d ...]"? there should be some "Detected KVM capable Intel host CPU, enabling nested KVM" or similar for AMD
[15:36] <rbasak> kvm_intel.ko should be loaded. Or AMD equiv.
[15:43] <tjaalton> kgunn: pong
[15:44] <kgunn> tjaalton: hey there, so i'm trying to rebuild mesa on dragonboard
[15:45] <kgunn> tjaalton: if i use dpkg-buildpackage will gallium be built as a default?
[15:45] <kgunn> figured you might know
[15:46] <tjaalton> kgunn: i'm not sure, check rules
[15:46] <kgunn> k
[15:47] <tjaalton> or d/control, if it build-depends on it
[15:55] <tjaalton> uh.. it==llvm
[15:55] <rcj> pitti, looks like theres a kpartx regression in util-linux for 2.28.1-1ubuntu1 in yakkety bug# 1618525
[15:57] <kgunn> tjaalton: so from rules...it seems to suggest on arm64 it will build gallium
[15:59] <tjaalton> kgunn: right, iirc that was a fairly recent change
[15:59] <tjaalton> can't check atm
[16:00] <ddellav> Also if possible we need someone on the MIR team to promote designate: https://bugs.launchpad.net/ubuntu/+source/designate/+bug/1543748 It's passed it's security review
[16:00] <kgunn> tjaalton: no worries...thanks for pointers anyhoo
[16:01] <slangasek> infinity, kees, stgraber: tb meeting?
[17:29] <doko> seb128, Laney, tjaalton, Mirv: is there anything which should migrate to the release pocket before starting a test rebuild?
[17:30] <seb128> doko, not that I know of no...
[17:37] <Mirv> doko: yes http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src has the gold linker disabling for powerpc. there's no actions from Kubuntu side on the KDE autopkgtest issues, they nowadays usually ask to ignore those. I don't see anything terribly worrysome in there in those failures.
[17:39] <Mirv> while ignoring those, the qtdeclarative-opensource-src below would also migrate to release pocket which has two fixes already in stable phone images
[17:39] <doko> ok, waiting for these
[17:39] <Mirv> doko: those are not happening without overriding the autopkgtests though
[17:39] <Mirv> if any archive admin wouldn't mind ^
[17:40] <doko> jamespage, rbasak: anything you want to have in the release pocket from the server side before a test rebuild?
[17:40] <Mirv> so akonadi-calendar bluez-qt kalarmcal kdeclarative kglobalaccel libkdegames modemmanager-qt5 networkmanager-qt5  (and akonadi in the sense its s390x test seems stuck but is required)
[17:44] <acheronuk> I know yofel said we (kubuntu) simply don't have the resources ATM to address those failures
[17:46] <doko> Mirv: that's a release-team action, not an archive-team action. please could you ask on #ubuntu-release?
[17:51] <slangasek> Mirv: akonadi-calendar claims abi compliance checker passes on armhf and s390x but fails on x86 + ppc64el; would like to understand this failure to be sure it's really not an interface regression before overriding those failures
[17:52] <slangasek> bluez-qt is ok, non-ABI-changing symbol drop
[17:52] <slangasek> OTOH it's also easily fixed...
[18:01] <slangasek> Mirv: bluez-qt fix uploaded; the rest are all dh_acc regressions, which I would want to know the truth of before overriding
[18:02] <Mirv> doko: sorry, right
[18:03] <jamespage> ddellav, coreycb: hey ping me tomorrow and we'll go through the seed process for designate otherwise it will bounce straight back into universe
[18:03] <coreycb> jamespage, ok that'd be good to learn about
[18:03] <doko> slangasek, Mirv: when were these dh_acc regressions run?
[18:03] <Mirv> slangasek: thanks for the bluez-qt, I also saw that's easy one. I've asked on #kubuntu-devel and associated people were pinged. they are low on people who know about the autopkgtests (which are inherited from Debian) right now though.
[18:04] <Mirv> doko: I think the relevant time frame might be "after libc update"
[18:04] <Mirv> compared to the earlier build + autopkgtests which was after GCC6 but before libc6
[18:05] <doko> Mirv: if these were run with earlier versions than gcc-6 6.1.1-12 then please retry
[18:07] <Mirv> doko: looks like gcc-6 6.2.0-1ubuntu12 (and gcc 4:6.1.1-1ubuntu2)
[18:07] <doko> hmm, ok
[18:07] <Mirv> at least for akonadi-calendar
[18:07] <Mirv> anyway, I can't stay a moment longer now, see you in 10h
[18:09] <doko> I love it that dh_acc is soo verbose
[18:09] <doko> xnox: ^^^ ;-P
[18:09] <slangasek> doko: several times, as linked from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
[18:09] <xnox> there was one bug that i filed that dh_acc was failing on qt stuff.
[18:10] <xnox> i didn't debug the failures again after doko reverted "upstream fix" to unbreak dh_acc
[18:10] <xnox> there might be gcc leaked symbols in the dh_acc output that need updating....
[18:10] <slangasek> xnox: do you have a bug # for that?
[18:10] <doko> that could be too
[18:11] <xnox> the reverted upstream fix or the guess that there are gcc leaked symbols since that?
[18:11] <xnox> the latter is just a wild guess, based on previous abi migration
[18:11] <xnox> (note we don't have an abi migration this time around, apart from some cases when we do)
[18:11] <xnox> (because upstream "fixed" abi tags in templates resolutions...)
[18:12] <doko> no, the reversion is just a removed inline attribute. the original issue that such files are not built with GCC 6 is not yet fixed
[18:32] <slangasek> xnox: a bug # for what you filed about dh_acc failing on qt stuff...
[18:33] <xnox> doko, ah.
[18:34] <xnox> it was not the bug that i filed.... let me recall where it was, it was pointed out to me by mirv/doko or some such.
[18:36] <doko> xnox, slangasek: the upstream issue is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72813 (and the r198733 commit is now reverted in the packages)
[18:38] <xnox> and that's dh_acc with qt bug, beacause dh_acc uses that flag & qt things include atomic header eventually which fail to compile
[18:38] <doko> right, but that is now reverted
[20:12] <tjaalton> doko: I don't have anything
[20:17] <acheronuk> LP: #1609273
[20:17] <doko> tjaalton: ack
[20:28] <semiosis> bdmurray: adding test instructions to the bugs now
[20:29] <semiosis> bdmurray: done for bug 1565985
[20:30] <semiosis> bdmurray: bug 1561250 already has a pretty concise description with how to reproduce/test
[20:35] <bdmurray> semiosis: sudo echo is the testcase for bug 1561250?
[20:35] <semiosis> sudo anything
[20:35] <bdmurray> okay, cool
[20:35] <semiosis> sudo does a localhost lookup, apparently
[20:35] <sarnold> lol "see the error ^^^^"
[20:36] <semiosis> s/localhost/current hostname/
[20:37] <semiosis> and how am I now able to edit the descriptions of those bugs I did not create?  did someone grant me that authority?
[20:37] <bdmurray> anybody can edit bug descriptions
[20:37] <semiosis> oh ha!  never noticed that
[20:53] <tdaitx> what are the usual suspects on a "Build killed with signal TERM after 150 minutes of inactivity"?
[20:53] <tdaitx> Some context: sometimes openjdk builds fail during the build and while I can see make's message "recipe for target blah/blah failed" + "dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2" on the ppa's build page the build isn't killed right away... While I can reproduce the failure itself, I am unable to reproduce this hang+timeout on a sbuild/chroot build, so I wonder where I should be looking into
[20:54] <tdaitx> slangasek, infinity, xnox, pitti ^ are you somewhat familiar with this?
[21:06] <cjwatson> tdaitx: That indicates that your build left a stale process behind that we didn't manage to clean up.
[21:06] <cjwatson> tdaitx: launchpad-buildd (unfortunately) currently uses sbuild in sudo mode, which isn't quite as good at cleaning up processes as the more usual schroot mode is.
[21:07] <cjwatson> tdaitx: I'd suggest instrumenting debian/rules to dump a process tree on error, at which point you should be able to see what's going on locally.
[21:07] <tdaitx> cjwatson, right, I will try that way then, thanks! =)
[21:15] <robert_ancell> slangasek, hey, who do I need to bribe to let snapd-glib into yakkety?
[21:15] <slangasek> robert_ancell: I take bribes
[21:16] <slangasek> robert_ancell: and I've been working through the NEW queue slowly ;)
[21:17] <robert_ancell> slangasek, it's gone up a bit in priority since we're going to need it to solve bug 1616943 properly
[21:17] <robert_ancell> i.e. will need to be SRUd back to Xenial
[21:18] <slangasek> ok
[21:18] <robert_ancell> slangasek, thanks
[21:19] <robert_ancell> slangasek, and a heads up, I'm currently finishing a new binary package for it "snapd-login-service" and once we're happy with the API I'll do a soname bump. Both of which will need archive admin approval right?
[21:20] <slangasek> yes
[21:21] <slangasek> binary review tends to be lighter weight though
[21:51] <robert_ancell> A question about multi-arch. I have a package (snapd-glib) that provides a library and a service. When I build the package the service is installed into /usr/lib/x86_64-linux-gnu/snapd-login-service but I get the lintian warning "E: snapd-login-service: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/snapd-login-service"
[21:51] <robert_ancell> Should I ignore the warning or should I change something in my packaging?
[21:51] <robert_ancell> Packaging in lp:~ubuntu-desktop/snapd-glib/ubuntu if anyone is interested
[21:52] <robert_ancell> (The service is installed into $(libexecdir) via autotools)
[22:25] <slangasek> robert_ancell: maybe you want to build with --libexecdir=/usr/lib ?  I apologize for getting the default wrong in debhelper when adding multiarch support originally
[22:25] <robert_ancell> slangasek, that's what I was wondering. I noticed a number of packages seem to not be setting this. But if this is the correct behaviour I'll switch to that.
[22:56] <slangasek> robert_ancell: please use the current debian/copyright spec, Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[22:56] <robert_ancell> slangasek, ok
[22:56] <robert_ancell> My copy-pasting is caught out again! ;)
[22:56] <slangasek> robert_ancell: also, what does it mean when you say 'License: LGPL-2 LGPL-3'?
[22:56] <slangasek> the same code is made available under either license?
[22:57] <robert_ancell> slangasek, yeah, that's what we ended up doing for liblightdm-gobject for some reason.
[22:57] <slangasek> robert_ancell: ok.  standard syntax would be 'LGPL-2 or LGPL-3', then
[22:57] <robert_ancell> And I just copied the same. I couldn't find our licence policy on the Wiki
[22:57] <robert_ancell> ok
[22:57] <slangasek> LDFLAGS+=-Wl,--as-needed
[22:57] <slangasek> not needed in Ubuntu
[22:58] <Unit193> slangasek: Might want to https that link, or lintian will give a warning.
[22:58] <slangasek> curiously, lintian didn't care about the http pointing to a wrong url ;)
[22:58] <robert_ancell> slangasek, has anything changed in the spec or is just the link wrong?
[22:59] <slangasek> robert_ancell: the spec has likely changed since the svn rev you reference, yes - and lintian will then tell you about it :)
[22:59] <robert_ancell> slangasek, lintian was only giving me that one warning about the libexec issue here
[23:00] <slangasek> robert_ancell: yeah, because non-standard debian/copyright is allowed... but if you use the standard it'll do much more analysis
[23:00] <robert_ancell> ah
[23:00] <slangasek> robert_ancell: anyway, none of these are blockers, so 0.8-0ubuntu1 source accepted
[23:01] <robert_ancell> slangasek, thanks! I'm prepping 0.10-0ubuntu1 right now and it will have those fixes.