Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: bmarkus on July 12, 2010, 05:38:02 AM
-
Python 2.7 is just recently released as the main 2.x version. It shows that there is demand for 2.x and can't be omitted and replaced with 3.x
I have no problem with 2.6 as it is in the repo, but I think this would be good to migrate to 2.7 Last time such and action to 2.6 was smooth without any serious hassles.
Jason:
if you build 2.7 I'm ready to test and rebuild my extensions as last time.
For more info on 2.7 see
http://docs.python.org/dev/whatsnew/2.7.html
-
I will go for a build this week.
-
I will go for a build this week.
Fine :)
-
Apps that depend on just python itself can remain with a dependency on python2.6. But if we wish to update pygtk, pygobject, and pycairo against python2.7, then extensions that depend on them would have to be rebuilt. Here is a list of pygtk dependent apps, as well as apps that depend on them. I only recursed about 2 levels, so there may be more:
bleachbit-locale.tcz
catfish-locale.tcz
ccsm-locale.tcz
compiz-base.tcz
compiz-gnome.tcz
gedit-dev.tcz
gedit-locale.tcz
gnome-desktop-base.tcz
rabbitvcs-gedit.tcz
compiz-gnome.tcz
rabbitvcs-nautilus.tcz
gramps-locale.tcz
meld-locale.tcz
rabbitvcs.tcz
blueman.tcz
eog-plugins.tcz
gedit.tcz
gnome-desktop-base.tcz
rabbitvcs-gedit.tcz
rabbitvcs-locale.tcz
rabbitvcs-nautilus.tcz
rabbitvcs-thunar.tcz
totem-locale.tcz
wicd-locale.tcz
bleachbit.tcz
catfish.tcz
ccsm.tcz
comix.tcz
emesene.tcz
gedit.tcz
gnome-desktop-base.tcz
gramps.tcz
meld.tcz
nicotine.tcz
notify-python.tcz
postr.tcz
pygtksourceview.tcz
python-gtkspell.tcz
rabbitvcs.tcz
recordmydesktop-gtk.tcz
rhythmbox.tcz
thunarx-python.tcz
totem.tcz
tucan.tcz
tv-player.tcz
wicd.tcz
wifi-radar.tcz
zenmap.tcz
zeroinstall-injector.tcz
bleachbit-locale.tcz
catfish-locale.tcz
ccsm-locale.tcz
compiz-base.tcz
compiz-gnome.tcz
gedit-dev.tcz
gedit-locale.tcz
gnome-desktop-base.tcz
rabbitvcs-gedit.tcz
compiz-gnome.tcz
rabbitvcs-nautilus.tcz
gramps-locale.tcz
meld-locale.tcz
rabbitvcs.tcz
blueman.tcz
eog-plugins.tcz
gedit.tcz
gnome-desktop-base.tcz
rabbitvcs-gedit.tcz
rabbitvcs-locale.tcz
rabbitvcs-nautilus.tcz
rabbitvcs-thunar.tcz
totem-locale.tcz
wicd-locale.tcz
Though several are -locale extensions, there are 73 extensions, 50 of them are from Arslan and the rest are mostly from bmarkus, robc, Juanito, and JLS. Since I won't be the one doing the rebuilding to upgrade pygtk dependent apps to the just released python, I want to hear from the others who will be affected if it is felt needed to upgrade pygtk related stuff at this time.
-
Impressive list :)
I'm not sure that all applications depending on pygtk must be rebuilt as they are not depending on Python itself. My suggestion is to provide Python and a new pygtk for private review for extension makers and test.
-
do we really need to rebuild all of them except extensions which install files into lib/python2.6 ?
if so i can not rebuild all of them in short time, while i am planning updating gnome packages to 2.30.2 they will be rebuild slowly anyways. So just let them stay broken a while.
btw the list has duplicated lines
-
do we really need to rebuild all of them except extensions which install files into lib/python2.6 ?
if so i can not rebuild all of them in short time, while i am planning updating gnome packages to 2.30.2 they will be rebuild slowly anyways. So just let them stay broken a while.
btw the list has duplicated lines
I don't think so. Lets test it on few samples.
-
I was under the impression that pygtk had shared libs in /usr/local/lib, but apparently it does not but places it's files in /usr/local/lib/python2.x. That should mean leaving a pygtk version that is built against 2.6 in the repo, say named to pygtk-2.6, while the pygtk-dev extension that folks would build against would belong to the new pygtk, version 2.7. Kind of like with boost and icu.
I will be back on my main machine tomorrow and can build python and upload it for testing. Hopefully we can realize a sane upgrade cycle that does not require rebuilds.
-
Upon a close look, python dependent packages are of course bound to the version of python they are made against, as well as any packages built against those, like stuff dependent on pygtk, all has to be coordinated to that specific python version. That leaves about three approaches for a python upgrade. The first time involved few python dependent packages, so it was pretty simple. Now we have gnome and a whole lot of other stuff that uses python.
First approach is to rebuild everything to the new python version, and replace the existing python dependent packages and everything that depends on them. A lot of work, but would be a clean upgrade.
Second is to apply the relevant python version number to python dependent packages, like pygtk2.7, so to know which python they belong to. This would allow more than one version of python installed at once for those dependent packages, but would not be a clean system and would be confusing. As well as the fact that there would have to be a separate dependency stack for each python version in the repo supported by this. That would not result in a clean repo and would be confusing and there would be duplication even if it could be pulled off. Compiling in that environment would be frustrating to say the least.
Third would be the approach that Debian uses, and that is include support for both versions of python in python dependent apps like pygtk, with files in both /usr/local/lib/python2.6 and /usr/local/lib/python2.7 in the same extension. Debian can manage it, but I don't think that is either feasible or in the spirit of TC to include both versions in the same extension, with the possible errors and all that it would entail.
Though I have stated differently during the 1.x days, I dare to suggest that we forgo keeping with the latest python as they are released and instead time the update with a major TC upgrade, starting afresh with a new python extension in the case of an upgrade that requires a recompile, which won't be every time. Since a major TC version includes a toolchain and kernel upgrade, so many extensions are rebuilt to take advantage of that anyway. Though it would mean starting from scratch on a TC upgrade that a python upgrade is also decided, at least there is stability within each TC version's repo. This approach is the only remaining one for an openssl upgrade, and I think python qualifies to be in that same category given the scope of the repo.
Please share any thoughts or ideas.
-
Jason,
We can't keep support for different 2.x versions, there must be only one for sure. However it is not clear for me what is your advice, to keep 2.6 as it is now or move to 2.7 as in last paragraph, being just in a major release update of TC, even if it is a very end of the procedure.
For me both keeping 2.6 or moving to 2.7 is OK as related extensions maintained by me can be easily and safely recompiled using build scripts.
-
Though I have stated differently during the 1.x days, I dare to suggest that we forgo keeping with the latest python as they are released and instead time the update with a major TC upgrade, starting afresh with a new python extension in the case of an upgrade that requires a recompile, which won't be every time. Since a major TC version includes a toolchain and kernel upgrade, so many extensions are rebuilt to take advantage of that anyway. Though it would mean starting from scratch on a TC upgrade that a python upgrade is also decided, at least there is stability within each TC version's repo. This approach is the only remaining one for an openssl upgrade, and I think python qualifies to be in that same category given the scope of the repo.
Please share any thoughts or ideas.
If this ends up being the chosen route, then I think it would be a good idea to make 2.7 the Python 2.x supported in TC3.x
-
I already have a plan to upgrade gnome to 2.30.2 so most of them will be build anyways if you are going to upgrade python to 2.7 this is the best time
-
It seems that we are going to update to 2.7 right now :)
-
I just got up and am heading out the door to work now, but I will upload python2.7 when I get home.
I personally don't understand what realistic benefits justify this much trouble, but I won't stand in the way if moving to 2.7 now is what is desired by those who will be doing most of the rebuilding. If anyone has concerns, now is the time to raise them. But this will need to be done in a manner that does not break the repo. I will think about how we can go about this today.
-
I will be uploading python in a couple hours. Didn't mean to appear quite so negative my last post, posting just after waking up is not always best.
I think we can best do this by upgrading the extensions by dependency sets. In other words, when we build say pyusb against the new python, we make sure that all apps dependent on pyusb get rebuilt at the same time, or at least uploaded at the same time. That way the old python stays in the repo and apps that use it will still work until they get upgraded. Pygtk and the gnome stacks will be large, but other than that we should be able to migrate piece by piece.
I am of course open to other suggestions.
-
python-2.7.tcz and python-2.7-dev.tcz is uploaded. Let the fun begin.
I think that python should always have a version number, even the main one, given it's upgrade and compatibility nature.
-
When python-2.7.tcz installed from the repo on a clean TC 3.0rc1 files.tar.gz is not extracted, there are no python binary in /usr/local/bin
Restarting the system it works.
python-2.7.tcz itself doesn't work, there is an 'Invalid installation' error message. Installing python-2.7-dev.tcz it is fine, so separation must be fine tuned.
-
I think that python should always have a version number, even the main one, given it's upgrade and compatibility nature.
Sounds good. Adding Python 3.x fits to it too. However it may cause confusion for users not knowing which Python version to install at first. Not a big issue, as Python itself is not loaded directly but by other extensions, like pygtk.tcz but still...
-
Submitted pyusb.tcz It is not listed in any .dep files, so can go to the repo just now.
urwid.tcz also submitted which is used only by WICD.
Next step would be to rebuild the most commonly used pygtk and its python dependencies, pycairo, ...
-
I will repackage python tonight, I think I remember what caused the invalid installation thing, as well as I will deal differently with the files.
-
Anyway in this test period should I rebuild some of the extensions I mantain?
For sure. All :)
-
and how should I call them?
-
and how should I call them?
As we are going to update Python moving from 2.6 to 2.7 not keeping different versions paralel only one, keep current name, like pygtk.tcz just rebuild against Python 2.7
-
I will repackage python tonight, I think I remember what caused the invalid installation thing, as well as I will deal differently with the files.
python-2.7 tce.installed script is just missing flags: "-C /"
as a result files.tar.gz contents are being extracted to the current directory
-
I do not aee why files.tar.gz is needed, its content can be moved to the extension as other files.
-
when the extension is mounted the actual place of python is /tmp/tcloop/python*
as a result python thinks that its home is /tmp/tcloop/python*/usr/local/lib/python*
maybe a simple patch may fix this issue instead of copying python to root file system
-
Thanks for the info. In this case better to keep it and make sure it is extracted /added properly instead of patching code.
-
I was in a rush last night to package python and deal with the extensions that were backing up in the queue, so I made a couple of omissions. I will fix it tonight.
Though a patch could be done to make python use use /usr/local/.. instead of /tmp/tcloop/usr/local/.. as its path when invoked as a symlink in /usr/local, the files are small and can be just copied to the filesystem. I used a tar.gz so this extension would overwrite any /usr/local/bin/python symlink, but a force copy from somewhere else would work too.
With pygtk, pygobject, pycairo, since it has so many dependent apps, perhaps the Debian way of including both the files in /usr/local/lib/python2.6 and /usr/local/lib/python2.7 would be best for this one extension so the repo doesn't either get broken by the update, or there be the managing of numerous extensions put on hold waiting for them to all be built, and in the meantime hoping no one submits a package built against the current pygtk.
-
installing both python-2.6 and python-2.7 side by side but python executable conflicts
to me there are three ways to go
1) force rebuild of all python extensions
2) append python2.7 suffix to new python extensions temporarily such as:
pygtk-python2.7
pyqt-python2.7
3)rename python to python-2.6 and adjust all dep files
python --> python-2.6
and all other python dependent extensions
pygtk-python2.6
pyqt-python2.6
I think the second one is the easiest and less painful way
-
One reason I used a tar.gz of the binaries was to force an overwrite of an existing /usr/local/bin/python symlink. Since 2.7 will be our main python, it should claim the /usr/local/bin/python symlink and not be overwritten when python 2.6 is installed.
Python versions are of course designed to coexist with one another, the main one claiming the python symlink. There is actually a "make altinstall" option when installing python as the non-main version that will not disturb an existing /usr/local/bin/python symlink if it is present in the system.
As we will be doing this again one day in the near future, the more I think option 2 would be a way to go even more than including both python directories in each extension as one would not have to build for both versions at any time on any one package. Once a package is made, it remains and does not have to be repackaged in the future upon another python update, or even renamed. There will be some overlapping of the same files outside of /usr/local/lib/'python2.x/site-packages, but those are the same files and would be harmless. I think there may be a variable used to install those files in a manner that would not conflict with another build of the same package like pygtk. I will look more into it tonight, I may have misread.
To have to rebuild the entire python related part of the repo would be a huge undertaking, but if we use the numbering approach it can be done gradually, with the old python versions being slowly phased out.
-
Python-2.7.tcz has been fixed and uploaded.
-
pygtk-2.7, pygobject-2.7, pycairo-2.7, pyusb, and urwid uploaded.
-
weird file list are you sure they are compiled against python-2.7 ?
Edit: sorry i think i clicked on wrong link
-
I need at least these extensions build against python-2.7 please ?
sip
pyqt
dbus-python
python_libxml2
pyrex
pyorbit
-
I'll have a look at dbus-python, pyrex and pyorbit
-
dbus-python-2.7, pyorbit-2.7, pyrex-2.7 posted
-
After migrating applications to Python 2.7 we have to remove 2.7 from extenson names and go back pygtk.tcz pyrex.tcz etc. and keep Python 2.7 as the main Python version. Hopefully there will be no 2.8 released and 2.7 is really the last 2.x
-
:'( WICD is not compatible with Python 2.7 according to my recent tests. Google returns similar posts with other distros too.
It is already in the WICD bug tracking system.
-
So far, using the -2.7 suffix has been generally agreed upon for python related extensions built against version 2.7. But there are packages built against python 2.7 that have been submitted without the python suffix in the name.
To avoid conflict and confusion, let's please stay with using -2.7 in the extension name for python 2.7 related packages. I strongly prefer that we always use a python version suffix in python package names to ensure a smooth and seamless upgrade between python versions from here on without any mass renaming of extensions and their .dep file references that will break existing tce directories.
I am open to ideas on this subject, but I think we need to consider the future and remember we will surely be doing this again in the coming months or year. And a smooth and non-broken transition is paramount.
-
What is the current status of python extensions in need of building with python 2.7 ?
-
Based on checking which extensions contain "python2.6/site-packages" AND do not contain "python2.7/site-packages" AND for which extension_name-2.7 does not exist, I come up with:
bitbake.tcz.list
boost-dev.tcz.list
boost.tcz.list
bzr.tcz.list
dictclient.tcz.list
django-1.1.1.tcz.list
farsight2-dev.tcz.list
farsight2.tcz.list
feedparser.tcz.list
gammu.tcz.list
git.tcz.list
gnome-colors.tcz.list
gpsd-python.tcz.list
graphviz.tcz.list **
gtk-vnc-dev.tcz.list
gtk-vnc.tcz.list
libftdi-dev.tcz.list
libftdi.tcz.list
lilypond-2.12.2.tcz.list [python-2.4]
mercurial-1.2.1.tcz.list [python-2.5]
nicotine.tcz.list
oo2.tcz.list [python-2.3.4]
psyco.tcz.list
pybsddb-dev.tcz.list
pybsddb.tcz.list
pyogg-vorbis.tcz.list [python-2.5]
pyopenssl.tcz.list
PyPanel.tcz.list
pysqlite2.tcz.list
pysqlite.tcz.list
python_coherence.tcz.list
python-keybinder.tcz.list
python-xlib.tcz.list
recordmydesktop-gtk.tcz.list
rsvg.tcz.list
SQLAlchemy.tcz.list
supybot.tcz.list
telepathy-farsight-dev.tcz.list
telepathy-farsight.tcz.list
wicd.tcz.list
xcb-proto.tcz.list
xpyb-dev.tcz.list
xpyb.tcz.list
zenmap.tcz.list
zeroinstall-injector.tcz.list
zfs-fuse.tcz.list
I did not double-check every single extension, so there could be some mistakes in the above.
-
some notes about the list above:
* boost python is not available in boost.tcz (i wish it had), files in python2.6 directory belong to python.tcz and have no relation with boost
* gnome-colors is a set of icon themes (have some icons with name python)
* rsvg module for python 2.7 is available in gnome-python-desktop
* i will take care of gtk-vnc, telepathy-farsight (needs farsight2-2.7 first) , and maybe gpsd if last packager does not want to do it
* weird why vtemodule is not listed ?
-
There still a few extensions using python 2.6, and some like WICD will not work with python 2.7.
I am personally more concerned about our strategy than I am about how many extensions have been updated to 2.7. If we are happy with using the python version in the names of python related extensions, then there is no hurry to upgrade or rebuild. But having the python version number in the name and supporting 2 versions of python can make the repo a little more cluttered and perhaps confusing especially to newer users. If we want to be able to have python upgrades in between major TC releases, then it is really about the only way to go. Otherwise, I think that future python upgrades would need to only take place during a major TC version change if we are going to require current extensions be rebuilt with the goal of supporting only one version of python. There are advantages with either approach.
I just want to make sure we are all on the same page before we proceed further.
-
Juanito had mentioned earlier today, and Arslan mentioned earlier in the thread, that we could rename the python 2.6 related extensions with the 2.6 suffix, therefore freeing the new python stuff to be without a version number tacked on. Not the easiest way, but perhaps the more palatable for users and extension makers alike. One large renaming, and then the new python extension and its dependent extensions would not require the 2.x suffix. And when a new TC major version is released, the old python stuff with the version number is left behind in the old repo, while the new stuff gets carried over.
It is technically no different than just using a version number in the name of all python extensions, and would require a 'one time per update' mass renaming that using the version number would never require. But I am willing to go that route if it sounds more like what the community would like to do.
The more I ponder it, I think renaming the 2.6 stuff with the 2.6 suffix is probably a good idea anyway, at least to identify it as 2.6 related just as the 2.7 does for the 2.7. Perhaps letting 2.6 stuff remain without the version number is giving the impression that 2.6 is the main (latest) python version, as well as being confusing as to it's version.
-
Looking at what would need to be done to properly support 2 concurrent versions of python, I think that we do after all need to stick to one version of python in the repo. And upon major TC upgrades, it can then be discussed if python needs to be updated, and then we would keep to that one version for the duration of that major TC release.
What we can do now is to focus on updating and retiring the 2.6 stuff, keeping only what will not run on 2.7 and labeling it with the -2.6 name. Though in theory supporting 2 pythons could work, it would require further factoring out the python parts of extensions, and add more complexity to figuring dependencies and all. It is a level of complication that I am sure we agree we don't need.
I thought that supporting multiple python versions would allow a smooth upgrade process, but the more I look into what would need to be done to reduce file and extension conflict, I see that it is just digging a hole. I got is into that hole, and I will try to help get us out as best I can.
-
Looking at what would need to be done to properly support 2 concurrent versions of python, I think that we do after all need to stick to one version of python in the repo. And upon major TC upgrades, it can then be discussed if python needs to be updated, and then we would keep to that one version for the duration of that major TC release.
Agree to support one version of Python officially only and let user deal with the case when he need a different version.
I do not aware applications which requires definitely 2.7 while WICD doesn't work with 2.7 and according to discussion to the author we can't expect a fix in the near future. Also, 2.6 line is updated frequently (latest is 2.6.6) and works fine.
My proposal is to declare that Python 2.6.x is the only supported in current TC/MC and keep 2.6 up-to-date. 2.7, 2.5 and 3.x nice to have of cource but only for test for the challengers brave enough. In general, build applications against 2.6 except special cases.
BTW, this is de facto the current case, as python 2.6 is called python. SO it is basically just a policy change.
-
Since early in this thread, the idea was to migrate to python 2.7, which has progressed to the point there is no turning back. The issue is on the naming of python 2.7 related extensions, whether to continue to use the 2.7 suffix, as well as that of supporting 2.6 extensions as opposed to replacing them with 2.7 versions.
We really need to get on the same page concerning the python update, and all agree on a path to take. I want to hear from extension makers that package python stuff and either hear a consensus on the 2.7 naming and possible factoring of python modules in to separate extensions when necessary, or ideas of how to proceed. But as it is, I think I am forced to rename the python 2.6 stuff with the -2.6 name so that the 2.7 stuff either has the 2.7 suffix or not, and the 2.6 suffix is what distinguishes the 2.6 extensions.
-
There's perhaps a choice of whether to rename the extensions using python-2.6 or remove them if they have been replaced by a tested and working python-2.7 version.
If we're going to only change the python version when we change major versions of tc - eg tc-2.x to tc-3.x, I would suggest we can drop the *-2.7, if we might change more often that this, perhaps it's better to keep the *-2.7
-
I'm fine having 2.7 is the standard supported. The most importans is that Jason have to make the statement and publish guidlines on (re)naming Python components.
I will follow.
-
Since we are already doing the -2.7 naming, it is probably best to just stick with that and leave the 2.6 stuff alone. It so far as worked well, just needs to be universally followed at this point, and then with TC 4.0 we can then either move the 2.7 stuff over to the 4.x repo or decide to use a more recent release.
There is at least one extension, libproxy, that may need it's python stuff separated into a libproxy-python-2.7 extension for the 2.7 component, and maybe libproxy-python for the 2.6. We can deal with those cases as we see them.
So what I will do is check to make sure that 2.7 related stuff is named 2.7 when it comes in. And there are also a few extensions that have 2.7 stuff that will need to have the 2.7 suffix added to them.
-
Here are extensions that depend on things that are built with python-2.7 and python.tcz. May or may not cause an issue, but here is a list.
compiz-gnome.tcz.tree
pidgin-dev.tcz.tree
rhythmbox.tcz.tree
wicd-locale.tcz.tree
-
rhythmbox-2.7 has been posted a week or two now, so rhythmbox could be removed from the repo.
-
ok.
-
Upon looking at our present python situation, it appears that many of the python extensions have been rebuilt for 2.7 and have a 2.7 version available. Perhaps we could aim for the replacement and retirement of the python 2.6 related extensions to simplify things since we are already pretty far down the path.
-
Here are extensions that depend on things that are built with python-2.7 and python.tcz. May or may not cause an issue, but here is a list.
compiz-gnome.tcz.tree
pidgin-dev.tcz.tree
rhythmbox.tcz.tree
wicd-locale.tcz.tree
wicd-locale is just a set of locale files and has wicd.tcz as a dependency. wicd.tcz itself depends on Python-2.6 and doesn't work with Python-2.7
-
From bmarkus in the /usr/bin/python symlink thread:
Maybe I'm wrong, but for me python.tcz is the python extension while python-2.7 is the new till it will be renamed to python.tcz and the current pytho.tcz to python-2.6 to tcz.
I thought the general understanding is that python-2.7 is the current one to use and build against, while the 2.6 python is only to support existing extensions until they are replaced. But even this small symlink issue points out the confusion that is resulting from having 2 python versions while updating python stuff in the middle of a release.
Looking back, it would have been more clear if the 2.6 stuff would have been named with the 2.6 suffix before we even started building against 2.7. But then we still would have had the issue of the main python version not being python.tcz. And either way we have a mass renaming effort to deal with.
I know that wicd does not work with python-2.7, but aside from that I am about ready to say why don't we just remove all the 2.6 related extensions since most have been replaced with 2.7 versions. Then if there were any removed that did not yet have updated versions, they could just be built and submitted then. Obviously, that would only happen if the affected extension makers who are active agreed on it, or if some agreed but wanted time to replace stuff, then only after that time. But I could quit making the Tylenol stockholders happy with high share prices that are resulting from my purchases, and those of other extension makers, if we did go that route. I am ready for this python issue to reach a conclusion and be behind us, and I am sure I am not alone.
Removing the 2.6 stuff except for wicd and it's deps will require some rebuilding in the near future, which was planned anyway with updating python. Not removing or just renaming 2.6 stuff will still result in file conflict and confusion, sapping resources in time and energy that could be spent in moving forward.
The bulk of the python stuff is from bmarkus, robc, Kingdomcome, Arslan, Juanito, and JLS, and not necessarily in that order in terms of number of extensions. Here is a list I made a couple weeks ago, but should still be complete. I think these either need to be updated if not already, or removed or updated by someone else if the owner is no longer active. Most of the important ones have been updated by now. I am not asking which ones we want to remove, it is much more to the point to ask which ones you want to keep or would like to be allowed time to upgrade.
I will remove nothing without permission, and this is not a pattern for the next python upgrade, but rather just bailing us out of a potentially growing mess. I am open to other ideas, but at this point I think anything less than aiming for the removal of the old python stuff may just add to the issues we are seeing. Python 2.7 stuff then can be renamed back to not having the 2.7 suffix, and some are already named without it.
EDIT: wicd and it's deps will of course remain, perhaps with a 2.6 suffix, and they will only be a few extensions.
BeautifulSoup.tcz
Extension_by: Thomas Genty <tomlohave@gmail.com>
PyPanel.tcz
Extension_by: Kingdomcome
SQLAlchemy.tcz
Extension_by: Kingdomcome
avahi.tcz
Extension_by: juanito
bitbake.tcz
Extension_by: robc
blueman.tcz
Extension_by: juanito
boost.tcz
Extension_by: robc
bzr.tcz
Extension_by: Kingdomcome
dbus-python.tcz
Extension_by: juanito
dictclient.tcz
Extension_by: Kingdomcome
django-1.1.1.tcz
Extension_by: Althalus
farsight2-dev.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
farsight2.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
feedparser.tcz
Extension_by: Kingdomcome
gammu.tcz
Extension_by: bmarkus
git.tcz
Extension_by: juanito, jls_legalize, SvOlli
gpsd-python.tcz
Extension_by: Arslan S., T. Buctoo
gst-python.tcz
Extension_by: juanito, Arslan S.
gtk-vnc-dev.tcz
Extension_by: Arslan S.
gtk-vnc.tcz
Extension_by: Arslan S.
hplip.tcz
Extension_by: juanito
kaa-base.tcz
Extension_by: Thomas Genty <tomlohave@gmail.com>
kaa-display.tcz
Extension_by: Thomas Genty <tomlohave@gmail.com>
kaa-imlib2.tcz
Extension_by: Thomas Genty <tomlohave@gmail.com>
kaa-metadata.tcz
Extension_by: Thomas Genty <tomlohave@gmail.com>
libftdi-dev.tcz
Extension_by: robc
libftdi.tcz
Extension_by: robc
libgsf-gnome.tcz
Extension_by: juanito
libproxy.tcz
Extension_by: juanito
nicotine.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
notify-python.tcz
Extension_by: Arslan S.
pil.tcz
Extension_by: juanito
psyco.tcz
Extension_by: robc
pybsddb-dev.tcz
Extension_by: robc
pybsddb.tcz
Extension_by: robc
pycairo-dev.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
pycairo.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
pygame.tcz
Extension_by: Thomas Genty <tomlohave@gmail.com>
pygobject-dev.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
pygobject.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
pygtk-dev.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
pygtk.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
pylirc.tcz
Extension_by: Thomas Genty <tomlohave@gmail.com>
pyopenssl.tcz
Extension_by: Kingdomcome
pyorbit.tcz
Extension_by: juanito
pyqt.tcz
Extension_by: robc
pyrex.tcz
Extension_by: juanito
pyserial.tcz
Extension_by: juanito
pysqlite.tcz
Extension_by: Kingdomcome
pysqlite2.tcz
Extension_by: Kingdomcome
python-dev.tcz
Extension_by: Jason W
python-keybinder.tcz
Extension_by: blofsy
python-xlib.tcz
Extension_by: Kingdomcome
python.tcz
Extension_by: Jason W
python_coherence.tcz
Extension_by: juanito
python_configobj.tcz
Extension_by: juanito, Arslan S.
python_libxml2.tcz
Extension_by: juanito, Arslan S.
python_setuptools.tcz
Extension_by: juanito
python_twisted.tcz
Extension_by: juanito
python_zope.interface.tcz
Extension_by: juanito
pyusb.tcz
Extension_by: bmarkus
recordmydesktop-gtk.tcz
Extension_by: robc
rsvg.tcz
Extension_by: blofsy
sip.tcz
Extension_by: robc
supybot.tcz
Extension_by: Kingdomcome
telepathy-farsight-dev.tcz
Extension_by: Arslan S.
telepathy-farsight.tcz
Extension_by: Arslan S.
urwid.tcz
Extension_by: bmarkus
vtemodule.tcz
Extension_by: bmarkus
wicd.tcz
Extension_by: bmarkus
xcb-proto.tcz
Extension_by: robc
xpyb-dev.tcz
Extension_by: robc
xpyb.tcz
Extension_by: robc
zenmap.tcz
Extension_by: Key, juanito, Robert Schumann
zeroinstall-injector.tcz
Extension_by: jls_legalize (unsenepopiu at tin dot it)
zfs-fuse.tcz
Extension_by: Daniel Barnes
-
My proposal is to rename
python.tcz -> python-2.6.tcz
python-2.7 -> python-2.6
as well as related extensions, like pyusb, pyserial, pygtk, ...
It would make clear for everybodey that 2.7 is the officially supported vetsion. For those who are not aware of histry and details just looking for Python and would go for python.tcz it would install 2.7 by default.
-
I think that is a good start, I don't have time today and maybe not this week, but that can be the goal. Especially if we can also retire some of the 2.6 stuff, that would go a long way.
So for now a renaming to -2.6 for old python stuff, and the more we can eventually retire the simpler things will become.
-
I don't understand why meld should be called meld-2.6.
This program is a user program, with a gui and is not a dep of nothing.
-
It it is a dep of nothing, then I guess it could stay meld.
I guess that libraries and other stuff that are listed in dep files are really the ones that need version numbers, end use apps can stay without them.
Believe me, I will be happy when the version names of python stuff are not needed. Hopefully soon.
-
rabbitvcs depends on meld, i use rabbitvcs with gnome, and meld is working with python 2.7 for me ???
can you at least create meld for python 2.7 too please
-
I still think the best approach is to name the 2.6 stuff with the 2.6 suffix, to free the current python extensions from needing to be named 2.7. And for the eventual phasing out of 2.6 but for what is absolutely necessary to keep.
To help work towards having one python version in the repo, as we have obvioulsy by now seen the complications of supporting 2 python versions.
-
I'm ready to rename, adjust, ... my extensions as soon as renaming
python.tcz -> python-2.6.tcz
python-2.7.tcz -> python.tcz
is done.
-
Ok. I was starting sort of 'top down' with the apps that have no dependencies.
But I will next rename python.tcz to python-2.6.tcz, and python-2.7.tcz to python.tcz.
Of course, all affected dep files will need adjusting on each renaming of any extension, but I will take care of that as we go.
-
rabbitvcs depends on meld, i use rabbitvcs with gnome, and meld is working with python 2.7 for me ???
can you at least create meld for python 2.7 too please
meld with python 2.7 gives segfault to me
-
rabbitvcs depends on meld, i use rabbitvcs with gnome, and meld is working with python 2.7 for me ???
can you at least create meld for python 2.7 too please
meld with python 2.7 gives segfault to me
i just build meld 1.4.0 using your build script with pygtk-2.7 and it is working fine
maybe it is about new pygtk i haven't updated my local tce yet
-
rabbitvcs depends on meld, i use rabbitvcs with gnome, and meld is working with python 2.7 for me ???
can you at least create meld for python 2.7 too please
meld with python 2.7 gives segfault to me
i just build meld 1.4.0 using your build script with pygtk-2.7 and it is working fine
maybe it is about new pygtk i haven't updated my local tce yet
I tested with the new pygtk and I get segfaults
-
I renamed the python extensions as mentioned above, with affected dep files adjusted:
python.tcz (2.6) --->> python-2.6.tcz
python-dev.tcz (2.6) --->> python-2.6-dev.tcz
python-2.7.tcz --->> python.tcz
python-2.7-dev.tcz ---->> python-dev.tcz
Please use appsaudit to fetch new dep files. Also, remove the python-2.7.tcz extension, and allow the python.tcz to be updated with the new 2.7 version one.
Now we will start renaming the old python packages. Lets please be patient with each other, as it may be a tedious process with perhaps some typos or errors along the way. Also, there may be discussion or disagreement on which extensions need the 2.6 suffix. It may be a rough road until we get a good handle on the situation, so lets keep that in mind as we proceed and work toward a common goal.
-
BeautifulSoup.tcz already has a 2.7 version available with the -2.7 name, and no other extensions depend on it.
My recommendation is to remove BeautifulSoup.tcz and rename the 2.7 version to BeautifulSoup.tcz.
Will do so in a week or so if I do not hear objections from the extension maker.
-
Bmarkus has said he will rename his extensions to 2.6, and I am happy for folks to rename their own. Let me know here and I will wait for you do do it. Either way I will be checking and adjusting affected dep files as I upload the renamed extension.
But it has already been decided to rename 2.6 stuff as 2.6, and the python.tcz extensions themselves have been renamed to pave the way. The time for discussion of that has past. In any democracy, once a vote has been cast and a decision has been made, the decision is carried out even though there will invariably remain some differences of opinion. There has been more than plenty of time for discussion of the python situation, even to the point of "paralysis of analysis". Now is simply the time to carry out the renaming of 2.6 stuff.
The way I define a python package is if it has files in /usr/local/lib/pythonx.x directory. Others that have python files in other directories should not need renaming.
-
Either way I will be checking and adjusting affected dep files as I upload the renamed extension.
Why isn't the renaming being done with a script?
-
I was giving the extension makers a chance for those who would rather do it themselves. Since there has been no other submissions recently of renamed 2.6 stuff, I take that as a go ahead to resume renaming the rest.
-
I will be starting on the renaming soon.
I also notice that Arch Linux has patched wicd to work with python 2.7.
-
I also notice that Arch Linux has patched wicd to work with python 2.7.
Thanks. There is an ongoing discussion at WICD'S bugtracking page at launchpad, seems to be other fix also. Will check them.
-
2.6 stuff renamed, went well and dep files seem to have no errors. Hopefully this is the last dealing with 2.6 aside from fixing any conflict or similar that may arise.
It will be a pain on the first tce-update, check for missing dependencies after updating dep files, and deleting the old extensions that were converted to the 2.6 name is desirable. But once done it should be smooth from now.
-
Regarding WICD's Python 2.7 bug it was announced two days ago:
This is fixed in Wicd's trunk and will be released in 1.7.1 in the next couple of days.
I will update WICD to 1.7.1 as soon as available.
-
Python 2.7.1 is out
-
Ok, I will aim for it soon.
-
Ok, I will aim for it soon.
Thanks for the update !
-
Regarding WICD's Python 2.7 bug it was announced two days ago:
This is fixed in Wicd's trunk and will be released in 1.7.1 in the next couple of days.
I will update WICD to 1.7.1 as soon as available.
Still not released. Do you perhaps know how to make wicd behave with python and python2.6 coexisting?
Because I think they didn't mean a stable release
-
And could it be, that pygobject-2.7 gets overwritten by pygobject-2.6? I'm having some strange problems lately, but I'm not sure I created them or not...
-
It appears the libraries in /usr/local/lib overwrite each other. Another reason to deprecate and remove the 2.6 stuff, or at least stuff using pygobject-2.6.
-
I agree, I don't want to use wicd at all, but I'll have to find some time and setup my wpa_supplicant first.
I'm not sure yet if wpa_gui (qt dependency) is a reasonable alternative to the wicd gui, so I'm sure people will protest if we'd simply abandon that package altogether :D
-
I meant to say migrating the 2.6 stuff to python 2.7 rather than removing.
-
if your wireless is automatic ip with some password you can use cnetworkmanager
sudo cnetworkmanager --connect=MySSID --wpa-pass=MySSIDPassword
see cnetworkmanager info for details
regarding wicd bug i posted somewhere else in these forums there is wicd 1.7.1b2 which you can use, no need to wait 1.7.1 release
or you can apply this patch to wicd 1.7.0
http://projects.archlinux.org/svntogit/packages.git/tree/wicd/trunk/deepcopy+python27-fixes.patch (http://projects.archlinux.org/svntogit/packages.git/tree/wicd/trunk/deepcopy+python27-fixes.patch)
a note about patch, remove the last section which replaces python with python2