=== juliank_ is now known as juliank [05:32] good morning [06:02] pitti: 1587727 (man that was quick :) [06:16] #1587727 [06:52] sarnold: yep, known already :) [06:52] 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] pitti: aha, good :) I thought you mentioned getting errors for it, wanted to make sure [06:53] pitti: hehehehehe [06:53] Good morning [06:53] good morning ;) [07:47] 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] apw: correct, we've been trying for a loong time [07:47] apw: I think we actually succeeded on the server image? (at least for some time, maybe it came back) [07:48] ah no, python2.7 is still on http://releases.ubuntu.com/xenial/ubuntu-16.04-server-amd64.list [07:48] pitti, but it would be a reasonable statement that it would be wrong introducing new python2 dependancies, that they should be python3 [07:48] pitti, for xenial/yakkety [07:49] right [07:49] every such case throws us back [07:49] did desktop make it? [07:49] I thought something did :) [07:49] yeah i did too :) [07:49] I think we managed to get rid of it on the cloud images [07:50] no py2.7 there [07:50] desktop still has it [07:51] 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] pitti, on systemd ... who supplied the resolvconf integration service ? [08:00] apw: for networkd you mean? that was me [08:00] and yes, it's horrible [08:00] pitti, yeah for networkd ... ok i think it may be flawed [08:01] 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] we shove that domain into /etc/resolv.conf and that then feeds back into resolved which sees /etc/resolv.conf updated [08:01] so it becomes a (indeed the) primary DNS [08:02] 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] apw: networkd already sends its DNS info to resolved anyway [08:03] apw: this was mostly a shim for people using networkd without resolved [08:07] pitti, it is utterly unclear how that file is to be interpreted (other than telling you it should not :) [08:09] 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] pitti, do you know how to do that so perhaps i can at least fake it [08:09] apw: hang on, I'm trying in a VM (not using networkd on my desktop, or anywhere permanent) [08:10] pitti, oh you meany, making me use it :-p [08:10] when did I? :-) [08:10] when you uploaded it to yakkety :) [08:11] well the resolved bits anyhow [08:11] 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] apw: so for a global DNS server, you just get DNS= and OPER_STATE=, no other fields [08:13] 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] pitti, and if you have both ? [08:13] apw: so I think we must make /lib/systemd/system/systemd-networkd-resolvconf-update.service ignore files which have ROUTE_DOMAINS [08:13] as these just can't be handled via glibc [08:13] /etc/resolv.conf simply lacks syntax for this [08:14] that seems appropriate to me [08:24] apw: do you want to file a bug about it to track it, or want me to? [08:25] (we might eventually need to port this fix to xenial, if anyone decides to start using networkd there) [08:25] 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] sarnold: it's reverted in 230-2, which is sitting in y-proposed [08:26] this first attempt clearly didn't go well [08:26] pitti: woot :) thanks [08:26] now we're getting flak from the other side for disabling it again :) [08:26] sarnold: but I think this needs to be re-thought [08:26] figures [08:26] sarnold: one recent proposal that I've seen is to use SIGHUP instead of SIGKILL [08:26] it's a nice feature to have available but to turn on by default seems a pretty drastic change [08:27] which DTRT with tmux and screen (they stay running), but should still clean up gnome leftovers [08:27] that's way more unixy :) [08:28] nohup exists for applications that just inherit, applications which care can handle it .. [08:30] pitti, i'll file a bug now and have a look [08:38] pitti : is there a ppa for autopkgtest to get adt-buildvm-ubuntu-cloud for yakkety images working on a Xenial system? [08:38] cpaelzer: not a PPA, but it's in xenial-backports (and trusty-backports too) [08:39] cpaelzer: but it's still not working very well, I filed bug 1587188 yesterday [08:39] bug 1587188 in cloud-init (Ubuntu) "[yakkety regression] does not grow partition any more" [Undecided,New] https://launchpad.net/bugs/1587188 [08:39] i. e. the generated images have a horribly small root partition, so only small tests actually work [08:39] 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] not entirely sure if that's actually in cloud-init, or a regression in how we build the cloud images themeselves, though [08:40] cpaelzer: oh, wait, which fix do you mean? [08:40] cpaelzer: oh, the renamed images, I see [08:40] pitti: I was looking for the one with the name change loosing -disk1 [08:41] that fix is in 3.20.7 [08:41] yeah that is why I started looking for a ppa, but backports is fine [08:41] 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] 3.20.7 just landed in testing [08:41] pitti, bug #1587762 [08:41] bug 1587762 in systemd (Ubuntu) "systemd-networkd-resolvconf-update.service incorrectly published domain limited DNS servers to /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1587762 [08:42] cpaelzer: in the meantime, just locally apply http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=6676ed6ea [08:42] cpaelzer: and the next time you'll get a package upgrade that will include the fix [08:42] pitti: I almost edited that lone myself before starting to think you likely fixed that already [08:43] pitti: thanks, I'll give the cloudinit bug at least a few minutes - maybe I can find something there for us [08:45] 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] somewhat nicer than to patch the real system :-) [08:46] cpaelzer: just run it out of git :) [08:46] cpaelzer: that's what I do in production [08:47] +1 evil overlord points for pitti for "run it out of git in production" [08:47] 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] and while autopkgtest's tests are annoying (they take ~ 30 mins), they are also rather effective at guarding against regressions [08:49] and even then, git reset --hard HEAD^, and life goes on [08:52] pitti, cna i use awk in this context, rather than sed? [08:52] apw: sure, as long as it gets along with mawk [08:53] apw: btw, it might be easier to actually not run this horrible thing at all if resolved is being used [08:53] apw: this is a shim for using networkd without resolved, but with resolvconf and software that uses /etc/resolv.conf directly [08:53] it's not needed for anything else [08:54] yeah that makes sense, is there an easy way to tell that ? [08:54] i'm trying to use sbuild to build an i386 package on my laptop and it's complaining about [08:54] sbuild-build-depends-core-dummy:amd64 : Depends: crossbuild-essential-amd64:i386 but it is not installable [08:55] mwhudson, are you building that in a amd64 chroot or something ? [08:55] i'm confused, i don't think i need or what any cross building nonsense here [08:55] apw: first iteration is to add "ConditionPathExists=!/run/systemd/resolve" to /lib/systemd/system/systemd-networkd-resolvconf-update.path [08:55] apw: i made it with mk-sbuild --arch i386 yakkety so i hope now [08:55] *not [08:56] and $ schroot -c yakkety-i386 --directory / -- uname -m [08:56] i686 [08:58] yep that looks believeable [08:58] ah passing --build i386 --host i386 is happier [08:59] or indeed --arch i386 [09:00] pitti, so without the other fix or with that together [09:00] pitti, as i am assuming that will fix my issues completely [09:01] does anyone happen to know the incantation to get the filet to make --extra-repository-key=file.asc work for a ppa? [09:01] i'm sure i can figure it out but... [09:02] apw: right, if you don't run this unit at all, it'll fix things for you [09:02] apw: I'm just not sure whether we can get away with this [09:04] pitti, well i have done the other bit too, i'll add a diff to the bug [09:04] pitti, then we can think about the test [09:04] apw: cheers [09:05] apw: I'll write that (before applying the patch) [09:05] apw: still battling with armhf lost autopkgtests and infra, getting to this later [09:08] pitti, no rush at all [09:08] pitti, and this way i can hand apply the fix and see if it works in practice [09:09] hm apparently that option just doesn't work? [09:12] or doesn't do what i think [09:12] hacked around, anyway [09:13] 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:13] bug 1560797 in apt (Ubuntu Wily) "duplicate for #1569099 apt does not configure Pre-Depends: before depending package" [High,Fix released] https://launchpad.net/bugs/1560797 [09:13] bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix released] https://launchpad.net/bugs/1560797 [09:15] pitti, ok patch attached and cowboy'd onto my machine ... seems to be working at least for now [09:16] 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:16] bug 1538438 in apt (Ubuntu) "apt-helper crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Triaged] https://launchpad.net/bugs/1538438 [09:16] bug 1580952 in apt (Ubuntu Xenial) "[SRU] Update apt/xenial to 1.2.12" [Medium,Fix committed] https://launchpad.net/bugs/1580952 [09:17] juliank: for xenial you mean? nothing, but until yesterday it didn't age for 7 days yet; today it's fine [09:17] Ah OK [09:18] juliank: sorry, that was for wily [09:18] juliank: which refers to bug 1575877 which is v-done and 7 days now [09:18] bug 1575877 in apt (Ubuntu Wily) "no_proxy ignored if https_proxy set" [Medium,Fix committed] https://launchpad.net/bugs/1575877 [09:18] * pitti releases [09:18] Yeah, xenial was uploaded 2016-05-12 [09:18] so it's far beyond schedule [09:19] juliank: look at http://people.canonical.com/~ubuntu-archive/pending-sru.html [09:19] 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] Eww, and some autopkgtest regressions [09:20] i. e. bug 1538438 (not fixed in y, not verified), and bug 1580952 (missing test case, not verified) [09:20] bug 1538438 in apt (Ubuntu) "apt-helper crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Triaged] https://launchpad.net/bugs/1538438 [09:20] bug 1580952 in apt (Ubuntu Xenial) "[SRU] Update apt/xenial to 1.2.12" [Medium,Fix committed] https://launchpad.net/bugs/1580952 [09:21] pitti: Oops, the first is fixed in yakkety [09:22] 1.2.12 is the bugfix cherry-pick of 1.3~exp1 in yakkety [09:23] 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] 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] pitti: example: bug 1587695 [09:24] bug 1587695 in amavisd-new (Ubuntu) "package amavisd-new 1:2.10.1-2ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete] https://launchpad.net/bugs/1587695 [09:24] pitti: perhaps on invoke-rc.d failure, invoke-rc.d should automatically dump "systemctl status" to stderr? [09:24] Or else, I'd like some other way for apport to pick it up. [09:25] juliank: right, the apport one is a glitch, I'll retry [09:26] pitti: Yes, and the sbuild one also happens in the most recent build with apt 1.2.10ubuntu1 [09:26] 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] yeah [09:26] so something definitively broke this, but not the new apt [09:28] pitti: What to verify about bug 1580952? I don't think this makes a whole lot of sense there. [09:28] bug 1580952 in apt (Ubuntu Xenial) "[SRU] Update apt/xenial to 1.2.12" [Medium,Fix committed] https://launchpad.net/bugs/1580952 [09:29] I suggested "Please add an SRU test case which exercise the code paths that changed here." [09:29] It's a "New upstream microrelease" with test cases in it. [09:29] maybe at least some small test plan with installing/upgrading various packages, downloading a source, etc. [09:29] to make sure it'snot completely broken [09:29] right, that too [09:32] 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] juliank: ok, agreed [09:37] juliank: I updated the two bugs [09:37] * pitti releases [09:37] Yay! [09:37] juliank: thanks for the updates [09:39] 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] I'm trying to get more translations in as well, but the merge gets confusing (anyone knows a .po merge helper?) [09:40] juliank: msgmerge ? [09:41] rbasak: hm, no amavis messages in https://launchpadlibrarian.net/262668434/JournalErrors.txt, so I'm not sure if that'd actually help [09:41] 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] rbasak: might be that this is a forking service which only outputs to log files, not to stdout/err? [09:42] rbasak: ah, wait, this only shows messags with priority >= warning, so maybe that's why [09:42] rbasak: yeah, I guess we can amend the ubuntu hook for package failures to include the status [09:43] apw: nice fix! (I'd just do s/routable/route_domains/) [09:43] pitti: thanks. I could see you were busy on something else so I filed bug 1587791 so as not to forget. [09:43] bug 1587791 in apport (Ubuntu) "apport hides systemd postinst service start failure error messages" [Undecided,New] https://launchpad.net/bugs/1587791 [09:43] thanks [09:44] rbasak: yeah, sorry; still working on some test infra fallout [09:44] pitti: np. I'd like to see this fixed (will save us bug triaging time) but it's hardly urgent. === yuning_ is now known as yuning-afk [09:47] pitti, yeah makes more sense feel free to hack her up ;) [10:24] tinoco, xnox: aupkg02 (10.100.0.13) is down again; can you please prod it? [10:28] 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] tseliot: because of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#packagekit, the proposed version is incompatible [10:29] see bug 1496292 [10:29] bug 1496292 in packagekit (Ubuntu) "Needs to be ported to packagekit 1" [High,Confirmed] https://launchpad.net/bugs/1496292 [10:31] 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] 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] that said back to what I actually wanted to do ... or lunch :-) [10:47] cpaelzer: yay, you figured it out? thanks! [11:26] Locu [11:26] oups, sorry [11:30] 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] cpaelzer: greaet === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko === seb128_ is now known as seb128 === _salem is now known as salem_ [13:15] pitti: I was happy too early about the yakkety adt now being fine a few hours before [13:15] the disk size is good now but something (tm) crashes it now [13:15] do you have any notes / best practise on debugging adt-run / adt-virt-qemu? [13:16] 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] if it is a timeout it is rather fast - like 2 seconds :-) [13:20] cpaelzer: should be 5 s [13:20] cpaelzer: hm, and that's with the PYTHONHASHSEED=0 hack already? [13:21] as this has this very symptom [13:23] pitti: I'll build from git as you do and let you know if anything in there fixes my issue [13:23] pitti: do I need to recreate the guest images to pick up the change? [13:30] cpaelzer: shouldn't be necessary really [13:32] pitti: yeah - out of git is good, thanks [13:33] cpaelzer: which version do you have installed? 3.20.7? [13:33] sil2100, hi, do you have any thoughts @ https://code.launchpad.net/~mitya57/appmenu-qt5/lp1574699/+merge/294381 ? [13:33] cpaelzer: aside from the image rename I don't see a relevant change since 3.20.6 [13:34] pitti: started with 3.20.4, then used 3.20.7 for the image create, but back to .4 for run [13:34] pitti: now I just switched to git to stay ahead just as you do [13:34] cpaelzer: .4 won't work, that doesn't have the PYTHONHASHSEED hack [13:34] cpaelzer: you need >= .5 for running yakkety images [13:34] cpaelzer: this hack applies to adt-run time, not to image creation time [13:35] which is why the adt-run out of git now got it working [13:35] good [13:35] right [13:35] 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] infinity, sarnold: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#systemd is just landing [13:36] with the unkill change [14:00] 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:00] Debian bug 708123 in grub-pc "[grub-pc] grub2 (2.00-14) fails to install on RAID arrays (rescue, boot is broken)" [Important,Open] [14:01] I'll grab an image of it and muck around in qemu [14:03] cyphermox: ^- can you deal with that? [14:05] ack [14:05] tumbleweed: filed a bug? [14:06] I was wondering what you'd want to look at [14:06] I'm going to start by trying to upgrade the metadata in a VM copy of it [14:11] symptoms are: rescue prompt shows no md devices, one has to boot it off a raid member [14:11] and the raid modules all seem to be present [14:40] also, rescue mode seems racy :P [15:38] sil2100: hi, can you rebuild mtp for yakkety please? it still depends on boost from xenial [15:41] ginggs: hey! Ok, no-change rebuild on its way [15:42] sil2100: thanks! [15:50] 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] sil2100: mtp (0.0.4+16.04.20160413-0ubuntu2) xenial; urgency=medium <= distribution is xenial [15:54] Copied from ubuntu xenial in Stable Phone Overlay PPA by Ubuntu Archive Auto-Sync <= this sounds weird to me [16:01] ginggs: ah, right, my bad - I guess the rebuild didn't happen in the end [16:02] Thanks :) [16:35] hallyn: demoting cgmanager to universe for now, as per http://people.canonical.com/~ubuntu-archive/component-mismatches.txt [16:36] 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] 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] @pilot in === udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry [16:42] 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] flaiks: we just discussed this [16:43] 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] thats not what this channel is for, [16:43] flaiks: the support channel is #ubuntu [16:46] 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] jrwren: not for me, but thank you, it's not been backported for the record for flaiks [16:47] mapreri: i usually fix the problems, in my packages [16:47] ikonia: sorry. I meant to direct taht to flaiks [16:47] 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] would be awesome if you can look at it and see if you can make it out! ♥ [16:48] jrwren: not a problem at all [16:49] not having porterboxes available doesn't really help either (the actual maintainer tried in qemu but no luck) [16:54] pitti: phased out [16:57] 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] mapreri: Partial removals are certainly possible, though we prefer to avoid the cop-out option if at all possible :) [16:58] mapreri: worth trying with -O2 [16:58] mapreri: (the "obvious" difference between Debian and Ubuntu that's ppc64el-specific is that Ubuntu's toolchain defaults to -O3 on ppc64el) [16:59] so DEB_MAINT_CFLAGS_STRIP := -O3 and DEB_MAINT_CFLAGS_APPEND := -O2 or equivalent [16:59] interesting. [16:59] (didn't know it) [16:59] mapreri: you can try it in a PPA [16:59] ya [17:00] err s/DEB_MAINT_CFLAGS/DEB_CFLAGS_MAINT/g [17:00] ah yeah, that makes sense given that it's memory related [17:07] 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] could be related for it being virtualized? [17:08] mapreri: virt/non-virt makes no difference for ppc64el [17:08] so let's try just retrying that build [17:09] of course it could be non-deterministic [17:10] - failed [17:12] cjwatson: any other suggestion? :) [17:12] * mapreri would be very happy to have it building! [17:15] i have to go out for some hours now, but please do feel free to dump ideas (or even try out stuff!) [17:19] mapreri: -O2 would definitely be my next suggestion [17:20] also diff build logs and see if that throws up anything (though I don't immediately spot anything very obvious) [17:29] 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] 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] mterry: is this where you end up having to write a backend for geoclue-2.0 that uses ubuntu-location-service? [17:31] which makes it compatible with geoclue2 [17:31] mterry, https://code.launchpad.net/~robert-ancell/canonical-is-puppet/geolocation-api/+merge/296077 [18:56] 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 [18:56] bug 1585863 in OEM Priority Project xenial "WiFi malfunction after suspend & resume stress" [Critical,New] https://launchpad.net/bugs/1585863 [19:11] @pilot out === udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [19:45] is pkexec broken? pkexe whoami gives me: [19:46] polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie [19:50] pkcheck --list-temp --> Error getting session: No session for pid [20:19] 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] [-PWD=/«PKGBUILDDIR»-] {+PWD=/«BUILDDIR»/cowdancer-0.80+ppa0+} [20:19] (this is the diff, for completeness: https://volatile.mapreri.org/2016-06-01/821944dc8105ba888c8857b2cacb7737/diff.html ) [20:20] (actually, is the full logs dwdiffed) [21:21] mapreri: Yes, it's the same; congratulations, you've found an sbuild bug to do with + handling [21:21] ahahahah \o/ [21:22] cjwatson: bug in which it can't correctly compute PKGBUILDDIR and sed it over the build log? [21:23] indeed [21:23] probably needs to quote a regex harder [21:30] hallyn: ok, thanks; I figure ubuntu-app-launch and ubuntu-core-libs will need some work then, but systemd-shim is gone already === jgrimm is now known as jgrimm-afk [23:21] does anyone have a script for doing a no-change rebuild of a package in a ppa? === salem_ is now known as _salem