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 14:05:33 +0100 Message-ID: <8C82AEE2-9306-4C6F-8517-7D9F3BCA9221@ipfire.org> In-Reply-To: <798b6a5a-c936-4ccc-9c1b-7d89e9e754d1@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3559302534122213597==" List-Id: --===============3559302534122213597== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > 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 i= n 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 w= ith 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 try= ing 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 i= n build/ and your logs are in logs/. If you then run clean, it will try to re= move those directories and since they don=E2=80=99t exist, ./make.sh clean wi= ll 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 t= o next, run ./make.sh clean, then change to master and run it again. That sho= uld give you a clean tree. >>=20 >> I will run the clean in master which will get rid of all the old named dir= s and then move to next with a clean structure for doing the build with the n= ew 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 a= nd 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 empty th= e whole time. Not a big issue. Oh, I did not notice this, but we should change that... > The other thing I found was that the following were listed in the untracked= changes section. >=20 > doc/ChangeLog > doc/packages-list.txt We used to generate these files, but I don=E2=80=99t think they have any valu= e any more, so I removed them. This was also necessary because the build envi= ronment can no longer write to the doc/ directory. You can just delete them, but if you build master again, they will be created= again. > I just did my build ignoring them but presumably they either need to be add= ed 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 ver= y nicely. That is good to know! Best, -Michael > 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 packa= ge update build. >>>>=20 >>>> The gettoolchain and downloadsrc worked fine. However the ./make.sh clea= n just came straight back to the cursor without removing any of the directori= es in my repo. >>>>=20 >>>> I am now using my master repo version for doing the package update but s= omething has gone wrong with the unshared migration because the clean command= worked fine when it was in your own repo. >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. --===============3559302534122213597==--