Summary: | devel/librashader: update to 0.4.5 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Stefan Schlosser <bsdcode> | ||||||||
Component: | Individual Port(s) | Assignee: | Robert Clausecker <fuz> | ||||||||
Status: | Closed FIXED | ||||||||||
Severity: | Affects Only Me | CC: | fuz | ||||||||
Priority: | --- | ||||||||||
Version: | Latest | ||||||||||
Hardware: | Any | ||||||||||
OS: | Any | ||||||||||
URL: | https://github.com/SnowflakePowered/librashader/releases/tag/librashader-v0.4.3 | ||||||||||
Attachments: |
|
Description
Stefan Schlosser
2024-09-15 22:32:00 UTC
Created attachment 253593 [details]
0002-emulators-ares-bump-PORTREVISION.patch
I have added a second patch to bump the PORTREVISION of emulators/ares, just in case this is necessary.
librashader upstream promises no ABI breakage until version 0.5.0, this is also reflected in the SONAME of librashader.so. So bumping the PORTREVISION of emulators/ares shouldn't actually be necessary. I also tested the new librashader.so with the previous build 140_1 version of emulators/ares and it worked without problems.
What is the general guideline for updating ports in this situation?
Please resubmit your patch to be against the currently committed version 0.4.2 of devel/librashader. Bumping reverse dependencies is not necessary if the library API is compatible to the old one. (In reply to Robert Clausecker from comment #2) Thanks for your explanation. In this case there is nothing more to do aside from removing/obsoleting the second patch, because emulators/ares already got PORTREVISION bumped when version 0.4.2 of devel/librashader got committed. Comment on attachment 253593 [details]
0002-emulators-ares-bump-PORTREVISION.patch
The API of devel/librashader hasn't changed, so bumping the PORTREVISION of emulators/ares isn't neccessary.
Upstream has released version 0.4.5, which is mostly a bugfix release. I'd like to update my patch to this version. Will provide the patch soon. Shall I hold this update if I finish the current patch before you get around to uploading a new batch or is it ok if I commit it anyway? (In reply to Robert Clausecker from comment #6) Please commit it anyway. I'm currently testing version 0.4.5 with emulators/ares and it seems there's a bug. There's a little bit to sort out before we can update to 0.4.5. Thanks. Created attachment 253741 [details]
0001-devel-librashader-update-to-0.4.5.patch
Nevermind, it was a user-error. Version 0.4.5 is working fine with emulators/ares. So here is the updated patch for devel/librashader.
On it! A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e1f689b9c64e02a8c488d0c7bf8608f5803dff77 commit e1f689b9c64e02a8c488d0c7bf8608f5803dff77 Author: Stefan Schlosser <bsdcode@disroot.org> AuthorDate: 2024-09-15 21:39:14 +0000 Commit: Robert Clausecker <fuz@FreeBSD.org> CommitDate: 2024-09-25 06:28:06 +0000 devel/librashader: update to 0.4.5 Changes: https://github.com/SnowflakePowered/librashader/releases/tag/librashader-v0.4.3 https://github.com/SnowflakePowered/librashader/releases/tag/librashader-v0.4.5 Version 0.4.3 allows building on stable Rust, so the port has switched from building with lang/rust-nightly to lang/rust. When building on stable Rust, upstream's librashader-build-script doesn't generate the C headers anymore. The port has to package the pre-generated headers instead. This shouldn't have any user-visible effects for consumers. Version 0.4.4 was skipped due to a release configuration error. PR: 281525 Event: EuroBSDcon 2024 devel/librashader/Makefile | 10 ++- devel/librashader/Makefile.crates | 60 ++++-------------- devel/librashader/distinfo | 126 ++++++++------------------------------ 3 files changed, 43 insertions(+), 153 deletions(-) Thank you for your contribution. |