On Sat, 4 Jan 2025 at 09:22, aotto1968 via Python-list
wrote:
>
> On 30.12.24 18:29, Michael Torrie wrote:
> > On 12/26/24 12:34 AM, aotto1968 via Python-list wrote:
> >> sorry you don't understand the problem…
> >>
> >> > You managed to make a build of Python that attempts to link to a DLL
> >>
On 30.12.24 18:29, Michael Torrie wrote:
On 12/26/24 12:34 AM, aotto1968 via Python-list wrote:
sorry you don't understand the problem…
> You managed to make a build of Python that attempts to link to a DLL
I never touch the OpenSUSE python. the OpenSUSE python try to use my
sqalite3.
The
On 12/26/24 12:34 AM, aotto1968 via Python-list wrote:
> sorry you don't understand the problem…
>
> > You managed to make a build of Python that attempts to link to a DLL
>
> I never touch the OpenSUSE python. the OpenSUSE python try to use my
> sqalite3.
The *only* mechanism that would cause
On Mon, 30 Dec 2024 at 15:02, aotto1968 via Python-list
wrote:
> > You managed to make a build of Python that attempts to link to a DLL
>
> I never touch the OpenSUSE python. the OpenSUSE python try to use my
> sqalite3.
You keep saying this, but do you even know what "make install" does?
Are y
On 26.12.24 19:33, Michael Torrie wrote:
On 12/25/24 10:46 PM, Chris Angelico wrote:
Right. That's exactly what would happen if he'd built Python using
absolute paths to libraries, which is the normal way to do it. And so
the solution is to rebuild Python using absolute paths to libraries.
You
On 26.12.24 04:55, Michael Torrie wrote:
On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
It is not only an *usage* error it is also an *security* error because:
1) "cnf" is using OS python
2) os "root" python
3) using *
On 26.12.24 04:55, Michael Torrie wrote:
On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
It is not only an *usage* error it is also an *security* error because:
1) "cnf" is using OS python
2) os "root" python
3) using *
On 26.12.24 06:46, Chris Angelico wrote:
On Thu, 26 Dec 2024 at 14:57, Michael Torrie via Python-list
wrote:
On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
It is not only an *usage* error it is also an *security* err
On 25.12.24 23:55, Chris Angelico wrote:
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
It is not only an *usage* error it is also an *security* error because:
1) "cnf" is using OS python
2) os "root" python
3) using **my** local non-root library
Yes. And YOU were the one who
On 12/25/24 10:46 PM, Chris Angelico wrote:
> Right. That's exactly what would happen if he'd built Python using
> absolute paths to libraries, which is the normal way to do it. And so
> the solution is to rebuild Python using absolute paths to libraries.
You're right. Definitely appears to be a p
On Thu, 26 Dec 2024 at 14:57, Michael Torrie via Python-list
wrote:
>
> On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
> > On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
> > wrote:
> >> It is not only an *usage* error it is also an *security* error because:
> >>
> >> 1) "cnf"
On 12/25/24 8:55 PM, Michael Torrie wrote:
> This is Python related, but
> it's not necessarily python's fault per se.
It's also a good reminder to use venv. Then there's no way of
activating your custom python with its custom sqlite3 library unless you
explicitly activate the venv.
--
https://m
On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
> On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
> wrote:
>> It is not only an *usage* error it is also an *security* error because:
>>
>> 1) "cnf" is using OS python
>> 2) os "root" python
>> 3) using **my** local non-root librar
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
> It is not only an *usage* error it is also an *security* error because:
>
> 1) "cnf" is using OS python
> 2) os "root" python
> 3) using **my** local non-root library
Yes. And YOU were the one who installed a new root Python. This i
On 25.12.24 12:05, aotto1968 wrote:
I get angry…
next python error…
1) The OpenSUSE command "cnf" checks if a special package feature is installed.
2) I recently compiled **my** SQLite3 library specifically tailored to **my** requirement and installed it in **my** SQLite3
project directory and
I get angry…
next python error…
1) The OpenSUSE command "cnf" checks if a special package feature is installed.
2) I recently compiled **my** SQLite3 library specifically tailored to **my** requirement and installed it in **my** SQLite3
project directory and never changed the OpenSUSE installat
On 12/16/24 12:08 AM, aotto1968 via Python-list wrote:
> If I read the answers I come to the conclusion that the "supporters" at
> python doesn't ever understand the problem.
Sorry you feel that way. Various people gave the best advice they could
based on what you had provided. You were given s
On 2024-12-16, aotto1968 via Python-list wrote:
> If I read the answers I come to the conclusion that the "supporters"
> at python doesn't ever understand the problem.
You should definitely demand to speak to the manager and request your
money back.
--
Grant
--
https://mail.python.org/mailman
On 2024-12-16 08:08:46 +0100, aotto1968 via Python-list wrote:
> On 13.12.24 11:36, aotto1968 wrote:
> > it's a shame...
> > almost every tool I touch that uses "python" in some way has some
> > configuration error because apparently a __private__ python installation
> > __isn't__ properly "underst
On 13.12.24 11:36, aotto1968 wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python
installation __isn't__ properly "understood".
-> I think after ~30 years *python* should be able to handle a shared-
On 12/14/24 10:31 AM, aotto1968 via Python-list wrote:
> The CORE problem is that python3 works well in *my* environment but the
> installation is done as root and root does not use *my* environment.
>
> the mono build search for a working python3 and find *my*
> > HOME/ext/x86_64-suse-linux-gnu/
On Sun, 15 Dec 2024 at 06:05, aotto1968 via Python-list
wrote:
> The CORE problem is that python3 works well in *my* environment but the
> installation is done as root and root does not use *my* environment.
>
So, it's an environment problem, NOT a Python problem. You messed up
your installation.
On 14.12.24 10:56, Peter J. Holzer wrote:
On 2024-12-13 11:36:01 +0100, aotto1968 via Python-list wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some
configuration error because apparently a __private__ python installation
__isn't__ properly "understood".
->
On 12/14/24 2:56 AM, Peter J. Holzer via Python-list wrote:
> So it might be because it's in a different directory ("HOME/ext/..." is
> a relative path. That will not work in a different directory. Also
> "HOME" is a strange choice for a directory name. Did you mean $HOME?) or
> because the accepta
On 12/13/24 1:56 PM, aotto1968 via Python-list wrote:
> the problem is *not* to setup an environment variable, the problem is that
> python is *not*
> able to setup the *python* environment by it self.
You're mistaken in this case. Nothing you've posted indicates the
problem is in Python itself.
On 2024-12-13 11:36:01 +0100, aotto1968 via Python-list wrote:
> it's a shame...
> almost every tool I touch that uses "python" in some way has some
> configuration error because apparently a __private__ python installation
> __isn't__ properly "understood".
>
> -> I think after ~30 years *python*
On 13.12.24 19:24, Barry wrote:
On 13 Dec 2024, at 15:54, aotto1968 via Python-list
wrote:
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared
libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file
or directory
This is a debug build?
Try
> On 13 Dec 2024, at 15:54, aotto1968 via Python-list
> wrote:
>
> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared
> libraries: libpython3.12d.so.1.0: cannot open shared object file: No such
> file or directory
This is a debug build?
Try setting LD_LIBRARY_PAT
On 13.12.24 11:44, aotto1968 wrote:
On 13.12.24 11:36, aotto1968 wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python
installation __isn't__ properly "understood".
-> I think after ~30 years *pytho
On 13.12.24 11:36, aotto1968 wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python
installation __isn't__ properly "understood".
-> I think after ~30 years *python* should be able to handle a shared-
30 matches
Mail list logo
