Re: Bug#758013: s3ql autopkg test regression

2014-08-20 Thread Matthias Klose
Am 20.08.2014 um 06:52 schrieb Nikolaus Rath:
 If someone cares deeply about this, the necessary patch is at 
 https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/.
  
 
 I did not add it to the debian package yet because I considered it a
 minor issue that I did not want to bug my sponsor with. But if some DD
 wants to sponsor a new upload right away to get this fixed, I'm happy to
 update the package in SVN.

sure, I can do this.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f47510.7000...@debian.org



Re: guardian and django1.7

2014-08-20 Thread Brian May
On 19 Aug 2014 18:37, Brian May br...@microcomaustralia.com.au wrote:

 On 19 Aug 2014 18:04, Raphael Hertzog hert...@debian.org wrote:
  Did you fill that new directory with an initial migration generated with
  ./manage.py makemigrations?

 Yes, did that, but than I realized I needed to do testapp.

 So I did just testapp by itself, but suspect both django apps need to be
done.

 At which point I ran out of time :-)

If this works, my concern, if not obvious: to rename the migrations
directories to south_migrations in a debian/patch file will require a patch
to delete every file and another patch to recreate it in the new release.
This will have to be done/rechecked for every release.

Yuck.


Re: Playing with git-dpm

2014-08-20 Thread Vincent Bernat
 ❦ 19 août 2014 21:44 -0400, Barry Warsaw ba...@debian.org :

 * Switching branches makes my editor unhappy.

 Why is this a PITA?  Because Emacs will notice that a file you're visiting in
 a buffer is changed and will prompt you reload it.  I guess because
 checkout-patched deletes the debian directory and update-patches restores it,
 it makes Emacs unhappy.  I suppose you also have to be careful not to write a
 buffer to the debian/ directory when in the patched-pkg branch.

I am using this snippet:

#+begin_src elisp
(defun vbe:revert-buffer-keep-history (rest -)
  Revert buffer but keep undo history
  (clear-visited-file-modtime)
  (widen)
  (let ((inhibit-read-only t)
(current-point (point)))
(delete-region (point-min) (point-max))
(insert-file-contents (buffer-file-name))
(not-modified)
(goto-char current-point)
(set-visited-file-modtime)))

(setq revert-buffer-function 'vbe:revert-buffer-keep-history)
(global-auto-revert-mode 1)   ; Auto revert (when no pending changes)
#+end_src

This makes auto revert automatic but don't lose the previous content
by keeping the undo history. It also keeps your current position in the
file.
-- 
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan  Plauger)


signature.asc
Description: PGP signature


Bug#758720: ITP: python-astropy-helpers -- Utilities to build and install Astropy affiliated packages

2014-08-20 Thread Ole Streicher
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist
Owner: Ole Streicher deb...@liska.ath.cx
X-Debbugs-Cc:  debian-de...@lists.debian.org, debian-as...@lists.debian.org, 
debian-python@lists.debian.org


* Package name: python-astropy-helpers
  Version : 0.4.1
  Upstream Author : The Astropy Developers
* URL : http://astropy.org
* License : BSD
  Programming Lang: Python
  Description : Utilities to build and install Astropy affiliated packages

This project provides a Python package, astropy_helpers, which
includes many build, installation, and documentation-related tools
used by the Astropy project, but packaged separately for use by
other projects that wish to leverage this work. The motivation
behind this package and details of its implementation are in the
accepted Astropy Proposal for Enhancement (APE) 4.

I am still not sure whether this will be built from a separated source
package, of as an additional package of the python-astropy source.

Best

