Re: How would you feel about this derivative logo for Nonguix?
Hi Felipe, On Wed, Mar 06 2024, Luis Felipe wrote: > That page also mentions the reasoning behind the derivative logo. Absolutely gorgeous! I like A1, although in a fit of disrespect I might have placed the horns upside down like a scorpion... Great work. The project is very lucky to have you! Kind regards Felix P.S. Please do not use Nonguix if you can avoid it.
Patch review session tomorrow (Thursday 7th March)
Hi, A reminder that the first patch review session is happening tomorrow, Thursday 7th March. Who knows how many people will be there, or what level of experience everyone will have. We'll be learning what works as we try out these sessions. Hopefully, Andreas Enge with his 'committer' hat on will be able to talk about how he reviews patches. I'm hoping we'll have some other experienced developers who will also be able to add their tips and tricks. If possible we'll break into groups - or just one big group - and everyone will start learning and doing reviews! I've added a series of steps to do a review using plain CLI tools: https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024 For those that use Emacs, there is information in the manual or please add to the Wiki page. You can register (on Meetup) through the Patch review page: If you would just like to come along, it will be on this link: https://meet.jit.si/london-guix-meetup According to my current understanding of timezones it will be at: 18:00 UTC, 18:00 GMT (London), 19:00 CET (Paris), 13:00 EST (New York) See you there! Steve / Futurile
Re: doc: Removing much of Binary Installation (was: Feedback of the GNU Guix manual)
On 2024-03-06, pelzflorian (Florian Pelz) wrote: > I don’t feel qualified to judge, but is this the preference? Arch wiki > advises against the Arch AUR package: “Therefore, after updating Guix > once, the AUR advantage really turns into a disadvantage, as there will > be many unnecessary files in the /usr file tree that are part of the > Guix AUR package but that are never used by Guix anymore. Therefore, > consider using the manual installation.” [0] > > The reason of existence for these distribution packages is probably > similar to the reason why the Binary Installation section exists. Indeed, after the first guix pull, most of the packaged files are no longer used. As the one who packaged and maintains guix in Debian, my main motivation was and is to have a trust path from debian; mainly not having to manually verify the signatures of the manual installation method (I would hazard to guess that the percentage of people who actually do manually verify signatures is disturbingly small). The guix-daemon should continue to work from the packaged version, although as guix develops more and more features; how long an old version can be expected to continue to work remains an open question. I cannot say I have done a *great* job at maintaining guix in Debian, but hopefully at least a passable job. Although there are some annoying things that probably need to be fixed: https://bugs.debian.org/1064748 a.k.a. https://issues.guix.gnu.org/69518 ... or backported to Debian stable: https://bugs.debian.org/1036304 https://bugs.debian.org/1038916 I have found a fair number of issues (especially typos!) to fix in upstream guix as a result of packaging it for Debian, so if nothing else, it is some quality assurance! :) live well, vagrant signature.asc Description: PGP signature
Re: doc: Removing much of Binary Installation
Suhail Singh writes: > FWIW, as an openSUSE Tumbleweed user, I believe Tumbleweed users who > don't care if there is an easy way to uninstall Guix would be better > served by using =guix-install.sh= as opposed to =zypper=. Btw, for completeness, on Tumbleweed, the user needs to take some additional steps to ensure that restoring a previous Tumbleweed snapshot doesn't revert Guix state. Unless I'm misremembering, these steps are needed regardless of whether =zypper= or =guix-install.sh= was used to install Guix. -- Suhail
Re: doc: Removing much of Binary Installation
Matt writes: > I wonder if we should have similar concerns about the Debian and > openSUSE packages? FWIW, as an openSUSE Tumbleweed user, I believe Tumbleweed users who don't care if there is an easy way to uninstall Guix would be better served by using =guix-install.sh= as opposed to =zypper=. The issues of "unnecessary files" applies to Tumbleweed as well (and I believe the same would be true for Debian as well). In addition, the manpages can get out of sync. The reason for the latter is that doing =sudo -i guix pull --fallback= doesn't generate manpages. However, the version of Guix installed via =zypper= does install manpages (presumably generated via =help2man=). As such, after updating Guix, running something like =man guix= results in outdated manpage being shown. If Guix installation is done via =guix-install.sh=, no manpage is shown which, in my opinion, is the lesser evil. On a related note, it would help if Guix would install manpages in addition to infopages. Not sure if this omission constitutes a bug or a missing feature. -- Suhail
Re: doc: Removing much of Binary Installation (was: Feedback of the GNU Guix manual)
On Wed, 06 Mar 2024 18:15:05 +0100 pelzflorian (Florian Pelz) wrote ---
> Thank you Matt for the suggested diff.
Thank you for taking the time to review it!
> > - Places directions for 'guix-install.sh' after directions to use
> > distribution-specific package managers, giving preference to those simpler
> > install processes over the more manual 'guix-install.sh' process
>
> I don’t feel qualified to judge, but is this the preference? Arch wiki
> advises against the Arch AUR package: “Therefore, after updating Guix once,
> the AUR advantage really turns into a disadvantage, as there will be many
> unnecessary files in the /usr file tree that are part of the Guix AUR
> package but that are never used by Guix anymore. Therefore, consider using
> the manual installation.” [0]
>
> [0] https://wiki.archlinux.org/title/Guix
Good question, I wondered about this after I submitted.
The current manual has instructions for using the Debian, Ubuntu, and openSUSE
package managers. These instructions are given after the recommendation for
=guix-install.sh= along with the transition:
"If you’re running Debian or a derivative such as Ubuntu, you can instead
install the package..."
"Instead" means "in place of something previously mentioned." So, as written,
installing with =guix-install.sh= and installing with those specific package
managers have equal levels of recommendation.
Since users of foreign systems are likely familiar with the corresponding
foreign package managers, in addition to their use being one step versus four,
I vote that they appear first.
This is good information about the situation with Arch. Maybe this is why Arch
isn't mentioned?
I wonder if we should have similar concerns about the Debian and openSUSE
packages?
> The reason of existence for these distribution packages is probably similar
> to the reason why the Binary Installation section exists.
>
> As for the suggested diff where much of Binary Installation gets removed,
>
> > -@item
> > -@cindex substitutes, authorization thereof
> > -To use substitutes from @code{@value{SUBSTITUTE-SERVER-1}},
> > -@code{@value{SUBSTITUTE-SERVER-2}} or a mirror (@pxref{Substitutes}),
> > -authorize them:
> > -
> > -@example
> > -# guix archive --authorize < \
> > - ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER-1}.pub
> > -# guix archive --authorize < \
> > - ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER-2}.pub
> > -@end example
> > -
> > -@quotation Note
> > -If you do not enable substitutes, Guix will end up building
> > -@emph{everything} from source on your machine, making each installation
> > -and upgrade very expensive. @xref{On Trusting Binaries}, for a
> > -discussion of reasons why one might want do disable substitutes.
> > -@end quotation
>
> I disagree with this chunk. This must stay. Not enabling substitutes is an
> option in guix-install.sh and the Guix System installer. Users might want
> to enable substitutes later on.
Excellent point.
I have updated the patch with the following:
- Add commas in appropriate places; after "For...Ubuntu-based systems",
"Likewise", and the 'or' within the list of substitutes
- Remove ')' from after 'guix pull'
- Clarify that 'guix-install.sh' guides users through the steps. Previously,
it was unclear if the script ran without user input.
- Add the substitute server setup with the following changes:
+ Make explicit that the default for binary installations is to build
everything
+ Change "for a discussion of reasons why one might want do disable
substitutes" (note the 'do' typo) to "for a discussion why this is the
default". This aims to state it positively and encourage people to consider
the reasons.
- Emphasize that the substitute authorization code is an example and may need
modification
v02-refactor-binary-installation-section.diff
Description: Binary data
Re: How would you feel about this derivative logo for Nonguix?
On Wednesday, March 6th, 2024 at 11:37 AM, Luis Felipe wrote: > > > Hi, > > Nonguix would like to have a logo [...] I couldn't help it and suggested to > reuse the GNU Guix logo I like this. There's a clear visual continuity, but with warnings and (in options B-D) part of the Guix horns covered up as well, emphasizing the "non." I had read rms's "install fest devil" idea and immediately thought of it when I saw your options, even without making the connection that the red line was a tail (I thought it was an arrow pointing left?) - it might be an obscure reference to many but I think your execution was spot on in that regard. Not that my say-so carries any weight, but one thumbs up from me. Cheers, Ryan
How would you feel about this derivative logo for Nonguix?
Hi, Nonguix would like to have a logo. @jonsger contacted me asking if I'd be interested in helping them with that, based on logo ideas from the community. I don't use nonguix myself, so I thought I wouldn't have the motivation to design a logo. But I couldn't help it and suggested to reuse the GNU Guix logo (which is a free cultural work after all) and proposed the following designs: https://gitlab.com/nonguix/nonguix/-/issues/317 That page also mentions the reasoning behind the derivative logo. I don't see any issue if Nonguix uses such a logo (specially variant D2), but what do you think about it? They don't want to upset the GNU Guix community. Cheers, -- Luis Felipe López Acevedo https://luis-felipe.gitlab.io/ OpenPGP_0x0AB0D067012F08C3.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Emacs and tree-sitter grammars
All versions of Emacs except emacs-minimal are built with tree-sitter support. But no grammar is added to propagated-inputs. Emacs version 29.1 ships with the following major modes: typescript-ts-mode c-ts-mode c++-ts-mode java-ts-mode python-ts-mode css-ts-mode json-ts-mode csharp-ts-mode bash-ts-mode dockerfile-ts-mode cmake-ts-mode go-ts-mode yaml-ts-mode rust-ts-mode ruby-ts-mode In version 30.0.50 more added: html-ts-mode heex-ts-mode elixir-ts-mode lua-ts-mode Maybe grammars for these modes should be added to propagated-inputs? -- Best regards, Aleksandr Vityazev
doc: Removing much of Binary Installation (was: Feedback of the GNU Guix manual)
Thank you Matt for the suggested diff.
Yes, I agree some simplification as you suggested would be beneficial,
so that the description of Binary Installation looks as simple as it
really is. (In particular, I have witnessed people, to whom I had
suggested Guix, fail at trying Guix because they tried Guix System on a
not libre-friendly laptop, when they could/should have tried Binary
Installation.)
> - Places
> directions for 'guix-install.sh' after directions to use
> distribution-specific package managers, giving preference to those
> simpler install processes over the more manual 'guix-install.sh'
> process
I don’t feel qualified to judge, but is this the preference? Arch wiki
advises against the Arch AUR package: “Therefore, after updating Guix
once, the AUR advantage really turns into a disadvantage, as there will
be many unnecessary files in the /usr file tree that are part of the
Guix AUR package but that are never used by Guix anymore. Therefore,
consider using the manual installation.” [0]
The reason of existence for these distribution packages is probably
similar to the reason why the Binary Installation section exists.
As for the suggested diff where much of Binary Installation gets
removed,
> -@item
> -@cindex substitutes, authorization thereof
> -To use substitutes from @code{@value{SUBSTITUTE-SERVER-1}},
> -@code{@value{SUBSTITUTE-SERVER-2}} or a mirror (@pxref{Substitutes}),
> -authorize them:
> -
> -@example
> -# guix archive --authorize < \
> - ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER-1}.pub
> -# guix archive --authorize < \
> - ~root/.config/guix/current/share/guix/@value{SUBSTITUTE-SERVER-2}.pub
> -@end example
> -
> -@quotation Note
> -If you do not enable substitutes, Guix will end up building
> -@emph{everything} from source on your machine, making each installation
> -and upgrade very expensive. @xref{On Trusting Binaries}, for a
> -discussion of reasons why one might want do disable substitutes.
> -@end quotation
I disagree with this chunk. This must stay. Not enabling substitutes
is an option in guix-install.sh and the Guix System installer. Users
might want to enable substitutes later on.
Regards,
Florian
[0] https://wiki.archlinux.org/title/Guix
Re: You're invited to the first patch review session!
On 2024-03-06 11:36:29 +, Etienne B. Roesch wrote: > That's the link I have https://meet.jit.si/london-guix-meetup Great, thank you very much, looking forward to tomorrow. :) Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: You're invited to the first patch review session!
That's the link I have https://meet.jit.si/london-guix-meetup Etienne On Wed, Mar 6, 2024 at 11:28 AM Tomas Volf <~@wolfsden.cz> wrote: > Hi, > > On 2024-03-06 10:40:14 +0100, Andreas Enge wrote: > > > > Looking forward to tomorrow, > > > > I would just like to point out that the link to the jitsi meeting is not > on the > wiki page and was not shared here neither (for those of us who have issues > with > meetup.com). I think it was said before the link would be shared > somewhere, so > please take this as a reminder (since it is tomorrow already). > > Have a nice day, > Tomas Volf > > -- > There are only two hard things in Computer Science: > cache invalidation, naming things and off-by-one errors. >
Re: You're invited to the first patch review session!
Hi, On 2024-03-06 10:40:14 +0100, Andreas Enge wrote: > > Looking forward to tomorrow, > I would just like to point out that the link to the jitsi meeting is not on the wiki page and was not shared here neither (for those of us who have issues with meetup.com). I think it was said before the link would be shared somewhere, so please take this as a reminder (since it is tomorrow already). Have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
G-exps: thunk instead of top-level references?
Hi Ludio,
I'd like to get some advice:
In commit 84c3aafb5a18ad278bbb36df7b70849fe05789c8 "trytond:
Avoid top-level references to other modules" your turned a
top-level variable which defines into a thunk:
-(define %standard-trytond-native-inputs
+(define (%standard-trytond-native-inputs)
`(("python-dateutil" ,python-dateutil)
and the users:
(native-inputs
- `(,@%standard-trytond-native-inputs
+ `(,@(%standard-trytond-native-inputs)
("trytond-purchase" ,trytond-purchase)))
I'm about to change the uses into G-exprs (see below) and wonder
whether "%standard-trytond-native-inputs" should still be a thunk
or can be turned pack into a top-level variable.
-(define
(%standard-trytond-native-inputs)
-
`(("python-dateutil" ,python-dateutil)
+(define
%standard-trytond-native-inputs
+ (list
python-dateutil
and uses
- (native-inputs
(%standard-trytond-native-inputs))
+ (native-inputs
+ (cons* trytond-account-payment-clearing
+ %standard-trytond-native-inputs))
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Re: You're invited to the first patch review session!
Hello, Am Tue, Mar 05, 2024 at 07:19:46PM + schrieb Etienne B. Roesch: > Anything we need to have prepared by Thursday? > I imagine a ubuntu vm running with vanilla guix installed is installed? you should have a means of running Guix, and so that your store gets populated with recent basic things, I would also suggest to run a "guix pull". It can be a virtual machine, a full Guix system, or simply a "foreign" distribution with Guix as a package manager. (I am not sure what you mean by "is installed"; I do not think Steve plans to install a machine shared between the participants, please bring your own!) Then you should clone the git repository as the basis to apply patches, as explained here: https://guix.gnu.org/en/manual/devel/en/html_node/Contributing.html I think reading the first two subsections 22.1 and 22.2 is enough to get started. Notice that building Guix takes a rather long time; on my oldish laptop with two cores, about half an hour. So this should be done before. Looking forward to tomorrow, Andreas
Re: rust-team branch merged
On Mon, Feb 26, 2024 at 09:24:29PM -0500, Jason Conroy wrote: > Hello Efraim, > > Thanks for investigating this - a Rust development workflow using only > Guix-native crates is something I've been waiting for! > > I was experimenting with your patches and it seems that they do pull in the > source crates for requested packages, but not their dependencies (example > below). Is there something I'm missing? When you say they pull in the source crates do you mean the sources of the other rust packages needed by rust-rand? I didn't test that, but I assumed it wouldn't. Currently if you were to pull in rust-rand-0.8 and rust-rand-0.7 then you'd have both rand-0.*.crate files in the registry but only one of them would be listed in share/cargo/registry/index/ra/nd/rand. I need to adjust the generation of that file to combine multiple sources if they exist, and sort them (I'm not sure it's necessary, but wouldn't be surprised if we hit undefined behaviour if they were listed multiple times or out of order). I also need to figure out something with a config.toml to see if it's possible to generate one that could be included from another one, since you can't add 'local-registry = $GUIX_PROFILE/...' in a toml file. > Cheers, > Jason > > $ guix shell --pure bash findutils rust-rand -- bash -c 'find -L > $GUIX_ENVIRONMENT/share/cargo' > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/index > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/index/ra > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/index/ra/nd > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/index/ra/nd/rand > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/rand-0.8.5.crate > /gnu/store/zf88v65rbg2di4qhgdbvhfcjf31rdzby-profile/share/cargo/registry/config.json > > On Thu, Dec 14, 2023 at 10:10 AM Efraim Flashner > wrote: > > > On Wed, Dec 13, 2023 at 10:34:11AM +0200, Efraim Flashner wrote: > > > * Compiled rust packages currently have a 'package' phase, which runs > > > the command used to crate a 'crate tarball', and is installed in > > > %output/share/cargo/registry, with unpacked sources in > > > %output/share/cargo/src. In theory it should be possible to use these > > > for local rust development. The benefits include everything that comes > > > with being a guix package, including pre-patched shebangs. Currently no > > > index file is created in $GUIX_ENVIRONMENT/share/cargo/registry/index, > > > which is likely necessary to actually make use of this. Additionally, I > > > am unsure how to use '$GUIX_ENVIRONMENT' in ~/.cargo/config so that it > > > is expanded and not taken as a literal string. > > > > In the Guix London meetup someone mentioned that they were interested in > > playing around with using Guix for rust development. I've adjusted the > > cargo-build-system to produce the registry index files and I added a > > profile hook to generate the config.json to locate the packaged crates. > > > > toml files can't process environment variables (which is probably a good > > thing ...) but that means its a little harder to test out. > > > > with the two patches applied create an environment with the crates you > > want and get the location of GUIX_ENVIRONMENT: > > `env | grep GUIX_ENVIRONMENT | cut -f2 -d=` > > > > in ~/.cargo/config: > > [source.crates-io] > > local-registry = '/share/cargo/registry' > > > > 'cargo build' should pull from the local crates in the GUIX_ENVIRONMENT. > > I'm not sure what happens if it doesn't have those crates available and > > would need to get them from crates.io. > > > > -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
