Re: Guix CLI options through manifest.scm or guix.scm

[Distopico]

On 2023-09-14, Ludovic Courtès  wrote:

> Hi,
>
> Distopico  skribis:
>
>> Is it possible to define/express CLI options from manifest.scm or
>> guix.scm? For example, I have
>>
>> ```
>> guix shell \
>>  -m manifest.scm \
>>  --container -F -N -P \
>>  --share=/opt/android-sdk \
>>  --share=$HOME/.android/avd \
>>  --share=$HOME/.gradle/ \
>>  --preserve='^DISPLAY$' \
>>  --preserve='^XAUTHORITY$' \
>>  --preserve='^DBUS_' \
>>  --expose=$XAUTHORITY \
>>  --expose=/var/run/dbus
>> ```
>
> There are two things relevant to ‘guix shell’: (1) what packages go
> inside the environment, and (2) how the environment is built (container
> vs. pure, networking or not, etc.).
>
> The manifest only takes care of #1.
>
> We need a non-CLI way to express #2.  I don’t think manifests are a good
> fit for that; perhaps we need a new  abstraction, which
> might mean we need a new ‘environment.scm’ file or similar.
>
> Anyhow, I agree that something’s missing here.
>
> Thanks,
> Ludo’.

Aren't there many variations/types of files? But still, it would be
ideal to configure it. Perhaps 'envrc.scm' could be another option.

Best!


signature.asc
Description: PGP signature

Re: Thank you for using Emacs

[kiasoc5]

On 2023-09-18 16:45, MSavoritias wrote:
And for guile specifically to offer guile-studio instead of plain 
Emacs.


Speaking of guile studio:

- The homepage for the package is Guile's homepage, not guile-studio's 
(https://git.elephly.net/software/guile-studio)
- There is no mention of Guile studio anywhere in the Guix manual or 
cookbook


So, the visibility of Guile Studio is rather low. Indeed, I only found 
it while searching for Guile libraries, not for Emacs specifically.


It would be nice to put this Emacs starter kit front-and-center, at 
least in the Guix manual. Perhaps the Guile project could make it the 
official IDE? :D

[PATCH qa-frontpage] Apply incoming patches onto the correct feature branch

[Vivien Kraus]

It seems that the only available information of the feature branch is
in the patch name.
---

Hello guix!

Thank you for making the QA tool. It seems to me that feature branches
are ignored for patches. The patches seem to always be applied on top
of master. I get that idea because the base-for-issue-* tag is always
put on HEAD, and all my patches targetting gnome-team recently get
applied to master. I understand that the latter could be a problem
with me.

If patches are indeed applied on top of master, then the question
arises, what to do. The available information from patchwork is
scarce: the base-commit is not available, and the optional feature
branch only appears in the name of the patches of the series.

I think it is possible to parse the patch names. This way, we get some
useful information: the feature branch, the series revision, and the
patch index. The patch index can be used to make sure the patches are
in correct order (this can be the case if a server in the path
re-orders the emails).

What do you think?

Best regards,

Vivien

 guix-qa-frontpage/manage-patch-branches.scm | 80 +++--
 1 file changed, 76 insertions(+), 4 deletions(-)

diff --git a/guix-qa-frontpage/manage-patch-branches.scm 
b/guix-qa-frontpage/manage-patch-branches.scm
index 7f3adb1..0512680 100644
--- a/guix-qa-frontpage/manage-patch-branches.scm
+++ b/guix-qa-frontpage/manage-patch-branches.scm
@@ -102,6 +102,55 @@
 (close-pipe pipe)
 result))
 