Ole

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJT9LR/AAoJEHEVr9B3ENz3xj0QAIPexnVRkMemUs0dS/CNfD9c
5zSigmAdEBKLfgsAosbUBgBDl6JrWDFgBnOMArb/w1PIp1oe+8gpsh+TjngJg/yq
DSGeADlwGu25oCeDmtiNA8AVHlirV13VbchFTFREkEey0U9w4Wahq2abfBQhXjC9
sMbNJH8cNvDG3ai+/IpYXRxrF3uN/KipUJSGBftfeNuPvunkNWkIt2I82EhezqR9
PAjOIdEAovIizafStyZTlNirmS8F5bSVG7XXTyA6jhx1T53FWagq6y1MP8B33L4S
3EH3eVVjcttD9XlMdsIqLxlsEVPZd3SzjKKQNP1eeLHBUpMOfED7Ao49vay4Pab4
/N4H0uP0DS9yl5hFF9Qg5dA9TsC558x5ufWeNh3PtJH9qKakna8noqIzTDh6dNuy
HowvzltCQquqh1fPDCvfR8SF/EKEziP+/gDzwx4XP0iDE/ZBDry/Bjy6bjiklM1L
eRhVPu4HC+z0JyBSkUL21W/5M5cjgVsID49bcrKFSuf6NyG88St0yFAYc1B36VWh
0Lgddb+vt6AOO1B4h7ftF6JAYGz24/4M5znHTYN08ISoqChfYbVxZ80JmFQQ6Yau
g77gzN/2pPVnghyyaT1z3j31BAGaCbr4Sixny/T8Y3hg+rsQmoE1OamJz55iZ3tL
9L5nWkTlrpYfpdr4hq9L
=6naU
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f4b47f.1030...@liska.ath.cx



Re: Playing with git-dpm

2014-08-20 Thread Barry Warsaw
On Aug 20, 2014, at 08:26 AM, Vincent Bernat wrote:

This makes auto revert automatic but don't lose the previous content
by keeping the undo history. It also keeps your current position in the
file.

Thanks!  I'll have to think about whether I want to enable this globally, but
it does seem like it would come in handy with git-dpm.

Cheers,
-Barry



signature.asc
Description: PGP signature


archivemail: joining the team?

2014-08-20 Thread Jonathan Dowland
Hi all,

I have a vested in interested in the archivemail package. The maintainer
appears to be MIA so I uploaded an NMU today; the package has had a FTBFS (due
to a bad test) for nearly a year.

I didn't really notice until afterwards that the package was in team
maintenance.

Anyway, I was going to look into taking over the package before I realised
that, so instead perhaps I should join the team? I've clicked the 'join' button
on alioth.


Thanks

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140820190731.ga25...@bryant.redmars.org



Re: Playing with git-dpm

2014-08-20 Thread Raphael Hertzog
Hi Barry,

On Tue, 19 Aug 2014, Barry Warsaw wrote:
 * The egg-info directory is a PITA.
 
 The upstream tarball has a lazr.smtptest.egg-info directory.  debuild -S blows
 this away, and then git thinks I want to delete it.  It doesn't get staged, so
 it's easy to `git checkout -- lazr.smtptest.egg-info`[3], but it gets annoying
 *very* quickly after just a few debuilds.  I'm not sure what the best way to
 handle this is, if there is one.

You can commit the removal, but it will regularly cause merge conflicts.

