I imagine this would be more ideal as a boolean value.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/commit/09d90d4012f97d287b1c77490f666ce115191f89#r143612130
You are receiving this because you are subscribed to this thread.
Message ID:
__
>Technically it's more efficient because we don't need to brute-force search
Well, for small numbers of items (<100) brute force is generally faster than a
map. Not that it matters - like you say, the real-world difference is
negligible.
--
Reply to this email directly or view it on GitHub:
h
@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
Doesn't seem worth it to me
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2220#issuecomment-2094014697
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-m
I mean, it's not a full implementation because it only handles building,
signing and parsing packages (not rpmdb management or specfile parsing or
anything else), but, it kind of already exists
https://github.com/rpm-rs/rpm
--
Reply to this email directly or view it on GitHub:
https://github.c
I read this issue as being "we should fail, but currently we ignore by default.
Let's fail by default and provide an option to ignore"
Which would be a change to how it currently behaves in addition to adding a new
option (to restore present behavior)
But I might have read that incorrectly
-
@pmatilai As a behavioral change, perhaps this is suitable for RPM v6? (as in
v6 of the tool, not v6 of the format)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1939#issuecomment-2038570348
You are receiving this because you are sub
How about defaulting to Zstd compression as opposed to Gzip?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-9014566
You are receiving this because you are subscribed to this thread.
Message ID:
Crazy idea: perhaps RPM should take into consideration GPU architecture?
Currently the CUDA and ROCm packages tend to be **massive**, and that's partly
because they contain optimized code for nearly a dozen different generations of
GPUs.
```
$ dnf info rocblas rocsparse rocsolver
Last metadata
Ah, you're right that if the builder and rebuilder aren't the same person
(which, really, is the primary use case of reproducible builds) then you won't
be able to reproduce the package.
@DemiMarie suggested a while back that if the non-signature aspects of the
package are reproducible, then yo
>A signed rpm build can never be "reproducible" according to their current
>definition.
Theoretically you could just ensure that the RPM signature uses the same
`SOURCE_DATE_EPOCH` timestamp rather than the current time - it's a bit icky,
but it works.
--
Reply to this email directly or view
>rpmlib() dependencies on v3 compatibility are dropped:
Are these being specifically singled out for deletion, or can we blanket-delete
feature dependencies introduced before 4.6? Because that's a much longer, e.g.
* ExplicitPackageProvides
* FileCaps
* FileDigests
...
--
Reply to this emai
>this cannot be reflected in PAYLOADFORMAT as that would be a gratituous
>compatibility break
Ironically dropping the tag entirely would work fine, because of the backwards
compatibility backflips already in place to deal with v3 packages.
https://github.com/rpm-software-management/rpm/blob/182
@dralley commented on this pull request.
> headerDel(pkg->header, RPMTAG_PAYLOADDIGEST);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGEST, pld);
headerDel(pkg->header, RPMTAG_PAYLOADDIGESTALT);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGESTALT, upld);
pld = _free(pld
Why can't 6 go there?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8530347
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm
Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2861#issuecomment-1905116686
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-
Closed #2835.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835#event-11563746414
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm
@dralley 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.
Oh, and as per
htt
@dralley 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.
The precise meaning
@dralley commented on this pull request.
> +short archnum;
+char name[66];
+short osnum;
+short signature_type;
+char reserved[16];
+};
+```
+
+and is illustrated with one pulled from the rpm-2.1.2-1.i386.rpm
+package:
+
+```
+: ed ab ee db 03 00 00 00
+```
+
+The fir
@dralley 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;
+cha
@dralley 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. Th
@dralley commented on this pull request.
> +
+Field | Value
+|--
+tag | Must equal the Index Entry (ie 62 or 63)
+type| BIN
+offset | Size of the region entries in the Index
+count | 16
+
+The number of entries in the region (aka region index length) can thus be
+calcula
Understood, thanks! Feel free to close this once you're done with it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1901738765
You are receiving this because you are subscribed to this thread.
Message ID:
Technically `totalFileSize <= UINT32_MAX` ought to be OK?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/commit/80a238d01d9587a53983fc090ee5f2827b8725f5#r136850899
You are receiving this because you are subscribed to this thread.
Message ID:
```suggest
# Which rpm format to generate (4 or 6)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/commit/83c87b1c63f6f733971675943a2278549ad07a0a#r136849221
You are receiving this because you are subscribed to this thread.
Message ID:
__
Updated
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1884986428
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-
@dralley pushed 1 commit.
eb08565561b42ded13fea02054312a75553eebae Clean up immutable regions section a
bit
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835/files/9f3185cb7bf13f78ad557116325fe75c452944e6..eb08565561b42ded13fea02054312a75553eebae
You are receiving
> Yup. The dependency is tracking the use of syntax that will create a package
> that won't work quite right with versions of rpm before 3.0.3.
...
>Not a bug. The dependency is written with <= so that the range is closed, as
>>= would make the implicit promise "forever". Meanwhile, since the m
@dralley pushed 3 commits.
f161a47fa0ff1349acfd5fa62a58fc2b88a3650d Update format documentation in the
manual
e452eab72b4df2c9ae8ad8bbcc8a9a2acf1c2b0f Merge header regions document into
format document
9f3185cb7bf13f78ad557116325fe75c452944e6 Clean up immutable regions section a
bit
--
Vie
@dralley commented on this pull request.
> @@ -264,3 +256,101 @@ could start at byte 589, byte that is an improper
> boundary for an INT32.
As a result, 3 null bytes are inserted and the date for the SIZE actually
starts at byte 592: "00 09 9b 31", which is 629553).
+### Immutable header re
@dralley commented on this pull request.
> # Package format
-This document describes the RPM file format version 3.0, which is used
-by RPM versions 2.1 and greater. The format is subject to change, and
-you should not assume that this document is kept up to date with the
-latest RPM code.
@dralley pushed 1 commit.
cbebd9eccf2d57132c676a5b14996e8616e4d42b Clean up immutable regions section a
bit
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835/files/64b4c81b4ae9d1599084676d1a8f999bfc11abfc..cbebd9eccf2d57132c676a5b14996e8616e4d42b
You are receiving
@dralley pushed 3 commits.
1ece805fc54d31715afdc56c7dbb0d35a82863bd Update format documentation in the
manual
73403c2ad734c2b816c0f881ac2e822b13bbf7ab Merge header regions document into
format document
64b4c81b4ae9d1599084676d1a8f999bfc11abfc Clean up immutable regions section a
bit
--
Vie
@dralley commented on this pull request.
> # Package format
-This document describes the RPM file format version 3.0, which is used
-by RPM versions 2.1 and greater. The format is subject to change, and
-you should not assume that this document is kept up to date with the
-latest RPM code.
How would that work exactly? Add a `%doc(README)` to replace `%readme`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8067851
You are receiving this because you are subscribed to this thread.
Message ID:
@dralley commented on this pull request.
> @@ -229,7 +216,7 @@ In our example there would be 32 such 16-byte index
> entries, followed
by the data section:
```
-0210: 72 70 6d 00 32 2e 31 2e 32 00 31 00 52 65 64 20rpm.2.1.2.1.Red
+0210: 72 70 6d 00 32 2e 31 2e 32 00 31 00 52 65
@dralley pushed 1 commit.
c579fbf1a914f96fa14465acec97390197740f54 Update format documentation in the
manual
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835/files/dbd7eb8f93c9804ff37ae22ef8d01f507b384318..c579fbf1a914f96fa14465acec97390197740f54
You are receiving
@dralley pushed 1 commit.
dbd7eb8f93c9804ff37ae22ef8d01f507b384318 Update format documentation in the
manual
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835/files/f44637672c6096f2dac5e5b87291b9fbb06da6f7..dbd7eb8f93c9804ff37ae22ef8d01f507b384318
You are receiving
@dralley pushed 1 commit.
f44637672c6096f2dac5e5b87291b9fbb06da6f7 Update format documentation in the
manual
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835/files/b891bfcbacb824507cd3527cfa5951c24be55bd4..f44637672c6096f2dac5e5b87291b9fbb06da6f7
You are receiving
@dralley commented on this pull request.
>
```
0008: 00 01 72 70 6d 2d 32 2e..rpm-2.
```
-The next two bytes (8-9) form an int16 that indicates the architecture
-the package was built for. While this is used by file(1), the true
-architecture is stored as a string in the Header.
@dralley pushed 1 commit.
b891bfcbacb824507cd3527cfa5951c24be55bd4 Update format documentation in the
manual
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835/files/a561596b015506565c2370559586156b5db0293b..b891bfcbacb824507cd3527cfa5951c24be55bd4
You are receiving
@dralley commented on this pull request.
> +
+The Signature can contain multiple different types of signatures, stored under
+unique tags (just like the Header). Details about these tags and the
information
+they store can be found [here](signatures_digests.md).
+
+RPM v4 packages are expected
@dralley pushed 1 commit.
6ede171288e5bb6e565818e988cfa4bf69962367 Update format documentation in the
manual
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835/files/5bfcfa058cdd7c6a93c2d96e02dea9fc044b5476..6ede171288e5bb6e565818e988cfa4bf69962367
You are receiving
@dralley commented on this pull request.
>
## Signature
-A 3.0 format signature (denoted by signature type 5 in the Lead), uses
-the same structure as the Header. For historical reasons, this
-structure is called a "header structure", which can be confusing since
-it is used for both the H
@dralley commented on this pull request.
>
```
: ed ab ee db 03 00 00 00
```
-The first 4 bytes (0-3) are "magic" used to uniquely identify an RPM
-package. It is used by RPM and file(1). The next two bytes (4, 5)
-are int8 quantities denoting the "major" and "minor" RPM file fo
@dralley commented on this pull request.
> @@ -23,17 +23,20 @@ package file is divided in 4 logical sections:
. Payload -- compressed archive of the file(s) in the package (aka "payload")
```
-All 2 and 4 byte "integer" quantities (int16 and int32) are stored in
-network byte order. When
Make it (mostly) up to date with RPMv4 standards.
Also fix some broken links, and mark old signature tags as deprecated.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2835
-- Commit Summary --
* Update format documentation
Unrelated, but this line found in the scriptlet documentation seems rather out
of date :)
> The %pre script executes just before the package is to be installed. It is
> the rare package that requires anything to be done prior to installation;
> none of the 350 packages that comprise Red Hat Li
I expect it means %pre and %post, which admittedly break the pattern followed
by the other scriptlet types.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2834
You are receiving this because you are subscribed to this thread.
Message
%config(missingok) is documented, however, %missingok is not. Presumably there
is a lot of overlap, but it is unclear if there are any distinctions in when
and how they should be used.
vattrtest.spec only tests %missingok, can I presume that they are equivalent in
function?
--
Reply to this
The manual doesn't include any details about %caps, the only mention is in the
changelog, a couple of command line flags, and specfiles used for testing
purposes.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2832
You are receiving t
`%readme` is documented as being obsolete, perhaps it should be removed with a
shim that behaves as though it was marked as `%doc` instead, with a warning
message to change it?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#
>group tag made optional
Come to think of it, is this considered legacy nowadays? IIRC the Fedora
packaging guidelines and other distros recommend against it, I believe comps
kind of replaced it?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/
>From a discussion with @Conan-Kudo
> (me) what is the intended purpose behind RPM automatically adding a
> config($pkgname) dependency to both the provides and requires dependency
> lists of a package with a %config declared in the specfile? why self-require
> like that?
> (neal) My understa
> rpmlib() dependencies are reset (ideally they'd be replaced by a better
> mechanism but that's probably out of scope)
Unrelated (or maybe related) question - why are rpmlib dependencies set with
less-than or equal-to the version in which the feature was added? Is trying to
express that "if t
How one would compress the header section without altering some aspect of the
format significantly (in a way that would not be trivial to backport)?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2220#issuecomment-1841634630
You are re
I wouldn't say SHA2-256 is falling out of fashion, most crypto-people seem to
think there's not much risk of it being broken any time soon. But a bit of
future proofing wouldn't hurt.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussio
@dralley pushed 1 commit.
2d69151aa250d1dde056ed009c0fa644685da01c Remove lead checks other than the
"magic number" check
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2736/files/01ae94b0b1cfa60bbd98d050b40aef36701f7190..2d69151aa250d1dde056ed009c0fa644685da01c
You
Remove checks on the lead's "signature type" and "rpm
package format version" fields.
closes #2423
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2736
-- Commit Summary --
* Remove lead checks other than the "magic number
Relevant https://github.com/rpm-software-management/rpm/issues/2462
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-7149254
You are receiving this because you are subscribed to this thread.
Message ID:
_
>(I don't know anybody using them so dunno)
@Conan-Kudo I believe you may have mentioned in the past that the MD5 headers
(pkgid) are used in some build systems?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2633#issuecomment-1703679
I still haven't been able to track down a cause for ^, do you happen to
remember anything?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1570#issuecomment-1696001800
You are receiving this because you are subscribed to this thread.
M
>MD5 and SHA1 dropped everywhere
What about the flags `--hdrid` and `--pkgid`?
https://github.com/rpm-software-management/rpm/blob/21457de886faf2415500a8bb7cc6c816d72939ef/docs/man/rpm.8.md?plain=1#L657
and
](https://github.com/rpm-software-management/rpm/blob/21457de886faf2415500a8bb7cc6c816d7
How would that make using the parallel arrays easier?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6711380
You are receiving this because you are subscribed to this thread.
Message ID:
___
re: "crypto modernization", maybe look at supporting SHA-3 checksums?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6675616
You are receiving this because you are subscribed to this thread.
Message ID:
__
Yes, `BUILDTIME` at the very least is
[complicated](https://github.com/rpm-software-management/rpm/issues/2527). I'm
not sure what infrastructure might rely on `BUILDHOST` being present, though.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rp
As far as BUILDHOST goes, rather than using a default value, it would be better
to just disinclude the tag IMO.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2603#issuecomment-1667144083
You are receiving this because you are subscrib
You can use Fedora as a base image with Github Actions too - of course the VM
will still be Ubuntu, but all of the commands can run inside of a container
image of your choosing.
https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container#defining-the-container-image
--
Reply to t
@Conan-Kudo Is this making any sense?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6167128
You are receiving this because you are subscribed to this thread.
Message ID:
___
>but we of course still store the file mtime in the header.
Right, I understand, no disagreement there. If you need a fully reproducible
package, you need to set source-date-epoch.
But if you don't need or even want a fully reproducible package (but you still
want the payload to be reproducibl
Sorry if so, I don't recall seeing a response on that specific topic.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2531#issuecomment-1576769144
You are receiving this because you are subscribed to this thread.
Message ID: _
Sorry for the miscommunication. The question I had started out with was
>but the point of source_date_epoch is to make packages reproducable right? If
>you allow the buildtime to be different, then the package is no longer
>reproducable, and there's no reason to use source_date_epoch
You poi
@dralley commented on this pull request.
> @@ -104,7 +104,7 @@ static rpmRC markReplacedFiles(const rpmpsm psm)
if (!headerGet(h, RPMTAG_FILESTATES, &secStates, HEADERGET_MINMEM))
continue;
-
+
Ignore the editor autoformat noise.
--
Reply to this email directly or
Presumably this code is with regards to the installed size, not the size
including CPIO headers.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2531
-- Commit Summary --
* Fix an instance that used archivesize where it oug
As per discussion with @Conan-Kudo, the `use_source_date_epoch_as_buildtime`
option can be deprecated if the new payload format no longer includes file
mtimes, as the option only exists for payload reproducibility. If the payload
is reproducible with or without SOURCE_DATE_EPOCH (because the mt
When I think expectation I kind of mean "such that it will fail if not
present", but luckily it looks like that is not the case.
```
[dalley@thinkpad rpm-rs]$ rpm -qpi target/test.rpm
warning: target/test.rpm: Header V4 RSA/SHA256 Signature, key ID 5ab27f39: NOKEY
Name: test
Epoch :
>Other examples of such tags include RPMTAG_BUILDHOST, RPMTAG_SOURCERPM and
>RPMTAG_RPMVERSION, just to name a few.
When you say expected, do you know specific examples for these?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2527#is
`RPMTAG_BUILDTIME` is considered by all documentation I've seen so far to be an
optional, informational tag as opposed to a mandatory one. However, `rpm
--rebuilddb` will encounter issues if an RPM missing the buildtime tag is
installed.
A "sanity check" is done on all installed packages [ensu
>RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH is a different kind
>of mess, needs to be sorted out nevertheless (make RPMTAG_FILESIGNATURES just
>an alias for RPMSIGTAG_FILESIGNATURES or something)
I noticed that (some?) Fedora 37 packages seem to have RPMTAG_FILESIGNATURES in
the
How about no longer setting `RPMTAG_GROUP` to `Unspecified` automatically?
Just exclude the tag.
https://github.com/rpm-software-management/rpm/blob/93ee7d9c6164467608094a7e0652a0e3d84a6715/build/parsePreamble.c#L1239
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm
Thanks. What is the expected use case of providing the uncompressed archive
size? Repository metadata exposes it, but frankly I don't understand why, it
doesn't seem like particularly useful information.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-man
Should this be looking at `RPMTAG_LONGSIZE` instead?
https://github.com/rpm-software-management/rpm/blob/13e89c6ae5ff9cb20b0721e80732e7cde55da96c/lib/psm.c#L666
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2498#issuecomment-153007441
Ok: *elsewhere* the documentation claims those tags are the uncompressed sizes
>RPMTAG_LONGARCHIVESIZE - uncompressed payload size
https://github.com/rpm-software-management/rpm/blob/c21885e6b0e3045dc165d4d7be1911987a9cec9b/docs/manual/large_files.md#64-bit-tags
So maybe it's just the documentat
It looks probable that nothing has written a "correct" `RPMTAG_ARCHIVESIZE` tag
since 2007. Given that nobody noticed, is there any reason to keep this stuff
in rpm v6?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2498#issuecomment
I'm not sure if this issue I've just filed calls into question the value of a
couple of other tags?
https://github.com/rpm-software-management/rpm/issues/2498
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment
The signature tags "payloadsize" and "longarchivesize" that both claim to be
uncompressed payload sizes in the comments alongside. Then we have the main
header tags "archivesize" and "longarchivesize" which the documentation
describes as being compressed payload sizes.
```
RPMSIGTAG_PAYLOA
So, not really a question about packages themselves -
[`parseEVR()`](https://github.com/rpm-software-management/rpm/blob/4afe2d14d33db82ccb41c0a8d5eb1a4db90762fc/rpmio/rpmver.c#L24-L57)
is extremely lax on doing any kind of validation. For example all of these
are parsed without complaint
* `:
Closed #2486 as not planned.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2486#event-9024780445
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Ok.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2486#issuecomment-1511389601
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-ma
Sure, but in that case it should not look for PAYLOADDIGESTALT at all.
Otherwise you'd just be comparing it against a value that it will not match
most of the time.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2486#issuecomment-151
@DemiMarie @pmatilai
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2486#issuecomment-1510417707
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint m
To reproduce:
specfile
```
Name: rpm-test
Version:0
License:LGPL
Release:0
Summary:""
#BuildRequires:
%description
%build
cat > hello-world.sh <
ba21f4cb197179798065399a1551af2727e41efe56daed73ce869549b1280dd0
8
5a
There are two components to this
1) `rpm -v --checksig` (also without -v) seems to exclude any digests which
fail to verify so long as an equivalent one does verify. This seems to apply
even when using `--define "_pkgverify_level all"`.
2) `rpm` appears to fail to verify PAYLOADDIGESTALT in si
@dralley commented on this pull request.
> @@ -466,6 +483,13 @@ int rpmvsVerify(struct rpmvs_s *sis, int type,
int strength = (sinfo->type | sinfo->strength);
int required = 0;
+ /* Ignore failure if an alternative exists and verifies ok */
+ if (sinfo->rc == RPMRC_
What's the background on the issue you are referring to here?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5616514
You are receiving this because you are subscribed to this thread.
Message ID:
__
> except for the rpm magic, the lead will be zeros only
I'm curious if we want to apply this even to the "major" file format version
number in the lead? Of all the fields, that one seems like it could eventually
have some potential use.
--
Reply to this email directly or view it on GitHub:
> (*) Header tag data entries must be sorted.
I'm unclear on what this means, do you mean
1) We cannot require tags to be sorted at parse time for compatibility reasons,
or
2) There are certain tags which must be in certain positions in a sort-order
violating way?
--
Reply to this email dir
`RPMTAG_CHANGELOG` doesn't seem to be used anywhere anymore, presumably
replaced by the combo (`RPMTAG_CHANGELOGNAME`, `RPMTAG_CHANGELOGTIME`,
`RPMTAG_CHANGELOGTEXT`)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2327#issuecomment-1
Well, I did include "deprecated". I think that still applies?
IMO if a tag is "stupid and pointless" and doesn't need to be written then it
is effectively deprecated and should be documented as such, yes?. My main
point is to just have it documented somewhere.
There's also a bunch of tags whi
1 - 100 of 134 matches
Mail list logo
