Re: Fwd: Problem with reprotest-kernel
On Thu, May 14, 2020 at 09:11:51PM +0200, Evangelos Ribeiro Tzaras wrote:
> 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
> >>
> >>
> >> Subject: Problem with reprotest-kernel
> >> Date: Thu, 14 May 2020 15:44:21 +0200
> >> From: Evangelos Ribeiro Tzaras <devrtz@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?
Good question. Sadly I can't tell what the differences are between
the testbed and the non-testbed. Hopefully is the answer to the
original problem in making the non-testbed more like the testbed.
> >> 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
> >>
Regards
Geert Stappers
P.S.
I'm on both mailinglists, no need to CC me.
--
Silence is hard to parse
Reply to: