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 18:51:38 +0200 Message-ID: <1ff745df-d501-fcbe-8d0c-ab8ea0b145e6@ipfire.org> In-Reply-To: <4E2F3FBF-5BF5-4B2C-90AB-EB381564E15E@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4472666135108297925==" List-Id: --===============4472666135108297925== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, All, On 01/04/2021 15:24, Michael Tremer wrote: > Hello, >=20 >> On 1 Apr 2021, at 12:32, Adolf Belka wrote: >> >> Hi Michael, >> >> On 01/04/2021 11:55, Michael Tremer wrote: >>> Hello, >>>> 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 wi= thout 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 testbe= d 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 >=20 > Okay. >=20 >>> I would expect that some parts of the web UI are not compatible with newe= r versions of Perl. >> Everything I have checked so far on my vm testbed has worked but I have no= t been able to check everything. >=20 > That is surprising, but good news :) >=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 = 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 lf= s 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 break= s 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 fo= r perl and each other package will have its own patch. >>> Yes, there will be tons of dependencies and packages might bring perl bin= dings (e.g. rrdtool) which will need to be touched, too. >> As you mentioned rrdtool I went back and checked several graphs and log p= ie charts on my vm testbed to see if they worked and all graphs I checked see= med to be working. >> However there are so many changes that it definitely needs a careful look = through to find the things that I missed. >=20 > 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. >=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 :) >>> https://wiki.ipfire.org/devel/git/pull-requests >=20 >> I had a look at this but if I understand it correctly to be able to do a p= ull 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 be= lieve I can do this. >=20 > 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. I just sent in the series but part way through I sent the patches a bit too q= uickly and got a rate limit warning and dropped me out of git send-email. I r= e-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? Regards, Adolf. >=20 >>>> This will mean that I will be sending a huge number of patches in to pat= chwork later today/tomorrow. If I should be doing this another way, because o= f the large number of packages in the series, let me know what I should do di= fferently. >>> 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 M= atthias's statement that "sed is your friend". I definitely found it useful f= or this work. >=20 > Yes, it is great to finally see why certain things are as they are. Sed, gr= ep, vim, and so on are really power tools. It just takes ages to use them and= everyone is still learning new things after decades. >=20 > -Michael >=20 >> >> Regards, >> Adolf >>> -Michael >>>> >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>> --=20 >>>> Sent from my laptop >>>> >=20 --===============4472666135108297925==--