Re: [Rpm-maint] [rpm-software-management/rpm] support reproducible automatic rebuilds (PR #2880)

2024-01-30 Thread Panu Matilainen
> This seems to defeat the point. The point of this is to clamp the times to > the date stamp in the changelog. If you're doing automatic rebuilds, you > should not use that feature, full stop. :+1: It looks like an attempt to eat and keep the cake, and we all know how well that works. >

[Rpm-maint] [rpm-software-management/rpm] Add support for address-sanitizer builds and enable on CI (PR #2879)

2024-01-30 Thread Panu Matilainen
Details in commits, but in short - fix a bunch of leaks + other issues found by ASAN - add ENABLE_ASAN build-option to cmake, and enable it on CI going forward You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2879 -- Commit

[Rpm-maint] [rpm-software-management/rpm] RPM 4.19.x bugfix release (Issue #2878)

2024-01-29 Thread Panu Matilainen
There are some pretty nasty bugs in 4.19.1 still, I think we should put out an expedited bugfix release to address at least these regressions: - https://github.com/rpm-software-management/rpm/pull/2843 - https://github.com/rpm-software-management/rpm/pull/2818 Other, less nasty stuff: -

Re: [Rpm-maint] [rpm-software-management/rpm] Noarch RPMs that contain EBPF binaries code incorrectly fail with "Arch dependent binaries in noarch package" (Issue #2875)

2024-01-26 Thread Panu Matilainen
Can you point me to such a specimen? Rpm doesn't know anything about EBPF, the warning/error is based on detecting ELF files which up to now have been pretty arch-specific. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Support building other projects as part of test image (Issue #2877)

2024-01-26 Thread Panu Matilainen
Yep, both rpm-sequoia and popt are something we'd occasionally want to build from sources instead of packaged versions. So this is actually fairly important piece, even if we have managed without it so far. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)

2024-01-26 Thread Panu Matilainen
One thing just for the record, up to now elfdeps has been path agnostic by design to match the dynamic linker: it doesn't matter where those libraries come from as long as they're in the runtime path. Of course it's not an "end user tool" but having consistent output regardless of the file

Re: [Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)

2024-01-26 Thread Panu Matilainen
Actually, we'll need to have this path-discovery wrapped in some libc specific helper script in rpm because this eg musl has an entirely different library search path mechnism. That's fine though, for glibc we could implement our own ld.so.conf parser for the immediate use and then once the

Re: [Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)

2024-01-26 Thread Panu Matilainen
Yeah elfdeps basically ignores all path-aspects, it only really handles DT_NEEDED and DT_SONAME. One thing here though: a manually added require/provide is not equal to one discovered by rpm, the latter are tracked on file-level and rpm actually uses this information. That's why I'm so

Re: [Rpm-maint] [rpm-software-management/rpm] Is there available a macro with package name during processing `%files` section? (Discussion #2876)

2024-01-25 Thread Panu Matilainen
> If there was some macro with package name, I think I could simplify this: > > %{gem_extdir_mri} > %dir %{gem_instdir} > %{gem_libdir} > %{gem_spec -d} If you declared these macros in terms including some %{name} then ... you'd have X number of such identical %files sections, now just even

Re: [Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)

2024-01-25 Thread Panu Matilainen
Note that I'm specifically avoiding talking about filtering these dependencies out because I think in many cases its more useful to turn them into something else instead. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)

2024-01-25 Thread Panu Matilainen
Yes, that possible ld.so.conf fragment in the buildroot needs to be covered. But, I think the hosts ld.so.conf[.d] needs to be processed as well. The currently building package could be installing to a subdirectory that some other package (which would have to be a build-dependency) has declared

Re: [Rpm-maint] [rpm-software-management/rpm] Is there available a macro with package name during processing `%files` section? (Discussion #2876)

2024-01-25 Thread Panu Matilainen
No no. What I'm telling you is to script the file section generation. Something like ``` for n in psych mental; do cat << EOF > ${n}.txt %{ruby_libdir}/${n} %{ruby_libdir}/${n}.rb %{ruby_libarchdir}/${n}.so #... EOF done ``` ...and include from %files with -f. Or make that a spec local macro

Re: [Rpm-maint] [rpm-software-management/rpm] Is there available a macro with package name during processing `%files` section? (Discussion #2876)

2024-01-25 Thread Panu Matilainen
If you have lots of those with nothing but the name changing, no macros will help with that. Generate those files manifests programmatically from %install and include with %files -f. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Testsuite failure with rpm 4.18.2 (Issue #2874)

2024-01-25 Thread Panu Matilainen
:monocle_face: seems most appropriate here... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1910081323 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Testsuite failure with rpm 4.18.2 (Issue #2874)

2024-01-25 Thread Panu Matilainen
So this is actually another bug fixed by a0553eb38a01772254cd48fef7ad116294cf801a -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1910075031 You are receiving this because you are subscribed to this thread. Message

Re: [Rpm-maint] [rpm-software-management/rpm] Testsuite failure with rpm 4.18.2 (Issue #2874)

2024-01-25 Thread Panu Matilainen
Looking at `cpio -t` output is proving more helpful :smile: This from the Ubuntu-created file: > [pmatilai︎localhost tmp]$ cpio -tv < out |head -4 6 blocks drwx-- 1 root root0 Jun 28 2011 ./a/dir -r 1 root root 15 Jun 28 2011 ./a/file drwx--

Re: [Rpm-maint] [rpm-software-management/rpm] Testsuite failure with rpm 4.18.2 (Issue #2874)

2024-01-25 Thread Panu Matilainen
Okay, the headers are otherwise identical so it's the payload that has to differ then, and that payloaddigest changing throws everything else off too. And indeed, extracting the rpm2cpio output shows some differences (from `diff -u -a` output), eg: ```

Re: [Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)

2024-01-25 Thread Panu Matilainen
The above *almost* works. It's just that the ld.so.conf from Fedora causes an "ldconfig: need absolute file name for configuration file when using -r" error from ldconfig. Had me scratching hair for a bit because I thought it ws complaining about the path I was passing in -f which *was*

Re: [Rpm-maint] [rpm-software-management/rpm] Testsuite failure with rpm 4.18.2 (Issue #2874)

2024-01-25 Thread Panu Matilainen
4.18.2 would be missing at least this: 7ec148c1d61e0b526ae5c917f0ddc2b4a3222146 which could affect it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1909841982 You are receiving this because you are subscribed to

Re: [Rpm-maint] [rpm-software-management/rpm] Testsuite failure with rpm 4.18.2 (Issue #2874)

2024-01-25 Thread Panu Matilainen
I remember a case or two where the checksums mismatch due to different libmagic versions producing different strings. I also remember tweaking the test to avoid relying on libmagic stuff there, but don't remember when exactly. But yes, it's fragile. Very. -- Reply to this email directly or

Re: [Rpm-maint] [rpm-software-management/rpm] Testsuite failure with rpm 4.18.2 (Issue #2874)

2024-01-25 Thread Panu Matilainen
If guessing and trying fails, 'runroot rpm -qp --xml /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm' is your friend, one can then diff the output of that between working and non-working files. We should probably dump that output anyway to make it more debuggable. -- Reply to this email directly

Re: [Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)

2024-01-25 Thread Panu Matilainen
Yes, a clean way to discover the system library paths searched by the dynamic loader would go a long way. Hmm. I guess this is kinda doable by running `ldconfig -r ` followed by `ldconfig -r -p` from which you can pull the directories (so effectively the path) or the files themselves. Just do

Re: [Rpm-maint] [rpm-software-management/rpm] Split Perl dependency generators into a separate repo (Issue #2873)

2024-01-24 Thread Panu Matilainen
FWIW, I think we should follow the [Python lead](https://github.com/rpm-software-management/python-rpm-packaging) and call it perl-rpm-packaging to allow for all sorts of helper material to live there and not just macros/scripts and the like. A bit of consistency is a nice bonus. -- Reply to

Re: [Rpm-maint] [rpm-software-management/rpm] add build directory auto path to %autosetup step (PR #2859)

2024-01-24 Thread Panu Matilainen
@pmatilai commented on this pull request. > @@ -78,16 +84,81 @@ static char *doUncompress(const char *fn) return cmd; } +/** + * Detect if an archive has a single top level entry, and it's a directory. + * + * @param path path of the archive + * @return 1 if archive as only a

Re: [Rpm-maint] [rpm-software-management/rpm] Check date/time for consistently using unsigned ints (#1228)

2024-01-24 Thread Panu Matilainen
Static checking in RHEL discovered exactly one place where we still had time_t conversion to signed integers: getBuildTime(). Fixed that in https://github.com/rpm-software-management/rpm/commit/97aa64d8281974fb369c66d5aef8650515b89c52, I think we can consider this done now. -- Reply to this

Re: [Rpm-maint] [rpm-software-management/rpm] Check date/time for consistently using unsigned ints (#1228)

2024-01-24 Thread Panu Matilainen
Closed #1228 as completed via 97aa64d8281974fb369c66d5aef8650515b89c52. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1228#event-11582158266 You are receiving this because you are subscribed to this thread. Message ID:

[Rpm-maint] [rpm-software-management/rpm] Safer handling of internal soname dependencies (Discussion #2872)

2024-01-24 Thread Panu Matilainen
This is one of those topics that gets raised semi-annually at least. To point out a couple, https://bugzilla.redhat.com/show_bug.cgi?id=2259260 and https://bugzilla.redhat.com/show_bug.cgi?id=1464368 and https://github.com/rpm-software-management/rpm/issues/1227 but there are certainly more

Re: [Rpm-maint] [rpm-software-management/rpm] Don't use _nl_msg_cat_cntr if __GLIC__ is not defined (PR #2856)

2024-01-23 Thread Panu Matilainen
Thanks for the patch! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2856#issuecomment-1905777264 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Don't use _nl_msg_cat_cntr if __GLIC__ is not defined (PR #2856)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)

2024-01-23 Thread Panu Matilainen
I'm not actually finished with this, but I do have a local backup anyway, closing is okay. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1905561075 You are receiving this because you are subscribed to this thread.

Re: [Rpm-maint] [rpm-software-management/rpm] Don't use _nl_msg_cat_cntr if __GLIC__ is not defined (PR #2856)

2024-01-23 Thread Panu Matilainen
@pmatilai commented on this pull request. > @@ -532,7 +532,7 @@ static int filerequireTag(Header h, rpmtd td, > headerGetFlags hgflags) /* I18N look aside diversions */ -#if defined(ENABLE_NLS) +#if defined(ENABLE_NLS) && (defined(__GLIBC__) || !defined(__linux__)) AFAICS this isn't

Re: [Rpm-maint] [rpm-software-management/rpm] Pass arg1 to file trigger scripts (PR #2871)

2024-01-23 Thread Panu Matilainen
I'm glad this ended up on your plate, I never found the patience to sort this out :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2871#issuecomment-1905533378 You are receiving this because you are subscribed to this thread.

Re: [Rpm-maint] [rpm-software-management/rpm] Pass arg1 to file trigger scripts (PR #2871)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Add "local_generator" (PR #2734)

2024-01-23 Thread Panu Matilainen
I find `packaged` quite misleading, because the case is to allow for attributes and generators that are local to the *build*. Those attributes *may also* be packaged, but that's not relevant for this feature. I see two separate main cases for this: - build a package with the generator it ships

Re: [Rpm-maint] [rpm-software-management/rpm] 4.19.1: bug in `%___build_pre_env` definition (Issue #2863)

2024-01-22 Thread Panu Matilainen
@pmatilai converted this issue into discussion #2870. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2863#event-11556184345 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Store auxiliary data in rpmdb (#1595)

2024-01-22 Thread Panu Matilainen
@pmatilai converted this issue into discussion #2869. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1595#event-11556131967 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Add macro '%-x**' containing all occurrences of the flag '-x' (PR #2449)

2024-01-22 Thread Panu Matilainen
Actually, there is a kind of a way to access the values from Lua even now. %-f* macro has the last definition of the macro. If you pop (ie undefine) it, you get the one underneath. And with that, you can walk all the values. It wont work on normal macros as "%undefine -f*" is not permitted, but

Re: [Rpm-maint] [rpm-software-management/rpm] Add macro '%-x**' containing all occurrences of the flag '-x' (PR #2449)

2024-01-22 Thread Panu Matilainen
Just realized %{-f} and %{-f*} explictly documented as being the last occurence. So yep, we can't change that. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2449#issuecomment-1903868651 You are receiving this because you are subscribed

Re: [Rpm-maint] [rpm-software-management/rpm] Add macro '%-x**' containing all occurrences of the flag '-x' (PR #2449)

2024-01-22 Thread Panu Matilainen
I know its that way historically, just doubtful of people actually relying on multivalues being handled that way. But then, I wouldn't know. Yet another possibility could be letting macros declare the way they want their arguments, ie "I can handle multiple values, bring em on", just like we

Re: [Rpm-maint] [rpm-software-management/rpm] add build directory auto path to %autosetup step (PR #2859)

2024-01-22 Thread Panu Matilainen
@pmatilai commented on this pull request. > + int r, ret, rootLen; + char *rootName; + + a = archive_read_new(); + archive_read_support_filter_all(a); + archive_read_support_format_all(a); + r = archive_read_open_filename(a, path, 10240); + if (r !=

Re: [Rpm-maint] [rpm-software-management/rpm] add build directory auto path to %autosetup step (PR #2859)

2024-01-22 Thread Panu Matilainen
@pmatilai commented on this pull request. > @@ -78,16 +84,81 @@ static char *doUncompress(const char *fn) return cmd; } +/** + * Detect if an archive has a single top level entry, and it's a directory. + * + * @param path path of the archive + * @return 1 if archive as only a

Re: [Rpm-maint] [rpm-software-management/rpm] add build directory auto path to %autosetup step (PR #2859)

2024-01-22 Thread Panu Matilainen
@pmatilai commented on this pull request. > @@ -78,16 +84,81 @@ static char *doUncompress(const char *fn) return cmd; } +/** + * Detect if an archive has a single top level entry, and it's a directory. + * + * @param path path of the archive + * @return 1 if archive as only a

Re: [Rpm-maint] [rpm-software-management/rpm] Add macro '%-x**' containing all occurrences of the flag '-x' (PR #2449)

2024-01-22 Thread Panu Matilainen
Like I said before, I'm not convinced this is the way we want to represent the multivalue case. Assuming we can technically do this now, is there a reason not to put those values into the normal -x* macro? It seems to me we can't really break any significant existing users as we just haven't

Re: [Rpm-maint] [rpm-software-management/rpm] Check that all OpenPGP signatures are a single signature packet (Issue #2109)

2024-01-22 Thread Panu Matilainen
Closed #2109 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2109#event-11555365840 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Check that all OpenPGP signatures are a single signature packet (Issue #2109)

2024-01-22 Thread Panu Matilainen
What's considered rpm-level C code no longer knows about such packet level details, backends will need to deal with RFC compliancy on their own. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2109#issuecomment-1903798717 You are

Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild double-free (Issue #2826)

2024-01-22 Thread Panu Matilainen
Closed #2826 as completed via #2843. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2826#event-11555214340 You are receiving this because you are subscribed to this thread. Message ID: ___

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-22 Thread Panu Matilainen
> It seems like the commit hash mentioned in the commit message isn't correct > (it's the "Bump CI" commit which doesn't seem to have anything to do with > this). It's actually explained in the message: > rpmugUname() and rpmugGname() are have no users in the current codebase, > so this was

Re: [Rpm-maint] [rpm-software-management/rpm] Document scriptlet arguments (Issue #2867)

2024-01-22 Thread Panu Matilainen
Yep. The gaps in our documentation are so enormous they're difficult to see. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2867#issuecomment-1903746094 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)

2024-01-22 Thread Panu Matilainen
As a closing note, catching up 20 years of documentation neglet doesn't happen in a single PR. I've no illusions about this being complete or error-free, just that it's a basis on which more can be built. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Document "dribbles" in the format reference (Issue #2462)

2024-01-22 Thread Panu Matilainen
Closed #2462 as completed via 1b32d3c87f41a5f821e066e17918adb782068b45. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2462#event-11554951324 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Document trailer invariants (#1481)

2024-01-22 Thread Panu Matilainen
Closed #1481 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1481#event-11554939051 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Document trailer invariants (#1481)

2024-01-22 Thread Panu Matilainen
The region tag and the trailer are now documented in #2861. I'm not going to document common sense like no data can overlap. This is also not a wishlist, refining further limitations belongs to v6. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)

2024-01-22 Thread Panu Matilainen
@pmatilai pushed 6 commits. 2e2fe7350f8e6e2f2693a70225aabb9b46afebf2 Use markdown formatting features for package format, fix links ae0d06db4e7db78c069cfb912bdefc362da025bf Split the lead and header structure to their own documents 4719e49d4e33e9e3bcad0e159ae88cb0b606d83e Fix some

Re: [Rpm-maint] [rpm-software-management/rpm] add build directory auto path to %autosetup step (PR #2859)

2024-01-22 Thread Panu Matilainen
@pmatilai commented on this pull request. > @@ -17,6 +17,7 @@ target_link_libraries(rpmlua PRIVATE LUA::LUA) target_link_libraries(rpmbuild PRIVATE librpmbuild) target_link_libraries(rpmspec PRIVATE librpmbuild) target_link_libraries(rpmdeps PRIVATE librpmbuild)

[Rpm-maint] [rpm-software-management/rpm] Document known package format quirks (Issue #2866)

2024-01-22 Thread Panu Matilainen
Another fine idea by @dralley: in the 25+ years of rpm format, the packages in the wild have any number of various quirks (bugs, design mistakes, forks and whatnot) that rpm and other software may need to deal with. I can recall at least half a dozen off-hand but that info should instead be

Re: [Rpm-maint] [rpm-software-management/rpm] Document "dribbles" in the format reference (Issue #2462)

2024-01-22 Thread Panu Matilainen
The IMA signatures and their journey from there to here are a tragic mess, just opened up a new ticket to remind me: #2865 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2462#issuecomment-1903493987 You are receiving this because you

[Rpm-maint] [rpm-software-management/rpm] Consolidate IMA file signature tags (Issue #2865)

2024-01-22 Thread Panu Matilainen
The IMA file signature tags are a mess: they were originally added to the main header so the tags were defined in the > 5000 range. They were moved to the signature header where they belong in later releases, and new tags in the signature range (256-999) were reserved for the use there. These

Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)

2024-01-22 Thread Panu Matilainen
@pmatilai commented on this pull request. > +## Lead Format + +The Lead is stored as a C structure: + +``` +struct rpmlead { +unsigned char magic[4]; +unsigned char major, minor; +short type; +short archnum; +char name[66]; +short osnum; +short signature_type; +

Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)

2024-01-22 Thread Panu Matilainen
@pmatilai commented on this pull request. > +0048: 00 00 00 00 00 01 00 05 +``` + +Bytes 76-77 ("00 01" above) form an int16 that indicates the OS the +package was built for. In this case, 1 == Linux. The next 2 bytes +(78-79) form an int16 that indicates the signature type.

Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)

2024-01-21 Thread Panu Matilainen
@pmatilai commented on this pull request. > @@ -56,6 +56,8 @@ contains an OpenPGP signature on the header + payload data. > The PGP tag is used for RSA signatures and the GPG tag is used for DSA signatures. +Note: the signature tags overlap with those of the main header. What I mean by

Re: [Rpm-maint] [rpm-software-management/rpm] move custom definition of the %__spec_check_pre from spec file to global macros causes not the same result (Issue #2862)

2024-01-21 Thread Panu Matilainen
@pmatilai converted this issue into discussion #2864. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2862#event-11552920204 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)

2024-01-19 Thread Panu Matilainen
The more I looked at this and the existing docs, the more clear it became that the stuff needs more than a touch-up job to be credible. I ended up rewriting much of bit of it, updating and preserving the v3 docs too for historians and the like: #2861. That was quite the pile to chew out in a

[Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)

2024-01-19 Thread Panu Matilainen
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2861 -- Commit Summary -- * Use markdown formatting features for package format, fix links * Split the lead and header structure to their own documents * Fix some

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add a cmake target for hands-free docs-server (Issue #2854)

2024-01-19 Thread Panu Matilainen
On a related note, it wouldn't hurt to ship the manual in html format in our tarballs. I guess we'd need Mr Jekyll for that too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2854#issuecomment-1900072519 You are receiving this

Re: [Rpm-maint] [rpm-software-management/rpm] Update Docs for "Users and Groups" in the manual (Issue #2857)

2024-01-19 Thread Panu Matilainen
Well, I always intended systemd-sysusers to be the native and default "backend" of this feature because ... it is. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2857#issuecomment-1899950764 You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-19 Thread Panu Matilainen
@pmatilai commented on this pull request. > return 0; } const char * rpmugUname(uid_t uid) { -static uid_t lastUid = (uid_t) -1; -static char * lastUname = NULL; - -if (uid == (uid_t) -1) { - lastUid = (uid_t) -1; Yup, and as an added bonus it now never contains

[Rpm-maint] [rpm-software-management/rpm] RFE: add a cmake target for hands-free docs-server (Issue #2854)

2024-01-18 Thread Panu Matilainen
For someone like me who's utterly unaware of the Ruby ecosystem, setting up the jekyll server for locally testing docs changes is a rather terrifying experience. We should have a cmake target that sets it up and runs it in a hands-free manner. Something along the lines of "make docs-server"

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-17 Thread Panu Matilainen
@pmatilai pushed 1 commit. 58b13066e4b540d6440c41becaf3690663cd46d2 Simplify the cache lookup logic, no functional changes -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843/files/d23eb53abdde25ad2c45d20c32dde255fb36384d..58b13066e4b540d6440c41becaf3690663cd46d2

Re: [Rpm-maint] [rpm-software-management/rpm] CMakeLists.txt: restore readline support as an explicit option (PR #2852)

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

Re: [Rpm-maint] [rpm-software-management/rpm] CMakeLists.txt: restore readline support as an explicit option (PR #2852)

2024-01-17 Thread Panu Matilainen
Ack, one of many many many many tiny things that fell through the cracks, probably a case of "I'll fix this later". Thanks for the patch! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2852#issuecomment-1897951171 You are receiving this

Re: [Rpm-maint] [rpm-software-management/rpm] Fix link, declarative builds instead of autobuild (PR #2853)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Fix link, declarative builds instead of autobuild (PR #2853)

2024-01-17 Thread Panu Matilainen
The feature is no longer "autobuild" so there's nothing to rename. Thanks for the patch! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2853#issuecomment-1897947879 You are receiving this because you are subscribed to this thread.

Re: [Rpm-maint] [rpm-software-management/rpm] Remove cycles from CMake dependency graph (PR #2820)

2024-01-17 Thread Panu Matilainen
Just FWIW, https://gitlab.kitware.com/cmake/cmake/-/issues/22852 describes this very case. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2820#issuecomment-1895869882 You are receiving this because you are subscribed to this thread.

Re: [Rpm-maint] [rpm-software-management/rpm] Remove cycles from CMake dependency graph (PR #2820)

2024-01-17 Thread Panu Matilainen
@pmatilai requested changes on this pull request. I came *this* close to merging, but testing made me remember why it's done the way it is: we want the tarballs always recreated on "dist". With this patch, that no longer happens. Of course loops can't be right either, but I can't apply this

Re: [Rpm-maint] [rpm-software-management/rpm] don't attempt to install html pages if they're not built (PR #2848)

2024-01-17 Thread Panu Matilainen
Oh indeed. I tweaked the commit message to elaborate on when it happens (this only affects building from git without doxygen, release tarballs have the html content prebuilt) and applied manually as commit 6098fe1e9f735ab3a603eb429e01300ae48bf4fe Thanks for the patch! -- Reply to this email

Re: [Rpm-maint] [rpm-software-management/rpm] don't attempt to install html pages if they're not built (PR #2848)

2024-01-17 Thread Panu Matilainen
Closed #2848. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2848#event-11510440839 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list

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

2024-01-17 Thread Panu Matilainen
@pmatilai converted this issue into discussion #2851. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2389#event-11510089819 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Attribute marker in `-V` mode undefined for multi-attribute files (Issue #2846)

2024-01-17 Thread Panu Matilainen
I think it's slighly more subtle: whether a file is a %license or not has little relevance to verify results. However a content mismatch on a %config file is something entirely different (with possible noreplace/missingok modifiers) and yet again quite different for a %ghost which can also have

Re: [Rpm-maint] [rpm-software-management/rpm] 4.19.1: broken `update-pot` target (Issue #2817)

2024-01-17 Thread Panu Matilainen
Closed #2817 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2817#event-11508091602 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] 4.19.1: broken `update-pot` target (Issue #2817)

2024-01-17 Thread Panu Matilainen
> MANY projects have not updated .po files I fail to see any relevance to rpm. In any case, this is supposedly fixed in b4dc72f4b92489f77de9b0ae0bed754875d37ece. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-16 Thread Panu Matilainen
Split to refactor + thread-safe fix, and restored that rpmugFree() on librpm exit that had gone missing at some point. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893715068 You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-16 Thread Panu Matilainen
@pmatilai pushed 3 commits. 4945ad298058fd3c325c6b803ef6c3e2cb2d97aa Remember to free user/group cache on librpm shutdown (again) 8656e2e0327a9af38ef180eb014bac9271b3f8df Centralize user/group lookup caching into a single data structure d23eb53abdde25ad2c45d20c32dde255fb36384d Make

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-16 Thread Panu Matilainen
Oh, except that rpmugGname() and rpmugUname() additionally rely on central storage of the returned values so simple mutex locking doesn't work for those. So those would have to be changed to return malloced data for a simple fix (it wont break any users because there aren't any, at the moment).

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-16 Thread Panu Matilainen
It wouldn't be hard to introduce per-thread locking instead. The bigger deal here is the new central struct that makes it possible to do stuff, perhaps I should actually split that into a separate commit and then consider the thread safety separately. The reason its lumped into one is basically

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-16 Thread Panu Matilainen
Yup, but this patch doesn't change that, the "leak" is already there. This only makes it per-thread. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893568039 You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-16 Thread Panu Matilainen
It does leak, should've mentioned that in the commit message. In the sense that each thread calling it will leave one cache around and reachable. It's far from ideal but it's basically an emergency bandaid. What do you mean about ending itself? -- Reply to this email directly or view it on

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: introduce an rpm-controlled per-build directory to builds (Issue #2078)

2024-01-16 Thread Panu Matilainen
Added buildroot itself to the description, there's no reason whatsoever to scatter the built content around multiple directories if we have that one top-level directory to rule it all. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Strange behavior for multilib (Issue #2837)

2024-01-16 Thread Panu Matilainen
Right, that one. An architecture change is a fairly special operation, I'm not convinced it needs to "just work" with regular update, it just needs to be doable. Eg, using --replacepkgs, which back then it wasn't. Also, an i686 package *can* be considered an update to an i586 package, but a

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: introduce an rpm-controlled per-build directory to builds (Issue #2078)

2024-01-15 Thread Panu Matilainen
> Couldn't we just make `%setup -c` the default behavior and then strip the top > level directory automatically when extracting an archive? This directory needs to be set up regardless of whether a spec uses %setup or not. And, extracting the sources to the topmost directory would defeat some

Re: [Rpm-maint] [rpm-software-management/rpm] Strange behavior for multilib (Issue #2837)

2024-01-15 Thread Panu Matilainen
> What's so special about an identical NEVR? The content may still be > different, we had a couple of bug reports about same NEVR with different > files and rpm not doing the correct thing. Because by the very definition of rpm, release must change any time content changes? That people

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Declarative build system support (#1087)

2024-01-15 Thread Panu Matilainen
Closed #1087 as completed via f02ddfd121d91ea00a534a0e04374c478f56d437. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1087#event-11487059627 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)

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

Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)

2024-01-15 Thread Panu Matilainen
Okay I guess we've had all the feedback we're going to get on this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1891987087 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-15 Thread Panu Matilainen
(commit message tweaked somewhat in the later pushes) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1891985861 You are receiving this because you are subscribed to this thread. Message ID:

[Rpm-maint] [rpm-software-management/rpm] Make user/group lookup caching thread-safe (PR #2843)

2024-01-15 Thread Panu Matilainen
This seems like a huge overkill when in 4.19.1 theres exactly one rpmfiStat() call that unnecessarily invokes an rpmug lookup in a threaded scenario, but then rpmfiStat() and rpmfilesStat() are public APIs that people expect to be safe for use within the originating thread. Collect all the

Re: [Rpm-maint] [rpm-software-management/rpm] Strange behavior for multilib (Issue #2837)

2024-01-14 Thread Panu Matilainen
No colors are involved in this case (no files, but yes rpmteColorDS() is the key to the coloring thing. It's weird alright. I guess I thought thought the patch only affected --replacepkgs behavior when that's what the commit message talks about and that's the testcase that chances as well. But

Re: [Rpm-maint] [rpm-software-management/rpm] check for rpmlib version (Discussion #2841)

2024-01-14 Thread Panu Matilainen
FWIW, this isn't an rpm issue at all. It's like any old feature test, you test for the symbol in cmake, and define something you *can* test with ifdef. There are multiple ways to do that. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Strange behavior for multilib (Issue #2837)

2024-01-12 Thread Panu Matilainen
Bisecting points the regression to commit 21836bc7524f8fc07972e0e56eed1c3b68775368 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-110637 You are receiving this because you are subscribed to this thread. Message

<    6   7   8   9   10   11   12   13   14   15   >