Re: Another F34 update experience : gtatools-*
On Wed, 2021-04-28 at 18:43 -0400, przemek klosowski wrote: > On 4/28/21 6:01 PM, Adam Williamson wrote: > > > On Wed, 2021-04-28 at 17:42 -0400, przemek klosowski via devel wrote: > > > Trying to update F33 -> F34 on a development laptop with about 4700 > > > packages. I think it started as F30 and did three Fedora system upgrades. > > > ... > > > > > > I am getting four errors: > > > ... > > > The first three can be solved by erasing gtatool-gdal, gtatool-matlab > > > and rdma-core-34.0-1.fc33.i686. The first two are relatively painless, > > > but rdma-core forces the removal of the entire Wine installation--I did > > > it and plan/hope to reinstall Wine after the upgrade. > > It's worth trying the upgrade with --allowerasing instead of rolling > > your own erasures. It may be able to come up with a strategy that > > involves removing less stuff. > > In my defense I am a little apprehensive about --allowerasing because I > have a hole in my pants from being bitten by it years ago and having to > rescue-install hundreds of packages including RPM :). Of course I know > that I don't have to worry about it any more because of protected > packages---in fact one of my 'rolled-own' erasure pulled systemd and > triggered the protected package fuse, so I know it works! Also with system-upgrade there's always a confirmation step, so you can just run it and see what it would do, and cancel if it wants to blow up your system... > However, in this case, --best --allowerasing trips up the following > errors, while plain upgrade just skips packages with conflicts ( > iptables-libs ) and broken dependencies (gst and gwe ). > > Problem 1: problem with installed package gst-0.7.4-2.fc33.noarch > - cannot install the best update candidate for package > gst-0.7.4-2.fc33.noarch > - gst-0.7.4-2.fc33.noarch does not belong to a distupgrade repository > - nothing provides python3-pyxdg >= 0.27 needed by > gst-0.7.5-2.fc34.noarch > Problem 2: problem with installed package gwe-0.15.2-1.fc33.noarch > - cannot install the best update candidate for package > gwe-0.15.2-1.fc33.noarch > - gwe-0.15.2-1.fc33.noarch does not belong to a distupgrade repository > - nothing provides python3-pyxdg >= 0.27 needed by > gwe-0.15.3-1.fc34.noarch > Problem 3: cannot install the best update candidate for package > iptables-1.8.5-6.fc33.x86_64 > - problem with installed package iptables-1.8.5-6.fc33.x86_64 > - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) > = 1.8.7-3.fc34, but none of the providers can be installed > - cannot install the best update candidate for package > iptables-libs-1.8.5-6.fc33.x86_64 > - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and > iptables-libs-1.8.7-6.fc34.x86_64 > - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade > repository > (try to add '--skip-broken' to skip uninstallable packages) > > Indeed adding --best --allowerasing --skip-broken skips those three > packages again, i.e. behaves like a plain system-upgrade with no options. The iptables issue is known, see https://bugzilla.redhat.com/show_bug.cgi?id=1953178 . Try without -- best - just with --allowerasing, or --allowerasing --skip-broken . > > In general, if the problem is basically "package X wasn't rebuilt for a > > library soname bump", the appropriate step is to file a bug against > > package X. For the gtatool stuff, though, it looks to me like it got > > orphaned and retired, but has not been specifically obsoleted; we may > > need to put it in fedora-obsolete-packages. There were several attempts > > to rebuild it between July and November, but they all apparently failed > > (well, the last seems to have succeeded but was never tagged and has > > been garbage-collected), and now it's been orphaned. > > So if they did succeed, wouldn't it make sense to include them? I am a > reasonably heavy Octave user, and although I actually didn't have to > load Matlab files recently, I think it is a useful feature. Maybe Orion > has an opinion about this? Well, I can't really say. All I can see is what happened in Koji: https://koji.fedoraproject.org/koji/buildinfo?buildID=1641421 succeeded, but doesn't seem to have been tagged at all, and that's the last time anyone touched the package. After that, it got orphaned and auto-retired due to being orphaned for a set period of time. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it:
Re: Another F34 update experience : gtatools-*
On 4/28/21 6:01 PM, Adam Williamson wrote: On Wed, 2021-04-28 at 17:42 -0400, przemek klosowski via devel wrote: Trying to update F33 -> F34 on a development laptop with about 4700 packages. I think it started as F30 and did three Fedora system upgrades. ... I am getting four errors: ... The first three can be solved by erasing gtatool-gdal, gtatool-matlab and rdma-core-34.0-1.fc33.i686. The first two are relatively painless, but rdma-core forces the removal of the entire Wine installation--I did it and plan/hope to reinstall Wine after the upgrade. It's worth trying the upgrade with --allowerasing instead of rolling your own erasures. It may be able to come up with a strategy that involves removing less stuff. In my defense I am a little apprehensive about --allowerasing because I have a hole in my pants from being bitten by it years ago and having to rescue-install hundreds of packages including RPM :). Of course I know that I don't have to worry about it any more because of protected packages---in fact one of my 'rolled-own' erasure pulled systemd and triggered the protected package fuse, so I know it works! However, in this case, --best --allowerasing trips up the following errors, while plain upgrade just skips packages with conflicts ( iptables-libs ) and broken dependencies (gst and gwe ). Problem 1: problem with installed package gst-0.7.4-2.fc33.noarch - cannot install the best update candidate for package gst-0.7.4-2.fc33.noarch - gst-0.7.4-2.fc33.noarch does not belong to a distupgrade repository - nothing provides python3-pyxdg >= 0.27 needed by gst-0.7.5-2.fc34.noarch Problem 2: problem with installed package gwe-0.15.2-1.fc33.noarch - cannot install the best update candidate for package gwe-0.15.2-1.fc33.noarch - gwe-0.15.2-1.fc33.noarch does not belong to a distupgrade repository - nothing provides python3-pyxdg >= 0.27 needed by gwe-0.15.3-1.fc34.noarch Problem 3: cannot install the best update candidate for package iptables-1.8.5-6.fc33.x86_64 - problem with installed package iptables-1.8.5-6.fc33.x86_64 - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) = 1.8.7-3.fc34, but none of the providers can be installed - cannot install the best update candidate for package iptables-libs-1.8.5-6.fc33.x86_64 - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and iptables-libs-1.8.7-6.fc34.x86_64 - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade repository (try to add '--skip-broken' to skip uninstallable packages) Indeed adding --best --allowerasing --skip-broken skips those three packages again, i.e. behaves like a plain system-upgrade with no options. In general, if the problem is basically "package X wasn't rebuilt for a library soname bump", the appropriate step is to file a bug against package X. For the gtatool stuff, though, it looks to me like it got orphaned and retired, but has not been specifically obsoleted; we may need to put it in fedora-obsolete-packages. There were several attempts to rebuild it between July and November, but they all apparently failed (well, the last seems to have succeeded but was never tagged and has been garbage-collected), and now it's been orphaned. So if they did succeed, wouldn't it make sense to include them? I am a reasonably heavy Octave user, and although I actually didn't have to load Matlab files recently, I think it is a useful feature. Maybe Orion has an opinion about this? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Another F34 update experience : gtatools-*
On Wed, 2021-04-28 at 17:42 -0400, przemek klosowski via devel wrote: > Trying to update F33 -> F34 on a development laptop with about 4700 > packages. I think it started as F30 and did three Fedora system upgrades. > > I did the standard > > dnf upgrade --refresh > > dnf system-upgrade --releasever=34 download > > I am getting four errors: > > > Problem 1: package gtatool-gdal-2.2.3-6.fc33.x86_64 requires > libgdal.so.27()(64bit), but none of the providers can be installed > - gdal-libs-3.1.4-2.fc33.x86_64 does not belong to a distupgrade > repository > - problem with installed package gtatool-gdal-2.2.3-6.fc33.x86_64 > Problem 2: package gtatool-matlab-2.2.3-6.fc33.x86_64 requires > libmatio.so.9()(64bit), but none of the providers can be installed > - matio-1.5.17-4.fc33.x86_64 does not belong to a distupgrade repository > - problem with installed package gtatool-matlab-2.2.3-6.fc33.x86_64 > Problem 3: rdma-core-34.0-1.fc33.i686 has inferior architecture > - rdma-core-34.0-1.fc33.x86_64 does not belong to a distupgrade > repository > - problem with installed package rdma-core-34.0-1.fc33.i686 > Problem 4: package openexr-libs-2.5.5-1.fc34.x86_64 obsoletes > OpenEXR-libs < 2.5.3 provided by OpenEXR-libs-2.3.0-8.fc34.x86_64 > - package Field3D-1.7.3-10.fc34.x86_64 requires > libHalf-2_5.so.25()(64bit), but none of the providers can be installed > - package Field3D-1.7.3-10.fc34.x86_64 requires > libImath-2_5.so.25()(64bit), but none of the providers can be installed > - package gtatool-hdr-2.2.3-6.fc33.x86_64 requires > libIlmImf-2_3.so.24()(64bit), but none of the providers can be installed > - problem with installed package Field3D-1.7.3-5.fc33.x86_64 > - OpenEXR-libs-2.3.0-6.fc33.x86_64 does not belong to a distupgrade > repository > - Field3D-1.7.3-5.fc33.x86_64 does not belong to a distupgrade repository > - problem with installed package gtatool-hdr-2.2.3-6.fc33.x86_64 > > The first three can be solved by erasing gtatool-gdal, gtatool-matlab > and rdma-core-34.0-1.fc33.i686. The first two are relatively painless, > but rdma-core forces the removal of the entire Wine installation--I did > it and plan/hope to reinstall Wine after the upgrade. It's worth trying the upgrade with --allowerasing instead of rolling your own erasures. It may be able to come up with a strategy that involves removing less stuff. In general, if the problem is basically "package X wasn't rebuilt for a library soname bump", the appropriate step is to file a bug against package X. For the gtatool stuff, though, it looks to me like it got orphaned and retired, but has not been specifically obsoleted; we may need to put it in fedora-obsolete-packages. There were several attempts to rebuild it between July and November, but they all apparently failed (well, the last seems to have succeeded but was never tagged and has been garbage-collected), and now it's been orphaned. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Another F34 update experience : gtatools-*
Trying to update F33 -> F34 on a development laptop with about 4700 packages. I think it started as F30 and did three Fedora system upgrades. I did the standard dnf upgrade --refresh dnf system-upgrade --releasever=34 download I am getting four errors: Problem 1: package gtatool-gdal-2.2.3-6.fc33.x86_64 requires libgdal.so.27()(64bit), but none of the providers can be installed - gdal-libs-3.1.4-2.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package gtatool-gdal-2.2.3-6.fc33.x86_64 Problem 2: package gtatool-matlab-2.2.3-6.fc33.x86_64 requires libmatio.so.9()(64bit), but none of the providers can be installed - matio-1.5.17-4.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package gtatool-matlab-2.2.3-6.fc33.x86_64 Problem 3: rdma-core-34.0-1.fc33.i686 has inferior architecture - rdma-core-34.0-1.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package rdma-core-34.0-1.fc33.i686 Problem 4: package openexr-libs-2.5.5-1.fc34.x86_64 obsoletes OpenEXR-libs < 2.5.3 provided by OpenEXR-libs-2.3.0-8.fc34.x86_64 - package Field3D-1.7.3-10.fc34.x86_64 requires libHalf-2_5.so.25()(64bit), but none of the providers can be installed - package Field3D-1.7.3-10.fc34.x86_64 requires libImath-2_5.so.25()(64bit), but none of the providers can be installed - package gtatool-hdr-2.2.3-6.fc33.x86_64 requires libIlmImf-2_3.so.24()(64bit), but none of the providers can be installed - problem with installed package Field3D-1.7.3-5.fc33.x86_64 - OpenEXR-libs-2.3.0-6.fc33.x86_64 does not belong to a distupgrade repository - Field3D-1.7.3-5.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package gtatool-hdr-2.2.3-6.fc33.x86_64 The first three can be solved by erasing gtatool-gdal, gtatool-matlab and rdma-core-34.0-1.fc33.i686. The first two are relatively painless, but rdma-core forces the removal of the entire Wine installation--I did it and plan/hope to reinstall Wine after the upgrade. The fourth problem looks like requiring removal of OpenEXR-libs, but that forces removal of 121 packages including ImageMagick, gimp, blender, lyx and texlive, which seemed harsh. It turns out that it can be solved by removing gtatool-hdr, though! This wasn't obvious to me at first sight---I only tried it because of the other gtatool-* packages causing problems, prejudicing me slightly. I haven't reported it in Bugzilla yet---what package should I report it against? OpenEXR-libs? gtatool-hdr? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 update experience
rpm -qa | wc - reports 5939 On Tue, Apr 27, 2021 at 2:13 PM Tomasz Torcz wrote: > > Dnia Tue, Apr 27, 2021 at 04:08:38PM +, Zbigniew Jędrzejewski-Szmek > napisał(a): > > On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote: > > > Updated F33 -> F34. Mostly went well, except there is one thing which > > > could be better. This is not new to F34 but has been there since the > > > dnf system-upgrade. > > > > > > Running on a pretty decent laptop (core i7, 8GB, SSD). The issue is > > > that the installation hangs a long time with no evidence of activity. > > > The hang begins at > > > dnf running transaction. It is disconcerting because it hangs for > > > about 20-30 minutes, and during that time the fan is not running, so > > > > 20-30 minutes seems unexpected… There is a phase where dnf is solving > > the deps, but it's usually much much shorter (*), and it's CPU-bound, > > so the fans should be on. I don't know what's going on in your case, > > but it sounds like some bug. > > In 2019 I did some measurements of F31→F32. First step of distribution > upgrade > took 16 minutes on a desktop computer. The results are at > https://enotty.pipebreaker.pl/posts/2019/12/time-needed-to-dist-upgrade-fedora/ > > > Do you have a huge number of packages? Lot's of modules? A very slow disk? > > `rpm -qa` returns 3109. No modules (I think). Storage is btrfs raid1 > over 2xHDD (5900 RPM) + bcache with 2x384GiB partitions. > > -- > Tomasz .. oo o. oo o. .o .o o. o. oo o. .. > Torcz.. .o .o .o .o oo oo .o .. .. oo oo > o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Those who don't understand recursion are doomed to repeat it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 update experience
Dnia Tue, Apr 27, 2021 at 04:08:38PM +, Zbigniew Jędrzejewski-Szmek napisał(a): > On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote: > > Updated F33 -> F34. Mostly went well, except there is one thing which > > could be better. This is not new to F34 but has been there since the > > dnf system-upgrade. > > > > Running on a pretty decent laptop (core i7, 8GB, SSD). The issue is > > that the installation hangs a long time with no evidence of activity. > > The hang begins at > > dnf running transaction. It is disconcerting because it hangs for > > about 20-30 minutes, and during that time the fan is not running, so > > 20-30 minutes seems unexpected… There is a phase where dnf is solving > the deps, but it's usually much much shorter (*), and it's CPU-bound, > so the fans should be on. I don't know what's going on in your case, > but it sounds like some bug. In 2019 I did some measurements of F31→F32. First step of distribution upgrade took 16 minutes on a desktop computer. The results are at https://enotty.pipebreaker.pl/posts/2019/12/time-needed-to-dist-upgrade-fedora/ > Do you have a huge number of packages? Lot's of modules? A very slow disk? `rpm -qa` returns 3109. No modules (I think). Storage is btrfs raid1 over 2xHDD (5900 RPM) + bcache with 2x384GiB partitions. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 update experience
As I said, the machine has an ssd. But it has a very large number of packages. It's used for development so has lots of devel pkgs, and a large selection of the live. On Tue, Apr 27, 2021, 12:10 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote: > > Updated F33 -> F34. Mostly went well, except there is one thing which > > could be better. This is not new to F34 but has been there since the > > dnf system-upgrade. > > > > Running on a pretty decent laptop (core i7, 8GB, SSD). The issue is > > that the installation hangs a long time with no evidence of activity. > > The hang begins at > > dnf running transaction. It is disconcerting because it hangs for > > about 20-30 minutes, and during that time the fan is not running, so > > 20-30 minutes seems unexpected… There is a phase where dnf is solving > the deps, but it's usually much much shorter (*), and it's CPU-bound, > so the fans should be on. I don't know what's going on in your case, > but it sounds like some bug. > > Do you have a huge number of packages? Lot's of modules? A very slow disk? > > Zbyszek > > (*) I was upgrading a rpi3 recently, and I had to wait a few minutes... > But on a beefy machine, anything above a few dozen seconds is suspicious. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34 update experience
On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote: > Updated F33 -> F34. Mostly went well, except there is one thing which > could be better. This is not new to F34 but has been there since the > dnf system-upgrade. > > Running on a pretty decent laptop (core i7, 8GB, SSD). The issue is > that the installation hangs a long time with no evidence of activity. > The hang begins at > dnf running transaction. It is disconcerting because it hangs for > about 20-30 minutes, and during that time the fan is not running, so 20-30 minutes seems unexpected… There is a phase where dnf is solving the deps, but it's usually much much shorter (*), and it's CPU-bound, so the fans should be on. I don't know what's going on in your case, but it sounds like some bug. Do you have a huge number of packages? Lot's of modules? A very slow disk? Zbyszek (*) I was upgrading a rpi3 recently, and I had to wait a few minutes... But on a beefy machine, anything above a few dozen seconds is suspicious. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F34 update experience
Updated F33 -> F34. Mostly went well, except there is one thing which could be better. This is not new to F34 but has been there since the dnf system-upgrade. Running on a pretty decent laptop (core i7, 8GB, SSD). The issue is that the installation hangs a long time with no evidence of activity. The hang begins at dnf running transaction. It is disconcerting because it hangs for about 20-30 minutes, and during that time the fan is not running, so no evidence of cpu usage. There seems to be no way to switch VT to try to see what's happening. I'd hate to see what happens on a less capable machine. I wish there was some way to get some better feedback that the update is alive. -- Those who don't understand recursion are doomed to repeat it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
