Why is greetd greeter user in so many groups?

[kiasoc5]

Hooray, greetd has been merged! [1]

However, according to upstream the greeter user only needs to be in
the video and greeter groups. [2]

Whereas the guix definition for the greeter user has many more groups:

(define %greetd-accounts
  (list (user-account
 (name "greeter")
 (group "wheel")
 (supplementary-groups '("users" "tty" "input" "video"
"audio"))
 (system? #t

I can understand the need for tty and input, but why does the
greeter user need the wheel and audio?

1. https://issues.guix.gnu.org/49969
2. https://git.sr.ht/~kennylevinsen/greetd/#manually-from-source

Re: On commit access, patch review, and remaining healthy

[Hartmut Goebel]

Hi,

here are my reasons for reviewing patches very very rarely-

Basically I share Brian Cully's experiences. I'm using Thunderbird for 
mail and my system is set up to emacs could send out mails.


I tried debbugs from time to time and for me it is disgusting:

 * too complicated to get to the list of patches or bugs ( I never can
   remember the many key-presses to perform) ,
 * I did not manage to apply patches from there (emacs would need to
   know where my guix development directory is - how can I tell it?)
 * commands withing debbugs feel complicated
 * if a ticket contains several updated patches, its very hard to find
   those relevant (one of the reasons of forges' success is that they
   present you the current state)
 * actually testing the patches required to apply the patches to my
   worktree - and chances are high 'git am' will fail with some
   conflict - chances raise extremely for old patches
 * Over all for me debbugs.el needs a much more "noops"-friendly interface

Regarding the actual review:

 * Yes, I miss a review guide-line
 * As Arun wrote: Guix has high quality standards. I feel uncomfortable
   with judging whether a summary or description is good enough. Also
   I'm not a native speaker and don't feel entitled to review English
   gramar and spelling.
 * I miss a way to contribute to a review but not actually approving
   it. (In git(lab,hub) I could add comments other reviewers and the
   submitter could resolve or give feedback. This allows me to focus on
   e.g. some parts, while someone else could review the summary and
   description.)
 * I also miss automated tests. E.g. it dos not make sense to waste my
   time for running 'guix lint', as a automate could do this.

When agreeing to a patch:

 * I'd like to simply merge the patch without taking care abut whether
   the submitter has commit right. This saves time for the submitter.
   Sending "LGTM" is pleasant, anyhow wasting time. The reviewer needs
   to send a mail, the submitter needs to dig the branch, rebase it and
   push. If the reviewer already did merge it, he/she could push, too,
   IMHO.
 * And for me as a submitter: I want my patches to be merged by the
   reviewer.


Am 07.06.22 um 17:11 schrieb Ludovic Courtès:

Do you or would you use them to keep track of pending patches?


I use issues.guix.gnu.org eventually. Anyhow this is browse-only. I did 
not even manage to add a reply there.


--
Regards
Hartmut Goebel

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

Re: On commit access, patch review, and remaining healthy

[Arun Isaac]

>> Also, should we remove old/broken/unused/rarely-used packages from Guix?
>> In the past, I have packaged and contributed very niche packages which
>> probably no one else uses, and sometimes even I don't use anymore. But,
>> these packages continue to stay in Guix and add to the maintenance
>> burden. Should we have some policy to phase out such packages,
>> especially if such packages break often? I mean, that there is no need
>> to phase out an elisp package that builds trivially all the time, but
>> what about more complex packages that take many many hours to maintain?
>
> I think they should be removed. This could link to the maintainer
> comment above. If a package is identified as old or broken, then users
> could be notified, and after a “cooling off” period they are
> removed. This could allow for discussion about whether removal is
> appropriate, or whether someone else would step up and update the
> package. Under Gentoo (the distro I know well, having used it since
> 2004), obsolete and problematic packages are hard masked, and users
> notified why, and when removal from the repository will occur. The
> hard masking prevents new installations (almost - you can make some
> additional configuration changes to enable installation). Users then
> have a choice - support the resolution of the issues leading to hard
> masking, or move the package definition to a personal repository so it
> can continue to be used (at their own risk). Regarding rarely used
> packages - I wouldn’t remove these if there is a maintainer for them
> and they are still being kept up to date. If this no longer happens,
> then they are in the old/broken category.

I like this idea. We already have a way to mark packages as
deprecated. The Gentoo method seems like a way to mark packages that are
"about to be deprecated". I like the way it notifies the user of the
impending deprecation without the user having to subscribe to the
mailing list or the issue tracker.

> I guess the big question for me is “could this be automated in some
> way?”

Indeed, it's all a matter of somebody implementing the tooling! ;-) Like
Ludo mentioned, Cuirass and the Guix data service may be involved in
determining which packages are frequently broken.

>> I don't have strong opinions on these questions. I would love to hear
>> what others think.
>> 
>
> I hope my comments are useful!

Definitely, thanks!

Re: LibreSSL?

[Efraim Flashner]

On Mon, Jun 20, 2022 at 12:17:38AM +0200, Andreas Enge wrote:
> Hello,
> 
> Am Fri, Apr 01, 2022 at 10:41:11AM +0200 schrieb Ludovic Courtès:
> > At first sight, it looks like an easy-to-maintain package: no
> > dependencies, few users, stable API.
> > 
> > I tried to update it to 3.5.1 and was proved wrong though: there’s one
> > test failure in ‘tests/asn1object’ and the Internet doesn’t seem to know
> > how to address the problem.  So it would need a bit more work.
> > 
> > I’d lean towards keeping it and doing that extra work, collectively, but
> > I understand this very discussion shows that it’s debatable.
> 
> at some point in time, my understanding was that we would switch everything
> to libressl and drop openssl. I have not followed, but from
>https://lwn.net/Articles/841664/
> it looks as if the problems with openssl are more or less solved, at least
> they are not worse than in libressl.
> 
> So an option would be to try to switch the existing dependencies to openssl
> and decide from there.
> 
> What do you think?

I thought I had updated it last month but it turns out I never actually
did. My daughter and I looked at fixing acme-client before the staging
merge before we saw it was abandoned, I guess that's when I thought I
updated libressl. I'd be more interested in trying to use openssl-3 than
trying to pull along libressl.

-- 
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

Re: RISCV porting effort

[Pjotr Prins]

Chris Batten created the slides and presented twice. He writes:

We presented our work on using Guix in computer architecture research at the 
gem5 users workshop an
d the Workshop on Computer Architecture Research with RISC-V ... it was awesome 
to have Pjotr join
in person for CARRV too! Pjotr did a great job at CARRV advocating for Guix ... 
people seemed inter
ested. Links to slides:

 - https://www.csl.cornell.edu/~cbatten/pdfs/batten-guix-slides-carrv2022.pdf
 - 
https://www.csl.cornell.edu/~cbatten/pdfs/batten-guix-slides-gem5workshop2022.pdf

Thanks to all of you for all of your help in preparing the two workshop 
presentations. I am looking
 forward to continuing to collaborate on this in the future!


On Sat, Jun 18, 2022 at 12:52:11AM +0200, Pjotr Prins wrote:
> On Fri, Jun 17, 2022 at 06:08:18PM +0200, Ludovic Courtès wrote:
> > And… I think one of you will have to come and present all this work in
> > Paris: .  Who’s in?  :-)
> 
> We should all show up :) 
>