IRC Announcement
by Nick Bebout
Since its beginnings, the Fedora Project has used the freenode IRC network
for our project communications. Due to a variety of recent changes to that
network, the Fedora Project is moving our IRC communications to Libera.Chat.
If you are a current IRC user, please go and register your nick(s) on
Libera.Chat ( https://libera.chat/guides/registration#registering ) and
rejoin the #fedora related channels you wish to. You can take this
opportunity to choose a new secure password and make sure you are
connecting via SSL. There is good documentation about choosing an IRC
client at https://libera.chat/guides/clients
If you are a Matrix user, we ask for your patience as we get bridges setup
on the new network. If you were joined to rooms via the generic freenode
bridge, you will need to leave them and rejoin the fedora rooms in matrix
(which will be plumbed with the Libera channels)
As of 2021-05-28 our official IRC presence is on irc.libera.chat.
Many Fedora channels have moved over and are ready on Libera.Chat. However,
less-used channels have not be automatically setup. If you need a specific
#fedora-* IRC channel setup, please file a ticket at http://pagure.io/irc
requesting the channel.
New channels should have the same name as they did on freenode. For
example: #fedora, #fedora-admin, #fedora-devel, and #fedora-join.
If you would like a fedora IRC ‘cloak’ you can request it at:
https://fedoraproject.org/wiki/LiberaCloaks
(an IRC cloak obfuscates your client host address and shows ‘fedora’
instead). Please note that cloaks are not foolproof, there are ways for
people to still get your IP, but they do make it more difficult for people
to obtain your IP.
Also, look for upcoming exciting announcements around Fedora’s Matrix
presence.
nb
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
2 years, 10 months
Building for EPEL-8 and CMake (again)
by Ron Olson
Hey all-
Awhile back I asked about the status of CMake in CentOS so I could build my packages for EPEL-8; they require a version of CMake that is greater than 3.11.4 which is currently available. CentOS Stream has a later version, as does RHEL 8.4. I get that CentOS Stream is the future of CentOS, but when I run a koji build for EPEL 8 it uses CentOS 8, not CentOS Stream and thus all my builds fail.
TL;DR: How can I build anything for EPEL 8 with CMake if the package is too old?
Thanks!
Ron
2 years, 10 months
F35 Change: Support using a GPT partition table in Kickstart
(System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/InstallGPTwithKickstart
== Summary ==
Add support for configuring GPT partition table in kickstart without
requiring a custom pre-installation script or a custom boot script.
[[Category:SystemWideChange]]
== Owners ==
* Name: [[User:Davdunc|David Duncan]], [[User:Chrismurphy|Chris
Murphy]], [[User:Salimma|Michel Alexandre Salim]],
[[User:Dcavalca|Davide Cavalca]], [[User:Ngompa|Neal Gompa]],
[[User:Dustymabe|Dusty Mabe]]
* Email: davdunc(a)amazon.com, chrismurphy(a)fedoraproject.org,
michel(a)michel-slm.name, dcavalca(a)fb.com, ngompa13(a)gmail.com,
dusty(a)dustymabe.com
* Products: Fedora Cloud Edition
* Responsible WGs: Fedora Cloud WG
== Detailed Description ==
Fedora Cloud Edition wants to use a GPT partition table; however, it
is not possible
to force the creation of an image with the GPT partition table with
our current tooling
because Anaconda requires setting <code>inst.gpt</code> as a kernel
boot parameter
to do it. This Change proposes to add a way to declare this via kickstart so
that the Cloud Edition image builds can create images using the GPT
partition table
using the current tooling (which is built on Anaconda).
== Benefit to Fedora ==
Users will be able to install systems with a GPT partition table via
kickstart without
requiring an extensive custom pre-installation script or a custom boot
script. Disk images
produced using the Anaconda tooling (Oz/ImageFactory, Lorax) can also
trivially make
images with GPT partition tables. This makes it possible to create
hybrid BIOS+UEFI boot
images, given [[Changes/UnifyGrubConfig|the changes to GRUB
configuration from Fedora Linux 34]].
== Scope ==
* Proposal Owners
** Review and discuss with the Anaconda maintainers and determine the
next steps for support of the inst.gpt in pykickstart
** Work with Anaconda maintainers to implement in Anaconda
* Release engineering: [https://pagure.io/releng/issue/10137 #10137]
* Policies and guidelines: N/A
* Trademark approval: N/A
== How to test ==
Build images using virt-install with kickstarts that have the option
set. Verify that the disk partition table is properly configured as
GPT. Verify that without the option set, it uses legacy MBR.
== User Experience ==
* Allows for the use of the standard pykickstart directive for
specifying the preference for GPT partition.
== Dependencies ==
* Anaconda [https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#ins...
inst.gpt]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 10 months
texlive 2021 landing in Rawhide
by Tom Callaway
Hi Fedorans,
Just a heads-up, texlive-base (where the compiled code and immediate
dependencies lives) and texlive (where the thousands of other noarch
components live) have been updated to TeXLive 2021 in Rawhide (and the
latest available components from CTAN at the time I did the work).
I've done local testing and everything seems to still work, but inevitably,
the act of updating TeXLive breaks things, so if your packages have TeX
dependencies and stop building in rawhide, let me know.
Also, FWIW, I have no plans to bring this back to any stable branches.
TL2020 is doing well enough there for now.
Thanks in advance for your patience,
~spot
P.S. Please don't start the "WHY THE #$%& does texlive make so many
subpackages" thread unless you're sending me money, fine alcohol, or
patches.
2 years, 10 months
Intent to retire - findbugs / findbugs-bcel / findbugs-contrib / eclipse-findbugs
by Richard Fearn
Hi everyone,
I'm writing to say that I intend to retire the following packages:
* findbugs
* findbugs-bcel
* findbugs-contrib
* eclipse-findbugs
The rationale behind this is:
* The last FindBugs release was in March 2015 [1].
* Upstream has been dead since 2016 [2].
* The project was forked in 2017 [3] as SpotBugs [4].
* FindBugs depends on an old snapshot of Apache Commons BCEL (packaged as
findbugs-bcel). I don't think it's possible (or worthwhile) to get FindBugs
to build against upstream BCEL.
* It no longer builds against the latest rawhide versions of ASM and
Hamcrest.
* Trying to maintain FindBugs and keep it building/working against the
latest versions of Java libraries isn't really a good use of anyone's time
(and there is no upstream to contribute patches back to).
* findbugs-contrib (known upstream as fb-contrib [5]) is a FindBugs plugin
that provides additional detectors, and is of no use without FindBugs
itself.
* Likewise, eclipse-findbugs makes FindBugs available in the Eclipse IDE,
and is of no use without FindBugs being available.
As far as I can tell, nothing else depends on this set of packages:
$ sudo dnf repoquery --recursive --whatrequires findbugs
Last metadata expiration check: 1:11:19 ago on Sat 29 May 2021 23:00:52 BST.
ant-findbugs-0:3.0.1-25.fc34.noarch
eclipse-findbugs-0:3.0.1-23.fc34.noarch
eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-contrib-samples-0:7.4.7-6.fc34.noarch
findbugs-tools-0:3.0.1-25.fc34.noarch
$ sudo dnf repoquery --recursive --whatrequires findbugs-bcel
Last metadata expiration check: 1:11:24 ago on Sat 29 May 2021 23:00:52 BST.
ant-findbugs-0:3.0.1-25.fc34.noarch
eclipse-findbugs-0:3.0.1-23.fc34.noarch
eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-0:3.0.1-25.fc34.noarch
findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-contrib-samples-0:7.4.7-6.fc34.noarch
findbugs-tools-0:3.0.1-25.fc34.noarch
$ sudo dnf repoquery --recursive --whatrequires findbugs-contrib
Last metadata expiration check: 1:11:31 ago on Sat 29 May 2021 23:00:52 BST.
eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch
findbugs-contrib-samples-0:7.4.7-6.fc34.noarch
$ sudo dnf repoquery --recursive --whatrequires eclipse-findbugs
Last metadata expiration check: 1:11:39 ago on Sat 29 May 2021 23:00:52 BST.
eclipse-findbugs-contrib-0:7.4.7-6.fc34.noarch
It's been interesting keeping FindBugs alive since I picked it up in 2010
(11 years ago... where has the time gone?!), but the world has moved on (to
SpotBugs), and I think it's time to let it go.
Regards,
Rich
[1] http://findbugs.sourceforge.net/
[2]
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/00432...
[3]
https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2017-September/0043...
[4] https://spotbugs.github.io/
[5] https://github.com/mebigfatguy/fb-contrib
--
Richard Fearn
richardfearn(a)gmail.com
2 years, 10 months
Friday , May 28 unattended update broke amdgpu DKMS building
by eedio
I was on unattended updates and Friday afternoon the Radeon RS780 machine rebooted into minimal resolution mode and can no longer go to full HD resolution.
I put the disk into an old laptop with intel GPU where the DKMS modules amdgpu cannot build properly, thus Radeon machines are screwed.
"/etc/udev/rules.d/70-amdgpu.rules:1 Invalid operator for GROUP."
was what the protocoll had to say.
2 years, 10 months
New Fedora Packages Ready For Testing
by Brendan Early
Hi all,
Fedora Packages Static is intended to replace the old Fedora Packages
app and is now available for testing at
https://packages.stg.fedoraproject.org. Any feedback would be
appreciated here or on Pagure at https://pagure.io/fedora-packages-static.
The app is designed to function with the minimum amount of dynamic
server components needed. Pages are statically generated using a Python
script; the only dynamically generated page is the search result page.
Data is updated hourly. Search is handled externally by an instance of
Apache Solr. Clients do not need JS to use the app.
Thanks to Timothée Floure for the original version of Fedora Packages
Static and Kevin Fenzi for helping deploy the app on OpenShift.
Brendan Early
2 years, 10 months
Where is system-config-users?
by Robert-André Mauchin
Hello,
System-config-users
https://src.fedoraproject.org/rpms/system-config-users has been retired
due to FTBFS and lack of mainteance. I would like to revive it but I
can't find the source code anywhere. It was previously hosted on
fedorahosted but has not been moved to Pagure.
Anyone knows if there is still an official repo for it?
Best regards,
Robert-André
2 years, 10 months
Having python3-faker installed causes pytest-3 to fail
by Artur Frenszek-Iwicki
Long story short: I have a Python package ("cozy") which built fine in koji, but failed to build locally - or rather, it built fine, but then caused pytest-3 to crash. After a bit of fiddling, I managed to nail this down to having "python3-faker" installed - when I removed it from my system, pytest-3 worked fine. When I added "BuildRequires: python3-faker" to the package spec and submitted a scratch build to koji, that failed with the same traceback as the local build.
Here's the link to a successful build (currently in Rawhide):
https://koji.fedoraproject.org/koji/taskinfo?taskID=68991239
Here's the link to a failed scratch build (same spec as above, with added BR on python3-faker):
https://koji.fedoraproject.org/koji/taskinfo?taskID=69012902
I have very little Python knowledge, and the traceback lists some internal Python libs, so I'm not really sure if this should be reported as a bug against cozy, pytest-3, python-faker, or maybe even python3.9 itself. I'd be grateful if someone knowledgeable in the matter took a look.
Thanks in advance,
A.FI.
2 years, 10 months
