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. B
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
Piotr Ożarowski 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:
Piotr Ożarowski writes:
> [Nikolaus Rath, 2011-05-26]
>> I am using dh_python2 - does that mean I should not be calling dh_strip?
>
> can you point me to source package?
http://mentors.debian.net/debian/pool/main/p/python-llfuse
dget
http://mentors.debian.net/debian/pool/main/
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
Nikolaus Rath 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 b
Vincent Bernat writes:
> OoO En cette nuit nuageuse du dimanche 05 juin 2011, vers 00:07,
> Nikolaus Rath disait :
>
>> * URL : http://code.google.com/p/python-llfuse/
>> * License : LGPL
>> * Section : python
>
> [...]
>
Vincent Bernat writes:
> OoO En cette soirée bien amorcée du samedi 11 juin 2011, vers 22:01,
> Nikolaus Rath disait :
>
>>>> * URL : http://code.google.com/p/python-llfuse/
>>>> * License : LGPL
>>>> * Section : py
Vincent Bernat writes:
> OoO En cette nuit nuageuse du lundi 13 juin 2011, vers 01:04, Nikolaus
> Rath disait :
>
>>> Or Maintainer: Nikolaus, Uploader: DPMT. And DPMT is:
>>> Debian Python Modules Team
>
>> Done. Package is in the DPMT SVN now.
>
> d
Vincent Bernat 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
Vincent Bernat writes:
> OoO La nuit ayant déjà recouvert d'encre ce jour du lundi 13 juin 2011,
> vers 23:23, Nikolaus Rath disait :
>
>> Ah, of course. This should be fixed as well now.
>
> OK. Uploaded.
Thanks!
-Nikolaus
--
»Time flies like an arrow,
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 t
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 woul
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
Stefano Rivera 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,
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 _stat
Jakub Wilk writes:
> * Nikolaus Rath , 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,
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-llfuse&arch=i386&ver=0.37.1-1&stamp=1324492935
P
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-py
Nikolaus Rath 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 arro
Jakub Wilk writes:
> * Nikolaus Rath , 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 a
Moritz Muehlenhoff 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
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 flie
Dmitry Shachnev writes:
> Hi Nikolaus,
>
> On Thu, Sep 12, 2013 at 11:43 PM, Nikolaus Rath 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
Paul Tagliamonte 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 (un
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=
Piotr Ożarowski 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 lo
Piotr Ożarowski 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
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 *
Nikolaus Rath 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
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 pro
Simon McVittie 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 autopk
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/.
>>
>>
>&g
Brian May 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
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
On Feb 17 2015, Piotr Ożarowski 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 t
On Feb 17 2015, Piotr Ożarowski 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 READ
On Feb 17 2015, Nikolaus Rath wrote:
> On Feb 17 2015, Piotr Ożarowski 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?
>>
>>
Hi,
I recently switched the python-llfuse package to use pybuild. However,
this seems to have a side effect that the debugging symbols for the C
extension are no longer included in the -dbg package, so it now contains
only the extension build for the debug interpreter. Is that deliberate?
I think
On Apr 02 2015, Sebastian Ramacher wrote:
> On 2015-04-01 20:15:04, Nikolaus Rath wrote:
>> Hi,
>>
>> I recently switched the python-llfuse package to use pybuild. However,
>> this seems to have a side effect that the debugging symbols for the C
>> extension a
On Apr 04 2015, Piotr Ożarowski wrote:
> [Nikolaus Rath, 2015-04-04]
>> > In the process of converting it to pybuild, you've droppped the dh_strip
>> > override. Bring it back and the debug symbols should be back in -dbg.
>>
>> I certainly did so, because I
On Apr 23 2015, Barry Warsaw 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 b
ckage 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 Wed, 29 Jul 2015 20:49:49 -0700
The package builds cleanly in a sid chroot as of several days ago (right
n
On Aug 08 2015, Piotr Ożarowski 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 ye
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,
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 -
On Aug 22 2015, Nikolaus Rath wrote:
> 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 director
On Oct 01 2015, "Kai Storbeck" wrote:
> Hi,
>
> Roundup 1.4.20-1.1 is still the version in stable. Roundup 1.5 was
> released a few years back, and I need someone to help me with the
> final stages in getting 1.5 in stretch, or getting it removed.
>
>
> Roundup is a python web application with qui
On Oct 02 2015, Piotr Ożarowski wrote:
> I think that the main problem of our team is that we have over 300
> members and only few people contribute to packages they didn't inject to
> the repo (some people do not care even about those).
I always assumed that it was generally preferred to have Py
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
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 p
On Oct 28 2015, Piotr Ożarowski wrote:
>> > Can you be more specific about what's missing?
>>
>> I for one lack a high level presentation of how the various bits work
>> together
>
> here's what I got so far (I wanted to provide it as
> /usr/share/doc/dh-python/README).
Looks great. That would
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
On Dec 07 2015, Barry Warsaw 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
On Dec 07 2015, Simon McVittie 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
On Dec 08 2015, Barry Warsaw 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 bo
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 lea
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.
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
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 pristi
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
debian/patches/use-local-intersphinx-inventory.patch
>From 48e6c33f77106b9368e7db430d296ba6c31e47a6 Mon Sep 17 00:00:00 2001
From: Nikolaus Rath
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
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:
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/u
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 pref
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 gi
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 considere
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 'n
On Feb 10 2017, Scott Kitterman wrote:
> On February 9, 2017 8:29:32 PM PST, Nikolaus Rath wrote:
>>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 ment
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 sur
On Jul 05 2017, Vincent Bernat wrote:
> Hey!
>
> How to remove a patch with git-dpm?
Look for "Removing existing patches" in git-dpm(1):
$ git-dpm checkout-patched
$ git rebase -i upstream-unstable
$ git-dpm dch -- -i
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FC
Hello,
Could someone please add me to the DPMT and DPAP teams on Salsa? My
Alioth and Salsa username is nikratio-guest.
Thanks!
-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
De
On Apr 05 2018, Piotr Ożarowski 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
On Aug 08 2018, Thomas Goirand wrote:
> On 08/04/2018 09:05 AM, Ruben Undheim wrote:
>> Hi,
>>
2/ Ondrej Novy will do a mass-change from git-dpm to gbp on team packages.
Related to this, Piotr will review and amend the team policy if necessary,
as
well as work on the pipeline
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.
75 matches
Mail list logo
