Re: Generated patches change over time
Hello Mark, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: [...] >> Lesson learned: we should not rely at all on generated patches because >> they are bound to change frequently (version string at the end, length >> of commit hash prefixes, etc.) It’s probably worse than tarballs >> generated by Git hosting services. > > I guess the length of the commit hashes probably won't change very > often, so the version number is the most pressing issue here. Overall though such patches may typically change several times a year. > I wonder if it would be worth adding a special 'origin' type that > removes the version number from the end of git patches. As I replied to Maxim, this is not really possible. >> So we should probably work towards using local copies of patches, unless >> we find that the generated patches do not include any variable bits. > > It might still be best to work towards using local copies of patches, > although in the case of IceCat the set of patches is often quite large. > > Another issue to consider is that the use of local copies of patches > involves putting more trust in contributors, in practice, or at least it > seems so to me. When someone adds a non-obvious patch from upstream as > a local file, it leads me to want to check to make sure it hasn't been > modified from the upstream version, whereas if the package recipe > fetches a patch from a URL that is clearly from the upstream git > repository, it's somewhat more transparent what's going on. Yeah I agree with this. Another concern is unbounded growth of the Git repo. OTOH a patch that changes over time becomes non auditable: you’ll notice it has changed, and maybe that’s because of a benign change like those discussed above, but maybe it’s something else; if you can’t retrieve or reproduce the original patch, you can’t tell what the difference is. So I don’t have a good solution, but I think we should avoid upstream patches when we know they are generated in a non-reproducible fashion. Thanks, Ludo’.
Re: Generated patches change over time
l...@gnu.org (Ludovic Courtès) writes: > Maxim Cournoyer skribis: > l...@gnu.org (Ludovic Courtès) writes: >> >>>Lesson learned: we should not rely at all on generated patches because >>>they are bound to change frequently (version string at the end, length >>>of commit hash prefixes, etc.) It’s probably worse than tarballs >>>generated by Git hosting services. >>> >>>So we should probably work towards using local copies of patches, >>>unless >>>we find that the generated patches do not include any variable bits. >>> >> >> Maybe we could pass the patches through some sanitizer to strip any >> metadata? I guess the content itself shouldn't change? > > We can’t really do that, or the downloads would no longer be > fixed-output derivations and thus we wouldn’t be solving the problem. Can you elaborate on why it cannot be done? If I understand correctly, our 'git-fetch' origin type deletes the .git subdirectory after fetching it, and yet it still creates fixed-output derivations, no? I don't see why stripping metadata from a patch is fundamentally any different. Mark
Re: 01/01: gnu: ocaml@4.01: Remove aarch64-linux from supported-systems.
Hi Efraim, guix-comm...@gnu.org writes: > efraim pushed a commit to branch master > in repository guix. > > commit 454e7132d6fffb5c9a5ce086ffd1b687416feb83 > Author: Efraim Flashner > Date: Sat Dec 1 22:41:19 2018 +0200 > > gnu: ocaml@4.01: Remove aarch64-linux from supported-systems. > > * gnu/packages/ocaml.scm (ocaml@4.01)[supported-systems]: New field. What's the rationale for this change? Debian includes OCaml 4.01 in its arm64 port. https://packages.debian.org/search?arch=arm64&keywords=ocaml http://http.us.debian.org/debian/pool/main/o/ocaml/ocaml_4.01.0-5_arm64.deb Mark
hg-fetch with subrepos
Hi guix! Thanks and please bear with my first ever mailing list post. I was trying to package coin3d (https://bitbucket.org/Coin3D/coin/wiki/Home) as it is now under a bsd3 license. The hash of the repo always changes. I think this is due to the .hg files not being recursively deleted for the subrepositories (https://www.mercurial-scm.org/wiki/Subrepository). Does anyone have any insights? Thanks! John
Re: Generated patches change over time
Hello, Maxim Cournoyer skribis: >>> l...@gnu.org (Ludovic Courtès) writes: > >>Lesson learned: we should not rely at all on generated patches because >>they are bound to change frequently (version string at the end, length >>of commit hash prefixes, etc.) It’s probably worse than tarballs >>generated by Git hosting services. >> >>So we should probably work towards using local copies of patches, >>unless >>we find that the generated patches do not include any variable bits. >> > > Maybe we could pass the patches through some sanitizer to strip any metadata? > I guess the content itself shouldn't change? We can’t really do that, or the downloads would no longer be fixed-output derivations and thus we wouldn’t be solving the problem. Ludo’.
Re: Merging core-updates
Ricardo Wurmus writes: >> Overall I’m in favor of merging. > > I agree. > > I’ve been using core-updates on my laptop (both system and user profile) > for about a week now without any problems. Me too. janneke
New French PO file for 'guix-manual' (version 0.16.0.1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-manual' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/guix-manual/fr.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix-manual/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix-manual.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Merging core-updates
Hi, > ‘core-updates’ seems to be in a rather good shape. […] > On x86_64, LibreOffice, IceCat, etc. are available as substitutes; ‘guix > weather’ reports only 50% of coverage on berlin and 80% on > mirror.hydra.gnu.org (we’ll have to elucidate the bad number on berlin.) > I’m using ‘core-updates’ for both my system and my user profile. > > Overall I’m in favor of merging. I agree. I’ve been using core-updates on my laptop (both system and user profile) for about a week now without any problems. -- Ricardo
Re: Guile-JSON now seems to be a required dependency
Hi Eric, Eric Bavier writes: > On Fri, 30 Nov 2018 23:45:04 -0500 > Timothy Sample wrote: > >> Hello all, >> >> I just tried to build Guix from source and got an error: >> >> ERROR: no code for module (json) >> >> It looks like the new “swh.scm” module (which is really cool!) makes >> Guile-JSON a required dependency. I’m not sure if this is intentional. >> If it is, the “Requirements” section of the manual needs an update. > > Yes, we decided to make it a hard requirement. I'm working on a patch > to follow through. That’s good to know. Thanks very much for your work. :) > `~Eric -- Tim
Merging core-updates
Hello Guix! ‘core-updates’ seems to be in a rather good shape. Unfortunately, the web UI and APIs of hydra.gnu.org and berlin.guixsd.org make it difficult to have a clear view of the situation. “make assert-binaries-available” passes for all architectures, meaning we have Emacs/X11 among other things available as substitutes. The ‘bootstrap-tarballs’ package is available on all platforms including aarch64. On x86_64, LibreOffice, IceCat, etc. are available as substitutes; ‘guix weather’ reports only 50% of coverage on berlin and 80% on mirror.hydra.gnu.org (we’ll have to elucidate the bad number on berlin.) I’m using ‘core-updates’ for both my system and my user profile. Overall I’m in favor of merging. What do people think? Thanks, Ludo’.
Re: Question about Guix documentation
Hi Laura, Laura Lazzati writes: [...] > Yesterday I mentioned that I installed GuixSD on bare metal over IRC > channel, in my retroPC that in December this year will be 13 years old > :) happy birthday retroPC! a teenager :-) [...] > The example for desktop.scm has the line: > (device "my-root") instead of (device (file-system-label "my-root")) > I also don't know if that is a mistake or if it is on purpose because > of being newbie :) good work: it's a mistake as documented here https://guix.info/manual/en/File-Systems.html#File-Systems the file to fix is this: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples/desktop.tmpl because it is included in the documentation here: (https://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n9863) --8<---cut here---start->8--- @lisp @include os-config-desktop.texi @end lisp --8<---cut here---end--->8--- built via make as defined here (https://git.savannah.gnu.org/cgit/guix.git/tree/doc/local.mk#n107) --8<---cut here---start->8--- %D%/os-config-%.texi: gnu/system/examples/%.tmpl $(AM_V_GEN)$(MKDIR_P) "`dirname $@`"; \ cp "$<" "$@" --8<---cut here---end--->8--- > I wanted to ask you before doing anything because I'd rather read > other stuff, but if it is OK, then they are two lines, I can change > them and patch them. yes please, fix that template thanks! Gio -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Guile-JSON now seems to be a required dependency
On Fri, 30 Nov 2018 23:45:04 -0500 Timothy Sample wrote: > Hello all, > > I just tried to build Guix from source and got an error: > > ERROR: no code for module (json) > > It looks like the new “swh.scm” module (which is really cool!) makes > Guile-JSON a required dependency. I’m not sure if this is intentional. > If it is, the “Requirements” section of the manual needs an update. Yes, we decided to make it a hard requirement. I'm working on a patch to follow through. `~Eric pgpgpZHT4ptoy.pgp Description: OpenPGP digital signature
Re: Guile-JSON now seems to be a required dependency
Timothy Sample writes:
If it is as new dependency, ya'll can use this texinfo patch that adds
guile-json as a dependency and alphabetizes the required packages:
Thanks,
Joshua
>From 2d860d1889b6c4bafe3d605ee47f9c93c3e91091 Mon Sep 17 00:00:00 2001
From: Joshua Branson
Date: Sat, 1 Dec 2018 08:36:20 -0500
Subject: [PATCH] Adding guile-json as a required dependency for swh.scm. I
also alphabetized the requirements.
---
doc/guix.texi | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index fff5dfe0b..e651c3617 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -643,15 +643,17 @@ later, including 2.2.x;
@item @url{https://notabug.org/cwebber/guile-gcrypt, Guile-Gcrypt}, version
0.1.0 or later;
@item
-@uref{http://gnutls.org/, GnuTLS}, specifically its Guile bindings
-(@pxref{Guile Preparations, how to install the GnuTLS bindings for
-Guile,, gnutls-guile, GnuTLS-Guile});
+@c FIXME: Specify a version number once a release has been made.
+@uref{https://gitlab.com/guile-git/guile-git, Guile-Git}, from August
+@item @url{https://github.com/aconchillo/guile-json, Guile-JSON}, version
+1.2.0 or later;
@item
@uref{https://notabug.org/guile-sqlite3/guile-sqlite3, Guile-SQLite3}, version 0.1.0
or later;
@item
-@c FIXME: Specify a version number once a release has been made.
-@uref{https://gitlab.com/guile-git/guile-git, Guile-Git}, from August
+@uref{http://gnutls.org/, GnuTLS}, specifically its Guile bindings
+(@pxref{Guile Preparations, how to install the GnuTLS bindings for
+Guile,, gnutls-guile, GnuTLS-Guile});
2017 or later;
@item @url{http://zlib.net, zlib};
@item @url{http://www.gnu.org/software/make/, GNU Make}.
--
2.19.2
> Hello all,
>
> I just tried to build Guix from source and got an error:
>
> ERROR: no code for module (json)
>
> It looks like the new “swh.scm” module (which is really cool!) makes
> Guile-JSON a required dependency. I’m not sure if this is intentional.
> If it is, the “Requirements” section of the manual needs an update.
>
> I was able to build Guix using the same build script without Guile-JSON
> on commit 5e369f8ab9e230193194b4d5846a5c78bbc89943.
>
> -- Tim
Question about Guix documentation
Hi everyone :) I have some questions as regards documentation: Yesterday I mentioned that I installed GuixSD on bare metal over IRC channel, in my retroPC that in December this year will be 13 years old :) I did a basic installation, almost followed the first example in: https://guix.info/manual/en/Using-the-Configuration-System.html#Using-the-Configuration-System, since it is old and it cannot support a GUI, for a example. I would like to read some other stuff this weekend, but there were some parts of the documentation that were confusing for me or in which I made mistakes because instead of being example texinfo commands they were code. I don't know if that is on purpose. The example for desktop.scm has the line: (device "my-root") instead of (device (file-system-label "my-root")) I also don't know if that is a mistake or if it is on purpose because of being newbie :) I wanted to ask you before doing anything because I'd rather read other stuff, but if it is OK, then they are two lines, I can change them and patch them. Regards :) Laura
