Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)

2023-02-10 Thread Gordon Messmer
Does anyone have any opinions on whether the version needs to be massaged in any way? Libtool's version system is ... kinda weird. In most cases, we probably only really care about the leading number, and using the second is more restrictive than strictly necessary. I'm OK with that, but I

Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)

2023-02-10 Thread Gordon Messmer
Is everyone happy with the naming of things? Especially the macro and the command line option? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-1426130025 You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)

2023-02-10 Thread Gordon Messmer
> there's no requirement to run elfdeps through chroot OK. I just wanted to be clear that those tests weren't run in chroot for a reason. > add a corresponding AT_SKIP_IF() in the tests Thanks. Tests are conditional now with coverage of both GNU and non-GNU builds. -- Reply to this email

Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)

2023-02-10 Thread Gordon Messmer
@gordonmessmer pushed 1 commit. 159dd2d9ddef13c1b7a55b1007007619a62739eb Add tests for the elf dependency generator fallback version feature. -- View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)

2023-02-10 Thread Panu Matilainen
> the tests would need to be conditional on the presence of dlmopen(), but I'm > not sure how that works in this framework. You can communicate this kind of a thing to the test-suite via tests/atlocal.in (the WITH_CAP example probably being most similar to this), and then just add a

Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)

2023-02-10 Thread Panu Matilainen
We're working to replace fakechroot so that's a (relatively) short-term concern. And actually there's no requirement to run elfdeps through chroot (fake or otherwise) because it's a self-contained, non-privileged thing. Then again, the added tests seem to be working okay as this is passing CI.

Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate RPMTAG_NOT_FOUND signedness mismatch, take II (PR #2391)

2023-02-10 Thread Panu Matilainen
Merged #2391 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2391#event-8488189803 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: store SBOM data in rpm headers? (Issue #2389)

2023-02-10 Thread Panu Matilainen
Both #1532 and #607 seem to touch on the same subject. I'm not opposed at all in principle, the question is more in the details: should the info be in the header of each binary package, or would a buildinfo-style file/subpackage (with a strong identifier tying it to the same build) be enough?

Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate RPMTAG_NOT_FOUND signedness mismatch, take II (PR #2391)

2023-02-10 Thread Panu Matilainen
@pmatilai pushed 1 commit. c0c2a33314c05c3ecfcaa0e956fc546664567703 Use proper type for copyTagsFromMainDebug -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2391/files/5b8a35cfc5aa2dcdd40d10bee96dce4fea9c5ec0..c0c2a33314c05c3ecfcaa0e956fc546664567703 You are