Re: [Rpm-maint] [rpm-software-management/rpm] Clean up applyAttr() and rpmfcHelper() interaction (PR #3101)

2024-05-15 Thread Panu Matilainen
Merged #3101 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3101#event-12827802004 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mail

[Rpm-maint] [rpm-software-management/rpm] Clean up applyAttr() and rpmfcHelper() interaction (PR #3101)

2024-05-15 Thread Panu Matilainen
Apply the attributes in applyAttr() as per the name, and pass *that* index array to rpmfcHelper() which only needs to concern itself with generating the path arrays as per the used protocol. No functional changes, doing this in "raw C" because this refactor is worth cherry-picking to 4.20 too,

Re: [Rpm-maint] [rpm-software-management/rpm] Convert major librpmbuild structs to native C++ allocation / initialization (PR #3099)

2024-05-15 Thread Panu Matilainen
@pmatilai commented on this pull request. > } StringBuf freeStringBuf(StringBuf sb) { -if (sb) { - sb->buf = _free(sb->buf); - sb = _free(sb); -} -return sb; +delete sb; There will also need to be stuff like mass-moving to the C++-versions of C headers, convert

Re: [Rpm-maint] [rpm-software-management/rpm] Convert major librpmbuild structs to native C++ allocation / initialization (PR #3099)

2024-05-15 Thread Panu Matilainen
@pmatilai commented on this pull request. > } StringBuf freeStringBuf(StringBuf sb) { -if (sb) { - sb->buf = _free(sb->buf); - sb = _free(sb); -} -return sb; +delete sb; Oh, absolutely. This is really just stage 1 of the C++ onboarding, with many more to follow

Re: [Rpm-maint] [rpm-software-management/rpm] Convert major librpmbuild structs to native C++ allocation / initialization (PR #3099)

2024-05-15 Thread Daniel Alley
@dralley commented on this pull request. > } StringBuf freeStringBuf(StringBuf sb) { -if (sb) { - sb->buf = _free(sb->buf); - sb = _free(sb); -} -return sb; +delete sb; I assume / hope there's an intention to move away from `new` / `delete` at a later stage of

[Rpm-maint] [rpm-software-management/rpm] Non-root owned symlink causes install failure (Issue #3100)

2024-05-15 Thread Michal Domonkos
**Describe the bug** Installing a package that ships a file in a directory symlink that's owned by a non-root user results in a cpio unpacking error. **To Reproduce** Steps to reproduce the behavior: 1. `useradd user` 2. `chown -h user /lib` 3. `dnf install -y kernel-core` **Expected behavior**

Re: [Rpm-maint] [rpm-software-management/rpm] Convert major librpmbuild structs to native C++ allocation / initialization (PR #3099)

2024-05-15 Thread Panu Matilainen
@pmatilai pushed 1 commit. 05f1578f82cb5d2fc8911c6c14ccb78e4f87f5f8 Replace rpmhash with STL unordered_multimap in file rename tracking -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3099/files/46e7fbfcd4a8534395f0a13c1d6b982410fa3916..05f1578f82cb5d2fc8911c6c14ccb78

[Rpm-maint] [rpm-software-management/rpm] Convert major librpmbuild structs to native C++ allocation / initialization (PR #3099)

2024-05-15 Thread Panu Matilainen
Details in the commits, in brief this brings the major data structures of librpmbuild under C++ native allocation and initialization, making it possible to use native data types in said structs. A few "obvious" cases converted to STL too, but plenty more to do on that department. You can view, c

Re: [Rpm-maint] [rpm-software-management/rpm] Implement merging of new key material when importing pubkeys (PR #3083)

2024-05-15 Thread Panu Matilainen
> the "legacy" backend @mlschroe , I didn't quite expect you to start so actively hacking on it, more like terminal care and hence the name. If you intend to continue developing it, I'm okay with renaming it to something else than "legacy". Only it can't be "internal" anymore because it's not :