Rust February 2023

rust@lists.fedoraproject.org

6 participants
8 discussions

Re: Handling crate updates
by the Mulhern 27 Feb '23

27 Feb '23

Hi! I always regenerate using rust2rpm; I think it saves trouble. Among other things, upstream may have added a new feature (or removed one). If so then rust2rpm will properly generate the appropriate sub-packages corresponding to the possible feature combinations. Also, rust2rpm itself undergoes updates which incorporate changes which reflect the current Fedora packaging guidelines. - mulhern On Sun, Feb 26, 2023 at 4:23 PM <h-k-81(a)hotmail.com> wrote: > > Hello everyone > > > I was wondering how the rust-sig / rust folks handle crate updates. > Let's say you generate a spec file with `rust2rpm` and manually patch > it. The reason is not important here. Then a week later the upstream > releases a new version. How do you handle this? Do you regenerate the > spec file with `rust2rpm` and reapply your patches or do you update the > spec file yourself? Should this be documented in the "Rust Packaging > Guidelines"? > > > Hussein > _______________________________________________ > Rust mailing list -- rust(a)lists.fedoraproject.org > To unsubscribe send an email to rust-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/rust@lists.fedoraproject.org > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

2 1

Handling crate updates
by h-k-81＠hotmail.com 26 Feb '23

26 Feb '23

Hello everyone I was wondering how the rust-sig / rust folks handle crate updates. Let's say you generate a spec file with `rust2rpm` and manually patch it. The reason is not important here. Then a week later the upstream releases a new version. How do you handle this? Do you regenerate the spec file with `rust2rpm` and reapply your patches or do you update the spec file yourself? Should this be documented in the "Rust Packaging Guidelines"? Hussein

1 0

EPEL8 support
by Orion Poplawski 20 Feb '23

20 Feb '23

Is there any possibility of reasonable rust support in EPEL8? At the moment we don't have rust-packaging or cargo2rpm/rust2rpm. CentOS stream 8 seems to have rust/carge 1.66.1 and rust-srpm-macros 5-2. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

3 4

Rust packaging tools "next generation" ready for testing
by Fabio Valentini 16 Feb '23

16 Feb '23

Hello fellow Rustaceans and / or frustrated Rust packagers, My work on the "next generation" of Rust packaging tools has finally progressed to the point where it can be tested by actual people. :) Adding support for new features of cargo - "namespaced dependencies" (`dep:foo`) and "weak dependency features" (`foo?/bar`) syntax for feature dependencies; both stable since Rust 1.60.0 - proved to be very difficult in the existing rust2rpm code base, which is why I implemented a new backend for RPM BuildRequires, Requires, and Provides generators (the cargo2rpm binary and Python package). I have already adapted all RPM macros to depend on cargo2rpm instead of rust2rpm / cargo-inspector. Building RPM packages no longer pulls in any part of rust2rpm, which is only needed for generating spec files (and patches) now. For now, only changes that were absolutely necessary to make rust2rpm work for the new cargo features were implemented. In the near future, I plan to pull out the old cargo metadata handling from rust2rpm, and replace it with API calls to cargo2rpm. Project structure and packaging now looks like this: - cargo2rpm: provides /usr/bin/cargo2rpm and cargo2rpm Python package for low-level functionality - rust-packaging: provides rust-rpm-macros, rust-srpm-macros, and cargo-rpm-macros; depends on cargo2rpm for implementing the backend for some RPM macros and generators - rust2rpm: spec file generator (some parts of the backend are still going to be modernized and / or replaced by functions now implemented in cargo2rpm) I've prepared a COPR with test builds of these three packages: https://copr.fedorainfracloud.org/coprs/decathorpe/rust-packaging-ng/monito… Running test builds against these new RPM macros is easy with this mock config: https://github.com/decathorpe/rust-packaging-ng/blob/main/copr.cfg For testing spec file generation, packages from the COPR will need to be installed on the host system where "rust2rpm" is run. For example: After enabling the COPR repo and updating all packages to the latest version, running "rust2rpm" for existing Rust package should produce the same results as before, and for crates that use the new syntax in their feature dependencies, it should produce valid spec files. Building the packages against the new RPM macro implementations can then be done with something like "mock -r ./path/to/copr.cfg ./path/to/src.rpm` (with paths pointing at the mock config linked above and the SRPM to be built, respectively). All packages should have their Provides and Obsoletes set up correctly for upgrades from existing installs of rust2rpm to work as expected. Version numbers are also intended to be transparently upgraded to the "stable" release of these tools once they are pushed to Fedora. At this point, I still expect there to be some rough edges. I only finished implementing the final pieces earlier today. Please report back if you see anything that doesn't work as expected. The new code in cargo2rpm has over 95% test coverage - getting more weird data as input to tickle out the last edge cases would be great ;) The latest version of the RPM macros now lives in a repository separate from rust2rpm: https://pagure.io/fedora-rust/rust-packaging The cargo2rpm executable and Python package are maintained here: https://pagure.io/fedora-rust/cargo2rpm And rust2rpm continues to be maintained here (though I have not pushed my latest patches there yet, and the RPM macros are still in the repo even though I moved further development to a separate project): https://pagure.io/fedora-rust/rust2rpm The spec files and patches for the packages in COPR are also public: https://github.com/decathorpe/rust-packaging-ng I will continue working on these three components until I think the new versions / packages are ready to be pushed to rawhide, which I will announce in advance. Until the updates are ready, please DO NOT push packages that use `dep:foo` or `foo?/bar` syntax in their feature dependencies to rawhide. Doing so *might* work with or without workarounds, but the resulting packages *will definitely be broken*. Happy testing, Fabio

1 1

Re: fallible_collections crate fails to build on i686 arch
by Josh Stone 03 Feb '23

03 Feb '23

On 2/3/23 12:55 AM, blinxen wrote: > So what your saying is that because we create a memory layout for a > single u8 value > and then set it as the pointer for the Vec which we then trick into > thinking that it has a lot of memory causes UB? > This would mean that what I wrote into the issue is completely wrong? Is > that correct? Right, AFAICT the self.get_unchecked_mut(len) is somewhat ok -- it's at least a pointer to allocated memory, although creating &mut T to uninitialized memory (past the end of the proper slice) is not good either. That should really use pointer add, and I think I'll send a PR for that. But the actual crash you're experiencing is while reading the input slice. The weird 133937 index number is just because there happens to be mapped memory near that u8 allocation for some distance, then it crashes on unmapped memory. It's all UB reading after the first byte though.

1 0

Re: fallible_collections crate fails to build on i686 arch
by Fabio Valentini 03 Feb '23

03 Feb '23

On Thu, Feb 2, 2023 at 10:14 PM <h-k-81(a)hotmail.com> wrote: > > Hello everyone > > > While trying to fix the build of the `rust-fallible_collections` package > I found out [1] that the crate does not work properly with 32 bit systems. > I am not quite sure if my findings are 100% accurate but lets say they > are. What would be the best option here? Adding "ExcludeArch" to the > spec file? > > Thank you for you answers in advance! Hi! I'm not familiar with this crate's code (it might be fine, for all I know), but the tests themselves look like they're just begging for UB and crashes :) I think Josh is more familiar with this kind of stuff, but I think it *should* be safe to just skip the test that crashes for Fedora builds of rust-fallible_collections. Side note: You might not even really need this crate - many APIs for fallible allocations have recently been added to the Rust standard library. For example Vec::try_reserve has been stable since Rust 1.57: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.try_reserve So depending on what the crate that depends on these APIs needs, you might be able to ditch the dependency on fallible_collections entirely. Fabio

4 3

Re: fallible_collections crate fails to build on i686 arch
by Fabio Valentini 02 Feb '23

02 Feb '23

On Thu, Feb 2, 2023 at 10:48 PM <h-k-81(a)hotmail.com> wrote: > > Well this is awkward, I unretired the `rust-fallible_collections` > package because it is a dependency of a dependency > but after checking again I don't really need the first dependency. > It is only needed for benchmarks und I recently learned that I can just > remove such dependencies. So yeah.... > > > Should I just retire it again? I don't mind maintaining it, but if you > say that it is no longer needed > because the APIs are getting stabilized in the standard library then it > wouldn't make sense to keep it. Oh, even better :D I would wait with the retirement until everything you need has been built for Fedora and we're actually sure nothing depends on it. Going through the retirement / unretirement process multiple times wastes releng time :) Fabio

1 0

fallible_collections crate fails to build on i686 arch
by h-k-81＠hotmail.com 02 Feb '23

02 Feb '23

Hello everyone While trying to fix the build of the `rust-fallible_collections` package I found out [1] that the crate does not work properly with 32 bit systems. I am not quite sure if my findings are 100% accurate but lets say they are. What would be the best option here? Adding "ExcludeArch" to the spec file? Thank you for you answers in advance! Hussein [1] https://github.com/vcombey/fallible_collections/issues/35

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Rust February 2023