Re: [ART] Logo proposal
Le mercredi 11 février 2015 à 22:12 -0500, Luis Felipe López Acevedo a écrit : Thus, the first step would be to come up with a multi-page site (yay!) and with appropriate style. That probably means departing from the gnu.org style sheets and server-side includes. This is not an ideal solution, but it easier than trying to adjust all of gnu.org to meet our needs. I would hope that whoever takes up this task communicates with the gnu.org webmasters in an effort to collaborate in the longer run. Thoughts? Volunteers? While a place for the website is found, I can work on some mock-ups, if that's OK. A VM has been obtained at my university for the Guix build farm. It can be used for web hosting as well. As for the mock-ups, if I can be of any help tell me, Luis. rigelk -
Re: [ART] Updated SLiM theme with GuixSD logo
Le jeudi 12 février 2015 à 20:41 +0100, Andreas Enge a écrit : On Thu, Feb 12, 2015 at 01:56:37PM -0500, Luis Felipe López Acevedo wrote: I just updated the SLiM theme with the new GuixSD logo. The text-input box remains in the same position, so no additional changes are needed. See the attached image, I regret the previous more gnu inspired theme, but must admit that the new one is very beautiful indeed! The new theme take a step towards a more modern allure. We wouldn’t want to feel old-fashioned, would we ? ;) rigelk -
Guix toolchain compilation failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, As I tried to compile the 'hello' package with 'guix build hello' (with verbosity, processors and --keep-failed options), I have the following errors: http://bpaste.net/show/190277/ Any ideas about how to solve this ? (I'm not even sure if there's enough info in that log file... if not, just say so) Thanks, - - rigelk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTKKWcAAoJEHfJ0QE7gLd6xhsH+wS5XP6Fds8MvUIOjSzJjApH NO6bLXrG4ZNhGhMhh7/fA6J9rdpoAcsAZ0GymBma6ZnZ+Hppxh9+rTfSKC5fjq1Y 79OMJrTsvawdlR4EL6Leb/zJTSiZX5WlCixWLYjy9xpn4enCNDycJJda/UJVhtTp 6oliPR62b0xTvRsEHcknt8Nx6dBM7sITLE+wC2zVcqJA6HtcfXvUBn4eqoty13mp HJh96Ja84V1Uqd7t942msr/h86dYuAwt3Y/mEtaGBW3NO2nLD8dARk5yhTPhh19+ 1DdKDHYelLU5UwMjF9AQqoYcMrN31cbSO0yITfH3gPDjEA08TNo8hLOabYmTNjM= =iu9f -END PGP SIGNATURE-
Re: [GSoC] GNUnet binary distribution system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2014 04:35, Mark H Weaver wrote: Pierre-Antoine Rault p...@rigelk.eu writes: On 10/03/2014 22:09, Ludovic Courtès wrote: The initial discussion [0] left open the question of where binaries themselves should be stored. A possibility would be to use GNUnet’s DHT simply as a discovery mechanism, and then to establish a connection directly to the user’s machine, which would run, say, an HTTP server. That's what I had in mind. Now, considered the post [2] by Christian Grothoff, we might consider using either an HTTP server for performance or GNUnet's MESH for anonymity (and security). We should balance needs and ease of implementation. [2] http://lists.gnu.org/archive/html/guix-devel/2014-03/msg00113.html FWIW, I think it might be worthwhile to support BitTorrent magnet links as well, as a middle ground between these two extremes. Most users will not be able to host binaries via HTTP; even if they have a server, the bandwidth requirements are hard to predict and likely to be too high. I'm not sure to understand why you precise BitTorrent magnet links. Magnet is a de-facto standard that is independant from BitTorrent [3] [4], and using BitTorrent in our case wouldn't have better performance than GNUnet's MESH. The only user case when BitTorrent might come in handy is when one wants to download a binary (as one would download a .deb) before manually installing it with guix ; i suppose this can also be done through GNUnet. Then of course it's just a user case: users might be more familiar with BitTorrent. [3] http://magnet-uri.sourceforge.net/ [4] http://magnet-uri.sourceforge.net/magnet-draft-overview.txt I hope this makes sense :) - - rigelk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHrRnAAoJEHfJ0QE7gLd6mcMH/A3dlgu2UAJKo3JzR7RSdf8M 2V4xxw4d+vNNPqpIBRYsfJUVkRxePmAljntzsgTQ59AbibAjMt5uXI2htqYAGFia nsXvSIv0YkkPoE15morUtL8XYohRNvkSmaSKR2EqX/+Vxxm7C3Ftni4tlIbLB13k afK/ExDYV2+SoASS5myPqCaK3jusCmCeXlew2aDInbn7owGgtA4dxvti5TtfGaUi IMp/xXb3jimzIyzWbX+rKCvouVRK+ncdBxGzw+kPMtE6h5hja70M0Mw6IaREvJqA dj9mb5YU+OUoLrayVM/PcTML2gqYHhoXkSDQzqsWHLfbtxq0ymUWcnOe2d/WdGY= =JIQ8 -END PGP SIGNATURE-
Re: [patch] - Packaging guideline documentation update
Cross-refs and a small glossary would help a lot to start with Guix. However, I was thinking about an explanation of folders, sub folders and main files as seen in the GNUnet manual [1]. [1] https://gnunet.org/book/export/html/37 Of course, these are just ideas to help brainstrom :) - rigelk l...@gnu.org a écrit : Pierre-Antoine Rault p...@rigelk.eu skribis: On 10/03/2014 21:56, Ludovic Courtès wrote: I’ve applied a stripped-down version of the patch: I ended up removing “Packaging 101” because it was redundant with the “Packaging Guidelines” section of the manual, so I moved the missing bits in that section (info (guix) Packaging Guidelines). I also removed details about how ‘git format-patch’ and co. work, because these commands already have their own manual. I admit it was overkill :) I realize the manual can be improved when it comes to introductory material. I would think of a (not so) short explaination of the guix tree as seen in the GNUnet manuel, for instance. What do you think ? Hmm, perhaps. Actually, part of the module name space is described here in there. For instance (gnu packages ...) is described under “Package Modules”, (guix build ...) is described under “Derivations”, etc. Perhaps a new section with cross-refs to these would help? Ludo’.
Re: [patch] - Packaging guideline documentation update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 10/03/2014 21:56, Ludovic Courtès wrote: I’ve applied a stripped-down version of the patch: I ended up removing “Packaging 101” because it was redundant with the “Packaging Guidelines” section of the manual, so I moved the missing bits in that section (info (guix) Packaging Guidelines). I also removed details about how ‘git format-patch’ and co. work, because these commands already have their own manual. I admit it was overkill :) I realize the manual can be improved when it comes to introductory material. I would think of a (not so) short explaination of the guix tree as seen in the GNUnet manuel, for instance. What do you think ? - - rigelk -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHkaAAAoJEHfJ0QE7gLd6XSsIAIX5kQtsZmdJ6P8kSRo+0Euo YolTVuBs1BGbEq+sIx1nBPpzt1CYCuLkO/R/FzbKNpy2RmHwR/M2K1OEcr71hH2B DFIW65WEkTAZeouDRmU06leg+9I3EkQpJ6rqRmIyts9drUzRQoJdzkn0uZAROvSN hqBofvBQGvurvbBg+bjIW9UqObowsa9Bhg8lH0bLWpqA2CIzw8U3uWPTphHc5azH ML7lNYtdr7J95yMXsl/PN2DpiWiO8pG+uXPmBUanCgmipcAW5tU1VmC9Jp+LJBPU h1ke6Ym0wFsyFwuqzqC3INcOkwvGeM9yO7D/XNHVlQusY+FyRIkbEGeHyVkQ3Eg= =tuXM -END PGP SIGNATURE-
[patch] - Packaging guideline documentation update
Hello guix, Attached is a patch with basic explaination most of you know by heart, but that may not be obvious for newbies (like me). The details provided to the doc and hacking file both cover packaging and how to avoid the main pitfalls I've encountered myself recently. Most of them are based on advice from Dave, Mark_weaver (on #guix), these slides: http://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf and these commands http://lists.gnu.org/archive/html/guix-devel/2013-12/msg00079.html What do you think ? Are there things to add ? (of course there are !) First patch here ; any advice ? - rigelk From 8138e894da83d0ad3616df049992538fd0b3ec6f Mon Sep 17 00:00:00 2001 From: Pierre-Antoine Rault p...@rigelk.eu Date: Sun, 9 Mar 2014 17:10:27 +0100 Subject: [PATCH] doc: Updated packaging guidelines. * ./HACKING (Submitting Patches): detailed git commands for 'git format-patch' and 'git send-mail'. (Packaging 101) New section detailing packaging contribution from a newbie point of view, avoiding explaining common pitfalls. * doc/guix.texi (Packaging Guidelines): Shortly explained dev procedure ; explaining deprecated #:export and new public-define ; redirection to HACKING file added. (Contributing) Added reference to #guix channel on freenode. --- HACKING | 80 +++ doc/guix.texi | 34 - 2 files changed, 97 insertions(+), 17 deletions(-) diff --git a/HACKING b/HACKING index 0dc2908..1fb65f8 100644 --- a/HACKING +++ b/HACKING @@ -4,6 +4,7 @@ Copyright © 2012, 2013 Ludovic Courtès l...@gnu.org Copyright © 2013 Nikita Karetnikov nik...@karetnikov.org +Copyright © 2014 Pierre-Antoine Rault p...@rigelk.eu Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright @@ -12,8 +13,9 @@ Copyright © 2013 Nikita Karetnikov nik...@karetnikov.org * Building from Git -When building Guix from a checkout, the following packages are required in -addition to those mentioned in the installation instructions: +Development should be done through git. When building Guix from a git +checkout, the following packages are required in addition to those +mentioned in the installation instructions: - [[http://www.gnu.org/software/autoconf/][GNU Autoconf]] - [[http://www.gnu.org/software/automake/][GNU Automake]] @@ -51,7 +53,11 @@ take a look at âinfo '(guix) Installation'â or send a message to * Running Guix before it is installed -Command-line tools can be used even if you have not run make install. +Command-line tools can be used even if you have not run make +install. Actually, some developpers prefer not to run make install and +use a script in their /usr/local/bin/ named 'guix' to call the following +substitute to 'guix'. + To do that, prefix each command with â./pre-inst-envâ, as in: ./pre-inst-env guix build --help @@ -85,10 +91,74 @@ wrapping it, swallowing or rejecting the following s-expression, etc. Development is done using the Git distributed version control system. Thus, access to the repository is not strictly necessary. We welcome contributions in the form of patches as produced by âgit format-patchâ sent to -guix-devel@gnu.org. Please write commit logs in the [[http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs][GNU ChangeLog format]]. +guix-devel@gnu.org (see below). Remember to please write commit logs in +the [[http://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs][GNU ChangeLog format]]. + +When posting a patch to the mailing-list, use [PATCH] ... as a +subject. You may use your email client or the 'git send-mail' command. + +Depending on your distribution, 'git send-mail' might be part of another +package (git-email in Debian, for instance). It is an extremely nice +tool. You can generate a patch series by doing: + +$ git format-patch commit + +This will generate a bunch of files called 0001-commit-title, +0002-commit-title and so on. Then just do: + +$ git send-email --to guix-devel@gnu.org --in-reply-to message-id of +your first message 000*.patch + +And we'll get all your patches in a nice thread :) As you become a regular contributor, you may find it convenient to have write -access to the repository (see below.) +access to the repository (see below, Commit Access.) + +* Packaging 101 + +To get started adding package to the guix tree (gnu/packages/), copy +a *.scm in the tree or create a new one. It should contain at least three +elements: + + - A licence (copy from other .scm, and put your name) + - A define-module form (which imports (and may export) modules) + - A define-public form containing the package description (one may use +define only, but then has to add an #:export (package_name) to the +define form - deprecated) + +Modify the define-public form according to the package: copyright
