From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fischer To: development@lists.ipfire.org Subject: Re: The unshared changes give a problem with build after doing git pull on next Date: Fri, 26 Jul 2024 17:06:34 +0200 Message-ID: <37d60cd4-d9e9-4658-b256-08846bda3924@ipfire.org> In-Reply-To: <242A597A-756A-4837-8A65-A5B8E4452BBE@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1353994207536282592==" List-Id: --===============1353994207536282592== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 26.07.2024 16:18, Michael Tremer wrote: > Hello Matthias, Hi Michael, >> On 26 Jul 2024, at 15:08, Matthias Fischer = wrote: >>=20 >> Hi, >>=20 >> I'd like to jump in at this point...for me its not working as expected >> and I don't know why. >>=20 >> Being curious I tried to build 'next', but I always get the same error: >>=20 >> ***SNIP*** >> root(a)Devel64-1: /git/ipfire-2.x # ./make.sh build >> Packaged toolchain compilation >> Building IPFire >> stage2 >> Jul 26 13:32:59: Building stage2 unshare: cannot change >> /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument >=20 > What is the host system that you are using? uname -a: Linux Devel64-1 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux lsb_release -a: root(a)Devel64-1: /git/ipfire-2.x # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy Hardware: Both 'devels' are running with i7-2600 / 16GB RAM. Worked with no problems until current 'next'... ;-) >>=20 >> ERROR: Downloading stage2 >> [ FAIL ] >> Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if >> applicable [ FAIL ] >> ***SNAP*** >>=20 >> This is a clean pull, nothing changed. >>=20 >> And - I noticed some oddities: >>=20 >> './make.sh downloadscr' runs without any errors, but doesn't verify >> BLAKE2 checksums as before? >> "***Verifying BLAKE2 checksum >> all files BLAKE2 checksum match [ DONE ]" is missing. >=20 > This is now done in one step. It has always done the verification twice bef= ore which is just unnecessary. I see. Ok for me. Sorry for the noise... >> Changing the BLAKE2 checksum on (e.g.) 'squid 6.10' didn't produce an >> immidiate error, './make.sh downloadsrc' runs through and just ends with: >=20 > Unless you are thinking that this is no longer working? I was just wondering - I missed the immediate error. >> ***SNIP*** >> ERROR: Failed to download sources [ FAIL ] >> Check /git/ipfire-2.x/log_x86_64/_build.preparation.log for errors >> if applicable [ FAIL ] >> ***SNAP*** >>=20 >> And in this log I find: >> ***SNIP*** >> Jul 26 13:43:34: Building squid make: Entering directory >> '/git/ipfire-2.x/lfs' >> -e Download: https://source.ipfire.org/source-2.x/squid-6.10.tar.xz >> 2024-07-26 15:43:35 >> URL:https://source.ipfire.org/source-2.x/squid-6.10.tar.xz >> [2558208/2558208] -> "/tmp/squid-6.10.tar >> make: *** [squid:67: /git/ipfire-2.x/cache/squid-6.10.tar.xz] Error 1 >> ***SNAP*** >>=20 >> If I test this wrong checksum with Core186 (e.g.), 'make' stops in >> between and I get: >> ***SNIP*** >> ERROR: BLAKE2 checksum error in squid, check file in cache or signature >> [ FAIL ] >> Check /git/ipfire-2.x/log/_build.preparation.log for errors if >> applicable [ FAIL ] >> ***SNAP*** >=20 > I don=E2=80=99t quite understand what the problem is here? What do you expe= ct to happen? As stated above - I was just wondering why a checksum error didn't produce an appropriate error message like before, pointing at the affected package. >> And: >> './make.sh gettoolchain' doesn't give any feedback, cursor just jumps to >> the next line. No "Toolchain is already downloaded. Exiting..." as before. >=20 > It might be that I have removed the output when refactoring the function. >=20 > Is the toolchain downloaded okay though? The toolchain is downloaded and OK. Best Matthias >=20 > -Michael >=20 >>=20 >> Do I have an error somewhere? >>=20 >> Best >> Matthias >>=20 >>=20 >> On 26.07.2024 15:05, Michael Tremer wrote: >>> Hello, >>>=20 >>>> On 26 Jul 2024, at 13:39, Adolf Belka wrote: >>>>=20 >>>> Hi Michael, >>>>=20 >>>> On 26/07/2024 10:35, Adolf Belka wrote: >>>>> Hi Michael, >>>>>=20 >>>>> On 26/07/2024 10:17, Michael Tremer wrote: >>>>>> Hello, >>>>>>=20 >>>>>> Hmm, this might be a slight transitioning problem=E2=80=A6 >>>>>=20 >>>>> Yes, of course. >>>>>>=20 >>>>>> If you are now in next and build the distribution, it will likely buil= d in build_x86_64/ and logs will be stored in logs_x86_64/. If you run ./make= .sh clean, those directories will be removed. >>>>>=20 >>>>> I had forgotten that the new build system created the build and log dir= s with the architecture included in the name now. >>>>>=20 >>>>> My next still had all the build and logs from the last build run and I = did not do a ./make.sh clean before I did the pit pull. So the new clean was = trying to remove the build_x86_64 but I still had the build dire. >>>>>>=20 >>>>>> If you however change back to master, it will assume that your build i= s in build/ and your logs are in logs/. If you then run clean, it will try to= remove those directories and since they don=E2=80=99t exist, ./make.sh clean= will return really quickly.> Is this maybe what happens? >>>>>=20 >>>>> Yes. That makes sense. >>>>>>=20 >>>>>> You can fix this by either removing the directories by hand or changin= g to next, run ./make.sh clean, then change to master and run it again. That = should give you a clean tree. >>>>>=20 >>>>> I will run the clean in master which will get rid of all the old named = dirs and then move to next with a clean structure for doing the build with th= e new system. >>>>>=20 >>>> Everything worked fine for the build after I cleared out the old dirs. >>>>=20 >>>> Have noticed a couple of things. The new build process creates log_x86_6= 4 and all log info is placed in there. However the log dir is still present a= nd when I deleted it and started the build it was re-created but stayed empty= the whole time. Not a big issue. >>>=20 >>> Oh, I did not notice this, but we should change that... >>>=20 >>>> The other thing I found was that the following were listed in the untrac= ked changes section. >>>>=20 >>>> doc/ChangeLog >>>> doc/packages-list.txt >>>=20 >>> We used to generate these files, but I don=E2=80=99t think they have any = value any more, so I removed them. This was also necessary because the build = environment can no longer write to the doc/ directory. >>>=20 >>> You can just delete them, but if you build master again, they will be cre= ated again. >>>=20 >>>> I just did my build ignoring them but presumably they either need to be = added somewhere to include them or they need to be added to the .gitignore >>>>=20 >>>> Apart from those two very minor observations, the new build process ran = very nicely. >>>=20 >>> That is good to know! >>>=20 >>> Best, >>> -Michael >>>=20 >>>> Regards, >>>>=20 >>>> Adolf >>>>=20 >>>>> Thanks. >>>>>=20 >>>>> Adolf. >>>>>>=20 >>>>>> Best, >>>>>> -Michael >>>>>>=20 >>>>>>> On 26 Jul 2024, at 08:57, Adolf Belka wrot= e: >>>>>>>=20 >>>>>>> Hi Michael, >>>>>>>=20 >>>>>>> I ran git pull origin next on my local repo and then went to try a pa= ckage update build. >>>>>>>=20 >>>>>>> The gettoolchain and downloadsrc worked fine. However the ./make.sh c= lean just came straight back to the cursor without removing any of the direct= ories in my repo. >>>>>>>=20 >>>>>>> I am now using my master repo version for doing the package update bu= t something has gone wrong with the unshared migration because the clean comm= and worked fine when it was in your own repo. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Adolf. >>>=20 >>>=20 >>=20 >=20 --===============1353994207536282592==--