Re: [Rpm-maint] [rpm-software-management/rpm] Drop architecture from %builddir path (PR #3069)

@pmatilai pushed 1 commit. 658bc4f097fd0dd050e10b3ee31a31d25fa35be1 Drop architecture from %builddir path -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3069/files/60ca0113b7a935f3e670e390b4720def7fbadd62..658bc4f097fd0dd050e10b3ee31a31d25fa35be1 You are receiving

Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

Makes sense, thanks for the clarification. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9270632 You are receiving this because you are subscribed to this thread. Message ID:

Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

The compressed and uncompressed digests are *alternatives*, both cannot be valid at the same time. Rpm calculates both but uses the one that matches (if any). This is to allow freely changing between uncompressed and compressed format of the same content, which "obviously" must be a legit case.

[Rpm-maint] [rpm-software-management/rpm] Drop architecture from %builddir path (PR #3069)

This causes more issues than it solves, at least presently. For one, when BuildArch is used it typically causes the path to disagree with the actual arch (eg on noarch packages). Which looks weird and causes yet other issues in turn. The other issue, raised by Neal Gompa, is that it can cause

Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

One other thing I noticed is that the rpm header carries the digest of the compressed payload in addition to the uncompressed payload digest. Verification of the compressed payload alongside `BTRFS_IOC_ENCODED_WRITE` is relatively straightforward, but verifying the uncompressed payload would

Re: [Rpm-maint] [rpm-software-management/rpm] Code cleanups in tests/rpmpgppubkeyfingerprint.c (PR #3068)

> I took the liberty to make this whole source look better. Better is subjective. The indentation was mostly following rpm coding style, now it's not. See Coding style / Indentation in CONTRIBUTING.md. Never, ever make formatting changes at the same time as other changes, and in particular,

Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

If what you mean is that the payload shouldn't be used before it's been checked against a digest in the cryptographically verified header, then yes. The question is what quantifies as "used". The payload data needs to go somewhere while we're calculating the digest, in which case we could

Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

Do you plan on doing streaming cryptographic verification? See . -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)

I hacked together a proof of concept implementation which uses `BTRFS_IOC_ENCODED_WRITE` to write a zstd-compressed cpio payload directly to disk as-is, from a carefully aligned rpm. Compressed extents are then reflinked to the installation path. presentation:

Re: [Rpm-maint] [rpm-software-management/rpm] Code cleanups in tests/rpmpgppubkeyfingerprint.c (PR #3068)

@ffesti I took the liberty to make this whole source look better. Please let me know if you want me to make changes in incremental commits. This is a small test file which is essentially testing a dummy function, so I made all changes in one commit. -- Reply to this email directly or view it

Re: [Rpm-maint] [rpm-software-management/rpm] Fix file handle leaks (PR #3068)

@sshedi pushed 1 commit. ffc49917d14bde347d2281e0784547cffda7f199 rpmpgppubkeyfingerprint.c: code cleanups -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3068/files/4befafdf0bd6c625d7817c8a020dde4affa71d90..ffc49917d14bde347d2281e0784547cffda7f199 You are receiving

Re: [Rpm-maint] [rpm-software-management/rpm] Fix file handle leaks (PR #3068)

@ffesti commented on this pull request. > return 1; } if (!fpr || strcmp(got, fpr) != 0) { fprintf(stderr, "%s:\n got '%s'\nexpected '%s'\n", filename, got, fpr ? fpr : ""); free(got); + fclose(f); This should probably also free(fp);

Re: [Rpm-maint] [rpm-software-management/rpm] Fix file handle leaks (PR #3068)

@ffesti commented on this pull request. > return 1; } // We expect success now. char *got = rpmhex(fp, fplen); if (! got) { fprintf(stderr, "%s: rpmhex failed\n", filename); + fclose(f); This should probably also free(fp); -- Reply to this email

[Rpm-maint] [rpm-software-management/rpm] Fix file handle leaks (PR #3068)

You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3068 -- Commit Summary -- * Fix file handle leaks -- File Changes -- M tests/rpmpgppubkeyfingerprint.c (9) -- Patch Links --

Re: [Rpm-maint] [rpm-software-management/rpm] Add error messages for url helper calls (PR #3041)

Hmm, and of course we have entirely different way of reporting the error on install, eg: > [root@localhost _build]# ./tools/rpm --define "_urlhelper /bad" -U --nodeps > --root /srv/test >

[Rpm-maint] [rpm-software-management/rpm] Fix header source/patch names disagreeing with src.rpm contents (PR #3067)

If sources or patches in the spec are defined via a macro that does not yet exist, itll still work for building if the macro has been defined by that time as theres another round of expansion there. But this can leave the source/patch names inserted to the header disagreeing with what actually

Re: [Rpm-maint] [rpm-software-management/rpm] how should a test on given argument --noclean (Discussion #3065)

You can't. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3065#discussioncomment-9261221 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Convert macro table to STL containers + native strings (PR #3062)

The final commit turns the macro entry stack into an STL container too, making the macro entries themselves freestanding and since all this is now standard library stuff we don't need to manually clean up and deallocate etc. -- Reply to this email directly or view it on GitHub:

[Rpm-maint] [rpm-software-management/rpm] Convert a bunch of librpm stuff to native C++ allocation (and containers) (PR #3066)

Nothing hugely interesting in here, see commit 0d1071b99ada2df920ba657d9e015e0c2259d4b6 for rationale. There are bits and pieces to finish in librpmio side still but moving on to librpm as some of this stuff is linked, eg string pool cannot use C++ containers before rpmds is updated to clean

Re: [Rpm-maint] [rpm-software-management/rpm] Convert macro table to STL containers + native strings (PR #3062)

@pmatilai pushed 3 commits. 9c28251cdb3664839a5a03b6f6b15f096653483b Add copy control and in particular, destructor to the macro context 3ff1f78c49d63d75b30cc46607edfb148cb5e948 Convert macro table to STL containers + native strings a06877ec1ed1fd5ac8cbaae8100288a2b220fd5c Untangle the