Unannounced soname bump: libreport
by Adam Williamson
A new build of libreport was done for all releases today by mfabik:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592551
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592550
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592524
https://koji.fedoraproject.org/koji/buildinfo?buildID=1592531
This build changes the soname of libreport from libreport.so.0 to
libreport.so.1 (and indeed does introduce several API and ABI changes).
It was sent out as a 'stable' update for F31 and F32 (despite the
soname bump). None of libreport's dependencies - notably including abrt
- have been rebuilt for any release, AFAIK.
This means abrt is uninstallable in F33 and Rawhide build roots at
present and probably will break subsequent F33 and Rawhide composes
because there are probably release-blocking images with abrt in them. I
have filed negative karma on the F31 and F32 updates, which failed
openQA testing due to this issue.
It seems a new release of abrt has been made upstream, but at least one
commit *after* that release looks necessary for the latest libreport.
Additionally my first attempt to build the new release failed because
the tarball was missing a file:
https://github.com/abrt/abrt/issues/1519
I am continuing to try and get a successful abrt build, but if we can't
manage at least that, we will need to untag this build for F33 and
Rawhide.
Other dependencies are abrt-java-connector and reportd, which I haven't
looked into it detail yet.
Please remember to announce soname bumps ahead of time so this kind of
problem can be avoided. Thanks. Please also try and generally do a
better job of release engineering and co-ordination...:)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3 years, 7 months
F33 and GNOME megaupdate planning
by Kalev Lember
Hi all,
Fedora 33 went into Beta freeze yesterday so we need to do a bit of
planning how we handle GNOME megaupdates during that time. This is how
my plan looks like:
GNOME 3.37.91 was released during this weekend. I was keeping an eye on
the modules and built everything as they were released upstream, so we
went into the Beta freeze fully up to date (with the exception of
gnome-terminal and vte291 which are still at 3.36.x versions and need
maintainer attention due to a large number of downstream patches).
The next GNOME release is .92 in two weeks. At that point, we are deep
into the Beta freeze in Fedora land and don't have much schedule room
left. I think it's best to not ask for a freeze break to land .92 at
that point.
After that comes the .0 release just one week after .92.
My plan is to collect all the GNOME updates that are released in that
time and put together a megaupdate in Bodhi for .92. If something urgent
comes up during that time (something that warrants a freeze break) then
this should go to Bodhi separately, so that we can pull those individual
fixes through the Beta freeze as needed. Anything else I think it's best
to wait for the .92 megaupdate.
The .92 megaupdate is likely never going to go stable (as we are going
to be in freeze at that point) and is likely just going to get replaced
by .0 megaupdate a week later.
We also have a f33-gnome side tag in koji now. If you are helping with
builds, please use the side tag for any builds that you want to be part
of the megaupdates.
(I've cross-posted this to both the desktop@ and devel@ mailing lists.)
--
Kalev
3 years, 7 months
Package downgrades from f32 -> f33 (categorized list inside)
by Fabio Valentini
Following up on the recent discussion, I've checked repository
contents of f32 and f33 for downgrades and categorized them. I also
dropped packages with F33FTBFS issues from the list since for these
the reason for the downgrade is already documented as a bug.
# Koji tagging / compose issues?
(builds are either missing from the f33 tag for no reason or are tagged with
f33 but not included in composes)
- distgen is newer in 32 than in 33:
0:1.6-1.fc32 > 0:1.5-3.fc33
- enchant2 is newer in 32 than in 33:
0:2.2.9-1.fc32 > 0:2.2.8-2.fc33
- libdkimpp is newer in 32 than in 33:
0:2.0.0-6.fc32 > 0:2.0.0-3.fc32
- swift-lang is newer in 32 than in 33:
0:5.2.5-1.fc32 > 0:5.2.4-3.fc33
# Built for f34 (and f32) but not f33:
(packages were updated but package maintainer seems to have missed the f33
branch point and has not submitted updates for f33)
- ck is newer in 32 than in 33:
0:0.7.0-3.fc32 > 0:0.6.0-10.fc32
- cockpit-podman is newer in 32 than in 33:
0:22-1.fc32 > 0:21-1.fc33
- fdupes is newer in 32 than in 33:
1:2.1.1-1.fc32 > 1:2.1.0-2.fc33
- golang-github-willf-bitset is newer in 32 than in 33:
0:1.1.11-1.fc32 > 0:1.1.10-5.fc33
- libmediainfo is newer in 32 than in 33:
0:20.08-1.fc32 > 0:20.03-3.fc33
- mediainfo is newer in 32 than in 33:
0:20.08-1.fc32 > 0:20.03-3.fc33
- ncmpc is newer in 32 than in 33:
0:0.39-1.fc32 > 0:0.38-2.fc33
- procps-ng is newer in 32 than in 33:
0:3.3.16-1.fc32 > 0:3.3.15-9.fc33
- python-ogr is newer in 32 than in 33:
0:0.13.1-1.fc32 > 0:0.13.0-1.fc33
- rpm-ostree is newer in 32 than in 33:
0:2020.4-1.fc32 > 0:2020.3-1.fc33
- yoshimi is newer in 32 than in 33:
0:1.7.2-1.fc32 > 0:1.7.1-2.fc33
# Missing only bodhi updates:
(packages were updated for f33 after beta freeze but no bodhi updates were
submitted)
- blender is newer in 32 than in 33:
1:2.83.1-1.fc32 > 1:2.82a-5.fc33
- fuse-overlayfs is newer in 32 than in 33:
0:1.1.2-1.fc32 > 0:1.1.0-11.dev.git800011b.fc33
- relval is newer in 32 than in 33:
0:2.5.1-1.fc32 > 0:2.5.0-3.fc33
- skopeo is newer in 32 than in 33:
1:1.1.1-1.fc32 > 1:1.0.1-16.dev.git091f924.fc33
# Package downgrades (not updated in master / f33):
(packages were only updated in stable branches, but never in master or f33)
- appstream-data is newer in 32 than in 33:
0:32-8.fc32 > 0:32-7.fc33
- buildah is newer in 32 than in 33:
0:1.15.1-1.fc32 > 0:1.15.0-0.68.dev.git2c46b4b.fc33
- containers-common is newer in 32 than in 33:
1:1.1.1-1.fc32 > 1:1.0.1-16.dev.git091f924.fc33
- fedmsg is newer in 32 than in 33:
0:1.1.2-1.fc32 > 0:1.1.1-11.fc33
- gnome-remote-desktop is newer in 32 than in 33:
0:0.1.8-2.fc32 > 0:0.1.7-5.fc33
- gnome-shell-extension-material-shell is newer in 32 than in 33:
0:3-2.fc32 > 0:3-1.fc33
- python-certbot-dns-google is newer in 32 than in 33:
0:1.7.0-1.fc32 > 0:1.5.0-1.fc33
- python3-operator-courier is newer in 32 than in 33:
0:2.1.9-3.fc32 > 0:2.1.9-2.fc33
# Weird Release tag screws up rpmdev-bumpspec:
(rpmdev-bumpspec screwed up the upgrade path due to mass rebuild commit)
- radare2 is newer in 32 than in 33:
0:4.5.0-2.fc32 > 0:4.5.0-1.fc33.1
# Packages not included in mass rebuild?
- tmt is newer in 32 than in 33:
0:0.20-1.fc32 > 0:0.19-1.fc33
# Uh, WTF?
(no idea what went wrong here)
- python3-magic is newer in 32 than in 33:
0:5.38-2.fc32 > 0:0.4.15-4.fc33
- texlive-arphic is newer in 32 than in 33:
9:svn15878.0-21.fc32 > 9:svn15878-27.fc33
- texlive-babel-malay-doc is newer in 32 than in 33:
9:svn43235-21.fc32 > 9:svn43234-27.fc33
- texlive-tudscr is newer in 32 than in 33:
9:svn51675-21.fc32 > 9:LPPL-27.fc33
If you see one of your packages on this list, please remedy the
downgrade / upgrade path issue accordingly, if possible. We don't want
f33 to have older software than f32 :)
Fabio
3 years, 7 months
New version of net-snmp + soname bump
by Josef Ridky
Hi folks,
upstream authors has released new major version of net-snmp that is now heading to Rawhide and F33.
As part of this update, soname will change from .35 to .40.
I would like to ask all maintainers, that rely on some part from net-snmp to rebuild their packages with new version of net-snmp once available.
For rawhide, update should be available later today. For F33 override will be provided with availability till September 4th, 2020.
Best regards
Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
3 years, 7 months
Re: Proposal to Add: Log In/Out Blocker Criteria
by Kamil Paral
On Wed, Aug 12, 2020 at 4:25 PM Kamil Paral <kparal(a)redhat.com> wrote:
> I'd accept the criterion as proposed (because we need it now), and do the
> reorganization later (possibly when this cycle is over and we have more
> time to bikeshed about best criterion layout). I'm fine with either adding
> to the existing criterion (mine version) or creating a standalone criterion
> (Geoff's version), just note that the standalone version would still need
> to get tweaked (remove "multiple user accounts", etc).
>
In accordance with the discussion during the last QA meeting, I've put my
proposed changes live:
https://fedoraproject.org/w/index.php?title=Fedora_33_Beta_Release_Criter...
3 years, 7 months
