From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: The unshared changes give a problem with build after doing git pull on next Date: Wed, 28 Aug 2024 21:13:20 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4324896981036446372==" List-Id: --===============4324896981036446372== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 28/08/2024 21:10, Adolf Belka wrote: > Hi Matthias, > > On 28/08/2024 20:28, Matthias Fischer wrote: >> On 28.08.2024 19:52, Adolf Belka wrote: >>> Hi All, >>> >>> On 28/08/2024 18:30, Matthias Fischer wrote: >>>> On 28.08.2024 17:46, Michael Tremer wrote: >>>>> Hello everyone, >>>> Hi, >>>> >>>>> Could you please confirm that this works: >>>>> >>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D5e8730eb9= aec83a76b3ae7719925ede8470069a6 >>> >>> I don't know if the problem is because of the above commit but coreutils = fails to build. It appears to be not finding aclocal-1.16 >> >> IMHO 'automake 1.16.5 =3D> 1.17' must be the culprit... > > but that is then also a peculiarity as I did the update build of automake t= o 1.17 and the build system had the same coreutils as today and the whole bui= ld went successfully. Coreutils was updated to the current version by myself = back on 12th June and it was merged on 22nd July. > > A difference today is the make.sh file but also the toolchain has been bump= ed up due to the binutils update. > > If coreutils is not being built due to automake-1.17 I can't understand why= my build of automake-1.17 with the same version of coreutils did build succe= ssfully. There must be some other factor interacting. > and I have done at least 4 or 5 builds successfully since automake-1.17 was p= ulled into my build system. > Regards, > Adolf. >> >>> >>> It built fine yesterday so the problem must be one of the updates that wa= s in the git pull I did today. >> >> Just a quick test: went back to 'automake 1.16.5'. Build runs. >> >> Best >> Matthias >> >>> >>> >>> Regards, >>> >>> Adolf. >>> >>>> For me it does. >>>> >>>>> It works for me on Ubuntu 22.04 LTS with kernel 5.15. >>>> Here: >>>> Ubuntu 22.04 LTS / 6.8.0-40-generic >>>> >>>> I tested 'make.sh' with all important parameters (clean, downloadsrc, >>>> gettoolchain) - right now a 'next'-build is running and looking good - >>>> I'll report when its ready. ;-) >>>> >>>> Best >>>> Matthias >>>> >>>>> There is also another fix to support kernels without time namespaces (<= 5.6). However, I am not sure if the built itself runs through on this and do= es not require anything more recent: >>>>> >>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3Dfaccfa707= 54fabaed56c9147ace4d509f7d2317c >>>>> >>>>> -Michael >>>>> >>>>>> On 27 Aug 2024, at 20:03, / / wrote: >>>>>> >>>>>> I can concur that moving the line to where Matthias put it does fix th= e issues on my machines with downloading and building, it also takes care of = the error -> mount: /git/ipfire-2.x/build_x86_64/proc: mount point does not e= xist from what I am seeing. >>>>>> >>>>>> # If unshare is asked to terminate, terminate all child processes >>>>>> =C2=A0=C2=A0=C2=A0 "--kill-child" >>>>>> =C2=A0=C2=A0 ) >>>>>> >>>>>> mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc >>>>>> >>>>>> fi >>>>>> >>>>>> while [ $# -gt 0 ]; do >>>>>> >>>>>> one thing I don't see is the mount when i check the output of mount or= the output of findmnt -o+PROPAGATION >> --===============4324896981036446372==--