This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: 2.1 on OpenBSD 2.8: lots of bugs @ build
Type: Stage:
Components: None Versions:
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: fdrake Nosy List: fdrake, valaulmo
Priority: normal Keywords:

Created on 2001-04-18 00:42 by valaulmo, last changed 2022-04-10 16:03 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
config.tar.bz2 valaulmo, 2001-04-18 00:42 config.* (config.status, config.cache, etc.)
Messages (5)
msg4318 - (view) Author: Brad Allen (valaulmo) Date: 2001-04-18 00:42
I am doing a survey of current distributed information
systems, to see
if they are close to what they should be (I figured out
what they should
be in 1984), and am forced to find a Python which Mojo
Nation is compatible
with.  I will probably go back to Python 2.0, but since
the latest released
version (released today!) was 2.1, I just started there
(since the stable
one for OpenBSD 2.8 was way back at Python 1.6 and I
figured anything
past that was experimenting anyway).

--- Python 2.1 on OpenBSD 2.8 with Pentium I:

I'm getting these warnings while compiling Python 2.1
on OpenBSD 2.8:

cc   -o python \
                Modules/python.o \
                libpython2.1.a -lc_r -lutil
-L/usr/local/lib -lz  -lm  
./Modules/posixmodule.c:2995: warning: this program
uses setreuid(), which is deprecated.
./Modules/posixmodule.c:3014: warning: this program
uses setregid(), which is deprecated.
./Modules/posixmodule.c:4147: warning: tempnam()
possibly used unsafely; consider using mkstemp()
./Modules/posixmodule.c:4193: warning: tmpnam()
possibly used unsafely; consider using mkstemp()
ld: libpython2.1.a(fileobject.o): RRS text relocation
at 0x31168 for "_flockfile"
ld: libpython2.1.a(fileobject.o): RRS text relocation
at 0x311af for "_funlockfile"
PYTHONPATH= ./python ./setup.py build
running build


Please consider fixing those things.

---

***   HUNG   test_bufio.py

When running tests as "MAKE=gmake gmake test", it hung
under
test_bufio.  It required a SIGKILL to stop.  I tried
two things:

* Running test as README says manually with "python
...".
     python ./Lib/test/test_bufio.py
  This worked OK and produced no output that I was
aware of
  (unless it was hidden).

* Tried defining DONT_USE_FGETS_IN_GETLINE in the file
where it
  was looked at (./Objects/fileobject.c).  This did not
help;
  it still hung.  Running the test manually again at
this point worked also.


So, I had to find a way to skip that test (hid it in a
subdirectory
called HIDE).

***   HUNG   test_complex.py

The same thing happened with test_complex.py: it hung
during "...make test",
but ran OK manually; then I hid it to skip.  For
test_dl, I got slightly
different results; after the usual hanging, I then
manually ran it and got:

***   HUNG   test_dl.py*

Q:/usr/local/src/python/Python-2.1:2148$ python
Lib/test/test_dl.py
Traceback (most recent call last):
  File "Lib/test/test_dl.py", line 6, in ?
    import dl
ImportError: No module named dl
Q:/usr/local/src/python/Python-2.1:2149$ 

In each case, lots of CPU by the "python" process was
used as its
"hung" state.  I waited approximately three minutes of
CPU.  A
133Megahertz Pentium with a CPU cache on a Dell
computer is extremely
fast, and ought to finish any test within two minutes. 
Tell me if
I just failed to wait long enough for an increadibly
inefficiently
programmed test to complete, and I'll retry it.  The
fact that it did
not respond to signals except KILL also indicates to me
that it was
comotose.  (This discussion reminds me of a date where
the person
told me that the commands in Unix are very violent
sounding and the
names of the principles used by programmers are very
anti-social.
I'm glad someone thinks that way, since English itself
is far, far
worse, according to
http://www.islandnet.com/~edonon/decoding.htm, and
I said to myself "how can anybody use this language?"
in disgust.
Someday we'll fix that, too (and not just for
historical politeness;
for pureness of utility and efficiency -- snowballed
efficiency!).)

---

***   MEMORY FAULT   test_fork1.py

While the tests were running "test_fork1", I got a
Memory Fault.
Rerunning it manually worked, though, and I hid it
also.  (I did not
test rerunning it.)

While waiting for all these tests to hang, I got tired
of it and
now I want to request that you have all the tests run
in parallel.
That way, it is easier to weed out all the hanging ones
in one shot.
This is easy, right?

***   HUNG   test_compile.py

Next to hang was this one:

$ python ./Lib/test/test_compile.py
Running tests on argument handling
testing complex args
1 2
1 2
3 4
1 2 3
1 2 3
2 3 4
$

As you can see, it ran OK manually, and this time I had
some output to
look at.  While looking at it I realized that I do not
know if those
are the expected results, and in the house I'm in, I
have to listen to
too much hollaring to be able to learn Python in a few
minutes like
I am usually able to do in proper environments.

***   HUNG   test_doctest.py

test_doctest.py passed manually but automatically hung,
too.
It had too much output to include it all, but the last
line said
the test passed.


***   HUNG & SEGFAULT test_threadedtempfile.py

For test_threadedtempfile, I got a bad error:

$ python Lib/test/test_threadedtempfile.py 
Creating
Starting
Reaping
Segmentation fault (core dumped)
$ rm *core
$ python Lib/test/test_threadedtempfile.py 
Creating
Starting
Reaping
^C^C^C^Z
^Z^X^C
Killed
$ 
$ jobs
[1]-  Stopped                 less README
[2]+  Stopped                 MAKE=gmake gmake test
$ sync
$ rm Lib/test/test_threadedt

So far, a few tests ran better the second time than the
first.  Is
the compiling working better than the interpreting?

---

Brad Allen <Ulmo@Q.Net>

*
msg4319 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2001-07-11 18:29
Logged In: YES 
user_id=3066

The warnings are irrelevant -- any package that wraps those
functions to make them available to applications will cause
those warnings on OpenBSD, even if they are never used.

The other issues require more attention than I can spare
this week, so I'll leave this open.
msg4320 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2001-07-17 15:22
Logged In: YES 
user_id=3066

I'm looking into getting access to an OpenBSD machine to
test on.

The last comment in the bug report makes me wonder a bit,
however: did you wait for long to see if the tests
terminated?  Many of the tests will appear to run faster
during the second phase of the test since the test modules
will have already been byte-compiled, but the byte-code used
 to execute the tests will be the same during both phases.
msg4321 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2001-08-02 03:21
Logged In: YES 
user_id=3066

--sigh--  Still having problems getting access on an OpenBSD
machine.  Appearantly one has been set up at my employers
main office, but I can't get to it from the PythonLabs
office yet.  ;-(

No, I'm not ignoring this, but the priority isn't high given
that I can't get to a usable installation.  (It would be
great if SourceForge could provide one on the compile farm,
or if their FreeBSD machine actually responded.)
msg4322 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2001-09-11 20:01
Logged In: YES 
user_id=3066

Not able to reproduce this, and there are no corroborating
reports.
History
Date User Action Args
2022-04-10 16:03:58adminsetgithub: 34357
2001-04-18 00:42:05valaulmocreate