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.
Hello,
Hmm, this might be a slight transitioning problem…
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.
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?
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.
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.
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.
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…
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.
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 when 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 changes 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 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.
Hello,
On 26 Jul 2024, at 13:39, Adolf Belka adolf.belka@ipfire.org wrote:
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…
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.
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 when I deleted it and started the build it was re-created but stayed empty the 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.
doc/ChangeLog doc/packages-list.txt
We used to generate these files, but I don’t think they have any value any more, so I removed them. This was also necessary because the build environment 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 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.
That is good to know!
Best, -Michael
Regards,
Adolf
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.
Hi,
I'd like to jump in at this point...for me its not working as expected and I don't know why.
Being curious I tried to build 'next', but I always get the same error:
***SNIP*** root@Devel64-1: /git/ipfire-2.x # ./make.sh build Packaged toolchain compilation Building IPFire stage2 Jul 26 13:32:59: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
ERROR: Downloading stage2 [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
This is a clean pull, nothing changed.
And - I noticed some oddities:
'./make.sh downloadscr' runs without any errors, but doesn't verify BLAKE2 checksums as before? "***Verifying BLAKE2 checksum all files BLAKE2 checksum match [ DONE ]" is missing.
Changing the BLAKE2 checksum on (e.g.) 'squid 6.10' didn't produce an immidiate error, './make.sh downloadsrc' runs through and just ends with:
***SNIP*** ERROR: Failed to download sources [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
And in this log I find: ***SNIP*** Jul 26 13:43:34: Building squid make: Entering directory '/git/ipfire-2.x/lfs' -e Download: https://source.ipfire.org/source-2.x/squid-6.10.tar.xz 2024-07-26 15:43:35 URL:https://source.ipfire.org/source-2.x/squid-6.10.tar.xz [2558208/2558208] -> "/tmp/squid-6.10.tar make: *** [squid:67: /git/ipfire-2.x/cache/squid-6.10.tar.xz] Error 1 ***SNAP***
If I test this wrong checksum with Core186 (e.g.), 'make' stops in between and I get: ***SNIP*** ERROR: BLAKE2 checksum error in squid, check file in cache or signature [ FAIL ] Check /git/ipfire-2.x/log/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
And: './make.sh gettoolchain' doesn't give any feedback, cursor just jumps to the next line. No "Toolchain is already downloaded. Exiting..." as before.
Do I have an error somewhere?
Best Matthias
On 26.07.2024 15:05, Michael Tremer wrote:
Hello,
On 26 Jul 2024, at 13:39, Adolf Belka adolf.belka@ipfire.org wrote:
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…
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.
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 when I deleted it and started the build it was re-created but stayed empty the 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.
doc/ChangeLog doc/packages-list.txt
We used to generate these files, but I don’t think they have any value any more, so I removed them. This was also necessary because the build environment 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 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.
That is good to know!
Best, -Michael
Regards,
Adolf
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.
Hello Matthias,
On 26 Jul 2024, at 15:08, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
I'd like to jump in at this point...for me its not working as expected and I don't know why.
Being curious I tried to build 'next', but I always get the same error:
***SNIP*** root@Devel64-1: /git/ipfire-2.x # ./make.sh build Packaged toolchain compilation Building IPFire stage2 Jul 26 13:32:59: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
What is the host system that you are using?
ERROR: Downloading stage2 [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
This is a clean pull, nothing changed.
And - I noticed some oddities:
'./make.sh downloadscr' runs without any errors, but doesn't verify BLAKE2 checksums as before? "***Verifying BLAKE2 checksum all files BLAKE2 checksum match [ DONE ]" is missing.
This is now done in one step. It has always done the verification twice before which is just unnecessary.
Changing the BLAKE2 checksum on (e.g.) 'squid 6.10' didn't produce an immidiate error, './make.sh downloadsrc' runs through and just ends with:
Unless you are thinking that this is no longer working?
***SNIP*** ERROR: Failed to download sources [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
And in this log I find: ***SNIP*** Jul 26 13:43:34: Building squid make: Entering directory '/git/ipfire-2.x/lfs' -e Download: https://source.ipfire.org/source-2.x/squid-6.10.tar.xz 2024-07-26 15:43:35 URL:https://source.ipfire.org/source-2.x/squid-6.10.tar.xz [2558208/2558208] -> "/tmp/squid-6.10.tar make: *** [squid:67: /git/ipfire-2.x/cache/squid-6.10.tar.xz] Error 1 ***SNAP***
If I test this wrong checksum with Core186 (e.g.), 'make' stops in between and I get: ***SNIP*** ERROR: BLAKE2 checksum error in squid, check file in cache or signature [ FAIL ] Check /git/ipfire-2.x/log/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
I don’t quite understand what the problem is here? What do you expect to happen?
And: './make.sh gettoolchain' doesn't give any feedback, cursor just jumps to the next line. No "Toolchain is already downloaded. Exiting..." as before.
It might be that I have removed the output when refactoring the function.
Is the toolchain downloaded okay though?
-Michael
Do I have an error somewhere?
Best Matthias
On 26.07.2024 15:05, Michael Tremer wrote:
Hello,
On 26 Jul 2024, at 13:39, Adolf Belka adolf.belka@ipfire.org wrote:
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…
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.
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 when I deleted it and started the build it was re-created but stayed empty the 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.
doc/ChangeLog doc/packages-list.txt
We used to generate these files, but I don’t think they have any value any more, so I removed them. This was also necessary because the build environment 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 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.
That is good to know!
Best, -Michael
Regards,
Adolf
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.
On 26.07.2024 16:18, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
On 26 Jul 2024, at 15:08, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
I'd like to jump in at this point...for me its not working as expected and I don't know why.
Being curious I tried to build 'next', but I always get the same error:
***SNIP*** root@Devel64-1: /git/ipfire-2.x # ./make.sh build Packaged toolchain compilation Building IPFire stage2 Jul 26 13:32:59: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
What is the host system that you are using?
uname -a: Linux Devel64-1 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a: root@Devel64-1: /git/ipfire-2.x # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy
Hardware: Both 'devels' are running with i7-2600 / 16GB RAM. Worked with no problems until current 'next'... ;-)
ERROR: Downloading stage2 [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
This is a clean pull, nothing changed.
And - I noticed some oddities:
'./make.sh downloadscr' runs without any errors, but doesn't verify BLAKE2 checksums as before? "***Verifying BLAKE2 checksum all files BLAKE2 checksum match [ DONE ]" is missing.
This is now done in one step. It has always done the verification twice before which is just unnecessary.
I see. Ok for me. Sorry for the noise...
Changing the BLAKE2 checksum on (e.g.) 'squid 6.10' didn't produce an immidiate error, './make.sh downloadsrc' runs through and just ends with:
Unless you are thinking that this is no longer working?
I was just wondering - I missed the immediate error.
***SNIP*** ERROR: Failed to download sources [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
And in this log I find: ***SNIP*** Jul 26 13:43:34: Building squid make: Entering directory '/git/ipfire-2.x/lfs' -e Download: https://source.ipfire.org/source-2.x/squid-6.10.tar.xz 2024-07-26 15:43:35 URL:https://source.ipfire.org/source-2.x/squid-6.10.tar.xz [2558208/2558208] -> "/tmp/squid-6.10.tar make: *** [squid:67: /git/ipfire-2.x/cache/squid-6.10.tar.xz] Error 1 ***SNAP***
If I test this wrong checksum with Core186 (e.g.), 'make' stops in between and I get: ***SNIP*** ERROR: BLAKE2 checksum error in squid, check file in cache or signature [ FAIL ] Check /git/ipfire-2.x/log/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
I don’t quite understand what the problem is here? What do you expect to happen?
As stated above - I was just wondering why a checksum error didn't produce an appropriate error message like before, pointing at the affected package.
And: './make.sh gettoolchain' doesn't give any feedback, cursor just jumps to the next line. No "Toolchain is already downloaded. Exiting..." as before.
It might be that I have removed the output when refactoring the function.
Is the toolchain downloaded okay though?
The toolchain is downloaded and OK.
Best Matthias
-Michael
Do I have an error somewhere?
Best Matthias
On 26.07.2024 15:05, Michael Tremer wrote:
Hello,
On 26 Jul 2024, at 13:39, Adolf Belka adolf.belka@ipfire.org wrote:
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…
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.
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 when I deleted it and started the build it was re-created but stayed empty the 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.
doc/ChangeLog doc/packages-list.txt
We used to generate these files, but I don’t think they have any value any more, so I removed them. This was also necessary because the build environment 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 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.
That is good to know!
Best, -Michael
Regards,
Adolf
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.
Hello,
On 26 Jul 2024, at 16:06, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 26.07.2024 16:18, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
On 26 Jul 2024, at 15:08, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
I'd like to jump in at this point...for me its not working as expected and I don't know why.
Being curious I tried to build 'next', but I always get the same error:
***SNIP*** root@Devel64-1: /git/ipfire-2.x # ./make.sh build Packaged toolchain compilation Building IPFire stage2 Jul 26 13:32:59: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
What is the host system that you are using?
uname -a: Linux Devel64-1 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a: root@Devel64-1: /git/ipfire-2.x # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy
Hardware: Both 'devels' are running with i7-2600 / 16GB RAM. Worked with no problems until current 'next'... ;-)
Oh, wow this is quite an ancient kernel. Is there any chance you can update this?
ERROR: Downloading stage2 [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
This is a clean pull, nothing changed.
And - I noticed some oddities:
'./make.sh downloadscr' runs without any errors, but doesn't verify BLAKE2 checksums as before? "***Verifying BLAKE2 checksum all files BLAKE2 checksum match [ DONE ]" is missing.
This is now done in one step. It has always done the verification twice before which is just unnecessary.
I see. Ok for me. Sorry for the noise...
Changing the BLAKE2 checksum on (e.g.) 'squid 6.10' didn't produce an immidiate error, './make.sh downloadsrc' runs through and just ends with:
Unless you are thinking that this is no longer working?
I was just wondering - I missed the immediate error.
What is in the logs? This seems to be a problem indeed.
***SNIP*** ERROR: Failed to download sources [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
And in this log I find: ***SNIP*** Jul 26 13:43:34: Building squid make: Entering directory '/git/ipfire-2.x/lfs' -e Download: https://source.ipfire.org/source-2.x/squid-6.10.tar.xz 2024-07-26 15:43:35 URL:https://source.ipfire.org/source-2.x/squid-6.10.tar.xz [2558208/2558208] -> "/tmp/squid-6.10.tar make: *** [squid:67: /git/ipfire-2.x/cache/squid-6.10.tar.xz] Error 1 ***SNAP***
If I test this wrong checksum with Core186 (e.g.), 'make' stops in between and I get: ***SNIP*** ERROR: BLAKE2 checksum error in squid, check file in cache or signature [ FAIL ] Check /git/ipfire-2.x/log/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
I don’t quite understand what the problem is here? What do you expect to happen?
As stated above - I was just wondering why a checksum error didn't produce an appropriate error message like before, pointing at the affected package.
It totally should.
And: './make.sh gettoolchain' doesn't give any feedback, cursor just jumps to the next line. No "Toolchain is already downloaded. Exiting..." as before.
It might be that I have removed the output when refactoring the function.
Is the toolchain downloaded okay though?
The toolchain is downloaded and OK.
Best Matthias
-Michael
Do I have an error somewhere?
Best Matthias
On 26.07.2024 15:05, Michael Tremer wrote:
Hello,
On 26 Jul 2024, at 13:39, Adolf Belka adolf.belka@ipfire.org wrote:
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…
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.
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 when I deleted it and started the build it was re-created but stayed empty the 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.
doc/ChangeLog doc/packages-list.txt
We used to generate these files, but I don’t think they have any value any more, so I removed them. This was also necessary because the build environment 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 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.
That is good to know!
Best, -Michael
Regards,
Adolf
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.
Hello Matthias,
On 26 Jul 2024, at 16:06, Matthias Fischer matthias.fischer@ipfire.org wrote:
On 26.07.2024 16:18, Michael Tremer wrote:
Hello Matthias,
Hi Michael,
On 26 Jul 2024, at 15:08, Matthias Fischer matthias.fischer@ipfire.org wrote:
Hi,
I'd like to jump in at this point...for me its not working as expected and I don't know why.
Being curious I tried to build 'next', but I always get the same error:
***SNIP*** root@Devel64-1: /git/ipfire-2.x # ./make.sh build Packaged toolchain compilation Building IPFire stage2 Jul 26 13:32:59: Building stage2 unshare: cannot change /git/ipfire-2.x/build_x86_64/proc filesystem propagation: Invalid argument
What is the host system that you are using?
uname -a: Linux Devel64-1 5.15.0-117-generic #127-Ubuntu SMP Fri Jul 5 20:13:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a: root@Devel64-1: /git/ipfire-2.x # lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy
It looks like you can simply update the kernel staying on the same release:
https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels
For 22.04 LTS, there is a Linux 6.8 image available.
Could you check that and confirm that it fixes the mount propagation problem?
Hardware: Both 'devels' are running with i7-2600 / 16GB RAM. Worked with no problems until current 'next'... ;-)
ERROR: Downloading stage2 [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.ipfire.log for errors if applicable [ FAIL ] ***SNAP***
This is a clean pull, nothing changed.
And - I noticed some oddities:
'./make.sh downloadscr' runs without any errors, but doesn't verify BLAKE2 checksums as before? "***Verifying BLAKE2 checksum all files BLAKE2 checksum match [ DONE ]" is missing.
This is now done in one step. It has always done the verification twice before which is just unnecessary.
I see. Ok for me. Sorry for the noise...
Changing the BLAKE2 checksum on (e.g.) 'squid 6.10' didn't produce an immidiate error, './make.sh downloadsrc' runs through and just ends with:
Unless you are thinking that this is no longer working?
I was just wondering - I missed the immediate error.
***SNIP*** ERROR: Failed to download sources [ FAIL ] Check /git/ipfire-2.x/log_x86_64/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
And in this log I find: ***SNIP*** Jul 26 13:43:34: Building squid make: Entering directory '/git/ipfire-2.x/lfs' -e Download: https://source.ipfire.org/source-2.x/squid-6.10.tar.xz 2024-07-26 15:43:35 URL:https://source.ipfire.org/source-2.x/squid-6.10.tar.xz [2558208/2558208] -> "/tmp/squid-6.10.tar make: *** [squid:67: /git/ipfire-2.x/cache/squid-6.10.tar.xz] Error 1 ***SNAP***
If I test this wrong checksum with Core186 (e.g.), 'make' stops in between and I get: ***SNIP*** ERROR: BLAKE2 checksum error in squid, check file in cache or signature [ FAIL ] Check /git/ipfire-2.x/log/_build.preparation.log for errors if applicable [ FAIL ] ***SNAP***
I don’t quite understand what the problem is here? What do you expect to happen?
As stated above - I was just wondering why a checksum error didn't produce an appropriate error message like before, pointing at the affected package.
And: './make.sh gettoolchain' doesn't give any feedback, cursor just jumps to the next line. No "Toolchain is already downloaded. Exiting..." as before.
It might be that I have removed the output when refactoring the function.
Is the toolchain downloaded okay though?
The toolchain is downloaded and OK.
Best Matthias
-Michael
Do I have an error somewhere?
Best Matthias
On 26.07.2024 15:05, Michael Tremer wrote:
Hello,
On 26 Jul 2024, at 13:39, Adolf Belka adolf.belka@ipfire.org wrote:
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…
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.
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 when I deleted it and started the build it was re-created but stayed empty the 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.
doc/ChangeLog doc/packages-list.txt
We used to generate these files, but I don’t think they have any value any more, so I removed them. This was also necessary because the build environment 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 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.
That is good to know!
Best, -Michael
Regards,
Adolf
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.
-
Adolf Belka -
Matthias Fischer -
Michael Tremer