package transformation and “guix graph”?

package transformation and “guix graph”?

[Simon Tournier]

Hi,

Investigating « bug#62645: Failing `guix install gnash` » [1], I am a
bit surprised:

--8<---------------cut here---------------start------------->8---
$ guix build gnash --with-c-toolchain=gnash=gcc-toolchain@9 -n 2>&1 | grep tar.gz | wc -l
1008
--8<---------------cut here---------------end--------------->8---

and most of the packages to rebuild are Rust packages.  Basically
because the dependency ’gtk+’; surprising but why not.

Where I am really surprised is that:

--8<---------------cut here---------------start------------->8---
$ guix build gnash --with-c-toolchain=gnash=gcc-toolchain@9 -n 2>&1 | grep rust-hmac
  /gnu/store/983c5jb08bypxa9r6cmzg3znncmjhs4s-rust-hmac-0.8.1.tar.gz

$ guix graph --path gnash rust-hmac -t bag
guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'rust-hmac@0.12.0'
--8<---------------cut here---------------end--------------->8---

The package rust-hmac needs to be rebuilt but it does not appear
connected via “guix graph”.  Note that rust-hmac has no direct
dependency and only the ones from the Rust build system.

Similarly, the node ’gcc’ appears in the DAG of gnash:

--8<---------------cut here---------------start------------->8---
$ guix graph gnash -t bag-emerged | grep label | grep gcc
  "/gnu/store/wcx86bp6zcad2n2x5940dndhcksvfk5v-gcc-11.3.0.drv" [label = "gcc@11.3.0", shape = box, fontname = sans];
  "/gnu/store/rws8k2p28lvcims2yxr87v0yq4d793yk-gcc-mesboot-wrapper-4.9.4.drv" [label = "gcc-mesboot-wrapper@4.9.4", shape = box, fontname = sans];
  "/gnu/store/9nnxabq3m41pnq619gr59bjrbj054sl7-gcc-mesboot1-4.6.4.drv" [label = "gcc-mesboot1@4.6.4", shape = box, fontname = sans];
  "/gnu/store/ifxv0rvji2fqmj8m3yypwylc9fb3v1iq-gcc-mesboot0-2.95.3.drv" [label = "gcc-mesboot0@2.95.3", shape = box, fontname = sans];
  "/gnu/store/8vp8iadwjcvhaaqpa1wy60irhjdppwx7-gcc-core-mesboot0-2.95.3.drv" [label = "gcc-core-mesboot0@2.95.3", shape = box, fontname = sans];
  "/gnu/store/d3380kgfxv8dq9bimdqy2p0rfb30ad0q-gcc-mesboot-4.9.4.drv" [label = "gcc-mesboot@4.9.4", shape = box, fontname = sans];
  "/gnu/store/jgdyp8yr4j9ajk8ppfkypb1kylav7yx5-gcc-mesboot1-wrapper-4.6.4.drv" [label = "gcc-mesboot1-wrapper@4.6.4", shape = box, fontname = sans];
  "/gnu/store/j3idibd5016sxv4c15mx4xrpzggccjd0-python-pexpect-4.8.0.drv" [label = "python-pexpect@4.8.0", shape = box, fontname = sans];
--8<---------------cut here---------------end--------------->8---

but then,

--8<---------------cut here---------------start------------->8---
$ guix graph --path gnash -e '(@@ (gnu packages gcc) gcc-11)' -t bag 
guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'gcc@11.3.0'
--8<---------------cut here---------------end--------------->8---

And note that,

--8<---------------cut here---------------start------------->8---
$ guix build -e '(@@ (gnu packages gcc) gcc-11)' --no-grafts -d
/gnu/store/rcd13s3lcd579s0l8v3awk4a6kbj8hvz-gcc-11.3.0.drv
$ guix build -e '(@@ (gnu packages gcc) gcc-11)' -d
/gnu/store/rcd13s3lcd579s0l8v3awk4a6kbj8hvz-gcc-11.3.0.drv
--8<---------------cut here---------------end--------------->8---

