Re: net ads testjoin coredumped with "bogus pointer". OpenBSD 6.6. samba 4.8.12
Nothing changed net(85330) in free(): bogus pointer (double free?) 0x Abort trap (core dumped) пн, 7 окт. 2019 г. в 22:18, dmitry.sensei : > No problem > > пн, 7 окт. 2019 г., 16:17 Klemens Nanni : > >> jca@ sent an update to samba 4.9.x along its request for testing to >> ports@ on 04.10.2019, can you check whether the new version still has >> this problem? >> > -- Dmitry Orlov
[ports-gcc] Unbreak geo/gpsbabel
Hi,
I was trying to build qt5^W geo/qlandkartegt with naddy's latest fix on
macppc, but i hit that:
> http://build-failures.rhaalovely.net//sparc64/2019-10-06/geo/gpsbabel.log
> http://build-failures.rhaalovely.net//powerpc/2019-09-17/geo/gpsbabel.log
I found out that landry met the issue with print/poppler, i quote the
commit [0] message:
> Add ${MODGCC4_CPPLIBDEP} to LIB_DEPENDS-*, changes nothing for clang
> archs, but fixes the dreaded 'Missing library for estdc++>=17.0' error
> message at pkg_create on other archs. COMPILER_LIBCXX is in WANTLIB-*,
> but nothing brought it into context, as ${MODGCC4_CPPLIBDEP} is only in
> LIB_DEPENDS, which isnt inherited by LIB_DEPENDS-* here.
I bumped REVISION as this version was already built during a previous
macppc fix for qlandkartegt iirc.
This builds fine on amd64 and macppc [1].
Two ports depend on it: geo/qlandkartegt (it's still building) and
geo/viking
naddy, sthen: i let you decide if it's critical enough to get
committed, otherwise i'll ping post-unlock :)
Charlène.
[0]
https://github.com/openbsd/ports/commit/10eedd1e2cf2afea1bcbe41e374ce44fb7be4a8a
[1] https://bin.charlenew.xyz/gpsbabel.missinglib.log
Index: Makefile
===
RCS file: /cvs/ports/geo/gpsbabel/Makefile,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 Makefile
--- Makefile3 Sep 2019 13:48:25 - 1.35
+++ Makefile9 Oct 2019 23:41:05 -
@@ -12,6 +12,9 @@ DISTNAME= gpsbabel-${VERSION}
PKGNAME-main= gpsbabel-${VERSION}
PKGNAME-tk=gpsbabel-tk-${VERSION}
PKGNAME-qt=gpsbabel-qt-${VERSION}
+REVISION-main= 0
+REVISION-tk= 0
+REVISION-qt= 0
CATEGORIES=geo
HOMEPAGE= https://www.gpsbabel.org/
@@ -34,7 +37,8 @@ MULTI_PACKAGES= -main -tk -qt
MODULES= devel/qmake x11/tk x11/qt5
MODQMAKE_PROJECTS =gui/app.pro
-LIB_DEPENDS-main= devel/libusb-compat \
+LIB_DEPENDS-main= ${MODGCC4_CPPLIBDEP} \
+ devel/libusb-compat \
devel/shapelib
cWANTLIB = c m pthread
@@ -43,8 +47,9 @@ WANTLIB-tk =
WANTLIB-qt += GL Qt5Core Qt5Gui Qt5Network Qt5WebKit Qt5WebKitWidgets
WANTLIB-qt += Qt5Widgets Qt5Xml ${COMPILER_LIBCXX} ${cWANTLIB}
-LIB_DEPENDS-tk=
-LIB_DEPENDS-qt=x11/qt5/qtwebkit
+LIB_DEPENDS-tk=${MODGCC4_CPPLIBDEP}
+LIB_DEPENDS-qt=${MODGCC4_CPPLIBDEP} \
+ x11/qt5/qtwebkit
PKG_ARCH-tk= *
RUN_DEPENDS-tk=geo/gpsbabel \
${MODTK_RUN_DEPENDS}
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/10/09 17:12:39 Modified files: net/fastnetmon : Makefile Log message: fastnetmon: use __atomic* primitives instead of __sync* ones This fixes the build on macppc, and probably hppa. OK naddy@ jasper@ (maintainer)
Re: math/py-pandas build failure: scm_integration
On Wed, Oct 09, 2019 at 12:12:32PM +0100, Stuart Henderson wrote:
> Anyone see where this is coming from? I don't see anything about
> setuptools_scm.integration in py-pandas itself.
Oooohh... that's a known issue.
It is random and appears with other ports as well.
There is something down the dependency chain that finds this installed and
somewhat ends up depending on it.
I have never foudn the guilty one...
> running install_egg_info
> running egg_info
> writing requirements to pandas.egg-info/requires.txt
> writing pandas.egg-info/PKG-INFO
> writing top-level names to pandas.egg-info/top_level.txt
> writing dependency_links to pandas.egg-info/dependency_links.txt
> Traceback (most recent call last):
> File "./setup.py", line 746, in
> **setuptools_kwargs)
> File "/usr/local/lib/python2.7/site-packages/setuptools/__init__.py", line
> 145, in setup
> return distutils.core.setup(**attrs)
> File "/usr/local/lib/python2.7/distutils/core.py", line 151, in setup
> dist.run_commands()
> File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
> self.run_command(cmd)
> File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
> File
> "/usr/local/lib/python2.7/site-packages/setuptools/command/install.py", line
> 61, in run
> return orig.install.run(self)
> File "/usr/local/lib/python2.7/distutils/command/install.py", line 575, in
> run
> self.run_command(cmd_name)
> File "/usr/local/lib/python2.7/distutils/cmd.py", line 326, in run_command
> self.distribution.run_command(command)
> File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
> File
> "/usr/local/lib/python2.7/site-packages/setuptools/command/install_egg_info.py",
> line 34, in run
> self.run_command('egg_info')
> File "/usr/local/lib/python2.7/distutils/cmd.py", line 326, in run_command
> self.distribution.run_command(command)
> File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
> File
> "/usr/local/lib/python2.7/site-packages/setuptools/command/egg_info.py", line
> 296, in run
> self.find_sources()
> File
> "/usr/local/lib/python2.7/site-packages/setuptools/command/egg_info.py", line
> 303, in find_sources
> mm.run()
> File
> "/usr/local/lib/python2.7/site-packages/setuptools/command/egg_info.py", line
> 534, in run
> self.add_defaults()
> File
> "/usr/local/lib/python2.7/site-packages/setuptools/command/egg_info.py", line
> 574, in add_defaults
> rcfiles = list(walk_revctrl())
> File "/usr/local/lib/python2.7/site-packages/setuptools/command/sdist.py",
> line 20, in walk_revctrl
> for item in ep.load()(dirname):
> File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py",
> line 2434, in load
> return self.resolve()
> File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py",
> line 2440, in resolve
> module = __import__(self.module_name, fromlist=['__name__'], level=0)
> ImportError: No module named setuptools_scm.integration
>
>
--
Antoine
sparc64 bulk build report
bulk build on sparc64-0.ports.openbsd.org started on Sun Oct 6 12:24:46 MDT 2019 finished at Wed Oct 9 16:32:43 MDT 2019 lasted 03D21h07m done with kern.version=OpenBSD 6.6 (GENERIC.MP) #80: Sun Oct 6 00:03:51 MDT 2019 built packages:9753 Oct 6:6358 Oct 7:1717 Oct 8:1553 Oct 9:124 critical path missing pkgs: http://build-failures.rhaalovely.net//sparc64/2019-10-06/summary.log build failures: 60 http://build-failures.rhaalovely.net//sparc64/2019-10-06/audio/gradio.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/cad/magic.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/cad/netgen.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/cad/qucs.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/chinese/libpinyin.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/comms/xastir.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/devel/kdevelop.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/devel/libcoap.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/devel/py-unicorn,python3.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/devel/rebar,erlang21.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/emulators/BasiliskII.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/emulators/citra.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/emulators/fs-uae.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/emulators/gambatte,-main.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/emulators/nestopia,-libretro.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/emulators/ppsspp.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/emulators/vbam.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/games/dxx-rebirth.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/games/love.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/games/mvdsv.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/games/pokerth.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/games/postal.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/games/stone-soup.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/games/xevil.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/geo/gpsbabel.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/geo/spatialite/gis.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/graphics/colord-gtk.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/graphics/openimageio.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/lang/apl.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/lang/janet.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/mail/kopano/core.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/math/coq.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/math/kst.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/math/py-scikit-learn.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/multimedia/mkvtoolnix.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/multimedia/synfig.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/net/bitcoin,no_x11.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/net/dleyna/renderer.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/net/dleyna/server.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/net/litecoin.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/net/mutella.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/net/routinator.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/net/telegram-purple.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/net/toxcore.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/productivity/gnucash.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/security/libfprint.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/security/sslscan,openssl.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/telephony/iaxclient.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/telephony/pjsua,-main.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/gnome/libgweather.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/gnome/tracker.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/gnome/zenity.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/gtk+4,-cloudprint.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/gtk-vnc.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/kde4/krfb.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/kde4/smokeqt.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/libdbus-c++.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/libhandy.log http://build-failures.rhaalovely.net//sparc64/2019-10-06/x11/mate/caja.log
Re: Tor-Browser port
Yes, it's a lot of work to update and maintain the port. Attila should chime in, but I don't know how the load can be lightened on his end. I just really do the package testing, and did the port build on i386 in the past. Wondering now about rock64 builds if the firefox port on aarch64 actually builds now. I'll take a look. We do need better hardware at some point, which will ease the process a bit, but a lot of the git wrangling isn't simple. I should at least setup some automated builds with updated snapshots to at least keep tabs on that. g ports: > I've contacted the torbsd project additionally to the maintainer and > they responded withing hours. > > He's currently working on it but won't make it into 6.6 > > On 2019-10-09 09:49, Stuart Henderson wrote: >> On 2019/10/09 07:13, Solène Rapenne wrote: >>> And it's now marked BROKEN so it's unlikely it will ship in 6.6 except if >>> someone fix it in the next days. >> It's too late for 6.6. >> >
Ports tree locked for 6.6 release
The ports tree is now locked for the 6.6 release. No more commits. If something truly critical comes up, talk to sthen@ and me. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Tor-Browser port
I've contacted the torbsd project additionally to the maintainer and they responded withing hours. He's currently working on it but won't make it into 6.6 On 2019-10-09 09:49, Stuart Henderson wrote: > On 2019/10/09 07:13, Solène Rapenne wrote: >> And it's now marked BROKEN so it's unlikely it will ship in 6.6 except if >> someone fix it in the next days. > It's too late for 6.6. >
Troubles with Bro
Hi Ports, I am fully aware that this is very late in a release cycle so hopefully this works as expected on 6.6 which I didn't test iris# uname -a OpenBSD iris.int.autonsys.com 6.5 GENERIC.MP#5 amd64 iris# syspatch -l 001_rip6cksum 002_srtp 003_mds 004_bgpd 005_libssl 006_tcpsack 007_smtpd 008_swapgs 009_resume 010_frag6ecn 011_expat 012_sysupgrade 013_unbound 014_dhcpd iris# /usr/local/bin/broctl deploy checking configurations ... bro scripts failed. error in /usr/local/share/bro/base/protocols/dce-rpc/./main.bro, line 51: "redef" used but not previously defined (DPD::ignore_violations) Notice that I only change the name of the interface in /etc/bro/node.cfg per /usr/local/share/doc/pkg-readmes/bro iris# /usr/local/bin/broctl start Warning: broctl node config has changed (run the broctl "deploy" command) starting bro ... Error: bro terminated immediately after starting; check output with "diag" iris# /usr/local/bin/broctl status Warning: broctl node config has changed (run the broctl "deploy" command) Name Type Host StatusPidStarted bro standalone localhost stopped iris# /usr/local/bin/broctl diag Warning: broctl node config has changed (run the broctl "deploy" command) [bro] No core file found and egdb is not installed. It is recommended to install egdb so that BroControl can output a backtrace if Bro crashes. Bro 2.6.4 OpenBSD 6.5 Bro plugins: (none found) No reporter.log stderr.log error in /usr/local/share/bro/base/protocols/dce-rpc/./main.bro, line 51: "redef" used but not previously defined (DPD::ignore_violations) stdout.log max memory size (kbytes, -m) unlimited data seg size (kbytes, -d) 33554432 core file size (blocks, -c) unlimited .cmdline -i em0 -U .status -p broctl -p broctl-live -p standalone -p local -p bro local.bro broctl broctl/standalone broctl/auto .env_vars PATH=/usr/local/bin:/usr/local/share/broctl/scripts:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin BROPATH=/var/spool/bro/installed-scripts-do-not-touch/site::/var/spool/bro/installed-scripts-do-not-touch/auto:/usr/local/share/bro:/usr/local/share/bro/policy:/usr/local/share/bro/site CLUSTER_NODE= .status TERMINATED [atexit] No prof.log No packet_filter.log No loaded_scripts.log Also Cron /usr/local/bin/broctl cron Error: cannot start bro; check output of "diag" Error: env: bash: No such file or directory starting bro ... This used to work as expected in 6.4 I shut down my installation as I didn't need at that time but I now needed badly. I will upgrade to 6.6 as soon as it is released. Best, Predrag
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2019/10/09 11:59:09 Modified files: games/xmoto: Makefile games/xmoto/patches: patch-src_include_xm_hashmap_h Added files: games/xmoto/patches: patch-src_VTexture_h patch-src_drawlib_DrawLibOpenGL_cpp Log message: Fix font rendering. Patch taken from FreeBSD. Noticed and OK solene@
Re: C preprocessor search paths
Thanks a lot for the helpfull answers Stuart and Jeremie. On October 9, 2019 11:11:22 AM GMT+02:00, Jeremie Courreges-Anglas wrote: >On Wed, Oct 09 2019, Christopher Zimmermann wrote: >> On Tue, Oct 08, 2019 at 01:44:14PM +0200, Jeremie Courreges-Anglas >wrote: >>> On Tue, Oct 08 2019, Christopher Zimmermann >wrote: >>> > On Mon, Oct 07, 2019 at 09:09:50PM +0100, Stuart Henderson wrote: >>> >> On 2019/10/07 21:37, Christopher Zimmermann wrote: >>> >> > How is an arbitrary piece of software supposed to >>> >> > discover /usr/local/include and /usr/local/lib? >>> >> >>> >> The same way it will discover /opt/include and /opt/lib on a >linux box - >>> >> you tell it to look there. >>> > >>> > - What's the preferred way to teach a build system our search >paths ? >>> > - What's the preferred / most portable way for a piece of software >to >>> > discover the search paths? >>> > >>> > Is it pkg-config, $CPATH / $LIBRARY_PATH, autoconf, something >else? >>> >>> Many build systems have support for pkg-config (eg pkg.m4 for >autoconf). >>> autoconf honours (at least) CPPFLAGS/CFLAGS/LDFLAGS. >>> CPATH and LIBRARY_PATH are OCaml idioms AFAIK. >> >> Quite contrary CPATH and LIBRARY_PATH are variables heeded by gcc and >> clang compiler and linker. > >Hah, indeed, I had completely forgotten about this. > >> I did some experiments: >> >> $ echo '#include' >incl_test.c >> $ CPATH= cc -E -Wp,-v incl_test.c >/dev/null >> clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target >amd64-unknown-openbsd6.6 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/lib/clang/8.0.1/include >> /usr/include >> End of search list. >> incl_test.c:1:9: fatal error: 'bzlib.h' file not found >> #include >> ^ >> 1 error generated. >> $ CPATH=/usr/local/include cc -E -Wp,-v incl_test.c >/dev/null >> clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target >amd64-unknown-openbsd6.6 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/include >> /usr/lib/clang/8.0.1/include >> /usr/include >> >> But this is _really_ unexpected: >> >> $ CPATH= echo '#include' |cc -E -Wp,-v - >/dev/null > >> clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target >amd64-unknown-openbsd6.6 >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/include >> /usr/X11R6/include >> /usr/lib/clang/8.0.1/include >> /usr/include >> End of search list.nd of search list >> >> This tells me that the preprocessor has a decent idea of our search >> path, but forgets about /usr/local and /usr/X11R6 includes when a >file >> is passed as argument instead of run in a pipe. >> >> The heck why does it do that? > >Your command doesn't do what you think it does. > >> CPATH= echo '#include' |cc -E -Wp,-v - >/dev/null > >CPATH is only clobbered for the first command in the pipe, 'echo'. >'cc' >still inherits whatever is in CPATH, and I guess it's set to a custom >value. Did you actually remove CPATH/LIBRARY_PATH from your >/etc/profile? ;) Well yes, I did indeed, but did not yet reboot. >--8<-- >russell ~/tests$ echo '#include' | CPATH= cc -E -Wp,-v - >>/dev/null >clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target >amd64-unknown-openbsd6.6 >ignoring nonexistent directory "/usr/lib/clang/8.0.1/include" >#include "..." search starts here: >#include <...> search starts here: > /usr/include >End of search list. >:1:9: fatal error: 'bzlib.h' file not found >#include >^ >1 error generated. >-->8-- > > >>> There's no single answer. >> >> Of course not. >> >>> Can opam simply inject -I/usr/local/include and -L/usr/local/lib in >the >>> dune build system used by ocaml-lmdb? >> >> Since the C compiler/linkers heed CPATH and LIBRARY_PATH, I can >simply >> set those variables to inject the standard search path. >> But why do I even have to do that? The preprocessor seems to know the >> correct search path, but seems to forget it under some circumstances. > >By design our base compilers aren't supposed to look into /usr/local or >/usr/X11R6. Then for a build system is there any way to discover /usr/local/include except guessing? Christopher signature.asc Description: PGP signature
[NEW] devel/p5-Sys-MemInfo
Greetings, attached is a new port for the perl module Sys::MemInfo. Sys::MemInfo returns the total amount of free and used physical memory in bytes in totalmem and freemem variables. Tested on -current amd64. This will be needed for an updated version of mail/imapsync. Comments? If OK, someone is needed to push it to CVS. Kind regards, Henry p5-Sys-MemInfo.tar.gz Description: application/gzip
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/10/09 05:22:03 Modified files: graphics/openimageio: Makefile Log message: stop using -Werror to allow building on aarch64; ok pascal@
math/py-pandas build failure: scm_integration
Anyone see where this is coming from? I don't see anything about
setuptools_scm.integration in py-pandas itself.
running install_egg_info
running egg_info
writing requirements to pandas.egg-info/requires.txt
writing pandas.egg-info/PKG-INFO
writing top-level names to pandas.egg-info/top_level.txt
writing dependency_links to pandas.egg-info/dependency_links.txt
Traceback (most recent call last):
File "./setup.py", line 746, in
**setuptools_kwargs)
File "/usr/local/lib/python2.7/site-packages/setuptools/__init__.py", line
145, in setup
return distutils.core.setup(**attrs)
File "/usr/local/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/usr/local/lib/python2.7/site-packages/setuptools/command/install.py",
line 61, in run
return orig.install.run(self)
File "/usr/local/lib/python2.7/distutils/command/install.py", line 575, in run
self.run_command(cmd_name)
File "/usr/local/lib/python2.7/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File
"/usr/local/lib/python2.7/site-packages/setuptools/command/install_egg_info.py",
line 34, in run
self.run_command('egg_info')
File "/usr/local/lib/python2.7/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/usr/local/lib/python2.7/site-packages/setuptools/command/egg_info.py",
line 296, in run
self.find_sources()
File "/usr/local/lib/python2.7/site-packages/setuptools/command/egg_info.py",
line 303, in find_sources
mm.run()
File "/usr/local/lib/python2.7/site-packages/setuptools/command/egg_info.py",
line 534, in run
self.add_defaults()
File "/usr/local/lib/python2.7/site-packages/setuptools/command/egg_info.py",
line 574, in add_defaults
rcfiles = list(walk_revctrl())
File "/usr/local/lib/python2.7/site-packages/setuptools/command/sdist.py",
line 20, in walk_revctrl
for item in ep.load()(dirname):
File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line
2434, in load
return self.resolve()
File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line
2440, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
ImportError: No module named setuptools_scm.integration
Re: C preprocessor search paths
On Wed, Oct 09 2019, Christopher Zimmermann wrote: > On Tue, Oct 08, 2019 at 01:44:14PM +0200, Jeremie Courreges-Anglas wrote: >> On Tue, Oct 08 2019, Christopher Zimmermann wrote: >> > On Mon, Oct 07, 2019 at 09:09:50PM +0100, Stuart Henderson wrote: >> >> On 2019/10/07 21:37, Christopher Zimmermann wrote: >> >> > How is an arbitrary piece of software supposed to >> >> > discover /usr/local/include and /usr/local/lib? >> >> >> >> The same way it will discover /opt/include and /opt/lib on a linux box - >> >> you tell it to look there. >> > >> > - What's the preferred way to teach a build system our search paths ? >> > - What's the preferred / most portable way for a piece of software to >> > discover the search paths? >> > >> > Is it pkg-config, $CPATH / $LIBRARY_PATH, autoconf, something else? >> >> Many build systems have support for pkg-config (eg pkg.m4 for autoconf). >> autoconf honours (at least) CPPFLAGS/CFLAGS/LDFLAGS. >> CPATH and LIBRARY_PATH are OCaml idioms AFAIK. > > Quite contrary CPATH and LIBRARY_PATH are variables heeded by gcc and > clang compiler and linker. Hah, indeed, I had completely forgotten about this. > I did some experiments: > > $ echo '#include' >incl_test.c > $ CPATH= cc -E -Wp,-v incl_test.c >/dev/null > clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target > amd64-unknown-openbsd6.6 > #include "..." search starts here: > #include <...> search starts here: > /usr/lib/clang/8.0.1/include > /usr/include > End of search list. > incl_test.c:1:9: fatal error: 'bzlib.h' file not found > #include > ^ > 1 error generated. > $ CPATH=/usr/local/include cc -E -Wp,-v incl_test.c >/dev/null > clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target > amd64-unknown-openbsd6.6 > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/lib/clang/8.0.1/include > /usr/include > > But this is _really_ unexpected: > > $ CPATH= echo '#include' |cc -E -Wp,-v - >/dev/null > clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target > amd64-unknown-openbsd6.6 > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/X11R6/include > /usr/lib/clang/8.0.1/include > /usr/include > End of search list.nd of search list > > This tells me that the preprocessor has a decent idea of our search > path, but forgets about /usr/local and /usr/X11R6 includes when a file > is passed as argument instead of run in a pipe. > > The heck why does it do that? Your command doesn't do what you think it does. > CPATH= echo '#include' |cc -E -Wp,-v - >/dev/null CPATH is only clobbered for the first command in the pipe, 'echo'. 'cc' still inherits whatever is in CPATH, and I guess it's set to a custom value. Did you actually remove CPATH/LIBRARY_PATH from your /etc/profile? ;) --8<-- russell ~/tests$ echo '#include' | CPATH= cc -E -Wp,-v - >/dev/null clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target amd64-unknown-openbsd6.6 ignoring nonexistent directory "/usr/lib/clang/8.0.1/include" #include "..." search starts here: #include <...> search starts here: /usr/include End of search list. :1:9: fatal error: 'bzlib.h' file not found #include ^ 1 error generated. -->8-- >> There's no single answer. > > Of course not. > >> Can opam simply inject -I/usr/local/include and -L/usr/local/lib in the >> dune build system used by ocaml-lmdb? > > Since the C compiler/linkers heed CPATH and LIBRARY_PATH, I can simply > set those variables to inject the standard search path. > But why do I even have to do that? The preprocessor seems to know the > correct search path, but seems to forget it under some circumstances. By design our base compilers aren't supposed to look into /usr/local or /usr/X11R6. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: C preprocessor search paths
On 2019/10/09 10:38, Christopher Zimmermann wrote: > But this is _really_ unexpected: > > $ CPATH= echo '#include' |cc -E -Wp,-v - >/dev/null > clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target > amd64-unknown-openbsd6.6 > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/X11R6/include > /usr/lib/clang/8.0.1/include > /usr/include > End of search list.nd of search list I guess you have set CPATH in the environment (the command line you show does not reset it for cc, only for echo). cc is not expected to know anything about /usr/local/include or /usr/X11R6/include unless specifically told to look there. This is intentional.
Re: C preprocessor search paths
On Tue, Oct 08, 2019 at 01:44:14PM +0200, Jeremie Courreges-Anglas wrote: > On Tue, Oct 08 2019, Christopher Zimmermann wrote: > > On Mon, Oct 07, 2019 at 09:09:50PM +0100, Stuart Henderson wrote: > >> On 2019/10/07 21:37, Christopher Zimmermann wrote: > >> > How is an arbitrary piece of software supposed to > >> > discover /usr/local/include and /usr/local/lib? > >> > >> The same way it will discover /opt/include and /opt/lib on a linux box - > >> you tell it to look there. > > > > - What's the preferred way to teach a build system our search paths ? > > - What's the preferred / most portable way for a piece of software to > > discover the search paths? > > > > Is it pkg-config, $CPATH / $LIBRARY_PATH, autoconf, something else? > > Many build systems have support for pkg-config (eg pkg.m4 for autoconf). > autoconf honours (at least) CPPFLAGS/CFLAGS/LDFLAGS. > CPATH and LIBRARY_PATH are OCaml idioms AFAIK. Quite contrary CPATH and LIBRARY_PATH are variables heeded by gcc and clang compiler and linker. I did some experiments: $ echo '#include' >incl_test.c $ CPATH= cc -E -Wp,-v incl_test.c >/dev/null clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target amd64-unknown-openbsd6.6 #include "..." search starts here: #include <...> search starts here: /usr/lib/clang/8.0.1/include /usr/include End of search list. incl_test.c:1:9: fatal error: 'bzlib.h' file not found #include ^ 1 error generated. $ CPATH=/usr/local/include cc -E -Wp,-v incl_test.c >/dev/null clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target amd64-unknown-openbsd6.6 #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/clang/8.0.1/include /usr/include But this is _really_ unexpected: $ CPATH= echo '#include' |cc -E -Wp,-v - >/dev/null clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target amd64-unknown-openbsd6.6 #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/X11R6/include /usr/lib/clang/8.0.1/include /usr/include End of search list.nd of search list This tells me that the preprocessor has a decent idea of our search path, but forgets about /usr/local and /usr/X11R6 includes when a file is passed as argument instead of run in a pipe. The heck why does it do that? > There's no single answer. Of course not. > Can opam simply inject -I/usr/local/include and -L/usr/local/lib in the > dune build system used by ocaml-lmdb? Since the C compiler/linkers heed CPATH and LIBRARY_PATH, I can simply set those variables to inject the standard search path. But why do I even have to do that? The preprocessor seems to know the correct search path, but seems to forget it under some circumstances. Christopher -- http://gmerlin.de OpenPGP: http://gmerlin.de/christopher.pub CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1 signature.asc Description: PGP signature
Re: Tor-Browser port
On 2019/10/09 07:13, Solène Rapenne wrote: > And it's now marked BROKEN so it's unlikely it will ship in 6.6 except if > someone fix it in the next days. It's too late for 6.6.
[Update] devel/p5-DateTime-Format-Flexible : Update to 0.32
Hi, ports@: Here is a simple patch for devel/p5-DateTime-Format-Flexible to update to 0.32. It build well and pass all tests on amd64-head system. No other ports depend on it. Comments? OK? wen Index: Makefile === RCS file: /cvs/ports/devel/p5-DateTime-Format-Flexible/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile5 Jul 2019 18:31:54 - 1.1.1.1 +++ Makefile9 Oct 2019 07:22:54 - @@ -2,7 +2,7 @@ COMMENT = flexibly parse strings and turn them into DateTime objects -DISTNAME = DateTime-Format-Flexible-0.31 +DISTNAME = DateTime-Format-Flexible-0.32 CATEGORIES = devel Index: distinfo === RCS file: /cvs/ports/devel/p5-DateTime-Format-Flexible/distinfo,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 distinfo --- distinfo5 Jul 2019 18:31:54 - 1.1.1.1 +++ distinfo9 Oct 2019 07:22:54 - @@ -1,2 +1,2 @@ -SHA256 (DateTime-Format-Flexible-0.31.tar.gz) = Da9i/krwszbUXjZxQ6WAtaNJEqZ57veI1UxNWtaFwtE= -SIZE (DateTime-Format-Flexible-0.31.tar.gz) = 74507 +SHA256 (DateTime-Format-Flexible-0.32.tar.gz) = UKe5/rKHuxSycyOlPCMkSGGBo6tss/THZi1CvpAa2O4= +SIZE (DateTime-Format-Flexible-0.32.tar.gz) = 76438
[Update] databases/p5-DBD-LDAP : Update to 1.00
Hi, ports@: Here is a simple patch for databases/p5-DBD-LDAP to update to 1.00. It build well and pass all tests on amd64-head system. No other ports depend on it. Comments? OK? wen Index: Makefile === RCS file: /cvs/ports/databases/p5-DBD-LDAP/Makefile,v retrieving revision 1.11 diff -u -p -r1.11 Makefile --- Makefile12 Jul 2019 20:43:55 - 1.11 +++ Makefile9 Oct 2019 06:55:24 - @@ -5,7 +5,7 @@ COMMENT=DBI driver for LDAP databases MODULES= cpan PKG_ARCH= * -DISTNAME= DBD-LDAP-0.22 +DISTNAME= DBD-LDAP-1.00 CATEGORIES=databases perl5 Index: distinfo === RCS file: /cvs/ports/databases/p5-DBD-LDAP/distinfo,v retrieving revision 1.5 diff -u -p -r1.5 distinfo --- distinfo4 Jun 2015 04:46:48 - 1.5 +++ distinfo9 Oct 2019 06:55:24 - @@ -1,2 +1,2 @@ -SHA256 (DBD-LDAP-0.22.tar.gz) = 2vqx0onv5Q9xScfoEcBfWTKsjUi9qjnejGQxcSH4h4E= -SIZE (DBD-LDAP-0.22.tar.gz) = 35329 +SHA256 (DBD-LDAP-1.00.tar.gz) = KandghENIcUJY1hNRm/qr8pottnJ2NZYesKJcu/9MTU= +SIZE (DBD-LDAP-1.00.tar.gz) = 29841
