Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 225300 - Merge Review: automake16
Summary: Merge Review: automake16
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Patrice Dumas
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-01-29 21:08 UTC by Nobody's working on this, feel free to take it
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: automake16-1.6.3-14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-04 13:06:33 UTC
pertusus: fedora-review+


Attachments (Terms of Use)
complete Makefile.in patching when using automake16.texi (deleted)
2007-03-18 22:44 UTC, Patrice Dumas
no flags Details | Diff
finish Makefile.in patching (deleted)
2007-08-27 18:32 UTC, Patrice Dumas
no flags Details | Diff

Description Nobody's working on this, feel free to take it 2007-01-29 21:08:49 UTC
Fedora Merge Review: automake16

http://cvs.fedora.redhat.com/viewcvs/devel/automake16/

Comment 1 Karsten Hopp 2007-02-20 14:25:45 UTC
please check automake16-1.6.3-9 or later as it has fixes for the most common
review issues.

Comment 2 Patrice Dumas 2007-03-18 22:42:00 UTC
The install-info scriptlet is certainly wrong, it should certainly
be automake16.info. Moreover, I suggest dropping the .gz in these 
scriptlets.

There should be a comment explaining why there is a plain ./configure
and not %configure.

make check should be in %check

I am not completely sure that that package should explicitly Conflict 
with automake 1.6.3: there could be no real conflict. 

Comment 3 Patrice Dumas 2007-03-18 22:44:05 UTC
Created attachment 150342 [details]
complete Makefile.in patching when using automake16.texi

Comment 4 Karsten Hopp 2007-03-22 14:18:22 UTC
- install-info has been fixed by Florian LaRoche.
- comment about ./configure added
- make check moved to %check

I don't think your makefile changes are required as we don't ship dvi stuff
afaik. Applied anyway.

Comment 5 Patrice Dumas 2007-03-25 02:09:20 UTC
I don't think the
Obsoletes:  automake = 1.6.3
is right either. In my opinion there shouldn't be anything 
related with automake = 1.6.3.

Comment 6 Karsten Hopp 2007-04-16 12:38:57 UTC
the Obsolete: is required as we shipped automake-1.6.3 in older releases and 
automake16 needs to replace that.

Comment 7 Patrice Dumas 2007-04-22 21:31:23 UTC
Is it really true? It means that people having automake on a
previous release won't have the latest automake. I am not
sure that it is what we want. If it was possible to say to
rpm to install automake16 and update to current automake 
version it would be even better, but that is not the case.
In any case using a precise version is not right. What about
if a use has 1.6.2 installed? He will get the latest, while
with 1.6.3 it goes to automake16. Isn't that wrong?

Comment 8 Patrice Dumas 2007-08-27 18:32:26 UTC
Created attachment 174101 [details]
finish Makefile.in patching

For an unknown reason, part of my patch above wasn't 
applied.

Comment 9 Karsten Hopp 2007-08-28 10:11:39 UTC
We don't ship any dvi files and it doesn't really matter. But I've added this
for completeness in -13.
Please close this bugzilla if everything else looks ok.

Comment 10 Patrice Dumas 2007-08-28 11:31:40 UTC
Almost. There is still the automake = 1.6.3 obsoletion that
annoys me. I sent a mail on -devel, we'll see what people respond.
And if nobody responds for some day I'll repost on -packaging.

Comment 11 Patrice Dumas 2007-09-14 20:10:07 UTC
The Obsolete is right, as explained by Michael Schwendt, it
allows to rename the package while still updating to the latest
version.

Still 2 issues remaining:
Is the 
Buildrequires:  autoconf >= 2.52
needed? I don't think so. 

Otherwise could you please precise what is covered by MIT
in a comment for example? 
In my opinion the documentation is under OFSFDL, this should
be added, with a comment.

Comment 12 Karsten Hopp 2007-09-17 13:57:46 UTC
autoconf is definitely required tor the self tests. You'll get >50 failures
otherwise. 
I'd prefer not to start listing which files are under which license. When
someone has concerns about the used licenses he/she would have to check every
file anyhow.

Can you point me to a wiki page backing up your request for that ?

You're right about OFSFDL, I've added that to the license list

Comment 13 Patrice Dumas 2007-09-17 20:53:10 UTC
(In reply to comment #12)
> autoconf is definitely required tor the self tests. You'll get >50 failures
> otherwise. 

Right.

> I'd prefer not to start listing which files are under which license. When
> someone has concerns about the used licenses he/she would have to check every
> file anyhow.

Indeed. My issue is that I don't see any file under the MIT license.
All that I see are in GPL.

Comment 14 Patrice Dumas 2007-09-21 18:39:23 UTC
I guess that it is install-sh which is MIT. A comment in 
the spec file would be good.

APPROVED.

Comment 15 Patrice Dumas 2007-10-04 08:16:01 UTC
You can close this bug.

Comment 16 Karsten Hopp 2007-10-04 13:06:33 UTC
thanks, closing...


Note You need to log in before you can comment on or make changes to this bug.