Exploring licenses of NPM packages recursively

[swedebugia]

Hi

Today I found this tool:
https://hackernoon.com/licenses-for-npm-packages-b2036b4bb6a
https://github.com/franciscop/legally/blob/master/package.json

I intend to try to package it so we can use it to check licenses.

Also this tool might be useful:
https://www.npmjs.com/package/dependency-graph

--
Cheers
Swedebugia

Re: Generated patches change over time

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Maxim Cournoyer  skribis:
>>
> l...@gnu.org (Ludovic Courtès) writes:
>>>
Lesson learned: we should not rely at all on generated patches because
they are bound to change frequently (version string at the end, length
of commit hash prefixes, etc.)  It’s probably worse than tarballs
generated by Git hosting services.

So we should probably work towards using local copies of patches,
unless
we find that the generated patches do not include any variable bits.

>>>
>>> Maybe we could pass the patches through some sanitizer to strip any 
>>> metadata? I guess the content itself shouldn't change?
>>
>> We can’t really do that, or the downloads would no longer be
>> fixed-output derivations and thus we wouldn’t be solving the problem.
>
> Can you elaborate on why it cannot be done?  If I understand correctly,
> our 'git-fetch' origin type deletes the .git subdirectory after fetching
> it, and yet it still creates fixed-output derivations, no?  I don't see
> why stripping metadata from a patch is fundamentally any different.

You’re right, along the same lines, it could be a fixed-output
derivation.

The problem is rather that the workflow would be a bit awkward: ‘guix
download’ would download the raw, unprocessed patch, and thus it would
give you the “wrong” hash.

In essence you’d have to put a random hash in your package definition,
run “guix build -S”, copy the correct hash from the error message,
manually look at the patch, etc.

It’s possible, but it’s a bit awkward IMO.

Or we would need to add a ‘--strip-patch-metadata’ option to ‘guix
download’ so that it applies the exact same transformation when
downloading.

Thoughts?

Ludo’.

Re: hg-fetch with subrepos

[Björn Höfling]

On Sat, 1 Dec 2018 11:10:54 -0800
John Soo  wrote:

> Hi guix!
> 
> Thanks and please bear with my first ever mailing list post.  I was
> trying to package coin3d
> (https://bitbucket.org/Coin3D/coin/wiki/Home) as it is now under a
> bsd3 license.  The hash of the repo always changes. I think this is
> due to the .hg files not being recursively deleted for the
> subrepositories (https://www.mercurial-scm.org/wiki/Subrepository).
> Does anyone have any insights?
> 

Hi John,

I'm also packaging coin3d :-)

And I stumbled upon that problem too. Ludovic explained me on IRC: The
problem is the metadata directory ".hg": It contains metadata that is
not fixed. For normal hg-repositories, it will be stripped away, but
not recursively for those with sub-repos.

I have a patch that works. I just wasn't sure if it goes to master or
to staging, as it could affect the java-packages as well.

I'm attaching what I have here, will prepare an official patch tonight
or tomorrow.

Björn

PS: With coin3d, I want to add freecad. If that is your intention too,
we should share resources.

From 57167ebf39e3f10c4025cb03893456c7269f98f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20H=C3=B6fling?=
 
Date: Fri, 23 Nov 2018 18:38:27 +0100
Subject: [PATCH] hg-fetch: Remove .hg directories of sub-repositories.

* guix/build/hg.scm (hg-fetch): Remove all .hg directories recursively.
---
 guix/build/hg.scm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/guix/build/hg.scm b/guix/build/hg.scm
index ea51eb670..9f493f1d6 100644
--- a/guix/build/hg.scm
+++ b/guix/build/hg.scm
@@ -45,8 +45,10 @@ Mercurial changeset identifier.  Return #t on success, #f otherwise."
   ;; The contents of '.hg' vary as a function of the current
   ;; status of the Mercurial repo.  Since we want a fixed
   ;; output, this directory needs to be taken out.
-  (with-directory-excursion directory
-(delete-file-recursively ".hg"))
+  ;; Since the '.hg' file is also in sub-modules, we have to
+  ;; search for it in all sub-directories.
+  (for-each delete-file-recursively
+(find-files directory "^\\.hg$" #:directories? #t))
 
   #t)
 
-- 
2.19.1



pgpuDifojzRjy.pgp
Description: OpenPGP digital signature

Re: 01/01: gnu: ocaml@4.01: Remove aarch64-linux from supported-systems.

[Efraim Flashner]

On Sat, Dec 01, 2018 at 05:23:32PM -0500, Mark H Weaver wrote:
> Hi Efraim,
> 
> guix-comm...@gnu.org writes:
> 
> > efraim pushed a commit to branch master
> > in repository guix.
> >
> > commit 454e7132d6fffb5c9a5ce086ffd1b687416feb83
> > Author: Efraim Flashner 
> > Date:   Sat Dec 1 22:41:19 2018 +0200
> >
> > gnu: ocaml@4.01: Remove aarch64-linux from supported-systems.
> > 
> > * gnu/packages/ocaml.scm (ocaml@4.01)[supported-systems]: New field.
> 
> What's the rationale for this change?
> Debian includes OCaml 4.01 in its arm64 port.
> 
>   https://packages.debian.org/search?arch=arm64&keywords=ocaml
>   http://http.us.debian.org/debian/pool/main/o/ocaml/ocaml_4.01.0-5_arm64.deb
> 
>   Mark

starting phase `configure'
../gnu/config.guess: unable to guess system type

This script, last modified 2011-11-11, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (../gnu/config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to  in order to provide the needed
information to handle your system.

config.guess timestamp = 2011-11-11

uname -m = aarch64
uname -r = 4.4.52
uname -s = Linux
uname -v = #19 SMP Tue May 2 11:36:30 HKT 2017

/usr/bin/uname -p =
/bin/uname -X =

hostinfo   =
/bin/universe  =
/usr/bin/arch -k   =
/bin/arch  =
/usr/bin/oslevel   =
/usr/convex/getsysinfo =

UNAME_MACHINE = aarch64
UNAME_RELEASE = 4.4.52
UNAME_SYSTEM  = Linux
UNAME_VERSION = #19 SMP Tue May 2 11:36:30 HKT 2017
Cannot guess host type
You must specify one with the -host option


I tried Debian's autoreconf plan, where every package gets "autoreconf
-vfi" before configure, but there was no configure.ac in the source.
After looking through the included configure script, it checks for
arm*-*-*-*, so adding "-host" "arm64-unknown-linux-gnu" made it pass the
configure phase. There is more work needed to make it actually build,
but it looks like it is possible.

It still fails to build, but it's at least getting much closer. I'll fix
that.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

New French PO file for 'guix-manual' (version 0.16.0.1)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the French team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/fr.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Common Lisp executables: purging spurious reference to libraries?

[Pierre Neidhardt]

Hi Guix!

I'm packaging the new rewrite of Next (https://next.atlas.engineer).
It's a Common Lisp application and the executable should be
self-contained, it does not need to depend on SBCL or the like.

However, `guix size next` return the full dependency tree of Common Lisp
libraries.

If I inspect the executable, I see that it contains a bunch of references:

--8<---cut here---start->8---
> strings next | grep sbcl
sbcl_home
sbcl_fallback_sigsegv_handler
sbcl_main
/sbcl.core
Usage: sbcl [runtime-options] [toplevel-options] [user-options]
website .
More information about SBCL is available at .
/gnu/store/bbjhsli5dssp2wh9gi9749c9mny46lcy-sbcl-1.4.13/lib/sbcl/
sbcl_home
sbcl_fallback_sigsegv_handler
sbcl_main
   to sbcl-devel.~
sbcl_fallback_sigsegv_handler
sbcl_home
sbcl_main
/gnu/store/7jvzkfcjxr6cqb9hvqv2rdcvr18fp7yd-sbcl-next-1.0.0-1.b889934/bin/next-exec.lisp
/gnu/store/n4l31ls9s50v5plws4yq7wq75c9hahm4-sbcl-next-1.0.0-1.b889934-lib/share/common-lisp/sbcl-source/next/source/package.lisp
/gnu/store/dxx2i719izq7jmxxj31c3pxcnhvkfwx6-sbcl-unix-opts-0.1.7/share/common-lisp/sbcl-source/unix-opts/unix-opts.lisp
...
--8<---cut here---end--->8---

I think this is why Guix keeps the Common Lisp libraries in the
closure.

Any idea how to remove them?

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Better support for single-user systems

[Taylan Kammer]

Most desktop users have single unix account and are also in control of
root.  These users might not want to differentiate between the current
guix version of root and their normal user.  They might also not want
to differentiate between the packages available to root and the normal
user.  As such I would propose the following two improvements:

- Allow a system-wide guix installation that's updated with a special
  variant of 'guix pull' executed by root

- Allow direct addition of packages to the system profile to obviate
  the need of running a full 'guix system reconfigure' after adding
  packages to the system configuration

(The latter might show a reminder that if the package isn't also added
to the system config, it will be removed again on the next system
reconfiguration.)

Currently I use a hack to imitate #1 where I have a unix account
called 'guix-user' with which I run 'guix pull', and both root and my
normal user have symlinks to that user's current guix.  For #2 I don't
have a workaround; I just re-run 'guix system reconfigure' every time.


What do others think?


- Taylan

Re: Merging core-updates

[Danny Milosavljevic]

Hi Ludo,

On Sat, 01 Dec 2018 19:20:26 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> On x86_64, LibreOffice, IceCat, etc. are available as substitutes; ‘guix
> weather’ reports only 50% of coverage on berlin and 80% on
> mirror.hydra.gnu.org (we’ll have to elucidate the bad number on berlin.)
> I’m using ‘core-updates’ for both my system and my user profile.
> 
> Overall I’m in favor of merging.

Me too.

I've finally disabled the flaky Rust test in core-updates so it shouldn't
nondeterministically break the build anymore.  Unfortunately that means
it will cause some senseless rebuilds - among those icecat :(

So let's wait for those builds and then merge.


pgpU8daKbEfAQ.pgp
Description: OpenPGP digital signature

Re: Merging core-updates

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> On Sat, 01 Dec 2018 19:20:26 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> On x86_64, LibreOffice, IceCat, etc. are available as substitutes; ‘guix
>> weather’ reports only 50% of coverage on berlin and 80% on
>> mirror.hydra.gnu.org (we’ll have to elucidate the bad number on berlin.)
>> I’m using ‘core-updates’ for both my system and my user profile.
>> 
>> Overall I’m in favor of merging.
>
> Me too.
>
> I've finally disabled the flaky Rust test in core-updates so it shouldn't
> nondeterministically break the build anymore.  Unfortunately that means
> it will cause some senseless rebuilds - among those icecat :(

Sounds good.  Thanks for taking care of this!

> So let's wait for those builds and then merge.

OK, hopefully that’ll be done by the end of the day.

This in turn means we could release 0.16.0 Wednesday or so (I’ll be at
the R-B Summit the next week anyway so it’d be good to get it done by
then!).

Ludo’.

Re: hg-fetch with subrepos

[Ludovic Courtès]

Hello,

Björn Höfling  skribis:

> And I stumbled upon that problem too. Ludovic explained me on IRC: The
> problem is the metadata directory ".hg": It contains metadata that is
> not fixed. For normal hg-repositories, it will be stripped away, but
> not recursively for those with sub-repos.
>
> I have a patch that works. I just wasn't sure if it goes to master or
> to staging, as it could affect the java-packages as well.

Such a patch can go to ‘master’: it won’t trigger any rebuild because,
by definition, the content hash of an ‘origin’ is known in advance
(these are “fixed-output derivations.”)

However, we should audit current uses of ‘hg-fetch’ with recursive
sub-repos because there hashes are most likely wrong already.

> I'm attaching what I have here, will prepare an official patch tonight
> or tomorrow.

Awesome.  FWIW this patch already LGTM.  :-)

Thanks,
Ludo’.

Re: 01/01: gnu: ocaml@4.01: Remove aarch64-linux from supported-systems.

[Ludovic Courtès]

Efraim Flashner  skribis:

> On Sat, Dec 01, 2018 at 05:23:32PM -0500, Mark H Weaver wrote:
>> Hi Efraim,
>> 
>> guix-comm...@gnu.org writes:
>> 
>> > efraim pushed a commit to branch master
>> > in repository guix.
>> >
>> > commit 454e7132d6fffb5c9a5ce086ffd1b687416feb83
>> > Author: Efraim Flashner 
>> > Date:   Sat Dec 1 22:41:19 2018 +0200
>> >
>> > gnu: ocaml@4.01: Remove aarch64-linux from supported-systems.
>> > 
>> > * gnu/packages/ocaml.scm (ocaml@4.01)[supported-systems]: New field.
>> 
>> What's the rationale for this change?
>> Debian includes OCaml 4.01 in its arm64 port.
>> 
>>   https://packages.debian.org/search?arch=arm64&keywords=ocaml
>>   http://http.us.debian.org/debian/pool/main/o/ocaml/ocaml_4.01.0-5_arm64.deb
>> 
>>   Mark
>
> starting phase `configure'
> ../gnu/config.guess: unable to guess system type

Would it be enough to add Automake as a native input and copy
‘config.guess’ from there?

If not, I think it’d be good to add a comment above ‘supported-systems’
explaining why we remove a specific system.

Thanks,
Ludo’.

Re: Question about Guix documentation

[Laura Lazzati]

Hi!
On Sat, Dec 1, 2018 at 2:17 PM Giovanni Biscuolo  wrote:

> happy birthday retroPC! a teenager :-)
It's not its birthday yet, but thank you ;) I just did a basic
installation, since it only has 1GB of RAM memory. But I love it and
criticizing  my retroPC is one of the things people should never do
hahahaha.

> yes please, fix that template
Thank you for the advice. And I know that if the patch is not OK, then
I can fix it if it is wrong, Even if I test it before sending it.

Regards :)
Laura

Re: hg-fetch with subrepos

[John Soo]

Thanks!

That patch looks familiar :D Looking forward to it.

John

On Sun, Dec 2, 2018 at 1:59 PM Ludovic Courtès  wrote:

> Hello,
>
> Björn Höfling  skribis:
>
> > And I stumbled upon that problem too. Ludovic explained me on IRC: The
> > problem is the metadata directory ".hg": It contains metadata that is
> > not fixed. For normal hg-repositories, it will be stripped away, but
> > not recursively for those with sub-repos.
> >
> > I have a patch that works. I just wasn't sure if it goes to master or
> > to staging, as it could affect the java-packages as well.
>
> Such a patch can go to ‘master’: it won’t trigger any rebuild because,
> by definition, the content hash of an ‘origin’ is known in advance
> (these are “fixed-output derivations.”)
>
> However, we should audit current uses of ‘hg-fetch’ with recursive
> sub-repos because there hashes are most likely wrong already.
>
> > I'm attaching what I have here, will prepare an official patch tonight
> > or tomorrow.
>
> Awesome.  FWIW this patch already LGTM.  :-)
>
> Thanks,
> Ludo’.
>

Re: Guile-JSON now seems to be a required dependency

[Joshua Branson]

Timothy Sample  writes:

> Hi Eric,
>
> Eric Bavier  writes:
>
>> On Fri, 30 Nov 2018 23:45:04 -0500
>> Timothy Sample  wrote:
>>
>>> Hello all,
>>>
>>> I just tried to build Guix from source and got an error:
>>>
>>> ERROR: no code for module (json)
>>>
>>> It looks like the new “swh.scm” module (which is really cool!) makes
>>> Guile-JSON a required dependency.  I’m not sure if this is intentional.
>>> If it is, the “Requirements” section of the manual needs an update.
>>
>> Yes, we decided to make it a hard requirement.  I'm working on a patch
>> to follow through.

I believe I created such a patch.

>From 2d860d1889b6c4bafe3d605ee47f9c93c3e91091 Mon Sep 17 00:00:00 2001
From: Joshua Branson 
Date: Sat, 1 Dec 2018 08:36:20 -0500
Subject: [PATCH] Adding guile-json as a required dependency for swh.scm. I
 also alphabetized the requirements.

---
 doc/guix.texi | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index fff5dfe0b..e651c3617 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -643,15 +643,17 @@ later, including 2.2.x;
 @item @url{https://notabug.org/cwebber/guile-gcrypt, Guile-Gcrypt}, version
 0.1.0 or later;
 @item
-@uref{http://gnutls.org/, GnuTLS}, specifically its Guile bindings
-(@pxref{Guile Preparations, how to install the GnuTLS bindings for
-Guile,, gnutls-guile, GnuTLS-Guile});
+@c FIXME: Specify a version number once a release has been made.
+@uref{https://gitlab.com/guile-git/guile-git, Guile-Git}, from August
+@item @url{https://github.com/aconchillo/guile-json, Guile-JSON}, version
+1.2.0 or later;
 @item
 @uref{https://notabug.org/guile-sqlite3/guile-sqlite3, Guile-SQLite3}, version 0.1.0
 or later;
 @item
-@c FIXME: Specify a version number once a release has been made.
-@uref{https://gitlab.com/guile-git/guile-git, Guile-Git}, from August
+@uref{http://gnutls.org/, GnuTLS}, specifically its Guile bindings
+(@pxref{Guile Preparations, how to install the GnuTLS bindings for
+Guile,, gnutls-guile, GnuTLS-Guile});
 2017 or later;
 @item @url{http://zlib.net, zlib};
 @item @url{http://www.gnu.org/software/make/, GNU Make}.
-- 
2.19.2



>
> That’s good to know.  Thanks very much for your work.  :)
>
>> `~Eric
>
> -- Tim

Re: Octave & QtOctave

[Kei Kebreau]

swedebugia  writes:

> On 2018-11-28 11:47, Ludovic Courtès wrote:
>> Kei Kebreau  skribis:
> snip
>
>>>
>>> I agree with ng0 that Octave and its GUI interface should be kept in
>>> separate packages, as the difference in size is more than 5000 MiB.
>>> I also agree that the GUI package should be named "octave", but I don't
>>> know whether the CLI package should be named "octave-minimal" or
>>> "octave-cli".  I find myself leaning toward "octave-cli" because the CLI
>>> package does include some non-essential dependencies.
>>
>> Makes sense to me.  If others agree with this (“octave-cli” rather than
>> “octave-minimal”), go ahead!
>
> I agree.

Here are two tentative patches that make the changes we've discussed.
Also, should we make a deprecated-package definition for qtoctave?

>From f31adbdaa5582e1c2d02adc2e7fc6afa2fc6e171 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sat, 1 Dec 2018 23:15:14 -0500
Subject: [PATCH 1/2] gnu: Rename "octave" to "octave-cli".

* gnu/packages/maths.scm (octave): Rename to...
(octave-cli): ...this.
[name]: Change to "octave-cli".
(qtoctave): Inherit from octave-cli.
(flann)[inputs]: Adjust accordingly.
* gnu/packages/engineering.scm (qucs)[inputs]: Likewise.
(qucs-s)[inputs]: Likewise.
* gnu/packages/machine-learning.scm (shogun)[inputs]: Likewise.
---
 gnu/packages/engineering.scm  |  4 ++--
 gnu/packages/machine-learning.scm |  2 +-
 gnu/packages/maths.scm| 16 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index 008035649..761cc1282 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -1702,7 +1702,7 @@ parallel computing platforms.  It also supports serial execution.")
  ("gcc-toolchain" ,gcc-toolchain)
  ("iverilog" ,iverilog)
  ("libtool" ,libtool)
- ("octave" ,octave)
+ ("octave" ,octave-cli)
  ("qt4" ,qt-4)
  ("sed" ,sed)))
   (home-page "http://qucs.sourceforge.net/";)
@@ -1832,7 +1832,7 @@ simulations are also supported.")
("libtool" ,libtool)
("mpi" ,openmpi)
("ngspice" ,ngspice)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("qt4" ,qt-4)
("qucs" ,qucs)
("sed" ,sed)
diff --git a/gnu/packages/machine-learning.scm b/gnu/packages/machine-learning.scm
index a7df9dce0..c4a25eabd 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -493,7 +493,7 @@ sample proximities between pairs of cases.")
  `(("python" ,python)
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("swig" ,swig)
("eigen" ,eigen)
("hdf5" ,hdf5)
diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 3dabef441..bcd70232f 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1413,9 +1413,9 @@ can solve two kinds of problems:
 
 ;; For a fully featured Octave, users are strongly recommended also to install
 ;; the following packages: less, ghostscript, gnuplot.
-(define-public octave
+(define-public octave-cli
   (package
-(name "octave")
+(name "octave-cli")
 (version "4.4.1")
 (source
  (origin
@@ -1498,20 +1498,20 @@ script files.")
 (license license:gpl3+)))
 
 (define-public qtoctave
-  (package (inherit octave)
+  (package (inherit octave-cli)
 (name "qtoctave")
 (source (origin
-  (inherit (package-source octave
+  (inherit (package-source octave-cli
 (inputs
  `(("qscintilla" ,qscintilla)
("qt" ,qtbase)
-   ,@(package-inputs octave)))
+   ,@(package-inputs octave-cli)))
 (native-inputs
  `(("qttools" , qttools) ;for lrelease
("texlive" ,texlive) ;for texi2dvi
-   ,@(package-native-inputs octave)))
+   ,@(package-native-inputs octave-cli)))
 (arguments
- (substitute-keyword-arguments (package-arguments octave)
+ (substitute-keyword-arguments (package-arguments octave-cli)
((#:phases phases)
 `(modify-phases ,phases
(add-before 'configure 'patch-qscintilla-library-name
@@ -3577,7 +3577,7 @@ in finite element programs.")
  `(("unzip" ,unzip)))
 (inputs
  `(("hdf5" ,hdf5)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("python" ,python-2) ; print syntax
;; ("python2-numpy" ,python2-numpy) ; only required for the tests
("zlib" ,zlib)))
-- 
2.19.2

>From 2cdaf3cbc1c611acae606af47479eb14c479153e Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sat, 1 Dec 2018 23:37:50 -0500
Subject: [PATCH 2/2] gnu: Rename "qtoctave" to "octave".

* gnu/packages/maths.scm (qtoctave): Rename to...
(octave): ...this.
[name]: Change to "octave".
---
 gnu/packages/maths.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index bcd70232f..8b1

Re: Octave & QtOctave

[Kei Kebreau]

l...@gnu.org (Ludovic Courtès) writes:

> Kei Kebreau  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hello,
>>>
>>> n...@n0.is skribis:
>>>
 names for packages are (mostly) random, although in some
 cases following classiifcations (see python-*, r-*, ...).
>>>
>>> That randomness is very limited in practice, if I may.  :-)
>>>
>>>   https://gnu.org/software/guix/manual/en/html_node/Package-Naming.html
>>>
>>> “qtoctave” was added by Kei.  WDYT about the naming issue, Kei?
>>>
>>> Ludo’.
>>
>> I agree with ng0 that Octave and its GUI interface should be kept in
>> separate packages, as the difference in size is more than 5000 MiB.
>> I also agree that the GUI package should be named "octave", but I don't
>> know whether the CLI package should be named "octave-minimal" or
>> "octave-cli".  I find myself leaning toward "octave-cli" because the CLI
>> package does include some non-essential dependencies.
>
> Makes sense to me.  If others agree with this (“octave-cli” rather than
> “octave-minimal”), go ahead!
>
> Ludo’.

Sorry, the last message didn't include the earlier contributors to this
thread.

Here are two tentative patches that make the changes we've discussed.
Also, should we make a deprecated-package definition for qtoctave?

>From f31adbdaa5582e1c2d02adc2e7fc6afa2fc6e171 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sat, 1 Dec 2018 23:15:14 -0500
Subject: [PATCH 1/2] gnu: Rename "octave" to "octave-cli".

* gnu/packages/maths.scm (octave): Rename to...
(octave-cli): ...this.
[name]: Change to "octave-cli".
(qtoctave): Inherit from octave-cli.
(flann)[inputs]: Adjust accordingly.
* gnu/packages/engineering.scm (qucs)[inputs]: Likewise.
(qucs-s)[inputs]: Likewise.
* gnu/packages/machine-learning.scm (shogun)[inputs]: Likewise.
---
 gnu/packages/engineering.scm  |  4 ++--
 gnu/packages/machine-learning.scm |  2 +-
 gnu/packages/maths.scm| 16 
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/engineering.scm b/gnu/packages/engineering.scm
index 008035649..761cc1282 100644
--- a/gnu/packages/engineering.scm
+++ b/gnu/packages/engineering.scm
@@ -1702,7 +1702,7 @@ parallel computing platforms.  It also supports serial execution.")
  ("gcc-toolchain" ,gcc-toolchain)
  ("iverilog" ,iverilog)
  ("libtool" ,libtool)
- ("octave" ,octave)
+ ("octave" ,octave-cli)
  ("qt4" ,qt-4)
  ("sed" ,sed)))
   (home-page "http://qucs.sourceforge.net/";)
@@ -1832,7 +1832,7 @@ simulations are also supported.")
("libtool" ,libtool)
("mpi" ,openmpi)
("ngspice" ,ngspice)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("qt4" ,qt-4)
("qucs" ,qucs)
("sed" ,sed)
diff --git a/gnu/packages/machine-learning.scm b/gnu/packages/machine-learning.scm
index a7df9dce0..c4a25eabd 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -493,7 +493,7 @@ sample proximities between pairs of cases.")
  `(("python" ,python)
("numpy" ,python-numpy)
("r-minimal" ,r-minimal)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("swig" ,swig)
("eigen" ,eigen)
("hdf5" ,hdf5)
diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 3dabef441..bcd70232f 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1413,9 +1413,9 @@ can solve two kinds of problems:
 
 ;; For a fully featured Octave, users are strongly recommended also to install
 ;; the following packages: less, ghostscript, gnuplot.
-(define-public octave
+(define-public octave-cli
   (package
-(name "octave")
+(name "octave-cli")
 (version "4.4.1")
 (source
  (origin
@@ -1498,20 +1498,20 @@ script files.")
 (license license:gpl3+)))
 
 (define-public qtoctave
-  (package (inherit octave)
+  (package (inherit octave-cli)
 (name "qtoctave")
 (source (origin
-  (inherit (package-source octave
+  (inherit (package-source octave-cli
 (inputs
  `(("qscintilla" ,qscintilla)
("qt" ,qtbase)
-   ,@(package-inputs octave)))
+   ,@(package-inputs octave-cli)))
 (native-inputs
  `(("qttools" , qttools) ;for lrelease
("texlive" ,texlive) ;for texi2dvi
-   ,@(package-native-inputs octave)))
+   ,@(package-native-inputs octave-cli)))
 (arguments
- (substitute-keyword-arguments (package-arguments octave)
+ (substitute-keyword-arguments (package-arguments octave-cli)
((#:phases phases)
 `(modify-phases ,phases
(add-before 'configure 'patch-qscintilla-library-name
@@ -3577,7 +3577,7 @@ in finite element programs.")
  `(("unzip" ,unzip)))
 (inputs
  `(("hdf5" ,hdf5)
-   ("octave" ,octave)
+   ("octave" ,octave-cli)
("python" ,python-2) ; print syntax
;; ("python2-numpy" ,python2-numpy) ; only required for the tests
  

Re: Generated patches change over time

[Maxim Cournoyer]

l...@gnu.org (Ludovic Courtès) writes:

[...]

> You’re right, along the same lines, it could be a fixed-output
> derivation.
>
> The problem is rather that the workflow would be a bit awkward: ‘guix
> download’ would download the raw, unprocessed patch, and thus it would
> give you the “wrong” hash.
>
> In essence you’d have to put a random hash in your package definition,
> run “guix build -S”, copy the correct hash from the error message,
> manually look at the patch, etc.
>
> It’s possible, but it’s a bit awkward IMO.
>
> Or we would need to add a ‘--strip-patch-metadata’ option to ‘guix
> download’ so that it applies the exact same transformation when
> downloading.

The way I see it, `guix download' should just do the right thing -- the
metadata stripping should be baked in and not user
controllable. Alternatively, it could be controllable, but enabled by
default. This would keep the workflow the same as it is now.

Maxim

Re: Generated patches change over time

[Mark H Weaver]

Maxim Cournoyer  writes:

> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>> You’re right, along the same lines, it could be a fixed-output
>> derivation.
>>
>> The problem is rather that the workflow would be a bit awkward: ‘guix
>> download’ would download the raw, unprocessed patch, and thus it would
>> give you the “wrong” hash.
>>
>> In essence you’d have to put a random hash in your package definition,
>> run “guix build -S”, copy the correct hash from the error message,
>> manually look at the patch, etc.
>>
>> It’s possible, but it’s a bit awkward IMO.
>>
>> Or we would need to add a ‘--strip-patch-metadata’ option to ‘guix
>> download’ so that it applies the exact same transformation when
>> downloading.
>
> The way I see it, `guix download' should just do the right thing -- the
> metadata stripping should be baked in and not user
> controllable. Alternatively, it could be controllable, but enabled by
> default. This would keep the workflow the same as it is now.

I *certainly* don't want "guix download" to try to automatically detect
that the downloaded file contains a patch, after some possibly
nontrivial amount of plain text which is typically present in patch
files, and to canonicalize the patch in that case.

However, we could add an optional flag to "guix download", or perhaps
add another 'guix' subcommand, to request the use of a specific 'origin'
type.  In addition to supporting canonicalized patches, this could also
improve the workflow for other origin types such as 'git-fetch' and
'hg-fetch'.

In general, the specified 'origin' type would determine the number and
meaning of the arguments, e.g. for 'git-fetch' an additional commit
argument would be needed.

Thoughts?

  Mark

Re: 01/01: gnu: ocaml@4.01: Remove aarch64-linux from supported-systems.

[Mark H Weaver]

l...@gnu.org (Ludovic Courtès) writes:

> Efraim Flashner  skribis:
>
>> On Sat, Dec 01, 2018 at 05:23:32PM -0500, Mark H Weaver wrote:
>>> Hi Efraim,
>>> 
>>> guix-comm...@gnu.org writes:
>>> 
>>> > efraim pushed a commit to branch master
>>> > in repository guix.
>>> >
>>> > commit 454e7132d6fffb5c9a5ce086ffd1b687416feb83
>>> > Author: Efraim Flashner 
>>> > Date:   Sat Dec 1 22:41:19 2018 +0200
>>> >
>>> > gnu: ocaml@4.01: Remove aarch64-linux from supported-systems.
>>> > 
>>> > * gnu/packages/ocaml.scm (ocaml@4.01)[supported-systems]: New field.
>>> 
>>> What's the rationale for this change?
>>> Debian includes OCaml 4.01 in its arm64 port.
>>> 
>>>   https://packages.debian.org/search?arch=arm64&keywords=ocaml
>>>   
>>> http://http.us.debian.org/debian/pool/main/o/ocaml/ocaml_4.01.0-5_arm64.deb
>>> 
>>>   Mark
>>
>> starting phase `configure'
>> ../gnu/config.guess: unable to guess system type
>
> Would it be enough to add Automake as a native input and copy
> ‘config.guess’ from there?

Ideally, we shouldn't need 'config.guess' at all.  Normally, it is only
used if the GNU triplet is not explicitly passed to ./configure.  A few
years ago, I fixed most instances of this problem by unconditionally
passing --build= to ./configure in the default 'configure'
phase of gnu-build-system.

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=3c7d023d6458669c6bfa23bc85e098c91f699892

However, our OCaml package has a custom 'configure' phase that does not
pass --build.  I'm not sure if that's because OCaml's configure phase
doesn't support --build, or if it was omitted because it's not typically
needed on x86_64.

* * *

Anyway, more generally, I hope that we will not get in the habit of
simply removing systems from 'supported-systems' when builds fail on
those systems, without investigating and concluding that it would be
prohibitively difficult to support the software on that system.

To my mind, it's *good* to see failed builds on other architectures, to
be reminded of bugs on non-x86_64 systems that should be fixed.  When we
remove systems from 'supported-systems' without good reason, this is
somewhat analogous to deleting unfixed bug reports.

What do you think?

  Mark

Re: Octave & QtOctave

[swedebugia]

On 2018-12-02 20:28, Kei Kebreau wrote:
snip


Here are two tentative patches that make the changes we've discussed.


Nice


Also, should we make a deprecated-package definition for qtoctave?


Yes, that sounds like a good idea to me.

--
Cheers
Swedebugia

Re: Question about Guix documentation

[swedebugia]

On 2018-12-02 16:05, Laura Lazzati wrote:

Hi!
On Sat, Dec 1, 2018 at 2:17 PM Giovanni Biscuolo  wrote:


happy birthday retroPC! a teenager :-)

It's not its birthday yet, but thank you ;) I just did a basic
installation, since it only has 1GB of RAM memory. But I love it and
criticizing  my retroPC is one of the things people should never do
hahahaha.


1GB of RAM? That is a *lot* :)
I have 2 GB on my 2 day-to-day laptops. 1 with GNOME3 GuixSD and 1 with 
Parabola+MATE. Both work fine and I rarely have to wait for other 
programs than the really heavy ones (Libreoffice comes to mind).


I choose light programs: mpv, mpsyt, generally console programs over gui 
if possible and suitable.


A friend of mine have a 4-core Samsung with 8 GB RAM and GNOME3 and I 
feel no big difference compared to my laptop (besides when compiling of 
course)


If you configure a good size swapfile or partition you will probably 
have no trouble running X11 and a light desktop manager (i.e. anything 
besides GNOME3). (I admit I did not actually check GNOME3 on a 1 GB RAM 
PC).


I would say it is possible to configure a desktop system to run smoothly 
with anything above 512MB RAM and 1-2 Ghz 1 core processor. (in 2003 I 
started out with GNU/Linux on a 350Mhz with 512MB RAM with no problems 
besides playing DVDs which caused glitches during playback because the 
processor could not keep up)

--
Cheers
Swedebugia

Re: Guile-JSON now seems to be a required dependency

[Ludovic Courtès]

Hello,

Joshua Branson  skribis:

> Timothy Sample  writes:
>
>> Hi Eric,
>>
>> Eric Bavier  writes:

[...]

>>> Yes, we decided to make it a hard requirement.  I'm working on a patch
>>> to follow through.
>
> I believe I created such a patch.

Eric, could you consider merging your patch with Joshua’s?  Making
Guile-JSON a hard dependency takes more than updating guix.texi, though.

Thanks to both of you,
Ludo’.

Re: Guile-JSON now seems to be a required dependency

[Eric Bavier]

On Sun, 02 Dec 2018 22:59:47 +0100
l...@gnu.org (Ludovic Courtès) wrote:

> Hello,
> 
> Joshua Branson  skribis:
> 
> > Timothy Sample  writes:
> >  
> >> Hi Eric,
> >>
> >> Eric Bavier  writes:  
> 
> [...]
> 
> >>> Yes, we decided to make it a hard requirement.  I'm working on a patch
> >>> to follow through.  
> >
> > I believe I created such a patch.  
> 
> Eric, could you consider merging your patch with Joshua’s?  Making
> Guile-JSON a hard dependency takes more than updating guix.texi, though.

Here's an updated patch.

I think this takes care of everything.  Most of the conditional-loading
logic in modules has been removed/factored/superseded already.

`~Eric
From 48c22f503493a4406758e91844d3708fe5f88864 Mon Sep 17 00:00:00 2001
From: Eric Bavier 
Date: Sat, 1 Dec 2018 20:46:22 -0600
Subject: [PATCH] Make Guile-JSON a required dependency.

* README (Requirements): Remove "optional" verbiage.
* doc/guix.texi (Requirements): Move Guile-JSON from optional to required.
* configure.ac (HAVE_GUILE_JSON): Remove Automake conditional.
(have_guile_json): Error if not "yes".
* Makefile.am (MODULE, SCM_TESTS)[HAVE_GUILE_JSON]: Add modules and tests
unconditionally.
* gnu/packages/package-mangement.scm (guix-minimal)[propagated-inputs]: Leave
guile-json input.
---
 Makefile.am | 72 -
 README  |  2 +-
 configure.ac|  6 ++-
 doc/guix.texi   |  9 +---
 gnu/packages/package-management.scm |  2 +-
 5 files changed, 37 insertions(+), 54 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e14ac57f2..32cebd591 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -62,7 +62,9 @@ MODULES =	\
   guix/base16.scm\
   guix/base32.scm\
   guix/base64.scm\
+  guix/ci.scm	\
   guix/cpio.scm	\
+  guix/docker.scm	   			\
   guix/records.scm\
   guix/pki.scm	\
   guix/progress.scm\
@@ -186,15 +188,24 @@ MODULES =	\
   guix/build/make-bootstrap.scm			\
   guix/search-paths.scm\
   guix/packages.scm\
-  guix/import/print.scm\
-  guix/import/utils.scm\
-  guix/import/gnu.scm\
-  guix/import/snix.scm\
   guix/import/cabal.scm\
+  guix/import/cpan.scm\
   guix/import/cran.scm\
-  guix/import/hackage.scm			\
+  guix/import/crate.scm\
   guix/import/elpa.scm   			\
+  guix/import/gem.scm\
+  guix/import/github.scm   			\
+  guix/import/gnome.scm\
+  guix/import/gnu.scm\
+  guix/import/hackage.scm			\
+  guix/import/json.scm\
+  guix/import/opam.scm\
+  guix/import/print.scm\
+  guix/import/pypi.scm\
+  guix/import/snix.scm\
+  guix/import/stackage.scm			\
   guix/import/texlive.scm   			\
+  guix/import/utils.scm\
   guix/scripts.scm\
   guix/scripts/download.scm			\
   guix/scripts/perform-download.scm		\
@@ -216,46 +227,29 @@ MODULES =	\
   guix/scripts/system/search.scm		\
   guix/scripts/lint.scm\
   guix/scripts/challenge.scm			\
+  guix/scripts/import/crate.scm			\
   guix/scripts/import/cran.scm			\
+  guix/scripts/import/elpa.scm  		\
+  guix/scripts/import/gem.scm			\
   guix/scripts/import/gnu.scm			\
-  guix/scripts/import/nix.scm			\
   guix/scripts/import/hackage.scm		\
-  guix/scripts/import/elpa.scm  		\
+  guix/scripts/import/json.scm  		\
+  guix/scripts/import/nix.scm			\
+  guix/scripts/import/opam.scm			\
+  guix/scripts/import/pypi.scm			\
+  guix/scripts/import/stackage.scm		\
   guix/scripts/import/texlive.scm  		\
   guix/scripts/environment.scm			\
   guix/scripts/publish.scm			\
   guix/scripts/edit.scm\
   guix/scripts/size.scm\
   guix/scripts/graph.scm			\
+  guix/scripts/weather.scm			\
   guix/scripts/container.scm			\
   guix/scripts/container/exec.scm		\
   guix.scm	\
   $(GNU_SYSTEM_MODULES)
 
-if HAVE_GUILE_JSON
-
-MODULES +=	\
-  guix/ci.scm	\
-  guix/docker.scm	   			\
-  guix/import/cpan.scm\
-  guix/import/crate.scm\
-  guix/import/gem.scm\
-  guix/import/github.scm   			\
-  guix/import/gnome.scm\
-  guix/import/json.scm\
-  guix/import/opam.scm\
-  guix/import/pypi.scm\
-  guix/import/stackage.scm			\
-  guix/scripts/import/crate.scm			\
-  guix/scripts/import/gem.scm			\
-  guix/scripts/import/json.scm  		\
-  guix/scripts/import/opam.scm			\
-  guix/scripts/import/pypi.scm			\
-  guix/scripts/import/stackage.scm		\
-  guix/scripts/weather.scm
-
-endif
-
 if HAVE_GUILE_SSH
 
 MODULES +=	\
@@ -335,7 +329,10 @@ SCM_TESTS =	\
   tests/base16.scm\
   tests/base32.scm\
   tests/base64.scm\
+  tests/cpan.scm\
   tests/cpio.scm\
+  tests/crate.scm\
+  tests/gem.scm	\
   tests/pki.scm	\
   tests/print.scm\
   tests/sets.scm\
@@ -389,22 +386,13 @@ SCM_TESTS =	\
   tests/services.scm\
   tests/scripts-build.scm			\
   tests/containers.scm\
+  tests/opam.scm\
   tests/pack.scm\
+  tests/pypi.scm\
   tests/import-utils.scm			\
   tests/store-d

Re: Dual Boot GuixSd along side other preexisting distros

[Chris Marusich]

Tomáš Čech  writes:

> In my system configuration I have this hack I found somewhere:
>
> (bootloader
>  (bootloader-configuration
>   (bootloader
>(bootloader
> (inherit grub-bootloader) (installer #~(const #t))
>
> so it doesn't install bootloader at all.

FYI, the --no-bootloader option to "guix system" should prevent Guix
from installing a bootloader.  You might find that useful.

-- 
Chris


signature.asc
Description: PGP signature

Re: [bug#33572] Guile-JSON now seems to be a required dependency

[Eric Bavier]

On Sun, 2 Dec 2018 16:22:25 -0600
Eric Bavier  wrote:

> On Sun, 02 Dec 2018 22:59:47 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
> 
> > Hello,
> > 
> > Joshua Branson  skribis:
> > 
> > > Timothy Sample  writes:
> > >  
> > >> Hi Eric,
> > >>
> > >> Eric Bavier  writes:  
> > 
> > [...]
> > 
> > >>> Yes, we decided to make it a hard requirement.  I'm working on a patch
> > >>> to follow through.  
> > >
> > > I believe I created such a patch.  
> > 
> > Eric, could you consider merging your patch with Joshua’s?  Making
> > Guile-JSON a hard dependency takes more than updating guix.texi, though.
> 
> Here's an updated patch.

Oops, messed up the texinfo formatting; this patch is better.

`~Eric
From 5f04eb187de528f5879bd84901f71dba13c68f43 Mon Sep 17 00:00:00 2001
From: Eric Bavier 
Date: Sat, 1 Dec 2018 20:46:22 -0600
Subject: [PATCH] Make Guile-JSON a required dependency.

* README (Requirements): Remove "optional" verbiage.
* doc/guix.texi (Requirements): Move Guile-JSON from optional to required.
* configure.ac (HAVE_GUILE_JSON): Remove Automake conditional.
(have_guile_json): Error if not "yes".
* Makefile.am (MODULE, SCM_TESTS)[HAVE_GUILE_JSON]: Add modules and tests
unconditionally.
* gnu/packages/package-mangement.scm (guix-minimal)[propagated-inputs]: Leave
guile-json input.
---
 Makefile.am | 72 -
 README  |  2 +-
 configure.ac|  6 ++-
 doc/guix.texi   |  8 +---
 gnu/packages/package-management.scm |  2 +-
 5 files changed, 37 insertions(+), 53 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e14ac57f2..32cebd591 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -62,7 +62,9 @@ MODULES =	\
   guix/base16.scm\
   guix/base32.scm\
   guix/base64.scm\
+  guix/ci.scm	\
   guix/cpio.scm	\
+  guix/docker.scm	   			\
   guix/records.scm\
   guix/pki.scm	\
   guix/progress.scm\
@@ -186,15 +188,24 @@ MODULES =	\
   guix/build/make-bootstrap.scm			\
   guix/search-paths.scm\
   guix/packages.scm\
-  guix/import/print.scm\
-  guix/import/utils.scm\
-  guix/import/gnu.scm\
-  guix/import/snix.scm\
   guix/import/cabal.scm\
+  guix/import/cpan.scm\
   guix/import/cran.scm\
-  guix/import/hackage.scm			\
+  guix/import/crate.scm\
   guix/import/elpa.scm   			\
+  guix/import/gem.scm\
+  guix/import/github.scm   			\
+  guix/import/gnome.scm\
+  guix/import/gnu.scm\
+  guix/import/hackage.scm			\
+  guix/import/json.scm\
+  guix/import/opam.scm\
+  guix/import/print.scm\
+  guix/import/pypi.scm\
+  guix/import/snix.scm\
+  guix/import/stackage.scm			\
   guix/import/texlive.scm   			\
+  guix/import/utils.scm\
   guix/scripts.scm\
   guix/scripts/download.scm			\
   guix/scripts/perform-download.scm		\
@@ -216,46 +227,29 @@ MODULES =	\
   guix/scripts/system/search.scm		\
   guix/scripts/lint.scm\
   guix/scripts/challenge.scm			\
+  guix/scripts/import/crate.scm			\
   guix/scripts/import/cran.scm			\
+  guix/scripts/import/elpa.scm  		\
+  guix/scripts/import/gem.scm			\
   guix/scripts/import/gnu.scm			\
-  guix/scripts/import/nix.scm			\
   guix/scripts/import/hackage.scm		\
-  guix/scripts/import/elpa.scm  		\
+  guix/scripts/import/json.scm  		\
+  guix/scripts/import/nix.scm			\
+  guix/scripts/import/opam.scm			\
+  guix/scripts/import/pypi.scm			\
+  guix/scripts/import/stackage.scm		\
   guix/scripts/import/texlive.scm  		\
   guix/scripts/environment.scm			\
   guix/scripts/publish.scm			\
   guix/scripts/edit.scm\
   guix/scripts/size.scm\
   guix/scripts/graph.scm			\
+  guix/scripts/weather.scm			\
   guix/scripts/container.scm			\
   guix/scripts/container/exec.scm		\
   guix.scm	\
   $(GNU_SYSTEM_MODULES)
 
-if HAVE_GUILE_JSON
-
-MODULES +=	\
-  guix/ci.scm	\
-  guix/docker.scm	   			\
-  guix/import/cpan.scm\
-  guix/import/crate.scm\
-  guix/import/gem.scm\
-  guix/import/github.scm   			\
-  guix/import/gnome.scm\
-  guix/import/json.scm\
-  guix/import/opam.scm\
-  guix/import/pypi.scm\
-  guix/import/stackage.scm			\
-  guix/scripts/import/crate.scm			\
-  guix/scripts/import/gem.scm			\
-  guix/scripts/import/json.scm  		\
-  guix/scripts/import/opam.scm			\
-  guix/scripts/import/pypi.scm			\
-  guix/scripts/import/stackage.scm		\
-  guix/scripts/weather.scm
-
-endif
-
 if HAVE_GUILE_SSH
 
 MODULES +=	\
@@ -335,7 +329,10 @@ SCM_TESTS =	\
   tests/base16.scm\
   tests/base32.scm\
   tests/base64.scm\
+  tests/cpan.scm\
   tests/cpio.scm\
+  tests/crate.scm\
+  tests/gem.scm	\
   tests/pki.scm	\
   tests/print.scm\
   tests/sets.scm\
@@ -389,22 +386,13 @@ SCM_TESTS =	\
   tests/services.scm\
   tests/scripts-build.scm			\
   tests/containers.scm\
+  tests/opam.scm\
   tests/pack.scm\
+  tests/pypi.scm\
   tests/import-

Re: Patchwork + automated checking and testing of patches

[Chris Marusich]

Hi Chris,

This is really cool stuff!  Thanks for looking into it.

Christopher Baines  writes:

> I don't intend to do anything with Jenkins, as I think that wouldn't be
> maintainable, but I think setting up some system to check some of the
> following would be beneficial:

I'm actually a little hesitant to ask, since I don't have time to
contribute to this right now, and I don't want to bike-shed.  However,
I'm just curious: why do you think using Jenkins wouldn't be
maintainable?  I've read about Jenkins but haven't used it personally,
and I've heard good things about it, so I'm curious to know why you
prefer to avoid it entirely.

-- 
Chris


signature.asc
Description: PGP signature

Re: Dual Boot GuixSd along side other preexisting distros

[Joshua Branson]

Chris Marusich  writes:

> Tomáš Čech  writes:
>
>> In my system configuration I have this hack I found somewhere:
>>
>> (bootloader
>>  (bootloader-configuration
>>   (bootloader
>>(bootloader
>> (inherit grub-bootloader) (installer #~(const #t))
>>
>> so it doesn't install bootloader at all.
>
> FYI, the --no-bootloader option to "guix system" should prevent Guix
> from installing a bootloader.  You might find that useful.

I personally found it more useful to have GuixSD manage my grub.  And
code in my config the other boot option.  That way GuixSD generated the
grub booting for both GuixSD and the other distro.

Re: Question about Guix documentation

[Laura Lazzati]

> 1GB of RAM? That is a *lot* :)
> I have 2 GB on my 2 day-to-day laptops. 1 with GNOME3 GuixSD and 1 with
> Parabola+MATE. Both work fine and I rarely have to wait for other
> programs than the really heavy ones (Libreoffice comes to mind).
Oh no! my retroPC is fancy :O and I did not know :) I was going to add
that I did almost up to 4th year of university with it but felt
ashamed. I guess you know where the name  MATE comes from ;), it is at
the end of the site. I will check the processor. because I don't
remember how many cores it has.
And send the patch, of course.

Regards :)

Re: Patchwork + automated checking and testing of patches

[Christopher Baines]

Chris Marusich  writes:

> Hi Chris,
>
> This is really cool stuff!  Thanks for looking into it.
>
> Christopher Baines  writes:
>
>> I don't intend to do anything with Jenkins, as I think that wouldn't be
>> maintainable, but I think setting up some system to check some of the
>> following would be beneficial:
>
> I'm actually a little hesitant to ask, since I don't have time to
> contribute to this right now, and I don't want to bike-shed.  However,
> I'm just curious: why do you think using Jenkins wouldn't be
> maintainable?  I've read about Jenkins but haven't used it personally,
> and I've heard good things about it, so I'm curious to know why you
> prefer to avoid it entirely.

Sure, I've used Jenkins in different contexts, and indeed currently use
Jenkins, so I've got some experience here.

I'm obviously ignoring all the good parts here, but one source of data
is Debian. It used to have a package for Jenkins, and you can see some
of the work/issues here [1] and the thread about it's removal here [2].

One issue in particular to call out is some potential bootstrapping
issues [3] that seem to have been encountered.

It seems sensible to me to use Guix when doing things related to the
Guix project, like automated testing of patches (dogfooding, if you know
the term). Some of the things I've mentioned here lead me to doubt that
Jenkins will at some point be available through Guix.

So that's something about the maintainability of a Guix package, but
there's an operational component to this as well. The attack surface it
offers is maybe larger than sometimes necessary, if you only need a
read-only web interface for example.

1:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=unstable;ordering=normal;repeatmerged=0;src=jenkins
2: https://lists.debian.org/debian-java/2016/01/msg00019.html
3: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714596


signature.asc
Description: PGP signature

Re: Octave & QtOctave

[Kei Kebreau]

swedebugia  writes:

> On 2018-12-02 20:28, Kei Kebreau wrote:
> snip
>
>> Here are two tentative patches that make the changes we've discussed.
>
> Nice
>
>> Also, should we make a deprecated-package definition for qtoctave?
>
> Yes, that sounds like a good idea to me.

Here's the new second patch, then.

>From 663441af034b6bd7a3bd24866d3721cac21be221 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sat, 1 Dec 2018 23:37:50 -0500
Subject: [PATCH 2/2] gnu: Rename "qtoctave" to "octave".

* gnu/packages/maths.scm (qtoctave): Define in terms of 'deprectated-package'.
(octave): New variable, formerly known as "qtoctave".
---
 gnu/packages/maths.scm | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index bcd70232f..67be8b807 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1497,9 +1497,9 @@ Work may be performed both at the interactive command-line as well as via
 script files.")
 (license license:gpl3+)))
 
-(define-public qtoctave
+(define-public octave
   (package (inherit octave-cli)
-(name "qtoctave")
+(name "octave")
 (source (origin
   (inherit (package-source octave-cli
 (inputs
@@ -1525,6 +1525,9 @@ script files.")
   "qscintilla2_qt5"))
#t
 
+(define-public qtoctave
+  (deprecated-package "qtoctave" octave))
+
 (define-public opencascade-oce
   (package
 (name "opencascade-oce")
-- 
2.19.2