Re: Another F34 update experience : gtatools-*

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux