Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Add ability to run lua scripts directly (#1273)
Bump. We sure would like to make progress on this so that rpm-ostree can start supporting lua appropriately and not asking packagers to rewrite their scriptlets. -- 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/1273#issuecomment-650429825___ 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 RPMTRANS_FLAG_NOARTIFACTS symbol to Python bindings (#1293)
Merged #1293 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/1293#event-3486446227___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add RPMTRANS_FLAG_NOARTIFACTS symbol to Python bindings (#1293)
Should've been in commit 07ed169da37db05773b608043db859fe2c362a8f You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1293 -- Commit Summary -- * Add RPMTRANS_FLAG_NOARTIFACTS symbol to Python bindings -- File Changes -- M python/rpmmodule.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1293.patch https://github.com/rpm-software-management/rpm/pull/1293.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/1293 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Phasing out obsolete crypto in rpm (#1292)
We need to come up with a plan how to deal with obsoleted crypto in rpm. MD5 is practically gone long since and SHA1 is on its way out too, to the point that it's not necessarily even possible to calculate these algorithms anymore (eg MD5 on FIPS mode). Yet we still carry them in various more-or-less prominent and permanent places such as the MD5 header+payload digest, database indexes (RPMDBI_SIGMD5 and RPMDBI_SHA1HEADER), MD5 aliasing for pkgid, and SHA1 aliasing for hdrid, and so on. -- 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/1292___ 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 --excludeartifacts install option (#1274)
Is there a matching dnf options, like `--setopt=tsflags=noartifacts,nodocs`? -- 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/1274#issuecomment-650109484___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Always fail build on dependency generator failures (#1183)" (#1286)
The other thing is that leaving regressions sitting in the tree with the notion that somebody will fix it at some point is just not okay at all: that s*** *will* accumulate and cause hell to pay when the time to make the next release comes. *Ideally* rpm should be release ready at any given commit. As a general rule, if a regression can't be fixed on the spot, it's usually better to revert and rethink. -- 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/1286#issuecomment-650064212___ 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_TTY warning causes test-suite failure in mock (#1290)
Closed #1290 via #1291. -- 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/1290#event-3485664720___ 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 bogus test-suite failure when input is not a tty (#1290) (#1291)
Merged #1291 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/1291#event-3485664711___ 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)
> > imposes its own signal handling on users when the db is open > > Can turn that off since > [56f49d7](https://github.com/rpm-software-management/rpm/commit/56f49d7f5af7c1c8a3eb478431356195adbfdd25) > right? API users turning off signal handling is not a solution, it's a problem in its own right. > > and our ABI hasn't been particularly stable historically > > Maintaining C shared libraries is indeed extremely hard. I've messed up in > the past and only just barely caught it before releases etc. That said there > are nice tools now like [libabigail](https://pagure.io/libabigail) - should > be easy to set that up on CI here right? > (I still need to do that for ostree) librpm ABI stability or lack of thereof has little to do about it being difficult, it's merely that rpm has historically exported all manner of crap that it never should have, and it's not possible to get rid off it all in one go, unfortunately. So for 12+ years we've done staged "exit accumulated crap, bump soname" releases every now and then, rpm soname bumps are an absolute PITA. > > dbus library itself is much more stable AIUI. > > Yeah, libdbus as a C shared library has been fine and will continue to be so, > but exposing an API over DBus is a separate thing with long term commitments. Eh, no kidding? > > If we're effectively saying most projects shouldn't be using librpm to read > the rpm database effectively (that seems like what you're implying) that's a > rather radical thing right? Maybe I am misunderstanding though. I said no such thing. Different users have different priorities and needs, projects should (be able to) use what works best for them. Linking to librpm comes with heavy and hard to understand babbage and is way too intimate (think "bare metal") for various "casual" users. A DBus API puts a much needed insulation layer between the process that actually accesses rpmdb and the unsuspecting piece of software wanting to know something about packages on the system. With the existing librpm API, very weird things happen in dark corners such as gdb running as root on a 32bit process on a 64bit system, doing rpmdb query for debuginfo discovery. -- 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-650015111___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint