Numerical problem (compiling python-numba package)

[Emmanuel Medernach]

Hello

I don't know if guix-devel is appropriate to report issue with a package.

I have a problem installing the package python-numba version: 0.61.0, I 
cannot compile it on my machine (it compiles on others).


Many tests are failing because of rounding errors such as:

==
FAIL: test_explicit_output 
(numba.tests.test_array_exprs.TestArrayExpressions)

Check that ufunc calls with explicit outputs are not rewritten.
--
Traceback (most recent call last):
  File 
"/gnu/store/72yrh3zapdhq2ka5s0d9jlmx3ma0b0c3-python-numba-0.61.0/lib/python3.10/site-packages/numba/tests/test_array_exprs.py", 
line 387, in test_explicit_output

    ns = self._test_explicit_output_function(explicit_output)
  File 
"/gnu/store/72yrh3zapdhq2ka5s0d9jlmx3ma0b0c3-python-numba-0.61.0/lib/python3.10/site-packages/numba/tests/test_array_exprs.py", 
line 247, in _test_explicit_output_function

    self.assertPreciseEqual(expected, run_func(control_cfunc))
  File 
"/gnu/store/72yrh3zapdhq2ka5s0d9jlmx3ma0b0c3-python-numba-0.61.0/lib/python3.10/site-packages/numba/tests/support.py", 
line 438, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, 
failure_msg))
AssertionError: when comparing [2. 2.54030231 2.58385316 
3.0100075  4.34635638 6.28366219
 7.96017029 8.75390225 8.85449997 9.08886974] and [2. 2.54030231 
2.58385316 3.0100075  4.34635638 6.28366219
 7.96017029 8.75390225 8.85449997 9.08886974]: 8.753902254343306 != 
8.753902254343304


==
FAIL: test_index_ufunc (numba.tests.test_extending.TestPandasLike)
Check Numpy ufunc on an Index object.
--
Traceback (most recent call last):
  File 
"/gnu/store/72yrh3zapdhq2ka5s0d9jlmx3ma0b0c3-python-numba-0.61.0/lib/python3.10/site-packages/numba/tests/test_extending.py", 
line 640, in test_index_ufunc

    self.assertPreciseEqual(ii._data, np.cos(np.sin(i._data)))
  File 
"/gnu/store/72yrh3zapdhq2ka5s0d9jlmx3ma0b0c3-python-numba-0.61.0/lib/python3.10/site-packages/numba/tests/support.py", 
line 438, in assertPreciseEqual
    self.fail("when comparing %s and %s: %s" % (first, second, 
failure_msg))
AssertionError: when comparing [0.60858395 0.54922627 0.57440088] and 
[0.60858395 0.54922627 0.57440088]: 0.549226270051226 != 0.5492262700512262


More generally this asks the question about reproducibility of numerical 
packages.


Best regards,

Emmanuel Medernach

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[45mg]

Hi Ekaitz,

We would be far from the first project to rename the 'master' branch to
'main'. Here's a blog post from GitLab that should give you an idea of
how widespread this is:
https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/

When everyone from GitHub to GitLab to the Git project itself has taken
steps in this direction, it would seem strange for us /not/ to do so
given the opportunity.

It looks like you're aware of the widespread effort to move away from
'master-slave' terminology, and you're even in support of said effort,
so I guess that doesn't need to be discussed here directly.

I was pleasantly surprised to find that Guix has been committed to
inclusivity from the start [1]. This is uncommon in projects as old as
Guix is - for example, NixOS only adopted a Code of Conduct in late
2023, and only after a huge amount of drama that nearly split the
community [2]. When people criticize Guix over GNU's reputation, this is
one of the things I bring up. It is something to be proud of, IMHO.

Here's my perspective: it will cost us basically nothing to rename the
master branch, especially if we do it in the context of the Codeberg
migration since we'd already by upending peoples' workflows.

In return, we get an opportunity to remind everyone that even after a
decade, and even in the midst of all the moral backsliding going on
around us today, /we still care/. Because, unfortunately, it appears
that even this basic assumption cannot be taken for granted anymore [3].


[1] The CODE-OF-CONDUCT file was added in
e15fcdd149cec662fcaf4b550ee32879bd53a591, which dates back to 2015!
[2] https://discourse.nixos.org/t/adopting-a-code-of-conduct/35136
[3] Political discussion is apparently discouraged on GNU mailing lists,
but it should suffice to investigate why the term 'DEI' has been in
the news lately.

Re: Securing personal forks (Was: Discussion with Codeberg volunteers)

[Murilo]

Hi Felix and 45mg,

I came up with a quick dirty hack for solving my authentication problems on guix
forks and channel forks, and upon seeing this discussion I thought I'd share
some bits.
It's a very simple trick, only requires (roughly) 3 lines of code in
'guix/git-authenticate.scm'.

See [1] for the diff (in the guix-hacks branch), just search for the 'init auth
hack' commit (I rebase it all the time so its better if you search for the
commit as any links will get broken soon).

