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

On 2024-04-13 13:53, bad💽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.

On 4/13/24 16:25, Carlos E.R. wrote:
> On 2024-04-13 13:53, bad💽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?).

On 2024-04-14 14:12, bad💽sector wrote:
> On 4/13/24 16:25, Carlos E.R. wrote:
>> On 2024-04-13 13:53, bad💽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.

On 4/14/24 22:21, Carlos E.R. wrote:
> On 2024-04-14 14:12, bad💽sector wrote:
>> On 4/13/24 16:25, Carlos E.R. wrote:
>>> On 2024-04-13 13:53, bad💽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.

On 2024-04-16 01:23, bad💽sector wrote:
> On 4/14/24 22:21, Carlos E.R. wrote:
>> On 2024-04-14 14:12, bad💽sector wrote:
>>> On 4/13/24 16:25, Carlos E.R. wrote:
>>>> On 2024-04-13 13:53, bad💽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.

bad💽sector wrote:
> On 4/13/24 16:25, Carlos E.R. wrote:
>> On 2024-04-13 13:53, bad💽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.

On 4/16/24 06:14, R Daneel Olivaw wrote:
> bad💽sector wrote:
>> On 4/13/24 16:25, Carlos E.R. wrote:
>>> On 2024-04-13 13:53, bad💽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.

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

On 2024-04-16 15:11, bad💽sector wrote:
> On 4/16/24 06:14, R Daneel Olivaw wrote:
>> bad💽sector wrote:
>>> On 4/13/24 16:25, Carlos E.R. wrote:
>>>> On 2024-04-13 13:53, bad💽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.
>
>
> 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)]

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: ‘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]

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://   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.

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

On 4/16/24 12:09, Carlos E.R. wrote:
> On 2024-04-16 15:11, bad💽sector wrote:
>> On 4/16/24 06:14, R Daneel Olivaw wrote:
>>> bad💽sector wrote:
>>>> On 4/13/24 16:25, Carlos E.R. wrote:
>>>>> On 2024-04-13 13:53, bad💽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.
>>
>>
>> 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)]
>
> 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: ‘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]
>
> 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://   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.
>
>
>>
>> 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.

On 2024-04-16 19:55, bad💽sector wrote:
> On 4/16/24 12:09, Carlos E.R. wrote:
>> On 2024-04-16 15:11, bad💽sector wrote:
>>> On 4/16/24 06:14, R Daneel Olivaw wrote:
>>>> bad💽sector wrote:
>>>>> On 4/13/24 16:25, Carlos E.R. wrote:
>>>>>> On 2024-04-13 13:53, bad💽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.
>>>
>>>
>>> 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)]
>>
>> 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: ‘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]
>>
>> 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://   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.
>>
>>
>>>
>>> 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.

On 4/16/24 17:10, Carlos E.R. wrote:
> On 2024-04-16 19:55, bad💽sector wrote:
>> On 4/16/24 12:09, Carlos E.R. wrote:
>>> On 2024-04-16 15:11, bad💽sector wrote:
>>>> On 4/16/24 06:14, R Daneel Olivaw wrote:
>>>>> bad💽sector wrote:
>>>>>> On 4/13/24 16:25, Carlos E.R. wrote:
>>>>>>> On 2024-04-13 13:53, bad💽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.
>>>>
>>>>
>>>> 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)]
>>>
>>> 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: ‘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]
>>>
>>> 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://   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.
>>>
>>>
>>>>
>>>> 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

On 2024-04-17 03:21, bad💽sector wrote:
> On 4/16/24 17:10, Carlos E.R. wrote:
>> On 2024-04-16 19:55, bad💽sector wrote:
>>> On 4/16/24 12:09, Carlos E.R. wrote:
>>>> On 2024-04-16 15:11, bad💽sector wrote:
>>>>> On 4/16/24 06:14, R Daneel Olivaw wrote:
>>>>>> bad💽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.