bug#60719: Acknowledgement (openbios-qemu-ppc fails to build on aarch64)
Fixed as of 042b92edb20648c030dcbaf59acd176731550b70 -- Andrew Patterson
bug#54944: guix pull hangs on 32 bit
Csepp writes: > Csepp writes: > >> Maxim Cournoyer writes: >> >>> Hi! >>> >>> raingloom writes: >>> It's been at 67% on guix-packages-base for at least an hour now. The system itself is responsive and with the swap I gave it, it has more than enough memory. Htop shows three guile processes at the top of the list when sorted by CPU%, their states are S, D, D. Both CPUs are practically idling. This looks like some kind of lockup to me. Fresh install based on bare-bones example on a 32 bit netbook, but the install image used is the latest tagged version, since apparently there is no 32 bit option for edge. I also tried pulling using channel-with-substitutes, since I'm not too keen on locally building everything on such an old machine. Although Guix itself should frankly not take this long to build if we want to be competitive with other distros. Anyways, pulling with that in channels.scm gives a cert related error, so that's great, means old images can't easily be used for installation. >>> >>> Have you been able to reproduce this? If so, could you share the commit >>> you are starting from and the CPU architecture, so that we may hopefully >>> reproduce too? >>> >>> Thanks, >>> >>> Maxim >> >> CPU architecture is x86, commit it happened on last time is 347733b. >> Other possibly relevant factors: >> * spinning rust storage >> * 1GB RAM >> * encrypted BTRFS root >> * 4GB (encrypted) swap >> * 128MB zswap >> >> The last was not there when I originally submitted the bug. >> >> The swap is relevant because if it's a timing issue it's very possible >> some part of the code assumes reads are almost instant, which is not >> true with swap, and delaying a read might be exposing a race condition. > > Happening again. > pulled to: 8320c0c > pulled from: 4501a50 > > Same system. > > The system version is from november of last year due, because trying to > upgrade takes so damn long and often gets stuck on some package with no > substitute. > So... the situation is not great... The process status says sleep so it's probably hanging in a syscall? Maybe a kernel bug?
bug#54944: guix pull hangs on 32 bit
Csepp writes: > Maxim Cournoyer writes: > >> Hi! >> >> raingloom writes: >> >>> It's been at 67% on guix-packages-base for at least an hour now. The >>> system itself is responsive and with the swap I gave it, it has more >>> than enough memory. Htop shows three guile processes at the top of the >>> list when sorted by CPU%, their states are S, D, D. >>> Both CPUs are practically idling. >>> This looks like some kind of lockup to me. >>> >>> Fresh install based on bare-bones example on a 32 bit netbook, but the >>> install image used is the latest tagged version, since apparently there >>> is no 32 bit option for edge. >>> >>> I also tried pulling using channel-with-substitutes, since I'm not too >>> keen on locally building everything on such an old machine. Although >>> Guix itself should frankly not take this long to build if we want to be >>> competitive with other distros. Anyways, pulling with that in >>> channels.scm gives a cert related error, so that's great, means old >>> images can't easily be used for installation. >> >> Have you been able to reproduce this? If so, could you share the commit >> you are starting from and the CPU architecture, so that we may hopefully >> reproduce too? >> >> Thanks, >> >> Maxim > > CPU architecture is x86, commit it happened on last time is 347733b. > Other possibly relevant factors: > * spinning rust storage > * 1GB RAM > * encrypted BTRFS root > * 4GB (encrypted) swap > * 128MB zswap > > The last was not there when I originally submitted the bug. > > The swap is relevant because if it's a timing issue it's very possible > some part of the code assumes reads are almost instant, which is not > true with swap, and delaying a read might be exposing a race condition. Happening again. pulled to: 8320c0c pulled from: 4501a50 Same system. The system version is from november of last year due, because trying to upgrade takes so damn long and often gets stuck on some package with no substitute. So... the situation is not great...
bug#61513: [PATCH 1/2] gnu: Add emacs-next-tree-sitter.
Am Montag, dem 20.02.2023 um 11:33 +0100 schrieb Simon Tournier: > Hi, > > On jeu., 16 févr. 2023 at 21:36, Liliana Marie Prikler > wrote: > > * gnu/packages/emacs.scm (emacs-next-tree-sitter): New variable. > > (emacs-next): Remove tree sitter support. > > Naive question: why not squash the 2 patches? Adding the new > variable and fix the version of emacs-next. Because the next patch "upgrades" emacs-next to the then HEAD of the emacs-29 branch, which wasn't hitherto packaged in Guix. Alternatively, one could reset it to an earlier version in the first commit, but we have a(n informal) policy that discourages downgrades. Cheers
bug#53250: icedove clears user data on upgrade
Hi,
Nicholas von Klitzing writes:
> Hi Jonathan,
>
> Thanks for testing the patch. What exactly doesn't work?
>
> Is icedove still generating new profiles upon install?
>
> Even if it stops generating profiles, you still need to use `icedove -p` to
> select the correct default.
I believe the reason it wasn't working was because the substitution of
the MOZ_DEDICATED_PROFILES value to False was not effective:
I believe this should fix it:
--8<---cut here---start->8---
modified gnu/packages/gnuzilla.scm
@@ -1335,8 +1335,8 @@ (define-public icedove-minimal
(add-after 'patch-source-shebangs 'fix-profile-setting
(lambda _
(substitute* "comm/mail/moz.configure"
-(("MOZ_DEDICATED_PROFILES, True")
- "MOZ_DEDICATED_PROFILES, False"
+(("\"MOZ_DEDICATED_PROFILES\", True")
+ "\"MOZ_DEDICATED_PROFILES\", False"
(add-after 'build 'neutralize-store-references
(lambda _
;; Mangle the store references to compilers & other build tools
in
--8<---cut here---end--->8---
Pushed to master as c81d2d448c, after testing resolution on an affected
machine.
Closing!
--
Thanks,
Maxim
bug#30435: libreoffice: Fonts don't show up after install
Hi Felix, Felix Lechner writes: > Hi, > > On Mon, Feb 20, 2023 at 8:06 AM Maxim Cournoyer > wrote: >> >> I haven't seen this problem in a long while, so I'm inclined to think >> it's been resolved. > > I think I had that issue with a fresh install within the last year and > based on advice in IRC (thanks nckx!) ran 'fc-cache -fv'. OK, thanks for the information; let's leave this bug open then. > For what it's worth, I believe Debian's packaging tools (in this case, > Debhelper) detect changes to the font directories and add a font > update hook to the package installation scripts. Since we do not have > such scripts—and I am with Ludo' that it's probably a feature worth > preserving—maybe our package manager could run the hook? Another idea: modify fontconfig so that it never creates or uses cache. Revisit later if it causes performance problems (I doubt it would). -- Thanks, Maxim
bug#30435: libreoffice: Fonts don't show up after install
Hi, On Mon, Feb 20, 2023 at 8:06 AM Maxim Cournoyer wrote: > > I haven't seen this problem in a long while, so I'm inclined to think > it's been resolved. I think I had that issue with a fresh install within the last year and based on advice in IRC (thanks nckx!) ran 'fc-cache -fv'. For what it's worth, I believe Debian's packaging tools (in this case, Debhelper) detect changes to the font directories and add a font update hook to the package installation scripts. Since we do not have such scripts—and I am with Ludo' that it's probably a feature worth preserving—maybe our package manager could run the hook? Kind regards Felix Lechner
bug#30435: libreoffice: Fonts don't show up after install
Hi Ludovic,
Ludovic Courtès writes:
> Hi,
>
> Pierre Neidhardt skribis:
>
>> Running
>>
>> fc-cache -fv
>>
>> fixes the issue.
>>
>> Should we run this command in a profile hook?
>
> Profile hooks are normal derivations; as such, they don’t have access to
> anything but their dependencies and their output(s).
>
> There’s currently no infrastructure to run arbitrary code upon package
> installation (which I think is a feature more than a bug :-)). We could
> make an exception, but it’s kinda ugly.
>
> I wonder if, instead, we could have Fontconfig realize that the cache is
> stale somehow.
>
> Alternately, we could generate the cache in a profile hook and have
> Fontconfig use that cache instead of the one in ~/.cache. However,
> Fontconfig would need to be able to:
>
> 1. Be told which cache to use, not just the one from ~/.guix-profile,
> so that it works equally well with other profiles.
That's possible since adding support to XDG_DATA_DIRS in fontconfig
itself (see c738a054cac00441a4f697f0b40705d0b3f4a7a7, "gnu: fontconfig:
Add a search path for XDG_DATA_DIRS.").
> 2. Merge several caches, so it can also account for fonts installed in
> /run/current-system/profile.
There was also something contributed that should have improved/fix cache
invalidity in 6f12880a76a6c91058718d15845f8b9d9b529a5a ("gnu:
fontconfig: Use (locally) deterministic caching").
I haven't seen this problem in a long while, so I'm inclined to think
it's been resolved.
--
Thanks,
Maxim
bug#32026: [PATCH v4 1/9] gnu: Add a 'update-mozilla-locales' helper for maintenance.
Hi Ludovic, Ludovic Courtès writes: > Hey Maxim, > > Thanks a lot for working on this! Having locales available makes a big > difference to many users. > > (A couple of years ago I started working on that for the LibreOffice > package. I got quite far but didn’t complete it. I can dig that from > my stashes if there’s interest in giving a hand.) I'd be interested to pick it up, yes! Perhaps not in the coming 2 weeks, which will be very busy for me, but afterward. -- Thanks, Maxim
bug#58485: [shepherd] Restarting guix-publish fails
Hi Ludo,
> Can you confirm shepherd (PID 1) is 0.9.3?
it is:
root 1 0.2 0.2 308148 76816 ?Sl Feb07 52:08
/gnu/store/kphp5d85rrb3q1rdc2lfqc1mdklwh3qp-guile-3.0.9/bin/guile
--no-auto-compile
/gnu/store/4nw0zb4swga0cb8i35nvng3rg6z5qm8p-shepherd-0.9.3/bin/shepherd
--config /gnu/store/cvrai6z8777jf7860rnvppfznl1lcxi1-shepherd.conf
> ‘sudo herd restart ssh-daemon’ works fine on my laptop FWIW.
This works fine too. Only unattended-upgrades seems to have this issue :/
The strace looks unsuspicious right now:
---snip---
1 14:12:15.117035 read(21, "(shepherd-command (version 0) (action restart)
(service ssh-daemon) (arguments ()) (directory \"/root\"))", 1024) = 103
1 14:12:15.117254 close(27) = 0
1 14:12:15.117283 close(30) = 0
1 14:12:15.117416 newfstatat(AT_FDCWD, "/etc/localtime",
{st_dev=makedev(0x8, 0x2), st_ino=110100491, st_mode=S_IFREG|0444, st_nlink=1,
st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, s
t_size=2298, st_atime=1676898665 /* 2023-02-20T14:11:05.338746772+0100 */,
st_atime_nsec=338746772, st_mtime=1676898664 /*
2023-02-20T14:11:04.874743456+0100 */, st_mtime_nsec=874743456, st_c
time=1676898664 /* 2023-02-20T14:11:04.874743456+0100 */,
st_ctime_nsec=874743456}, 0) = 0
1 14:12:15.117475 write(17, "shepherd[1]: Service ssh-daemon has been
stopped.\n", 50) = 50
1 14:12:15.117524 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK,
IPPROTO_IP) = 26
1 14:12:15.117561 setsockopt(26, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
1 14:12:15.117598 bind(26, {sa_family=AF_INET, sin_port=htons(),
sin_addr=inet_addr("0.0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
1 14:12:15.117724 write(21, "(reply (version 0) (result #f) (error (error
(version 0) action-exception start ssh-daemon system-error (\"bind\" \"~A\"
(\"Address already in use\") (98 (messages (\"Service ssh-daemon has been
stopped.\")))", 204) = 204
1 14:12:15.117754 close(21) = 0
---snap---
But nginx seems to have the same issue, except that it does not fail
entirely and succeeds after waiting a short period of time:
---snip---
2023/02/20 14:12:14 [notice] 7136#0: signal 15 (SIGTERM) received from 6644,
exiting
2023/02/20 14:12:14 [notice] 7137#0: exiting
2023/02/20 14:12:14 [notice] 7137#0: exit
2023/02/20 14:12:14 [notice] 7136#0: signal 17 (SIGCHLD) received from 7137
2023/02/20 14:12:14 [notice] 7136#0: worker process 7137 exited with code 0
2023/02/20 14:12:14 [emerg] 6645#0: bind() to 0.0.0.0:443 failed (98: Address
already in use)
2023/02/20 14:12:14 [emerg] 6645#0: bind() to 0.0.0.0:80 failed (98: Address
already in use)
2023/02/20 14:12:14 [emerg] 6645#0: bind() to [::]:80 failed (98: Address
already in use)
2023/02/20 14:12:14 [notice] 7136#0: exit
2023/02/20 14:12:14 [notice] 6645#0: try again to bind() after 500ms
2023/02/20 14:12:14 [notice] 6645#0: using the "epoll" event method
2023/02/20 14:12:14 [notice] 6645#0: nginx/1.23.3
2023/02/20 14:12:14 [notice] 6645#0: OS: Linux 6.1.9
2023/02/20 14:12:14 [notice] 6645#0: getrlimit(RLIMIT_NOFILE): 1024:4096
2023/02/20 14:12:14 [notice] 6648#0: start worker processes
2023/02/20 14:12:14 [notice] 6648#0: start worker process 6649
2023/02/20 14:12:32 [info] 6649#0: epoll_wait() failed (4: Interrupted system
call)
---snap---
I see we’re already using SO_REUSEADDR, so all of this is a bit of a
mystery to me.
Thanks,
Lars
--
Lars-Dominik Braun
Wissenschaftlicher Mitarbeiter/Research Associate
www.leibniz-psychology.org
ZPID - Leibniz-Institut für Psychologie /
ZPID - Leibniz Institute for Psychology
Universitätsring 15
D-54296 Trier - Germany
Tel.: +49–651–201-4964
signature.asc
Description: PGP signature
bug#61642: intermittent write_wait_fd error when updating
Simon Tournier writes: > Hi, > > On Mon, 20 Feb 2023 at 11:46, Christopher Baines wrote: > >> It's not, since it relates to code in the (guix substitutes) module. > > Do you mean that if "https://substitutes.nonguix.org; is incorrectly > configured, then the code in (guix substitutes) should handle the > error instead of crash with a backtrace? No, but to answer your question, yes. I don't think this is a server side code/configuration issue. Also see this older bug for the same issue https://issues.guix.gnu.org/56005 signature.asc Description: PGP signature
bug#32026: [PATCH v4 1/9] gnu: Add a 'update-mozilla-locales' helper for maintenance.
Hey Maxim, Thanks a lot for working on this! Having locales available makes a big difference to many users. (A couple of years ago I started working on that for the LibreOffice package. I got quite far but didn’t complete it. I can dig that from my stashes if there’s interest in giving a hand.) Ludo’.
bug#61642: intermittent write_wait_fd error when updating
Hi, On Mon, 20 Feb 2023 at 11:46, Christopher Baines wrote: > It's not, since it relates to code in the (guix substitutes) module. Do you mean that if "https://substitutes.nonguix.org; is incorrectly configured, then the code in (guix substitutes) should handle the error instead of crash with a backtrace? Cheers, simon
bug#61642: intermittent write_wait_fd error when updating
Simon Tournier writes: > Hi, > > On dim., 19 févr. 2023 at 17:50, Nathan Dehnel wrote: > >> 'https://substitutes.nonguix.org'... 0.0%Backtrace: > > [...] > >> "https://substitutes.nonguix.org; _ # _ …) > > The issue appears to be on the nonguix side, please report to them. It's not, since it relates to code in the (guix substitutes) module. signature.asc Description: PGP signature
bug#61513: [PATCH 1/2] gnu: Add emacs-next-tree-sitter.
Hi, On jeu., 16 févr. 2023 at 21:36, Liliana Marie Prikler wrote: > * gnu/packages/emacs.scm (emacs-next-tree-sitter): New variable. > (emacs-next): Remove tree sitter support. Naive question: why not squash the 2 patches? Adding the new variable and fix the version of emacs-next. Cheers, simon
bug#61642: intermittent write_wait_fd error when updating
Hi, On dim., 19 févr. 2023 at 17:50, Nathan Dehnel wrote: > 'https://substitutes.nonguix.org'... 0.0%Backtrace: [...] > "https://substitutes.nonguix.org; _ # _ …) The issue appears to be on the nonguix side, please report to them. Cheers, simon
bug#58485: [shepherd] Restarting guix-publish fails
Hi Lars,
Lars-Dominik Braun skribis:
>> Indeed. This is fixed by Shepherd commit
>> d97592f58603ff51cb280ae57d413c8731e601b3, which will be in the upcoming
>> 0.9.3 release.
> I’m on 0.9.3 and it works fine with `herd restart` now. But ssh-daemon
> has the same issue when being restarted by unattended-upgrades (which
> is fatal, because unable to use SSH I have to restart the entire box):
>
> ---snip---
> shepherd: Service nginx has been stopped.
> shepherd: Service nginx has been started.
> shepherd: Service collectd has been stopped.
> shepherd: Service collectd has been started.
> shepherd: Service ntpd has been stopped.
> shepherd: Service ntpd has been started.
> shepherd: Service guix-publish has been stopped.
> shepherd: Service guix-publish has been started.
> shepherd: Service ssh-daemon has been stopped.
> Backtrace:
>7 (primitive-load "/gnu/store/ip5m1n8kb6p0rfglzpkk17k060a?")
> In ice-9/boot-9.scm:
> 724:2 6 (call-with-prompt ("prompt") # ?)
> 1752:10 5 (with-exception-handler _ _ #:unwind? _ # _)
> In ice-9/eval.scm:
> 619:8 4 (_ #(#(#)))
> In ice-9/boot-9.scm:
>260:13 3 (for-each # _)
> In gnu/services/herd.scm:
> 168:4 2 (invoke-action ssh-daemon restart () #)
> 176:7 1 (failure)
> In ice-9/boot-9.scm:
> 1685:16 0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> ERROR:
> 1. :
> service: ssh-daemon
> action: start
> key: system-error
> args: ("bind" "~A" ("Address already in use") (98)
> ---snap---
>
> Maybe I can strace herd and see what happens exactly.
Can you confirm shepherd (PID 1) is 0.9.3?
‘sudo herd restart ssh-daemon’ works fine on my laptop FWIW.
Note that the situation is different from that of ‘guix publish’: here
it’s inetd style, as opposed to systemd style for ‘guix publish’.
Thanks,
Ludo’.
