This is next release of gimp-print. As its not yet in FC6 core and extras and i
found it useful with its support to number ofprinter drivers, i decided to see
it in extras. 

This package has still some packaging problem for SOURCE as upstream has
released with tag rc3, gutenprint-5.0.0-rc3 and i am not able to solve the
problem as version string not accpets a hypen(-) so i can't make it as
version: 5.0.0-rc3
so what i did is, i download source from upstream and rebuild tar.bz2 file with
parent source tree directory name renamed to gutenprint-5.0.0 from
gutenprint-5.0.0-rc3.

Mock Build for rawhide i386 is successfull.
rpmlint -v gutenprint-5.0.0-rc3.1.fc6.i386.rpm
I: gutenprint checking
W: gutenprint non-conffile-in-etc /etc/cups/command.types
E: gutenprint postun-without-ldconfig /usr/lib/libgutenprint.so.2.0.0
E: gutenprint postun-without-ldconfig /usr/lib/libgutenprintui2.so.1.0.0
E: gutenprint postun-without-ldconfig /usr/lib/libgutenprintui.so.1.0.0
E: gutenprint non-empty-%postun /sbin/ldconfig

  how can i solve these errors?

I think the way pre-releases are normally done is like '5.0.0-0.rc3.1'.

Thanks for your comment.
But can you please give me solution of how to handle version string problem,
otherwise i have to keep my own Source tarball link that have tarball created
from gutenprint-5.0.0 directory and not from upstream gutenprint-5.0.0-rc3.

Your comment also still saying that i have to use 
version: 5.0.0
Release: 0.rc3.1%{?dist}
whereas i have used
Version: 5.0.0
Release: rc3.1%{?dist}

As per your suggestion, i updated package as
SPEC URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.rc3.1.fc5.src.rpm

I think it should be '5.0.0-0.1.rc3'. The Naming Guidelines say
"0.%{X}.%{alphatag}" is the release tag for pre-release packages.

As per your suggestion, i updated package as
SPEC URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.1.rc3.fc5.src.rpm

also there is no need for you to make your own tarball you can use the -n 
switch to use the upstream tarball

as for the rmplint errors  i think the %find_lang  should be in the %install 
section

and you need to mark the config file as a config file

Created attachment 132558 [details]
spec file addressing rpmlint, directory ownership, and other issues

The README in the gutenprint package contains some tips on how to package it.
Unless there is a good reason not to do so, I would follow that advice.

You probably don't want to package escputil or its manual page because they
would cause file conflicts with gimp-print-utils.

The package as it stands has a dependency on perl(perlmenu); there is no
package in FC5 or FE5 that satisfies this dependency.

I have built this on FC6/rawhide i386, and will give it a bit of a review in a
while, before installing it, is it possible to give a measure of how "safe" is
this to install on a box without nuking printing? Does gimp-print need to be
removed first, or are there obsoletes to handle that? How do CUPS, gimp, and the
new system-config-printer react to the changeover?

I'm mainly interested to see if the printable CD media works on my Epson R300
which gutenprint's drivers claim to support ...

Thanks for all your comments. 
Paul,
 Thanks for correcting SPEC file. Will upload new SRPM,SPEC.
But i have some questions. As gutenprint claims that its replacement to
gimp-print and gimp-print-utils is a part of gimp-print then why not to make
package to remove gimp-print,gimp-print-utils,gimp-print-plugins (add obsoletes
to them)and install this new gutenprint package?
I have those perl(Perlmenu) and perl-Curses RPMS from rpm.pbone.net. Should i
add them also in Fedora Extras by repackaging them according to Fedora Extras
guidlelines?

