[15:00] <sil2100> o/
[15:01]  * vorlon waves
[15:01] <juliank> o\
[15:01] <tdaitx> o>
[15:01] <waveform> \o
[15:02] <rbalint> o/
[15:03] <xnox> #startmeeting Weekly Ubuntu Foundations team
[15:03] <meetingology> Meeting started Thu Mar 21 15:03:41 2019 UTC.  The chair is xnox. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:03] <meetingology> Available commands: action commands idea info link nick
[15:03] <xnox> #topic Lightning rounds
[15:04] <xnox> $ echo $(shuf -e vorlon bdmurray xnox tdaitx doko sil2100 rbalint infinity cyphermox mwhudson juliank waveform)
[15:04] <xnox> mwhudson doko xnox bdmurray cyphermox sil2100 juliank infinity rbalint vorlon tdaitx waveform
[15:04] <xnox> doko, ?
[15:04]  * xnox goes to fix the script to not have mwhudson it in.
[15:04] <doko> - more openjdk-11-transition work
[15:04] <doko> - new OpenJDK upstreams: 8u202, 8u212, Openjdk 12 ga, OpenJDK 11.0.3+4, OpenJDK 13
[15:04] <doko> - Help tracking down https://bugs.openjdk.java.net/browse/JDK-8221083
[15:04] <doko> - Fix PR jit/87808, backport fix for PR tree-optimization/89505
[15:04] <doko> - GCC 9 update
[15:04] <doko> - 360s
[15:04] <doko> (done)
[15:04] <xnox> * made fuse-zip fail on all arches, instead of just s390x!
[15:04] <xnox>   - possibly a way out here is more patches to fuse
[15:04] <xnox>   - why did we merge fuse, past DebianImportFreeze?!
[15:04] <xnox> * openssl backports discussions with security/pat
[15:04] <xnox> * working on unbreaking subiquity on power/serial
[15:04] <xnox> * waiting on ibm to continue optimized atlas builds for z13/z14
[15:04] <xnox> * vorlon, still awaiting openssl 1.1.1 accept into
[15:04] <xnox>   bionic-proposed. All feedback responded to....
[15:05] <xnox>   https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386
[15:05] <xnox> * on holidays next week ⛷️
[15:05] <xnox> (done)
[15:05] <xnox> bdmurray,
[15:05] <bdmurray> converted two ET cronjobs from pycassa to python cassandra
[15:05] <bdmurray> submitted RT, mojo spec MP regarding update of daisy to r824 in prod ET
[15:05] <bdmurray> modified the above RT to also include updating apport to r3227 see below
[15:05] <bdmurray> discovered an issue with how apport calls gdb fixed in r3227
[15:05] <bdmurray> submitted RT, mojo spec MP regarding update of daisy to r826 in prod ET
[15:05] <bdmurray> review of rls-dd-incoming bug tasks
[15:05] <bdmurray> submitted PR for metrics and jobs w/ a metric for retracers-results
[15:05] <bdmurray> submitted PR for metrics and jobs w/ a metric for retracer-avg-process time
[15:05] <bdmurray> created some test graphs of the above
[15:05] <bdmurray> reviewed, merged, uploaded xnox's u-r-u lintian fixes for disco
[15:05] <bdmurray> review of netplan SRU exception
[15:05] <bdmurray> special SRU review of keystone, python-ldappool
[15:06] <sil2100> cyphermox
[15:06] <sil2100> Oh, or did bdmurray not finish?
[15:06] <bdmurray> I did finish
[15:07] <vorlon> xnox: yeah, haven't had any SRU day time since last we discussed
[15:07] <xnox> vorlon, ack.
[15:08] <xnox> sil2100, go
[15:08] <sil2100> No cyphermox ?
[15:08] <sil2100> - SRU reviews and releases
[15:08] <sil2100> - A lot of new kernel reviews (new cycle)
[15:08] <sil2100> - Some package approvals for the OpenJDK-11 transition
[15:08] <sil2100> - Review of the pi spec
[15:08] <sil2100> - Reviews and infrastructure help for ubuntu-canary
[15:08] <sil2100> - Helping out with an iproute2 backports upload
[15:08] <sil2100> - Few FFe reviews
[15:08] <sil2100> - Shepherding disco first set of language-pack delta updates
[15:08] <sil2100> - Fixing kernel-sru-review to handle kernel backports of flavor kernels without crashing
[15:08] <sil2100> - 360
[15:08] <sil2100> - core18:
[15:08] <cyphermox> gah, sorry, I'm here
[15:08] <sil2100>   * Finalized gadget snap code branch location and permissions
[15:08] <sil2100>   * Moar work on core18 promotion - scripts almost there, only the jenkins job needed
[15:08] <sil2100>   * Backporting missing change from core for support of out-of-core18 wpa-supplicant (PR)
[15:08] <sil2100>   * Modified version number to include the date (and thinking about that a bit)
[15:08] <sil2100>   * Checked status of snap prepare-image for classic seeding
[15:09] <sil2100> - Tomorrow: out-of-office o/
[15:09] <sil2100> (done)
[15:09] <xnox> cyphermox, go
[15:09] <cyphermox> shim review: attempting to review OpenSuSE / tumbleweed / SLES shims; hard to even get a build env working to begin with
[15:09] <cyphermox> shim review: partial review of Debian's shims for ia32, x64, aa64. We're gaining an additional contributor to reviewing shims too yay!
[15:09] <cyphermox> uploaded grub2 SRUs for http module + debconf prompts (LP: #1787630) (LP: #564853)
[15:09] <cyphermox> added mmx64.efi to d-i images (and will end up on dailies) to better address Secure Boot configuration for unfinished installs (LP: #1798171)
[15:09] <cyphermox> initial review of netplan wireguard support PR
[15:09] <cyphermox> revived netplan PR#34: "openvswitch support" - allow networkd to bring up devices without addresses / unconfigured but IFF_UP.
[15:09] <cyphermox> netplan roadmap: prioritizing next features to implement
[15:09] <cyphermox> paperwork for design / user stories for new netplan features
[15:09] <cyphermox> I still need help to get the netplan.io SRUs reviewed in the bionic, cosmic queues
[15:10] <cyphermox> fwiw I'm looking now at why the dailies don't yet have mmx64.efi as I thought they would; which is why I was unresponsive, deep hack mode looking at mark-pending-current and such
[15:10] <cyphermox> (done)
[15:10] <xnox> cyphermox, mark-pending-current.... interesting, i wonder if ci jobs are fialing.
[15:10] <cyphermox> they def are
[15:10] <xnox> juliank, !
[15:10] <juliank> (short week, OoO on monday)
[15:10] <juliank> * (last Fri) Re-verified APT SRUs
[15:10] <juliank> * ESM UX review
[15:10] <juliank> * Some PackageKit merge review
[15:10] <juliank> * Improve PackageKit error handling (https://github.com/hughsie/PackageKit/pull/321)
[15:11] <juliank> * Tighten APT dependencies on its own libs (https://salsa.debian.org/apt-team/apt/merge_requests/56)
[15:11] <juliank> * Rebase APT proposed update branches against master and do some more stringview cleanup
[15:11] <juliank> * More ESM UX bikeshedding
[15:11] <juliank> * Analysis of aptdaemon use in software-properties
[15:11] <juliank> * First stab at PackageKit driver installs in software-properties-gtk - (updates works already)
[15:11] <juliank>   - Not sure about QApt vs PackageKit in the Qt backend
[15:11] <juliank> (also: apt-side of ESM stuff landed everywhere today, woohoo!)
[15:11] <juliank> (done)
[15:11] <xnox> infinity is not in the channel...
[15:11] <bdmurray> rbalint:
[15:11] <rbalint> (short week)
[15:11] <rbalint> * fixed script bzr -> git conversion script to handle software-properties' repo
[15:11] <rbalint> * converted and switched software-properties project to git
[15:11] <rbalint> * prepared sru patches for systemd-detect-virt wsl detection
[15:11] <rbalint> * partner work
[15:11] <rbalint> * fixing unattended-upgrades bugs, I'm finalizing tests and push the changes later today
[15:11] <rbalint> (done)
[15:12] <vorlon>  * short week, was off last Friday
[15:12] <xnox> vorlon,
[15:12] <vorlon>  * legwork for fips vs secureboot
[15:12] <vorlon>  * discussions around UC20 roadmap
[15:12] <vorlon>  * discussing netplan roadmap for 19.10
[15:12] <vorlon>  * looked at snap seeding and core18 coming into the disco desktop images
[15:12] <vorlon>  * worked with xnox to fix modules.squashfs the right way around (in debian-cd)
[15:12] <vorlon>  * next week: off (spring break)
[15:12] <vorlon> (done)
[15:12] <xnox> tdaitx,
[15:12] <tdaitx> * openjdk-11 bionic security transition
[15:12] <tdaitx>   - gradle test and fixes (LP: #1820389, LP: #1797761, Debian: #925225)
[15:12] <tdaitx>   - geogebra update for Bionic
[15:12] <tdaitx>   - investigated LP: #1803855 in gradle/groovy but that requires a new groovy update and that is not happening any time soon
[15:12] <tdaitx>   - following up on android-tools (LP: #1820513)
[15:12] <tdaitx>   - quick check on an octave update for bionic for better openjdk-11 support, but that would require a soversion update
[15:12] <tdaitx> * openjdk-7 packaged and uploaded for review by security team
[15:12] <tdaitx> Other:
[15:12] <tdaitx> - 360 fun
[15:12] <tdaitx> - working some odd hours this and the next weeks (gym on Mon/Fri afternoon + apartment renovation^Wproblems going on)
[15:12] <tdaitx> - happy 321 holidays!
[15:12] <tdaitx> (done)
[15:13] <tdaitx> waveform: go!
[15:13] <waveform> * More work on pi spec (answering reviews)
[15:13] <waveform> * SRU for RPi.GPIO to bionic
[15:13] <waveform> * RPi.GPIO fixes accepted upstream; tested updated package on ubuntu under aarch64
[15:13] <waveform> * ITP colorzero to Debian (new dep of gpiozero)
[15:13] <waveform> * Reading up on live-build (overlays for pi configuration hacks)
[15:13] <waveform> * Worked on first boot design (3 scenarios to support)
[15:13] <waveform> * Experimented with seeding cloud-init from boot partition on the pi
[15:13] <waveform> * piwheels configuration for ubuntu (ongoing)
[15:13] <waveform> (done)
[15:14] <xnox> Any status questions?
[15:14] <xnox> #topic Release incoming bugs (disco)
[15:14] <xnox> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html#foundations-bugs
[15:15] <bdmurray> I went ahead and set the importance for all the rls-dd-incoming
[15:15] <bdmurray> bug 1790205
[15:15] <xnox> bdmurray, so... depending on how big ones instalation is, one will have bigger or smaller journal usage.
[15:15] <bdmurray> I was surprised to find 4G of logs on my system
[15:16] <xnox> bdmurray, so if people have large hard drive, you will have gigs of logs.
[15:16] <xnox> bdmurray, is it more than what journal declares to be the limit? one sec:
[15:16] <bdmurray> xnox: and if my hard drive becomes small because of the logs then what happens?
[15:16] <xnox> bdmurray, $ journalctl -b -u systemd-journald.service -n 1
[15:16] <xnox> -- Logs begin at Mon 2018-09-17 14:21:50 BST, end at Thu 2019-03-21 15:16:25 GMT. --
[15:16] <xnox> Mar 21 11:27:37 ottawa systemd-journald[571]: System journal (/var/log/journal/1b8df0fa27039f0163586c6756a6d401) is 3.7G, max 4.0G, 231.6M free.
[15:16] <xnox> for me, the max is 4G, and it's below that at the moment, so that is working correct.
[15:17] <xnox> if logs are more, than max, that would be a bug, so far i have not seen anybody, prove that limits are neither in place, nor observed.
[15:17] <xnox> bdmurray, what does above say for you?
[15:17] <bdmurray> Mar 19 07:50:32 impulse systemd-journald[608]: System journal (/var/log/journal/5daa40091e7e4b6fa27e6439f0a48bdc) is 3.9G, max 4.0G, 23.8M free
[15:17] <xnox> bdmurray, or is it the case that 4GB is "omg logs grow uncontrollable"
[15:17] <xnox> bdmurray, so you are definately capped already.
[15:19] <xnox> $ journalctl --disk-usage
[15:19] <xnox> Archived and active journals take up 3.7G in the file system.
[15:19] <xnox> so maybe --disk-usage, should state the max, and free, like it does on startup.
[15:19] <vorlon> sounds sensible
[15:19] <xnox> vorlon, ^
[15:20] <xnox> ok.
[15:20] <vorlon> I do think 4GB sounds like a surprisingly large amount for logs however
[15:20] <vorlon> is there so much more data in journals vs. traditional syslog that we need to allocate more space?
[15:21] <juliank> "Archived and active journals take up 4.0G in the file system." for me
[15:21] <tdaitx> mar 18 21:44:34 tdaitx-P65 systemd-journald[32600]: System journal (/var/log/journal/e0e3d1032c874b5ba18c951f8ae3cbfa) is 1.0G, max 1.0G, 0B free.
[15:21] <tdaitx> Archived and active journals take up 1.0G in the file system.
[15:22] <tdaitx> but I set it to 1G in journald.conf
[15:22] <tdaitx> SystemMaxUse=1G
[15:23] <xnox> $ journalctl | grep gnome-shell
[15:25] <juliank> ^ gnome-shell sucks
[15:26] <vorlon> my thinking here is that the journal should be rotating by date.  Because if something's going on /currently/ that makes the logs balloon, we should keep those (up to the limit), but I don't think we should let systemd consistently fill up a fixed amount of space on disk
[15:27] <juliank> MaxRetentionSec=1m
[15:27] <juliank> and MaxFileSec control that
[15:28] <vorlon> my desktop has a 1.3G journal on a 12G rootfs.  is that going to grow up to 4G?  (How do I check on cosmic the limit?)
[15:28] <vorlon> ah found it
[15:28] <vorlon> Mar 12 11:01:49 virgil systemd-journald[6237]: System journal (/var/log/journal/c856e8839ee179de1933c6264c9c4260) is 1.2G, max 1.1G, 0B free.
[15:28] <rbalint> vorlon, it used to be the case but time just correlates with log size, while log size is the cost paid for the logs on systems thus size base limit fits the cost better and now it can proberly be enforced
[15:29] <xnox> vorlon, that looks buggy. because 1.2 is more than 1.1
[15:29] <vorlon> xnox: I notice!
[15:29] <xnox> vorlon, that is worth filing a bug.
[15:29] <rbalint> before journald size based limits could not have been enforced thus time-based was the best heuristics
[15:29] <juliank> 10% max used, 15% min free
[15:29] <xnox> vorlon, and it's not weird variable size fs, right ? i.e. compressed btrfs?
[15:29] <juliank> each capped to 4 GB
[15:29] <vorlon> xnox: haha no
[15:29] <xnox> ok
[15:30] <bdmurray> The --disk-usage switch gave me a different number than the system journal did too
[15:30] <juliank> it likely grew at boot, and then vacuumed later and it got down?
[15:30] <bdmurray> System journal (/var/log/journal/5daa40091e7e4b6fa27e6439f0a48bdc) is 3.9G
[15:30] <bdmurray> Archived and active journals take up 4.0G in the file system.
[15:30] <xnox> well --disk-usage shoes the current size, i think, which might be both persistent (/var) and runtime (/run)
[15:30] <gaughen> time to let it go for now
[15:30] <gaughen> don't make me sing
[15:31] <bdmurray> Okay, lets move on. xnox you'll follow up with the bug yes?
[15:31] <gaughen> bdmurray, xnox is on vacation after tomorrow
[15:31] <doko> no Hasselhoff?
[15:31] <xnox> bdmurray, yes.
[15:31] <xnox> bdmurray, doing typy typy now.
[15:32] <bdmurray> bug 1807479 - there's a patch but why was this assinged to the team xnox?
[15:32] <cyphermox> err
[15:32] <cyphermox> system-config-kickstart?
[15:32] <juliank> yo!
[15:35] <bdmurray> We've decided that it doesn't need to be assigned to the team
[15:35] <bdmurray> ando somebody'll have a look at the patch
[15:36] <tdaitx> the fix seems correct anyway
[15:38] <bdmurray> bug 1811694
[15:38] <bdmurray> there are hundreds of dupes of that in the error tracker
[15:38] <juliank> make it go away!
[15:38] <juliank> aah
[15:39] <juliank> But yes, that seems like aptdaemon needs to be adapted to python 3.7 or something
[15:39] <vorlon> bdmurray: +1 for accepting it and putting it on the backlog
[15:39] <bdmurray> will do
[15:40] <bdmurray> xnox: is bug 1815599 on your radar?
[15:40] <xnox> no
[15:40] <xnox> bdmurray, i hope that like cpaelzer and/or server team can take it
[15:41] <bdmurray> xnox: have you done more than hope?
[15:42] <bdmurray> gaughen: you'll bring it up with the server team yes?
[15:42] <gaughen> doing so right now
[15:42] <vorlon> so we're not taking it for disco but we "hope" server team does? :)
[15:42] <gaughen> vorlon, yes
[15:43] <xnox> the last hope
[15:43] <bdmurray> no, a new hope
[15:43] <juliank> the final hope
[15:43] <juliank> the meow hope
[15:44] <bdmurray> bug 1798369
[15:44] <cpaelzer> xnox: was not on my radar at all so far
[15:44] <vorlon> the last best hope for mankind
[15:44] <juliank> A unicorn's hope
[15:44] <xnox> cpaelzer, can it be? i think it's "normal" to not recover the multipaths, but i might be wrong. they claim "it never recovers", or i think it does but "takes a while"
[15:44] <gaughen> YES!
[15:45] <cpaelzer> xnox: they didn't really answer to Frank, but I'll take a look
[15:46] <xnox> cpaelzer, yeah, try to move it along, by sounding to have multipath knowledge
[15:46] <cpaelzer> the great pretender ...
[15:49] <bdmurray> I'll test the reinstall option and see if it still exists
[15:49] <xnox> cool
[15:50] <bdmurray> Okay, I think that's good for today.
[15:50] <xnox> bdmurray, you might need to trick the iso to think it is disco final....
[15:50] <xnox> bdmurray, by like bind-mounting final sounding things into .disk
[15:50] <xnox> and /etc/os-release et.al.
[15:50] <bdmurray> that sounds involved
[15:50] <xnox> bdmurray, cause disco-on-disco will currently thinkg it is an upgrade from disco-to-19.04
[15:51] <xnox> instead of 19.04-on-19.04 reinstall
[15:51] <xnox> #topic Team proposed-migration report
[15:51] <xnox> #link http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:52] <rbalint> u-u fix is on the way to unlock python-apt
[15:53] <xnox> doko, do we need the new fuse?
[15:55] <doko> there was a reason ...
[15:55] <xnox> but the regression in fuse-zip is real
[15:55] <xnox> so we shouldn't let new fuse in, as is at the moment.
[15:55] <xnox> (as seen in the rebuild of fuse-zip, with new fuse support)
[15:56] <xnox> nest up gdb/python3.7 kind of related
[15:56] <xnox> python3.7 are blocked by openssl 1.1.1b compat (there is a bug report aobut that)
[15:57] <doko> there's a new comment on the python issue
[15:57] <xnox> but should we let gdb through then?
[15:57] <xnox> (cause python3.X->gdb is openssl issues, and shouldn't block new gdb)
[15:57] <xnox> rbalint, python-apt blocked by unattended-upgrades regressions. Did you look at that?
[15:58] <rbalint> u-u fix is on the way to unlock python-apt
[15:58] <doko> https://bugs.python.org/issue35998
[15:58] <xnox> doko, fuse has uint/int abi bugs in the interface layear, which cuases hangs in fuse-zip testsuite, that hangs the VM.
[15:58] <xnox> rbalint, great!
[15:59] <xnox> re:perl -> there is progress in debian, the gdn/ndb regression compat is real, but we don't know if we care about acient dbs to be usable on new releases.
[15:59] <xnox> i guess i should upload that into ubuntu direct, instead of waiting for the fixed up upload in debian.
[15:59] <vorlon> why?  I don't think it's urgent
[15:59] <vorlon> I think we should let the Debian maintainer fix it
[16:00] <vorlon> unless we think that's not happening soon
[16:00] <xnox> vorlon, well it is urgent as IBM observe it, in their testing of disco.
[16:00] <xnox> vorlon, it was raised as a partner hwe issue.
[16:01] <vorlon> it's buggy and they've identified the bug and it will be fixed by release
[16:01] <xnox> ok.
[16:01] <vorlon> I don't think IBM have said it's blocking them from testing other stuff, have they?
[16:07] <xnox> #topic AOB
[16:07] <gaughen> no
[16:07] <vorlon> none here
[16:07] <xnox> #endmeeting
[16:07] <meetingology> Meeting ended Thu Mar 21 16:07:54 2019 UTC.
[16:07] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-21-15.03.moin.txt
[16:09] <xnox> running meetings is hard
[16:16] <teward> i'm glad i'm not the only one who thinks so xnox XD
[16:16] <xnox> vorlon, cyphermox - i nominate rbalint to run the next meeting.
[16:16] <vorlon> :)
[16:16] <xnox> that is my revenge.
[16:17] <xnox> unicorn
[16:17] <gaughen> :-)
[16:17] <rbalint> xnox, revenge on whom ? :-)
[16:18] <xnox> i'll keep that to myself.
[17:30] <cyphermox> xnox: we should changet the meeting template so next chair selection is part of the meeting
[22:40] <xnox> cyphermox, yes!