Re: make packagers life easier
On 03/15/2015 06:00 PM, Tomáš Čech wrote: How to implement? - inject always failing phase into phases list Another level of this feature could be even continuing of the build. I have a similar feature request. Long time ago when I was packaging gnunet and curl, I had to spend a lot of time trying to understand why `make check` phase fails in the build environment. More often than not, I had to extensively study the test cases and the testing mechanism being used to understand and then resolve the failures, much to my chagrin, by trail-and-error as I did not have access to the build environment. Sure, `guix build -K` helped to some extent but there were some hard-to-debug cases which only failed in the build environment due to separate network and filesystem namespaces. I discussed this with Christian and his suggestion was to implement a debug shell which the guix builder will bail out to when a phase fails. The packager can then examine the environment right at the moment where the failure happens. I know that since the build happens in a separate namespace this can be hard to implement, but one idea is to configure the build environments network namespace to accept connections from localhost and spawn sshd when the build fails. WDYT? Regards, Sree
Re: [GNUnet-developers] GNU in GSOC 2015 - Application sent
Hi! I'd like this also to be mentioned briefly under the GNUnet project so that anyone interested in GNUnet can find it. Please add the following under GNUnet ideas: h4Supporting GNU Guix's package distribution/h4 p Please refer to the description for this project listed under a href=#guixGNU Guix project ideas/a. /p Thanks, Sree On 03/09/2015 11:11 PM, Ludovic Courtès wrote: h4Supporting binary package distribution through GNUnet/h4 p GNU Guix provides a transparent binary/source deployment model. A server can claim: “hey, I have the binary for tt/gnu/store/v9zic07iar8w90zcy398r745w78a7lqs-emacs-24.4/tt!”, where the base32 string uniquely identifies a build process. If you trust that server to provide genuine binaries, then you can grab them instead of building Emacs locally. This mechanism is called a href=/software/guix/manual/html_node/Substitutes.htmlemphsubstitution/emph/a. /p p The “traditional model” has been to have a build farm build and serve binary packages over HTTP. In that model, users trust the build farm to provide authentic binaries. /p p The project aims to provide a emphpractical/emph decentralization distribution mechanism for binary packages, using a href=/software/gnunetGNUnet’s networking layers/a. In that model, users would be able to automatically share binaries they have built locally, and to install binaries built by other users. This is part of a broader goal of emphdisintermediation/emph among users, and between users and upstream software developers. /p p Deliverables a href=http://lists.gnu.org/archive/html/guix-devel/2015-03/msg00192.html;include/a a substituter that uses GNUnet as its back-end, and a tool to publish build results. /p strongMentors/strong: a href=mailto:totak...@in.tum.de;Sree Harsha Totakura/a, a href=mailto:bart.po...@gmail.com;Bart Polot/a Thanks, Ludo'.
Re: [GNUnet-developers] Guix + GNUnet at GSoC?
On 03/05/2015 11:33 PM, Ludovic Courtès wrote: Who would like to (co-)mentor it? Hi! I and Bart would like to co-mentor this project. Should I write to summer-of-c...@gnu.org for including this project in the list of ideas? Regards, Sree
Re: Server unrresponsive
On 01/21/2015 04:04 PM, Ludovic Courtès wrote: This message suggests that hydra.gnu.org, the server that provides pre-compiled binaries, is somewhat slow. This is unfortunately too frequent and we hope to switch to a more powerful front-end server. I believe switching to hydra.gnunet.org may be helpful. Have you considered it? Sree
Re: Gnunet update
On 08/12/2014 08:25 PM, Ludovic Courtès wrote: the attached patch attempts to update gnunet to its current release 0.10.1. It fails one of its tests; Sree, could you maybe look into it? It would be nice to be up-to-date before coming to the GHM in gnunet's birth place! Indeed. :-) Likewise, I hope we can take the GHM as an opportunity to hack up a GNUnet service and properly integrate the NSS plug-in for GNS. I am a bit busy hacking for a demo which will present during the GHM. I shall try to find time to investigate the failing test, but I cannot promise anything as of now :-) Sree
Re: Troubles with install image
On 07/15/2014 05:34 PM, Thompson, David wrote: Are you referring to offloading builds or using a replacement to hydra.gnu.org for serving substitutes? I was talking about an addition (local cache) to hydra.gnu.org. Sree
Re: [PATCH] gnu: Add perl-tk, perl-x11-protocol, and clusterssh
On 04/04/2014 05:15 PM, Eric Bavier wrote: * gnu/packages/admin.scm (clusterssh): New variable I am actually in need of something like this. I am using parallel-ssh, but this looks very promising. Thank you! +(description + ClusterSSH controls a number of xterm windows via a single graphical +console window to allow commands to be interactively run on multiple servers +over an ssh connection.) Is there a typo here? s/an ssh connection/ssh connections ? It seems to interact with multiple servers by having a connection to each one of them. Sree
Re: Guix, Hydra Nix
Hi Ludo,
Thank you very much. Please ACK my understanding.
On 03/28/2014 10:26 PM, Ludovic Courtès wrote:
Sree Harsha Totakura sreehar...@totakura.in skribis:
From the sources, I found that build-aux/hydra/*.scm convert packages into a
format hydra understands for building them.
Yes. Specifically, build-aux/hydra/*.scm return a list of “jobs”, where
each job is represented as an alist with a number of compulsory items,
such as ‘derivation’ (see ‘package-alist’.)
OK, so the list of jobs is what is termed as a jobset in Hydra. Jobset is a
collection of jobs + configuration for when to rebuild the jobset and where to
get the jobset's inputs (sources).
The file build-aux/hydra/gnu-system.scm prepares the jobset which contains all
packages currently in Guix. This jobset is configured in hydra.gnu.org to
initiate a build whenever there is a new commit in Guix source repository.
The file build-aux/hydra/guix.scm is a jobset to build Guix iteself.
The result of those scripts is then consumed by Hydra’s
hydra-eval-guile-jobs:
https://github.com/NixOS/hydra/blob/master/src/script/hydra-eval-guile-jobs.in
hydra-eval-guile-jobs is itself called by hydra-evaluator, from here:
https://github.com/NixOS/hydra/blob/master/src/lib/Hydra/Helper/AddBuilds.pm
Aye, this is where the magic happens. So it looks at the file extension of the
jobset's recipe and if it is .scm, then it uses Guix.
Hydra refuses to install without nix-store. So Nix has to be installed as
well.
I'm guessing Hydra uses nix-store command to build and retrieve store paths
for
packages given to it. Is it true?
Yes. ‘nix-store’ is essentially a client of {guix,nix}-daemon, just
like ‘guix build’. Hydra passes ‘nix-store’ a .drv file name, a
low-level representation of the build process; ‘nix-store’ doesn’t have
to care whether it was produced by Guix or Nix, and can’t tell the
difference. (Similarly, ‘guix build’ can be passed a .drv produced by
Nix.)
If so, how can hydra nix-store compile Guix packages?
Just like this. :-)
Ah, so the derivations, when sent to {guix,nix}-daemon are expressed in the same
format? `guix build' converts our guile code into this format.
So, when Hydra sees a .scm file as input, it asks Guix to convert the jobset
into derivations which are then sent to the {guix,nix}-daemon via 'nix-store'.
Does this mean that {guix,nix}-daemon are interchangeable? Can Hydra run with
the setup: guix clients, nix clients, guix-daemon, Hydra? Or does it need a
nix-daemon?
Sree
Re: [PATCH] Add (guix svn-download).
On 03/27/2014 10:30 AM, Ludovic Courtès wrote: I realize you’re not in the ‘guix’ group on Savannah. I can add you, but I need to know what your Savannah account is (or you need to create one if you don’t have one already.) Thanks. :-) Yes, I did not have an account on Savannah. I just created it and sent you guys a request for inclusion. Sree
Add svn-fetch method
The following patch adds a new origin method to fetch from SVN repositories. Note that the subversion command is used with --trust-server-cert option which causes it to trust any given SSL certificate if fetching from HTTPS repositories. The authenticity of the code should only be verified by the given hash. Sree
[PATCH] Add (guix svn-download).
* guix/svn-download.scm, guix/build/svn.scm: New files. * Makefile.am (MODULES): Add them. --- Makefile.am |2 ++ guix/build/svn.scm| 48 ++ guix/svn-download.scm | 89 + 3 files changed, 139 insertions(+) create mode 100644 guix/build/svn.scm create mode 100644 guix/svn-download.scm diff --git a/Makefile.am b/Makefile.am index 764332a..0eb9a83 100644 --- a/Makefile.am +++ b/Makefile.am @@ -52,6 +52,7 @@ MODULES = \ guix/http-client.scm \ guix/gnupg.scm \ guix/store.scm \ + guix/svn-download.scm\ guix/ui.scm \ guix/build/download.scm \ guix/build/cmake-build-system.scm\ @@ -66,6 +67,7 @@ MODULES = \ guix/build/union.scm \ guix/build/pull.scm \ guix/build/rpath.scm \ + guix/build/svn.scm \ guix/packages.scm\ guix/snix.scm\ guix/scripts/download.scm\ diff --git a/guix/build/svn.scm b/guix/build/svn.scm new file mode 100644 index 000..e3a8693 --- /dev/null +++ b/guix/build/svn.scm @@ -0,0 +1,48 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2014 Ludovic Courtès l...@gnu.org +;;; Copyright © 2014 Sree Harsha Totakura sreehar...@totakura.in +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +(define-module (guix build svn) + #:use-module (guix build utils) + #:export (svn-fetch)) + +;;; Commentary: +;;; +;;; This is the build-side support code of (guix svn-download). It allows a +;;; Subversion repository to be cloned and checked out at a specific revision. +;;; +;;; Code: + +(define* (svn-fetch url revision directory +#:key (svn-command svn)) + Fetch REVISION from URL into DIRECTORY. REVISION must be a valid svn +revision. Return #t on success, #f otherwise. + (and (zero? (system* svn-command checkout --non-interactive + ;; Trust the server certificate. This is OK as we + ;; verify the checksum later. This can be removed when + ;; ca-certificates package is added. + --trust-server-cert -r revision url directory)) + (with-directory-excursion directory + (begin + ;; The contents of '.svn' vary as a function of the current status + ;; of the repo. Since we want a fixed output, this directory needs + ;; to be taken out. + (delete-file-recursively .svn) + #t + +;;; svn.scm ends here diff --git a/guix/svn-download.scm b/guix/svn-download.scm new file mode 100644 index 000..1d94430 --- /dev/null +++ b/guix/svn-download.scm @@ -0,0 +1,89 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2014 Ludovic Courtès l...@gnu.org +;;; Copyright © 2014 Sree Harsha Totakura sreehar...@totakura.in +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +(define-module (guix svn-download) + #:use-module (guix records) + #:use-module (guix derivations) + #:use-module (guix packages) + #:use-module (ice-9 match) + #:export (svn-reference +svn-reference? +svn-reference-url +svn-reference-revision +svn-fetch)) + +;;; Commentary: +;;; +;;; An origin method that fetches a specific revision from
[PATCH] Add (guix svn-download).
* guix/svn-download.scm, guix/build/svn.scm: New files. * Makefile.am (MODULES): Add them. --- Makefile.am |2 ++ guix/build/svn.scm| 49 +++ guix/svn-download.scm | 90 + 3 files changed, 141 insertions(+) create mode 100644 guix/build/svn.scm create mode 100644 guix/svn-download.scm diff --git a/Makefile.am b/Makefile.am index 764332a..0eb9a83 100644 --- a/Makefile.am +++ b/Makefile.am @@ -52,6 +52,7 @@ MODULES = \ guix/http-client.scm \ guix/gnupg.scm \ guix/store.scm \ + guix/svn-download.scm\ guix/ui.scm \ guix/build/download.scm \ guix/build/cmake-build-system.scm\ @@ -66,6 +67,7 @@ MODULES = \ guix/build/union.scm \ guix/build/pull.scm \ guix/build/rpath.scm \ + guix/build/svn.scm \ guix/packages.scm\ guix/snix.scm\ guix/scripts/download.scm\ diff --git a/guix/build/svn.scm b/guix/build/svn.scm new file mode 100644 index 000..aaf6cb8 --- /dev/null +++ b/guix/build/svn.scm @@ -0,0 +1,49 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2014 Ludovic Courtès l...@gnu.org +;;; Copyright © 2014 Sree Harsha Totakura sreehar...@totakura.in +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +(define-module (guix build svn) + #:use-module (guix build utils) + #:export (svn-fetch)) + +;;; Commentary: +;;; +;;; This is the build-side support code of (guix svn-download). It allows a +;;; Subversion repository to be cloned and checked out at a specific revision. +;;; +;;; Code: + +(define* (svn-fetch url revision directory +#:key (svn-command svn)) + Fetch REVISION from URL into DIRECTORY. REVISION must be a valid svn +revision. Return #t on success, #f otherwise. + (and (zero? (system* svn-command checkout --non-interactive + ;; Trust the server certificate. This is OK as we + ;; verify the checksum later. This can be removed when + ;; ca-certificates package is added. + --trust-server-cert -r (number-string revision) + url directory)) + (with-directory-excursion directory + (begin + ;; The contents of '.svn' vary as a function of the current status + ;; of the repo. Since we want a fixed output, this directory needs + ;; to be taken out. + (delete-file-recursively .svn) + #t + +;;; svn.scm ends here diff --git a/guix/svn-download.scm b/guix/svn-download.scm new file mode 100644 index 000..55ad614 --- /dev/null +++ b/guix/svn-download.scm @@ -0,0 +1,90 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2014 Ludovic Courtès l...@gnu.org +;;; Copyright © 2014 Sree Harsha Totakura sreehar...@totakura.in +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +(define-module (guix svn-download) + #:use-module (guix records) + #:use-module (guix derivations) + #:use-module (guix packages) + #:use-module (ice-9 match) + #:export (svn-reference +svn-reference? +svn-reference-url +svn-reference-revision +svn-fetch)) + +;;; Commentary: +;;; +;;; An origin method
SVN download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I wrote a helper to download sources from SVN directories. I guess it works but I am unable to test it as I get the following error while validating the server SSL certificates: @ build-started /gnu/store/7826n7p4928dnrdgjslpjhkkm7mc40jj-svn-checkout.drv - x86_64-linux /usr/local/var/log/guix/drvs/78//26n7p4928dnrdgjslpjhkkm7mc40jj-svn-checkout.drv.bz2 Error validating server certificate for 'https://gnunet.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: ng.gnunet.org - Valid: from Mon, 14 May 2012 12:14:28 GMT until Sun, 01 Jun 2014 04:00:00 GMT - Issuer: Technische Universitaet Muenchen, DE - Fingerprint: b5:75:8b:72:f8:8e:7e:04:b5:a7:bb:37:4a:b5:91:a6:3c:bb:19:51 (R)eject, accept (t)emporarily or accept (p)ermanently? svn: E175002: Unable to connect to a repository at URL 'https://gnunet.org/svn/gnunet' svn: E175002: OPTIONS of 'https://gnunet.org/svn/gnunet': Server certificate verification failed: issuer is not trusted (https://gnunet.org) builder for `/gnu/store/7826n7p4928dnrdgjslpjhkkm7mc40jj-svn-checkout.drv' failed with exit code 1 @ build-failed /gnu/store/7826n7p4928dnrdgjslpjhkkm7mc40jj-svn-checkout.drv - 1 builder for `/gnu/store/7826n7p4928dnrdgjslpjhkkm7mc40jj-svn-checkout.drv' failed with exit code 1 cannot build derivation `/gnu/store/dii1141l46gnn347lk11spqaqi15kgl9-svn-checkout.xz.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/wb5p8rf206r6kx5070bszvg4iy49fzcy-gnunet-0.10.1-svn.drv': 1 dependencies couldn't be built guix build: error: build failed: build of `/gnu/store/wb5p8rf206r6kx5070bszvg4iy49fzcy-gnunet-0.10.1-svn.drv' failed The certificate of ng.gnunet.org is signed by Deutsche Telekom Root CA 2. Where should that certificate be included to get past this error? Sree -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTMX7wAAoJECthXLMALpxG104IAItKQU86tbpbKEapQSRce8vx D5+dse5Oi5KCeeVWX93zVwnO/Zh0D7HW293cz+U4HHtpHuvHckMJszPhFAo8JpEv 26vxtJc2o/IW8hPdeKXUOKprGDQ7gOGIlap+I/GX2/JcERGBvlujCnj3ZPMx2p+S v418P589IwB5/s2rHvtmw4lxA1F0O4lxhCY0JWybLeE6RH4fhc24ZYpsd1CVzXM1 FjvzP6JSb6LL47fiaI3V7VgFsaIViMaHvnB0f0fwnjfFNdpP+yODWjWd6pk32dGX kwGIwHOYRQ2uVG5L/Bgm884O1rjHvQQpVw9iF73v2EcAVLtPGSlyRytzSEAaVbA= =2bjW -END PGP SIGNATURE-
Re: SVN download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/25/2014 09:29 PM, Ludovic Courtès wrote: Now, alternately, does GNUnet provide http SVN access (no TLS)? If it does, you could: It doesn't provide http SVN access. So, I guess the only option for now is to use the ca-certificates package. Sree -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTMfoSAAoJECthXLMALpxGDPYH/Am4H0wQimyAuASBdpo6Nuwz UlVz9FcXXlY883uBQeKfWfedU5e5SaaHoL02TkUSIVxdAmtpsGu/h68kL0sjcZhj pfOFSwXQusQnQ7+HYcmbPgkZBBQi5oFrCT21mMjH0U4ZgDT7GCQH8w8bPnnl1Am1 A1UG3ZKwYvZNNhDAFWSYvWJVgZwF8zRKQ34EOSqHJQdQ8PgRonsESc8TmBiSMCr2 UsmTTAtLcIL1ICsIInlHHTrYh+JqMnrTcv0c0ya2ZG3xCSX1Qxl2u9g86HOKTRmT IyhcfCOKhiiGOHXYLEoPyD2ThHHYB1r/kD6OuJ1Zsdbk2y+sgGXHFEKx5Rcy3UQ= =5ho8 -END PGP SIGNATURE-
Re: libffi cannot be installed in user profile in core-updates
On 03/24/2014 07:07 AM, Mark H Weaver wrote: This problem was introduced in d43547f12d4eae19845f3bf13a53a050af965063 gnu: libffi: Leave a copy of headers where libffi.pc expects them. What we need to do here is to symlink the header files instead of the include directory. This was suggested earlier here: http://lists.gnu.org/archive/html/guix-devel/2014-01/msg00213.html Ludo, please revert d43547f12d4eae19845f3bf13a53a050af965063. Sree
Re: GSoC 2014
On 03/19/2014 10:18 AM, Deepan Sekar wrote: Hi Hi! Im sorry for participating and contacting you so late about my interest in the project of Self-updating GNUnet with GNU Guix but I just came across GSoC 2014 two days ago. Anyways, I find the concept proposed really interesting and would like to contribute. I have gone through the documentation manuals of both GNUnet and GNU Guix but I've just started playing with the coding aspects. I apologize beforehand if I make some technical errors and ask you to assist me in correcting and understanding them better. Due to my late start, I realise I have a lot to cover in a few days but I'll list what I've understood and my ideas on how to perform the required task below. Essentially, the task at hand is to decentralize the existing process so that the updates/packages can be downloaded from peers in GNUnet rather than from the a centralized Guix server. In a crux, yes, that's the idea. Idea on how to implement this process: (I'm not sure if this is what is expected, please read it and tell me if this is what is expected else I'll make the recommended changes) 1. The Guix service which is to be implemented will use the hash key (given by the user)and search in GNUnet DHT for a match. 2. Once the match has been found, the authenticity of the peer holding the binary file is confirmed. 3. A Mesh channel is opened with the peer and the request for the file is sent along with the current version installed in the user's system (if there is one). 4. At the peer which receives this request, a comparison of the version sent by the user's request and the version available on the peer machine is done. 5. If the version available with the peer is higher (essentially the update), then the update is downloaded to the user's machine. 6. The host then tests for the authenticity of the package downloaded by verifying the signature. 7. Once the package is authenticated and installed (by Guix), the client(user) publishes in GNUnet DHT that it has the package now so that any other peer can repeat the same process with the current machine also as a possible server. We have discussed a bit on how to proceed with this project earlier. The discussions are available here: https://lists.gnu.org/archive/html/gnunet-developers/2014-03/threads.html As noted in the discussions, please apply with a roadmap of your implementation strategy soon as the deadline is nearing by. You should also join guix-devel and gnunet-developers mailing list and please direct your further questions there. Regards, Sree
Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2014 12:15 AM, Ludovic Courtès wrote: Is it possible to have several values associated with a key in the DHT? I’m asking because here we’d need to have the ability to get zero or more tuples as described above, one tuple for each node that claims to publish /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3. Yes, it is possible to store multiple values under the same key. The results of the lookup for that key will then contain none, some or all of those values. Later, as an optimisation, we can build a custom DHT block plugin for Guix packages. This plugin can then combine several such values of the same key. So, in the end we can achieve a list of tuples from a key lookup instead of getting a single tuple as a response multiple times. Sree -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTIWsMAAoJECthXLMALpxGirQH/11Ye/UscEox3yD4N6ns0dW+ goWJpwop6Q/OHnGbskiGa9CniXO9byzp7u5u6bzfWxQAAai61oRbiY41QLllMduN dU6VzJl4KKnXR8cV6A2CzN0ysLGBMz3pscO2l4M5OyTq238l/oEwlZaD7RXpW/sB Lu87eFxE3gu1oscfR5iGjP7lQCHwm2tSZHyqOLMlsGDUd9ycX0oI7XvfjifSLUbe hBSG8KoF4KlYZggcwUyphkLsR2tnys9zShCPxNON3f5PLfyffINs5w0WD09Em3aB 3dqoI1I9QA0hLHRi3VDJ3E50ucth3J2RyH0A4lbbYEe2QMgIr+Kl0YimEU0qrsM= =c5mk -END PGP SIGNATURE-
Re: Guix - GNUnet binary ditribution roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2014 08:14 PM, Pierre-Antoine Rault wrote: Hi, Sorry for contacting you directly (without the guix mailing list), but Ludovic Courtès recommanded me to contact you as I would like to work [1] on integrating GNUnet in Guix as a binary deployment and sharing system. [1] http://lists.gnu.org/archive/html/guix-devel/2014-03/msg00106.html No problem; I was also following your thread on guix-devel. For now I'm afraid I have to catch up with what has been said and thus made the following requirements/ideas list (all ideas are not from me): * required: users may run a server to share binaries (HTTP or GNUnet server). Let's just stick with the GNUnet server (we call such a server as a service in GNUnet, let's call it Guix service) as of now. HTTP can be done optionally. Moreover the currently binary distribution is made through a HTTP server. * required: users should use a gpg key to sign their packages. OK, sounds good. * required: users would look for hashes on a dht node (GNUnet node) to find user servers. I am assuming the hash lookup will be against the package and the result will contain the peers offering the package. This requires all nodes which are running the Guix service to publish into DHT the packages they built or downloaded from others. * required: users should be able to add/remove keys to their keyring of trusted keys (which would have official keys as a basis). Yes. * optional: users' servers could be dht nodes themselves. This may not be possible. If you are running the Guix server, you would want to publish the packages you built into the DHT and for this you need to run the DHT service. Anyway, why do you want this option at all? * optional: users should be able to share a magnet link [2][3] to one's binaries. [2] http://magnet-uri.sourceforge.net/ [3] http://magnet-uri.sourceforge.net/magnet-draft-overview.txt OK, this is a convenience feature. I am still reading the GNUnet manual at the moment and have tested the GNUnet package on my distribution successfully. Now I am trying to come up with a roadmap to develop the system. Do you have an idea of what such a roadmap should include/begin with ? The requirements from Guix side are missing here. IMO, you have to: * Understand the current protocol used over HTTP to search and download packages from Guix Hydra server. * Implement a equivalent client/downloader in Guix using Guile to download the packages using GNUnet. * Extend the Guix daemon to publish package updates into GNUnet DHT, whenever new packages are added to the Guix store. The roadmap should contain a plan for implementing these requirements, the order in which the implementation happens and estimates of how long each step takes. To begin with, I suggest you should start experimenting with GNUnet's DHT by writing an service which publishes periodically some (key, value) pairs. In parallel, you may also try to understand the Hydra protocol. Regards, Sree PS: I could not find your PGP key on keyservers. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTIK4EAAoJECthXLMALpxG20cH+wX6OyQrOh/AEAGWWDS3NE8P cxOrABCO5STOQl/dtfBeK/tbk1or8h3IM4h2mB/E+v4bHGxiJ7ajoayRzHpiAc5n ET0xzuU2UXkN70ld9nXNHqtCBICm43sAGnl+fchkP6kqbjuejoDt6eZLecGjGLMR F55CuClxg9vqCMTuOaIXQQNLWxWcudLsrp1Qy/As9L7U6fuCZWmqHEgk7vy3CvUD O3lBZcuR0CAcp8ADvVbywh5xTqCwX51epXNxDD83K13cOjlDNDp4+3dyq4vHr1f1 ZVbzk37Ac+yKSVrQa9XkRS/dermR9doktC9ta1EYofnZe6RcS/YeSRw2VCh0XGA= =rM/g -END PGP SIGNATURE-
Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/12/2014 09:56 PM, Ludovic Courtès wrote: Let's just stick with the GNUnet server (we call such a server as a service in GNUnet, let's call it Guix service) as of now. HTTP can be done optionally. Moreover the currently binary distribution is made through a HTTP server. Yeah, let’s keep HTTP optional. The requirement will be to have a server over GNUnet’s MESH, right? Yes, so the service should be using both DHT and MESH services of GNUnet. DHT to publish and lookup packages and MESH for downloading and seeding packages. * required: users should use a gpg key to sign their packages. OK, sounds good. For consistency, I’d prefer to use our SPKI-style infrastructure (info (guix) Invoking guix archive). OK. * optional: users' servers could be dht nodes themselves. This may not be possible. If you are running the Guix server, you would want to publish the packages you built into the DHT and for this you need to run the DHT service. To me “could be DHT nodes” is the same as could “run the DHT service”. I think you’re saying the same thing, no? :-) Yes, if a node is a DHT node that basically implies that it is running the DHT service. The requirements from Guix side are missing here. IMO, you have to: * Understand the current protocol used over HTTP to search and download packages from Guix Hydra server. * Implement a equivalent client/downloader in Guix using Guile to download the packages using GNUnet. * Extend the Guix daemon to publish package updates into GNUnet DHT, whenever new packages are added to the Guix store. I think guix-daemon would remain unchanged. Instead, the package publisher could (say) periodically ask for the list of live store items (as per ‘guix gc --list-live’) and publish those. OK, I agree; this is also simple. Does '--list-live' option list all the items in the store or only the ones currently used? I believe it is helpful for other peers to push all items in the store, but then how do packages age-out? However, I think the protocol could be different from, and simpler than Hydra’s. Ideally, I imagine you could do something like: dht-get /gnu/store/ykmg6ydrmlkn600wklriw3wzc1z3dcli-emacs-24.3 and get as a reply (roughly) a tuple containing: 1. a signature (as a canonical s-expression); 2. a reference to a MESH channel from which to download the archive of that store item; We also need a peer identity in the tuple since establishing MESH connections require both the peer identity and a channel number. MESH is the GNUnet's equivalent of TCP: peer identity ~= IP address; channel number ~= port number. Sree -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTIOVgAAoJECthXLMALpxG49cH/A9uK5z3R7++uFfrp3LTs7UD qTZV63wn7y01l2WfX2Yzvj7gMIHNhwojBkfpALgchHVDCbTXtfdDHo5OYFbmpxhN MqJ6bmrkF2uQ1d1cgWqlByaOERDWEw8RwCjzAwJ0FzEv1P2/5KUXdlQCFwKyd+k+ g5//utsLrEfPzb5KvXEKUCloBCksnt7iBuyhUwy2KH7BaNOc1pmeWUShc5zErH2m rrZJfa+vS7YqvbpqKN4ZorDoDHW8SqOXJOxStrBuV0qzNq4iCWZkDeomybKEQ/UA b3YmtKwLIrMEf3f7/mPmAIy3A5mN2yKy4CP3m2dGVObDzuWWCEQX/WvuZCP4Upk= =Gb1A -END PGP SIGNATURE-
Re: Binary downloads
On 03/07/2014 05:46 PM, Pjotr Prins wrote: Sorry, I was not clear. I do not want to build on my laptop (the noise drives me nuts :). So I want to build on a remote server and install on my laptop, or on compute nodes, or whatever. With Nix it is possible. Does Guix allow caching of packages, so I can share. Of course it does, question is how :). Do I revert to Nix? FWIK, you have to run the same hydra from Nix on the server. Then you'll have to change the hydra.gnu.org server to your server in the Guix code somewhere. Sree
Re: New Hydra build slaves
On 03/03/2014 11:31 PM, Ludovic Courtès wrote: BTW, it would be great if someone would volunteer to help with administration of Hydra and the build machines. So if someone is interested, please let me know. Since I am here at TUM, I can help with volunteering the server here. How can I help? Sree
Re: hydra.gnu.org migrates to /gnu/store!
On 02/28/2014 11:28 PM, Ludovic Courtès wrote: Among other things, it’s migrating from /nix/store to /gnu/store. Is this already present in the master branch? If so, will the store be rebuilt when I update master? Sree
Re: New Hydra build slaves
On 03/04/2014 12:12 PM, Ludovic Courtès wrote: For the machine at TUM, the main issue currently is to get the networking issue that Christian identified sorted out. AFAIK, Christian has written to the network operations dept. here. I will check with them later. I was actually thinking of general Hydra administration. Occasionally machines may have troubles, like transient errors (networking, disk space, random build issues, etc.) requiring manual intervention, or occasional Hydra upgrades. OK, I can do these. There’s also the problem that our current setup is fairly hackish. Having scripts to automate some of the tasks would be an improvement. We can try setting up some kinda monitoring on the buildslaves which can then send emails when problems arise. WDYT? Sree
Re: [PATCH] gnu: Add miniupnpc.
On 02/23/2014 10:43 AM, Andreas Enge wrote: your message headers contain: Content-Type: text/plain; charset=y so that git am complains about fatal: cannot convert from y to UTF-8 Or does the list software mess it up? Ah, I think I answered with a 'y' when git complained that it is going to send the message as UTF-8. I guess I didn't read the message properly; I guess it had asked me that character encoding the patch is in. On Sat, Feb 22, 2014 at 10:37:05AM +0100, Sree Harsha Totakura wrote: + #:phases + (alist-delete + 'configure + %standard-phases))) There is a tiny problem with indentation here. +(license + (x11-style + https://github.com/miniupnp/miniupnp/blob/master/miniupnpc/LICENSE; Can you refer to a file in the tarball and add the obigatory comment? Something like: (license (x11-style file://doc/README See 'doc/README' in the distribution. (copy-pasted from w3m). I fixed these in the following patch. Sree
Re: GNUnet build failure on mips64el
On 02/22/2014 08:44 AM, Mark H Weaver wrote: PASS: test_local_revocation.py Feb 22 07:17:50-660583 testbed-api-topology-16547 WARNING Error while establishing a link: 0x4: Timeout while connecting to CORE of peer with id: 0 -- Retrying Feb 22 07:17:51-098510 testbed-api-topology-16547 WARNING Error while establishing a link: 0x5: Timeout while connecting to CORE of peer with id: 1 -- Retrying Feb 22 07:17:56-127624 testbed-api-topology-16547 WARNING Error while establishing a link: 0x7: Timeout while acquiring HELLO of peer 6ULB -- Retrying Feb 22 07:17:56-134033 testbed-api-topology-16547 WARNING Error while establishing a link: 0x6: Timeout while acquiring HELLO of peer 6DER -- Retrying Feb 22 07:18:01-142761 testbed-api-topology-16547 WARNING Error while establishing a link: 0x9: Timeout while acquiring HELLO of peer 6DER -- Retrying Feb 22 07:18:01-143920 testbed-api-topology-16547 WARNING Error while establishing a link: 0x8: Timeout while acquiring HELLO of peer 6ULB -- Retrying --8---cut here---end---8--- These warnings are likely caused due to the system getting overloaded. The testcase has a test ramp-up part which starts 2 peers and then connects them. This part is failing as peers are unable to connect. After printing the text above, it gets stuck in 'src/revocation/.libs/test_revocation', with the two 'gnunet-service-nse' subprocesses both running continuously and all other gnunet processes sleeping. This is likely to cause the load on the system. 'gnunet-service-nse' tries to find a proof-of-work to participate in the size estimation application of GNUnet. This proof-of-work involves find a value whose hash matches its first n digits; this is required to avoid Sybil attacks and can be computationally expensive and can be taxing on the loongson you have. I am not sure if the NSE service is needed for this testcase. If not it should be easy to fix. In any case, the testcase should not run for more than ~1 minute. I'd like to debug this. Would it be possible to provide me access to this machine? Sree
Re: GNUnet build failure on mips64el
On 02/21/2014 04:31 PM, Ludovic Courtès wrote: On the GNUnet side, it would be great if the tests were less timing sensitive. We faced these problems earlier when we added Sheevaplug and RasberryPi into our buildbots. Unfortunately, since we are having a network application, the timeouts are necessary. We can try increasing the timeouts but that makes the test runs long if a testcase were to fail genuinely. Guess we'll have to come up with some automated measurement for timeouts depending on the host configuration. I just don't know how; any ideas? Sree
Calling functions in `make-flags'
Hi, I am trying to build a package which does not have 'configure' script. It instead relies solely on a makefile. For this to function, I have to set the 'SH' variable inside the Makefile to a valid shell. I am trying to set the 'SH' variable through build-flags like this: (arguments '(#:make-flags '((string-append SH= (which sh))) But this fails with the following error: 203: 1 [build #:make-flags ((string-append SH= (which sh))) ...] In unknown file: ?: 0 [system* make -j 4 (string-append SH= (which sh))] ERROR: In procedure system*: ERROR: Wrong type (expecting string): (string-append SH= (which sh)) How can I get this to work? Regards, Sree
Re: guix package: error: build failed: unable to fork: Invalid argument
On 02/19/2014 12:53 AM, David Knight wrote: Wonderful, setting these solved the problem. Now guix package -i hello works for me! Good. The namespaces are required for Guix to build new packages in a chroot environment which should be independent of the host system and consistent on all hosts for a given package. Sree
Re: [PATCH] gnu: gnutls: Configure location of system-wide trust store
On 02/19/2014 03:08 PM, Andreas Enge wrote: The next question is, where do these certificates come from in our system? I think a reasonable solution would be to: - create a package with certificates (maybe inspired from those contained in debian); - have gnutls depend on it, and use the gnutls configure flag to point to /nix/store/xxx-our-certificates/etc/ssl/... . I think this would be more in line with our approach than pointing to /etc. Also, if a certificate gets compromised and is withdrawn from the certificate package, this would force gnutls and all its dependencies to be recompiled. What do you think? I like this solution. Sree
[PATCH 0/2] Update cURL to 7.35.0 and fix its tests
The following patches update cURL to 7.35.0 and fix its test cases. Sree Harsha Totakura (2): gnu: curl: Update to 7.35.0. gnu: curl: Fix tests. gnu/packages/curl.scm | 20 1 file changed, 16 insertions(+), 4 deletions(-) -- 1.8.5.3
[PATCH 1/2] gnu: curl: Update to 7.35.0.
* gnu/packages/curl.scm (curl): Update to 7.35.0. --- gnu/packages/curl.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/curl.scm b/gnu/packages/curl.scm index a9bfa76..ea7dbf6 100644 --- a/gnu/packages/curl.scm +++ b/gnu/packages/curl.scm @@ -36,14 +36,14 @@ (define-public curl (package (name curl) - (version 7.28.1) + (version 7.35.0) (source (origin (method url-fetch) (uri (string-append http://curl.haxx.se/download/curl-; version .tar.lzma)) (sha256 (base32 - 13bhfs41yf60ys2hrikqxjwfzaj0gm91kqzsgc5fr4grzmpm38nx)) + 14w5cwh6b1426lxkq6kp6h4vxryr4n7wfrrwhny1r4123q7n8ab9)) (patches ;; This patch fixes testcase 172 which uses a hardcoded cookie ;; expiration value which is expired as of Feb 1, 2014. -- 1.8.5.3
Re: guix package: error: build failed: unable to fork: Invalid argument
On 02/18/2014 05:29 PM, David Knight wrote: it downloads about 277M of files (up to guile-2.0.9.tar.xz) into /nix/store then errors with guix package: error: build failed: unable to fork: Invalid argument. Rerunning the command gives the same error message. It is common to install those many files. They come from bootstrap packages and are required. The same error shows on two different distros (LFS and Gentoo on i686), and with both Guix 0.5 and cloned from git. Guix 0.5 'make check' passes all tests, and the git version from today passes all tests except 'topologically-sorted, more difficult' in store.scm. Other guix package commands such a --search= and --list-available seem to work as expected. I am suspecting that this is a problem with you kernel configuration. Do you have the namespaces available (the following options) in your config? CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y -- Sree
Re: [PATCH] gnu: gnurl: Update to 7.35.0.
On 02/16/2014 10:20 PM, Ludovic Courtès wrote: Applied, thanks. I suppose there’s a new cURL version as well? Yes, there is, but its tests are currently failing. I shall look into it and send a patch soon. Sree
[PATCH] Update gnurl to 7.35.0.
gnunet.org has release gnurl-7.35.0 recently. This patch updates gnurl in guix. Sree Harsha Totakura (1): gnu: gnurl: Update to 7.35.0. gnu/packages/gnunet.scm | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) -- 1.8.5.3
[PATCH] gnu: gnurl: Update to 7.35.0.
* gnu/packages/gnunet.scm (gnurl): Update to 7.35.0. --- gnu/packages/gnunet.scm | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm index 960a5d7..b084796 100644 --- a/gnu/packages/gnunet.scm +++ b/gnu/packages/gnunet.scm @@ -137,17 +137,13 @@ and support for SSL3 and TLS.) (define-public gnurl (package (name gnurl) - (version 7.34.0) + (version 7.35.0) (source (origin (method url-fetch) (uri (string-append https://gnunet.org/sites/default/files/gnurl-; version .tar.bz2)) (sha256 - (base32 - 0kpi9wx9lg938b982smjg54acdwswdshs2bzf10sj5r6zmb05ygp)) -;; This patch fixes testcase 172 which uses a hardcoded cookie -;; expiration value which is expired as of Feb 1, 2014. -(patches (list (search-patch curl-fix-test172.patch) + (base32 0dzj22f5z6ppjj1aq1bml64iwbzzcd8w1qy3bgpk6gnzqslsxknf (build-system gnu-build-system) (inputs `((gnutls ,gnutls) (libidn ,libidn) -- 1.8.5.3
Hydra serving source tarballs
Hi, I just observed that `guix build' is downloading source tarballs from Hydra. Is this supposed to be a feature? If so, what is the rationale behind not trying to download the source ball from mirrors or upstream download addresses? Regards, Sree
[PATCH] gnu: gnunet: Fix failing testcases.
* gnu/packages/gnunet.scm (gnurl): Add pkg-config. * gnu/packages/patches/gnunet-fix-tests.patch: Append fix for integration testcases. --- gnu/packages/gnunet.scm |8 +--- gnu/packages/patches/gnunet-fix-tests.patch | 12 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm index f3448a7..960a5d7 100644 --- a/gnu/packages/gnunet.scm +++ b/gnu/packages/gnunet.scm @@ -153,8 +153,9 @@ and support for SSL3 and TLS.) (libidn ,libidn) (zlib ,zlib))) (native-inputs -`((perl ,perl) - (groff ,groff) +`((groff ,groff) + (perl ,perl) + (pkg-config ,pkg-config) (python ,python-2))) (arguments `(#:configure-flags '(--enable-ipv6 --with-gnutls --without-libssh2 @@ -211,7 +212,8 @@ supports HTTPS, HTTPS and GnuTLS.) (search-patch gnunet-fix-scheduler.patch) ;; Patch to fix bugs in testcases: ;; * Disable peerinfo-tool tests as they depend on reverse DNS lookups -;; * Allow revocation testcase to run on loopback; upstream: #32130 +;; * Allow revocation and integration-tests testcases to run on +;; loopback; upstream: #32130, #32326 ;; * Skip GNS testcases requiring DNS lookups; upstream: #32118 (search-patch gnunet-fix-tests.patch))) (patch-flags '(-p0 diff --git a/gnu/packages/patches/gnunet-fix-tests.patch b/gnu/packages/patches/gnunet-fix-tests.patch index 1957b17..4276db5 100644 --- a/gnu/packages/patches/gnunet-fix-tests.patch +++ b/gnu/packages/patches/gnunet-fix-tests.patch @@ -44,3 +44,15 @@ Index: src/gns/test_gns_cname_lookup.sh rm -rf /tmp/test-gnunet-gns-peer-1/ TEST_DOMAIN_PLUS=www.gnu +Index: src/integration-tests/confs/test_defaults.conf +=== +--- src/integration-tests/confs/test_defaults.conf (revision 32320) src/integration-tests/confs/test_defaults.conf (working copy) +@@ -17,6 +17,7 @@ + EXTERNAL_ADDRESS = 127.0.0.1 + INTERNAL_ADDRESS = 127.0.0.1 + BINDTO = 127.0.0.1 ++RETURN_LOCAL_ADDRESSES = YES + + [hostlist] + SERVERS = -- 1.7.10.4
Re: none
On 02/12/2014 06:36 PM, Ludovic Courtès wrote: It would be nice if GNUnet’s ‘configure’ script would check whether gnurl has HTTPS support. It now does. :-) Sree
Re: [PATCH] gnu: gnunet: Add GNUnet-0.10.0.
Hi! On 02/10/2014 11:33 PM, Andreas Enge wrote: see my message from February 5: https://lists.gnu.org/archive/html/guix-devel/2014-02/msg00057.html To summarise, I do not know what happens. The testcase 172 tests cookies whose expiration value is hard-coded to 1391252187, which is Feb 1, 2014. Hence, the testcase is failing for a week :) I will come up with a patch soon. Regards, Sree
Re: gnu-build-system should set DESTDIR
On 02/10/2014 09:19 AM, John Darrington wrote: I think the make install target in gnu-build-system should set DESTDIR to / (or /.) Rationale: Setting DESTDIR will then make the install target to install files in the chroot dir (most likely to /usr/local/ or the prefix dir inside chroot) inside the chroot. But the intention is to install into a directory given by the --prefix variable to `configure'. Sree
Fwd: [GNUnet-developers] Google Summer of Code: GNUnet and Guix
Anyone interested in mentoring for GSoC 2014? Original Message Subject: [GNUnet-developers] Google Summer of Code: GNUnet and Guix Date: Thu, 06 Feb 2014 15:27:31 +0100 From: Sree Harsha Totakura totak...@in.tum.de To: gnunet-develop...@gnu.org, guix-devel@gnu.org On 02/06/2014 01:25 PM, Christian Grothoff wrote: Well, aside from that our plan was to package for GNU Guix and then use Guix to deploy to legacy distributions, I am unconvinced that merely packaging is an appropriate activity for a summer of *Code*. At least I had the impression that the goal was to write a bit more substantial code than what is typically required to script a package. Make a GNUnet package for GNU Guix is already done. I recently submitted patches for that. Still, it's of course great to hear that we'd have somebody willing and able to mentor this, so we should keep this in mind if/when student applications are submitted. What I want to see in the near future is for GNU Guix to propagate updates using GNUnet. I am willing to contribute to both projects in this direction and hopefully can mentor someone or be mentored by someone. Regards, Sree Harsha ___ GNUnet-developers mailing list gnunet-develop...@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Google Summer of Code: GNUnet and Guix
On 02/06/2014 01:25 PM, Christian Grothoff wrote: Well, aside from that our plan was to package for GNU Guix and then use Guix to deploy to legacy distributions, I am unconvinced that merely packaging is an appropriate activity for a summer of *Code*. At least I had the impression that the goal was to write a bit more substantial code than what is typically required to script a package. Make a GNUnet package for GNU Guix is already done. I recently submitted patches for that. Still, it's of course great to hear that we'd have somebody willing and able to mentor this, so we should keep this in mind if/when student applications are submitted. What I want to see in the near future is for GNU Guix to propagate updates using GNUnet. I am willing to contribute to both projects in this direction and hopefully can mentor someone or be mentored by someone. Regards, Sree Harsha
Re: Gnunet-0.10.0 recipe
On 02/03/2014 11:17 PM, Andreas Enge wrote: Just one last question: Is there a reason you did not add libmicrohttpd as an input? Or should I add it again? I had forgotten to add it, nevertheless it should be added to the inputs as it is a direct dependency. But how did the build succeed if libmicrohttpd were not listed in inputs? The official description printed with make sync-descriptions is different, but in fact adds only this sentence: The package includes gnunet-gtk, which provides a GTK+ graphical user interface to the GNUnet service. I think here the official description should be changed. First of all, what is the package? And as far as I can tell, gnunet-gtk would be a distinct package. The official GNU description and synopsis for GNUnet seems to be not updated in a while. It stresses only the file-sharing application while it has now newer applications like GNS and Conversation. Christian, could you please update those? Sree
Re: Gnunet-0.10.0 recipe
Hi Christian, Does GNUnet use openssl while building or is it used only during `make check`? Sree On 02/03/2014 11:57 PM, Ludovic Courtès wrote: Andreas Enge andr...@enge.fr skribis: On Fri, Jan 31, 2014 at 05:05:37PM +0100, Ludovic Courtès wrote: Note for upstream: It would be great to use GnuTLS instead of OpenSSL, especially given that OpenSSL’s license may be incompatible with the GPL in this case. From my trials, I think openssl is used only for make check. So it should probably pass into native-inputs. Could you check with ‘guix gc --references $(guix build gnunet)’ if the reference on OpenSSL is retained? If not, that’s fine, but otherwise that’s not cool. There is no reference to openssl left. OK, thanks for testing. Then indeed, OpenSSL can be moved to ‘native-inputs’ (it won’t be used when cross-compiling anyway, right?). Ludo’.
[PATCH] gnu: gnunet: Add GNUnet-0.10.0.
* gnunet/packages/gnunet.scm (gnunet): New variable. * gnu/package/patches/gnunet-fix-scheduler.patch: New file. * gnu/package/patches/gnunet-fix-tests.patch: New file. * gnu-system.am (dist_patch_DATA): Add the above two patch files. --- gnu-system.am |2 + gnu/packages/gnunet.scm | 67 +++ gnu/packages/patches/gnunet-fix-scheduler.patch | 13 + gnu/packages/patches/gnunet-fix-tests.patch | 46 4 files changed, 128 insertions(+) create mode 100644 gnu/packages/patches/gnunet-fix-scheduler.patch create mode 100644 gnu/packages/patches/gnunet-fix-tests.patch diff --git a/gnu-system.am b/gnu-system.am index 1f7327e..da35ad0 100644 --- a/gnu-system.am +++ b/gnu-system.am @@ -255,6 +255,8 @@ dist_patch_DATA = \ gnu/packages/patches/glibc-bootstrap-system.patch\ gnu/packages/patches/glibc-ldd-x86_64.patch \ gnu/packages/patches/glibc-make-4.0.patch\ + gnu/packages/patches/gnunet-fix-scheduler.patch \ + gnu/packages/patches/gnunet-fix-tests.patch \ gnu/packages/patches/gobject-introspection-cc.patch \ gnu/packages/patches/grub-gets-undeclared.patch \ gnu/packages/patches/gstreamer-0.10-bison3.patch \ diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm index 4a50fd7..e3c3b45 100644 --- a/gnu/packages/gnunet.scm +++ b/gnu/packages/gnunet.scm @@ -17,6 +17,7 @@ ;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. (define-module (gnu packages gnunet) + #:use-module (gnu packages) #:use-module (gnu packages autotools) #:use-module (gnu packages compression) #:use-module (gnu packages curl) @@ -30,10 +31,14 @@ #:use-module (gnu packages libidn) #:use-module (gnu packages libjpeg) #:use-module (gnu packages libtiff) + #:use-module (gnu packages libunistring) + #:use-module (gnu packages maths) #:use-module (gnu packages openssl) #:use-module (gnu packages pkg-config) #:use-module (gnu packages perl) + #:use-module (gnu packages pulseaudio) #:use-module (gnu packages python) + #:use-module (gnu packages sqlite) #:use-module (gnu packages video) #:use-module (gnu packages xiph) #:use-module ((guix licenses) @@ -185,3 +190,65 @@ supports HTTPS, HTTPS and GnuTLS.) (license (license:bsd-style file://COPYING See COPYING in the distribution.)) (home-page https://gnunet.org/gnurl;))) + +(define-public gnunet + (package + (name gnunet) + (version 0.10.0) + (source +(origin + (method url-fetch) + (uri (string-append mirror://gnu/gnunet/gnunet- version + .tar.gz)) + (sha256 (base32 + 0zqpc47kywhjrpphl0palz849khv00ra2gjrfkysp6p0gfsbvd0i)) + (patches + (list +;; Patch to fix serious bug in scheduler; upstream commit: #31747 +(search-patch gnunet-fix-scheduler.patch) +;; Patch to fix bugs in testcases: +;; * Disable peerinfo-tool tests as they depend on reverse DNS lookups +;; * Allow revocation testcase to run on loopback; upstream: #32130 +;; * Skip GNS testcases requiring DNS lookups; upstream: #32118 +(search-patch gnunet-fix-tests.patch))) + (patch-flags '(-p0 + (build-system gnu-build-system) + (inputs +`((gnutls ,gnutls) + (glpk ,glpk) + (libextractor ,libextractor) + (libgcrypt ,libgcrypt) + (gnurl ,gnurl) + (libidn ,libidn) + (opus ,opus) + (libtool ,libtool) + (libunistring ,libunistring) + (pulseaudio, pulseaudio) + (sqlite ,sqlite) + (zlib ,zlib))) + (native-inputs +`((pkg-config ,pkg-config) + (python ,python-2))) + (arguments +'(#:phases + (let* ((check (assq-ref %standard-phases 'check)) + (pre-check + (lambda* (#:key outputs #:allow-other-keys) +(let ((out (assoc-ref outputs out))) + (setenv GNUNET_PREFIX out) + (setenv PATH (string-append + (getenv PATH) : out /bin)) + #t +(alist-cons-after 'pre-check 'check check + (alist-cons-after 'install 'pre-check pre-check +(alist-delete + 'check %standard-phases)) + (synopsis Anonymous peer-to-peer file-sharing framework) + (description +GNUnet is a framework for secure, peer-to-peer networking. It works in a +decentralized manner and does not rely on any notion of trusted services. One +service implemented on it is censorship-resistant file-sharing. Communication +is encrypted and anonymity is provided by making messages originating from a +peer indistinguishable from those that the
Re: Gnunet-0.10.0 recipe
Here's the new patch with Andreas' changes and Openssl included as a dependency. Sree On 01/30/2014 11:56 PM, Sree Harsha Totakura wrote: Yes, this looks better, perhaps Ludo can replace the relevant part with this. (where the 'set-path-for-check phase will be made obsolete by the recent gnunet modification I suggested in its bug tracker). Yes, this will be made obsolete. We have slightly different inputs; what is opus needed for? Apart from that, We now have a new voice-chat service called conversation. Opus is the audio codec it requires, hence the new dependency. I have additional inputs: (libmicrohttpd ,libmicrohttpd) (openssl ,openssl) ; needed for some tests creating TLS certificates Maybe openssl is a remainder from an earlier gnunet version and not needed/ used anymore? The README mentions openssl as a requirement; I forgot to add it. Perhaps the build didn't build relevant parts or testcases. I shall try adding the openssl dependency and see how it goes.
[PATCH] gnu: gnunet: Add gnurl-7.34.0.
* gnu/packages/gnunet.scm (gnurl): New variable. Thanks to Zerwas for the initial recipe. --- gnu/packages/gnunet.scm | 64 +++ 1 file changed, 64 insertions(+) diff --git a/gnu/packages/gnunet.scm b/gnu/packages/gnunet.scm index 52a434a..e0ddc30 100644 --- a/gnu/packages/gnunet.scm +++ b/gnu/packages/gnunet.scm @@ -25,11 +25,15 @@ #:use-module (gnu packages glib) #:use-module (gnu packages gnupg) #:use-module (gnu packages gnutls) + #:use-module (gnu packages groff) #:use-module (gnu packages gstreamer) + #:use-module (gnu packages libidn) #:use-module (gnu packages libjpeg) #:use-module (gnu packages libtiff) #:use-module (gnu packages openssl) #:use-module (gnu packages pkg-config) + #:use-module (gnu packages perl) + #:use-module (gnu packages python) #:use-module (gnu packages video) #:use-module (gnu packages xiph) #:use-module ((guix licenses) @@ -123,3 +127,63 @@ also features security features such as basic and digest authentication and support for SSL3 and TLS.) (license license:lgpl2.1+) (home-page http://www.gnu.org/software/libmicrohttpd/;))) + +(define-public gnurl + (package + (name gnurl) + (version 7.34.0) + (source (origin +(method url-fetch) +(uri (string-append https://gnunet.org/sites/default/files/gnurl-; +version .tar.bz2)) +(sha256 + (base32 + 0kpi9wx9lg938b982smjg54acdwswdshs2bzf10sj5r6zmb05ygp + (build-system gnu-build-system) + (inputs `((gnutls ,gnutls) + (libidn ,libidn) + (zlib ,zlib))) + (native-inputs +`((perl ,perl) + (groff ,groff) + (python ,python-2))) + (arguments +`(#:configure-flags '(--enable-ipv6 --with-gnutls --without-libssh2 + --without-libmetalink --without-winidn + --without-librtmp --without-nghttp2 + --without-nss --without-cyassl + --without-polarssl --without-ssl + --without-winssl --without-darwinssl + --disable-sspi --disable-ntlm-wb + --disable-ldap --disable-rtsp --disable-dict + --disable-telnet --disable-tftp --disable-pop3 + --disable-imap --disable-smtp --disable-gopher + --disable-file --disable-ftp) + #:test-target test + #:parallel-tests? #f + ;; We have to patch runtests.pl in tests/ directory and add a failing + ;; test due to curl-gnurl name change to tests/data/DISABLED + #:phases + (alist-cons-before + 'check + 'patch-runtests + (lambda* (#:rest args) + (begin (chdir tests) +(let* ((path (search-path-as-string-list (getenv PATH))) + (sh (search-path path sh)) + (exp (string-append s@/bin/sh@ sh @g)) + (f (open-file data/DISABLED a))) + (system* sed -i exp runtests.pl) + (newline f) + (display 1022 f) + (close f)) +(chdir ../))) + %standard-phases))) + (synopsis Microfork of cURL with support for the HTTP/HTTPS/GnuTLS subset of cURL) + (description +Gnurl is a microfork of cURL, a command line tool for transferring data +with URL syntax. While cURL supports many crypto backends, libgnurl only +supports HTTPS, HTTPS and GnuTLS.) + (license (license:bsd-style file://COPYING + See COPYING in the distribution.)) + (home-page https://gnunet.org/gnurl;))) -- 1.7.10.4
HTTP proxy support in Guix
Hi, Is there support for using a HTTP proxy while downloading sources or substitutes? - Sree
Re: Installing a C tool chain
On 01/27/2014 10:53 AM, Ludovic Courtès wrote: I believe this could be addressed by having a simple “toolchain” meta-package with the sole purpose of propagating these 4 inputs, and by documenting it in the manual. Yes, a toolchain package would be nice. Debian does similarly: it has build-essential package. Sree
[PATCH] gnu: libffi: Symlink header files instead of moving them into {$prefix}/include to make them consistent with installed pkg-config file.
* gnu/packages/libffi.scm (libffi): Symlink header files instead of moving them. --- gnu/packages/libffi.scm |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gnu/packages/libffi.scm b/gnu/packages/libffi.scm index d1a834d..978481a 100644 --- a/gnu/packages/libffi.scm +++ b/gnu/packages/libffi.scm @@ -32,8 +32,10 @@ (with-directory-excursion (string-append out /lib/libffi-3.0.13/include) (for-each (lambda (h) - (format #t moving `~a' to includedir~% h) - (rename-file h (string-append out /include/ h))) + (format #t Linking `~a' to includedir~% h) + (symlink + (string-append out /lib/libffi-3.0.13/include/ h) + (string-append out /include/ h))) (scandir . (lambda (x) (not (member x '(. ..)) -- 1.7.10.4
Re: [PATCH] gnu: linux: Add iotop-0.6.
On 01/27/2014 07:05 PM, Ludovic Courtès wrote: Pushed, thanks (I made a mistake so this is two commits instead of one; sorry!). I applied it to ‘master’, but it needs a fix for http://bugs.gnu.org/16569, right? Yes, it needs to be fixed for this. Sree
Re: [PATCH] gnu: packages: Add ncdc-1.18.1.
On 01/24/2014 06:18 PM, Ludovic Courtès wrote: + #:use-module ((guix licenses) +#:renamer (symbol-prefix-proc 'license:))) #:use-module (guix licenses) I had to use the renamer as the package depends on zlib and there is also a license with the same name. Sree
/dev/shm inconsistency in chroot
Hi,
It has been known for a while that any access to /dev/shm fails inside
chroot if the host system has /dev/shm symlinked to /run/shm.
The suggested method to deal with this until now is to remove the
symlink from the host system, create /dev/shm directory and mount a
tmpfs on it.
I spent sometime investigating why this is needed and here are some
points I noted: from libstore/build.cc the daemon tries to bind mount
some paths from the host system into the chroot directory. Among these
are /dev and /dev/pts. The daemon also mounts a tmpfs file system under
chrootdir+/dev/shm should the path /dev/shm exist.
Due to bind mounting /dev, on systems where /dev/shm is a symlink, the
symlink is also present in the chrootdir+/dev. Since the symlink points
to /run/shm, and since /run is not bind mounted by default into the
chrootdir+/run, the symlink is broken inside chroot.
The above problem can be addressed by passing --chroot-directory=/run to
the guix-daemon which then includes /run into the list of mounts that
are to be bind mounted inside chroot. This will resolve the
chroot+/dev/shm symlink properly. Yet, the accesses to /dev/shm fail
inside the chroot. This is because the mount statement in build.cc for
mounting tmpfs at chroot+/dev/shm mounts the tmpfs at /run/shm the
target of the symlink and since /run tree is made private the mount does
not propagate into the bind mounted chroot+/run tree. In the chroot,
this leaves the /dev/shm symlink to point to the directory /run/shm and
obviously any shared memory accesses fail.
This problem can be fixed finally by passing
--chroot-directory=/run/shm. Although the tmpfs mount for
chroot+/dev/shm still ends up mounting tmpfs at /run/shm, since /run/shm
is now bind mounted to chroot+/run/shm, inside the chroot the symlink
/dev/shm points to /run/shm which is now a tmpfs. The shared memory
accesses work fine here. However there is caveat: since /run/shm is
bindmounted any files from the host system from that directory are also
present in the chroot.
To address this further and to get rid of having the user to pass
--chroot-directory flag, I propose the attached patch.
Regards,
Sree
From 359fda36b6dcabea79a76b56e10d4d67702f545f Mon Sep 17 00:00:00 2001
From: Sree Harsha Totakura sreehar...@totakura.in
Date: Thu, 23 Jan 2014 20:11:57 +0100
Subject: [PATCH] Create tmpfs on /dev/shm after chrooting.
src/libstore/build.cc: Create tmpfs on /dev/shm after chrooting. If /dev/shm is a link, create required directory for mounting.
---
src/libstore/build.cc | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/src/libstore/build.cc b/src/libstore/build.cc
index 4329d9a..b01bf92 100644
--- a/src/libstore/build.cc
+++ b/src/libstore/build.cc
@@ -2054,12 +2054,6 @@ void DerivationGoal::initChild()
if (mount(none, (chrootRootDir + /proc).c_str(), proc, 0, 0) == -1)
throw SysError(mounting /proc);
-/* Mount a new tmpfs on /dev/shm to ensure that whatever
- the builder puts in /dev/shm is cleaned up automatically. */
-if (pathExists(/dev/shm))
-if (mount(none, (chrootRootDir + /dev/shm).c_str(), tmpfs, 0, 0) == -1)
-throw SysError(mounting /dev/shm);
-
/* Do the chroot(). Below we do a chdir() to the
temporary build directory to make sure the current
directory is in the chroot. (Actually the order
@@ -2067,6 +2061,17 @@ void DerivationGoal::initChild()
tmpRootDit/tmpDir are the same directories.) */
if (chroot(chrootRootDir.c_str()) == -1)
throw SysError(format(cannot change root directory to `%1%') % chrootRootDir);
+
+/* Mount a new tmpfs on /dev/shm to ensure that whatever
+ the builder puts in /dev/shm is cleaned up automatically. */
+if (pathExists (/dev/shm))
+{
+Path target = /dev/shm;
+if (isLink(target) !pathExists(target = readLink(target)))
+createDirs(target);
+if (mount(none, /dev/shm, tmpfs, 0, 0) == -1)
+throw SysError(mounting /dev/shm);
+}
}
#endif
--
1.7.10.4
signature.asc
Description: OpenPGP digital signature
sqlite upgrade to 3.8.2
Hi, The attached patch upgrades Sqlite to 3.8.2. Please commit it to master. Sree From 848d90f4b02cd16417e6488ef9dcbec352e9c2f2 Mon Sep 17 00:00:00 2001 From: Sree Harsha Totakura sreehar...@totakura.in Date: Wed, 22 Jan 2014 14:34:42 +0100 Subject: [PATCH] gnu: sqlite: Upgrade to 3.8.2 Signed-off-by: Sree Harsha Totakura sreehar...@totakura.in --- gnu/packages/sqlite.scm |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gnu/packages/sqlite.scm b/gnu/packages/sqlite.scm index ae083cd..f688e13 100644 --- a/gnu/packages/sqlite.scm +++ b/gnu/packages/sqlite.scm @@ -26,7 +26,7 @@ (define-public sqlite (package (name sqlite) - (version 3.7.15.2) + (version 3.8.2) (source (origin (method url-fetch) ;; TODO: Download from sqlite.org once this bug : @@ -34,10 +34,10 @@ ;; has been fixed. (uri (string-append mirror://sourceforge/sqlite.mirror/SQLite%20 - version /sqlite-autoconf-3071502.tar.gz)) + version /sqlite-autoconf-3080200.tar.gz)) (sha256 (base32 - 135s6r5z12q56brywpxnraqbqm7bdkxs76v7dygqgjpnjyvicbbq + 14pg9zlwbwsj5w7f3qr25d3nniyv82gmczwlvpj0i0ic1431v1d0 (build-system gnu-build-system) (home-page http://www.sqlite.org/;) (synopsis The SQLite database management system) -- 1.7.10.4 signature.asc Description: OpenPGP digital signature
New package recipe: libopus-1.1
Hi, Attached is a recipe for libopus-1.1. Please include it. Thank you, Sree From eafeaed576eccd20e108f62dc61d89d2c4be353b Mon Sep 17 00:00:00 2001 From: Sree Harsha Totakura sreehar...@totakura.in Date: Wed, 22 Jan 2014 16:17:18 +0100 Subject: [PATCH] new package: libopus-1.1 Signed-off-by: Sree Harsha Totakura sreehar...@totakura.in --- gnu/packages/opus.scm | 50 + 1 file changed, 50 insertions(+) create mode 100644 gnu/packages/opus.scm diff --git a/gnu/packages/opus.scm b/gnu/packages/opus.scm new file mode 100644 index 000..2102b59 --- /dev/null +++ b/gnu/packages/opus.scm @@ -0,0 +1,50 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2013 Andreas Enge andr...@enge.fr +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +;; Author: Sree Harsha Totakura sreehar...@totakura.in + +(define-module (gnu packages opus) + #:use-module (gnu packages) + #:use-module ((guix licenses) +#:renamer (symbol-prefix-proc 'license:)) + #:use-module (guix packages) + #:use-module (guix download) + #:use-module (guix build-system gnu)) + +(define-public libopus + (package +(name libopus) +(version 1.1) +(source (origin + (method url-fetch) + (uri (string-append +http://downloads.xiph.org/releases/opus/opus-; version +.tar.gz)) + (sha256 + (base32 +158xprn2086arvdib3vbbygz7z6jqkw2nci7nlywzzwallap0wmr +(build-system gnu-build-system) +(synopsis Libopus - hightly versatile audio codec) +(description Opus is a totally open, royalty-free, highly versatile audio +codec. Opus is unmatched for interactive speech and music transmission over +the Internet, but is also intended for storage and streaming applications. It +is standardized by the Internet Engineering Task Force (IETF) as RFC 6716 +which incorporated technology from Skype's SILK codec and Xiph.Org's CELT +codec.) +(license license:bsd-3) +(home-page http://www.opus-codec.org/;))) \ No newline at end of file -- 1.7.10.4 signature.asc Description: OpenPGP digital signature
Re: sqlite upgrade to 3.8.2
Ok, thanks. Attached the new patch with the suggested changes. Sree On 01/22/2014 05:43 PM, Mark H Weaver wrote: gnu: sqlite: Update to 3.8.2. * gnu/packages/sqlite.scm (sqlite): Upgrade to 3.8.2. From 16a77fe7ff74fd5062671d6fdb9eabba2bd89659 Mon Sep 17 00:00:00 2001 From: Sree Harsha Totakura sreehar...@totakura.in Date: Wed, 22 Jan 2014 18:00:09 +0100 Subject: [PATCH] gnu: sqlite: Upgrade to 3.8.2. * gnu/packages/sqlite.scm (sqlite): Upgrade to 3.8.2. Signed-off-by: Sree Harsha Totakura sreehar...@totakura.in --- gnu/packages/sqlite.scm |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gnu/packages/sqlite.scm b/gnu/packages/sqlite.scm index ae083cd..f688e13 100644 --- a/gnu/packages/sqlite.scm +++ b/gnu/packages/sqlite.scm @@ -26,7 +26,7 @@ (define-public sqlite (package (name sqlite) - (version 3.7.15.2) + (version 3.8.2) (source (origin (method url-fetch) ;; TODO: Download from sqlite.org once this bug : @@ -34,10 +34,10 @@ ;; has been fixed. (uri (string-append mirror://sourceforge/sqlite.mirror/SQLite%20 - version /sqlite-autoconf-3071502.tar.gz)) + version /sqlite-autoconf-3080200.tar.gz)) (sha256 (base32 - 135s6r5z12q56brywpxnraqbqm7bdkxs76v7dygqgjpnjyvicbbq + 14pg9zlwbwsj5w7f3qr25d3nniyv82gmczwlvpj0i0ic1431v1d0 (build-system gnu-build-system) (home-page http://www.sqlite.org/;) (synopsis The SQLite database management system) -- 1.7.10.4 signature.asc Description: OpenPGP digital signature
Re: New package recipe: libopus-1.1
Hi, Here is the patch with the suggested commit message. Sree On 01/22/2014 05:37 PM, Mark H Weaver wrote: gnu: Add libopus. * gnu/packages/opus.scm: New file. * gnu-system.am (GNU_SYSTEM_MODULES): Add it. From 18c8bb6e1064ec39982c5350e22c74562fd6ea94 Mon Sep 17 00:00:00 2001 From: Sree Harsha Totakura sreehar...@totakura.in Date: Wed, 22 Jan 2014 18:07:06 +0100 Subject: [PATCH] gnu: Add libopus. * gnu/packages/opus.scm: New file. * gnu-system.am (GNU_SYSTEM_MODULES): Add it. Signed-off-by: Sree Harsha Totakura sreehar...@totakura.in --- gnu-system.am |1 + gnu/packages/opus.scm | 47 +++ 2 files changed, 48 insertions(+) create mode 100644 gnu/packages/opus.scm diff --git a/gnu-system.am b/gnu-system.am index 43f95b3..6a88c45 100644 --- a/gnu-system.am +++ b/gnu-system.am @@ -149,6 +149,7 @@ GNU_SYSTEM_MODULES =\ gnu/packages/onc-rpc.scm \ gnu/packages/openldap.scm \ gnu/packages/openssl.scm \ + gnu/packages/opus.scm\ gnu/packages/package-management.scm \ gnu/packages/parallel.scm \ gnu/packages/parted.scm \ diff --git a/gnu/packages/opus.scm b/gnu/packages/opus.scm new file mode 100644 index 000..fad265e --- /dev/null +++ b/gnu/packages/opus.scm @@ -0,0 +1,47 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2014 Sree Harsha Totakura sreehar...@totakura.in +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. + +(define-module (gnu packages opus) + #:use-module (gnu packages) + #:use-module (guix licenses) + #:use-module (guix packages) + #:use-module (guix download) + #:use-module (guix build-system gnu)) + +(define-public libopus + (package +(name libopus) +(version 1.1) +(source (origin + (method url-fetch) + (uri (string-append +http://downloads.xiph.org/releases/opus/opus-; version +.tar.gz)) + (sha256 + (base32 +158xprn2086arvdib3vbbygz7z6jqkw2nci7nlywzzwallap0wmr +(build-system gnu-build-system) +(synopsis Libopus - highly versatile audio codec) +(description Opus is a totally open, royalty-free, highly versatile audio +codec. Opus is unmatched for interactive speech and music transmission over +the Internet, but is also intended for storage and streaming applications. It +is standardized by the Internet Engineering Task Force (IETF) as RFC 6716 +which incorporated technology from Skype's SILK codec and Xiph.Org's CELT +codec.) +(license bsd-3) +(home-page http://www.opus-codec.org/;))) -- 1.7.10.4 signature.asc Description: OpenPGP digital signature
fetching substitutes slow
Hi, Over the last week I tried to fetch substitutes with no success from hydra.gnu.org. It always showed the error server is unresponsive. However, the nar packages get downloaded with wget. So, I removed the timeout with the attached patch and the substitute downloads are working again. This time I observed that the speed at which the substitute-binary.scm downloads the nar file is far low than when the same file is downloaded through wget. I haven't done extensive testing on this to confirm firmly, but it looks like the http-fetch implementation is not efficient. Can anyone confirm this? - Sree From 50417a01f71f973002171dcd9e5457721b3487ab Mon Sep 17 00:00:00 2001 From: Sree Harsha Totakura sreehar...@totakura.in Date: Tue, 21 Jan 2014 08:56:37 +0100 Subject: [PATCH] - remove timeout --- guix/scripts/substitute-binary.scm |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guix/scripts/substitute-binary.scm b/guix/scripts/substitute-binary.scm index 901b3fb..ec620c5 100755 --- a/guix/scripts/substitute-binary.scm +++ b/guix/scripts/substitute-binary.scm @@ -142,7 +142,7 @@ provide. ;; sudo tc qdisc del dev eth0 root (let ((port #f)) (with-timeout (if (or timeout? (guile-version? 2.0.5)) - %fetch-timeout + 0 0) (begin (warning (_ while fetching ~a: server is unresponsive~%) -- 1.7.10.4 signature.asc Description: OpenPGP digital signature
Re: Guix initd script
Yes, but it may not work if those distros have systemd which is likely to replace or may have replaced sysinit. Sree On 01/15/2014 04:22 PM, Ludovic Courtès wrote: Sree Harsha Totakura sreehar...@totakura.in skribis: I wrote an initd script for starting guix-daemon and would like to share it. It is available here: https://gnunet.org/content/gnu-guix-initd-script Nice, thanks! I assume that’s notably for Debian-based distros, right? Ludo’.
Re: Guix initd script
On 01/15/2014 08:40 PM, Nikita Karetnikov wrote:
Could you add a license header?
Ok, attached the file with license header.
Sree
#!/bin/sh
### BEGIN INIT INFO
# Provides: guix-daemon
# Required-Start:$local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: starts the guix-daemon
# Description: starts guix-daemon using start-stop-daemon
### END INIT INFO
#
# Author:Sree Harsha Totakura sreehar...@totakura.in using lightdm script
#from Yves-Alexis Perez cor...@debian.org
#
# License:
# (C) 2014 Sree Harsha Totakura sreehar...@totakura.in
#
# This file is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published
# by the Free Software Foundation; either version 3, or (at your
# option) any later version.
#
# This file is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNUnet; see the file COPYING. If not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/local/bin/guix-daemon
DAEMON_OPTS=--build-users-group=guix-builder --cores=0
NAME=guixd
DESC=guix-daemon
test -x $DAEMON || exit 0
set -e
. /lib/lsb/init-functions
case $1 in
start)
echo -n Starting $DESC:
start-stop-daemon --start --background --make-pidfile \
--quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON -- $DAEMON_OPTS || true
echo $NAME.
;;
stop)
echo -n Stopping $DESC:
start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \
--exec $DAEMON || true
echo $NAME.
;;
restart)
echo -n Restarting $DESC:
start-stop-daemon --stop --quiet --pidfile \
/var/run/$NAME.pid --exec $DAEMON || true
sleep 1
start-stop-daemon --start --background --make-pidfile \
--quiet --pidfile \
/var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS || true
echo $NAME.
;;
status)
status_of_proc -p /var/run/$NAME.pid $DAEMON $NAME exit
0 || exit $?
;;
*)
echo Usage: $NAME {start|stop|restart|status} 2
exit 1
;;
esac
exit 0
signature.asc
Description: OpenPGP digital signature
