[09:00] <juliank> Eickmeyer: it looks like I'm not going to make it today
[09:13] <Eickmeyer> juliank: I'm OK with that, so long as we can get this fixed before Final (it's 2am for me and I have a sudden case of insomnia).
[09:13] <juliank> ack
[09:15] <juliank> Eickmeyer: I mean, if we can't figure out what's wrong in time, we'll have to remove the page, which is a feature regression in the installer, but at least it won't crash you. I'm really mostly interested in figuring out if that's a generic issue that we just have not noticed elsewhere as opposed to getting the plugin to work
[09:16] <Eickmeyer> juliank: Yes, totally. I couldn't agree more, I just want to at least try. The plugin seems to be a fork of the Edubuntu one that stgraber made, so maybe there's some insight??
[09:17] <juliank> maybe
[09:17] <juliank> cjwatson: do you know what the intend of the check for EFI/$vendor is in grub postinst? I'm moving to a list of ESP devices, and I'm considering getting rid of it to make life easier
[09:18] <juliank> Because I'm making a mess
[09:18] <juliank> Optimally I should support grub-install <device> <device>...
[09:18] <juliank> but that's a ton of effort
[09:19] <juliank> So I have a wrapper script, a hack in grub to teach it about other ESPs we own, and I want to use that from an installer for first install
[09:19] <juliank> Also the other use case - you replace/add an ESP also requires that you install grub to it if it's not there yet
[09:20] <juliank> We don't check mbr boot sectors to make sure they previously had grub installed, do we?
[09:20] <cjwatson> We have a different thing there that achieves the same result IIRC
[09:21] <cjwatson> The intent of the postinst is not to do grub-install until we know we've been told to do so
[09:22] <cjwatson> But it may be OK to test that core.efi exists which I think would be analogous to the same check
[09:22] <cjwatson> The MBR case checks for /boot/grub/core.img or /boot/grub/@FIRST_CPU_PLATFORM@/core.img I think
[09:22] <cjwatson> Testing for /boot/grub/@FIRST_CPU_PLATFORM@/core.efi might work
[09:23] <juliank> oh that sounds useful, yes
[09:24] <juliank> Thanks cjwatson
[09:26] <cjwatson> np
[12:20] <bdmurray> seb128: Do you know why evolution-data-server appears in /var/run/reboot-required.pkgs?
[12:40] <seb128> bdmurray, because it has a postinst snippet for it, https://salsa.debian.org/gnome-team/evolution-data-server/-/commit/5f13ac9f , but I don't know why rebooting is advised/why that has been added, maybe jbicha can help you to reply to that question though
[12:49] <kanashiro> LocutusOfBorg, I have patches to fix 2 out of 3 perl packages blocking pkg-perl-tools migration
[12:49] <kanashiro> https://bugs.launchpad.net/ubuntu/+source/liblog-agent-perl/+bug/1870535
[12:49] <kanashiro> https://bugs.launchpad.net/ubuntu/+source/libsyntax-highlight-engine-kate-perl/+bug/1870536
[12:55] <kanashiro> hum, the other one has the same problem
[12:55] <kanashiro> https://bugs.launchpad.net/ubuntu/+source/libcgi-application-plugin-messagestack-perl/+bug/1870540
[12:56] <kanashiro> LocutusOfBorg, so the patches above should let pkg-perl-tools migrate
[13:28] <ahasenack> teward: thanks for the release notes update about nginx, I had forgotten that one
[13:28] <teward> ahasenack: yep.  please revise accordingly for anything I missed I literally fast-wrote that before I got my morning coffee :P
[13:30] <ahasenack> hehe
[13:30] <ahasenack> teward: let me find the bug, I wrote some scenarios there that I could copy over
[13:31] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1861101/comments/15 that bit
[13:31] <teward> ahasenack: ack.  also keep note of https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1870491 which is a case of upgrade woes - someone i think modified their configurations
[13:31] <teward> and in turn got a "Upgrade conflict" because it tries to overwrite the 'default'
[13:32] <teward> but thats within the same version so...
[13:34] <ahasenack> teward: this is done, right? https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1865902
[13:43] <teward> that's an old one heh.  yes 1.17.9 is in
[13:44] <teward> ahasenack: I JFDI so :p
[13:44] <teward> nobody argued
[13:44] <teward> bug ==> Fix Released
[15:32] <AsciiWolf> kenvandine, hi, I just tried clean install of Ubuntu 20.04 Beta that was released today and it seems that Snap Store is launched without any "Ubuntu Software" branding and has support only for Snap apps
[15:33] <kenvandine> AsciiWolf: the only support for snaps is a bug, which should be fixed in the next snapd release
[15:33] <kenvandine> and if you refresh snap-store, you should see the Ubuntu Software branding
[15:34] <kenvandine> the workaround for that didn't make it into beta
[15:34] <AsciiWolf> kenvandine, ah, thanks for the info! :)
[16:00] <AsciiWolf> kenvandine, snap-store, core runtime and other system snaps still seem to be removable, but I suspect it is also because of the snapd bug :)
[16:05] <kenvandine> AsciiWolf: that's different
[16:05] <kenvandine> that was fixed last night
[16:06] <kenvandine> but not published yet
[16:06] <AsciiWolf> ah, ok :)
[16:06] <AsciiWolf> thanks
[16:44] <alkisg> Hi, when's the last day that "syncpackage" from debian is allowed? (of course for important-bug-fixing microreleases only, and btw in universe)
[16:46] <ginggs> alkisg: if the package is not seeded, it can be sync'd right up until the release
[16:47] <alkisg> ginggs: great, thank you very much
[16:50] <LocutusOfBorg> kanashiro, did you forward to debian?
[16:50] <LocutusOfBorg> btw don't remember to refresh your advocacy page :D
[16:51] <kanashiro> LocutusOfBorg, not yet, but I'll do it today
[16:52] <kanashiro> and yes, I'll add those urls there :)
[16:52] <LocutusOfBorg> sponsored all of them! :D
[16:52] <LocutusOfBorg> well, they ended up in unapproved queue :D
[16:54] <kanashiro> thanks!
[19:48] <blackboxsw> hrm, in trying to sbuild a package for focal I'm hitting this bug  https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/1862787
[19:48] <blackboxsw> I'm trying to figure out how I should be resolving this maintainer mismatch issue as it looks 'fix released'
[19:53] <blackboxsw> E: <pkgname> changes: inconsistent-maintainer ME <me@me.com> (changes vs. source) Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[20:42] <xnox> blackboxsw:  what is the target suite of your package, and version number?
[20:44] <blackboxsw> xnox: target suite is focal. version number of what pkg?
[20:44] <blackboxsw> the pkg I'm building, built is 20.1-10-g71af48df-0ubuntu3 is
[20:44] <blackboxsw> no series-specific ~20.04 etc.
[20:45] <blackboxsw> maybe I needed to switch versioning schema now that beta has started ?
[20:45] <xnox> blackboxsw:  and where are you running lintian? it seems like you have triggered lintian to go into "Debian" profile instead of "Ubuntu" profile
[20:45] <xnox> blackboxsw:  can you point me at your build/log/source package where you see that inconsisten-maintainer error?
[20:45] <blackboxsw> xnox: I believe I'm kicking it off via an sbuild
[20:46] <xnox> yeah, if you can give me $ dget url/to/.dsc and like just calling sbuild on it does that, i can check what's wrong.
[20:46] <xnox> maybe Ubuntu profile is out of date
[20:46] <xnox> but just to be clear you don't need to fix the warning, it is bogus for ubuntu.
[20:46] <xnox> (false positive)
[20:47] <blackboxsw> xnox: good 'ole cloud-init.  ubuntu/devel branch https://github.com/canonical/cloud-init/tree/ubuntu/devel
[20:48] <blackboxsw>  +1 can push up the dsc etc now, though it's also currently in the upload queue for focal. not sure if that dsc is present somewhere in launchpad url-magic space while in queue
[20:48] <blackboxsw> thanks for context xnox.
[20:49] <blackboxsw> xnox: https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=cloud-init
[20:49] <blackboxsw> https://launchpad.net/ubuntu/focal/+upload/23242134/+files/cloud-init_20.1-10-g71af48df-0ubuntu3.dsc rather
[20:50] <xnox> ahaha
[20:50] <xnox> blackboxsw:  i bet if you used name.lastname@ubuntu.com as the maintainer email address, you would not see that warning.
[20:50]  * blackboxsw thinks xnox found a smoking bit of config
[20:50] <xnox> blackboxsw:  note distro team has an exception, and name.lastname@ubuntu.com is a working email alias.
[20:51] <xnox> blackboxsw:  or launchpad-id@ubuntu.com -> if you are a contributing developer / per-package uploader.
[20:51] <xnox> blackboxsw:  anyway, will play with that, once the package lands in the archive proper.
[20:51] <xnox> check what is going on.
[20:51] <blackboxsw> haha, so @canonical.com ain't gonna work and  Ubuntu Develop Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>ers <ubuntu-devel-discuss@lists.ubuntu.com>
[20:51] <blackboxsw> is not going to work either
[20:51] <blackboxsw> ok
[20:51] <blackboxsw> thanks a bunch
[20:52] <xnox> anyway, most of distro team use launchpadid@ubuntu.com
[20:52] <xnox> blackboxsw:  but probably something to fix in lintain profile to accept @canonical.com as ubuntuish thing.
[20:53] <blackboxsw> +1, will override defaults for my lintian profile.
[20:53] <blackboxsw> yeah thanks
[20:53] <blackboxsw> that's the bit of glue I was missing/misunderstanding
[20:55] <blackboxsw> or maybe running lintian w/    --suppress-tags inconsisten-maintainer
[21:09] <Unit193> riscv64, eh?  That's new and shiny.
[21:14] <xnox> nah, just very slow
[21:15] <xnox> and not quite there yet. still needs to build everything and have usable/downloadable images one can run locally before the rest of us can do anything for it.
[21:15] <Unit193> Heh, noticed.  The build failure that was sent to me was very much not a real failure. :P
[21:18] <cjwatson> The builders aren't especially slow - even with emulation that hardware is pretty fast.
[21:19] <cjwatson> Well, depends on the package I suppose
[21:20] <cjwatson> binutils did well but python3.8 was pretty slow.  So ignore me :)
[21:20] <sarnold> python slow? I'm shocked! shocked!
[21:21] <sarnold> (yes, I realize that's probably not actually the cause, but I'm not about to let a good joke opportunity go to waste)
[21:25] <cjwatson> Disproportionately, I mean :P
[21:25] <sarnold> hehe
[21:28] <Unit193> I was just saying it was new! :3
[22:36] <jbicha> bdmurray: it's been years so I'm fuzzy on the details, but there are issues when e-d-s is upgraded and users don't log out
[22:37] <Unit193> ...`killall`? :3
[23:18] <Eickmeyer[m]> bdmurray: Saw your email about the slideshow. Someone in #ubuntu-quality found a problem with one of the translations. Are the translations done?
[23:19]  * Eickmeyer[m] uploaded an image: photo_2020-04-03_15-37-41.jpg (93KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/gmsIwOKJTcYzQVhJpfbHpEnN >
[23:19] <Eickmeyer[m]> bdmurray: ^
[23:22] <bdmurray> Eickmeyer[m]: It needs fixing here https://translations.launchpad.net/ubuntu/focal/+source/ubiquity-slideshow-ubuntu/+pots/ubiquity-slideshow-ubuntustudio/es/+translate
[23:22] <Eickmeyer[m]> bdmurray: Thanks, I'll pass that along.