Re: [Python-apps-team] RFS: cgmail (adopted)

[Dmitrijs Ledkovs]

2009/2/16 Sandro Tosi :
>
> you'd be welcome to so do :) You can find some documentation at [1]
> [2] [3], and feel free to ask d-pyt...@l.d.o for clarification or, if
> you hang around irc, we're on #debian-python at irc.debian.org.
>
> [1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam
> [2] http://python-apps.alioth.debian.org/policy.html
> [3] http://wiki.debian.org/PAPT_Howto
>

Thanks for the links. Inject didn't work so I did the manual injection. Looks
good to me =D

* Updated Maintainers field to PAPT
* Set myself in Uploaders
* Update VCS-* fields to point to svn
* Rebuild from svn and uploaded to mentors

I again kindly request to sponsor this upload for me.

I am looking for a sponsor for the new version 0.5-1
of my package "cgmail".

It builds these binary packages:
cgmail - A new shiny mail checker for the GNOME desktop

The package appears to be lintian clean.

The upload would fix these bugs: 461447, 515539

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/c/cgmail
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/c/cgmail/cgmail_0.5-1.dsc

-- 
With best regards


Ледков Дмитрий Юрьевич


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

Re: Butchered python configuration ...

[Dmitrijs Ledkovs]

2009/4/28 itsovermyhead :
> 2009/4/28 Piotr Ożarowski :
>> [itsovermyhead, 2009-04-28]
>>> dev3:/usr/bin# ls -la python*
>>> -rwxr-xr-x 2 root root 1015264 2008-10-23 08:53 python
>>> -rwxr-xr-x 2 root root 1015264 2008-10-23 08:53 python2.4
>>> -rwxr-xr-x 1 root root    1276 2008-10-23 08:53 python2.4-config
>>
>> I'd start with:
>> # rm /usr/bin/python # and all other local files
>> # ln -s /usr/bin/python2.4 /usr/bin/python
>
> Thanks for your reply Piotr - are you confident about this solution? A
> lot of people use this server so I want to be as sure as possible that
> this is the right approach to the problem.
>
> Can you could explain your reasoning so I can understand what you're
> proposing better.
>
> Cheers
>
> S
>

As far as i know. python binary is always the default python
interpreter which points to one of the supported version and by
default it points (symlink) to python2.5 in lenny (I think). the
pythonX.Y are actually real binaries.

If you are not convineced I gues you should

$apt-get source python

and study the packaging.


-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич


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

Re: sk1 package

[Dmitrijs Ledkovs]

2009/5/19 Vladimir Osintsev :
>>> * starting debian/copyright , but there is lot of work - code has a
>>> number of authors (attention to libraries and plugins)
>>
>> It's a lot of bureaucratic work, but if we don't do this right, the package
>> will be rejected immediately. Vladimir, can you start with this? Igor, you
>> probably want to have this file in your source package as well.
>
> Okay, I will begin this "bureaucratic work".
>
>

$ licensecheck -r .

note the dot above

and

http://dep.debian.net/deps/dep5/

Your friends =D

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич


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

Re: Packaging plugins for Python applications

[Dmitrijs Ledkovs]

2009/5/29 Jakub Wilk :
> Hello,
>
> What is the correct umbrella to package a plugin for a Python application
> under? DPMT or PAPT?
>

Depends how you package it. If you "inject" it into the app's private
modules folder eg /usr/share/APPLICATION/plugins/ then I
think it is safe to go into PAPT. If you install/package it as a
public module than it has to go into DPMT.

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич


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

Re: VCS for Python code Was: Trac team almost dead?

[Dmitrijs Ledkovs]

Recently I have discovered some very nice features of hg that make it
attractive:

1) Multiple branches such that debian/ can be kept on alioth and have
working copy that has everything if maintainer prefers so
2) MercurialQueues plugin allows to keep versioned quilt patches,
rebase, merge and split them. Keep their history in a seperate branch
and always upto date series file.

This 2 features are very neat that imho bzr and git are lacking. (well
bzr will have stable support for nested trees soon can be simulated
with checkouts now and git has tg2quilt)

One major drawback of hg is missing pristine-tar support and abandoned
hg-buildpackage. Anyone willing to start working on this drawback
together with me? I have a little bit of ugly hackish code.  =)


-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич


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

Re: lintian troubles ... almost done

[Dmitrijs Ledkovs]

2009/9/3 Alessandro Dentella :
>> > bad-distribution-in-changes-file
>> > 
>> >
>> >   If I run lintian on .changes it complains
>> >   "bad-distribution-in-changes-file" but I'm unsure on what I should do.
>> >   At present I'm building on an ubuntu-hardy so the name gets written in
>> >   the changelog. There is nothing peculiar of one distro or another so I'm
>> >   unsure what I should write.
>>
>> Not sure about Ubuntu, but for Debian, that'd always be “unstable”
>> (unless you're uploading to another suite of course, but that's
>> another story).
>
> fine thanks. I tryied 'sid', but that's clearly not accepted.
>

For debian valid once are: experimental & unstable (there others but
they are not needed usually). And in general packages get uploaded to
unstable.

For ubuntu you should use the adjectives of a release eg karmic jaunty
etc. for eg ppa uploads.

>
> Last question
> -
>
> When testing creating the package from my newly created sources on a newer
> machine (ubuntu 9.04), lintian complained:
>
> W: python-sqlkit: embedded-javascript-library
>     usr/share/doc/python-sqlkit/html/_static/jquery.js
>
> That's clearly the jquery of the sphinx documentation. It's introduced in
> the upstream package when sphinx compile the docs (not at my build time).
>
> Is it mecessary to fix this or I can just leave it as is (it appears as a
> warning, not an error).
>

Imho documentation should be build (rebuild) at deb package building stage.

>
> thanks again
> sandro
> *:-)
>
>
> --
> Sandro Dentella  *:-)
> http://sqlkit.argolinux.org        SQLkit home page - PyGTK/python/sqlalchemy
>
>
> --
> To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>



-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич


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

Re: lintian troubles ... almost done

[Dmitrijs Ledkovs]

(Please reply to list as well thanks)

2009/9/3 Alessandro Dentella :
>> > Last question
>> > -
>> >
>> > When testing creating the package from my newly created sources on a newer
>> > machine (ubuntu 9.04), lintian complained:
>> >
>> > W: python-sqlkit: embedded-javascript-library
>> >     usr/share/doc/python-sqlkit/html/_static/jquery.js
>> >
>> > That's clearly the jquery of the sphinx documentation. It's introduced in
>> > the upstream package when sphinx compile the docs (not at my build time).
>> >
>> > Is it mecessary to fix this or I can just leave it as is (it appears as a
>> > warning, not an error).
>> >
>>
>> Imho documentation should be build (rebuild) at deb package building stage.
>
> What's the advantage?
>
>  * it's html text
>  * would be just as the one shipped in the upstream version
>  * it would still put jquery.js in it as an automatic routing of sphinx
>    so I should anyhow decide what to do with it
>
> sandro
> *:-)
>

Think of html as binary and code/documentation as source. By
rebuilding you will make sure that:

1) It's up to date
2) That htmls were not modified
3) The source works and produces correct documentation

You should ship upstream "binaries" or html documentation because it's
not the source (preferred form of modification). And think about the
case when later you gonna apply a patch to the package you would want
it to make it into documentation. Source+patches should match to
produced documentation.

I have no clue about the js file bit though. Remove it (via patch) and
symlink it from the shipped package by debian? That is my wild guess.
Or maybe contact sphinx maintainer in Debian. I hope there is an
option to symlink it.

>
> --
> Sandro Dentella  *:-)
> http://sqlkit.argolinux.org        SQLkit home page - PyGTK/python/sqlalchemy
>



-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич


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

Re: RFC: Proposed updates to the Python Policy to reflect current practices

[Dmitrijs Ledkovs]

2009/12/8 Loïc Minier :
>  [ MFT: debian-pyt...@ldo ]
>
>        Hi all,
>
>  To resurrect the Python Policy as a document reflecting required and
>  recommended Python packaging practices, we prepared a set of patches.
>  We started in private to provide a complete set of changes and avoid
>  flames as much as possible, but now we'd like the whole Debian Python
>  community to send comments, feedback, or additional patches.
>


