Re: [Rpm-maint] [rpm-software-management/rpm] Improved python support: enums are now enums with all additional goodies. (#1309)

2020-08-04 Thread Panu Matilainen
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)

2020-08-04 Thread KOLANICH
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)

2020-08-04 Thread Panu Matilainen
@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)

2020-08-04 Thread Panu Matilainen
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)

2020-08-04 Thread Panu Matilainen
@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)

2020-08-04 Thread Panu Matilainen
@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)

2020-08-04 Thread marxin
> 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)

2020-08-04 Thread Panu Matilainen
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)

2020-08-04 Thread Florian Festi
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)

2020-08-04 Thread Panu Matilainen
`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