From Newsgroup: alt.os.linux.suse

*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)]


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 2024-04-13 13:53, badEfA+sector wrote:

*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 :-)
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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?).


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 2024-04-14 14:12, badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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?
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 4/14/24 22:21, Carlos E.R. wrote:

On 2024-04-14 14:12, badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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.


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 2024-04-16 01:23, badEfA+sector wrote:

On 4/14/24 22:21, Carlos E.R. wrote:

On 2024-04-14 14:12, badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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.
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 4/16/24 06:14, R Daneel Olivaw wrote:

badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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?-a 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).



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 2024-04-16 15:11, badEfA+sector wrote:

On 4/16/24 06:14, R Daneel Olivaw wrote:

badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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?-a 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)-a (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


cer@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: rCyMesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpmrCO

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) - rCyMesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpmrCO saved [215472/215472]

cer@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/

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://-a-a no https://-a 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.

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/

then 1st attempt gives me:

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

Or badly updated machine :-)

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).

--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 4/16/24 12:09, Carlos E.R. wrote:

On 2024-04-16 15:11, badEfA+sector wrote:

On 4/16/24 06:14, R Daneel Olivaw wrote:

badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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?-a 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)-a (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)

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

cer@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: rCyMesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpmrCO

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

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

cer@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/

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.

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://-a-a no https://-a 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.

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/

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

then 1st attempt gives me:

# 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.



--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 2024-04-16 19:55, badEfA+sector wrote:

On 4/16/24 12:09, Carlos E.R. wrote:

On 2024-04-16 15:11, badEfA+sector wrote:

On 4/16/24 06:14, R Daneel Olivaw wrote:

badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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?-a 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)-a (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)

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


cer@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: rCyMesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpmrCO

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

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

cer@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/

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.

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://-a-a no https://-a 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.

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/

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.

then 1st attempt gives me:

# 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.
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 4/16/24 17:10, Carlos E.R. wrote:

On 2024-04-16 19:55, badEfA+sector wrote:

On 4/16/24 12:09, Carlos E.R. wrote:

On 2024-04-16 15:11, badEfA+sector wrote:

On 4/16/24 06:14, R Daneel Olivaw wrote:

badEfA+sector wrote:

On 4/13/24 16:25, Carlos E.R. wrote:

On 2024-04-13 13:53, badEfA+sector wrote:

*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?-a 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)-a (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)

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


cer@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: rCyMesa-libGL1-32bit-24.0.3-1699.375.pm.2.x86_64.rpmrCO

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

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

cer@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/

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

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://-a-a no https://-a 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.

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/

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

then 1st attempt gives me:

# 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






--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.suse

On 2024-04-17 03:21, badEfA+sector wrote:

On 4/16/24 17:10, Carlos E.R. wrote:

On 2024-04-16 19:55, badEfA+sector wrote:

On 4/16/24 12:09, Carlos E.R. wrote:

On 2024-04-16 15:11, badEfA+sector wrote:

On 4/16/24 06:14, R Daneel Olivaw wrote:

badEfA+sector wrote:

...

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/

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.

...
--
Cheers, Carlos.

--- Synchronet 3.21d-Linux NewsLink 1.2