Hi Michael,
On 26/07/2024 10:17, Michael Tremer wrote:
Hello,
Hmm, this might be a slight transitioning problem…
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 with 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 trying 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 remove those directories and since they don’t exist, ./make.sh clean will 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 should 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 new system.
Thanks.
Adolf.
Best, -Michael
On 26 Jul 2024, at 08:57, Adolf Belka adolf.belka@ipfire.org wrote:
Hi Michael,
I ran git pull origin next on my local repo and then went to try a package 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 directories in my repo.
I am now using my master repo version for doing the package update but something has gone wrong with the unshared migration because the clean command worked fine when it was in your own repo.
Regards,
Adolf.