On Thu, 3 Dec 2020, Michel Alexandre Salim wrote:
>> Apart from the usual package-not-available story (which I want to fix
>> as part of my work bringing up the EPEL Packagers SIG), my current
>> snag is that python-tox-current-env uses %generate_buildrequires which
>> does not work on CentOS 8:
>>
>> CentOS 8 is still on RPM 4.14:
>> <mock-chroot> sh-4.4# rpm -q rpm
>> rpm-4.14.2-37.el8.x86_64
>>
>> I'll put up a patch to hardcode dependencies for non-Fedora releases,
>> though that sorts of defeat the purpose of dynamic build
>> requirements.
>> Then again, this is only needed for EPEL8, since EPEL9 will have a
>> new enough RPM.
>>
> Given that %generate_buildrequires is the selling point of pyproject-
> rpm-macros, I'm guessing a better way forward for EPEL8 would be to not
> require it on EPEL8 since there's no way it would work, since RH won't
> update RPM?
>
> https://src.fedoraproject.org/rpms/pyproject-rpm-macros
Is %generate_buildrequires suppose to work for packages
which do not used python ?
From the name I would expect it to, but reading that doc makes me
think %generate_buildrequires *is* python specific.
If so, the name is misleading.
(I am also confused/suspicious of the point of a macro to automate
build requires, except as a step on a path to somewhere else.
If build requirements need to be stated explicitly,
then automating their statement is a good way of hiding an issue
that needs to be reviewed whenever changes are made.
)
--
Andrew C. Aitchison Kendal, UK
andrew(a)aitchison.me.uk
Folks -
Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6. From
the 8.2 beta:
Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs)
Name Stream Profiles Summary
python27 2.7 [d][e] common [d] Python programming
language, version 2.7
python36 3.6 [d][e] build, common [d] Python programming
language, version 3.6
python38 3.8 [d][e] build, common [d] Python programming
language, version 3.8
Currently, %python_pkgversion is set to 3 in
/usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros.
python3-devel is still provided only by python36-devel, so presumably all
EPEL8 python packages will continue to be built against python 3.6. But I
imagine that people will soon be asking for python 3.8 versions of EPEL
packages. How can we provide those? Does this have to be done in some
modular fashion - which seems to come back to the discussion of whether or not
every package has to become its own module or whether to group them together
somehow. Or since both python modules are "default" modules and we can
install both python36-devel and python38-devel at the same time, perhaps we
can define the python3_other* macros again for python38 and just go that way?
Thoughts?
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
Hi!
Two packages I built for EPEL 9 are now reported by koschei as having
missing build dependencies.
https://koschei.fedoraproject.org/package/davix?collection=epel9https://koschei.fedoraproject.org/package/uglify-js?collection=epel9
The EPEL 9 builds were built using the following build dependencies
according to the root.log files:
rapidjson-devel-1.1.0-19.el9
web-assets-devel-5-15.el9
nodejs-packaging-2021.01-5.el9
These can no longer be found in the koji buildroot. There are no
expired buildroot overrides for these builds, which could explain the
disappearance.
I can't find these builds in EPEL's koji, so I guess they where
provided by RHEL, but now are no longer? Did RHEL dop these?
Mattias
The following Fedora EPEL 7 Security updates need testing:
Age URL
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82b601cdc1 libofx-0.9.9-3.el7
The following builds have been pushed to Fedora EPEL 7 updates-testing
zstd-1.5.1-3.el7
Details about builds:
================================================================================
zstd-1.5.1-3.el7 (FEDORA-EPEL-2021-05645744d6)
Zstd compression library
--------------------------------------------------------------------------------
Update Information:
latest upstream (1.5.1)
--------------------------------------------------------------------------------
ChangeLog:
* Wed Dec 29 2021 P��draig Brady <P(a)draigBrady.com> - 1.5.1-3
- Avoid executable stack on i686 also.
* Tue Dec 28 2021 Zbigniew J��drzejewski-Szmek <zbyszek(a)in.waw.pl> - 1.5.1-2
- Disable amd64 assembly on non-intel architectures (#2035802):
this should avoid the issue where an executable stack is created.
* Wed Dec 22 2021 P��draig Brady <P(a)draigBrady.com> - 1.5.1-1
- Latest upstream
--------------------------------------------------------------------------------
The following Fedora EPEL 7 Security updates need testing:
Age URL
13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-afc31f929c seamonkey-2.53.10.1-1.el7
1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82b601cdc1 libofx-0.9.9-3.el7
The following builds have been pushed to Fedora EPEL 7 updates-testing
unrealircd-5.2.3-1.el7
Details about builds:
================================================================================
unrealircd-5.2.3-1.el7 (FEDORA-EPEL-2021-33a94b58ec)
Open Source IRC server
--------------------------------------------------------------------------------
Update Information:
# UnrealIRCd 5.2.3 This release contains a couple of small changes.
**Important: From upstream's perspective, UnrealIRCd 6 is the new "stable",
UnrealIRCd 5.2.x is now "oldstable".** ## Enhancements * Spanish example conf
was added (`conf/help/example.es.conf`) ## Fixes * `set::anti-flood::connect-
flood` was only expiring entries every 2 minutes. Only after a `REHASH` the
configuration file setting was used. * Memory leak in websocket module *
Send `WALLOPS` back to the sender too # Changes * Update `HELPOP` docs *
Add information on EOL date * Add `CONTRIBUTING.md` file with a reference to
docs on how people can help out.
--------------------------------------------------------------------------------
ChangeLog:
* Wed Dec 29 2021 Robert Scheck <robert(a)fedoraproject.org> 5.2.3-1
- Upgrade to 5.2.3
--------------------------------------------------------------------------------