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?
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