Where is this git repository hosted? Or where can I get the current
version of the policy as seen on the debian.org website?


-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


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

Re: RFC: Proposed updates to the Python Policy to reflect current practices

[Dmitrijs Ledkovs]

2009/12/9 Loïc Minier :
> On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote:
>> Where is this git repository hosted? Or where can I get the current
>> version of the policy as seen on the debian.org website?
>
>  Concerning the Python Policy, it's currently not handled in any VCS, so
>  I created a private git repo from the uploads of the python-defaults
>  package (which I found in the morgue) and committed the proposed
>  changes on top of that.  I can provide a copy of the repo to you, but
>  it's not in any way an official repo for the python-defaults package or
>  the policy.
>
> --
> Loďc Minier
>

Yes please! I'm struggling to read the patches like that I'd rather
read git annotate =) which would be proposed final but with info where
the words came from (patches or old stuff)

Thanks.

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


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

Re: PyGTK and Python 2.6

[Dmitrijs Ledkovs]

2009/12/17 Josselin Mouette :
> Le mercredi 16 décembre 2009 à 19:22 -0500, Scott Kitterman a écrit :
>> >Am I missing something? Can I get "import gtk" to work under Python
>> >2.6 on Debian? Should I try to port Epidermis back to Python 2.5 or
>> >should I wait for Python 2.6 to be fully supported in Debian
>> >experimental or unstable?
>>
>> You would have to rebuild pygtk locally using the experimental packages.  I 
>> expect we'll see
>> Python 2.6 in unstable some time next week.
>>
>> >I'm not looking for a definitive answer, (unless there is one!), just
>> >advice. Thank you.
>> >
>> My advice would be wait.
>
> OTOH porting from python2.6 to python2.5 should be really easy, there
> have been very few language additions to python2.6. This would allow
> your software to also work on Debian stable, as well as some other major
> releases of other distributions.
>

Unless import from future was used extensively

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


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

Re: Double build failures

[Dmitrijs Ledkovs]

On 04/05/12 18:05, Vincent Bernat wrote:
> Hi!
> 
> I got  some bug reports from  Jakub about double build  failures. I have
> always  found those  kind  of tests  a  bit silly,  but  that's just  my
> opinion.
> 
> Most of the time, the failures  are because of the created egg directory
> that is  not cleaned up by the  clean target of setup.py.  While I could
> add the appropriate bits to  each clean target in debian/rules, it seems
> better to  fix the  problem either in  dh_python2 or in  setuptools. Any
> thoughts?


IMHO it is a better fit in dh_auto_clean (python_distutils buildsystem)
and or dh_clean.


-- 
Regards,
Dmitrijs.



signature.asc
Description: OpenPGP digital signature

Re: Double build failures

[Dmitrijs Ledkovs]

On 04/05/12 18:23, Sandro Tosi wrote:
> On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk  wrote:
>>> or in setuptools.
>>
>> Ideally, by burning it with fire.
> 
> CPython upstreams are developing a new module to replace distutils and
> setuptools: packaging. It might be worth check with them if it will
> handle this case.
> 

I swear last week it was called distribute...

(if a buildsystem changes it's name more often than every 10 years think
twice before using it.)


-- 
Regards,
Dmitrijs.



signature.asc
Description: OpenPGP digital signature

Re: Double build failures

[Dmitrijs Ledkovs]

On 04/05/12 19:04, Scott Kitterman wrote:
> On Friday, May 04, 2012 06:38:30 PM Dmitrijs Ledkovs wrote:
>> On 04/05/12 18:23, Sandro Tosi wrote:
>>> On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk  wrote:
>>>>> or in setuptools.
>>>>
>>>> Ideally, by burning it with fire.
>>>
>>> CPython upstreams are developing a new module to replace distutils and
>>> setuptools: packaging. It might be worth check with them if it will
>>> handle this case.
>>
>> I swear last week it was called distribute...
>>
>> (if a buildsystem changes it's name more often than every 10 years think
>> twice before using it.)
> 
> distribute is a fork of setuptools.  distutils is still distutils, so you can 
> use it only thinking once.
> 

ok. what is the relationship between 'distribute' & 'packaging'?


-- 
Regards,
Dmitrijs.



signature.asc
Description: OpenPGP digital signature

Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3

[Dmitrijs Ledkovs]

On 3 September 2012 21:27, Thomas Kluyver  wrote:
> Hi Nigel,
>
> On 3 September 2012 14:57, Nigel Sedgwick  wrote:
>> The application makes heavy use of numpy and wx and will soon make heavy
>> use of scipy, matplotlib and various other python libraries that are
>> widely used.
>
> Python 3 versions of numpy and scipy are already in wheezy. wx and
> matplotlib haven't yet released Python 3 compatible versions, and
> Wheezy is frozen now, so they've missed that boat. If you need to use
> those packages for a substantial application in the near future,
> sticking with Python 2 for now is your safest bet. If you use Python
> 2.6 or 2.7 with modern idioms, it should be relatively easy to port
> code later when all the libraries are ready.
>
> As far as I understand Debian, none of those python3- packages will be
> added to Squeeze. The idea of a stable release is that the only
> updates it gets are bugfixes and security.
>

One more thing there is debian-backports =)

http://backports-master.debian.org/

You may want to request a backport from folks who do those, and maybe
(dependencies permitting) they can make a python3 backport of scipy /
numpy for current stable release squeeze.


> Looking further ahead: matplotlib is aiming to release a Python 3
> version in October. wxPython has a development version working on
> Python 3, but I don't see any indication of how soon a release is
> planned. Other GUI toolkits (Qt, GTK) already support Python 3, if
> they are an option for you.
>
> Best wishes,
> Thomas
>

Regards,

Dmitrijs.


-- 
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/canbhluj7xcppo3bgujw-7+sazvjvet_kjtqdovfh-3-7ruk...@mail.gmail.com

Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz

[Dmitrijs Ledkovs]

On 02/10/12 17:57, Nicolas Chauvat wrote:
> On Tue, Oct 02, 2012 at 09:59:32AM -0400, Barry Warsaw wrote:
>> On Oct 02, 2012, at 02:42 PM, Nicolas Chauvat wrote:
>>
>>> As far as I know, pylint already runs with Python3. Doesn't it?
>>
>> pyflakes is the one we want to port.
> 
> May I ask why ?
> 

Because it was used with python2 code bases, now code is ported to
python3 and we'd like to continue using pyflakes with out python3 code
as before without leaving compatibility future imports around, just for
pyflakes to work.

ps. I'm with barry on this one, btw ;-)

-- 
Regards,
Dmitrijs.



signature.asc
Description: OpenPGP digital signature

Re: DD requesting to join python-modules-team

[Dmitrijs Ledkovs]

On 10 October 2012 16:22, Hans-Christoph Steiner  wrote:
>
> On Oct 9, 2012, at 4:48 AM, Jakub Wilk wrote:
>
>> * Hans-Christoph Steiner , 2012-10-08, 20:14:
>>> I'm a DD that is working on a couple python module packages.  I have 
>>> 'pyjavaproperties' already in wheezy/unstable and python-pure-otr in the 
>>> works, packaged as 'python-potr' since that was the original name and the 
>>> library is still called 'potr', i.e. "import potr"
>>
>> Welcome to the team! :)
>>
>> Please note that we use Subversion as VCS:
>> https://wiki.debian.org/Teams/PythonAppsPackagingTeam/HowTo (but replace 
>> "apps" with "modules").
>
> For a team package, is git-buildpackage out of the question?  If so, I can 
> convert.
>

I doubt you will get hardly any "team" commits for it.
Or team code review from automatic commit emails.

You can check the mailing list archive for the past discussions.
Currently none of the other version control systems / build tools
offer as fluent workflow as the current one for the top
commiters/uploaders/sponsors in the team.

Nothing stops you to use bzr-svn or git-svn though ;-) works like a
charm for me.

Regards,

Dmitrijs.


--
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/canbhlujsouoykp1eabz5po6pf4ujfpm5fl7i2vxqr6_1uof...@mail.gmail.com

Re: RFS: pyxdg 0.24-1

[Dmitrijs Ledkovs]

On 6 November 2012 11:14, Thomas Kluyver  wrote:
> Hello,
>
> I'd like to request a sponsor to upload a new version of pyxdg. This is
> essentially the same as an earlier RFS for 0.23-1, but with a new upstream
> version.
>

Can you add an autopkgtest that runs the upstream testsuite?

Regards,

Dmitrijs.


-- 
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/canbhlugn2rdw8inyoux9ocovhvxbutrwuapi3ett+41k4of...@mail.gmail.com

Re: RFS: pyxdg 0.24-1

[Dmitrijs Ledkovs]

On 6 November 2012 12:36, Thomas Kluyver  wrote:
> On 6 November 2012 12:03, Dmitrijs Ledkovs  wrote:
>>
>> Can you add an autopkgtest that runs the upstream testsuite?
>
>
> I've had a go - can you have a glance at the attached patch? If it looks OK,
> I'll commit it.
>

Looks good. Commit and I will sponsor your package.

Regards,

Dmitrijs.


pyxdg_add_autopkgtest.patch
Description: Binary data

Re: RFS: pyxdg 0.24-1

[Dmitrijs Ledkovs]

On 6 November 2012 12:55, Thomas Kluyver  wrote:
> On 6 November 2012 12:54, Dmitrijs Ledkovs  wrote:
>>
>> Looks good. Commit and I will sponsor your package.
>
>
> Done. Thanks, Dmitrijs.
>

I am thinking to upload to experimental instead of unstable. It's a
few upstream releases jump and a python3 package is introduced.
This makes this changes unsuitable for unstable considering that we
are currently frozen and these changes are not appropriate for wheezy
at this time.
Is that ok with you? Or did you intend to upload into unstable?

Regards,

Dmitrijs.


-- 
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/canbhluidottjeo__+gns-ns1xuobqtg28qy69feznajyxmd...@mail.gmail.com

Re: RFS: pyxdg 0.24-1

[Dmitrijs Ledkovs]

On 6 November 2012 14:09, Thomas Kluyver  wrote:
> On 6 November 2012 13:58, Dmitry Shachnev  wrote:
>>
>> It won't be _automatically_ synced, but you can file a sync request:
>> https://wiki.ubuntu.com/SyncRequestProcess.
>>
>> Or Dmitrijs will sync it for you :)
>
>
> Great, thanks Dmitry.
>
> Dmitrijs, let me know if you're happy to do the sync - otherwise I can make
> a request.

I have a small white board with stuff to sync =) as there is ~6hour
delay until I can do it.
Cool, will upload & sync.

Regards,

Dmitrijs.


-- 
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/CANBHLUhZ3F_BNAzLsOLpTqc_oTi+G=yscse7cpvgjvrpens...@mail.gmail.com

Re: How to prevent debhelper using Python 2

[Dmitrijs Ledkovs]

On 14 November 2012 19:11, Jakub Wilk  wrote:
> * Barry Warsaw , 2012-11-14, 13:17:
>
 While working on the python3-sympy package, I've seen that if Python 2
 is installed, various dh_* commands, like dh_auto_clean, will automatically
 try to run setup.py in Python 2. In this case, setup.py checks the Python
 version and fails. This isn't a problem when building in a clean 
 environment
 like a buildd, but it's annoying when trying to build the package locally.
>>>
>>> s/annoying .*/still an RC bug/.
>>
>> Specifically, which RC bug?
>
>
> I meant that package failing to build in a non-minimal environment (which
> was the case here, if I understood correctly) is an RC bug.
>
> Sorry for not being clean.
>

Yes, a typical case of FTBFS on a BDFH (fails to build from source on
a build daemon from hell) of a wider set of FTBFS in a sane way bugs.

A BDFH is a term coined by Lucas, which means a build daemon with a
many -dev packages installed as possible, especially the license toxic
(e.g. openssl). Because many packages have "autodetection" of
libraries which are not explicitly enabled/disabled and hence produce
different builds in "dirty" environments. There was a full archive
rebuild done in the past, see [1]

[1] https://lists.debian.org/debian-devel/2008/01/msg00869.html

Regards,

Dmitrijs.


-- 
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/CANBHLUgkF4YSF1QBUqj42SemxaH7aeCQ_dnXNN=CEokNT5uY=a...@mail.gmail.com

Re: Solving the multiarch triplet once and for all

[Dmitrijs Ledkovs]

On 18 December 2012 15:48, Paul Wise  wrote:
> Seems like a lot of effort when there is no /usr/bin//python
> so there can be only one arch of python installed anyway. What are the
> use-cases for python multiarch?
>

cross-compiling the archive / cross-bootstrapping the archive for a
new architecture.

Regards,

Dmitrijs.


-- 
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/canbhlujab32bcb+xptzm0z-oo-iie39jkqv2jbl17o+mnp4...@mail.gmail.com

Re: Private modules

[Dmitrijs Ledkovs]

On 22 December 2012 23:27, Barry Warsaw  wrote:
> On Dec 22, 2012, at 05:19 PM, Paul Tagliamonte wrote:
>
>>Yeah, please don't use virtualenv, as much as I'd like to see a good way
>>of using virtualenv in Debian.
>
> Can you expand on that?  It should be usable to develop code, but do you mean
> something else?
>

The way I interpreted Paul's comment is that it implies "don't use
virtualenv inside the .deb package as to be distributed by Debian"
e.g. system-wide python packages should not be using virtualenv
environment out of the box on Debian, as that opens a can of worms.
(virtualenv does nothing to help to what a coherent distribution tries
to achieve).

I do agree with you that one should not "break" vritualenv on purpose
for those people who wish to use it.

Regards,

Dmitrijs.


-- 
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/CANBHLUjiu=RfsBvaj-Q+11yQhFngZMhoPQh=6KFAwk=op4y...@mail.gmail.com

Re: Setting http_proxy in debian/rules

[Dmitrijs Ledkovs]

On 5 February 2013 17:48, Barry Warsaw  wrote:
> There's been a lot of discussion lately on various forums (e.g. catalog-sig)
> about PyPI security.  I realized that our recommendation for setting
> http_proxy in debian/rules can have beneficial local security implications.
>
> More details here:
>
> http://mail.python.org/pipermail/catalog-sig/2013-February/004831.html

I should add a hook to export that for the build & binary stages of
the package build in my sbuild config (but not the fetching
build-deps)
Also one should be able to set that in debuild hooks.

Cause python pypi is hardly the only type of packages that try to go
online for things (waf, maven, gems and custom scripts come to mind).

Regards,

Dmitrijs.


-- 
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/CANBHLUg001BoG9i02OfexcRde-u-NO5o9rHw6bOaVwC_Na=2...@mail.gmail.com

Re: PIL/python-imaging becomes a python package and gets Python3 support

[Dmitrijs Ledkovs]

On 10 February 2013 16:54, Matthias Klose  wrote:
> There are 126 source packages needing updates. The list of packages
> and maintainers is attached below. I'll file bug reports later (user:
> d...@debian.org, tag: pillow).
>

I see that a few packages were identified to work out of the box by
fedora folks and they have also started patching packages.
There is some overlap so it's worth checking fedora trackers before
doing our own patches:
https://fedoraproject.org/wiki/Features/Pillow
https://bugzilla.redhat.com/show_bug.cgi?id=894484

>
> Debian HPIJS and HPLIP maintainers 
>hplip
>
> Matthias Klose 
>python-reportlab
>

Does this mean that hplip & python-reportlab are now have all their
dependenices ported to python3 and hence can also be ported? \o/

Regards,

Dmitrijs.


-- 
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/canbhlugyw1bnnnzsextrrndjqdetj02yaaz3x+vsazagrfk...@mail.gmail.com

Re: How does team maintenace of python module works?

[Dmitrijs Ledkovs]

