bug#63331: Guile-GnuTLS/Git circular dependency

[Simon Josefsson via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> We need to solve that.  For now, the only fix I can think of is having
> ‘guile-gnutls’ built from a “make dist”-provided tarballs.  Apparently
> we can add assets at ; would you
> like to upload a tarball and accompanying signature, Simon?

The tarballs I created are available here:
https://gitlab.com/gnutls/guile/-/releases

Is a new releases necessary, or does the 3.7.11 release work?  I can do
a release tonight or tomorrow, but I'm also happy to help someone else
to do the release -- see README-release for the process, skip 'make
upload' if you don't have ftp.gnu.org gnutls credentials.

I'm not sure I exactly what the real problem is here -- but would one
solution be to publish a source-only tarball with the source code files
from git, together with a signature?  That would include any gnulib
files, but not autogenerated ./configure etc.

/Simon


signature.asc
Description: PGP signature

bug#62496: For network-manager-applet's nm-connection-editor, libnma needs to be installed

[Maxim Cournoyer]

Hi,

Josselin Poiret  writes:

> Hi everyone,
>
> Maxim Cournoyer  writes:
>
>> I've reverted to the previously working version on master, but we should
>> figure out what's up with this change in recent releases.  It may affect
>> 1.42 as well (which is supposedly the current stable release).
>>
>> Leaving this open.  Thanks for investigating.
>
> The patchset I sent in [1] should resolve this, I've been happily
> running with it.

Installed, thank you!

-- 
Thanks,
Maxim

bug#57826: NetworkManager GUI crashes when setting up eduroam

[Maxim Cournoyer]

Hi,

Csepp  writes:

> I have not yet debugged this properly, here is what I know:
> When I used nm-applet to fill out the WPA2 enterprise connection
> details, nm-applet crashed.
> When I tried sudo nm-connection-editor (because I thought it was a
> permission error, which is also present, yay) it produced this error:
>
> Trace/breakpoint trap
>
> I will try to strace or gdb it later, but I'd be very thankful if
> someone who knows more about GTK looked into it.

Could you try again after a Guix pull and with 'sudo -E
nm-connection-editor' ?  NetworkManager was just updated.

-- 
Thanks,
Maxim

bug#62294: gnupg is pinned at 2.2.32 for bug that is fixed upstream

[Maxim Cournoyer]

Hello,

We're now at 2.2.39 on master.  Closing!

-- 
Thanks,
Maxim

bug#62379: /gnu/store/.links filling the hard drive on foreign distro

[Maxim Cournoyer]

Hi,

Ludovic Courtès  writes:

> Hi,
>
> Elias Kueny  skribis:
>
>> The problem is the size of /gnu/store/.links: after garbage collection
>> with "guix gc --delete-generations=1w", /gnu/store is 17.4 GB in
>> total, and /gnu/store/.links is 14.5 GB (344120 items, ranging from 93
>> MB to 4.1 kB each).
>
> This is expected: /gnu/store/.links contains hard links to other files
> in /gnu/store.  IOW /gnu/store/.links is a subset of the rest of
> /gnu/store, sharing the same inodes.
>
>> The garbage collector prints that "currently hard linking saves
>> 3717.77 MiB".  With a 40GB hard drive, the gnu store regularly fills
>> up all the available space if I'm not careful. I found from an old
>> issue (https://issues.guix.gnu.org/24937#1) that 10 millions links
>> should need around 700 MB, so this sounds like a bug.
>
> Note that the issue you mention was addressed to a large extent in 2021:
>
>   https://issues.guix.gnu.org/24937#20
>

Closing, as this is working as intended.  If you do not wish to use the
guix-daemon deduplication feature, you can provide it with the
'--disable-deduplication', with the caveat that your hard drive may be
filled even faster :-).

-- 
Thanks,
Maxim

bug#63284: proot: Build gets stuck in test-0cf405b0 (and maybe test-25069c13)

[Blake Shaw via Bug reports for GNU Guix]

I'm also dealing with the issue, except for me it gets stuck in
test-kkk, if that info is helpful at all. 

Josselin Poiret via Bug reports for GNU Guix  writes:

> [[PGP Signed Part:Undecided]]
> Hi Ivan,
>
> Ivan Vilata i Balaguer  writes:
>
>> Hi!  It looks like some tests during the build of `proot` get stuck in the
>> version of Guix shown below:
>
> I already provided fixes for two tests upstream [1] but I'm waiting on
> [2] since it seems like an actual regression.

> [1] https://github.com/proot-me/proot/pull/351
> [2] https://github.com/proot-me/proot/issues/352
>
> Best,

bug#63350: [BUG] emacs-tmr cannot find ffplay at runtime when timers end

[Kyle Andrews]

Dear Guix,

The emacs-tmr package does not play the alert sound for me. Instead, I see the 
following error in the message buffer:

Error running timer ‘tmr--complete’: (user-error "Cannot play 
/gnu/store/b91yva8kcx7zkdn9g1cz8n2943s0qnas-sound-theme-freedesktop-0.8/share/sounds/freedesktop/stereo/alarm-clock-elapsed.oga
 without ‘ffplay’")

There is an added patch-paths phase which seems to be trying to point ffplay to 
an absolute path. It just doesn't seem to matter.

bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

> Am Samstag, dem 06.05.2023 um 22:55 -0400 schrieb Maxim Cournoyer:
>> Hi!
>> 
>> Liliana Marie Prikler  writes:
>> 
>> > Am Freitag, dem 05.05.2023 um 14:29 -0400 schrieb Maxim Cournoyer:
>> > Didn't we agree in v2 that we want to address this on the account-
>> > service level?  Unless the rest of this series somehow depends on
>> > this patch, I'd rather delay it until we have a proper solution.
>> 
>> I think we agreed the idea to have  support > group> objects for its group field was a good idea that should be
>> implemented, but I declined doing this new work as part of this
>> series :-).
> Indeed, that's how I understood it.  However, I also thought that
> addressing this issue in a later series means we can keep the current
> behaviour until that is done.

My focus on this series was making sure the configuration is easy(er) to
reason with and that it works out of the box for the most part.

>> > > Synchronizing both is not practical, as it can easily lead to
>> > > slightly different  objects conflicting, again
>> > > causing problems.
>> > It might not be practical to do so inside the service, but note how
>> > this has already become an effort in defensive programming.  There
>> > are easier ways to not make this a problem on the configuration
>> > level, namely by specifying the same group for both user and group
>> > fields.  As far as I see this is even the default state of being if
>> > the user is supplied as a string.
>> 
>> I really don't like the group information being duplicated in both
>> the user and a distinct field; it's an awkward API that raises more
>> questions than it provides answers, in my opinion (non-intuitive).
> And I agree that it's awkward, but I don't agree that this patch solves
> the underlying issue.

It puts the issue aside; if you can't configure a mismatched group, you
can't shoot yourself in the foot.

>> One of the reasons I came think this way is because a 
>> can differ by being a system group or not, which would make it easy
>> to introduce unexpected, subtle variants.
> Is that a serious issue, though?  Yes, two configuration files, one
> with (system? #t) and one without will produce different results in
> that GIDs are allocated differently, but the same applies to the user
> as well.  The only real issue I can think about here goes back to the
> handling of duplicate accounts and groups; and again, we both agree
> that those ought to be hard errors rather than warnings.

I think it's a serious issue because the permissions configured in the
start slot may be wrong, and the service could fail to run because of
it.

-- 
Thanks,
Maxim

bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Liliana Marie Prikler]

Hi Maxim,

Am Sonntag, dem 07.05.2023 um 14:12 -0400 schrieb Maxim Cournoyer:
> My focus on this series was making sure the configuration is easy(er)
> to reason with and that it works out of the box for the most part.
Obsoleting the group field does imho not significantly ease its use. 
It rather makes its non-ootb use harder, because you now have to edit
two operating-system fields, without changing anything for the ootb
use.

> > > > 
> It puts the issue aside; if you can't configure a mismatched group,
> you can't shoot yourself in the foot.
No, it doesn't: Since it pulls in the groups field into "stuff you need
to worry about when editing your MPD service", it actually exacerbates
the issue.  Yes, the API is awkward, but it does help making mpd-
service-type self-contained.

> > 
> I think it's a serious issue because the permissions configured in
> the start slot may be wrong, and the service could fail to run
> because of it.
What is "it" here: the fact that you can make a group with (system? #f)
or the error in accounts-service-type that has been demoted to a
warning?

Cheers

bug#63178: shepherd 0.10.0-rc1 riscv64 build failure

[Ludovic Courtès]

Hi!

Efraim Flashner  skribis:

> On Sat, May 06, 2023 at 07:59:39PM +0200, Ludovic Courtès wrote:

[...]

>> I believe 7c79df11c7a9d938ed9b48e00c4366da95301d4b fixes a race
>> condition that these tests were showing: ‘herd stop root’ can return
>> before the shepherd process has terminated.
>> 
>> Could you try again?
>> 
>> For AArch64, what machine are you using, with what CPU?  There’s a
>> Guile (?) bug manifesting on the OverDrive 1000 that causes more or
>> less random test failures, unless you set GUILE_JIT_THRESHOLD=-1:
>> 
>>   https://github.com/wingo/fibers/issues/83
>> 
>> Thanks for your help!
>
> The pine64¹ is an allwinner A64 with 4 A53 cores and the pinebook pro²
> uses an RK3399, 4 cores of A53 and 2 cores of A72. I've also picked up 2
> rock64³s using an RK3328 with 4 A53 cores.

OK, thanks.  Could you also check whether the Guile+Fibers snippet at
 works on these machines?

Thanks,
Ludo’.

bug#63082: [PATCH v3 05/16] services: mpd: Obsolete the 'group' field.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler  writes:

> Hi Maxim,
>
> Am Sonntag, dem 07.05.2023 um 14:12 -0400 schrieb Maxim Cournoyer:
>> My focus on this series was making sure the configuration is easy(er)
>> to reason with and that it works out of the box for the most part.
> Obsoleting the group field does imho not significantly ease its use.
> It rather makes its non-ootb use harder, because you now have to edit
> two operating-system fields, without changing anything for the ootb
> use.

If you haven't tried that already, I'd like to give you the following
challenge: with the current MPD service, are you able to configure it so
that it works as your user, touching the minimum amount of configuration
switches (as you'd do if you were a new MPD service user getting
started?).

With this series I opinionated on the side that less is better, coming
from the realization that configuring a working MPD was already quite
the challenge (less after this series, if it succeeds at its goal).  In
my opinion, the main two use cases for configuring the services
user/group probably are:

1. you want to run it as an existing user
2. you want it to run as its own user

The defaults cover 2, while for 1 you don't have a need to configure a
group for it, since an existing user will also already have an existing
group (and the  captures such group).

>> It puts the issue aside; if you can't configure a mismatched group,
>> you can't shoot yourself in the foot.
> No, it doesn't: Since it pulls in the groups field into "stuff you need
> to worry about when editing your MPD service", it actually exacerbates
> the issue.  Yes, the API is awkward, but it does help making mpd-
> service-type self-contained.

The thing is that the 'group' field of mpd-service-type has a default,
which is easy to forget (because it's duplicated from a 
object and you may reasonably expect the service to default to the
specified user-account's group).  But that's not easy to achieve.  I
tried.

>> I think it's a serious issue because the permissions configured in
>> the start slot may be wrong, and the service could fail to run
>> because of it.
> What is "it" here: the fact that you can make a group with (system? #f)
> or the error in accounts-service-type that has been demoted to a
> warning?

I was thinking about the first one, although 2 would have been a nice
sanity check to avoid ending in a strange state where your existing user
is now in a different group that it ought to, for example.

I hope all this text helps furthering our common understanding :-).

-- 
Thanks,
Maxim