Re: Respectfully request to join the debian python team
Hi Stefano, thanks for the advice, I'll definitely take a look into patching and orphaned packages. As far as mentoring how would I go about doing that? finding one that is. On Thu, Jan 21, 2021 at 12:15 PM Stefano Rivera wrote: > Hi PerRy (2021.01.21_07:39:50_+) > > I wanted to request to join the debian python team. In a previous email, > I > > shared that I have been using debian for a while now and at this point in > > time I want to contribute back to the project. One of my skills is > writing > > scripts in python, and I want to utilize and build upon this skill in > > contributing back to debian. > > Aside from a password reset, I'd recommend getting started by > contributing patches through the bug tracking system, or adopting some > orphaned packages, and getting some experience maintaining them. Ideally > finding some mentors to help you out, along the way. > > We don't generally give people who are brand new to contributing to the > project commit access to hundreds of packages. > > SR > > -- > Stefano Rivera > http://tumbleweed.org.za/ > +1 415 683 3272 > > -- *Perry Ryan Cruz Aganad*
Respectfully request to join the debian python team
My name is Perry, I wanted to request to join the debian python team. In a previous email, I shared that I have been using debian for a while now and at this point in time I want to contribute back to the project. One of my skills is writing scripts in python, and I want to utilize and build upon this skill in contributing back to debian. I have read, understand, and accept the debian python team policy. Salsa Login: username - bpm10 pw - Crazydiamond.246 -- *Perry Ryan Cruz Aganad*
Looking to help
Greetings everyone!, I have been using debian for a while now and I am a point where I want to help and start contributing to debian itself. I read the web page about contributing and I took away that I should just jump right in, and I specifically jumped here because I do know how write python scripts. I am new at this but I'm a quick learner so please let me know if I can help out in anyway, thanks!.
Re: Executable files part of library
Magnus Therning wrote: Interestingly enough distutils doesn't keep executable bits on libraries, and this causes lintian to complain: W: python-pyggy: script-not-executable ./usr/lib/python2.3/site-packages/pyggy/dfa.py N: N: This file starts with the #! sequence that marks interpreted scripts, N: but it is not executable. N: bug in lintian, it should not complain about interpreter library files in this way. I believe there is already a bug(s) on this. Ignore it.
Re: Maintaining Python 1.5
On Wednesday 11 September 2002 15:00, Matthias Klose wrote: Neil Schemenauer writes: Matthias Klose wrote: Moshe Zadka writes: I was wondering if you mind passing Python 1.5 maintainership to me. I do not mind passing the maintainership, but I do mind keeping it in unstable. I don't think it is up to individual Debian developers to decide what packages should be allowed in Debian. ??? Interisting. So I am allowed to package perl3, quichote-0.1 and marlais 0.5? If you wanted to and could make sure it did not break anything, why not. I could definately see something like this making sense in a corporate setting. A Debian devel may not be allowed to upgrade some of their boxes and it would be easier to use foo X.Y on all platforms than deal with the compatibility. This is also why it makes sense to keep python1.5 around. As Moshe points out python1.5 is still the python most RH users get and it is way too easy to let a 2.x ism into your code. Hell on a python list this morning I was reminded that a solution I proposed only works in 2.2.1+.
Re: Maintaining Python 1.5
On Tuesday 10 September 2002 15:09, Chris Lawrence wrote: On Sep 10, Matthias Klose wrote: Moshe Zadka writes: I was wondering if you mind passing Python 1.5 maintainership to me. I do not mind passing the maintainership, but I do mind keeping it in unstable. Debian is not a museum for old python versions. What hinders you to install the python1.5 packages from woody in unstable? apt tagging is your friend. Well, two problems I can see: 1. Woody will eventually go away to archive.debian.org land, not long after sarge is released. 2. There are woody Python packages that want libdb1, which disappears from libc6 in sid/sarge. I agree we shouldn't keep it around forever, but it seems like as long as people are using python1.5 with post-woody we should keep it. Chris Plus there are alreayy glibc changes in sid/sarge so people running woody are being forced to upgrade glibc or compile packages by hand. There is still a fair amount of software that has only been tested with 1.5 so it is not necessarily museum quality.
Re: Emacs in build-depends of python2.1
Converting a hack to another hack with no strong reason nor fun is not exactly what I dream of every night. So, I am not sure that such a conversion would be worth the time spent. If despite all of this you still want to tackle on this task and have some ELisp questions (I think it should be OK with Python ;-), feel free to ask me, but don't count on me to do this. Sorry. somebody to volunteer for a pythonic conversion of the docs? the real answer as was discussed would be to move the Python docs to a format designed for interchange (most likely docbook). texinfo simply is not meant for this. Coupling this work with a comprehensive list of undocumented modules, perhaps getting them documented along the way would really be a great idea. The question really boils down to whether the upstream want this to happen or not. Roughly 5 people and a month or two's work should cover it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emacs in build-depends of python2.1
On 26-Jun-2002 Florent Rougon wrote: Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: The problem is we now have a piece of a fairly common package using script(s) in a language few understand. So if you get hit by a bus someone WILL have to reverse engineer that script. This is the same Well, I guess you mean py2texi.el's upstream maintainer instead of you. Has someone had problems contacting him? Does his script often break? The home page, http://www.zamazal.org/software/python/py2texi/, is mentioned at the beginning of py2texi.el. hmm, sorry, was going on other people's comments here. I was not aware you inherited this from the upstream. Please allow me to eat my foot (-: These are the implementation quirks. Now: - is it the only .el file used in the whole Python build? - are you sure the locally-and-not-installed python binary would be able to use modules like re, StringIO, etc.? - does someone actually use these info files, which are not supported by upstream and may be incorrect: The result code is ugly and need not contain complete information from Python manuals. I apologize for my ignorance, especially ignorance to python.sty due to the difficult nature of such a conversion? I use the python info docs nearly every time I code in python and would miss them a lot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emacs in build-depends of python2.1
Converting a hack to another hack with no strong reason nor fun is not exactly what I dream of every night. So, I am not sure that such a conversion would be worth the time spent. If despite all of this you still want to tackle on this task and have some ELisp questions (I think it should be OK with Python ;-), feel free to ask me, but don't count on me to do this. Sorry. The problem is we now have a piece of a fairly common package using script(s) in a language few understand. So if you get hit by a bus someone WILL have to reverse engineer that script. This is the same reason I dislike build-essential requiring Haskell. It is a fine language but the number of people in Debian who speak it is probably about 20 or 30. In essential we have sh, sed and awk guaranteed. Just beyond that is perl and python. Then there is C(++). Once you move beyond these the chances of the typical developer being able to debug, help, or rewrite is small. elisp is even more specialized then just lisp. And yes it is annoying when you do 'apt-get --build python' to discover suddenly that emacs is going to be installed if for no other reasons than the build system just gained another 50+mb in size (some of us use chroots on smaller drives). I understand you not feeling the need is high to change now. But bear these thoughts in mind in the future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-jabber test pkg ready
making python-jabber2.{1,2} would let it, but is it the correct way?
if you want to support multiple python versions, yes. You could also make a
python-jabber package which depended on the newest python version you support.
That way a user can just use python-jabber and let the upgrades move him
forward.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
On 06-Apr-2002 Jérôme Marant wrote: Sean 'Shaleh' Perry [EMAIL PROTECTED] writes: http://people.debian.org/~jerome/python-4suite the source is 600 so we can not download it. My apologies. It is strange that scp copied them all 644 except from this one. Fixed now. Will get a few compilations in for you tomorrow. I presume the package is named 11.99 to allow for the 12 upgrade? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
4suite is obviously updating the python search path to add its modules, the modules should be added at the front of the list and not the end where they seem to be added. This really sucks. I don't have in mind any package that requires the removal of the old version in order to build. However, upstream said they don't care. we SHOULD be able to fix this ourselves, I just do not know enough about distutils yet to tackle it. It happened once on my system and I just removed the package directory, then unpacked it again (dpkg-cource -x package.dsc) and rebuild the package. I cannot explain why this happens. It looks like the building failure changed something. I tried that to no avail. Any ideas? PS: I hope they'll provide prerendered html documentation otherwise our autobuilders will suffer. the other choice is to render the html once and make a new tarball. Yes the orig.tar.gz will be slightly less pristine, but it will save the rest of Debian hours of time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
I put it at: http://people.debian.org/~jerome/python-4suite The package is now compatible with python-xml. Please test it. If you think that is is reliable enough, I'll upload it and will be able to close #128604, at last. Thanks in advance. Cheers, PS: I'm not sure about this, but it seems that the old version of the package must not be installed on the system in order to build the new package. Could someone try to build it and confirm? I have a nice, huge dual 1.7ghz 500MB RAM machine on loan currently. Will get in a few builds for you this weekend. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test new 4suite
On 05-Apr-2002 Jérôme Marant wrote: Hi, I've just built a preversion of the 4suite 0.12a2 snapshot. Building the package takes a huge amount of time (the whole documentation is processed with 4xslt, which is known as one of the slowest XSLT processors) and packaging becomes more and more painful with no real fine tuning of intall directories and tons of lintian warnings to fix. I put it at: http://people.debian.org/~jerome/python-4suite the source is 600 so we can not download it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#128531: tmda
On 20-Feb-2002 dman wrote: On Wed, Feb 20, 2002 at 07:57:52AM -0800, Sean 'Shaleh' Perry wrote: | | What do you have against giving the user optimizations? | | Absolutely nothing, but I don't see why this needs to be done outside of | the package management system. | | I fail to see why these files need to be known by dpkg? Many python modules | are forwards compatible, The bytecode files are version-specific even if the source code isn't. which was my point. To have multiple version support the object files must be made at install time.
Re: Bug#128531: tmda
They should be known by dpkg because they're part of the package. It's impossible to support more than just the currently installed versions anyway. Once a new version of python is added, the package will still need to be updated or at least reinstalled to compile the modules for the new version. Adam, that is the whole point of compileall.
Re: dummy packages and lintian
On 08-Feb-2002 Federico Di Gregorio wrote: hi, hi have python-psycopg be a fake package that depends on the right python-psycopg package (i provide psycopg packages for python 1.5, 2.1 and 2.2.) lintian give me an error saying that the package should contain at least the copyright file. given that the copyright is available because the package *depends* on a real package, should i include the copyright even in the dummy package, symlink the doc directory or file an override to lintian? the override will require adding a file to your package too. So I would go for either the symlink or simply ignoring the error.
Re: Suggestion of dh_purepython
On 10-Jan-2002 Bastian Kleineidam wrote: Hi Python folks, I have put together a dh_purepython debhelper script to help the installation of pure Python packages. Still missing: 1) All Python X.Y versions need to be preinstalled. What happens when you install an new Python version? Hmm, we have to register those pure python packages somehow and byte-compile them if we install a new pythonX.Y package. read all python* binaries from /usr/bin, loop through every one that has a version on the end, strip the version out and use it. for i in /usr/bin/python* do # if $i ends in a number # pyver = $i's version number # call /usr/lib/python$pyver/compileall.py done
Re: Python2.2 doesn't build on potato
On 15-Dec-2001 Carel Fellinger wrote: Hi, Today I tried the new Python2.2c1 to find that it doesn't build on potato. It works out of the box on my woody system, but fails on my potato setup:( The latest 2.2 that does build under potato is 2.2.a4 It seems to have to do with changes in the ssl libs. SSL has changed a lot since potato, you may end up backporting a libssl from woody.
RE: Package name question - pyada or python-pyada?
I have filed an ITP for pyAda which is an Ada wrapper to allow Python to be embedded and extended with Ada. Since pyada contains no python code I was going to name the package pyada instead of python-pyada, or am I wrong about the usage of 'python-' in a package name. pyAda is the well known name, I would use that.
RE: 4Suite in Debian ?
On 28-Feb-2001 Jérôme Marant wrote: Hi, Would you think great to have 4Suite (http://www.4suite.org) in Debian ? As 4DOM was included in Python-xml, we could simply remove it from 4Suite add a dependency instead. I looked into packaging it for narval. However, the version of xml it wants versus what is in Debian were conflicting at the time. I no longer have the time to work on this, so feel free.
Re: Dependencies on Python
none; both packages should depend on python|python2 I am just waiting till python2 packages stabilise to upload versions with correct dependencies. But, of course, the correct way would be to have virtual package python, provided by python1-base and python2-base it is my understanding that a) not all 1.5 is compatible with 2.x b) not all licenses of 1.5 are compatible with 2.x until this is fixed, the maintainer should not add the python2 depends until he has personally tested it.
