Getting condor builds reproducible

[Tim Theisen]

I am happy to report condor builds show as reproducible across all 
platforms on the tracker page. All patches have been accepted upstream 
and I will be able to drop all patches with the July (HTCondor 25.12) 
release.

...Tim

On 5/25/26 09:18, Tim Theisen wrote:
> Hello Vagrant,
>
> This only needs to be a simple boolean. So, upstream has already 
> adopted the following fix to build/cmake/CondorConfigure.cmake:
>
> -add_definitions(-D${OS_NAME}="${OS_NAME}_${OS_VER}")
> +add_definitions(-D${OS_NAME}=1)
>
> https://github.com/htcondor/htcondor/pull/4500
>
> I will apply the patch and submit a new build.
>
> Thank you for the assistance.
>
> ...Tim
>
> On 5/24/26 20:22, Vagrant Cascadian wrote:
>> On 2026-05-24, Tim Theisen wrote:
>>> Thank you for this insight. I will take care of the -DLINUX issue with
>>> condor. I can work directly with the developers to see what all the
>>> ramifications are.
>> Great, always best to get stuff upstream, as it helps other
>> distributions as well!
>>
>> Please let us know the end results when you have more information.
>>
>>
>> For completeness, a few more hopefully useful comments below, since I
>> already tested the builds...
>>
>>
>>>> On 2026-05-24, Vagrant Cascadian wrote:
>>>>> During a local build I see various build arguments passing the kernel
>>>>> version:
>>>>>
>>>>>     /usr/bin/c++ -DCONDOR_VERSION=\"25.10.1\" -DHAVE_CONFIG_H
>>>>>     -DLINUX=\"LINUX_6.12.90+DEB13-AMD64\" ...
>>>>>
>>>>> This is probably a permutation of this issue:
>>>>>
>>>>> https://tests.reproducible-builds.org/debian/issues/unstable/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
>>>>>
>>>>> Probably caused by the use of CMAKE_SYSTEM_VERSION:
>>>>>
>>>>>     CMakeLists.txt-string( TOUPPER "${CMAKE_SYSTEM_NAME}" OS_NAME )
>>>>>     CMakeLists.txt:string( TOUPPER "${CMAKE_SYSTEM_VERSION}" OS_VER )
>>>>>     CMakeLists.txt-string( TOUPPER "${CMAKE_SYSTEM_PROCESSOR}" 
>>>>> SYS_ARCH )
>>>>>
>>>>> Not sure if just removing that line entirely, or providing a 
>>>>> "REDACTED"
>>>>> string would be an option here... we have the buildd.debian.org 
>>>>> logs to
>>>>> get information like that if needed, rather than embedding in the
>>>>> binaries.
>> I tried both removing it entirely and using "REDACTED" and both worked
>> about the same (e.g. passing -DLINUX=\"LINUX_\"
>>
>> I also tried adjusting build/cmake/CondorConfigure.cmake:
>>
>> -add_definitions(-D${OS_NAME}="${OS_NAME}_${OS_VER}")
>> +add_definitions(-D${OS_NAME}="${OS_NAME}")
>>
>> Which also worked.
>>
>> In theory, putting that add_definition in a conditional and passing a
>> -DOS_NAME_VALUE or similar to configure might be another approach,
>> although this would require intervention on the package maintainers for
>> each and every distro, which is less ideal.
>>
>>
>>>> It seems to build by replacing OS_VER with "REDACTED" ... although
>>>> passes:
>>>>
>>>>     -DLINUX=\"LINUX_\"
>>>>
>>>> And it dramatically reduced the diffoscope output (from hundreds of
>>>> megabytes to ~10MB)! Checking another build to see if I can figure out
>>>> what is left...
>> The only other issue is build path related, but that is normalized
>> across most of the build environments for most distros...
>>
>>
>> live well,
>>    vagrant
>
-- 
Tim Theisen (he, him, his)
Release Manager
Center for High Throughput Computing
University of Wisconsin - Madison
3695 Morgridge Hall
1205 University Ave
Madison, WI 53706