* Problem building cdrkit with latest cmake
@ 2025-05-08 12:53 Adolf Belka
2025-05-08 13:19 ` Michael Tremer
0 siblings, 1 reply; 5+ messages in thread
From: Adolf Belka @ 2025-05-08 12:53 UTC (permalink / raw)
To: IPFire: Development-List
Hi Everyone.
I found that curl had three updates for a range of bug fixes and so I went ahead and ran a build of curl-1.13.0. It built without any problems.
However cmake, a couple of steps later failed to build because of some changes in curl to certain names.
So I installed the latest cmake and then curl and cmake both built without any issues.
Then json-c failed due to the min ver of cmake being supported is now 3.5 and in the near future this will be changed to 3.10.
I found a patch from json-c that changed the minimum required version from 2.8 to 3.9...3.12 and json-c then successfully built.
libjpeg successfully built as it already had an acceptable min cmake version.
libssh failed to build so it was updated to 0.11.1 and this built successfully.
Then I came to cdrkit!!!
This failed to build due to too low a min version so I changed the min version from 2.8 to 3.25 but it the failed to build due to the cmake_policy(SET CMPOO15 OLD) and OLD is no longer allowed. It has to be NEW.
So I changed the policy to NEW and then it starting building cdrkit but then the build failed due to the fact that it could not find xconfig.h
In the source file there is xconfig.h.in but it is not getting built into xconfig.h
I checked for the existing build that works and found that there were 83 CMAKE Warnings, all related to the fact that Policy CMP0115 is not set. The cmake_policy value in the existing patch was set at CMP0015 so I also tried using cmake_policy(SET CMP0115 NEW) but that still stopped with the missing xconfig.h
It looks like the NEW cmake_policy no longer allows error to be ignored and building to continue as has been the case up to date.
It looks to me like the only way to fix it is to update cdrkit to properly work with the latest cmake but as the existing version was released 15 years ago and nothing further has been done with it I think it will not get fixed.
There is also cdrtools but there are some questions raised by some distros about it's licence. However the developer of that package died and so nothing further has been done with that for the last 7 years.
I did find that there is a project called libburnia that has a command line package called xorrisofs which emulates mkisofs.
All the mkisofs options that we use in IPFire are available with xorrisofs. The project had the last release of xorriso in 2023 but it looks like the package is released around every two years. The last commits for the project were done 2 weeks ago and there looks to be a continuing ongoing level of commit updates being done.
Would it be worthwhile for me to look at building this package and make the changes in the cdrom sections to use xorrisofs instead of mkisofs and see if its emulation of mkisofs produces a working IPFire iso that can be successfully installed and run?
If the answer is not a simple one to give then we can discuss this issue in the monthly video conf on Monday.
I will comment out cdrkit in my make.sh so I can check out if the other packages that use cmake (12 of them) can all be made to work with the latest cmake.
Regards,
Adolf.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem building cdrkit with latest cmake
2025-05-08 12:53 Problem building cdrkit with latest cmake Adolf Belka
@ 2025-05-08 13:19 ` Michael Tremer
2025-05-08 19:00 ` Adolf Belka
0 siblings, 1 reply; 5+ messages in thread
From: Michael Tremer @ 2025-05-08 13:19 UTC (permalink / raw)
To: Adolf Belka; +Cc: IPFire: Development-List
Hello Adolf,
Yet another success store of an alternative to configure/make/make install.
I remember this from IPFire 3 where we have made the transition to libburn. It needs three packages:
https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libburn/libburn.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libisofs/libisofs.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libisoburn/libisoburn.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
We are using the whole thing here:
https://git.ipfire.org/?p=people/ms/bricklayer.git;a=blob;f=src/bricklayer-master.in;hb=3b216919f31dc6ca3b44d9d25536626b60aea9f1#l527
So it seems to generate a bootable ISO and that is all we need.
Happy to make the transition in IPFire 2 as well.
-Michael
> On 8 May 2025, at 13:53, Adolf Belka <adolf.belka@ipfire.org> wrote:
>
> Hi Everyone.
>
> I found that curl had three updates for a range of bug fixes and so I went ahead and ran a build of curl-1.13.0. It built without any problems.
>
> However cmake, a couple of steps later failed to build because of some changes in curl to certain names.
>
> So I installed the latest cmake and then curl and cmake both built without any issues.
>
> Then json-c failed due to the min ver of cmake being supported is now 3.5 and in the near future this will be changed to 3.10.
>
> I found a patch from json-c that changed the minimum required version from 2.8 to 3.9...3.12 and json-c then successfully built.
>
> libjpeg successfully built as it already had an acceptable min cmake version.
>
> libssh failed to build so it was updated to 0.11.1 and this built successfully.
>
> Then I came to cdrkit!!!
>
> This failed to build due to too low a min version so I changed the min version from 2.8 to 3.25 but it the failed to build due to the cmake_policy(SET CMPOO15 OLD) and OLD is no longer allowed. It has to be NEW.
> So I changed the policy to NEW and then it starting building cdrkit but then the build failed due to the fact that it could not find xconfig.h
> In the source file there is xconfig.h.in but it is not getting built into xconfig.h
>
> I checked for the existing build that works and found that there were 83 CMAKE Warnings, all related to the fact that Policy CMP0115 is not set. The cmake_policy value in the existing patch was set at CMP0015 so I also tried using cmake_policy(SET CMP0115 NEW) but that still stopped with the missing xconfig.h
>
> It looks like the NEW cmake_policy no longer allows error to be ignored and building to continue as has been the case up to date.
>
> It looks to me like the only way to fix it is to update cdrkit to properly work with the latest cmake but as the existing version was released 15 years ago and nothing further has been done with it I think it will not get fixed.
>
> There is also cdrtools but there are some questions raised by some distros about it's licence. However the developer of that package died and so nothing further has been done with that for the last 7 years.
>
> I did find that there is a project called libburnia that has a command line package called xorrisofs which emulates mkisofs.
> All the mkisofs options that we use in IPFire are available with xorrisofs. The project had the last release of xorriso in 2023 but it looks like the package is released around every two years. The last commits for the project were done 2 weeks ago and there looks to be a continuing ongoing level of commit updates being done.
>
> Would it be worthwhile for me to look at building this package and make the changes in the cdrom sections to use xorrisofs instead of mkisofs and see if its emulation of mkisofs produces a working IPFire iso that can be successfully installed and run?
>
> If the answer is not a simple one to give then we can discuss this issue in the monthly video conf on Monday.
>
> I will comment out cdrkit in my make.sh so I can check out if the other packages that use cmake (12 of them) can all be made to work with the latest cmake.
>
> Regards,
>
> Adolf.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem building cdrkit with latest cmake
2025-05-08 13:19 ` Michael Tremer
@ 2025-05-08 19:00 ` Adolf Belka
2025-05-09 10:02 ` Adolf Belka
0 siblings, 1 reply; 5+ messages in thread
From: Adolf Belka @ 2025-05-08 19:00 UTC (permalink / raw)
To: Michael Tremer; +Cc: IPFire: Development-List
Hi Michael,
On 08/05/2025 15:19, Michael Tremer wrote:
> Hello Adolf,
>
> Yet another success store of an alternative to configure/make/make install.
>
> I remember this from IPFire 3 where we have made the transition to libburn. It needs three packages:
>
> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libburn/libburn.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libisofs/libisofs.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libisoburn/libisoburn.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
>
> We are using the whole thing here:
>
> https://git.ipfire.org/?p=people/ms/bricklayer.git;a=blob;f=src/bricklayer-master.in;hb=3b216919f31dc6ca3b44d9d25536626b60aea9f1#l527
>
> So it seems to generate a bootable ISO and that is all we need.
>
> Happy to make the transition in IPFire 2 as well.
I think for IPFire-2 we can just use the xorriso package that libburn supplies to the Gnu Project.
This is a self contained source tarball that includes the bits from libisofs and libisoburn, sufficient to do the cli commands for xorriso and xorrisofs.
https://www.gnu.org/software/xorriso/
I think this makes it simpler for IPFire-2 and it supplies what is needed for creating a bootable ISO.
My plan would be to follow this path unless you think that installing the three full packages that you listed is the better thing to do also for IPFire-2.
Regards,
Adolf.
>
> -Michael
>
>> On 8 May 2025, at 13:53, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Everyone.
>>
>> I found that curl had three updates for a range of bug fixes and so I went ahead and ran a build of curl-1.13.0. It built without any problems.
>>
>> However cmake, a couple of steps later failed to build because of some changes in curl to certain names.
>>
>> So I installed the latest cmake and then curl and cmake both built without any issues.
>>
>> Then json-c failed due to the min ver of cmake being supported is now 3.5 and in the near future this will be changed to 3.10.
>>
>> I found a patch from json-c that changed the minimum required version from 2.8 to 3.9...3.12 and json-c then successfully built.
>>
>> libjpeg successfully built as it already had an acceptable min cmake version.
>>
>> libssh failed to build so it was updated to 0.11.1 and this built successfully.
>>
>> Then I came to cdrkit!!!
>>
>> This failed to build due to too low a min version so I changed the min version from 2.8 to 3.25 but it the failed to build due to the cmake_policy(SET CMPOO15 OLD) and OLD is no longer allowed. It has to be NEW.
>> So I changed the policy to NEW and then it starting building cdrkit but then the build failed due to the fact that it could not find xconfig.h
>> In the source file there is xconfig.h.in but it is not getting built into xconfig.h
>>
>> I checked for the existing build that works and found that there were 83 CMAKE Warnings, all related to the fact that Policy CMP0115 is not set. The cmake_policy value in the existing patch was set at CMP0015 so I also tried using cmake_policy(SET CMP0115 NEW) but that still stopped with the missing xconfig.h
>>
>> It looks like the NEW cmake_policy no longer allows error to be ignored and building to continue as has been the case up to date.
>>
>> It looks to me like the only way to fix it is to update cdrkit to properly work with the latest cmake but as the existing version was released 15 years ago and nothing further has been done with it I think it will not get fixed.
>>
>> There is also cdrtools but there are some questions raised by some distros about it's licence. However the developer of that package died and so nothing further has been done with that for the last 7 years.
>>
>> I did find that there is a project called libburnia that has a command line package called xorrisofs which emulates mkisofs.
>> All the mkisofs options that we use in IPFire are available with xorrisofs. The project had the last release of xorriso in 2023 but it looks like the package is released around every two years. The last commits for the project were done 2 weeks ago and there looks to be a continuing ongoing level of commit updates being done.
>>
>> Would it be worthwhile for me to look at building this package and make the changes in the cdrom sections to use xorrisofs instead of mkisofs and see if its emulation of mkisofs produces a working IPFire iso that can be successfully installed and run?
>>
>> If the answer is not a simple one to give then we can discuss this issue in the monthly video conf on Monday.
>>
>> I will comment out cdrkit in my make.sh so I can check out if the other packages that use cmake (12 of them) can all be made to work with the latest cmake.
>>
>> Regards,
>>
>> Adolf.
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem building cdrkit with latest cmake
2025-05-08 19:00 ` Adolf Belka
@ 2025-05-09 10:02 ` Adolf Belka
2025-05-09 12:33 ` Michael Tremer
0 siblings, 1 reply; 5+ messages in thread
From: Adolf Belka @ 2025-05-09 10:02 UTC (permalink / raw)
To: Michael Tremer; +Cc: IPFire: Development-List
Hi Michael,
On 08/05/2025 21:00, Adolf Belka wrote:
> Hi Michael,
>
> On 08/05/2025 15:19, Michael Tremer wrote:
>> Hello Adolf,
>>
>> Yet another success store of an alternative to configure/make/make install.
>>
>> I remember this from IPFire 3 where we have made the transition to libburn. It needs three packages:
>>
>> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libburn/libburn.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
>> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libisofs/libisofs.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
>> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libisoburn/libisoburn.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
>>
>> We are using the whole thing here:
>>
>> https://git.ipfire.org/?p=people/ms/bricklayer.git;a=blob;f=src/bricklayer-master.in;hb=3b216919f31dc6ca3b44d9d25536626b60aea9f1#l527
>>
>> So it seems to generate a bootable ISO and that is all we need.
>>
>> Happy to make the transition in IPFire 2 as well.
>
> I think for IPFire-2 we can just use the xorriso package that libburn supplies to the Gnu Project.
>
> This is a self contained source tarball that includes the bits from libisofs and libisoburn, sufficient to do the cli commands for xorriso and xorrisofs.
>
> https://www.gnu.org/software/xorriso/
>
> I think this makes it simpler for IPFire-2 and it supplies what is needed for creating a bootable ISO.
>
> My plan would be to follow this path unless you think that installing the three full packages that you listed is the better thing to do also for IPFire-2.
I did a test build of the xorriso package and made a symbolic link of xorrisofs to mkisofs in the LFS so that no changes should be needed anywhere else. Anything using mkisofs would then use xorrisofs with the same arguments as used for mkisofs.
It successfully produced an iso, which was bootable as I was able to install IPFire with it onto my vm testbed.
Couldn't test out the making of the backupiso as that downloads the current released iso and my test build is with CU195.
Are you okay with using the xorriso source tarball or should I do a build and patch submit with the full libburn, libisofs & libisoburn packages?
The Gnu xorriso site says
" Software copies included in GNU xorriso:
GNU xorriso is feature-wise equivalent to the dynamic compilation of libburnia libraries, libjte, and libburnia program xorriso. It restricts itself to a technical form where the legal commitments of the libburnia project and the legal intentions of FSF match completely."
so it is clearly a limited form but it looks like it should be sufficient for IPFire-2.x.
Regards,
Adolf.
>
> Regards,
> Adolf.
>
>>
>> -Michael
>>
>>> On 8 May 2025, at 13:53, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>
>>> Hi Everyone.
>>>
>>> I found that curl had three updates for a range of bug fixes and so I went ahead and ran a build of curl-1.13.0. It built without any problems.
>>>
>>> However cmake, a couple of steps later failed to build because of some changes in curl to certain names.
>>>
>>> So I installed the latest cmake and then curl and cmake both built without any issues.
>>>
>>> Then json-c failed due to the min ver of cmake being supported is now 3.5 and in the near future this will be changed to 3.10.
>>>
>>> I found a patch from json-c that changed the minimum required version from 2.8 to 3.9...3.12 and json-c then successfully built.
>>>
>>> libjpeg successfully built as it already had an acceptable min cmake version.
>>>
>>> libssh failed to build so it was updated to 0.11.1 and this built successfully.
>>>
>>> Then I came to cdrkit!!!
>>>
>>> This failed to build due to too low a min version so I changed the min version from 2.8 to 3.25 but it the failed to build due to the cmake_policy(SET CMPOO15 OLD) and OLD is no longer allowed. It has to be NEW.
>>> So I changed the policy to NEW and then it starting building cdrkit but then the build failed due to the fact that it could not find xconfig.h
>>> In the source file there is xconfig.h.in but it is not getting built into xconfig.h
>>>
>>> I checked for the existing build that works and found that there were 83 CMAKE Warnings, all related to the fact that Policy CMP0115 is not set. The cmake_policy value in the existing patch was set at CMP0015 so I also tried using cmake_policy(SET CMP0115 NEW) but that still stopped with the missing xconfig.h
>>>
>>> It looks like the NEW cmake_policy no longer allows error to be ignored and building to continue as has been the case up to date.
>>>
>>> It looks to me like the only way to fix it is to update cdrkit to properly work with the latest cmake but as the existing version was released 15 years ago and nothing further has been done with it I think it will not get fixed.
>>>
>>> There is also cdrtools but there are some questions raised by some distros about it's licence. However the developer of that package died and so nothing further has been done with that for the last 7 years.
>>>
>>> I did find that there is a project called libburnia that has a command line package called xorrisofs which emulates mkisofs.
>>> All the mkisofs options that we use in IPFire are available with xorrisofs. The project had the last release of xorriso in 2023 but it looks like the package is released around every two years. The last commits for the project were done 2 weeks ago and there looks to be a continuing ongoing level of commit updates being done.
>>>
>>> Would it be worthwhile for me to look at building this package and make the changes in the cdrom sections to use xorrisofs instead of mkisofs and see if its emulation of mkisofs produces a working IPFire iso that can be successfully installed and run?
>>>
>>> If the answer is not a simple one to give then we can discuss this issue in the monthly video conf on Monday.
>>>
>>> I will comment out cdrkit in my make.sh so I can check out if the other packages that use cmake (12 of them) can all be made to work with the latest cmake.
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problem building cdrkit with latest cmake
2025-05-09 10:02 ` Adolf Belka
@ 2025-05-09 12:33 ` Michael Tremer
0 siblings, 0 replies; 5+ messages in thread
From: Michael Tremer @ 2025-05-09 12:33 UTC (permalink / raw)
To: Adolf Belka; +Cc: IPFire: Development-List
Hello,
> On 9 May 2025, at 11:02, Adolf Belka <adolf.belka@ipfire.org> wrote:
>
> Hi Michael,
>
> On 08/05/2025 21:00, Adolf Belka wrote:
>> Hi Michael,
>> On 08/05/2025 15:19, Michael Tremer wrote:
>>> Hello Adolf,
>>>
>>> Yet another success store of an alternative to configure/make/make install.
>>>
>>> I remember this from IPFire 3 where we have made the transition to libburn. It needs three packages:
>>>
>>> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libburn/libburn.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
>>> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libisofs/libisofs.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
>>> https://git.ipfire.org/?p=ipfire-3.x.git;a=blob;f=libisoburn/libisoburn.nm;hb=f1a186fd032e8e5718e41120a27103c83ed69a3e
>>>
>>> We are using the whole thing here:
>>>
>>> https://git.ipfire.org/?p=people/ms/bricklayer.git;a=blob;f=src/bricklayer-master.in;hb=3b216919f31dc6ca3b44d9d25536626b60aea9f1#l527
>>>
>>> So it seems to generate a bootable ISO and that is all we need.
>>>
>>> Happy to make the transition in IPFire 2 as well.
>> I think for IPFire-2 we can just use the xorriso package that libburn supplies to the Gnu Project.
>> This is a self contained source tarball that includes the bits from libisofs and libisoburn, sufficient to do the cli commands for xorriso and xorrisofs.
>> https://www.gnu.org/software/xorriso/
>> I think this makes it simpler for IPFire-2 and it supplies what is needed for creating a bootable ISO.
>> My plan would be to follow this path unless you think that installing the three full packages that you listed is the better thing to do also for IPFire-2.
>
> I did a test build of the xorriso package and made a symbolic link of xorrisofs to mkisofs in the LFS so that no changes should be needed anywhere else. Anything using mkisofs would then use xorrisofs with the same arguments as used for mkisofs.
>
> It successfully produced an iso, which was bootable as I was able to install IPFire with it onto my vm testbed.
That is good news.
> Couldn't test out the making of the backupiso as that downloads the current released iso and my test build is with CU195.
>
> Are you okay with using the xorriso source tarball or should I do a build and patch submit with the full libburn, libisofs & libisoburn packages?
We don’t have any other use for the libraries, so I am happy to take the fast path - provided it is also being updated regularly like the other packages.
> The Gnu xorriso site says
>
> " Software copies included in GNU xorriso:
> GNU xorriso is feature-wise equivalent to the dynamic compilation of libburnia libraries, libjte, and libburnia program xorriso. It restricts itself to a technical form where the legal commitments of the libburnia project and the legal intentions of FSF match completely."
>
> so it is clearly a limited form but it looks like it should be sufficient for IPFire-2.x.
Perfect! No idea why I made it so complicated in IPFire 3. Maybe because I don’t like bundled libraries :)
-Michael
> Regards,
>
> Adolf.
>
>> Regards,
>> Adolf.
>>>
>>> -Michael
>>>
>>>> On 8 May 2025, at 13:53, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>
>>>> Hi Everyone.
>>>>
>>>> I found that curl had three updates for a range of bug fixes and so I went ahead and ran a build of curl-1.13.0. It built without any problems.
>>>>
>>>> However cmake, a couple of steps later failed to build because of some changes in curl to certain names.
>>>>
>>>> So I installed the latest cmake and then curl and cmake both built without any issues.
>>>>
>>>> Then json-c failed due to the min ver of cmake being supported is now 3.5 and in the near future this will be changed to 3.10.
>>>>
>>>> I found a patch from json-c that changed the minimum required version from 2.8 to 3.9...3.12 and json-c then successfully built.
>>>>
>>>> libjpeg successfully built as it already had an acceptable min cmake version.
>>>>
>>>> libssh failed to build so it was updated to 0.11.1 and this built successfully.
>>>>
>>>> Then I came to cdrkit!!!
>>>>
>>>> This failed to build due to too low a min version so I changed the min version from 2.8 to 3.25 but it the failed to build due to the cmake_policy(SET CMPOO15 OLD) and OLD is no longer allowed. It has to be NEW.
>>>> So I changed the policy to NEW and then it starting building cdrkit but then the build failed due to the fact that it could not find xconfig.h
>>>> In the source file there is xconfig.h.in but it is not getting built into xconfig.h
>>>>
>>>> I checked for the existing build that works and found that there were 83 CMAKE Warnings, all related to the fact that Policy CMP0115 is not set. The cmake_policy value in the existing patch was set at CMP0015 so I also tried using cmake_policy(SET CMP0115 NEW) but that still stopped with the missing xconfig.h
>>>>
>>>> It looks like the NEW cmake_policy no longer allows error to be ignored and building to continue as has been the case up to date.
>>>>
>>>> It looks to me like the only way to fix it is to update cdrkit to properly work with the latest cmake but as the existing version was released 15 years ago and nothing further has been done with it I think it will not get fixed.
>>>>
>>>> There is also cdrtools but there are some questions raised by some distros about it's licence. However the developer of that package died and so nothing further has been done with that for the last 7 years.
>>>>
>>>> I did find that there is a project called libburnia that has a command line package called xorrisofs which emulates mkisofs.
>>>> All the mkisofs options that we use in IPFire are available with xorrisofs. The project had the last release of xorriso in 2023 but it looks like the package is released around every two years. The last commits for the project were done 2 weeks ago and there looks to be a continuing ongoing level of commit updates being done.
>>>>
>>>> Would it be worthwhile for me to look at building this package and make the changes in the cdrom sections to use xorrisofs instead of mkisofs and see if its emulation of mkisofs produces a working IPFire iso that can be successfully installed and run?
>>>>
>>>> If the answer is not a simple one to give then we can discuss this issue in the monthly video conf on Monday.
>>>>
>>>> I will comment out cdrkit in my make.sh so I can check out if the other packages that use cmake (12 of them) can all be made to work with the latest cmake.
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-05-09 12:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-05-08 12:53 Problem building cdrkit with latest cmake Adolf Belka
2025-05-08 13:19 ` Michael Tremer
2025-05-08 19:00 ` Adolf Belka
2025-05-09 10:02 ` Adolf Belka
2025-05-09 12:33 ` Michael Tremer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox