Re: shortening the git test suite
Ludovic Courtès ezt írta (időpont: 2018. júl. 6., P, 23:05): > Hello, > > Mark H Weaver skribis: > > > Why do you say that only upstream needs to worry about it? I would > > think that you could say the same thing about almost any test suite, but > > there's always the possibility that our particular combination of input > > versions, or the unusual aspects of Guix, might break something that > > upstream doesn't know about. > > > > I would think that git-svn interop is something that any user of the > > git/svn integration needs to worry about. > > I agree. > > > If we feel that very few of our users care about git-svn interop, > > another option would be to add a lighter variant of 'git' that does not > > include SVN support. It would probably be a good idea to have a > > 'git-minimal' package anyway, for use by our 'git-fetch' origin method. > > Naturally, only the 'git' package variant that includes SVN support > > would need to run the SVN tests. > > Yeah, I think we could to do something like this in this case. > > Instead of ‘git-minimal’, we could have ‘git’ without SVN support, and > have a separate ‘git-svn’ package. We can probably arrange for that > ‘git-svn’ package to only provide the relevant libexec/git-core bits > (git-svn is just a Perl script anyway.) > > Thoughts? > > > Also, looking ahead, I think it would be great if we could eventually > > move to a model where the tests of some packages are split off into > > separate derivations. Similarly, we could work toward splitting off > > documentation generation to separate derivation for selected packages. > > The most important advantage to this approach is that it would allow > > inputs needed only for tests or docs to be omitted from the inputs of > > the main package. I expect that this will in many cases be needed to > > prevent circular dependencies, and it could also greatly reduce the > > amount of rebuilding needed after updating certain packages. > > Currently if test fails, the whole derivation fails, and you can’t > install your package. If tests were run separately, this would no > longer hold: you could get your package regardless of whether tests > fail. How would you address this? I guess that calls for a new build > model, no? > > One example where this can be seen in action is the dependency of java-jarjar on java-asm-bootstrap. java-asm-bootstrap is java-asm without the tests, it is exactly there to break a dependency cycle. java-asm is a full rebuild using tests. java-asm-bootstrap is defined, while java-asm is define-public-ed (here a full rebuild is involved). I'm not sure that a full rebuild can be worked around in all cases, I guess that sometimes test capabilities are detected at configure time. WDYT? Thanks, > Ludo’. > >
Re: GNU Guix & GuixSD 0.15.0 released
Hooray :) Nitpick and complain: Could we please send this to guix-devel as TO and use BCC for the rest or even: separate emails? I'm getting so many duplicates with every release. I know it's a timesaver, but cross-posting and then people replying with "reply to all" to cross-posted messages can be annoying. alex sassmannshausen transcribed 186K bytes: > Yay, congratulations to all involved. Those commit numbers are off the > charts! > > :DDD > > Alex > > On Fri, 6 Jul 2018, 14:24 Ludovic Courtès, wrote: > > > We are pleased to announce the release of GNU Guix & GuixSD 0.15.0, > > representing 7,020 commits by 100 people over 7 months. > > > > This release brings us close to our goals for 1.0, so it’s probably one > > of the last zero-dot-something releases. > > > > > > • About > > > > GNU Guix is a transactional package manager for the GNU system. > > The Guix System Distribution, GuixSD, is an advanced distribution > > of the GNU system. > > > > In addition to standard package management features, Guix supports > > transactional upgrades and roll-backs, unprivileged package > > management, and per-user profiles. GuixSD offers a declarative > > approach to operating system configuration management and is highly > > hackable. Guix uses low-level mechanisms from the Nix package > > manager, except that packages are defined as native Guile modules, > > using extensions to the Scheme language. > > > > GuixSD uses the Linux-Libre kernel and the GNU Shepherd init system. > > It can be used on an i686, x86_64, armv7, or aarch64 machine. > > > > It is also possible to use Guix on top of an already installed > > GNU/Linux system, including on armv7, aarch64, and mips64el. > > > > https://www.gnu.org/software/guix/ > > > > • Download > > > > Here are the compressed sources and a GPG detached signature[*]: > > https://alpha.gnu.org/gnu/guix/guix-0.15.0.tar.gz > > https://alpha.gnu.org/gnu/guix/guix-0.15.0.tar.gz.sig > > > > Here are the bootable USB installation images and their signatures[*]: > > https://alpha.gnu.org/gnu/guix/guixsd-install-0.15.0.i686-linux.iso.xz > > > > https://alpha.gnu.org/gnu/guix/guixsd-install-0.15.0.i686-linux.iso.xz.sig > > > > https://alpha.gnu.org/gnu/guix/guixsd-install-0.15.0.x86_64-linux.iso.xz > > > > https://alpha.gnu.org/gnu/guix/guixsd-install-0.15.0.x86_64-linux.iso.xz.sig > > > > Here is the QCOW2 virtual machine (VM) image and its signature: > > https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.15.0.x86_64-linux.xz > > > > https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.15.0.x86_64-linux.xz.sig > > > > Here are the binary tarballs and their signatures[*]: > > https://alpha.gnu.org/gnu/guix/guix-binary-0.15.0.i686-linux.tar.xz > > > > https://alpha.gnu.org/gnu/guix/guix-binary-0.15.0.i686-linux.tar.xz.sig > > https://alpha.gnu.org/gnu/guix/guix-binary-0.15.0.x86_64-linux.tar.xz > > > > https://alpha.gnu.org/gnu/guix/guix-binary-0.15.0.x86_64-linux.tar.xz.sig > > https://alpha.gnu.org/gnu/guix/guix-binary-0.15.0.armhf-linux.tar.xz > > > > https://alpha.gnu.org/gnu/guix/guix-binary-0.15.0.armhf-linux.tar.xz.sig > > https://alpha.gnu.org/gnu/guix/guix-binary-0.15.0.aarch64-linux.tar.xz > > > > https://alpha.gnu.org/gnu/guix/guix-binary-0.15.0.aarch64-linux.tar.xz.sig > > > > Use a mirror for higher download bandwidth: > > http://www.gnu.org/order/ftp.html > > > > Here are the SHA1 checksums: > > > > b971e19b539f3f27f675bc1d7cfc126065a7d61c guix-0.15.0.tar.gz > > 48e4f95b13133f23e271791e230f1a50896b2033 > > guix-binary-0.15.0.aarch64-linux.tar.xz > > a37add10720284793b82f86cca84b24a94253360 > > guix-binary-0.15.0.armhf-linux.tar.xz > > 1c26d12ad278273f2864bc165a998e5429d1eea0 > > guix-binary-0.15.0.i686-linux.tar.xz > > 38fd4c9076f82823b5e981d78622a2d3c74984d0 > > guix-binary-0.15.0.x86_64-linux.tar.xz > > 410db099a7c8bbc134a2f05438004db12376d71e > > guixsd-install-0.15.0.i686-linux.iso.xz > > 1029730bf9f11a8039d66a9bf4fc77e8e1b2eb53 > > guixsd-install-0.15.0.x86_64-linux.iso.xz > > 2664f09efe3f5f999c0a115251eb68eb30ed74b0 > > guixsd-vm-image-0.15.0.x86_64-linux.xz > > > > [*] Use a .sig file to verify that the corresponding file (without the > > .sig suffix) is intact. First, be sure to download both the .sig file > > and the corresponding tarball. Then, run a command like this: > > > > gpg --verify guix-0.15.0.tar.gz.sig > > > > If that command fails because you don't have the required public key, > > then run this command to import it: > > > > gpg --keyserver pool.sks-keyservers.net \ > > --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > > > > and rerun the 'gpg --verify' command. > > > > This release was bootstrapped with the following tools: > > Autoconf 2.69 > > Automake 1.16.1 > > Makeinfo 6.5 > > Help2man 1.47.6 > > > > To install the Guix System Distribution, please see “System > > Installation” in the manual. T
Having a Guix archive on the download page?
Is it an idea to also have a current Guix archive on the download page? Or at least a link to one? https://www.gnu.org/software/guix/download/ Ever so often I need to rescue a running Guix system which won't run guix pull and even a build-from-source quickly. Being able to do guix archive --import < guix-latest.nar or something similar would be rather convenient. Now I am packing my own archive from a VM because my systems won't build a recent tree and guix pull requires guile-git which won't build in turn. It is one of those days that I look to either pack guix or have a long slog of building just to get going again... With a downloadable archive, and with the recent improvement of guix pull, I think anyone can rescue quickly any guix daemon and build system. The key term is: convenience. Pj.
Re: shortening the git test suite
Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> If we feel that very few of our users care about git-svn interop, >> another option would be to add a lighter variant of 'git' that does not >> include SVN support. It would probably be a good idea to have a >> 'git-minimal' package anyway, for use by our 'git-fetch' origin method. >> Naturally, only the 'git' package variant that includes SVN support >> would need to run the SVN tests. > > Yeah, I think we could to do something like this in this case. > > Instead of ‘git-minimal’, we could have ‘git’ without SVN support, and > have a separate ‘git-svn’ package. We can probably arrange for that > ‘git-svn’ package to only provide the relevant libexec/git-core bits > (git-svn is just a Perl script anyway.) > > Thoughts? Sure, that sounds good to me. Whether it makes to have a 'git-minimal' package depends on how many other optional dependencies could reasonably be removed from it, besides subversion. If not much else could be removed, then I suppose there would be no need for a 'git-minimal' variant. >> Also, looking ahead, I think it would be great if we could eventually >> move to a model where the tests of some packages are split off into >> separate derivations. Similarly, we could work toward splitting off >> documentation generation to separate derivation for selected packages. >> The most important advantage to this approach is that it would allow >> inputs needed only for tests or docs to be omitted from the inputs of >> the main package. I expect that this will in many cases be needed to >> prevent circular dependencies, and it could also greatly reduce the >> amount of rebuilding needed after updating certain packages. > > Currently if test fails, the whole derivation fails, and you can’t > install your package. If tests were run separately, this would no > longer hold: you could get your package regardless of whether tests > fail. Indeed, and I agree that we would need to address this. > How would you address this? I guess that calls for a new build > model, no? I'm not sure what you mean by "build model", whether you are talking about the daemon interface or something else, but I think the changes could be confined to the Guix user interface. A field could be added to , somewhat similar to 'replacement', but pointing to a package object which runs tests, or perhaps a list of package objects. The guix client could simply add the test packages to the list of derivations to build. This could be inhibited via a "--no-tests" guix build option. In typical cases where "make check" expects to be run from a fully built source directory, the main package would typically produce a tarball of the built source directory as an additional output. The test package would simply unpack this tarball and run "make check" in it. Regarding the build order: ideally, we would run the tests for package FOO immediately after building FOO, or at least before building anything that depends on FOO, to avoid wasted work in case the tests fail. I'm not sure how best to accomplish this. What do you think? Mark
Re: shortening the git test suite
Mark H Weaver writes: >>> Also, looking ahead, I think it would be great if we could eventually >>> move to a model where the tests of some packages are split off into >>> separate derivations. Similarly, we could work toward splitting off >>> documentation generation to separate derivation for selected packages. >>> The most important advantage to this approach is that it would allow >>> inputs needed only for tests or docs to be omitted from the inputs of >>> the main package. I expect that this will in many cases be needed to >>> prevent circular dependencies, and it could also greatly reduce the >>> amount of rebuilding needed after updating certain packages. >> >> Currently if test fails, the whole derivation fails, and you can’t >> install your package. If tests were run separately, this would no >> longer hold: you could get your package regardless of whether tests >> fail. > > Indeed, and I agree that we would need to address this. > >> How would you address this? I guess that calls for a new build >> model, no? > > I'm not sure what you mean by "build model", whether you are talking > about the daemon interface or something else, but I think the changes > could be confined to the Guix user interface. A field could be added to > , somewhat similar to 'replacement', but pointing to a package > object which runs tests, or perhaps a list of package objects. The guix > client could simply add the test packages to the list of derivations to > build. This could be inhibited via a "--no-tests" guix build option. A problem that would need solving is that tests often depend on the build directory, which is different from what is installed (and ends up in the store). The build directory is lost. This is not true for all packages, but I’ve encountered enough for which this would not work. A change to the “build model” might be to allow for build directories to be provided as inputs to a derivation. (If this were to be implemented developers could use that as a way to debug failed builds by keeping the build directory, make changes, and continuing the build using the modified build directory, but this feature would have to be heavily guarded from being abused as a means to get stateful builds into the store.) -- Ricardo
Re: shortening the git test suite
On Fri, Jul 06, 2018 at 23:05:04 +0200, Ludovic Courtès wrote: > Instead of ‘git-minimal’, we could have ‘git’ without SVN support, and > have a separate ‘git-svn’ package. We can probably arrange for that > ‘git-svn’ package to only provide the relevant libexec/git-core bits > (git-svn is just a Perl script anyway.) > > Thoughts? I'm a git-svn user, and that sounds fine with me. I agree that's much better to provide a separate package with the SVN tests rather than simply disable SVN tests in a full-featured Git. -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com signature.asc Description: PGP signature
