Hi,
I build Vim (bleeding-edge package, updated within a day of the latest
upstream release) for Fedora Rawhide, among many other platforms,
using the openSUSE Build Service and the delightful issue I've found
is that python3-devel cannot be installed by the OBS due to a conflict
between python3-rpm-generators and python-rpm-macros. If you suggest I
should ask the OBS developers for help on this don't bother because
I've asked them and they've told me this is an upstream issue you
folks need to fix. This issue has existed for over a week now, so it'd
be delightful if it could be fixed.
Thanks for your time and patience,
Brenton

Suppose I am main admin of a package which I would like to orphan in
release branches, but keep maintaining the package in arbitrary [1]
branches, which are used for building modules. Would this considered
as a valid approach?
How should I handle orphaning the package in this case? I can think
of at least two possibilities:
1. Keep myself as admin and set bugzilla_contact for product Fedora to
orphan.
2. Set orphan as main admin and demote myself to just admin.
In case no one adopts orphaned package and it is retired by Release
Engineering, should commiters be still able to commit to non-retired
arbitrary branches? I assume yes, but I'd rather ask in advance.
[1] https://fedoraproject.org/wiki/Changes/ArbitraryBranching
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk

Consider a library like libGL. At runtime, you want the drivers it
might load to be installed. But when building an application, you just
need the library itself. If the drivers themselves have non-trivial
dependencies, the buildroot is more likely to fail to compose.
The problem, in a sense, is that the devel package requires the package
providing the API library, _and_ said required package requires the
drivers. What if instead you had (in pseudo-spec):
%package devel
Requires: %{name}-sdk
%package sdk
%package libs
Requires: foo-drivers
where -libs and -sdk have identical %files, but -sdk has automatic
provides for library sonames turned off (so it never satisfies a
runtime dependency). This would duplicate some content on the mirrors,
but not the installed system, and it would let you compose a buildroot
with only the API surface you link against.
---
Is this all dodging the issue that nothing agrees what Recommends:
means? And that nobody's compose tools or comps files really understand
what drivers they want, and that propagating that information is an
unbounded task? Well, yeah, a bit. I still think it'd solve a real
problem, I'm just wondering if the idea is too ugly to consider.
- ajax

Is python-pycrypto a package? If not, I'm starting to think it should
be. I'm seeing it show up as requirements for some python projects I'd
like to work on.
Thoughts?
https://pypi.org/project/pycrypto/
Joseph D. Wagner