[09:42] <GunnarHj> sil2100: Thanks for the bionic upload for bug #1778041. Want to mention that it resulted in much fewer binaries than is present in bionic-release. Is that a problem? (I hope not.)
[09:46] <sil2100> GunnarHj: I don't think so, sometimes microreleases just drop binary packages so yeah, but I must say I didn't have experience with such cases before - accepted it as it seemed the logical way to go
[09:46] <sil2100> Since it's either that or leaving it busted
[10:03] <GunnarHj> sil2100: That's what I thought/hoped. There is an additional aspect with the xenial one - there is already stuff the old way in bionic-updates.
[10:04] <GunnarHj> sil2100: s/bionic-updates/xenial-updates/
[10:28] <abeato> sil2100, is it a good time for a review of https://github.com/CanonicalLtd/ubuntu-image/pull/155 ?
[13:01] <g40> Greetings. Can anyone help? Trying to update a chroot'd 18.04 base image on an 18.04 host. `Get:3 http://ports.ubuntu.com/ubuntu-ports xenial-backports InRelease [107 kB] Err:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease   Couldn't create temporary file /tmp/apt.conf.vN6blL for passing config to apt-key`
[13:02] <g40> filesystem is writable. `ls -als /tmp total 12 4 drwxr-xr-x  2 root root 4096 Aug 13 12:55 . 4 drwxr-xr-x 22 root root 4096 Aug 13 12:38 .. 4 -rw-r--r--  1 root root    6 Aug 13 12:57 x`
[13:02] <ahasenack> g40: shouldn't /tmp be 1777?
[13:04] <g40> @ahasenack boom! great catch, thank you.
[13:04] <udevbot> Error: "ahasenack" is not a valid command.
[13:40] <scientes> mvo, any questions about command-not-found?
[13:40] <mvo> scientes: in a meeting right now, sorry. but excited about your C implementaton, I think its pretty cool to have that
[13:41] <scientes> hit me up
[13:41] <scientes> (later)
[13:46] <mvo> scientes: now :) so I think the C implementation is great, low latency/overhead and all that. the update-alternatives problem could be solved by making it a server side problem. I had this idea that we would store the commands in a new apt indexfile that is automatically downloaded by apt when c-n-f is installed. the apt snippet is super simple:https://paste.ubuntu.com/p/TW4gR7KnmF/  and here is an example what it would look like http://peop
[13:46] <mvo> le.canonical.com/~mvo/c-n-f/dists/bionic/main/cnf/
[13:46] <mvo> scientes: this would then be parsed by c-n-f into whatever format it wants
[13:47] <mvo> scientes: the server side extractor is also easyhttps://git.launchpad.net/~mvo/command-not-found-extractor/tree/
[13:47] <mvo> scientes: (unfortuantely I have some trouble getting the server side deployed but that is a different matter)
[13:47] <mvo> scientes: what do you think about this?
[13:48] <mvo> scientes: ideally this would be same for debian/ubuntu too, the format is pretty simple
[13:53] <scientes> yeah that is great
[13:56] <scientes> I'll code that up in the C version
[13:58] <mvo> scientes: thanks, lets coordinate with the proposal of the ideas to debian and please keep naging me about getting the extractor to the server side, it needs some admin work mostly I think
[14:01] <ahasenack> is gcc-8 the default one in cosmic?
[14:02] <scientes> ahasenack, $ ls -al /usr/bin/gcc
[14:02] <scientes> lrwxrwxrwx 1 root root 5 Jul 21 00:14 /usr/bin/gcc -> gcc-8
[14:02] <ahasenack> trying to figure out this error in a ppc64el build: cc1plus: error: unrecognized command line option ‘-Wno-deprecated-register’ [-Werror]
[14:02] <ahasenack> same package builds in the other arches
[14:02] <ahasenack> well, is still building. so far amd64, s390x and i386 passed
[14:03] <ahasenack> thanks scientes
[14:04] <tomreyn> is it known and expected that changing the upgrade-manager release-upgrade prompt to 'normal' enables starting an upgrade from 16.04 to 18.04 without -d ? (and apparently that fails?
[14:05] <scientes> that should always work even without -d
[14:12] <tomreyn> scientes: 16.04 -> 18.04 LTS upgrade is not enabled, yet, no.
[14:17] <scientes> oh my bad
[15:34] <slashd> seb128, based on our last week discussion, dgadomski_ did the MP for both LPs (dgadomski and tseliot) : https://code.launchpad.net/~dgadomski/ubuntu/+source/gdm3/+git/lp1782152/+merge/352976, it is set to "Need review". According to your process, should I wait for that MP to be approved/merged before uploading ?
[16:06] <slashd> seb128, basically what are the desktop team expectations according to your process before tseliot or I can upload gdm3 for Bionic (both LPs) which has a MP "Needs review" and Xenial (dariusz bug only)
[16:38] <ahasenack> hi, on a ppc64el lxd container (haven't tried elsewhere), dpkg-buildflags in cosmic returns -O3, instead of -O2
[16:39] <ahasenack> I'm trying to track down where that is coming from
[16:39] <ahasenack>  /etc/dpkg/* has nothing
[16:39] <ahasenack> any other ideas?
[16:39] <ahasenack> dpkg-buildflags --status output: https://pastebin.ubuntu.com/p/WXPwsbT5H9/
[16:40] <ahasenack> in a lxd container in my laptop, amd64, I get -O2 in cosmic
[16:41] <ahasenack> ah
[16:41] <ahasenack>  /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm
[16:41] <ahasenack> if arch ppc64el, set -O3
[16:41] <ahasenack> amazing
[16:41] <ahasenack> rbasak: ^ FYI
[16:42] <ahasenack> "-g -O3" actually
[16:43] <cjwatson> Yes, it was a specific requirement from the port's sponsor AIUI
[17:06] <ahasenack> hi guys, any idea why adding -O3 would enable -Werror=format=truncation?
[17:07] <ahasenack> https://gist.github.com/panlinux/4716e167c2e06612b28be4b9f8f2b52b scroll all the way to the right, the only difference between the two g++ command lines is the last -On I added
[17:07] <ahasenack> -O3 fails, -O2 works
[17:07] <ahasenack> (it was easier than editing -O2/-O3 inside the long command line, but has the same result)
[17:10] <seb128> slashd, no, it's fine, go ahead with the upload and I'm going to review/merge it
[17:13] <cjwatson> ahasenack: the GCC manual says that -Wformat-truncation sometimes estimates the number of bytes that will be written based on optimisation-level-dependent heuristics
[17:13] <cjwatson> "While enabling optimization will in most cases improve the accuracy of the warning, it may also result in false positives."
[17:14] <ahasenack> hm
[17:14] <cjwatson> You'll need to analyse the error manually and see whether it's a true overflow
[17:15] <ahasenack> I could try -O2 *with* -Wformat-truncation
[17:15] <cjwatson> If it's a false positive, then sometimes carefully-chosen assert() calls are enough to hint the compiler into what's going on
[17:15] <ahasenack> if that triggers again, then it's not the optimize, right
[17:15] <cjwatson> No, you misunderstand
[17:16] <cjwatson> -Wformat-truncation is enabled by default, but behaves differently depending on the optimisation level, because that influences the heuristics that it uses to analyse how many bytes will be written
[17:17] <cjwatson> Before going any further, you should analyse the code path that the compiler is complaining about and see whether it's actually a potential overflow
[17:18] <cjwatson> If it is, then fix it; if it isn't, then maybe there's an assert you can add to help the compiler prove that it isn't
[17:26] <rbasak> ahasenack: I'm not sure what the specific issue is that you're working on, but it might be acceptable to override it down to -O2 for the time being and leave a bug open if you're trying to land something.
[17:26] <ahasenack> rbasak: it's the squid build I mentioned in the standup
[17:26] <ahasenack> that it only failed in ppc64, and at that time I saw that -O3 was used, and I thought it was something new in cosmic, not that it was ppc64 exclusive
[17:27] <rbasak> Does it fail with -O3 on amd64?
[17:28] <ahasenack> it should, let me check
[17:34] <sarnold> -O3 ppc64el reminds me of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905868  (probably just coincidence)
[17:34] <ahasenack> cjwatson: as far as I can see, the truncation can indeed happen. Target buffer is 64 bytes, source string can be up to 3*256+10
[17:35] <ahasenack> upstream seems aware: http://squid-web-proxy-cache.1019090.n4.nabble.com/compiler-Error-tp4686058p4686065.html
[17:35] <ahasenack> this error is a bit down in that page
[17:35] <ahasenack> I also got the first one, but that one was easy to fix
[17:39] <ahasenack> heh, look at what I found: https://bugs.squid-cache.org/show_bug.cgi?id=4875
[17:40] <ahasenack> with a pr and a work-in-progress patch
[17:40] <ahasenack> goo
[17:40] <ahasenack> d
[18:19] <tsimonq2> !dmb-ping
[18:19] <tsimonq2> 40 mins, but I'd really be happy to have quorum. ;)
[18:19] <slashd> tsimonq2, I'll be there
[18:19] <tsimonq2> Thanks!
[19:01] <tsimonq2> !dmb-ping For real this time
[19:01] <tsimonq2> darnit
[19:01] <tsimonq2> !dmb-ping | For real this time
[19:01] <tsimonq2> I hate how ubottu is inconsistent in what it wants you to pipe and what it doesn't.
[19:02] <Unit193> It isn't, you pipe !info as well as factoids.
[19:11] <tsimonq2> Unit193: Oh?
[19:11] <tsimonq2> Hmm.
[20:33] <tsimonq2> infinity: So, I'm now a Core Developer: https://lists.ubuntu.com/archives/ubuntu-devel/2018-August/040436.html
[20:34] <tsimonq2> infinity: I think you said you wanted to push a Core Developer-only DMB policy at one point, after I became a Core Developer.
[20:34] <tsimonq2> infinity: So, there you go. :)
[21:04] <infinity> tsimonq2: \o/
[21:04] <infinity> tsimonq2: Congrats.
[21:04] <tsimonq2> infinity: Thanks!