Take 1 minute to help with Infra & Releng Team with a decision
by Michal Konecny
Hi everyone,
it came to Infra & Releng Team (sub-team in CPE that is taking care of
Fedora Infra, Fedora Release Engineering and CentOS Infra) attention
that there is a confusion about the labels we are using for issues in
our trackers. Namely fedora-infrastructure, releng and centos-infra.
There was even a request to change them to something less confusing.
So we want to decide if this is really need to change, so we ask you to
take this quick survey [0] (this is an anonymous survey, nothing is
collected by us) to see if the change is really needed or people are
happy with current labels.
The survey will be closed on 7th March 2023.
On behalf of I&R Team,
Michal
[0] - https://forms.gle/J2HWDkw1UNuj8HYD8
1 year, 3 months
OpenSSH: hardening hostkeys permissions
by Dmitry Belyavskiy
Dear colleagues,
Many years ago we implemented the patch
https://src.fedoraproject.org/rpms/openssh/c/1ddd0ee5
Unfortunately, as it was 11 years ago, we can't find the exact explanation
where the requirement came from. We think that we intended to increase
security, but it probably caused more confusion than gain of the security
over the years.
The patch allows more relaxed permissions for the private keys than
upstream OpenSSH permits - 0640 instead of 0600, and the key file must
belong to the ssh_keys group. The ssh_keysign utility was simultaneously
changed from suid root to sgid ssh_keys.
The side effect of this solution is that ssh with host based auth (HBA)
started to fail after changing group ID ( with newgrp, etc.). In the case
of HBA ssh invokes ssh-keysign that does a lot of sanity checks including
group checks. The workaround is returning setuid bit instead of sgid, and
we recommend it to our clients.
Some more information is available in
https://bugzilla.redhat.com/show_bug.cgi?id=1498845
As this problem affects several clients, and it is a deviation from
upstream (the similar patch was rejected by upstream), we want to drop this
downstream patch in Fedora. We also can get rid of a designated ssh_keys
group
The problem we expect is that after reverting the patch we can lose the
remote access to the hosts because sshd will reject starting because of
group reading permissions. This should be covered by the upgrade scriptlet,
though we still may come across some issues, especially if you use host
keys in non-standard locations. How do we properly implement this feature
to avoid customers' negative feedback? Current upgrade scriptlet covers
standard key locations/names and works well enough at the 1st glance.
The proposed changes are available
https://src.fedoraproject.org/rpms/openssh/pull-request/37
A separate question is whether we want to publish this announcement as a
Fedora change and at what level. For me it looks like a self-contained
change.
--
Dmitry Belyavskiy
1 year, 3 months
F39 proposal: Modernize Thread Building Blocks for Fedora 39
(System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Fedora is currently shipping version 2020.3 (released July 10, 2020)
of the Thread Building Blocks library. The current upstream version is
2021.8 (released December 22, 2022). The Fedora community has
expressed [https://bugzilla.redhat.com/show_bug.cgi?id=2036372
interest] in moving the TBB package to track a more modern version of
the upstream.
== Owner ==
* Name: [[User:trodgers| Thomas Rodgers]]
* Email: trodgers(a)redhat.com
== Detailed Description ==
Fedora has shipped with version 2020.3 of the Thread Building Blocks
library since Fedora 33. The
upstream project made a decision to break backward compatibility after
that version was released.
As packages move to match the upstream's changes it becomes more
difficult to defer updating the
Fedora packaging for TBB. The situation is further complicated as
there are currently a majority
of TBB dependent packages which have not been updated to track a new
upstream release, as detailed in this
[https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c1 analysis] on
the tracking issue.
This proposal aims to provide a way to modernize the TBB packge
version for Fedora while providing stability for those packages which
continue to depend on the older TBB library version.
It will be possible to install both devel and runtime versions of both
TBB packages, however the devel compat package for version 2020.3 will
require clients to point to a new include path where the legacy
headers will be found.
== Feedback ==
== Benefit to Fedora ==
Fedora 39 will include a current version of Thread Building Blocks
(version 2021.8) while continuing to support clients dependent on an
older version of TBB (version 2020.3). Fedora will stay relevant as
far as Thread Building Blocks clients are concerned.
== Scope ==
* Proposal owners:
** A compat package based on the current 2020.3 version of the
existing TBB package will be created.
** Evaluate TBB dependent packages to identify those which need to
move to the compat version of the TBB package. An initial analysis
suggests the majority of current TBB clients will need to move to the
compat package.
** Post a request for rebuilds to fedora-devel
** Create patches for those packages affected by this change to adjust
their includes to point the compat package's headers as necessary,
work with affected package owners to update package specs to account
for the change.
** When most packages are done, re-tag all the packages in rawhide.
** Watch fedora-devel and assist in rebuilding broken TBB clients.
* Other developers:
** Those who depend on Thread Building Blocks will have to rebuild
their packages. Feature owners will alleviate some of this work as
indicated above, and will assist those whose packages fail to build in
debugging them.
* Release engineering: TODO <!-- [https://pagure.io/releng/issues
#Releng issue number] -->
* Policies and guidelines: N/A (not needed for this Change)
** Apart from scope, this is business as usual, so no new policies, no
new guidelines.
== Upgrade/compatibility impact ==
* No manual configuration or data migration needed.
* Some impact on other packages needing code changes to rebuild.
== How To Test ==
* No special hardware is needed.
* Parallel install of the 2020.3 TBB compat packages and the updated
TBB packages and checking that it does not break other packages.
== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new TBB packages, and may need to adjust their
code to either remain on the compat TBB version or move to the new
version supplied by the updated TBB package.
== Dependencies ==
Packages that must be rebuilt:
<code>& dnf repoquery -s --releasever=rawhide --whatrequires libtbb\*
--enablerepo=fedora | sort -u</code>
The tracking [https://bugzilla.redhat.com/show_bug.cgi?id=2036372
issue's] analysis suggests that only the following packages will be
able to move to a newer TBB -
* fawkes
* gazebo
* opencascade
* pmemkv
* root
While the remaining clients of TBB will need to have their spec's
include paths adjusted to use the 2020.3 compat package.
== Contingency Plan ==
* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F39 with the existing TBB package, which is already in
rawhide.
== Documentation ==
* Notes on the scope of change, motivation, and likely impacts are in
the comments on the tracking
[https://bugzilla.redhat.com/show_bug.cgi?id=2036372 issue].
* https://github.com/oneapi-src/oneTBB/releases/tag/v2021.7.0
(Released 2nd October 2022)
* https://github.com/oneapi-src/oneTBB/releases/tag/v2020.3 (Released
10th July 2020)
== Release Notes ==
<!-- TODO -->
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 3 months
RE: fedpkg: Failed to get repository name from Git url or pushurl
by Artur Frenszek-Iwicki
> Should that tutorial work? Is it perhaps obsolete?
I'd say the opposite of obsolete - it's been updated to suggest using
fedpkg all along the way, instead of the old rpmbuild tools. But it
looks like it wasn't tested enough to make sure everything works.
> My newbie understanding is that fedpkg should get the source from the
> Source0 location and then follow the build instructions.
> Is that even close?
This is a bit complicated. When the package is being built, the list
of files is taken from the Source: tags in the spec file. However,
fedpkg keeps a separate file, "sources" (no extension), where it
lists files uploaded to the Fedora build cache. The justification
is that keeping source tarballs in the repository is a bad idea,
since these files can be really large (1GiB+ for game packages),
so they're stored in a cache instead, and the repository contains
only this "sources" file with references to said cache. (That being
said, you totally can store source files in the repo - this is
often done with stuff like non-standard Fedora configs.)
As for the "get the source from the Source0 location" bit - no.
fedpkg will not download stuff from Source: tags for you,
only the files listed in the "sources" file.
Since my impression is that you want to start experimenting with
RPM packaging in general, and not specifically fedpkg - I'll do
a bit shameless self-promotion and link to an article
on RPM packaging that I wrote some time ago:
https://blog.svgames.pl/article/basics-of-rpm-packaging
In this article, I show how to build RPM packages using the traditional
rpmbuild workflow. If you're just starting out with writing specs
and such, it should get you started enough to make switching
to fedpkg later down the road a no-brainer.
A.FI.
1 year, 3 months
Re: Changes to Bugzilla API key requirements
by Kevin Kofler
Ben Cotton wrote:
> Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You
> must replace your API keys at least once a year. Additionally, any API
> key that is not used for 30 days will be suspended but can be
> re-enabled on the account's preferences tab.
So Red Hat Bugzilla API use again got unfriendlier.
The previous change was already unacceptable IMHO (going as far as
invalidating any passwords accidentally attempted to be used through the
API!), this makes it even worse.
IMHO, Fedora really needs its own bug tracker that is not driven by this
kind of enterprise-grade security requirements.
Kevin Kofler
1 year, 3 months
c++ packaging of contour terminal and libunicode
by Felix Wang
spec file URL of libunicode: https://gist.githubusercontent.com/topazus/e30b83d669600756894a77b5258c94...
spec file URL of contour: https://gist.githubusercontent.com/topazus/f81005cb85762ce2cf6e138f0b1ced...
Descriptions about problems:
I first build libunicode dependency using my spec file and install it on my machine.
Then I try build contour terminal. It failed with the following errors:
```
[ 10%] Linking CXX static library libtext_shaper.a
cd /home/ruby/rpmbuild/BUILD/contour-98c8c0d0e96dc7c56ee06b4e8bfd71a23ae4f4d6/redhat-linux-build/src/text_shaper && /usr/bin/cmake -P CMakeFiles/text_shaper.dir/cmake_clean_target.cmake
cd /home/ruby/rpmbuild/BUILD/contour-98c8c0d0e96dc7c56ee06b4e8bfd71a23ae4f4d6/redhat-linux-build/src/text_shaper && /usr/bin/cmake -E cmake_link_script CMakeFiles/text_shaper.dir/link.txt --verbose=1
/usr/bin/ar qc libtext_shaper.a CMakeFiles/text_shaper.dir/font.cpp.o CMakeFiles/text_shaper.dir/font_locator_provider.cpp.o CMakeFiles/text_shaper.dir/fontconfig_locator.cpp.o CMakeFiles/text_shaper.dir/mock_font_locator.cpp.o CMakeFiles/text_shaper.dir/open_shaper.cpp.o CMakeFiles/text_shaper.dir/shaper.cpp.o
/usr/bin/ranlib libtext_shaper.a
gmake[2]: Leaving directory '/home/ruby/rpmbuild/BUILD/contour-98c8c0d0e96dc7c56ee06b4e8bfd71a23ae4f4d6/redhat-linux-build'
[ 10%] Built target text_shaper
/usr/bin/ld: /tmp/ccW09Umc.ltrans0.ltrans.o: warning: relocation against `_ZGVZN8logstore4Sink7consoleEvE8instance' in read-only section `.text.startup'
/usr/bin/ld: /tmp/ccW09Umc.ltrans0.ltrans.o: relocation R_X86_64_PC32 against symbol `_ZTIZN8logstore4SinkC4EbRSoEUlSt17basic_string_viewIcSt11char_traitsIcEEE_' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
gmake[2]: *** [src/crispy/CMakeFiles/crispy-core.dir/build.make:148: src/crispy/libcrispy-core.so] Error 1
gmake[2]: Leaving directory '/home/ruby/rpmbuild/BUILD/contour-98c8c0d0e96dc7c56ee06b4e8bfd71a23ae4f4d6/redhat-linux-build'
gmake[1]: *** [CMakeFiles/Makefile2:267: src/crispy/CMakeFiles/crispy-core.dir/all] Error 2
gmake[1]: Leaving directory '/home/ruby/rpmbuild/BUILD/contour-98c8c0d0e96dc7c56ee06b4e8bfd71a23ae4f4d6/redhat-linux-build'
gmake: *** [Makefile:159: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.Eo3xWu (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.Eo3xWu (%build)
```
I also try to build contour from the SOURCE file of contour .spec file, which is
cmake . -DCONTOUR_BUILD_WITH_QT6=ON && make -j6, the above build cmd worked fine. So I doubt the error that appeared in the build process with .spec file is related with the setting build flags with %cmake macros, but I do not know how to modify it? Or the error is relevant with build options in CMakeLists.txt from the upstream repo code?
1 year, 3 months
Update of catch to Catch2 v3
by Tom Hughes
As discussed a few weeks ago the Catch testing framework has
a slightly weird naming scheme, namely:
* Catch (v1.x, actually a branch in Catch2 repository)
* Catch2 v2.x
* Catch2 v3.x
Since Catch2 was released we have had catch1 and catch packages
to support both v1.x and v2.x users.
I have now added catch2 (for Catch2 v2.x) and upgraded the catch
package to Catch2 v3.x in rawhide and f38.
What this means is that if your package uses catch-devel to build
that you probably need to update your BuildRequire to catch2-devel
when you next build it - unless your upstream supports v3.x of
course.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
1 year, 3 months