On 12 February 2013 15:08, Dmitry Shachnev  wrote:
> Hi Thomas,
>
> On Tue, Feb 12, 2013 at 7:00 PM, Thomas Goirand  wrote:
>> ...
>> So I wonder, how is the python module packaging policy? Since this
>> module is marked as team maintained, and that I've been accepted in the
>> python module packaging team on Alioth, am I allowed to just refresh the
>> package, and upload version 1.0 in debian experimental? Or do I need
>> approval from current uploaders?
>>
>> What does it mean for a package to be team maintained in the python
>> packaging team?
>
> If the team is in Maintainer field, I think you can freely upload the
> new version. See
> 
> for details.

But please join the team and update the svn repository, or
alternatively ask somebody from the team to commit your upload.

Regards,

Dmitrijs.


-- 
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/CANBHLUj8e2LVJzSYcERve7+t33cANU+2w=q1cref0zhmheo...@mail.gmail.com

Python Software Foundation: Python Trademark at Risk

[Dmitrijs Ledkovs]

Dear All,

Full article: 
http://pyfound.blogspot.co.uk/2013/02/python-trademark-at-risk-in-europe-we.html

There is a company in the UK that is trying to trademark the use of
the term "Python" for all software, services, servers... pretty much
anything having to do with a computer. Specifically, it is the company
that got a hold on the python.co.uk domain 13 years ago.

According to our London counsel, some of the best pieces of evidence
we can submit to the European trademark office are official letters
from well-known companies "using PYTHON branded software in various
member states of the EU" so that we can "obtain independent witness
statements from them attesting to the trade origin significance of the
PYTHON mark in connection with the software and related
goods/services." We also need evidence of use throughout the EU.

Further instructions on how to submit letters of support are in the
blog article linked above.

Please help defend python trademark.

Regards,

Dmitrijs.


-- 
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/CANBHLUh5LzzB3=fYjWMbFmGSEw452zjV=xfp0oexuxzemfb...@mail.gmail.com

Re: [Python-modules-team] Bug#699312: Bug#699312: pytest version in raring is old

[Dmitrijs Ledkovs]

On 16 February 2013 18:10, Simon Chopin  wrote:
> Hello Joseph,
>
> Quoting Joseph Tate (2013-01-30 05:27:08)
>> I've updated the version of pytest to the latest upstream.  It doesn't need 
>> to be backported, I would just like to see the version in raring be updated.
>>
>> *** /tmp/tmpKV7SC6/bug_body
>> In Ubuntu, the attached patch was applied to achieve the following:
>>
>>
>>   * New upstream release, backport to precise
>>
>>
>> Thanks for considering the patch.
>
> As you might not be aware of, Debian testing is currently frozen, which
> means that to keep a clear migration path for RC bug fixes I avoid
> uploading new upstream versions to unstable at this time.
>
> However, I'm considering uploading this new upstream version to
> experimental as soon as I've figured out how the DPMT deals with
> branching.

Some started pushing experimental to trunk, expecting no further
uploads into sid.
Some create branches/experimental if they expect to keep the two in parallel.
Just do it, and tag it, one can always branch from a tag if further
uploads to sid are required.
Although a consensus would be nice.
d-i team for example is using a "jessie" branch name for things that
should atm be uploaded into experimental.

Regards,

Dmitrijs.


-- 
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/CANBHLUj9Uv63TSv6UO5vc_XF=oKyPCWdfA=vybuxvj-nwsb...@mail.gmail.com

Re: How does team maintenace of python module works?

[Dmitrijs Ledkovs]

On 16 February 2013 14:27, Jakub Wilk  wrote:
> * Scott Kitterman , 2013-02-16, 09:10:
>>
>> On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote:
>>>
>>> The following four positions have all been advocated in this thread:
>>>
>>> A - Maintain the status quo, in which DPMT packages may only be
>>> maintained in SVN.
>>> B - As A, but encourage the creation of a separate team where Python
>>> modules can be maintained in git.
>>> C - Allow DPMT-maintained packages to live in SVN or git, so new packages
>>> can be committed to git if the packager prefers. Optionally, we could make
>>> provisions to migrate existing packages.
>>> D - Migrate all the DPMT-maintained packages to git.
>>>
>>> (I suggest we don't consider other VCSs - while we might have our
>>> favourites, I sampled the list of Debian teams, and found very few using
>>> anything other than svn or git. So tools & workflows for other VCSs are
>>> likely to be less well developed.)
>>>
>>> So I would vote CDBA, in order of preference.
>>
>>
>> E - Migrated to bzr, but I want someone else to to all the work.
>>
>> EA
>
>
> F - Migrate to Mercurial, but I want someone else to do all the work.
>

A, F.1 - Migrate to Mercurial, if and only if mercurial queues are
fully functional and are used to maintain the debian/patches
sub-repository.

realisticly i am opposed to a mix of version control systems.

someone to do the work - means starting a mirror which works in
read-only / mirror mode only.

When gnome.org was migrating from svn - they had multiple mirrors
running (bzr, and git, not sure if an hg was there as well)

Regards,

Dmitrijs.


-- 
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/CANBHLUjUfbFBnanRP2P9pu2M_PmmvEUWC5W4Byi=-ns2hqg...@mail.gmail.com

Re: How does team maintenace of python module works?

[Dmitrijs Ledkovs]

On 16 February 2013 21:35, Robert Collins  wrote:
> On 17 February 2013 08:29, Dmitrijs Ledkovs  wrote:
>> On 16 February 2013 14:27, Jakub Wilk  wrote:
>>> * Scott Kitterman , 2013-02-16, 09:10:
>>>>
>>>> On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote:
>>>>>
>>>>> The following four positions have all been advocated in this thread:
>>>>>
>>>>> A - Maintain the status quo, in which DPMT packages may only be
>>>>> maintained in SVN.
>>>>> B - As A, but encourage the creation of a separate team where Python
>>>>> modules can be maintained in git.
>>>>> C - Allow DPMT-maintained packages to live in SVN or git, so new packages
>>>>> can be committed to git if the packager prefers. Optionally, we could make
>>>>> provisions to migrate existing packages.
>>>>> D - Migrate all the DPMT-maintained packages to git.
>>>>>
>>>>> (I suggest we don't consider other VCSs - while we might have our
>>>>> favourites, I sampled the list of Debian teams, and found very few using
>>>>> anything other than svn or git. So tools & workflows for other VCSs are
>>>>> likely to be less well developed.)
>>>>>
>>>>> So I would vote CDBA, in order of preference.
>>>>
>>>>
>>>> E - Migrated to bzr, but I want someone else to to all the work.
>>>>
>>>> EA
>>>
>>>
>>> F - Migrate to Mercurial, but I want someone else to do all the work.
>>>
>>
>> A, F.1 - Migrate to Mercurial, if and only if mercurial queues are
>> fully functional and are used to maintain the debian/patches
>> sub-repository.
>>
>> realisticly i am opposed to a mix of version control systems.
>>
>> someone to do the work - means starting a mirror which works in
>> read-only / mirror mode only.
>>
>> When gnome.org was migrating from svn - they had multiple mirrors
>> running (bzr, and git, not sure if an hg was there as well)
>>
>> Regards,
>>
>> Dmitrijs.
>
> I will *always* have a soft spot in my heart for bzr, having spent
> many years working on it.
> But consider:
>
> http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bazaar&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date&to_date&hlght_date&date_fmt=%25Y-%25m&beenhere=1
>

Corrected url s/bazaar/bzr/ and disabled vote to make the graph lighter.

http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bzr&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

> If we're changing VCS, there is a vastly higher probability that the
> folk whose software we are packaging is in git, and that contributors
> we get will be familiar with git, than any other system now. That
> doesn't mean git is better or worse, but if we're changing systems
> because of preference (rather than fitness-for-purpose), then I think
> we'd be crazy to consider any other VCS.
>

svn is very alive and stable. I have managed in the past to crash or
otherwise make bzr/hg/git inconsistent. Some of my bugs got fixed and
mostly git is fit for purpose on the stability side of things.
I haven't used hg in a while. svn has always been good for me (but i
guess i'm a fairly recent developer and haven't seen the pre 1.5 days
of svn).

