Re: rsync: update to 3.2.2
On 2020-08-04, Klemens Nanni wrote: > I also looked at iconv but rsync configures and builds with it even when > --disable-iconv gets passed, this smells like some configure* bug. 3.2.2p0 now does not pick up iconv. I quickly looked over configure.ac, and as far as I can tell (1) detection that iconv is available and how, and (2) the choice to enable --iconv are independent of each other. -- Christian "naddy" Weisgerber na...@mips.inka.de
amd64 bulk build failures 2020-08-10
Here is the list of build failures from the amd64 bulk build started on 2020-08-10. These are the remaining LLVM 10 fallout: devel/py-llvmlite,python3 devel/rttr games/fs2open net/bro print/scribus productivity/aqbanking x11/gnustep/back x11/gnustep/renaissance I didn't upload new logs. These are still the same failures as in earlier builds: http://build-failures.rhaalovely.net/amd64/2020-08-07/ -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: amd64 bulk build failures 2020-08-10
Christian Weisgerber: > Here is the list of build failures from the amd64 bulk build started > on 2020-08-10. 2020-08-09 actually, not that it matters. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: i386/LLVM 10
On 2020-08-12, Stuart Henderson wrote: >> print/scribus > /pobj/scribus-1.5.5/scribus-1.5.5/scribus/third_party/lib2geom/path.h:260:11: > error: no viable overloaded '=' This one is probably an easy fix for somebody who actually knows C++. The problem is in an ancient embedded copy of lib2geom. I looked for a fix elsewhere, but FreeBSD compiles this port with gcc9, and lib2geom, which seems to be at home inside inkscape, has changed beyond recognition. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: i386/LLVM 10
On 2020-08-10, Stuart Henderson wrote: > x11/qt4 > > ld: error: relocation R_386_PC32 cannot be used against symbol cti_vm_throw; > recompile with -fPIC defined in ../../JavaScriptCore/release/libjscore.a(JITStubs.o) referenced by JITStubs.cpp JITStubs.o:(.text+0x21) in archive ../../JavaScriptCore/release/libjscore.a We've seen that error before. That was in textproc/wkhtmltopdf, which builds its own included copy of Qt4 WebKit. Back then, removing -ffunction-sections from the compiler flags fixed it. Now the problem is back, in both wkhtmltopdf and qt4, without -ffunction-sections. I thought maybe LLVM 10 had enabled this option by default, but it doesn't look like it. -fno-function-sections also has no effect. I don't understand what's going on. There is a short assembly stub, ctiVMThrowTrampoline(), which CALLs cti_vm_throw(). Somehow that generates an R_386_PC32 relocation, and somehow that is incompatible with PIC. (How can PC-relative addressing be incompatible with position-independent code?) With LLVM 8, there is no callable ctiVMThrowTrampoline() function in the object file, and ctiVMThrowTrampoline's code is inlined... somewhere. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: i386/LLVM 10
Jeremie Courreges-Anglas: > I don't have an i386 ports test rig. naddy, do you still run i386 test > builds? Else I can just push it in the tree for sthen to pick up in > the next bulk, it won't make things worse... I've installed i386 on my spare APU2. I can't run full builds there, but I can test individual ports. I'll give this patch a try. -- Christian "naddy" Weisgerber na...@mips.inka.de
amd64 bulk build failures 2020-08-12
(No change from 2020-08-10.) Here is the list of build failures from the amd64 bulk build started on 2020-08-12. These are the remaining LLVM 10 fallout: devel/py-llvmlite,python3 devel/rttr games/fs2open net/bro print/scribus productivity/aqbanking x11/gnustep/back x11/gnustep/renaissance I didn't upload new logs. These are still the same failures as in earlier builds: http://build-failures.rhaalovely.net/amd64/2020-08-07/ -- Christian "naddy" Weisgerber na...@mips.inka.de
cmake sporadic library versioning problem
Occasionally, print/poppler fails to build with a curious error: A shared library has been built with the version number from SHARED_LIBS, but during the fake stage this is forgotten and the upstream version number used. This produces an error, because the file doesn't exist. It only happens _sometimes_ and this has been going on for months. Now in my latest bulk build, x11/kde-applications/marble has failed the same way: ===> build c++ -fPIC -O2 -pipe -std=c++0x -DNDEBUG -shared -Wl,-soname,libmarblewidget-qt5.so.1.0 -o src/lib/marble/libmarblewidget-qt5.so.1.0 ... ===> fake CMake Error at src/lib/marble/cmake_install.cmake:41 (file): file INSTALL cannot find "/usr/obj/ports/marble-kf5-19.12.3/build-amd64/src/lib/marble/libmarblewidget-qt5.so.0.28.0": No such file or directory. So whatever this is, it does not affect only poppler. The fact that this type of error happens only during _some_ bulk builds suggests that it might be triggered by something else on the machine. Another port that happens to be installed at the same time, or something that is building at the same time. (Cf. how "rm /tmp/conftest*" in misc/screen caused mysterious configure failures in other ports.) -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: llvm10 and libtheoraplay on i386
Jeremie Courreges-Anglas:
> > Shared libraries should be linked with -fpic/-fPIC.
>
> naddy committed a fix using -fPIC which is safe to use on all arches.
>
> (I don't know if ports should use ${PICFLAG} from bsd.own.mk when
> practical, but a few ports do it already.)
Once upon a time, it was decided that ports should just use -fPIC
and not bother with the -fpic/-fPIC distinction.
--
Christian "naddy" Weisgerber na...@mips.inka.de
LLVM 10: build failures on amd64 2020-08-13
The remaining build failures on amd64 due to the LLVM 10 update: devel/py-llvmlite,python3 needs update to 0.34.0 devel/rttr games/fs2open print/scribus productivity/aqbanking x11/gnustep/back\ -fuse-ld=bfd not passed through x11/gnustep/renaissance / sebastia@ is looking into it Logs: http://build-failures.rhaalovely.net/amd64/2020-08-07/ -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: cmake sporadic library versioning problem
On 2020-08-13, Christian Weisgerber wrote: > A shared library has been built with the version number from > SHARED_LIBS, but during the fake stage this is forgotten and the > upstream version number used. This produces an error, because the > file doesn't exist. > > It only happens _sometimes_ and this has been going on for months. > > Now in my latest bulk build, x11/kde-applications/marble has > failed the same way: Now x11/kde-applications/kdepim-runtime. c++ ... -o bin/libakonadi-filestore.so.0.0 ... . . . CMake Error at resources/shared/filestore/cmake_install.cmake:52 (file): file INSTALL cannot find "/usr/obj/ports/kdepim-runtime-kf5-19.12.3/build-amd64/bin/libakonadi-filestore.so.5.13.3": No such file or directory. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: LLVM 10: build failures on amd64 2020-08-13
Rafael Sadowski: > > The remaining build failures on amd64 due to the LLVM 10 update: > > devel/rttr > > fixed I still get the same build errors. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: i386 failures
On 2020-08-18, Stuart Henderson wrote: > build failures: 12 These are the actual i386 failures: > audio/mscore: out of memory linking > devel/cutter: narrowing from type 'const unsigned long long' to 'size_t' (aka > 'unsigned long') > devel/geany: linking (scintilla) > geo/pgrouting: ICE (log below) The ones below also happen on amd64: > devel/py-llvmlite: llvm mismatch (all archs) > games/fs2open: no matching constructor for initialization of > 'std::unique_lock' > graphics/openexr: picks up wrong numpy; possibly related to boost update or > openexr update (log below) > print/scribus: no viable overloaded '=' > productivity/aqbanking: linker missing symbols (as amd64) Already fixed: > devel/intellij: patch error (all archs, since fixed) > x11/gnustep/back: (as amd64) > x11/gnustep/renaissance: (as amd64) -- Christian "naddy" Weisgerber na...@mips.inka.de
LLVM 10: build failures on amd64 2020-08-17
The remaining build failures on amd64 due to the LLVM 10 update: devel/py-llvmlite,python3 needs update to 0.34.0 games/fs2open print/scribus productivity/aqbanking Logs: http://build-failures.rhaalovely.net/amd64/2020-08-07/ -- Christian "naddy" Weisgerber na...@mips.inka.de
LLVM 10: build failures on amd64 2020-08-18
The remaining build failures on amd64 due to the LLVM 10 update: devel/py-llvmlite,python3 needs update to 0.34.0 games/fs2open productivity/aqbanking Logs: http://build-failures.rhaalovely.net/amd64/2020-08-07/ -- Christian "naddy" Weisgerber na...@mips.inka.de
LLVM 10: build failures on amd64 2020-08-20
The remaining build failures on amd64 due to the LLVM 10 update: devel/py-llvmlite,python3 needs update to 0.34.0 productivity/aqbanking Logs: http://build-failures.rhaalovely.net/amd64/2020-08-07/ -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: i386 ports build report
Stuart Henderson:
> build failures: 7
> devel/cutter
Here's a fix. If I understand the code correctly, this struct
element is assigned an iterator over a std::unordered_map.
I have confirmed that cutter builds with this on i386.
Index: Makefile
===
RCS file: /cvs/ports/devel/cutter/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile14 Aug 2020 17:15:56 - 1.7
+++ Makefile24 Aug 2020 22:47:57 -
@@ -5,6 +5,7 @@ COMMENT = RE platform powered by radare2
GH_ACCOUNT = radareorg
GH_PROJECT = cutter
GH_TAGNAME = v1.11.1
+REVISION = 0
CATEGORIES = devel
Index: patches/patch-src_widgets_GraphGridLayout_cpp
===
RCS file: patches/patch-src_widgets_GraphGridLayout_cpp
diff -N patches/patch-src_widgets_GraphGridLayout_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_widgets_GraphGridLayout_cpp 24 Aug 2020 22:47:57
-
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: src/widgets/GraphGridLayout.cpp
+--- src/widgets/GraphGridLayout.cpp.orig
src/widgets/GraphGridLayout.cpp
+@@ -526,7 +526,7 @@ void GraphGridLayout::calculateEdgeMainColumn(GraphGri
+ // to contain blocks above sweep line and query for nearest column which
isn't blocked by a block.
+
+ struct Event {
+-size_t blockId;
++ut64 blockId;
+ size_t edgeId;
+ int row;
+ enum Type {
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: rsync 3.2.3
On 2020-08-26, "Theo de Raadt" wrote: > I've encountered a few situations with _mostly offline machines_ where > the rsync package is need, and thus, 1 file can be copied over for > pkg_add. I don't think I'm the only person to encounter this situation. We could link rsync statically with some dependencies, or provide a static flavor that does this. The flip side is that somebody needs to remember to bump rsync every time one of those dependencies is updated, otherwise the installed rsync package will not be updated. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: cmake sporadic library versioning problem
Otto Moerbeek: > > Is it possible that char* (env_vers_cstr) points to null or garbage > > because env changed? Or is this nonsense and this cannot happen and > > env_vers_cstr is always valid with the first match? > > No, Posix allows previous values of getenv() to be invalidated by > subsequenct calls to setenv(), plus a few other conditions. To clarify: The environment is within the process's address space. Neither the parent nor any other process can change it. However, the process itself can modify it, which is where putenv() etc. come in. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: gmake: parse error: error in archive specification
Rafael Sadowski:
> It is very easy to reproduce:
> $ cd /usr/ports/security/argon2 && make test
>
> ===> Regression tests for argon2-20190702
> Building without optimizations
> cc -O2 -pipe -std=c89 -Wall -g -Iinclude -Isrc -pthread -Wextra
> -Wno-type-limits src/argon2.c src/core.c src/blake2/blake2b.c src/thread.c
> src/encoding.c src/ref.c src/test.c -o testcase
> Default build
> *** Parse error in
> /usr/ports/pobj/argon2-20190702/phc-winner-argon2-20190702: Error in archive
> specification: "(, 1)" (Makefile:42)
The test target runs "sh kats/test.sh", which in turn calls "make"(!).
The errors are from our make(1) choking on the GNU makefile syntax.
Here's a fix: Export the MAKE variable, which always contains the
path with which the current make was invoked, and use it in the
kat/test.sh script.
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/security/argon2/patches/patch-Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 patch-Makefile
--- patches/patch-Makefile 17 Sep 2020 04:41:43 - 1.2
+++ patches/patch-Makefile 20 Sep 2020 20:09:58 -
@@ -21,3 +21,12 @@ Index: Makefile
LIB_CFLAGS := -shared -fPIC
PC_EXTRA_LIBS ?=
endif
+@@ -212,6 +212,8 @@ $(PC_NAME): $(PC_SRC)
+ dist:
+ cd ..; \
+ tar -c --exclude='.??*' -z -f $(DIST)-`date "+%Y%m%d"`.tgz
$(DIST)/*
++
++export MAKE
+
+ .PHONY: test
+ test: $(SRC) src/test.c
Index: patches/patch-kats_test_sh
===
RCS file: patches/patch-kats_test_sh
diff -N patches/patch-kats_test_sh
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-kats_test_sh 20 Sep 2020 20:09:58 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: kats/test.sh
+--- kats/test.sh.orig
kats/test.sh
+@@ -9,7 +9,7 @@ do
+ printf "Force OPTTEST=1\n"
+ fi
+
+- make genkat $opttest > /dev/null
++ ${MAKE:-make} genkat $opttest > /dev/null
+ if [ $? -ne 0 ]
+ then
+ exit $?
--
Christian "naddy" Weisgerber na...@mips.inka.de
Preparing for the 6.8 release
The 6.8 release is coming up, and it is time to finalize the ports tree for the release. Please, no more new ports and no casual updates. Let's focus on fixing bugs. If you don't want to surprised by your favorite application being broken in the release, make sure to test it NOW. Time is short. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [UPDATE] lang/python/3.8
Remi Pointel: > this is the diff to update Python 3.8 to latest release. > > sthen@ or naddy@: someone of you could test a bulk build with this diff? There was one build error (x11/xcolor), but it's not clear that it was caused by the Python update. I sent details to Remi and Laurence. -- Christian "naddy" Weisgerber na...@mips.inka.de
Preparing for 6.8 lock
Preparations for the release are proceeding apace and ports need to keep up with base. ALL COMMITS NOW NEED TO BE APPROVED BY naddy@ OR sthen@. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: aarch64 bulk build report
On 2020-09-25, phess...@openbsd.org wrote: > bulk build on arm64.ports.openbsd.org > started on Tue Sep 22 10:58:30 MDT 2020 > finished at Fri Sep 25 03:27:49 MDT 2020 > http://build-failures.rhaalovely.net/aarch64/2020-09-22/converters/wv2.log > http://build-failures.rhaalovely.net/aarch64/2020-09-22/editors/calligra.log > http://build-failures.rhaalovely.net/aarch64/2020-09-22/editors/xwpe.log > http://build-failures.rhaalovely.net/aarch64/2020-09-22/emulators/vice.log Those fail with internal compiler errors. > http://build-failures.rhaalovely.net/aarch64/2020-09-22/games/shockolate.log Abuses va_list as a pointer to stack arguments. I don't know what to do about this. > http://build-failures.rhaalovely.net/aarch64/2020-09-22/geo/pdal.log Machine-independent. > http://build-failures.rhaalovely.net/aarch64/2020-09-22/lang/pfe.log The not-so-portable Forth environment. > http://build-failures.rhaalovely.net/aarch64/2020-09-22/sysutils/nomad.log > http://build-failures.rhaalovely.net/aarch64/2020-09-22/sysutils/rclone.log > http://build-failures.rhaalovely.net/aarch64/2020-09-22/sysutils/telegraf.log > http://build-failures.rhaalovely.net/aarch64/2020-09-22/sysutils/terragrunt.log Those are Go lang. > http://build-failures.rhaalovely.net/aarch64/2020-09-22/x11/e17/elementary.log Mesa link error. Didn't this use to crash? > http://build-failures.rhaalovely.net/aarch64/2020-09-22/x11/qt5/qtwebkit.log Debug package creation fails. > http://build-failures.rhaalovely.net/aarch64/2020-09-22/graphics/mojoshader.log Machine-independent, fixed. > http://build-failures.rhaalovely.net/aarch64/2020-09-22/databases/sqlite3-odbc.log > http://build-failures.rhaalovely.net/aarch64/2020-09-22/sysutils/libvirt.log > http://build-failures.rhaalovely.net/aarch64/2020-09-22/x11/qt5/qtwebengine.log Those have been fixed. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: aarch64 bulk build report
On 2020-09-28, Christian Weisgerber wrote: >> http://build-failures.rhaalovely.net/aarch64/2020-09-22/x11/e17/elementary.log > > Mesa link error. Didn't this use to crash? The complaints about undefined _mesa_* symbols are a red herring. edje_cc still crashes as before. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: fix ucblogo comment and license
Daniel Dickman: > The comment looks a bit odd. > -COMMENT= Berkeley's implementation of the logo programming language#' > +COMMENT= Berkeley's implementation of the logo programming language An unbalanced single quote causes a problem somewhere. I forgot. Maybe just syntax highlighting? Anyway, this format balances the quote, but comments out the closing one at the same time. There are 17 ports in the tree that use this idiom in COMMENT. > And I think the license is GPL not BSD? Indeed. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Change curl domain
Emil Engler: > The cURL project moved to a new domain a few days ago: > https://daniel.haxx.se/blog/2020/11/04/the-journey-to-a-curl-domain/ > > This patch changes the domain from curl.haxx.se to curl.se Thanks. Note that changing the HOMEPAGE also requires a REVISION bump. curl.haxx.se will continue to work fine for a long time, so this is a purely cosmetic change. I'll slip it in with the next update to curl, presumably in a month when 7.74 is released. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [macppc] x11/agar/*: remove BROKEN, fix assembly code, add AltiVec detection
Charlene Wendling: > As such, i'm proposing again the powerpc fixes i brought then > (see [0]): > > - `rlwimi' requires 32-bit integers > - add AltiVec detection for OpenBSD My ok from back then still stands. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: make clean=depends to clean also test-deps
Marc Espie: > On Sat, Nov 14, 2020 at 07:36:31PM +, Mikolaj Kucharski wrote: > > Before I dig into this, would it be okay, if make clean=depends also > > cleaned up test dependencies? Yes, please! > The other issue is: what semantics. > make clean=depends will clean build/run depends recursively I would expect the same for test depends. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: upcoming textproc/groff-1.23.0
Ingo Schwarze: > There is another reason why now is a good time to switch priorities. > Upstream has been doing lots of work on documentation, and in that > context, they decided to use newer makeinfo(1) features that our > ancient /usr/bin/makeinfo does not support. The natural consequence > is to make groff depend on the print/texinfo port and use the newer > gmakeinfo(1) version contained in that port to format the groff > documentation. (Yes, the irony that groff does *not* use roff for > its own documentation but instead uses TeX is not lost on me.) It is GNU project policy that distribution tarballs include pre-formatted .info files so that makeinfo is NOT required. ... Although, I guess that groff wants to build HTML/PDF documentation? The need for a newer makeinfo will bite us more and more, especially porters who are not as comfortable disentangling the dependencies and touch(1)ing the correct files when upstream make a mistake while creating the tarball and the autotools build cascade goes off and wants to re-run makeinfo without need... > Now, print/texinfo isn't exactly a lean port. Here is its > list of dependencies according to "make full-all-depends": Installing this monster for a newer makeinfo(1) will sooner or later trap us in a recursive dependency. > * Texinfo is needed to build the documentation. The alternative >would be to ship groff without documentation and point people to >https://www.gnu.org/software/groff/manual/html_node/ . >But frankly, we don't generally like telling people "get the >manual from the web" in OpenBSD. Actually, we tend not to build documentation that requires pulling in dependencies like Doxygen or, well, TeXLive. (Admittedly, much Doxygen-generated documentation seems very poor in the first place and just regurgitates header files.) -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: upcoming textproc/groff-1.23.0
Ingo Schwarze: > > It is GNU project policy that distribution tarballs include > > pre-formatted .info files so that makeinfo is NOT required. > > tar -tzvf groff-1.23.0.rc1.tar.gz | grep -F .info > > tells me the groff project doesn't include it in the tarball, but > maybe i can convince them to do that in the future. I mean... https://ftp.gnu.org/gnu/makeinfo.README | makeinfo is part of the texinfo distribution. | Get texinfo-*.tar.gz. | | However, all GNU distributions should come with prebuilt info files, | thus makeinfo should not be needed. If you notice a distribution | that does not come with *.info files, please report it as a bug. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: PostgreSQL 13.1 Upgrade
Jeremy Evans: > Now that PostgreSQL 13.1 is out, I think we can consider upgrading to > it. The diff below was tested on amd64 on a partial bulk of the ports > depending on PostgreSQL. > > Could we please have this tested in a bulk? I ran this through a bulk build on amd64. Two build failures were attributable to it: ===> databases/postgresql-plr pg_backend_support.c:120:13: error: use of undeclared identifier 'tag_hash'; did you mean 'time_hash'? ctl.hash = tag_hash; ^~~~ ===> databases/timescaledb -- Compiling against PostgreSQL version 13.1 -- Configuring incomplete, errors occurred! See also "/usr/obj/ports/timescaledb-1.7.4/build-amd64/CMakeFiles/CMakeOutput.log". CMake Error at CMakeLists.txt:209 (message): TimescaleDB only supports PostgreSQL 9.6.3+, 10.2+, 11 or 12 -- Christian "naddy" Weisgerber na...@mips.inka.de
x11/gtk+2: print to lpr (was: Re: CVS: cvs.openbsd.org: ports)
Antoine Jacoutot:
> CVSROOT: /cvs
> Module name: ports
> Changes by: ajacou...@cvs.openbsd.org 2020/12/06 02:00:22
>
> Modified files:
> x11/gtk+3 : Makefile distinfo
> x11/gtk+3/pkg : PLIST-main
>
> Log message:
> Update to gtk+3-3.24.24.
> Amongst other changes:
> - Allow the lpr backend to print pdf and ps files
Should we port this change back to x11/gtk+2? I seem to remember
that it affected GTK+2 too, back when Mozilla still used it.
I don't know an actual GTK+2 application to test it on now, though.
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
retrieving revision 1.236
diff -u -p -r1.236 Makefile
--- Makefile11 Nov 2020 11:49:55 - 1.236
+++ Makefile6 Dec 2020 20:27:55 -
@@ -11,7 +11,7 @@ GNOME_PROJECT=gtk+
PKGNAME-main= gtk+2-${GNOME_VERSION}
PKGNAME-cups= gtk+2-cups-${GNOME_VERSION}
-REVISION-main= 10
+REVISION-main= 11
REVISION-cups= 4
CATEGORIES=x11 devel
Index: patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
===
RCS file: patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
diff -N patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c6 Dec
2020 20:27:55 -
@@ -0,0 +1,25 @@
+$OpenBSD$
+
+Allow attempts to print PDF and PS files using the LPR backend.
+https://gitlab.gnome.org/GNOME/gtk/-/commit/8d5357ee56b1d34fe14346ed15004f9e4d571594
+
+Index: modules/printbackends/lpr/gtkprintbackendlpr.c
+--- modules/printbackends/lpr/gtkprintbackendlpr.c.orig
modules/printbackends/lpr/gtkprintbackendlpr.c
+@@ -392,9 +392,13 @@ gtk_print_backend_lpr_init (GtkPrintBackendLpr *backen
+ {
+ GtkPrinter *printer;
+
+- printer = gtk_printer_new (_("Print to LPR"),
+- GTK_PRINT_BACKEND (backend),
+- TRUE);
++ printer = g_object_new (GTK_TYPE_PRINTER,
++"name", _("Print to LPR"),
++"backend", backend,
++"is-virtual", FALSE,
++"accepts-pdf", TRUE,
++"accepts-ps", TRUE,
++NULL);
+ gtk_printer_set_has_details (printer, TRUE);
+ gtk_printer_set_icon_name (printer, "gtk-print");
+ gtk_printer_set_is_active (printer, TRUE);
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: x11/gtk+2: print to lpr (was: Re: CVS: cvs.openbsd.org: ports)
Landry Breuil: > i think print/gtklp can be used to test it.. That appears to require a running CUPS server. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [UPDATE] www/youtube-dl to 2020.12.31
Ricardo Mestre: > Latest release of the year, OK? Can't you just take maintainer and commit those directly? -- Christian "naddy" Weisgerber na...@mips.inka.de
libc++ 10.0: games/dangerdeep
games/dangerdeep fails to build with libc++ 10.0.
Here's a build fix, adapted from FreeBSD (which has since removed
the port because of the scons -> python2 dependency).
OK?
Index: patches/patch-src_coastmap_h
===
RCS file: /cvs/ports/games/dangerdeep/patches/patch-src_coastmap_h,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_coastmap_h
--- patches/patch-src_coastmap_h30 Apr 2017 08:24:33 - 1.1
+++ patches/patch-src_coastmap_h5 Jan 2021 20:03:40 -
@@ -1,4 +1,5 @@
$OpenBSD: patch-src_coastmap_h,v 1.1 2017/04/30 08:24:33 espie Exp $
+Index: src/coastmap.h
--- src/coastmap.h.orig
+++ src/coastmap.h
@@ -90,7 +90,7 @@ class coastsegment (public)
@@ -10,3 +11,21 @@ $OpenBSD: patch-src_coastmap_h,v 1.1 201
// some attributes used for map reading/processing
std::vector themap; // pixel data of map file, y
points up, like in OpenGL
+@@ -148,7 +148,7 @@ class coastmap
+ void process_coastline(int x, int y);
+ void process_segment(int x, int y);
+
+- class worker : public thread
++ class worker : public ::thread
+ {
+ coastmap& cm;
+ public:
+@@ -160,7 +160,7 @@ class coastmap
+ }
+ };
+
+- thread::auto_ptr myworker;
++ ::thread::auto_ptr myworker;
+ void construction_threaded();
+
+ public:
Index: patches/patch-src_game_h
===
RCS file: /cvs/ports/games/dangerdeep/patches/patch-src_game_h,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_game_h
--- patches/patch-src_game_h30 Apr 2017 08:56:45 - 1.1
+++ patches/patch-src_game_h5 Jan 2021 20:03:40 -
@@ -1,12 +1,25 @@
$OpenBSD: patch-src_game_h,v 1.1 2017/04/30 08:56:45 espie Exp $
+Index: src/game.h
--- src/game.h.orig
+++ src/game.h
-@@ -212,7 +212,7 @@ class game (protected)
+@@ -210,9 +210,9 @@ class game (protected)
+ void simulate_objects_mt(double delta_t, unsigned idxoff, unsigned
idxmod, bool record,
+double& nearest_contact);
- class simulate_worker : public thread
+- class simulate_worker : public thread
++ class simulate_worker : public ::thread
{
- mutex mtx;
+ dd::mutex mtx;
condvar cond;
condvar condfini;
game& gm;
+@@ -230,7 +230,7 @@ class game (protected)
+ double sync();
+ };
+
+- thread::auto_ptr myworker;
++ ::thread::auto_ptr myworker;
+
+ player_info playerinfo;
+
--
Christian "naddy" Weisgerber na...@mips.inka.de
libc++ 10.0: textproc/groff
textproc/groff fails to build with libc++ 10.0. groff blocks over a thousand package paths, so this needs to be fixed before we can switch to the newer libc++. Analysis: groff includes a copy of gnulib. gnulib provides *.h wrappers for some standard header files. Those wrappers are not standalone. They are intended to be included in a source file after "config.h" has been included. In particular, gnulib has a wrapper for math.h, but not for stdlib.h. In libc++ 10, includes . When building groff, this include directive picks up the gnulib math.h wrapper. Since is included from some source files that do not include the local config.h, the math.h wrapper will then error out: error: "Please include config.h first." Possible solutions: Cherrypick the libc++ upstream patch that untangles the interactions between the two header files and stops stdlib.h from including math.h. https://github.com/llvm/llvm-project/commit/c490c5e81ac90cbf079c7cee18cd56171f1e27af That patch looks very sensible, but as the commit history shows there were problems related to "local submodule visibility" and I don't know what that is and how it affects us. In the groff port, we could add #include "config.h" to all files that don't do so already and include . This is relatively clean, but will touch a number of files. In the groff port, we could alternatively copy FreeBSD's pragmatic solution and simply add #include "config.h" to the math.h wrapper. That's not correct in some larger gnulib sense, but should suffice for the purposes of the port. Since the problem originates with gnulib, it could affect ports other than groff, too. However, a cursory search of the FreeBSD ports tree shows only one other port with a gnulib math.in.h patch, and that one is unrelated. Suggestions? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: libc++ 10.0: textproc/groff
Ingo Schwarze: > > In the groff port, we could add #include "config.h" to all files > > that don't do so already and include . > > I plan to prepare, test, and post patches for the groff port when i find > time (which will not take more than two days), but if others beat me to > it, i do not object to such paches being committed at once. I gave this a try but ran into an obstacle with yacc(1), which puts #include #include at the very start of the generated files. There's no way to prepend an #include "config.h" there, apart from post-processing yacc's output with sed... -- Christian "naddy" Weisgerber na...@mips.inka.de
print/py-pikepdf,python3 build failure
In my latest amd64 package bulk build, print/py-pikepdf,python3 failed
to build.
Specifically, page.o couldn't be compiled:
src/qpdf/page.cpp:82:10: error: no matching member function for call to 'def'
.def("externalize_inline_images",
&QPDFPageObjectHelper::externalizeInlineImages,
~^~~
This didn't happen in recent builds and I don't see any immediately
suspicious change. Here's the full log:
>>> Building on amd64-1 under print/py-pikepdf,python3
BDEPENDS =
[lang/python/3.8;devel/py-pybind11,python3;devel/py-setuptools_scm_git_archive,python3;devel/py-setuptools_scm,python3;devel/py-setuptools,python3;print/qpdf]
DIST = [print/py-pikepdf,python3:pikepdf-1.19.3.tar.gz]
FULLPKGNAME = py3-pikepdf-1.19.3p0
RDEPENDS =
[textproc/py-lxml,python3;print/qpdf;devel/py-setuptools,python3;graphics/py-Pillow,python3;lang/python/3.8]
(Junk lock obtained for amd64-1 at 1610068891.86)
>>> Running depends in print/py-pikepdf,python3 at 1610068891.93
last junk was in textproc/ruby-fast-stemmer,ruby26
/usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1 py3-setuptools-44.1.1v0
py3-setuptools_scm-3.3.3p0 py3-setuptools_scm_git_archive-1.0p2 python-3.8.7
qpdf-10.1.0
was: /usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1 py3-setuptools-44.1.1v0
py3-setuptools_scm-3.3.3p0 py3-setuptools_scm_git_archive-1.0p2 python-3.8.7
qpdf-10.1.0
/usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1 py3-setuptools-44.1.1v0
py3-setuptools_scm-3.3.3p0 py3-setuptools_scm_git_archive-1.0p2 python-3.8.7
qpdf-10.1.0
>>> Running show-prepare-results in print/py-pikepdf,python3 at 1610068894.52
===> print/py-pikepdf,python3
===> py3-pikepdf-1.19.3p0 depends on: py3-pybind11-* -> py3-pybind11-2.6.1
===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools_scm_git_archive-* ->
py3-setuptools_scm_git_archive-1.0p2
===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools_scm-* ->
py3-setuptools_scm-3.3.3p0
===> py3-pikepdf-1.19.3p0 depends on: python->=3.8,<3.9 -> python-3.8.7
===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools->=39.0.1v0 ->
py3-setuptools-44.1.1v0
===> py3-pikepdf-1.19.3p0 depends on: qpdf-* -> qpdf-10.1.0
===> Verifying specs: c++ c++abi pthread m qpdf
===> found c++.6.0 c++abi.4.0 pthread.26.1 m.10.1 qpdf.8.1
py3-pybind11-2.6.1
py3-setuptools-44.1.1v0
py3-setuptools_scm-3.3.3p0
py3-setuptools_scm_git_archive-1.0p2
python-3.8.7
qpdf-10.1.0
Don't run junk because nojunk in x11/qt5/qtbase
(Junk lock released for amd64-1 at 1610068895.49)
distfiles size=2360826
>>> Running build in print/py-pikepdf,python3 at 1610068895.54
===> print/py-pikepdf,python3
===> Checking files for py3-pikepdf-1.19.3p0
`/usr/ports/distfiles/pikepdf-1.19.3.tar.gz' is up to date.
>> (SHA256) pikepdf-1.19.3.tar.gz: OK
===> Extracting for py3-pikepdf-1.19.3p0
===> Patching for py3-pikepdf-1.19.3p0
===> Compiler link: clang -> /usr/bin/clang
===> Compiler link: clang++ -> /usr/bin/clang++
===> Compiler link: cc -> /usr/bin/cc
===> Compiler link: c++ -> /usr/bin/c++
===> Generating configure for py3-pikepdf-1.19.3p0
===> Configuring for py3-pikepdf-1.19.3p0
===> Building for py3-pikepdf-1.19.3p0
running egg_info
writing src/pikepdf.egg-info/PKG-INFO
writing dependency_links to src/pikepdf.egg-info/dependency_links.txt
writing requirements to src/pikepdf.egg-info/requires.txt
writing top-level names to src/pikepdf.egg-info/top_level.txt
reading manifest file 'src/pikepdf.egg-info/SOURCES.txt'
writing manifest file 'src/pikepdf.egg-info/SOURCES.txt'
running build
running build_py
creating
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8
creating
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/__init__.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/_cpphelpers.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/_methods.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/_version.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/codec.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/jbig2.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/objects.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
creating
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf/models
copying src/pikepdf/models/__init__.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf/models
copying src/pikepdf/models/encryption.py ->
/usr/obj/por
Re: [update] archivers/gtar 1.32 -> 1.33
Stefan Hagen: > portcheck, make port-lib-depends-check: ok > make test: > amd64 - up to test 165 all good, then I ran out of disk space > sparc64 - passed Well, I get: 89: extracting even when . and .. are unreadableFAILED (extrac09.at:37) Looking at tests/testsuite.dir/089/testsuite.log in the work directory shows chmod a-r . .. tar -xvf archive.tar -C extract f [...] +tar: .: Cannot getcwd: Permission denied +tar: Error is not recoverable: exiting now I don't think our getcwd(3) fails this way. Which makes me think a gnulib wrapper has been enabled. Ah, yes, from the configure output: checking whether getcwd succeeds when 4k < cwd_length < 16k... no Hmmm. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: dev and deve and devel
On 2021-01-09, Jan Stary wrote: > The current ports.tar.gz contains a dev/ and deve/ directory > beside the expected devel/ category. Is that intended? The creation of those directories wasn't intended as such, they're the result of cvs import accidents, but once a directory has been created in CVS, it can never be deleted from the repository. However, the -P option will tell cvs checkout or update to remove now empty directories from a checked-out tree. Which ports.tar.gz are you referring to? They're not in here: https://ftp.openbsd.org/pub/OpenBSD/snapshots/ports.tar.gz -- Christian "naddy" Weisgerber na...@mips.inka.de
libc++ 10.0: editors/libreoffice
Here is some black magic extracted from upstream that fixes building
editors/libreoffice with libc++ 10.0, at least on amd64.
https://github.com/LibreOffice/core/commit/cc5a6c6afeed1d2cf76d288133971d29ee8d893e
ok?
Index: Makefile
===
RCS file: /cvs/ports/editors/libreoffice/Makefile,v
retrieving revision 1.239
diff -u -p -r1.239 Makefile
--- Makefile22 Dec 2020 15:28:19 - 1.239
+++ Makefile10 Jan 2021 23:21:17 -
@@ -38,6 +38,8 @@ DPB_PROPERTIES= parallel
EPOCH= 0
+REVISION= 0
+
MAINTAINER=Robert Nagy
HOMEPAGE= http://www.libreoffice.org/
Index: patches/patch-bridges_source_cpp_uno_gcc3_linux_x86-64_except_cxx
===
RCS file: patches/patch-bridges_source_cpp_uno_gcc3_linux_x86-64_except_cxx
diff -N patches/patch-bridges_source_cpp_uno_gcc3_linux_x86-64_except_cxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-bridges_source_cpp_uno_gcc3_linux_x86-64_except_cxx 10 Jan
2021 23:21:17 -
@@ -0,0 +1,69 @@
+$OpenBSD$
+
+gcc3_linux_x86_64 needs a hack to detect the reserve member in LLVM >= 10
+libcxxabi __cxa_exception, in addition to the existing hack for LLVM 5.
+https://github.com/LibreOffice/core/commit/cc5a6c6afeed1d2cf76d288133971d29ee8d893e
+
+Index: bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx
+--- bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx.orig
bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx
+@@ -82,6 +82,59 @@ extern "C" {
+ static void _GLIBCXX_CDTOR_CALLABI deleteException( void * pExc )
+ {
+ __cxxabiv1::__cxa_exception const * header =
static_cast<__cxxabiv1::__cxa_exception const *>(pExc) - 1;
++#if defined _LIBCPPABI_VERSION // detect libc++abi
++// First, the libcxxabi commit
++//
++// "[libcxxabi] Align unwindHeader on a double-word boundary" towards
++// LLVM 5.0 changed the size of __cxa_exception by adding
++//
++// __attribute__((aligned))
++//
++// to the final member unwindHeader, on x86-64 effectively adding a hole
of
++// size 8 in front of that member (changing its offset from 88 to 96,
++// sizeof(__cxa_exception) from 120 to 128, and alignof(__cxa_exception)
++// from 8 to 16); the "header1" hack below to dynamically determine
whether we run against a
++// LLVM 5 libcxxabi is to look at the exceptionDestructor member, which
must
++// point to this function (the use of __cxa_exception in fillUnoException
is
++// unaffected, as it only accesses members towards the start of the
struct,
++// through a pointer known to actually point at the start). The
libcxxabi commit
++//
++// "Insert padding before the __cxa_exception header to ensure the
thrown" in LLVM 6
++// removes the need for this hack, so the "header1" hack can be removed
again once we can be
++// sure that we only run against libcxxabi from LLVM >= 6.
++//
++// Second, the libcxxabi commit
++//
++// "[libcxxabi] Insert padding in __cxa_exception struct for
compatibility" in LLVM 10 changed
++// the layout of the start of __cxa_exception to
++//
++// [8 byte void *reserve]
++// 8 byte size_t referenceCount
++//
++// so the "header2" hack below to dynamically determine whether we run
against a LLVM >= 10
++// libcxxabi is to look whether the exceptionDestructor (with its known
value) has increased its
++// offset by 8. As described in the definition of __cxa_exception
++// (bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx), the "header2"
hack (together with the
++// "#if 0" in the definition of __cxa_exception and the corresponding
hack in fillUnoException)
++// can be dropped once we can be sure that we only run against new
libcxxabi that has the
++// reserve member.
++if (header->exceptionDestructor != &deleteException) {
++auto const header1 = reinterpret_cast<__cxa_exception const *>(
++reinterpret_cast(header) - 8);
++if (header1->exceptionDestructor == &deleteException) {
++header = header1;
++} else {
++auto const header2 = reinterpret_cast<__cxa_exception const *>(
++reinterpret_cast(header) + 8);
++if (header2->exceptionDestructor == &deleteException) {
++header = header2;
++} else {
++assert(false);
++}
++}
++}
++#endif
++assert(header->exceptionDestructor == &deleteException);
+ typelib_TypeDescription * pTD = nullptr;
+ OUString unoName( toUNOname( header->exceptionType->name() ) );
+ ::typelib_typedescription_ge
Re: [update] archivers/gtar 1.32 ->1.33
Stefan Hagen: > > The diff below reverts the getcwd check in question and the testsuite > > will pass. > > New patch. The previous was full with stuff I tried... Thanks. I have reported the problem upstream. There is no urgency to updating the port, so let's wait a bit and see if they come up with a permanent fix. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Libreoffice Application Error after Jan 13 snapshot
On 2021-01-14, Ed Ahlsen-Girard wrote: > Libreoffice puts the splash screen up and closes within two > seconds, with a message on the command line of Application Error. > Nothing is logged in messages. So it seems that LibreOffice is broken with libc++ 10.0 and the upstream fix I added is not enough. OpenBSD is definitely not the only system to build LibreOffice with clang 10.0. Corresponding fixes must be out there somewhere... -- Christian "naddy" Weisgerber na...@mips.inka.de
textproc/py-sphinx,python3 build failure
textproc/py-sphinx,python3 failed to build in my latest amd64 bulk build. ModuleNotFoundError: No module named 'setuptools_scm' >>> Building on amd64-2 under textproc/py-sphinx,python3 BDEPENDS = [www/py-jinja2,python3;devel/py-setuptools,python3;devel/py-six,python3;textproc/py-alabaster,python3;textproc/py-snowballstemmer,python3;graphics/py-imagesize,python3;textproc/py-pygments,python3;textproc/py-docutils,python3;devel/py-babel,python3;www/py-requests,python3;lang/python/3.8] DIST = [textproc/py-sphinx,python3:Sphinx-1.5.6.tar.gz] FULLPKGNAME = py3-sphinx-1.5.6 RDEPENDS = [textproc/py-pygments,python3;graphics/py-imagesize,python3;textproc/py-snowballstemmer,python3;textproc/py-alabaster,python3;devel/py-six,python3;devel/py-setuptools,python3;www/py-jinja2,python3;lang/python/3.8;www/py-requests,python3;devel/py-babel,python3;textproc/py-docutils,python3] (Junk lock obtained for amd64-2 at 1611681471.46) >>> Running depends in textproc/py-sphinx,python3 at 1611681471.52 last junk was in devel/py-parso,python3 /usr/sbin/pkg_add -aI -Drepair py3-alabaster-0.7.10p2 py3-babel-2.8.0p0 py3-docutils-0.12p3 py3-imagesize-1.1.0p2 py3-jinja2-2.11.2p1 py3-pygments-2.5.2p1 py3-requests-2.25.0 py3-setuptools-44.1.1v0 py3-six-1.15.0 py3-snowballstemmer-2.0.0 was: /usr/sbin/pkg_add -aI -Drepair py3-alabaster-0.7.10p2 py3-babel-2.8.0p0 py3-docutils-0.12p3 py3-imagesize-1.1.0p2 py3-jinja2-2.11.2p1 py3-pygments-2.5.2p1 py3-requests-2.25.0 py3-setuptools-44.1.1v0 py3-six-1.15.0 py3-snowballstemmer-2.0.0 python-3.8.7 /usr/sbin/pkg_add -aI -Drepair py3-alabaster-0.7.10p2 py3-babel-2.8.0p0 py3-docutils-0.12p3 py3-imagesize-1.1.0p2 py3-jinja2-2.11.2p1 py3-pygments-2.5.2p1 py3-requests-2.25.0 py3-setuptools-44.1.1v0 py3-six-1.15.0 py3-snowballstemmer-2.0.0 >>> Running show-prepare-results in textproc/py-sphinx,python3 at 1611681475.35 ===> textproc/py-sphinx,python3 ===> py3-sphinx-1.5.6 depends on: py3-babel-* -> py3-babel-2.8.0p0 ===> py3-sphinx-1.5.6 depends on: py3-six-* -> py3-six-1.15.0 ===> py3-sphinx-1.5.6 depends on: py3-imagesize-* -> py3-imagesize-1.1.0p2 ===> py3-sphinx-1.5.6 depends on: py3-alabaster-* -> py3-alabaster-0.7.10p2 ===> py3-sphinx-1.5.6 depends on: py3-docutils-* -> py3-docutils-0.12p3 ===> py3-sphinx-1.5.6 depends on: py3-pygments-* -> py3-pygments-2.5.2p1 ===> py3-sphinx-1.5.6 depends on: py3-snowballstemmer-* -> py3-snowballstemmer-2.0.0 ===> py3-sphinx-1.5.6 depends on: py3-jinja2-* -> py3-jinja2-2.11.2p1 ===> py3-sphinx-1.5.6 depends on: py3-requests-* -> py3-requests-2.25.0 ===> py3-sphinx-1.5.6 depends on: python->=3.8,<3.9 -> python-3.8.7 ===> py3-sphinx-1.5.6 depends on: py3-setuptools->=39.0.1v0 -> py3-setuptools-44.1.1v0 py3-alabaster-0.7.10p2 py3-babel-2.8.0p0 py3-docutils-0.12p3 py3-imagesize-1.1.0p2 py3-jinja2-2.11.2p1 py3-pygments-2.5.2p1 py3-requests-2.25.0 py3-setuptools-44.1.1v0 py3-six-1.15.0 py3-snowballstemmer-2.0.0 python-3.8.7 (Junk lock released for amd64-2 at 1611681476.62) Woken up devel/py-jaraco-functools,python3 distfiles size=4410607 >>> Running build in textproc/py-sphinx,python3 at 1611681476.70 ===> textproc/py-sphinx,python3 ===> Checking files for py3-sphinx-1.5.6 `/usr/ports/distfiles/Sphinx-1.5.6.tar.gz' is up to date. >> (SHA256) Sphinx-1.5.6.tar.gz: OK ===> Extracting for py3-sphinx-1.5.6 ===> Patching for py3-sphinx-1.5.6 ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ ===> Generating configure for py3-sphinx-1.5.6 ===> Configuring for py3-sphinx-1.5.6 ===> Building for py3-sphinx-1.5.6 running egg_info writing Sphinx.egg-info/PKG-INFO writing dependency_links to Sphinx.egg-info/dependency_links.txt writing entry points to Sphinx.egg-info/entry_points.txt writing requirements to Sphinx.egg-info/requires.txt writing top-level names to Sphinx.egg-info/top_level.txt reading manifest file 'Sphinx.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no files found matching 'sphinx/locale/.tx/config' no previously-included directories found matching 'doc/_build' no previously-included directories found matching 'sphinx/locale/.tx' writing manifest file 'Sphinx.egg-info/SOURCES.txt' running build running build_py creating /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib creating /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/__init__.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/__main__.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/addnodes.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/apidoc.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/application.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1
Re: Build failures from -fno-common
Christian Weisgerber:
> I'll send a followup message with additional background information.
So what's a "common (variable)"? When multiple object files have
an externally visible variable with the same name, the linker will
merge these variables so that they all refer to the same memory
location.
This is an ancient linker feature. It was never part of any C
language standard. In fact C is quite explicit that you can
only define a variable in one object file
int number;
and then have to declare it elsewhere:
extern int number;
A declaration makes a name and type known. A definition additionally
reserves memory for a variable (or creates code for a function).
One frequent way to end up with commons is to put a definition in
a header file that is included by multiple source files.
How to fix commons? The first step is to determine whether they
are intentional or whether they are an accidental name clash, a bug
in fact. Intentionally shared variables should just be defined in
one place and declared with "extern" elsewhere. Accidental ones
can either be renamed or their visibility limited to the same source
file by declaring them "static".
Both LLVM11 and GCC10 no longer permit commons by default. FreeBSD
has already switched to LLVM11 and quick-moving Linux distributions
are switching to GCC10.
To fix a port, in order of preference:
(1) Update to a newer release that is already fixed.
(2) Cherry-pick a fix from an upstream repository if not already
included in a newer release.
(3) Create a patch yourself, or copy one from FreeBSD etc., if
no upstream fix is available.
(4) Explicitly permit commons by adding -fcommon to CFLAGS if
the code base really depends on it.
How to reproduce build errors due to commons? Since we haven't
switched compilers yet, you can add -fno-common to CFLAGS. For
large scale work on this, it is easier to rebuild your compiler so
that it defaults to -fno-common. Below is a diff for our in-tree
clang:
Index: gnu/llvm/clang/include/clang/Driver/Options.td
===
RCS file: /cvs/src/gnu/llvm/clang/include/clang/Driver/Options.td,v
retrieving revision 1.3
diff -u -p -r1.3 Options.td
--- gnu/llvm/clang/include/clang/Driver/Options.td 1 Dec 2020 13:30:13
- 1.3
+++ gnu/llvm/clang/include/clang/Driver/Options.td 26 Jan 2021 21:09:47
-
@@ -840,7 +840,8 @@ def fno_record_command_line : Flag<["-"]
Group;
def : Flag<["-"], "frecord-gcc-switches">, Alias;
def : Flag<["-"], "fno-record-gcc-switches">, Alias;
-def fcommon : Flag<["-"], "fcommon">, Group;
+def fcommon : Flag<["-"], "fcommon">, Group,
+ Flags<[CoreOption, CC1Option]>, HelpText<"Place uninitialized global
variables in a common block">;
def fcompile_resource_EQ : Joined<["-"], "fcompile-resource=">, Group;
def fcomplete_member_pointers : Flag<["-"], "fcomplete-member-pointers">,
Group,
Flags<[CoreOption, CC1Option]>,
Index: gnu/llvm/clang/lib/Driver/ToolChains/Clang.cpp
===
RCS file: /cvs/src/gnu/llvm/clang/lib/Driver/ToolChains/Clang.cpp,v
retrieving revision 1.3
diff -u -p -r1.3 Clang.cpp
--- gnu/llvm/clang/lib/Driver/ToolChains/Clang.cpp 1 Dec 2020 13:30:13
- 1.3
+++ gnu/llvm/clang/lib/Driver/ToolChains/Clang.cpp 26 Jan 2021 21:09:47
-
@@ -1404,20 +1404,6 @@ static bool isSignedCharDefault(const ll
}
}
-static bool isNoCommonDefault(const llvm::Triple &Triple) {
- switch (Triple.getArch()) {
- default:
-if (Triple.isOSFuchsia())
- return true;
-return false;
-
- case llvm::Triple::xcore:
- case llvm::Triple::wasm32:
- case llvm::Triple::wasm64:
-return true;
- }
-}
-
static bool hasMultipleInvocations(const llvm::Triple &Triple,
const ArgList &Args) {
// Supported only on Darwin where we invoke the compiler multiple times
@@ -5638,11 +5624,9 @@ void Clang::ConstructJob(Compilation &C,
if (!Args.hasFlag(options::OPT_Qy, options::OPT_Qn, true))
CmdArgs.push_back("-Qn");
- // -fcommon is the default unless compiling kernel code or the target says so
- bool NoCommonDefault = KernelOrKext || isNoCommonDefault(RawTriple);
- if (!Args.hasFlag(options::OPT_fcommon, options::OPT_fno_common,
-!NoCommonDefault))
-CmdArgs.push_back("-fno-common");
+ // -fno-common is the default, set -fcommon only when that flag is set.
+ if (Args.hasFlag(options::OPT_fcommon, options::OPT_fno_common, false))
+CmdArgs.push_back("-fcommon");
// -fsigned-bitfields is default, and clang doesn't yet support
// -funsigned
Build failures from -fno-common
Here are the results from a first amd64 bulk build with -fno-common. It's very much a case of mixed news. The good news is that few ports with a significant number of dependencies failed, and consequently most of the tree built. The bad news is that there are about 300 mostly leaf ports that failed individually. I'll send a followup message with additional background information. Meanwhile, here's the full list: archivers/arc - ports@openbsd.org archivers/gshar+gunshar - ports@openbsd.org astro/sattrack - ports@openbsd.org astro/wmglobe - ports@openbsd.org astro/wmmoonclock - ports@openbsd.org astro/wmspaceweather- ports@openbsd.org astro/wmsun - ports@openbsd.org audio/audacity UPDATEports@openbsd.org audio/gimmix- ports@openbsd.org audio/gtkpodUPDATEports@openbsd.org audio/mp3splt-gtk UPDATEports@openbsd.org audio/mpg321- na...@openbsd.org audio/musepack - ports@openbsd.org audio/nspmod- ports@openbsd.org audio/py-ogg- ports@openbsd.org audio/scmpc - ports@openbsd.org audio/soundtracker - ports@openbsd.org audio/speech-dispatcher UPDATEports@openbsd.org audio/vgmplay - bcal...@openbsd.org audio/wmmp3 - ports@openbsd.org audio/wmtune- ports@openbsd.org audio/xhippo- ports@openbsd.org audio/ympd - ports@openbsd.org benchmarks/netperf UPDATEports@openbsd.org biology/nutdb - ports@openbsd.org cad/geda-gaf- e...@openbsd.org cad/gerbv - bcal...@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/c3270 - jer...@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/minicom - ports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/smstools - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/citus UPDATEports@openbsd.org databases/db/v3 - ports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/arm-none-eabi/gdb UPDATEports@openbsd.org devel/avr32/binutils- ports@openbsd.org devel/blame - ports@openbsd.org devel/boehm-gc UPDATEports@openbsd.org devel/distccUPDATEports@openbsd.org devel/dtc UPDATEports@openbsd.org devel/libgcrootsUPDATEports@openbsd.org devel/libmtpUPDATEports@openbsd.org devel/libowfat - j.klem...@wemelug.de devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org devel/ti-msp430gcc - ports@openbsd.org editors/beaver - ports@openbsd.org editors/hexcurse- ports@openbsd.org editors/hnb - ports@openbsd.org editors/tea UPDATEports@openbsd.org education/epte - ports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/advancemame - ports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/mupen64plus/core - anth...@anjbe.name emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/ace
Re: Remove astro/sattrack
On 2021-01-30, Klemens Nanni wrote: > Imported in 1998 and modified in 2009 to "fix Y2K bug" which means > "we may not distribute modified versions [due to its license]". > Feedback? Objections? OK? ok FreeBSD removed it in 2011, "No more public distfiles". -- Christian "naddy" Weisgerber na...@mips.inka.de
audio/libgpod build failure (python)
In my latest amd64 bulk build, audio/libgpod failed to build: configure: error: pygobject support explicitly requested but pygobject couldn't be found >>> Building on localhost under audio/libgpod BDEPENDS = [graphics/gdk-pixbuf2;devel/glib2;textproc/libxml;devel/gettext,-runtime;devel/libusb1;devel/libplist;textproc/intltool;databases/sqlite3;devel/gmake] DIST = [audio/libgpod:libgpod-0.8.0.tar.gz] FULLPKGNAME = libgpod-0.8.0p11 RDEPENDS = [devel/gettext,-runtime;devel/libplist;devel/libusb1;devel/glib2;graphics/gdk-pixbuf2;textproc/libxml;databases/sqlite3] (Junk lock obtained for localhost at 1612002203.11) >>> Running depends in audio/libgpod at 1612002203.17 last junk was in x11/kde-applications/rocs /usr/sbin/pkg_add -aI -Drepair gdk-pixbuf-2.42.2 glib2-2.66.4 libplist-1.12p1 libusb1-1.0.23p2 libxml-2.9.10p2 was: /usr/sbin/pkg_add -aI -Drepair gdk-pixbuf-2.42.2 gettext-runtime-0.21p0 glib2-2.66.4 gmake-4.3 intltool-0.51.0p2 libplist-1.12p1 libusb1-1.0.23p2 libxml-2.9.10p2 sqlite3-3.34.0 /usr/sbin/pkg_add -aI -Drepair gdk-pixbuf-2.42.2 glib2-2.66.4 libplist-1.12p1 libusb1-1.0.23p2 libxml-2.9.10p2 >>> Running show-prepare-results in audio/libgpod at 1612002205.50 ===> audio/libgpod ===> libgpod-0.8.0p11 depends on: intltool->=0.41.1p0 -> intltool-0.51.0p2 ===> libgpod-0.8.0p11 depends on: gmake-* -> gmake-4.3 ===> libgpod-0.8.0p11 depends on: sqlite3-* -> sqlite3-3.34.0 ===> libgpod-0.8.0p11 depends on: gettext-runtime-* -> gettext-runtime-0.21p0 ===> libgpod-0.8.0p11 depends on: glib2-* -> glib2-2.66.4 ===> libgpod-0.8.0p11 depends on: libplist-* -> libplist-1.12p1 ===> libgpod-0.8.0p11 depends on: gdk-pixbuf-* -> gdk-pixbuf-2.42.2 ===> libgpod-0.8.0p11 depends on: libxml-* -> libxml-2.9.10p2 ===> libgpod-0.8.0p11 depends on: libusb1-* -> libusb1-1.0.23p2 ===> Verifying specs: c ffi gdk_pixbuf-2.0 gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 iconv intl lzma m pcre plist pthread sqlite3 usb-1.0 xml2 z ===> found c.96.0 ffi.1.2 gdk_pixbuf-2.0.3200.3 gio-2.0.4200.12 glib-2.0.4201.5 gmodule-2.0.4200.12 gobject-2.0.4200.12 iconv.7.0 intl.7.0 lzma.2.1 m.10.1 pcre.3.0 plist.2.0 pthread.26.1 sqlite3.37.11 usb-1.0.1.2 xml2.16.1 z.5.0 gdk-pixbuf-2.42.2 gettext-runtime-0.21p0 glib2-2.66.4 gmake-4.3 intltool-0.51.0p2 libplist-1.12p1 libusb1-1.0.23p2 libxml-2.9.10p2 sqlite3-3.34.0 (Junk lock released for localhost at 1612002206.65) distfiles size=997674 >>> Running build in audio/libgpod at 1612002206.71 ===> audio/libgpod ===> Checking files for libgpod-0.8.0p11 `/usr/ports/distfiles/libgpod-0.8.0.tar.gz' is up to date. >> (SHA256) libgpod-0.8.0.tar.gz: OK ===> Extracting for libgpod-0.8.0p11 ===> Patching for libgpod-0.8.0p11 ===> Applying OpenBSD patch patch-bindings_python_gpod_i_in Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-bindings_python_gpod_i_in,v 1.1 2017/11/01 16:41:44 rsadowski Exp $ | |Use SWIG C++-style comments instead of Python comments which |SWIG interprets as preprocessor directives. | | |Index: bindings/python/gpod.i.in |--- bindings/python/gpod.i.in.orig |+++ bindings/python/gpod.i.in -- Patching file bindings/python/gpod.i.in using Plan A... Hunk #1 succeeded at 296. done ===> Applying OpenBSD patch patch-configure Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-configure,v 1.1 2013/10/25 19:12:07 naddy Exp $ | |Do not pick up TagLib, which is only used by test-rebuild-db. | |--- configure.orig Tue Oct 12 13:59:23 2010 |+++ configure Fri Oct 25 21:08:25 2013 -- Patching file configure using Plan A... Hunk #1 succeeded at 16900. done ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ ===> Generating configure for libgpod-0.8.0p11 ===> Configuring for libgpod-0.8.0p11 Using /usr/obj/ports/libgpod-0.8.0/config.site (generated) configure: loading site script /usr/obj/ports/libgpod-0.8.0/config.site checking for a BSD-compatible install... /usr/obj/ports/libgpod-0.8.0/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... mkdir -p checking for gawk... (cached) awk checking whether gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by gmake... GNU checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... (cached) o checking whether we are using the GNU C compiler... (cached) yes checking whether cc accepts -g... (cached) yes ch
Re: [update] x11/xvkbd (Re: Build failures from -fno-common)
Yozo TODA: > here attached xvkbd updates to 4.1 where > * -fno-common problem is fixed > * change CONFIGURE_STYLE to gnu since configure is provided > * port-lib-depends-check passes > * compiles and works on amd64, with Xquartz/macOS as X server > > anyone please check and commit to the ports tree? Thank you. Unfortunately your mailer has garbled the attachment. Can you resend it? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Remove audio/gimmix
Klemens Nanni: > Upstream is completely dead, even FreeBSD has marked their port as such > (EXPIRATION DATE: 2021-04-01, not sure what will happen then, though). It will be removed. r...@freebsd.org performs regular "Remove expired ports" commits. -- Christian "naddy" Weisgerber na...@mips.inka.de
Update: devel/libmtp 1.1.18, -fno-common fix
This updates devel/libmtp to the latest release 1.1.18, which also
includes a -fno-common fix. No major changes, one function was added.
No idea how to test actual functionality.
OK?
Index: Makefile
===
RCS file: /cvs/ports/devel/libmtp/Makefile,v
retrieving revision 1.42
diff -u -p -r1.42 Makefile
--- Makefile12 Jul 2019 20:44:39 - 1.42
+++ Makefile1 Feb 2021 20:35:57 -
@@ -2,10 +2,10 @@
COMMENT= Media Transfer Protocol (MTP) implementation
-DISTNAME= libmtp-1.1.15
+DISTNAME= libmtp-1.1.18
CATEGORIES=devel
-SHARED_LIBS += mtp 7.0 # 12.0
+SHARED_LIBS += mtp 7.1 # 13.0
HOMEPAGE= http://libmtp.sourceforge.net/
Index: distinfo
===
RCS file: /cvs/ports/devel/libmtp/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- distinfo28 Apr 2018 13:05:45 - 1.18
+++ distinfo1 Feb 2021 20:35:57 -
@@ -1,2 +1,2 @@
-SHA256 (libmtp-1.1.15.tar.gz) = 0ECQC0Z1fjEbH7O/qMBdsJyLaBHgRLzoyIyfP206MCE=
-SIZE (libmtp-1.1.15.tar.gz) = 805983
+SHA256 (libmtp-1.1.18.tar.gz) = coD+UMBEyBigZmf0XqvKiE3qsxk8qoaC4LWB6EeigfA=
+SIZE (libmtp-1.1.18.tar.gz) = 832463
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/libmtp/pkg/PLIST,v
retrieving revision 1.17
diff -u -p -r1.17 PLIST
--- pkg/PLIST 31 Jan 2017 10:01:50 - 1.17
+++ pkg/PLIST 1 Feb 2021 20:35:57 -
@@ -21,7 +21,7 @@ bin/mtp-sendtr
@bin bin/mtp-tracks
@bin bin/mtp-trexist
include/libmtp.h
-lib/libmtp.a
+@static-lib lib/libmtp.a
lib/libmtp.la
@lib lib/libmtp.so.${LIBmtp_VERSION}
lib/pkgconfig/libmtp.pc
--
Christian "naddy" Weisgerber na...@mips.inka.de
Build failures from -fno-common (2021-02-01)
Here is an updated list of ports that fail to build with -fno-common. astro/wmglobe - ports@openbsd.org astro/wmmoonclock - ports@openbsd.org astro/wmspaceweather- ports@openbsd.org astro/wmsun - ports@openbsd.org audio/audacity UPDATEports@openbsd.org audio/gimmix- ports@openbsd.org audio/gtkpodUPDATEports@openbsd.org audio/mp3splt-gtk UPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/scmpc - ports@openbsd.org audio/wmmp3 - ports@openbsd.org audio/wmtune- ports@openbsd.org audio/xhippo- ports@openbsd.org audio/ympd - ports@openbsd.org benchmarks/netperf UPDATEports@openbsd.org cad/geda-gaf- e...@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/minicom - ports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/citus UPDATEports@openbsd.org databases/db/v3 - ports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/arm-none-eabi/gdb UPDATEports@openbsd.org devel/avr32/binutils- ports@openbsd.org devel/blame - ports@openbsd.org devel/boehm-gc UPDATEports@openbsd.org devel/distccUPDATEports@openbsd.org devel/libgcrootsUPDATEports@openbsd.org devel/libmtpUPDATEports@openbsd.org devel/libowfat - j.klem...@wemelug.de devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org devel/ti-msp430gcc - ports@openbsd.org editors/beaver - ports@openbsd.org editors/hexcurse- ports@openbsd.org editors/hnb - ports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/advancemame - ports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/angband UPDATEe...@openbsd.org games/atomix- ports@openbsd.org games/clonekeen - e...@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freeblocks- ports@openbsd.org games/freedroid - ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnugo - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/gnushogi - ports@openbsd.org games/heroes- anth...@anjbe.name games/jumpnbump - bcal...@openbsd.org games/lincity - ports@openbsd.org games/megaglest/base- ports@openbsd.org games/mirrormagic - ports@openbsd.org games/nethack/3.6 - es...@openbsd.org games/oolite- n...@openbsd.org games/openjk- bcal...@openbsd.org games/opentyrian- ports@openbsd.org games/pacman-arena - ports@openbsd.org games/prboom
x11/menu-cache: fix for -fno-common
Fix build with -fno-common.
The header file erroneously defines the global variables instead of
simply declaring them.
No recent upstream activity.
ok?
Index: Makefile
===
RCS file: /cvs/ports/x11/menu-cache/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile12 Jul 2019 20:51:17 - 1.11
+++ Makefile1 Feb 2021 21:46:32 -
@@ -4,7 +4,7 @@ COMMENT=caching mechanism for freedesk
DISTNAME= menu-cache-1.1.0
EXTRACT_SUFX= .tar.xz
-REVISION= 0
+REVISION= 1
SHARED_LIBS += menu-cache 1.0 # 4.1
Index: patches/patch-menu-cache-gen_menu-tags_h
===
RCS file: patches/patch-menu-cache-gen_menu-tags_h
diff -N patches/patch-menu-cache-gen_menu-tags_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-menu-cache-gen_menu-tags_h1 Feb 2021 21:46:32 -
@@ -0,0 +1,110 @@
+$OpenBSD$
+
+Index: menu-cache-gen/menu-tags.h
+--- menu-cache-gen/menu-tags.h.orig
menu-cache-gen/menu-tags.h
+@@ -22,38 +22,38 @@
+ #include
+ #include
+
+-FmXmlFileTag menuTag_Menu;
+-FmXmlFileTag menuTag_AppDir;
+-FmXmlFileTag menuTag_DefaultAppDirs;
+-FmXmlFileTag menuTag_DirectoryDir;
+-FmXmlFileTag menuTag_DefaultDirectoryDirs;
+-FmXmlFileTag menuTag_Include;
+-FmXmlFileTag menuTag_Exclude;
+-FmXmlFileTag menuTag_Filename;
+-FmXmlFileTag menuTag_Or;
+-FmXmlFileTag menuTag_And;
+-FmXmlFileTag menuTag_Not;
+-FmXmlFileTag menuTag_Category;
+-FmXmlFileTag menuTag_MergeFile;
+-FmXmlFileTag menuTag_MergeDir;
+-FmXmlFileTag menuTag_DefaultMergeDirs;
+-FmXmlFileTag menuTag_Directory;
+-FmXmlFileTag menuTag_Name;
+-FmXmlFileTag menuTag_Deleted;
+-FmXmlFileTag menuTag_NotDeleted;
+-FmXmlFileTag menuTag_OnlyUnallocated;
+-FmXmlFileTag menuTag_NotOnlyUnallocated;
+-FmXmlFileTag menuTag_All;
+-FmXmlFileTag menuTag_LegacyDir;
+-FmXmlFileTag menuTag_KDELegacyDirs;
+-FmXmlFileTag menuTag_Move;
+-FmXmlFileTag menuTag_Old;
+-FmXmlFileTag menuTag_New;
+-FmXmlFileTag menuTag_Layout;
+-FmXmlFileTag menuTag_DefaultLayout;
+-FmXmlFileTag menuTag_Menuname;
+-FmXmlFileTag menuTag_Separator;
+-FmXmlFileTag menuTag_Merge;
++extern FmXmlFileTag menuTag_Menu;
++extern FmXmlFileTag menuTag_AppDir;
++extern FmXmlFileTag menuTag_DefaultAppDirs;
++extern FmXmlFileTag menuTag_DirectoryDir;
++extern FmXmlFileTag menuTag_DefaultDirectoryDirs;
++extern FmXmlFileTag menuTag_Include;
++extern FmXmlFileTag menuTag_Exclude;
++extern FmXmlFileTag menuTag_Filename;
++extern FmXmlFileTag menuTag_Or;
++extern FmXmlFileTag menuTag_And;
++extern FmXmlFileTag menuTag_Not;
++extern FmXmlFileTag menuTag_Category;
++extern FmXmlFileTag menuTag_MergeFile;
++extern FmXmlFileTag menuTag_MergeDir;
++extern FmXmlFileTag menuTag_DefaultMergeDirs;
++extern FmXmlFileTag menuTag_Directory;
++extern FmXmlFileTag menuTag_Name;
++extern FmXmlFileTag menuTag_Deleted;
++extern FmXmlFileTag menuTag_NotDeleted;
++extern FmXmlFileTag menuTag_OnlyUnallocated;
++extern FmXmlFileTag menuTag_NotOnlyUnallocated;
++extern FmXmlFileTag menuTag_All;
++extern FmXmlFileTag menuTag_LegacyDir;
++extern FmXmlFileTag menuTag_KDELegacyDirs;
++extern FmXmlFileTag menuTag_Move;
++extern FmXmlFileTag menuTag_Old;
++extern FmXmlFileTag menuTag_New;
++extern FmXmlFileTag menuTag_Layout;
++extern FmXmlFileTag menuTag_DefaultLayout;
++extern FmXmlFileTag menuTag_Menuname;
++extern FmXmlFileTag menuTag_Separator;
++extern FmXmlFileTag menuTag_Merge;
+
+ typedef enum {
+ MERGE_NONE, /* starting value */
+@@ -152,19 +152,19 @@ typedef struct {
+ } MenuRule;
+
+ /* requested language(s) */
+-char **languages;
++extern char **languages;
+
+ /* list of menu files to monitor */
+-GSList *MenuFiles;
++extern GSList *MenuFiles;
+
+ /* list of menu dirs to monitor */
+-GSList *MenuDirs;
++extern GSList *MenuDirs;
+
+ /* list of available app dirs */
+-GSList *AppDirs;
++extern GSList *AppDirs;
+
+ /* list of available dir dirs */
+-GSList *DirDirs;
++extern GSList *DirDirs;
+
+ /* parse and merge menu files */
+ MenuMenu *get_merged_menu(const char *file, FmXmlFile **xmlfile, GError
**error);
+@@ -177,7 +177,7 @@ gboolean save_menu_cache(MenuMenu *layout, const char
+ void _free_layout_items(GList *data);
+
+ /* verbosity level */
+-gint verbose;
++extern gint verbose;
+
+ #define DBG if (verbose) g_debug
+ #define VDBG if (verbose > 1) g_debug
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: Update lang/iverilog to 11.0 (fixes no-common)
Greg Steuck: > iverilog still starts. But the regression tests fail: driver/iverilog -B. -BMvpi -BPivlpp -tcheck -ocheck.vvp ./examples/hello.vl Cannot locate IVL modules : couldn't get command path from OS. gmake: *** [Makefile:141: check] Error 1 -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: FIX: devel/gettext on hppa
k...@intricatesoftware.com: > gettext fails to build on hppa with an undefined reference to > `__sync_val_compare_and_swap_4'. The following allows it to build > but it uses the fallback code that is not threadsafe. okay? ok naddy@ -- Christian "naddy" Weisgerber na...@mips.inka.de
Remove multimedia/avinfo?
multimedia/avinfo needs to be fixed for -fno-common, but I'm leaning towards just removing it. Avinfo is an utility for displaying AVI, MPEG, OGG/OGM, MKV, IFO header information. It returns the length of a clip, FPS, resolution, codecs, sound parameters, and the number, type and language of the stream. The last release was some 15 years ago. Which means it won't even recognize some of today's formats. I tried to run it against a recent A/V file, and it just dumped core from free(). Nowadays, mediainfo provides such functionality. OK to remove? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: x11/skippy: fix with -fno-common
Charlene Wendling: > The below diff allows building skippy with -fno-common. While here: > > - MASTER_SITES and HOMEPAGE are 404'd, drop them > - refresh WANTLIB > - don't hardcode PREFIX, don't build with -g > - add -fno-common fix, from Gentoo [0] (and add a missing RCS tag) Hmm, a port without MASTER_SITES? I guess there are precedence cases. ok naddy@ There is a fork on GitHub, but the last activity was in 2015. https://github.com/richardgv/skippy-xd -- Christian "naddy" Weisgerber na...@mips.inka.de
textproc/calibre build failure
In my latest amd64 bulk build, textproc/calibre failed to build. Error: /usr/obj/ports/calibre-2.85.1/fake-amd64/usr/local/share/bash-completion/completions/calibre does not exist Wild guess: A stealth dependency on bash? Full log attached. -- Christian "naddy" Weisgerber na...@mips.inka.de calibre.log.xz Description: application/xz
Build failures from -fno-common (2021-02-07)
Here is an updated list of ports that fail to build with -fno-common. This is now the default for base clang, so those are now regular bulk build failures. "UPDATE" means that an update is available according to portroach. astro/wmspaceweather- ports@openbsd.org astro/wmsun - ports@openbsd.org audio/audacity UPDATEports@openbsd.org audio/gimmix- ports@openbsd.org audio/gtkpodUPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org audio/xhippo- ports@openbsd.org cad/geda-gaf- e...@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/citus UPDATEports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/arm-none-eabi/gdb UPDATEports@openbsd.org devel/avr32/binutils- ports@openbsd.org devel/blame - ports@openbsd.org devel/giggle- ports@openbsd.org devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org devel/ti-msp430gcc - ports@openbsd.org editors/beaver - ports@openbsd.org editors/hexcurse- ports@openbsd.org editors/hnb - ports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/mupen64plus/rsp-cxd4 - anth...@anjbe.name emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/angband UPDATEe...@openbsd.org games/atomix- ports@openbsd.org games/clonekeen - e...@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freeblocks- ports@openbsd.org games/freedroid - ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/heroes- anth...@anjbe.name games/mirrormagic - ports@openbsd.org games/nethack/3.6 - es...@openbsd.org games/oolite- n...@openbsd.org games/openjk- bcal...@openbsd.org games/opentyrian- ports@openbsd.org games/pacman-arena - ports@openbsd.org games/prboom- ports@openbsd.org games/prboom-plus - r...@slipgate.org games/sdlpop- rob...@openbsd.org games/sdlroids - ports@openbsd.org games/spider- ports@openbsd.org games/typespeed - ports@openbsd.org games/vms-empire- ports@openbsd.org games/xboing- ports@openbsd.org geo/pgpointcloud- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/enjoympeg - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org graphics/ocaml-cairoUPDATEports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au japanese/Wnn- es...@openbsd.org japanese/onew - es...@openbsd.org lang/ar
Remove x11/xfed?
I fixed up x11/xfed for -fno-common, but trying to run it with a random .bdf file from xenocara, I just get a parse error. Judging by the time stamps in the archive, it was packaged in 1998 with the actual source files having dates from 1989 and 1991. The master site disappeared a long time ago. FreeBSD removed the port ten years ago. I think it's time to delete this port. OK? -- Christian "naddy" Weisgerber na...@mips.inka.de
www/liferea build failure (webkitgtk4?)
In my latest amd64 bulk build, www/liferea failed to build. Maybe somebody has an idea what triggered this: ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to WebCore::presentingApplicationPID() ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to WebCore::Process::setIdentifier(WTF::ObjectIdentifier) ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to WebCore::Process::identifier() ... Log attached. -- Christian "naddy" Weisgerber na...@mips.inka.de liferea.log.xz Description: application/xz
x11/gnome/yelp build failure
Christian Weisgerber: > In my latest amd64 bulk build, www/liferea failed to build. > Maybe somebody has an idea what triggered this: > > ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to > WebCore::presentingApplicationPID() > ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to > WebCore::Process::setIdentifier(WTF::ObjectIdentifier) > ld: error: .libs/libwebkit2gtk-4.0.so.3.3: undefined reference to > WebCore::Process::identifier() > ... Same error in x11/gnome/yelp. -- Christian "naddy" Weisgerber na...@mips.inka.de yelp.log.xz Description: application/xz
Build failures from -fno-common (2021-02-09)
Here is an updated list of ports that fail to build with -fno-common. Reminder: The compiler default has been switched to -fno-common. These are now regular build failures in every bulk build (on the clang architectures). I have cc'ed everybody who is listed as a maintainer of at least one of these. astro/wmspaceweather- ports@openbsd.org astro/wmsun - ports@openbsd.org audio/audacity UPDATEports@openbsd.org audio/gimmix- ports@openbsd.org audio/gtkpodUPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org audio/xhippo- ports@openbsd.org cad/geda-gaf- e...@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/citus UPDATEports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/arm-none-eabi/gdb UPDATEports@openbsd.org devel/avr32/binutils- ports@openbsd.org devel/giggle- ports@openbsd.org devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org devel/ti-msp430gcc - ports@openbsd.org editors/beaver - ports@openbsd.org editors/hexcurse- ports@openbsd.org editors/hnb - ports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/mupen64plus/rsp-cxd4 - anth...@anjbe.name emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/angband UPDATEe...@openbsd.org games/atomix- ports@openbsd.org games/clonekeen - e...@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freeblocks- ports@openbsd.org games/freedroid - ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/heroes- anth...@anjbe.name games/mirrormagic - ports@openbsd.org games/nethack/3.6 - es...@openbsd.org games/oolite- n...@openbsd.org games/opentyrian- ports@openbsd.org games/pacman-arena - ports@openbsd.org games/prboom- ports@openbsd.org games/prboom-plus - r...@slipgate.org games/sdlpop- rob...@openbsd.org games/sdlroids - ports@openbsd.org games/spider- ports@openbsd.org games/vms-empire- ports@openbsd.org games/xboing- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/enjoympeg - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org graphics/ocaml-cairoUPDATEports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au japanese/onew - es...@openbsd.org lang/arena - ports@openbsd.org lang/erlang/19 - ports@openbsd.org lang/moarvm UPDATEpas...@stumpf.co lang/pccUPDATEports@openbsd.org
Build failures from -fno-common (2021-02-10)
Here is an updated list of ports that fail to build with -fno-common: astro/wmspaceweather- ports@openbsd.org astro/wmsun - ports@openbsd.org audio/audacity UPDATEports@openbsd.org audio/gtkpodUPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org cad/geda-gaf- e...@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/citus UPDATEports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/avr32/binutils- ports@openbsd.org devel/giggle- ports@openbsd.org devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org devel/ti-msp430gcc - ports@openbsd.org editors/beaver - ports@openbsd.org editors/hexcurse- ports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/mupen64plus/rsp-cxd4 - anth...@anjbe.name emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/angband UPDATEe...@openbsd.org games/atomix- ports@openbsd.org games/clonekeen - e...@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freeblocks- ports@openbsd.org games/freedroid - ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/heroes- anth...@anjbe.name games/mirrormagic - ports@openbsd.org games/nethack/3.6 - es...@openbsd.org games/oolite- n...@openbsd.org games/opentyrian- ports@openbsd.org games/pacman-arena - ports@openbsd.org games/sdlpop- rob...@openbsd.org games/sdlroids - ports@openbsd.org games/spider- ports@openbsd.org games/vms-empire- ports@openbsd.org games/xboing- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/enjoympeg - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org graphics/ocaml-cairoUPDATEports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au japanese/onew - es...@openbsd.org lang/arena - ports@openbsd.org lang/erlang/19 - ports@openbsd.org lang/moarvm UPDATEpas...@stumpf.co lang/pccUPDATEports@openbsd.org lang/snobol4UPDATEst...@wb8wsf.org mail/avengerUPDATEports@openbsd.org mail/mlmmj - ports@openbsd.org mail/sma- ports@openbsd.org mail/wmmultipop3- ports@openbsd.org mail/wmpop3 - ports@openbsd.org math/abs- ports@openbsd.org math/foma - ports@openbsd.org math/mcl- ports@openbsd.org math/pspp
Re: -fno-common for games/angband
Edd Barrett: > I think this is right. The variables in question are already defined in > mon-init.c, so just the missing `extern` qualifiers. Yes, that's exactly right. > No bump required I think. Maybe, but I suggest to bump all ports that get fixed nevertheless. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [macppc, all archs] net/echoping wants libm
Charlene Wendling: > > util.o: In function `tvstddev': > > util.c:(.text+0x6f4): undefined reference to `sqrt' > > The autoconf stuff really detects the need for`-lm' as seen in > config.log: 'ac_cv_lib_m_sqrt=yes', but is not used anywhere at all. No, we are preloading the autoconf cache with this and many other results. See infrastructure/db/config.site. There is no actual test for this in the configure script. There _is_ a test whether -lm is required for pow(3), "checking if libmath is mandatory". If you run nm(1) on the compiled util.o on amd64, there is no unresolved reference to sqrt(). What's happening here is that the compiler inlines its own optimized sqrt(), instead of calling the libm function. The same happens for pow() in the configure test. Or worse, I think the compiler notices that this lone pow() call has no effect and just drops it, neutering the test. If you compile with -ffreestanding, which is the ultimate hammer to prevent such shenanigans, util.o has a reference to sqrt() and the configure check for -lm actually works. Anyway, that's not a solution for the port. Your solution is fine, but the comment needs to be tweaked. Maybe like this? # Requires libm: uses sqrt(3), inlined by the compiler on some archs -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: REMOVE: games/prboom
Ryan Freeman: > First time trying to remove something, here is a patch to move > games/prboom to the attic. games/prboom-plus does everything it > did and more with fixes. > > anything I've forgotten for removal? Port removals need an entry in devel/quirks. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Fix cad/geda-gaf -fno-common
It looks like this could be updated. http://ftp.geda-project.org/geda-gaf/stable/v1.10/1.10.2/ -- Christian "naddy" Weisgerber na...@mips.inka.de
devel/avr32 -fno-common fixes
The GNU toolchain explicitly avoids common variables. Whoever
hacked up this derived version didn't understand that.
* binutils: Since linkrelax is already defined as a global variable,
it is already initialized to 0, so we can simply drop this
initialization.
* gcc-bootstrap, gcc: Use the mechanism provided by the .opt file
processing to initialize these globals.
With this, devel/avr32/* builds.
OK?
Index: binutils/Makefile
===
RCS file: /cvs/ports/devel/avr32/binutils/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- binutils/Makefile 12 Jul 2019 21:15:34 - 1.4
+++ binutils/Makefile 12 Feb 2021 22:41:54 -
@@ -2,6 +2,7 @@
COMMENT = Atmel AVR 32-bit binutils
V =2.23.1
+REVISION = 0
DISTNAME = avr32-binutils-${V}
# GPLv3
Index: binutils/patches/patch-gas_config_tc-avr32_c
===
RCS file: binutils/patches/patch-gas_config_tc-avr32_c
diff -N binutils/patches/patch-gas_config_tc-avr32_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ binutils/patches/patch-gas_config_tc-avr32_c12 Feb 2021 22:41:54
-
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+fix for -fno-common
+
+Index: gas/config/tc-avr32.c
+--- gas/config/tc-avr32.c.orig
gas/config/tc-avr32.c
+@@ -47,7 +47,6 @@
+
+ /* Flags given on the command line */
+ static int avr32_pic = FALSE;
+-int linkrelax = FALSE;
+ int avr32_iarcompat = FALSE;
+
+ /* This array holds the chars that always start a comment. */
Index: gcc/Makefile
===
RCS file: /cvs/ports/devel/avr32/gcc/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- gcc/Makefile15 Jan 2021 19:03:58 - 1.8
+++ gcc/Makefile12 Feb 2021 22:41:54 -
@@ -3,7 +3,7 @@
COMMENT = Atmel AVR 32-bit gcc
V =4.4.7
DISTNAME = avr32-gcc-${V}
-REVISION = 1
+REVISION = 2
# GPLv3
PERMIT_PACKAGE = Yes
Index: gcc/patches/patch-gcc_config_avr32_avr32_c
===
RCS file: gcc/patches/patch-gcc_config_avr32_avr32_c
diff -N gcc/patches/patch-gcc_config_avr32_avr32_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/patches/patch-gcc_config_avr32_avr32_c 12 Feb 2021 22:41:54 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+fix for -fno-common
+
+Index: gcc/config/avr32/avr32.c
+--- gcc/config/avr32/avr32.c.orig
gcc/config/avr32/avr32.c
+@@ -207,10 +207,6 @@ static const struct arch_type_s avr32_arch_types[] = {
+ {NULL, 0, 0, 0, NULL}
+ };
+
+-/* Default arch name */
+-const char *avr32_arch_name = "none";
+-const char *avr32_part_name = "none";
+-
+ const struct part_type_s *avr32_part;
+ const struct arch_type_s *avr32_arch;
+
Index: gcc/patches/patch-gcc_config_avr32_avr32_opt
===
RCS file: gcc/patches/patch-gcc_config_avr32_avr32_opt
diff -N gcc/patches/patch-gcc_config_avr32_avr32_opt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/patches/patch-gcc_config_avr32_avr32_opt12 Feb 2021 22:41:54
-
@@ -0,0 +1,25 @@
+$OpenBSD$
+
+fix for -fno-common
+
+Index: gcc/config/avr32/avr32.opt
+--- gcc/config/avr32/avr32.opt.orig
gcc/config/avr32/avr32.opt
+@@ -56,7 +56,7 @@ Target Report Mask(HAS_ASM_ADDR_PSEUDOS)
+ Use assembler pseudo-instructions lda.w and call for handling direct
addresses. (Enabled by default)
+
+ mpart=
+-Target Report RejectNegative Joined Var(avr32_part_name)
++Target Report RejectNegative Joined Var(avr32_part_name) Init("none")
+ Specify the AVR32 part name
+
+ mcpu=
+@@ -64,7 +64,7 @@ Target Report RejectNegative Joined Undocumented Var(a
+ Specify the AVR32 part name (deprecated)
+
+ march=
+-Target Report RejectNegative Joined Var(avr32_arch_name)
++Target Report RejectNegative Joined Var(avr32_arch_name) Init("none")
+ Specify the AVR32 architecture name
+
+ mfast-float
Index: gcc-bootstrap/Makefile
===
RCS file: /cvs/ports/devel/avr32/gcc-bootstrap/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- gcc-bootstrap/Makefile 9 Jan 2021 21:41:16 - 1.8
+++ gcc-bootstrap/Makefile 12 Feb 2021 22:41:54 -
@@ -7,7 +7,7 @@ PKGNAME = avr32-gcc-bootstrap-${V}
# GPLv3
PERMIT_PACKAGE = Yes
-REVISION = 1
+REVISION = 2
WANTLIB = c gmp mpfr
DIST_SUBDIR = gcc
Index: gcc-bootstrap/patches/patch-gcc_config_avr32_avr32_c
===
RCS file: gcc-bootstrap/patches/patch-gcc_config_avr32_avr32_c
diff -N gcc-bootstrap/patches/patch-gcc_config_avr32_avr32_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc-bootstrap/patches/patch-gcc_config_avr32_avr32_c12 Feb 2021
22:41:54 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+fix
Re: FIX: games/xboing -fno-common
Ryan Freeman: > From FreeBSD, a bit hard to follow as their commit (re)touched the > original patches > > Once this builds, the game doesn't seem very playable. I already looked at this. If you build it with -fcommon, it already isn't playable. That needs to be fixed first--or the port should be removed. This is a case where the no-common fix is not obvious. If you look at the code, the intent appears to have been to have local waitMode variables in each module. However, they are all merged into a single common. If you follow the likely intent, the different instances of waitMode should be declared static. However, it's entirely possible that the game logic has come to rely on the accidental merging of the variables. So this needs testing... for which the game needs to be playable in the first place. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: FIX: games/xboing -fno-common
Stuart Henderson: > naddy had a similar diff and same problem. Looking at the compiler > warnings it doesn't exactly seem LP64-clean (or, well, clean at all); Speaking in general terms: A lot of the crufty X11 code in the ports tree has a pattern where they use callback APIs that take a pointer argument, and if they just want to pass an int, they cast it to a pointer and back (instead of allocating an int and passing a pointer to it). That works out fine, no truncation, despite scary compiler warnings. IIRC we mostly cleaned up the actual LP64 problems years ago. -- Christian "naddy" Weisgerber na...@mips.inka.de
Build failures from -fno-common (2021-02-13)
Here is an updated list of ports that fail to build with -fno-common: audio/audacity UPDATEports@openbsd.org audio/gtkpodUPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/avr32/binutils- ports@openbsd.org devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org devel/ti-msp430gcc - ports@openbsd.org editors/beaver - ports@openbsd.org editors/hexcurse- ports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/mupen64plus/rsp-cxd4 - anth...@anjbe.name emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/atomix- ports@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freeblocks- ports@openbsd.org games/freedroid - ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/heroes- anth...@anjbe.name games/mirrormagic - ports@openbsd.org games/nethack/3.6 - es...@openbsd.org games/oolite- n...@openbsd.org games/opentyrian- ports@openbsd.org games/pacman-arena - ports@openbsd.org games/sdlpop- rob...@openbsd.org games/sdlroids - ports@openbsd.org games/spider- ports@openbsd.org games/vms-empire- ports@openbsd.org games/xboing- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/enjoympeg - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au japanese/onew - es...@openbsd.org lang/arena - ports@openbsd.org lang/erlang/19 - ports@openbsd.org lang/moarvm UPDATEpas...@stumpf.co lang/pccUPDATEports@openbsd.org lang/snobol4UPDATEst...@wb8wsf.org mail/avengerUPDATEports@openbsd.org mail/mlmmj - ports@openbsd.org mail/sma- ports@openbsd.org mail/wmmultipop3- ports@openbsd.org mail/wmpop3 - ports@openbsd.org math/abs- ports@openbsd.org math/foma - ports@openbsd.org math/mcl- ports@openbsd.org math/pspp UPDATEbcal...@openbsd.org misc/geekcode - ports@openbsd.org misc/hfsplus- ports@openbsd.org misc/logjam - ports@openbsd.org misc/plan - ports@openbsd.org misc/viz- ports@openbsd.org misc/wmmand - ports@openbsd.org multimedia/audiopreview - ports@openbsd.org multimedia/lives
Re: FIX games/atomix -fno-common
Bjorn Ketelaars: > Fix taken from > https://gitlab.gnome.org/GNOME/atomix/-/commit/be7f44f1945a569494d46c60eaf6e7b39b2bb48b.patch There also seem to be much newer versions available. https://download.gnome.org/sources/atomix/3.34/ atomix-3.34.0.tar.xz519.6 KiB 2019-Sep-09 19:16 That will still need the patch, but might be worth an update anyway? To catch up with 13 years of changes? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: REMOVE: games/prboom
Ryan Freeman:
> > anything I've forgotten for removal?
>
> Thanks naddy, kn, edd for the hints on Quirks and the main category unhook.
> This more like it?
devel/quirks needs a version bump when an entry is added.
Also...
> --- devel/quirks/files/Quirks.pm 10 Feb 2021 12:49:31 - 1.1173
> +++ devel/quirks/files/Quirks.pm 11 Feb 2021 22:50:06 -
> @@ -539,6 +539,7 @@ my $stem_extensions = {
> 'py-sphinx-intl' => 'py3-sphinx-intl',
> 'stegcracker' => 'stegseek',
> 'py-ldap3' => 'py3-ldap3',
> + 'prboom' => 'prboom-plus',
> };
>
> my $obsolete_reason = {
> @@ -2077,6 +2078,7 @@ my $obsolete_reason = {
> 'icinga-web' => 38,
> 'icinga-cgi' => 38,
> 'icinga-idoutils' => 38,
> + 'prboom' => 3,
> };
>
> # reasons for obsolete packages
... I think when a port is replaced ($stem_extenions), it doesn't
get another entry in $obsolete_reason.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: FIX x11/compiz/plugins-main -fno-common
Bjorn Ketelaars: > Fix taken from > https://github.com/compiz-reloaded/compiz-plugins-main/commit/1f39291442513c08930bef308d0ce9dccea74589 That enum isn't used anywhere?! Oh well, no point in diverging from upstream. ok naddy@ -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Remove multimedia/audiopreview
Rafael Sadowski: > Next victim of "-fno-common". The project is dead and I don't think we > should save this application. Alternatives are available. Similar history on FreeBSD and OpenBSD: kevlo@ imported it in July 2010, and since then the respective ports have only received mechanical infrastructure commits. FreeBSD expired it in 2019. I think this can be deleted, but I'm cc'ing kevlo@, just in case. -- Christian "naddy" Weisgerber na...@mips.inka.de
Remove graphics/enjoympeg?
graphics/enjoympeg fails to build with -fno-error. A glance at DESCR Enjoympeg is a MPEG-1 video player based on the source of plaympeg from the SMPEG library. It has [... who cares...] makes me think that this port can be removed. FreeBSD did so about a decade ago. MPEG-1 video (Video CD) is laughably obsolete. FFmpeg etc. can still handle it if somebody is really sitting on an archive of VHS-quality videos. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: FIX: games/xboing -fno-common
Klemens Nanni: > OK kn to remove this, although I certainly do not object to fixing it > if someone wants to do the legwork -- it just seems unreasonable to me > (if done by people who only fix it "to fix the tree"). FWIW, the FreeBSD port is equally unplayable. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: FIX games/atomix -fno-common
Bjorn Ketelaars: > Yes, you are right, it is worth an update. For now update to 3.22.0 as > newer versions depend on libgnome-games-support, which - I think - is > not in ports. Upstream provided the -fno-common fix. > > Run tested on amd64. I managed to make water. ok naddy@ -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: UPDATE: x11/oroborus
Ryan Freeman: > Took a stab here, FreeBSD has moved to 2.0.20 and uses Debian's mirror > to fetch the distfile. I followed suit. Charlene already proposed something similar: https://marc.info/?l=openbsd-ports&m=161256652328956&w=2 -- Christian "naddy" Weisgerber na...@mips.inka.de
Build failures from -fno-common (2021-02-14)
There has been a flurry of activity, so here is again the updated list of ports that fail to build with -fno-common: audio/gtkpodUPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org editors/beaver - ports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freeblocks- ports@openbsd.org games/freedroid - ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/mirrormagic - ports@openbsd.org games/nethack/3.6 - es...@openbsd.org games/oolite- n...@openbsd.org games/pacman-arena - ports@openbsd.org games/sdlpop- rob...@openbsd.org games/sdlroids - ports@openbsd.org games/spider- ports@openbsd.org games/vms-empire- ports@openbsd.org games/xboing- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/enjoympeg - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au japanese/onew - es...@openbsd.org lang/arena - ports@openbsd.org lang/erlang/19 - ports@openbsd.org lang/moarvm UPDATEpas...@stumpf.co lang/pccUPDATEports@openbsd.org mail/avengerUPDATEports@openbsd.org mail/sma- ports@openbsd.org mail/wmmultipop3- ports@openbsd.org mail/wmpop3 - ports@openbsd.org math/abs- ports@openbsd.org math/foma - ports@openbsd.org misc/hfsplus- ports@openbsd.org misc/logjam - ports@openbsd.org misc/plan - ports@openbsd.org misc/wmmand - ports@openbsd.org multimedia/audiopreview - ports@openbsd.org multimedia/lives- ports@openbsd.org net/angst - ports@openbsd.org net/argus - ste...@openbsd.org net/argus-clients - ste...@openbsd.org net/dicoUPDATEports@openbsd.org net/ekg - ports@openbsd.org net/ettercap- ports@openbsd.org net/honeyd - ports@openbsd.org net/ipv6-toolkit- bl...@openbsd.org net/jftpgw - ports@openbsd.org net/msdl- ports@openbsd.org net/nagios/nagios UPDATEports@openbsd.org net/netatalk- ports@openbsd.org net/openmdns-
Remove comms/scmxx?
comms/scmxx fails to build with -fno-common. There is actually a slightly newer version 0.9.0 from 2006 available, which will presumably need the same fix. "data exchange utility for Siemens mobile phones" Hmm. Siemens Mobile folded 15 years ago. I guess it's _possible_ that somebody still uses a cellphone from back then in those countries that haven't yet switched off GSM... Still, maybe it's time to bury this piece of history. -- Christian "naddy" Weisgerber na...@mips.inka.de
devel/mingw: fix for -fno-common build or...?
Even more so than the micro-controller toolchains that I already
touched, this port feels massively outdated and should probably be
replaced by some newer version. That, however, is a substantial
undertaking and needs to be done by somebody who can verify that
the result actually works.
So here are the fixes required to build this with -fno-common,
straight from the GNU binutils history. (So easy to find with
tog after cloning a local copy of the Git repo... I digress.)
Do we want this? Should the port be deleted instead?
Index: Makefile
===
RCS file: /cvs/ports/devel/mingw/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- Makefile14 May 2020 15:30:46 - 1.22
+++ Makefile16 Feb 2021 23:09:56 -
@@ -3,14 +3,12 @@
COMMENT = development environment for native Windows applications
V =1.0.1
-REVISION = 9
+REVISION = 10
BASENAME = x86-mingw32-build
DISTNAME = ${BASENAME}-${V}-sh
PKGNAME = mingw-${V}
WRKDIST = ${WRKDIR}/${BASENAME}-${V}
CATEGORIES = devel
-
-HOMEPAGE = http://www.mingw.org/
MAINTAINER = Paul Irofti
Index: patches/patch_binutils-2.20.1-binutils_dwarf_h
===
RCS file: patches/patch_binutils-2.20.1-binutils_dwarf_h
diff -N patches/patch_binutils-2.20.1-binutils_dwarf_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch_binutils-2.20.1-binutils_dwarf_h 16 Feb 2021 23:09:56
-
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+Fix for -fno-common, from GNU upstream.
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34f4fc672e56b1bcd89a108e2b799437ce2241a
+
+--- binutils-2.20.1/binutils/dwarf.h.orig
binutils-2.20.1/binutils/dwarf.h
+@@ -111,6 +111,7 @@ extern int do_debug_frames_interp;
+ extern int do_debug_macinfo;
+ extern int do_debug_str;
+ extern int do_debug_loc;
++extern int do_wide;
+
+ extern void init_dwarf_regnames (unsigned int);
+
Index: patches/patch_binutils-2.20.1-binutils_readelf_c
===
RCS file: patches/patch_binutils-2.20.1-binutils_readelf_c
diff -N patches/patch_binutils-2.20.1-binutils_readelf_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch_binutils-2.20.1-binutils_readelf_c16 Feb 2021 23:09:56
-
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+Fix for -fno-common, from GNU upstream.
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34f4fc672e56b1bcd89a108e2b799437ce2241a
+
+--- binutils-2.20.1/binutils/readelf.c.orig
binutils-2.20.1/binutils/readelf.c
+@@ -149,7 +149,6 @@
+ #include "filenames.h"
+
+ char * program_name = "readelf";
+-int do_wide;
+ static long archive_file_offset;
+ static unsigned long archive_file_size;
+ static unsigned long dynamic_addr;
Index: patches/patch_binutils-2.20.1-gprof_hist_c
===
RCS file: patches/patch_binutils-2.20.1-gprof_hist_c
diff -N patches/patch_binutils-2.20.1-gprof_hist_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch_binutils-2.20.1-gprof_hist_c 16 Feb 2021 23:09:56 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Fix for -fno-common, from GNU upstream.
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34f4fc672e56b1bcd89a108e2b799437ce2241a
+
+--- binutils-2.20.1/gprof/hist.c.orig
binutils-2.20.1/gprof/hist.c
+@@ -48,6 +48,8 @@
+ static histogram *find_histogram (bfd_vma lowpc, bfd_vma highpc);
+ static histogram *find_histogram_for_pc (bfd_vma pc);
+
++histogram * histograms;
++unsigned num_histograms;
+ double hist_scale;
+ static char hist_dimension[16] = "seconds";
+ static char hist_dimension_abbrev = 's';
Index: patches/patch_binutils-2.20.1-gprof_hist_h
===
RCS file: patches/patch_binutils-2.20.1-gprof_hist_h
diff -N patches/patch_binutils-2.20.1-gprof_hist_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch_binutils-2.20.1-gprof_hist_h 16 Feb 2021 23:09:56 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Fix for -fno-common, from GNU upstream.
+https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34f4fc672e56b1bcd89a108e2b799437ce2241a
+
+--- binutils-2.20.1/gprof/hist.h.orig
binutils-2.20.1/gprof/hist.h
+@@ -30,8 +30,8 @@
+ int *sample; /* Histogram samples (shorts in the file!). */
+ } histogram;
+
+-histogram *histograms;
+-unsigned num_histograms;
++extern histogram *histograms;
++extern unsigned num_histograms;
+
+ /* Scale factor converting samples to pc values:
+each sample covers HIST_SCALE bytes. */
--
Christian "naddy" Weisgerber na...@mips.inka.de
games/freeblocks: -fno-common fixes or -fcommon?
games/freeblocks fails to build with -fno-common. Upstream has not
yet addressed this problem.
The patches below fix dozens of multiple variable definitions.
Some need an extern, some need to be defined in a source module in
the first place. One had a wrong enum type.
Alternatively, this may be a case where -fcommon is warranted.
Opinions?
Index: Makefile
===
RCS file: /cvs/ports/games/freeblocks/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile14 Feb 2020 11:11:33 - 1.6
+++ Makefile17 Feb 2021 20:33:08 -
@@ -6,7 +6,7 @@ CATEGORIES =games x11
GH_ACCOUNT = dorkster
GH_PROJECT = freeblocks
GH_TAGNAME = v0.5
-REVISION = 2
+REVISION = 3
HOMEPAGE = https://github.com/dorkster/freeblocks
Index: patches/patch-src_block_c
===
RCS file: patches/patch-src_block_c
diff -N patches/patch-src_block_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_block_c 17 Feb 2021 20:33:08 -
@@ -0,0 +1,35 @@
+$OpenBSD$
+
+Index: src/block.c
+--- src/block.c.orig
src/block.c
+@@ -23,8 +23,28 @@ const int POINTS_PER_BLOCK = 10;
+ const int POINTS_PER_BUMP = 5;
+ const int POINTS_PER_COMBO_BLOCK = 15;
+
+-int speed_init = 1;
++int ROWS;
++int COLS;
++int NUM_BLOCKS;
++int START_ROWS;
++int DISABLED_ROWS;
++int CURSOR_MAX_X;
++int CURSOR_MIN_Y;
++int CURSOR_MAX_Y;
++int BLOCK_MOVE_SPEED;
++int DRAW_OFFSET_X;
++int DRAW_OFFSET_Y;
++
+ Block **blocks = NULL;
++int speed_init = 1;
++
++bool animating;
++int bump_timer;
++int bump_pixels;
++int speed;
++int speed_timer;
++int game_over_timer;
++bool jewels_cursor_select;
+
+ int blockRand(void) {
+ return rand() % NUM_BLOCKS;
Index: patches/patch-src_block_h
===
RCS file: patches/patch-src_block_h
diff -N patches/patch-src_block_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_block_h 17 Feb 2021 20:33:08 -
@@ -0,0 +1,66 @@
+$OpenBSD$
+
+Index: src/block.h
+--- src/block.h.orig
src/block.h
+@@ -33,21 +33,21 @@
+ #define SPEED_TIME 1800 / (60/FPS)
+ #define MAX_SPEED 25
+
+-const int POINTS_PER_BLOCK;
+-const int POINTS_PER_BUMP;
+-const int POINTS_PER_COMBO_BLOCK;
++extern const int POINTS_PER_BLOCK;
++extern const int POINTS_PER_BUMP;
++extern const int POINTS_PER_COMBO_BLOCK;
+
+-int ROWS;
+-int COLS;
+-int NUM_BLOCKS;
+-int START_ROWS;
+-int DISABLED_ROWS;
+-int CURSOR_MAX_X;
+-int CURSOR_MIN_Y;
+-int CURSOR_MAX_Y;
+-int BLOCK_MOVE_SPEED;
+-int DRAW_OFFSET_X;
+-int DRAW_OFFSET_Y;
++extern int ROWS;
++extern int COLS;
++extern int NUM_BLOCKS;
++extern int START_ROWS;
++extern int DISABLED_ROWS;
++extern int CURSOR_MAX_X;
++extern int CURSOR_MIN_Y;
++extern int CURSOR_MAX_Y;
++extern int BLOCK_MOVE_SPEED;
++extern int DRAW_OFFSET_X;
++extern int DRAW_OFFSET_Y;
+
+ typedef struct Block{
+ int x,y;
+@@ -62,15 +62,15 @@ typedef struct Block{
+ bool sound_after_move;
+ }Block;
+
+-Block **blocks;
+-bool animating;
+-int bump_timer;
+-int bump_pixels;
+-int speed;
+-int speed_init;
+-int speed_timer;
+-int game_over_timer;
+-bool jewels_cursor_select;
++extern Block **blocks;
++extern bool animating;
++extern int bump_timer;
++extern int bump_pixels;
++extern int speed;
++extern int speed_init;
++extern int speed_timer;
++extern int game_over_timer;
++extern bool jewels_cursor_select;
+
+ void blockSet(int i, int j, bool alive, int color);
+ void blockClear(int i, int j);
Index: patches/patch-src_game_c
===
RCS file: patches/patch-src_game_c
diff -N patches/patch-src_game_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_game_c17 Feb 2021 20:33:08 -
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: src/game.c
+--- src/game.c.orig
src/game.c
+@@ -23,6 +23,10 @@
+ #include "menu.h"
+ #include "sys.h"
+
++bool cursor_moving;
++int cursor_timer;
++int rebind_index;
++
+ void gameTitle() {
+ title_screen = true;
+ high_scores_screen = false;
Index: patches/patch-src_game_h
===
RCS file: patches/patch-src_game_h
diff -N patches/patch-src_game_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_game_h17 Feb 2021 20:33:08 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Index: src/game.h
+--- src/game.h.orig
src/game.h
+@@ -21,9 +21,9 @@
+
+ #include "sys.h"
+
+-bool cursor_moving;
+-int cursor_timer;
+-int rebind_index;
++extern bool cursor_moving;
++extern int cursor_timer;
++extern int rebind_index;
+
+ void gameTitle();
+ void gameHighScores();
Index: patches/patch-src_menu_h
===
RCS file: patches/patch-src_menu_h
diff -N patches/patch-src_menu_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_menu_h17 Feb 2021
Re: Unplug unused lang/erlang/19 (avoids -fno-common)
Greg Steuck: > I tested that benchmarks/tsung still works as a proxy for > all-things-erlang21. This is to be followed by erlang/19 directory > removal. devel/rebar and devel/rebar3 still have erlang19 flavors. -- Christian "naddy" Weisgerber na...@mips.inka.de
Build failures from -fno-common (2021-02-16)
Here is the updated list of ports that now fail to build due to the new -fno-common compiler default. I have again cc'ed everybody who is listed as maintainer of at least one affected port. "UPDATE" means that portroach says that an update is available. audio/gtkpodUPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/lcdproc UPDATEports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xastir- ports@openbsd.org comms/xdx - ports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org editors/beaver - ports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/coldfire - ports@openbsd.org emulators/fuse UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/pcsxr - ports@openbsd.org emulators/simh - ports@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freeblocks- ports@openbsd.org games/freedroid - ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/mirrormagic - ports@openbsd.org games/oolite- n...@openbsd.org games/pacman-arena - ports@openbsd.org games/sdlpop- rob...@openbsd.org games/spider- ports@openbsd.org games/vms-empire- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au lang/arena - ports@openbsd.org lang/erlang/19 - ports@openbsd.org lang/moarvm UPDATEpas...@stumpf.co lang/pccUPDATEports@openbsd.org mail/avengerUPDATEports@openbsd.org mail/sma- ports@openbsd.org mail/wmmultipop3- ports@openbsd.org mail/wmpop3 - ports@openbsd.org math/abs- ports@openbsd.org math/foma - ports@openbsd.org misc/hfsplus- ports@openbsd.org misc/logjam - ports@openbsd.org misc/wmmand - ports@openbsd.org multimedia/audiopreview - ports@openbsd.org multimedia/lives- ports@openbsd.org net/angst - ports@openbsd.org net/argus - ste...@openbsd.org net/argus-clients - ste...@openbsd.org net/dicoUPDATEports@openbsd.org net/ekg - ports@openbsd.org net/ettercap- ports@openbsd.org net/honeyd - ports@openbsd.org net/ipv6-toolkit- bl...@openbsd.org net/jftpgw - ports@openbsd.org net/msdl- ports@openbsd.org net/nagios/nagios UPDATEports@openbsd.org net/openmdns- gonz...@openbsd.org net/plushs - ports@openbsd.org net/tcpreplay UPDATEni...@openbsd.org net/weex- ports@openbsd.org net/yersinia- ste...@openbsd.org productivity/siag -
Remove games/spider?
Is anybody still interested in games/spider? It's a 30-year old solitaire game. Our master site is gone, but I've found another one. The port fails to build with -fno-common. When built with -fcommon, it runs, so it could be repaired. But getting there means wading through reams and reams of warnings: * functions are used before they are declared (=> warning), * functions are declared without type (=> warning), * so the functions default to int but return no value (=> warning). This has been partially addressed in the existing patches, and I've started fixing more of it, but it goes on and on. I feel I'm wasting time providing life support to a museum piece. Can we just remove it? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Build failures from -fno-common (2021-02-16)
Stuart Henderson: > I think we are getting to the stage where we should just mark them BROKEN > with an identifiable tag, so that we don't have to wade through them when > identifying other ports breakage in builds. > > Then if no updates happen maybe remove them in a few months (say, a bit > after 6.9 is done). If that approach had been suggested earlier, I wouldn't have spent time fixing random ports I have no interest in. How about we all give it a big push and fix the remaining ones? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Build failures from -fno-common (2021-02-16)
Stuart Henderson: > > > comms/birda - ports@openbsd.org > > > comms/jpilot- ports@openbsd.org > > > comms/scmxx UPDATEports@openbsd.org > for old mobile phones/portable devices I already suggested scmxx for removal. Siemens Mobile ceased to exist 15 years ago. The Palm Pilots and IrDA are similarly outdated. I think these can be removed. > > > editors/tea UPDATEports@openbsd.org > hardcodes -lstdc++ We have a separate port editors/teaqt for the latest version. I think this can be removed. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: education/gamgi: set "-fcommon", update to 0.17.3g
Klemens Nanni: > I went the easy way just like Debian did; the update itself did not > change "-fno-common" behaviour, i.e. it's the same twenty files that > clash on the `gamgi' symbol. That's a hint that it's defined in a header file that is included everywhere. You just need to mark it extern and copy the definition into a *.c file. > +# avoid patching twenty occurence of "ld: error: duplicate symbol: gamgi" > +COPTS += -fcommon It's never been quite clear to me how COPTS is to be used, but we do not use it in the ports tree. -- Christian "naddy" Weisgerber na...@mips.inka.de
Update: net/weex 2.8.3 (-fno-common)
weex is still maintained, sort of, by the Debian packager.
Update to latest release 2.8.3, which also fixes the build with
-fno-common.
With some guidance from the FreeBSD port how to wrangle the incoherent
autotool files into buildable shape.
Note: I don't use this, I haven't tested it.
OK?
Patch attached rather than inline because there are ISO 8859-1
characters in there.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Index: Makefile
===
RCS file: /cvs/ports/net/weex/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile 12 Jul 2019 20:48:52 - 1.18
+++ Makefile 19 Feb 2021 23:01:22 -
@@ -1,31 +1,36 @@
# $OpenBSD: Makefile,v 1.18 2019/07/12 20:48:52 sthen Exp $
-COMMENT= noninteractive ftp client
-DISTNAME= weex-2.6.1.5
-REVISION= 4
+COMMENT= noninteractive FTP/FTPS client for updating web pages
+
+VERSION= 2.8.3
+DISTNAME= weex-${VERSION}
CATEGORIES= net
HOMEPAGE= http://weex.sourceforge.net
-# GPL
+# GPLv2+
PERMIT_PACKAGE= Yes
-WANTLIB= c iconv intl
+WANTLIB= c crypto iconv intl ssl
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=weex/}
+DISTFILES= weex_${VERSION}.tar.gz
BUILD_DEPENDS= devel/gettext,-tools
LIB_DEPENDS= devel/gettext,-runtime
-SEPARATE_BUILD= Yes
-CONFIGURE_STYLE= autoconf
-AUTOCONF_VERSION= 2.13
+AUTOCONF_VERSION= 2.69
+AUTOMAKE_VERSION= 1.11
+CONFIGURE_STYLE= autoreconf
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"
+post-patch:
+ cp ${LOCALBASE}/share/gettext/po/Makevars.template \
+ ${WRKSRC}/po/Makevars
+
post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/weex
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/weex
${INSTALL_DATA} ${WRKSRC}/doc/sample.weexrc \
${PREFIX}/share/examples/weex
Index: distinfo
===
RCS file: /cvs/ports/net/weex/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo 18 Jan 2015 03:14:54 - 1.4
+++ distinfo 19 Feb 2021 23:01:22 -
@@ -1,2 +1,2 @@
-SHA256 (weex-2.6.1.5.tar.gz) = 1PMHKT/xgjBkEJhyMnO6YkPl++ta+F+JqJOLgm6RrDg=
-SIZE (weex-2.6.1.5.tar.gz) = 206972
+SHA256 (weex_2.8.3.tar.gz) = cqWGq0ca2cgvdSmuF2hOJXU58hmnXBmKEqqDKHDhFgM=
+SIZE (weex_2.8.3.tar.gz) = 319900
Index: patches/patch-Makefile_am
===
RCS file: patches/patch-Makefile_am
diff -N patches/patch-Makefile_am
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Makefile_am 19 Feb 2021 23:01:22 -
@@ -0,0 +1,11 @@
+$OpenBSD$
+
+Index: Makefile.am
+--- Makefile.am.orig
Makefile.am
+@@ -1,4 +1,4 @@
+ AUTOMAKE_OPTIONS=foreign
+
+-SUBDIRS=po intl src doc man debian
++SUBDIRS=po src doc man debian
+ EXTRA_DIST=weex-2.6.1.spec
Index: patches/patch-aclocal_m4
===
RCS file: patches/patch-aclocal_m4
diff -N patches/patch-aclocal_m4
--- patches/patch-aclocal_m4 9 Oct 2004 18:55:20 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,16 +0,0 @@
-$OpenBSD: patch-aclocal_m4,v 1.1.1.1 2004/10/09 18:55:20 naddy Exp $
aclocal.m4.orig Tue Jun 13 13:56:57 2000
-+++ aclocal.m4 Sat Oct 9 19:34:35 2004
-@@ -173,10 +173,9 @@ AC_DEFUN(AM_WITH_NLS,
-
- if test "$gt_cv_func_gettext_libc" != "yes"; then
- AC_CHECK_LIB(intl, bindtextdomain,
-- [AC_CACHE_CHECK([for gettext in libintl],
-- gt_cv_func_gettext_libintl,
-+ [AC_CACHE_VAL(gt_cv_func_gettext_libintl,
- [AC_CHECK_LIB(intl, gettext,
-- gt_cv_func_gettext_libintl=yes,
-+ [gt_cv_func_gettext_libintl=yes; LIBS="$LIBS -lintl"],
- gt_cv_func_gettext_libintl=no)],
- gt_cv_func_gettext_libintl=no)])
- fi
Index: patches/patch-configure_in
===
RCS file: /cvs/ports/net/weex/patches/patch-configure_in,v
retrieving revision 1.1
diff -u -p -r1.1 patch-configure_in
--- patches/patch-configure_in 19 Nov 2005 01:52:26 - 1.1
+++ patches/patch-configure_in 19 Feb 2021 23:01:22 -
@@ -1,11 +1,15 @@
-$OpenBSD: patch-configure_in,v 1.1 2005/11/19 01:52:26 alek Exp $
configure.in.orig Sat Nov 19 02:40:10 2005
-+++ configure.in Sat Nov 19 02:40:30 2005
-@@ -18,6 +18,7 @@ AC_PROG_INSTALL
-
+$OpenBSD$
+
+Index: configure.in
+--- configure.in.orig
configure.in
+@@ -24,7 +24,8 @@ AC_PROG_CC
+ AC_PROG_INSTALL
dnl for gettext
-+LIBS="-liconv ${LIBS}"
- AM_GNU_GETTEXT
+-AM_GNU_GETTEXT
++AM_GNU_GETTEXT_VERSION([0.21])
++AM_GNU_GETTEXT([external])
AC_CHECK_FUNC(gettext,,AC_CHECK_LIB(intl, gettext))
localedir='${prefix}/share/locale'
+ AC_SUBST(localedir)
Index: patches/patch-po_Makefile_in_in
===
RCS file: patches/patch-po_Makefile_in_in
diff -N patches/patch-po_Makefile_in_in
--- patches/patch-po_Makefile_in_in 9 Oct 2004 18:55:20 - 1.1.1.1
+++ /de
Re: education/gamgi: set "-fcommon", update to 0.17.3g
Klemens Nanni: > > That's a hint that it's defined in a header file that is included > > everywhere. You just need to mark it extern and copy the definition > > into a *.c file. > Right, but if I mark that symbol `extern' others now show up as well: I see. There are a lot of tables that are defined in a handful of *.c files and the declaration in the corresponding *.h files is missing an "extern". That's straightforward to fix... > I don't want to patch all of those. ... but it affects 700 variables or so. I guess -fcommon is the pragmatic solution. -- Christian "naddy" Weisgerber na...@mips.inka.de
Build failures from -fno-common (2021-02-20)
Here is the updated list of ports that now fail to build due to the new -fno-common compiler default. audio/gtkpodUPDATEports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org cad/graywolf- jus...@atlantide.mooo.com comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/jpilot- ports@openbsd.org comms/scmxx UPDATEports@openbsd.org comms/seyon - ports@openbsd.org comms/xdx - ports@openbsd.org databases/pgpoolUPDATEp...@openbsd.org devel/mingw - p...@irofti.net devel/remakeUPDATEports@openbsd.org editors/tea UPDATEports@openbsd.org education/gamgi UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/pcsxr - ports@openbsd.org games/corewars - ports@openbsd.org games/egobooUPDATEports@openbsd.org games/freedroidrpg - ports@openbsd.org games/gnurobbo - ports@openbsd.org games/mirrormagic - ports@openbsd.org games/oolite- n...@openbsd.org games/sdlpop- rob...@openbsd.org games/vms-empire- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au lang/arena - ports@openbsd.org lang/moarvm UPDATEpas...@stumpf.co mail/avengerUPDATEports@openbsd.org mail/sma- ports@openbsd.org mail/wmmultipop3- ports@openbsd.org mail/wmpop3 - ports@openbsd.org math/abs- ports@openbsd.org misc/logjam - ports@openbsd.org misc/wmmand - ports@openbsd.org multimedia/audiopreview - ports@openbsd.org multimedia/lives- ports@openbsd.org net/angst - ports@openbsd.org net/argus - ste...@openbsd.org net/argus-clients - ste...@openbsd.org net/dicoUPDATEports@openbsd.org net/ekg - ports@openbsd.org net/ettercap- ports@openbsd.org net/honeyd - ports@openbsd.org net/ipv6-toolkit- bl...@openbsd.org net/jftpgw - ports@openbsd.org net/msdl- ports@openbsd.org net/nagios/nagios UPDATEports@openbsd.org net/openmdns- gonz...@openbsd.org net/plushs - ports@openbsd.org net/tcpreplay UPDATEni...@openbsd.org net/weex- ports@openbsd.org net/yersinia- ste...@openbsd.org productivity/xinvest- ports@openbsd.org productivity/xquote - ports@openbsd.org security/bsd-airtools - ports@openbsd.org security/flasm - rpoin...@openbsd.org security/foremost - ports@openbsd.org security/gringotts - p...@openbsd.org security/ipguard- ports@openbsd.org security/ossec-hids UPDATEp...@irofti.net security/tempwatch - ports@openbsd.org sysutils/radmind- ports@openbsd.org sysutils/wmmon - ports@openbsd.org sysutils/wmwlmon- mar...@nazgul.ch www/sarg- ports@openbsd.org x11/agar/test UPDATEports@openbsd.org x11/fbpanel - ports@openbsd.org x11/gnustep/corebase- sebas...@openbsd.org x11/gnustep/gworkspace - sebas..
games/renpy build failure
The latest flurry of python changes appears to have triggered this
build failure of games/renpy in my latest bulk build:
>>> Building on localhost under games/renpy
BDEPENDS =
[lang/cython;archivers/bzip2;graphics/glew;graphics/ffmpeg;lang/python/2.7;devel/pygame;games/pygame_sdl2]
DIST = [games/renpy:renpy-7.3.5-source.tar.bz2]
FULLPKGNAME = renpy-7.3.5
RDEPENDS =
[graphics/glew;graphics/ffmpeg;lang/python/2.7;games/pygame_sdl2;x11/gnome/zenity]
(Junk lock obtained for localhost at 1613929733.93)
>>> Running depends in games/renpy at 1613929734.01
last junk was in net/filezilla
/usr/sbin/pkg_add -aI -Drepair ffmpeg-4.3.1p0v1 glew-2.2.0 py-cython-0.29.21p1
py-game-2.0.1p0 pygame_sdl2-7.3.5.606 python-2.7.18p0
was: /usr/sbin/pkg_add -aI -Drepair bzip2-1.0.8p0 ffmpeg-4.3.1p0v1 glew-2.2.0
py-cython-0.29.21p1 py-game-2.0.1p0 pygame_sdl2-7.3.5.606 python-2.7.18p0
/usr/sbin/pkg_add -aI -Drepair ffmpeg-4.3.1p0v1 glew-2.2.0 py-cython-0.29.21p1
py-game-2.0.1p0 pygame_sdl2-7.3.5.606 python-2.7.18p0
>>> Running show-prepare-results in games/renpy at 1613929741.27
===> games/renpy
===> renpy-7.3.5 depends on: py-game-* -> py-game-2.0.1p0
===> renpy-7.3.5 depends on: pygame_sdl2-* -> pygame_sdl2-7.3.5.606
===> renpy-7.3.5 depends on: py-cython-* -> py-cython-0.29.21p1
===> renpy-7.3.5 depends on: python->=2.7,<2.8 -> python-2.7.18p0
===> renpy-7.3.5 depends on: bzip2-* -> bzip2-1.0.8p0
===> renpy-7.3.5 depends on: ffmpeg-* -> ffmpeg-4.3.1p0v1
===> renpy-7.3.5 depends on: glew-* -> glew-2.2.0
===> Verifying specs: GLEW SDL2 avcodec avformat avresample avutil freetype m
png pthread swresample swscale z python2.7
===> found GLEW.9.0 SDL2.0.9 avcodec.24.0 avformat.21.0 avresample.2.0
avutil.14.0 freetype.30.0 m.10.1 png.18.0 pthread.26.1 swresample.3.0
swscale.7.0 z.5.0 python2.7.0.0
bzip2-1.0.8p0
ffmpeg-4.3.1p0v1
glew-2.2.0
py-cython-0.29.21p1
py-game-2.0.1p0
pygame_sdl2-7.3.5.606
python-2.7.18p0
(Junk lock released for localhost at 1613929742.26)
distfiles size=68211972
>>> Running patch in games/renpy at 1613929742.32
===> games/renpy
===> Checking files for renpy-7.3.5
`/usr/ports/distfiles/renpy-7.3.5-source.tar.bz2' is up to date.
>> (SHA256) renpy-7.3.5-source.tar.bz2: OK
===> Extracting for renpy-7.3.5
===> Patching for renpy-7.3.5
===> Compiler link: clang -> /usr/bin/clang
===> Compiler link: clang++ -> /usr/bin/clang++
===> Compiler link: cc -> /usr/bin/cc
===> Compiler link: c++ -> /usr/bin/c++
>>> Running configure in games/renpy at 1613929752.27
===> games/renpy
===> Generating configure for renpy-7.3.5
===> Configuring for renpy-7.3.5
>>> Running build in games/renpy at 1613929752.51
===> games/renpy
===> Building for renpy-7.3.5
_renpysteam is out of date.
Traceback (most recent call last):
File "./setup.py", line 148, in
cython("_renpysteam", language="c++", compile_if=steam_sdk,
libs=["steam_api"])
File "/usr/obj/ports/renpy-7.3.5/renpy-7.3.5-source/module/setuplib.py", line
326, in cython
c_fn])
File "/usr/local/lib/python2.7/subprocess.py", line 185, in check_call
retcode = call(*popenargs, **kwargs)
File "/usr/local/lib/python2.7/subprocess.py", line 172, in call
return Popen(*popenargs, **kwargs).wait()
File "/usr/local/lib/python2.7/subprocess.py", line 394, in __init__
errread, errwrite)
File "/usr/local/lib/python2.7/subprocess.py", line 1047, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
*** Error 1 in games/renpy (/usr/ports/lang/python/python.port.mk:248
'do-build': @: ;mkdir -p /usr/obj/ports/renpy-7.3.5/lib/python2.7/site...)
*** Error 2 in games/renpy (/usr/ports/infrastructure/mk/bsd.port.mk:2931
'/usr/obj/ports/renpy-7.3.5/.build_done': @cd /usr/ports/games/ren...)
*** Error 2 in games/renpy (/usr/ports/infrastructure/mk/bsd.port.mk:2594
'build': @lock=renpy-7.3.5; export _LOCKS_HELD=" renpy-7.3.5"; ...)
===> Exiting games/renpy with an error
*** Error 1 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:137 'build': @:
${echo_msg:=echo}; : ${target:=build}; for i in ; do eval...)
>>> Ended at 1613929752.83
Error: job failed with 512 on localhost at 1613929752
--
Christian "naddy" Weisgerber na...@mips.inka.de
Build failures from -fno-common (2021-02-21)
Here is the updated list of ports that now fail to build due to the new -fno-common compiler default. (It looks like portroach now fails to show available updates for master site Sourceforge.) audio/gtkpod- ports@openbsd.org audio/nspmod- ports@openbsd.org audio/wmtune- ports@openbsd.org comms/birda - ports@openbsd.org comms/efax - i...@openbsd.org comms/scmxx - ports@openbsd.org comms/seyon - ports@openbsd.org comms/xdx - ports@openbsd.org devel/mingw - p...@irofti.net devel/mk- ports@openbsd.org devel/remake- ports@openbsd.org editors/tea UPDATEports@openbsd.org emulators/libretro-genesis-plus-gx - ports@openbsd.org emulators/pcsxr - ports@openbsd.org games/corewars - ports@openbsd.org games/egoboo- ports@openbsd.org games/freedroidrpg - ports@openbsd.org games/mirrormagic - ports@openbsd.org games/oolite- n...@openbsd.org games/sdlpop- rob...@openbsd.org games/vms-empire- ports@openbsd.org graphics/dpic - ports@openbsd.org graphics/gimp/liquid-rescale- ports@openbsd.org inputmethods/cellwriter - vas...@lxmx.com.au lang/moarvm UPDATEpas...@stumpf.co mail/avengerUPDATEports@openbsd.org mail/sma- ports@openbsd.org mail/wmmultipop3- ports@openbsd.org mail/wmpop3 - ports@openbsd.org misc/logjam - ports@openbsd.org misc/wmmand - ports@openbsd.org multimedia/audiopreview - ports@openbsd.org multimedia/lives- ports@openbsd.org net/angst - ports@openbsd.org net/argus - ste...@openbsd.org net/argus-clients - ste...@openbsd.org net/dicoUPDATEports@openbsd.org net/ekg - ports@openbsd.org net/ettercap- ports@openbsd.org net/ipv6-toolkit- bl...@openbsd.org net/jftpgw - ports@openbsd.org net/nagios/nagios - ports@openbsd.org net/tcpreplay - ni...@openbsd.org net/weex- ports@openbsd.org net/yersinia- ste...@openbsd.org security/bsd-airtools - ports@openbsd.org security/foremost - ports@openbsd.org security/gringotts - p...@openbsd.org security/ossec-hids UPDATEp...@irofti.net security/tempwatch - ports@openbsd.org sysutils/radmind- ports@openbsd.org sysutils/wmmon - ports@openbsd.org sysutils/wmwlmon- mar...@nazgul.ch www/sarg- ports@openbsd.org x11/agar/test UPDATEports@openbsd.org x11/gnustep/corebase- sebas...@openbsd.org x11/gnustep/gworkspace - sebas...@openbsd.org x11/gnustep/terminal- sebas...@openbsd.org x11/golem - ports@openbsd.org x11/uwm - ports@openbsd.org x11/wind- ports@openbsd.org x11/wmii- ports@openbsd.org x11/wminfo - ports@openbsd.org -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Fix x11/uwm to compile with -fno-common
Greg Steuck:
> I confirmed that uwm still launches and managed to exercise the Exit
> item in the menu.
Launching an xterm also works.
> Happy to either apply the patch or remove the port as it looks pretty
> dead upstream.
Hey, I was looking at it at the same time. It's functional, I see
no reason to remove the port.
Here's an update to 0.2.11a, which only updates/fixes the autotools
infrastructure and removes the obsolete HTML documentation.
And the obligatory -fno-common fix.
ok?
Index: Makefile
===
RCS file: /cvs/ports/x11/uwm/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile12 Jul 2019 20:51:23 - 1.5
+++ Makefile22 Feb 2021 20:22:27 -
@@ -1,9 +1,8 @@
# $OpenBSD: Makefile,v 1.5 2019/07/12 20:51:23 sthen Exp $
COMMENT = lightweight WM with an original look and feel
-DISTNAME = uwm-0.2.11
+DISTNAME = uwm-0.2.11a
CATEGORIES = x11
-REVISION = 2
HOMEPAGE = http://udeproject.sourceforge.net/
@@ -23,7 +22,6 @@ CONFIGURE_STYLE = gnu
CONFIGURE_ENV =CPPFLAGS=-I${LOCALBASE}/include \
LDFLAGS=-L${LOCALBASE}/lib
-FAKE_FLAGS = udedocdir=${PREFIX}/share/doc/uwm \
- udehtmldocdir=${PREFIX}/share/doc/uwm/html
+FAKE_FLAGS = udedocdir=${PREFIX}/share/doc/uwm
.include
Index: distinfo
===
RCS file: /cvs/ports/x11/uwm/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo20 May 2013 06:38:39 - 1.1.1.1
+++ distinfo22 Feb 2021 20:22:27 -
@@ -1,2 +1,2 @@
-SHA256 (uwm-0.2.11.tar.gz) = PV2Jw6OLg56k0tUNf3YHzr2TlZ5loWI7cF7rXoMder8=
-SIZE (uwm-0.2.11.tar.gz) = 473171
+SHA256 (uwm-0.2.11a.tar.gz) = 3QVoV8mLdckgOGGRfbM7yvh7oHS90gTPcyzky3d8tAg=
+SIZE (uwm-0.2.11a.tar.gz) = 633259
Index: patches/patch-uwm_Makefile_in
===
RCS file: patches/patch-uwm_Makefile_in
diff -N patches/patch-uwm_Makefile_in
--- patches/patch-uwm_Makefile_in 20 May 2013 06:38:39 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-uwm_Makefile_in,v 1.1.1.1 2013/05/20 06:38:39 bcallah Exp $
uwm/Makefile.in.orig Sat May 18 21:17:33 2013
-+++ uwm/Makefile.inSat May 18 21:17:50 2013
-@@ -169,7 +169,7 @@ LIBMULTITHREAD = @LIBMULTITHREAD@
- LIBOBJS = @LIBOBJS@
- LIBPTH = @LIBPTH@
- LIBPTH_PREFIX = @LIBPTH_PREFIX@
--LIBS = @LIBS@
-+LIBS = @LIBS@ @LIBINTL@
- LIBTHREAD = @LIBTHREAD@
- LN_S = @LN_S@
- LTLIBC = @LTLIBC@
Index: patches/patch-uwm_workspaces_h
===
RCS file: patches/patch-uwm_workspaces_h
diff -N patches/patch-uwm_workspaces_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-uwm_workspaces_h 22 Feb 2021 20:22:27 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+Comment out unused variables to fix build with -fno-common.
+
+Index: uwm/workspaces.h
+--- uwm/workspaces.h.orig
uwm/workspaces.h
+@@ -94,9 +94,9 @@ typedef struct {
+
+ // These three lists will be declared in workspaces.c, and declared static
+ // so that no other module has direct access to them
+-NodeList Workspaces;
+-NodeList Layers;
+-NodeList WS_Layer_Defaults; // This will be the list which handles setting up
++//NodeList Workspaces;
++//NodeList Layers;
++//NodeList WS_Layer_Defaults; // This will be the list which handles setting
up
+ // defaults for where
windows will be mapped to.
+ // End three listings
+
Index: pkg/PLIST
===
RCS file: /cvs/ports/x11/uwm/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 20 May 2013 06:38:39 - 1.1.1.1
+++ pkg/PLIST 22 Feb 2021 20:22:27 -
@@ -2,33 +2,6 @@
@bin bin/uwm
share/doc/uwm/
share/doc/uwm/README
-share/doc/uwm/html/
-share/doc/uwm/html/contents.gif
-share/doc/uwm/html/crossref.gif
-share/doc/uwm/html/index.html
-share/doc/uwm/html/manual.css
-share/doc/uwm/html/manual.html
-share/doc/uwm/html/next.gif
-share/doc/uwm/html/next_g.gif
-share/doc/uwm/html/node1.html
-share/doc/uwm/html/node10.html
-share/doc/uwm/html/node11.html
-share/doc/uwm/html/node12.html
-share/doc/uwm/html/node13.html
-share/doc/uwm/html/node14.html
-share/doc/uwm/html/node15.html
-share/doc/uwm/html/node2.html
-share/doc/uwm/html/node3.html
-share/doc/uwm/html/node4.html
-share/doc/uwm/html/node5.html
-share/doc/uwm/html/node6.html
-share/doc/uwm/html/node7.html
-share/doc/uwm/html/node8.html
-share/doc/uwm/html/node9.html
-share/doc/uwm/html/prev.gif
-share/doc/uwm/html/prev_g.gif
-share/doc/uwm/html/up.gif
-share/doc/uwm/html/up_g.gif
share/doc/uwm/l2h.conf
share/doc/uwm/manual.pdf
share/doc/uwm/manual.tex
--
Christian "naddy" Weisgerber
net/argus: fix for -fno-common
net/argus: fix the build with -fno-common
This is just unused code that is copy-pasted from ArgusUdp.c where
is also unused.
OK?
Index: Makefile
===
RCS file: /cvs/ports/net/argus/Makefile,v
retrieving revision 1.25
diff -u -p -r1.25 Makefile
--- Makefile20 Mar 2020 16:44:25 - 1.25
+++ Makefile23 Feb 2021 21:37:21 -
@@ -3,7 +3,7 @@
COMMENT = Audit Record Generation and Utilization System
DISTNAME = argus-3.0.8.2
-REVISION = 1
+REVISION = 2
CATEGORIES = net
HOMEPAGE = http://qosient.com/argus/
Index: patches/patch-argus_ArgusUdt_c
===
RCS file: patches/patch-argus_ArgusUdt_c
diff -N patches/patch-argus_ArgusUdt_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-argus_ArgusUdt_c 23 Feb 2021 21:37:21 -
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+Fix for -fno-common: remove unused variable duplicated in ArgusUdp.c
+
+Index: argus/ArgusUdt.c
+--- argus/ArgusUdt.c.orig
argus/ArgusUdt.c
+@@ -40,9 +40,6 @@
+ #include
+ #include
+
+-#include
+-struct bootp *bp;
+-
+ struct ArgusSystemFlow *
+ ArgusCreateUDTFlow (struct ArgusModelerStruct *model, struct udt_header *udt)
+ {
--
Christian "naddy" Weisgerber na...@mips.inka.de
net/argus-clients: fix for -fno-common
net/argus-clients: fix for -fno-common This removes an unused variable from the static library argus_common.a. It clashes with one in the raconvert tool. You could argue the latter one should be renamed instead, but then again, the library variable isn't referenced anywhere. OK? Index: Makefile === RCS file: /cvs/ports/net/argus-clients/Makefile,v retrieving revision 1.18 diff -u -p -r1.18 Makefile --- Makefile20 Mar 2020 16:44:25 - 1.18 +++ Makefile23 Feb 2021 21:40:01 - @@ -3,7 +3,7 @@ COMMENT = utilities to read and parse Argus data DISTNAME = argus-clients-3.0.8.2 -REVISION = 2 +REVISION = 3 CATEGORIES = net HOMEPAGE = http://qosient.com/argus/ Index: patches/patch-common_argus_util_c === RCS file: /cvs/ports/net/argus-clients/patches/patch-common_argus_util_c,v retrieving revision 1.5 diff -u -p -r1.5 patch-common_argus_util_c --- patches/patch-common_argus_util_c 12 Aug 2016 21:39:14 - 1.5 +++ patches/patch-common_argus_util_c 23 Feb 2021 21:40:01 - @@ -1,7 +1,19 @@ $OpenBSD: patch-common_argus_util_c,v 1.5 2016/08/12 21:39:14 steven Exp $ common/argus_util.c.orig Wed Jun 1 21:17:28 2016 -+++ common/argus_util.cFri Jun 3 19:23:33 2016 -@@ -22679,8 +22679,8 @@ ArgusLog (int priority, char *fmt, ...) + +First hunk: remove unused variable that clashes with one in raconvert + +Index: common/argus_util.c +--- common/argus_util.c.orig common/argus_util.c +@@ -6634,7 +6634,6 @@ ArgusGetIndicatorString (struct ArgusParserStruct *par + + + char argus_strbuf[MAXSTRLEN]; +-u_short ArgusThisProto; + + void + ArgusPrintSourceID (struct ArgusParserStruct *parser, char *buf, struct ArgusRecordStruct *argus, int len) +@@ -22679,8 +22678,8 @@ ArgusLog (int priority, char *fmt, ...) *tptr++ = buf[i]; } -- Christian "naddy" Weisgerber na...@mips.inka.de
Remove x11/golem?
x11/golem is an old window manager. This is another port that is broken by -fno-common. Our port is at version 0.0.5, which is 19 years old. When you start it, there is a spew of errors about undefined symbols and the plugins can't be loaded. I don't think anybody uses this. There is a newer development version 0.0.6 on Sourceforge. It's from 2007. It relies on an included copy of complib, which is Linux-only. FreeBSD somehow had a port of 0.0.6, but they deleted it in 2019: BROKEN= All plugins fail to load with Undefined symbol "display" DEPRECATED= Broken for more than 6 months BROKEN_aarch64= fails to link: can't create dynamic relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol: display in readonly segment Does anybody want to fix this? No? Remove it? -- Christian "naddy" Weisgerber na...@mips.inka.de
