Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue46263>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
title: test_sched_getaffinity and setaffinity fail on FreeBSD buildbit ->
posix.sched_{get|set}affinity(-1) no longer returns ProcessLookup causing test
failures on FreeBSD
___
Python tracker
<https://bugs.pyth
Kubilay Kocak added the comment:
>From one of our base/kernel developers:
--
> koobs wrote:
>
> I don't grok the system call semantics, but it appears the issue is calls
> with the '-1' argument:
>
> mask = posi
Kubilay Kocak added the comment:
Investigating
--
stage: patch review ->
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue47205>
___
__
Kubilay Kocak added the comment:
I modified the systems /etc/make.conf for unrelated purposes today (adding in
LASTCFLAGS among other variables).
Why and how Pythons build is inheriting that is the bigger question. I wonder
if its buildbot environment related.
In the short term I've
Change by Kubilay Kocak :
--
assignee: terry.reedy ->
components: +Library (Lib) -Extension Modules, FreeBSD, IDLE, IO, Installation,
Interpreter Core, SSL, Subinterpreters, Tests, Tkinter, Windows, XML, macOS
nosy: +lukasz.langa -koobs, ned.deily, paul.moore, ronaldousso
Kubilay Kocak added the comment:
Reference for Linux behaviour:
filedesc: don't use ioctl(FIOCLEX) on Linux #62425
https://github.com/rust-lang/rust/pull/62425
Looks like we match the behaviour intentionally (or otherwise).
--
___
Python tracker
Kubilay Kocak added the comment:
O_PATH support was added in FreeBSD CURRENT April 15:
https://reviews.freebsd.org/D29323?id=86257
https://github.com/freebsd/freebsd-src/commit/8d9ed174f3afba5f114742447e622fc1173d4774
@Victor If the failure in this tests suggests either a bug in our
Kubilay Kocak added the comment:
There was a recent worker update to latest CURRENT (14). I'll try to identify
recent changes or changesets that may have affected behaviour and reference
them here
--
___
Python tracker
<https://bugs.python.
Kubilay Kocak added the comment:
Fix meta (not incl 2.7 which is no longer available to select).
--
components: +Unicode -FreeBSD
versions: +Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36
Change by Kubilay Kocak :
--
components: +Interpreter Core -FreeBSD
nosy: -koobs
___
Python tracker
<https://bugs.python.org/issue43901>
___
___
Python-bug
Kubilay Kocak added the comment:
I'll see if I can isolate
--
___
Python tracker
<https://bugs.python.org/issue43233>
___
___
Python-bugs-list mailing list
Unsub
Kubilay Kocak added the comment:
P.S gdb and bash have been rebuilt :)
--
___
Python tracker
<https://bugs.python.org/issue43068>
___
___
Python-bugs-list mailin
Kubilay Kocak added the comment:
Note: Not suggesting dep removals, just a try-except-skip block in the
(hopefully) one place the sub-process handler in the test framework that runs
then :)
--
___
Python tracker
<https://bugs.python.
Kubilay Kocak added the comment:
@Gregory I'm the worker owner and can coordinate buildbot worker changes with
Zach or Victor
FreeBSD has:
editline (in FreeBSD base, installed in /usr/ )
libedit in ports/packages (installs in /usr/local)
readline in ports/packages (installs in /usr/local
Kubilay Kocak added the comment:
Would we like the freebsd worker CI configurations to be modified to use
ports/package versions of libedit (or readline, or whatever) to ensure
converage?
Right now the defaults are used (whatever edit library that entails
Kubilay Kocak added the comment:
Rebuilding bash & gdb now to pickup new/updated ncurses library.
Still suggest picking up "subprocess.CalledProcessError" generically in test
framework for tests that use subprocess/external commands
--
Kubilay Kocak added the comment:
The failure mode is a generic "an external dependency expected by a test suite
is not available or doesn't run", applying to many core Python test that
invokes an external utilities, and not specific to OS.
As far as I'm aware, the bes
Kubilay Kocak added the comment:
FreeBSD base was updated on the FreeBSD workers, between versions that changes
the way the base curses library was built, and what it built.
The net results was that any software (from ports) linked against base curses
needed to be rebuilt, and until
New submission from Kubilay Kocak :
Thank you for the PR David.
If there's anything I can do to help support you with respect to Python on
FreeBSD (such as accounts on the official freebsd python buildbot workers) let
me know :)
--
___
Python
Kubilay Kocak added the comment:
@Kyle Yes, msg373597 freebsd CURRENT buildbot passes, but freebsd 12/stable
does not (cannot, since stable/12 wont get the syscall)
That means the Python memfd functions and tests need to account
Kubilay Kocak added the comment:
I've updated the FreeBSD CURRENT buildbot past base/r363065 [1] which
implements SHM_GROW_ON_WRITE:
https://svnweb.freebsd.org/changeset/base/363065
https://reviews.freebsd.org/D25502
Also worth noting that I don't believe stable/12 (FreeBSD 12.x
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue38576>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue39503>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
memfd_create came in via:
https://github.com/freebsd/freebsd/commit/575e351fdd996f72921b87e71c2c26466e887ed2
via review: https://reviews.freebsd.org/D21393
via kevans (cc'd)
--
nosy: +kevans
___
Python tracker
Kubilay Kocak added the comment:
Failure on AMD64 FreeBSD Shared 3.x (full log attached):
==
FAIL: test_subinterpreter (test.test__xxsubinterpreters.IsRunningTests
Kubilay Kocak added the comment:
Another example, this time for lzma:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209355
--
___
Python tracker
<https://bugs.python.org/issue40
Kubilay Kocak added the comment:
FreeBSD base provides uuid.h (uuid(3)) but uuid libraries/headers can be
provided by e2fsprogs-libuuid (for example) in another location, for example
/usr/local/
Pythons build system doesn't provide sufficient granularity to pass
include/library locations
Kubilay Kocak added the comment:
Added 8gb swap disk to each BB worker
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Kubilay Kocak added the comment:
Provisioning new/additional swap to both of FreeBSD BB workers in the next few
days. Apologies for the delay
--
___
Python tracker
<https://bugs.python.org/issue39
Kubilay Kocak added the comment:
Confirming: test_ssl passes with 1.1.1e + reverted EOF change
--
___
Python tracker
<https://bugs.python.org/issue40
Kubilay Kocak added the comment:
Updating the koobs-freebsd-564d buildbots FreBSD openssl port now which has had
the 1.1.1e EOF change reverted. Will run the last 3.x build again and report
here whether it passes (it should) or not.
--
___
Python
Kubilay Kocak added the comment:
+1 to mutually beneficial relationships :)
--
___
Python tracker
<https://bugs.python.org/issue39982>
___
___
Python-bugs-list m
Kubilay Kocak added the comment:
koobs-freebsd-564d (CURRENT) BB has been updated past
https://svnweb.freebsd.org/base?view=revision=359302
test_socket is no longer failing
--
resolution: -> fixed
stage: -> resolved
status: open -&g
Kubilay Kocak added the comment:
Seeing the following on the freebsd CURRENT bb:
==
FAIL: test_set_and_clear (test.test_threading.EventTests)
--
Traceback
Kubilay Kocak added the comment:
Confirming on FreeBSD CURRENT buildbot worker which had its openssl updated to
1.1.1e a number of days ago. I reverted back to 1.1.1d
Full log of the failing build/tests with 1.1.1e attached
--
nosy: +koobs
Added file:
https://bugs.python.org
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue40039>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
I've been in touch with the FreeBSD SCTP maintainer and will continue to
investigate that avenue.
In the meantime, I'm re-running the last successful 3.x build (382 [1]) to see
if that fails or not to isolate Cpython code changes as contributing causes
[1
Kubilay Kocak added the comment:
Update to BB complete. Rebuilding:
https://buildbot.python.org/all/#/builders/18/builds/162 and
https://buildbot.python.org/all/#/builders/152/builds/409
--
___
Python tracker
<https://bugs.python.org/issue39
Kubilay Kocak added the comment:
Saw the following commit which *may* be related:
"Log:
sendfile() does currently not support SCTP sockets.
Therefore, fail the call.
"
https://svnweb.freebsd.org/changeset/base/358965
I'm updating FreeBSD base on the BB worker to include t
Kubilay Kocak added the comment:
The current test runs a try/finally without any exception handling, so even
minimal exception handling will cover a large swatch of potential issues.
CalledProcessError [1] returned by check_call() or check_output() appears to be
handy
[1]
https
Kubilay Kocak added the comment:
Not suggesting it's the *best* way, but for example, isn't there a way to
handle return codes from shell executions such as:
https://docs.python.org/3/library/subprocess.html#subprocess.CalledProcessError
Kubilay Kocak added the comment:
Updated FreeBSD CURRENT base, which removed libncurses. The bash port
installation needed to be rebuilt.
@Victor Can tests be skipped on the basis of required dependencies failing to
load/run?
--
status: open -> pend
Kubilay Kocak added the comment:
Testing with security.bsd.unprivileged_proc_debug=1
--
___
Python tracker
<https://bugs.python.org/issue39933>
___
___
Pytho
Kubilay Kocak added the comment:
Investigating
--
___
Python tracker
<https://bugs.python.org/issue39321>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
For our future reference/selves, GDB (currently 9.1 w/ python bindings) is now
installed on the two FreeBSD buildbot workers
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Kubilay Kocak :
--
assignee: docs@python ->
components: -2to3 (2.x to 3.x conversion tool), Build, Cross-Build,
Documentation, Extension Modules, FreeBSD, Installation, Interpreter Core,
Library (Lib), SSL, Tests, Unicode, ctypes
nosy: -docs@python, ko
Change by Kubilay Kocak :
--
nosy: -Alex.Willmer, ezio.melotti, vstinner
___
Python tracker
<https://bugs.python.org/issue24666>
___
___
Python-bugs-list mailin
Kubilay Kocak added the comment:
Looks OK now: https://buildbot.python.org/all/#/builders/214
If it fails again in the same manner, please re-open
--
assignee: -> koobs
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/i
Kubilay Kocak added the comment:
Rebuilding now
--
___
Python tracker
<https://bugs.python.org/issue39321>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
Identified a kernel/userland mismatch which may have caused this. Have
restarted the server and worker, and will rebuild
https://buildbot.python.org/all/#/builders/214/builds/152
--
___
Python tracker
<ht
Kubilay Kocak added the comment:
@Christian As current assignee, are you able to produce a test that fixes the
remaining issue (per msg357792)? I can rebuild OpenSSL on the worker at your
direction at any time to make the test fail again or provide you with an SSH
account to assist
Change by Kubilay Kocak :
--
nosy: -koobs
___
Python tracker
<https://bugs.python.org/issue39059>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
I had to rebuild the openssl (1.1.x) port on the worker that had test_ssl
failing in order to bring it back to green, so as not to hide new test failures.
If/when someone is able to produce a fix for the failing test, I am happy to
revert the openssl build
Kubilay Kocak added the comment:
In case it's relevant, I note the following:
The ssl module is built with -I/usr/local/include in the compile line.
Leaving aside:
- the warts of the build system, and
- the lack of specific --with-foo= semantics to allow providing
well(narrowly)-scoped
New submission from Kubilay Kocak :
Thank you for the heads-up David.
If you need OS support and don't have access to a FreeBSD install, I can
provide you with an SSH account to the servers that run the Python buildbots if
that would be helpful either now or in the future
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue38744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
@Victor
The guest running the worker was:
- running a FreeBSD build world (-j8)concurrently which is what was creating
additional load, though I've done this before and it hasn't caused timeouts.
- suspended/resumed (virtualbox save/restore) which may have
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue37531>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue38234>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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:
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:
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:
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
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:
@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:
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:
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:
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:
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:
See Also: #26826
--
___
Python tracker
<https://bugs.python.org/issue37959>
___
___
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:
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:
@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:
See Also: #31334
--
___
Python tracker
<https://bugs.python.org/issue37811>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue37811>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue37788>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue37664>
___
___
Python-bugs-list mailing list
Unsubscribe:
Kubilay Kocak added the comment:
Since this is likely a regression from issue 37664, which is still open, and
also contains the report, I'd close this issue in favour of the former. Having
regression reports in separate issues for still open in new/separate issues
tends to results in them
Kubilay Kocak added the comment:
Thanks for clarifying Victor
--
___
Python tracker
<https://bugs.python.org/issue37471>
___
___
Python-bugs-list mailin
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
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
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/issue36402>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue36624>
___
___
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:
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
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:
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
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
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
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
Change by Kubilay Kocak :
--
nosy: +koobs
___
Python tracker
<https://bugs.python.org/issue30458>
___
___
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/issue36632>
___
___
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:
1 - 100 of 163 matches
Mail list logo
