Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems
On 2015-12-01 23:19, Elan Ruusamäe wrote: > On 01.12.2015 19:49, jajcus wrote: >> The hack is to have architecture-specific pyconfig-*.h files and >> a ghost >> symlink updated with python-devel install. I hope this works. > > a cleaner way is to install wrapper header file which based on > preprocessor variables includes proper arch specific file > no triggers, no scriptlets, no ghosts. Is it better now? Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: RFC: default python installlation directories
On Wed, 02 Dec 2015, Jacek Konieczny wrote: > On 2015-12-01 19:57, Jan Rękorajski wrote: > > Well, icedove still doesn't build, this time with: > [...] > > checking Python environment is Mozilla virtualenv... Traceback (most recent > > call last): > > File "", line 1, in > > ImportError: No module named mozbuild.base > > configure: error: Python environment does not appear to be sane. > > Try python-2.7.10-6.1 and rpm-build-macros-1.713 Looks good on my machine, I sent a test build to make sure. -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: RFC: default python installlation directories
On 2015-12-01 19:57, Jan Rękorajski wrote: > Well, icedove still doesn't build, this time with: [...] > checking Python environment is Mozilla virtualenv... Traceback (most recent > call last): > File "", line 1, in > ImportError: No module named mozbuild.base > configure: error: Python environment does not appear to be sane. Try python-2.7.10-6.1 and rpm-build-macros-1.713 Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems
On 2015-12-02 15:54, Jacek Konieczny wrote: > On 2015-12-02 15:35, Jakub Bogusz wrote: >> On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote: > >>> At least for this: >>> https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422 >>> > >> >> get_config_h_filename() should return the ABI-specific file for multilib >> installs to work correctly. > > But then virtualenv will probably fail to copy the right file to the > right place when making the virtual environment. I will check this, though. It seems virtualenv symlinks whole python include directory and would not mind different pyconfig*.h files. So patching get_config_h_filename() and making pyconfig.h include platform-dependent header could work. Now I have questions: 1. how should we call thee platform-dependent header files? 2. What set of #if/#ifdef should i use in pyconfig.h to include proper file on a platform? Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pythonegg() vs manual dependencies
On 2015-12-02 16:33, Jakub Bogusz wrote: > Currently many packages, for which pythonegg()/python3egg() dependencies > are generated, have the same set of dependencies (or outdated version of it) > specified manually in .spec by package name. We can do that. > Manually specified dependencies duplicating autodetected ones could be > dropped now, but what should be specified as rpm-pythonprov version to > ensure functional pythonegg/python3egg depdencies detector? rpm-pythonprov-5.4.15-31 seems to work properly now, but versions before my optimizations were also ok. The broken RPM never got into th-main AFAIK. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
pythonegg() vs manual dependencies
Currently many packages, for which pythonegg()/python3egg() dependencies are generated, have the same set of dependencies (or outdated version of it) specified manually in .spec by package name. Manually specified dependencies duplicating autodetected ones could be dropped now, but what should be specified as rpm-pythonprov version to ensure functional pythonegg/python3egg depdencies detector? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems
On 2015-12-02 15:35, Jakub Bogusz wrote: On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote: At least for this: https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422 get_config_h_filename() should return the ABI-specific file for multilib installs to work correctly. But then virtualenv will probably fail to copy the right file to the right place when making the virtual environment. I will check this, though. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems
On 02.12.2015 15:56, Jacek Konieczny wrote: ee, what patch? At least for this: https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422 There might be other Python code parsing this header, as it is considered a part of standard Python interface. uh. what a mess! python sucks then! :D ruby at least provides such header export in native language (ruby array) -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems
On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote: > On 2015-12-02 13:03, Elan Ruusamäe wrote: > >>How would you convince python library to parse this file correctly? > >>Another PLD-specific Python patch, which would cause many standard > >>Python packages to fail? > >> > >>My solution is not pretty, but doesn't change a thing from the Python > >>perspective. > > > >ee, what patch? > > At least for this: > https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422 > > There might be other Python code parsing this header, as it is > considered a part of standard Python interface. > > >i'm speaking of installing "config.h" from static source111, and python > >original rename as config-ARCH.h when packaging. > >and the preprocessor macros are generic, from compiler > > But this file is not only used by the C compiler. If it would be the > case, then we would ship the file in the -devel package and not the > -libs packages and there would be no problem. get_config_h_filename() should return the ABI-specific file for multilib installs to work correctly. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems
On 2015-12-02 13:03, Elan Ruusamäe wrote: How would you convince python library to parse this file correctly? Another PLD-specific Python patch, which would cause many standard Python packages to fail? My solution is not pretty, but doesn't change a thing from the Python perspective. ee, what patch? At least for this: https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422 There might be other Python code parsing this header, as it is considered a part of standard Python interface. i'm speaking of installing "config.h" from static source111, and python original rename as config-ARCH.h when packaging. and the preprocessor macros are generic, from compiler But this file is not only used by the C compiler. If it would be the case, then we would ship the file in the -devel package and not the -libs packages and there would be no problem. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems
On 02.12.2015 14:03, Elan Ruusamäe wrote: i'm speaking of installing "config.h" from static source111, and python original rename as config-ARCH.h when packaging. so you get the idea, it was in our linux-libc-headers too before upstream started to do that themselves: https://github.com/pld-linux/linux-libc-headers/blob/bd829e04c6c7fb524bd7d012bf9bc67d474b0825/linux-libc-headers.spec -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
java packaging
error: Install/Erase problems: file /usr/bin/javaws from install of oracle-java8-jre-X11-1.8.0.66-1.x86_64 conflicts with file from package icedtea-web-1.6-1.x86_64 just dumping info here, i don't expect anything. just maybe someone thinks javaws should be moved to some subpackage in oracle-java8.spec -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/python] Prevent pyconfig.h conflicts on multiarch systems
On 02.12.2015 09:48, Jacek Konieczny wrote: On 2015-12-01 23:19, Elan Ruusamäe wrote: On 01.12.2015 19:49, jajcus wrote: The hack is to have architecture-specific pyconfig-*.h files and a ghost symlink updated with python-devel install. I hope this works. a cleaner way is to install wrapper header file which based on preprocessor variables includes proper arch specific file no triggers, no scriptlets, no ghosts. …and new compatibility problems with all the Python world, and if the file is identical on both multilib packages, rpm will happily install it without complaining so, it would be something like: #if X86_64 #include "py-x86_64.h" #elseif IX86 #include "py-ix86.h" #else #error unsupported arch #endif How would you convince python library to parse this file correctly? Another PLD-specific Python patch, which would cause many standard Python packages to fail? My solution is not pretty, but doesn't change a thing from the Python perspective. ee, what patch? i'm speaking of installing "config.h" from static source111, and python original rename as config-ARCH.h when packaging. and the preprocessor macros are generic, from compiler and my solution doesn't also change a thing from python perspecitve, just config.h -> config-ARCH.h redirection is done on file cpp level, not symlink. solution done at packaging time, not at package install time. also my solution would make rpm -V work properly. ps: such solution is commonly done in fedora where they do handle multilib more thoughtfully than us -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
