GMP GCC C++ Hurd cross-build failure on core-updates

[zamfofex]

Hello, Guix! I have been trying to update the Hurd packages to their latest 
commits in the hopes that I can eventually get networking with netdde 
functioning.

In , I got something that seemed to be 
working at first (at least it progressed farther than the status quo at the 
time), but eventually I got an error that seemed related to Mig, which I had 
not updated in that patch set.

Updating Mig required a more recent glibc than what was available in Guix at 
the time, so I worked on  to update glibc.

Now that the recent glibc is on core-updates, I picked up my work once again. I 
updated the packages to the latest commits, and updated Mig! However, I ran 
into an issue while trying to build a system image. The issue is that GMP fails 
to cross‐compile during the ‘configure’ phase becase the cross‐compiling ‘g++’ 
is not functional.

When checking whether ‘g++’ can compile executables during ‘configure’, ‘g++’ 
is unable to link the executables because some ‘pthread_*’ symbols required by 
libstdc++ are missing from libc. And when checking using ‘readelf’, they are 
indeed missing from the cross‐built libc, which instead contains similar 
‘__pthread_*’ symbols.

I don’t know for sure what the issue is, but I highly suspect libstdc++ is 
being compiled against the native glibc headers, rather than the cross‐built 
glibc headers like it should.

Note: Currently, trying to cross‐build packages from core‐updates for the Hurd 
will fail while compiling glibc, since the Hurd package is too outdated for 
that version of glibc.

I’ll attach a diff (for core-updates) with the updated Hurd packages to this 
email. To verify the behavior I’m describing, try running:

- - - - -
./pre-inst-env guix build --target=i586-pc-gnu gmp
- - - - -

Any kind of assistance would be appreciated! Thanks in advance.

hurd.diff
Description: Binary data

Re: Release progress, week 8

[Maxim Cournoyer]

Hi Simon,

zimoun  writes:

> Hi Ludo,
>
> On Fri, 02 Dec 2022 at 23:45, Ludovic Courtès  wrote:
>
>> I started writing super long release notes (a book!), comments welcome:
>>
>>   
>> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md
>>
>> Comments?  Suggestions?  Happiness?  Excitement?  You tell!

Thank you for writing it!  It looks good, though I think the explanation
of the benefit of GUIX_PYTHONPATH is a bit backward; one of the main
goals was to avoid having foreign distributions break spectacularly
because of Guix exposing their (sometimes incompatible) Python libraries
via the shared PYTHONPATH.  It also fixed a sometimes useful use case of
using Python's virtualenv on top of Guix.

[...]

> About “guix pack -f deb”, I thought it was experimental and it is not
> mentioned.  Maybe,

I don't think there's a need to label it as experimental.  The mechanics
are simple, and already proven to work.  I don't see the user-facing
options changing in backward incompatible ways in the future.

>  —has
> been extended with an experimental format: `guix pack -f deb` creates a
> standalone `.deb` package 
>
> It reminds me that,
>
> https://othacehe.org/wsl-images-for-guix-system.htm
>
> could fit a Guix blog post.  Mathieu, WDYT?

Mathieu wrote one already, it's published on their personal blog.  I've
read it recently, it was interesting [0]

[0]  https://othacehe.org/wsl-images-for-guix-system.html

> About the part « **Python packaging** has seen important changes. » I
> would mention the removal of many Python 2 packages.  Maxim, WDYT?

It's already mentioned in the NEWS which will land in the announcement
emails, at least.  We could mention that despite removing 500+ Python 2
packages, our collection has grown from X to Y ;-).

I'll see if I can squeeze some extra bits in before the release.

-- 
Thanks,
Maxim

