Re: A registry for distributed sources and binaries

On Tue, Jul 26, 2016 at 05:40:49AM +0200, Pjotr Prins wrote: > On Mon, Jul 25, 2016 at 11:21:43AM +0200, Ludovic Courtès wrote: > > I like the idea! (With the caveat that, again, external repos can break > > anytime.) > > > > Partly related to that: > >

Re: A registry for distributed sources and binaries

On Mon, Jul 25, 2016 at 11:21:43AM +0200, Ludovic Courtès wrote: > I like the idea! (With the caveat that, again, external repos can break > anytime.) > > Partly related to that: > . Actually very much related because a git pull attached to a

FOSDEM 2016 was awesome! Let's do FOSDEM 2017

FOSDEM 2017 call for proposals has started: https://fosdem.org/2017/news/2016-07-20-call-for-participation/ We need help with writing the proposal (we can build on last years this time), we need help on selecting talks and we need help creating the schedule. Finally, if we get a slot, we need

Re: Go & bundling

2016-07-26 0:05 GMT+02:00 Ludovic Courtès : > Leo Famulari skribis: > > > We will have to decide what to do about bundled dependencies. Bundling > > the source code of dependencies appears to be standard practice in the > > world of Go. > > Bundling appears to

Re: core-updates, next release, and all that

Andreas Enge skribis: > On Sun, Jul 24, 2016 at 12:59:22PM -0400, Leo Famulari wrote: >> So strange. Could the source code have been corrupted while unpacking? >> Can anyone replicate this locally, so they can use --keep-failed? > > Yes, but I still cannot make anything of it. >

Re: Odd behavior with --dry-run and --upgrade