+(define (parse-patch-name name)
+  (let ((args
+ (and
+  (string-prefix? "[" name)
+  (let ((stop (string-index name #\])))
+(substring name 1 stop
+(as-bug-number
+ (lambda (arg)
+   (and (string-prefix? "bug#" arg)
+(string->number (substring arg (string-length "bug#"))
+(as-v2
+ (lambda (arg)
+   (and (string-prefix? "v" arg)
+(string->number (substring arg 1)
+(as-patch-number
+ (lambda (arg)
+   (match (string-split arg #\/)
+ (((= string->number index) (= string->number total))
+  (and index total (<= index total)
+   (cons index total)))
+ (else #f)
+(let analyze ((bug-number #f)
+  (branch "master")
+  (version 1)
+  (index 1)
+  (total 1)
+  (arguments
+   (if args
+   (string-split args #\,)
+   '(
+  (match arguments
+((or ("") ())
+ `((bug-number . ,bug-number)
+   (branch . ,branch)
+   (version . ,version)
+   (index . ,index)
+   (total . ,total)))
+(((= as-bug-number (? number? new-bug-number))
+  arguments ...)
+ (analyze new-bug-number branch version index total arguments))
+(((= as-v2 (? number? new-version))
+  arguments ...)
+ (analyze bug-number branch new-version index total arguments))
+(((= as-patch-number ((? number? new-index) . (? number? new-total)))
+  arguments ...)
+ (analyze bug-number branch version new-index new-total arguments))
+((feature-branch arguments ...)
+ (analyze bug-number feature-branch version index total arguments))
+
 (define (create-branch-for-issue issue-number patchwork-series)
   (define (apply-patches)
 (let ((series-data
@@ -116,9 +165,32 @@
(json->scm body)
 
   (if (assoc-ref series-data "received_all")
-  (let* ((patch-data
-  (vector->list
-   (assoc-ref series-data "patches")))
+  (let* ((annotated-patch-data
+  (map
+   (lambda (patch)
+ (let ((name (assoc-ref patch "name")))
+   `((patch . ,patch)
+ (metadata . ,(parse-patch-name name)
+   (vector->list
+(assoc-ref series-data "patches"
+ (patch-data
+  (map
+   (lambda (annotated)
+ (assq-ref annotated 'patch))
+   (stable-sort
+annotated-patch-data
+(lambda (a b)
+  (let ((a-meta (assq-ref a 'metadata))
+(b-meta (assq-ref b 'metadata)))
+(< (assq-ref a-meta 'index)
+   (assq-ref b-meta 'index)))
+ (feature-branch
+  (match annotated-patch-data
+((p rest ...)
+ (let ((meta (assq-ref p 'metadata)))
+   (if meta
+   (assq-ref meta 'branch)
+   "master")
  (branch-name
   (simple-format #f "issue-~A" issue-number))
  (base-tag
@@ -127,7 

Re: How can we decrease the cognitive overhead for contributors?

[Development of GNU Guix and the GNU System distribution.]

Hi Simon,

On Mon, Sep 18 2023, Simon Tournier wrote:
>
> To be clear, I dismiss only these two sentences:

Having read your message from earlier today [1] in which I think you
questioned the continued utility of this thread ("could we stop this
useless and unproductive flamewar?") it seems fair to say that this
communication has now reached a logical end.

Participants are arguing over what they are arguing about.

Let's build something cool today. Thanks for everyone's work on Guix!

Kind regards
Felix

[1] https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00430.html

Re: How can we decrease the cognitive overhead for contributors?

[Liliana Marie Prikler]

Am Montag, dem 18.09.2023 um 20:39 +0300 schrieb MSavoritias:
> 
> On 9/18/23 20:13, Simon Tournier wrote:
> > On Mon, 18 Sept 2023 at 18:35, MSavoritias 
> > wrote:
> > 
> > > I was talking from my experience. If you don't share it that is
> > > fine.
> > Share what?  Your experience?  How can I?  Instead, I share facts
> > backed by numbers.
> > 
> > It is fine to share how you perceive, encouraged even!  It is not
> > fine to make bold claim based on nothing more than a very
> > subjective view point.
> 
> Please take a step back. You cannot dismiss my experience.
> 
> As I have said and other people in this thread, and as I said i also 
> engage with people in social networks, and I am talking from that
> experience.
I think it is fair to say that experiences are subjective and
potentially misleading (and in the case of social media typically
subject to the bias induced by filter bubbles).  Now, the same
similarly applies to facts and statistics when given the wrong
interpretation, but first things first, we have to be aware of those
sources of bias and then work with them.  In this case it means not
making hasty claims on contributor count based on what you've heard in
social media.


Am Montag, dem 18.09.2023 um 11:37 +0200 schrieb Simon Tournier:
> Please point one project where:
> 
>   + more than 900 people have contributed to the project,
>   + more than 100 people had or have write access in the repository.
Some more data points captured by the same means you used, make of them
what you will:

Emacs: 1440/470
GCC: 2468/908
Nixpkgs: 7283/6339
Rust: 5657/5460
NPM (just the cli): 896/53
guixrus: 31/4

(As we can see, the pull request model hides how many people actually
have write access in some instances.)

What's not shown in these data points obviously are recent
contributions and active committers – we've had them posted at some
point, but that's old data by now.

Quite interestingly, Emacs and GCC both appear to have a 3:1 ratio of
contributors to committers despite using the same email-based workflow.
Perhaps that's due to age, or maybe it's a sign that we are too slow to
accept help? 

> The thing is nobody talked about email vs web forge to my knowledge
> though.
The thing is every discussion à la "maybe we should improve our
workflow somehow" eventually devolves into exactly this.  I have seen
my fair share of such discussions already in the short time I've spent
contributing to Guix.  The best that has so far come from it was people
spinning of their own channels (and even then, the use of another forge
appears almost incidental at times; our vetting process has similarly
been criticized for its perceived inefficiencies).

Now, I'd like to call back to a point I made earlier:

Am Dienstag, dem 05.09.2023 um 22:43 +0200 schrieb Liliana Marie
Prikler:
> Maybe it's time to take a step back and instead of asking “How can we
> decrease the cognitive overhead for contributors?”, we should perhaps
> ask “For which contributors do we want to/can we decrease the
> cognitive overhead?”
You can quite easily work around this issue by maintaining a
comparatively small channel for some thirty people.  However, you do
now have the cognitive overhead of being one of its four maintainers
while also trying to feed back whatever code has actually matured well
upstream to ease your own maintenance burden.  If that's the tradeoff
you want to make, then by all means, go for it.

> One of the solution offered was to have *also* a web interface. It
> was never suggested any comparison.
> 
> The comparison seemed to have stemmed from some people feeling they 
> would be left behind (?) and wanting to prove that email is better or
> something. Personally i don't care what is better.
I think you are underestimating the community splitting effects that
offering different *blessed* frontends has.  We are not talking about
your personal choice of a mail user agent here, because there's nothing
to bless; you simply take whatever is comfortable to you.  For blessed
web frontends OTOH, just offering two different representations of the
same data can already lead to problems, e.g. different bugs being
reported by the mumi vs. old school debbugs crowd.  This is also part
of the reason why large organizations tend to centralize their stuff in
one platform, which most forges make stupidly simple.  Even if they
could cater to different groups simultaneously, *they just don't care*.

Now Guix is already a little special in that it offers like three views
into this big pile of bug reports and patches (plus a fourth one if you
count yhetil).  If you're going to add yet another interface, you have
to consider maintenance (as Andreas pointed out early on) and possibly
different styles of etiquette encouraged by such interfaces (as I
pointed out soon after) or possibly other road bumps.  

Cheers

Re: How can we decrease the cognitive overhead for contributors?

[Simon Tournier]

Hi,

On Mon, 18 Sept 2023 at 19:40, MSavoritias  wrote:

> As i said its okay if you don't understand it, or share it. What you can
> not do is dismiss my experience.

I do not dismiss your experience.  To the contrary.  It is because I
do not share other experiences that I am interested by learning them.
I think some of the points your are raising here or there are very
valuable, and whatever if I fully share them or not.  They are
valuable and it is important that you express them.  Period. :-)

To be clear, I dismiss only these two sentences [1]:

And the fact that guix doesn't get have many
committers and contributors are scarce, speaks for itself. If you don't
see it I suggest asking people in social networks/forums why they
*don't* get involved in guix.

Because here you do not speak about your personal experience; you are
reporting two statements which are IMHO not backed and thus they drag
down.  You draw a general conclusion extrapolated from your subjective
viewpoint.

Do not take me wrong, your viewpoint is valuable.  As important as any
other subjective viewpoint.  And for what it is worth, I read (almost)
all viewpoints with interest.  It is important that we all share them.

I do not feel personally attacked.  You, do you feel personally
attacked?   If yes, I am sorry for my tone because it was not my
intent.  I think it is important 1. to focus on positive actionable
items and 2. avoid slippery slope leading to negativity.

Well, instead of these two claims, it appears to me more engaging to ask:

 + considering Guix is 10 years old, how many new contributors does
the project get per month?  On average.
 + how many contributors contribute more than X times?
 + how many people roam on other media than Guix mailing list?
 + etc.

IMHO, by these questions, you are sharing your experience, your
perspective and your viewpoint without jumping to some partial
conclusion; even we could maybe reach together or infer some
interesting conclusions.  Somehow, these questions would drag up and
engage potentially fruitful discussions.  Maybe, that's what you
wanted to express?

Anyway.  That's how I view the things from my perspective.

It is my last email in this thread too.

Cheers,
simon


1: Re: How can we decrease the cognitive overhead for contributors?
MSavoritias 
Sun, 17 Sep 2023 19:20:48 +0300
id:f199249e-b30a-adf5-224f-1aed74a56...@fannys.me
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/f199249e-b30a-adf5-224f-1aed74a56...@fannys.me

Re: Implementing the guix-dameon in Guile

[Thompson, David]

Hey Christopher and Ludovic,

First, congrats on the NLnet funding! I've wanted to see this project
happen for years so I'm excited to see it finally happening.

On Thu, Sep 14, 2023 at 9:30 AM Ludovic Courtès  wrote:
>
> Hi Christopher,
>
> Christopher Baines  skribis:
>
> > My plan is to focus on this over the next year. I left my previous day
> > job quite a few months ago now to take a bit of a break, that's the main
> > reason I've been able to spend more time trying to push forward some of
> > the QA stuff. With some monetary support from NLNet [2], I'm planning to
> > continue this break and focus for the next year on getting a Guile
> > implementation of the guix-daemon written and adopted.
> >
> > 2: https://nlnet.nl/project/GuixDaemon-Guile/
>
> Yay, this is great news!! But also: thank you for your long-term
> commitment, it’s an invaluable contribution to the project.
>
> ...
>
> I imagine the daemon could be structured as a set of actors (it’s really
> my thing these days ;-)), with an eye on facilitating code sharing and
> interaction with the Coordinator, Cuirass, and all that.

Sounds like an excellent idea to us Spritely folks, too! :)

Christopher, if you ever need help with actor model related things,
come talk to us in #spritely on libera.chat.

- Dave

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/18/23 20:13, Simon Tournier wrote:

On Mon, 18 Sept 2023 at 18:35, MSavoritias  wrote:


I was talking from my experience. If you don't share it that is fine.

Share what?  Your experience?  How can I?  Instead, I share facts
backed by numbers.

It is fine to share how you perceive, encouraged even!  It is not fine
to make bold claim based on nothing more than a very subjective view
point.


Please take a step back. You cannot dismiss my experience.

As I have said and other people in this thread, and as I said i also 
engage with people in social networks,


and I am talking from that experience.


As i said its okay if you don't understand it, or share it. What you can 
not do is dismiss my experience.


It is not attack on you personally what i have said it is meant as how I 
view things from my perspective that is all.



Consider this my last email in this thread.


MSavoritias.

Re: How can we decrease the cognitive overhead for contributors?

[Simon Tournier]

On Mon, 18 Sept 2023 at 18:35, MSavoritias  wrote:

> I was talking from my experience. If you don't share it that is fine.

Share what?  Your experience?  How can I?  Instead, I share facts
backed by numbers.

It is fine to share how you perceive, encouraged even!  It is not fine
to make bold claim based on nothing more than a very subjective view
point.

Re: Cross compilation status

[Liliana Marie Prikler]

Am Montag, dem 18.09.2023 um 17:17 +0300 schrieb Efraim Flashner:
> On Sun, Sep 10, 2023 at 04:59:35PM +0200, Liliana Marie Prikler
> wrote:
> > Hi Mathieu,
> > 
> > Am Sonntag, dem 10.09.2023 um 11:14 +0200 schrieb Mathieu Othacehe:
> > > I have CC'ed members of the python, java, ruby, rust, r, haskell
> > > and
> > > emacs teams. Any plans adding cross-compilation support to your
> > > build-system, barriers to overcome?
> > For Emacs, there are layers of problems.  First things first, we
> > are only doing byte compilation atm, which may or may not be
> > arch-dependant based on stuff like endianness.  For native
> > compilation, there is the thing that even a slightly differently
> > configured emacs won't load the packages you've just compiled
> > without compiling it natively on its own.
> > Granted, if we want to do cross-compilation, having just the
> > bytecode might already be "good enough", but I wanted to throw this
> > out there.
> > 
> > I think we'd need some support from Emacs proper before we can
> > start implementing cross builds.
> 
> I will note that the only big-endian architecture which we "support"
> is 32-bit powerpc, so we don't have to worry that much about wrong
> endianness.
Fine, let's add word size to point out the obvious :)

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/14/23 11:24, Ricardo Wurmus wrote:

Fannys  writes:


But again, even if this is a great option for you, it might be a really bad
option for some other people. Everybody does not have the time to spend
learning emacs, or other specific tool. It's ok if the workflow suggests that
but it's not great if we have no other alternative.

It's not accessible and imposes a barrier in some people.

Yeah agreed. And we should be consious of that.
Ironically by mandating Emacs and Email we force people to use specific
tools while at the same time even though the same people will complain(!) 
against vendor lock-in
like github.

We don’t *mandate* the use of Emacs.  It’s just a common recommendation
because it works so well with text and is trivially extensible, so it’s
a common target for helper tools.  Surely we also wouldn’t call a
recommendation to use a shell script “vendor lock-in” just because it
needs Bash.

Emacs works well with text, and text is all that’s needed in a
patch-based workflow, which is in fact vendor agnostic.

Of course this doesn’t mean that it is as accessible as we’d want.

Well as it was pointed out when it is the only thing that is mentioned 
in the manual and all the tooling is based around it, it might as well 
be mandated.


If it works only in Bash it pretty much is "vendor lock-in" yes.

I have mentioned in other email so I won't repeat myself here, plain 
Emacs is not really accessible for a person that wants to start messing 
around with guix or guile.



MSavoritias

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/18/23 12:37, Simon Tournier wrote:

Hi,

On Sun, 17 Sep 2023 at 19:20, MSavoritias  wrote:


Including an committer. And the fact that guix doesn't get have many
committers and contributors are scarce, speaks for itself. If you don't
see it I suggest asking people in social networks/forums why they
*don't* get involved in guix.

--8<---cut here---start->8---
$ git shortlog -sn --all | wc -l
952

$ git log --format="%ce" | sort | uniq -c | wc -l
104
--8<---cut here---end--->8---

Please point one project where:

   + more than 900 people have contributed to the project,
   + more than 100 people had or have write access in the repository.

It is fine to discuss how to improve and what we could do better.  It is
incorrect to say “guix doesn't get have many committers and
contributors” and it is not fine to frame it negatively.

I was talking from my experience. If you don't share it that is fine.

For example Debian moved to Gitlab. Same for gnome and kde.

As I pointed in my very first reply [1] in this thread:

 For instance, Debian is based on Gitlab since their switch from Alioth
 to Salsa.  It would be interesting to know if this “new” web-based
 workflow using Merge Request is increasing the number of submissions
 and/or increasing the number of occasional contributors.

As far as I have read all this thread, no one provides numbers.  The
answer by Vagrant (Debian Developer and Guix contributor) appears to me
interesting [2].  Therefore, could we stop this useless and unproductive
flamewar?  Many Guix channels are hosted on Gitlab, Github or Sourcehut
and they are not receiving so much more contributions.  As Katherine
pointed [3],


Regarding the many contributions it has to do also with a lot of other 
stuff. Obviously a web interface wouldn't


solve everything. And i hope it never seemed I said otherwise.



 I know everyone is focusing on email vs. web-forge, but I am trying to
 draw attention to the root causes of the complexity, and enumerating
 possible solutions to these.

and I think that kind of mindset is very helpful; it is engaging.  Well,
to my approximate recollection, there is a talk at each DebConf about
reflecting on newcomers backed by some stats; e.g., [4].  In summary,
“email vs. web-forge” is a fake-problem, IMHO.  Last, the talk [5] by
Enrico Zini appears to me much more fruitful.  The question is about
sustain the community.  And this sustainability does not clearly depend
on any tool.


The thing is nobody talked about email vs web forge to my knowledge though.

What was pointed out was specifically cognitive overhead and how we can 
reduce that.


One of the solution offered was to have *also* a web interface. It was 
never suggested any comparison.


The comparison seemed to have stemmed from some people feeling they 
would be left behind (?) and wanting to


prove that email is better or something. Personally i don't care what is 
better.


What i care is that some people prefer web-based so we should 
accommodate them :) plain and simple.



MSavoritias


Cheers,
simon


1: Re: How can we decrease the cognitive overhead for contributors?
Simon Tournier 
Thu, 24 Aug 2023 20:53:14 +0200
id:871qfsuvad@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-08
https://yhetil.org/guix/871qfsuvad@gmail.com

2: Re: How can we decrease the cognitive overhead for contributors?
Vagrant Cascadian 
Sat, 02 Sep 2023 18:05:40 -0700
id:87wmx8m5gb.fsf@wireframe
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/87wmx8m5gb.fsf@wireframe

3: Re: How can we decrease the cognitive overhead for contributors?
Katherine Cox-Buday 
Tue, 05 Sep 2023 13:15:48 -0600
id:13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com

4: https://debconf23.debconf.org/talks/32-teams-newcomers-and-numbers/
5: https://debconf23.debconf.org/talks/2-adulting/

Notmuch, Debbugs: my helpers (was Re: New section to easily reference Debbugs URLs within Emacs Debbugs)

[Simon Tournier]

Hi,

On Sun, 17 Sep 2023 at 16:51, Maxim Cournoyer  wrote:

> If you use Emacs and Emacs-Debbugs, you may be interested in applying
> the settings newly documented in the 'Viewing Bugs within Emacs' section
> of the manual; see it at the bottom of info "(guix) The Perfect Setup").

Oh, cool!

On Saturday, I discovered ’honey-apple’ on IRC and today I was planning
to improve my setup.  Perfect timing! :-)

BTW, let me share some of my helpers.  They are quite simple but it
helps me.  Maybe it could be useful to others.  Well, I read my emails
using Emacs-Notmuch but I guess this should be adaptable for Gnus or
mu4e.

Since I often lag behind, I often have patches in my inbox where I have
been CC.  I try to keep focused on by an easy triage, so I quickly want
to know if this patch is still open or if it is already marked as done.
Before opening, or while reading, I just press ’C’ and it queries
Debbugs (SOAP) and displays the current status.

Similarly, sometimes old but still open bug pops up.  It is a reply or
just a ping and because it is old, I do not necessary have the context.
I just press ’b’ and it opens Emacs-Debbugs for the issue at hand.  If
there is many messages (that I do not have locally) and say it will need
some time to read them, and say I am often reading offline, well I just
press ’I’ and it downloads all the thread and injects it in my Guix
email folder (and also indexed by notmuch :-)).

Last, when reading from Debbugs, I press ’R’ for replying.  I like to
have https://issues.guix.gnu.org/issue/N at hand so pressing ’R’
stashes this URL specific to the issue and ready to be pasted.

Below the config. :-)

--8<---cut here---start->8---
  (defun my/notmuch-show-get-debbugs ()
"Extract Debbugs number.

>From an email message, it exracts the number  as in
n...@debbugs.gnu.org from the fields From/To/CC and it returns a
list of integers.

If in `notmuch-search-mode', then the returns is nil, so let try
to extract from the email subject assuming the pattern bug#."
(let* ((all-mails (seq-reduce
   (lambda (r f)
 (let ((s (funcall f)))
   (if s
   (append r (split-string s "," t))
 r)))
   (list 'notmuch-show-get-from
 'notmuch-show-get-to
 'notmuch-show-get-cc)
   nil))
   (debbugs (seq-filter
 (lambda (x) (string-match-p (regexp-quote 
"@debbugs.gnu.org") x))
 all-mails))
   (numbers (remq nil
  (mapcar
   (lambda (x)
 (let ((n (when (string-match 
"\\([0-9]+\\)@debbugs.gnu.org" x)
(match-string 1 x)))
   (d (when (string-match 
"\\([0-9]+\\)-d...@debbugs.gnu.org" x)
(match-string 1 x)))
   (c (when (string-match 
"\\([0-9]+\\)-cl...@debbugs.gnu.org" x)
(match-string 1 x)))
   )
   (or n d c)))
   debbugs
  (or
   (mapcar 'string-to-number numbers)
   ;; Let extract from the subject
   (let* ((subject (notmuch-search-find-subject))
  (n (when (and subject
(string-match ".*bug#\\([0-9]+\\).*" subject))
   (match-string 1 subject
 (when n
   (list (string-to-number n

  (defun my/notmuch-debbugs-check ()
"Send request to Debbugs instance about pending status and report."
(interactive)
(let* ((number (car (my/notmuch-show-get-debbugs)))
   (meta (if number
 (car (debbugs-get-status number))
   (user-error "Notmuch: no @debbugs.gnu.org")))
   (status (debbugs-get-attribute meta 'pending))
   (listify #'(lambda (bug attr)
  (let ((some (debbugs-get-attribute bug attr)))
(if (listp some)
some
  (list some)
   (infos (or (sort (append
 (funcall listify meta 'tags)
 (funcall listify meta 'severity))
'string<)
  "")))
  (message "Status bug#%d: %s %s" number status infos)))

  (define-key notmuch-tree-mode-map (kbd "C")
'my/notmuch-debbugs-check)
  (define-key notmuch-search-mode-map (kbd "C")
'my/notmuch-debbugs-check)
  (define-key notmuch-show-mode-map (kbd "C")
#'(lambda ()
;; : For some reason, without wrapping with
;; (lambda () (interactive) ...)
;; it returns: Wrong type argument: commandp

Re: How can we decrease the cognitive overhead for contributors?

[Simon Tournier]

Hi,

On Sun, 17 Sep 2023 at 14:29, MSavoritias  wrote:

> The reason I have come to guix is because it strives to actually make it 
> easier for people to change things. with guix shell and such. So making 
> it easier for people to contribute is absolutely a part of it. Im not 
> saying we should force every volunteer of course to do "work". What I am 
> saying is:

Sorry if I misread you.  From my understanding you are mixing unrelated
things.  As I have tried to explain elsewhere in this thread, there is a
range of contributions.  Somehow, we can divide them in 4 categories:

0. Use Guix (and potentially report bugs :-))
1. Extend Guix for your own needs
2. Submit your modifications
3. Merge some modifications

Here, you start to speak about #0 and #1 and then you splice to #2.

I agree, it is a whole as the “free software” definition:

0. The freedom to run the program as you wish, for any purpose.
1. The freedom to change it so it does your computing as you wish.
2. The freedom to redistribute copies so you can help others.
3. The freedom to distribute copies of your modified versions to others.

However, to stay actionable, we need to keep in mind the 4 levels.  And
we need to recognize and identify for each level what is good, smooth,
easy and what is harder, unexpected or worse blocker.

Else, we are in some vacuum of abstract and we are locked in rants
without some engaging path forward.

That’s said, let me point that people are already engaging for improving
the accessibility of editors other than Emacs.  For instance, Vim [1] or
VSCode [2].  The frame is not “what we should do” but “let me show you
what I have”, IMHO.  Well, you are free to join the fun! :-)

1: https://10years.guix.gnu.org/video/using-vim-for-guix-development/
2: 
https://videos.univ-grenoble-alpes.fr/video/26660-cafe_guix_vscode_comme_outil_deditionmp4/

Cheers,
simon

Re: How can we decrease the cognitive overhead for contributors?

[Simon Tournier]

Hi,

On Sun, 17 Sep 2023 at 19:20, MSavoritias  wrote:

> Including an committer. And the fact that guix doesn't get have many 
> committers and contributors are scarce, speaks for itself. If you don't 
> see it I suggest asking people in social networks/forums why they 
> *don't* get involved in guix.

--8<---cut here---start->8---
$ git shortlog -sn --all | wc -l
952

$ git log --format="%ce" | sort | uniq -c | wc -l
104
--8<---cut here---end--->8---

Please point one project where:

  + more than 900 people have contributed to the project,
  + more than 100 people had or have write access in the repository.

It is fine to discuss how to improve and what we could do better.  It is
incorrect to say “guix doesn't get have many committers and
contributors” and it is not fine to frame it negatively.

> For example Debian moved to Gitlab. Same for gnome and kde.

As I pointed in my very first reply [1] in this thread:

For instance, Debian is based on Gitlab since their switch from Alioth
to Salsa.  It would be interesting to know if this “new” web-based
workflow using Merge Request is increasing the number of submissions
and/or increasing the number of occasional contributors.

As far as I have read all this thread, no one provides numbers.  The
answer by Vagrant (Debian Developer and Guix contributor) appears to me
interesting [2].  Therefore, could we stop this useless and unproductive
flamewar?  Many Guix channels are hosted on Gitlab, Github or Sourcehut
and they are not receiving so much more contributions.  As Katherine
pointed [3],

I know everyone is focusing on email vs. web-forge, but I am trying to 
draw attention to the root causes of the complexity, and enumerating 
possible solutions to these.

and I think that kind of mindset is very helpful; it is engaging.  Well,
to my approximate recollection, there is a talk at each DebConf about
reflecting on newcomers backed by some stats; e.g., [4].  In summary,
“email vs. web-forge” is a fake-problem, IMHO.  Last, the talk [5] by
Enrico Zini appears to me much more fruitful.  The question is about
sustain the community.  And this sustainability does not clearly depend
on any tool.


Cheers,
simon


1: Re: How can we decrease the cognitive overhead for contributors?
Simon Tournier 
Thu, 24 Aug 2023 20:53:14 +0200
id:871qfsuvad@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-08
https://yhetil.org/guix/871qfsuvad@gmail.com

2: Re: How can we decrease the cognitive overhead for contributors?
Vagrant Cascadian 
Sat, 02 Sep 2023 18:05:40 -0700
id:87wmx8m5gb.fsf@wireframe
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/87wmx8m5gb.fsf@wireframe

3: Re: How can we decrease the cognitive overhead for contributors?
Katherine Cox-Buday 
Tue, 05 Sep 2023 13:15:48 -0600
id:13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com

4: https://debconf23.debconf.org/talks/32-teams-newcomers-and-numbers/
5: https://debconf23.debconf.org/talks/2-adulting/

Re: [fr] Moment de convivialité Guix@Paris en septembre

[Simon Tournier]

salut Tanguy,

On Thu, 14 Sep 2023 at 18:06, Tanguy LE CARROUR  wrote:

> Ce jeudi 28 septembre à 19h, se tiendra la première édition de Guix@Paris
> ouverte au public.

Chouette !  Je serai là.

à tantôt,
simon

Re: Guix Days and Fosdem 2024

[Simon Tournier]

Hi Manolis,

On Sun, 17 Sep 2023 at 17:42, Manolis Ragkousis  wrote:

> It's that time of the year again. We should start preparing for the Guix 
> Days 2024 and a Declarative and Minimalistic Computing devroom proposal.

Cool!

> I have created the pages at [1] devroom proposal and [2] Guix days. I 
> copy pasted the text from last year and updated the year.

I have cleaned a bit – remove past irrelevant information – the page of
Guix Days. :-)

Hope to see you!

Cheers,
simon


[2] https://libreplanet.org/wiki/Group:Guix/FOSDEM2024

Re: Thank you for using Emacs

[Peter Polidoro]

MSavoritias  writes:


What i meant more was:

- Offer an alternative to Emacs.

- Specify a distro like doom Emacs that comes with better 
defaults.


I would maybe lean towards the second one i here fyi. I agree it 
would be nice

to introduce people to lisp modifiable editors :D


I would lean towards the first option of adding a totally 
different alternative to Emacs, the simpler the better.


Introducing anyone to Emacs for the first time, Doom, vanilla, or 
otherwise, in the manual is just going down a rabbit hole of 
raising more questions than it answers.


I really appreciate that Emacs documentation is in the manual for 
those who already use it, but there must be way easier free 
software options out there.

Re: Thank you for using Emacs

[MSavoritias]

On 9/18/23 16:10, Peter Polidoro wrote:


MSavoritias  writes:

I go to the manual to learn package management, 
https://guix.gnu.org/en/manual/devel/en/guix.html#Package-Management


Apparently i have to either use the terminal or something called 
emacs. If I follow the guide located here: 
https://emacs-guix.gitlab.io/website/manual/latest/emacs-guix.html#Installation


It says to install emacs-guix. Okay. So apparently it is an Emacs 
thing, whatever that means. And when you start Emacs after installing 
the package, you are going to end up with Emacs in its plain form. 
Unfamiliar keybindings, no autocomplete, etc. Well thats no to Emacs 
then. The other thing is the terminal apparently. Horrible, but at 
least it works.


You make a very good point, being exposed to Emacs for the very first 
time in this way would be a terrible experience and listing 
alternative options would be very beneficial.


However, I would just like to say "Thank you!" to everyone here for 
using Emacs in the manual.


For my entire career in hardware engineering, I have felt like an 
outcast for using Emacs and being passionate about free software. When 
everyone else on a team or in a company or organization uses 
proprietary software only, it is very isolating and career limiting to 
stay committed to the free software and hardware movements.


So while you may not win any popularity contests by using Emacs in the 
manual, just know that it is very much appreciated by some of us.


Its not Emacs per se. Its more like vanilla Emacs. I very much like 
Emacs. The idea of it at least.


What i meant more was:

- Offer an alternative to Emacs.

- Specify a distro like doom Emacs that comes with better defaults.

I would maybe lean towards the second one i here fyi. I agree it would 
be nice to introduce people to lisp modifiable editors :D


And for guile specifically to offer guile-studio instead of plain Emacs.


MSavoritias

Re: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Simon Tournier]

Hi Ludo,

On Mon, 18 Sept 2023 at 15:56, Ludovic Courtès  wrote:

> Anyhow, how about this plan:
>
>   1. Merge  with the hard Git
>  dependency.

Is #65866 fixing bug#63331 (Guile-GnuTLS/Git circular dependency) [1]?

Does the merge of #65866 lead to close #63331?  Because you wrote,

This patch series is a first step towards getting Git out of
derivation graphs when it’s only used to fetch source code
(origins with ‘git-fetch’), with the goal of fixing:

so...

>   2. When libgit2 1.7 with shallow clones is available in Guix, work on
>  a patch to use Guile-Git for clones and evaluate it.

...we could also suggest to continue and have a complete fix of #63331
before merging #65866.  It avoids to introduce a hard dependency which
will be difficult to remove and let the time for this evaluation of
libgit-2.1.7, no?

For what my opinion is worth, I have nothing for introducing a hard
dependency to Git but we have to be clear that 1. once introduced it
will hard to remove, 2. we will merge patches using faster Git
plumbing equivalent implementation and so 3. it will push out
Guile-Git.


> As I wrote, as an example, I don’t think that there could be a practical
> implementation of (guix git-authenticate) shelling out to ‘git’.

[...]

> PS: I don’t buy the “libgit2 will disappear from Guix” argument because
> it’s not a natural phenomenon that we’re observing but a willful
> construction.

As I wrote elsewhere, Git-Annex (or Magit) are shelling out to 'git',
IIRC.  Well, personally I do not consider that Git-Annex is slow or
that Git-Annex does not implement features as complex as (guix
git-authenticate).

After reading [2],

 I cannot imagine a viable implementation of things like ‘commit-closure’
 and ‘commit-relation’ from (guix git) done by shelling out to ‘git’.
 I’m quite confident this would be slow and brittle.

wolf came 3 days later [3] with a first rough implementation for
'commit-relation' using Git plumbing which is much more faster than
the one implemented with Guile-Git.  Even, speaking specifically about
'commit-relation', I challenge whoever to beat "git merge-base
--is-ancestor"; life is risky: I bet my round of beers in Brussels in
the next Guix Days. :-)  Reading the C implementation of
"merge-base.c" [4] and following the various procedures, it appears to
me impossible to beat it; bah using Guile-Git cumulates various
penalties from talking to libgit2 to the Garbage Collector of Guile.

The question does not appear to me if you buy it or not. :-)  The
question is instead: do we merge code that uses Git plumbing shelling
out that is faster than the current implementation using Guile-Git?

Cheers,
simon

1: https://issues.guix.gnu.org/issue/63331

2: bug#65720: Guile-Git-managed checkouts grow way too much
Ludovic Courtès 
Fri, 08 Sep 2023 19:08:05 +0200
id:87pm2s385m@gnu.org
https://issues.guix.gnu.org//65720
https://issues.guix.gnu.org/msgid/87pm2s385m@gnu.org
https://yhetil.org/guix/87pm2s385m@gnu.org

3: bug#65720: Guile-Git-managed checkouts grow way too much
wolf 
Mon, 11 Sep 2023 16:42:59 +0200
id:ZP8nc1m8rN_34XV-@ws
https://issues.guix.gnu.org//65720
https://issues.guix.gnu.org/msgid/ZP8nc1m8rN_34XV-@ws
https://yhetil.org/guix/ZP8nc1m8rN_34XV-@ws

4: 
https://github.com/git/git/blob/bda494f4043963b9ec9a1ecd4b19b7d1cd9a0518/builtin/merge-base.c#L103-L115

Re: Cross compilation status

[Efraim Flashner]

On Sun, Sep 10, 2023 at 04:59:35PM +0200, Liliana Marie Prikler wrote:
> Hi Mathieu,
> 
> Am Sonntag, dem 10.09.2023 um 11:14 +0200 schrieb Mathieu Othacehe:
> > I have CC'ed members of the python, java, ruby, rust, r, haskell and
> > emacs teams. Any plans adding cross-compilation support to your
> > build-system, barriers to overcome?
> For Emacs, there are layers of problems.  First things first, we are
> only doing byte compilation atm, which may or may not be arch-dependant
> based on stuff like endianness.  For native compilation, there is the
> thing that even a slightly differently configured emacs won't load the
> packages you've just compiled without compiling it natively on its own.
> Granted, if we want to do cross-compilation, having just the bytecode
> might already be "good enough", but I wanted to throw this out there.
> 
> I think we'd need some support from Emacs proper before we can start
> implementing cross builds.

I will note that the only big-endian architecture which we "support" is
32-bit powerpc, so we don't have to worry that much about wrong
endianness.

-- 
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: hard dependency on Git? (was bug#65866: [PATCH 0/8] Add built-in builder for Git checkouts)

[Ludovic Courtès]

Hello!

Maxim Cournoyer  skribis:

> Yeah, 'git gc' is lacking from libgit2.  I'm not against adding
> dependency on the real 'git' CLI, but at that point, as Simon mentioned,
> I see little reason to keep libgit2 around for much longer, given it
> performs worst than git CLI in every aspect.  I doubt forking processes
> on GNU/Linux would cause a performance hit compared to using libgit2,
> especially given how optimized git appears to be (at least compared to
> libgit2).

As I wrote, as an example, I don’t think that there could be a practical
implementation of (guix git-authenticate) shelling out to ‘git’.

Anyhow, how about this plan:

  1. Merge  with the hard Git
 dependency.

  2. When libgit2 1.7 with shallow clones is available in Guix, work on
 a patch to use Guile-Git for clones and evaluate it.

  3. Brainstorm on ways to address lack of GC support based on a closer
 analysis of disk usage for Guix’s cached checkouts.

Deal?

Ludo’.

PS: I don’t buy the “libgit2 will disappear from Guix” argument because
it’s not a natural phenomenon that we’re observing but a willful
construction.

Thank you for using Emacs

[Peter Polidoro]

MSavoritias  writes:

I go to the manual to learn package management, 
https://guix.gnu.org/en/manual/devel/en/guix.html#Package-Management


Apparently i have to either use the terminal or something called 
emacs. 
If I follow the guide located here: 
https://emacs-guix.gitlab.io/website/manual/latest/emacs-guix.html#Installation


It says to install emacs-guix. Okay. So apparently it is an 
Emacs thing, 
whatever that means. And when you start Emacs after installing 
the 
package, you are going to end up with Emacs in its plain form. 
Unfamiliar keybindings, no autocomplete, etc. Well thats no to 
Emacs 
then. The other thing is the terminal apparently. Horrible, but 
at least 
it works.


You make a very good point, being exposed to Emacs for the very 
first time in this way would be a terrible experience and listing 
alternative options would be very beneficial.


However, I would just like to say "Thank you!" to everyone here 
for using Emacs in the manual.


For my entire career in hardware engineering, I have felt like an 
outcast for using Emacs and being passionate about free software. 
When everyone else on a team or in a company or organization uses 
proprietary software only, it is very isolating and career 
limiting to stay committed to the free software and hardware 
movements.


So while you may not win any popularity contests by using Emacs in 
the manual, just know that it is very much appreciated by some of 
us.

Re: Implementing the guix-dameon in Guile

[Christopher Baines]

Mathieu Othacehe  writes:

>> I imagine the daemon could be structured as a set of actors (it’s really
>> my thing these days ;-)), with an eye on facilitating code sharing and
>> interaction with the Coordinator, Cuirass, and all that.
>
> I think this point is really important here. If the offload mechanism of
> the existing guix-daemon was scaling correctly, with a better API, we
> would probably never had to develop the Cuirass remote worker and the
> Build Coordinator mechanisms.

Indeed.

> Perhaps, part of the Build Coordinator code could be one day integrated
> inside the new guix-daemon so that we can only use one offload mechanism
> for all use cases. Users of the current "guix offload" as well as CI
> tools could rely upon a unique offload mechanism.

Yeah, I think the ideal situation would be to have a daemon that's
flexible and extensible enough to allow this, without being too
complicated or fragile.

> The three other points I had in mind when proposing the subject to NLNet
> were to:
>
> - Fix the sqlite contention issues that have been observed on Berlin and
>   other machines with huge local databases.

Yeah, I think there's some simple things that can be done to improve the
use of SQLite, and then some instrumentation can be added so that any
performance issues can be better understood.

> - Remove the GC lock: I think it has been done on recent nix-daemon.

I'm hoping that with some careful design of how to do garbage
collection, this should be possible.

> - Add support for unprivileged daemon.

I'm not quite sure what is required for this, but maybe it would be
possible without too much effort.

Thanks for your input!

Chris


signature.asc
Description: PGP signature

Re: Implementing the guix-dameon in Guile

[Christopher Baines]

Mekeor Melire  writes:

> 2023-09-13 16:36 m...@cbaines.net:
>
>> I think this has been talked about for a while [1], but I want to
>> make it happen. Currently the guix-daemon is still similar to the
>> nix-daemon that it was forked from, and is implemented in C++. I
>> think that a Guile implementation of the guix-daemon will simplify
>> Guix and better support hacking on and around the daemon to add new
>> features and move Guix forward.
>
> Yippie! I'm really excited about this; and convinced that it'll
> greatly impact and improve the Guix project.
>
>> I'd like to hear what people think about which direction the
>> implementation should go, and what features they'd like to see.
>
> Here's a feature-request (in the long-run). But I'm not sure if I
> understand correctly that a new, improved Guix-daemon enables us to
> implement this. Sorry if I'm wrong. I'd like to be able to step
> through the build-process of a package phase-by-phase and see what
> changed after each phase by looking at the file-tree.

This definitely isn't in the minimal scope, but it's something that I
think having the Guile daemon will maybe make easier to do.

Given the phases are running inside the builder script, I think you'd
need to have that cooperate somehow, and with the help of the daemon
connect somehow to the user so that they can pause and resume the build
process, and inspect the internal state of the builder. The daemon could
also provide access to process/filesystem information as well.


signature.asc
Description: PGP signature

Re: Implementing the guix-dameon in Guile

[Christopher Baines]

Caleb Ristvedt  writes:

>> Still though, I'd like to hear what people think about which direction
>> the implementation should go, and what features they'd like to see. Even
>> if those are not essential to make the Guile implementation viable, it
>> still might inform the direction to take.
> Okay, brain dump time:
>
> I think that using fibers has a lot of potential, but there are
> obstacles that need to be worked around.  In the single-threaded case,
> we risk a big slowdown if multiple clients are active at once, since
> we're doing what used to be done by n processes with one single thread.
> It would be especially noticeable during big disk reads and writes,
> since those basically ignore O_NONBLOCK, and most procedures that act on
> entire files at once would therefore probably not hit many yield points.
> The worst situation would be where multiple worker fibers are attempting
> to do reference scanning at the same time.  Posix asynchronous disk IO
> could be used, but glibc currently implements it... using a thread pool.
> There is the RWF_NOWAIT flag to preadv2, though it's only available on
> newer linuxes and has bugs in 5.9 and 5.10.
>
> Additionally, being single-threaded means use of F_SETLKW is a no-go, so
> you're stuck with polling there.  Granted, that's not such a big issue if
> in 99% of use cases there is only one process doing the locking, so it
> can all be managed internally.

I think a thread pool is essential for using SQLite, so we're already
going to have thread pools interacting with fibers, so if more cases
come up where this is needed, then I think it's an option.

> Speaking of file locks, the risk of accidental clobbering of locks jumps
> way up once it's all moved in to one process, and IIRC we already have
> bugs with accidental clobbering of locks.  You can get a half-decent
> interface by doing what sqlite does, which is a combination of
> intra-process locking and holding on to open file descriptors until all
> locks on the underlying file are released.  There are some subtle
> pathological cases there that are a lot more likely in the guix daemon
> than in sqlite, though.  For example, suppose you open a file twice to
> get ports p1 and p2, acquire read locks on both of them, then close p1,
> then open the file again to get p3, acquire a read lock on it, close p2,
> get p4, acquire a read lock on it, close p3, get p5... and so on.  This
> will cause unbounded file descriptor usage, and eventually you'll run
> out.  There is no workaround in this model other than "hope that usage
> pattern doesn't come up much".  Additionally, you need to ensure that
> every close of a potentially-locked file goes through a special
> close-wrapper.
>
> I'm actually in the middle of working on a solution for this that
> involves a separate locker process that gets passed file descriptors to
> lock via a unix socket.
>
> Speaking of file descriptors, running the entire daemon in one process
> is going to mean much higher pressure on file descriptor resource usage.
> IIRC, while building a derivation, the closure of its inputs needs to be
> locked, and that means a file descriptor for each and every store item
> in its input closure, simultaneously.  The separate locker process would
> make it possible to retain those locks while not having them open in the
> main process.

Maybe that will still need to happen, however I think it might be
possible to replace the IPC through locking files with inter-fiber
communication inside of the dameon.

Backwards compatibility is the priority though, so this can only happen
in cases where that's unaffected.

> In the multithreaded case, fork() and clone() become concerns, since
> they can no longer be safely run from guile.  One way around this would
> be to use posix_spawn to produce a single-threaded guile process, then
> have that do the fork or clone as necessary.  The fork case shouldn't
> actually be necessary, though, as the child process can just exec
> directly.  In the clone case, CLONE_PARENT can be used to make the
> resulting process a child of the original, main process, though I don't
> know how portable that is to hurd (really, I don't know how namespace
> setup works in general on hurd).  Instead of doing this
> spawn-two-processes-to-spawn-one routine every time we want to set up a
> container, we could create a spawner-helper process once and just keep
> it around.  If we can do that before any threads are created, we don't
> even need posix_spawn (though it is nice to have around, and I do have
> bindings to it).  I remember reading that that's what the apache web
> server did.
>
> This would however mean some places would need to use interfaces like
> "eval-with-container" instead of "call-with-container", which is
> somewhat less convenient.  But code staging shouldn't be a terribly
> foreign concept to most guixers.
>
> Another concern is child process management; a blocking waitpid will of
> course block the calling 

Re: Implementing the guix-dameon in Guile

[Christopher Baines]

Josselin Poiret  writes:

>> 2: https://nlnet.nl/project/GuixDaemon-Guile/
>>
>> Rewrites are risky because you only get the value right at the end,
>> therefore the priority is to get a minimal but viable implementation in
>> Guile that can be switched to, and not to get distracted on adding or
>> improving functionality unnecessarily. That is better done once the new
>> implementation has been adopted.
>>
>> While I think there's a substantial amount of work to do, progress
>> towards a Guile guix-daemon has already been made. There was a least one
>> GSoC project which did make progress, and there's Guile implementations
>> of some of the functionality in Guix already.
>>
>> Still though, I'd like to hear what people think about which direction
>> the implementation should go, and what features they'd like to see. Even
>> if those are not essential to make the Guile implementation viable, it
>> still might inform the direction to take.
>
> I think the #1 feature for me would be to have it completely
> unpriviledged using mount namespaces, so that you could still build
> software without needing to run the daemon on the system.  You won't be
> able to run the built software without using namespaces as well though,
> but that still a step in the right direction imo.
>
> WDYT?

Thanks for the suggestion :)

I'm not quite sure what this would involve, but it sounds like it might
not be that hard to do.


signature.asc
Description: PGP signature

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[Peter Pronai]

Wilko Meyer  writes:

> Hi Guix,
>
> I haven't had enough time to read up on every topic that has been
> mentioned in the "How can we decrease the cognitive overhead for
> contributors?" discussion as at some point it got quite a lot to
> follow. At one point[0] there was a discussion on having a survey to get
> a better picture on and quantify what potential blockers are to engage
> with/contribute to Guix; which seems, if done right (as surveys have to
> be carefully crafted), a good idea; especially with the prospect of
> repeating it annually as a means to check if issues got
> better/priorities in Guixes userbase change and so on. If there's a
> consensus on doing this, I'd be happy to contribute some of my time to
> get things going (would creating a issue on guixes bug tracker for this
> topic be a good idea? how are these non-code contrib. topics handled?).
>
> Before writing this mail, I had a look on how other projects handle
> these kind of surveys, in particular:
>
> - the emacs user survey[1]
> - the nix community survey[2]
> - the curl user survey[3]
> - the fennel survey[4]
>
> I identified a few key themes that could be useful for a guix user
> survey as well. I plan on doing a more extensive summary on this later
> this weekend if my time allows it, for now a loose collection of
> ideas/list of what, in my subjective opinion, stood out and what most
> surveys had in common should do to hopefully get a discussion on this
> started:
>
> - the emacs user survey specifically asked for elisp profiency; mapping
>   out the Guile profiency of guixes community could be feasible.
> - fennel as well as emacs had questions on which programming languages
>   their community uses; in the regards on recent discussions on
>   guix-devel on developer ecosystems[4] this could help to identify if
>   there are any shortcomings in providing importers/packages for certain
>   languages that may be used by guix users.
> - the nix survey specifically asked for the environments and context nix
>   is being used in; it'd be interesting to see where and for what
>   purpose people are using Guix.
> - most surveys had, some more some less extensive, demographic
>   questions and questions mapping out how many years people have been
>   programming.
>
> Specifially in the lights of the original discussion/regarding
> contributions:
>
> - I think that the "Where do you discuss Fennel or interact with other
>   Fennel developers" question of fennels survey should be asked for guix
>   as well, to get a grasp on which platforms are being used to discuss
>   all things guix.
> - the curl user survey[6] did a pretty good job in mapping out what
>   prevents users from contributing (p.20) as well as mapping out what
>   areas of the project are regarding as good/which have room for
>   improvements (p.24-26)
> - fennel asked for "the biggest problems you have using Fennel", it had
>   a "If you haven't hacked on Fennel itself, why not?" question as
>   well. I personally think this could be good to assess potential pain
>   points/blockers for Guix as well. Fennel also asked for "favorite
>   features" which could be a nice way to map out which parts of Guix are
>   popular.
>
> Last, the nix user survey allowed free-form responses. Having a
> qualitative research component to a survey could help getting better
> results (especially when identifying problems in using guix/blockers in
> contributing and so on); but evaluating these is pretty time extensive
> and dependant on how much resources people have to compile a list of
> findings/results from a prospective survey.
>
> What could the next steps be to get this going?
>
> [0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00086.html
> [1]: https://emacssurvey.org/
> [2]: https://discourse.nixos.org/t/2022-nix-survey-results/18983
> [3]: https://daniel.haxx.se/blog/2022/06/16/curl-user-survey-2022-analysis/
> [4]: https://fennel-lang.org/survey/2022
> [5]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html
> [6]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf

I definitely vote for having a free form field too, and also an extra
one for feedback on the survey.  It might not be easy to turn it into
quantitative data, but if a lot of people mention certain key words,
that should be both easy to grep for and very apparent even for a casual
reader.