we are yet to figure out a packaging workflow that works great,
especially w.r.t. patch management. On one hand you want to simply
commit and merge, on the other hand you want to ship a patch series
for the convenience of dowstream/users, but that means rebasing, and
rebasing is pain to track history off, hence end up committing patches
but one wants to commit directly LOOPREACHED.

Regards,

Dmitrijs.


-- 
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/canbhluimts5aijzvzcuye9yajm6rzkbskvsadnjdug9prp0...@mail.gmail.com

Re: How does team maintenace of python module works?

[Dmitrijs Ledkovs]

On 19 February 2013 23:49, Ludovic Gasc  wrote:
>
> On Feb 19, 2013 11:21 PM, "Barry Warsaw"  wrote:
>>
>> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
>>
>
> I can do that this week-end. I've only a github account to publish the git
> repository, unless somebody else has an access for a better place? For a
> test, I think that github is enough.
>

Using github would be against the basic principles laid out in the
Debian Social Contract.
While gitorious hosted solution, would be ok it reimplements the git
server & protocol and hence lacks many features.
It is best to continue to use excellent hosting facilities provided by
git.debian.org / alioth.debian.org.
One can create repositories in a home directory (please don't use
official team account / group names) which would be good enough for
maintainance.

Having an gerrit instance would help a lot to serve merge requests
functionality.

Regards,

Dmitrijs.


-- 
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/canbhlugvhb5fv3srj+dojsvit+1hordojkuafzbgeolhx5+...@mail.gmail.com

Re: [Python-apps-commits] r9456 - in packages/pyflakes/trunk/debian (7 files)

[Dmitrijs Ledkovs]

On 25 February 2013 19:03, Sandro Tosi  wrote:
> hey, can you stop committing huge changes without asking to uploaders
> first? I've already contacted you when you un-coordinately upload
> pyflakes to experimental, ans you hadn't reply - it's time to give it
> a stop now
>

I'm sorry for missing your previous email, due to a filtering mistake
on my side.

My understanding was that package has Debian Python Team set as
maintainer, such that improvements and co-maintainership is welcomed.
Newer packages in experimental require/need/want pyflakes support
specifically python3 support.

Do you disagree with proposed changes? If yes, please comment and
revert relevant pieces.

Or is this just a concern over my lack of courtesy? If you feel the
need to ack every commit of pyflakes, you should consider moving
python team to uploads and setting yourself as maintainer and/or
removing the package from the team all together. In either of those
cases, I typically file wishlist bugs with a patch attached.

I again apologies for not promptly replying to your previous message.

Regards,

Dmitrijs.


> On Mon, Feb 25, 2013 at 7:20 PM,   wrote:
>> Date: Monday, February 25, 2013 @ 18:20:53
>>   Author: xnox
>> Revision: 9456
>>
>> Add python3 package / module.
>>
>> Added:
>>   packages/pyflakes/trunk/debian/patches/use-standard-unittest.patch
>>   packages/pyflakes/trunk/debian/pyflakes.manpages
>> (from rev 9455, packages/pyflakes/trunk/debian/manpages)
>> Modified:
>>   packages/pyflakes/trunk/debian/changelog
>>   packages/pyflakes/trunk/debian/control
>>   packages/pyflakes/trunk/debian/patches/series
>>   packages/pyflakes/trunk/debian/rules
>> Deleted:
>>   packages/pyflakes/trunk/debian/manpages
>>
>> Modified: packages/pyflakes/trunk/debian/changelog
>> ===
>> --- packages/pyflakes/trunk/debian/changelog2013-02-25 14:11:44 UTC (rev 
>> 9455)
>> +++ packages/pyflakes/trunk/debian/changelog    2013-02-25 18:20:53 UTC (rev 
>> 9456)
>> @@ -1,3 +1,9 @@
>> +pyflakes (0.6.1-1~exp1ubuntu1) UNRELEASED; urgency=low
>> +
>> +  * Add python3 package / module.
>> +
>> + -- Dmitrijs Ledkovs   Mon, 25 Feb 2013 18:15:57 
>> +
>> +
>>  pyflakes (0.6.1-1~exp1) experimental; urgency=low
>>
>>* New upstream release:
>>
>> Modified: packages/pyflakes/trunk/debian/control
>> ===
>> --- packages/pyflakes/trunk/debian/control  2013-02-25 14:11:44 UTC (rev 
>> 9455)
>> +++ packages/pyflakes/trunk/debian/control  2013-02-25 18:20:53 UTC (rev 
>> 9456)
>> @@ -3,8 +3,10 @@
>>  Priority: optional
>>  Maintainer: Python Applications Packaging Team 
>> 
>>  Uploaders: Tristan Seligmann , Varun Hiremath 
>> , Sandro Tosi 
>> -Build-Depends: debhelper (>= 9), python
>> +#Needs python3.3 to run unittests, but can be executed / used with lower 
>> py3.x
>> +Build-Depends: debhelper (>= 9), python, python3, python3 (>= 3.3) | 
>> python3.3
>>  XS-Python-Version: >= 2.6
>> +X-Python3-Version: >= 3.2
>>  Standards-Version: 3.9.4
>>  Homepage: https://launchpad.net/pyflakes
>>  Vcs-Svn: svn://anonscm.debian.org/python-apps/packages/pyflakes/trunk/
>> @@ -20,3 +22,14 @@
>>   .
>>   Unlike PyLint, Pyflakes checks only for logical errors in programs;
>>   it does not perform any checks on style.
>> +
>> +Package: py3flakes
>> +Architecture: all
>> +Depends: ${python3:Depends}, ${misc:Depends}
>> +Description: passive checker of Python 3 programs
>> + Pyflakes is program to analyze Python 3 programs and detect various
>> + errors. It works by parsing the source file, not importing it, so it
>> + is safe to use on modules with side effects. It's also much faster.
>> + .
>> + Unlike PyLint, Pyflakes checks only for logical errors in programs;
>> + it does not perform any checks on style.
>>
>> Deleted: packages/pyflakes/trunk/debian/manpages
>> ===
>> --- packages/pyflakes/trunk/debian/manpages 2013-02-25 14:11:44 UTC (rev 
>> 9455)
>> +++ packages/pyflakes/trunk/debian/manpages 2013-02-25 18:20:53 UTC (rev 
>> 9456)
>> @@ -1 +0,0 @@
>> -debian/pyflakes.1
>>
>> Modified: packages/pyflakes/trunk/debian/patches/series
>> ===
>> --- packages/pyflakes/trunk/debian/patches/series   2013-02-25 14:11:44 
>

Re: [Python-apps-commits] r9456 - in packages/pyflakes/trunk/debian (7 files)

[Dmitrijs Ledkovs]

On 25 February 2013 20:29, Sandro Tosi  wrote:
> On Mon, Feb 25, 2013 at 8:15 PM, Dmitrijs Ledkovs  wrote:
>> On 25 February 2013 19:03, Sandro Tosi  wrote:
>>> hey, can you stop committing huge changes without asking to uploaders
>>> first? I've already contacted you when you un-coordinately upload
>>> pyflakes to experimental, ans you hadn't reply - it's time to give it
>>> a stop now
>>>
>>
>> I'm sorry for missing your previous email, due to a filtering mistake
>> on my side.
>>
>> My understanding was that package has Debian Python Team set as
>> maintainer, such that improvements and co-maintainership is welcomed.
>
> and they are, but switching python helper or introducing a new package
> are huge changes enough to require a consultation with the people that
> are responsible for the package (the uploaders), which didn't happen.
>

In my view they aren't, since -support is deprecated in the team and
many pyflakes reverse-build-dependencies are being ported to python3.
But point taken.
I'm not sure I agree with consultation "who are responsible for the
package" in the context of python-team & uploaders field usage as done
in pyflakes.
But I am fine with your interpretation, I shall consult you from now
on, when I notice you in the maintainer/uploaders/who-uploads fields.


>> Newer packages in experimental require/need/want pyflakes support
>> specifically python3 support.
>
> explicit is better than implicit: file a bug against pyflakes,
> explaining why you need a new package and what's the tool requiring it
> - that's what I'd expected.
>

ack.

