Hello:

All this crap has me so annoyed.
It has kept me looking all over the web for anything related to connman+resolv.conf.
There are a great many posts complaining about this same issue, going back as far as 2017 ...

I did find an interesting tidbit with respect to the origins of connman and networkmanager which I could not have imagined.

Who would have guessed?
Those two heavyweights behind a simple application ...

[tin foil]
Make me wonder just much interest they would have in other (competing?) and much less complicated not to mention unobtrusive applications such as WiCD failing or simply just being abandoned. Because, besides connman, networkmanager and WiCD ...

What else is there for Linux?
[/tin foil]

I also found the same opinion/idea already seen in a few forums:

See here.

Also a couple of possible solutions:

See here.

This last one (originally suggested by Ralph.Ronnquist) is what I am interested in doing but I was not so sure as to how to go about it.

Then I found man connman.conf with the explanation to an an entry I had not seen/noticed before and which could be a solution:

* underlining is mine

See here.

But it happens that the entry for etc/connman/main.conf mentioned above is not present in that file so I think that the best go-to solution would be to clobber the resolv.conf with a real file and not a symlink to /etc/connman/resolv.conf.  ie: blunt force, like with a kitchen roach.

Curiously enough, although I have had my box on-line for almost nine hours, so far there has not been a DNS change (!).
So I really do not have a clue as to what is going on with connman or how it decides when to do what it does.

Truth be told, I just want WiCD back. 8^°

Thank your for the instructions, I was thinking of doing more or less the same thing.
What kept me back is the assumption that as it had been set up by connman doing so would break it and things would get worse.

I will wait and see what happens / till I get another DNS change from connman and then proceed.

Thank you very much for your input.

Best,

A.

Hello:

Badly or not-as-expected.

My conky setup queries my DNS and I can see it on-screen.
One moment it was as-expected and the next time I looked it had changed.

As posted previously, I has left it at this ...

~$cat /etc/resolv.conf
# edited by user 17092024
nameserver 192.168.1.11
~$ 

... and now it is this:

~$ cat /etc/resolv.conf
domain Home
search Home
nameserver [my fibre provider DNS]
nameserver [my fibre provider DNS]
~$ 

Maybe I did not do the chattr -f +i /etc/resolv.conf routine correctly?
Cannot say as I am unable to check the file's attrbutes:

~$ lsattr  /etc/resolv.conf
lsattr: Operation not supported While reading flags on /etc/resolv.conf
~$ 

Hmm ...
I finally found what the -f modifier does.
It happens that it does not mean force, it just suppresses error messages.

I will edit the file again, boot into recovery/repair mode and try to set it from there.

What a load of crock ...  8^/
I will report back once I am done.

Best,

A.

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.