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 16:08:39 +0200 Message-ID: In-Reply-To: <8C82AEE2-9306-4C6F-8517-7D9F3BCA9221@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6273119708267946789==" List-Id: --===============6273119708267946789== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I'd like to jump in at this point...for me its not working as expected and I don't know why. Being curious I tried to build 'next', but I always get the same error: ***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 ERROR: Downloading stage2 [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP*** This is a clean pull, nothing changed. And - I noticed some oddities: './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. 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: ***SNIP*** ERROR: Failed to download sources [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP*** 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*** 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*** And: './make.sh gettoolchain' doesn't give any feedback, cursor just jumps to the next line. No "Toolchain is already downloaded. Exiting..." as before. Do I have an error somewhere? Best Matthias 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 build = in build_x86_64/ and logs will be stored in logs_x86_64/. If you run ./make.s= h clean, those directories will be removed. >>>=20 >>> I had forgotten that the new build system created the build and log dirs = 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 di= d not do a ./make.sh clean before I did the pit pull. So the new clean was tr= ying 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 is = in build/ and your logs are in logs/. If you then run clean, it will try to r= emove those directories and since they don=E2=80=99t exist, ./make.sh clean w= ill 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 changing = to next, run ./make.sh clean, then change to master and run it again. That sh= ould give you a clean tree. >>>=20 >>> I will run the clean in master which will get rid of all the old named di= rs and then move to next with a clean structure for doing the build with the = 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_64 = and all log info is placed in there. However the log dir is still present and= when I deleted it and started the build it was re-created but stayed empty t= he 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 untracke= d 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 va= lue any more, so I removed them. This was also necessary because the build en= vironment can no longer write to the doc/ directory. >=20 > You can just delete them, but if you build master again, they will be creat= ed again. >=20 >> I just did my build ignoring them but presumably they either need to be ad= ded 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 ve= ry 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 wrote: >>>>>=20 >>>>> Hi Michael, >>>>>=20 >>>>> I ran git pull origin next on my local repo and then went to try a pack= age update build. >>>>>=20 >>>>> The gettoolchain and downloadsrc worked fine. However the ./make.sh cle= an just came straight back to the cursor without removing any of the director= ies in my repo. >>>>>=20 >>>>> I am now using my master repo version for doing the package update but = something has gone wrong with the unshared migration because the clean comman= d worked fine when it was in your own repo. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Adolf. >=20 >=20 --===============6273119708267946789==--