Source: rust-polling
Version: 3.4.0-1
Severity: wishlist
Tags: help
User: debian-loongarch@lists.debian.org
Usertags: loong64

Dear maintainers,

The package librust-async-io-2+default-dev blocked compilation of 29
packages in the Debian Package Auto-Building environment.
The dependency state of rust-async-io is as follows,
```
Dependency installability problem for rust-async-io on loong64:
rust-async-io build-depends on missing:
- librust-polling-3+default-dev:loong64
```
After analyzing the package rust-async-io, I found out that it's because compilation of rust-polling failed.
The build log of rust-polling can be found at https://buildd.debian.org/status/logs.php?pkg=rust-polling&ver=3.4.0-1&arch=loong64.

I have built the rust-polling successfully in my local loong64
environment, without modifications required.
```
......
   dh_md5sums -O--buildsystem=cargo
   dh_builddeb -O--buildsystem=cargo
dpkg-deb: building package '../librust-polling-dev_3.4.0-1_loong64.deb'
in 'librust-polling-dev'。
dpkg-genbuildinfo -O../rust-polling_3.4.0-1_loong64.buildinfo
dpkg-genchanges -O../rust-polling_3.4.0-1_loong64.changes

```
Please try to rebuild rust-polling for loong64 in the Debian Package Auto-Building environment.
If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I have built the rust-polling successfully in my local loong64
environment, without modifications required.

Make sure you are not using DEB_BUILD_OPTIONS=nocheck

since rust crates don't have stable ABIs and cargo doesn't support
pre-built rust crates, librust* packages contain source code rather
than binaries of any sort.

The package build process does a test build to check that the code
is actually buildable before packaging but this is skipped if DEB_BUILD_OPTIONS=nocheck is set.

Please try to rebuild rust-polling for loong64 in the Debian Package Auto-Building environment.

It failed again.

I've taken a quick look at the code, but I'm not seeing anything
obvious. The definitions in linux-raw-sys seem to exist, at least
accoding to the error messages. I notice that the reexports of those definitions are gaurded behind a target_pointer_bits guard, it may
be worth checking if rustc is setting that correctly on your
architecture (though if it isn't, I'd expect that to cause a lot
of problems)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Hi,

On Thu, 7 Mar 2024 14:39:31 +0000 Peter Green wrote:

I have built the rust-polling successfully in my local loong64 environment, without modifications required.

Make sure you are not using DEB_BUILD_OPTIONS=nocheck

I didn't use any DEB_BUILD_OPTIONS in my local ENV.
After comparing, I found that the packages version I used when compiling rust-polling locally were different from the current Debian
Auto-Building packages version, for examples:
- My local ENV
   Compiling libc v0.2.150   //Note that
   Compiling rustix v0.38.25
   Compiling linux-raw-sys v0.4.11
   Compiling pin-project-lite v0.2.13
   Compiling cfg-if v1.0.0
   Compiling bitflags v2.4.0
   Compiling tracing-core v0.1.30
- Debian Package Auto-Building ENV
   Compiling libc v0.2.150   //Note that
   Compiling rustix v0.38.25
   Compiling linux-raw-sys v0.4.11
   Compiling pin-project-lite v0.2.13
   Compiling cfg-if v1.0.0
   Compiling bitflags v2.4.0
   Compiling tracing-core v0.1.30

The error build log of rust-polling is as follows,
```
error[E0425]: cannot find value `FS_IOC_GETFLAGS` in module `c`
    --> /usr/share/cargo/registry/rustix-0.38.30/src/fs/ioctl.rs:142:57 ......
error[E0425]: cannot find value `FS_IOC_SETFLAGS` in module `c`
    --> /usr/share/cargo/registry/rustix-0.38.30/src/fs/ioctl.rs:161:57
     |
161  |         let ctl = ioctl::Setter::<ioctl::BadOpcode<{ c::FS_IOC_SETFLAGS }>, u32>::new(flags.bits());
     | ^^^^^^^^^^^^^^^
     |
    ::: /usr/share/cargo/registry/libc-0.2.152/src/unix/linux_like/linux/mod.rs:2922:1 ......
```

Please try to rebuild rust-polling for loong64 in the Debian Package Auto-Building environment.

It failed again.

