bug#70886: Packaging a gradle application
After 1.0.0, I'm able to build one more version, but it is not built properly, as it's not able to build ittelf or any other version. There's probably something wrong with one of the dependencies, but it's hard to say what and which one exactly. One way to test would be to rebuild with the shipped jar dependencies and see if we can get further, then figure out which is responsible for the issue. It's very time consumming though. Le 12 mai 2024 20:57:12 GMT+02:00, Nicolas Graves a écrit : > >Hi Noé, > >Regarding Gradle, IIRC, the main hinderance to get that into Guix is the >extremely costly bootstrap process through which its building blocks (in >particular recent Kotlin versions) can be built. > >The work on this is mainly done by Julien Lepiller in channel >guix-android : >https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/kotlin.scm > >He managed to get kotlin v1.0.0 to work but there was another >hurdle IIRC, I can't tell you more, but maybe Julien can. > >There's still quite some work to do before we're able to write and use a >gradle-build-system. If you have a lot of computer power, don't hesitate >to take a look there. > >There's also more info disseminated in the mailing list. >
bug#70886: Packaging a gradle application
Hi Noé, Regarding Gradle, IIRC, the main hinderance to get that into Guix is the extremely costly bootstrap process through which its building blocks (in particular recent Kotlin versions) can be built. The work on this is mainly done by Julien Lepiller in channel guix-android : https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/kotlin.scm He managed to get kotlin v1.0.0 to work but there was another hurdle IIRC, I can't tell you more, but maybe Julien can. There's still quite some work to do before we're able to write and use a gradle-build-system. If you have a lot of computer power, don't hesitate to take a look there. There's also more info disseminated in the mailing list. -- Best regards, Nicolas Graves
bug#66866: Grafting breaks cross-compilation
Hello, I think I finally understand why the problem only occurs with grafts if a dependency uses copy-build-system. It is actually somewhat complicated. When a package is lowered into a derivation by 'package->derivation' in guix/packages.scm, a list of potentially applicable grafts is created by the 'bag-grafts' procedure. This works by first traversing the bag for native packages (where bag-build-inputs and bag-target-inputs are followed recursively; and also bag-host-inputs if not cross building) and building the native derivations of the grafted versions of the packages which have a replacement (such as glibc at the time of writing). Building the grafted package (in the 'input-graft' procedure) is done again with 'package->derivation', which eventually calls 'graft-derivation' in guix/grafts.scm, which in turn calls 'non-self-references', where the ungrafted package is actually built (ignoring the store monad indirection), not just its derivation. In the case of cross builds, the bag is also traversed for the target dependencies, where the bag-host-inputs are followed recursively. Analogously, this causes the ungrafted packages and their ungrafted replacement to be cross built to compute the grafted derivations. As dan found out, the 'lower' procedure in guix/build-system/copy.scm incorrectly puts standard-packages into the host inputs. They contain the glibc-final package in gnu/packages/commencement.scm (which inherits the replacement of glibc). Because copy-build-system puts them into bag-host-inputs, the package replacement of the glibc-final package is then cross built without grafts when calculating its grafted derivation, which it does not support. Note that the glibc-final package and its package replacement are distinct from the glibc package and its replacement in gnu/packages/base.scm. I confirmed this by running --8<---cut here---start->8--- ,use (guix) (with-store store (run-with-store store (package->cross-derivation (package-replacement (@@ (gnu packages commencement) glibc-final)) "i686-linux-gnu" #:graft? #f))) --8<---cut here---end--->8--- in the REPL, which returns the same incorrect glibc derivation that is attempted to be built as a dependency when running `guix build alsa-lib --target=i686-linux-gnu`. It is actually possible to compute the graft derivations only when needed by a store reference (which does not change the derivation of the grafted package). Then, this problem does not occur even without the fix for the copy-build-system, as the invalid derivations are never actually built. With substitutes or after running GC, this may even prevent building a package with replacement when the requested package output which (transitively) depends on it has no (transitive) store reference to it. I made a patch for that here: https://issues.guix.gnu.org/70895 Regarding the changes to the copy-build-system: Ludovic Courtès writes: > But still, there seem to be some expectation that ‘copy-build-system’ > can support cross-compilation for real, so maybe we should add a > ‘copy-cross-build’ procedure in addition to the patch above. In guix/build-system/copy.scm, it is described as an extension of gnu-build-system and the manual says "It adds much of the gnu-build-system packages to the set of inputs. Because of this, the copy-build-system does not require all the boilerplate code often needed for the trivial-build-system." Therefore, I think it makes sense to add the copy-cross-build procedure so that copy-build-system actually behaves like gnu-build-system. Cheers, David
bug#70897: Guix system hangs on boot with LUKS root partition
Hi Ludo' and others, I recently updated my systems after finally finding https://issues.guix.gnu.org/70051 and seeing the issue I was having with booting with a non-root LUKS partition configured had been fixed. After updating to a commit past these two: 49f82fca41 mapped-devices: luks: Specify modules needed at the top-level. 6062339156 mapped-devices: can specify modules to import. I am now seeing a different error, which I am pretty sure is related to the module import changes in 49f82fca41. The error I get is about an unknown symbol "system*/tty" when the initramfs tries to prompt for a password to unlock the LUKS partition containing the root filesystem. I don't know how the module plumbing of Shepherd and the generated initramfs work, but I suspect the fix for Shepherd opening LUKS partition broke the import of system*/tty in the initramfs (for example, at the early REPL that booting my latest system generation ends up at, system*/tty is undefined initially, but after evaluating "(use-modules (gnu build file-systems))" system*/tty resolves to a procedure as exected--so the module is at least present in the initramfs). I have encountered this error with two different systems, and I believe the reproduction is simply trying to open a LUKS device without a keyfile so that a password prompt is necessary. Cheers, Kaelyn
bug#70877: guix-daemon fails to copy 4+GB file to store
On Sat, May 11, 2024 at 12:52:53PM +0200, Ricardo Wurmus wrote: > The guix-daemon's libutil/util.cc uses copy_file_range to copy a > downloaded file into the store. copy_file_range fails on files larger > than 4GB with an error like this: > > guix build: error: short write in copy_file_range `15' to `16': No such > file or directory > > The man page for copy_file_range says that it could return EFBIG when > the range exceeds the maximum range. The daemon code does not check any > limits and will attempt to copy the whole file. > > I believe our code ought to check the value of st.size and fall back to > a boring copy if it exceeds some "reasonable" value. > > This is where copy_file_range is used: > https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libutil/util.cc#n382 > > Here is a little reproducer: > > (use-modules (guix download) > (guix packages) > (guix build-system trivial)) > > (package > (name "chungus") > (version "1") > (source >(origin > (method url-fetch) > (uri "http://localhost:/chungus;) > (sha256 > (base32 "0nx67d4ls2nfwcfdmg81vf240z6lpwpdqypssr1wzn3hyz4szci4" > (build-system trivial-build-system) > (home-page "") > (synopsis "") > (description "") > (license #f)) > > --8<---cut here---start->8--- > # generate a big file > dd bs=1M count=4096 if=/dev/zero of=/tmp/chungus > # serve it > guix shell woof -- woof -i 127.0.0.1 -p -c 1 /tmp/chungus > # build the source derivation > guix build --no-grafts -Sf bug.scm > # observe the error > # guix build: error: short write in copy_file_range `15' to `16': No such > file or directory > --8<---cut here---end--->8--- > This sounds like a similar failure to bug 65714 that I ran into with guix copy, but I wasn't able to diagnose it. https://issues.guix.gnu.org/65714 -- 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
