> copying the id from the one being rebuilt would be wrong
Okay, got it.
Any reason we can't do better than guessing when populating SOURCERPM?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1000.
--
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/1000#event-2933844609___
Rpm-maint mailing list
It's related to #957 allright, in that this request is the very reason for the
existence of that ticket.
Rpm cannot inject SOURCEPKGID on builds where src.rpm is not generated, and
copying the id from the one being rebuilt would be wrong. See
https://bugzilla.redhat.com/show_bug.cgi?id=1741715
@fedya OpenMandriva 3.0 was rpm5, not rpm4. It isn't normally supported to sign
rpm5 packages with rpm4. If it was working with OpenMandriva 4.0 with rpm 4.14,
then that's a different story...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Right now, SOURCERPM seems to be a prediction of what the source package name
SHOULD be.
Since the source package is given directly when building with `-rb`, the
SOURCERPM should be set based on that package and the SHOURCEPKGID should also
be set appropriately.
>From what I can tell, this
i'm trying to sign rpm5 package from here
http://abf-downloads.rosalinux.ru/rosa2016.1/container/3181857/x86_64/main/release-rpm-new/
with rpm --addsign
my ~/.rpmmacros
```
%_signature gpg
%_gpg_path /root/.gnupg
%_gpg_name 16a853e7
%_gpgbin /usr/bin/gpg
%__gpg_check_password_cmd /bin/true
Is there a place where one can get info on the Python bindings? Like explaining
all the API and what types of data is returned.
Thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@fedya Were you using rpm4 to sign six months ago? If so, what version and what
distribution?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It was OpenMandriva 3.0
--
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/1002#issuecomment-572292482___
Rpm-maint mailing list
pmatilai commented on this pull request.
> +{
+rpmlog(RPMLOG_ERR, "bdb_ro error reading %s database\n", dbi->dbi_file);
+}
+
+static int bdbro_Open(rpmdb rdb, rpmDbiTagVal rpmtag, dbiIndex * dbip, int
flags)
+{
+const char *dbhome = rpmdbHome(rdb);
+dbiIndex dbi = NULL;
+char
No objections (obviously), just out of curiosity: how did you spot this, is
this to address something that came up with rpm, or just looking for common
errors related to dl*() usage (or something else)?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
> I think I'd be more comfortable with this if it conflicted with the regular
> bdb backend option.
Now that I looked this a bit closer, conflicting would be both unnecessary and
plain draconian. If both are enabled in configure, real BDB always wins on
autodetection but either can be manually
BDBD, LMDB and SQLite were already implicitly enabled via build
dependencies, but NDB build has not been enabled at all.
Came up when discussing read-only BDB in #980.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/999
--
pmatilai 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-bdb-ro
(EXPERIMENTAL)],[enable the
pmatilai commented on this pull request.
> + if (meta[4] < 8 || meta[4] > 10) {
+ fprintf(stderr, "unsupported hash version %d\n", meta[4]);
+ bdb_close(db);
+ return 0;
+ }
+ db->maxbucket = meta[18];
+ db->highmask = meta[19];
+
pmatilai commented on this pull request.
> + *dbip = dbi;
+return 0;
+}
+
+static int bdbro_Close(dbiIndex dbi, unsigned int flags)
+{
+if (dbi->dbi_db)
+ bdb_close(dbi->dbi_db);
+dbiFree(dbi);
+return 0;
+}
+
+static int bdbro_Verify(dbiIndex dbi, unsigned int flags)
pmatilai commented on this pull request.
> + return EPERM;
+if ((dbi = dbiNew(rdb, rpmtag)) == NULL)
+ return 1;
+path = rstrscat(NULL, dbhome, "/", dbi->dbi_file, NULL);
+rpmlog(RPMLOG_DEBUG, "opening db index %s\n", path);
+dbi->dbi_db = bdb_open(path);
+
Conan-Kudo 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/999#pullrequestreview-339815518___
Merged #999 into master.
--
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/999#event-2931082075___
Rpm-maint mailing list
Merged #998 into master.
--
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/998#event-2930794790___
Rpm-maint mailing list
Ack. Useful to know as such things have a tendency to happen again after the
first occurrence :)
Thanks for the info and the patch too of course.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It came up when testing a combination of dnf, musl C library, and newer
elfutils (with libdebuginfod disabled). libdw from elfutils tries to dlopen() a
non-existing libdebuginfod, but never fetches the error via dlerrror(), so when
rpm later loads a plugin (successfully) and issues dlerror(),
22 matches
Mail list logo
