Kubilay Kocak added the comment:
@Martin tldr; That was three years ago so I don't know if the issue remains.
Perhaps a new out of tree builder will help answer that question.
We(FreeBSD) gave up^W switched away from out of tree builds due to lack of
support getting issues fixed
Kubilay Kocak added the comment:
@Łukasz in case you're not aware, all koobs-freebsd* bots are DTrace enabled,
and can be tested with the custom builder. I'm on IRC (python-dev) if you need
anything from me to help progress this
--
___
Python
Kubilay Kocak added the comment:
@Victor I was just checking this issue to copy the test command, to provide
results to you both when I saw the lovely surprise. Thank you :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21590>
___
_
Kubilay Kocak added the comment:
@Martin Maybe Zach (nosey'd) can help us get an out-of-tree builder set up?
If this is relevant for 3.5+, versions should be updated accordingly.
--
nosy: +zach.ware
___
Python tracker <rep...@bugs.python.org>
Kubilay Kocak added the comment:
Attach file with test results.
It's worth mentioning that these results may (or may not) be different than
output when running under the process id started by twistd, which is executed
by root (startup script), and results in the following command:
buildbot
Kubilay Kocak added the comment:
This (adding support for pkg-config) should be done in tandem with adding
--with-foo-{include,library} arguments for each *external* dependency, which
can be used for: libffi, readline, libintl, openssl, sqlite, db*, among others.
Values obtained from pkg
Kubilay Kocak added the comment:
This started failing once again on koobs-freebsd-current:
==
ERROR: test_chown (test.test_os.ChownFileTests)
--
Traceback
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
Added file:
http://bugs.python.org/file45439/koobs-freebsd-current-python-3.5-debug-build-773.txt
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Kubilay Kocak added the comment:
I also note *one* failure on koobs-freebsd-9 on 3.x and 3.6 branches, identical
errors:
Nov 09 14:53 c27269c0d619... failure AMD64 FreeBSD 9.x 3.x #5304 Failed test
Nov 09 14:53 b671ac7ae620... failure AMD64 FreeBSD 9.x 3.6 #282 Failed test
Kubilay Kocak added the comment:
It appears something has changed in the past few weeks (with no changes made to
the buildbot worker).
Now only 3.5 branch (both debug and non-debug) builders are failing, except
there are now many failing tests, many different errors, and test clean is also
Kubilay Kocak added the comment:
Ping. All branches on the koobs-freebsd-current buildbot are still failing due
to this issue
I could recreate the entire worker environment from scratch, but:
a) I'm not sure it will resolve the issue
b) I'd rather fix the root cause
Kubilay Kocak added the comment:
All builders (branches) are failing, not just 3.x DEBUG. Failures also appear
no longer random or intermittent
--
title: test_os.test_chown() random failure on "AMD64 FreeBSD CURRENT Debug 3.x"
buildbot -> test_os.test_chown() failure on
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23284>
___
_
Kubilay Kocak added the comment:
Could we please:
a) Rename 'optimizations' to 'pgo' or 'profiled'
b) Use enable/disable instead of with/without. The former is used for toggling
program features, the latter is used for external dependencies [1][2][3]
Yes Python's configure / autofoo isn't
Kubilay Kocak added the comment:
I also invoke PEP20 (explicit > implicit) in favour of renaming the option :]
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Kubilay Kocak added the comment:
@Serhiy
I have noticed that the failure is reproducible in the buildbot workers only
when startup (of buildbot) is invoked via sudo, and not when started on
first-boot (rc runs as root).
In both situations, twistd then drops privs to --uid=buildbot --gid
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28491>
___
_
Kubilay Kocak added the comment:
Serhiy, ah I thought the patch would be applied to say the 'custom' builder for
this buildbot or the branch in general :)
If not, I can test this in ~<= 2 days locally, though its worth noting that the
issue quite likely not be reproducible outs
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23102>
___
_
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29225>
___
_
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30333>
___
_
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
stage: resolved -> backport needed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Kubilay Kocak added the comment:
@Antoine Happy to any time. PM me public key on IRC (freenode:koobs) and I'll
reply with user@host:port
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23404>
___
_
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
stage: -> backport needed
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Kubilay Kocak added the comment:
Thank you for investigating Victor.
This appears to require backporting to 3.6 and 3.5 which are also failing:
FAIL: test_repr (test.test_float.ReprTestCase)
--
Traceback (most recent call last
Kubilay Kocak added the comment:
2.7 branch on koobs-freebsd-current worker doesn't appear to be failing
currently, but there may be differences in (or a lack of equivalent) coverage
compared to 3.*.
I also note that -fno-strict-aliasing is being included in 2.7's compile
arguments:
cc
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30280>
___
_
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
Added file: http://bugs.python.org/file46937/python-sudo.txt
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Kubilay Kocak added the comment:
as per msg280837, this beings to happen when I restart the buildbot worker via
sudo (does not fail on initial startup, executed/invoked using the same script,
which does not use sudo) and the environment the worker starts with appears to
be relevant.
Attached
Kubilay Kocak added the comment:
For what it's worth, the koobs-freebsd-current buildbot worker has DTrace
enabled and can be used to build/test Python/dtrace bits
Zach and I spoke recently about getting custom builds hooked up to GitHub,
which I believe is now already possible, so all that's
Changes by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30345>
___
_
Kubilay Kocak added the comment:
bpo-30188 (and bpo-30188 ?) need merging to 3.6/3.5, 3.6 just failed with:
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:748)
Full build log attached
--
nosy: +koobs
resolution: fixed ->
stage: resolved -> backport needed
Kubilay Kocak added the comment:
Apologies I meant 5b4feb7e86 by haypo and 067931dd95d (also needs merge?) by
inada.naoki
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Kubilay Kocak <koobs.free...@gmail.com> added the comment:
The changeset(s) applied in this issue were/are fine (thus no response on the
issue)
It is the *removal* of the changesets included in this issue (as proposed in
https://github.com/python/cpython/pull/5233) that would re
Kubilay Kocak <koobs.free...@gmail.com> added the comment:
If the intent is to use this issue to track the resolution of the original
issue (clang compilation broken) and cover the new PR (which just moves the
code from os detection to compiler detection), then it can remain open.
Oth
Kubilay Kocak <koobs.free...@gmail.com> added the comment:
I believe changeset d4b93e21c2664d6a78e0656e7a7be0807be1c352 may be the cause
of buildbot failures on FreeBSD (at least koobs-freebsd-current, log attached),
due to only the EBADF error being handled (not EINVAL, et al).
Unfortu
Change by Kubilay Kocak <koobs.free...@gmail.com>:
--
stage: resolved -> needs patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Kubilay Kocak :
--
nosy: +koobs
title: test_cmd_line test_utf8_mode test_warnings fail in AMD64 FreeBSD CURRENT
buildbots -> test_cmd_line test_utf8_mode test_warnings fail in all FreeBSD 3.x
(3.8) buildbots
___
Python tracker
<
Change by Kubilay Kocak <koobs.free...@gmail.com>:
--
nosy: +koobs
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32430>
___
_
Kubilay Kocak added the comment:
All our FreeBSD ports (lang/python??) and the packages produced from them all
contain a LIBFFI option which is enabled by default, since 2015 [1][2]:
LIBFFI=on: Use libffi from ports instead of bundled version
This means that any 'default' package builds
Change by Kubilay Kocak :
--
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue20397>
___
___
Python-bug
Kubilay Kocak added the comment:
The version in base is:
/usr/bin/openssl version
OpenSSL 1.1.1-freebsd 11 Sep 2018
There is a version from ports also installed at a different prefix, which I
don't believe Python picks up by default unless Modules/Setup or --with-openssl
(is this in 3.6
Kubilay Kocak added the comment:
To clarify affected tests/versions:
Python 3.x - test_socket test_multiprocessing_spawn
Python 2.7 - test_multiprocessing_spawn
All of the issues are related to incorrect recvmsg(2) buffer length use, so
I've amended the issue summary to describe
Change by Kubilay Kocak :
--
nosy: -koobs
___
Python tracker
<https://bugs.python.org/issue34694>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
Copying in my original email to Pablo that elucidated the test failure cause
and resolution, including upstream commit/review/issue references for the
recvmsg(2) changes IN CURRENT.
Full buildbot worker log attached
While I'm here, update list of versions
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue34589>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue35413>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue35290>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue35537>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: -koobs
___
Python tracker
<https://bugs.python.org/issue34656>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
Downstream issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232792
--
nosy: +koobs
versions: +Python 2.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue35998>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
I've just removed gdb from the buildbot at Pablo's (email) request. I can
reinstall it on request at any time to resolve the test_gdb failures tracked in
this issue.
--
___
Python tracker
<https://bugs.python.
Kubilay Kocak added the comment:
Pablo asked for gdb to be installed to debug the crash in bug issue 36114 and I
let him know in my email reply that when I had installed gdb in the past for an
unrelated debug need, that test_gdb failed, which at the time I didn't have the
time/cycles
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36235>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36184>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue35224>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue35823>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
Access to the buildbot has been restored (a while ago), and this issue being
resolved (merge to 2.7) is the only test failing to get 2.7 back to green,
which has been failing for months.
Can we test with Victors proposed patch in msg330654 ? I don't believe
Kubilay Kocak added the comment:
Again, happy to provide ssh access to the koobs-freebsd-current worker to help
analysis, just PM me ssh public keys on IRC (koobs @ #python-dev freenode)
--
___
Python tracker
<https://bugs.python.org/issue33
Kubilay Kocak added the comment:
Seeing a test_ayncio failure on koobs-freebsd-current:
Timeout (0:25:00)!
Thread 0x000800abb000 (most recent call first):
File
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/selectors.py",
line 558 in select
File
"/us
Kubilay Kocak added the comment:
@Andrew That would be great, as having failing buildbots can hide new
regressions that end up taking much longer to identify and fix as they are
hidden, and is better for you than reverting implementation code
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36624>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
For FreeBSD Python language ports, the change doesn't have a big negative
impact for the Python language/interpreter ports themselves
We have the following block in lang/python3? ports:
.if ${PORT_OPTIONS:MPYMALLOC}
ABIFLAGS:= m${ABIFLAGS}
.endif
Kubilay Kocak added the comment:
Those script names would already have code to handle name changes based on
existing abiflags/soabi string (as FreeBSD does), and would be trivial to
modify for 'm' removal.
For third party stuff: we use setuptools --record for 'everything', so as long
Change by Kubilay Kocak :
--
resolution: fixed ->
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue35621>
___
___
Python-bugs-list
Kubilay Kocak added the comment:
New buildbot failure on koobs-freebsd10 that appears related to (includes) this
changeset
Full log attached
--
nosy: +koobs
Added file:
https://bugs.python.org/file48384/koobs-freebsd-10-non-debug-3x-build-1170.txt
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36402>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
And I just remembered that I had to restart the build worker service on that
host (koobs-freebsd10) this morning as I was receiving messaging that the
worker had gone missing.
I ran `[koobs@10-STABLE-amd64:~] sudo /usr/local/etc/rc.d/buildslave restart
Kubilay Kocak added the comment:
This looks like a reincarnation of #27838
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue37400>
___
___
Pytho
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue30458>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
title: mmap module, adding new constant -> mmap module, add MAP_ALIGNED_SUPER
FreeBSD constant
___
Python tracker
<https://bugs.python.org/issu
Kubilay Kocak added the comment:
Thanks for clarifying Victor
--
___
Python tracker
<https://bugs.python.org/issue37471>
___
___
Python-bugs-list mailin
New submission from Kubilay Kocak :
Thanks David!
Can this be backported to earlier 3.x's and 2.7?
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36659>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36707>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue35755>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36454>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36632>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
@Eric Happy to give you SSH access to one of the FreeBSD buildbots that's
experienced the crash if it helps. Just flick me a pubkey, I'm on IRC (koobs @
freenode / #python-dev)
--
nosy: +koobs
___
Python tracker
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue37811>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
See Also: #31334
--
___
Python tracker
<https://bugs.python.org/issue37811>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
See Also: #26826
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue37157>
___
___
Python-bugs-list mailin
Kubilay Kocak added the comment:
See Also: #26826
--
___
Python tracker
<https://bugs.python.org/issue37959>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
Possibly related:
https://reviews.freebsd.org/D20584 - Add a linux compatible copy_file_range(2)
syscall
https://lists.freebsd.org/pipermail/freebsd-current/2019-July/073747.html
--
___
Python tracker
<ht
Kubilay Kocak added the comment:
Hmm... a test checkout of master/default on the host in question has
test_copy_file_range{_*} passing:
[user@CURRENT-amd64:/usr/home/user/repos/cpython] ./python -m test -vvv test_os
|grep range
...
test_copy_file_range (test.test_os.FileTests) ... ok
Kubilay Kocak added the comment:
Ran rebuild (in the BB UI) on that failed build (#1356), and test_os now passes:
0:22:52 load avg: 8.38 [339/419] test_os passed
Victor independently logged into the host and ran a from scratch build/test and
test_os passes for him too (verifying my from
Kubilay Kocak added the comment:
Possibly, but unlikely as the system had been freshly installed and rebooted
before the worker was restarted.
The worker processes, however, had not been stopped prior to, or during the
upgrade, so it's possible that the worker had an inconsistent build
Kubilay Kocak added the comment:
@Pablo Upgrade to latest CURRENT revision a few hours ago. Some system software
is still updating. I'll push a rebuild on BB once complete. Stand by :)
--
___
Python tracker
<https://bugs.python.org/issue37
Kubilay Kocak added the comment:
@Victor I mounted fdescfs on the buildbot workers to make the tests run faster.
You're correct that it's not enabled by default.
If we could look at the initial support being as simple as possible, we can
look to backport this to 2.7 as well
Kubilay Kocak added the comment:
I've restarted the worker via sudo service(8), which shouldn't have the same
(environment) issue as starting the rc script directly under sudo
https://buildbot.python.org/all/#/builders/168/builds/1462 is running now
Let me know if you need any further
Kubilay Kocak added the comment:
I can restart the worker to create the environment that reproduces the issue at
any time to confirm the test passes, just let me know
--
___
Python tracker
<https://bugs.python.org/issue38
Kubilay Kocak added the comment:
Thanks Terry, I've restarted the worker under sudo
The following builds are underway:
https://buildbot.python.org/all/#/builders/168/builds/1467 (default)
https://buildbot.python.org/all/#/builders/212/builds/218 (3.8)
https://buildbot.python.org/all
Kubilay Kocak added the comment:
@Victor Yes. I restarted the worker to re-create reproduction conditions. It
looks like default, 3.8 and 3.7 are OK now after Terry;s commits, with 2.7
failing (expected):
https://buildbot.python.org/all/#/builders/169/builds/170
It would be nice to fix
Kubilay Kocak added the comment:
We're tracking this in our downstream bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221700
There's a patch there you may base something upstream on
Open question:
closefrom(2) test in ./configure && ifdef __F
Kubilay Kocak added the comment:
On "close_except", close_range and posix_spawn(close_fds=True), I'll talk to my
interested FreeBSD colleagues about potential inroads in that regard.
In the meantime, we're good on closefrom(2) anywhere it can be used
Kubilay Kocak added the comment:
> Would it be possible to modify FreeBSD to enable it by default? Or is there a
> reason to not enable it by default?
That's very unlikely to happen. I believe it was added as an opt-in feature for
some linux compatibility situations. The correct so
Kubilay Kocak added the comment:
This is related to issue 37400 and issue 27838 in that specific invocations of
the buildbot service (like via sudo) cause the environment to be setup
differently.
In this case, I had just started the buildbot worker via sudo prior to the
build starting
1 - 100 of 163 matches
Mail list logo
