[netbsd] libmacchina fails to build following `vergen` dependency addition

[grtcdr]

====
   Compiling git2 v0.13.21
error[E0609]: no field `uid` on type `&Process`
   --> /usr/pkgsrc/wip/macchina/work/vendor/vergen-5.1.15/src/feature/si.rs:265:28
    |
265 |     *user.uid() == process.uid
    |                            ^^^ unknown field

error: aborting due to previous error

For more information about this error, try `rustc --explain E0609`.
error: could not compile `vergen`

To learn more, run the command again with --verbose.
*** Error code 101

Stop.
bmake[1]: stopped in /usr/pkgsrc/wip/macchina
*** Error code 1

Stop.
bmake: stopped in /usr/pkgsrc/wip/macchina
====

[grtcdr]

@uttarayan21 does vergen not work on NetBSD?

[uttarayan21]

I haven't actually tried to cross compile it for netbsd, So I don't know. I'll try to compile on my local machine tomorrow.

[grtcdr]

Me neither, and it's a little unfortunate that I removed NetBSD from our actions right before the feature was added.

[uttarayan21]

Haha that's true and theres no netbsd check for libmacchina in the first place.

[grtcdr]

Yeah...

[uttarayan21]

Seems to build fine on my machine on the latest commit as well as 0.8.1

[grtcdr]

Can you try building macchina?

[uttarayan21]

Compiling macchina gives me a linker ( the x11 ) error but vergen seems to compile.

[grtcdr]

That's weird, pin can't seem to compile the program... I'll have a deeper look into this, as I'm also looking into completely removing X11 bindings as they don't seem to be working (linux is prefering /sys/class/drm for some reason) and I'm pretty sure NetBSD is using ACPIVGA rather than X11.

[grtcdr]

Brought back NetBSD for macchina's actions and it isn't failing; which begs the question: why is it failing on actual systems running NetBSD?

[uttarayan21]

Haha ! No clue as to why that is. I guess some rust library mismatch or something.

[grtcdr]

I'm building it as we speak in a VM

[grtcdr]

Same issue as reported, should we file this?

[uttarayan21]

Yeah probably should file this. Compiles when cross compiled but not when native lol.

[grtcdr]

Compiles when cross compiled but not when native lol.

Yeah, confusing...

I filed an issue at vergen when it should have been in git2-rs

[grtcdr]

@uttarayan21

I have reason to believe that the error is only produced on versions of Rust < 1.54.0, as our runners are all on that version and they have no problem compiling the code.

pkgsrc, NetBSD's package manager, packages Rust 1.52.0 at the time of writing this, so this could be a version incompatibility issue.

I'll keep you posted if it turns out to be something else.

[uttarayan21]

Ah I see. I thought that could happen.

[grtcdr]

I didn't lol, I was scrambling for ideas until pin asked about the version we were running

[0323pin]

Rust-1.54.0 NetBSD-current

So, I've created a GitHub account in order to have easier communication. I still can't compile any version of macchina after 0.9.2 because of the vergen crate. git2 is not an issue, it compiles just fine as a dependency of onefetch.

Here's the error,

error[E0609]: no field uid on type &Process --> /usr/pkgsrc/wip/macchina/work/vendor/vergen-5.1.15/src/feature/si.rs:265:28 | 265 | *user.uid() == process.uid | ^^^ unknown field

error: aborting due to previous error

For more information about this error, try rustc --explain E0609. error: could not compile vergen

To learn more, run the command again with --verbose. *** Error code 101

Stop.

I've tried building it with the following patch vergen = { version = "5.1.15", default-features = false, features = ["build","cargo","git","rustc"] } but, it still fails. I wonder why it's trying to build si even after disableing the future.

[grtcdr]

Hey pin!

My guess is that we're making calls to vergen methods even if you try to disable the features, one way to get around this is if we disable them for NetBSD, until vergen maintainers add support for the platform.

[0323pin]

@grtcdr can we please do this? I'll post the message above on the vergen issue you've raised.

My guess is that we're making calls to vergen methods even if you try to disable the features

Care to explain it? It's failing at build time.

I could try to build vergen on it's own, if that helps. Still puzzled why you are able to cross-compile.

[grtcdr]

In build.rs (both macchina and libmacchina) we should set up a check so it doesn't export the commit version and fail at build time for NetBSD.

I'll do this when as soon as I can :)

[grtcdr]

I should've anticipated this; leaving early before any vergen code is executed does not resolve the issue (tested it in my VM), but I'll leave it there for now. Maybe I can come up up with something...

[0323pin]

@grtcdr thank you for looking into this, I'll be patient :)

[0323pin]

Building vergen as a standalone crate fails with the same error. However, building it with the si feature disabled compleates successfuly.

===> Building for vergen-5.1.15
   Compiling libc v0.2.101
   Compiling autocfg v1.0.1
   Compiling proc-macro2 v1.0.29
   Compiling unicode-xid v0.2.2
   Compiling syn v1.0.76
   Compiling version_check v0.9.3
   Compiling pkg-config v0.3.19
   Compiling tinyvec_macros v0.1.0
   Compiling matches v0.1.9
   Compiling rustversion v1.0.5
   Compiling unicode-bidi v0.3.6
   Compiling semver v1.0.4
   Compiling log v0.4.14
   Compiling percent-encoding v2.1.0
   Compiling anyhow v1.0.44
   Compiling cfg-if v1.0.0
   Compiling bitflags v1.3.2
   Compiling num-traits v0.2.14
   Compiling num-integer v0.1.44
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling tinyvec v1.4.0
   Compiling form_urlencoded v1.0.1
   Compiling unicode-normalization v0.1.19
   Compiling jobserver v0.1.24
   Compiling time v0.1.44
   Compiling quote v1.0.9
   Compiling idna v0.2.3
   Compiling rustc_version v0.4.0
   Compiling cc v1.0.70
   Compiling url v2.2.2
   Compiling libz-sys v1.1.3
   Compiling libgit2-sys v0.12.23+1.2.0
   Compiling chrono v0.4.19
   Compiling thiserror-impl v1.0.29
   Compiling enum-iterator-derive v0.7.0
   Compiling vergen v5.1.15 (/usr/pkgsrc/wip/vergen/work/vergen-5.1.15)
   Compiling thiserror v1.0.29
   Compiling enum-iterator v0.7.0
   Compiling getset v0.1.1
   Compiling git2 v0.13.22
    Finished release [optimized] target(s) in 7m 55s
$ 

[grtcdr]

Good to hear that it's somewhat finally working, does macchina launch just fine?

[0323pin]

@grtcdr This was building vergen standalone with the si feature off. I can not build macchina itself even patching Cargo.toml to turn the feature off. Maybe you guys could try to make it possible to disable the si feature.

[grtcdr]

Is this what you're using?

[build-dependencies]
vergen = { version = "5.1.15", default-features = false, features = ["build","cargo","git","rustc"] }

[0323pin]

@grtcdr I have an idea actually. I was using the above on macchina Cargo.toml, which doesn't help. This is probably bacause the feature is sill being called from libmacchina Cargo.toml.

Do you you want me to try to patch both Cargo.toml files and regenerate the Cargo-lock for both. I could try to build macchina then.

[grtcdr]

Yeah, please, go ahead :)

[0323pin]

@grtcdr I can't seem to patch libmacchina Cargo.toml as the file is set to autoupdate when something changes. This causes the patch to be rejected as there are mismatches :(

[grtcdr]

I'm not sure what you mean, libmacchina is sourced through its latest version (from crates.io), how does your patch work?

[0323pin]

This has to do with how patches are applied in pkgsrc. One way to see if this works would be to use vergen = { version = "5.1.15", default-features = false, features = ["build","cargo","git","rustc"] } instead of vergen = "5.1.15"

in both macchina and libmacchina Cargo.toml files.

[grtcdr]

Oh, so you'd like me to apply these specific changes?

[uttarayan21]

Still seems to build fine in a docker container for me though. (main branch / no changes )

[grtcdr]

Thing is, cross is giving a false positive; building it in a native/VM environment throws the expected errors.

[0323pin]

@grtcdr Give me one more try, I'll try to fool the system ;)

@uttarayan21 The problem is sysinfo has basically no support for NetBSD. I guess the issues are only visible when compiling natively.

[uttarayan21]

Ah so that's the problem. I'm curious what happens with the resulting binary though.

[grtcdr]

Ah so that's the problem. I'm curious what happens with the resulting binary though.

Me too, panic on --version maybe?

[0323pin]

Ok, I'll try to explain why I can patch macchina's Cargo.toml but not libmacchina's one. When patching inside pkgsrc with the systems patching tool a copy of the original file to be patches is copied to file-name.orig and the patch is represented by a new file file-name Then a diff -u is applied to generate the unified diff which is applied at build time.

For macchina inside the build directory you will then find Cargo.toml and Cargo.toml.orig. But, libmacchina is set to pull the dependencies from crates.io at build time, which means that inside the build directory there are already Cargo.toml.orig, the one in your repo and a Cargo.toml, which has the updated dependencies. This results in a diff -u operation between the two and a broken patch. Unfortunately the naming of the files is the same as use by pkgsrc and this causes the issue.

The only way I currently see to be able to test this is if you guys could apply the change suggested above, maybe in a seperate branch and provide an rc-release, test-release or alpha. I can then try the build and if it works you can merge, if not, we are simply looking in the wrong place.

vergen does build standalone if I disable the si-feature.

[grtcdr]

Okay, I see how the pieces are connected now.

I'll start working on an alpha release when I get home :)

[0323pin]

@grtcdr Thanks! Perhaps revert your last two changes to see if it builds with only the vergen change compared to the latest release. Up to you really.

[uttarayan21]

Ah so that's the problem. I'm curious what happens with the resulting binary though.

Me too, panic on --version maybe?

@0323pin @grtcdr

Since I was curious I made a netbsd kvm and tested the binary built from docker and It didn't panic and actually seems to work.

Edit: The latest commit also works

[grtcdr]

Whaaat... You gotta let us in on your secret.

[0323pin]

@grtcdr He's running a docker-built binary and not a native built one. @uttarayan21 Actually, it doesn't surprise me that much. Since, you are apparently not using the sysinfo bits, why should it panic?

I run nushell and it doesn't panic but any functionality that depends on sysinfo simply returns nothing. This is why I believe that removing the si-feature from vergen on both macchina and libmacchina will solve the problem.

Anyway, good to know the docker binary is running without panic but, it does not help us shipping a natively built binary.

[uttarayan21]

That's true running --doctor reveals that the kernel readout fails. I'm learning how to use netbsd a bit to test out some more and try out building it natively right now. Edit: Screenshot.

[grtcdr]

Kernel should fail on NetBSD, so no worries there.

[0323pin]

@uttarayan21 the only one worrying me right now it's resolution :( I guess you don't have a DE installed and a WM needs wmctrl installed. There have been some issues with pkg count since the database default location has moved and configurations may end-up in a split-brain situation. Finally, I'd guess battery has no meaning inside a vitual machine.

[uttarayan21]

Yeah its a fresh install without x11 and with nothing but sshd and dhcp enabled. So thats why many stuff might not work.

[grtcdr]

Resolution doesn't require X11. After we started utilizing the ACPIVGA driver for NetBSD, and using /sys/class/drm for Linux, I decided to ditch X11.