Re: LaTeX packaging policy

[Nguyễn Gia Phong]

On 2023-01-04 at 08:11+01:00, Reza Housseini wrote:
> What about size? Does [propagating all build inputs]
> not bloat up profile sizes?

I'm new to Guix, but aren't both build inputs
and propagated build inputs required at run time?
IIUC the only difference is that the propagated ones' env
is, ehm, propagated all the way up instead of just
to the direct dependee.

Re: LaTeX packaging policy

[Reza Housseini]

Good question, maybe we should just do that.  Thoughts?


What about size? Does this not bloat up profile sizes?

--
Reza Housseini

This message is signed with my GnuPG key:

C0F3 0812 9AF2 80F4 0830 C2C1 C375 C6AF 0512 5C52



OpenPGP_0xC375C6AF05125C52.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Some team related thoughts and questions...

[Vagrant Cascadian]

I filed a couple patches related to teams recently, which pointed out a
few things about the teams process to me...


First off, I wonder if there is (or it is worth creating) a way to make
the scope of a team more fine-grained... e.g. I think the Embedded team
would want to be notified of changes to gnu/packages/bootloaders.scm,
for the u-boot-* packages, but maybe not for grub? Similar also for the
arm-trusted-firmware-* or opensbi packages, but maybe not for
ath9k-htc-firmware (although the case could be made that that is an
embedded system unto itself).


I also wonder about splitting Embedded and Bootstrap into separate
teams; some things are obviously one or the other, but I do not, at
least in my mind, see the overlap.

Perhaps a description would for the team(s) would help a bit here.  I
see embedded as dealing with bootloaders or firmware commonly used on
embedded systems, and perhaps cross-compilers?

Is the Bootstrap team ... bootstrapping a new language compiler family?
bootstrapping a system from scratch? Yes to both? What is it's scope?


I wonder if the team.scm script could also have a few regexps in it for
the patch description. For example, "deterministic" or "reproducible"
might be a useful search term for my recently proposed Reproducible
Builds team, which otherwise would only be interested in a small pool of
reproducible builds tooling packages, but reproducible builds issues
actually could be relevent for all packages in guix.


Lastly, I use the name "Vagrant Cascadian" with my contributions to
guix, but I may use a different email address depending on the nature of
the contribution (e.g. reproducible builds). I am not sure what would
happen if I added "Vagrant Cascadian" twice, with two different email
addresses. Does it handle that reasonably?

It would be a little awkward to add a "Vagrant Cascadian (reproducible
builds)" in the name field but I guess that might be a trivial
workaround if having "Vagrant Cascadian" twice causes issues.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: ️ Install every Guix package ️

[kiasoc5]

On 1/3/23 21:33, jgart wrote:

Hi Guixers,

How would you approach writing a script that installs every Guix package 
exhaustively for your current revision?

I'm thinking of something similar to `all-packages` on PyPi but for every Guix 
package (the whole wide ️).

https://pypi.org/project/all-packages/



Perhaps you are inspired by this?

https://a.exozy.me/posts/installing-every-arch-package/

I'd run the list of all packages by guix size before attempting such 
shenanigans (untested):


```
$ guix package -A | cut -f 1 | sort -u | xargs guix size
```

Surely if there are outstanding questions that could be answered by 
installing all packages, they could be answered in another way?

Re: Install every Guix package

[Nguyễn Gia Phong]

On 2023-01-04 at 02:33+00:00, jgart wrote:
> How would you approach writing a script that installs
> every Guix package exhaustively for your current revision?

I don't want to know why you'd like to do that,
but you can start from here:

repo=https://data.guix.gnu.org/repository/1/branch/master
path=latest-processed-revision/packages.json
guix shell curl -- curl $repo/$path?all_results=on |
  guix shell jq -- jq -r '.packages[] | .name' |
  guix shell findutils -- xargs guix shell

️ Install every Guix package ️

[jgart]

Hi Guixers,

How would you approach writing a script that installs every Guix package 
exhaustively for your current revision?

I'm thinking of something similar to `all-packages` on PyPi but for every Guix 
package (the whole wide ️).

https://pypi.org/project/all-packages/

Re: What's missing from qutebrowser for text rendering?

[jgart]

Just adding this here as a note to self:

oriansj
jgart: the answer to your qutebrowser problem is a known defect with an easy 
work around: --qt-arg disable-seccomp-filter-sandbox true

mroh
ah, that explains why I have no fonts in kiwix-desktop.  thx!
jgart 

oriansj: [THANKS ]: Yay.

Re: GNU Guix 1.4.0 released

[indieterminacy]

On 03-01-2023 19:42, Joshua Branson wrote:


What areas does guix need more documentation?  To answer that question
for myself, I might say more gexp examples.  Though unmatched-paren is
working on a series of blog posts to dive really deep into that topic.



Guix should use more em dashes in the documentation — gets coat

--
Jonathan McHugh
indieterminacy@libre.brussels

Bogus ‘etc/teams.scm’ usage recommendations?

[Ludovic Courtès]

Hello Guix!

The manual recommends this (info "(guix) Teams"):

  git send-email --to issue_num...@debbugs.gnu.org $(./etc/teams.scm cc 
mentors) *.patch

where:

--8<---cut here---start->8---
λ ./etc/teams.scm cc mentors
--add-header="X-Debbugs-Cc: r...@raghavgururajan.name" 
--add-header="X-Debbugs-Cc: zimon.touto...@gmail.com" …
--8<---cut here---end--->8---

I believe this cannot work because the shell will split words on each
whitespace; IOW, the double quotes above do not have the desired effect.

The second issue is that passing ‘--add-header’ to ‘git send-email’
seems to have no effect.  AIUI, ‘git send-email’ passes those to ‘git
format-patch’, except that it has no reason to invoke it, right?

Maybe I’m missing something but it looks like we have documentation to
improve.  Thoughts?

Ludo’.

Re: FOSDEM tracks: deadlines are approaching!

[Ludovic Courtès]

Hi there!

Ludovic Courtès  skribis:

>   • Containers, Dec. 10th
> 
> https://discuss.linuxcontainers.org/t/fosdem-2023-containers-devroom-call-for-papers/15597
>
>   • CI/CD, Dec. 12th
> https://lists.fosdem.org/pipermail/fosdem/2022q4/003457.html
>
>   • Declarative & minimalist computing (don’t miss it!), Dec. 3rd
> https://lists.fosdem.org/pipermail/fosdem/2022q4/003446.html
>
>   • HPC, big data, and data science, Dec. 16th
> https://hpc-bigdata-fosdem23.github.io/
>
>   • Nix & NixOS :-), Dec. 7th
> https://lists.fosdem.org/pipermail/fosdem/2022q4/003463.html
>
>   • Open research tools & technologies, Dec. 4th
> https://lists.fosdem.org/pipermail/fosdem/2022q4/003470.html
>
>   • RISC-V, Dec. 10th
> https://lists.fosdem.org/pipermail/fosdem/2022q4/003474.html
>
>   • Security, Dec. 1st (oops!)
> https://github.com/security-devroom/fosdem-2023

There’s a great program in the minimalistic computing devroom, with lots
of Guile and Guix!

  https://fosdem.org/2023/schedule/track/declarative_and_minimalistic_computing/

A quick search reveals additional Guix talks in other devrooms:

  https://fosdem.org/2023/schedule/event/openresearch_guix/
  https://fosdem.org/2023/schedule/event/rv_gnu_guix/
  
https://fosdem.org/2023/schedule/event/security_where_does_that_code_come_from/

Exciting!

Ludo’.

Re: git-fetch without a hash

[Ludovic Courtès]

Hi!

Stephen Paul Weber  skribis:

>>> However, there's no real reason that git-fetch *needs* to be
>>> fixed-output in terms of having a hash pre-defined, at least for local
>>> development and other purposes.  So is there a way around this?
>>
>>  • write (package (source (git-checkout …)) …)
>
> This works well.  Now I'm curious how to know what can go in the
> (source) field?  Obviously not just (origin)...

Any “file-like object” can go there: a package (though that makes little
sense), a “computed-file”, etc.