If you don't want to, it goes something like this:
--
...
  (unless (or (member (openpgp-public-key-fingerprint signing-key)
  (commit-authorized-keys repository commit
  default-authorizations))
  (member (openpgp-format-fingerprint
(openpgp-public-key-fingerprint signing-key))
  '("          ")))
...
--

After I add my fingerprint to the 'or' condition, I also add my public key to
the 'keyring' branch of the fork [2].
After that we need to bootstrap it once with '--disable-authentication', and
after bootstrapping it once you can freely rebase with only '--allow-downgrades'
(or don't rebase at all, your call) and enjoy full authentication on your fork.

No need to mess with introductory commits, you can just keep guix' default one.
No need to edit '.guix-authorizations'.

It also works for authenticated channel forks, you just need to add your key to
the 'keyring' branch of the channel fork and it will work.

Just sharing this quick hack I use, its far from ideal but it works for me, and
seeing this discussion I thought it might be useful for someone in the meantime
:)

Best regards,
Murilo

[1] https://codeberg.org/look/guix/commits/branch/guix-hacks
[2] 
https://codeberg.org/look/guix/commit/8e2902aabb14e93864920bac51a178aeedf8a563

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Liliana Marie Prikler]

Am Mittwoch, dem 12.02.2025 um 11:44 +0100 schrieb Ekaitz Zarraga:
> We also execute programs (and we have many references to that word in
> our docs), and some people I know had members of their family
> executed because of their ethnicity or beliefs. I think all of us
> understand those are two different meanings of the same word, and
> that's what the dictionary says.
Even assuming that those meanings of "execute" map to the same words in
all languages (they don't) and that there are no alternatives to
"executing" programs (there are, e.g. "running" them), this point is
not as good as you're trying to make it.  To my knowledge, all uses of
"master", even the "master's degree" cited below, do come with a bit of
an elitist connotation ;)

> I also hold a masters degree but never enslaved anyone with it. We
> all understand I didn't go to a slavery school, but an engineering
> school.
> 
> Master doesn't have an obvious derogatory meaning, and in Git there's
> no slave. I would support this change if we had something called
> slave and would like to change both words.
Funny that you mention git, given that it comes with the following
hint:

> Using 'master' as the name for the initial branch. This default
> branch name is subject to change. To configure the initial branch
> name to use in all of your new repositories, which will suppress this
> warning, call:
>   git config --global init.defaultBranch 
> 
> Names commonly chosen instead of 'master' are 'main', 'trunk' and
> 'development'. The just-created branch can be renamed via this
> command:
>   git branch -m 

> Also, why is this about black people specially? Which group of black 
> people specifically? All of them have been slaved? Are all of them 
> specially sensitive to words in the English language (which btw is 
> probably not the first language of most of us)?
It is not.  Hartmut simply recalled the most relevant bit of
information within the current cultural Zeitgeist.  "No gods, no
masters" has been a slogan even before git was a thing :)

Within the predominant discussion, it is typically the fate of African
American people, who first suffered from slavery, then overtly racist
laws and now still racist enforcement of "the law", which may be less
overtly racist but still serves to oppress minorities wherever they may
be oppressed.  These people have been forced to learn English as their
first language, same as we have been forced to learn it as our second
or third language.  So yeah, I would hazard a guess that some
sensitivity exists for a not that small group of people.

> Are we suggesting here that all black people are the same? Isn't that
> more racist than the word "master" alone?
No, that's just you extrapolating without a cause.

> I think this is just a trend that got popular in the narrative in the
> US, and they are trying to export it. The world is not the United
> States.
Even if true, the usage of "master" as the main branch for Guix
development is dated.  

If a move to Codeberg does not find consensus for whatever reason, a
rename can still be sought after as a standalone change.  But IMHO it
would be weirdly conservative to switch platforms while keeping the old
branch name.

Cheers

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Giovanni Biscuolo]

Ludovic Courtès  writes:

> Simon Tournier  skribis:

[...]

>> I would add two roadblocks (at least for me):
>>
>>  1. Not being able to process offline.
>>
>>  2. Not being able to comment patches directly from the editor of my own
>> choice.
>
> I think this was now answered: Magit-Forge, fj.el, forgejo-cli.  Not all
> of this is fully ready, but I’m sure we’ll find enough motivation to
> give a hand to their developers.

(sorry if this has already been answered...)

so if I understand correctly, all patch comments (rationale and all
related discussion) will be moved (stored) to Codeberg and guix-patches
will be dismissed?

[...]

thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Questions on updating `aerc` and its Go dependency

[Tanguy Le Carrour]

Hi,


On Mon Feb 10, 2025 at 9:00 AM CET, Tanguy Le Carrour wrote:
> On Sun Feb 9, 2025 at 9:49 AM CET, Sharlatan Hellseher wrote:
>> I've added go-git-sr-ht-rjarry-go-opt-v2 variant to master.
>
> Thanks!
>
> I’ll send the patch for Aerc later this week.

Submitted as #76226.

-- 
Tanguy

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Ekaitz Zarraga]

Hi all,

I don't want to destroy the thread so I just going to give a couple of 
notes on this in order to share what I think is important, and often 
misheard and leave.


On 2025-02-12 12:46, 45mg wrote:
> It looks like you're aware of the widespread effort to move away from
> 'master-slave' terminology, and you're even in support of said effort,
> so I guess that doesn't need to be discussed here directly.

Yes I am!
I think the words have been subject to an extreme scrutiny that I don't 
agree with. That's all.
The case of Git I consider a poor understanding, and it had led me to 
stupid situations in the past.


Now we need to know which is the root branch of the repositories, and 
sometimes it's not obvious.


> Here's my perspective: it will cost us basically nothing to rename the
> master branch, especially if we do it in the context of the Codeberg
> migration since we'd already by upending peoples' workflows.

I don't agree with this point 100%. It has been done before, yes. It's 
as simple as renaming a branch, yes. But it would affect other things.

We should go through a GCD for it, imho.

> it should suffice to investigate why the term 'DEI' has been in
>  the news lately.

In the news where, exactly?
(this doesn't mean I'm not sensible about the problem or anything like 
that, I'm just trying to point out this all comes from a movement from a 
political situation that is not universal)



On 2025-02-12 13:14, Liliana Marie Prikler wrote:


Even assuming that those meanings of "execute" map to the same words in
all languages (they don't) and that there are no alternatives to
"executing" programs (there are, e.g. "running" them), this point is
not as good as you're trying to make it.  To my knowledge, all uses of
"master", even the "master's degree" cited below, do come with a bit of
an elitist connotation ;)


There are alternatives, you can "run" programs, you can "launch" 
programs, you can "operate"... or IDK, I'm not a linguist myself. The 
same goes to "main" vs "master" or anything else. It's just a matter of 
taste and decisions.


Not all uses of master have an elitist background (some are also 
misogynistic :) ), but that's not the reason why we are discussing this.



Funny that you mention git, given that it comes with the following
hint:


I know, I know, what I was criticizing was the reason.


It is not.  Hartmut simply recalled the most relevant bit of
information within the current cultural Zeitgeist.  "No gods, no
masters" has been a slogan even before git was a thing :)


A slogan I like, btw. But I don't feel like I should remove the word. I 
feel like I should remove the people that are masters.
And yes, I know Hartmut just made this simple and I wasn't targeting him 
(<3), but ideas behind.



Within the predominant discussion, it is typically the fate of African
American people, who first suffered from slavery, then overtly racist
laws and now still racist enforcement of "the law", which may be less
overtly racist but still serves to oppress minorities wherever they may
be oppressed.  These people have been forced to learn English as their
first language, same as we have been forced to learn it as our second
or third language.  So yeah, I would hazard a guess that some
sensitivity exists for a not that small group of people.


It's not a small group what you describe, but I'm not sure about the 
amount of people we are doing this for. I think this is just a matter of 
image, and I'm not sure about who are we trying to please with the change.


We are proposing it because other people did something similar, and 
because some claim people is hurt by a word, this word, in this context. 
What I'm trying is to think rationally about it and try to avoid some 
possible harm (I have had misunderstanding with other project's 
branching scheme, specially with some that have many branches, in guile 
it has happened to me... I think the master branch is still there but 
very old).


What I think in this specific case is all started with good intentions 
but somebody got a little bit too far and git developers wanted to be a 
little friendly. I don't like this, maybe because my personal 
experience, where I've seen people being banned from places for using 
the word "negro" in spanish which just means "black" (the color), and 
surprisingly for many people from the US is the word "black people" in 
spain prefer to be called.


What I mean here is we should choose our way to do things, and not 
necessarily copy whatever political/social/anything situation that 
happens in one specific country, because that's a little bit 
condescending with the rest of the world. If we are talking about 
inclusion, that also matters.



If a move to Codeberg does not find consensus for whatever reason, a
rename can still be sought after as a standalone change.  But IMHO it
would be weirdly conservative to switch platforms while keeping the old
branch name.


Practically speaking, the move to Codeb

Welcoming Steve as a new committer!

[Maxim Cournoyer]

Hello Guix!

I'm pleased to announce that Steve has just been enabled as a committer
to the project, bringing the number of committers to 48.
Congratulations!  Happy committing, Steve!  And thank you for all your
contributions to the Guix project thus far!

-- 
Maxim

Re: Welcoming Steve as a new committer!

[Efraim Flashner]

On Thu, Feb 13, 2025 at 12:20:02AM +0900, Maxim Cournoyer wrote:
> Hello Guix!
> 
> I'm pleased to announce that Steve has just been enabled as a committer
> to the project, bringing the number of committers to 48.
> Congratulations!  Happy committing, Steve!  And thank you for all your
> contributions to the Guix project thus far!

Congrats!

-- 
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: [GCD] Migrating repositories, issues, and patches to Codeberg

[Ekaitz Zarraga]

On 2025-02-12 16:17, Liliana Marie Prikler wrote:

So if we do the change, I'd prefer if we have made the move to
Codeberg already.

Non sequitur.  If Codeberg makes seeing the default branch that
obvious, changing it at once should not matter.


I didn't explain this properly.

I meant agreed to move to Codeberg. I'm ok with doing both things at the 
same time, if we do it.


What I'd like to avoid is not to have Codeberg and have the branch name 
changed.

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Liliana Marie Prikler]

Am Mittwoch, dem 12.02.2025 um 14:36 +0100 schrieb Ekaitz Zarraga:
> (this doesn't mean I'm not sensible about the problem or anything
> like that, I'm just trying to point out this all comes from a
> movement from a political situation that is not universal)
As does the free software movement.

> Not all uses of master have an elitist background (some are also 
> misogynistic :) ), but that's not the reason why we are discussing
> this.
Fair enough, I should have said discriminatory to catch all meanings.

> 
> But I don't feel like I should remove the word. I feel like I should
> remove the people that are masters.
And then what?

> 
> I think this is just a matter of image, and I'm not sure about who
> are we trying to please with the change.
Since I was the one to initially make this suggestion: myself, plus
whoever agrees with me, regardless of their reason.

> What I'm trying is to think rationally about it and try to avoid some
> possible harm (I have had misunderstanding with other project's 
> branching scheme, specially with some that have many branches, in
> guile it has happened to me... I think the master branch is still
> there but very old).
What possible harm do you intend to avoid by *keeping* the old name?

> What I think in this specific case is all started with good
> intentions but somebody got a little bit too far[…]
I'd like to give you the benefit of the doubt, but this paragraph does
read like concern trolling to me.  We are used to working with
branches, switching the main branch should not cause that much of an
overhead.

