Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
2013/8/13 Peter FELECAN : > Alright. Consequently the page > http://wiki.opencsw.org/python-2-x-multi-versioned-modules is to be > deleted or redirected to the new one ? Let's keep the wiki page for notes. ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
"Maciej (Matchek) Bliziński" writes: > 2013/8/12 Maciej (Matchek) Bliziński >> I'd say at the end of each packaging/uploading session. Once you >> upload a package, the changes are immediately reflected in the >> database. > > I've turned it into a cronjob. > > http://buildfarm.opencsw.org/~maciej/python-modules.html > > I didn't write code to update the wiki page, generating HTML is simpler. > > The code is in /home/maciej/src/project-status on the buildfarm. Alright. Consequently the page http://wiki.opencsw.org/python-2-x-multi-versioned-modules is to be deleted or redirected to the new one ? > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
2013/8/12 Maciej (Matchek) Bliziński > I'd say at the end of each packaging/uploading session. Once you > upload a package, the changes are immediately reflected in the > database. I've turned it into a cronjob. http://buildfarm.opencsw.org/~maciej/python-modules.html I didn't write code to update the wiki page, generating HTML is simpler. The code is in /home/maciej/src/project-status on the buildfarm. ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
2013/8/11 Peter FELECAN : > Fair enough. With what frequency? Daily, weekly or whenever it feels > necessary? I'd say at the end of each packaging/uploading session. Once you upload a package, the changes are immediately reflected in the database. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
"Maciej (Matchek) Bliziński" writes: > 2013/8/11 Peter FELECAN : >>> The query is currently very slow, runs for more than 1 minute. I'll >>> see if I can speed it up. >> >> For me is quasi instantaneous. > > There was no index on the base directory field. I added it and it did the > trick. > >>> I'll leave it to you to dress the returned data structure in the wiki >>> syntax to make a table. >> >> That not an issue but I wonder how can I post it to the page that I >> created? Manually? > > Yes. I know there's an API but I didn't bother implementing. It could > be done for full automation, of course, but for now maybe it's > sufficient to run the script and paste the result in. Fair enough. With what frequency? Daily, weekly or whenever it feels necessary? -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
2013/8/11 Peter FELECAN : >> The query is currently very slow, runs for more than 1 minute. I'll >> see if I can speed it up. > > For me is quasi instantaneous. There was no index on the base directory field. I added it and it did the trick. >> I'll leave it to you to dress the returned data structure in the wiki >> syntax to make a table. > > That not an issue but I wonder how can I post it to the page that I > created? Manually? Yes. I know there's an API but I didn't bother implementing. It could be done for full automation, of course, but for now maybe it's sufficient to run the script and paste the result in. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
"Maciej (Matchek) Bliziński" writes:
> 2013/8/9 Peter FELECAN :
>> "Maciej (Matchek) Bliziński" writes:
>>
>>> 2013/8/9 Peter FELECAN :
I created this page:
http://wiki.opencsw.org/python-2-x-multi-versioned-modules
on which we can list the modules transition to the multi-versioned
recipe.
>>>
>>> This can and should be populated automatically. We can use the REST
>>> API to look for files in specific directories, and list them. I'll see
>>> if I can write such a tool; I'll extend the API if necessary.
>>
>> Great. I must confess that I wasn't very enthusiastic to maintain that
>> page by hand.
>
> I've just implemented the backend part and the client library method.
> http://sourceforge.net/apps/trac/gar/changeset/21707
>
> An example call using curl:
>
> curl
> http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/i386/SunOS5.10/pkgnames-and-paths-by-basedir?basedir=/opt/csw/lib/python;
> echo
>
> The client library has the new method GetPathsAndPkgnamesByBasedir(),
> it returns a dictionary from package names to the list of files.
>
> The most rudimentary shell helper would be:
>
> function pkgs_in_dir() { curl -s
> http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/i386/SunOS5.10/pkgnames-and-paths-by-basedir?basedir=$1
> | python -c "import cjson; import sys; print
> '\n'.join(sorted(cjson.decode(sys.stdin.read("; }
>
> Then you can call it:
> pkgs_in_dir /opt/csw/lib/python2.7
Very nice.
> The query is currently very slow, runs for more than 1 minute. I'll
> see if I can speed it up.
For me is quasi instantaneous.
> I'll leave it to you to dress the returned data structure in the wiki
> syntax to make a table.
That not an issue but I wonder how can I post it to the page that I
created? Manually?
--
Peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
2013/8/9 Peter FELECAN :
> "Maciej (Matchek) Bliziński" writes:
>
>> 2013/8/9 Peter FELECAN :
>>> I created this page:
>>>
>>> http://wiki.opencsw.org/python-2-x-multi-versioned-modules
>>>
>>> on which we can list the modules transition to the multi-versioned
>>> recipe.
>>
>> This can and should be populated automatically. We can use the REST
>> API to look for files in specific directories, and list them. I'll see
>> if I can write such a tool; I'll extend the API if necessary.
>
> Great. I must confess that I wasn't very enthusiastic to maintain that
> page by hand.
I've just implemented the backend part and the client library method.
http://sourceforge.net/apps/trac/gar/changeset/21707
An example call using curl:
curl
http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/i386/SunOS5.10/pkgnames-and-paths-by-basedir?basedir=/opt/csw/lib/python;
echo
The client library has the new method GetPathsAndPkgnamesByBasedir(),
it returns a dictionary from package names to the list of files.
The most rudimentary shell helper would be:
function pkgs_in_dir() { curl -s
http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/i386/SunOS5.10/pkgnames-and-paths-by-basedir?basedir=$1
| python -c "import cjson; import sys; print
'\n'.join(sorted(cjson.decode(sys.stdin.read("; }
Then you can call it:
pkgs_in_dir /opt/csw/lib/python2.7
The query is currently very slow, runs for more than 1 minute. I'll
see if I can speed it up.
I'll leave it to you to dress the returned data structure in the wiki
syntax to make a table.
Maciej
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
"Maciej (Matchek) Bliziński" writes: > 2013/8/9 Peter FELECAN : >> I created this page: >> >> http://wiki.opencsw.org/python-2-x-multi-versioned-modules >> >> on which we can list the modules transition to the multi-versioned >> recipe. > > This can and should be populated automatically. We can use the REST > API to look for files in specific directories, and list them. I'll see > if I can write such a tool; I'll extend the API if necessary. Great. I must confess that I wasn't very enthusiastic to maintain that page by hand. -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
2013/8/9 Peter FELECAN : > I created this page: > > http://wiki.opencsw.org/python-2-x-multi-versioned-modules > > on which we can list the modules transition to the multi-versioned > recipe. This can and should be populated automatically. We can use the REST API to look for files in specific directories, and list them. I'll see if I can write such a tool; I'll extend the API if necessary. ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
"Maciej (Matchek) Bliziński" writes: > 2013/8/9 Peter FELECAN >> >> That's quite bad and it shows why adding >> /opt/csw/lib/python/site-packages at the end of the search path for >> Python 2.7 was not a reasonable solution. >> >> I will experiment with a 2.7 Python without this patch which force us to >> speed up the delivery of adapted modules. However, this is not a real >> issue as we are in "unstable", isn't it? > > We've just introduced Python 2.7, it's a reasonable expectation that > the module support will grow gradually. My experimentation is successful, i.e. it confirms that having the non multi-versioned path in the search list for modules is not a good thing for the 2.7 interpreter. Consequently I uploaded a new Python 2.7 set of packages which doesn't suffer anymore of this brain damage... The first module ready to be uploaded is lxml. Wanting for the new 2.7 interpreter's installation on the build farm. > It would be good to have a list saying which modules are available for > which versions. I created this page: http://wiki.opencsw.org/python-2-x-multi-versioned-modules on which we can list the modules transition to the multi-versioned recipe. -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
2013/8/9 Peter FELECAN > > That's quite bad and it shows why adding > /opt/csw/lib/python/site-packages at the end of the search path for > Python 2.7 was not a reasonable solution. > > I will experiment with a 2.7 Python without this patch which force us to > speed up the delivery of adapted modules. However, this is not a real > issue as we are in "unstable", isn't it? We've just introduced Python 2.7, it's a reasonable expectation that the module support will grow gradually. It would be good to have a list saying which modules are available for which versions. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
Peter FELECAN writes:
> What's the solution for this issue? The obvious answer is to
> provide a specific module for each version with a shared object
> linked with the corresponding Python library.
>
> I'm trying to build the lxml module using the new multi version
> modules provided by Maciej.
>
> Unfortunately it's not a pleasure ride... I'm trying to demangle
> this and will give a status in a follow up.
After solving the gar issues when building multi-versioned Python
modules, I encounter the same symptom as described in the parent
message in /opt/csw/lib/python2.7/distutils/dist.py!
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Options.so",
O_RDONLY) Err#2 ENOENT
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Optionsmodule.so",
O_RDONLY) Err#2 ENOENT
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Options.py",
O_RDONLY) = 6
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Options.pyc",
O_RDONLY) = 7
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Options.pyc",
O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0100644) Err#17 EEXIST
open64("/opt/csw/lib/python/site-packages/Cython/Compiler/Scanning.so",
O_RDONLY) = 5
open("/opt/csw/lib/python/site-packages/Cython/Compiler/Scanning.so", O_RDONLY)
= 6
open("/opt/csw/lib/i386/libpython2.6.so.1.0", O_RDONLY) = 6
Received signal #6, SIGABRT [default]
That's quite bad and it shows why adding
/opt/csw/lib/python/site-packages at the end of the search path for
Python 2.7 was not a reasonable solution.
I will experiment with a 2.7 Python without this patch which force us to
speed up the delivery of adapted modules. However, this is not a real
issue as we are in "unstable", isn't it?
--
Peter
___
maintainers mailing list
maintainers@lists.opencsw.org
https://lists.opencsw.org/mailman/listinfo/maintainers
.:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
Peter FELECAN writes: > This, in category.mk, has no effect: > > include gar/gar.mk > > GARCOMPILER_PYTHON_2_6 = SOS12U3 > GARCOMPILER_PYTHON_2_7 = GNU > GARCOMPILER = $(GARCOMPILER_$(PYTHON_VERSION)) > > $(GARCOMPILER) expands to nil. Well, for this part, I found the source of the error: GARCOMPILER = $(GARCOMPILER_$(PYTHON_VERSION)) I'm committing the correction and throttling forward. -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
"Maciej (Matchek) Bliziński" writes: > 2013/8/9 Peter FELECAN >> What's the solution for this issue? The obvious answer is to >> provide a specific module for each version with a shared object >> linked with the corresponding Python library. >> >> I'm trying to build the lxml module using the new multi version >> modules provided by Maciej. > > I don't see a different way. I'm not saying the contrary. With what I'm struggling now is the modulated python module recipe. After updating the .buildsys/v2 I'm having difficulties in packaging lxml module: the compiler is not defined whatever I do. This, in category.mk, has no effect: include gar/gar.mk GARCOMPILER_PYTHON_2_6 = SOS12U3 GARCOMPILER_PYTHON_2_7 = GNU GARCOMPILER = $(GARCOMPILER_$(PYTHON_VERSION)) $(GARCOMPILER) expands to nil. Here is the tail of the output: running build_ext building 'lxml.etree' extension -DNDEBUG -O -I/opt/csw/include -Kpic -I/opt/csw/include/libxml2 -I/pariNAma/opencsw/lang-python/pylxml/trunk/work/build-isa-pentium_pro-python_version-2_6/lxml-3.1.2/./src/lxml/includes -I/opt/csw/include/python2.6 -c src/lxml/lxml.etree.c -o build/temp.solaris-2.10-i86pc-2.6/src/lxml/lxml.etree.o unable to execute -DNDEBUG: No such file or directory error: command '-DNDEBUG' failed with exit status 1 gmake[1]: *** [build-work/build-isa-pentium_pro-python_version-2_6/lxml-3.1.2/setup.py] Error 1 gmake[1]: Leaving directory `/pariNAma/opencsw/lang-python/pylxml/trunk' gmake: *** [merge-isa-pentium_pro-python_version-2_6] Error 2 If you have a recipe which works for this kind of package, give me a reference. TIA -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] symptoms for Python 2.6 vs 2.7 incompatibility for binary modules
2013/8/9 Peter FELECAN > What's the solution for this issue? The obvious answer is to > provide a specific module for each version with a shared object > linked with the corresponding Python library. > > I'm trying to build the lxml module using the new multi version > modules provided by Maciej. I don't see a different way. ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