>> Do you disagree with proposed changes? If yes, please comment and
>> revert relevant pieces.
>
> I'm disagreeing with the *way* you're doing such changes.
>

ok. Thanks for explaining it as well.

>> Or is this just a concern over my lack of courtesy? If you feel the
>> need to ack every commit of pyflakes, you should consider moving
>> python team to uploads and setting yourself as maintainer and/or
>> removing the package from the team all together. In either of those
>> cases, I typically file wishlist bugs with a patch attached.
>
> see above: team maintenance (even with team set to maintainer) doesn't
> mean you can do whatever changes you see fit for the moment (and them
> maybe disappear because you lost interest). small changes doesn't
> require any ack from my side; adding new bin packages or changing
> helper do.
>

Ok. I do wonder where the line of small vs not-so-small changes lies,
but I guess it will often be different on per-package specific
factors/basis.
Point taken.

Regards,

Dmitrijs.


-- 
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/canbhluhhathkcsosrrz0pstzhan_f2osn6y1p7tnc86fkhm...@mail.gmail.com

Re: About canonical Vcs fields

[Dmitrijs Ledkovs]

On 14 March 2013 13:56, Dmitry Shachnev  wrote:
> Hi,
>
> We discussed new lintian vcs-field-not-canonical check in IRC last week,
> which affects *lots* of packages in our SVN (see [¹]). Now people are
> recommended to use `svn://anonscm.debian.org/*` URIs instead of
> `svn://svn.debian.org/*`, but it seems that it's not what most packages
> use at the moment.
>
> So let's do a quick poll:
>
> [1a] I used anonscm.debian.org, and like it.
> [1b] I used svn.debian.org, but like the new URIs and will switch.
>
> [2a] I used svn.debian.org, don't like the new URIs but I don't mind 
> switching.
> [2b] I used svn.debian.org, and will continue to use it, lintian should allow 
> that.
> [2c] I used anonscm.debian.org, but don't like it.
>
> (I hope I've covered all options, let me know if there is something not
> listed above. If you had different packages that used different URIs,
> vote for the variant that applies to the biggest part of your packages.)

Some technical rational behind switching to annonscm:
"""
The machine hosting alioth.debian.org is running on wagner.debian.org.
VCSs are no longer on wagner since the migration which took place
during 2011, vasks.debian.org is now hosting svn.debian.org,
arch.debian.org, bzr.debian.org, darcs.debian.org, git.debian.org, and
hg.debian.org. Those services are tightly related to Alioth since all
the user accounts and the groups are taken from FusionForge database.
This means that you can only create VCS repositories for existing
alioth projects and that any member of that project will have access
to the corresponding public repository.
"""
So it was nice when all of them pointed to alioth, now all $vcs are on
vasks and thus have a new / different ssh host key.
So it's nice to change hostname for all VCS fields to point to
something that internally resolves to vasks, and at the same time not
expose the internal host name.
anonscm is as good as any to serve this purpose.

Regards,

Dmitrijs.


--
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/canbhluikpo3hpepqtzpgfuce+bpwweqwpeqxzmfr3vuvjd8...@mail.gmail.com

Re: About canonical Vcs fields

[Dmitrijs Ledkovs]

On 23 March 2013 12:37, Jakub Wilk  wrote:
> * Dmitry Shachnev , 2013-03-23, 15:51:
>
>>> I use svn.d.o everywhere, I don't like the new ones. However, the thing I
>>> don't like much more is inconsistency: some packages use svn.d.o, some
>>> anonscm.d.o, and some mixture of the two... Ugh. I don't mind switching if
>>> we switch everything at once. I'm happy to make the mass-commit if there's
>>> consensus that this is the right to do.
>>
>> I don't have anything against a mass-commit, it looks like others don't as
>> well. And Dmitrijs provided a good technical rationale... so please do it :)
>
>
> Okay. Unless I hear objections, I'll do mass-commit to switch to anonscm.d.o
> in ~2 weeks.
>

Can you do such commit simply after wheezy is out the door?

Regards,

Dmitrijs.


-- 
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/canbhluiiddtubaaukrznmqsksxqvzrbgxnbayr2z_8byfl5...@mail.gmail.com

Re: Accepted python-defaults 2.7.3-5 (source all)

[Dmitrijs Ledkovs]

On 6 May 2013 00:29, Sandro Tosi  wrote:
> Hello,
> has this been discussed *and* agreed on? I can only see Luca's mail
> for python plans, but no ack from other "members of the debian python
> board" nor the ACK from RT.
>

Python2.6 security support ends in October 2013 upstream. Which is
well ahead of jessie freeze & release. From security point of view
alone, it would be unwise to ship python2.6 in jessie. Which imho is
serious enough reason to remove python2.6 given its potential high
exposure when used by web-frameworks.

Regards,

Dmitrijs.



> On Mon, May 6, 2013 at 3:18 AM, Matthias Klose  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Format: 1.8
>> Date: Mon, 06 May 2013 02:48:48 +0200
>> Source: python-defaults
>> Binary: python python-minimal python-examples python-dev idle python-doc 
>> python-dbg python-all python-all-dev python-all-dbg
>> Architecture: source all
>> Version: 2.7.3-5
>> Distribution: unstable
>> Urgency: low
>> Maintainer: Matthias Klose 
>> Changed-By: Matthias Klose 
>> Description:
>>  idle   - IDE for Python using Tkinter (default version)
>>  python - interactive high-level object-oriented language (default 
>> version)
>>  python-all - package depending on all supported Python runtime versions
>>  python-all-dbg - package depending on all supported Python debugging 
>> packages
>>  python-all-dev - package depending on all supported Python development 
>> packages
>>  python-dbg - debug build of the Python Interpreter (version 2.7)
>>  python-dev - header files and a static library for Python (default)
>>  python-doc - documentation for the high-level object-oriented language 
>> Python
>>  python-examples - examples for the Python language (default version)
>>  python-minimal - minimal subset of the Python language (default version)
>> Changes:
>>  python-defaults (2.7.3-5) unstable; urgency=low
>>  .
>>* Drop Python 2.6 as a supported Python version.
>> Checksums-Sha1:
>>  315dc450ead64db62a2fa12ad33b47274c995904 1560 python-defaults_2.7.3-5.dsc
>>  328d99a7291bb06fc6e34d82d2c6b284ae9dacaa 164899 
>> python-defaults_2.7.3-5.tar.gz
>>  a41aa886f6e511400424c73c8eb620e2b981d83a 184016 python_2.7.3-5_all.deb
>>  6a89b342c56926c9a88a9f674d8ff2cb67a142ba 41796 
>> python-minimal_2.7.3-5_all.deb
>>  48f7d67b1692a6b9fbfa56417a56c587c7cf85fe 850 python-examples_2.7.3-5_all.deb
>>  af3227891f517dcc595c71f8c76dd9cb2e086f17 908 python-dev_2.7.3-5_all.deb
>>  21b2969b35907c50d49465553c327d37fec6513f 3032 idle_2.7.3-5_all.deb
>>  2132985c086355f0beec97ef561335e3fc32338a 22738 python-doc_2.7.3-5_all.deb
>>  aa637dab2b14a02f83c29a77aa4a98fa314f3d0f 1008 python-dbg_2.7.3-5_all.deb
>>  725d890be4a767c02fd9466765a3c8493ba1a8c4 856 python-all_2.7.3-5_all.deb
>>  93869e7bbe3d15ab2ed3e2dd546fd1f05ec5e73a 874 python-all-dev_2.7.3-5_all.deb
>>  e46b3d62aa365e95a957c49add92252b154cf2aa 882 python-all-dbg_2.7.3-5_all.deb
>> Checksums-Sha256:
>>  4cc77363730638924075a9ec096f8870c6a67fb36bd6b12fd1e6c669b9055e8e 1560 
>> python-defaults_2.7.3-5.dsc
>>  82a2a99e9a81b8552f23665f305b353702d5d854803d497842a6b1f0b0ff 164899 
>> python-defaults_2.7.3-5.tar.gz
>>  3e7a417705fa203a9629e5bbd3893b2506e79ef3a2463a99e338380f0188d096 184016 
>> python_2.7.3-5_all.deb
>>  b057061a2d2d8281b43836ae56e0ee2e86b25d1236d1aed6299760e1d06c713e 41796 
>> python-minimal_2.7.3-5_all.deb
>>  c9324ca4cb0ed964e8b273f0d81bf3f5a29be71539e75ff8f62d2daba8f23995 850 
>> python-examples_2.7.3-5_all.deb
>>  74b58147b451b1bc278dbd8cdcb12294fa5381975e24ae92a87a9933150d8b8a 908 
>> python-dev_2.7.3-5_all.deb
>>  db41c1e2983d79df8187c3a1ffdd2c4ba22bbf7d90e45e2bdb0f3b62c01611fa 3032 
>> idle_2.7.3-5_all.deb
>>  090f564a8ae8cdcb8b1d5e59dc766237a2a124a9e29a506c2c78f1075a357e07 22738 
>> python-doc_2.7.3-5_all.deb
>>  51d56f09fb38920e1066c883fdc013facd069da5ac2172b5b5302ad305189ea9 1008 
>> python-dbg_2.7.3-5_all.deb
>>  09e0831f1c5e8ef3d13699003614df3028c18853cb92751982843dfdeba32756 856 
>> python-all_2.7.3-5_all.deb
>>  43984b78bc44f82fdf3c4554c5d0bd77b22e171a2ddfdfe8f161424a052d33a7 874 
>> python-all-dev_2.7.3-5_all.deb
>>  b43eeca70ed21769bdc478cb26c7172cb1c4806b96e60f56cbe3e481529101b5 882 
>> python-all-dbg_2.7.3-5_all.deb
>> Files:
>>  ea09587c19d1fc46f1ee21313d1985d4 1560 python optional 
>> python-defaults_2.7.3-5.dsc
>>  cde37a578130113b6404de0dd4ee228a 164899 python optional 
>> python-defaults_2.7.3-5.tar.gz
>>  af727799182693133343afeef1e17800 184016 python standard 
>> python_2.7.3-5_all.deb
>>  4dd3d659dbd2f7705f0aa10f34fdd350 41796 python standard 
>> python-minimal_2.7.3-5_all.deb
>>  4404958df2028d7e12f463a17391f6ee 850 python optional 
>> python-examples_2.7.3-5_all.deb
>>  da57f5461bf1e2c1338e3ebbb971888b 908 python optional 
>> python-dev_2.7.3-5_all.deb
>>  96d8a24c4590b15681a0ab5c236cb648 3032 python optional idle_2.7.3-5_all.deb
>>  d098b041656927b689a51b5bd567dc11 22738 doc optional 
>> python-doc_2.7.3-5_all.deb
>>  7e5d66559b7566079f485a085c03cd85 1008 debug extra python-db

