[opensuse-packaging] rpmlint, or whatever checks

older
[opensuse-packaging] metadata error

Ruediger Meier

27 Feb 2014 27 Feb '14

15:29

Hi, I never got it how to get straight forward around build failures which are caused by package checks. In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 .... I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0) Is this an rpmlint issue at all? Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Show replies by date

Marcus Meissner

27 Feb 27 Feb

15:33

On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:

...

Hi,

I never got it how to get straight forward around build failures which are caused by package checks.

In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....

I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)

Is this an rpmlint issue at all?

Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.

Fix the original bug and do not work around it. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ruediger Meier

15:38

On Thursday 27 February 2014, Marcus Meissner wrote:

...

On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:

...
Hi,

I never got it how to get straight forward around build failures which are caused by package checks.

In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....

I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)

Is this an rpmlint issue at all?

Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.

Fix the original bug and do not work around it.

That wasn't my question. It's a gcc bug. How should I fix it for SLE 11? And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right? cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andreas Schwab

15:42

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

Ruediger Meier writes:

...

It's a gcc bug.

Is it?

...

And it's just a gcc warning not an error.

It's a potentially serious warning. Don't ignore it.

...

I mean it should be possible to build an rpm from valid C code right?

Is it valid C code? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ruediger Meier

15:52

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On Thursday 27 February 2014, Andreas Schwab wrote:

...

Ruediger Meier writes:

...
It's a gcc bug.

Is it?

Yes, like this: http://gcc.gnu.org/ml/gcc-help/2008-02/msg00304.html

...

...
And it's just a gcc warning not an error.

It's a potentially serious warning. Don't ignore it.

No it's not a serious warning. It's a gcc bug. This is a questions which I have already solved. Now I just want to get around this.

...

...
I mean it should be possible to build an rpm from valid C code right?

Is it valid C code?

I think yes: v->rvsn = hextou(++bp, &bp); cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Cristian Morales Vega

16:19

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On 27 February 2014 15:52, Ruediger Meier wrote:

...

On Thursday 27 February 2014, Andreas Schwab wrote:

...
Is it valid C code?

I think yes: v->rvsn = hextou(++bp, &bp);

It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andrey Borzenkov

16:26

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On Thu, Feb 27, 2014 at 8:19 PM, Cristian Morales Vega wrote:

...

On 27 February 2014 15:52, Ruediger Meier wrote:

...
On Thursday 27 February 2014, Andreas Schwab wrote:

...
Is it valid C code?

I think yes: v->rvsn = hextou(++bp, &bp);

It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.

May be I miss something obvious here, but how can ++bp (which changed *value* of bp) have any effect on &bp (which takes *address* of bp)? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Cristian Morales Vega

16:34

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On 27 February 2014 16:26, Andrey Borzenkov wrote:

...

On Thu, Feb 27, 2014 at 8:19 PM, Cristian Morales Vega wrote:

...
On 27 February 2014 15:52, Ruediger Meier wrote:

...
On Thursday 27 February 2014, Andreas Schwab wrote:

...
Is it valid C code?

I think yes: v->rvsn = hextou(++bp, &bp);

It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.

May be I miss something obvious here, but how can ++bp (which changed *value* of bp) have any effect on &bp (which takes *address* of bp)?

My bad. Having gcc at my side I didn't think this through... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andreas Schwab

16:34

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

Cristian Morales Vega writes:

...

On 27 February 2014 15:52, Ruediger Meier wrote:

...
On Thursday 27 February 2014, Andreas Schwab wrote:

...
Is it valid C code?

I think yes: v->rvsn = hextou(++bp, &bp);

It's not. What's the value of "&bp"? Without a sequence point in the middle you can't guarantee "++bp" has taken effect.

There is a sequence point before the function call. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andrey Borzenkov

16:24

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On Thu, Feb 27, 2014 at 7:52 PM, Ruediger Meier wrote:

...

On Thursday 27 February 2014, Andreas Schwab wrote:

...
Ruediger Meier writes:

...
It's a gcc bug.

Is it?

Yes, like this: http://gcc.gnu.org/ml/gcc-help/2008-02/msg00304.html

...
...
And it's just a gcc warning not an error.

It's a potentially serious warning. Don't ignore it.

No it's not a serious warning. It's a gcc bug. This is a questions which I have already solved. Now I just want to get around this.

Is adding pragma around this code an option? I do not have example ready right now, but would be something like

...

...
...
I mean it should be possible to build an rpm from valid C code right?

Is it valid C code?

I think yes:

#pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wsequence-point"

...

v->rvsn = hextou(++bp, &bp);

#pragma GCC diagnostic pop -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andreas Schwab

16:25

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

Ruediger Meier writes:

...

v->rvsn = hextou(++bp, &bp);

What is hextou? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Jean Delvare

22:26

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

Le Thursday 27 February 2014 à 17:25 +0100, Andreas Schwab a écrit :

...

Ruediger Meier writes:

...
v->rvsn = hextou(++bp, &bp);

What is hextou?

Some kind of curse probably, beware! -- Jean Delvare Suse L3 Support -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Bernhard Voelker

16:33

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On 02/27/2014 04:52 PM, Ruediger Meier wrote:

...

v->rvsn = hextou(++bp, &bp);

At least it's pretty ugly. And even if it works today - it most probably won't anymore if someone changes hextou into a macro (or if it is one today: if someone changes it into a function). Therefore it is at least bad to maintain. I'd split off the ++bp into a separate statement. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Cristian Rodríguez

28 Feb 28 Feb

02:52

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

El 27/02/14 13:33, Bernhard Voelker escribió:

...

On 02/27/2014 04:52 PM, Ruediger Meier wrote:

...
v->rvsn = hextou(++bp, &bp);

At least it's pretty ugly. And even if it works today - it most probably won't anymore if someone changes hextou into a macro (or if it is one today: if someone changes it into a function). Therefore it is at least bad to maintain. I'd split off the ++bp into a separate statement.

Also, ++bp may be evaluated more than once in the case of a macro.. and that's extremely difficult to debug. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Marcus Meissner

27 Feb 27 Feb

15:50

On Thu, Feb 27, 2014 at 04:38:09PM +0100, Ruediger Meier wrote:

...

On Thursday 27 February 2014, Marcus Meissner wrote:

...
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:

...
Hi,

I never got it how to get straight forward around build failures which are caused by package checks.

In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....

I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)

Is this an rpmlint issue at all?

Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.

Fix the original bug and do not work around it.

That wasn't my question. It's a gcc bug. How should I fix it for SLE 11?

Can you point me to your source code / project/package in OBS, then I can check this? gcc is usually right for this warning.

...

And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right?

- suppress the gcc warning - #!BuildIgnore post-build-checks I thought it should be able to suppress with rpmlint, but it might be that check_gcc_output just uses the same output format. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andreas Schwab

16:09

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

Marcus Meissner writes:

...

- #!BuildIgnore post-build-checks

This is too big of a hammer. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ruediger Meier

16:26

On Thursday 27 February 2014, Marcus Meissner wrote:

...

On Thu, Feb 27, 2014 at 04:38:09PM +0100, Ruediger Meier wrote:

...
On Thursday 27 February 2014, Marcus Meissner wrote:

...
On Thu, Feb 27, 2014 at 04:29:11PM +0100, Ruediger Meier wrote:

...
Hi,

I never got it how to get straight forward around build failures which are caused by package checks.

In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....

I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)

Is this an rpmlint issue at all?

Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.

Fix the original bug and do not work around it.

That wasn't my question. It's a gcc bug. How should I fix it for SLE 11?

Can you point me to your source code / project/package in OBS, then I can check this?

gcc is usually right for this warning.

