From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: perl update notification Date: Thu, 01 Apr 2021 13:32:46 +0200 Message-ID: <7821e520-5b38-7a6d-2dc2-da931ca7d3b9@ipfire.org> In-Reply-To: <2E2ADAC5-B4FF-4B9B-A087-364C08DBA048@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3414478425676898408==" List-Id: --===============3414478425676898408== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 01/04/2021 11:55, Michael Tremer wrote: > Hello, >=20 >> On 1 Apr 2021, at 09:31, Adolf Belka wrote: >> >> Hi All, >> >> After a lot of work I have successfully built the new version of perl with= out 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. >=20 > From which version to which did you jump? It was from 5.30.0 to 5.32.1 >=20 > 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 b= een able to check everything. >=20 >> 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 th= e changed rootfile in the patch but for the addons I have to update the PAK_V= ER number if the rootfile has changed so they will have a combination of lfs = and rootfile in the patch. >=20 > Yes, please commit any changes of the LFS files and rootfiles of the same p= ackage 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. >=20 >> 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. >=20 > Yes, there will be tons of dependencies and packages might bring perl bindi= ngs (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 thr= ough to find the things that I missed. >=20 > It might even be helpful for me to push the git branch somewhere so that I = do not have to pull each patch separately :) >=20 > 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 do= n't. Mine are on my local desktop computer. I just keep it up-to-date with th= e IPFire system by doing a git pull before I do any changes. So I don't belie= ve I can do this. >=20 >> This will mean that I will be sending a huge number of patches in to patch= work 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 diff= erently. >=20 > No, go ahead. I do not think there is a better or worse time for this :) >=20 > 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 Matt= hias's statement that "sed is your friend". I definitely found it useful for = this work. Regards, Adolf >=20 > -Michael >=20 >> >> >> Regards, >> >> Adolf. >> >> --=20 >> Sent from my laptop >> >=20 --===============3414478425676898408==--