bug#48796: closed (Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix)

[bo0od via Bug reports for GNU Guix]

Everything is explained well in the past posts but no fixation proposed.

Saying need info while all the info there is just ridiculous, closing 
the bug is just a bug skip not fix which lead to either more comments 
here or duplicates tickets else where.


Unless there is a policy saying guix for guix OS only not for any other 
OS then this ticket is still valid.


GNU bug Tracking System:

Your bug report

#48796: Guix on Debian 11 - Cant run or find applications from Guix

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 48...@debbugs.gnu.org.



OpenPGP_0xED4E3C19ACA54DD4.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#25018: GC incorrectly removes the temporary root file of the calling process

[Ludovic Courtès]

Hi Maxim,

(Stripping Cc:.)

Ludovic Courtès  skribis:

> Thank you!  (Your bug triage work is much appreciated!)  We could turn
> the example here in a unit test; the only downside is that running the
> GC in a test is expensive.

Actually, there are tests that most likely relied on the previous
behavior and are now failing in
tests/{derivations,nar,publish,pypi,store}.scm.  We’ll have to look at
each one to make sure they are indeed making the wrong assumption and to
fix them.

What about reverting the change first so we can do that without
pressure and come up with a self-contained patch?

Ludo’.

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[Maxime Devos]

On 14-10-2022 20:08, Timothée Flutre wrote:

Hello,

I have a computer with Ubuntu 22.04.1 LTS". Some time ago, I installed 
Guix to try it out, which I finally did not for various reasons. But 
hearing the talk of K. Hinsen last month convinced me of giving it 
another try.


I hence started by upgrading Guix, like this:
sudo -i guix pull >& output_guix_pull.txt


You are trying to upgrade the daemon (and have some setup where root's 
Guix is used), I assume?  If you meant to update the set of available 
packages of your regular user, you shouldn't do sudo (because sudo if 
for switching to root instead).



But I got the following message (last line of the output):
Please report the COMPLETE output above by email to >.


The whole report is attached in the file "output_guix_pull.txt".


The attachment seems to be missing.

Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

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

[jbranso--- via Bug reports for GNU Guix]

October 14, 2022 7:48 AM, "Maze"  wrote:

> jbra...@dismail.de writes:
> 
>> 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. :)
> 
> I'd rather have a bootable and rw system on a thumbdrive than an ISO
> image which is a ro system which loads itself in RAM. Changes don't
> survive reboots, that's what I find inconvenient with an ISO image.

That is kind of cool to have a bootable rw iso that you can update!

> 
> But anyway now I think I understand that I don't need to mount the store
> copy-on-write when the installing (and booted) sytem has a rw store. At
> least I think so, I'll try next time. It means what I did last time was
> probably unnecessary to begin with.
> 
>> 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.
> 
> I know it's much better with Guix system. But I'll need some time.
> Because I live in a country where VPNs are a necessity but are supposed
> to be licensed, I have my own homebrew VPN on Debian using ssh, sysvinit
> and a bunch of horribly dirty shell scripts and cron tasks. It is
> probably possible to achieve a much better VPN system with shepherd, but
> it's a programming task, I'm trying to do it. It's actually both
> a motivation to migrate my main computer to Guix... and the reason why I
> can't do it right now.

I personally use sway.  Everytime that I install guix system now,
I install bare-bones.scm first.  Then after it is installed, I set up
sway.  I have tried to install gnome.scm before, and network issues 
caused it to fail half way through like 3+ times.

> 
>> Thanks,
>> 
>> Joshua

bug#57878: Minimal reproducible setup

[Liliana Marie Prikler]

Am Freitag, dem 14.10.2022 um 18:07 +0200 schrieb zimoun:
> Hi Liliana,
> 
> Maybe it could be worth to have that in the manual too, no?  For
> example, under ’Application setup, Emacs packages’ [1].
Would you prefer a paragraph, a note, or a footnote?

bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

[Timothée Flutre]

Hello,

I have a computer with Ubuntu 22.04.1 LTS". Some time ago, I installed Guix
to try it out, which I finally did not for various reasons. But hearing the
talk of K. Hinsen last month convinced me of giving it another try.

I hence started by upgrading Guix, like this:
sudo -i guix pull >& output_guix_pull.txt

But I got the following message (last line of the output):
Please report the COMPLETE output above by email to .

The whole report is attached in the file "output_guix_pull.txt".

Thank you in advance for your help!
Timothée Flutre

bug#57878: Minimal reproducible setup

[zimoun]

Hi Liliana,

On mer., 12 oct. 2022 at 21:42, Liliana Marie Prikler 
 wrote:

> 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 ;)

Indeed, the news entry reads,

--8<---cut here---start->8---
 (entry (commit "11a06d1e49f4d50d6789e05bbf35e2e145ff7838")
(title
 (en "Emacs now supports native compilation")
 (de "Emacs kann Pakete nun nativ kompilieren")
 (pt "O Emacs agora suporta compilação nativa"))
(body
 (en "Emacs can now compile packages natively.  Under the default
configuration, this means that Emacs packages will now be just-in-time (JIT)
compiled as you use them, and the results stored in a subdirectory of your
@code{user-emacs-directory}.

Furthermore, the build system for Emacs packages transparently supports native
compilation, but note, that @code{emacs-minimal}---the default Emacs for
building packages---has been configured without native compilation.
To natively compile your emacs packages ahead of time, use a transformation
like @option{--with-input=emacs-minimal=emacs}.")
--8<---cut here---end--->8---

Maybe it could be worth to have that in the manual too, no?  For
example, under ’Application setup, Emacs packages’ [1].

Because it appears to me more than just a simple news if it is more or
less an user choice.

1: 


Cheers,
simon

bug#58375: Installer does not show what is being downloaded

[Mathieu Othacehe]

Hey,

> If we really want to capture the output of ‘guix system init’, then we
> need to open a pseudo-terminal with ‘openpty’ & co. instead of ‘pipe’ in
> ‘run-external-command-with-handler’.  That may be relatively easy
> actually.

So I implemented your proposal. It seems to be working quite well. As
discussed on #guix, we could avoid to dump the download bars to the
syslog if the "guix system init" command succeeds. However, it seems
quite tricky in the current implementation where the syslog dumping is
actually a hook (%syslog-line-hook).

Fixing this issue, I also realized that when the "guix system init"
command fails, the user is only offered to resume the installation or
restart it.

In cases where "guix system init" failed because of a network issue, or
because a partition was too small, restarting/resuming seems like the
right thing to do.

However, when the installer failed because "guix system init" crashed or
segfaulted, restarting/resuming won't probably help, and dumping the
crash is probably the best way to get help. That's why I added in a
second patch, a new button "Report the failure" to the
"run-install-failed-page".

Thanks,

Mathieu
>From c6286404e9c4c0dc302c3d398a8f27b050cf4ce0 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Fri, 14 Oct 2022 17:28:27 +0200
Subject: [PATCH 1/2] installer: Run the "guix system init" command in a PTY.

Fixes: 

* gnu/installer/utils.scm (run-external-command-with-handler/tty): New
procedure.
(run-external-command-with-line-hooks, run-command): Add a TTY? argument.
* gnu/installer/final.scm (install-system): Call run-command with TTY?
argument set to #true.
---
 gnu/installer/final.scm |  2 +-
 gnu/installer/utils.scm | 50 +
 2 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm
index 3f6dacc490..044f79372b 100644
--- a/gnu/installer/final.scm
+++ b/gnu/installer/final.scm
@@ -211,7 +211,7 @@ (define (assert-exit x)
 
  (setenv "PATH" "/run/current-system/profile/bin/")
 
- (set! ret (run-command install-command)))
+ (set! ret (run-command install-command #:tty? #t)))
(lambda ()
  ;; Restart guix-daemon so that it does no keep the MNT namespace
  ;; alive.
diff --git a/gnu/installer/utils.scm b/gnu/installer/utils.scm
index 5fd2e2d425..061493e6a7 100644
--- a/gnu/installer/utils.scm
+++ b/gnu/installer/utils.scm
@@ -20,6 +20,7 @@
 (define-module (gnu installer utils)
   #:use-module (gnu services herd)
   #:use-module (guix utils)
+  #:use-module ((guix build syscalls) #:select (openpty login-tty))
   #:use-module (guix build utils)
   #:use-module (guix i18n)
   #:use-module (srfi srfi-1)
@@ -45,6 +46,7 @@ (define-module (gnu installer utils)
 nearest-exact-integer
 read-percentage
 run-external-command-with-handler
+run-external-command-with-handler/tty
 run-external-command-with-line-hooks
 run-command
 run-command-in-installer
@@ -124,10 +126,37 @@ (define dummy-pipe
 (close-port input)
 (close-pipe dummy-pipe)))
 
-(define (run-external-command-with-line-hooks line-hooks command)
+(define (run-external-command-with-handler/tty handler command)
+  "Run command specified by the list COMMAND in a child operating in a
+pseudoterminal with output handler HANDLER.  HANDLER is a procedure taking an
+input port, to which the command will write its standard output and error.
+Returns the integer status value of the child process as returned by waitpid."
+  (define-values (controller inferior)
+(openpty))
+
+  (match (primitive-fork)
+(0
+ (catch #t
+   (lambda ()
+ (close-fdes controller)
+ (login-tty inferior)
+ (apply execlp (car command) command))
+   (lambda _
+ (primitive-exit 127
+(pid
+ (close-fdes inferior)
+ (let* ((port (fdopen controller "r0"))
+(result (false-if-exception
+ (handler port
+   (close-port port)
+   (cdr (waitpid pid))
+
+(define* (run-external-command-with-line-hooks line-hooks command
+   #:key (tty? #false))
   "Run command specified by the list COMMAND in a child, processing each
-output line with the procedures in LINE-HOOKS.  Returns the integer status
-value of the child process as returned by waitpid."
+output line with the procedures in LINE-HOOKS.  If TTY is set to #true, the
+COMMAND will be run in a pseudoterminal.  Returns the integer status value of
+the child process as returned by waitpid."
   (define (handler input)
 (and
  (and=> (get-line input)
@@ -136,14 +165,17 @@ (define (handler input)
   #f
   (begin (for-each (lambda (f) (f line))
(append line-hooks
-  

bug#57878: Minimal reproducible setup

[Max Brieiev]

I am new to Guix.

My issue is related to the native compilation too, however it manifests
itself differently.

The build of emacs-next goes well.

However, when I start Emacs it throws lots of errors, most of which are
like this:

Deleting /tmp/comp-lambda-RCGJQI.eln
comp--native-compile: Native compiler error: (lambda ( arg1) (let ((f 
#'make-process)) (apply f arg1))), "Compiling /tmp/comp-lambda-RCGJQI.eln...
x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: 
execvp: No such file or directory
compilation terminated.

So while it builds successfully I can't really run it.

What confuses me is that everyone else in this thread has a differnt
issue. For some, if I understand it correctly, the problem is that the
compiler runs to aggressively and makes Emacs unusable. Is it right?

But in my case the native compiler just plainly fails to execute,
because assembler program is not found.

Why isn't it deterministic, meaning that going through the same build
process, the resulting build of my Emacs is different from the others,
reporting related, but different issues?

And this is what makes me think that the problem is actually in
packaging.

This sounds like the problem with dependencies, libgccjit in particular,
doesn't it?

bug#57878: Minimal reproducible setup

[Max Brieiev]

Liliana Marie Prikler  writes:
> 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?)

AFAIU, the compiler is invoked any time a function is redefined or
advised, see (info "(elisp) Advising Functions"). In Emacs it is a very
common paractice to put advices around a function to modify its
behaviour. Since this happens during runtime (for example, in response
to a hook, or after you manually run some command), you should accept
the fact that native compiler may be invoked at any time as you use
Emacs.

> 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 ;)

How pressing is this issue? There are literally no reports of packages
breaking due to native compilation. So this is probably the reason why
Eli considers it as a non-issue.

> 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.

If security is a concern, you should not load random Elisp in the first
place. It is much easier to just directly run harmful elisp, then to
exploit native compiler, which stays silent until after you evaluate
some (possibly harmful) elisp.

bug#58419: Grafting order depends on store connection state

[Ludovic Courtès]

Hi,

Josselin Poiret  skribis:

> (let ((right (with-store store (run-with-store store (package->derivation
>   (specification->package
>"password-store")
>   (wrong (with-store store (run-with-store store (mbegin %store-monad
>(package->derivation
> 
> (specification->package
>  "texlive-bin"))
>(package->derivation
> 
> (specification->package
>  
> "password-store")))
>   (pk right)
>   (pk wrong))
>
> Both derivations differ even though they ideally should be identical,
> apparently git doesn't appear in the same place in the grafting
> derivation.

Right:

--- #
+++ #
@@ -19,17 +19,17 @@
   ("x" . "/gnu/store/3bpq5knfvzhxhqfwzqm9br917nz7r0yp-gnupg-2.2.32")
   ("x" . "/gnu/store/31ffp5lszf1g7h1zw750w621cm14hxlr-util-linux-2.37.2")
   ("x" . "/gnu/store/zpw3l0y7sq3ag3fmq001x22bdpalw1fy-xclip-0.13")
-  ("x" . "/gnu/store/f686n3snbkbbf41g7hqyb75dymnckr3z-git-2.37.3")
   ("x" . "/gnu/store/g8qm4vq1f9v81zg8aazkiaf1j3wb8w0s-dmenu-5.1")
   ("x" . "/gnu/store/mk4514a1rjf6mqp0z46kzh80z7j1mhbs-xdotool-3.20211022.1")
   ("x" . "/gnu/store/vmwvxj3ksnmck2cfwsgm9dfi9n41050x-wl-clipboard-2.0.0")
+  ("x" . "/gnu/store/f686n3snbkbbf41g7hqyb75dymnckr3z-git-2.37.3")
   ("x" . "/gnu/store/0jlw8kk0ll25lzbz939jaz4sbfkr8gqj-gnupg-2.2.32")
   ("x" . "/gnu/store/a8k9s0wpf0f3l7nwsscjhnbs5wrn2y1q-util-linux-2.37.2")
   ("x" . "/gnu/store/4vh3qdhsq6misl3vvgm39zdh4sflz4s0-xclip-0.13")
-  ("x" . "/gnu/store/svj9wb4jcb701g3fjf0cmi87rv85sx0x-git-2.37.3")
   ("x" . "/gnu/store/h647qh34g8afyy99gbkngavvlm2p14vn-dmenu-5.1")
   ("x" . "/gnu/store/n6gsqfcc51m4flr21p8szzic5yh1fpfb-xdotool-3.20211022.1")
-  ("x" . "/gnu/store/k28gncxkgxy3hn8qzwylsazc00pwr71s-wl-clipboard-2.0.0"
+  ("x" . "/gnu/store/k28gncxkgxy3hn8qzwylsazc00pwr71s-wl-clipboard-2.0.0")
+  ("x" . "/gnu/store/svj9wb4jcb701g3fjf0cmi87rv85sx0x-git-2.37.3"
   (unsetenv "GUILE_LOAD_COMPILED_PATH")
   (unsetenv "LD_LIBRARY_PATH"))
 (exit
@@ -44,10 +44,10 @@
 	   (("/gnu/store/3bpq5knfvzhxhqfwzqm9br917nz7r0yp-gnupg-2.2.32" . "/gnu/store/0jlw8kk0ll25lzbz939jaz4sbfkr8gqj-gnupg-2.2.32")
 	("/gnu/store/31ffp5lszf1g7h1zw750w621cm14hxlr-util-linux-2.37.2" . "/gnu/store/a8k9s0wpf0f3l7nwsscjhnbs5wrn2y1q-util-linux-2.37.2")
 	("/gnu/store/zpw3l0y7sq3ag3fmq001x22bdpalw1fy-xclip-0.13" . "/gnu/store/4vh3qdhsq6misl3vvgm39zdh4sflz4s0-xclip-0.13")
-	("/gnu/store/f686n3snbkbbf41g7hqyb75dymnckr3z-git-2.37.3" . "/gnu/store/svj9wb4jcb701g3fjf0cmi87rv85sx0x-git-2.37.3")
 	("/gnu/store/g8qm4vq1f9v81zg8aazkiaf1j3wb8w0s-dmenu-5.1" . "/gnu/store/h647qh34g8afyy99gbkngavvlm2p14vn-dmenu-5.1")
 	("/gnu/store/mk4514a1rjf6mqp0z46kzh80z7j1mhbs-xdotool-3.20211022.1" . "/gnu/store/n6gsqfcc51m4flr21p8szzic5yh1fpfb-xdotool-3.20211022.1")
-	("/gnu/store/vmwvxj3ksnmck2cfwsgm9dfi9n41050x-wl-clipboard-2.0.0" . "/gnu/store/k28gncxkgxy3hn8qzwylsazc00pwr71s-wl-clipboard-2.0.0")))
+	("/gnu/store/vmwvxj3ksnmck2cfwsgm9dfi9n41050x-wl-clipboard-2.0.0" . "/gnu/store/k28gncxkgxy3hn8qzwylsazc00pwr71s-wl-clipboard-2.0.0")
+	("/gnu/store/f686n3snbkbbf41g7hqyb75dymnckr3z-git-2.37.3" . "/gnu/store/svj9wb4jcb701g3fjf0cmi87rv85sx0x-git-2.37.3")))
 	  (map
 	   (match-lambda
 	 ((name . file)

If we squint a bit, we realize it’s the same thing but in a different
order, which is good news: it’s functionally equivalent.

The downside is obvious: it’s stupidly non-deterministic, and we can end
up building the same grafts multiple times.

The order differs in two places: in the definition of ‘%build-inputs’,
and in the definition of the ‘mapping’ variable.  This can be solved by
sorting things in the right place, but that needs some thought.

To be continued…

Ludo’.

bug#58149: guix pull error

[zimoun]

Hi Bengt,

On ven., 07 oct. 2022 at 04:40, b...@bokr.com wrote:
> On +2022-10-04 12:11:52 +0200, Ludovic Courtès wrote:
>> Matthieu Haefele  skribis:

>> > Starting download of 
>> > /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz
>> > From 
>> > https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14.67-gnu/linux-libre-4.14.67-gnu.tar.xz...
>> > download failed 
>> > "https://linux-libre.fsfla.org/pub/linux-libre/releases/4.14.67-gnu/linux-libre-4.14.67-gnu.tar.xz;
>> >  404 "Not Found"
>> 
>> [...]
>> 
>> > Starting download of 
>> > /gnu/store/f2j6pi0d18pbz35ypflp61wzhbfcr8dp-linux-libre-4.14.67-gnu.tar.xz
>> > From 
>> > https://mirror.hydra.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg...
>> > In procedure connect: Network is unreachable

>>   wget -O linux-libre-4.14.67-gnu.tar.xz \
>>
>> https://ci.guix.gnu.org/file/linux-libre-4.14.67-gnu.tar.xz/sha256/050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg
>>   guix download file://$PWD/linux-libre-4.14.67-gnu.tar.xz

> --8<---cut here---start->8---
> $ wget -q -O- 
> https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/sha256sums.asc|egrep 
> 4\\.14\\.67
> 93b4ea4816a8a73e4ba2d9c26dc622035b1b504010f1048c0455a190a653166e  
> ChangeLog-4.14.67
> a53d3a3b5877e1847fb34ecb75aabce2a1bf3cc0ee7236cf2aef02f0ecf83433  
> linux-4.14.67.tar.gz
> 3f4b056dc27233a78f7a4a35ed6fdcfd0a9680ec40b611a898bb6c8b905070ba  
> linux-4.14.67.tar.xz
> 42c7ff27d7cefbf0b4e313c757db1f2cfa2d65fa22cbe908c24aafafc995bd5f  
> patch-4.14.67.xz
> --8<---cut here---end--->8---

> --8<---cut here---start->8---
> $ time wget -q 
> https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz
>
> real0m47.015s
> user0m2.381s
> sys 0m3.720s
> $ sha256sum linux-4.14.67.tar.xz 
> 3f4b056dc27233a78f7a4a35ed6fdcfd0a9680ec40b611a898bb6c8b905070ba  
> linux-4.14.67.tar.xz
> --8<---cut here---end--->8---

I miss what you are suggesting.  Back on 2018, Guix relied on the kernel
distributed by linux-libre.fsfla.org.  Then they dropped the revision of
that version.

Note that at this time (2018), using the wayback time-machine [1], many
signatures were provided.  Then, once included in Guix by commit
fabe2c73548e88004b01f5218d1110141a2114d5, it reads,

--8<---cut here---start->8---
-(define %linux-libre-4.14-version "4.14.66")
-(define %linux-libre-4.14-hash 
"1sf18m6xjyg535yviz3yjbislf57s180y67z7mzbcl5pq9352bg9")
+(define %linux-libre-4.14-version "4.14.67")
+(define %linux-libre-4.14-hash 
"050zvdxjy6sc64q75pr1gxsmh49chwav2pwxz8xlif39bvahnrpg")
--8<---cut here---end--->8---

Therefore, you trusted the author of that commit (here Mark H Weaver).


Well, back to today. :-) Thing changed since 2018.  The Linux kernel is
special since it needs some deblob.  Even, a special origin is done for
that purpose named ’computed-origin’.

If you consider the current 4.14 series; revision 295.  For instance,

--8<---cut here---start->8---
$ wget -q 
https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.295.tar.xz
$ wget -q -O- 
https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/sha256sums.asc|egrep 
4\\.14\\.295
eb77cae3fadc31f3b44ce3806c9492be1116e4b76ad82ca574c7da22bd78b50c  
ChangeLog-4.14.295
fc96f9a1a6f8671d034cc8c8e885bb89a52ba38e2ebaba36e9c83e3761ef1f13  
linux-4.14.295.tar.gz
62ccb9ba94a7da5115bc923eebf8dffee9229801da02be87d90ae68ab9a76a6b  
linux-4.14.295.tar.xz
941c34f4a5c438bbb1b0ab5ee84b8075acf9c4d3843697259e980def08c6a839  
patch-4.14.295.xz
$ sha256sum linux-4.14.295.tar.xz
62ccb9ba94a7da5115bc923eebf8dffee9229801da02be87d90ae68ab9a76a6b  
linux-4.14.295.tar.xz
--8<---cut here---end--->8---

--8<---cut here---start->8---
$ guix hash -S none -H sha256 -f hex linux-4.14.295.tar.xz
62ccb9ba94a7da5115bc923eebf8dffee9229801da02be87d90ae68ab9a76a6b

$ guix hash -S none -H sha256 -f nix-base32 linux-4.14.295.tar.xz
0svalywqmrhav63vw0ns06c25sgyvzwfngljpham3nm7jjxbkk32
--8<---cut here---end--->8---

and then you can compare this hash with the one in Guix source [2].

And you can do the same with the deblob scripts.

1: 

2: 



Cheers,
simon

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

[Maze]

jbra...@dismail.de writes:



> 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.  :)
>

I'd rather have a bootable and rw system on a thumbdrive than an ISO
image which is a ro system which loads itself in RAM. Changes don't
survive reboots, that's what I find inconvenient with an ISO image.

But anyway now I think I understand that I don't need to mount the store
copy-on-write when the installing (and booted) sytem has a rw store. At
least I think so, I'll try next time. It means what I did last time was
probably unnecessary to begin with.

> 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.

I know it's much better with Guix system. But I'll need some time.
Because I live in a country where VPNs are a necessity but are supposed
to be licensed, I have my own homebrew VPN on Debian using ssh, sysvinit 
and a bunch of horribly dirty shell scripts and cron tasks. It is
probably possible to achieve a much better VPN system with shepherd, but
it's a programming task, I'm trying to do it. It's actually both
a motivation to migrate my main computer to Guix... and the reason why I
can't do it right now.

> Thanks,
>
> Joshua

bug#58508: gtg package (Getting Things GNOME) doesn't run

[Christopher Baines]

Pkill9  writes:

> This is the error I get when running:
>
> guix environment --ad-hoc gtg -- gtg
>
> ```
> Traceback (most recent call last):
>   File "/gnu/store/0x46vnn6nk10dmkjvg9jmzqx65pmjs4r-gtg-0.6/bin/.gtg-real", 
> line 76, in 
> gi.require_version('GtkSource', '4') 
>   File 
> "/gnu/store/vbms7iz53dpdz5iz8ik2blr77w17imva-python-pygobject-3.40.1/lib/python3.9/site-packages/gi/__init__.py",
>  line 126, in require_version
> raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace GtkSource not available
>
> ```

If you're up for tweaking the package definition, try adding
gtksourceview-4 as an input and see if you get the same error.

Chris


signature.asc
Description: PGP signature

bug#58508: gtg package (Getting Things GNOME) doesn't run

[Pkill9]

This is the error I get when running:

guix environment --ad-hoc gtg -- gtg

```
Traceback (most recent call last):
  File "/gnu/store/0x46vnn6nk10dmkjvg9jmzqx65pmjs4r-gtg-0.6/bin/.gtg-real", 
line 76, in 
gi.require_version('GtkSource', '4') 
  File 
"/gnu/store/vbms7iz53dpdz5iz8ik2blr77w17imva-python-pygobject-3.40.1/lib/python3.9/site-packages/gi/__init__.py",
 line 126, in require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace GtkSource not available

```

bug#58485: [shepherd] Restarting guix-publish fails

[Liliana Marie Prikler]

Am Freitag, dem 14.10.2022 um 08:18 +0200 schrieb Lars-Dominik Braun:
> Hi,
> 
> > Ahh, so the issue is that shepherd waits neither for the process to
> > be
> > actually killed nor for the socket to become available, isn't it?
> I would argue it’s the former, but having either of them would solve
> the problem, I think.
I think you need both: if the process is killed, but the socket
remains, you need to clean it up.  As far as I'm aware, that does not
happen automatically.

Cheers

bug#58290: guile ssh error on guix deploy

[Andrew Tropin]

On 2022-10-08 14:39, Ludovic Courtès wrote:

> Hi!
>
> Andrew Tropin  skribis:
>
>> From time to time I get the following error, the only thing I change is
>> IPv6 config in static-networking service.  Sometimes it fails, but after
>> a few more attempts with the same config it deploys sucessfully.
>>
>> -*- mode: compilation; default-directory: "~/work/abcdw/trop.in/" -*-
>> Compilation started at Tue Oct  4 14:19:46
>>
>> make -k deploy-pinky
>> guix deploy ./guix/pinky.scm
>
> [...]
>
>> In guix/ssh.scm:
>> 376:2  7 (send-files # _ # …)
>> 222:5  6 (remote-run (begin (use-modules (guix) (srfi #) # #) …) #)
>> In ssh/popen.scm:
>>  64:4  5 (open-remote-pipe* _ "r+" _ . _)
>> In unknown file:
>>4 (channel-open-session #)
>> In ice-9/boot-9.scm:
>>   1685:16  3 (raise-exception _ #:continuable? _)
>>   1683:16  2 (raise-exception _ #:continuable? _)
>>   1685:16  1 (raise-exception _ #:continuable? _)
>>   1685:16  0 (raise-exception _ #:continuable? _)
>>
>> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>> Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel 
>> opening failure: channel 67 error (2) open failed" #> (closed) 7f7d1af9e140> #f)'.
>
> Are there any hints from sshd in the /var/log/messages of that machine
> as to why the connection was closed?

--8<---cut here---start->8---
bob@pinky /var/log$ zcat messages.1.gz | grep "Oct  4" | grep ssh
Oct  4 05:57:09 localhost shepherd[1]: Service sshd-380 has been started. 
Oct  4 05:57:11 localhost sshd[15950]: Accepted publickey for bob from 
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 54710 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct  4 06:34:17 localhost shepherd[1]: Service sshd-381 has been started. 
Oct  4 06:34:19 localhost sshd[15958]: Accepted publickey for bob from 
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 57064 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct  4 06:36:55 localhost shepherd[1]: Service sshd-382 has been started. 
Oct  4 06:36:57 localhost sshd[15991]: Accepted publickey for bob from 
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 41088 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct  4 06:37:30 localhost shepherd[1]: Service sshd-383 has been started. 
Oct  4 06:37:33 localhost sshd[16031]: Accepted publickey for bob from 
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 56148 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct  4 06:43:39 localhost shepherd[1]: 3 connections still in use after 
sshd-382 termination. 
Oct  4 06:43:39 localhost shepherd[1]: Service sshd-382 (PID 15991) exited with 
255. 
Oct  4 06:43:39 localhost shepherd[1]: Service sshd-382 has been disabled. 
Oct  4 06:43:39 localhost shepherd[1]: Transient service sshd-382 terminated, 
now unregistered. 
Oct  4 06:43:41 localhost shepherd[1]: Service sshd-384 has been started. 
Oct  4 06:43:42 localhost sshd[16166]: Accepted publickey for bob from 
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 36040 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct  4 06:43:49 localhost shepherd[1]: 3 connections still in use after 
sshd-384 termination. 
Oct  4 06:43:49 localhost shepherd[1]: Service sshd-384 has been disabled. 
Oct  4 06:43:49 localhost shepherd[1]: Transient service sshd-384 terminated, 
now unregistered. 
Oct  4 06:48:58 localhost shepherd[1]: Service sshd-385 has been started. 
Oct  4 06:49:00 localhost sshd[16205]: Accepted publickey for bob from 
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 34134 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct  4 06:52:05 localhost shepherd[1]: Service sshd-386 has been started. 
Oct  4 06:52:06 localhost sshd[16212]: Accepted publickey for bob from 
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 55922 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct  4 06:53:02 localhost shepherd[1]: 4 connections still in use after 
sshd-386 termination. 
Oct  4 06:53:02 localhost shepherd[1]: Service sshd-386 has been disabled. 
Oct  4 06:53:02 localhost shepherd[1]: Transient service sshd-386 terminated, 
now unregistered. 
Oct  4 06:53:03 localhost shepherd[1]: Service sshd-387 has been started. 
Oct  4 06:53:04 localhost sshd[16370]: Accepted publickey for bob from 
201:2a73:cac3:e128:cf3d:8dc:8afa:df66 port 50604 ssh2: RSA 
SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y
Oct  4 06:53:11 localhost shepherd[1]: 4 connections still in use after 
sshd-387 termination. 
Oct  4 06:53:11 localhost shepherd[1]: Service sshd-387 has been disabled. 
Oct  4 06:53:11 localhost shepherd[1]: Transient service sshd-387 terminated, 
now unregistered. 
Oct  4 06:54:25 localhost shepherd[1]: Service ssh-daemon has been stopped. 
Oct  4 06:57:42 localhost shepherd[1]: Service ssh-daemon has been started. 
Oct  4 06:58:20 localhost shepherd[1]: Service sshd-1 has been started. 
Oct  4 06:58:22 localhost sshd[239]: Accepted publickey for bob from 

bug#58485: [shepherd] Restarting guix-publish fails

[Lars-Dominik Braun]

Hi,

> Ahh, so the issue is that shepherd waits neither for the process to be
> actually killed nor for the socket to become available, isn't it?
I would argue it’s the former, but having either of them would solve
the problem, I think.

Lars