Bug 705043 - Review Request: paco - a source code package organizer for Unix
Summary: Review Request: paco - a source code package organizer for Unix
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Susi Lehtola
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 184008 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-16 13:33 UTC by Veeti Paananen
Modified: 2011-08-22 14:56 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-08-09 01:31:13 UTC
susi.lehtola: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Veeti Paananen 2011-05-16 13:33:35 UTC
Spec: http://rojekti.fi/files/paco/paco.spec
SRPM: http://rojekti.fi/files/paco/paco-2.0.9-1.fc14.src.rpm
Description: After the installation of a source package with "./configure && make && make install", one is usually left with having no idea of what it was installed and where it all went, making it difficult to uninstall the package in the future.

Paco was written to solve this problem in a quite simple fashion.

When installing a package from sources, paco wraps the "make install" command (or whatever command or group of commands are needed to install the files into the system), and saves installation information into a text database.

This is my first package and I need a sponsor.

(There is a very old previous request for the same application at bug 184008. I've been adviced to create a new request.)

Comment 1 Damien Durand 2011-05-16 14:58:05 UTC
*** Bug 184008 has been marked as a duplicate of this bug. ***

Comment 2 Fabian Affolter 2011-06-04 16:19:35 UTC
Just some comment on your spec file:

- rpmlint output:

[fab@laptop021 SRPMS]$ rpmlint paco-2.0.9-1.fc14.src.rpm 
paco.src: E: description-line-too-long C After the installation of a source package with "./configure && make && make install", one is usually left with having no idea of what it was installed and where it all went, making it difficult to uninstall the package in the future.
paco.src: E: description-line-too-long C When installing a package from sources, paco wraps the "make install" command (or whatever command or group of commands are needed to install the files into the system), and saves installation information into a text database.
paco.src: E: description-line-too-long C Paco has many usage options for removing packages, looking at package files, file counts, sorting, missing files, etc. Run "paco -h" on the command line, or "man paco" for more information.
paco.src:13: W: configure-without-libdir-spec
1 packages and 0 specfiles checked; 3 errors, 1 warnings.

[fab@laptop021 x86_64]$ rpmlint paco*
paco.x86_64: E: description-line-too-long C After the installation of a source package with "./configure && make && make install", one is usually left with having no idea of what it was installed and where it all went, making it difficult to uninstall the package in the future.
paco.x86_64: E: description-line-too-long C When installing a package from sources, paco wraps the "make install" command (or whatever command or group of commands are needed to install the files into the system), and saves installation information into a text database.
paco.x86_64: E: description-line-too-long C Paco has many usage options for removing packages, looking at package files, file counts, sorting, missing files, etc. Run "paco -h" on the command line, or "man paco" for more information.
paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit@GLIBC_2.2.5
paco.x86_64: E: incorrect-fsf-address /usr/share/doc/paco-2.0.9/COPYING
paco.x86_64: W: no-manual-page-for-binary ocap
2 packages and 0 specfiles checked; 4 errors, 2 warnings.

- Development .so files needs to go to a -devel subpackage
- ChangeLog file is missing in %doc

Comment 3 Veeti Paananen 2011-06-04 20:43:53 UTC
I've taken your comments into account and made some changes to the spec file. The new files are here:

Spec: http://rojekti.fi/files/paco/paco-2.spec
SRPM: http://rojekti.fi/files/paco/paco-2.0.9-1.fc15.src.rpm

What I've done:

* Fixed the description text.
* Changed the "Group" to "Applications/System", since I think that makes more sense for than "Development/Tools".
* Included the ChangeLog file.

Here's the new rpmlint output:

[veeti@veeti-pc SPECS]$ rpmlint ../SRPMS/paco-2.0.9-1.fc15.src.rpm 
paco.src:13: W: configure-without-libdir-spec
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

I assume that this is just a false positive, since the description has a line with the text ./configure inside it.

[veeti@veeti-pc SPECS]$ rpmlint ../RPMS/x86_64/paco-2.0.9-1.fc15.x86_64.rpm 
paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit@GLIBC_2.2.5
paco.x86_64: E: incorrect-fsf-address /usr/share/doc/paco-2.0.9/COPYING
paco.x86_64: W: no-manual-page-for-binary ocap
1 packages and 0 specfiles checked; 1 errors, 2 warnings.

What should I do about the incorrect FSF address? Patch the COPYING file?

As for the libpaco-log library, I don't think that it's a "development file", since it's an essential component of the paco application. From the paco website:

"How does it perform this magic? It is accomplished using the LD_PRELOAD method, which preloads a shared library before installation using the environment variable LD_PRELOAD. During installation, this library catches the system calls that cause filesystem alterations (such as open, link, rename, ...), and logs the created files."

Thanks!

Comment 4 Veeti Paananen 2011-06-16 01:15:56 UTC
I realized something yesterday - I had completely ignored the "gpaco" GUI frontend included in paco. So I started tinkering around with subpackages (using the existing cmake package as an example), and added a "paco-gui" subpackage to the spec. So the newest files can be found here:

SPEC: http://rojekti.fi/files/paco/3/paco.spec
SRPM: http://rojekti.fi/files/paco/3/paco-2.0.9-3.fc15.src.rpm

(Better late than never, right?)

I'm not completely sure about the subpackage's name: should it be paco-gui or gpaco (as the actual executable is called gpaco)?

In addition, I've patched the license file to fix the FSF address error, and there's also another patch there to make the gpaco.desktop file more compliant. I've e-mailed the author about those.

And that's not all - I've also fixed a line in the %files section that was causing some dependency problems with i686 builds. Thanks to Rex and Kevin for their help in the devel mailing list!

Here's the latest rpmlint output straight out of the oven:

[veeti@veeti-pc SPECS]$ rpmlint paco.spec
paco.spec:20: W: configure-without-libdir-spec
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

Same as before - false positive (?) from the package description.

[veeti@veeti-pc x86_64]$ rpmlint paco-2.0.9-3.fc15.x86_64.rpm 
paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit@GLIBC_2.2.5
paco.x86_64: W: no-manual-page-for-binary ocap
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

[veeti@veeti-pc x86_64]$ rpmlint paco-gui-2.0.9-3.fc15.x86_64.rpm 
paco-gui.x86_64: W: no-documentation
paco-gui.x86_64: W: no-manual-page-for-binary gpaco
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

Comment 5 Martin Gieseking 2011-07-17 11:23:08 UTC
Hi Veeti, here are some comments on your latest package:

- if you don't plan to maintain the package for EPEL < 6, you can drop all the
  buildroot stuff (BuildRoot field, %clean section, initial cleaning of the
  buildroot in %install)

- you should ask upstream to properly apply the GPL by adding the text given in 
  COPYING to the source files:

   <one line to give the program's name and a brief idea of what it does.>
   Copyright (C) <year>  <name of author>

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   ...

  Without these information it's not clear what license is actually intended
  (GPL+, GPLv2, GPLv2+). Currently, it's actually GPL+ as relying on COPYING
  is not sufficient. Also see the information given here:
  http://fedoraproject.org/wiki/Licensing:Main

- The rpmlint warning shared-lib-calls-exit should be fixed upstream.

- I suggest to prefix the patch file names with the package name to avoid
  conflicts and to easily find the patches in the source directory:
  paco-fix-fsf-address.patch
  paco-fix-desktop-file.patch

- Giving the full icon path in the .desktop file is fine, but it's 
  recommended to simply use the basename of the icon file:
  http://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files

- It's common practice to list all BuildRequires at the top part of the spec
  file, e.g. below BuildRoot or the PatchXXX lines -- even those of the
  subpackages. This allows to get an overview of the direct dependencies 
  easily.

- You should preserve the timestamp of file ChangeLog, e.g. with 
  iconv -f iso8859-1 -t utf-8 ChangeLog > ChangeLog.conv && \
  touch -r ChangeLog ChangeLog.conv && \
  mv -f ChangeLog.conv ChangeLog

- Directory %{_datadir}/paco/ only contains README, faq.txt, and pacorc.
  README is already packaged as %doc, and pacorc is installed in /etc.
  Thus, I recommend to drop %{_datadir}/paco/ completely. You can add faq.txt
  as %doc as well.

- Please be a bit more verbose in %files. This helps to avoid adding unwanted 
  files and gives a better overview of the package's content:

  %{_bindir}/ocap
  %{_bindir}/paco*
  %{_bindir}/rpm2paco
  %{_bindir}/superpaco
  %{_libdir}/libpaco-log.so.*
  %{_mandir}/man5/pacorc.5*
  %{_mandir}/man8/*.8*

Comment 6 Susi Lehtola 2011-07-17 12:31:28 UTC
- As has already been stated on fedora-devel, it is generally preferred to delete the files you don't want to ship at the end of %install, instead of excluding them in %files.

- The usual convention is to apply any patches directly after %setup, unless the patches do not operate on pristine source files. Please convert the ChangeLog at the end of the %prep phase, after the patches have been applied.

- It is also advisable to version the patches, e.g.
 Patch0: paco-2.0.9-fix-fsf-address.patch
since often you might have to rebase these, and having a different content of the patch file in different branches (e.g. f14 vs f15) might be confusing.

- You should ship
 %{_libdir}/*.so
 %{_libdir}/pkgconfig
in a -devel package, since these can be used to compile against paco. Or do you have any specific reason why you don't want to ship these?

PS. If you're on IRC, please join #fedora.fi on IRCNet.

Comment 7 Veeti Paananen 2011-07-17 15:33:33 UTC
Hi! Thank you for your comments.

> if you don't plan to maintain the package for EPEL < 6, you can drop all the buildroot stuff (BuildRoot field, %clean section, initial cleaning of the buildroot in %install)

I do plan on maintaining this for EL5 (although I think that would require dropping the GUI subpackage on that branch, since the GTK+ version there is way too old).

> you should ask upstream to properly apply the GPL by adding the text given in  COPYING to the source files

I'll e-mail him about this.

> Giving the full icon path in the .desktop file is fine, but it's recommended to simply use the basename of the icon file

The reason I added the full path to the desktop file was that the basename didn't work for me (the icon didn't show up with the menu entry). I came to the conclusion that the icon should be installed somewhere in the /usr/share/icons tree instead of /usr/share/pixmaps for that to work - please correct me if I'm wrong.

> As has already been stated on fedora-devel, it is generally preferred to delete the files you don't want to ship at the end of %install, instead of excluding them in %files.

Is there any specific advantage/reason/logic for doing this? I've changed the spec to do this, but to me using an "exclude" command in the files section seems more logical (and easier to understand) than just removing those files during %install.

As for the shared library, my understanding is that it's not meant to be used by other applications - it's only designed for internal use by paco to log installations (and that would probably explain the exit calls in the library too). paco doesn't install any header files either. However, I might be missing something here.

In any case, I've fixed all the other stuff you've mentioned. Here's the new spec and SRPM:

SPEC: http://rojekti.fi/files/paco/4/paco.spec
SRPM: http://rojekti.fi/files/paco/4/paco-2.0.9-4.fc15.src.rpm

Changelog:

* Sun Jul 17 2011 Veeti Paananen <veeti.paananen@rojekti.fi> - 2.0.9-4
- Prefixed patch files with package name and version
- Moved build requirements in spec file to the top
- Preserve the changelog file's timestamp when converting to UTF-8
- Removed /usr/share/paco since the same files are already installed elsewhere
- Added faq.txt to documentation
- More verbose file listings
- Moved file exclusions to rm statements in install section
- Moved patch statements to directly after setup

Nothing new in rpmlint.

Comment 8 Veeti Paananen 2011-07-17 15:35:23 UTC
Whoops, I guess those lines were wrapped for a reason. Sorry about the overflowing text.

Comment 9 Susi Lehtola 2011-07-17 18:27:58 UTC
(In reply to comment #7)
> > Giving the full icon path in the .desktop file is fine, but it's recommended to simply use the basename of the icon file
> 
> The reason I added the full path to the desktop file was that the basename
> didn't work for me (the icon didn't show up with the menu entry). I came to the
> conclusion that the icon should be installed somewhere in the /usr/share/icons
> tree instead of /usr/share/pixmaps for that to work - please correct me if I'm
> wrong.

Nope, /usr/share/pixmaps works just fine.

> > As has already been stated on fedora-devel, it is generally preferred to delete the files you don't want to ship at the end of %install, instead of excluding them in %files.
> 
> Is there any specific advantage/reason/logic for doing this? I've changed the
> spec to do this, but to me using an "exclude" command in the files section
> seems more logical (and easier to understand) than just removing those files
> during %install.

%exclude is usually only used, when you want to use wildcards in the %files section of a given (sub)package, but at the same time place a specific file in another subpackage. For instance:

 %files
 %defattr(-,root,root,-)
 %{_bindir}/foo-*
 %exclude %{_bindir}/foo-bar

 %files bar
 %defattr(-,root,root,-)
 %{_bindir}/foo-bar

Freeminded use of %excludes can lead to trouble, since you might end up with files that are not packaged altogether...

> As for the shared library, my understanding is that it's not meant to be used
> by other applications - it's only designed for internal use by paco to log
> installations (and that would probably explain the exit calls in the library
> too). paco doesn't install any header files either. However, I might be missing
> something here.

... but the existence of pkgconfig stuff would lead to think the contrary, would it not?

Please contact upstream to clarify this issue.

Comment 10 Veeti Paananen 2011-07-17 18:51:39 UTC
> Nope, /usr/share/pixmaps works just fine
Well, upstream has already adopted the absolute path after my patch - so I think that we should just keep it this way.

I'll send another e-mail about the library.

Comment 11 Veeti Paananen 2011-07-18 12:21:15 UTC
Some clarification from upstream about licensing and the static library:

> Yes, the intended version for paco is GPLv2.

> libpaco-log is meant to be used only by the paco command line
> executable and not by any other application. I added a pkgconfig file
> just for the configure script to be able to detect any older instance
> of paco on the system. It's a dirty trick, I know, but it doesn't harm
> anything.

Comment 12 Susi Lehtola 2011-07-18 12:40:07 UTC
(In reply to comment #11)
> Some clarification from upstream about licensing and the static library:
> 
> > Yes, the intended version for paco is GPLv2.
> 
> > libpaco-log is meant to be used only by the paco command line
> > executable and not by any other application. I added a pkgconfig file
> > just for the configure script to be able to detect any older instance
> > of paco on the system. It's a dirty trick, I know, but it doesn't harm
> > anything.

... okay. So the install system is broken, the development stuff should not be installed.

**

Please note that you are currently mixing styles, which is not allowed.

http://fedoraproject.org/wiki/Packaging/Guidelines#Using_.25.7Bbuildroot.7D_and_.25.7Boptflags.7D_vs_.24RPM_BUILD_ROOT_and_.24RPM_OPT_FLAGS

**

If you want to get sponsored, you need to demonstrate your knowledge of the Fedora guidelines, most importantly
 http://fedoraproject.org/wiki/Packaging/Guidelines
 http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
In addition to the Packaging Guidelines, there are a bunch of language / application specific guidelines that are linked to in the Packaging Guidelines.

Here are some tricks of the trade:
http://fedoraproject.org/wiki/Packaging_tricks
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets
http://fedoraproject.org/wiki/Common_Rpmlint_issues

I will sponsor you if you have at least one other submission and perform a couple of informal reviews of packages of other people. (Martin might be a willing sponsor as well.)

Please review only packages *not* marked with FE-NEEDSPONSOR, as I will have to do the full formal review after you to check that you have got everything correctly.

Once I have sponsored you you will be able to do formal reviews of your own.

Comment 13 Susi Lehtola 2011-07-18 12:57:23 UTC
I'm not sure whether paco-gui is the best name for the GUI package; I would just name it gpaco. You can do this by specifying
 %package -n gpaco
instead of 
 %package gui
and the thing for %files as well.

**

rpmlint output:
paco.src:23: W: configure-without-libdir-spec
paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit@GLIBC_2.2.5
paco.x86_64: W: no-manual-page-for-binary ocap
paco-gui.x86_64: W: no-documentation
paco-gui.x86_64: W: no-manual-page-for-binary gpaco
4 packages and 0 specfiles checked; 0 errors, 5 warnings.


The configure-without-libdir-spec warning is probably caused by the ./configure in the %description, and is as such erroneus.

Since this is a C++ program, there's no need to call exit, as one can throw exceptions instead. However, this change would need to be done by upstream.

Other warnings are OK.

**

MUST: The package does not yet exist in Fedora. The Review Request is not a duplicate. OK

MUST: The spec file for the package is legible and macros are used consistently. 
 NEEDSWORK
- Macro styles mixed.
- Please remove the unnecessary empty lines in -gui, e.g., the empty line at the start of the %description ends up in the result rpm as well.

MUST: The package must be named according to the Package Naming Guidelines. OK
MUST: The spec file name must match the base package %{name}. OK
MUST: The package must be licensed with a Fedora approved license and meet the  Licensing Guidelines. OK

MUST: The License field in the package spec file must match the actual license. NEEDSWORK
- As stated by Martin above in comment #5, the license is somewhat badly defined.
- gpaco/about.cc defines a GPLv2+ license, so do lib/paco/getopt.h and lib/paco/getopt.cc.
- License tag should reflect the license of the result, which is anyway in this case GPL+ + GPLv2+ = GPLv2+.
- Please change License tag to GPLv2+ and ask upstream to add proper license headers in every source code file.

MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. OK
$ md5sum paco-2.0.9.tar.bz2 ../SOURCES/paco-2.0.9.tar.bz2 
d2debbea1b11156470f7fd849bb93c80  paco-2.0.9.tar.bz2
d2debbea1b11156470f7fd849bb93c80  ../SOURCES/paco-2.0.9.tar.bz2

MUST: The package MUST successfully compile and build into binary rpms. OK
MUST: The spec file MUST handle locales properly. N/A
MUST: Optflags are used and time stamps preserved. OK
MUST: Packages containing shared library files must call ldconfig. OK
MUST: A package must own all directories that it creates or require the package that owns the directory. OK
MUST: Files only listed once in %files listings. OK
MUST: Debuginfo package is complete. OK
MUST: Permissions on files must be set properly. OK
MUST: Large documentation files must go in a -doc subpackage. N/A
MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. OK
MUST: Header files must be in a -devel package. N/A
MUST: Static libraries must be in a -static package. N/A
MUST: If a package contains library files with a suffix then library files ending in .so must go in a -devel package. N/A
MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency. N/A
MUST: Packages does not contain any .la libtool archives. OK
MUST: Desktop files are installed properly. OK
MUST: No file conflicts with other packages and no general names. OK
SHOULD: %{?dist} tag is used in release. OK
SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. OK
SHOULD: The package builds in mock. OK
EPEL: Clean section exists. OK
EPEL: Buildroot cleaned before install. OK
EPEL: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'. N/A

**

This package is in pretty good shape, so you'll just need to do another submission and a couple of informal reviews as instructed in comment #12.

Comment 14 Veeti Paananen 2011-07-18 17:14:48 UTC
New spec and SRPM:

SPEC: http://rojekti.fi/files/paco/5/paco.spec
SRPM: http://rojekti.fi/files/paco/5/paco-2.0.9-5.fc15.src.rpm

Changelog:

* Mon Jul 18 2011 Veeti Paananen <veeti.paananen@rojekti.fi> - 2.0.9-5
- Replaced build root variables with the build root macro
- Renamed GUI subpackage to gpaco after the upstream name
- Changed license to GPLv2+
- Removed empty line in gpaco description

rpmlint:

[veeti@veeti-pc SRPMS]$ rpmlint paco-2.0.9-5.fc15.src.rpm 
paco.src:22: W: configure-without-libdir-spec
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

[veeti@veeti-pc x86_64]$ rpmlint paco-2.0.9-5.fc15.x86_64.rpm gpaco-2.0.9-5.fc15.x86_64.rpm 
paco.x86_64: W: shared-lib-calls-exit /usr/lib64/libpaco-log.so.0.0.0 exit@GLIBC_2.2.5
paco.x86_64: W: no-manual-page-for-binary ocap
gpaco.x86_64: W: spelling-error Summary(en_US) paco -> capo, pace, pact
gpaco.x86_64: W: spelling-error %description -l en_US paco -> capo, pace, pact
gpaco.x86_64: W: no-documentation
gpaco.x86_64: W: no-manual-page-for-binary gpaco
2 packages and 0 specfiles checked; 0 errors, 6 warnings.

----------

I'll check the package wishlist for anything that I would be interested in and look for packages I can comment on. Right now I've left comments on these: bug 713923, bug 714491, bug 714543, bug 714899, bug 716580, bug 717337

Comment 15 Veeti Paananen 2011-07-18 20:53:57 UTC
I've packaged a C++ wrapper library for libcurl called cURLpp and the review request is at bug 723053. I'll try to find some packages that I could informally review more thoroughly than the comments I've left so far.

Comment 16 Veeti Paananen 2011-07-19 12:08:34 UTC
New spec and SRPM:

Spec: http://rojekti.fi/files/paco/6/paco.spec
SRPM: http://rojekti.fi/files/paco/6/paco-2.0.9-6.fc15.src.rpm

Changelog:

* Tue Jul 19 2011 Veeti Paananen <veeti.paananen@rojekti.fi> - 2.0.9-6
- Add default file attributes to gpaco subpackage
- Removed unnecessary recursive flags from rm commands to delete unwanted files

Nothing new in rpmlint.

Comment 17 Veeti Paananen 2011-07-19 15:39:50 UTC
I've made a thorough informal review at bug 722914 (hopefully I did it right!). I'll try to find a couple of more packages to go through later.

Comment 18 Susi Lehtola 2011-07-26 19:20:55 UTC
Since you have also reviewed bug 705319, I have sponsored you in pkgdb.

You seem to have addressed all the issues I raised, so I have to declare this package

APPROVED


Proceed by requesting git branches.
http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure

Comment 19 Veeti Paananen 2011-07-26 20:21:44 UTC
Cool, thanks!

New Package SCM Request
=======================
Package Name: paco
Short Description: A source code package organizer for Unix/Linux
Owners: vpaan
Branches: f14 f15 el5 el6
InitialCC:

Comment 20 Gwyn Ciesla 2011-07-27 10:01:38 UTC
Git done (by process-git-requests).

Comment 21 Veeti Paananen 2011-07-27 12:44:20 UTC
Package Change Request
======================
Package Name: paco
New Branches: f16
Owners: vpaan

Comment 22 Fedora Update System 2011-07-27 12:57:29 UTC
paco-2.0.9-6.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/paco-2.0.9-6.fc15

Comment 23 Fedora Update System 2011-07-27 13:12:37 UTC
paco-2.0.9-6.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/paco-2.0.9-6.fc14

Comment 24 Fedora Update System 2011-07-27 13:30:15 UTC
paco-2.0.9-6.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/paco-2.0.9-6.el6

Comment 25 Gwyn Ciesla 2011-07-27 13:35:18 UTC
Git done (by process-git-requests).

Comment 26 Fedora Update System 2011-07-27 13:55:39 UTC
paco-2.0.9-7.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/paco-2.0.9-7.el5

Comment 27 Fedora Update System 2011-07-27 14:08:07 UTC
paco-2.0.9-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/paco-2.0.9-6.fc16

Comment 28 Fedora Update System 2011-07-30 10:35:01 UTC
paco-2.0.9-7.el5 has been pushed to the Fedora EPEL 5 testing repository.

Comment 29 Fedora Update System 2011-08-09 01:31:06 UTC
paco-2.0.9-6.fc14 has been pushed to the Fedora 14 stable repository.

Comment 30 Fedora Update System 2011-08-09 01:39:53 UTC
paco-2.0.9-6.fc15 has been pushed to the Fedora 15 stable repository.

Comment 31 Fedora Update System 2011-08-16 20:54:38 UTC
paco-2.0.9-6.el6 has been pushed to the Fedora EPEL 6 stable repository.

Comment 32 Fedora Update System 2011-08-16 21:07:13 UTC
paco-2.0.9-7.el5 has been pushed to the Fedora EPEL 5 stable repository.

Comment 33 Fedora Update System 2011-08-22 14:56:06 UTC
paco-2.0.9-6.fc16 has been pushed to the Fedora 16 stable repository.


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