Ludovic Courtès writes: > Hi! > > Alex Kost skribis: > >> Roel Janssen (2016-07-23 18:11 +0300) wrote: >> >>> Dear Guix, >>> >>> For some time now, running `guix package --dry-run --upgrade' results in >>> build actions involving grafting. For a dry-run, I find that really

Re: Broken Calibre package

Andreas Enge writes: > On Mon, Jul 25, 2016 at 10:42:16PM +0200, Andreas Enge wrote: >> As a first fix, we should revert and replace qtbase by qt in the package. > > Things were a bit more complex; I also needed to build the python bindings > in python2-pyqt with the non-modular Qt. So I

Go & bundling

Leo Famulari skribis: > We will have to decide what to do about bundled dependencies. Bundling > the source code of dependencies appears to be standard practice in the > world of Go. Bundling appears to be standard practice in the world. :-) > The compiler began supporting

Reviewer assignment

Hello! Andy Wingo skribis: > A fully distributed system sounds nice but it has costs too. In my mind > for a project of Guix's target size the best situation would be having > around 100 committers or so who have internalized the coding style and > patterns of Guix so that

DMD

Hello, I just noticed that we still have a dmd package (that does not build on arm). Should we not drop it now that we have the shepherd? Andreas

Re: Broken Calibre package

On Mon, Jul 25, 2016 at 10:42:16PM +0200, Andreas Enge wrote: > As a first fix, we should revert and replace qtbase by qt in the package. Things were a bit more complex; I also needed to build the python bindings in python2-pyqt with the non-modular Qt. So I re-added the previous version as

Re: extending initrd

Hi, Tomáš Čech skribis: > I'm playing a bit with initrd and I miss there a way, how to add > additional content to the image (busybox in my case now). Is there > really no way yet how to do that? The initrd automatically contains everything the given gexp refers to:

Re: [GSoC] Continuous integration tool à la Hydra.

Hello! Mathieu Lirzin skribis: > Since my second update I have first fixed a major bug. When building > different branches of Guix and evaluating package derivations the > results were always the same. The issue was that the evaluations were > happening in the same Guile process

Re: [GSoC update] Npm & guix

Hello! Jelle Licht skribis: > On Ludo's advice, I snarfed Ricardo's recursive importer and bolted it > on my npm importer. After leaving the importer running for a quite > some hours (and making it more robust in the face of inconsistent npm > information), it turns out that

Re: Help with Perl security update

On Mon, Jul 25, 2016 at 04:00:09PM -0400, Leo Famulari wrote: I'm trying to patch our Perl package against CVE-2016-1238 and CVE-2016-6185: This patch uses a graft to apply new patches which are composed of commits from the 'maint-5.22' branch of

Re: [PATCH} Add RAID devices.

Hello! On Sat, Jul 23, 2016 at 10:43:58PM -0700, Chris Marusich wrote: > Cool! Is it possible to use them in combination? Using the example > From the documentation, would it possible to use LUKS to create an > encrypted /dev/mapper/home which uses /dev/md0 instead of /dev/sda3? unfortunately

Re: [PATCH 0/5] Improve the pypi updater.

Cyril Roelandt skribis: > On 07/22/2016 11:22 PM, Ludovic Courtès wrote: >> Neat! So the test dependencies go to ‘inputs’ instead of >> ‘propagated-inputs’, right? That can definitely save time and avoid >> errors. >> > > Indeed, the runtime dependencies are propagated

Re: [PATCH 4/5] import: pypi: Compute test requirements when reading requirements files.

Cyril Roelandt skribis: > On 07/22/2016 11:30 PM, Ludovic Courtès wrote: >> This seems to suggest that this could be factorized somehow. Maybe >> unpack once and read the two files at once? > > The problem is that both files might not be there, and unzip will return > a

Re: [PATCH 2/5] import: pypi: Remove setuptools from the inputs.

Cyril Roelandt skribis: > On 07/22/2016 11:43 PM, Leo Famulari wrote: >> In my experience, it is more often required for Python 2.x, but >> sometimes it is required by Python 3.x packages, and sometimes not for >> Python 2.x packages. >> >> I'd be happy to get a more

Re: [PATCH} Add RAID devices.

Hello, Chris Marusich skribis: > Andreas Enge writes: [...] >> + #~(let ((every (@ (srfi srfi-1) every))) > > Can't you just use "every" on its own? It looks like you've imported > the srfi-1 module earlier on. I’m the one who suggested it as a

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

On Mon, Jul 25, 2016 at 12:02:11PM +0200, Cyril Roelandt wrote: > This could probably be useful: > https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work Indeed, thanks a lot! Andreas

Re: Broken Calibre package

On Mon, Jul 25, 2016 at 10:15:08PM +0200, Roel Janssen wrote: > Thanks for the recent upgrade to version 2.62.0 of Calibre. I encounter > the following problem after completing the setup dialog: > Are we missing a qtwebkit package? Yes. It is not the calibre upgrade that poses problems, but the

Separate Mailing Lists for Patches vs General Dev Discussion?

Hi, I'm following the Guix-Project, even if not contributing much because of time constraints. The one, very simple to implement, thing that would make following the project more easy IMHO would be a separate list for patches. Or maybe the other way around: A separate list for more general

Broken Calibre package

Dear Guix, Thanks for the recent upgrade to version 2.62.0 of Calibre. I encounter the following problem after completing the setup dialog: Traceback (most recent call last): File "/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/bin/.calibre-real", line 20, in

Re: core-updates, next release, and all that

Hello Leo, replying personally, since I am getting embarrassed... On Mon, Jul 25, 2016 at 08:40:56PM +0200, Andreas Enge wrote: > I had the impression that the new wxwidgets url did not appear, since the > build still fails on hydra. Now I see that the url is there, and the failure > on hydra is

Re: Go build system

On Mon, Jul 25, 2016 at 12:25:40AM +0200, Ludovic Courtès wrote: > It outlines the command sequence that needs to be run. I’d suggest > starting from that in ‘go-build-system’. Let’s make it work for this > package, and then we can adjust if some of the assumptions happened to > be specific to

Re: core-updates, next release, and all that

On Mon, Jul 25, 2016 at 12:30:03PM -0400, Leo Famulari wrote: > What went wrong? I had the impression that the new wxwidgets url did not appear, since the build still fails on hydra. Now I see that the url is there, and the failure on hydra is probably just cached because the hash did not change.

Re: core-updates, next release, and all that

On Mon, Jul 25, 2016 at 09:51:49AM +0200, Andreas Enge wrote: > On Sun, Jul 24, 2016 at 06:48:13PM +0200, Andreas Enge wrote: > > It worked out and did not take that long after all. I pushed the fix, merged > > master into core-updates > > This does not seem to have worked out. I will let someone

Re: [PATCH] gnu: gmime: Remove gpg to gpg2 patch.

On Mon, Jul 25, 2016 at 11:47:51AM +, ng0 wrote: > (with-fluids ((%default-port-encoding #f)) >(substitute* (find-files "tests" "\\.c$") > (("(system *\\(\")(/[^ ]*)" all pre prog-path) > (let* ((base (basename prog-path)) > -

Re: [PATCH] gnu: Add perceptualdiff.

On Mon, Jul 25, 2016 at 12:49:56PM +0200, Vincent Legoll wrote: > Hello, > > > Maybe you're right. Unlike the gnu-build-sytem, the cmake-build-system > > seems to create a 'build/' directory adjacent to the unpacked source > > code. > > Yes, I think in cmake's land, the recommended way is to

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

On Mon, Jul 25, 2016 at 10:59:07AM +0200, Ludovic Courtès wrote: > All the Guix repositories on Savannah now reject unsigned Git commits: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#112 > > Please report any problems. Since the repo disables forced-pushing, we instead delete

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

On Mon, Jul 25, 2016 at 12:02:11PM +0200, Cyril Roelandt wrote: > On 07/25/2016 10:59 AM, Ludovic Courtès wrote: > > Hello! > > > > All the Guix repositories on Savannah now reject unsigned Git commits: > > > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#112 > > > > This could

Re: [PATCH] doc: Explain when guix edit is read-only.

Ludovic Courtès (2016-07-24 20:06 +0300) wrote: > Alex Kost skribis: > >> myglc2 (2016-07-22 01:35 +0300) wrote: >> >>> * doc/guix.texi (Invoking guix edit): Explain when you can and can't >>> edit the recipe >>> --- >>> doc/guix.texi | 10 -- >>> 1 file changed, 8

Re: [PATCH 2/3] profiles: Add fonts-dir-file hook.

Ludovic Courtès (2016-07-24 20:09 +0300) wrote: > Alex Kost skribis: > >> Ludovic Courtès (2016-07-05 17:31 +0300) wrote: >> >>> Alex Kost skribis: >>> Ludovic Courtès (2016-07-02 17:34 +0300) wrote: > Alex Kost skribis:

Re: [PATCH] gnu: emacs: Install site-start.el in non-versioned directory.

Alex Kost (2016-07-24 09:16 +0300) wrote: > Ricardo Wurmus (2016-07-24 08:06 +0300) wrote: > >> Alex Kost writes: >> >>> Ricardo tested Emacs 25 with this package definition: >>> and noticed that it doesn't find >>> Emacs packages in

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

Cyril, On 2016-07-25 12:02, Cyril Roelandt wrote: What will we do about patches sent by casual contributors, that will probably be unsigned? Should the committer sign them? Yes. (Most already do this, though.) Kind regards, T G-R -- Sent from a web browser. Excuse my brevity.

Re: [PATCH] gnu: sbcl: Update to 1.3.7.

Andy Patterson writes: > This patch allows sbcl to build using the newer texlive. Pushed, thanks!

[PATCH] gnu: gmime: Remove gpg to gpg2 patch.

gmime building broke with gpg@2.1 --build-gpg2-as-gpg or what it was. This fixes it. Please also fix the typo in the commit message ("peviously"). From 3bc7d2c8d94da0a81ecc16b2e12791f9ed466c95 Mon Sep 17 00:00:00 2001 From: ng0 Date: Mon, 25 Jul 2016 11:38:37 +

Re: [GSoC update] Npm & guix

Jelle Licht writes: > On Ludo's advice, I snarfed Ricardo's recursive importer and bolted it on my > npm > importer. After leaving the importer running for a quite some hours (and > making > it more robust in the face of inconsistent npm information), it turns out that > jQuery has a direct or

Re: [PATCH] gnu: Add perceptualdiff.

Hello, > Maybe you're right. Unlike the gnu-build-sytem, the cmake-build-system > seems to create a 'build/' directory adjacent to the unpacked source > code. Yes, I think in cmake's land, the recommended way is to build in a directory outside of the source code , generally at the same level

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

On 07/25/2016 10:59 AM, Ludovic Courtès wrote: > Hello! > > All the Guix repositories on Savannah now reject unsigned Git commits: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#112 > This could probably be useful: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work What

Re: Gs

¡Hola! Andreas Enge skribis: > On Sat, Jul 23, 2016 at 01:03:07PM +0200, Ludovic Courtès wrote: >> For the current solution (avoiding a full rebuild), see commit >> 61dc82d9b90d0545739c30bfc33003bd062071f0. LilyPond could hard-code the >> file name of ‘gsc’. > > This looks

Re: A registry for distributed sources and binaries

Hello, Ricardo Wurmus skribis: > Currently, GUIX_PACKAGE_PATH depends on some manual work to be done > first. Finding a third-party repository, downloading it, updating it > separately from Guix itself (it won’t get updated via “guix pull”), > setting the variable. > > When

Replying to bug reports

Hi, Jookia <166...@gmail.com> skribis: > Even worse, if I want to reply to an issue on a mailing list that I'm not > subscribed to, it's difficult. To reply to a bug report listed at , email n...@debbugs.gnu.org, where N is the bug number. For mailing lists in

Heads-up: git.sv.gnu.org now rejects unsigned commits

Hello! All the Guix repositories on Savannah now reject unsigned Git commits: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#112 Please report any problems. In the future the hook will also check that commits are signed by authorized keys, but the details need to be laid out. Ludo’.

Re: [PATCH 3/3] gnu: ecl: Wrap with PATH, CPATH, LIBRARY_PATH and LD_LIBRARY_PATH

Andy Patterson skribis: > * gnu/packages/lisp.scm (ecl)[arguments]: Wrap with PATH, CPATH, > LIBRARY_PATH and LD_LIBRARY_PATH [...] > + ("libffi" ,libffi) > + ("linux-headers" ,linux-libre-headers) > + ("gcc" ,gcc) > +

Re: Go build system

On Mon 25 Jul 2016 00:25, l...@gnu.org (Ludovic Courtès) writes: >> Should Go packages refer to the compiler? This Syncthing package does >> retain a reference. > > I suppose it keeps a reference to run-time support libraries provided by > the ‘go’ package? I believe that unless you specifically

Re: [GSoC update] Npm & guix

On Sun 24 Jul 2016 03:06, Jelle Licht writes: > On Ludo's advice, I snarfed Ricardo's recursive importer and bolted it > on my npm importer. After leaving the importer running for a quite > some hours (and making it more robust in the face of inconsistent npm > information), it

Re: [PATCH 2/3] gnu: ecl: Enable tests.

Andy Patterson skribis: > * gnu/packages/lisp.scm (ecl): Enable tests. That’s good news. Applied, thanks! Ludo’.

Re: A registry for distributed sources and binaries

On Sun 24 Jul 2016 15:58, Andreas Enge writes: > A problem, as mentioned in another reply, is the lack of people doing code > review, which is not a very rewarding task. That can be changed by everyone > of us :-) Could we just focus on this problem perhaps? One of the issues

Re: [PATCH 1/3] gnu: ecl: Update to 16.1.2.

Andy Patterson skribis: > * gnu/packages/lisp.scm (ecl): Update to 16.1.2. Applied, thanks!

Re: [PATCH v2] gnu: Add lrzip.

Leo Famulari skribis: > On Sun, Jul 24, 2016 at 11:36:24PM +0200, Ludovic Courtès wrote: >> No, I’ll try and adjust what’s available at: >> . >> (Suggestions welcome, though!) > > I will

Re: help with setenv of perl-curses

Hello, > +(build-system perl-build-system) > +(inputs `(("ncurses" ,ncurses))) > +(arguments > + `(#:phases > + (modify-phases %standard-phases > + (add-before > + 'configure 'set-curses-ldflags > + (lambda* (#:key inputs #:allow-other-keys) > +

Re: Cook source disappeared

Leo Famulari skribis: > This project is trying to address the problem: > https://www.softwareheritage.org/ > > I wonder if Guix can use that archive as a last resort? Yes, when it’s available (currently there’s no HTTP API that we can use). I discussed our use case with the

Re: core-updates, next release, and all that

Andreas Enge skribis: > On Sun, Jul 24, 2016 at 06:04:39PM +0200, Andreas Enge wrote: >> Right now, I am trying to disable parallel builds; so far >> things look good, I think we are beyond the previous point of failure. >> But of course this would not be a very pleasant

Re: [PATCH] gnu: Bump version of "hplip" to "3.16.5".

Please ignore patch. There's already a newer version in the git repo.

Re: [PATCH 4/7] gnu: Add spice-gtk.

> Likewise if its .pc file “Requires” the .pc file of a dependency. Maybe we want to patch pkg-config to not check for propagated dependencies? > If an installed .h file of spice-gtk #includes a .h file of a > dependency, that dependency should be a propagated input. > Likewise if its .pc file

[PATCH] gnu: Bump version of "hplip" to "3.16.5".

* gnu/packages/cups.scm (hplip): Version bump to 3.16.5. --- gnu/packages/cups.scm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gnu/packages/cups.scm b/gnu/packages/cups.scm index 8437170..f1df906 100644 --- a/gnu/packages/cups.scm +++ b/gnu/packages/cups.scm @@

Re: core-updates, next release, and all that

On Sun, Jul 24, 2016 at 06:48:13PM +0200, Andreas Enge wrote: > It worked out and did not take that long after all. I pushed the fix, merged > master into core-updates This does not seem to have worked out. I will let someone more git-savvy do it next time, maybe after someone more C-savvy has

extending initrd

Hi, I'm playing a bit with initrd and I miss there a way, how to add additional content to the image (busybox in my case now). Is there really no way yet how to do that? In expression->initrd it refers to closure yet I fail to find how is it found/constructed... Thanks in advance for pointers.

Re: Odd behavior with --dry-run and --upgrade

On Mon, Jul 25, 2016 at 12:18:41AM +0200, Ludovic Courtès wrote: > > I'm totally agree with this; nowadays I always use --dry-run with > > --no-grafts option. > Same here… > > As a user I expect that --dry-run means no building at all. > But honestly, I think changing ‘--dry-run’ to do ‘--dry-run

icecat "mailto" handler does not work - and cannot be reconfigured by user

> Unless I misunderstood what you mean: this already exists. On the page > you linked to above look for “reply via email to”. It’s followed by a > button. When you click on it you get a “mailto”-Link. Whoops. I should have read the page better. However, clicking on that button in icecat does

Re: A registry for distributed sources and binaries

On Sun, Jul 24, 2016 at 10:35:43PM +0200, Ricardo Wurmus wrote: What do you think about that? Does this align with your vision? What do others think? Is this something that would benefit the Guix project and its audience? I like the idea a lot. I'm only concerned with security of such

Re: [PATCH] Add Elixir (was: )

On Mon, Jul 25, 2016 at 08:13:33AM +0200, Ricardo Wurmus wrote: > back to the original patch, which I didn’t look at as the ensuing > discussion on review process and registry proposals took up more time > than I anticipated. :) > I’m a little uncertain on how to proceed. I have a couple of

Re: Seeking guidance regarding system roll-back and switch-generation

Hi Ludo, Thank you for the concrete suggestions. I've looked into using the parameters file. It contains almost all the info I need, but I think some is still missing. > The output of ‘guix system build’ contains the ‘parameters’ file, which > is enough to generate grub.cfg (see

[PATCH] Add Elixir (was: )

Hi Pjotr > From 5fd8f64794b27f59f6688177a7a9e532b5d57f01 Mon Sep 17 00:00:00 2001 > Date: Tue, 19 Jul 2016 11:13:27 + > Subject: [PATCH] gnu: Add elixir. > To: guix-devel@gnu.org > From: Pjotr Prins > References: