Request to join PAPT and DPMT

[Zygmunt Krynicki]

Hello

I'd like to join PAPT and DPMT to co-maintain west and several other 
Python packages related to or needed by the Zephyr project. I'm an 
old-timer, in a way, but I have not been very active in packaging 
before. I'm looking to improve my skills and actively maintain the small 
subset of packages I'm using. My username on salsa is zyga-guest.


Best regards

ZK

Re: git packaging (was: Python packaging help.)

[Zygmunt Krynicki]

Is there a way to use git but build with sbuild. I kind of don't want
to go back to pbuilder and IIRC git-buildpackage requires it.

On Tue, Mar 31, 2015 at 5:43 PM, Barry Warsaw  wrote:
> On Mar 31, 2015, at 04:48 PM, Antoine Musso wrote:
>
>>I have only been introduced to git-buildpackage and using Jenkins to more or
>>less automatically build them when proposing a patch or a change is merged.
>
> Really, git-dpm is just the patch manager.  There are a few others, but I
> found git-dpm to be the most straightforward and fool-proof (where "fool" is
> defined as Barry :) of the lot.  It's also relatively easy to learn and
> remember, the latter which might not be as much of a problem when we're using
> it regularly.
>
> git-dpm makes it easier to manage your quilt patches, but git-buildpackage is
> still the tool you'll use to build your git-maintained packages.  E.g., here's
> an alias I use to do test builds of packages under development:
>
> gitbp is aliased to `git-buildpackage --git-ignore-new --git-export=WC -S -us 
> -uc'
>
>>> * Do we migrate all packages at once or one-at-a-time as needed?
>>
>> From past experience in migrating a huge svn tree, it is usually easier to
>> move them in batches as developers request it.  If you get to find some
>> volunteers, they will by the first line dealing with potential issues and
>> updating the doc.  Will make it easier for others.
>
> I tend to agree that we can do it piecemeal, at least at first until we're
> sure the tools (both conversion and operational) are working properly.  I
> definitely don't want to have a long tail of svn laggards, so there should be
> a specific time where we convert even the less active projects.
>
>>> * Do we try to keep all svn history, or just upload history?
>>
>>I tend to like the history, the blame and commit message logs are sometime
>>useful to get the context of a change/line of code.
>
> I found it adequate to just convert the upload history, but don't have any
> objections to keeping all the package history, if the conversion can be done
> easily and with high fidelity, to whatever git regime we end up adopting.  I'm
> not sure I'm personally interested in working on that (import-dscs.py is good
> enough for me), but I'd be happy to test out anybody else's contributions or
> recipes.
>
> Cheers,
> -Barry


-- 
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/CAJN_i48wJ96+kDE=79vqgtctcptfs8zdikv+1sdintw3xue...@mail.gmail.com

Re: Python packaging help.

[Zygmunt Krynicki]

Barry the import script looks pretty cool.

Any chance to package it and bless it as the official conversion script?

Best regards
ZK

On Tue, Mar 31, 2015 at 3:57 PM, Barry Warsaw  wrote:
> On Mar 31, 2015, at 01:14 PM, Balasankar C wrote:
>
>>One more doubt. Where are new packages uploaded to in Python Modules
>>Team? Is there a git repo or should I upload to Debian Mentors?
>
> The team still officially supports only Subversion, but we have been
> experimenting with switching to git.
>
> https://wiki.debian.org/Python/GitPackaging
>
> I personally favor and advocate git-dpm, but this has not yet been decided by
> the team.  I'd like for the team to make the switch very soon after Jessie is
> released, and I would personally be comfortable switching now.  We'll need to
> decide a few things before we can do that:
>
> * Do we adopt git-dpm or something else?
> * Do we migrate all packages at once or one-at-a-time as needed?
> * Do we try to keep all svn history, or just upload history?
>
> See also:
>
> http://anonscm.debian.org/cgit/users/barry/import-dscs.git/tree/import-dscs.py
>
> I'm sure there's more I'm missing.  I would definitely like to keep this on
> the radar.
>
> Cheers,
> -Barry


-- 
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/CAJN_i48M952Nmf=+esoukpt0dqyihrttrwhpzlydimaacyt...@mail.gmail.com

Re: Python packaging help.

[Zygmunt Krynicki]

W dniu 31.03.2015 o 09:44, Balasankar C pisze:


Hi,
One more doubt. Where are new packages uploaded to in Python Modules
Team? Is there a git repo or should I upload to Debian Mentors? I am
asking this because, in Ruby team, the uploads usually happen to the
git repos created inside pkg-ruby-extras folder in git.debian.org. I
found a python-modules folder there. Can I use that?
If no, what should be the Vcs-Browser and Vcs-Git fields set to?
- --


Please familiarize yourself with 
https://wiki.debian.org/Teams/PythonModulesTeam


Best regards
ZK


--
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/551a5314.4090...@canonical.com

Re: django 1.7 bugs

[Zygmunt Krynicki]

On Fri, Sep 12, 2014 at 4:10 AM, Brian May
 wrote:
> Obviously this is likely to fall out of date quickly. Apologies for any
> errors.
>
> I just wanted to try classify what is holding these bugs up.
>
>
> Bugs waiting for new Debian package:
>
> #755607 [i|+|  ] [src:django-restricted-resource]
> django-restricted-resource: Please ensure it works with Django 1.7
> #755610 [i|H+|  ] [src:lava-server] lava-server: Please ensure it works with
> Django 1.7
> #755661 [i|H+|  ] [src:django-testscenarios] django-testscenarios: Please
> ensure it works with Django 1.7

I wrote large parts of lava-server and both of the django- packages
here but I'm not an active upstream anymore (I cannot commit to those
repositories, only Linaro folks can) . If anyone wants my help though
I'd gladly render assistance.

Best regards
ZK


-- 
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/CAJN_i4_P6rMMPdsSrhZErugw_b3H2Qs7b5HN8Xu4q4WVVP5=d...@mail.gmail.com

Re: Proposed changes to python-virtualenv

[Zygmunt Krynicki]

On Mon, Jun 2, 2014 at 10:51 PM, Barry Warsaw  wrote:

> On Jun 02, 2014, at 04:43 PM, Donald Stufft wrote:
>
> >Sounds reasonable to me, the only “downside” is that virutalenv will
> default
> >to Python 3, which is probably not what most people want (however they
> >can do virtualenv -p python2).
>
>
Barry, would it be sensible to default to python2 (so keep existing outside
behaviour unchanged) and then only after a grace period and enough
announcements make python3 the default? To me doing it right now seems like
breaking lots of scripting for no good reason.

Thanks
ZK




> But it's what most people *should* want .
>
> Seriously though, I wonder if this is a problem or if some transition or
> wider
> announcement needs to be made.
>
> -Barry
>

Re: RFS: python-ebooklib

[Zygmunt Krynicki]

I think you are quite welcome to join DPMT

https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin

Best regards
ZK


On Thu, Apr 24, 2014 at 6:34 PM, Daniel James  wrote:

> Hello,
>
> I am a non-DD looking for sponsorship of (or any helpful hints about) my
> first upload to Debian: http://mentors.debian.net/package/python-ebooklib
>
> EbookLib is a Python library for managing EPUB2/EPUB3 and Kindle files.
> It's capable of reading and writing EPUB files (Kindle support is under
> development). Upstream homepage is https://github.com/aerkalov/ebooklib
>
> I have had some general feedback from the Debian Mentors list and
> believe the package is now ready for review.
>
> I'd be happy to join a packaging team should that be possible. My
> username on Alioth is dhj-guest, if that helps :-)
>
> Thanks!
>
> Daniel
>
>
> --
> 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/53593d05.7010...@64studio.com
>
>

Intersphinx usage

[Zygmunt Krynicki]

Hi.

I'd like to add support for intersphinx [1] to a package I'm working
on [2]. The generated documentation should also include the
intersphinx meta-data so that other packages that build-depend on my
package can cross-reference documentation elements.

Are there any examples of intersphinx usage and packaging that I can refer to?

Thanks
ZK

[1] http://sphinx-doc.org/latest/ext/intersphinx.html
[2] 
http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/


-- 
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/CAJN_i4_3tkzGMb7RDUpSX5oiVD=gqcy97sz-jasbmp1+d18...@mail.gmail.com

Re: About access to git.debian.org and the DPMT

[Zygmunt Krynicki]

On Tue, Nov 26, 2013 at 11:07 PM, Piotr Ożarowski  wrote:
> debian/copyright is still not complete - vendor files are still in the tarball
> so you have to mention these files in debian/copyright

Fixed

> also:
>
> $ ./debian/rules get-orig-source
> uscan --noconf --force-download --download-current-version --destdir=.
> plainbox: Version (0.4~b1) available on remote site:
>   http://pypi.python.org/packages/source/p/plainbox/plainbox-0.4b1.tar.gz
>   (local version is 0.4~b1)
> plainbox: Successfully downloaded updated package plainbox-0.4b1.tar.gz
> and symlinked plainbox_0.4~b1.orig.tar.gz to it
> dpkg-source: info: using source format `3.0 (quilt)'
> dpkg-source: info: applying 01-add-main-module
> dpkg-source: info: applying 02-executable-laucher1
> can't find file to patch at input line 26
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --
> |Description: Make plainbox.impl.secure.launcher1 executable via `python -m`
> | This patch adds a simple if __name__ == '__main__': main() statement
> | a the end of plainbox.impl.secure.launcher1 module so that it can be
> | executed directly with `python3 -m ...`. This is useful to generate
> | the plainbox-trusted-launcher-1.1 manual page with help2man
> |
> |Author: Zygmunt Krynicki 
> |Bug: https://bugs.launchpad.net/checkbox/+bug/1255085
> |Last-Update: 2013-11-26
> |Forwarded: yes
> |---
> |The information above should follow the Patch Tagging Guidelines, please
> |checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
> |are templates for supplementary fields that you might want to add:
> |
> |Origin: , 
> |Bug: 
> |Bug-Debian: http://bugs.debian.org/
> |Bug-Ubuntu: https://launchpad.net/bugs/
> |Forwarded: 
> |Reviewed-By: 
> |Last-Update: 
> |
> |--- plainbox-0.4~b1.orig/plainbox/impl/secure/launcher1.py
> |+++ plainbox-0.4~b1/plainbox/impl/secure/launcher1.py
> --
> No file to patch.  Skipping patch.
> 1 out of 1 hunk ignored
> dpkg-source: info: fuzz is not allowed when applying patches
> dpkg-source: info: if patch '02-executable-laucher1' is correctly applied by 
> quilt, use 'quilt refresh' to update it
> dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B 
> .pc/02-executable-laucher1/ --reject-file=- < 
> trunk/debian/patches/02-executable-laucher1 gave error exit status 1


Fixed, I think.
The odd thing is, despite the patch looking malformed, it was always
applying and un-applying for me, not sure what's going on.
I did get a source package built though (with a clean git tree and the
upstream tarball in a directory above). If it still causes you
problems then I need to know how to reproduce that.

>> I'll inject the -2 version shortly, thanks.
>
> see Q5 from document linked in my signature

I've injected -3 as UNRELEASED and I'll keep it at -3 until it gets
into the archive. I hope that is okay.

Best regards
Zygmunt Krynicki


--
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/CAJN_i4-YGqLxz-2EDHnmzTs9+4zF2+ix9j=oohbqa3zt9xm...@mail.gmail.com

please review and sponsor the plainbox package

[Zygmunt Krynicki]

Hello.

I've just successfully injected plainbox into the python-modules
directory [1].I've filed an ITP bug and I'll shortly correct the
changelog to reference the bug number. You can find the git source
corresponding to the package that was uploaded on [2]. I'm also
available in #debian-python to answer any questions that you may have.

[1] 
http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/
[2] https://github.com/zyga/debian.plainbox

Best regards
Zygmunt Krynicki


-- 
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/cajn_i49pwk1qbezsvrmk+f2bko5v5yma6b+k3opnte9vxp6...@mail.gmail.com

please review and sponsor the plainbox package

[Zygmunt Krynicki]

Hello.

I've just successfully injected plainbox into the python-modules directory
[1].I've filed an ITP bug and I'll shortly correct the changelog to
reference the bug number. You can find the git source corresponding to the
package that was uploaded on [2]. I'm also available in #debian-python to
answer any questions that you may have.

[1]
http://anonscm.debian.org/viewvc/python-modules/packages/plainbox/trunk/debian/
[2] https://github.com/zyga/debian.plainbox

Best regards
Zygmunt Krynicki

Re: About access to git.debian.org and the DPMT

[Zygmunt Krynicki]

Hello again.

I've prepared 0.4~b1-2 with the following changes:
(the branch is still on github at https://github.com/zyga/debian.plainbox

On Tue, Nov 26, 2013 at 9:41 AM, Piotr Ożarowski  wrote:

> [Zygmunt Krynicki, 2013-11-26]
> > > * "plainbox is a Simple replacement for CheckBox" looks weird to me,
> > >>   it looks better with lower case "s" IMO (see dev. ref. §6.2.2),
> > >>
> > >
> > > I was reading that and I think that description is no longer accurate.
> I
> > > will write a better one, that describes the purpose of the project as
> it
> > > stands now.
> > >
> > >
> >
> > Rewrote descriptions entirely
>
> please use lowercase "t" and remove the dot from the end of short
> description
>
>
Corrected


> > > * plainbox manpage is missing,
> > >>
> > >
> > > Is it mandatory to have one? I recall reading about not symlinking to
> > > undocumented.7. Plainbox does not currently have a man page but
> instead has
> > > built-in --help. I guess I'm asking about the minimum required man page
> > > that could be worked upon later.
> > >
> >
> > No change yet
>
> it's not mandatory but help2man is so easy to use...
> (and even if you decide to not write/generate one, let lintian complain
> about it)
>

I now auto-generate both man pages at build time. I was unsure if this is
the right avenue (it won't affect cross building as this is an -all package
but perhaps there are some guidelines on how to use help2man). I'll work on
getting upstream man pages generated with sphinx, which should fix that
issue in a couple of releases.


>
> > > How should I inject that into SVN? Will I get commit access to the
> > > collaborative repository?
>
> you already have commit access,
>
> https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Work_With_The_Packages
>
>
I'll inject the -2 version shortly, thanks.

>
> > Before I sort that out I've updated the repository on github.
> > Please have a look and tell me if I missed anything.
>
> please move -doc package to "extra" priority; sorry I forgot to mention
> it in my last mail
>

Done

I also made sure to fix the vendorized packages. Those are now patched
away, totaling in three patches in debian/patches. Two will be dropped by
the time beta2 is released. The remaining one has to be carried for as long
as python3.2 is supported by the upstream plainbox project but should not
change so won't be a burden to maintain.

Thanks
ZK

Re: About access to git.debian.org and the DPMT

[Zygmunt Krynicki]

On Mon, Nov 25, 2013 at 11:22 PM, Zygmunt Krynicki <
zygmunt.kryni...@canonical.com> wrote:

> Hi.
>
> Thanks for the quick review!
>
>
> On Mon, Nov 25, 2013 at 9:24 PM, Piotr Ożarowski  wrote:
>
>> > [1] https://github.com/zyga/debian.plainbox
>>
>> * -doc package is empty,
>>
>
> Odd, it wasn't when I was building it, I must have broken something before
> the final packaging commit.
>

Docs were being added to the plainbox package by mistake, this is now
corrected.


>
>
>> * debian/copyright is not complete, there are Python Software
>>   Foundation, Aaron Iles, Michael Foord and Linaro Limited files in
>>   plainbox/vendor dir,
>>
>
> All of those will be removed. This is in the debian/TODO.txt, basically
> none of the vendor packages are needed in recent enough Debian and Ubuntu
> releases.
>
>
>> * about plainbox.vendor - please use packaged versions of this modules
>>   and drop them from python3-plainbox (at least mock and funcsigs are
>>   not needed),
>>
>
> As above.
>

No change so far


>
>
>> * XlsxWriter is not packaged for Debian and you probably need it in
>>   Recommends or Suggests (if the later one, we can upload it without
>>   waiting for python3-xlsxwriter package),
>>
>
> Good point, thanks. I'll do that.
>
>

Done

* debian/changelog: distribution is wrong, you want to upload to
>>   unstable, right?
>>
>
> This one was for Ubuntu 14.04, I'll make a branch for unstable (I didn't
> expect to get this review that fast :-)
>
>

Corrected. The branch 'sid' is now the master branch and the 'trusty'
branch is a derivative with minimum changes.


> * "Priority: extra" - please use "optional" by default (unless there's a
>>   reason to use different priority); FTP masters will later move it to
>>   "extra" for unknown reason (I suspect they just don't like me and move
>>   all packages I upload/sponsor to "extra" ;), but IMO the right
>>   priority is optional in this case,
>>
>
> Noted, thanks.
>
>

Corrected


> * add DPMT to Uploaders,
>>
>
> d...@debian.org?
>

I figured this out and corrected


>
>
>> * Standards-Version 3.9.5 is already out, please check
>>   /usr/share/doc/debian-policy/upgrading-checklist.txt.gz,
>>
>
> Will do.
>
>

Updated without any changes.


> * "plainbox is a Simple replacement for CheckBox" looks weird to me,
>>   it looks better with lower case "s" IMO (see dev. ref. §6.2.2),
>>
>
> I was reading that and I think that description is no longer accurate. I
> will write a better one, that describes the purpose of the project as it
> stands now.
>
>

Rewrote descriptions entirely


> * there's "XS-Testsuite: autopkgtest" but I don't see any tests in the
>>   package,
>>
>
> Disabled because of the bug preventing unit tests to run. This will be
> fixed in beta2 on Wednesday.
>
>

I've removed XS-Testsuite until this can be re-enabled


> * plainbox manpage is missing,
>>
>
> Is it mandatory to have one? I recall reading about not symlinking to
> undocumented.7. Plainbox does not currently have a man page but instead has
> built-in --help. I guess I'm asking about the minimum required man page
> that could be worked upon later.
>

No change yet

>
>
>> * I'd use s/b/~/ instead of s/b/~beta/ in debian/watch (to keep it as
>>   close to upstream as possible), and please escape last dot in this
>>   file.
>>
>> Noted, will fix this.
>

Fixed


>
>
>> Fix those and inject to our SVN repo (that's right, we don't use GIT...
>> yet)
>>
>
> How should I inject that into SVN? Will I get commit access to the
> collaborative repository?
>
>
Before I sort that out I've updated the repository on github.
Please have a look and tell me if I missed anything.

Best regards
ZK

Re: How to split off main executable from python3-foo to foo

[Zygmunt Krynicki]

On Mon, Nov 25, 2013 at 8:44 PM, Piotr Ożarowski  wrote:

> Cześć,
>
>
Cześć


> [Zygmunt Krynicki, 2013-11-25]
> > I'm writing to to you as the upstream for pybuild.
> >
> > I'm trying to use pybuild to split a simple upstream python3-only project
> > into a number of smaller packages. I'm having problems trying to force
> the
> > main executable to move away from the python3-foo library package into
> the
> > foo "main" package. Is there any simple way of doing that?
>
> if it's only about executables: consider not splitting it into smaller
> packages at all (unless these packages will pull additional dependencies).
>

Currently it is about being discoverable. We care about our users being
able to simply 'sudo apt-get install plainbox' to get the basic development
tool installed. Since plainbox is also a library for other projects we
wanted to have python3-plainbox as a dependency. It is likely that we will
eventually move some of the development tools away from the package but
even then it is unclear if that would affect dependencies in any way.


> If that's not an option, you can simply `mv debian/python3-foo/usr/bin/foo
> debian/foo/usr/bin` in debian/rules or use debian/foo.install
> files instead of PYBUILD_NAME/PYBUILD_DESTDIR.
>
> If it's about moving files to private directory, use¹ distutils'
> --install-scripts=/usr/share/doo --install-dir=/usr/share/foo and add
> (f.e. via debian/foo.links) /usr/bin/foo → /usr/share/foo/script symlink.
>
>
Thanks!

If I didn't guess right, you have to be more specific, or point us to
> your initial work.
>
>
This is for my initial plainbox package. In this particular case I have to
ship /usr/bin/plainbox-trusted-launcher-1 in python3-plainbox but really
want to have /usr/bin/plainbox in the plainbox package for the reasons
stated above.

Best regards
ZK

Re: About access to git.debian.org and the DPMT

[Zygmunt Krynicki]

Hi.

Thanks for the quick review!


On Mon, Nov 25, 2013 at 9:24 PM, Piotr Ożarowski  wrote:

> > [1] https://github.com/zyga/debian.plainbox
>
> * -doc package is empty,
>

Odd, it wasn't when I was building it, I must have broken something before
the final packaging commit.


> * debian/copyright is not complete, there are Python Software
>   Foundation, Aaron Iles, Michael Foord and Linaro Limited files in
>   plainbox/vendor dir,
>

All of those will be removed. This is in the debian/TODO.txt, basically
none of the vendor packages are needed in recent enough Debian and Ubuntu
releases.


> * about plainbox.vendor - please use packaged versions of this modules
>   and drop them from python3-plainbox (at least mock and funcsigs are
>   not needed),
>

As above.


> * XlsxWriter is not packaged for Debian and you probably need it in
>   Recommends or Suggests (if the later one, we can upload it without
>   waiting for python3-xlsxwriter package),
>

Good point, thanks. I'll do that.


> * debian/changelog: distribution is wrong, you want to upload to
>   unstable, right?
>

This one was for Ubuntu 14.04, I'll make a branch for unstable (I didn't
expect to get this review that fast :-)


> * "Priority: extra" - please use "optional" by default (unless there's a
>   reason to use different priority); FTP masters will later move it to
>   "extra" for unknown reason (I suspect they just don't like me and move
>   all packages I upload/sponsor to "extra" ;), but IMO the right
>   priority is optional in this case,
>

Noted, thanks.


> * add DPMT to Uploaders,
>

d...@debian.org?


> * Standards-Version 3.9.5 is already out, please check
>   /usr/share/doc/debian-policy/upgrading-checklist.txt.gz,
>

Will do.


> * "plainbox is a Simple replacement for CheckBox" looks weird to me,
>   it looks better with lower case "s" IMO (see dev. ref. §6.2.2),
>

I was reading that and I think that description is no longer accurate. I
will write a better one, that describes the purpose of the project as it
stands now.


> * there's "XS-Testsuite: autopkgtest" but I don't see any tests in the
>   package,
>

Disabled because of the bug preventing unit tests to run. This will be
fixed in beta2 on Wednesday.


> * plainbox manpage is missing,
>

Is it mandatory to have one? I recall reading about not symlinking to
undocumented.7. Plainbox does not currently have a man page but instead has
built-in --help. I guess I'm asking about the minimum required man page
that could be worked upon later.


> * I'd use s/b/~/ instead of s/b/~beta/ in debian/watch (to keep it as
>   close to upstream as possible), and please escape last dot in this
>   file.
>
> Noted, will fix this.


> Fix those and inject to our SVN repo (that's right, we don't use GIT...
> yet)
>

How should I inject that into SVN? Will I get commit access to the
collaborative repository?

Thanks
ZK

About access to git.debian.org and the DPMT

[Zygmunt Krynicki]

Hi.

I'd like to join the Debian python modules team.

My goal is to maintain a set of packages related to PlainBox [1] I have
prepared packaging for Ubuntu 14.04 and I'd like to prepare one for Debian
as well.

My alioth username is zyga-guest.

Best regards
Zygmunt Krynicki


[1] https://github.com/zyga/debian.plainbox

How to split off main executable from python3-foo to foo

[Zygmunt Krynicki]

Hi Piotr.

I'm writing to to you as the upstream for pybuild.

I'm trying to use pybuild to split a simple upstream python3-only project
into a number of smaller packages. I'm having problems trying to force the
main executable to move away from the python3-foo library package into the
foo "main" package. Is there any simple way of doing that?

Best regards.
ZK

Re: How to run upstream test suite that uses ‘tox’?

[Zygmunt Krynicki]

Hi

I had a look at their tox.ini and IMHO you won't be able to reproduce that
with plain setuptools alone. You'd have to see what the test is doing to
see what I mean. They are testing multiple variants of the build as well
(without and with native extensions). It might be possible to test
everything in one swoop but you'd have to modify coverage to allow you to
choose CTracer or PyTracer. I think it's best to keep talking to upstream
developers to get them to converge on something that would be good enough
to run.

Alternatively you can just test one variant and have something better than
nothing.

Good luck.
ZK


On Sun, Nov 17, 2013 at 9:29 AM, Dmitry Shachnev  wrote:

> I tried running the test commands outside tox, and got
> .
>
> Also, as I said on IRC, another problem with the tests is that they
> use nose, so enabling them will lead to build-dependency loop between
> nose and python-coverage.
>
> --
> Dmitry Shachnev
>
> On Sat, Nov 16, 2013 at 1:06 PM, Ben Finney 
> wrote:
> > Howdy all,
> >
> > I'm trying to run the test suite of a packagfe I'm maintaining. Upstream
> > only supports running the test suite using ‘tox’:
> >
> > $ tox -e py27,py33
> >
> > But this fails in a Debian build environment because ‘tox’ expects to
> > install packages from PyPI, and ignores already-installed OS packages.
> >
> > With ‘python-nose’ and ‘python-mock’ both installed, ‘tox -e py27’ still
> > attempts to install ‘nose’ and ‘mock’ from the internet (and fails
> > because I've disabled internet access in the build environment).
> >
> > How can I convince ‘tox’ to use the OS-installed packages?
> >
> > Alternatively, I don't really care about the special features of ‘tox’;
> > I only want to run the test suite with the specific PYthon version. What
> > can I do in the build environment to run the test suite as ‘tox’ would
> > run it?
>
>
> --
> 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/cakimphvqcgf_gw0xapwzwroapgd9zpfa+7pgty6h4k+ry0c...@mail.gmail.com
>
>

Re: CLI recommendations for version-specific /usr/bin scripts

[Zygmunt Krynicki]

Hi Barry, Thomas.

On Mon, Nov 11, 2013 at 7:13 PM, Thomas Kluyver wrote:

> On 11 November 2013 08:45, Barry Warsaw  wrote:
>
>> > Question: dash or no dash in the script name?
>>
>
I personally like the name-version format as it often separates things in
Debian so I'd tab-tab until I get to see some set of choices and the dash
gives it a nice visual separation.

Best regards
Zygmunt Krynicki

Re: PEP 453 affects Debian packaging of Python packages

[Zygmunt Krynicki]

ot get the "upgrade" required by another application.


Our model assumes that only one version may be installed. This is the 
spherical model in vacuum model IMHO. We seem to love special-casing 
super-important packages like the kernel, database servers and a few 
others, where we support co-installation, but we frown upon the concept 
that this is something that is universally needed for all the other 
packages.


What might be healthy for the project is to recognize that Debian is 
not "maintaining" all of the packages equally. We could provide 
packages for all library versions but not provide security fixes 
ourselves. We would still have to solve the problem of "picking" the 
right library version for a given program but it's certainly in the 
"doable" spectrum (especially if we're talking about python)





 'maintainer rights'. Packaging should not be an art form. If 
someone uploads a
 newer version to Debian mentors (or another submission system), the 
maintainer
 should get an e-mail. If a package is out of date for more than a 
few days
 without a clear reason, people should be prodding the maintainer to 
ask what's
 up. If a maintainer is regularly unresponsive, drop the package to 
team
 maintainership so that other people can work on it. Put another 
way, focus on
 what is best for Debian and for the upstream project being 
packaged, not what
 the person who has appointed themself 'maintainer' of that package 
wants.



While I generally agree, most of the time the maintainer of a package
knows the details better than anyone else in the project, and can make
better techincal decisions.



I don't think this is true but I have no data to back my claim. 

I'd say that for a large majority of packages there *should* be no 
single maintainer as that person has no better knowledge than project 
developers and the fact that only one person is blessed is an 
artificial bottleneck which is impacting users.


For the context of python we could have *no* maintainers and only a 
fully automatic packaging process. This goes hand in hand with the 
'special subset' for which the Debian project might care more (for 
example, because of special security concerns or legacy properties that 
are hard to migrate), enough to warrant a human having to "ack" each 
automated change as we do now.






 - Make it really, really easy to accept changes to packaging. One 
of the
 reasons for the meteoric rise of Github is that when someone 
submits a change
 that clearly improves things, the repository owner literally just 
has to click
 a big green button to accept that. I don't mean DPMT should use 
Github, but,
 for instance, if upstream makes a bugfix release 1.4.3, and Debian 
has 1.4.2,
 it should be as near as possible one click/one command to grab the 
new version,
 update the changelog, commit the change, upload the package, and 
whatever else

 needs doing.


(check the license, review the diff for changes that may cause issues
or are unsafe, ensure it doesn't break API, )



License, yes, because the project is responsible for that.

Everything else - no. If the "maintainer" wants to do that kind of work 
I would suggest that he or she joins the developers and just work 
upstream.


Why does the Debian project have to second guess everything? Do we 
really feel qualified to do that on a large scale?


Maybe if this wasn't happening then we would get more people that 
develop the software to give us a hand, as they would be interested in 
giving the best possible service to their users. This might also 
address some of the scalability issues with the current packaging model.






 I know this won't go down well with everyone here. I contend that 
if the
 situation continues as is, Debian packaging will be seen as ever 
more
 irrelevant by Python developers. Already, the default assumption is 
that distro



We care more about users than developers. Python developers can use
virtualenv and pip on Debian like any other Python development env.



Is this codified anywhere? That Debian project puts the needs of the 
users above the needs of users that also happen to develop software?


Your second statement is valid but it only means that packaging for 
Debian is ever-more-irrelevant. That hurts everyone as packging 
applications is hard without having their libraries packaged (see 
catch22 above).


Best regards
Zygmunt Krynicki



--
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/523c95c9.6cb6b40a.3f21.8...@mx.google.com

Re: PEP 453 affects Debian packaging of Python packages

[Zygmunt Krynicki]

W dniu śro, wrz 18, 2013 o 10:57 ,nadawca Tshepang Lekhonkhobe 
 napisał:
On Wed, Sep 18, 2013 at 3:36 PM, Paul Tagliamonte 
 wrote:
   4) Python modules from dpkg are borderline useless for 
developers. We
  package modules so that apps can use them, not so that people 
can

  develop with them.


Are they 'borderline useless' because they are normally much older
than upstream? I think most development work has no need for
latest-and-greatest



I think this assumption is wrong. You may want to get security fixes, 
features or any combination of the above. 


In my experience debian _packages_ tend to strongly cluster as either 
well maintained and up-to-date or just dead and forgotten. In the 
second case I would bet that all real users (developers) are just 
taking the version from pypi and totally ignore the one in Debian.


Also note that for testing many projects rely on tox or other 
virtualenv-wrapping system (just look at travis-ci for the number of 
projects that use pypi-originated source ignoring any debian packages) 
so any developer that works on a project like that is realistically 
always using a virtualenv for development (for isolation of 
dependencies and precise version control, note that none of this is 
about security, it's just about getting the combination that works in a 
process where change is under the control of the developer)


Best regards
ZK


--
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/523a1646.8264b40a.26e5.5...@mx.google.com

Re: Current state of packaging Python software for Debian

[Zygmunt Krynicki]

W dniu 15.06.2011 03:28, Ben Finney pisze:


If we are talking from a perspective of upstream developers that
also maintain their packages then I would *love* to see setup.py
sdist-test and would use it each day.


;-)


How would a putative ‘sdist_test’ differ from ‘test’? Why is this an
argument for a new command, and not an argument to improve what is done
by ‘test’ anyway?


Pure test runs the test on the check-out of the code and is usually 
invoked by the upstream developer. It can (and often does) run on a 
superset of files that are distributed with sdist).


In contrast, the theoretical sdist_test would first create a release 
tarball with sdist, unpack it to some temporary directory and run 
`setup.py test` there.


Such a command would be useful for checking that project manifest file 
contains everything desired to make the program run correctly (I often 
miss something and only realise it's missing when I start packaging).


IMHO it should be a separate command to ensure that 1) stuff that works 
today keeps working 2) there is no performance penalty for running 
setup.py test that would be required by setup.py sdist_test.


Best regards
ZK



--
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/4df86ad1.7020...@canonical.com

Re: Current state of packaging Python software for Debian

[Zygmunt Krynicki]

W dniu 15.06.2011 02:46, Jakub Wilk pisze:

* Zygmunt Krynicki , 2011-06-15, 01:03:

In a setup.py world:

$ python setup.py build_sphinx

This is all fine and pretty (thanks to python).


Only if you are happy that your extension modules are built in-place. :/


I did not use extension modules yes so I probably did not run into the 
problem. Out of curiosity (and future-proofing my packages), what is the 
good way of building those extension modules and why?



In recent versions of debhelper, dh_compress doesn't touch these files
anymore.


Cool!


build-depend on sphinx


*sigh*


Why sigh?


and recommend jquery on -doc package.


Why recommend? If you have a separate -doc package (hint: not every
package have one), there's no good reason to leave jquery.js symlink
dangling.


AFAIR because it's really required to read the documentation. It is only 
used for the search feature. I don't remember the details but I found 
this pattern to be used by several existing packages.




Always the same boring and useless text in -doc-base files.


Care to propose an algorithm for generating them?


It would help if there was an active user community that consumes those 
files somehow. I don't see much value to them TBH. We could simply use a 
placeholder text like "foobar-doc documents the python package 
python-foobar".




Georg (the upstream Sphinx maintainer) makes a good point, which is
that he really can't be expected to test Sphinx with any version of
jquery than the one he ships.


I missed this part earlier.

Is it because jquery in sphinx is patched or is it because there is no 
good backwards compatibility between various jquery releases?


Thanks
ZK


--
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/4df80520.7080...@canonical.com

Re: Current state of packaging Python software for Debian

[Zygmunt Krynicki]

W dniu 15.06.2011 02:28, Yaroslav Halchenko pisze:


On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:

That's different. IHMO you ask for make dist-check AFAIR (my
automake-foo is getting old). Testing installed stuff is often
harder and not supported as we don't want to include tests in the
package (for build-deps vs install-deps). Source layout is also
different from installed layout. Some data files required for
testing are also not present in the production environment.


valid points BUT so far the test batteries usually included with the
python modules I package relied on reasonably small amount of data
files, so upstream usually doesn't mind have them installed alongside
with the tests installed alongside with the modules themselves.
Benefits:  any user can run tests later on (usually by "import m1;
m1.test()") to verify that everything on his system is still functioning
as promised (e.g. there were no upgrades of the 3rd party modules,
breaking the functionality of the module in question; or effects of
user-specific environment/settings/etc which could not be foreseeing
during package building)


I agree in the value but I don't want to assume that it is a default 
practice or requirement. I package/hack on the webapp (django) side of 
tests and after being spoiled with the goodness of python-testtools and 
python-testscenarios I ventured to create equivalents (compatible 
wrappers really) for django. This means that my packages build depend on 
5 additional packages just for testing. In addition to that (due to the 
way django works) each django application I make (a python package 
really) has a helper django project (another python package) that allows 
it to invoke the test. In practice it means that:


1) Running tests is non-trivial. It works when you do it via setup.py 
test but it was not easy to get to that point. It's not something you 
can reproduce easily after installation without shipping the setup file 
somehow and (unfortunately) setup.py often uses find_packages() to 
discover where the code is. I did not check this but I suspect it might 
break in subtle ways as it was never intended to be used post-install.


2) Test code itself is large and has significant dependencies. 
Separating that from production deployments is important. Perhaps some 
python packages/modules are easy and have little or no extra data files 
but we cannot assume that's the case for all modules.


I'm not trying to say "it's a bad idea", I want to figure out how to do 
it properly.



Testing that python setup.py sdist output can still run tests is
valuable but falls under release management - not packaging.


oops -- I bluntly believed that we are taking care about both
aspects in Debian ;-)


Well joke aside you cannot fix the tarball that people release on pypi 
with half of the test code and data missing just because their 
MANIFEST.in was flaky.


In that sense we are not doing "release management" as there is no 
equivalent of dist-check without being able to fix .orig.tar.gz.


If we are talking from a perspective of upstream developers that also 
maintain their packages then I would *love* to see setup.py sdist-test 
and would use it each day.


Thanks
ZK




--
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/4df7ff48.3000...@canonical.com

Re: Current state of packaging Python software for Debian

[Zygmunt Krynicki]

W dniu 15.06.2011 02:13, Ben Finney pisze:



$ python setup.py test


I would also like this to become the de-facto standard. Can we somehow
make it happen? (debian policy, python something?)3.3).


AFAICT it *is* the de facto standard. Perhaps you mean that you want it
to be the de jure standard? What change are you wanting on this?


You are right, I did me an "official" not "in practice", sorry about that.

I guess I'm just asking, can we just do it? (flip a switch to make it 
official somehow). If not can we just start running `setup.py test` 
implicitly. It does nothing harmful when there is no test suite defined.




I would say it's also incumbent on the jQuery developers to stop
recommending that every application bundle the library leading to
rampant proliferation of different versions and custom patches. But
that's not something that will be fixed within the scope of this
discussion.


It's hard not to bundle unless you are only targeting Debian. I don't 
see anything that the upstream can recommend to make that better for us.




2) We keep stripping jquery and replacing it with a symlink to
libjs-jquery but we make the process less cumbersome and manual.


It would be good to work with the jQuery developers in some capacity on
this.


I don't see how jQuery upstream can help us with this. I was referring 
to the seemingly identical code I see in my packages that:


1) Build the documentation with sphinx
2) Puts it into a separate package
3) Replaces a copy of jquery with a symlink to libjs-jquery.
4) Makes sure that .css and .js files are not compressed

I'm only asking to make 1-4 a recommended practice for Debian packages 
of python packages/modules that use sphinx for documentation. If we can 
make 1-4 implicit (somehow) this would simplify a lot of things.


Thanks
ZK


--
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/4df7fd0e.7010...@canonical.com

Re: Current state of packaging Python software for Debian

[Zygmunt Krynicki]

W dniu 15.06.2011 01:06, Yaroslav Halchenko pisze:

ideally I would like to see the helper which would allow (or even by
default would do) to invoke test batteries against just installed  (i.e.
python setup.py install) version of the modules:  in my experience it
helped to avoid various issues of incomplete inclusion of
submodules/data files.


That's different. IHMO you ask for make dist-check AFAIR (my 
automake-foo is getting old). Testing installed stuff is often harder 
and not supported as we don't want to include tests in the package (for 
build-deps vs install-deps). Source layout is also different from 
installed layout. Some data files required for testing are also not 
present in the production environment.


Testing that python setup.py sdist output can still run tests is 
valuable but falls under release management - not packaging.


Best regards
ZK


--
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/4df7f2d9@canonical.com

Re: Current state of packaging Python software for Debian

[Zygmunt Krynicki]

W dniu 15.06.2011 00:04, Barry Warsaw pisze:

On Jun 14, 2011, at 05:53 PM, Zygmunt Krynicki wrote:


Can please we have standardized hooks to build sphinx documentation and run
setup.py test tests?


I'd like to see the packaging folks address this.  Eric is subscribed to this
list and can probably speak to packaging's take on it, but my preferences
would be that

$ pysetup test


I have no practical knowledge of python3 (are we there yet?) so I cannot 
comment but...


  In Python<  3.3, using

setuptools/distribute/distutils2, this should be the standard interface:

$ python setup.py test


I would also like this to become the de-facto standard. Can we somehow 
make it happen? (debian policy, python something?)3.3).



Below I cut most of the discussion where we agree on sphinx 
documentation and python.



In a setup.py world:

$ python setup.py build_sphinx


[cut]

This is all fine and pretty (thanks to python). On the debian side I 
always have to copy-paste the same-looking code over and over again 
(symlink jquery, don't compress .js and .css, build-depend on sphinx and 
recommend jquery on -doc package. Always the same boring and useless 
text in -doc-base files. All begs for automation.




Georg (the upstream Sphinx maintainer) makes a good point, which is that he
really can't be expected to test Sphinx with any version of jquery than the
one he ships.  Operating systems (Debian/Ubuntu) are the integrators, and as
Jakub points out in that issue, if Debian deviates from upstream by replacing
Sphinx's version of jquery, it's incumbent on Debian to ensure it works
properly.


I agree, still, in the end there are only two possible choices:

1) We stop replacing the bundled jquery and recommend this as best practice.

2) We keep stripping jquery and replacing it with a symlink to 
libjs-jquery but we make the process less cumbersome and manual.


Best regards
ZK


--
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/4df7e8a4.5090...@canonical.com

Re: Current state of packaging Python software for Debian

[Zygmunt Krynicki]

W dniu 14.06.2011 16:45, Barry Warsaw pisze:


I want to be a conduit between Debian and upstream, so please, I encourage
everyone who has concrete issues that can help the Debian story, to raise them
here.  Python is a big ship so it takes time to steer, but as I hope I've
shown with PEP 3147 and 3149, we *can* steer it into a more Debian-friendly
direction.


Can please we have standardized hooks to build sphinx documentation and 
run setup.py test tests? Can those hooks do the right thing with 
generated documentation (dealing all the boring .doc-base files, 
replacing jquery with symlinks, ensuring proper requirements are used).


Thanks
ZK


--
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/4df783e6.8080...@canonical.com

Re: Proposal for a Python-related GSoC project

[Zygmunt Krynicki]

W dniu 23.03.2011 13:41, Francesca Ciceri pisze:
> [please CC me, as I'm not subscribed]
>
> Hi all,
> as you probably have known, also this year Debian has been selected as a
> mentoring organisation for Google Summer of Code.
> Now is the right time to propose projects and apply as mentors, so we can
> catch the best students ;)
> During a brainstorming about possible project, Lars Wirzenius has 
proposed a

> Python one, so here I am.
> Let me quote directly his proposal:
>
> <  liw>  how about something like dh-make-perl but for python's pypi?
> i.e., take a package from pypi (the python package inventory) and
> make a rudimentary debian package out of it, automatically?

You might be interested to learn more about pkgme 
(https://launchpad.net/pkgme). It is designed as a generic shell for 
various packaging plugins. One of the first plugins that AFAIK was 
created was one that creates proper packaging for python+distutils.


I'm CCing upstream author (James Westby) perhaps he would be interested 
to know more about this.


Best regards
Zygmunt Krynicki


--
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/4d89ecdb.8060...@ubuntu.com

django-debian 0.1 released

[Zygmunt Krynicki]

Hello.

I've just released django-debian 0.1

The goal of this package is to provide tight integration between various 
Debian-specific configuration systems and Django applications.


This initial release provides support for dbconfig-common with sqlite3 
backend. Additional backends will be provided shortly after testing.


You can get the tarball from [1], source code from [2], package in 
bzr-builddeb format in [3]



I look forward to all comments and contributions.

Best regards
Zygmunt Krynicki

[1]: http://pypi.python.org/pypi/django-debian/0.1
[2]: lp:django-debian
[3]: lp:~zkrynicki/ubuntu/lucid/django-debian/packaging


--
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/4d77841e.5030...@ubuntu.com

Re: Packaging Django applications and projects

[Zygmunt Krynicki]

eral.


I'm a little worried about upgrade verbosity. In particular, I would 
like to allow silent (unattended) upgrades if possible. I think with 
proper debconf settings it's possible to ask the question "do you want 
to upgrade database schema to version $FOO" with "yes, I do" being the 
silent default. The issue here is that unless you upgrade you cannot 
really start the application properly which should (AFAIR) be treated 
equally as upgrade failure. That's rather extreme IMHO. I'd rather 
require that applications can be safely upgraded because the system will 
create appropriate database/media files backups before it triggers the 
process.



Data: I like to differentiate between data supporting the package and
data that belongs to the sysadmin/site. IMO the former belongs in /var
somewhere and the latter at a path chosen by the sysadmin. I don't
think this is gotten right by much software, including by all database
packages.


How do you differentiate which data belongs to the sysadmin/site and 
which to the package? Do I understand correctly that user-submitted 
content is "application data" and static resources are "package data"?


Thanks for the feedback!
Zygmunt Krynicki

[1] 
http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html#s-httpd-location



--
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/4d766b0d.1030...@canonical.com