From vagrant at reproducible-builds.org  Mon May 25 01:03:05 2026
From: vagrant at reproducible-builds.org (Vagrant Cascadian)
Date: Sun, 24 May 2026 17:03:05 -0700
Subject: Getting condor builds reproducible
In-Reply-To: <875x4czcy3.fsf@wireframe>
References: <474974de-12b1-4838-a6b7-d8b657168e9d@cs.wisc.edu>
 <87h5nxaeca.fsf@wireframe> <875x4czcy3.fsf@wireframe>
Message-ID: <8733zgz77q.fsf@wireframe>

On 2026-05-24, Vagrant Cascadian wrote:
> On 2026-05-23, Vagrant Cascadian wrote:
>> On 2026-05-22, Tim Theisen wrote:
>>> Now that reproducible builds are mandatory, I am working on getting 
>>> condor to meet those requirements.
> ...
>>> It claims that there was a regression in reproducibility on i386 it that 
>>> is blocking promotion. None of the recent changes should caused this.
>>
>> It is entirely possible that there is some non-deterministic
>> issue... such as an ordering issue with a reasonable chance to come out
>> reproducible, but some N out of 100 times comes out different.
>>
>> A hunch would be to check the version of the kernel that was used in
>> both builds, as there have been a lot of kernel security updates
>> lately... and those versions can sometimes get embedded in builds. That
>> is not something that is intentionally varied, but due to security
>> updates, sometimes that can cause issues.
>
> Ok, my hunch has a little more background to go on that this is at least
> part of the issue...
>
> 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.

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...


> buildd.debian.org and reproduce.debian.net might end up with a different
> version depending on the timing and frequency of kernel updates being
> available and applied, which might lead to inconsistant reproducibility
> results.

Yes, this is exactly what happened on i386:

  https://buildd.debian.org/status/fetch.php?pkg=condor&arch=i386&ver=25.10.1%2Bdfsg-1&stamp=1778880751&raw=0

  -DLINUX=\"LINUX_6.12.86+DEB13-AMD64\"

And on reproduce.debian.net:

  https://reproduce.debian.net/i386/api/v1/builds/208996/log

  -DLINUX=\"LINUX_6.12.88+DEB13-AMD64\"

For the corresponding amd64 logs, they were running the same
kernel. Probably the same for other architectures too...


> I think tests.reproducible-builds.org may not actually be varying the
> kernel version, though at least historically the intention is to vary
> the kernel version (e.g. use a backports kernel and a stable kernel
> across two builds).

We should really ensure tests.r-b.o is systematically testing different
kernel versions... since buildd.debian.org/reproduce.debian.net may run
arbitrary kernel versions that will be out of sync on occasion, we want
some way to catch that.

I do not think it is reasonable for reproduce.debian.net to run the
original running kernel version (E.g. running a security vulnerable
kernel) in the build environment just to get reproducible builds...


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260524/7d0694ff/attachment.sig>

From tim at cs.wisc.edu  Mon May 25 01:15:57 2026
From: tim at cs.wisc.edu (Tim Theisen)
Date: Sun, 24 May 2026 19:15:57 -0500
Subject: Getting condor builds reproducible
In-Reply-To: <8733zgz77q.fsf@wireframe>
References: <474974de-12b1-4838-a6b7-d8b657168e9d@cs.wisc.edu>
 <87h5nxaeca.fsf@wireframe> <875x4czcy3.fsf@wireframe>
 <8733zgz77q.fsf@wireframe>
Message-ID: <c2c7034b-0b68-435d-a316-823f530a09c7@cs.wisc.edu>

Hello Vagrant,

This 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.

...Tim

