[01:00] <Phanes> hello
[01:01] <Phanes> can i get an explanation of why we have /lib32 and /lib instead of, say, /lib -> /lib64 for 64bit systems and /lib -> /lib32 for 32bit systems and just use that symlink location
[04:07] <sarnold> Phanes: hopefully useful https://wiki.debian.org/Multiarch
[04:20] <Phanes> do you also have the build options and steps used in your initial cross-compiler environment for building ubuntu or did you literally just take debian and change stuff around
[04:23] <sarnold> heh, good question. I wonder if launchpad has history from the early days or not
=== Guest63440 is now known as RAOF
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
[08:29] <pitti> xnox: sorry for the delay in reviewing https://github.com/systemd/systemd/pull/5545, last week was a bit crazy
[08:29] <pitti> xnox: I promise to do a timely review/landing in the next (probably final) round :)
[08:42] <cpaelzer> xnox: would you mind taking a look at sponsoring bug 1673491
[08:42] <ubottu> bug 1673491 in libnl3 (Ubuntu) "[Zesty] libnl3 Segmentation fault in sriov environments" [Critical,New] https://launchpad.net/bugs/1673491
[08:43] <cpaelzer> xnox: you were uploading the base version, and I prepped a fix in a bileto ppa (now already verified by reporter)
[08:44] <happyaron> Saviq: would you mind to test the new zfs packages? it works for me locally
=== maclin1 is now known as maclin
[09:08] <Laney> bdmurray: SRU> because it's expected for things to be in proposed for SRUs for a long time
[09:11] <Laney> bdmurray: I suppose you could make the delay configurable per release, but even then > 10 days is reasonably common
[09:24] <freedwhayt> Why ubuntu-16.04.2-desktop-amd64.iso has /usr/share/initramfs-tools/hooks/klibc^i-t instead of "-"klibc? initramfs-tools-core_0.122ubuntu8.8_all.deb when extracted with "dpkg-deb -x" shows klibc file but when installed it becomes klibc^i-t.
[09:30] <infinity> freedwhayt: See the klibc-utils preinst.
[09:31] <infinity> freedwhayt: Or "dpkg -S /usr/share/initramfs-tools/hooks/klibc"
[09:54] <freedwhayt> infinity: I did reinstall, I did rebuild package myself. Nothing helps.
[09:57] <freedwhayt> I dont want to complain but initramfs-tools-core and klibc-utils both contain /usr/share/initramfs-tools/hooks/klibc.
[10:01] <freedwhayt> diversion by klibc-utils from: /usr/share/initramfs-tools/hooks/klibc \n diversion by klibc-utils to: /usr/share/initramfs-tools/hooks/klibc^i-t should mean something I dont understand.
[10:12] <cjwatson> Phanes: We don't have the full bootstrap history available, but in general we start new Ubuntu ports using the corresponding Debian port as a baseline since it's a whole lot less effort.  There have been a couple of exceptions when we've done a port in advance of Debian.  But in any case the bootstrapping process involves repeated rebuilds until we're confident that the path we took to get ...
[10:12] <cjwatson> ... there doesn't matter.
[10:14] <cjwatson> sarnold: The early days of the amd64 and i386 architectures (and powerpc for that matter) were before Launchpad existed in any case ...
=== _salem is now known as salem_
[12:47] <pitti> cjwatson: hey Colin, how are you?
[12:48] <pitti> cjwatson: was it ever proposed to not enable ssh.service by default, but instead use ssh.socket and socket activation? This would avoid the need for that nasty /etc/network/if-up.d/openssh-server (which is a race condition and thus sometimes causes connection errors right after bringing up an interface)
[12:49] <pitti> it also avoids a running openssh master as long as nobody uses it
[12:54] <cjwatson> pitti: Hi.  There's a section in README.Debian about why I'm not doing that.
[12:55] <pitti> cjwatson: ah, thanks!
[12:55] <pitti> cjwatson: I suppose using IP_FREEBIND would be an even better solution to get rid of /etc/network/if-up.d/openssh-server
[12:56] <cjwatson> Perhaps; I haven't tried.
[12:56] <cjwatson> It would certainly be nice to ditch that hack.
[12:57] <pitti> cjwatson: I can't actually reproduce the necessity of that hack
[12:57] <pitti> I removed /etc/network/if-up.d/openssh-server, ifdown ens3, restart ssh.service, ifup ens3, and I can connect just fine
[12:57] <cjwatson> https://bugzilla.mindrot.org/show_bug.cgi?id=2512
[12:57] <ubottu> bugzilla.mindrot.org bug 2512 in sshd "Use IP_FREEBIND if available for sshd listening socket" [Enhancement,New]
[12:58] <pitti> cjwatson: thanks for the heads-up!
[12:58] <cjwatson> I would have to trawl back through bug history to work out what exactly prompted the hack
[13:05] <pitti> I was mostly wondering as Fedora doesn't have such a hack, but doesn't enable sshd.socket by default either (probably for similar reasons); I'll do some git archaeology
[13:07] <pitti> bug 103436
[13:07] <ubottu> bug 103436 in openssh (Ubuntu) "sshd not reconfigured by /etc/network" [Wishlist,Fix released] https://launchpad.net/bugs/103436
[13:07] <cjwatson> Our README.Debian links to a related Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=963268
[13:07] <ubottu> bugzilla.redhat.com bug 963268 in openssh "add socket activated sshd units to the package" [Unspecified,Closed: rawhide]
[13:08] <pitti> hm, there is no reproducer or much justification in #103436, and it obviously works with most real-life use cases; I wonder if that only applies to some restricted ListenAddresses or AddressFamily or so
=== JanC is now known as Guest30327
=== JanC_ is now known as JanC
[13:47] <tjaalton> systemd-resolve seems to be broken when using shortnames, at least of hosts on my local net with 192.168.1.1 as the dns server
[13:47] <tjaalton> with fqdn it's fine
[13:48] <tjaalton> but with a shortname it just says "no servers could be reached
[13:48] <tjaalton> "
=== hikiko is now known as hikiko|bbl
=== JanC_ is now known as JanC
=== hikiko|bbl is now known as hikiko
[16:40] <sarnold> cjwatson: yeah, I figured that the early ubuntu days would predate launchpad, but I also figured the pioneers might have stuffed all the history into launchpad just to be thorough :)
[17:40] <nacc> slangasek: is there a reason this would not be acceptable to you (for dep3changelog): http://paste.ubuntu.com/24216487/ ? it actually fails for the example on the dep3 page too (doesn't extract the bug info). It's not particularly clear on which 'header' is which in that example, admittedly, so i'm also happy to ask for clarification from the dep3 owner :)
[17:55] <rbasak> slashd: so I've updated/announced to ubuntu-devel@ and ubuntu-news-team@, created and added you to ~ubuntu-sru-developers, adjusted various pages in the wiki and asked the TB to add the new ACL entry. I think that's everything I need to do. Hopefully it'll all work once the TB have made the change for us.
[17:57] <slashd> rbasak, tks
[17:57] <slashd> much appreciated
[17:58] <slashd> rbasak, does this include nomination ? or it has to be done by the TB ? I don't seem to have the right to do it
[17:58] <slashd> at the moment
[17:58] <rbasak> Nomination might work once the TB have made the ACL change. I'm not sure though. Let's see.
[17:59] <slashd> rbasak, sound good, tks again
[18:13] <slangasek> nacc: only that I wouldn't be the one accepting it, I originally wrote the script but the devscripts maintainers own it now :)
[18:13] <nacc> slangasek: right it just hasn't been changed since your original, and i'm not sure if the code is incorrect or the spec is :)
[18:14] <nacc> slangasek: so just wanted to run it past you before i send to them
[18:14] <slangasek> nacc: I was probably excessively strict because I didn't want to write a more complete parser, just one that did what I needed
[18:15] <nacc> slangasek: ack
[19:00] <nacc> cyphermox: i think my systemd-resolved (17.04) is quite unahppy, but i have no idea how to debug -- `nslookup ...` returns SERVFAIL, but if I do `nslookup ... 8.8.8.8` (or 192.168.1.1) it works. Seems to only be true for some domains, too
[19:01] <cyphermox> nacc: are you connected to a VPN?
[19:01] <sarnold> nacc: among my DNS pals dig is considered the One True Way to debug dns
[19:01] <nacc> cyphermox: not currently
[19:01] <nacc> sarnold: fair enough, `dig` reports the same :)
[19:02] <sarnold> there we go :)
[19:02] <cyphermox> right, dig would report the same thing
[19:03] <nacc> http://paste.ubuntu.com/24216827/
[19:03] <nacc> e.g. (my banking subpage refuses to load currently :)
[19:03] <cyphermox> nacc: what you would want to do, I guess, is start /lib/systemd/systemd-resolved in a separate terminal, from the command-line, after stopping the service using systemctl, and then do systemd-resolve (whatever) again to get the logs
[19:04] <nacc> cyphermox: thanks!
[19:04] <cyphermox> also, it's possibly "just" that resolved isn't running
[19:04] <jbicha> nacc: I had to reopen https://bugs.debian.org/773426
[19:04] <ubottu> Debian bug 773426 in imagemagick "imagemagick: Imagemagick not run from menu in Mate" [Important,Open]
[19:04] <cyphermox> file a bug, or pastebin the logs from systemd-resolved and I'll look
[19:04] <nacc> cyphermox: thanks again!
[19:05] <nacc> jbicha: :(
[19:08] <nacc> cyphermox: looks to be a dnssec issue? http://paste.ubuntu.com/24216847/
[19:09] <cyphermox> err
[19:09] <cyphermox> is that the whole thing?
[19:09] <nacc> cyphermox: yeah
[19:13] <cyphermox> this is ridiculous
[19:13] <cyphermox> ok, I was missing setting SYSTEMD_LOG_LEVEL=debug
[19:13] <cyphermox> can you do this again just so I make sure I'm getting the same behavior here?
[19:14] <nacc> cyphermox: run systemd-resolve again?
[19:14] <cyphermox> systemd-resolved
[19:14] <cyphermox> but start it as so:
[19:14] <cyphermox> sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-resolved
[19:14] <nacc> cyphermox: ah ok
[19:14] <cyphermox> then do systemd-resolve www.perdu.com for instance.
[19:16] <cyphermox> and if you do it again it should probably get it right the second time
[19:17] <cyphermox> ie. dig banking.firsttechfed.com twice, the first would SERVFAIL, but the second should succeed, immediately after restarting systemd-resolved
[19:17] <nacc> cyphermox: http://paste.ubuntu.com/24216896/ that is a dig on www.perdu.com then banking.firsttechfed.com
[19:17] <nacc> cyphermox: let me try it with twice in a row
[19:18] <nacc> cyphermox: i consistently get SERVFAIL
[19:18] <cyphermox> ok
[19:19] <cyphermox> for now, to unblock you let's modify /etc/systemd/resolved.conf to set DNSSEC=no and restart systemd-resolved
[19:19] <nacc> cyphermox: i should say the above log was `systemd-resolve www.perdu.com` not `dig`
[19:19] <cyphermox> it shouldn't matter
[19:20] <cyphermox> systemd-resolve just always asks resolved
[19:20] <nacc> cyphermox: yep, understood
[19:20] <nacc> cyphermox: and DNSSEC=no does work
[19:24] <nacc> cyphermox: i'm happy to just chalk this up to some configuration issue on my end (or with my ISP even) -- but if there's anything i can do to help debug (now or later), let me know!
[19:31] <cyphermox> I don't think it's an issue with your configuration, probably more a problem that is caused by your router supporting DNSSEC, but something else on the path not supporting it
[19:32] <nacc> cyphermox: ah is ee
[19:32] <cyphermox> or you know, the other way around, possibly your router can't do DNSSEC, and the logic to downgrade to not care is broken
[19:33] <cyphermox> nacc: I suppose that only started breaking today?
[19:35] <nacc> cyphermox: i'm not 100% sure. I think I saw the same last week and just ignored it (as sometimes my bank has periodic website outages and it wasn't urgent)
[19:35] <nacc> cyphermox: i only noticed more clearly today because they didn't state there was an outage :)
[19:36] <cyphermox> I'm wondering if it's not that say, they screwed up their DNSSEC?
[19:36] <nacc> cyphermox: i wonder too -- i guess i need to try and find another address that has the problem ;)
[19:43] <cyphermox> looks like your provider is missing a DS record
[19:43] <cyphermox> maybe try cloudflare.com?
[19:44] <nacc> cyphermox: which provider do you mean? is it an ISP issue?
[19:44] <cyphermox> nacc: no, I think this is a site owner issue.
[19:45] <nacc> cyphermox: oh i see -- i can probably ping their ownership, they are pretty responsive
[19:45] <nacc> gaughen: --^ you have the same bank, right?
[19:45] <cyphermox> compare with cloudflare.com, I'd venture that works correctly if you re-enable DNSSEC.
[19:45] <nacc> gaughen: first tech, that is :)
[19:45] <nacc> cyphermox: alright, i will look into it, thanks!
[19:46] <cyphermox> moar coffee.
=== led2 is now known as led1
[20:21]  * gaughen looks up
=== mwhudson_ is now known as mwhudson
=== tumbleweed_ is now known as tumbleweed
=== mapreri_ is now known as mapreri
=== Spads_ is now known as Spads
=== ivoks_ is now known as ivoks
=== Saviq_ is now known as Saviq
=== iahmad_ is now known as iahmad
=== robru_ is now known as robru
=== ulkesh_ is now known as ulkesh
[20:51] <infinity> jdstrand: FWIW, "rm_conffile won't remove the conffile if it's modified" is only sort of true.  It will rename it to $name.dpkg-bak in that case.
[20:52] <infinity> jdstrand: And if apparmor is loading *.dpkg-* namespaced files, the bug is in apparmor (please tell me it doesn't).
[20:52] <jdstrand> infinity: it doesn't, and I forgot about the -bak bit. it's been a while since I rm_conffiled
[20:52] <infinity> jdstrand: Ditto for typical editor backup extensions, etc.  This is why most people eventually settle on a whitelist of acceptable filenames instead of blacklisting.
[20:54] <infinity> jdstrand: Anyhow, I stand by my comment in the other PR that an upgrade strategy that assumes we don't know how to use our tools is probably not reasonable. :P
[20:54] <jdstrand> no, that isn't reasonable
[20:55] <jdstrand> I just checked the apparmor sources and we won't ever load .dpkg-bak (or -new, -old or -dist), as well as various other extensions
[20:56] <infinity> jdstrand: All that aside, thanks for the enlightening interjection that profile path and the file it's referencing don't need to match.  If someone had pointed that out last week, this SRU would probably be released by now. :/
[20:56] <jdstrand> np. I only just saw it today cause I was on holiday last week
[21:37] <nacc> teward: fyi, LP: #1673056
[21:37] <ubottu> Launchpad bug 1673056 in nginx (Ubuntu) "Upgraded nginx-upload-progress module has showstopper" [Undecided,New] https://launchpad.net/bugs/1673056
=== daniel1 is now known as Odd_Bloke
[21:57] <nacc> jgrimm: should LP: #1634989 be fix-released?
[21:57] <ubottu> Launchpad bug 1634989 in rabbitmq-server (Ubuntu) "Segfault on rabbitmq-server start" [Medium,Triaged] https://launchpad.net/bugs/1634989
[21:59] <jgrimm> nacc, yep i just commented as much
[21:59] <nacc> jgrimm: ok, could be i hadn't refreshed yet -- do you have perms to change it or want me to?
[22:00] <jgrimm> nacc, worked! thanks sir
[22:00] <nacc> jgrimm: awesome, np -- was just checking up :)
[22:00] <nacc> dannf`: i wonder, have you tried rebuilding emacs25 25.1+1-2ubuntu2 in a arm64 env?
=== Riddelll is now known as Riddell
[22:11] <dannf`> nacc: i don't know if i ever did
[22:12] <nacc> dannf`: just wondering if that one still builds in arm64 with current zesty, or if it was a fluke
[22:22] <dannf`> nacc: well, i've had trouble reproducing the failure even w/ the -proposed version
[22:23] <nacc> dannf`: right, i recalled that, would just be another datapoint (but admittedly not necessarily that helpful)
[23:22] <tyhicks> bah, my security updates for nvidia-graphics-drivers-375 landed in universe instead of restricted
[23:22] <tyhicks> infinity: can you move those to the correct place?
[23:26] <infinity> tyhicks: Did that literally just happen? rmadison hasn't caught up to reality yet.
[23:26] <infinity> Ahh, indeed.
[23:26] <tyhicks> infinity: yes - it just happened
[23:30] <infinity> tyhicks: Fixed.  Err.  Crap.  I should have fixed it after the updates copies.
[23:30]  * infinity fixes harder.
[23:31] <tyhicks> thank you!
[23:32] <infinity> tyhicks: Maybe fixed.  I'll check again when the archive settles.
[23:32] <tyhicks> infinity: sounds good
[23:53] <nacc> rbasak: for `usd clone`'s usage of fetch_remote, shouldn't lpusip not existing be fatal?
[23:53] <nacc> rbasak: lpmep not existing is whatever, but i'm not sure we have a reasonable usecase for using usd without having an imported tree?