Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Generators for license (#1073)
I have been wondering what else we might want to generate automatically (from the files). But looking through the tags I didn't find anything else (except may be %changelog). Just noting here in case anyone else wonders. -- 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/1073#issuecomment-588081623___ 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: Generators for license (#1073)
I would not expect such generators asking for more than 200-300 files. If that would help, we can force it to be passed at once, so that you don't have to initialize many things multiple times. -- 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/1073#issuecomment-588078866___ 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: Generators for license (#1073)
This would require to query the rpmdb during build. I wonder what the implications would be (except being pretty slow). I was worried about bootstrapping at first but I guess we can just ignore files not found in the rpmdb - or if there is no rpmdb found 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/issues/1073#issuecomment-588076987___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] update OCaml requires/provides to cover also cmx (#1070)
Will you guys please discuss and perform any separation of language support in a separate SR, please?! -- 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/1070#issuecomment-587927935___ 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 znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)
ffesti commented on this pull request. > @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char * > platform) } +# if defined(__linux__) && defined(__x86_64__) OK , there's a #if defined(__linux__) && defined(__i386__) branch just below with its own implementation of cpuid. -- 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/1035#discussion_r380715617___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] More fpLookupSubdir cleanups (#1071)
Good question, I've no idea. @ffesti? -- 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/1071#issuecomment-587491783___ 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 znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)
Conan-Kudo commented on this pull request. > @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char * > platform) } +# if defined(__linux__) && defined(__x86_64__) Wait nope, there's a `cpuid()` implementation for i386 right below... -- 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/1035#discussion_r380710615___ 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 znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)
ffesti commented on this pull request. > @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char * > platform) } +# if defined(__linux__) && defined(__x86_64__) Hmm, shouldn't the #if match up with the one around is_ryzen or be more 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/pull/1035#pullrequestreview-360385619___ 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 znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)
Conan-Kudo commented on this pull request. > @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char * > platform) } +# if defined(__linux__) && defined(__x86_64__) You're right, this was accidentally broken when I rebased it again... -- 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/1035#discussion_r380709287___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Use common error logic regardless of setexecfilecon() availability (#1079)
Refactor the custom exec context setting code to look like setexecfilecon() in case the real one is not available to eliminate pesky behavioral differences between the two cases. This fixes a concrete bug of libselinux setexecfilecon() returning with an error when security_getenforce() returns with -1 (such as a bare chroot with no /sys mounts etc), causing us to spit out useless error messages in that case ever since fixing the bogus if-logic in commit ab601b882b9d9d8248250111317615db1aa7b7c6. Fixes: #1077 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1079 -- Commit Summary -- * Use common error logic regardless of setexecfilecon() availability -- File Changes -- M plugins/selinux.c (46) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1079.patch https://github.com/rpm-software-management/rpm/pull/1079.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/1079 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] New setexecfilecon() errors on chroot installs (#1077)
Okay, the difference is rpm's own code doing: ``` if (rc && security_getenforce() < 1) rc = RPMRC_OK; ``` versus libselinux setexecfilecon() doing: ``` if (rc < 0 && security_getenforce() == 0) rc = 0; ``` When inside bare chroot with no /sys etc mounts, security_getenforce() fails. Rpm discards this, libselinux does 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/issues/1077#issuecomment-587447928___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] More fpLookupSubdir cleanups (#1071)
I didn't plan to push more commits, but now that you ask: Does it really make sense to have the symlinks of already installed packages in the `symlinks` hash? If a symlink is deleted on disk, the code will ignore it anyway (see the "Ignore already removed (by eg %pretrans) links" comment). If it's still on disk, the fingerprint lookup code will have found it and it will not be part of the "subDir" element. So what's the 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/1071#issuecomment-587448013___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] More fpLookupSubdir cleanups (#1071)
> I'm trying to make dir -> symlink-to-dir transactions work in the easy cases, > I think this will be fixed with the changes as well Wow. Good luck with that :grin: As for the slashes, I seem to recall looking at reducing them but something preventing that, perhaps some "hidden" dependency to rpmfi API / users expecting those slashes there and placing them back would've been impossible/hard. But it's a long time ago, things may have changed and my memory is really hazy on the details at best. BTW, are you expecting to push more commits to this particular PR or should we just merge 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/1071#issuecomment-587424452___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Auto-enable optimizations for non-rotational disks on Linux (#949)
Ok, looking at the history of flush_io and the potential to do more with it in the future I think just keeping both of those macros is the way to go. As auto detection for now is Linux only there is no perspective to get rid of these macros and just always "do the right thing(tm)" as people with not yet supported OSes will need to configure them manually. Wrt needing to overwrite two macros: This is less of an issue IMHO if both default to auto detection. Then one can view them as separate features that can be switched to a specified behaviour if the automatic default does not work properly. Yes, you may want to switch on both were auto detection is not working but this is still less messy than having three macros to deal with. Especially if some of them overrule others - which is kinda inevitable. -- 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/949#issuecomment-587362611___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use autodetect for _minimize_writes and _flush_io (#1066)
As most of these changes are incorporated into the original PR I am closing this one. -- 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/1066#issuecomment-587351563___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use autodetect for _minimize_writes and _flush_io (#1066)
Closed #1066. -- 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/1066#event-3046235283___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] First iteration of a 4.14.3 update release (#1078)
@ffesti one another thing which needs to be backported is definitely 15b296c324794d288750136b3b4f3350c3d0b8c7 -- 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/1078#issuecomment-587333931___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
