Re: Linux-libre source code will be taken offline

[Jason Self]

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. ;-) 

On the contrary: The file versioning and locations are 100% knowable
and predictable in advance. This has been the point I've been trying to
get across this entire time.

> I am not familiar with the Linux Libre scripts.  Are these scripts
> already under a Git repo?

Yes, git://linux-libre.fsfla.org/releases.git which carries tagged
releases, scripts, and logs. As you can see it goes all the way back to
2.6.21.

The primary motivation for the creation of this git repository was
actually for Guix, as a solution to the feedback from the tarballs
being removed due to the lack of disk space, but it appears that it is
not being used.


pgpS_jzKZewEi.pgp
Description: OpenPGP digital signature

Re: Linux-libre source code will be taken offline

[Jason Self]

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 the current Guix version becomes an old version,
hopefully it can transparently handle that transition without issue. Or
just use git. :)

Even this method is just a band-aid though and has a different set of
challenges for the long-term. I'd be happy to discuss that with whoever
is interested.


pgpQIsClMHVKg.pgp
Description: OpenPGP digital signature

Re: Linux-libre source code will be taken offline

[Jason Self]

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
> > and predictable in advance. I wonder if there is, or could be made,
> > a way to leverage that so that future moving of files can be done
> > without causing problems, as long as the files themselves remain
> > otherwise identical. As an example, the current cleanup scripts
> > might be found in old/gen7 in the future. Although using git would
> > probably be a better choice as it would seem to eliminate URL
> > hunting.  
> 
> Guix has the availability to transparently build any old version using
> “guix time-machine”, i.e.,
> 
>   guix time-machine --commit=0c7c84407d65f3d03ad1fe3984ae4d524992f498
> \ -- build linux-libre
> 
> should build the Linux (libre) kernel as it was on 2020, 25th May.
> 
> If the user allow substitutes, then the necessary materials is fetch
> from machines hosted in Berlin and maintain by Guix folk.
> 
> However, if the user does not allow substitutes, then the source are
> first fetched from upstream.  Here several cases of origin.  Upstream
> is still up, everything is fine.  Upstream disappeared in the
> meantime, it depends on the “type” of the origin and the core issue
> is the mapping between the information at package time (e.g., 2020,
> 25th May) and the servers providing a fallback at request time for
> this missing source.
> 
> When the upstream source is a Git repo, this map is a simple
> contend-addressed lookup by a (almost) straightforward resolver.
> 
> When the upstream source is not Git repo, this map becomes harder and
> requires – in addition to a fallback server – an external resolver:
> something that maps from the information at package time (2020, 25th
> May) to the fallback server.
> 
> If the package linux-libre defined on 2020, 25th May (written on
> stone) points to an URL source which disappears, this Guix
> time-machine feature becomes doomed because URL is a really bad
> contend-addressed system as all the broken internet shows us.
> 
> For sure, the infrastructure needs to evolve for a better future;
> easier maintainability for instance.  However, please consider the
> archivist point of view and help to not break the past. :-)

It's not really breaking the past if this is how the past worked in
reality: That previous generations of scripts are moved to old/genN,
but more of Guix's representation of how the past worked which says
that they not move, which doesn't reflect the actual reality of the
past. The two don't seem equivalent.

It seems that Guix can handle multiple download locations already,
either from the main location or from others so why is the old/gen7
location not already in the kernel build recipe? If a new freedom
problem were found that resulted in the need to come up with an 8th
generation, the current ones will be findable in old/gen7. Is Guix
build machinery currently aware of that and ready to check old/gen7
now for whenever that future move happens? If not, then this would seem
to create future breakage when that happens. This move is 100% knowable
and predictable in advance so why not have it ready for now and put
old/gen7 into the recipe for the kernel, even if it's just an additional
hardcoded URL and not something dynamically computed? If not, using git
would seem to be a better choice. I'm not sure why it's not used
already.


pgpBs5nAG4au9.pgp
Description: OpenPGP digital signature

Re: Linux-libre source code will be taken offline

[Jason Self]

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 been moved, not deleted.

The versioning and locations in terms of gnuN and genN are knowable and
predictable in advance. I wonder if there is, or could be made, a way to
leverage that so that future moving of files can be done without
causing problems, as long as the files themselves remain otherwise
identical. As an example, the current cleanup scripts might be found in
old/gen7 in the future. Although using git would probably be a better
choice as it would seem to eliminate URL hunting.


pgpiE2tI6auaf.pgp
Description: OpenPGP digital signature

