From: Vagrant Cascadian <vagrant@debian.org>
To: guix-devel@gnu.org
Subject: Re: [bug#40190] Linux-Libre 5.7
Date: Mon, 08 Jun 2020 13:52:41 -0700 [thread overview]
Message-ID: <87lfkxfffq.fsf@ponder> (raw)
In-Reply-To: <87o8ptffqs.fsf@ponder>
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
Resending to correct list...
On 2020-06-08, Vagrant Cascadian wrote:
> On 2020-04-17, Mark H Weaver wrote:
>> Vagrant Cascadian <vagrant@debian.org> wrote:
>>> I think the patcset now needs some minor updates to apply to master, but
>>> just wondering when we could consider switching to 5.6... ?
>>
>> I do not wish to be a blocker on this, and moreover I would welcome it
>> if someone else would step up to take over maintenance of our kernel
>> packages.
>
> Thanks for all your work!
>
> I've just pushed the source update for 5.7.1 (and packages for
> linux-libre-arm*-generic)...
>
>
>> However, I should say that for all previous kernel upgrades, I have
>> taken the time to consider each of the new configuration options
>> presented by "make oldconfig" and to try make a sensible choice for each
>> one. I have not found it sufficient to rely on the automatically
>> selected choices, which very often default to "no" for modules that
>> ought to be included, and occasionally default to "yes" for options that
>> are contrary to our commitment to the GNU FSDG.
>>
>> I will leave it up to the Guix maintainers to decide what to do if no
>> one volunteers to take up the job of properly updating our default
>> kernel configurations.
>
> I still do not have the the time, ability or confidence to review
> updating the configs for multiple architectures...
>
> I wasn't able to produce a working config for 5.7.x on x86_64 (issues
> with graphics on intel prevented sway from loading), let alone one that
> has been scrutinized for correctness in terms of GNU FSDG.
>
> Can anyone else step in to help with reviewing kernel config updates?
>
> Alternately, is it plausible to work out a blacklist/whitelist feature
> for options that can get updated more dynamically that a whole kernel
> config? That's well outside my skillset in terms of guile, but that
> might be a more maintainable option for the future...
>
>
> live well,
> vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
prev parent reply other threads:[~2020-06-08 20:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 19:14 RFC: Linux-Libre 5.5.x on pinebook pro Vagrant Cascadian
2020-03-19 19:25 ` Vincent Legoll
2020-03-20 4:35 ` Vagrant Cascadian
2020-03-22 13:21 ` RFC: Linux-Libre 5.5.x Vagrant Cascadian
2020-03-23 4:08 ` Vagrant Cascadian
[not found] ` <87mu7xg34t.fsf@ponder>
[not found] ` <87h7y5g30m.fsf@ponder>
[not found] ` <874ku5fkoq.fsf@ponder>
[not found] ` <87369ovbpu.fsf@devup.no>
[not found] ` <87tv24mnbo.fsf@ponder>
[not found] ` <877dywno8o.fsf@ponder>
[not found] ` <874ku0no5n.fsf@ponder>
[not found] ` <87imhzb4sk.fsf@yucca>
[not found] ` <87imhxud4b.fsf@netris.org>
[not found] ` <87o8ptffqs.fsf@ponder>
2020-06-08 20:52 ` Vagrant Cascadian [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lfkxfffq.fsf@ponder \
--to=vagrant@debian.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).