[00:00] <CarlFK> to a new thing that uses yaml ... are there images using this yet?
[08:19] <tjaalton> CarlFK: it's called subiquity, and the current focal images should use it aiui
[08:19] <CarlFK> tjaalton: thanks
[08:21] <tjaalton> server image that is
[08:30] <xnox> mwhudson:  arrrrrrrrgh
[08:30] <JackFrost> International pirate day?
[08:31] <mwhudson> xnox: p. much
[08:32] <mwhudson> xnox: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/ubuntu-server-live/+build/200376 has new casper, not sure image has been published yet though
[08:34] <mwhudson> (it hasn't)
[08:56] <CarlFK> tjaalton: any idea why this is now an iso9660?  (which is RO, so I can't mount and tweek it's boot parameters) http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/images/hd-media/
[08:57] <tjaalton> no
[08:58]  * CarlFK crys 
[09:36] <alkisg> Hi all. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792687 recommends NOT regenerating the .pot file on each build, yet python-distutils-extra's build_i18n.py does that unconditionally. Any way around it, or any other advice?
[10:10] <xnox> jibel:  bdmurray: is this critical for .4 release? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860559 and do we need ask kernel team to fix this; or should we promote finalrd to main and make casper depend on it. As far as I can tell it's installer failing to reboot, rather than installed systems.
[10:11] <xnox> sil2100:  ^
[10:17] <sil2100> xnox: I would like the kernel team to take a look and see what caused the regression, at least for now. Didn't dive into the bug so I'm not saying no to the finalrd approach, but before making a decision it would be wise to know what the fudge happened
[11:00] <rbalint> update_excuses is quite outdated :-(
[11:01] <rbalint> sil2100, , could you please trigger it? ^
[11:02] <cjwatson> update_excuses is updated automatically as fast as it can go.  If it's outdated then it's not just a matter of triggering it.
[11:03] <cjwatson> Also it's only 14 minutes old.
[11:04] <cjwatson> Updated seconds after you asked, I think (the timestamp that's 14 minutes old is probably when the process started; the mtime on the filesystem is about three minutes old)
[11:13] <rbalint> cjwatson, thanks!
[11:14] <sil2100> rbalint: which update_excuses do you mean? Since if it's about the focal one, it's as cjwatson mentioned
[11:14] <rbalint> sil2100, cjwatson when i asked it was from 2020.01.22 21:06:24 +0000
[11:16] <rbalint> sil2100, cjwatson i think ~11 hours is a bit long between updates, maybe something regressed and became very slow
[11:16] <sil2100> uh, sounds very unlikely, you sure you didn't have some cached version on your browser? I don't think britney ever took so long
[11:16] <sil2100> I can actually check the logs, wait
[11:17] <sil2100> rbalint: looking at the logs, it looks like britney was rather running as expected
[11:18] <rbalint> sil2100, strange, i tried refreshing
[11:18] <sil2100> rbalint: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/focal/2020-01-23/
[11:18] <rbalint> sil2100, i'll check with wget next time
[11:19] <rbalint> sil2100, cjwatson sorry for the noise then
[11:19] <sil2100> rbalint: no worries! It still might have been something fishy indeed, but at least from the britney POV it seemed to be working as intended
[11:27] <bdmurray> sil2100: who will chase down the kernel team regarding that 18.04.4 bug?
[11:29] <sil2100> bdmurray: if xnox didn't yet, I will poke them in a moment
[11:31] <sil2100> bdmurray: jibel poked them already, I'll follow up as well
[11:33] <rbasak> waveform: we should discuss this in public really, so let's chat here
[11:33] <waveform> rbasak, sure
[11:34] <rbasak> The planned flash-kernel change fixes a race that already sort of exists I think
[11:34] <rbasak> So perhaps we can land the u-boot-rpi changes now, certainly in Focal
[11:34] <waveform> rbasak, a race? Where's that?
[11:35] <rbasak> That without the Depends it's possible flash-kernel will be deconfigured
[11:35] <waveform> ah yes - of course, and now it'll ensure it runs anyway
[11:36] <rbasak> Does the Breaks then need to be bumped to refer to the version where we fix this in flash-kernel - for Bionic or Focal or both?
[11:37] <waveform> hmm - the Breaks was mostly to do with the issue that the proposed u-boot will not accept the uboot.env from older f-k's (only applicable to the bionic pi2 image, but still) - but if we're relying on the new f-k trigger behaviour then it probably would be sensible to bump it up
[11:38] <rbasak> It would ensure that an older flash-kernel won't be running at the time the postinst runs
[11:39] <rbasak> And flash-kernel will be upgraded if was installed at some point during a full upgrade
[11:41] <waveform> yup - sounds good - I'll tweak that commit; would I be right in thinking focal will be 2019.07+dfsg-1ubuntu4 and bionic will be 2019.07+dfsg-1ubuntu3.18.04.1 ?
[11:41] <rbasak> Hang on
[11:41] <rbasak> I'm not certain the Breaks needs to be bumped!
[11:42] <rbasak> And do we know the version of flash-kernel that will be uploaded?
[11:44] <rbasak> This mess is complicated :(
[11:45] <rbasak> ddstreet: ubuntu-dev-tools imported
[11:45] <rbasak> It'll be manual until my whitelist change lands
[11:48] <waveform> rbasak, doh! Was looking at the u-boot versions - just a mo
[11:50] <waveform> rbasak, well - f-k will be jumping from 3.90<stuff> to 3.98<stuff> on bionic so presumably it would be sufficient to just have Breaks: << 3.98
[12:28] <ahasenack> tribaal: hi, about your kitty tip, nice terminal, but I'm finding myself having to install kitty-terminfo in all remote servers I log into :/
[12:28] <tribaal> ahasenack: for me it's only a problem if I want to tmux inside of (Ubuntu) remotes
[12:28] <tribaal> just SSH seems to work out of the box
[12:29] <ahasenack> tribaal: saw that with tmux, yes, but just now saw that backspace didn't work without the terminfo package
[12:29] <tribaal> oh?
[12:29]  * tribaal tries
[12:29] <ahasenack> maybe something in focal, though. It was a focal lxd I started up
[12:29] <tribaal> works fine here on a 16.04 remote
[12:30] <tribaal> having the terminfo installed by default in focal would be nice
[12:30] <tribaal> but I guess that'd be a thing to send to upstream terminfo if there's such a thing :)
[12:32]  * tribaal tries on a focal lxd as well
[12:34] <tribaal> ahasenack: silly question: how do you launch a focal LXD? I see to remember there was a special alias for in-devel distros, but I can't remember what
[12:34] <ahasenack> tribaal: lxc launch ubuntu-daily:focal
[12:35] <tribaal> ahhh ubuntu-daily: that's the trick :)
[12:35] <tribaal> ahasenack:thanks
[12:42] <tribaal> ahasenack: indeed, backspace doesn't work via SSH on eoan/focal apparently
[12:42] <tribaal> works fine on bionic however
[12:42] <ahasenack> interesting
[12:42]  * tribaal tries disco
[12:44] <tribaal> disco fails as well
[12:47] <tribaal> yep, just tried on our platform as well - it's not LXD-related
[12:47] <tribaal> works on bionic, but not on disco+
[12:49] <ahasenack> lxd or not?
[12:50] <tribaal> ahasenack: correct. For disco+ the backspace key doesn't work on LXD and on "normal" virtualisation
[12:50] <tribaal> for bionci the backspace key seems to behave properly in both cases
[12:50] <tribaal> (LXD and non-LXD)
[12:53] <ahasenack> tribaal: I also seem to have lost my prompt colors
[12:55] <ahasenack> noaha
[12:55] <ahasenack> case "$TERM" in
[12:55] <ahasenack>     xterm-color|*-256color) color_prompt=yes;;
[12:55] <ahasenack> esac
[12:55] <ahasenack> but TERM is xterm-kitty
[12:56] <tribaal> ah ha
[12:57] <tribaal> ahasenack: does it behave like this on bionic as well? I wonder why the backspace works there and not later
[12:57] <ahasenack> I'm on eoan
[12:59] <ahasenack> TERMs are complicated
[13:06] <tribaal> ahasenack: I'm on eoan as well, but connecting to bionic
[14:28] <rbalint> apw, could you please merge this hint for systemd? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/377998
[15:03] <apw> rbalint, could you check line 14
[15:04] <rbalint> apw, thanks, fixed!
[16:08] <rbasak> waveform: on u-boot, give me a few minutes to think this through
[16:08] <waveform> rbasak, no prob
[16:09] <rbasak> Which branches exactly are ready?
[16:09] <rbasak> sru-pi4 preferred for both?
[16:09] <rbasak> waveform: do you have an LP bug ready? We'll need that for the SRU at a minimum
[16:10] <rbasak> But probably best to write everything up there
[16:10] <rbasak> Together with the required SRU paperwork
[16:10] <waveform> rbasak, yup - oh, I need to update the branch links though - just a mo
[16:11] <waveform> rbasak, LP: #1846329
[16:11] <waveform> rbasak, and just for reference the f-k one is LP: #1847587
[16:12] <waveform> (should have the correct branch links in there too now)
[16:22] <rbasak> waveform: you still need the trigger thing, don't you?
[16:23] <rbasak> Because if flash-kernel is upgraded first and entirely, then the u-boot-rpi upgrade won't cause flash-kernel to run again otherwise?
[16:24] <waveform> rbasak, that doesn't matter - u-boot copies itself into the boot partition (it shouldn't but as discussed with infinity on -release last night that's a bigger fix than we want to do right now); so if flash-kernel goes first then it'll already have updated the boot scripts, then u-boot updates (and updates itself)
[16:26] <rbasak> OK, thanks.
[16:26] <rbasak> Sorry, I had my head round this on Tuesday, but keeping my head around the complexities is quite difficult!
[16:27] <waveform> rbasak, no prob - I know the feeling :)
[16:31] <rbasak> dannf: o/
[16:31] <rbasak> dannf: do you have any interest currently in u-boot or flash-kernel?
[16:32] <dannf> rbasak: hi - no, i don't
[16:32] <rbasak> np, thanks.
[16:32] <rbasak> We're about to do a major SRU, so I thought I'd check.
[16:39]  * ahasenack has a pi4 with focal
[16:41] <ackk> hi, I have a tricky deb question. package A is using dbconfig-common to manage a postgres database. now I want to replace A with B (which has Breaks/Replaces/Provides: A). when A gets removed, it asks if the database should be purged. I need that not to happen, is there a way to preseed that answer from scripts in  B?
[16:53] <rbasak> waveform: so I'm uploading f8f21a5 to Focal, right?
[16:53] <waveform> rbasak, yup - that looks right
[16:53] <rbasak> You don't mention the shebang drop in that chagnelog entry. Intentional?
[16:55] <rbasak> waveform: ^
[16:56] <rbasak> In Bionic, you want 2019.07+dfsg-1ubuntu3~18.04.1 instead of 2019.07+dfsg-1ubuntu3.18.04.1 since we need it to be lower than the version in Focal. I can tweak that.
[16:56] <waveform> rbasak, hmm - what's the rules surrounding purely cosmetic changes?
[16:57] <rbasak> waveform: fuzzy. I don't mind either way.
[16:57] <rbasak> What about Disco and Eoan?
[16:57] <waveform> in that case, let's say intentional (rather than "Dave forgot at whatever the unholy hour was last night" :))
[16:57] <rbasak> :-)
[16:58] <rbasak> Disco is EOL now
[16:58] <rbasak> But usually we need to SRU Eoan too
[16:58] <rbasak> Sorry I hadn't looked at that before.
[16:58] <rbasak> vorlon: opinion on Eoan? ^
[16:58] <rbasak> I'm happy to upload your Focal branch
[16:58] <rbasak> Bionic is ready to go with that tweak.
[16:59] <rbasak> Just the Eoan question. That's more of an SRU hat thing.
[16:59] <waveform> Disco's already EOL and Eoan already has pi4 support so from that perspective there's no absolute requirement - but the f-k changes are probably sufficiently important to SRU; the u-boot changes may be relevant for anyone upgrading from bionic
[16:59] <rbasak> Oh, the versioning is good
[16:59] <rbasak> Because you're using ubuntu3
[17:00] <waveform> well ... I'm using whatever dch -i gave me frankly ... really hadn't thought that hard about it
[17:00] <rbasak> Let's say we land your branch as-is right now (with the minor version string tweak to ~ for Bionic)
[17:00] <rbasak> Then what will happen if a user upgrades to Eoan?
[17:01] <rbasak> Eoan has 2019.07+dfsg-1ubuntu3, which doesn't include your planned changes in Focal 2019.07+dfsg-1ubuntu4
[17:02] <rbasak> Actually let's defer that.
[17:02] <rbasak> I'll leave a note in the bug.
[17:02] <waveform> just checking something ... okay, there's a potential issue in the case that they're upgrading from the weirdo pi2 image with the differing root file-system label, and the fix for the 3A+ booting is also missing
[17:02] <rbasak> Let's at least put the thing in bionic-proposed assuming the SRU hat is happy. I don't think an Eoan fix will require a change to the Bionic upload.
[17:03] <rbasak> You might need to backport the fixes in Focal back to Eoan in an SRU.
[17:03] <rbalint> sil2100, coult you please merge this for the libnfs transition? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/378003
[17:03] <waveform> okay - I'll prep and Eoan branch
[17:03] <rbasak> That should be checked before the Bionic SRU is released I think.
[17:03] <waveform> *an
[17:11] <rbalint> doko, could you please do that? LP: #1860698
[17:11] <rbasak> waveform: uploaded
[17:11] <rbasak> waveform: please get yourself PPU for u-boot :-P
[17:12] <waveform> rbasak, thanks - will try!
[17:17] <rbasak> waveform: FTBFS :-/
[17:17] <rbasak> Looks like some Python thing
[17:18] <rbasak> Can I leave that with you?
[17:19] <waveform> rbasak, bizarre ... built in the PPA - yup, leave it with me
[17:19] <rbasak> waveform: maybe a component mismatch?
[17:19] <rbasak> If your PPA has universe visible. u-boot being in main does not for archive builds.
[17:20] <rbasak> Although
[17:20] <waveform> bah "Depends: libpython-dev but it is not going to be installed"
[17:20] <rbasak> Actually, didn't that chagne a while back?
[17:20] <rbasak> Anyway, I'll leave it with you :)
[17:20] <ahasenack> was in main in disco, not so much for eoan
[17:21] <doko> rbasak: I'll leave the i386 removals with vorlon
[17:21] <ahasenack> disco and before, that is
[17:21] <waveform> no idea (if that changed a while back) - but yeah, I'll dig into it
[17:21] <doko> waveform: libpython2-dev
[17:21] <doko> for a quick fix
[17:21] <ahasenack> also in universe for eoan+
[17:23] <doko> waveform: which package is this?
[17:23] <waveform> doko, u-boot-rpi (from u-boot)
[17:24] <doko> I'll have a look to built it
[17:33] <sil2100> rbalint: ACK
[17:34] <doko> waveform: https://paste.ubuntu.com/p/rhDdKKFfny/   not checked. please make sure that the binary package has the correct dependencies and uses python2 as the shebang
[17:36] <waveform> doko, thanks - will do
[18:31] <waveform> rbasak, I've incorporated doko's python2 patch (plus some extra fixes for any/all bare "python" shebangs I could find) into the focal-clean-up branch, rebased and pushed that - just building the pkg in a PPA again
[18:40] <waveform> rbasak, okay - ignore me - still got a build failure - having a look
[19:04] <ahasenack> autopkgtest is driving me nuts, why isn't it adding deb-src lines anymore?
[19:04] <ahasenack> failed with stderr "E: You must put some 'source' URIs in your sources.list
[19:04] <ahasenack> autopkgtest -o dep8 -U -s --apt-pocket=proposed=src:php7.3 ./php-doctrine-dbal-2.10.1/ -- lxd ubuntu-daily:focal
[19:04] <ahasenack> that is my command line
[19:04] <ahasenack> before I had -B, because this package doesn't need rebuilding
[19:04] <ahasenack> same thing
[20:04] <waveform> rbasak, if you're still around: got a u-boot version that builds in -proposed now - I've pushed the rebased branch which has one additional commit at the top to handle the python 2 switchover; all subsequent commits are unaltered
[20:48] <coreycb> tjaalton: Hi, I see you're on sru rota tomorrow. if you have a chance would you be able to take a look at the the openstack uploads in unapproved queues for bug 1858933 and bug 1723030?
[20:48] <tjaalton> coreycb: ok
[20:48] <coreycb> tjaalton: thanks
[20:56]  * mwhudson rubs his eyes
[20:57] <mwhudson> autopkgtest --apt-pocket=proposed -U . fails in the build step
[20:57] <mwhudson> sbuild -d focal passes
[20:57] <mwhudson> how does that happen?>
[20:57] <mwhudson> (for python-jsonschema fwiw)
[20:57] <mwhudson> if this pure python test depends on the running kernel version i am going to be very angry
[20:58] <mwhudson> ah i think the failing tests are skipped in the sbuild case for some reason
[21:36] <mwhudson> ah because python3-json-pointer is not installed in sbuild
[21:36] <mwhudson> why the heck is it in cloud-images
[21:37] <mwhudson> cloud-init -> python-jsonpatch -> python-json-pointer
[22:42] <vorlon> doko, rbasak: ugh why is that skiboot binary there?  looking to see why my scripts haven't already removed it
[22:42] <vorlon> uh weird it's an arch: all binary
[22:42] <vorlon> so that's why
[22:42] <rbasak> waveform: can you give me a commit with an archive-suitable changelog please?
[22:43] <rbasak> With 2019.07+dfsg-1ubuntu4 in focal-proposed, it needs to be 2019.07+dfsg-1ubuntu5 presumably
[23:53] <vorlon> Laney: do you have any idea about the autopilot-gtk/arm64 autopkgtest failure with new glib2.0? autopilot-gtk itself is uninteresting and will probably be removed as unmaintained (python2), but I'm not sure whether the failure represents a glib2.0 regression