bug#57878: Minimal reproducible setup

2022-10-12 Thread Liliana Marie Prikler
Am Sonntag, dem 02.10.2022 um 10:25 +0200 schrieb Konrad Hinsen:
> As for Liliana's idea of disabling deferred compilation : shouldn't
> it be sufficient to have all Emacs Lisp packages in Guix AOT-
> compiled?
>From personal experience, no.  Even if you compile code ahead of time,
there seem to be some leftovers that are deferred.  guix-emacs.el is an
oversight, but apart from that I also other leftovers (possibly from
init.el?)

> There would be nothing left to compile in deferred mode. A quick scan
> of the relevant page on Emacs Wiki
> (https://www.emacswiki.org/emacs/GccEmacs) suggests that some package
> manager do this.
In Guix, this is more or less a user choice – we advertised the
transformation by which you can opt-in to AOT compilation in a news
entry.  Also, enforcing ahead-of-time compilation does not fix the more
pressing issue of packages breaking with native compilation ;)

To quote Eli:
> More generally, we never expected people who have Emacs with native
> compilation available to want to disable it.  It made no sense to us
> during development of Emacs 28, and frankly, it still doesn't, at
> least to me.
I think this reasoning really falls flat in presence of any non-Emacs
package manager.  Like, obviously wanting to natively compile packages
managed by (dpkg, rpm, pacman, emerge, guix), but not natively
compiling a random elisp script you just downloaded from the web is a
legitimate use case.

Cheers





bug#58444: Make gtk use librsvg on aarch64 again.

2022-10-12 Thread pelzflorian (Florian Pelz)
close 58444
thanks

"pelzflorian (Florian Pelz)"  writes:
> "pelzflorian (Florian Pelz)"  writes:
>> I wrote a patch but probably it would rebuild the world.
> It does rebuild the world.  I will try with (or (target-aarch64?)
> (target-x86-64?)).

My other attempt also caused rebuilds.  Also it's not that important if
gtk+-2 uses an old librsvg.  I had thought GNUtoo's i686 fix (and thank
you for it) introduced a regression for aarch64, but had not noticed how
his use of (target-x86-64?) was a common pattern for e.g. emacs as well.
Perhaps it is better to remove the (target-x86-64?) checks as soon as
mrustc supports i686.

Sorry for the noise.  Closing.

Regards,
Florian





bug#57764: Corrupted store on top on Debian, you want the output

2022-10-12 Thread jbranso--- via Bug reports for GNU Guix
September 15, 2022 2:59 AM, "Maze"  wrote:

> I corrupted my store and it says you want the guix pull output, so
> please find it at the end of this message. Mostly I send it because guix
> asks, but (see below) at least 2 things broke on that machine, not sure
> it's related. I have to explain a little but I don't actually require or
> expect that a lot of indivudually-tailored help can be given by GNU in
> this case... It's a non-standard use case on more than one account.
> 
> I have been doing more than a few unsupported things with this installation.
> Over the week-end and Monday, 3 things stand out:
> 
> * I have been starting to use guix home on this guix which is not a guix
> system but which is on top of Debian. I have some user shepherd
> services. They still work as I'm writing this. I think this is
> unsupported though.
> 
> * I tried to install a guix system to a thumb drive. It is inconvenient
> to use the ISO so I decided to do it from Guix on top of Debian. When I

I personally do not understand your usecase.  For me, installing the 
guix system installer on a usb is as simple as:

wget https://path/to/guix/installer.iso
sudo dd if=installer.iso of=/dev/sdb status=progress && sync

I would rather do than than to try to build a custom iso image.  :)

Also do you wanna just take the plunge and install guix system?

It's super worth it!

It has been the most stable distro that I have ever used.

Thanks,

Joshua





bug#58451: cool-retro-term's fonts are broken

2022-10-12 Thread Eric Bavier
Hi Christine,

Thanks for the report. This should be fixed in 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=86ec52f66735b122b9035eba56516fd16f3be958

The "Cannot read property 'fontlist' of null" is still present, but was/is also 
present in the earlier 1.1.1 release, and seems to be mostly harmless.