Re: pyflakes and Python 3 scripts (was Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz)

[Dmitrijs Ledkovs]

On 24 May 2013 20:40, Barry Warsaw  wrote:
> On May 24, 2013, at 02:55 PM, Barry Warsaw wrote:
>
> py3flakes - What I don't like about that is that it's harder to locate(1).
>

I like pyflakes3, but better yet I'd prefer:
python3 -m flakes

similar to how compileall / unittest / et al work.

Regards,

Dmitrijs.


-- 
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/canbhluh-ejci6vrcxafbgrjkqvmo0+9zwd+knk+53aggbxf...@mail.gmail.com

Re: python3.3 status

[Dmitrijs Ledkovs]

On 13 June 2013 07:01, Scott Kitterman  wrote:
> On Wednesday, June 12, 2013 03:13:38 PM Scott Kitterman wrote:
>> On Wednesday, June 12, 2013 12:48:45 AM Scott Kitterman wrote:
>> > On Thursday, June 06, 2013 12:46:05 PM Scott Kitterman wrote:
>> More updates and added all the "unknown" packages from the transition
>> tracker. Items marked as fixed in the last update have been removed.
>>
>> > > On Thursday, May 23, 2013 06:19:06 PM Scott Kitterman wrote:
>> > > > I've been working on this a bit ...
>> > > >
>> > > > On Tuesday, May 07, 2013 02:01:26 PM Jakub Wilk wrote:
>> > > > > python3-defaults maintainer(s?) decided to make python3.3 a
>> > > > > supported
>> > > > > version without prior notice. Yay. Now we have dozens of packages
>> > > > > failing to build:
>
> boost1.49 FTBFS TODO (could not find an open bug) - I plan to ignore this
> this and wait until the boost1.53 transition starts and we can not care.
>

boost1.49 fixed in the 1.49.0-4 upload.

Regards,

Dmitrijs.


-- 
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/CANBHLUi0rvVWs60=D_Pya-NxYczsh2AV=jm1x=1yexcub2-...@mail.gmail.com

Re: dh-python in unstable

[Dmitrijs Ledkovs]

On 2 August 2013 14:15, Piotr Ożarowski  wrote:
> dh-python is already in unstable \o/
>
> To build/install python3-foo or pypy-foo binary packages,
> you can use this in debian/rules:
>
> %:
> dh $@ --with python2,python3,pypy --buildsystem=pybuild
>

Shouldn't it be soon.

> dh $@ --with python2,python3,pypy,pypy3 --buildsystem=pybuild

pypy published a release with python3 support

in which case, can pypy2 become an alias for pypy to at least match
python2, python3 ?

Regards,

Dmitrijs.


--
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/CANBHLUgx6Y8UZ2hORFbqq7pv5GzppSWs0FfHNtEDKu=vzr2...@mail.gmail.com

Re: Source package name suggestion?

[Dmitrijs Ledkovs]

On 22 August 2013 16:25, Barry Warsaw  wrote:
> I plan to file an ITP to package the 'q' library:
>
> https://pypi.python.org/pypi/q/2.4
>
> 'q' seems like a terrible source package name, so I'll probably pick
> 'python-q' as the spn.  Obviously we'll have python-q and python3-q[*] binary
> packages.  I just wanted to see if anybody has strong opinions either way.
>
> -Barry
>
> [*] q 2.4 doesn't support Python 3 but there's an upstream issue/pull request
> that adds it and wfm.

I bet it's unrelated to QQ (largest IM network in the world, unless
skype has caught up after merging MSN).

Regards,

Dmitrijs.


-- 
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/canbhluhsm81x0nge4pq4_+osqf3h4nrlnmubbu48hykrm53...@mail.gmail.com

Re: dh-python in unstable

[Dmitrijs Ledkovs]

On 28 August 2013 21:15, Barry Warsaw  wrote:
> On Aug 02, 2013, at 05:42 PM, Piotr Ożarowski wrote:
>
>>[Barry Warsaw, 2013-08-02]
>>> On Aug 02, 2013, at 03:15 PM, Piotr Ożarowski wrote:
>>> >export PYBUILD_DESTDIR_python2=debian/python-foo/
>>> >export PYBUILD_DESTDIR_python2-dbg=debian/python-foo-dbg/
>>> >export PYBUILD_DESTDIR_python3=debian/python3-foo/
>>> >export PYBUILD_DESTDIR_python3-dbg=debian/python3-foo-dbg/
>>> >export PYBUILD_DESTDIR_pypy=debian/pypy-foo/
>>>
>>> I wonder if it wouldn't be possible to calculate default values for all of
>>> these.  E.g. if you had:
>>>
>>> export PYBUILD_NAME=foo
>>>
>>> I think the rest could be pretty much figured out, at least for the common
>>> cases.  Is that worth it?
>>
>>good idea, I'll add --name and PYBUILD_NAME
>
> I'm wondering if this is (supposed to be) working yet (in
> dh-python 1.20130819-1)?
>
> If you look at my nose2 package in svn, I tried to do this:
>
> export PYBUILD_NAME=nose2
>
> but it didn't seem to calculate the other variables automatically, and the
> build did not put things in the right place.  By adding these:
>
> export PYBUILD_DESTDIR_python2=debian/python-nose2
> export PYBUILD_DESTDIR_python3=debian/python3-nose2
>

