bug#72315: [bug#72643] [PATCH core-updates 0/6] Restore i586-gnu (GNU/Hurd) support

2024-08-18 Thread Janneke Nieuwenhuizen
Ludovic Courtès writes:

Hello,

> Janneke Nieuwenhuizen  skribis:
>
>> As mentioned on IRC, I've reconfigured my system to core-updates+this
>> patch series and it works for me.
>
> Pushed as 817838c38bbeb4ef7dcb64af5fce168aeb51306e, thanks for testing!

Yay!

>> --- a/gnu/system/examples/devel-hurd.tmpl
>> +++ b/gnu/system/examples/devel-hurd.tmpl
>> @@ -59,7 +59,7 @@
>>  (define guix-packages
>>(filter-map input->package
>>(fold alist-delete (package-direct-inputs guix)
>> -'("glibc-utf8-locales" "graphviz" "po4a"
>> +'("glibc-utf8-locales" "graphviz" "imagemagick" 
>> "po4a"
>
> I’ve submitted a patch to remove it:
>
>   https://issues.guix.gnu.org/72674

Thanks, that's great.

> Regarding ‘hurd-team’, I admit I had forgotten about it.  What are the
> important things we should bring over to ‘master’ or ‘core-updates’?

I don't think so; most of it is not really finished.  Possibly

--8<---cut here---start->8---
d7562eae93 hurd: Support system init in /libexec/runsystem.
b9b5f1ee5f hurd-boot: Support system init: Create essential device nodes.
ddba840edd system: hurd: Add swap-services to hurd-default-essential-services.
--8<---cut here---end--->8---

that help booting the Hurd after installing it on real hardware from a
GNU/Linux Guix installation with `guix init ... /hurd'.  After `guix
init', you'll have to reconfigure the GNU/Linux system, adding
menu-entries from /hurd/boot/grub.cfg (at least, that's what I did using
some ugly regex parsing in config.scm).

But these are not so interesting, because they will support booting Hurd
only once.  Supporting a second boot is more tricky and only has these
even less finished patches

--8<---cut here---start->8---
fa003825ef DRAFT hurd-boot: Support second boot.
6b34e08e4d DRAFT hurd: Support second boot.
--8<---cut here---end--->8---

These only work if the filesystem is clean -- which most of the time is
not the case when you restart -- why would you restart if not for a
kernel crash.  That means you'll have to boot into GNU/Linux and fsck
/hurd.

I'm using

--8<---cut here---start->8---
59ae639ac6 DRAFT system: examples: Add devel-hurd.tmpl.
--8<---cut here---end--->8---

as a convenience to build a childhurd to develop in (as opposed to just
offloading to).

ISTM that I've been the only user of these and they're not all that
great.  So yeah.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com





bug#72693: openscad-2021.01 build failure

2024-08-18 Thread bdju
build log here: https://0x0.st/X4Rv.txt

```
building /gnu/store/7fc94ifad3hc5i1vvvm8vkq80bvqfn7x-openscad-2021.01.drv...
\ 'build' phase��@ build-log 21141 217
��op1’ [-Wunused-parameter]
  773 |   template  Value operator()(const T &op1, 
const U &op2) const { return false; }
  |  ~^~~
| 'build' phasebuilder for 
`/gnu/store/7fc94ifad3hc5i1vvvm8vkq80bvqfn7x-openscad-2021.01.drv' failed with 
exit code 1
build of /gnu/store/7fc94ifad3hc5i1vvvm8vkq80bvqfn7x-openscad-2021.01.drv failed
View build log at 
'/var/log/guix/drvs/7f/c94ifad3hc5i1vvvm8vkq80bvqfn7x-openscad-2021.01.drv.gz'.
guix package: error: build of 
`/gnu/store/7fc94ifad3hc5i1vvvm8vkq80bvqfn7x-openscad-2021.01.drv' failed
guix package --upgrade . --do-not-upgrade={pfetch,rgbds}  852.41s user 4.31s 
system 37% cpu 38:13.46 total
```

guix version: guix (GNU Guix) 6c045f2c9eb7b8efe7c8a1002cda990abaa9be1a
***I am using Guix System.***





bug#72694: kaidan-0.9.0 build failure

2024-08-18 Thread bdju
build log: https://0x0.st/X4R7.txt

```
building /gnu/store/qclfsd734zvd85ydpqqlk335yp83fwk9-kaidan-0.9.0.drv...
- 'configure' phasebuilder for 
`/gnu/store/qclfsd734zvd85ydpqqlk335yp83fwk9-kaidan-0.9.0.drv' failed with exit 
code 1
build of /gnu/store/qclfsd734zvd85ydpqqlk335yp83fwk9-kaidan-0.9.0.drv failed
View build log at 
'/var/log/guix/drvs/qc/lfsd734zvd85ydpqqlk335yp83fwk9-kaidan-0.9.0.drv.gz'.
guix package: error: build of 
`/gnu/store/qclfsd734zvd85ydpqqlk335yp83fwk9-kaidan-0.9.0.drv' failed
guix package --upgrade . --do-not-upgrade={pfetch,rgbds,openscad}  750.74s user 
3.04s system 132% cpu 9:27.78 total
```

guis version: guix (GNU Guix) 6c045f2c9eb7b8efe7c8a1002cda990abaa9be1a
I am running Guix System.





bug#69267: icedove.desktop has no StartupWMClass

2024-08-18 Thread Jonathan Brielmaier via Bug reports for GNU Guix

I have submitted a patch at https://issues.guix.gnu.org/67849#11

~Jonathan





bug#72697: cmake-build-system sets wrong CMAKE_SYSTEM_NAME when crossbuilding for Hurd

2024-08-18 Thread Dariqq

Hi,

I was playing around with a package using cmake and got an error when 
crossbuilding for i586-pc-gnu. The reason seems to be that cmake build 
system only checks for a mingw target and assumes all other targets are 
Linux and sets CMAKE_SYSTEM_NAME accordingly.


I am able to work around it by adding something like

#$@(if (and (%current-target-system)
target-hurd?)
   '("-DCMAKE_SYSTEM_NAME=GNU")
   '())

to the configure-flags of my package.


I am unsure how a fix should look like. I was thinking of moving the 
entire crossbuild code out of the build side and instead prepend the 
right configure flags for the target to configure-flags for the cross 
builder kind of similar how meson-build-system does it.


Unfortunately a change like this causes a lot of rebuilds.





bug#72670: avahi-daemon can fail to restart due to stale /run/avahi-daemon/pid

2024-08-18 Thread Ludovic Courtès
Ludovic Courtès  skribis:

> But the core problem seems to be that ‘cleanup-service-type’ deletes
> /var/run at boot but not /run.  I guess it should delete /run as well?

Oh, it’s already filed here: https://issues.guix.gnu.org/64775





bug#69267: icedove.desktop has no StartupWMClass

2024-08-18 Thread Jonathan Brielmaier via Bug reports for GNU Guix

Fixed via
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b1b3724996952102ad2751fa5111c6e8680b2ed4

I think it works now, as in my GNOME session icedove behaves as intended.

~Jonathan





bug#72687: System installation failed

2024-08-18 Thread Leon Schröder
Hello,

I tried to install Guix on some hardware I had l lying around and it did
not quite work out.  I used the graphical installer and did not do anything
special.  The Installation failed, and I was asked if I wanted to report a
problem, after which I chose the upload functionality in the Installer.
The uploaded achive is called "installer-dump-fe4c231a".  The installer did
not complain about non-free hardware.

I hope this helps to impove Guix.

Kind regards
Leon Schröder


bug#72166: Shepherd periodically goes unresponsive on one of my machines

2024-08-18 Thread Jonathan Frederickson
On Fri, Aug 16, 2024, at 12:12 PM, Ludovic Courtès wrote:
> Could you share (maybe privately) the relevant excerpt of
> /var/log/messages?
> 
> Could you also share (ideally) a minimum Guix System config and a
> sequence of commands to reproduce it?
> 
> Are you able to reproduce it in ‘guix system vm’?

I'll send some logs to you privately; I don't actually see any logs that look 
relevant in /var/log/messages but maybe you'll spot something I haven't.

I'll try to come up with a reproduction and a minimal system config to 
reproduce the issue, though I will say that I haven't yet tracked down the 
exact situation that triggers it.

(Perhaps notably, both this machine running Guix System and another machine 
running Guix Home on a foreign distro where I've experienced the same issue are 
running Sway, and I think swaylock may be related somehow.)

I'll also try reproducing it with 'guix system vm' if I can, though that may be 
challenging as this machine only has 4 GB of RAM.