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