[05:32] <cpaelzer> good morning
[06:02] <sarnold> pitti: 1587727 (man that was quick :)
[06:16] <karstensrage> #1587727
[06:52] <pitti> sarnold: yep, known already :)
[06:52] <pitti> sarnold: I clearly don't visit the right web sites :) (I get a crash with www.facebook.com which I never use, for example)
[06:52] <sarnold> pitti: aha, good :) I thought you mentioned getting errors for it, wanted to make sure
[06:53] <sarnold> pitti: hehehehehe
[06:53] <pitti> Good morning
[06:53] <sarnold> good morning ;)
[07:47] <apw> pitti, i am not mad in thinking that we (at least) tried to make python3 the one and only python for xenial and up?
[07:47] <pitti> apw: correct, we've been trying for a loong time
[07:47] <pitti> apw: I think we actually succeeded on the server image? (at least for some time, maybe it came back)
[07:48] <pitti> ah no, python2.7 is still on http://releases.ubuntu.com/xenial/ubuntu-16.04-server-amd64.list
[07:48] <apw> pitti, but it would be a reasonable statement that it would be wrong introducing new python2 dependancies, that they should be python3
[07:48] <apw> pitti, for xenial/yakkety
[07:49] <pitti> right
[07:49] <pitti> every such case throws us back
[07:49] <sarnold> did desktop make it?
[07:49] <sarnold> I thought something did :)
[07:49] <apw> yeah i did too :)
[07:49] <pitti> I think we managed to get rid of it on the cloud images
[07:50] <pitti> no py2.7 there
[07:50] <pitti> desktop still has it
[07:51] <sarnold> I thught cloud-init was still python 2.. http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/bin/cloud-init uses #!/usr/bin/python   anway...
[07:59] <apw> pitti, on systemd ... who supplied the resolvconf integration service ?
[08:00] <pitti> apw: for networkd you mean? that was me
[08:00] <pitti> and yes, it's horrible
[08:00] <apw> pitti, yeah for networkd ... ok i think it may be flawed
[08:01] <apw> it seems (and i may be doing it wrong) if i tell networkd about a DNS server which is specific to a domain
[08:01] <apw> we shove that domain into /etc/resolv.conf and that then feeds back into resolved which sees /etc/resolv.conf updated
[08:01] <apw> so it becomes a (indeed the) primary DNS
[08:02] <pitti> apw: indeed, good point; so we need to look at whether the entry has Domains= as well, I figure, and then not supply it?
[08:03] <pitti> apw: networkd already sends its DNS info to resolved anyway
[08:03] <pitti> apw: this was mostly a shim for people using networkd without resolved
[08:07] <apw> pitti, it is utterly unclear how that file is to be interpreted (other than telling you it should not :)
[08:09] <apw> pitti, cirtainly it _is_ reporting in there that there is DNS but there is ROUTE_DOMAINS= in there as well, but i don't have enough configuration via networkd to know what it would look like if my primary DNS was configured in here
[08:09] <apw> pitti, do you know how to do that so perhaps i can at least fake it
[08:09] <pitti> apw: hang on, I'm trying in a VM (not using networkd on my desktop, or anywhere permanent)
[08:10] <apw> pitti, oh you meany, making me use it :-p
[08:10] <pitti> when did I? :-)
[08:10] <apw> when you uploaded it to yakkety :)
[08:11] <apw> well the resolved bits anyhow
[08:11] <apw> as resolved gets half its config from networkd because thats not a layering violation
[08:12]  * pitti doesn't understand these three comments, sorry
[08:13] <pitti> apw: so for a global DNS server, you just get DNS= and OPER_STATE=, no other fields
[08:13] <apw> i am trying to configure resolved which we switched to using, to do that i _have_ to configure networkd because that part of resolved configuration is stored only in files networkd also reads
[08:13] <apw> pitti, and if you have both ?
[08:13] <pitti> apw: so I think we must make /lib/systemd/system/systemd-networkd-resolvconf-update.service ignore files which have ROUTE_DOMAINS
[08:13] <pitti> as these just can't be handled via glibc
[08:13] <pitti> /etc/resolv.conf simply lacks syntax for this
[08:14] <apw> that seems appropriate to me
[08:24] <pitti> apw: do you want to file a bug about it to track it, or want me to?
[08:25] <pitti> (we might eventually need to port this fix to xenial, if anyone decides to start using networkd there)
[08:25] <sarnold> pitti: btw what are we going to do with the KillUserProcesses thing? it apparently didn't go over well on fedora when upstream flipped it..
[08:26] <pitti> sarnold: it's reverted in 230-2, which is sitting in y-proposed
[08:26] <pitti> this first attempt clearly didn't go well
[08:26] <sarnold> pitti: woot :) thanks
[08:26] <pitti> now we're getting flak from the other side for disabling it again :)
[08:26] <pitti> sarnold: but I think this needs to be re-thought
[08:26] <sarnold> figures
[08:26] <pitti> sarnold: one recent proposal that I've seen is to use SIGHUP instead of SIGKILL
[08:26] <sarnold> it's a nice feature to have available but to turn on by default seems a pretty drastic change
[08:27] <pitti> which DTRT with tmux and screen (they stay running), but should still clean up gnome leftovers
[08:27] <sarnold> that's way more unixy :)
[08:28] <sarnold> nohup exists for applications that just inherit, applications which care can handle it ..
[08:30] <apw> pitti, i'll file a bug now and have a look
[08:38] <cpaelzer> pitti : is there a ppa for autopkgtest to get adt-buildvm-ubuntu-cloud for yakkety images working on a Xenial system?
[08:38] <pitti> cpaelzer: not a PPA, but it's in xenial-backports (and trusty-backports too)
[08:39] <pitti> cpaelzer: but it's still not working very well, I filed bug 1587188 yesterday
[08:39] <pitti> i. e. the generated images have a horribly small root partition, so only small tests actually work
[08:39] <cpaelzer> pitti: ah, your update is so recent I just don't have it got yet via backports - thanks for making me aware of the follow on issue
[08:40] <pitti> not entirely sure if that's actually in cloud-init, or a regression in how we build the cloud images themeselves, though
[08:40] <pitti> cpaelzer: oh, wait, which fix do you mean?
[08:40] <pitti> cpaelzer: oh, the renamed images, I see
[08:40] <cpaelzer> pitti: I was looking for the one with the name change loosing -disk1
[08:41] <pitti> that fix is in 3.20.7
[08:41] <cpaelzer> yeah that is why I started looking for a ppa, but backports is fine
[08:41] <pitti> cpaelzer: I'm going to upload 3.20.8 to sid now, and as soon as this autosyncs, I'll backport it to t and x
[08:41] <pitti> 3.20.7 just landed in testing
[08:41] <apw> pitti, bug #1587762
[08:42] <pitti> cpaelzer: in the meantime, just locally apply http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=6676ed6ea
[08:42] <pitti> cpaelzer: and the next time you'll get a package upgrade that will include the fix
[08:42] <cpaelzer> pitti: I almost edited that lone myself before starting to think you likely fixed that already
[08:43] <cpaelzer> pitti: thanks, I'll give the cloudinit bug at least a few minutes - maybe I can find something there for us
[08:45] <cpaelzer> the probably easiest way to get fixes early until released is pull-lp/debian-source and then run with full path like /tmp/autopkgtest-3.20.7/tools/adt-buildvm-ubuntu-cloud
[08:45] <cpaelzer> somewhat nicer than to patch the real system :-)
[08:46] <pitti> cpaelzer: just run it out of git :)
[08:46] <pitti> cpaelzer: that's what I do in production
[08:47] <cpaelzer> +1 evil overlord points for pitti for "run it out of git in production"
[08:47] <pitti> well, if I do a fix I don't want to wait a day before I can roll it out, people need it NOW :)
[08:48] <pitti> and while autopkgtest's tests are annoying (they take ~ 30 mins), they are also rather effective at guarding against regressions
[08:49] <pitti> and even then, git reset --hard HEAD^, and life goes on
[08:52] <apw> pitti, cna i use awk in this context, rather than sed?
[08:52] <pitti> apw: sure, as long as it gets along with mawk
[08:53] <pitti> apw: btw, it might be easier to actually not run this horrible thing at all if resolved is being used
[08:53] <pitti> apw: this is a shim for using networkd without resolved, but with resolvconf and software that uses /etc/resolv.conf directly
[08:53] <pitti> it's not needed for anything else
[08:54] <apw> yeah that makes sense, is there an easy way to tell that ?
[08:54] <mwhudson> i'm trying to use sbuild to build an i386 package on my laptop and it's complaining about
[08:54] <mwhudson>  sbuild-build-depends-core-dummy:amd64 : Depends: crossbuild-essential-amd64:i386 but it is not installable
[08:55] <apw> mwhudson, are you building that in a amd64 chroot or something ?
[08:55] <mwhudson> i'm confused, i don't think i need or what any cross building nonsense here
[08:55] <pitti> apw: first iteration is to add "ConditionPathExists=!/run/systemd/resolve" to /lib/systemd/system/systemd-networkd-resolvconf-update.path
[08:55] <mwhudson> apw: i made it with mk-sbuild --arch i386 yakkety so i hope now
[08:55] <mwhudson> *not
[08:56] <mwhudson> and $ schroot -c yakkety-i386 --directory / -- uname -m
[08:56] <mwhudson> i686
[08:58] <apw> yep that looks believeable
[08:58] <mwhudson> ah passing --build i386 --host i386 is happier
[08:59] <mwhudson> or indeed --arch i386
[09:00] <apw> pitti, so without the other fix or with that together
[09:00] <apw> pitti, as i am assuming that will fix my issues completely
[09:01] <mwhudson> does anyone happen to know the incantation to get the filet to make --extra-repository-key=file.asc work for a ppa?
[09:01] <mwhudson> i'm sure i can figure it out but...
[09:02] <pitti> apw: right, if you don't run this unit at all, it'll fix things for you
[09:02] <pitti> apw: I'm just not sure whether we can get away with this
[09:04] <apw> pitti, well i have done the other bit too, i'll add a diff to the bug
[09:04] <apw> pitti, then we can think about the test
[09:04] <pitti> apw: cheers
[09:05] <pitti> apw: I'll write that (before applying the patch)
[09:05] <pitti> apw: still battling with armhf lost autopkgtests and infra, getting to this later
[09:08] <apw> pitti, no rush at all
[09:08] <apw> pitti, and this way i can hand apply the fix and see if it works in practice
[09:09] <mwhudson> hm apparently that option just doesn't work?
[09:12] <mwhudson> or doesn't do what i think
[09:12] <mwhudson> hacked around, anyway
[09:13] <juliank> pitti: bug 1569099 got a verification-needed, but that does not make much sense, it's a duplicate of bug 1560797 which is already closed in xenial with the same commit.
[09:15] <apw> pitti, ok patch attached and cowboy'd onto my machine ... seems to be working at least for now
[09:16] <juliank> Anyway, what is missing for the apt SRU to be moved to -release? From what I see in bug 1538438, that one should be fixed, but still verification-needed. And bug 1580952 has verification-needed, but no test case, as it's a new-micro-release-type-SRU
[09:17] <pitti> juliank: for xenial you mean? nothing, but until yesterday it didn't age for 7 days yet; today it's fine
[09:17] <juliank> Ah OK
[09:18] <pitti> juliank: sorry, that was for wily
[09:18] <pitti> juliank: which refers to bug 1575877 which is v-done and 7 days now
[09:18]  * pitti releases
[09:18] <juliank> Yeah, xenial was uploaded 2016-05-12
[09:18] <juliank> so it's far beyond schedule
[09:19] <pitti> juliank: look at http://people.canonical.com/~ubuntu-archive/pending-sru.html
[09:19] <pitti> juliank: the dupe bug is striked through, so irrelevant; but the two other bugs weren't verified, and it's not fixed in yakkety
[09:20] <juliank> Eww, and some autopkgtest regressions
[09:20] <pitti> i. e. bug 1538438 (not fixed in y, not verified), and bug 1580952 (missing test case, not verified)
[09:21] <juliank> pitti: Oops,  the first is fixed in yakkety
[09:22] <juliank> 1.2.12 is the bugfix cherry-pick of 1.3~exp1 in yakkety
[09:23] <juliank> The autopkgtests are strange, but unrelated it seems: sbuild fails with "E: Unable to find a source package for procenv" and apport with "https://launchpad.net/ubuntu/+archive/primary/+files/libacl1-dbgsym_2.2.52-3_i386.ddeb gnutls_handshake() failed: The TLS connection was non-properly terminated."
[09:24] <rbasak> pitti: I'm sure I've asked you this before, but I can't find a reference right now. systemd is hiding errors from postinst invoke-rc.d, and as a result it doesn't end up in bug reports. Can we amend apport to provide it in the general case?
[09:24] <rbasak> pitti: example: bug 1587695
[09:24] <rbasak> pitti: perhaps on invoke-rc.d failure, invoke-rc.d should automatically dump "systemctl status" to stderr?
[09:24] <rbasak> Or else, I'd like some other way for apport to pick it up.
[09:25] <pitti> juliank: right, the apport one is a glitch, I'll retry
[09:26] <juliank> pitti: Yes, and the sbuild one also happens in the most recent build with apt 1.2.10ubuntu1
[09:26] <pitti> juliank: sbuild, this also apparently happesn with the xenial-release apt, as it also failed for the proposed dpkg: http://autopkgtest.ubuntu.com/packages/s/sbuild/xenial/amd64/
[09:26] <juliank> yeah
[09:26] <pitti> so something definitively broke this, but not the new apt
[09:28] <juliank> pitti: What to verify about bug 1580952? I don't think this makes a whole lot of sense there.
[09:29] <pitti> I suggested "Please add an SRU test case which exercise the code paths that changed here."
[09:29] <juliank> It's a "New upstream microrelease" with test cases in it.
[09:29] <pitti> maybe at least some small test plan with installing/upgrading various packages, downloading a source, etc.
[09:29] <pitti> to make sure it'snot completely broken
[09:29] <pitti> right, that too
[09:32] <juliank> I mean, the autopkgtests check all those things in an automated integration test case fashion, and users apparently use it successfully (at least the one who checked that no_proxy worked correctly), so...
[09:34] <pitti> juliank: ok, agreed
[09:37] <pitti> juliank: I updated the two bugs
[09:37]  * pitti releases
[09:37] <juliank> Yay!
[09:37] <pitti> juliank: thanks for the updates
[09:39] <juliank> pitti: I already started queuing (currently 2) commits for 1.2.13! :) - should arrive in a few weeks. Especially fancy ones like "fail instead of segfault on unreadable config files" and the easy "Provide complete apt bash completion"
[09:40] <juliank> I'm trying to get more translations in as well, but the merge gets confusing (anyone knows a .po merge helper?)
[09:40] <pitti> juliank: msgmerge ?
[09:41] <pitti> rbasak: hm, no amavis messages in https://launchpadlibrarian.net/262668434/JournalErrors.txt, so I'm not sure if that'd actually help
[09:41] <juliank> Hmm, yeah, https://stackoverflow.com/questions/16214067/wheres-the-3-way-git-merge-driver-for-po-gettext-files says we can build a 3 way merge driver with that
[09:41] <pitti> rbasak: might be that this is a forking service which only outputs to log files, not to stdout/err?
[09:42] <pitti> rbasak: ah, wait, this only shows messags with priority >= warning, so maybe that's why
[09:42] <pitti> rbasak: yeah, I guess we can amend the ubuntu hook for package failures to include the status
[09:43] <pitti> apw: nice fix! (I'd just do s/routable/route_domains/)
[09:43] <rbasak> pitti: thanks. I could see you were busy on something else so I filed bug 1587791 so as not to forget.
[09:43] <pitti> thanks
[09:44] <pitti> rbasak: yeah, sorry; still working on some test infra fallout
[09:44] <rbasak> pitti: np. I'd like to see this fixed (will save us bug triaging time) but it's hardly urgent.
[09:47] <apw> pitti, yeah makes more sense feel free to hack her up ;)
[10:24] <pitti> tinoco, xnox: aupkg02 (10.100.0.13) is down again; can you please prod it?
[10:28] <tseliot> pitti: aptdaemon can't be installed in yakkety, any ideas? https://launchpadlibrarian.net/262720256/buildlog_ubuntu-yakkety-amd64.ubuntu-drivers-common_1%3A0.4.19_BUILDING.txt.gz
[10:29] <pitti> tseliot: because of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#packagekit, the proposed version is incompatible
[10:29] <pitti> see bug 1496292
[10:31] <tseliot> pitti: ok, so it is a known issue. I need to backport some code from u-d-c to xenial (to give back about 1 second on boot), so I'll just ignore yakkety for now
[10:45] <cpaelzer> pitti: the resizing issue you reported is actually in cloud-utils, I created a MP for smoser to consider - details in the bug
[10:46] <cpaelzer> that said back to what I actually wanted to do ... or lunch :-)
[10:47] <pitti> cpaelzer: yay, you figured it out? thanks!
[11:26] <caribou> Locu
[11:26] <caribou> oups, sorry
[11:30] <cpaelzer> pitti: just verified, 'til the fix hits the archive booting into the adt guest with your vm script and running "sudo resize2fs /dev/vda1" gets you images to work with for now
[11:32] <pitti> cpaelzer: greaet
[13:15] <cpaelzer> pitti: I was happy too early about the yakkety adt now being fine a few hours before
[13:15] <cpaelzer> the disk size is good now but something (tm) crashes it now
[13:15] <cpaelzer> do you have any notes / best practise on debugging adt-run / adt-virt-qemu?
[13:16] <cpaelzer> with all debug enabled I see it booting fine, but then kill the qemu by a sig 15 when executing "adt-virt-qemu: DBG: execute-timeout: /tmp/adt-virt-qemu.7vsnggp9/runcmd true"
[13:16] <cpaelzer> if it is a timeout it is rather fast - like 2 seconds :-)
[13:20] <pitti> cpaelzer: should be 5 s
[13:20] <pitti> cpaelzer: hm, and that's with the PYTHONHASHSEED=0 hack already?
[13:21] <pitti> as this has this very symptom
[13:23] <cpaelzer> pitti: I'll build from git as you do and let you know if anything in there fixes my issue
[13:23] <cpaelzer> pitti: do I need to recreate the guest images to pick up the change?
[13:30] <pitti> cpaelzer: shouldn't be necessary really
[13:32] <cpaelzer> pitti: yeah - out of git is good, thanks
[13:33] <pitti> cpaelzer: which version do you have installed? 3.20.7?
[13:33] <mitya57> sil2100, hi, do you have any thoughts @ https://code.launchpad.net/~mitya57/appmenu-qt5/lp1574699/+merge/294381 ?
[13:33] <pitti> cpaelzer: aside from the image rename I don't see a relevant change since 3.20.6
[13:34] <cpaelzer> pitti: started with 3.20.4, then used 3.20.7 for the image create, but back to .4 for run
[13:34] <cpaelzer> pitti: now I just switched to git to stay ahead just as you do
[13:34] <pitti> cpaelzer: .4 won't work, that doesn't have the PYTHONHASHSEED hack
[13:34] <pitti> cpaelzer: you need >= .5 for running yakkety images
[13:34] <pitti> cpaelzer: this hack applies to adt-run time, not to image creation time
[13:35] <cpaelzer> which is why the adt-run out of git now got it working
[13:35] <cpaelzer> good
[13:35] <pitti> right
[13:35] <pitti> 3.20.8 is uploaded to sid, but it'll take another half day or so to land in yakkety;  I'll backport it tomorrow
[13:36] <pitti> infinity, sarnold: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd is just landing
[13:36] <pitti> with the unkill change
[14:00] <tumbleweed> cjwatson: I've hit something that feels very much like https://bugs.debian.org/708123 in an upgrade from 12.04 to 14.04 (and then we went to 16.04)
[14:01] <tumbleweed> I'll grab an image of it and muck around in qemu
[14:03] <cjwatson> cyphermox: ^- can you deal with that?
[14:05] <cyphermox> ack
[14:05] <cyphermox> tumbleweed: filed a bug?
[14:06] <tumbleweed> I was wondering what you'd want to look at
[14:06] <tumbleweed> I'm going to start by trying to upgrade the metadata in a VM copy of it
[14:11] <tumbleweed> symptoms are: rescue prompt shows no md devices, one has to boot it off a raid member
[14:11] <tumbleweed> and the raid modules all seem to be present
[14:40] <tumbleweed> also, rescue mode seems racy :P
[15:38] <ginggs> sil2100: hi, can you rebuild mtp for yakkety please? it still depends on boost from xenial
[15:41] <sil2100> ginggs: hey! Ok, no-change rebuild on its way
[15:42] <ginggs> sil2100: thanks!
[15:50] <sil2100> ginggs: hm, strange that it deps on the old boost still, I did a no-change rebuild of it on the 20th of May already
[15:53] <ginggs> sil2100: mtp (0.0.4+16.04.20160413-0ubuntu2) xenial; urgency=medium  <= distribution is xenial
[15:54] <ginggs> Copied from ubuntu xenial in Stable Phone Overlay PPA by Ubuntu Archive Auto-Sync <= this sounds weird to me
[16:01] <sil2100> ginggs: ah, right, my bad - I guess the rebuild didn't happen in the end
[16:02] <sil2100> Thanks :)
[16:35] <pitti> hallyn: demoting cgmanager to universe for now, as per http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[16:36] <pitti> hallyn: only the binary for now; we still have a few rdepends of the library in main, like upstart and ubuntu-core-libs
[16:36] <pitti> hallyn: is cgmanager still actually a thing which we want to support, or is that being phased out in favor of lxcfs etc?
[16:41] <mterry> @pilot in
[16:42] <flaiks> is there a way to get kernel 4.6 running on 16.04 ? i need it for a required fix for my t460s
[16:42] <ikonia> flaiks: we just discussed this
[16:43] <mapreri> what usually people do in ubuntu when a package ftbfs in one arch for reason nobody can't get? — are partial removals a thing?
[16:43]  * mapreri is looking at cowdancer
[16:43] <ikonia> thats not what this channel is for,
[16:43] <ikonia> flaiks: the support channel is #ubuntu
[16:46] <jrwren> ikonia: try #ubuntu-kernel you migth also ask if the patch that you see in 4.6 has been backported to the ubuntu 4.4 kernel
[16:46] <ikonia> jrwren: not for me, but thank you, it's not been backported for the record for flaiks
[16:47] <dobey> mapreri: i usually fix the problems, in my packages
[16:47] <jrwren> ikonia: sorry. I meant to direct taht to flaiks
[16:47] <mapreri> dobey: "for reason nobody can't get" implies we 1/ can't figure out the problem 2/ can't reproduce it 3/ in debian just builds.
[16:48] <mapreri> would be awesome if you can look at it and see if you can make it out! ♥
[16:48] <ikonia> jrwren: not a problem at all
[16:49] <mapreri> not having porterboxes available doesn't really help either (the actual maintainer tried in qemu but no luck)
[16:54] <hallyn> pitti: phased out
[16:57] <dobey> mapreri: well i don't know enough about the code and its memory model, but it would appear that the memleak test is failing for some reason. i see in the shell script for that test a comment about LD_PRELOAD causing a memleak, so perhaps related?
[16:57] <cjwatson> mapreri: Partial removals are certainly possible, though we prefer to avoid the cop-out option if at all possible :)
[16:58] <cjwatson> mapreri: worth trying with -O2
[16:58] <cjwatson> mapreri: (the "obvious" difference between Debian and Ubuntu that's ppc64el-specific is that Ubuntu's toolchain defaults to -O3 on ppc64el)
[16:59] <cjwatson> so DEB_MAINT_CFLAGS_STRIP := -O3 and DEB_MAINT_CFLAGS_APPEND := -O2 or equivalent
[16:59] <mapreri> interesting.
[16:59] <mapreri> (didn't know it)
[16:59] <cjwatson> mapreri: you can try it in a PPA
[16:59] <mapreri> ya
[17:00] <cjwatson> err s/DEB_MAINT_CFLAGS/DEB_CFLAGS_MAINT/g
[17:00] <dobey> ah yeah, that makes sense given that it's memory related
[17:07] <mapreri> i wanted to try, before that, a no change rebuild in a ppa: https://launchpad.net/~mapreri/+archive/ubuntu/ppa/+build/9845065 — it bult..
[17:08] <mapreri> could be related for it being virtualized?
[17:08] <cjwatson> mapreri: virt/non-virt makes no difference for ppc64el
[17:08] <cjwatson> so let's try just retrying that build
[17:09] <cjwatson> of course it could be non-deterministic
[17:10] <mapreri> - failed
[17:12] <mapreri> cjwatson: any other suggestion? :)
[17:12]  * mapreri would be very happy to have it building!
[17:15] <mapreri> i have to go out for some hours now, but please do feel free to dump ideas (or even try out stuff!)
[17:19] <cjwatson> mapreri: -O2 would definitely be my next suggestion
[17:20] <cjwatson> also diff build logs and see if that throws up anything (though I don't immediately spot anything very obvious)
[17:29] <mterry> seb128, so are we OK with switching packages to geoclue-2.0?  Did we ever find an actual solution for them?  (I see that empathy got switched to 2.0)
[17:31] <seb128> mterry, yeah, see the migration bug, seems like robert_ancell fixed our geoip server to talk the same api that google/mozilla use
[17:31] <dobey> mterry: is this where you end up having to write a backend for geoclue-2.0 that uses ubuntu-location-service?
[17:31] <seb128> which makes it compatible with geoclue2
[17:31] <seb128> mterry, https://code.launchpad.net/~robert-ancell/canonical-is-puppet/geolocation-api/+merge/296077
[18:56] <mterry> cyphermox, in bug 1585863, $4 suggested modifying a network-manager patch of yours -- basically dropping your changes to src/supplicant-manager/nm-supplicant-interface.c -- can you comment there?  I was about to sponsor it, but wasn't sure I knew what the deal was there
[19:11] <mterry> @pilot out
[19:45] <brainwash> is pkexec broken? pkexe whoami  gives me:
[19:46] <brainwash>  polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
[19:50] <brainwash> pkcheck --list-temp --> Error getting session: No session for pid <PID>
[20:19] <mapreri> cjwatson: is the version of sbuild used for the primary archive builds and for the ppa builds the same?  I see weird differences in the output like this (just curiosity):
[20:19] <mapreri> [-PWD=/«PKGBUILDDIR»-] {+PWD=/«BUILDDIR»/cowdancer-0.80+ppa0+}
[20:19] <mapreri> (this is the diff, for completeness: https://volatile.mapreri.org/2016-06-01/821944dc8105ba888c8857b2cacb7737/diff.html )
[20:20] <mapreri> (actually, is the full logs dwdiffed)
[21:21] <cjwatson> mapreri: Yes, it's the same; congratulations, you've found an sbuild bug to do with + handling
[21:21] <mapreri> ahahahah \o/
[21:22] <mapreri> cjwatson: bug in which it can't correctly compute PKGBUILDDIR and sed it over the build log?
[21:23] <cjwatson> indeed
[21:23] <cjwatson> probably needs to quote a regex harder
[21:30] <pitti> hallyn: ok, thanks; I figure ubuntu-app-launch and ubuntu-core-libs will need some work then, but systemd-shim is gone already
[23:21] <mwhudson> does anyone have a script for doing a no-change rebuild of a package in a ppa?