Re: Proposal for Outreachy (May-August 2020)
On Sun, 12 Jan 2020 00:39:55 +0100 Ludovic Courtès wrote: > Hi, > > > The “or any later version” wording is present in source file headers, > so it’s definitely ‘gpl2+’, not ‘gpl2’. Right, that's what I was supposed to say, but my brain removed the "+". > I fixed this one and a couple of others in > 7bd000d104f79f2b1c51c48c9d01f247189f9935. > > Thanks for the heads-up! No problem. > Ludo’. Jan Wielkiewicz
Re: Store channel specification in profile
Hi,
Pierre Neidhardt skribis:
>> Basically an entry looks like:
>>
>> --8<---cut here---start->8---
>> ("diffoscope"
>> "131"
>> "out"
>> "/gnu/store/h8zr4rxhvpikv9p07kdjkf2dsrja35wm-diffoscope-131"
>> (propagated-inputs ())
>> (search-paths ())
>> (properties
>> (provenance
>> (repository
>> (version 0)
>> (url "https://git.savannah.gnu.org/git/guix.git;)
>> (branch "master")
>> (commit
>> "b5d4d5b9bcf267fddd02fcc14b88eac0bebf979f")
>> --8<---cut here---end--->8---
>
> The above is not very human friendly. Each entry should be something
> like plist with default values, so that the user does not have to write
> "out" every time.
Note that it was never designed to be human-friendly. :-) The Scheme
code passed to ‘--manifest’ is friendlier.
> Questions:
>
> - Do manifests really need the store path?
> - Same question about propagated-inputs. Aren't they already encoded in
> the package definition? Why repeating them here?
This ‘manifest’ file exists mostly for one purpose: to allow incremental
operations on a profile with ‘guix upgrade’, ‘guix install’, and so on.
If ‘--manifest’ were the only way to build a profile, this ‘manifest’
file would (almost) not be needed. (Actually it’s also needed for
‘--list-installed’.)
Incremental operations need all this info so they can pull in the right
store items, set the right search paths, etc. IOW, they need to work
around the fact that some of the objects for their profile are
not available.
HTH!
Ludo’.
Re: Proposal for Outreachy (May-August 2020)
Hi, Jan skribis: > Don't know if this is a good place, but gnome-color-manager in this > commit: > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=29ae18db0578bbdbc0119703f7412fe91927e80e > has GPL2 license in the "license" field and the COPYING file also tells > the license is GPL2, but if you check a random source file, for example > https://gitlab.gnome.org/GNOME/gnome-color-manager/blob/master/src/gcm-brightness.c > Then files are licensed under GPL2 or any later. >> * This program 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 2 of the License, or >> * (at your option) any later version. > > I guess the license is GPLV2 then, but I'm not sure, can someone > confirm this? The “or any later version” wording is present in source file headers, so it’s definitely ‘gpl2+’, not ‘gpl2’. I fixed this one and a couple of others in 7bd000d104f79f2b1c51c48c9d01f247189f9935. Thanks for the heads-up! Ludo’.
Re: Speeding up “guix pull”: splitting modules
Hello, zimoun skribis: > So knowing where the cycles are could help to transform the DaG (not > fully acyclic yet) to a DAG. :-) Unfortunately, the module graph necessarily contains cycles. The only way to avoid them would be to have exactly one module per package, given that the package graph is acyclic. Thanks, Ludo’.
Re: TeX Live 2019 wanted
Marius Bakke writes:
> I'll look into updating the remaining texlive packages shortly.
Now this was some rocket science...
The attached 9 patches updates everything (I think) to 2019.3.
The only regression I found from 'master' was that "discrover" fails to
find math fonts during the build process. Anything else using
texlive-union appears to be in order.
I get a similar error for 'asymptote' on the current master branch, but
that seems to be sporadically working on Berlin?
https://ci.guix.gnu.org/search?query=system%3Ax86_64-linux+asymptote
I think I'll "punt" on that issue for now. Pierre, if you ever wanted
to figure out the TeX Live font stuff, now is a good time! ;-)
Ricardo, let me know if you spot anything odd! I'll commit this in a
day or two unless there are any comments.
From 4c23ee4b136bfa6814a75feea1f1548fbade5d81 Mon Sep 17 00:00:00 2001
From: Marius Bakke
Date: Sat, 11 Jan 2020 23:36:36 +0100
Subject: [PATCH 1/9] gnu: Add ruby-hydra.
* gnu/packages/ruby.scm (ruby-hydra): New public variable.
---
gnu/packages/ruby.scm | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 57d7fa91f3..969fc95a00 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -6,7 +6,7 @@
;;; Copyright © 2015, 2019 Ricardo Wurmus
;;; Copyright © 2015, 2016, 2017 Ben Woodcroft
;;; Copyright © 2017 ng0
-;;; Copyright © 2017, 2019 Marius Bakke
+;;; Copyright © 2017, 2019, 2020 Marius Bakke
;;; Copyright © 2017, 2018, 2019 Efraim Flashner
;;; Copyright © 2017, 2018 Tobias Geerinckx-Rice
;;; Copyright © 2017 Clément Lassieur
@@ -1953,6 +1953,40 @@ two hashes.")
(home-page "https://github.com/liufengyun/hashdiff;)
(license license:expat)))
+(define-public ruby-hydra
+ ;; No releases yet.
+ (let ((commit "5abfa378743756ae4d9306cc134bcc482f5c9525")
+(revision "0"))
+(package
+ (name "ruby-hydra")
+ (version (git-version "0.0" revision commit))
+ (home-page "https://github.com/hyphenation/hydra;)
+ (source (origin
+(method git-fetch)
+(uri (git-reference (url home-page) (commit commit)))
+(file-name (git-file-name name version))
+(sha256
+ (base32
+ "1cik398l2765y3d9sdhjzki3303hkry58ac6jlkiy7iy62nm529f"
+ (build-system ruby-build-system)
+ (arguments
+ '(#:phases (modify-phases %standard-phases
+(add-after 'unpack 'make-files-writable
+ (lambda _
+(for-each make-file-writable (find-files "."))
+#t))
+(replace 'check
+ (lambda _
+(invoke "rspec"))
+ (native-inputs
+ `(("ruby-rspec" ,ruby-rspec)))
+ (propagated-inputs
+ `(("ruby-byebug" ,ruby-byebug)))
+ (synopsis "Ruby hyphenation patterns")
+ (description
+ "ruby-hydra is a Ruby library for working with hyphenation patterns.")
+ (license license:expat
+
(define-public ruby-shindo
(package
(name "ruby-shindo")
--
2.24.1
From 679f2698636f224b9c91abb87eff8ad9cf59351d Mon Sep 17 00:00:00 2001
From: Marius Bakke
Date: Thu, 9 Jan 2020 18:36:50 +0100
Subject: [PATCH 2/9] gnu: poppler: Update to 0.84.0.
* gnu/packages/pdf.scm (poppler): Update to 0.84.0.
---
gnu/packages/pdf.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/pdf.scm b/gnu/packages/pdf.scm
index 368b2ce69e..32a45ed4d5 100644
--- a/gnu/packages/pdf.scm
+++ b/gnu/packages/pdf.scm
@@ -90,14 +90,14 @@
(define-public poppler
(package
(name "poppler")
- (version "0.79.0")
+ (version "0.84.0")
(source (origin
(method url-fetch)
(uri (string-append "https://poppler.freedesktop.org/poppler-;
version ".tar.xz"))
(sha256
(base32
- "1j18jlv1q6h21azb939gqjsgcbsh5qcd8dwxdmad54p5ixha91gr"
+ "0ccp2gx05cz5y04k5pgbyi4ikyq60nafa7x2yx4aaf1vfkd318f7"
(build-system cmake-build-system)
;; FIXME:
;; use libcurl:no
--
2.24.1
From 23b9afcc9fe608a26c13fe2f579a8accd025bb2b Mon Sep 17 00:00:00 2001
From: Marius Bakke
Date: Fri, 10 Jan 2020 23:49:42 +0100
Subject: [PATCH 3/9] gnu: inkscape: Fix build with Poppler 0.84.
* gnu/packages/inkscape.scm (inkscape)[arguments]: Add phase
'adjust-for-new-poppler'.
---
gnu/packages/inkscape.scm | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/inkscape.scm b/gnu/packages/inkscape.scm
index 1ad23a92d4..0bd8b9496b 100644
--- a/gnu/packages/inkscape.scm
+++ b/gnu/packages/inkscape.scm
@@ -2,7 +2,7 @@
;;; Copyright © 2014 John Darrington
;;; Copyright © 2014, 2016 Mark H Weaver
;;; Copyright © 2016, 2018 Ricardo Wurmus
-;;; Copyright © 2017 Marius
staging branch open
Guix, There is a brand new staging branch on Savannah: https://git.savannah.gnu.org/cgit/guix.git/log/?h=staging Please submit your changes by Monday, January 19th. signature.asc Description: PGP signature
Re: drop net-tools from %base-packages?
Hello, Simon Josefsson skribis: > From 3ac6e4c9853a0cbc6fb42a2d263bb03bb9583c34 Mon Sep 17 00:00:00 2001 > From: Simon Josefsson > Date: Wed, 1 Jan 2020 18:05:47 +0100 > Subject: [PATCH] system: Drop net-tools from %BASE-PACKAGES (replaced by > iproute2). > > * gnu/system.scm (%base-packages): Remove net-tools. Finally applied, thanks! Ludo’.
Re: qtwenengine anybody?
Pierre Neidhardt writes: >> Now we just need some packages using it! :-) > > We can get started with Qutebrowser. This was my first thought as well. Though next is also a good candidate too? :) If anyone is working on updating quitebrowser let me know. If not I'll starting working on this soon. Side note Pierre, I'll switch GIQT over to this in the next couple of days as well. Mike
Re: qtwenengine anybody?
Marius Bakke writes: > mike.ros...@gmail.com writes: > >> I've attached a patch that resolves these suggestions. Along with >> patches to fix punctuation suggested by Pierre. >> >> Complete diff can still be found >> at. https://gitlab.com/mike.rosset/guix/compare/master...merge-qtwebengine >> >> Marius I've forgot to attach from your series in my last email. I've >> attached the rest of the series for you. encase you want to git am. > > Great! I've squashed them appropriately and finally merged qtwebengine! > > I also moved the package definition alongside the other first party Qt > modules. > > Now we just need some packages using it! :-) Thank you Marius, I appreciate this being merged and all the suggestions everyone provided. Mike
Package request: OpenRA
Hi, We don't have OpenRA (https://www.openra.net/). Has anyone worked on it? Otherwise I'll go ahead. Any tip, any special wish? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: qtwenengine anybody?
mike.ros...@gmail.com writes: > I've attached a patch that resolves these suggestions. Along with > patches to fix punctuation suggested by Pierre. > > Complete diff can still be found > at. https://gitlab.com/mike.rosset/guix/compare/master...merge-qtwebengine > > Marius I've forgot to attach from your series in my last email. I've > attached the rest of the series for you. encase you want to git am. Great! I've squashed them appropriately and finally merged qtwebengine! I also moved the package definition alongside the other first party Qt modules. Now we just need some packages using it! :-) signature.asc Description: PGP signature
Re: Proposal for a blog contribution on reproducible computations
Hi Konrad Konrad Hinsen writes: [...] > Maybe I got something wrong, but I think I described this as you say > (please check!). Quote: > > Build systems are pieces of Guile code that are part of Guix. But this > Guile code is only a shallow layer orchestrating invocations of other > software, such as =gcc= or =make=. And that software is defined by > packages. > > The build procedure is that "shallow layer orchestrating invocations". > Does this sound right? what about "shallow layer (build procedure) orchestrating invocations", just to be super-clear? :-) [...] > Giovanni Biscuolo writes: > >>> (which is sad because your Org file with Babel sessions is much nicer…). >>> I think Pierre had something to convert Org to Markdown. >> >> you could try pandoc or emacs-ox-hugo, both in Guix >> I can help convert/adapt if needed > > My plan for now is pandoc, but if that doesn't work as expected, I'll > come back to your offer for help! I seldom used pandoc to converd org to Markdown, please give me a feedback on the quality of the result, thanks! [...] Ciao, Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Parameterized packages
Hi Ludo! Ludovic Courtès writes: > The way I see it, we’re still toying with the idea and its pros and > cons—discussions about CLI syntax can come later. ;-) Sure thing! > The added flexibility of package parameters is definitely nice, but > really, maintainability is a big concern. The example Tobias gave (a > parameter to enable/disable X11 support) is interesting because it shows > that parameters can quickly become ubiquitous and get “out of control”, > from a maintenance viewpoint. What I understood from Tobias comment on the X11 support parameter is that we need to store the parameter metadata centrally. Why do you think this suggests it will get "out of control"? > That’s another good example of a problem that would arise. :-/ > It doesn’t seem reasonable to me to add complex logic in (guix packages) > to deal with this issue; I would very much prefer to leave input > handling unchanged. > > I’m worried about the maintenance cost of parameters. Having the > feature is one thing, but being able to guarantee that the package > combinations we offer all work is another one. > > We could have the feature and use it very seldom in Guix itself, but I’m > guessing that that’s not what you have in mind. Indeed, the ultimate goal would be to do things like "install a headless system" and "use static libraries everywhere", etc. > Also, for CI purposes, we would need a way to enumerate all the possible > combinations… Considering the number of outputs would explode as parameters get added, it does not seem reasonable to try building everything. Maybe an easy option would be: - Only build the default packages (i.e. using the default values of the parameters). - If a non-default output is requested often enough (to be defined) then build it. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Proposal for a blog contribution on reproducible computations
Ludovic Courtès writes: > Another thing that comes to mind: would it make sense to mention ‘guix > graph’ in the part where you pipe the output of ‘guix show’ to ‘recsel’, > etc.? Forgot that one, sorry. Yes, it would make sense, though I'd place it a bit later in the text. But I'd have to figure out first how how the various options of "guix graph" relate exactly to what I am writing. ‘package’ This is the default type used in the example above. It shows the DAG of package objects, excluding implicit dependencies. It is concise, but filters out many details. Are "implicit dependencies" those added by the build system? If yes, this edges in this graph would correspond to package-direct-inputs. ‘bag’ Similar to ‘bag-emerged’, but this time including all the bootstrap dependencies. And that is package-closure with arrows defined by bag-direct-inputs, right? Cheers, Konrad.
Re: Proposal for a blog contribution on reproducible computations
Hi Ludo, Simon, and GIovanni, Thanks for your feedback ! > Minor comments: > > • You write “Build systems are packages as well”. This could be > slightly misleading: build systems are (1) a set of packages, and > (2) a build procedure. Dunno if it makes sense to clarify that. Maybe I got something wrong, but I think I described this as you say (please check!). Quote: Build systems are pieces of Guile code that are part of Guix. But this Guile code is only a shallow layer orchestrating invocations of other software, such as =gcc= or =make=. And that software is defined by packages. The build procedure is that "shallow layer orchestrating invocations". Does this sound right? > • In the ‘guix pack’ example, you could perhaps omit all the -S flags > except for /bin, and mention ‘--save-provenance’. I'll have to look up ‘--save-provenance’ first. I don't use "guix pack" that much, though I should probably use it more, if only to expose more people indirectly to Guix. > • Would it make sense to mention MPFR in the paragraph about IEEE 754? I considered it, but left it out because it would probably create confusion. And people who are aware of MPFR probably don't need my explanation of floats. > • Regarding ‘--container’, you write that namespaces “may not be > present on your system, or may be disabled by default”, which is a > bit strong; “may be present on your system, but perhaps disabled by > default” would be more accurate. :-) Fixed. I don't know anything about the implementation techniques of –container, so I'll blindly write what you say :-) > The format we use is Markdown fed to Haunt: OK, pandoc should get me there. > You can post a patch against the guix-artwork.git repo here when you’re > ready. OK. > If you want we can publish it next Tuesday or Thursday. We could have > it on both hpc.guix.info and guix.gnu.org, with one saying that it’s a > re-post of the other. Fine with me! zimoun writes: > That said, I also find interesting the command-line and hashes comparisons: > > --8<---cut here---start->8--- > /usr/bin/gcc pi.c -o pi-debian-gcc8 > docker run -v `pwd`:`pwd` -w `pwd` -ti gcc-toolchain gcc pi.c -o pi-docker > guix environment --container --ad-hoc gcc-toolchain -- gcc pi.c -o pi-guix > > md5sum pi-* > > b268af34d62763a2a707944403bf7b0b pi-debian-gcc8 > 1be3c1b5d1e065017e4c56f725b1a692 pi-docker > 1be3c1b5d1e065017e4c56f725b1a692 pi-guix > --8<---cut here---end--->8--- > > Anyway! :-) Nice! Not sure I want to go into that because it requires adding another system (Debian), which I think is mainly a source of confusion. >> • Would it make sense to mention MPFR in the paragraph about IEEE 754? > > And MPFI? ;-) OK, I see another blog post coming ;-) But there are people more competent than myself for that. Giovanni Biscuolo writes: >> (which is sad because your Org file with Babel sessions is much nicer…). >> I think Pierre had something to convert Org to Markdown. > > you could try pandoc or emacs-ox-hugo, both in Guix > I can help convert/adapt if needed My plan for now is pandoc, but if that doesn't work as expected, I'll come back to your offer for help! Thanks everyone, Konrad.
