Repo-specific zypper bug? Never seen one before!

[bad💽sector]

*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Retrieving: libavcodec60-6.1.1-1699.5.pm.3.x86_64.rpm
........................................<55%>=================================[|
(5.6 KiB/s)]

[Carlos E.R.]

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

[bad💽sector]

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?

---------------------------------
^C
Trying to exit gracefully...
Segmentation fault (core dumped)
---------------------------------

NB. Many times there is no exit, graceful or ugly,
only a total hang!

Especially when observed only or mostly in association
with specific software then a segfault is a result of memory
mismanagment by that software (or did I miss sometyhing?).

[Carlos E.R.]

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?

I repeat: different server network.

Don't you know that Packman doesn't belong to openSUSE, that it is a
different network, a different operator, a different ownership? It is
external? It doesn't benefit from the opensuse mirroring agreements?
Doesn't belong to the opensuse infraestructure? It is not maintained by
the same people? It is not operated by the same people? (even if some
people are in both) That it has a different legal status?

Why then would not a problem affect one and not the other?

[bad💽sector]

Post by Carlos E.R.

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?

I repeat: different server network.
Don't you know that Packman doesn't belong to openSUSE, that it is a
different network, a different operator, a different ownership? It is
external? It doesn't benefit from the opensuse mirroring agreements?
Doesn't belong to the opensuse infraestructure? It is not maintained by
the same people? It is not operated by the same people? (even if some
people are in both) That it has a different legal status?
Why then would not a problem affect one and not the other?

Irrelevant, regardless of whether it's maintained by the kremlin or by
the vatican the fact remains that the problem from where I sit is
virtually exclusively on a pacman repo. That repo tree has a lot to do
with DRM so as far as I'm concerned it could be hacked to sabotage it
from time to time, or to snoop or otherwise set up its cuustomers (among
dozens of other possibilities). If I came across like I was suspecting
suse devs of something I don't see where that arose from.

[Carlos E.R.]

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?

I repeat: different server network.
Don't you know that Packman doesn't belong to openSUSE, that it is a
different network, a different operator, a different ownership? It is
external? It doesn't benefit from the opensuse mirroring agreements?
Doesn't belong to the opensuse infraestructure? It is not maintained
by the same people? It is not operated by the same people? (even if
some people are in both) That it has a different legal status?
Why then would not a problem affect one and not the other?

Irrelevant, regardless of whether it's maintained by the kremlin or by
the vatican the fact remains that the problem from where I sit is
virtually exclusively on a pacman repo.

Fully relevant.

If you are so obtuse as to not understand, I will not bother to explain.

[R Daneel Olivaw]

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?
---------------------------------
^C
Trying to exit gracefully...
Segmentation fault (core dumped)
---------------------------------
NB. Many times there is no exit, graceful or ugly,
only a total hang!
Especially when observed only or mostly in association
with specific software then a segfault is a result of memory
mismanagment by that software (or did I miss sometyhing?).

My guess is that http://packman.links2linux.org/mirrors has the answer.
Which mirror are you using? I'm set up for the gwdg one (with https)
and that seems to work just fine, I was using an Austrian one a couple
of years ago but it went offline without warning and I think I've been
using the current one ever since.

[bad💽sector]

Post by R Daneel Olivaw

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?
---------------------------------
^C
Trying to exit gracefully...
Segmentation fault (core dumped)
---------------------------------
NB. Many times there is no exit, graceful or ugly,
only a total hang!
Especially when observed only or mostly in association
with specific software then a segfault is a result of memory
mismanagment by that software (or did I miss sometyhing?).

My guess is that http://packman.links2linux.org/mirrors has the answer.
Which mirror are you using?  I'm set up for the gwdg one (with https)
and that seems to work just fine, I was using an Austrian one a couple
of years ago but it went offline without warning and I think I've been
using the current one ever since.

Thank you, it's still doing it BTW:

Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64 (Packman
Essentials Repository) (95/96), 210.4 KiB
Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
................<52%>===============[| (1.6 KiB/s)]

This was the repo in use (coughed up by Yast under 'community repos'):
http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials

the mirros page shows just: http:// no https:// and if I try to edit
it to https in Yast it gets written as http only

BUT if I truncate to just FTP

ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials

then 1st attempt gives me:

# zypper dup
Loading repository data...
Reading installed packages...
Segmentation fault (core dumped)
(segfault=badly written software)


