[Bug 274099] lang/python27 fails to compile on 14.0-BETA2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274099
Hiroo Ono changed:
What|Removed |Added
CC||hiroo.ono+free...@gmail.com
--- Comment #20 from Hiroo Ono ---
The code in the Makefile:
> .if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1400092 && (${SSL_DEFAULT} == base
> || ${SSL_DEFAULT:Mopenssl3*} )
does not properly deal with the openssl variation. For ssl's DEFAULT VERSION,
there are base, openssl111, openssl, openssl31 and openssl32. The above code
treats 'openssl' as 'openssl111', but security/openssl is actually openssl30.
It should be like:
> +.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1400092 && \
> (${SSL_DEFAULT} == base || ${SSL_DEFAULT} == openssl || \
> ${SSL_DEFAULT:Mopenssl3*} )
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
[Bug 274099] lang/python27 fails to compile on 14.0-BETA2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274099 --- Comment #21 from Hiroo Ono --- Created attachment 248352 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=248352&action=edit properly deal with the SSL_DEFAULT variations. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
Problem reports for python@FreeBSD.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- Open|205308 | devel/py-pip and devel/py-virtualenv don't aggree Open|242896 | lang/python*: Fail to package in poudriere (testp Open|257362 | lang/python3: Add link for python3-embed.pc where Open|258192 | devel/py-pyinstaller: Fails to run on 3.8+. Fix i Open|262759 | Python ports that install conflicting files in ge In Progress |262109 | Mk/Uses/python.mk: Improve CMake/Python integrati Open|264426 | www/mitmproxy: Update to 8.0.0 (<=7.0.4 vulnerabl Open|257353 | lang/python38: Intermittently fails to build unde Open|234981 | graphics/py-wand: Add DOCS option Pass MAINTAINER Open|224115 | devel/py-babel directory name != port name In Progress |258195 | lang/python38: Update to 3.8.12 Open|268043 | devel/py-twisted: Consumer ports fail to run: mod Open|264993 | www/mitmproxy: Update to 9.0.1 Open|260448 | [NEW] devel/py-aiosignal: Project to manage callb 14 problems total for which you should take action.
[Bug 276281] lang/python39 fails to include tzset in time module
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276281
Maxim Dounin changed:
What|Removed |Added
CC||mdou...@mdounin.ru
--- Comment #11 from Maxim Dounin ---
This seems to be a bug in tzcode, as recently updated from tzcode2010m to
tzcode2023c. The bug is still present upstream, checked most recent tzcode2024a
and github.
More specifically, the tzparse() function in localtime.c uses the
increment_overflow_time() function, assuming that the resulting variable
("janfirst" variable) is not changed when the overflow is detected:
https://github.com/eggert/tz/blob/e48c5b532a26e094db24a7de44c33786860c7ae1/localtime.c#L1187
This assumption, however, is not true if increment_overflow_time() is
implemented using C23 ckd_add() or __builtin_add_overflow(): the overflowed
result is stored to the variable instead. This manifests itself on systems with
32-bit time_t, where the loop in question reaches the overflow.
The most trival workaround I can see would be to compile localtime.c with
HAVE_STDCKDINT_H defined to 0, so that C implementation of
increment_overflow_time() is used instead of __builtin_add_overflow(). The C
implementation does not change the resulting variable on overflow, so the
assumption of the code holds true.
Here is a simple test with the most recent tzcode sources, tzcode2024a, on
FreeBSD 13.2-RELEASE-p8 i386:
$ make date
cc -O2 -pipe -c date.c -o date.o
printf '%s\n' >tzdir.h.out '#ifndef TZDEFAULT' '# define TZDEFAULT
"/etc/localtime" /* default zone */' '#endif' '#ifndef TZDIR' '# define
TZDIR "/usr/share/zoneinfo" /* TZif directory */' '#endif'
mv tzdir.h.out tzdir.h
cc -O2 -pipe -c localtime.c -o localtime.o
cc -O2 -pipe -c strftime.c -o strftime.o
cc -O2 -pipe -c asctime.c -o asctime.o
cc -o date -O2 -pipe date.o localtime.o strftime.o asctime.o
$ TZ=AEST-10AEDT-11,M10.5.0,M3.5.0 ./date -r 1044144000
Sun Feb 2 10:00:00 AEST 2003
As can be seen from "10:00:00 AEST", the result is broken. The same code,
recompiled with HAVE_STDCKDINT_H set to 0:
$ touch localtime.c
$ make date CFLAGS=-DHAVE_STDCKDINT_H=0
cc -DHAVE_STDCKDINT_H=0 -c localtime.c -o localtime.o
cc -o date -DHAVE_STDCKDINT_H=0 date.o localtime.o strftime.o asctime.o
$ TZ=AEST-10AEDT-11,M10.5.0,M3.5.0 ./date -r 1044144000
Sun Feb 2 11:00:00 AEDT 2003
Now the result is correct, "11:00:00 AEDT".
It would be great if someone can take a look and implement a workaround.
--
You are receiving this mail because:
You are the assignee for the bug.
