Request to change default /etc/resolv.conf symlink
by Petr Menšík
Hello,
We reported issues with DNSSEC tools stopped working with resolved were
enabled shortly before f33 release. I admit I have not noticed soon
enough, because I haven't noticed how it behaves. We were promised a
quick fix back then. Since f33 systemd-resolved is installed by default
on Workstation and Server.
But the issue remains unchanged still in Fedora 37. Any attempt to use
DNSSEC without manual change just fails. You can try delv from
bind-utils, unbound-host -rD from unbound or drill -S
src.fedoraproject.org from ldns-utils. They all fail on default
installation. I have reported multiple bugs, which remains in NEW state
for years. I have reported also upstream issues, which are either
ignored or closed without proper fix.
It stop any my attempts at getting DNSSEC more popular and used. It is
clearly not high on systemd team priority list. For years. It has caused
regression without a proper fix.
I request to change default resolv.conf back to file generated by
Network Manager. We have resolve nss plugin listed in
/etc/nsswitch.conf, so it would still cache all name requests from
glibc. But it would not interfere with DNS specialized tools in a weird
way, like LLMNR [1]. I don't think systemd-resolved provides any other
record types than reverse mapping or addresses. All that can be safely
provided via resolve nss plugin, where it would not cause any
regressions. A minimal change would be using
/run/systemd/resolve/resolv.conf as a target of current /etc/resolv.conf
symlink.
If systemd-resolved ever becomes capable as a good DNS cache, we can
return it back to domain port. I don't think it is ready for that.
Opinions?
Regards,
Petr
1. https://github.com/systemd/systemd/issues/23494
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
1 year, 11 months
CPE Weekly Update – Week 23 2022
by Michal Konecny
Hi everyone,
This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).
Week: 6th - 10th 2022
If you wish to read this in form of a blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/cpe-weekly-update--week-23-2022/
# Highlights of the week
## Infrastructure & Release Engineering
Goal of this Initiative
-----------------------
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release (mirrors,
mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible
initiatives that CPE might take on.
Link to planning board: https://zlopez.fedorapeople.org/I&R-2022-06-08.pdf
Link to docs: https://docs.fedoraproject.org/en-US/infra/
Update
------
### Fedora Infra
* Staging instance of release-monitoring.org migrated to OCP4 (fixed
authentication issue)
* the-new-hotness 1.2.1 released and deployed on production
* Got a bunch of f34 machines reinstalled with f36.
* In the middle of upgrading the wiki (some plugins and theme currently
broken in staging)
* Image builder prod deployment in process, hit some snags with networks
* Map of critical services is now available in [Fedora Infra
docs](https://docs.fedoraproject.org/en-US/infra/map_critical_services/)
### CentOS Infra including CentOS CI
* Git.centos.org [scheduled
migration](https://lists.centos.org/pipermail/centos-devel/2022-June/1203...
(new RHEL8 hosts being prepared)
### Release Engineering
* Fedora 34 is EOL
* Perl side-tag merged into Fedora 37
## CentOS Stream
Goal of this Initiative
-----------------------
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.
Updates
-------
* Completed scripting for initial import of module RPMs and module-*
tags. Initial importing in progress to c9s koji from c8s koji..
* Working on automated scripting to pull new builds so that the c9s koji
can be automatically updated until we shift to the new koji builder for
c8s as well as c9s.
## CentOS Duffy CI
Goal of this Initiative
-----------------------
Duffy is a system within CentOS CI infrastructure allowing tenants to
provision and access machines (physical and/or virtual, of different
architectures and configurations) for the purposes of CI testing.
Development of Duffy is largely finished, we're currently planning and
testing deployment scenarios.
Updates
-------
* Release 3.0.1, 3.1.0, 3.2.0 (maybe shouldn’t have skipped betas 🤔).
* Add client (end user) CLI commands for requesting/retiring/etc. sessions.
* Add API endpoints and corresponding CLI commands for retrieving
information about configured node pools.
* Fix dependencies to have finer-granular installation options using
Python package extras (client CLI, task worker, current and legacy web
API servers).
## Package Automation (Packit Service)
Goal of this initiative
-----------------------
Automate RPM packaging of infra apps/packages
Updates
-------
* Working on adding packit to datagrepper and noggin
* Fasjson-client in bugzilla review
## Flask-oidc: oauth2client replacement
Goal of this initiative
-----------------------
Flask-oidc is a library used across the Fedora infrastructure and is the
client for ipsilon for its authentication. flask-oidc uses oauth2client.
This library is now deprecated and no longer maintained. This will need
to be replaced with authlib.
Updates:
--------
* We now have a very early barebones
[POC](https://app-flask-oidc-dev.apps.ocp.stg.fedoraproject.org/oidc/)
in place which makes use of authlib to authenticate over oidc with
Noggin/IPA.
* Working towards implementing the existing flask-oidc API to retrieve
user data.
## EPEL
Goal of this initiative
-----------------------
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special
Interest Group that creates, maintains, and manages a high quality set
of additional packages for Enterprise Linux, including, but not limited
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL),
Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will
never conflict with or replace packages in the base Enterprise Linux
distributions. EPEL uses much of the same infrastructure as Fedora,
including buildsystem, bugzilla instance, updates manager, mirror
manager and more.
Updates
-------
* This week we have 6018 (+155) packages, from 2730 (+58) source packages
* Unused marketing information and links were removed from EPEL docs
* Fedora's backported java_arches macro got merged into epel9
Kindest regards,
CPE Team
1 year, 11 months
Minizip pull requests
by Julian Sikorski
Hello,
I have created two PRs against minizip which are yet to be merged:
- https://src.fedoraproject.org/rpms/minizip/pull-request/3
- https://src.fedoraproject.org/rpms/minizip/pull-request/4
The first one should be a low risk one and should allow pkg-config using
dependencies like (shameless self-interest plug) to build against system
minizip again.
The second one needs support from a provenpackager. I tried rebuilding
the 18 dependencies of minizip and this is a bit tricky for two reasons:
- libsmbl and libspatialite need to be rebuilt before the other dependencies
- I cannot figure out how to get fedpkg srpm to work with libspatialite,
I am getting a Package already exists: %package debuginfo error from the
%{?mingw_debug_package} line. I am sure this is something someone
familiar with mingw can fix in a shortest amount of time.
Other than that, I can confirm that 13 dependencies can be rebuilt with
no changes. How can we move this forward?
Best regards,
Julian
1 year, 11 months
CMake broken in rawhide?
by Richard Shaw
I'm trying to rebuild a package using "fedpkg mockbuild" and the build is
failing in Rawhide but not Fedora 36.
It clearly tells CMake to put the files in the redhat-linux-build directory
but it does not:
/usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON '-DCMAKE_CXX_FLAGS=-O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fPIC' -DBUILD_SHARED_LIBS=ON -DNNG_SUPP_TLS=ON -DNNG_SUPP_WEBSOCKET=ON
-DNNG_ENABLE_NNGCAT=ON -DNNG_TESTS=ON -DNNG_ENABLE_DOC=ON .
...
-- Build files have been written to: /builddir/build/BUILD/nng-1.4.0
+ /usr/bin/cmake --build redhat-linux-build -j12 --verbose
Error: /builddir/build/BUILD/nng-1.4.0/redhat-linux-build is not a directory
I don't see anyone screaming but it doesn't seem like a problem related to
the nng package.
Thanks,
Richard
1 year, 11 months
Who checks the exception at fedora-scm-requests?
by Miro Hrončok
Hello,
I've recently seen a package that was imported into Fedora without a package
review. I've noticed this because the packages doesn't even install and I
wanted to check if this could have been caught in the package review but I
couldn't find it, so I've checked the fedora-scm-requests ticket.
The ticket at fedora-scm-requests was created with exception=true. I am not
going to link to it, because I am not here to point fingers. I am just
genuinely curious.
According to
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuideline...
we have 3 kinds of exceptions:
- FPC grants an explicit exemption from the process...
- The package is being created so that multiple versions of the same package
can coexist in the distribution...
- The package exists in both Fedora and RHEL, but the packager wants to ship it
in EPEL under an alternative name...
In those cases, the packager requests the repo with --exception, makes sense.
However, who checks if the flag was used according to the rules? Because
apparently, is seems that nobody does. Is it expected that we are all
responsible people who would not abuse this simply to avoid package reviews?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 11 months
py3status orphaned
by Jakub Jedelský
Hi y'all,
package py3status [1] is looking for a new maintainer. I'm not an active
user of the package (nor i3 WM) anymore and have no capabilities to take
care of it.
It's a nice piece of python code, I hope it won't be orphaned for a long
time ;)
Best,
- jj
[1] https://src.fedoraproject.org/rpms/py3status
1 year, 11 months
perl-Chart license change
by Petr Pisar
Upstream corrected a license in perl-Chart-2.402.0
from ((GPL+ or Artistic) and Artistic 2.0) to (GPL+ or Artistic).
-- Petr
1 year, 11 months