WanWizard

For the VU+ 4K models:

Oh, seen it, it's not a regular python package.

Here is the package, they will be part of OpenPLi 7.3, due soon.

Thanks for the feedback .

Flushed all index packages from the cache now, so "opkg update" should pull in the correct ones.

Should, but probably not is...

Done. Found some other plugins with the same problem, fixed those too.

and cdparanoia from the same source but svn, i suspect that this is a temporary situation, i didn't checked for few days now.

Both their git and svn servers run on the same machine, which is running (you can ping it) but services are not responding,

I've notified their SysAdmin, just in case. There are plenty of people that don't monitor at all, or only monitor IP connectivity.

We fix missing dependencies when we see them, but I haven't lately (the last one was cdparanoia which I fixed), and I build daily (at home).

p.s. a build is a build, whether or not it happens "at home"...

Hmm, did I make a typo?

edit: yes, I did, fixed it, thanks.

No, the =? means "use this if no value is already set".

That is why it is there, to make sure there is a default value. I can only assume it is supposed to be updated on release, but whoever came up with it forgot to document it...

edit: I've added a note about this to the wiki.

Ok. So we need to do something about this, I'll have a look.

The timezone thing is a typical example of a dependency problem, as handling timezones has changed in develop, but it requires a new tzdata setup which the release OE doesn't have.

 

2.4GHz RF Wireless Tastatur

So it is not an IR remote.

So far i saw that if i disable the workaround by setting the boolean "m_remote_control" to false the qwerty keyboard work but the initial issue is back, the one with numerical input text.

 
That is the issue at hand, yes.
  

I wonder if there was any other issue reported at that time, or if there exists any extra infos which can help me to fix this?

No, this is exactly the problem. How to make a standard remote use the SMS-style input, while the qwerty remote use the alphanumeric input?

You still ignore the fact that the VU+ drivers reports the remote has an "A" key, when it hasn't. It has nothing to do with "blame", but with pointing out what the root cause of the problem is. Addressing the root cause is a fix, the rest is a workaround.

If you can fix it and provide a pull request, I'm all for it, I hate workarounds of any sort.

It doesn't help that afaik nobody in the team has one of these remotes, which makes development and testing very difficult.

But what I don't want it to bother users with a question that isn't relevant for 99.99999% of all users. If there is no way to reliably detect the remote, it should then be an override in the keyboard/remote setup menu (autodetect/numeric/alphanumeric), with autodetect being the default.

hmm can't find it on feed, have installed the last 7.2 release from date 04.05.2020 on vu ultimo 4k.