This is basically three different but related parts:
- the db indexes themselves
- the --hdrid and --pkgid query flags
- RPMTAG_PKGID and RPMTAG_HDRID tag aliases
Then there's also RPMTAG_SOURCEPKGID that's still md5 but that is a separate
topic and needs a separate ticket too.
--
Reply to this
RPMTAG_SOURCEPKGID is simply the header+payload MD5 digest of the source rpm.
We wont be calculating MD5 for V6 packages so this has got to change somehow.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3329
You are receiving this beca
1. What ever politic choice and speach has been done (for good reason, for
sure), do you have an intention to document the API ? (i know it is something
boring to do, but it is so helpfull for users)
2. And / Or take some 5 minutes of your time to provide some help about how to
use it when user
@pmatilai because of poor documentation. Please share to make things alive and
lovely the constructive way.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-10756237
You are receiving this because you are subs
please help
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3322#discussioncomment-10756259
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint ma
Thanks for taking the fix. 🙏
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3324#issuecomment-2373286103
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-ma
To summarize from bugzilla:
The actual issue here is not really a gdb regression, it's the fact that >= 15
creates a gdb_index with a version of 9 which is something dwz doesn't handle.
So AIUI this only happens if dwz is enabled. The corresponding upstream dwz bug
is here:
https://sourceware.
I don't think I've ever come across a .cxx/.hxx extension in any project that
I've looked at, but that is a totally fair point.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373486296
You are receiving this because
Um, the whole unix-like world is using ELF, and yes including shared objects.
But I just realized, there's a gotcha here: elfutils, which the script relies
on, is a Linux-only project by their own declaration:
https://sourceware.org/elfutils/ says it quite explicitly.
So disabling the script as
So, thanks for the patch :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3324#issuecomment-2373255338
You are receiving this because you are subscribed to this thread.
Message ID: ___
R
Merged #3324 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3324#event-14393942950
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
Yup, this is why there is a loop. Otherwise we'd encounter dangling symlinks
that won't get deleted.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3311#issuecomment-2373422407
You are receiving this because you are subscribed to this th
**Describe the bug**
I'm not able to redirect LUA scriptlet stdout/stderr to a FD using
`rpmtsSetScriptFd()` API call.
**To Reproduce**
Have something like this in the spec file:
```
%pre -p
print("pre scriptlet successfully done")
```
**Expected behavior**
The message being printed to the give
I'm not a fan of `.cc`/`.hh` simply because it looks like it's associated with
the traditional UNIX C compiler binary `cc`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373660009
You are receiving this because you
Oh, I've just realized that the `xx` is actually the slanted `++` :smile: I see
what they did there.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373661495
You are receiving this because you are subscribed to this
> I'm not a fan of `.cc`/`.hh` simply because it looks like it's associated
> with the traditional UNIX C compiler binary `cc`.
Oh, yup. It's also just two characters and somehow that feels wrong. Like, how
many file extensions are there with only two characters...
> And case sensitive extensio
Also note that C++ modules will use `.ixx`, and if we ever get around to using
them for an RPM C++ API interface (in some indeterminate time in the future),
it would be nice if everything lined up for it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-mana
@ffesti pushed 1 commit.
a06349ba66cb3fe8ee156029829959d1b7f82a7d Split PGP fingerprints into groups of
4 characters
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3321/files/a927b9d12e218b77133418ee32d886588eaf9b64..a06349ba66cb3fe8ee156029829959d1b7f82a7d
You are r
I wonder what's the deal with upper verses lower case hex strings. I split the
fingerprints into groups of four and in lowercase this looks very wrong to me
for some reason. Any opinions on that topic? Looks like RPM has always used
lowercase in one continuous string.
--
Reply to this email di
CMake itself uses it, and when I first learned C++, I used it for my stuff too.
😅
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373607449
You are receiving this because you are subscribed to this thread.
Message I
You can also use `.c++`/`.h++` if you're feeling bold... 😛
All the valid extension types are listed [on the Wikipedia page for the
language](https://en.wikipedia.org/wiki/C%2B%2B).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#
I'm also more accustomed to seeing `.cpp/.hpp` but Neal's point about the
`CXXFLAGS` is valid. Also, it seems like `.cxx/.hxx` is ever so slightly more
common (historically) on UNIX whereas `.cpp/.hpp` on Windows (based on a quick
search on the interwebz). I also kinda like the more minimalistic
@ffesti pushed 4 commits.
6aea28756d11044c69f55ea1c8ba8405195c8ecf Add rpmPubkeyMainKey and
rpmPubkeyFingerprint
d8689a699b58eb380641c582759c924a4f02a877 Add rpmKeyringVerifySig2 that return
the matching key
3a19e3737b7c8f2bd9156453c4cefe0eaf4f5293 Add Key Fingerprints to rpmsinfoMsg()
a927b9
> cxx/hxx has the significant benefit that it's the only version with some
> actual, concrete rationale to back it
Once you put it down this way... it'd seem foolish to do anything else really.
So .cxx and .hxx it is. Thanks for the input!
Note that .hxx for *C++ only* headers - so at this point
Ack, it seems like sticking to `.h` for pure C headers and `.hpp` for C++
(later) makes the most sense, and is most consistent.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373745410
You are receiving this because
> > cxx/hxx has the significant benefit that it's the only version with some
> > actual, concrete rationale to back it
>
> Once you put it down this way... it'd seem foolish to do anything else
> really. So `.cxx` and `.hxx` it is. Thanks for the input! Note that .hxx for
> _C++ only_ headers -
Oh geez, okay whatever, strike that as a reason. 😵
Still, I stand by my original rationale for cxx/hxx.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373713438
You are receiving this because you are subscribed to t
Yup, cxx/hxx has the significant benefit that it's the only version with some
actual, concrete rationale to back it :laughing:
I was a little surprised to see the core guidelines recommending .cpp and .h.
.cpp is common enough not to raise eyebrows, but .h? Why on earth would one NOT
want to d
> We have a specific reason to not mix the headers: we don't want to make our
> C++ API public anytime soon. Having C++ in separate headers also helps
> editors do syntax highlighting and the like.
Indeed, if it quacks, it's a duck. No point in pretending otherwise :smile:
--
Reply to this em
@ffesti pushed 6 commits.
a9202d26b33e7c40bab0c467969fdb74a6029178 Use long PGP Key IDs for all outputs
c48d695487fe93cb6d441f51b573d934d61bf527 Use long PGP Key Ids in our test cases
12cbbcc23a71168af83c8c9f80f6b984847a130b Add rpmPubkeyMainKey and
rpmPubkeyFingerprint
cc6bd70a7cef0caad8ecc08
@ffesti commented on this pull request.
> free(pgpsubkeys);
}
*count = pgpsubkeysCount;
return subkeys;
}
+
+int rpmPubkeyFingerprint(rpmPubkey key, uint8_t **fp, size_t *fplen)
+{
+if (key == NULL)
+ return -1;
+key = key->mainkey;
+pthread_rwlock_rdl
@ffesti commented on this pull request.
> @@ -319,10 +319,16 @@ rpmRC rpmKeyringVerifySig(rpmKeyring keyring,
> pgpDigParams sig, DIGEST_CTX ctx)
rpmlog(rc ? RPMLOG_ERR : RPMLOG_WARNING, "%s\n", lints);
free(lints);
}
-}
-
-if (keyring)
+ if (keyptr
> Also note that C++ modules will use .ixx
Where is that stated? Based on quick googling around, .ixx seems to be a Visual
Studio specific extension. Both gcc and clang have/accept their own litanies
(.cppm, .ccm, .cxxm, .c++m and whatnot) :zany_face:
--
Reply to this email directly or view i
> Why on earth would one NOT want to differentiate from plain C headers?
Isn't that to have a single header file for both C and C++ usage, assuming that
you'd wrap the C++ only bits with `__cplusplus`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-managem
It's somewhat rare these days to have mixed C/C++ headers in a single project,
so I can see why they say that. That doesn't mean I agree with it. 😃
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373725339
You are re
As for sharing the same header - yes you can certainly do that. AFAIK neither C
or C++ compilers are actually in the slightest interested about the extension,
that's all just convention. I would instinctively pick .h for plain C.
We have a specific reason to not mix the headers: we don't want to
Added an AC to the description - lets try to get that habbit rolling too
:smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3316#issuecomment-2373770888
You are receiving this because you are subscribed to this thread.
Message ID
37 matches
Mail list logo
