Re: [Rpm-maint] [rpm-software-management/rpm] Make the "rpmbuild debuginfo -g3 .debug_macro" test an expected fail … (#1267)
"relies on a DWARF5 feature which clang <= 10 does not support" sounds as if the situation is about to change though, and okay I found this: https://reviews.llvm.org/D72828. In that case we should XFAIL based on clang version instead. In any case, please fix the commit summary to fit on one line. Something like "Expect failure on DWARF5 tests on clang" is a more succinct way of saying that, information about the upstream status and versions should be explained in the message itself. -- 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/1267#issuecomment-642422049___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
This isn't just for dnf's benefit. It's a mechanism that anybody who needs to do so is free to listen, and everybody else can ignore. -- 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/1255#issuecomment-642408715___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] Fwd: Errors in rpm man pages
Hello rpm maintainers, On Sat, May 09, 2020 at 11:27:01AM +0200, Helge Kreutzmann wrote: > I'm now reporting the errors for your project. If future reports should > use another channel, please let me know. As I'm not a developer, I intend to unsubscribe soon. If you have any question do not hesitate to contact me directly. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make the "rpmbuild debuginfo -g3 .debug_macro" test an expected fail … (#1267)
@ignatenkobrain 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/1267#pullrequestreview-428370928___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make the "rpmbuild debuginfo -g3 .debug_macro" test an expected fail … (#1267)
…when using clang This relies on a DWARF5 feature which clang = 10 does not support. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1267 -- Commit Summary -- * Make the rpmbuild debuginfo -g3 .debug_macro test an expected fail when using clang -- File Changes -- M tests/rpmbuild.at (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1267.patch https://github.com/rpm-software-management/rpm/pull/1267.diff -- 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/1267 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
I rebased the branch to make sure it applies cleanly to master. I also added an additional patch, introducing the --verity-algo argument to rpmsign, allowing the user to specify the algorithm to use for the verity signatures. Is there anything else you would like me to address at this point? -- 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/1203#issuecomment-642125240___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
> Well, we add this on request of the DNF team that need to be notified if > something else (rpm cli) changes the rpmdb underneath their daemon. Ah, I see. Well, nothing else can/should be changing the rpmdb on rpm-ostree based systems (see also https://github.com/coreos/rpm-ostree/pull/1789 where rpm-ostree will start wrapping `/usr/bin/rpm`). > So this is going to be a plugin that can be disabled or just plainly not be > installed in the first place. We will probably not integrate this into the > systemd-inhibit plugin but have it as a separate plugin that is very similar > and comes in it's own sub package. OK that seems fine, then we can not install it in the container image and rpm-ostree based systems. > Can you please elaborate on why sending some DBus signals should be > problematic? A few things. First, rpm-ostree updates are *offline* (generating a new root) by default - so anything listening and responding to these DBus signals would be confused because it's not affecting the *current* rpm database but a new one it can't see. Second, and related to that - which exact component would be listening to these signals? Would it be `dnf` or `libdnf`? I really hope it's not the library because then rpm-ostree would be talking to *itself* over DBus which...yeah I would like not to have that happen :smile: Do we really need DBus for this versus just e.g. having interested processes use `inotify()` on the path to the rpmdb's directory, and ensuring that RPM does `touch(/path/to/rpmdb)` whenever it makes a change? This is basically what we do for ostree changes. (And yes in some cases rpm-ostreed does catch inotify updates from its own changes but that's kind of intentional and much less heavy-weight than talking to oneself over dbus) -- 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/1255#issuecomment-642022674___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@pmatilai commented on this pull request.
>
if (gpg_path && *gpg_path != '\0')
(void) setenv("GNUPGHOME", gpg_path, 1);
+ if (tty)
+ setenv("GPG_TTY", tty, 0);
+ else if (!getenv("GPG_TTY"))
+ rpmlog(RPMLOG_WARNING, _("Could not set GPG_TTY to stdin: %m\n"));
This seems a bit fishy: technically, setenv() can fail too, but this getenv()
check would not catch that even if the message basically says to do so. Instead
that %m might be related to ttyname() or setenv() for GNUPGHOME failing, or
even earlier, getenv() does not set errno itself at all. I'd suggest moving
this section before the GNUPGHOME section and doing the GPG_TTY environment
check always.
Seems to me this should be moved section should be moved before the
gpg_path/GNUPGHOME thing to eliminate that ambiguity, and the getenv("GPG_TTY")
check always performed (ie remove the 'else').
--
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/938#pullrequestreview-427995405___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpmdb --exportdb needs write access to the lock file (#1266)
rpmdb --exportdb calls rpmtxnBegin() with RPMTXN_READ flags. Internally that function calls rpmlockNew() and rpmlockAcquire(). Neither function has a flags parameter to specify what kind of lock is requested. rpmlockNew() automatically creates a read lock if it can't open the .rpm.lock file in RW mode. rpmlockAcquire() however wants to establish a write lock always so won't work on a read-only lock. So in the end it means that means rpmdb --exportdb only works as root on a read-write file system. Doesn't work for unprivileged users, nor on read only file systems. That doesn't seem to be intentional given the rpmlockNew() fallback to a read lock. -- 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/1266___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> + fprintf(stderr, "Connection Error (%s)\n", err.message);
+ dbus_error_free();
+ }
+ if (state->bus) {
+ rc = dbus_bus_request_name(state->bus, "org.rpm.announce",
+ DBUS_NAME_FLAG_REPLACE_EXISTING , );
+ }
+ if (dbus_error_is_set()) {
+ //fprintf(stderr, "Name Error (%s)\n", err.message);
+ dbus_error_free();
+ }
+ if (DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER != rc) {
+ dbus_connection_close(state->bus);
+ dbus_connection_unref(state->bus);
+ state->bus = NULL;
+ state->logging = 0;
Unify this with the code in cleanup hook, maybe close_dbus() helper or such.
--
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/1255#pullrequestreview-427927188___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> +return RPMRC_OK;
+}
+
+static rpmRC dbus_announce_tsm_pre(rpmPlugin plugin, rpmts ts)
+{
+int rc;
+
+rc = open_dbus(plugin, ts);
+if (rc != RPMRC_OK)
+ return rc;
+return send_ts_message(plugin, "StartTransaction", ts, RPMRC_OK);
+}
+
+static rpmRC dbus_announce_tsm_post(rpmPlugin plugin, rpmts ts, int res)
+{
+return send_ts_message(plugin, "CompleteTransaction", ts, res);
This is perhaps in the bike-shedding department, but "complete" by definition
seems to indicate success, whereas this can have an error condition as well. So
maybe "EndTransaction" would be closer to pairing with Start in these context.
--
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/1255#pullrequestreview-427924424___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> +char * dbcookie;
+
+if (!state->logging) {
+ return RPMRC_OK;
+}
+
+msg = dbus_message_new_signal("/org/rpm/Transaction", // object name
+ "org.rpm.Transaction", // interface name
+ name); // name of the signal
+if (NULL == msg) {
+ return RPMRC_FAIL;
+}
+
+dbcookie = rpmdbCookie(rpmtsGetRdb(ts));
+if (!dbus_message_append_args(msg, DBUS_TYPE_STRING, )) {
+ return RPMRC_FAIL;
Probably should also add the transaction ID to these messages.
--
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/1255#discussion_r438021380___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> +char * dbcookie;
+
+if (!state->logging) {
+ return RPMRC_OK;
+}
+
+msg = dbus_message_new_signal("/org/rpm/Transaction", // object name
+ "org.rpm.Transaction", // interface name
+ name); // name of the signal
+if (NULL == msg) {
+ return RPMRC_FAIL;
+}
+
+dbcookie = rpmdbCookie(rpmtsGetRdb(ts));
+if (!dbus_message_append_args(msg, DBUS_TYPE_STRING, )) {
+ return RPMRC_FAIL;
This leaks memory in the failure case.
--
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/1255#pullrequestreview-427912875___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> +
+msg = dbus_message_new_signal("/org/rpm/Transaction", // object name
+ "org.rpm.Transaction", // interface name
+ name); // name of the signal
+if (NULL == msg) {
+ return RPMRC_FAIL;
+}
+
+dbcookie = rpmdbCookie(rpmtsGetRdb(ts));
+if (!dbus_message_append_args(msg, DBUS_TYPE_STRING, )) {
+ return RPMRC_FAIL;
+}
+dbcookie = _free(dbcookie);
+
+if (!dbus_connection_send(state->bus, msg, )) {
+ return RPMRC_FAIL;
Hmm, failing the entire transaction if dbus announce fails seems a bit
dramatic. Then again, if people are actually relying on these signals...
--
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/1255#pullrequestreview-427912576___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> +static rpmRC dbus_announce_init(rpmPlugin plugin, rpmts ts)
+{
+struct dbus_announce_data * state = rcalloc(1, sizeof(*state));
+rpmPluginSetData(plugin, state);
+return RPMRC_OK;
+}
+
+static rpmRC open_dbus(rpmPlugin plugin, rpmts ts)
+{
+struct stat st;
+DBusError err;
+int rc = 0;
+struct dbus_announce_data * state = rpmPluginGetData(plugin);
+
+/* Assume we are logging but... */
+state->logging = 1;
This logging member seems redundant to me, we simply shouldn't open the bus at
all for test- and chroot-transactions. The less state there is to worry about,
the better.
--
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/1255#pullrequestreview-427909419___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> + if (dbus_error_is_set()) {
+ //fprintf(stderr, "Name Error (%s)\n", err.message);
+ dbus_error_free();
+ }
+ if (DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER != rc) {
+ dbus_connection_close(state->bus);
+ dbus_connection_unref(state->bus);
+ state->bus = NULL;
+ state->logging = 0;
+ return RPMRC_NOTFOUND;
+ }
+return RPMRC_OK;
+}
+}
+
+return RPMRC_NOTFOUND;
The return code logic is confusing, with multiple returns in space of just a
few lines.
--
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/1255#pullrequestreview-427904266___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> +
+/* ...don't log test transactions */
+if (rpmtsFlags(ts) & (RPMTRANS_FLAG_TEST|RPMTRANS_FLAG_BUILD_PROBS))
+ state->logging = 0;
+
+/* ...don't log chroot transactions */
+if (!rstreq(rpmtsRootDir(ts), "/"))
+ state->logging = 0;
+
+/* Don't open */
+if (!state->logging || state->bus)
+ return RPMRC_OK;
+
+if (lstat("/run/systemd/system/", ) == 0) {
+if (S_ISDIR(st.st_mode)) {
+ // initialise the error value
Please use `/* ... */` for comments, // is not in the rpm coding style even if
the compiler permits it.
--
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/1255#pullrequestreview-427900196___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> +/* ...don't log chroot transactions */
+if (!rstreq(rpmtsRootDir(ts), "/"))
+ state->logging = 0;
+
+/* Don't open */
+if (!state->logging || state->bus)
+ return RPMRC_OK;
+
+if (lstat("/run/systemd/system/", ) == 0) {
+if (S_ISDIR(st.st_mode)) {
+ // initialise the error value
+ dbus_error_init();
+
+ state->bus = dbus_bus_get_private(DBUS_BUS_SYSTEM, );
+ if (dbus_error_is_set()) {
+ fprintf(stderr, "Connection Error (%s)\n", err.message);
This should be filtered out in case dbus isn't running to begin with, similarly
to what commit 708e61307bc3fd027b016fdf5a1d1a5274c1843c does. Also, rpmlog()
should be used instead of fprintf().
--
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/1255#pullrequestreview-427899061___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
@pmatilai commented on this pull request.
> +state->logging = 1;
+
+/* ...don't log test transactions */
+if (rpmtsFlags(ts) & (RPMTRANS_FLAG_TEST|RPMTRANS_FLAG_BUILD_PROBS))
+ state->logging = 0;
+
+/* ...don't log chroot transactions */
+if (!rstreq(rpmtsRootDir(ts), "/"))
+ state->logging = 0;
+
+/* Don't open */
+if (!state->logging || state->bus)
+ return RPMRC_OK;
+
+if (lstat("/run/systemd/system/", ) == 0) {
+if (S_ISDIR(st.st_mode)) {
That check looks like it's "inherited" from systemd_inhibit plugin, where this
is relevant because we're talking to systemd over dbus (see commit
ec6495d79fa9834bca3394f56e9f6eb933030b1d). This is an entirely different case
though, other processes might want to know about rpmdb state changes regardless
of whether systemd is running or not.
--
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/1255#discussion_r438000287___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add _without_check macro (#1256)
Yeah this needs to interact with both _with_check and _without_check, and not add semantics to %_without_check value. And for that, it'd seem that we need to parse the spec before fiddling with these values as otherwise we can't know about bcond's set in the spec. It also needs a better commit summary regardless of implementation, this is not about some macro being added but integration between --with/without check idiom and --nocheck. -- 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/1256#issuecomment-641884348___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin does not work on Fedora 33 (#1260)
Thanks @ignatenkobrain for spotting and reporting! -- 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/1260#issuecomment-641869253___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerin does not work on Fedora 33 (#1260)
Closed #1260 via #1265. -- 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/1260#event-3428649168___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix completely broken prefix search on sqlite backend (#1265)
Merged #1265 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/1265#event-3428649150___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix completely broken prefix search on sqlite backend (#1265)
Looks good. In my mind the prefix search is also bound to the index iteration. Probably because this is how it was introduced on bdb. -- 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/1265#issuecomment-641862934___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix completely broken prefix search on sqlite backend (#1265)
Seems to fix my problem :) -- 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/1265#issuecomment-641855601___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix tag mixup in 32e2bc50cff9db05729349ff6645a0251d5719fb (#1263)
Merged #1263 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/1263#event-3428547697___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fail the build if %_build_pkgcheck_set failed (#1258)
Merged #1258 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/1258#event-3428535250___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fail the build if %_build_pkgcheck_set failed (#1258)
Oh, somebody is actually using this functionality :sweat_smile: Always useful to know. Thanks for the patch! -- 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/1258#issuecomment-641847640___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix completely broken prefix search on sqlite backend (#1265)
The prefix search was so wrong its a small miracle it ever did anything at all. What have I been thinking? Well, I do remember thinking this prefix stuff looks kinda fishy but then it seems to work so... The prefix search belongs to the keyed iterator fetch case of course, not the case where were otherwise iterating over all keys. Fixes: #1260 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1265 -- Commit Summary -- * Fix completely broken prefix search on sqlite backend -- File Changes -- M lib/backend/sqlite.c (51) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1265.patch https://github.com/rpm-software-management/rpm/pull/1265.diff -- 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/1265 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
