Yes, it's because the engine pushes the macro with each option but only pops it
once.
I guess we could modify freeArgs that it pops until the level is clear, or we
could change setupArgs so that it pushes just once.
But see also https://github.com/rpm-software-management/rpm/pull/2449 that asks
We define two new test macros RPMOUTPUT_SEQUOIA and RPMOUTPUT_LEGACY to make it
easier to write parser dependent test output in the test cases.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3055
-- Commit Summary --
*
Yes, I agree. On the plus side, I don't think the "legacy" parser needs
anything else, so no more of those pull requests...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3051#issuecomment-2069420196
You are receiving this because you
This type is needed to verify the primary binding signature embedded in subkey
binding signatures.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3051
-- Commit Summary --
* Add the Primary Binding pgp signature type
--
AFAICT the code in question was never released, so there's nothing to fix on
your side. (I already fixed it in the "legacy" parser repo)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2063893785
You are receiving this
Not exactly. It is because you removed all the non-digest code from
digest_openssl.c.
(Florian updated the signature verification code to no longer use deprecated
functions, that's why he had to bump the required version.)
--
Reply to this email directly or view it on GitHub:
And also delete the no longer needed include statements.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3045
-- Commit Summary --
* Relax openssl version requirement
-- File Changes --
M rpmio/CMakeLists.txt (2)
I think you broke DSA signatures: it calls `EVP_PKEY_verify` with `padded_sig`
which is constructed from just `sig->r`. But `constructDSASignature` (called
at the beginning) takes `sig->r` and `sig->s` and creates a DSA_SIG from it.
I'm pretty sure PKEY_verify to be passed something DER
Ok, done.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3034#issuecomment-2056819462
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
@mlschroe pushed 1 commit.
2e3cf5f4629a6f3372451dabe35b58fdf69692bd Add testcases for Ed25519 and NIST
P-256
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3034/files/a7a9a1df6f972282d472bf58ea0d89895f0a30a6..2e3cf5f4629a6f3372451dabe35b58fdf69692bd
You are
I can add both an ed25519 and an nist p-256 key test.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3034#issuecomment-2056750547
You are receiving this because you are subscribed to this thread.
Message ID:
Maybe we should put all unknown algorithms into the DSA slots. I think the
distinction was just done so that very old rpm versions didn't trip when they
saw a non-rsa signature. Another reason could have been to allow both signing
with the old RSA/MD5 (for compat reasons) and the new DSA/SHA1
See also 23770e1a4f28c56a31fe600cae332c77333b60b6
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3034#issuecomment-2051692148
You are receiving this because you are subscribed to this thread.
Message ID:
Key import and verification already works, its just that rpm does not know
where to put the signature.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3034
-- Commit Summary --
* Allow signing with ECDSA keys
-- File
This breaks the build if IMA support is not configured and there is no imaevm.h
header file. You need to put a
`#ifdef WITH_IMAEVM` around the `#include "rpmsignfiles.h"` in sign/rpmgensig.c
--
Reply to this email directly or view it on GitHub:
This subpacket is an alternative to the issuer keyid subpacket. It
contains the pubkey version plus the complete fingerprint.
I would prefer to drop all the subpacket definitions from the rpm code, as rpm
has no business dealing with subpackets. Unfortunately
`pgpValString(PGPVAL_SUBTYPE,
You can't trust keys.openpgp.org to only return key material for the query, so
you need to check the returned data to make sure it doesn't contain an extra
pubkey.
It would be safe if rpmkeys had a `--freshen` option that makes sure no new
pubkeys are imported.
--
Reply to this email
Oh wait, I can do this myself.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#issuecomment-2042071468
You are receiving this because you are subscribed to this thread.
Message ID: ___
In the light of the xz attack, could you please remove me from the list of
people that have direct push rights to the rpm code? I don't see why I would
need it because everything is done with pull requests, and it's just increasing
the attack surface.
--
Reply to this email directly or view
I don't get that. Currently rpm will not import anything at all if the keyid is
already known. I'm not even talking about what rpm --import does (it should
probably merge pgp packets), I'm just talking about how the pseudo-package rpm
generates is named.
--
Reply to this email directly or
And you should certainly not ask a keyserver for keys you want to import into
the rpm database.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2039437101
You are receiving this because you are subscribed to this
I know that. It does not need to be 100% correct (it obviously can't). The use
case is to have a different release when the expire time of a key is extended.
For example, SUSE has those keys:
build-rsa-307e3d54-44201d5d.asc
build-rsa-307e3d54-4be01a65.asc
build-rsa-307e3d54-53287cdc.asc
Yes. The old code was very stupid in that regard, it just took the time from
the first signature. It didn't even check if the signature really was a
self-signature.
My proposal is to add a "pgpDigParamsModificationTime()" that returns the
maximum of all self-signature creation time (they can
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3020
-- Commit Summary --
* Bring back the test of the buildtime macro
-- File Changes --
M tests/rpmbuild.at (22)
-- Patch Links --
I accidentally merged this by pushing to the wrong remote. I'm really sorry
about this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#issuecomment-2039325097
You are receiving this because you are subscribed to this thread.
@mlschroe pushed 0 commits.
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944/files/36e2f4259ccfdf3ccf6ae271edb5fc052b0b..aa7c57c0b820a407ffd9b2ad00f990f698505df6
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2944.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#event-12370608022
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
...since the keyring changes done in 2008. I'm so out of touch with rpm...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034700620
You are receiving this because you are subscribed to this thread.
Message ID:
OTOH rpm only looks at the keyid to check if the key is already present since
some time...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034511695
You are receiving this because you are subscribed to this thread.
Ah, I missed that. Then please ignore me ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034198154
You are receiving this because you are subscribed to this thread.
Message ID:
Why wouldn't it make sense? Sequoia needs to do digesting anyway to verify the
signatures, it might as well expose the functionality. Securitywise it is bad
design if two implementations are used.
--
Reply to this email directly or view it on GitHub:
You really should use Sequoia for digesting. It makes no sense to use
openssl/libgcrypt in rpm and something else in sequoia. If it's not already
exposed, can you please add expose digesting functionality in Sequoia?
--
Reply to this email directly or view it on GitHub:
It needs to get a new release when the key us updated, otherwise the rpm
--import will just do nothing.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2034037416
You are receiving this because you are subscribed to
I.e. pgpDigParamsCreationTime() is somewhat misnamed, it does not the key
creation time.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-2033982940
You are receiving this because you are subscribed to this thread.
This somehow slipped my radar. The "time" used in rpm is not supposed to be the
key creation time, but the last time the key was changed. I don't think you
should break this.
--
Reply to this email directly or view it on GitHub:
Reopened #2004.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2004#event-12337884161
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing
Note that pgpGrab() is in the public API. I could not find any usage outside of
rpm, though.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3013#issuecomment-2031922210
You are receiving this because you are subscribed to this thread.
rpmvs.c is the only one using it in the rpm source and it can be trivially
rewritten.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3013
-- Commit Summary --
* Get rid of pgpGrab()
-- File Changes --
M
Fixed with
https://github.com/rpm-software-management/rpmpgp_legacy/commit/31c2f3d017372ee11b6c7403f13889736757c046
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3001#issuecomment-2031713736
You are receiving this because you are
Yeah, that's also what I was going to implement. The userid seems to be
optional.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3001#issuecomment-2031710562
You are receiving this because you are subscribed to this thread.
Message
I think the original intend was to make the macro definitions look like bash
function definitions.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2976#issuecomment-2031386866
You are receiving this because you are subscribed to this
The code in doDefine() supports multiline macros, it's that nasty rdcl()
function that is to blame here.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2976#issuecomment-2031383183
You are receiving this because you are subscribed to
There's not much you can do against a malicious upstream.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2031325567
You are receiving this because you are subscribed to this thread.
Message ID:
@mlschroe pushed 1 commit.
c9579db452e4d4c6996d30419889f831c15c68b3 Support clamping the file mtime to
the build time
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944/files/be088c0aa13707a14962d649823b696b3d5a2c7e..c9579db452e4d4c6996d30419889f831c15c68b3
You are
I've updated the pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#issuecomment-2023034485
You are receiving this because you are subscribed to this thread.
Message ID: ___
@mlschroe pushed 1 commit.
be088c0aa13707a14962d649823b696b3d5a2c7e Support clamping the file mtime to
the build time
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944/files/ee365274c42530286a09dad1fc83144ef478b25a..be088c0aa13707a14962d649823b696b3d5a2c7e
You are
Our headers are always useing utf8 and the pax standard also requires utf8
strings. So do this nasty little locale switching to make libarchive not depend
on the active locale.
You can view, comment on, or merge this pull request online at:
Yes, I'll take the ownership for now. Thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2414#issuecomment-2017947916
You are receiving this because you are subscribed to this thread.
Message ID:
I'll open a pull request for this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-2017876840
You are receiving this because you are subscribed to this thread.
Message ID:
Ok, let's move on with this. Time for some bike shedding.
Proposal 1:
add `%clamp_mtime}` with supported values `buildtime`, `source_date_epoch`
Proposal 2:
add `%mtime_policy` with supported values `clamp_to_buildtime`,
`clamp_to_source_data_epoch`
I added proposal 2 because the original pull
That makes things a bit easier, so we just need to teach libarchive that it
should accept utf8. I'll adapt the title of this issue ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-2003579832
You are receiving this
Why "legacy"? Does the current code reject non-utf8 file names?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-2003513183
You are receiving this because you are subscribed to this thread.
Message ID:
I think pretty much everybody that uses rpmarchive just does it to pipe it into
tar/cpio to extract the content. How about adding an option so that it can
directly extract the content?
--
Reply to this email directly or view it on GitHub:
And this is about file names, I think "upstream rpm" treats those pretty much
as binary as they are created by the build process and not part of the spec
file.
--
Reply to this email directly or view it on GitHub:
It just warns about the unknown attribute.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-2003338390
You are receiving this because you are subscribed to this thread.
Message ID:
It's kinda sad that this strips the leading spaces:
```
rpm -E "%{lua:macros.define({'foo', ' 1 '})}" -E "x%{foo}x"
>1 <
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2962#issuecomment-1999675441
You are receiving this because
I noticed that there is no documentation for this construct
```
$ rpm --define 'foo { bar }' --eval '>%{foo}<'
> bar <
```
Should we document it? Or is that feature deprecated? Does anybody use it at
all?
--
Reply to this email directly or view it on GitHub:
It's not much work to not use libarchive for writing. The only two formats that
can be used for archive writing are cpio and pax (all the others have too many
limitations). Writing cpio is easy and writing a pax tar file is also not hard
(reading a tar file is where it gets really messy because
I find it very surprising that bsdtar's output depends on the current locale,
but that seems to be the case:
```
$ echo hello > micro_µ
$ bsdtar -cf - . | bsdtar -tf -
./
./micro_µ
$ LC_CTYPE=de_DE@euro bsdtar -cf - . | bsdtar -tf -
./
./micro_µ
$ LC_CTYPE=de_DE@euro bsdtar --options
Btw, it cannot handle UTF8 filenames as well, as it checks the current locale
which is not initialized and thus 7 bit ascii...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-1999274523
You are receiving this because
Oh, and the error handling in rpm2archive is completely broken...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2972#issuecomment-1999270285
You are receiving this because you are subscribed to this thread.
Message ID:
In the newc cpio format the content of hardlinked files is
supposted to be stored with the last hardlink and not the first.
Fixes issue #2974
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2975
-- Commit Summary --
*
With the newc format, the content of hardlinked files is supposted to be stored
with the last hardlink. This is different from tar, where the content is stored
with the first entry. rpm2archive always stores the content with the first
hardlink.
This does not seem to matter in practice, as both
In this case archive_write_header() returns ARCHIVE_WARN, which is treated as
error in rpm2archive. OTOH I don't think libarchive should mess with the file
names, maybe it makes sense to set the hdrcharset to `BINARY` for pax. But that
adds a "hdrcharset=BINARY" attribute that GNU tar complains
It fails because it want to convert the filenames to utf8:
$ echo $LC_CTYPE
de_DE@euro
$ rpm2archive /usr/src/packages/RPMS/x86_64/empty-3.0.0-1.x86_64.rpm >
/dev/null
Error writing archive: Can't translate pathname './fooöo' to UTF-8 (84)
--
Reply to this email directly or view it on GitHub:
You can already do:
```
macros.echo({"hello world"})
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2967#issuecomment-1994089448
You are receiving this because you are subscribed to this thread.
Message ID:
Note that we need to come up with something that works both for `Source:` and
`%sourcelist`
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-1991682334
You are receiving this because you are subscribed to this thread.
@mlschroe requested changes on this pull request.
You need to set the signal handler to SIG_DFL in the child
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2958#pullrequestreview-1931036967
You are receiving this because you are
The offset in the region trailer in the Data section is supposed to be negative
for some reason. I.e. the description of the offset in the second table is not
correct.
Btw, does deleting of tags via dribbles really work? I didn't think it was
possible...
--
Reply to this email directly or
The default in libsolv (and also what SUSE uses) is actually to remove those
packages in distro-sync mode if they get in the way. But dnf turns disables
this feature:
```
/* don't erase packages that are no longer in repo during distupgrade */
solver.set_flag(SOLVER_FLAG_KEEP_ORPHANS,
You probably already know this, but rpmbuild is killed by the write() system
that writes the filelist to the generator being done after the child has exited.
I think the only way to prevent this is to ignore SIGPIPE before calling
write(). Everything else like the select() thing we currently do
For reference: https://bugzilla.suse.com/show_bug.cgi?id=1220213
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2949#issuecomment-1980932247
You are receiving this because you are subscribed to this thread.
Message ID:
This is a bit of a corner case, but I just received a bug report that builds
sometimes terminate for a specific package. It turned out the package contained
this little gem:
```
%define __perllib_provides /bin/true
```
Anyway, I don't think rpm should be killed by this. Once upon a time
See https://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
for testcases ;-)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#issuecomment-1978695068
You are receiving this because you are subscribed to this thread.
If you strip trailing slashes you also have to do it for %basename
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2945#issuecomment-1978685964
You are receiving this because you are subscribed to this thread.
Message ID:
@mlschroe commented on this pull request.
> @@ -245,6 +245,10 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%clamp_mtime_to_source_date_epoch 0
+# If true, make sure that timestamps in built rpms
+#
@mlschroe commented on this pull request.
> - goto exit;
+
+ if (!spec->buildDir) {
+ /* Using release here causes a buildid no-recompute test to fail */
+ spec->buildDir =
rpmExpand("%{_top_builddir}/%{NAME}-%{VERSION}-%{_arch}", NULL);
+ /*
@mlschroe commented on this pull request.
> if (initialPackage) {
if (checkForRequiredForBuild(pkg->header)) {
goto exit;
}
- char *buildRoot = rpmGetPath(spec->buildRoot, NULL);
- free(spec->buildRoot);
- spec->buildRoot = buildRoot;
-
@mlschroe pushed 2 commits.
2880adc356b3808241ab348c372f190dd48cb624 Add support for a _buildtime macro
for setting the build time manually
ee365274c42530286a09dad1fc83144ef478b25a Support clamping the file mtime to
the build time
--
View it on GitHub:
This makes it easier to reproduce a build that was done without
SOURCE_DATE_EPOCH. The two new macros are opt in so that the current
functionality is not touched.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2944
--
I think this all has drifted away from the initial proposal. The goal was to be
able to improve reproducibility of a given rpm by:
- adding a way to specify the buildtime
- adding an option to clamp the file mtimes to the buildtime
Disregarding the implementation details, do you all think this
Maybe a warning would be less intrusive. (And what about `%{zzz foo}`?)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2940#issuecomment-1969148570
You are receiving this because you are subscribed to this thread.
Message ID:
Your "test-define" example is also not working like you expect. If you add
```
%define test 2
```
at the top of the specfile and add "%test" to your echo statement, you'll see
that it echos "2" even if you call rpmbuild with `--define "test 1"`.
Basically --define and --undefine work similar to
True. I'm fine with leaving it the way it is.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932#issuecomment-1966443986
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2932 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932#event-11935607092
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
There are good reasons to leave it the way it is, I just wanted to point out
that there's a somewhat undocumented difference.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932#issuecomment-1966339147
You are receiving this because
I stumbled over this:
```
$ rpm --eval '%{?_libdir:foo}'
foo
$ rpm --eval '%{_libdir:foo}'
/usr/lib64
```
Should those two both return `foo`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2932
You are receiving this because you are
We don't use LIKE anymore since commit
c9380471adfa9fb06ace251a5f02b348507db345, so maybe we
can just remove the pragma?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2925#issuecomment-1961484365
You are receiving this because you
The examples for getcwd() and getenv() use `!=` as inequality test. That's
invalid in lua, it is supposed to be `~=` instead.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2929
You are receiving this because you are subscribed to
We're testing for it in the test cases so it might be intentional, but is there
any good reason why `%{dirname:foo}` returns `foo` instead of `` or `.`? At
least the documentation says it is a "dirname(1) macro analogue"...
--
Reply to this email directly or view it on GitHub:
@mlschroe approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#pullrequestreview-1887945667
You are receiving this because you are subscribed to this thread.
Message ID:
Aaand, if `c` is signed, doesn't the < 0x20 break utf8?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#issuecomment-1948368777
You are receiving this because you are subscribed to this thread.
Message ID:
And shouldn't it be `\\u%04x` instead of `u%04x`?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#issuecomment-1948365421
You are receiving this because you are subscribed to this thread.
Message ID:
Your `\r` escaping has a typo: it uses \t instead of \r.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#issuecomment-1948362268
You are receiving this because you are subscribed to this thread.
Message ID:
Seems like it's missing escaping of weird characters like everything < 0x20
(most important`\n`), the `\` and the `"` characters.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#issuecomment-1948064464
You are receiving this because
Here's some thoughts about improving reproducible builds with rpm. The goal
(for me) is to be able to reproduce a rpm given the source rpm.
We currently have the following switches:
- `%source_date_epoch_from_changelog`
- `%use_source_date_epoch_as_buildtime`
-
Just as datapoint: SUSE switched to ndb a couple of years ago and I've not
heard of any problems with the ndb database.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1931583617
You are receiving this because you are
That looks like the correct output to me. Why do you think it doesn't work?
Note that %quote does not add any quotes, the effect is purely internal. Here's
how to make it visible:
```
$ rpm --define '%foo(D:) %{shescape %{**}}' --eval '%foo -D"33 44" argument'
'-D"33' '44"' 'argument'
$ rpm
But the change that documented it was commit
a5bd7571358c7974da1c909e331525b13dce1264 by Ralf done March 2023
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2449#issuecomment-1903870809
You are receiving this because you are
(We might be able to change the behavior of %-f so that it includes all
occurrences, but even that makes me a bit uneasy.)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2449#issuecomment-1903859438
You are receiving this because you
1 - 100 of 791 matches
Mail list logo