Re: branch master updated: doc: Recommend avoiding execl, execle or execlp in mcron job specifications.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hello,
>
> guix-comm...@gnu.org skribis:
>
>> diff --git a/doc/guix.texi b/doc/guix.texi
>> index e547d469f4..caa6976a82 100644
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -18940,9 +18940,8 @@ gexps to introduce job definitions that are passed 
>> to mcron
>>;; job's action as a Scheme procedure.
>>#~(job '(next-hour '(3))
>>   (lambda ()
>> -   (execl (string-append #$findutils "/bin/updatedb")
>> -  "updatedb"
>> -  "--prunepaths=/tmp /var/tmp /gnu/store"))
>> +   (system* (string-append #$findutils "/bin/updatedb")
>> +"--prunepaths=/tmp /var/tmp /gnu/store"))
>>   "updatedb"))
>>  
>>  (define garbage-collector-job
>> @@ -18980,6 +18979,12 @@ the job would appear as ``Lambda function'' in the 
>> output of
>>  @command{herd schedule mcron}, which is not nearly descriptive enough!
>>  @end quotation
>>  
>> +@quotation Tip
>> +Avoid calling the Guile procedures @code{execl}, @code{execle} or
>> +@code{execlp} inside a job specification, else mcron won't be able to
>> +output the completion status of the job.
>> +@end quotation
>
> The problem is that this creates an additional process and the first one
> now just sits there in ‘waitpid’.
>
> Could mcron return the completion status of the process that calls the
> thunk?  It suppose it’s already monitoring it (via SIGCHLD or a direct
> ‘waitpid’ call) so it should have that info available, no?

Yes, that should be possible, and I agree that's desirable.  We'd have
to move the finalization logging from 'run-job' to 'child-cleanup', both
defined in (mcron base), moving or factoring out 'seconds-since' and
also recording the start date of the job in the  record
returned by 'run-job'.

My personal mcron TODO now reads:

--8<---cut here---start->8---
* mcron
** TODO Add a 'test' command to run scheduled action *now*
** TODO Log job completion status upon SIGCHLD
--8<---cut here---end--->8---

But feel free to beat me to it!

-- 
Thanks,
Maxim

Re: Potential minor API change notice

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> Hi,
>>>
>>> Maxim Cournoyer  skribis:
>>>
 This is a heads up to let you know that the
 %BASE-PACKAGES-DISK-UTILITIES public variable exported from (gnu system)
 may be removed in the near future.
>>>
>>> If the patch eventually gets consensus, I would suggest making that
>>> variable an alias using ‘define-deprecated’: that way people will know
>>> about it and code won’t break.
>>
>> An deprecated alias to what?
>
> To ‘%base-packages’ for example?  It doesn’t really matter.

I've found that by setting the replacement to #f, it does what I want:

--8<---cut here---start->8---
1 file changed, 4 insertions(+)
gnu/system.scm | 4 

modified   gnu/system.scm
@@ -38,6 +38,7 @@ (define-module (gnu system)
   #:use-module (guix gexp)
   #:use-module (guix records)
   #:use-module (guix packages)
+  #:use-module (guix deprecation)
   #:use-module (guix derivations)
   #:use-module (guix profiles)
   #:use-module ((guix utils) #:select (substitute-keyword-arguments))
@@ -177,6 +178,7 @@ (define-module (gnu system)
 %base-packages-interactive
 %base-packages-linux
 %base-packages-networking
+%base-packages-disk-utilities
 %base-packages-utils
 %base-firmware
 %default-kernel-arguments))
@@ -894,6 +896,8 @@ (define %base-packages-networking
 ;; many people are familiar with, so keep it around.
 iw wireless-tools))
 
