Re: git-dpm -> gbp conversion (mass-change)

[Nikolaus Rath]

On Aug 08 2018, Thomas Goirand  wrote:
> On 08/08/2018 01:38 PM, Nikolaus Rath wrote:
>> That doesn't make sense to me. git-dpm maintains (and rebases) Debian
>> patches separately, so upgrading to a new upgrade release can
>> principally not be any harder than with gbp.
>
> It is a nightmare when patches are conflicting.

Could you give an example where this is handled differently by git-dpm
than by gbp? As I said, the problem is exactly the same.


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

Re: Please add me on Salsa

[Nikolaus Rath]

On Apr 05 2018, Piotr Ożarowski <pi...@debian.org> wrote:
> Hi Nikolaus,
>
> [Nikolaus Rath, 2018-04-03]
>> Could someone please add me to the DPMT and DPAP teams on Salsa? My
>> Alioth and Salsa username is nikratio-guest.
>
> what do you think about our policy and on which packages do you want to
> work with us?

Huh? I have been member of the team for a few years already, I'm just
not registered on Salsa yet (as far as I know Alioth memberships don't
transfer automatically).

But yeah, I am still committed to abide by the policy, and I am
maintaining the python-llfuse and python-dugong packages.


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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


signature.asc
Description: PGP signature

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Nikolaus Rath]

On Feb 14 2017, Scott Kitterman  wrote:
> How does dgit avoid maintainer forgot to push problems without being
> limited to the granularity of one commit per upload?

It does not. Until 'dgit push' is called the next time, it will revert
to one commit per upload for the "dark" period.

I am not sure if the next dgit push will retroactively fix history, or
only affect changes that have not yet been uploaded.

Best,
-Nikolaus

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

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

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Nikolaus Rath]

On Feb 10 2017, Scott Kitterman <deb...@kitterman.com> wrote:
> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath <nikol...@rath.org> wrote:
>>On Feb 10 2017, Scott Kitterman <deb...@kitterman.com> wrote:
>>>>No. You are confusing dgit with one particular way to use it. You can
>>>>use dgit with the maint-merge workflow mentioned above, you can use
>>>>dgit
>>>>with git-dpm, and you can use dgit with gbp.
>>>
>>> OK.  So then I gather it's effectively a layer on top of 'normal'
>>> things like gbp-pq or git-dpm?  What added value would it provide?
>>
>>Among other things, it enables users to run 'dgit clone', and get an
>>up-to-date, patches-applied copy of the most recent source package.
>
> How is that different/better than debcheckout?

It works all the time. debcheckout does not guarantee you the newest
version (VCS may lag behind Debian archive), nor does it guarantee a
patches applied, complete package (you might end up with just debian/,
patches-unapplied, or even weirder things).

Best,
-Nikolaus

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

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

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Nikolaus Rath]

On Feb 10 2017, Scott Kitterman  wrote:
>>No. You are confusing dgit with one particular way to use it. You can
>>use dgit with the maint-merge workflow mentioned above, you can use
>>dgit
>>with git-dpm, and you can use dgit with gbp.
>
> OK.  So then I gather it's effectively a layer on top of 'normal'
> things like gbp-pq or git-dpm?  What added value would it provide?

Among other things, it enables users to run 'dgit clone', and get an
up-to-date, patches-applied copy of the most recent source package.

But it seems to me that you are contemplating whether or not the team
should be using dgit. This is also not a decision that needs to be made
prior to any switch away from dgit-dpm, you can start using dgit at any
point.


Best,
-Nikolaus

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

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

Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

[Nikolaus Rath]

On Feb 07 2017, Barry Warsaw  wrote:
> On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote:
>
>>I know the discussion is leaning towards replacing usage of git-dpm
>>with gbp-pq. I have nothing against it but, since we are talking about
>>solutions for a git-centric workflow, has anyone considered the dgit-
>>maint-merge workflow [1]?
>
> As I understand it, there are a few design choices that make dgit less
> desirable for this team.

No. You are confusing dgit with one particular way to use it. You can
use dgit with the maint-merge workflow mentioned above, you can use dgit
with git-dpm, and you can use dgit with gbp.

Best,
-Nikolaus

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

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

Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)

[Nikolaus Rath]

On Jan 23 2017, Brian May  wrote:
> I don't particular care what we move to, however it seems to me that we
> really should be dropping git-dpm.

I think git-dpm works very nice as long as the package doesn't get too
complex. I think it would be overreaction to convert all packages, just
because git-dpm is unsuitable for some of them.

Best,
-Nikolaus

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

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

Re: Team maintained packages and git-dpm (was Re: Team upload for python-jedi)

[Nikolaus Rath]

On Jan 23 2017, Brian May  wrote:
[ Convert from git-dpm to gbp ]
> Or would dgit be a better option? I confuse I don't really understand
> dgit.

dgit can be used with both git-dpm and gbp. Moving to dgit-only would
mean to use a single-debian-patch.


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

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

Potential issue when using dgit for DPMT modules

[Nikolaus Rath]

Hello,

This is just a heads-up for a potential issue that you may encounter
when you attempt to use dgit for a DPMT module (bug 850005).

If an attempt to do "dgit --dpm build-source" fails with something like:

,
| $ dgit --dpm --clean=git build-source 
| Format `3.0 (quilt)', need to check/update patch stack
| examining quilt state (multiple patches, dpm mode)
| dgit: split brain (separate dgit view) may be needed (--quilt=dpm).
| dgit: base trees orig=c8ab943f37df17d83f09 o+d/p=9e2aab849fc3a861ab5a
| dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
| dgit: quilt differences:  HEAD ## o+d/p   HEAD == o+d/p
| dgit: --quilt=dpm specified, implying patches-applied git tree
| dgit:  but git tree differs from result of applying debian/patches to upstream
`

Then the problem might be that some files that are present in the
upstream branch are not present in the master branch, but the deletion
has not been recorded in the patched branch.

In the case of python-llfuse, the missing files were:

$ git diff --stat 9e2aab849fc3a861ab5a..HEAD^ | grep -v " debian"
 src/llfuse.egg-info/PKG-INFO|  80 -
 src/llfuse.egg-info/SOURCES.txt | 108 
 src/llfuse.egg-info/dependency_links.txt|   1 -
 src/llfuse.egg-info/requires.txt|   1 -
 src/llfuse.egg-info/top_level.txt   |   1 -
 src/llfuse.egg-info/zip-safe|   1 -
 24 files changed, 93 insertions(+), 192 deletions(-)


In this case, the files were removed in commit 2d78b, which is the
"merge patched into master" commit generated by git-dpm.

In general, however, git-dpm seems to handle removals in the patched
branch just fine, so I suspect that this problem is either an artifact
of the import from svn-buildpackage, or I may have manually amended the
merge commit and now forgot about it.

In the former case, other packages that were batch converted from SVN
may have a similar problem.

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

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

Re: Upstream build system, Sphinx autodoc, Python import path

[Nikolaus Rath]

On Sep 30 2016, Florent Rougon  wrote:
>>> Instead of attempting circumvention of the effect of using intersphinx,
>>> it's best to simply *DISABLE* intersphinx in the conf.py of the
>>> documentation.
>>
>> Even better than disabling intersphinx is to ship the required data in
>> the package, e.g:
>
> Or use the following alternative, which lets the user browse the
> documentation offline.

Which just goes to show that there is no solution that can't be further
improved :-). Thanks!


Best,
-Nikolaus

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

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

Re: Upstream build system, Sphinx autodoc, Python import path

[Nikolaus Rath]

On Sep 29 2016, Thomas Goirand <z...@debian.org> wrote:
> On 09/27/2016 10:48 AM, Ben Finney wrote:
>> https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation
>
> I just had a quick look to that page, not only it advises to override
> the wrong dh sequence, but also it gives stupid advices for intersphinx:
>
> "sphinx-build might try to access the Internet to fetch intersphinx
> inventory files; http_proxy set to 127.0.0.1:9 will prevent that."
>
> Instead of attempting circumvention of the effect of using intersphinx,
> it's best to simply *DISABLE* intersphinx in the conf.py of the
> documentation. Setting-up http_proxy / https_proxy to do that, really,
> is the wrong way. Lots of my packages contain intersphinx disabling
> patches.

Even better than disabling intersphinx is to ship the required data in
the package, e.g:

$ cat debian/patches/use-local-intersphinx-inventory.patch 
>From 48e6c33f77106b9368e7db430d296ba6c31e47a6 Mon Sep 17 00:00:00 2001
From: Nikolaus Rath <nikol...@rath.org>
Date: Thu, 8 Oct 2015 12:24:34 -0700
Subject: Use local intersphinx inventory

Forwarded: not-needed
Last-Update: 2011-07-06
 Instead of downloading the Python intersphinx directory
 at build time, use the cached copy shipped in debian/.
Patch-Name: use-local-intersphinx-inventory.patch
---
 rst/conf.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rst/conf.py b/rst/conf.py
index 2290d..f6425 100644
--- a/rst/conf.py
+++ b/rst/conf.py
@@ -27,7 +27,8 @@ extensions = ['sphinx.ext.autodoc', 'sphinx.ext.intersphinx',
   'sphinx_cython' ]
 
 # Link to Python standard library
-intersphinx_mapping = {'python': ('http://docs.python.org/3/', None) }
+intersphinx_mapping = {'python': ('http://docs.python.org/3/',
+  '../debian/python.inv')}
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']

$ grep intersphinx -C 1 debian/rules  

update_intersphinx:
wget http://docs.python.org/3/objects.inv -O debian/python.inv



Best,
-Nikolaus

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

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

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Nikolaus Rath]

On Aug 10 2016, Thomas Goirand  wrote:
> As I only heard complains about git-dpm, maybe someone would like to
> express his joy using it, and explain why they think it's a nice tool.
> But is there such person? It seems git-dpm only brings frustration.

In my opinion, git-dpm solves the problem of keeping a full history of
Debian source packages (i.e., patches applied and debian/patches/
populated) as well as possible. This means that it is often painful.

I think the only way to make this less painful is to get rid of the idea
of managing patches in a VCS and use something like gitpkg. This has the
drawback source package is now *generated* from the Git repository
(i.e., you can't do git clone + debuild), but it makes maintaining the
Git repository much less painful. Judging from all the attempts I've
seen so far, trying to put patches (i.e., the output of a VCS) under
version-control is just a doomed endeavor.


I don't believe that switching from git-dpm to git-buildpackage is going
to make things easier, it'll just be trading one set of problems for
another.


Best,
-Nikolaus

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

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

Is pristine-tar failing just for me?

[Nikolaus Rath]

Hello,

Whenever I use pristine-tar, I'm getting the following warning:

| warning: pristine-gz cannot reproduce build of [whatever].orig.tar.gz; 
storing 85% size diff in delta
| (Please consider filing a bug report so the delta size can be improved.)

I've reported this as a bug, but since pristine-tar is unmaintained I
don't except any quick fix.

However, I am wondering: am I the only one who sees this, or do other
people here have the same issue?

The most recent example is the python-llfuse tarball. It is generated by
uscan after filtering out non-DFSG files.

Best,
-Nikolaus

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

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

Can I upload a Python application to DPMT?

[Nikolaus Rath]

Hello,

Would anyone have a problem with me moving the s3ql package from the
DPAT to the DPMT repository? I want to switch from svn to git (-dpm).

If that's not a good idea, I'll create some new git repo somewhere, but
I figured that DPMT might be better.

Best,
-Nikolaus

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

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

How to put experimental upload into git

[Nikolaus Rath]

Hello,

I'd like to upload the newest python-llfuse release to 
experimental first.


Are there any best practices for handling this on the git side? I 
could imagine:


* Don't commit anything to git at all (it would only be a single 
commit 
  for the upload), commit when uploading to unstable.


* Commit regularly, with the upload to unstable becoming a 
descendant 
  of the upload to experimental.


* Commit to a new branch that then becomes dangling, because the 
next 
  upload to unstable descends from the most-recent unstable 
  upload rather than from experimental.


Thoughts?

Thanks,
-Nikolaus

(No Cc on replies please, I'm reading the list)
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

Re: Bug#810136: transition: python3-defaults (python3.5 as default python3)

[Nikolaus Rath]

On Jan 06 2016, Scott Kitterman  wrote:
> 5.  Cython3 not currently working [3].  This appears to be due to a change in
> python3.5.  It affects borgbackup and s3ql only.  As these are rather late in
> the transition, we could probably go ahead while this is getting sorted.  
> These
> are both leaf applications that would become temporarily
> uninstallable.

If necessary, s3ql can also be build with cython instead of cython3.


Best,
-Nikolaus

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

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

Re: Rebuild for packages with entry points?

[Nikolaus Rath]

On Dec 07 2015, Simon McVittie <s...@debian.org> wrote:
> On 07/12/15 19:00, Barry Warsaw wrote:
>> On Dec 07, 2015, at 10:22 AM, Nikolaus Rath wrote:
>>> It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/
>>> fixed in stretch.
>> 
>> I'm also not sure how many packages it affects in practice.  We could also 
>> let
>> rebuilds be bug-driven.
>
> This looks like a job for Lintian, assuming setuptools entry points are
> easy to detect with a regex.

Well, yes, but what's the point? New uploads will not be affected by
this bug anyway, and if you just want the warnings for old packages,
wouldn't the time consumed by writing a Lintian check be better spent
writing a script that triggers rebuilds directly?


Best,
-Nikolaus

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

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

Re: Rebuild for packages with entry points?

[Nikolaus Rath]

On Dec 07 2015, Barry Warsaw <ba...@debian.org> wrote:
> On Dec 07, 2015, at 10:22 AM, Nikolaus Rath wrote:
>
>>Would it make sense to do a no-change rebuild for all Python packages
>>that use setuptool's entry point functionality?
>>
>>It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/
>>fixed in stretch. I believe most packages will see new releases anyway
>>(and thus get the change), but I believe there are at least some
>>packages that are rarely touched...
>
> I'm also not sure how many packages it affects in practice.  We could also let
> rebuilds be bug-driven.

Aeh, you know about a bug and you want to delay fixing it until someone
has reporeds it for every affected package? This seems like a pretty
inconsiderate waste of time for both users and maintainers.


Best,
-Nikolaus

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

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

Re: Rebuild for packages with entry points?

[Nikolaus Rath]

On Dec 08 2015, Barry Warsaw <ba...@debian.org> wrote:
> On Dec 08, 2015, at 08:48 AM, Nikolaus Rath wrote:
>
>>Aeh, you know about a bug and you want to delay fixing it until someone
>>has reporeds it for every affected package? This seems like a pretty
>>inconsiderate waste of time for both users and maintainers.
>
> There are always lots of bugs that affect people.

True - but I have to admit that I don't get the connection to what we
(or at least I) were discussing until now..?

> But hey, don't let me stop you if you want to fix this particular one.

Well, my proposal is to just do a mass rebuild. It will be redundant for
a lot of packages, but computer time is much cheaper than developer time
(which would be required for Lintian checks, or writing, reacting to,
and closing per-package bugreports).

However, I don't know how to trigger such a rebuild, and I think if I
knew it I'd still be unable to actually do it because I'm only a
DM. Thus my mail to this list :-).


Best,
-Nikolaus

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

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

Rebuild for packages with entry points?

[Nikolaus Rath]

Hello,

Would it make sense to do a no-change rebuild for all Python packages
that use setuptool's entry point functionality?

It'd be nice to have https://bitbucket.org/pypa/setuptools/issues/443/
fixed in stretch. I believe most packages will see new releases anyway
(and thus get the change), but I believe there are at least some
packages that are rarely touched...


Best,
-Nikolaus

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

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

Re: pybuild: passing {dir}/tests to nose/pytest by default duplicated binary

[Nikolaus Rath]

On Oct 14 2015, Piotr Ożarowski  wrote:
>> export PYBUILD_TEST_ARGS={dir}/tests
>
> should I do that by default in pybuild if
> * "test" or "tests" directory is detected
> * PYBUILD_TEST_ARGS is not set
> * nose or pytest test suite is used

Yes please!


Best,
-Nikolaus

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

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

Re: [DPMT] radical changes: automation, carrot and stick

[Nikolaus Rath]

On Oct 07 2015, Piotr Ożarowski  wrote:
> I no longer think requiring contribution (the 3 months thing) is a good
> idea for DPMT (might be for a new team).
>
> I assume you all like other ideas, like no team in Maintainer, right?
>
> * team only in Uploaders field, the main contact (AKA Maintainer) has to
>   be real person (reason: nobody reads -team mailing list) + automatic
>   team subscription via script that sets up git repository
> * emails with all commits (diffs) made by someone not listed in Maintainer
>   are automatically sent to Maintainer

Sounds good to me.

> * when someone who is not listed in debian/control (i.e.
>   Maintainer/Uploaders) wants to upload team package - just commit
>   and upload to DELAYED/2 (in case of RC bug) or to DELAYED/7, no need
>   to notify anyone, because...

No opinion, I'd need a sponsor anyway.


> * removal¹ of packages (not person) from the team if there's no
>   contribution in 3 months in a row (and given person is not MIA, as in
>   active in other packages, for MIA ones: decide if someone wants to
>   take over or orphan the package, no more team packages that nobody
>   takes care of and no objections if someone takes over your package)
>
> [¹] as in upload to unstable without DPMT in Uploaders, repo stays in
> case one decides come back

Not sure about that one. What would be gained by this? What if the
package is simply in good shape and doesn't need contributions?


Best,
-Nikolaus

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

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

pybuild: how to pass multiple test args?

[Nikolaus Rath]

Hello,

I have the following in debian/rules:

export PYBUILD_TEST_PYTEST=1
export PYBUILD_TEST_ARGS=--installed {dir}/test/

In unstable, this gives the following result:

make[1]: Leaving directory '/«BUILDDIR»/python-llfuse-0.41.1+dfsg'
   dh_auto_test -O--buildsystem=pybuild
pybuild --test --test-pytest -i python{version} -p 2.7 --dir .
I: pybuild base:170: cd 
/«BUILDDIR»/python-llfuse-0.41.1+dfsg/.pybuild/pythonX.Y_2.7/build; python2.7 
-m pytest --installed /«BUILDDIR»/python-llfuse-0.41.1+dfsg/test/
= test session starts ==
platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.7.2
rootdir: /«BUILDDIR»/python-llfuse-0.41.1+dfsg, inifile: 
ERROR: file not found: --installed /«BUILDDIR»/python-llfuse-0.41.1+dfsg/test/

In other words, the two arguments are passed as one.

How can I pass them separately? 


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

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

pybuild: build for any one interpreter?

[Nikolaus Rath]

Hello,

I'd like to use pybuild for a Python application. Is there a way to tell
it to build with any *one* Python interpreter? The -p version always me
to select one specific interpreter, but it would be nice if I could tell
it to use whatever interpreter is available (but not all of them).

Best,
-Nikolaus

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

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

Re: Please upload python-llfuse from DPMT SVN

[Nikolaus Rath]

On Aug 08 2015, Piotr Ożarowski pi...@debian.org wrote:
 [Nikolaus Rath, 2015-08-08]
 Does anyone have time to sponsor an upload of python-llfuse from the
 DPMT SVN repository to unstable?

 my sbuild claims cython3 is not installable, that's why I didn't upload
 it yet

Ah, ok. I assumed you were busy with other things when I didn't hear
anything back.

(The cython issue is #794511)

Thanks!
-Nikolaus

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

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


signature.asc
Description: PGP signature

Please upload python-llfuse from DPMT SVN

[Nikolaus Rath]

Hello,

Does anyone have time to sponsor an upload of python-llfuse from the
DPMT SVN repository to unstable?

I've updated the package to a new Debian revision that fixes the
following bugs:

python-llfuse (0.40+dfsg-2) unstable; urgency=medium

  * Correctly handle symlink-to-directory transition of 
/usr/share/doc/{python,python3}-llfuse-dbg when upgrading from jessie.
Closes: #788161.
  * Add versioned Breaks and Conflicts to -dbg packages to avoid
upgrade problems due to moved file. Closes: #781652.
  * Put debugging symbols for regular interpreter into -dbg
package again. Closes: #781719.
  * Bumped Standards-Version to 3.9.6 (no changes needed).
  * Added missing build-depends on cython3 and cython-dbg. 
Closes: #794056.

 -- Nikolaus Rath nikol...@rath.org  Wed, 29 Jul 2015 20:49:49 -0700


The package builds cleanly in a sid chroot as of several days ago (right
now it doesn't build because cython has become uninstallable).


Related to that, it would be fantastic if someone could also give me
upload permissions for this package, so that I can do future uploads on
my own (I'm a DM).


Best,
-Nikolaus

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

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


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

nose2 vs pytest (was: Python 2, Python 3, Stretch Buster)

[Nikolaus Rath]

On Apr 23 2015, Barry Warsaw ba...@debian.org wrote:
 There *are* however proven, stable tools that improve the Python coding and
 maintenance experience and for me, tox is one of those.  There are others,
 such as nose2, that I won't even start a new project without adopting from the
 first commit.

Are you by any chance also familiar with pytest and could same a few
word about pros/cons?

I've chosen pytest over nose1 because of the richer feature set for
writing tests, but I think in several cases pytest is suffering from its
own complexity (eg. https://bitbucket.org/pytest-dev/pytest/issue/635/).
Reading your comment I was wondering if nose2 might be a better choice,
but the nose2 manual wasn't very informative at all (I actually did not
found any information about how to write tests).

Best,
-Nikolaus

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

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


signature.asc
Description: PGP signature

Re: dh_python3: how to use .pydist file?

[Nikolaus Rath]

On Feb 17 2015, Piotr Ożarowski pi...@debian.org wrote:
 [Ben Finney, 2015-02-17]
 The question remains, though: where should that fact (and many others
 like it) be documented so newcomers don't have to keep asking?

 I guess dependencies section in dh.python{2,3} manpage should be more
 clear that README.PyDist is about .pydist and pydist-overrides files.
 Patches are welcome.

Already done after your first response (#778633) :-).

Best,
-Nikolaus

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

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


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

Re: dh_python3: how to use .pydist file?

[Nikolaus Rath]

On Feb 17 2015, Nikolaus Rath nikol...@rath.org wrote:
 On Feb 17 2015, Piotr Ożarowski pi...@debian.org wrote:
 [Ben Finney, 2015-02-17]
 The question remains, though: where should that fact (and many others
 like it) be documented so newcomers don't have to keep asking?

 I guess dependencies section in dh.python{2,3} manpage should be more
 clear that README.PyDist is about .pydist and pydist-overrides files.
 Patches are welcome.

 Already done after your first response (#778633) :-).

Here's a revised patch that also documents the format of the
py3dist-overrides file:

diff --git a/dh_python3.rst b/dh_python3.rst
--- a/dh_python3.rst
+++ b/dh_python3.rst
@@ -38,14 +38,38 @@
 
 dependencies
 
-dh_python3 tries to translate Python dependencies from requires.txt file to
-Debian dependencies. Use debian/py3dist-overrides or --no-guessing-deps option
-to override it if the guess is incorrect. If you want dh_python3 to generate
-more strict dependencies (f.e. to avoid ABI problems) create
-debian/python3-foo.pydist file. See /usr/share/doc/dh-python/README.PyDist
-for more information. If the pydist file contains PEP386 flag or set of (uscan
-like) rules, dh_python3 will make the depedency versioned (version requirements
-are ignored by default).
+
+dh_python3 tries to translate Python dependencies from the
+`requires.txt` file to Debian dependencies. In many cases, this works
+without any additional configuration because dh_python3 comes with a
+build-in mapping of Python module names to Debian packages that is
+periodically regenerated from the Debian archive. By default, the
+version information in the Python dependencies is discarded. If you
+want dh_python3 to generate more strict dependencies (e.g. to avoid
+ABI problems), or if the automatic mapping does not work correctly for
+your package, you have to provide dh_python3 with additional rules for
+the translation of Python module to Debian package dependencies.
+
+For a package *python3-foo* that depends on a package *python3-bar*,
+there are two files that may provide such rules:
+
+#. If the *python3-foo* source package ships with a
+   `debian/py3dist-overrides` file, this file is used by dh_python3
+   during the build of *python3-foo*.
+
+#. If the *python3-bar* source package ships with a
+   `debian/python3-bar.pydist` file (and uses dh_python3), this file
+   will be included in the binary package as
+   `/usr/share/dh-python/dist/cpython3/python3-bar`. During the build
+   of *python3-foo*, dh_python3 will then find and use the file.
+
+Both files have the same format described in
+`/usr/share/doc/dh-python/README.PyDist`. If all you want is to
+generate versioned dependencies (and assuming that the *python3-bar*
+package provides the *pybar* Python module), in most cases it will be
+sufficient to put the line ``pybar python3-bar; PEP386`` into either
+of the above files.
+
 
 private dirs
 

Best,
-Nikolaus

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

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

Re: dh_python3: how to use .pydist file?

[Nikolaus Rath]

On Feb 17 2015, Piotr Ożarowski pi...@debian.org wrote:
 [Nikolaus Rath, 2015-02-17]
 I'm trying to get dh_python to generate versioned dependencies for the
 s3ql package (available in the python-apps SVN repository).
 
 I have created a file debian/s3ql.pydist with the contents:
 
 $ cat debian/s3ql.pydist 
 dugong python3-dugong; PEP386

 pydist file is not the way to go. Purpose of this file is to customise
 what dh_pythonX generates when OTHER packages try to generate dependency
 for s3ql (and since your binary package name doesn't have python
 prefix it should not provide public module/extension and hence not
 install pydist file).

 What you want is debian/py3dist-overrides file or pydist file
 in python3-dugong package

Oh, ok. Where do I find the format of the py3dist-overrides file?
Neither dh_python3(1), nor /usr/share/doc/dh-python, nor Google was able
to tell me...

Thanks!
-Nikolaus

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

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


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

dh_python3: how to use .pydist file?

[Nikolaus Rath]

Hello,

I'm trying to get dh_python to generate versioned dependencies for the
s3ql package (available in the python-apps SVN repository).

I have created a file debian/s3ql.pydist with the contents:

$ cat debian/s3ql.pydist 
dugong python3-dugong; PEP386

The requirements in setup.py are:

$ cat src/s3ql.egg-info/requires.txt 
apsw = 3.7.0
pycrypto
requests
defusedxml
dugong = 3.4
llfuse = 0.39

When creating the s3ql package, I get the output:

[...]
  dh_python3
D: dh_python3 dh_python3:149: version: 1.2014-2
D: dh_python3 dh_python3:150: argv: ['/usr/bin/dh_python3']
D: dh_python3 dh_python3:151: options: {'depends': None, 'suggests': None, 
'skip_private': False, 'no_ext_rename': False, 'recommends': None, 'package': 
None, 'verbose': False, 'no_shebang_rewrite': False, 'guess_deps': True, 
'no_package': None, 'shebang': None, 'vrange': None, 'clean_dbg_pkg': True, 
'regexpr': None, 'compile_all': False, 'ignore_shebangs': False, 'arch': None, 
'O': None, 'requires': None}
D: dh_python3 dh_python3:152: args: []
D: dh_python3 dh_python3:154: supported Python versions: 3.4 (default=3.4)
D: dh_python3 debhelper:98: source=s3ql, binary packages=['s3ql', 's3ql-dbg']
D: dh_python3 dh_python3:171: processing package s3ql...
I: dh_python3 tools:100: replacing shebang in 
debian/s3ql/usr/lib/s3ql/benchmark.py
  [...]
D: dh_python3 fs:220: package s3ql details = {'public_vers': set(), 'ext_vers': 
set(), 'nsp.txt': set(), 'private_dirs': {'/usr/lib/s3ql': {'compile': True, 
'ext_vers': {Version('3.4')}, 'shebangs': {/usr/bin/python3, /usr/bin/python3, 
/usr/bin/python3, /usr/bin/python3, /usr/bin/python3, /usr/bin/python3, 
/usr/bin/python3, /usr/bin/python3, /usr/bin/python3, /usr/bin/python3, 
/usr/bin/python3, /usr/bin/python3, /usr/bin/python3, /usr/bin/python3, 
/usr/bin/python3, /usr/bin/python3, /usr/bin/python3, /usr/bin/python3, 
/usr/bin/python3}}}, 'requires.txt': 
{'debian/s3ql/usr/lib/s3ql/s3ql-2.13.egg-info/requires.txt'}, 'egg-info': 
set(), 'compile': False, 'shebangs': {/usr/bin/python3, /usr/bin/python3, 
/usr/bin/python3, /usr/bin/python3, /usr/bin/python3, /usr/bin/python3, 
/usr/bin/python3, /usr/bin/python3, /usr/bin/python3, /usr/bin/python3, 
/usr/bin/python3, /usr/bin/python3}, 'ext_no_version': set()}
D: dh_python3 depends:107: generating dependencies for package s3ql
D: dh_python3 pydist:121: trying to find dependency for apsw = 3.7.0 
(python=None)
D: dh_python3 pydist:121: trying to find dependency for pycrypto (python=None)
D: dh_python3 pydist:121: trying to find dependency for requests (python=None)
D: dh_python3 pydist:121: trying to find dependency for defusedxml (python=None)
D: dh_python3 pydist:121: trying to find dependency for dugong = 3.4 
(python=None)
D: dh_python3 pydist:121: trying to find dependency for llfuse = 0.39 
(python=None)
D: dh_python3 depends:242: D={'python3:any (= 3.3.2-2~)', 'python3-requests', 
'python3-defusedxml', 'python3-crypto', 'python3-llfuse', 'python3-apsw', 
'python3 (= 3.4~)', 'python3', 'python3 ( 3.5)', 'python3-dugong'}; R=[]; 
S=[]; E=[], B=[]; RT=[('/usr/lib/s3ql', '-V 3.4')]
D: dh_python3 dh_python3:171: processing package s3ql-dbg...
[...]

Not surprisingly, the binary package then ends up without the versioned
dependency, and also without the s3ql.pydist file in 
/usr/share/dh-python/dist/cpython3/ (as README.PyDist promised).

What am I doing wrong?

Best,
-Nikolaus

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

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


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

Re: Proposed git migration plan

[Nikolaus Rath]

Brian May br...@microcomaustralia.com.au writes:
 2. Sometimes I make repeated mistakes when building a package; under
 subversion I have to make a new commit for each one before testing. 

Why is that? I'm testing my uncommitted changes with

svn-buildpackage --svn-ignore-new --svn-builder=pdebuild

and it seems to work very well.

Best,
-Nikolaus (who wishes for a decent mercurial-buildpackage)

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

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


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

Re: Bug#758013: s3ql autopkg test regression

[Nikolaus Rath]

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

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

SVN is updated.


Best,
-Nikolaus

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

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


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

Re: Bug#758013: s3ql autopkg test regression

[Nikolaus Rath]

On 08/19/2014 01:33 AM, Matthias Klose wrote:
 Control: severity -1 important

Care to provide a justification? There is no bug in the program itself,
so I don't see how this is has a major effect on the usability of a
package.

 That's a bug in the test (race condition) rather than in the program.
 It's fixed upstream.
 
 Nikolaus, I find this kind of attitude rather disturbing.  If you don't care
 about the autopkg tests, and if you are not ready to fix these but rather wait
 for the fixes from upstream (and maybe new bugs), then I think it's better to
 drop the autopkg tests.

What makes you think I'm not ready to fix them?

And even if was my intention to wait for a new upstream version instead,
I think I'm a bit more qualified than you to judge if that's a good idea
or not.

 And replying to the bug report without replying to the maintainer is at least 
 odd.

What do you mean? I am the maintainer.

Best,
-Nikolaus

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

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


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

Re: Bug#758013: s3ql autopkg test regression

[Nikolaus Rath]

Simon McVittie s...@debian.org writes:
 On 19/08/14 09:33, Matthias Klose wrote:
 [Nikolaus Rath wrote:]
 That's a bug in the test (race condition) rather than in the program.
 It's fixed upstream.
 
 [...] If you don't care
 about the autopkg tests, and if you are not ready to fix these but rather 
 wait
 for the fixes from upstream (and maybe new bugs), then I think it's better to
 drop the autopkg tests.

 There are always at least two possible reasons for a failing test: the
 code under test is wrong or the test is wrong.

 The most important thing is that someone with knowledge of the package
 has looked at the failure report and triaged it, i.e. assigned it an
 appropriate priority based on their knowledge of the package. It appears
 Nikolaus has done this, and it will be dealt with when it's dealt with.
 I don't think there's a problem here.

If someone cares deeply about this, the necessary patch is at 
https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/.
 

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


Best,
-Nikolaus

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

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


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

RFS: defusedxml 0.4.1-2 (was: What happened to python-defusedxml?)

[Nikolaus Rath]

Nikolaus Rath nikol...@rath.org writes:
 Hello,

 I'd like to add python3 support to the defusedxml package. However, even
 though apt-get source says that

 NOTICE: 'defusedxml' packaging is maintained in the 'Svn' version control 
 system at:
 svn://anonscm.debian.org/svn/python-modules/packages/defusedxml/trunk/

 .. there is actually no *defusedxml* module anywhere in
 python-modules/packages.

 Can someone tell me what the status of this package is (and how I can
 help to add python3 support)?

Looking at snapshots.debian.org, it seems that after the initial upload
by Luke Faraone, the package has never been touched by anyone. My guess
is that Luke simply forgot to run the svn-inject.

Since the package has DPMT in its maintainer field, I took the liberty
of injecting the original version into SVN, and then committed some
changes to make it build a Python 3 package as well.

It would be great if someone could review the changes and sponsor an
upload.

The package builds fine in my up-to-date sid chroot, and there are no
Lintian warnings.

Best,
-Nikolaus

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

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


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

What happened to python-defusedxml?

[Nikolaus Rath]

Hello,

I'd like to add python3 support to the defusedxml package. However, even
though apt-get source says that

NOTICE: 'defusedxml' packaging is maintained in the 'Svn' version control 
system at:
svn://anonscm.debian.org/svn/python-modules/packages/defusedxml/trunk/

.. there is actually no *defusedxml* module anywhere in
python-modules/packages.

Can someone tell me what the status of this package is (and how I can
help to add python3 support)?


Best,
Nikolaus

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

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


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

Re: pybuild: where to put --test-pytest?

[Nikolaus Rath]

Piotr Ożarowski pi...@debian.org writes:
 [Nikolaus Rath, 2014-03-14]
 It seems that pybuild tries to find the tests in some temporary
 directory:
 
 $ debuild -us -uc
 []
 make[1]: Leaving directory `ROOT/python-dugong-2.1'
dh_auto_test -O--buildsystem=pybuild
 I: pybuild base:170: cd ROOT/python-dugong-2.1/.pybuild/pythonX.Y_3.4/build; 
 python3.4 -m pytest 
 = test session starts 
 ==
 platform linux -- Python 3.4.0 -- pytest-2.5.1
 collected 0 items
 [...]
 
 This is presumably because the tests are in ROOT/test, not in
 ROOT/python-dugong-2.1/.pybuild/pythonX.Y_3.4/build. The latter seems to
 contain only the dugong module itself.
 
 Who/what is responsible for copying the tests in this directory? 

 how about instead of copying these files, pointing pytest to them?

I was assuming that there's some rationale for pybuild looking for the
tests in this directory. If they have to be copied there manually, or if
pybuild has to be told to look for them elsewhere, then why look for
them in this weird location in the first place?

It seems to me I'm missing something here.. maybe the right question to
ask is: in what situation would I *not* need to copy the files manually
or modify PYBUILD_TEST_ARGS?


Thanks,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

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


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

Re: pybuild: where to put --test-pytest?

[Nikolaus Rath]

Piotr Ożarowski pi...@debian.org writes:
 [Nikolaus Rath, 2014-03-12]
 I'm working on a package that uses pytest. Conventiently, pybuild seems
 to have a --test-pytest option -- but I'm completely at a loss where to
 put it.
 
 Currently my rules file looks like this:

 you can add this line in debian/rules:

  export PYBUILD_TEST_PYTEST=1

Thanks, this seems to work (documenting this in the pybuild manpage
would be nice).

However, now I have a different problem:

It seems that pybuild tries to find the tests in some temporary
directory:

$ debuild -us -uc
[]
make[1]: Leaving directory `ROOT/python-dugong-2.1'
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:170: cd ROOT/python-dugong-2.1/.pybuild/pythonX.Y_3.4/build; 
python3.4 -m pytest 
= test session starts ==
platform linux -- Python 3.4.0 -- pytest-2.5.1
collected 0 items
[...]

This is presumably because the tests are in ROOT/test, not in
ROOT/python-dugong-2.1/.pybuild/pythonX.Y_3.4/build. The latter seems to
contain only the dugong module itself.

Who/what is responsible for copying the tests in this directory? 


Thanks,
-Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

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


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

pybuild: where to put --test-pytest?

[Nikolaus Rath]

Hello,

I'm working on a package that uses pytest. Conventiently, pybuild seems
to have a --test-pytest option -- but I'm completely at a loss where to
put it.

Currently my rules file looks like this:

,
| #!/usr/bin/make -f
| # -*- makefile -*-
| 
| #export DH_VERBOSE=1
| export PYBUILD_NAME=dugong
| 
| %:
|   dh $@ --with python3,sphinxdoc --buildsystem=pybuild
| 
| override_dh_auto_build:
|   dh_auto_build
|   python3 setup.py build_sphinx
| 
| override_dh_auto_clean:
|   dh_auto_clean
|   rm -rf doc/html doc/doctrees
`

Where can I sneak in the --test-pytest option?


Thanks,
-Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

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


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

Re: PEP 453 affects Debian packaging of Python packages

[Nikolaus Rath]

Paul Tagliamonte paul...@debian.org writes:
 On Wed, Sep 18, 2013 at 03:22:19PM +0200, Piotr Ożarowski wrote:
 [W. Martin Borgert, 2013-09-18]
  As a passionate pip hater I would go for a Conflicts,
  which finally would make pip uninstallable :~)
  Next steps: get rid of gem, npm, EPT, ...
 
 +1 (unless all these wheel re-inventors will speed up a bit - they're
 still where Linux packagers were 5-10 years ago)

 And *THIS* is why we get bad reputations.

   1) pip isn't for global package management, for this is stupid. If we
  disabled root use of pip, I think we'd all be a bit happier.

Yet it forces me to pass --install-option --user even when called as a
an unprivileged user.

 I don't understand the pip hate. Why don't you guys try and, you know,
 figure out *why* these tools were invented. It (for sure) is overly
 simplistic, but it's there for a reason.

Disclaimer: I actually like pip. But the above is really bugging me.

Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bo3pjy4r@vostro.rath.org

Re: How to help with sphinx 1.2?

[Nikolaus Rath]

Dmitry Shachnev mity...@gmail.com writes:
 Hi Nikolaus,

 On Thu, Sep 12, 2013 at 11:43 PM, Nikolaus Rath nikol...@rath.org wrote:
 Hello,

 Is there a way for me to help getting Sphinx 1.2 into unstable?

 I looked at the open bugs, but didn't find anything that seemed to block
 an upload..

 Except for the fact it has not been released yet.

So that is the showstopper? I thought I've seen other Debian packages
based on development releases, so I thought maybe b1 would have a chance
of making it out of experimental...

Best,
Nikolaus


-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

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


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gekfkuw@rath.org

How to help with sphinx 1.2?

[Nikolaus Rath]

Hello,

Is there a way for me to help getting Sphinx 1.2 into unstable?

I looked at the open bugs, but didn't find anything that seemed to block
an upload..

Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

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


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gelomgr@rath.org

Re: Enabling hardened build flags for Wheezy

[Nikolaus Rath]

Moritz Muehlenhoff j...@debian.org writes:
 Hi,

 dpkg-buildflags allows a uniform setting of default build flags for
 code written in C and C++. 

 Using dpkg-build-flags in your rules files has a number of benefits:
[...]

Should packages of Python extensions written in C and using
distribute/setuptools worry about this, or will the debian setuptools
package be patched to use dpkg-build-flags?


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k434xtub@inspiron.ap.columbia.edu

Re: Mysterious double python dependency

[Nikolaus Rath]

Jakub Wilk jw...@debian.org writes:
 * Nikolaus Rath nikol...@rath.org, 2011-12-30, 10:14:
 When creating the S3QL package, I somehow get a dependency on both
 python and python2.7:

Depends: python (= 2.6.6-7~), [...], python2.7

 They were both generated by dh_python2. And they are both needed to
 run the postinst script:

 1) python (= 2.6.6-7~) is needed because /usr/bin/pycompile is in
 the python package.

 2) s3ql's private modules must be used only with python2.7 (since
 /usr/lib/s3ql/s3ql/_deltadump.so was built for 2.7). Naturally, you
 need python2.7 to byte-compile for 2.7.

 Does it make sense now?

 No, of course it doesn't. All scripts that would use the _deltadump
 extension have #!/usr/bin/python shebangs, so there's no guarantee
 they'll actually be run with python2.7. The dependency should have
 been python (= 2.7), python ( 2.8), as per Python Policy 3.1.1.

Pardon my ignorance, but is that something I should fix in the S3QL
control file, or something that should be fixed in dh_python2?

Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k45cv1nj@vostro.rath.org

Mysterious double python dependency

[Nikolaus Rath]

Hello,

When creating the S3QL package, I somehow get a dependency on both
python and python2.7:

Depends: python (= 2.6.6-7~), [...], python2.7

This seems to come from the python:Depends substitution variable:

python:Depends=python, python (= 2.6.6-7~), python (= 2.6), python-apsw, 
python-pycryptopp, python-llfuse, python-argparse, python-lzma, python2.7

The debian/control file says:

X-Python-Version: = 2.6
Build-Depends: python-dev (= 2.6.6-3~),

Depends: ${misc:Depends},
 ${python:Depends},
 ${shlibs:Depends},
 ${sphinxdoc:Depends},

and after the 
(http://anonscm.debian.org/viewvc/python-apps/packages/s3ql/trunk/debian/)


Does anyone have a suggestion how to find out where this dependency
comes from?

Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lipuqefk@inspiron.ap.columbia.edu

Re: Mysterious double python dependency

[Nikolaus Rath]

Nikolaus Rath nikol...@rath.org writes:
 Hello,

 When creating the S3QL package, I somehow get a dependency on both
 python and python2.7:

 Depends: python (= 2.6.6-7~), [...], python2.7


Apparently the culprit is bug #625740.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipkyqatw@inspiron.ap.columbia.edu

Trouble with dh_sphinxdoc

[Nikolaus Rath]

Hello,

I have the unusual problem that builds on buildd fail with

dh_sphinxdoc: Sphinx documentation not found

yet builds in my local, up-to-date sid pbuilder chroot work just fine.

Example:

https://buildd.debian.org/status/fetch.php?pkg=python-llfusearch=i386ver=0.37.1-1stamp=1324492935

Package is at

http://mentors.debian.net/debian/pool/main/p/python-llfuse/python-llfuse_0.37.1-1.dsc

Does anyone have an idea what might be causing this?


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4zxbvrq@inspiron.ap.columbia.edu

Sphinx documentation copyright

[Nikolaus Rath]

Hello,

My package generates its documentation with sphinx. I'm wondering what
license the resulting generated files fall under. In particular:

1. I guess that the generated HTML files have the same license as the .rst
files they're generated from, right?

2. The included sphinx templates in _static/* probably have the same
license as sphinx itself, right? But
/usr/share/doc/python-sphinx/copyright says

[...]
Copyright (c) 2007-2011 by the Sphinx team (see AUTHORS file).
[...]

does that mean that I should include (or copy  paste) the sphinx
AUTHORS file in my package's debian/copyright?

3. What is the license of autogenerated javascript libraries like
_static/underscore.js or searchindex.js?



Thanks,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqljuvib@vostro.rath.org

Re: Sphinx documentation copyright

[Nikolaus Rath]

Jakub Wilk jw...@debian.org writes:
 * Nikolaus Rath nikol...@rath.org, 2011-07-09, 15:03:
3. What is the license of autogenerated javascript libraries like
_static/underscore.js

 Err, this one is by no means autogenerated.
 https://bitbucket.org/birkenfeld/sphinx/changeset/b7fb19a0992d

Oh, I see. It looked pretty autogenerated because of the obfuscated
code. I'm depending on libjs-underscore now to provide this file.

Thanks,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxgnus4f@vostro.rath.org

Re: Avoiding download of intersphinx inventories during build

[Nikolaus Rath]

Stefano Rivera stefa...@debian.org writes:
 Hi Nikolaus (2011.07.05_21:01:21_+0200)
 The python module I'm packaging uses intersphinx. Since the debian
 package rebuilds the documentation from the sources, the package needs
 to download the inventories:

 It will, of course, build successfully without them, just won't include
 intersphinx links and will throw some warnings. However, yes, that still
 goes again Debian policy, and produces a different build.

 intersphinx is capable of referring to a local inventory file, you could
 patch the source to do that, and include an inventory in debian/. A
 slightly stale inventory shouldn't be a major problem.

Sounds good, will do that.


Thanks!

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87oc17mszq@inspiron.ap.columbia.edu

Avoiding download of intersphinx inventories during build

[Nikolaus Rath]

Hello,

The python module I'm packaging uses intersphinx. Since the debian
package rebuilds the documentation from the sources, the package needs
to download the inventories:

Running Sphinx v1.1pre
loading pickled environment... not yet created
loading intersphinx inventory from http://docs.python.org/objects.inv...


Now, I understand that downloading files during build is a big no, but I
don't quite know how to handle this. Should I ship the pickled sphinx
environment as a debian patch? This seems rather fragile..

Any suggestions?

Thanks,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87box8o8la@inspiron.ap.columbia.edu

Add python app to python-modules repository?

[Nikolaus Rath]

Hello,

Would it be ok if I uploaded S3QL (a Python application) into the
python-modules SVN repository?

I tried to join the python-apps team, but I didn't get a reply on either
my Alioth request or my mail to the list. However, I did find a sponsor
who's also willing to co-maintain it, so it would be great if I could
put this in a repository somewhere.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iprrotlj@inspiron.ap.columbia.edu

Where to put debugging extension

[Nikolaus Rath]

Hello,

Should I put the extension build for the debug interpreter into the
normal python-xx package, or into the python-xx-dbg package that also
contains the debugging symbols?

The first variant seems to be more common, but I'm having trouble to
come up with a good pattern for debian/xx.install to exclude the
extension build for the debugging intepreter (and, vice versa, for
including it in debian/xx-dbg.install).

Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762o6g9ly@inspiron.ap.columbia.edu

Re: Looking for sponsor: python-llfuse

[Nikolaus Rath]

Vincent Bernat ber...@debian.org writes:
 OoO La nuit ayant déjà recouvert  d'encre ce jour du lundi 13 juin 2011,
 vers 23:23, Nikolaus Rath nikol...@rath.org disait :

 Ah, of course. This should be fixed as well now.

 OK. Uploaded.

Thanks!

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87boy041jv@inspiron.ap.columbia.edu

Re: Looking for sponsor: python-llfuse

[Nikolaus Rath]

Vincent Bernat ber...@debian.org writes:
 OoO En cette  nuit nuageuse du lundi 13 juin  2011, vers 01:04, Nikolaus
 Rath nikol...@rath.org disait :

 Or Maintainer: Nikolaus, Uploader: DPMT. And DPMT is:
 Debian Python Modules Team python-modules-t...@lists.alioth.debian.org

 Done. Package is in the DPMT SVN now.

 debian/changelog:

 This is a bit unusual to  describe non change related things here, but I
 am fine with it.

That was in response to Jacob's request. I'm fine to put it somewhere
else (or not document it at all) :-).

 debian/control:

 Since you build  C modules, you only need to  depends on the appropriate
 version   of   python-all-dev   and  python3-all-dev.   python-all   and
 python3-all are dependencies of those.

Fixed.

 I don't think that python-all-dbg and python3-all-dbg will be needed
 to build the package.

To build the debug versions, I'm calling python-dbg setup.py (so I need
python-*-dbg). Is that the wrong thing to do?


 You need to update Vcs-* to the new location.

Fixed, sorry.

 debian/copyright:

 Please, use DEP-5 format.
 http://dep.debian.net/deps/dep5/

Done. I used  http://dep.debian.net/deps/dep5/ as the 
VERSIONED_FORMAT_URL, because it says that the format is now fixed. Is
that correct? Some other packages used URLs like
http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?op=filerev=135,
but these just give 400s now.

 Also, you  say that python-llfuse is  licensed with LGPL 3.  There is no
 such  mention in  the upstream  package. Only  LGPL. As  upstream, you
 should add a LICENSE file to clarify this.

Done as well. Should I release a new version with just the LICENSE file
added, or can this wait for a regular update (without delaying the
debian package)?


 The python3-llfuse-dbg  does not contain  debug symbols. Only  the debug
 version of the library (llfuse.cpython-32dmu.so).

I'm a bit at a loss here. For some reason, dh_strip puts the
python3-llfuse debugging symbols into the python-llfuse-dbg directory:


$ dh_strip -v -a -ppython-llfuse --dbg-package=python-llfuse-dbg
[...]
install -d 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages
objcopy --only-keep-debug 
debian/python3-llfuse/usr/lib/python3/dist-packages/llfuse.cpython-32mu.so 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
chmod 644 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
strip --remove-section=.comment --remove-section=.note --strip-unneeded 
debian/python3-llfuse/usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
objcopy --add-gnu-debuglink 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
 debian/python3-llfuse/usr/lib/python3/dist-packages/llfuse.cpython-32mu.so
objcopy --only-keep-debug 
debian/python3-llfuse-dbg/usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so
chmod 644 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so
strip --remove-section=.comment --remove-section=.note --strip-unneeded 
debian/python3-llfuse-dbg/usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so
objcopy --add-gnu-debuglink

debian/python-llfuse-dbg/usr/lib/debug//usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so

debian/python3-llfuse-dbg/usr/lib/python3/dist-packages/llfuse.cpython-32dmu.so

Shouldn't this command only work on the python-llfuse package?


 The .c files are now regenerated in debian/rules. I am not regenerating
 the documentation yet. I understood that this is nice to have but not
 required, so I wanted to wait until the Sphinx 1.1 hits the archive.
 When that has happened, it's just a matter of uncommenting one line in
 debian/rules.

 I was also a bit surprised that  so many DD did agree to not rebuild the
 documentation. I would prefer that  the documentation is rebuilt. Why do
 you need Sphinx 1.1?

Sphinx 1.0 cannot extract the function signature for extension modules,
Sphinx 1.1 can (by parsing the first line of the docstring). llfuse does
some postprocessing on these docstrings (to remove C type declarations),
so using Sphinx 1.0 doesn't just silently omit the signatures, but
aborts with an error because of missing hooks for signature
postprocessing.

Discussion:
https://bitbucket.org/birkenfeld/sphinx/issue/564

Relevant changesets:
https://bitbucket.org/birkenfeld/sphinx/changeset/de340a6098c7
https://bitbucket.org/birkenfeld/sphinx/changeset/a8b0ef275438


I also added a sphinx wishlist bug to backport this feature (Bug
#630409).



Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe

Re: Looking for sponsor: python-llfuse

[Nikolaus Rath]

Vincent Bernat ber...@debian.org writes:
 I don't think that python-all-dbg and python3-all-dbg will be needed
 to build the package.

 To build the debug versions, I'm calling python-dbg setup.py (so I need
 python-*-dbg). Is that the wrong thing to do?

 I was not aware that this was the way to do it.

I don't know any other way to build the extension for the debug
compiler, but if you tell me one then I'll be happy to use it :-).
Otherwise it seems to me that I really need the dependency on
python-all-dbg.


 The python3-llfuse-dbg  does not contain  debug symbols. Only  the debug
 version of the library (llfuse.cpython-32dmu.so).

 I'm a bit at a loss here. For some reason, dh_strip puts the
 python3-llfuse debugging symbols into the python-llfuse-dbg directory:

 $ dh_strip -v -a -ppython-llfuse --dbg-package=python-llfuse-dbg
 [...]
 Shouldn't this command only work on the python-llfuse package?

 The -a means all arch packages. I suppose that you should not use it
 with -p.

Ah, of course. This should be fixed as well now.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uyx5stf@inspiron.ap.columbia.edu

Re: Looking for sponsor: python-llfuse

[Nikolaus Rath]

Vincent Bernat ber...@debian.org writes:
 OoO En  cette soirée bien  amorcée du samedi  11 juin 2011,  vers 22:01,
 Nikolaus Rath nikol...@rath.org disait :

 * URL : http://code.google.com/p/python-llfuse/
 * License : LGPL
 * Section : python
 
 [...]
 
 I would also be happy to join the python team and have this package team
 maintained.   Would   that   be   preferred?  My   alioth   login   is
 nikratio-guest.
 
 I can sponsor  you. Please join the team. Piotr,  could you add Nikolaus
 to the team?

 Cool, thanks! So I'll change debian/control to

 Maintainer: Debian Python Team debian-python@lists.debian.org
 Uploader: Nikolaus Rath nikol...@rath.org

 Or Maintainer: Nikolaus, Uploader: DPMT. And DPMT is:
 Debian Python Modules Team python-modules-t...@lists.alioth.debian.org

Done. Package is in the DPMT SVN now.

 and then upload the package with svn-inject. Is there anything else I
 need to do?

 I still  need to review the  package. Also ensure that  you applied what
 Jakub said in debian-mentors@.

The .c files are now regenerated in debian/rules. I am not regenerating
the documentation yet. I understood that this is nice to have but not
required, so I wanted to wait until the Sphinx 1.1 hits the archive.
When that has happened, it's just a matter of uncommenting one line in
debian/rules.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwnehcs8@vostro.rath.org

Re: Looking for sponsor: python-llfuse

[Nikolaus Rath]

Vincent Bernat ber...@debian.org writes:
 OoO  En  cette nuit  nuageuse  du dimanche  05  juin  2011, vers  00:07,
 Nikolaus Rath nikol...@rath.org disait :

 * URL : http://code.google.com/p/python-llfuse/
 * License : LGPL
 * Section : python

 [...]

 I would also be happy to join the python team and have this package team
 maintained.   Would   that   be   preferred?  My   alioth   login   is
 nikratio-guest.

 I can sponsor  you. Please join the team. Piotr,  could you add Nikolaus
 to the team?

Cool, thanks! So I'll change debian/control to

Maintainer: Debian Python Team debian-python@lists.debian.org
Uploader: Nikolaus Rath nikol...@rath.org

and then upload the package with svn-inject. Is there anything else I
need to do?

Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vt816jt@vostro.rath.org

Re: Looking for sponsor: python-llfuse

[Nikolaus Rath]

Nikolaus Rath nikol...@rath.org writes:
 Hello,

 I am looking for a sponsor for the python-llfuse package. I am also the
 upstream author.

 * URL : http://code.google.com/p/python-llfuse/
 * License : LGPL
 * Section : python

 It builds these binary packages:
[...]


Really no one willing to help?

Best,
   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739jhmljk@vostro.rath.org

Looking for sponsor: python-llfuse

[Nikolaus Rath]

Hello,

I am looking for a sponsor for the python-llfuse package. I am also the
upstream author.

* URL : http://code.google.com/p/python-llfuse/
* License : LGPL
* Section : python

It builds these binary packages:
python-llfuse - Python bindings for the low-level FUSE API
python-llfuse-dbg - Python bindings for the low-level FUSE API (debugging 
symbols)
python3-llfuse - Python 3 bindings for the low-level FUSE API
python3-llfuse-dbg - Python 3 bindings for the low-level FUSE API (debugging 
symbols)

ITP is #626658.

Python-llfuse is a dependency of S3QL (http://code.google.com/p/s3ql/)
which I intend to package (ITP #626651).

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/python-llfuse
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/p/python-llfuse/python-llfuse_0.32-1.dsc


I would also be happy to join the python team and have this package team
maintained. Would that be preferred? My alioth login is nikratio-guest.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739jpl07h@vostro.rath.org

Re: dh_strip and Python Extensions

[Nikolaus Rath]

Piotr Ożarowski pi...@debian.org writes:
 [Christian Kastner, 2011-05-26]
 On 05/26/2011 02:32 AM, Nikolaus Rath wrote:
  I'm not quite sure when this started, but dh_strip is placing my Python
  .so extensions into /usr/lib/debug/..., which makes Lintian complain:
  [...]
  
  $ lintian ../python-llfuse-dbg_0.31-1_amd64.deb
  W: python-llfuse-dbg: python-debug-in-wrong-location 
  usr/lib/debug/usr/lib/pyshared/python2.6/llfuse.so 
  /usr/lib/debug/usr/lib/pymodules/python2.6/llfuse.so
  W: python-llfuse-dbg: python-debug-in-wrong-location 
  usr/lib/debug/usr/lib/pyshared/python2.6/llfuse_d.so 
  /usr/lib/debug/usr/lib/pymodules/python2.6/llfuse_d.so
 
 The first path is where dh_strip has installed the files. The second
 path, however, is where they are expected. See [0] for a fix, and [1]
 for a rationale.

 you can also use dh_python2

I am using dh_python2 - does that mean I should not be calling dh_strip?

Thanks,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vttlf4e@inspiron.ap.columbia.edu

dh_strip and Python Extensions

[Nikolaus Rath]

Hello,

I'm not quite sure when this started, but dh_strip is placing my Python
.so extensions into /usr/lib/debug/..., which makes Lintian complain:

$ dpkg-buildpackage
[...]
dh_strip -v -a -ppython-llfuse --dbg-package=python-llfuse-dbg;
install -d 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/pyshared/python2.6
objcopy --only-keep-debug 
debian/python-llfuse/usr/lib/pyshared/python2.6/llfuse.so 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/pyshared/python2.6/llfuse.so
chmod 644 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/pyshared/python2.6/llfuse.so
strip --remove-section=.comment --remove-section=.note --strip-unneeded 
debian/python-llfuse/usr/lib/pyshared/python2.6/llfuse.so
objcopy --add-gnu-debuglink 
debian/python-llfuse-dbg/usr/lib/debug//usr/lib/pyshared/python2.6/llfuse.so 
debian/python-llfuse/usr/lib/pyshared/python2.6/llfuse.so
[...]

$ lintian ../python-llfuse-dbg_0.31-1_amd64.deb
W: python-llfuse-dbg: python-debug-in-wrong-location 
usr/lib/debug/usr/lib/pyshared/python2.6/llfuse.so 
/usr/lib/debug/usr/lib/pymodules/python2.6/llfuse.so
W: python-llfuse-dbg: python-debug-in-wrong-location 
usr/lib/debug/usr/lib/pyshared/python2.6/llfuse_d.so 
/usr/lib/debug/usr/lib/pymodules/python2.6/llfuse_d.so


Did I accidentally change something? Has dh_strip's behaviour changed?


Thanks,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739k2cnda@vostro.rath.org

X-Python3-Version if Python 3 is unsupported?

[Nikolaus Rath]

Hello,

What should I put into X-Python3-Version for a package that does not
support Python 3? According to
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html,
not providing that header would mean that the package is compatible with
all currently supported versions. But there doesn't seem to be a keyword
like none either.


Best,

   -Nikolaus

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

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y61zc3al@vostro.rath.org