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: Thu, 29 Aug 2024 09:46:18 +0200 Message-ID: <5EFC11B6-47B5-4321-88BF-E8A1437ABD24@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8546155007766111826==" List-Id: --===============8546155007766111826== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 28 Aug 2024, at 21:10, Adolf Belka wrote: >=20 > Hi Matthias, >=20 > On 28/08/2024 20:28, Matthias Fischer wrote: >> On 28.08.2024 19:52, Adolf Belka wrote: >>> Hi All, >>>=20 >>> On 28/08/2024 18:30, Matthias Fischer wrote: >>>> On 28.08.2024 17:46, Michael Tremer wrote: >>>>> Hello everyone, >>>> Hi, >>>>=20 >>>>> Could you please confirm that this works: >>>>>=20 >>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D5e8730= eb9aec83a76b3ae7719925ede8470069a6 >>>=20 >>> 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... >=20 > 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. >=20 > A difference today is the make.sh file but also the toolchain has been bump= ed up due to the binutils update. >=20 > 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. This is because of the older toolchain. We used to ship automake 1.16 in the = old toolchain and automake 1.17 in the actual system last week. I then rebuilt the toolchain so that we have the same versions throughout whi= ch removed automake 1.16. When Coreutils was calling autoreconf, it found the= older version of automake in the toolchain and used that. Now that has gone,= it can only find 1.17 and is unhappy with that. So, these are just normal birthing issues with a new toolchain :) -Michael > Regards, > Adolf. >>>=20 >>> 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 >>>=20 >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>> For me it does. >>>>=20 >>>>> It works for me on Ubuntu 22.04 LTS with kernel 5.15. >>>> Here: >>>> Ubuntu 22.04 LTS / 6.8.0-40-generic >>>>=20 >>>> 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. ;-) >>>>=20 >>>> Best >>>> Matthias >>>>=20 >>>>> 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: >>>>>=20 >>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3Dfaccfa= 70754fabaed56c9147ace4d509f7d2317c >>>>>=20 >>>>> -Michael >>>>>=20 >>>>>> On 27 Aug 2024, at 20:03, / / wrote: >>>>>>=20 >>>>>> 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 = exist from what I am seeing. >>>>>>=20 >>>>>> # If unshare is asked to terminate, terminate all child processes >>>>>> "--kill-child" >>>>>> ) >>>>>>=20 >>>>>> mount --bind ${BUILD_DIR}/proc ${BUILD_DIR}/proc >>>>>>=20 >>>>>> fi >>>>>>=20 >>>>>> while [ $# -gt 0 ]; do >>>>>>=20 >>>>>> one thing I don't see is the mount when i check the output of mount or= the output of findmnt -o+PROPAGATION --===============8546155007766111826==--