2nd attemp after reboot works ok

So my question remains: WHAT is CAUSING this, swinging repos is NOT the
answer it's just a workaround. I'd like to find THE cause and fix THAT
(i.e. help getting it fixed).

[Carlos E.R.]

Post by bad💽sector

Post by R Daneel Olivaw

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?
---------------------------------
^C
Trying to exit gracefully...
Segmentation fault (core dumped)
---------------------------------
NB. Many times there is no exit, graceful or ugly,
only a total hang!
Especially when observed only or mostly in association
with specific software then a segfault is a result of memory
mismanagment by that software (or did I miss sometyhing?).

My guess is that http://packman.links2linux.org/mirrors has the
answer. Which mirror are you using?  I'm set up for the gwdg one (with
https) and that seems to work just fine, I was using an Austrian one a
couple of years ago but it went offline without warning and I think
I've been using the current one ever since.

Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64 (Packman
Essentials Repository)  (95/96), 210.4 KiB
Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
................<52%>===============[| (1.6 KiB/s)]

Have you tried to download that file directly?

http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm


***@Telcontar:~/tmp/A> wget http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
--2024-04-16 18:02:00-- http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
Resolving ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)... 137.226.34.46, 2a00:8a60:e012:a00::21
Connecting to ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)|137.226.34.46|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 215472 (210K) [application/x-redhat-package-manager]
Saving to: ‘Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm’

Mesa-libGL1-32bit-24.0.3-169 100%[=============================================>] 210,42K --.-KB/s in 0,1s

2024-04-16 18:02:01 (1,42 MB/s) - ‘Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm’ saved [215472/215472]

***@Telcontar:~/tmp/A>


It downloads here instantly, so you selected a bad mirror. Choose another one.


You can also download it manually, and put in the appropriate directory. In my machine, that would be:

/var/cache/zypp/packages/Ext_Packman/Essentials/x86_64/

Post by bad💽sector
http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials
the mirros page shows just: http://   no https://  and if I try to edit
it to https in Yast it gets written as http only

Use the ones actually on the page. If there are no https, then there are no https.

Post by bad💽sector
BUT if I truncate to just FTP
ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials

With no protocol? You are asking the software to crash.

For ftp it would be:

ftp://ftp.gwdg.de/pub/linux/misc/packman/

Post by bad💽sector
# zypper dup
Loading repository data...
Reading installed packages...
Segmentation fault (core dumped)
(segfault=badly written software)

Or badly updated machine :-)

Post by bad💽sector
2nd attemp after reboot works ok
So my question remains: WHAT is CAUSING this, swinging repos is NOT the
answer it's just a workaround. I'd like to find THE cause and fix THAT
(i.e. help getting it fixed).

[bad💽sector]

Post by Carlos E.R.

Post by bad💽sector

Post by R Daneel Olivaw

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?
---------------------------------
^C
Trying to exit gracefully...
Segmentation fault (core dumped)
---------------------------------
NB. Many times there is no exit, graceful or ugly,
only a total hang!
Especially when observed only or mostly in association
with specific software then a segfault is a result of memory
mismanagment by that software (or did I miss sometyhing?).

My guess is that http://packman.links2linux.org/mirrors has the
answer. Which mirror are you using?  I'm set up for the gwdg one
(with https) and that seems to work just fine, I was using an
Austrian one a couple of years ago but it went offline without
warning and I think I've been using the current one ever since.

Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64 (Packman
Essentials Repository)  (95/96), 210.4 KiB
Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
................<52%>===============[| (1.6 KiB/s)]

Have you tried to download that file directly?

Sure have, two things have proven effective

1
change repo (wrong answer)

2
taboo the package (wrong answer)

Post by Carlos E.R.
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
--2024-04-16 18:02:00--
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
Resolving ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)...
137.226.34.46, 2a00:8a60:e012:a00::21
Connecting to ftp.halifax.rwth-aachen.de
(ftp.halifax.rwth-aachen.de)|137.226.34.46|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 215472 (210K) [application/x-redhat-package-manager]
Saving to: ‘Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm’
Mesa-libGL1-32bit-24.0.3-169
100%[=============================================>] 210,42K
--.-KB/s    in 0,1s
2024-04-16 18:02:01 (1,42 MB/s) -
‘Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm’ saved [215472/215472]
It downloads here instantly, so you selected a bad mirror. Choose another one.
You can also download it manually, and put in the appropriate directory.
/var/cache/zypp/packages/Ext_Packman/Essentials/x86_64/

