Re: Trusted Firmware-A (ARMv8)

[Development of GNU Guix and the GNU System distribution.]

It’s rather complicated. Anyway, I have to adapt the source code to be able to
install Guix on this board. It will take me some time to figure out how to do
this. Maybe start by modifying `make-arm-trusted-firmware'.
-- 
Best regards,
Kevin Vigouroux

Re: Release progress, week 2, release manifest, what builds are failing?

[Christopher Baines]

Ludovic Courtès  writes:

> $ make assert-binaries-available 
> Compiling Scheme modules...
> Compiling Scheme modules...
> Compiling Scheme modules...
> Compiling Scheme modules...
> computing 401 package derivations for x86_64-linux...
> looking for 508 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org ☀
>   92.7% substitutes available (471 out of 508)
>   at least 4,332.1 MiB of nars (compressed)
>   6,445.4 MiB on disk (uncompressed)
>   0.026 seconds per request (1.1 seconds in total)
>   38.4 requests per second
>
>   0.0% (0 out of 37) of the missing items are queued
>   at least 1,000 queued builds
>   x86_64-linux: 1000 (100.0%)
>   build rate: 15.77 builds per hour
>   i686-linux: 2.96 builds per hour
>   x86_64-linux: 9.88 builds per hour
>   aarch64-linux: 3.71 builds per hour
>   armhf-linux: 0.04 builds per hour
>
> Substitutes are missing for the following items:
>   /gnu/store/885iln2zpcxqvbr35d54bqhzs7l9djmq-libreoffice-7.3.5.2 
>i686-linux
>   /gnu/store/3fbzxn7bmlx7f250n6wdk56fl633giha-mate-1.24.1 
>i686-linux
>   /gnu/store/475m6q7hp7a1gw98ki9l4g04gmvsa75y-xz-5.2.5
>i586-gnu
>   /gnu/store/8fhdpb76nqy3v22jr33j18i1k07rl5n1-xz-5.2.5-static 
>i586-gnu
>   /gnu/store/6dvavfwg4zdih3rlvac4qqkx46my8gl6-tar-1.34
>i586-gnu
>   /gnu/store/sa1ay72axmi9g75sll2wy9cqpfldfy40-gcc-toolchain-12.2.0-debug  
>i586-gnu
>   /gnu/store/qxwclv8hx9z3gqwjil4hpwkwndh6f2zm-gcc-toolchain-12.2.0
>i586-gnu
>   /gnu/store/dypv1jgfzxlkbpp36z393xbdqal1v591-gcc-toolchain-12.2.0-static 
>i586-gnu
>   /gnu/store/7bx9jykip9lc13yn2bck1m4q8ccds1mz-make-4.3-debug  
>i586-gnu
>   /gnu/store/422i4q46cisabwsxrs7raf67awwwzsys-make-4.3
>i586-gnu
>   /gnu/store/f8jsczp72i49c79rjf8nv2q6jskqa5vy-gawk-5.1.0  
>i586-gnu
>   /gnu/store/d646qvpcdi0l9r2mqhqkxkrgwm0b50qh-findutils-4.8.0 
>i586-gnu
>   /gnu/store/zb0zbds0k2vjnln88dp4paldghl2mdwv-grep-3.6
>i586-gnu
>   /gnu/store/62hb8sk7vnz26flasklrm0x0yh5pdnq4-coreutils-8.32-debug
>i586-gnu
>   /gnu/store/fmk805j58dig4076wy8q6fj1w47jxaw1-coreutils-8.32  
>i586-gnu
>   /gnu/store/kgz0xm0c05ys92nkg07l7lbbikrx7hia-guix-1.3.0-31.3170843   
>armhf-linux
>   /gnu/store/nz1rw5cfrh4z3bl7fm2qsvxxpl955cqh-guile-3.0.8-debug   
>armhf-linux
>   /gnu/store/zmk1kmfk7wxm5w3ambajgnx7b0s5iq84-guile-3.0.8 
>armhf-linux
>   /gnu/store/26yb2pj71wg9cywmhpmsf6n1d81i43c5-python-3.9.9-idle   
>armhf-linux
>   /gnu/store/dh5rr8gd148afs3jzijs8i9gfwwi6igz-python-3.9.9
>armhf-linux
>   /gnu/store/x0yzk738mm4if6kbc8i8q7x3ajz2rd27-python-3.9.9-tk 
>armhf-linux
>   /gnu/store/5p9jplb7hzci9nrpk4nxqa7qlyfb6wji-vim-9.0.0719
>armhf-linux
>   /gnu/store/kxzqk19zm8y8dchcgx0izhwhfmzxwdmi-emacs-no-x-28.2 
>armhf-linux
>   /gnu/store/3ss4kln2a69xfja55wbi46pr1nsjbngr-openssh-8.9p1   
>armhf-linux
>   /gnu/store/s95hh0h7zak67iwhq8aavl3np53ri9y7-nss-certs-3.81  
>armhf-linux
>   /gnu/store/5nn8q80kywqvpzkhafpv3lppfbm5wm7n-bootstrap-tarballs-0
>armhf-linux
>   /gnu/store/z74rg03jdf18byyin6ygggw5q77mk1mn-guix-1.3.0-31.3170843   
>powerpc64le-linux
>   /gnu/store/ycl224w6nz4dj2rnb7mcki4p5w46cnfp-vim-9.0.0719
>powerpc64le-linux
>   /gnu/store/f2mw6w0nk0j670qvlw2z72mvrwm5575w-emacs-28.2  
>powerpc64le-linux
>   /gnu/store/8psdslg1p8g814ih6sd1xrxvx39bf9v4-openssh-8.9p1   
>powerpc64le-linux
>   /gnu/store/5i4v6wbdlj4y9dpfp15jnrnphg0x84py-guix-1.3.0-31.3170843   
>aarch64-linux
>   /gnu/store/pgm8608mzhwxn86q48lpb77vp4pxp6g3-python-3.9.9-idle   
>aarch64-linux
>   /gnu/store/v4hgmb3k2l60yy8vzl3h1wvp5fa15db7-emacs-28.2  
>aarch64-linux
>   /gnu/store/pfk09jhc4fqalkv6bbv0cv7j00whydzm-gcc-toolchain-12.2.0-debug  
>aarch64-linux
>   /gnu/store/kjcr6zmkh0gdraclp5v5kqqqsy4hdx9h-gcc-toolchain-12.2.0
>aarch64-linux
>   /gnu/store/ylhykr5g3yvbdarwb0h7smhhx2wga89m-gcc-toolchain-12.2.0-static 
>aarch64-linux
>   /gnu/store/v14vx389rwshm5chr5llbrnjyrvgxbp7-bootstrap-tarballs-0
>aarch64-linux
> make: *** [Makefile:7146: assert-binaries-available] Error 1

So, now that bordeaux.guix.gnu.org has caught up with the changes from
the staging merge, checking the release manifest against it hopefully
just gives outputs that are missing because of build failures.

I've just pushed a change to the release manifest to tweak it's handling
of armhf-linux. The emacs package doesn't need replacing, but the guix
package doesn't build for armhf-l

Re: * TODO Guix json dump all python packages in channel (CLI)

[zimoun]

Hi,

On Mon, 24 Oct 2022 at 22:03, jgart  wrote:

> Wouldn't it be cool if you could do
>
> ```
> guix dump -L my-guix-channel/ --json --filter=py
> ```
>
> I know it's possible by writing Guix API code.

>From my opinion, this perfectly fits a Guix extension.  Well, if you are
interested by the JSON file, you can start by,



where the job is done by the website, see here [1].

1: 



Hope that helps,
simon

Build LanguageTool use maven-build-system?

[Declan Tsien]

I believe LanguageTool[1] is a Java project using Maven as it's building
tool.

Lazy me. Instead of digging the mailing list and source code which would
cost too much time and may not work out. I packaged the binary
distribution (jar files) using =copy-build-system= which I am trying to
get it merged into Nonguix[2] in case someone else also wants it.

So my questions would be:

1: What is the current status of maven-build-system? Is it capable of
building a package like this[3]?

2: Also, I don't see =guix import= has support for maven. Does that mean
we have to manually write a package definition for every dependency if
it wasn't included in Guix yet?

3: If =maven-build-system= is capable of building a package like this,
would someone like to tackle packaging =LanguageTool= from source? 

1: https://github.com/languagetool-org/languagetool
2:
https://gitlab.com/nonguix/nonguix/-/merge_requests/226#note_1147169576
3: https://github.com/languagetool-org/languagetool/blob/master/pom.xml

Thanks


signature.asc
Description: PGP signature

Re: Release progress, week 2, release manifest, what builds are failing: gst-plugins-bad

[Christopher Baines]

Christopher Baines  writes:

> /gnu/store/msq74p2bd4g99n2x2wl85pjwc51pp82f-gst-plugins-bad-1.20.3.drv

I spotted ci.guix.gnu.org actually has a substitute for this. Turns out
it's just very flaky. bordeaux.guix.gnu.org has now attempted to build
it 9 times, and only 1 build succeeded:

https://data.guix.gnu.org/gnu/store/msq74p2bd4g99n2x2wl85pjwc51pp82f-gst-plugins-bad-1.20.3.drv

Anyway, I've sent a patch that disables the flaky test:

  https://issues.guix.gnu.org/58773


signature.asc
Description: PGP signature

Re: Build LanguageTool use maven-build-system?

[Julien Lepiller]

Le 25 octobre 2022 04:10:51 GMT+02:00, Declan Tsien  a 
écrit :
>
>I believe LanguageTool[1] is a Java project using Maven as it's building
>tool.
>
>Lazy me. Instead of digging the mailing list and source code which would
>cost too much time and may not work out. I packaged the binary
>distribution (jar files) using =copy-build-system= which I am trying to
>get it merged into Nonguix[2] in case someone else also wants it.
>
>So my questions would be:
>
>1: What is the current status of maven-build-system? Is it capable of
>building a package like this[3]?

It's working fine, but most packages are still lacking a lot of dependencies, 
including some maven plugins

>
>2: Also, I don't see =guix import= has support for maven. Does that mean
>we have to manually write a package definition for every dependency if
>it wasn't included in Guix yet?

There's no importer and an importer would be a bit limited as it won't be able 
to get proper sources most of tge tine, though importing the dependency graph 
would be useful already. Would you like to give it a try? :)

>
>3: If =maven-build-system= is capable of building a package like this,
>would someone like to tackle packaging =LanguageTool= from source? 

Like I said, the biggest issue would be number of packages, and maybe bug fixes 
as we currently have only one package using the maven-build-system.

>
>1: https://github.com/languagetool-org/languagetool
>2:
>https://gitlab.com/nonguix/nonguix/-/merge_requests/226#note_1147169576
>3: https://github.com/languagetool-org/languagetool/blob/master/pom.xml
>
>Thanks

Re: Types and builds for mypy

[Maxim Cournoyer]

Hi Phil,

Phil  writes:

> Thanks for your reply Maxim,
>
> Maxim Cournoyer writes:
>
>
>> Is MyPy the only consumer of Python type annotations?  I think so, but
>> I'm not sure.  If it's the only one, it'd make sense to move mypy and
>> all the annotation types to (gnu packages python-types), I think.
>
> Mypy is certainly a prominent consumer, but you're right - PEP 561 type stub
> packages are also used by PyCharm, pytype, and I've heard CPython can
> use them to compile, to name a few.
>
> So I think my revised opinion is mypy should stay where it is, but I do
> like the idea of keeping all the types in one module?

I'd actually be fine with having mypy in a (gnu packages python-types)
module along its types packages.

[...]

> Cool thanks - leave this with me, I have a working package so can submit
> a patch shortly!

Excellent!

-- 
Thanks,
Maxim

Re: Build LanguageTool use maven-build-system?

[Declan Tsien]

Julien Lepiller  writes:

>
> There's no importer and an importer would be a bit limited as it won't be 
> able to get proper sources most of tge tine, though importing the dependency 
> graph would be useful already. Would you like to give it a try? :)
>

Can you elaborate on this? How can I import the dependency graph if there
is no importer? I very much like to try it out when I am bored at home.


signature.asc
Description: PGP signature

Exact Versions and Guix Dev Tooling

[jgart]

Hi,

What's the Guix approach to getting exact versions for a dev project.

Should we be contributing those packages upstream or should Guix just
provide the tooling to generate exact package definitions for exact
versions that are needed in a particular project?

For example, what if a dev needs the versions of every library you're
using in a development project and they are not in Guix?

What is Guix's answer to that? Do they have to package everything and
wait for it to get merged to the master branch?

I'm nodding to tools like these in the Nix community:

# PureScript

https://github.com/purs-nix/purs-nix
https://github.com/justinwoo/spago2nix
https://github.com/nix-community/poetry2nix

# Node

https://github.com/nix-community/npmlock2nix
https://github.com/svanderburg/node2nix
https://github.com/serokell/nix-npm-buildpackage

# Rust

https://github.com/kolloch/crate2nix
https://github.com/oxalica/rust-overlay
https://github.com/nix-community/fenix

Is our approach currently that if you develop with Guix you have to
develop against the versions that are in Guix master or some other branch?

WDYT

guix git authenticate throws hard

[jgart]

 guix git authenticate 95620d8845a75c9721876441e66bf28ba4a95eff jgart
Backtrace:
  11 (primitive-load "/home/jgart/.config/guix/current/bin/g…")
In guix/ui.scm:
   2263:7 10 (run-guix . _)
  2226:10  9 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
  1747:15  6 (with-exception-handler # …)
In guix/channels.scm:
   164:10  5 (_)
In guix/base16.scm:
 71:7  4 (_ "a")
In unknown file:
   3 (string-fold # …)
In guix/base16.scm:
76:31  2 (_ _ 0)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure bytevector-u8-set!: Argument 2 out of range: 0

WDYT

Re: Build LanguageTool use maven-build-system?

[Liliana Marie Prikler]

Am Mittwoch, dem 26.10.2022 um 07:56 +0800 schrieb Declan Tsien:
> Julien Lepiller  writes:
> 
> > 
> > There's no importer and an importer would be a bit limited as it
> > won't be able to get proper sources most of tge tine, though
> > importing the dependency graph would be useful already. Would you
> > like to give it a try? :)
> > 
> 
> Can you elaborate on this? How can I import the dependency graph if
> there is no importer? I very much like to try it out when I am bored
> at home.
What Julien means is that if you were trying to write an importer,
you'd end up writing one that produces something like this

  (define-public java-language-tool
 (package 
   (name "java-language-tool")
   (version "6.0")
   (source this-thing-raises-an-error)
   ...
   (inputs (list java-commons-cli ...))
   (native-inputs (list java-junit ...))
   ...))

  (define-public java-commons-cli
 (package
(name "java-commons-cli")
(version some-version)
(source this-thing-raises-an-error)
...))

In other words, you won't be able to actually build language-tool until
you insert proper sources in all the source fields – which Julien fears
maven, being a binary distribution system first and foremost, won't
deliver on its own.

Cheers

Re: Build LanguageTool use maven-build-system?

[Declan Tsien]

Liliana Marie Prikler  writes:

> What Julien means is that if you were trying to write an importer,
> you'd end up writing one that produces something like this
>
>   (define-public java-language-tool
>  (package 
>(name "java-language-tool")
>(version "6.0")
>(source this-thing-raises-an-error)
>...
>(inputs (list java-commons-cli ...))
>(native-inputs (list java-junit ...))
>...))
>
>   (define-public java-commons-cli
>  (package
> (name "java-commons-cli")
> (version some-version)
> (source this-thing-raises-an-error)
> ...))
>
> In other words, you won't be able to actually build language-tool until
> you insert proper sources in all the source fields – which Julien fears
> maven, being a binary distribution system first and foremost, won't
> deliver on its own.
>
> Cheers

I see. Thanks.


signature.asc
Description: PGP signature

Re: guix git authenticate throws hard

[Julien Lepiller]

From the manual: "signer is the OpenPGP fingerprint of public key used to sign 
commit.", but we should still catch this error :)

Le 26 octobre 2022 04:33:50 GMT+02:00, jgart  a écrit :
> guix git authenticate 95620d8845a75c9721876441e66bf28ba4a95eff jgart
>Backtrace:
>  11 (primitive-load "/home/jgart/.config/guix/current/bin/g…")
>In guix/ui.scm:
>   2263:7 10 (run-guix . _)
>  2226:10  9 (run-guix-command _ . _)
>In ice-9/boot-9.scm:
>  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
>  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
>  1747:15  6 (with-exception-handler # …)
>In guix/channels.scm:
>   164:10  5 (_)
>In guix/base16.scm:
> 71:7  4 (_ "a")
>In unknown file:
>   3 (string-fold # …)
>In guix/base16.scm:
>76:31  2 (_ _ 0)
>In ice-9/boot-9.scm:
>  1685:16  1 (raise-exception _ #:continuable? _)
>  1685:16  0 (raise-exception _ #:continuable? _)
>
>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
>In procedure bytevector-u8-set!: Argument 2 out of range: 0
>
>WDYT
>

Re: Exact Versions and Guix Dev Tooling

[Liliana Marie Prikler]

Hi,

Am Dienstag, dem 25.10.2022 um 20:49 -0500 schrieb jgart:
> Hi,
> 
> What's the Guix approach to getting exact versions for a dev project.
> 
> Should we be contributing those packages upstream or should Guix just
> provide the tooling to generate exact package definitions for exact
> versions that are needed in a particular project?
> 
> For example, what if a dev needs the versions of every library you're
> using in a development project and they are not in Guix?
> 
> What is Guix's answer to that? Do they have to package everything and
> wait for it to get merged to the master branch?
You can manage channels, guix.scm and manifests however you want,
including packaging stuff at random commits.  The resulting files won't
be much prettier than your average lock file, but I'd assume that's the
point.

> I'm nodding to tools like these in the Nix community:
> 
> # PureScript
> 
> https://github.com/purs-nix/purs-nix
> https://github.com/justinwoo/spago2nix
> https://github.com/nix-community/poetry2nix
> 
> # Node
> 
> https://github.com/nix-community/npmlock2nix
> https://github.com/svanderburg/node2nix
> https://github.com/serokell/nix-npm-buildpackage
> 
> # Rust
> 
> https://github.com/kolloch/crate2nix
> https://github.com/oxalica/rust-overlay
> https://github.com/nix-community/fenix
> 
> Is our approach currently that if you develop with Guix you have to
> develop against the versions that are in Guix master or some other
> branch?
You can use importers for node and rust – for purescript you might be
able to reuse haskell or node tooling, idk? – but note that we don't
support pulling random commits.  You'd be well advised in using release
versions.  Again, you don't have to target Guix master and can maintain
your own channel to trim down your guix.scm or you can blow it up by
mentioning every package in existence down to mesboot.

Cheers

Re: guix git authenticate throws hard

[jgart]

On Wed, 26 Oct 2022 07:21:35 +0200 Julien Lepiller  wrote:
> From the manual: "signer is the OpenPGP fingerprint of public key used to 
> sign commit.", but we should still catch this error :)

Is it possible to give the email instead of the fingerprint?

Deduce the fingerprint from the email?