Re: Linux-libre source code will be taken offline

[Jason Self]

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 source code would be removed (but not for the
cleanup scripts) but my understanding is that this doesn't requite
rewriting history.

The release tarballs are already gone but the tags corresponding to the
libre kernel versions continue to exist in releases.git. My
understanding is that the desire is to eventually remove those
although I'm not sure about the timing but certainly long enough into
the future to allow time to adapt.

Also, the cleanup scripts will continue to exist in git as well, in both
old and new versions, even after the tags for the corresponding libre
kernel release have been deleted, so an interested person would still
be able to recreate the appropriate source code even after tag deletion
has happened. Given that they result in kernel source code with known
freedom problems it seems very undesirable to use the old versions
though.

This could be an example that it's desirable to use releases.git to
obtained needed pieces, whether scripts or the source code.


pgphRt9rHLkN_.pgp
Description: OpenPGP digital signature

Re: Linux-libre 5.8 and beyond

[Jason Self]

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 Linux-libre to publish updated deblob scripts, or else I will
> manually check for new blobs.

This can be determined by checking for the availability of the new
kernel version in git. The git repository is updated first, prior to
tarballs being created so I assume you'd want to be looking there given
that speed of updates seems important. If the new kernel version
appears without a corresponding script update then you can know that no
script updates were determined to be necessary.

Wouldn't a better setup be to obtain the desired kernel version from
Linux-libre, obtain the desired kernel version from kernel.org,
independently run the clean-up scripts, and then toss out the results
from kernel.org once the source code is determined to be identical?*

I mean, if you're already willing to wait until the analysis of whether
updated cleanup scripts are needed or not has been done, then you're
already at the point of the Linux-libre kernel source code being
available too because once that determination is made, any updated
scripts and the corresponding kernel source code are pushed into git
simultaneously.

Confirming if the results you get from the cleanup scripts are the same
is helpful all around. It is not necessary to trust the Linux-libre
project infrastructure because you're also verifying the integrity and
also gets you access to the double verification steps that are done
which check that the version does in fact correspond to the upstream
version plus the changes that Linux-libre made, and that it also
corresponds to the previous release plus the incremental patches.

* As a disclaimer there may be one difference in that the clean-up
  scripts will in some cases delete all of the files in a directory
  while leaving the directory itself in place. Git doesn't track empty
  directories and so diffing of the entire kernel source code would
  reveal that. The diff should otherwise report everything to be
  identical.


pgp83VtwwEZLp.pgp
Description: OpenPGP digital signature

Re: Linux-libre 5.8 and beyond

[Jason Self]

I always thought the reproducible builds mantra was "trust but verify",
not to actively distrust?


pgpFznz8RXrAU.pgp
Description: OpenPGP digital signature

Re: Linux-libre git repository

[Jason Self]

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, other than changing tags, but possibly different
> git versions, tar versions and flags, and compression tool versions
> and optimizations could be a factor. Reproducible builds has
> documented some potential causes:

Adding in compression changes this because, for just one example,
compression details can change between versions of compressors.

Assuming that there is no compression and there aren't changes in the
underlying git repository and assuming that git archive is invoked with
precisely the same parameters each time, git archive is supposed to
generate bit-identical tarballs between different platforms/versions of
git (it's considered a bug if it doesn't.)

Indeed, the Linux stable tree takes advantage of this reproducibility by
adding a GPG signature for the uncompressed tarballs as a git note under
refs/notes/signatures/tar. The signature also includes a comment
with the precise command to regenerate the uncompressed tarball with
git archive. This then makes it possible to verify a GPG signature of an
uncompressed tarball that way. An example is [0]. cgit automatically
adds the (sig) link when the corresponding git note is added in
refs/notes/signatures/tar but they can also be accessed directly from
within git.

I found that useful after learning that GPG signatures within git itself
"only validate the commit file contents up to the SHA-1 of the top level
tree, it's not a GPG signature of the entire tree state. This means that a
SHA-1 collision on the tree object, or any blob object, still results
in a valid GPG signature."

It seemed to be a neat way to sidestep the whole matter of SHA-1 falling
apart, at least until git moves on to SHA-2 at some as-yet-unknown
future point.

Anyway, the Linux-libre git repository similarly contains GPG
signatures for the uncompressed tarballs but as tags not as a git note
but either way the outcome is the same.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/






refs/notes/signatures/tar


pgpPndpRU78qs.pgp
Description: OpenPGP digital signature

Re: Linux-libre 5.8 and beyond

[Jason Self]

