New upstream release 0.11.2

FFe granted, please go ahead.

Please sponsor

Jean-Peer, this package really isn't in great shape:
* It's not necessary to depend on python << 3. python3 is a separate stack.
* There is a newer standards-version 3.9.1
* You should probably remove the dh-make comments from the top of debian/rules (even lintian complains about them)
* Is all the UbuntuVersion detection really necessary? This package is for maverick.
* The install files could probably be a lot simpler with more wildcards, but the version you have obviously works (as long as you remember to add new files to it)
* It's not necessary to update-icon-cache for hicolor, it uses a dpkg trigger
* You shouldn't need to call compileall or clean up .pyc files, python-support has support for private modules
* Deleting files from users home directories in postrm is bad.

Thanks a lot for your review. Valuable comments since I'm not very experienced with packaging and re-used the sources that former maintainers created.

>* It's not necessary to depend on python << 3. python3 is a separate stack.
Ok.

>* There is a newer standards-version 3.9.1
Ok (I've prepared the package on Lucid).

>* You should probably remove the dh-make comments from the top of debian/rules (even lintian complains about them)
Ok.

>* Is all the UbuntuVersion detection really necessary? This package is for maverick.
I use this set of debian files for building PPA packages for several distributions, so it's convenient. But I could remove it for this specific build in case it'd be prefered.

>* The install files could probably be a lot simpler with more wildcards, but the version you have obviously works (as long as you remember to add new files to it)
Yes, I know but I didn't wanted to modify them before a (final) release.

>* It's not necessary to update-icon-cache for hicolor, it uses a dpkg trigger
Ok.

>* You shouldn't need to call compileall or clean up .pyc files, python-support has support for private modules
We don't use python-support. I've played around with it but didn't succeed. Line 'dh_pysupport' is commented. I've investigated the thing and pyc-files are not created when using python-setuptools (AFAIK). More precise, they are created within the build tree but not copied (since not specified in install files) into the package. Should I add the according pyc files to the install files?

>* Deleting files from users home directories in postrm is bad.
Agree. However, we're writing configuration files into XDG directories (here ~/.config/sbackup). Should we really leave them when the package is purged?

What next? Should I incorporate your suggestions and attach an updated tarball and dsc file?

> I use this set of debian files for building PPA packages for several distributions, so it's convenient. But I could remove it for this specific build in case it'd be prefered.

OK. So, it's a potential issue because it hardcodes version numbers, what about natty, for example? That is only because the version of python in hardy doesn't support --install-layout. I'd drop it from here, yes.

> We don't use python-support.

That would be another issue I missed :) (I never actually got as far as building it, only reading the debdiff). Please use a python helper like python-support. It's correct to not have .pyc files in the deb.

> Should we really leave them when the package is purged?

Yes. You never touch user's home directories from maintainer scripts. And never assume that they'll be /home/$username

> Should I incorporate your suggestions and attach an updated tarball and dsc file?

That would be good, yes please.

"Jean-Peer Lorenz" <email address hidden> wrote:
>>* You shouldn't need to call compileall or clean up .pyc files, python-support has support for private modules
>We don't use python-support. I've played around with it but didn't succeed. Line 'dh_pysupport' is commented. I've investigated the thing and pyc-files are not created when using python-setuptools (AFAIK). More precise, they are created within the build tree but not copied (since not specified in install files) into the package. Should I add the according pyc files to the install files?
>
You may not ship. pyc files in the package. If you are not using one of the Python helpers (python-support, python-central, or dh_python2) the odds of getting it right are very low.

Please review!

In the meantime I've fixed two more bugs upstream and revamped the whole packaging. Should be in better shape now:
* use 0.11.1 instead of 0.11.0 as base; it fixes two more important bugs
* standards version set to latest 3.9.1
* drop dependecies on python << 3.0 and setuptools
* clean up of Makefile and rules file
* proper use of distutils and dh_pysupport
* installation of private python package instead of public one
* drop distribution detection (no longer required)
* don't byte compile python modules manually
* don't call update icon cache for hicolor
* don't touch user's home directories from Makefile nor maintainer scripts
* simplifications of install files (more wildcards)
* removed maintainer scripts that are no longer required.

Please sponsor

Hi, sorry I haven't had much time available for Ubuntu in the last couple of weeks (pyweek got me)

