Re: About donation to GNU Guix project

[Maxim Cournoyer]

Hi Mert,

Mert Gör  writes:

> hi people !
>
> I want to learn if I can donate hardware(server and other hardware for
> GNU Guix infrastructure) or donate with some money if they all
> possible I'll be happy
>
> happy hacking !
>
> hwpplayer1 on Libera.chat

Donating hardware is a bit tricky because it needs to be hosted
somewhere, but it can be discussed and welcome, especially if the
hosting can also be provided somehow (we have a couple machines running
in people's home connecting via a WireGuard tunnel to the build farm
from which we can get packages built via Cuirass).

Money is easy to keep for when it is needed.  It gets spent on various
things such as hardware replacements (e.g. SSDs), hosting fees, Guix
events, etc.

There are at least two places you can donate money two:

1. Free Software Foundation (FSF):
https://my.fsf.org/civicrm/contribute/transact?reset=1&id=50

2. Guix Europe
http://foundation.guix.info/

I'm actually not sure how donating to Guix Europe works (I know you can
become a member for a small fee), but you could ask for the bank account
number and wire the funds there.

I'd use the one closest to you geographically, as the processing costs
(e.g. the cost of a wire transfer) should be lower.  The FSF does take a
10% cut on any new deposit, but I that's fair since they provide the
Guix project with valuable services such as the Savannah hosting and
Debbugs service, mailing lists, etc. (on top of their excellent mission
to spread the word and defend free software).

-- 
Thanks,
Maxim

Re: Changes to the branching/commit policy

[Maxim Cournoyer]

Hi Christopher,

Christopher Baines  writes:

> Andreas Enge  writes:
>
>> thanks for taking up this issue! I agreed with Ludovic's comments, so
>> things look good now for me. A very minor point: In the section on
>> "trivial" changes, I would drop this sentence (which was already there
>> before):
>> "This is subject to being adjusted, allowing individuals to commit directly
>> on non-controversial changes on parts they’re familiar with."
>> The sentence is meaningless, as everything is all the time subject to being
>> adjusted; and we do not have immediate plans to adjust it.
>
> My reading of this line is that "adjusted" is probably not the right
> word to use, but I think the intent here is to talk about how currently
> it's accepted that people can and will push non-controversial changes on
> parts they’re familiar with directly to master.
>
> I'm not sure if others read this similarly.

That's how I read it as well.  I like the ability for people to, at
times depending on the situation, choose to push directly to fix or
update something instead of going through the otherwise recommended 1
week QA/review flow.

-- 
Thanks,
Maxim

Re: rust-build-system from antioxidant

[Maxim Cournoyer]

Hi Maxime,

Maxime Devos  writes:

> Op 02-06-2023 om 20:02 schreef Nicolas Graves:
>> A few months ago, Maxime Devos worked on a new rust-build-system to
>> handle a few issues we were experiencing with cargo (see discussions on
>> antioxidant in guix-devel).
>> A month ago, we discussed about the possibility of the integration
>> in
>> core guix, and the required steps. Maxime and I had a different
>> approach. Maxime highlighted the possibility to make a smooth transition
>> but once that would require many gradual changes and deprecation. My
>> approach was that since we'll have to eventually migrate all packages to
>> rust-build-system, and since we can freeze all former rust packages in
>> an archive channel, I would be clearer to make the transition at once.
>> [...]
>
> Actually, I started out with the non-gradual approach, but that was
> overruled by Ludo', IIRC.

Did you perhaps meant to say that it was disagreed with, or at worst
"blocked by"?  There should not be a notion of 'overruling' in our
contribution processes (unless the Guix co-maintainers have to step in
as a last resort) if all participants strive to build consensus, as
mentioned in info '(guix) Commit Access':

   It is expected from all contributors, and even more so from committers,
   to help build consensus and make decisions based on consensus.  To learn
   what consensus decision making means and understand its finer details,
   you are encouraged to read
   .

I thought I knew what consensus meant myself, but the above link helped
me to re-frame a few things in a way that is more conducive to building
consensus.

-- 
Thanks,
Maxim

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

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

Hi Maxim,

On Sun, Jun 11, 2023 at 5:48 PM Maxim Cournoyer
 wrote:
>
> When you rewrite the
> history (by using rebase, say), the existing signatures of the rewritten
> (rebased) commits are replaced with new ones generated from your key.

That was probably a misunderstanding. I meant to suggest with some
trepidation that 'master' is merged into the feature branch, and then
the feature branch is merged back into 'master'. I thought the two
merge commits would be signed by the person performing the merges
while the "origin seal" of the accepted change is also preserved.

Please forgive me. I merely hoped to find common ground but apparently
added confusion rather than clarity.

