Bug 204177

packaging looks ok.
+ Mockbuild is successfull for i386 FC6
- rpmlint on binary rpm is NOT silent
W: digikam-doc summary-not-capitalized digiKam and Showfoto documentation
Summary doesn't begin with a capital letter.

=>Make Summary start with capital letter

E: digikam-doc no-binary
The package should be of the noarch architecture because it doesn't contain
any binaries.

=>make package noarch type 

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/pt/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/nl/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/et/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/de/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/da/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/de/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/da/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/pl/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink
/usr/share/doc/HTML/pt_BR/digikam/common ../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/es/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/sv/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/en/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/nl/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/es/digikam/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/pl/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/pt/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/fr/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/et/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/it/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/en/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/sv/showfoto/common
../common
The relative symbolic link points nowhere.

W: digikam-doc dangling-relative-symlink /usr/share/doc/HTML/it/digikam/common
../common
The relative symbolic link points nowhere
=> check link path where you want to link in SPEC file

+ dist tag is present
+ Buildroot is correct
+ source URL is correct
+ BR is correct
+ License used is GPL
+ License file COPYING is included
+ Desktop file is handled correctly
+ MD5 sum on tarball is matching upstream tarball
5fea0b1d1aff7ce98954bbc3951d5fa9  digikam-doc-0.8.2-r1.tar.bz2
+ No duplicate files

why files from this package is not merged with digikam package?

I can review this.

(In reply to comment #1)
> =>Make Summary start with capital letter

digiKam is the proper name of the project, with capital letter it's invalid.

> =>make package noarch type 

Adding 'BuildArch: noarch' cause this error:
checking build system type... x86_64-redhat-linux-gnu
checking host system type... x86_64-redhat-linux-gnu
checking target system type... Invalid configuration `noarch-redhat-linux-gnu':
machine `noarch-redhat' not recognized
configure: error: /bin/sh admin/config.sub noarch-redhat-linux-gnu failed

> => check link path where you want to link in SPEC file

Links point to ../common directory which is provided by i.e by kdelibs (required
by digikam package, digikam package is needed by digikam-doc)

> + License used is GPL

License is GFDL

> why files from this package is not merged with digikam package?

This is how it's made in upstream, why? Probably because it's 40MB of docs
against 4.2M of apps, so rebuilding digikam package (with docs included) cause
almost 36MB bandwidth wasting.

(In reply to comment #3)
> (In reply to comment #1)
> > =>Make Summary start with capital letter
> 
> digiKam is the proper name of the project, with capital letter it's invalid.

Perhaps a compromise would be to change the summary to:

Documentation for digiKam and Showfoto

> > =>make package noarch type 
> 
> Adding 'BuildArch: noarch' cause this error:
> checking build system type... x86_64-redhat-linux-gnu
> checking host system type... x86_64-redhat-linux-gnu
> checking target system type... Invalid configuration `noarch-redhat-linux-gnu':
> machine `noarch-redhat' not recognized
> configure: error: /bin/sh admin/config.sub noarch-redhat-linux-gnu failed

This is probably due to someone copy-and-pasting configure.ac bits between
projects. What happens if you have a noarch package and you use:

%configure --target=sparc64

Does that fix the problem?

(In reply to comment #4)
> Perhaps a compromise would be to change the summary to:
> 
> Documentation for digiKam and Showfoto

Oh, you are right :) thanks.

> > checking target system type... Invalid configuration `noarch-redhat-linux-gnu':
> > machine `noarch-redhat' not recognized
> > configure: error: /bin/sh admin/config.sub noarch-redhat-linux-gnu failed
> 
> This is probably due to someone copy-and-pasting configure.ac bits between
> projects. What happens if you have a noarch package and you use:
> 
> %configure --target=sparc64
> 
> Does that fix the problem?

"checking target system type... sparc64-unknown-none" and building goes fine,
above error is caused by %configure macro which set
"--target=noarch-redhat-linux-gnu".

(In reply to comment #5)
> > > checking target system type... Invalid configuration
`noarch-redhat-linux-gnu':
> > > machine `noarch-redhat' not recognized
> > > configure: error: /bin/sh admin/config.sub noarch-redhat-linux-gnu failed
> > 
> > This is probably due to someone copy-and-pasting configure.ac bits between
> > projects. What happens if you have a noarch package and you use:
> > 
> > %configure --target=sparc64
> > 
> > Does that fix the problem?
> 
> "checking target system type... sparc64-unknown-none" and building goes fine,
> above error is caused by %configure macro which set
> "--target=noarch-redhat-linux-gnu".

This isn't normally a problem unless there is for some reason AC_CANONICAL_* in
the configure.ac, so that the configure script can make platform-specific
decisions. Is that the case here, and if so, what is platform-dependent? I'd
have thought nothing was platform dependent for a documentation package.

There isn't anything platform-dependent in documentation package, I've just
tried to fix this in clean way, becuse IMHO "--target=" is more like a
workaround. Anyway thanks for help, I've added "--target=x86" :)

Spec URL: http://dakar.lunixsys.com/~mgarski/digikam-doc.spec
SRPM URL: http://dakar.lunixsys.com/~mgarski/digikam-doc-0.8.2-2.src.rpm

- Changed summary field
- Build as noarch

(In reply to comment #7)
> There isn't anything platform-dependent in documentation package, I've just
> tried to fix this in clean way, becuse IMHO "--target=" is more like a
> workaround. Anyway thanks for help, I've added "--target=x86" :)

This is still a workaround; "--target=x86" certainly isn't true for a ppc build
for instance. The proper fix would be to patch out the configure check for the
platform. I'm not saying that you need to do that though, since the workaround
gets the package building as noarch successfully.

1.  MUST: --target=x86 will break on the buildsystem, as will may try to build
.noarch on a ppc builder.  (I'll attach a patch soon for that)

2.  marking files under %_docdir as %doc is redundant (everything under %_docdir
is already implicitly %doc).

Created attachment 135326 [details]
fix for noarch build

Created attachment 135327 [details]
specfile patch for items in comment #9

Alternatively, or could avoid the need for patch + automake by changing
--target=x86
to
--target=%{_build_cpu}

Not sure which, patching, or using --target is better (less hackish)

If it wasn't clear from comment #12, I'll leave it up to you to decide which
approach you'd rather take in maintaining this (as a noarch build).

Spec URL: http://dakar.lunixsys.com/~mgarski/digikam-doc.spec
SRPM URL: http://dakar.lunixsys.com/~mgarski/digikam-doc-0.8.2-3.src.rpm

- Remove redundant %doc
- Fix noarch building

I have used --target=%{_build_cpu}, and will report this issue upstream.

Looks good, thanks, APPROVED. 

BTW, you interested in doing digikamimageplugins-doc too?  (:

Thanks for approving. I will import package when CVS will be up (recently it had
many downtimes).

I will consider making digikamimageplugins-doc, but IMHO you as a
digikamimageplugins maintainer could keep base and doc package in better sync :)

OK, ok, I'll go whip something up.

And, many thanks Paul for the hint on the auto* magic to make the .noarch build
work.

FYI, digikamimageplugins-doc bug #204955

Marcin or Paul, maybe one of you would be interested in reviewing? :)

I'm not official reviewer and I didn't review any package, so I'll have to dig
through documentation and see how things are working, then I could review your
package :)

Package Change Request
======================
Package Name: digikam-doc
New Branches: EL-5

cvs done.