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, 12 months
Self Introduction: Xiaofeng, FAS: wasphin
by xiaofeng
Hi, all,
My name is Xiaofeng, I am using Fedora for the first time since Fedora 13.
Currently I work on RHEL like distributions for C++ development, I am
willing to join the fedora packager group, especially the epel group.
By now, I want to co-maintain the qt-creator for epel8, it does not work
since the llvm upgrade to 11, I am really appreciated if someone can
sponsor me, thanks.
Thanks and regards.
Xiaofeng
--
xiaofeng
--
gpg key fingerprint:
2048R/5E63005B
C84F 671F 70B7 7330 4726 5EC8 02BC CBA2 5E63 005B
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2 years, 12 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
3 years
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
3 years
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.
3 years
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
3 years
Re: Fedora mingw-openssl update
by Richard W.M. Jones
On Mon, May 31, 2021 at 06:47:28PM +0200, Sandro Mani wrote:
> Hi Richard
>
> Apparently I need a newer openssl to build mingw-python3-3.9.5. Do
> you have any time to look into updating to mingw-openssl-1.1.1k? I'm
> not really familiar with the situation of all downstream patches to
> be comfortable touching that package...
One thing that may cause a problem is that openssl apparently has a
new API/ABI which breaks every client:
https://fedoraproject.org/wiki/Changes/OpenSSL3.0
But according to our Fedora / mingw policy we should stay in step with
the base Fedora packages are deal with any fallout if it happens. I
can have a go at synching the packages this morning.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
3 years
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.
3 years
