Bug 540761 - Review Request: deja-dup - Simple backup tool and frontend for duplicity
Review Request: deja-dup - Simple backup tool and frontend for duplicity
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-11-23 22:12 EST by Rahul Sundaram
Modified: 2013-03-13 01:46 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-02 04:43:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
mclasen: fedora‑review+
tibbs: fedora‑cvs+

Attachments (Terms of Use)
Deja Dup's SIGSEGV on cold Restore (12.35 KB, text/plain)
2009-12-10 17:52 EST, Michal Nowak
no flags Details

  None (edit)
Description Rahul Sundaram 2009-11-23 22:12:06 EST
Spec URL: http://sundaram.fedorapeople.org/packages/deja-dup.spec
SRPM URL: http://sundaram.fedorapeople.org/packages/deja-dup-11.1-1.fc12.src.rpm

Déjà Dup is a simple backup tool. It hides the complexity of doing backups the 
'right way' (encrypted, off-site, and regular) and uses duplicity as the 

 • Support for local or remote backup locations, including Amazon S3
 • Securely encrypts and compresses your data
 • Incrementally backs up, letting you restore from any particular backup
 • Schedules regular backups
 • Integrates well into your GNOME desktop

Note to reviewers: You need atleast Vala 0.7.6 to rebuild the SRPM. For Fedora 12, the latest Vala is in updates testing repo.
Comment 1 Michael Terry 2009-12-07 20:21:45 EST
Hi, I'm the maintainer of deja-dup and saw this via google alerts.  :)

First, thanks so much for creating the spec!  I've long wanted deja-dup on Fedora.

However, I notice that the spec requires vala, and you comment on needing vala to rebuild the SRPM.  You *shouldn't* need vala to build deja-dup from a tarball.  You *do* need it to build from bzr.  The tarball includes the vala source, but also already includes the generated C code.

If you patch the vala source in the tarball, then you will need valac because the C code will be out of date.  But you can patch the C code instead to avoid that.
Comment 2 Rahul Sundaram 2009-12-07 20:35:58 EST
Ah, I should have contacted you when I put up the review request but forgot about that. Sorry. I was pretty sure I added Vala as a build dependency based on the configure output but looks like I am misremembering something.  Removed vala and updated the spec and SRPM in place. Thanks.
Comment 4 Rahul Sundaram 2009-12-07 20:53:22 EST
Koji scratch build at 

Comment 5 Rahul Sundaram 2009-12-07 21:13:10 EST
Updated to latest upstream release. Added BR on libnotify-devel

Comment 6 Michael Terry 2009-12-07 21:26:37 EST
Note that 13.x is tracking GNOME 2.30 development.  That is, 13.3 is a 'development/unstable' release equivalent to 2.29.3.  You still may want to package it, I just wanted to make that more explicit.

11.1 is still the latest stable release.
Comment 7 Rahul Sundaram 2009-12-07 21:30:03 EST
Yes, I noticed the announcement. Assuming you will release in sync with GNOME 2.30, that release matches Fedora 13 schedule. I can branch the stable release for Fedora 12 if it this review gets approved soon.
Comment 8 Michal Nowak 2009-12-08 04:03:49 EST
Though, shouldn't we generate the C code from Vala, when rebuilding, ourselves? 

Since we don't have Vala-specific policy here, I'd use Fonts Packaging Policy https://fedoraproject.org/wiki/Packaging:FontsPolicy#Building_from_sources where we sometimes have source files for OTF/TTF font files and we should build from them.

I am not an expert on Vala but if maintainer is going to fix a bug in Deja Dup, I guess they fixes it in meta-code (Vala) rather than in code (C) itself.

Just an idea.
Comment 9 Michal Nowak 2009-12-08 04:21:47 EST
newman@dhcp-lab-124 SRPMS $ rpmlint /home/newman/rpmbuild/RPMS/x86_64/deja-dup-13.3-1.fc12.x86_64.rpm /home/newman/rpmbuild/RPMS/x86_64/deja-dup-debuginfo-13.3-1.fc12.x86_64.rpm
deja-dup.x86_64: W: non-conffile-in-etc /etc/gconf/schemas/deja-dup.schemas
deja-dup.x86_64: W: non-conffile-in-etc /etc/xdg/autostart/deja-dup-monitor.desktop

This might be some rpmlint nonsense, I don't expect anyone to edit those two files.

deja-dup.x86_64: W: file-not-in-%lang /usr/share/man/ps/man1/deja-dup-monitor.1.gz
deja-dup.x86_64: W: file-not-in-%lang /usr/share/man/ps/man1/deja-dup-preferences.1.gz
deja-dup.x86_64: W: file-not-in-%lang /usr/share/man/ps/man1/deja-dup.1.gz