the derivation does not match with the one reported by “guix graph”.


Last, the package ’gcc’ appears in the graph of ’rust-hmac’ – which
seems weird to me but why not:

--8<---------------cut here---------------start------------->8---
$ guix graph rust-hmac -t bag-emerged | grep label | grep gcc
  "/gnu/store/wcx86bp6zcad2n2x5940dndhcksvfk5v-gcc-11.3.0.drv" [label = "gcc@11.3.0", shape = box, fontname = sans];
--8<---------------cut here---------------end--------------->8---

and then again no path between rust-hmac and gcc.  Note the same
derivation.


What do I miss?


Cheers,
simon

1: https://issues.guix.gnu.org/issue/62645

Re: package transformation and “guix graph”?

[Adam Faiz]

Hello,

> Hi,
> 
> Investigating « bug#62645: Failing `guix install gnash` » [1], I am a
> bit surprised:
>> The package rust-hmac needs to be rebuilt but it does not appear
> connected via “guix graph”.  Note that rust-hmac has no direct
> dependency and only the ones from the Rust build system.
> 
> Similarly, the node ’gcc’ appears in the DAG of gnash:
> 
> but then,
> 
> --8<---------------cut here---------------start------------->8---
> $ guix graph --path gnash -e '(@@ (gnu packages gcc) gcc-11)' -t bag 
> guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'gcc@11.3.0'
> --8<---------------cut here---------------end--------------->8---
> 
> And note that,
> 
> --8<---------------cut here---------------start------------->8---
> $ guix build -e '(@@ (gnu packages gcc) gcc-11)' --no-grafts -d
> /gnu/store/rcd13s3lcd579s0l8v3awk4a6kbj8hvz-gcc-11.3.0.drv
> $ guix build -e '(@@ (gnu packages gcc) gcc-11)' -d
> /gnu/store/rcd13s3lcd579s0l8v3awk4a6kbj8hvz-gcc-11.3.0.drv
> --8<---------------cut here---------------end--------------->8---
> 
> the derivation does not match with the one reported by “guix graph”.
> 
> 
> Last, the package ’gcc’ appears in the graph of ’rust-hmac’ – which
> seems weird to me but why not:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix graph rust-hmac -t bag-emerged | grep label | grep gcc
>   "/gnu/store/wcx86bp6zcad2n2x5940dndhcksvfk5v-gcc-11.3.0.drv" [label = 
> "gcc@11.3.0", shape = box, fontname = sans];
> --8<---------------cut here---------------end--------------->8---
> 
> and then again no path between rust-hmac and gcc.  Note the same
> derivation.
> 
> 
> What do I miss?
There's a long standing issue of rust packages not using inputs and native-inputs[1] because of how cargo-build-system works.
The WIP antioxidant-build-system[2] will properly address all the shortcomings currently in Guix's Rust packaging.

gcc-11 is an implicit input of gnu-build-system so it's still in the build graph.

1: https://issues.guix.gnu.org/53127
2: https://notabug.org/maximed/cargoless-rust-experiments

> 
> 
> Cheers,
> simon
> 
> 1: https://issues.guix.gnu.org/issue/62645

Re: package transformation and “guix graph”?

[Ludovic Courtès]

Hi!

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> Investigating « bug#62645: Failing `guix install gnash` » [1], I am a
> bit surprised:
>
> $ guix build gnash --with-c-toolchain=gnash=gcc-toolchain@9 -n 2>&1 | grep tar.gz | wc -l
> 1008
>
>
> and most of the packages to rebuild are Rust packages.  Basically
> because the dependency ’gtk+’; surprising but why not.
>
> Where I am really surprised is that:
>
> $ guix build gnash --with-c-toolchain=gnash=gcc-toolchain@9 -n 2>&1 | grep rust-hmac
>   /gnu/store/983c5jb08bypxa9r6cmzg3znncmjhs4s-rust-hmac-0.8.1.tar.gz
>
> $ guix graph --path gnash rust-hmac -t bag
> guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'rust-hmac@0.12.0'

