bug#54899: Add version metadata check to Python sanity-check

[Maxim Cournoyer]

Hello Guix,

Many Python packages rely on third party packages such as
python-setuptools-scm or python-versioneer to compute the version string
used as part of the packaging.

When these tools are missing, the version string ends up being '0.0.0'
in the resulting PKG-INFO package metadata file, which is wrong and
breaks Python build systems dependency verification.

This issue is about adding a check to our already existing sanity-check
phase/script so that it ensure the version string in the built package
metadata is not 0.0.0 (unless defined as such at the level of the Guix
package).

Thanks,

Maxim

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Maxime Devos]

Attila Lendvai schreef op di 12-04-2022 om 19:47 [+]:
> and i can't get rid of this^ warning. i installed glibc-locales to
> root and my user, reconfigured, restarted the guix-daemon.
> 
> which is probably the cause of the ultimate error:
> 
> warning: failed to delete .git/refs/tags/v??.2.0: No such file or
> directory
> r:sha256 hash mismatch for...
> 
> the daemon starts from an empty env:
> 
> https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/build.cc#n1590
> 
> and then copies the env from the derivation, but it doesn't seem to
> contain any LANG value. i assume guile is also launched then without
> a LANG env. BTW, guile could be more informative in its warning, too.

Some remarks:

  * LANG should be set, because it is in #:leaked-env-vars (see
guix/git-download.scm).  I don't know whose LANG it is though
-- the user's, or the daemon's?

  * To install an UTF-8 locale, you need glibc-locales (or possibly
glibc-utf8-locales)  (At least, for now.  Upstream has some plans
for including a C.UTF-8 locale so maybe eventually we can fallback
to C.UTF-8.)

  * This locale data needs to be in $GUIX_LOCPATH.

  * GUIX_LOCPATH is not leaked.

  * Even if it was, I don't think that /gnu/store/...glibc-locales
would be accessible from the build container (though you could give
it a try?).

  * So perhaps GUIX_LOCPATH needs to be set in the gexp in
guix/git-download.scm, + some setlocale as done by
gnu-build-system.

  * Long-term, it could be interesting to remove the
‘file name = string encoded in current locale's encoding’
assumption from Guile.

  * svn-download, hg-download, bzr-download and cvs-download
probably have the same issue.

Greetings,
Maxime.


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

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Attila Lendvai]

i'm trying to build a golang package that i have just imported. its repo has a 
tag with unicode in it, namely v½.2.0, as observable at 
https://github.com/klauspost/pgzip/tags

