Re: Linux-libre source code will be taken offline
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
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
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
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
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
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
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
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
> 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
[PATCH] gnu: linux-libre-headers: Update to 3.18.11
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: [PATCH] gnu: linux-libre-headers: Update to 3.18.11
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
/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
Re: 01/01: gnu: vlc: Update to 2.2.0
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: Gluglug X60 Guix howto
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 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
Re: Join the Guix hackathon, Sep. 27-28
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
[PATCH] Kernel Configuration
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: [PATCH] Kernel Configuration
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
Re: installing a modified package
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
Upstream Release Monitoring
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: GNU Guixguix source archive branch, master, updated. v0.7-198-ge46db77
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
Authorized binary substitutes from Hydra might help. Otherwise, more space? signature.asc Description: PGP signature
Re: [PATCH] profiles: Report about upgrades.
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
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
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
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
gnu: wpa-supplicant: Update to 2.2.
* 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-supplicant): Update to version 2.2. Signed-off-by: Jason Self j...@jxself.org --- 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
[PATCH] Correcting FFmpeg build error
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/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: htop: Update to 1.0.3.
* 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 to version 1.0.3. Signed-off-by: Jason Self j...@jxself.org --- 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
Re: Troubles with install image
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: libogg: Update to 1.3.2.
* 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 FLAC to 1.3.0
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: 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 j...@jxself.org --- .../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 stdio.h - #include stdlib.h -+#include string.h - #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
Re: [PATCH] gnu: Add ffmpeg.
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.
