Re: Missing substitutes and TIMEOUT property (Racket, MAME)
Leo Famulari writes: > The logs of the failing builds should say if the failure was caused by > timeout or exceeding the maximum "silent time" (time without any output > from the build). If I look at failed builds for Racket or MAME, I get this: http://ci.guix.gnu.org/build/2290964/details http://ci.guix.gnu.org/build/2293173/details It says --8<---cut here---start->8--- Status Failed (dependency) --8<---cut here---end--->8--- and does not have any logs. Something is fishy. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Game package requests: Tesseract, Warsow, Unvanquished (needs pnacl)
Sadly this is outdated and the Debian script does not seem to deal with the data under CC-ND-4.0 :( -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: [bug#39825] [PATCH] gnu: Add warsow-qfusion.
I'm trying to use commit c4de15df559410aff0ca6643724e24cddb0ecbbd as suggested upstream (https://github.com/Warsow/qfusion/issues/46#issuecomment-592940682) but git-fetch fails with --8<---cut here---start->8--- Submodule 'libsrcs' (https://github.com/Warsow/qfusion-libsrcs.git) registered for path 'libsrcs' Submodule 'third-party/angelscript' (https://github.com/Qfusion/angelscript.git) registered for path 'third-party/angelscript' Submodule 'third-party/libRocket' (https://github.com/Qfusion/libRocket) registered for path 'third-party/libRocket' Submodule 'third-party/openal-soft' (https://github.com/Warsow/openal-soft.git) registered for path 'third-party/openal-soft' Submodule 'third-party/recastnavigation' (https://github.com/Warsow/recastnavigation.git) registered for path 'third-party/recastnavigation' Submodule 'third-party/sqlite-amalgamation' (https://github.com/Warsow/sqlite-amalgamation.git) registered for path 'third-party/sqlite-amalgamation' Cloning into '/gnu/store/l4bjqp1yjkx0hczz0y2i9h0gzayfdx11-warsow-qfusion-2.5-1.c4de15d-checkout/libsrcs'... Cloning into '/gnu/store/l4bjqp1yjkx0hczz0y2i9h0gzayfdx11-warsow-qfusion-2.5-1.c4de15d-checkout/third-party/angelscript'... Cloning into '/gnu/store/l4bjqp1yjkx0hczz0y2i9h0gzayfdx11-warsow-qfusion-2.5-1.c4de15d-checkout/third-party/libRocket'... Cloning into '/gnu/store/l4bjqp1yjkx0hczz0y2i9h0gzayfdx11-warsow-qfusion-2.5-1.c4de15d-checkout/third-party/openal-soft'... Cloning into '/gnu/store/l4bjqp1yjkx0hczz0y2i9h0gzayfdx11-warsow-qfusion-2.5-1.c4de15d-checkout/third-party/recastnavigation'... Cloning into '/gnu/store/l4bjqp1yjkx0hczz0y2i9h0gzayfdx11-warsow-qfusion-2.5-1.c4de15d-checkout/third-party/sqlite-amalgamation'... Submodule path 'libsrcs': checked out 'd3c01feeed14aa2f24c1839fedfb43b4c38a3412' Submodule path 'third-party/angelscript': checked out '478944145ce6d278abc2a119355c425b332482df' error: Server does not allow request for unadvertised object 867fc72f980b40325c35d2a9182f741e8e0ca876 Fetched in submodule path 'third-party/libRocket', but it did not contain 867fc72f980b40325c35d2a9182f741e8e0ca876. Direct fetching of that commit failed. git-fetch: '/gnu/store/zm51w1zv9zchx3n3xjw81zrjnlaswawa-git-minimal-2.25.1/bin/git submodule update --init --recursive' failed with exit code 1 --8<---cut here---end--->8--- Indeed, 867fc72f980b40325c35d2a9182f741e8e0ca876 does not exist in libRocket, so I suspect it was removed, but isn't Git supposed to fetch master? Where did it guess this commit from. I don't understand how this is possible. The .gitmodules file is --8<---cut here---start->8--- [submodule "third-party/libRocket"] path = third-party/libRocket url = https://github.com/Qfusion/libRocket [submodule "third-party/angelscript"] path = third-party/angelscript url = https://github.com/Qfusion/angelscript.git [submodule "third-party/recastnavigation"] path = third-party/recastnavigation url = https://github.com/Warsow/recastnavigation.git [submodule "third-party/openal-soft"] path = third-party/openal-soft url = https://github.com/Warsow/openal-soft.git [submodule "third-party/sqlite-amalgamation"] path = third-party/sqlite-amalgamation url = https://github.com/Warsow/sqlite-amalgamation.git [submodule "libsrcs"] path = libsrcs url = https://github.com/Warsow/qfusion-libsrcs.git --8<---cut here---end--->8--- and --8<---cut here---start->8--- > git submodule status --recursive d3c01feeed14aa2f24c1839fedfb43b4c38a3412 libsrcs (d3c01fe) 478944145ce6d278abc2a119355c425b332482df third-party/angelscript (heads/master) +4889e4c100920cbd0fc9004566d6380771bd77a7 third-party/libRocket (release-1.2.1-1264-g4889e4c1) 6761218e51699f46bf25c377e65b3e9ea5e434b9 third-party/openal-soft (openal-soft-1.18.1-694-g6761218e) 2c85309280dbc9c82029e7ab16dfb01b9235c74e third-party/recastnavigation (1.5.0-78-g2c85309) bc1dd8284590b5092a9bed4deb80a49e01cfb911 third-party/sqlite-amalgamation (heads/master) --8<---cut here---end--->8--- I must be missing something about Git submodules... -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: [GSOC 2020] Idea: Guile based build-tool
Thanks for the link, Simon! --Leandro On Mon, 2 Mar 2020, 07:03 zimoun, wrote: > Dear, > > Perhaps, some inspiration about build systems in this paper [1] by > Haskellers. > > [1] > https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf > > > All the best, > simon >
python2 in git
Hi Guix,
our “git” package has python-2 among its inputs. It says this:
("python" ,python-2) ; CAVEAT: incompatible with python-3 according to
INSTALL
The INSTALL file for git 2.25.1 says this about Python:
- Python version 2.4 or later (but not 3.x, which is not
supported by Perforce) is needed to use the git-p4 interface
to Perforce.
The git-p4 script does, however, contain conditionals to accomodate
Python 3. Here’s an example:
--8<---cut here---start->8---
# support basestring in python3
try:
unicode = unicode
except NameError:
# 'unicode' is undefined, must be Python 3
str = str
unicode = str
bytes = bytes
basestring = (str,bytes)
else:
# 'unicode' exists, must be Python 2
str = str
unicode = unicode
bytes = str
basestring = basestring
--8<---cut here---end--->8---
It also uses the Python 3 style “print” call instead of the Python 2
style statement.
I would like to build git with the latest version of Python. Any
objections?
--
Ricardo
Re: python2 in git
Hi Ricardo!
On March 3, 2020 12:43:29 PM UTC, Ricardo Wurmus wrote:
>Hi Guix,
>
>our “git” package has python-2 among its inputs. It says this:
>
>("python" ,python-2) ; CAVEAT: incompatible with python-3 according to
>INSTALL
>
>The INSTALL file for git 2.25.1 says this about Python:
>
> - Python version 2.4 or later (but not 3.x, which is not
> supported by Perforce) is needed to use the git-p4 interface
> to Perforce.
>
>The git-p4 script does, however, contain conditionals to accomodate
>Python 3. Here’s an example:
>
>--8<---cut here---start->8---
># support basestring in python3
>try:
>unicode = unicode
>except NameError:
># 'unicode' is undefined, must be Python 3
>str = str
>unicode = str
>bytes = bytes
>basestring = (str,bytes)
>else:
># 'unicode' exists, must be Python 2
>str = str
>unicode = unicode
>bytes = str
>basestring = basestring
>--8<---cut here---end--->8---
>
>It also uses the Python 3 style “print” call instead of the Python 2
>style statement.
>
>I would like to build git with the latest version of Python. Any
>objections?
Good analysis! None from me!
Maxim
Re: python2 in git
Ricardo, Ricardo Wurmus 写道： I would like to build git with the latest version of Python. Any objections? Quite the opposite. Kind regards, T G-R signature.asc Description: PGP signature
Re: Missing substitutes and TIMEOUT property (Racket, MAME)
Pierre, Pierre Neidhardt 写道： Leo Famulari writes: The logs of the failing builds should say if the failure was caused by timeout or exceeding the maximum "silent time" (time without any output from the build). If I look at failed builds for Racket or MAME, I get this: http://ci.guix.gnu.org/build/2290964/details http://ci.guix.gnu.org/build/2293173/details It says --8<---cut here---start->8--- Status Failed (dependency) --8<---cut here---end--->8--- Cuirass should link to the failing dependencies for further inspection, but doesn't (yet?). You have to guess. It's fun. and does not have any logs. Since these builds were never attempted, they never produced any logs. I think that's the correct approach. This is also why blindly raising time-outs for these packages isn't the solution: there's nothing to time out. Something is fishy. Not fishy, just -ETODO. Kind regards, T G-R signature.asc Description: PGP signature
Re: Missing substitutes and TIMEOUT property (Racket, MAME)
Tobias Geerinckx-Rice 写道： Since these builds were never attempted, they never produced any logs. Not the same architecture, but here's a staging MAME that was built and killed without explanation after a non-magical-looking number of seconds: http://ci.guix.gnu.org/build/2337230/details I don't understand. There has to be a better way to query Cuirass than endlessly clicking ‘Next’… :-/ T G-R signature.asc Description: PGP signature
Re: Missing substitutes and TIMEOUT property (Racket, MAME)
Hello Tobias, Tobias Geerinckx-Rice ezt írta (időpont: 2020. márc. 3., Ke 15:35): > Tobias Geerinckx-Rice 写道： > > Since these builds were never attempted, they never produced any > > logs. > > Not the same architecture, but here's a staging MAME that was > built and killed without explanation after a non-magical-looking > number of seconds: > > http://ci.guix.gnu.org/build/2337230/details > > I don't understand. There has to be a better way to query Cuirass > than endlessly clicking ‘Next’… :- > You can try to get failing dependency information from the guix data service. Last time I checked that did work. It should list all the failed dependencies that failed directly. > > T G-R >
Re: Guix Data Services: whishlist about SWH
Hi, On Mon, 24 Feb 2020 at 18:10, Ludovic Courtès wrote: > >> Using the Software Heritage (SWH) API [3], does it seems a good idea > >> to add SWH coverage somewhere in the Guix Data Services? > > That’s a great idea! Maybe it’s not a good idea to store that info in > the database of the Data Service though. (Web browsers could query the > SWH API by themselves actually, though it’d be nice to have a JS-free > variant.) It is out of my skills. :-) What I have in mind is: 1. Green/red button like SWH stamp! :-) Green for archived in SWH and red for not yet, and maybe orange for scheduled. 2. A chart for the coverage. Well, the point 1. works at the package level and should be done entirely inside the webbrowser (modulo JS-free). However, point 2. cannot be checked on the fly, IMHO and so needs to be stored somewhere in the Data Service. I have no idea where to look to for example start something about the point 1. Clue accepted. ;-) > > I think the first step towards this would be to experiment with fetching > > data from the Software Heritage API. Do you know how you'd fetch data > > about the output from a fixed output derivation (like harfbuzz)? > > The ‘archival’ linter does that. See also the examples at: > > > https://guix.gnu.org/blog/2019/connecting-reproducible-deployment-to-a-long-term-source-code-archive/ Thank you for the pointer. I will try to find my way in the linter code. :-) Thinking about connections between Guix/Nix and SWH and discussing with lewo, it could be also nice to "push" for each evaluation of Cuirass all our upstream sources to the SWH listener. Well, the SWH listener is still a work-in-progress but currently it accepts something in the format of 'sources.json'. A patch implementing that is pending [1] and in the near future (after soonish the patch's review) this 'sources.json' will be produced by the Website... Hum? The question is then: what will produce this 'sources.json' file? Cuirass or Data Services? If I understand Clément's concern about Cuirass, he is not in favour to add too much Guix only features to Cuirass. So Cuirass does not seem the right place. Well, the Data Service could do that. For each evaluation, it produces this 'sources.json' file and it serves it a a place that the SWH listener could ingest and so schedule some fetching. There is still questions to minimize the resource consumption (more on SWH side than on our side), but that another story. In this case, Guix will be more robust, especially about time travelling. What do you think? [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39547#29 [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39547#35 All the best, simon
Re: [bug#39742] [PATCH 1/7] gnu: java-openjfx-build: Add helpful patch.
Hi
I packaged openjfx and would like to get some review. Can someone take a look?
Alexey Abramov writes:
> * gnu/packages/java.scm: Add patch
> * gnu/packages/patches/java-openjfx-build-get_guix_jdk_version.patch: New
> file. Allows you to run gradlew to run properly. Useful for debugging.
> ---
> gnu/packages/java.scm | 3 ++-
> .../java-openjfx-build-get_guix_jdk_version.patch | 14 ++
> 2 files changed, 16 insertions(+), 1 deletion(-)
> create mode 100644
> gnu/packages/patches/java-openjfx-build-get_guix_jdk_version.patch
>
> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
> index 9371901e1f..01541ee419 100644
> --- a/gnu/packages/java.scm
> +++ b/gnu/packages/java.scm
> @@ -2355,7 +2355,8 @@ new Date();"))
>(file-name (string-append name "-" version "-checkout"))
>(sha256
> (base32
> -"0yg38mwpivswccv9n96k06x3iv82i4px1a9xg9l8dswzwmfj259f"
> +"0yg38mwpivswccv9n96k06x3iv82i4px1a9xg9l8dswzwmfj259f"))
> + (patches (search-patches
> "java-openjfx-build-get_guix_jdk_version.patch"
> (build-system ant-build-system)
> (arguments
> `(#:jar-name "java-openjfx.jar"
> diff --git
> a/gnu/packages/patches/java-openjfx-build-get_guix_jdk_version.patch
> b/gnu/packages/patches/java-openjfx-build-get_guix_jdk_version.patch
> new file mode 100644
> index 00..214ef9949c
> --- /dev/null
> +++ b/gnu/packages/patches/java-openjfx-build-get_guix_jdk_version.patch
> @@ -0,0 +1,14 @@
> +--- a/build.gradle
> b/build.gradle
> +@@ -742,9 +742,9 @@
> + if (inStream.readLine() != null) {
> + String v = inStream.readLine();
> + if (v != null) {
> +-int ib = v.indexOf(" (build ");
> ++int ib = v.indexOf(" (guix build ");
> + if (ib != -1) {
> +-String ver = v.substring(ib + 8, v.size() - 1);
> ++String ver = v.substring(ib + 13, v.size() - 1);
> +
> + defineProperty("jdkRuntimeVersion", ver)
> + defineProperty("jdkVersion",
> jdkRuntimeVersion.split("-")[0])
--
Alexey
Re: Store channel specification in profile
On Tue, 25 Feb 2020 at 11:32, Pierre Neidhardt wrote: > Ludovic Courtès writes: > > (Note: we should remove the ‘sort’ call here as the order of packages in > > the manifest is significant when there are file collisions.) > > But the export is not an "internal manifest", it should not need to know > about package order, right? > > I sorted the export so that it produces a reproducible output, which is > more version-control friendly. IMHO, the sort would not be too expensive; even on all the packages that Guix already includes now. ;-) So, it does not matter too much, I guess. However, the manifest returned is not necessary functional because the pkg1@v1 and pkg2@v2 are not necessary provided by the same commit. Therefore we could imagine "options" to the '--export' command, as '--export=full' or '--export=light' etc. And even '--export=sorted' and maybe combined as '--export=light,sorted'. Cheers, simon
Re: Store channel specification in profile
Hi Ludo,
On Mon, 24 Feb 2020 at 17:16, Ludovic Courtès wrote:
> > ;; Thanks to Ivan Vilata-i-Balaguer for this:
> > (define (guix-commit)
> > (let ((guix-manifest (profile-manifest (string-append (getenv "HOME")
> > "/.config/guix/current"
> > (match (assq 'source (manifest-entry-properties (car (manifest-entries
> > guix-manifest
> > (('source ('repository ('version 0) _ _
> > ('commit commit) _ ...))
> >commit)
> > (_ #f
> >
> > (match (command-line)
> > ((_ where)
> >(format #t ";; commit: ~a\n" (guix-commit))
> >(pretty-print
> > `(specifications->manifest
> > ',(guix-manifest where
>
> Emitting channel info as comments like this, and/or a warning when
> there’s a conflict (packages coming from different commits of the same
> channel) could be done as a second step.
The snippet uses the last commit of "guix pull", right?
Or the commit of last installed package with "guix package -i"?
Even if it can be done as a second step, the commits of each installed
packages are IMHO the key point of the exporter. Because otherwise, I
am doing "guix package -I | cut" and I am almost done.
Cheers,
simon
Re: [GSOC 2020] Discussing GNU Guix project ideas?
Dear Leandro, On Wed, 26 Feb 2020 at 23:42, Leandro Doctors wrote: > I am interested in the Scheme-based ideas. (I have recently > rediscovered LISP, and I am a Clojure fan.) However, I haven't found > any indication on how to proceed in the Ideas page [1]. Elsewhere, you have been discussing a proposal of about "Guile build tool"; which IMHO a large and hard task. Based on your interests (Clojure, Leiningen, etc.), you should consider something around a Clojure "importer". (Note that I am ignorant about the Java ecosystem.) Currently, it is possible to import Python packages from PyPI, or Haskell packages from Hackage, or etc. see [1] and something about Clojure seems missing. I am quoting Ludo from [2]: --8<---cut here---start->8--- Now we should keep in touch with the Clojure folks to work on an importer (I learned about “tools.deps”) and to get Clojupyter packaged… --8<---cut here---end--->8--- and then Jupyter is a "poor-man web-browser" version of Org-mode (very opinionated! ;-)) and Clojupyter [3] is one of its kernel. [1] https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-import.html [2] https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00189.html [3] https://github.com/clojupyter/clojupyter Well, hope that helps as feedback. Thanks, simon
Re: [GSOC 2020] Discussing GNU Guix project ideas?
On Tue, 3 Mar 2020 at 19:32, zimoun wrote: > Based on your interests (Clojure, Leiningen, etc.), you should > consider something around a Clojure "importer". (Note that I am > ignorant about the Java ecosystem.) Thanks for the idea, Simon! > Currently, it is possible to import Python packages from PyPI, or > Haskell packages from Hackage, or etc. see [1] and something about > Clojure seems missing. I am quoting Ludo from [2]: Thanks for the pointers! I will check these projects and let you know. On another side, I will be offline for a fer days, so I expect to start working on my proposal draft from March 16th onwards. Would it be OK if I publish a project draft on GoogleDocs/GitHub/GitLab in (let's say) MarkDown by March 20th, so people can easily comment on it? I think getting feedback on a document via email may be quite difficult... Please, state your preference. Best, Leandro
Re: wishlist: Guix tagging/logging
Hi Pierre, On Tue, 11 Feb 2020 at 09:47, Pierre Neidhardt wrote: > > I think it's a great idea! > > How do we tag locally though? Some trivial database? > An s-exp file? Using "git tag". For example, currently the "guix time-machine" only accepts '--commit='' and because only the released versions are tagged, it is not easy to navigate. Another example is, let consider that I publish a channel with tags, then my collaborators could easily obtain the list of all the tags via "guix tag --list" (or whatever CLI)and then pull to one particular tag and/or time-machine to it etc. Yet another example, today when I play with issues from the mailing list and/or the bug tracker, I often use "guix time-machine" or "guix pull -p /tmp/test" but often I am doing that between "real" day job and often on several days. Then it is boring to search in my shell history which commit or reopen the message or collect in an org file, so I often create a branch and/or tags in my local Guix checkout and I retrieve my information using Git. This extra step using Git is not natural and somehow the Git information is already there hidden under some Guix layer. We could imagine that Guix (optionally) checkouts the complete repo and this Git repo is the database. (Note that Guix already checkouts some more or less large parts or the repo.) And the tags could be exported to a s-exp file, go under version control and shared; with an importer tags. Moreover, aside tagging, we could improve the inferior creation by cutting some "updating time" using e.g., worktree. All the best, simon
