Bug 540761

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.

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.

Also FYI,

https://www.redhat.com/archives/fedora-desktop-list/2009-December/msg00005.html

Koji scratch build at 

http://koji.fedoraproject.org/koji/taskinfo?taskID=1861894

Updated to latest upstream release. Added BR on libnotify-devel

http://sundaram.fedorapeople.org/packages/deja-dup.spec
http://sundaram.fedorapeople.org/packages/deja-dup-13.3-1.fc12.src.rpm

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.

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.

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.

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?

The ps thing comes from upstream source. Not sure why. Michael Terry?

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?

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.

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.

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.

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.

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?

If you do decide to build from vala source, running 'rm */vala.stamp' should force re-compilation.

* 13.4 is released.
* Any input from packaging committee wrt building from Vala/C?

Updated 

http://sundaram.fedorapeople.org/packages/deja-dup.spec
http://sundaram.fedorapeople.org/packages/deja-dup-13.4-1.fc13.src.rpm

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.

(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?

"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.

So we haven't Déjà-Dup if we haven't Vala?

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

any update on this ?

Still waiting for a review

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.

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

http://sundaram.fedorapeople.org/packages/deja-dup.spec
http://sundaram.fedorapeople.org/packages/deja-dup-13.91-1.fc12.src.rpm

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  

http://fedoraproject.org/wiki/Packaging/Guidelines#Prepping_BuildRoot_For_.25install

> 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

New Package CVS Request
=======================
Package Name:  deja-dup 
Short Description: Simple backup tool and frontend for duplicity 
Owners: sundaram
Branches: F-12 F-13 
InitialCC:

CVS done (by process-cvs-requests.py).

Thank you Rahul and Matthias!