bug#50595: Faliure in guix import go

[Sarah Morgensen]

Hello,

Thanks for your report!

Stephen Paul Weber  writes:

> $ guix import go -r bdd.fi/x/runitor
>
> guix import: warning: Failed to import package "bdd.fi/x/runitor".
> reason: ("struct-vtable" "Wrong type argument in position 1 (expecting 
> struct): ~S" (#f) (#f)).

It seems this is occurring because "https://bdd.fi/x/runitor?go-get=1";
does not have the

  

tag in the  element, as the Go spec requires (it's a direct child
of the  element).  However, it seems fairly harmless to relax this
requirement in our importer, so the following patch should fix this.

>From ca17299a3011171d6889202003d1e888b22303ec Mon Sep 17 00:00:00 2001
Message-Id: 
From: Sarah Morgensen 
Date: Thu, 16 Sep 2021 18:27:09 -0700
Subject: [PATCH] import: go: Match "go-import" meta tags anywhere.

Some personal sites forget to put  in a
 element, so look anywhere for them.

* guix/import/go.scm (fetch-module-meta-data): Match "go-import" meta
tags anywhere in the page.
---
 guix/import/go.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guix/import/go.scm b/guix/import/go.scm
index dad007d511..43abe004b3 100644
--- a/guix/import/go.scm
+++ b/guix/import/go.scm
@@ -480,7 +480,7 @@ build a package."
  (strip-.git-suffix/maybe repo-url)
   ;; 
   (let* ((meta-data (http-fetch* (format #f "https://~a?go-get=1"; module-path)))
- (select (sxpath `(// head (meta (@ (equal? (name "go-import"
+ (select (sxpath `(// (meta (@ (equal? (name "go-import"
   // content
 (match (select (html->sxml meta-data #:strict? #t))
   (() #f)   ;nothing selected

base-commit: 72297993a174586ee0a23b95b6b9ee2f3db34cf1
--
2.33.0

bug#50606: Add support for other formats of Guix channels

[Leo Famulari]

On Thu, Sep 16, 2021 at 02:41:10PM -0300, EuAndreh via Bug reports for GNU Guix 
wrote:
> My proposal was a little more crude: get the channel code from a tarball.  In
> this model there are no authentications with fingerprint or signed commits,
> neither "guix pull" would know much about the before/after state of a channel
> besides comparing the checksum of the whole tarball.

For this use case, where you don't require many of the `guix pull`
features, you could use GUIX_PACKAGE_PATH instead:

https://guix.gnu.org/cookbook/en/html_node/GUIX_005fPACKAGE_005fPATH.html

bug#50606: Add support for other formats of Guix channels

[Ludovic Courtès]

EuAndreh  skribis:

> My proposal was a little more crude: get the channel code from a tarball.  In
> this model there are no authentications with fingerprint or signed commits,
> neither "guix pull" would know much about the before/after state of a channel
> besides comparing the checksum of the whole tarball.
>
> This lower level abstraction is much less sofisticated, and would probably 
> mean
> refetching and rebuilding from tarball-backed channels than Git channels.  But
> this also means that the requirement is lower, and much more universal: a
> tarball file served over HTTP, compared to a specific Git HTTP protocol.

Note that we already have -L and GUIX_PACKAGE_PATH as an alternative to
full-blown channels.  I’d recommend using that when in need of a
lightweight alternative.  How does that sound?

Thanks,
Ludo’.

bug#50568: Missing source code

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> On Tue, Sep 14, 2021 at 10:38:55AM +0200, Ludovic Courtès wrote:
>> Hi,
>> 
>> Maxime Devos  skribis:
>> 
>> > The Wayback Machine has some copies of software at 
>> > https://www.atromatic.net:
>> 
>> Thanks, they’re now all in store on berlin.
>> 
>> It’s kinda ironic that it’s the Wayback Machine that’s saving us here…
>> I wonder if there’s a way to construct generic web.archive.org URLs that
>> we could use as a fallback in (guix build download)?
>
> AFAIK Just replace the date in
>
> On Mon, Sep 13, 2021 at 03:49:05PM +0200, Maxime Devos wrote:
>> https://web.archive.org/web/20161204140455/https://www.astromatic.net/download/stuff/stuff-1.26.0.tar.gz
>
> by the current time.

Oh nice, that seems to work:

--8<---cut here---start->8---
$ guix download 
https://web.archive.org/web/20210911171400/https://www.astromatic.net/download/stuff/stuff-1.26.0.tar.gz

Starting download of /tmp/guix-file.QXTq4V
>From 
>https://web.archive.org/web/20210911171400/https://www.astromatic.net/download/stuff/stuff-1.26.0.tar.gz...
following redirection to 
`https://web.archive.org/web/20161204140455/http://www.astromatic.net/download/stuff/stuff-1.26.0.tar.gz'...
 …6.0.tar.gz
200KiB/s 00:20 | 3.9MiB transferred
/gnu/store/l3r5j8r4f6fh6bxa9va3681n3bclxpdq-stuff-1.26.0.tar.gz
1syibi3b86z9pikhicvkkmgxm916j732fdiw0agw0lq6z13fdcjm
--8<---cut here---end--->8---

How ’bout the attached patch?  Works for me.

Thanks,
Ludo’.

diff --git a/guix/build/download.scm b/guix/build/download.scm
index c8ddadfdd4..140e42afec 100644
--- a/guix/build/download.scm
+++ b/guix/build/download.scm
@@ -678,6 +678,18 @@ and write the output to FILE."
(false-if-exception*
 (disarchive-assemble spec file #:resolver resolve
 
+(define (internet-archive-uri uri)
+  "Return a URI corresponding to an Internet Archive backup of URI, or #f if
+URI does not denote a Web URI."
+  (and (memq (uri-scheme uri) '(http https))
+   (let* ((now  (time-utc->date (current-time time-utc)))
+  (date (date->string now "~Y~m~d~H~M~S")))
+ ;; Note: the date in the URL can be anything and web.archive.org
+ ;; automatically redirects to the closest date.
+ (build-uri 'https #:host "web.archive.org"
+#:path (string-append "/web/" date "/"
+  (uri->string uri))
+
 (define* (url-fetch url file
 #:key
 (timeout 10) (verify-certificate? #t)
@@ -769,7 +781,9 @@ otherwise simply ignore them."
 
   (setvbuf (current-error-port) 'line)
 
-  (let try ((uri (append uri content-addressed-uris)))
+  (let try ((uri (append uri content-addressed-uris
+   (or (and=> (internet-archive-uri (first uri)) list)
+   '()
 (match uri
   ((uri tail ...)
(or (fetch uri file)

bug#50568: Missing source code

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Tue, 14 Sept 2021 at 10:40, Ludovic Courtès  wrote:
>
>> Thanks, they’re now all in store on berlin.
>
> Do we do the usual trick to save them on SWH?

I think their contents are already saved on berlin, just not the
tarballs themselves.

For example:

--8<---cut here---start->8---
$ guix download 
https://web.archive.org/web/20161204140455/https://www.astromatic.net/download/stuff/stuff-1.26.0.tar.gz

Starting download of /tmp/guix-file.HTtGKM
>From 
>https://web.archive.org/web/20161204140455/https://www.astromatic.net/download/stuff/stuff-1.26.0.tar.gz...
 …6.0.tar.gz
163KiB/s 00:25 | 3.9MiB transferred
/gnu/store/l3r5j8r4f6fh6bxa9va3681n3bclxpdq-stuff-1.26.0.tar.gz
1syibi3b86z9pikhicvkkmgxm916j732fdiw0agw0lq6z13fdcjm
$ guix environment --ad-hoc disarchive -- disarchive disassemble 
/gnu/store/l3r5j8r4f6fh6bxa9va3681n3bclxpdq-stuff-1.26.0.tar.gz |grep swhid
(swhid 
"swh:1:dir:128bbe76a82dd0b38b725565ed703a7148257ae0"))
--8<---cut here---end--->8---

and:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix swh)
scheme@(guile-user)> (lookup-directory 
"128bbe76a82dd0b38b725565ed703a7148257ae0")
$24 = #f
--8<---cut here---end--->8---

Hmm actually maybe they vanished before they got a chance to be
archived?

Ludo’.

bug#50606: Add support for other formats of Guix channels

[EuAndreh via Bug reports for GNU Guix]

I'm very much in favor of keeping the current channel implementation leveraging
aspects specific to Git, and I also don't think that adding any other DVCS is
worth it.

bug#50606: Add support for other formats of Guix channels

[EuAndreh via Bug reports for GNU Guix]

In this model, downgrade prevention would a) be inexistant or b) require work
from the upstream tarball provider, to produce tarballs with metadata files that
could provide such data.

Authentication could be done by relying on TLS, or requiring a signature file.

bug#50606: Add support for other formats of Guix channels

[EuAndreh via Bug reports for GNU Guix]

I agree with most points, but I'm not proposing creating integrations with other
DVCS, en par with the current Git integration.

My proposal was a little more crude: get the channel code from a tarball.  In
this model there are no authentications with fingerprint or signed commits,
neither "guix pull" would know much about the before/after state of a channel
besides comparing the checksum of the whole tarball.

This lower level abstraction is much less sofisticated, and would probably mean
refetching and rebuilding from tarball-backed channels than Git channels.  But
this also means that the requirement is lower, and much more universal: a
tarball file served over HTTP, compared to a specific Git HTTP protocol.

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

[Maxime Devos]

Ludovic Courtès schreef op do 16-09-2021 om 17:20 [+0200]:
> +,@(let ((system (or (%current-target-system) (%current-system
> +(if (or (string-prefix? "i686-" system)
> +(string-prefix? "i586-" system))

(Unrelated to the build failure) you could use target-x86-32? here
to make the code a little simpler:

,@(if (target-x86-32?)
  '((add-after ))
  '()

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#50625: ghostscript shell scripts refer to unqualified external commands

[Jack Hill]

Hi Guix,

Many of the commands, e.g. ps2pdf, provided by the ghostscript package are 
implemented as shell scripts that do some argument or file name processing 
before invoking the main gs binary. These scripts invoke external commands 
like basename, awk, dirname, and even gs by dynamically looking them up 
PATH. Instead, they should refer to a specific path in the store so that 
the behavior of ghostscript doesn't depend on the environment and so that 
Guix can see these references.


Best,
Jack

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

[Ludovic Courtès]

Hi,

Guillaume Le Vaillant  skribis:

> Ludovic Courtès  skribis:
>
>> On ‘core-updates-frozen’, CMake has one test failure on i686-linux when
>> building on berlin (e.g., ):
>>
>> --8<---cut here---start->8---
>> 545/558 Test #518: RunCMake.CPack_TXZ 
>> ***Failed3.79 sec
>> [...]
>> --8<---cut here---end--->8---
>>
>> I cannot reproduce it on hardware with 32 cores.  I suspect it has to do
>> with the number of threads used for xz compression, which defaults to
>> the number of cores, and some of the build machines on berlin have way
>> more cores.
>>
>> Ludo’.
>
> I tried a few times on a machine with 16 cores, and I can't reproduce
> either. The build succeeded every time.

My latest attempt is to go as far as setting the number of threads used
by libarchive to 1 (patch attached).  However, that still fails
systematically on berlin’s 32-core build machines.

The Internet doesn’t seem to have much to say about this problem.

Ideas anyone?

Ludo’.

diff --git a/gnu/packages/cmake.scm b/gnu/packages/cmake.scm
index f76ee3ff3a..a235d922e0 100644
--- a/gnu/packages/cmake.scm
+++ b/gnu/packages/cmake.scm
@@ -92,7 +92,7 @@ using the CMake build system.")
 
 ;;; Build phases shared between 'cmake-bootstrap' and the later variants
 ;;; that use cmake-build-system.
-(define %common-build-phases
+(define (%common-build-phases)
   `((add-after 'unpack 'split-package
   ;; Remove files that have been packaged in other package recipes.
   (lambda _
@@ -100,6 +100,18 @@ using the CMake build system.")
 (substitute* "Auxiliary/CMakeLists.txt"
   ((".*cmake-mode.el.*") ""))
 #t))
+,@(let ((system (or (%current-target-system) (%current-system
+(if (or (string-prefix? "i686-" system)
+(string-prefix? "i586-" system))
+'((add-after 'unpack 'clamp-xz-thread-number
+(lambda _
+  ;; By default, 'CPack' would use as many threads as the
+  ;; number of available cores for xz compression.
+  ;; However, this leads to test failures: .
+  (substitute* "Source/cmArchiveWrite.cxx"
+(("case CompressXZ:")
+ "case CompressXZ: numThreads = 1;\n")
+'()))
 (add-before 'configure 'patch-bin-sh
   (lambda _
 ;; Replace "/bin/sh" by the right path in... a lot of
@@ -188,7 +200,7 @@ using the CMake build system.")
" --exclude-regex ^\\(" (string-join skipped-tests "\\|") "\\)$")))
#:phases
(modify-phases %standard-phases
- ,@%common-build-phases
+ ,@(%common-build-phases)
  (add-before 'configure 'set-paths
(lambda _
  ;; Help cmake's bootstrap process to find system libraries
@@ -295,7 +307,7 @@ and workspaces that can be used in the compiler environment of your choice.")
#:build-type "Release"
#:phases
(modify-phases %standard-phases
- ,@%common-build-phases
+ ,@(%common-build-phases)
  (add-after 'install 'delete-help-documentation
(lambda* (#:key outputs #:allow-other-keys)
  (delete-file-recursively

bug#50624: Importing (gnu packages lxqt) in gnu/packages/kde-frameworks.scm causes unbound variable error.

[Brendan Tildesley]

I want to use libdbusmenu-qt in kde-frameworks.scm, but just adding 
#:use-modules (gnu packages lxqt)
and running some guix package command results in this. What should I do? Thanks.



$ ./pre-inst-env guix show knotifications
;;; note: source file /home/b/code/guix-cryfs/gnu/packages/kde-frameworks.scm
;;;   newer than compiled 
/home/b/code/guix-cryfs/gnu/packages/kde-frameworks.go
;;; note: source file /home/b/code/guix-cryfs/gnu/packages/kde-frameworks.scm
;;;   newer than compiled 
/run/current-system/profile/lib/guile/3.0/site-ccache/gnu/packages/kde-frameworks.go
error: curl: unbound variable
hint: Did you forget a `use-modules' form?

error: googletest: unbound variable
hint: Did you forget a `use-modules' form?

error: bzip2: unbound variable
hint: Did you forget a `use-modules' form?

error: binutils: unbound variable
hint: Did you forget a `use-modules' form?

error: gcc-4.9: unbound variable
hint: Did you forget a `use-modules' form?

error: python-2: unbound variable
hint: Did you forget a `use-modules' form?

error: tcc: unbound variable
hint: Did you forget a `use-modules' form?

error: gnu-make: unbound variable
hint: Did you forget a `use-modules' form?

error: unzip: unbound variable
hint: Did you forget a `use-modules' form?

error: binutils: unbound variable
hint: Did you forget a `use-modules' form?

error: perl: unbound variable
hint: Did you forget a `use-modules' form?

error: coreutils: unbound variable
hint: Did you forget a `use-modules' form?

Throw to key `unbound-variable' with args `("resolve-interface" "no binding 
`~A' in module ~A" (python (gnu packages python)) #f)'.
Backtrace:
In ice-9/boot-9.scm:
  1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
  18 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2 17 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 16 (_ #(#(#)))
In guix/ui.scm:
   2185:7 15 (run-guix . _)
  2148:10 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/package.scm:
906:9 12 (_)
In srfi/srfi-1.scm:
634:9 11 (for-each # …)
In guix/scripts/package.scm:
   911:29 10 (_ _)
In gnu/packages.scm:
   292:55  9 (_ "knotifications" _)
In unknown file:
   8 (force #)
In gnu/packages.scm:
   239:33  7 (fold-packages # …)
In guix/discovery.scm:
   153:11  6 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
   460:18  5 (fold # …)
In guix/discovery.scm:
   143:19  4 (_ _ ())
In srfi/srfi-1.scm:
   691:23  3 (filter-map # . #)
In guix/discovery.scm:
   118:22  2 (_ . _)
In guix/ui.scm:
324:2  1 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" 
(unbound-variable "resolve-interface" "no binding `~A' in module ~A" (python 
(gnu packages python)) #f))'.

bug#50605: go: Commit d36c73b8a8f breaks `go tool`

[Katherine Cox-Buday]

I talked with Sarah in IRC (thanks for the quick response, Sarah!), and
we discovered it was because I had set =GOROOT= to
="${GUIX_PROFILE}/share/go". Go will set =${GOTOOLS}= relative to this
path.

Since Guix sets both of these to sensible defaults, I was able to remove
the customization and things went back to working as normal.

Sorry for the noise, and I hope this helps some future person!

-- 
Katherine

bug#50483: [R] Package r-shiny: Shiny server logic inactive

[Charles via Bug reports for GNU Guix]

Hello, I am responsible to updating the minify build syste to use the updated 
uglifyjs (now node-uglify-js found in gnu/packages/uglifyjs.scm). When updating 
I noticed that some R packages had the input uglify-js (the old lisp one). I 
chose not mess with them at risk of breaking. What I failed to realize is that 
some R packages (like r-shiny) actually use the minify build-system to do the 
minifying, thus trying to call the updated uglifyer, while only importing the 
new one. Other R package like (r-shinytree) do not use the minify build system 
and instead directly call uglify-js using open-pipe* (these are the ones I 
didn't want to break).

I would highly suggest against using the old lisp uglifyer since it is outdated 
by 6 years, and if anyone decides to write some modern javascript, your package 
will break. Instead simply update the input to ("node-uglify-js" 
,node-uglify-js) and don't forget to use module (gnu packages uglifyjs). For 
the packages like r-shinytree, I would suggest having them use the minify-build 
system like r-shiny (and also updating to the newer node-uglify-js). I have 
tested updaing the input, and it works for the ggplot2 example stated earlier 
in this thread.

Again I'm really sorry for not catching this. It is very late where I am, so if 
it isn't clear how to update, I can do it tomorrow.

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

[Guillaume Le Vaillant]

Ludovic Courtès  skribis:

> On ‘core-updates-frozen’, CMake has one test failure on i686-linux when
> building on berlin (e.g., ):
>
> --8<---cut here---start->8---
> 545/558 Test #518: RunCMake.CPack_TXZ 
> ***Failed3.79 sec
> [...]
> --8<---cut here---end--->8---
>
> I cannot reproduce it on hardware with 32 cores.  I suspect it has to do
> with the number of threads used for xz compression, which defaults to
> the number of cores, and some of the build machines on berlin have way
> more cores.
>
> Ludo’.

I tried a few times on a machine with 16 cores, and I can't reproduce
either. The build succeeded every time.


signature.asc
Description: PGP signature

bug#32440: localization of guix refresh

[Julien Lepiller]

Indeed, I didn't notice it was added, and doesn't cause issues. Closing, thanks 
for the reminder :)

Le 16 septembre 2021 03:40:46 GMT-04:00, zimoun  a 
écrit :
>Hi Julien,
>
>On Tue, 14 Aug 2018 at 21:45, Julien Lepiller  wrote:
>
>> I've just found out that guix refresh is not translated. Indeed,
>> guix/script/refresh.scm is not listed in po/guix/POTFILES.in as it
>> should be. Adding it to the file leads to an issue though. One of the
>> entries generated in po files is the following:
>
>The file ’guix/script/refresh.scm’ had been added to
>’po/guix/POTFILES.in’ by the commit
>c1eb04e6fd1c2cdb30b7b33d500b4ce54cabc27d.
>
>Closing?
>
>Cheers,
>simon

bug#50596: Cannot get guix copy to work...

[Stephen Paul Weber]

Thanks for the follow up.
Does it mean this bug can be closed?


Yes, thanks.

bug#28173: texlive-texmf-minimal not reproducible

[Ricardo Wurmus]

zimoun  writes:


Hi,

On Mon, 09 Oct 2017 at 23:39, Ricardo Wurmus 
 wrote:

Ricardo Wurmus  writes:


texlive-texmf-minimal is no longer needed and should be 
removed, so I

think this bug can be closed.


Texlive-texmf-minimal has in fact been removed, but the bug 
report is
still valid.  Many of the generated files in TeX Live packages 
contain
timestamps and it is not clear which of them may be removed 
without

affecting the behaviour of the collection.


What is the status of this old bug [1]?  Since 
texlive-texmf-minimal had
been removed, what is the reproducer?  i.e., which part is not 
reproducible?


1: 


Many of the modular texlive packages have reproducibility issues.

Take texlive-cm for example.  METAFONT writes a timestamp into 
every generated font file 
(e.g. /gnu/store/lkmiyfzi1bq571yn4gypbcs5vn4fpma7-texlive-cm-51265/share/texmf-dist/fonts/tfm/public/cm/cmvtt10.600gf). 
It also generates log files that contain timestamped lines like 
these:


│ │ │ │ │ │ ├── +++ 
/gnu/store/lkmiyfzi1bq571yn4gypbcs5vn4fpma7-texlive-cm-51265/share/texmf-dist/fonts/tfm/public/cm/cmu10.log

│ │ │ │ │ │ │ @@ -1,6 +1,6 @@
│ │ │ │ │ │ │ -This is METAFONT, Version 2.7182818 (TeX Live 2019) 
(preloaded base=mf 2021.4.16)  16 SEP 2021 11:21
│ │ │ │ │ │ │ +This is METAFONT, Version 2.7182818 (TeX Live 2019) 
(preloaded base=mf 2021.4.16)  16 APR 2021 23:30


The texlive-union executes processes that also lead to 
irreproducible files.  Here’s an example:


   ./pre-inst-env guix build --rounds=2 --no-grafts -K -e '(begin 
   (import (gnu packages tex)) (texlive-union (list 
   texlive-ydoc)))'


This is what diffoscope has to say:

--8<---cut here---start->8---
$ diffoscope 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265-check
--- 
   /gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265
+++ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265-check
│   --- 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share
├── +++ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265-check/share
│ │   --- 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share/texmf-var
│ ├── +++ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265-check/share/texmf-var
│ │ │   --- 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share/texmf-var/web2c
│ │ ├── +++ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265-check/share/texmf-var/web2c
│ │ │ │   --- 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share/texmf-var/web2c/updmap.log
│ │ │ ├── +++ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265-check/share/texmf-var/web2c/updmap.log

│ │ │ │ @@ -1,9 +1,9 @@
│ │ │ │  updmap version r50442 (2019-03-18 11:35:23 +)
│ │ │ │ -Thu Sep 16 11:24:07 2021
│ │ │ │ +Thu Sep 16 11:24:06 2021
│ │ │ │  
│ │ │ │  Using the following config files:
│ │ │ │ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share/texmf-config/web2c/updmap.cfg
│ │ │ │  
│ │ │ │  updmap is creating new map files

│ │ │ │  using the following configuration:
│ │ │ │LW35 font names  : URWkb 
(/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share/texmf-config/web2c/updmap.cfg)

│ │ │ │ @@ -810,19 +810,19 @@
│ │ │ │  
│ │ │ │ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share/texmf-dist/fonts/map/dvips/tetex/mathpple.map:

│ │ │ │  eurbo10
│ │ │ │  eurmo10
│ │ │ │  
│ │ │ │  Files generated:
│ │ │ │ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share/texmf-dist/fonts/map/dvips/updmap/:

│ │ │ │ -   15890 2021-09-16 11:24:07 builtin35.map
│ │ │ │ -   21363 2021-09-16 11:24:07 download35.map
│ │ │ │ -   21470 2021-09-16 11:24:07 psfonts_pk.map
│ │ │ │ -   21674 2021-09-16 11:24:07 psfonts_t1.map
│ │ │ │ -   21669 2021-09-16 11:24:07 ps2pk.map
│ │ │ │ -  14 2021-09-16 11:24:07 psfonts.map -> 
psfonts_t1.map

│ │ │ │ +   15890 2021-09-16 11:24:06 builtin35.map
│ │ │ │ +   21363 2021-09-16 11:24:06 download35.map
│ │ │ │ +   21470 2021-09-16 11:24:06 psfonts_pk.map
│ │ │ │ +   21674 2021-09-16 11:24:06 psfonts_t1.map
│ │ │ │ +   21669 2021-09-16 11:24:06 ps2pk.map
│ │ │ │ +  14 2021-09-16 11:24:06 psfonts.map -> 
psfonts_t1.map
│ │ │ │ 
/gnu/store/2x6jddfgfg5rp342wsrsl5gssz2lkd06-texlive-union-51265/share/texmf-dist/fonts/map/pdftex/updmap/:

│ │ │ │ -   21676 2021-09-16 11:24:07 pdftex_dl14.map
│ │ │ │ -   20011 2021-09-16 11:24:07 pdftex_ndl14.map
│ │ │ │ -  15 2021-09-16 11:24:07 pdftex.map -> 
pdftex_dl14.map

│ │ │ │ +   21676 2021-09-16 11:24:06 pdftex_dl14.map
│ │ │ │ +   20011 2021-09-16 11:24:06 pdftex_ndl14.map
│ │ │ │ +  15 2021-09-16 11:24:06 pdftex.map -> 
pdftex_dl14.map
│ │ │ │ 
/gnu/store/2x6jddfgfg5

bug#50606: Add support for other formats of Guix channels

[zimoun]

Hi,

On Thu, 16 Sept 2021 at 10:18, Ludovic Courtès  wrote:
> EuAndreh  skribis:

> > Guix channel authors may want to serve channels:

[...]

> > - via other DVCS like Mercurial, Fossil, BitKeeper;
> > - decoupled from the backing versioning tool.

[...]

> All in all, I’m not in favor of supporting other version control tools
> for channels.

Adding more all to "all in all". :-)

Support other VCS would mean a lot of work: refactor "pull" and then
break several CLIs (pull, time-machine, describe) -- without speaking
about "guix git" subcommand.  I do not know if all the Git concepts
currently used by Guix translate well to other VCS.  Moreover the
transparent recent fallback to SWH for channels would also needs piece
of work -- it is not straightforward to fetch back content from
metadata at hand; it is currently only done for Git source and the
others VCS are still WIP, i.e., they do not work out-of-the-box.
Well, from a pragmatic point of view, I am not convinced that such
effort is worth considering the popularity of Git vs other-VCS.

All the best,
simon

bug#28303: “guix import texlive keyval” fails

[Ricardo Wurmus]

zimoun  writes:


Hi,

On Tue, 10 Oct 2017 at 08:51, l...@gnu.org (Ludovic Courtès) 
wrote:

Ricardo Wurmus  skribis:

In the case of “keyval” I don’t know exactly what is wrong, 
but in
general it looks like the importer doesn’t use subversion from 
the store

but expects it to be available in the environment.


For now, we could always return an error like “svn command not 
found” or

similar?


I think this old bug [1] is fixed now.  The 2 examples works now 
and

from my understanding, I do not have SVN in my profiles as user.


The SVN parts still fail, but at least the rest of the import 
works fine.



Closing?


Yes, please.

I’d like to note that this importer should eventually be replaced. 
I have some WIP for a new importer.


--
Ricardo

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

[Ludovic Courtès]

On ‘core-updates-frozen’, CMake has one test failure on i686-linux when
building on berlin (e.g., ):

--8<---cut here---start->8---
545/558 Test #518: RunCMake.CPack_TXZ ***Failed 
   3.79 sec
-- MINIMAL-MONOLITHIC-type - PASSED
-- TXZ/MINIMAL-MONOLITHIC-type - PASSED
-- MINIMAL-COMPONENT-type - PASSED
-- TXZ/MINIMAL-COMPONENT-type - PASSED
-- MINIMAL-package-target-MONOLITHIC-type - PASSED
-- TXZ/MINIMAL-package-target-MONOLITHIC-type - PASSED
-- MINIMAL-package-target-COMPONENT-type - PASSED
-- TXZ/MINIMAL-package-target-COMPONENT-type - PASSED
-- THREADED_ALL-package-target-MONOLITHIC-type - PASSED
CMake Error at RunCMake.cmake:201 (message):
  TXZ/THREADED_ALL-package-target-MONOLITHIC-type - FAILED:

  Result is [1], not [0].

  stderr does not match that expected.

  Command was:

   command> 
"/tmp/guix-build-cmake-bootstrap-3.20.2.drv-0/cmake-3.20.2/bin/cmake" 
"-DRunCMake_TEST=THREADED_ALL-package-target-MONOLITHIC-type" 
"-DRunCMake_TEST_FILE_PREFIX=THREADED_ALL" "-DRunCMake_SUBTEST_SUFFIX=" 
"-DGENERATOR_TYPE=TXZ" "-DPACKAGING_TYPE=MONOLITHIC" 
"-Dsrc_dir=/tmp/guix-build-cmake-bootstrap-3.20.2.drv-0/cmake-3.20.2/Tests/RunCMake/CPack"
 
"-Dbin_dir=/tmp/guix-build-cmake-bootstrap-3.20.2.drv-0/cmake-3.20.2/Tests/RunCMake/TXZ/CPack/THREADED_ALL-package-target-build"
 
"-Dconfig_file=/tmp/guix-build-cmake-bootstrap-3.20.2.drv-0/cmake-3.20.2/Tests/RunCMake/CPack/conf/TXZ_config.cmake"
 "-P" 
"/tmp/guix-build-cmake-bootstrap-3.20.2.drv-0/cmake-3.20.2/Tests/RunCMake/CPack/VerifyResult.cmake"

  Actual stdout:

   actual-out>

  Expected stderr to match:

   expect-err> ^$

  Actual stderr:

   actual-err> CMake Error at 
/tmp/guix-build-cmake-bootstrap-3.20.2.drv-0/cmake-3.20.2/Tests/RunCMake/CPack/VerifyResult.cmake:88
 (message):
   actual-err>   Found more than one file for file No.  '1'! Found files count 
'0'.  Files:
   actual-err>   '' Globbing expression: 'threaded_all-0.1.1-*.tar.xz'
   actual-err>
   actual-err>   CPack output: 'make[1]: Entering directory
   actual-err>   
'/tmp/guix-build-cmake-bootstrap-3.20.2.drv-0/cmake-3.20.2/Tests/RunCMake/TXZ/CPack/THREADED_ALL-package-target-build'
   actual-err>
   actual-err>
   actual-err>   Run CPack packaging tool...
   actual-err>
   actual-err>   CPack: Create package using TXZ
   actual-err>
   actual-err>   CPack: Install projects
   actual-err>
   actual-err>   CPack: - Run preinstall target for:
   actual-err>   THREADED_ALL-package-target-MONOLITHIC-type
   actual-err>
   actual-err>   CPack: - Install project: 
THREADED_ALL-package-target-MONOLITHIC-type []
   actual-err>
   actual-err>   CPack: Create package
   actual-err>
   actual-err>   make[1]: Leaving directory
   actual-err>   
'/tmp/guix-build-cmake-bootstrap-3.20.2.drv-0/cmake-3.20.2/Tests/RunCMake/TXZ/CPack/THREADED_ALL-package-target-build'
   actual-err>
   actual-err>
   actual-err>   '
   actual-err>
   actual-err>   CPack error: 'CPack Error: Problem to open archive
   actual-err>   
,
   actual-err>   ERROR = archive_write_open: Internal error initializing 
compression
   actual-err>   library: Cannot allocate memory
   actual-err>
   actual-err>   CPack Error: Problem compressing the directory
   actual-err>
   actual-err>   CPack Error: Error when generating package: threaded_all
   actual-err>
   actual-err>   make[1]: *** [Makefile:146: package] Error 1
   actual-err>
   actual-err>   ';
   actual-err>
   actual-err>   CPack result: '';
   actual-err>
   actual-err>   config file: ''

Call Stack (most recent call first):
  RunCMake.cmake:215 (run_cmake)
  CPack/CPackTestHelpers.cmake:119 (run_cmake_command)
  CPack/CPackTestHelpers.cmake:143 (run_cpack_test_common_)
  CPack/RunCMakeTest.cmake:24 (run_cpack_test_package_target)
--8<---cut here---end--->8---

I cannot reproduce it on hardware with 32 cores.  I suspect it has to do
with the number of threads used for xz compression, which defaults to
the number of cores, and some of the build machines on berlin have way
more cores.

Ludo’.

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

[Guillaume Le Vaillant]

Sarah Morgensen  skribis:

> arcan-sdl@0.5.5.2-1.b4dd1fb
> aris@2.2
> blastem@0.6.2
> crispy-doom@5.8.0
> geeqie@1.5
> glabels@3.4.1
> gmtp@1.3.11

These are fixed in c9f7770eeec3a7b493dcbf45c96a4528f2635604 and
following.


signature.asc
Description: PGP signature

bug#48400: Nyxt build fails because php fails x86_64

[zimoun]

Hi,

On Fri, 02 Jul 2021 at 18:35, zimoun  wrote:
> On Thu, 13 May 2021 at 11:24, Bone Baboon  wrote:

>> On a x86_64 computer Nyxt fails to build because php fails to build.

[...]

> Do you still have this problem?

Two of us reported the build passes.  And it is marked moreinfo since 4
weeks, so I close.  Feel free to reopen if I miss something.

All the best,
simon

bug#33463: guix publish error on Hydra: fport_close: Bad file descriptor

[Mark H Weaver]

Hi Simon,

zimoun  writes:
> This old bug [1] is about Hydra which is down now, IIRC.
>
> Does it make sense to keep it open?

I think it's okay to close it.  I'm doing so now.

 Thanks!
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#50606: Add support for other formats of Guix channels

[Ludovic Courtès]

Hi,

EuAndreh  skribis:

> As I've described in [0], one can't have a Guix channel served over Git's
> "Dumb HTTP" protocol.  That is caused by libgit's inability to do so [1].
>
> Guix channel authors may want to serve channels:
> - via "Dumb HTTP" Git repositories;
> - via other DVCS like Mercurial, Fossil, BitKeeper;
> - decoupled from the backing versioning tool.
>
> My initial though is that making Guix knowing how to handle channels served as
> tarballs would suffice, and cover all of the above.  Those channels wouldn't
> have the exact same caching and authentication characteristics as channels
> served via Git repositories, but that seems OK.
>
> WDYT?

Channel authentication and downgrade prevention are very much linked to
Git, though they could work with any append-only kind of DVCS.

Now, the implementation is (purposefully) very much Git-only; the format
of channel specs is somewhat Git-only as well.  I understand it can be
frustrating users of other VCSes, but from a maintenance viewpoint,
supporting a single VCS greatly simplifies things.  I also think it’s
beneficial from a user interface standpoint because it allows us to
provide tighter integration than if there was a high-level abstraction
layer.

All in all, I’m not in favor of supporting other version control tools
for channels.

Supporting the “dump HTTP” Git transport would be nice, but as you
write, it’s more of a feature request for libgit2.

Thanks,
Ludo’.

bug#33463: guix publish error on Hydra: fport_close: Bad file descriptor

[zimoun]

Hi Mark,

This old bug [1] is about Hydra which is down now, IIRC.

Does it make sense to keep it open?  If yes, what could be the
actionable next step?

On Wed, 21 Nov 2018 at 19:51, Mark H Weaver  wrote:
> FYI, I just spotted this output from "guix publish" on Hydra.
>
>   Mark
>
>
> GET /sd34hpwkjdax611r4cqqk5rhna79sl9k.narinfo
> GET /ndbv402716xnhsy229m2mgx7lf415ank.narinfo
> GET /jj4ibyflqrd24xb16p7vsadj7nr3ik2k.narinfo
> GET /fxxba73sgq1r2vav5imj2wsp6cy4mqlj.narinfo
> GET /d38frkfi36nq10c0sss7fr8rnz2alhdn.narinfo
> GET /clgxxvd97r7dwgdx0vczwp90hhcixnvm.narinfo
> GET /bq2c0p4bl18fh0fbd0zav0svnry9c60x.narinfo
> In guix/workers.scm:
> GET /911rlhagn0f6rcwf6ysfjd0c3xvmi3cp.narinfo
>  74:9  2 (_)
> 78:32  1 (_ system-error "fport_close" "~A" ("Bad file descrip…") …)
> In unknown file:
>0 (make-stack #t)
> ERROR: In procedure make-stack:
> ERROR: In procedure fport_close: Bad file descriptor
> GET /21fbk56f29242d246z79d11yv6bsayny.narinfo
> GET /mz2ysbhy69y90n6wcyjb1slpcacl08v1.narinfo

1: 

Thanks,
simon

bug#33409: guile-ssh build fail when run guix pull

[zimoun]

Hi,

Sorry for the late reply about guile-ssh and guix pull [1].

1: 

On Sat, 17 Nov 2018 at 07:50, "Feng Shu"  wrote:

> Some deprecated features have been used.  Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.  Set it to "no" to suppress
> this message.
> make[1]: Leaving directory 
> '/tmp/guix-build-guile-ssh-0.11.3.drv-0/guile-ssh-0.11.3/tests'

[...]

>   1555:38  6 (_ #)
> In guix/packages.scm:
>881:14  5 (cache! # # …)
> In unknown file:
>4 (_ # # #)
> In guix/grafts.scm:
> 304:4  3 (graft-derivation # # …)
> 182:4  2 (references-oracle # #)
>191:20  1 (_ _ _)
> In guix/store.scm:
>   1104:15  0 (_ # _ _)
>
> guix/store.scm:1104:15: Throw to key `srfi-34' with args `(# &nix-protocol-error [message: "build of 
> `/gnu/store/lnwp3cinar5yq9fy511wdg29lqwq7aqj-guile-ssh-0.11.3.drv' failed" 
> status: 100] c7e2c30>)'.
> guix pull: error: You found a bug: the program 
> '/gnu/store/hwrncjaf5yfi37i0pjg0saqx25phm828-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "0c7707d53e66839a2beae8c05eddc91ac5a6d5e1"; system: "i686-linux";
> host version: "3b362c8a8366b55a172817d7c347098accd3d56b"; pull-version: 1).
> Please report it by email to .

Does it still not work for you?  What is the status of this bug?


All the best,
simon

bug#28743: guix package dry-run upgrade incorrect behaviour with verbosity

[zimoun]

Hi,

This old bug [1] is about dry-run.  IIUC, it is not now fixed as shown
below.  However, there is another annoying thing about the option
’--verbosity’.

1: 

On Sun, 08 Oct 2017 at 10:06, Oleg Pykhalov  wrote:
> l...@gnu.org (Ludovic Courtès) writes:

> Previous discussion thread and attached debugging files:
> https://lists.gnu.org/archive/html/help-guix/2017-10/msg0.html
>
>
> After patching no new generation created.  But dry-run still shows
> available upgrades and that will be build some derivations.
>
>> I’ve pushed the above patch as eca16a3d1d9e6b2c064e0105c1015258bf2755f2.
>> Now we need to fix the UI side of things.

Let create a profile with a package without the grafts, then check the
update with dry-run, make the upgrade, check the dry-run upgrade again.
All seem fine, right?

--8<---cut here---start->8---
$ guix package -i r-shiny -p /tmp/foo --no-grafts 2>/dev/null
$ guix package -p /tmp/foo --upgrade --dry-run
The following package would be upgraded:
   r-shiny (dependencies or package changed)

The following derivation would be built:
   /gnu/store/bqsnn9k5jw3gklbzkzhknqpfikvl3bdy-profile.drv

$ guix package -p /tmp/foo --list-generations
Generation 1Sep 16 2021 09:04:48(current)
  r-shiny   1.6.0   out 
/gnu/store/gq31n44a6b815xlrh0zph6vwc7wqqw8c-r-shiny-1.6.0

$ guix package -p /tmp/foo --upgrade --dry-run
The following package would be upgraded:
   r-shiny (dependencies or package changed)

The following derivation would be built:
   /gnu/store/bqsnn9k5jw3gklbzkzhknqpfikvl3bdy-profile.drv

$ guix package -p /tmp/foo --upgrade
The following package will be upgraded:
   r-shiny (dependencies or package changed)

The following derivation will be built:
   /gnu/store/bqsnn9k5jw3gklbzkzhknqpfikvl3bdy-profile.drv

building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building database for manual pages...
building profile with 1 package...

$ guix package -p /tmp/foo --list-generations
Generation 1Sep 16 2021 09:04:48
  r-shiny   1.6.0   out 
/gnu/store/gq31n44a6b815xlrh0zph6vwc7wqqw8c-r-shiny-1.6.0

Generation 2Sep 16 2021 09:06:05(current)

$ guix package -p /tmp/foo --upgrade --dry-run
guix package: warning: nothing to do
--8<---cut here---end--->8---

However, let do the same thing with the option ’--verbosity=2’ (equal
deprecated ’--verbose’).

--8<---cut here---start->8---
$ rm -fr /tmp/foo*
$ guix package -i r-shiny -p /tmp/foo --no-grafts 2>/dev/null
$ guix package -p /tmp/foo --upgrade --dry-run --verbosity=2
The following package would be upgraded:
   r-shiny (dependencies or package changed)

$ guix package -p /tmp/foo --list-generations
Generation 1Sep 16 2021 09:04:48
  r-shiny   1.6.0   out 
/gnu/store/gq31n44a6b815xlrh0zph6vwc7wqqw8c-r-shiny-1.6.0

Generation 2Sep 16 2021 09:06:05(current)

$ guix package -p /tmp/foo --upgrade --verbosity=2
guix package: warning: nothing to do
--8<---cut here---end--->8---

Et voilà!  Still a bug.  Same with any other ’verbosity’ value.


All the best,
simon

bug#30896: Guix pull problems on armhf

[zimoun]

Hi Jelle,

On Wed, 21 Mar 2018 at 20:59, Jelle Licht  wrote:
> I have been running the binary Guix installation on top of Armbian on my
> Rockchip RK3288 (armhf) based computing platform.
>
> Up till about ~8 days ago, guix pull worked as intended. Recently,
> running guix pull leads to the following error message
> `./guix/build/pull.scm:44:20: ./guix/build/pull.scm:44:20: Throw to key
> `match-error' with args `("match" "no matching pattern"' [1]
>
>
> I already checked that re{moving,naming} `$HOME/.config/guix/latest'
> does not change anything. Neither does running `./pre-inst-env guix
> pull' from a git checkout.
>
> [1]: For the full log, see: https://paste.debian.net/1015219/

The situation about “guix pull” has changed a bit since this report from
2018 [2].  Is it still an issue?  If yes, could you do an update of the
current problem?  If no, let close it. :-)

2: 

Cheers,
simon

bug#29244: guix update -u always wants to update: python-wrapper & python-ipython

[zimoun]

Hi

On Fri, 10 Nov 2017 at 14:58, Benjamin Andresen  wrote:

> this is with an empty user account that has no packages installed before this:
>> guixsd% guix package -u
>> The following packages will be upgraded:
>> python-wrapper 3.5.3 → 3.5.3 
>> /gnu/store/xnb9bn2vgr3ch8zznsv23w65bb5psshh-python-wrapper-3.5.3
>> python-ipython 5.3.0 → 5.3.0 
>> /gnu/store/7lg8s2kc6k8fxbdx80ykz39kz2lwj08g-python-ipython-5.3.0
>>
>> nothing to be done

>From my understanding, this old bug [1] can be closed.  Now it is fixed,
aside the issue reported in bug#28743 [2].  Is it solved for you?

--8<---cut here---start->8---
$ guix package -i python-wrapper python-ipython -p /tmp/foo  2>/dev/null

$ guix package -p /tmp/foo --list-generations
Generation 1Sep 16 2021 09:24:06(current)
  python-wrapper3.8.2   out 
/gnu/store/nckjv3ccwdi6096j478gvns43ssbls2p-python-wrapper-3.8.2
  python-ipython7.9.0   out 
/gnu/store/y6rgmla9xr3sxdlv4lwnksy584w2l4xj-python-ipython-7.9.0

$ guix package -p /tmp/foo --upgrade --dry-run
guix package: warning: nothing to do

$ guix package -p /tmp/foo --upgrade
guix package: warning: nothing to do

$ guix package -p /tmp/foo --list-generations
Generation 1Sep 16 2021 09:24:06(current)
  python-wrapper3.8.2   out 
/gnu/store/nckjv3ccwdi6096j478gvns43ssbls2p-python-wrapper-3.8.2
  python-ipython7.9.0   out 
/gnu/store/y6rgmla9xr3sxdlv4lwnksy584w2l4xj-python-ipython-7.9.0
--8<---cut here---end--->8---


1: 
2: 

All the best,
simon

bug#33293: Documentation links in guix.info site are broken

[zimoun]

Hi Laura,

On Tue, 06 Nov 2018 at 18:12, Laura Lazzati  wrote:
> The latest documentation manual is: https://guix.info/manual/en/
>
> However when opening  https://guix.info links to documentation, I get a 404 
> not found for all the links I tried.
>
> For instance clicking defining packages in yellow in the main page redirects 
> to https://guix.info/manual/html_node/Package-Management.html
> Instead of:
> https://guix.info/manual/en/Defining-Packages.html#Defining-Packages

I think now it is fixed and all the redirections are correct. Closing?

All the best,
simon

bug#32440: localization of guix refresh

[zimoun]

Hi Julien,

On Tue, 14 Aug 2018 at 21:45, Julien Lepiller  wrote:

> I've just found out that guix refresh is not translated. Indeed,
> guix/script/refresh.scm is not listed in po/guix/POTFILES.in as it
> should be. Adding it to the file leads to an issue though. One of the
> entries generated in po files is the following:

The file ’guix/script/refresh.scm’ had been added to
’po/guix/POTFILES.in’ by the commit
c1eb04e6fd1c2cdb30b7b33d500b4ce54cabc27d.

Closing?

Cheers,
simon

bug#30619: Cuirass requires TLS certificates

[zimoun]

Hi,

On Tue, 27 Feb 2018 at 17:00, l...@gnu.org (Ludovic Courtès) wrote:
> Andreas Enge  skribis:
>
>> the cuirass service requires TLS certificates to do continuous integration
>> of guix (or more generally, git repositories served over https). This works
>> when nss-certs is installed as a global package in the system.
>>
>> Should the service depend on the nss-certs package? Or maybe take as an
>> optional configuration parameter a certificate package?
>
> I thought that, instead of assuming /etc/ssl/certs exists, the Cuirass
> service could use (file-append nss-certs 
> "/etc/ssl/certs/ca-certificates.crt").
> That would make it self-contained.
>
> That’s currently not possible though because this certificate bundle is
> built as a profile hook.  We would first need to export the procedure
> that creates bundles, possibly by moving it to a new (guix
> x509-certificates) module.

What is the status of this old bug [1]?  Well, if it is not fixed yet,
it seems a forgotten bug. :-)

1: 

Cheers,
simon

bug#28303: “guix import texlive keyval” fails

[zimoun]

Hi,

On Tue, 10 Oct 2017 at 08:51, l...@gnu.org (Ludovic Courtès) wrote:
> Ricardo Wurmus  skribis:
>
>> In the case of “keyval” I don’t know exactly what is wrong, but in
>> general it looks like the importer doesn’t use subversion from the store
>> but expects it to be available in the environment.
>
> For now, we could always return an error like “svn command not found” or
> similar?

I think this old bug [1] is fixed now.  The 2 examples works now and
from my understanding, I do not have SVN in my profiles as user.

Closing?

Cheers,
simon


--8<---cut here---start->8---
$ guix import texlive keyval
following redirection to `https://ctan.org/xml/1.2/pkg/keyval'...
command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "51265" 
"svn://www.tug.org/texlive/tags/texlive-2019.3/Master/texmf-dist/source/latex/keyval"
 "/tmp/guix-directory.lqE1vR/svn" failed with signal 11
guix import: warning: Could not determine source location.  Please manually 
specify the source field.
(package
  (name "texlive-latex-keyval")
  (version "1.15")
  (source #f)
  (build-system texlive-build-system)
  (arguments '(#:tex-directory "latex/keyval"))
  (home-page "http://www.ctan.org/pkg/keyval";)
  (synopsis "Process 'key=value' schemes")
  (description
"The package offered the first key-value decoder for LaTeX 2e; its original 
user was the graphicxgraphicx package, but it is widely used elsewhere in 
common LaTeX packages.  The package is part of the latex-graphicslatex-graphics 
bundle, which is one of the collections in the requiredLaTeX 
â\x80\x98requiredâ\x80\x99 set of packages.")
  (license lppl1.3c))

$ guix import texlive multirow
following redirection to `https://ctan.org/xml/1.2/pkg/multirow'...
command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "51265" 
"svn://www.tug.org/texlive/tags/texlive-2019.3/Master/texmf-dist/source/latex/multirow"
 "/tmp/guix-directory.UUm4ha/svn" failed with signal 11
guix import: warning: Could not determine source location.  Please manually 
specify the source field.
(package
  (name "texlive-latex-multirow")
  (version "2.8")
  (source #f)
  (build-system texlive-build-system)
  (arguments '(#:tex-directory "latex/multirow"))
  (home-page "http://www.ctan.org/pkg/multirow";)
  (synopsis
"Create tabular cells spanning multiple rows")
  (description
"The package has a lot of flexibility, including an option for specifying 
an entry at the â\x80\x9cnaturalâ\x80\x9d width of its text.  The package is 
distributed with the bigdelimbigdelim and bigstrutbigstrut packages, which can 
be used to advantage with \\multirow cells.")
  (license lppl1.3+))
--8<---cut here---end--->8---