+(define-deprecated %base-packages-disk-utilities #f '())
+
 (define %base-packages
   ;; Default set of packages globally visible.  It should include anything
   ;; required for basic administrator tasks.
--8<---cut here---end--->8---

--8<---cut here---start->8---
$ ./pre-inst-env guix system build ~/stow/guix/hurd.scm
/home/maxim/stow/guix/hurd.scm:410:22: warning: '%base-packages-disk-utilities' 
is deprecated
--8<---cut here---end--->8---

I've sent a v2 to 59661 (you are in cc).

-- 
Thanks,
Maxim

missing sanity check

[Vagrant Cascadian]

On 2022-12-03, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>>   In guix/packages.scm:
>> 1295:37  5 (_)
>> 1555:16  4 (package->bag _ _ _ #:graft? _)
>> 1652:22  3 (thunk)
>>   In guix/gexp.scm:
>>  523:11  2 (lower "python-gwcs-0.18.2" #:source _ #:inputs _ # _ . #)
>>  460:52  1 (%local-file #f # …)
>>   In unknown file:
>>  0 (basename #f #)
>
> D’oh, this was due to a file missing from the tarball, which should be
> fixed with 90612b9f1f5fe2d976356e4fa40293a245ebd6c5.
>
> If you feel like doing it, you can run ‘make dist’ from ‘version-1.4.0’
> and try again.  :-)

I definitely did not feel up for a round of 'make dist' for it; I just
patched it in to the debian package:

  
https://salsa.debian.org/debian/guix/-/commit/6b9d57fec61edad9b9303e8a3fad1feb0ce8a004

And it worked, thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: GNU Guix 1.4.0rc1 available for testing!

[John Kehayias]

On Thu, Dec 01, 2022 at 10:17 AM, Ludovic Courtès wrote:

> Hello Guix!
>
> The first release candidate of the upcoming 1.4.0 release is now
> available for testing:
>

Thanks for all the hard work everyone, and especially to Ludo’ for helping herd 
(no pun intended) the cats to get us to this point!

I think I'll dive into some VM testing for the first time...

John

GDB is Unable to find libthread_db

[Attila Lendvai]

dear Guixers,

i'm trying to debug:


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


which is essentally that gpaste sigsegv's:


$ gpaste-client --version
(/home/alendvai/.guix-home/profile/bin/gpaste-client:6955): GPaste-CRITICAL **: 
21:23:48.100: Error calling StartServiceByName for org.gnome.GPaste: Process 
org.gnome.GPaste received signal 11


but the error happens in a thread, and GDB is unable to find 'libthread_db 
matching inferior's thread library':



$ gdb --args ./src/client/gpaste-client --version
GNU gdb (GDB) 12.1

[...]

Warning: /gnu/store/frcfl9lbc5pijlnfgd8c02ynvlp19qqv-gpaste-3.34.4-checkout: No 
such file or directory.
Reading symbols from ./src/client/gpaste-client...
(gdb) set auto-load safe-path /
(gdb) r
Starting program: 
/home/alendvai/workspace/gpaste/builddir/src/client/gpaste-client --version
warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.
[New LWP 7206]
[New LWP 7207]

(/home/alendvai/workspace/gpaste/builddir/src/client/gpaste-client:7203): 
GPaste-CRITICAL **: 21:25:48.822: Error calling StartServiceByName for 
org.gnome.GPaste: Process org.gnome.GPaste received signal 11

[LWP 7206 exited]
[LWP 7203 exited]
[LWP 7207 exited]
[New process 7203]
[Inferior 1 (process 7203) exited with code 01]
(gdb) 


the same question was asked on guix-help 
(https://lists.gnu.org/archive/html/help-guix/2022-09/msg3.html) but 
without any answers.

any hints on how to proceed?

my primary goal is to fix gpaste, which a tool that i use(d) daily. getting at 
least a backtrace from GDB to see where the error originates from would 
probably give me some hints.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Life is dear, love is dearer. Both can be given up for freedom.”
— Sándor Petőfi (1823–1849), 'Szabadság, szerelem!'

Re: GNU Guix 1.4.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

Hello Svante,

Svante Signell  writes:
> What about hurd?

Hurd can be used with QEMU on Linux-based Guix System; see the
childhurd section in the manual.  However, I tried and somewhat failed
to run on my real hardware (a Beebox mini PC): When booting, the Hurd
runs an rc script which freezes.

I make /dev/sda1 an ext2 filesystem and use a slightly modified
/run/current-system/profile/share/guile/site/3.0/gnu/system/examples/bare-hurd.scm
as the template for a manual installation (with the usual steps from
the Guix manual).  Note: e2fsprogs is needed for manual installation
but is not installed in the rc1 installer image; a bug
.

(Thank you for making me notice the bug!)

After these preparations, I run:

guix system init /mnt/etc/config.scm /mnt --target=i586-pc-gnu --skip-checks

Then a last step: Open `guix repl` and run

,use (gnu build hurd-boot)
(make-hurd-device-nodes "/mnt")

It installs and runs somewhat iff I edit the GRUB boot options (with
the E key in the boot menu) to boot from sd0s1 instead of hd0s1, on
every boot.  If I forget to do this, I need to run `fsck.ext2
/dev/sda1` from the installer image before I can boot the already
installed Hurd again.

Anyway, it starts /gnu/store/38sb8h…-system/rc, which freezes.

Also note that the Hurd release shipped with Guix has known security
issues (see Sergey Bugaev’s writeups; there has not yet been a new mig
release since and Guix would need it for newer Hurd, I think).

Note: These instructions are the result of trial and error.  I am not a
hurd user (yet) and don’t know details.

Regards,
Florian

Re: Guile-Gcrypt 0.4.0 released

[Vagrant Cascadian]

On 2022-12-01, Ludovic Courtès wrote:
> I’m pleased to announce Guile-Gcrypt version 0.4.0:
>
>   git clone https://notabug.org/cwebber/guile-gcrypt.git
>   cd guile-gcrypt
>   git checkout v0.4.0  # or 425554d4327eeeb60c39e3d4a1b7bc5e36b63953
>   git tag -v v0.4.0

FWIW, I updated guile-gcrypt to 0.4.0 in Debian experimental and updated
to guix 1.4.0rc1 in Debian experimental using guile-gcrypt 0.4.0, and it
seemed to go fine so far...

  https://buildd.debian.org/status/package.php?p=guile-gcrypt&suite=experimental
  https://buildd.debian.org/status/package.php?p=guix&suite=experimental

I'm guessing guile-gcrypt 0.4.0 will not land in the soon-to-be-released
guix 1.4.0 once it is released, though?

Looking at the longer term, makes me wonder if I should build guix with
guile-gcrypt 0.3.0 currently in Debian unstable & testing ... or if
0.4.0 is a small enough difference that it will probably be fine to
build guix 1.4.0* against it (and eventually migrate it to debian
unstable and eventually testing)?

I know the guix thing would be to package all the relevent versions, but
that is a bit trickier in Debian! :)

live well,
  vagrant


signature.asc
Description: PGP signature

Re: guix emacs package MELPA/ELPA

[Stefan Kangas]

Akib Azmain Turja  writes:

> GNU ELPA (elpa.gnu.org) is not the correct place for guix.el.  GNU ELPA
> is for the packages that are part of GNU Emacs but not distributed with
> Emacs; therefore FSF holds the copyright of those packages.
>
> NonGNU ELPA is the correct place, it is for all types of free software
> Emacs packages that are not part of GNU Emacs.

Thinking of this in terms of "being part of Emacs" or not doesn't
necessarily help make things clearer, in my opinion.

The main difference between GNU ELPA and NonGNU ELPA is that the former
requires all copyright to be assigned to the Free Software Foundation,
whereas the latter does not.  So if the copyright of guix.el is
assigned, it could be added to GNU ELPA.  Otherwise, it would have to go
to NonGNU ELPA.

There are also ethical requirements for both archives, of course.  These
are mainly that packages must be free software, and not recommend using
non-free software.

Re: File search

[Ludovic Courtès]

Hi Antoine,

"Antoine R. Dumont (@ardumont)" 
skribis:

> After toying a bit with the initial code, I took the liberty to make it
> a guix extension (we discussed it a bit with @zimoun). It was mostly to
> get started with Guile (I know some lisp implems but not this one so i
> had to familiarize myself with tools and whatnot ;). Anyway, that can be
> reverted if you feel like it can be integrated as a Guix cli directly.
>
> Currently, the implementation scans and indexes whatever package is
> present in the local store of the machine's user. From nix/guix's
> design, it makes sense to do it that way as it's likely that even though
> you don't have all the tools locally, it may be already present as a
> dependency of some high level tools you already use (it's just not
> exposed because not declared in config.scm or home-configuration.scm).
>
> You will find inlines (at the bottom) some cli usage calls [1] and the
> current implementation [2].

Yay, nice work!

I toyed a bit with your code and that gave me an idea: instead of the
costly ‘fold-packages’ + ‘package-derivation’, we can iterate over all
the manifests on the system and index packages they refer to.  That way,
no need to talk to the daemon, computer derivations, etc.  Should be
faster, though of course it still needs to traverse those directories.

Please find attached a modified version that illustrates that.  (We’ll
need version control at some point.  :-))

Thanks,
Ludo’.

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2022 Ludovic Courtès 
;;;
;;; 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 .

(define-module (guix extensions index)
  #:use-module (guix config)  ;; %guix-package-name, ...
  #:use-module (guix ui)  ;; display G_
  #:use-module (guix scripts)
  #:use-module (sqlite3)
  #:use-module (ice-9 match)
  #:use-module (guix describe)
  #:use-module (guix store)
  #:use-module (guix monads)
  #:autoload   (guix combinators) (fold2)
  #:autoload   (guix grafts) (%graft?)
  #:autoload   (guix store roots) (gc-roots)
  #:use-module (guix derivations)
  #:use-module (guix packages)
  #:use-module (guix profiles)
  #:use-module (guix sets)
  #:use-module ((guix utils) #:select (cache-directory))
  #:autoload   (guix build utils) (find-files)
  #:autoload   (gnu packages) (fold-packages)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-9)
  #:use-module (srfi srfi-71)
  #:export (guix-index))

(define debug #f)

(define schema
  "
create table if not exists Packages (
  idinteger primary key autoincrement not null,
  name  text not null,
  version   text not null,
  unique(name, version) -- add uniqueness constraint
);

create table if not exists Directories (
  idinteger primary key autoincrement not null,
  name  text not null,
  package   integer not null,
  foreign key (package) references Packages(id) on delete cascade,
  unique (name, package) -- add uniqueness constraint
);

create table if not exists Files (
  name  text not null,
  basename  text not null,
  directory integer not null,
  foreign key (directory) references Directories(id) on delete cascade
  unique (name, basename, directory) -- add uniqueness constraint
);

create index if not exists IndexFiles on Files(basename);")

(define (call-with-database file proc)
  (let ((db (sqlite-open file)))
(dynamic-wind
  (lambda () #t)
  (lambda ()
(sqlite-exec db schema)
(proc db))
  (lambda ()
(sqlite-close db)

(define (insert-files db package version directories)
  "Insert files from DIRECTORIES as belonging to PACKAGE at VERSION."
  (define stmt-select-package
(sqlite-prepare db "\
SELECT id FROM Packages WHERE name = :name AND version = :version;"
#:cache? #t))

  (define stmt-insert-package
(sqlite-prepare db "\
INSERT OR IGNORE INTO Packages(name, version) -- to avoid spurious writes
VALUES (:name, :version);"
#:cache? #t))

  (define stmt-select-directory
(sqlite-prepare db "\
SELECT id FROM Directories WHERE name = :name AND package = :package;"
#:cache? #t))

  (define stmt-insert-directory
(sqlite-prepare db "\
INSERT OR IGNORE INTO Directories(name, package) -- to avoid spurious writes
VALUES (:name, :package);"
#:cache? #t))

  (define stmt-i

Re: guix emacs package MELPA/ELPA

[Eli Zaretskii]

> From: Stefan Kangas 
> Date: Sat, 3 Dec 2022 08:57:07 -0800
> Cc: guix-devel@gnu.org, emacs-de...@gnu.org
> 
> The main difference between GNU ELPA and NonGNU ELPA is that the former
> requires all copyright to be assigned to the Free Software Foundation,
> whereas the latter does not.

Not only that: the packages on GNU ELPA are generally expected to conform
more closely to Emacs coding conventions, and are held to higher standards
than those on NonGNU ELPA.

Re: Release progress, week 8

[Julien Lepiller]

Do we string freeze?

Le 2 décembre 2022 23:45:04 GMT+01:00, "Ludovic Courtès"  a écrit 
:
>Hello Guix!
>
>Release progress: week 8.
>
>Apologies for not sending this one on time this Thursday; instead we got
>RC1, which is nice.  :-)
>
>  https://lists.gnu.org/archive/html/guix-devel/2022-12/msg0.html
>
>The RC was made from ‘version-1.4.0’ branch, which only takes important
>fixes now (if in doubt, please ask).
>
>Now we need reports from users to act upon.  I’d say we can decide next
>week whether we need an RC2 or not.  I can handle the next release
>candidate or the release itself, but I’ll be unavailable on Dec. 12–15.
>
>I started writing super long release notes (a book!), comments welcome:
>
>  
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md
>
>Comments?  Suggestions?  Happiness?  Excitement?  You tell!
>
>Ludo’.
>
>Week 7: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00274.html
>Week 6: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00161.html
>Week 5: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
>Week 4: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
>Week 3: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00293.html
>Week 2: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00210.html
>Week 1: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00137.html

Re: Release progress, week 8

[Ludovic Courtès]

Hi!

Vagrant Cascadian  skribis:

>   In guix/packages.scm:
> 1295:37  5 (_)
> 1555:16  4 (package->bag _ _ _ #:graft? _)
> 1652:22  3 (thunk)
>   In guix/gexp.scm:
>  523:11  2 (lower "python-gwcs-0.18.2" #:source _ #:inputs _ # _ . #)
>  460:52  1 (%local-file #f # …)
>   In unknown file:
>  0 (basename #f #)

D’oh, this was due to a file missing from the tarball, which should be
fixed with 90612b9f1f5fe2d976356e4fa40293a245ebd6c5.

If you feel like doing it, you can run ‘make dist’ from ‘version-1.4.0’
and try again.  :-)

Thanks for testing!

Ludo’.

Re: GNU Guix 1.4.0rc1 available for testing!

[Ludovic Courtès]

Hi!

Ahmed Khanzada  skribis:

> Thank you, Paren and Simon. That was easy. :)
>
> I am now on a seemingly stable Guix 1.4 and GNU/Linux kernel 6.

Note that 1.4 is not released yet (it’s a release candidate at this
point), but it’s good to know that it works for you.  Thanks for
testing!

Ludo’.

Re: Help with G-expression

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Fri, 02 Dec 2022 at 22:30, Ludovic Courtès  wrote:
>
>> Oops, that one is a new bug due to
>> 54003af85cc5b689bd328b30617c93ed2f5fd647.  I’ll look into it.
>
> Ah, a good news. :-)

Fixed in 9672db290a35f59113682a7f0c17c050a4ae2578.

[…]

> How can I guess that this
> module (guix profiles) requires (gcrypt hash) as extension?  Just to be
> loaded since it is not used.

You cannot guess it.  Guile-Gcrypt here is an indirect dependency of
(guix profiles).  All you can do is notice that it is needed and add a
‘with-extensions’ form.

It’s annoying, but I don’t see how this could be avoided.

HTH!

Ludo’.

Re: GNU Guix 1.4.0rc1 available for testing!

[Kaelyn]

--- Original Message ---
On Saturday, December 3rd, 2022 at 9:50 AM, zimoun  
wrote:


> 
> 
> Hi,
> 
> On Fri, 02 Dec 2022 at 17:17, Ahmed Khanzada m...@enzu.ru wrote:
> 
> > How can I switch my current GNU Guix installation over to 1.4?
> > Afterwards, how could I switch it back? Is that all safe to do so?
> 
> 
> I guess some usual,
> 
> guix pull --branch=version-1.4.0
> guix system reconfigure
> 
> then
> 
> guix pull --roll-back
> guix system reconfigure

As a side note, if you use GRUB as your bootloader, you can select an alternate 
menu entry to temporarily switch to an older generation. You can also roll back 
to the previous system generations with:

  guix system roll-back

> 
> Well, I think it should be possible using “guix time-machine”, something
> like,
> 
> guix time-machine --branch=version-1.4.0 -- system reconfigure
> 
> but then I do not know how it goes for switching back.

I've not tried guix time-machine to reconfigure a system, but once it is done, 
the same "guix system roll-back" should work for switching back to your 
previous system generation (pre-1.4.0-branch).

HTH!

Cheers,
Kaelyn

> 
> Cheers,
> simon

Re: Licence of the Guix blog posts

[Thiago Jung Bauermann]

Hello Ludo,

Ludovic Courtès  writes:

> You might remember that I started long ago asking people who had
> contributed to the blog whether they would agree to licensing their work
> under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant
> Sections, no Front-Cover Texts, and no Back-Cover Texts¹.

>⋮

> Simon, what do you think about emailing the authors of the “10 years of
> stories” post asking if they agree with the licensing?  :-)  No rush,
> though the sooner the more likely we are to get an answer.

I'm one of the author of that post, and I agree with these licensing
terms.

Thank you for addressing this topic!

-- 
Thanks
Thiago

Re: guix emacs package MELPA/ELPA

[Akib Azmain Turja]

Arvid Krein  writes:

> Hello guix-devel,
>
> this is my first time writing to this list so I hope I am at the right
> place.
> I noticed that the guix package for emacs was moved from being
> developed at Github/Gitlab to Savannah. There is the guix package

Thanks for letting me know, I thought guix.el was just dead.

> 'emacs-guix'. Some people (including me) would rather use the MELPA or
> ELPA package repositories for emacs. I noticed that the guix.el
> package in MELPA is still refering to the old locations on
> github/gitlab which are unmaintained and do not work.
> I will try to get the location fixed in MELPA. But since the package
> has moved closer to the guix project (if I understood it right) would
> it maybe make more sense to host it on ELPA (since it is the GNU
> repository)? I do not really know anything about emacs packaging which
> is why I am asking.
>
> Greetings
>
> Arvid
>

GNU ELPA (elpa.gnu.org) is not the correct place for guix.el.  GNU ELPA
is for the packages that are part of GNU Emacs but not distributed with
Emacs; therefore FSF holds the copyright of those packages.

NonGNU ELPA is the correct place, it is for all types of free software
Emacs packages that are not part of GNU Emacs.

I'm CC'ing emacs-devel list, with hopes that someone will give a better
explanation, or correct me.

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."


signature.asc
Description: PGP signature

Re: GNU Guix 1.4.0rc1 available for testing!

[Ahmed Khanzada]

Thank you, Paren and Simon. That was easy. :)

I am now on a seemingly stable Guix 1.4 and GNU/Linux kernel 6.

I'll look into submitting a pull request to the documentation in the
spot where I had expected to find this information.

Re: Release progress, week 8

[zimoun]

Hi Ludo,

On Fri, 02 Dec 2022 at 23:45, Ludovic Courtès  wrote:

> I started writing super long release notes (a book!), comments welcome:
>
>   
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md
>
> Comments?  Suggestions?  Happiness?  Excitement?  You tell!

I will try to propose a couple of paragraphs for this:

--8<---cut here---start->8---
# Supporting long-term reproducibility

TODO:
  - SWH fallback for channels
  - Disarchive
--8<---cut here---end--->8---

About “guix pack -f deb”, I thought it was experimental and it is not
mentioned.  Maybe,

--8<---cut here---start->8---
 —has
been extended with an experimental format: `guix pack -f deb` creates a
standalone `.deb` package 
--8<---cut here---end--->8---

It reminds me that,

https://othacehe.org/wsl-images-for-guix-system.htm

could fit a Guix blog post.  Mathieu, WDYT?

About the part « **Python packaging** has seen important changes. » I
would mention the removal of many Python 2 packages.  Maxim, WDYT?


Cheers,
simon

Re: GNU Guix 1.4.0rc1 available for testing!

[zimoun]

Hi,

On Fri, 02 Dec 2022 at 17:17, Ahmed Khanzada  wrote:
> How can I switch my current GNU Guix installation over to 1.4?
> Afterwards, how could I switch it back? Is that all safe to do so?

I guess some usual,

guix pull  --branch=version-1.4.0
guix system reconfigure

then

guix pull  --roll-back
guix system reconfigure

Well, I think it should be possible using “guix time-machine”, something
like,

guix time-machine  --branch=version-1.4.0 -- system reconfigure

but then I do not know how it goes for switching back.

Cheers,
simon