Re: Removing the need for ./configure --localstatedir=/var ?

[Efraim Flashner]

On Thu, Sep 07, 2017 at 12:02:43PM -0500, Christopher Allan Webber wrote:
> Every now and then I rebuild Guix and hit the problem where I run
> ./configure and then I am reminded that I need to instead do:
> 
>   ./configure --localstatedir=/var
> 
> IIRC this is because of GNU standards about default paths and pretty
> much no other reason that we don't default to /var.  But I think Guix is
> a special case.
> 
> Should we ask maybe for an exception?  There's no reason for users to
> bump into this.  It's annoying even for me, and at least I know (or
> think I do) why.
> 
>  - Chris
> 

I've made sure to also pass --sysconfdir=/etc so that /etc/guix/acl
doesn't end up in /usr/local/etc/guix/acl, leading to a split between
`guix foo' and './pre-inst-env guix foo'.

-- 
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

blis

[Efraim Flashner]

I admit, looking at the commit, I'm a little jealous that there wasn't
an aarch64 special version. I checked in $repo/config¹ and there's a
config folder for armv7a, armv8a and longsoon3a, among other options. It
might be worth having some of these be the default option for these
platforms, since it should overlap with our supported architectures.

On the other hand, armv8a's make_defs.mk specify a BIG.little (or is
that big.LITTLE?) configuration of A57 + A53. I know some of my boards
are A53 only so I don't know how that works.

The default armv7a looks harmless, although there are options for using
an A9 or A15 specifically.


¹ https://github.com/flame/blis/tree/0.2.2/config

-- 
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

Re: Guix - installation script

[Christopher Baines]

On Thu, 7 Sep 2017 19:11:58 +0100
Hellseher  wrote:

> Hi,
> 
> Sorry for delayed replay, it's busy time at work/home.

No problem :)

> I'll check and fix it as soon as possibly, but you always can pull 
> request it on a GitHub.
> 
> You also mentioned to send it to guix-devel@gnu.org, which format do
> you prefer?

A patch produced by Git. There are a few ways of doing this, e.g. `git
format-patch`, or `git send-email`.

What I'd recommend is cloning the guix repository, putting the install
script in to the scripts/ directory (this might not be the best place,
but its a good start), and then commiting. You should then be able to
run `git format-patch HEAD^`, which will generate a file you can send
to the list.


pgp6mRRxhGm1i.pgp
Description: OpenPGP digital signature

Removing the need for ./configure --localstatedir=/var ?

[Christopher Allan Webber]

Every now and then I rebuild Guix and hit the problem where I run
./configure and then I am reminded that I need to instead do:

  ./configure --localstatedir=/var

IIRC this is because of GNU standards about default paths and pretty
much no other reason that we don't default to /var.  But I think Guix is
a special case.

Should we ask maybe for an exception?  There's no reason for users to
bump into this.  It's annoying even for me, and at least I know (or
think I do) why.

 - Chris

Re: missing licence files and incomplete licence lists

[Dave Love]

Ludovic Courtès  writes:

> Hi,
>
> Dave Love  skribis:
>
>> I realize that a lot of packages don't include licence files
>> (e.g. glibc).
>
> You mean ‘COPYING’ & co.?

Yes.

>> I'd mistakenly assumed that was automated according to the "license"
>> fields.
>
> Nope.  Outside of GNU there are no real conventions for license file
> names anyway.

Debian and SuSE both specify SPDX ones.  (There's been discussion about
using that for Fedora.)

That's orthogonal to the semantics of the field, though; if it's
misleading, that might be worse than not having it at all.

>> Also, some license fields aren't complete -- compare glibc's lgpl with
>> the contents of Debian's libc6 "copyright" file, which includes gpl,
>> bsd, and others, not just lgpl.
>
> Guix is much less comprehensive than Debian.  The ‘license’ field is
> meant to list the license that applies to the combined work.
>
> For glibc, it’s LGPLv2+; glibc includes BSD-licensed work, but that
> doesn’t matter from this perspective.

Is that based on FSF legal advice?  I think it needs to be if you want
to ignore what BSD licences say.  I'm afraid I'm old enough to remember
the BSD licence in a court case, without which the free software
landscape might be rather different, and the FSF campaigned against the
"obnoxious" advertising condition of original BSD.

>> Should bugs just be filed against each case, or can things be checked
>> systematically?
>
> Given the meaning of ‘license’ above, if you find errors, you’re of
> course welcome to report them.  But keep in mind that ‘license’ is
> looser than the info you’d fine in Debian ‘copyright’ files.

Is it meant to be equivalent of the RPM License field in Fedora/SuSE?
If not, exactly what does it mean?

Sorry if this seems too picky, but it's meant to be friendly advice from
long observation!  A GNU project should follow FSF legal advice, but I'd
expect Debian and Fedora to be fairly good models in the areas they
clearly agree.

Re: Question about multiple licenses

[Dave Love]

Alex Vong  writes:

> Dave Love  writes:
>
>> Indeed.  Not only do you need to list the licences (according to all
>> "legal advice" I've seen for distributions), but normally also
>> distribute the relevant licence texts, even for permissive licences if
>> they require that (e.g. BSD).  I raised this recently, as it's not
>> generally being done, so some Guix binary packages appear to be
>> copyright-infringing.
>>
> Yes, I think Debian has a /usr/share/doc/PKG/copyright file for each
> package PKG. Also, it includes the /usr/share/common-licenses/
> directory, so that those copyright files can refer to the common
> licenses without copying them verbatimly.

Yes.  That won't work for variant licences, though, and for where you
have to maintain the copyright notice in the file.

>>> Also, in this particular case, since ASL2.0 is incompatible with GPLv2,
>>> we actually need to take advantage of the "or later" clause, and
>>> "upgrades" it to "GPLv3+". Listing the license as GPLv2+ would confuse
>>> the user that GPLv2 covers the program, but in fact it is "effectively"
>>> GPLv3.
>>
>> This possibly depends on whether the licence information refers to the
>> source or binary package.  Fedora explicitly says binary, for instance.
>>
> I am unaware of this distinction. Maybe a website explaining this would
> be helpful.

It's in the Fedora reference.  For instance, the licence of a test
program in the distribution doesn't affect the licence of the binary
outputs if it's not shipped.

>> For what it's worth, the information for Fedora and Debian packagers is
>> 
>> and
>> .
>> They're not necessarily consistent, and things may be somewhat different
>> for GNU, but they provide a reasonable indication of the legalities.
>
> I think we should improve the status quote by documenting the license
> accurately in the license field. What do you think?

Yes, following the Fedora example.  I'd assume it's meant to be
basically the same thing as RPM's License: field.

Re: Question about multiple licenses

[Dave Love]

Ludovic Courtès  writes:

> Dave Love  skribis:
>
>> Alex Vong  writes:
>>
>>> Based on the above general argument, I think we should list all the
>>> licenses instead of just GPLv2+ since it would be inaccurate to say that
>>> the whole program is under just GPLv2+.
>>
>> Indeed.  Not only do you need to list the licences (according to all
>> "legal advice" I've seen for distributions), but normally also
>> distribute the relevant licence texts, even for permissive licences if
>> they require that (e.g. BSD).  I raised this recently, as it's not
>> generally being done, so some Guix binary packages appear to be
>> copyright-infringing.
>
> There’s no such thing as a “Guix binary package” though, which makes it
> different from traditional distros.
>
> In Guix a package is a Scheme object that refers to the source and build
> method of upstream software.

Sure, but if you use guix pack and distribute the result, it seems
clearly a copyright infringement, because even BSD requires

  2. Redistributions in binary form must reproduce the above copyright
 notice, this list of conditions and the following disclaimer in the
 documentation and/or other materials provided with the distribution.

> One can always view the COPYING file by running, say:
>
>   tar xf $(guix build -S glibc) glibc-2.25/COPYING
>
> This is of course suboptimal because the exact incantation varies from
> package to package (in some cases there’s no such file.)
>
> Thoughts?
>
> Ludo’.

Well, from what I know about copyright, that isn't the licence of glibc,
which is the sum of all the licences involved, and you'd have to know
how to find them if you didn't just unpack the tarball.  With pack
output in a lot of cases you don't have the information.

Packaging BLIS

[Ludovic Courtès]

Hello,

Dave Love  skribis:

> Ludovic Courtès  writes:

[...]

>> >> One example which has been investigated, and you can't, is BLIS.  You
>>
>> (Why “you can’t?”  It’s free software AFAICS on
>> .)
>
> Well, you could embark on some sort of (GCC-specific?) re-write, but it
> would be better to work on .
> I don't think there's anywhere you can just attach GCC attributes, and
> certainly no magic will happen for currently-unsupported architectures.

That caught my attention so I packaged BLIS:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=5a7deb117424ff4d430b771b50e534cf065c0ba1

There are several “flavors” of BLIS, so you can always rebuild your
favorite program with:

  --with-input=openblas=blis-haswell

and similar (or even ‘--with-graft=blis=blis-haswell’ where applicable).

Hopefully the issue you linked to above will be fixed in future versions
of BLIS, at which point we can probably provide a single “blis” package.

Ludo’.

“Code Staging in GNU Guix”

[Ludovic Courtès]

Hello Guix!

I wrote a recap of G-expressions, how we got there, and how they differ
from related work that I’ll have the pleasure to present at GPCE¹ in
Vancouver end of October:

  https://hal.inria.fr/hal-01580582/en

(The web site rebuilt the PDF from LaTeX source and that led to a weird
layout, different from what I had.  Talk about reproducibility…)

If you’ve been following gexps all along, it will look familiar.  One of
the new things in there is the discussion of “hygiene” (scope
preservation) for gexps, which I mentioned earlier².

At least one of the anonymous reviewers appears to be a
Scheme/Lisp/staging expert and made very detailed comments and
suggestions, so I’m sure we’ll have interesting discussions there.  :-)

Ludo’.

¹ https://conf.researchr.org/home/gpce-2017
² https://lists.gnu.org/archive/html/guix-devel/2017-07/msg00181.html


signature.asc
Description: PGP signature

Re: QT install and search paths

[宋文武]

Hartmut Goebel  writes:

> Am 04.09.2017 um 09:44 schrieb Thomas Danckaert:
>> Just to make sure, the idea is to:
>>
>>  1. apply 宋文武's qtbase patch adjusting the paths of various qt components
>>
>>  2. apply your 2 patches for qtscintilla and qtwebkit
>>
>>  3. adjust kde.scm so packages in there build correctly?
>
> ACK from my side.

Yes, and here are my updates on the paths issue of pkg-config files and
qwt:

>From e8a252f5037b77f44a1516c715bbd437a6e23cb2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= 
Date: Sun, 3 Sep 2017 17:38:57 +0800
Subject: [PATCH 2/3] gnu: qt: Fix install paths in submodules.

Before this, the paths in pkg-config (.pc) and libtool (.la) files of
submodules are all pointing to qtbase.

* gnu/packages/qt.scm (qtbase)[native-inputs]: Move 'which' to
'propagated-inputs'.
[arguments]: Rename 'patch-mkspecs' phase to 'patch-mkspecs' and patch
more qmake spec files there.
(qtsvg)[arguments]: Add 'configure-qmake' phase.
---
 gnu/packages/qt.scm | 86 +++--
 1 file changed, 63 insertions(+), 23 deletions(-)

diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm
index 80508f058..a41aa4fbb 100644
--- a/gnu/packages/qt.scm
+++ b/gnu/packages/qt.scm
@@ -375,7 +375,8 @@ developers using C++ or QML, a CSS & JavaScript like language.")
 #t
 (build-system gnu-build-system)
 (propagated-inputs
- `(("mesa" ,mesa)))
+ `(("mesa" ,mesa)
+   ("which" ,(@ (gnu packages base) which
 (inputs
  `(("alsa-lib" ,alsa-lib)
("cups" ,cups)
@@ -426,8 +427,7 @@ developers using C++ or QML, a CSS & JavaScript like language.")
("perl" ,perl)
("pkg-config" ,pkg-config)
("python" ,python-2)
-   ("ruby" ,ruby)
-   ("which" ,(@ (gnu packages base) which
+   ("ruby" ,ruby)))
 (arguments
  `(#:phases
(modify-phases %standard-phases
@@ -491,10 +491,11 @@ developers using C++ or QML, a CSS & JavaScript like language.")
  '("-no-sse2"))
"-no-mips_dsp"
"-no-mips_dspr2")
- (add-after 'install 'patch-qt_config.prf
+ (add-after 'install 'patch-mkspecs
(lambda* (#:key outputs #:allow-other-keys)
  (let* ((out (assoc-ref outputs "out"))
-(mkspecs (string-append out "/lib/qt5/mkspecs"))
+(archdata (string-append out "/lib/qt5"))
+(mkspecs (string-append archdata "/mkspecs"))
 (qt_config.prf (string-append
 mkspecs "/features/qt_config.prf")))
;; For each Qt module, let `qmake' uses search paths in the
@@ -508,6 +509,20 @@ developers using C++ or QML, a CSS & JavaScript like language.")
   "$$clean_path($$replace(dir, mkspecs/modules, ../../lib))")
  (("\\$\\$\\[QT_INSTALL_BINS\\]")
   "$$clean_path($$replace(dir, mkspecs/modules, ../../bin))"))
+
+   ;; Searches Qt tools in the current PATH instead of QT_HOST_BINS.
+   (substitute* (string-append mkspecs "/features/qt_functions.prf")
+ (("cmd = \\$\\$\\[QT_HOST_BINS\\]/\\$\\$2")
+  "cmd = $$system(which $${2}.pl 2>/dev/null || which $${2})"))
+
+   ;; Resolve qmake spec files within qtbase by absolute paths.
+   (substitute*
+   (map (lambda (file)
+  (string-append mkspecs "/features/" file))
+'("device_config.prf" "moc.prf" "qt_build_config.prf"
+  "qt_config.prf" "winrt/package_manifest.prf"))
+ (("\\$\\$\\[QT_HOST_DATA/get\\]") archdata)
+ (("\\$\\$\\[QT_HOST_DATA/src\\]") archdata))
#t))
 (native-search-paths
  (list (search-path-specification
@@ -553,26 +568,51 @@ developers using C++ or QML, a CSS & JavaScript like language.")
 (arguments
  `(#:phases
(modify-phases %standard-phases
- (replace 'configure
-   (lambda* (#:key outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "out")))
-   ;; Valid QT_BUILD_PARTS variables are:
-   ;; libs tools tests examples demos docs translations
-   (zero? (system* "qmake" "QT_BUILD_PARTS = libs tools tests"
-   (string-append "PREFIX=" out))
- (add-before 'install 'fix-Makefiles
+ (add-before 'configure 'configure-qmake
(lambda* (#:key inputs outputs #:allow-other-keys)
- (let ((out(assoc-ref outputs "out"))
-   (qtbase (assoc-ref inputs "qtbase")))
-   (substitute* (find-files "." "Makefile")
-(((string-append "INSTALL_ROOT)" qtbase))
-  

Re: Please put the system-configuration into the image

[ng0]

Hartmut Goebel transcribed 1.3K bytes:
> Am 07.09.2017 um 10:30 schrieb Ludovic Courtès:
> > However, I don’t quite understand the use case: you’d like to hack on
> > the OS declaration of the image from within the image?  That sounds
> > inconvenient no?
> 
> My use case is this:
> 
> I plan to use GuixSD for one of my systems. Prior to installing GuixSD
> on real hardware, I want to test it and see how a GuixSD system would
> work and feel. And taking the perspective of a non-developer, I don't
> have any GuixSD yet. I may be using Fedora or Debian and want to try out
> GuixSD. For this I use the QEMU image

You can take any system configuration file and build a shared or free-standing
vm with the "guix system" function. It's really easy this way.
"guix system vm config.scm" would produce a vm and in the end you get a
shell script you can use to start this vm.

> My understanding is that I would have a system-definition describing
> this very system and if I want to change the system-configuration, I
> change the system-definition. On e.g. Debian I would apt-get software
> and change config-files, while on GuixSD I would change the
> system-definition and reconfigure.
> 
> And I imagine to have the corresponding system-definition *in* the
> system, since in this use-case there is no separate "main GuixSD
> installation". Like when using ansible, puppet, etc. for managing *this*
> system, I need the system definition *for* this system *in* this system.
> 
> I hope this is clearer now.

Wouldn't simply keeping the configuration file(s) in a git help
(for a start)? This is what I do personally:
https://gitweb.krosos.org/systems

For infotropique I have this combination of plain config files (templates)
and (almost) the same content in variations of the before referenced 
"install.scm".
> -- 
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 
> 
> 

-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org


signature.asc
Description: PGP signature

Re: 03/03: gnu: elogind: Update to 232.3.

[Ludovic Courtès]

Heya!

Leo Famulari  skribis:

> On Tue, Sep 05, 2017 at 10:59:54AM -0400, Ricardo Wurmus wrote:
>> rekado pushed a commit to branch master
>> in repository guix.
>> 
>> commit fa67d5654176b4b815832eaf259188e1486c65ab
>> Author: Ricardo Wurmus 
>> Date:   Tue Jul 25 10:15:58 2017 +0200
>> 
>> gnu: elogind: Update to 232.3.
>> 
>> * gnu/packages/freedesktop.scm (elogind): Update to 232.3.
>> [home-page]: Use new upstream home page.
>> [arguments]: Disable tests, add new required configure flags; add build 
>> phase
>> "autogen".
>> [native-inputs]: Add autoconf, automake, libtool, and python.
>
> According to `git bisect`, this update broke several packages related to
> FreeDesktop and GNOME.
>
> Specifically, those packages all require libcap to be available now. The
> list of affected packages can be found with `git grep libcap`, since
> they all had libcap added to their inputs.
>
> I found that propagating libcap from elogind fixed some of the build
> failures and not others.

I’ve pushed a Proper Fix™ here:

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

The problem is just that libelogind.la was missing a -L flag for libcap.

I’ve successfully rebuilt all the dependents of elogind here.

Cheers,
Ludo’.

Re: Please put the system-configuration into the image

[Hartmut Goebel]

Am 07.09.2017 um 10:30 schrieb Ludovic Courtès:
> However, I don’t quite understand the use case: you’d like to hack on
> the OS declaration of the image from within the image?  That sounds
> inconvenient no?

My use case is this:

I plan to use GuixSD for one of my systems. Prior to installing GuixSD
on real hardware, I want to test it and see how a GuixSD system would
work and feel. And taking the perspective of a non-developer, I don't
have any GuixSD yet. I may be using Fedora or Debian and want to try out
GuixSD. For this I use the QEMU image

My understanding is that I would have a system-definition describing
this very system and if I want to change the system-configuration, I
change the system-definition. On e.g. Debian I would apt-get software
and change config-files, while on GuixSD I would change the
system-definition and reconfigure.

And I imagine to have the corresponding system-definition *in* the
system, since in this use-case there is no separate "main GuixSD
installation". Like when using ansible, puppet, etc. for managing *this*
system, I need the system definition *for* this system *in* this system.

I hope this is clearer now.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Please put the system-configuration into the image

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 05.09.2017 um 20:05 schrieb ng0:
>> The config used to build the disk-image is in gnu/system/install.scm
>> see 
>> https://www.gnu.org/software/guix/manual/html_node/Building-the-Installation-Image.html#Building-the-Installation-Image
>> hope this helps.
>
> Thanks for pointing to this – I didn't recognize that.
>
> Nevertheless I would expect to have it in the image so I can start
> hacking without first searching the manual and copy-pasting the file.
> This is primary to lower the entry level :-)

It is in the image, in the form of the (gnu system install) module.

However, I don’t quite understand the use case: you’d like to hack on
the OS declaration of the image from within the image?  That sounds
inconvenient no?

When hacking on that image, I simply do that from my main GuixSD
installation with:

  guix system vm gnu/system/install.scm

HTH,
Ludo’.

Re: How to package gnucash-docs

[Ludovic Courtès]

Hello!

Chris Marusich  skribis:

> First, "make check" fails because xmllint tries to look up a DTD on the
> Internet when validating the XML for dozens of documents.

Usually it’s a matter of defining XML_CATALOG_FILES (which happens
automatically if libxml2 is an input), or something similar.  If you
grep gnu/packages/*.scm, you’ll find instances of this that either add
libxml2 as an input, or modify the XML DTD URL to refer to the local
DTD.

> Second, I'm not sure if gnucash-docs should exist as a separate package
> in Guix.  I feel like it would be nicer if I could just add this as a
> "doc" output of the gnucash package.  How can I accomplish that?

If upstream makes it a separate package, I think it’s OK to make it a
separate package too.

Now, if you really want to make it a single package, it’s also possible,
by simply adding extra phases in ‘gnucash’ to build the doc.

HTH!

Ludo’.

Re: Random idea about speeding up guix pull

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 05.09.2017 um 16:33 schrieb Ludovic Courtès:
>> The problem is that libgit2 doesn’t support shallow clones, and it’s
>> unclear whether it will support it in the future:
>
> Maybe I'm wrong, but to my understanding fetching a single branch/tag is
> not a "shallow clone", isn't it?

I think it is, in the sense that just a subset of the Git object graph
is fetched, but I’m not 100% sure about the terminology.

Ludo’.