> What I mean here is we should choose our way to do things, and not 
> necessarily copy whatever political/social/anything situation that 
> happens in one specific country, because that's a little bit 
> condescending with the rest of the world. If we are talking about 
> inclusion, that also matters.
Keeping a ten years old default doesn't really sound like "choosing our
way" to me.

The "one specific country" argument is kinda weak too.  I count myself
to the rest of the world — though admittedly still the imperial core —
and I think other proponents for this change do as well.  As a gesture
towards inclusion, the change is probably symbolic at best, but not
even doing that for dubious reasons will leave us in the past
indefinitely. 

> 
> Practically speaking, the move to Codeberg would make the rename
> EASIER and also avoid some of the possible harm as it would be more
> obvious to see the default branch in the web interface of the
> repository.
> 
> So if we do the change, I'd prefer if we have made the move to
> Codeberg already.
Non sequitur.  If Codeberg makes seeing the default branch that
obvious, changing it at once should not matter.


Cheers

GNU Shepherd 1.0.2 released

[Ludovic Courtès]

We are glad to announce version 1.0.2 of the Shepherd, the second
bug-fix release in the 1.0.x series.

Check out the web site to learn more about the Shepherd 1.0.x series:

  https://gnu.org/software/shepherd/news/2024/12/the-shepherd-1.0.0-released/

• About

  The Shepherd is a service manager written in Guile that looks after
  the herd of daemons running on the system.  It can be used as an
  “init” system (PID 1) and also by unprivileged users to manage
  per-user daemons—e.g., gpg-agent, tor, privoxy.  It supports several
  daemon startup mechanisms, including inetd, systemd-style socket
  activation, and timers.  The Shepherd is configured in Guile Scheme
  and can be extended in the same language.  It builds on a simple
  memory-safe and callback-free programming model.

  The Shepherd is developed jointly with the Guix project; it is used as
  the init system of Guix System and service manager of Guix Home.

  https://www.gnu.org/software/shepherd/

• Download

  Here are the compressed sources and a GPG detached signature:
https://ftp.gnu.org/gnu/shepherd/shepherd-1.0.2.tar.gz
https://ftp.gnu.org/gnu/shepherd/shepherd-1.0.2.tar.gz.sig

  Here are the SHA1 and SHA256 checksums:

2af0ab3c090ae39c7a21e2b1aa550938b8299d64  shepherd-1.0.2.tar.gz
df4bac04b4b0476fa8f9ed138292ac2cc54b4304b5eefd859ed4892d4f9924bf  
shepherd-1.0.2.tar.gz

  Verify the integrity of the tarball with ‘cksum -a sha256 --check’.

  Authenticate the code by downloading the corresponding .sig file:

gpg --verify shepherd-1.0.2.tar.gz.sig

  The signing key can be retrieved with:

gpg --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

  As a last resort to find the key, you can try the official GNU
  keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify shepherd-1.0.2.tar.gz.sig

  This tarball was bootstrapped with the following tools:
Autoconf 2.71
Automake 1.16.5
Gettext 0.21
Makeinfo 7.1.1

  It is bit-for-bit reproducible from a checkout of the ‘v1.0.2’ tag of
  the Git repository.

• Changes since version 1.0.1

  ** ‘daemonize’ action preserves replacement bindings for ‘sleep’ etc.
 ()

  The shepherd process replaces bindings for ‘sleep’, ‘system*’, ‘system’, and
  other core Guile procedures with cooperative variants thereof—for instance, it
  replaces ‘sleep’ with Fibers’ own ‘sleep’ procedure, which does not block.

  Previously, the ‘daemonize’ action would remove those binding replacements,
  which could lead to blocking in shepherd, with symptoms such as ‘herd status’
  not responding.  This is now fixed.

  ** Gracefully handle failure to create a service’s log file
 ()

  If the file passed as #:log-file to ‘make-forkexec-constructor’ & co. could
  not be created, ‘herd status’ and similar commands would hang.  This is now
  fixed in two ways: by attempting to create the parent directory of the log
  file if it does not exist, and by reporting the failure and keeping the
  service ‘stopped’ in other cases.

  ** Timers honor daylight saving time (DST) changes
 ()

  Previously, timers would always sleep a fixed amount of time between two
  consecutive calendar events—e.g., 24h between two occurrences of a daily
  event—regardless of whether both events occur in the same timezone or DST
  setting.  Timers now correctly honor DST changes—e.g., sleeping for 25h
  between two daily events if the first one occurs on CEST (Central European
  Summer Time, or UTC+2) and the second one occurs on CET (Central European
  Time, or UTC+1).

  ** ‘cron-string->calendar-event’ can now interpret things like “*/2”
 ()

  Until now, ‘cron-string->calendar-event’ would fail to interpret
  specifications like "0 */2 * * *" (meaning: every two hours).  This is now
  fixed.

  ** ‘cron-string->calendar-event’ properly interprets stars for hours
 ()

  Previously, using a star for the hours in a cron specification such as
  "* * * * *" (meaning: every minute) would lead ‘cron-string->calendar-event’
  to erroneously report an error.  This is now fixed.

  ** ‘timer-service’ and ‘transient-service’ now honor #:requirement

  Previously they would both ignore it, returning a service that depends on
  nothing but the root service (which is probably acceptable most of the time).

  ** ‘default-message-destination-procedure’ is now exported

  That procedure of (shepherd service system-log) was documented but not
  exported.  This is now fixed.

  ** Translations

  This version is fully translated in German, Romanian, Slovak, Swedish, and
  Ukranian; it is partially translated in seven other languages.  Check out
  https://translationproject.org/domain/shepherd.html to help translate it into
  your language!


