[17:02] <bdmurray> vorlon: There are a lot of new grub-installer bug failures will older media fail to install grub?
[18:15] <vorlon> bdmurray: should not
[20:55] <bdmurray> vorlon: there are quite a few with the following error - "grub-installer: grub-install: error: failed to register the EFI boot entry: Operation not permitted."
[20:58] <sarnold> I've seen a *lot* of those
[20:58] <bdmurray> Is *lot* > "quite a few" ?
[20:58] <sarnold> and I don't recall seeing a satisfying explanation of what causes those
[20:59] <sarnold> bdmurray: well, it's more than several by a bunch
[20:59] <ahasenack> such precise metrics :)
[21:15] <vorlon> bdmurray: that's not a new failure; we have a number of older reports like that, and ultimately it comes down to some sort of incompatibility between libefivar and the firmware.  (Not sure if it's a firmware bug or a client software bug)
[21:16] <seb128> those grubs error are probably the most reported issues on launchpad
[21:16] <seb128> it feels wrong that we never tried to figure the problem out or to properly message it to user...
[21:16] <vorlon> it's firmware-dependent
[21:17] <vorlon> so if someone has a machine where they can reproduce it, I'm happy to debug
[21:17] <seb128> still, it's hitting lot of users and we are not doing much for them
[21:17] <seb128> well, we get almost daily reports for years but we ignore those
[21:17] <vorlon> but all the reports we've gotten in LP have been drive-bys from people who don't follow up
[21:17] <seb128> do we have any debug instructions we could end to users to get some data?
[21:17] <vorlon> I don't ignore them; I follow up and get no response
[21:18] <vorlon> dmidecode?
[21:18] <seb128> I would disagree with that, most reports didn't get a reply
[21:18] <vorlon> then I don't know where they're filing the bugs
[21:19] <seb128> ubiquity or grub2 in most cases
[21:19] <seb128> anyway, if we had a stock reply with instructions on what debug commands are useful that would be nice
[21:24] <bdmurray> I should be able to script commenting on the bugs with the commands and we can see what happens.
[21:26] <seb128> vorlon, replying to your question, https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bugs?orderby=-id&start=0
[21:27] <seb128>  1377 New bugs
[21:28] <seb128> it's daily report of install failures of that type or of Invalid argument errors
[21:28] <vorlon> ok well it's non-trivial to sort through the logs that get attached to ubiquity bug reports to classify these bugs
[21:29] <vorlon> the ones that get filed against shim-signed and grub2 have clear logs and generally get triaged... without follow-up from submitters
[21:30] <seb128> follow-up is probably tricky indeed
[21:30] <seb128> some have logs though
[21:30] <vorlon> again, logs are useless, this is a firmware-specific problem and no one I know has affected firmware
[21:30] <seb128> e.g https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1874610 from 'boot-repair' whatever that is, e.g https://launchpadlibrarian.net/481279131/plain so it's likely those users would reply if we had followed up
[21:31] <vorlon> boot-repair ugh
[21:31] <vorlon> ah that one at least lists a machine model
[21:31] <seb128> we should at least be able to tweak the apport hook to collect the info that would be useful
[21:32] <seb128> if what we need is a list of hardware references
[21:32] <seb128> vendor/model of laptops or similar
[21:32] <vorlon> what we really need isn't to know what the machine is, but to have access to an affected machine to debug
[21:32] <vorlon> I don't suppose cert has a Dell Latitude e7270
[21:32] <seb128> well, knowing the machine could allow us to maybe talk to the vendor to get one of those
[21:33]  * vorlon nods
[21:34] <vorlon> also, fwiw, at least some of these are matters of firmware configurations that are incompatible with installing Ubuntu - because they have a firmware setting that locks the boot order
[21:35] <vorlon> I don't know what we can do to improve the user's experience in that case; the failure happens at the end of the install, and requires a reboot to get into the firmware to fix the setting
[21:35] <sarnold> could that be tested via a no-op write at the start?
[21:36] <vorlon> possibly
[21:36] <sarnold> I suppose if we actually had one of those machines to tst one, we'd know :) heh
[21:36] <seb128> we started poking at bios setting to warn users upfront about issues with e.g rts disk setups
[21:36] <seb128> maybe we could something similar for those situations?
[21:37] <seb128> (rts->rst)
[22:50] <mwhudson> Trevinho: hi do you know what the story is with gjs and its autopkgtests?
[22:51] <Trevinho> mwhudson: not really, I've seen the failures this morning but I was a bit busy with other sides of the stack, but it's not clear to me what's failing, given they worked fine at build time
[22:52] <mwhudson> Trevinho: ah i bet they need to be run with the libffi from proposed
[22:52] <mwhudson> although no, i tried that yesterday
[22:52] <Trevinho> mwhudson: I need to check it closely, however, ideally we're soon importing a new mozjs and gjs versions anyways
[22:52] <Trevinho> mwhudson: yeah, I was thinking libffi could be related
[22:53] <Trevinho> mwhudson: iirc I built with proposed in my sbuild and they went well
[22:53] <mwhudson> Trevinho: the same tests are run at build and autopkgtest time?
[22:53] <mwhudson> i guess i can retry with all-proposed=1
[22:55] <mwhudson> Trevinho: how soon is "soon", it's one of the things blocking the libffi transition
[22:55] <mwhudson> although ghc is also blocking the libffi transition and that has a few more days of hamster-wheel spinning at best
[22:56] <Trevinho> mwhudson: so, I checked I tested with proposed... but let me retry
[22:57] <Trevinho> mwhudson: as per "soon", I've uploaded mozjs78 in debian and it's in new there, so would just need a sync in ubuntu (and NEW approval), same for new gjs, it's in experimental...
[22:57] <mwhudson> Trevinho: well as you say the builds passed on launchpad, so if that runs the same tests then it *should* work with all-proposed=1
[22:57] <mwhudson> unless it's vm vs chroot or kernel versions or some such
[23:00] <Trevinho> mwhudson: I didn't rebuild in LP after transition I think, as I did it before uploading... So it likely built there with previous ffi.
[23:00] <mwhudson> oh
[23:02] <mwhudson> no, it built with libffi8ubuntu1 amd64 3.4~20200819gead65ca871-0ubuntu3
[23:05] <Trevinho> mwhudson: ok, so rebuilt locally... and went well as well
[23:05] <Trevinho> with 3.4 as you say
[23:22] <mwhudson> Trevinho: ok
[23:23] <Trevinho> mwhudson: I've retriggered it and worked though https://autopkgtest.ubuntu.com/packages/gjs/groovy/amd64
[23:24] <Trevinho> mwhudson: oh, no sorry... i misread the number I think
[23:24] <mwhudson> yeah i was going to say, the pass is the version from release
[23:28] <Trevinho> anyway sure something changed ffi.. as per "not ok 7 - Unicode encoding for symbols should be functioning properly for ARGV and imports."
[23:29] <Trevinho> mwhudson: installed tests have changed install location in this release, I'm not sure if this affected though
[23:39] <mwhudson> Trevinho: it passed with all-proposed=1 https://autopkgtest.ubuntu.com/packages/gjs/groovy/amd64
[23:39] <Trevinho> \o/
[23:39] <mwhudson> yeah
[23:40] <Trevinho> without all-proposed it means it uses only part of proposed or what? :o
[23:40] <mwhudson> only the package being tested
[23:40] <mwhudson> the idea is to test if the package will make release worse
[23:40] <mwhudson> so by default you test release + the package
[23:42] <mwhudson> britney has gotten a bit smarter about this recently, it's clear that gjs isn't even installable unless libffi migrates as well, so it tests gjs + libffi from proposed and everything else from release
[23:42] <mwhudson> clearly there is some other package version that gjs implicitly depends on and ideally we'd figure out what and add a versioned dependency i guess
[23:42] <mwhudson> but well
[23:48] <Trevinho> ah i see