bug#27447: pelican-quickstart produces files with store path shebangs

[Mark H Weaver]

reopen 27447
thanks

Hi Simon,

zimoun  writes:

> On Fri, 18 Dec 2020 at 21:10, zimoun  wrote:
>> On Thu, 22 Jun 2017 at 12:35, ng0  wrote:
>
>>> In a pelican directory after running pelican-quickstart:
>>>
>>> egrep -nr "store"
>>> …
>>> pelicanconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>>> develop_server.sh:1:#!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash
>>> publishconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>>>
>>> We have a couple more bugs like this. If they are already grouped,
>>> add this bug to them.
>>
>> What are these other “couple more bugs like this”?
>>
>> 
>
> No moreinfo so I am closing.  If I am missing something, then please
> reopen it.

The lack of response about the "couple more bugs like this" does not
invalidate the bug reported in this bug report.  I think it was merely a
suggestion that this bug might possibly be merged with other similar
bugs.  The key point is that we don't need an answer to that question to
investigate/fix this bug.

Unless we have reason to believe that 'pelican-quickstart' is no longer
embedding store paths in the generated files, I think we should keep
this bug open.  Does that make sense?

Regards,
  Mark

bug#45826: SBCL / Common Lisp packages fail to build on aarch64

[Leo Famulari]

On Wed, Jan 13, 2021 at 10:03:47PM +0100, Guillaume Le Vaillant wrote:
> I tried to bootstrap sbcl using ecl instead of clisp, using
> "guix build -s aarch64-linux sbcl" on a x86-64 machine because I don't
> have any arm64 hardware, but it failed with the same memory fault.

Thanks! On #guix, Efraim reported that the builds were succeeding on his
aarch64 hardware. So, I'm not sure what's going on :/

bug#44871: arcan: update to 0.6

[Vinícius dos Santos Oliveira]

> Would you like to give it a try?

Maxim,

I did give it a try, but it is too much for me. I'm still a newbie in guix
and I cannot undertake this job just yet.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

bug#45826: SBCL / Common Lisp packages fail to build on aarch64

[Guillaume Le Vaillant]

Leo Famulari  skribis:

> I noticed that many Common Lisp or SBCL-related packages are failing to
> build on the aarc64 platform on our build farm, due the failure to build
> SBCL:
>
> From the log of :
>
> --
> //entering make-target-2.sh
> //doing warm init - compilation phase
> This is SBCL 2.1.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at .
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> Initial page table:
> Gen  Boxed   CodeRaw  LgBox LgCode  LgRaw  Pin   Alloc Waste  
>   Trig  WP GCs Mem-age
>  6 397250  0  0  0  0042335440 66352 
> 200 647   0  0.
>Total bytes allocated=  42335440
>Dynamic-space-size bytes =3221225472
> COLD-INIT... (Length(TLFs)= 9736)
> Disassembler: 72 printers, 0 prefilters, 4 labelers
> CORRUPTION WARNING in SBCL pid 1774 tid 1774:
> Memory fault at 0xfffa (pc=0x1002199f70)
> The integrity of this image is possibly compromised.
> Exiting.
> Error opening /dev/tty: No such device or address
> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> ldb> 
> real  0m6.120s
> user  0m5.958s
> sys   0m0.137s
> command "sh" "make.sh" "clisp" 
> "--prefix=/gnu/store/j1ciw4dc8iskd5fdcw0s1ba08kkg7vx6-sbcl-2.1.0" 
> "--dynamic-space-size=3072" "--with-sb-core-compression" 
> "--with-sb-xref-for-internals" failed with status 1
> --
>
> It appears that SBCL can support this platform. However, until we make
> it work, I plan to remove aarch64 from the "supported-systems" of sbcl,
> to avoid attempting these builds.

I tried to bootstrap sbcl using ecl instead of clisp, using
"guix build -s aarch64-linux sbcl" on a x86-64 machine because I don't
have any arm64 hardware, but it failed with the same memory fault.


