Change by Eitan Adler :
--
nosy: +eitan.adler
___
Python tracker
<https://bugs.python.org/issue24955>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eitan Adler :
--
nosy: +eitan.adler
___
Python tracker
<https://bugs.python.org/issue36596>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eitan Adler :
--
nosy: +eitan.adler
___
Python tracker
<https://bugs.python.org/issue33597>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33657>
___
_
Eitan Adler <li...@eitanadler.com> added the comment:
yeah, I was looking at that too. I think someone else modified related files
but never ran a regen (or did so with different tooling than I).
Even on master, my regen results in c
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6752
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Eitan Adler <li...@eitanadler.com>:
There is an option for --with-c-locale-warning which was turned into a run-time
option in eb81795d7d3a8c898fa89a376d63fc3bbfb9a081. The configuration should be
cleaned up.
--
messages: 317676
nosy: eitan.adler
priority:
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33647>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33012>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32911>
___
_
Eitan Adler <li...@eitanadler.com> added the comment:
FTR this was entirely self-inflicted: I had a setting which explicitly asked
for non-posix gmtime.
That said, leaving this open for the same reasons as above.
--
___
Python tracke
Eitan Adler <li...@eitanadler.com> added the comment:
Relevant conversation:
https://lists.freebsd.org/pipermail/freebsd-standards/2018-May/003714.html
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Eitan Adler <li...@eitanadler.com> added the comment:
Thanks! I've confirmed this is the case on my system and will be starting a
conversation about fixing it.
In the meantime I am leaving this bug open since we may want to detect this
case in python and c
Change by Eitan Adler <li...@eitanadler.com>:
--
components: +Library (Lib)
type: -> behavior
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Eitan Adler <li...@eitanadler.com>:
How to reproduce:
∴cat bad.py
import time
import calendar
one = time.gmtime(1234567899)
two = calendar.timegm(time.gmtime(1234567899))
three = time.gmtime(two)
print(one)
print(two)
print(three)
print(one == three)
Expected be
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue1294959>
___
_
Eitan Adler <li...@eitanadler.com> added the comment:
There are few if any valid reasons to make direct use of the syscall from
python code. Portable code would have to reimplement most of the logic from
`getentropy` in any case.
What you're usecase for the direct s
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30411>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30104>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33531>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33528>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6563
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue13590>
___
_
Eitan Adler <li...@eitanadler.com> added the comment:
copying and adapting my comments on the PR:
Strict Prototypes is correct and helpful for C. That said, the way it is
currently implemented, by checking for the compiler in CC is sub-optimal at
best.
CC ought to always be a C co
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue9031>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue5755>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eitan.adler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue1222585>
___
_
Change by Eitan Adler <li...@eitanadler.com>:
--
title: build system runs when it merely link -> build system runs when it may
merely link
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Eitan Adler <li...@eitanadler.com>:
--
pull_requests: +6528
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33486>
___
_
Eitan Adler <li...@eitanadler.com> added the comment:
> If these changes are autogenerated, I would prefer that a trusted core
> developer create a PR.
They are fully auto-generated (using autoupdate and autoreconf). It someone
else wants to submit the PR, feel free.
> Is
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6527
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Eitan Adler <li...@eitanadler.com>:
autotools has a standard macro for defining HAVE_LONG_DOUBLE. Lets use it
rather than using our own.
--
components: Build
messages: 316615
nosy: eitan.adler
priority: normal
severity: normal
status: open
title: use more st
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6525
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Eitan Adler <li...@eitanadler.com>:
confg.sub has been updated upstream. lets pull it in.
--
components: Build
messages: 316612
nosy: eitan.adler
priority: normal
severity: normal
status: open
title: update.config.sub
type: enhan
Eitan Adler <li...@eitanadler.com> added the comment:
On any system where "gcc" is not the correct compiler to use. If it does not
exist, is too old, points to the incorrect compiler, etc.
Concretely I have two such systems:
- on one, "gcc" does not exist
- on t
New submission from Eitan Adler <li...@eitanadler.com>:
There is a ton of logic in configure.ac to detect pthreads support. There is a
standard macro to use instead:
https://www.gnu.org/software/autoconf-archive/ax_pthread.html#ax_pthread
In order to simplify our pthread logic we shoul
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6475
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6473
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Eitan Adler <li...@eitanadler.com>:
markdownlint is, as the name implies, a tool for linting markdown files.
The current template has the following lint warnings:
```
./.github/PULL_REQUEST_TEMPLATE.md:8: MD031 Fenced code blocks should be
surrounded by blank
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6470
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Eitan Adler <li...@eitanadler.com>:
There are few if any functional changes, but this is helpful when making other
changes to the build system.
--
components: Build
messages: 316477
nosy: eitan.adler
priority: normal
severity: normal
status: open
title:
Eitan Adler <li...@eitanadler.com> added the comment:
I believe I have removed the regen step from all my patches. I will separately
upgrade the generated files (particularly since it is only a minor version
bump).
--
___
Python tracke
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6469
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Eitan Adler <li...@eitanadler.com> added the comment:
The unrelated changes are likely due to the "regen" step. I am using newer
tools than previously used. It is unclear to me why we include generated files
in the repository. Some projects prefer this to avoid the need to
New submission from Eitan Adler <li...@eitanadler.com>:
The current "autoconf" target is suboptimal in a few ways:
- it does not use a quoted srcdir
- it uses autoheader and autoconf instead of autoreconf
- it does act sanely if 'cd' fails.
--
components: Build
messa
Change by Eitan Adler <li...@eitanadler.com>:
--
title: autoconf target does not -> autoconf target does not behave correctly
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6468
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Eitan Adler <li...@eitanadler.com>:
The build system attempts to run certain test code when it can actually just
link the code. This is a minor performance optimization but is really a
semantic correctness issue.
--
components: Build
messages: 31647
Change by Eitan Adler <li...@eitanadler.com>:
--
keywords: +patch
pull_requests: +6466
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Eitan Adler <li...@eitanadler.com>:
configure.ac requires explicit configuration for finding the preferred
compiler. This results in a non-native way of configuring the system, and does
not actually work on most platforms.
Expected behavior:
CC is used to discover
New submission from Eitan Adler <li...@eitanadler.com>:
There are a number of incorrect items in python's build system.
Expected behavior:
- CC is correctly report as the compiler, and without any additional options
- CFLAGS is correctly reported for the required flags to the co
Eitan Adler (bad account) <eitan+bo...@eitanadler.com)> added the comment:
closing this as I created under a bad account and can't find a way to merge
them.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
New submission from Eitan Adler <ei...@eitanadler.com>:
There are a number of incorrect items in python's build system.
Expected behavior:
- CC is correctly report as the compiler, and without any additional options
- CFLAGS is correctly reported for the required flags to the co
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eadler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20353>
___
__
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eadler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue13829>
___
__
Change by Eitan Adler <li...@eitanadler.com>:
--
nosy: +eadler
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27126>
___
__
Changes by Eitan Adler li...@eitanadler.com:
--
nosy: +eadler
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16605
___
___
Python-bugs-list mailing
57 matches
Mail list logo
