Re: No default OpenJDK version?

[Julien Lepiller]

I think the first step would be to target openjdk 9, since it already 
introduces quite a lot of changes compared to java 8. To do it, I would suggest 
to change the default jdk in the ant-build-system and maven-build-system, and 
see what is broken, if it can simply be updated without breaking dependents, or 
if it (and its dependencies) needs to be built with an older jdk.

Some packages are bootstrap packages that are quite old and will never support 
a newer jdk. For some of them, we can simply specify a source/target level (not 
sure it's supported by the build-system yet), but I remember trying and a few 
need java 5, which is no longer a supported level.

I have already added support for java modules in the ant-build-system, and I 
just pushed a few updates to some packages that could not previously be built 
with java 9.

Le 20 avril 2024 19:19:37 GMT+02:00, Markku Korkeala  a 
écrit :
>On Tue, Apr 16, 2024 at 10:37:30PM +0200, Julien Lepiller wrote:
>> Currently, most java packages use the implicit jdk from the build system 
>> (ant- or maven-build-system), which is… icedtea@8. We still have quite a lot 
>> of old packages that don't build with openjdk9, so I'm not sure when we can 
>> update the default jdk…
>
>Hi,
>
>is there effort to update the default jdk at some point? I could help with
>it. I'm not familiar with the guix java build systems, but have long
>experience as a Java developer. I also maintain few java packages in Fedora
>and saw the transition to to jdk11 [1], jdk17 [2] and now to jdk21 [3]. The
>pages have documented common issues and workarounds, which might help.
>
>[1]: https://fedoraproject.org/wiki/Changes/Java11
>[2]: https://fedoraproject.org/wiki/Changes/Java17
>[3]: https://fedoraproject.org/wiki/Changes/Java21
>
>Best wishes,
>Markku
>
>> Le 16 avril 2024 22:25:33 GMT+02:00, Vagrant Cascadian 
>>  a écrit :
>> >When recently taking a look at diffoscope, I was reminded that there is
>> >effectively no default openjdk version, you have to pick a specific
>> >version for each package definition...
>> >
>> >At some time in diffoscope's history, that was openjdk@12.
>> >
>> >But there are quite a few versions to choose from:
>> >
>> >  guix package -A openjdk | sort -V
>> >  openjdk 9.181   out,jdk,doc gnu/packages/java.scm:869:2
>> >  openjdk 10.46   out,jdk,doc gnu/packages/java.scm:1140:2
>> >  openjdk 11.0.22 out,jdk,doc gnu/packages/java.scm:1218:2
>> >  openjdk 12.33   out,jdk,doc gnu/packages/java.scm:1536:2
>> >  openjdk 13.0.14 out,jdk,doc gnu/packages/java.scm:1576:2
>> >  openjdk 14.0.2  out,jdk,doc gnu/packages/java.scm:1583:2
>> >  openjdk 15.0.10 out,jdk,doc gnu/packages/java.scm:1598:2
>> >  openjdk 16.0.2  out,jdk,doc gnu/packages/java.scm:1617:2
>> >  openjdk 17.0.10 out,jdk,doc gnu/packages/java.scm:1625:2
>> >  openjdk 18.0.2.1out,jdk,doc gnu/packages/java.scm:1642:2
>> >  openjdk 19.0.2  out,jdk,doc gnu/packages/java.scm:1646:2
>> >  openjdk 20.0.2  out,jdk,doc gnu/packages/java.scm:1663:2
>> >  openjdk 21.0.2  out,jdk,doc gnu/packages/java.scm:1667:2
>> >
>> >Some packages may only work with a specific era of openjdk, but I
>> >suspect many of the packages in guix just picked whatever version
>> >happened to be present when it was added to guix.
>> >
>> >Which makes it hard to know when to update the openjdk dependency...
>> >
>> >In the diffoscope case, it seems to have work fine with openjdk@21, with
>> >the only result being that some openjdk-version-specific tests pass and
>> >some are skipped as a one-for-one trade compared to the old openjdk@12.
>> >
>> >Alternately, I would be tempted to switch to openjdk@17, which is the
>> >current default in Debian, so has a little more testing behind it...
>> >
>> >Though there is a bit of a perverse incentive to stick with the oldest
>> >version that still works, due to openjdk having a very long bootstrap
>> >chain of itself...
>> >
>> >And then the question gets to be of diffoscope's dependencies, what
>> >versions of openjdk do they pull in (notably enjarify, which uses
>> >openjdk@12, although that also seems to work ok with openjdk@21)?
>> >
>> >
>> >Would it make sense to have an openjdk "default" version, so packages
>> >could instead depend on that, and only need to specify a version if
>> >needed for some particular reason? Or is compatibility across openjdk
>> >versions troublesome enough that it really always needs to be handled on
>> >a case-by-case basis?
>> >
>> >
>> >live well,
>> >  vagrant
>> 

Re: No default OpenJDK version?

[Julien Lepiller]

Makes sense, we can do that.

Le 16 avril 2024 23:50:54 GMT+02:00, Vagrant Cascadian 
 a écrit :
>On 2024-04-16, Julien Lepiller wrote:
>> Currently, most java packages use the implicit jdk from the build
>> system (ant- or maven-build-system), which is… icedtea@8. We still
>> have quite a lot of old packages that don't build with openjdk9, so
>> I'm not sure when we can update the default jdk…
>
>But for the packages that explicitly need to pull in openjdk:
>
>  git grep 'openjdk[1-9]' | grep -v define-public | grep -v java.scm | nl
> 1  gnu/packages/android.scm:(native-inputs (list openjdk12))
> 2  gnu/packages/apl.scm:(inputs (list bash-minimal openjdk18))
> 3  gnu/packages/apl.scm:(native-inputs (list `(,openjdk18 "jdk") zip))
> 4  gnu/packages/axoloti.scm: `(("openjdk" ,openjdk11 "jdk")
> 5  gnu/packages/bioconductor.scm: (list (list openjdk11 "jdk")
> 6  gnu/packages/bioinformatics.scm:   #:jdk openjdk11))
> 7  gnu/packages/cran.scm:   ("jdk" ,openjdk11 "jdk")
> 8  gnu/packages/diffoscope.scm: (list `(,openjdk12 "jdk")
> 9  gnu/packages/emacs-xyz.scm:   (list emacs-ecukes emacs-espuds 
> emacs-undercover openjdk9))
>10  gnu/packages/geo.scm:   openjdk11))
>11  gnu/packages/geo.scm:   #:jdk ,openjdk11
>12  gnu/packages/groovy.scm:   #:jdk ,openjdk9
>13  gnu/packages/groovy.scm:   #:jdk ,openjdk9
>14  gnu/packages/groovy.scm:   #:jdk ,openjdk9
>15  gnu/packages/groovy.scm:   #:jdk ,openjdk9
>16  gnu/packages/groovy.scm:   #:jdk ,openjdk9
>17  gnu/packages/gstreamer.scm:   ("openjdk" ,openjdk14)
>18  gnu/packages/gstreamer.scm:   ("openjdk:jdk" ,openjdk14 "jdk")
>19  gnu/packages/java-compression.scm:   #:jdk ,openjdk9
>20  gnu/packages/kodi.scm:   openjdk9 ;like 
> groovy
>21  gnu/packages/mpi.scm: `(("jdk" ,openjdk11 "jdk")
>22  gnu/packages/pep.scm:   `(,openjdk9 "jdk") which yml2))
>
>
>It is not a crazy number of packages, but in cases like diffoscope and
>enjarify, which seem fairly compatible with arbitrary versions, it would
>be nice to have an unversioned option to specify?
>
>Maybe I confused things by talking about the "default" version, I guess
>I was wondering if it would make sense for an "openjdk-latest" or
>"openjdk-lts" or whatever color you want, just as long as it does not
>require specifying (and more importantly, keeping track of) the version
>of openjdk needed.
>
>live well,
>  vagrant

Re: No default OpenJDK version?

[Julien Lepiller]

Currently, most java packages use the implicit jdk from the build system (ant- 
or maven-build-system), which is… icedtea@8. We still have quite a lot of old 
packages that don't build with openjdk9, so I'm not sure when we can update the 
default jdk…

Le 16 avril 2024 22:25:33 GMT+02:00, Vagrant Cascadian 
 a écrit :
>When recently taking a look at diffoscope, I was reminded that there is
>effectively no default openjdk version, you have to pick a specific
>version for each package definition...
>
>At some time in diffoscope's history, that was openjdk@12.
>
>But there are quite a few versions to choose from:
>
>  guix package -A openjdk | sort -V
>  openjdk 9.181   out,jdk,doc gnu/packages/java.scm:869:2
>  openjdk 10.46   out,jdk,doc gnu/packages/java.scm:1140:2
>  openjdk 11.0.22 out,jdk,doc gnu/packages/java.scm:1218:2
>  openjdk 12.33   out,jdk,doc gnu/packages/java.scm:1536:2
>  openjdk 13.0.14 out,jdk,doc gnu/packages/java.scm:1576:2
>  openjdk 14.0.2  out,jdk,doc gnu/packages/java.scm:1583:2
>  openjdk 15.0.10 out,jdk,doc gnu/packages/java.scm:1598:2
>  openjdk 16.0.2  out,jdk,doc gnu/packages/java.scm:1617:2
>  openjdk 17.0.10 out,jdk,doc gnu/packages/java.scm:1625:2
>  openjdk 18.0.2.1out,jdk,doc gnu/packages/java.scm:1642:2
>  openjdk 19.0.2  out,jdk,doc gnu/packages/java.scm:1646:2
>  openjdk 20.0.2  out,jdk,doc gnu/packages/java.scm:1663:2
>  openjdk 21.0.2  out,jdk,doc gnu/packages/java.scm:1667:2
>
>Some packages may only work with a specific era of openjdk, but I
>suspect many of the packages in guix just picked whatever version
>happened to be present when it was added to guix.
>
>Which makes it hard to know when to update the openjdk dependency...
>
>In the diffoscope case, it seems to have work fine with openjdk@21, with
>the only result being that some openjdk-version-specific tests pass and
>some are skipped as a one-for-one trade compared to the old openjdk@12.
>
>Alternately, I would be tempted to switch to openjdk@17, which is the
>current default in Debian, so has a little more testing behind it...
>
>Though there is a bit of a perverse incentive to stick with the oldest
>version that still works, due to openjdk having a very long bootstrap
>chain of itself...
>
>And then the question gets to be of diffoscope's dependencies, what
>versions of openjdk do they pull in (notably enjarify, which uses
>openjdk@12, although that also seems to work ok with openjdk@21)?
>
>
>Would it make sense to have an openjdk "default" version, so packages
>could instead depend on that, and only need to specify a version if
>needed for some particular reason? Or is compatibility across openjdk
>versions troublesome enough that it really always needs to be handled on
>a case-by-case basis?
>
>
>live well,
>  vagrant

Re: Trying to use guix-android

[Julien Lepiller]

no code for module (android import repo)

Looks like you don't have guix-android after all. Can you check with guix 
describe?

Le 20 février 2024 18:49:59 GMT+01:00, Tobias Alexandra Platen 
 a écrit :
>I added the guix-android channel[1] and did a guix pull.
>Then in a new terminal window I started guix repl,
>and followed the instructions in the readme.
>
>But I got a:
>
>guix repl
>GNU Guile 3.0.9
>Copyright (C) 1995-2023 Free Software Foundation, Inc.
>
>Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>This program is free software, and you are welcome to redistribute it
>under certain conditions; type `,show c' for details.
>
>Enter `,help' for help.
>scheme@(guix-user)> ,use (android import repo)
>While executing meta-command:
>no code for module (android import repo)
>scheme@(guix-user)> (let ((manifest (get-manifest)))
>  (fetch-manifest-repositories manifest))
>;;; :2:17: warning: possibly unbound variable `get-manifest'
>;;; :3:3: warning: possibly unbound variable `fetch-manifest-
>repositories'
>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>error: get-manifest: unbound variable
>
>Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>scheme@(guix-user) [1]>
>
>So for now I fall back to repo and download from[2].
>
>
>
>[1] https://framagit.org/tyreunom/guix-android
>[2] https://github.com/LineageOS/android.git
>

Re: Meeting in Brussels on Wednesday night?

[Julien Lepiller]

I'll join you at some point :)

Le 31 janvier 2024 17:21:40 GMT+01:00, Christopher Baines  a 
écrit :
>
>Ludovic Courtès  writes:
>
>> To those traveling to Brussels tomorrow: who’s in to meet in our lair,
>> namely Au Bon Vieux Temps, on Wednesday evening/night?  :-)
>>
>>   
>> https://www.openstreetmap.org/?mlat=50.84832=4.35237#map=20/50.84832/4.35237=Y
>>
>> I should be able to be there around 9:30–10PM.
>
>I'm in, I'll probably be there a little earlier as well, maybe around
>20:00 to 20:30.

Re: Discontinuing data.guix.gnu.org?

[Julien Lepiller]

In terms of finance, our last blocker is that I still don't have access to the 
account, but Andreas does, so we should be able to take responsibility for the 
cost relatively easily.

Ideally, we would take ownership of the machine(s), so we don't overcomplicate 
our finances by having to reimburse someone regularly.

Le 9 janvier 2024 19:12:44 GMT+01:00, "Ludovic Courtès"  a écrit :
>Hello Christopher,
>
>Christopher Baines  skribis:
>
>> Ludovic Courtès  writes:
>
>[...]
>
>>> Christopher Baines  skribis:
>>>
 As previously set out, I'm planning to stop hosting the data service
 instances this year. While I would like to stop hosting the server for
 data.guix.gnu.org,
>>>
>>> I forgot the outcome of previous discussions, but it seems to me that
>>> the service itself and all the data it accumulated over the years are
>>> super valuable.  I would be sad to see it go!
>>
>> There was a discussion back in April, but no action came directly from
>> it.
>>
>> Just having data.qa.guix.gnu.org was discussed, and at least
>> concentrating on getting to a sustainable hosting situation there seemed
>> like a sensible priority. The longer history provided by
>> data.guix.gnu.org does have value though in my view.
>>
>>> Is there something we can do to not lose it all?  It could be
>>> distributing responsibility, reducing the scope, ensuring hosting is
>>> managed collectively by the project, etc.  WDYT?
>>
>> Since that discussion, I have disabled the database dumps and backups,
>> which has reduced (to 62€ per month) the hosting costs (although
>> obviously not having backups isn't ideal). It's possible to further
>> reduce the hosting costs as well by switching away from a VM to a
>> physical machine at Hetzner.
>>
>> But yeah, given that having at least one data service instance is a key
>> part of keeping the bordeaux build farm running, managing the hosting
>> through the project seems to be the way to go. I'm just not sure how we
>> can get there, or what I can do to move things in that direction.
>
>Like you, I would have hoped for more reactions.  Unfortunately, I’m not
>offering to help here because I have more than enough on my plate and
>even a 1+ month backlog on guix-devel…
>
>Maintainers, what’s your take on this?
>
>Guix Foundation, is there any blocker to taking responsibility for
>covering hosting expenses, possibly rediscussing the scope and cost?
>
>Let 2024 be a thriving Guix year! :-)
>
>Ludo’.
>

Re: Update weblate.

[Julien Lepiller]

Hi,

GNU Health is not under the responsibility of the Guix project. You should 
contact them instead

Le 13 décembre 2023 23:35:32 GMT+01:00, Feng Shu  a écrit :
>
>https://hosted.weblate.org/projects/gnu-health seem to not be updated,
>when sync health hg to it?
>

Re: Western US mirroring?

[Julien Lepiller]

Sounds like a great idea!

Le 10 décembre 2023 02:19:16 GMT+01:00, Andy Tai  a écrit :
>Hi, just an idea:
>
>The GNU Guix project currently has a substitution server mirror in the
>East coast of the US.
>
>No mirror in the Western US.
>
>The OSU Open Source Lib (https://osuosl.org/) offers hosting resources
>to FOSS projects...
>https://osuosl.org/services/
>
>Maybe the GNU Guix project can request hosting service from them, to
>have a substitution mirror, for example, so more resources can be
>available for downloading of artifacts for Guix users...
>
>Maybe this can be expanded later to have more services for Guix and
>other GNU projects in the West coast of the US, in cooperation with
>the FSF IT?
>
>Wonder if the idea is OK.
>

Re: How to get nginx and letsencrypt working on the guix system

[Julien Lepiller]

Usually, this is fixed by not uting ssl at first, let certbot generate 
certificates, and reconfigure with ssl.

Le 31 octobre 2023 19:23:32 GMT+01:00, Tobias Alexandra Platen 
 a écrit :
>I installed the guix system on a virtual machine, and changed the
>config as documented in the guix manual under 12.9.19 Web Services:
>
>(service certbot-service-type
>(certbot-configuration
>(email "tpla...@posteo.de")
>(certificates (list (certificate-
>configuration
>(domains '("stream.isengaara.de")) (deploy-hook
>%nginx-deploy-hook))
> ;;; nginx testing
> (service nginx-service-type 
>(nginx-configuration
>  (server-blocks
>(list (nginx-server-configuration
>  (server-name '("stream.isengaara.de"))
>(root "/srv/http/stream.isengaara.de"))
>
>Certbot needs running nginx to create a certificate, and nginx wont
>start without a certificate. The documentation does not explain how
>to solve this circular service dependency.
>

Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19

[Julien Lepiller]

The print service I usually use has a lot of options for flyers, 
{10,15,20,30}*{10,15,20,30}, 12*12, 21*29.7 and 30*40 cm. I think 15*20 would 
be best.

Visit cards would be 3.5*7.5, 5.5*8.5 or 5*9 cm

Le 25 octobre 2023 22:37:00 GMT+02:00, Luis Felipe  a écrit :
>Hi,
>
>El 25/10/23 a las 18:11, Julien Lepiller escribió:
>> 
>> Le 25 octobre 2023 09:09:46 GMT+02:00, Andreas Enge  a 
>> écrit :
>>> Am Tue, Oct 24, 2023 at 10:17:01PM +0200 schrieb Vivien Kraus:
>>>>> Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19
>>>>> november for Capitole du Libre:
>>>>> We will stand in Village Associatif.  Let us know if you can help us
>>>>> at the event.  Well, I do not know exactly what means "a stand" since
>>>>> it will be the first for me. :-)  I guess it mainly consists to be
>>>>> around the Guix booth, chat with people about why Guix is awesome!
>>>>> and
>>>>> maybe demo some Guix features.
>>>>> Feel free to share your ideas. :-)
>>> Personally I am always drawn to strange hardware. So if anyone coming
>>> has a single board computer running Guix (Guix system?), this would be
>>> nice to show. Actually we would also need a screen then; I have a spare
>>> one, but it would be difficult to transport by bus and train.
>> I'll be there and since I live in Toulouse, I can bring a screen if 
>> necessary. I already planned to help oith the OSM stand though, so I 
>> probably won't stay long on the Guix stand.
>> 
>>> We need stickers! Julien, were you not the one buying our latest batch?
>> I had a batch of square stickers that lasted for a few years, but I managed 
>> to get rid of it during our last guix days. I'll order some more, they'll be 
>> useful for futuse events too.
>> 
>>> Maybe we could order more, we should have Guix Foundation pay for it.
>>> 
>>> We need flyers! Maybe print a number of reference cards? It looks like the
>>> project is missing a promotional flyer to be given to attract newcomers.
>> I can order flyers, visit cards or anything else, but I'd need help with the 
>> design.
>I think I can help, but I'd need to know about the dimensions for flyers and 
>visit cards the printer can handle, and your preferred size (if there's more 
>than one option).

Re: Meet Guix at Capitole du Libre in Toulouse, nov. 18-19

[Julien Lepiller]

Le 25 octobre 2023 09:09:46 GMT+02:00, Andreas Enge  a écrit :
>Am Tue, Oct 24, 2023 at 10:17:01PM +0200 schrieb Vivien Kraus:
>> > Some of us will be in Toulouse, INP-N7, 26 rue Riquet on 18 & 19
>> > november for Capitole du Libre:
>> > We will stand in Village Associatif.  Let us know if you can help us
>> > at the event.  Well, I do not know exactly what means "a stand" since
>> > it will be the first for me. :-)  I guess it mainly consists to be
>> > around the Guix booth, chat with people about why Guix is awesome!
>> > and
>> > maybe demo some Guix features.
>> > Feel free to share your ideas. :-)
>
>Personally I am always drawn to strange hardware. So if anyone coming
>has a single board computer running Guix (Guix system?), this would be
>nice to show. Actually we would also need a screen then; I have a spare
>one, but it would be difficult to transport by bus and train.

I'll be there and since I live in Toulouse, I can bring a screen if necessary. 
I already planned to help oith the OSM stand though, so I probably won't stay 
long on the Guix stand.

>We need stickers! Julien, were you not the one buying our latest batch?

I had a batch of square stickers that lasted for a few years, but I managed to 
get rid of it during our last guix days. I'll order some more, they'll be 
useful for futuse events too.

>Maybe we could order more, we should have Guix Foundation pay for it.
>
>We need flyers! Maybe print a number of reference cards? It looks like the
>project is missing a promotional flyer to be given to attract newcomers.

I can order flyers, visit cards or anything else, but I'd need help with the 
design.

>
>> Je compte bien y aller !
>
>Chouette! L'idée serait que plus on est nombreux, plus on peut alterner
>sur le stand et aussi profiter nous-mêmes de quelques présentations et
>autres stands. Je viens les deux jours, mais arrive assez tard samedi
>(11h27 à la gare) et repars assez tôt dimanche (17h24 de la gare).
>
>Andreas
>
>

Re: Ideas for ocaml-team

[Julien Lepiller]

I don't think it makes sense to have a separate brarch when we have so few 
contributions, and so few impacted packages

Le 12 septembre 2023 08:57:56 GMT+02:00, pukkamustard  
a écrit :
>
>Salut!
>
>Simon Tournier  writes:
>
>>> I think it's time to start an `ocaml-team` (or `ocaml-updates`) branch
>>> to collect some bigger updates and changes to the OCaml packages in
>>> Guix.
>>
>> I think that’s a great idea. :-)  Any progress on this?
>>
>
>There is #64249 (https://issues.guix.gnu.org/64249) to which I just
>submitted a v6.
>
>>> * Remove most ocaml4.07-* and ocaml4.09 packages
>>>   - We only want to keep the compiler around for bootstrapping purposes.
>>
>> Currently camlboot is used by ocaml-4.07-boot used by ocaml-4.07.  But
>> then version 4.09 and later and not bootstrapped; well they use the
>> upstream bootstrap (which is boot/ocamlc and friends IIRC).
>>
>> Well, independently of this upgrade plan, the OCaml bootstrap could be
>> the chain 4.07 -> 4.09 -> … and I do not know if 4.09 would be enough
>> for 4.14.  And if 4.14 would also be enough for 5.
>
>I don't know either and I don't think I will have time to look into this
>soonish.
>
>I think placing the 4.07 and 4.09 compiler in (gnu packages ocaml-boot),
>even if unused, seems reasonable. We should add some nice
>comments/breadcrumbs for whoever looks into completing the chain in the
>future.
>
>> That’s said, aside this bootstrapping consideration, I am in favor to
>> remove 4.07 and 4.09 OCaml packages.
>
>Ack
>
>> Do we create the branch ocaml-team for doing this plan?
>
>Just asked a similar question in the cover for the v6 to
>#64249. Basically I don't know how fast I/we will be able to look into
>the other items in this list. Maybe it makes sense to just merge in to
>master instead of having a too long-lived ocaml-team branch? Or set a
>pre-defined time-to-live for the branch? What's the current modus
>operandi for other teams?
>
>Cheers,
>pukkamustard

Re: guix build from git failure: missing sections in German, French, etc. doc translations？

[Julien Lepiller]

Hi Andy,

Thanks for the report! You might need a more recent po4a for it to work 
properly. Could try to guix pull, and enter a new shell for building guix?

Le 8 septembre 2023 20:43:05 GMT+02:00, Andy Tai  a écrit :
>Checking out the latest origin/master head, building guix fails:
>
>make[2]: Entering directory '/share/software/guix/guix.git/po/packages'
>make[2]: Nothing to be done for 'all'.
>make[2]: Leaving directory '/share/software/guix/guix.git/po/packages'
>make[2]: Entering directory '/share/software/guix/guix.git'
>  MAKEINFO doc/guix.info
>  MAKEINFO doc/guix.de.info
>  MAKEINFO doc/guix.fr.info
>  MAKEINFO doc/guix.es.info
>  MAKEINFO doc/guix.pt_BR.info
>contributing.pt_BR.texi:1338: @menu reference to nonexistent node
>`Configuring Git'
>contributing.pt_BR.texi:1339: @menu reference to nonexistent node
>`Sending a Patch Series'
>contributing.de.texi:1447: @menu reference to nonexistent node `Configuring 
>Git'
>contributing.de.texi:1448: @menu reference to nonexistent node
>`Sending a Patch Series'
>contributing.fr.texi:1389: @menu reference to nonexistent node `Configuring 
>Git'
>contributing.fr.texi:1390: @menu reference to nonexistent node
>`Sending a Patch Series'
>make[2]: *** [Makefile:4969: doc/guix.de.info] Error 1
>make[2]: *** Waiting for unfinished jobs
>make[2]: *** [Makefile:5099: doc/guix.fr.info] Error 1
>make[2]: *** [Makefile:5164: doc/guix.pt_BR.info] Error 1
>
>
>the script I used to build guix from git is attached

Re: Relaxing the restrictions for store item names

[Julien Lepiller]

Le 24 août 2023 10:41:23 GMT+02:00, Msavoritias  a écrit :
>
>What I am saying here is that:
>Its easy to see from our very US centric tech culture why everybody
>should just use ASCII because "This is how it is". But there is very
>little reasons why we shouldn't strive to be more inclusive of all
>cultures.
>Especially since nowadays where we have tools like Unicode that make our
>lives easier compared to US or nothing of 30-40 years ago.
>Just imagine how many good programmers we are missing because they don't
>want/can't learn English or don't have an ASCII keyboard.
>
>MSavoritias
>
>MSavoritias  writes:
>
>> Nguyễn Gia Phong  writes:
>>
>>> [[PGP Signed Part:Undecided]]
>>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
 Nguyễn Gia Phong  writes:
 > I think the distinction must be made here between Guix and GuixSD.
 >
 > The packaging software should support full localization,
 > but the distro should target the least common denominator.

 Depends what do we mean the "distro" here.
 If I can pick arabic or chinese in the installation as a display
 language and also I am able to use an arabic/chinese keyboard sounds
 good to me.
>>>
>>> I meant GuixSD.  I agree a distribution based on Guix Systems
>>> shouldn't meet any obstacle declaring packages with non-ASCII names.
>>> That you can type arabic and chinese and I can type hangul
>>> and most latin characters doesn't mean names having all of the above
>>> will be accessible to either of us or a third person.
>>>
>>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
 Regarding the initial question it was about package names to my
 understanding. Specifically package names in the store to use unicode
 characters. Which makes perfect sense there because some packages dont
 use ascii names.
>>>
>>> It does, but as said before, whether this is desireable depends
>>> on the target audience.  The purpose of API is to be used,
>>> i.e. it would be useless if even just one user can't type it.
>>>
>> Well we already have that don't we? What I mean is that ASCII names cant
>> be typed by all keyboards layouts easily. So what you are saying already
>> happens. Thats why I always have an ASCII layout available as a
>> secondary, next to my non ASCII. I bet every person that uses packages
>> with names other than english can add a seperate layout.
>>
>>> On 2023-08-24 at 10:41+03:00, MSavoritias wrote:
 Regarding the broken install example, most (all?) base
 packages use ASCII due to unix historical baggage.
 So you shouldn't need to type anything non ASCII
 to fix an install with only basic packages.
>>>
>>> Due to historical baggage, most (all?) keyboard layouts can fall
>>> back to ASCII alphanumerics.  A broken install was given
>>> as the worst case; there's no reason any other packages
>>> should be less accessible based on the users' culture.
>>>
>>
>> But they are already aren't they? Because if I want to add a package
>> with the Greek alphabet or the Japanese one I have to transliterate it
>> into ASCII which is always going to be worse and people won't be able to
>> find the package. Because they won't know we changed the name. Plus they
>> will have to change the layout. Same as an ASCII user would have to do.
>>
>>> I suggest, in an international context such as GuixSD,
>>> for every package to have a ASCII name.  It'd of course
>>> be better if a correctly written name is also available.
>>>
>>
>> So you propose two names? Sure if that can be done I don't see why not. 
>> Either way not
>> having unicode names is a bug. Also to note: Most of the world speaks
>> Unicode. So its more for compatibility purposes i guess (?) rather than
>> to be "international".
>>
>> MSavoritias
>
>

There are two things discussed here:

1. A restriction in the daemon prevents using unicode in store item names.

I think this is an issue worth fixing, as it would allow users to define their 
own store items more easily. For instance, I might want to make a file with 
non-ascii name a file-like item, eg.

(local-file "fond d'écran.jpg")

2. Naming policy for packages in the Guix channel

I don't think we should distribute packages that have non-ascii characters in 
their names. Of course I don't know all keyboards that exist out there, but I 
don't think you can find a programmer that can't type an ascii character, or a 
guix user that can't at least type "guix" in their terminal.

For discoverability, we could add the real non-ascii name in the package 
description.

Re: Guix and the developer ecosystem

[Julien Lepiller]

Le 5 août 2023 03:49:30 GMT+02:00, Distopico  a écrit :
>
>On 2023-07-31, "("  wrote:
>
>> Hi,
>>
>> Distopico  writes:
>>> In terms of programming languages, I have found almost all the ones I
>>> needed, with the exception of Kotlin.
>>
>> The build sequence for Kotlin is some sort of hellish double
>> nightmare-loop of doom.  As far as I'm aware, this is how
>> the main dependencies of Kotlin relate to each other:
>>
>>  .-.
>>  | |
>>.-> gradle --.  V
>>| ^  |kotlin --.
>> openjdk  '--'^^   |
>>| |'---'
>>'-'
>>
>> Fun!
>>
>
>Nice graphs, sound pretty complicate to solve that  :/

There's hope, because you can skip building gradle, and manually build kotlin. 
So you end up with a chain of kotlin versions. I actually managed to build 
some, but I'm stuck after 1.0.0:

https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/kotlin.scm

That's already a huge chain, and it's probably missing ten times more…

>
>>> In some languages like Haskell and GoLang, the language server depends a
>>> lot on the version it was compiled with. For example, I tried gopls,
>>> which is available in Guix, but it was built with Go 17 and is not
>>> compatible it.
>>
>> Ah, that'll be because Guix uses Go 17 for building Go programs, unless
>> you override the ``#:go'' keyword, but the latest version of Go it
>> provides is Go 20.  I suppose it couldn't hurt to change it to be built
>> with the latest version.  (We can't just make the default build Go be
>> 20, as that would require the CI to rebuild all Go packages.)
>>
>
>And that can be another problem, or it is indeed a real problem, going
>to a project that uses Go 1.7, but all the tools are built around Go
>1.20. That's why I imagine something like having tools relative to their
>versions, so we can install gopls@0.11 and go@1.17 together because they
>are compatible. And if I switch to another project, I could install
>Go@1.15 and gopls@0.9.5. Currently, that is not possible, at least I
>haven't seen it in Go/Rust/Haskell in Guix.

There's always the time-machine or inferiors. If it worked at some point in 
Guix, you can go back in time and get those packages. Not ideal since they'll 
depend on older software, but at least, if it worked in the past, it's 
guaranteed to continue to work today.

>
>>> I have started contributing to packages that I believe could be useful,
>>> and I like to contributing to teams such as Haskell or Rust. However,
>>> there are other topics, such as compiler and tools compatibility, where
>>> I'm not entirely clear about the direction that has been planned.
>>
>> The problem with Haskell, Rust, and Elm is mainly, as lilyp has
>> said/implied, that while the dependency trees of C applications and such
>> typically resemble the following:
>>
>> O <-- O
>>   O <-- O <-- O
>> O <-- O
>>
>> dependency trees for Rust, Haskell, and Elm look like this:
>>
>> / O
>>   / O <-- O
>>   | \ O
>>   |
>>   | / O
>> / O <-- O <-- O
>> | | \ O
>> | |
>> | | / O
>> | \ O <-- O
>> |   \ O
>> |
>> |   / O
>> | / O <-- O
>> | | \ O
>> | |
>> | | / O
>>   O <-- O <-- O <-- O <-- O
>> | | \ O
>> | |
>> | | / O
>> | \ O <-- O
>> |   \ O
>> |
>> |   / O
>> | / O <-- O
>> | | \ O
>> | |
>> | | / O
>> \ O <-- O <-- O
>>   | \ O
>>   |
>>   | / O
>>   \ O <-- O
>> \ O
>>
>> Except in reality it's much much much much much worse.
>>
>> So it's not because that's not something we'd like to have, it's largely
>> because packaging such things is a royal pain and there aren't all that
>> many people with the motivation to do that.
>>
>
>
>And this is the current reality, and it will become more and more
>common, whether for better or for worse. Package managers make it so
>convenient to install dependencies, but it leads to an abuse in that
>regard. I could name many of the most widely used programming languages
>today that have the same problem: JavaScript, Python, Haskell, Rust,
>just to name a few. So, here is my question: Is there a future vision
>for this situation? Because it will become more and more common over
>time.

The solution to this issue could 

Re: A Forum for Guix Users

[Julien Lepiller]

Le 15 juillet 2023 23:00:43 GMT+02:00, MSavoritias  a 
écrit :
>
>Attila Lendvai  writes:
>
>>> Regarding the forum I dont think any forum would have much traction.
>>> I agree that either matrix or xmpp could be considered instead for that
>>> purpose.
>>> As a more approachable chat mechanism compared to IRC.
>>
>>
>> it's an essential role of a forum that latecomers find the earlier
>> questions/discussions, typically through a websearch. a forum's
>> primary user-story is very much not that of a chat, i.e. a real-time,
>> ephemeral, linear flow of text, sometimes with multiple overlapping
>> discussions, and as such not very well processed by the search engine
>> crawlers...
>>
>> i think it all boils down to this:
>>
>> mailing list archives (and IRC logs) are stuck in time. their underlying 
>> data model is inadequate for efficient indexing/searching, and often lack 
>> structure even to conveniently present the archive to the user.
>
>Good point.
>My thinking is that next we miss too things for that:
>
>1. Easy search and indexing of our docs. Which already exists for the
>most part. Searching for occurunces of words like grep or a full blown
>wiki like gentoo or arch would be an interesting future approach.
>2. We need something easier than gnu info to contribute docs. As I have
>read a lot in irc for it to be a barrier. And personally its one of the
>main reasons i havent contributed yet. That I need time to learn
>it. That and I can't easily change or add Docs. I have to do pull
>requests and such.

At least for the cookbook, we can accept other formats, and a commiter will 
convert to the proper info format. What matters is the content, and you don't 
even have to create a patch, just send a chapter to the ML :)

>
>Thats why I was also aggreeing with Sourcehut in the other email. (Which
>already has guix ci support.) Guix would benefit from less NIH imo. At
>least in places where there already better solutions.
>
>Msavoritias
>
>> -- 
>> • attila lendvai
>> • PGP: 963F 5D5F 45C7 DFCD 0A39
>
>

Re: Format specification issue in the translations...

[Julien Lepiller]

Hi!

I think it's indeed a bug in the Shepherd. Both forms should be identical for 
singular and plural. Especially, I think we should use ~{ ~a,~} in both cases 
since even when there's a single service, the argument is a list, so with only 
~a, it wouldn't show properly.

Le 23 mai 2023 01:57:05 GMT+02:00, Sebastian Rasmussen  a 
écrit :
>Hi!
>
>I'm involved in the translation of Shepherd to Swedish, and
>poedit complains that the format specifications for the singular
>and plural forms of one of the strings are not the same:
>https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1107
>
>Later on in the source there is another string where the format
>specifications appear to be identical:
>https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1221
>
>If this is not a bug, please help me understand what can be done
>to make the translation tools not complain (even translationproject.org
>complains when I submit the .po-file).
>
>If this is indeed a bug in the source, do you mind fixing it?
>I'm not sure how your development process works, but if
>it helps I can fix it in a clone of the repo and post a link here..?
>
> / Sebastian
>

Re: OCaml bootstrap

[Julien Lepiller]

Le 4 mai 2023 10:41:18 GMT+02:00, Simon Tournier  a 
écrit :
>Hi,
>
>On Wed, 03 May 2023 at 23:25, Julien Lepiller  wrote:
>
>>>Julien, do you happen to know if there are plans to make camlboot more
>>>capable so it can be used to build newer versions of OCaml?  Maybe
>>>something to discuss with Nathanaëlle Courant and Gabriel Scherer?
>
>> We had some discussion here, but there's still some work to do:
>> https://github.com/Ekdohibs/camlboot/issues/59
>
>Cool!
>
>Just to be sure, the discussion is from one year ago, right?  Any
>update?

No updates. I don't think any of us worked more on that than you can read.

>
>Well, rehashing, I think we could consider a full-bootstrap from source
>for OCaml.  Whatever the seed (4.07 or 4.09), we could consider it as
>done and fixed.  Here all the “inputs”:
>
>--8<---cut here---start->8---
> "bash-minimal@5.1.16" 
> "bash-minimal@5.1.16" 
> "binutils@2.38" 
> "bzip2@1.0.8" 
> "coreutils@9.1" 
> "diffutils@3.8" 
> "file@5.44" 
> "findutils@4.9.0" 
> "gawk@5.2.1" 
> "gcc@11.3.0" 
> "glibc-utf8-locales@2.35" 
> "glibc@2.35" 
> "grep@3.8" 
> "guile@3.0.9" 
> "gzip@1.12" 
> "ld-wrapper@0" 
> "libffi@3.4.4" 
> "libgc@8.2.2"
> "libunistring@1.0" 
> "make@4.3" 
> "patch@2.7.6" 
> "pkg-config@0.29.2" 
> "sed@4.8" 
> "tar@1.34" 
> "xz@5.2.8" 
>--8<---cut here---end--->8---
>
>Only guile-3.0 is not a package deep in the graph.  All the others are.
>My question is: do we want to rebuild camlboot and then all the OCaml
>world each time we update one of these “inputs“?
>
>For example, what does it bring on the table to rebuild camlboot because
>grep had been updated?

I don't understand what you suggest here. I think grep is used in the Makefile, 
so we can't just remove it from the inputs. What would not building camlboot 
when grep is updated look like?

Have a grep-for-build that is never updated? Build camlboot once and repackage 
the binary (making it a bootstrap seed)?

>
>
>Cheers,
>simon

Re: OCaml bootstrap

[Julien Lepiller]

We had some discussion here, but there's still some work to do: 
https://github.com/Ekdohibs/camlboot/issues/59

Le 3 mai 2023 23:15:49 GMT+02:00, "Ludovic Courtès"  a écrit :
>Hello,
>
>Simon Tournier  skribis:
>
>> Well, 4.07 is the version that is de-bootstrapped, i.e. bootstrapped
>> using ’camlboot’ via Guile – for details see [2].
>>
>> However, higher versions (4.09, 4.14, 5) does not use this seed and thus
>> they are not de-bootstrapped.  Well, I do not know the status upstream;
>> from my point of view, we have two options:
>>
>>  a) Agree with other distros and OCaml folks to rely on a common OCaml
>>  4.07 bootstrapped using camlboot and then use this OCaml 4.07 as the
>>  seed for the subsequent versions.  Somehow having a way to verify the
>>  current OCaml compiler without running again and again via camlboot.
>>
>>  b) Build ourselves a chain from 4.07 bootstrapped with camlboot to
>>  modern OCaml compilers.  However, each time we modify one dependency of
>>  camlboot, it means rebuild the complete chain.  Well, bootstrapping via
>>  camlboot can be very slow and I do not know if we have the resources
>>  for non-x86_64 architecture.  Here, the list of the emerged
>>  dependencies:
>
>Julien, do you happen to know if there are plans to make camlboot more
>capable so it can be used to build newer versions of OCaml?  Maybe
>something to discuss with Nathanaëlle Courant and Gabriel Scherer?
>
>Ludo’.

Re: Time travel accident

[Julien Lepiller]

If you're able to find the derivation, you could set your system time and guix 
build /gnu/store/that.drv. this should not require network at all, so guix 
shouldn't complain.

Le 7 avril 2023 18:10:13 GMT+02:00, Konrad Hinsen  
a écrit :
>Hi Josselin and Julien,
>
>Thanks to both of you for your suggestions!
>
>Josselin Poiret  writes:
>
>> We have --without-tests=package already, see --help-transform for all
>> available package transformations.  The one annoying thing is that
>> disabling tests will change the derivation and you thus will not recover
>> the same store item (it might be bit-for-bit equivalent, but its path
>> will not be the same), preventing you from using substitutes either.
>
>For my case, that sounds OK. There are no substitutes for that
>three-year old commit any more, so I am building everything. And I don't
>care about bit-for-bit equivalence, I just want to run Python 3.8.2.
>
>> Though, I'm not sure it will help you here because openssl is built as
>> part of the `guix time-machine`'s build process, which afaik cannot be
>> transformed.
>
>Ahhh... there's the bad news.
>
>> By the way, we can also "fix the past" by using guix/quirks.scm.  Since
>
>Oohhh... There's always one more surprise in Guix!
>
>
>Julien Lepiller  writes:
>
>> Changing your system date should let it build.
>
>Interesting idea! I tried, but it doesn't work: Guix itself complains
>about a certificate failure if I set the clock three years back.
>
>Maybe "guix time-machine" should have an option for setting the clock to
>the commit timestamp just for the build process...
>
>Cheers,
>  Konrad.
>

Re: Time travel accident

[Julien Lepiller]

Changing your system date should let it build.

Le 7 avril 2023 10:30:11 GMT+02:00, Josselin Poiret  a écrit :
>Hi Konrad,
>
>Konrad Hinsen  writes:
>
>> I guess there is nothing we can do retroactively to fix this, but can we
>> do something to prevent such issues in the future?
>>
>> One idea is to allow disabling tests at the command line. I'd then run
>> "guix build" for that specific package with tests disabled, and
>> continue. That should be doable with a suitable package transformation.
>
>We have --without-tests=package already, see --help-transform for all
>available package transformations.  The one annoying thing is that
>disabling tests will change the derivation and you thus will not recover
>the same store item (it might be bit-for-bit equivalent, but its path
>will not be the same), preventing you from using substitutes either.
>
>Though, I'm not sure it will help you here because openssl is built as
>part of the `guix time-machine`'s build process, which afaik cannot be
>transformed.
>
>By the way, we can also "fix the past" by using guix/quirks.scm.  Since
>that version of openssl doesn't build anymore, I wonder if we could just
>change its derivation retroactively to at least make it build.
>
>Best,

Re: guix git build error

[Julien Lepiller]

Hi Andy,

I'm afraid I'm unable to reproduce your error. You could try cleaning
the translated texi files to make sure you get the most up-to-date ones:

rm doc/*.texi
git checkout doc

Does that help?

Otherwise, I'll need you to send me say guix-cookbook.fr.texi. There
shouldn't be a refernece to an English title, since it's fully
translated. Maybe the POXREF step didn't work well for you?

Le Tue, 7 Mar 2023 21:49:49 -0800,
Andy Tai  a écrit :

> Just check out origin/master of guix git HEAD,
> 
> make error:
> 
> Compiling Scheme modules...
>   GEN  etc/openrc/guix-daemon
> [  0%] LOAD guix.scm
>   GEN  etc/gnu-store.mount
>   GEN  etc/guix-daemon.service
>   GEN  etc/guix-publish.service
>   GEN  etc/guix-gc.service
>   GEN  etc/init.d/guix-daemon
> ./doc/guix-cookbook.fr.texi:652: @pxref reference to nonexistent node
> `A Scheme Crash Course'
> ./doc/guix-cookbook.fr.texi:3370: @ref reference to nonexistent node
> `Reproducible profiles'
>   GEN  etc/guix-daemon.conf
>   GEN  etc/guix-publish.conf
> make[2]: *** [Makefile:5300: doc/guix-cookbook.fr.info] Error 1
> make[2]: *** Waiting for unfinished jobs
> ./doc/guix-cookbook.sk.texi:634: @pxref reference to nonexistent node
> `A Scheme Crash Course'
> ./doc/guix-cookbook.sk.texi:3256: @ref reference to nonexistent node
> `Reproducible profiles'
> ./doc/guix-cookbook.ko.texi:624: @pxref reference to nonexistent node
> `A Scheme Crash Course'
> make[2]: *** [Makefile:5388: doc/guix-cookbook.sk.info] Error 1
> 
> 
> 
> This did not happen before (as far as what I have seen)
> 

Re: Ocaml (was: Merging core-updates?)

[Julien Lepiller]

We can probably get rid of most 4.07 variants but I would keep the bootstrap 
(in the hope we can bootstrap later versions from it). 4.09 is still used for 
unison, and I think Andreas uses it a lot :)

I'd say remove all leaf 4.07 packages that are libraries only.

Le 20 février 2023 11:35:16 GMT+01:00, Simon Tournier 
 a écrit :
>Hi Julien,
>
>On dim., 19 févr. 2023 at 10:15, Julien Lepiller  wrote:
>> ocaml-4.14 and ocaml-5 don't have this issue. I just pushed a fix for
>> ocaml-4.09. I'll also have to fix ocaml-4.07 since it fails to build as
>> early as camlboot. It'll take a while to test. Thanks for pointing me
>> to that patch!
>
>Do we still keep 4.07 and 4.09?  And all the package variants?
>
>Cheers,
>simon

Re: Ocaml (was: Merging core-updates?)

[Julien Lepiller]

ocaml-4.14 and ocaml-5 don't have this issue. I just pushed a fix for
ocaml-4.09. I'll also have to fix ocaml-4.07 since it fails to build as
early as camlboot. It'll take a while to test. Thanks for pointing me
to that patch!

Le Sat, 18 Feb 2023 12:38:55 +0100,
Andreas Enge  a écrit :

> Am Sat, Feb 18, 2023 at 12:03:31PM +0100 schrieb Andreas Enge:
> > this looks exactly like the line that posed problems for openjdk.
> > Maybe there is a patch? Could someone familiar with ocaml have a
> > look?  
> 
> It looks like this:
>https://github.com/ocaml/ocaml/pull/10266
> 
> Andreas
> 

Re: Merging core-updates?

[Julien Lepiller]

I haven't tried the patch, but before it, I was already able to build mpc for 
x86_64 on a SSD with btrfs.

Le 16 février 2023 16:03:15 GMT+01:00, Janneke Nieuwenhuizen  
a écrit :
>Andreas Enge writes:
>
>> Am Wed, Feb 15, 2023 at 09:39:39AM +0100 schrieb Janneke Nieuwenhuizen:
>>> I have released 0.24.2 and updated mes-boot on core-updates as
>>> Let's hope this fixes these bugs.
>>
>> With your latest patch, I have successfully bootstrapped core-updates
>> on x86_64 up to hello and mpc. Thanks a lot!
>
>Great, thanks so much for checking!  Are you using any of tmpfs or btrfs
>on /tmp?
>
>Greetings,
>janneke
>

Re: Openjdk (was: Merging core-updates?)

[Julien Lepiller]

Le 16 février 2023 12:03:35 GMT+01:00, Efraim Flashner  
a écrit :
>On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote:
>
>> Is it necessary to keep all these version of openjdk and to bootstrap
>> version n with version n-1?
>
>Probably? I assume if you can cut some out that'd be ok. I'm pretty sure
>openjdk-11 and openjdk-17 are considered LTS by upstream so it would
>make sense to keep those specifically.

Upstream ensures openjdk N+1 can be built by openjdk N, but not necessarily 
with N-1. We can try :)

Re: Architecture support [was: Re: Merging core-updates?]

[Julien Lepiller]

Could we get berlin to evaluate a small set of core packages (mpc, hello, …)? 
Are the changes intended to fix the issue with bordeaux's machines? Is it 
configured to build core-updates?

Le 14 février 2023 17:30:32 GMT+01:00, Andreas Enge  a écrit :
>Hello,
>
>Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner:
>> Aarch64 and armhf are getting stuck at gcc-cross-boot0.
>
>I got to hello on my aarch64, which is very encouraging! I will have to
>try again with your latest changes to core-updates, but am rather optimistic.
>
>Andreas
>
>

Re: Merging core-updates?

[Julien Lepiller]

Le Sun, 12 Feb 2023 12:52:51 +0100,
Julien Lepiller  a écrit :

> Le Sun, 12 Feb 2023 12:06:14 +0100,
> Andreas Enge  a écrit :
> 
> I just tried to build mpc on my machine, from core-updates. I get the
> same derivation as the one shown on the data service, and it built
> fine. Maybe there's something wrong with the machines behind bordeaux?
> I probably got substitutes from berlin, for gcc and friends (though I
> built gmp, mpfr and mpc).
> 

And I was able to rebuild (with --check) patch-mesboot. The error looks
a lot like https://issues.guix.gnu.org/49985. We should fix that indeed
:)

Re: Merging core-updates?

[Julien Lepiller]

Le Sun, 12 Feb 2023 12:06:14 +0100,
Andreas Enge  a écrit :

> Hello,
> 
> Am Sun, Feb 12, 2023 at 10:05:40AM +0100 schrieb Julien Lepiller:
> > As discussed at Guix Days before Fosdem, we haven't merged
> > core-updates in a very long time. I'd volunteer to lead this
> > effort, but I don't know what steps I should follow. Do we have
> > some documentation about that?  
> 
> I volunteer to follow your lead, but also have no clue what is
> actually expected.
> 
> With Chris's help, I scheduled an evaluation on the build coordinator,
> which has not finished yet, so there is not yet anything to see at
>
> http://data.qa.guix.gnu.org/gnu/store/bjyfp7bhb9j25sw62nrkqjiivnzjxija-mpc-1.3.1.drv
> But if you click down the dependency tree, some of them have been
> built. And the first one already failed:
>
> http://data.qa.guix.gnu.org/gnu/store/0p0zs4gv8vg7rny25ki1szv4c7yk9zzb-patch-mesboot-2.5.9.drv
> With a strange error:
> starting phase `build'
> make: stat:Makefile: sterror: unknown error
> make: *** No targets specified and no makefile found.  Stop.
> error: in phase 'build': uncaught exception:
> srfi-34 # exit-status: 2 term-signal: #f stop-signal: #f] 1439cc0> phase
> `build' failed after 0.0 seconds command "make" failed with status 2
> Having failed three times in a row, this does not look like a
> transient error.
> 
> I also reconfigured bayfront to do more builds itself.
> 
> Actually I am wondering whether the first step of killing these
> untamed non-feature branches would not be to build and merge staging?
> It is based on master, supposed to contain only medium sized changes,
> but which I suspect end up being a world-rebuilding cluster of
> changes.
> 
> Andreas
> 

I just tried to build mpc on my machine, from core-updates. I get the
same derivation as the one shown on the data service, and it built
fine. Maybe there's something wrong with the machines behind bordeaux?
I probably got substitutes from berlin, for gcc and friends (though I
built gmp, mpfr and mpc).

Merging core-updates?

[Julien Lepiller]

Hi Guix!

As discussed at Guix Days before Fosdem, we haven't merged core-updates
in a very long time. I'd volunteer to lead this effort, but I don't
know what steps I should follow. Do we have some documentation about
that?

Re: Help adding a graph backend

[Julien Lepiller]

As the message says, use ./configure --localstatedir=/var :)

Le 10 février 2023 04:10:02 GMT+01:00, Kyle Andrews  a écrit :
>
>Dear Guix,
>
>I am not very comfortable editing Guix source code. However, I would
>very much like to add a new backend for `guix graph`. Right now guix
>graph descriptions can only be exported into special purpose tools like
>graphviz, D3, and cypher. I would like to add a fourth option which
>would support loading the dependency data into general purpose network 
>analysis software tools: an edgelist backend.
>
>=> https://en.wikipedia.org/wiki/Edge_list
>
>I think this code will do the job, but I don't know how to test it. So, I 
>don't know for sure.
>
>``` guix/graph.scm
>(define (el-prologue name port)
>  (display "from, to" port))
>
>(define (el-epilogue port)
>  (display "\n" port))
>
>(define (el-node id label port)
>  (display "" port))
>
>(define (el-edge id1 id2 port)
>  (format port "~a, ~a\n"))
>
>(define %edgelist-backend
>  (graph-backend "edgelist"
> "Generate graph in CSV edge list format"
> el-prologue el-epilogue
> el-node el-edge))
>
>(define %graph-backends
>  (list %graphviz-backend
>%d3js-backend
>%cypher-backend
>%edgelist-backend)) ; <- the new proposed backend
>```
>
>Maybe it would be using some incantation involving ./pre-inst-env? I gave it a 
>try following the manual:
>
>```
>cd ~/{{path/to/guix}}
>guix shell -D guix
>./bootstrap
>./configure
>```
>
>This gave an error:
>
>```
>configure: error: chosen localstatedir '/usr/local/var' does not match that of 
>the existing installation '/var'
>Installing may corrupt /gnu/store!
>Use './configure --localstatedir=/var'.
>```
>
>Since I am not that excited about corrupting my /gnu/store given that I don't 
>know what I am doing, I didn't proceed further. 
>
>I figured because I wanted to extend Guix with a new feature and that I
>could piece together a story in my head about how the code should look, my 
>query should be sent to this list rather than to help-guix.
>
>Thanks in advance for any helpful suggestions towards getting this backend 
>added to Guix!
>
>Cheers,
>Kyle
>

Reducing useless module imports

[Julien Lepiller]

Hi Guix!

during the Guix Days, we talked about reducing module imports. First,
let's note there's an empty module (gnu packages key-mon).

Then, we looked at build systems modules that are imported, but for
which the build system is never used:

```
for f in *.scm; do systems=$(grep '#:use-module (guix build-system' $f
| sed 's|^.*use-module (guix build-system \([^)]*\).*|\1|'); for s in
$systems; do if grep "${s}-build-system" $f >/dev/null; then :; else
echo $s is not used in $f; fi; done; done
```

For instance, (gnu packages minetest) imports (guix build-system
minetest) but never uses the minetest-build-system. (gnu packages
abiword) uses (guix build-system gnu) but does not use the
gnu-build-system.

Many modules seem to use a lot of imports that are actually useless,
for instance (gnu packages heads) imports 20 package modules, but
only uses 4 of them.

Removing these module imports would help a lot with reducing the number
of loops. If anyone wants to volunteer a lint checker for that,
raise hands :D

UTF-8 progress bar

[Julien Lepiller]

Hi Guix!

I have a patch waiting (https://issues.guix.gnu.org/59975) that will
change progress bars to use some unicode characters. I think they look
better, but I'm a bit afraid they might not look right on some config,
so I'd like to know if your terminal is able to show these characters:

"▏▎▍▌▋▊▉█▏▕"

If you are not using a unicode locale, this change will not affect you
as guix will fallback to the ascii style. If your terminal can't show
these characters and you have a UTF-8 locale (you'd run echo $LANG to
know that), please report your config (name of terminal app, locale,
fonts, …)!

Re: Time for ocaml-xzy.scm and reorganizing OCaml packages?

[Julien Lepiller]

Le Wed, 11 Jan 2023 20:05:58 +0100,
Simon Tournier  a écrit :

> Hi,
> 
> Maybe it is time for ocaml-xzy.scm. :-)
> 
> Currently, the file gnu/packages/ocaml.scm contains 315 define-public.
> Maybe, it would make sense to have:
> 
>  + ocaml.scm for compiler and essentials (as ocaml-findlib or dune)
>  + ocaml-xyz.scm for ocaml- packages
>  + ocaml-apps.scm for standalone program written in OCaml as unison,
>ocamlmod, etc
>  + ocaml-legacy.scm for the old ocaml4.0x things
> 
> WDYT?

Sounds good to me. Are you planning to work on a patch?

> 
> Well, with the question of the new ocaml5 thing. :-)
> 
> Trying to package some OCaml, I note that the OCaml package named
> camlzip is not prefixed with ’ocaml-’ although it can only be used as
> a library, IIUC.
> 
> --8<---cut here---start->8---
> $ tree $(guix build camlzip)
> /gnu/store/r7p7azlfwrjs5c6kbwb50pvlqxi4k776-camlzip-1.11
> ├── bin
> ├── lib
> │   └── ocaml
> │   └── site-lib
> │   ├── camlzip
> │   │   └── META
> │   └── zip
> │   ├── dllcamlzip.so
> │   ├── gzip.cmi
> │   ├── gzip.cmt
> │   ├── gzip.cmti
> │   ├── gzip.cmx
> │   ├── gzip.mli
> │   ├── libcamlzip.a
> │   ├── META
> │   ├── zip.a
> │   ├── zip.cma
> │   ├── zip.cmi
> │   ├── zip.cmt
> │   ├── zip.cmti
> │   ├── zip.cmx
> │   ├── zip.cmxa
> │   ├── zip.cmxs
> │   ├── zip.mli
> │   ├── zlib.cmi
> │   ├── zlib.cmt
> │   ├── zlib.cmti
> │   ├── zlib.cmx
> │   └── zlib.mli
> └── share
> └── doc
> └── camlzip-1.11
> └── LICENSE
> 
> 9 directories, 24 files
> --8<---cut here---end--->8---
> 
> Moreover, “guix import opam -r camlzip” returns,
> 
> (define-public ocaml-camlzip
>   (package
> (name "ocaml-camlzip")
> 
> Well, therefore I would be expecting ocaml-camlzip to be consistent
> with the Guix naming convention.  And with this large
> gnu/packages/ocaml.scm file containing all the OCaml related stuff, I
> am guessing that it’s time to reorganize a bit.  WDYT?

We can rename camlzip :)

> 
> Cheers,
> simon

Re: advanced?

[Julien Lepiller]

Already fixed in weblate for French. Will push the update shortly :)

Le 9 janvier 2023 12:12:27 GMT+01:00, "Ludovic Courtès"  a écrit :
>Hey,
>
>A heads-up for Julien and the translators:
>
>Ludovic Courtès  skribis:
>
>> Simon Josefsson via "Development of GNU Guix and the GNU System
>> distribution."  skribis:
>>
>>> From aac8f6d1fb382b9f9120b7cd51dc80e8ef07cc03 Mon Sep 17 00:00:00 2001
>>> From: Simon Josefsson 
>>> Date: Sat, 26 Nov 2022 22:35:15 +0100
>>> Subject: [PATCH] website: Reduce use of 'advanced' term.
>>>
>>> ---
>>>  website/apps/base/templates/about.scm | 4 ++--
>>>  website/apps/base/templates/home.scm  | 6 +++---
>>>  2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> It’s been a month and it looks like there wasn’t any opposition to this
>> change, so I went ahead and pushed it.
>
>Unsurprisingly, removing the one word invalidated all translations,
>as can be seen at the top of the front page:
>
>  
>
>Ludo’.

Re: Packaging OCaml repositories that define multiple packages?

[Julien Lepiller]

The importer will not support such a package. As you say, it wants to build 
them separately because they are separate opam packages. So, either we build 
them separately too, or we build all at once.

If we build all at once, that's fine. You could name the package ocaml-mirage 
and not use any #:package argument. Dune will then build all packages from the 
repository.

One issue with that is that the importer will not know about it and will try to 
import subpackages again whenever a packages depends on it, instead of using 
ocaml-mirage.

I don't like the alias solution, though it should work, since the importer 
would see them.

Le 8 janvier 2023 15:04:35 GMT+01:00, Csepp  a écrit :
>I'm going through my MirageOS commits for what is hopefully the last
>time before I send the patches and I realized that a problem that I
>thought was isolated is a lot more widespread than I thought.
>
>As an example look at https://github.com/mirage/mirage/
>
>It defines functoria, functoria-runtime, mirage, and mirage-runtime.
>
>It is possible to build all 4 as one package.
>
>The opam importer seems to not be able to handle situations like this,
>since it defines a new package for each sub-package.
>
>How should I proceed?  I definitely want to merge all redundant packages
>into one, but then what?  How should the package description reflect
>this?  What should the package be named when it corresponds to 4 OPAM
>packages at once?
>
>For now I defined a few aliases for cases like this, but I'm not sure if
>this is ideal.  They look like this (made up but possible example):
>(define ocaml-mirage ocaml-mirage-runtime)

Re: Experimenting with reduced gcc-lib

[Julien Lepiller]

Le 15 décembre 2022 15:34:02 GMT+01:00, "Ludovic Courtès"  a 
écrit :
>Hello!
>
>Julien Lepiller  skribis:
>
>> Before the patch we get:
>>
>> guix size perl
>> total: 147.7 MiB
>>
>> After the patch:
>>
>> ./pre-inst-env guix size perl
>> total: 114.5 MiB
>
>Nice!
>
>> I don't want to push that patch as is, because libstdc++.so is still in
>> the gcc-static-lib output and will bring all the useless stuff with it.
>> C++ programs will bring back the remaining 33.2 MiB.
>
>It wouldn’t be worse than the current situation though?
>
>> Another possible target is glibc, since the only useful bits in there
>> are libc.so and ld-linux.so (I think?). This could reduce the closure
>> of our packs by another ~40 MiB (I think our systems would still need
>> most of the content of this package).
>
>‘share/i18n’ is 16 MiB and ‘lib/iconv’ is 8 MiB.  Now, separating them
>without introducing loss of functionality may be tricky.
>
>> From bff8567b0770455397d44f1ed304a67681b472c9 Mon Sep 17 00:00:00 2001
>> From: Julien Lepiller 
>> Date: Thu, 8 Dec 2022 22:29:01 +0100
>> Subject: [PATCH] gnu: gcc: Separate lib output.
>>
>> * gnu/packages/gcc.scm (gcc-4.7): Replace `lib' output with `static-lib'
>>   and `shared-lib'.
>> * gnu/packages/commencement.scm (gcc-boot0): Update accordingly.
>> ---
>>  gnu/packages/commencement.scm |  6 +++---
>>  gnu/packages/gcc.scm  | 39 +--
>>  gnu/tests/mail.trs|  0
>>  3 files changed, 31 insertions(+), 14 deletions(-)
>>  create mode 100644 gnu/tests/mail.trs
>
>Oops?

Oopsie :)

>
>> (outputs '("out";commands, etc. (60+ MiB)
>> -  "lib";libgcc_s, libgomp, etc. (15+ 
>> MiB)
>> +  "shared-lib" ;libgcc_s, libgomp, etc. (5+ MiB)
>> +  "static-lib" ;object code libraries and 
>> internal data files of GCC. (10+ MiB)
>
>The convention is to use “lib” for shared libraries and “static” for
>static libraries.

But using lib introduces a --libdir argument which is used to install static 
libs…

>
>Is libgomp in “lib”?  Is it found when linking with ‘-fopenmp’?

Well, shared-lib should be renaimed into libgcc, because it's the only library 
there.

Libgomp amd all other libs are in static-lib (which is not well named either 
^^'). It will be found I think but not tested (it find libstdc++ in the same 
directory).

>
>Thanks for this work; we really need to do something about package
>sizes!
>
>Ludo’.

Experimenting with reduced gcc-lib

[Julien Lepiller]

Hi Guix!

I had a look at gcc to try and reduce its footprint. I figured gcc-lib
contained shared and static libraries as well as support libraries for
gdb, many headers and compiler runtime, that are taking a lot of space
when they are not needed at runtime. Reducing its 33.4 MiB would help
create smaller guix packs, have smaller system and profile closures,
etc.

I figured gcc has a --with-slibdir option that is advertised as being
useful to specify a directory for the shared libraries. I decided to
use it and create a new output for the gcc package, shared-lib. In
fact, this option only installs libgcc_s.so in that output, and that's
the only thing required by most packages.

Attached is a patch that divides gcc-lib into gcc-static-lib and
gcc-shared-lib (not very good names, gcc-static-lib contains shared
libs too).

Before the patch we get:

guix size perl
total: 147.7 MiB

After the patch:

./pre-inst-env guix size perl
total: 114.5 MiB

This is because before the patch, gcc-lib is 33.4 MiB, and after the
patch gcc-shared-lib is only 0.2 MiB.

I don't want to push that patch as is, because libstdc++.so is still in
the gcc-static-lib output and will bring all the useless stuff with it.
C++ programs will bring back the remaining 33.2 MiB.

Another possible target is glibc, since the only useful bits in there
are libc.so and ld-linux.so (I think?). This could reduce the closure
of our packs by another ~40 MiB (I think our systems would still need
most of the content of this package).
>From bff8567b0770455397d44f1ed304a67681b472c9 Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Thu, 8 Dec 2022 22:29:01 +0100
Subject: [PATCH] gnu: gcc: Separate lib output.

* gnu/packages/gcc.scm (gcc-4.7): Replace `lib' output with `static-lib'
  and `shared-lib'.
* gnu/packages/commencement.scm (gcc-boot0): Update accordingly.
---
 gnu/packages/commencement.scm |  6 +++---
 gnu/packages/gcc.scm  | 39 +--
 gnu/tests/mail.trs|  0
 3 files changed, 31 insertions(+), 14 deletions(-)
 create mode 100644 gnu/tests/mail.trs

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index b4566b41cc..f3fce1750f 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -2853,7 +2853,7 @@ (define gcc-boot0
 (lambda _ #t
(add-after 'install 'symlink-libgcc_eh
  (lambda* (#:key outputs #:allow-other-keys)
-   (let ((out (assoc-ref outputs "lib")))
+   (let ((out (assoc-ref outputs "static-lib")))
  ;; Glibc wants to link against libgcc_eh, so provide
  ;; it.
  (with-directory-excursion
@@ -3417,7 +3417,7 @@ (define glibc-final
;; if 'allowed-references' were per-output.
(arguments
 `(#:allowed-references
-  (,(gexp-input gcc-boot0 "lib")
+  (,(gexp-input gcc-boot0 "shared-lib")
,(kernel-headers-boot0)
,static-bash-for-glibc
,@(if (hurd-system?)
@@ -3523,7 +3523,7 @@ (define gcc-final
  `(#:guile ,%bootstrap-guile
#:implicit-inputs? #f
 
-   #:allowed-references ("out" "lib" ,zlib-final
+   #:allowed-references ("out" "shared-lib" "static-lib" ,zlib-final
  ,glibc-final ,static-bash-for-glibc)
 
;; Things like libasan.so and libstdc++.so NEED ld.so for some
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index bb154cac62..010c6102a0 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -106,8 +106,16 @@ (define-public gcc-4.7
'("CC"  "CXX" "LD" "AR" "NM" "OBJDUMP" "RANLIB" "STRIP")
'("gcc" "g++" "ld" "ar" "nm" "objdump" "ranlib" "strip"))
   '()
+ (static-libdir
+  (let ((base '(or (assoc-ref outputs "static-lib")
+   (assoc-ref outputs "out"
+(lambda ()
+  ;; Return the directory that contains lib/libgcc_s.so et al.
+  (if (%current-target-system)
+  `(string-append ,base "/" ,(%current-target-system))
+  base
  (libdir
-  (let ((base '(or (assoc-ref outputs "lib")
+  (let ((base '(or (assoc-ref outputs "shared-lib")
(assoc-ref outputs "out"
 (lambda ()
   ;; Return the directory that contains lib/libgcc_s.so et al.
@@ -138,6 +146,12 @@ (define-public gcc-4.7
  ,(string-append "--with-gxx-include-dir="
  (assoc-ref %outputs "out&

Re: GNU Guix 1.4.0rc1 available for testing!

[Julien Lepiller]

For i18n, weblate is still following master. I'll switch when we start string 
freeze, which should be one week before release. When the time comes, please 
someone ping me :)

Le 4 décembre 2022 17:17:38 GMT+01:00, "pelzflorian (Florian Pelz)" 
 a écrit :
>There are some release blockers.  To summarize, IMHO it would be
>regrettable if these bugs were not fixed before release:
>
>* [PATCH v2 2/3] install: Add missing e2fsprogs utility.
>  <https://issues.guix.gnu.org/59661>
>  Otherwise manual installation does not work as advertised.
>
>* [version 1.4.0rc1] reconfigure fails
>  <https://issues.guix.gnu.org/59780>
>  Otherwise users cannot update Guix System once installed
>  unless they take manual action.
>
>* [version 1.4.0rc1] install.sh script should authorize bordeaux
>  <https://issues.guix.gnu.org/59781>
>  Otherwise especially ARM users get far less substitutes
>  unless they take manual action.
>
>Julien Lepiller  writes:
>> Do we string freeze?
>
>About string freeze: I do not know if that is the case, but changes to
>critical parts of doc/guix.texi on master should not be reflected on
>Weblate if they don’t get into 1.4.0.
>
>Regards,
>Florian

Re: Release progress, week 8

[Julien Lepiller]

Do we string freeze?

Le 2 décembre 2022 23:45:04 GMT+01:00, "Ludovic Courtès"  a écrit 
:
>Hello Guix!
>
>Release progress: week 8.
>
>Apologies for not sending this one on time this Thursday; instead we got
>RC1, which is nice.  :-)
>
>  https://lists.gnu.org/archive/html/guix-devel/2022-12/msg0.html
>
>The RC was made from ‘version-1.4.0’ branch, which only takes important
>fixes now (if in doubt, please ask).
>
>Now we need reports from users to act upon.  I’d say we can decide next
>week whether we need an RC2 or not.  I can handle the next release
>candidate or the release itself, but I’ll be unavailable on Dec. 12–15.
>
>I started writing super long release notes (a book!), comments welcome:
>
>  
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md
>
>Comments?  Suggestions?  Happiness?  Excitement?  You tell!
>
>Ludo’.
>
>Week 7: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00274.html
>Week 6: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00161.html
>Week 5: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
>Week 4: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00026.html
>Week 3: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00293.html
>Week 2: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00210.html
>Week 1: https://lists.gnu.org/archive/html/guix-devel/2022-10/msg00137.html

Re: guix graph build phases

[Julien Lepiller]

I don't get why you want a picture. Could you share an example of what it would 
look like?

Le 22 novembre 2022 23:43:19 GMT+01:00, jgart  a écrit :
>On Tue, 22 Nov 2022 23:12:16 +0100 Julien Lepiller  wrote:
>> The graph will always be flat, since it's a list, so graphviz would be a bit 
>> overkill :). Being able to list phases could still be cool :)
>
>How about with the plantuml that have packaged?

Re: guix graph build phases

[Julien Lepiller]

The graph will always be flat, since it's a list, so graphviz would be a bit 
overkill :). Being able to list phases could still be cool :)

Le 22 novembre 2022 22:32:54 GMT+01:00, jgart  a écrit :
>hi,
>
>`guix graph --phases` shows the order of phases for a particular package
>and any custom phases that were introduced, deleted, replaced, etc. with
>graphviz
>
>wdyt
>
>

Re: [Guix Website] A Search Page for Packages

[Julien Lepiller]

I believe the website used both: an unprefixed url will serve the page fsom the 
prefixed directory based on accept-language, but you can also switch language 
easily by using the prefixed path.

Not translating URLs is fine and allows to easily switch language while staying 
on the same page.

Le 21 novembre 2022 20:00:29 GMT+01:00, Luis Felipe 
 a écrit :
>On Monday, November 21st, 2022 at 12:57, Ludovic Courtès  wrote:
>
>> Hi again,
>> 
>
>> Luis Felipe luis.felipe...@protonmail.com skribis:
>> 
>
>> > > > On Wednesday, November 9th, 2022 at 16:43, Luis Felipe 
>> > > > luis.felipe...@protonmail.com wrote:
>> > 
>
>> > > > > I have a working package browser now and will be styling it
>> > > > > next. I'll link to a public repository later.
>> > 
>
>> > > > Here is the source code, by the way:
>> > > > https://codeberg.org/luis-felipe/guix-packages-website
>> > 
>
>> > > Maybe some kind of alpha/beta/in development banner or message would be
>> > > good, just to set expectations that this is a new thing that's being
>> > > worked on.
>> > 
>
>> > I added that and some other things that were missing and realeased version 
>> > 0.1.0 of the package browser.
>> 
>
>> 
>
>> One thing I noticed is that i18n support seems to be missing.
>> 
>
>> It’s OK to keep that for later, but how about making sure URLs are
>> prepared to handle that, by adding /en in the path?
>> 
>
>> That is, from:
>> https://packages.guix.gnu.org/packages/ecl-cl-unicode/0.1.6/
>> to:
>> https://packages.guix.gnu.org/en/packages/ecl-cl-unicode/0.1.6/
>
>Yeah, I left i18n for later, and was actually considering getting rid of the 
>language prefix in URL paths in favor of using HTTP Request's Accept-Language 
>header to detect the user's preferred language and serve the localized 
>resources in that language if available (similar to what happens with apps on 
>the desktop). That looked like less work to me than [also] internationalizing 
>the URLs, but maybe it is not a good practice? In any case, I'm planning to 
>add i18n for version 0.2.0 and was hoping to ask Julien and Florian for advise 
>about that...

Re: foreign-distro?

[Julien Lepiller]

Le Sun, 20 Nov 2022 14:54:40 -0600,
jgart  a écrit :

> Does Guix have a declarative Guix API way of knowing if it is
> installing a package into foreign distro versus Guix System?
> 
> I'm thinking of a function like `foreign-distro?`:
> 
> ```
> (define-public peek
>   (package
>(name "peek")
>...
> (inputs 
>   `(,@(if (foreign-distro?) `(("ffmpeg" ,ffmpeg)) '(
> ```
> 
> The above includes ffmpeg in the inputs only if installing peek on a
> foreign distro. It could additionally patch the ffmpeg executable in
> a peek package phases if foreign-distro? returns #t.
> 
> WDYT
> 


Guix doesn't have a notion of foreign distro, it's all in your head,
and there's no difference between Guix System and other distros in the
Guix package manager's point of view :)

To be more specific, Guix only knows what you current system is (that's
captured by %current-system). It's probably x86_64-linux right know. As
you can see, there's no place in there to tell it whether you're on a
foreign distro or not.

Lastly, I don't think I would want to differentiate the two cases,
especially since it would mean that somehow Guix packages depend on
something external. There's this idea that Guix packages should somehow
be self-sufficient.

Re: Fwd: question on setting up guix.scm for project development

[Julien Lepiller]

To be clear, guix package always operates on the list of installed packages in 
your user profile (~/.guix-profile), not packages from your environment. Don't 
rely on its information to look at what's in a guix shell :)

Le 15 novembre 2022 16:40:05 GMT+01:00, Andy Tai  a écrit :
>Hi, thanks.
>
>guix shell -D -f guix.scm
>
>did work for me I did not see d2 0.1.4 from
>
>
>guix package --list-installed
>or
>guix package --list-available
>but
>
>pkg-config --modversion d2
>
>did show 0.1.4   So it is there, in this guix shell.
>
>Thanks for all the replies to this question.
>
>On Mon, Nov 14, 2022 at 10:15 PM Julien Lepiller  wrote:
>
>> I think you got it right, I've used thas in the past. Maybe your cli
>> options are out of order? Instead of -f -d, try -D -f. Do you even have d1
>> or d3 in your current shell? Could they come from outside?
>>
>> Le 14 novembre 2022 19:41:58 GMT+01:00, Andy Tai  a écrit :
>>>
>>>
>>> guix.scm---
>>> (use-modules (guix packages)
>>>)
>>>
>>> (define-public d2-0.1.4
>>>(package
>>>(name "d2")
>>>(version "0.1.4")
>>>
>>>...
>>> )
>>>
>>>
>>> (define-public my-package
>>>(package
>>>   (name "my-package")
>>>   (version "0.1")
>>>  ...
>>>
>>>
>>>  (input (list d1 d2-0.1.4 d3...)
>>> 
>>> ))
>>>
>>> my-package
>>>
>>> ---end guix.scm---
>>>
>>>

Re: Fwd: question on setting up guix.scm for project development

[Julien Lepiller]

I think you got it right, I've used thas in the past. Maybe your cli options 
are out of order? Instead of -f -d, try -D -f. Do you even have d1 or d3 in 
your current shell? Could they come from outside?

Le 14 novembre 2022 19:41:58 GMT+01:00, Andy Tai  a écrit :
>Hi, guix allows setting up an environment containing all the
>dependencies for development of a package; this can be done via a
>guix.scm file containing the package definition.
>
>My question is, if I am developing a package which has dependencies
>with newer versions than what is available in the guix repo, how can I
>use the guix.scm file to bring in the new version of the dependencies?
> As an example:
>
>Say  my package "my-package" has dependencies d1, d2, d3
>where d2 in the current guix package repo is at version 0.1.2 but I
>need a later release version 0.1.4; so I tried something like this:
>
>guix.scm---
>(use-modules (guix packages)
>   )
>
>(define-public d2-0.1.4
>   (package
>   (name "d2")
>   (version "0.1.4")
>
>   ...
>)
>
>
>(define-public my-package
>   (package
>  (name "my-package")
>  (version "0.1")
> ...
>
>
> (input (list d1 d2-0.1.4 d3...)
>
>))
>
>my-package
>
>---end guix.scm---
>
>
>and if I use
>
>guix shell -f -d ./guix.scm
>
>this does not seem to generate an environment that contains the new
>dependency, that is d2 version 0.1.4
>
>I wonder how can this made to work?  Ideally no need to create a
>private channel or such..  Thanks for info on this.
>

Re: guix git authenticate throws hard

[Julien Lepiller]

Commit signing is a git feature, so git itself can be used to check your last 
commits are signed:

git log --show-signature

This will look the same as git log if the commit is unsigned, and show the 
result of gpg —verify otherwise. Red background if unverified (eg. you don't 
have the public key) and green otherwise. This should zake it easy to spot 
whether you signed the last commits or not

Le 27 octobre 2022 02:07:40 GMT+02:00, jgart  a écrit :
>On Wed, 26 Oct 2022 09:07:57 +0200 Julien Lepiller  wrote:
>> It says fingerprint, so it's fingerprint. Using email or name would not be 
>> as secure.
>> 
>> Le 26 octobre 2022 07:35:20 GMT+02:00, jgart  a écrit :
>> >On Wed, 26 Oct 2022 07:21:35 +0200 Julien Lepiller  
>> >wrote:
>> >> From the manual: "signer is the OpenPGP fingerprint of public key used to 
>> >> sign commit.", but we should still catch this error :)
>> >
>> >Is it possible to give the email instead of the fingerprint?
>> >
>> >Deduce the fingerprint from the email?
>
>Julien and/or anyone else,
>
>What do you think if we have a CLI flag for git authenticate that would
>allow us to do this to authenticate the last 5 commits against the
>3B1D7F19E36BB60C0F5B2CA9A52AA2B477B6DD35 fingerprint, for example:
>
>guix git authenticate 3B1D7F19E36BB60C0F5B2CA9A52AA2B477B6DD35 -5
>
>I've run into situations where I can't remember if I signed a commit or not. 
>
>IWBC if I could just say authenticate the last commits against my
>fingerprint instead of going one by one. If this already exists and is
>not documented then we should definitely document that usage with an
>example to let others know.
>
>all best,
>
>jgart

Re: guix git authenticate throws hard

[Julien Lepiller]

It says fingerprint, so it's fingerprint. Using email or name would not be as 
secure.

Le 26 octobre 2022 07:35:20 GMT+02:00, jgart  a écrit :
>On Wed, 26 Oct 2022 07:21:35 +0200 Julien Lepiller  wrote:
>> From the manual: "signer is the OpenPGP fingerprint of public key used to 
>> sign commit.", but we should still catch this error :)
>
>Is it possible to give the email instead of the fingerprint?
>
>Deduce the fingerprint from the email?

Re: guix git authenticate throws hard

[Julien Lepiller]

From the manual: "signer is the OpenPGP fingerprint of public key used to sign 
commit.", but we should still catch this error :)

Le 26 octobre 2022 04:33:50 GMT+02:00, jgart  a écrit :
> guix git authenticate 95620d8845a75c9721876441e66bf28ba4a95eff jgart
>Backtrace:
>  11 (primitive-load "/home/jgart/.config/guix/current/bin/g…")
>In guix/ui.scm:
>   2263:7 10 (run-guix . _)
>  2226:10  9 (run-guix-command _ . _)
>In ice-9/boot-9.scm:
>  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
>  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
>  1747:15  6 (with-exception-handler # …)
>In guix/channels.scm:
>   164:10  5 (_)
>In guix/base16.scm:
> 71:7  4 (_ "a")
>In unknown file:
>   3 (string-fold # …)
>In guix/base16.scm:
>76:31  2 (_ _ 0)
>In ice-9/boot-9.scm:
>  1685:16  1 (raise-exception _ #:continuable? _)
>  1685:16  0 (raise-exception _ #:continuable? _)
>
>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>In procedure bytevector-u8-set!: Argument 2 out of range: 0
>
>WDYT
>

Re: Build LanguageTool use maven-build-system?

[Julien Lepiller]

Le 25 octobre 2022 04:10:51 GMT+02:00, Declan Tsien  a 
écrit :
>
>I believe LanguageTool[1] is a Java project using Maven as it's building
>tool.
>
>Lazy me. Instead of digging the mailing list and source code which would
>cost too much time and may not work out. I packaged the binary
>distribution (jar files) using =copy-build-system= which I am trying to
>get it merged into Nonguix[2] in case someone else also wants it.
>
>So my questions would be:
>
>1: What is the current status of maven-build-system? Is it capable of
>building a package like this[3]?

It's working fine, but most packages are still lacking a lot of dependencies, 
including some maven plugins

>
>2: Also, I don't see =guix import= has support for maven. Does that mean
>we have to manually write a package definition for every dependency if
>it wasn't included in Guix yet?

There's no importer and an importer would be a bit limited as it won't be able 
to get proper sources most of tge tine, though importing the dependency graph 
would be useful already. Would you like to give it a try? :)

>
>3: If =maven-build-system= is capable of building a package like this,
>would someone like to tackle packaging =LanguageTool= from source? 

Like I said, the biggest issue would be number of packages, and maybe bug fixes 
as we currently have only one package using the maven-build-system.

>
>1: https://github.com/languagetool-org/languagetool
>2:
>https://gitlab.com/nonguix/nonguix/-/merge_requests/226#note_1147169576
>3: https://github.com/languagetool-org/languagetool/blob/master/pom.xml
>
>Thanks

Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[Julien Lepiller]

Deadline for stands is November 15th. Quoting the website:

FOSDEM 2023 stands call for proposals

Back after two virtual editions, FOSDEM 2023 will take place at the ULB on the 
4th and 5th of February 2023. As has become traditional, we offer free and open 
source projects a stand to display their work “in real life” to the audience. 
You can share information, demo software, interact with your users and 
developers, give away goodies, sell merchandise or accept donations. All is 
possible! 

We offer you: 

One table (180x80cm) with a set of chairs and a power socket.

Fast wireless internet access.

A spot on stands.fosdem.org. 

You can choose if you want the spot for the entire conference, or simply for 
one day. Joint submissions (sharing a table) will be favoured in the process. 

Submit your application at stands.fosdem.org/submission! Deadline closes the 
15th of November; accepted stands will be announced the 1st of December. 

Le 20 octobre 2022 19:36:48 GMT+02:00, zimoun  a 
écrit :
>Hi Julien,
>
>> IIRC, Julien was responsible for a booth at FOSDEM for Linux From
>> Scratch some years ago, so maybe they can share their experience?
>
>I am a bit lost with FOSDEM website, news and deadline.  How does it
>work to ask for a booth?
>
>
>Cheers,
>simon

Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[Julien Lepiller]

I'll be happy to help!

From my experience with LFS it's important to have enough to share with people. 
We had stickers (obviously), and also bookmarks and even printed versions of 
the book. Even with three people we could manage the stand, but the more we 
are, the easier it becomes. Remember you have to attend the devroom too!

We had issues managing stocks of stickers. Having too many displayed at once 
will incentivise people to take a huge pile to share with friends at home, but 
it also means the stocks deplete quickly :)

One nice thing to have is also a table cloth with our logo/graphics. Some 
distros have live-CDs.

I can take care of ordering that, stickers and anything else if I get 
reimbursed. I can't come up with nice graphics by myself though, so please 
share any ideas :)

Le 20 octobre 2022 16:44:49 GMT+02:00, Jonathan Brielmaier 
 a écrit :
>On 18.10.22 18:59, zimoun wrote:
>> Hi,
>> 
>> As the winter, FOSDEM 2023 is coming…
>> 
>>  https://fosdem.org/2023
>> 
>> 
>> Three questions:
>> 
>>   1. do we run for a booth?
>>   2. who is in?
>>   3. who is volunteer to make that happens?
>
>Count me in as volunteer for the booth. I'll can help from Friday
>afternoon until sunday afternoon/evening.
>
>~Jonathan
>

Re: Advanced network configuration

[Julien Lepiller]

Le 10 octobre 2022 17:17:16 GMT+02:00, "Ludovic Courtès"  a écrit 
:
>Hi!
>
>Alexey Abramov  skribis:
>
>[...]
>
>>> I’m not sure.  IIUC, a “networking target” here could translate to a
>>> Shepherd service that depends on all the relevant DHCP and static
>>> networking services.  The question the becomes how to express that
>>> grouping conveniently.
>>
>> Yes, I also would like to point out that their must be a way to
>> establish a firewall, for example, *before* any network interface is up
>> (After=network-pre.target in systemd [1]). And the same thing during the
>> shutdown procedure (Before=network-pre.target in systemd).
>
>I would do that by having ‘networking’ depend on ‘firewall’ (say).
>
>Does that make sense?

Wouldn't there be an issue if firewall rules reference interfaces created by 
the networking service?

>
>It’d be interesting to see whether we need something beyond this.
>

Re: Packaging docs

[Julien Lepiller]

I don't know what other commiters think about that, but you could try and 
suggest a concrete change. Can you write a patch, or at least a paragraph and 
point to the location it should go to, in the manual?

Le 8 octobre 2022 19:24:31 GMT+02:00, jgart  a écrit :
>On Sat, 08 Oct 2022 08:08:28 +0200 Julien Lepiller  wrote:
>> I don't think there's a specific policy, but our packages tend to enable 
>> most optional dependencies and docs are always useful, so I'd package doc 
>> dependencies too.
>> 
>
>Hi roptat,
>
>Should we make a policy and add it to the docs?
>
>--
>jgart
>
>

Re: Packaging docs

[Julien Lepiller]

I don't think there's a specific policy, but our packages tend to enable most 
optional dependencies and docs are always useful, so I'd package doc 
dependencies too.

Le 8 octobre 2022 05:08:34 GMT+02:00, jgart  a écrit :
>Hi,
>
>What's are policy for packaging docs deps?
>
>For example, this package has docs deps:
>
>https://github.com/m-lundberg/simple-pid/blob/master/docs/requirements.txt
>
>Should those be packaged and included also in the Guix package definition?
>
>Is our policy for packaging docs deps documented somewhere?
>

Re: Planning for a release, for real

[Julien Lepiller]

It depends on the language, I'd say a week is good, maybe less as long as we 
can include a week-end (maybe it's personal, but I find more time to contribute 
in the week-ends).

Le 7 octobre 2022 11:49:21 GMT+02:00, "Ludovic Courtès"  a écrit :
>Hi,
>
>Julien Lepiller  skribis:
>
>> I'll take care of the cranslations (notifying translators, ensuring string 
>> freeze is respected, …)
>
>Great, thanks.
>
>> We need to be careful not to start the stsing freeze step too early. Last 
>> time (or previous?) we started a week before the scheduled release date, but 
>> the schedule slipped by a few weeks and we had some pressure in the pipeline 
>> because some patches could not be applied because of string changes.
>>
>> Let's try to have a better vision on the planning this time :)
>
>Right!  How long do you think we need for the string freeze?
>
>I feel that thanks to Weblate translations are continuously updated, so
>maybe things can be frozen for a shorter period of time?
>
>Thanks,
>Ludo’.

Re: Planning for a release, for real

[Julien Lepiller]

I'll take care of the cranslations (notifying translators, ensuring string 
freeze is respected, …)

We need to be careful not to start the stsing freeze step too early. Last time 
(or previous?) we started a week before the scheduled release date, but the 
schedule slipped by a few weeks and we had some pressure in the pipeline 
because some patches could not be applied because of string changes.

Let's try to have a better vision on the planning this time :)

Le 6 octobre 2022 16:50:22 GMT+02:00, "Ludovic Courtès"  a écrit :
>Hello Guix!
>
>Will Guix’s 10th year be a release year?  I hope so!
>
>We need to plan and coordinate.  Releases have to be a group effort;
>some of the most important work won’t be coding but coordination.
>Coordination is key.  I don’t think I should be spearheading that
>effort, but I’m happy to be part of it.
>
>Who’s ready to commit time towards that goal for the coming weeks?
>
>Here’s a list of things to do to get there:
>
>  • Merge ‘staging’ (?).  What’s the status of that one, it seemed ready
>a couple of weeks ago, but then I lost track of it.  Marius?
>
>We need a ‘staging’ champion to keep track of what’s left to be
>done, reports progress, pings people, etc.  That person does not
>have to be hacking like crazy, on the contrary!
>
>  • Get base binaries on all supported architectures in a timely
>fashion, or drop some of the architectures.
>
>Namely, ‘make assert-binaries-available’ is currently failing.  It
>uses a manifest that encodes what we consider to be the basic
>requirements for each architecture; it’s not demanding for
>aarch64-linux, even less for armhf-linux and i586-gnu—yet we’re not
>meeting these criteria yet.
>
>We need to look at missing substitutes, address build issues and
>build farm issues that cause them until we get to zero failures.  If
>after some effort we fail to get to zero, then we should consider
>dropping architectures (I’m looking at armhf-linux and i586-gnu
>specifically).
>
>Again we need a champion to keep track of this and ping people so we
>make progress!
>
>  • Address the blockers of , most of
>which are issues in the installer.
>
>  • Freeze strings: enter a period where translatable strings in the
>code and in the manual must not be changed so translators have a
>chance to keep up.  Julien, how would you like to do that?  Weblate
>has given us more flexibility it seems.
>
>  • Publish a release candidate and call for testing of the installer in
>particular.  Fix bugs, loop.
>
>  • Update NEWS (mostly done already!), prepare a blog post listing the
>highlights and linking to the relevant material.  (See
> for inspiration.)
>
>I’d like us to do this with an eye of getting better organized, which
>involves defining roles such as that of “release managers”.
>
>The NixOS folks handle this in a way that I find inspiring, with
>rotating release manager responsibilities, a schedule announced upfront,
>and a detailed description of the process:
>
>  https://github.com/NixOS/nixpkgs/issues/193585
>  https://nixos.github.io/release-wiki/Home.html
>
>We have
>
>but it’s low-level and dates back to a time where release were a
>one-person activity.  Time for a change.
>
>So, who’s in?  Let’s get our act together!
>
>Ludo’.

Re: Advanced network configuration

[Julien Lepiller]

I guess using debbugs would give other people a chance to have a look at your 
patches and comment, but I'm the only one who can push anyway. If you decide to 
use debbugs, make sure to CC me too.

Le 6 octobre 2022 15:11:30 GMT+02:00, Alexey Abramov  a 
écrit :
>Hi Ludo, Julien
>
>Ludovic Courtès  writes:
>
>> Hi Alexey,
>>
>> (Cc: Julien, author of Guile-Netlink.)
>>
>
>[...]
>
>>
>> I’m sure your improvements to Guile-Netlink would be welcome.
>
>> Regarding ‘static-networking’ in Guix, the goal was to allow it to be as
>> expressive as the underlying netlink interface, but clearly we focused
>> on the most common use cases.
>>
>> If you can think of how you’d like to represent these setups in
>> ‘static-networking’ (perhaps a ‘bonds’ field similar to the netplan YAML
>> snippet you showed?), we (or you :-)) can try and implement it.
>
>Yeah, that was my intention =). @Julien Could you tell me how can I
>collaborate? Shall I send patches to you directly or maybe debbugs, or
>guix-patches?
>
>>> 2. Having a router with Guix at home. I have to run multiple services
>>> that provision 'networking' which is not allowed right now. The DHCP
>>> client service is greedy right now and binds to all available
>>> interfaces. I sent a [1] patch to solve this. However, I cannot define
>>> dhcp-client and static configuration at the same time anyway.
>>
>> OK, we could allow users to change the Shepherd service name used by the
>> DHCP client then.
>
>That would indeed help for now. I can prepare yet another patch for
>that.
>
>[...]
>
>> I’m not sure.  IIUC, a “networking target” here could translate to a
>> Shepherd service that depends on all the relevant DHCP and static
>> networking services.  The question the becomes how to express that
>> grouping conveniently.
>
>Yes, I also would like to point out that their must be a way to
>establish a firewall, for example, *before* any network interface is up
>(After=network-pre.target in systemd [1]). And the same thing during the
>shutdown procedure (Before=network-pre.target in systemd).  Applications
>have to be able to gracefully shutdown their network connections.  Is it
>the case right now, I don't know?
>
>I am checking (shepherd services) where `shutdown-services' defined, and
>seems like it just walks across %services hash table. Am I missing
>something?
>
>Footnotes:
>[1]  
>https://www.freedesktop.org/software/systemd/man/systemd.special.html#network-pre.target
>
>-- 
>Alexey

Re: Capitole du Libre at Toulouse

[Julien Lepiller]

I'll be there, so we could still meet :)

Le 3 octobre 2022 09:24:05 GMT+02:00, Oliver Propst  
a écrit :
>On 2022-10-01 13:14, Andreas Enge wrote:
>> Am Mon, Sep 26, 2022 at 11:30:53PM +0200 schrieb zimoun:
>> We decided that with only two confirmed and one uncertain participation,
>> we would not have enough people power and did not submit anything.
>> 
>> Andreas
>
>Sorry to hear this :(
>
>-- 
>Kinds regards Oliver Propst
>https://twitter.com/Opropst
>

Re: stray go files

[Julien Lepiller]

I don't think your error is related to that file. A stray go file is a file 
that exist but doesn't have a corresponding scm file that would be built in 
guix.po.scm is not needed, and ends up being stray. If you figure out how to 
fix that, I'd be happy :)

I think you will have to run configure again, because you have a reference to a 
store item that doesn't exist anymore.

Le 10 septembre 2022 17:06:05 GMT+02:00, jgart  a écrit :
>On Sat, 10 Sep 2022 10:04:50 -0500 jgart  wrote:
>> do you happen to know why this error occurs when running `make clean-go`?
>
>After running make and manually deleting po.go I get this
>
>./pre-inst-env: line 55: 
>/gnu/store/hr8j0z9qpwcxzi5d9mr5di9yl68pw6hw-profile/bin/guile: No such file or 
>directory
>make: *** [Makefile:6811: guix/build/po.go] Error 127
>

Re: Clojure & Maven Resolver packages

[Julien Lepiller]

You could try updating maven resolver, but that means you will also have to 
rebuild all its dependents and make sure they don't break.

Maven stuff are a bit fragile under Guix because we can't build them as 
intended. There's a chicken-and-egg problem with maven, its dependencies and 
its plugins. So we can only use a rudimentary build system that breaks easily 
with updates.

If you decide to try and update that package, it would be much welcome and if 
you have any issues or questions along the way, don't hesitate to ask for help!

Le 3 septembre 2022 17:38:37 GMT+02:00, Roman Scherer 
 a écrit :
>Hello Guix,
>
>I would like to enable the S3 transporter for the Clojure package. For
>this I need version 1.8.2 of the Maven Resolver packages. Right now we
>have version 1.6.3 packaged in Guix.
>
>Should I update the existing packages to 1.8.2 or create new package
>variants with a 1.8 prefix for this?
>
>Right now I have the variants, but I was wondering what the best
>approach would be.
>
>Thanks, Roman.

Re: GitLab to plans to delete dormant projects

[Julien Lepiller]

Our build farms need those sources, so they keep them in cache. If you need a 
source, you can always substitute from the build farms if the origin 
disappeared (that's actually the default and you don't even need to trust the 
build farm for that to work).

Another fallback option when substitution is not possible is to get the source 
from Software Heritage. They keep an archive of almost everything. To do that, 
they have listers that help tgem find sources fsom different sesvices. They 
have a lister for GitLab, and even one for Guix. Also, as part of guix lint, a 
request is sert to swh if the oriqin is not yet archived.

Hopefully that means our origins are saved by Software Heritage, so we can 
transparently fall back to them.

Le 6 août 2022 15:08:21 GMT+02:00, "Olivier Dion via Development of GNU Guix 
and the GNU System distribution."  a écrit :
>Hi,
>
>Following this article , GitLab is
>planning to start deleting project that were idle for > 12 months.
>
>Many packages origin in Guix use an url to a GitLab project.  What are
>the consequence of such deletion on Guix reproducibility?  Will it
>affects the time-machine?
>
>-- 
>Olivier Dion
>oldiob.dev
>
>

Re: nix installed with guix on a foreign distro

[Julien Lepiller]

It's a common limitation of packages that provide a server. Guix doesn't manage 
daemons on foreign distros, it's the role of your distro.

You might be able to set it up by installing as root, maybe manually copy the 
systemd service and hope that's enough. We can't support all methods of running 
daemons there exist on foreign distros, so you're on your own.

Le 27 juillet 2022 00:49:07 GMT+02:00, jgart  a écrit :
>On Tue, 26 Jul 2022 16:16:58 -0500 Nathan Dehnel  wrote:
>> I just installed the nix package provided by the host distro (not
>> guix). Seems to work fine.
>
>Hi Nathan,
>
>I've done that plenty of times before. That's usually how I install nix
>on a foreign distro (i.e. by using apt or xbps (void linux), etc.)
>
>What I'm asking about here is making it easy to install nix with guix on a 
>foreign distro.
>
>Currently, I can do the following on a foreign distro:
>
>`guix install nix`
>
>But the above will not set up the daemon service and create the build users, 
>etc...
>
>So, currently I'm not sure how we should go about supporting that on a foreign 
>distro...
>
>wdyt,
>
>jgart
>

Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Julien Lepiller]

I agree that we should better document that policy. I think we could go 
further, but it's ok to document the common denominator first. To me, the 
structure you suggest is not great, but I don't have issues with the content.

Le 25 juillet 2022 13:18:28 GMT+02:00, Maxime Devos  a 
écrit :
>
>On 25-07-2022 07:21, Julien Lepiller wrote:
>> I don't like the wording at all. You're mixing too many things together.
>Feel free to try to separate the things, but going previous discussions, many 
>tings are important, and they appear all to be inseparable.
>> 
>> I think it would be better to first document the guiding principles (eg. the 
>> goal that there are no non-free software in Guix, going for the simplest 
>> thing, etc) and then derive rules for specific cases, based on these 
>> principles:
>> 
>> How do I remove non-free software? -> snippet because …
>> 
>> How do I remove bundled libraries? -> snippet or phase because …
>> 
>> How do I fix a build issue? -> patch or snippet if this affects building 
>> from source, can also be a phase if the result of --sources can still build
>> 
>> A test issue?
>> 
>> …
>> 
>> This leaves some cases up to interpretation, but that's probably not so 
>> different from "it's not an absolute rule". It's also much clearer and 
>> quicker to figure out in which case you are. If not documented as a case, 
>> you can fall back to the general principles.
>
>TBC, is the issue here the structure of the section, or some individual rules? 
>In the former case, I could try rewriting it a bit to follow your proposed 
>structure.
>
>Greetings,
>Maxime.

Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Julien Lepiller]

I don't like the wording at all. You're mixing too many things together.

I think it would be better to first document the guiding principles (eg. the 
goal that there are no non-free software in Guix, going for the simplest thing, 
etc) and then derive rules for specific cases, based on these principles:

How do I remove non-free software? -> snippet because …

How do I remove bundled libraries? -> snippet or phase because …

How do I fix a build issue? -> patch or snippet if this affects building from 
source, can also be a phase if the result of --sources can still build

A test issue?

…

This leaves some cases up to interpretation, but that's probably not so 
different from "it's not an absolute rule". It's also much clearer and quicker 
to figure out in which case you are. If not documented as a case, you can fall 
back to the general principles.

Le 25 juillet 2022 05:17:33 GMT+02:00, Maxime Devos  a 
écrit :
>Context: it's currently a mess:, and at times contradictory
>
> * There is policy involving those three, as can be seen from the
>   shepherd mess.
> * This policy is partially secret, as can be seen by some people
>   treating some things as policy even if it's not in the manual.
> * Some versions of the policy are based on archeology, e.g. see the
>   'snippets were introduced for this particular purpose, so don't use
>   it for other things’ which is not documented in the manual as sole
>   legitimate reason and asking contributors to read all past
>   discussions seems too much for me.
> * Sometimes, people refer to the manual (Snippets versus Phases) for
>   how things (should) work, but what they say is not actually present
>   in that section of the manual.
> * Some variants of the policy are contradictory with each other (IIRC)
> * Some of the policies are contradictory with current practice in
>   other Guix packages.
> * '(guix)Snippets versus Phases says Phases' states that it is elusive.
> * The section name implies it's a ‘X versus Y’, which seems
>   polarizing? (Maybe?)
> * The section neglects the is/ought-distinction -- it just says what
>   is typically used for what, not whether they should be used for them
>   and whether they are allowed to be used for other things, so that
>   section does not seem policy to me (except for the single 'should
>   produce' and 'must not' line), only matters of fact.
>
>I can't work with such a mess. As such, I've a proposal for a consistent, 
>clear and non-elusive set of rules and guidelines, based on the following 
>principles:
>
> * It appears we cannot agree on what exactly the policy should be, but
>   having a single policy everyone can use even if some would rather
>   have the specifics be a tiny bit different, is much better than the
>   mess of everyone having their own policy.
> * There are no absolutes, except that the result of "guix build
>   --source" must be free software;
> * There can be more than one (acceptable) way to do things, but this
>   doesn't make things elusive, this just means there are multiple
>   acceptable options and you should probably go for the simplest.
>
>More concretely, I propose the following new contents for (guix)Snippets 
>versus Phases (the phrasing could use some work for smooth reading), which I 
>believe to be sufficiently clear (except for some phrasing that could be 
>tweaked, e.g. the phrases are currently rather long), covers a sufficient 
>amount of cases (feel free to respond if you see a missing case), free of 
>contradictions (likewise) and mostly in line with current practice:
>
>[start]
>
>@c: There is no opposition or such, so no versus, let's not start with 
>polarisation.
>
>20.4.5 Snippets, phases and patches
>
>Snippets, phases and patches at times serve overlapping purposes. To decide 
>between the three, there are several considerations to keep in mind:
>
> * Patches must not be used to remove non-free files, because a patch
>   by construction contains the non-free file itself so the patch would
>   be non-free, which would not be acceptable to Guix. Likewise,
>   patches should not be used to remove bundled libraries, to avoid
>   large space usage, but this is not an absolute rule unlike as for
>   non-free files.
> * Snippets are often convenient for removing unwanted files such as
>   bundled libraries, non-free sources and binaries. It is technically
>   also possible to use phases for this, albeit slightly less
>   convenient at times. However, phases must not be used to remove
>   non-free sources, as then the output of "guix build --source" would
>   still contain the non-free sources, which is incompatible with Guix'
>   stance on free software. Likewise, phases should not be used to
>   remove binaries; however, this is not strictly forbidden.
> * Snippets must not embed store items in the source, as this is
>   incompatible with cross-compilation and prevents effectively sharing
>   the source code produced with "guix build --source" with people
>   using 

Translating news on weblate?

[Julien Lepiller]

Hi Guix!

I was thinking we could have our news file translated at weblate, which
would help having more people translate it. Attached is a script that
is able to generate a pot file from the news.scm file and a translated
news.scm file from the existing news.scm and a directory that contains
the po files and a LINGUAS file.

The goal is to regularly fetch the news.scm file, generate a new pot
that would automatically be updated on weblate. Translators can do
their work, and the result is regularly merged back (after being
checked that it doesn't break) in our repo.

The script tries to reformat the news in a standard way and to merge
existing copyright lines with the authorship lines in the po files. It
is also able to generate the initial po files that I would give
weblate, so translators don't have to redo translations that have
already been done.

I also attached the LINGUAS file with all languages for which we have
at least one entry in news.scm.

WDYT?


LINGUAS
Description: Binary data
#!/gnu/store/5rbr7gi8q7gpmb4gmqrpnpk55a4gjpkz-profile/bin/guile \
--no-auto-compile -s
!#

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2022 Julien Lepiller 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;; This code is a helper for news file translation using Gettext.

;;; Code:

(use-modules (srfi srfi-1)
 (srfi srfi-9)
 (srfi srfi-19)
 (ice-9 match)
 (ice-9 pretty-print)
 (ice-9 rdelim)
 (ice-9 regex)
 (guix build po)
 (guix channels))

(define read-channel-news (@@ (guix channels) read-channel-news))
(define channel-news-entries (@@ (guix channels) channel-news-entries))
(define  (@@ (guix channels) ))
(define channel-news-entry (@@ (guix channels) channel-news-entry))

(define (print-msg msg)
  (if msg
(let* ((msg (string-join (string-split msg #\\) ""))
   (msg (string-join (string-split msg #\") "\\\""))
   (msg (string-join (string-split msg #\newline)
 "\\n\"\n\"")))
  (if (string-contains msg "\n") (string-append "\"\n\"" msg) msg))
""))

(define* (generate-po news-file pot-file #:optional lang)
  "Generate a pot file from a news file."
  (let ((news (call-with-input-file news-file read-channel-news)))
(call-with-output-file pot-file
  (lambda (port)
(format port "# SOME DESCRIPTIVE TITLE~%")
(format port "# Copyright (C) YEAR the authors of Guix (msgids) and the following authors (msgstr)~%")
(format port "# This file is distributed under the same license as the guix news file.~%")
(format port "# ~%")
(format port "msgid \"\"~%")
(format port "msgstr \"\"
\"Project-Id-Version: guix news checkout\\n\"
\"Report-Msgid-Bugs-To: bug-g...@gnu.org\\n\"
\"POT-Creation-Date: ~a\\n\"
\"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\\n\"
\"Last-Translator: FULL NAME \\n\"
\"Language-Team: LANGUAGE \\n\"
\"Language: \\n\"
\"MIME-Version: 1.0\\n\"
\"Content-Type: text/plain; charset=UTF-8\\n\"
\"Content-Transfer-Encoding: 8bit\\n\"~%~%" (date->string (current-date)))
(for-each
  (match-lambda
(($  commit tag title body)
 (let ((msgid1 (assoc-ref title "en"))
   (msgid2 (assoc-ref body "en"))
   (msgstr1 (assoc-ref title lang))
   (msgstr2 (assoc-ref body lang)))
   (when commit
 (format port "#. commit: ~a~%" commit))
   (when tag
 (format port "#. tag: ~a~%" tag))
   (format port "msgid \"~a\"~%" (print-msg msgid1))
   (format port "msgstr \"~a\"~%~%" (print-msg msgstr1))
   (when commit
 (format port "#. commit: ~a~%" commit))
   (when tag
 (format port "#. tag: ~a~%" tag))
   (format port "msgid \"~a\&qu

Re: Bootstrap script only works with guix environment, not with guix shell

[Julien Lepiller]

That's because you're not using guix shell properly.

guix shell guix

Creates a shell where guix *itself* is available

guix shell -D guix

Creates a shell where guix *dependencies* are available. That's what you need 
to use.

The manual provides more information on how to build Guix from the sources: 
https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html#Building-from-Git

HTH!

On July 9, 2022 12:02:12 AM GMT+02:00, Zelphir Kaltstahl 
 wrote:
>On 7/8/22 23:57, Zelphir Kaltstahl wrote:
>> 
>> Hello Guix developers!
>> 
>> I am messing around again with updating a package and according to my own 
>> guide from previous adventures, I have to run the following command to 
>> generate the `pre-inst-env` script, in the root directory of the guix 
>> sources:
>> 
>> 
>> guix environment guix -- ./bootstrap
>> 
>> 
>> But then I remembered, that actually `guix shell` is the newer thing and 
>> changed it to:
>> 
>> 
>> guix shell guix -- ./bootstrap
>> 
>> 
>> However, this does not work. I get an error:
>> 
>> 
>> $ guix shell guix -- ./bootstrap
>> + find po/doc -type f -name guix-manual*.po
>> + sed -e s,.*/guix-manual\.,,;s,\.po$,,
>> + langs=fr
>> ru
>> es
>> pt_BR
>> de
>> zh_CN
>> + [ ! -e doc/guix.fr.texi ]
>> + [ ! -e doc/guix.ru.texi ]
>> + [ ! -e doc/guix.es.texi ]
>> + [ ! -e doc/guix.pt_BR.texi ]
>> + [ ! -e doc/guix.de.texi ]
>> + [ ! -e doc/guix.zh_CN.texi ]
>> + find po/doc -type f -name guix-cookbook*.po
>> + sed -e s,.*/guix-cookbook\.,,;s,\.po$,,
>> + langs=de
>> fr
>> sk
>> ko
>> + [ ! -e doc/guix-cookbook.de.texi ]
>> + [ ! -e doc/guix-cookbook.fr.texi ]
>> + [ ! -e doc/guix-cookbook.sk.texi ]
>> + [ ! -e doc/guix-cookbook.ko.texi ]
>> + exec autoreconf -vfi
>> autoreconf: Entering directory `.'
>> autoreconf: running: autopoint --force
>> autoreconf: running: aclocal --force -I m4
>> autoreconf: configure.ac: tracing
>> autoreconf: configure.ac: not using Libtool
>> autoreconf: running: /usr/bin/autoconf --force
>> configure.ac:92: error: possibly undefined macro: GUILE_MODULE_AVAILABLE
>>If this token and others are legitimate, please use m4_pattern_allow.
>>See the Autoconf documentation.
>> configure.ac:99: error: possibly undefined macro: GUILE_PKG
>> configure.ac:100: error: possibly undefined macro: GUILE_PROGS
>> autoreconf: /usr/bin/autoconf failed with exit status: 1
>> 
>> 
>> When I use `guix environment` it works:
>> 
>> 
>>   guix environment guix -- ./bootstrap
>> + find po/doc -type f -name guix-manual*.po
>> + sed -e s,.*/guix-manual\.,,;s,\.po$,,
>> + langs=fr
>> ru
>> es
>> pt_BR
>> de
>> zh_CN
>> + [ ! -e doc/guix.fr.texi ]
>> + [ ! -e doc/guix.ru.texi ]
>> + [ ! -e doc/guix.es.texi ]
>> + [ ! -e doc/guix.pt_BR.texi ]
>> + [ ! -e doc/guix.de.texi ]
>> + [ ! -e doc/guix.zh_CN.texi ]
>> + find po/doc -type f -name guix-cookbook*.po
>> + sed -e s,.*/guix-cookbook\.,,;s,\.po$,,
>> + langs=de
>> fr
>> sk
>> ko
>> + [ ! -e doc/guix-cookbook.de.texi ]
>> + [ ! -e doc/guix-cookbook.fr.texi ]
>> + [ ! -e doc/guix-cookbook.sk.texi ]
>> + [ ! -e doc/guix-cookbook.ko.texi ]
>> + exec autoreconf -vfi
>> autoreconf: Entering directory `.'
>> autoreconf: running: autopoint --force
>> autoreconf: running: aclocal --force -I m4
>> autoreconf: configure.ac: tracing
>> autoreconf: configure.ac: not using Libtool
>> autoreconf: running: 
>> /gnu/store/km9l89sd4wm9jp358481v2z6qacwl2h9-autoconf-2.69/bin/autoconf 
>> --force
>> autoreconf: running: 
>> /gnu/store/km9l89sd4wm9jp358481v2z6qacwl2h9-autoconf-2.69/bin/autoheader 
>> --force
>> autoreconf: running: automake --add-missing --copy --force-missing
>> Makefile.am:816: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
>> autoreconf: Leaving directory `.'
>> 
>> 
>> I do not know, if this is intentional or not, but I thought that `guix 
>> environment` will be phased out or something.
>> 
>> Here is my installed guix version:
>> 
>> 
>> $ guix describe
>>guix d7d2340
>>  repository URL:https://git.savannah.gnu.org/git/guix.git
>>  branch: master
>>  commit: d7d23407213247d0173eabd2c769f2b98cef4fe9
>> 
>> $ guix --version
>> guix (GNU Guix) 0
>> Copyright (C) 2022 the Guix authors
>> License GPLv3+: GNU GPL version 3 or later
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> 
>> 
>> I did `guix pull && guix package -u` just a few minutes ago, so everything 
>> should be quite up-to-date.
>> 
>> Best regards,
>> Zelphir
>> 
>> -- 
>> repositories:https://notabug.org/ZelphirKaltstahl
>
>Addendum:
>
>I just noticed, that also the next step `guix shell guix -- ./configure 
>--localstatedir=/var` does not work, but `guix environment guix -- ./configure 
>--localstatedir=/var` does work:
>
>
>$ guix shell guix -- ./configure --localstatedir=/var
>checking for a BSD-compatible install... /usr/bin/install -c
>checking whether build 

Re: Samba Services

[Julien Lepiller]

This is the relevant part. I think the rest is noise caused by the issue in the 
manual being copied to all translations:

./doc/guix.texi:29670: warning: node next `Network File System' in menu 
`Continuous Integration' and in sectioning `Samba Services' differ
./doc/guix.texi:16349: node `Services' lacks menu item for `Samba Services' 
despite being its Up target
./doc/guix.texi:29985: warning: node prev `Continuous Integration' in menu 
`Network File System' and in sectioning `Samba Services' differ

In particular, it sounds like you didn't add the Samba Services node to the 
menu near line 16349 (that's a different menu from the one at the top of the 
file I believe). The other warnings should disappear after you add it.

On July 5, 2022 9:21:48 AM GMT+02:00, Simon Streit  wrote:
>Hello,
>
>While preparing my patch series [1], I've run into issues where I can't
>compile my own branch now:
>
>--8<---cut here---start->8---
>  MAKEINFO doc/guix.fa.info
>./doc/guix.es.texi:30547: warning: node next `Sistema de archivos en red' in 
>menu `Integración continua' and in sectioning `Samba Services' differ
>./doc/guix.es.texi:16840: node `Servicios' lacks menu item for `Samba 
>Services' despite being its Up target
>./doc/guix.es.texi:30867: warning: node prev `Integración continua' in menu 
>`Sistema de archivos en red' and in sectioning `Samba Services' differ
>./doc/guix.texi:29670: warning: node next `Network File System' in menu 
>`Continuous Integration' and in sectioning `Samba Services' differ
>./doc/guix.texi:16349: node `Services' lacks menu item for `Samba Services' 
>despite being its Up target
>./doc/guix.texi:29985: warning: node prev `Continuous Integration' in menu 
>`Network File System' and in sectioning `Samba Services' differ
>make[2]: *** [Makefile:4834: doc/guix.es.info] Error 1
>make[2]: *** Waiting for unfinished jobs
>make[2]: *** [Makefile:4704: doc/guix.info] Error 1
>./doc/guix.fa.texi:29097: warning: node next `Network File System' in menu 
>`Continuous Integration' and in sectioning `Samba Services' differ
>./doc/guix.fa.texi:16005: node `Services' lacks menu item for `Samba Services' 
>despite being its Up target
>./doc/guix.fa.texi:29407: warning: node prev `Continuous Integration' in menu 
>`Network File System' and in sectioning `Samba Services' differ
>make[2]: *** [Makefile:4899: doc/guix.fa.info] Error 1
>./doc/guix.de.texi:31749: warning: node next `Network File System' in menu 
>`Kontinuierliche Integration' and in sectioning `Samba Services' differ
>./doc/guix.de.texi:17543: node `Dienste' lacks menu item for `Samba Services' 
>despite being its Up target
>./doc/guix.de.texi:32070: warning: node prev `Kontinuierliche Integration' in 
>menu `Network File System' and in sectioning `Samba Services' differ
>make[2]: *** [Makefile:4769: doc/guix.de.info] Error 1
>make[2]: Leaving directory '/home/ss2/code/guix'
>make[1]: *** [Makefile:6573: all-recursive] Error 1
>make[1]: Leaving directory '/home/ss2/code/guix'
>make: *** [Makefile:4004: all] Error 2
>--8<---cut here---end--->8---
>
>Chances are I missed something while preparing the manual. The problem
>arises with this [2] commit.  
>
>Test units in this branch have been prepared too.  Thinking about it
>wsdd hasn't got any yet.  
>
>[1] https://git.steel-is-real.com/guix/log/?h=simons-samba-service
>[2] 
>https://git.steel-is-real.com/guix/commit/?h=simons-samba-service=04fd3f8e4eb840b9e2b10337a65035f33bbffce4
>
>Thanks in advance for looking into this! 
>
>
>Kind regards
>Simon 
>

Re: Seek Gitolite users (was bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks)

[Julien Lepiller]

I use gitolite, what should I do to help?

On June 23, 2022 11:35:18 AM GMT+02:00, zimoun  wrote:
>Hi,
>
>This old bug #25957 [1] needs a Gitolite user. :-)
>
>1: 
>
>
>On Mon, 28 Mar 2022 at 09:49, Efraim Flashner  wrote:
>
>> I spent some time looking at gitolite and the service. As I understand
>> it, with the exception of svnserve, it searches $PATH for a number of
>> different binaries, including git-annex. I believe that this would only
>> work if git-annex (and potentially other packages) are installed
>> globally.
>>
>> In addition, git (not git-minimal) and openssh are propagated inputs AND
>> wrapped. I haven't tested to see if wrapping only is enough.
>>
>> I think the best choice is to:
>> A: Replace /usr/bin/svnserve with svnserve so it will just search $PATH,
>> like it does with the other helpers.
>> B: Adjust the service so that it automatically creates a variant (or
>> just a wrapped version) of the package which is wrapped with a list of
>> additional packages so that they can be in gitolite's path. If I were
>> deploying this to an arm device I wouldn't want it wrapped with
>> git-annex since it doesn't build, but would definitely want it for an
>> x86_64 machine.
>>
>> I suppose we should try to find someone who is using the gitolite
>> service and see if they can be our test subject for wrapping the package
>> with optional addons.
>
>Any volunteer ?  For testing Gitolite and then close this very old bug
>from 5 years, 15 weeks, 6 days ago.
>
>
>Cheers,
>simon
>

Re: maradns reproducibility fixes and the merits of picking a random number

[Julien Lepiller]

On June 7, 2022 5:24:22 AM GMT+02:00, Felix Lechner  
wrote:
>Hi,
>
>On Mon, Jun 6, 2022 at 6:50 PM Vagrant Cascadian
> wrote:
>>
>> So, Debian's maradns package just removes this embedding of a "random"
>> number, and I've basically adapted their patches to build reproducibly
>> on guix too... by basically embedding the same "random" number every
>> single build!
>
>There may be more than one opinion, but as the maintainer of a TLS
>library in Debian I think it is a questionable tradeoff. At a minimum,
>it would be preferable to use the version number instead of a fixed
>constant for all releases.

Consider that even without the patch, each distro will build maradns once and 
distribute the package to their user. Every user gets the same binary with the 
same "random" number. So even if it's chosen at build time, it won't really 
help.

In our case, it only means users who don't use substitutes get a random number, 
others get the same number that the build farm picked at random. Fixing a 
number doesn't sound like it's gonna change a lot for these users.

>
>MaraDNS does not support DNSSEC so the program may not use entropy for
>keys. Either way, I'd rather use an unreproducible build than,
>accidentally, a known number series to encrypt secrets. Can one patch
>out the constant entirely so it is no longer available?
>
>The upstream website says: "People like MaraDNS because it’s ...
>remarkably secure." [1] Since many distributions have the same issue,
>upstream could perhaps offer the patch as a build switch to enable a
>build-time seed only when needed.

Sounds like the safest option. Maybe we could change the code that uses that 
number to naise an exception or abort?

>
>Thank you for your hard work on Guix! As a newbie I'll say, what a
>great distro. Thanks, everyone!
>
>Kind regards,
>Felix Lechner
>
>[1] https://maradns.samiam.org/
>

Re: Mummi wishlist: API using Message-ID

[Julien Lepiller]

As long as the script shows it's trying and explains why it takes time, it 
should be fine. It could offer a --continue option too :)

On June 6, 2022 2:03:16 PM GMT+02:00, Ricardo Wurmus  wrote:
>
>Arun Isaac  writes:
>
>>> Once delpoyed to issues.guix.gnu.org you can visit
>>>
>>> https://issues.guix.gnu.org/msgid/HAv_FWZRa_dCADY6U07oX-E2vTrtcxk8ltkpfvTpYCsIh4O5PuItHGIh6w-g5GGmoqVEfkjDUOplpUErdGEPAiFYdrjjDhwd9RJ4OyjjGgY=@hector.link
>>
>> This is great news! Using this, we should be able to implement a `mumi
>> send-email' command to easily send N patches to a new issue. Here is
>> how `mumi send-email' might be implemented:
>>
>> 1. Generate patches with `git format-patch --thread' so that there is a
>>Message-ID header.
>>
>> 2. Send the first patch to guix-patc...@gnu.org.
>>
>> 3. Poll https://issues.guix.gnu.org/ to see if the first
>>patch has reached Debbugs/Mumi. Find the issue number of the new
>>issue that was created.
>>
>> 4. Send the remaining patches to the new issue.
>
>This sounds like it could take quite some time, and the work it performs
>is not transactional, so an impatient person cancelling it before
>completion could end up with a bunch of “initial” emails without ever
>sending the rest of the patches.
>
>I think that maybe we should wean mumi off of debbugs and operate on
>received email directly (using debbugs as a storage backend for the time
>being).
>
>-- 
>Ricardo
>

Re: Teams

[Julien Lepiller]

If we make a team per build system, I'd be in ant, maven, ocaml and dune :)

I think there was also interest in formal methods, it could be a team.

On June 5, 2022 11:51:20 AM GMT+02:00, zimoun  wrote:
>Hi Ricardo,
>
>On Sat, 04 Jun 2022 at 14:07, Ricardo Wurmus  wrote:
>
>> As a first step I’d suggest collecting teams, setting up the email
>> aliases, and updating the website to show the existing teams.  Here’s
>> a draft of three teams:
>
>Well, a team per build system would fit more or less the needs, I
>guess.  It is not a big deal if there are some overlaps.
>
>For what is it is worth, I would suggest that people with commit access
>appear at least once in one team, if possible.
>
>
>> * R team
>> Simon Tournier
>> Ricardo Wurmus
>
>In addition, add me to:
>
>* Julia team
>
>
>Cheers,
>simon
>

Re: Donation of used Softiron Overdrive 1000

[Julien Lepiller]

I'd wait for the maintainers to say whether they are interested. If so, I'm 
happy to host the machine unless the maintainers prefer not to let me :)

Thanks for the donation offer btw!

On April 27, 2022 10:43:03 AM GMT+02:00, Reza Housseini 
 wrote:
>
>On 4/27/22 10:13, Julien Lepiller wrote:
>> I used to host one of them (or was it another kind of overdrive?). Now that 
>> I moved to a new place where I should stay for a while, I should be able 
>> host one again, if needed :)
>> 
>> My German is not too great. Does it come with disks and USB cable? What's 
>> its condition overall? Will it die after a few weeks? :D
>> 
>> On April 27, 2022 9:03:36 AM GMT+02:00, Reza Housseini 
>>  wrote:
>> 
>> Hi Guixers,
>> 
>> 
>> I'd like to donate this used machine [1] to the guix project. Is there 
>> any interest and when yes can I advice the seller to send the machine 
>> directly to the build farm hoster?
>> 
>> Thanks for the great project.
>> 
>> 
>> Kind regards,
>> 
>> Reza
>> 
>> 
>> 
>> [1]https://www.ebay-kleinanzeigen.de/s-anzeige/softiron-overdrive-1000-arm64-aarch64-developer-kit/1952849632-228-7046
>> 
>
>Hi Julien
>
>The seller said it is in excellent condition. It has an 1TB HDD included, but 
>about the cables I am not sure.
>
>Can I advice the seller to send it to you then?
>
>Cheers,
>
>Reza
>

Re: Donation of used Softiron Overdrive 1000

[Julien Lepiller]

I used to host one of them (or was it another kind of overdrive?). Now that I 
moved to a new place where I should stay for a while, I should be able host one 
again, if needed :)

My German is not too great. Does it come with disks and USB cable? What's its 
condition overall? Will it die after a few weeks? :D

On April 27, 2022 9:03:36 AM GMT+02:00, Reza Housseini 
 wrote:
>
>Hi Guixers,
>
>
>I'd like to donate this used machine [1] to the guix project. Is there any 
>interest and when yes can I advice the seller to send the machine directly to 
>the build farm hoster?
>
>Thanks for the great project.
>
>
>Kind regards,
>
>Reza
>
>
>[1] 
>https://www.ebay-kleinanzeigen.de/s-anzeige/softiron-overdrive-1000-arm64-aarch64-developer-kit/1952849632-228-7046
>

Re: What are the specs for your guix server?

[Julien Lepiller]

It's relatively small. 8 cores, 8 GB of RAM, 1 TB of disk and good bandwidth 
for 150€/year. Serving the videos just require some bandwidth, no processing. I 
don't really have numbers for that, but I would be surprised if more than two 
people downloaded videos at the same time.

On March 2, 2022 12:36:04 AM GMT+01:00, jbra...@dismail.de wrote:
>March 1, 2022 5:36 PM, "Julien Lepiller"  wrote:
>
>> Thanks, I changed the default format and published the .ass file on my 
>> server. Not sure about the
>> other files.
>
>I was pretty impressed that you were able to serve/host those videos.  How 
>powerful is your server?  May I ask how much it costs you?
>
>Thanks,
>
>Joshua
>
>> 
>> On March 1, 2022 11:08:50 PM GMT+01:00, Tanguy LE CARROUR 
>>  wrote:
>> 
>>> Hi Julien,
>>> 
>>> Quoting Julien Lepiller (2022-03-01 15:36:19)
>>> 
>>>> I'm looking for volunteers to create English subtitles for the Guix Days
>>>> talks. […] Please send me the subtitles once
>>>> they are completed, I'll add them with the videos.
>>> 
>>> It's my first time, so thank you for your indulgence! :-)
>>> 
>>> I'm attaching my humble contribution:
>>> 
>>> - `.txt` the transcription ;
>>> - `.ass` the file created by Aegisub ; and
>>> - `.sub` an attempt to export it to sub format.
>>> 
>>> I have to admit that is pretty bad "punctuation-wise", because I was not
>>> sure were the sentences started and ended. Sorry!
>>> 
>>> Just let me know if I have to fix anything.
>>> 
>>> Regards,
>>> 
>>> --
>>> Tanguy

Re: Creating subtitles for the Guix Days videos!

[Julien Lepiller]

Thanks, I changed the default format and published the .ass file on my server. 
Not sure about the other files.

On March 1, 2022 11:08:50 PM GMT+01:00, Tanguy LE CARROUR 
 wrote:
>Hi Julien,
>
>
>Quoting Julien Lepiller (2022-03-01 15:36:19)
>> I'm looking for volunteers to create English subtitles for the Guix Days
>> talks. […] Please send me the subtitles once
>> they are completed, I'll add them with the videos.
>
>It's my first time, so thank you for your indulgence! :-)
>
>I'm attaching my humble contribution:
>
>- `.txt` the transcription ;
>- `.ass` the file created by Aegisub ; and
>- `.sub` an attempt to export it to sub format.
>
>I have to admit that is pretty bad "punctuation-wise", because I was not
>sure were the sentences started and ended. Sorry!
>
>Just let me know if I have to fix anything.
>
>Regards,
>
>-- 
>Tanguy

Creating subtitles for the Guix Days videos!

[Julien Lepiller]

Hi Guix!

I'm looking for volunteers to create English subtitles for the Guix Days
talks. It would be great for people who are not very good with spoken
English but who can still understand text.

We have created a pad with the list of videos and steps to coordinate
and make sure we don't all work on the same videos. Please add you name
in front of the video you want to create subtitles for:

https://mensuel.framapad.org/p/guixdays2022-videosubtitles-9stl

You can use aegisub to create the subtitles. Note that it's a lot of
work (typically 1 hour for ~10 minutes of video), so I'd be glad for any
work you can do, even if it's partial. Please send me the subtitles once
they are completed, I'll add them with the videos.

Re: [minor patch] Amend CoC

[Julien Lepiller]

Sounds good, but isn't that included in "sexual identity" already? For 
reference, where does the author say that?

On February 20, 2022 2:02:07 PM GMT+01:00, Taylan Kammer 
 wrote:
>This is a really tiny thing.  A recent thread on the ML prompted me to
>look at our CoC and I noticed it doesn't include 'sex' in the list of
>things based on which one might be discriminated against, so attached
>is a patch that adds that one word.
>
>Note: The upstream Contributor Covenant wouldn't want to include it
>because the author seems to have a peculiar world-view where they don't
>acknowledge that humans actually have a sex.  I hope the Guix maintainers
>are more reasonable than that. :-)
>
>-- 
>Taylan

Upstreaming my Android channel

[Julien Lepiller]

Hi Guix!

I have been working on updating Android packages for some time now. I
think it's at a point I'm confident I can share and move them upstream.
My work is currently in a separate channel at
https://framagit.org/tyreunom/guix-android. I have been working on the
SDK and tools, which we already have. We currently are limited to
Android 7 versions, because later Android versions do not use the same
build system anymore.

Since then, Android uses the Soong build system, based on blueprint.
It's pretty complex, and specific. I tried to build it, but it assumes
too many things to be useful. Instead, I "reimplemented" it by
following what a Nix contributor did in soongnix:
https://github.com/danielfullmer/soongnix

I created a soong-build-system that has a few modules for cc, art and
java types of packages. It supports building most packages from the SDK
and other Android tools: aapt, appt2, adb, aidl, apksigner, dexdump,
dmtracedump, dx, etc1tool, fastboot, hprof-conv, libaapt2_jni,
split-select, zipalign.

I have an importer that is a bit different from the existing importers.
First, it needs to checkout ~30GB of git repositories (and that's with
--depth=1 for all of them!), explore the set of Android.bp files (used
by soong) and create one package for each package in these Android.bp
files. That creates packages that can be a bit smaller than expected.
Instead of printing, the importer creates two files: one for the source
definitions (many packages share the same source) and one for the
packages and their dependencies.

Since I have all of that in a channel, the importer doesn't work from
the command-line, but I have a relatively simple API that you can use
to import packages:

```
,use (android import repo)
(define manifest (get-manifest))

;; Fetch repositories that form the android distribution.
;; This is very big (> 28GB) and will take some time.  If it fails
;; because of a network issue, restart that command again until
;; everything is downloaded.
;;
;; You can also add an optional destination directory where the
;; sources are to be downloaded, e.g. on a different file-system if
;; you lack space on the file system your home directory is on.
(define root (fetch-manifest-repositories manifest))

;; Finds all Android.bp files from which to import, takes ~10s on warm
;; cache, significantly longer on cold cache and spiny disks.
(define bp-files (get-all-bp-files root))

;; Creates the shared structure: a map of modules and variables to the
;; files that define them, so we can find them, without actually parsing
;; everything.  Will take ~5mins on an HDD, could be faster on SSD.
(define bp-maps (get-bp-maps bp-files))

;; Run the import.  The last two arguments are the names of files that
;; will be generated.
(import-recursively manifest root bp-maps '("adb" "fastboot")
"sources.scm" "packages.scm")
```

That would import adb and fastboot

You can see the result of importing a bit more than that at
https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/android-tools.scm
and
https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/android-sources.scm

It's pretty great but missing a few things. These packages don't have a
home page, synopsis, description, ... and I don't see a way to easily
import that. Although I could manually add them, the work will have to
be done again at each update. Every month, Google releases a new
Android revision (not necessarily a major version) that modifies some
sources, and can impact the set of dependencies we need to build.

I was aiming at having an importer that was able to recreate all the
files with no human intervention. I think it's the only sane way to
take care of all those packages.

Currently I think all of android/build, android/build-system,
android/import, android/packages/android-{headers,tools,sources}.scm
and android/packages/{bison,clang}.scm can be upstreamed. The rest is
wip or broken packages.

Do you have any ideas how we could plan upstreaming all this?
Especially, how could the importer fit in the current Guix
infrastructure?

Thoughts?

Re: CWiid fails to build

[Julien Lepiller]

That's because we don't have ldconfig. It's useless. You should remove the call 
from the makefile or whatever the build uses.

On February 19, 2022 3:14:53 PM GMT+01:00, Tobias Platen 
 wrote:
>nearly finnished: I get a make[1]: ldconfig: No such file or directory
>error when I try to compile my package.
>

Re: CWiid fails to build

[Julien Lepiller]

Error 127 means file not found. To run autoreconf, you need to add autoconf and 
automake in the native-inputs of your package.

On February 19, 2022 12:11:17 PM GMT+01:00, Tobias Platen 
 wrote:
>Hello,
>
>I added the CWiid package to guix, and now autoconf fails when
>building. I attached the logs and the package definition.
>
>Tobias
>
>

Re: Maven Build System Dependency Issue

[Julien Lepiller]

Hi Phil,

I have already seen the issue previously, and I believe it is now fixed
on master. As you can see here,
https://github.com/guix-mirror/guix/blob/master/gnu/packages/java.scm#L7899
we now propagate the correct parent pom.

In particular, java-jmh is a much more complex package, and it builds
fine with the maven-build-system. So I suggest you to pull to the
latest master commit and enjoy :)

Don't hesitate to get back if you still have issues on master, I'll be
happy to help!

Le Tue, 8 Feb 2022 15:27:14 +, Phil Beadling 
a écrit :

> Hi Guixers,
> 
> First let me say I'm a Maven novice, so it's possible I'm doing
> something dumb on the Maven side of things.
> 
> I'm unable to make a bare-bones Maven project build in Guix.

Re: Clarifying blog post licensing

[Julien Lepiller]

On January 26, 2022 10:24:11 AM GMT+01:00, "Ludovic Courtès"  
wrote:
>Hello Guix!
>
>With a few exceptions, our blog posts do not have a license, which is
>not great as it prevents sharing and reuse, at least by those outside
>Guix circles (we discussed it in the past but never got around to fixing
>it).
>
>I’d like us to clarify that, with a footer on blog posts saying that,
>unless otherwise stated, posts are dual-licensed under CC-BY-SA 4.0 and
>GFDL 1.3+ (the latter so we can reuse material in the cookbook and in
>the manual).  Patch below.
>
>What do people think?
>
>If maintainers and everyone agrees, I’d like to publicly email all the
>authors asking them whether they agree with the proposed licensing
>terms, or whether they’d like a different free license.  The script
>below enumerates blog post authors (the list needs a bit of cleanup
>still):
>
>--8<---cut here---start->8---
>scheme@(guile-user)> ,pp authors
>$22 = ("A collective of GNU maintainers"
> "Andreas Enge"
> "Chris Marusich"
> "Chris Marusich and Léo Le Bouter"
> "Christopher Baines"
> "Christopher Lemmer Webber"
> "Danjela Lura"
> "Danny Milosavljevic"
> "David Thompson"
> "Efraim Flashner"
> "Florian Pelz"
> "Guix Hackers"
> "Gábor Boskovits"
> "Jakob L. Kreuze"
> "Jan (janneke) Nieuwenhuizen"
> "Jan Nieuwenhuizen"
> "Joshua Branson"
> "Julien Lepiller"
> "Konrad Hinsen"
> "Laura Lazzati"
> "Ludovic (civodul) Courtès"
> "Ludovic Courtès"
> "Ludovic Courtès and Leo Famulari"
> "Magali Lemes"
> "Manolis Ragkousis"
> "Marius (mbakke) Bakke"
> "Marius Bakke"
> "Mathieu Othacehe"
> "Maxim Cournoyer"
> "Pierre Neidhardt"
> "Pjotr Prins"
> "Ricardo (rekado) Wurmus"
> "Ricardo Wurmus"
> "Roel Janssen"
> "Simon Tournier"
> "Tatiana Sholokhova"
> "Tobias Geerinckx-Rice"
> "sirgazil")
>--8<---cut here---end--->8---
>
>How does that sound?
>
>Thanks,
>Ludo’.
>

I agree

Re: Language menu in the HTML manual

[Julien Lepiller]

I have only tested on mobile. The language menu is always visible and takes up 
the whole screen. We should hide the menu by default. Is that what the icon is 
supposed to do? If possible, the links should go to the same page in the other 
language, but that might be difficult.

Le 19 janvier 2022 00:53:00 GMT+01:00, "Ludovic Courtès"  a écrit 
:
>Hello Guix!
>
>I added a language menu in the on-line HTML manual that you can see in
>the top-right corner of manual pages:
>
>  https://guix.gnu.org/manual/devel/es/html_node/Empezando.html
>  https://guix.gnu.org/manual/devel/ru/guix.ru.html
>
>(CSS needs to be fixed so the menu item colors look right.)
>
>This is done with these two commits:
>
>  
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7eb883b7c284c78cc17093bfc4ef2d70e0acad83
>  
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/commit/?id=db26102d4149a3a857701add00d23bdf38e21911
>
>I think eventually we could also add explicit links to, say, report
>translation errors or other issues.
>
>Let me know what you think!
>
>Ludo’.
>

Re: Proposal: Separate the guix repo

[Julien Lepiller]

You probably want "make make-packages-go" and similar targets (maybe also 
make-cli-go).

Le 16 janvier 2022 09:30:54 GMT+01:00, Ryan Prior  a 
écrit :
>‐‐‐ Original Message ‐‐‐
>
>On Sunday, January 16th, 2022 at 4:21 AM, Jacob Hrbek  
>wrote:
>
>> Currently it's taking me 1~4 hours (depending on the system without
>>
>> outsourcing the load on high performance system) to build the guix
>>
>> repository in order to be able to test the contribution and contribute
>
>I have this issue too. Whether or not we split the repo, providing lightweight 
>makefile targets that don't build everything would be great. I don't need to 
>build all the localization stuff for every language regularly when I'm only 
>going to be testing Guix in English, and so on with lots of tools I'm not 
>necessarily testing.
>
>Ryan
>

Re: [bug#53166] [PATCH] website: Announce Guix days!

[Julien Lepiller]

Pushed with Luis Felipe's patch as
413df9b96887838ba35adf2ddf73836ad9bf6189 and
3985fd27ec85e4c2bf25fc3f3f603179721e6f61, thanks! The website should be
updated soon :)

Re: bug#53166: [PATCH] website: Announce Guix days!

[Julien Lepiller]

Attached is the new version I plan to push this evening. Last call for
comments!
From b52128768525c3a563362d218af3f79b53b96155 Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Mon, 10 Jan 2022 18:05:05 +0100
Subject: [PATCH] website: Add conference announcement.

* website/posts/online-guix-days-2022-announcement-1.md: New file.
* website/static/blog/img/Guix-Days-online-2022.png: New file.
* website/apps/base/templates/theme.scm: Add announce banner.
---
 website/apps/base/templates/theme.scm |   9 +-
 .../online-guix-days-2022-announcement-1.md   | 138 ++
 .../static/blog/img/Guix-Days-online-2022.png | Bin 0 -> 103920 bytes
 3 files changed, 146 insertions(+), 1 deletion(-)
 create mode 100644 website/posts/online-guix-days-2022-announcement-1.md
 create mode 100644 website/static/blog/img/Guix-Days-online-2022.png

diff --git a/website/apps/base/templates/theme.scm b/website/apps/base/templates/theme.scm
index 81815b6..3aa09ea 100644
--- a/website/apps/base/templates/theme.scm
+++ b/website/apps/base/templates/theme.scm
@@ -120,7 +120,14 @@
  (body
   ,(navbar #:active-item active-menu-item)
 
-  ;; NOTE: Comment this message out when it is not needed anymore.
+  ;; NOTE: Comment these messages out when they are not needed anymore.
+  (div
+   (@ (class "message-box msg-info"))
+   (p ,(G_ `("Online conference February 19-20. "
+ ,(G_ `(a
+(@ (href "/blog/2022/online-guix-days-2022-announcement-1/"))
+"Learn more"))
+ "!"
   ;(div
   ; (@ (class "message-box msg-info"))
   ; (p ,(G_ `("Online conference November 22nd. "
diff --git a/website/posts/online-guix-days-2022-announcement-1.md b/website/posts/online-guix-days-2022-announcement-1.md
new file mode 100644
index 000..150ad04
--- /dev/null
+++ b/website/posts/online-guix-days-2022-announcement-1.md
@@ -0,0 +1,138 @@
+title: Announcing the second online Guix Days
+date: 2022-01-12 00:00
+author: Guix Hackers
+slug: online-guix-days-2022-announcement-1
+tags: Conference, Community
+---
+
+The Guix hackers are very happy to announce the second online Guix Days
+Conference on **19 & 20 February 2022**.  This conference is open to everyone
+and will be held entirely online.  Want to speak?  Submit your proposal!
+
+Important dates:
+
+1. **February 8**: Deadline for talks proposal.
+1. **February 12**: Deadline for releasing your pre-recorded talks.
+1. **February 14**: Release of the schedule.
+1. **February 19**: Conference day!
+1. **February 20**: Conference day!
+
+![Guix Days logo](/static/blog/img/Guix-Days-online-2022.png)
+
+The agenda of these two days is:
+
+ - pre-recorded talks with live question and answer sessions
+ - birds of a feather (BoF) sessions
+ - lightning round talks, if possible
+ - retrospective and future of Guix
+ - hack together
+
+Talks will be released **before** the conference day, **watch them as soon
+as possible**! And: **no registration fee**.
+
+# Until February 8: talk proposals
+
+Propose your talks by sending them to `guix-d...@gnu.org`.  Feel free to drop
+in `#guix` on irc.libera.chat to discuss what you would like to talk about
+before submitting. :)
+
+You can choose one of the following formats:
+
+ - Standard talk. 15-45 minutes pre-recorded presentation and a 5 minutes lightning talk.
+   The 5-minute presentation will be live, to refresh our minds, followed by
+   a 30 minutes live Q
+ - BoF (birds of a feather, for a session with a small group who wants to talk
+   about a specific topic) with no presentation. You may prepare something live
+   to spark conversations.
+ - Lightning talk with a 5 minutes live presentation
+
+In addition to the format you would like to choose, please describe your session
+with 10 lines or more (for lightning talks, at least 1 sentence).
+
+Once you have sent your proposal, you will be notified in the coming days
+whether your talk be part of the Guix Day. Submit earlier to get more time to
+prepare your session!
+
+Even for live presentation, please prepare a back-up pre-recorded talk, so
+we can play it if you cannot attend or have a technical problem during the
+Guix days. The deadline for short presentations (5 minutes) is February 16.
+
+We welcome all kinds of topics from the community, especially your own experience
+with Guix, your cool projects that involve Guix in some way, infrastructure around
+guix (translations, continuous integration, ...), and any subject you feel
+should be discussed during the conference.
+
+We particularly encourage people who consider themselves part of a group
+underrepresented in Guix and the broader free software movement to submit
+a talk. Do not hesitate to get in touch with the organizers at `guix-d...@gnu.org`
+if unsure or if you would like guidance on how to prepare your talk.
+
+Pl

Re: bug#53166: [PATCH] website: Announce Guix days!

[Julien Lepiller]

Great, I added all of that, thanks!

Le 12 janvier 2022 12:58:03 GMT+01:00, "Ludovic Courtès"  a écrit 
:
>Hi again!
>
>Julien Lepiller  skribis:
>
>> +# Until February 8: talks proposal
>> +
>> +Propose your talks by sending them to `guix-d...@gnu.org`.  Feel free to 
>> drop
>> +in `#guix` on irc.freenode.net to discuss what you would like to talk about
>
>Should be irc.libera.chat.
>
>A couple of ideas occurred to me while biking this morning:
>
>> +We welcome all kinds of topics from the community, especially your own 
>> experience
>> +with Guix, your cool projects that involve Guix in some way, infrastructure 
>> around
>> +guix (translations, continuous integration, ...), and any subject you feel
>> +should be discussed during the conference.
>
>What about adding something like:
>
>  We particularly encourage people who consider themselves part of a
>  group underrepresented in Guix and the broader free software movement
>  to submit a talk; do not hesitate to get in touch with the organizers
>  at `guix-d...@gnu.org` if unsure or if you would like guidance on how
>  to prepare your talk.
>
>  Please make sure your talk is accessible to a non-expert audience, for
>  instance by explaining the general context before diving into
>  technical descriptions, and by avoiding acronyms and jargon.
>
>?
>
>After the first sentence above, I also thought about that one:
>
>  We accept talks in languages other than English provided English
>  subtitles are included.
>
>Thoughts?
>
>Ludo’.

Re: [PATCH] website: Announce Guix days!

[Julien Lepiller]

There shouldn't be a need for the language tag at all, because the server uses 
the user's language in that case. I'll fix the url and irc link. I'd love to 
get the correct png, thanks!

Le 10 janvier 2022 20:52:10 GMT+01:00, Luis Felipe 
 a écrit :
>Hi, Julien.
>
>On Monday, January 10th, 2022 at 5:16 PM, Julien Lepiller jul...@lepiller.eu 
>wrote:
>
>> Attached is the full patch, with the blog post, banner and logo. I'll
>> 
>
>> push on Wednesday if there is no answer.
>
>I tried the patch locally and found some issues:
>
>The link from the banner to the blog post fails:
>
>#+begin_src
>(div
> (@ (class "message-box msg-info"))
> (p ,(G_ `("Online conference February 19-20. "
>   ,(G_ `(a
>  (@ (href "/blog/2020/online-guix-days-2022-announce-1/"))
>  "Learn more"))
>   "!"
>#+end_src
>
>I think the correct URL path should be:
>
>/en/blog/2022/online-guix-days-2022-announce-1/
>
>That is, with language tag and year 2022.
>
>In the blog post, I see that:
>
>1. Part of the text in the image looks jagged. I can patch the source SVG 
>later to fix that, and send you an updated PNG.
>2. IRC information is referring to irc.freenode.net instead of libera.
>3. Link to the last conference fails. It reads:
>
>[the last conference](/blog/2020/online-guix-day-announce-1/)
>
>I think the correct path should be:
>
>/en/blog/2020/online-guix-day-announce-1/

Re: [PATCH] website: Announce Guix days!

[Julien Lepiller]

The variant is wonderful! I'll use that in the announcement. Thanks!

Le 10 janvier 2022 23:44:26 GMT+01:00, Luis Felipe 
 a écrit :
>I'm attaching a patch that fixes the jagged text in the source SVG and adds a 
>variant of the poster. And here are PNGs from each of them:
>
>Original (fixed text):
>https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-online-2022.png
>
>Variant:
>https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-2022-Variant.png
>
>
>
>
>

Re: [PATCH] website: Announce Guix days!

[Julien Lepiller]

Thanks, I like this better. Can you send a patch for it?

Le 11 janvier 2022 01:47:02 GMT+01:00, Luis Felipe 
 a écrit :
>On Monday, January 10th, 2022 at 10:44 PM, Luis Felipe 
> wrote:
>
>> I'm attaching a patch that fixes the jagged text in the source SVG and adds 
>> a variant of the poster. And here are PNGs from each of them:
>> 
>
>> Original (fixed text):
>> 
>
>> https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-online-2022.png
>> 
>
>> Variant:
>> 
>
>> https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-2022-Variant.png
>
>Actually, since those little i-shaped things below the GuixDays text are 
>supposed to represent people, not i(s), I think this version might be better:
>
>https://luis-felipe.gitlab.io/media/2022/01/Guix-Days-2022-Variant-B.png
>
>If you'd like to use this one for the post, I can send a new patch later.

[PATCH] website: Announce Guix days!

[Julien Lepiller]

Le Thu, 06 Jan 2022 20:54:29 +0100,
zimoun  a écrit :

> Hi Julien,
> 
> On Sat, 11 Dec 2021 at 02:37, Julien Lepiller 
> wrote:
> 
> > I suggest that we have these days right after Fosdem, Monday and
> > Tuesday. This should give us just a few more days to prepare, as I
> > think we're starting pretty late already. If you prefer to have
> > them before fosdem, I can change the blog post of course.  
> 
> What is the final decision?  No strong opinion on the date, so let
> pick the ones your proposed.  How does it sound?
> 

Sorry that I haven't been working on that before. Since we're already
this late, I suggest to postpone the guix days and have them two weeks
later. this should give us enough time to rest from Fosdem madness and
prepare :)

Attached is the full patch, with the blog post, banner and logo. I'll
push on Wednesday if there is no answer. Could one of our maintainers
resurrect the old guix-days email alias? It would contain the
maintainers, me and Simon for now. Anyone else interested?

> 
> > Also, we need to secure a BBB instance :)  
> 
> Well, I think we will find one.  Fosshost is not an option though.
> 
> 
> Cheers,
> simon

>From b1ed3af5838b65293441f62e5d6447357be849b4 Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Mon, 10 Jan 2022 18:05:05 +0100
Subject: [PATCH] website: Add conference announcement.

* website/posts/online-guix-days-2022-announce-1.md: New file.
* website/static/blog/img/Guix-Days-online-2022.png: New file.
* website/apps/base/templates/theme.scm: Add announce banner.
---
 website/apps/base/templates/theme.scm |   9 +-
 .../posts/online-guix-days-2022-announce-1.md | 126 ++
 .../static/blog/img/Guix-Days-online-2022.png | Bin 0 -> 25862 bytes
 3 files changed, 134 insertions(+), 1 deletion(-)
 create mode 100644 website/posts/online-guix-days-2022-announce-1.md
 create mode 100644 website/static/blog/img/Guix-Days-online-2022.png

diff --git a/website/apps/base/templates/theme.scm b/website/apps/base/templates/theme.scm
index 81815b6..8fe188c 100644
--- a/website/apps/base/templates/theme.scm
+++ b/website/apps/base/templates/theme.scm
@@ -120,7 +120,14 @@
  (body
   ,(navbar #:active-item active-menu-item)
 
-  ;; NOTE: Comment this message out when it is not needed anymore.
+  ;; NOTE: Comment these messages out when they are not needed anymore.
+  (div
+   (@ (class "message-box msg-info"))
+   (p ,(G_ `("Online conference February 19-20. "
+ ,(G_ `(a
+(@ (href "/blog/2020/online-guix-days-2022-announce-1/"))
+"Learn more"))
+ "!"
   ;(div
   ; (@ (class "message-box msg-info"))
   ; (p ,(G_ `("Online conference November 22nd. "
diff --git a/website/posts/online-guix-days-2022-announce-1.md b/website/posts/online-guix-days-2022-announce-1.md
new file mode 100644
index 000..4e5c512
--- /dev/null
+++ b/website/posts/online-guix-days-2022-announce-1.md
@@ -0,0 +1,126 @@
+title: Announcing the second online Guix Days Conference
+date: 2022-01-10 00:00
+author: Guix Hackers
+slug: online-guix-days-2022-announce-1
+tags: Conference, Community
+---
+
+The Guix hackers are very happy to announce the second online Guix Days
+Conference on **19 & 20 February 2022**.  This conference is open to everyone
+and will be held entirely online.  Want to speak?  Submit your proposal!
+
+Important dates:
+
+1. **February 8**: Deadline for talks proposal.
+1. **February 12**: Deadline for releasing your pre-recorded talks.
+1. **February 14**: Release of the schedule.
+1. **February 19**: Conference day!
+1. **February 20**: Conference day!
+
+![Guix Days logo](/static/blog/img/Guix-Days-online-2022.png)
+
+The agenda of these two days is:
+
+ - pre-recorded talks with live question and answer sessions
+ - birds of a feather (BoF) sessions
+ - lightning round talks, if possible
+ - retrospective and future of Guix
+ - hack together
+
+Talks will be released **before** the conference day, **watch them as soon
+as possible**! And **no registration fee**.
+
+# Until February 8: talks proposal
+
+Propose your talks by sending them to `guix-d...@gnu.org`.  Feel free to drop
+in `#guix` on irc.freenode.net to discuss what you would like to talk about
+before submitting. :)
+
+You can choose one of the following formats:
+
+ - Standard talk. 15-45 minutes pre-recorded presentation and a 5 minutes lightning talk.
+   The 5-minute presentation will be live, to refresh our minds, followed by
+   a 30 minutes live Q
+ - BoF (birds of a feather, for a session with a small group who wants to talk
+   about a specific topic) with no presentation. You may prepare something live
+   to spark conversations.
+ - Lightning talk with a 5 minutes live presentation
+
+In addition to t

Re: Guix Documentation Meetup

[Julien Lepiller]

Le 8 janvier 2022 14:41:53 GMT+01:00, Matt  a écrit :
>
> > I would like for Guix to host a community wiki
>
>Agreed. 
>
>Ironically, Guix already has two of them.
>
>1. goto gnu.guix.org
>2. Select wiki from the help menu
>3. Discover that linked wiki is not a community wiki
>4. Click the (supposed) community wiki: 
>https://guix.miraheze.org/wiki/Main_Page
>
>Is this the "official" Guix wiki? 
>If so, why is it not a direct link from the home page.
>Who hosts it? If I spend hours writing something, is it just going to 
>disappear some day?
>

Someone was frustrated there was no wiki, so they started that, but it's not 
official at all. Miraheze hosts other wikis, like the bootstrappable wiki, I 
think it's ok, but if we had a wiki, it should rather be hosted on gnu or guix 
infrastructure.

Organising Guix Days

[Julien Lepiller]

Hi Guix!

I think it's time to start organising the Guix Days, traditionally held
around Fosdem.

During our guix-europe assembly, we discussed some options and everyone
agreed they wanted a two-day event, online just as Fosdem. I attached a
proposed blog post that we should put on the website as soon as we
agree on the first details.

I suggest that we have these days right after Fosdem, Monday and
Tuesday. This should give us just a few more days to prepare, as I think
we're starting pretty late already. If you prefer to have them before
fosdem, I can change the blog post of course.

As for how it'll be organised. I propose to do something similar to
what we need in November 2020. I'd love to get some talks from people
outside the usual maintainers and commiters, to have an overview of the
diversity of people and usage around Guix.

Last year, we asked speakers to prepare a video in advance, and they
would only have an extended Q/discussion session. I think this year
we should have the same process, but ask for a short (3-5 minutes) talk
at the start of the session to refresh our minds on the main points of
the presentation before discussions start.

Of course, one of our co-maintainers should have a session on a
retrospective (what happened last year in Guix) and lead discussions on
the future of Guix. We should reserve plenty of time for this session.

In addition, I'd like to invite people to submit discussion ideas and
be free of having to make a presentation if they prefer (BoF). I'd also
like to "innovate" and have a session of lightning talks, where people
would only have to give a short, live presentation on any topic related
to Guix (I'm thinking short presentation of a project where you use
guix, of something you're doing with guix, how you found guix, a story
of your first days with guix, ...). We can also replace that with a
presentation round at the beginning of the conference if we don't have
enough lightning talks.

The Guix Days have never been a "real" conference, and always had a lot
of room for discussions that start on the spot. I'd like to emulate
this by keeping a lot of time out of the talk sessions to discuss
whatever comes up naturally during our discussions.

Also, we need to secure a BBB instance :)

WDYT?
title: Announcing the second online Guix Days Conference
date: 2021-12-10 00:00
author: Guix Hackers
slug: online-guix-days-2022-announce-1
tags: Conference, Community
---

The Guix hackers are very happy to announce the second online Guix Days
Conference on **7 & 8 February 2022**.  This conference is open to everyone
and will be held entirely online.  Want to speak?  Submit your proposal!

Important dates:

1. **January 21**: Deadline for talks proposal.
1. **January 28**: Deadline for releasing your pre-recorded talks.
1. **February 2**: Release of the schedule.
1. **February 7**: Conference day!
1. **February 8**: Conference day!

![Guix Days logo](/static/blog/img/Guix-Days-online-2022.png)

The agenda of these two days is:

 - pre-recorded talks with live question and answer sessions
 - birds of a feather (BoF) sessions
 - lightning round talks, if possible
 - retrospective and future of Guix
 - hack together

Talks will be released **before** the conference day, **watch them as soon
as possible**! And **no registration fee**.

# Until January 21: talks proposal

Propose your talks by sending them to `guix-d...@gnu.org`.  Feel free to drop
in `#guix` on irc.freenode.net to discuss what you would like to talk about
before submitting. :)

You can choose one of the following formats:

 - Standard talk. 15-45 minutes pre-recorded presentation and a 5 minutes lightning talk.
   The 5-minute presentation will be live, to refresh our minds, followed by
   a 30 minutes live Q
 - BoF (birds of a feather, for a session with a small group who wants to talk
   about a specific topic) with no presentation. You may prepare something live
   to spark conversations.
 - Lightning talk with a 5 minutes live presentation

In addition to the format you would like to choose, please describe your session
with 10 lines or more (for lightning talks, at least 1 sentence).

Once you have sent your proposal, you will be notified in the coming days
whether your talk be part of the Guix Day. Submit earlier to get more time to
prepare your session!

Even for live presentation, please prepare a back-up pre-recorded talk, so
we can play it if you cannot attend or have a technical problem during the
Guix days. The deadline for short presentations (5 minutes) is February 4.

We welcome all kinds of topics from the community, especially your own experience
with Guix, your cool projects that involve Guix in some way, infrastructure around
guix (translations, continuous integration, ...), and any subject you feel
should be discussed during the conference.

Have a look at the topics from [the last conference](/blog/2020/online-guix-day-announce-1/)
for ideas, but don't hesitate to innovate in your 

Re: Proposal: Build timers

[Julien Lepiller]

Do we even care that much about accuracy? I don't really care that the build 
takes 30 or 31 seconds, or even 1 minute, but I certainly care whether it takes 
30s or 3h. I think this is also what SBUs give you: a rough estimate of which 
build is longer than the other. I think a simple proportionality relation would 
work well enough in most common cases. It might be quite off on a super 
computer, but who cares, really?

Le 23 novembre 2021 16:35:24 GMT-05:00, Jacob Hrbek  a 
écrit :
>Skimming through the research that lily provided our builds are reproducible 
>so the changes in cpu cycles requirements should be same with any post-build 
>implementation disabled, but i recognize that different CPUs might use 
>different configuration that influences the calculation and it will be a 
>complicated task to account for all variables that influence the build across 
>systems so instead of accurate measurements we should work with a sane 
>tolerance for accuracy.
>
>-- Jacob "Kreyren" Hrbek
>
>Sent with ProtonMail Secure Email.
>
>‐‐‐ Original Message ‐‐‐
>
>On Tuesday, November 23rd, 2021 at 8:09 PM, Liliana Marie Prikler 
> wrote:
>
>> Am Montag, den 22.11.2021, 22:02 + schrieb Jacob Hrbek:
>> 
>
>> > See the proposal in https://git.dotya.ml/guix.next/GUIX.next/issues/5
>> > 
>
>> > -- Jacob "Kreyren" Hrbek
>> > 
>
>> > Sent with ProtonMail Secure Email.
>> 
>
>> Your Pokémon analogy is extremely flawed. The same CPU at a different
>> 
>
>> clockrate does not perform the same task in the same amount of cycles
>> 
>
>> [1, 2].
>> 
>
>> [1] Kotla, Ramakrishna & Devgan, Anirudh & Ghiasi, Soraya & Keller, Tom
>> 
>
>> & Rawson, Freeman. (2004). Characterizing the impact of different
>> 
>
>> memory-intensity levels. 3 - 10. 10.1109/WWC.2004.1437388.
>> 
>
>> [2] Snowdon, David & Sueur, Etienne & Petters, Stefan & Heiser, Gernot.
>> 
>
>> (2009). Koala a platform for OS-level power management. Proceedings of
>> 
>
>> the 4th ACM European Conference on Computer Systems, EuroSys'09. 289-
>> 
>
>> 302. 10.1145/1519065.1519097.

Re: Proposal: Build timers

[Julien Lepiller]

Le 23 novembre 2021 01:21:06 GMT-05:00, Jacob Hrbek  a 
écrit :
>I think you are overcomplicating the implementation.. What I am proposing is 
>to store the time value before and after the build and then log the 
>subtraction of these two values per package (or even per package's phase).
>
>For storage it can be either/both:
>1. locally: Storing the value somewhere on the system and adding up to it each 
>build to provide more accurate average.
>
>**optionally** This local database can be shared across multiple systems that 
>add values to it like simple listener waiting for POST requests.

We already log time on cuirass, but we don't use this information at all. If 
you could provide some wip code to show how you would implement the feature 
with this info, that would be great for this discussion.

For jocal logs, there is the store database (in /var/guix) for instance, though 
running the gc will also erase the info along with the store item.

>- within the guix repo: Since we are already building the package we can take 
>the time and then do the provided math in reverse to calculate the time:
>
>Build took 100 sec on system with 8 threads at 2.4 Ghz max cpu frequency:
>
>100 * (2.4 * 8) = 1920 (build time value per one thread at 1 Ghz)
>
>Building the package on system with 2 threads at 2.4 Ghz max cpu frequency:
>
>1920 / (2 * 2.4) = 400
>
>We can then assume that the build will take 1920/400=4.8 -> 4.8 times 
> longer on this system.

LFS has a notion of a Standard Build Unit (SBU), that is the build time of a 
particular package on your machine. Each package build time is estimated in 
SBU. However, they do not take threads into account, because the relation is 
not exactly proportional (some parts are linear, there is some overhead, …). 
SBUs change quite often with versions, so I don't think averaging on different 
versions/derivations would make a lot of sense… But I suppose this info could 
help determine how long it should take to build the same derivation or a 
similar one.

Re: Time for a request-for-comments process?

[Julien Lepiller]

Le 9 novembre 2021 13:01:46 GMT-05:00, zimoun  a 
écrit :
>Hi Ludo,
>
>On Tue, 09 Nov 2021 at 17:52, Ludovic Courtès  wrote:
>> zimoun  skribis:
>
>>> However, as I said elsewhere, this effort should start be collecting
>>> what do we consider as changes requiring formal process?
>>
>> Agreed, that’s what I meant above.
>
>I meant, based on changed already merged.  For instance, on the top of
>my head, some changes that *I* consider requiring a RFC:
>
> - new inputs style
> - guix shell
> - authentication
> - GUIX_EXTENSIONS_PATH (not finished and not documented)
>
>And it would be nice if we could come with a list of such changes.  It
>would help for finding patterns – if they are :-) – for examples,
>numbers of people involved in the discussion, time between each reply,
>structure of the cover letters, etc.
>
>
>> I don’t have an answer, but I think we should look at what others are
>> doing, what criteria they use, etc.  The Nix RFC process is probably the
>> closest match in terms of application domain, but maybe others are
>> closer to the way we practice decision-making in Guix.
>
>Yeah, for sure, several items need definitions. ;-)
>
> - which kind of change requires a RFC?

At the very least those changes we thought were important enough to add them to 
the news entries.

> - what is the process?
> - how to decide?  Accept or reject?

I think the process could allow for some time to discuss various options and 
arrive at a concensus. The final implementation might be different from the 
initial idea.

I suppose this is where we have to look at other project's processes :)

> - who decide?
> - etc.
>
>
>Cheers,
>simon
>

Re: Request to use GNU guix reproducibility bugs data for research project | University of Waterloo

[Julien Lepiller]

The guix data service also has some info on reproducibility. See 
data.guix.gnu.org
(Select master, the latest processed revision, and add /package-reproducibility 
to the URL). This page compares between berlin and bordeaux.

There are a lot of unknowns because the build farms haven't both built some of 
the packages, so we can't compare, but of those tgat have been built on both 
sites, we can already observe some interesting differences.

Le 2 novembre 2021 08:01:51 GMT-04:00, zimoun  a 
écrit :
>Hi,
>
>
>On Fri, 29 Oct 2021 at 16:48, Muhammad Hassan  
>wrote:
>
>> I would like to scrap reproducibility bugs data from the linked
>> website to use in my research project that is being conducted at the
>> University of Waterloo. I am a Master's student.
>
>Nice!  Thank for your interest to Guix.
>
>
>> The project aims to provide automated support for non-reproducibility
>> detection.
>
>Non-reproducibility can be large. Against which one are you working?
>
>
>> Please tell me if there is an API that I can use to scrap the data.
>
>For instance, “guix build --no-substitutes” followed by “guix build
>--check” allows you to locally build and rebuild for checking if the
>build is reproducible – bitwise speaking.  Then, “guix challenge” allows
>to check your local builds against the build-farm.  Note that two
>build-farms are available [1,2] for various architectures.
>
>The Guix project runs a Data Service to collect various data. This
>service serves a JSON API (not-really documented but roaming on IRC
>#guix helps ;-)).  One year ago (already, damned!), a tiny and drafty
>script to somehow get the reproducibility coverage was around [3].  I
>have not worked on it since then and I do not know if it still works.
>Perhaps, it might be an entry-point for working on reproducibility data
>from Guix.
>
>Feel free to ask more details.
>
>
>1: 
>2: 
>3: 
>
>
>Hope that helps,
>simon
>
>PS: I close the issue since it is not one, IIUC.  Instead, let redirect
>to the mailing list guix-devel which seems a better place for discussing
>such request. :-)
>
>

Re: Accuracy of importers?

[Julien Lepiller]

Le 28 octobre 2021 03:02:27 GMT-04:00, "Ludovic Courtès" 
 a écrit :
>Hello Guix!
>
>As I’m preparing my PackagingCon talk and wondering how language package
>managers could make our lives easier, I thought it’d be interesting to
>know how well our importers are doing.
>
>My understanding is that most of them require manual intervention—i.e.,
>one has to tweak what ‘guix import’ produces, even if we ignore
>synopsis/description/license, to set the right inputs, etc.  If we were
>to estimate the fraction of imported packages for which manual changes
>are needed, what would it look like?
>
>   importer fraction of imported packages needing changes
>
>   gnu  90% (doesn’t know about dependencies)
>   pypi 50% (some miss source distro, “sdist”; some have
> non-Python deps)
>   cpan ?
>   hackage  ?
>   stackage (Lars?)
>   egg  (Xinglu?)
>   elpa (Nicolas?)
>   gem  ?
>   go   (Sarah? Leo? Raghav?)
>   cran 5% (Ricardo? Simon? seems to almost always work?)
>   crate10% (Efraim?)
>   texlive  (Ricardo? Thiago? Marius?)
>   opam (Julien?)

I find it pretty good, when importing huge numbers of packages recently, I was 
able to build all of them without modification. However, lots rely on a github 
tarball, so I would change the source in these cases before sending them to 
guix.

>   minetest (Maxime? Vivien?)
>   julia (WIP)  (Simon?)
>   npm (WIP)(Jelle? Timothy?)
>
>(Lower is better.)  What would be your estimate?  
>
>Among those, which importers provide source that differs from what you’d
>get from upstream’s checkout or release tarballs?  My guess:
>
>   pypi (see LastPyMile paper)
>   elpa (gives hosted tarballs that can differ from upstream repo)
>   gem (similar to PyPI)
>   npm (ditto)
>
>What about licensing info: which ones provide accurate licensing info?
>My guess:
>
>   gnu
>   pypi
>   cpan
>   cran
>   elpa
>   go (?)
>   cran
>   crate (?)
>   texlive
>   opam (?)
>   minetest (?)
>
>TIA! :-)
>
>Ludo’.
>

Re: --with-source version not honored?

[Julien Lepiller]

I think your incantation is incorrect: you build foobar@9.0.1, and you replace 
the source of foobar@9.5.0 only.

For the rest of your question, I think there is actually no way to fix that: 
when you use ",version", it gets evaluated before you can import the package. 
Maybe (package-version this-package) would work?

Le 20 octobre 2021 05:18:02 GMT-04:00, Phil Beadling  a 
écrit :
>Hi all,
>
>I'm using the following incantation:
>
>guix build
>--with-source=foobar@9.5.0=/opt/thirdparty/foobar/foobar950_beta/linux64
><--with-source=gurobipy@9.5.0=/opt/thirdparty/gurobi/gurobi950_beta/linux64>
>foobar
>
>
>However the package build is failing with:
>
>(copy-file "lib/libfoobar.so.9.0.1" "/gnu/store/gkawzac…")
>
>In procedure copy-file: No such file or directory
>
>
>That is the new version number 9.5.0 is not written to every place when
>transforming the original package (version 9.0.1).  I think only the
>package-version is updated, but the other package components are not then
>regenerated, meaning that if they use the package-version as an input we
>get a disjoint package.
>
>In the example above I use version like so:
>
>
>
>
>
>
>*(add-after 'install 'install-foobar-library
>  (lambda* (#:key outputs #:allow-other-keys)
>  (let* ((dir (string-append (assoc-ref outputs "out")
>
>"/lib/python3.8/site-packages/foobar/"))
> (lib-to-install (string-append
>"libfoobar.so." ,version))*
>
>But ",version" is not updated, nor is it updated if I change this to call
>(package-version foobar).
>
>
>If I drop into Guile I can see this a bit more clearly by writing a
>manifest - the code below gives exactly the same error however when the
>package-version is displayed it correctly responds with 9.5.0.
>
>Not sure if this should be considered a bug, or if there is a lazy way of
>evaluating version so avoid the problem - I think it's unexpected from a
>practicioners point of view as packages end up inconsistent.
>
>I presume I can manually replace the arguments section of the package in
>the manifest to workaround this - is there a standard way of doing this?
>
>Any ideas or clarifications welcome!
>
>Cheers,
>Phil.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>*(use-modules (guix transformations) (guix packages))(define
>transform  ;; The package transformation procedure.
>(options->transformation   '((with-source .
>"gurobipy@9.5.0=/opt/thirdparty/foobar/foobar950_beta/linux64"(define
>my-package (transform (specification->package "foobar")))(display
>(package-version my-package)) ;; this will display version
>9.5.0(newline)(packages->manifest (list my-package)) ;; building this will
>fail because copy-file still looks for 9.0.1*