Bug#843627: Give back mercurial for armhf

[Javi Merino]

Hi,

mercurial 4.0-1 failed to build on armhf because
test-largefiles-update.t failed[0].  I've tested it on a porterbox ten
times and I can't reproduce the error.  Can you please give it back
for armhf and see if it was a transient error in the testsuite?

gb mercurial_4.0-1 . armhf

[0] 
https://buildd.debian.org/status/fetch.php?pkg=mercurial=armhf=4.0-1=1478103982


signature.asc
Description: PGP signature

Bug#825646: trace-cmd: New upstream release 2.6

[Javi Merino]

Source: trace-cmd
Severity: wishlist
Tags: patch

trace-cmd has a new version upstream: 2.6.  I have prepared an update
for it, find it attached.

Cheers,
Javi

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/changelog b/debian/changelog
index 2ab6641..c511b63 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+trace-cmd (2.6-0.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release
+  * Build-depend on dh-python
+  * Bump standards-version to 3.9.8 (no change needed)
+
+ -- Javi Merino <vi...@debian.org>  Sat, 28 May 2016 13:20:49 +0200
+
 trace-cmd (2.5.3-1) unstable; urgency=medium
 
   * Bump Standards-Version to 3.9.6
diff --git a/debian/control b/debian/control
index cf37d53..b4c0f59 100644
--- a/debian/control
+++ b/debian/control
@@ -3,8 +3,8 @@ Section: devel
 Priority: optional
 Maintainer: Ubuntu Kernel Team <kernel-t...@lists.ubuntu.com>
 Uploaders: Seth Forshee <seth.fors...@canonical.com>, Kamal Mostafa <ka...@canonical.com>
-Standards-Version: 3.9.6
-Build-Depends: debhelper (>= 7), cdbs, asciidoc, docbook-xsl, libgtk2.0-dev, xsltproc, libxml2-dev, python-dev (>= 2.6.6-3), python-gtk2-dev, swig
+Standards-Version: 3.9.8
+Build-Depends: debhelper (>= 7), cdbs, asciidoc, docbook-xsl, libgtk2.0-dev, xsltproc, libxml2-dev, python-dev (>= 2.6.6-3), python-gtk2-dev, swig, dh-python
 Vcs-Git: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
 Vcs-Browser: http://git.kernel.org/?p=linux/kernel/git/rostedt/trace-cmd.git
 

Bug#825033: sonata: new upstream beta release using Python 3

[Javi Merino]

On Fri, May 27, 2016 at 06:28:54PM +0100, Simon McVittie wrote:
> On Fri, 27 May 2016 at 16:06:52 +0200, Javi Merino wrote:
> > > +sonata (1.7~b1-0.1) UNRELEASED; urgency=medium
> > > +
> > > +  * Non-maintainer upload.
> > 
> > The package is team maintained by the Python apps packaging team.
> > I'd say this is a team upload more than an NMU.
> 
> I might be theoretically a member of that team, but if I am, then I don't
> remember that I am :-)
> 
> > To be honest, I've lost interest in the package.  If you want to take
> > the package over, feel free to replace my name with yours.
> 
> I'm very tempted to move it to collab-maint git and list pkg-mpd as
> primary maintainer - the more I use git the more I hate packaging with
> svn, and others in pkg-mpd seem more likely to care about this package
> than others in PAPT. Would that be OK?

It makes sense.  Sonata is part of the mpd "ecosystem" whereas
regarding PAPT, it's just an application written in python.  If more
people are going to take care of it in pkg-mpd then by all means move
it there.

Cheers,
Javi

Bug#825033: sonata: new upstream beta release using Python 3

[Javi Merino]

Hi Simon,

On Sun, May 22, 2016 at 06:56:12PM +0100, Simon McVittie wrote:
> Package: sonata
> Version: 1.6.2.1-6
> Severity: wishlist
> Tags: patch
> Control: block -1 by 808824
> 
> The original sonata website has vanished, but there are two maintained
> forks.
> 
> http://www.nongnu.org/sonata/ points to https://github.com/multani/sonata/
> which has a beta release 1.7b1 running under Python 3. This requires
> python-mpd2, a fork of python-mpd with Python 3 compatibility, which
> I've just uploaded to NEW (#808824 will be closed when this reaches
> the archive).

The beta release is from January but the previous alpha release is
from 2013.  I though about packaging the beta for Jessie, I'm glad
that I didn't :)

> There is also <https://codingteam.net/project/sonata> which points to
> <https://git.gitorious.org/sonata/sonata>, but that seems to be dead
> (latest commit 2012, no releases since 1.6.2.1) so I would suggest
> ignoring it.
> 
> I have prepared a proof-of-concept update for the Sonata packaging,
> attached. Also available from:
> ssh://git.debian.org/git/users/smcv/sonata.git

Looks good to me.  One minor nit.

> From 483297dd9991e97bc81f9231a82faaa35a0a6535 Mon Sep 17 00:00:00 2001
> From: Simon McVittie <s...@debian.org>
> Date: Sun, 22 May 2016 18:34:50 +0100
> Subject: [PATCH] New upstream beta version
> 
> ---
>  debian/changelog   |  26 
>  debian/clean   |   1 +
>  debian/control |  62 +
>  debian/copyright   |  73 +++---
>  debian/patches/fix-cras-on-no-albums.patch |  16 ---
>  debian/patches/fix-lyrics-fetching.patch   |  43 --
>  debian/patches/fix-missing-crossfade.patch |  24 
>  debian/patches/from_upstream__fix-mmkeys.patch |  44 --
>  debian/patches/series  |   4 -
>  debian/python-mmkeys.docs  |   1 -
>  debian/python-mmkeys.install   |   1 -
>  debian/python-mmkeys.preinst   |  11 --
>  debian/rules   |  20 ++-
>  debian/sonata.docs |   3 +-
>  debian/sonata.install  |   3 +-
>  debian/sonata.menu |   4 -
>  debian/sonata.xpm  | 177 
> -
>  debian/watch   |   5 +-
>  18 files changed, 136 insertions(+), 382 deletions(-)
>  create mode 100644 debian/clean
>  delete mode 100644 debian/patches/fix-cras-on-no-albums.patch
>  delete mode 100644 debian/patches/fix-lyrics-fetching.patch
>  delete mode 100644 debian/patches/fix-missing-crossfade.patch
>  delete mode 100644 debian/patches/from_upstream__fix-mmkeys.patch
>  delete mode 100644 debian/python-mmkeys.docs
>  delete mode 100644 debian/python-mmkeys.install
>  delete mode 100755 debian/python-mmkeys.preinst
>  delete mode 100644 debian/sonata.menu
>  delete mode 100644 debian/sonata.xpm
> 
> diff --git a/debian/changelog b/debian/changelog
> index 861eaa5..3cd6674 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,29 @@
> +sonata (1.7~b1-0.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.

The package is team maintained by the Python apps packaging team.
I'd say this is a team upload more than an NMU.

> [...]
> diff --git a/debian/control b/debian/control
> index b6f1ab2..2ec7b97 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -2,40 +2,46 @@ Source: sonata
>  Section: sound
>  Priority: optional
>  Maintainer: Python Applications Packaging Team 
> <python-apps-t...@lists.alioth.debian.org>
> -Uploaders: Javi Merino <vi...@debian.org>
> -Build-Depends: debhelper (>= 9),
> -python-all-dev (>= 2.6.6-3~),
> -pkg-config, 
> -python-gtk2-dev
> -Build-Conflicts: libffi4-dev
> -Standards-Version: 3.9.5
> +Uploaders:
> + Javi Merino <vi...@debian.org>,

To be honest, I've lost interest in the package.  If you want to take
the package over, feel free to replace my name with yours.

Cheers,
Javi

Bug#805756: mercurial-git: add explanatory comments in README.Debian for reST markup

[Javi Merino]

On Sun, Nov 22, 2015 at 05:05:20PM +1100, Ben Finney wrote:
> Control: retitle -1 mercurial-git: add explanatory comments in README.Debian 
> for reST markup
> Control: tags -1 + patch
> 
> On 22-Nov-2015, txt.file wrote:
> > I think this would help. As it is neither from the file name ending nor
> > from the content obvious that this file could be reST.
> 
> Attached is a patch for the current ‘mercurial-git’ code, which adds
> an explanatory comment and editor hints for Emacs and Vim.

I've patched it in the repository.  I'll upload it with the next
version of mercurial-git.  Thanks!
Javi

Bug#804167: fails to upgrade

[Javi Merino]

On Fri, 6 Nov 2015 16:21:03 +0100 Andreas Henriksson  wrote:
> Hi again.
>
> On Fri, Nov 06, 2015 at 03:01:08PM +0100, Peter Palfrader wrote:
> [...]
> > But it should work.
> >
> > An "exit 0" at the end, or a "if [ -d ... ]; then rmdir .. ; fi" would
> > also work instead and might be preferable.
>
> Please stop suggesting exit 0. It does not work. Hopefully the attached
> minimal testcase will convince you of this. The final "exit 0" will
> simply never be reached. run: ./foo.sh && echo $?
> (Try also replace 'false' with 'false && true' to more exactly simulate
> your particular bug case.)
>
> (... and even if it was reached, that would certainly throw away
> any exit code - not just the rmdir one.)
>
> rmdir failing is not the end of the world anyway, it's just a
> "lets be nice and clean up if we can" kind of thing.
>
> In your very obscure case that noone else triggered so far there
> is no directory to clean up anyway, so don't worry! :P

For the record, I've triggered this today when upgrading an aarch64
chroot.  Maybe it's not that obscure ;)

Cheers,
Javi

Bug#804267: mercurial-crecord: remove mercurial-crecord from the archive

[Javi Merino]

Package: mercurial-crecord
Version: 0.20140626-1
Severity: normal

According to [0], mercurial-crecord is included in mercurial 3.6.  You
can enable it by adding to your .hgrc:

[experimental]
crecord=True

and do "hg commit -i" to bring the crecord interface.

To me, it looks like we don't need mercurial-crecord in sid/stretch
any more, shall we remove it from the archive?

[0] 
https://bitbucket.org/edgimar/crecord/issues/48/crecord-occasionally-fails-in-mercurial-36#comment-23129458

Bug#804267: mercurial-crecord: remove mercurial-crecord from the archive

[Javi Merino]

On Fri, Nov 06, 2015 at 08:21:33PM +0100, Andrew Shadura wrote:
> Hello,
> 
> On 6 November 2015 at 20:10, Javi Merino <vi...@debian.org> wrote:
> > Package: mercurial-crecord
> > Version: 0.20140626-1
> > Severity: normal
> >
> > According to [0], mercurial-crecord is included in mercurial 3.6.  You
> > can enable it by adding to your .hgrc:
> >
> > [experimental]
> > crecord=True
> >
> > and do "hg commit -i" to bring the crecord interface.
> >
> > To me, it looks like we don't need mercurial-crecord in sid/stretch
> > any more, shall we remove it from the archive?
> 
> Yes, there's experimental implementation of crecord in Mercurial, yet
> I'm not sure it's mature enough — it's experimental, after all. When
> it stops being experimental we may stop shipping it.

Ok, let's wait until mercurial 3.7 (February 2016) and see if it's no
longer experimental then.

Cheers,
Javi


signature.asc
Description: PGP signature

Bug#804259: mercurial-git: TypeError: exchangepush() got an unexpected keyword argument 'opargs'

[Javi Merino]

On Fri, Nov 06, 2015 at 06:50:01PM +0100, Jakub Wilk wrote:
> Package: mercurial-git
> Version: 0.8.2-1
> Severity: grave
> 
> I can't push to git repos:
> 
> $ git init gitrepo
> Initialized empty Git repository in /home/jwilk/gitrepo/.git/
> 
> $ hg clone gitrepo hgrepo
> updating to branch default
> 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 
> $ cd hgrepo
> $ hg push
> pushing to /home/jwilk/gitrepo
> ** Unknown exception encountered with possibly-broken third-party extension 
> git
> ** which supports versions 3.4 of Mercurial.
> ** Please disable git and try your action again.
> ** If that fixes the bug please report it to 
> https://bitbucket.org/durin42/hg-git/issues
> ** Python 2.7.10+ (default, Oct 10 2015, 09:11:24) [GCC 5.2.1 20151028]
> ** Mercurial Distributed SCM (version 3.6)
> ** Extensions loaded: color, convert, gpg, graphlog, strip, mq, pager, 
> progress, purge, rebase, record, shelve, git
> Traceback (most recent call last):
>  File "/usr/bin/hg", line 43, in 
>mercurial.dispatch.run()
>  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 54, in 
> run
>sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
>  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 116, in 
> dispatch
>ret = _runcatch(req)
>  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 187, in 
> _runcatch
>return _dispatch(req)
>  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 920, in 
> _dispatch
>cmdpats, cmdoptions)
>  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 679, in 
> runcommand
>ret = _runcommand(ui, options, cmd, d)
>  File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 183, 
> in closure
>return func(*(args + a), **kw)
>  File "/usr/lib/python2.7/dist-packages/hgext/pager.py", line 139, in pagecmd
>return orig(ui, options, cmd, cmdfunc)
>  File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 183, 
> in closure
>return func(*(args + a), **kw)
>  File "/usr/lib/python2.7/dist-packages/hgext/color.py", line 525, in colorcmd
>return orig(ui_, opts, cmd, cmdfunc)
>  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1051, in 
> _runcommand
>return checkargs()
>  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1011, in 
> checkargs
>return cmdfunc()
>  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 917, in 
> 
>d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
>  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 803, in check
>return func(*args, **kwargs)
>  File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 183, 
> in closure
>return func(*(args + a), **kw)
>  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 803, in check
>return func(*args, **kwargs)
>  File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3525, in mqcommand
>return orig(ui, repo, *args, **kwargs)
>  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 803, in check
>return func(*args, **kwargs)
>  File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 5426, in 
> push
>opargs=opts.get('opargs'))
>  File "/usr/lib/python2.7/dist-packages/mercurial/extensions.py", line 183, 
> in closure
>return func(*(args + a), **kw)
>  File "/usr/lib/python2.7/dist-packages/hgext/git/util.py", line 48, in inner
>return f(*args, **kwargs)
> TypeError: exchangepush() got an unexpected keyword argument 'opargs'

Gah, sorry for that, it's due to mercurial 3.6.  I did a very brief
test of mercurial-git but I didn't test pushing to git repositories so
I missed it.

There isn't a new version of mercurial-git yet, so for the time being
downgrade to mercurial 3.5.2-2 as workaround.

Cheers,
Javi


signature.asc
Description: PGP signature

Bug#802923: mercurial-common: Rename of bash-completion file broke completion autoloading mechanism.

[Javi Merino]

Hi Oleksandr,

On Sun, Oct 25, 2015 at 09:38:07AM +0200, Oleksandr Gavenko wrote:
> Package: mercurial-common
> Version: 3.5.2-1
> Severity: normal
> New version move
> 
>   /usr/share/bash-completion/completions/hg
> 
> to:
> 
>   /usr/share/bash-completion/completions/mercurial
> 
> Newer bash-completion project moved to autoloading on demand schema with
> "completion -D" trick.
> 
> This means that completion file only loaded during first time pressing TAB on
> "hg ... TAB" expression in interactive session.
> 
> As for now we have no "hg" completion it wasn't loaded. As a trick I type:
> 
>   $ mercurial cloTAB
> 
> and:
> 
>   complete -o bashdefault -o default -o nospace -F _hg hg \
>   || complete -o default -o nospace -F _hg hg
> 
> from /usr/share/bash-completion/completions/mercurial, loaded and starting
> from that time I able to use completion for hg.
> 
> I don't understand reason for such renames even if look to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799052

Isn't this the same as https://bugs.debian.org/801079 ?

reportbug says that you're still using 3.5.2-1, is this fixed in 3.5.2-2?

Cheers,
Javi

Bug#803082: [Python-modules-team] Bug#803082: Bug#803082: ipython ftbfs (too new lessc version)

[Javi Merino]

On Fri, Oct 30, 2015 at 05:34:41PM +0100, Matthias Klose wrote:
> On 30.10.2015 10:03, Brian May wrote:
> >I suspect the solution to this is to update to use ipython 4.0.0
> >
> >It looks like there have been significant structural changes in 4.0.0,
> >so work is required to merge the patches (conflicts occur due to missing
> >files) and update debian/rules.
> 
> the 3.x series seems to be still recent enough, and still has the monolithic
> approach. So maybe you'll see less surprises with this one?

Julien Puydt (CCed) has been filing a number of ITPs for
ipython/jupyter packages recently, so maybe he's also considering the
transition to ipython 4.0.0.

Cheers,
Javi

Bug#800539: ITP: python-trappy -- Trace Analysis and Plotting

[Javi Merino]

Package: wnpp
Severity: wishlist
Owner: Javi Merino <vi...@debian.org>

* Package name: python-trappy
  Version : 1.0.0
  Upstream Author : ARM trappy team <tra...@arm.com>
* URL : https://arm-software.github.io/trappy
* License : Apache
  Programming Lang: Python
  Description : Trace Analysis and Plotting

TRAPpy is a framework written in Python for analysing and plotting
FTrace data by converting it into standardised PANDAS DataFrames
(tabular times series data representation). The goal is to allow
developers easy and systematic access to FTrace data and leverage the
flexibility of PANDAS for the analysis.

TRAPpy also provides functionality to build complex statistical
analysis based on the underlying FTrace data.

I'm using this package and I'm one of the upstream authors.  I will
set the maintainer to the python modules team with me as uploader.
I'll continue to maintain the package in Debian.

Bug#794987: mercurial-git: failed to import extension hgext.git: No module named ignore

[Javi Merino]

Control: forwarded -1 
https://bitbucket.org/durin42/hg-git/issues/157/hg-git-081-doesnt-work-under-mercurial-35

On Sat, Aug 08, 2015 at 10:04:18PM -0400, James McCoy wrote:
 Package: mercurial-git
 Version: 0.8.1-2
 Severity: important
 
 In a repository using hg-git:
 
 $ hg status
 *** failed to import extension hgext.git: No module named ignore
 ** unknown exception encountered, please report by visiting
 ** http://mercurial.selenic.com/wiki/BugTracker
 ** Python 2.7.10 (default, Jul  1 2015, 10:54:53) [GCC 4.9.2]
 ** Mercurial Distributed SCM (version 3.5)
 ** Extensions loaded: color, graphlog, hgk, strip, mq, pager, purge, record, 
 rebase, histedit, gpg
 Traceback (most recent call last):
   File /usr/bin/hg, line 43, in module
 mercurial.dispatch.run()
   File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 30, in 
 run
 sys.exit((dispatch(request(sys.argv[1:])) or 0)  255)
   File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 92, in 
 dispatch
 ret = _runcatch(req)
   File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 163, in 
 _runcatch
 return _dispatch(req)
   File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 862, in 
 _dispatch
 repo = hg.repository(ui, path=path)
   File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 136, in 
 repository
 peer = _peerorrepo(ui, path, create)
   File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 123, in 
 _peerorrepo
 obj = _peerlookup(path).instance(ui, path, create)
   File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 93, in 
 _peerlookup
 return thing(path)
   File /usr/lib/python2.7/dist-packages/hgext/git/__init__.py, line 84, in 
 _local
 p = urlcls(path).localpath()
 TypeError: 'NoneType' object is not callable

