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 18:35:27 +0100 Message-ID: In-Reply-To: <1ff745df-d501-fcbe-8d0c-ab8ea0b145e6@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3222748559243928395==" List-Id: --===============3222748559243928395== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 1 Apr 2021, at 17:51, Adolf Belka wrote: >=20 > Hi Michael, All, >=20 > On 01/04/2021 15:24, Michael Tremer wrote: >> 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 w= ithout any errors. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> I have installed the iso, that resulted from my build, into my vm testb= ed 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 new= er versions of Perl. >>> Everything I have checked so far on my vm testbed has worked but I have n= ot 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= the changed rootfile in the patch but for the addons I have to update the PA= K_VER number if the rootfile has changed so they will have a combination of l= fs and rootfile in the patch. >>>> Yes, please commit any changes of the LFS files and rootfiles of the sam= e package together. We technically can probably not go back if something brea= ks 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 f= or perl and each other package will have its own patch. >>>> Yes, there will be tons of dependencies and packages might bring perl bi= ndings (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 se= emed 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 wit= h the IPFire system by doing a git pull before I do any changes. So I don't b= elieve 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=3Dpeople/bonnietwin/ipfire-2.x.git;a= =3Dsummary Check out the =E2=80=9CUser Repositories=E2=80=9D section https://wiki.ipfire= .org/devel/sources > 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 no= w 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 Setting the rate-limit any higher would probably defeat the point, but I supp= ose want to have a high burst so that we can submit larger patchsets without = any problems. -Michael >=20 > Regards, > Adolf. >>>>> This will mean that I will be sending a huge number of patches in to pa= tchwork 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 d= ifferently. >>>> 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 ge= t 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, g= rep, vim, and so on are really power tools. It just takes ages to use them an= d everyone is still learning new things after decades. >> -Michael >>>=20 >>> Regards, >>> Adolf >>>> -Michael >>>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Adolf. >>>>>=20 >>>>> --=20 >>>>> Sent from my laptop >>>>>=20 --===============3222748559243928395==--