Re: Package Tutorial bug - missing BuildRequires gcc
by Otto Liljalaakso
Kenneth Goldman kirjoitti 1.3.2023 klo 22.35:
> https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
> GNU_Hello/
>
> The tutorial says:
>
> Lines which are not needed (e.g. BuildRequires and Requires) can be
> commented out with the hash # for now.
>
> However, I believe that this line is needed. I'm new so perhaps I'm missing
> something.
>
> BuildRequires: gcc
Hello Kenneth,
Thank you reporting the problems you have with the tutorial here on
devel. This kind of feedback is really useful for improving the
tutorial. I can see how it can be confusing in its current form. The
root of the problem here seems to be that the tutorial first instructs
to create a new specfile with rpmdev-newspec, then to replace it with a
different initial specfile, and then later goes back to discussing
something that was in the rpmdev-newspec's variant. The Requires: and
BuildRequires: in the line you quote refer to that.
I wrote a pull request to improve this [1]. Please take a look.
[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/115
1 year, 2 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, 2 months
Updating libbraiding from 1.1 to 1.2 in F39/Rawhide
by Ben Beasley
In one week (2023-03-09), or slightly later, I plan to update libbraiding from 1.1 to 1.2 in F39/Rawhide. Upstream says, “Minor changes for compatibility with newer C++.”
https://github.com/miguelmarco/libbraiding/compare/1.1...1.2
This is not supposed to be an incompatible update, and the .so version is unchanged, but there are changes to inline template functions that are used both inside and (potentially) outside the compiled library, and the compiled library loses several symbols as a result:
Comparing the ABI of binaries between libbraiding-1.1-14.fc38.x86_64.rpm and libbraiding-1.2-1.fc39.x86_64.rpm:
================ changes of 'libbraiding.so.0.0.0'===============
Functions changes summary: 5 Removed, 0 Changed, 0 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
5 Removed functions:
[D] 'method bool CBraid::Factor<CBraid::ArtinPresentation>::CompareWithDelta(CBraid::sint32) const' {_ZNK6CBraid6FactorINS_17ArtinPresentationEE16CompareWithDeltaEi}
[D] 'method bool CBraid::Factor<CBraid::ArtinPresentation>::CompareWithIdentity() const' {_ZNK6CBraid6FactorINS_17ArtinPresentationEE19CompareWithIdentityEv}
[D] 'method CBraid::Factor<CBraid::ArtinPresentation> CBraid::Factor<CBraid::ArtinPresentation>::Flip(CBraid::sint32) const' {_ZNK6CBraid6FactorINS_17ArtinPresentationEE4FlipEi}
[D] 'function bool CBraid::MakeLeftWeighted<CBraid::ArtinPresentation>(CBraid::Factor<CBraid::ArtinPresentation>&, CBraid::Factor<CBraid::ArtinPresentation>&)' {_ZN6CBraid16MakeLeftWeightedINS_17ArtinPresentationEEEbRNS_6FactorIT_EES5_}
[D] 'function bool CBraid::MakeRightWeighted<CBraid::ArtinPresentation>(CBraid::Factor<CBraid::ArtinPresentation>&, CBraid::Factor<CBraid::ArtinPresentation>&)' {_ZN6CBraid17MakeRightWeightedINS_17ArtinPresentationEEEbRNS_6FactorIT_EES5_}
================ end of changes of 'libbraiding.so.0.0.0'===============
Therefore, for safety, I plan to build this for F39/Rawhide only, and I plan to coordinate a rebuild of sagemath (the sole dependent package) in a side tag.
1 year, 2 months
Intention to take ownership of and revive from retirement - ortp
by Philip Wyett
Hi all,
Once upon a time...
One day a fedora packager found libosip2 orphaned and decided it needed some love and adopted it.
Little did he know the rabbit hole he was about to go down. ;-)
All things lead to linphone and as a result I have adopted:
- libosip2
- libeXosip2
- linphone
An integral dependency is the retired ortp. I would like to take ownership of the package,
following the process[1].
The overall process as I see it maybe quite a brutal one, with:
- Major version updates
- soname bumps
- etc.
Hopefully when work is complete, we will have a working linphone stack. Please be patient as
efforts progress.
[1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
Regards
Phil
--
*** Playing the game for the games own sake. ***
Associations:
* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
1 year, 2 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, 2 months
Fedora 38 compose report: 20230302.n.0 changes
by Fedora Rawhide Report
OLD: Fedora-38-20230301.n.0
NEW: Fedora-38-20230302.n.0
===== SUMMARY =====
Added images: 1
Dropped images: 0
Added packages: 0
Dropped packages: 0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages: 0 B
Size of upgraded packages: 0 B
Size of downgraded packages: 0 B
Size change of upgraded packages: 0 B
Size change of downgraded packages: 0 B
===== ADDED IMAGES =====
Image: Silverblue dvd-ostree x86_64
Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-38-20230302.n.0.iso
===== DROPPED IMAGES =====
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
===== DOWNGRADED PACKAGES =====
1 year, 2 months
Re: packaging tutorial error - /usr/bin/systemd-nspawn mock-chroot
debug advice
by Vít Ondruch
Dne 01. 03. 23 v 22:59 Kenneth Goldman napsal(a):
> https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
> GNU_Hello/
>
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> when running that tutorial (Fedora 37, x86), I get this error:
>
> ERROR: Exception(/home/kgold/hello/hello-2.10-1.fc37.src.rpm)
> Config(fedora-37-x86_64) 0 minutes 18 seconds
> INFO: Results and/or logs in: /home/kgold/hello/results_hello/2.10/1.fc37
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The log has at the end:, but I suspect that the python issue is a reporting
> issue, not the actual failure.
>
> RPM build errors:
The real error you should be concerned is above this ^^ line.
> Child return code was: 1
> EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M
> d0156a2d35ca46a0ba55a993d05852c1 -D /var/lib/mock/fedora-37-x86_64/root -a
> -u mockbuild --capability=cap_ipc_lock
> --bind=/tmp/mock-resolv.lphffv1r:/etc/resolv.conf --bind=/dev/btrfs-control
> --bind=/dev/mapper/control --bind=/dev/loop-control --bind=/dev/loop0
> --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4
> --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8
> --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe
> --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir
> --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
> --setenv=PROMPT_COMMAND=printf "\\033]0;<mock-chroot>\\007"
> --setenv=PS1=<mock-chroot> \\s-\\v\\$ --setenv=LANG=C.UTF-8
> --resolv-conf=off bash --login -c /usr/bin/rpmbuild -bb --target x86_64
> --nodeps /builddir/build/SPECS/hello.spec\n', 1)]
> Traceback (most recent call last):
> File "/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py",
> line 93, in trace
> result = func(*args, **kw)
> ^^^^^^^^^^^^^^^^^
> File "/usr/lib/python3.11/site-packages/mockbuild/util.py", line 598, in
> do_with_status
> raise exception.Error("Command failed: \n # %s\n%s" % (command, output),
> child.returncode)
> mockbuild.exception.Error: Command failed:
>
This backtrace is confusing indeed and requested to be improved here:
https://github.com/rpm-software-management/mock/issues/1018
Vít
1 year, 2 months