bug#45279: [core-updates] copy-recursively does not throw an error on missing directory

[zimoun]

Hi,

On Thu, 17 Dec 2020 at 12:03, Ludovic Courtès  wrote:
> Marius Bakke  skribis:
>
>> On the 'core-updates' branch, using copy-recursively on a nonexistent
>> directory does not cause a build failure.  Instead an error is printed
>> and the script continues:
>>
>>   (copy-recursively "doesnotexist" output)
>>   [...]
>>   starting phase `install'
>>   i/o error: doesnotexist: No such file or directory
>>   phase `install' succeeded after 0.0 seconds
>>
>> This is on cc6cb6e80a42355147809b4830053a34d1563994.
>
> I think it’s always been this way.  Do you think we should change it?

An example from bug#45308 [1] using ’copy-file’, it raises an error and
so a failure.  If ’copy-recursively’ is used instead, it means that the
build would say «success» and print “i/o error:” somewhere in the long
build log, right?  Harder to notice.

As The Zen of Python (python -c 'import this') says: :-)

Errors should never pass silently.
Unless explicitly silenced.


All the best,
simon

1: 

bug#45308: Unexpected fail with build transformation --with-commit

[zimoun]

Dear,

Using Guix f4450e8, the package emacs-next builds:

  $ guix build emacs-next
  /gnu/store/93hb0g731f64avayj8rdz26bz48xg2ri-emacs-next-28.0.50-0.2ea3466

and the recipe reads:

--8<---cut here---start->8---
(define-public emacs-next
  (let ((commit "2ea34662c20f71d35dd52a5ed996542c7386b9cb")
(revision "0"))
(package/inherit emacs
  (name "emacs-next")
  (version (git-version "28.0.50" revision commit))
  (source
   (origin
 (inherit (package-source emacs))
 (method git-fetch)
 (uri (git-reference
   (url "https://git.savannah.gnu.org/git/emacs.git/;)
   (commit commit)))
[...]   
--8<---cut here---end--->8---

However, the equivalent but specifying the exact same commit fails:

--8<---cut here---start->8---
$ guix build emacs-next 
--with-commit=emacs-next=2ea34662c20f71d35dd52a5ed996542c7386b9cb

[...]

In end of data:
site-start.el:3:1: Warning: the function ‘guix-emacs-autoload-packages’ is not
known to be defined.
Done (Total of 2 files compiled)
phase `install-site-start' succeeded after 0.1 seconds
starting phase `glib-or-gtk-wrap'
phase `glib-or-gtk-wrap' succeeded after 0.0 seconds
starting phase `strip-double-wrap'
Backtrace:
   9 (primitive-load "/gnu/store/nqja2pn6mqyqq8gpvsp8jnjaz9c…")
In ice-9/eval.scm:
   191:35  8 (_ _)
In guix/build/gnu-build-system.scm:
838:2  7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1736:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
   857:16  5 (every1 # …)
In guix/build/gnu-build-system.scm:
   847:30  4 (_ _)
In ice-9/boot-9.scm:
142:2  3 (dynamic-wind # …)
In ice-9/eval.scm:
619:8  2 (_ #(#(#)))
In unknown file:
   1 (copy-file "bin/emacs-git.2ea3466" "bin/emacs")
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure copy-file: No such file or directory
builder for 
`/gnu/store/h7s176h5d0fqjzz0ac4pdvzb7rb0dm9i-emacs-next-git.2ea3466.drv' failed 
with exit
code 1
build of /gnu/store/h7s176h5d0fqjzz0ac4pdvzb7rb0dm9i-emacs-next-git.2ea3466.drv 
failed
View build log at
'/var/log/guix/drvs/h7/s176h5d0fqjzz0ac4pdvzb7rb0dm9i-emacs-next-git.2ea3466.drv.bz2'.
guix build: error: build of 
`/gnu/store/h7s176h5d0fqjzz0ac4pdvzb7rb0dm9i-emacs-next-git.2ea3466.drv'
failed
--8<---cut here---end--->8---

Note that the items in the derivation are not ordered the same way
(which should not be, IMHO, i.e., should be sorted):

--8<---cut here---start->8---
Derive
([("out","/gnu/store/93hb0g731f64avayj8rdz26bz48xg2ri-emacs-next-28.0.50-0.2ea3466","","")]
 ,[("/gnu/store/09224jzfa4albcdp321czpjxf6b7s9az-librsvg-2.40.21.drv",["out"])
   ,("/gnu/store/097awwm6ypakc4hgzak3nbhhnax1kb4n-dbus-1.12.16.drv",["out"])
   ,("/gnu/store/0x7akam0zda5cyaarxjxmcrph801ldf5-glib-2.62.6.drv",["out"])

[...]

   
,("/gnu/store/z7hfbdl9xrjjx1nq6v94xwq1ivy82zn3-fontconfig-2.13.1.drv",["out"])]
 
,["/gnu/store/dqbd35sjzmj1hb4s83p6x2k65dyh28xx-emacs-next-28.0.50-0.2ea3466-guile-builder","/gnu/store/jm5y2ys7fwasip9gy6pdv0pn5nf1k49k-module-import"]
 
,"x86_64-linux","/gnu/store/2wrp7x9aclqsapm58dz5i654qds8nbb8-guile-2.0.14/bin/guile",["--no-auto-compile","-L","/gnu/store/jm5y2ys7fwasip9gy6pdv0pn5nf1k49k-module-import","/gnu/store/dqbd35sjzmj1hb4s83p6x2k65dyh28xx-emacs-next-28.0.50-0.2ea3466-guile-builder"]
 
,[("GUILE_LOAD_COMPILED_PATH","/gnu/store/57arpl064shmcfnszyi93cm6xhpkm1sr-module-import-compiled")
   ,("allowSubstitutes","0")
   ,("guix properties","((type . graft) (graft (count . 24)))")
   
,("out","/gnu/store/93hb0g731f64avayj8rdz26bz48xg2ri-emacs-next-28.0.50-0.2ea3466")
   ,("preferLocalBuild","1")])
--8<---cut here---end--->8---

--8<---cut here---start->8---
Derive
([("out","/gnu/store/9a8labbn5r7c6aavazvi9zhy75srxp0a-emacs-next-git.2ea3466","","")]
 ,[("/gnu/store/0914wj4m75qvn2wlxi5gw85dna6n2v7f-mesa-20.1.9.drv",["out"])
   ,("/gnu/store/09224jzfa4albcdp321czpjxf6b7s9az-librsvg-2.40.21.drv",["out"])
   ,("/gnu/store/097awwm6ypakc4hgzak3nbhhnax1kb4n-dbus-1.12.16.drv",["out"])

[...]

   
,("/gnu/store/yshx9iapfwhk90wn3c1nw5jp1hqzx09x-util-linux-2.35.1.drv",["lib"])
   
,("/gnu/store/z7hfbdl9xrjjx1nq6v94xwq1ivy82zn3-fontconfig-2.13.1.drv",["out"])]
 
,["/gnu/store/8qm8aklnh0937bvy9kpy8n7jy8nqwldj-guix-emacs.el","/gnu/store/nqja2pn6mqyqq8gpvsp8jnjaz9cb71js-emacs-next-git.2ea3466-guile-builder","/gnu/store/s48w5zmgchqp8rjl9z2bg8wb0v3j44gj--2ea3466","/gnu/store/ziqkzr6gbllc2rbp0cg18vmr02grf8xi-module-import"]
 

bug#45279: [core-updates] copy-recursively does not throw an error on missing directory

[Mark H Weaver]

Ludovic Courtès  writes:

> Marius Bakke  skribis:
>
>> On the 'core-updates' branch, using copy-recursively on a nonexistent
>> directory does not cause a build failure.  Instead an error is printed
>> and the script continues:
>>
>>   (copy-recursively "doesnotexist" output)
>>   [...]
>>   starting phase `install'
>>   i/o error: doesnotexist: No such file or directory
>>   phase `install' succeeded after 0.0 seconds
>>
>> This is on cc6cb6e80a42355147809b4830053a34d1563994.
>
> I think it’s always been this way.  Do you think we should change it?

In general, I think it's a good idea to raise errors for things like
this.  Warnings that only end up in build logs are likely to go
unnoticed for a long time.

  Mark

bug#45300: [Suggestion] Add option --with-patch

[Philippe SWARTVAGHER]

Hello,

We already have `--with-branch=`, `with-commit=`, ... An additional
option could be `--with-patch=package=add-extra-feature.patch` which
would apply the patch file `add-extra-feature.patch` located in the my
current directory to the sources of `package` before Guix starts
building `package`.

This would bring the possibility to easily share patches (for tests,
reviews, ... for instance) without having to commit the patch in the
source repository of the package, without changing the package
definition, and without applying ourselves the patch to our local source
repository of the package.

Thanks !

-- 
Philippe SWARTVAGHER

PhD Student
TADaaM team, Inria Bordeaux Sud-Ouest

bug#40895: Should be solved by new importer

[Hartmut Goebel]

This issue is solved by the new importer.

--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#45295: “sudo guix system reconfigure” triggers re-clone/update of Git checkout

[Ludovic Courtès]

Hi!

If you do, as a regular user:

  guix pull
  sudo guix system reconfigure …

the ‘guix system reconfigure’, as part of the downgrade-detection
machinery, triggers an update of the channel checkout(s) in
~root/.cache, even though ~USER/.cache is already up-to-date.

One way to avoid it might be to special-case the checkout cache
directory for when ‘SUDO_USER’ is set.

Thoughts?

Ludo’.

bug#45109: GNOME: unable to change alert "beep" sound since staging merge

[Bengt Richter]

Hi Mark, and who may be interested,

On +2020-12-14 19:11:51 -0500, Mark H Weaver wrote:
> reopen 45109
> thanks
> 
> Earlier, I wrote:
> > I initially tried Marius's idea to revert the dconf update, which
> > seemed to work, but now I find that I'm unable to reproduce the
> > problem, even with my original post-staging-merge system where I first
> > encountered it.
> 
> I spoke too soon.  Now the problem is happening again, after another
> system upgrade and reboot.  I don't have time right now to investigate
> further, but I'm reopening the bug.
> 
>  Thanks,
>Mark

The same happened again to me -- i.e., my alert sound preference got reset.
This was after a pureos (debian based) update.
uname -a =-> Linux LionPure 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 
(2020-11-28) x86_64 GNU/Linux

man 7 dconf =-> mentions that gsettings wraps unstable api gconf, so I poked
a little, but no time right now. HTH someone else go further :)

--8<---cut here---start->8---
$ gsettings list-recursively |egrep 'sound|beep'
org.gnome.desktop.sound input-feedback-sounds false
org.gnome.desktop.sound theme-name '__custom'
org.gnome.desktop.sound allow-volume-above-100-percent false
org.gnome.desktop.sound event-sounds true
org.gnome.rhythmbox.plugins seen-plugins ['fmradio', 'mpris', 'daap', 'rb', 
'artsearch', 'replaygain', 'webremote', 'lyrics', 'dbus-media-server', 
'im-status', 'rblirc', 'notification', 'grilo', 'audioscrobbler', 'soundcloud', 
'sendto', 'mtpdevice', 'pythonconsole', 'ipod', 'magnatune']
org.gnome.desktop.a11y.keyboard slowkeys-beep-press false
org.gnome.desktop.a11y.keyboard bouncekeys-beep-reject false
org.gnome.desktop.a11y.keyboard slowkeys-beep-reject false
org.gnome.desktop.a11y.keyboard feature-state-change-beep false
org.gnome.desktop.a11y.keyboard slowkeys-beep-accept false
org.gnome.desktop.a11y.keyboard stickykeys-modifier-beep false
--8<---cut here---end--->8---

As you recall from previously (here I've re-selected sonar.ogg :),
--8<---cut here---start->8---
$ find ~/ -name '*__custom*'
/home/bokr/.local/share/sounds/__custom
$ find ~/ -name '*__custom*'|xargs ls -l
total 4
lrwxrwxrwx 1 bokr bokr 48 Dec 17 08:52 bell-terminal.ogg -> 
/usr/share/sounds/gnome/default/alerts/sonar.ogg
lrwxrwxrwx 1 bokr bokr 48 Dec 17 08:52 bell-window-system.ogg -> 
/usr/share/sounds/gnome/default/alerts/sonar.ogg
-rw-r--r-- 1 bokr bokr 61 Dec 10 12:11 index.theme
--8<---cut here---end--->8---

BTW, do you or anyone know if there is a CRUD[1]-log that can be enabled,
to log *EVERY* CRUD change to any persistent storage during system
(debian in this case) updates? That can't be a new idea ;)
(Maybe it's hard in the context of something signed that runs privileged
to do updates before rebooting to grub? )

Also, is there a standard policy somewhere for preserving/migrating content 
state
when installing a replacement storage box for the content?

If it is too much work to write migration code when storage internals or apis
change, couldn't it just be policy to mark the old box as box.old_NNN instead
of deleting/overwiting it, and emit (and log) a simple hint?

[1] https://en.wikipedia.org/wiki/Create,_read,_update_and_delete

-- 
Regards,
Bengt Richter

bug#44760: Closure copy in ‘guix system init’ is inefficient

[Ludovic Courtès]

Hi,

Jonathan Brielmaier  skribis:

> there seems to be another regression in this series.
>
> Pulling from 6a060ff27ff68384d7c90076baa36c349fff689d gives:
> ```
> [ 1/20] Loading './guix/base32.scm'...

[...]

> [10/20] Loading './guix/store/deduplication.scm'...
>
> ;;; Failed to autoload copy-file/deduplicate in (guix store deduplication):
>
> ;;; no code for module (gcrypt hash)
>
> Backtrace:
>
>   17 (primitive-load "/gnu/store/1fwvy0fz6zfgnyq1mj5pn8mfin7?")
>
> In ice-9/eval.scm:
>
> 619:8 16 (_ #f)
>
> In srfi/srfi-1.scm:
>
>460:18 15 (fold # ?)
>
>460:18 14 (fold # ?)
>
>460:18 13 (fold # ?)
>
> In ice-9/eval.scm:
>
> 619:8 12 (_ #(#(#) # ?))
>
> In ice-9/boot-9.scm:
>
>2806:4 11 (save-module-excursion #)
>
> In unknown file:
>
>   10 (primitive-load "./guix/store/deduplication.scm")
>
> In ice-9/eval.scm:
>
>721:20  9 (primitive-eval (define-module (guix store #) # (# #) ?))
>
> In ice-9/psyntax.scm:
>
>   1241:36  8 (expand-top-sequence ((define-module (guix store #) ?)) ?)
>
>   1233:19  7 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
>
>285:10  6 (parse _ (("placeholder" placeholder)) (()) _ c (eval) ?)
>
> In ice-9/eval.scm:
>
>293:34  5 (_ #)
>
> In ice-9/boot-9.scm:
>
>3380:4  4 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
>
>   2565:24  3 (call-with-deferred-observers #)
>
>   3393:24  2 (_)
>
>222:17  1 (map1 (((gcrypt hash)) ((guix build utils)) ((guix ?)) ?))
>
>3300:6  0 (resolve-interface (gcrypt hash) #:select _ #:hide _ # _ ?)
>
>
>
> ice-9/boot-9.scm:3300:6: In procedure resolve-interface:
>
> no code for module (gcrypt hash)

As discussed on IRC, the following command works for me:

  guix time-machine \
--commit=6a060ff27ff68384d7c90076baa36c349fff689d -- \
pull -p /tmp/test

However, I don’t have enough information about the issue.

Could you provide information on how to reproduce the issue?

Thanks in advance,
Ludo’.

bug#44999: guix deploy Error reading from the channel

[Jérémy Korwin-Zmijowski]

Hey Ludo' !

Thank you for asking !

I apologize to have not taken the time to investigate on this
(understand: put 'pk' commands everywhere haha. I don't know what else
to do).

Just did a retry. The command line still hangs with :

   $ guix deploy ynm-droplet-declaration.scm 
   La (1) machine suivante sera déployée :
 kitchen

   guix deploy: déploiement vers kitchen...

The droplet is created with the right hostname (kitchen in ynm / 1 GB
Memory  / 25 GB Disk  / FRA1 - Debian 9 x64)

So I SSH to the machine and ran some commands :

$ ssh root@165.22.28.15 -p 22 -i /home/jeko/.ssh/id_rsa.pub
The authenticity of host '165.22.28.15 (165.22.28.15)' can't be
established.
ECDSA key fingerprint is
SHA256:7dACwKdFtebnZB/vs/pMcChgsp3yoITOvATZFtXki+c.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes
Warning: Permanently added '165.22.28.15' (ECDSA) to the list of known
hosts.
Linux kitchen 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05)
x86_64

The programs included with the Debian GNU/Linux system are free
software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
# ls /root/
guix-binary-1.0.1.x86_64-linux.tar.xz
# ls /tmp/
guix-infect.sh  var
# guix --version
guix (GNU Guix) 1.0.1
Copyright (C) 2019 the Guix authors
License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

While I was writing this message, I've been disconnected from SSH

   root@kitchen:~# Connection to 165.22.28.15 closed by remote host.
   Connection to 165.22.28.15 closed.

And the following trace appeared on the hanging deploy command

   ;;; [2020/12/17 14:10:55.445770, 0] read_from_channel_port: [GSSH
   ERROR] Error reading from the channel: #

If I want to SSH again to the machine, I get this message :

   $ ssh root@165.22.28.15 -p 22 -i /home/jeko/.ssh/id_rsa.pub
   @@@
   @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
   @@@
   IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
   Someone could be eavesdropping on you right now (man-in-the-middle
   attack)!
   It is also possible that a host key has just been changed.
   The fingerprint for the ECDSA key sent by the remote host is
   SHA256:52FacP3UGfdq4zggEVW5cbCzlbqSepkZhki5qMo0bnQ.
   Please contact your system administrator.
   Add correct host key in /home/jeko/.ssh/known_hosts to get rid of
   this message.
   Offending ECDSA key in /home/jeko/.ssh/known_hosts:36
 remove with:
 ssh-keygen -f "/home/jeko/.ssh/known_hosts" -R "165.22.28.15"
   ECDSA host key for 165.22.28.15 has changed and you have requested
   strict checking.
   Host key verification failed.

That's all I can bring on the table right know ! 

To be continued…

Jérémy

bug#45294: guix system reconfigure won't run since commit 6a060ff27ff68384d7c90076baa36c349fff689d

[yasu]

Hi,

On my system, guix system reconfigure stopped running since commit:
6a060ff27ff68384d7c90076baa36c349fff689d.

The last good commit was its parent:
dea1ee1fd740248307f74ca4cb70b94742264098

Regards,
Yasu

~$ sudo guix system reconfigure  ~/config.scm

The following derivations will be built:
   /gnu/store/qhvxbh8fa832wd3j36j2lzlci5mdvyv9-system.drv
   /gnu/store/hkipg032lph2krlvdmsgyijxd10ywvaq-combined-initrd.drv
   /gnu/store/c063b54m10j25j1w72c8j71ybchx2ppf-microcode-initrd.drv
   /gnu/store/izqw36p3q10amfn1vq1wvghi1ihys6xa-module-import-
compiled.drv
   /gnu/store/yjlp5dp89saaasymxmls2jdshp8dbn6q-intel-microcode-
20201118.drv
   /gnu/store/961s8ggdwrv0zhks4q756xbsjbvgphls-intel-microcode-
20201118-checkout.drv
   /gnu/store/kj08l70y2jzwigkj5ncnhahj6cbxc8qr-module-import-
compiled.drv
   /gnu/store/jmk4d8nna8mdwwsaqvibfr05d3m38py0-module-import-
compiled.drv
   /gnu/store/zx61i0p7p6g23jsm4vp2icsqxypixiqw-raw-initrd.drv
   /gnu/store/z2cwj7an5nwgzqfy9904drc8bhfhyqqy-parameters.drv
   /gnu/store/ppnr4xm0zrfk3wmk3hzyqvn87fbfm6vf-grub.cfg.drv

building /gnu/store/jmk4d8nna8mdwwsaqvibfr05d3m38py0-module-import-
compiled.drv...
building /gnu/store/izqw36p3q10amfn1vq1wvghi1ihys6xa-module-import-
compiled.drv...
 46%
[  
  ]
builder for `/gnu/store/izqw36p3q10amfn1vq1wvghi1ihys6xa-module-import-
compiled.drv' failed with exit code 1
build of /gnu/store/izqw36p3q10amfn1vq1wvghi1ihys6xa-module-import-
compiled.drv failed
View build log at
'/var/log/guix/drvs/iz/qw36p3q10amfn1vq1wvghi1ihys6xa-module-import-
compiled.drv.bz2'.
cannot build derivation `/gnu/store/c063b54m10j25j1w72c8j71ybchx2ppf-
microcode-initrd.drv': 1 dependencies couldn't be built
building /gnu/store/zx61i0p7p6g23jsm4vp2icsqxypixiqw-raw-initrd.drv...
cannot build derivation `/gnu/store/hkipg032lph2krlvdmsgyijxd10ywvaq-
combined-initrd.drv': 1 dependencies couldn't be built
cannot build derivation `/gnu/store/ppnr4xm0zrfk3wmk3hzyqvn87fbfm6vf-
grub.cfg.drv': 1 dependencies couldn't be built
guix system: error: build of
`/gnu/store/ppnr4xm0zrfk3wmk3hzyqvn87fbfm6vf-grub.cfg.drv' failed
~$
~$



This is the content of:
/var/log/guix/drvs/iz/qw36p3q10amfn1vq1wvghi1ihys6xa-module-import-
compiled.drv.bz2


[ 1/26] Loading './gnu/build/linux-initrd.scm'...
[ 2/26] Loading './guix/base32.scm'...
[ 3/26] Loading './guix/build/store-copy.scm'...
[ 4/26] Loading './guix/build/syscalls.scm'...
[ 5/26] Loading './guix/build/utils.scm'...
[ 6/26] Loading './guix/combinators.scm'...
[ 7/26] Loading './guix/cpio.scm'...
[ 8/26] Loading './guix/progress.scm'...
[ 9/26] Loading './guix/records.scm'...
[10/26] Loading './guix/serialization.scm'...
[11/26] Loading './guix/sets.scm'...
[12/26] Loading './guix/store/deduplication.scm'...
;;; Failed to autoload copy-file/deduplicate in (guix store
deduplication):
;;; no code for module (gcrypt hash)
Backtrace:
  17 (primitive-load "/gnu/store/k6dm80bpy4p8w4255n6c84vp01j?")
In ice-9/eval.scm:
619:8 16 (_ #f)
In srfi/srfi-1.scm:
   460:18 15 (fold #
?)
   460:18 14 (fold #
?)
   460:18 13 (fold #
?)
In ice-9/eval.scm:
619:8 12 (_ #(#(#) # ?))
In ice-9/boot-9.scm:
   2806:4 11 (save-module-excursion #)
In unknown file:
  10 (primitive-load "./guix/store/deduplication.scm")
In ice-9/eval.scm:
   721:20  9 (primitive-eval (define-module (guix store #) # (# #) ?))
In ice-9/psyntax.scm:
  1241:36  8 (expand-top-sequence ((define-module (guix store #) ?)) ?)
  1233:19  7 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
   285:10  6 (parse _ (("placeholder" placeholder)) (()) _ c (eval)
?)
In ice-9/eval.scm:
   293:34  5 (_ #)
In ice-9/boot-9.scm:
   3380:4  4 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
  2565:24  3 (call-with-deferred-observers #

bug#44999: guix deploy Error reading from the channel

[Ludovic Courtès]

Hi Jérémy,

Jérémy Korwin-Zmijowski  skribis:

> I made some more attempts. I was unable to reproduce the previous
> scenario… Looks like with my ssh connections I put myself in an
> exceptionnal situation.
>
> All I got is `guix deploy` running forever (I let it more than 2 hours)
>
>$ guix deploy ynm-droplet-declaration.scm
>La (1) machine suivante sera déployée :
>  ynm1607086083
>
>guix deploy: déploiement vers ynm1607086083...
>
> I have to kill it myself. There is no guix on the target system.
>
> As soon as I get some time I will try to determine where it stops.

Did it eventually succeed?  Or do you keep hitting hangs?

Thanks,
Ludo’.

bug#45193: Wrapper of Qt programs doesn't extend existing environment variable

[Zhu Zihao]

I try to read and understand how wrap-qt-program in qt-utils.scm works.
When building QT program, Guix builder populates qt related environment
variable, and wrap-qt-program just record it into wrapper.

However, the wrap behaviour in qt-build-system is quite different, it
search all inputs and mark them should be included in envvar definition
if correspond directory exists.

Another difference is, wrap-qt-program will include the directory of
output in envvar but qt-build-system won't do.

I'm not sure whether we need to include output, and don't know recording
build time environment follows reproducible build rule or not. Maybe we
need an expert on Qt programming/packaging to give us some hints? :(

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#45279: [core-updates] copy-recursively does not throw an error on missing directory

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> On the 'core-updates' branch, using copy-recursively on a nonexistent
> directory does not cause a build failure.  Instead an error is printed
> and the script continues:
>
>   (copy-recursively "doesnotexist" output)
>   [...]
>   starting phase `install'
>   i/o error: doesnotexist: No such file or directory
>   phase `install' succeeded after 0.0 seconds
>
> This is on cc6cb6e80a42355147809b4830053a34d1563994.

I think it’s always been this way.  Do you think we should change it?

Thanks,
Ludo’.

bug#45290: man-db links to the wrong libraries when cross-compiling

[Efraim Flashner]

'man mkfs.ext4' fails on aarch64 when cross-compiled from x86_64. It is
unable to execute 'gzip'. file /gnu/store/...-gzip-1.10/bin/gzip' shows
it is for x86_64.

It also links to the wrong bzip2 and xz.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature