Re: Merging ‘staging’?

2022-06-13 Thread Thiago Jung Bauermann


Hello,

Ludovic Courtès  writes:

> Hello Guix,
>
> Ludovic Courtès  skribis:
>
>> Which means I’ll merge ‘staging’ in ‘master’ tomorrow morning if nothing
>> has collapsed by then.  :-)
>
> Merged, enjoy!  :-)

Nice!

> Thanks to everyone who helped on the way!

Thank you for merging the branch!

> Next up: release and ‘core-updates’.

Exciting times. :-)

-- 
Thanks
Thiago



Re: Teams

2022-06-13 Thread raingloom
I'd definitely love to see an A/V or graphics production team, making
Guix more suitable for artists has been on my TODO list for a while,
even made some tentative steps towards packaging Blender addons.
Personally, I'd love to help out with testing and/or developing Blender
stuff.

On Mon, 13 Jun 2022 13:38:16 +
Blake Shaw  wrote:

> Hi folks,
> 
> I'm just getting back to the list after finishing a gig, but want to
> raise my hand to join both the scheme team and perhaps something like
> an A/V team if folks think that would be a desirable team to put
> together. I think an A/V team would look after:
> 
> #+begin_example scheme
>  (gnu packages gstreamer)
>  (gnu packages gl) ;; Maybe games could handle this?
>  (gnu packages video)
>  (gnu packages graphics)
>  (gnu packages music)
> #+end_example
> 
> Which is quite a lot! So maybe some of this should be split up with
> the "games" team.
> 
> On another note, I'll be getting back to the Guile Docs soon, and
> before that I plan on taking a stab at refactoring the patch
> submission criteria, which I think could use some work. As it is
> currently, it personally becomes a hurdle of a checklist when I want
> to quickly submit a patch, which has lead me to running a hotfix
> branch so that I can quickly fix an issue and move on, therefore
> contributing what I should be. I think it could express all the same
> requirements in less rules, making it easier to ensure what you're
> handing in is in order. But I still need to take a stab at it and see.
> 
> Best,
> 
> On Fri, Jun 10, 2022, 03:29 Arun Isaac 
> wrote:
> 
> >
> > Hi Guix,
> >
> > I like the idea of teams. And, it's nice to see so many volunteers
> > raise their hands!
> >  
> > > * Rust team
> > > Efraim Flashner
> > > Aleksandr Vityazev
> > > Arun Isaac
> > > John Soo
> > > Maxim Cournoyer
> > > Nicolas Goaziou
> > > Tobias Geerinckx-Rice  
> >
> > However, I know very little about Rust, and I'm not a good fit for
> > this team. I could easily be a part of the python, emacs lisp,
> > common lisp, scheme teams, etc if necessary.
> >
> > But, what I'd really like is to be part of a mumi+tooling team.
> > Maybe we should have such a team?
> >
> > Also, since we have so many ideas for teams, can we have some
> > structured way to suggest teams, and add or remove them as needs
> > change?
> >
> > Regards,
> > Arun
> >
> >  




Rust and Python Together Forever With Guix

2022-06-13 Thread jgart
Hi Guixers,

Have any packages been packaged that are a muli language codebases of rust and 
python like this one:

https://github.com/samuelcolvin/rtoml

This is how nix packages the above:

https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/python-modules/rtoml/default.nix#L59

Any advice here or references to existing guix packages that handle rust and 
python together is much appreciated.

all best,

jgart



Celebrating 10 years of Guix in Paris, Sep. 16–18

2022-06-13 Thread Ludovic Courtès
We’re excited to inform you that we’re organizing a three-day conference
to celebrate 10 years of Guix and to share knowledge and enthusiasm!

  https://guix.gnu.org/en/blog/2022/celebrating-10-years-of-guix-in-paris/

The event will take place in Paris, France, Sep. 16th through 18th and
you can already register on-line:

  https://10years.guix.gnu.org/

Check out the web site for more info and stay tuned for updates!

Ludovic Courtès, Tanguy Le Carrour, and Simon Tournier.


signature.asc
Description: PGP signature


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

2022-06-13 Thread Giovanni Biscuolo
Hi Maxime

Maxime Devos  writes:

> Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]:
>> Maxime I have a question for you please: do you really think that in
>> the NixOS community
>
> Going by the Java example, yes, at least for some of the NixOS
> community.  I've also seen this interpretation of reproducibility in
> Clojure (there was some question on building things from source and
> reproducibility, and the response was something along the line ‘using
> upstream binaries is 100% reproducible’).

