Leo Famulari writes:
> On Tue, Aug 25, 2020 at 05:01:07PM -0400, Leo Famulari wrote:
> But, we must remember that the other party may not understand the
> context of their suggestion deeply enough to know why it should not be
> implemented. There are technical *and* social contexts at play, and t
On Tue, Aug 25, 2020 at 05:01:07PM -0400, Leo Famulari wrote:
> If there are concrete problems to report or changes to request, please
> let us know by opening a bug ticket at , or by sending
> a patch to .
I'd like to explain more clearly what I meant by my last message.
First, it's important to
Hi,
I have started handling major updates of linux-libre for Guix, starting
with version 5.7 (collaborators are invited!).
I didn't read this discussion because it's quite long and I don't
perceive that anything needs to change with how we package linux-libre.
It has worked well for several years
Hello, Mark,
On Aug 25, 2020, Mark H Weaver wrote:
> Alexandre Oliva wrote:
>> On Aug 15, 2020, Mark H Weaver wrote:
>>
>>> If I were to implement this, what would you suggest I do if the patches
>>> fail to apply
>>
>> Look at the conflict presented by the rebase, and resolve the likely
>>
Hi Alexandre,
Alexandre Oliva wrote:
> On Aug 15, 2020, Mark H Weaver wrote:
>
>> If I were to implement this, what would you suggest I do if the patches
>> fail to apply
>
> Look at the conflict presented by the rebase, and resolve the likely
> freedom issue introduced at that point.
>
>> if th
Hello, Mark,
On Aug 15, 2020, Mark H Weaver wrote:
> I was talking about my hope to enable users, *on their own
> machines* and using *their own private build recipes*, to make a
> best-effort deblobbing of a non-standard kernel variant that they need
> to use for whatever reason.
A non-free ke
On Aug 15, 2020, Mark H Weaver wrote:
> Alexandre Oliva wrote:
>> On Aug 12, 2020, Mark H Weaver wrote:
>>> I also consider it unwise for all of us, as a matter of habit or policy,
>>> to trust the integrity of the computer systems used by the Linux-libre
>>> project to perform the deblobbing.
On Aug 15, 2020, Mark H Weaver wrote:
> I only checked your claims regarding 5.4, and found that you're mistaken
> about them being updated in 5.4.44.
There was a change to scripts at 5.4.44, just not one you cared about,
because you didn't use the (discontinued) deblob-main script to prepare
a
On Aug 15, 2020, Mark H Weaver wrote:
> Alexandre Oliva wrote:
>> On Aug 12, 2020, Mark H Weaver wrote:
>>
> It may be useful for users with newer hardware devices, which are
> not yet well supported by the latest stable release, to use an
> arbitrary commit from either Linus' main
Hello, Mark,
Apologies for the delay in responding. It's been an "interesting" week.
I'm breaking up what turned out to be a very very long reply into
multiple posts, so as to address the various issues in separate posts,
that might very well turn into separate subthreads.
On Aug 15, 2020, Mar
On Sat, 15 Aug 2020 21:24:08 -0400
Mark H Weaver wrote:
> Hi Alexandre,
>
> I thought about it some more, and I've changed my mind on one point:
> I've decided that for future kernel updates, in order to eliminate the
> risk of unintentionally allowing blobs into Guix, I will either wait
> for L
I always thought the reproducible builds mantra was "trust but verify",
not to actively distrust?
pgpFznz8RXrAU.pgp
Description: OpenPGP digital signature
Hi Alexandre,
I thought about it some more, and I've changed my mind on one point:
I've decided that for future kernel updates, in order to eliminate the
risk of unintentionally allowing blobs into Guix, I will either wait for
Linux-libre to publish updated deblob scripts, or else I will manually
Hi Alexandre,
Alexandre Oliva wrote:
> On Aug 12, 2020, Mark H Weaver wrote:
>
It may be useful for users with newer hardware devices, which are
not yet well supported by the latest stable release, to use an
arbitrary commit from either Linus' mainline git repository or some
Hello, Mark,
On Aug 12, 2020, Mark H Weaver wrote:
> Mark H Weaver wrote:
>>> the linux-libre project periodically deletes most of its older
>>> tarballs, even if there are no accidents.
> Jason Self responded:
>> Just FYI that git://linux-libre.fsfla.org/releases.git was created
>> mainly to
Hi Jason,
I didn't see your email until just now. I read this list only
sporadically, so it's best to keep me in the CC list for messages that
you'd like me to see, or that are responses to me.
Mark H Weaver wrote:
>> the linux-libre project periodically deletes most of its older
>> tarballs, e
Bengt Richter wrote:
> BTW, how did nix get such a weird alphabet for 0-31 ?
My guess is that the weird alphabet was chosen to avoid some of the most
common letters in English text, so that when scanning build outputs for
embedded hashes, one is less likely to mistake something else (e.g. text
or
Bengt,
Bengt Richter 写道：
BTW, how did nix get such a weird alphabet for 0-31 ?
Watermarking themselves? :)
This question probably deserves a Nix FAQ entry by now, if there
isn't one already :-)
“This is to reduce the possibility that hash representations
contain character sequences that
On +2020-08-09 18:17:48 -0400, Mark H Weaver wrote:
>
> Note that although base32 encodes 5 bits per character, the first
> character of a base32-encoded sha256 hash can only be 0 or 1, since
> there's only 1 bit remaining to encode after the other 255 bits have
> been encoded in the last 51 cha
> the linux-libre project periodically deletes most of its older
> tarballs, even if there are no accidents.
Just FYI that git://linux-libre.fsfla.org/releases.git was created
mainly to solve that problem. Versions are now pretty much permanent.
> It may be useful for users with newer hardware de
Hi Vagrant,
Vagrant Cascadian wrote:
> At a longer glance, it looks like I failed to update the hashes
> correctly. The hashes for deblob-check 5.7 and deblob-check 5.8 both
> began with "1n" and I must have somehow glazed over the differences and
> not updated the local commit.
Ah, okay, that m
On Sat, Aug 08, 2020 at 11:30:40PM -0400, Mark H Weaver wrote:
> Note that the default kernel configurations for 5.8 still need to be
> added. Leo, would you like to work on that?
I'm planning to do that when the 5.8 kernel becomes the "stable" kernel.
I assume this will happen soon.
On 2020-08-08, Vagrant Cascadian wrote:
> On 2020-08-08, Mark H. Weaver wrote:
>> Vagrant Cascadian wrote:
>>> I saw the 5.8 was out, and gave a quick shot at updating it, but it hung
>>> python indefinitely during the deblobbing process.
>>
>> I was unable to reproduce this problem. I simply add
On 2020-08-08, Mark H. Weaver wrote:
> Vagrant Cascadian wrote:
>> I saw the 5.8 was out, and gave a quick shot at updating it, but it hung
>> python indefinitely during the deblobbing process.
>
> I was unable to reproduce this problem. I simply added version 5.8 in
> the usual way, without chan
Hi Vagrant,
Vagrant Cascadian wrote:
> I saw the 5.8 was out, and gave a quick shot at updating it, but it hung
> python indefinitely during the deblobbing process.
I was unable to reproduce this problem. I simply added version 5.8 in
the usual way, without changing the deblobbing code at all,
Hi,
Vagrant Cascadian wrote:
> Thanks for updating linux-libre to 5.7!
Yes, many thanks to Leo Famulari for taking care of that (large) job.
> I saw the 5.8 was out, and gave a quick shot at updating it, but it hung
> python indefinitely during the deblobbing process. I also tried
> switching t
Thanks for updating linux-libre to 5.7!
I saw the 5.8 was out, and gave a quick shot at updating it, but it hung
python indefinitely during the deblobbing process. I also tried
switching to python 3 instead of python 2, but it had the same
issue. Apparently this is a known issue:
https://lists.
27 matches
Mail list logo