Note that it’s not the same version (0.12.0 vs. 0.8.1), but the result
is the same with 0.8.  The reason is that Rust packages aren’t like
“real” packages; the sources are eventually aggregated in whatever
package needs them.

IOW, ‘guix graph’, ‘guix refresh -l’, etc. aren’t very useful with Rust
packages, and that’s a problem.  See <https://issues.guix.gnu.org/53127>.

> $ guix graph --path gnash -e '(@@ (gnu packages gcc) gcc-11)' -t bag 
> guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'gcc@11.3.0'

That’s because you’re not looking at the “right” GCC 11 package object:

--8<---------------cut here---------------start------------->8---
$ guix graph --path gnash -e '(@@ (gnu packages commencement) gcc-final)'
gnash@0.8.11-0.583ccbc
ffmpeg@2.8.20
pulseaudio@16.1
elogind@246.10
kexec-tools@2.0.23
ld-wrapper@0
guile@3.0.9
gcc@11.3.0
--8<---------------cut here---------------end--------------->8---

HTH!

Ludo’.

Re: package transformation and “guix graph”?

[Simon Tournier]

Hi,

(Well, something appears to me weird: rebuild Gnash which is a C++
software using another toolchain implies a Rust-world rebuild.)


On Wed, 03 May 2023 at 23:36, Ludovic Courtès <ludo@gnu.org> wrote:

> Note that it’s not the same version (0.12.0 vs. 0.8.1), but the result
> is the same with 0.8.  The reason is that Rust packages aren’t like
> “real” packages; the sources are eventually aggregated in whatever
> package needs them.

Hum, ok.



>> $ guix graph --path gnash -e '(@@ (gnu packages gcc) gcc-11)' -t bag 
>> guix graph: error: no path from 'gnash@0.8.11-0.583ccbc' to 'gcc@11.3.0'
>
> That’s because you’re not looking at the “right” GCC 11 package object:

Hum, this “right” looks weird to me.  I read from (gnu packages gcc):

--8<---------------cut here---------------start------------->8---
;; Note: When changing the default gcc version, update
;;       the gcc-toolchain-* definitions.
(define-public gcc gcc-11)
--8<---------------cut here---------------end--------------->8---

Then from (gnu packages commencent):

--8<---------------cut here---------------start------------->8---
(define gcc-boot0
  (package
    (inherit gcc)
--8<---------------cut here---------------end--------------->8---

Then,

--8<---------------cut here---------------start------------->8---
(define gcc-final
  ;; The final GCC.
  (package (inherit gcc-boot0)
--8<---------------cut here---------------end--------------->8---

And,

--8<---------------cut here---------------start------------->8---
(define-public gcc-toolchain
  (make-gcc-toolchain gcc-final))
--8<---------------cut here---------------end--------------->8---

Well, I am lost with the difference between gcc-final and gcc-11.

Last, what lost me is this:

--8<---------------cut here---------------start------------->8---
(define-public gcc-toolchain-4.8
  (make-gcc-toolchain gcc-4.8))

(define-public gcc-toolchain-4.9
  (make-gcc-toolchain gcc-4.9))

(define-public gcc-toolchain-5
  (make-gcc-toolchain gcc-5))

(define-public gcc-toolchain-6
  (make-gcc-toolchain gcc-6))

(define-public gcc-toolchain-7
  (make-gcc-toolchain gcc-7))

(define-public gcc-toolchain-8
  (make-gcc-toolchain gcc-8))

(define-public gcc-toolchain-9
  (make-gcc-toolchain gcc-9))

(define-public gcc-toolchain-10
  (make-gcc-toolchain gcc-10))

(define-public gcc-toolchain-11
  gcc-toolchain)

(define-public gcc-toolchain-12
  (make-gcc-toolchain gcc-12))
--8<---------------cut here---------------end--------------->8---

compared to ’gcc-toolchain’ which uses gcc-final.  Why not gcc-11 as all
the others?  It would make it consistent with the rest, no?


Cheers,
simon