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, 02 Aug 2024 18:50:17 +0100 Message-ID: <39F6BACE-25C7-4901-B4F1-5CE00D3D89F7@ipfire.org> In-Reply-To: <37d60cd4-d9e9-4658-b256-08846bda3924@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5534674039578749304==" List-Id: --===============5534674039578749304== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Matthias, > On 26 Jul 2024, at 16:06, Matthias Fischer = wrote: >=20 > On 26.07.2024 16:18, Michael Tremer wrote: >> Hello Matthias, >=20 > Hi Michael, >=20 >>> 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? >=20 > 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 >=20 > 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 It looks like you can simply update the kernel staying on the same release: https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels For 22.04 LTS, there is a Linux 6.8 image available. Could you check that and confirm that it fixes the mount propagation problem? >=20 > Hardware: > Both 'devels' are running with i7-2600 / 16GB RAM. Worked with no > problems until current 'next'... ;-) >=20 >>>=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 be= fore which is just unnecessary. >=20 > I see. Ok for me. Sorry for the noise... >=20 >>> 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? >=20 > I was just wondering - I missed the immediate error. >=20 >>> ***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 exp= ect to happen? >=20 > 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. >=20 >>> 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? >=20 > The toolchain is downloaded and OK. >=20 > Best > Matthias >=20 >>=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 bui= ld in build_x86_64/ and logs will be stored in logs_x86_64/. If you run ./mak= e.sh clean, those directories will be removed. >>>>>>=20 >>>>>> I had forgotten that the new build system created the build and log di= rs 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 = is in build/ and your logs are in logs/. If you then run clean, it will try t= o remove those directories and since they don=E2=80=99t exist, ./make.sh clea= n 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 changi= ng 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 t= he 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 empt= y 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 untra= cked 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 cr= eated 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 wro= te: >>>>>>>>=20 >>>>>>>> Hi Michael, >>>>>>>>=20 >>>>>>>> I ran git pull origin next on my local repo and then went to try a p= ackage update build. >>>>>>>>=20 >>>>>>>> The gettoolchain and downloadsrc worked fine. However the ./make.sh = clean just came straight back to the cursor without removing any of the direc= tories in my repo. >>>>>>>>=20 >>>>>>>> I am now using my master repo version for doing the package update b= ut something has gone wrong with the unshared migration because the clean com= mand worked fine when it was in your own repo. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Adolf. --===============5534674039578749304==--