On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
> > I'd like to get this package reviewed please:
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> > Would anyone like to swap reviews?
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
Time zone: Europe/London
Starting a new thread since the old one is hard to navigate at this point.
Modularity is a distribution-level change and requires some mindset
shift from packagers and users alike. I understand the concerns some
people have, feeling it’s something new and half-baked that is being
forced on them.
We’re an open source community and in order to drive innovation, we
need to be able to try new approaches and technologies in the open,
not develop them without any input and hands-on experience behind
closed doors, later serving them on a silver plate. The feedback we’re
getting is extremely valuable, but some of it is too narrowly focused
on one specific problem area and not taking into account the other
aspects, requirements, or goals that we’re pursuing. Our objective is
still to deliver multiple versions, or variants, of our content across
releases or even distributions (think EPEL or CentOS). And it’s a good
The concept of default streams was introduced to make modularity
invisible to anyone who has no interest in alternatives and wants the
system to operate as it historically has. Whether a specific package
is delivered via a module or not shouldn’t matter. (This does not mean
it should be hidden, just that it should have no practical difference
to the system.) This applies to both buildroots and runtime, leaving
the choice of whether to modularize or not to the maintainer.
Obviously, the implementation is falling short in this regard right
now, but we have solutions in development or under design. This
includes making the default streams available in the non-modular
buildroot via Ursa Prime or tracking the module enablement intent in
our software management stack, as Stephen suggested in the original
While these issues are being resolved, we are considering temporarily
disallowing default streams in Fedora. I don’t want to abandon the
idea completely, as doing so reduces the motivation to actually build
modules and reap the benefits they might provide.
Yes, modularity still has some additional development ahead. We need
to improve the software management stack experience; we need to
revisit our release engineering SOPs; we need to stabilize and boost
performance of our infrastructure; and last but not least, we need to
improve the packager experience, providing more features to make the
creation of modules easier, as well as guidance, best practices and
policies that make it easy to collaborate. These changes are similar
to those for other useful but disruptive technologies that Fedora has
successfully introduced in the past.
I do believe we all intend the best, even if we sometimes disagree. We
currently don’t have any other proposal that would fulfill the vision
of our Objective and the needs of our users. The input here helps us
re-focus on the most acute pain points but the manpower and control we
have is also rather limited. If you want to and can help with the
implementation, I’d like to encourage you to do so.
Hello fellow Python packagers. This is an announcement about a new set of RPM
macros you can use to build PEP 517/518 enabled packages, that is Python
packages that have the pyproject.toml file.
The set of macros is designed for modern packaging with dynamic buildrequires in
The macros are in the pyproject-rpm-macros package and you can use them like this:
See the full documentation of the macros:
See example spec files:
(These use setuptools (setup.py), flit and poetry for build backends, but you
cannot tell that from the specfiles - BuildRequires are generated dynamically
from upstream metadata.)
The macros are **provisional**, i.e. their API may be changed upon feedback
received from you.
We are not (yet) interested in a general "update all the Python packages" hunt,
but rather in early adopters.
If you have questions, ask here. We'll gladly extend the docs if something is
If you find bugs, report them in bugzilla or here. Likewise for RFEs.
It's become clear that I haven't had the time I thought I'd have this past
year due to $life ...
These are in a bit of a broken state and right now I'd advise people that
need them to use upstream packages/containers.
I don't foresee sufficient time coming in the near future with family needs
in advance of hobbies like Fedora of course.
I'll give it a week or so for anyone to contact me who wants to pick them
up, otherwise I'll update pagure to assign them to "orphan"
I'm hoping that this one hasn't been dead for 8 weeks, because all it needs
to get it building again is to disable the gtk-doc generation...
I don't really want to own it, but I have dependent packages, so if no one
else does, I will claim it.
If you want it (or know of some reason it shouldn't be brought back),
please speak up.
Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.
1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Selected streams should not
be changed without direct action from the user.
2. So far as possible, Modularity should be invisible to those who
don't specifically need it. This means being able to set default
streams so that `yum install package` works for module-provided
Where this becomes an issue is at system-upgrade time (moving from
Fedora 30->31 or continuously tracking Rawhide). Because of
requirement 1, we cannot automatically move users between streams, but
in the case of release upgrades we often want to move to a new default
for the distribution.
The Modularity WG has generally agreed that we want and need to
support behavior of the following use-cases:
Use Case 1:
On Fedora 30, user Alice runs
yum install Foo
The package "Foo" is provided by a module "foo" with a default stream
"v1.0". Because it's available in a default stream, the package is
installed and the module stream "foo:v1.0" is implicitly enabled for
Fedora 31 is released. On Fedora 31, the module "foo" has a new
default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
Alice expects the package Foo she installed to be upgraded to version
1.1, because that's what would have happened if it was provided as a
package from the non-modular repositories.
Use Case 2:
On Fedora 30, user Bob runs
yum enable foo:v1.0
In this case, the "v1.0" stream of the "foo" module has a dependency
on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
the system also implicitly enables "bar:v2.4".
Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
about "foo:v1.0" would expect the upgrade to complete, adjusting the
dependencies as needed.
At Flock and other discussions, we've generally come up with a
solution, but it's not yet recorded anywhere. I'm sending it out for
wider input, but this is more or less the solution we intend to run
with, barring someone finding a severe flaw.
What happens today is that once the stream is set, it is fixed and
unchangeable except by user decision. Through discussions with UX
folks, we've more or less come to the decision that the correct
behavior is as follows:
* The user's "intention" should be recorded at the time of module
enablement. Currently, module streams can exist in four states:
"available, enabled, disabled, default". We propose that there should
be two additional states (names TBD) representing implicit enablement.
The state "enabled" would be reserved for any stream that at some
point was enabled by name. For example, a user who runs `yum install
freeipa:DL1` is making a conscious choice to install the DL1 stream of
freeipa. A user who runs `yum install freeipa-client` is instead
saying "give me whatever freeipa-client is the default".
* The state `dep_enabled` would be set whenever a stream becomes
enabled because some other module stream depended on it. This state
must be entered only if the previous state was `default` or
`available`. (We don't want `enabled` or `disabled` streams being able
to transition to this state.)
* The state `default_enabled` would be set whenever a stream becomes
enabled because a transaction pulled in a package from a default
stream, causing it to be enabled. This state must only be entered if
the previous state was `default` or `dep_enabled`. We don't want
`enabled` or `disabled` to be able to transition to `default_enabled`.
If a user requests installation of a package provided by a stream
currently in the `dep_enabled` state, that stream should transition to
the `default_enabled` state (meaning that now the user would expect it
to be treated the same as any other default-enabled stream).
* When running `dnf update`, if a module stream's dependency on
another module changes to another stream, the transaction should cause
that new stream to be enabled (replacing the current stream) if it is
in the `dep_enabled` state.
When running `dnf update` or `dnf system-upgrade`, if the default
stream for a module installed on the system changes and the module's
current state is `default_enabled`, then the transaction should cause
the new default stream to be enabled.
* If stream switching during an update or upgrade would result in
other module dependency issues, that MUST be reported and returned to
This requires some constraints to be placed on default and dependency changes:
* Any stream upgrade such as this must guarantee that any artifacts of
the stream that is exposed as "API" MUST support RPM-level package
upgrades from any previous stream in this stable release. (Example:
"freeipa:DL"1 depends on a the "pki-core:3.8" stream at Fedora 30
launch. Later updates move this to depending on "pki-core:3.9" and
even later "pki-core:3.10". In this case the packages from
"pki-core:3.10" must have a safe upgrade path from both "pki-core:3.8"
and "pki-core:3.9" since we cannot guarantee or force our users to
update regularly and they might miss some of the intermediate ones.
I would like to introduce a plan I call Square 1 
There are two goals to Square 1.
The first is to get, and keep, the core buildroot packages, self-hosting.
The second is to get the list of core buildroot packages as small as possible.
What are the benefits to Square 1?
More stable release and less failed builds.
If we are able to shrink binaries, faster koji builds.
Smoother initial creation of RHEL 9.
What are the milestones to get these benefits?
- Get initial list of "core binaries"
- write/find software that will find binary/source dependencies
- write/find software that will track binary/source dependencies
- write/find/setup automation that finds and tracks binary/source
dependencies, so people can easily see what has changed over time.
- work with package maintainers to trim down binary/source dependencies
-- trimming out "extra" package languages. (ex: perl for a
minor script, when everything is in python.)
-- trimming functionality and/or moving functionality to sub-packages
or separate package.
- integrate these tests into the rawhide gating system, to alert when
new dependencies have been added.
Much of this work overlaps with the Fedora Minimization efforts.
Square 1 hopes to utilize, rather than duplicate, their efforts. And
maybe some tools created for Square 1 can help the minimization
 - Square 1 is at the heart of Ring Zero
 - This has nothing to do with the company or software with a
similar sounding name.
 - The core buildroot is the packages in @buildsys-build, and
everything needed to build those packages.
 - self-hosting is the ability to build all the packages on themselves.
 - Yep, I said it. We're already looking at RHEL 9.
 - https://docs.fedoraproject.org/en-US/minimization/
Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
2.0.0 to libdav1d.so.3.0.0.
I will be updating it next week on F31/32, consumers of these libraries
(ffmpeg, xine-lib, vlc) will need to rebuild their packages.
we have decided that it is a time to go through Copr backend data and
clean it up a little. Due to several bugs forgetting to remove backend
data after removing their records from the database, _temporarily_
backing up some folder here and there, etc, we ended up with a lot of
unknown data, that should have been already deleted.
So, we wrote a script  to find data that should be deleted, and we
... haven't deleted it yet. Instead, we put it aside in a case there
were any false-positives by the script. If you want to be extra safe,
I am attaching a list of all of those files, you may check it.
If you find out, that we accidentally want to remove any of your data
that is still being used, please contact us immediately! Otherwise, we
are going to delete it once we are running out of disk space (which
may not take a lot of time)
Thank you for understanding,