[01:06] <slangasek> mapreri: are you fixing mldemos for the new opencv?
=== JanC is now known as Guest88964
=== JanC_ is now known as JanC
[05:24] <Logan> jbicha: do you remember why you stopped building qmmp-plugin-projectm on arm64 with this change? https://launchpad.net/ubuntu/+source/qmmp/1.1.3-0ubuntu1
[05:24] <Logan> trying to determine whether to drop/keep that delta
[06:59] <cpaelzer> nacc: glad I could help serving a few bugs for the importer :-)
[06:59] <cpaelzer> nacc: looking at the new tree now
[08:21] <LocutusOfBorg> jbicha, is the xmonad patch retro-compatible with an older gnome-settings-daemon? I would like to upstream it in Debian too
[09:37] <lag> Can anyone help me access a private PPA (which I have access to) please?
[09:40] <cking> lag, ^ if you explain the exact issue it may help somebody figure out what's wrong
[09:42] <lag> W: The repository '<REMOVED_FOR_SECURITY> zesty Release' does not have a Release file.
[09:42] <lag> N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
[09:42] <lag> E: Failed to fetch <REMOVED_FOR_SECURITY>/ppa/ubuntu/dists/zesty/main/source/Sources  401  Authorization Required
[09:46] <mapreri> slangasek: actually, I wanted to ask for removal of mldemos.  It FTBFSed even before opencv 3.1.
[09:46] <mapreri> (well, new opencv caused a different failure too, but still)
[09:47] <mapreri> In that transition I already have 2 packages that FTBFS but didn't during my build tests, so if you want to fix one or 2 go ahead :)
[09:49] <jbicha> LocutusOfBorg: no, g-s-d was split into separate binaries in 3.24; I believe RequiredComponents means that all listed binaries must be running
[09:52] <jbicha> Logan: maybe it failed to build? if it builds, syncing is fine with me :)
[10:11] <mwhudson> lag: stupid questions would be, you did get your password right? the particular ppa does actually have publications for zesty?
[10:17] <lag> mwhudson: Stupid answer would be, yes, I copied and pasted the PPA deb lines directly from LP to sources.list
[10:17] <lag> mwhudson: Yes, Zesty is published/tested
[10:18] <lag> mwhudson: FYI: This is dja's PPA
[10:19] <mwhudson> lag: huh then i don't know :/
[10:19] <mwhudson> i guess you could try poking around in the browser
[10:20] <lag> mwhudson: On subsequent issue of `sudo apt-get update` it's now professing a GPG error, but the key is not --recv-keys gettable
[10:20] <mwhudson> !/
[10:20] <mwhudson> !? rather
[10:20] <lag> mwhudson: A1CC0926363E55AB -- is that your experience?
[10:21] <mwhudson> lag: --keyserver keyserver.ubuntu.com ?
[10:21] <mwhudson> aka "the one that works"
[10:21] <mwhudson> (i fetched the key fine from there)
[10:22] <lag> mwhudson: Oooo
[10:22] <lag> mwhudson: Nice, thanks
[10:23] <lag> mwhudson: Interesting that they are not propagated to other servers?
[10:23] <mwhudson> lag: i don't know that that is deliberate...
[10:24] <lag> mwhudson: Same error though -- still saying the key is not available -- do I have to give `apt-get update` any further args?
[10:24] <mwhudson> oh
[10:24] <mwhudson> you need some apt-key invocation
[10:24] <lag> The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A1CC0926363E55AB
[10:24] <mwhudson> apt doesn't care about your keyring :-)
[10:24] <lag> mwhudson: :)
[10:24] <mwhudson> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $fingerprint
[10:25] <mwhudson> this reminds me i have some keys to sign but i'm not sure i have enough whisky in the house to deal with caff
[10:28] <lag> mwhudson: :)
[10:29] <lag> mwhudson: Is caff a person?
[10:29] <mwhudson> https://wiki.debian.org/caff
[10:29] <lag> mwhudson: I have a nice little script that helps me to sign keys
[10:29] <lag> mwhudson: Ewww, good luck with that :(
[10:41] <ginggs> has anything recently changed with the way 'hardening=+all,-pie' is handled in Ubuntu?  I thought we are now doing things the same as Debian.  p4vasp FTBFS in artful, but builds fine in Debian unstable
[10:44] <jbicha> pitti: hi, I believe you're sponsoring meson 0.41.1? it fixes build failures for some vala apps
[10:57] <rbasak> Is it just me or has various things sent to ubuntu-devel@ started arriving twice?
[11:06] <pitti> jbicha: I am, yes; I just saw jussi's sponsor request mail
[11:07] <dja> lag/mwhudson - I'll copy it to a public ppa in a couple of hours
[11:07] <dja> just have some cleaning etc to do
[11:08] <lag> dja: It's fine -- I have it now, thanks
[11:08] <dja> lag, ah excellent
[11:08] <lag> dja: Just installing now
[11:08] <dja> I will save the effort for housework then :)
[11:09] <lag> dja: Actually I'm looking for your Grub entry (did you send that via mail)
[11:09] <dja> oh
[11:10] <dja> I sent 1 line of it
[11:10] <dja> let me see what I sent you
[11:12] <lag> dja: Found it, rebooting
[11:12] <dja> ah good
[11:12] <dja> you can also examine it interactively in grub when you're booting
[11:13] <dja> the commands are printed somewhere on screen :)
[11:13] <dja> anyway, housework time
[11:14] <lag> dja: Ya, I do that a lot
[11:15] <lag> dja reaches for his feather duster and pinni
=== santa is now known as Guest47677
[11:44] <rbasak> nacc: some of our tooling (eg. queue sync) doens't work with a locally imported tree any more by default, since it's looking for a remote for pkg, rather than at local importer/ prefixed branches. Not sure how to resolve this. I think I'm happy with where we're putting things, so perhaps tooling needs to be able to look in the right places, or else we need some code abstraction to find them?
[15:14] <nacc> rbasak: can you file a bug or pastebin an example so i can debug?
[15:17] <rbasak> nacc: I know where the bug is, it's a just the architectural question of how to resolve.
[15:18] <nacc> rbasak: can you point me at a line?
[15:18] <rbasak> nacc: queue.py:215
[15:18] <rbasak>                 devel_head_ref = repo.lookup_reference('refs/remotes/pkg/ubuntu/%s-devel' % series)
[15:18] <rbasak> But for a local import, it's refs/heads/importer/ubuntu/%s-devel
[15:18] <rbasak> I could look for both for example
[15:19] <nacc> rbasak: i think that's only a problem for the queue code, which doesn't use the git_repository functions
[15:20] <nacc> rbasak: oh wait, i see what you mean
[15:21] <nacc> rbasak: it *could* happen elsewhere
[15:21] <nacc> rbasak: but i meant that line, at least, explicitly is looking at a remote ref
[15:21] <rbasak> Yeah - so what should it do instead?
[15:21] <rbasak> Look for both?
[15:21] <rbasak> Or require an option for local? Etc.
[15:22] <ginggs> <ginggs> has anything recently changed with the way 'hardening=+all,-pie' is handled in Ubuntu?  I thought we are now doing things the same as Debian.  p4vasp FTBFS in artful, but builds fine in Debian unstable <-- fixed by no-change rebuild of fltk1.3
[15:22] <nacc> rbasak: let me look a bit more after the call
[15:28] <nacc> rbasak: ok, so contextually, sync() is trying to find the -devel branches for all possible series?
[15:28] <nacc> rbasak: what should it do if both pkg/ubuntu/*-devel and importer/ubuntu/*-devel are present?
[15:30] <rbasak> nacc: that's right. And yes - what should it do?
[15:30] <rbasak> Perhaps favour the local branches?
[15:30] <rbasak> Or fail and ask?
[15:30] <nacc> rbasak: well, it's your subcommand :) I'm trying to think out loud a bit
[15:34] <rbasak> Sure. What about the general case though? Are there other subcommands that need to look at the imported trees (rather than HEAD), and what should they do
[15:34] <rbasak> ?
[15:36] <nacc> rbasak: yeah, so I think what we should do is write a wrapper in git_repository.py that takes a series name and returns the 'later' (or possibly sorted by version, all) branches that are devel pointers of that series
[15:39] <rbasak> What if we need things that aren't devel pointers? :)
[15:39] <nacc> rbasak: series parameter
[15:39] <nacc> rbasak: *pocket parameter
[15:39] <rbasak> I mean I need to see all the pointers. For example in my lint tool, to figure out the SRU version number.
[15:39] <rbasak> Also, what should the return type be? pygit2.Reference?
[15:40] <nacc> rbasak: well the linter should be using get_heads_and_versions
[15:40] <nacc> rbasak: which will give you all of them in a given namespace
[15:41] <rbasak> Ah, OK. Thanks
[15:41] <nacc> rbasak: i think it can be made more flexible to allow no namespace, etc. (and not insert '/' if not provided)
[15:41] <rbasak> That makes sense
[15:42] <nacc> rbasak: i think it's ok to have two APIs for now, they probably can consolidate eventually
[15:42] <nacc> rbasak: the consolidation being a third parameter to get_heads_and_versions which also takes a suffix (or well-defined 'pocket' argument)
[15:43] <nacc> rbasak: that i think you could actually use in the queue code too, just need to peel the head to get the ref object
[15:44] <nacc> rbasak: but i think you're right, you'd need to do both in the queue code, and have some sort of prioritization (or query to the user) -- i think favoring local imports (or 'later' version?) would work to start?
[15:51] <rbasak> nacc: yeah. I'll file a bug. In queue sync, I can workaround with my new --series, --no-trim, --no-fetch, --parent and --source options.
[15:54] <rbasak> LP: #1699541 for reference. Leaving for now.
[15:54] <ubottu> Launchpad bug 1699541 in usd-importer "subcommands fail when only a local import exists" [Undecided,New] https://launchpad.net/bugs/1699541
[15:55] <nacc> rbasak: ack, thanks
[15:56] <ogra_> cyphermox, yo ... regarding netplan in the core snap ... we dont build from proposed ... so nplan should be copied to the snappy image PPA to be picked up by edge core builds
[15:58] <cyphermox> it will be in updates soon
[15:59] <nacc> rbasak: also, i think we had previously said that only the importer would know about importer/ ... obviously that can't be true for 'offline imports'
[16:00] <nacc> rbasak: so we might need to rethink other bits
[16:01] <ogra_> cyphermox, ah, cool, for the next time we can copy from proposed to https://launchpad.net/~snappy-dev/+archive/ubuntu/image ... in case there is testing needed just give me a ping when you have some package for it
[16:01] <nacc> rbasak: i'm triggering the assertion at git_repository.py:941 with websockify (0.5.1+dfsg1-1 specifically)
[16:02] <rbasak> nacc: on origin/master I don't see an assertion on 941 but there is one nearby.
[16:03] <nacc> rbasak: err, right, 937 in master
[16:03] <nacc> rbasak: sorry was on the wrong branch locally (but the bastion import is what shows it, so it's in master too)
[16:04]  * rbasak is reminding himself of the code
[16:05] <nacc> rbasak: i'm getting us some more debugging output as well
[16:07] <nacc> rbasak: pygit2.TreeEntry('include', blob, f5030fe889982444316aa710b12026d377e187e0)
[16:07] <nacc> rbasak: that's the tree_entry variable before the assertion triggers
[16:10]  * rbasak tries to reproduce
[16:10] <nacc> rbasak: thanks
[16:11] <rbasak> I can reproduce
[16:14] <bdmurray> juliank, infinity: Looking at apt and those 'dpkg exited unexpectedly' bugs - is there some additional information we could gather here? https://git.launchpad.net/apt/tree/apt-pkg/deb/dpkgpm.cc#n2078
[16:17] <nacc> rbasak: ah tests/include -> ../include
[16:18] <nacc> rbasak: another symlink issue?
[16:19] <rbasak> Ah
[16:21] <rbasak> os.path.isdir returns True for a symlink to a directory.
[16:22] <nacc> rbasak: yeah, i think you have to explicilty check for a symlink
[16:23] <rbasak> Better to use lstat and check using S_ISDIR I think.
[16:24] <nacc> rbasak: as you see fit :) the python docs basically say isfile/isdir will be true for symlinks (it doesn't mean 'regular file'/'regular dir')
[16:26] <rbasak> Yeah, my mistake
[16:27] <nacc> rbasak: oh not meant as criticism :) i find it surprising too
[16:34] <nacc> rbasak: so the fix is changing _add_missing_tree_dirs to not use isdir, but lstat and ISDIR?
[16:34] <rbasak> Yep. https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/326084
[16:34] <nacc> rbasak: so that we only recurse on directories
[16:34] <rbasak> (filed just this moment)
[16:34] <nacc> rbasak: ack, reviewing
[16:35] <juliank> bdmurray: I guess we could at least log the status code or something. AFAICT, the branch is entered on signals that are not SEGV, but I'm not sure it's really useful, you'll see the type of signal anyway
=== girish946 is now known as girishjoshi
[16:39] <nacc> rbasak: merged, thanks!
[16:52] <bdmurray> juliank: Can you elaborate on "see the type of signal anyway"?
[17:06] <slangasek> mapreri: removal is also fine! are you requesting its removal from Debian or Ubuntu, and can I get a more formal paper trail?
[17:16] <juliank> bdmurray: Well, in the error tracker you saw that it was calling abort() anyway
[17:17] <juliank> But we can add it, I just wouldn't do an out-of-band release for that, it seems really low priority
[17:19] <bdmurray> juliank: I was trying to get more information than "Error: Sub-process /usr/bin/dpkg exited unexpectedly" as seen in https://launchpadlibrarian.net/320875815/DpkgHistoryLog.txt
[17:20] <juliank> Ah, yes in that log file it would be more helpful. But at least you know it's not a segfault or a error exit
[17:21] <bdmurray> Oh yeah, that's true.
=== tomreyn_ is now known as tomreyn
[17:23] <juliank> bdmurray: I guess we should (1) add a return _error->Error(_("Sub-process %s received signal %u."),Name, WTERMSIG(Status)); branch and (2) just print the waitpid status as is somewhere in the unexpected path
[17:23] <juliank> There are three users of that string in the apt code, I'd obviously prefer generalizing this for all of them
[18:24] <smoser> sil2100, still there?
[18:24] <smoser> i'm on holiday at the moment. i just was going to check in for a cuople hours.
[18:25] <sarnold> dangerous thing to do on holiday :)
[18:25] <smoser> the new-upstream-snapshot change was done in one of the branches, i'm not sure which.  it was a result of bzr insisting that a file had changed been fully removed and then added again with 100% the same contents.
[18:25] <smoser> i'd seen this in other places in the past...
[18:26] <smoser> 'bzr diff' between two branches will show you 100% difference on 100% equal files.
[18:26] <smoser> the end result is that it doesn't matter as long as it was correct.
[18:27] <smoser> its really just an 'upstream revision control management' thing. i'm looking forward to it being replaced by one that uses git in the future.
=== wxl_ is now known as wxl
[19:02] <nacc> cyphermox: systemd-resolve question -- lxd has a /etc/systemd/network/lxd.network with DNS=10.0.4.1 and Domains=lxd. But systemd-resolve <container>.lxd does not query 10.0.4.1. What am I missing?
[19:03] <cyphermox> xnox: slangasek: ^
[19:03] <slangasek> haha
[19:03] <cyphermox> we were just discussing that
[19:03] <nacc> heh
[19:03] <nacc> I have been reading lots of manpages ... which are eye-bleeders
[19:04] <slangasek> what did xnox say was the right bit? '[DHCP] UseDomains=yes' into the systemd-resolved config?
[19:04] <cyphermox> nacc: systemd's defaults for UseDomains= break that
[19:04] <cyphermox> yep
[19:04] <nacc> cyphermox: ah i see
[19:04] <cyphermox> to be precise, UseDomains=route would fix this; UseDomains=yes would fix this and make <container> work too
[19:05]  * cyphermox goes to verify this
[19:05] <nacc> cyphermox: ok, that goes into /etc/systemd/resolved.conf in the [Resolve] section? it's not in the manpage :)
[19:05] <cyphermox> nacc: no, it goes into /etc/systemd/network/lxd.network
[19:06] <nacc> cyphermox: oh ok
[19:12] <slangasek> cyphermox: is that by convention, or is that actually a different config namespace than the other bits read for resolved?
[19:14] <cyphermox> slangasek: it's a DHCP setting, so it goes with each interface
[19:14] <nacc> cyphermox: well, clearly i don't know which services i need to restart/reload (and which can be). Rebooted after mucking with the files and I do now get resolution of <container>
[19:15] <nacc> cyphermox: but not <container>.lxd, is that expected too?
[19:16] <nacc> cyphermox: hrm, worked for one container, rather, but not another, debugging
[19:16] <cyphermox> what setting did you use? it's probably something else
[19:16] <cyphermox> you'd want to check what systemd-resolve --status reports, I suppose
[19:17] <nacc> cyphermox: weird, it works for some random subset -- UseDomains=yes in /etc/systemd/network/lxd.network
[19:17] <nacc> cyphermox: should status indicate which domains, if any are being used?
[19:17] <cyphermox> nacc: I don't know. Right now I'm not able to make lxc work correctly on my system
[19:18] <nacc> cyphermox: excellent :)
[19:18] <cyphermox> status should indicate everything
[19:19] <nacc> cyphermox: ok, there are some domains in "Global", but none per-link
[19:19] <nacc> http://paste.ubuntu.com/24918979/
[19:19] <cyphermox> ... and nothing lxc there.
[19:21] <nacc> cyphermox: oh an interesting, no 'DNS Servers" entry at all (whereas my wifi entry does have it (but no domain, which is ok): http://paste.ubuntu.com/24918987/
[19:22] <nacc> cyphermox: sorry, i'll stop pinging you random pastes until you're in a working state yourself :)
[19:22] <cyphermox> won't be long, I fallback to another system that does work
[19:24] <nacc> cyphermox: cool, last paste of partial resolution, correctly on per-link basis (I think), and that all three should resolve: http://paste.ubuntu.com/24919010/
[19:29] <cyphermox> nacc: what is in resolv.conf?
[19:30] <cyphermox> because by default you might well also have dnsmasq running, the one from NM, and things in resolv.conf which may or may not have been picked up by systemd-resolve
[19:30] <nacc> cyphermox: nameserver 127.0.0.53
[19:31] <nacc> cyphermox: which, iiuc, is just systemd-resolved?
[19:31] <cyphermox> yes
[19:31] <nacc> cyphermox: i do have dnsmasq running for NM, that's true
[19:31] <cyphermox> ok, in that case, what is in /run/systemd/resolve/resolv.conf?
[19:31] <nacc> cyphermox: that contains 'nameserver 192.168.1.1'
[19:31] <nacc> cyphermox: interesting
[19:32] <cyphermox> well, that's expected
[19:32] <cyphermox> that would be your wifi
[19:32] <cyphermox> (I guess)
[19:32] <nacc> cyphermox: yep
[19:42] <nacc> cyphermox: how does systemd-network know to map 'lxd.network' to lxdbr0? Is that perhaps what's missing? e.g., Name=lxdbr0 in a [Match] section?
[19:42] <nacc> cyphermox: or does the lack of [Match] mean it will always be tried?
[19:42] <nacc> cyphermox: nm, answered my question by finishing the manpage section :)
[19:50] <xnox> nacc, cyphermox, slangasek: one is missing [Match] Name=eth0 [DHCP] UseDomains=true as a /etc/systemd/network/usedomains.network
[19:50] <xnox> nacc, it's a per-link / .network configuration. Not a resolved daemon option.
[19:50] <nacc> xnox: right, so i added [DHCP] ... to lxd.network
[19:50] <nacc> xnox: the manpage says no Match is match all
[19:50] <xnox> yeap. or whichever you need =)
[19:51] <xnox> sure.
[19:51] <nacc> xnox: but it still doesn't work :)
[19:51] <nacc> xnox: well, not fully, at least
[19:51] <nacc> i get partial resolution, which is weird
[19:51] <xnox> nacc, it does for me here. $ sudo systemctl restart systemd-networkd systemd-resolved
[19:51] <xnox> nacc, what doesn't work?
[19:51] <nacc> xnox: one sec, let me grab the paste
[19:51] <xnox> and what is your /etc/resolv.conf?
[19:52] <nacc> xnox: /etc/resolv.conf is pointing to just systemd-resolved, /run/resolvconf/resolv.conf is pointing to my wifi nameserver
[19:52] <xnox> nacc, also who are you trying to resolve, from where, and where the target actually is. For me I get container <-> container resolving each other.
[19:52] <nacc> xnox: i want host resolving container
[19:52] <nacc> xnox: http://paste.ubuntu.com/24919010/
[19:52] <xnox> nacc, we do not do that at all. because that would conflict when one has multiple container bridges.
[19:52] <nacc> xnox: sure, but i don't.
[19:53] <nacc> xnox: so i should be able to configure something to do it, right?
[19:53] <xnox> nacc, what we do provide and support, is one container resolving the other container, with search domains. e.g. cuty-animal resolving ugly-animal.
[19:53] <xnox> right, yes you should be able to.
[19:53] <xnox> however, you need to have a dhcp client for your host, running on that bridge, and specifying that to resolved.
[19:54] <xnox> i do not think we feed that on the host.
[19:54] <xnox> (by default)
[19:54] <xnox> not sure how to configure that properly.
[19:54] <xnox> what is your lxd.network on the host?
[19:54] <nacc> xnox: confirmed that the containers do see other properly (i hadn't even tested that before)
[19:54] <nacc> xnox: http://paste.ubuntu.com/24919186/
[19:54] <xnox> nacc, i think i want your output of $ systemd-resolve --status
[19:54] <xnox> too
[19:55] <xnox> right, that would not work.
[19:55] <xnox> as that unit makes no sense at all.
[19:55] <xnox> what you do want is dhcp network file that will get an ip address on the bridge.
[19:55] <nacc> xnox: the only thing i added was the last two lines, the others were there already
[19:55] <xnox> hm. but that's very backwards.
[19:56] <xnox> o_O
[19:56] <xnox> where did the first two come from?
[19:56] <nacc> xnox: http://paste.ubuntu.com/24919194/ (--status) and the frustrating part is: http://paste.ubuntu.com/24919190/
[19:56] <nacc> xnox: oh wait, nm, i probably added it tryign to get this all to work
[19:56] <nacc> xnox: so i will admit to PEBCAK :)
[19:57] <nacc> xnox: but i'd also like to understand what i should be doing instead ... it feels like my host has all the information it needs to resolve everything, i just don't know how to tell systemd to use 10.0.4.1 to resolve *.lxd
[19:57] <xnox> nacc, i think on the host, you simply want to adjust /etc/systemd/resolved.conf and change DNS= to have the whatever dnsmasq on the lxd bridge binds to (10.0.4.1) and then Domains=lxd in that file too
[19:57] <xnox> then restart systemd-resolved
[19:57] <xnox> and then it should work for host to resolve cute-animal
[19:57] <xnox> this is basically hand tuning the host.
[19:58] <nacc> xnox: right, but that ends up putting it global, instead of per-link?
[19:58] <xnox> a more generic way, is to write .network files for systemd-networkd on the host to get a dhcp lease, just like a container would, and then resolve names as if host is one more containers.
[19:58] <nacc> xnox: e.g.: http://paste.ubuntu.com/24919212/
[19:58] <xnox> correct.
[19:58] <xnox> you can do per-link via dbus api.
[19:59] <nacc> xnox: the issue i found was that it ended up pegging my cpu eventually :)
[19:59] <nacc> xnox: as in immediately afterwards (it's doing so now)
[19:59] <nacc> *after restarting systemd-resolved
[20:00] <xnox> please file a bug with output of /proc/<pid>/stack
[20:00] <xnox> when it does.
[20:00] <nacc> lol
[20:00] <nacc> [<ffffffffffffffff>] 0xffffffffffffffff
[20:00] <xnox> nacc, i think you may be able to create a decent enough .network file to do per link resolution.
[20:00] <xnox> soemthing like
[20:01] <xnox> [Match] Name=lxdbr0 [Network] DNS=10.0.4.1 Domains=lxd
[20:02] <xnox> instead of changing /etc/systemd/resolved.conf
[20:02] <xnox> restart systemd-netwrokd, restart systemd-resolved
[20:02] <xnox> then look at status of $ systemd-resolve --status
[20:02] <xnox> and it should have that DNS/domains at a per-link under lxdbr0
[20:02] <xnox> does above make sense? i haven't tried this, just going by the manpages.
[20:03] <nacc> xnox: yep it does, testing it now
[20:03] <nacc> xnox: nice! i think that does it
[20:03] <nacc> xnox: well that makes --status show it
[20:04] <nacc> xnox: but systemd-resolve still doesn't resolve it? odd
[20:04] <nacc> xnox: oh it made it ipv6 only
[20:04] <nacc> xnox: ok, i think i can tweak it from here
[20:05] <xnox> it should just work.
[20:05] <xnox> e.g. $ getent ahosts cute-animal
[20:05] <xnox> should return ipv6 and ipv4 for cute.animal.lxd
[20:05] <xnox> should return ipv6 and ipv4 for cute-animal.lxd
[20:06] <nacc> xnox: agreed, but it doesn't :) ... trying to figure out why
[20:06] <nacc> xnox: http://paste.ubuntu.com/24919265/
[20:06] <nacc> xnox: and still some running containers resolve and some don't
[20:07] <xnox> that's weird.
[20:07] <xnox> your setup looks very odd.
[20:07] <xnox> i'll play with things locally, to see if i can configure it to do what is needed right.
[20:08] <xnox> and what is your current output of systemd-resolve --status?
[20:08] <nacc> xnox: sure, i'd appreciate it! (i'm on artful, fwiw)
[20:08] <xnox> and did you restart both networkd and resolved?
[20:08] <nacc> xnox: yep, restarted both
[20:08] <nacc> xnox: http://paste.ubuntu.com/24919275/
[20:08] <nacc> xnox: note that beofre, lxdbr0 had LLMNR/IPv4 and IPv6
[20:11] <xnox> that looks correct to me.
[20:11] <xnox> nacc, now I see you have _both_ lxd and lxc, are the names that are not working are for the lxc containers, rather than lxd containers?
[20:12] <xnox> e.g. containers that are running, in the output of $ lxc list -> should be resolvable as short names, and hopefully as long names too.
[20:21] <cyphermox> nacc:
[20:21] <cyphermox> are you connected to the VPN?
[20:21] <cyphermox> s/the/a/
[20:23] <nacc> xnox: no, only lxd containers
[20:23] <nacc> xnox: i have no actual lxc containers (that bridge config is legacy)
[20:23] <nacc> cyphermox: not currently
[20:25] <cyphermox> ok
[20:26] <nacc> xnox: i agree 100% with your earlier statement: "containers that are running, in the output of $ lxc list ..." but sadly that has never been the case for me (i believe mwhudson also experiences this)
[20:28] <cyphermox> nacc: after you restarted systemd-networkd/systemd-resolved, did you restart lxd as well?
[20:29] <cyphermox> ie. do you have an IP for lxdbr0?
[20:46] <mapreri> slangasek: actually, I was thinking of demoting it from release to -proposed, not a complete removal.  I believe at some point the maintainer is going to fix what he caused not so long ago…
[20:56] <slangasek> mapreri: demoting instead of deleting clutters update-excuses.  If we're not fixing it, I'd like a bug ref and to delete it, and then bring it back when it's reuploaded to Debian with the fix
[21:03] <mapreri> slangasek: what I "fear" is that once deleted, nobody is going to notice that it's fixed in debian, and the auto-syncer is not going to bring it back by itself…
[21:05] <mapreri> then, for a package with popcon 12 in debian I probably won't care much
[21:05] <mapreri> slangasek: I'll file a bug later in the process if no fix comes out of nothing, just for a change.
[21:05] <slangasek> mapreri: that's a bug in the autoimporter in my view, which I intend eventually to fix; and I do run the importer manually in the meantime to make sure we pick those up
[21:06] <mapreri> oh, cool, that's nice to hear
[22:00] <nacc> cyphermox: heh, so restarting lxd also causes systemd-resolved to peg cpu
[22:02] <nacc> cyphermox: interesting, restarting the containers is causing them to show up as resolve-able. Which makes sense, I suppose, they have to re-issue their dhcp requests.
[22:02] <nacc> cyphermox: let me reboot
[22:12] <nacc> cyphermox: urgh, on reboot, my systemd-resolved --status changed back to not be per-link somehow...
[22:12] <nacc> cyphermox: restarting both networkd and resolved, the per-link DNS and domain come back
[22:18] <nacc> cyphermox: hrm, but the 'Current Scopes' is now "none"
[22:28] <nacc> cyphermox: well, i'm not sure what changed, maybe the last lxd restart did it, but now the scopes is "DNS LLMNR/IPv4 LLMNR/IPv6" but and 2 of 3 freshly started containers resovle from the host, but systemd-resolved is pegging cpu ...