Re: Python package with some rust dependency

[Alexis Simon]

Hi,

So I think I'm nearly there (part of the scm attached).

The last thing I'd like to do is run the python tests inside the 
cargo-build-system but couldn't find an example of it. I don't 
understand how to do that.


I get the following error, which is most probably me not knowing how to 
write scheme.

```
error: in phase 'check-python-module': uncaught exception:
wrong-type-arg "apply" "Apply to non-list: ~S" (#f) (#f)
phase `check-python-module' failed after 0.0 seconds
Backtrace:
   8 (primitive-load "/gnu/store/c2v51hzvlji63jbh0jwn5dbz10j…")
In guix/build/gnu-build-system.scm:
908:2  7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9  5 (for-each # …)
In ice-9/boot-9.scm:
  1752:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   929:23  3 (_)
In unknown file:
   2 (_ "/gnu/store/qzx9n7452cw0w11c96gvijdnmk6v82m2-python…" …)
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 apply: Apply to non-list: #f
```

Thanks
Alexis


On 15/02/2024 22:08, Alexis Simon wrote:

Hi,

So right now I'm trying to go the splitting in two packages way, similar 
to what is done for python-cryptography.


So I managed to build the first one that produces a header file in the 
store /gnu/store/*/lib/header.h


In the second package, I don't get how to copy this file inside the 
build. I've been trying something like this:

```
     (native-inputs (list python-fwdpy11-rust-lib))
     (arguments
   (list
     #:phases
     #~(modify-phases %standard-phases
     (add-before 'build 'copy-rust-lib
    (lambda* (#:key native-inputs #:allow-other-keys)
  (copy-file (search-input-file
    native-inputs "lib/fp11rust_api.h")
   "lib/core/internal/fp11rust_api.h"))
```
Which complains there is no match, because it seams the package store 
path is not present in the native-inputs, although I specify it in the 
package.


Thanks,
Alexis

On 13/02/2024 13:55, Alexis Simon wrote:
Fair enough, I just meant that it's pretty hard as a newcomer to know 
which build system You're supposed to use to start with when 
encountering a project where several languages are used.


Alexis

On 13/02/2024 13:46, Carlo Zancanaro wrote:

On Tue, Feb 13 2024, Alexis Simon wrote:

Ok, this seems really counter intuitive though to go and use the cargo
build system for a python package only have a tiny part in rust.


I'm not sure why this is counter-intuitive. The existence of any rust at
all means you need to build rust code. The normal way to do that in Guix
is to use the cargo-build-system.

Equally, I don't find it strange that the upstream build instructions[1]
ask me to install a rust compiler and cbindgen. I need to do that if I
want to build rust code.

It's also worth noting that there are 22 packages in Cargo.lock[2], so
building the one rust file in the repository is a bit more involved.

Carlo

[1]: https://molpopgen.github.io/fwdpy11/misc/developersguide.html
[2]: 
https://github.com/molpopgen/fwdpy11/blob/main/rust/fp11rust/Cargo.lock


(define-public fwdpy11
  (package
(name "fwdpy11")
(version "0.21.6")
(source
 (origin
   (method url-fetch)
   (uri (pypi-uri "fwdpy11" version))
   (sha256
(base32 "1mgs7fcda3cr7a7kbnk0x50993131453rlrkq7nv4pxqw53lnrv3"
(build-system cargo-build-system)
(arguments
  (list
#:imported-modules `(,@%cargo-build-system-modules
   ,@%pyproject-build-system-modules)
#:modules '((guix build cargo-build-system)
((guix build pyproject-build-system) #:prefix py:)
(guix build utils))
#:phases
#~(modify-phases %standard-phases
(add-after 'unpack 'chdir-rust
(lambda _
  (chdir "rust/fp11rust")))
(replace 'unpack-rust-crates
;; This is to avoid the non-crate source from being erroneously
;; unpacked by this phase, causing an error.
(lambda* (#:key inputs #:allow-other-keys #:rest args)
  (apply (assoc-ref %standard-phases 'unpack-rust-crates)
 (append args
 (list #:inputs (alist-delete "source" inputs))
(replace 'configure
(lambda* (#:key inputs #:allow-other-keys #:rest args)
  (apply (assoc-ref %standard-phases 'configure)
 (append args
 (list #:inputs (alist-delete "source" inputs))
(delete 'build)
(delete 'check)
(delete 'install)
  

Re: How to debug a failed build of rust application under cargo-build-system?

[woshilapin]

Hi,

It is indeed a code error which looks weird. Are you sure the 2 compilations 
compile the same source code? How do you invoke `cargo install`? Because if you 
invoke `cargo install --path .`, then I'm pretty sure it's compiling whatever 
is on your machine at the current directory. However, any other invocation of 
`cargo install` might actually pull some source from `crates.io` (the package 
registry for `cargo`). For example, `cargo install cargo-nextest` will download.
Same applies for `guix build` (I'm a guix very beginner so I might not be the 
best at this), I'm not sure `guix build` build the current directory. Doesn't 
it build the `package.scm` which itself describe where to pull the source code?

So, trying a way to be sure that `cargo install` and `guix build` actually 
build the same source code might a first step. I hope this helps.

Have a nice day.
--
woshilapin

Le jeudi 15 février 2024 à 13:43, Tomas Volf <~@wolfsden.cz> a écrit :

> Greetings,
> 
> I am trying to package a rust application and the build fails. I am not sure
> how to debug that. When I try to compile the application using `cargo 
> install', it does pass and build just fine. However, when I try to build the 
> application (imported using the cargo importer) using` guix build', I get 
> this error:
> 
> Compiling tonic v0.10.2
> error[E0277]: the `?` operator can only be used in an async block that 
> returns `Result` or `Option` (or another type that implements `FromResidual`)
> --> 
> /tmp/guix-build-netavark-1.10.3.drv-0/netavark-1.10.3/guix-vendor/rust-tonic-0.10.2.tar.gz/src/transport/server/incoming.rs:32:45
> 
> |
> 28 | / async_stream::try_stream! {
> 29 | | tokio::pin!(incoming);
> 30 | |
> 31 | | while let Some(item) = incoming.next().await {
> 32 | | yield item.map(ServerIo::new_io)?
> | | ^ cannot use the `?` operator in an async block that returns `()`
> 33 | | }
> 34 | | }
> | |_- this function should return `Result` or `Option` to accept `?`
> |
> = help: the trait `FromResidual>` is not 
> implemented for `()`
> 
> 
> For more information about this error, try `rustc --explain E0277`.
> error: could not compile `tonic` (lib) due to previous error
> 
> I am not know rust, but this looks like a code error? If that is the case, I 
> do
> not understand why `cargo install' works, since it should be using the same
> code.
> 
> Could someone nudge me in the right direction regarding how to debug this 
> issue?
> I am not really sure where to start.
> 
> Thank you and have a nice day,
> Tomas Volf
> 
> --
> There are only two hard things in Computer Science:
> cache invalidation, naming things and off-by-one errors.

Re: torbrowser

[Gottfried]

Hi Clement,

now after updating my manifest it worked:
It downloaded torbrowser additional to icecat and ungoogled-chromium


gfp@Tuxedo ~$ guix package -p /home/gfp/Projekte/Icecat/guix-profil -m 
/home/gfp/Projekte/Icecat/icecat.scm

Die folgenden Pakete werden installiert:
   icecat 115.7.0-guix0-preview1
   torbrowser 13.0.9
   ungoogled-chromium 112.0.5615.165-1

I am happy
thanks for your help

Kind regards

Gottfried


Am 18.01.24 um 15:57 schrieb Clément Lassieur:

No problem

Maybe you are not in the good place

can you show the output of:

     pwd

?

Also, where is "gfp" located?

On Thu, Jan 18, 2024, at 3:01 PM, Gottfried wrote:

Am 18.01.24 um 15:39 schrieb Clément Lassieur:
> so what is the file that contains
>
>      ;; Icecat Manifest
>      (specifications->manifest '("icecat" "ungoogled-chromium"
> "torbrowser"))
>

The file is :

icecat.scm

it is located unter:

gfp/Projekte/Icecat/


May be I don't understand something.

Sorry for the inconvenience.





>
> On Thu, Jan 18, 2024, at 2:42 PM, Gottfried wrote:
>> Am 18.01.24 um 15:20 schrieb Clément Lassieur:
>> > does the file exist?
>> >
>> > What is the output of:
>> >
>> >      cat gfp/Projekte/Icecat/icecat.scm
>>
>>
>> gfp@Tuxedo ~$ cat gfp/Projekte/Icecat/icecat.scm
>> cat: gfp/Projekte/Icecat/icecat.scm: No such file or directory
>>
>>
>> >
>> > And what is the output of:
>> >
>> >      guix package -m gfp/Projekte/Icecat/icecat.scm
>> >
>>
>>
>> gfp@Tuxedo ~$ guix package -m gfp/Projekte/Icecat/icecat.scm
>> guix package: error: failed to load 'gfp/Projekte/Icecat/icecat.scm':
>> ice-9/boot-9.scm:2190:9: In procedure primitive-load-path: Unable to
>> find file "guix/gfp/Projekte/Icecat/icecat.scm" in load path
>>
>> Kind regards
>>
>> Gottfried
>>
>>
>> *Attachments:*
>>
>>   * OpenPGP_0x61FAF349C9FB7F94.asc
>>   * OpenPGP_signature
>

--
Kind regards

Gottfried



*Attachments:*

  * OpenPGP_0x61FAF349C9FB7F94.asc
  * OpenPGP_signature




--


OpenPGP_0x61FAF349C9FB7F94.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Guix Days: Patch flow discussion

[Christopher Baines]

Clément Lassieur  writes:

> On Fri, Feb 16 2024, Andreas Enge wrote:
>
>> Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur:
>>> Would it makes sense to have a "does-not-apply" tag too?
>>
>> Should this not appear in the QA page, assuming that once all the new
>> issues are closed, older ones will bubble to the top and be treated by QA?
>> (I am not sure if just looking at the n latests issues is how QA works,
>> but I think so.)
>
> I think it would be useful (at least for me) if I browse a list of
> patches that I want to review, to document why a review can't be done.
>
> Also, so that other people won't try to apply it.
>
> It would be great that QA does that job, I imagine when it does it it
> can also add that tag.

There's the filter issues form which allows finding patches which can't
be applied:

  https://qa.guix.gnu.org/patches?failed-to-apply-patches=on

I think QA tagging issues might be useful for people to benefit from
that data in other places, and should be possible, it just needs QA to
send emails I think.


signature.asc
Description: PGP signature

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Fri, Feb 16 2024, Andreas Enge wrote:

> Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur:
>> Would it makes sense to have a "does-not-apply" tag too?
>
> Should this not appear in the QA page, assuming that once all the new
> issues are closed, older ones will bubble to the top and be treated by QA?
> (I am not sure if just looking at the n latests issues is how QA works,
> but I think so.)

I think it would be useful (at least for me) if I browse a list of
patches that I want to review, to document why a review can't be done.

Also, so that other people won't try to apply it.

It would be great that QA does that job, I imagine when it does it it
can also add that tag.

Re: Guix Days: Patch flow discussion

[Andreas Enge]

Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur:
> Would it makes sense to have a "does-not-apply" tag too?

Should this not appear in the QA page, assuming that once all the new
issues are closed, older ones will bubble to the top and be treated by QA?
(I am not sure if just looking at the n latests issues is how QA works,
but I think so.)

Andreas

Re: Guix Days: Patch flow discussion

[Clément Lassieur]

On Tue, Feb 06 2024, Suhail wrote:

> Steve George  writes:
>
>> elsewhere in the thread someone mentions some tags we could use
>> consistently so maintainers can find patches that have been reviewed
>> easily.
>
> It seems on the [dev manual] we already have "reviewed-looks-good"
> documented.  Thus, I'd like to propose the below *mutually exclusive*
> Debbugs tag set:
>
> - "not-yet-reviewed" :: automatically set for all submissions
> - "reviewed-needs-fix" :: set explicitly by the reviewer
> - "needs-another-review" :: automatically set if there's a revised
>   patch, unless "not-yet-reviewed" (in which case no change)
> - "reviewed-looks-good" :: set explicitly by the reviewer

Would it makes sense to have a "does-not-apply" tag too?

I believe that would help sorting old those old patches that don't apply
anymore.

> In addition to the above, it might also help for there to be an
> additional tag of "might-not-need-review" (or simpler,
> "review-not-needed") which gets automatically set, provided we implement
> a way to label some changes (for some packages) as being "trivial enough
> that they're okay as long as build succeeds".
>
> On a related note, is it possible for a reviewer who isn't a committer
> to set debbugs tags?
>
> [dev manual]: 
> 
>
>> It would be great to agree those - try them for a bit - and document
>> them in a 'howto' so that everyone uses the same process.
>
> In addition to documenting the tags in the "Debbugs Usertags" section of
> the manual, it would help for there to be a "howto" which focuses more
> on the transition between the tags (i.e., the contribution workflow).