Re: [Rpm-maint] [rpm-software-management/rpm] Improved python support: enums are now enums with all additional goodies. (#1309)
Eh, there's no swig involved, this is all hand-written C. -- 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/1309#issuecomment-668996401___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Improved python support: enums are now enums with all additional goodies. (#1309)
1. What clutters the namespace is the enums values generated by swig, because they are not really python enums and they are not namespaced. IDK if we can just break compatibility and get rid of them. The proposed solution is to setup swig to place them into a separate module (is it possible?), and then import that module and convert it, and not explicitly expose it. 2. in some places, where we don't directly interface the cext, we can, by just wrapping the returned values into the enum ctor -- 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/1309#issuecomment-668671569___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
@pmatilai commented on this pull request. > @@ -14,6 +14,7 @@ DISTCHECK_CONFIGURE_FLAGS = \ --with-audit \ --with-selinux \ --with-imaevm \ + --with-fsverity \ Sorry for the silence, I've been on a vacation. We need to get this past the CI to consider merging. I'd suggest taking this out of the initial autofoo commit, and instead add a new "Enable fsverity in CI" commit to the end of the series that adds this *and* fsverity-utils-devel to ci/Dockerfile along with the other build dependencies. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1203#pullrequestreview-460769176___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enable thread autodetection for a parallel compression. (#1324)
I think it should at least follow the same convention as XZ: T with no numbers mean autodetection (its okay if 0 means that too). This seems to silently change XZ behavior too which is not okay. We'll need some sort of resource manager (no matter how crude) in rpm sooner than later to handle this sort of stuff, but in the meanwhile I think a first step towards sanity could be axing the crazily complicated logic from XZ and simply limit threading to 64bit platforms. And with that, it should be possible to refactor this to use common logic for this and the XZ case. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1324#issuecomment-668558057___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Improved python support: enums are now enums with all additional goodies. (#1309)
@pmatilai requested changes on this pull request. NAK for cluttering the already cluttered rpm namespace with 100+ effective duplicate symbols under slightly different name, that will only confuse the living daylights of anybody trying to actually use this stuff instead of being helpful. If we can reasonably turn the actual RPMFOO* symbols into actual Python enums, that'd be fine. If we could actually return those from the places where we return bitfields from the API (lots of them), that'd be awesome. -- 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/1309#pullrequestreview-460718659___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Improved python support: enums are now enums with all additional goodies. (#1309)
@pmatilai commented on this pull request. > @@ -0,0 +1,74 @@ +from __future__ import absolute_import + +from . import _rpm + +__all__ = [] + +_enumClass = None +_flagEnumClass = None +try: + from enum import IntEnum as _enumClass +except ImportError: + try: + from enum import Enum as _enumClass + except ImportError: We don't support Python 2 at all, you can drop all this compat foobar. -- 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/1309#pullrequestreview-460715498___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enable thread autodetection for a parallel compression. (#1324)
> Right, this isn't any worse than what we already have for XZ, but then again > what is there for XZ is simply wrong in the face of concurrent package > generation as we have now. The lowly IO stream has no way of knowing how many > threads it can legitimately consume. That said, would it be possible to merge my pull request? I'm planning to experiment with `T0` when building `openSUSE:Factory`. Or do you see a way how to communicate the top-level parallelism to the compressing API? -- 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/1324#issuecomment-668488681___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Can not parse CHANGELOGTEXT from the specfile (#1301)
Ooh, that's a nice and elegant solution! -- 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/1301#issuecomment-668467332___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Can not parse CHANGELOGTEXT from the specfile (#1301)
Guess _changelog_trimtime should be counted from the newest entry to prevent the changelog depending on the build time. This still limits the changelog to the same length when building a new release but is stable over time and rebuilds. -- 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/1301#issuecomment-668448982___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Can not parse CHANGELOGTEXT from the specfile (#1301)
`rpmspec --undefine "_changelog_trimtime" -q --qf "[%{CHANGELOGTEXT}\n]" --specfile docpkg.spec` (or define _changelog_trimtime to %{nil}) for a more permanent workaround. Labeling this as bug though, this is not a sane behavior for changelog trimming. -- 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/1301#issuecomment-668433190___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint