Re: Handling crate updates
by the Mulhern
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
1 year, 2 months
Handling crate updates
by h-k-81＠hotmail.com
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 year, 2 months
EPEL8 support
by Orion Poplawski
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/
1 year, 2 months
Rust packaging tools "next generation" ready for testing
by Fabio Valentini
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/moni...
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 year, 2 months
Re: fallible_collections crate fails to build on i686 arch
by Josh Stone
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 year, 2 months
Re: fallible_collections crate fails to build on i686 arch
by Fabio Valentini
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
1 year, 2 months
Re: fallible_collections crate fails to build on i686 arch
by Fabio Valentini
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 year, 2 months
