Hello.
The following packages are downgrades when I attempt upgrade from Fedora 32 to Fedora 33:
- containers-common (skopeo) 1:1.1.1 -> 1:1.0.1 - fuse-overlayfs 1.1.2 -> 1.1.0 - strace 5.8 -> 5.7.0.6.7ab6 - thunderbird 668.11.0 -> 8.10.0
Is this expected?
On Mon, Aug 24, 2020 at 1:01 PM Miro Hrončok mhroncok@redhat.com wrote:
Hello.
The following packages are downgrades when I attempt upgrade from Fedora 32 to Fedora 33:
- containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
- fuse-overlayfs 1.1.2 -> 1.1.0
- strace 5.8 -> 5.7.0.6.7ab6
- thunderbird 668.11.0 -> 8.10.0
Is this expected?
-- Miro Hrončok
Thanks to your reminder, I ran a small scripted analysis of repository contents to compare 32 to 33:
Downgraded packages: - R-data.table is newer in 32 than in 33: 0:1.13.0-1.fc32 > 0:1.12.8-4.fc33 - apcupsd is newer in 32 than in 33: 0:3.14.14-18.fc32 > 0:3.14.14-17.fc32 - apcupsd-cgi is newer in 32 than in 33: 0:3.14.14-18.fc32 > 0:3.14.14-17.fc32 - apcupsd-gui is newer in 32 than in 33: 0:3.14.14-18.fc32 > 0:3.14.14-17.fc32 - appliance-tools is newer in 32 than in 33: 0:010.1-1.fc32 > 0:010.0-3.fc33 - appstream-data is newer in 32 than in 33: 0:32-8.fc32 > 0:32-7.fc33 - blender is newer in 32 than in 33: 1:2.83.1-1.fc32 > 1:2.82a-5.fc33 - blender-fonts is newer in 32 than in 33: 1:2.83.1-1.fc32 > 1:2.82a-5.fc33 - blender-luxcorerender is newer in 32 than in 33: 0:2.4-1.fc32 > 0:2.3-3.fc33 - blender-rpm-macros is newer in 32 than in 33: 1:2.83.1-1.fc32 > 1:2.82a-5.fc33 - bpytop is newer in 32 than in 33: 0:1.0.17-1.fc32 > 0:1.0.16-1.fc33 - buildah is newer in 32 than in 33: 0:1.15.1-1.fc32 > 0:1.15.0-0.68.dev.git2c46b4b.fc33 - buildah-tests is newer in 32 than in 33: 0:1.15.1-1.fc32 > 0:1.15.0-0.68.dev.git2c46b4b.fc33 - buildbot is newer in 32 than in 33: 0:2.8.3-2.fc32 > 0:2.5.1-4.fc33 - buildbot-master is newer in 32 than in 33: 0:2.8.3-2.fc32 > 0:2.5.1-4.fc33 - buildbot-worker is newer in 32 than in 33: 0:2.8.3-2.fc32 > 0:2.5.1-4.fc33 - buildbot-www is newer in 32 than in 33: 0:2.8.3-2.fc32 > 0:2.5.1-4.fc33 - ck is newer in 32 than in 33: 0:0.7.0-3.fc32 > 0:0.6.0-10.fc32 - ck-devel is newer in 32 than in 33: 0:0.7.0-3.fc32 > 0:0.6.0-10.fc32 - cockpit is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-bridge is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-dashboard is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-doc is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-kdump is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-machines is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-networkmanager is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-packagekit is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-pcp is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-podman is newer in 32 than in 33: 0:22-1.fc32 > 0:21-1.fc33 - cockpit-selinux is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-sosreport is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-storaged is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-system is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-tests is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - cockpit-ws is newer in 32 than in 33: 0:226-1.fc32 > 0:225-1.fc33 - containers-common is newer in 32 than in 33: 1:1.1.1-1.fc32 > 1:1.0.1-16.dev.git091f924.fc33 - darktable is newer in 32 than in 33: 0:3.2.1-1.fc32 > 0:3.0.0-3.fc32 - darktable-tools-noise is newer in 32 than in 33: 0:3.2.1-1.fc32 > 0:3.0.0-3.fc32 - dogtag-pki is newer in 32 than in 33: 0:10.9.2-2.fc32 > 0:10.9.2-1.fc33 - dogtag-pki-console-theme is newer in 32 than in 33: 0:10.9.2-2.fc32 > 0:10.9.2-1.fc33 - dogtag-pki-server-theme is newer in 32 than in 33: 0:10.9.2-2.fc32 > 0:10.9.2-1.fc33 - elementary-greeter is newer in 32 than in 33: 0:5.0.4-1.fc32 > 0:5.0.3-1.fc33 - fdupes is newer in 32 than in 33: 1:2.1.1-1.fc32 > 1:2.1.0-2.fc33 - fedmsg is newer in 32 than in 33: 0:1.1.2-1.fc32 > 0:1.1.1-11.fc33 - fedmsg-base is newer in 32 than in 33: 0:1.1.2-1.fc32 > 0:1.1.1-11.fc33 - fedmsg-doc is newer in 32 than in 33: 0:1.1.2-1.fc32 > 0:1.1.1-11.fc33 - firefox is newer in 32 than in 33: 0:79.0-5.fc32 > 0:78.0.2-1.fc33 - firefox-pkcs11-loader is newer in 32 than in 33: 0:3.13.6-1.fc32 > 0:3.13.4-1.fc32 - firefox-wayland is newer in 32 than in 33: 0:79.0-5.fc32 > 0:78.0.2-1.fc33 - firefox-x11 is newer in 32 than in 33: 0:79.0-5.fc32 > 0:78.0.2-1.fc33 - fuse-overlayfs is newer in 32 than in 33: 0:1.1.2-1.fc32 > 0:1.1.0-11.dev.git800011b.fc33 - gala is newer in 32 than in 33: 0:3.3.2-1.fc32 > 0:3.3.1-1.fc33 - gala-devel is newer in 32 than in 33: 0:3.3.2-1.fc32 > 0:3.3.1-1.fc33 - gala-libs is newer in 32 than in 33: 0:3.3.2-1.fc32 > 0:3.3.1-1.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 - golang-github-willf-bitset-devel is newer in 32 than in 33: 0:1.1.11-1.fc32 > 0:1.1.10-5.fc33 - hyperscan is newer in 32 than in 33: 0:5.3.0-1.fc32 > 0:5.2.1-2.fc32 - hyperscan-devel is newer in 32 than in 33: 0:5.3.0-1.fc32 > 0:5.2.1-2.fc32 - kdevelop-python is newer in 32 than in 33: 0:5.5.2-1.fc32 > 0:5.5.1-1.fc33 - libdkimpp is newer in 32 than in 33: 0:2.0.0-6.fc32 > 0:2.0.0-3.fc32 - libdkimpp-devel is newer in 32 than in 33: 0:2.0.0-6.fc32 > 0:2.0.0-3.fc32 - libmediainfo is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 - libmediainfo-devel is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 - luxcorerender is newer in 32 than in 33: 0:2.4-1.fc32 > 0:2.3-3.fc33 - luxcorerender-core is newer in 32 than in 33: 0:2.4-1.fc32 > 0:2.3-3.fc33 - luxcorerender-devel is newer in 32 than in 33: 0:2.4-1.fc32 > 0:2.3-3.fc33 - mediainfo is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 - mediainfo-gui is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 - mediainfo-qt 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 - neovim is newer in 32 than in 33: 0:0.4.4-1.fc32 > 0:0.4.3-5.fc33 - oci-seccomp-bpf-hook is newer in 32 than in 33: 0:1.2.0-1.fc32 > 0:0.0.1-0.6.gitba7bbb16.fc33 - pki-tests is newer in 32 than in 33: 0:10.9.2-2.fc32 > 0:10.9.2-1.fc33 - procps-ng is newer in 32 than in 33: 0:3.3.16-1.fc32 > 0:3.3.15-9.fc33 - procps-ng-devel is newer in 32 than in 33: 0:3.3.16-1.fc32 > 0:3.3.15-9.fc33 - procps-ng-i18n is newer in 32 than in 33: 0:3.3.16-1.fc32 > 0:3.3.15-9.fc33 - python3-certbot-dns-google is newer in 32 than in 33: 0:1.7.0-1.fc32 > 0:1.5.0-1.fc33 - python3-dask+array is newer in 32 than in 33: 0:2.23.0-1.fc32~bootstrap > 0:2.21.0-2.fc33~bootstrap - python3-dask+bag is newer in 32 than in 33: 0:2.23.0-1.fc32~bootstrap > 0:2.21.0-2.fc33~bootstrap - python3-dask+dataframe is newer in 32 than in 33: 0:2.23.0-1.fc32~bootstrap > 0:2.21.0-2.fc33~bootstrap - python3-dask+delayed is newer in 32 than in 33: 0:2.23.0-1.fc32~bootstrap > 0:2.21.0-2.fc33~bootstrap - python3-dask is newer in 32 than in 33: 0:2.23.0-1.fc32~bootstrap > 0:2.21.0-2.fc33~bootstrap - python3-fedmsg is newer in 32 than in 33: 0:1.1.2-1.fc32 > 0:1.1.1-11.fc33 - python3-luxcorerender is newer in 32 than in 33: 0:2.4-1.fc32 > 0:2.3-3.fc33 - python3-magic is newer in 32 than in 33: 0:5.38-2.fc32 > 0:0.4.15-4.fc33 - python3-ogr is newer in 32 than in 33: 0:0.13.1-1.fc32 > 0:0.13.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 - python3-tmt is newer in 32 than in 33: 0:0.20-1.fc32 > 0:0.19-1.fc33 - radare2 is newer in 32 than in 33: 0:4.5.0-2.fc32 > 0:4.5.0-1.fc33.1 - radare2-common is newer in 32 than in 33: 0:4.5.0-2.fc32 > 0:4.5.0-1.fc33.1 - radare2-devel is newer in 32 than in 33: 0:4.5.0-2.fc32 > 0:4.5.0-1.fc33.1 - relval is newer in 32 than in 33: 0:2.5.1-1.fc32 > 0:2.5.0-3.fc33 - rpm-ostree is newer in 32 than in 33: 0:2020.4-1.fc32 > 0:2020.3-1.fc33 - rpm-ostree-devel is newer in 32 than in 33: 0:2020.4-1.fc32 > 0:2020.3-1.fc33 - rpm-ostree-libs is newer in 32 than in 33: 0:2020.4-1.fc32 > 0:2020.3-1.fc33 - skopeo is newer in 32 than in 33: 1:1.1.1-1.fc32 > 1:1.0.1-16.dev.git091f924.fc33 - skopeo-tests is newer in 32 than in 33: 1:1.1.1-1.fc32 > 1:1.0.1-16.dev.git091f924.fc33 - strace is newer in 32 than in 33: 0:5.8-1.fc32 > 0:5.7.0.6.7ab6-1.fc33 - swift-lang is newer in 32 than in 33: 0:5.2.5-1.fc32 > 0:5.2.4-3.fc33 - swtpm is newer in 32 than in 33: 0:0.3.4-1.20200811git80f0418.fc32 > 0:0.3.0-4.20200218git74ae43b.fc33 - swtpm-devel is newer in 32 than in 33: 0:0.3.4-1.20200811git80f0418.fc32 > 0:0.3.0-4.20200218git74ae43b.fc33 - swtpm-libs is newer in 32 than in 33: 0:0.3.4-1.20200811git80f0418.fc32 > 0:0.3.0-4.20200218git74ae43b.fc33 - swtpm-tools is newer in 32 than in 33: 0:0.3.4-1.20200811git80f0418.fc32 > 0:0.3.0-4.20200218git74ae43b.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 - tmt is newer in 32 than in 33: 0:0.20-1.fc32 > 0:0.19-1.fc33 - tmt-all is newer in 32 than in 33: 0:0.20-1.fc32 > 0:0.19-1.fc33 - tmt-provision-container is newer in 32 than in 33: 0:0.20-1.fc32 > 0:0.19-1.fc33 - tmt-provision-virtual is newer in 32 than in 33: 0:0.20-1.fc32 > 0:0.19-1.fc33 - wingpanel is newer in 32 than in 33: 0:2.3.2-1.fc32 > 0:2.3.1-2.fc33 - wingpanel-devel is newer in 32 than in 33: 0:2.3.2-1.fc32 > 0:2.3.1-2.fc33 - wingpanel-libs is newer in 32 than in 33: 0:2.3.2-1.fc32 > 0:2.3.1-2.fc33 - yoshimi is newer in 32 than in 33: 0:1.7.2-1.fc32 > 0:1.7.1-2.fc33
While I can't confirm the thunderbird issue (which looks like it's caused by F33FTBFS), your other downgrades are in this list.
Most other downgrades seem to be caused by packagers submitting updates for f34 and f32 but forgetting f33.
Fabio
On Mon, Aug 24, 2020 at 8:42 AM Fabio Valentini decathorpe@gmail.com wrote:
[...]
- appliance-tools is newer in 32 than in 33: 0:010.1-1.fc32 > 0:010.0-3.fc33
Something is wrong here, as Bodhi automatically submitted it yesterday to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f6a9b16a4
On Mon, Aug 24, 2020 at 2:45 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Aug 24, 2020 at 8:42 AM Fabio Valentini decathorpe@gmail.com wrote:
[...]
- appliance-tools is newer in 32 than in 33: 0:010.1-1.fc32 > 0:010.0-3.fc33
Something is wrong here, as Bodhi automatically submitted it yesterday to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f6a9b16a4
It's possible that the repo mirror I hit hasn't gotten this update push yet. I'll re-run the script later (or the day after tomorrow, after the beta freeze) and file bugs for the remaining downgrades.
Fabio
On Mon, Aug 24, 2020 at 8:52 AM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Aug 24, 2020 at 2:45 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Aug 24, 2020 at 8:42 AM Fabio Valentini decathorpe@gmail.com wrote:
[...]
- appliance-tools is newer in 32 than in 33: 0:010.1-1.fc32 > 0:010.0-3.fc33
Something is wrong here, as Bodhi automatically submitted it yesterday to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1f6a9b16a4
It's possible that the repo mirror I hit hasn't gotten this update push yet. I'll re-run the script later (or the day after tomorrow, after the beta freeze) and file bugs for the remaining downgrades.
No, something is definitely wrong, because last night's F33 compose also had the same problem. I literally released that to attempt to fix image builds yesterday and it wasn't even used.
On Mon, Aug 24, 2020 at 3:04 PM Neal Gompa ngompa13@gmail.com wrote:
No, something is definitely wrong, because last night's F33 compose also had the same problem. I literally released that to attempt to fix image builds yesterday and it wasn't even used.
Oh. Yeah then something is *definitely* wrong with f33 composes. See also: https://pagure.io/releng/issue/9683#comment-672206
Fabio
On 8/24/20 07:00, Miro Hrončok wrote:
Hello.
The following packages are downgrades when I attempt upgrade from Fedora 32 to Fedora 33:
- containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
- fuse-overlayfs 1.1.2 -> 1.1.0
- strace 5.8 -> 5.7.0.6.7ab6
- thunderbird 668.11.0 -> 8.10.0
Is this expected?
Definitely not on the first two. I have asked the maintainers to look into it. Looks like packages in rawhide are failing to build.
On Tue, Aug 25, 2020 at 1:32 PM Daniel Walsh dwalsh@redhat.com wrote:
On 8/24/20 07:00, Miro Hrončok wrote:
Hello.
The following packages are downgrades when I attempt upgrade from Fedora 32 to Fedora 33:
- containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
- fuse-overlayfs 1.1.2 -> 1.1.0
- strace 5.8 -> 5.7.0.6.7ab6
- thunderbird 668.11.0 -> 8.10.0
Is this expected?
Definitely not on the first two. I have asked the maintainers to look into it. Looks like packages in rawhide are failing to build.
The container stack never seems to be dealt with well in the branching stage of the release, this isn't the first time I've noticed that, could it be added to a process or similar to ensure it's smooth, not sure we want individual commit related builds once we've branched and headed for beta.
Peter
On Tue, Aug 25, 2020 at 3:13 PM Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Aug 25, 2020 at 1:32 PM Daniel Walsh dwalsh@redhat.com wrote:
On 8/24/20 07:00, Miro Hrončok wrote:
Hello.
The following packages are downgrades when I attempt upgrade from Fedora 32 to Fedora 33:
- containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
- fuse-overlayfs 1.1.2 -> 1.1.0
- strace 5.8 -> 5.7.0.6.7ab6
- thunderbird 668.11.0 -> 8.10.0
Is this expected?
Definitely not on the first two. I have asked the maintainers to look into it. Looks like packages in rawhide are failing to build.
The container stack never seems to be dealt with well in the branching stage of the release, this isn't the first time I've noticed that, could it be added to a process or similar to ensure it's smooth, not sure we want individual commit related builds once we've branched and headed for beta.
Peter
Do you think it would be a good idea to file bugs for those packages where a build for f33 was "forgotten"? Since I already have the "downgrade check" scripted [0] it's a simple task of:
- check if the package has attempted build for f33 - if yes, check if it's FTBFS, and don't report a bug - if no build was attempted for f33, report a bug
I see ~100 downgraded *binary* packages going from fully updated f32 to fully updated f33. The number of affected *source* packages is naturally lower than that. The script also doesn't account for packages being renamed (but in those cases, proper Obsoletes and Provides need to be present during package review, so I don't think this is a problem).
Fabio
[0]: https://gist.github.com/decathorpe/9b8bf35404c11b4ebf73d06ff303bc88
On Tue, Aug 25, 2020 at 08:14:38PM +0200, Fabio Valentini wrote:
Do you think it would be a good idea to file bugs for those packages where a build for f33 was "forgotten"? Since I already have the "downgrade check" scripted [0] it's a simple task of:
- check if the package has attempted build for f33
- if yes, check if it's FTBFS, and don't report a bug
- if no build was attempted for f33, report a bug
I see ~100 downgraded *binary* packages going from fully updated f32 to fully updated f33. The number of affected *source* packages is naturally lower than that. The script also doesn't account for packages being renamed (but in those cases, proper Obsoletes and Provides need to be present during package review, so I don't think this is a problem).
Yes, I think that would be lovely.
kevin
On Tue, Aug 25, 2020 at 9:33 PM kevin kevin@scrye.com wrote:
On Tue, Aug 25, 2020 at 08:14:38PM +0200, Fabio Valentini wrote:
Do you think it would be a good idea to file bugs for those packages where a build for f33 was "forgotten"? Since I already have the "downgrade check" scripted [0] it's a simple task of:
- check if the package has attempted build for f33
- if yes, check if it's FTBFS, and don't report a bug
- if no build was attempted for f33, report a bug
I see ~100 downgraded *binary* packages going from fully updated f32 to fully updated f33. The number of affected *source* packages is naturally lower than that. The script also doesn't account for packages being renamed (but in those cases, proper Obsoletes and Provides need to be present during package review, so I don't think this is a problem).
Yes, I think that would be lovely.
kevin
I'm on it.
By the way, I'm finding some weird issues where packages are tagged with f33 in koji for a few days but an *older* build is in the repos, e.g. appliance-tools and ddgr.
Fabio
On Wed, Aug 26, 2020 at 11:45:48AM +0200, Fabio Valentini wrote:
On Tue, Aug 25, 2020 at 9:33 PM kevin kevin@scrye.com wrote:
On Tue, Aug 25, 2020 at 08:14:38PM +0200, Fabio Valentini wrote:
Do you think it would be a good idea to file bugs for those packages where a build for f33 was "forgotten"? Since I already have the "downgrade check" scripted [0] it's a simple task of:
- check if the package has attempted build for f33
- if yes, check if it's FTBFS, and don't report a bug
- if no build was attempted for f33, report a bug
I see ~100 downgraded *binary* packages going from fully updated f32 to fully updated f33. The number of affected *source* packages is naturally lower than that. The script also doesn't account for packages being renamed (but in those cases, proper Obsoletes and Provides need to be present during package review, so I don't think this is a problem).
Yes, I think that would be lovely.
kevin
I'm on it.
By the way, I'm finding some weird issues where packages are tagged with f33 in koji for a few days but an *older* build is in the repos, e.g. appliance-tools and ddgr.
I am not seeing that here. Could be a mirror issue?
I ran out check_latest_build script on f33 (which looks at each package and tries to figure out if the last tagged one is the 'highest').
It gives:
containernetworking-plugins-0.8.6-1.fc33 < containernetworking-plugins-0.8.6-11.1.gitbd58999.fc33 crun-0.14.1-1.fc33 < crun-0.14.1-2.fc33 fabtests-1.11.0-1.fc33 < fabtests-1.11.0rc2-1.fc33 igt-gpu-tools-1.25-1.20200818git4e5f76b.fc33 < igt-gpu-tools-1.25-2.20200719git9b964d7.fc33 libfabric-1.11.0-1.fc33 < libfabric-1.11.0rc2-1.fc33 slirp4netns-1.1.4-1.fc33 < slirp4netns-1.1.4-4.dev.giteecccdb.fc33 stdair-1.00.10-5.fc33 < stdair-1.00.10-6.fc33 sympa-6.2.56-2.fc33 < sympa-6.2.56-2.fc33.1
kevin
On Wed, Aug 26, 2020 at 7:11 PM kevin kevin@scrye.com wrote:
On Wed, Aug 26, 2020 at 11:45:48AM +0200, Fabio Valentini wrote:
On Tue, Aug 25, 2020 at 9:33 PM kevin kevin@scrye.com wrote:
On Tue, Aug 25, 2020 at 08:14:38PM +0200, Fabio Valentini wrote:
Do you think it would be a good idea to file bugs for those packages where a build for f33 was "forgotten"? Since I already have the "downgrade check" scripted [0] it's a simple task of:
- check if the package has attempted build for f33
- if yes, check if it's FTBFS, and don't report a bug
- if no build was attempted for f33, report a bug
I see ~100 downgraded *binary* packages going from fully updated f32 to fully updated f33. The number of affected *source* packages is naturally lower than that. The script also doesn't account for packages being renamed (but in those cases, proper Obsoletes and Provides need to be present during package review, so I don't think this is a problem).
Yes, I think that would be lovely.
kevin
I'm on it.
By the way, I'm finding some weird issues where packages are tagged with f33 in koji for a few days but an *older* build is in the repos, e.g. appliance-tools and ddgr.
I am not seeing that here. Could be a mirror issue?
I ran out check_latest_build script on f33 (which looks at each package and tries to figure out if the last tagged one is the 'highest').
It gives:
containernetworking-plugins-0.8.6-1.fc33 < containernetworking-plugins-0.8.6-11.1.gitbd58999.fc33 crun-0.14.1-1.fc33 < crun-0.14.1-2.fc33 fabtests-1.11.0-1.fc33 < fabtests-1.11.0rc2-1.fc33 igt-gpu-tools-1.25-1.20200818git4e5f76b.fc33 < igt-gpu-tools-1.25-2.20200719git9b964d7.fc33 libfabric-1.11.0-1.fc33 < libfabric-1.11.0rc2-1.fc33 slirp4netns-1.1.4-1.fc33 < slirp4netns-1.1.4-4.dev.giteecccdb.fc33 stdair-1.00.10-5.fc33 < stdair-1.00.10-6.fc33 sympa-6.2.56-2.fc33 < sympa-6.2.56-2.fc33.1
kevin
Hrm. It looks like at least some of those issues were transient, yes. However, two issues are still left:
- libdkimpp-2.0.0-6.fc33 is tagged with f33 and f34 but 2.0.0-3.fc32 is in the f33 repos - swift-lang-5.2.5-1.fc33 is tagged with f33 and f34 but 5.2.4-3.fc33 is in the f33 repos
Both these packages were built ~two weeks ago, so maybe they were screwed up by the mass branching somehow?
Fabio
On Wed, Aug 26, 2020 at 07:18:49PM +0200, Fabio Valentini wrote:
Hrm. It looks like at least some of those issues were transient, yes. However, two issues are still left:
- libdkimpp-2.0.0-6.fc33 is tagged with f33 and f34 but 2.0.0-3.fc32
is in the f33 repos
f34 should have been fine... f33 the newer one was only tagged in this morning:
Wed Aug 26 03:25:54 2020 libdkimpp-2.0.0-6.fc33 tagged into f33 by humaton [still active]
So it should be in today's f33 compose, but indeed I don't see it there. Odd.
oh. Man. I sure hate timezones. ;)
It was tagged after the f33 compose started.
- swift-lang-5.2.5-1.fc33 is tagged with f33 and f34 but 5.2.4-3.fc33
is in the f33 repos
Same here. Tagged in this morning, should be fixed tomorrow.
Both these packages were built ~two weeks ago, so maybe they were screwed up by the mass branching somehow?
Yeah, possibly so.
kevin
On Wed, Aug 26, 2020 at 1:53 PM kevin kevin@scrye.com wrote:
On Wed, Aug 26, 2020 at 07:18:49PM +0200, Fabio Valentini wrote:
Hrm. It looks like at least some of those issues were transient, yes. However, two issues are still left:
- libdkimpp-2.0.0-6.fc33 is tagged with f33 and f34 but 2.0.0-3.fc32
is in the f33 repos
f34 should have been fine... f33 the newer one was only tagged in this morning:
Wed Aug 26 03:25:54 2020 libdkimpp-2.0.0-6.fc33 tagged into f33 by humaton [still active]
So it should be in today's f33 compose, but indeed I don't see it there. Odd.
oh. Man. I sure hate timezones. ;)
It was tagged after the f33 compose started.
- swift-lang-5.2.5-1.fc33 is tagged with f33 and f34 but 5.2.4-3.fc33
is in the f33 repos
Same here. Tagged in this morning, should be fixed tomorrow.
I untagged them since they are directly tagged to f33 tag without getting right with fedora-33 key. I am tagging them to f33-updates-candidate to let bodhi take care of the process flow since we are in freeze now.
Both these packages were built ~two weeks ago, so maybe they were screwed up by the mass branching somehow?
Yeah, possibly so.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@lists.fedoraproject.org
On Thu, Aug 27, 2020 at 9:42 AM Mohan Boddu mboddu@bhujji.com wrote:
On Wed, Aug 26, 2020 at 1:53 PM kevin kevin@scrye.com wrote:
On Wed, Aug 26, 2020 at 07:18:49PM +0200, Fabio Valentini wrote:
Hrm. It looks like at least some of those issues were transient, yes. However, two issues are still left:
- libdkimpp-2.0.0-6.fc33 is tagged with f33 and f34 but 2.0.0-3.fc32
is in the f33 repos
f34 should have been fine... f33 the newer one was only tagged in this morning:
Wed Aug 26 03:25:54 2020 libdkimpp-2.0.0-6.fc33 tagged into f33 by humaton [still active]
So it should be in today's f33 compose, but indeed I don't see it there. Odd.
oh. Man. I sure hate timezones. ;)
It was tagged after the f33 compose started.
- swift-lang-5.2.5-1.fc33 is tagged with f33 and f34 but 5.2.4-3.fc33
is in the f33 repos
Same here. Tagged in this morning, should be fixed tomorrow.
I untagged them since they are directly tagged to f33 tag without getting right with fedora-33 key. I am tagging them to f33-updates-candidate to let bodhi take care of the process flow since we are in freeze now.
And its not possible, since there is a update with the same build that got pushed to f34, sigh.
I will work with adamw in creating a FBR to push these updates directly to the f33 tag.
Both these packages were built ~two weeks ago, so maybe they were screwed up by the mass branching somehow?
Yeah, possibly so.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@lists.fedoraproject.org
I fixed skopeo and fuse-overlayfs earlier today, so hopefully we should be good on those soon.
On Mon, Aug 24, 2020 at 01:00:58PM +0200, Miro Hron??ok wrote:
Hello.
The following packages are downgrades when I attempt upgrade from Fedora 32 to Fedora 33:
- containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
- fuse-overlayfs 1.1.2 -> 1.1.0
- strace 5.8 -> 5.7.0.6.7ab6
- thunderbird 668.11.0 -> 8.10.0
Is this expected?
-- Miro Hron??ok -- Phone: +420777974800 IRC: mhroncok