(In reply to comment #10)
> Thanks for all your comments. 
> Paul,
>  Thanks for correcting SPEC file. Will upload new SRPM,SPEC.
> But i have some questions. As gutenprint claims that its replacement to
> gimp-print and gimp-print-utils is a part of gimp-print then why not to make
> package to remove gimp-print,gimp-print-utils,gimp-print-plugins (add obsoletes
> to them)and install this new gutenprint package?

Packages in Extras aren't supposed to obsolete packages in Core. I'm pretty sure
about this but can't actually find where it's documented. It may be worth
bringing up on fedora-extras-list.

I believe that gutenprint will eventually make it into Core. At that point,
gimp-print will go and it'll be safe to include the files that conflict with it.

> I have those perl(Perlmenu) and perl-Curses RPMS from rpm.pbone.net. Should i
> add them also in Fedora Extras by repackaging them according to Fedora Extras
> guidlelines?

perl-Curses is already in Extras.

A module providing perl(perlmenu) [not perl(Perlmenu)] would need to be provided
as a submission for Extras before gutenprint could be properly reviewed. It's
possible that that module may itself have additional dependencies.

Do you know which program in the gutenprint package is responsible for these
dependencies? Another possible option might be to not package that particular
program if it's not important.

Paul,
  Will check perl thing in gutenprint package.I have already created package
with Obsoletes and updates files are as
SPEC file: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM file:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.2.rc3.fc5.src.rpm

If its not allowed to obsolete core packages then i can revert back changes in
SPEC. Also why not to package 
%{_libdir}/gimp/*/plug-ins/print
under gutenprint?


Why mock build did not give any dependency error for both perl packages but
while installing final binary rpm it asked for perl-PerlMenu as well as
perl-Curses ?

But i solved dependency problem using perl-PerlMenu package and you have asked
me to add perl(perlmenu) module package?
What is correct package then?

(In reply to comment #12)
>   Will check perl thing in gutenprint package.I have already created package
> with Obsoletes and updates files are as
> SPEC file: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
> SRPM file:
> http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.2.rc3.fc5.src.rpm

You're still not using the package split suggested in the upstream README file.
Why not?

> If its not allowed to obsolete core packages then i can revert back changes in
> SPEC. Also why not to package 
> %{_libdir}/gimp/*/plug-ins/print
> under gutenprint?

I didn't include this file because you didn't include it in your original
package. The reason you didn't include it is probably because you missed the
buildreq of gimp-devel, so it didn't get built. I think it actually belongs in a
separate subpackage. See the README file again.

> Why mock build did not give any dependency error for both perl packages but
> while installing final binary rpm it asked for perl-PerlMenu as well as
> perl-Curses ?

mock will help you to find build-time dependencies (BuildRequires). It doesn't
help with runtime dependencies (Requires). The perl modules are only needed at
runtime, not build-time.

Did you find out where these dependencies are coming from?

(In reply to comment #13)
> But i solved dependency problem using perl-PerlMenu package and you have asked
> me to add perl(perlmenu) module package?
> What is correct package then?

I believe it's using this:
http://search.cpan.org/dist/perlmenu/

The upstream name for this is all lower case.

ok. I need some time to create gutenprint-extras, gutenprint-cups,
gutenprint-foomatic packages as per given in README file of source tarball.
will upload new SRPM once i finish its package building.

(In reply to comment #15)
> ok. I need some time to create gutenprint-extras, gutenprint-cups,
> gutenprint-foomatic packages as per given in README file of source tarball.
> will upload new SRPM once i finish its package building.

Good.

I forgot to ask: did you understand why I made each of the changes to the spec
file in Comment #8? If there's anything you're unsure about, please ask.

yes. I first understood all changes you made and then start working on SPEC.
What i understood well is %files section, language handling, package naming with
setup call must be with -n and package name like 
%setup -q -n %{name}-%{version}%{?beta:-%{beta}}
and %configure call with  --disable-static --disable-dependency-tracking
But i dont understand --disable-dependency-tracking option to %configure

Now i making changes to %configure call to add more options as per README
suggests to
%configure --disable-static --disable-dependency-tracking \
           --with-foomatic --with-ghostscript \
           --with-user-guide --with-samples \
           --with-escputil

(In reply to comment #17)
> i dont understand --disable-dependency-tracking option to %configure

Here's a good explanation:
http://www.redhat.com/archives/fedora-extras-list/2005-July/msg00156.html

I added subpackages and now updated
SPEC file:  http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM file: 
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.3.rc3.fc5.src.rpm

Why did you add explicit dependencies on perl-Curses and perl-perlmenu?

I noted earlier that the binary packages already have the correct perl
dependencies, i.e. perl(Curses) and perl(perlmenu), auto-generated by RPM.

There is no need to add any further dependencies, and in fact perl package name
dependencies such as perl-Curses and perl-perlmenu should be avoided altogether,
as per the discussion on perl(XML::Parser) in a different bugzilla ticket.

Updated version
SPEC file:  http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM file: 
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.4.rc3.fc5.src.rpm

ChangeLog for this new version
* Wed Jul 19 2006 Parag Nemade <panemade>- 5.0.0-0.4.rc3
- Removed Requires on perl-Curses and perl-perlmenu 
  as both are automatically added on binary RPM
- Commented Obsoletes and provides tag as Fedora Extras package can not
  Obsoletes Fedora Core Package.

rpmlint on gutenprint-extras, gutenprint-cups, gutenprint-foomatic gives
W: gutenprint-extras no-documentation

5.0 is out now -- we should really try to get this into Core IMHO

Updated to New Release
SPEC file:  http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM file: 
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.5.fc5.src.rpm

I need review of this updated package.

FWIW, I was able to use this gutenprint.spec to successfully print to an HP
Photosmart 7760 by using the 7550 driver. My build was against FC5. It's the
first time I was able to print to it's Photo tray correctly. This is a needed
improvement for gimp printing--a very nice "must have" for fc6. Total build was
over 80 megs versus 25 megs for gimp-print 4.2.7.

#196989 is a duplicate.

Thanks for testing the package. I was not knowing that gutenprint was already
requested here. Updating to #196989 bug about this package link.

/usr/share/gutenprint/doc should be /usr/share/doc/gutenprint, I believe.

=========
from %configure using your spec:
Build genppd statically:                no
***WARNING: Use of --disable-static-genppd or --disable-static
when building CUPS is very dangerous.  The build may
fail when building the PPD files, or may *SILENTLY*
build incorrect PPD files or cause other problems.
Please review the README and release notes carefully!

./configure --help
  --enable-static-genppd  build a statically-linked cups-genppd and
                          rastertogutenprint. WARNING: Please read the README
                          and NEWS (release notes) CAREFULLY before disabling
                          this! [(automatic)]

From NEWS, section about static:
  7) Due to the implementation of CUPS, it is necessary on some
     systems to link the programs associated with the CUPS driver (in
     particular, cups-genppd and rastertogutenprint) statically
     against the Gutenprint library.  Please see bugs 865253 and
     865265 for full details.

     This fix works correctly unless --disable-static (to disable
     building static libraries) is passed on the command line.
     Normally, only people packaging up Gutenprint for distribution
     use this option.  If you wish to use this option, please read
     item (6) in Exceptions and Workarounds *carefully* for a full
     description of the problem along with suggested methods of
     procedure.

As far as I can tell, "Exceptions and Workarounds" ends at item 5. ;)   In
another place, which I think may be a fix for the above, is to build it, install
it, and rebuild it, which mock may not be accoustomed to. I'm not sure where the
built .a files should be if it's compiled without --disable-static (typically in
-devel).

=========
From the README:
NOTES TO PACKAGERS: 

* We recommend that your installation package run
cups-genppdupdate.5.0 and restart CUPS as part of the
installation process.

CUPS is being restarted, cups-genppdupdate.5.0 isn't being run in %post

=========
You may want to break out the languages into other sub-packages.
/usr/share/cups/model/gutenprint/5.0 is 124 megs, but is just 7.3 megs times 17
languages. The main gutenprint package size could be greatly reduced.

(In reply to comment #26)
> /usr/share/gutenprint/doc should be /usr/share/doc/gutenprint, I believe.
> 
    I followed the way Makefile is installing those doc files here. Should i
move /usr/share/gutenprint/doc to /usr/share/doc/gutenprint ?

> =========
> from %configure using your spec:
> Build genppd statically:                no
> ***WARNING: Use of --disable-static-genppd or --disable-static
> when building CUPS is very dangerous.  The build may
> fail when building the PPD files, or may *SILENTLY*
> build incorrect PPD files or cause other problems.
> Please review the README and release notes carefully!
> 
> ./configure --help
>   --enable-static-genppd  build a statically-linked cups-genppd and
>                           rastertogutenprint. WARNING: Please read the README
>                           and NEWS (release notes) CAREFULLY before disabling
>                           this! [(automatic)]
> 
> From NEWS, section about static:
>   7) Due to the implementation of CUPS, it is necessary on some
>      systems to link the programs associated with the CUPS driver (in
>      particular, cups-genppd and rastertogutenprint) statically
>      against the Gutenprint library.  Please see bugs 865253 and
>      865265 for full details.
> 
>      This fix works correctly unless --disable-static (to disable
>      building static libraries) is passed on the command line.
>      Normally, only people packaging up Gutenprint for distribution
>      use this option.  If you wish to use this option, please read
>      item (6) in Exceptions and Workarounds *carefully* for a full
>      description of the problem along with suggested methods of
>      procedure.
> 
> As far as I can tell, "Exceptions and Workarounds" ends at item 5. ;)   In
> another place, which I think may be a fix for the above, is to build it, install
> it, and rebuild it, which mock may not be accoustomed to. I'm not sure where the
> built .a files should be if it's compiled without --disable-static (typically in
> -devel).

     Will check that