Doesn't change the fact that it affects packman only, something on that
repo is limping or being interfered with, I have seen this on other
packman repos going back quite a while. Sometimes a repo change works,
it worked this time again but I don't see how THAT could be THE
solution. There's no 'ignore' option either because there has been no
'failure' as such, or a timeout to open any other options. It just locks
up. Sometimes even Cntrl-C is a hit-or-miss affair.

Post by Carlos E.R.

Post by bad💽sector
http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials
the mirros page shows just: http://   no https://  and if I try to
edit it to https in Yast it gets written as http only

Use the ones actually on the page. If there are no https, then there are no https.

Post by bad💽sector
BUT if I truncate to just FTP
ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials

With no protocol? You are asking the software to crash.
ftp://ftp.gwdg.de/pub/linux/misc/packman/

I don't remember, Yast must have prepended it just as it fixed an https
entry to http.

Post by Carlos E.R.

Post by bad💽sector
# zypper dup
Loading repository data...
Reading installed packages...
Segmentation fault (core dumped)
(segfault=badly written software)

Or badly updated machine :-)

Could be a result and not a cause.

[Carlos E.R.]

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector

Post by R Daneel Olivaw

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?
---------------------------------
^C
Trying to exit gracefully...
Segmentation fault (core dumped)
---------------------------------
NB. Many times there is no exit, graceful or ugly,
only a total hang!
Especially when observed only or mostly in association
with specific software then a segfault is a result of memory
mismanagment by that software (or did I miss sometyhing?).

My guess is that http://packman.links2linux.org/mirrors has the
answer. Which mirror are you using?  I'm set up for the gwdg one
(with https) and that seems to work just fine, I was using an
Austrian one a couple of years ago but it went offline without
warning and I think I've been using the current one ever since.

Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64 (Packman
Essentials Repository)  (95/96), 210.4 KiB
Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
................<52%>===============[| (1.6 KiB/s)]

Have you tried to download that file directly?

Sure have, two things have proven effective
1
change repo (wrong answer)
2
taboo the package (wrong answer)

Post by Carlos E.R.
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
--2024-04-16 18:02:00--
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
Resolving ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)...
137.226.34.46, 2a00:8a60:e012:a00::21
Connecting to ftp.halifax.rwth-aachen.de
(ftp.halifax.rwth-aachen.de)|137.226.34.46|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 215472 (210K) [application/x-redhat-package-manager]
Saving to: ‘Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm’
Mesa-libGL1-32bit-24.0.3-169
100%[=============================================>] 210,42K
--.-KB/s    in 0,1s
2024-04-16 18:02:01 (1,42 MB/s) -
‘Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm’ saved [215472/215472]
It downloads here instantly, so you selected a bad mirror. Choose another one.
You can also download it manually, and put in the appropriate
/var/cache/zypp/packages/Ext_Packman/Essentials/x86_64/

Doesn't change the fact that it affects packman only, something on that
repo is limping or being interfered with, I have seen this on other
packman repos going back quite a while. Sometimes a repo change works,
it worked this time again but I don't see how THAT could be THE
solution. There's no 'ignore' option either because there has been no
'failure' as such, or a timeout to open any other options. It just locks
up. Sometimes even Cntrl-C is a hit-or-miss affair.

Cntrl-C is known to not work as you would assume. Areas of zypper are
non interruptible.

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials
the mirros page shows just: http://   no https://  and if I try to
edit it to https in Yast it gets written as http only

Use the ones actually on the page. If there are no https, then there are no https.

Post by bad💽sector
BUT if I truncate to just FTP
ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials

With no protocol? You are asking the software to crash.
ftp://ftp.gwdg.de/pub/linux/misc/packman/

I don't remember, Yast must have prepended it just as it fixed an https
entry to http.

No, ftp.gwdg.de goes to http.

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
# zypper dup
Loading repository data...
Reading installed packages...
Segmentation fault (core dumped)
(segfault=badly written software)

Or badly updated machine :-)

Could be a result and not a cause.

Whatever. I do not use Tumbleweed for a reason.

[bad💽sector]

Post by Carlos E.R.

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector

Post by R Daneel Olivaw

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
*zypper dup* often locks up one download or
another but the problem arises VIRTUALLY ALWAYS
ONLY while downloading from a packman repo and
not other repos. I've found a few workarounds
but am beginning to wonder what the underlying
real cause and what the associated permanent fix
might be. How no other repos are affected?