what caught me off-guard that above paths are relative dh_auto_*
"--sourcedirectory" and are not relative top-level package src dir,
aka $(CURDIR).
I happen to have a "normal" package which has a distutils python app
in a subdir that I need to build.

Is that a bug or a feature? Seems inconsistent from the rest of paths
specified within debhelper.

Regards,

Dmitrijs.


--
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/canbhlujq43dzs3ybtbnpwisvuvvp-lzrp+oyfwqaf0rn42c...@mail.gmail.com

Re: dh-python in unstable

[Dmitrijs Ledkovs]

On 2 August 2013 14:15, Piotr Ożarowski  wrote:
> dh-python is already in unstable \o/
>
> To build/install python3-foo or pypy-foo binary packages,
> you can use this in debian/rules:
>
> %:
> dh $@ --with python2,python3,pypy --buildsystem=pybuild
>
> or if you don't want to play with .install files:
>
> export PYBUILD_DESTDIR_python2=debian/python-foo/
> export PYBUILD_DESTDIR_python2-dbg=debian/python-foo-dbg/
> export PYBUILD_DESTDIR_python3=debian/python3-foo/
> export PYBUILD_DESTDIR_python3-dbg=debian/python3-foo-dbg/
> export PYBUILD_DESTDIR_pypy=debian/pypy-foo/
>
> %:
> dh $@ --with python2,python3,pypy --buildsystem=pybuild
>
> See pybuild(1) and dh_pypy(1) for more info.
> Note that adding dh-python to Build-Depends enables multiarch support in 
> dh_python2

There is package that needs sources to be processed with 2to3, before
doing the python3 build. So far I have failed to build the package
properly with pybuild.
I've tried setting PYBUILD_D_python3= to directory with processed
source files, but that resulted in python3 unit-tests still running
against "normal" python2 sources.
Setting PYBUILD_BEFORE_BUILD_python3 to process the sources in-tree,
resulted instead python2 unit-tests running against python3 code which
fails.
Is there an example of using pybuild with 2to3 style build?

Package is paste.

Regards,

Dmitrijs.


--
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/CANBHLUjy=gF9X6MJigs5AH5-b+wjwL=BpFdUyWn=qxtsoot...@mail.gmail.com

Re: Reverting switch to dh-python for pyflakes

[Dmitrijs Ledkovs]

Hello,

On 21 September 2013 05:02, Thomas Goirand  wrote:
> Hi,
>
> I'm having issues with backporting pyflakes 0.7.3-1 to Ubuntu precise.
> It would help a lot if you reverted your switch to dh-python. Do you
> think that's possible?
>

No, I will not revert that. Instead dh-python should be backported
into precise-backports, if that hasn't been done yet. Similarly how
it's already been backported to stable-backports.

Also note that pyflakes is using/building python3 modules as well. Not
sure if pyflakes support the precise's python3.

Regards,

Dmitrijs.


-- 
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/canbhlug1vff4e1yx3pz_uqnb6qhvkqodocnmno0mb5ccdbv...@mail.gmail.com

Re: Will rtupdate be used for python 2 --> python 3 transition?

[Dmitrijs Ledkovs]

On 29 October 2013 02:22, Steve M. Robbins  wrote:
> Hello,
>
> The Debian Python Policy documents [1] the rtupdate script for dealing with
> default runtime changes.  Is this documentation still valid?  Will rtupdate be
> used when the default runtime changes to python 3 or later?
>

python3.X series and python2.X series are two distinct languages
(incompatible API and ABI changes), and it has been decided to keep
both alive as independent implementations.
thus "/usr/bin/python" will always point to a python2.X
implementation, the last one ever of which is python2.7.

However, "/usr/bin/python3" will continue to be updated, and will be
migrating in debian (e.g. 3.1 -> 3.2, 3.2 -> 3.3, and etc).
.rtupdate file location for python3 is /usr/share/python3/runtime.d

ps. ... apart from Arch who decided to point "python" to a python3.x
implementation, which is widely agreed as being wrong. And Python
upstream essentially veto doing so -
http://www.python.org/dev/peps/pep-0394/

Regards,

Dmitrijs.


-- 
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/CANBHLUiEzygwknQvifxhe4a29aSgOSvag0=qodjrfhu1d3t...@mail.gmail.com

Re: debian/rules for packages using Cython

[Dmitrijs Ledkovs]

On 12 November 2013 21:56, Tim Michelsen  wrote:
 multiple other packages? I recommend pybuild for sanity.
>>> OK, I followed that style guie but still get failures in the build:
>>>
>>>  dpkg-source -i -I --before-build recipe-1.0.1~ppa7~revno-{revno}
>>
>> oh, paths with "{foo}" will not work, sorry (will be fixed in next
>> dh-python upload). I bet you wanted to replace "{revno}" with revision
>> number, though.
> Yes, but usually, this should be the task of bzr dailydeb.
>
> For instance, here it works without troubles:
> https://code.launchpad.net/~pythonxy/+recipe/pandas-daily-current
>

This one is not use pybuild at clean, but rather python_distutils

"dh clean --buildsystem=python_distutils"

Regards,

Dmitrijs.


-- 
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/canbhluibeanafbnkkx6kpj1wypwlz+u51oz5gjhhkjwid3f...@mail.gmail.com

Re: debian/rules for packages using Cython

[Dmitrijs Ledkovs]

On 12 November 2013 22:54, Tim Michelsen  wrote:
>> This one is not use pybuild at clean, but rather python_distutils
>>
>> "dh clean --buildsystem=python_distutils"
> OK, but where can I find an example on how to configure the
> corresponding pybuild-based rule correctly?
>
> Sorry, I am lost here.
>
> And this packaging is full of style rules but no trouble shooting guide!

no, launchpad recipes are shooting you =)

when launchpad prepares the package it clones it into a directory
which has "{}" in the path, and pybuild chokes on paths with "{}" in
it, as Piotr just explained.

Either don't use pybuild at clean stage with launchpad recipes, or
don't use launchpad repices but rather generate source package locally
and upload it into ppa with dput.

Regards,

Dmitrijs.


-- 
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/CANBHLUiCL7RWPAfLW33Nw9=a0ur1v0_6zdd8gjdc9+jfzrr...@mail.gmail.com

Re: debian/rules for packages using Cython

[Dmitrijs Ledkovs]

On 13 November 2013 19:42, Tim Michelsen  wrote:
>> Either don't use pybuild at clean stage with launchpad recipes,
> How do I disable pybuild cleaning?
>

Please address your packaging questions to mailing list, either where
this thread started.
Or on debian mentors.

If one is using dh(1), one should read how it works at dh(1)
It accurately describes how that works, and how to override specific targets.

pybuild, is simply implementation system for dh_auto_* based commands.

How in general those work, see individual manpages for those, and
debhelper(7) manpage for common build system options.

Regards,

Dmitrijs.


-- 
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/canbhluhnt0utcjil_h3qeuv5doj4w3lpl9j7wrmk7rw_ilw...@mail.gmail.com

Re: C API include files

[Dmitrijs Ledkovs]

Heya,

On 6 December 2013 09:49, Olе Streicher  wrote:
> Hi,
>
> I am the maintainer of the astropy package [1], and there the topic was
> brought up what to do with header files for the C API [2]. The package
> provides a C API for one sub-package, astropy.wcs. In the moment, its
> header files are just installed under
>

On a similar note, I have libboost-python packages. It is not a python
extension itself, but rather it is a C++/boost api to write compiled
python extensions.
At the moment headers are the same thus are simply shipped in
/usr/include/ direct, the shared library however are on per-python
version/flavour. At the moment libboost_python.so referes to python2
and libboost_python3.so refers to python3 (default versions). This is
not ideal, as it doesn't leave room for -dbg python variants.
Therefore I was thinking to ship libboost_python.so (same name) in per
python versioned directories e.g.
/usr/lib/python3.3/config-3.3m-x86_64-linux-gnu/ I haven't checked if
that would that work out for typical boost-python extension modules.

Regards,

Dmitrijs.


--
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/CANBHLUhzb02K1100Aa7cL2quifMSBaJ0qwNC�5ok3twf-...@mail.gmail.com