> 
> =========
> From the README:
> NOTES TO PACKAGERS: 
> 
> * We recommend that your installation package run
> cups-genppdupdate.5.0 and restart CUPS as part of the
> installation process.
> 
> CUPS is being restarted, cups-genppdupdate.5.0 isn't being run in %post
 
 I modififed SPEC file to run cups-genppdupdate.5.0 in %post

>  =========
> You may want to break out the languages into other sub-packages.
> /usr/share/cups/model/gutenprint/5.0 is 124 megs, but is just 7.3 megs times 17
> languages. The main gutenprint package size could be greatly reduced.

   Will do that and then post updated package link. But how can i handle this? I
mean how can i make separate packages for all languages?

> Will do that and then post updated package link. But how can i handle this? I
> mean how can i make separate packages for all languages?

I'm just getting familiar with the package, but it appears that those ppd's and
a few other bits may(?) be moved to gutenprint-cups (to "%files cups" section
instead of "%files"):
%{_sbindir}/cups-genppd*
%{_mandir}/man8/cups-calibrate.8*,
%{_mandir}/man8/cups-genppd*.8*
%{_datadir}/cups/model/gutenprint/

I don't know the best way to make the package for multiple languages. Perhaps
see the openoffice.org spec. Or you could just do an -i18n- package.

========
BTW, gimp 2.4 looks like it will be swtiching to gtk's printing module and not
using gutenprint. Gimp 2.4 won't be out for fc6 (i'm guessing).

Regarding movong docs from /usr/share/gutenprint/doc to
/usr/share/doc/gutenprint, I'd only attempt that if there's a configure option
for doing ot; otherwise you may find that any built-in documentation references
in the software may point to the wrong place.

Regarding --disable-static: this needs to be looked at carefully; building,
installing, and rebuilding is a non-starter as far as packaging is concerned.

Regarding splitting off separate packages for each language: take at look at how
it's done in gcompris:
http://cvs.fedora.redhat.com/viewcvs/devel/gcompris/gcompris.spec?root=extras&view=markup

Thanks Paul for your comments.

I will prefer not to move docs from /usr/share/gutenprint/doc to
/usr/share/doc/gutenprint.

I will check gcompris SPEC and do same for this package.

For --disable-static i will really need suggestions whether i should remove it
from passing a option to  %configure or keep it there.

