bug#70339: Constructing hg-fetch fixed-output derivation requires Mercurial
Simon Tournier skribis: > Hi Ludo, > > On Fri, 12 Apr 2024 at 11:30, Ludovic Courtès > wrote: > >> > $ guix build -S -d hg-commitsigs >> > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% >> > 3,7 MB will be downloaded: >> > /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2 >> > substituting /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2... >> > downloading from >> > https://ci.guix.gnu.org/nar/lzip/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2 >> > ... >> > mercurial-6.2.2 3.5MiB >> > 529KiB/s 00:07 ▕██▏ 100.0% >> > >> > /gnu/store/pkb6zd9xfmxx6rsh4p7w3glh7xqg5sqy-hg-commitsigs-0.1.0-0.b53eb68-checkout.drv >> > >> > and it is unexpected. >> >> That running ‘hg clone’ requires Mercurial isn’t totally unexpected to >> me. :-) > > There is a misunderstanding, I guess. > > Running 'hg clone' requires to have a local copy of Mercurial, yes for sure. > :-) > > However, just ask what it will run (please note the dash d in guix > build -S -d hg-commitsigs) must not require to have a local copy of > Mercurial (binary). If you still think yes, why is it not the case > for fixed-output derivations relying on the old Git builder? Oh sorry, I had missed the ‘-d’ bit. In this case, what’s happening is grafts: Guix downloads (or builds) Mercurial so it can compute its grafted derivation. >> Now, the ‘guix recover’ tool (or whatever you call it) you’re working on >> could create a different fixed-output derivation producing the same >> result but without using Mercurial; typically, the builder of that >> derivation would download from SWH. >> >> Does that make sense? > > Yes, it makes sense; see my very first attempt in [1] :-). [...] > 1: https://gitlab.com/zimoun/guix-drv Nice! Thanks, Ludo’.
bug#70339: Constructing hg-fetch fixed-output derivation requires Mercurial
Hi Ludo, On Fri, 12 Apr 2024 at 11:30, Ludovic Courtès wrote: > > $ guix build -S -d hg-commitsigs > > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% > > 3,7 MB will be downloaded: > > /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2 > > substituting /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2... > > downloading from > > https://ci.guix.gnu.org/nar/lzip/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2 > > ... > > mercurial-6.2.2 3.5MiB > > 529KiB/s 00:07 ▕██▏ 100.0% > > > > /gnu/store/pkb6zd9xfmxx6rsh4p7w3glh7xqg5sqy-hg-commitsigs-0.1.0-0.b53eb68-checkout.drv > > > > and it is unexpected. > > That running ‘hg clone’ requires Mercurial isn’t totally unexpected to > me. :-) There is a misunderstanding, I guess. Running 'hg clone' requires to have a local copy of Mercurial, yes for sure. :-) However, just ask what it will run (please note the dash d in guix build -S -d hg-commitsigs) must not require to have a local copy of Mercurial (binary). If you still think yes, why is it not the case for fixed-output derivations relying on the old Git builder? > > I think it comes from this part: > > > > (hg-fetch '#$(hg-reference-url ref) > >'#$(hg-reference-changeset ref) > >#$output > >#:hg-command (string-append #+hg "/bin/hg"))) > > > > from ’hg-fetch’ in (guix hg-download). Here the #+hg is not required > > because just before there is: [...] > Maybe, but one way or another, Mercurial is necessary. Again, I think it is a bug from #+hg instead of plain "hg". Having a local copy of Mercurial (binary) must not be required to just display the fixed-output derivation. For running this fixed-output derivation, yes for sure. > Now, the ‘guix recover’ tool (or whatever you call it) you’re working on > could create a different fixed-output derivation producing the same > result but without using Mercurial; typically, the builder of that > derivation would download from SWH. > > Does that make sense? Yes, it makes sense; see my very first attempt in [1] :-). But you cannot apply this strategy for fixed-output derivations relying on Mercurial. You need first to build Mercurial (and thus all the Python stack) just to display the fixed-output derivation. Then, yes once you have this fixed-output derivation, it is possible to manipulate it for getting another one. This report is about #+hg that needs to be fixed for the future. And because of that, the strategy above for fixed-output derivations relying on Mercurial is doomed for the past, IMHO. Except if you have an idea. ;-) Cheers, simon 1: https://gitlab.com/zimoun/guix-drv
bug#70258: FreeCAD dependency probably outdated
I'm unable to build python-pivy with the suggested changes. Here is the
actual diff I used:
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 92566abfed..8c8b162b55 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -32389,43 +32389,42 @@ (define-public python-retry
(define-public python-pivy
(package
(name "python-pivy")
-(version "0.6.5")
+(version "0.6.9.a0")
(source
- (origin
-(method git-fetch)
-(uri (git-reference
- (url "https://github.com/coin3d/pivy;)
- (commit version)))
-(file-name (git-file-name name version))
-(sha256
- (base32 "0vids7sxk8w5vr73xdnf8xdci71a7syl6cd35aiisppbqyyfmykx"
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/coin3d/pivy;)
+ (commit version)))
+ (file-name (git-file-name name version))
+ (sha256
+(base32 "13v9bfmipfhjbwnrl96d82fgb317j2sijgpzhhk02390649qbx6c"
(build-system python-build-system)
(arguments
- `(;; The test suite fails due to an import cycle between 'pivy' and '_coin'
-#:tests? #f
-#:phases
-(modify-phases %standard-phases
- (add-after 'unpack 'patch-cmake-include-dirs
+ `( ;; The test suite fails due to an import cycle between 'pivy' and '_coin'
+ #:tests? #f
+ #:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'patch-cmake-include-dirs
(lambda _
- ;; Patch buildsystem to respect Coin3D include directory
- (substitute* "CMakeLists.txt"
- (("\\$\\{SoQt_INCLUDE_DIRS}")
- "${Coin_INCLUDE_DIR};${SoQt_INCLUDE_DIRS}"))
- #t)
+ ;; Patch build system to respect Coin3D include directory
+ (substitute* "interfaces/CMakeLists.txt"
+ (("\\$\\{SoQt_INCLUDE_DIRS\\}")
+"${Coin_INCLUDE_DIR};${SoQt_INCLUDE_DIRS}")))
(native-inputs
- (list cmake swig))
+ (list cmake swig))
(inputs
- (list python-wrapper
-qtbase-5
-libxi
-libice
-soqt
-glew
-coin3D))
+ (list python-wrapper
+ qtbase-5
+ libxi
+ libice
+ soqt
+ glew
+ coin3D))
(home-page "https://github.com/coin3d/pivy;)
(synopsis "Python bindings to Coin3D")
(description
- "Pivy provides python bindings for Coin, a 3D graphics library with an
+ "Pivy provides python bindings for Coin, a 3D graphics library with an
Application Programming Interface based on the Open Inventor 2.1 API.")
(license license:isc)))
I get lots of errors like these:
--8<---cut here---start->8---
interfaces/coin_header_includes.h:662: Error: Unable to find
'Inventor/VRMLnodes/SoVRMLViewpoint.h'
interfaces/coin_header_includes.h:663: Error: Unable to find
'Inventor/VRMLnodes/SoVRMLVisibilitySensor.h'
interfaces/coin_header_includes.h:664: Error: Unable to find
'Inventor/VRMLnodes/SoVRMLWorldInfo.h'
/gnu/store/ivbbmgrvhdc46p2ywx1x2zsmal3x0z5n-soqt-1.6.0-1.fb8f655/include/Inventor/Qt/devices/SoQtDevice.h:66:
Error: Unable to find 'Inventor/SbLinear.h'
/gnu/store/ivbbmgrvhdc46p2ywx1x2zsmal3x0z5n-soqt-1.6.0-1.fb8f655/include/Inventor/Qt/SoQtObject.h:40:
Error: Unable to find 'Inventor/SbBasic.h'
--8<---cut here---end--->8---
--
Ricardo
bug#70349: Clang fails to communicate RUNPATH?
Hi Guix,
I've noticed a strange error when attempting to build my software
against clang-toolchain. I've attached a minimally breaking example,
but the gist of it is that RUNPATH validation fails as shown below.
starting phase `validate-runpath'
validating RUNPATH of 1 binaries in
"/gnu/store/sd1zjjf13mi448qbqaphhcvf9ap5jxji-why-hello-0/bin"...
/gnu/store/sd1zjjf13mi448qbqaphhcvf9ap5jxji-why-hello-0/bin/hello:
error: depends on 'libfmt.so.9', which cannot be found in RUNPATH
("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib")
Is this expected? I know that the -for-system have historically
disregarded the existence of clang-toolchain and hence led to issues,
but I think this is something else…
Cheers
(use-modules (gnu packages pretty-print)
(gnu packages pkg-config)
(guix packages)
(guix gexp)
(guix transformations)
(guix build-system meson)
((guix licenses) #:select (gpl3+))
((guix git-download) #:select (git-file-name))
(srfi srfi-26))
(define why-hello
(package
(name "why-hello")
(version "0")
(source (file-union (git-file-name name version)
`(("hello.cpp" ,(plain-file "hello.cpp"
"\
#include
int
main()
{
fmt::print (\"{}\\n\", \"Hello, world\");
return 0;
}
"))
("meson.build" ,(plain-file "meson.build"
"\
project('hello', 'cpp', default_options: ['cpp_std=c++20'])
executable('hello', files('hello.cpp'), install: true,
dependencies: [dependency('fmt')])
")
(build-system meson-build-system)
(inputs (list fmt))
(native-inputs (list pkg-config))
(home-page (and=> (current-filename)
(cute string-append "file://" <>)))
(synopsis "Hello world")
(description "This package provides a simple program that builds with
GCC/G++ normally, but fails miserably when the clang-toolchain is used.")
(license gpl3+)))
(define why-hello-clang
((options->transformation
'((with-c-toolchain . "why-hello=clang-toolchain")))
why-hello))
why-hello-clang
bug#59365: make-dynamic-linker-cache OOMs for LLVM 15 on i686-linux
Hello, Ludovic Courtès skribis: >> GC Warning: Failed to expand heap by 285216768 bytes >> GC Warning: Failed to expand heap by 268439552 bytes >> GC Warning: Out of Memory! Heap size: 3620 MiB. Returning NULL! >> Warning: Unwind-only out of memory exception; skipping pre-unwind handler. >> Warning: Unwind-only out of memory exception; skipping pre-unwind handler. >> Warning: Unwind-only out of memory exception; skipping pre-unwind handler. >> >> (excerpt from https://ci.guix.gnu.org/build/1702995/log/raw) >> >> Not sure why this phase uses so much memory. Ideas? > > Yes: the gremlin.scm code uses ‘file-dynamic-info’, which loads the > whole file in memory. Ridiculous. > > We should instead mmap it (but there are no ‘mmap’ bindings in Guile, > yet) or arrange to load just the relevant parts (we’ll have to check but > maybe ‘file-dynamic-info’ can find everything it needs at the beginning > of a file, the PT_DYNAMIC segment.) Another instance of the problem that we just stumbled upon is ‘guix pack -RR’: that too tries to load entire ELF files in memory, in ‘elf-loader-compile-flags’. Mmap! Ludo’.
bug#70339: Constructing hg-fetch fixed-output derivation requires Mercurial
Hello!
Simon Tournier skribis:
> $ guix build -S -d hg-commitsigs
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> 3,7 MB will be downloaded:
> /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2
> substituting /gnu/store/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2...
> downloading from
> https://ci.guix.gnu.org/nar/lzip/6fya762sz5hjdj04vdn5g3v6zii6f11d-mercurial-6.2.2
> ...
> mercurial-6.2.2 3.5MiB
> 529KiB/s 00:07 ▕██▏ 100.0%
>
> /gnu/store/pkb6zd9xfmxx6rsh4p7w3glh7xqg5sqy-hg-commitsigs-0.1.0-0.b53eb68-checkout.drv
>
>
> and it is unexpected.
That running ‘hg clone’ requires Mercurial isn’t totally unexpected to
me. :-)
> I think it comes from this part:
>
> (hg-fetch '#$(hg-reference-url ref)
>'#$(hg-reference-changeset ref)
>#$output
>#:hg-command (string-append #+hg "/bin/hg")))
>
> from ’hg-fetch’ in (guix hg-download). Here the #+hg is not required
> because just before there is:
>
> (set-path-environment-variable "PATH" '("bin")
>(match '#+inputs
> (((names dirs outputs ...) ...)
> dirs)))
Maybe, but one way or another, Mercurial is necessary.
Now, the ‘guix recover’ tool (or whatever you call it) you’re working on
could create a different fixed-output derivation producing the same
result but without using Mercurial; typically, the builder of that
derivation would download from SWH.
Does that make sense?
HTH,
Ludo’.
bug#57836: fzf 0.33.0 release commit fails to build
Hi, Thank you for reporting this, I thinks this issue is outdated as fzf is on 0.41.0 since 767edbb6fe781d19c19971f2ccd3b0da8fd053fc in master branch. Current upstream version is 0.49.0 to wic we may bump it. Closing as no more relevant. -- Oleg signature.asc Description: PGP signature