Cheers,
`~Eric

On October 11, 2022 7:08:29 PM UTC, Christine Lemmer-Webber 
 wrote:
>I realize we've made some modifications to cool-retro-term's font stuff
>back in Bavier's original patches adding cool-retro-term.  Particularly,
>some mentions of fonts are emoved.  However, something has gone wrong,
>you can no longer increase font sizes, and there aren't really any fonts
>listed.  The culprit seems hinted by looking at the output from running
>cool-retro-term from another terminal:
>
>qrc:/Fonts.qml:206:1: Expected token `}'
>qrc:/Fonts.qml:206:1: Expected token `}'
>qrc:/ApplicationSettings.qml:173: TypeError: Cannot read property 'count' of 
>undefined
>qrc:/ApplicationSettings.qml:126: TypeError: Cannot read property 'fontlist' 
>of null
>
>I'm guessing the code that's trying to remove mentions of forbidden
>fonts is accidentally dropping a closing brace somehow.
>
>
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#22608: Module system thread unsafety and .go compilation

2022-10-12 Thread Maxim Cournoyer
Hi,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>> For the record, these issues should be fixed in Guile 2.2.4:
>>>
>>> 533e3ff17 * Serialize accesses to submodule hash tables.
>>> 46bcbfa56 * Module import obarrays are accessed in a critical section.
>>> 761cf0fb8 * Make module autoloading thread-safe.
>>>
>>> ‘guix pull’ now defaults to 2.2.4, so we’ll see if indeed those crashes
>>> disappear.
>>
>> I think we haven't seen these in the last 4 years!  We still have
>> references to https://bugs.gnu.org/15602 in our code base though;
>> although the upstream issue appears to have been fixed.  Could we remove
>> the workarounds now?
>
> The module thread-safety issue discussed here appears to be done.

Alright, I'm closing this one then.

> However the workarounds for  must remain:
> that specific issue is still there.

Thanks for the heads-up!

-- 
Maxim





bug#56322: [PATCH core-updates 0/3] Ruby packaging issues

2022-10-12 Thread Remco van 't Veer
Applied changes from feedback by Maxime Devos and rebased on
core-updates.

Remco van 't Veer (3):
  gnu: ruby: trigger autotools bootstrap
  gnu: ruby: fix unbundling of libffi for inheriting rubies
  gnu: ruby: regenerate parse.c

 gnu/packages/ruby.scm | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)


base-commit: 685110045c04a60bf18163aab1c230f944c871c9
-- 
2.37.3






bug#56322: [PATCH core-updates 3/3] gnu: ruby: regenerate parse.c

2022-10-12 Thread Remco van 't Veer
* gnu/packages/ruby.scm (baseruby, ruby-2.7): Use bootstrap baseruby to 
regenerate parse.c
---
 gnu/packages/ruby.scm | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index bd55d5ac6d..497271f442 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -188,7 +188,23 @@ (define-public ruby-2.7
 "test/ruby/test_process.rb"
 "test/ruby/test_system.rb"
 "tool/rbinstall.rb")
-   (("/bin/sh") (which "sh"))
+   (("/bin/sh") (which "sh"
+(native-inputs (list autoconf automake baseruby bison
+
+(define baseruby ;; for bootstrapping ruby's parser generator
+  (package
+(inherit ruby-2.7)
+(name "baseruby")
+(source (origin
+  (inherit (package-source ruby-2.7))
+  ;; override snippet to not include deletion of bundled parse.c
+  (snippet `(begin
+  ;; Remove bundled libffi
+  (delete-file-recursively "ext/fiddle/libffi-3.2.1")
+  ;; Trigger bootstap
+  (delete-file "configure")
+  (delete-file "aclocal.m4")
+(native-inputs (list autoconf automake
 
 (define-public ruby-3.0
   (package
-- 
2.37.3






bug#56322: [PATCH core-updates 2/3] gnu: ruby: fix unbundling of libffi for inheriting rubies

2022-10-12 Thread Remco van 't Veer
* gnu/packages/ruby.scm (ruby-3.0, ruby-3.1): Inherit package-source to ensure 
inclusion of unbundling snippet
---
 gnu/packages/ruby.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index 25d7aba933..bd55d5ac6d 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -196,6 +196,7 @@ (define-public ruby-3.0
 (version "3.0.4")
 (source
  (origin
+   (inherit (package-source ruby-2.7))
(method url-fetch)
(uri (string-append "http://cache.ruby-lang.org/pub/ruby/;
(version-major+minor version)
@@ -213,6 +214,7 @@ (define-public ruby-3.1
 (version "3.1.2")
 (source
  (origin
+   (inherit (package-source ruby-3.0))
(method url-fetch)
(uri (string-append "http://cache.ruby-lang.org/pub/ruby/;
(version-major+minor version)
-- 
2.37.3






bug#56322: [PATCH core-updates 1/3] gnu: ruby: trigger autotools bootstrap

2022-10-12 Thread Remco van 't Veer
* gnu/packages/ruby.scm (ruby-2.6, ruby-2.7): Remove autotools artifacts
---
 gnu/packages/ruby.scm | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/ruby.scm b/gnu/packages/ruby.scm
index e1b71a0a1a..25d7aba933 100644
--- a/gnu/packages/ruby.scm
+++ b/gnu/packages/ruby.scm
@@ -116,7 +116,9 @@ (define-public ruby-2.6
(snippet `(begin
;; Remove bundled libffi
(delete-file-recursively "ext/fiddle/libffi-3.2.1")
-   #t
+   ;; Trigger bootstap
+   (delete-file "configure")
+   (delete-file "aclocal.m4")
 (build-system gnu-build-system)
 (arguments
  `(#:test-target "test"
@@ -142,6 +144,7 @@ (define-public ruby-2.6
  (list readline openssl-1.1 libffi gdbm))
 (propagated-inputs
  (list zlib))
+(native-inputs (list autoconf automake))
 (native-search-paths
  (list (search-path-specification
 (variable "GEM_PATH")
@@ -185,10 +188,7 @@ (define-public ruby-2.7
 "test/ruby/test_process.rb"
 "test/ruby/test_system.rb"
 "tool/rbinstall.rb")
-   (("/bin/sh") (which "sh")))
- #t)
-(native-inputs
- (list autoconf
+   (("/bin/sh") (which "sh"))
 
 (define-public ruby-3.0
   (package
-- 
2.37.3






bug#58198: topological-sort does not sort topologically in case of diamonds

2022-10-12 Thread Maxime Devos



On 08-10-2022 20:13, Maxime Devos wrote:

I found a solution: [...]


It's buggy, it doesn't handle situations like

libnewsboat
  /   |
 |  regex-rs
 ||
strprintf.

Revised module is attached.
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2019 Ludovic Courtès 
;;; Copyright © 2022 Maxime Devos 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

;; To be used by the implementation of workspaces.
;; Extracted from (guix import utils), and changed from (guix sets)
;; to a guile-pfds equivalent.
(define-module (topological-sort)
  #:export (topological-sort topological-sort*)
  #:use-module (srfi srfi-1)
  #:use-module ((srfi srfi-69) #:select (hash))
  #:use-module ((ice-9 match) #:select (match))
  ;; XXX: Cuirass compiles even build-side only modules.
  #:autoload (pfds hamts) (make-hamt hamt-ref hamt-set))

(define (topological-sort nodes
  node-dependencies
  node-name)
  "Perform a breadth-first traversal of the graph rooted at NODES, a list of
nodes, and return the list of nodes sorted in topological order.  Call
NODE-DEPENDENCIES to obtain the dependencies of a node, and NODE-NAME to
obtain a node's uniquely identifying \"key\"."
  ;; It is important to do a breadth-first traversal instead of a depth-first
  ;; traversal -- a simpler depth-first traversal has caused failures in the
  ;; past.
  (define (is-dependency? potential-dependency potential-dependents)
(member (node-name potential-dependency)
	(map node-name
		 (append-map node-dependencies potential-dependents
  (let loop ((unexpanded-nodes nodes)
	 (result '()) ; in reverse topological order
	 ;; Identical to 'result', except for using a different data
	 ;; structure.
	 (visited (make-hamt hash equal?)))
(if (null? unexpanded-nodes)
	(reverse result) ; done!
	(let inner-loop ((current-unexpanded-nodes unexpanded-nodes)
			 (later-unexpanded-nodes '())
			 (result result)
			 (visited visited)
			 (progress? #false))
	  (match current-unexpanded-nodes
	((first . current-unexpanded-nodes)
	 (cond ((hamt-ref visited (node-name first) #false)
		;; Already visisted, nothing to do!
		(inner-loop current-unexpanded-nodes
later-unexpanded-nodes result visited
#true))
		   ;; XXX: would be nice to not recompute
		   ;; 'node-dependencies'.
		   ((is-dependency? first current-unexpanded-nodes)
		;; The node was a dependency of something on the previous
		;; level, but also of something of the current level.
		;; Delay it for later.
		(inner-loop current-unexpanded-nodes
(cons first later-unexpanded-nodes)
result
visited
progress?))
		   (#true
		;; Expand 'first', putting dependencies in
		;; 'later-unexpanded-nodes'.
		(inner-loop current-unexpanded-nodes
(append (node-dependencies first)
	later-unexpanded-nodes)
(cons first result)
(hamt-set visited (node-name first) #true)
#true
	(()
	 ;; All nodes on the current level are expanded, descend!
	 ;; But first check for a cycle.
	 (if progress?
		 (loop later-unexpanded-nodes result visited)
		 (error "cycle"

(define (topological-sort* nodes node-dependencies node-name)
  "Like TOPOLOGICAL-SORT, but don't assume that NODES are roots.  Instead,
consider all nodes in the closure of NODES."
  (define artificial-root (make-symbol "root")) ; uninterned, fresh symbol
  (define nodes* (list artificial-root))
  (define (node-dependencies* node*)
(if (eq? node* artificial-root)
	nodes
	(node-dependencies node*)))
  (define (node-name* node*)
(if (eq? node* artificial-root)
	artificial-root
	(node-name node*)))
  (define (proper-node? node*)
(not (eq? node* artificial-root)))
  (filter proper-node?
	  (topological-sort nodes* node-dependencies* node-name*)))


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


bug#58452: openldap fails to cross-compile to aarch64 (strip errors) (was: guix pack cross-compile failed to build docker img of openldap for aarch64)

2022-10-12 Thread Maxime Devos

retitle 58452 openldap fails to cross-compile to aarch64 (strip errors)
thanks

"guix pack" and Docker seem unrelated here, rather it seems to be 
regular cross-compilation bug to me that could presumably be reproduced

with "guix build openldap --target=aarch64-linux-gnu".

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


bug#53519: python-seaborn build failure

2022-10-12 Thread Arun Isaac


Closing since python-seaborn now builds successfully on the latest
master.

I have also sent a new patch updating python-seaborn to
0.12.0. https://issues.guix.gnu.org/58466