> 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 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
> other subsystem tree.

The cleaning up scripts are version-specific and won't work on an 
"arbitrary commit from Linus's mainline git repository" (i.e., someone
wanting to get today's most recent commit going into 5.9.) The scripts
would fall over and die in such a scenario, or if forced to continue by
using --force the result would be incomplete cleaning. Using the
scripts on a version other than what the precise version that they were
intended for can also cause them to fail in obscure ways, as Vagrant
Cascadian has found out firsthand by running the 5.7 cleaning scripts
on 5.8 (that was determined to be the source of the problems they were
having.) If you look closely at the results of Vagrant Cascadian's
attempt, you'll see there was more than syntax errors: plenty of blobs
were certainly left in. Thus: As said, the clean up scripts can only be
used for the version that they were intended. Use with any other
version invites problems.

> It allows us to update to a new point version (which usually
> includes security fixes) more quickly, before the linux-libre
> project reacts.

Any attempt outrun the Linux-libre project and get updates out sooner
is unwise. While major new kernel releases will definitely require 
updates to the cleanup scripts, even minor patched versions 
occasionally require changes too. Updating to a new version prior to 
the Linux-libre project having had time to review that new version and 
determine if any updates are needed to the scripts risks introducing
freedom problems in the corresponding Guix version.

The moment that the Linux-libre project determines that scripts are
suitable is the moment that the new cleaned-up release is ready to
publish in git and the appropriate tags will then appear in git. The
compressed tarballs come some time later.


pgpcbWiAK1dCb.pgp
Description: OpenPGP digital signature

Linux-libre 4.1

[Jason Self]

Hello, just wanted to let you know I've made up some kernel
configuration files for 4.1. Just in case you want to use them.

https://jxself.org/git/?p=kernel-configs.git


signature.asc
Description: PGP signature

Re: [PATCH] gnu: linux-libre-headers: Update to 3.18.11

[Jason Self]

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

gnu: linux-libre: Set CONFIG_DEVMEM=y

[Jason Self]

/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

[PATCH] gnu: linux-libre-headers: Update to 3.18.11

[Jason Self]

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 good idea to put a copy of linux-libre-3.18.11-gnu.tar.xz in
http://alpha.gnu.org/gnu/guix/mirror/ along with the current version
3.3.8.


0001-gnu-linux-libre-headers-Update-to-3.18.11.patch
Description: Binary data


signature.asc
Description: PGP signature

Re: 01/01: gnu: vlc: Update to 2.2.0

[Jason Self]

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
> kernels.

If using an LTS version is desired, support for the 3.3 series ended
almost three years ago. The 3.4 series is supported until September
2016. I seem to recall a discussion about a separation of roles though
where, even though there may be some overlap, the intent of GSRC was
to be something people installed on an existing distro and that the
intent of Guix was to be completely independent and standalone. Given
that, how much effort do we want to put in to maintaining that
overlap? Anyway, Debian seems sufficently slow moving to me and so I
looked at that to get an idea of what might be acceptable. They have
3.5 in Wheezy and are jumping to 3.16 for Jessie which I understand is
due soon? Given that, what about using 3.14? It is much newer and
supported until August 2016 [0].

[0] https://kernel.org/category/releases.html


signature.asc
Description: PGP signature

Re: [gnu.org #954922] Vague "licensing" for the symbola font.

[Jason Self]

Alex Kost  wrote:

> IIUC it applies to all the files.  Quotation from
> :
>
> --8<---cut here---start->8---
> In lieu of a licence
>
> Fonts and documents in this site are not pieces of property or 
> merchandise items; they carry no trademark, copyright, license or 
> other market tags; they are offered free for any use.
> --8<---cut here---end--->8---

Couldn't this be used as a statement that they're abandoning their
copyright [0]? It's been saved away on the Wayback Machine [1] for
future documentation, just in case.

[0]
http://en.wikipedia.org/wiki/Abandonment_%28legal%29#Abandonment_of_copyright
[1]
https://web.archive.org/web/20150113144655/http://users.teilar.gr/~g1951d/


signature.asc
Description: PGP signature

Re: Gluglug X60 Guix howto

[Jason Self]

Alex Sassmannshausen  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 other owners.
>
> You can read my experience at http://glean.eu/guix-gluglug.html.
>
> HTH,
>
> Alex

This it great - Thanks! Can you please make it available under an
appropriate Free license [0]?

[0] http://freedomdefined.org/Licenses#Comparison_of_Licenses


signature.asc
Description: PGP signature

[PATCH] gnu: eudev: Update to 1.10.

[Jason Self]

0001-gnu-eudev-Update-to-1.10.patch
Description: Binary data


signature.asc
Description: PGP signature

Re: Join the Guix hackathon, Sep. 27-28

[Jason Self]

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 also lots of audio things for VoIP.
Mumble [0] is one such thing. It's free, works very well, and uses the
unencumbered Opus audio codec - the successor to Vorbis. :)

[0] http://mumble.info

Re: [PATCH] Kernel Configuration

[Jason Self]

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

I don't use it myself, but think EC2. My understanding is that
ramdisk-less boot is a popular thing because it speeds up booting and
makes maintenance easier. Ideally it'd be easy to set up Guix anywhere.


signature.asc
Description: PGP signature

[PATCH] Kernel Configuration

[Jason Self]

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 should be built in, not a module. Doing
it as a module can cause difficulties when running in a VM in some
cases and the normal config already has it as a built-in.


0001-gnu-linux-libre-Configuration-options-should-be-spec.patch
Description: Binary data


signature.asc
Description: PGP signature

Re: installing a modified package

[Jason Self]

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 useful it might also be a good idea to share them so that
they can be included.


signature.asc
Description: PGP signature

Long-term Release Kernels

[Jason Self]

I was wondering what people though about whether or not there should
also be a long-term release kernel package (see the longterm section
at [0]) in addition to the current one which always tracks the latest
version? 

The short-term support versions provides all of the latest changes and
features but is only supported for about 2-3 months after release so
you're upgrading to new a new stable series more often.

In contrast, the long-term versions are suported for at least 2 years
(sometimes longer like the 3.2 and 3.4 series which will be supported
for 4 and the 2.6 series which is supported for 6) but won't
necessarily have the latest stuff. I could see that some might want a
kernel that isn't changing as much.

Thoughts? If it's a good idea, which version to select and how should
it work (i.e., if it's 3.14 there will probably be a newer long-term
kernel prior to the Aug 2016 date that it's dropped.)

[0] https://www.kernel.org/category/releases.html


signature.asc
Description: PGP signature

Upstream Release Monitoring

[Jason Self]

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 detected.

Re: Guix package wishlist on libreplanet.org

[Jason Self]

Andreas Enge said:
> Do I need an account on libreplanet, or does one of my existing gnu or
> savannah accounts work? I was under the impression I needed a
separate one
> and not motivated to create it...
> 
> Andreas

My understanding is that the LibrePlanet wiki uses single sign on so
if you have an account in the fsf.org domain that should work. Sadly,
Savannah isn't included in single sign on. Perhaps that can be fixed
some day...

Re: GNU Guixguix source archive branch, master, updated. v0.7-198-ge46db77

[Jason Self]

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. He had not. So I
reverted it to avoid breakage until it was out, since it was going to
404 for a while.

Re: Problem No space left on device

[Jason Self]

Authorized binary substitutes from Hydra might help. Otherwise, more
space?


signature.asc
Description: PGP signature

Re: [PATCH] profiles: Report about upgrades.

[Jason Self]

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. :)

New x86 machine

[Jason Self]

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

Re: Package test service for GNU maintainers

[Jason Self]

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 process. A separate process could also work but I do like the
idea of making it easy for maintainers to use (i.e., reducing steps,
minimizing workflow changes, etc.)


signature.asc
Description: PGP signature

Re: Package test service for GNU maintainers

[Jason Self]

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 coordinating with the FSF sysadmin.

Perhaps, in time, the things you describe could be even done by
default when new things are uploaded, since (I think) maintainers get
emails about stuff they upload anyway it seems like a good time to
include the output of the stuff you described?


signature.asc
Description: PGP signature

[PATCH] gnu: linux-libre: Update to 3.15.7.

[Jason Self]

* gnu/packages/linux.scm (linux-libre): Update to version 3.15.7.

Changelog: https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.15.7


0001-gnu-linux-libre-Update-to-3.15.7.patch
Description: Binary data


signature.asc
Description: PGP signature

[PATCH] Correcting FFmpeg build error

[Jason Self]

From 8077c5b884c296b59607176193dbc939908a4fe0 Mon Sep 17 00:00:00 2001
From: Jason Self 
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 
---
 gnu/packages/video.scm |1 -
 1 file changed, 1 deletion(-)

diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm
index 075113c..8850543 100644
--- a/gnu/packages/video.scm
+++ b/gnu/packages/video.scm
@@ -193,7 +193,6 @@
   "--disable-armv6t2"
   "--disable-vfp"
   "--disable-neon"
-  "--disable-vis"
   "--disable-mips32r2"
   "--disable-mipsdspr1"
   "--disable-mipsdspr2"
-- 
1.7.9.5



signature.asc
Description: PGP signature

gnu: wpa-supplicant: Update to 2.2.

[Jason Self]

* gnu/packages/admin.scm (wpa-supplicant): Update to version 2.2.
From a2f2de4db39269543e3fd2f0dca397b9dbb34e67 Mon Sep 17 00:00:00 2001
From: Jason Self 
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-supplicant): Update to version 2.2.

