On Tue, 28 Sep 2021 19:11:58 +0200
zimoun wrote:
> The method you are proposing seems awkward; as you say, old/gen7 is
> not currently a valid URL. And you are proposing that you set in
> stone now this URL expecting that maybe it will be valid in the
> future. Ah future cannot be predicted.
Granted that old/gen7 is not currently a valid URL but we can know
that, 5 or 10 years from now, when Linux-libre has moved on to the 8th,
9th or even 10th generation, the 7th generation scripts will exist
there. If Guix can begin checking those additional locations now then,
in the future once
On Tue, 28 Sep 2021 10:43:20 +0200
zimoun wrote:
> Hi,
>
> On Mon, 27 Sep 2021 at 17:46, Jason Self wrote:
>
> [...]
> >
> > Yes. In gen6. They have been moved, not deleted.
> >
> > The versioning and locations in terms of gnuN and genN are knowable
&
On Mon, 27 Sep 2021 19:30:29 -0400
Leo Famulari wrote:
> I didn't check that the files are bit-identical, but my understanding
> is that the "old" revisions of the deblobbing scripts are available
> here:
>
> https://linux-libre.fsfla.org/pub/linux-libre/releases/old/
Yes. In gen6. They have
For some clarity on the situation:
http://www.fsfla.org/pipermail/linux-libre/2021-August/003439.html
The scripts are not being removed and my understanding is that Guix
only uses the scripts anyway.
> and their Git repo is also going to be rewritten to remove them.
The tags for the kernel
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
I always thought the reproducible builds mantra was "trust but verify",
not to actively distrust?
pgpFznz8RXrAU.pgp
Description: OpenPGP digital signature
On Thu, 13 Aug 2020 09:47:21 -0700
Vagrant Cascadian wrote:
> It is also possible to retrieve tarballs directly from linux-libre git
> tags, though I know at least projects hosted on github this does
> occasionally result in non-identical tarballs. Not sure what factors
> might trigger this,
> 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
I understand that updated headers are needed in order for the new
version of VLC to compile successfully. Please see attached. I hope
this is sufficient.
Also, since Alexandre Oliva periodically removes tarballs so as to
free up space on the virtual machine that hosts these, it might also
be a
Mark H Weaver declared:
Updating linux-libre-headers entails a full rebuild of everything in
Guix.
Yes, I know. It was on my To Do list I hadn't picked up on that the
update was already done so never mind.
signature.asc
Description: PGP signature
/dev/mem has become an optional device. This patch sets /dev/mem to
enabled.
0001-gnu-linux-libre-Set-CONFIG_DEVMEM-y.patch
Description: Binary data
signature.asc
Description: PGP signature
Ludovic Courtès said;
Right. The version has to be chosen carefully (should be a LTS
version and one that is likely to remain on fsfla.org and/or that we
mirror on alpha.gnu.org), plus we don’t want glibc’s requirement to
be too high so people can use Guix on GNU/Linux with relatively old
Alex Sassmannshausen alex.sassmannshau...@gmail.com wrote ..
Hello,
I received a request for instructions on how to get Guix running as
standalone on the Gluglug X60 — my work is ongoing (I haven't
reconfigured the Grub BIOS, nor have I got wireless working yet), but
a first draft may help
Andreas Enge said:
I am not quite sure what google hangout is, but it sounds a lot like
a proprietary software as a service. So I do not think that would be
in line with the gnu philosophy...
You got it right. Other options are available for screen sharing that
are free software. There are
Hello, I wanted to make sure that I was doing this correctly before
committing anything. It seems that it's best to have all of the
kernel's config stuff centrally located. Plus, all of these are
already enabled in the normal config, and I'd argue in a better way.
For example: CONFIG_VIRTIO_BLK
Ludovic Courtès said:
Furthermore I would rather keep CONFIG_VIRTIO_BLK=m rather than =y
precisely because that module only makes sense when running a QEMU
guest and not otherwise.
WDYT?
My reason for making it y instead of m is:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902951
Carlos Carleos asked:
What would be the similar sequence for GUIX?
Edit the package definition as appropriate to accomplish what you need
to do? Make a new package definition that uses the old one as an input
with whatever changes are needed? If the changes you're making would
be generally
With the number of packages available using Guix (and it seems to keep
increasing) keeping up on the latest upstream versions manually is
gonna be a pain. :) Shouldn't the checking be automated in some way?
One idea might be to create a bug in the GNU Bug Tracker when a new
upstream release is
Ludovic Courtès asked:
What was the reason for reverting to 3.16.1 and then switching back to
3.16.2?
I jumped the gun. I compiled 3.16.2 for my public repository using the
deblob scripts and later on updated Guix, but I didn't think to check
if lxo had actually published 3.16.2 tarballs yet.
Authorized binary substitutes from Hydra might help. Otherwise, more
space?
signature.asc
Description: PGP signature
Ludovic Courtès:
Perhaps even a different format, like, say:
The following package will be upgraded:
guile 1.8.8 → 2.0.9out /gnu/store/...
Thoughts?
I like that. :)
Hello,
There's a new x86-64 machine on the block (soon to be) building
things. Guix has been installed on it and hopefully its fast CPU, 16GB
of RAM and 2TB of storage will be pressed into service soon to help
with the upcoming giant rebuilds.
signature.asc
Description: PGP signature
John Darrington asked:
The way you describe it above, would it not be considered SaaS?
No, assuming it's running on FSF/GNU equipment: Then the GNU Project
is doing its own computing on its own machines. This is one reason I
liked the idea of somehow integrating this into the existing FTP
upload
Since GNU maintainers (in theory) already upload their stuff to
ftp.gnu.org or alpha.gnu.org using that file triplet it might be nice
if something could be worked into their existing workflow. Perhaps new
commands in the directive file to do the things you describe? This
would probably require
* gnu/packages/admin.scm (wpa-supplicant): Update to version 2.2.
From a2f2de4db39269543e3fd2f0dca397b9dbb34e67 Mon Sep 17 00:00:00 2001
From: Jason Self j...@jxself.org
Date: Sun, 20 Jul 2014 07:13:19 -0700
Subject: [PATCH 1/1] gnu: wpa-supplicant: Update to 2.2.
* gnu/packages/admin.scm (wpa
From 8077c5b884c296b59607176193dbc939908a4fe0 Mon Sep 17 00:00:00 2001
From: Jason Self j...@jxself.org
Date: Sun, 20 Jul 2014 12:08:58 -0700
Subject: [PATCH 1/1] gnu: ffmpeg: Remove --disable-vis.
* gnu/packages/video.scm (ffmpeg): Remove --disable-vis.
Signed-off-by: Jason Self j...@jxself.org
* gnu/packages/admin.scm (htop): Update to version 1.0.3.
From a15e2d287f205b088b9141cb1e80ee0592d1a274 Mon Sep 17 00:00:00 2001
From: Jason Self j...@jxself.org
Date: Sat, 19 Jul 2014 13:40:43 -0700
Subject: [PATCH 1/1] gnu: htop: Update to 1.0.3.
* gnu/packages/admin.scm (htop): Update
David Thompson asked:
Any ideas?
I have one of these machines too. You're using the fork of coreboot
called libreboot right? The grub.cfg that you see is in from the flash
chip. Try using the Scan option at the bottom to have it scan the
HDD and use that grub.cfg instead.
Once the Scan option
* gnu/packages/xiph.scm (libogg): Update to version 1.3.2.
0001-gnu-libogg-Update-to-1.3.2.patch
Description: Binary data
This change updates FLAC to version 1.3.0 and removes
flac-fix-memcmp-not-declared.patch. The patch has been incorporated by
upstream and it's no longer necessary to maintain it separately.
From c21c2e188a19994d3e3b1cce8896c153d2a1ee0c Mon Sep 17 00:00:00 2001
From: Jason Self j...@jxself.org
Date
Ludovic Courtès asked:
Anyway, I agree that it’s a major inconvenience, but I wonder if we
should be concerned about shipping without testing. What do people
think?
I have no objection.
32 matches
Mail list logo
