Bug 617014 – media-gfx/sam2p-0.49.3 stabilization

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Kent Fredric (IRC: kent\n) (RETIRED) 2017-04-29 16:56:34 UTC]

Created attachment 471292 [details]
build.log

See tracker bug for details.

perl -pe0 bts.ttt l1g8z.pst l1ghz.pst l1gbz.pst l1g8l.pst l1ghl.pst l1gbl.pst >bts1.ttt
./ps_tiny --copy <bts1.ttt >bts2.ttt
perl -x hq.pl <bts2.ttt >bts2.tth
do "hq.pl" failed, '.' is no longer in @INC; did you mean do "./hq.pl"? at hq.pl line 2.
x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG2_H -march=native -mtune=native -O2 -pipe -fsigned-char -fno-rtti -fno-exceptions -ansi -pedantic -Wall -W -c sam2p_main.cpp
sam2p_main.cpp:152:1: error: expected primary-expression before ‘;’ token
 ;
 ^
make: *** [Makedep:157: sam2p_main.o] Error 1
make: *** Waiting for unfinished jobs....
 * ERROR: media-gfx/sam2p-0.49.1::gentoo failed (compile phase):
 *   emake failed


PS: Good luck with hq.pl, this is the sort of terror I avoid.

I might get brave and circle around it when I have time, but the offending line is probably:

  ($0=~/(.*)/s);do$1;die$@if$@;__END__+if 0;

[Comment 1 Alexis Ballier 2017-05-15 15:24:12 UTC]

Thanks, I was going to ask what all this means for mere mortals like me, but I noticed you reported this upstream and it got fixed meanwhile. Fix imported, thanks!


commit ffb4b769ec24ec1e0801375dadacffd557b6ce75 (HEAD -> master, origin/master, origin/HEAD)
Author: Alexis Ballier <[e-mail]>
Date:   Mon May 15 17:23:05 2017 +0200

    media-gfx/sam2p: Import upstream fix to build with perl 5.26, bug #617014

[Comment 2 Kent Fredric (IRC: kent\n) (RETIRED) 2017-05-15 15:41:29 UTC]

If you can keep this open until affected versions are removed from tree, that'd be nice. Because end users being able to install a stable sam2p that is affected on a stable 5.26 would be a fatal combination.

Hence, 5.26's eventual stabilization should be blocked on the affected versions being removed ( or at very least, a stable version being available without affect )

Unless of course, you are entirely ok with sam2p stable being broken come 5.26 stabilization.

(I've left the bug resolved though, you're the maintainer, its up to you :))

[Comment 3 Alexis Ballier 2017-05-15 15:48:07 UTC]

(In reply to Kent Fredric (IRC: kent\n) from comment #2)
> If you can keep this open until affected versions are removed from tree,
> that'd be nice. Because end users being able to install a stable sam2p that
> is affected on a stable 5.26 would be a fatal combination.
> 
> Hence, 5.26's eventual stabilization should be blocked on the affected
> versions being removed ( or at very least, a stable version being available
> without affect )
> 
> Unless of course, you are entirely ok with sam2p stable being broken come
> 5.26 stabilization.
> 
> (I've left the bug resolved though, you're the maintainer, its up to you :))

Well, I usually don't track bugs like that; if you want to convert this bug to a stablereq, feel free, but it sounds more like a candidate for a new bug blocking a perl 5.26 stable bug; I don't see any usefulness in a bug with nothing actionable.

[Comment 4 Kent Fredric (IRC: kent\n) (RETIRED) 2017-05-15 18:05:42 UTC]

(In reply to Alexis Ballier from comment #3)
> Well, I usually don't track bugs like that; if you want to convert this bug
> to a stablereq, feel free, but it sounds more like a candidate for a new bug
> blocking a perl 5.26 stable bug; I don't see any usefulness in a bug with
> nothing actionable.

Just you typically have to wait a month before stable reqs :)

And besides, how would you respond if you had 2 stable versions in tree, and somebody reported a bug that the older was now broken to the point of not being usable.

That's actionable right?

That'd be a "ok, we'll clean this up so its not a problem any more". Just its too soon to do that right now :)

[Comment 5 Alexis Ballier 2017-05-16 09:04:20 UTC]

(In reply to Kent Fredric (IRC: kent\n) from comment #4)
> (In reply to Alexis Ballier from comment #3)
> > Well, I usually don't track bugs like that; if you want to convert this bug
> > to a stablereq, feel free, but it sounds more like a candidate for a new bug
> > blocking a perl 5.26 stable bug; I don't see any usefulness in a bug with
> > nothing actionable.
> 
> Just you typically have to wait a month before stable reqs :)

Yes. I don't mind having a stablereq sitting for time to pass. I do mind having a build failure bug open that is fixed and just waiting for its corresponding stablereq. That's why I told you that if you want this open, convert this to stablereq and we'll all be happy.

> And besides, how would you respond if you had 2 stable versions in tree, and
> somebody reported a bug that the older was now broken to the point of not
> being usable.
> 
> That's actionable right?
> 
> That'd be a "ok, we'll clean this up so its not a problem any more". Just
> its too soon to do that right now :)

If it's broken, it's not too soon: When something is messed up we always have the possibility to fast track to stable. If it's not broken then it's not a bug :)

[Comment 6 Agostino Sarubbo 2017-06-20 05:07:27 UTC]

amd64 stable

[Comment 7 Agostino Sarubbo 2017-06-20 07:02:18 UTC]

x86 stable

[Comment 8 Agostino Sarubbo 2017-06-21 11:59:04 UTC]

ppc stable

[Comment 9 Agostino Sarubbo 2017-06-21 12:18:16 UTC]

ppc64 stable

[Comment 10 Markus Meier 2017-06-25 07:23:23 UTC]

arm stable

[Comment 11 Tobias Klausmann (RETIRED) 2017-06-26 20:20:11 UTC]

Stable on alpha.

[Comment 12 Sergei Trofimovich (RETIRED) 2017-06-30 07:26:48 UTC]

ia64 stable

[Comment 13 Agostino Sarubbo 2017-07-07 09:08:31 UTC]

sparc stable

[Comment 14 Andreas K. Hüttel 2017-10-31 03:08:14 UTC]

ping

[Comment 15 Andreas K. Hüttel 2017-11-08 20:20:36 UTC]

ping

[Comment 16 Andreas K. Hüttel 2017-11-17 23:28:54 UTC]

ping

[Comment 17 Sergei Trofimovich (RETIRED) 2017-12-03 18:46:43 UTC]

hppa stable

Last arch. Closing.