update scipy to 1.7.3
Following the recent fix to gnuradio, here's an update of scipy from the
1.6.x series to the 1.7.x series now that we have pythran.
This doesn't fix the warning about numpy being too new yet. That will need
an update to a newer version of scipy which will take more time.
All reverse dependencies built on amd64 for testing.
ok?
Index: Makefile
===
RCS file: /cvs/ports/math/py-scipy/Makefile,v
retrieving revision 1.55
diff -u -p -u -r1.55 Makefile
--- Makefile19 Jan 2023 03:13:35 - 1.55
+++ Makefile4 Sep 2023 04:28:41 -
@@ -1,6 +1,6 @@
COMMENT= maths, science and engineering modules for Python
-MODPY_EGG_VERSION= 1.6.3
+MODPY_EGG_VERSION= 1.7.3
DISTNAME= scipy-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
@@ -29,7 +29,10 @@ MODPY_DISTUTILS_BUILDARGS = --fcompiler=
BUILD_DEPENDS= ${RUN_DEPENDS} \
${MODFORTRAN_BUILD_DEPENDS} \
- devel/py-pybind11${MODPY_FLAVOR}>=2.4.3
+ devel/py-pybind11${MODPY_FLAVOR}>=2.4.3 \
+ devel/py-pip${MODPY_FLAVOR} \
+ lang/cython${MODPY_FLAVOR} \
+ lang/pythran${MODPY_FLAVOR}
LIB_DEPENDS= ${MODFORTRAN_LIB_DEPENDS} \
math/cblas \
Index: distinfo
===
RCS file: /cvs/ports/math/py-scipy/distinfo,v
retrieving revision 1.13
diff -u -p -u -r1.13 distinfo
--- distinfo19 Jan 2023 03:13:35 - 1.13
+++ distinfo4 Sep 2023 04:28:41 -
@@ -1,2 +1,2 @@
-SHA256 (scipy-1.6.3.tar.gz) = p1sBTTKU/OJoUqnQTqJ7VnHYZza+s0rN/AWFkkYmBwc=
-SIZE (scipy-1.6.3.tar.gz) = 27187987
+SHA256 (scipy-1.7.3.tar.gz) = q1h1+s/e934KR9X9OeoXi1jmDkVKTIWqHlL8uA23ur8=
+SIZE (scipy-1.7.3.tar.gz) = 36102562
Index: patches/patch-scipy_special_tests_test_basic_py
===
RCS file:
/cvs/ports/math/py-scipy/patches/patch-scipy_special_tests_test_basic_py,v
retrieving revision 1.7
diff -u -p -u -r1.7 patch-scipy_special_tests_test_basic_py
--- patches/patch-scipy_special_tests_test_basic_py 19 Jan 2023 03:13:35
- 1.7
+++ patches/patch-scipy_special_tests_test_basic_py 4 Sep 2023 04:28:41
-
@@ -4,7 +4,7 @@ https://github.com/numpy/numpy/pull/5020
Index: scipy/special/tests/test_basic.py
--- scipy/special/tests/test_basic.py.orig
+++ scipy/special/tests/test_basic.py
-@@ -3303,7 +3303,8 @@ def test_xlog1py():
+@@ -3301,7 +3301,8 @@ def test_xlog1py():
if x == 0 and not np.isnan(y):
return x
else:
Index: pkg/PLIST
===
RCS file: /cvs/ports/math/py-scipy/pkg/PLIST,v
retrieving revision 1.17
diff -u -p -u -r1.17 PLIST
--- pkg/PLIST 19 Jan 2023 03:13:35 - 1.17
+++ pkg/PLIST 4 Sep 2023 04:28:46 -
@@ -1,12 +1,13 @@
@conflict py-scipy-*
@pkgpath math/py-scipy
+lib/python${MODPY_VERSION}/site-packages/SciPy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
+lib/python${MODPY_VERSION}/site-packages/SciPy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
+lib/python${MODPY_VERSION}/site-packages/SciPy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
+lib/python${MODPY_VERSION}/site-packages/SciPy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
+lib/python${MODPY_VERSION}/site-packages/SciPy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
+lib/python${MODPY_VERSION}/site-packages/SciPy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
+lib/python${MODPY_VERSION}/site-packages/SciPy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/scipy/
-lib/python${MODPY_VERSION}/site-packages/scipy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
-lib/python${MODPY_VERSION}/site-packages/scipy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
-lib/python${MODPY_VERSION}/site-packages/scipy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
-lib/python${MODPY_VERSION}/site-packages/scipy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
-lib/python${MODPY_VERSION}/site-packages/scipy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
-lib/python${MODPY_VERSION}/site-packages/scipy-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/scipy/HACKING.rst.txt
lib/python${MODPY_VERSION}/site-packages/scipy/INSTALL.rst.txt
lib/python${MODPY_VERSION}/site-packages/scipy/LICENSE.txt
@@ -27,10 +28,12 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/scipy/_build_utils/${MODPY_PYCACHE}compiler_helper.${MODPY_PYC_MAGIC_TAG}pyc
Re: UPDATE: qwt-6.2.0
On Sun, 3 Sep 2023, Stefan Hagen wrote: > Rafael Sadowski wrote (2023-08-31 07:00 IST): > > Simple update qwt-6.2.0. Tested on amd64. OK? > > How to test it? > > It breaks gnuradio: > /usr/ports/pobj/gnuradio-3.8.2.0/gnuradio-3.8.2.0/gr-qtgui/lib/../include/gnuradio/qtgui/DisplayPlot.h:44:10: > fatal error: 'qwt_compat.h' file not found > I ran into the same problem while testing a scipy update so integrated pull 5320 from upstream which fixes this problem and have committed this. This allows me to make progress on scipy. With the below I was able to launch gnuradio. Although to be honest it seems like gnuradio itself is in dire need of an update. Index: Makefile === RCS file: /cvs/ports/comms/gnuradio/Makefile,v retrieving revision 1.18 diff -u -p -u -r1.18 Makefile --- Makefile31 Jul 2023 07:18:36 - 1.18 +++ Makefile4 Sep 2023 03:05:00 - @@ -7,7 +7,7 @@ COMMENT = signal-processing toolkit for V =3.8.2.0 DISTNAME = gnuradio-$V -REVISION = 7 +REVISION = 8 SHARED_LIBS += gnuradio-analog 0.0 # 3.7 SHARED_LIBS += gnuradio-atsc 0.0 # 3.7 Index: patches/patch-gr-qtgui_include_gnuradio_qtgui_DisplayPlot_h === RCS file: patches/patch-gr-qtgui_include_gnuradio_qtgui_DisplayPlot_h diff -N patches/patch-gr-qtgui_include_gnuradio_qtgui_DisplayPlot_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-gr-qtgui_include_gnuradio_qtgui_DisplayPlot_h 4 Sep 2023 03:05:00 - @@ -0,0 +1,18 @@ +backport https://github.com/gnuradio/gnuradio/pull/5302 so +gnuradio can build with Qwt 6.2 + +Index: gr-qtgui/include/gnuradio/qtgui/DisplayPlot.h +--- gr-qtgui/include/gnuradio/qtgui/DisplayPlot.h.orig gr-qtgui/include/gnuradio/qtgui/DisplayPlot.h +@@ -41,7 +41,10 @@ + #include + + #if QWT_VERSION >= 0x06 +-#include ++typedef QPointF QwtDoublePoint; ++typedef QRectF QwtDoubleRect; ++ ++typedef QwtInterval QwtDoubleInterval; + #endif + + typedef QList QColorList; Index: patches/patch-gr-qtgui_include_gnuradio_qtgui_TimeRasterDisplayPlot_h === RCS file: patches/patch-gr-qtgui_include_gnuradio_qtgui_TimeRasterDisplayPlot_h diff -N patches/patch-gr-qtgui_include_gnuradio_qtgui_TimeRasterDisplayPlot_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-gr-qtgui_include_gnuradio_qtgui_TimeRasterDisplayPlot_h 4 Sep 2023 03:05:00 - @@ -0,0 +1,17 @@ +backport https://github.com/gnuradio/gnuradio/pull/5302 so +gnuradio can build with Qwt 6.2 + +Index: gr-qtgui/include/gnuradio/qtgui/TimeRasterDisplayPlot.h +--- gr-qtgui/include/gnuradio/qtgui/TimeRasterDisplayPlot.h.orig gr-qtgui/include/gnuradio/qtgui/TimeRasterDisplayPlot.h +@@ -35,7 +35,9 @@ + #if QWT_VERSION < 0x06 + #include + #else +-#include ++#include ++ ++typedef QwtInterval QwtDoubleInterval; + #endif + + /*! Index: patches/patch-gr-qtgui_include_gnuradio_qtgui_WaterfallDisplayPlot_h === RCS file: patches/patch-gr-qtgui_include_gnuradio_qtgui_WaterfallDisplayPlot_h diff -N patches/patch-gr-qtgui_include_gnuradio_qtgui_WaterfallDisplayPlot_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-gr-qtgui_include_gnuradio_qtgui_WaterfallDisplayPlot_h 4 Sep 2023 03:05:00 - @@ -0,0 +1,17 @@ +backport https://github.com/gnuradio/gnuradio/pull/5302 so +gnuradio can build with Qwt 6.2 + +Index: gr-qtgui/include/gnuradio/qtgui/WaterfallDisplayPlot.h +--- gr-qtgui/include/gnuradio/qtgui/WaterfallDisplayPlot.h.orig gr-qtgui/include/gnuradio/qtgui/WaterfallDisplayPlot.h +@@ -34,7 +34,9 @@ + #if QWT_VERSION < 0x06 + #include + #else +-#include ++#include ++ ++typedef QwtInterval QwtDoubleInterval; + #endif + + /*! Index: patches/patch-gr-qtgui_include_gnuradio_qtgui_plot_raster_h === RCS file: patches/patch-gr-qtgui_include_gnuradio_qtgui_plot_raster_h diff -N patches/patch-gr-qtgui_include_gnuradio_qtgui_plot_raster_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-gr-qtgui_include_gnuradio_qtgui_plot_raster_h 4 Sep 2023 03:05:00 - @@ -0,0 +1,19 @@ +backport https://github.com/gnuradio/gnuradio/pull/5302 so +gnuradio can build with Qwt 6.2 + +Index: gr-qtgui/include/gnuradio/qtgui/plot_raster.h +--- gr-qtgui/include/gnuradio/qtgui/plot_raster.h.orig gr-qtgui/include/gnuradio/qtgui/plot_raster.h +@@ -28,8 +28,10 @@ + #include + + #if QWT_VERSION >= 0x06 +-#include +-#include // doesn't seem necessary, but is... ++#include ++#include ++ ++typedef QwtInterval QwtDoubleInterval; + #endif + + class QwtColorMap; Index: patches/patch-gr-qtgui_include_gnuradio_qtgui_plot_waterfall_h === RCS file:
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2023/09/03 22:25:20 Modified files: comms/gnuradio : Makefile Added files: comms/gnuradio/patches: patch-gr-qtgui_include_gnuradio_qtgui_DisplayPlot_h patch-gr-qtgui_include_gnuradio_qtgui_TimeRasterDisplayPlot_h patch-gr-qtgui_include_gnuradio_qtgui_WaterfallDisplayPlot_h patch-gr-qtgui_include_gnuradio_qtgui_plot_raster_h patch-gr-qtgui_include_gnuradio_qtgui_plot_waterfall_h patch-gr-qtgui_include_gnuradio_qtgui_qtgui_types_h patch-gr-qtgui_include_gnuradio_qtgui_timeRasterGlobalData_h patch-gr-qtgui_include_gnuradio_qtgui_waterfallGlobalData_h patch-gr-qtgui_lib_plot_raster_cc patch-gr-qtgui_lib_plot_waterfall_cc patch-gr-qtgui_lib_timeRasterGlobalData_cc patch-gr-qtgui_lib_waterfallGlobalData_cc Log message: make gnuradio build again following recent qwt update Integrate pull 5320 from upstream which adds support for qwt 6.2+
Re: CVS: cvs.openbsd.org: ports
On Sun, Sep 03, 2023 at 04:46:49PM +0200, Antoine Jacoutot wrote: > On Sat, Sep 02, 2023 at 11:32:27AM -0600, Thomas Frohwein wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: t...@cvs.openbsd.org2023/09/02 11:32:27 > > > > Modified files: > > games/fna : Makefile distinfo > > games/fna/files: FNA.Settings.props > > > > Log message: > > canary use of the new MODULES=dist-tuple > > I don't know if this change is the reason, but it fails right at 'make > extract'. it's related and is fixed again with: https://marc.info/?l=openbsd-ports-cvs=169375215927111=2 > ===> Checking files for fna-23.07p0 > >> Fetch https://github.com/FNA-XNA/FNA/releases/download/23.07/fna-2307.zip > 562fdd89-5efa-475e-91e... 100% > |**| 3824 KB > 00:00 > >> Fetch > >> https://github.com/FNA-XNA/FNA.NetStub/archive/ebff244074bb3c28aeeb8cf7b383b5a029d7e28d.tar.gz > >> Fetch > >> https://github.com/flibitijibibo/Vorbisfile-CS/archive/521c8532f03b3608a141b36d7c1343e816b46cb1.tar.gz > >> (SHA256) fna-2307.zip: OK > >> (SHA256) > >> FNA-XNA-FNA.NetStub-ebff244074bb3c28aeeb8cf7b383b5a029d7e28d.tar.gz: OK > >> (SHA256) > >> flibitijibibo-Vorbisfile-CS-521c8532f03b3608a141b36d7c1343e816b46cb1.tar.gz: > >> OK > ===> Extracting for fna-23.07p0 > rmdir: /usr/ports/pobj/fna-23.07/FNA/../FNA.NetStub: Directory not empty > mv: > /usr/ports/pobj/fna-23.07/FNA.NetStub-ebff244074bb3c28aeeb8cf7b383b5a029d7e28d: > No such file or directory > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2748 > '_post-extract-finalize': @[[ -d > /usr/ports/pobj/fna-23.07/FNA/../FNA.NetStu...) > *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2741 > '/usr/ports/pobj/fna-23.07/.extract_done': @cd /usr/ports/games/fna && > PKGPA...) > *** Error 2 in /usr/ports/games/fna > (/usr/ports/infrastructure/mk/bsd.port.mk:2637 'all': @lock=fna-23.07p0; > export _LOCKS_HELD=" fna-23.07...) > > -- > Antoine
Re: CVS: cvs.openbsd.org: ports
On Sun, 3 Sep 2023, Daniel Dickman wrote: > CVSROOT: /cvs > Module name: ports > Changes by: dan...@cvs.openbsd.org 2023/09/03 18:56:02 > > Modified files: > www/jupyter-notebook: Makefile distinfo > www/jupyter-notebook/pkg: PLIST > > Log message: > update to jupyter-notebook 6.3.0 > > This was ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2023/09/03 18:56:02 Modified files: www/jupyter-notebook: Makefile distinfo www/jupyter-notebook/pkg: PLIST Log message: update to jupyter-notebook 6.3.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2023/09/03 18:49:20 Modified files: net/dbip : Makefile.inc net/dbip/asn : distinfo net/dbip/city : distinfo net/dbip/country: distinfo Log message: Update dbip to 2023.09.
Re: UPDATE: x11/fvwm3 to 1.0.7
Hi Marc, Marc Espie wrote on Mon, Sep 04, 2023 at 12:11:52AM +0200: > On Sun, Sep 03, 2023 at 08:54:55PM +0200, Ingo Schwarze wrote: >> In addition to that, showing the complete list from man -w would >> force man(1) to do additional work, slowing down display of the >> manual page. When any of the -w, -a, or -k options is given, man(1) >> always searches through the whole MANPATH. By contrast, in standard >> mode, i.e. without any of these three options, it ends the search >> after the first database that returns a match and displays that >> match right away. For example, if you type "man printf", only the >> base system manual page database is inspected and you do not have to > How much work is that actually ? I mean with the current database system > if you just say "man something" it ought to be fairly quick, no ? > > (especially with just 3 databases) Actually, you have a point here. On my notebook, measuring the difference isn't even trivial. I managed to do it by inserting calls to clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) into the code. On my notebook, the variation of the times is quite large while the times themselves are rather small, but anyway, here are the results for a simple name lookup, not including times for reading, parsing, and formatting the actual manual page file - all times in milliseconds: program startup time until the program reaches main(): 2 - 4 ms prep work before opening the database (option parsing etc.): 0.4 - 0.6 ms lookup time in the base system database: 1 - 3 ms lookup time in the Xenocara database: 0.5 - 1.5 ms lookup time in the ports database: 0.9 - 2.3 ms It looks like the difference is measureable. I performed no rigorous statistics, but a crude estimate might be that skipping the Xenocara and ports databases as we currently do saves about half the lookup time, or in absolute terms about 2 milliseconds on average on my notebook. Frankly, i don't have a luna88k machine, but at least on modern hardware, it looks like this doesn't matter at all. So *if* we want to show this information to the user, i guess i could just take that micro-optimization out and always scan all databases. However, nobody told me so far that they like the idea of showing this information, but one developer told me privately that they are not a fan. By the way, the point of getting rid of that optimization would be that in a situation like this, $ man -w FvwmPager /usr/X11R6/man/man1/FvwmPager.1 /usr/local/man/man1/FvwmPager.1 we would get, with the patch and without the optimization, $ man FvwmPager Showing: /usr/X11R6/man/man1/FvwmPager.1 See also: /usr/local/man/man1/FvwmPager.1 FvwmPager(1) General Commands Manual FvwmPager(1) NAME FvwmPager - the FVWM Pager module [...] That looks neat for the FVWM case - however, i fear some people might like exactly the same feature less in this case: $ man ls Showing: /usr/share/man/man1/ls.1 See also: /usr/local/man/man1/gls.1 LS(1) General Commands Manual LS(1) NAME ls - list directory contents [...] So, if many people use neither -w nor -a, how do you usually find out that there are multiple manual pages for the name you are looking for? Are you using man -f printf # but i would have expected that to be even less known? man -k Nm=printf # but that can be quite noisy IMHO... Or? Yours, Ingo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/09/03 18:25:19 Modified files: devel/p5-B-Keywords: Makefile distinfo Log message: update p5-B-Keywords to 1.26
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/09/03 17:52:48 Modified files: databases/p5-Data-RandomPerson: Makefile distinfo databases/p5-Data-RandomPerson/pkg: PLIST Log message: update p5-Data-RandomPerson to 0.60
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/09/03 17:51:38 Modified files: textproc : Makefile Log message: p5-List-Util-WeightedChoice
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/09/03 17:49:08 Log message: import p5-List-Util-WeightedChoice 0.06 OK sthen@ Comment: extension to allow for nonnormalized weighted choices Description: Perl extension to allow for nonnormalized weighted choices. Just one function, a simple means of making a weighted random choice. Status: Vendor Tag: bluhm Release Tags: bluhm_20230904 N ports/textproc/p5-List-Util-WeightedChoice/Makefile N ports/textproc/p5-List-Util-WeightedChoice/distinfo N ports/textproc/p5-List-Util-WeightedChoice/pkg/DESCR N ports/textproc/p5-List-Util-WeightedChoice/pkg/PLIST No conflicts created by this import
Re: [new] devel/py-logfury
On 2023/09/03 18:05, Paul Galbraith wrote: > Hi, this is a new port of the python logfury logging toolkit. It's a > sub-dependency of the B2 command-line tool for Backblaze cloud storage > access (https://www.backblaze.com/docs/cloud-storage-command-line-tools) > which is what I'm really aiming to get packaged. > > https://pypi.org/project/logfury > > Is this Ok to add? Feedback appreciated. > ok with "# needs testfixtures" added next to NO_TEST (no need to send a new diff)
Re: new textproc/p5-List-Util-WeightedChoice
Now with attachment. On Mon, Sep 04, 2023 at 01:35:22AM +0200, Alexander Bluhm wrote: > Hi, > > List::Util::WeightedChoice is needed for another port update. > ok to import p5-List-Util-WeightedChoice-0.06 ? > > Comment: > extension to allow for nonnormalized weighted choices > > Required by: > p5-Data-RandomPerson-0.60 > > Description: > Perl extension to allow for nonnormalized weighted choices. Just > one function, a simple means of making a weighted random choice. > > bluhm p5-List-Util-WeightedChoice.tgz Description: application/tar-gz
new textproc/p5-List-Util-WeightedChoice
Hi, List::Util::WeightedChoice is needed for another port update. ok to import p5-List-Util-WeightedChoice-0.06 ? Comment: extension to allow for nonnormalized weighted choices Required by: p5-Data-RandomPerson-0.60 Description: Perl extension to allow for nonnormalized weighted choices. Just one function, a simple means of making a weighted random choice. bluhm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 16:16:48 Modified files: editors/vim: Tag: OPENBSD_7_3 Makefile distinfo editors/vim/patches: Tag: OPENBSD_7_3 patch-runtime_filetype_vim patch-src_configure_ac editors/vim/pkg: Tag: OPENBSD_7_3 PLIST-main Removed files: editors/vim/patches: Tag: OPENBSD_7_3 patch-runtime_syntax_bindzone_vim Log message: update vim in -stable
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 16:16:11 Modified files: editors/vim: Makefile distinfo Log message: use DIST_TUPLE
Re: UPDATE: x11/fvwm3 to 1.0.7
On Sun, Sep 03, 2023 at 08:54:55PM +0200, Ingo Schwarze wrote: > In addition to that, showing the complete list from man -w would > force man(1) to do additional work, slowing down display of the > manual page. When any of the -w, -a, or -k options is given, man(1) > always searches through the whole MANPATH. By contrast, in standard > mode, i.e. without any of these three options, it ends the search > after the first database that returns a match and displays that > match right away. For example, if you type "man printf", only the > base system manual page database is inspected and you do not have to How much work is that actually ? I mean with the current database system if you just say "man something" it ought to be fairly quick, no ? (especially with just 3 databases)
[new] devel/py-logfury
Hi, this is a new port of the python logfury logging toolkit. It's a sub-dependency of the B2 command-line tool for Backblaze cloud storage access (https://www.backblaze.com/docs/cloud-storage-command-line-tools) which is what I'm really aiming to get packaged. https://pypi.org/project/logfury Is this Ok to add? Feedback appreciated. py-logfury.tgz Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 16:05:45 Modified files: editors/vim: Makefile distinfo Log message: update to vim-9.0.1859, various recent commits have been security-ish (buffer overflow, potential oob write, etc) set COMPILER_LANGS=c while there, COMPILER was added for ruby 3.2 on sparc64 but this isn't C++ software so no need to pull in libestdc++
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/03 15:51:10 Modified files: textproc/ruby-redcloth: Makefile Log message: Remove tests that do not run
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/03 15:41:41 Modified files: textproc/ruby-fast_xs: Makefile Log message: Fix tests
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/03 15:40:47 Modified files: textproc/ruby-fast-stemmer: Makefile Log message: Fix tests
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/03 15:33:19 Modified files: net/ruby-snmp : Makefile Log message: Remove tests that do not run
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 14:39:13 Modified files: devel/llvm/13 : Makefile devel/llvm/13/patches: patch-lld_ELF_Relocations_cpp patch-lld_docs_ld_lld_1 patch-llvm_lib_Target_Mips_AsmParser_MipsAsmParser_cpp Log message: merge some obvious differences from base llvm that we need to have
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dan...@cvs.openbsd.org 2023/09/03 14:34:58 Modified files: math/py-sympy : Makefile distinfo math/py-sympy/patches: patch-setup_py math/py-sympy/pkg: PLIST Log message: update py-sympy to 1.12
Re: [update] net/synapse 1.91.0
Working for me on amd64, thanks! On 8/30/23 08:17, Renaud Allard wrote: Sorry, I sent a diff from before the cvsup. Here is the correct one. On 8/30/23 14:54, Renaud Allard wrote: Hello, Here is a patch for net/synapse 1.91.0. Tested working on amd64. Best Regards
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2023/09/03 14:22:01 Modified files: wayland: Makefile Log message: Add new ports but comment out for now
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 14:08:36 Modified files: emulators/qemu : Makefile Log message: set USE_NOBTCFI=Yes to help qemu with Intel Bowel Syndrome
[maintainer] www/gotosocial 0.10.0 -> 0.11.1
Hi @ports,
Nice to see GoToSocial back on OpenBSD.
Please find enclosed an update for the port.
For DISTFILES, I tried to do it according to [1] but I am not sure
I did it properly.
Release notes:
https://github.com/superseriousbusiness/gotosocial/releases/tag/v0.11.0
https://github.com/superseriousbusiness/gotosocial/releases/tag/v0.11.1
Hashtags are here at last!
It would be nice if someone using sqlite could test it, just to be sure.
Regards,
Hukadan
[1] https://marc.info/?l=openbsd-ports=169263393617832=2diff --git a/www/gotosocial/Makefile b/www/gotosocial/Makefile
index 95f053d1d2d..d8e6386603d 100644
--- a/www/gotosocial/Makefile
+++ b/www/gotosocial/Makefile
@@ -4,7 +4,7 @@ ONLY_FOR_ARCHS = amd64
COMMENT = ActivityPub social network server
MODGO_MODNAME = github.com/superseriousbusiness/gotosocial
-MODGO_VERSION = v0.10.0
+MODGO_VERSION = v0.11.1
DISTNAME = gotosocial-${MODGO_VERSION}
@@ -15,8 +15,8 @@ HOMEPAGE = https://docs.gotosocial.org
MAINTAINER = Hukadan
# fetch the web assets built for the release
-DISTFILES += gotosocial_${MODGO_VERSION:S/v//}_web-assets.tar.gz:0
-MASTER_SITES0 = https://github.com/superseriousbusiness/gotosocial/releases/download/${MODGO_VERSION}/
+DISTFILES.web_assets += gotosocial_${MODGO_VERSION:S/v//}_web-assets.tar.gz
+MASTER_SITES.web_assets = https://github.com/superseriousbusiness/gotosocial/releases/download/${MODGO_VERSION}/
# AGPL-3.0+
PERMIT_PACKAGE = yes
diff --git a/www/gotosocial/distinfo b/www/gotosocial/distinfo
index f276f024d10..4ed3fa9f316 100644
--- a/www/gotosocial/distinfo
+++ b/www/gotosocial/distinfo
@@ -299,8 +299,8 @@ SHA256 (go_modules/codeberg.org/gruf/go-byteutil/@v/v1.0.0.mod) = QcCPpVXeuDc9bN
SHA256 (go_modules/codeberg.org/gruf/go-byteutil/@v/v1.0.2.mod) = QcCPpVXeuDc9bNUG2/F8y9plYbXMZJN3ZB2V28sK/cE=
SHA256 (go_modules/codeberg.org/gruf/go-byteutil/@v/v1.1.2.mod) = QcCPpVXeuDc9bNUG2/F8y9plYbXMZJN3ZB2V28sK/cE=
SHA256 (go_modules/codeberg.org/gruf/go-byteutil/@v/v1.1.2.zip) = YdFgfs0/+DA01h7y5g70hFS99VEtG+pnYU0N4ausIMI=
-SHA256 (go_modules/codeberg.org/gruf/go-cache/v3/@v/v3.4.1.mod) = 5kbbHxAFZ6H7oG7LVj3Dc79cc5XdQbXfVchVXdpILh4=
-SHA256 (go_modules/codeberg.org/gruf/go-cache/v3/@v/v3.4.1.zip) = jp6uMmh9hAkQUazauz4HyPTcdmMzMhu9AP9J3DXenLY=
+SHA256 (go_modules/codeberg.org/gruf/go-cache/v3/@v/v3.5.6.mod) = N5CctzQ2q9TgO28dsMWMJq6Qz4wUkLecSh8NdFygj54=
+SHA256 (go_modules/codeberg.org/gruf/go-cache/v3/@v/v3.5.6.zip) = QIQJtkilE91mzJb2fBoqb2HW0a1tN0s2FR8T3kWGzqo=
SHA256 (go_modules/codeberg.org/gruf/go-ctx/@v/v1.0.2.mod) = wr52uw3dr0RsUJTdOvvEwdl0PGaPxMvSZCxMsrMjshg=
SHA256 (go_modules/codeberg.org/gruf/go-ctx/@v/v1.0.2.zip) = F0aClFhGGw85QwVMsrs4g7HEWs0as4n0A4ffKeXAaj0=
SHA256 (go_modules/codeberg.org/gruf/go-debug/@v/v1.3.0.mod) = PpjlrH+jWs0iQ3sZNCdpabawPmQNOre0+NpDvviQCdk=
@@ -324,8 +324,8 @@ SHA256 (go_modules/codeberg.org/gruf/go-iotools/@v/v0.0.0-20230601182242-d933b07
SHA256 (go_modules/codeberg.org/gruf/go-iotools/@v/v0.0.0-20230601182242-d933b07dcbef.zip) = zsf9f7z8fPL3kCMLdFoGKkKul7LML6zBe8eAOLukoog=
SHA256 (go_modules/codeberg.org/gruf/go-kv/@v/v1.5.1.mod) = +YI13A8UyxDnPIygqX+V89WmVsml9Q+qUxPxNVJsKS8=
SHA256 (go_modules/codeberg.org/gruf/go-kv/@v/v1.5.2.mod) = +YI13A8UyxDnPIygqX+V89WmVsml9Q+qUxPxNVJsKS8=
-SHA256 (go_modules/codeberg.org/gruf/go-kv/@v/v1.6.1.mod) = u3i0DiJMNRlNuWC0m+U8IBzTQLkOQFlizyrB7dzBekg=
-SHA256 (go_modules/codeberg.org/gruf/go-kv/@v/v1.6.1.zip) = XihoFpINC0LZvs7UuCyMY2KQdgRqduSrwYEAEFElfKU=
+SHA256 (go_modules/codeberg.org/gruf/go-kv/@v/v1.6.4.mod) = u3i0DiJMNRlNuWC0m+U8IBzTQLkOQFlizyrB7dzBekg=
+SHA256 (go_modules/codeberg.org/gruf/go-kv/@v/v1.6.4.zip) = nRlmyYnh4AwWQ9CdqZh/53fkBq9pVPEStvk9/LBAZjc=
SHA256 (go_modules/codeberg.org/gruf/go-log/@v/v1.0.5.mod) = T+icqUaGfqbZ1gMi/jmMyTu3SogXhnBuxXSnRneuejA=
SHA256 (go_modules/codeberg.org/gruf/go-log/@v/v1.0.5.zip) = 4srurKHxjdBs0jU6ZkwSwZa8pkKIygY9Rm4X5dIHoV0=
SHA256 (go_modules/codeberg.org/gruf/go-logger/v2/@v/v2.2.1.mod) = QpjiICxHUEnKt74GZVj8+xcGFajd6wFCfGr6wL+Xrjc=
@@ -359,12 +359,14 @@ SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.mod) = KAIbQYClnDmTYHq
SHA256 (go_modules/github.com/!burnt!sushi/toml/@v/v0.3.1.zip) = gVxuWUdF8tiEL/mksFacZpXmzf1eB+Wz2Y0GtyykHjw=
SHA256 (go_modules/github.com/!burnt!sushi/xgb/@v/v0.0.0-20160522181843-27f122750802.mod) = luveICsJL29NHzkwvAfPGKVpmZjd6lG5T+hYETspqNg=
SHA256 (go_modules/github.com/!burnt!sushi/xgb/@v/v0.0.0-20160522181843-27f122750802.zip) = 9Slix/vsqB6op3fR+LHx0lgD3EN/u0kPJTNEIyiEMo4=
+SHA256 (go_modules/github.com/!dmitriy!v!titov/size/@v/v1.5.0.mod) = MRl6b0y6ZcNzFGrSQEh42h4IAUcO6Lj6AfkWEM2m6Y8=
+SHA256 (go_modules/github.com/!dmitriy!v!titov/size/@v/v1.5.0.zip) = ynVQ9PbVfZWHB70eJcxjSrB2hK0CfpwU5yUyxpyh6iY=
SHA256 (go_modules/github.com/!kim!machine!gun/automemlimit/@v/v0.2.6.mod) = b5LMxSk8dJByGenBa0mL61o/i84ZEJV5VRX0/vhw4+0=
SHA256 (go_modules/github.com/!kim!machine!gun/automemlimit/@v/v0.2.6.zip) = 3x9yK/hT4aDPl2h9qNecNIuELtBwoCdO1PPA15C3Rf0=
SHA256
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 13:22:04 Modified files: devel/llvm/13/patches: patch-llvm_lib_Target_AArch64_AArch64ReturnProtectorLowering_h patch-llvm_lib_Target_Mips_MipsReturnProtectorLowering_h patch-llvm_lib_Target_PowerPC_PPCReturnProtectorLowering_h patch-llvm_lib_Target_X86_X86ReturnProtectorLowering_h Log message: my regexp was not good enough... let's fixup the files (no code change)
jupyter notebook 6.2.0 -> 6.3.0
Fairly small update of Jupyter notebook.
(Updating to jupyter notebook 6.4.0 or newer will require bringing in new
deps)
ok?
Index: Makefile
===
RCS file: /cvs/ports/www/jupyter-notebook/Makefile,v
retrieving revision 1.23
diff -u -p -u -r1.23 Makefile
--- Makefile8 Jan 2023 02:57:01 - 1.23
+++ Makefile3 Sep 2023 19:04:33 -
@@ -1,6 +1,6 @@
COMMENT = web-based notebook for interactive computing
-MODPY_EGG_VERSION =6.2.0
+MODPY_EGG_VERSION =6.3.0
DISTNAME = notebook-${MODPY_EGG_VERSION}
PKGNAME = jupyter-notebook-${MODPY_EGG_VERSION}
Index: distinfo
===
RCS file: /cvs/ports/www/jupyter-notebook/distinfo,v
retrieving revision 1.10
diff -u -p -u -r1.10 distinfo
--- distinfo8 Jan 2023 02:57:01 - 1.10
+++ distinfo3 Sep 2023 19:04:33 -
@@ -1,2 +1,2 @@
-SHA256 (notebook-6.2.0.tar.gz) = BGSyjhjnoGzsN+YXdUbCMic5vgeWLdE79xK8uINh8BM=
-SIZE (notebook-6.2.0.tar.gz) = 13927515
+SHA256 (notebook-6.3.0.tar.gz) = y8k5jWyBRz6c24kdLK6cDTcY/KKJ3abSbfXLZg/K3H0=
+SIZE (notebook-6.3.0.tar.gz) = 13922153
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/jupyter-notebook/pkg/PLIST,v
retrieving revision 1.12
diff -u -p -u -r1.12 PLIST
--- pkg/PLIST 8 Jan 2023 02:57:01 - 1.12
+++ pkg/PLIST 3 Sep 2023 19:04:34 -
@@ -27,6 +27,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}config_manager.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}config_manager.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}conftest.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}conftest.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}extensions.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}extensions.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}jstest.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -39,6 +41,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}notebookapp.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}serverextensions.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}serverextensions.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}traittypes.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}traittypes.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}transutils.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}transutils.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/notebook/${MODPY_PYCACHE}utils.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -131,6 +135,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/notebook/bundler/tools.py
lib/python${MODPY_VERSION}/site-packages/notebook/bundler/zip_bundler.py
lib/python${MODPY_VERSION}/site-packages/notebook/config_manager.py
+lib/python${MODPY_VERSION}/site-packages/notebook/conftest.py
lib/python${MODPY_VERSION}/site-packages/notebook/edit/
lib/python${MODPY_VERSION}/site-packages/notebook/edit/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/notebook/edit/${MODPY_PYCACHE}/
@@ -2017,6 +2022,8 @@ lib/python${MODPY_VERSION}/site-packages
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/notebook/tests/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/notebook/tests/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/notebook/tests/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/notebook/tests/${MODPY_PYCACHE}conftest.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/notebook/tests/${MODPY_PYCACHE}conftest.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/notebook/tests/${MODPY_PYCACHE}launchnotebook.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/notebook/tests/${MODPY_PYCACHE}launchnotebook.${MODPY_PYC_MAGIC_TAG}pyc
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 13:08:19 Modified files: mail/stalwart/jmap: Makefile Log message: use the lang/clang module and adapt to the split of devel/llvm
Re: UPDATE: x11/fvwm3 to 1.0.7
Hello Stefan, Stefan Hagen wrote on Sun, Sep 03, 2023 at 04:19:07PM +0100: > I think Espies suggestion is more discoverable because the user gets a > message on install he might see. Granted. Then again, rumour has it that people rarely heed post-install messages from pkg_add(1). > Ingos suggestion is technically "more correct". However, I asked 6 devs > and only one knew what -a/w does. So I don't think this is used. Interesting and astonishing to me. The -w option originated in Version 7 AT UNIX and -w in 4.3BSD-Tahoe. I certainly use both of them *very* often, usually many times every day, and feel surprised that people apparently get along without using them. Still, useful to know for the maintainer of a tool if an option is known to and used by few people. > From a user perspective, I think it would be nice if we cold make the > manpage display a tiny bit dynamic and show the output of man -w at the > bottom. > > Example > > MANPAGE VERSIONS: > fvwm3-FvwmButtons(1), FvwmButtons(1) Hm, that's an interesting idea, and i kind of like it. However, showing such information at the bottom feels like a dubious choice to me, in particular if many people are unaware of the -w and -a options. If there is more than one match, the user may be about to read the wrong one, and they likely want that information up front, rather than first reading the whole thing and then being told at the end: "Got you! This wasn't the page you were looking for." In addition to that, showing the complete list from man -w would force man(1) to do additional work, slowing down display of the manual page. When any of the -w, -a, or -k options is given, man(1) always searches through the whole MANPATH. By contrast, in standard mode, i.e. without any of these three options, it ends the search after the first database that returns a match and displays that match right away. For example, if you type "man printf", only the base system manual page database is inspected and you do not have to wait for a scan of the Xenocara and ports databases. So, here is a patch that displays a heads-up message up front - but only if more than one result is found in the same database. Besides, nothing changes in -w, -a, and -k mode, this only tweaks the default mode. For example: $ man printf Showing: /usr/share/man/man1/printf.1 See also: /usr/share/man/man3/printf.3 See also: /usr/share/man/man9/printf.9 PRINTF(1) General Commands Manual PRINTF(1) NAME printf - formatted output [...] $ man chmod chown Showing: /usr/share/man/man1/chmod.1 See also: /usr/share/man/man2/chmod.2 CHMOD(1) General Commands Manual CHMOD(1) NAME chmod - change file modes [...] BUGS There's no perm option for the naughty bits. OpenBSD 7.3 September 2, 2019 OpenBSD 7.3 Showing: /usr/share/man/man8/chown.8 See also: /usr/share/man/man2/chown.2 CHOWN(8) System Manager's Manual CHOWN(8) NAME chown - change file owner and group [...] $ man boot Showing: /usr/share/man/man8/amd64/boot.8 See also: /usr/share/man/man9/boot.9 BOOT(8)System Manager's Manual (amd64) BOOT(8) NAME boot, boot.conf - amd64-specific second-stage bootstrap [...] As a matter of fact, that's slightly similar to what man.openbsd.org has already been doing for quite some time, even though some details regarding presentation and priorities differ, consider: https://man.openbsd.org/printf https://man.openbsd.org/boot Even with the patch, such headers will *not* be displayed with explict commands like $ man 3 printf $ man -s 2 chmod chown $ man -S luna88k 8 boot or when there is only one match, like in $ man ls $ man -S sparc64 boot Does this make sense to you? By the way, i think showing the full path (just like in man -w) is better than just showing printf(1), printf(3), and printf(9). In complicated cases, for example when architecture dependent, preformatted, or compressed pages, or sections with suffixes are involved, seeing the full path may help the user to understand at first sight what is going on. Even in simple cases, seing right away whether the clash happens in base, Xenocara, ports, or in some custom tree (which can be configured via man.conf(5), MANPATH, -m, or -M) may also help. On the other hand, its trivial to figure out that to get at /usr/share/man/man3/printf.3, "man 3 printf" will work. Then again, if people insist on showing "printf(1), printf(3), ..." only, i can certainly tweak the patch. Similarly, moving the information after each manual page is trivial, but not better IMHO. > This would bring discoverability to Ingos solution. And we could freely > rename manpages, because our man(1) is clever enough to find them > anyway. (compared to
Re: New port: devel/objfw
Am 03.09.23 um 19:55 schrieb Stuart Henderson: yep, exactly. reasons: - we find that some upstream projects don't understand shared library versioning, and either increment the version number when not needed, or don't increment when it is needed. Upstream handling reads exactly like OpenBSD handling, so this case is probably fine. (minor increased for new symbols, major increased on ABI break) as this information is used to trigger updates of packages depending on a library after that library has changed incompatibly, it needs to work otherwise people get mismatching library+other packages. - in the past (rarely) we've had to bump library versions in ports after a major incompatible change in system headers/libraries I think we're unlikely to use this second reason again, we have a different mechanism to force updates of all ports which is more convenient now, but even ignoring that the first reason is enough. and considering that when a port is brought into OpenBSD the upstream library version is often >0.0, making sure that ports start with 0.0 means that we can check that ports is indeed in control of the version number. I guess since the second case is unlikely, in practice, OpenBSD's version will always be one major version less than upstream. But hey, if that is required to show "we're using OpenBSD library versions here and not upstream versions", so be it. My concern is just someone having it installed without ports on OpenBSD - and then there is a lot of fun with library versions being exactly one major version apart. Seems like asking for trouble on systems where you have both, ports and non-ports versions. please don't do this, patches straight from github are fragile and easily change e.g. when the shortened commit hash is no longer unique they add an extra hex digit. if you must fetch a patch from elsewhere please use a static file rather than an on-the-fly generated one, but preferably include the patches in the port (copy the original files with an .orig.port suffix in the work directory and apply patches, then run "make update-patches" to generate files with the correct format and filename conventions) I realized that patch is not needed at all, as both versions are 1.0 in this release. Only in the future, when they diverge, such a patch would be required. However, any future release will already include the patch, so, including it is not necessary and just setting the variables like it already were will just magically make it work with the next update. -- Jonathan
Re: CVS: cvs.openbsd.org: ports
x11/py-qt5 broke in my last bulk:
>>> Running configure in x11/py-qt5,python3 at 1693756267.05
===> x11/py-qt5,python3
===> Generating configure for py3-qt5-5.15.9p0
===> Configuring for py3-qt5-5.15.9p0
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/sipbuild/toml.py", line 25, in
import tomllib
ModuleNotFoundError: No module named 'tomllib'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/bin/sip-build", line 5, in
from sipbuild.tools.build import main
File "/usr/local/lib/python3.10/site-packages/sipbuild/__init__.py", line 25,
in
from .abstract_builder import AbstractBuilder
File "/usr/local/lib/python3.10/site-packages/sipbuild/abstract_builder.py",
line 26, in
from .configurable import Configurable
File "/usr/local/lib/python3.10/site-packages/sipbuild/configurable.py", line
27, in
from .pyproject import PyProjectOptionException
File "/usr/local/lib/python3.10/site-packages/sipbuild/pyproject.py", line
26, in
from .toml import toml_load
File "/usr/local/lib/python3.10/site-packages/sipbuild/toml.py", line 27, in
import tomli as tomllib
ModuleNotFoundError: No module named 'tomli'
On Sat, 2023-09-02 at 04:58 -0600, Rafael Sadowski wrote:
> CVSROOT:/cvs
> Module name:ports
> Changes by: rsadow...@cvs.openbsd.org 2023/09/02 04:58:57
>
> Modified files:
> editors/qscintilla: Makefile distinfo
> editors/qscintilla/pkg: PLIST
> editors/py-qscintilla: Makefile distinfo
> editors/py-qscintilla/pkg: PLIST
> x11/py-sip-qt5 : Makefile distinfo
> devel/py-qt-builder: Makefile distinfo
> x11/py-qtpy : Makefile distinfo
> x11/py-qtpy/pkg: PLIST
> devel/py-sip : Makefile distinfo
> devel/py-sip/pkg: PLIST
> x11/py-qt5 : Makefile
> Removed files:
> devel/py-sip/patches:
>
> patch-sipbuild_generator_parser_instantiations_py
>
> Log message:
> Update riverbankcomputing (Python Qt5) ecosystem and friends
>
> - QScintilla 2.14.1
> - Py QScintilla 2.14.1
> - SIP support for PyQt 12.12.2
> - PyQt-builder 1.15.2
> - QtPy 2.4.0
>
> Bonus: x11/py-qt5 depends on x11/py-sip-qt5${MODPY_FLAVOR}>=12.12 now
>
> Feedback, tests and OK landry@ merci
>
--
Antoine
Re: New port: devel/objfw
Am 03.09.23 um 19:49 schrieb Jeremie Courreges-Anglas: I don't know which of .SILENT or make -s or the escape characters hide the compiler command lines used to build the object files, but let's find a way to disable this behaviour at least in the port. Attached is an updated port that removes the silent rules. However, that makes the output quite confusing and is IMO not really an improvement. But hey, you're the guys looking at that output, if that's what you prefer, I'm fine with that :-). We need to see the programs and flags involved, if only to verify that said flags are sane in the context of the ports tree. If that's all: buildsys.mk is the source of truth for all that. Printing OBJC, OBJCFLAGS, CPPFLAGS, LIBS and LDFLAGS from that would probably be sufficient for that purpose and would look a lot less messy. Like being used as an alternative for other objc frameworks and as a runtime for objc applications. Admittedly that's not an ecosystem I know much about. Nope, this is not an OpenStep implementation, so cannot act as the alternative of one. Thanks. Updated tarball attached which simplifies SHARED_LIBS handling and zaps COMPILER_LANGS=objc. Could you please tweak/patch the port so that compiler/linker commands are printed? I took those two changes. For silent see above. PTAL. -- Jonathan objfw.tar.gz Description: application/gzip
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 12:49:18 Modified files: x11/roxterm: Makefile distinfo x11/roxterm/pkg: PLIST Log message: update to roxterm-3.13.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2023/09/03 12:44:01 Modified files: x11/py-qt5 : Makefile Log message: Add missing build dependency on textproc/py-toml Spotted by Mark Patruck, thanks
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 12:43:30 Modified files: textproc/py-chardet: Makefile distinfo textproc/py-chardet/pkg: PLIST Log message: update to py3-chardet-5.2.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 12:43:27 Modified files: textproc/py-bracex: Makefile distinfo Log message: update to py3-bracex-2.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 12:42:37 Modified files: x11/kde-applications/umbrello: Makefile Log message: use the lang/clang module and adapt to the split of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 12:35:25 Modified files: devel/llvm : Makefile.inc Log message: add a diff-to-base make target to ease comparing each component between base and ports
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 12:29:31 Modified files: net/p5-SNMP-Info: Makefile distinfo net/p5-SNMP-Info/pkg: PLIST Log message: update to p5-SNMP-Info-3.95
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 12:26:13 Modified files: www/ttyd : Makefile distinfo Log message: update to ttyd-1.7.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lr...@cvs.openbsd.org 2023/09/03 12:26:00 Modified files: devel/intellij : Makefile distinfo devel/intellij/pkg: PLIST Log message: devel/intellij: update to 2023.2.1 ok landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 12:23:39 Modified files: www/py-multidict: Makefile distinfo Log message: update to py3-multidict-6.0.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2023/09/03 12:23:36 Modified files: www/py-soupsieve: Makefile distinfo Log message: update to py3-soupsieve-2.5
Re: [fix] cad/oce: unreplaced variable on cmake files
Klemens Nanni wrote:
> On Sun, Sep 03, 2023 at 04:32:24PM +0200, Johannes Thyssen Tishman wrote:
> > *ping*
> >
> > Aug 31, 2023 22:58:50 Johannes Thyssen Tishman :
>
> You can usually give it a week before pinging, four days is a little hasty,
> especially since oce is a monster C++ ports (~5600 files to compile), i.e.
> nothing you'd quickly (re)build and test.
Good to know, thanks. Never really know when is a good time to ping
and I was afraid it would come off a little pushy, I'm sorry. The
list has been quite active lately and I didn't want this patch to
get lost. My bad.
> The patched .cmake file stlil looks ugly, but should work.
Indeed. The cmake script is ugly as is IMO. Took me forever to debug.
> My machine is still churning along, I'll take care of the fix once confirmed.
Thanks a lot.
> Thanks.
>
> >
> > > Hi,
> > >
> > > The following cmake files installed by cad/oce contain a variable
> > > (${OCCT_INSTALL_BIN_LETTER}) that should've been replaced during
> > > installation:
> > >
> > > /usr/local/lib/cmake/opencascade/OpenCASCADEApplicationFrameworkTargets-release.cmake
> > > /usr/local/lib/cmake/opencascade/OpenCASCADEDataExchangeTargets-release.cmake
> > > /usr/local/lib/cmake/opencascade/OpenCASCADEDrawTargets-release.cmake
> > > /usr/local/lib/cmake/opencascade/OpenCASCADEFoundationClassesTargets-release.cmake
> > > /usr/local/lib/cmake/opencascade/OpenCASCADEModelingAlgorithmsTargets-release.cmake
> > > /usr/local/lib/cmake/opencascade/OpenCASCADEModelingDataTargets-release.cmake
> > > /usr/local/lib/cmake/opencascade/OpenCASCADEVisualizationTargets-release.cmake
> > >
> > > To verify, run the following. You'll notice how the variable is
> > > escaped (\${...}):
> > >
> > > # pkg_add oce
> > > $ grep OCCT_INSTALL_BIN_LETTER
> > > /usr/local/lib/cmake/opencascade/OpenCASCADE*
> > >
> > > I'm working on porting FreeCAD (which depends on oce)
> > > and I'm getting the following error during the configuration stage:
> > >
> > >> CMake Error at
> > >> /usr/local/lib/cmake/opencascade/OpenCASCADEFoundationClassesTargets.cmake:87
> > >> (message):
> > >> The imported target "TKernel" references the file
> > >>
> > >> "/usr/local/lib${OCCT_INSTALL_BIN_LETTER}/libTKernel.so.1.0"
> > >>
> > >> but this file does not exist. Possible reasons include:
> > >>
> > >> * The file was deleted, renamed, or moved to another location.
> > >>
> > >> * An install or uninstall procedure did not complete successfully.
> > >>
> > >> * The installation package was faulty and contained
> > >>
> > >>
> > >> "/usr/local/lib/cmake/opencascade/OpenCASCADEFoundationClassesTargets.cmake"
> > >>
> > >> but not all the files it references.
> > >
> > > The diff below is based on a patch from the FreeBSD port and should
> > > fix this issue. The only consumer is cad/kicad and it built fine.
> > >
> > > Kind regards,
> > > Johannes
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/cad/oce/Makefile,v
> > > retrieving revision 1.9
> > > diff -u -p -r1.9 Makefile
> > > --- Makefile 28 Feb 2023 21:22:28 - 1.9
> > > +++ Makefile 31 Aug 2023 19:47:51 -
> > > @@ -7,7 +7,7 @@ GH_ACCOUNT = tpaviot
> > > GH_PROJECT = oce
> > > GH_COMMIT = 98a788062f0f30593880b0df1bcf967408212ba4
> > > DISTNAME = oce-7.6.0
> > > -REVISION = 1
> > > +REVISION = 2
> > >
> > > .for LIB in TKBO TKBRep TKBin TKBinL TKBinTObj TKBinXCAF TKBool TKCAF
> > > TKCDF \
> > > TKDCAF TKDraw TKFeat TKFillet TKG2d TKG3d TKGeomAlgo TKGeomBase TKHLR
> > > \
> > > Index: patches/patch-adm_cmake_occt_macros_cmake
> > > ===
> > > RCS file: /cvs/ports/cad/oce/patches/patch-adm_cmake_occt_macros_cmake,v
> > > retrieving revision 1.2
> > > diff -u -p -r1.2 patch-adm_cmake_occt_macros_cmake
> > > --- patches/patch-adm_cmake_occt_macros_cmake 11 Mar 2022 18:24:30
> > > - 1.2
> > > +++ patches/patch-adm_cmake_occt_macros_cmake 31 Aug 2023 19:47:51 -
> > > @@ -1,15 +1,12 @@
> > > -Ugly hack on ALL_OCCT_TARGET_FILES: change later
> > > -
> > > Index: adm/cmake/occt_macros.cmake
> > > --- adm/cmake/occt_macros.cmake.orig
> > > +++ adm/cmake/occt_macros.cmake
> > > -@@ -592,7 +592,8 @@ macro (OCCT_UPDATE_TARGET_FILE)
> > > +@@ -592,7 +592,7 @@ macro (OCCT_UPDATE_TARGET_FILE)
> > > "cmake_policy(PUSH)
> > > cmake_policy(SET CMP0007 NEW)
> > > string (TOLOWER \"\${CMAKE_INSTALL_CONFIG_NAME}\"
> > > CMAKE_INSTALL_CONFIG_NAME_LOWERCASE)
> > > - file (GLOB ALL_OCCT_TARGET_FILES
> > > \"${INSTALL_DIR}/${INSTALL_DIR_CMAKE}/OpenCASCADE*Targets-\${CMAKE_INSTALL_CONFIG_NAME_LOWERCASE}.cmake\")
> > > -+ file (GLOB ALL_OCCT_TARGET_FILES
> > > -+
> > > \"${PROJECT_BINARY_DIR}/CMakeFiles/Export/${INSTALL_DIR_CMAKE}/OpenCASCADE*Targets-\${CMAKE_INSTALL_CONFIG_NAME_LOWERCASE}.cmake\")
> > > ++ file (GLOB ALL_OCCT_TARGET_FILES
> > >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/09/03 11:58:20 Modified files: converters/p5-Convert-ASN1: Makefile distinfo Log message: update p5-Convert-ASN1 to 0.34
Re: New port: devel/objfw
On 2023/09/03 15:58, Jonathan Schleifer wrote:
> This would be small enough if the package still built. Moving
> > SHARED_LIBS to 0.0 I get:
> >
> > Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfw.so.0.0
> > does not exist
> > Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwrt.so.0.0
> > does not exist
> > Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwtls.so.0.0
> > does not exist
>
> Ah, so the problem here was different definitions of soname. For me, the
> .0.0 is part of the soname, so it is indeed part of the soname after all (if
> going by my definition).
>
> > at make package time. This is what Stuart meant when he said that the
> > port should be in control: SHARED_LIBS should decide the version used to
> > build and install the shared libraries.
>
> So in plain English: OpenBSD wants to ignore upstream library version /
> soname versions and always use its own. Got it.
yep, exactly. reasons:
- we find that some upstream projects don't understand shared library
versioning, and either increment the version number when not needed, or
don't increment when it is needed. as this information is used to trigger
updates of packages depending on a library after that library has
changed incompatibly, it needs to work otherwise people get mismatching
library+other packages.
- in the past (rarely) we've had to bump library versions in ports after
a major incompatible change in system headers/libraries
I think we're unlikely to use this second reason again, we have a
different mechanism to force updates of all ports which is more
convenient now, but even ignoring that the first reason is enough.
and considering that when a port is brought into OpenBSD the upstream
library version is often >0.0, making sure that ports start with 0.0
means that we can check that ports is indeed in control of the version
number.
> > - .SILENT doesn't help understanding what is going on
> The non-.SILENT output isn't too useful either, as that's just a bunch of
> shellscript then that loops over things.
> > and I wonder about two things:
> > - COMPILER + COMPILER_LANGS: is COMPILER_LANGS actually useful here?
> You mean because Clang is guaranteed to support ObjC?
> > - is this framework already used by other applications in the wild?
> I'm at least fairly certain not by anything else in OpenBSD ports ;).
> >Could it be used as a building block for other ports?
> Define building blocks. Like a Makefile template for other ports? I don't
> think so, it's just a regular library, users of the library can use whatever
> build system they want.
> >Do we have to
> >care about some existing ports automatically picking it up?
> I don't think so, no.
> > That's a lot of questions, sorry :)
>
> No worries, I hope I addressed everything with the new tarball I attached.
comments on the makefile:
: COMPILER= base-clang ports-clang
: COMPILER_LANGS =objc
objc is not supported by the COMPILER/COMPILER_LANGS framework; from
bsd.port.mk(5):
COMPILER_LANGS
The value of COMPILER_LANGS will be added to the respective
module's supported langs. Defaults to ‘c c++’. Only ‘c’ and
‘c++’ are supported by this mechanism. ‘fortran’ or ‘java’ still
need old modules annotations, so that it's possible to select,
e.g., ‘gfortran’ from gcc 8 while having clang from base. See
also CHOSEN_COMPILER.
: LIBOBJFW_VERSION_MAJOR =0
: LIBOBJFW_VERSION_MINOR =0
: LIBOBJFWRT_VERSION_MAJOR = 0
: LIBOBJFWRT_VERSION_MINOR = 0
: LIBOBJFWTLS_VERSION_MAJOR = 0
: LIBOBJFWTLS_VERSION_MINOR = 0
:
: SHARED_LIBS += objfw ${LIBOBJFW_VERSION_MAJOR}.${LIBOBJFW_VERSION_MINOR}
: SHARED_LIBS += objfwrt
${LIBOBJFWRT_VERSION_MAJOR}.${LIBOBJFWRT_VERSION_MINOR}
: SHARED_LIBS += objfwtls
${LIBOBJFWTLS_VERSION_MAJOR}.${LIBOBJFWTLS_VERSION_MINOR}
...
: MAKE_FLAGS += OBJFW_LIB_MAJOR=${LIBOBJFW_VERSION_MAJOR}
: MAKE_FLAGS += OBJFW_LIB_MINOR=${LIBOBJFW_VERSION_MINOR}
: MAKE_FLAGS += OBJFWRT_LIB_MAJOR=${LIBOBJFWRT_VERSION_MAJOR}
: MAKE_FLAGS += OBJFWRT_LIB_MINOR=${LIBOBJFWRT_VERSION_MINOR}
: MAKE_FLAGS += OBJFWTLS_LIB_MAJOR=${LIBOBJFWTLS_VERSION_MAJOR}
: MAKE_FLAGS += OBJFWTLS_LIB_MINOR=${LIBOBJFWTLS_VERSION_MINOR}
this can be simplified
SHARED_LIBS += objfw 0.0
SHARED_LIBS += objfwrt 0.0
SHARED_LIBS += objfwtls 0.0
MAKE_FLAGS += OBJFW_LIB_MAJOR=${LIBobjfw_VERSION:R} \
OBJFW_LIB_MINOR=${LIBobjfw_VERSION:E} \
OBJFWRT_LIB_MAJOR=${LIBobjfwrt_VERSION:R} \
OBJFWRT_LIB_MINOR=${LIBobjfwrt_VERSION:E} \
OBJFWTLS_LIB_MAJOR=${LIBobjfwtls_VERSION:R} \
OBJFWTLS_LIB_MINOR=${LIBobjfwtls_VERSION:E}
: MASTER_SITES1 = https://github.com/ObjFW/ObjFW/commit/
please don't do this, patches straight from github are fragile and
easily change e.g. when the shortened commit hash is no longer
Re: New port: devel/objfw
On Sun, Sep 03 2023, Jeremie Courreges-Anglas wrote:
> On Sun, Sep 03 2023, Jonathan Schleifer wrote:
>> This would be small enough if the package still built. Moving
>>> SHARED_LIBS to 0.0 I get:
>>>
>>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfw.so.0.0
>>> does not exist
>>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwrt.so.0.0
>>> does not exist
>>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwtls.so.0.0
>>> does not exist
>>
>> Ah, so the problem here was different definitions of soname. For me, the
>> .0.0 is part of the soname, so it is indeed part of the soname after all
>> (if going by my definition).
>
> Not sure we have the same definition indeed. objfw indeed seems to
> use -Wl,-soname but not on OpenBSD (which is fine), so the resulting
> library doesn't have a DT_SONAME dynamic tag and the versioning
> information available to ld.so(8) only comes from the major.minor
> version encoded in the library file name.
>
>>> at make package time. This is what Stuart meant when he said that the
>>> port should be in control: SHARED_LIBS should decide the version used to
>>> build and install the shared libraries.
>>
>> So in plain English: OpenBSD wants to ignore upstream library version /
>> soname versions and always use its own. Got it.
>
> Basically, yes.
>
>>> For automake or cmake ports this
>>> is usually handled transparently by the ports infrastructure, which sets
>>> various values in the build environment. Here you don't seem to use
>>> automake so you're probably going to need patches + ${SUBST_CMD} to inject
>>> LIBobjfw_VERSION etc at the right spot.
>>
>> Ah, perfect, this can just be overridden using MAKE_FLAGS. Done.
>
> Thanks. See the attached port for a more
>
>>> Regarding the port, I see two nits:
>>> - Portable -> portable in COMMENT
>> Done
>>> - maybe include your full name in MAINTAINER
>> Done
>>> - .SILENT doesn't help understanding what is going on
>> The non-.SILENT output isn't too useful either, as that's just a bunch
>> of shellscript then that loops over things.
>
> I don't know which of .SILENT or make -s or the escape characters hide
> the compiler command lines used to build the object files, but let's
> find a way to disable this behaviour at least in the port. We need to
> see the programs and flags involved, if only to verify that said flags
> are sane in the context of the ports tree.
>
>>> and I wonder about two things:
>>> - COMPILER + COMPILER_LANGS: is COMPILER_LANGS actually useful here?
>> You mean because Clang is guaranteed to support ObjC?
>
> Yup. Also the ports infrastructure doesn't seem to do much with
> COMPILER_LANGS=objc.
>
>>> - is this framework already used by other applications in the wild?
>> I'm at least fairly certain not by anything else in OpenBSD ports ;).
>>>Could it be used as a building block for other ports?
>> Define building blocks.
>
> Like being used as an alternative for other objc frameworks and as
> a runtime for objc applications. Admittedly that's not an ecosystem
> I know much about.
>
>> Like a Makefile template for other ports?
>> I don't think so, it's just a regular library, users of the library can
>> use whatever build system they want.
>>>Do we have to
>>>care about some existing ports automatically picking it up?
>> I don't think so, no.
>>> That's a lot of questions, sorry :)
>>
>> No worries, I hope I addressed everything with the new tarball I attached.
>
> Thanks. Updated tarball attached which simplifies SHARED_LIBS handling
> and zaps COMPILER_LANGS=objc. Could you please tweak/patch the port so
> that compiler/linker commands are printed?
Woops...
objfw-2.tar.gz
Description: Binary data
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: New port: devel/objfw
On Sun, Sep 03 2023, Jonathan Schleifer wrote:
> This would be small enough if the package still built. Moving
>> SHARED_LIBS to 0.0 I get:
>>
>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfw.so.0.0 does
>> not exist
>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwrt.so.0.0
>> does not exist
>> Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwtls.so.0.0
>> does not exist
>
> Ah, so the problem here was different definitions of soname. For me, the
> .0.0 is part of the soname, so it is indeed part of the soname after all
> (if going by my definition).
Not sure we have the same definition indeed. objfw indeed seems to
use -Wl,-soname but not on OpenBSD (which is fine), so the resulting
library doesn't have a DT_SONAME dynamic tag and the versioning
information available to ld.so(8) only comes from the major.minor
version encoded in the library file name.
>> at make package time. This is what Stuart meant when he said that the
>> port should be in control: SHARED_LIBS should decide the version used to
>> build and install the shared libraries.
>
> So in plain English: OpenBSD wants to ignore upstream library version /
> soname versions and always use its own. Got it.
Basically, yes.
>> For automake or cmake ports this
>> is usually handled transparently by the ports infrastructure, which sets
>> various values in the build environment. Here you don't seem to use
>> automake so you're probably going to need patches + ${SUBST_CMD} to inject
>> LIBobjfw_VERSION etc at the right spot.
>
> Ah, perfect, this can just be overridden using MAKE_FLAGS. Done.
Thanks. See the attached port for a more
>> Regarding the port, I see two nits:
>> - Portable -> portable in COMMENT
> Done
>> - maybe include your full name in MAINTAINER
> Done
>> - .SILENT doesn't help understanding what is going on
> The non-.SILENT output isn't too useful either, as that's just a bunch
> of shellscript then that loops over things.
I don't know which of .SILENT or make -s or the escape characters hide
the compiler command lines used to build the object files, but let's
find a way to disable this behaviour at least in the port. We need to
see the programs and flags involved, if only to verify that said flags
are sane in the context of the ports tree.
>> and I wonder about two things:
>> - COMPILER + COMPILER_LANGS: is COMPILER_LANGS actually useful here?
> You mean because Clang is guaranteed to support ObjC?
Yup. Also the ports infrastructure doesn't seem to do much with
COMPILER_LANGS=objc.
>> - is this framework already used by other applications in the wild?
> I'm at least fairly certain not by anything else in OpenBSD ports ;).
>>Could it be used as a building block for other ports?
> Define building blocks.
Like being used as an alternative for other objc frameworks and as
a runtime for objc applications. Admittedly that's not an ecosystem
I know much about.
> Like a Makefile template for other ports?
> I don't think so, it's just a regular library, users of the library can
> use whatever build system they want.
>>Do we have to
>>care about some existing ports automatically picking it up?
> I don't think so, no.
>> That's a lot of questions, sorry :)
>
> No worries, I hope I addressed everything with the new tarball I attached.
Thanks. Updated tarball attached which simplifies SHARED_LIBS handling
and zaps COMPILER_LANGS=objc. Could you please tweak/patch the port so
that compiler/linker commands are printed?
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/03 11:48:33 Modified files: devel/ruby-rspec/1: Makefile Log message: Remove tests that do not run
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/03 11:44:51 Modified files: devel/ruby-metaclass: Makefile Log message: Remove tests that do not run
Re: lang/ocaml and IBT WAS: amd64: IBT bulk build breakage
On Sun Sep 3, 2023 at 3:40 PM CEST, Christian Weisgerber wrote: > Volker Schlecht: > > > Is that an ok? :-) > > Yes, for your ocaml IBT fix and the opam IBT fix from chrisz@. Committed the ocaml fix and checked the build of sysutils/opam in tree. With the fixed ocaml, it seems to build and run without issues now, so I'd leave it to chrisz@ to commit the opam update.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 11:42:58 Modified files: wayland/wayland: Makefile Log message: use the lang/clang module and adapt to the split of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 11:41:30 Modified files: geo/py-osmium : Makefile Log message: use the lang/clang module and adapt to the split of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/03 11:41:05 Modified files: devel/ruby-locale: Makefile Log message: Remove tests that do not run
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 11:40:28 Modified files: devel/kdevelop : Makefile Log message: use the lang/clang module and adapt to the split of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2023/09/03 11:39:26 Modified files: devel/ruby-gettext: Makefile Log message: Remove tests that do not run
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 11:24:17 Modified files: devel/qt-creator: Makefile Log message: use the lang/clang module and adapt to the split of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 11:22:36 Modified files: x11/gnome/builder: Makefile Log message: switch over to the lang/clang module to adapt to the new llvm split
[new] www/py-flasgger
Hello, Here's a new port for py-flasgger which is a new dep for a www/py-httpbin update and possibly of interest for those who have APIs implemented in Flask. pkg/DESCR: Flask extension to extract OpenAPI-Specification from all Flask views registered in your API. https://github.com/flasgger/flasgger Comments? Thanks, Lucas py-flasgger.tgz Description: application/tar-gz
Re: [update] www/py-httpbin to 0.10.1
On Sun, Sep 03, 2023 at 04:59:42PM +, Lucas Raab wrote: > Hello, > > Here's an update for www/py-httpbin. This has been make test-ed with its two > deps: devel/py-test-httpbin and devel/py-treq. > > Switching to a new upstream which has adopted it after no contact from the > prior upstream. > > changelog since fork: > https://github.com/psf/httpbin/releases > > Comments? > > Thanks, > Lucas whoops, I forgot this requires a new port, py-flasgger. Set this asidw for now, sorry for the noise.
UPDATE: sysutils/coreutils 9.3 => 9.4
Hi ports -- Attached is an update to the GNU coreutils. NEWS: https://git.savannah.gnu.org/cgit/coreutils.git/tree/NEWS All tests pass on amd64; a big endian test would be appreciated. OK? ~BrianIndex: Makefile === RCS file: /cvs/ports/sysutils/coreutils/Makefile,v retrieving revision 1.27 diff -u -p -r1.27 Makefile --- Makefile4 Jun 2023 17:26:47 - 1.27 +++ Makefile3 Sep 2023 12:41:49 - @@ -1,6 +1,6 @@ COMMENT = file, shell and text manipulation utilities -DISTNAME = coreutils-9.3 +DISTNAME = coreutils-9.4 CATEGORIES = sysutils MAINTAINER = Brian Callahan Index: distinfo === RCS file: /cvs/ports/sysutils/coreutils/distinfo,v retrieving revision 1.14 diff -u -p -r1.14 distinfo --- distinfo4 Jun 2023 17:26:47 - 1.14 +++ distinfo3 Sep 2023 12:41:49 - @@ -1,2 +1,2 @@ -SHA256 (coreutils-9.3.tar.xz) = rbz8/omSNbceh2jc8HzVMlILf1T5qAZIQ/jRmakEu6o= -SIZE (coreutils-9.3.tar.xz) = 5808696 +SHA256 (coreutils-9.4.tar.xz) = 6mE6TPRGEjJukXIBu7zfvTAd4h/8O1m25cB+BAsnXlI= +SIZE (coreutils-9.4.tar.xz) = 5979200 Index: patches/patch-Makefile_in === RCS file: /cvs/ports/sysutils/coreutils/patches/patch-Makefile_in,v retrieving revision 1.14 diff -u -p -r1.14 patch-Makefile_in --- patches/patch-Makefile_in 4 Jun 2023 17:26:47 - 1.14 +++ patches/patch-Makefile_in 3 Sep 2023 12:41:49 - @@ -3,7 +3,7 @@ XXX: Avoid rebuilding coreutils.info; ou Index: Makefile.in --- Makefile.in.orig +++ Makefile.in -@@ -21087,6 +21087,7 @@ doc/$(am__dirstamp): +@@ -22186,6 +22186,7 @@ doc/$(am__dirstamp): @: > doc/$(am__dirstamp) $(srcdir)/doc/coreutils.info: doc/coreutils.texi $(srcdir)/doc/version.texi $(doc_coreutils_TEXINFOS) Index: pkg/PLIST === RCS file: /cvs/ports/sysutils/coreutils/pkg/PLIST,v retrieving revision 1.12 diff -u -p -r1.12 PLIST --- pkg/PLIST 4 Jun 2023 17:26:47 - 1.12 +++ pkg/PLIST 3 Sep 2023 12:41:49 - @@ -352,6 +352,11 @@ share/locale/sr/LC_TIME/coreutils.mo share/locale/sv/LC_MESSAGES/coreutils.mo share/locale/sv/LC_TIME/ share/locale/sv/LC_TIME/coreutils.mo +share/locale/ta/ +share/locale/ta/LC_MESSAGES/ +share/locale/ta/LC_MESSAGES/coreutils.mo +share/locale/ta/LC_TIME/ +share/locale/ta/LC_TIME/coreutils.mo share/locale/tr/LC_MESSAGES/coreutils.mo share/locale/tr/LC_TIME/ share/locale/tr/LC_TIME/coreutils.mo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 11:00:20 Modified files: emulators/citra: Makefile Log message: remove build dependency on devel/llvm; does not seem to be needed
[update] www/py-httpbin to 0.10.1
Hello,
Here's an update for www/py-httpbin. This has been make test-ed with its two
deps: devel/py-test-httpbin and devel/py-treq.
Switching to a new upstream which has adopted it after no contact from the
prior upstream.
changelog since fork:
https://github.com/psf/httpbin/releases
Comments?
Thanks,
Lucas
diff refs/heads/master refs/heads/httpbin
commit - a12677c96068efb4853bf1d30ce2533ae9bd2098
commit + 6f6d072fbb3518d06299f58447a56e32f7e3ffba
blob - f746e5c3dab07922dbc03b49b9b59807bd4c4383
blob + 5e6e6d3c26d27edc0d9cff1ada52083b10722b98
--- www/py-httpbin/Makefile
+++ www/py-httpbin/Makefile
@@ -1,15 +1,14 @@
COMMENT = HTTP request and response service
-MODPY_EGG_VERSION =0.7.0
+MODPY_EGG_VERSION =0.10.0
DISTNAME = httpbin-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 0
CATEGORIES = www
-HOMEPAGE = https://github.com/postmanlabs/httpbin
+HOMEPAGE = https://github.com/psf/httpbin
-# MIT
+# MIT, ISC
PERMIT_PACKAGE = Yes
MODULES = lang/python
@@ -18,12 +17,15 @@ MODPY_PI = Yes
MODPY_PYBUILD =setuptools
#MODPY_PYTEST_ARGS = test_httpbin.py
-RUN_DEPENDS = www/py-flask${MODPY_FLAVOR} \
- textproc/py-MarkupSafe${MODPY_FLAVOR} \
+RUN_DEPENDS = archivers/py-brotli${MODPY_FLAVOR} \
devel/py-decorator${MODPY_FLAVOR} \
- www/py-itsdangerous${MODPY_FLAVOR} \
+ devel/py-gevent${MODPY_FLAVOR} \
devel/py-six${MODPY_FLAVOR} \
- archivers/py-brotli${MODPY_FLAVOR} \
+ textproc/py-MarkupSafe${MODPY_FLAVOR} \
+ www/py-flasgger${MODPY_FLAVOR} \
+ www/py-flask${MODPY_FLAVOR} \
+ www/py-itsdangerous${MODPY_FLAVOR} \
+ www/py-jinja2${MODPY_FLAVOR} \
www/py-werkzeug${MODPY_FLAVOR}
# also wanted "raven" but it's only used for sending app errors to a
# web service, and does nothing unless SENTRY_DSN is set in the environment,
blob - b3aebdbcdcb0190b140ceba731d0ae979683411c
blob + e4b17ea77ec8fb5beecc61413ba83be67be16781
--- www/py-httpbin/distinfo
+++ www/py-httpbin/distinfo
@@ -1,2 +1,2 @@
-SHA256 (httpbin-0.7.0.tar.gz) = y7N3kMkVdfTxV1f0KtQdn3KesifV7b6J5OwXVIbbjfo=
-SIZE (httpbin-0.7.0.tar.gz) = 92613
+SHA256 (httpbin-0.10.0.tar.gz) = 2iapImNrzdGgezDHJll8xL6F0WDuOH4Ph7tRnP/smhw=
+SIZE (httpbin-0.10.0.tar.gz) = 103729
blob - eecb292ca7420ae605e08d08756a9bf882757587 (mode 644)
blob + /dev/null
--- www/py-httpbin/patches/patch-httpbin_core_py
+++ /dev/null
@@ -1,37 +0,0 @@
-BaseResponse -> Response as of werkzeug 2.0
-
-see: https://github.com/postmanlabs/httpbin/pull/674
-
-Index: httpbin/core.py
httpbin/core.py.orig
-+++ httpbin/core.py
-@@ -19,9 +19,8 @@ from flask import Flask, Response, request, render_tem
- from six.moves import range as xrange
- from werkzeug.datastructures import WWWAuthenticate, MultiDict
- from werkzeug.http import http_date
--from werkzeug.wrappers import BaseResponse
-+from werkzeug.wrappers import Response as WzResponse
- from werkzeug.http import parse_authorization_header
--from raven.contrib.flask import Sentry
-
- from . import filters
- from .helpers import get_headers, status_code, get_dict, get_request_range,
check_basic_auth, check_digest_auth, \
-@@ -48,17 +47,13 @@ def jsonify(*args, **kwargs):
- return response
-
- # Prevent WSGI from correcting the casing of the Location header
--BaseResponse.autocorrect_location_header = False
-+WzResponse.autocorrect_location_header = False
-
- # Find the correct template folder when running from a different location
- tmpl_dir = os.path.join(os.path.dirname(os.path.abspath(__file__)),
'templates')
-
- app = Flask(__name__, template_folder=tmpl_dir)
- app.debug = bool(os.environ.get('DEBUG'))
--
--# Send app errors to Sentry.
--if 'SENTRY_DSN' in os.environ:
--sentry = Sentry(app, dsn=os.environ['SENTRY_DSN'])
-
- # Set up Bugsnag exception tracking, if desired. To use Bugsnag, install the
- # Bugsnag Python client with the command "pip install bugsnag", and set the
blob - /dev/null
blob + 2029504b0471f8311a49e7ccbb3095055a69db9c (mode 644)
--- /dev/null
+++ www/py-httpbin/patches/patch-httpbin_filters_py
@@ -0,0 +1,15 @@
+Index: httpbin/filters.py
+--- httpbin/filters.py.orig
httpbin/filters.py
+@@ -10,7 +10,10 @@ This module provides response filter decorators.
+ import gzip as gzip2
+ import zlib
+
+-import brotlicffi as _brotli
++try:
++import brotlicffi as _brotli
++except ImportError:
++import brotli as _brotli
+
+ from six import BytesIO
+ from decimal import Decimal
blob - 78aa0169423053694a2d608623fac990cb694218
blob + fa78a699456f7bfea0d932fd5268b2cfdf48c484
--- www/py-httpbin/pkg/PLIST
+++ www/py-httpbin/pkg/PLIST
@@ -7,6 +7,7 @@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:51:11 Modified files: lang/rust : Makefile Log message: switch to lang/clang and set llvm version to 16 (unused for now)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2023/09/03 10:48:14 Modified files: devel/p5-Test-Output: Makefile distinfo devel/p5-Test-Output/pkg: DESCR Log message: update p5-Test-Output to 1.034
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:31:04 Modified files: lang/ldc : Makefile Log message: use the lang/clang module and adapt to the switch of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:30:39 Modified files: lang/clang : clang.port.mk Log message: allow changing the MODCLANG_VERSION
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:27:04 Modified files: lang/zig : Makefile Log message: this port seems to be broken on every usable arch, so put the least effort into moving to the split llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:25:26 Modified files: lang/crystal : Makefile Log message: use the lang/clang module and adapt to the switch of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:21:09 Modified files: lang/clazy : Makefile Log message: use the lang/clang module and adapt to the switch of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:19:57 Modified files: x11/qt5/qttools: Makefile x11/qt6/qttools: Makefile Log message: use the lang/clang module and adapt to the switch of devel/llvm
Re: UPDATE: x11/fvwm3 to 1.0.7
On Sun, Sep 03, 2023 at 04:19:07PM +0100, Stefan Hagen wrote: > Marc Espie wrote (2023-09-01 22:08 IST): > > On Thu, Aug 31, 2023 at 11:20:17PM +0200, Ingo Schwarze wrote: > > > Hi Stefan, > > > > > > Stefan Hagen wrote on Wed, Aug 30, 2023 at 09:41:20AM +0200: > > > > > > > There's no good way to handle a conflict that's introduced with an > > > > update. So what we would do is to move the manpages into the install > > > > directory. (thanks to espie@ for the suggestion) > > > > > > Actually, i regard that as bad advice, espie@ shouldn't say such things. > > > > I don't know. The ability of install versioned manpages for the same > > software doesn't seem to be a bad idea to me. > > > > And /etc/man.conf does feature new default paths, so why not ? > > > > If adding new directories isn't the right level, maybe new sections ? > > or explicit versionned stuff. > > > > Yeah, we've installed several versions of tcl for a long time. > > > > Oh, and man has a "-a" option to display ALL manual pages. > > > > We have currently ZERO mechanism to desambiguate anything outside of > > sections... > > > > if you say, man foo, it will give you the first foo, not even hinting > > there might be a second food behind it. > > > > Yeah, we can rename stuff so that man doesn't get confused, but why > > does man get confused in the first place ? > > I think Espies suggestion is more discoverable because the user gets a > message on install he might see. > > Ingos suggestion is technically "more correct". However, I asked 6 devs > and only one knew what -a/w does. So I don't think this is used. > > From a user perspective, I think it would be nice if we cold make the > manpage display a tiny bit dynamic and show the output of man -w at the > bottom. > > Example > > MANPAGE VERSIONS: > fvwm3-FvwmButtons(1), FvwmButtons(1) > > This would bring discoverability to Ingos solution. And we could freely > rename manpages, because our man(1) is clever enough to find them > anyway. (compared to linux man, which can't do this) > > Another idea would be to print something to stderr when more than one > manpage for the search term is available. Either before the pager is > started or after the pager is closed. > > I don't like what some linuxes do: SuSE for example shows the user a > list and asks which one to display. This is annoying. > > --- > > I'm sending another diff with Ingos suggestion. I'm happy with this as > well. Both is inconvenient in a way, but at least the man pages are > there. > > OK? > > - Stefan Hi Stefan and everyone else involved, thanks for all the feedback and explanations! The latest revision by Stefan looks good to me, tested on amd64.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:17:13 Modified files: devel/spidermonkey102: Makefile Log message: remove build dep on devel/llvm because llvm-ar is not available anymore without a version suffix
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:16:06 Modified files: devel/meson: Makefile Log message: use the lang/clang module and adapt to the switch of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:15:08 Modified files: devel/include-what-you-use: Makefile Log message: use the lang/clang module and adapt to the switch of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:14:30 Modified files: devel/codechecker: Makefile Log message: use the lang/clang module and adapt to the switch of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:13:31 Modified files: devel/clang-tools-extra: Makefile Log message: use the lang/clang module and adapt to the split of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2023/09/03 10:13:26 Modified files: infrastructure/lib/DPB: PkgPath.pm Log message: get rid of some noise in equiv.log: checking stubbed out paths for locknames won't make sense since they all have the same info, but not actually the same pkgname
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:11:14 Modified files: devel/llvm/16/patches: patch-lldb_source_Plugins_Process_OpenBSD_NativeRegisterContextOpenBSD_arm64_cpp patch-lldb_source_Plugins_Process_OpenBSD_NativeRegisterContextOpenBSD_arm64_h Log message: unbreak lldb build on arm64
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lr...@cvs.openbsd.org 2023/09/03 10:09:10 Modified files: games/devilutionx: Makefile distinfo games/devilutionx/pkg: PLIST README Added files: games/devilutionx/patches: patch-CMake_Dependencies_cmake patch-Source_CMakeLists_txt patch-Source_storm_storm_svid_cpp Removed files: games/devilutionx/patches: patch-CMakeLists_txt patch-CMake_FindSDL2_cmake patch-SourceS_miniwin_h Log message: games/devilutionx: update to 1.5.1 with feedback and contributions from bcallah@, sdk@, sthen@, and thfr@ many thanks! ok bcallah@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: rob...@cvs.openbsd.org 2023/09/03 10:07:59
Modified files:
devel/afl++: Makefile
Log message:
set LLVM_CONFIG to llvm-config-${MODCLANG_VERSION} after the split of devel/llvm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2023/09/03 10:07:41 Modified files: www/sogo : Makefile distinfo www/sogo/pkg : PLIST Added files: www/sogo/patches: patch-SoObjects_SOGo_SOGoGCSFolder_m Log message: update 5.8.0 -> 5.8.4 OK landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2023/09/03 10:06:44 Modified files: www/sope : Makefile distinfo Log message: update 5.8.0 -> 5.8.4 OK landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:05:56 Modified files: lang/clang : clang.port.mk Log message: modify the clang module a little so that we can use it in ports depending on llvm to handle dependencies
Re: [fix] cad/oce: unreplaced variable on cmake files
On Sun, Sep 03, 2023 at 04:32:24PM +0200, Johannes Thyssen Tishman wrote:
> *ping*
>
> Aug 31, 2023 22:58:50 Johannes Thyssen Tishman :
You can usually give it a week before pinging, four days is a little hasty,
especially since oce is a monster C++ ports (~5600 files to compile), i.e.
nothing you'd quickly (re)build and test.
The patched .cmake file stlil looks ugly, but should work.
My machine is still churning along, I'll take care of the fix once confirmed.
Thanks.
>
> > Hi,
> >
> > The following cmake files installed by cad/oce contain a variable
> > (${OCCT_INSTALL_BIN_LETTER}) that should've been replaced during
> > installation:
> >
> > /usr/local/lib/cmake/opencascade/OpenCASCADEApplicationFrameworkTargets-release.cmake
> > /usr/local/lib/cmake/opencascade/OpenCASCADEDataExchangeTargets-release.cmake
> > /usr/local/lib/cmake/opencascade/OpenCASCADEDrawTargets-release.cmake
> > /usr/local/lib/cmake/opencascade/OpenCASCADEFoundationClassesTargets-release.cmake
> > /usr/local/lib/cmake/opencascade/OpenCASCADEModelingAlgorithmsTargets-release.cmake
> > /usr/local/lib/cmake/opencascade/OpenCASCADEModelingDataTargets-release.cmake
> > /usr/local/lib/cmake/opencascade/OpenCASCADEVisualizationTargets-release.cmake
> >
> > To verify, run the following. You'll notice how the variable is
> > escaped (\${...}):
> >
> > # pkg_add oce
> > $ grep OCCT_INSTALL_BIN_LETTER /usr/local/lib/cmake/opencascade/OpenCASCADE*
> >
> > I'm working on porting FreeCAD (which depends on oce)
> > and I'm getting the following error during the configuration stage:
> >
> >> CMake Error at
> >> /usr/local/lib/cmake/opencascade/OpenCASCADEFoundationClassesTargets.cmake:87
> >> (message):
> >> The imported target "TKernel" references the file
> >>
> >> "/usr/local/lib${OCCT_INSTALL_BIN_LETTER}/libTKernel.so.1.0"
> >>
> >> but this file does not exist. Possible reasons include:
> >>
> >> * The file was deleted, renamed, or moved to another location.
> >>
> >> * An install or uninstall procedure did not complete successfully.
> >>
> >> * The installation package was faulty and contained
> >>
> >>
> >> "/usr/local/lib/cmake/opencascade/OpenCASCADEFoundationClassesTargets.cmake"
> >>
> >> but not all the files it references.
> >
> > The diff below is based on a patch from the FreeBSD port and should
> > fix this issue. The only consumer is cad/kicad and it built fine.
> >
> > Kind regards,
> > Johannes
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/cad/oce/Makefile,v
> > retrieving revision 1.9
> > diff -u -p -r1.9 Makefile
> > --- Makefile 28 Feb 2023 21:22:28 - 1.9
> > +++ Makefile 31 Aug 2023 19:47:51 -
> > @@ -7,7 +7,7 @@ GH_ACCOUNT = tpaviot
> > GH_PROJECT = oce
> > GH_COMMIT = 98a788062f0f30593880b0df1bcf967408212ba4
> > DISTNAME = oce-7.6.0
> > -REVISION = 1
> > +REVISION = 2
> >
> > .for LIB in TKBO TKBRep TKBin TKBinL TKBinTObj TKBinXCAF TKBool TKCAF TKCDF
> > \
> > TKDCAF TKDraw TKFeat TKFillet TKG2d TKG3d TKGeomAlgo TKGeomBase TKHLR \
> > Index: patches/patch-adm_cmake_occt_macros_cmake
> > ===
> > RCS file: /cvs/ports/cad/oce/patches/patch-adm_cmake_occt_macros_cmake,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 patch-adm_cmake_occt_macros_cmake
> > --- patches/patch-adm_cmake_occt_macros_cmake 11 Mar 2022 18:24:30 -
> > 1.2
> > +++ patches/patch-adm_cmake_occt_macros_cmake 31 Aug 2023 19:47:51 -
> > @@ -1,15 +1,12 @@
> > -Ugly hack on ALL_OCCT_TARGET_FILES: change later
> > -
> > Index: adm/cmake/occt_macros.cmake
> > --- adm/cmake/occt_macros.cmake.orig
> > +++ adm/cmake/occt_macros.cmake
> > -@@ -592,7 +592,8 @@ macro (OCCT_UPDATE_TARGET_FILE)
> > +@@ -592,7 +592,7 @@ macro (OCCT_UPDATE_TARGET_FILE)
> > "cmake_policy(PUSH)
> > cmake_policy(SET CMP0007 NEW)
> > string (TOLOWER \"\${CMAKE_INSTALL_CONFIG_NAME}\"
> > CMAKE_INSTALL_CONFIG_NAME_LOWERCASE)
> > - file (GLOB ALL_OCCT_TARGET_FILES
> > \"${INSTALL_DIR}/${INSTALL_DIR_CMAKE}/OpenCASCADE*Targets-\${CMAKE_INSTALL_CONFIG_NAME_LOWERCASE}.cmake\")
> > -+ file (GLOB ALL_OCCT_TARGET_FILES
> > -+
> > \"${PROJECT_BINARY_DIR}/CMakeFiles/Export/${INSTALL_DIR_CMAKE}/OpenCASCADE*Targets-\${CMAKE_INSTALL_CONFIG_NAME_LOWERCASE}.cmake\")
> > ++ file (GLOB ALL_OCCT_TARGET_FILES
> > \"\$ENV{DESTDIR}${INSTALL_DIR}/${INSTALL_DIR_CMAKE}/OpenCASCADE*Targets-\${CMAKE_INSTALL_CONFIG_NAME_LOWERCASE}.cmake\")
> > foreach(TARGET_FILENAME \${ALL_OCCT_TARGET_FILES})
> > file (STRINGS \"\${TARGET_FILENAME}\" TARGET_FILE_CONTENT)
> > file (REMOVE \"\${TARGET_FILENAME}\")
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:04:04 Modified files: devel/llvm : Makefile Added files: devel/llvm : Makefile.inc devel/llvm/files: DESCR-lldb DESCR-main DESCR-python README-main llvm-wrapper.sh.in Removed files: devel/llvm : distinfo devel/llvm/patches: patch-cmake_modules_GetLibraryName_cmake patch-cmake_modules_LLVMProcessSources_cmake patch-docs_CommandGuide_llvm-ranlib_rst patch-include_llvm_BinaryFormat_ELF_h patch-include_llvm_CodeGen_AsmPrinter_h patch-include_llvm_CodeGen_MachineFrameInfo_h patch-include_llvm_CodeGen_Passes_h patch-include_llvm_CodeGen_ReturnProtectorLowering_h patch-include_llvm_CodeGen_TargetFrameLowering_h patch-include_llvm_InitializePasses_h patch-lib_CodeGen_AsmPrinter_AsmPrinter_cpp patch-lib_CodeGen_CMakeLists_txt patch-lib_CodeGen_PrologEpilogInserter_cpp patch-lib_CodeGen_ReturnProtectorLowering_cpp patch-lib_CodeGen_ReturnProtectorPass_cpp patch-lib_CodeGen_TargetPassConfig_cpp patch-lib_MC_MCAsmInfoELF_cpp patch-lib_MC_MCELFStreamer_cpp patch-lib_MC_MCParser_AsmParser_cpp patch-lib_Target_AArch64_AArch64AsmPrinter_cpp patch-lib_Target_AArch64_AArch64FrameLowering_cpp patch-lib_Target_AArch64_AArch64FrameLowering_h patch-lib_Target_AArch64_AArch64ISelLowering_cpp patch-lib_Target_AArch64_AArch64InstrInfo_cpp patch-lib_Target_AArch64_AArch64InstrInfo_td patch-lib_Target_AArch64_AArch64ReturnProtectorLowering_cpp patch-lib_Target_AArch64_AArch64ReturnProtectorLowering_h patch-lib_Target_AArch64_AArch64Subtarget_h patch-lib_Target_AArch64_AArch64TargetMachine_cpp patch-lib_Target_AArch64_CMakeLists_txt patch-lib_Target_Mips_AsmParser_MipsAsmParser_cpp patch-lib_Target_Mips_CMakeLists_txt patch-lib_Target_Mips_MCTargetDesc_MipsABIInfo_cpp patch-lib_Target_Mips_MipsAsmPrinter_cpp patch-lib_Target_Mips_MipsFrameLowering_cpp patch-lib_Target_Mips_MipsFrameLowering_h patch-lib_Target_Mips_MipsISelLowering_cpp patch-lib_Target_Mips_MipsInstrInfo_td patch-lib_Target_Mips_MipsLoongson2FBTBFix_cpp patch-lib_Target_Mips_MipsReturnProtectorLowering_cpp patch-lib_Target_Mips_MipsReturnProtectorLowering_h patch-lib_Target_Mips_MipsTargetMachine_cpp patch-lib_Target_Mips_Mips_h patch-lib_Target_PowerPC_CMakeLists_txt patch-lib_Target_PowerPC_PPCAsmPrinter_cpp patch-lib_Target_PowerPC_PPCFrameLowering_cpp patch-lib_Target_PowerPC_PPCFrameLowering_h patch-lib_Target_PowerPC_PPCInstrInfo_td patch-lib_Target_PowerPC_PPCReturnProtectorLowering_cpp patch-lib_Target_PowerPC_PPCReturnProtectorLowering_h patch-lib_Target_PowerPC_PPCTargetMachine_cpp patch-lib_Target_RISCV_RISCVISelLowering_cpp patch-lib_Target_Sparc_SparcISelLowering_cpp patch-lib_Target_Sparc_SparcInstr64Bit_td patch-lib_Target_Sparc_SparcInstrInfo_td patch-lib_Target_X86_CMakeLists_txt patch-lib_Target_X86_X86AsmPrinter_h patch-lib_Target_X86_X86FixupGadgets_cpp patch-lib_Target_X86_X86FrameLowering_cpp patch-lib_Target_X86_X86FrameLowering_h patch-lib_Target_X86_X86IndirectThunks_cpp patch-lib_Target_X86_X86InstrCompiler_td patch-lib_Target_X86_X86MCInstLower_cpp
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:01:34 ports/devel/llvm/files Update of /cvs/ports/devel/llvm/files In directory cvs.openbsd.org:/tmp/cvs-serv96584/files Log Message: Directory /cvs/ports/devel/llvm/files added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 10:00:05 Log message: import devel/llvm/16; Status: Vendor Tag: robert Release Tags: robert_20230903 N ports/devel/llvm/16/Makefile N ports/devel/llvm/16/distinfo N ports/devel/llvm/16/patches/patch-clang_docs_CommandGuide_clang_rst N ports/devel/llvm/16/patches/patch-clang_include_clang_AST_FormatString_h N ports/devel/llvm/16/patches/patch-clang_include_clang_Basic_CodeGenOptions_def N ports/devel/llvm/16/patches/patch-clang_include_clang_Basic_DiagnosticSemaKinds_td N ports/devel/llvm/16/patches/patch-clang_include_clang_Driver_Options_td N ports/devel/llvm/16/patches/patch-clang_include_clang_Sema_Sema_h N ports/devel/llvm/16/patches/patch-clang_lib_AST_FormatString_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Basic_Targets_Mips_h N ports/devel/llvm/16/patches/patch-clang_lib_Basic_Targets_X86_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Basic_Targets_X86_h N ports/devel/llvm/16/patches/patch-clang_lib_CodeGen_CGCall_cpp N ports/devel/llvm/16/patches/patch-clang_lib_CodeGen_CodeGenModule_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Driver_Driver_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Driver_ToolChains_Arch_RISCV_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Driver_ToolChains_Arch_X86_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Driver_ToolChains_Clang_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Driver_ToolChains_OpenBSD_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Frontend_CompilerInvocation_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Sema_SemaChecking_cpp N ports/devel/llvm/16/patches/patch-clang_lib_Sema_SemaDeclAttr_cpp N ports/devel/llvm/16/patches/patch-compiler-rt_lib_builtins_ppc_atomic_lock_free_c N ports/devel/llvm/16/patches/patch-compiler-rt_lib_interception_interception_h N ports/devel/llvm/16/patches/patch-compiler-rt_lib_interception_interception_linux_h N ports/devel/llvm/16/patches/patch-compiler-rt_lib_sanitizer_common_sanitizer_linux_cpp N ports/devel/llvm/16/patches/patch-compiler-rt_lib_sanitizer_common_sanitizer_linux_h N ports/devel/llvm/16/patches/patch-compiler-rt_lib_sanitizer_common_sanitizer_platform_h N ports/devel/llvm/16/patches/patch-compiler-rt_lib_ubsan_ubsan_platform_h N ports/devel/llvm/16/patches/patch-libcxx_include_stdio_h N ports/devel/llvm/16/patches/patch-libunwind_src_AddressSpace_hpp N ports/devel/llvm/16/patches/patch-libunwind_src_EHHeaderParser_hpp N ports/devel/llvm/16/patches/patch-libunwind_src_UnwindCursor_hpp N ports/devel/llvm/16/patches/patch-lld_ELF_Arch_AArch64_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_Arch_PPC64_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_Arch_X86_64_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_Config_h N ports/devel/llvm/16/patches/patch-lld_ELF_Driver_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_DriverUtils_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_InputFiles_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_InputFiles_h N ports/devel/llvm/16/patches/patch-lld_ELF_LinkerScript_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_Relocations_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_ScriptParser_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_SymbolTable_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_Symbols_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_Symbols_h N ports/devel/llvm/16/patches/patch-lld_ELF_Writer_cpp N ports/devel/llvm/16/patches/patch-lld_ELF_Writer_h N ports/devel/llvm/16/patches/patch-lld_docs_ld_lld_1 N ports/devel/llvm/16/patches/patch-lld_tools_lld_lld_cpp N ports/devel/llvm/16/patches/patch-lldb_include_lldb_Host_openbsd_HostInfoOpenBSD_h N ports/devel/llvm/16/patches/patch-lldb_include_lldb_Utility_ArchSpec_h N ports/devel/llvm/16/patches/patch-lldb_source_Core_FormatEntity_cpp N ports/devel/llvm/16/patches/patch-lldb_source_Host_common_SocketAddress_cpp N ports/devel/llvm/16/patches/patch-lldb_source_Host_openbsd_Host_cpp N ports/devel/llvm/16/patches/patch-lldb_source_Host_openbsd_HostInfoOpenBSD_cpp N ports/devel/llvm/16/patches/patch-lldb_source_Host_posix_DomainSocket_cpp N ports/devel/llvm/16/patches/patch-lldb_source_Host_posix_PipePosix_cpp N ports/devel/llvm/16/patches/patch-lldb_source_Initialization_CMakeLists_txt N ports/devel/llvm/16/patches/patch-lldb_source_Initialization_SystemInitializerCommon_cpp N ports/devel/llvm/16/patches/patch-lldb_source_Plugins_Process_CMakeLists_txt N ports/devel/llvm/16/patches/patch-lldb_source_Plugins_DynamicLoader_POSIX-DYLD_DYLDRendezvous_cpp N ports/devel/llvm/16/patches/patch-lldb_source_Plugins_DynamicLoader_POSIX-DYLD_DynamicLoaderPOSIXDYLD_cpp N
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2023/09/03 09:59:29 Log message: import devel/llvm/13 based on our current devel/llvm port Status: Vendor Tag: robert Release Tags: robert_20230903 N ports/devel/llvm/13/Makefile N ports/devel/llvm/13/distinfo N ports/devel/llvm/13/patches/patch-llvm_docs_CommandGuide_llvm-ranlib_rst N ports/devel/llvm/13/patches/patch-llvm_include_llvm_BinaryFormat_ELF_h N ports/devel/llvm/13/patches/patch-llvm_include_llvm_CodeGen_AsmPrinter_h N ports/devel/llvm/13/patches/patch-llvm_include_llvm_CodeGen_MachineFrameInfo_h N ports/devel/llvm/13/patches/patch-llvm_include_llvm_CodeGen_Passes_h N ports/devel/llvm/13/patches/patch-llvm_include_llvm_CodeGen_ReturnProtectorLowering_h N ports/devel/llvm/13/patches/patch-llvm_include_llvm_CodeGen_TargetFrameLowering_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_PowerPC_PPCFrameLowering_h N ports/devel/llvm/13/patches/patch-llvm_include_llvm_InitializePasses_h N ports/devel/llvm/13/patches/patch-llvm_lib_CodeGen_CMakeLists_txt N ports/devel/llvm/13/patches/patch-llvm_lib_CodeGen_ReturnProtectorPass_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_CodeGen_TargetPassConfig_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_MC_MCAsmInfoELF_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_MC_MCELFStreamer_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_X86_X86_h N ports/devel/llvm/13/patches/patch-llvm_lib_CodeGen_AsmPrinter_AsmPrinter_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_CodeGen_PrologEpilogInserter_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_CodeGen_ReturnProtectorLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_AArch64FrameLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_AArch64FrameLowering_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_AArch64ISelLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_AArch64InstrInfo_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_AArch64InstrInfo_td N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_AArch64ReturnProtectorLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_CMakeLists_txt N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_AArch64ReturnProtectorLowering_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_AArch64Subtarget_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_AArch64_CMakeLists_txt N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MCTargetDesc_MipsABIInfo_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MipsAsmPrinter_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MipsFrameLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MipsFrameLowering_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MipsISelLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_AsmParser_MipsAsmParser_cpp N ports/devel/llvm/13/patches/patch-lld_ELF_Arch_PPC64_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MipsInstrInfo_td N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MipsReturnProtectorLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MipsReturnProtectorLowering_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_MipsTargetMachine_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Mips_Mips_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_PowerPC_CMakeLists_txt N ports/devel/llvm/13/patches/patch-llvm_lib_Target_PowerPC_PPCAsmPrinter_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_PowerPC_PPCFrameLowering_cpp N ports/devel/llvm/13/patches/patch-lld_ELF_Arch_X86_64_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_PowerPC_PPCReturnProtectorLowering_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_PowerPC_PPCTargetMachine_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_RISCV_RISCVISelLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Sparc_SparcISelLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Sparc_SparcInstr64Bit_td N ports/devel/llvm/13/patches/patch-llvm_lib_Target_Sparc_SparcInstrInfo_td N ports/devel/llvm/13/patches/patch-llvm_lib_Target_X86_CMakeLists_txt N ports/devel/llvm/13/patches/patch-llvm_lib_Target_PowerPC_PPCInstrInfo_td N ports/devel/llvm/13/patches/patch-llvm_lib_Target_X86_X86_td N ports/devel/llvm/13/patches/patch-llvm_lib_Target_X86_X86FrameLowering_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_X86_X86FrameLowering_h N ports/devel/llvm/13/patches/patch-llvm_lib_Target_X86_X86IndirectThunks_cpp N ports/devel/llvm/13/patches/patch-llvm_lib_Target_X86_X86InstrCompiler_td
Re: UPDATE: qwt-6.2.0
Rafael Sadowski wrote (2023-08-31 07:00 IST):
> Simple update qwt-6.2.0. Tested on amd64. OK?
How to test it?
It breaks gnuradio:
/usr/ports/pobj/gnuradio-3.8.2.0/gnuradio-3.8.2.0/gr-qtgui/lib/../include/gnuradio/qtgui/DisplayPlot.h:44:10:
fatal error: 'qwt_compat.h' file not found
I'm trying qgis and bacula next.
Best regards,
Stefan
> Cheers Rafael
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/qwt/Makefile,v
> retrieving revision 1.34
> diff -u -p -u -p -r1.34 Makefile
> --- Makefile 31 Mar 2022 12:52:13 - 1.34
> +++ Makefile 31 Aug 2023 06:00:26 -
> @@ -1,10 +1,9 @@
> COMMENT= Qt widgets for technical applications
>
> -VERSION =6.1.6
> +VERSION =6.2.0
> DISTNAME = qwt-${VERSION}
> -REVISION = 1
>
> -SHARED_LIBS =qwt${QTLIBSUFFIX} 7.1
> +SHARED_LIBS =qwt${QTLIBSUFFIX} 8.0
>
> CATEGORIES = x11
>
> @@ -28,9 +27,8 @@ MODQMAKE_INSTALL_ROOT =
> NO_TEST =Yes
> USE_GMAKE = Yes
>
> -BUILD_DEPENDS = x11/qt5/qtsvg
> -LIB_DEPENDS =x11/qt5/qttools,-main
> -RUN_DEPENDS =x11/qt5/qtsvg
> +LIB_DEPENDS =x11/qt5/qttools,-main \
> + x11/qt5/qtsvg
>
> QTVER = qt5
> SUBST_VARS = WRKINST QTVER QTLIBSUFFIX
> @@ -38,7 +36,6 @@ SUBST_VARS =WRKINST QTVER QTLIBSUFFIX
> pre-configure:
> ${SUBST_CMD} ${WRKSRC}/{qwtconfig.pri,qwt.prf} \
> ${WRKSRC}/designer/designer.pro \
> - ${WRKSRC}/textengines/textengines.pri \
> ${WRKSRC}/src/src.pro
> post-configure:
> # ensure CXXFLAGS/-std=c++11 is passed to all clang++
> Index: distinfo
> ===
> RCS file: /cvs/ports/x11/qwt/distinfo,v
> retrieving revision 1.6
> diff -u -p -u -p -r1.6 distinfo
> --- distinfo 19 Jan 2021 06:20:27 - 1.6
> +++ distinfo 31 Aug 2023 06:00:26 -
> @@ -1,2 +1,2 @@
> -SHA256 (qwt-6.1.6.tar.bz2) = mUYNMcEV7kEXsBddiF9HwsWQ14QgbwmBXcBY++Xt4fY=
> -SIZE (qwt-6.1.6.tar.bz2) = 4306402
> +SHA256 (qwt-6.2.0.tar.bz2) = kZT2UTlV0P1zAPZxWBdQZEYBl6urGpL6EnpnpLC3FTA=
> +SIZE (qwt-6.2.0.tar.bz2) = 4815773
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/x11/qwt/pkg/PLIST,v
> retrieving revision 1.7
> diff -u -p -u -p -r1.7 PLIST
> --- pkg/PLIST 11 Mar 2022 20:17:15 - 1.7
> +++ pkg/PLIST 31 Aug 2023 06:00:26 -
> @@ -4,6 +4,160 @@
> @pkgpath x11/qwt,-main
> @pkgpath x11/qwt,-common
> @pkgpath x11/qwt,-main,qt5
> +include/QwtAbstractLegend
> +include/QwtAbstractScale
> +include/QwtAbstractScaleDraw
> +include/QwtAbstractSlider
> +include/QwtAlphaColorMap
> +include/QwtAnalogClock
> +include/QwtArrowButton
> +include/QwtAxis
> +include/QwtAxisId
> +include/QwtBezier
> +include/QwtCPointerData
> +include/QwtClipper
> +include/QwtColorMap
> +include/QwtColumnRect
> +include/QwtColumnSymbol
> +include/QwtCompass
> +include/QwtCompassMagnetNeedle
> +include/QwtCompassRose
> +include/QwtCompassScaleDraw
> +include/QwtCompassWindArrow
> +include/QwtCounter
> +include/QwtCurveFitter
> +include/QwtDate
> +include/QwtDateScaleDraw
> +include/QwtDateScaleEngine
> +include/QwtDial
> +include/QwtDialNeedle
> +include/QwtDialSimpleNeedle
> +include/QwtDynGridLayout
> +include/QwtEventPattern
> +include/QwtGlobal
> +include/QwtGraphic
> +include/QwtHueColorMap
> +include/QwtInterval
> +include/QwtIntervalSample
> +include/QwtIntervalSeriesData
> +include/QwtIntervalSymbol
> +include/QwtKnob
> +include/QwtLegend
> +include/QwtLegendData
> +include/QwtLegendLabel
> +include/QwtLinearColorMap
> +include/QwtLinearScaleEngine
> +include/QwtLogScaleEngine
> +include/QwtLogTransform
> +include/QwtMagnifier
> +include/QwtMath
> +include/QwtMatrixRasterData
> +include/QwtNullPaintDevice
> +include/QwtNullTransform
> +include/QwtOHLCSample
> +include/QwtPainter
> +include/QwtPainterCommand
> +include/QwtPanner
> +include/QwtPicker
> +include/QwtPickerClickPointMachine
> +include/QwtPickerClickRectMachine
> +include/QwtPickerDragLineMachine
> +include/QwtPickerDragPointMachine
> +include/QwtPickerDragRectMachine
> +include/QwtPickerMachine
> +include/QwtPickerPolygonMachine
> +include/QwtPickerTrackerMachine
> +include/QwtPixelMatrix
> +include/QwtPlainTextEngine
> +include/QwtPlot
> +include/QwtPlotAbstractBarChart
> +include/QwtPlotAbstractCanvas
> +include/QwtPlotBarChart
> +include/QwtPlotCanvas
> +include/QwtPlotCurve
> +include/QwtPlotDict
> +include/QwtPlotDirectPainter
> +include/QwtPlotGLCanvas
> +include/QwtPlotGraphicItem
> +include/QwtPlotGrid
> +include/QwtPlotHistogram
> +include/QwtPlotIntervalCurve
> +include/QwtPlotItem
> +include/QwtPlotLayout
> +include/QwtPlotLegendItem
> +include/QwtPlotMagnifier
> +include/QwtPlotMarker
> +include/QwtPlotMultiBarChart
> +include/QwtPlotOpenGLCanvas
> +include/QwtPlotPanner
> +include/QwtPlotPicker
> +include/QwtPlotRasterItem
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/09/03 09:25:55 Modified files: net/liboping/patches: patch-src_oping_c Log message: liboping: mention similar patch from upstream issue
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2023/09/03 09:20:16 Modified files: net/liboping : Makefile Added files: net/liboping/patches: patch-src_oping_c Log message: libocurses: neuter -Werror and fix format string warnings discussed with jca
Re: UPDATE: x11/fvwm3 to 1.0.7
Marc Espie wrote (2023-09-01 22:08 IST):
> On Thu, Aug 31, 2023 at 11:20:17PM +0200, Ingo Schwarze wrote:
> > Hi Stefan,
> >
> > Stefan Hagen wrote on Wed, Aug 30, 2023 at 09:41:20AM +0200:
> >
> > > There's no good way to handle a conflict that's introduced with an
> > > update. So what we would do is to move the manpages into the install
> > > directory. (thanks to espie@ for the suggestion)
> >
> > Actually, i regard that as bad advice, espie@ shouldn't say such things.
>
> I don't know. The ability of install versioned manpages for the same
> software doesn't seem to be a bad idea to me.
>
> And /etc/man.conf does feature new default paths, so why not ?
>
> If adding new directories isn't the right level, maybe new sections ?
> or explicit versionned stuff.
>
> Yeah, we've installed several versions of tcl for a long time.
>
> Oh, and man has a "-a" option to display ALL manual pages.
>
> We have currently ZERO mechanism to desambiguate anything outside of
> sections...
>
> if you say, man foo, it will give you the first foo, not even hinting
> there might be a second food behind it.
>
> Yeah, we can rename stuff so that man doesn't get confused, but why
> does man get confused in the first place ?
I think Espies suggestion is more discoverable because the user gets a
message on install he might see.
Ingos suggestion is technically "more correct". However, I asked 6 devs
and only one knew what -a/w does. So I don't think this is used.
From a user perspective, I think it would be nice if we cold make the
manpage display a tiny bit dynamic and show the output of man -w at the
bottom.
Example
MANPAGE VERSIONS:
fvwm3-FvwmButtons(1), FvwmButtons(1)
This would bring discoverability to Ingos solution. And we could freely
rename manpages, because our man(1) is clever enough to find them
anyway. (compared to linux man, which can't do this)
Another idea would be to print something to stderr when more than one
manpage for the search term is available. Either before the pager is
started or after the pager is closed.
I don't like what some linuxes do: SuSE for example shows the user a
list and asks which one to display. This is annoying.
---
I'm sending another diff with Ingos suggestion. I'm happy with this as
well. Both is inconvenient in a way, but at least the man pages are
there.
OK?
- Stefan
Index: x11/fvwm3/Makefile
===
RCS file: /cvs/ports/x11/fvwm3/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- x11/fvwm3/Makefile 24 Jan 2023 18:05:35 - 1.8
+++ x11/fvwm3/Makefile 1 Sep 2023 15:51:43 -
@@ -1,6 +1,6 @@
COMMENT= multiple virtual desktop window manager
-VERSION= 1.0.6a
+VERSION= 1.0.7
DISTNAME= fvwm3-${VERSION}
CATEGORIES= x11
@@ -20,13 +20,14 @@ WANTLIB += readline rsvg-2 event_core ev
MASTER_SITES= https://github.com/fvwmorg/fvwm3/releases/download/${VERSION}/
+BUILD_DEPENDS+=textproc/asciidoctor
+
LIB_DEPENDS+= graphics/png \
x11/gnome/librsvg \
devel/libevent2
SUBST_VARS=VERSION
-SEPARATE_BUILD=Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --enable-mandoc \
@@ -39,7 +40,14 @@ CONFIGURE_ENV+= CPPFLAGS="${CPPFLAGS} -
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+USE_GMAKE =yes
+
post-install:
+ cd ${WRKINST}/${TRUEPREFIX}/man/man1 && for m in Fvwm*.1; \
+ do mv {,fvwm3-}$$m; done
+ cd ${WRKINST}/${TRUEPREFIX}/man/man1/ && \
+ mv fvwm3-FvwmCommand{,3}.1 && \
+ ln -s fvwm3-FvwmCommand3.1 FvwmCommand3.1
mv ${WRKINST}/${TRUEPREFIX}/bin/FvwmCommand{,3}
mv ${WRKINST}/${TRUEPREFIX}/share/FvwmScript-* \
${WRKINST}/${TRUEPREFIX}/share/fvwm3/
Index: x11/fvwm3/distinfo
===
RCS file: /cvs/ports/x11/fvwm3/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- x11/fvwm3/distinfo 22 Jan 2023 12:11:26 - 1.3
+++ x11/fvwm3/distinfo 1 Sep 2023 15:51:43 -
@@ -1,2 +1,2 @@
-SHA256 (fvwm3-1.0.6a.tar.gz) = RmWmYTPgcLeRkXsHlMxt9rdUZ56+kTBxhCfbZHm7W2g=
-SIZE (fvwm3-1.0.6a.tar.gz) = 4538100
+SHA256 (fvwm3-1.0.7.tar.gz) = OqzXz+/2DbG82cdzMtxXX+dxHS0wbwR5UlN43G2z0x4=
+SIZE (fvwm3-1.0.7.tar.gz) = 4512128
Index: x11/fvwm3/patches/patch-configure
===
RCS file: /cvs/ports/x11/fvwm3/patches/patch-configure,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-configure
--- x11/fvwm3/patches/patch-configure 13 Oct 2022 16:00:45 - 1.3
+++ x11/fvwm3/patches/patch-configure 1 Sep 2023 15:51:43 -
@@ -1,7 +1,7 @@
Index: configure
--- configure.orig
+++ configure
-@@ -11779,7 +11779,7 @@ then :
+@@ -11726,7 +11726,7 @@ then :
else $as_nop
with_intl=maybe
Index:
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2023/09/03 09:09:03 Modified files: security/lynis : Makefile distinfo Log message: Update for Lynis to 3.0.9 https://github.com/CISOfy/lynis/releases/tag/3.0.9 OK sdk@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2023/09/03 09:07:45 Modified files: sysutils/stripe-cli: Makefile distinfo modules.inc sysutils/stripe-cli/pkg: DESCR Log message: Update for Stripe-cli to 1.17.2 https://github.com/stripe/stripe-cli/releases/tag/v1.17.2 OK sdk@
