Hello:

I guess not.

But the fact is that between the last release by a member of the WiCD project team and Andreas' starting to work on it, over 12 years passed.

We can shorten that to 7 if we count Pieter Leclerc's contribution (not listed as a team member) by releasing 1.7.3 (12/2014) and squashing ~30 bugs. That was his only (albeit very valuable) contribution.

But that is it, no one else till Andreas stepped up.
There is even a request for membership dating from 2021 still pending approval.

What I fail to understand is the lack of communication from the owner/members of the WiCD project team.
eg:
We do not have any time or willingness to further develop/maintain WiCD and as a result the project will be permanently archived as of mm/yyyy.
If interested in continuing development/maintenance of the WiCD project, please contact us so we can transfer the licence and control of the code/repository.

Indeed.
Would be a very good thing the whole thing moved away from github.

Best,

A.

Hello:

I don't have much of a clue as to all that would entail.
eg: with respect to the person listed as the owner of the project or the people listed as active members of the 'Wicd-devel' team.

Andreas Messer joined in 09/2021 and started to work on the WiCD project which, to all intents and purposes, had been dead-in-the-water since the bugfixing release (1.7.3 - 12/2014) authored by Pieter Leclerc who, for whatever reason, is not listed as a member of the team.

Things probably got complicated for Andreas and in spite of all his efforts nothing much happened till now but in all fairness, he seems to be the only active member of the WiCD project since 04/2012 with the release of 1.7.2 by David Paleino.
ie: over 12 years ...

With the publishing of the python2 -> python3 work done by Takahiro Yoshizawa, WiCD is now back in the spotlight. 
Kudos to him for that.

Hopefully, the WiCD project will soon be put under new management (or forked?) and, in time, recover its place in the Debian/Devuan repositories.

And in all my Devuan installations, where it is sorely missed.

Best,

A.

Hello:

Surprised?

Indeed ...
As genuine as a wooden nutmeg.

Best,

A.

Hello:

~$ cat /etc/resolv.conf 
# Generated by NetworkManager
search home
nameserver 192.168.1.1
nameserver 2a02:1210:3236:f500:a2b5:49ff:feb7:9ea0
~$ 

Right ...
Let's try something.

As sudo, please edit resolv.conf so that it ends up like this:

~$ cat /etc/resolv.conf 
# Generated by NetworkManager
# search home
#
nameserver 8.8.8.8
nameserver 8.8.4.4
#
# nameserver 192.168.1.1
# nameserver 2a02:1210:3236:f500:a2b5:49ff:feb7:9ea0
~$ 

Save the file, reboot and see if your problem is still there.
If things work, now you know that you have some DNS configuration problem.

TL;DR
192.168.1.1 is (most probably) a/your router's IP address.
2a02:1210:3236:f500:a2b5:49ff:feb7:9ea0 is a valid IPv6 address but I cannot say what it belongs to, maybe the router also.

You can check it here: http://sqa.fyicenter.com/1000334_IPv6_A … idator.htm

By editing resolv.conf you will have set Google's DNS servers as nameservers for your box and things should work as expected now.
Bear in mind that Google's DNS servers are not the only ones you can use, you can also use your service provider's DNS servers or freely available public DNS servers.

Let us know how you fared with this.

Best,

A.

Hello:

Welcome to Dev1.

Packages in the Devuan repositories come directly from the Debian repositories 'as they are' unless they need to be sanitized/fixed because of their needing systemd. If for whatever reason that cannot be done, the package is then banned from Devuan repositories.

See: https://www.devuan.org/os/packages

If Pinta was once available for Devuan, it must have been (at some point) available in the Debian repositories.
ie: if it is not in the Debian repositories, it will not be in the Devuan repositories either.

The Pinta package seems to have been removed from Debian unstable last year.
See:
https://tracker.debian.org/news/1448883 … -unstable/

Probably because of a bug, cannot really say.
See:
https://bugs.debian.org/cgi-bin/bugrepo … ug=1041606

