Non-responsive maintainer: rfenkhuber?
by Fabio Valentini
Hi everybody,
Following the policy for non-responsive package maintainers [0], I'm
asking here if anybody knows how to contact rfenkhuber. Roman, if
you're still interested in maintaining your packages, please respond.
Some of his packages are broken on fedora 31+ due to retired Java
dependencies, and others are getting pretty out of date (see the
linked Bug List in [1]), which is starting to impact some Stewardship
SIG packages as well.
The issues include
- F31(+)FTBFS: archaius, hystrix, memoryfilesystem
- Outdated: assertj-core, memoryfilesystem (possibly others as well)
Thanks,
Fabio
[0]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_packa...
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1770390
4 years, 5 months
CPE Weekly: 2019-11-08
by Aoife Moloney
Hi everyone,
Welcome to the CPE team weekly project update mail!
Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS. Our goal is to keep
core servers and services running and maintained, build releases, and
other strategic tasks that need more dedicated time than volunteers
can give.
For better communication, we will be giving weekly reports to the
CentOS and Fedora communities about the general tasks and work being
done.
For increased communication between our communities, we have created
#redhat-cpe on Freenode! Please feel free to catch us there, a mail
has landed on both the CentOS and Fedora devel lists with context
here.
Note:
This document is currently built from individual reports rolled into a
google document which we edit and copy into a final document. We are
aware that this causes problems with some email readers, and are
working on a method to make this less problematic.
High Level Project Updates:
Fedora:
Rawhide Gating:
We are working towards deployment of Bodhi 5.0 to production
Testing & Staging are both going fine
Synching with centos.ci.org
New ci-resultsdb-listener due in production this week
More work is going into docs for rawhide gating
repoSpanner
Discovered a new bottleneck that appears due to network latency that
wasn’t present in local testing.
We are also further analysing core dumps for unexplained hanging of the app
Tested pushing the Ansible repo to a local repospanner cluster to see
how it performed with new 83x patch. It pushed in 4 minutes. Network
bottleneck is prenventing real numbers.
We are also working on improving testing.
Additional developer docblocks landed
Application Retirements
Elections
Blocking issue was fixed (https://pagure.io/fedora-infrastructure/issue/8253)
Fedocal
jlanda hitting permission error in communishift
https://pagure.io/fedora-infrastructure/issue/8274
Nuancier
Benson Muite is now working on OIDC authentication
We are emailing him to check the progress and if he needs any help
Fpaste
Updated fpaste CLI appears to have landed in EPEL.
Writing a commblog about it
Sunset date: 1 December 2019
Badges
GDPR query under investigation
CentOS:
RHEL 8.1 announced Tuesday, team are busy tackling this
Workaround to help automatically restart repospanner
7.8 beta push has 3 packages left
Misc
Some of the team attended the OpenAlt conference in Brno. Watch out
for blogs about our experience!
The team are exploring smaller end of year initiatives, and we would
welcome any thoughts or feedback.
Comments? Suggestions? Feedback? Let Us Know!
Kind regards & have a great weekend!
Aoife
--
Aoife Moloney
Feature Driver
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
4 years, 5 months
EPEL-8 builds
by Peter Robinson
Hi,
I'd like to know why people are pushing EPEL-8 builds without engaging
with the maintainers of the packages. I've had a few packages where
I'm the only maintainer and I've explicitly not built them for EPEL-8
for reasons yet people are now coming without any engagement what so
ever and building them where they won't have to support the packages
no understand why the maintainer hasn't built them in the first place.
Peter
4 years, 5 months
The same RPM macro but different value for arch/noarch builds - how?
by Peter Lemenkov
Hello All,
We have a set of macros for Erlang libraries rpm building. Some of
these macros evaliated before actual build (if I understand RPM build
process correctly) and their actual value depends on a type of a
package - arch-dependent or noarch.
Previously we've used %{buildarch} macro to distinguish between
noarch-packages and arch-specific and that worked well enough.
Unfortunately this macro was removed recently.
Is there a way to pass "noarch" to some scripts from
/usr/lib/rpms/macros.d when building noarch package? Spec-file was
marked already as BuildArch: noarch. Where this information is stored
now?
--
With best regards, Peter Lemenkov.
4 years, 5 months
thunderbird-enigmail: how to claim ownership for F31 if package is
retired in rawhide?
by Felix Schwarz
Hey,
thunderbird-enigmail was retired in rawhide after being orphaned for more than
6 weeks. However F30+F31 still have the RPM but it does not work at all due to
Thunderbird changes.
I'm not interested in taking over the master branch but I'd like to ensure
that F31 ships working software. Which procedure should I follow to claim
ownership on the F31 branch?
(Obviously I'm not too keen on applying the whole un-retirement process which
involves a potentially very long package review.)
Felix
4 years, 5 months