From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer 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 15:18:56 +0100 Message-ID: <242A597A-756A-4837-8A65-A5B8E4452BBE@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0369546809206165086==" List-Id: --===============0369546809206165086== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Matthias, > 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 What is the host system that you are using? >=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. This is now done in one step. It has always done the verification twice befor= e which is just unnecessary. > 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: Unless you are thinking that this is no longer working? > ***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*** I don=E2=80=99t quite understand what the problem is here? What do you expect= to happen? > And: > './make.sh gettoolchain' doesn't give any feedback, cursor just jumps to > the next line. No "Toolchain is already downloaded. Exiting..." as before. It might be that I have removed the output when refactoring the function. Is the toolchain downloaded okay though? -Michael >=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 build= 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 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 d= id not do a ./make.sh clean before I did the pit pull. So the new clean was t= rying 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 = 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 changing= to next, run ./make.sh clean, then change to master and run it again. That s= hould give you a clean tree. >>>>=20 >>>> I will run the clean in master which will get rid of all the old named d= irs 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 an= d 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 untrack= ed 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 v= alue any more, so I removed them. This was also necessary because the build e= nvironment can no longer write to the doc/ directory. >>=20 >> You can just delete them, but if you build master again, they will be crea= ted again. >>=20 >>> I just did my build ignoring them but presumably they either need to be a= dded 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 v= ery 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 pac= kage update build. >>>>>>=20 >>>>>> The gettoolchain and downloadsrc worked fine. However the ./make.sh cl= ean just came straight back to the cursor without removing any of the directo= ries 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 comma= nd worked fine when it was in your own repo. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Adolf. >>=20 >>=20 >=20 --===============0369546809206165086==--