signature.asc
Description: PGP signature

bug#24156: QEMU '-net bridge' --> "qemu-system-x86_64: -net bridge: bridge helper failed"

[zimoun]

Hi

On Mon, 11 Jan 2021 at 16:38, George Clemmer  wrote:
>> On Fri, 18 Dec 2020 at 20:47, zimoun  wrote:
>>> On Thu, 04 Aug 2016 at 22:40, myglc2  wrote:
>>
 Motivation: bridging or routing is required to enable a connection to be
 made inward to a QEMU VM. TAP seems like the best of the available
 solutions. But connecting to a TAP device produces an error when the
 QEMU bridge helper fails.
>>
>> If no moreinfo is provided to detail what could the next actionable
>> step, then I will close this more-than-3-years bug report in the coming
>> days.

[...]

> I can't easily provide more detail as I am not currently use QEMU.

Therefore I am closing.  Feel free to reopen it and discuss the wishlist
on guix-devel.


All the best,
simon

bug#45845: emacs-doom-modeline: Some icons are missing

[Luis Felipe via Bug reports for GNU Guix]

## Steps to reproduce

1. guix install emacs-doom-modeline
2. Start Emacs
3. M-x doom-modeline-mode

## Expected result

Doom modeline and its icons display correctly.

## Unexpected result

Doom modeline is displayed, but some of its icons are missing. You only see 
Unicode placeholders.

To be able to see the appropriate icons, one have to perform additional steps:

1. guix install emacs-all-the-icons
2. Start Emacs
3. M-x all-the-icons-install-fonts

I would expect "guix install emacs-doom-modeline" to install 
emacs-all-the-icons, and the latter to install any required font packages.

## System information

GNU Emacs 27.1
emacs-doom-modeline 3.0.0
GNU Guix efa773f

---
Luis Felipe López Acevedo
https://luis-felipe.gitlab.io/

bug#40887: No substitutes for libreoffice / vigra

[Maxim Cournoyer]

Hi Mathieu,

Mathieu Othacehe  writes:

> Hello,
>
>>> Does Cuirass honor this property? In the past, the timeout and
>>> max-silent-time properties were ignored by Cuirass:
>
> Until recently Cuirass didn't honor "max-silent-time" and "timeout"
> properties. However, the "wip-offload" branch adds support for those two
> properties between other things.
>
> Berlin is running a Cuirass instance based on that branch, so those
> properties should now be honored.

Thanks for the heads up, and for your work or Cuirass!

Maxim

bug#34934: deeptools is not reproducible

[Maxim Cournoyer]

This is no longer an issue.

Closing.

Maxim

bug#34935: nanopolish is not reproducible

[Maxim Cournoyer]

This is no longer an issue.

Closing.

Maxim

bug#35112: python-cffi is not reproducible

[Maxim Cournoyer]

Closing, as I can no longer reproduce this problem.

Maxim

bug#33213: python-3/fixed and python-minimal test_socket.py

[Maxim Cournoyer]

Hello,

Nam Nguyen  writes:

> Hi,
>
> python has a memory leak in the test for test_socket.py, and it was
> fixed in commit 90aeaee861845142843a0f988fa4ff016c723cdb.
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=90aeaee861845142843a0f988fa4ff016c723cdb
>
> More information from IRC:
> 8<
>  There is a bug in Python 3 which causes the test suite to run
> out of memory on recent kernels:
> https://bugs.python.org/issue34587
>  Unfortunately the only workaround I can think of is removing
> "/tmp/guix-build-python-3.6.5.drv-0/Lib/test/test_socket.py" some
> time during the build (but before the check phase).

This problem was supposed to be fixed upstream [0], but I tried and it
still hangs.  Oh well.

At any rate, the test is disabled in Guix.

Closing,

Thanks for the report!

Maxim


[0]  https://bugs.python.org/issue34587

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[Andreas Enge]

