Re: Is this a bug in guix refresh with respect to Common Lisp packages?
Yep, this looks broken: [jgart@fedora guix] [env]$ make -j6 && ./pre-inst-env guix refresh -l sbcl-enhanced-eval-when ecl-enhanced-eval-when make all-recursive make[1]: Entering directory '/home/jgart/Code/guix' Making all in po/guix make[2]: Entering directory '/home/jgart/Code/guix/po/guix' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/jgart/Code/guix/po/guix' Making all in po/packages make[2]: Entering directory '/home/jgart/Code/guix/po/packages' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/home/jgart/Code/guix/po/packages' make[2]: Entering directory '/home/jgart/Code/guix' Compiling Scheme modules... Compiling Scheme modules... Compiling Scheme modules... Compiling Scheme modules... Compiling Scheme modules... Compiling Scheme modules... Compiling Scheme modules... Compiling Scheme modules... make[2]: Leaving directory '/home/jgart/Code/guix' make[1]: Leaving directory '/home/jgart/Code/guix' Building the following 2 packages would ensure 10 dependent packages are rebuilt: cl-definitions-systems@2.0.1 ecl-definitions-systems@2.0.1 This email is gluten-free, vegan, and 100% organic, jgart
Is this a bug in guix refresh with respect to Common Lisp packages?
make -j6 && ./pre-inst-env guix refresh -l sbcl-enhanced-eval-when I don't see 7 dependent packages that would be rebuilt... Just three. Building the following 1 package would ensure 7 dependent packages are rebuilt: cl-definitions-systems@2.0.1 sent while avoiding adult responsibilities, jgart
#$(this-package-input "subversion") in git introduces a cycle
Hello Guix,
While working toward resolving bug #66305, I've decided to tidy the
house a bit, starting with dropping input labels and using gexps for the
git package, as shown attached.
>From 703534c8b1b8355293d3014ef5e59a0f8dd263de Mon Sep 17 00:00:00 2001
Message-ID: <703534c8b1b8355293d3014ef5e59a0f8dd263de.1696644353.git.maxim.courno...@gmail.com>
From: Maxim Cournoyer
Date: Fri, 6 Oct 2023 11:02:51 -0400
Subject: [PATCH] gnu: git: Remove labels and use gexps.
* gnu/packages/version-control.scm (git)
[native-inputs, inputs]: Remove labels.
[arguments]: Use gexps. Use gexp variables input searching procedures where
it makes sense.
---
gnu/packages/version-control.scm | 692 ---
1 file changed, 351 insertions(+), 341 deletions(-)
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index d9c53af71c..1a6e36ca53 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -230,358 +230,368 @@ (define git-cross-configure-flags
(define-public git
(package
- (name "git")
- (version "2.41.0")
- (source (origin
-(method url-fetch)
-(uri (string-append "mirror://kernel.org/software/scm/git/git-"
-version ".tar.xz"))
-(sha256
- (base32
- "0h40arw08xbpi2cbf7pvc947v963rjxz3inb2ar81zjc8byvlj77"
- (build-system gnu-build-system)
- (native-inputs
-`(("native-perl" ,perl)
- ;; Add bash-minimal explicitly to ensure it comes before bash-for-tests,
- ;; see .
- ("bash" ,bash-minimal)
- ("bash-for-tests" ,bash)
- ("gettext" ,gettext-minimal)
- ;; To build the man pages from the git sources, we would need a dependency
- ;; on a full XML tool chain, and building it actually takes ages. So we
- ;; use this lazy approach and use released tarball.
- ("git-manpages"
- ,(origin
- (method url-fetch)
- (uri (string-append
-"mirror://kernel.org/software/scm/git/git-manpages-"
-version ".tar.xz"))
- (sha256
- (base32
-"0xsqakgy0s60zpa13ilj6zj420kdh8pf4v3nrp1nziwj8ja4qymw"
- ;; For subtree documentation.
- ("asciidoc" ,asciidoc)
- ("docbook2x" ,docbook2x)
- ("docbook-xsl" ,docbook-xsl)
- ("libxslt" ,libxslt)
- ("pkg-config" ,pkg-config)
- ("texinfo" ,texinfo)
- ("xmlto" ,xmlto)))
- (inputs
-`(("curl" ,curl)
- ("expat" ,expat)
- ("openssl" ,openssl)
- ("perl" ,perl)
- ("python" ,python) ; for git-p4
- ("zlib" ,zlib)
-
- ;; For PCRE support in git grep (USE_LIBPCRE2).
- ("pcre" ,pcre2)
-
- ;; For 'gitweb.cgi'.
- ("perl-cgi" ,perl-cgi)
-
- ;; For 'git-svn'.
- ("subversion" ,subversion)
- ("perl-term-readkey" ,perl-term-readkey)
-
- ;; For 'git-send-email'.
- ("perl-authen-sasl" ,perl-authen-sasl)
- ("perl-net-smtp-ssl" ,perl-net-smtp-ssl)
- ("perl-io-socket-ssl" ,perl-io-socket-ssl)
-
- ;; For 'git gui', 'gitk', and 'git citool'.
- ("tcl" ,tcl)
- ("tk" ,tk)
-
- ;; For 'git-credential-libsecret'
- ("glib" ,glib)
- ("libsecret" ,libsecret)))
-(outputs '("out"; the core
- "send-email" ; for git-send-email
- "svn"; git-svn
- "credential-netrc" ; git-credential-netrc
- "credential-libsecret" ; git-credential-libsecret
- "subtree"; git-subtree
- "gui")) ; gitk, git gui
-(arguments
- `(#:make-flags `("V=1" ;more verbose compilation
+(name "git")
+(version "2.41.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "mirror://kernel.org/software/scm/git/git-"
+ version ".tar.xz"))
+ (sha256
+ (base32
+"0h40arw08xbpi2cbf7pvc947v963rjxz3inb2ar81zjc8byvlj77"
+(build-system gnu-build-system)
+(native-inputs
+ (list perl
+ ;; Add bash-minimal explicitly to ensure it comes before bash-for-tests,
+ ;; see .
+ bash-minimal
+ bash
+ gettext-minimal
+ (origin
+ (method url-fetch)
+ (uri (string-append
+ "mirror://kernel.org/software/scm/git/git-manpages-"
+ version ".tar.xz"))
+ (sha256
+ (base32
+ "0xsqakgy0s60zpa13ilj6zj420kdh8pf4v3nrp1nziwj8ja4qymw")))
+ ;; For subtree documentation.
+ asciidoc
+ docbook2x
+ docbook-xsl
+ libxslt
+ pkg-config
+ texinfo
+ xmlto))
+(inputs
+ (list curl
+ expat
+
Guix QA "Unable to apply patches"
Hi, for one of my package patches, Guix QA shows "Unable to apply patches" in https://qa.guix.gnu.org/issue/63095 even though I double checked the patch applies cleanly on the current head of the master branch. Guix QA shows no hint as what the failure is (no log, etc.) Curious how to investigate the problem?
Re: IDEA: missing-tests-pypi-error? condition
Hi Maxim! Maxim Cournoyer aliandika: > Hi, > > Munyoki Kilyungi writes: > >> "jgart" aliandika: >> >>> Hi Guixers, >>> >>> I was recently reviewing a patch by a contributor and was discussing the >>> notion of preferring upstream to PyPI when tests are missing on PyPI. >>> >> What's the policy on this. Shouldn't we prefer >> upstream over PyPI? Sometimes, PyPI versions lag >> behind upstream versions. > > There's no written policy about it at this time, but I think it's common > knowledge in Guix that we try hard to: > > 1. Unbundle dependencies (that one is documented) > 2. Run test suites (that one isn't) > > We could hint at this globally in the contributing section, and perhaps > expound with more specific details in the Python Modules contributing > section, mentioning that when the PyPI source archive lacks tests, > fetching from the git repository should be preferred. > > Another thing we could do is default to fetch from git for the Python > importer. > Thanks for this info. I'm dedicating an hour of my day from work to try to contrib to the eco-system with Jgarte's help. What's, if I may naively ask, the process for documenting this knowledge? I can take a stub at trying to document this and asking for reviews. >>> WDYT if we also signalled a special condition when there are missing tests >>> in PyPI? >>> >> I posit that this should be the responsibility of >> the contributor. Adding extra glue can add >> unnecessary complexity. > > I think an error would help catching this situation; the > gnu-build-system would fail running 'make check' when there is no check > target for example, but in the Python world, running 'python setup.py > test' often succeeds even 0 tests were run, which is easy to overlook. > I'm not sure how easy it'd be to check for missing tests though. > TIL'ed. -- (Life is like a pencil that will surely run out, but will leave the beautiful writing of life.) (D4F09EB110177E03C28E2FE1F5BBAE1E0392253F (hkp://keys.openpgp.org)) signature.asc Description: PGP signature
Re: IDEA: missing-tests-pypi-error? condition
Hi, Munyoki Kilyungi writes: > "jgart" aliandika: > >> Hi Guixers, >> >> I was recently reviewing a patch by a contributor and was discussing the >> notion of preferring upstream to PyPI when tests are missing on PyPI. >> > What's the policy on this. Shouldn't we prefer > upstream over PyPI? Sometimes, PyPI versions lag > behind upstream versions. There's no written policy about it at this time, but I think it's common knowledge in Guix that we try hard to: 1. Unbundle dependencies (that one is documented) 2. Run test suites (that one isn't) We could hint at this globally in the contributing section, and perhaps expound with more specific details in the Python Modules contributing section, mentioning that when the PyPI source archive lacks tests, fetching from the git repository should be preferred. Another thing we could do is default to fetch from git for the Python importer. >> WDYT if we also signalled a special condition when there are missing tests >> in PyPI? >> > I posit that this should be the responsibility of > the contributor. Adding extra glue can add > unnecessary complexity. I think an error would help catching this situation; the gnu-build-system would fail running 'make check' when there is no check target for example, but in the Python world, running 'python setup.py test' often succeeds even 0 tests were run, which is easy to overlook. I'm not sure how easy it'd be to check for missing tests though. -- Thanks, Maxim
Re: IDEA: missing-tests-pypi-error? condition
"jgart" aliandika: >> Sometimes, PyPI versions lag behind upstream versions. > > Hi Bonz, > > Yes, in my experience that has sometimes been the case because maintainers > don't make timely releases to PyPI. > >> What's the policy on this. Shouldn't we prefer upstream over PyPI? > > Our importer works with the JSON API that PyPI provides at > https://pypi.org/pypi/baz/json > > See here: > > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/pypi.scm?h=master#n141 > > That API provides a lot of package data that GitHub does not track in a > unified and structured way. > Then given the above ... >> Adding extra glue can add unnecessary complexity. > > You're right. I thought about that after I sent the email with the idea ;() > PyPi unless we need to use upstream is the way to go ;) -- (Life is like a pencil that will surely run out, but will leave the beautiful writing of life.) (D4F09EB110177E03C28E2FE1F5BBAE1E0392253F (hkp://keys.openpgp.org)) signature.asc Description: PGP signature
Re: Failed to build in QA
"reza.housse...@gmail.com" writes: > On October 5, 2023 10:49:06 AM GMT+02:00, Christopher Baines > wrote: >> >>"reza.housse...@gmail.com" writes: >> >>> I submitted an issue to guix. But QA refuses to build it [1]. I have >>> no clue what the problem is, can anyone shed light on a possible >>> resolution? >> >>You pretty much found the problem, the relevant line on the page you >>linked to is: >> >>[ 6/ 50] loading... 24.0% of 25 filesbuilder for >>`/gnu/store/qhvpjfn3d9cwz5zxadblbnbqa92a8i27-guix-cli-core.drv' failed due to >>signal 11 (Segmentation fault) >> >>So the data service wasn't able to build Guix. This probably isn't due >>to your changes, and it doesn't happen very often, so the thing to do >>here is just retry. >> >>I've triggered QA to reapply the patches now (by deleting the >>issue-66262 branch), so hopefully things will work better this time. >> >>Thanks, >> >>Chris > > Thanks very much, it seems to have worked, but now it's stuck with > paraview undefined symbol, although the necessary module > (gnu/packages/image-processing) is imported? This is probably down to a top level circular dependency. In particular, trying to paraview to compute the version to form part of the native-search-path at the top level causes problems. Making openfoam have LD_LIBRARY_PATH as a search path seems like the incorrect use of search paths though, since you're searching for something in the same package. Replacing this with wrapping would be an improvement, although still I'm unsure why LD_LIBRARY_PATH would need setting in this case. signature.asc Description: PGP signature
Re: IDEA: missing-tests-pypi-error? condition
> Sometimes, PyPI versions lag behind upstream versions. Hi Bonz, Yes, in my experience that has sometimes been the case because maintainers don't make timely releases to PyPI. > What's the policy on this. Shouldn't we prefer upstream over PyPI? Our importer works with the JSON API that PyPI provides at https://pypi.org/pypi/baz/json See here: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/pypi.scm?h=master#n141 That API provides a lot of package data that GitHub does not track in a unified and structured way. > Adding extra glue can add unnecessary complexity. You're right. I thought about that after I sent the email with the idea ;() Doing my best to make inboxes a happier place, jgart
Re: IDEA: missing-tests-pypi-error? condition
"jgart" aliandika: > Hi Guixers, > > I was recently reviewing a patch by a contributor and was discussing the > notion of preferring upstream to PyPI when tests are missing on PyPI. > What's the policy on this. Shouldn't we prefer upstream over PyPI? Sometimes, PyPI versions lag behind upstream versions. > WDYT if we also signalled a special condition when there are missing tests in > PyPI? > I posit that this should be the responsibility of the contributor. Adding extra glue can add unnecessary complexity. > I'm thinking of something similar to here: > > https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/pypi.scm?h=master#n562 > > Maybe it can be a missing-tests-pypi-error? > > This email is gluten-free, vegan, and 100% organic, > > jgart > -- (Life is like a pencil that will surely run out, but will leave the beautiful writing of life.) (D4F09EB110177E03C28E2FE1F5BBAE1E0392253F (hkp://keys.openpgp.org)) signature.asc Description: PGP signature
