eze/RC cycle for 2.06 as the same effort is better spent getting 2.06
out the door.
But I'm pretty sure there have been previous threads discussing the hope
of maintenance releases, and a tentative statement by the project
maintainers that they will try to do so going forward.
So hopefully t
because no one is publicizing a list of
FYI-these-patches-are-really-important-and-you-really-should-backport-them".
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
OpenPGP_signature
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
quite missing the point, I'd
say. Do you expect people looking for CI status for patches to not visit
gitlab.com, only run a script to curl CI status over the API?
I'm not personally familiar with the captcha argument, and honestly, my
personal standards on multiple repo-criteria counts are
file is in
> master).
Yeah, having a somewhat independent script to run CI builds is good, it
helps avoid getting locked into specific CI providers. :)
As we've seen from e.g.
https://www.theregister.com/2020/11/02/travis_ci_pricng/
https://news.ycombinator.com/i
, and maybe even respond to the mailing list with
status reports.
e.g.
https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/20108
(Using a patchwork also prevents patches from disappearing!)
> This is currently not officially part of the GRUB project, so creating
> issues, for instance, should still be done on Savannah. I'll be sending
> out a patch series to the list soon with the changes used to integrate
> GRUB into GitLab's CI.
>
> If you've made it this far, congratulations! I hope we can put this to
> good use and help speed up GRUB's development cycle.
>
> Glenn
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
OpenPGP_signature
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
of more up to date
official sources should always be considered a good thing. Having a
delta between upstream sources and built sources is never *good*, even
if it is often a *necessary evil*.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP dig
instead propose a third option though. grub could benefit
from a policy to fork off maintenance branches for CVE fixes, and all
distros would upgrade to 2.04.1 (or 2.02.1), then later on a couple of
rolling release distros would upgrade to 2.06 once it is released.
--
Eli Schwartz
Arch Linux B
from luks1 to luks2. The grubx64.efi image should both support luks2 due
to manually added modules, AND automatically Do The Right Thing with the
generic cryptomount command.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
__
then, you'll have to manually add required GRUB modules for LUKS2,
> PBKDF2 and the gcry modules required for your configured cipher/hash
> combination.
This sounds like useful guidance.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted U
t; prompt involved. Only entering
> the correct LUKS passphrase is required.
>
> Hope that helps...
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
b is failing this way, and does a workaround
> exist?
>
> Thank you for your time...suggestions welcome.
If I remember correctly, you mentioned on IRC that you could
successfully use grub-git to cryptomount a luks1 /boot/grub directory,
then use the grub modules there to further cr
On 6/21/20 2:26 PM, Mike Gilbert wrote:
> On Thu, Jun 11, 2020 at 6:58 PM Eli Schwartz wrote:
>>
>> On 11/7/19 12:08 AM, Vladimir 'phcoder' Serbinenko wrote:
>>> On Wed, 6 Nov 2019, 20:55 Michael Chang, wrote:
>>>
>>>> On Wed, Nov 06,
ke system unbootable on upgrade, I'd rather be fixing this than just
> pepper over it.
Given grub 2.06 is on the horizon, is it time to re-evaluate this and
disable something known to be badly broken?
Failing that, is anyone working on making it a separ
ng-patches.html
source:
https://git.archlinux.org/pacman.git/tree/doc/submitting-patches.asciidoc
Currently the grub-dev manual talks a lot about the coding style
(similar in spirit to my HACKING.asciidoc/HACKING.html) and very little
about how to submit patches. This information is definitely m
rub.texi itself.
>
> That would be perfect. Especially if it appears in 2.06 release.
>
> Thank you for doing this work!
I believe the suggestion is to add the new program check-commands.py
provided at the end of the previous message, AND make it autogenerate a
grub.texi stub listing &qu
n't
support gnu99 will fail to compile grub, wouldn't they?
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
he configs
> that you have observed getting malformed.
It is the position of the Ubuntu developer who responded to the OP's
launchpad.net bug which motivated this cross-post to the grub-devel list.
Direct link to the quoted phrases:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/
inuation across multiple lines (of all the things one might do in a
POSIX sh formatted configuration file, this is pretty tame), an issue of
"highly unusual abuse of POSIX shell semantics", this is pretty bad I
have to say. Also, it's victim blaming.
Just my $0.02 as a distro person
On 3/10/20 2:58 PM, Patrick Steinhardt wrote:
> In order to support the Argon2 key derival function for LUKS2, we
> obviously need to implement Argon2. It doesn't make a lot of sense to
> hand-code any crypto, which is why this commit instead imports Argon2
> from the cryptsetup project. This commi
On 10/21/19 11:09 AM, Daniel Kiper wrote:
> On Wed, Oct 16, 2019 at 11:03:06PM -0400, Eli Schwartz wrote:
>> The 'which' utility is not guaranteed to be installed either, and if it
>> is, its behavior is not portable either.
>>
>> Conversely, the 'command
The 'which' utility is not guaranteed to be installed either, and if it
is, its behavior is not portable either.
Conversely, the 'command -v' shell builtin is required to exist in all
POSIX 2008 compliant shells, and is thus guaranteed to work everywhere.
Examples of open-source shells likely to
21 matches
Mail list logo
