Re: `make check` fails when trying to build from Git

[Steve George]

On  4 May, Ashvith Shetty wrote:
> I've been looking forward to contributing some packages to Guix, but so
> far, I've not been able to figure out from the manual, so I'm going through
> the entire Contributing
>  section.
> 
> So far, after the `guix shell -D guix -CPW` command, I've reached the `make
> check` part, where the tests fail. What logs should I share, so that I can
> make it easier for people to check out the issue that's stopping me from
> progressing?
(...)

Hi Ashvith - are you building the master branch with a recent checkout?

I also get some FAILS, but not as many as you.

You can probably continue and if the ./pre-inst-env guix command works then you 
can continue to package.

The manual has a section on how to investigate the test failures: if you have 
alook at those there may be clues and you can create issues with a proper log 
at that point.

Best,

Steve / Futurile

Patch review session tomorrow (Friday) / Patches to review

[Steve George]

Hi,

The next patch review session is tomorrow - Friday 3rd May - would love to see 
you there!

17:00 UTC; 18:00 BST (London); 19:00 CEST (Paris); 13:00 EDT (New York)

Details on the Wiki [0] - Jiti URL is: 

  https://meet.jit.si/london-guix-meetup

If you are a committer there are some patches that have been reviewed that 
could be reviewed/signed-off if appropriate:

https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=reviewed-looks-good;users=guix

There are also some 'escalated' ones which would benefit from experiened 
contributors looking at: 

https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=escalated-review-request;users=guix

Cheers,

Steve / Futurile

[0] https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

Re: Core updates status

[Steve George]

Hi,

On 25 Apr, Kaelyn wrote:
> Hi,
> 
> On Tuesday, April 23rd, 2024 at 11:08 PM, Steve George  
> wrote:
(...)
> > - guile-rsvg failing
> > - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70537
> > - I'm able to build librsvg@2.56.4 but not guile-rsvg
> > - guile-rsvg@2.18.1 / guile2.2-rsvg
> > - guile-rsvg builds on master - connected?
> 
> I've started looking at this build failure this morning, and my initial 
> impressions are that a propagated-input is missing. I tried building 
> guile-rsvg from core-updates and the build failed with three missing pango 
> libraries (ld could not find -lpangocairo-1.0, -lpangoft2-1.0, and 
> -lpango-1.0). I tried moving pango from the inputs to the propagated-inputs 
> for librsvg, and that fixed the build of guile-rsvg. I'm just not sure if 
> that is the right place to propagate it; I haven't yet traced where the pango 
> libraries are being added to the linking command, as I've checked the 
> pkgconfig files for librsvg, cairo, and a couple of other packages and not 
> seen references to pango (which is what makes me think the pango 
> propagated-input is needed elsewhere, and not actually in librsvg--but I also 
> don't know Rust or what dependencies the rust code in librsvg has).

That's great, thanks for taking a look. Efraim mentioned that there would be 
Rust changes for it.

Steve / Futurile

Re: Managing patches and branches, retrospective and futher changes?

[Steve George]

Hi,

I think we should strongly recommend against long-running unmerged branches.

Perhaps there could be a recommendation to merge every 3 months.

Could we add any automation to remind people if:

1. a branch has been unmerged for more than 3 months
2. an odd merge takes places (e.g. the core-updates merges)

Thanks,

Steve

On 24 Apr, Christopher Baines wrote:
> Hey!
> 
> Almost a year ago, the branching strategy was changed [1][2].
> 
> 1: https://issues.guix.gnu.org/63459
> 2: https://lists.gnu.org/archive/html/guix-devel/2023-06/msg00024.html
> 
> I think these changes have gone OK, we've had ~27 [3] branches merged in
> this manor and I think looking back these changes have been
> helpful. Coordination and visibility has improved, and we've been able
> to build and test more prior to merging.
> 
> 3: https://issues.guix.gnu.org/search?query=%22Request+for+merging%22
> 
> There's still room for more improvement though. The current guidance is
> here [4], and I've sent a patch for improvements here [5].
> 
> 4: 
> https://guix.gnu.org/en/manual/devel/en/html_node/Managing-Patches-and-Branches.html
> 5: https://issues.guix.gnu.org/70549
> 
> Let me know if you have any thoughts or questions!
> 
> Thanks,
> 
> Chris

Re: Core updates status

[Steve George]

Hi,

You just need to checkout core-updates and then 'start building'!

It would be good to confirm this one:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316

It looks like Zhen Junjie applied two patches to fix NSS cross-compilation on 
Master [0]

Maybe master and core-updates have diverged - I haven't had time to look.

To check for reproducibility do a normal build, and if that's successful do the 
same build with `--check`

Thanks,

Steve 

[0] 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fb86bf658a9374d41b05c5e586bfc6a3150cc3cb
 and 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=452e7673bfeb0a14cecb8e760dda2c436aa69047


On 24 Apr, Christina O'Donnell wrote:
> Hi Steve,
> 
> On 24/04/2024 07:08, Steve George wrote:
> > Hi,
> > 
> > We're trying to stabilise and merge core-updates, help definitely wanted!
> 
> I'd love to help! Any of these issues novice-friendly?
> 
> Will there be a point release after core-updates is merged?
> 
> Kind regards,
> 
> Christina
> 
> 

Core updates status

[Steve George]

Hi,

We're trying to stabilise and merge core-updates, help definitely wanted!

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70456

So far the main blockers are:

- guile-rsvg failing
  - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70537
  - I'm able to build librsvg@2.56.4 but not guile-rsvg
  - guile-rsvg@2.18.1 / guile2.2-rsvg
  - guile-rsvg builds on master - connected?

This blocks further progress 

What builds so far: 

  - gcc-toolchain and all the dependents from commencement.scm
  ./pre-inst-env guix build --no-substitutes gcc-toolchain

  - bunch of the basic - but blocked on guile-rsvg
  ./pre-inst-env guix system --no-substitutes vm 
gnu/system/examples/bare-bones.tmpl

Other potential issues:

- 45885  libpng non-deterministic build
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45885
  won't build due to block on pango - 

- 58719 [core-updates]: build failure for file on i686
  https://ci.guix.gnu.org/build/4057809/details

- 40316 [core-updates] Nss not reproducible
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40316
  confirmed 

- 68270  libstdc++-boot0.x86_64 is broken
  - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68270

- 39415  [core-updates] Removing SSL patches in CMake and Kodi - help wanted
- check if they are there and remove?
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39415


This is building from  4a0e6e3895cefe7c2999c22e56fe9b3dbca97f55 which includes 
the last merge from master.

Thanks,

Steve

Online social and patch review session on Monday

[Steve George]

Hi,

Our next online social and patch review session is on Monday (15th April):

  17:00 UTC; 18:00 London; 19:00 Paris; 13:00 New York

Please come along if you'd like to hangout and chat about Guix, and/or if you'd 
like to do some patch reviews. The sessions are very informal and we can run 
multiple virtual rooms if people want to pair and do patch reviews together.

If you have *simple* patches suitable for new contributors to review that have 
been forgotten (e.g. QA isn't handling them), you can add them to the 
'patch-review-hackers-list':

https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=patch-review-hackers-list;users=guix

This is done through a usertag on debbugs, to add your issue send email to 
cont...@debbugs.gnu.org

Subject: 
Body:

user guix
usertag  + patch-review-hackers-list
quit

As usual all the details on the Wiki:

https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

Hope to see you there!

Steve / Futurile

Re: Status of ‘core-updates’

[Steve George]

On 10 Apr, Ludovic Courtès wrote:
> Hello!
> 
> Josselin Poiret  skribis:
> 
> > Disclaimer: I've been quite busy with work recently and haven't been
> > able to work on core-updates that much (having to build the world
> > locally doesn't help).
> 
> No problem.  We should find someone willing to pick up the coordination
> work for the coming month or so.  Any volunteer?  :-)
> 
> To be clear (but I guess it’s crystal clear to anyone who’s been around
> long enough :-)), what we need most is someone to keep track of changes,
> coordinate efforts, decide what goes in the branch and what’s postponed
> or moved to a separate branch, and send periodic (weekly) status updates
> over the course of a couple of months.  This can (and probably should)
> be done without doing any actual hacking on the branch.
(...)

This sounds like something I can do:

- track changes (in branch)
- co-ordinate blocking issues (in bug system)
- co-ordinate with people doing the actual work :-P
- send (periodic) weekly emails
- encourage shipping by minimising scope creep ;-)


Sounds like there's already agreement to revert the 'pkgconf' change and push a 
new branch without them which becomes 'core-updates'. Josselin on IRC I had the 
impression you were working on that?

Thanks,

Re: Coordinators for patch review session on Tuesday

[Steve George]

On  4 Apr, Christina O'Donnell wrote:
> Hi,
> 
> Thanks for your reply,
> 
> > 1. Changing the tag to reviewed-looks-good
> > 
> > It doesn't look like this worked. The way to do this is in the instructions 
> > are 4. 'Set a user tag' [0], probably the easiest way is to send an email 
> > (I do get funny results sometimes with my email client):
> > 
> > Subject: setting usertag on 65938
> > 
> > user guix
> > usertag 65938 + reviewed-looks-good
> > quit
> > 
> > The first line is important it has to be 'user guix' for it to appear on 
> > the patch review reports [1]. I think I messed up the instructions in the 
> > Wiki - you have to have a + in between the bug number and the tag you want 
> > to set (sorry about that). Please try again.
> 
> Ah I got it this time. I was missing the 'user guix'. I didn't read the wiki
> and tried to look it up from the debbugs documentation.
> 
> > This is really just a way of signalling that reviews are happening - so 
> > trying to keep us in sync. The usertags we're using are:
> > 
> > - patch-review-hackers-list
> > - under-review
> > - escalated-review-request
> > - waiting-on-contributor
> > - reviewed-looks-good
> If I change the patch quite a lot, should I mark it as
> 'escalated-review-request' instead of 'reviewed-looks-good'?

Since a maintainer will look at it anyway before it's committed, and you are 
going to 're-roll' it as a v2 (which they will see) I wouldn't bother. I've 
been using 'escalated-review-request' for (a) ones I see that are just too hard 
for me, (b) if I personally think there's some outstanding issue with the patch 
that I can't solve.

> 
> And should I remove them from the patch-review-hackers-list after I've
> responded

Yes please - if you remove it from that list, and you make yourself the owner 
then I hope we'll keep people co-ordinated!

> > The patch changes all look reasonable to me, you've already done a lot:
> Great, thanks! Good to know I'm doing things vaguely right!
> > 1. You should add a reviewed-by trailer:
> > Reviews are contributions from our community (and work!) so we should 
> > recognise them and add trailers. It also helps the maintainer know who did 
> > the review and therefore the level of confidence.
> > 
> > Basically just add 'Reviewed-by: A Person  - [2]
> Sure, do you want me resubmit these patches to add that?

No - I think you're all good, it looked they were both going to the build 
system last night.


> > It looks like your updated patch retriggered QA, so if you look here and 
> > the foolow the Data Service link on the right you can see it's building it:
> > 
> >https://qa.guix.gnu.org/issue/65938
> > 
> > The last step will be for a maintainer to see that it's built correctly, 
> > see your review and to apply it - great job for a first patch review!
> Wonderful! The first of many, I'm hoping.
(...)

Keep an eye on them in QA, and see if a maintainer sees them. If nothing 
happens after 10 days consider pinging on IRC.

Thanks,

Steve 

Re: Coordinators for patch review session on Tuesday

[Steve George]

Hi,

Comments below:

On 3 Apr, Christina O'Donnell wrote:
(...)
> Thank you for writing this up in so much depth! I've reviewed [1] and tried
> to tag it as reviewed-looks-good, though I don't think that has gone
> through. If you or someone else could take a look at it then I'd appreciate
> that. I plan on reviewing some more patches this evening.
> 
> Kind regards,
> Christina
> 
> [1] https://debbugs.gnu.org/cgi-bin/bugreport.cgi?users=guix;bug=65938
>

1. Changing the tag to reviewed-looks-good

It doesn't look like this worked. The way to do this is in the instructions are 
4. 'Set a user tag' [0], probably the easiest way is to send an email (I do get 
funny results sometimes with my email client):

Subject: setting usertag on 65938

user guix
usertag 65938 + reviewed-looks-good
quit

The first line is important it has to be 'user guix' for it to appear on the 
patch review reports [1]. I think I messed up the instructions in the Wiki - 
you have to have a + in between the bug number and the tag you want to set 
(sorry about that). Please try again.

This is really just a way of signalling that reviews are happening - so trying 
to keep us in sync. The usertags we're using are:

- patch-review-hackers-list
- under-review
- escalated-review-request 
- waiting-on-contributor
- reviewed-looks-good

The patch changes all look reasonable to me, you've already done a lot:

1. You should add a reviewed-by trailer:
Reviews are contributions from our community (and work!) so we should recognise 
them and add trailers. It also helps the maintainer know who did the review and 
therefore the level of confidence.

Basically just add 'Reviewed-by: A Person  - [2]

It looks like your updated patch retriggered QA, so if you look here and the 
foolow the Data Service link on the right you can see it's building it:

  https://qa.guix.gnu.org/issue/65938

The last step will be for a maintainer to see that it's built correctly, see 
your review and to apply it - great job for a first patch review!

Steve / Futurile

[0] 
https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024#Patch_review_process_-_CLI_tools
[1] 
https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024#Patch_review_states_and_reports
[2] 
https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024#10._Add_a_Reviewed-by_Trailer

Re: Coordinators for patch review session on Tuesday

[Steve George]

On  2 Apr, Christina O'Donnell wrote:
> Hi Steve,
> 
> I just wanted to say that I enjoyed the first one of these and I'm looking
> forward to today's session. I did want to go to the last session, but I lost
> track of time and missed it!
> 
> I'm a new contributor who's only sent a few patches up, but these sessions
> have been helpful for making contributing feel less intimidating. I haven't
> quite felt comfortable enough to review any patches on my own, so I do like
> the idea of pair-reviewing patches with someone who's a bit more
> experienced.
(...)

Hi Christina - thanks for coming along today - I hope it was useful.

There's good instructions on the Wiki on how to review patches:

https://libreplanet.org/wiki?title=Group:Guix/PatchReviewSessions2024

I would love feedback on how to improve them!

There's plenty of patches to review, I've been keeping a list of them for the 
patch review calls:

https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=patch-review-hackers-list;users=guix

And the wiki page references some other reports.

Please pick some patches and have a go - if you want someone else to look at 
them feel free to ping here or on IRC!

Thanks,

Steve / Futurile

Coordinators for patch review session on Tuesday

[Steve George]

Hi all,

The next patch-review session is taking place on Tuesday 2nd of March [0] and 
I'd love to try pair-programming where groups can actively work on some patch 
reviews.

Is anyone willing to 'co-ordinate' a pair programming session?

Last time I set-up a cloud host and installed Upterm (https://upterm.dev/) so 
that everyone could ssh into a session. We could run 4-5 simultaneous sessions 
where people could 'pair' to do patch reviews together. 

To co-ordinate a session I'll give you SSH access and there are instructions on 
how to launch the Upterm session. We have written instructions on some basic 
tools to do the patch reviews - and as Guix is installed for each user you can 
add your own ;-)

Anyone up for it?

I'm also collecting simple patches for review onto a list so they can be 
assigned to each group:

https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=patch-review-hackers-list;users=guix

Feel free to add simple issues there!

Thanks,

Futurile / Steve

[0] 
https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024#Patch_Review_Sessions_2024

Thanks for attending the first patch review session!

[Steve George]

Hi everyone,

Just wanted to say thanks to everyone who came along to Guix London's 
first patch review session!


Along with a special thanks to Andreas Enge for jumping in as our first 
committer showing how he reviews and answering a host of questions.


Arun, Chris, Fabio and I were really excited to see you all!

I hope you'll allow a little bit of chaos as it's the first time we've 
tried this - plus my 'robot voice' when I demo'd!


Next time we'll split into some breakout rooms much faster so that 
everyone can work together and help each other at the right level.


If you have time to dig-in and review some patches before next time, 
check out the 'step-by-step' instructions on the Wiki:


https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

Would love your feedback or edits.

There are also links to the patch-review-hackers-list list [0] and 
explanations of the other usertags reports.


Our next session is on Wednesday March 20th - this is a mixed session - 
if you're in London you can join Arun, Chris and Fabio in person. Or you 
can be virtual and with a robot voice, like me!


We're looking for feedback on how to make the sessions work for everyone 
- if you'd like to help in any way give us a shout!


Steve (on behalf of the Guix London team)

p.s. we haven't forgotten about the questions that were asked, we'll 
collect those together into an FAQ and add them to the wiki page.


[0] 
https://debbugs.gnu.org/cgi-bin/pkgreport.cgi?tag=patch-review-hackers-list;users=guix

Re: GSoC 2024

[Steve George]

Hi,

I had a couple of ideas - but would need help from someone to mentor

1. Moldable development in Guix
Exploratory REPL experience is one of the hall-marks of 'moldable' systems. 
This shortens the development cycle and improves the ability of users to 
explore Guix.

The best REPL experience today is through Emacs. We have a modern nREPL 
implementation that is compatible with Guile. This needs further development 
and the Guix client side improved.

* Develop a basic CLI Nrepl experience in guile-ares-rs 
(https://git.sr.ht/~abcdw/guile-ares-rs)
* Add further CLI REPL functions to Guix 
* Stretch goal to add a Guix / Guile Scheme nrepl support to Conjure 
(https://github.com/Olical/conjure/issues/549) 

This would need co-ordination with Andrew Tropin (abcw) and Oliver Caldwell 
(Olical), and some help from a Guix mentor. 

2. Improving Docker image output (guix pack)
Docker containers are a common deployment method for applications. While they 
may be good for deployment, they have weak reproducibilty which Guix solves. 
Docker containers generated by Guix for deployment are large compared to 
similar deployments using Nix or Alpine. The purpose of this project is to 
optimise the build and deployment pipeline in Guix.

* Examine the current 'guix pack' process for optimisations
* Optimise the build process to add docker specific capabilities like 
multi-stage builds
* Explore using grafts or masking to reduce final image size

** NOTE:** I know this is a bit weak - I don't know enough about this myself 
yet - is this even a good target - I think it's interesting for scientific 
computing?

3. Add sandboxing to guix packages
Improving the security for end-users by implementing optional sandboxing for 
desktop applications. The likes of Bubblewrap and Flatseal are available for 
Linux. There's some existing Nix prior-art that could be a good starting point 
(https://nixos.wiki/wiki/Firejail) and (https://sr.ht/~fgaz/nix-bubblewrap/)

* Figure out which of the available options is the most sustainable
* Integrate policys and implementation into high-profile packages
* Stretch would be to create a Guile native library / approach

Anyone interested in these - willing to mentor/co-mentor with me?

On  4 Mar, Gábor Boskovits wrote:
> Hello guix,
> 
> I coordinated with the GNU org admins, and we can still do this round,
> but we have to go fast to make this happen. I have already taken the
> initiative to try to get an ideas page up, now I would like to confirm
> if the mentors from last year are still available, and that the ideas
> are still valid.
> 
> Hereby I quickly collected the projects with the respective mentors,
> please pm me your availability:
> 
> Decentralized substitute distribution
> pukkamustard (pukkamustard [at] posteo [dot] net)
> attila.lendvai (ethswarm.org, scheme)
> 
> Robustify long-term support for Reproducible Research
> Simon Tournier (zimoun)
> 
> Develop a Web interface to configure Guix System
> Ludovic Courtès (civodul)
> 
> Trusted computing: Goblins for GNU Guix
> Christopher Webber, Ludovic Courtès and Pjotr Prins
> 
> Guix Data Service revision processing instrumentation and performance
> Christopher Baines
> 
> Guile based build-tool
> Pjotr Prins
> 
> GNU Guix system monitor
> Pjotr Prins
> 
> Booting via network
> Danny Milosavljevic
> 
> Syntax and semantics of systemd units in the Shepherd
> Ludovic Courtès (civodul)
> 
> GNUnet integration
> no mentor available
> 
> Adding modules in support of continuous integration to cuirass
> Ludovic Courtès (civodul)
> 
> Continue rewrite build daemon in Guile Scheme
> Ludovic Courtès (civodul)
> 
> I myself am available to co-mentor, and also to be the formal mentor
> in case someone does not feel like doing the official dance with
> Google. Currently I can commit to devoting two hours a week to this.
> 
> Regards,
> g_bor
> 

Patch review session tomorrow (Thursday 7th March)

[Steve George]

Hi,

A reminder that the first patch review session is happening tomorrow, Thursday 
7th March.

Who knows how many people will be there, or what level of experience everyone 
will have. We'll be learning what works as we try out these sessions.

Hopefully, Andreas Enge with his 'committer' hat on will be able to talk about 
how he reviews patches. I'm hoping we'll have some other experienced developers 
who will also be able to add their tips and tricks. If possible we'll break 
into groups - or just one big group - and everyone will start learning and 
doing reviews!

I've added a series of steps to do a review using plain CLI tools:

https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

For those that use Emacs, there is information in the manual or please add to 
the Wiki page.

You can register (on Meetup) through the Patch review page:

If you would just like to come along, it will be on this link:

https://meet.jit.si/london-guix-meetup

According to my current understanding of timezones it will be at:

18:00 UTC, 18:00 GMT (London), 19:00 CET (Paris), 13:00 EST (New York)

See you there!

Steve / Futurile

Re: Proposal to turn off AOT in clojure-build-system

[Steve George]

Hi,

I don't think I'm making any progress convincing you, and I'm not enjoying the 
interaction so I'm going to take a few days off from this thread.

I've tried to ask the Clojure community for a definitive expression of what 
they think Linux distributions should do with byte-compiled libraries. We'll 
see if there's a response, this is a public forum so feel free to chime in and 
express clearly your perpective:

  
https://clojureverse.org/t/should-linux-distributions-ship-clojure-byte-compiled-aot-or-not/10595/1

Thanks,

Steve / Futurile

On 22 Feb, Maxime Devos wrote:
> >> [...] 
> >> > But, I would like to draw attention to this thread on Clojureverse as 
> >> > the best source I could find:
> >> >Alex Miller is the main community manager for Clojure, and is a 
> >> >maintainer of the core libraries, so his perspective is key. He notes 
> >> >that, AOT code is tied to *specific versions of Clojure*:
> >> >
> >> >  "AOT'ed code is that it is inherently the product of a particular 
> >> > version of tthe Clojure compiler ... I would recommend NOT AOT compiling 
> >> > libraries" [4]
> >> 
> >> This reasoning does not follow – yes, it is tied to the Clojure version, 
> >> so what? Guix automatically rebuilds dependents when the dependency (in 
> >> this case, the Clojure compiler) changes.
> (...)
> 
> >I think this preceding sentence is the heart of different assumptions 
> >between us.
> 
> >The Clojure packages we haave are for developers writing applications 
> >(libraries and tools). The ecosystem has very few end-user applications [0]. 
> >As a Clojure developer I can use the Clojure tools from Guix, and a few 
> >libraries. We (and all the other distributions) have a miniscule portion of 
> >the Clojure/Java library universe [1]. This leads to the following usage 
> >scenarios:
> 
> >1. A developer installs Clojure from Guix, and uses libraries from outside 
> >Guix.
> They can install the JVM/Clojure and some common tools (like clj-tools-cli). 
> They will use libraries from elsewhere, including their own. AOT compilation 
> is a problem because of the issue of mixed AOT and non-AOT.
> 
> >2. A developer installs a Clojure from outside Guix, uses libraries from 
> >inside Guix
> This will cause problems because the Guix Clojure libraries will have been 
> AOT'd by a different version of the compiler. It's also fairly common to 
> install/use parallel versions of Clojure/jvm due to different deployment 
> needs, this is likely to cause difficult to find bugs.
> 
> My answer to (1) and (2) is:
> 
> (a) About “install Clojure from outside Guix + use libraries inside Guix”:
> 
>  If these libraries are AOT:
> 
> Don’t do that, then. If you mix-and-match binaries (in this case, .class 
> files) different distributions, you are free to do so, but when (not if, 
> when) things break, you get to keep the pieces.
> 
> If these libraries are just the .clj files (not AOT) (which as I understand 
> it is the standard situation): doesn’t seem a problem to me (see point (b)).
> 
> Adding source from other places is one thing (probably ok), adding binaries 
> is another (probably not ok, especially if unstable ABIs (see Clojure 
> compiler) and mismatched versions (see hypotheses of 2.) are involved.
> 
> (b) What is this “the issue of mixed AOT and non-AOT”? Do you have a source 
> on this? Besides Clojure supposedly, I haven’t ever heard of such problems 
> for any language – for example, there is no such issue with Guile and AFAIK 
> not for Python. I haven’t heard of any such issues for the Common Lisp 
> implementations either (though I haven’t checked), so this doesn’t seem like 
> a “Clojure doesn’t do hygienic macros” issue.
> 
> (c) Guix isn’t forcing anyone to use AOT’d libraries. If people really want 
> to assist in murdering the climate (or its a situation where total cost of 
> non-AOT is lower than AOT), they can unfortunately (*) simply do so applying 
> a recursive transformation that adds #:aot? #false flags everywhere or 
> whatever the exact argument is (**).
> 
> Given that this transformation has some legitimate use cases, this 
> transformation could even be a pre-canned procedure + transformation included 
> in Guix itself
> 
> (*) ‘unfortunately’ only applies to the first case. For the case in 
> parentheses, replace by ‘fortunately’.
> (**) IIRC is wasn’t #:aot? but some other name, but that’s not really the 
> point here.
> 
> (d) If a deployment need multiple versions of Clojure, then just fix your 
> deployment to make everything work with the latest version of Clojure. Or, if 
> you for some reason don’t do that, just use a (recursive) transformation to 
> change the version of the Clojure compiler used to match the Clojure that 
> will be used in the particular deployment.
> 
> (e) You can simply add missing packages to Guix as the need arises.
> 
> >I can see the sense of compiling to byte code if it's an end-user 
> >application. In that case we'd want to make the start-up 

Re: You're invited to the first patch review session!

[Steve George]

Hi Vagrant,

On 22 Feb, Vagrant Cascadian wrote:
> On 2024-02-22, Steve George wrote:
> > We're going to run some online patch review sessions. The first one is on 
> > *Thursday, 7th March* and you can sign-up here:
> >
> >   https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024
> 
> Hoping to make it for some of these, thanks for doing it!
> 
> One small point is if people could include the scheduled times in UTC in
> addition to "arbitrary" timezones. It is much easier to compare against
> UTC (especially because it does not do daylight savings time) if you
> don't happen to be in one of the specified timezones. :)
(...)

I've put the UTC time into the Wiki page. The Meet-up page should send you a 
calendar invite which will be correct for your timezone. And, yeah daylight 
saving and meeting co-ordination is just *hard*! Look forward to seeing you at 
some of the sessions!

Steve

You're invited to the first patch review session!

[Steve George]

Hi

We're going to run some online patch review sessions. The first one is on 
*Thursday, 7th March* and you can sign-up here:

  https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

The background is that Guix has many fantastic contributions that are waiting 
to be reviewed and added to the archive. We have the QA system that does test 
builds, but each patch also needs to be evaluated and checked. Anyone can 
review patches, and reviews help to confirm that a patch is in good shape to be 
added to the archive.

Doing patch reviews is also a great way to learn about Guix, the different 
packages and methods involved in packaging. To encourage new reviewers to step 
forward, and to have some fun we're going to run on-line patch review sessions. 
These will be informal, probably chaotic - but fun - with the aim that we learn 
as a group how to review packages.

Each session will be hour 1:30 and they are rotating through the week, so there 
should be plenty of opportunities to come along. We're using the Guix London's 
Meet-up and the sessions run on Jitsi. 

We'll try and talk a bit about how to do reviews, and then we'll try and do 
some reviews, learning and asking questions together!

Hope to see you there!

Steve / Futurile

Re: Proposal to turn off AOT in clojure-build-system

[Steve George]

Hi Maxime,

On 19 Feb, Maxime Devos wrote:
(...) 
> > Consequently, there is no specific statement saying 'Distributors should 
> > not AOT libraries' that I can point to.
> 
> In this bit about differences in perspective, I haven’t seen any mention of 
> AOT, hence the “Consequently” does not follow. The part that’s missing here 
> is that (IIUC) in Clojure, it is somewhat conventional to stuff the compiled 
> .class files in a superior Aryan JAR instead – the inferior UnderJARs you get 
> from the “guix install clj-whatever” equivalent would only contain 
> non-compiled .clj (and data files, whatever).
> 
> > But, I would like to draw attention to this thread on Clojureverse as the 
> > best source I could find:
> >Alex Miller is the main community manager for Clojure, and is a maintainer 
> >of the core libraries, so his perspective is key. He notes that, AOT code is 
> >tied to *specific versions of Clojure*:
> >
> >  "AOT'ed code is that it is inherently the product of a particular version 
> > of tthe Clojure compiler ... I would recommend NOT AOT compiling libraries" 
> > [4]
> 
> This reasoning does not follow – yes, it is tied to the Clojure version, so 
> what? Guix automatically rebuilds dependents when the dependency (in this 
> case, the Clojure compiler) changes.
(...)

I think this preceding sentence is the heart of different assumptions between 
us.

The Clojure packages we haave are for developers writing applications 
(libraries and tools). The ecosystem has very few end-user applications [0]. As 
a Clojure developer I can use the Clojure tools from Guix, and a few libraries. 
We (and all the other distributions) have a miniscule portion of the 
Clojure/Java library universe [1]. This leads to the following usage scenarios:

1. A developer installs Clojure from Guix, and uses libraries from outside Guix.
They can install the JVM/Clojure and some common tools (like clj-tools-cli). 
They will use libraries from elsewhere, including their own. AOT compilation is 
a problem because of the issue of mixed AOT and non-AOT.

2. A developer installs a Clojure from outside Guix, uses libraries from inside 
Guix
This will cause problems because the Guix Clojure libraries will have been 
AOT'd by a different version of the compiler. It's also fairly common to 
install/use parallel versions of Clojure/jvm due to different deployment needs, 
this is likely to cause difficult to find bugs.

I can see the sense of compiling to byte code if it's an end-user application. 
In that case we'd want to make the start-up as fast as possible. Your comments 
seem to have this use-case in mind.

But, today there aren't any such end-user Clojure applications in Guix.

> >I believe this means that with AOT code on, any user who installs a 
> >different version of Clojure from the one that we used to AOT the libraries 
> >*may* have problems.
> 
> Unlike, say, Maven, this situation simply does not happen in Guix, because we 
> don’t just download binaries and call it a day (except for some bootstrapping 
> stuff, but that’s not relevant for Clojure AOT), because we have functioning 
> recompilation of dependents, because of shebang patching, because binaries 
> that are to be invoked should not rely on the ambient CLASSPATH / 
> LD_LIBRARY_PATH / etc. and, if, the underlying binaries do rely on that, they 
> are wrapped (see wrap-program) to set them (or, at least, they should be, you 
> might find some bugs in this department if you go looking).
> 
> Even if they aren’t wrapped, then in that case the dependencies are 
> propagated-inputs, and you can only have a single version of a propagated 
> package in the same environment (barring stacking environment shenanigans, 
> but then you are looking for it and/or you can just report a bug about how 
> the binaries should be wrapped/classpath should be patched in/...).
> 

In this paragraph you're assumption is that a Guix user is only using libraries 
from within Guix. Hopefully, I've shown why this assumption is unlikely above.

You also mentioned Debian, and @e.hashiman [2] said that Clojure libraries are 
not AOT'd on Debian, while applications are. From what I can find there are 130 
packages in Debian with the word Clojure in them [3]. I looked at a selection 
and it seems true that Debian does not AOT libraries (and I can't find any 
Clojure 'apps'). For completeness I also checked what Clojars, the main 
distribution archive for Clojure developers, does:

- https://sources.debian.org/src/core-match-clojure/1.0.0-1/project.clj/
- Lein-based project - has to have :aot keyword - distributes as source 
files
- Clojure source files (.clj) in Debian
- Clojure source files in Clojars
- Byte compiled files in GUIX
- installed and inspected with jar -tvf

- https://sources.debian.org/src/data-csv-clojure/1.0.0-1/deps.edn/
- tools.deps project - has to have a specific aot alias - distributes as 
source files
- Clojure source files (.clj) in the 

Proposal to turn off AOT in clojure-build-system

[Steve George]

Hi,

Guix's clojure-build-system turns on AOT compilation by default. I would like 
to advocate that 'as a distributor' we should *not* ship Clojure code AOT'd, so 
we should change the default.

This has been discussed previously. In #56604 r0man noted that AOT compilation 
should not be on by default [0], Reilly makes the same point in #53765 [1].

Maxime makes the point that where a compiler is available it should be used [2] 
and that if it doesn't work it's a bug:

  "if a Clojure library misbehaves when AOT-compiled, without additional 
context, that seems like a bug in the Clojure library to me (or the 
AOT-compilation code).

The perspective in the Clojure community is quite different from Guix's on a 
number of fronts. There's not much discussion about offline builds, 
reproducibility or code coming from Distributions. The internalised perspective 
is that you use the build tools to download libraries directly from Clojars (a 
Maven repo) and developers create a final uberjar for production usage 
Consequently, there is no specific statement saying 'Distributors should not 
AOT libraries' that I can point to. But, I would like to draw attention to this 
thread on Clojureverse as the best source I could find:

Alex Miller is the main community manager for Clojure, and is a maintainer of 
the core libraries, so his perspective is key. He notes that, AOT code is tied 
to *specific versions of Clojure*:

  "AOT'ed code is that it is inherently the product of a particular version of 
tthe Clojure compiler ... I would recommend NOT AOT compiling libraries" [4]

In the same thread thheller, who is the maintainer of the most popular 
ClojureScript tooling,  notes you cannot mix AOT and non-AOT libraries [5]:

"you cannot just ship your library AOT compiles as it would also contain 
clojure.core. Clojure AOT current ... can not load clj files from .class files. 
So AOT produces the class files and will fail if one of the dependent classes 
is missing although the .clj file is present"

I believe this means that with AOT code on, any user who installs a different 
version of Clojure from the one that we used to AOT the libraries *may* have 
problems. And, that we can't have trees where some part is AOT'd but a 
dependency is not. Finally, there is no expectation in the Clojure community 
that this is a bug, consequently it will not be fixed. Therefore, we should 
change to default to AOT off.

What do people think, does this make sense?

Thanks,

Steve / Futurile

[0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56604#5
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53765#290
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53765#293
[4] https://clojureverse.org/t/deploying-aot-compiled-libraries/2545/6
[5] https://clojureverse.org/t/deploying-aot-compiled-libraries/2545/3
[5] https://gist.github.com/hiredman/c5710ad9247c6da12a99ff6c26dd442e

Re: Committers available for Patch hacking/review meet-up?

[Steve George]

On 15/02/2024 00:53, jgart wrote:

7th March (Thursday)
20th March (Wednesday)
2nd April (Tuesday)
15th April (Monday)
3rd May (Friday)
16th May (Thursday)
29th May (Wednesday)

Each one held at 19:00 CET / 18:00 BST / 13:00 EST [0] for 1.5 hours.


Hi,

Thanks for putting this together.

Lately I've been too busy with work and other tasks/priorities to review Guix 
patches, unfortunately.

Those dates and times conflict with my work hours so I probably won't be able 
to attend any of the proposed dates.

I live in the CT timezone and I am usually working from 9 AM to 5 or 6 PM CT on 
weekdays.

I could potentially do a Saturday or Sunday sometime in May.

all best,

jgart

https://whereis.みんな/


Hi Jgart - understood and no worries - sorry about the timing, hard to 
find something that works for everyone. If you don't mind I'll email you 
a bit closer to May and see what your calendar is like - then we can see 
if organising something on a weekend or maybe recording a video would be 
possible.


Thanks,

Steve

Re: Committers available for Patch hacking/review meet-up?

[Steve George]

Hi Andreas,

On 14/02/2024 14:04, Andreas Enge wrote:

Hello,

thanks, Steve, for getting things going!

Am Tue, Feb 13, 2024 at 02:48:08PM + schrieb Steve George:

We said they'd be every 13 days, for 3 months to see if it has interest.
Proposed calendar:
7th March (Thursday)


I will be around on this day.



That's brilliant - thanks so much!


Each one held at 19:00 CET / 18:00 BST / 13:00 EST [0] for 1.5 hours.


For these, we will have the daylight savings time switch; so maybe we
should move to 19:00 CEST. Something we can do later.



Argh!


What I propose is that we'd do the following:
1 - 30 mins: a committer runs through their review process, and shows a
recent patch or patches they've reviewed. Really informal showing what they
do.


Well, I only ever look at simple packages, and do not think I have anything
resembling a process to share. But I will try to be around in any case :)

(...)

Understood, any tips, tricks or any thoughts are going to be welcome!

Steve

Committers available for Patch hacking/review meet-up?

[Steve George]

Hi,

At Guix Days we said we'd organise some patch review sessions.

Q1: Can at least one committer uh ... commit to be at each session to help?

The goal of of the sessions is:

1. Teaching people how to do patch reviews
2. Do some patch reviews together in a friendly hacking session

We said they'd be every 13 days, for 3 months to see if it has interest. 
Proposed calendar:


7th March (Thursday)
20th March (Wednesday)
2nd April (Tuesday)
15th April (Monday)
3rd May (Friday)
16th May (Thursday)
29th May (Wednesday)

Each one held at 19:00 CET / 18:00 BST / 13:00 EST [0] for 1.5 hours.

What I propose is that we'd do the following:

1 - 30 mins: a committer runs through their review process, and shows a 
recent patch or patches they've reviewed. Really informal showing what 
they do.


31-90 mins: we select an issue (or issues) to run through.

What I would like is for one Committer to agree to be in each session. 
We'd then know that a specific person will walk through their process, 
and if the group does review some patches they can be committed so 
there's a "win".


Anyone available? If you are and can put your name down for a particular 
date that would be brilliant!



Q2: Does anyone have permission on 
https://libreplanet.org/wiki/Group:Guix to give a user the right to 
create new pages? I want to document the sessions and how-to's.


Thanks,

Steve
ps Specific people in the 'to' as they've shown an interest
pps I'll send specific info for each session later.

[0] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20240213=5416=136=179

Re: Guix Days: Patch flow discussion

[Steve George]

On  9 Feb, Edouard Klein wrote:
> 
> Skyler Ferris  writes:
> 
> > On 2/6/24 05:39, Steve George wrote:
> >> I agreed to organise some 'patch review' online sessions in the next 
> >> couple of
> >> weeks.
> >>
> >> Organising a basic process is a good topic for that online session. For
> >> example, elsewhere in the thread someone mentions some tags we could use
> >> consistently so maintainers can find patches that have been reviewed 
> >> easily. It
> >> would be great to agree those - try them for a bit - and document them in a
> >> 'howto' so that everyone uses the same process.
> > Have these been announced somewhere yet (eg, with url & exact time)? If
> > not will being subscribed to the help-guix list and/or checking the Guix
> > blog be sufficient to receive notification? As someone who has sent
> > patches in the past and intends to continue sending more in the future,
> > I'd like to do my part to keep the project in a good state. However, I
> > am new to interacting with large FLOSS projects so I'm nervous about
> > causing more problems than I solve if I just start doing things.
> 
> Same here.
>

Hi Skyler & Edouard - you haven't missed an announcement :-) I'll get it 
organised next week and will mail out here - plus I'll email you both directly 
as you've both shown interest.

Thanks,

Steve / Futurile

Re: Collecting Guix talks at FOSDEM

[Steve George]

Hi,

Did anyone take a photo of the discussion whiteboard?

And/or anyone get a photo of the room generally that could be used in 
the blog post? Be nice to have a visual ...


Steve
ps I will check with each person in any photo that they don't object to 
it being posted



On 06/02/2024 07:39, Pjotr Prins wrote:

Hi Steve,

It would also be nice to write a BLOG about what was discussed at Guix
days and FOSDEM. That way we get a historical record. If you take the
lead we can collect the notes that were made and write a concise
overview of each discussion. I am sure people are happy to help. That
an idea?

Pj.

On Tue, Jan 16, 2024 at 03:35:17PM +, Steve George wrote:

Hi all,

We're planning to put up a blog post about Guix (and Guix-related) talks at
FOSDEM [0]. I've collected all the talks that that are about Guix (or
connected areas). If I've missed any Guix related talks please tell me so I
can add them to the blog post:

- Declarative and Minimalist Computing track
-

This track [1] has:

- RISC‐V Bootstrapping in Guix and Live‐Bootstrap
 - Ekiatz Zárraga
 - Sunday: 11:20 - 11:40
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-1755-risc-v-bootstrapping-in-guix-and-live-bootstrap/

- Self-hosting and autonomy using guix-forge
 - Arun IsaaC
 - Sunday: 11:40 - 12:00
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2560-self-hosting-and-autonomy-using-guix-forge/

- Spritely, Guile, Guix: a unified vision for user security
 - Christine Lemmer-Webber
 - Sunday: 12:00 - 12:25
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2331-spritely-guile-guix-a-unified-vision-for-user-security/


Other tracks
-

- Making reproducible and publishable large-scale HPC experiments
 - Philippe SWARTVAGHER
 - Saturday: 10:30 - 11:00
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2651-making-reproducible-and-publishable-large-scale-hpc-experiments
/

- Supporting architecture psABIs with GNU Guix.
 - Efraim Flashner
 - Sunday: 14:30 - 14:55
  - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2927-supporting-architecture-psabis-with-gnu-guix/


Connected 'Guile/Scheme' interest
--

- Scheme in the Browser with Guile Hoot and WebAssembly
 - Robin Templeton
 - Sunday: 11:00-11:20
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2339-scheme-in-the-browser-with-guile-hoot-and-webassembly/

Thanks,

Steve

[0] Ludo's post from last year:
https://guix.gnu.org/en/blog/2023/meet-guix-at-fosdem-2023/
[1] 
https://fosdem.org/2024/schedule/track/declarative-and-minimalistic-computing/

Re: Guix Days: Patch flow discussion

[Steve George]

Hi Suhail,

On  5 Feb, Suhail wrote:
> Felix Lechner via  writes:
> 
> > Another is that committers should commit what they think is right
> > rather than ask for revised patches.
> 
> I could be mistaken, but I believe this does happen today at least some
> of the time.  Is your position that
> 
> 1. this never happens today and thus, should happen some times when
>warranted.  Or that,
> 
> 2. it happens far too rarely today, and should happen more often. Or
>that,
> 
> 3. committers should never ask for revisions?
(...)

Just to reply to this part, there were a variety of views on what the correct 
balance was between teaching someone and fixing issues so that a contributors 
patch was applied without them having to make further efforts. The general 
opinion seemed to be, that it was better to fix small issues and commit the 
change for new users, so they had the satisfaction of their contribution making 
it into the repository. One proposal was to do the 'fix', and to then reply 
back to the bug with a diff - showing what was done.

Steve

Re: Guix Days: Patch flow discussion

[Steve George]

Hi Edouard,

On  6 Feb, Edouard Klein wrote:
> I, for one, would be willing to review patches, hoping that in turn my
> patches would be reviewed instead of staying in limbo forever, which is
> a drag on me submitting more patches.
> 
> Is there a procedure to follow, or do I just start replying "LGTM" to
> patch email threads ?

Starting to review patches would be brilliant.

I agreed to organise some 'patch review' online sessions in the next couple of 
weeks. 

Organising a basic process is a good topic for that online session. For 
example, elsewhere in the thread someone mentions some tags we could use 
consistently so maintainers can find patches that have been reviewed easily. It 
would be great to agree those - try them for a bit - and document them in a 
'howto' so that everyone uses the same process.

Steve

Re: Collecting Guix talks at FOSDEM

[Steve George]

Hi Tanguy,

On 06/02/2024 08:19, Tanguy LE CARROUR wrote:
(...)

Quoting Pjotr Prins (2024-02-06 08:39:25)

It would also be nice to write a BLOG about what was discussed at Guix
days


I have notes about what sessions took place during the Guix days.
I was planning to send (tomorrow?) a patch for the Guix Foundation website
to make it available, like "GNU Guix Days FOSDEM 2023" [1].

[1]: https://foundation.guix.info/events/index.html

I don’t know if it’s the right place to put notes about the content,
though? 樂


Ludo said they put them into this repo:

https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024

Do you have access to this? (I do not).

We can ask people on the channel / this list to put their notes - or 
integrate their notes into the existing ones there (as it's a shared 
endeavour).


Does that work?

Steve

Re: Collecting Guix talks at FOSDEM

[Steve George]

Hi,

Sounds good.

A blog post for the main Guix web site, with links to the detailed notes 
that were collected.


Ludo told me the raw notes are being collected here:

https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/guix-days-2024

Thanks,

Steve

On 06/02/2024 07:39, Pjotr Prins wrote:

Hi Steve,

It would also be nice to write a BLOG about what was discussed at Guix
days and FOSDEM. That way we get a historical record. If you take the
lead we can collect the notes that were made and write a concise
overview of each discussion. I am sure people are happy to help. That
an idea?

Pj.

On Tue, Jan 16, 2024 at 03:35:17PM +, Steve George wrote:

Hi all,

We're planning to put up a blog post about Guix (and Guix-related) talks at
FOSDEM [0]. I've collected all the talks that that are about Guix (or
connected areas). If I've missed any Guix related talks please tell me so I
can add them to the blog post:

- Declarative and Minimalist Computing track
-

This track [1] has:

- RISC‐V Bootstrapping in Guix and Live‐Bootstrap
 - Ekiatz Zárraga
 - Sunday: 11:20 - 11:40
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-1755-risc-v-bootstrapping-in-guix-and-live-bootstrap/

- Self-hosting and autonomy using guix-forge
 - Arun IsaaC
 - Sunday: 11:40 - 12:00
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2560-self-hosting-and-autonomy-using-guix-forge/

- Spritely, Guile, Guix: a unified vision for user security
 - Christine Lemmer-Webber
 - Sunday: 12:00 - 12:25
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2331-spritely-guile-guix-a-unified-vision-for-user-security/


Other tracks
-

- Making reproducible and publishable large-scale HPC experiments
 - Philippe SWARTVAGHER
 - Saturday: 10:30 - 11:00
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2651-making-reproducible-and-publishable-large-scale-hpc-experiments
/

- Supporting architecture psABIs with GNU Guix.
 - Efraim Flashner
 - Sunday: 14:30 - 14:55
  - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2927-supporting-architecture-psabis-with-gnu-guix/


Connected 'Guile/Scheme' interest
--

- Scheme in the Browser with Guile Hoot and WebAssembly
 - Robin Templeton
 - Sunday: 11:00-11:20
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2339-scheme-in-the-browser-with-guile-hoot-and-webassembly/

Thanks,

Steve

[0] Ludo's post from last year:
https://guix.gnu.org/en/blog/2023/meet-guix-at-fosdem-2023/
[1] 
https://fosdem.org/2024/schedule/track/declarative-and-minimalistic-computing/

Re: Guix Days: Patch flow discussion

[Steve George]

Hi Hartmut,

Apologies, my reply-to went a bit mad and I sent you empty emails :-(

You said:

> The current mail-based workflow is too complicated for new and 
> occasional committers. This is the main reason I gave up reviewing patches.
>

In the case of *reviewing patches* can you give some examples of:

1. Some patches from others you reviewed?
2. The steps you went through to undertake that review?

If for example, you started to review a simple update to a package how do you 
aproach it?

It would be great to hear directly from someone doing 'reviewing' on the 
specifics. Apologies, if this is going over old ground.

Thanks,

Steve

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

Re: Guix Days: Patch flow discussion

[Steve George]

On 05/02/2024 15:57, Clément Lassieur wrote:

Hello,

On Mon, Feb 05 2024, Steve George wrote:


Hi,

Our goal for the discussion:

How do we double the number of patches that are *reviewed* and
*applied* to Guix in the next six months?

Patch flow is a pipeline, to change it we could:

a. Increase the number of committers - more people to do the
work


I don't think reviewers have to be committers.  If a patch is marked as
‘reviewed’ by a non-commiter, another person can just apply the patch
and push.  Although the commiter will take some responsibility in doing
so, and make sure the review was done correctly, it still makes their
work way easier.

My point is that not being committer shouldn't discourage people to
review patches.

(...)

Agreed - I put it a bit lower in the notes - clearly managed to bury it :-)

The discussion focused on increasing the number of Reviewers. A reviewer 
can be anyone - they don't need to be a committer.


The purpose of the proposed 'Patch Review' sessions is for contributors 
to come along and review patches together.


Thanks,

Steve

Re: Guix Days: Patch flow discussion

[Steve George]

Hi Leo,

On 05/02/2024 14:07, Leo Famulari wrote:

On Mon, Feb 5, 2024, at 04:39, Steve George wrote:

Our goal for the discussion:

How do we double the number of patches that are *reviewed* and
*applied* to Guix in the next six months?

Patch flow is a pipeline, to change it we could:

a. Increase the number of committers - more people to do the
work
b. Increase the efficiency of existing committers
c. Open the gates by decreasing the quality expected from patches


Hi George,


Just 'Steve' :-)


It's an important subject and, in my opinion, more important than any technical 
questions at this stage of the project.

However, I think the question assumes that all contributions should be 
accepted, and that the entire problem is that we are not accepting them 
efficiently enough. We should not unconsciously accept this assumption.

Guix can reject contributions, either in a general way (we don't want that type 
of thing in Guix), or due to specific reasons (the code is not idiomatic, the 
contributor can't work effectively with the rest of the group, etc).

(...)

Today there are 1264 bugs with patches attached to them today [0].

We don't have any stats (that I'm aware of) that show how many patches 
the project reviews and either asks for edits, rejects or applies.


The group - and I hope the minutes reflect this - wanted to maintain the 
current standards. So the discussion of the pipeline focused on how we 
review more patches, and make decisions about them: whether that 
decision is to accept the contribution, ask for more work, or reject it 
as out of scope.


To answer your comment about the 'unconscious' assumptions - my personal 
view is:


* I don't think ALL patches should simply be accepted
* I do think that more patches need to be reviewed and a decision made
* I believe (no evidence) the project is missing out on great 
contributions amongst those 1200+ patches in the tracker
* I believe (no evidence) that potential contributors are put-off by the 
speed of review / lack of clarity


Thanks,

Steve

[0] https://debbugs.gnu.org/rrd/guix-patches.html

Guix Days: Patch flow discussion

[Steve George]

Hi,

Our goal for the discussion:

How do we double the number of patches that are *reviewed* and
*applied* to Guix in the next six months?

Patch flow is a pipeline, to change it we could:

a. Increase the number of committers - more people to do the
work
b. Increase the efficiency of existing committers
c. Open the gates by decreasing the quality expected from patches

We essentially decided to focus our discussion on (b). We looked at
things that 'hinder' and 'help' patch review:


Hinders


- All our patch reviewers are volunteers doing it in their spare time.

- For a volunteer reviewing someone else's work is not very rewarding, 
most would prefer to use that precious time to scratch their own itch.


- Can feel like an Sisyphean task: no matter how many patches someone 
reviews there are more, exacerbated by the number of Guix packages.


- Sense of responsibility: the minute that a reviewer looks at the patch 
they are now stuck with it


- Repetitive and boring: often patches have minor issues, but it's the 
same sorts of issues time and time again.


- Risk of negative social interaction: having to tell someone that their 
patch is incorrect, or that their contribution cannot be used is 
difficult and draining. Some people felt it was better to say nothing, 
rather than to respond to a patch.



Helps
==

This led us to the focus on the fact that **reviewing and applying
patches can be different people**

We looked for ideas to create more reviewers, make reviewing easier and
more fun:


- Share in the work


1. encourage new reviewers to step forward - making it more known that 
reviewing patches helps to get them applied. Anyone can review patches.


2. create directed 'how-to' documentation for reviewing and connect it 
to QA so that 'new reviewers' know what to do


3. create documentation about 'when' and 'how' it's appropriate to send 
a 'v2' version of a patch so that the QA system builds and accepts it. 
Sometimes, patches rot because non-committers don't want to be seen as 
'stealing' someone's work with a v2 patch - but making the small changes 
and resubmitting to QA is what is required.


4. Pay someone else to do it. Noted but out of scope.
5. Remove old packages overhead. Old untouched packages create mental 
overhead, and make the task of maintaining the repository in a good 
state more difficult. We could remove old 'untouched' packages and ones 
that no-longer compile. We have methods to hide and notify.



- Make it more fun
---

1. do online sessions around reviews, some sprints or pairing - both 
social and a way to spread skills

2. find ways to recognise and appreciate reviewers - 'reviewer of the month'
3. make it a game - we could have a 'Guix London' vs 'Guix Paris' leader 
board for reviews. Make it a group goal 'can we beat januarys reviews 
number'
4. create some graphs / leaderboard so we know how many patches are 
being reviewed and we can recognise the contribution



- Automate it away
---

1. Chris is continuing to try and automate away the boring work - 
general agreement in the group that QA has made a lot of difference.


2. general discussion about create a 'guix review' command (Nix has one) 
which would download a branch with the appropriate patch and build it 
locally. This is for instances where some adjustment is needed or to 
check a build. While this can be done today, it's a number of steps and 
quite involved.



Agreed Actions
==

* [Chris]: continuing his work to improve QA automation. Implication was 
we'll need some reports / graphs - but these were not discussed in detail.


* [Futurile]: organise a **patch review online sessions**. To run every 
13 days (so it rotates through the week) - for 3 months to see if it has 
any traction. Co-ordinate with maintainers so that patches that are 
reviewed can be committed



Actions looking for someone - you?


* Carry forward the 'guix review' command idea

* Write an RFC and discuss the idea of removing older 'bit-rot' packages

* write 'how-to' documentation for reviews and when it's socially
acceptable to do a v2 patch. A checklist-like approach.


If you were in the discussion and I've misrepresented your point, or 
forgotten an important aspect please please reply and correct me.


Also, if you would like to help on any of the tasks please email back to 
the group so we can all co-ordinate.


Finally, thank-you to everyone who came along and put their shared brain 
power to the task - look forward to doing some patch reviews together 
online in the coming weeks!


Thanks,

Steve/Futurile

Re: Collecting Guix talks at FOSDEM

[Steve George]

On 17/01/2024 15:47, Simon Tournier wrote:
(..)

On Tue, 16 Jan 2024 at 15:35, Steve George  wrote:


We're planning to put up a blog post about Guix (and Guix-related) talks
at FOSDEM [0]. I've collected all the talks that that are about Guix (or
connected areas). If I've missed any Guix related talks please tell me
so I can add them to the blog post:


Thanks for taking care about that.

It could be nice to publish this bog soon.  Is it doable?

(...)

Hi - initial draft of the post went to Ludo today for review (and commit 
as I don't have the rights). We'll see what his reaction is to my 
British English and random punctuation! ;-)


Thanks,

Steve

Collecting Guix talks at FOSDEM

[Steve George]

Hi all,

We're planning to put up a blog post about Guix (and Guix-related) talks 
at FOSDEM [0]. I've collected all the talks that that are about Guix (or 
connected areas). If I've missed any Guix related talks please tell me 
so I can add them to the blog post:


- Declarative and Minimalist Computing track
-

This track [1] has:

- RISC‐V Bootstrapping in Guix and Live‐Bootstrap
- Ekiatz Zárraga
- Sunday: 11:20 - 11:40
- 
https://fosdem.org/2024/schedule/event/fosdem-2024-1755-risc-v-bootstrapping-in-guix-and-live-bootstrap/


- Self-hosting and autonomy using guix-forge
- Arun IsaaC
- Sunday: 11:40 - 12:00
- 
https://fosdem.org/2024/schedule/event/fosdem-2024-2560-self-hosting-and-autonomy-using-guix-forge/


- Spritely, Guile, Guix: a unified vision for user security
- Christine Lemmer-Webber
- Sunday: 12:00 - 12:25
- 
https://fosdem.org/2024/schedule/event/fosdem-2024-2331-spritely-guile-guix-a-unified-vision-for-user-security/



Other tracks
-

- Making reproducible and publishable large-scale HPC experiments
- Philippe SWARTVAGHER
- Saturday: 10:30 - 11:00
- 
https://fosdem.org/2024/schedule/event/fosdem-2024-2651-making-reproducible-and-publishable-large-scale-hpc-experiments 
   /


- Supporting architecture psABIs with GNU Guix.
- Efraim Flashner
- Sunday: 14:30 - 14:55
 - 
https://fosdem.org/2024/schedule/event/fosdem-2024-2927-supporting-architecture-psabis-with-gnu-guix/



Connected 'Guile/Scheme' interest
--

- Scheme in the Browser with Guile Hoot and WebAssembly
- Robin Templeton
- Sunday: 11:00-11:20
- 
https://fosdem.org/2024/schedule/event/fosdem-2024-2339-scheme-in-the-browser-with-guile-hoot-and-webassembly/


Thanks,

Steve

[0] Ludo's post from last year: 
https://guix.gnu.org/en/blog/2023/meet-guix-at-fosdem-2023/
[1] 
https://fosdem.org/2024/schedule/track/declarative-and-minimalistic-computing/

Re: packaging Typst

[Steve George]

Hi Alexis,

I've been doing some Rust packaging recently, so maybe this will help you to 
get started. Here's how I would approach it.

Explore the software

The first thing I did was explore whether Typst builds in a current Guix 
environment. If we don't have the right version of Rust, for example, there's 
little point continuing:

- clone it into an appropriate place
- start a shell: 
$ guix shell --container --network rust rust-cargo coreutils openssl 
nss-certs gcc-toolchain

We need 'openssl' and 'nss-certs' so that cargo will work. 

- build it: 
[env]$ env CC=gcc cargo build

Kept failing on ring v0.17.5 which is looking for 'cc'. It builds with 296 
crates, so we might have our hands full here! Eventually outputs a 
/target/debug/typst command which seems to work.


Import using Guix import
=
Normally, we'd be able to use the `crates` importer. But, the Typst crates are 
just place-holders with no details. 

AFAIK the importer only works with crates-io, we can't feed it Cargo.toml file 
directly. We'll need to manually create a package and check for any 
dependencies.

Manually create a top-level package

To manually create the package we have to go through the projects Cargo.toml.

- create an intial typst.scm file in some project directory.
- create a minimal typst package by looking in Cargo.lock at 'typst'
- for each dependency look at what the Cargo.lock used to build it - check 
whether we have it in Guix
- in some cases we will have the crate, but not the right version

Import the dependencies
=
The first crate that I found which we don't have in the Guix archive is 
'comemo' [0]. We can import this with: 

$ guix shell --development guix --container --nesting --network nss-certs
[env]$ guix import crate --recursive comemo@0.3.0 > comemo-import.scm

Move these package definitions into your main `typst.scm` file. Check them to 
add any missing development dependencies.

The first one in the dependency stack is `rust-comemo-0.3` which we reference 
at the bottom of the file. We try and build it as the importer has pulled it in:

$ guix shell --development guix --container --nesting 
[env]$ guix build --load-path=./ --file=typst.scm


The next one `rust-comemo-macros` which has been set to `skip-build: #t`, we'll 
try building it that way initially:

- add rust-comemo-macros-0.3 to the bottom of the typst.scm file
- comment out the rust-comemo-0.3 line
- try and build with: guix build --load-path=./ --file=typst.scm 

- If it builds successfully, change the `skip-build: #t` part of the 
definition to be #f.
- error[E0433]: failed to resolve: use of undeclared crate or module 
`comemo`
- tried adding comemo as a dependency which didn't work
- set it to #:tests? #f - for now

There's some more things that have to be done to 'contribute' these packages, 
but for now I would move onto the next dependency. And that's all there is to 
this part - finding the dependencies and importing them.

Building a dependent package that's not a crate
===
The cargo-build-system expects to build everything from Crates AFAIK. I believe 
it will take some messing around with the phases to add the typst-lib which 
seems to be a dependency. It looks like librsvg (in gnome.scm) does a lot of 
messing with phases, and greetd (in admin.scm) does some as well - these might 
be good examples to look at.

Hopefully this is enough to get you started!

Steve

[0] https://crates.io/crates/comemo
(define-module (typst)
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix packages)
#:use-module (guix gexp)
#:use-module (guix download)
#:use-module (guix git-download)
#:use-module (guix utils)
#:use-module (guix build-system gnu)
#:use-module (guix build-system cargo)
#:use-module (gnu packages crates-io))

;; guix shell --development guix --container --nesting 
;; guix build --load-path=./ --file=typst.scm


; librsvg in gnome.scm mixes build systems
; greetd in admin.scm does some minor changes

(define-public rust-comemo-0.3
  (package
(name "rust-comemo")
(version "0.3.0")
(source
 (origin
   (method url-fetch)
   (uri (crate-uri "comemo" version))
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32 "14ng6gqklsy8m9wn6radragn8pazsmn5759mywxb1ddf8bqrg818"
(build-system cargo-build-system)
(arguments
 `(#:cargo-inputs (("rust-comemo-macros" ,rust-comemo-macros-0.3)
   ("rust-siphasher" ,rust-siphasher-0.3
(home-page "https://github.com/typst/comemo;)
(synopsis "Incremental computation through constrained memoization.")
(description "Incremental computation through constrained memoization.")
(license (list license:expat