Re: guix import doesn't like newlines anymore :(
On Fri, 16 Sep 2022 07:31:45 +0200 zimoun wrote: hi, > For which importer? rust but Ithink I've experienced it with others also iirc try to test `guix import crate just -r`
Re: guix import doesn't like newlines anymore :(
Hi, On Thu, 15 Sep 2022 at 19:10, jgart wrote: > Hi does anyone know why guix import does not insert newlines anymore? For which importer? Cheers, simon
guix import doesn't like newlines anymore :(
Hi does anyone know why guix import does not insert newlines anymore? Is there a thread somewhere for that that I have missed? #+
Guix and Coleslaw Home Recipe!
jgart ponders to self: Will this package build the `coleslaw` CLI command with our current asdf-build-system? What's missing? https://github.com/coleslaw-org/coleslaw Here's my attempt but there's no executable in the store for `coleslaw`: https://git.sr.ht/~whereiseveryone/guixrus/commit/9f8a48141c5e6c4bcdde21164db733c66d189724 Guillaume, what do you think if I add documentation or a tutorial somewhere for how to deal with common lisp packages that require to build an executable? Before I do that though, I'd like to first understand fully what I'll be writing about ;() any advice much appreciated, jgart
Re: Updating minetest to 5.6.0?
> No, Guix does collective maintenance, and AFAIK nobody has made a patch > yet or volunteered to keep track of Minetest packages. If you have a > patch, you can simply sent it. Will do that soon once I sort other things out. > You can compile them: > > $ ./pre-inst-env guix build minetest minetest-worldedit minetest-... I did successfully compile the game, mineclone2, and some other mods. Generally the game works, mineclone2 (a subgame) works and is visible. > The minetest-mod-build-system has some (very basic) tests for testing > that the mods at least load with the new Minetest. About that, I can never see mods installed with Guix in Minetest. Is the build system really working as intended? I'm running the latest Guix. Am I missing something? I don't see the mods on the current version nor the latest I packaged. I tried installing a mod by force installing it into "share/minetest/mods/modname" using the copy-build-system just like mineclone2 is installed, but it doesn't work this way. Any ideas what's wrong? > For some additional testing, you could create a new world (creative > mode), enable all the mods, place blocks of various mods, testing things > out. >> Should I also update games and mods? > If you want to, but I would say it's only required if otherwise the > mods > fail to load or are otherwise broken by the update. > Greetings, > Maxime. Jan WielkiewiczTemat: Re: Updating minetest to 5.6.0? Data: 2022-09-15 20:25 Nadawca: "Maxime Devos" maximede...@telenet.be> Adresat: "Jan" tona_kosmicznego_smie...@interia.pl>; guix-devel@gnu.org; > >> > > On 15-09-2022 19:59, Jan wrote: >> Hello, >> >> I almost effortlessly updated the minetest package to 5.6.0 so I wonder if there's a person who is in charge of updating minetest-related stuff or should I just send the patch? > > No, Guix does collective maintenance, and AFAIK nobody has made a patch > yet or volunteered to keep track of Minetest packages. If you have a > patch, you can simply sent it. > >> Is there any test procedure for minetest mods and games? > > You can compile them: > > $ ./pre-inst-env guix build minetest minetest-worldedit minetest-... > > The minetest-mod-build-system has some (very basic) tests for testing > that the mods at least load with the new Minetest. > > For some additional testing, you could create a new world (creative > mode), enable all the mods, place blocks of various mods, testing things > out. > >> Should I also update games and mods? > > If you want to, but I would say it's only required if otherwise the mods > fail to load or are otherwise broken by the update. > > Greetings, > Maxime. > >
Re: What build system would be more appropriate for this application
Hello Luis Felipe, On Tuesday, September 6th, 2022 at 22:54, Luis Felipe wrote: > This way, the package builds and I'm able to run the application in a guix > shell. However, as the comments above indicate, I'd like to > > 1. Indicate the destination for the "mazo" Python package using > GUIX_PYTHONPATH instead of the hardcoded path. > 2. Make sure the "bin/mazo" file is executable (the source, "mazo.py", is > executable, though). > 3. Run tests > > Do you think I can achieve these sticking to the copy-build-system, or would > it be necessary to resort to meson or similar build systems? I found that using the python-build-system was more appropriate after all, even though the application doesn't use setuputils or anything like that. To address problem (1), I found that once you use the python-build-system, a "site-packages" procedure becomes available. It returns the appropriate path were to place Python packages. The "site-packages" procedure is not documented in the manual, though. The procedure is defined in the module "(guix build python-build-system)". Grepping for "site-packages" in Guix package definitions shows lots of examples. To address problem (2), there's Guile's "chmod" procedure. For example: (chmod "myscript" #o555). Plenty of examples in Guix packages too. As for (3), I could replace the check phase normally, in the same way it is done in many package definitions. So now I have a package definition I will be sending soon for review :) publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Updating minetest to 5.6.0?
I'm also working on a VR version of minetest, I'll plan to package that one too.
Re: Updating minetest to 5.6.0?
On 15-09-2022 19:59, Jan wrote: Hello, I almost effortlessly updated the minetest package to 5.6.0 so I wonder if there's a person who is in charge of updating minetest-related stuff or should I just send the patch? No, Guix does collective maintenance, and AFAIK nobody has made a patch yet or volunteered to keep track of Minetest packages. If you have a patch, you can simply sent it. Is there any test procedure for minetest mods and games? You can compile them: $ ./pre-inst-env guix build minetest minetest-worldedit minetest-... The minetest-mod-build-system has some (very basic) tests for testing that the mods at least load with the new Minetest. For some additional testing, you could create a new world (creative mode), enable all the mods, place blocks of various mods, testing things out. > Should I also update games and mods? If you want to, but I would say it's only required if otherwise the mods fail to load or are otherwise broken by the update. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Updating minetest to 5.6.0?
Hello, I almost effortlessly updated the minetest package to 5.6.0 so I wonder if there's a person who is in charge of updating minetest-related stuff or should I just send the patch? Is there any test procedure for minetest mods and games? Should I also update games and mods? I ask because last time when there was a major minetest update (Irrlicht fork) someone did the job faster than me and I ended up wasting my time. By the way I'm back and alive after the pandemic madness and other things that kept me "busy" (depressed), so I might contribute to Guix more often from now on :) Jan Wielkiewicz
Re: substitute derivation: also substitute grafts?
On 15-09-2022 19:43, Csepp wrote: Could we store the offsets of references somewhere at build time? I now remember that idea, I forgot about that one. My answer: I don't see why not, maybe by adding a phase to %standard-phases (at the very end, to avoid it becoming invalid) that saves it in, say, OUTPUT/.graft-offsets? That would avoid grafting files that don't even have any references, where a copy-file (maybe using copy_file_range or such when available) would suffice. Fallbacks might be necessary (not every store item is constructed from a package), but it all sounds doable and efficient. Also the union could needs to be modified to ignore the .graft-offsets of the union'ed things. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: substitute derivation: also substitute grafts?
Maxime Devos writes: > [[PGP Signed Part:Undecided]] > > > On 15-09-2022 16:46, Csepp wrote: >> Ricardo Wurmus writes: >> >>> [...] >>> Did I say *all items*? Well, … grafts are not included, because >>> graft >>> derivations are marked as not substitutable. >>> >>> Can we change that conditionally? I would really like to avoid >>> having >>> to build grafts on B when they have already been built on A. >> I would love this too, because IO can be incredibly slow on HDDs and >> large packages. My netbook would be thankful. >> > > There are some some opportunities for optimizations in the grafting > code before substituting more -- for example, to avoid seek times, it > would be possible to rewrite multiple files concurrently (maybe using > 'par-for-each' to process each file in a directory in parallel). > > This is already done in (guix build grafts), except that: > > * 'find-files' itself is not parallelised, even though parallelising it > could potentially reduce the time spent seeking (*) > * it uses (parallel-job-count), which is (IIUC) 1 by default because >--cores=1 by default. As grafts are more IO intensive than CPU >intensive, maybe it would be reasonable to impose a _minimum_ amount >of parallelism, I don't, know, 2 or 4 or so? > > (I'm assuming the main problem here is seek times.) > > Also combinable with the proposal of having substitutes for grafts. > > Greetings, > Maxime. > > (*) IIUC, the time for N parallel seeks should, in theory, ≃ 1 seek, > for small values of N, because of elevator algorithms. > > [2. OpenPGP public key --- application/pgp-keys; > OpenPGP_0x49E3EE22191725EE.asc]... > > [[End of PGP Signed Part]] Could we store the offsets of references somewhere at build time?
Re: substitute derivation: also substitute grafts?
On 15-09-2022 16:46, Csepp wrote: Ricardo Wurmus writes: [...] Did I say *all items*? Well, … grafts are not included, because graft derivations are marked as not substitutable. Can we change that conditionally? I would really like to avoid having to build grafts on B when they have already been built on A. I would love this too, because IO can be incredibly slow on HDDs and large packages. My netbook would be thankful. There are some some opportunities for optimizations in the grafting code before substituting more -- for example, to avoid seek times, it would be possible to rewrite multiple files concurrently (maybe using 'par-for-each' to process each file in a directory in parallel). This is already done in (guix build grafts), except that: * 'find-files' itself is not parallelised, even though parallelising it could potentially reduce the time spent seeking (*) * it uses (parallel-job-count), which is (IIUC) 1 by default because --cores=1 by default. As grafts are more IO intensive than CPU intensive, maybe it would be reasonable to impose a _minimum_ amount of parallelism, I don't, know, 2 or 4 or so? (I'm assuming the main problem here is seek times.) Also combinable with the proposal of having substitutes for grafts. Greetings, Maxime. (*) IIUC, the time for N parallel seeks should, in theory, ≃ 1 seek, for small values of N, because of elevator algorithms. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: substitute derivation: also substitute grafts?
Ricardo Wurmus writes: > Hi Guix, > > I really like the fact that Guix can substitute derivations. It’s a > great way to transfer a profile from one powerful machine to a weak > machine without having to set up SSH for “guix copy” first. > > I just build a profile on machine A, and then on the weak machine B I > do > > guix build --substitute-urls="http://A:8000; > /gnu/store/…-profile.drv > > and all items for that profile are copied to B. > > Did I say *all items*? Well, … grafts are not included, because graft > derivations are marked as not substitutable. > > Can we change that conditionally? I would really like to avoid having > to build grafts on B when they have already been built on A. I would love this too, because IO can be incredibly slow on HDDs and large packages. My netbook would be thankful.
substitute derivation: also substitute grafts?
Hi Guix, I really like the fact that Guix can substitute derivations. It’s a great way to transfer a profile from one powerful machine to a weak machine without having to set up SSH for “guix copy” first. I just build a profile on machine A, and then on the weak machine B I do guix build --substitute-urls="http://A:8000; /gnu/store/…-profile.drv and all items for that profile are copied to B. Did I say *all items*? Well, … grafts are not included, because graft derivations are marked as not substitutable. Can we change that conditionally? I would really like to avoid having to build grafts on B when they have already been built on A. -- Ricardo PS: please keep me in Cc as I’m not subscribed to guix-devel at the moment.
OpenVR in Guix
I saw that Guix includes OpenVR[1], which is kind of problematic, because there is no libre compatible runtime. I have a Valve Index, which I use without Steam[2], using the libre runtime Monado, which currently only supports OpenXR[3], but I plan to add a nonsteam OpenVR runtime to Monado. So I think there is no need to remove OpenVR. In Debian this packages is in contrib, because of the SteamVR dependency. [1]https://guix.gnu.org/en/packages/openvr-1.8.19/ [2]https://www.gnu.org/philosophy/nonfree-games.html [3]https://guix.gnu.org/en/packages/openxr-1.0.24/
My first package
Hello,
I've created my first package for guix, the sekai speech synthesis
toolkit which I use mainly for producing singing voice with lilypond.
I'll also plan a talk at the gnu hackers meeting how I make Desktop
Music using the Guix System. Two more packages will follow next.
Tobias Alexandra
diff --git a/gnu/packages/speech.scm b/gnu/packages/speech.scm
index 042c157e43..cc0b03d110 100644
--- a/gnu/packages/speech.scm
+++ b/gnu/packages/speech.scm
@@ -31,11 +31,14 @@ (define-module (gnu packages speech)
#:use-module (guix git-download)
#:use-module (guix utils)
#:use-module (guix build-system gnu)
+ #:use-module (guix build-system cmake)
#:use-module (gnu packages)
#:use-module (gnu packages audio)
+ #:use-module (gnu packages algebra)
#:use-module (gnu packages autotools)
#:use-module (gnu packages base);for 'which'
#:use-module (gnu packages bison)
+ #:use-module (gnu packages boost)
#:use-module (gnu packages compression)
#:use-module (gnu packages documentation)
#:use-module (gnu packages emacs)
@@ -44,15 +47,18 @@ (define-module (gnu packages speech)
#:use-module (gnu packages glib)
#:use-module (gnu packages gstreamer)
#:use-module (gnu packages linux)
+ #:use-module (gnu packages maths)
#:use-module (gnu packages ncurses)
#:use-module (gnu packages perl)
#:use-module (gnu packages pkg-config)
#:use-module (gnu packages pulseaudio)
#:use-module (gnu packages python)
+ #:use-module (gnu packages serialization)
#:use-module (gnu packages swig)
#:use-module (gnu packages texinfo)
#:use-module (gnu packages textutils))
+
(define-public flite
(package
(name "flite")
@@ -318,6 +324,33 @@ (define-public sonic
(home-page "https://github.com/waywardgeek/sonic;)
(license license:asl2.0)))
+(define-public sekai
+ (package
+(name "sekai")
+(version "0.6.0")
+(source (origin
+ (method git-fetch)
+ (uri (git-reference
+(url "https://notabug.org/isengaara/sekai;)
+(commit "0.6rc0")))
+ (sha256
+ (base32
+"0j55pipx3hcp0xl4v0d72fdwysnz9a9a40x65a9lxpl4k6wyp4nm"
+(build-system cmake-build-system)
+(arguments '(#:tests? #f))
+(inputs `(("fftw" ,fftw)
+ ("libsndfile",libsndfile)
+ ("pkg-config",pkg-config)
+ ("gsl",gsl)
+ ("jsoncpp",jsoncpp)
+ ("boost",boost)
+ ("jack" ,jack-1)
+ ))
+(synopsis "The SEKAI speech toolkit")
+(description "The future of Singing Voice Synthesis using the Excitation plus Resonances model.")
+(home-page "https://qtau.de/sekai;)
+(license license:agpl3+)))
+
(define-public festival
(package
(name "festival")