Signed-off-by: Jason Self 
---
 gnu/packages/admin.scm |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index f542f0c..f6232ab 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -668,7 +668,7 @@ commands and their arguments.")
 (define-public wpa-supplicant
   (package
 (name "wpa-supplicant")
-(version "2.1")
+(version "2.2")
 (source (origin
   (method url-fetch)
   (uri (string-append
@@ -677,7 +677,7 @@ commands and their arguments.")
 ".tar.gz"))
   (sha256
(base32
-"0xxjw7lslvql1ykfbwmbhdrnjsjljf59fbwf837418s97dz2wqwi"
+"1vf8jc4yyksbxf86narvsli3vxfbm8nbnim2mdp66nd6d3yvin70"
 (build-system gnu-build-system)
 (arguments
  '(#:phases (alist-replace
-- 
1.7.9.5



signature.asc
Description: PGP signature

gnu: sudo: Update to 1.8.10p3

[Jason Self]

* gnu/packages/admin.scm (sudo): Update to version 1.8.10p3.
From acd861da2c83d9ef760eef917b1665bf40e4f647 Mon Sep 17 00:00:00 2001
From: Jason Self 
Date: Sun, 20 Jul 2014 07:09:44 -0700
Subject: [PATCH 1/1] gnu: sudo: Update to 1.8.10p3.

* gnu/packages/admin.scm (sudo): Update to version 1.8.10p3.

Signed-off-by: Jason Self 
---
 gnu/packages/admin.scm |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 6a59685..f542f0c 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -617,7 +617,7 @@ system administrator.")
 (define-public sudo
   (package
 (name "sudo")
-(version "1.8.10p2")
+(version "1.8.10p3")
 (source (origin
   (method url-fetch)
   (uri
@@ -627,7 +627,7 @@ system administrator.")
 version ".tar.gz")))
   (sha256
(base32
-"1wbrygz584abmywklq0b4xhqn3s1bjk3rrladslr5nycdpdvhv5s"
+"002l6h27pnhb77b65frhazbhknsxvrsnkpi43j7i0qw1lrgi7nkf"
 (build-system gnu-build-system)
 (arguments
  '(#:configure-flags '("--with-logpath=/var/log/sudo.log")
-- 
1.7.9.5



signature.asc
Description: PGP signature

gnu: htop: Update to 1.0.3.

[Jason Self]

* gnu/packages/admin.scm (htop): Update to version 1.0.3.
From a15e2d287f205b088b9141cb1e80ee0592d1a274 Mon Sep 17 00:00:00 2001
From: Jason Self 
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 to version 1.0.3.

Signed-off-by: Jason Self 
---
 gnu/packages/admin.scm |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index ed15644..6a59685 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -101,14 +101,14 @@ graphs and can export its output to different formats.")
 (define-public htop
   (package
(name "htop")
-   (version "1.0.2")
+   (version "1.0.3")
(source (origin
 (method url-fetch)
-(uri (string-append "mirror://sourceforge/htop/"
+(uri (string-append "http://hisham.hm/htop/";
   version "/htop-" version ".tar.gz"))
 (sha256
  (base32
-  "18fqrhvnm7h4c3939av8lpiwrwxbyw6hcly0jvq0vkjf0ixnaq7f"
+  "0a8qbpsifzjwc4f45xfwm48jhm59g6q5hlib4bf7z13mgy95fp05"
(build-system gnu-build-system)
(inputs
 `(("ncurses" ,ncurses)))
-- 
1.7.9.5



signature.asc
Description: PGP signature

gnu: dfc: Update to 3.0.4.

[Jason Self]

* gnu/packages/admin.scm (dfc): Update to version 3.0.4.
From e6aed17bdcf8a0643802e440efec860ed644d12d Mon Sep 17 00:00:00 2001
From: Jason Self 
Date: Sat, 19 Jul 2014 13:33:14 -0700
Subject: [PATCH 1/1] gnu: dfc: Update to 3.0.4.

* gnu/packages/admin.scm (dfc): Update to version 3.0.4.

Signed-off-by: Jason Self 
---
 gnu/packages/admin.scm |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index 8b7a2c0..ed15644 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -78,16 +78,16 @@ interface and is based on GNU Guile.")
 (define-public dfc
   (package
(name "dfc")
-   (version "3.0.3")
+   (version "3.0.4")
(source
 (origin
  (method url-fetch)
   (uri (string-append
-"http://projects.gw-computing.net/attachments/download/78/dfc-";
+"http://projects.gw-computing.net/attachments/download/79/dfc-";
 version ".tar.gz"))
   (sha256
(base32
-"1b4hfqv23l87cb37fxwzfk2sgspkyxpr3ig2hsd23hr6mm982j7z"
+"0zk1ppx93ijimf4sbgqilxxikpsa2gmpbynknyh41xy7jbdjxp0b"
(build-system cmake-build-system)
(arguments '(#:tests? #f)) ; There are no tests.
(native-inputs `(("gettext" ,gnu-gettext)))
-- 
1.7.9.5



signature.asc
Description: PGP signature

gnu: acl: Update to 2.2.52.

[Jason Self]

* gnu/packages/acl.scm (acl): Update to version 2.2.52.
From 2f4f94c660c58b3c46c1ce485c22017eebe255ad Mon Sep 17 00:00:00 2001
From: Jason Self 
Date: Sat, 19 Jul 2014 13:24:47 -0700
Subject: [PATCH 1/1] gnu: acl: Update to 2.2.52.

* gnu/packages/acl.scm (acl): Update to version 2.2.52.

Signed-off-by: Jason Self 
---
 gnu/packages/acl.scm |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/acl.scm b/gnu/packages/acl.scm
index 37c0b71..ef15022 100644
--- a/gnu/packages/acl.scm
+++ b/gnu/packages/acl.scm
@@ -28,7 +28,7 @@
 (define-public acl
   (package
 (name "acl")
-(version "2.2.51")
+(version "2.2.52")
 (source
  (origin
   (method url-fetch)
@@ -36,7 +36,7 @@
   version ".src.tar.gz"))
   (sha256
(base32
-"09aj30m49ivycl3irram8c3givc0crivjm3ymw0nhfaxrwhlb186"
+"08qd9s3wfhv0ajswsylnfwr5h0d7j9d4rgip855nrh400nxp940p"
 (build-system gnu-build-system)
 (arguments
  `(#:phases
-- 
1.7.9.5



signature.asc
Description: PGP signature

Re: [PATCH] linux-initrd: Add AHCI modules.

[Jason Self]

I would prefer to not maintain different kernel configurations (for
Guix and non-Guix.)

If the initial ramdisk doesn't have enough stuff present to be able to
boot successfully, this seems to provide a good example of entire
directories of stuff to include:

http://www.linuxfromscratch.org/blfs/view/cvs/postlfs/initramfs.html

Even if it might make it bigger than manually tuning it this is
probably easier than figuring out which specific things need copying
and makes it bootable on a wide variety of computers with many
different setups. (And plus I hope for full disk encryption with LVM
some day.)  :)


signature.asc
Description: PGP signature

gnu: linux-libre: Update to 3.15.6

[Jason Self]

* gnu/packages/linux.scm (linux-libre): Update to version 3.15.6.

Changelog, for those so interested:
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.15.6


0001-gnu-linux-libre-Update-to-3.15.6.patch
Description: Binary data


signature.asc
Description: PGP signature

Re: Troubles with install image

[Jason Self]

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 is completed you'll see a new menu item at the
bottom that wasn't there before, representing the grub.cfg from the
HDD. Select it and press return.

I have to boot my machine this way all the time. I've been too lazy to
replace the grug.cfg in the flash chip with the proper one I need. The
exact process is documented on libreboot.org if you care to do that.


signature.asc
Description: PGP signature

[PATCH] gnu: ffmpeg: Update to 2.3

[Jason Self]

* gnu/packages/video.scm (ffmpeg): Update to version 2.3.


0001-gnu-ffmpeg-Update-to-2.3.patch
Description: Binary data


signature.asc
Description: PGP signature

[PATCH] gnu: libogg: Update to 1.3.2.

[Jason Self]

* gnu/packages/xiph.scm (libogg): Update to version 1.3.2.


0001-gnu-libogg-Update-to-1.3.2.patch
Description: Binary data

[PATCH] Update libvorbis to 1.3.4

[Jason Self]

This patch updates libvorbis to 1.3.4.


0001-gnu-packages-xiph.scm-libvorbis-Update-to-version-1..patch
Description: Binary data


signature.asc
Description: PGP signature

[PATCH] Update FLAC to 1.3.0

[Jason Self]

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 
Date: Mon, 14 Jul 2014 20:22:28 -0700
Subject: [PATCH 1/1] * gnu/packages/xiph.scm (flac): Update to version 1.3.0


Signed-off-by: Jason Self 
---
 .../patches/flac-fix-memcmp-not-declared.patch |   13 -
 gnu/packages/xiph.scm  |6 ++
 2 files changed, 2 insertions(+), 17 deletions(-)
 delete mode 100644 gnu/packages/patches/flac-fix-memcmp-not-declared.patch

diff --git a/gnu/packages/patches/flac-fix-memcmp-not-declared.patch b/gnu/packages/patches/flac-fix-memcmp-not-declared.patch
deleted file mode 100644
index 9dd5c81..000
--- a/gnu/packages/patches/flac-fix-memcmp-not-declared.patch
+++ /dev/null
@@ -1,13 +0,0 @@
-See http://sourceforge.net/p/flac/bugs/364/
-
-diff -Naur flac-1.2.1-orig/examples/cpp/encode/file/main.cpp flac-1.2.1-ae/examples/cpp/encode/file/main.cpp
 flac-1.2.1-orig/examples/cpp/encode/file/main.cpp	2012-12-27 20:15:11.0 +0100
-+++ flac-1.2.1-ae/examples/cpp/encode/file/main.cpp	2012-12-27 20:25:01.0 +0100
-@@ -30,6 +30,7 @@
- 
- #include 
- #include 
-+#include 
- #include "FLAC++/metadata.h"
- #include "FLAC++/encoder.h"
- 
diff --git a/gnu/packages/xiph.scm b/gnu/packages/xiph.scm
index 03cf0e4..fad8329 100644
--- a/gnu/packages/xiph.scm
+++ b/gnu/packages/xiph.scm
@@ -192,16 +192,14 @@ OpenBSD's sndio.")
 (define flac
   (package
(name "flac")
-   (version "1.2.1")
+   (version "1.3.0")
(source (origin
 (method url-fetch)
 (uri (string-append "http://downloads.xiph.org/releases/flac/flac-";
 version ".tar.gz"))
 (sha256
  (base32
-  "1pry5lgzfg57pga1zbazzdd55fkgk3v5qy4axvrbny5lrr5s8dcn"))
-(patches
- (list (search-patch "flac-fix-memcmp-not-declared.patch")
+  "1p0hh190kqvpkbk1bbajd81jfbmkyl4fn2i7pggk2zppq6m68bgs"
(build-system gnu-build-system)
(arguments
 `(#:parallel-tests? #f
-- 
1.7.9.5



signature.asc
Description: PGP signature

Updating To Linux-libre 3.15.5

[Jason Self]

There have been a number of fixes to 3.15 since it was released on
June 8 as described in:
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.15.1
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.15.2
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.15.3
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.15.4
https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.15.5

The attached patch updates the Linux-libre to 3.15.5 so as to
incorporate these changes.
commit 97bebf310bf3d4bc35b767a959b700f90789c93b
Author: Jason Self 
Date:   Sun Jul 13 12:07:36 2014 -0700

Updating Linux-libre to version 3.15.5

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 3b08771..9e4f2b6 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -186,7 +186,7 @@ for SYSTEM, or #f if there is no configuration for SYSTEM."
  #f)))
 
 (define-public linux-libre
-  (let* ((version "3.15")
+  (let* ((version "3.15.5")
  (build-phase
   '(lambda* (#:key system inputs #:allow-other-keys #:rest args)
  ;; Apply the neat patch.
@@ -259,7 +259,7 @@ for SYSTEM, or #f if there is no configuration for SYSTEM."
  (uri (linux-libre-urls version))
  (sha256
   (base32
-   "125n04rwqmr3bm9slk62w6xcg355hx85rwv2x16nl6qki70hsick"
+   "0kh7yz6jl0jj6z24vh5qzzdn4s3ll4i4rnk4d0l0animnm3s305v"
 (build-system gnu-build-system)
 (native-inputs `(("perl" ,perl)
  ("bc" ,bc)


signature.asc
Description: PGP signature

Updating Kernel Configs

[Jason Self]

Attached is a patch to change the kernel configurations. Two things
are done:

I turned off CONFIG_DEBUG_INFO so that local builds aren't so
enormous. It also turns off the nvidiafb module based on bug report
I've received for my own kernel repository. Nouveau has its own
framebuffer device and it looks like they conflict if you load both.
From 4e48e787e2383ecc5606eede7bd45a2376cc7bf8 Mon Sep 17 00:00:00 2001
From: Jason Self 
Date: Sun, 13 Jul 2014 09:31:55 -0700
Subject: [PATCH 1/1] Disabling CONFIG_DEBUG_INFO so that local builds aren't
 so enormous. Also turning off nvidiafb module based on
 a bug report I received. Nouveau has its own
 framebuffer device and it looks like they conflict if
 you load both

---
 gnu/packages/linux-libre-i686.conf   |7 ++-
 gnu/packages/linux-libre-x86_64.conf |7 ++-
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/gnu/packages/linux-libre-i686.conf b/gnu/packages/linux-libre-i686.conf
index dbef97b..edef148 100644
--- a/gnu/packages/linux-libre-i686.conf
+++ b/gnu/packages/linux-libre-i686.conf
@@ -5024,10 +5024,7 @@ CONFIG_FB_N411=m
 CONFIG_FB_HGA=m
 CONFIG_FB_OPENCORES=m
 CONFIG_FB_S1D13XXX=m
-CONFIG_FB_NVIDIA=m
-CONFIG_FB_NVIDIA_I2C=y
-# CONFIG_FB_NVIDIA_DEBUG is not set
-CONFIG_FB_NVIDIA_BACKLIGHT=y
+# CONFIG_FB_NVIDIA is not set
 CONFIG_FB_RIVA=m
 CONFIG_FB_RIVA_I2C=y
 # CONFIG_FB_RIVA_DEBUG is not set
@@ -7298,7 +7295,7 @@ CONFIG_DYNAMIC_DEBUG=y
 #
 # Compile-time checks and compiler options
 #
-CONFIG_DEBUG_INFO=y
+# CONFIG_DEBUG_INFO is not set
 # CONFIG_DEBUG_INFO_REDUCED is not set
 # CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
diff --git a/gnu/packages/linux-libre-x86_64.conf b/gnu/packages/linux-libre-x86_64.conf
index 877570d..9868074 100644
--- a/gnu/packages/linux-libre-x86_64.conf
+++ b/gnu/packages/linux-libre-x86_64.conf
@@ -4861,10 +4861,7 @@ CONFIG_FB_N411=m
 CONFIG_FB_HGA=m
 CONFIG_FB_OPENCORES=m
 CONFIG_FB_S1D13XXX=m
-CONFIG_FB_NVIDIA=m
-CONFIG_FB_NVIDIA_I2C=y
-# CONFIG_FB_NVIDIA_DEBUG is not set
-CONFIG_FB_NVIDIA_BACKLIGHT=y
+# CONFIG_FB_NVIDIA is not set
 CONFIG_FB_RIVA=m
 CONFIG_FB_RIVA_I2C=y
 # CONFIG_FB_RIVA_DEBUG is not set
@@ -7075,7 +7072,7 @@ CONFIG_DYNAMIC_DEBUG=y
 #
 # Compile-time checks and compiler options
 #
-CONFIG_DEBUG_INFO=y
+# CONFIG_DEBUG_INFO is not set
 # CONFIG_DEBUG_INFO_REDUCED is not set
 # CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
-- 
1.7.9.5



signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add ffmpeg.

[Jason Self]

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.

Re: [PATCH] gnu: Add IceCat.

[Jason Self]

Ludovic Courtès said:
> It succeeded on i686 but failed on x86_64 for unclear reasons
> (the log doesn't show any error, but dmesg shows a couple of
> OOMs...), so I’ve just restarted it.

Lots of memory is probably needed. I haven't tried to compile
IceCat but I recall the Mozilla instructions for Firefox saying
that 4GB was required and that less may give memory errors during
compile. I'm not sure how much RAM Hydra has.

Re: Online hackathon ?

[Jason Self]

There will also be a hackathon going on at the GNU Project's 30th
anniversary [0] in Boston if anyone's interested in meeting in person
there. It could probably be coordinated with an online hackathon too.
Based on Libby's message [1] it might be possible to coordinate
something for Guix too.

Just a thought...

[0] https://gnu.org/gnu30/
[1]
https://lists.nongnu.org/archive/html/gnu-linux-libre/2013-08/msg00014.html