Intent to start ARC investigation git-forge replacement
by Tomas Hrcka
Hello, Fedora community,
Following on from the Fedora Council's decision to investigate Forgejo
and GitLab as potential replacements[1], the Community Platform
Engineering team will start an ARC[2] investigation to compare
proposed alternatives for current pagure use cases.
The council has defined some broad requirements for the team to
consider during this investigation. But we would like inputs from all
gitforge user groups in our community.
So, if you have a specific use case or workflow, share it with us in
the form of a user story in this ticket[6], or consider joining the
ARC team for this investigation.
High-level overview of investigation requirements by the council:
1. Suitability for dist-git and src.fedoraproject.org replacement
2. Suitability for replacement of Bugzilla for packaging issues and
review process
3. Suitability for replacement of Pagure and Bugzilla for release
issues (change process, blocker bugs, etc)
* https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
* https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
4. Suitability for replacement of Pagure for SIG and Team ticket
tracking (e.g. FESCo tracker)
5. Cost of hosting and maintenance (hardware + time and resources
from CPE and wider infrastructure team)
6. Ease of migration from current Pagure, GitHub, and GitLab
7. Ease of extension and enhancement — can we improve things
ourselves to add missing features/features that are cool and useful
like CI integration?
8. New features like Asciidoc support, Online editor, and others to
make things easier for the Fedora teams and their workflows.
9. Estimate Future risk for Fedora project and Infrastructure team
1. Long-term project vision
2. Platform SMEs in the Fedora Infrastructure team and the wider community
These requirements do not represent feature sets, but rather a
high-level overview of our current use cases.
CPE has already done some initial mapping of how our current
applications interact with distgit[3] and if we have missed anything,
please let folks know in a thread on discussions.fp.o[4].
The aim of this investigation will not be to pick one solution or the other,
but instead, focus on providing the Fedora Council and decision
makers[5] with an extensive comparison of the two.
For discussion about the purpose of this investigation please use the
discussions.fp.o thread[7]
The ARC investigation will commence in early May.
[1] - https://communityblog.fedoraproject.org/2024-git-forge-evaluation/
[2] - https://fedora-arc.readthedocs.io/en/latest/index.html
[3] - https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html#inte...
[4] - https://discussion.fedoraproject.org/t/dist-git-decoupling-investigation/...
[5] - https://pagure.io/Fedora-Council/tickets/issue/488
[6] - https://pagure.io/fedora-infra/arc/issue/164
[7] - https://discussion.fedoraproject.org/t/arc-git-forge-investigation/114018
Tomas Hrcka
Cat herder at Community Platform Engineering team
fas: humaton
libera.CHAT: jednorozec
matrix: @humaton:fedora.im
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2 days, 14 hours
LLVM Packaging Ideas for Fedora 41
by Tom Stellard
Hi,
After each Fedora release we do a retrospective with the LLVM package maintainers
and talk about how we can improve the LLVM packages[1] in Fedora. We've come up
with some ideas for Fedora 41 that we'd like to share to raise awareness and
get feedback. Right now these are just ideas, and we plan to write up a formal
change proposal once we have decided which of these we are going to implement:
* Spec file merge. We plan to merge the clang, compiler-rt, and libomp packages
in with llvm and have them be sub-packages of the llvm package. This will allow
us to use the build configuration recommended by upstream and also make it possible
to optimize the packages using Profile-Guided Optimizations (PGO).
* Build compat packages (e.g. llvm18) as early as possible. When we package a new
major release of llvm, we create a compat package so that packages that aren't
compatible with the new version can still use the old version. In the past, we've
waited to introduce the compat packages until the new version of LLVM was ready
(typically during the Beta Freeze). However, this proved to be an issue this
release for packages the were ready to switch to the compat packages early in
the release cycle, but then had to wait for Beta freeze.
* Switch to python-style compat/main packages. In order to make the packaging more
consistent between the main package (e.g. llvm) and the compat package (e.g. llvm18),
we would retire the un-versioned dist-git for llvm, and create a new versioned dist-git
for each new release (e.g. llvm19, llvm20, llvm21 etc.). We would then designate one
of these as the 'main version', and that version would produce binary rpms that look
like the current main package (i.e. llvm-libs instead of llvm19-libs).
* Invert the order of compat/main packages. Instead of having the compat package be
the old version, and the main package be the new version, we would have the compat package
be newer and the main package be older. This would allow us to introduce a new version of
llvm without impacting other packages that depend on the main version of LLVM.
If anyone has any feedback on these ideas we'd like to hear it and are happy to discuss
these more.
Thanks,
Tom
[1] LLVM Packages are: llvm, clang, compiler-rt, libomp, lld, lldb, llvm-test-suite, libclc,
llvm-bolt, libcxx, mlir, flang, python-lit, and polly.
3 days, 11 hours
on dnf autoremove aggressive behaviour
by Germano Massullo
I recently updated to F40 KDE, but Jami software [1] bundled Qt6 RPM
package messed up with system Qt6 (see later fix at [2]), so I had to run:
# dnf autoremove
# dnf reinstall $(rpm -qa)
I have noticed an aggressive packaging removal behaviour from "dnf
autoremove", indeed it removed various essential packages, some of them
even installed by default during Fedora installation (complete list at
[3]) For example:
- gdisk
- openssl
- lz4
- java-21-openjdk
dnf man page, says:
====
dnf [options] autoremove
Removes all "leaf" packages from the system that were originally
installed as dependencies of user-installed packages, but which are no
longer required by any such package.
Packages listed in installonlypkgs are never automatically removed by
this command.
====
I wonder:
1) where installonlypkgs is defined, I could not find it in /etc/dnf
2) why it removed also packages that are shipped by default during a
Fedora installation, like gdisk and openssl
[1]: https://en.wikipedia.org/wiki/Jami_(software)
[2]:
https://review.jami.net/c/jami-project/+/27951/2/packaging/rules/rpm/jami...
[3]: https://paste.centos.org/view/ec0ae480
1 week, 2 days
Updating Taskwarrior to v3
by Ankur Sinha
Hi folks,
Taskwarrior has recently released version 3.x. While the command line
remains the same, this version includes backwards incompatible changes:
https://github.com/GothenburgBitFactory/taskwarrior/releases/tag/v3.0.0
https://taskwarrior.org/docs/upgrade-3/
- the user task database format has changed and requires users to
manually migrate
- it no longer supports taskserver for syncing
The upgrade steps say that one must migrate their data base *before*
installing task v3.
So, this is clearly a backwards incompatible change that requires users
intervention.
What would be the best way of handling this? I didn't want to just
update the package in Fedora. Instead I was thinking of packaging
taskwarrior v3 as a new package, task3, that will obsolete the
current package but not update it.
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
1 week, 3 days
RFC: Flaws detected by static analyzers in Fedora 41 Core Critical
Path Packages
by Siteshwar Vashisht
Hello,
This is a follow up on my previous email[1] about OpenScanHub Prototype for
Fedora.
Thank you to those who have provided early feedback. Your help is truly
appreciated!
I am writing this message to get feedback from the community on possibly
new defects identified by static analyzers in Core Critical Path packages
that have changed in Fedora 41.
TLDR: This report[2] contains 14188 identified defects. Please review the
report and provide feedback.
A mass scan was performed this week on the packages that have changed in
Fedora 41. This report[2] contains all the new defects that have been
identified in the core packages listed in Critical Path Packages. Please
review the report and fix or report any defects to upstream that may be
real bugs. Not all defects reported by OpenScanHub may be actual bugs, so
please verify reported defects before investing time into fixing or
reporting them. We hope this is helpful for the packages you maintain and
for the upstream projects. Questions can be asked on the OpenScanHub
mailing list[3]. If you want to see the full logs of the scans, they are
available on the tasks[4] page. User documentation for performing a scan is
available on the Fedora wiki[5].
If the feedback on this report is positive, there may be a possibility of
increasing the scope of scans to cover a wider range of packages.
Please remember this is currently an early production stage for OpenScanHub
scanning. Constructive feedback is appreciated. Thank you!
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[2] https://svashisht.fedorapeople.org/f41-22-Apr-2024/
[3]
https://lists.fedoraproject.org/archives/list/openscanhub@lists.fedorapro...
[4] https://openscanhub.fedoraproject.org/task/
[5] https://fedoraproject.org/wiki/OpenScanHub
1 week, 4 days
Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
by Jan Kolarik
Hello everyone,
We've prepared a side-tag for testing Rawhide with dnf5 as the default
package manager. Instructions for installing the packages from the side-tag
can be found at the following link [1].
Please provide feedback in Bodhi or on this mailing list regarding the use
cases you're familiar with from the existing dnf command, and share your
experience with this new version.
If there's no negative feedback regarding any critical functionality, we
plan to push the packages from the side-tag to Rawhide next week.
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-8a41ea93a2
Thanks,
Jan
1 week, 5 days