Am Wed, Jan 13, 2021 at 11:39:19AM +0100 schrieb Ludovic Courtès:
> ISL, MPFI, and GMP-ECM haven’t migrated, it seems.

gmp-ecm has migrated to gitlab.inria.fr; I just pushed a commit with an
updated URI. Besides the automatically created gitlab releases with git
snapshots, the maintainer also uploads a release tarball. I chose to use
the latter, which requires to manually update a hash together with the
version number upon a new release.

Andreas

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[Ludovic Courtès]

help-debb...@gnu.org (GNU bug Tracking System) skribis:

> We can already change Scotch and CMH to ‘git-fetch’ I think.

For Scotch, the ‘v6.1.0’ tag at gitlab.inria.fr provides different
content than the tarball on gforge:

Nur en /tmp/scotch_6.1.0/: bin
Nur en /tmp/scotch_6.1.0/doc/src/ptscotch: p.ps
Nur en /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout: .gitignore
Nur en /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout: .gitlab-ci.yml
Nur en /tmp/scotch_6.1.0/: include
Nur en /tmp/scotch_6.1.0/: lib
diff -ru /tmp/scotch_6.1.0/src/libscotch/library.h /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout/src/libscotch/library.h
--- /tmp/scotch_6.1.0/src/libscotch/library.h	1970-01-01 01:00:01.0 +0100
+++ /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout/src/libscotch/library.h	1970-01-01 01:00:01.0 +0100
@@ -67,8 +67,6 @@
 
 /*+ Integer type. +*/
 
-#include 
-
 typedef DUMMYIDX SCOTCH_Idx;
 
 typedef DUMMYINT SCOTCH_Num;
diff -ru /tmp/scotch_6.1.0/src/libscotch/Makefile /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout/src/libscotch/Makefile
--- /tmp/scotch_6.1.0/src/libscotch/Makefile	1970-01-01 01:00:01.0 +0100
+++ /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout/src/libscotch/Makefile	1970-01-01 01:00:01.0 +0100
@@ -2320,28 +2320,6 @@
 	common.h\
 	scotch.h
 
-library_graph_diam$(OBJ)	:	library_graph_diam.c			\
-	module.h\
-	common.h\
-	graph.h	\
-	scotch.h
-
-library_graph_diam_f$(OBJ)	:	library_graph_diam.c			\
-	module.h\
-	common.h\
-	scotch.h
-
-library_graph_induce$(OBJ)	:	library_graph_diam.c			\
-	module.h\
-	common.h\
-	graph.h	\
-	scotch.h
-
-library_graph_induce_f$(OBJ)	:	library_graph_diam.c			\
-	module.h\
-	common.h\
-	scotch.h
-
 library_graph_io_chac$(OBJ)	:	library_graph_io_chac.c			\
 	module.h\
 	common.h\
diff -ru /tmp/scotch_6.1.0/src/libscotchmetis/library_metis.h /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout/src/libscotchmetis/library_metis.h
--- /tmp/scotch_6.1.0/src/libscotchmetis/library_metis.h	1970-01-01 01:00:01.0 +0100
+++ /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout/src/libscotchmetis/library_metis.h	1970-01-01 01:00:01.0 +0100
@@ -106,7 +106,6 @@
 */
 
 #ifndef SCOTCH_H  /* In case "scotch.h" not included before */
-#include 
 typedef DUMMYINT SCOTCH_Num;
 #endif /* SCOTCH_H */
 
diff -ru /tmp/scotch_6.1.0/src/libscotchmetis/library_parmetis.h /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout/src/libscotchmetis/library_parmetis.h
--- /tmp/scotch_6.1.0/src/libscotchmetis/library_parmetis.h	1970-01-01 01:00:01.0 +0100
+++ /gnu/store/h84nd9h3131l63y4rllvzpnk6q0dsaq2-scotch-6.1.0-checkout/src/libscotchmetis/library_parmetis.h	1970-01-01 01:00:01.0 +0100
@@ -106,7 +106,6 @@
 */
 
 #ifndef SCOTCH_H  /* In case "scotch.h" not included before */
