Bug 168690

* rpmlint clean on src.rpm and resulting noarch rpm
* package name appropriate
* acceptable license
* Spec file clean and easy to understand
* consistant use of macros
* package owns directory and all files it installs
* -- uninstalls cleany after use
* desktop file clean, matches spec
* md5sum matches upstream
* file list sane, file permissions sane
* proper use of macros
* proper use of ghost

* Builds clean in mock, tested on PPC with removable media, succesfully backed
up files, succesfully backed up files after modification, succesfully restored
files after backup.

Only thing I would suggest changing (non blocking) -

1) change
Source: http://stuff

to

Source0: http://stuff

2) Put an empty line between %build and %install sections (for readability)

APPROVED

Dave,
Have you been sponsored for fedora extras cvs access?

My understanding is this is your first package submission so its not clear to me
if you have cvs import access yet

-jef

Jef,

No, I've not yet been sponsored. I'm currently awaiting a sponsor so I can be
added to the cvsextras group and hence import pyBackPack to CVS.

--Dave

I get the following traceback when trying to start pyBackPack:

Traceback (most recent call last):
  File "/usr/bin/pybackpack", line 3, in ?
    gui.StartUp()
  File "/usr/lib/python2.4/site-packages/pybackpack/gui.py", line 1273, in StartUp
    widgets = BackupTool()
  File "/usr/lib/python2.4/site-packages/pybackpack/gui.py", line 1234, in __init__
    self['filechooserwidget1'].get_children()[0].get_children()[1].\
IndexError: list index out of range

Running python-2.4.1-14.  Any ideas ?

Some advice for Dave:

Candidates are to be judged on their knowledge and understanding of the
PackageNamingGuidelines, PackagingGuidelines, and other project process and
specifications.  If sponsors are not yet convinced after having an approved
package, is helpful for candidates to further participate by helping to review
packages submitted by other contributors in order to further prove skills and
knowledge to the sponsors.  There is probably no better way to demonstrate a
grasp of the guidelines than by giving beneficial advice to other package review
requests.

It is a judgement call by the sponsors exactly how much work it takes to prove
this understanding.  If a single package approval didn't convince anyone, simply
sitting and waiting will not convince them either.

This needs to get changed to NEW again.
The packager was not a contributor and per
http://fedoraproject.org/wiki/Extras/Contributors #7 - I should not have
assigned the bug to me.

Hey Dave. Hopefully you are still out there. ;) 

I also get the traceback that Luke reported in comment #4. 
I'd be happy to work with you to track it down and fix it. 

Also, I'd consider sponsoring you, but as Warren mentioned in comment #5, the 
best way for sponsors to see that you understand the guidelines is to see 
comments from you on other packages that are in review. I currently don't see
any comments out there from you. You can find a list of packages in NEW or REVIEW 
state at: 

https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEW&hide_resolved=1

https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-REVIEW&hide_resolved=1

Dave,

I just saw on fedora-devel that you're alive again a plan working on this this
summer again, or am I mixing Dave's now? Anyways if your still alive some sign
of live would be nice. A solution for the traceback problem would be even better :)

Hans,

You've got the right Dave. I just rolled out version 0.4.2 this morning. It
fixes the traceback crashing problem, and so should make all 2 of the pyBackPack
users out there happy :)
I'm looking forward to applying to work on this again over the summer, and will
of course give as much help and support as I can to anyone who beats me to the
punch.

Does working on this again include creating a package for FE? Ifso could you
post a link to a spec + srpm for 0.4.2 here? Then I can start a review for you
and if al goes well sponsor you.

Spec: http://minus-zero.org/projects/pybackpack/pybackpack.spec
SRPM: http://minus-zero.org/projects/pybackpack/pybackpack-0.4.2-1.src.rpm

That was quick, before I start doing a full review, one very important question
 remains: As I've understood you've written pybackpack yourself for google's
summer of code last summer and then sorta went under the radar, assuming I've
understood this correctly, what are the chances of you dropping under the radar
again in the future?

I think its great you want to create and maintain an FE package of your
software, but "we" expect a certain amound of responsivenes / reachability from
contributers. We don't want users and other contributers to get frustrated by a
(total) lack of response / communication. We're all volunteers so I'm not asking
for 24 hour max respnse time, and a response could be: "sorry real busy with
real life right now I'll look at this next month, if you hear nothing within 6
weeks poke me"

Please don't take this the wrong way, but before I sponsor someone especially my
first someone, I would like some assurance (a promise will do) that you won't
"disappear" (again). OTOH I might have misunderstood the history surrounding
this, again in that case please don't take this wrong :)

This seems to be redundant:

%attr(755,root,root) %{python_sitearch}/pybackpack/gui.py
%attr(755,root,root) %{python_sitearch}/pybackpack/findfiles.py
%attr(755,root,root) %{python_sitearch}/pybackpack/rdiff_interface.py
%{python_sitearch}/pybackpack/*.py

and causes these warnings:
warning: File listed twice: /usr/lib/python2.4/site-packages/pybackpack/findfiles.py
warning: File listed twice: /usr/lib/python2.4/site-packages/pybackpack/gui.py
warning: File listed twice:
/usr/lib/python2.4/site-packages/pybackpack/rdiff_interface.py

when building the rpm.

Bernard: A similar issue occurs with my Scribes packaging. If it helps, I've
worked around that by using a simple `chmod +x` in %install, thus not needing to
specify the %attr for these in the %files section; and the glob can take care of
it all. :)

There also seems to be a serious issue with recursively following symbolic links:

$ mkdir testdir
$ cd testdir && ln -sf / root

create a backup set using only testdir, and attemp to backup.

Observe strace output:
stat64("/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/svn/tacomis/tags/v_1-8-1/demo/.svn/empty-file",
{st_mode=S_IFREG|0444, st_size=0, ...}) = 0
access("/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/testdir/root/home/bjohnson/svn/tacomis/tags/v_1-8-1/demo/.svn/empty-file",
R_OK) = 0

The result is the gui hangs and eats cpu while it tries to resolve this link.

I didn't apply for SoC 2006 and nobody has picked up pyBackPack's development -
consider it dead.

Ok, closing as wontfix.

Just for the record, I've taken pybackpack off Dave's hands and have started
development of it again. I'm not overly familiar with Fedora's package process
and I'll be doing my development mainly on Ubuntu but I'd just like to reverse
Dave's "consider it dead" comment and reassure you that the package is still
alive and kicking. Thanks.

Great.  If you can fix the bug in comment #15, I'll continue to help test.

Bernard, the bug in comment #15 has now been fixed in svn. pybackpack now backs
up symlinks but doesn't follow them.

I'll be making a minor release this week with other changes such as updated
calls for the changed nautilusburn API which should make it stop crashing in FC6.

I have bugs to report, but your ticketing system is not open for tickets
("TICKET_CREATE privileges are required to perform this operation").

Sorry about that, i closed it to avoid spam (sigh) and then had trouble
installing a user accounts module so for the moment you can log in as
guest/guest to file a ticket. I should probably have documented this more
obviously. I look forward to reading your bugs.

More progress - fixed some more nasty bugs and ended up making two minor
releases this weekend. The latest of which is 0.4.4. I tried my hand at building
an RPM too, for your convenience:

Spec: http://andrewprice.me.uk/projects/pybackpack/download/pybackpack.spec
SRPM:
http://andrewprice.me.uk/projects/pybackpack/download/pybackpack-0.4.4-1.src.rpm
RPM:
http://andrewprice.me.uk/projects/pybackpack/download/pybackpack-0.4.4-1.noarch.rpm

Hope I packaged it correctly. I ran rpmlint over the resulting files and it said
nothing anyway. Feedback much appreciated.

Bernard, if you want to avoid the hassle of filing those bugs you're welcome to
email them to me and I'll deal with them. Thanks all.

I filed these bugs in some brief testing I did:

http://projects.sucs.org/projects/pybackpack/ticket/35
http://projects.sucs.org/projects/pybackpack/ticket/36
http://projects.sucs.org/projects/pybackpack/ticket/37
http://projects.sucs.org/projects/pybackpack/ticket/38

#36 would be considered a blocker because pybackpack is not useful until this
one is addressed.

I agree that #36 is a big problem. It was introduced when I fixed the infinite
loop with symlinks bug and I think it might be due to files being stat-ed too
much but I won't know for sure until I investigate further, which will occur
after I've sorted out a handful of university deadlines and Christmas-related
business.

Bernard: Thanks for your testing work. It's very much appreciated.

As mentioned on comment #22 my bug tracker now has support for proper user
accounts. Hopefully some of the noise I'm generating on this bugzilla can be
transferred over there now. See http://projects.sucs.org/projects/pybackpack/

Thanks

I've just released pybackpack 0.4.5 which fixes bugs #35, #36 and #37 mentioned
above. There is still some performance to tweak out of the initial file analysis
walk but this should be a very big improvement on the 10 hour duration Bernard
was reporting.

Spec: http://andrewprice.me.uk/projects/pybackpack/download/pybackpack.spec
SRPM:
http://andrewprice.me.uk/projects/pybackpack/download/pybackpack-0.4.5-1.src.rpm
RPM:
http://andrewprice.me.uk/projects/pybackpack/download/pybackpack-0.4.5-1.noarch.rpm

Your feedback is much appreciated. Thanks.

I am not able to access any of these links above. Shouldnt this review reopened
or a new review submitted as per comment #18?

Sorry about that Rahul, my university's network (which my website lies behind)
has been inaccessible all weekend and it's still dropping packets. Hopefully
it'll get fixed soon.

Re: the review - let me know if I do need to open it or a new one. Cheers.

If you have a problem with hosting, you can get someone in #fedora-extras
channel to temporarily provide you with a anonymous host. You can upload it to
fedoraproject.org wiki too. Otherwise mail me the packages and spec files and I
will host them till you get past the review. I dont want good packages struck in
review just because of this.

Yes, Please open a new review and mark this one as a duplicate of the new one.
It helps in our tracking process since we are going through a major revamp of
infrastructure and repository merges within Fedora. Thanks. 

I've opened a new review request at bug 221884. I can't see a way to mark this
one as a duplicate though.

You need to apply for fedorabugs group access in the Fedora Account system to be
able to change bug status.

http://fedoraproject.org/wiki/Infrastructure/AccountSystem

I have done it for you now. I was able to access the spec file and packages now
in the new review you have submitted so I believe that your hosting problems are
solved but if you need help, feel free to drop me a mail anytime. 

*** This bug has been marked as a duplicate of 221884 ***