(In reply to comment #30)
> I will prefer not to move docs from /usr/share/gutenprint/doc to
> /usr/share/doc/gutenprint.

Hmmm, we don't seem to have anything in the guidelines for this AFAICS. But IMHO
all docs should be marked as %doc and thus should land in
/usr/share/doc/<packagename-version-release> (the proper place used by all other
packages)

Maybe we need to add such a rule :-/

The question is: are these files docs or are they data? I don't know in this
specific instance because I don't know the package, but many apps with GUI front
ends have built-in ways to access their docs, which are expected to be in the
place they're configured with. Marking them as %doc and/or moving them elsewhere
could cause this built-in means of accessing the docs to fail, which would
violate the rule:

  MUST: If a package includes something as %doc, it must not affect the runtime
  of the application. To summarize: If it is in %doc, the program must run
  properly if it is not present.

(In reply to comment #31)
> (In reply to comment #30)
> > I will prefer not to move docs from /usr/share/gutenprint/doc to
> > /usr/share/doc/gutenprint.
> 
> Hmmm, we don't seem to have anything in the guidelines for this AFAICS. But IMHO
> all docs should be marked as %doc and thus should land in
> /usr/share/doc/<packagename-version-release> (the proper place used by all other
> packages)
> 
> Maybe we need to add such a rule :-/

Sure if you think like that. Primary looking at package said me that let that
doc files be in /usr/share/gutenprint/doc
Then i check under /usr/share on my system using
find . -name doc * and i got following output
./sane/xsane/doc
./cups/doc
./apps/quanta/doc
./sgml/docbook/xsl-stylesheets-1.69.1-5/htmlhelp/doc
./scrollkeeper/doc
./vim/vim70/doc
./eclipse/plugins/org.python.pydev_0.9.3/PySrc/ThirdParty/logilab/common/doc
./eclipse/plugins/org.python.pydev_0.9.3/PySrc/ThirdParty/logilab/pylint/doc
./pear/doc
./gutenprint/doc
where some of the entries belongs to Fedora Core packages.

So it looks to me that either we have different strategy for Fedora Extras or we
have some Guidelines that will require a major changes when a package moves from
Fedora Extras to Fedora Core. Then i would like to see that Guidelines page.

The files in /usr/share/gutenprint/doc appear to me to be %doc and won't affect
runtime.

The reference-html subdir should be in gutenprint-devel, as it's titled "The
Developer's Guide to Gutenprint". Same with gutenprint.pdf.

Using gutenprint in gimp 2.2.12 has an "About" button, but no "Help" button
(with the docs in /usr/share/gutenprint/doc). gutenprint-users-manual.odt
(OpenDocument Text) and gutenprint-users-manual.pdf should be in the main
package's %doc, AFAICT.

Parag, I'm not certain about --disable-static, but this package sure seems to
warn against it.

ok I have updated package
Spec URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.7.fc5.src.rpm

I need review for this package. I have not donr any work on --disable-static
issue as i need suggestions on that issue.


* Wed Aug 09 2006 Parag Nemade <panemade>- 5.0.0-0.7
- Moved /usr/share/gutenprint/doc to %doc of main rpm and devel rpm 
- Additionally added API documents for gutenprint and gutenprintui2

* Tue Aug 08 2006 Parag Nemade <panemade>- 5.0.0-0.6
- Added cups-genppdupdate.5.0 at post section
- Splitted gutenprint main rpm for separate languages

Removing FE-NEEDSPONSOR as submitter was sponsored in: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199254

May I see official Review of this now as i feel its now in better consition to
be included in FE

I'll try and do a full review on this later today unless someone else wants to 
jump in first. 

OK - Package name
OK - Spec file matches base package name.
OK - Meets Packaging Guidelines.
OK - License (GPL)
OK - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
ede8acbd1e94c9d4fd366fb37e335bfb  gutenprint-5.0.0.tar.bz2
ede8acbd1e94c9d4fd366fb37e335bfb  gutenprint-5.0.0.tar.bz2.1
OK - Package compiles and builds on at least one arch.
OK - BuildRequires correct
OK - Spec handles locales/find_lang
See below - Spec has needed ldconfig in post and postun
OK - Package has no duplicate files in %files.
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
See below - Spec has consistant macro usage.
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - Headers/static libs in -devel subpackage.
OK - .pc files in -devel subpackage.
OK - .so files in -devel subpackage.
OK - -devel package Requires: %{name} = %{version}-%{release}
OK - .la files are removed.
OK - Package doesn't own any directories other packages own.
See below - No rpmlint output.

SHOULD Items:

OK - Should include License or ask upstream to include it.
See below - Should build in mock.
OK - Should have subpackages require base package with fully versioned depend.

Issues:

1.  No need for the:
Requires(post): /sbin/ldconfig
Requires(postun): /sbin/ldconfig

Using post/postun with -p /sbin/ldconfig adds the dependency for you.

2. You're mixing the %{buildroot} and the $RPM_BUILD_ROOT macros.
Try and pick one and use only that style...

3. The package doesn't seem to build under mock/devel/i386:

RPM build errors:
    File not found by glob: /var/tmp/gutenprint-5.0.0-0.7.fc6-root-mockbuild/
usr/lib/gimp/*/plug-ins/print

The plug-ins directory there is empty. Perhaps a missing BuildRequires or 
something
that's preventing the plug-ins from being built? Removing that from the files
list gets it to build.

4. rpmlint says:

W: gutenprint macro-in-%changelog doc
W: gutenprint macro-in-%changelog configure

rpm will expand macros even in changelogs. Change them to %%doc and %%configure 
to
prevent this.

W: gutenprint mixed-use-of-spaces-and-tabs

Should pick one or the other.

W: gutenprint-cups no-documentation
W: gutenprint-extras no-documentation
W: gutenprint-foomatic no-documentation
W: gutenprint-ppds-cs no-documentation
W: gutenprint-ppds-da no-documentation
W: gutenprint-ppds-de no-documentation
W: gutenprint-ppds-el no-documentation
W: gutenprint-ppds-en_GB no-documentation
W: gutenprint-ppds-es no-documentation
W: gutenprint-ppds-fr no-documentation
W: gutenprint-ppds-hu no-documentation
W: gutenprint-ppds-ja no-documentation
W: gutenprint-ppds-nb no-documentation
W: gutenprint-ppds-nl no-documentation
W: gutenprint-ppds-pl no-documentation
W: gutenprint-ppds-pt no-documentation
W: gutenprint-ppds-sk no-documentation
W: gutenprint-ppds-sv no-documentation
W: gutenprint-ppds-zh_TW no-documentation

All those can be ignored.

5. Might include Changelog as a %doc?

Here is updated package but still mock build is really failing now. previous
releases it was not the case. If i manually build rpm using rpmbuild -ba
gutenprint.spec then  its executing gimp2 dir and installing
/usr/lib/gimp/2.0/plug-ins/print file, but same will not be happening in mock.
That means i am missing some BR. I confused becuase i have already added all BRs.

Spec URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.9.fc6.src.rpm

Got it. I need to add gimp as BR instread to make it as
Requires : gimp

Updated package
Spec URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.10.fc6.src.rpm

Excellent. I am still seeing: 
W: gutenprint mixed-use-of-spaces-and-tabs
from rpmlint. You might replace the tabs with spaces in the spec... but thats 
not a blocker. 

It looks like the package conflicts with the gimp-print-plugin package in core: 

        file /usr/lib/gimp/2.0/plug-ins/print from install of gutenprint-5.0.0-
0.10.fc6 conflicts with file from package gimp-print-plugin-4.2.7-20.1

Extras packages must not conflict with core packages. Is there some way to
move the file or otherwise prevent the conflict?

But actually all gimp-print packages must be obsolete by this package. AFAIK
this package will be replacing gimp-print in FC7 core. Becuase gimp-print is now
old and its next version is gutenprint.

Should i create similar way of gimp-print-plugin rpm created by gimp-print spec
here in my case also. I mean Do i need to have separate package for file
/usr/lib/gimp/2.0/plug-ins/print
??

Anyway i have upgraded package to create one more sub-package gutenprint-plugin
and i hope now there will be no more rpmlint warnings you will find. But yes it
will be problematic for core gimp-print package

I already added commented lines in SPEC that will obsolete core packages. But
its not allowed right?

Updated package
Spec URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.11.fc6.src.rpm

Thats unfortunate. Extras packages are not supposed to conflict or obsolete 
core packages (Although there could be a explicit statement about that in the 
review/packaging guidelines).

I see two ways forward:

1. Since this package will replace gimp-print in FC7 we can leave the package 
here (updating with new releases, etc) and wait until FC7 opens up for new 
packages and then have the core folks import this package to replace gimp 
print. This means people won't be able to easily use it until it's imported in 
core however.

2. (prefered by me) Is there any way that this package can install along side 
(but not conflicting with) gimp-print and allow users to select which one they 
wish to use? I see encouraging signs of this in the README, like:
    
    "Installing the CUPS driver for Gutenprint 5.0 will not interfere
    with your ability to continue using the Gimp-Print 4.2 CUPS
    driver."

and

    * Gutenprint permits installation of Gimp-Print 4.2 alongside
      Gutenprint 5.0, and in the future will permit concurrent
      installation of different stable versions of Gutenprint with
      different minor version numbers.  Gutenprint uses the old-style
      kernel numbering system, whereby even numbered minor versions
      are stable (4.2, 5.0, 5.2) and odd numbered minor versions are
      development (4.3, 5.1).  Therefore, you should consider allowing
      Gutenprint 5.0 and Gimp-Print 4.2 to be installed concurrently.

and

    * All files and directories with versioned names
      (e. g. cups-genppdupdate, rastertogutenprint, the PPD files) may
      be installed concurrently with other versions of Gimp-Print and
      Gutenprint as described above.  Other executables (such as the
      Canon and Epson back ends, and cups-calibrate) are not
      versioned, but are not linked against libgutenprint and do not
      have any other dependencies on Gutenprint.

However, the gimp plugin appears problematic:

     * The GIMP plugin, unlike the core library and the Foomatic and
      CUPS drivers, may not be installed concurrently with other
      versions.  For example, you may not install both the Gimp-Print
      4.2 and the Gutenprint 5.0 version of the Print plugin, as they
      use different configuration file formats.

So, I would suggest: Not shipping a gimp plugin (comment out, but leave in
the spec for fc7+), and seeing if you can get this package to not conflict with
gimp-print-4.2. The conflicts I see:

        file /usr/lib/gimp/2.0/plug-ins/print from install of gutenprint-5.0.0-
0.10.fc6 conflicts with file from package gimp-print-plugin-4.2.7-20.1
        file /usr/bin/escputil from install of gutenprint-5.0.0-0.10.fc6 
conflicts with file from package gimp-print-utils-4.2.7-20.1
        file /usr/share/man/man1/escputil.1.gz from install of gutenprint-5.0.0-
0.10.fc6 conflicts with file from package gimp-print-utils-4.2.7-20.1
        file /usr/bin/cups-calibrate from install of gutenprint-cups-5.0.0-
0.10.fc6 conflicts with file from package gimp-print-cups-4.2.7-20.1
        file /usr/lib/cups/backend/canon from install of gutenprint-cups-5.0.0-
0.10.fc6 conflicts with file from package gimp-print-cups-4.2.7-20.1
        file /usr/lib/cups/backend/epson from install of gutenprint-cups-5.0.0-
0.10.fc6 conflicts with file from package gimp-print-cups-4.2.7-20.1
        file /usr/lib/cups/filter/commandtocanon from install of gutenprint-
cups-5.0.0-0.10.fc6 conflicts with file from package gimp-print-cups-4.2.7-20.1
        file /usr/lib/cups/filter/commandtoepson from install of gutenprint-
cups-5.0.0-0.10.fc6 conflicts with file from package gimp-print-cups-4.2.7-20.1
        file /usr/share/man/man8/cups-calibrate.8.gz from install of gutenprint-
cups-5.0.0-0.10.fc6 conflicts with file from package gimp-print-cups-4.2.7-20.1

Perhaps the gutenprint-devel list could tell you how to configure things so 
gutenprint can work with gimp-print-4.2 already installed? Perhaps the above 
cups conflicts just need to have a gutenprint- prefix? 

I'm also for the "Lets not ship the gimp plugin for now" route. Maybe we even
can get this package as a proper Fedora Core update with the plugin later in FC6
after the package got a bit of testing in Extras.

For time-being, here is the update which is based on following text from README

    * Gutenprint permits installation of Gimp-Print 4.2 alongside
      Gutenprint 5.0, and in the future will permit concurrent
      installation of different stable versions of Gutenprint with
      different minor version numbers.  Gutenprint uses the old-style
      kernel numbering system, whereby even numbered minor versions
      are stable (4.2, 5.0, 5.2) and odd numbered minor versions are
      development (4.3, 5.1).  Therefore, you should consider allowing
      Gutenprint 5.0 and Gimp-Print 4.2 to be installed concurrently.


For CUPS sub-package ===>
 "Installing the CUPS driver for Gutenprint 5.0 will not interfere
    with your ability to continue using the Gimp-Print 4.2 CUPS
    driver."
AND
    * All files and directories with versioned names
      (e. g. cups-genppdupdate, rastertogutenprint, the PPD files) may
      be installed concurrently with other versions of Gimp-Print and
      Gutenprint as described above.  Other executables (such as the
      Canon and Epson back ends, and cups-calibrate) are not
      versioned, but are not linked against libgutenprint and do not
      have any other dependencies on Gutenprint.

For plugin sub-package which is disabled in SPEC becuase of ===>
However, the gimp plugin appears problematic:
     * The GIMP plugin, unlike the core library and the Foomatic and
      CUPS drivers, may not be installed concurrently with other
      versions.  For example, you may not install both the Gimp-Print
      4.2 and the Gutenprint 5.0 version of the Print plugin, as they
      use different configuration file formats.

I have disabled all conflicting files to be installed. 
Updated package have same versioning
Spec URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.11.fc6.src.rpm

From the gutenprint front page: "Gutenprint was formerly called Gimp-Print."

This program has had a change of name in version 5.0.  I have a feeling if it
had simply kept it's old name, we'd just drop gimp-print 4.2.x and upgrade
gimp-print to version 5.0. That's all this essentially is. Yes, you can install
them side-by-side, simply because it's a major upgrade (think: installing OOo1 &
OOo2 at the same time).

It seems to me that this isn't really an /extras/ package conflicting with a
/core/ package, it's a /core/ package which has seen major improvements and now
has a new name. I hope we don't get stuck with the old printing capabilities of
gimp due to this...

We didn't keep phoenix in parallel just because it was renamed firefox (by way
of hypothetical example)...

My two pence. :)  /me out

In answer to comment #47: 

This package builds fine and installs ok alongside gimp-print. Unfortunately, I 
only have one printer here and it's being cranky. I am able to select the 
gutenprint drivers in system-config-printer and in the cups admin interface. 
Can some more of the folks watching this review try the package out and see if 
they run into any problems? It's looking ok here from prelim testing... 

In answer to comment #48: 

fc6 is frozen now, and has gimp-print in it. fc7 will likely have gutenprint, 
but thats going to be quite a while away for most people to use. If we can get 
this package in extras to work alongside the gimp-print that helps a lots of 
people, until it can be merged into core in fc7. 

(In reply to comment #49)
> This package builds fine and installs ok alongside gimp-print. Unfortunately, I 
> only have one printer here and it's being cranky. I am able to select the 
> gutenprint drivers in system-config-printer and in the cups admin interface. 
> Can some more of the folks watching this review try the package out and see if 
> they run into any problems? It's looking ok here from prelim testing... 

I currently don't have hardware at hand to test it. Just my 2 cent: I'd say just
approve this package if it looks okay otherwise and if the packagers made sure
it works

Perhaps we could call for testers on fedora-extras and fedora-devel lists?

Parag: Can you ask for testers on those lists? 
If you like I can probibly build packages for fc5|fc6 i386/x86_64 and put them 
up so people don't need to build the packages to test... 

I would feel better if we had at least a few 'this works fine for me' 
reports... 

I would like to add that I would very much like to see this in FC6 core.  I have
been hand compiling and installing gutenprint for over a year now in order to
support a printer that isn't properly supported by gimp-print.  This has been
very irritating to do, and I've gotten parts of it wrong leading to the need to
configure printers through the ipp web interface instead of using
system-config-printers and having garbage i18n characters show up in ipp.

I'm thinking of moving a couple of friends I support to Ubuntu just because they
have gutenprint.

kevin,
   Can you plz put gutenprint packages for x86_64 for fc5/fc6??

Sure, I would be happy to... 

For some reason the x86_64 build isn't working for me now. I get: 

RPM build errors:
    File not found: /var/tmp/gutenprint-5.0.0-0.11.fc6-root-mockbuild/usr/lib64/
cups/filter/rastertogutenprint.5.0

Perhaps some change in core? 
Any ideas? 

rastertogutenprint.5.0 is a part of gutenprint-cups package. Its building fine
on i386. Can you mock build it and check for any errors in build.log?

It looks like it's installing that under /usr/lib on x86_64, instead of /usr/
lib64... ;( 

grep rastertogutenprint.5.0 build.log:

  /bin/sh ../../libtool --mode=install /usr/bin/install -c 
'rastertogutenprint.5.0' '/var/tmp/gutenprint-5.0.0-0.11.fc6-root-mockbuild/usr/
lib/cups/filter/rastertogutenprint.5.0'
/usr/bin/install -c .libs/rastertogutenprint.5.0 /var/tmp/gutenprint-5.0.0-
0.11.fc6-root-mockbuild/usr/lib/cups/filter/rastertogutenprint.5.0
extracting debug info from /var/tmp/gutenprint-5.0.0-0.11.fc6-root-mockbuild/
usr/lib/cups/filter/rastertogutenprint.5.0
error: File not found: /var/tmp/gutenprint-5.0.0-0.11.fc6-root-mockbuild/usr/
lib64/cups/filter/rastertogutenprint.5.0
    File not found: /var/tmp/gutenprint-5.0.0-0.11.fc6-root-mockbuild/usr/lib64/
cups/filter/rastertogutenprint.5.0

when i check RPMMacros wiki page i found
%{_libdir} extracts to /usr/lib only not /usr/lib64 as %{_lib} evaluates to lib 
do we need separate SPEC or there is some trick to make same SPEC work on x86_64
arch??

ok, looking at the cups.spec from core, what they do is at the top define: 

%define cups_serverbin %{_exec_prefix}/lib/cups

I think you should do likewise and then replace the %{_libdir} in the cups 
package and the directories you remove from the cups package with the macro 
above... 

I tried something like this:

--- gutenprint.spec.1   2006-09-08 06:34:57.000000000 -0600
+++ gutenprint.spec     2006-09-25 20:12:30.000000000 -0600
@@ -1,4 +1,5 @@
 %define build_with_ijs_support 1
+%define cups_serverbin %{_exec_prefix}/lib/cups
 
 Name:           gutenprint
 Summary:        Printer Drivers Package
@@ -223,9 +224,9 @@
 rm -rf %{buildroot}%{_bindir}/escputil
 rm -rf %{buildroot}%{_mandir}/man1/escputil.1*
 rm -rf %{buildroot}%{_libdir}/gimp/2.0/plug-ins/print
-rm -rf %{buildroot}%{_libdir}/cups/backend/*
-rm -rf %{buildroot}%{_libdir}/cups/filter/commandtocanon
-rm -rf %{buildroot}%{_libdir}/cups/filter/commandtoepson
+rm -rf %{buildroot}%{cups_serverbin}/backend/*
+rm -rf %{buildroot}%{cups_serverbin}/filter/commandtocanon
+rm -rf %{buildroot}%{cups_serverbin}/filter/commandtoepson
 rm -rf %{buildroot}%{_bindir}/cups-calibrate
 rm -rf %{buildroot}%{_mandir}/man8/cups-calibrate.8*
 
@@ -304,10 +305,10 @@
 %defattr(-, root, root,-)
 %config(noreplace) %{_sysconfdir}/cups/command.types
 %{_datadir}/cups/calibrate.ppm
-#%{_libdir}/cups/backend/*
-#%{_libdir}/cups/filter/*
+#%{cups_serverbin}/cups/backend/*
+#%{cups_serverbin}/cups/filter/*
 #%{_bindir}/cups-calibrate
-%{_libdir}/cups/filter/rastertogutenprint.5.0
+%{cups_serverbin}/filter/rastertogutenprint.5.0
 %{_sbindir}/cups-genppd*
 %{_datadir}/cups/model/gutenprint/5.0/C
 #%{_mandir}/man8/cups-calibrate.8*

That gets it further, but it's now dying in a very odd way making the ppd 
files. If you would like access to my x86_64 test box to do test builds, drop 
me an email and I will get you access there. 

Oddly, that error only happens on devel/fc6. On fc5, the above patch gets it 
compiling on x86_64 just fine. ;( 

For folks that would like to test, I have put up some repos for fc5{i386/
x86_64} and fc6(i386 only for now): 

--cut--
[gutenprint-test]
name=gutenprint testing rpms
baseurl=http://www.scrye.com/gutenprint/$releasever/$basearch/
enabled=1
gpgcheck=0
--cut--

I get this error while trying to install your rpm on a FC6 test 3+ (rawhide
basically)..

Loading "installonlyn" plugin
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package gutenprint.i386 0:5.0.0-0.11.fc6 set to be updated
--> Running transaction check
--> Processing Dependency: libgtk-1.2.so.0 for package: gutenprint
--> Processing Dependency: libgdk-1.2.so.0 for package: gutenprint
--> Processing Dependency: libglib-1.2.so.0 for package: gutenprint
--> Processing Dependency: libgmodule-1.2.so.0 for package: gutenprint
--> Finished Dependency Resolution
Error: Missing Dependency: libgtk-1.2.so.0 is needed by package gutenprint
Error: Missing Dependency: libgdk-1.2.so.0 is needed by package gutenprint
Error: Missing Dependency: libglib-1.2.so.0 is needed by package gutenprint
Error: Missing Dependency: libgmodule-1.2.so.0 is needed by package gutenprint

In reply to comment #60:

Do you have the extras-development repository enabled? 
gtk+ is in extras. It should pull it in. 

I was using extras-development, just that the server I sync against (I mirror it
locally), isnt' updated or something.  Renabling the mirrorlist and it
downloaded the correct RPMs.

I'm using it now, works fine (I'm just using the drivers).

What needs the gtk+ libs (nothing yet, of course), and can those files be put
into a subpackage as well?

I have tested the compiled drivers from repository (x86_64/fc5).
Working fine on a canon ip3000/USB using ip4000 driver.

I rebuilt Guteprint for x86_64 system using mock and tested it with Epson Stylus
CX4600. Guteprint immediately recognized the printer and set the right driver.
With the old gimp-print, the closed driver was for Stylus CX3200. As a result,
most of the configuration for CX4600 are available including the CMYK color
setting. The noticeable difference is the improved speed of the printer and the
bug that prevent a proper output of paper is fixed. 

I really hope this pacakge will make on Extras repository once rpmlint will be
sorted as it dramatically improve the performance of the printer. Kudos for
Epson for helping providing Linux support for their printer. Although it is too
late to include it on Core repository, this package will definitively be
available as default on FC7 and above.

Excellent to hear some positive testing reports both here and on the lists. 

In reply to comment #63:

It looks like the libgutenprintui libraries in the main package need gtk
libgutenprintui.so.1
libgutenprintui2.so.1

I don't know if they can be split off or not... Parag?

Parag: 

- Can you apply something like the changes from comment #58 with a proper
changelog entry and upload a new spec/src.rpm?

- I just did another fc6/x86_64 build here and it worked. Either the problem I 
was seeing before was something that was temp broken in devel, or there is some 
kind of race condition in the build process that I managed to hit. 

- Can you also add '--disable-rpath' to the configure call? This shows up on 
x86_64 rpmlint as: 
E: gutenprint binary-or-shlib-defines-rpath /usr/lib64/libgutenprintui.so.1.0.0 
['/usr/lib64']
E: gutenprint binary-or-shlib-defines-rpath /usr/lib64/
libgutenprintui2.so.1.0.0 ['/usr/lib64']
E: gutenprint binary-or-shlib-defines-rpath /usr/bin/ijsgutenprint.5.0 ['/usr/
lib64']
E: gutenprint-cups binary-or-shlib-defines-rpath /usr/sbin/cups-genppd.5.0 ['/
usr/lib64']
E: gutenprint-cups binary-or-shlib-defines-rpath /usr/lib/cups/filter/
rastertogutenprint.5.0 ['/usr/lib64']
E: gutenprint-extras binary-or-shlib-defines-rpath /usr/bin/testpattern ['/usr/
lib64']

(In reply to comment #66)
> Excellent to hear some positive testing reports both here and on the lists. 

Thanks to all whot tested this package.

> 
> In reply to comment #63:
> 
> It looks like the libgutenprintui libraries in the main package need gtk
> libgutenprintui.so.1
> libgutenprintui2.so.1
> 
> I don't know if they can be split off or not... Parag?

I don't think we should split them and create a new package. Those are part of
gutenprint-devel package. And as all *.so.1 files must go to -devel packages,
ther are already there. 

> 
> Parag: 
> 
> - Can you apply something like the changes from comment #58 with a proper
> changelog entry and upload a new spec/src.rpm?

Will do that later today.

> 
> - I just did another fc6/x86_64 build here and it worked. Either the problem I 
> was seeing before was something that was temp broken in devel, or there is some 
> kind of race condition in the build process that I managed to hit. 
> 
> - Can you also add '--disable-rpath' to the configure call? This shows up on 
> x86_64 rpmlint as: 
> E: gutenprint binary-or-shlib-defines-rpath /usr/lib64/libgutenprintui.so.1.0.0 
> ['/usr/lib64']
> E: gutenprint binary-or-shlib-defines-rpath /usr/lib64/
> libgutenprintui2.so.1.0.0 ['/usr/lib64']
> E: gutenprint binary-or-shlib-defines-rpath /usr/bin/ijsgutenprint.5.0 ['/usr/
> lib64']
> E: gutenprint-cups binary-or-shlib-defines-rpath /usr/sbin/cups-genppd.5.0 ['/
> usr/lib64']
> E: gutenprint-cups binary-or-shlib-defines-rpath /usr/lib/cups/filter/
> rastertogutenprint.5.0 ['/usr/lib64']
> E: gutenprint-extras binary-or-shlib-defines-rpath /usr/bin/testpattern ['/usr/
> lib64']
> 


Kevin,
 Sure will add --disable-rpath to ./configure in SPEC.
So same %{_libdir} macro worked for x86_64 right in mock build??

(In reply to comment #67)
> > It looks like the libgutenprintui libraries in the main package need gtk
> > libgutenprintui.so.1
> > libgutenprintui2.so.1
> > 
> > I don't know if they can be split off or not... Parag?
> 
> I don't think we should split them and create a new package. Those are part of
> gutenprint-devel package. And as all *.so.1 files must go to -devel packages,
> ther are already there. 

Why should they be in the -devel subpackage? It was my understanding that only
the unversioned shared object files must be in the -devel subpackage (*.so); and
versioned libraries (*.so.N and so on) should be in the main package or a -libs
subpackage or something similar, as appropriate. Is this not the case here?

Thanks peter, 
 My mistake I forgot the following MUST
- MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
then library files that end in .so (without suffix) must go in a -devel package.
Will Change SPEC and uplaod new package later today.

Peter,
   you confused me. I rechecked for .so files and found that 
 rpm -ql gutenprint | grep so
/usr/lib/gutenprint/5.0.0/modules/color-traditional.so
/usr/lib/gutenprint/5.0.0/modules/print-canon.so
/usr/lib/gutenprint/5.0.0/modules/print-escp2.so
/usr/lib/gutenprint/5.0.0/modules/print-lexmark.so
/usr/lib/gutenprint/5.0.0/modules/print-olympus.so
/usr/lib/gutenprint/5.0.0/modules/print-pcl.so
/usr/lib/gutenprint/5.0.0/modules/print-ps.so
/usr/lib/gutenprint/5.0.0/modules/print-raw.so
/usr/lib/libgutenprint.so.2
/usr/lib/libgutenprint.so.2.0.0
/usr/lib/libgutenprintui.so.1
/usr/lib/libgutenprintui.so.1.0.0
/usr/lib/libgutenprintui2.so.1
/usr/lib/libgutenprintui2.so.1.0.0

AND
 rpm -ql gutenprint-devel | grep so
/usr/lib/libgutenprint.so
/usr/lib/libgutenprintui.so
/usr/lib/libgutenprintui2.so

This clearly shows that packaging for gutenpeint is corret. isn't it?

Kevin,
 If you check current SPEC i have commented some files to solve issue of having
both gimp-print and gutenprint to be installed on same machine. And the patch
you posted contains those files to be packaged. What should you suggest now?

Kevin,
Kindly forget my last comment. Arghh its vey busy day today and that made me to
read wrongly your patch. Actually i reinstalled my system and now i got my
system back working again. Here is updated SPEC and SRPM location
Spec URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.12.fc6.src.rpm

I have kept last version's SRPM online as it is.
Can you please check whether this new SRPM is buiding RPMs for x86_64 properly??

Created attachment 137323 [details]
build result

Attempting to build x86_64 package. It looks like errors occured because
program link to lib instead of lib64.

(In reply to comment #70)
> Peter,
>    you confused me. I rechecked for .so files and found that 
>  rpm -ql gutenprint | grep so
> [...]
> This clearly shows that packaging for gutenpeint is corret. isn't it?

That looks correct to me. Thanks for fixing it.

In reply to comment #72:

Nope. You missed 3 lines you need to change from _libdir to the cups_serverbin: 

< rm -rf %{buildroot}%{_libdir}/cups/backend/*
< rm -rf %{buildroot}%{_libdir}/cups/filter/commandtocanon
< rm -rf %{buildroot}%{_libdir}/cups/filter/commandtoepson
---
> rm -rf %{buildroot}%{cups_serverbin}/backend/*
> rm -rf %{buildroot}%{cups_serverbin}/filter/commandtocanon
> rm -rf %{buildroot}%{cups_serverbin}/filter/commandtoepson

Can you change those and spin a -13 release?

If that looks good and builds ok, and given that we have now had some favorable 
comments from testers, I am ready to approve... 

thanks for your patience... 

Updated Package:-

Spec URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.13.fc6.src.rpm

ok. I see only two more minor issues: 

- /usr/lib/gutenprint/5.0.0/modules/ has .la files in it still. Can you remove 
those at the same time you remove other la files? 

- You should own (ie, add to files in main package):
/usr/share/gutenprint/5.0.0
/usr/share/gutenprint

It would be nice to remove the dependency on gtk+, but I don't see an easy way 
to do this off hand. Anyone else see an easy way to do so?

The -13 builds fine on i386 and x86_64 here. 

Kevin,
    Done. Updated packages can be found at
Spec URL: http://people.redhat.com/pnemade/gutenprint/gutenprint.spec
SRPM URL:
http://people.redhat.com/pnemade/gutenprint/gutenprint-5.0.0-0.14.fc6.src.rpm

one issue: 

- #rm -rf %{buildroot} in clean? That shouldn't be commented... perhaps it was 
while you were testing something?

Fix that before you import it? 

I think all the issues I can see are solved, so this package is APPROVED. 
Don't forget to close this NEXTRELASE when you have imported and built it. 

Thanks for your patience with this long process. 

Kevin,
 Thnaks very much for your time and sponsoring this package. I have imported
package. Do I need to build it on build server? If yes how can i do that?

Parag: You'll need to setup your install the client-side tools and whatnot for
the build system, the import the package and tag then enqueue a build for it.
For more information please see:
http://fedoraproject.org/wiki/Extras/Contributors#head-0956b12959af46cfe0aa12d09ed15e573bfd9ef4

(In reply to comment #81)
> Parag: You'll need to setup your install the client-side tools [...]

That should read "...need to install and setup the client-side tools..."

Apologies for any confusion.

I got some issues in package build i gave following command
plague-client build gutenprint gutenprint-5.0.0-0.14.fc6 fc6


Got results as 
Error: could not check out gutenprint-5.0.0-0.14.fc6 from
fedora-development-extras - output was:

cvs checkout: warning: cannot open /cvs/extras/CVSROOT/val-tags read/write:
Permission denied
cvs [checkout aborted]: no such tag gutenprint-5.0.0-0.14.fc6


What i missed?

You should not specify the fc6 tag... 

Just use 'make build' or 'make plague' in your gutenprint/devel directory, it 
will make the right plague-client call. It should be something like: 

plague-client build gutenprint gutenprint-5.0.0-0.14 devel

(In reply to comment #84)
> You should not specify the fc6 tag... 

 ?!

 That comes from %{?dist} dist tag and it is the right behaviour.

 I suspect that Parag is missing the make tag.

 Just for reference after confirming that changes are the one I really want to 
commit I do this:

$ make clog && cvs ci -F clog && make clean && make tag && make build

In this case looking closer, it looks like the package was tagged incorrectly. 
Parag: did you use 'make tag' or something else to tag the files?

Your best bet is probibly to bump the release up to 15 (and add a changelog 
that you did so for tagging issues) check in your .spec file with that change, 
and do 'make tag && make build' 

(In reply to comment #84)
> You should not specify the fc6 tag... 
> 
> Just use 'make build' or 'make plague' in your gutenprint/devel directory, it 
> will make the right plague-client call. It should be something like: 
> 
> plague-client build gutenprint gutenprint-5.0.0-0.14 devel
> 
> 

kevin,
   Can you please give me step by step procedure right after i boot my machine
and connected to internet?? How can i go to gutenprint/devel directory? Do i
need to login to build server? how?

This is getting a bit offtopic for here, so I sent Parag a direct email
with more info on cvs setup. 

Sorry for taking much time to build that package. But After all this is first
time i did build my package. So it took some time to learn me. 
Thanks to Kevin and all those who helped me alot to make and test this package.

I've installed the packages on extras and everything appears to be working fine
with the exception of replacement of the gimp-print plugin.  I tried removing
the gimp-print-plugin provided in FC6 core, but then realized their doesn't
appear to be an rpm available to replace it.  Is one in the works, or is this
deferred to FC7?  Thanks!

(In reply to comment #90)
> I've installed the packages on extras and everything appears to be working fine
> with the exception of replacement of the gimp-print plugin.  I tried removing
> the gimp-print-plugin provided in FC6 core, but then realized their doesn't
> appear to be an rpm available to replace it.  Is one in the works, or is this
> deferred to FC7?  Thanks!
yes extras version of gutenprint is meant for parallel installation of old
gimp-print package along with new gutenprint package. Check more in gutenprint's
SPEC file about what is set for FC7 and what excluded in extras.
http://cvs.fedora.redhat.com/viewcvs/rpms/gutenprint/devel/gutenprint.spec?root=extras&view=markup