Sebastian Gibb skribis:
> the python-peachpy package fails to build in the current available version
> python-peachpy-0.2.0-1.906d578, see
> http://ci.guix.gnu.org/build/851814/details
Apparently breakage occured in the
Hey there,
Ludovic Courtès skribis:
> So it would seem that the solution to this is to prevent dbus-daemon
> from starting elogind. We can do that by changing
> org.freedesktop.login1.service so that it has “Exec=true” instead of
> “Exec=elogind --daemon”.
>
> “Exec=true” is a bit crude
On 2022-05-27, Vagrant Cascadian wrote:
> I've been working on a package called lcsync:
>
> https://issues.guix.gnu.org/55682
>
> But lcsync needs CAP_NET_RAW... Normally, this is accomplished by
> running:
>
> setcap cap_net_raw=eip /path/to/bin/lcsync
Similar issues seem to have come up for
I've been working on a package called lcsync:
https://issues.guix.gnu.org/55682
But lcsync needs CAP_NET_RAW... Normally, this is accomplished by
running:
setcap cap_net_raw=eip /path/to/bin/lcsync
You could add lcsync to setuid-programs, but this would be a terrible
idea, as it's a file
Ludovic Courtès skribis:
> Currently (40a729a0e6f1d660b942241416c1e2c567616d4d), shepherd and
> dbus-daemon compete to start elogind: shepherd tries to start it
> eagerly, and dbus-daemon starts it on-demand upon bus activation.
>
> Sometimes dbus-daemon wins, and thus shepherd tries a few times
Hi,
the python-peachpy package fails to build in the current available version
python-peachpy-0.2.0-1.906d578, see
http://ci.guix.gnu.org/build/851814/details
Please find the error message below. While I don't understand python I believe
the problem is fixed upstream with the following commit:
Hello Liliana Marie,
Liliana Marie Prikler writes:
[...]
> Anyway, I fixed the actual bug, so it's no longer necessary to debate
> workarounds.
Thanks a lot for your fix!
For posterity, commit d37c7f7ad4134cc15d1558eb6c0bc4c59a0db1af fixes
this bug
Upstream, it's fixed in pull request dated
Hi,
On Thu, 26 May 2022 at 17:05, Ludovic Courtès wrote:
> This file was empty when you ran the command instead of containing an
> integer (could have been a file system corruption or something like
> that).
No, I did nothing special and the file system is not corrupted. :-)
I am just using
Am Mittwoch, dem 25.05.2022 um 19:09 +0200 schrieb Giovanni Biscuolo:
> I'm not able to find what's the call with the wrong number of
> arguments but what about to (temporary) disable the failing tests
> like for example in 0ae9e75c31b22ea55093f4cd05954f366b1f8bcc (emacs-
> eply)?
That's unlikely