Please report bugs to bug-g...@gnu.org.
Join g

node-team / bootstrapping node packages

[Nicolas Graves]

Hi guix,

I was wondering if a node-team would be useful to make the work towards
making a few applications available in Guix.

It's been quite some time that 68941 is ready but forgotten.  Based on
this patch series, I'm now able to build a node-tape-bootstrap with
minimal missing dependencies to make the process fully bootstrapped
(concat-stream, tap, libtap, es-value-fixtures).

So I can send :
- a rebased 68941 v3, probably moving all those packages and then some
in a new node-bootstrap.scm 
- a patch series completing those up to node-tape with those few missing
bootstrapped dependencies, probably bootstrap libtap and
es-value-fixtures along the way.  I use an opiniated trick here that
would require some review, the same one as in 67902 that had the same
fate (patch series ready but unreviewed and forgotten). We also need
some fixes to the build-system there.

>From there, the path seems clear to me :
- extend the node-build-system to a node-workspace-build-system to be
able to package tap without requiring 2k+ lines.  I've done that for a
rust-build-system but lost the progress since, but I know it's doable.
- build node-tap-bootstrap on node-tape-bootstrap
- rebuild a node-tape with node-tap-bootstrap 
- rebuild a node-tap with node-tap
- port typescript build from guixrus in a new node-build.scm or
node-typescript.scm

These are the minimal building blocks to start being able to package
some final-user things.

My final goal is a zotero-translation-server sans aws-sdk.  I think this
is doable but I need some foresight on how this can happen (i.e. Would I
tackle that alone and should I eventually setup GPG or (my preference)
can I do that in close collaboration with a new node-team member ?)

-- 
Best regards,
Nicolas Graves

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Ekaitz Zarraga]

On 2025-02-11 18:40, Hartmut Goebel wrote:

Am 11.02.25 um 11:36 schrieb Tomas Volf:

What are the benefits of changing the name of the master branch?


"master" is considered offensive for black people, because of centuries 
of slavery - where the "master" was the suppressor.




Those you know me know that I'm all in for the inclusion etc. but I 
honestly think this is too much.


We also execute programs (and we have many references to that word in 
our docs), and some people I know had members of their family executed 
because of their ethnicity or beliefs. I think all of us understand 
those are two different meanings of the same word, and that's what the 
dictionary says.


I also hold a masters degree but never enslaved anyone with it. We all 
understand I didn't go to a slavery school, but an engineering school.


Master doesn't have an obvious derogatory meaning, and in Git there's no 
slave. I would support this change if we had something called slave and 
would like to change both words.


Also, why is this about black people specially? Which group of black 
people specifically? All of them have been slaved? Are all of them 
specially sensitive to words in the English language (which btw is 
probably not the first language of most of us)?


Are we suggesting here that all black people are the same? Isn't that 
more racist than the word "master" alone?


I think this is just a trend that got popular in the narrative in the 
US, and they are trying to export it. The world is not the United States.


I know this is not the place to discuss this, but I found this rhetoric 
very poor.

Re: GNU Shepherd 1.0.2 released

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

Hi Ludo',

On Wed, Feb 12 2025, Ludovic Courtès wrote:

> glad to announce version 1.0.2 of the Shepherd

Thank you so much for offering the Shepherd to the world!

I think back with dread about using INI files and SystemD, not to
mention the social tensions that arose when it took over.  The Shepherd
makes me proud to use GNU Guix!

Kind regards
Felix

[GCD] Renaming `Master` Branch Into Another Term

[indieterminacy]

Hello,

I believe that the term `Master` for the root branch is an anacronism.

I propose that it is renamed to `The Gulf of Mexico`.

Unless people have a better suggestion?

Kind regards,


Jonathan

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Liliana Marie Prikler]

Am Mittwoch, dem 12.02.2025 um 10:56 -0500 schrieb Suhail Singh:
> I am not arguing on whether the branch name should be changed or not.
> However, I do think this is a topic that should be discussed in a
> GCD. [… N]ot discussing this via a GCD would go against its intended
> use:
That's why I commented on the Codeberg GCD — so that it can be included
in a v2 of said GCD.  I do expect there will be some revisions before
the decision is final.

Cheers

Re: G-Golf in Guix - 1 G-Golf (only) pkg, 1 pkg per lib examples per major version number

[pelzflorian (Florian Pelz)]

David Pirotte  writes:
>> >g-golf 
>> >g-golf-gtk-4-examples
>> >g-golf-adw-1-examples  

You are right, of course.  Indeed Guix would better now include a
package even if the packaging is not ideal.

I submitted a first attempt for g-golf-gtk-4-examples at

.

Thank you not only for the mighty G-Golf but also, by the way, for your
patch to allow Guile-Cairo to run its tests.  The patch has not reached
upstream, but with it, the Guile-Cairo commit needed by examples can
build in Guix.

> when trying oe of the distributed example, they have
> to use --no-grafts:
>
>   is this requirement documented somewhere in guix by the way?