Analyzed by our rust team, due to rust libc 0.2.152 missing LoongArch's FS_IOC_{G,S}{ETVERSION,ETFLAGS} related symbol bindings.
The following commit (Add ioctl FS_IOC_{G,S}{ETVERSION,ETFLAGS} for LoongArch64) can resolve this question: https://github.com/rust-lang/libc/commit/9a074313961e93a0f38fab26b72a4fc393ed1148

Could the above commit "Add ioctl FS_IOC_{G,S}{ETVERSION,ETFLAGS} for LoongArch64" be backpunched to Debian rust-libc 0.2.152-1。
Or wait for the next upstream version of rust-lang/libc.
What about your suggestion?


Thanks,
Dandan Zhang

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi, <br>
</p>
<p>On Thu, 7 Mar 2024 14:39:31 +0000 Peter Green <plugwash@debian.org>
wrote:</plugwash@debian.org></p>
<p><plugwash@debian.org></plugwash@debian.org></p>
<plugwash@debian.org>&gt; &gt; I have built the rust-polling
successfully in my local loong64 <br>
&gt; &gt; environment, without modifications required.<br>
&gt; <br>
&gt; Make sure you are not using DEB_BUILD_OPTIONS=nocheck<br>
&gt; <br>
<br>
I didn't use any DEB_BUILD_OPTIONS in my local ENV.<br>
After comparing, I found that the packages version I used when
compiling rust-polling locally were different from the current
Debian Auto-Building packages version, for examples:<br>
- My local ENV<br>
   Compiling libc v0.2.150   //Note that<br>
   Compiling rustix v0.38.25<br>
   Compiling linux-raw-sys v0.4.11<br>
   Compiling pin-project-lite v0.2.13<br>
   Compiling cfg-if v1.0.0<br>
   Compiling bitflags v2.4.0<br>
   Compiling tracing-core v0.1.30<br>
- Debian Package Auto-Building ENV<br>
   Compiling libc v0.2.150   //Note that<br>
   Compiling rustix v0.38.25<br>
   Compiling linux-raw-sys v0.4.11<br>
   Compiling pin-project-lite v0.2.13<br>
   Compiling cfg-if v1.0.0<br>
   Compiling bitflags v2.4.0<br>
   Compiling tracing-core v0.1.30<br>
<br>
The error build log of rust-polling is as follows,<br>
```<br>
error[E0425]: cannot find value `FS_IOC_GETFLAGS` in module `c`<br>
    --&gt;
/usr/share/cargo/registry/rustix-0.38.30/src/fs/ioctl.rs:142:57 <br>
......<br>
error[E0425]: cannot find value `FS_IOC_SETFLAGS` in module `c`<br>
    --&gt;
/usr/share/cargo/registry/rustix-0.38.30/src/fs/ioctl.rs:161:57<br>
     |<br>
161  |         let ctl = ioctl::Setter::&lt;ioctl::BadOpcode&lt;{
c::FS_IOC_SETFLAGS }&gt;, u32&gt;::new(flags.bits());<br>
     |                                                        
^^^^^^^^^^^^^^^<br>
     |<br>
    ::: /usr/share/cargo/registry/libc-0.2.152/src/unix/linux_like/linux/mod.rs:2922:1<br>
......<br>
```<br>
<br>
&gt; &gt; Please try to rebuild rust-polling for loong64 in the
Debian Package <br>
&gt; &gt; Auto-Building environment.<br>
&gt; <br>
&gt; It failed again.<br>
</plugwash@debian.org><br>
Analyzed by our rust team, due to rust libc 0.2.152 missing
LoongArch's FS_IOC_{G,S}{ETVERSION,ETFLAGS} related symbol bindings.<br>
The following commit (Add ioctl FS_IOC_{G,S}{ETVERSION,ETFLAGS} for
LoongArch64) can resolve this question:<br>
<a class="moz-txt-link-freetext" href="https://github.com/rust-lang/libc/commit/9a074313961e93a0f38fab26b72a4fc393ed1148">https://github.com/rust-lang/libc/commit/9a074313961e93a0f38fab26b72a4fc393ed1148</a><br>
<br>
Could the above commit "Add ioctl FS_IOC_{G,S}{ETVERSION,ETFLAGS}
for LoongArch64" be backpunched to Debian rust-libc 0.2.152-1。<br>
Or wait for the next upstream version of rust-lang/libc.<br>
What about your suggestion?<br>
<br>
<br>
Thanks,<br>
Dandan Zhang<br>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)