Ouch!  It hurts so much ;-(

[...]

>> P.S.: or you Maxime are just playng the devil's advocate? :-D
>
> No, I'm not advocating that trivial reproducibility is useful or the
> goal or such.  My response was some speculation on an answer to the
> following question:
>
>> but it's impossible to me to understand how a packaged upstream jar
>> can be considered reproducible (and bootstrappable);

OK OK, now I understand, I did not imagine there's still this kind of
interpretation about reproducible builds in some groups of
developers/maintainers


Thanks!  Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature


Re: Teams

2022-06-13 Thread Blake Shaw
Hi folks,

I'm just getting back to the list after finishing a gig, but want to raise
my hand to join both the scheme team and perhaps something like an A/V team
if folks think that would be a desirable team to put together. I think an
A/V team would look after:

#+begin_example scheme
 (gnu packages gstreamer)
 (gnu packages gl) ;; Maybe games could handle this?
 (gnu packages video)
 (gnu packages graphics)
 (gnu packages music)
#+end_example

Which is quite a lot! So maybe some of this should be split up with the
"games" team.

On another note, I'll be getting back to the Guile Docs soon, and before
that I plan on taking a stab at refactoring the patch submission criteria,
which I think could use some work. As it is currently, it personally
becomes a hurdle of a checklist when I want to quickly submit a patch,
which has lead me to running a hotfix branch so that I can quickly fix an
issue and move on, therefore contributing what I should be. I think it
could express all the same requirements in less rules, making it easier to
ensure what you're handing in is in order. But I still need to take a stab
at it and see.

Best,

On Fri, Jun 10, 2022, 03:29 Arun Isaac  wrote:

>
> Hi Guix,
>
> I like the idea of teams. And, it's nice to see so many volunteers raise
> their hands!
>
> > * Rust team
> > Efraim Flashner
> > Aleksandr Vityazev
> > Arun Isaac
> > John Soo
> > Maxim Cournoyer
> > Nicolas Goaziou
> > Tobias Geerinckx-Rice
>
> However, I know very little about Rust, and I'm not a good fit for this
> team. I could easily be a part of the python, emacs lisp, common lisp,
> scheme teams, etc if necessary.
>
> But, what I'd really like is to be part of a mumi+tooling team. Maybe we
> should have such a team?
>
> Also, since we have so many ideas for teams, can we have some structured
> way to suggest teams, and add or remove them as needs change?
>
> Regards,
> Arun
>
>


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

2022-06-13 Thread Arun Isaac


Hi Giovanni,

Rather than any specific criticism of our workflow, my point was that
there are many little things to keep in mind when reviewing patches, and
this makes it demanding. I am pretty happy with Guix's rigorous coding
standards, and am not suggesting we abandon them.

Cheers! :-)
Arun



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

2022-06-13 Thread Maxime Devos
Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]:
> Maxime I have a question for you please: do you really think that in
> the NixOS community

Going by the Java example, yes, at least for some of the NixOS
community.  I've also seen this interpretation of reproducibility in
Clojure (there was some question on building things from source and
reproducibility, and the response was something along the line ‘using
upstream binaries is 100% reproducible’).

>  (or any other project mentioned in
> https://reproducible-builds.org/who/projects/) the term reproducible
> is
> interpreted in that way?

I don't know about all of them, but for Guix and Debian: no.

> IMVHO if we continue using the term reproducible in that trivial way
> [3]
> when talking about software (this include each and every scientific
> paper [4]), we will never get to any point; reproducible is what
> reproducible means: https://reproducible-builds.org/docs/definition/

Exactly, trivial interpretations aren't really the point, because
trivial.

> [...]
> I was just hoping that nowadays "reproducible" is perceived as "build
> reproducible" (as defined in the definition above) by all software
> developers and many users (including scientists)

I'd hope so, yes.

> P.S.: or you Maxime are just playng the devil's advocate? :-D

No, I'm not advocating that trivial reproducibility is useful or the
goal or such.  My response was some speculation on an answer to the
following question:

> but it's impossible to me to understand how a packaged upstream jar
> can be considered reproducible (and bootstrappable);


signature.asc
Description: This is a digitally signed message part


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

2022-06-13 Thread Giovanni Biscuolo
Hi Maxime and all,

I'm so sorry this discussion is shifting to the actual meaning of
reproducible... especially since Maxime and many of us know it very well

I'm sure 95% of people I know would not understand me if I tell them
that their software should be reproducible, they should study a little
bit (effort) what software is to really understand what I mean... or
Just Trust Us™

Maxime Devos  writes:

[...]

> It's ‘reproducible’ in the trivial sense that you can ‘reproduce’ a
> scientific paper by putting it a photocopier.

Maxime I have a question for you please: do you really think that in the
NixOS community (or any other project mentioned in
https://reproducible-builds.org/who/projects/) the term reproducible is
interpreted in that way?

That's not reproducible in this context [1] (I mean software
reproducibility), or to be unambiguous we should always use "build
reproducible" instead of "reproducible" so we amost recall some context
[2]?

IMVHO if we continue using the term reproducible in that trivial way [3]
when talking about software (this include each and every scientific
paper [4]), we will never get to any point; reproducible is what
reproducible means: https://reproducible-builds.org/docs/definition/

I was just hoping that nowadays "reproducible" is perceived as "build
reproducible" (as defined in the definition above) by all software
developers and many users (including scientists)

... the same holds for "bootstrappable" (in this context)


Happy Hacking!  Gio'

P.S.: or you Maxime are just playng the devil's advocate? :-D



[1] context is what defines the meaning of symbols ;-)

[2] build what?

[3] scan and print (aka copy) and distribute the compiled binary
artifact

[4] is it software even if not always expressed in a programming
language? (my guess is yes)

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature


Re: Merging ‘staging’?

2022-06-13 Thread Ludovic Courtès
Hello Guix,

Ludovic Courtès  skribis:

> Which means I’ll merge ‘staging’ in ‘master’ tomorrow morning if nothing
> has collapsed by then.  :-)

Merged, enjoy!  :-)

Thanks to everyone who helped on the way!

Next up: release and ‘core-updates’.

Ludo’.