Kind regards
Felix

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Maxim Cournoyer]

Hi Felix,

Felix Lechner  writes:

> Hi Maxim,
>
> On Sun, Jun 11, 2023 at 2:26 PM Maxim Cournoyer
>  wrote:
>>
>> rebasing causes the PGP-signed commits to be resigned with the key of
>> the people of does the rebase, which obfuscates the origin seal
>> somewhat.
>>
>> I think we should continue to prefer merging
>
> Let's take your argument all the way for a moment, please. What if the
> signed merge commits were to serve as the mutual approvals Ludo' has
> been asking for?

I'm not sure how that'd work, since Git only allows a single PGP
signature per commit, as far as I can tell.  When you rewrite the
history (by using rebase, say), the existing signatures of the rewritten
(rebased) commits are replaced with new ones generated from your key.

-- 
Thanks,
Maxim

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

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

Hi Maxim,

On Sun, Jun 11, 2023 at 2:26 PM Maxim Cournoyer
 wrote:
>
> rebasing causes the PGP-signed commits to be resigned with the key of
> the people of does the rebase, which obfuscates the origin seal
> somewhat.
>
> I think we should continue to prefer merging

Let's take your argument all the way for a moment, please. What if the
signed merge commits were to serve as the mutual approvals Ludo' has
been asking for?

Non-forward merges could also be used for changes involving just a
single commit, although that would create more overhead and result in
a more complicated project history.

Kind regards
Felix

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Maxim Cournoyer]

Hi Andreas,

Andreas Enge  writes:

> Hello,
>
> Am Sat, Jun 10, 2023 at 11:17:44PM -0400 schrieb Maxim Cournoyer:
>> > That to me says this should go to staging.
>> Correct.  Except there's no staging branch anymore.  I guess we should
>> create one?  :-)
>
> I would say it should go to a team branch; xsystem?
>
> Regardless of name, I think the idea behind the team branch concept is
> that a branch should regroup related changes (as much as possible), but
> in any case there should be an identified person or group of persons taking
> responsibility for shepherding the branch up to its merge; and for repairing
> potential breakage. So we could extend the concept to have a
> june-2023-disruptive-changes branch, with the aim of regrouping several
> maybe unrelated changes leading to bigger rebuilds (and identified
> responsibilities). We should not create a random branch where lots of big
> changes accumulate for which nobody takes responsibility.
>
> The changes suggested at
>https://issues.guix.gnu.org/63459
> remove the staging and core-updates branches from the documentation.
> Does it leave open problems behind?
>
> One thing I wonder about is whether we should not rebase all team branches
> on master instead of merging master back in. In this way, at least the
> commits specific to a branch would be visible since they are on top; with
> the former merging concept of staging and core-updates, they would end up
> buried deep in the commit history. It could also help keeping changes
> focused. What do you think?

Rebasing only really works if a single person works on the branch, since
it rewrites history.  So it doesn't seem very team friendly.  Also,
rebasing causes the PGP-signed commits to be resigned with the key of
the people of does the rebase, which obfuscates the origin seal
somewhat.

I think we should continue to prefer merging, but minimizing this to
only when it's truly required, as Linus suggests for branches
maintainers (where it's suggested to not sync with the main branch to
avoid getting unrelated/untested changes).  If the branches are
short-lived that shouldn't be (common) problem anyway.

What do you think?

-- 
Thanks,
Maxim

Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.

[Maxim Cournoyer]

Hi,

Christopher Baines  writes:

> Maxim Cournoyer  writes:
>
>> Hi Christopher,
>>
>> Christopher Baines  writes:
>>
>>> guix-comm...@gnu.org writes:
>>>
 apteryx pushed a commit to branch master
 in repository guix.

 commit ec9f15b158300da3a77ce02cd2267222f435e80f
 Author: Maxim Cournoyer 
 AuthorDate: Tue Jun 6 12:12:40 2023 -0400

 gnu: wxwidgets: Add libxtst to inputs.

 WxWidgets was already built with XTest support, but mostly by luck, via
 propagation of libxtst from GTK's propagated at-spi2-core package.  
 Make it an
 explicit input.

 * gnu/packages/wxwidgets.scm (wxwidgets) [inputs]: Add libxtst.
 ---
  gnu/packages/wxwidgets.scm | 1 +
  1 file changed, 1 insertion(+)
>>>
>>> Did this need to go straight to the master branch?
>>>
>>> → guix refresh -l wxwidgets
>>> Building the following 217 packages would ensure 456 dependent packages are 
>>> rebuilt: ...
>>>
>>> That to me says this should go to staging.
>>
>> Correct.  Except there's no staging branch anymore.  I guess we should
>> create one?  :-)
>
> You're the second person to mention this. I guess I view the branch not
> existing as a minor technical detail that doesn't really change what
> you'd do.

