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: Fri, 26 Jul 2024 14:39:09 +0200 Message-ID: <798b6a5a-c936-4ccc-9c1b-7d89e9e754d1@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5123493422086337841==" List-Id: --===============5123493422086337841== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 26/07/2024 10:35, Adolf Belka wrote: > Hi Michael, > > On 26/07/2024 10:17, Michael Tremer wrote: >> Hello, >> >> Hmm, this might be a slight transitioning problem=E2=80=A6 > > Yes, of course. >> >> 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. > > I had forgotten that the new build system created the build and log dirs wi= th the architecture included in the name now. > > 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 tryi= ng to remove the build_x86_64 but I still had the build dire. >> >> 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 rem= ove those directories and since they don=E2=80=99t exist, ./make.sh clean wil= l return really quickly.> Is this maybe what happens? > > Yes. That makes sense. >> >> 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 shou= ld give you a clean tree. > > 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 the ne= w system. > Everything worked fine for the build after I cleared out the old dirs. 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 wh= en I deleted it and started the build it was re-created but stayed empty the = whole time. Not a big issue. The other thing I found was that the following were listed in the untracked c= hanges section. doc/ChangeLog doc/packages-list.txt 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 Apart from those two very minor observations, the new build process ran very = nicely. Regards, Adolf > Thanks. > > Adolf. >> >> Best, >> -Michael >> >>> On 26 Jul 2024, at 08:57, Adolf Belka wrote: >>> >>> Hi Michael, >>> >>> I ran git pull origin next on my local repo and then went to try a packag= e update build. >>> >>> The gettoolchain and downloadsrc worked fine. However the ./make.sh clean= just came straight back to the cursor without removing any of the directorie= s in my repo. >>> >>> I am now using my master repo version for doing the package update but so= mething has gone wrong with the unshared migration because the clean command = worked fine when it was in your own repo. >>> >>> Regards, >>> >>> Adolf. >>> >> --===============5123493422086337841==--