"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
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:
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
@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:
…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
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?
> 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
@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
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
@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",
+
@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,
@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
+
@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
+
@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) {
+
@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)
@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) {
+
@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), "/"))
+
@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)
@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),
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
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:
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
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
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:
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
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
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
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:
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
29 matches
Mail list logo