No, as a requirement --no-grafts is not documented, just arcane
knowledge in Debbugs.  The option can be found in `guix build --help'.

> Assuming you split as suggested, all example scripts could be
> (automatically) 'guix patched' to pass the --no-grafts option (?). This
> would also show guix users how to launch their own app, when using
> guix.

Yes, I guess grafts could be patched in using (with-parameters ((%graft?
#f)) ...), but strangely the hello-world in the package runs fine even
with grafts.  I do not understand why it affects me elsewhere.

Regards,
Florian

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Suhail Singh]

Liliana Marie Prikler  writes:

> That's why I commented on the Codeberg GCD — so that it can be
> included in a v2 of said GCD.  I do expect there will be some
> revisions before the decision is final.

Ah, my bad.  That that was the intent had escaped me.  Thank you for
clarifying.

-- 
Suhail

Re: Welcoming Steve as a new committer!

[Ian Eure]

Welcome!

On February 12, 2025 7:20:02 AM PST, Maxim Cournoyer 
 wrote:
>Hello Guix!
>
>I'm pleased to announce that Steve has just been enabled as a committer
>to the project, bringing the number of committers to 48.
>Congratulations!  Happy committing, Steve!  And thank you for all your
>contributions to the Guix project thus far!
>
>-- 
>Maxim
>

Re: On a Guile-based Build-Tool complimenting Guix

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

Hi,

On Thu, Dec 19 2024, Divya Ranjan wrote:

> why doesn’t Guix [...] have a purely Guile-based build tool?

A year ago, I rewrote Guix's Makefile recipes in GNU Guile.  They look
like the example below.  Would the maintainers accept such a patch?

It would be a small step for a human but a big step for humankind.

Kind regards
Felix

* * *

export SHELL = /run/current-system/profile/bin/guile

.SILENT: all

all:
(format #t "Hello, Guix!")

Re: Numerical problem (compiling python-numba package)

[Ricardo Wurmus]

Hi Emmanuel,

> I don't know if guix-devel is appropriate to report issue with a
> package.

It's appropriate.

> I have a problem installing the package python-numba version: 0.61.0, I 
> cannot compile it on my machine (it
> compiles on others).

While I cannot reproduce this (I upgraded python-numba and built it on
my laptop before pushing the upgrade commit), I wonder if the test case
could be reduced to just numpy, or at least broken out of the numba test
suite.

-- 
Ricardo

Re: Welcoming Steve as a new committer!

[Leo Famulari]

On Thu, Feb 13, 2025 at 12:20:02AM +0900, Maxim Cournoyer wrote:
> I'm pleased to announce that Steve has just been enabled as a committer
> to the project, bringing the number of committers to 48.
> Congratulations!  Happy committing, Steve!  And thank you for all your
> contributions to the Guix project thus far!

Welcome!

Re: [GCD] Renaming `Master` Branch Into Another Term

[indieterminacy]

Hi Ian,

I created this stub, given that the major GCD being discussed atm 
(regarding Codeberg) features a thread concerning whether the term 
`master` is not apt for future Guix activity.


As can be imagined (and already raised), that topic risks being 
counterproductive in the same channel (nobody has strayed off too far I 
should posit).

Id prefer the ruin of this thread than another.

On 2025-02-12 19:09, Ian Eure wrote:

Hi Jonathan,

indieterminacy  writes:


Hello,

I believe that the term `Master` for the root branch is an anacronism.

I propose that it is renamed to `The Gulf of Mexico`.

Unless people have a better suggestion?


Please don’t waste our time with trolling nonsense.



Please dont conflate seriousness with sense.

As an Irish citizen I have an acute awareness regarding top down 'naming 
rights'.
Its not cool and its my prerogative to highlight my displeasure should I 
notice abuses.


The contemporary Gulf hooha is nothing new - only yesterday was I 
drawing parallels regarding the Dail position on the term 'British 
Isles' [Volume 606 - 28 September, 2005  -- 593]:

https://social.coop/@indieterminacy/113987198315864816

Im entirely ok with a new name being chosen in solidarity - in line with 
Streisand effect type asymmetric tactics.


Not only do I have a name Anglicised from the Celtic form (barstardised 
from some random Saxon permutation).
I personally had to resist (through legal means) my children (and 
thereby all descendants) having an altered capitalisation of their 
surname.


... So forgive me for providing conjecture that is evidently able to be 
improved upon.


You and others are free to use this stub to discuss the topic regarding 
naming.

Or another.

However, Id assert naming is significant AND irreverence is not 
absolutely an impedance within such debates.
Irreverence is not a tool to leave rusted - any historical analysis 
countering authoritarianism makes that clear.


For instance, if trolling is genuinely a point of concern and pain, then 
I suggest that we switch the name `master` to

`uyghur`.

Rather than playing with purity tests btl armed with eptimology, anguish 
and thesauruses, we can remind people that shitty things are happening 
and that they should not be forgotten.



Jonathan

Re: [GCD] Renaming `Master` Branch Into Another Term

[paul]

LMAO, thank you for bringing this up Jonathan. While I think "The Gulf 
of Mexico" is kind of a mouthful, I agree it makes no sense for the 
default branch to be called master. I have no strong opinion on the new 
name, imho it should be "main" as the de facto standard goes but also 
"history" as Felix proposed or "default" could be suitable I believe.


giacomo

Re: [GCD] Renaming `Master` Branch Into Another Term

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

Hi indieterminacy,

On Wed, Feb 12 2025, indieterminacy wrote:

> better suggestion?

I have used the deadpan 'history' for years and never had second
thoughts.  It is the branch with which all others share their history.

History is something that happens.  There are no notions of superiority
or control that would remain with 'main'.

I came up with the name in the motherland of language police (SF Bay
Area).  No one ever complained.  Have courage!  It can be done.

Kind regards
Felix

P.S. I'm not a project member and have no vote.
P.P.S. Sorry about asking for this GCD earlier & thanks!

Re: Welcoming Steve as a new committer!

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

On Thu, Feb 13, 2025 at 12:20 AM, Maxim Cournoyer wrote:

> Hello Guix!
>
> I'm pleased to announce that Steve has just been enabled as a committer
> to the project, bringing the number of committers to 48.
> Congratulations!  Happy committing, Steve!  And thank you for all your
> contributions to the Guix project thus far!

Great news, welcome Steve! Glad to have you onboard for more Guix
goodness.

John

Branch naming (Was: [GCD] Migrating repositories, issues, and patches to Codeberg)

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

Hi,

On Mon, Feb 10 2025, Ludovic Courtès wrote:

> I support it as well¹ but I think we’d rather address it separately.

Let's offer a place to litigate for those who want to spend their time
on it!  Will someone please start this GCD?

Kind regards
Felix

Re: [GCD] Renaming `Master` Branch Into Another Term

[Ian Eure]

Hi Jonathan,

indieterminacy  writes:


Hello,

I believe that the term `Master` for the root branch is an 
anacronism.


I propose that it is renamed to `The Gulf of Mexico`.

Unless people have a better suggestion?


Please don’t waste our time with trolling nonsense.

 -- Ian

Re: [GCD] Renaming `Master` Branch Into Another Term

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

Hi indieterminacy,

On Wed, Feb 12 2025, indieterminacy wrote:

> things are happening and [...] they should not be forgotten.

That is "history!"

Kind regards
Felix

scilab graphical version

[Christopher Howard]

Hello Nicolas and David, I was wondering if anyone is running the graphical 
version of scilab on Guix and how you got that working. I am very interested in 
the model building GUI:

https://www.scilab.org/software/xcos/model-building-edition

-- 
📛 Christopher Howard
🚀 gemini://gem.librehacker.com
🌐 http://gem.librehacker.com

בראשית ברא אלהים את השמים ואת הארץ

Re: G-Golf in Guix - G-Golf pkg(s) name(s)

[David Pirotte]

Hello Ian,

> Changing this convention would require a very large amount of work 
> ...

In my initial message, I was merely asking to not apply the guile-
prefix rule to the g-golf package definition.

That I would not do this for other packages either was an answer to
iyzsong, as they were explaining 'the general rule'. Although I find it
strange wrt other guile-* pkgs for which that rule was also applied, I
have no 'strong feeleing', and think it's up to their authors to raise
their voice, if they consider this important.

> I’m not sure what the history of it is; I’d be interested to find 
> out.

That was a few year ago, in #guix, but I don' think it is worth loosing
your time.

But for the record, and fwiw, during that chat, they also did ask that
I post here (finally did) and also said(wrote) that because the g-golf
package definition was in the guile-xyz.scm file, it had to be named as
guile-*, which I didn't think was an accurate statement (as
exception(s) did exist already, nor a proper justification anyway ...
but if that's so, may I suggest to create a xyz-guile.scm file.

> Because of the large impact such a change would make ...

I am merely asking that Guix accepts to 'make an exception' for its
g-golf packages definitions, it only took me a few seconds to make
those changes [1], and another minute or two to review and update the
description field (updated upstream a little while ago as well).

Attached is a patch reflecting those changes.

Please reconsider,
Thanks,
David

[1] I don't use Guix but I have a clone, did pull the latest and
patched ...
From 98b5177b6a3c27a65652fa9f77143d76637439df Mon Sep 17 00:00:00 2001
From: David Pirotte 
Date: Wed, 12 Feb 2025 18:58:42 -0300
Subject: [PATCH] gnu: g-golf: pkg names and description review

* gnu/packages/guile-xyz.scm (g-golf): Use g-golf as the package name, not
  guile-g-golf. Updating the description.

  (g-golf-guile-2.2): Use g-golf-guile-2 as the package name, not
  guile-2.2-g-golf.
---
 gnu/packages/guile-xyz.scm | 43 +-
 1 file changed, 28 insertions(+), 15 deletions(-)

diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 92d5d90194..06471df28a 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -2521,9 +2521,9 @@ (define-public guile-sly
 (home-page "https://dthompson.us/projects/sly.html";)
 (license license:gpl3+)))
 
-(define-public guile-g-golf
+(define-public g-golf
   (package
-(name "guile-g-golf")
+(name "g-golf")
 (version "0.8.0")
 (source
  (origin
@@ -2597,24 +2597,37 @@ (define (get lib)
 (propagated-inputs
  (list gobject-introspection))
 (home-page "https://www.gnu.org/software/g-golf/";)
-(synopsis "Guile bindings for GObject Introspection")
+(synopsis "GNOME: (Guile Object Library for)")
 (description
- "G-Golf (Gnome: (Guile Object Library for)) is a library for developing
-modern applications in Guile Scheme.  It comprises a direct binding to the
-GObject Introspection API and higher-level functionality for importing Gnome
-libraries and making GObject classes (and methods) available in Guile's
-object-oriented programming system, GOOPS.")
+ "@uref{https://www.gnu.org/software/g-golf, G-Golf} is a Guile Object Library
+ for GNOME.
+
+@uref{https://www.gnu.org/software/g-golf, G-Golf} is a tool to develop fast
+and feature-rich graphical applications, with a clean and recognizable look
+and feel. Here is an overview of the
+@uref{https://developer.gnome.org/documentation/introduction/overview/libraries.html},
+GNOME platform libraries}, accessible using
+@uref{https://www.gnu.org/software/g-golf, G-Golf}.
+
+In particular,
+@uref{https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/},
+libadwaita} provides a number of widgets that change their layout based on the
+available space. This can be used to make applications adapt their UI between
+desktop and mobile devices. The @uref{https://wiki.gnome.org/Apps/Web}, GNOME
+Web} (best known through its code name, Epiphany, is a good example of such an
+adaptive UI.
+
+For a complete description, visit the
+@uref{https://www.gnu.org/software/g-golf, G-Golf} home-page or read the
+distributed README file.")
 (license license:lgpl3+)))
 
-(define-public g-golf
-  (deprecated-package "g-golf" guile-g-golf))
-
-(define-public guile2.2-g-golf
+(define-public g-golf-guile-2.2
   (package
-(inherit guile-g-golf)
-(name "guile2.2-g-golf")
+(inherit g-golf)
+(name "g-golf-guile-2.2")
 (inputs
- (modify-inputs (package-inputs guile-g-golf)
+ (modify-inputs (package-inputs g-golf)
(replace "guile" guile-2.2)
(replace "guile-lib" guile2.2-lib)
 
-- 
2.47.2



pgpGuplQHX1sn.pgp
Description: OpenPGP digital signature

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Leo Famulari]

On Wed, Feb 12, 2025 at 05:13:25PM +0100, Liliana Marie Prikler wrote:
> That's why I commented on the Codeberg GCD — so that it can be included
> in a v2 of said GCD.  I do expect there will be some revisions before
> the decision is final.

It should be a separate discussion.

Maybe it's a minor change, maybe it's a major change. That depends on
how the Guix community responds to such a proposal.

But the proposal to move our Git hosting to Codeberg does not need to
include every proposal that is related to Git.

Re: bug#55231: [PATCH v1] initrd: Allow extra search paths with ‘initrd-extra-module-paths’

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

Hi all,

> I'm not sure if what I'm proposing would actually work.

How prophetic.

I did some more testing with the proposed change to `derivation`, and it seems 
to be causing a weird issue. I didn't think that propagating 
non-substitutability would be much of a problem, since there are very few 
non-substitutable packages, but I was surprised to find that this change makes 
almost all packages non-substitutable! I did some REPL-ing to find the culprit, 
and it when I traced it back, I found that all of my non-substitutable 
derivations appeared to be so because their dependency graph included a 
derivation called `# 
/gnu/store/d69awcc5wahh71amx0dmgaimsdvvp2bg-gcc-11.4.0-lib 7fc7c9bb99b0>`.

Unfortunately, I cannot for the life of me figure out what this derivation is, 
or why it isn't substitutable (all of its inputs are substitutable, and I can't 
find any relevant package explicitly marked as non-substitutable). I wonder if 
maybe it has something to do with the `gnu-build-system`? It appears to be an 
input of `bash-minimal`, which is what leads me to that suspicion. If I could 
figure out what this derivation is and why it's non-substitutable, I think that 
the change that the proposed change to `derivation` would work (and, in some 
sense, implement what ought intuitively to be the default behaviour, as Brian 
noted).

Any and all relevant thoughts would be much appreciated.

Best,

Morgan

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Suhail Singh]

Liliana Marie Prikler  writes:

>> I think this is just a matter of image, and I'm not sure about who
>> are we trying to please with the change.
> Since I was the one to initially make this suggestion: myself, plus
> whoever agrees with me, regardless of their reason.

...

> As a gesture towards inclusion, the change is probably symbolic at
> best, but not even doing that for dubious reasons will leave us in the
> past indefinitely.

I am not arguing on whether the branch name should be changed or not.
However, I do think this is a topic that should be discussed in a GCD.
I do not have an opinion on whether it's better to do it as part of the
Codeberg GCD or separately.  That's a decision that's perhaps best left
to Liliana and Ludo (and others, in case there were co-authors I've
accidentally omitted).

However, not discussing this via a GCD would go against its intended
use:

#+begin_quote
  The GCD process is intended to provide a consistent and structured way
  to propose, discuss, and decide on major changes affecting the
  project.  It aims to draw the attention of community members on
  important decisions, technical or not, and to give them a chance to
  weigh in.
#+end_quote

Given that it would affect users' workflow, I believe this change would
qualify as a major change.  And the importance of a decision made on
this topic is made no less important from the benefits being symbolic.
Symbols can be important as well.

-- 
Suhail

Re: [GCD] Migrating repositories, issues, and patches to Codeberg

[Hartmut Goebel]

Am 12.02.25 um 11:23 schrieb Giovanni Biscuolo:

so if I understand correctly, all patch comments (rationale and all
related discussion) will be moved (stored) to Codeberg and guix-patches
will be dismissed?


Yes. This will be a side-effect of commenting in a

Anyhow, you can "watch" the repos and "you will receive emails for every 
change (creation of issues, pull requests, comments, etc.) done in this 
repository." This might become many and there is a issue for refining this.


One can also "watch" single issues or pull-request (patches).

--
Regards
Hartmut Goebel

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

Re: Welcoming Steve as a new committer!

[Tobias Geerinckx-Rice]

Steeeve!

Welcome, Steve.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

Re: scilab graphical version

[Nicolas Graves]

I haven't tried to package it, but the issue might probably be that the
java environment in Guix is pretty poor, there's most likely a lot of
work before we can package the Scilab GUI.

That said, I haven't even tried, so maybe it's less difficult than I
expect!  Don't hesitate to take a look if you have some time for that :)

-- 
Best regards,
Nicolas Graves