On 5/24/26 19:03, Vagrant Cascadian wrote:
> On 2026-05-24, Vagrant Cascadian wrote:
>> On 2026-05-23, Vagrant Cascadian wrote:
>>> On 2026-05-22, Tim Theisen wrote:
>>>> Now that reproducible builds are mandatory, I am working on getting
>>>> condor to meet those requirements.
>> ...
>>>> It claims that there was a regression in reproducibility on i386 it that
>>>> is blocking promotion. None of the recent changes should caused this.
>>> It is entirely possible that there is some non-deterministic
>>> issue... such as an ordering issue with a reasonable chance to come out
>>> reproducible, but some N out of 100 times comes out different.
>>>
>>> A hunch would be to check the version of the kernel that was used in
>>> both builds, as there have been a lot of kernel security updates
>>> lately... and those versions can sometimes get embedded in builds. That
>>> is not something that is intentionally varied, but due to security
>>> updates, sometimes that can cause issues.
>> Ok, my hunch has a little more background to go on that this is at least
>> part of the issue...
>>
>> 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.
> 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...
>
>
>> buildd.debian.org and reproduce.debian.net might end up with a different
>> version depending on the timing and frequency of kernel updates being
>> available and applied, which might lead to inconsistant reproducibility
>> results.
> Yes, this is exactly what happened on i386:
>
>    https://buildd.debian.org/status/fetch.php?pkg=condor&arch=i386&ver=25.10.1%2Bdfsg-1&stamp=1778880751&raw=0
>
>    -DLINUX=\"LINUX_6.12.86+DEB13-AMD64\"
>
> And on reproduce.debian.net:
>
>    https://reproduce.debian.net/i386/api/v1/builds/208996/log
>
>    -DLINUX=\"LINUX_6.12.88+DEB13-AMD64\"
>
> For the corresponding amd64 logs, they were running the same
> kernel. Probably the same for other architectures too...
>
>
>> I think tests.reproducible-builds.org may not actually be varying the
>> kernel version, though at least historically the intention is to vary
>> the kernel version (e.g. use a backports kernel and a stable kernel
>> across two builds).
> We should really ensure tests.r-b.o is systematically testing different
> kernel versions... since buildd.debian.org/reproduce.debian.net may run
> arbitrary kernel versions that will be out of sync on occasion, we want
> some way to catch that.
>
> I do not think it is reasonable for reproduce.debian.net to run the
> original running kernel version (E.g. running a security vulnerable
> kernel) in the build environment just to get reproducible builds...
>
>
> 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



From holger at layer-acht.org  Mon May 25 02:07:43 2026
From: holger at layer-acht.org (Holger Levsen)
Date: Mon, 25 May 2026 01:07:43 +0000
Subject: Getting condor builds reproducible
In-Reply-To: <8733zgz77q.fsf@wireframe>
References: <474974de-12b1-4838-a6b7-d8b657168e9d@cs.wisc.edu>
 <87h5nxaeca.fsf@wireframe> <875x4czcy3.fsf@wireframe>
 <8733zgz77q.fsf@wireframe>
Message-ID: <ahOg39PbDsQzkSdm@layer-acht.org>

On Sun, May 24, 2026 at 05:03:05PM -0700, Vagrant Cascadian wrote:
> I do not think it is reasonable for reproduce.debian.net to run the
> original running kernel version (E.g. running a security vulnerable
> kernel) in the build environment just to get reproducible builds...

I very much agree! :)

(I also applaud your other findings in that mail I'm replying too. They are
 just not as 'simple' as this one. As if anything here would be simple.)


-- 
cheers,
	Holger

 ???????
 ???????  holger@(debian|reproducible-builds|layer-acht).org
 ???????  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ???

AI is for our brains what cars are for our legs. (Tom?? Peltan)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260525/2a576395/attachment.sig>

From vagrant at reproducible-builds.org  Mon May 25 02:22:38 2026
From: vagrant at reproducible-builds.org (Vagrant Cascadian)
Date: Sun, 24 May 2026 18:22:38 -0700
Subject: Getting condor builds reproducible
In-Reply-To: <c2c7034b-0b68-435d-a316-823f530a09c7@cs.wisc.edu>
References: <474974de-12b1-4838-a6b7-d8b657168e9d@cs.wisc.edu>
 <87h5nxaeca.fsf@wireframe> <875x4czcy3.fsf@wireframe>
 <8733zgz77q.fsf@wireframe>
 <c2c7034b-0b68-435d-a316-823f530a09c7@cs.wisc.edu>
Message-ID: <87zf1oxoyp.fsf@wireframe>

On 2026-05-24, Tim Theisen wrote:
> This 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260524/2c9eb393/attachment.sig>

From tim at cs.wisc.edu  Mon May 25 15:18:48 2026
From: tim at cs.wisc.edu (Tim Theisen)
Date: Mon, 25 May 2026 09:18:48 -0500
Subject: Getting condor builds reproducible
In-Reply-To: <87zf1oxoyp.fsf@wireframe>
References: <474974de-12b1-4838-a6b7-d8b657168e9d@cs.wisc.edu>
 <87h5nxaeca.fsf@wireframe> <875x4czcy3.fsf@wireframe>
 <8733zgz77q.fsf@wireframe> <c2c7034b-0b68-435d-a316-823f530a09c7@cs.wisc.edu>
 <87zf1oxoyp.fsf@wireframe>
Message-ID: <dc59a2ab-efa0-4c6b-8787-306587fe66e1@cs.wisc.edu>

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



From doko at debian.org  Tue May 26 11:49:06 2026
From: doko at debian.org (Matthias Klose)
Date: Tue, 26 May 2026 12:49:06 +0200
Subject: Bug#1137648: dh-strip-nondeterminism doesn't handle timestamps in
 gcc-bpf's libgcc.a
Message-ID: <e9fcf97b-68fa-471b-ae1a-5eaa47ddbe9f@debian.org>

Package: dh-strip-nondeterminism
Version: 1.15.0-1
Severity: serious
Tags: sid forky

see
https://reproduce.debian.net/amd64/api/v1/builds/256496/artifacts/655740/diffoscope