(define-public the-pkg
  (package
(name "go-github-com-klauspost-pgzip")
(version "1.0.2-0.20170402124221-0bf5dcad4ada")
(source
  (origin
(method git-fetch)
(uri (git-reference
   (url "https://github.com/klauspost/pgzip;)
   (commit "0bf5dcad4ada")))
(file-name (git-file-name name version))
(sha256
  (base32 "0dgp2iljvhibzxia1g3lsfg4bjmfh4kf0bfrmfi7sd49hwhrvk7s"
(build-system go-build-system)
(arguments '(#:skip-build? #t #:import-path "github.com/klauspost/pgzip"))
(home-page "https://github.com/klauspost/pgzip;)
(synopsis "pgzip")
(description
  "Package pgzip implements reading and writing of gzip format compressed 
files, as
specified in @url{https://rfc-editor.org/rfc/rfc1952.html,RFC 1952}.")
(license license:expat)))

i have attached the build log, but the essence is this:

guile: warning: failed to install locale

and i can't get rid of this^ warning. i installed glibc-locales to root and my 
user, reconfigured, restarted the guix-daemon.

which is probably the cause of the ultimate error:

warning: failed to delete .git/refs/tags/v??.2.0: No such file or directory
r:sha256 hash mismatch for...

the daemon starts from an empty env:

https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/build.cc#n1590

and then copies the env from the derivation, but it doesn't seem to contain any 
LANG value. i assume guile is also launched then without a LANG env. BTW, guile 
could be more informative in its warning, too.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“The unexamined life is not worth living for a human being.”
— Socrates (c. 470–399 BC, tried and executed), 'Apology' (399 BC)


build-log
Description: Binary data

bug#54545: [Guix Home] ‘shepherd’ started twice?

[Ludovic Courtès]

Hi,

Andrew Tropin  skribis:

> Prepared a patch series, which fixes the issues and sligthly adjusts the
> way home shepherd reload configuration logic works, now it happens only
> if configuration is changed and also it doesn't try to be smart and
> start a shepherd if it's not started yet.
>
> From d2578f8924217451ca20f0b61fd6f9b9d31c930d Mon Sep 17 00:00:00 2001
> From: Andrew Tropin 
> Date: Tue, 12 Apr 2022 11:30:58 +0300
> Subject: [PATCH 1/3] home: shepherd: Prevent launching the second instance.
>
> * gnu/home/services/shepherd.scm: Prevent launching the second instance.

I applied this one with a convention commit log, including a “Fixes”
line, which is important for traceability.  (Please check the ChangeLog
convention for future patches.)

> From 56d16b4cd511f6837329b888dade0c6d6da4d89d Mon Sep 17 00:00:00 2001
> From: Andrew Tropin 
> Date: Tue, 12 Apr 2022 12:19:50 +0300
> Subject: [PATCH 2/3] home: shepherd: Use run-on-change to reload shepherd
>  config.
>
> * gnu/home/services/shepherd.scm: Add shepherd configuration to
> XDG_CONFIG_HOME and use it instead of full path to the store. It's necessary
> to use run-on-change service.

[...]

> +++ b/gnu/home/services/shepherd.scm
> @@ -105,27 +105,30 @@ (define (launch-shepherd-gexp config)
>  (system*
>   #$(file-append shepherd "/bin/shepherd")
>   "--logfile"
> - (string-append log-dir "/shepherd.log")
> - "--config"
> - #$(home-shepherd-configuration-file services shepherd)
> + (string-append log-dir "/shepherd.log")
>  #~"")))
>  
>  (define (reload-configuration-gexp config)
>(let* ((shepherd (home-shepherd-configuration-shepherd config))
>   (services (home-shepherd-configuration-services config)))
> -#~(system*
> -   #$(file-append shepherd "/bin/herd")
> -   "load" "root"
> -   #$(home-shepherd-configuration-file services shepherd
> +#~(when (file-exists?
> + (string-append
> +  (or (getenv "XDG_RUNTIME_DIR")
> +  (format #f "/run/user/~a" (getuid)))
> +  "/shepherd/socket"))
> +(system*
> + #$(file-append shepherd "/bin/herd")
> + "load" "root"
> + #$(home-shepherd-configuration-file services shepherd)
>  
> -(define (ensure-shepherd-gexp config)
> -  #~(if (file-exists?
> - (string-append
> -  (or (getenv "XDG_RUNTIME_DIR")
> -  (format #f "/run/user/~a" (getuid)))
> -  "/shepherd/socket"))
> -#$(reload-configuration-gexp config)
> -#$(launch-shepherd-gexp config)))
> +(define (add-shepherd-configuration config)
> +  (let* ((shepherd (home-shepherd-configuration-shepherd config))
> + (services (home-shepherd-configuration-services config)))
> +`(("shepherd/init.scm"
> +   ,(home-shepherd-configuration-file services shepherd)
> +
> +(define (home-shepherd-run-on-change config)
> +  `(("files/.config/shepherd/init.scm" ,(reload-configuration-gexp config

How does this relate to the bug at hand?

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

As discussed elsewhere, I find it less ambiguous to pass store file
names for configuration files.

That can be a drawback in some cases, for daemons that won’t be able to
load a new config from a different location, but shepherd is not in that
category: it can load a config file via ‘herd load root’ from any place.

Last, it would be nice if we could use the (guix scripts system
reconfigure) machinery like ‘guix system reconfigure’ and ‘guix deploy’
to upgrade services.  An idea for future work.  :-)

> From e80e9fae6f6bcd478fa904aad8eb426da3f42f10 Mon Sep 17 00:00:00 2001
> From: Andrew Tropin 
> Date: Tue, 12 Apr 2022 12:23:26 +0300
> Subject: [PATCH 3/3] home: run-on-first-login: Add a startup message to the
>  script.
>
> gnu/home/services.scm: Add a startup message to the script to make it clear
> when it begins.
> ---
>  gnu/home/services.scm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gnu/home/services.scm b/gnu/home/services.scm
> index 49bd6e3555..e2c51910a8 100644
> --- a/gnu/home/services.scm
> +++ b/gnu/home/services.scm
> @@ -344,6 +344,7 @@ (define (compute-on-first-login-script _ gexps)
>   #~(begin
> (use-modules (guix i18n))
> #$%initialize-gettext
> +   (display (G_ "Starting run-on-first-login script.\n\n"))

I’m not fond of unconditional low-level logging.  In Guix there’s
relatively little logging and whatever logging there is is controlled by
‘-v’; I think we should follow that approach as much as possible.

Thank you!

Ludo’.

bug#54770: Non-root LUKS devices unusable after Shepherd upgrade

[Christoph Weiss]

Hi Ludo,

Oh, I had no idea that's how it worked... sorry about that.  Indeed this 
has fixed the issue.  Thank you for your time!


Christoph

bug#54787: importer Bioconductor: no tarball, only Git

[zimoun]

Hi Ricardo,

On lun., 11 avril 2022 at 18:15, Ricardo Wurmus  wrote:
> zimoun  writes:
>
>> $ guix import cran -a bioconductor CHETAH
>> guix import: warning: failed to retrieve package information from
>> https://cran.r-project.org/web/packages/CHETAH/DESCRIPTION: 404 (Not Found)
>> guix import: error: failed to download description for package 'CHETAH'
>>
>> The reason is because there is no source package.  Only the Git source
>> repo.
>
> We should finally switch to fetching the sources from Git.  I wonder why
> we haven’t done this earlier.

Because, maybe, we have just finished the janitor work cleaning the
files cran.scm, bioconductor.scm and bioinformatics.scm. :-)

> I guess we should do this gradually to avoid mass updates, so perhaps we
> should introduce bioconductor-git-reference and switch over packages one
> by one.

First, note that annotations do not have Git repo; at least not always,
e.g.,



Second, if we go for something like:

--8<---cut here---start->8---
(define* (bioconductor-git-reference name #:optional
 (release %bioconductor-version))
  "Return a  for the R package archive on Bioconductor for the
RELEASE corresponding to NAME."
  (git-reference
   (url (string-append %bioconductor-git-url name))
   (commit (string-append "RELEASE_" (string-replace-substring
  %bioconductor-version "." "_")
--8<---cut here---end--->8---

then, it raises the question: import/cran.scm or build-system/r.scm ?
i.e., do we put a module dependency against (guix git-download) for the
r-build-system or not?

TeXLive already has a dependency to svn-download, so why not.

Well, I am also in favor to break the API and move %bioconductor-version
and %bioconductor-url to (guix build-system r).  WDYT?  It would
simplify some things (#36805 and #39885), I guess.


Third, the adjustments of the importer require a large cup of coffee.


Back to CHETAH, note that

   guix import cran -a git htpps://git.bioconductor.org/CHETAH

works but it points to master instead of RELEASE_3_14.  Well, I am not
very familiar with the Bioconductor workflow for their release.


Last, using this in gnu/packages/bioconductor.scm,

--8<---cut here---start->8---
(define-public r-chetah
  (package
(name "r-chetah")
(version "1.11.2")
(source
 (origin
   (method git-fetch)
   (uri (bioconductor-git-reference "CHETAH"))
   (file-name (git-file-name name version))
   (sha256
(base32 "021v5831zqdy4pirfsb35kbnz8kmz4lxqc4cwi55qgd6r081xlgh"
(properties `((upstream-name . "CHETAH")))
(build-system r-build-system)
(propagated-inputs
 (list r-biodist
   r-corrplot
   r-cowplot
   r-dendextend
   r-ggplot2
   r-gplots
   r-pheatmap
   r-plotly
   r-reshape2
   r-s4vectors
   r-shiny
   r-singlecellexperiment
   r-summarizedexperiment))
(native-inputs (list r-knitr))
(home-page "https://git.bioconductor.org/packages/CHETAH;)
(synopsis "Fast and accurate scRNA-seq cell type identification")
(description
 "CHETAH (CHaracterization of cEll Types Aided by Hierarchical 
classification) is
an accurate, selective and fast scRNA-seq classifier.  Classification is guided
by a reference dataset, preferentially also a scRNA-seq dataset.  By
hierarchical clustering of the reference data, CHETAH creates a classification
tree that enables a step-wise, top-to-bottom classification.  Using a novel
stopping rule, CHETAH classifies the input cells to the cell types of the
references and to \"intermediate types\": more general classifications that 
ended
in an intermediate node of the tree.")
(license #f)))
--8<---cut here---end--->8---

it just builds with,

./pre-inst-env guix build r-chetah



WDYT?


Cheers,
simon

bug#28084: lilypond, fontforge are not reproducible

[zimoun]

Hi,

Using 3670480, it is still the case, see below.

On mar., 22 déc. 2020 at 16:27, zimoun  wrote:
> The package lilypond is still not reproducible with Guix af34f75.
>
> On Mon, 14 Aug 2017 at 05:24, Danny Milosavljevic  
> wrote:
>> +++ 
>> /gnu/store/5isa0knfahy345j3zw7yg9vzc073rfg4-lilypond-2.19.63-check/share/lilypond/2.19.63/fonts/svg/emmentaler-11.svg
>>1970-01-01 01:00:01.0 +0100
>> @@ -5,7 +5,7 @@
>>  -->
>>  http://www.w3.org/2000/svg; 
>> xmlns:xlink="http://www.w3.org/1999/xlink; version="1.1">
>>  
>> -Created by FontForge 20160404 at Sun Aug 13 21:37:49 2017
>> +Created by FontForge 20160404 at Sun Aug 13 21:01:36 2017
>>   By Nix build user
>>
>> And some actual strokes are different in the svg (for example the ones for 
>> glyph custodes.hufnagel.u0).
>>
>> Binary files *.otf are different.
>> Binary files *.woff are different.

How do we tackle this old bug?


Cheers,
simon



--8<---cut here---start->8---
simon@pfiuh07$ diff -r --no-dereference 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0{,-check}
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/info/lilypond/09/lily-2be182be.png
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/info/lilypond/09/lily-2be182be.png
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/info/lilypond/0b/lily-1c5fca01.png
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/info/lilypond/0b/lily-1c5fca01.png
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/info/lilypond/41/lily-2c8b3dd2.png
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/info/lilypond/41/lily-2c8b3dd2.png
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/info/lilypond/50/lily-6fe36958.png
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/info/lilypond/50/lily-6fe36958.png
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/info/lilypond/56/lily-f9c182c3.png
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/info/lilypond/56/lily-f9c182c3.png
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/info/lilypond/70/lily-6b0704f6.png
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/info/lilypond/70/lily-6b0704f6.png
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/info/lilypond/d6/lily-1eaf4a7b.png
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/info/lilypond/d6/lily-1eaf4a7b.png
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/info/lilypond/fd/lily-1981c3c7.png
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/info/lilypond/fd/lily-1981c3c7.png
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/lilypond/2.20.0/fonts/otf/emmentaler-11.otf
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/lilypond/2.20.0/fonts/otf/emmentaler-11.otf
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/lilypond/2.20.0/fonts/otf/emmentaler-14.otf
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/lilypond/2.20.0/fonts/otf/emmentaler-14.otf
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/lilypond/2.20.0/fonts/otf/emmentaler-16.otf
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/lilypond/2.20.0/fonts/otf/emmentaler-16.otf
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/lilypond/2.20.0/fonts/otf/emmentaler-18.otf
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/lilypond/2.20.0/fonts/otf/emmentaler-18.otf
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/lilypond/2.20.0/fonts/otf/emmentaler-20.otf
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/lilypond/2.20.0/fonts/otf/emmentaler-20.otf
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/lilypond/2.20.0/fonts/otf/emmentaler-23.otf
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/lilypond/2.20.0/fonts/otf/emmentaler-23.otf
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/lilypond/2.20.0/fonts/otf/emmentaler-26.otf
 and 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0-check/share/lilypond/2.20.0/fonts/otf/emmentaler-26.otf
 differ
Binary files 
/gnu/store/fi4v4dsksfaqrvg61chnfzyis3rzx59q-lilypond-2.20.0/share/lilypond/2.20.0/fonts/otf/emmentaler-brace.otf
 and 

bug#34427: guile-bootstrap@2.2 segfault?

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> On Tue, Feb 12, 2019 at 03:27:37PM +0100, Ludovic Courtès wrote:
>> Hello Efraim,
>> 
>> Efraim Flashner  skribis:
>> 
>> > I'm testing %bootstrap-guile from bootstrap.scm and I'm getting a
>> > segfault when runing guile --version. I've attached an strace of the
>> > process.
>> 
>> To be clear, I believe this is for a *cross-compiled* Guile, right?
>
> That's right, %bootstrap-guile is extracted from $(guix build
> --target=powerpc-linux-gnu bootstrap-tarballs)

Cross-compilation to aarch64-linux-gnu works fine:

--8<---cut here---start->8---
$ unshare -mrf chroot $(guix build guile-static-stripped 
--target=aarch64-linux-gnu) /bin/guile
guile: warning: failed to install locale
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
warning: failed to install locale: Invalid argument
GNU Guile 3.0.7
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> %host-type
$1 = "aarch64-unknown-linux-gnu"
scheme@(guile-user)> ,q
$ guix describe
Generation 210  Apr 11 2022 09:34:10(current)
  guix 7da907f
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 7da907f90e74a4edf96d76ee457ff958265ef8d4
--8<---cut here---end--->8---

The problem has to do specifically with powerpc-linux-gnu (this is with
transparent emulation via QEMU+binfmt_misc):

--8<---cut here---start->8---
$ unshare -mrf chroot $(guix build guile-static-stripped 
--target=powerpc-linux-gnu) /bin/guile
guile: warning: failed to install locale
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Pre-boot error; key: wrong-type-arg, args: (#f "Wrong type to apply: ~S" (#f) 
(#f))qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
--8<---cut here---end--->8---

Unfortunately I fail to get a backtrace from that core dump.

Efraim, could you get a backtrace on the bare metal?

Besides, if PPC32 is the only platform that has a problem, I think this
bug should not be a blocker.

WDYT?

Ludo’.

bug#54864: Also, [BUG]

[Christopher Rodriguez]

I also wanted to report a [BUG]: the UI for Gnu Cuirass lists
specifications defined as targetting either `armhf-linux` and
`arm64-linux` as `armhf-linux` on the Web UI, which should be changed to
report the accurate build target (if both `armhf-linux` and
`arm64-linux` are indeed still valid targets for builds).

--

Christopher Rodriguez


signature.asc
Description: PGP signature

bug#34427: guile-bootstrap@2.2 segfault?

[zimoun]

Hi,

This bug #34427 is marked as important 3 years, 5 weeks, 1 day ago.  Is
it important? ;-)

http://issues.guix.gnu.org/issue/34427

On Tue, 12 Feb 2019 at 17:44, Efraim Flashner  wrote:
> On Tue, Feb 12, 2019 at 03:27:37PM +0100, Ludovic Courtès wrote:

>> Since I saw a build failure similar to the one you mention when
>> cross-building for GNU/Hurd, I’m tempted to think this has to do with
>> cross-compilation.

What is the status of this bug?


Cheers,
simon

bug#34427: bug#34453: [PATCH] build guile-static with guile-2.0

[zimoun]

Hi,

What is the status of this old patch #34453?

http://issues.guix.gnu.org/issue/34453


On Sat, 16 Feb 2019 at 17:06, Ludovic Courtès  wrote:
> Efraim Flashner  skribis:
>
>> When experimenting I found that using guile@2.0 as a base for
>> guile-static, the resulting guile-static didn't segfault on the target
>> architecture.
>
> As discussed in , I would rather
> fix the segfault in 2.2 than move back to 2.0 and effectively delay the
> problem.

Note that #34427 is still open.


Cheers,
simon

bug#54545: [Guix Home] ‘shepherd’ started twice?

[Andrew Tropin]

On 2022-04-04 22:16, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> Activation script tries to load latest shepherd configuration with `herd
>> load root ./path/to/config.scm` and it starts a shepherd process.  Login
>> shell starts the shepherd process as well.  Probably we need to do
>> config reload using on-change service and also not trigger on-change
>> stuff if user isn't logged in.
>
> Makes sense.
>
>> I can think on the proper solution and make a patch with a fix later
>> this week or beginning of the next week.
>
> Awesome, thanks for taking a look!
>
> Ludo’.

Prepared a patch series, which fixes the issues and sligthly adjusts the
way home shepherd reload configuration logic works, now it happens only
if configuration is changed and also it doesn't try to be smart and
start a shepherd if it's not started yet.

From d2578f8924217451ca20f0b61fd6f9b9d31c930d Mon Sep 17 00:00:00 2001
From: Andrew Tropin 
Date: Tue, 12 Apr 2022 11:30:58 +0300
Subject: [PATCH 1/3] home: shepherd: Prevent launching the second instance.

* gnu/home/services/shepherd.scm: Prevent launching the second instance.
---
 gnu/home/services/shepherd.scm | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/gnu/home/services/shepherd.scm b/gnu/home/services/shepherd.scm
index 012585fea4..df6bbb30e6 100644
--- a/gnu/home/services/shepherd.scm
+++ b/gnu/home/services/shepherd.scm
@@ -93,17 +93,21 @@ (define (launch-shepherd-gexp config)
  (services (home-shepherd-configuration-services config)))
 (if (home-shepherd-configuration-auto-start? config)
 (with-imported-modules '((guix build utils))
-  #~(let ((log-dir (or (getenv "XDG_LOG_HOME")
-   (format #f "~a/.local/var/log" (getenv "HOME")
-  ((@ (guix build utils) mkdir-p) log-dir)
-  (system*
-   #$(file-append shepherd "/bin/shepherd")
-   "--logfile"
-   (string-append
-log-dir
-"/shepherd.log")
-   "--config"
-   #$(home-shepherd-configuration-file services shepherd
+  #~(unless (file-exists?
+ (string-append
+  (or (getenv "XDG_RUNTIME_DIR")
+  (format #f "/run/user/~a" (getuid)))
+  "/shepherd/socket"))
+  (let ((log-dir (or (getenv "XDG_LOG_HOME")
+ (format #f "~a/.local/var/log"
+ (getenv "HOME")
+((@ (guix build utils) mkdir-p) log-dir)
+(system*
+ #$(file-append shepherd "/bin/shepherd")
+ "--logfile"
+ (string-append log-dir "/shepherd.log")
+ "--config"
+ #$(home-shepherd-configuration-file services shepherd)
 #~"")))
 
 (define (reload-configuration-gexp config)
-- 
2.35.1

From 56d16b4cd511f6837329b888dade0c6d6da4d89d Mon Sep 17 00:00:00 2001
From: Andrew Tropin 
Date: Tue, 12 Apr 2022 12:19:50 +0300
Subject: [PATCH 2/3] home: shepherd: Use run-on-change to reload shepherd
 config.

* gnu/home/services/shepherd.scm: Add shepherd configuration to
XDG_CONFIG_HOME and use it instead of full path to the store. It's necessary
to use run-on-change service.
---
 gnu/home/services/shepherd.scm | 40 +++---
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/gnu/home/services/shepherd.scm b/gnu/home/services/shepherd.scm
index df6bbb30e6..9a99fed2b5 100644
--- a/gnu/home/services/shepherd.scm
+++ b/gnu/home/services/shepherd.scm
@@ -105,27 +105,30 @@ (define (launch-shepherd-gexp config)
 (system*
  #$(file-append shepherd "/bin/shepherd")
  "--logfile"
- (string-append log-dir "/shepherd.log")
- "--config"
- #$(home-shepherd-configuration-file services shepherd)
+ (string-append log-dir "/shepherd.log")
 #~"")))
 
 (define (reload-configuration-gexp config)
   (let* ((shepherd (home-shepherd-configuration-shepherd config))
  (services (home-shepherd-configuration-services config)))
-#~(system*
-   #$(file-append shepherd "/bin/herd")
-   "load" "root"
-   #$(home-shepherd-configuration-file services shepherd
+#~(when (file-exists?
+ (string-append
+  (or (getenv "XDG_RUNTIME_DIR")
+  (format #f "/run/user/~a" (getuid)))
+  "/shepherd/socket"))
+(system*
+ #$(file-append shepherd "/bin/herd")
+ "load" "root"
+ #$(home-shepherd-configuration-file services shepherd)
 
-(define (ensure-shepherd-gexp config)
-  #~(if (file-exists?
- (string-append
-  (or (getenv "XDG_RUNTIME_DIR")
-  (format #f "/run/user/~a" (getuid)))
-  

bug#54770: Non-root LUKS devices unusable after Shepherd upgrade

[Ludovic Courtès]

Hi,

Christoph Weiss  skribis:

> Thanks for your reply.  Just to double check, I ran another `sudo guix
> pull` and `sudo guix system reconfigure /etc/config.scm`.  I still 
> cannot boot that installation.
>
> This is `guix system describe`'s output for my working revision:
>
> Generation 40   Apr 08 2022 19:52:13
>   file name: /var/guix/profiles/system-40-link
>   canonical file name: /gnu/store/sp41bjidi9qrl0k1gqpxivrdign7f7d6-system
>   label: GNU with Linux-Libre 5.16.14
>   bootloader: grub
>   root device: UUID: b63f8b65-48f2-41a7-9652-9a0cb1759048
>   kernel:
>   /gnu/store/1shy73077i3im91i4lv9bamifm4w29q1-linux-libre-5.16.14/bzImage
>   channels:
> guix:
>   repository URL: https://git.savannah.gnu.org/git/guix.git
>   commit: f077fa0fd0519f0e04f458192a87854094aa36eb
>   configuration file:
>   /gnu/store/18hd645wcz8l5bvhp4lsy49cadq0d655-configuration.scm

This commit is older than the fix:

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

Probably this comes from a confusion: ‘sudo guix pull’ updates
~root/.config/guix/bin, but ‘sudo guix system reconfigure’ runs your
user’s ~/.config/guix/bin.

If you use sudo, what you need to do is:

  guix pull  # without sudo!
  sudo guix system reconfigure …

Let me know if that helps!

Ludo’.

bug#44948: glade does not respond

[Michael Rohleder]

Hey Jesse!

Is this still reproduceable?  It seems to work for me.

-- 
These download files are in Microsoft Word 6.0 format.  After unzipping, 
these files can be viewed in any text editor, including all versions of 
Microsoft Word, WordPad, and Microsoft Word Viewer.  [Microsoft website]


signature.asc
Description: PGP signature