February 2023 - devel - Fedora Mailing-Lists

Retiring Bottles in favor of Flatpak provided by upstream

by Sandro

Hi, Development of Bottles is moving fast and we have been struggling to keep up with upstream releases, especially since the introduction of Rust components. Upstream has approached the maintainers [1,2] and asked us to retire the package in favor of the Flatpak packages provided by upstream. I'm planning to move forward with retiring Bottles in the coming days. I will add a comment in all open bug reports, letting users know they should switch to the Flatpak release. Bottles in F36 and F37 will not receive any further updates unless there are security related issues surfacing. [1] https://github.com/bottlesdevs/Bottles/issues/2345 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2160007 Cheers, Sandro -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee

1 year, 2 months

20
37
5 / 9

Release rpkg-1.65 and fedpkg-1.43

by Ondrej Nosek

Hi all, a new version rpkg-1.65 together with fedpkg-1.43 are released containing both features and bugfixes. Currently, all supported packages are present in stable repositories. Changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.65.html https://docs.pagure.org/fedpkg/releases/1.43.html Both released (rpkg & fedpkg) versions need to be installed together, they contain some changes incompatible with older packages. Centpkg also requires the newest version of rpkg. Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.65-2.el7&builds=rp... Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 https://bodhi.fedoraproject.org/updates/?packages=fedpkg&page=1 rpkg is also available from PyPI. Thanks to all contributors. Regards

1 year, 2 months

5
11
0 / 0

Should python-mysql be retired in Fedora and EPEL?

by Michel Alexandre Salim

Dear fellow Fedorans, It seems that python-mysqlclient will now transparently upgrade python- mysql since 2.1.1-2 (for Fedora): https://src.fedoraproject.org/rpms/python-mysqlclient/c/1da9400c1c9c8eb8b... and 1.4.6-6 (EPEL 8) https://src.fedoraproject.org/rpms/python-mysqlclient/c/cc24faae44f40898b... (python-mysql was never in EPEL9) The two upstreams are the same (python-mysql points to https://github.com/PyMySQL/mysqlclient-python but that just redirects to https://github.com/PyMySQL/mysqlclient) However it seems that python-mysql itself is not retired -- should it? Seems like there's no release in which trying to install it won't just install python-mysqlclient instead anyway. The maintainers don't seem to overlap: - python-mysql maintained by mschorm and hobbes1069 - python-mysqlclient maintained by fab (the changes to make mysqlclient obsolete mysql are made by non- maintainers) Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

1 year, 2 months

3
3
0 / 0

can't install package pipewire-jack-audio-connection-kit

by Martin Gansser

Hi, when trying to install pipewire-jack-audio-connection-kit i get this error message: # dnf -y install pipewire-jack-audio-connection-kit Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020. Error: Problem: problem with installed package jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - conflicting requests - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.i686 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 - package pipewire-jack-audio-connection-kit-0.3.15-2.fc33.x86_64 conflicts with jack-audio-connection-kit provided by jack-audio-connection-kit-1.9.14-5.fc33.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) How can i fix this ? Regards Martin

1 year, 2 months

11
17
0 / 0

Go leaves will be mass retired in one month

by Maxwell G

