[00:19] <mwhudson> oh good good the celery in artful is not compatible with the kombu in artful
[00:19] <mwhudson> ah it's only in proposed, phew
[00:22] <mwhudson> jamespage: i assume you're asleep/not here but why did you sync kombu from experimental?
[01:09] <jbicha> mwhudson: could you sync pygobject from Debian experimental?
[02:36] <mwhudson> jbicha: ah does that have the ftbfs fix as well?
[02:40] <lotuspsychje> good morning guys
[02:40] <jbicha> mwhudson: yes, that's sort of where you got it from, I believe :)
[02:40] <mwhudson> jbicha: okidoke :)
[02:41] <lotuspsychje> ive edited 3 duplicate bugs on a fresh 17.10 install, all fixxed with dnssec=off
[02:41] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1690605
[02:41] <ubottu> Launchpad bug 1690605 in systemd (Ubuntu) "systemd-resolved: no dns resolution after upgrade to Artful" [Undecided,New]
[02:41] <lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1681597
[02:41] <ubottu> Launchpad bug 1682499 in systemd (Ubuntu Zesty) "duplicate for #1681597 disable dnssec" [High,Fix released]
[02:41] <lotuspsychje> and https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1682499
[02:41] <ubottu> Launchpad bug 1682499 in systemd (Ubuntu Zesty) "disable dnssec" [High,Fix released]
[02:41] <mwhudson> jbicha: synced
[02:42] <lotuspsychje> just letting you guys know it wasnt fixxed on a yesterdays install
[02:44] <jbicha> xnox: systemd-resolved problems in artful for some people ^
[02:44] <lotuspsychje> i enabled updates during setup
[03:26] <mwhudson> what does launchpad's sbuild do with alternates in build-depends? i know debian's just takes the first entry
=== JanC_ is now known as JanC
=== geser_ is now known as geser
[07:41] <pitti> mwhudson: it uses apt to resolve them, so it does take alternatives into acconut
[07:41] <pitti> mwhudson: so "B-D: some-nonexisting-package | libfoo-dev" will work in Ubuntu, and we do use that occasionally to avoid a delta to debian
=== klebers_ is now known as klebers
[08:09] <mwhudson> pitti: but if all packages are available, it should use the first one?
[08:09] <pitti> mwhudson: right, unless that's conflicted to by another build dep
[08:10] <mwhudson> hm
[08:10] <pitti> the first is the "preferred" alternative (in D and U), but if that's uninstallable, apt tries permutatinos
[08:13] <mwhudson> pitti: what happened here then? https://launchpadlibrarian.net/319663773/buildlog_ubuntu-artful-amd64.aubio_0.4.3-4ubuntu2_BUILDING.txt.gz
[08:13] <mwhudson> pitti: the dep is "python3-all-dev | python3-dev | python3 | python3-all" but it installed python3
[08:14] <mwhudson> when i just deleted everything but the first dep it installed fine
[08:26] <xnox> jbicha, re:u-u-t and dconf-qt i believe both are dead, but needs actual checking of reverse deps and filing bugs etc.
[08:27] <xnox> jbicha, re systemd-resolved dnssec was re-enabled in the hope that it is better in latest new upstream release.... turns out it is not.
[08:27] <pitti> mwhudson: did it actually install python3? it might already have been installed in your build env, so it was already satisfied that way
[08:28] <pitti> mwhudson: but that doesn't make any sense as a build dep anyway -- either you need -dev or not, and either you want -all (for building a python module package) or not (for building a program that uses python, but doesn't export public libraries)
[08:28] <mwhudson> pitti: no, it really installed python3
[08:28] <mwhudson> Get:12 http://ftpmaster.internal/ubuntu artful-proposed/main amd64 python3 amd64 3.5.3-1ubuntu3 [8710 B]
[08:29] <mwhudson> pitti: i agree it's nonsensical
[08:29] <pitti> hm, if none of them was installed, it should have installed python3-all-dev indeed
[08:29] <mwhudson> so it's not a real problem, but i was a bit confused nonetheless
[08:29] <mwhudson> this smells like a wgrant or infinity sort of problem
[08:30] <xnox> we do building with resolve alternative depends, thus it can choose other things if something else listed python3 | python3-all-dev for example.
[08:30] <xnox> but meh, indeed such a b-d doesn't make much sense.
[09:43] <mirak> hi
[09:43] <mirak> how ubiquty knows what packages it must install ?
[10:05] <infinity> xnox: I'm not sure how the dnssec bits in systemd-resolved can get "better", given that they rely on the internet not being crap.
[10:06] <xnox> infinity, touche
[10:06] <xnox> infinity, they fixed bugs, but not enough of them =)
[10:06] <infinity> xnox: Insert one DNS server that publishes zones that claim to require dnssec and aren't signed (or are incorrectly signed), and your world explodes.  systemd can't fix that.
[10:06] <xnox> well, it has fallback mode, which is not falling back hard enough, imho
[10:07] <infinity> xnox: That above situation is exactly where you shouldn't fall back, though.
[10:07] <xnox> and a lot of it is downgrade attacks if one does fallback too much
[10:07] <infinity> xnox: Because falling back is accepting a potential MITM.
[10:07] <xnox> yeah
[10:07] <xnox> but what we do now is disable dnssec completely in stable series
[10:07] <infinity> So, I aplaud the effort to use systemd to debug the internet, but the result is pretty frustrating.
[10:07] <xnox> i'd rather have "we tried dnssec and it did work, you are dnssec connection *this* time" instead of "we didn't even bother"
[10:08] <infinity> If there was a UI for this, sure. :P
[10:08] <xnox> that's what the fallback option was supposed to do....
[10:08] <infinity> But it's not like the user knows "hey, this lookup was dnsseccy".
[10:08] <xnox> but doesn't
[10:08] <infinity> They just know "the internet works" or "the internet is broken".
[10:08] <xnox> google chrome shows that i think; but that i think also bypasses NSS to get that info.
[10:10] <infinity> Yeah, there's no way one can get that info from gethostbyname.
[10:10] <xnox> nah, plugin.
[10:10] <xnox> (not builtin indicator into google chrome)
[10:11] <infinity> I mean, if/when dnssec becomes the norm, I'm perfectly happy with a setup that drops badly-configured DNS zones on the floor.
[10:11] <infinity> Just as I'm happy blackholing email from poorly-configured SMTP servers.
[10:11] <infinity> But today probably isn't that day.
[10:12] <xnox> yeah
[10:12] <infinity> People are still learning how to use dnssec correctly, and it seems that a large number of them are learning slowly and poorly. :P
[10:12] <maswan> I find that the problem isn't so much badly configured zones, as captive portals
[10:12] <infinity> maswan: I've seen a lot of the former.  But the latter definitely makes things even more "interesting", for sure.
[10:12] <maswan> Which mess with DNS (and all other things too)
[10:12]  * xnox loves how android rejects captive portals with expired SSL certificates, for example London Underground WiFi
[10:13] <infinity> The only reasonable solution to the captive portal mess is some collusion among OS and browser vendors to just test some well-known location.
[10:13] <infinity> Cause "spoof DNS for the world" doesn't work in a dnssec world.
[10:15] <maswan> yeah. been seeing more and more browser stuff of "this network appears to require a login" features testing towards a well-known page
[10:15] <maswan> since it is already breaking for a mostly https world
[10:17] <maswan> One more data point, a majority of swedish household ISPs do dnssec validation on the resolvers provided to the users
[10:17] <maswan> So broken zones would be broken to them anyway
[10:19] <infinity> maswan: Yeah, but who cares about Sweden? :)
[10:20] <infinity> (Also, that's quite progressive... Next you're going to tell me that all Swedish ISPs give their customers v6 IPs and routing, too?)
[10:21] <infinity> I wish the Canadian ISPs would wake up on that score.
[10:22] <maswan> Nah, v6 they're horribly behind the curve on
[10:22] <mapreri> jbicha: ok.  BTW, for me this is a proof that keeping the old changelog entry is useful, until you said so I believe you were the person introducing the delta.
[10:22] <mapreri> :)
=== popey_ is now known as popey
=== klebers_ is now known as klebers
=== dannf` is now known as dannf
[14:22] <hallyn> sarnold: bug 1690820 , fyi.  I can create a package for a, but istr there's a special process for security regressions?
[14:22] <ubottu> bug 1690820 in shadow (Ubuntu) "killing su does not kill subprocess (SIGTERM not propagated)" [Undecided,New] https://launchpad.net/bugs/1690820
[15:19] <mdeslaur> hallyn: do you know what the issue is?
[15:19] <mdeslaur> sarnold: FYI ^
[15:21] <hallyn> mdeslaur: yes, a security fix for unpriv users being able to kill other user's shells, introduced a regression which prevents sigterm sent to su fro mbeing forwarded to the job
[15:22] <hallyn> (the git commit has the details)
[15:22] <hallyn> yeah i assumed i was too early for sarnold, i know how he rolls :)  he probably just got to bed 2 hrs ago :)
[15:24] <mdeslaur> hallyn: if you have the commit or the debdiff, could you attach it to the bug for sarnold to release as a security regression fix?
[15:24] <mdeslaur> it does need to be built as a security regression updates
[15:24] <mdeslaur> *update
[15:26] <hallyn> mdeslaur: sure.  sorry i didn't even open the bug, assumed it would have a link to the commit.  will add it.
[15:27] <hallyn> (added) \o
[15:31] <mdeslaur> hallyn: thanks!
[15:33] <sil2100> jdstrand_: hey! I was just looking at promoting snapd from -proposed to -updates and saw that LP: #1664638 has a comment from George - could you check if it's still good to go? I don't have enough context
[15:33] <ubottu> Launchpad bug 1664638 in snapd (Ubuntu Zesty) "Need an interface for kubernetes" [Undecided,Fix committed] https://launchpad.net/bugs/1664638
[16:06] <jdstrand_> sil2100: hi! the comment doesn't change what I said about the interface and its suitability for SRU. it is a work in progress interface that jut needs to be iterated on and George gave comments so that could happen
=== jdstrand_ is now known as jdstrand
[16:07] <sil2100> jdstrand_: ACK, in that case I'll be releasing it to -updates
[16:07] <jdstrand> sil2100: great :)
[16:08] <sil2100> jdstrand: hm, although I do see an autopkgtest failure for zesty
[16:08] <sil2100> jdstrand: for armhf
[16:09] <sil2100> jdstrand: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/s/snapcraft/20170511_171104_47fb3@/log.gz <- from snapcraft
[16:09]  * jdstrand looks
[16:09] <sil2100> Argh
[16:09] <sil2100> Networkin error
[16:09] <sil2100> Let me quickly re-run
[16:09] <jdstrand> sil2100: that's all unrelated, yeah
[16:09] <sil2100> Temporary failure resolving 'ftpmaster.internal'
=== jdstrand is now known as jdstrand_
[17:36] <sarnold> hallyn: thanks <3 :) you know me too well
[17:36] <sil2100> jamespage: hey!
[17:36] <sarnold> hallyn: since A requires a merge from debian still I didn't actually fix shadow there
=== jdstrand_ is now known as jdstrand
[17:38] <sil2100> jamespage: I'm currently looking into releasing neutron-lbaas to -updates - the bug is verified for all releases but I just wanted to make sure it's tested both for neutron and neutron-lbaas, right?
[17:38] <sil2100> I mean, it's tested with both packages, right?
[18:01] <hallyn> sarnold: oh, so sru only?
[18:04] <sarnold> hallyn: well, the security fix is still needed there, of course; it's a bit strange not being able to upload for -devel :/
[18:05] <hallyn> so the security upgrade only exists in z, and that's bc it happened before a started?
[18:05] <hallyn> noone should run z anyway, so ... :)  (it'st lts and not the latest :)
[18:25] <sarnold> hallyn: exactly! :) I managed to lose two races on that one -- both z was released and p closed before I got the update out. agrh.
[18:26] <sarnold> hallyn: or maybe that's three races lost, z released, a opened, p closed.
[18:26] <sarnold> hallyn: in any event I was finally happy to have moved on. sigh. :)
[18:48] <hallyn> sorry :(
[18:49] <hallyn> and hopefully the code is right this time.  that's some fragile stuff
[18:53] <sarnold> for as much time as I spent reading it i'm surprised to have missed it :(
[19:11] <jamespage> sil2100: it is yes
[19:11] <jamespage> thanks
[19:59] <nacc> rbasak: dpb1_: fyi, automatic import restarted after the tooling change to `git ubuntu`
[19:59] <nacc> meaning i think it works :)
[20:00] <dpb1_> nacc: this sounds like good news
[20:00] <nacc> rbasak: working on fixups to my namespace branch, i'll push (probably over the top, maybe replace) the branch again once
[20:00] <dpb1_> :)
[20:00] <nacc> dpb1_: yeah, `usd` is dead :)
[20:00] <dpb1_> woohoo
[20:00] <dpb1_> what git commit is that?
[20:01] <nacc> slangasek: --^ as well. Still need to do the git delta for the automatic setup of lp:, but on my todo for this week
[20:01] <nacc> dpb1_: master for the fully working replacement, but `usd` was killed in a separate branch (so the snap can redirect to git-ubuntu), sha of master right now is fa6e2ec5
[20:01] <nacc> dpb1_: shell completion is still not quite working in the snap, but i recall some discussion in #snappy about it, i'm going to go read the logs
[20:01] <nacc> *after lunch
[20:02]  * dpb1_ nods
[21:21] <mdeslaur> infinity: thanks for the mysql-5.7 sync
=== JanC_ is now known as JanC
[22:00] <nacc> rbasak: around?
[22:01] <rbasak> nacc: sorry, just about to disappear
[22:05] <nacc> rbasak: np, will talk tmrw
[23:19] <nacc> rbasak: well, i think the namespace branch i have locally is 'just working' :)