[00:31] <Unit193> jbicha: Pinging with 1757574 as you did the aforementioned upload.
[00:31] <Unit193> LP 1757574
[00:31] <ubottu> Launchpad bug 1757574 in libappindicator (Ubuntu) "development libraries missing depends listed in *.pc files" [Undecided,New] https://launchpad.net/bugs/1757574
[00:32] <jbicha> Unit193: could you be more specific?
[00:33] <Unit193> jbicha: Eg libappindicator-dev should depend on libgtk2.0-dev, same for the gtk varient.
[00:36] <jbicha> do you want to submit a merge proposal? https://code.launchpad.net/~indicator-applet-developers/libappindicator/trunk.16.10
[00:36] <jbicha> lp:libappindicator
[00:39] <Unit193> Sure, I could do that if it gets it in.
[00:55] <Unit193> https://code.launchpad.net/~unit193/libappindicator/build-depends/+merge/341865
[00:59] <Unit193> (If you're wondering how one could have a build-depend on that but not libgtk2.0-dev, wxwidgets.)
[01:23] <Unit193> Thanks!
[09:28] <tseliot> doko: hi, any chance of getting the fix for gcc in 16.04 and 14.04? https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1750937
[09:28] <ubottu> Launchpad bug 1750937 in gcc-4.8 (Ubuntu) "4.4.0-116 Kernel update on 2/21 breaks Nvidia drivers (on 14.04 and 16.04) due to outdated gcc-4.8" [Undecided,Fix released]
[09:44] <doko> tseliot: I'm not sure what you're asking
[09:45] <doko> if it's about the retpoline patches, then you should ask the security team
[09:45] <anon^_^> hello
[09:45] <anon^_^> doko?
[09:46] <anon^_^> i was the user that reported an issue with reptoline missing in gcc-4.8
[09:46] <anon^_^> in ubuntu-kernel yesterday
[09:47] <tseliot> doko: this ^
[09:47] <anon^_^> i had a functional system with nvidia 384, updated to 3.13.0-143-lowlatency
[09:48] <doko> looks good to me: https://launchpad.net/ubuntu/+source/gcc-4.8
[09:48] <anon^_^> then kern.log began throwing errors
[09:48] <anon^_^> Mar 21 02:11:55 ****** kernel: [   60.800613] nvidia: version magic '3.13.0-143-lowlatency SMP preempt mod_unload modversions ' should be '3.13.0-143-lowlatency SMP preempt mod_unload modversions retpoline '
[09:48] <anon^_^> the nvidia driver was unloaded
[09:49] <anon^_^> actually it was 4:4.8.2-1ubuntu6
[09:49] <anon^_^> gcc version
[09:50] <anon^_^> removed both the kernel and nvidia 384, re-installed and it was still broken
[09:50] <anon^_^> modinfo nvidia-384 -k 3.13.0-143-lowlatency
[09:50] <anon^_^> vermagic:       3.13.0-143-lowlatency SMP preempt mod_unload modversions
[09:51] <anon^_^> ^ no retpoline flag
[09:51] <anon^_^> to get the nvidia driver to load i have to manually edit
[09:51] <anon^_^> # /usr/src/linux-headers-3.13.0-143/include/linux/vermagic.h
[09:52] <anon^_^> following sven's workaround
[09:52] <anon^_^> https://devtalk.nvidia.com/default/topic/1030325/nvidia-driver-installation-v387-26-on-ubuntu-16-04/
[09:52] <anon^_^> then i removed the nvidia module from dkms, re-installed, rebooted
[09:53] <anon^_^> there probably aren't very many people using 14.04 with it being close to EOL
[09:54] <anon^_^> but i doubt that most ubuntu users are going to be able to figure out what broke nvidia drivers or go through all that to fix it
[09:56] <anon^_^> if i remove that workaround from vermagic.h the nvidia module will not load
[09:58] <anon^_^> the issue is persistent across reboots and re-install
[10:10] <anon^_^> doko?
[10:16] <doko> sbeattie: ^^^  I have no idea about that ...
[11:54] <coreycb> sil2100: it seems like the accepted into proposed script needs updating if only per-release verification-done tags are accepted
[11:59] <sil2100> coreycb: it is updated, not sure why Brian's response had the old comment - for instance right now it's like this: https://bugs.launchpad.net/ubuntu/+source/httmock/+bug/1735160/comments/21
[11:59] <ubottu> Launchpad bug 1735160 in py-macaroon-bakery (Ubuntu Artful) "[SRU] Please backport python3-macaroonbakery 0.0.6-1 [universe] from bionic" [Undecided,In progress]
[11:59] <coreycb> sil2100: ok cool
[11:59] <coreycb> sil2100: thanks :)
[12:00] <sil2100> I'll poke Brian later, maybe he's missing a bzr pull or something ;)
[12:00] <sil2100> (but that's a very old change)
[12:02] <sil2100> bdmurray: hey! As per coreycb's pointer, it seems like you have a greatly outdated sru-review script? Looks like you're leaving outdated verification comments, like for instance in https://bugs.launchpad.net/horizon/+bug/1582725/comments/19
[12:02] <ubottu> Launchpad bug 1582725 in horizon (Ubuntu Xenial) "cinder_policy.json action does not match the Cinder policy.json file" [Medium,Fix released]
[12:04] <sil2100> bdmurray: I changed that string ages ago when we switched to the verification-done-SERIES enforcement
[13:38] <bdmurray> sil2100: I might have been in an old branch... I'll clean that up.
[13:58] <sil2100> bdmurray: thanks ;)
[14:40] <rbasak> sil2100: reminder to review bug 1466926 please
[14:40] <ubottu> bug 1466926 in apache2 (Ubuntu Xenial) "reload apache2 with mpm_event cause scoreboard is full" [Undecided,In progress] https://launchpad.net/bugs/1466926
[15:18] <sil2100> rbasak: ACK
[15:20] <rbasak> sil2100: thank you for the review
[17:13] <powersj> slangasek: LP: #1758113 is currently causing troubles with server ISO
[17:13] <ubottu> Launchpad bug 1758113 in python-cryptography (Ubuntu) "bionic: depends on package that does not exist" [Undecided,New] https://launchpad.net/bugs/1758113
[17:16] <powersj> ^ coreycb is this known?
[17:17] <slangasek> powersj: also reported as LP: #1758004; but I'm not sure what the actual bug is, python3-cffi-backend provides both virtual package names
[17:17] <ubottu> Launchpad bug 1758004 in Ubuntu on IBM z Systems "[Ubuntu 18.04] Error installing the "Basic Ubuntu Server"" [High,New] https://launchpad.net/bugs/1758004
[17:17] <coreycb> powersj: i don't know. my changes to that were no-ops.
[17:18] <slangasek> powersj: is python3-cffi-backend present on the ISO?
[17:18] <coreycb> powersj: Tristan might be a better contact
[17:18] <powersj> slangasek: it is not
[17:19] <slangasek> powersj: ok. does the error occur when trying to do an install of this task without a network apt source?
[17:20] <slangasek> powersj: my guess is that apt within the target is fine to do this installation, but our code to assemble the pool on the image fails to handle versioned provides
[17:21] <slangasek> in this case, we would've sidestepped the bug if the squashfs on the server ISO was the full server task
[17:21] <slangasek> xnox: ^^
[17:22] <xnox> slangasek, which server team rejected
[17:22] <xnox> slangasek, saying "oh no, people use server.iso, as a mini d-i.iso, and only install minimal by default"
[17:22] <xnox> slangasek, unless we ship multiple squashfs on the server.iso
[17:22] <slangasek> xnox: where/when was this reject?
[17:23] <xnox> slangasek, in an informal conversation.
[17:23] <xnox> slangasek, however that was in the context of disable tasksel /as well/. maybe they will be happy with a fatter squashfs. (and tasksel kept in tact)
[17:23] <xnox> i can re-raise that.
[17:24] <slangasek> xnox: yeah, I don't think that's a good rationale for this behavior anymore
[17:24] <slangasek> xnox: please re-raise it where I can participate in the discussion :)
[17:24] <xnox> slangasek, meet us in the pub, in cambridge, at 17:00 tomorrow
[17:24] <xnox> =)
[17:24]  * xnox giggles
[17:26] <slangasek> xnox: anyway, these days we are producing a "good" squashfs for the subiquity image, and it's a shame that we're not using it for the d-i image
[17:29] <slangasek> ? Unknown dependency python3-cffi-backend-api-min (<= 9729) by python3-cryptography
[17:29] <slangasek> ? Unknown dependency python3-cffi-backend-api-max (>= 9729) by python3-cryptography
[17:29] <slangasek> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/bionic/daily-20180322.log
[17:30] <slangasek> actually, this seems to be in germinate
[17:30] <slangasek> cjwatson: does germinate support versioned provides, in some version later than what we currently have on nusakan?
[17:31] <cjwatson> I don't think so.  Could I have a bug?
[17:31] <cjwatson> It shouldn't be too horribly difficult
[17:31] <slangasek> cjwatson: https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1758004
[17:31] <ubottu> Launchpad bug 1758004 in germinate (Ubuntu) "[Ubuntu 18.04] Error installing the "Basic Ubuntu Server"" [Undecided,Triaged]
[17:31] <cjwatson> Thanks.  I'd be happy to take a look, though probably not today
[17:36] <cjwatson> I do at least have a failing test case in place
[19:24] <sergiusens> slangasek: since I see you are on it, just wanted to say that the new dh-python broken our snapcraft pkg builds https://launchpadlibrarian.net/361662873/buildlog_ubuntu-bionic-amd64.snapcraft_2.40+18.04.2_BUILDING.txt.gz
[19:25] <sergiusens> *broke
[19:27] <sergiusens> there seems to be new copy logic in there
[19:27] <slangasek> sergiusens: please refer this to doko who made this post-FF change
[19:28] <sergiusens> ack, I'll log a bug
[19:33] <sergiusens> doko: LP: #1758142
[19:33] <ubottu> Launchpad bug 1758142 in dh-python (Ubuntu) "Recursive follow of symlinks" [Undecided,New] https://launchpad.net/bugs/1758142
[19:59] <slangasek> powersj, cjwatson: as a short-term hack to unbreak server, I think I'm going to try to have germinate on nusakan ignore versions entirely for provides calculation; AFAIK we don't have any versioned dependencies currently that will be incorrectly resolved to non-version-matching virtual packages as a result of this, and even if we do, the outcome is no worse than currently
[20:00] <powersj> slangasek: ok I would need to wait for tomorrow's ISO to re-test?
[20:00] <slangasek> powersj: I would retrigger a build immediately for testing
[20:00] <powersj> even better
[20:02] <slangasek> powersj: (and running now)
[20:02] <mwhudson> morning
[20:05]  * slangasek waves
[20:05] <slangasek> powersj: we should diff the .list files for each architecture, to make sure it's done what we expect
[20:08]  * powersj downloads the 20180322.list
[20:27] <slangasek> powersj: 20180322.1 done
[20:27]  * powersj waits on http://cdimage.ubuntu.com/ubuntu-server/daily/20180322.1/
[20:29] <slangasek> unfortunately the dh-python dpkg-dev fix landed at the same time so the diff is large
[20:30] <powersj> diff http://paste.ubuntu.com/p/xXpyH96ntG/
[20:30] <powersj> yeah
[20:30] <slangasek> -/pool/main/p/perl/libperl5.26_5.26.1-5_amd64.deb
[20:30] <slangasek> that part doesn't look good though
[20:30] <slangasek> +/pool/main/p/python-cffi/python3-cffi-backend_1.11.5-1_amd64.deb
[20:30] <slangasek> whereas that part does
[20:32] <slangasek> actually, even the perl stuff is consistent with the priority-mismatches fixup
[20:33] <powersj> diff with only changes: http://paste.ubuntu.com/p/8VHTTf57ds/
[20:33] <powersj> all the gcc and gnupg2 changes are expected?
[20:33] <slangasek> yes
[20:33] <slangasek> python3 -> dh_python was incorrectly pulling in dpkg-dev -> build-essential
[20:33] <powersj> ok I'll launch tests
[20:34] <slangasek> so actually 20180321 might be a better basis for comparison
[20:34] <slangasek> hmmm no, gcc was already in the mix in 20180321
[20:34] <slangasek> so nevermind
[20:35] <slangasek> I could revert this change and do another build for comparison
[20:35] <slangasek> powersj: ^^?
[20:35] <powersj> that might be good to make sure we don't let something slip through
[20:35] <powersj> I'll still launch on 22.1
[20:35] <slangasek> k, running
[20:39] <slangasek> the libperl5.26 change *looks* super-odd, but when I dig I am surprised to find that perl-base (/usr/bin/perl) does not depend on libperl.  Sooooo even this is plausible
[20:41] <slangasek> cjwatson: you mentioned a failing test case, perhaps you also arrived at something like https://code.launchpad.net/~vorlon/germinate/+git/germinate/+ref/lp.1758004
[20:48] <powersj> slangasek: smoke test install just completed successfully
[20:50] <cjwatson> slangasek: Similar kind of thing; thanks
[20:52] <jbicha> cking: why did you reintroduce xchat-gnome to Ubuntu? LP: #1758163
[20:52] <ubottu> Launchpad bug 1758163 in xchat-gnome (Ubuntu) "Please remove xchat-gnome from Ubuntu (again)" [Undecided,New] https://launchpad.net/bugs/1758163
[20:52] <cking> jbicha, it can be killed, it's too much hassle to maintain IMHO
[20:53] <jbicha> could you comment on the bug please then :)
[20:54] <cking> done
[20:55] <jbicha> apw: since you sponsored xchat-gnome back into Ubuntu, could you look into removing it now? ^
[20:57] <slangasek> jbicha, cking, apw: done
[20:57] <jbicha> cool, that was really fast :)
[20:58] <cking> thank
[20:58] <cking> s
[21:01] <slangasek> oh no, we removed his irc client from the archive and he fell offline
[21:02] <acheronuk> lol
[21:04] <slangasek> powersj: 22.2 is up, with a shorter (and still interesting) delta
[21:05] <powersj> slangasek: is this what you show? 22.1 diffed against 22.2 http://paste.ubuntu.com/p/2cTHwh7W3W/
[21:05] <powersj> so e2fslibs
[21:05] <slangasek> powersj: yes.  so, what does ef2slibs mean
[21:07] <powersj> ef2slibs was on the cd, but since changing germinate to ignore versions it is now not on there
[21:10] <anon^_^> doko, sbeattie, any update re: reptoline, gcc-4.8 issue with 14.04 that lead to persistent unloading of Nvidia driver?
[21:33] <slangasek> powersj: turns out libext2fs2 Provides: e2fslibs (= 1.44.0-1); so it's a bit strange that e2fslibs and libext2fs2 exist like this, but it's not wrong for the image build to drop e2fslibs from the image based on my germinate change
[21:34] <powersj> ok
[21:39] <sbeattie> anon^_^: I don't know what you're referencing. gcc-4.8 4.8.4-2ubuntu1~14.04.4 (available in both trusty-security and trusty-updates) is needed for the dkms build. I'm not sure why any of that would cause a module to unload, though.
[21:42] <jbicha> slangasek: can you explain the bash 4.4.18-1.1ubuntu1 removal?
[21:43] <jbicha> because I used sbuild-launchpad-chroot to create an armhf chroot but it is stuck trying to update bash with an error that looks like Debian bug 889869
[21:43] <ubottu> Debian bug 889869 in bash "bash: crash in qemu-user: bash: xmalloc: ... cannot allocate XX bytes (0 bytes allocated)" [Important,Fixed] http://bugs.debian.org/889869
[21:43] <slangasek> jbicha: PIE is a security feature, and shouldn't be disabled to work around a bug in qemu-user-static
[21:44] <jbicha> is there a LP bug for the issue I experienced then?
[21:44] <slangasek> jbicha: LP: #1751011
[21:44] <ubottu> Launchpad bug 1751011 in bash (Ubuntu) "bash crashes in qemu-user environments (bionic)" [Undecided,Triaged] https://launchpad.net/bugs/1751011
[21:44] <jbicha> bash being stuck half-installed is a bit of a problem…
[21:49] <jbicha> slangasek: I request that you reconsider. The PIE change was only in Debian one week before it was reverted
[21:50] <jbicha> meanwhile, I added it to the Release Notes…
[21:51] <slangasek> jbicha: considering.  I think at minimum, I would want it signed off by the Security Team that they're ok with non-PIE bash in 18.04
[21:56] <slangasek> jbicha: barring that signoff, although I understand it's inconvenient to have qemu-user completely unusable for cross-chroots as a result of this, there are also still large swaths of the archive that qemu-user can't cope with (last I checked: anything Qt-based, for armhf), so I think having it completely-broken vs 25% broken is not a persuasive reason to disable the hardening feature
[21:56] <slangasek> mdeslaur, sbeattie: ^^ would one of you want to weigh in on this?
[21:58] <sbeattie> slangasek: we previously had bash as no-pie because it hit a similar failure on older kernels. It's not ideal, but I can live with it.
[21:59] <jbicha> slangasek: comment 15 at Debian bug 865599 has another proposal…
[21:59] <ubottu> Debian bug 865599 in src:bash "bash can stop disabling PIE" [Normal,Open] http://bugs.debian.org/865599
[21:59] <jbicha> I don't know enough about bash to know what the proposal means
[22:00] <slangasek> sbeattie: you're not required to live with it, though... if you think this is important to our hardening story in 18.04, I think that takes precedence
[22:01] <slangasek> also it's one thing to have had PIE disabled for a package for 16.10-17.10, and another to have it disabled in 18.04 LTS
[22:01] <slangasek> jbicha: yes, that suggestion makes sense given what I saw of the description of the problem (internal use of sbrk instead of glibc malloc)
[22:02] <slangasek> jbicha: I think it's worth investigating as a path forward (but I'm probably not going to pursue this myself)
[22:03] <jbicha> ok
[22:29] <anon^_^> sbeattie, pm
[22:51] <tjaalton> could a member of the security team please review https://bugs.launchpad.net/ubuntu/+source/pysmi/+bug/1748572
[22:51] <ubottu> Launchpad bug 1748572 in pysmi (Ubuntu) "[MIR] pysmi, pycryptodome" [High,New]
[22:51] <tjaalton> I need to get 389-ds-base unblocked, finally
[22:52] <sarnold> tjaalton: it'll be next week before we can get to that
[22:52] <tjaalton> sarnold: as long as it's on the radar, thanks
[22:53] <sarnold> tjaalton: yup, not forgotten, it just got knocked back a bit on the list when encrypted devices stopped working the other day :/
[22:53] <tjaalton> fun times
[22:54] <sarnold> there's always a bit of a rush around FF time .. this one more than most, probably because it's an LTS..
[22:54] <tjaalton> I'm just as guilty :)
[22:55] <sarnold> it's probably just the way things are going to go when it's run on a cycle ;)
[22:56] <tjaalton> yup
[23:15] <slangasek> tjaalton: <cough> I accidentally got 389-ds-base in already without the MIR being handled
[23:15] <sarnold> heh
[23:16] <slangasek> MIR still needs doing of course
[23:33] <tjaalton> slangasek: oh, hehe.. thanks