Hi Michael,
On 01/04/2021 19:35, Michael Tremer wrote:
Hello,
On 1 Apr 2021, at 17:51, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael, All,
On 01/04/2021 15:24, Michael Tremer wrote:
Hello,
On 1 Apr 2021, at 12:32, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
On 01/04/2021 11:55, Michael Tremer wrote:
Hello,
On 1 Apr 2021, at 09:31, Adolf Belka adolf.belka@ipfire.org wrote:
Hi All,
After a lot of work I have successfully built the new version of perl without any errors.
As Michael had warned, there were a huge number of packages that needed to have their rootfiles updated to reflect the change in version number that is in the directory path for many files.
I have installed the iso, that resulted from my build, into my vm testbed and everything that I tested worked fine with no hiccups.
From which version to which did you jump?
It was from 5.30.0 to 5.32.1
Okay.
I would expect that some parts of the web UI are not compatible with newer versions of Perl.
Everything I have checked so far on my vm testbed has worked but I have not been able to check everything.
That is surprising, but good news :)
Next thing I will do is the commits for each changed package.
My understanding is that for the common packages I only need to provide the changed rootfile in the patch but for the addons I have to update the PAK_VER number if the rootfile has changed so they will have a combination of lfs and rootfile in the patch.
Yes, please commit any changes of the LFS files and rootfiles of the same package together. We technically can probably not go back if something breaks in only one module, but this is then possible to rewiew in reasonable time.
I will make the perl change into a series of patches, the primary one for perl and each other package will have its own patch.
Yes, there will be tons of dependencies and packages might bring perl bindings (e.g. rrdtool) which will need to be touched, too.
As you mentioned rrdtool I went back and checked several graphs and log pie charts on my vm testbed to see if they worked and all graphs I checked seemed to be working. However there are so many changes that it definitely needs a careful look through to find the things that I missed.
Usually it should crash when you load the module. If it generates a graph, it is rather unlikely that there is anything big that broke.
It might even be helpful for me to push the git branch somewhere so that I do not have to pull each patch separately :) https://wiki.ipfire.org/devel/git/pull-requests
I had a look at this but if I understand it correctly to be able to do a pull request I need to have my changes in a publicly available git location. I don't. Mine are on my local desktop computer. I just keep it up-to-date with the IPFire system by doing a git pull before I do any changes. So I don't believe I can do this.
Do you have a Git repository on our server? If not, should I create one so that you can share your changes with others and use it for backup?
No I don't have one. It sounds like it could be useful to have, especially if I find other packages to update like the perl one.
Here you go: https://git.ipfire.org/?p=people/bonnietwin/ipfire-2.x.git;a=summary
Check out the “User Repositories” section https://wiki.ipfire.org/devel/sources
Thanks very much. Will start learning how to use it now.
I just sent in the series but part way through I sent the patches a bit too quickly and got a rate limit warning and dropped me out of git send-email. I re-started sending from after the last one that was sent but all of those now have an unknown series title in Patchwork. Do I need to resend the whole series or is it OK left like that or what?
I guess this is something for Peter. The archive shows them all:
https://lists.ipfire.org/pipermail/development/2021-April/thread.html
They are all in the archive and also all in Patchwork. It is just that in Patchwork patches 1/71 to 48/71 have a Series name of perl: Update to 5.32.1 with a series number of 1890 while patches 49/71 to 71/71 have a Series name of Untitled series #1891.
If that does not affect the usage of those patches then no problem.
Setting the rate-limit any higher would probably defeat the point, but I suppose want to have a high burst so that we can submit larger patchsets without any problems.
I don't have a problem with the rate limit. I knew it was there but with 712 patches I got a bit too hurried and tried the all setting in git send-mail which sent the patches much too quickly (probably looked like a spammer). I just need to be more steady with my sending of the patches.
Regards, Adolf.
-Michael
Regards, Adolf.
This will mean that I will be sending a huge number of patches in to patchwork later today/tomorrow. If I should be doing this another way, because of the large number of packages in the series, let me know what I should do differently.
No, go ahead. I do not think there is a better or worse time for this :) Thank you for putting all this time into this.
Happy to help. I also felt very satisfied when I eventually managed to get a complete clean build. Learnt quite a bit as I was doing it as well, like Matthias's statement that "sed is your friend". I definitely found it useful for this work.
Yes, it is great to finally see why certain things are as they are. Sed, grep, vim, and so on are really power tools. It just takes ages to use them and everyone is still learning new things after decades. -Michael
Regards, Adolf
-Michael
Regards,
Adolf.
-- Sent from my laptop