>>> If having a way around it is not desirable should url-fetch consider
>>> this an error as well?
>>
>>I’m not sure; do you have an example where it’s not behaving as
>>expected?
>
> Yes.  When using (sha256 #f) url-fetch still has network access and
> works to download things, which is inconsistent vs other fetchers.

Hmm indeed:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> ,verbosity 3
scheme@(guile-user)> ,build (origin
  (method url-fetch)
  (uri "mirror://gnu/hello/hello-2.12.1.tar.gz")
  (sha256 #f))
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 100.0%
building /gnu/store/lz34lhyxhq5wxj87fnd465hmwbhv17bn-hello-2.12.1.tar.gz.drv...

Starting download of 
/gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz
>From https://ftpmirror.gnu.org/gnu/hello/hello-2.12.1.tar.gz...
following redirection to 
`https://mirror.cyberbits.eu/gnu/hello/hello-2.12.1.tar.gz'...
downloading from https://ftpmirror.gnu.org/gnu/hello/hello-2.12.1.tar.gz ...
 hello-2.12.1.tar.gz  1009KiB   
18.4MiB/s 
00:00 [##] 100.0%
successfully built 
/gnu/store/lz34lhyxhq5wxj87fnd465hmwbhv17bn-hello-2.12.1.tar.gz.drv
$5 = "/gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz"
--8<---cut here---end--->8---

In this case, the derivation uses the “download” built-in builder:

--8<---cut here---start->8---
scheme@(guile-user)> ,lower (origin
  (method url-fetch)
  (uri "mirror://gnu/hello/hello-2.12.1.tar.gz")
  (sha256 #f))
$6 = # 
/gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz 7f3ff487c000>
scheme@(guile-user)> (derivation-outputs $6)
$7 = (("out" . #< path: 
"/gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz" hash-algo: 
sha256 hash: #f recursive?: #f>))
scheme@(guile-user)> (fixed-output-derivation? $6)
$8 = #f
--8<---cut here---end--->8---

As it turns out, guix-daemon turns off the chroot for all built-in
builders, fixed-output or not; quoth ‘build.cc’:

/* Note: built-in builders are *not* running in a chroot environment so
   that we can easily implement them in Guile without having it as a
   derivation input (they are running under a separate build user,
   though).  */
useChroot = settings.useChroot && !isBuiltin(drv);

I was actually surprised to see this, this wasn’t really intended.  The
good news is that this is safe AFAICS: there’s only one built-in builder
to date, and that’s “download”.

Now I wonder whether we should keep this “feature” or not.  Probably not.

Thoughts?

Besides, we can think about adding more builtins, such as a
“git-download” builtin, which would let us break potential cycles.

Ludo’.

Re: LaTeX packaging policy

[Ludovic Courtès]

Nguyễn Gia Phong  skribis:

> On 2023-01-03 at 10:05+01:00, Ludovic Courtès wrote:
>> But how difficult would it be to identify what needs to be propagated?
>
> Is there any practical reasons to not propagate all TeX packages?
> For other language I suppose we need to avoid version clashing,
> but in my experience TeX packages usually maintain a stable API.

Good question, maybe we should just do that.  Thoughts?

Ludo’.

Re: The Guix Days! (FOSDEM 2023)

[Ludovic Courtès]

Hello,

Pjotr Prins  skribis:

> Just a heads up: we are excited to have Guix days and the FOSDEM
> devroom in Brussels Feb 2-5!!
>
> If you want to attend Guix days, please add to this list (the login is
> a bit hidden). We can only have limited people and catering. If we run
> over the max room number we'll have a problem:
>
> => https://libreplanet.org/wiki/Group:Guix/FOSDEM2023
>
> The programme for the devroom runs partially virtual and partially
> live. The lineup is great as ever:
>
> =>
> https://fosdem.org/2023/schedule/track/declarative_and_minimalistic_computing/

I booked my train, yay!!

It’s that time of the year where we usually have a blog post inviting
people to meet us at FOSDEM and at the Guix Days.  :-)

  https://guix.gnu.org/en/blog/2022/meet-guix-at-fosdem-2022/
  source: 
https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/posts/meet-guix-at-fosdem-2022.md

Who’s in to prepare this year’s post?

Ludo’.

Re: All updaters are broken

[Ludovic Courtès]

Hi!

Hartmut Goebel  skribis:

> Am 03.01.23 um 10:49 schrieb Ludovic Courtès:
>> I tried something different and perhaps simpler: making sure
>> ‘options->update-specs’ always returns a list of , as the
>> name implies, and does the right thing with manifests, -r, and -e.
>> (Part of the patch moves the  definition before its first
>> use.)
>>
>> WDYT?
>
> I'm biased, as this look much like my last proposal :-) plus some good
> simplifications which I would never been able of. Esp. getting rid of
> this (package) function is good, as this function made the
> control-flow obscure,
>
> FMPOV please go ahead and merge.

Ricardo and I discussed it earlier today on IRC; I went ahead and pushed
it as 473692b812b4ab4267d9bddad0fb27787d2112ff and then submitted tests
for the CLI that would have caught these issues:

  https://issues.guix.gnu.org/60520

Ludo’.

Re: GNU Guix 1.4.0 released

[indieterminacy]

On 03-01-2023 19:42, Joshua Branson wrote:

indieterminacy  writes:


On 03-01-2023 10:08, Ludovic Courtès wrote:

Hi!
Maxim Cournoyer  skribis:

Congrats, and yay!  It's a hell of a release! :-) Let's try to make 
more
punctual ones from now on, and also try to lower the amount of 
manual
labor producing one incurs (by streamlining the process), as 
speaking

for me, this was one of the reasons I kept putting it back.

Definitely, let’s see how we can make the process smoother.
In my experience though, a lot of the work is coordination: keeping
track of what needs to be done, open bugs, calling for testing, etc.
I think we should start thinking about the next release, forming a
small release team, and I’ll be happy to mentor!
Thanks,
Ludo’.


Out of curiosity, have you ever approached developing a release from 
the

perspective of doing documentation first?

For example, test driven approaches like BDD or TDD have allowed the
expectations and examples to be worked out first and the the 
implementation

built to form it.

More practically, theres a recent thread concerning different 
approaches and
priorities concerning syntaxes. Also, if during 1.5 there were 
articulations
regarding how existing behaviour does not conform with desired 
behaviour then it
may become easier to divide up tasks into chunks for teams or 
individuals to

work on.

With idealised documentation in place this could provide a point of 
motivation
for developers and avoid any fatigue once the solution is in place as 
the
/drudgery/ of explaining how things work and how they can be used had 
been

worked out in advance.


What areas does guix need more documentation?  To answer that question
for myself, I might say more gexp examples.  Though unmatched-paren is
working on a series of blog posts to dive really deep into that topic.



Over the years in general (ie for whatevever in programming), I tend to 
find documentation examples to provide the easiest way of explaining 
things and this can create shortcomings as creating or maintenan
FWIW, I always need multiple examples for any programming domain but 
this was not the point I was trying to make.
(in any case I learn systems through breaking them, it tends to give me 
a better understanding of systems).


For an idea about documenting before a project, it may be good to create 
diagrams,

as some (like myself) are visually orientated.
Not only can it be a visual assistance, it can also aid recall.
In terms of a project, this may widen the talent pool and improve 
alignment.


In any case, while I cannot comment on the tactics within the OpenBSD 
community
I always considered it a noble thing that no improvements we put into 
their OS

until the features were correctly documented.



While OpenBSD does a pretty good job of documenting everything, I would
also chime in and say that Guix does a fantastic job of translating the
existing documentation into other languages. What do we have
documentation in English, German, French, and significant parts in
Russian and some asian languages. That's pretty stellar!


Yes, indeed!

Seeing this talk in Paris made it very clear how much this is being 
treated seriously.

https://10years.guix.gnu.org/program/#let-s-translate-guix-together-

Thanks for making this point.

Perhaps some people from different language communities require 
assistance in order to build

next generation Guix functionality.
It may be worth lowering the cost of them articulating their needs, 
including
which section within the documentation requires focus for a specific 
language.




Thanks everybody with your work on 1.4.0 !


--
Jonathan McHugh
indieterminacy@libre.brussels

Re: git-fetch without a hash

[Stephen Paul Weber]

However, there's no real reason that git-fetch *needs* to be
fixed-output in terms of having a hash pre-defined, at least for local
development and other purposes.  So is there a way around this?


 • write (package (source (git-checkout …)) …)


This works well.  Now I'm curious how to know what can go in the (source) 
field?  Obviously not just (origin)...



If having a way around it is not desirable should url-fetch consider
this an error as well?


I’m not sure; do you have an example where it’s not behaving as
expected?


Yes.  When using (sha256 #f) url-fetch still has network access and works to 
download things, which is inconsistent vs other fetchers.


signature.asc
Description: PGP signature

Updating Guix's packaged GNU/Hurd

[Joshua Branson]

Hey Guix,

I follow bug-h...@gnu.org pretty religiously (it's super entertaining),
and there has been work on a new cross-hurd branch, which are some
scripts for cross-compiling and creating an up-to-date Hurd system:

https://github.com/flavioc/cross-hurd

Anyone who is interested in updating Guix's GNU Hurd package recipe
might be interested in the above repo.

Thanks,


Joshua

Re: GNU Guix 1.4.0 released

[Joshua Branson]

indieterminacy  writes:

> On 03-01-2023 10:08, Ludovic Courtès wrote:
>> Hi!
>> Maxim Cournoyer  skribis:
>> 
>>> Congrats, and yay!  It's a hell of a release! :-) Let's try to make more
>>> punctual ones from now on, and also try to lower the amount of manual
>>> labor producing one incurs (by streamlining the process), as speaking
>>> for me, this was one of the reasons I kept putting it back.
>> Definitely, let’s see how we can make the process smoother.
>> In my experience though, a lot of the work is coordination: keeping
>> track of what needs to be done, open bugs, calling for testing, etc.
>> I think we should start thinking about the next release, forming a
>> small release team, and I’ll be happy to mentor!
>> Thanks,
>> Ludo’.
>
> Out of curiosity, have you ever approached developing a release from the
> perspective of doing documentation first?
>
> For example, test driven approaches like BDD or TDD have allowed the
> expectations and examples to be worked out first and the the implementation
> built to form it.
>
> More practically, theres a recent thread concerning different approaches and
> priorities concerning syntaxes. Also, if during 1.5 there were articulations
> regarding how existing behaviour does not conform with desired behaviour then 
> it
> may become easier to divide up tasks into chunks for teams or individuals to
> work on.
>
> With idealised documentation in place this could provide a point of motivation
> for developers and avoid any fatigue once the solution is in place as the
> /drudgery/ of explaining how things work and how they can be used had been
> worked out in advance.

What areas does guix need more documentation?  To answer that question
for myself, I might say more gexp examples.  Though unmatched-paren is
working on a series of blog posts to dive really deep into that topic.

> In any case, while I cannot comment on the tactics within the OpenBSD 
> community
> I always considered it a noble thing that no improvements we put into their OS
> until the features were correctly documented.
>

While OpenBSD does a pretty good job of documenting everything, I would
also chime in and say that Guix does a fantastic job of translating the
existing documentation into other languages. What do we have
documentation in English, German, French, and significant parts in
Russian and some asian languages. That's pretty stellar!

>
> Thanks everybody with your work on 1.4.0 !

Re: All updaters are broken

[Hartmut Goebel]

Am 03.01.23 um 10:49 schrieb Ludovic Courtès:

I tried something different and perhaps simpler: making sure
‘options->update-specs’ always returns a list of , as the
name implies, and does the right thing with manifests, -r, and -e.
(Part of the patch moves the  definition before its first
use.)

WDYT?


I'm biased, as this look much like my last proposal :-) plus some good 
simplifications which I would never been able of. Esp. getting rid of 
this (package) function is good, as this function made the control-flow 
obscure,


FMPOV please go ahead and merge.

--
Regards
Hartmut Goebel

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

Has ci.guix.gnu.org stopped building?

[Leo Famulari]

According to the web interface, ci.guix.gnu.org stopped building things
on December 31, with evaluation 79343.

Is this true? What's wrong?

Re: GNU Guix 1.4.0 released

[indieterminacy]

On 03-01-2023 10:08, Ludovic Courtès wrote:

Hi!

Maxim Cournoyer  skribis:

Congrats, and yay!  It's a hell of a release! :-) Let's try to make 
more

punctual ones from now on, and also try to lower the amount of manual
labor producing one incurs (by streamlining the process), as speaking
for me, this was one of the reasons I kept putting it back.


Definitely, let’s see how we can make the process smoother.

In my experience though, a lot of the work is coordination: keeping
track of what needs to be done, open bugs, calling for testing, etc.

I think we should start thinking about the next release, forming a
small release team, and I’ll be happy to mentor!

Thanks,
Ludo’.


Out of curiosity, have you ever approached developing a release from the 
perspective of doing documentation first?


For example, test driven approaches like BDD or TDD have allowed the 
expectations and examples to be worked out first and the the 
implementation built to form it.


More practically, theres a recent thread concerning different approaches 
and priorities concerning syntaxes. Also, if during 1.5 there were 
articulations regarding how existing behaviour does not conform with 
desired behaviour then it may become easier to divide up tasks into 
chunks for teams or individuals to work on.


With idealised documentation in place this could provide a point of 
motivation for developers and avoid any fatigue once the solution is in 
place as the /drudgery/ of explaining how things work and how they can 
be used had been worked out in advance.


In any case, while I cannot comment on the tactics within the OpenBSD 
community I always considered it a noble thing that no improvements we 
put into their OS until the features were correctly documented.


Thanks everybody with your work on 1.4.0 !

--
Jonathan McHugh
indieterminacy@libre.brussels

Re: GNU Guix 1.4.0 released

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès  writes:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> Congrats, and yay!  It's a hell of a release! :-) Let's try to make more
>> punctual ones from now on, and also try to lower the amount of manual
>> labor producing one incurs (by streamlining the process), as speaking
>> for me, this was one of the reasons I kept putting it back.
>
> Definitely, let’s see how we can make the process smoother.
>
> In my experience though, a lot of the work is coordination: keeping
> track of what needs to be done, open bugs, calling for testing, etc.
>
> I think we should start thinking about the next release, forming a
> small release team, and I’ll be happy to mentor!

Great!  I think it'd be nice to have automation as much as possible,
with the end goal of pressing a button and having all the artifacts and
texts (at least templates of the final) produced.

-- 
Thanks,
Maxim

Re: Stratification of GNU Guix into Independent Channels

[zimoun]

Hi,

On Sat, 24 Dec 2022 at 03:49, "jgart"  wrote:

> Users could then decide what channels they'd like to subscribe to/opt
> in to by adding any of the following channels as they please: 
>
> python-channel
> rust-channel
[...]
> etc...
>
> The above channels would still be maintained under the auspices of
> GNU. 
>
> What do you think would be the pros and cons of the stratified
> approach versus the monorepo approach that we currently have?

The Big cons is about maintenance.

It is possible to have a look at the complete current state [1] but it
would be hard, if not impossible, when using many many many channels.
When using other channels [2], time to time it breaks.  Somehow, you
have a combinatorial problem.

Consider that some Git tools are part of one channel and for instance
Julia packages are part of another channel.  The update of Git from its
channel could have an impact on the packages defined in some other
channels; for concrete case: Git update from 2.38.0 to 2.38.1 breaks
julia-documenter [3].  Using few channels, it makes doable to tackle
such issues (guix refresh, guix graph, etc.).  Using many many channels,
it makes it hard to detect; although CI and QA are improving a lot and
for sure they can help, the situation is not good enough yet, IMHO.

Moreover, many channels would be dependant from one to the other.  Give
a look at (gnu packages python-xyz).  If the packages defined here would
become the channel ’python-channel’ then this ’python-channel’ would
depend on many others – this (gnu packages python-xyz) module requires
103 other (gnu packages …) modules.

Concretely, the split would be a painful, boring and tedious work where
I am doubtful about the practical outcome.

>From my point of view, solutions for improving the situation of “guix
pull” are:

 + more modular; maybe split *package-modules* in (guix self)
 
 + transform subcommands as extensions; here we would have a better
   control for the Guix feature dependencies via the Scheme API


1: 
2: 
3: 

Cheers,
simon

Re: All updaters are broken

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

> Okay.  Here’s something simpler using “partition”:
>
> commit 96fb123832b262a3453fe1b7646758da235a343e
> Author: Ricardo Wurmus 
> Date:   Tue Jan 3 10:14:52 2023 +0100
>
> WIP
>
> diff --git a/guix/scripts/refresh.scm b/guix/scripts/refresh.scm
> index e0b94ce48d..bbda2df35a 100644
> --- a/guix/scripts/refresh.scm
> +++ b/guix/scripts/refresh.scm
> @@ -183,9 +183,9 @@ (define (show-help)
>(newline)
>(show-bug-report-information))
>  
> -(define (options->update-specs opts)
> -  "Return the list of packages requested by OPTS, honoring options like
> -'--recursive'."
> +(define (options->packages+update-specs opts)
> +  "Return the list of packages and update-specs requested by OPTS, honoring
> +options like '--recursive'."
>(define core-package?
>  (let* ((input->package (match-lambda
>   ((name (? package? package) _ ...) package)
> @@ -220,7 +220,7 @@ (define (keep-newest package lst)
>  (_
>   (cons package lst)
>  
> -  (define args-packages
> +  (define args-packages+update-specs
>  ;; Packages explicitly passed as command-line arguments.
>  (match (filter-map (match-lambda
>   (('argument . spec)
> @@ -244,17 +244,18 @@ (define args-packages
>(some   ;user-specified packages
> some)))
>  
> -  (define packages
> +  (define packages+update-specs
>  (match (assoc-ref opts 'manifest)
> -  (#f args-packages)
> +  (#f args-packages+update-specs)
>((? string? file) (packages-from-manifest file

I tried something different and perhaps simpler: making sure
‘options->update-specs’ always returns a list of , as the
name implies, and does the right thing with manifests, -r, and -e.
(Part of the patch moves the  definition before its first
use.)

WDYT?

This is on top of , which also
clarified a couple of things.

After that I’d like to thing about tests for the CLI.

Thanks,
Ludo’.

diff --git a/guix/scripts/refresh.scm b/guix/scripts/refresh.scm
index 65c3ce9c16..9438df870d 100644
--- a/guix/scripts/refresh.scm
+++ b/guix/scripts/refresh.scm
@@ -183,9 +183,31 @@ (define (show-help)
   (newline)
   (show-bug-report-information))
 
+
+;;;
+;;; Utilities.
+;;;
+
+(define-record-type 
+  (%update-spec package version)
+  update?
+  (package update-spec-package)
+  (version update-spec-version))
+
+(define* (update-spec package #:optional version)
+  (%update-spec package version))
+
+(define (update-specification->update-spec spec)
+  "Given SPEC, a package name like \"guile@2.0=2.0.8\", return a 
+record with two fields: the package to upgrade, and the target version."
+  (match (string-rindex spec #\=)
+(#f  (update-spec (specification->package spec) #f))
+(idx (update-spec (specification->package (substring spec 0 idx))
+  (substring spec (1+ idx))
+
 (define (options->update-specs opts)
-  "Return the list of packages requested by OPTS, honoring options like
-'--recursive'."
+  "Return the list of  records requested by OPTS, honoring
+options like '--recursive'."
   (define core-package?
 (let* ((input->package (match-lambda
  ((name (? package? package) _ ...) package)
@@ -220,60 +242,43 @@ (define (keep-newest package lst)
 (_
  (cons package lst)
 
-  (define args-packages
-;; Packages explicitly passed as command-line arguments.
-(match (filter-map (match-lambda
+  (define update-specs
+;; Update specs explicitly passed as command-line arguments.
+(match (append-map (match-lambda
  (('argument . spec)
   ;; Take either the specified version or the
   ;; latest one.
-  (update-specification->update-spec spec))
+  (list (update-specification->update-spec spec)))
  (('expression . exp)
-  (read/eval-package-expression exp))
- (_ #f))
+  (list (update-spec (read/eval-package-expression exp
+ (('manifest . manifest)
+  (map update-spec (packages-from-manifest manifest)))
+ (_
+  '()))
opts)
   (() ;default to all packages
(let ((select? (match (assoc-ref opts 'select)
 ('core core-package?)
 ('non-core (negate core-package?))
 (_ (const #t)
- (fold-packages (lambda (package result)
-  (if (select? package)
-  (keep-newest package result)
-  result))
-'(
+ (map update-spec
+  

Re: All updaters are broken

[Ricardo Wurmus]

Hi Hartmut,

> Am 02.01.23 um 20:17 schrieb Ricardo Wurmus:
>
>  Thanks for providing the patch. For me this looks huge and hard to
> maintain.
>
> “Hard to maintain”?  How so?
>
> For me this double structure is hard to understand and thus to maintain. YMMV.

Okay.  Here’s something simpler using “partition”:

commit 96fb123832b262a3453fe1b7646758da235a343e
Author: Ricardo Wurmus 
Date:   Tue Jan 3 10:14:52 2023 +0100

WIP

diff --git a/guix/scripts/refresh.scm b/guix/scripts/refresh.scm
index e0b94ce48d..bbda2df35a 100644
--- a/guix/scripts/refresh.scm
+++ b/guix/scripts/refresh.scm
@@ -183,9 +183,9 @@ (define (show-help)
   (newline)
   (show-bug-report-information))
 
-(define (options->update-specs opts)
-  "Return the list of packages requested by OPTS, honoring options like
-'--recursive'."
+(define (options->packages+update-specs opts)
+  "Return the list of packages and update-specs requested by OPTS, honoring
+options like '--recursive'."
   (define core-package?
 (let* ((input->package (match-lambda
  ((name (? package? package) _ ...) package)
@@ -220,7 +220,7 @@ (define (keep-newest package lst)
 (_
  (cons package lst)
 
-  (define args-packages
+  (define args-packages+update-specs
 ;; Packages explicitly passed as command-line arguments.
 (match (filter-map (match-lambda
  (('argument . spec)
@@ -244,17 +244,18 @@ (define args-packages
   (some   ;user-specified packages
some)))
 
-  (define packages
+  (define packages+update-specs
 (match (assoc-ref opts 'manifest)
-  (#f args-packages)
+  (#f args-packages+update-specs)
   ((? string? file) (packages-from-manifest file
 
   (if (assoc-ref opts 'recursive?)
+  (let ((packages update-specs (partition package? packages+update-specs)))
 (mlet %store-monad ((edges (node-edges %bag-node-type
(all-packages
-(return (node-transitive-edges packages edges)))
+  (return (append (node-transitive-edges packages edges) update-specs
   (with-monad %store-monad
-(return packages
+(return packages+update-specs
 
 
 ;;;
@@ -561,12 +562,13 @@ (define (options->updaters opts)
 (with-error-handling
   (with-store store
 (run-with-store store
-  (mlet %store-monad ((update-specs (options->update-specs opts)))
+  (mlet %store-monad ((packages+update-specs (options->packages+update-specs opts)))
+(let ((packages update-specs (partition package? packages+update-specs)))
   (cond
(list-dependent?
-  (list-dependents (map update-spec-package update-specs)))
+(list-dependents (append packages (map update-spec-package update-specs
(list-transitive?
-  (list-transitive (map update-spec-package update-specs)))
+(list-transitive (append packages (map update-spec-package update-specs
(update?
 (parameterize ((%openpgp-key-server
 (or (assoc-ref opts 'key-server)
@@ -587,9 +589,18 @@ (define (options->updaters opts)
  #:key-download key-download
  #:warn? warn?))
update-specs)
+  (for-each
+   (lambda (package)
+ (update-package store
+ package
+ #false
+ updaters
+ #:key-download key-download
+ #:warn? warn?))
+   packages)
   (return #t)))
(else
 (for-each (cut check-for-package-update <> updaters
#:warn? warn?)
-(map update-spec-package update-specs))
-  (return #t)
+  (append packages (map update-spec-package update-specs)))
+(return #t))

(This patch ignores white-space.) 

Here’s the patch with white-space changes:

commit 96fb123832b262a3453fe1b7646758da235a343e
Author: Ricardo Wurmus 
Date:   Tue Jan 3 10:14:52 2023 +0100

WIP

diff --git a/guix/scripts/refresh.scm b/guix/scripts/refresh.scm
index e0b94ce48d..bbda2df35a 100644
--- a/guix/scripts/refresh.scm
+++ b/guix/scripts/refresh.scm
@@ -183,9 +183,9 @@ (define (show-help)
   (newline)
   (show-bug-report-information))
 
-(define (options->update-specs opts)
-  "Return the list of packages requested by OPTS, honoring options like
-'--recursive'."
+(define (options->packages+update-specs opts)
+  "Return the list of packages and update-specs requested by OPTS, honoring
+options like '--recursive'."
   (define core-package?
 

Re: LaTeX packaging policy

[Nguyễn Gia Phong]

On 2023-01-03 at 10:05+01:00, Ludovic Courtès wrote:
> But how difficult would it be to identify what needs to be propagated?

Is there any practical reasons to not propagate all TeX packages?
For other language I suppose we need to avoid version clashing,
but in my experience TeX packages usually maintain a stable API.

Re: GNU Guix 1.4.0 released

[Ludovic Courtès]

Hi!

Maxim Cournoyer  skribis:

> Congrats, and yay!  It's a hell of a release! :-) Let's try to make more
> punctual ones from now on, and also try to lower the amount of manual
> labor producing one incurs (by streamlining the process), as speaking
> for me, this was one of the reasons I kept putting it back.

Definitely, let’s see how we can make the process smoother.

In my experience though, a lot of the work is coordination: keeping
track of what needs to be done, open bugs, calling for testing, etc.

I think we should start thinking about the next release, forming a
small release team, and I’ll be happy to mentor!

Thanks,
Ludo’.

Re: build-system-modules

[Ludovic Courtès]

Hi,

Nicolas Graves via "Development of GNU Guix and the GNU System
distribution."  skribis:

> I met a packaging error two times when hacking guile or maven packages,
> where after using the #:modules flag in arguments, I found myself with
> gnu build-system packaging phases instead of guile or maven build-system
> modules. When inverting the modules order, I don't have this error
> anymore. I would like to invert them, except if there's a reason against
> it.
>
> Codelines I'm referring to :
>
>  (define %guile-build-system-modules
>;; Build-side modules imported by default.
> -  `((guix build guile-build-system)
> -,@%gnu-build-system-modules))
> +  `(,@%gnu-build-system-modules
> +(guix build guile-build-system)))
>
>
>  (define %maven-build-system-modules
>;; Build-side modules imported by default.
> -  `((guix build maven-build-system)
> -(guix build maven pom)
> -,@%gnu-build-system-modules))
> +  `(,@%gnu-build-system-modules
> +(guix build maven-build-system)
> +(guix build maven pom)))

Maybe you’re confusing #:imported-modules and #:modules?

The former says which modules are made available in the build
environment, so the order doesn’t matter; ‘%guile-build-system-modules’
is the default value of #:imported-modules.

Conversely, #:modules says which modules are in scope; it’s usually a
subset of #:imported-modules.  In that case, you can also pass #:hide,
#:select, etc. as in:

  #:modules (((guix build gnu-build-system) #:hide (%standard-phases))
 (guix build mavent-build-system))

Does that make sense?

Thanks,
Ludo’.

Re: LaTeX packaging policy

[Ludovic Courtès]

Hello!

Josselin Poiret  skribis:

> While using a bit of LaTeX recently, I've noticed some packages don't
> work "out-of-the-box", at least on LuaLaTeX, and need some additional
> propagated inputs.  Examples would be babel-french needing scalefnt,
> fontspec needing luaotfload, or hyperref needing stringenc.  Is there
> any established policy for what propagated-inputs need to be included in
> package definitions?  Should we add some LaTeX specific packaging
> guidelines in the manual, like for Python or Rust (the former is
> outdated by the way, mentioning Python 2 packages).

I noticed the lack of propagated inputs for some packages.

I don’t think there’s an established policy.  Ideally, to mimic what’s
done with other languages and to make things work out of the box, we’d
propagate anything that’s needed.  But how difficult would it be to
identify what needs to be propagated?

Thanks,
Ludo’.