Re: [Bug]devel/py-buildbot/buildbot lacks dependency on sysutils/py-packaging
On Fri, 24 May 2024 13:07:16 +0200 Landry Breuil wrote: > Le Fri, May 24, 2024 at 12:24:44PM +0200, Matthias Pitzl a écrit : > > I think theres a missing run dependency on sysutils/py-packaging. > > After installing py3-packaging is was able to continue with the buildbot > > upgrade > > without any further problems. > > thanks for the report, i'll check and fix that. > > Is the same problem as my report about py3-llvm failing after upgrade to OpenBSD-7.4, https://marc.info/?l=openbsd-ports&m=171579318532378 ? - Jules -- http://op59.net
Problems with py3-llvm after sysupgrade to 7.4
After sysupgrade from 7.3 to 7.4 and `pkg_add -u`, the `py3-llvm` package seems to be broken. In Python, `import clang.cindex` now fails: # python3 -c 'import clang.cindex' ModuleNotFoundError: No module named 'clang' My `locate` (whose database i think hasn't been updated since before i upgraded) says that `cindex.py` is at: /usr/local/lib/python3.10/site-packages/clang/cindex.py But `pkg_info -L py3-llvm` says: Information for inst:py3-llvm-13.0.0p4 Files: /usr/local/llvm13/lib/python3.10/site-packages/clang/__init__.py /usr/local/llvm13/lib/python3.10/site-packages/clang/__pycache__/__init__.cpython-310.pyc /usr/local/llvm13/lib/python3.10/site-packages/clang/__pycache__/cindex.cpython-310.pyc /usr/local/llvm13/lib/python3.10/site-packages/clang/__pycache__/enumerations.cpython-310.pyc /usr/local/llvm13/lib/python3.10/site-packages/clang/cindex.py /usr/local/llvm13/lib/python3.10/site-packages/clang/enumerations.py So maybe the package has changed from installing into: /usr/local/lib/python3.10/site-packages/ to installing into: /usr/local/llvm13/lib/python3.10/site-packages/ ? If i set `PYTHONPATH=/usr/local/llvm13/lib/python3.10/site-packages`, `import clang.cindex` works, but attempting to use it in Python with `clang.cindex.Index.create()` fails: # PYTHONPATH=/usr/local/llvm13/lib/python3.10/site-packages python3 -c 'import clang.cindex; clang.cindex.Index.create()' Traceback (most recent call last): File "/usr/local/llvm13/lib/python3.10/site-packages/clang/cindex.py", line 4174, in get_cindex_library library = cdll.LoadLibrary(self.get_filename()) File "/usr/local/lib/python3.10/ctypes/__init__.py", line 452, in LoadLibrary return self._dlltype(name) File "/usr/local/lib/python3.10/ctypes/__init__.py", line 374, in __init__ self._handle = _dlopen(self._name, mode) OSError: File not found During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/usr/local/llvm13/lib/python3.10/site-packages/clang/cindex.py", line 2699, in create return Index(conf.lib.clang_createIndex(excludeDecls, 0)) File "/usr/local/llvm13/lib/python3.10/site-packages/clang/cindex.py", line 212, in __get__ value = self.wrapped(instance) File "/usr/local/llvm13/lib/python3.10/site-packages/clang/cindex.py", line 4147, in lib lib = self.get_cindex_library() File "/usr/local/llvm13/lib/python3.10/site-packages/clang/cindex.py", line 4180, in get_cindex_library raise LibclangError(msg) clang.cindex.LibclangError: File not found. To provide a path to libclang use Config.set_library_path() or Config.set_library_file(). self.get_filename()='libclang.so' Running Python with `ktrace -i --t cni` and then using `kdump` doesn't seem to show to any offending libclang path but i hacked /usr/local/llvm13/lib/python3.10/site-packages/clang/cindex.py to show the file it's looking for, and it's just `libclang.so`. On my machine there is: /usr/local/llvm13/lib/libclang.so.8.2 and setting LD_LIBRARY_PATH to `/usr/local/llvm13/lib` makes things work: # LD_LIBRARY_PATH=/usr/local/llvm13/lib PYTHONPATH=/usr/local/llvm13/lib/python3.10/site-packages python3 -c 'import clang.cindex; clang.cindex.Index.create()' Presumably something equivalent to setting PYTHONPATH and LD_LIBRARY_PATH system-wide should be happening when py3-llvm is installed, but it's not happening on my machine for some reason? Any help/suggestions would be appreciated. Thanks, - Jules dmesg is: OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16972566528 (16186MB) avail mem = 16438452224 (15676MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (68 entries) bios0: vendor LENOVO version "G2ETB1WW (2.71 )" date 03/09/2018 bios0: LENOVO 2324FV6 efi0 at bios0: UEFI 2.3.1 efi0: Lenovo rev 0x2710 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI POAT SSDT SSDT DMAR UEFI DBG2 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz, 2594.22 MHz, 06-3a-09, patch 0021 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way
Re: devel/gmake default CXX=g++ should be c++ ?
On Fri, 8 Sep 2023 11:05:48 +0200 Christian Weisgerber wrote: > Julian Smith: > > > devel/gmake defaults to CC=cc but CXX=g++. > > Not any more. Starting with 4.4.1, gmake sets the CXX default to > the C++ compiler it found at configure time, i.e., "c++" in our > case. Great, in that case it sounds like this problem will solve itself. > That doesn't even apply to 4.4.1. I think you're on 7.3 and not > on -current. Apologies, i haven't yet managed to switch to current. - Jules -- http://op59.net
devel/gmake default CXX=g++ should be c++ ?
devel/gmake defaults to CC=cc but CXX=g++. It doesn't seem to make sense to mix `cc`, the system C compiler (typically clang-based) with `g++`, the non-system GNU C++ compiler. I've been routinely running gmake with a `CXX=c++` prefix in order to build various C/C++ projects. Here's a new patch file that fixes the port for me: /usr/ports/devel/gmake/patches/patch-src_default_c Index src/default.c --- src/default.c.orig +++ src/default.c @@ -530,7 +530,7 @@ "OBJC", "gcc", #else "CC", "cc", -"CXX", "g++", +"CXX", "c++", "OBJC", "cc", #endif - Jules -- http://op59.net
Re: Port for nedit-ng text editor
On Tue, 04 Jul 2023 11:14:03 +0200 Omar Polo wrote: > here's a diff against your makefile and an updated tarball attached. > I've just briefly tried the port, the gui pops up and i can type > things. Seems to work for me :-) Many thanks for answering all my questions and for the updated port. I'll submit an updated port after the next release of nedit-ng, which will hopefully be soon. - Jules -- http://op59.net
Port for nedit-ng text editor
I've made a first attempt at a port for the editor nedit-ng, a
re-implementation of nedit using Qt instead of motif.
The port is available at: http://op59.net/nedit-ng.tgz
The website for nedit-ng is: https://github.com/eteran/nedit-ng
For now the port uses placeholder version 2023.1rc1, and a hard-coded
git sha. I'm expecting to update things to use a new release from the
maintainer soon.
The port Makefile is just 25 lines and there are no patches.
I ran into a few minor issues while making the port:
* I had to get the following patch pushed to the project's
import/CMakeLists.txt:
if(${X11_FOUND})
if(TARGET_PLATFORM_MACOS)
link_directories(/usr/X11/lib)
link_directories(/opt/X11/lib)
endif()
+if(TARGET_PLATFORM_OPENBSD)
+link_directories(/usr/X11R6/lib)
+endif()
endif()
Is there a better way of doing this - for example does cmake on OpenBSD
already know where to find X11 libraries?
* Could /usr/ports/infrastructure/templates/Makefile.template's
CONFIGURE_STYLE section mention cmake?
* Issues in https://www.openbsd.org/faq/ports/guide.html:
5. Fill in DISTNAME
* It wasn't initially clear to me that this must end in a numeric
version number conforming to packages-specs(7).
This would have been useful because getting this wrong caused
obscure errors much later from `make package`, saying:
pkg_create: Can't call method "p" on an undefined value
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2140
'/usr/ports/packages/amd64/all/nedit-ng-a5be3d1e.tgz': @trap
"cd /usr/ports/...) *** Error 2 in .
(/usr/ports/infrastructure/mk/bsd.port.mk:2621
'_internal-package': @case X${_DEPENDS_CACHE} in X)
_DEPENDS_CACHE=$( mktem...) *** Error 2 in
/usr/ports/editors/nedit-ng
(/usr/ports/infrastructure/mk/bsd.port.mk:2600 'package':
@lock=nedit-ng-a5be3d1e; export _LOCKS...)
13. Try setting SEPARATE_BUILD.
* How does one do this?
17. Put a longer description of the port into pkg/DESCR
* I think this is required; perhaps that should have been obvious,
but i got this wrong at first.
22. Create pkg/PLIST
* `make update-plist` failed with `DON'T BUILD PORTS AS ROOT!`.
Most of the other `make` commands needed to be run as root, so it
might be good to clarify this.
Thanks for any help or suggestions,
- Julian
--
http://op59.net
Re: Titlebar in firefox and tor-browser
On Tue, 31 Jan 2023 18:05:50 -0500 Morgan Aldridge wrote: > On Tue, Jan 31, 2023 at 5:20 PM Julian Smith wrote: > > > > On OpenBSD 7.2 with Fvwm2 (fvwm2-2.6.9p1), Firefox (firefox-107.0) > > and Tor-browser (tor-browser-11.5.6) both appear to not set the > > window titlebar to the current tab's text. > > > > Instead, the titlebar is always set to "Mozilla Firefox" or "Tor > > Browser". > > > > Is this expected? Is there any way to make the titlebar show the > > current Tab's text? > > > > I think OpenBSD 7.0 used to set the titlebar text as expected. I > > had a look in /usr/ports/www/mozilla-firefox/, but couldn't see > > anything obvious. > > I can confirm this same functionality on amd64/7.2-stable with MLVWM > (mlvwm-0.9.3) and Firefox (firefox-107.0.1). As the MLVWM developer > (and port maintainer), I know that it, like fvwm in base, only draws > the window title from `WM_TITLE` (C_STRING, STRING, or > COMPOUND_STRING), not the newer `_NET_WM_NAME` (UTF8_STRING) > extension. Due to incompatible licensing, I haven't perused the source > for fvwm2 from ports, so it might differ. My guess is that Firefox has > stopped setting `WM_TITLE` with the tab name and only sets it in the > UTF-8 `_NET_WM_NAME`. > > I ran into a related regression in SDL[0][1] a while ago, which has > since been fixed, where they stopped setting `WM_TITLE` because they > felt it was superseded by `_NET_WM_NAME`. According to the ICCCM spec, > `WM_TITLE` should always be set, and for window managers supporting > NetWM/EWMH (Extended Window Manager Hints) where `X_HAVE_UTF8_STRING`, > the window manager should use `_NET_WM_NAME` instead. Unfortunately, > many application developers have decided (incorrectly, IMHO) that this > means `_NET_WM_NAME` replaces `WM_TITLE` and doesn't need to be set > anymore (because it's harder... it's not UTF-8, so they have to check > encodings and encode the string correctly & appropriately.) I know > Thomas Adam, one of the fvwm3 developers, and I have discussed this > particular interpretation before too. > > Running `xprop` on a Firefox window with the OpenBSD homepage loaded > confirms my suspicions: > > WM_NAME(STRING) = "Mozilla Firefox" > _NET_WM_NAME(UTF8_STRING) = "OpenBSD — Mozilla Firefox" > > So, I'd suggest submitting a bug report upstream w/Firefox. (I believe > the Firefox codebase is used for Thunderbird, as well, so I suspect > this issue affects it too.) Many thanks for this. I get the same results with xprop. I had a look for WM_NAME and there's already a Firefox bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1679182. One of the comments mentions a suggested workaround is to set LC_ALL=en_US.UTF-8, and this fixes the problem for me: LC_ALL=en_US.UTF-8 firefox (I think https://www.openbsd.org/faq/faq10.html implies that `en_US.UTF-8` is supported on OpenBSD, but any suggestions about a better workaround would be welcome.) More generally, it looks like the problem is caused by Firefox changing around version 0.83 to using a non-ascii dash in its titlebar text. It uses `gtk_window_set_title()` to set the titlebar. I guess the implication is that GTK is not setting WM_NAME if the text is not pure ascii and the locale is not utf8. It looks like gtk2 is obsolete though, so i haven't submitted a bug report. BTW i tried fvwm3 but it doesn't appear to behave differently from fvwm2 here. - Julian -- http://op59.net/
Titlebar in firefox and tor-browser
On OpenBSD 7.2 with Fvwm2 (fvwm2-2.6.9p1), Firefox (firefox-107.0) and Tor-browser (tor-browser-11.5.6) both appear to not set the window titlebar to the current tab's text. Instead, the titlebar is always set to "Mozilla Firefox" or "Tor Browser". Is this expected? Is there any way to make the titlebar show the current Tab's text? I think OpenBSD 7.0 used to set the titlebar text as expected. I had a look in /usr/ports/www/mozilla-firefox/, but couldn't see anything obvious. Thanks, - Julian -- http://op59.net/
Re: Python3 tarfile PAX/GNU mtime confusion
On Sun, 25 Sep 2022 23:01:37 +0100 Stuart Henderson wrote: > Newer openbsd handles this. > Thanks for this; i'll upgrade. - Julian -- http://op59.net
Python3 tarfile PAX/GNU mtime confusion
I'm using OpenBSD 7.0 GENERIC.MP#232 amd64.
OpenBSD's tar and pax seem to always think mtimes are zero when
extracting tar files created by OpenBSD's python3 (python-3.8.12).
These tar files have correct mtimes when opened by python3 itself or
read by gtar from ports. Similarly, Linux tar sees correct mtimes.
`file` claims the tar files are 'POSIX tar archive'.
OpenBSD's python2 doesn't seem to have this probelem - it creates tar
files that work correctly with OpenBSD's tar and pax.
When loading a python3-created tar file in python3, it says the format
is 2, which is tarfile.PAX_FORMAT, so i would have expected things
to work with tar and pax. Python-3.8 changed the default from
GNU_FORMAT to PAX_FORMAT
(https://docs.python.org/3/library/tarfile.html#tar-formats "Changed in
version 3.8: The default format for new archives was changed to
PAX_FORMAT from GNU_FORMAT.").
[So could it be possible that python3 is actually generating GNU_FORMAT
tar archives, but claiming that they are PAX_FORMAT? I've had a quick
look at Python-3.8.12/Lib/tarfile.py and it doesn't seem to have any
obvious error like this.]
The attached tarmtime.py script demonstrates the problem - it creates
various tar archives and extracts with `tar` and `pax` and shows the
`Jan 1 1970` mtimes.
Thanks for any advice here,
- Julian
--
http://op59.net
#!/usr/bin/env python3
import io
import os
import sys
import tarfile
import time
def system( command):
print( 'running: %s' % command)
sys.stdout.flush()
return os.system( command)
with tarfile.open('tarmtime1.tgz', 'w:gz') as t:
t.add( 'tarmtime.py', 'tarmtime1/tarmtime.py')
system( 'tar -xzf tarmtime1.tgz')
system( 'ls -l tarmtime1/*')
with tarfile.open('tarmtime2.tar', 'w') as t:
t.add( 'tarmtime.py', 'tarmtime2/tarmtime.py')
system( 'tar -xf tarmtime2.tar')
system( 'ls -l tarmtime2/*')
if 1:
with tarfile.open('tarmtime2.tar', 'r') as t:
ti = t.getmember( 'tarmtime2/tarmtime.py')
print( 'ti: name=%s size=%s mtime=%s' % (ti.name, ti.size, ti.mtime))
with tarfile.open('tarmtime3.tar', 'w') as t:
data = b'123'
ti = tarfile.TarInfo( 'tarmtime3/foo')
ti.size = len( data)
#ti.mtime = time.time()
data2 = io.BytesIO(data)
t.addfile(ti, data2)
ti = tarfile.TarInfo( 'tarmtime3/bar')
ti.size = len( data)
ti.mtime = time.time()
data2 = io.BytesIO(data)
t.addfile(ti, data2)
system( 'tar -xf tarmtime3.tar')
system( 'ls -l tarmtime3/*')
system( 'pax -r -f tarmtime3.tar')
system( 'ls -l tarmtime3/*')
system( 'rm -r tarmtime3')
system( 'gtar -xf tarmtime3.tar')
system( 'ls -l tarmtime3/*')
if 1:
with tarfile.open('tarmtime3.tar', 'r') as t:
ti = t.getmember( 'tarmtime3/foo')
print( 'ti: name=%s size=%s mtime=%s' % (ti.name, ti.size, ti.mtime))
ti = t.getmember( 'tarmtime3/bar')
print( 'ti: name=%s size=%s mtime=%s' % (ti.name, ti.size, ti.mtime))
print( 'Cleanup with: rm -r tarmtime1* tarmtime2* tarmtime3*')
pkg-config for OpenSceneGraph omits /usr/X11R6/include
I think "pkg-config --cflags openscenegraph" may be missing required
include path /usr/X11R6/include/.
On OpenBSD-6.7 "pkg-config --cflags openscenegraph" outputs:
-I/usr/local/include
But some openscenegraph headers end up including gl headers, which are
in /usr/X11R6/include.
Here's a minimal example of it going wrong:
osgtest.cpp:
#include
int main(void)
{
}
Compile command:
c++ -c osgtest.cpp `pkg-config --cflags openscenegraph`
Output:
In file included from osgtest.cpp:1:
In file included from /usr/local/include/osg/Camera:17:
In file included from /usr/local/include/osg/Transform:17:
In file included from /usr/local/include/osg/Group:17:
In file included from /usr/local/include/osg/Node:19:
In file included from /usr/local/include/osg/StateSet:18:
In file included from /usr/local/include/osg/StateAttribute:20:
In file included from /usr/local/include/osg/Shader:25:
In file included from /usr/local/include/osg/GLExtensions:18:
In file included from /usr/local/include/osg/GLDefines:25:
/usr/local/include/osg/GL:113:10: fatal error: 'GL/gl.h' file not found
#include
^
1 error generated.
"locate GL/gl.h" shows: /usr/X11R6/include/GL/gl.h
This breaks Flightgear's cmake build on OpenBSD. I'm hoping to update
OpenBSD's Flightgear port at some point; i have it building ok using a
custom build script, but would be good to have it build using the
native cmake system.
One can add "pkg-config --sflags gl" to get the right flags - this
outputs "-I/usr/X11R6/include -I/usr/X11R6/include/libdrm". I guess
this should probably be unnecessary though? and certainly the
Flightgear cmake build works on other systems without it.
Thanks,
- Jules
--
http://op59.net
Re: Switch to LLVM 10 imminent
I'd like to try llvm-10 (latest git master), but when i try to build on OpenBSD-6.7 (amd64), but i get build failures such as: llvm-project/libcxxabi/../libcxx/include/__config:1150:6: error: "No thread API"). Is there a set of patches somewhere that i can use? [ports/lang/clang/ doesn't seem to have anything relevant.] Thanks, - Jules On Sat, 1 Aug 2020 22:14:03 +0200 Christian Weisgerber wrote: > I don't think there was any public announcement, but most will have > surmised it by now: The base compiler will soon switch from LLVM 8 > to LLVM 10 on all CLANG_ARCHS. This also concerns the linker on > LLD_ARCHS. > > This will cause a certain amount of breakage in the ports tree. > We are working on it now. > > I have uploaded the failure logs from early builds at > http://build-failures.rhaalovely.net/amd64-clang/ > > Note that the devel/pango failure prevented GTK and Qt and thus a > huge chunk of the tree from building. More meaningful logs should > appear within 24 hours. > > Principal sources of build failures: > * C++ incompatibilities, as always. > * Use of -Werror breaking on new warnings. > * Linking errors. > > There are also silly problems such as configure scripts misrecognizing > LLVM 10 due to changes in the output of "cc -v" or "cc -dumpversion". > > Anyway, I would like to encourage more people to join into the effort. > (And yes, I'm aware that there's no publically available snapshot > or patchset with LLVM 10...) > -- http://op59.net