Different server network. Obviously :-)

is THIS a clue? And even if it be one, again
how come only on the packman repo?
---------------------------------
^C
Trying to exit gracefully...
Segmentation fault (core dumped)
---------------------------------
NB. Many times there is no exit, graceful or ugly,
only a total hang!
Especially when observed only or mostly in association
with specific software then a segfault is a result of memory
mismanagment by that software (or did I miss sometyhing?).

My guess is that http://packman.links2linux.org/mirrors has the
answer. Which mirror are you using?  I'm set up for the gwdg one
(with https) and that seems to work just fine, I was using an
Austrian one a couple of years ago but it went offline without
warning and I think I've been using the current one ever since.

Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64 (Packman
Essentials Repository)  (95/96), 210.4 KiB
Retrieving: Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
................<52%>===============[| (1.6 KiB/s)]

Have you tried to download that file directly?

Sure have, two things have proven effective
1
change repo (wrong answer)
2
taboo the package (wrong answer)

Post by Carlos E.R.
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
--2024-04-16 18:02:00--
http://ftp.halifax.rwth-aachen.de/packman/suse/openSUSE_Tumbleweed/Essentials/x86_64/Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm
Resolving ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)...
137.226.34.46, 2a00:8a60:e012:a00::21
Connecting to ftp.halifax.rwth-aachen.de
(ftp.halifax.rwth-aachen.de)|137.226.34.46|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 215472 (210K) [application/x-redhat-package-manager]
Saving to: ‘Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm’
Mesa-libGL1-32bit-24.0.3-169
100%[=============================================>] 210,42K
--.-KB/s    in 0,1s
2024-04-16 18:02:01 (1,42 MB/s) -
‘Mesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpm’ saved [215472/215472]
It downloads here instantly, so you selected a bad mirror. Choose another one.
You can also download it manually, and put in the appropriate
/var/cache/zypp/packages/Ext_Packman/Essentials/x86_64/

Doesn't change the fact that it affects packman only, something on
that repo is limping or being interfered with, I have seen this on
other packman repos going back quite a while. Sometimes a repo change
works, it worked this time again but I don't see how THAT could be THE
solution. There's no 'ignore' option either because there has been no
'failure' as such, or a timeout to open any other options. It just
locks up. Sometimes even Cntrl-C is a hit-or-miss affair.

Cntrl-C is known to not work as you would assume. Areas of zypper are
non interruptible.

No problemo, there's always the ON/OFF switch by the power supply unit

Post by Carlos E.R.

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials
the mirros page shows just: http://   no https://  and if I try to
edit it to https in Yast it gets written as http only

Use the ones actually on the page. If there are no https, then there are no https.

Post by bad💽sector
BUT if I truncate to just FTP
ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials

With no protocol? You are asking the software to crash.
ftp://ftp.gwdg.de/pub/linux/misc/packman/

I don't remember, Yast must have prepended it just as it fixed an
https entry to http.

No, ftp.gwdg.de goes to http.

maybe, but the update THAT came from this and only this :-))

ftp://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentials

Post by Carlos E.R.

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector
# zypper dup
Loading repository data...
Reading installed packages...
Segmentation fault (core dumped)
(segfault=badly written software)

Or badly updated machine :-)

Could be a result and not a cause.

Whatever. I do not use Tumbleweed for a reason.

I will use it for another year, maybe; for now I'm downleveled from 7
distros to only 4

Artix, Devuan, Slackware, Tumbleweed

[Carlos E.R.]

...

Post by bad💽sector

Post by Carlos E.R.

Post by bad💽sector

Post by Carlos E.R.
You can also download it manually, and put in the appropriate
/var/cache/zypp/packages/Ext_Packman/Essentials/x86_64/

Doesn't change the fact that it affects packman only, something on
that repo is limping or being interfered with, I have seen this on
other packman repos going back quite a while. Sometimes a repo change
works, it worked this time again but I don't see how THAT could be
THE solution. There's no 'ignore' option either because there has
been no 'failure' as such, or a timeout to open any other options. It
just locks up. Sometimes even Cntrl-C is a hit-or-miss affair.

Cntrl-C is known to not work as you would assume. Areas of zypper are
non interruptible.

No problemo, there's always the ON/OFF switch by the power supply unit

And then you can get a corrupted rpm database, and that is a big problem.

...