Oh yes, we'll need to do the rpmfilesFpLookup() call for TR_REMOVED packages.
Fixing...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As it now expands the argument I think it should be handled in doFoo().
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
mlschroe commented on this pull request.
> @@ -109,6 +121,27 @@ static char *getMntPoint(const char *dirName, dev_t dev)
return res;
}
+static int getRotational(const char *dirName, dev_t dev)
+{
+int rotational = 1;/* Be a good pessimist, assume the worst */
+#if
@mlschroe pushed 1 commit.
954c491165cacf9156d2e4b0f3afaaaef9c3d529 Only look at symlinks in new packages
in fpLookupSubdir
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
mlschroe commented on this pull request.
> pi = rpmtsiInit(ts);
while ((p = rpmtsiNext(pi, 0)) != NULL) {
fingerPrint *fpList;
(void) rpmsqPoll();
+ if (rpmteType(p) == TR_REMOVED)
+ continue; /* we are only interested in new packages */
mlschroe commented on this pull request.
> @@ -109,6 +121,27 @@ static char *getMntPoint(const char *dirName, dev_t dev)
return res;
}
+static int getRotational(const char *dirName, dev_t dev)
+{
+int rotational = 1;/* Be a good pessimist, assume the worst */
+#if
I've added a commit that makes the code only consider symlinks. Florian, any
objections to this?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 1 commit.
1732cc787d6f508019edc7c455aa02d9b9ad78e6 Only look at symlinks in new packages
in fpLookupSubdir
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
I didn't plan to push more commits, but now that you ask:
Does it really make sense to have the symlinks of already installed packages in
the `symlinks` hash? If a symlink is deleted on disk, the code will ignore it
anyway (see the "Ignore already removed (by eg %pretrans) links" comment). If
Regarding your b81b4a35240f16fa8b45156b0151fab9e130a8e8 commit:
fpLookupSubdir's slash handling is still somewhat broken, it tends to duplicate
slashes when creating the link. The fingerprint lookup fortunately calls
rpmCleanPath() with gets rid of the extra slashes again.
BTW, why do the
Ok, that's what I thought. But it's somewhat brittle, that example from the
mail will not work if FOO-DOC is installed before FOO as then /usr/share/FOO-1
will get created as directory and the install of FOO will fail with a
RPMERR_EXIST_AS_DIR error.
(I'm trying to make dir -> symlink-to-dir
Ok, I have to admit I'm not entirely sure what fpLookupSubdir is trying to fix.
It was added by Florian in commits c6ccc90d7fef0f1b65e4bf5b77d5b800d4b53ffd and
af3464a053ecb0b56cc5af494ea22955fb350757, unfortunately without a reference to
some bug.
It seems to be about having a symlink in one
@mlschroe pushed 1 commit.
1c9343142a728dce571ee0c8ce4f6fae42354588 Reduce the number of calls to
fpLookupSubdir()
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
This reduces the number of calls to fpLookupSubdir() and also gets rid of a
poolid-str-poolid roundtrip.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1071
-- Commit Summary --
* fpLookupSubdir: get rid of a
@mlschroe pushed 1 commit.
3252e1e25872bc7820828425e1daea51d0700b13 Remove duplicated code in
fpLookupSubdir
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe pushed 1 commit.
6232c8e1e515833f3a51af2800d3ab70d82a9e05 fsmMkdirs: do not dup the last
verified directory name
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe pushed 1 commit.
c410531402fe2541566d16b963b1ed575cab8ea9 fsmMkdirs: Remove dnlx array
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
It gets only written to and nobody uses it, so be gone.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1069
-- Commit Summary --
* fsmMkdirs: Remove dnlx array
-- File Changes --
M lib/fsm.c (8)
-- Patch Links --
Simplify the way the fingerprint cache is created.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1068
-- Commit Summary --
* Move fingerprint hash setting out of fpLookupSubdir()
* Remove duplicated code in
@mlschroe pushed 1 commit.
dd4bb9f38fdf1d147a09ca0cdbf38ed75e409b17 Add a --salvagedb option to the rpmdb
tool
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
I'd prefer if we named this %macrobody, so that there's less chance that it
clashes with somebody else's use of %body.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
No, there's a (very) small chance that it picks up entries that have been
deleted. It's like the .recover command of the sqlite cli:
Like the ".dump" command, ".recover" attempts to convert the entire contents of
a database file to text. The difference is that instead of reading data using
the
Is the argument a macro name or some generic string? I.e. is it
`%{body:_builddir}` which should then return ` %{_topdir}/BUILD`? Or is it
`%{noexpand:%_builddir}` which then should only do one level of expansion? I
find the latter a bit weird.
--
You are receiving this because you are
mlschroe approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1053#pullrequestreview-356505622___
mlschroe commented on this pull request.
> @@ -1784,6 +1784,29 @@ rpmDefineMacro(rpmMacroContext mc, const char * macro,
> int level)
return rc;
}
+int rpmMacroIsDefined(rpmMacroContext mc, const char *n)
+{
+int defined = 0;
+if ((mc = rpmmctxAcquire(mc)) != NULL) {
+ if
(Oh, and I renamed ME_NOEXPAND to ME_LITERAL for consistency)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ok, done. I also used RPMMACRO_LITERAL at some other places where it made sense.
I tried to add it to the buildroot macro (re-)definition, but with buildroot it
is pretty hopeless. rpm's rpmGenPath always expands all arguments, which leads
to the buildroot getting expanded over and over again.
@mlschroe pushed 3 commits.
69f083fe169487a95a0b9a4896dad88dcae4331d Add a ME_LITERAL macro flag that
turns off body expansion
2c5a7c08acae96ab07ae7c6bcee39616f69f852f Add rpmPushMacroFlags function to
allow the definition of literal macros
9c082dc030142eb068a8320ac91f7f106736dcbb Use
mlschroe approved this pull request.
Nice!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 1 commit.
42b61f94e8ae14f484184984246d7ea84ae1bf20 Add rpmPushMacroFlags function to
allow the definition of literal macros
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Another good name would be `ME_LITERAL`.
We also may want to expose this by adding a rpmPushMacroLiteral() function so
that this can be used in other places where we don't want expansion to happen.
E.g. everywhere where we have calculated a file name or path and want to set a
macro for it.
--
This adds a ME_NOEXPAND macro flag that turns off body expansion.
This is much simpler than the weird % character doubling. Its also a bit
faster
because theres less calls to expandMacro().
You can view, comment on, or merge this pull request online at:
Before this commit, there was an escape flag that made the macro
expansion keep %% escapes. But this did not work for macros
that returned an % character by other means.
Remove the old escape mechanism and instead double the % characters
when the body is split into argument.
Fixes: #1055
You can
mlschroe commented on this pull request.
> @@ -514,6 +514,22 @@ static ARGV_t runCmd(const char *cmd,
return output;
}
+static ARGV_t runCall(const char *cmd,
+const char *buildRoot, const char *fn)
+{
+
+ARGV_t output = NULL;
+char *fullcmd = rstrscat(NULL,
I think this should print `hel%loo`:
```
rpm --define 'foo() %1' --define 'loo what' --define 'bar hel%(echo %)loo'
--eval '%{foo %bar}'
```
IMHO we should rip out mb->escape and instead double all '%' characters in the
argv.
--
You are receiving this because you are subscribed to this thread.
mlschroe commented on this pull request.
> @@ -514,6 +514,22 @@ static ARGV_t runCmd(const char *cmd,
return output;
}
+static ARGV_t runCall(const char *cmd,
+const char *buildRoot, const char *fn)
+{
+
+ARGV_t output = NULL;
+char *fullcmd = rstrscat(NULL,
mlschroe commented on this pull request.
> @@ -1784,6 +1784,29 @@ rpmDefineMacro(rpmMacroContext mc, const char * macro,
> int level)
return rc;
}
+int rpmMacroIsDefined(rpmMacroContext mc, const char *n)
+{
+int defined = 0;
+if ((mc = rpmmctxAcquire(mc)) != NULL) {
+ if
What's the purpose of the 'name' part? Is this about supporting signatures from
multiple groups? Or is this about supporting new pubkey algorithms (e.g.
ed22519)?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Oh wow, I knew that %global expands right away when defining the macro, but I
somehow didn't expect that it expands again when the macro is used:
```
$ rpm --eval '
> %define foo
> %global bar
> %foo percent, %bar percent'
%% percent, % percent
```
Is that documented anywhere?
Anyway,
mlschroe commented on this pull request.
> + break;
+case EM_MIPS:
+ elf_machine = "mips";
+ break;
+case EM_PPC:
+case EM_PPC64:
+ elf_machine = "ppc";
+ break;
+case EM_S390:
+ elf_machine = "s390";
+ break;
+case EM_ARM:
+ if
This can be used to recover as much data as possibly from a terminally broken
database. It is currently only supported for the ndb database.
This method is currently hidden from the API by using a macro to select salvage
mode. If it should be more exposed, we can add a rpmtsSalvageDB() method.
See also commit a429c99e13fbe9926243f29b78df8d64222c4469 for db3.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1040
-- Commit Summary --
* Permit ndb database queries on read-only media
-- File Changes --
M
I don't like that it doesn't output anything if neither `--biarch-deps` not
`--multiarch-deps` is provided. I think it would be better to either change the
option to `--no-biarch-deps` or at least default to biarch if neither option is
given.
--
You are receiving this because you are
@mlschroe pushed 5 commits.
da94ee8195da2bc841e2a4606f2948d46a1109bb Drop useless %{F:..} built-in macro
85e5a70368854da0537099128530b0df69ca2216 Fix regression on v3 package handling
on database rebuild
d5c69756cf6cd16e7c2e8b81fba19bf81f3dd1ba Explicitly mention that the rpmio/
sub dir is
doFoo() contains this:
```
if (expand) {
(void) expandThis(mb, g, gn, );
} else {
buf = xmalloc(MACROBUFSIZ + fn + gn);
buf[0] = '\0';
}
```
If `expand` is true (which is the default), expandThis() will allocate the
buffer, rounding up the size of the
It should either escape the '%' chars or use a custom match function.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1018___
rpmdb.c's rpmdbRebuild() function contains this:
```
if (headerIsEntry(h, RPMTAG_HEADERIMAGE)) {
Header nh = headerReload(headerCopy(h), RPMTAG_HEADERIMAGE);
rc = rpmdbAdd(newdb, h);
headerFree(nh);
} else {
```
I guess that
It fails because of
```
macro.c: In function 'doFoo':
macro.c:1211:2: error: 'sprintf' argument 3 may overlap destination object
'buf' [-Werror=restrict]
1211 | sprintf(b, "file%s.file", buf);
| ^~
macro.c:1074:11: note: destination object referenced by
There's now a workaround for this. Instead of adding a new dbiSetNextInstance
call I've opted to change the put functions to make sure that the next instance
counter will be higher than the stored package.
For ndb this change is trivial. The sqlite backend doesn't need changing.
For lmdb/db3
@mlschroe pushed 1 commit.
de1a21071913b20bbb98a2aadf7991ae8e048304 Implement automatic conversion of the
database
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
That's also incorrect. It doesn't copy the "next package" counter, so adding
new packages will overwrite old ones.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ok, fixed. I'm not happy about adding a new parameter to rpmdbRebuild(), but it
seemed to be the easiest way to fix this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 1 commit.
921b1adf0bcb38ec603be3ffa180794824f80cf5 Implement automatic conversion of the
database
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Oh wait, that doesn't work with erases. The rebuildb call must not renumber the
packages.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1012
-- Commit Summary --
* dbi.c: try the configured backend first
* Implement automatic conversion of the database
-- File Changes --
M lib/backend/bdb_ro.c (1)
FYI: I had to revert the ndb glue change, as it caused segfaults if just an
index dbi got closed. The commit doesn't contain any information about the
problem it tries to solve, do you remember why your change was necessary?
--
You are receiving this because you are subscribed to this thread.
Reopened #1009.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1009#event-2950287205___
Rpm-maint mailing list
@mlschroe pushed 0 commits.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1009/files/9076d958bf91502eed454283d7daeafece4c6836..471e7d8bb26f0d7be877a261812b8dd8172650d3
Oh my. The gcc people seem to be not too happy about this, but it's hard to fix
because the void cast is optimized away before the unused result check is done.
See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
Anyway, fixed to something
Fixes #1008
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1009
-- Commit Summary --
* ndb: fix ftruncate return value warning
-- File Changes --
M lib/backend/ndb/rpmxdb.c (2)
-- Patch Links --
Updated the pull request:
- about the dbiNew() call that cannot fail: this is copied from the other
backends. I currently left it untouched so that a different commit can clean up
all the backends.
- about using NULL: I think NULL is some leftover from the old K days and
should be avoided.
@mlschroe pushed 2 commits.
7d7f889c2f6f880810898540b710a88f8b817036 ndb: implement index regeneration if
the index is out of sync
24192af913e549f852f52567d59e435ff46f3c51 Remove the experimental status from
the ndb database
--
You are receiving this because you are subscribed to this
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1005
-- Commit Summary --
* ndb: only clear the dbenv in the rpmdb if the last reference is gone
* ndb: add a rpmxdbDelAllBlobs method
* ndb: implement index regeneration
I get that, but I was under the impression that ndb is still marked as
experimental. (That's about to change in the near future, though.)
Anyway, force pushed to multiple commits.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
I kind of fail to see the point, but I'll do it anyways just to please you.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This commit adds a verify method for ndbs Packages.db database.
It also cleans up the pkgdb code a bit:
* removed unused lzo compression code
* added some more comments and fixed spelling mistakes
* made ordered slots flag a boolean
* fixed a corner case where a package id lookup could segfault
@mlschroe pushed 1 commit.
56736fedb0dba9abeaabff829d97c805ba63e0cb Add support for reading BDB without
the library
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Added a check for the hash/btree version.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/980#issuecomment-568449448___
Db6 just added support for large data blobs and a heap database type, both are
not used by rpm. I tested it with a cooker container image, and the code could
read the database without problems.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Updated the code. It's now much faster and also implements prefix search.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mlschroe pushed 1 commit.
66c055f43b184ab42dc02a219660f866bee48b63 Add support for reading BDB without
the library
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe pushed 1 commit.
97092ae8be7ec0f02c8a4f833f65831625985b84 Add support for reading BDB without
the library
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@mlschroe pushed 1 commit.
042fdf6d8823ea2b3423134f23217f1d1f96d6e5 Add support for reading BDB without
the library
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
mlschroe commented on this pull request.
> @@ -594,6 +594,20 @@ AS_IF([test "$enable_ndb" = yes],[
])
AM_CONDITIONAL([NDB], [test "$enable_ndb" = yes])
+#=
+# Process --enable-bdb-ro
+AC_ARG_ENABLE([bdb-ro], [AS_HELP_STRING([--enable-ndb-ro
(EXPERIMENTAL)],[enable the
This commit implements a slow read-only backend that allows
accessing of BerkeleyDB databases without using the BerkeleyDB
library. The code supports btree version 9 and hash version 8
and 9.
There are two use cases for this:
1) Conversion of an existing BerkeleyDB to a different
backend.
2)
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/979
-- Commit Summary --
* Fix building with no BerkeleyDB support
* Move db_descr assignment from rpmdb to dbi
-- File Changes --
M configure.ac (2)
M
Don't you need to do some escaping in case the prefix includes a '%' or '_'
character?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You may want to rename `skipdata` to `ii_skipdata` so that it fits in better
with the other elements.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
mlschroe approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/971#pullrequestreview-327548592___
Oooh, did you notice the #if 0 code in ndb/glue.c? I once started the same
thing (but used DBC_KEY_SEARCH to select it), but didn't finish the
implementation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
mlschroe approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/969#pullrequestreview-327452563___
Oh yes, the documentation...
Anyway, calling `gcry_check_version(NULL)` results in just another call to
libgcrypt's global_init() function, so doing it doesn't hurt and brings it in
line with the documentation.
--
You are receiving this because you are subscribed to this thread.
Reply to this
What libgcrypt version are you using?
The gcrypt code seems to indicate that GCRYCTL_SET_THREAD_CBS is nowadays a
dummy call that just calls gcrypt's global_init() function. So does
```
gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0);
```
also work for you?
--
You are receiving this because
Wouldn't `%expand` work here? (Note that `suffix` is already used in rpm...)
```
%{expand:%%global something%{suff} value}
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
"Also only return an allocated dbi if everything fails." sounds not quite right
;)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Doing it in the child (i.e. before the execve call) should not block. It just
does the same open that gpg does later on.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Regarding opening the pipe for reading: oh yeah, that's right. You can't do it
before the fork. But it should work if you do it after the fork.
It would be much saner if the gpg call would just read from stdin, i.e. if we
use a normal pipe instead of that named pipe. But it's a bit late to
(A different fix that might also work (untested) would be to simply open the
named pipe for reading before doing the exec call. You can even do that before
the fork(). The opened file descriptor will not be used by gpg, but that
shouldn't hurt.)
--
You are receiving this because you are
A SIGCHLD can happen all the time for whatever reason, you need at least to
check if the process still exists and retry the Fopen if it does and the error
is EINTR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, we have `%_binarychangelogtrim`. The syntax is:
```
%_binarychangelogtrim maxnum,cuttime,minnum
```
It is only applied to binary packages, i.e. the source rpm still has the
complete changelog.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
(openSUSE is not slow to adopt new major versions. rpm-4.15 was released
2019-09-26, it is in the Factory staging project since 2019-10-02.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I wouldn't worry too much about that wrap around: if you add a new rpm header
every tenth of a second, you'll need 13 years for the hdrid to wrap.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The rebuilddb case is handled by stat()ing the database. A rebuilt database
will have a different inode number.
(You probably already know this, but sqlite will guarantee increasing numbers
when you use the AUTOINCREMENT keyword.)
--
You are receiving this because you are subscribed to this
Just FYI, recycling previously used header ids will break libsolv's
`repo_add_rpmdb()` function, which uses the packages from an old solv file if
the header id matches.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You see this with ndb but not lmdb because ndb fsyncs the main database after
each operation. So after a system crash you'll have a correct main database but
outdated indices. With lmdb there's no fsync at all, so you get a outdated main
database with matching indices.
Ndb's behavior is *way*
NDB supports detection of outdated indices since the beginning, but currently
rpm doesn't make use of that option.
So no, it's not yet fixed. (But it's not hard to do so, unlike with bdb)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Note that from a high level perspective, rpm does not need transactions. It
only has to database operations "insert header into database" and "remove
header from database" and only does one operation at a time.
It should be up to the database to keep the index table in sync. Now, rpm's
index
mlschroe approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/910#pullrequestreview-304543216___
Note that some error paths don't work correctly when building without omp.
Those are the ones that use `#pragma omp cancel parallel`, where the `goto
exit;` statements were deleted.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/909
-- Commit Summary --
* Use xdbs pagesize instead of sysconf(_SC_PAGE_SIZE)
* Multiple fixes in rpmxdb.c for the ndb database backend
-- File Changes --
M
401 - 500 of 818 matches
Mail list logo
