[01:21] <xnox> jbicha, i even have commit access to debian's git and we do co-ordinate on common things.
[01:25] <xnox> mbiebl, there are multiple issues with fallback handling if resolved is used by default (true for Ubuntu, not true for Debian). What I guess jbicha doesn't realise is that we are doing extensive code review and DNS resolution and networking configuration improvements. Hence e.g. already two CVEs identified and disclosed by Canonical security team in resolved. (One had other reporters as well) and the privacy settings we are adjusting. Indeed, changing
[01:25] <xnox> fallback defaults is a privacy issue for Ubuntu, but not for Debian.
[01:29] <sarnold> I fear aiming a fuzzer at systemd-resolved
[01:30] <sarnold> I tried once but never figured out how to build another object file in the codebase
[01:30] <sarnold> chrisccoulson's approach of just aiming it at a malicious server is good fun
[01:32] <xnox> indeed.
[01:35] <sarnold> .. but I'd really love to see someone aim a fuzzer directly at the functions.
[01:58] <sarnold> juliank: "uint8_t hostname[namelength + 2];"  -- I thought C++ committee decided against VLAs?
[02:01] <sarnold> juliank: '%02X%02X' -- that backslash feels way out of place. what does it do?
[07:01] <Unit193> LocutusOfBorg: Does the new screen in experimental fix the delta in Ubuntu?
[07:04] <LocutusOfBorg> Unit193, let me check
[07:04] <LocutusOfBorg> probably yes
[07:28] <juliank> sarnold: The C++ committee decided against it AFAIK, yes; but this is GNU C++ :) But should probably be allocated on the heap and have some length check or something. Not sure what you mean with a second part, where is a backslash in '%02X%02X'  (and which part of the code is that). That's both SOCKS support BTW which is in for quite some time already.
[08:09] <abeato> sil2100, hi, was wondering if ubuntu-image can build classic imagess?
[08:09] <sil2100> abeato: hey! Not yet, but it will
[08:10] <sil2100> abeato: it's on our roadmap
[08:11] <abeato> sil2100, ah, very nice... any rough idea on when that will happen?
[08:11] <sil2100> abeato: we're on the spec phase now, I'll know more once I have the plan finished
[08:13] <abeato> sil2100, great... meanwhile, which is the suggested way to create some sort of raw, customized, classic images? I'm playing with debootstrap + parted + kpartx at the moment
[08:13] <abeato> (which works, but maybe there is something more standardized)
[08:18] <juliank> abeato: Maybe you could use poettering's mkosi? (it's only in zesty and artful, though) There are probably a ton of other tools too
[08:19] <LocutusOfBorg> Unit193, seems syncable, doing it now
[08:20] <abeato> juliank, did not know about that tool, interesting suggestion, thanks
[08:37] <Unit193> LocutusOfBorg: Thanks.
[09:25] <juliank> Hmm, launchpad did not import apt from experimental yet, I'd have hoped 12 hours is enough for that
[09:36] <cjwatson> juliank: Importer setup bug - we'll be rolling out the fix today
[09:38] <juliank> cjwatson: ah, ok.
[09:50] <LocutusOfBorg> doko, hello, new binutils broke ghc build on arm64 :(
[09:50] <LocutusOfBorg>  /usr/bin/ld.gold: internal error in fix_errata, at ../../gold/aarch64.cc:1971
[09:55] <LocutusOfBorg> hello ScottK can you please check the new pyyaml logs? https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
[09:55] <LocutusOfBorg> I did import a new patch from jrtc27 and this one seems way better
=== Sir_Gallantmon is now known as Son_Goku
[11:26] <cjwatson> juliank: next importer run should work
[11:27] <juliank> cjwatson: thx
=== est31_ is now known as est31
=== est31 is now known as est
=== est is now known as est31
[12:20] <doko> LocutusOfBorg: does the BFD linker work?
[12:34] <LocutusOfBorg> doko, I don't know how to test :/ let me try
[13:48] <seb128> slangasek, hey, do you know who could be pinged about nplan autopkgtests blocking the  n-m update in artful while cyphermox_ is on vac?
[13:48] <seb128> jbicha, ^
[14:25] <slangasek> seb128: well, first it's not a new blocker, and second last I knew the root of these failures was believed to be in NM, so... :) I will mark it badtest for p-m.
[14:27] <slangasek> seb128: ah, but that was ppc64el-specific; why is NM triggering autopkgtest failures on other archs?  I'm not badtesting those without someone investigating to show it's not genuinely an NM regression
[14:27] <seb128> slangasek, define "new"? it's new since the n-m update
[14:27] <seb128> some problem with mtu handling
[14:28] <seb128> it could be a n-m issue/regression, it's just that cyphermox_ understood the issue at least a bit when I talked with him
[14:29] <slangasek> seb128: ok, well I don't believe he handed off that context to anyone.  Did he say it was definitely a test bug?
[14:31] <seb128> slangasek, it was discussed on https://irclogs.ubuntu.com/2017/06/22/%23ubuntu-desktop.html#t13:49
[14:31] <seb128> he wrote "and indeed the mtu issue seems like a genuine regression"
[14:31] <slangasek> seb128: that implies a regression in NM, surely?
[14:32] <seb128> slangasek, or netplan doing something not documented/supported which happened to work but stopped doing so
[14:32] <slangasek> "seb128: MTU is special in that so far we've been relying on systemd to apply the change (via udev) rather than NM, so it might not write anything in this case"
[14:32] <slangasek> seb128: I'll look into it later this morning
[14:32] <seb128> thanks
[14:45] <chiluk_> tjaalton: ... hey man... so i've been hitting a few bugs related to slowdown in chromium and chrome on skylake *(slow page scrolling, flashing, etc... there are quite a few bugs out there on this)... At the moment I've moved to using the xserver-xorg-video-intel-hwe-16.04 driver.  Is there anything else I can do to help you out on this?  I'm no X stack expert, but I can be pretty persistent.
=== chiluk_ is now known as chiluk
[15:47] <betanu701> Hi all, I was wondering if anyone can point me in the right direction on getting a tarball of ubunutu. I am trying to install a 64bit version in wsl but the only ones I can find are x86
[15:48] <betanu701> ubuntu* too many us!
[15:51] <nacc> betanu701: what is wsl?
[15:51] <nacc> betanu701: a 'tarball' of ubuntu doesn't make sense to me. ubuntu is a distribution
[15:51] <betanu701> windows subsystem linux
[15:51] <nacc> !ubuwin | betanu701
[15:51] <ubottu> betanu701: Canonical and Microsoft have announced that Windows 10 will be able to run Ubuntu programs without needing porting/recompilation. This functionality is still in beta and is not supported in #ubuntu. For discussion and support, see #ubuntu-on-windows.
[15:52] <nacc> betanu701: that thing?
[15:52] <nacc> betanu701: or something else?
[15:52] <betanu701> yes that thing. I will check out that channel. Thanks!
[16:13] <nacc> bdmurray: re: LP: #1574670, it's not fix released, do you agree?
[16:13] <ubottu> Launchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [Undecided,Confirmed] https://launchpad.net/bugs/1574670
[16:16] <bdmurray> nacc: sure
[16:16] <nacc> bdmurray: thanks, updated the bug states
[16:25] <sarnold> juliank: interesting. I copy-and-pasted that \ right from the link https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=2851ec6cf037d552118b885be0dd7796d74730c6 here... but I don't see it now when I reload. Crazy.
[16:26] <jbicha> bdmurray: did you see that u-release-upgrader's artful autopkgtests are failing? new pep8 error 'E722 do not use bare except'
[16:26] <jbicha> http://autopkgtest.ubuntu.com/packages/u/ubuntu-release-upgrader/artful/amd64
[16:27] <bdmurray> jbicha: No, shouldn't I get emails about that?
[16:28] <jbicha> I don't believe autopkgtest sends automated emails at all
[16:30] <nacc> you'll get an e-mail eventually taht it's stuck in -proposed for X days
[16:30] <jbicha> this is how it was fixed in another pkg: https://launchpadlibrarian.net/324926055/update-notifier_3.179_3.180.diff.gz
[16:31] <jbicha> webkit2gtk is stuck in proposed but no one in Ubuntu uploaded that
[20:13] <tjaalton> chiluk: try ppa:canonical-x/x-staging
[20:52] <chiluk> tjaalton: then what? would the plan then be to find fixes to cherry-pick?
[20:52] <chiluk> we have entire generations of Intel chips that are causing browser badness.
[20:52] <tjaalton> chiluk: this will hit xenial in 16.04.3
[20:52] <tjaalton> so you'd get upgraded to it anyway
[20:53] <chiluk> unless you aren't on the hwe stream.
[20:53] <chiluk> right?
[20:53] <tjaalton> right, those users are on -intel anywa
[20:53] <tjaalton> y
[20:54] <chiluk> how can you be so sure?  I'm sure there's lots of users out there who haven't figured out that they need to be on the -intel driver.
[20:54] <chiluk> are the fixes for all this slowdown known?
[20:54] <chiluk> basically can we backport the fixes into xenial-updates.
[20:54] <chiluk> rather backport the specific patches into xenial-updates.
[20:55] <tjaalton> I'm assuming you mean folks on -hwe-16.04 that are using the default driver, which is the modeset driver
[20:55] <tjaalton> stock xenial uses -intel, if it's installed
[20:56] <chiluk> actually I haven't checked is it possible to be on skylake or kaby-lake and not on the hwe stream?
[20:56] <tjaalton> yes it is
[20:56] <chiluk> and have a fully functional desktop?
[20:56] <tjaalton> because we enabled kbl on 16.04.1
[20:56] <tjaalton> I bet you
[20:56] <chiluk> yeah I bet you are correct.
[20:58] <chiluk> alright well I'lls tart with the x-staging + the default modeset, and see where that gets me.
[20:58] <chiluk> thanks tjaalton
[20:58] <tjaalton> the new xserver should fix at least some performance issues
[20:59] <tjaalton> which reminds me to update my skylake desktop on it..
[21:31] <mwhudson> Laney: you going to upload that session migration fix?
=== JanC_ is now known as JanC