## Chyba z 10. 04. 2020 05:53:34
Updater selhal:
inconsistent: Requested package knot-resolver that is not available.
1 Like
Hello @viktor,
You are using branch HBL. This branch is suggested to be used by experienced users. For now, you can find there Turris OS 5.1.0 in the development stage. Occasional bugs like packages are not built or things do not work there are expected. We know that and that’s why it is mentioned in our official documentation [1] and switch-branch [2].
Users do not mind a few bugs, which might happen as they want to test the latest features, which we are preparing.
If packages are not built, that’s should be easy to fix and you might want to send us pull request. But don’t worry, I fixed that [3] for you. I think it was not hard to add just one row even during Easter time.
[1] https://docs.turris.cz/geek/testing/#hbl-here-be-lions
[2] https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/develop/updater/switch-branch/files/switch-branch#L171
[3] https://gitlab.labs.nic.cz/turris/turris-os-packages/-/commit/01c412d50f2031922afa0ea10eda5a02e132a73f
Thanks, it´s working now.
Confirming current state.
INFO:Running postinst of resolver-conf
nothing done
Called /etc/init.d/kresd stop
remove dhcp script
job 1 at Thu Apr 16 20:58:00 2020
Called /etc/init.d/kresd start
remove dhcp script
uci: Entry not found
sh: out of range
Some other stuff from crons.
INFO:Running postinst of cronie
Command failed: Not found
INFO:Running prerm of vixie-cron
Command failed: Not foundI’m wondering what’s the point of your comment. It seems like DNS and cron is not working, which is not true. It works. You are using HBL branch, which is for experienced users and those don’t mind to have occasional bugs as they can recover from these bugs very easily. Any pull requests are welcome.
Is not true, that is seems like this services not working.
Really? Would you mind to share for example:
DNS:
dig turris.cz
ping turris.czJust some basic tests to see if the DNS is working.
Cron:
For example, you can do this. It does not say anything else except version, but it will tell you that crontab does not have any segfault.
crontab -VBut feel free to test it more. There are listed more commands which you can see if you run command crontab.
For me, this seems like you are trying to spread the false alarm that DNS(!) and rest functions of the routers are not working in HBL branch. There are some things, which could be improved. I admit it as I found them, reported them. However, you can see in the documentation that bugs might happen in the branch, which you are using. To use this branch, you need to opt-in for it in CLI. On the other hand, if you are would use branch HBD (Here be Dragons / Dangerous) you might expect worse issues.
Based on your previous posts here on the forum, I would like to suggest reading FAQ. Otherwise, your posts can be flagged and you might receive a warning.
Great idea! Thanks for useful feedback.
root@turris5:~# nslookup turris.cz
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: turris.cz
Address 1: 217.31.192.69
Address 2: 2001:1488:ac15:ff80::69
root@turris5:~# cronnext
next: 1587117660
No, sorry, it’s only your escalation. Continue with this tone and what you write will really becomes a reality.
What is the point of that statement when the logs for TOS build bots are not available to the user and thus the cause for the build failure?
The route with PR via Github been tried but PR been neglected for months - no point in creating a PR if it is being ignored, aside from forking for users on Gitlab not being permitted.
Bugs are also happening in the stable branch. If user feedback for certain branches, other than stable, is not wanted (unwelcome) than it should be clearly communicated.
You can reproduce it locally, don’t you? There’s a plan to change the current CI what we are using. Maybe in the future, we will provide it. It is not hard to do these following commands:
git clone https://gitlab.labs.nic.cz/turris/turris-build.git
cd turris-build
git checkout hbk
./compile_pkgs --prepare_tools -t omnia
cd build
make package/knot-resolver/compile -j4 V=sWhat these commands does is described in the README of the turris-build repository.
I see that there are none open pull requests in turris-build repository on GitHub. And if you check those closed ones, we are active there. If you compare it with OpenWrt main repository or OpenWrt packages feed. I think you are talking about your request to add kernel support for VRF. We suggested you push your changes to upstream. If it gets backported to a stable version of OpenWrt, we will have it and no further work is needed. If it does not get backported, you can use the HBD branch. There’s a separate thread for it. There were merged kernel 5.4 a few days ago and we need to investigated and check if any of our patches are still needed.
Currently, there is a possibility to use GitHub as our mirror, but if you want to send a pull request on our Gitlab changes are coming for it so you will be able to send it by default and in the meantime don’t hesitate to reach any of us and we will allow it for you.
And you expect that every user has a node for compiling? OpenWrt provides transparent access to the logs from their build bots.
I closed mine after they been neglected for some time.
That is one but there were other PR too.
That is not correct - on GitLab it was suggested:
if you really want it then it might be better to also contact OpenWRT developers.
Which been done, was it not?
On NIC.CZ’s Github repo mirror the PR been entirely neglected with no interaction whatsoever from the developers, not even a response to the question
What is the reason of this growing stale and not being merged?
And if it does not happen (upstream), also considering their aim/desire to keep the code count as lean/low as possible in support for device with much less capacity than the NIC.CZ hardware, plus being neglected on the TOS repo then any such PR NIC.CZ keeps on asking for is for nothing. NIC.CZ should make up their mind - act on PR (Github) in a timely fashion or just stop asking for it, else there is really no point in repeatedly asking for PR.
This is not going anywhere. You came just here to argue with me and this is getting off-topic.
If you know what you are doing. I mean adding a new package (this is not what we want and it should be sent to upstream instead) or editing changes, you should be sure that it does not break anything. If you know how to use CLI or Git, you can also follow steps in our documentation and test your changes before sending it to us. OpenWrt does not want to have untested changes.
Except for your pull request, we responded to other PRs next working day. This can be checked on GitHub.
I’m closing this thread.