But it is not in their repositories any longer.
See:
https://tracker.debian.org/pkg/pinta

Maybe contacting the package maintainer will get you more information.
See: https://www.pinta-project.com/contact

Best,

A.

Hello:

No, at least not where I am:

~$ date
Wed Sep 11 12:37:42 -03 2024
~$

~$ sudo apt update
---- snip --- 
Get:1 http://deb.devuan.org/merged daedalus InRelease [43.0 kB]
Get:2 http://deb.devuan.org/merged daedalus-updates InRelease [33.4 kB]
Get:3 http://deb.devuan.org/merged daedalus-security InRelease [33.2 kB]
Get:4 http://deb.devuan.org/merged daedalus/main i386 Packages [8931 kB]
Get:5 http://deb.devuan.org/merged daedalus/main amd64 Packages [9043 kB]
Get:6 http://deb.devuan.org/merged daedalus-updates/main i386 Packages [2488 B]
Get:7 http://deb.devuan.org/merged daedalus-updates/main amd64 Packages [2492 B]
Fetched 18.1 MB in 7s (2663 kB/s)                                                                                                                     
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
1 package can be upgraded. Run 'apt list --upgradable' to see it.
~$ 

Also, have a look here.
May have to do with connman, dnsproxy and how they interact.

Best,

A.

Hello:

Indeed ...

I was citing a post at [devuan-dev] and thought it was something to be taken into account.
See: https://lists.dyne.org/lurker/message/2 … a8.en.html

But also this:

I think my post is a very (very) long way from even the possibility of being characterised as the spreading of FUD.
Or anything of the sort.

Same for the OP at [devuan-dev] who clearly acted in good faith and did his research
I did not see his post characterised as FUD by anyone there.

Quite the contrary.

As for me, after over seven years and 1.527 posts at Dev1 ...
FUD?

Do lighten up. 8^P !!!

Best,

A.

Hello:

You're welcome.

Concurrently with the bug report to Devuan, this was posted to the [devuan-dev] list.
So I expect that comments/clarifications will get posted there first.

I wonder ...

Does this only affect Devuan? Debian is not affected?

Best,

A.

Hello:

Same here.

Maybe the reason is that all these updated packages only work properly on/with 6.1.0-25.
ie: not the previous version 6.1.0-23

Thanks for your input.

Best,

A.

Hello:

Offhand, I can see two issues here:

1.
Assuming that 'tuir' was working in Devuan Daedalus (the Devuan stable suite) the first thing to consider is that Devuan Excalibur is the Devuan testing suite. ie: these things are actually expected to happen. 

2.
There is no package named tuir in any of the Devuan repositories.
Or in the Debian repositories.

There are packages by that name in other distribution's repositories.
https://repology.org/project/tuir/versions

From the printout (just guessing) I think there may be something wrong with the application's python scripts.
Or the python version 'tuir' needs to work properly.

eg:
My Daedalus installation has python3/stable,now 3.11.2-1+b1 where as from the printout, it seems that the Excalibur installation uses 3.12.5. 

Best,

A.

Hello:

Welcome to Dev1.

Hmm ...
Have you asked at gnuinos about this?

The Devuan Daedalus (stable) repository has a similar package. ie: similar in name and most probably in function.

~$ apt list | grep -i sshaskpass
--- snip ---
ksshaskpass/stable 4:5.27.5-2 amd64    # 'k' instead of 'g'
ksshaskpass/stable 4:5.27.5-2 i386     # 'k' instead of 'g'
~$ 

See here.

But gsshaskpass (as you have found) is not in the Devuan repositories.

Notwithstanding, it can be found here.
It was the only hit I got by looking it up with the Google engine.

Does not appear to be a *.deb package, it has to be built from source.

There's one important note at the gnuinos web page which you should be taking into account:

It would seem that gsshaskpass does more or less the same thing ksshaskpass does but I cannot speculate further.
I'd say the people at gnuinos may have the answer to your question.

Best,

A.