Re: Backport of Python 3.6 for Debian Stretch?

2018-04-24 Thread Ludovic Gasc
2018-04-24 22:16 GMT+02:00 Matthew Woodcraft :

> Nguyễn Hồng Quân wrote:
>
>> I'm using Debian 9 on an ARM board (BeagleBone), for our IoT project.
>> We write an application which needs Python 3.6. But we are struggling with
>> packaging Python 3.6 as deb packages for Debian 9. We found the dsc file
>> for Debian buster. But there is difference in dependency hierarchy between
>> Stretch and Buster, so the found script produces *.deb files which are not
>> installable (due to missing dependencies).
>>
>
> You didn't say what dependency problem you're seeing. Is it python3.6
> depending on python3-distutils?
>
> If it is, you might try building the 3.6.5-3 source package from sid
> rather than the 3.6.5~rc1-1 package from buster, as that dependency has
> been removed there.
>
> That should give you a working Python 3.6, but without distutils which
> has recently been moved to the python3-stdlib-extensions package. If you
> need distutils you might try backporting that too.
>
>
Upgrade the python system from 3.5 to 3.6 might breaks some python system
libraries, no ?


Re: Backport of Python 3.6 for Debian Stretch?

2018-04-24 Thread Ludovic Gasc
Hi,

You can use pythonz, conda or pyenv to install the version of Python you
want without to disturb your system.

Regards.

--
Ludovic Gasc (GMLudo)

2018-04-24 8:58 GMT+02:00 Nguyễn Hồng Quân <ng.hong.q...@gmail.com>:

> I'm using Debian 9 on an ARM board (BeagleBone), for our IoT project.
> We write an application which needs Python 3.6. But we are struggling with
> packaging Python 3.6 as deb packages for Debian 9. We found the dsc file
> for Debian buster. But there is difference in dependency hierarchy between
> Stretch and Buster, so the found script produces *.deb files which are not
> installable (due to missing dependencies).
>
> Could you please provide an official packaging script for Python 3.6 and
> Debian 9?
>
> Thank you.
>
>
> --
> Quân
>
> Nguyễn Hồng Quân
> ☎ 093 9030 338
> Facebook: ng.hong.quan
>  quan.hoabinh.vn  agriconnect.vn
>
>


Re: How does team maintenace of python module works?

2013-02-20 Thread Ludovic Gasc
On Feb 20, 2013 11:57 PM, Dmitrijs Ledkovs x...@debian.org wrote:

 On 19 February 2013 23:49, Ludovic Gasc gml...@gmail.com wrote:
 
  On Feb 19, 2013 11:21 PM, Barry Warsaw ba...@python.org 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.

Ok, I'll use it this week-end.


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

 Regards,

 Dmitrijs.


Re: How does team maintenace of python module works?

2013-02-19 Thread Ludovic Gasc
On Feb 19, 2013 11:21 PM, Barry Warsaw ba...@python.org wrote:

 On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:

 After that it gets tricky, because we'd knock E out next, but the I'm not
 sure where the votes counted for E (Scott  Barry) should be reallocated.

 If it makes things easier, I am essentially sided with Piotr.  The fact
that I
 don't like git much is immaterial - I want a dvcs and don't have the time
to
 put into a bzr or hg migration.  I don't have time to put into a git
migration
 either, but it seems like you've got that covered. :)

 So I still think it comes down to, them that does the work gets to
decide, but
 there *is* work to do.  It's clear we don't want multiple vcses.  So I
think
 you have an opportunity to convince us by:

 * Doing a test migration and putting a test repo up so we can play with
it and
   see what it's like.

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.


 * Figure out whether full-source or debian/ only works better (maybe give
us
   both repos so we can play with them and discuss the pros and cons from
   actual working examples).

A tool that we could use in the future to maintain the packages with more
ease: https://honk.sigxcpu.org/piki/projects/git-buildpackage/


 * Put together draft policy and documentation to describe a workflow for
team
   maintenance of packages under git, including branching, pull requests,
code
   review, quilt integration, package building, etc.

 * Work out how upstreams that are under other vcses would work.

 * Provide a plan for a smooth flag day transition if/when consensus is
reached.

 * Gather feedback, fix problems, rinse and repeat.

 Once people are comfortable with how a git-based team repository would
work, I
 suspect you'll find more consensus to switch.

 Cheers,
 -Barry


 --
 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/20130219172048.66a75...@anarchist.wooz.org



Re: How does team maintenace of python module works?

2013-02-18 Thread Ludovic Gasc
On Feb 16, 2013 1:43 PM, Thomas Kluyver tho...@kluyver.me.uk wrote:

 On 16 February 2013 09:10, Thomas Goirand z...@debian.org wrote:

 It would be really stupid to only want to claim to be working as part
 of the team, that's not at all what I want to do. I'd like to be able to
 help when I can, and receive help when I need, which is the point of a
team.


 I agree there are reasonable reasons to want to maintain something in
git, and it's not ideal to exclude those packages from team maintainership
just because of the VCS question. Although, if it came to that, the team
would be happy to offer advice and assistance for Python packages that
aren't maintained by the team. We all want stuff to work smoothly, whether
or not it's our stuff.

 I suggest we take a poll - not as a binding decision, but to get an idea
of the level of support for different courses of action. You're free to
attach more weight to the votes of highly involved team members.

 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.)

I vote D, and I can handle the migration from SVN to Git, I've done this
several times for my work and WYMeditor.

Are you interested?


 So I would vote CDBA, in order of preference.

 Thanks,
 Thomas


Re: How does team maintenace of python module works?

2013-02-18 Thread Ludovic Gasc
On Mon, Feb 18, 2013 at 11:08 PM, Thomas Kluyver tho...@kluyver.me.ukwrote:

 On 18 February 2013 20:46, Ludovic Gasc gml...@gmail.com wrote:

 I vote D, and I can handle the migration from SVN to Git, I've done this
 several times for my work and WYMeditor.

 Are you interested?

 I'm interested personally, but the votes so far suggest there's no real
 will for any change - the only option with more than one first preference
 vote is the status quo.


I propose to make a poll on the Web (Doodle or other) and ask the question
in another thread, I'm not sure that each subscriber has read this long
thread.




 Thomas