I haven't been able to look at your pull request, sorry! I tried to manage it also with the build system. It was easy and fast, but you know, since I am not working for Turris, things need time since I am not paid for that. :-)
https://github.com/openwrt/packages/pull/23594 This one enables or disables HTTP support based on zlib support for curl After, it is being reviewed, I will backport it to the stable branches.
There will be created another PR, where I will try to enable zlib support for curl I need to compile it, see the size difference, write commit description, (no need to test it as I tested it locally for 1st point). Once, it will be approved, I can merge it by myself and also backport it to the stable branches.
Afterward, I am going to try your fix proposed upstream; thank you, Peter!
BTW: I updated syslog-ng to the latest version (currently 4.6.0) for OpenWrt and backported it to the stable branches, so it will be included in the upcoming Turris OS 7.0 RC3.
The new version of Squid is on its way to your downstream distribution; please check it out!
Have a nice day!
Bye-bye.
I will look at it, thanks! :) Turris guys did not release a new version since October, so there is still plenty time to look at it.
C'mon, you cant be even serious with this.
In Czech: https://www.root.cz/zpravicky/terrapin-attack-umoznuje-nepozorovane-odstrihavat-casti-zprav-v-ssh/#newIndex1 (I recommend to read the discussion as well)
b. OpenSSH since version 9.5, it uses Ed25519 keys by default. Tested?
Hmm, all your changes were pending as I can see pull requests untouched for months. Yet, the reason is that you dont have enough people, which are full time, right? Everyone can see your activity on GitLab and on forum. You need to admit that. Thats the reality. But we are getting slightly off topic here.
Shouldnt it be mentioned in the commit description? It should be. This was tested. How? Do you have any automatic tests? I can not see that CI run tested it. OpenWrt at least have something. I am not testing that it is not bullet proof, but looking how testing goes on Turris OS 6.5, I see that you need more tests. On each router, which do you have?
Patches no matter what should be send to upstream. I can not see there any activity from you guys. Except you, Michal, but you do have more things to do and honestly, your new guys, which are you in charge should cooperate more. Yet... if they are not full time, they are not, you can see that the progress is getting slower and slower.
When it will happen? Thats my question. What is so complicated on pushing this to forked repository on GitHub and creating pull request? Let me say something about one minute? Why it is not there since you said that it is tested? Wouldnt it be better if you dont have time and trust me on this one that you are great and working simultaneously on multiple things, which I admire, but you dont have time for everything that they would rather send patches to upstream, when OpenWrt community can help them? Just my 2c.
Would it be better to send this to upstream? Of course, it will be. Because you forgot to include so many changes, which are present in upstream repository, so you will end up with the same situation as Turris OS 3.x resulting in playing on your own playground without tests, incompatibility changes. Updating something to the latest version is not good. Who is testing that in OpenWrt? Only users, what are using snapshots. What about stable users.
Maybe, you should reconsider that. Cooperate with upstream is one thing.
This version isnt even in OpenWrt, so good luck. You will need it. Just wait until I say that I warned you.
This gets messy, why it is patch? Because it means that you will do something with this.
This is put into bad folder - branding. Why?
Why you dont include changes from master or stable branch? This looks like anyone can do package bump. Testing is important. It runs? Yes? All setups and configurations? OpenSSH is quite important on Turris router, isnt it?
Please do the diff between OpenWrt 21.02 and OpenWrt 22.03/23.05 and you will see how many changes you miss.
Include details, why are you are updating. It is not clear. You are just saying update. What about CVE? What about bug fixes?
Oh man. You really need mentor or someone, who will have time for you and do it better. This is really bad. Why dont you focus your time on something, which makes more sense for users? Hey... OpenWrt 22.03 we are looking for you. Those reForis changes, there is opened PR for several months already. It is not excuse. You can work simultaneously on multiple things. Why this can not be pushed to HBL to be tested first? reForis is there. Users dont care about reForis once they configured it. Also, you can not release 6.5.0 in a few days as it was discussed on forum, where you should participate.
You will update it now, but what will happen when you will use HBL branch, I mean to be more specific newer OpenWrt version. This version will be downgraded. Is that what you want?
@shenek fyi
Similar PR was just created - !340 (merged)
Oh my goodness, I was thinking for long time, if I should write something or not. From my point of view, this does not belong to master branch. Neither to Turris OS 6.5 (if you would release it as RC2, which you will do most likely and thats the stupid idea ever) or Turris OS 7.0. Overally, you should avoid doing such changes. This should be merged IMHO only to develop branch, but I am not saying anything, because you are not following stated and agreed workflow anymore. Yeah, formality things, which no one cares about anymore.
My reasoning why you should not merge it to 6.5 or 7.0:
6.5: It is already based on EoL branch, you should avoid doing and bringing breaking changes, which migration to upstream Lighttpd definitely is. You tested it on default configurations and you don't care about custom configuration. Maybe I forget some things, but when did you say that you don't support anything else than default configuration? This results into that your support department will be overloaded by advanced users or/and there is going to be one long discussion on your forum, where you are not responding.
7.0: Your merged change is not said anywhere in changelog. Keep in mind that if Lighttpd as webserver is not working, then it is a big problem, not only for you, but for users. How they can send you diagnostics from web?
However, it appears that you know what are you doing, so best luck with this.
This currently happens in HBL.
root@turris:~# reforis
Traceback (most recent call last):
File "/usr/bin/reforis", line 8, in <module>
sys.exit(main())
File "/usr/lib/python3.10/site-packages/reforis/__main__.py", line 35, in main
File "/usr/lib/python3.10/site-packages/reforis/__init__.py", line 47, in create_app
File "/usr/lib/python3.10/site-packages/reforis/__init__.py", line 176, in set_locale
AttributeError: 'Babel' object has no attribute 'localeselector'
Not correct.
Most likely, this should not be necessary because the issue that Jeffery is talking about and it is referenced in the commit, which you backported (not entirely correct, because now it seems like you are the author, which is not true), was fixed in Poetry Core 1.7.0. See https://github.com/python-poetry/poetry-core/pull/611
However, it does not harm to send it to upstream. I did that for you.
Drop all patches, which add files in host-pip-requirements. Probably some of them need to be replaced by HostBuild.
This still needs to be done otherwise HBL won't be compiled.
Great finding here, thanks! I somehow missed that while backporting several commits. Anyway, I corrected it now.
Yeah, it only took 2 weeks to drop single patch, but overally, we managed that.
Let me help you on this so things get moved on faster. :) We can call it effectivity.
Maybe at some point, you will reach a conclusion that your test might pass or fail, but in any case, this is not correct. Nobody can say anything thar I am not helpful to new guys at Turris. However, I refused to do the things it for you as my help is not appreciated, and my PRs are not getting any attention from your side. Also, I am not paid for it.
What needs to be done:
Reference: https://github.com/openwrt/packages/commit/3ee4e7297cf07b644bac3dfafc508da5f31bf63d
Let me quote from the commit description:
This also removes the toml host pip requirements file as toml is not
used by any other package.
Thus, if something is using toml in your build, it should be replaced by tomli:
https://github.com/openwrt/packages/pull/20657/commits/7d171049fde47161c67b2c2e905b833bc66613f0
If it is not possible to use tomli for whatever shitty reason, then do it by HostBuild. Don't reintroduce something, which was reworked. Reasons are in the commit messages.
Kind reminder, sounds like easy job to do. Can you look at it, please @rmuzik? HBL is not compiled for several days now.
@AreYouLoco Thanks. I don't care how it looks or how anyone could feel about it. The most important goal is that the job is done. Not here, but in upstream. I'm thinking that I should be really paid for it. :-) Obviously, you can hire a lot of people, but if you don't have time for them, they rely on self-studying. The stuff could be easy, could be hard. That depends on the knowledge. Always is good if you have someone to ask, and he will answer you promptly, which can not happen if someone is overloaded and overwhelmed by other duties.
Let's hope that they will discover IRC channels for OpenWrt - #openwrt-devel , etc. and join it there soon.
Regarding this Makefile, since it is taken from NixOS, I think it should be discussed with cjdns developer, if it can be backported. If you want to have it really secured and nice.
I am not using anyhow this package, but based on description https://github.com/openwrt/routing/pull/974, it seems like it should be also backported. Same approach as for the Python should be done here. Leaving comment instead of patching it here sounds better.
This I am not sure. I can not see any faillog in OpenWrt related to this. Anyway, Python 3.10 is already in OpenWrt 22.03, so it should be failing in upstream as well.
//EDIT: cjdns is compiled in upstream, so something fishy could be here going on. Reference: https://downloads.openwrt.org/releases/packages-22.03/powerpc_8540/routing/
Maybe, you can leave a comment here: https://github.com/openwrt/routing/pull/974 to request to backport it to stable OpenWrt releases.