I remember we were very happy to get rid of the staging branch last time
we managed to merge it -- I was naively hoping we'd have ironed out the
new team-based branching processes soon enough to not have to recreate
staging/core-updates anew; I guess I'm not alone :-).

Which reminds me, I need to take a look at
https://issues.guix.gnu.org/63459, which I'll try to do soon.

-- 
Thanks,
Maxim

Re: Draft new Guix Cookbook section on Emacs

[Remco]

Hi Mekeor,

2023/06/04 23:32, Mekeor Melire:

>  Geiser Guile Load Path
>
> If you maintain a local clone of the Guix source code repository, it
> already contains a =.dir-locals.el= file which ensures that the path
> of your local clone is added to ~geiser-guile-load-path~ whenever you
> open a Scheme file in there. But nevertheless, it makes sense to add
> the path to your local Guix repository to ~geiser-guile-load-path~ in
> your Emacs initialization file so that it's set correctly in other
> directories as well.
>
> Make sure that the compiled files in your local Guix repository are
> up-to-date. I.e. whenever your local working directory of the
> repository changes (for example, after running ~git pull~), rebuild
> Guix as described in the Guix manual. Otherwise, Guile would
> auto-compile all Guix sources which leads to misconfiguration[fn:1]
> and likely hits Geiser's timeout. Consider having two Git worktree of
> the Guix repository, keeping one always compiled.
>
> If you have other Guix-related source code directories on your machine
> (and you want to load Guile modules from there), you need to put those
> in the ~geiser-guile-load-path~ variable. (Geiser will then add those
> paths to Guile's ~%load-path~ and ~%load-compiled-path~ variables.)
>
> #+begin_src elisp
> (setq geiser-guile-load-path
>   (list
> "~/src/guix"
> "~/src/some/channel"))
> #+end_src

For editing my manifests, guix.scm, system.scm, etc. files I'm using
"~/.config/guix/current/share/guile/site/3.0" for
geiser-guile-load-path.  This automagically includes the foreign
channels I've configured at their current version and works pretty well
for me.

Thanks for sharing!

Cheers,
Remco

About donation to GNU Guix project

[Mert Gör]

hi people !

I want to learn if I can donate hardware(server and other hardware for 
GNU Guix infrastructure) or donate with some money if they all possible 
I'll be happy


happy hacking !

hwpplayer1 on Libera.chat

Mert Gör

Rust cross-compilation support.

[Jean-Pierre De Jesus Diaz]

Hello,

I'd like to use GNU Guix to build embedded software using Rust.

Currently I'm thinking of using GNU Guix and Rust for embedded
development but currently Rust does not support cross-compilation
as libstd is only compiled for the "host" target.

I was thinking that GNU Guix could provide a separate package
(or output) containing those targets like rustup does.  This could
also enable cross-compilation support in cargo-build-system (or
antioxidant).

The thing is that I haven't found an efficient way of doing it since
building libstd/libcore for another target requires re-building rustc
again.  So using a freshly built rust package as the input for another
rust-extra-targets package loses any potential benefit.

Maybe the same Rust package can build a select list of tier-1/2/3
targets and add a new output containing those.  But that approach
would slow down the build of the rust package.

Do you people see any other solutions to this?

FWIW I've managed to compile libcore for thumbv7em-none-eabihf with:

--8<---cut here---start->8---
(define-public rust-with-targets
  (package
(inherit rust)
(name "rust-with-targets")
(arguments
  (substitute-keyword-arguments (package-arguments rust)
((#:phases phases)
  `(modify-phases ,phases
 (add-after 'configure 'add-targets-to-config
   (lambda* (#:key inputs #:allow-other-keys)
 (let ((arm-gcc (assoc-ref inputs
"gcc-cross-sans-libc-arm-none-eabi"))
   (arm-binutils (assoc-ref inputs
"binutils-cross-arm-none-eabi")))
 (substitute* "config.toml"
   (("^python =.*" all)
(string-append all
   "target = [
  \"" ,((@@ (gnu packages rust) nix-system->gnu-triplet-for-rust)) "\",
  \"thumbv7em-none-eabihf\",
]\n"))
   (("^ar =.*" all)
(string-append all
   "[target.thumbv7em-none-eabihf]
ar = \"" arm-binutils "/bin/arm-none-eabi-ar\"
cc = \"" arm-gcc "/bin/arm-none-eabi-gcc\"
cxx = \"" arm-gcc "/bin/arm-none-eabi-g++\"
no-std = true\n"))
 ;; Rust tries to compile std for thumbv7em-none-eabihf but that
 ;; does not work as the target does not have a std
implementation.
 ;;
 ;; Maybe this can worked around by only testing for the host
 ;; architecture and compiling tests for libcore only for
 ;; thumbv7em-none-eabihf, but I don't know if that's possible.
 (delete 'check)
(native-inputs
  (modify-inputs (package-native-inputs rust)
(append (cross-binutils "arm-none-eabi"))
(append (cross-gcc "arm-none-eabi"))
--8<---cut here---end--->8---

Cheers,

—
Jean-Pierre De Jesus DIAZ

Re: Changes to the branching/commit policy

[Andreas Enge]

Am Sun, Jun 11, 2023 at 10:37:14AM +0100 schrieb Christopher Baines:
> My reading of this line is that "adjusted" is probably not the right
> word to use, but I think the intent here is to talk about how currently
> it's accepted that people can and will push non-controversial changes on
> parts they’re familiar with directly to master.

I read it the other way round: Right now it is not accepted, but it might
be adjusted to allow non-controversial changes in the future. Actually
the concept of "non-controversial commits" is probably controversial
in itself...

Andreas

Re: Changes to the branching/commit policy

[Christopher Baines]

Andreas Enge  writes:

> thanks for taking up this issue! I agreed with Ludovic's comments, so
> things look good now for me. A very minor point: In the section on
> "trivial" changes, I would drop this sentence (which was already there
> before):
> "This is subject to being adjusted, allowing individuals to commit directly
> on non-controversial changes on parts they’re familiar with."
> The sentence is meaningless, as everything is all the time subject to being
> adjusted; and we do not have immediate plans to adjust it.

My reading of this line is that "adjusted" is probably not the right
word to use, but I think the intent here is to talk about how currently
it's accepted that people can and will push non-controversial changes on
parts they’re familiar with directly to master.

I'm not sure if others read this similarly.


signature.asc
Description: PGP signature

Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi Christopher,
>
> Christopher Baines  writes:
>
>> guix-comm...@gnu.org writes:
>>
>>> apteryx pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit ec9f15b158300da3a77ce02cd2267222f435e80f
>>> Author: Maxim Cournoyer 
>>> AuthorDate: Tue Jun 6 12:12:40 2023 -0400
>>>
>>> gnu: wxwidgets: Add libxtst to inputs.
>>>
>>> WxWidgets was already built with XTest support, but mostly by luck, via
>>> propagation of libxtst from GTK's propagated at-spi2-core package.  
>>> Make it an
>>> explicit input.
>>>
>>> * gnu/packages/wxwidgets.scm (wxwidgets) [inputs]: Add libxtst.
>>> ---
>>>  gnu/packages/wxwidgets.scm | 1 +
>>>  1 file changed, 1 insertion(+)
>>
>> Did this need to go straight to the master branch?
>>
>> → guix refresh -l wxwidgets
>> Building the following 217 packages would ensure 456 dependent packages are 
>> rebuilt: ...
>>
>> That to me says this should go to staging.
>
> Correct.  Except there's no staging branch anymore.  I guess we should
> create one?  :-)

You're the second person to mention this. I guess I view the branch not
existing as a minor technical detail that doesn't really change what
you'd do.

Maybe we need to do more in the guidance to reassure people though, you
should still push to a branch if that's what you should do, even if that
branch doesn't currently exist on the remote. This situation will
probably come up more often in the case of team branches.


signature.asc
Description: PGP signature

Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Andreas Enge]

Hello,

Am Sat, Jun 10, 2023 at 11:17:44PM -0400 schrieb Maxim Cournoyer:
> > That to me says this should go to staging.
> Correct.  Except there's no staging branch anymore.  I guess we should
> create one?  :-)

I would say it should go to a team branch; xsystem?

Regardless of name, I think the idea behind the team branch concept is
that a branch should regroup related changes (as much as possible), but
in any case there should be an identified person or group of persons taking
responsibility for shepherding the branch up to its merge; and for repairing
potential breakage. So we could extend the concept to have a
june-2023-disruptive-changes branch, with the aim of regrouping several
maybe unrelated changes leading to bigger rebuilds (and identified
responsibilities). We should not create a random branch where lots of big
changes accumulate for which nobody takes responsibility.

The changes suggested at
   https://issues.guix.gnu.org/63459
remove the staging and core-updates branches from the documentation.
Does it leave open problems behind?

One thing I wonder about is whether we should not rebase all team branches
on master instead of merging master back in. In this way, at least the
commits specific to a branch would be visible since they are on top; with
the former merging concept of staging and core-updates, they would end up
buried deep in the commit history. It could also help keeping changes
focused. What do you think?

Andreas