(Resending as it seems this didn't reach the ML the first time...) Hi Fedorians, Changes/Mass_Retire_Golang_Leaves [1] has been approved by FESCo. As part of this Change, all Go library packages that are leaves will be be mass retired and removed from the Fedora 39 repositories in approximately one month. The following maintainers/groups own co-maintain or watch at least one package that we have identified as a leaf: @deepinde-sig @go-sig @osbuild-sig agerstmayr anthr76 athoscr atim carlwgeorge dcavalca dctrud eclipseo fab fale fuller gundersanne jchaloup jdoss jjelen laiot logic mayorga mgoodwin nathans obudai pwouters qulogic rga rominf yanqiyu I will forward this message to those users separately instead of BCCing. Apparently, some people have broken filters that hide any email sent to the ML even if it's addressed to them directly. See [2] for a full list of leaves and [3] for a maintainer by maintainer breakdown. Maintainers may opt out by cloning https://pagure.io/GoSIG/go-leaves/ and pushing an `opt-out/{PKGNAME}` file with a short justification. Something like: ``` git clone ssh://git@pagure.io/GoSIG/go-leaves.git cd go-leaves echo "Dependency for foo (review bug #XXXXX)" > ./opt-out/bar git add ./opt-out/bar git commit -m "opt out bar" git push origin ``` All Go SIG members have write access to this repository. Other users can submit a pull request. You're also welcome to file an issue and I'll push the file for you. After a month has passed, we'll remove Go SIG write access from the repository and stop accepting additional opt-outs. Then, we'll preform test builds in Copr to make sure there's no false positives in the list. Finally, I'll verify the results, opt out any additional false positives, and preform the mass retirement. As usual, anybody can unretire packages without a re-review within eight weeks by filing a releng ticket. [1] https://fedoraproject.org/wiki/Changes/Mass_Retire_Golang_Leaves [2] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves [3] https://pagure.io/GoSIG/go-leaves/blob/main/f/leaves-by-maintainer Thank you for your cooperation, -- Maxwell G (@gotmax23) Pronouns: He/They

1 year, 2 months

1
1
0 / 0

Planning to start unifying native and mingw packages

by Sandro Mani

Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants: eigen3 mingw-eigen3 enchant2 mingw-enchant2 freeimage mingw-freeimage gdal mingw-gdal GeographicLib mingw-GeographicLib geos mingw-geos giflib mingw-giflib gtkspell3 mingw-gtkspell3 gtkspellmm30 mingw-gtkspellmm30 jxrlib mingw-jxrlib leptonica mingw-leptonica libgeotiff mingw-libgeotiff libimagequant mingw-libimagequant libkml mingw-libkml librttopo mingw-librttopo libspatialite mingw-libspatialite libwebp mingw-libwebp openjpeg2 mingw-openjpeg2 OpenSceneGraph mingw-OpenSceneGraph osgearth mingw-osgearth podofo mingw-podofo proj mingw-proj python-pillow mingw-python-pillow qtspell mingw-qtspell shapelib mingw-shapelib svg2svgt mingw-svg2svgt tesseract mingw-tesseract uriparser mingw-uriparser I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos. Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/

1 year, 2 months

9
35
0 / 0

webkitgtk6.0 soname bump season

by Michael Catanzaro

Hi, The webkitgtk6.0 package (for GTK 4, not GTK 3) will be doing several soname bumps over the next two months in preparation for stabilizing the GTK 4 API. I won't announce individual bumps since they will be frequent. I will handle rebuilds of the impacted packages: gnome-initial-setup, gnome-builder, evolution-data-server, and epiphany. (If I've missed anything, please yell.) These soname bumps will happen in both rawhide and also in F38 once it is branched. Sometime soon, hopefully in February but maybe early March, the API/ABI will become stable, as it already is for GTK 3, and the fun will then be over. Hopefully. Michael

1 year, 2 months

1
2
0 / 0

Assess impact of package changes with the mass prebuilder

by Frederic Berat

Hello Fedora community, The Christmas period is coming, and soon after the Fedora mass rebuild will come and may lead to the creation of a bunch of FTBFS bugzillas. I'd like to share with you the availability of a tool that we started to develop this year, which aims to help developers to assess the impact a change in their component will have on other components that depend on them. I recently used it in order to prepare for the upcoming Autoconf 2.72 release, and with it uncovered about 84 build failures (out of 1197 packages depending on Autoconf) that would have been missed if I were following the "classical" workflow. This resulted in few bugs opened in corresponding components, and even upstream changes toward the Autoconf community, prior to the official 2.72 release. In the past weeks, it has also been used to assess the impact of porting Fedora to Modern C (by Florian Weimer) which tested about 10k packages and for the make 4.4 update (from DJ Delorie), which tested about 9k dependencies against this new version to look for breakage. Yet, the more users there will be, the more this tool will improve and be useful for the packagers. This tool is called the mass prebuilder. I've written a blog post for Red Hat a while ago, which already contains a lot of details about it: https://developers.redhat.com/articles/2022/09/26/find-errors-packages-th... There is a COPR package available to ease installation: https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/ And a detailed Howto available in the source README: https://gitlab.com/fedora/packager-tools/mass-prebuild/-/blob/main/README.md As of today, the tool provides most of the planned features, although it only uses COPR as a builder backend, whereas Koji is also planned on the long run (and likely others). Since the tool is fairly new, it lacks manpages, may miss features you would expect and is likely to have bugs (even if we tried to limit them as much as possible). Therefore, don't hesitate to open issues in the Gitlab repository if need be: https://gitlab.com/fedora/packager-tools/mass-prebuild/-/issues. Frédéric Bérat Senior Software Engineer, Platform Tools Red Hat <https://www.redhat.com> fberat(a)redhat.com <https://www.redhat.com>

1 year, 2 months

1
1
0 / 0

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, 2 months

3
6
0 / 0

qemu on i686

by Richard W.M. Jones

I've spent the day fixing various issues in qemu on Rawhide, but there's one remaining issue. The tests stubbornly fail on i686. It seems as if there is some issue with TLS (is gnutls borked on i686?) https://koji.fedoraproject.org/koji/taskinfo?taskID=98075482 [Ignore the transient aarch64 failure ...] Why are we building qemu on i686? Although leaf packages can decide to drop i686 unilaterally, and I am sorely tempted, this is a critical package so I'd like to know if you have a valid use case for qemu, qemu-img etc on i686. https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval If we remove qemu it will likely have ripple effects through the rest of the virt stack, which we'll deal with (by excluding i686 on those too). 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

1 year, 2 months

8
19
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel February 2023