Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12581 > unrolled thread

Problem with reprotest-kernel

Back to article view | Back to linux.debian.maint.python

Contents

  Problem with reprotest-kernel Evangelos Ribeiro Tzaras <devrtz@fortysixandtwo.eu> - 2020-05-14 15:50 +0200
    Re: Fwd: Problem with reprotest-kernel Geert Stappers <stappers@stappers.nl> - 2020-05-14 20:50 +0200
      Re: Fwd: Problem with reprotest-kernel Evangelos Ribeiro Tzaras <devrtz@fortysixandtwo.eu> - 2020-05-14 21:20 +0200
        Re: Fwd: Problem with reprotest-kernel Geert Stappers <stappers@stappers.nl> - 2020-05-14 21:30 +0200
        Re: Fwd: Problem with reprotest-kernel Evangelos Ribeiro Tzaras <devrtz@fortysixandtwo.eu> - 2020-05-17 17:30 +0200
          Re: Problem with reprotest-kernel, my build attempt fails Geert Stappers <stappers@stappers.nl> - 2020-05-18 18:30 +0200

#12581 — Problem with reprotest-kernel

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

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

-- 
Evangelos Ribeiro Tzaras

[toc] | [next] | [standalone]

#12582

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


> 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
-- 
Silence is hard to parse

[toc] | [prev] | [next] | [standalone]

#12583

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

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

[toc] | [prev] | [next] | [standalone]

#12584

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

[toc] | [prev] | [next] | [standalone]

#12600

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

[toc] | [prev] | [next] | [standalone]

#12608 — Re: Problem with reprotest-kernel, my build attempt fails

On Sun, May 17, 2020 at 05:22:49PM +0200, Evangelos Ribeiro Tzaras wrote:
> On 5/14/20 9:11 PM, 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
> >>>
> >>>
> >>> -------- Forwarded Message --------
> >>> 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.
> >>>
> >>> Effectively the ImportError is raised here:
> >>> 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?
> > 
> 
> 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
> 

> Can someone share some insight into why reprotest-kernel needs the -dev package?
} Can someone share some insight into why building reprotest-kernel needs the -dev package?

 -dev is a naming convention

Those packages contain the development files.  (stuff that the compiler needs)


Regards
Geert Stappers
-- 
Silence is hard to parse

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web