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:
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?),
@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 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
@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
@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
> 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
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___
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
`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
10 matches
Mail list logo