Or you can build the package in another directory, like svn-buildpackage
does. I'm not sure if git-dpm has something for this but you can
probably use git-buildpackage --git-export-dir=../build-area/ in
combination with git-dpm.

 * debian/patches/* get named automatically
 
 `git-dpm checkout-patched` creates a temporary patch branch.  I had to patch
 the setup.py, so I just edited it as normal.  Note though that you *must*
 commit this file while on the patch branch or it doesn't get quilt-ified, but
 it will still show up as modified on your packaging branch if you switch to
 it.  Oh, and the first line of your commit message gets turned into patch
 name.  I like that it handles quilt-ifying the patch automatically when you
 `git-dpm update-patches` but watch out with your commit messages or you may be
 left with a patch file that has an odd name.  I didn't try to change that and
 see if git-dpm could still grok the patch.

I believe that git-dpm can handle any quilt series as input but it will
always rename it based on the commit after a checkout-patched.

 * Where to push the repo?
 
 I'm not sure that we have a definitive path on git.debian.org for team
 maintained packages under git, but there is a python-modules directory
 containing a few packages.  So I pushed my branches to
 git+ssh://git.debian.org/git/python-modules/packages/lazr.smtptest.git
 
 It takes a bit of work to create this directory initially, but I found that
 gbp has a nice command you can corrupt wink into doing the right thing for
 you, e.g.:

Please do something like this to create new git repositories for
python-modules:
$ ssh git.debian.org
$ cd /git/python-modules
$ ./setup-repository lazr.smtptest lazr.smtptest packaging
$ exit

It will setup some default hooks to to forward the commit notices where
appropriate.

(I just did the required configuration for you.)

 Oddly, I don't see the repo here: http://anonscm.debian.org/cgit/ but I have
 no idea why.

It's there now. The repository listing is not updated in real time (too
much I/O involved).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140820192111.gb2...@x230-buxy.home.ouaza.com



Re: Playing with git-dpm

2014-08-20 Thread Barry Warsaw
On Aug 19, 2014, at 09:44 PM, Barry Warsaw wrote:

Anyway, I think that's it for now.  Feel free to muck about in this package,
but please do let me know if you want to push any permanent changes.  Tomorrow
I'll probably try to do a new upstream release to fix the typo in the setup.py
so I'll do a new package version and see how well that process works.

Done.  A few more thoughts:

d/patches are handled very nicely.  The thing I had to quilt patch in 2.0.1-1,
I fixed in the new upstream version.  When I updated to the new upstream,
git-dpm did the right thing by deleting the entire d/patches directory.
I.e. because the specific patch was no longer necessary, it got deleted, but
then there were no other patches in the quilt stack, so the whole directory
could just be dropped.  This was handled completely seamlessly.

Be sure you `git push --all --tags` or your upstream-* and pristine-tar
branches don't get pushed.  --tags of course pushes the tags, and
`git-dpm tag` works nicely[*].

I really wish `git-dpm import-new-upstream` would optionally take no
arguments, in which case it would call uscan to get the orig.tar.gz before
importing.  It would just save a little typing.  Even cooler would be
`git-dpm -vX.Y.Z` in which case it would add the d/changelog entry, uscan to
download the new orig.tar.gz, then call import-new-upstream.

git-dpm is just a shell script so I might try to submit a patch for that.

It's a little inconvenient to test out a new upstream tarball.  I think this
is a corner case, but I'll describe the situation for posterity.

I'm both upstream for lazr.smtptest and maintainer, and the bug I hit was in
the setup.py so for 2.0.1-1 I just added a quilt patch to work around the
problem.  Now, I go back to upstream and fix the typo there, but before I
release the new upstream, I'd like to test it in the context of a provisional
package build.  So I `python setup.py sdist` to create the tarball, copy it to
blah.orig.tar.gz and then import it into my local git-dpm repo.  I do a test
build and notice that the upstream patch is not quite right.  So I go back to
the upstream branch, fix the bug again, generate a new orig.tar.gz and head
back to the git-dpm repo.

The problem is that I've already imported the 2.0.2 orig.tar.gz.  The import
had been committed on all three branches, otherwise I wouldn't have been able
to test the new potential upstream release.

To back out of this and import the newly generated 2.0.2 tarball, I have to
checkout all three branches (i.e. upstream-lazr.smtptest, pristine-tar, and
lazr.smtptest) and uncommit (`git reset --hard HEAD^`) the effects of the
import.  Now I'm back to a known good place and can replay the import.

The other option would have been to do all this in a separate clone until I
was happy, but that's kind of icky.  I'm not sure what else would work better,
and as I say it's a corner case so probably not worth spending much effort
on.

One last thing: I'm not sure I recommend going with the package name as the
branch name.  I'm tired of typing `upstream-lazr.smtptest`.  The default
git-dpm branch names are starting to make more sense. :)

Cheers,
-Barry


signature.asc
Description: PGP signature


Re: archivemail: joining the team?

2014-08-20 Thread Piotr Ożarowski
[Jonathan Dowland, 2014-08-20]
 I have a vested in interested in the archivemail package. The maintainer
 appears to be MIA so I uploaded an NMU today; the package has had a FTBFS (due
 to a bad test) for nearly a year.
 
 I didn't really notice until afterwards that the package was in team
 maintenance.
 
 Anyway, I was going to look into taking over the package before I realised
 that, so instead perhaps I should join the team? I've clicked the 'join' 
 button
 on alioth.

thanks for updating archivemail and welcome on board :)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140820192945.gf4...@sts0.p1otr.com



Re: Playing with git-dpm

2014-08-20 Thread Barry Warsaw
Hi Raphael,

On Aug 20, 2014, at 09:21 PM, Raphael Hertzog wrote:

Or you can build the package in another directory, like svn-buildpackage
does. I'm not sure if git-dpm has something for this but you can
probably use git-buildpackage --git-export-dir=../build-area/ in
combination with git-dpm.

So, because of the way I've named the branches, the full invocation is:

$ git-buildpackage -S --git-export-dir=../build-area/ 
--git-debian-branch=lazr.smtptest --git-upstream-tree=upstream-lazr.smtptest

I really like gbp (and svn-buildpackage) default of using ../build-area/ and
this works nicely enough that it might be worth adding to git-dpm (or at least
creating another script/alias/config-setting/kludge) to make this work.  It's
a much better solution - thanks!

I believe that git-dpm can handle any quilt series as input but it will
always rename it based on the commit after a checkout-patched.

I think that's right.

Please do something like this to create new git repositories for
python-modules:
$ ssh git.debian.org
$ cd /git/python-modules
$ ./setup-repository lazr.smtptest lazr.smtptest packaging
$ exit

It will setup some default hooks to to forward the commit notices where
appropriate.

(I just did the required configuration for you.)

Thanks for both the recommendation and the fix!  Once the team decides on a
workflow, will it be feasible to write the equivalent of svn-inject?  Since
shell access to g.d.o is required it seems like this won't be completely
self-services, but teammates who are DDs could do it for other folks.

It's there now. The repository listing is not updated in real time (too
much I/O involved).

I was afraid of that. ;)

Cheers,
-Barry


signature.asc
Description: PGP signature


Re: Playing with git-dpm

2014-08-20 Thread Barry Warsaw
Oh, and I'm assuming that whatever we decide for DPMT would also apply to
PAPT, but that may not be a correct assumption?

In any case, once we decide, I volunteer to update the wiki documentation (and
policy as appropriate) with best practices.

Cheers,
-Barry


signature.asc
Description: PGP signature


Re: Playing with git-dpm

2014-08-20 Thread Raphael Hertzog
On Wed, 20 Aug 2014, Barry Warsaw wrote:
 So, because of the way I've named the branches, the full invocation is:
 
 $ git-buildpackage -S --git-export-dir=../build-area/ 
 --git-debian-branch=lazr.smtptest --git-upstream-tree=upstream-lazr.smtptest

So --git-export-dir is usally best set in ~/.gbp.conf:
$ cat ~/.gbp.conf
[DEFAULT]
pristine-tar = True
cleaner = /bin/true

[git-buildpackage]
sign-tags = True
export-dir = ../build-area/

For the other two options, the recommended practice is to put them in
debian/gbp.conf but I generally don't do that and just use standard branch
names (master / upstream).

 Thanks for both the recommendation and the fix!  Once the team decides on a
 workflow, will it be feasible to write the equivalent of svn-inject?  Since
 shell access to g.d.o is required it seems like this won't be completely
 self-services, but teammates who are DDs could do it for other folks.

git-import-dsc is your svn-inject, it will put upstream sources in the upstream
branch and will create the master branch based on that with the packaging
changes. But the quilt patches won't be applied after this operation.

I managed to start using git-dpm on a pre-existing repository but it required
an initial git-dpm init .../mypkg_1.orig.tar.gz IIRC.

Note that all members of the team automatically have shell access to 
git.debian.org
(it's just alioth itself).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140820201709.gc2...@x230-buxy.home.ouaza.com



python-openssl unavailable in sid

2014-08-20 Thread Brian May
Hello,

Can somebody please tell me why python-openssl and python3-openssl isn't
available in sid?


(sid-amd64)root@aquitard:/home/brian/tree/debian/unstable/celery/celery#
apt-get update
Get:1 http://ftp.au.debian.org sid InRelease [231 kB]
Get:2 http://ftp.au.debian.org sid/main Translation-en [4673 kB]
Get:3 http://ftp.au.debian.org sid/main amd64 Packages [6887 kB]
Fetched 11.8 MB in 6s (1882 kB/s)

Reading package lists... Done
(sid-amd64)root@aquitard:/home/brian/tree/debian/unstable/celery/celery#
apt-get install python-openssl python3-openssl
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package python-openssl is not available, but is referred to by another
package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

Package python3-openssl is not available, but is referred to by another
package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'python-openssl' has no installation candidate
E: Package 'python3-openssl' has no installation candidate

(sid-amd64)root@aquitard:/home/brian/tree/debian/unstable/celery/celery#
apt-cache policy python-openssl-doc
python-openssl-doc:
  Installed: 0.13.1-2
  Candidate: 0.13.1-2
  Version table:
 *** 0.13.1-2 0
500 http://ftp.us.debian.org/debian/ sid/main amd64 Packages
100 /var/lib/dpkg/status

Note that this version of python-openssl-doc is old, should have been
updated two days ago.


The following look fine to me:

https://packages.qa.debian.org/p/pyopenssl.html
https://packages.debian.org/sid/python-openssl


Is my local mirror bad? I tried random other mirrors, and get the same
problem. Alternatively, is something wrong with my local chroot?


It appears that the packages produced have changed to architecture
dependant packages, seriously wondering if maybe this got DAK confused.


(this problem is preventing me from uploading a fix for an RC bug)


Thanks
-- 
Brian May br...@microcomaustralia.com.au


Re: python-openssl unavailable in sid

2014-08-20 Thread Cyril Brulebois
Brian May br...@microcomaustralia.com.au (2014-08-21):
 Can somebody please tell me why python-openssl and python3-openssl isn't
 available in sid?
[…]
 It appears that the packages produced have changed to architecture
 dependant packages, seriously wondering if maybe this got DAK confused.
 
 
 (this problem is preventing me from uploading a fix for an RC bug)

Adding ftpmasters in the loop to make sure they see your report.

dak sees:
  python-openssl | 0.14-1  | sid  | all

while the amd64 Packages file only lists:
  python-openssl-dbg (amd64)
  python-openssl-doc (all)
  python3-openssl-dbg (amd64)

https://ftp-master.debian.org/removals.txt reports that the following
packages were indeed removed from sid:
  python-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc
  python3-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc

So it looks to me it might “just” be about getting arch:all packages
listed again in Packages files.

Mraw,
KiBi.


signature.asc
Description: Digital signature


Re: python-openssl unavailable in sid

2014-08-20 Thread Brian May
On 21 August 2014 10:42, Cyril Brulebois k...@debian.org wrote:

 Brian May br...@microcomaustralia.com.au (2014-08-21):
  Can somebody please tell me why python-openssl and python3-openssl isn't
  available in sid?
 […]
  It appears that the packages produced have changed to architecture
  dependant packages, seriously wondering if maybe this got DAK confused.


Obviously I meant to say ... changed to architecture *IN*dependant
packages. :-)


Adding ftpmasters in the loop to make sure they see your report.


Thanks for this.


dak sees:
   python-openssl | 0.14-1  | sid  | all

 while the amd64 Packages file only lists:
   python-openssl-dbg (amd64)
   python-openssl-doc (all)
   python3-openssl-dbg (amd64)

 https://ftp-master.debian.org/removals.txt reports that the following
 packages were indeed removed from sid:
   python-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386,
 kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc
   python3-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386,
 kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc

 So it looks to me it might “just” be about getting arch:all packages
 listed again in Packages files.


-- 
Brian May br...@microcomaustralia.com.au


Re: Bug#758013: s3ql autopkg test regression

2014-08-20 Thread Nikolaus Rath
On 08/20/2014 03:14 AM, Matthias Klose wrote:
 Am 20.08.2014 um 06:52 schrieb Nikolaus Rath:
 If someone cares deeply about this, the necessary patch is at 
 https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/.
  

 I did not add it to the debian package yet because I considered it a
 minor issue that I did not want to bug my sponsor with. But if some DD
 wants to sponsor a new upload right away to get this fixed, I'm happy to
 update the package in SVN.
 
 sure, I can do this.

SVN is updated.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f5469d.3020...@rath.org