Re: [Rpm-maint] [rpm-software-management/rpm] Make the "rpmbuild debuginfo -g3 .debug_macro" test an expected fail … (#1267)

2020-06-10 Thread Panu Matilainen
"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)

2020-06-10 Thread Panu Matilainen
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

2020-06-10 Thread Helge Kreutzmann
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)

2020-06-10 Thread Igor Raits
@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)

2020-06-10 Thread Tom Stellard
…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)

2020-06-10 Thread jessorensen
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)

2020-06-10 Thread Colin Walters
> 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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Ludwig Nussel
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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
@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)

2020-06-10 Thread Panu Matilainen
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)

2020-06-10 Thread Panu Matilainen
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)

2020-06-10 Thread Florian Festi
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)

2020-06-10 Thread Florian Festi
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)

2020-06-10 Thread Florian Festi
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)

2020-06-10 Thread Igor Raits
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)

2020-06-10 Thread Panu Matilainen
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)

2020-06-10 Thread Panu Matilainen
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)

2020-06-10 Thread Panu Matilainen
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)

2020-06-10 Thread Panu Matilainen
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