Re: [Rpm-maint] [rpm-software-management/rpm] Filter Lua deprecation warnings based on the originating rpm version (PR #3270)
Anti social or not, the reason for these warning is that those packages won't work with the next RPM version. Not sure if keeping the users in the dark will do them any favors. Right now they can demand the vendor to fix their packages before it is too late. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3270#issuecomment-2325858104 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Filter Lua deprecation warnings based on the originating rpm version (PR #3270)
if we don't actually remove the functions this is fine. We just need to issue the warnings in the last RPM version before removing them. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3270#issuecomment-2325922685 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Filter Lua deprecation warnings based on the originating rpm version (PR #3270)
OK, I could have worded that better. Yes, we need to issue a warning for all new usages. We will need to issue a warning to all usages the release before we actually remove the functions - with the hope that old usage has died out til then. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3270#issuecomment-2325953251 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Non-root owned symlink causes install failure (Issue #3283)
This is a continuation of #3100. Unsafe symlinks are detected during installation and create a failure. This is the right thing to do in case we encounter such things at this phase. But we really need to check for this in advance during the transaction check and not even start the transaction if such symlinks are found. The failure during the transaction is only acceptable if someone tries to escalate their privileges exploiting a race condition. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3283 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Unsafe symlinks lead to missing files (Issue #3284)
See https://issues.redhat.com/browse/RHEL-54386 for details This need examination to check whether this affects newer versions, too. rpm in RHEL 8 has a modern version of the fsm. So it is possible that this is an general issue. It could also be an unfortunate interaction between the new fsm code and the surrounding rpm-4.14.3 code. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3284 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Use long PGP Key IDs for all outputs (PR #3292)
Here how dropping the Short PGP KEy IDs in favor of long ones would look like. We still need to discuss if this really is a change we want in this magnitue or if we need to keep the old behavior at some places. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3292 -- Commit Summary -- * Use long PGP Key IDs for all outputs * Use long PGP Key Ids in our test cases -- File Changes -- M rpmio/rpmpgp.c (2) M tests/rpmi.at (16) M tests/rpmquery.at (2) M tests/rpmsigdig.at (112) M tests/rpmvfylevel.at (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3292.patch https://github.com/rpm-software-management/rpm/pull/3292.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3292 You are receiving this because you are subscribed to this thread. Message ID:___ 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 should not use short gpg key ids in messages (Issue #2403)
OK, sketched a patch for moving from short to long Key IDs in the messages: #3292. This is trivial to do but may be not trivial to deal with. Moving to Fingerprints is not quite as trivial. We do have the means to get Fingerprints from PGP keys but so far we lack that for signatures. I am currently still digging through the backends to see what would be needed to get them. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2403#issuecomment-2340306895 You are receiving this because you are subscribed to this thread. Message ID: ___ 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 should not use short gpg key ids in messages (Issue #2403)
Internally it looks like most places are just using the Key ID. Especially the rpmkeyring is using it as a key in the hash of all Pubkeys. If we don't have any hope to move that to Fingerprints as the v3 signatures won't offer them anyway, we might need to go down another route and just verify signatures more often and get the Fingerprints from the successfully verifying Pubkey. I am currently already compiling a list of all usages of the Key ID. I'll report back when I got the complete list. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2403#issuecomment-2340354908 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Reference Manual: RPM's Philosophy (PR #3299)
First brain dump. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3299 -- Commit Summary -- * About Reference Manual * Reference Manual: RPM's Philosophy -- File Changes -- M docs/CMakeLists.txt (2) A docs/manual/about.md (29) M docs/manual/index.md (3) A docs/manual/philosophy.md (148) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3299.patch https://github.com/rpm-software-management/rpm/pull/3299.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3299 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reference Manual: RPM's Philosophy (PR #3299)
@ffesti pushed 1 commit. 2efe3cfb546c4f9bed0d5a8c9ab99463991d6bf8 Reference Manual: RPM's Philosophy -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3299/files/82a40f72c7574400c0f7995a7497b538ca566861..2efe3cfb546c4f9bed0d5a8c9ab99463991d6bf8 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reference Manual: RPM's Philosophy (PR #3299)
@ffesti pushed 1 commit. 255a8fa4647ff07a66fb4d63d41c6c54696d3293 Reference Manual: RPM's Philosophy -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3299/files/2efe3cfb546c4f9bed0d5a8c9ab99463991d6bf8..255a8fa4647ff07a66fb4d63d41c6c54696d3293 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reference Manual: RPM's Philosophy (PR #3299)
Thanks a lot! Good to have a native speaker reading over this. Added the suggested changes. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3299#issuecomment-2346182247 You are receiving this because you are subscribed to this thread. Message ID: ___ 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 regression preventing manual %debug_package usage (PR #3296)
Merged #3296 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3296#event-14245297793 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Duplicate __debug_package causes problems for spec files directly using %debug_package (Issue #3290)
Closed #3290 as completed via #3296. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3290#event-14245298153 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support signing with Sequoia through a simple macro switch (PR #3282)
Merged #3282 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3282#event-14245497357 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document using Sequoia for signing (Issue #3248)
Closed #3248 as completed via #3282. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3248#event-14245497561 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document using Sequoia for signing (Issue #3248)
Closed #3248 as completed via d99186f2ef6fc0dfaaefe599a98492a84fd18940. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3248#event-14245497584 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't consider MD5 and SHA1 when verifying packages (PR #3293)
I wonder if messages like "MD5 digest: NOTFOUND" are really thing to do if we don't even look at those checksums. It's not that they were not found they were not looked for. May be we need a different message for when we ignore them. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3293#issuecomment-2348437284 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RPM treats disabled digests and signatures equal to not being present (Issue #3303)
This results in messages like `MD5 digest: NOTFOUND` which is confusing as the MD5 sum may just be there RPM is just not looking for it. We should at least give a message that shows we didn't even look - or may be give the status and state that it is ignored. Not sure if this is possible with things like FIPS where we might not be supposed to use the old algorithms at all. See #3293 for examples. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3303 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Phasing out obsolete crypto in rpm (#1292)
Closed #1292 as completed via #3293. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1292#event-14246488062 You are receiving this because you commented. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't consider MD5 and SHA1 when verifying packages (PR #3293)
Merged #3293 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3293#event-14246487852 You are receiving this because you are subscribed to this thread. Message ID: ___ 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 should not use short gpg key ids in messages (Issue #2403)
Here my findings so far: ### PGP KeyID and FingerPrint usage in RPM * PGP Fingerprint: 20 or 32 bytes hash of public key (depending on key algorithm) * (Long) KeyId: last 8 bytes of Fingerprint * Short KeyId: last 4 bytes of Fingerprint Short KeyId is prone to (accidental) collisions Long KeyId still can have collisions if searched for by an attacker * pgpPubkeyFingerprint() is not used at all execpt in one test case * const uint8_t *pgpDigParamsSignID(pgpDigParams digp) returns Long KeyId of signatures. Signatures only return KeyID. Fingerprint just not available for v3 PGP sigs. v4 PGP signatures contain Fingerprint but RPM does of have any means to get them right now. We could get the Fingerprint from the matching key - if available. ### Short KeyID in RPM * rpmio/rpmpgp.c L56 pgpIdentItem() * PR #3292 moves to long KeyId * See Pubkey Packages * rpmvs.c: sinfo->keyid Used to suppress repeat log messages - needs to die but is not critical ### Using FingerPrint instead of KeyID const uint8_t *pgpDigParamsSignID(pgpDigParams digp); Usage: * rpmkeyring.c: internally to find Pubkey for signatures. Probably fine, may need handling of conflicting KeyIDs. * lib/formats.c: pgpsigFormat() Human readable signature with KeyID. May need FingerPrints iff available in sig or keyring? * rpmts.c: Creation of Pubkey packages. * rpmvs.c: sinfo->keyidMust die! * rpmpgp.c pgpIdentItem() formats Public Keys or Signatures * Used short KeyID (see #3292) * Public API in rpmpgp.h * used in rpmvs.c -> rpmsinfoMsg() used 5 time through out the code base ### Pubkey Packages * gpg-pubkey packages are created on key import. * Short KeyID as Version and Creation time as release * Same as Provides EVR with key version as Epoch * Long KeyID as gpg(xxx) Provides * No Fingerprints in sight. * All just package tags - no runtime check. ### Sub Keys Support for subkeys seems very rudimentary. * No way to list installed subkeys. * No way to connect sub keys to gpg-pubkey packages * pgpPubkeyFingerprint() only works on raw key data and returns the Fingerprint of the primary key ### ToDo Possible sub projects in no particular order: * API: Add variant of pgpPubkeyFingerprint() that works for sub keys, too. * API: Add function to get fingerprint of v4 PGP signatures * Get rid of lib/package.c stashKeyid() and rpmsinfo_s.keyid * Offer a way to get information on the actually installed keys e.g. * Fingerprint format for pubkeys tag to get actual Fingerprint of installed key(s) * PGP key format that gives rpm -qi like output of the actual keys * Add --list to rpmkeys utility * Support multiple entries per KeyId in keyring * Print Fingerprint for Pubkeys in rpmsinfoMsg() * Check if EVR and Provides match stored key in loadKeyringFromDB * Store fingerprint with check result of signature and print it out Most of them deserve their own ticket once decided on. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2403#issuecomment-2354835502 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] brp-remove-la-files won't remove symlink files (Issue #3304)
Looking at the code and the history it looks like it always just matched against regular files. We probably could add another run that matches symlinks only before deleting the regular files. That way we can check the files being linked to to be proper libtool library files. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3304#issuecomment-2355366129 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] brp-remove-la-files: Remove symlinks, too (PR #3311)
As we check for file contents delete symlink before looking at regular files. Resolves: #3304 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3311 -- Commit Summary -- * brp-remove-la-files: Remove symlinks, too -- File Changes -- M scripts/brp-remove-la-files (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3311.patch https://github.com/rpm-software-management/rpm/pull/3311.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3311 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] brp-remove-la-files won't remove symlink files (Issue #3304)
Can you please test if the PR linked above fixes your issue? Thanks! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3304#issuecomment-2355385569 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] brp-remove-la-files: Remove symlinks, too (PR #3311)
@ffesti pushed 1 commit. 8fc4e71f9b51438f09c8206ceb1b407bbaca8aab brp-remove-la-files: Remove symlinks, too -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3311/files/7fd4312b5f811152f302406b0a0275edb12a9108..8fc4e71f9b51438f09c8206ceb1b407bbaca8aab You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Popt aliases for queries are only visible in rpm --help (#1196)
They should also be in some man page. Some probably with a bit longer explanation than the popt help text. -- 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/1196___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] scripts/pythondistdeps: New test suite and various updates and fixes (#1195)
Having a separate repo here is actually not a compromise but IMHO the preferred option. rpm-extras was thought more as an interim solution for scripts that don't have a large enough contributor base to be projects on their own. Even better if people from multiple distributions can share the ownership of the repo. -- 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/1195#issuecomment-619862405___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] RPM 4.14.3 released!
RPM 4.14.3 final is out. The release has two more fixes added that silence the error messages on systems not supporting selinux. Full details and download info at: https://rpm.org/wiki/Releases/4.14.3 On behalf of the rpm-team, Florian On 3/26/20 11:34 AM, Panu Matilainen wrote: > Usually rpm branches releases only get a couple of update releases, but > then it's the exceptions that prove the rule - here comes RPM 4.14.3 > release candidate 1! > > Highlights include: > - Backported support for caret version > - Numerous bugfixes across the board > - Clarify RPM license > > Full details and download info at: > > https://rpm.org/wiki/Releases/4.14.3 > > There are so many changes here that a RC seemed necessary. So please try > to test it in the environments that are still on 4.14, our normal > test-bed of Fedora (oops, did I just say that on the internet?) is all > on >= 4.15 by now. > > I should also mention that this release was prepared by Florian who in > the best release-and-run tradition went on PTO and left me to send the > announcement and getting the blame. Haha. > > On behalf of the rpm-team, > > - Panu - > > ___ > Rpm-maint mailing list > Rpm-maint@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-maint > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas Savage ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Convenient version comparison macro (#1217)
Another option would be having special operators. But this is also confusion as
we use the normal `<`, `>`, ... in dependencies. I also don't have a good
suggestion. `%if %{php_version} ver>= "1.2.3"` looks weird, too. But may be
someone has an better idea.
--
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/1217#issuecomment-628530128___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Automatic (sub)package generators (#329)
Looking at this there are a couple of separate issues. I wonder if the reason this has not been getting anywhere has been that we try to solve all these different things at once. May be we should split this into separate features and just start with one - solving only a few - but at least a few - real world cases. The current font and go macros are a pain to implement but - obviously - don't require something that can't be done. But they rely on all the actual data being punched into the spec file by the user. As long as we still want to do that this is basically a question of improving the macro language or offering a nicer template language. One improvement would be to allow multiple sections for the build scripts. That way things would not need to be distributed all over the spec file but macros could create everything they need in one place. This ofc needs some way of ordering the sections - probably with a priority similar to file triggers. Using data from the buildroot is currently not possible at all - with the exception of globs in file lists and dependency generators. To work around this we need to be able to create (sub) packages after the build. I contemplated template packages that get their attributes expanded after the build but I think this is too restrictive and too complicated to implement. I guess the easiest way to provide this is a spec file section that is not evaluated at parse time but is parsed after the build. We might want to disallow some things there but it will basically allow declaring sub packages. These could also be created by macros or by scripts processing the build root. Generating sub packages raises the question of how they interact with other packages in the spec. One way regarding files is below. If looked at more general this is a complicated issue. Do we want to make the already parsed packages available in the spec file or in lua? And even if we do should we offer a way to alter them? For now I would probably postpone these requirements and concentrate on the easier use cases. But this is something that's necessary to be able to implement the debuginfo packages and it might not even be enough... Then there is the question of making the package declarations smarter. Right now the file attributes and generated dependencies are calculated late - after the files have already been distributed to the packages. This can be changed but requires quite some re-factoring. After that one could use file attributes in %files. At the same time we could add priorities which allow "stealing" files from other packages. For me this looks very interesting but probably a second - or third - step. I guess the trick is to choose one or two of those and just implement them and see where this leads us. -- 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/329#issuecomment-629159129___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: Add spec section that is parsed after %install (#1222)
-- 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/1222___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: Allow multiple snippets of the same build script (#1223)
-- 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/1223___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: Make file attributes availble in %files (#1224)
File attributes are a powerful way of dealing with files. Unfortunately the file classification is not available in %files. As they emerged from the dependency generator code they are only executed after the %file lists are turned into real files. While dependency generator probably need to stay after the finalization of the file lists the classification could be run earlier. This requires a new data structure holding all files in the install root, instead of working with packages and their file lists. -- 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/1224___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: Make packages available in the spec file (#1225)
Right now there is no way to acess previously declared packages and their attributes from within the spec file. Automatic package generation may need to know what packages are there already to take them into account. Note: This does not (yet) include a way to actually alter those packages. -- 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/1225___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] REF: Have priorities for file patterns (#1226)
To give automatic sub packages more leeway to deal with files there needs to be a way to "steal" files from other packages, so files can end up in different packages depending on which sub package actually get created. For those cases it is not desired to have the files in more than one package. Adding a priority attribute to the entries in %files allows moving the file to the package with the highest priority while making sure it ends up some where. -- 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/1226___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Check date/time for consistently using unsigned ints (#1228)
Signed 32 bit integers run out of space 2038 for unix time. As RPM uses unsigned ints for all tags that should not be a problem.We still need to check that there are no signed 32 bit ints used anywhere near date and time handling -- 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/1228___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Move all time related APIs to 64 bit (#1229)
As signed 32 bit unix time is running out 2038 we should move all APIs dealing with time to 64 bit. At some point we also need to add new 64 bit tags - either in addition or by breaking compatibility and moving to 64 bit integer tags in general. -- 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/1229___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Investgate all brp scripts if they are worth parallelizing (#1230)
Several scripts have already received attention this way. LEt's make sure we didn't missed anything worth optimizing. -- 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/1230___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Check date/time for consistently using unsigned ints (#1228)
Also check the cpio payload format for issues. -- 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/1228#issuecomment-630636191___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Size check is too strict (#1232)
Well, normally rpm saves the new file to disk first and then moves it over the old file. So it actually does need this space. The latest version has some optimization for SSDs where files that are unchanged are only checksummed. This may be why you don't see an error message here. -- 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/1232#issuecomment-630793756___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add %postbuild section / Allow dynamic sub packages (#1239)
This is a POC for the new dynamic sub package feature. It add a %postbuild (better names welcome) section that is not expanded during regular Spec parsing. It is fed to the spec parser after the build scripts have run. This allows to create sub packages based on the content of the buildroot. There are still areas that require improvement: The line numbers and filename for the section should probably look more like we are parsing the spec file itself. You currently cannot put the main package / initial preamble into the %postbuild section. This requires rethinking what kind of processing is done during (initial) build and how this affects other users of rpmSpecParse. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1239 -- Commit Summary -- * Add pushStrOFI() to parseSpec * Allow reading lines of spec file raw * Allow using PART_EMPTY as the beginning of a parse pass * Add suppport for %postbuild spec section -- File Changes -- M build/build.c (3) M build/parseSpec.c (238) M build/rpmbuild_internal.h (7) M build/spec.c (3) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1239.patch https://github.com/rpm-software-management/rpm/pull/1239.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/1239 ___ 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 %postbuild section / Allow dynamic sub packages (#1239)
@ffesti commented on this pull request. > @@ -451,6 +453,7 @@ const char * rpmSpecGetSection(rpmSpec spec, int section) case RPMBUILD_BUILD:return getStringBuf(spec->build); case RPMBUILD_INSTALL: return getStringBuf(spec->install); case RPMBUILD_CHECK:return getStringBuf(spec->check); + //case RPMBUILD_POSTBUILD: return getStringBuf(spec->postbuild); left there as a reminder that RPMBUILD_POSTBUILD is still missing as a constant. -- 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/1239#discussion_r429877766___ 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 %postbuild section / Allow dynamic sub packages (#1239)
> I'd rather see this pushed to an external file entirely. That would > > * drive the intended usage home with a sledgehammer > > * make it easier to generate spec fragments from %build > > * simplify the parsing as you don't need to try not to parse a thing when > you're parsing that thing > > * be just as easy for complicated macro ecosystems > > > External files could maybe presented as spec tags (instead of sections) > resembling SOURCE, and thus allowing multiple files. Come to think of it, > you'd actually want to ship the generated spec fragments in an src.rpm for > reproducability / inspectability (this part will require some serious > thinking regardless of syntax details). So how about something like > > ``` > SpecN: > ``` > > ...where N > 0 because the spec itself is always 0. And these are then parsed > after the build phase, post %install more like it. The tag name should > probably indicate this somehow, but no ideas for that atm. I am not 100% sure why this rubs me the wrong way. It just doesn't feel right. A few thoughts and observations: It is hard to generate spec file fragments from within the spec. Just doing `echo > file
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: save the parsed spec in src.rpm (#1241)
rpmSpecGetSection() returns it when passed RPMBUILD_NONE. Guess adding this to the API is what you remember even if it has been a while: ` c38504c4ba build/rpmspec.h (Panu Matilainen 2011-06-17 13:44:39 +0300 78) * As a special case, RPMBUILD_NONE as section returns the entire spec in c38504c4ba build/rpmspec.h (Panu Matilainen 2011-06-17 13:44:39 +0300 79) * preprocessed (macros expanded etc) format. ` -- 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/1241#issuecomment-633919663___ 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 a version parsing and comparison API to librpmio (#1221)
Removing the nopromote API in Python but keeping it in C seems inconsistent. Not sure if I really care. -- 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/1221#issuecomment-634555607___ 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 a version parsing and comparison API to librpmio (#1221)
Overall this looks good. I am wondering what all the malloc and free costs us as we might do a few version comparisons during a transaction. Probably not enough to actually worry. Converting the EVR of the rpmds object just for comparison seems kinda weird. I am fine with this as a first step but we should consider moving the rpmds to use versions from the start. Which asks the question how this relates to rpmsid... That's not something we want to get into right now but we might want to think about in the 4.17 time frame. For now it is great we have something like this at all. -- 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/1221#issuecomment-634563090___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Support rpm version comparison in expressions (#1233)
This looks good (only looking at the last three - parser related - patches). -- 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/1233#issuecomment-634570810___ 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 an API + bindings for parsing EVR (#561)
Closed #561 via #1221. -- 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/561#event-3377826209___ 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 a version parsing and comparison API to librpmio (#1221)
Merged #1221 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/1221#event-3377826189___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Add an labelCompare() equivalent to Lua interface (#897)
Closed #897 via a1d2722c4a88a49008daa58653c9c5ebf9344d63. -- 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/897#event-3377826327___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Support rpm version comparison in expressions (#1233)
Merged #1233 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/1233#event-3377935097___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Convenient version comparison macro (#1217)
Closed #1217 via #1233. -- 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/1217#event-3377935109___ 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 %postbuild section / Allow dynamic sub packages (#1239)
@ffesti pushed 1 commit. 9b1a24a921f281747eb475276a3693471ee2b0b1 Add suppport for %postbuild spec section -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/1239/files/23077b960b01e952ea6acc6596ad4b66bfbe534a..9b1a24a921f281747eb475276a3693471ee2b0b1 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Bump CI Fedora version from 31 to 32 aka latest stable (#1243)
Merged #1243 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/1243#event-3381787330___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Preparing for rpm 4.16.0-beta1 (#1244)
Merged #1244 into rpm-4.16.x. -- 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/1244#event-3382355093___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] ts.addErase(tsi.pkg.idx) skips already erased items (#1214)
Just to add this here, too: ts.addErase returns an error code. False aka 0 is the erase element could be added and True aka 1 of it can't. DNF is ignoring this. So the transaction element is not disappearing - it is not created in the first place. I can't really see where RPM is at fault here. Closing. -- 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/1214#issuecomment-637379312___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] ts.addErase(tsi.pkg.idx) skips already erased items (#1214)
Closed #1214. -- 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/1214#event-3396480725___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] ts.addErase(tsi.pkg.idx) skips already erased items (#1214)
Yes, there may be more holes. But here all these additional checks won't catch anything unless DNF checks the return value of addErase. As RPM just doesn't add the transaction element at all there is nothing to check later. One could argue that rpm should just destroy the transaction but I'd argue an API use may actually want to ignore the error message and be content with the package no longer being there. -- 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/1214#issuecomment-637415093___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] ts.addErase(tsi.pkg.idx) skips already erased items (#1214)
As the change here is between the libsolv transaction and the creation of the rpm transaction checking for changes in the database can't really solve the problems if done within rpm only. DNF could check the database after obtaining the ts lock, but that's something we allow already - it's just not done. -- 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/1214#issuecomment-637416621___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Notify other programs when the rpmdb is changed via DBus (#1249)
See https://bugzilla.redhat.com/show_bug.cgi?id=1816123 for initial request. Using DBus would allow pushing even more information like what packages got installed/removed etc. This will be based on DBus signals as we (obviously) won't turn RPM into a daemon. During the transaction signals are going out onto the system bus but there will be no way to call into the RPM process or to query the rpmdb via 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/issues/1249___ 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 pre-flight check for erased packages too (#1250)
Merged #1250 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/1250#event-3397654265___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't auto-enable IO flushing on non-rotational disks (#1253)
This patch should also change the comment in macros.in as -1 no longer means auto detection. Otherwise this is obviously fine. -- 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/1253#issuecomment-638046886___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't auto-enable IO flushing on non-rotational disks (#1253)
Merged #1253 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/1253#event-3401230871___ 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 python ts.addErase() not raising exception on not-found packages (#1251)
Still not quite sure what the right behaviour is here. Raising the exception when passing in an non existing header number is all fine. It may also be fine for a name/label that is not found in the rpmdb. Where things get murky is when passing in an empty match iterator. I could imagine some code may rely on this just working and doing nothing. -- 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/1251#issuecomment-638149568___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Notify other programs when the rpmdb is changed via DBus (#1249)
Question here is what to actually send over the bus. For the initial use case just announcing the end of a transaction is enough. This allows long running processes to clue in on other tools changing the rpmdb. But there is obviously more that could be done: Announcing the start of a transaction may be used to signal in the UI that the rpmdb is currently blocked and the user has to wait before doing any transactions themselves. We could also send over the content of the transaction (may be as operation, NEVRA, hash, id tuples) or send each package that just finished. Otoh this may be seen as an invitation to do something like triggers outside of rpm. -- 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/1249#issuecomment-638158114___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Psmpre and psmpost plugin callbacks executed multiple times per package (#1254)
As psmpre and psmpost callbacks are basically used to report on the installed/removed packages one would think each of them is called exactly once per package. Unfortunately rpmpsmRun - which triggers them - is also called for other occasions like executing %posttrans and %verify scriptlets and checking the transaction. This is made worse by the callbacks neither providing the goal passed to rpmpsmRun nor an rpmts instance. -- 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/1254___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)
The plugin announces start and completion of transactions and the installation and erasure of packages. The patch still needs some polishing: * Names of the DBus enities may need a second thought * Man page is still missing a description of the dbus signal sent * DBus config is not properly integrated into Makefile Resolves: #1249 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1255 -- Commit Summary -- * Add dbus-announce plugin -- File Changes -- M doc/Makefile.am (5) A doc/rpm-plugin-dbus-announce.8 (25) M macros.in (1) M plugins/Makefile.am (5) A plugins/dbus_announce.c (198) A plugins/org.rpm.conf (10) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1255.patch https://github.com/rpm-software-management/rpm/pull/1255.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/1255 ___ 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)
Yeah, I had the package info as a separate patch, but I figured it'd be easier to just delete the functions than splitting all the changes and fixes. Otoh I could imaging some GUI tool to not blocking it's UI completely on an running transaction but instead just changing package by package. -- 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-638790678___ 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 python ts.addErase() not raising exception on not-found packages (#1251)
Merged #1251 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/1251#event-3406472496___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Notify other programs when the rpmdb is changed via DBus (#1249)
Well, DBus is not the same as DBus. There are two things you can do there: This thing here is just sending signals. They go to the bus and are then relayed to everyone subscribing to them. I don't know that much about DBus but I would hope sending a few thousands signals shouldn't hurt anyone. By design there is no way for 3rd party processes to talk back to rpm. They either listen or they don't. This also means we need to send everything we think anyone might need. Offering an RPM interface on DBus is a very different thing. This either needs some daemon or some bus-activated service - which is basically also a daemon. This allows users to basically do remote procedure calls to this daemon and get data back as a result. The DBus actually supports a tree like structure for making objects available and has some build in introspection interface. If we really want to add something like this we should probably talk to the DNF folks who are working on a daemon on their own. -- 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/1249#issuecomment-638800378___ 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)
Split the package signals into a separate patch as they need some deeper discussion on how the plugin hooks should actually work and what new we need to add (see #1254). -- 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-639431665___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add _without_check macro (#1256)
signaling and controling whether %check is executed during build. The macro can be set globally or in the spec file. The --nocheck parameter of rpmbuild takes precedence, though. If --nocheck is passed to rpmbuild the macro set accordingly. Otherwise it is set to 0 if not defined previously. Resolves: #316 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1256 -- Commit Summary -- * Add _without_check macro -- File Changes -- M build/build.c (1) M rpmbuild.c (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1256.patch https://github.com/rpm-software-management/rpm/pull/1256.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/1256 ___ 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)
May be the macro should be renamed to not collide with the with/without mechanism. The bcond mechnism assumes that the actual value is not set as a macro but only on the command line and is basically read only within the spec. If you set the macro itself having two of them can lead to the awkward situation where but are set to one or both are set to zero. So I would prefere to only have one macro. May be _nocheck is a better name and closer resembling the cli param. -- 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-640421215___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add way to set macro for --nocheck in rpmbuild (#316)
Did a PR for this on Friday. Comments on #1256 are welcome. -- 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/316#issuecomment-640425280___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add support for dependency generators for RPMTAG_ORDERNAME (#1262)
aka OrderWithRequires. Use __find_order in the attribute files Resolves: #1257 Please test! You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1262 -- Commit Summary -- * Add support for dependency generators for RPMTAG_ORDERNAME -- File Changes -- M build/rpmfc.c (9) M build/rpmfc.h (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1262.patch https://github.com/rpm-software-management/rpm/pull/1262.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/1262 ___ 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)
> Is there any coordination between this and the work to add dbus to libdnf in > [rpm-software-management/libdnf#941](https://github.com/rpm-software-management/libdnf/pull/941) > for example? 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. Note that this is very different from the lib dnf thing even if it also uses DBus. RPM will not offer a DBUS interface that can be queried or send commands to. All this does is sending out signals that notify who ever is interested that the rpmdb is changing. I will probably even drop the second patch providing more detailed information until there are real use cases. So all this is going to do is sending out a ping at the start and the end of every transaction. > For rpm-ostree we are already a DBus daemon, and having multiple other > libraries in the stack also going out and talking to DBus is going to be a > bit problematic. > Binding this to the systemd-inhibit plugin makes sense because we already > turn that off for rpm-ostree (because it's transactional, there's no reason > to inhibit). 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. Can you please elaborate on why sending some DBus signals should be problematic? -- 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-641112150___ 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)
Looks good to me. Should probably also go into 4.16. -- 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-641198193___ 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 support for dependency generators for RPMTAG_ORDERNAME (#1262)
Closed #1262. -- 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/1262#event-3424205732___ 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 support for dependency generators for RPMTAG_ORDERNAME (#1262)
*arg* I didn't even realize #1257 is a PR with a patch attached already. Please disregard. -- 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/1262#issuecomment-641199701___ 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 OrderWithRequires dependency generation (#1257)
Merged #1257 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/1257#event-3424224260___ 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 OrderWithRequires dependency generation (#1257)
Yes, not having a dependency generator for OrderWithRequires is clearly an oversight. Details on what generators are a valid use case are not relevant here. 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/1257#issuecomment-641202025___ 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 OrderWithRequires dependency generation (#1257)
This is indeed not possible. The argument here is (except that it is simply not implemented) that those dependencies are generated from files in the package and not the scriptlets. So qualifiers should not be needed. But I am pretty sure people could come up with some valid use cases. There is https://github.com/rpm-software-management/rpm/projects/11 There are quite a few things that I would like to see improved with dependency generators in the 4.17, 4.18 time frame. -- 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/1257#issuecomment-641227025___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix tag mixup in 32e2bc50cff9db05729349ff6645a0251d5719fb (#1263)
Hit merge just a little bit too quickly on this one... You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1263 -- Commit Summary -- * Fix tag mixup in 32e2bc50cff9db05729349ff6645a0251d5719fb -- File Changes -- M build/rpmfc.c (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1263.patch https://github.com/rpm-software-management/rpm/pull/1263.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/1263 ___ 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 OrderWithRequires dependency generation (32e2bc5)
*sigh* Fixed in #1263 -- 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/commit/32e2bc50cff9db05729349ff6645a0251d5719fb#commitcomment-39775202___ 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 OrderWithRequires dependency generation (32e2bc5)
Yes, sure. This is a dependency as all the others and does support the same features. The only difference is that OrderWithRequires is ignored during the dependency check and only used for ordering. -- 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/commit/32e2bc50cff9db05729349ff6645a0251d5719fb#commitcomment-39776284___ 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] %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] Testsuite cleanup (#1269)
Merged #1269 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/1269#event-3443606399___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Testsuite cleanup (#1269)
Wow! You now basically halved the time of the test suite takes. -- 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/1269#issuecomment-644031870___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Cleanup gpg-agent handling in test-suite (#1270)
Merged #1270 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/1270#event-3445622887___ 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 Translation subpackage(s) (#1276)
> What are the main benefits over `%lang(zh)` besides making the downloaded > binary RPM smaller? Is the increase in rpm-md repo metadata size worth it? Well, there is a trade off depending on the situation. But the more different languages are supported and the bigger the number of translated strings is the more it is worth packaging translation separately. Having this process automated we could even pick the right style of packaging depending on translation sizes. Or different distributions could choose their own policy. -- 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/1276#issuecomment-647543340___ 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 Translation subpackage(s) (#1276)
> FWIW in openSUSE many packages have a "-lang" subpackage to contain all > translations. Those packages in turn have automated provides that translate > into a locale namespace for libsolv, eg. `rpm -q --provides bash-lang`: > > ``` > locale(bash:es) > ``` The (compared the to locale name space) new boolean dependencies were designed to be able to also cover this use case. They are not quite as sleek but a more general solution. So yes, we are kinda copying the SuSE solution here. -- 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/1276#issuecomment-647546081___ 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
Re: [Rpm-maint] [rpm-software-management/rpm] Support threading for zstd compression. (#1303)
This change looks good and straight forward. I am missing some information on what version of zstd supports the new API - and if necessary a check in configure.ac. -- 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/1303#issuecomment-656683723___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] pythondistdeps.py: Adapt Python version marker workaround for setuptools 42+ (#1308)
Merged #1308 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/1308#event-3533973211___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] pythondistdeps.py: Adapt Python version marker workaround for setuptools 42+ (#1308)
Looks straight forward to me. -- 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/1308#issuecomment-656685900___ 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 Doxygen comments (#1302)
Merged #1302 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/1302#event-3533981732___ 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 Doxygen comments (#1302)
Thanks for the fix! -- 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/1302#issuecomment-656686843___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
