[Bug 167253] Review Request: CERN library and associated binaries

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: CERN library and associated binaries


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167253





------- Additional Comments From pertusus at free.fr  2005-11-15 06:53 EST -------
(In reply to comment #21)
> Needs work: 
> * Missing SMP flags. If it doesn't build with it, please add a comment 
>   (wiki: PackagingGuidelines#parallelmake) 

It breaks the libraries build, I added them when possible and added a comment too. 

I'll post a new srpm which contains other minor fixes (add a profile.d csh
script and provide saner defaults in the cernlib script) soon.

> * Spec file: some paths are not replaced with RPM macros 
>   (wiki: QAChecklist item 7) 

Which ones? I can't find them?

> * Build failed in mock 
>  
> It is easy to spot the problem, since you created the src.rpm blas and 
> lapack have changed and no longer have the devel part 
>  
> The fix is simply to replace them in BuildRequires with their devel 
> counterpart. 

Thanks. It is fixed, and I'll retry a mock build soon.

> I have noticed that in the build log I see lots of cases like this: 
>  
> Makefile:454: archive/hadjust.d: No such file or directory 

Yep, I don't know what it means and it seems harmless.

> Argument #4 of `hptit' is one type at (2) but is some other type at (1) [info 
> -f g77 M GLOBALS] 

I don't know for this one.
  
> Argument #2 of `ucopy' is one precision at (2) but is some other precision at 
> (1) [info -f g77 M GLOBALS] 

This is not an issue, as ucopy accept as argument the storage length. So it may
accomodate different precisions as long as the different precisions have a fixed
relative storage size, and this is the case in f77 (a double is 2 times real
storage). So the compiler should do the right thing, even though it is not very
clean. I didn't had a look to the precise code, though.

> Those are warnings and they don't block the package building but some of them 
> look scary. :-) 

Yep, but as long as the build proceed and leads to the right executable, even
though not very optimized I think it's enough, given that the upstream isn't
willing to change much.

I forgot to mention that the RPM optflags are not used during the build. I have
added a comment in the spec file.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.