Bug 676187 - (csync2) Review Request: csync2 - Cluster sync tool
Review Request: csync2 - Cluster sync tool
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ian Weller
Fedora Extras Quality Assurance
:
: 223633 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-08 20:28 EST by Angus Salkeld
Modified: 2014-01-12 20:40 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-16 04:49:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
ian: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Angus Salkeld 2011-02-08 20:28:58 EST
Description:
Csync2 is a cluster synchronization tool. It can be used to keep files on 
multiple hosts in a cluster in sync. Csync2 can handle complex setups with 
much more than just 2 hosts, handle file deletions and can detect conflicts.
It is expedient for HA-clusters, HPC-clusters, COWs and server farms.

SPEC: http://asalkeld.fedorapeople.org/csync2.spec
SRPM: http://asalkeld.fedorapeople.org/csync2-1.34-1.fc14.src.rpm
koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2799170

Other reviews:
https://bugzilla.redhat.com/show_bug.cgi?id=668243
https://bugzilla.redhat.com/show_bug.cgi?id=675947

$ rpmlint csync2
csync2.x86_64: W: non-conffile-in-etc /etc/csync2_ssl_cert.pem
csync2.x86_64: W: non-conffile-in-etc /etc/csync2_ssl_key.pem

If we _really_ need this fixed then I'll need to patch the code
to read then from their new location.

csync2.x86_64: W: no-manual-page-for-binary csync2-compare

Upstream does not provide a man page for this utility

1 packages and 0 specfiles checked; 0 errors, 3 warnings.
Comment 1 Angus Salkeld 2011-02-09 22:15:07 EST
builds on ppc: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=129364
Comment 3 Ian Weller 2011-02-11 15:13:09 EST
(In reply to comment #2)
> Please fix your 'Review Summary' field.

Did this for you.

I'll review this package as a part of your sponsorship.
Comment 4 Ian Weller 2011-02-11 15:45:54 EST
Line 33: You create and install to /etc/xinetd.d. You shouldn't be creating
this directory; add xinetd to your BuildRequires instead.

[  OK  ] specfiles match:
  5f5579ec396913a6070e57002f61d02ed407cf81  csync2.spec
  5f5579ec396913a6070e57002f61d02ed407cf81  csync2.spec.1
[  OK  ] source files match upstream:
  59b95388d378b659d64d17f7b736068dec7bf7ed  csync2-1.34.tar.gz
  59b95388d378b659d64d17f7b736068dec7bf7ed  csync2-1.34.tar.gz.1
[  OK  ] package meets naming and versioning guidelines.
[  OK  ] spec is properly named, cleanly written, and uses macros consistently.
[  OK  ] dist tag is present.
[  OK  ] build root is correct.
[  OK  ] license field matches the actual license.
[  OK  ] license is open source-compatible.
[  OK  ] license text included in package.
[  OK  ] latest version is being packaged.
[FAILED] BuildRequires are proper.
  See the above message regarding line 33. Otherwise, the build logs from Koji 
  look solid.
[  OK  ] compiler flags are appropriate.
[  OK  ] %clean is present. 
[  OK  ] package builds in mock.
[  OK  ] package installs properly.
[  OK  ] debuginfo package looks complete.
[      ] rpmlint is silent.
  Obviously, yeah, the no-manual-page-for-binary warning is just a warning.
       
  On the other hand, I feel like the PEM files would be better put somewhere in 
  /var/lib, unless the files are meant to be user-configurable. Could you
  explain more about what these files are used for in the context of this
  application? 
  
  What seems most likely is that you'll have to either move them out of /etc,
  or tag them as %config(noreplace). 
[FAILED] final provides and requires are sane
  There is no reason to list openssl and sqlite2, as RPM automatically adds the
  appropriate library requirements. Keep xinetd in there, though.
[  N/A ] %check is present and all tests pass:
[  OK  ] no shared libraries are added to the regular linker search paths.
[  OK  ] owns the directories it creates. 
[  OK  ] doesn't own any directories it shouldn't.
[  OK  ] no duplicates in %files.
[  OK  ] file permissions are appropriate.
[FAILED] scriptlets match those on ScriptletSnippets page.
  NEVER change /etc/services. This is especially not OK because it's difficult
  to automatically remove this line after the package is uninstalled.
[  OK  ] code, not content.
[  OK  ] documentation is small, so no -docs subpackage is necessary.
[  OK  ] %docs are not necessary for the proper functioning of the package.
[  OK  ] no headers.
[  OK  ] no pkgconfig files.
[  OK  ] no libtool .la droppings.
[  N/A ] desktop files valid and installed properly.
Comment 5 Angus Salkeld 2011-02-12 22:57:29 EST
Thanks for the review, I have sorted everything except the pem files.
I need to do a bit of research to how best to approach it.
Comment 6 Angus Salkeld 2011-02-13 19:28:56 EST
OK, I will remove the pem files as this is a step that needs to be done by the user (http://oss.linbit.com/csync2/paper.pdf).
Comment 7 Angus Salkeld 2011-02-13 19:52:50 EST
(In reply to comment #4)
> Line 33: You create and install to /etc/xinetd.d. You shouldn't be creating
> this directory; add xinetd to your BuildRequires instead.

Well we need this as 2 lines up we: rm -rf $RPM_BUILD_ROOT
So even if I add BuildRequires: xinetd it gets "cleaned up".
Comment 9 William Lima 2011-02-14 11:00:15 EST
(In reply to comment #6)
> OK, I will remove the pem files as this is a step that needs to be done by the
> user (http://oss.linbit.com/csync2/paper.pdf).

According to http://oss.linbit.com/csync2/ site:

The csync2 releases also have a copy of the 'paper.pdf' file
(and the TeX source) bundled in the csync2 source tarball.

I suggest you to include this file on %doc.

BuildRequires on openssl is also useless since you don't call "make cert".
BuildRequires on xinetd looks the same. Keep the Requires only.

###
make %{?_smp_mflags} all
###

This is the default target for makefiles. There is no need to call "all" target.
Comment 10 Ian Weller 2011-02-14 11:13:09 EST
(In reply to comment #9)
> BuildRequires on xinetd looks the same. Keep the Requires only.

Agreed, sorry I had you add this when it wasn't necessary (had a slip of what the heck RPM did) :)

> ###
> make %{?_smp_mflags} all
> ###
> 
> This is the default target for makefiles. There is no need to call "all"
> target.

Not that this matters too much, but it's important to note that "all" is *not necessarily* the default target for Makefiles; it is simply the *first* target that is the default. (It just so happens that all is the first one here.)
Comment 11 Ian Weller 2011-02-14 13:52:48 EST
Just did one last look, the only issue is the BuildRequires that William mentioned, so

----------------------------------------------
 This package csync2 is APPROVED by ianweller
----------------------------------------------

and we'll just go on faith that you'll fix the BuildRequires section and bump the release before you check it into the VCS.

Let's go finish that last package and get you sponsored.
Comment 12 Angus Salkeld 2011-02-14 15:13:11 EST
Thank you!

I'll sort that BuildRequires out and add the paper.pdf to doc.

-Angus
Comment 13 Angus Salkeld 2011-02-14 17:11:19 EST
New Package SCM Request
=======================
Package Name: csync2
Short Description: Csync2 is a cluster synchronization tool.
Owners: asalkeld
Branches: f15
InitialCC:
Comment 14 Jason Tibbitts 2011-02-15 14:28:56 EST
This package already exists in the package database.  Could you elaborate on what you are asking the SCM admins to do?
Comment 15 Jason Tibbitts 2011-02-15 14:30:23 EST
*** Bug 223633 has been marked as a duplicate of this bug. ***
Comment 16 Angus Salkeld 2011-02-15 17:45:00 EST
Well I thought this package needed packaging (it was on the package 
wish list and not in f14).

But I see it is in the package database - oops.
It is "orphaned" - does that mean it needs a maintainer? If so
I could take it over.

Jason can you add a f15 branch?
How do I can take ownership of this?
Comment 17 Jason Tibbitts 2011-02-17 10:01:05 EST
The package was simply orphaned (at least, I think it was), so all you needed to do was log into the package database and claim the package by clicking the "Take Ownership" button.

I went ahead and made you the owner and created an f15 branch for you.  The package also has orphaned EPEL branches which I have not touched.  You are welcome to keep them that way if you do not wish to maintain the package for EPEL.
Comment 18 Angus Salkeld 2011-09-14 19:19:32 EDT
Package Change Request
======================
Package Name: libqb
New Branches: f15 f16
Owners: asalkeld

I know f15 is in https://admin.fedoraproject.org/pkgdb/acls/name/csync2
but it is not in git for some reason.

Thanks
Angus
Comment 19 Jon Ciesla 2011-09-15 09:28:25 EDT
Should be better now.
Comment 20 Angus Salkeld 2011-09-15 19:08:07 EDT
(In reply to comment #19)
> Should be better now.

Thanks, that adds f15, but what about f16?

"New Branches: f15 f16"

Thanks
Angus
Comment 21 Angus Salkeld 2011-09-15 21:17:07 EDT
Package Change Request
======================
Package Name: libqb
New Branches: f14 f16
Owners: asalkeld

Can I update this to include f14?

A user is asking for it, still a couple of months til EOL
https://bugzilla.redhat.com/show_bug.cgi?id=738158
Comment 22 Jon Ciesla 2011-09-15 21:21:33 EDT
Git done (by process-git-requests).
Comment 23 Jon Ciesla 2011-09-15 21:22:20 EDT
f16 already existed, f14 is there now.
Comment 24 Angus Salkeld 2011-09-15 22:07:07 EDT
(In reply to comment #23)
> f16 already existed, f14 is there now.

groan - I am an idiot. Sorry for wasting you time.

I have copied the package request from another package I maintain "libqb"
No harm done I'll build libqb for f14/f15.

But what I am really after is (csync2):

Package Change Request
======================
Package Name: csync2
New Branches: f14 f16
Owners: asalkeld

-Angus
Comment 25 Angus Salkeld 2011-09-18 08:43:17 EDT
Can the csync2 package be updated please?

See #24 above.

Thanks
Angus
Comment 26 Jon Ciesla 2011-09-18 21:41:06 EDT
Git done (by process-git-requests).

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