From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: perl update notification Date: Thu, 01 Apr 2021 14:24:47 +0100 Message-ID: <4E2F3FBF-5BF5-4B2C-90AB-EB381564E15E@ipfire.org> In-Reply-To: <7821e520-5b38-7a6d-2dc2-da931ca7d3b9@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5771008946199733773==" List-Id: --===============5771008946199733773== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 1 Apr 2021, at 12:32, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 01/04/2021 11:55, Michael Tremer wrote: >> Hello, >>> On 1 Apr 2021, at 09:31, Adolf Belka wrote: >>>=20 >>> Hi All, >>>=20 >>> After a lot of work I have successfully built the new version of perl wit= hout any errors. >>>=20 >>> As Michael had warned, there were a huge number of packages that needed t= o have their rootfiles updated to reflect the change in version number that i= s in the directory path for many files. >>>=20 >>> 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. >>>=20 >>> My understanding is that for the common packages I only need to provide t= he 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 bind= ings (e.g. rrdtool) which will need to be touched, too. > As you mentioned rrdtool I went back and checked several graphs and log pi= e charts on my vm testbed to see if they worked and all graphs I checked seem= ed to be working. > However there are so many changes that it definitely needs a careful look t= hrough 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 pu= ll 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 bel= ieve I can do this. Do you have a Git repository on our server? If not, should I create one so th= at 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 patc= hwork 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 dif= ferently. >> 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 Ma= tthias's statement that "sed is your friend". I definitely found it useful fo= r 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 e= veryone is still learning new things after decades. -Michael >=20 > Regards, > Adolf >> -Michael >>>=20 >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>> --=20 >>> Sent from my laptop >>>=20 --===============5771008946199733773==--