filing as RC, because that keeps out gcc-bpf and dtrace out of testing.


From owner at bugs.debian.org  Tue May 26 11:57:01 2026
From: owner at bugs.debian.org (Debian Bug Tracking System)
Date: Tue, 26 May 2026 10:57:01 +0000
Subject: Processed: lolwut
References: <ahV8GGApMIR8Of8S@layer-acht.org>
Message-ID: <handler.s.C.17797929281749847.transcript@bugs.debian.org>

Processing commands for control at bugs.debian.org:

> severity 1137648 normal
Bug #1137648 [dh-strip-nondeterminism] dh-strip-nondeterminism doesn't handle timestamps in gcc-bpf's libgcc.a
Severity set to 'normal' from 'serious'
> # justification lolwut
> # failing to clean *your* mess is hardly a serious problem of strip-nd
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1137648: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1137648
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems


From tim at cs.wisc.edu  Tue May 26 14:23:44 2026
From: tim at cs.wisc.edu (Tim Theisen)
Date: Tue, 26 May 2026 08:23:44 -0500
Subject: Getting condor builds reproducible
In-Reply-To: <dc59a2ab-efa0-4c6b-8787-306587fe66e1@cs.wisc.edu>
References: <474974de-12b1-4838-a6b7-d8b657168e9d@cs.wisc.edu>
 <87h5nxaeca.fsf@wireframe> <875x4czcy3.fsf@wireframe>
 <8733zgz77q.fsf@wireframe> <c2c7034b-0b68-435d-a316-823f530a09c7@cs.wisc.edu>
 <87zf1oxoyp.fsf@wireframe> <dc59a2ab-efa0-4c6b-8787-306587fe66e1@cs.wisc.edu>
Message-ID: <6521fa69-1481-4e1f-b99c-f9ef165ce059@cs.wisc.edu>

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



From chris at reproducible-builds.org  Tue May 26 19:33:17 2026
From: chris at reproducible-builds.org (Chris Lamb)
Date: Tue, 26 May 2026 11:33:17 -0700
Subject: Bug#1137648: Processed: lolwut
In-Reply-To: <handler.s.C.17797929281749847.transcript@bugs.debian.org>
References: <ahV8GGApMIR8Of8S@layer-acht.org>
 <handler.s.C.17797929281749847.transcript@bugs.debian.org>
 <e9fcf97b-68fa-471b-ae1a-5eaa47ddbe9f@debian.org>
Message-ID: <a81e748a-3e8c-4597-a53e-bc8c14fcb5ca@app.fastmail.com>

Debian Bug Tracking System wrote:

>> severity 1137648 normal
> Bug #1137648 [dh-strip-nondeterminism] dh-strip-nondeterminism doesn't 
> handle timestamps in gcc-bpf's libgcc.a
> Severity set to 'normal' from 'serious'

Heads up that the .ar handler was disabled in December 2018:

 strip-nondeterminism (1.0.0-1) unstable; urgency=medium
 .
   * Ignore encrypted .zip files as we can never normalise them.
     (Closes: #852207)
   * Drop .ar handler; binutils is reproducible. (Closes: #781262, #843811)
     - Update debian/copyright to drop reference to ar.pm.
   * Remove javaproperties handler after Emmanuel Bourg's patch was released in
     openjdk-11 11.0.1+13-3. (Closes: #914289)

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843811#32 for more
context.


Best wishes,

-- 
      o
    ?   ?      Chris Lamb
   o     o     reproducible-builds.org ?
    ?   ?
      o


From serdii at point3.gmobb.jp  Thu May 28 15:16:19 2026
From: serdii at point3.gmobb.jp (Lernakademie Plus)
Date: Thu, 28 May 2026 16:16:19 +0200
Subject: =?utf-8?q?Dein_Erste-Hilfe-Zertifikat_=E2=80=93_heute_noch_fertig?=
Message-ID: <20260528141629.C69ED7DC75@smtp3.gmobb.jp>

 
   
      	 
    
 	 
    
Schnell & Einfach zum Zertifikat
 	 
    Mit diesem Online-Erste-Hilfe-Kurs erh?ltst du dein offizielles Zertifikat bequem von zu Hause aus ? ohne Termine und ohne Stress.
 Ideal f?r F?hrerschein, Arbeit oder Studium.
 	 
      Deine Vorteile:  
100% online ? jederzeit verf?gbar 
Offiziell anerkanntes Zertifikat 
Kein Termin n?tig 
Sofort starten & flexibel lernen 
  	 
    Einmaliger Zugang ? ohne versteckte Kosten
 Preis: siehe Angebotsseite
 	 
    Jetzt starten  	 
    Erste Hilfe Kurs Online
 ? 2026 Alle Rechte vorbehalten
 Abmelden
 	 
  	 
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260528/fef7fc24/attachment.htm>

