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, 1 month
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, 1 month
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, 1 month
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, 1 month
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, 1 month
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, 1 month
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, 1 month