-#include 
 typedef DUMMYINT SCOTCH_Num;
 #endif /* SCOTCH_H */
 

There’s not much we can do if upstream isn’t more cautious though.
Perhaps we can still update to the “new” 6.1.0, maybe labeling it
“6.1.0b”?

Attached a tentative patch.

Thanks,
Ludo’.

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index 7866bcc6eb..4f8f79052d 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -12,7 +12,7 @@
 ;;; Copyright © 2015 Fabian Harfert 
 ;;; Copyright © 2016 Roel Janssen 
 ;;; Copyright © 2016, 2018, 2020 Kei Kebreau 
-;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès 
+;;; Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Ludovic Courtès 
 ;;; Copyright © 2016 Leo Famulari 
 ;;; Copyright © 2016, 2017 Thomas Danckaert 
 ;;; Copyright © 2017, 2018, 2019, 2020 Paul Garlick 
@@ -3083,13 +3083,15 @@ implemented in ANSI C, and MPI for communications.")
   (package
 (name "scotch")
 (version "6.1.0")
-(source
- (origin
-  (method url-fetch)
-  (uri (string-append "https://gforge.inria.fr/frs/download.php/";
-  "latestfile/298/scotch_" version ".tar.gz"))
+(source (origin
+  (method git-fetch)
+  (uri (git-reference
+(url "https://gitlab.inria.fr/scotch/scotch";)
+(commit (string-append "v" version
+  (file-name (git-file-name name version))
   (sha256
-   (base32 "1184fcv4wa2df8szb5lan6pjh0raarr45pk8ilpvbz23naikzg53"))
+   (base32
+"164jqsy75j7zfnwngj10jc4060shhxni3z8ykklhqjykdrinir55"))
   (patches (search-patches "scotch-build-parallelism.patch"
"scotch-integer-declarations.patch"
 (build-system gnu-build-system)

bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter

[Ludovic Courtès]

Hi Chris,

Christopher Baines  skribis:

> I might have managed to reproduce the error happening on the daemon
> side:
>
> → /gnu/store/4j8vn0gbqz5adj1y02nnwcfwmqsjgj8s-guix-1.2.0-6.799f066/bin/guix 
> substitute --query
> info /gnu/store/3c01q1f16kljfry70qjg6cs6k8winfzg-guix-package-cache 
> /gnu/store/6lk8anal4s62gk3d30vgxppykbd5jcfj-guix-85e97c969 
> /gnu/store/9zl2zbh3q2jnbfvxgnhw8j3f637ni7z4-guix-cli 
> /gnu/store/ihricijvy16zwkd2n671xlyrn02sqhf9-guix-manual 
> /gnu/store/m3j427qnlp81vsdj3x9ds7s4i051r1vz-guix-system-tests 
> /gnu/store/mbv9j7wwqvwnr5awzbi126jdsj3h64h5-guix-packages 
> /gnu/store/n2m1ay7kpa5f4fls4vvcy46ar1fdl0wk-guix-system 
> /gnu/store/p4q9ajlb3l7x8xglqs6fflch2iwjqwaj-guix-module-union 
> /gnu/store/snhx33fgjj2xnc5vy96sr3c8jqw9c7s0-guix-85e97c969-modules 
> /gnu/store/vnrlvz9pxl5qrpy5x8y51v6awz7yzn8q-guix-packages-base 
> /gnu/store/z4wj18vyzaas2yqb0577cc3japy4fi7z-guix-config 
> /gnu/store/zdjfbsj1a94vdbbg9r0cx4jcqnwxazxs-guix-translated-texinfo
> Backtrace:
> In ice-9/boot-9.scm:
>   1736:10  5 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>4 (apply-smob/0 #)
> In ice-9/boot-9.scm:
> 718:2  3 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  2 (_ #(#(#)))
> In guix/ui.scm:
>   2127:12  1 (run-guix-command _ . _)
> In guix/scripts/substitute.scm:
>1256:4  0 (guix-substitute . _)
>
> guix/scripts/substitute.scm:1256:4: In procedure guix-substitute:
> Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.

It’s interesting that we’re not seeing 500 here, but a bad response.

I tried reproducing it locally (running “sudo killall guix-daemon” after
I had started “guix publish”, and then running a command similar to the
one above) but I failed: I get a proper 500 response, which ‘guix
substitute’ gracefully interprets as a transient error.

We could be defensive and catch 'bad-response.  The problem is that
there are other exceptions thrown by (web http) et al. and they’re not
quite documented so it’s not clear to me how to do it nicely.

Thoughts?

Ludo’.

bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter

[Ludovic Courtès]

I forgot to mention: running “sudo herd restart guix-publish” on berlin
a couple of hours ago solved the immediate problem.

Ludo’.

bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter

[Ludovic Courtès]

Hi,

Mathieu Othacehe  skribis:

> There are errors in "/var/log/guix-publish.log" that could be the cause
> of this problem I think.
>
> GET /7m6mlzh0d6nifdxhaij7varg4q7lqdj4.narinfo
> In guix/scripts/publish.scm:
> 482:4  7 (render-narinfo/cached # …)
>487:12  6 (_ . _)
> In guix/store.scm:
>1021:9  5 (_ # "7m6mlzh0d6n…")
> 619:2  4 (write-buffered-output #)
> In unknown file:
>3 (force-output #)
> In guix/store.scm:
> 917:4  2 (write #vu8(29 0 0 0 0 0 0 0 32 0 0 0 0 0 0 0 55 109 …) …)
> In unknown file:
>1 (put-bytevector # #vu8(29 0 …) …)
> In ice-9/boot-9.scm:
>   1669:16  0 (raise-exception _ #:continuable? _)
> In procedure fport_write: Broken pipe

As discussed on IRC today, the EPIPE above comes from talking to
guix-daemon, meaning that the store connection shown in the backtrace
has been closed by guix-daemon.

This can happen if guix-daemon was restarted but ‘guix publish’ wasn’t:
‘guix publish’ opens only one connection to the store at startup time,
and then never tries to re-open it.  There was an old bug on this topic:

  https://issues.guix.gnu.org/26705

Back then I marked it as ‘wontfix’ because:

  1. Losing a connection to the daemon Does Not Happen™ in normal
 conditions.  Namely, upon ‘herd restart guix-daemon’, ‘guix
 publish’ is automatically restarted.  One situation where ‘guix
 publish’ is not restarted is if one does “killall guix-daemon” or
 similar.  (Perhaps that’s something to fix in the Shepherd?)

  2. Catching EPIPE in the right place is tricky.  Basically we’d
 probably need to install a 'system-error handler around each RPC
 (and offer callers a way to choose the EPIPE handling strategy),
 which would incur additional overhead.

Ludo’.

bug#45758: Issue with emacs/fontconfig

[John Soo]

 
 

 
 
 
 This was closed after some debugging on irc
 
 
 

 
   

bug#44062: Fixed in 45050

[John Soo]

 
 

 
 
 
 If this is in error, can you open a new ticket?Thanks!
 
 
 

 
   

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[Andreas Enge]

Hello,

Am Wed, Jan 13, 2021 at 11:39:19AM +0100 schrieb Ludovic Courtès:
> ISL, MPFI, and GMP-ECM haven’t migrated, it seems.  CMH is now at
>  but without its tarballs.
> 
> Andreas, do you happen to know about the status of these?

For CMH, the tarballs are available from its (new) homepage:
   http://www.multiprecision.org/cmh/home.html
I can update the location at the next release, which I should prepare
some time soon (TM).

Concerning MPFI and GMP-ECM, I can ask their respective authors to keep
me updated; I have no doubts they are going to migrate their projects.

For ISL, I do not know.

Andreas

bug#45836: cups-service-type duplicates lp group

[Leo Prikler]

Hi Ludo,

Am Mittwoch, den 13.01.2021, 12:28 +0100 schrieb Ludovic Courtès:
> Hi Leo,
> 
> Leo Prikler  skribis:
> 
> > it has come to my attention due to the recent reporting of #45830
> > and
> > some conversation in IRC, that cups-service-type adds an lp group,
> > which is already defined in %base-groups.  Since both share the
> > same
> > definition, this is not too big an issue, but it prohibits us from
> > using a hard error for #45770.
> > 
> > I can currently think of two solutions: Either remove the lp group
> > from
> > cups-service-type or remove it from base-groups.  Neither sounds
> > particularly awesome.  Perhaps we could also delete identical
> > duplicates before asserting that there are none for #45770, but
> > that
> > sounds like a little much effort.  Any ideas how else to solve
> > this?
> 
> I’d be pragmatic here:
> 
>   1. Ignore duplicates that are identical (don’t report them).
Is that still not a problem, because either definition could change?

>   2. Remove “lp” from %base-groups since it has no use without CUPS
>  (right?).
That's probably true, but I fear, that some have already added "lp" to
their config.scm.  Would that cause issues?  We could also add CUPS to
%base-services or %desktop-services in some way, but that would
probably cause issues with configurations, that already have it.

Regards,
Leo

bug#45836: cups-service-type duplicates lp group

[Ludovic Courtès]

Hi Leo,

Leo Prikler  skribis:

> it has come to my attention due to the recent reporting of #45830 and
> some conversation in IRC, that cups-service-type adds an lp group,
> which is already defined in %base-groups.  Since both share the same
> definition, this is not too big an issue, but it prohibits us from
> using a hard error for #45770.
>
> I can currently think of two solutions: Either remove the lp group from
> cups-service-type or remove it from base-groups.  Neither sounds
> particularly awesome.  Perhaps we could also delete identical
> duplicates before asserting that there are none for #45770, but that
> sounds like a little much effort.  Any ideas how else to solve this?

I’d be pragmatic here:

  1. Ignore duplicates that are identical (don’t report them).

  2. Remove “lp” from %base-groups since it has no use without CUPS
 (right?).

Thanks,
Ludo’.

bug#45828: guix build: error: got unexpected path `Backtrace:' from substituter

[Mathieu Othacehe]

Hello,

There are errors in "/var/log/guix-publish.log" that could be the cause
of this problem I think.

--8<---cut here---start->8---
GET /7m6mlzh0d6nifdxhaij7varg4q7lqdj4.narinfo
In guix/scripts/publish.scm:
482:4  7 (render-narinfo/cached # …)
   487:12  6 (_ . _)
In guix/store.scm:
   1021:9  5 (_ # "7m6mlzh0d6n…")
619:2  4 (write-buffered-output #)
In unknown file:
   3 (force-output #)
In guix/store.scm:
917:4  2 (write #vu8(29 0 0 0 0 0 0 0 32 0 0 0 0 0 0 0 55 109 …) …)
In unknown file:
   1 (put-bytevector # #vu8(29 0 …) …)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)
In procedure fport_write: Broken pipe
--8<---cut here---end--->8---

Thanks,

Mathieu

bug#42162: gforge.inria.fr to be taken off-line in Dec. 2020

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

>> The following packages have their source on gforge.inria.fr:
>>
>> scheme@(guile-user)> ,pp packages-on-gforge
>> $7 = (#> 7f632401a640>
>>  #
>>  #

[...]

> I ran the code you had attached to the original message and got:
>
> ,pp packages-on-gforge
> $2 = ()
> scheme@(guile-user)> ,pp archived-source
> $3 = ()

Oh, it’s due to a bug, where the wrong ‘origin?’ predicate was taken.
After hiding the “wrong” one:

  #:use-module ((guix swh) #:hide (origin?))

I get:

--8<---cut here---start->8---
scheme@(guix-user)> ,pp packages-on-gforge
$1 = (#
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #)
scheme@(guix-user)> ,pp archived-source
$2 = (#
 #
 #
 #
 #
 #
 #
 #)
--8<---cut here---end--->8---

Attaching the fixed script for clarity.

BTW, gforge.inria.fr shutdown has been delayed a bit, but most active
projects have started migrating to gitlab.inria.fr or elsewhere, so
hopefully we should be able to start updating our package recipes
accordingly.  It’s likely, though, that tarballs were lost in the
migration.

For example, Scotch is now at .
 shows “assets” for
the 6.1.0 release, but these are auto-generated tarballs instead of the
handcrafted one found on gforge.inria.fr (but this one is fine since its
tarball is archived as-is on SWH.)

ISL, MPFI, and GMP-ECM haven’t migrated, it seems.  CMH is now at
 but without its tarballs.

Andreas, do you happen to know about the status of these?

We can already change Scotch and CMH to ‘git-fetch’ I think.  That
doesn’t solve the problem for earlier Guix revisions though, and I hope
Disarchive will save us!

Thanks,
Ludo’.

(use-modules (guix) (gnu)
 (guix svn-download)
 (guix git-download)
 ((guix swh) #:hide (origin?))
 (ice-9 match)
 (srfi srfi-1)
 (srfi srfi-26))

(define (gforge? package)
  (define (gforge-string? str)
(string-contains str "gforge.inria.fr"))

  (match (package-source package)
((? origin? o)
 (match (origin-uri o)
   ((? string? url)
(gforge-string? url))
   (((? string? urls) ...)
(any gforge-string? urls));or 'find'
   ((? git-reference? ref)
(gforge-string? (git-reference-url ref)))
   ((? svn-reference? ref)
(gforge-string? (svn-reference-url ref)))
   (_ #f)))
(_ #f)))

(define packages-on-gforge
  (fold-packages (lambda (package result)
   (if (gforge? package)
   (cons package result)
   result))
 '()))

(define archived-source
  (filter (lambda (package)
(let* ((origin (package-source package))
   (hash  (origin-hash origin)))
  (lookup-content (content-hash-value hash)
  (symbol->string
   (content-hash-algorithm hash)
  packages-on-gforge))

bug#40887: No substitutes for libreoffice / vigra

[Leo Famulari]

On Wed, Jan 13, 2021 at 09:12:18AM +0100, Mathieu Othacehe wrote:
> 
> Hello,
> 
> >> Does Cuirass honor this property? In the past, the timeout and
> >> max-silent-time properties were ignored by Cuirass:
> 
> Until recently Cuirass didn't honor "max-silent-time" and "timeout"
> properties. However, the "wip-offload" branch adds support for those two
> properties between other things.
> 
> Berlin is running a Cuirass instance based on that branch, so those
> properties should now be honored.

That's great, thanks!

bug#45835: (gnu machine digital-ocean) installs old Guix

[Mathieu Othacehe]

Hello Ricardo,

> I also wonder if there might not be a better way to deploy Guix quickly,
> for example by using a relocatable pack of Guix and using “guix copy”
> instead of executing a shell script.

I think that building a Guix System image and creating a droplet out of
it using the DigitalOcean API, as I described here[1] would be a better
solution.

Thanks,

Mathieu

[1]: https://othacehe.org/hosting-a-blog-using-only-scheme.html

bug#40887: No substitutes for libreoffice / vigra

[Mathieu Othacehe]

Hello,

>> Does Cuirass honor this property? In the past, the timeout and
>> max-silent-time properties were ignored by Cuirass:

Until recently Cuirass didn't honor "max-silent-time" and "timeout"
properties. However, the "wip-offload" branch adds support for those two
properties between other things.

Berlin is running a Cuirass instance based on that branch, so those
properties should now be honored.

Thanks,

Mathieu