See my other email in this thread in reply to Andreas. The complete source is in home:rudi_m:devel-snap/dateutils dateutils-0.2.7.git*.tar.xz [ 97s] build-aux/yuck-scmver.c: In function 'git_version': [ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined

...

...
And it's just a gcc warning not an error. I simply want to ignore it. I mean it should be possible to build an rpm from valid C code right?

- suppress the gcc warning

Ok thanks, I do this now because it has minimal impact: ... # work around false positive post-build-checks %if 0%{?sles_version} export CFLAGS="$RPM_OPT_FLAGS -Wno-sequence-point" %endif ... But it looks really ugly within spec file. I was hoping I could hide this in rpmlinrc or wherever.

...

- #!BuildIgnore post-build-checks

...

I thought it should be able to suppress with rpmlint, but it might be that check_gcc_output just uses the same output format.

Maybe this is something which needs to be fixed for SLE_11. I have already ugly lines in the spec file because it does not understand this rpmlintrc: ... # rpmlint complains about our release tarballs in / addFilter(".*-release-tarball.* suse-filelist-forbidden-fhs23 /release_obs_.*") ... while this works for all other distros. Actually it looks like SLE does not understand rpmlintrc at all. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andreas Schwab

16:36

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

Ruediger Meier writes:

...

[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined

This is probably the effect of inlining not properly maintaining sequence points. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Cristian Morales Vega

16:58

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On 27 February 2014 16:36, Andreas Schwab wrote:

...

Ruediger Meier writes:

...
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined

This is probably the effect of inlining not properly maintaining sequence points.

So the warning is "correct", but the code generation is wrong? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Andreas Schwab

17:02

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

Cristian Morales Vega writes:

...

On 27 February 2014 16:36, Andreas Schwab wrote:

...
Ruediger Meier writes:

...
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined

This is probably the effect of inlining not properly maintaining sequence points.

So the warning is "correct", but the code generation is wrong?

It was just a guess, since hextou is a static function. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ruediger Meier

17:05

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On Thursday 27 February 2014, Cristian Morales Vega wrote:

...

On 27 February 2014 16:36, Andreas Schwab wrote:

...
Ruediger Meier writes:

...
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined

This is probably the effect of inlining not properly maintaining sequence points.

So the warning is "correct", but the code generation is wrong?

As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries. The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Michael Matz

17:32

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

Hi, On Thu, 27 Feb 2014, Ruediger Meier wrote:

...

On Thursday 27 February 2014, Cristian Morales Vega wrote:

...
On 27 February 2014 16:36, Andreas Schwab wrote:

...
Ruediger Meier writes:

...
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined

This is probably the effect of inlining not properly maintaining sequence points.

So the warning is "correct", but the code generation is wrong?

As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries.

The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number.

The link you posted doesn't indicate a gcc bug, Diego was confused, it used macros, not function calls and amounted basically to *c++ = *c; and _that_ does correctly cause a warning (there really is no sequence point between lhs and rhs of assignments). Your case is different, there you had hextou(++bp, &bp); And now comes the guesses: probably hextou (a static function, not macro) uses the value of *arg2 (i.e. bp), as well as the incremented value. With a little inlining and depending on how hextou's code looks like, that can very well result in effectively the same code as the invalid one above. But as there's a sequence point right before calling the function, there actually is no problem, also not after inlining. So your case does show a gcc bug (in not properly maintaining sequence point rules over inlining, as Andreas said), the link you posted does not. Now, of course, nothing of that helps you in your problem, but perhaps is entertaining :) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Ruediger Meier

19:09

New subject: [opensuse-packaging] Re: rpmlint, or whatever checks

On Thursday 27 February 2014, Michael Matz wrote:

...

Hi,

On Thu, 27 Feb 2014, Ruediger Meier wrote:

...
On Thursday 27 February 2014, Cristian Morales Vega wrote:

...
On 27 February 2014 16:36, Andreas Schwab wrote:

...
Ruediger Meier writes:

...
[ 97s] build-aux/yuck-scmver.c:485: warning: operation on 'bp' may be undefined

This is probably the effect of inlining not properly maintaining sequence points.

So the warning is "correct", but the code generation is wrong?

As far as I understood, it's just a false positive warning. Seems to be fixed since gcc > 4.3. The was never a problem with the compiled binaries.

The link to the thread which I posted a few emails above indicates that there was a bug report about the issue. Unfortunately they didn't posted the bug number.

The link you posted doesn't indicate a gcc bug,

I just thought they are going to bug report this http://gcc.gnu.org/ml/gcc-help/2008-02/msg00320.html cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Dmitriy Perlow

15:41

Ruediger Meier Thu, 27 Feb 2014 18:29:11 +0300:

...

Hi,

I never got it how to get straight forward around build failures which are caused by package checks.

In my particular case I get on "SLE_11_SP2": .... I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. E: dateutils sequence-point yuck-scmver.c:485 ....

I've tried already rpmlintrc, for example addFilter(".*") addFilter("undefined operation") addFilter(".*operation on.*may be undefined.*") setBadness('sequence-point', 0)

Is this an rpmlint issue at all?

Or doesn't work rpmlintrc on SLE_11? I remember I had already issues in the past with "addFilter" which worked for all distros but not for SLE.

cu, Rudi

...

rpm -qf /usr/lib/build/checks-data/check_gcc_output

Hello. It is a post build check: https://en.opensuse.org/openSUSE:Packaging_checks#post-build-checks_and_brp-... post-build-checks-1.0-119.1.2.noarch -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

3711

Age (days ago)

3712

Last active (days ago)

List overview

Download

23 comments

10 participants

participants (10)

Andreas Schwab
Andrey Borzenkov
Bernhard Voelker
Cristian Morales Vega
Cristian Rodríguez
Dmitriy Perlow
Jean Delvare
Marcus Meissner
Michael Matz
Ruediger Meier