bug#50883: Suckless packages marked as 'x11' instead of 'expat'

[Sarah Morgensen]

Hello Guix,

It seems like some packages in suckless.scm are listed as having an
'x11' license when they are in fact 'expat' (as listed on
directory.fsf.org and confirmed by visual inspection).

I only checked three: dwm, dmenu, and st; but I suspect there are many
more.

(Perhaps at some point we should write a linter to check for potential
license discrepancies?)

--
Sarah

bug#50871: Stackage importer change breaks tests/lint, build

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Xinglu,

Xinglu Chen 写道：
On Tue, Sep 28 2021, Tobias Geerinckx-Rice via Bug reports for 
GNU Guix wrote:



Guix,


Oops, sorry for forgetting to address you…

Guix doesn't currently build because of a ‘lint’ test failure 
(log 
attached).  Reverting commit 
9c5e5ca1c0de56a0d5b2b924de10548172095b58 makes it pass.


Thanks for catching this!  The attached patch should fix this.


It did!  Thanks for the prompt fix, which I've now pushed as 
50d24214191abefc6b8f6c881f9a91c1f818a650.


…aand closing,

T G-R


signature.asc
Description: PGP signature

bug#50871: Stackage importer change breaks tests/lint, build

[Xinglu Chen]

On Tue, Sep 28 2021, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote:

> Guix,
>
> Guix doesn't currently build because of a ‘lint’ test failure (log 
> attached).  Reverting commit 
> 9c5e5ca1c0de56a0d5b2b924de10548172095b58 makes it pass.

Thanks for catching this!  The attached patch should fix this.

From 45b002a1a39adaf76ca0ab6ca2c1dd95eb26da30 Mon Sep 17 00:00:00 2001
Message-Id: <45b002a1a39adaf76ca0ab6ca2c1dd95eb26da30.1632854267.git.pub...@yoctocell.xyz>
From: Xinglu Chen 
Date: Tue, 28 Sep 2021 20:34:25 +0200
Subject: [PATCH] =?UTF-8?q?test:=20lint:=20Fix=20=E2=80=98haskell-stackage?=
 =?UTF-8?q?=E2=80=99=20test.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is a follow-up to commit 9c5e5ca1c0de56a0d5b2b924de10548172095b58.

The previous package was called “ghc-x” which is not available on Stackage,
instead change it to “ghc-pandoc” which does exist, and adjust its version.

* tests/lint.scm ("haskell-stackage"): Add additional metadata for the
  package; change package name to “ghc-pandoc”; and change to version to
  “100.0”.

Reported-by: Tobias Geerinckx-Rice 
---
 tests/lint.scm | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/tests/lint.scm b/tests/lint.scm
index 0f51b9ef79..e96265a55a 100644
--- a/tests/lint.scm
+++ b/tests/lint.scm
@@ -1317,29 +1317,30 @@ (define (package-with-phase-changes changes)
 
 (test-assert "haskell-stackage"
   (let* ((stackage (string-append "{ \"packages\": [{"
-  "\"name\":\"x\","
+  "\"name\":\"pandoc\","
+  "\"synopsis\":\"synopsis\","
   "\"version\":\"1.0\" }]}"))
  (packages (map (lambda (version)
   (dummy-package
-   (string-append "ghc-x")
+   "ghc-pandoc"
(version version)
(source
 (dummy-origin
  (method url-fetch)
  (uri (string-append
"https://hackage.haskell.org/package/;
-   "x-" version "/x-" version ".tar.gz"))
-'("0.9" "1.0" "2.0")))
+   "pandoc-" version "/pandoc-" version ".tar.gz"))
+'("0.9" "1.0" "100.0")))
  (warnings (pk (with-http-server `((200 ,stackage) ; memoized
-   (200 "name: x\nversion: 1.0\n")
-   (200 "name: x\nversion: 1.0\n")
-   (200 "name: x\nversion: 1.0\n"))
+   (200 "name: pandoc\nversion: 1.0\n")
+   (200 "name: pandoc\nversion: 1.0\n")
+   (200 "name: pandoc\nversion: 1.0\n"))
  (parameterize ((%hackage-url (%local-url))
 (%stackage-url (%local-url)))
(append-map check-haskell-stackage packages))
 (match warnings
   (((? lint-warning? warning))
-   (and (string=? (package-version (lint-warning-package warning)) "2.0")
+   (and (string=? (package-version (lint-warning-package warning)) "100.0")
 (string-contains (lint-warning-message warning)
  "ahead of Stackage LTS version"))
 

base-commit: 5edfa6d15e5bb92609ecff7e37e3985eced1dd4d
-- 
2.33.0



signature.asc
Description: PGP signature

bug#50872: Prosody service + letsencrypt certs improvements

[Christine Lemmer-Webber]

I finally got prosody working on my server using Guix.  However, the
manual says:

   Prosodyctl will also help you to import certificates from the
   ‘letsencrypt’ directory so that the ‘prosody’ user can access them.  See
   .

 prosodyctl --root cert import /etc/letsencrypt/live

However, what prosody actually does with this command is that it copies
the files from letsencrypt *over to* its own directory (but then also
restarts prosody... in theory).  According to the docs:

  This command can be put in cron or passed as a callback to automated
  certificate renewal programs such as certbot or other Let's Encrypt
  clients. For more information on using Prosody with these, see our
  Let's Encrypt page.

Hm, in other words we really ought to run this attached to some hook
related to the letsencrypt services... when they renew successfully, it
should trigger this command, I'd think.  We do similar things for nginx,
etc...

Thoughts?  Does this seem right?
 - Christine

bug#46242: Guix System is not listed in GNOME Boxes

[Mathieu Othacehe]

Hello,

> However, we only propose an xzipped iso (and not a raw iso file), so
> the data does not provide information on downloading. Either we have
> an outdated osinfo-db, or the lack of download option prevents boxes
> from showing it as a choice.

The reason for GNU Guix not showing up in GNOME Boxes appears to be that
the ISO9660 download URL is commented:

https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/guix.gnu.org/guix-1.1.xml.in#L15

I sent a new MR to add Guix 1.3.0 as well as Guix latest support here:

https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/360/diffs?commit_id=e7c8f037e6967edce4076fcf85b1a5bc0a9e2247

Let's see what happens!

Thanks,

Mathieu

bug#50871: Stackage importer change breaks tests/lint, build

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Guix,

Guix doesn't currently build because of a ‘lint’ test failure (log 
attached).  Reverting commit 
9c5e5ca1c0de56a0d5b2b924de10548172095b58 makes it pass.


Kind regards,

T G-R



test-suite.log
Description: Binary data


signature.asc
Description: PGP signature

bug#50856: Unbound variables in Guix Home

[Oleg Pykhalov]

Andrew Tropin  writes:

[…]

> From 634e6cbb7153ea02fb2ace6d39dae4055ed0c73c Mon Sep 17 00:00:00 2001
> From: Andrew Tropin 
> Date: Tue, 28 Sep 2021 12:30:55 +0300
> Subject: [PATCH] home-services: Add missing imports and function definition.
>
> * gnu/home-services/configuration.scm: Add missing imports.
> * gnu/home-services/utils.scm (list->human-readable-list): Add new function.
> * gnu/home-services/configuration.scm: Add missing imports.
> * gnu/home-services/xdg.scm: Fix ensure-list function.
> * guix/scripts/home/import.scm: Add missing imports.
> ---
>  gnu/home-services/configuration.scm |  2 ++
>  gnu/home-services/utils.scm | 30 -
>  gnu/home-services/xdg.scm   | 12 +++-
>  guix/scripts/home/import.scm|  4 
>  4 files changed, 42 insertions(+), 6 deletions(-)

Applied, thank you!

Oleg.



signature.asc
Description: PGP signature

bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Conversely, IIUC what the “normative parts of the output contents” (info
> "(ld) Options") really are, build IDs are computed on the code, not on
> debug info.
>
> But the problems remains the same I think: if you have
> /gnu/store/abc…/libfoo.so and /gnu/store/xyz…/libfoo.so, chances are
> that they are different due to embedded store file names, and thus get a
> different build ID.

We discussed this with Mark Wielaard on #guix¹, and one important
takeaway is:

--8<---cut here---start->8---
 so gdb just checks that the separate debug file has the same
  build-id as the code, right?  [12:16]
 it doesn't matter whether it really is the sha1 of all those
  sections, does it?
 that is kind of the whole point of the build-id, that it captures the
  whole build environment, not just the generated code, but also how it
  was generated (which is what the .debug sections kind of represent)
 ok  [12:17]
 civodul, no, it doesn't need to be a hash over the actual bits
  produced. It can be a completely different hash, it can be a different
  number of bits (but not too short, they need to be globally unique).
 ok, so we could have our own way of caculating build IDs  [12:18]
 civodul, all that really matters is that it uniquely identifies this
  binary blob. If any input, source, compiler, flags, etc. changes, it
  should be unique.
--8<---cut here---end--->8---

So I suspect that we would not need to rewrite build IDs upon grafting,
and we could use the ungrafted debug info with grafted code and vice
versa.

We should try it out to test the hypothesis, but if that works, that’d
be great.

Ludo’.

¹ https://logs.guix.gnu.org/guix/2021-09-28.log#114610

bug#50771: guix system search doesn't show system services from channels

[Andrew Tropin]

On 2021-09-27 15:27, zimoun wrote:

> Hi,
>
> On Fri, 24 Sept 2021 at 08:59, Andrew Tropin  wrote:
>>
>> Declared system service in (gnu services tmp) in my channel, did guix
>> pull with the apropriate channels configuration.
>>
>> System service from (gnu services tmp) can be used in my
>> operating-system record, but not searchable with `guix system search`.
>>
>> Do anyone know reasons for such behavior?  Are there any known good
>> solutions for that problem?
>
> Does it work if, instead of pulling, you run --load-path?
>
> Cheers,
> simon

`guix system --load-path=~/work/rde search home` doesn't show the
system service I declared :/

I suspect this problem happens due to implementation:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services.scm?h=7aea1c112647381c799ce217df1a083f72aab0ba#n200


signature.asc
Description: PGP signature

bug#48907: Grafts cause discrepancies in debug symbols file names (debug symbols missing in GDB).

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:
>
> [...]
>
>>> Yikes!  This means that debugging with grafts (with the aid of debugging
>>> symbols) is no longer possible, right?
>>
>> It depends on whether the separate “debug” output gets grafted or not,
>> but yeah, if a dependency tree has this shape (app -> lib + lib:debug),
>> running ‘guix install app’ alone will prevent you from getting debugging
>> symbols from ‘lib:debug’ I believe.  That sucks.
>>
>> I wonder if we should revert 482fda2729c3e76999892cb8f9a0391a7bd37119.
>> It’s often not very helpful anyway (we often find ourselves downloading
>> unnecessary package outputs because of grafting).
>
> Hmm.  Perhaps.  But it'd also suck to have to download 1 GiB of unneeded
> debugging symbols to just apply a graft to Qt, for example.

Yeah.  That’s already the case in some cases though, that’s what I
meant.

>>> I remember reading about a 2nd option to locate the separate debug
>>> symbol files with GDB in info '(gdb) Separate Debug Files':
>>>
>>>
>>>* The executable contains a "build ID", a unique bit string that is
>>
>> We’d have to check if this is applicable.  Looking at the ld manual
>> (info "(ld) Options"), it seems that the UUID “style” is ruled out
>> because it’s non-deterministic, and the md5 and sha1 styles would
>> require us to rewrite build IDs IIUC, similar to how we rewrite CRCs.
>
> Seems like it could work?  simark from #gdb says it should be
> deterministic for reproducible builds.  We'd need to fixup the grafted
> debug output, but they could being done in a separate derivation would
> no longer matter (as the debug symbols would be matched on a unique ID
> that is not linked to that derivation, not on their file name, which
> is).
>
> Did I get the above right?

To summarize, ‘.gnu_debuglink’ in executables/libraries contains the
CRC of the debug file.

Conversely, IIUC what the “normative parts of the output contents” (info
"(ld) Options") really are, build IDs are computed on the code, not on
debug info.

But the problems remains the same I think: if you have
/gnu/store/abc…/libfoo.so and /gnu/store/xyz…/libfoo.so, chances are
that they are different due to embedded store file names, and thus get a
different build ID.

Am I right?

(BTW, I just noticed build IDs were also discussed at
.)

Ludo’.

bug#50856: Unbound variables in Guix Home

[Andrew Tropin]

On 2021-09-28 00:15, Oleg Pykhalov wrote:

> Hi Guix,
>
> We have unbound variables in some Guix Home files:
> --8<---cut here---start->8---
> gnu/home-services/configuration.scm:56:6: warning: possibly unbound variable 
> `formatted-message'
> gnu/home-services/configuration.scm:57:7: warning: possibly unbound variable 
> `G_'
> gnu/home-services/xdg.scm:309:43: warning: possibly unbound variable 
> `maybe-list'
> gnu/home-services/xdg.scm:330:13: warning: possibly unbound variable 
> `list->human-readable-list'
> guix/scripts/home/import.scm:210:18: warning: possibly unbound variable 
> `package-version'
> guix/scripts/home/import.scm:210:35: warning: possibly unbound variable 
> `find-packages-by-name'
> guix/scripts/home/import.scm:222:23: warning: possibly unbound variable `cut'
> guix/scripts/home/import.scm:222:27: warning: possibly unbound variable 
> `version>?'
> guix/scripts/home/import.scm:222:45: warning: possibly unbound variable `<>'
> guix/scripts/home/import.scm:225:16: warning: possibly unbound variable 
> `version-unique-prefix'
> --8<---cut here---end--->8---
>
> maybe-list and list->human-readable-list come from
> gnu/home-services-utils.scm in rde project.
>
> Oleg.

My bad)  Here it is:

From 634e6cbb7153ea02fb2ace6d39dae4055ed0c73c Mon Sep 17 00:00:00 2001
From: Andrew Tropin 
Date: Tue, 28 Sep 2021 12:30:55 +0300
Subject: [PATCH] home-services: Add missing imports and function definition.

* gnu/home-services/configuration.scm: Add missing imports.
* gnu/home-services/utils.scm (list->human-readable-list): Add new function.
* gnu/home-services/configuration.scm: Add missing imports.
* gnu/home-services/xdg.scm: Fix ensure-list function.
* guix/scripts/home/import.scm: Add missing imports.
---
 gnu/home-services/configuration.scm |  2 ++
 gnu/home-services/utils.scm | 30 -
 gnu/home-services/xdg.scm   | 12 +++-
 guix/scripts/home/import.scm|  4 
 4 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/gnu/home-services/configuration.scm b/gnu/home-services/configuration.scm
index 3698006c37..e8f4bc77ec 100644
--- a/gnu/home-services/configuration.scm
+++ b/gnu/home-services/configuration.scm
@@ -23,6 +23,8 @@
   #:use-module (srfi srfi-1)
   #:use-module (ice-9 curried-definitions)
   #:use-module (ice-9 match)
+  #:use-module (guix i18n)
+  #:use-module (guix diagnostics)
 
   #:export (filter-configuration-fields
 
diff --git a/gnu/home-services/utils.scm b/gnu/home-services/utils.scm
index 3e490a0515..f13133a7ae 100644
--- a/gnu/home-services/utils.scm
+++ b/gnu/home-services/utils.scm
@@ -24,7 +24,8 @@
 
   #:export (maybe-object->string
 object->snake-case-string
-object->camel-case-string))
+object->camel-case-string
+list->human-readable-list))
 
 (define (maybe-object->string object)
   "Like @code{object->string} but don't do anyting if OBJECT already is
@@ -75,3 +76,30 @@ STYLE can be three `@code{lower}', `@code{upper}', defaults to
  (cons (first splitted-string)
(map string-capitalize
 (cdr splitted-string))
+
+(define* (list->human-readable-list lst
+#:key
+(cumulative? #f)
+(proc identity))
+  "Turn a list LST into a sequence of terms readable by humans.
+If CUMULATIVE? is @code{#t}, use ``and'', otherwise use ``or'' before
+the last term.
+
+PROC is a procedure to apply to each of the elements of a list before
+turning them into a single human readable string.
+
+@example
+(list->human-readable-list '(1 4 9) #:cumulative? #t #:proc sqrt)
+@result{} \"1, 2, and 3\"
+@end example
+
+yields:"
+  (let* ((word (if cumulative? "and " "or "))
+ (init (append (drop-right lst 1
+(format #f "~a" (string-append
+ (string-join
+  (map (compose maybe-object->string proc) init)
+  ", " 'suffix)
+ word
+ (maybe-object->string (proc (last lst)))
+
diff --git a/gnu/home-services/xdg.scm b/gnu/home-services/xdg.scm
index 457ce999a1..94275f3b65 100644
--- a/gnu/home-services/xdg.scm
+++ b/gnu/home-services/xdg.scm
@@ -287,9 +287,9 @@ The value of an XDG MIME entry must be a list, string or symbol, was given ~a")
 
 @example
 (merge-duplicates '((key1 . value1)
-  (key2 . value2)
-  (key1 . value3)
-  (key1 . value4)) '())
+(key2 . value2)
+(key1 . value3)
+(key1 . value4)) '())
 
 @result{} ((key1 . (value4 value3 value1)) (key2 . value2))
 @end example"
@@ -299,14 +299,16 @@ The value of an XDG MIME entry must be a list, string or symbol, was given ~a")
   (tail (cdr alist))
 

bug#50830: [core-updates-frozen] glibc looks for $sysconfdir/etc/localtime rather than /etc/localtime

[Ludovic Courtès]

Leo Famulari  skribis:

> On Mon, Sep 27, 2021 at 11:08:58PM +0200, Ludovic Courtès wrote:
>> So here’s a patch to fix it, and another one to do a minor cleanup
>> operation.
>
> I created a "tracking bug" to coordinate rebuilding the world:
>
> 

There was already , and I made this
bug a blocker.  I’ll email guix-devel so we can coordinate.

Thanks,
Ludo’.

bug#50672: python-pytorch is not reproducible

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Fri, 24 Sept 2021 at 16:11, Ludovic Courtès  
> wrote:
>
>> Having unbundled NNPACK in d326dec8115cf5e2cac9497633dc11ecc970361b, I
>> can confirm that PyTorch itself is now reproducible, but NNPACK isn’t.
>
> I reproduce: "guix build nnpack --no-grafts --check" differs.  Pytorch, not.
>
>> PyTorch upstream noted that the problem is in NNPACK, not PyTorch
>> proper.
>
> Closing this report?

No, I’ve retitled it.  Now looking at PeachPy:

  https://github.com/Maratyszcza/PeachPy/issues/88

> However, I notice 2 things:
>
>  1- Unbundled dependencies are still fetched

Yes but the snippet wipes them right after.

>  2- Does the Git submodule mechanism work with the SWH fallback?

No, not yet; there’s a comment in (guix git-download).  Fixing it should
be doable.

Thanks,
Ludo’.