After some further investigation, I have figured out a solution.
Changing the build dependency to the -dev package (from libzbar0 to
libzbar-dev) has fixed the failing reprotest-kernel job. I tried this
out after reading that ctypes.util.find_library is usually used to
lookup build-time dependencies rather than run-time dependencies.
Local builds and other reprotest variations work fine without the -dev
package. Can someone share some insight into why reprotest-kernel needs
the -dev package?
Thanks in advance
On 5/14/20 9:11 PM, Evangelos Ribeiro Tzaras wrote:
> Thank you for your comment
>
> On 5/14/20 8:47 PM, Geert Stappers wrote:
>> On Thu, May 14, 2020 at 07:27:26PM +0200, Evangelos Ribeiro Tzaras wrote:
>>> Hello,
>>>
>>> I have a problem with reprotest on a python package I am building
>>> and was recently made aware of this mailinglist.
>>>
>>> Can anyone tell me what's going on, how I can further debug my issue or
>>> ideally how I should fix the issue of a failing reprotest-kernel build?
>>>
>>> Thanks in advance
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: Problem with reprotest-kernel
>>> Date: Thu, 14 May 2020 15:44:21 +0200
>>> From: Evangelos Ribeiro Tzaras <dev...@fortysixandtwo.eu>
>>> To: debian-python@lists.debian.org
>>>
>>> Hello,
>>>
>>> I need some help with a failing reprotest-kernel (other reprotest works)
>>> build (both on CI and locally). My package python3-pyzbar provides
>>> bindings for libzbar0.
>>> The failure occurs while running the build-time tests for
>>> build-experiment-1 [1].
>>>
>>> Effectively the ImportError is raised here [2]:
>>> ctypes.util.find_library('zbar') returns None in build-experiment-1
>>> (testbed still works).
>>
>> My first impression would be a missing build dependency.
>>
>
> Maybe I am missing something obvious, but why would the build (and the
> failing test) succeed in the testbed if a dependency were missing?
>
>>
>>> So far I found out that uname -a prints 4.9.0-12-amd64 for testbed and
>>> 2.6.69-12-amd64 for build-experiment-1. On a local build I have seen
>>> some "FATAL: kernel too old" messages[3], but they don't show up in the
>>> logs[4], so I am wondering if it also happens on the CI but also does
>>> not show in the logs.
>>>
>>> A quick ddg search yielded [5] . Can anyone give me any insights?
>>> Because I feel disabling the kernel variation (without fully
>>> understanding the issue) is not the winning move here :)
>>>
>>> Thanks in advance
>>>
>>> [1] https://salsa.debian.org/devrtz/pyzbar/-/jobs/738921#L1116
>>> [2]
>>> https://salsa.debian.org/devrtz/pyzbar/-/blob/master/pyzbar/zbar_library.py#L63
>>> [3] https://fortysixandtwo.eu/img/reprotest_kernel_too_old.png
>>> [4] https://fortysixandtwo.eu/img/reprotest_too_old_not_in_log.png
>>> [5]
>>> http://debian.2.n7.nabble.com/Bug-928921-reprotest-kernel-too-old-SIGSEGV-td4512112.html
>>>
>>
>>
>> Groeten
>> Geert Stappers
>>
>
> Evangelos Ribeiro Tzaras
>
Evangelos Ribeiro Tzaras