Argh, yes, mercurial-git 0.8.1 doesn't work with hg 3.5.  When I
uploaded mercurial-git 0.8.1-2, I thought the breaks in mercurial
would still be valid (but I didn't check it, and I should have).
Sorry for that.

I was waiting for a new version of mercurial-git to be released, but
given that I've already broken it, I may backport the fix and release
a 0.8.1-3 that is compatible with mercurial 3.5.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#793365: ipython should recommend python-pygments

[Javi Merino]

Package: ipython
Version: 2.3.0-2
Severity: normal

Hi,

After installing ipython, ipython nbconvert fails with an
ImportError:


$ ipython nbconvert --to=html Untitled0.ipynb   
 
[NbConvertApp] Created profile dir: u'/root/.ipython/profile_default'
Traceback (most recent call last):
  File /usr/bin/ipython, line 5, in module
start_ipython()
  File /usr/lib/python2.7/dist-packages/IPython/__init__.py, line 120, in 
start_ipython
return launch_new_instance(argv=argv, **kwargs)
  File /usr/lib/python2.7/dist-packages/IPython/config/application.py, line 
565, in launch_instance
app.start()
  File /usr/lib/python2.7/dist-packages/IPython/terminal/ipapp.py, line 367, 
in start
return self.subapp.start()
  File /usr/lib/python2.7/dist-packages/IPython/nbconvert/nbconvertapp.py, 
line 268, in start
self.convert_notebooks()
  File /usr/lib/python2.7/dist-packages/IPython/nbconvert/nbconvertapp.py, 
line 284, in convert_notebooks
exporter = exporter_map[self.export_format](config=self.config)
  File 
/usr/lib/python2.7/dist-packages/IPython/nbconvert/exporters/templateexporter.py,
 line 151, in __init__
super(TemplateExporter, self).__init__(config=config, **kw)
  File 
/usr/lib/python2.7/dist-packages/IPython/nbconvert/exporters/exporter.py, 
line 94, in __init__
self._init_preprocessors()
  File 
/usr/lib/python2.7/dist-packages/IPython/nbconvert/exporters/exporter.py, 
line 222, in _init_preprocesso
rs
self.register_preprocessor(preprocessor)
  File 
/usr/lib/python2.7/dist-packages/IPython/nbconvert/exporters/exporter.py, 
line 188, in register_preprocessor
return self.register_preprocessor(preprocessor_cls, enabled)
  File 
/usr/lib/python2.7/dist-packages/IPython/nbconvert/exporters/exporter.py, 
line 201, in register_preprocessor
self.register_preprocessor(preprocessor(parent=self), enabled)
  File 
/usr/lib/python2.7/dist-packages/IPython/nbconvert/preprocessors/csshtmlheader.py,
 line 54, in __init__
self._regen_header()
  File 
/usr/lib/python2.7/dist-packages/IPython/nbconvert/preprocessors/csshtmlheader.py,
 line 84, in _regen_header
from pygments.formatters import HtmlFormatter
ImportError: No module named pygments.formatters


The ipython package should recommend python-pygments to prevent this
error.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#779676: dep5-copyright-license-name-not-unique check is too strict or too severe.

[Javi Merino]

On Sun, 7 Jun 2015 17:30:02 -0500 Steve M. Robbins st...@sumost.ca wrote:
 On Wed, Mar 04, 2015 at 07:13:12AM +0900, Charles Plessy wrote:
 
  I think that the dep5-copyright-license-name-not-unique tag should either:
  
   - reduce its severity, as just an advice for readability, or
   - only be issued when the same short name is used with a different 
  description.
 
 Have to agree with Charles.  I got the warning on the attached
 copyright file that uses the suggested GPL-2+ twice and *with the
 same description*.

I fully agree.  This check fails for the examples in [0] so it should
be removed or fixed.  The offending code is in
checks/source-copyright.pm, lines 391-405:

for (@short_licenses) {
$short_licenses_seen{$_} = $i;
if (not defined($full_license)) {
$required_standalone_licenses{$_} = $i;
} else {
if(defined($full_licenses_seen{$_})
and $_ ne 'public-domain') {
tag 'dep5-copyright-license-name-not-unique',
  license: $_, (paragraph at line $current_line);
} else {
$full_licenses_seen{$_} = $current_line;
print(license, seen = $_\n);
}
}
}

This adds the license to $full_licenses_seen when there is an entry
with a License: and then fails if there is another entry with the same
License.  That's perfectly valid, as the examples show.

[0] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#784584: hg clone over https fails with error [SSL: TLSV1_ALERT_PROTOCOL_VERSION]

[Javi Merino]

Control: tags -1 + upstream jessie

Hi Mathias,

On Wed, May 06, 2015 at 10:28:17PM +, Mathias Gibbens wrote:
 Package: mercurial
 Version: 3.1.2-2
 Severity: normal
 
 Dear Maintainer,
 
 Cloning a mercurial repository over https is unexpectedly failing.
 However, using version 3.4-1 from unstable works as expected.
 
 * What led up to the situation?
 
 I tried to clone an existing personal mercurial repository from a new
 jessie install. When I do, I get this error:
 
 $ hg clone https://hg.calenhad.com/foobar
 abort: error: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert
 protocol version (_ssl.c:581)
 
 However, this works just fine on a wheezy system:
 
 $ hg clone https://hg.calenhad.com/foobar
 destination directory: foobar
 no changes found
 updating to branch default
 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
 The server I am trying to clone from only supports TLSv1.2 and the more
 recent DHE/ECDHE ciphers. You can view its ssllabs report at
 https://www.ssllabs.com/ssltest/analyze.html?d=hg.calenhad.com
 
 * What exactly did you do (or not do) that was effective (or
 ineffective)?
 
 I thought this might be caused by my server using SNI for multiple https
 virtual hosts, but including the --insecure option when cloning had no
 effect.

Hmmm, I think this is a duplicate of #769761:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769761

I'm not marking it as a duplicate yet because I haven't had time to
read the bug report fully.  If you think it is, feel free to merge
them.

 I also tried enabling SSLv3, TLSv1, and TLSv1.1 in addition to TLSv1.2
 on my webserver, but I still get the same error.
 
 I installed mercurial 3.4-1 from the unstable repository, and the clone
 worked properly. So somewhere between 3.1.2-2 and 3.4-1 this problem was
 resolved. I looked in the changelog for the package and don't see
 anything specifically related to this problem.

You can get most of the versions in between from snapshots:

http://snapshot.debian.org/package/mercurial/

 I'm not sure where to look to compare changes in mercurial between
 3.1.2-2 and 3.4-1. I'm happy to provide feedback or try configuration
 changes. Feel free to run my clone command above -- the repository is an
 empty one created for testing purposes.

Many thanks for the test repository.  If this is #769761, there's a
patch from upstream that can be backported to 3.1.2-2 to fix it.  I probably
won't have time to work on this until the end of the month.  Can you
keep that repository around for a month or so?

Thanks,
Javi


signature.asc
Description: Digital signature

Bug#783237: CVE-2014-9462

[Javi Merino]

Hi Alessandro,

On Sat, May 02, 2015 at 09:04:42AM +0100, Javi Merino wrote:
 On Fri, May 01, 2015 at 08:53:28PM +0200, Alessandro Ghedini wrote:
  On Fri, May 01, 2015 at 07:16:07PM +0100, Javi Merino wrote:
   On Fri, Apr 24, 2015 at 01:21:56PM +0200, Moritz Muehlenhoff wrote:
Package: mercurial
Severity: important
Tags: security

Please see
http://chargen.matasano.com/chargen/2015/3/17/this-new-vulnerability-mercurial-command-injection-cve-2014-9462.html

Fix:
http://selenic.com/hg/rev/e3f30068d2eb

[...]

  Also, the vulnerability seems to affect the wheezy version as well, could 
  you
  please prepare an upload targeting wheezy-security as well?

I've prepared an upload for wheezy-security, find the diff below.  Can
I upload it to security-master?

Index: debian/changelog
===
--- debian/changelog(revisión: 11643)
+++ debian/changelog(copia de trabajo)
@@ -1,3 +1,11 @@
+mercurial (2.2.2-4+deb7u1) wheezy-security; urgency=high
+
+  * Fix CVE-2014-9462 by adding patch
+from_upstream__sshpeer_more_thorough_shell_quoting.patch (Closes:
+#783237)
+
+ -- Javi Merino vi...@debian.org  Wed, 06 May 2015 08:09:26 +0100
+
 mercurial (2.2.2-4) stable; urgency=high
 
   * Security update for CVE-2014-9390: errors in handling case-sensitive
Index: debian/patches/series
===
--- debian/patches/series   (revisión: 11643)
+++ debian/patches/series   (copia de trabajo)
@@ -14,3 +14,4 @@
 
from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch
 from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch
 from_upstream__pathauditor_check_for_Windows_shortname_aliases.patch
+from_upstream__sshpeer_more_thorough_shell_quoting.patch
Index: debian/patches/from_upstream__sshpeer_more_thorough_shell_quoting.patch
===
--- debian/patches/from_upstream__sshpeer_more_thorough_shell_quoting.patch 
(revisión: 0)
+++ debian/patches/from_upstream__sshpeer_more_thorough_shell_quoting.patch 
(revisión: 11901)
@@ -0,0 +1,29 @@
+Origin: http://selenic.com/hg/rev/e3f30068d2eb
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783237
+Description: sshpeer: more thorough shell quoting
+ This fixes CVE-2014-9462
+Applied-Upstream: 3.2.4
+
+--- a/mercurial/sshrepo.py
 b/mercurial/sshrepo.py
+@@ -20,6 +20,8 @@ class remotelock(object):
+ self.release()
+ 
+ def _serverquote(s):
++if not s:
++return s
+ '''quote a string for the remote shell ... which we assume is sh'''
+ if re.match('[a-zA-Z0-9@%_+=:,./-]*$', s):
+ return s
+@@ -44,7 +46,10 @@ class sshrepository(wireproto.wirereposi
+ sshcmd = self.ui.config(ui, ssh, ssh)
+ remotecmd = self.ui.config(ui, remotecmd, hg)
+ 
+-args = util.sshargs(sshcmd, self.host, self.user, self.port)
++args = util.sshargs(sshcmd,
++_serverquote(self.host),
++_serverquote(self.user),
++_serverquote(self.port))
+ 
+ if create:
+ cmd = '%s %s %s' % (sshcmd, args,


signature.asc
Description: Digital signature

Bug#783237: CVE-2014-9462

[Javi Merino]

On Fri, May 01, 2015 at 08:53:28PM +0200, Alessandro Ghedini wrote:
 On Fri, May 01, 2015 at 07:16:07PM +0100, Javi Merino wrote:
  On Fri, Apr 24, 2015 at 01:21:56PM +0200, Moritz Muehlenhoff wrote:
   Package: mercurial
   Severity: important
   Tags: security
   
   Please see
   http://chargen.matasano.com/chargen/2015/3/17/this-new-vulnerability-mercurial-command-injection-cve-2014-9462.html
   
   Fix:
   http://selenic.com/hg/rev/e3f30068d2eb
  
  I've prepared a fix for this, find the diff attached.  Can I upload it
  to stable-security?
 
  Index: debian/changelog
  ===
  --- debian/changelog(revisión: 11645)
  +++ debian/changelog(copia de trabajo)
  @@ -1,3 +1,11 @@
  +mercurial (3.1.2-2+deb8u1) stable-security; urgency=high
 
 Please use jessie-security instead of stable-security.

Ok

 Otherwise the upload looks good. Once the above is fixed you can go ahead and
 upload to security-master. Remember to build the package with full upstream
 sources (dpkg-buildpackage -sa), since this would be the first upload to
 jessie-security for mercurial.

Uploaded with full upstream sources.

 Also, the vulnerability seems to affect the wheezy version as well, could you
 please prepare an upload targeting wheezy-security as well?

Sure, I'll do that soon.  Cheers,
Javi


signature.asc
Description: Digital signature

Bug#783237: CVE-2014-9462

[Javi Merino]

On Fri, Apr 24, 2015 at 01:21:56PM +0200, Moritz Muehlenhoff wrote:
 Package: mercurial
 Severity: important
 Tags: security
 
 Please see
 http://chargen.matasano.com/chargen/2015/3/17/this-new-vulnerability-mercurial-command-injection-cve-2014-9462.html
 
 Fix:
 http://selenic.com/hg/rev/e3f30068d2eb

I've prepared a fix for this, find the diff attached.  Can I upload it
to stable-security?

Cheers,
Javi
Index: debian/changelog
===
--- debian/changelog	(revisión: 11645)
+++ debian/changelog	(copia de trabajo)
@@ -1,3 +1,11 @@
+mercurial (3.1.2-2+deb8u1) stable-security; urgency=high
+
+  * Fix CVE-2014-9462 by adding patch
+from_upstream__sshpeer_more_thorough_shell_quoting.patch
+(Closes: #783237)
+
+ -- Javi Merino vi...@debian.org  Fri, 01 May 2015 19:14:56 +0100
+
 mercurial (3.1.2-2) unstable; urgency=high
 
   * Fix CVE-2014-9390: Errors in handling case-sensitive directories
Index: debian/patches/series
===
--- debian/patches/series	(revisión: 11645)
+++ debian/patches/series	(copia de trabajo)
@@ -12,3 +12,4 @@
 from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch
 from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch
 from_upstream__pathauditor_check_for_Windows_shortname_aliases.patch
+from_upstream__sshpeer_more_thorough_shell_quoting.patch
Index: debian/patches/from_upstream__sshpeer_more_thorough_shell_quoting.patch
===
--- debian/patches/from_upstream__sshpeer_more_thorough_shell_quoting.patch	(revisión: 0)
+++ debian/patches/from_upstream__sshpeer_more_thorough_shell_quoting.patch	(revisión: 11887)
@@ -0,0 +1,31 @@
+Origin: http://selenic.com/hg/rev/e3f30068d2eb
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783237
+Description: sshpeer: more thorough shell quoting
+ This fixes CVE-2014-9462
+Applied-Upstream: 3.2.4
+
+diff --git a/mercurial/sshpeer.py b/mercurial/sshpeer.py
+--- a/mercurial/sshpeer.py
 b/mercurial/sshpeer.py
+@@ -20,6 +20,8 @@ class remotelock(object):
+ self.release()
+ 
+ def _serverquote(s):
++if not s:
++return s
+ '''quote a string for the remote shell ... which we assume is sh'''
+ if re.match('[a-zA-Z0-9@%_+=:,./-]*$', s):
+ return s
+@@ -45,7 +47,10 @@ class sshpeer(wireproto.wirepeer):
+ sshcmd = self.ui.config(ui, ssh, ssh)
+ remotecmd = self.ui.config(ui, remotecmd, hg)
+ 
+-args = util.sshargs(sshcmd, self.host, self.user, self.port)
++args = util.sshargs(sshcmd,
++_serverquote(self.host),
++_serverquote(self.user),
++_serverquote(self.port))
+ 
+ if create:
+ cmd = '%s %s %s' % (sshcmd, args,
+


signature.asc
Description: Digital signature

Bug#773796: wheezy-pu: package mercurial/2.2.2-4

[Javi Merino]

On Fri, Jan 02, 2015 at 08:49:31PM +, Adam D. Barratt wrote:
 Control: tags -1 +confirmed -moreinfo
 
 On Tue, 2014-12-23 at 15:24 +, Adam D. Barratt wrote:
  On 2014-12-23 14:55, Javi Merino wrote:
   On Tue, Dec 23, 2014 at 01:20:10PM +, Adam D. Barratt wrote:
   The patches look okay, but it appears that this hasn't been fixed in
   unstable yet. Is that correct? If so then we generally prefer to get
   unstable fixed first, so that the changes can get some testing there.
   
   That's correct, I'm preparing an upload for jessie.  If I upload the
   same fix to unstable, it would be unblocked?
  
  I'd be inclined to do so assuming it was in the near future, yes. Please 
  file a separate unblock bug for that.
 
 That happened now, so please feel free to go ahead with the p-u upload
 (bearing in mind that the window for getting fixes in to the 7.8 point
 release closes during this weekend).

Sorry, it fell through the cracks.  I've uploaded it now, better late
than never.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#773796: wheezy-pu: package mercurial/2.2.2-4

[Javi Merino]

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

mercurial in wheezy is affected by CVE-2014-9390[0] (Errors in
handling case-sensitive directories allow for remote code execution on
pull).  The security team says that few users are affected by it as it
only affects you if you are running on a case-sensitive filesystem.
They say it should go through stable-proposed-updates.

Upstream has said that three patches[1] need to be backported to fix
it.  I've done it for wheezy and prepared an upload, see the attached
debdiff against the current version in wheezy: 2.2.2-3.

[0] https://security-tracker.debian.org/tracker/CVE-2014-9390
[1] http://selenic.com/pipermail/mercurial-packaging/2014-December/000133.html

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru mercurial-2.2.2/debian/changelog mercurial-2.2.2/debian/changelog
--- mercurial-2.2.2/debian/changelog	2013-02-23 20:53:41.0 +0100
+++ mercurial-2.2.2/debian/changelog	2014-12-23 12:42:25.0 +0100
@@ -1,3 +1,10 @@
+mercurial (2.2.2-4) stable; urgency=high
+
+  * Security update for CVE-2014-9390: errors in handling case-sensitive
+directories allow for remote code execution on pull.
+
+ -- Javi Merino vi...@debian.org  Tue, 23 Dec 2014 12:42:20 +0100
+
 mercurial (2.2.2-3) unstable; urgency=low
 
   * Fix Backport improvement to vimdiff configuration by adding
diff -Nru mercurial-2.2.2/debian/patches/from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch mercurial-2.2.2/debian/patches/from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch
--- mercurial-2.2.2/debian/patches/from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch	1970-01-01 01:00:00.0 +0100
+++ mercurial-2.2.2/debian/patches/from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch	2014-12-23 10:33:58.0 +0100
@@ -0,0 +1,43 @@
+Origin: http://selenic.com/repo/hg-stable/rev/885bd7c5c7e3
+Description: encoding: add hfsignoreclean to clean out HFS-ignored characters
+ According to Apple Technote 1150 (unavailable from Apple as far as I
+ can tell, but archived in several places online), HFS+ ignores sixteen
+ specific unicode runes when doing path normalization. We need to
+ handle those cases, so this function lets us efficiently strip the
+ offending characters from a UTF-8 encoded string (which is the only
+ way it seems to matter on OS X.)
+ .
+ This is a fix for CVE-2014-9390
+Applied-Upstream: 3.2.3
+
+--- a/mercurial/encoding.py
 b/mercurial/encoding.py
+@@ -8,6 +8,28 @@
+ import error
+ import unicodedata, locale, os
+ 
++# These unicode characters are ignored by HFS+ (Apple Technote 1150,
++# Unicode Subtleties), so we need to ignore them in some places for
++# sanity.
++_ignore = [unichr(int(x, 16)).encode(utf-8) for x in
++   200c 200d 200e 200f 202a 202b 202c 202d 202e 
++   206a 206b 206c 206d 206e 206f feff.split()]
++# verify the next function will work
++assert set([i[0] for i in _ignore]) == set([\xe2, \xef])
++
++def hfsignoreclean(s):
++Remove codepoints ignored by HFS+ from s.
++
++ hfsignoreclean(u'.h\u200cg'.encode('utf-8'))
++'.hg'
++ hfsignoreclean(u'.h\ufeffg'.encode('utf-8'))
++'.hg'
++
++if \xe2 in s or \xef in s:
++for c in _ignore:
++s = s.replace(c, '')
++return s
++
+ def _getpreferredencoding():
+ '''
+ On darwin, getpreferredencoding ignores the locale environment and
diff -Nru mercurial-2.2.2/debian/patches/from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch mercurial-2.2.2/debian/patches/from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch
--- mercurial-2.2.2/debian/patches/from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch	1970-01-01 01:00:00.0 +0100
+++ mercurial-2.2.2/debian/patches/from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch	2014-12-23 10:33:58.0 +0100
@@ -0,0 +1,59 @@
+Origin: http://selenic.com/repo/hg-stable/rev/c02a05cc6f5e
+Description: pathauditor: check for codepoints ignored on OS X
+ This is a fix for CVE-2014-9390
+Applied-Upstream: 3.2.3
+
+--- a/tests/test-commit.t
 b/tests/test-commit.t
+@@ -216,7 +216,23 @@ subdir log
+   summary: commit-foo-subdir
+   
+   $ cd ..
+-  $ cd ..
++
++verify pathauditor blocks evil filepaths
++  $ cat  evil-commit.py EOF
++   from mercurial import ui, hg, context, node
++   notrc = u.h\u200cg.encode('utf-8') + '/hgrc'
++   u = ui.ui()
++   r = hg.repository(u, '.')
++   def filectxfn(repo, memctx

Bug#773796: wheezy-pu: package mercurial/2.2.2-4

[Javi Merino]

On Tue, Dec 23, 2014 at 01:20:10PM +, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo
 
 Hi,
 
 On 2014-12-23 12:15, Javi Merino wrote:
 mercurial in wheezy is affected by CVE-2014-9390[0] (Errors in
 handling case-sensitive directories allow for remote code execution on
 pull).  The security team says that few users are affected by it as it
 only affects you if you are running on a case-sensitive filesystem.
 They say it should go through stable-proposed-updates.
 
 Upstream has said that three patches[1] need to be backported to fix
 it.  I've done it for wheezy and prepared an upload, see the attached
 debdiff against the current version in wheezy: 2.2.2-3.
 
 [0] https://security-tracker.debian.org/tracker/CVE-2014-9390
 [1]
 http://selenic.com/pipermail/mercurial-packaging/2014-December/000133.html
 
 Thanks for looking at fixing this in stable.
 
 The patches look okay, but it appears that this hasn't been fixed in
 unstable yet. Is that correct? If so then we generally prefer to get
 unstable fixed first, so that the changes can get some testing there.

That's correct, I'm preparing an upload for jessie.  If I upload the
same fix to unstable, it would be unblocked?


signature.asc
Description: Digital signature

Bug#773847: unblock: mercurial/3.1.2-2

[Javi Merino]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mercurial.  It fixes #773640[0] (CVE-2014-9390:
Errors in handling case-sensitive directories allow for remote code
execution on pull).  Upstream has confirmed[1] that the three patches
that this update adds are the ones needed to fix it.  See below the
debdiff against 3.1.2-1, the version currently in jessie.

[0] https://bugs.debian.org/773640
[1] http://selenic.com/pipermail/mercurial-packaging/2014-December/000133.html

---8---
diff -Nru mercurial-3.1.2/debian/changelog mercurial-3.1.2/debian/changelog
--- mercurial-3.1.2/debian/changelog2014-10-03 00:34:41.0 +0200
+++ mercurial-3.1.2/debian/changelog2014-12-23 16:01:50.0 +0100
@@ -1,3 +1,15 @@
+mercurial (3.1.2-2) unstable; urgency=high
+
+  * Fix CVE-2014-9390: Errors in handling case-sensitive directories
+allow for remote code execution on pull by adding patches
+
from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch,
+from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch,
+and
+from_upstream__pathauditor_check_for_Windows_shortname_aliases.patch
+(Closes: #773640)
+
+ -- Javi Merino vi...@debian.org  Tue, 23 Dec 2014 16:01:50 +0100
+
 mercurial (3.1.2-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru 
mercurial-3.1.2/debian/patches/from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch
 
mercurial-3.1.2/debian/patches/from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch
--- 
mercurial-3.1.2/debian/patches/from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch
 1970-01-01 01:00:00.0 +0100
+++ 
mercurial-3.1.2/debian/patches/from_upstream__encoding_add_hfsignoreclean_to_clean_out_HFS-ignored_characters.patch
 2014-12-23 15:57:51.0 +0100
@@ -0,0 +1,44 @@
+Origin: http://selenic.com/repo/hg-stable/rev/885bd7c5c7e3
+Description: encoding: add hfsignoreclean to clean out HFS-ignored characters
+ According to Apple Technote 1150 (unavailable from Apple as far as I
+ can tell, but archived in several places online), HFS+ ignores sixteen
+ specific unicode runes when doing path normalization. We need to
+ handle those cases, so this function lets us efficiently strip the
+ offending characters from a UTF-8 encoded string (which is the only
+ way it seems to matter on OS X.)
+ .
+ This is a fix for CVE-2014-9390
+Applied-Upstream: 3.2.3
+
+diff --git a/mercurial/encoding.py b/mercurial/encoding.py
+--- a/mercurial/encoding.py
 b/mercurial/encoding.py
+@@ -8,6 +8,28 @@
+ import error
+ import unicodedata, locale, os
+ 
++# These unicode characters are ignored by HFS+ (Apple Technote 1150,
++# Unicode Subtleties), so we need to ignore them in some places for
++# sanity.
++_ignore = [unichr(int(x, 16)).encode(utf-8) for x in
++   200c 200d 200e 200f 202a 202b 202c 202d 202e 
++   206a 206b 206c 206d 206e 206f feff.split()]
++# verify the next function will work
++assert set([i[0] for i in _ignore]) == set([\xe2, \xef])
++
++def hfsignoreclean(s):
++Remove codepoints ignored by HFS+ from s.
++
++ hfsignoreclean(u'.h\u200cg'.encode('utf-8'))
++'.hg'
++ hfsignoreclean(u'.h\ufeffg'.encode('utf-8'))
++'.hg'
++
++if \xe2 in s or \xef in s:
++for c in _ignore:
++s = s.replace(c, '')
++return s
++
+ def _getpreferredencoding():
+ '''
+ On darwin, getpreferredencoding ignores the locale environment and
diff -Nru 
mercurial-3.1.2/debian/patches/from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch
 
mercurial-3.1.2/debian/patches/from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch
--- 
mercurial-3.1.2/debian/patches/from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch
1970-01-01 01:00:00.0 +0100
+++ 
mercurial-3.1.2/debian/patches/from_upstream__pathauditor_check_for_codepoints_ignored_on_OS_X.patch
2014-12-23 15:57:51.0 +0100
@@ -0,0 +1,59 @@
+Origin: http://selenic.com/repo/hg-stable/rev/c02a05cc6f5e
+Description: pathauditor: check for codepoints ignored on OS X
+ This is a fix for CVE-2014-9390
+Applied-Upstream: 3.2.3
+
+--- a/mercurial/pathutil.py
 b/mercurial/pathutil.py
+@@ -1,8 +1,12 @@
+ import os, errno, stat
+ 
++import encoding
+ import util
+ from i18n import _
+ 
++def _lowerclean(s):
++return encoding.hfsignoreclean(s.lower())
++
+ class pathauditor(object):
+ '''ensure that a filesystem path contains no banned components.
+ the following properties of a path are checked:
+@@ -39,11 +43,11 @@ class pathauditor(object):
+ raise util.Abort(_(path ends in directory separator: %s) % path)
+ parts = util.splitpath(path)
+ if (os.path.splitdrive(path)[0]
+-or parts[0].lower() in ('.hg', '.hg

Bug#773640: CVE-2014-9390: Errors in handling case-sensitive directories allow for remote code execution on pull

[Javi Merino]

Package: mercurial
Version: 3.1.2-1
Severity: important
Tags: security upstream

CVE-2014-9390[0][1] is a security vulnerability that affects mercurial
repositories in a case-sensitive filesystem (eg. VFAT or HFS+).  It
allows for remote code execution of a specially crafted repository.
This is less severe for the average Debian installation as they are
usually set up with case-insensitive filesystems.

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9390
[1] https://security-tracker.debian.org/tracker/CVE-2014-9390

This affects both Wheezy and Jessie.

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mercurial depends on:
ii  libc6 2.19-13
ii  mercurial-common  3.1.2-1
ii  python2.7.8-2
ii  ucf   3.0030

Versions of packages mercurial recommends:
ii  openssh-client  1:6.7p1-3

Versions of packages mercurial suggests:
pn  kdiff3 | kdiff3-qt | kompare | meld | tkcvs | mgdiff  none
pn  qct   none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773640: CVE-2014-9390: Errors in handling case-sensitive directories allow for remote code execution on pull

[Javi Merino]

On Sun, Dec 21, 2014 at 12:38:02PM +0100, Javi Merino wrote:
 Package: mercurial
 Version: 3.1.2-1
 Severity: important
 Tags: security upstream
 
 CVE-2014-9390[0][1] is a security vulnerability that affects mercurial
 repositories in a case-sensitive filesystem (eg. VFAT or HFS+).  It
 allows for remote code execution of a specially crafted repository.
 This is less severe for the average Debian installation as they are
 usually set up with case-insensitive filesystems.
 
 [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9390
 [1] https://security-tracker.debian.org/tracker/CVE-2014-9390
 
 This affects both Wheezy and Jessie.

In Ubuntu[0] they've fixed it by applying the following patches:

- http://selenic.com/repo/hg-stable/rev/035434b407be
- http://selenic.com/repo/hg-stable/rev/885bd7c5c7e3
- http://selenic.com/repo/hg-stable/rev/c02a05cc6f5e
- http://selenic.com/repo/hg-stable/rev/7a5bcd471f2e
- http://selenic.com/repo/hg-stable/rev/6dad422ecc5a

[0] https://bugs.launchpad.net/ubuntu/+source/git/+bug/1404035
[1] 
https://launchpadlibrarian.net/193058010/mercurial_3.1.2-1ubuntu1_source.changes

I'm working on applying the same patches.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768022: mercurial: 3.2 has been released

[Javi Merino]

Hi Faheem,
On Tue, Nov 11, 2014 at 06:04:55PM +0530, Faheem Mitha wrote:
 On Thu, 6 Nov 2014, Javi Merino wrote:
 On Tue, Nov 04, 2014 at 02:58:31PM +0530, Faheem Mitha wrote:
 
 Package: mercurial
 Version: 3.1.2-1~bpo70+1
 Severity: wishlist
 
 Dear Maintainer,
 
 Hi Faheem,
 
 Please consider packaging 3.2. I can build it myself, but the Debian
 patches have changed enough since the last release that they are no
 longer trivial to re-sync. If you could just refresh the patches, that
 would be helpful. Thanks.
 
 It's not as easy as refreshing the patches as you have seen.  I'm working
 on it and I hope to upload it before Sunday.  It will go to experimental
 though.
 
 I missed your email. I just saw it now. It looks like you have just uploaded
 to experimental.

I've seen that you are using the backported version.  As Jessie will
release with 3.1.2, wheezy-backports will stay with 3.1.2.  I can
upload 3.2 (well, 3.2.1, which shall be uploaded soon) to
wheezy-backports-sloppy if you are interested in it.

 If you need help with the Debian packaging, let the
 community know. There are people who can help.

The package is team-maintained, I'm just the most regular uploader.
Other people have uploaded mercurial when I was unavailable.  So yes,
I know there is a community and no, I'm not *the* maintainer but *a*
maintainer.  Cheers,
Javi


signature.asc
Description: Digital signature

Bug#768022: mercurial: 3.2 has been released

[Javi Merino]

On Tue, Nov 04, 2014 at 02:58:31PM +0530, Faheem Mitha wrote:
 Package: mercurial
 Version: 3.1.2-1~bpo70+1
 Severity: wishlist
 
 Dear Maintainer,

Hi Faheem,

 Please consider packaging 3.2. I can build it myself, but the Debian
 patches have changed enough since the last release that they are no
 longer trivial to re-sync. If you could just refresh the patches, that
 would be helpful. Thanks.

It's not as easy as refreshing the patches as you have seen.  I'm
working on it and I hope to upload it before Sunday.  It will go to
experimental though.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#764611: sonata: fails to launch since GLib upgrade to 2.42

[Javi Merino]

On Mon, Oct 13, 2014 at 10:36:08PM +0200, Dave wrote:
 I’m modifying the severity of the bug because sonata is no longer
 seriously broken.
 
 Here is a quote from libgtk2.0-0 changelog which could help the
 maintainers of sonata:

Thanks for tracking this!  I've been very busy recently and didn't
have time to look at this.  I'll package the latest alpha for unstable
once jessie is released in the hopes that it'll be in a stable state
for jessie+1 and will make sure that this is fixed upstream.

Thanks again,
Javi

 gtk+2.0 (2.24.25-1) unstable; urgency=medium
 (…)
 * New upstream release
 - tolerates incorrect use of gtk_main() after initializing threads with
 gtk_init() but before taking the lock with gdk_threads_enter(), which
 has historically worked on GNU systems because glibc's mutexes are more
 permissive than the new implementation in GLib 2.42
 (Closes: #758619, #763602, #763625, #763690, #763735, but the affected
 packages should still use Gdk's threading API properly)
 (…)
  -- Simon McVittie s...@debian.org  Fri, 10 Oct 2014 18:33:05 +0100


signature.asc
Description: Digital signature

Bug#760230: ITP: python-sk1libs -- Set of python non-GUI extensions for sK1 Project

[Javi Merino]

On Tue, Sep 02, 2014 at 11:58:18AM +0200, Agustin Martin wrote:
 On Mon, Sep 01, 2014 at 03:54:31PM -0700, Javi Merino wrote:
  Package: wnpp
  Severity: wishlist
  Owner: Javi Merino vi...@debian.org
  
  * Package name: python-sk1libs
Version : 0.9.1
Upstream Author : Igor E. Novikov igor.e.novi...@gmail.com
  * URL : 
  http://sk1project.org/modules.php?name=Productsproduct=sk1
  * License : LGPL-2+
Programming Lang: Python, C
Description : Set of python non-GUI extensions for sK1 Project
  
  sk1libs is a set of python non-GUI extensions for sK1 Project.
  The package includes multiplatform non-GUI extensions which are
  usually native extensions.
  
  This package is a dependency of the new upstream version of
  python-uniconvertor .  It'll be maintained in the Python Modules Team.
 
 Hi, Javi,
 
 Note that original sources name is sk1libs, even if I named my git repo
 python-sk1libs. sk1libs is also what is used in my pristine-tar branch.

I know, but I've changed the source package name to python-sk1libs to
make it consistent with the binary package.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#699301: Bug#644559: O: python-uniconvertor -- Universal vector graphics translator

[Javi Merino]

Hi Agustin,

On Mon, 22 Jul 2013 18:11:57 +0200 Agustin Martin agmar...@debian.org wrote:
 On Wed, Jan 16, 2013 at 03:36:56PM -0200, Ronoaldo Jos� de Lana Pereira 
 wrote: 
  2013/1/15 Mathieu Malaterre ma...@debian.org
  
   Ronoaldo,
  
 Do you still have interest in python-uniconvertor ? Apparently
   updating to 1.1.5 is somewhat difficult since it now needs a new
   dependency:
  
   http://ubuntuforums.org/showthread.php?p=11371010#post11371010
  
 
  Mathieu,
  
  Indeed, I do want to help maitaining it.
  
  I'll join the team suggested before and try working on it while I'm still
  testing Wheezy.
 
 Forgot to cc this bug report and interested people when sending a followup
 to #699301 and #592840 (cc'ed now).
 
 http://bugs.debian.org/699301
 http://bugs.debian.org/592840
 
 The short story, I have been playing on building a 1.1.5 python-uniconvertor
 package together with a new package python-sk1libs, the new dependency.
 I did a minimal testing and resulting package seems to work, but this is my
 first approach to python and everything I did needs extensive reviewing by
 someone fluent with python, long story in above bug reports.
 
 I do not intend to adopt this package, so you may be interested in my
 changes in
 
 http://anonscm.debian.org/gitweb/?p=users/agmartin/TMP/python-sk1libs.git;a=summary
 http://anonscm.debian.org/gitweb/?p=users/agmartin/TMP/python-uniconvertor.git;a=summary
 
 Note that python-modules team seems to have SVN as preferred VCS (fix me if 
 this is no longer true)

I'm looking into importing your packaging of python-sk1libs and
python-uniconvertor into the Python Modules team and fixing #699301 at
last.  In your email you state that you don't want to adopt the
package but python-sk1libs/debian/control shows you as maintainer.
Are you ok with me changing that to the Debian Python Modules team?

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#760230: ITP: python-sk1libs -- Set of python non-GUI extensions for sK1 Project

[Javi Merino]

Package: wnpp
Severity: wishlist
Owner: Javi Merino vi...@debian.org

* Package name: python-sk1libs
  Version : 0.9.1
  Upstream Author : Igor E. Novikov igor.e.novi...@gmail.com
* URL : http://sk1project.org/modules.php?name=Productsproduct=sk1
* License : LGPL-2+
  Programming Lang: Python, C
  Description : Set of python non-GUI extensions for sK1 Project

sk1libs is a set of python non-GUI extensions for sK1 Project.
The package includes multiplatform non-GUI extensions which are
usually native extensions.

This package is a dependency of the new upstream version of
python-uniconvertor .  It'll be maintained in the Python Modules Team.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#759775: ImportError: No module named cmds

[Javi Merino]

Control: tags 759775 unreproducible

On Sat, Aug 30, 2014 at 09:34:58AM +0200, Joerg wrote:
 Package: trash-cli
 Version: 0.12.9.14-1
 Severity: important
 
 Dear Maintainer,
 
 With the new version I can't put any file to trash bin anymore.
 
 /usr/bin/trash-put tobedeleted 
 Traceback (most recent call last):
   File /usr/bin/trash-put, line 4, in module
   from trashcli.cmds import put as main
   ImportError: No module named cmds

There seems to be something wrong in your system.  I've tried this
several times in my system and in a clean chroot and it works.

After installing the package, does
/usr/lib/python2.7/dist-packages/trashcli/cmds.py exist?  It should,
it's part of the package.

Does the output of python -c 'import sys; print(sys.path)'?  Does it
include /usr/lib/python2.7/dist-packages ?

Do you have any other trashcli in the other paths in sys.path?

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#759750: RFP: python-within -- A collection of python context managers

[Javi Merino]

Package: wnpp
Severity: wishlist

* Package name: python-within
  Version : 0.2.2
  Upstream Author : Brendan Curran-Johnson bren...@bcjbcj.ca
* URL : https://pypi.python.org/pypi/within/0.2.2
* License : MIT
  Programming Lang: Python
  Description : A collection of python context managers

python-within is a collection of context managers designed to make
everyday tasks simpler and safer to perform.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756018: mercurial: hg clone hangs after adding changesets

[Javi Merino]

On Thu, Aug 14, 2014 at 11:51:32AM +0200, Vincent Lefevre wrote:
 On 2014-08-14 09:38:05 +0200, Pierre-Yves David wrote:
  O Fri, Jul 25, 2014 at 03:22:05PM +0200, Vincent Lefevre wrote:
   $ hg clone http://dev.mutt.org/hg/mutt
   destination directory: mutt
   requesting all changes
   adding changesets
   
   Then hg is hanging. The CPU, disk and network activity is very low.
  
  Looks like the network died.
 
 Perhaps, but in this case, there should be a timeout and an error
 message.
 
 In case the network didn't completely die, hg could also give progress
 information (see what curl and apt-get do, for instance) and tell how
 many seconds (when this is large enough) since it last received data
 (a bit like mosh).
 
 Giving absolutely no information is bad for the user, who cannot know
 what to do: Wait? Abort?
 
  Can you try again with --debug?
 
 Unfortunately I can't reproduce the problem.

I can't reproduce it either.  If you can't reproduce it any more, can
you close the bug?

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#756018: mercurial: hg clone hangs after adding changesets

[Javi Merino]

On Mon, Aug 25, 2014 at 06:41:39PM +0200, Vincent Lefevre wrote:
 On 2014-08-25 09:28:23 -0700, Javi Merino wrote:
  On Thu, Aug 14, 2014 at 11:51:32AM +0200, Vincent Lefevre wrote:
   On 2014-08-14 09:38:05 +0200, Pierre-Yves David wrote:
Can you try again with --debug?
   
   Unfortunately I can't reproduce the problem.
  
  I can't reproduce it either.  If you can't reproduce it any more, can
  you close the bug?
 
 I could reproduce it twice. Once with the progress indicator
 and without --debug:

In that case, can you file a bug upstream?

http://bz.selenic.com/enter_bug.cgi

I sometimes do that for bugs that I can reproduce but in this case I
don't think I'd be able to reply to questions from developers if they
had any.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#750444: [Python-apps-team] Bug#750444: mercurial: Doesn't work

[Javi Merino]

On Tue, Jun 03, 2014 at 03:21:22PM +0200, Jakub Wilk wrote:
 * Christian Marillat maril...@debian.org, 2014-06-03, 14:47:
 AttributeError: httpsconnection instance has no attribute '_set_hostport'
 
 Patch:
 http://hg.intevation.org/mercurial/crew/rev/21b3513d43e4

I'm unable to reproduce this with mercurial 3.0.  In any case, that
patch is part of mercurial 3.0.1, which I'll upload soon.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#750871: Bug 750871 - patch

[Javi Merino]

Control: tags -1 - pending + wontfix

On Sat, Jun 07, 2014 at 09:35:43PM +0100, Max Bowsher wrote:
 The problem here is that some manual sed hackery munging the /usr/bin/hg
 shebang was removed in PAPT SVN r10748, with the justification that
 dh_python2 would take care of it automatically.
 
 Unfortunately, it was not considered that the package currently circumvents
 large portions of dh_python2's multiple python version support by calling
 the upstream Makefile instead of setup.py.

My guess is that the dh_python2 in sid doesn't have the problem
described in the bug, that's why I didn't see it.

 Fortunately the solution is relatively simple:
 
 * Drop package-local Makefile constructs handling multiple python versions

True, that needs to be simplified.  It's been in my todo list for a
while now.

 * Explicitly call the python_distutils debhelper buildsystem plugin

No, this is not a good idea.

 * Use override hooks to call only the upstream Makefile targets which handle
 non-distutils parts of the build.

I don't want to replicate upstream's Makefile in debian/rules.  Today
this may mean calling make doc and make tests by hand but you
never know what can change in upstream's Makefile that will be lost
because we're not using it any more.  Mercurial is meant to be built
using the Makefile so calling distutils directly should be reduced to
the minimum.

Faheem, as I understand it, the backport version of the package will need
to reverse apply r10748 [1]

http://anonscm.debian.org/viewvc/python-apps/packages/mercurial/trunk/debian/rules?r1=10311r2=10748pathrev=10748

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#724345: ITA: subvertpy -- Alternative Python bindings for Subversion

[Javi Merino]

On Sun, Mar 23, 2014 at 02:38:40PM +, Jelmer Vernooij wrote:
 On Sun, Mar 23, 2014 at 09:52:24AM +, Javi Merino wrote:
  On Sat, Mar 22, 2014 at 04:51:10PM +, Jelmer Vernooij wrote:
   On Sat, Mar 22, 2014 at 04:26:32PM +, Javi Merino wrote:
Jelmer Vernooij wrote:
 I request an adopter for the subvertpy package. It's a fairly low
 maintenance package; I no longer use it myself. I'll keep maintaining 
 it
 in the mean time, but it'd probably be better if somebody else took
 over.

I'd like to adopt this package and put it under the Python Modules
Team umbrella.  I've had a quick look and it's in a pretty good shape,
impressive for a package that's up for adoption, thanks!  All I can
think of doing is converting it to pybuilder to simplify a bit the
debian/rules .  I may do it just to justify the upload that changes
the Maintainer field ;)
   Thanks! Moving it under the Python Modules Team umbrella seems
   reasonable. Do they support Git as VCS these days?
  
  No, unfortunately it's still svn.  I use git-svn and git-buildpackage
  with some packages though.
  
   Would you mind me staying Co-Maintainer?
  
  Of course you can be co-maintainer!  Would you mind if I moved it to
  the Python Modules Team svn though?
 
 Hmm, maybe I should hold on to the package for a little while longer.
 I'd rather not see the history lost because of importing to svn. I can
 move it into the Python Modules Team once they migrate to Git.

Ok, so shall we migrate it to git then?


signature.asc
Description: Digital signature

Bug#724345: ITA: subvertpy -- Alternative Python bindings for Subversion

[Javi Merino]

On Sat, Mar 22, 2014 at 04:51:10PM +, Jelmer Vernooij wrote:
 Hi Javi,
 
 On Sat, Mar 22, 2014 at 04:26:32PM +, Javi Merino wrote:
  Jelmer Vernooij wrote:
   I request an adopter for the subvertpy package. It's a fairly low
   maintenance package; I no longer use it myself. I'll keep maintaining it
   in the mean time, but it'd probably be better if somebody else took
   over.
  
  I'd like to adopt this package and put it under the Python Modules
  Team umbrella.  I've had a quick look and it's in a pretty good shape,
  impressive for a package that's up for adoption, thanks!  All I can
  think of doing is converting it to pybuilder to simplify a bit the
  debian/rules .  I may do it just to justify the upload that changes
  the Maintainer field ;)
 Thanks! Moving it under the Python Modules Team umbrella seems
 reasonable. Do they support Git as VCS these days?

No, unfortunately it's still svn.  I use git-svn and git-buildpackage
with some packages though.

 What is pybuilder? I don't think I've come across it before.

I meant pybuild.  It's fairly recent.  It's an easy way of making
packages that support multiple versions of python and removes most of
the pyversions loops in debian/rules:

https://wiki.debian.org/Python/Pybuild

 Would you mind me staying Co-Maintainer?

Of course you can be co-maintainer!  Would you mind if I moved it to
the Python Modules Team svn though?

Cheers,
Javi




signature.asc
Description: Digital signature

Bug#742080: closed by Javi Merino vi...@debian.org (Bug#742080: fixed in hgsubversion 1.6-0.2)

[Javi Merino]

Control: reopen -1
Control: found 1.6-0.2

1.6-0.2 fixed the issue for repositories that don't follow the
standard layout only.  If you from a repository that follows the
standard svn layout (i.e., with a trunk/ tags/ and branches/
directory) still fails:

# hg clone --traceback svn://localhost/celesteville 
   
destination directory: celesteville
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 134, in 
_runcatch
return _dispatch(req)
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 806, in 
_dispatch
cmdpats, cmdoptions)
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 586, in 
runcommand
ret = _runcommand(ui, options, cmd, d)
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 897, in 
_runcommand
return checkargs()
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 868, in 
checkargs
return cmdfunc()
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 803, in 
lambda
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 511, in check
return func(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/mercurial/extensions.py, line 151, in 
wrap
util.checksignature(origfn), *args, **kwargs)
  File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 511, in check
return func(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/hgsubversion/wrappers.py, line 596, 
in clone
orig(ui, source, dest, **opts)
  File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 511, in check
return func(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/mercurial/commands.py, line 1310, in 
clone
branch=opts.get('branch'))
  File /usr/lib/python2.7/dist-packages/mercurial/extensions.py, line 196, in 
wrap
return wrapper(origfn, *args, **kwargs)
  File /usr/lib/python2.7/dist-packages/hgsubversion/wrappers.py, line 585, 
in hgclonewrapper
data['srcrepo'], data['dstrepo'] = orig(ui, *args, **opts)
  File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 374, in clone
destpeer.local().clone(srcpeer, heads=revs, stream=stream)
  File /usr/lib/python2.7/dist-packages/mercurial/localrepo.py, line 2402, in 
clone
return self.pull(remote, heads)
  File /usr/lib/python2.7/dist-packages/hgsubversion/svnrepo.py, line 81, in 
wrapper
return fn(self, *args, **opts)
  File /usr/lib/python2.7/dist-packages/hgsubversion/svnrepo.py, line 104, in 
pull
return wrappers.pull(self, remote, heads, force)
  File /usr/lib/python2.7/dist-packages/hgsubversion/wrappers.py, line 423, 
in pull
tbdelta = meta.update_branch_tag_map_for_rev(r)
  File /usr/lib/python2.7/dist-packages/hgsubversion/svnmeta.py, line 441, in 
update_branch_tag_map_for_rev
t_name = self.get_path_tag(p)
  File /usr/lib/python2.7/dist-packages/hgsubversion/svnmeta.py, line 259, in 
get_path_tag
return self.layoutobj.get_path_tag(path, self.taglocations)
  File /usr/lib/python2.7/dist-packages/hgsubversion/svnmeta.py, line 249, in 
taglocations
return self.layoutobj.taglocations(self.meta_data_dir)
  File /usr/lib/python2.7/dist-packages/hgsubversion/layouts/standard.py, 
line 60, in taglocations
from hgext_hgsubversion import util
  File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 111, 
in _demandimport
return _hgextimport(_import, name, globals, locals, fromlist, level)
  File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 43, 
in _hgextimport
return importfunc(name, globals, *args)
ImportError: No module named hgext_hgsubversion
abort: No module named hgext_hgsubversion!

This patch from upstream fixes it:

https://bitbucket.org/durin42/hgsubversion/commits/0f16e11b2c2bccb2f92d5f9a741d031eac344769?at=default

Cheers,
Javi

On Sat, Mar 22, 2014 at 03:21:25PM +, Debian Bug Tracking System wrote:
 Source: hgsubversion
 Source-Version: 1.6-0.2
 
 We believe that the bug you reported is fixed in the latest version of
 hgsubversion, which is due to be installed in the Debian FTP archive.
 
 A summary of the changes between this version and the previous one is
 attached.
 
 Thank you for reporting the bug, which will now be closed.  If you
 have further comments please address them to 742...@bugs.debian.org,
 and the maintainer will reopen the bug report if appropriate.
 
 Debian distribution maintenance software
 pp.
 Javi Merino vi...@debian.org (supplier of updated hgsubversion package)
 
 (This message was generated automatically at their request; if you
 believe that there is a problem with it please contact the archive
 administrators by mailing ftpmas...@ftp-master.debian.org)
 
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Format: 1.8
 Date: Sat, 22 Mar 2014 14:18:29 +
 Source: hgsubversion

Bug#724345: ITA: subvertpy -- Alternative Python bindings for Subversion

[Javi Merino]

Hi Jelmer,

Jelmer Vernooij wrote:
 I request an adopter for the subvertpy package. It's a fairly low
 maintenance package; I no longer use it myself. I'll keep maintaining it
 in the mean time, but it'd probably be better if somebody else took
 over.

I'd like to adopt this package and put it under the Python Modules
Team umbrella.  I've had a quick look and it's in a pretty good shape,
impressive for a package that's up for adoption, thanks!  All I can
think of doing is converting it to pybuilder to simplify a bit the
debian/rules .  I may do it just to justify the upload that changes
the Maintainer field ;)

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#742080: hgsubversion: some commands (like clone) fail

[Javi Merino]

Package: hgsubversion
Version: 1.6-0.1
Severity: important
Tags: patch

Some commands fail with hgsubversion 1.6.  For example clone:

$ hg --traceback --config extensions.hgsubversion= clone svn://127.0.0.1/babar
destination directory: babar
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 134, in 
_runcatch
return _dispatch(req)
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 806, in 
_dispatch
cmdpats, cmdoptions)
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 586, in 
runcommand
ret = _runcommand(ui, options, cmd, d)
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 897, in 
_runcommand
return checkargs()
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 868, in 
checkargs
return cmdfunc()
  File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 803, in 
lambda
d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 511, in check
return func(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/mercurial/extensions.py, line 151, in 
wrap
util.checksignature(origfn), *args, **kwargs)
  File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 511, in check
return func(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/hgext/hgsubversion/wrappers.py, line 
596, in clone
orig(ui, source, dest, **opts)
  File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 511, in check
return func(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/mercurial/commands.py, line 1310, in 
clone
branch=opts.get('branch'))
  File /usr/lib/python2.7/dist-packages/mercurial/extensions.py, line 196, in 
wrap
return wrapper(origfn, *args, **kwargs)
  File /usr/lib/python2.7/dist-packages/hgext/hgsubversion/wrappers.py, line 
585, in hgclonewrapper
data['srcrepo'], data['dstrepo'] = orig(ui, *args, **opts)
  File /usr/lib/python2.7/dist-packages/mercurial/hg.py, line 374, in clone
destpeer.local().clone(srcpeer, heads=revs, stream=stream)
  File /usr/lib/python2.7/dist-packages/mercurial/localrepo.py, line 2402, in 
clone
return self.pull(remote, heads)
  File /usr/lib/python2.7/dist-packages/hgext/hgsubversion/svnrepo.py, line 
81, in wrapper
return fn(self, *args, **opts)
  File /usr/lib/python2.7/dist-packages/hgext/hgsubversion/svnrepo.py, line 
104, in pull
return wrappers.pull(self, remote, heads, force)
  File /usr/lib/python2.7/dist-packages/hgext/hgsubversion/wrappers.py, line 
370, in pull
repo.ui)
  File /usr/lib/python2.7/dist-packages/hgext/hgsubversion/layouts/detect.py, 
line 31, in layout_from_subversion
from hgsubversion import svnwrap
  File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 111, 
in _demandimport
return _hgextimport(_import, name, globals, locals, fromlist, level)
  File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 43, 
in _hgextimport
return importfunc(name, globals, *args)
ImportError: No module named hgsubversion
abort: No module named hgsubversion!

The attached patch fixes it for me.

Cheers,
Javi

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages hgsubversion depends on:
ii  mercurial 2.9.1-1
ii  python2.7.5-5
ii  python-subvertpy  0.9.1-5
ii  subversion1.8.8-1

hgsubversion recommends no packages.

hgsubversion suggests no packages.

-- no debconf information
# HG changeset patch
# Parent 7d47a0f731354505ed9ae8d60d2a6996e8c3294f

diff --git a/hgsubversion/layouts/detect.py b/hgsubversion/layouts/detect.py
--- a/hgsubversion/layouts/detect.py
+++ b/hgsubversion/layouts/detect.py
@@ -26,7 +26,7 @@ def layout_from_subversion(svn, revision
 
 # import late to avoid trouble when running the test suite
 try:
-from hgext_hgsubversion import svnwrap
+from hgext.hgsubversion import svnwrap
 except ImportError:
 from hgsubversion import svnwrap
 
diff --git a/hgsubversion/layouts/standard.py b/hgsubversion/layouts/standard.py
--- a/hgsubversion/layouts/standard.py
+++ b/hgsubversion/layouts/standard.py
@@ -57,7 +57,7 @@ class StandardLayout(base.BaseLayout):
 
 def taglocations(self, meta_data_dir):
 # import late to avoid trouble when running the test suite
-from hgext_hgsubversion import util
+from hgext.hgsubversion import util
 
 if self._tag_locations is None:
 

Bug#740672: hgsubversion: New upstream version 1.6

[Javi Merino]

Package: hgsubversion
Version: 1.5-1
Severity: wishlist

mercurial = 2.9 doesn't work with hgsubversion 1.5.  Please upgrade
hgsubversion to 1.6.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages hgsubversion depends on:
ii  mercurial 2.9.1-1
ii  python2.7.5-5
pn  python-subvertpy | python-subversion  none
ii  subversion1.8.8-1

hgsubversion recommends no packages.

hgsubversion suggests no packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735578: mercurial: autopkgtest testsuite fails on stderr, hgsubversion requires network access

[Javi Merino]

retitle -1 autopkgtest hgsubversion shouldn't need network connectivity
severity -1 wishlist
thanks

On Tue, Feb 11, 2014 at 06:50:43AM +0100, Martin Pitt wrote:
 Hey Javi,

Hi Martin,

 Javi Merino [2014-02-10 22:31 +]:
  In Ubuntu's CI machinery we don't have access to outside servers
  like alioth.
 
 Actually, we recently fixed that by setting correct $http[s]_proxy
 variables. So as long as mercurial respects those, it should actually
 work now. (Just FYI)
 
  Would you accept a patch that sets up a local svn repository with
  some example commits and then imports from that? This makes the
  test independent of network, connectivity, or alioth problems, and
  as autopkgtest is primarily meant to be a do I have everything
  required in the package smoketest, it should suffice.
  
  I'd definitely accept it.  I don't really like the current test for
  hgsubversion, it's just the best I could come up with.
 
 Ack, thanks. I'll keep that on my list.

Ok, I'm lowering the priority of the bug to wishlist, as it's
something we'd like to improve in the package but not urgent.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#732153: mercurial: Broken state of the repository after VPN connection was dropped during push

[Javi Merino]

tags 732153 upstream
thanks

On Sat, Dec 14, 2013 at 08:30:13PM +, Grzegorz Andruszkiewicz wrote:
 Package: mercurial
 Version: 2.2.2-3
 Severity: normal
 
 Dear Maintainer,
 
 I was running hg push, and in the middle I dropped the VPN connection. The hg
 push command hang. After I killed it, the repository was is left in an
 inconsistent state. Miraculously the data managed to be transferred to the
 server, and a hg pull and hg update sorted things out.

This is an upstream bug.  Normally I would report it upstream but I
can't reproduce it.  If you'd like to report it in the mercurial bts,
it's here:

http://bz.selenic.com/buglist.cgi?product=Mercurialcomponent=Mercurialresolution=---list_id=3754

Bear in mind that upstream will probably ask you to reproduce it in a
more recent version of mercurial, 2.2.2 is ancient by their standards.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#735578: mercurial: autopkgtest testsuite fails on stderr, hgsubversion requires network access

[Javi Merino]

On Thu, Jan 16, 2014 at 05:19:16PM +0100, Martin Pitt wrote:
 Package: mercurial
 Version: 2.8.1-2
 User: autopkgtest-de...@lists.alioth.debian.org
 Usertags: autopkgtest
 
 Hello,

Hi Martin,

 mercurial's autopkgtest currently fails [1] in two different ways:
 
  * testsuite:
 
| adt-run:  dsc0t-testsuite:  - - - - - - - - - - stderr - - - - - - - - 
 - -
| warning: Tested with unexpected mercurial lib: 
 /usr/lib/python2.7/dist-packages/mercurial
| (expected /usr/bin/mercurial)
 
autopkgtests must not write anything to stderr by default, so that
unexpected warnings etc. are caught. If this is expected and cannot
easily be suppressed, then you can add Restrictions: allow-stderr
to its control stanza, as in attached debdiff.

Applied, will be in mercurial-2.9-1.  Thanks!

  * hgsubversion:
 
In Ubuntu's CI machinery we don't have access to outside servers
like alioth. This of course does not directly affect Debian, I
mostly mentioned it to explain why I disabled that particular test
in Ubuntu in case you wonder.
 
Would you accept a patch that sets up a local svn repository with
some example commits and then imports from that? This makes the
test independent of network, connectivity, or alioth problems, and
as autopkgtest is primarily meant to be a do I have everything
required in the package smoketest, it should suffice.

I'd definitely accept it.  I don't really like the current test for
hgsubversion, it's just the best I could come up with.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#729153: mercurial: fails to build from source on stable.

[Javi Merino]

On Sat, Nov 09, 2013 at 10:03:40PM +0530, Faheem Mitha wrote:
 Package: mercurial
 Version: 2.8-1
 Severity: normal
 
 Hi. I tried to rebuild 2.8 from source as stable as I usually do. I
 comment out the
 
 override_dh_auto_test:
 
 stanza because the tests often fail, but otherwise don't change anything.

You could do DEB_BUILD_OPTIONS=nocheck instead.  Anyway, the
testsuite should pass, it always passes in my computer and only fails
in some slow buildds.

 I got
 
 # Move templates and help installed by setup.py to their FHS-correct location
 mv 
 /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/templates
  
 /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/help
  
 /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial
 mv: cannot move 
 `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python2.7/dist-packages/mercurial/templates'
  to 
 `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial/templates':
  Directory not empty
 mv: cannot move 
 `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python2.7/dist-packages/mercurial/help'
  to 
 `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial/help':
  Directory not empty
 make[2]: *** [install-archindep] Error 1
 make[2]: Leaving directory `/usr/local/src/mercurial/mercurial-2.8'
 make[1]: *** [override_dh_install] Error 2
 make[1]: Leaving directory `/usr/local/src/mercurial/mercurial-2.8'
 make: *** [binary] Error 2
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
 2
 debuild: fatal error at line 1357:
 dpkg-buildpackage -rfakeroot -D -us -uc failed
 
 I'm not sure why this is happening, and haven't really investigated
 it. Any ideas?

What command do you use to build it?  2.8-1 and 2.8-2 build fine on my
machine and on the buildds, the only current failure are a couple of
timeouts in the testsuite in mips.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#729153: mercurial: fails to build from source on stable.

[Javi Merino]

control: tags -1 + moreinfo
control: severity -1 minor

2013/11/17 Javi Merino vi...@debian.org:
 On Sat, Nov 09, 2013 at 10:03:40PM +0530, Faheem Mitha wrote:
 I got

 # Move templates and help installed by setup.py to their FHS-correct location
 mv 
 /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/templates
  
 /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/help
  
 /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial
 mv: cannot move 
 `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python2.7/dist-packages/mercurial/templates'
  to 
 `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial/templates':
  Directory not empty
 mv: cannot move 
 `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python2.7/dist-packages/mercurial/help'
  to 
 `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial/help':
  Directory not empty
 make[2]: *** [install-archindep] Error 1
 make[2]: Leaving directory `/usr/local/src/mercurial/mercurial-2.8'
 make[1]: *** [override_dh_install] Error 2
 make[1]: Leaving directory `/usr/local/src/mercurial/mercurial-2.8'
 make: *** [binary] Error 2
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
 status 2
 debuild: fatal error at line 1357:
 dpkg-buildpackage -rfakeroot -D -us -uc failed

 I'm not sure why this is happening, and haven't really investigated
 it. Any ideas?

 What command do you use to build it?  2.8-1 and 2.8-2 build fine on my
 machine and on the buildds, the only current failure are a couple of
 timeouts in the testsuite in mips.

I've just done this in a wheezy chroot:

apt-get source -t sid mercurial
cd mercurial-2.8/
dch --bpo
debuild -us -uc

And it built mercurial_2.8-2~bpo70+1_amd64.deb and
mercurial-common_2.8-2~bpo70+1_all.deb that install and seem to work
fine in wheezy.  So I don't know what you're doing, all I can say is
that it works for me.

Cheers,
Javi


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718428: completion: diff -c tab should trigger labels

[Javi Merino]

control: forwarded -1 http://bz.selenic.com/show_bug.cgi?id=4100
control: tags -1 + upstream

2013/7/31 Matthew Gabeler-Lee chee...@fastcat.org:
 Package: mercurial
 Version: 2.6.2-1
 Severity: minor

 Invoking completion after the -c argument to diff should invoke the labels
 (branches, tags, bookmarks, ...) completion, not file completion as it does
 now.

 Not sure if other mercurial commands have an equivalent -c argument, diff is
 the only one that comes to mind.

We use the bash-completion script from upstream so I've forwarded this
to the upstream bts[0].  If you have any more comments on this, please
make them there.

[0] http://bz.selenic.com/show_bug.cgi?id=4100


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729788: dgit doesn't work if the user has set LANG in their environment

[Javi Merino]

Package: dgit
Version: 0.18
Severity: normal

When ssh'ing to coccia, ssh preserves the environment, so the reply
from the database is in the user's language instead of English and
dgit fails to parse it:

$ dgit clone dgit
(1 fila) ? at /usr/bin/dgit line 669.
$ LANG=C dgit clone dgit
canonical suite name for unstable is sid
[...]

I guess dgit should set LANG=C when doing the ssh.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dgit depends on:
ii  devscripts 2.13.4
ii  dpkg-dev   1.17.1
ii  git [git-core] 1:1.8.4.3-1
ii  git-core   1:1.8.4.3-1
ii  libdpkg-perl   1.17.1
ii  libwww-perl6.05-1
ii  perl [libdigest-sha-perl]  5.18.1-4
ii  realpath   1.19

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:6.4p1-1

Versions of packages dgit suggests:
pn  sbuild  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729807: dgit should depend on ssh-client

[Javi Merino]

Package: dgit
Version: 0.18
Severity: normal

As dgit ssh's to coccia, it should depend on ssh-client.  If you
install it in a clean chroot you get:

$ dgit clone dgit
Can't exec ssh: No such file or directory at /usr/bin/dgit line 660.
No such file or directory at /usr/bin/dgit line 660.
$

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dgit depends on:
ii  devscripts 2.13.4
ii  dpkg-dev   1.17.1
ii  git [git-core] 1:1.8.4.3-1
ii  git-core   1:1.8.4.3-1
ii  libdpkg-perl   1.17.1
ii  libwww-perl6.05-1
ii  perl [libdigest-sha-perl]  5.18.1-4
ii  realpath   1.19

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:6.4p1-1

Versions of packages dgit suggests:
pn  sbuild  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729788: dgit doesn't work if the user has set LANG in their environment

[Javi Merino]

2013/11/17 Ian Jackson ijack...@chiark.greenend.org.uk:
 Javi Merino writes (Bug#729788: dgit doesn't work if the user has set LANG 
 in their environment):
 When ssh'ing to coccia, ssh preserves the environment, so the reply
 from the database is in the user's language instead of English and
 dgit fails to parse it:

 $ dgit clone dgit
 (1 fila) ? at /usr/bin/dgit line 669.
 $ LANG=C dgit clone dgit
 canonical suite name for unstable is sid
 [...]

 I guess dgit should set LANG=C when doing the ssh.

 Thanks for the report.  Sorry about that.  I think you have the right
 idea.

 Can you try this patch (below) applied to your dgit ?

 NB that it's probably going to fall over right now just after the
 archive query, because alioth (git.debian.org) is down.

 But I think the patch will enable it to get further, and if you send
 me the -D output I'll be able to confirm whether the patch has fixed
 the problem.

Yes, that patch fixes it.  Alioth is down but now dgit gets to the
point of trying to access alioth, so the patch solves the issue:

$ printenv LANG
es_ES.UTF-8
$  dgit -D clone dgit
| ssh coccia.debian.org 'export LANG=C; psql -A service=projectb -c
'\''SELECT suite.codename
  FROM suite where
suite_name='\'''\\''\'''\''unstable'\'''\\''\'''\'' or
codename='\'''\\''\'''\''unstable'\'''\\''\'''\'';
'\'''
|codename|
|sid|
|(1 row)|
canonical suite name for unstable is sid
CD dgit
+ git init -q
+ git config remote.dgit.fetch '+refs/dgit/*:refs/remotes/dgit/dgit/*'
+ git remote add origin 'git+ssh://git.debian.org/git/dgit-repos/repos/dgit.git'
| ssh git.debian.org ' set -e; cd /git/dgit-repos/repos; if test -d
dgit.git; then echo 1; else echo 0; fi'
bash: line 0: cd: /git/dgit-repos/repos: No such file or directory
=!256
ssh: failed command: ssh git.debian.org ' set -e; cd
/git/dgit-repos/repos; if test -d dgit.git; then echo 1; else echo 0;
fi'
dgit: subprocess failed with error exit status 1


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728230: hg crashed with Exception in throw(): an unhandled exception

[Javi Merino]

On Tue, Oct 29, 2013 at 12:45:15PM -0700, Mykola Nikishov wrote:
 Package: mercurial
 Version: 2.7.2-1
 
 
 =
 
 ProblemType: Crash
 Architecture: i386
 Date: Thu Oct 24 01:23:54 2013
 Dependencies:
 [...]
 Title: hg crashed with Exception in throw(): an unhandled exception
 Traceback:
  Traceback (most recent call last):
File /usr/bin/hg, line 38, in module
  mercurial.dispatch.run()
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 28, in 
 run
  sys.exit((dispatch(request(sys.argv[1:])) or 0)  255)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 69, in 
 dispatch
  ret = _runcatch(req)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 97, in 
 _runcatch
  return _dispatch(req)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 778, 
 in _dispatch
  cmdpats, cmdoptions)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 549, 
 in runcommand
  ret = _runcommand(ui, options, cmd, d)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 869, 
 in _runcommand
  return checkargs()
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 840, 
 in checkargs
  return cmdfunc()
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 775, 
 in lambda
  d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 507, in 
 check
  return func(*args, **kwargs)
File /usr/lib/python2.7/dist-packages/mercurial/commands.py, line 5156, 
 in serve
  return s.serve()
File /usr/lib/python2.7/dist-packages/mercurial/commandserver.py, line 
 231, in serve
  while self.serveone():
File /usr/lib/python2.7/dist-packages/mercurial/commandserver.py, line 
 211, in serveone
  handler(self)
File /usr/lib/python2.7/dist-packages/mercurial/commandserver.py, line 
 194, in runcommand
  ret = dispatch.dispatch(req) or 0 # might return None
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 69, in 
 dispatch
  ret = _runcatch(req)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 97, in 
 _runcatch
  return _dispatch(req)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 778, 
 in _dispatch
  cmdpats, cmdoptions)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 549, 
 in runcommand
  ret = _runcommand(ui, options, cmd, d)
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 869, 
 in _runcommand
  return checkargs()
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 840, 
 in checkargs
  return cmdfunc()
File /usr/lib/python2.7/dist-packages/mercurial/dispatch.py, line 775, 
 in lambda
  d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 507, in 
 check
  return func(*args, **kwargs)
File /home/username/.javahg/tmp/1382566970689-0/javahg-test.py, line 73, 
 in throw
  raise Exception(an unhandled exception)

That's an extension in your home directory throwing an exception, so
definitely not a mercurial bug.  To the best of my knowledge we don't
have a javahg package in Debian to redirect this bug to.  I'm tempted
to close this bug as not a bug, can you elaborate a bit on why you
think this is a bug in mercurial?

Cheers,
Javi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728272: [Python-apps-team] Bug#728272: python3-memprof: missing python3-pkg-resources dependency

[Javi Merino]

On Wed, Oct 30, 2013 at 06:59:04AM +0100, Martin Pitt wrote:
 Hello,

Hi Martin,
 
 python3-memprof imports pkg_resources without depending on
 python3-pkg-resources. In Debian this gets pulled in through a
 transitive dependency with matplotlib, but as memprof uses it itself
 it should directly depend on it instead of relying on these.

You are right, I added the dependency for python-memprof and forgot
about python3-memprof.
 
 E. g. in Ubuntu we still have an older matplotlib and thus
 pkg_resources doesn't get installed with it, which is exposed by the
 failing autopkgtest (Many thanks for adding one! It's exactly the kind
 of thing which they are meant to detect):

Many thanks to you for reporting this back to Debian!
 
   
 https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-python-memprof/2/ARCH=i386,label=adt/
 
 Thanks for considering,

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#726700: nmu: mercurial_2.7.1-2~bpo70+1

[Javi Merino]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

It looks like I didn't build mercurial 2.7.2-1~bpo70+1 in a wheezy
chroot[0].  If it's possible to ask for binnmus for backports
packages, can you do it please?

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726613

nmu mercurial_2.7.1-2~bpo70+1 . amd64 . -m rebuild in a wheezy environment

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726613: mercurial wheezy backport has incorrect libc6 dependency

[Javi Merino]

Control: reopen -1

2013/10/17 Javi Merino vi...@debian.org:
 2013/10/17 Faheem Mitha fah...@faheem.info:
 Package: mercurial
 Version: 2.7.2-1~bpo70+1
 Severity: normal

 Currently, I see the mercurial wheezy backport is

 2.7.2-1~bpo70+1 0
100 http://debian.lcs.mit.edu/debian/ wheezy-backports/main amd64 
 Packages

 and `apt-cache show` gives

 Package: mercurial
 Version: 2.7.2-1~bpo70+1
 Installed-Size: 236
 Maintainer: Python Applications Packaging Team 
 python-apps-t...@lists.alioth.debian.org
 Architecture: amd64
 Depends: libc6 (= 2.14), python (= 2.7), python ( 2.8), ucf (= 
 2.0020), mercurial-common (= 2.7.2-1~bpo70+1)

 The version in the archive depends on libc6 (= 2.4) except for armhf,
 ia64, kfreebsd-amd64, kfreebsd-i386, s390x and sparc:

 http://packages.debian.org/wheezy-backports/mercurial

 Your mirror is tampering with the package:

 $ wget -q 
 http://http.us.debian.org/debian/pool/main/m/mercurial/mercurial_2.7.1-2~bpo70+1_i386.deb
  -O - | sha1sum
 b93368a34adf0852520c31e2778dd07b4f43460d  -
 $ wget -q 
 http://ftp.es.debian.org/debian/pool/main/m/mercurial/mercurial_2.7.1-2~bpo70+1_i386.deb
  -O - | sha1sum
 b93368a34adf0852520c31e2778dd07b4f43460d  -
 $ wget -q 
 http://debian.lcs.mit.edu/debian/pool/main/m/mercurial/mercurial_2.7.1-2~bpo70+1_amd64.deb
  -O - | sha1sum
 58035bc1d33f36a3742ca50ae835e7a9404434b2  -
 $

Erm this is wrong, I downloaded the i386 version from the official
mirrors which obviously has a different sha1sum.

You're right, looks like I didn't build it in a wheezy chroot and
that's why it got the wrong dependencies.  I'll request a binnmu.

Sorry for that,
Javi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725145: mercurial: Unnecessary Breaks on mercurial-git

[Javi Merino]

2013/10/2 James McCoy james...@debian.org:
 Source: mercurial
 Version: 2.7.1-3
 Severity: normal

 There's no (documented) reason for the addition of “Breaks:
 mercurial-git (= 0.4.0-1)” that was added in the latest upload.

 The only thing that has caused mercurial-git to stop working recently is
 python-dulwich's API changes[0].

 [0]: http://bugs.debian.org/724638

Yes, my bad.  As mercurial routinely breaks mercurial-git, I saw that
it was broken and assumed that it was because I had forgotten to test
it when I released mercurial 2.7.1-2.  I'll revert the breaks in
2.7.2-1.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725048: python-matplotlib should depend on python-tornado and python-nose

[Javi Merino]

Package: python-matplotlib
Version: 1.3.0-1.1
Severity: normal

$ python -c 'import pkg_resources; pkg_resources.require(matplotlib)'
Traceback (most recent call last):
  File string, line 1, in module
  File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 698, in require
needed = self.resolve(parse_requirements(requirements))
  File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 596, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: nose
$

If you install python-nose, you get the same trace for tornado.
python3-matplotlib depends on python3-nose and python3-tornado.
tornado appears as a explicit requirement for matplotlib[0].

[0] https://github.com/matplotlib/matplotlib/blob/master/setup.py#L67

Cheers,
Javi

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-matplotlib depends on:
ii  libatk1.0-0   2.10.0-2
ii  libc6 2.17-93
ii  libcairo2 1.12.16-2
ii  libfontconfig12.10.2-2
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.8.1-10
ii  libgdk-pixbuf2.0-02.28.2-1
ii  libglib2.0-0  2.36.4-1
ii  libgtk2.0-0   2.24.21-1
ii  libpango-1.0-01.32.5-5+b1
ii  libpangocairo-1.0-0   1.32.5-5+b1
ii  libpangoft2-1.0-0 1.32.5-5+b1
ii  libpng12-01.2.49-4
ii  libstdc++64.8.1-10
ii  python2.7.5-5
ii  python-dateutil   1.5+dfsg-0.1
ii  python-matplotlib-data1.3.0-1.1
ii  python-numpy [python-numpy-abi9]  1:1.7.1-3
ii  python-pyparsing  2.0.1+dfsg1-1
ii  python-support1.0.15
ii  python-tz 2012c-1
ii  tcl8.58.5.14-2
ii  tk8.5 8.5.14-2

Versions of packages python-matplotlib recommends:
pn  python-glade2  none
pn  python-tk  none

Versions of packages python-matplotlib suggests:
pn  dvipng none
ii  gir1.2-gtk-3.0 3.8.4-1
pn  ipythonnone
ii  librsvg2-common2.36.4-2
ii  python-cairo   1.8.8-1+b2
pn  python-configobj   none
pn  python-excelerator none
ii  python-gobject 3.10.0-1
ii  python-gtk22.24.0-3+b1
pn  python-matplotlib-doc  none
ii  python-qt4 4.10.2-2
pn  python-scipy   none
ii  python-sip 4.14.7-4
pn  python-traits  none
pn  python-wxgtk2.8none
pn  texlive-extra-utilsnone
pn  texlive-latex-extranone

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#721949: klavaro: Depends on a virtual package

[Javi Merino]

Package: klavaro
Severity: grave
Justification: renders package unusable

klavaro is uninstallable in sid:

$ aptitude install klavaro
The following NEW packages will be installed:
  klavaro{b} 
0 packages upgraded, 1 newly installed, 0 to remove and 37 not upgraded.
Need to get 780 kB of archives. After unpacking 2400 kB will be used.
The following packages have unmet dependencies:
 klavaro : Depends: libgtkdatabox-0.9.1-1 which is a virtual package.
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) klavaro [Not Installed]



Accept this solution? [Y/n/q/?] 


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718621: mercurial: conffiles not removed

[Javi Merino]

On Sun, Aug 11, 2013 at 05:28:56PM +0200, Paul Wise wrote:
 On Sun, 2013-08-11 at 16:04 +0200, Javi Merino wrote:
 
  /etc/bash_completion.d/mercurial and /etc/mercurial/hgrc were
  conffiles of mercurial in 2.6.2-1 and are conffiles of
  mercurial-common in 2.6.3-1.  mercurial depends on mercurial-common,
  so is this really a bug?
 
 So the issue must be that you aren't properly transferring these
 conffiles between packages. Perhaps this post helps with that:
 
 http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2006-12-23-moving-conffiles.html
 https://lists.debian.org/debian-devel/2006/12/msg00647.html

Well, that post says:

Fortunately, all of this is only necessary for upgrades from sarge to
etch, and once we can expect everyone to have etch's dpkg installed we
can move conffiles between packages more or less like any other
files.

So I don't really know how much of that post is actually helpful for
this situation.  What am I supposed to do?  Remove the files in
mercurial-common's preinst if they are present and their md5 match?

 In addition, the second two files should be removed:
 
 pabs@chianamo ~ $ dpkg-query -W -f='${Conffiles}\n' mercurial | grep obsolete 
 | tail -n2
  /etc/mercurial/hgrc.d/mergetools.rc 256f6d68e04f68df651392d7019bad0a obsolete
  /etc/mercurial/hgrc.d/cacerts.rc 9f9020947cdcb24be9e042f5fa40a43a obsolete

Why?  Those files are still present in mercurial 2.6.3-1 and they
still are conffiles.  I don't want to remove them, they are part of
the package.

  Besides, I can't reproduce it on a clean sid chroot:
 
 Er, obviously you won't be able to reproduce it in a clean sid chroot
 that never had the old version of mercurial installed.

Ok, I tried upgrading from 2.6.2-1 to 2.6.3-1: adequate doesn't
complain and dpkg-query doesn't show
/etc/mercurial/hgrc.d/mergetools.rc and
/etc/mercurial/hgrc.d/cacerts.rc as obsolete:

# dpkg -i mercurial_2.6.2-1_i386.deb mercurial-common_2.6.2-
Selecting previously unselected package mercurial.
(Reading database ... 13127 files and directories currently installed.)
Unpacking mercurial (from mercurial_2.6.2-1_i386.deb) ...
Selecting previously unselected package mercurial-common.
Unpacking mercurial-common (from mercurial-common_2.6.2-1_all.deb) ...
Setting up mercurial-common (2.6.2-1) ...
Setting up mercurial (2.6.2-1) ...

Creating config file /etc/mercurial/hgrc.d/hgext.rc with new version
# aptitude safe-upgrade
The following packages will be upgraded: 
  mercurial mercurial-common 
The following packages are RECOMMENDED but will NOT be installed:
  ca-certificates openssh-client 
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/2562 kB of archives. After unpacking 14.3 kB will be used.
Do you want to continue? [Y/n/?] 
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 13766 files and directories currently installed.)
Preparing to replace mercurial 2.6.2-1 (using .../mercurial_2.6.3-1_i386.d
Unpacking replacement mercurial ...
Preparing to replace mercurial-common 2.6.2-1 (using .../mercurial-common_
Unpacking replacement mercurial-common ...
Setting up mercurial-common (2.6.3-1) ...
Setting up mercurial (2.6.3-1) ...
 
Current status: 0 updates [-2].
# adequate mercurial
# dpkg-query -W -f='${Conffiles}\n' mercurial | grep obsolet
 /etc/bash_completion.d/mercurial ad9c61fc3330bdf30b26193bbee2bf8e obsolet
 /etc/mercurial/hgrc bcefdbdbe45da0913c9ae243149fd497 obsolete
#

 If you aren't going to fix this issue, please close the bug and I will
 just purge and reinstall mercurial to get rid of this issue.

I do want to fix it, it's just that I don't understand what's the
issue so I don't know how to do it.  I'm in DebConf, maybe you can
explain it to me IRL?

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#718621: mercurial: conffiles not removed

[Javi Merino]

On Mon, Aug 12, 2013 at 03:14:58PM +0200, Paul Wise wrote:
 On Mon, 2013-08-12 at 14:32 +0200, Javi Merino wrote:
  Why?  Those files are still present in mercurial 2.6.3-1 and they
  still are conffiles.  I don't want to remove them, they are part of
  the package.
 
 Are you sure about that?
 
 pabs@chianamo ~ $ aptitude download mercurial
 Get: 1 http://http.debian.net/debian/ testing/main mercurial amd64 2.6.3-1 
 [69.6 kB]
 Fetched 69.6 kB in 5s (12.6 kB/s)
 pabs@chianamo ~ $ dpkg -x mercurial_2.6.3-1_amd64.deb mercurial
 pabs@chianamo ~ $ find mercurial/etc/
 mercurial/etc/
 mercurial/etc/mercurial
 mercurial/etc/mercurial/hgrc.d
 mercurial/etc/bash_completion.d

Argh!  I was looking at the i386 package and it does have them but
that's the one I uploaded.  All the other arches don't have them, so it
looks like I fscked up the upload.  I've just uploaded 2.7-1 to sid
and it should have those files.  Please update and let me know if
cacerts.rc and mergetools.rc still show as obsolete.

Thanks,
Javi (Vicho)


signature.asc
Description: Digital signature

Bug#718621: mercurial: conffiles not removed

[Javi Merino]

Control: tags 718621 moreinfo unreproducible

On Sat, Aug 03, 2013 at 11:10:09AM +0200, Paul Wise wrote:
 Package: mercurial
 Version: 2.6.3-1
 Severity: normal
 User: debian...@lists.debian.org
 Usertags: obsolete-conffile adequate
 
 The recent upgrade did not deal with obsolete conffiles properly.
 Please use the dpkg-maintscript-helper support provided by dh_installdeb
 to remove these obsolete conffiles on upgrade.
 
 http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
 http://manpages.debian.net/man/1/dh_installdeb
 
 This bug report brought to you by adequate:
 
 http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
 
 pabs@chianamo ~ $ pkg=mercurial
 pabs@chianamo ~ $ adequate $pkg
 mercurial: obsolete-conffile /etc/mercurial/hgrc.d/mergetools.rc
 mercurial: obsolete-conffile /etc/mercurial/hgrc.d/cacerts.rc
 pabs@chianamo ~ $ dpkg-query -W -f='${Conffiles}\n' $pkg | grep obsolete
  /etc/bash_completion.d/mercurial ad9c61fc3330bdf30b26193bbee2bf8e obsolete
  /etc/mercurial/hgrc bcefdbdbe45da0913c9ae243149fd497 obsolete
  /etc/mercurial/hgrc.d/mergetools.rc 256f6d68e04f68df651392d7019bad0a obsolete
  /etc/mercurial/hgrc.d/cacerts.rc 9f9020947cdcb24be9e042f5fa40a43a obsolete

/etc/bash_completion.d/mercurial and /etc/mercurial/hgrc were
conffiles of mercurial in 2.6.2-1 and are conffiles of
mercurial-common in 2.6.3-1.  mercurial depends on mercurial-common,
so is this really a bug?

Besides, I can't reproduce it on a clean sid chroot:

# apt-cache policy mercurial adequate
mercurial:
  Installed: 2.6.3-1
  Candidate: 2.6.3-1
  Version table:
 *** 2.6.3-1 0
500 http://http.debian.net/debian/ sid/main i386 Packages
100 /var/lib/dpkg/status
adequate:
  Installed: 0.7.1
  Candidate: 0.7.1
  Version table:
 *** 0.7.1 0
500 http://http.debian.net/debian/ sid/main i386 Packages
100 /var/lib/dpkg/status
# adequate mercurial 
# 

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#714110: ITP: python-memprof -- memory profiler for Python

[Javi Merino]

Package: wnpp
Severity: wishlist
Owner: Javi Merino vi...@debian.org

* Package name: python-memprof
  Version : 0.2.2
  Upstream Author : Jose M. Dana jmd...@gmail.com
* URL : http://jmdana.github.io/memprof/
* License : GPLv3
  Programming Lang: Python
  Description : memory profiler for Python

memprof logs and plots the memory usage of all the variables during
the execution of the decorated methods.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701600: unblock: mercurial/2.2.2-3

[Javi Merino]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mercurial, it fixes #701168, an important bug in 
wheezy[0]

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701168

unblock mercurial/2.2.2-3

debdiff against the current version in wheezy:

diff -Nru mercurial-2.2.2/debian/changelog mercurial-2.2.2/debian/changelog
--- mercurial-2.2.2/debian/changelog2013-01-21 23:33:20.0 +
+++ mercurial-2.2.2/debian/changelog2013-02-23 19:53:41.0 +
@@ -1,3 +1,13 @@
+mercurial (2.2.2-3) unstable; urgency=low
+
+  * Fix Backport improvement to vimdiff configuration by adding
+from_upstream__set_vimdiff_to_check_changed.patch,
+from_upstream__mergetools_vimdiff_issue_warning.patch and
+from_upstream__mergetools_refine_vimdiff_warning_message.patch
+backported from upstream (Closes: #701168)
+
+ -- Javi Merino vi...@debian.org  Sat, 23 Feb 2013 19:52:22 +
+
 mercurial (2.2.2-2) unstable; urgency=low
 
   * Fix Please add patch from http://bz.selenic.com/show_bug.cgi?id=3511;
diff -Nru 
mercurial-2.2.2/debian/patches/from_upstream__mergetools_refine_vimdiff_warning_message.patch
 
mercurial-2.2.2/debian/patches/from_upstream__mergetools_refine_vimdiff_warning_message.patch
--- 
mercurial-2.2.2/debian/patches/from_upstream__mergetools_refine_vimdiff_warning_message.patch
   1970-01-01 01:00:00.0 +0100
+++ 
mercurial-2.2.2/debian/patches/from_upstream__mergetools_refine_vimdiff_warning_message.patch
   2013-02-23 19:31:52.0 +
@@ -0,0 +1,21 @@
+Origin: http://hg.intevation.org/mercurial/crew/rev/7d66a44e87ed
+Description: mergetools: refine vimdiff warning message
+ We explicitly redraw before echoing the message so that it simply
+ displays at the bottom of the window. Also simplifies the message
+ printing by using 'echomsg' (which uses 'echohl' internally) and adds
+ the names of the software involved for improved Googleability.
+Bug: http://bugs.debian.org/701168
+
+diff --git a/contrib/mergetools.hgrc b/contrib/mergetools.hgrc
+--- a/contrib/mergetools.hgrc
 b/contrib/mergetools.hgrc
+@@ -15,7 +15,7 @@ gvimdiff.regkeyalt=Software\Wow6432Node\
+ gvimdiff.regname=path
+ gvimdiff.priority=-9
+ 
+-vimdiff.args=$local $other $base -c 'echohl WarningMsg | echo merge conflict 
detected, type \:cq\ to abort | echohl'
++vimdiff.args=$local $other $base -c 'redraw | echomsg hg merge conflict, 
type \:cq\ to abort vimdiff'
+ vimdiff.check=changed
+ vimdiff.priority=-10
+ 
+
diff -Nru 
mercurial-2.2.2/debian/patches/from_upstream__mergetools_vimdiff_issue_warning.patch
 
mercurial-2.2.2/debian/patches/from_upstream__mergetools_vimdiff_issue_warning.patch
--- 
mercurial-2.2.2/debian/patches/from_upstream__mergetools_vimdiff_issue_warning.patch
1970-01-01 01:00:00.0 +0100
+++ 
mercurial-2.2.2/debian/patches/from_upstream__mergetools_vimdiff_issue_warning.patch
2013-02-23 19:31:52.0 +
@@ -0,0 +1,27 @@
+Origin: http://hg.intevation.org/mercurial/crew/rev/f2b1f78cf202
+Bug: http://bugs.debian.org/701168
+Subject: mergetools: vimdiff issue a warning explaining how to abort
+
+Adds a message displayed at each vimdiff invocation:
+
+  merge conflict detected, type :cq to abort
+
+Vimdiff is very confusing for non-vim user (not to speak about vim
+user confused anyway. However it is very likely that vimdiff is picked
+as the mergetool of choice when using the default config:
+- vim is available on all UNIX system.
+- Its one of the rare non graphical merge tools.
+
+diff --git a/contrib/mergetools.hgrc b/contrib/mergetools.hgrc
+--- a/contrib/mergetools.hgrc
 b/contrib/mergetools.hgrc
+@@ -15,7 +15,7 @@ gvimdiff.regkeyalt=Software\Wow6432Node\
+ gvimdiff.regname=path
+ gvimdiff.priority=-9
+ 
+-vimdiff.args=$local $other $base
++vimdiff.args=$local $other $base -c 'echohl WarningMsg | echo merge conflict 
detected, type \:cq\ to abort | echohl'
+ vimdiff.check=changed
+ vimdiff.priority=-10
+ 
+
diff -Nru 
mercurial-2.2.2/debian/patches/from_upstream__set_vimdiff_to_check_changed.patch
 
mercurial-2.2.2/debian/patches/from_upstream__set_vimdiff_to_check_changed.patch
--- 
mercurial-2.2.2/debian/patches/from_upstream__set_vimdiff_to_check_changed.patch
1970-01-01 01:00:00.0 +0100
+++ 
mercurial-2.2.2/debian/patches/from_upstream__set_vimdiff_to_check_changed.patch
2013-02-23 19:31:52.0 +
@@ -0,0 +1,17 @@
+Origin: http://selenic.com/hg/rev/93bc65e970c0
+Description: mergetools.hgrc: set vimdiff to check=changed
+Bug: http://bugs.debian.org/701168
+Applied-Upstream: 2.3.2
+
+diff --git a/contrib/mergetools.hgrc b/contrib/mergetools.hgrc
+--- a/contrib/mergetools.hgrc
 b/contrib/mergetools.hgrc
+@@ -16,6 +16,7 @@ gvimdiff.regname=path
+ gvimdiff.priority=-9
+ 
+ vimdiff.args=$local $other $base
++vimdiff.check=changed
+ vimdiff.priority=-10
+ 
+ merge.checkconflicts=True
+
diff -Nru mercurial-2.2.2/debian

Bug#699405: Summary: [journal.bookmarks transaction recovery error on multi-committer repos ]

[Javi Merino]

On Thu, Jan 31, 2013 at 03:27:38PM +1100, Peter Chubb wrote:
 Package: mercurial
 Version: 2.2.2-1~bpo60+1
 Severity: normal
 
 We keep being hit by bug http://bz/selenic.com/show_bug/?id=3318 ---

That bug was fixed in mercurial 2.1.2 and you are using mercurial 2.2.2
which shouldn't have it.

 can a more recent version of mercurial be added to stable, please?

Right now we are in a freeze so the only uploads going to stable are
ones that fix bugs that are = important.  New versions of mercurial
are currently only uploaded to experimental.  Once we release wheezy,
wheezy-backports will get a more recent mercurial.

Cheers,
Javi



signature.asc
Description: Digital signature

Bug#692797: unblock: python-greenlet/0.3.1-2.1

[Javi Merino]

On Sun, Feb 03, 2013 at 11:21:54AM +0100, Julien Cristau wrote:
 On Sat, Jan 26, 2013 at 16:30:04 +, Javi Merino wrote:
 
  On Sat, Jan 26, 2013 at 01:45:44PM +, Javi Merino wrote:
   Hi Laszlo,
   
   On Fri, 21 Dec 2012 22:50:40 +, Laszlo Boszormenyi wrote:
On Wed, 2012-12-19 at 19:55 +, Adam D. Barratt wrote:
 On Sat, 2012-11-24 at 13:34 +, Adam D. Barratt wrote:
  On Fri, 2012-11-09 at 23:08 +0100, Jelmer Vernooij wrote:
   On Fri, 2012-11-09 at 06:08 +, Adam D. Barratt wrote:
It also itself FTBFS on a few architectures - see
https://buildd.debian.org/status/package.php?p=python-greenletsuite=wheezy
 ; armel and mips{,el} are regressions from the current testing 
package.

   Thanks, I should've noticed that but hadn't. This is quite 
   surprising
   too, I don't see anything in the NMU that might be the cause of 
   this. 
  
  I suspect the issue was already there - see #665890, which is also 
  fixed
  in sid already.
 
 Laszlo, any chance of a fixed version?
 The good is that upstream uses git, I could check the individual
commits. The bad is that the places where it FTBFS are assembly codes.
Upstream reworked that parts with the relevant C code as well. So it's
not easy, I'd say impossible for me to backport those changes. I don't
speak ARM nor Sparc ASM at least.
   
   You can find more info on how to fix the FTBFS in armel in #697406.
   Peter says that building python-greenlet from TPU with the version of
   platform/switch_arm32_gcc.h from 0.4.0 solves the issue in armel.
  
  I've uploaded python-greenlet_0.3.1-2.2 to TPU which fixes the build
  for armel (tested in a porterbox).  This won't fix the SPARC one
  though.
  
 Are the debdiffs for the various NMUs in the BTS somewhere?

I've attached them to this email.

 0.3.1-2.3
 seems to add /usr/share/dpkg/buildflags.mk to debian/rules, with no
 build-dependency, which is not the same thing as compile with -O2 on
 mipsel.  Why?

That was an overlook on my side, I should fix that.  Or are you saying
that adding /usr/share/dpkg/buildflags.mk is not the right way of
fixing this?

Cheers,
Javi


diff -Nru python-greenlet-0.3.1/debian/changelog python-greenlet-0.3.1/debian/changelog
--- python-greenlet-0.3.1/debian/changelog	2012-08-25 15:05:43.0 +0100
+++ python-greenlet-0.3.1/debian/changelog	2013-01-26 15:57:17.0 +
@@ -1,3 +1,13 @@
+python-greenlet (0.3.1-2.2) wheezy-proposed-updates; urgency=low
+
+  * Non-maintainer upload.
+  * Fix python-greenlet FTBFS on armel in testing by using
+platform/switch_arm32_gcc.h from 0.4.0 to avoid compile errors in
+armel (Closes: #697406) (Thanks to Peter Michael Green
+plugw...@raspbian.org)
+
+ -- Javi Merino vi...@debian.org  Sat, 26 Jan 2013 14:40:01 +
+
 python-greenlet (0.3.1-2.1) wheezy-proposed-updates; urgency=low
 
   * Non-maintainer upload.
diff -Nru python-greenlet-0.3.1/debian/patches/series python-greenlet-0.3.1/debian/patches/series
--- python-greenlet-0.3.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ python-greenlet-0.3.1/debian/patches/series	2013-01-04 21:56:14.0 +
@@ -0,0 +1 @@
+switch_arm32_update.patch
diff -Nru python-greenlet-0.3.1/debian/patches/switch_arm32_update.patch python-greenlet-0.3.1/debian/patches/switch_arm32_update.patch
--- python-greenlet-0.3.1/debian/patches/switch_arm32_update.patch	1970-01-01 01:00:00.0 +0100
+++ python-greenlet-0.3.1/debian/patches/switch_arm32_update.patch	2013-01-26 14:07:26.0 +
@@ -0,0 +1,64 @@
+Description: use platform/switch_arm32_gcc.h from 0.4.0 to avoid compile errors
+Author: Peter Michael Green plugw...@raspbian.org
+Bug-Debian: http://bugs.debian.org/697406
+
+--- python-greenlet-0.3.1.orig/platform/switch_arm32_gcc.h
 python-greenlet-0.3.1/platform/switch_arm32_gcc.h
+@@ -25,26 +25,51 @@
+ 
+ #ifdef SLP_EVAL
+ #define STACK_MAGIC 0
+-#define REGS_TO_SAVE /*r1, r2, r3, r4,*/ r5, r6, fp, ip, lr
++#define REG_SP sp
++#define REG_SPSP sp,sp
++#ifdef __thumb__
++#define REG_FP r7
++#define REG_FPFP r7,r7
++#define REGS_TO_SAVE_GENERAL r4, r5, r6, r8, r9, r10, r11, lr
++#else
++#define REG_FP fp
++#define REG_FPFP fp,fp
++#define REGS_TO_SAVE_GENERAL r4, r5, r6, r7, r8, r9, lr
++#endif
++#if defined(__SOFTFP__)
++#define REGS_TO_SAVE REGS_TO_SAVE_GENERAL
++#elif defined(__VFP_FP__)
++#define REGS_TO_SAVE REGS_TO_SAVE_GENERAL, d8, d9, d10, d11, \
++   d12, d13, d14, d15
++#elif defined(__MAVERICK__)
++#define REGS_TO_SAVE REGS_TO_SAVE_GENERAL, mvf4, mvf5, mvf6, mvf7, \
++   mvf8, mvf9, mvf10, mvf11, \
++   mvf12, mvf13, mvf14, mvf15
++#else
++#define REGS_TO_SAVE REGS_TO_SAVE_GENERAL, f4, f5, f6, f7
++#endif
+ 
+ static int
+ slp_switch(void)
+ {
++void *fp;
+ register int

Bug#692797: unblock: python-greenlet/0.3.1-2.1

[Javi Merino]

On Mon, Feb 04, 2013 at 10:50:40PM +0100, Julien Cristau wrote:
   0.3.1-2.3
   seems to add /usr/share/dpkg/buildflags.mk to debian/rules, with no
   build-dependency, which is not the same thing as compile with -O2 on
   mipsel.  Why?
  
  That was an overlook on my side, I should fix that.  Or are you saying
  that adding /usr/share/dpkg/buildflags.mk is not the right way of
  fixing this?
  
 Yes, I'm saying if what's needed is to add -O2 then an upload targetted
 at wheezy should do just that, not add random (or not so random, but
 still kind of arbitrary) other flags.  Using dpkg-buildflags can wait
 for jessie.

Right.  Should I upload a 0.3.1-2.5 with that change then?




signature.asc
Description: Digital signature

Bug#699102: python-greenlet: FTBFS on sparc

[Javi Merino]

Package: python-greenlet
Version: 0.3.1-2.2
Severity: serious
Justification: FTBFS

The FTBFS in sparc[0] in wheezy can be fixed by applying the attached
patch

[0] 
https://buildd.debian.org/status/fetch.php?pkg=python-greenletarch=sparcver=0.3.1-2.2stamp=1359234024

Cheers,
Javi
Author: unixtool1192 unixtool1...@gmail.com
Origin: https://github.com/python-greenlet/greenlet/commit/619ab917e3ab47be7642ced21c8cfd8e8182844b
Description: add support for debian sparc and openbsd5-sparc64

--- a/platform/switch_sparc_sun_gcc.h
+++ b/platform/switch_sparc_sun_gcc.h
@@ -19,9 +19,9 @@
 
 #ifdef SLP_EVAL
 
-#include sys/trap.h
 
 #define STACK_MAGIC 0
+#define ST_FLUSH_WINDOWS 3
 
 static int
 slp_switch(void)
--- a/slp_platformselect.h
+++ b/slp_platformselect.h
@@ -12,7 +12,7 @@
 #include platform/switch_ppc_unix.h /* gcc on PowerPC */
 #elif defined(__GNUC__)  defined(__ppc__)  defined(__APPLE__)
 #include platform/switch_ppc_macosx.h /* Apple MacOS X on PowerPC */
-#elif defined(__GNUC__)  defined(sparc)  defined(sun)
+#elif defined(__GNUC__)  defined(sparc)
 #include platform/switch_sparc_sun_gcc.h /* SunOS sparc with gcc */
 #elif defined(__GNUC__)  defined(__s390__)  defined(__linux__)
 #include platform/switch_s390_unix.h	/* Linux/S390 */

Bug#665890: python-greenlet: FTBFS on mips*: error: $fp cannot be used in asm here

[Javi Merino]

On Mon, 26 Mar 2012 21:08:35 +0100, Adam D. Barratt wrote:
 Source: python-greenlet
 Version: 0.3.3-1
 Severity: serious

 python-greenlet no longer builds on mips*.  From the mipsel build log:

 creating build/temp.linux-mips-2.6-pydebug
 gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -fPIC 
 -I/usr/include/python2.6_d -c greenlet.c -o 
 build/temp.linux-mips-2.6-pydebug/greenlet.o
 In file included from slp_platformselect.h:32:0,
  from greenlet.c:390:
 platform/switch_mips_unix.h: In function 'slp_switch':
 platform/switch_mips_unix.h:43:1: error: $fp cannot be used in asm here
 error: command 'gcc' failed with exit status 1

This doesn't happen on the sid version of the package because that
code is actually dead code that's not used.  In 0.3.1-1 it's compiled
without optimizations so it fails but in 0.4.0 it's compiled with -O2,
the code is optimized out and the build succeeds.

I'm going to upload 0.3.1-2.2 to TPU (delayed/5) which fixes this and
#699102.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#692797: unblock: python-greenlet/0.3.1-2.1

[Javi Merino]

Hi Laszlo,

On Fri, 21 Dec 2012 22:50:40 +, Laszlo Boszormenyi wrote:
 On Wed, 2012-12-19 at 19:55 +, Adam D. Barratt wrote:
  On Sat, 2012-11-24 at 13:34 +, Adam D. Barratt wrote:
   On Fri, 2012-11-09 at 23:08 +0100, Jelmer Vernooij wrote:
On Fri, 2012-11-09 at 06:08 +, Adam D. Barratt wrote:
 It also itself FTBFS on a few architectures - see
 https://buildd.debian.org/status/package.php?p=python-greenletsuite=wheezy
  ; armel and mips{,el} are regressions from the current testing 
 package.
 
Thanks, I should've noticed that but hadn't. This is quite surprising
too, I don't see anything in the NMU that might be the cause of this. 
   
   I suspect the issue was already there - see #665890, which is also fixed
   in sid already.
  
  Laszlo, any chance of a fixed version?
  The good is that upstream uses git, I could check the individual
 commits. The bad is that the places where it FTBFS are assembly codes.
 Upstream reworked that parts with the relevant C code as well. So it's
 not easy, I'd say impossible for me to backport those changes. I don't
 speak ARM nor Sparc ASM at least.

You can find more info on how to fix the FTBFS in armel in #697406.
Peter says that building python-greenlet from TPU with the version of
platform/switch_arm32_gcc.h from 0.4.0 solves the issue in armel.

Cheers,
Javi



signature.asc
Description: Digital signature

Bug#692797: unblock: python-greenlet/0.3.1-2.1

[Javi Merino]

On Sat, Jan 26, 2013 at 01:45:44PM +, Javi Merino wrote:
 Hi Laszlo,
 
 On Fri, 21 Dec 2012 22:50:40 +, Laszlo Boszormenyi wrote:
  On Wed, 2012-12-19 at 19:55 +, Adam D. Barratt wrote:
   On Sat, 2012-11-24 at 13:34 +, Adam D. Barratt wrote:
On Fri, 2012-11-09 at 23:08 +0100, Jelmer Vernooij wrote:
 On Fri, 2012-11-09 at 06:08 +, Adam D. Barratt wrote:
  It also itself FTBFS on a few architectures - see
  https://buildd.debian.org/status/package.php?p=python-greenletsuite=wheezy
   ; armel and mips{,el} are regressions from the current testing 
  package.
  
 Thanks, I should've noticed that but hadn't. This is quite surprising
 too, I don't see anything in the NMU that might be the cause of this. 

I suspect the issue was already there - see #665890, which is also fixed
in sid already.
   
   Laszlo, any chance of a fixed version?
   The good is that upstream uses git, I could check the individual
  commits. The bad is that the places where it FTBFS are assembly codes.
  Upstream reworked that parts with the relevant C code as well. So it's
  not easy, I'd say impossible for me to backport those changes. I don't
  speak ARM nor Sparc ASM at least.
 
 You can find more info on how to fix the FTBFS in armel in #697406.
 Peter says that building python-greenlet from TPU with the version of
 platform/switch_arm32_gcc.h from 0.4.0 solves the issue in armel.

I've uploaded python-greenlet_0.3.1-2.2 to TPU which fixes the build
for armel (tested in a porterbox).  This won't fix the SPARC one
though.




signature.asc
Description: Digital signature

Bug#698671: unblock: mercurial/2.2.2-2

[Javi Merino]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mercurial

mercurial 2.2.2-2 fixed an important bug[0] by adding a patch from
upstream.  It's the only difference with 2.2.2-1, the current version
in wheezy.  The debdiff is attached

[0] http://bugs.debian.org/698634

unblock mercurial/2.2.2-2

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru mercurial-2.2.2/debian/changelog mercurial-2.2.2/debian/changelog
--- mercurial-2.2.2/debian/changelog	2012-06-03 18:21:58.0 +0100
+++ mercurial-2.2.2/debian/changelog	2013-01-21 23:33:20.0 +
@@ -1,3 +1,10 @@
+mercurial (2.2.2-2) unstable; urgency=low
+
+  * Fix Please add patch from http://bz.selenic.com/show_bug.cgi?id=3511;
+by adding it (Closes: #698634)
+
+ -- Javi Merino vi...@debian.org  Mon, 21 Jan 2013 23:33:20 +
+
 mercurial (2.2.2-1) unstable; urgency=low
 
   * New upstream release
diff -Nru mercurial-2.2.2/debian/patches/from_upstream__reinclude_root_directory_in_directory_rename_detection.patch mercurial-2.2.2/debian/patches/from_upstream__reinclude_root_directory_in_directory_rename_detection.patch
--- mercurial-2.2.2/debian/patches/from_upstream__reinclude_root_directory_in_directory_rename_detection.patch	1970-01-01 01:00:00.0 +0100
+++ mercurial-2.2.2/debian/patches/from_upstream__reinclude_root_directory_in_directory_rename_detection.patch	2013-01-21 22:56:37.0 +
@@ -0,0 +1,30 @@
+Origin: http://selenic.com/hg/rev/8b7cd9a998f0
+Description: copies: re-include root directory in directory rename detection (issue3511)
+Bug: http://bugs.debian.org/698634
+Bug-mercurial: http://bz.selenic.com/show_bug.cgi?id=3511
+Applied-Upstream: 2.2.3
+
+--- a/mercurial/context.py
 b/mercurial/context.py
+@@ -1043,7 +1043,7 @@ class workingctx(changectx):
+ wlock.release()
+ 
+ def dirs(self):
+-return self._repo.dirstate.dirs()
++return set(self._repo.dirstate.dirs())
+ 
+ class workingfilectx(filectx):
+ A workingfilectx object makes access to data related to a particular
+--- a/mercurial/copies.py
 b/mercurial/copies.py
+@@ -308,7 +308,9 @@ def mergecopies(repo, c1, c2, ca):
+ 
+ # generate a directory move map
+ d1, d2 = c1.dirs(), c2.dirs()
+-invalid = set([])
++d1.add('')
++d2.add('')
++invalid = set()
+ dirmove = {}
+ 
+ # examine each file copy for a potential directory move, which is
diff -Nru mercurial-2.2.2/debian/patches/series mercurial-2.2.2/debian/patches/series
--- mercurial-2.2.2/debian/patches/series	2012-06-03 18:21:58.0 +0100
+++ mercurial-2.2.2/debian/patches/series	2013-01-21 22:55:36.0 +
@@ -7,3 +7,4 @@
 deb_specific__install-mo-fhs.patch
 deb_specific__disable_libdir_replacement.patch
 deb_specific__fix_hg-ssh_interpreter.patch
+from_upstream__reinclude_root_directory_in_directory_rename_detection.patch

Bug#495779: Tag #495779 wontfix as it's been tagged as such in the upstream bts

[Javi Merino]

tags 495779 wontfix
thanks

Tag #495779 wontfix as it's been tagged as such in the upstream bts

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#695143: mercurial removes directory when removing the last contained file.

[Javi Merino]

tags 695143 + upstream wontfix 
thanks

On Tue, Dec 04, 2012 at 04:44:41PM +0100, g1 wrote:
 Package: mercurial
 Version: 1.6.4-1
 Severity: normal
 
 If I hg remove the last file in a directory, mercurial removes
 the directory on commit (see below). 
 
 Perhaps it's an upstream bug.
 
 Perhaps it's a feature documented in the Definitive Guide, but I
 won't buy the book just to check this, and the online version at
 http://hgbook.red-bean.com/read/ is barely usable.

Mercurial tracks files.  It has no way of representing an empty
directory so it deletes it when you remove all the files in it.  If
you want to have an empty directory in your repository, add an empty
.dummy file in it.  For more info see Mercurial tracks files, not
directories in the Definitive Guide:

http://hgbook.red-bean.com/read/mercurial-in-daily-use.html

Cheers,
Javi
 
 Script started on Tue Dec  4 16:21:35 2012
 | $ hg init
 | $ mkdir d
 | $ echo a  d/a
 | $ hg add d/a
 | $ hg commit -m file_created 
 | $ ls -s d
 | total 4
 | 4 a
 | $ hg manifest -v
 | 644   d/a
 | $ hg rm d/a
 | $ hg commit -m file_removed
 | $ ls -s d
 | ls: cannot access d: No such file or directory
 Script done on Tue Dec  4 16:23:16 2012


signature.asc
Description: Digital signature

Bug#661441: src:genshi: tests fail under python2.7, but failure is ignored

[Javi Merino]

Stefano Rivera wrote:
 ==
 FAIL: test_sanitize_remove_src_javascript 
 (genshi.filters.tests.html.HTMLSanitizerTestCase)
 --
 Traceback (most recent call last):
   File /«PKGBUILDDIR»/genshi/filters/tests/html.py, line 442, in 
 test_sanitize_remove_src_javascript
 'IMG SRC=`javascript:alert(RSnake says, \'foo\')`')
 AssertionError: ParseError not raised

 --
 Ran 828 tests in 1.198s

 FAILED (failures=1)

 Yet, the build continues...

FWIW, to make the build fail (which it should) apply this patch
(thanks to POX):

--- a/debian/rules
+++ b/debian/rules
@@ -16,7 +16,7 @@ DEB_PYTHON_SETUP_CMD += --with-speedups
 
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 binary-install/python-genshi::
-   for py in $(shell pyversions -vr); do \
+   set -e; for py in $(shell pyversions -vr); do \

PYTHONPATH=$(cdbs_python_destdir)/usr/lib/python$$py/site-packages \
python$$py setup.py test; \
done;


signature.asc
Description: Digital signature

Bug#672416: nmu: mercurial_2.2.1-2

[Javi Merino]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

gb mercurial_2.2.1-2 . kfreebsd-amd64

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671548: python-qt4 4.9.1-2 broke hgview

[Javi Merino]

Package: python-qt4
Version: 4.9.1-2
Severity: important

hgview worked fine with 4.9.1-1, but when I upgrade to 4.9.1-3, hgview fails 
with:

$ hgview
Traceback (most recent call last):
  File /usr/bin/hgview, line 33, in module
main()
  File /usr/lib/python2.7/dist-packages/hgviewlib/application.py, line 188, 
in main
sys.exit(start(repo, opts, args, parser.error))
  File /usr/lib/python2.7/dist-packages/hgviewlib/application.py, line 135, 
in start
app = Application(repo, opts, args)
  File /usr/lib/python2.7/dist-packages/hgviewlib/qt4/application.py, line 
48, in __init__
super(HgViewQtApplication, self).__init__(*args, **kwargs)
  File /usr/lib/python2.7/dist-packages/hgviewlib/application.py, line 78, in 
__init__
self.choose_viewer()
  File /usr/lib/python2.7/dist-packages/hgviewlib/application.py, line 102, 
in choose_viewer
viewer = self.HgRepoViewer(self.repo)
  File /usr/lib/python2.7/dist-packages/hgviewlib/qt4/hgrepoviewer.py, line 
58, in __init__
HgDialogMixin.__init__(self)
  File /usr/lib/python2.7/dist-packages/hgviewlib/qt4/hgdialogmixin.py, line 
69, in __init__
self.setupUi(self)
  File /usr/lib/python2.7/dist-packages/hgviewlib/qt4/hgqv_ui.py, line 59, in 
setupUi
self.textview_status = HgFileView(self.splitter)
  File /usr/lib/python2.7/dist-packages/hgviewlib/qt4/hgfileview.py, line 
119, in __init__
self.sci = qsci(self)
TypeError: QsciScintilla(QWidget parent=None): argument 1 has unexpected type 
'HgFileView'

I'm creating the bug against python-qt4 because it was its update who
broke it but feel free to reassign it.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-qt4 depends on:
ii  libc6 2.13-32
ii  libgcc1   1:4.7.0-7
ii  libpython2.7  2.7.3~rc2-2.1
ii  libqt4-dbus   4:4.8.1-1
ii  libqt4-declarative4:4.8.1-1
ii  libqt4-designer   4:4.8.1-1
ii  libqt4-help   4:4.8.1-1
ii  libqt4-network4:4.8.1-1
ii  libqt4-script 4:4.8.1-1
ii  libqt4-scripttools4:4.8.1-1
ii  libqt4-svg4:4.8.1-1
ii  libqt4-test   4:4.8.1-1
ii  libqt4-xml4:4.8.1-1
ii  libqt4-xmlpatterns4:4.8.1-1
ii  libqtassistantclient4 4.6.3-4
ii  libqtcore44:4.8.1-1
ii  libqtgui4 4:4.8.1-1
ii  libqtwebkit4  2.2.1-2
ii  libstdc++64.7.0-7
ii  python2.7.2-10
ii  python-sip [sip-api-8.1]  4.13.2-1
ii  python2.6 2.6.7-4
ii  python2.7 2.7.3~rc2-2.1

python-qt4 recommends no packages.

Versions of packages python-qt4 suggests:
pn  python-qt4-dbg  none

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#668025: mercurial: FTBFS[kfreebsd-amd64]: testsuite failure

[Javi Merino]

On Tue, Apr 10, 2012 at 08:21:00AM +0200, Julien Cristau wrote:
 On Sun, Apr  8, 2012 at 13:27:03 +0200, Christoph Egger wrote:
 
  Your package failed to build on the kfreebsd-amd64 buildds:
  
  --- 
  /build/buildd-mercurial_2.1.2-2-kfreebsd-amd64-aq2Wfm/mercurial-2.1.2/tests/test-symlink-placeholder.t
  +++ 
  /build/buildd-mercurial_2.1.2-2-kfreebsd-amd64-aq2Wfm/mercurial-2.1.2/tests/test-symlink-placeholder.t.err
  @@ -29,7 +29,6 @@
 $ rm b
 $ echo foo  b
 $ hg --config extensions.n=$TESTTMP/nolink.py status --debug
  -  ignoring suspect symlink placeholder b
   
   Make a clone using placeholders:
   
  
  ERROR: 
  /build/buildd-mercurial_2.1.2-2-kfreebsd-amd64-aq2Wfm/mercurial-2.1.2/tests/test-symlink-placeholder.t
   output changed
  
 Out of 4 tries on kfreebsd-amd64 for this version, it failed 3 times on
 3 different tests, and succeeded on the fourth build.  Not sure I
 understand this particular one, but I think it's more likely to be an
 unreliable test than a new bug.

None of the changes from 2.1.2-1 to 2.1.2-2 should affect these tests, so
that's actually 2 successful builds out of 5.  On some architectures the
testsuite is unreliable.  If this happens again, I'll probably stop
running it on kfreebsd-amd64.  

Cheers,
Javi



signature.asc
Description: Digital signature

Bug#666549: mercurial: Please remove the latest NEWS.Debian entry

[Javi Merino]

On Sat, Mar 31, 2012 at 07:52:02PM +0300, Adrian Bunk wrote:
 Package: mercurial
 Version: 2.1.1-2
 Severity: normal
 
 Please remove the latest entry from NEWS.Debian since it
 doesn't belong there:
 
 --  snip  --
 
 mercurial (2.1.1-1) unstable; urgency=low
 
   - pull return code now matches its pre-2.1 behavior
 
  -- Javi Merino vi...@debian.org  Fri, 02 Mar 2012 22:56:45 +
 
 --  snip  --
 
 OK, so there was a bug in 2.1 that was fixed in 2.1.1.

No, it's not a bug, it's a significant change in behaviour.
 
 It would have made sense to put that into changelog.Debian
 for people running testing/unstable and using apt-listchanges.
 
 NEWS.Debian is for the rare cases of serious incompatible
 changes in a package.

Well, it is for less serious cases, quoting the developer's reference
This is the preferred means to let the user know about significant
changes in a package.

 NEWS.Debian is not for listing all bugs that were present
 for a month in unstable and then fixed - that is what
 changelog.Debian is for.

Upstream already makes that distinction: bugs are listed here [0] and
unusual changes in behaviour are listed here [1].  As I said, this is
not a bug.  Of course, the differences between what constitutes a bug
and a feature are very personal ;-)

[0] http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.1.1_.282012-03-01.29
[1] http://mercurial.selenic.com/wiki/UpgradeNotes
 
 It is completely pointless that people upgrading from 1.6.4-1
 in squeeze will see this entry.

On the other hand, people upgrading from 2.1 wheezy will see it and
they may want to know about it.

Cheers,
Javi

 Please remove this entry from NEWS.Debian.
 
 Thanks in advance
 
 
 


signature.asc
Description: Digital signature

Bug#630893: ax25-apps: Should be removed from main

[Javi Merino]

On Mon, Mar 05, 2012 at 06:32:12PM -0500, Patrick Ouellette wrote:
 On Sat, Mar 03, 2012 at 10:16:19PM +, Javi Merino wrote:
  
  Package: ax25-apps
  
  Hi,
  
  Jeff White was contacted in June 2011 asking him to relicence the code
  but he didn't reply.  This package should be moved to non-free.
  
 
 How, exactly, does commenting on a bug report with absolutely NO NEW 
 INFORMATION do anything except increase the noise level in the BTS and
 mailing lists?

It's an RC bug that hasn't seen been any activity whatsoever for half
a year, so I was wondering if the maintainer had just forgotten about
it.  It happens sometimes.
 
 We are working on a resolution to the issue.

I'm glad to hear that and I hope your package is free of RC bugs for
the wheezy release.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#662058: trash-cli will be maintained again soon

[Javi Merino]

Steve McIntyre wrote:
 Please remove trash-cli; it's effectively unmaintained and RC-buggy,
 with low popcon.

Please don't remove it.  I agree that the package is in an appalling
state, but there's people working[1][2] on it.  I'll work with Stefano
to fix this.

[1] http://mentors.debian.net/package/trash-cli
[2] http://lists.debian.org/debian-mentors/2012/02/msg00370.html

Thanks,
Javi


signature.asc
Description: Digital signature

Bug#587391: pure-ftpd-postgresql: spontanous crash

[Javi Merino]

severity important
thanks

Toni Mueller wrote:
 sorry for missing the messages. I thought I had replied to this
 already, but it seems that (at least) the problem does not always
 occur, and I was also able to set up a working pure-ftpd-postgresql
 configuration on a different Lenny host, too. But I have to look again
 whether I used a different version of pure-ftpd, or not.

Dropping severity to important as it is a bug which has a major
effect on the usability of a package, without rendering it completely
unusable to everyone.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#610984: Downgrade #610894 to important

[Javi Merino]

severity 610894 important
thanks

Though it's an important bug, there's a workaround for the data loss
it may create.  Downgrading accordingly.  Cheers, Javi


signature.asc
Description: Digital signature

Bug#610895: Downgrade 610895 to important

[Javi Merino]

severity 610895 important
thanks

This bug doesn't render the package unusable, so downgrading to
important.  Thanks,
Javi


signature.asc
Description: Digital signature

Bug#610895: Downgrade 610895 to important

[Javi Merino]

severity 610895 normal
thanks

On Sun, Mar 04, 2012 at 04:54:02PM +, Javi Merino wrote:
 severity 610895 important
 thanks
 
 This bug doesn't render the package unusable, so downgrading to
 important.  Thanks,

This was meant for #610985.  Sorry for the noise,
Javi




signature.asc
Description: Digital signature

Bug#610985: Downgrade 610985 to important

[Javi Merino]

severity 610985 important
thanks

This bug doesn't render the package unusable, so downgrading to
important.  Thanks,
Javi



signature.asc
Description: Digital signature

Bug#651655: FTBFS in sid configure: error: unable to find the slang library and header file slang.h

[Javi Merino]

Package: slang-slirp
Version: 1.9.8-1.1

I think the problem is in this part of configure (lines 6010):

---
if test X$jd_slang_library_dir = X
then
   lib_library_dirs=\
$jd_prefix_libdir \
/usr/local/lib \
/usr/local/lib/slang \
/usr/local/slang/lib \
  /usr/lib \
  /usr/lib/slang \
  /usr/slang/lib \
  /opt/lib \
  /opt/lib/slang \
  /opt/slang/lib

case $host_os in
 *darwin* )
   exts=dylib so a
   ;;
 *cygwin* )
   exts=dll.a so a
   ;;
 * )
   exts=so a
esac

   for X in $lib_library_dirs ; do
   for E in $exts ; do
if test -r $X/libslang.$E ; then
   jd_slang_library_dir=$X
   break
fi
   done
   done
---

libslang2-dev installs libslang.so in
/usr/lib/i386-linux-gnu/libslang.so (in an i386 machine) but configure
is not looking for it in there because it's not multiarch aware.

Cheers,
Javi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#617549: Zapping segfaults with xserver-xorg-driver-ati

[Javi Merino]

reassign 617549 xserver-xorg-driver-ati
severity 617549 important
thanks

dpdt1 wrote:
 i thought it was an xorg error so i removed xserver-xorg-driver-ati and
 using only radeon driver now. (ati radeon X300 vga)
 rebooting desktop i can now start zapping app normally.
 (so maybe you can remove grave status now.)

It looks like a bug in the ati driver for your card, rather than a bug
in zapping.  Zapping works on the framebuffer and it fails with
xserver-xorg-driver-ati when openning the video device:

 (C) 2000-2005 Iñaki G. Etxebarria, Michael H. Schimek.
 This program is freely redistributable under the terms
 of the GNU General Public License.
 
 Using video device '/dev/video0', display ':0.0', screen -1.
 Querying frame buffer parameters from X server.
 Xinerama base 0, 0, version 1.1
 DGA base 65, 135, version 2.0
 Screen 0:
   position   0, 0 - 1280, 1024
   frame buffer address   0xe00c
   frame buffer size  1280x1024 pixels, 0x50 bytes
   bytes per line 5120 bytes
   pixfmt BGRA32_LE
 Opening device /dev/video0.
 3 = open (/dev/video0, RDWR


signature.asc
Description: Digital signature

Bug#622353: iceweasel: application/binary files are seen as Bzip archives

[Javi Merino]

tags 622353 - security
severity 622353 normal
thanks

 Please file this upstream (reproducible with firefox 4.0), but I don't think
 this has much security implication.

Agreed, this isn't a security bug.  Lowering the priority.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#662055: RM: ax25spyd -- RoQA; Distributes non-distributable file

[Javi Merino]

Package: ftp.debian.org
Severity: normal

popcon: 30, no rdeps

See bug #630894, distributes src/ripdump.c with copyright:

*  Changes Copyright (c) 1993 Jeff White - N0POY, All Rights Reserved.
*  Permission granted for non-commercial copying and use, provided
*  this notice is retained.

Jeff White (the copyright holder) was contacted but he never replied.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630894: ax25spyd filed for removal

[Javi Merino]

Filed for removal http://bugs.debian.org/662055


signature.asc
Description: Digital signature

Bug#630893: ax25-apps: Should be removed from main

[Javi Merino]

Package: ax25-apps

Hi,

Jeff White was contacted in June 2011 asking him to relicence the code
but he didn't reply.  This package should be moved to non-free.

-- System Information:
Debian Release: 6.0.4
  APT prefers stable
  APT policy: (800, 'stable'), (600, 'unstable'), (500, 'stable-updates')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#632604: libatomic-ops: FTBFS on i386

[Javi Merino]

tags 632604 unreproducible
thanks

Hi,

I built it in my real i386 machine just fine.

Cheers,
Javi


signature.asc
Description: Digital signature

Bug#660075: autofs5: Typo in man page for auto.master(5)

[Javi Merino]

Package: autofs5
Version: 5.0.4-3.2
Followup-For: Bug #660075

It's also wrong in the manpage of autofs(8).  Find a fix for both of
them in the attached patch.
--- a/man/auto.master.5.in
+++ b/man/auto.master.5.in
@@ -394,5 +394,5 @@
 .BR autofs (8).
 .SH AUTHOR
 This manual page was written by Christoph Lameter ch...@waterf.org,
-for the Dean GNU/Linux system.  Edited by h...@transmeta.com and
+for the Debian GNU/Linux system.  Edited by h...@transmeta.com and
 Ian Kent ra...@themaw.net .
--- a/man/autofs.8.in
+++ b/man/autofs.8.in
@@ -52,5 +52,5 @@
 .BR auto.master (5).
 .SH AUTHOR
 This manual page was written by Christoph Lameter ch...@waterf.org,
-for the Debi GNU/Linux system.  Edited by H. Peter Anvin
+for the Debian GNU/Linux system.  Edited by H. Peter Anvin
 h...@transmeta.com.

Bug#658599: subversion: Recommend openssh-client

[Javi Merino]

Package: subversion
Version: 1.6.12dfsg-6
Severity: minor

To check out svn+ssh repositories you need a ssh client.  Please add 
openssh-client to Recommends.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654925: mercurial: hg-ssh is installed system-wide but uses /usr/bin/env python as the python interpreter

[Javi Merino]

Package: mercurial
Version: 2.0.1-2
Severity: minor

From ubuntu:

https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/912625

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mercurial depends on:
ii  libc6 2.13-24
ii  mercurial-common  2.0.1-2
ii  python2.7.2-9
ii  python2.6 2.6.7-4
ii  python2.7 2.7.2-9
ii  ucf   3.0025+nmu2

mercurial recommends no packages.

Versions of packages mercurial suggests:
pn  kdiff3 | tkdiff | meld | xxdiff  none
pn  qct  none
pn  vim  2:7.3.363-1
pn  wish none

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651698: devscripts: [debcommit] Support committing to mercurial patch queues

[Javi Merino]

Package: devscripts

Version: 2.11.2
Severity: wishlist
Tags: patch

When using a mercurial repository with patch queues, debcommit should
refresh the current patch instead of committing the changes.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=36d4e4f5

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages devscripts depends on:
ii  dpkg-dev   1.16.1.2
ii  libc6  2.13-21 
ii  perl   5.14.2-6
ii  python 2.7.2-9 
ii  python2.6  2.6.7-4 
ii  python2.7  2.7.2-8 

Versions of packages devscripts recommends:
ii  at3.1.13-1 
ii  curl  7.23.1-2 
ii  dctrl-tools   2.20 
ii  debian-keyring2011.12.01   
ii  dput  0.9.6.2  
ii  equivsnone   
ii  fakeroot  1.18.2-1 
ii  gnupg 1.4.11-3 
ii  libcrypt-ssleay-perl  0.57-2+b3
ii  libjson-perl  2.53-1   
ii  libparse-debcontrol-perl  2.005-3  
ii  libsoap-lite-perl 0.714-1  
ii  liburi-perl   1.59-1   
ii  libwww-perl   6.03-1   
ii  lintian   2.5.4
ii  man-db2.6.0.2-3
ii  patch 2.6.1-2  
ii  patchutils0.3.2-1  
ii  python-debian 0.1.21   
ii  python-magic  5.09-2   
ii  sensible-utils0.0.6
ii  strace4.5.20-2.3   
ii  unzip 6.0-5
ii  wdiff 0.6.5-1  
ii  wget  1.13.4-1 
ii  xz-utils  5.1.1alpha+20110809-3

Versions of packages devscripts suggests:
pn  bsd-mailx [mailx]8.1.2-0.2006cvs-1
pn  build-essential  11.5 
pn  cvs-buildpackage none   
pn  devscripts-el35.2 
pn  gnuplot  none   
pn  libauthen-sasl-perl  none   
pn  libfile-desktopentry-perl0.04-3   
pn  libnet-smtp-ssl-perl 1.01-3   
pn  libterm-size-perl0.2-4+b3 
pn  libtimedate-perl 1.2000-1 
pn  libyaml-syck-perlnone   
pn  mutt none   
pn  openssh-client [ssh-client]  1:5.9p1-2
pn  svn-buildpackage 0.8.4
pn  w3m  none   

-- no debconf information
From 6bf9659bedff168e5ac2a59dfa86237d5a28c197 Mon Sep 17 00:00:00 2001
From: Javi Merino cibervi...@gmail.com
Date: Sat, 10 Dec 2011 16:32:50 +
Subject: [PATCH] debcommit: Learn to commit to hg patch queues

---
 scripts/debcommit.pl |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/scripts/debcommit.pl b/scripts/debcommit.pl
index 815b786..f255786 100755
--- a/scripts/debcommit.pl
+++ b/scripts/debcommit.pl
@@ -517,7 +517,7 @@ sub commit {
 	if (@files_to_commit and $all);
 
 my $action_rc;  # return code of external command
-if ($prog =~ /^(cvs|svn|svk|hg)$/) {
+if ($prog =~ /^(cvs|svn|svk)$/) {
 	if (!@files_to_commit  $onlydebian) {
 	@files_to_commit = (debian);
 	}
@@ -583,6 +583,18 @@ sub commit {
 	$action_rc = action($prog, record, --logfile, $fh, -a, @files_to_commit);
 	}
 }
+elsif ($prog eq 'hg') {
+	if (!@files_to_commit  $onlydebian) {
+	@files_to_commit = (debian);
+	}
+
+	if ($diffmode) {
+$action_rc = action($prog, diff, @files_to_commit);
+} else {
+my $commit_type = (-s .hg/patches/status)? qref : commit;
+	$action_rc = action($prog, $commit_type, -m, $message, @files_to_commit);
+}
+}
 else {
 	die debcommit: unknown program $prog;
 }
-- 
1.7.7.3

Bug#649644: python-software-properties: Link apt-add-repository manpage to add-apt-repository

[Javi Merino]

Package: python-software-properties
Version: 0.76.7debian2+nmu1
Severity: minor

apt-add-repository is a symlink of add-apt-repository, can you please also 
symlink the manpage so that users running man apt-add-repository aren't 
greeted with the dreaded No manual entry for apt-add-repository?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#636396: mercurial: Problem seems fixed.

[Javi Merino]

Hi Melanie,

On 02/11/11 23:44, Melanie Davis wrote:
 I installed the latest update.  Both clone and commit completed without
 error. 

Good, but I saw some problems with 2.0-1 in armel and that's why I
didn't close the bug.  In fact, be careful with what you have committed
with that version, even if the commit finished correctly it may be
corrupt.  Please use hg verify to check that everything is correct.

Can you update to 2.0-2 when that's available for armel?

Cheers,
Javi (Vicho)




signature.asc
Description: OpenPGP digital signature

Bug#646546: mercurial fails to run: abort: couldn't find mercurial libraries in [/usr/bin /usr/lib/python2.6 [...]

[Javi Merino]

On 25/10/11 00:40, Thilo-Alexander Ginkel wrote:
 Package: mercurial
 Version: 1.6.4-1
 Severity: normal
 Tags: squeeze
 
 Mercurial as installed on a fresh Debian 6.0 installation fails to execute 
 with the following error message:
 
 tg@vega ~$ hg
 abort: couldn't find mercurial libraries in [/usr/bin /usr/lib/python2.6 
 /usr/lib/python2.6/plat-linux2 /usr/lib/python2.6/lib-tk 
 /usr/lib/python2.6/lib-old /usr/lib/python2.6/lib-dynload 
 /usr/local/lib/python2.6/dist-packages /usr/lib/python2.6/dist-packages 
 /usr/lib/pymodules/python2.6]
 (check your install and PYTHONPATH)

Can you please run ls /usr/lib/pymodules/python2.6/ and debsums -c
mercurial mercurial-common (you may need to install the debsums package)?

Can you try to reinstall the package with aptitude install --reinstall
mercurial mercurial-common? It should say Processing triggers for
python-support ... as part of the output.

I've just installed mercurial in a fresh squeeze install and it works
for me.

 Some more verbose output:
 
 tg@vega ~$ PYTHONVERBOSE=x hg
 # installing zipimport hook
 import zipimport # builtin
 # installed zipimport hook
 # /usr/lib/python2.6/site.pyc matches /usr/lib/python2.6/site.py
 import site # precompiled from /usr/lib/python2.6/site.pyc
 # /usr/lib/python2.6/os.pyc matches /usr/lib/python2.6/os.py
 import os # precompiled from /usr/lib/python2.6/os.pyc
 import errno # builtin
 import posix # builtin
 # /usr/lib/python2.6/posixpath.pyc matches /usr/lib/python2.6/posixpath.py
 import posixpath # precompiled from /usr/lib/python2.6/posixpath.pyc
 # /usr/lib/python2.6/stat.pyc matches /usr/lib/python2.6/stat.py
 import stat # precompiled from /usr/lib/python2.6/stat.pyc
 # /usr/lib/python2.6/genericpath.pyc matches /usr/lib/python2.6/genericpath.py
 import genericpath # precompiled from /usr/lib/python2.6/genericpath.pyc
 # /usr/lib/python2.6/warnings.pyc matches /usr/lib/python2.6/warnings.py
 import warnings # precompiled from /usr/lib/python2.6/warnings.pyc
 # /usr/lib/python2.6/linecache.pyc matches /usr/lib/python2.6/linecache.py
 import linecache # precompiled from /usr/lib/python2.6/linecache.pyc
 # /usr/lib/python2.6/types.pyc matches /usr/lib/python2.6/types.py
 import types # precompiled from /usr/lib/python2.6/types.pyc
 # /usr/lib/python2.6/UserDict.pyc matches /usr/lib/python2.6/UserDict.py
 import UserDict # precompiled from /usr/lib/python2.6/UserDict.pyc
 # /usr/lib/python2.6/_abcoll.pyc matches /usr/lib/python2.6/_abcoll.py
 import _abcoll # precompiled from /usr/lib/python2.6/_abcoll.pyc
 # /usr/lib/python2.6/abc.pyc matches /usr/lib/python2.6/abc.py
 import abc # precompiled from /usr/lib/python2.6/abc.pyc
 # /usr/lib/python2.6/copy_reg.pyc matches /usr/lib/python2.6/copy_reg.py
 import copy_reg # precompiled from /usr/lib/python2.6/copy_reg.pyc
 # /usr/lib/python2.6/sitecustomize.pyc matches 
 /usr/lib/python2.6/sitecustomize.py
 import sitecustomize # precompiled from /usr/lib/python2.6/sitecustomize.pyc
 import encodings # directory /usr/lib/python2.6/encodings
 # /usr/lib/python2.6/encodings/__init__.pyc matches 
 /usr/lib/python2.6/encodings/__init__.py
 import encodings # precompiled from /usr/lib/python2.6/encodings/__init__.pyc
 # /usr/lib/python2.6/codecs.pyc matches /usr/lib/python2.6/codecs.py
 import codecs # precompiled from /usr/lib/python2.6/codecs.pyc
 import _codecs # builtin
 # /usr/lib/python2.6/encodings/aliases.pyc matches 
 /usr/lib/python2.6/encodings/aliases.py
 import encodings.aliases # precompiled from 
 /usr/lib/python2.6/encodings/aliases.pyc
 # /usr/lib/python2.6/encodings/utf_8.pyc matches 
 /usr/lib/python2.6/encodings/utf_8.py
 import encodings.utf_8 # precompiled from 
 /usr/lib/python2.6/encodings/utf_8.pyc
 Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
 [GCC 4.4.5] on linux2
 Type help, copyright, credits or license for more information.
 abort: couldn't find mercurial libraries in [/usr/bin /usr/lib/python2.6 
 /usr/lib/python2.6/plat-linux2 /usr/lib/python2.6/lib-tk 
 /usr/lib/python2.6/lib-old /usr/lib/python2.6/lib-dynload 
 /usr/local/lib/python2.6/dist-packages /usr/lib/python2.6/dist-packages 
 /usr/lib/pymodules/python2.6]
 (check your install and PYTHONPATH)
 # clear __builtin__._
 [...]
 
 Manually attempting to import mercurial from a python shell also fails (but 
 succeeds on Lenny, where mercurial is also working correctly):
 
 tg@vega ~$ python
 Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
 [GCC 4.4.5] on linux2
 Type help, copyright, credits or license for more information.
 import mercurial
 Traceback (most recent call last):
   File stdin, line 1, in module
 ImportError: No module named mercurial
 
 
 -- System Information:
 Debian Release: 6.0.3
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 2.6.32-028stab092.1 (SMP w/1 CPU core)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 Versions