In general, when you want to get the attention of sponsors again, you should resubscribe ubuntu-sponsors. However, given the size of the sponsor queue when I looked at it this weekend, I don't think there's been much universe sponsorship while I was away.

This package looks much better, thanks. I only have a few issues with it (from a quick skim):
1. The changelog in the proposed version rewrites history. Please base your changelog on the current version in maverick. BTW the format used with "LP #XXXX. $message" won't result in automatically closing bugs. You need to do "LP: #XXXX"
2. The package conflicts on packages not available in Ubuntu (nssbackup)
3. The maintainer scripts should allow invoke-rc.d and service to fail (adding "|| true" at the end of the command is a common solution).
4. sbackup-gtk needs to depend on libgtk2.0-bin because it calls gtk-update-icon-cache in postinst (or it needs to allow those calls to fail)

I'll modify the package to comply with your notes for points 1, 3, 4.

> 2. The package conflicts on packages not available in Ubuntu (nssbackup)
The Simple Backup solution was forked and developed as (Not so) Simple Backup meanwhile. There is a PPA where packages for nssbackup are provided. Version 0.11 re-merges both branches. Therefore, I'd like to keep the conflict with nssbackup. It is obsolete now and sbackup 0.11 replaces older sbackup versions as well as older nssbackup versions.

OK, ignore point 2.

Waiting on your debdiff.

(err, it's a new version so probably a tarball not a debdiff)

Please sponsor.

Here are updated uploads:
* upstream changelog
* build log (please ignore that the log refers to version ..ubuntu2)
* dsc file
* and tarball

I've modified maintainer scripts etc. according to your review. Moreover, I've fixed some bugs upstream and bumped the version numbering to 0.11.2 in the meantime.

This bug was fixed in the package sbackup - 0.11.2ubuntu1

---------------
sbackup (0.11.2ubuntu1) maverick; urgency=low

  * New upstream release. LP: #620384
  * [Fix] LP: #638072 Exclude rules not working on some dirs
  * [Fix] LP: #634356 Exception on reading snapshots in restore ui
  * [Fix] LP: #634031 Default behavior incorrectly set to `Cancel` instead
                      of `Retry`
  * [Fix] LP: #632605 catch error while closing snapshot file over FTP
  * [Fix] LP: #642087 Log. purge not working under certain circumstances
  * Workaround for LP #640034 Setting status to attention does not change
                              to specified icon (indicator-application)
  * Fix: don't block restore gui on long running tasks
  * Fix: don't touch snapshots being upgraded from backup process

sbackup (0.11.1ubuntu1) UNRELEASED; urgency=low

  * [Fix] LP: #587911 Logarithmic purge does not work
  * [Fix] LP: #622095 catch error when listing directory contents fails
  * [Fix]: revamped packaging: use distutils and pysupport

sbackup (0.11.0ubuntu1) UNRELEASED; urgency=low

  * [Fix] LP: #618730 Merge sbackup and nssbackup (see enclosed file
                      nssbackup.ChangeLog for further information)
  * [Fix] LP: #604558 'abort backup' on exernal drives not possible
  * [Fix] LP: #412934 sbackup/nssbackup fails if exclude-path contains an
                      equal-sign
  * [Fix] LP: #277137 crashed with NoSpaceError: No space left on device
  * [Fix] LP: #328902 Spelling and wording errors
  * [Fix] LP: #130856 Show remaining time till backup is finished in UI
  * [Fix] LP: #267759 Simple Backup should display a progress bar
  * [Fix] LP: #137293 empty dialog when restoring with sbackup
  * [Fix] LP: #176838 Incremental backups should not appear incremental when
                      restoring
  * [Fix] LP: #254464 Password for SSH Do Not URI Encode
  * [Fix] LP: #489107 sbackup crahses: stop_if_no_target is not an option in
                      general
  * [Fix] LP: #504990 Mb used instead of MB in the application dialogs
  * [Fix] LP: #507175 libgnomevfs2-extra required for FTP backups
  * [Fix] LP: #310306 Error: no space left
  * [Fix] LP: #383383 restore crashes when the destination path or file is non
                      existent
  * [Fix] LP: #331551 Wrong original English text in sbackup po-file
  * [Fix] LP: #585769 default backup directory doesn't exist in ubuntu
  * translations updated
 -- Jean-Peer Lorenz <email address hidden> Sat, 18 Sep 2010 18:44:57 +0200