What's the purpose of '/ps' here? Can you remove it?
Comment 10 Rahul Sundaram 2009-12-08 04:33:44 EST
The ps thing comes from upstream source. Not sure why. Michael Terry?
Comment 11 Michal Nowak 2009-12-08 04:55:38 EST
Michael/Rahul: Installed the 13.x version and noticed that in "Help" menu there are several items (Get Help..., Translate..., Report...), which on the first sight looks like those Ubuntu-specific items in every GNOME app in Ubuntu. Can this be done more GNOME way w/o those items, just for the sake of unification, please?
Comment 12 Michael Terry 2009-12-08 08:44:05 EST
Regarding 'ps': ps is the language code for Pashto.  Deja Dup has translated man pages.

Regarding Help items: They are inspired by Ubuntu, but are not Ubuntu specific.  The links go to the upstream Deja Dup project page in Launchpad.  You can patch them out if you don't want to look even a little like Ubuntu, but I'd prefer you didn't, as I'd get less translation traffic -- though I don't mind getting fewer bug reports and support requests :).  You may be interested in patching the 'Report a bug' link to point at Fedora's bugzilla, but I don't mind getting bug reports directly.

Regarding vala: Patching vala code is easier to do, but requires a build dependency on vala.  It's a trade-off.  Depends how much you expect to be patching Deja Dup and how difficult you find patching the generated C code to be.  In terms of official upstream tarballs, the C code will always be in sync with the vala code, so you don't have to worry about a fix only being in the vala code.
Comment 13 Rahul Sundaram 2009-12-09 08:02:59 EST
I am not going to be patching help items. It is going to be however upstream puts it. As long as it's functional and serves the purpose, it is good to go. 

Whether we need to be building it from Vala source is a question for the packaging committee. I will post and enquire.
Comment 14 Michal Nowak 2009-12-10 17:52:44 EST
Created attachment 377611 [details]
Deja Dup's SIGSEGV on cold Restore

How to reproduce
1. Build Deja Dup, install, run
2. press Restore (nothing was backed up ever :)
3. Segmentation fault (core dumped)

See the log full report from ABRT.
Comment 15 Michael Terry 2009-12-10 18:02:25 EST
That seems bad...  :-/  I've filed a bug (https://bugs.launchpad.net/deja-dup/+bug/495248) and will look at it this weekend.  Hopefully it's just on the 13.x line.
Comment 16 Michael Terry 2009-12-13 14:05:44 EST
OK, I fixed the crash, but it was caused by the gconf schema not being installed (no default value for a certain key -- /apps/deja-dup/backend).  If you installed from this .spec file, maybe the schema isn't being registered?
Comment 17 Michael Terry 2009-12-15 15:53:04 EST
If you do decide to build from vala source, running 'rm */vala.stamp' should force re-compilation.
Comment 18 Michal Nowak 2009-12-21 06:03:13 EST
* 13.4 is released.
* Any input from packaging committee wrt building from Vala/C?
Comment 19 Rahul Sundaram 2009-12-21 18:29:53 EST


I asked at https://www.redhat.com/archives/fedora-devel-list/2009-December/msg00979.html and while noone from the packaging committee has chimed in, I am inclined to stick with building from C for now. Once we have a better pool of packages in Vala, we would be able to determine the right path forward.
Comment 20 Thomas Spura 2010-01-15 15:00:08 EST
(In reply to comment #19)
> Once we have a better pool of packages in
> Vala, we would be able to determine the right path forward.    

This seems to be a chicken or egg problem.

When you don't build from vala, the pool of packages in vala won't grow.

'When in doubt, build from the source that upstream is going to be modifying,
fixing bugs in directly, etc.'
(quoted from https://www.redhat.com/archives/fedora-devel-list/2009-December/msg01006.html )
should be the right thing.

Or do you have any other update from the packaging committee, I missed atm?
Comment 21 Rahul Sundaram 2010-01-16 17:27:35 EST
"When you don't build from vala, the pool of packages in vala won't grow."

Not the case at all. There are Vala packages which build from the C source instead of the Vala source in Fedora for various reasons including the fact that Vala itself is fairly volatile and depending on the latest Vala compiler is not always feasible. The comments from the list were mixed with no conclusion.  If someone wants to draft up Vala guidelines, it would help and meanwhile I will appreciate a review of the package.
Comment 22 Gendre Sébastien 2010-02-06 15:51:27 EST
So we haven't Déjà-Dup if we haven't Vala?
Comment 23 Rahul Sundaram 2010-02-06 23:24:36 EST
As a user you would not need Vala to run Vala program because it is compiled into a native executable and there is no VM
Comment 24 Matthias Clasen 2010-02-20 23:24:45 EST
any update on this ?
Comment 25 Rahul Sundaram 2010-02-21 13:12:57 EST
Still waiting for a review
Comment 26 Matthias Clasen 2010-02-23 19:47:42 EST
Tried to build it in mock. Missing BuildRequires: scrollkeeper.
After adding that, it builds ok.

rpmlint results:
$ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/deja-dup-13.4-1.fc14.x86_64.rpm 
deja-dup.x86_64: W: spelling-error Summary(en_US) frontend -> fronted, front end, front-end
deja-dup.x86_64: W: spelling-error %description -l en_US Déjà 
deja-dup.x86_64: W: spelling-error %description -l en_US backend -> backed, back end, back-end
deja-dup.x86_64: W: non-conffile-in-etc /etc/gconf/schemas/deja-dup.schemas
deja-dup.x86_64: W: non-conffile-in-etc /etc/xdg/autostart/deja-dup-monitor.desktop
deja-dup.x86_64: W: file-not-in-%lang /usr/share/man/ps/man1/deja-dup-monitor.1.gz
deja-dup.x86_64: W: file-not-in-%lang /usr/share/man/ps/man1/deja-dup-preferences.1.gz
deja-dup.x86_64: W: file-not-in-%lang /usr/share/man/ps/man1/deja-dup.1.gz
1 packages and 0 specfiles checked; 0 errors, 8 warnings.

The spelling warnings are silly.
The non-conffile warnings are common practice for gconf schemas and autostart files.
The file-not-in-%lang warnings should be fixed. You can probably use
%find-lang --with-man for that.
Comment 27 Matthias Clasen 2010-02-23 20:42:37 EST
package name: ok
spec file name: ok
packaging guidelines: there is an instance of // in the file list somewhere. for the rest, see the individual points below
license: ok
license field: ok
license file: ok
spec file language: ok
readable: ok
upstream source: the source url seems wrong, http://launchpad.net/deja-dup/14/13.4/+download/deja-dup-13.4.tar.bz2 is the correct url for 13.4. The tarball is identical to the upstream one. The latest version is 13.91.
buildable: yes, see  above
ExcludeArch: ok
BuildRequires: scrollkeeper is missing, see above
locale handling: ok, but see above about --with-man and you might also want to look into using --with-gnome to get language tags for omf and help files
ldconfig: ok
system libraries: ok
relocatable: no, ok
directory ownership: problematic directories:
  /etc/gconf/schemas (owned by GConf2)
  /usr/lib/nautilus/extensions-2.0 (owned by nautilus)
  /usr/share/gnome/help (owned by yelp)
  /usr/share/icons/Humanity (owned by nothing ?)
Library deps are covering gconf and nautilus, but you should probably add a dep for yelp, and drop the Humanity icon, since we don't have the Humanity icon theme in Fedora anyway
duplicate files: ok
file permissions: ok
%clean: ok
macro use: ok
content: permissible
large docs: ok
%doc content: ok
headers: ok
static libs: ok
pc files: ok
shared libs: ok
devel deps: ok
libtool archives: ok
gui apps: ok
%install: needs to wipe the buildroot initially
utf8 filenames: ok
Comment 28 Rahul Sundaram 2010-03-01 06:47:04 EST

not sure what to do about:

"deja-dup.i686: W: file-not-in-%lang /usr/share/man/ps/man1/deja-dup-monitor.1.gz
deja-dup.i686: W: file-not-in-%lang /usr/share/man/ps/man1/deja-dup-preferences.1.gz"

"%install: needs to wipe the buildroot initially"  

Not required anymore  Refer to  

Comment 29 Matthias Clasen 2010-03-01 09:34:56 EST
> not sure what to do about:

Just remove the man pages from the explicit file list. Since you added --with-man to the %find_lang invocation, the .lang file already has those (with annotations now):

%lang(en) /usr/share/man/en_GB/man1/deja-dup.1*
%lang(ps) /usr/share/man/ps/man1/deja-dup.1*
%lang(sv) /usr/share/man/sv/man1/deja-dup.1*

Although it looks as though it doesn't pick up the deja-dup-preferences man page.
For that, you need to add --all-name to the %find_lang call.

> Not required anymore

I didn't know that ! That is good. Should get updated in the review guidelines...

upstream source: fine now
BuildRequires: fine now
%install: ok

Please try to work out the %lang issue, but I don't think that needs to block the review. APPROVED
Comment 30 Rahul Sundaram 2010-03-01 12:04:37 EST
New Package CVS Request
Package Name:  deja-dup 
Short Description: Simple backup tool and frontend for duplicity 
Owners: sundaram
Branches: F-12 F-13 
Comment 31 Jason Tibbitts 2010-03-01 21:14:00 EST
CVS done (by process-cvs-requests.py).
Comment 32 Michael Terry 2010-03-02 06:39:09 EST
Thank you Rahul and Matthias!

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