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. …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. 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 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 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 -- glen ___ 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: > On Tue, 01 Dec 2015, Jacek Konieczny wrote: > Well, icedove still doesn't build, this time with: > > Creating Python environment > New python executable in > /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python2.7 > Also creating executable in > /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python > Installing setuptools, pip, wheel...done. > running build_ext > > 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. > -- config.log -- > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > Doesn't matter if I use mozilla virtualenv, our virtualenv or virtualenv-2.7. I can see what is the problem now. I'll try to fix it tomorow. Lets keep that lib/share split only for the site-packages under the /usr prefix. We need it there. /usr/local and virtualenvs can have the Python way. 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 Tue, 01 Dec 2015, Jacek Konieczny wrote: > On 2015-11-30 09:19, Jan Rękorajski wrote: > > On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny wrote: > >> On 2015-11-29 23:30, Jan Rękorajski wrote: > > >>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7' > > >> I will investigate this further in the evening. > > > > A food for thought - what about dropping PLD specific hack with with > > lib<->share split? > > It constantly gives us grief with virtualenv. > > I guess I have managed to fix that. Vanila upstream virtualenv seems to > work correctly now, at least when not using --system-site-packages. > > I hope I have not introduced many new problems ;) Well, icedove still doesn't build, this time with: Creating Python environment New python executable in /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python2.7 Also creating executable in /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python Installing setuptools, pip, wheel...done. running build_ext 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. -- config.log -- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. Doesn't matter if I use mozilla virtualenv, our virtualenv or virtualenv-2.7. -- 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 Tue, 01 Dec 2015, Jacek Konieczny wrote: > On 2015-11-30 09:19, Jan Rękorajski wrote: > > On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny wrote: > >> On 2015-11-29 23:30, Jan Rękorajski wrote: > > >>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7' > > >> I will investigate this further in the evening. > > > > A food for thought - what about dropping PLD specific hack with with > > lib<->share split? > > It constantly gives us grief with virtualenv. > > I guess I have managed to fix that. Vanila upstream virtualenv seems to > work correctly now, at least when not using --system-site-packages. Thank you! -- 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-11-30 09:19, Jan Rękorajski wrote: > On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny wrote: >> On 2015-11-29 23:30, Jan Rękorajski wrote: >>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7' >> I will investigate this further in the evening. > > A food for thought - what about dropping PLD specific hack with with > lib<->share split? > It constantly gives us grief with virtualenv. I guess I have managed to fix that. Vanila upstream virtualenv seems to work correctly now, at least when not using --system-site-packages. I hope I have not introduced many new problems ;) Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ssh_config broken
On 01.12.2015 15:41, Paweł Gołaszewski wrote: My fault, forgot to change count :-/ Anyway - glen is right, rpm should reject that... well. you did not adjust the patch range, so the patch scope stayed the same, effectively cut out last line from patch. the same what jacek said in later thread. i guess there's no way to fight against such specific failure except some automated function testing? ps: i do create pld vagrant images regularily [1] that had catched some sshd setup errors in the past [2] but it's not built automatically, only when i hit "build". [1] https://www.pld-linux.org/people/glen/vm-info [2] http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2015-November/024554.html -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ssh_config broken
On 2015-12-01 15:05, Marcin Krol wrote: Anyway - glen is right, rpm should reject that... Perhaps we should go debian-like route and accept only patches that apply cleanly? Fuzziness can cause code to be inserted/deleted/modified in wrong places which can cause compile time errors, segfaults, broken configs etc. I encountered such issues many times and most of our patches apply with fuzzines or offsets. But this case was not about fuzzines or invalid patch. Patches are allowed to contain trailing data – they might be part of an e-mail message. That is why blues' patch was accepted. The line ignored was technically outside of the patch. Jacek ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ssh_config broken
Anyway - glen is right, rpm should reject that... Perhaps we should go debian-like route and accept only patches that apply cleanly? Fuzziness can cause code to be inserted/deleted/modified in wrong places which can cause compile time errors, segfaults, broken configs etc. I encountered such issues many times and most of our patches apply with fuzzines or offsets. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: ssh_config broken
On Tue, 1 Dec 2015, Elan Ruusamäe wrote: > https://github.com/pld-linux/openssh/commit/00b8e87302dc268a8df8b6f9a2e107e515492249 > > such commit made ssh config truncated: > > ➔ tail /etc/ssh/ssh_config > # mode correctly we set this to yes. > ForwardX11Trusted yes > StrictHostKeyChecking no > ServerAliveInterval 60 > ServerAliveCountMax 10 > TCPKeepAlive no > # Allow DSA keys > # PubkeyAcceptedKeyTypes +ssh-dss > # HostkeyAlgorithms +ssh-dss > # Send locale-related environment variables, also pass some GIT vars > ➔ > > first: you (blues) shouldn't use vim to edit patches, at least use editdiff > from patchutils! :-O My fault, forgot to change count :-/ Anyway - glen is right, rpm should reject that... -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
ssh_config broken
https://github.com/pld-linux/openssh/commit/00b8e87302dc268a8df8b6f9a2e107e515492249 such commit made ssh config truncated: ➔ tail /etc/ssh/ssh_config # mode correctly we set this to yes. ForwardX11Trusted yes StrictHostKeyChecking no ServerAliveInterval 60 ServerAliveCountMax 10 TCPKeepAlive no # Allow DSA keys # PubkeyAcceptedKeyTypes +ssh-dss # HostkeyAlgorithms +ssh-dss # Send locale-related environment variables, also pass some GIT vars ➔ first: you (blues) shouldn't use vim to edit patches, at least use editdiff from patchutils! secondly: how to avoid broken patch like this being ignored by build process? -- glen ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
