Re: devel/py-twisted: missed test dependency
Le Thu, Sep 19, 2024 at 02:31:40PM +0100, Stuart Henderson a écrit : > On 2024/09/19 09:21, K R wrote: > > Hi ports@, > > > > On Mon, Jun 10, 2024 at 12:07 PM Kirill A. Korinsky > > wrote: > > > > > > ports@, > > > > > > I've noticed that devel/py-twisted had missed test dependencies. > > > > Speaking of Twisted, the current version (24.7.0) fixes two CVEs: > > > > CVE-2024-41810 > > CVE-2024-41671 > > > > The version available on 7.5 is py3-twisted-22.10.0. Any chance to > > have an updated version for the 7.6 release? > > No, not for 7.6. If it was a simple update with just security fixes then > maybe we could still get it in, but in the versions between 22.10.0 and > now there are a lot of deprecations and removals and there are too > many other ports depending on this to check to see whether they need > adjusting. > > Update diff below if someone wants to help testing for post-release > (py-incremental must be updated too). Fwiw, devel/py-buildot still runs fine with that twisted/incremental version. thanks for the update ! Landry
[new] x11/gnome/railway, a train travel lookup application
hi, here's a quick port for https://mobile.schmidhuberj.de/railway which is a gtk4 application querying various train operator APIs for routes/itineraries, without having to bear the often ad-loaded websites of the operators. https://gitlab.com/schmiddi-on-mobile/railway-backend#profiles lists the supported operators so far, mostly in .de/.at/europe, but some city transport operators are support (BART for bay area for example) portswise, it's a gnome/rust/meson port, but the rust crates are properly vendored so it's easy to build. Even if the binary is diebahn ive named the port 'railway' per the upstream project name. maybe a symlink to bin/railway is in order, until upstreams does the rename in the build goo.. Landry railway-2.7.0.tgz Description: application/tar-gz
[new] mappyfile 1.0.2
hi, here's a new port i had lying in mystuff for some years, i use it occasionally - this is https://pypi.org/project/mappyfile/, a parser/validator for mapserver mapfiles. tests require an unported glob2, other than that it runs fine. lark_cython (https://pypi.org/project/lark-cython/) is an optional dependency for performance, i might port it too someday. feedback and oks welcome Landry mappyfile-1.0.2.tgz Description: application/tar-gz
[new] xfce4-timer-plugin 1.7.2
Hi, new port for https://docs.xfce.org/panel-plugins/xfce4-timer-plugin/start, havent actually tested it yet but it's been requested by an user. feedback and oks welcome. Landry timer-1.7.2.tgz Description: application/tar-gz
[update] upower 1.90.5
hi,
small untested update, it now LDEPs on polkit because there's a new
feature allowing interaction with the 'battery charging start and end
limit', and thus there's 'org.freedesktop.UPower.enable-charging-limit'
which needs auth.
i havent looked at all at the code from
https://gitlab.freedesktop.org/upower/upower/-/merge_requests/208 but i
guess its only implemented for linux - but with some code maybe it could
be hooked up to hw.battery.chargestart/stop sysctls ?
i've also noticed that upower doesnt properly support multiple
batteries, i might work on that someday.
Landry
? patch-src_up-device-battery_c
? patch-src_up-device_c
? upower-0.99.11-libupower-glib.so.2.1
? upower-0.99.13-libupower-glib.so.2.1
? upower-0.99.7-libupower-glib.so.2.1
? upower-0.99.9-libupower-glib.so.2.1
? upower-1.90.wip.diff
? upower-1.90.wip2.diff
? upower-1.90.wip3.diff
Index: Makefile
===
RCS file: /cvs/ports/sysutils/upower/Makefile,v
diff -u -r1.73 Makefile
--- Makefile13 Apr 2024 09:25:38 - 1.73
+++ Makefile10 Sep 2024 11:37:41 -
@@ -2,7 +2,7 @@
COMMENT = userland power management interface
-V =v1.90.4
+V =v1.90.5
DISTNAME = upower-${V}
PKGNAME = upower-${V:S/v//}
@@ -18,7 +18,7 @@
PERMIT_PACKAGE=Yes
# uses unveil()
-WANTLIB += c gio-2.0 glib-2.0 gobject-2.0 m
+WANTLIB += c gio-2.0 glib-2.0 gobject-2.0 m polkit-gobject-1
MODULES = devel/meson
CONFIGURE_ARGS =-Dintrospection=enabled \
@@ -32,7 +32,8 @@
# gtk-doc is disabled because otherwise xsltproc fetches from net
CONFIGURE_ARGS +=-Dgtk-doc=false
-LIB_DEPENDS = devel/glib2
+LIB_DEPENDS = devel/glib2 \
+ sysutils/polkit
BUILD_DEPENDS =devel/gettext,-tools \
devel/gobject-introspection \
textproc/docbook-xsl \
Index: distinfo
===
RCS file: /cvs/ports/sysutils/upower/distinfo,v
diff -u -r1.25 distinfo
--- distinfo13 Apr 2024 09:25:38 - 1.25
+++ distinfo10 Sep 2024 11:37:41 -
@@ -1,2 +1,2 @@
-SHA256 (upower-v1.90.4.tar.gz) = zRlN0ni9jQWLRyjv0dCpHN8Bc3jwJbVYvrb2CoavR4E=
-SIZE (upower-v1.90.4.tar.gz) = 181952
+SHA256 (upower-v1.90.5.tar.gz) = kmlWGDJa7wnyyUGSxxRE5VUUypgZV3sSgFn28DhH2UQ=
+SIZE (upower-v1.90.5.tar.gz) = 190801
Index: pkg/PLIST
===
RCS file: /cvs/ports/sysutils/upower/pkg/PLIST,v
diff -u -r1.18 PLIST
--- pkg/PLIST 13 Apr 2024 09:25:38 - 1.18
+++ pkg/PLIST 10 Sep 2024 11:37:41 -
@@ -34,4 +34,7 @@
share/locale/it/LC_MESSAGES/upower.mo
share/locale/pl/LC_MESSAGES/upower.mo
share/locale/sv/LC_MESSAGES/upower.mo
+share/polkit-1/
+share/polkit-1/actions/
+share/polkit-1/actions/org.freedesktop.upower.policy
@sample /var/db/upower/
Re: [new] reaction, a fail2ban alternative
Le Tue, Sep 10, 2024 at 09:09:22AM +0200, Theo Buehler a écrit :
> On Tue, Sep 10, 2024 at 08:22:25AM +0200, Landry Breuil wrote:
> > hi,
> >
> > here's a port for https://reaction.ppom.me/, which is a lightweight
> > fail2ban-like, currently written in go (but uses few modules and builds
> > quickly) and pending a rewrite in rust (per
> > https://framagit.org/ppom/reaction/-/issues/103)
> >
> > the configuration can be in jsonnet or yaml format (cf
> > https://blog.ppom.me/en-reaction/), i've included under files/ an
> > authlog.jsonnet sample that upstream provides to add ssh bots to a
> > blocked_ssh table, one only needs to append two lines to pf.conf to
> > block those (a MESSAGE files advises so).
>
> If I understand correctly, this needs to run as root since the authlog
> script issues pfctl commands.
yeah, that's the idea.. even if not great :)
> I'd replace the 'cp -r' in the Makefile with ${INSTALL_DATA}. Other than
> that this looks ok (haven't tested more than packaging on amd64).
thanks ! will see if there's more testing coming, and do more real-life
tests.
[new] reaction, a fail2ban alternative
hi, here's a port for https://reaction.ppom.me/, which is a lightweight fail2ban-like, currently written in go (but uses few modules and builds quickly) and pending a rewrite in rust (per https://framagit.org/ppom/reaction/-/issues/103) the configuration can be in jsonnet or yaml format (cf https://blog.ppom.me/en-reaction/), i've included under files/ an authlog.jsonnet sample that upstream provides to add ssh bots to a blocked_ssh table, one only needs to append two lines to pf.conf to block those (a MESSAGE files advises so). feedback welcome! Landry reaction-1.4.1.tgz Description: application/tar-gz
Re: firefox can't save file do ~/Downloads
Le Sun, Sep 01, 2024 at 06:55:54AM -0400, Jon Fineman a écrit : > When I try and print to pdf/save file to ~/Downloads I get the > following message: > > The folder contents could not be displayed > You do not have access to the specified folder. > > Not sure when it stopped working (recently though, last few weeks). It > had been working. I can see the ~/Downloads directory and > contents. Just can't write to it. > > Mozilla Firefox 129.0.2 > 7.6 GENERIC.MP#299 amd64 > > I don't believe I changed my unveil files. > > (/etc/firefox)$: grep Downloads * > unveil.content:~/Downloads r > unveil.main:~/Downloads rwc > (/etc/firefox)$: > > Any thoughts on what might have changed? hi and sorry for not replying earlier, was offline. this was probably caused by https://github.com/openbsd/src/commit/4d0caa417ef788ae46f25708d7c20334cfb8c596 and should be fixed in a snapshot containing https://github.com/openbsd/src/commit/863eace7cb72308d10e170ee98f15d95f55235d0 Landry
Re: Should implicit {RUN,BUILD,LIB}_DEPENDS be listed?
Le Fri, Aug 30, 2024 at 01:29:53PM +0200, Johannes Thyssen Tishman a écrit :
> Given the following scenario:
>
> Port A dependencies: X, Y, Z
> Port B dependencies: A, X, Y, Z
>
> Should port B explicitly list the X, Y and Z dependencies in
> {RUN,BUILD,LIB}_DEPENDS, even if they are pulled by port A already?
probably not the reply you want, but 'it depends'.
if that's 'classic' dependencies that port A is unlikely to lose, then
its no need to list them. But say it's a python port where dependencies
come and go, it might be a good idea to list them in B, in case A loses
the dep on something B uses..
for things that are for @tag (gtk4,-guic, desktop-file-utils)
annotations its expected to list them, because the port installation
*uses* them.
for LIB_DEPENDS, keep it to the bare minimum until
port-lib-depends-check stops complaining, you don't see devel/glib2
in all gtkX ports.
for BUILD/RUN depends; generally you list the ones upstream specifies.
"Implicit" ones from dependencies .. that depends.
it would have helped a lot if you said which port/language you were
referring to :p
[update] wayfire 0.9.0 (& wcm/wf-shell/wf-config)
-method-v1.hpp
include/wayfire/plugins/ipc/
include/wayfire/plugins/ipc/ipc-activator.hpp
include/wayfire/plugins/ipc/ipc-helpers.hpp
@@ -91,6 +94,8 @@
include/wayfire/txn/transaction.hpp
include/wayfire/unstable/
include/wayfire/unstable/translation-node.hpp
+include/wayfire/unstable/wlr-subsurface-controller.hpp
+include/wayfire/unstable/wlr-surface-controller.hpp
include/wayfire/unstable/wlr-surface-node.hpp
include/wayfire/unstable/wlr-text-input-v3-popup.hpp
include/wayfire/unstable/wlr-view-events.hpp
@@ -142,6 +147,7 @@
@so lib/wayfire/libresize.so
@so lib/wayfire/libscale-title-filter.so
@so lib/wayfire/libscale.so
+@so lib/wayfire/libsession-lock.so
@so lib/wayfire/libshortcuts-inhibit.so
@so lib/wayfire/libsimple-tile.so
@so lib/wayfire/libstipc.so
@@ -155,6 +161,7 @@
@so lib/wayfire/libwrot.so
@so lib/wayfire/libwsets.so
@so lib/wayfire/libxdg-activation.so
+@so lib/wayfire/libxkb-bindings.so
@so lib/wayfire/libzoom.so
@man man/man1/wayfire.1
share/examples/wayfire/
@@ -191,6 +198,7 @@
share/wayfire/metadata/resize.xml
share/wayfire/metadata/scale-title-filter.xml
share/wayfire/metadata/scale.xml
+share/wayfire/metadata/session-lock.xml
share/wayfire/metadata/shortcuts-inhibit.xml
share/wayfire/metadata/simple-tile.xml
share/wayfire/metadata/switcher.xml
Index: wcm/Makefile
===
RCS file: /cvs/ports/wayland/wcm/Makefile,v
diff -u -r1.1.1.1 Makefile
--- wcm/Makefile21 Dec 2023 16:19:21 - 1.1.1.1
+++ wcm/Makefile26 Aug 2024 13:20:02 -
@@ -1,9 +1,8 @@
COMMENT = wayfire graphical configuration manager
-V =0.8.0
+V =0.9.0
DISTNAME = wcm-${V}
-SHARED_LIBS += wf-wcm 0.0 # 0.0
CATEGORIES = wayland
MAINTAINER = Landry Breuil
@@ -16,7 +15,7 @@
MODULES = devel/meson
BUILD_DEPENDS =wayland/wayland-protocols\
- wayland/wayfire \
+ wayland/wayfire>=0.9.0 \
wayland/wf-shell \
LIB_DEPENDS = wayland/wayland \
Index: wcm/distinfo
===
RCS file: /cvs/ports/wayland/wcm/distinfo,v
diff -u -r1.1.1.1 distinfo
--- wcm/distinfo21 Dec 2023 16:19:21 - 1.1.1.1
+++ wcm/distinfo26 Aug 2024 13:20:02 -
@@ -1,2 +1,2 @@
-SHA256 (wcm-0.8.0.tar.xz) = Ya7zzqt/XBaWZGLELZi9BYDUWzRqhtAp3z5iW5vBO7o=
-SIZE (wcm-0.8.0.tar.xz) = 430960
+SHA256 (wcm-0.9.0.tar.xz) = jIYFzLcg+yTljxbC4nJ80HtnVL1EHJo/DnFVSLTnxK4=
+SIZE (wcm-0.9.0.tar.xz) = 434076
Index: wcm/patches/patch-src_wcm_cpp
===
RCS file: /cvs/ports/wayland/wcm/patches/patch-src_wcm_cpp,v
diff -u -r1.1.1.1 patch-src_wcm_cpp
--- wcm/patches/patch-src_wcm_cpp 21 Dec 2023 16:19:21 - 1.1.1.1
+++ wcm/patches/patch-src_wcm_cpp 26 Aug 2024 13:20:02 -
@@ -1,15 +1,15 @@
Index: src/wcm.cpp
--- src/wcm.cpp.orig
+++ src/wcm.cpp
-@@ -6,7 +6,6 @@
- #include
+@@ -7,7 +7,6 @@
#include
#include
+ #include
-#include
#define OUTPUT_CONFIG_PROGRAM "wdisplays"
-@@ -1507,15 +1506,6 @@ void WCM::open_page(Plugin *plugin)
+@@ -1604,15 +1603,6 @@ void WCM::open_page(Plugin *plugin)
current_plugin = plugin;
}
@@ -25,7 +25,7 @@
void WCM::load_config_files()
{
const char *wf_config_file_override = getenv("WAYFIRE_CONFIG_FILE");
-@@ -1523,7 +1513,7 @@ void WCM::load_config_files()
+@@ -1620,7 +1610,7 @@ void WCM::load_config_files()
if (wf_config_file.empty())
{
@@ -34,7 +34,7 @@
}
std::vector wayfire_xmldirs;
-@@ -1546,8 +1536,7 @@ void WCM::load_config_files()
+@@ -1643,8 +1633,7 @@ void WCM::load_config_files()
if (wf_shell_config_file.empty())
{
Index: wcm/patches/patch-src_wcm_hpp
===
RCS file: wcm/patches/patch-src_wcm_hpp
diff -N wcm/patches/patch-src_wcm_hpp
--- wcm/patches/patch-src_wcm_hpp 21 Dec 2023 16:19:21 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-https://github.com/WayfireWM/wcm/commit/aade4224e23e2c204e9e6a9d5f53437490b0cda8
-
-Index: src/wcm.hpp
src/wcm.hpp.orig
-+++ src/wcm.hpp
-@@ -27,6 +27,7 @@
- #pragma once
-
- #include
-+#include
- #include
- #include
- #include
Index: wcm/pkg/PLIST
===
RCS file: /cvs/ports/wayland/wcm/pkg/PLIST,v
diff -u -r1.1.1.1 PLIST
--- wcm/pkg/PLIST 21 Dec 2023 16:19:21 - 1.1.1.1
+++ wcm/pkg/PLIST 26 Aug 2024 13:20:02 -
@@ -47,6 +47,7 @@
share/wayfire/icons/plugin-lxqt-shell.svg
share/wayfire/icons/plugin-mag.svg
share/wayfire/icons/plugin-move.svg
+share/wayfire/icons/plugin-obs.svg
share/wayfire/icons/plugin-oswitch.svg
share/wayfire/icons/plugin-panel.svg
share/wayfire/icons/plugin-place.svg
Index: wf-config/Makefile
==
Re: net/synapse: fix tests
Le Sun, Aug 25, 2024 at 10:01:00AM +0200, Landry Breuil a écrit :
> Le Sun, Aug 25, 2024 at 09:36:26AM +0200, Landry Breuil a écrit :
> > Le Sun, Aug 25, 2024 at 03:30:56AM -0400, A Tammy a écrit :
> > >
> > > On 8/25/24 3:07 AM, Landry Breuil wrote:
> > > > Le Thu, Aug 22, 2024 at 10:04:45AM +0200, Landry Breuil a écrit :
> > > >> Le Thu, Aug 22, 2024 at 09:40:23AM +0200, Landry Breuil a écrit :
> > > >>> Le Wed, Aug 21, 2024 at 06:11:32PM +0200, Kirill A. Korinsky a écrit :
> > > >>>> On Wed, 21 Aug 2024 17:16:11 +0200,
> > > >>>> Landry Breuil wrote:
> > > >>>>> Le Wed, Aug 21, 2024 at 05:00:21PM +0200, Landry Breuil a écrit :
> > > >>>>>> Le Wed, Aug 21, 2024 at 03:49:45PM +0200, Kirill A. Korinsky a
> > > >>>>>> écrit :
> > > >>>>>>> ports@,
> > > >>>>>>>
> > > >>>>>>> Here a ping from another diff from my
> > > >>>>>> can you explain the dance about dropping/copying tests in pre-test
> > > >>>>>> ?
> > > >>>>>> why was that needed ? isn't doing MODPY_PYTEST_ARGS = --forked
> > > >>>>>> enough ?
> > > >>>>> now that i've tested, this fails with a rather strange error
> > > >>>>> (strange as
> > > >>>>> in "i dont understand why moving tests/ around helps") on all test
> > > >>>>> files:
> > > >>>>>
> > > >>>> and I confirm that this is the problem I am overlooking by moving
> > > >>>> tests.
> > > >> it feels we're getting close.. but not yet.
> > > > this version with a symlink for the rust lib works, and it's probably
> > > > what im
> > > > going to commit. fixing the tests requiring a throwaway synapse test
> > > > instance
> > > > is left for future work.
> > > >
> > > > Index: Makefile
> > > > ===
> > > > RCS file: /cvs/ports/net/synapse/Makefile,v
> > > > diff -u -r1.82 Makefile
> > > > --- Makefile31 Jul 2024 16:01:52 - 1.82
> > > > +++ Makefile25 Aug 2024 07:04:41 -
> > > > @@ -72,10 +72,20 @@
> > > > TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH} \
> > > > devel/py-mock${MODPY_FLAVOR} \
> > > > devel/py-parameterized${MODPY_FLAVOR} \
> > > > + devel/py-test-forked${MODPY_FLAVOR} \
> > > > www/py-jwt${MODPY_FLAVOR}
> > > >
> > > > do-configure:
> > > > @${MODCARGO_configure}
> > > > +
> > > > +MODPY_PYTEST_ARGS =--forked
> > > > +
> > > > +# some tests fail, but they need a previously running synapse process,
> > > > not just a database
> > > > +# E synapse.storage.prepare_database.UpgradeDatabaseException:
> > > > Uninitialised database:
> > > > +# run the main synapse process to prepare the database schema before
> > > > starting worker processes.
> > > > +# make sure that the rust library is found
> > > > +pre-test:
> > > > + ln -sf
> > > > ${WRKSRC}/build/lib.openbsd-${OSREV}-${ARCH}-cpython-${MODPY_MAJORMINOR}/synapse/synapse_rust.abi3.so
> > > > ${WRKSRC}/synapse/
> > > >
> > > > # to generate rust modules.inc:
> > > > # make modcargo-gen-crates and modcargo-gen-crates-licenses
> > >
> > >
> > > I encountered almost exactly the same kind of bug for devel/py-uvloop.
> > > The solution was to move or delete the original sources folder, like so
> > > -
> > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/py-uvloop/Makefile?rev=1.2&content-type=text/x-cvsweb-markup
> > >
> > > pre-test:
> > > cd ${WRKSRC} && test -d uvloop && mv uvloop uvloop-bk || test -d
> > > uvloop-bk
> > >
> > > This was because python tries to find the package to import in the local
> > > folder before it tries to find it in the PYTHONPATH environment vars
> > > locations.
> > >
> > > Because the python tests run after the fake target has been completed,
> > > the
Re: net/synapse: fix tests
Le Sun, Aug 25, 2024 at 09:36:26AM +0200, Landry Breuil a écrit :
> Le Sun, Aug 25, 2024 at 03:30:56AM -0400, A Tammy a écrit :
> >
> > On 8/25/24 3:07 AM, Landry Breuil wrote:
> > > Le Thu, Aug 22, 2024 at 10:04:45AM +0200, Landry Breuil a écrit :
> > >> Le Thu, Aug 22, 2024 at 09:40:23AM +0200, Landry Breuil a écrit :
> > >>> Le Wed, Aug 21, 2024 at 06:11:32PM +0200, Kirill A. Korinsky a écrit :
> > >>>> On Wed, 21 Aug 2024 17:16:11 +0200,
> > >>>> Landry Breuil wrote:
> > >>>>> Le Wed, Aug 21, 2024 at 05:00:21PM +0200, Landry Breuil a écrit :
> > >>>>>> Le Wed, Aug 21, 2024 at 03:49:45PM +0200, Kirill A. Korinsky a écrit
> > >>>>>> :
> > >>>>>>> ports@,
> > >>>>>>>
> > >>>>>>> Here a ping from another diff from my
> > >>>>>> can you explain the dance about dropping/copying tests in pre-test ?
> > >>>>>> why was that needed ? isn't doing MODPY_PYTEST_ARGS = --forked
> > >>>>>> enough ?
> > >>>>> now that i've tested, this fails with a rather strange error (strange
> > >>>>> as
> > >>>>> in "i dont understand why moving tests/ around helps") on all test
> > >>>>> files:
> > >>>>>
> > >>>> and I confirm that this is the problem I am overlooking by moving
> > >>>> tests.
> > >> it feels we're getting close.. but not yet.
> > > this version with a symlink for the rust lib works, and it's probably
> > > what im
> > > going to commit. fixing the tests requiring a throwaway synapse test
> > > instance
> > > is left for future work.
> > >
> > > Index: Makefile
> > > ===
> > > RCS file: /cvs/ports/net/synapse/Makefile,v
> > > diff -u -r1.82 Makefile
> > > --- Makefile31 Jul 2024 16:01:52 - 1.82
> > > +++ Makefile25 Aug 2024 07:04:41 -
> > > @@ -72,10 +72,20 @@
> > > TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH} \
> > > devel/py-mock${MODPY_FLAVOR} \
> > > devel/py-parameterized${MODPY_FLAVOR} \
> > > + devel/py-test-forked${MODPY_FLAVOR} \
> > > www/py-jwt${MODPY_FLAVOR}
> > >
> > > do-configure:
> > > @${MODCARGO_configure}
> > > +
> > > +MODPY_PYTEST_ARGS =--forked
> > > +
> > > +# some tests fail, but they need a previously running synapse process,
> > > not just a database
> > > +# E synapse.storage.prepare_database.UpgradeDatabaseException:
> > > Uninitialised database:
> > > +# run the main synapse process to prepare the database schema before
> > > starting worker processes.
> > > +# make sure that the rust library is found
> > > +pre-test:
> > > + ln -sf
> > > ${WRKSRC}/build/lib.openbsd-${OSREV}-${ARCH}-cpython-${MODPY_MAJORMINOR}/synapse/synapse_rust.abi3.so
> > > ${WRKSRC}/synapse/
> > >
> > > # to generate rust modules.inc:
> > > # make modcargo-gen-crates and modcargo-gen-crates-licenses
> >
> >
> > I encountered almost exactly the same kind of bug for devel/py-uvloop.
> > The solution was to move or delete the original sources folder, like so
> > -
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/py-uvloop/Makefile?rev=1.2&content-type=text/x-cvsweb-markup
> >
> > pre-test:
> > cd ${WRKSRC} && test -d uvloop && mv uvloop uvloop-bk || test -d
> > uvloop-bk
> >
> > This was because python tries to find the package to import in the local
> > folder before it tries to find it in the PYTHONPATH environment vars
> > locations.
> >
> > Because the python tests run after the fake target has been completed,
> > the move should be fine and shouldn't affect the PLIST generation.
>
> yeah, i also figured that out after finding how nix runs the tests in
> their synapse package, they rm -Rf synapse before starting tests.
>
> interestingly, i also realized that upstream doesn't run tests via
> pytest, but via twisted.trial, which might work around the "needs a
> running instance of synapse first" issue.
>
> currently trying with:
>
> # this symlink makes sure that the rust library is found, since by default
> th
Re: net/synapse: fix tests
Le Sun, Aug 25, 2024 at 03:30:56AM -0400, A Tammy a écrit :
>
> On 8/25/24 3:07 AM, Landry Breuil wrote:
> > Le Thu, Aug 22, 2024 at 10:04:45AM +0200, Landry Breuil a écrit :
> >> Le Thu, Aug 22, 2024 at 09:40:23AM +0200, Landry Breuil a écrit :
> >>> Le Wed, Aug 21, 2024 at 06:11:32PM +0200, Kirill A. Korinsky a écrit :
> >>>> On Wed, 21 Aug 2024 17:16:11 +0200,
> >>>> Landry Breuil wrote:
> >>>>> Le Wed, Aug 21, 2024 at 05:00:21PM +0200, Landry Breuil a écrit :
> >>>>>> Le Wed, Aug 21, 2024 at 03:49:45PM +0200, Kirill A. Korinsky a écrit :
> >>>>>>> ports@,
> >>>>>>>
> >>>>>>> Here a ping from another diff from my
> >>>>>> can you explain the dance about dropping/copying tests in pre-test ?
> >>>>>> why was that needed ? isn't doing MODPY_PYTEST_ARGS = --forked enough ?
> >>>>> now that i've tested, this fails with a rather strange error (strange as
> >>>>> in "i dont understand why moving tests/ around helps") on all test
> >>>>> files:
> >>>>>
> >>>> and I confirm that this is the problem I am overlooking by moving tests.
> >> it feels we're getting close.. but not yet.
> > this version with a symlink for the rust lib works, and it's probably what
> > im
> > going to commit. fixing the tests requiring a throwaway synapse test
> > instance
> > is left for future work.
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/net/synapse/Makefile,v
> > diff -u -r1.82 Makefile
> > --- Makefile31 Jul 2024 16:01:52 - 1.82
> > +++ Makefile25 Aug 2024 07:04:41 -
> > @@ -72,10 +72,20 @@
> > TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH} \
> > devel/py-mock${MODPY_FLAVOR} \
> > devel/py-parameterized${MODPY_FLAVOR} \
> > + devel/py-test-forked${MODPY_FLAVOR} \
> > www/py-jwt${MODPY_FLAVOR}
> >
> > do-configure:
> > @${MODCARGO_configure}
> > +
> > +MODPY_PYTEST_ARGS =--forked
> > +
> > +# some tests fail, but they need a previously running synapse process, not
> > just a database
> > +# E synapse.storage.prepare_database.UpgradeDatabaseException:
> > Uninitialised database:
> > +# run the main synapse process to prepare the database schema before
> > starting worker processes.
> > +# make sure that the rust library is found
> > +pre-test:
> > + ln -sf
> > ${WRKSRC}/build/lib.openbsd-${OSREV}-${ARCH}-cpython-${MODPY_MAJORMINOR}/synapse/synapse_rust.abi3.so
> > ${WRKSRC}/synapse/
> >
> > # to generate rust modules.inc:
> > # make modcargo-gen-crates and modcargo-gen-crates-licenses
>
>
> I encountered almost exactly the same kind of bug for devel/py-uvloop.
> The solution was to move or delete the original sources folder, like so
> -
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/py-uvloop/Makefile?rev=1.2&content-type=text/x-cvsweb-markup
>
> pre-test:
> cd ${WRKSRC} && test -d uvloop && mv uvloop uvloop-bk || test -d
> uvloop-bk
>
> This was because python tries to find the package to import in the local
> folder before it tries to find it in the PYTHONPATH environment vars
> locations.
>
> Because the python tests run after the fake target has been completed,
> the move should be fine and shouldn't affect the PLIST generation.
yeah, i also figured that out after finding how nix runs the tests in
their synapse package, they rm -Rf synapse before starting tests.
interestingly, i also realized that upstream doesn't run tests via
pytest, but via twisted.trial, which might work around the "needs a
running instance of synapse first" issue.
currently trying with:
# this symlink makes sure that the rust library is found, since by default the
source is used to run the tests
pre-test:
ln -sf
${WRKSRC}/build/lib.openbsd-${OSREV}-${ARCH}-cpython-${MODPY_MAJORMINOR}/synapse/synapse_rust.abi3.so
${WRKSRC}/synapse/
do-test:
cd ${MODPY_TEST_DIR} && ${SETENV} ${ALL_TEST_ENV} ${MODPY_BIN} -m
twisted.trial tests
this produces a more verbose output with all tests names printed, but maybe
more tests succeed.
Re: net/synapse: fix tests
Le Thu, Aug 22, 2024 at 10:04:45AM +0200, Landry Breuil a écrit :
> Le Thu, Aug 22, 2024 at 09:40:23AM +0200, Landry Breuil a écrit :
> > Le Wed, Aug 21, 2024 at 06:11:32PM +0200, Kirill A. Korinsky a écrit :
> > > On Wed, 21 Aug 2024 17:16:11 +0200,
> > > Landry Breuil wrote:
> > > >
> > > > Le Wed, Aug 21, 2024 at 05:00:21PM +0200, Landry Breuil a écrit :
> > > > > Le Wed, Aug 21, 2024 at 03:49:45PM +0200, Kirill A. Korinsky a écrit :
> > > > > > ports@,
> > > > > >
> > > > > > Here a ping from another diff from my
> > > > >
> > > > > can you explain the dance about dropping/copying tests in pre-test ?
> > > > > why was that needed ? isn't doing MODPY_PYTEST_ARGS = --forked enough
> > > > > ?
> > > >
> > > > now that i've tested, this fails with a rather strange error (strange as
> > > > in "i dont understand why moving tests/ around helps") on all test
> > > > files:
> > > >
> > >
> > > and I confirm that this is the problem I am overlooking by moving tests.
>
> it feels we're getting close.. but not yet.
this version with a symlink for the rust lib works, and it's probably what im
going to commit. fixing the tests requiring a throwaway synapse test instance
is left for future work.
Index: Makefile
===
RCS file: /cvs/ports/net/synapse/Makefile,v
diff -u -r1.82 Makefile
--- Makefile31 Jul 2024 16:01:52 - 1.82
+++ Makefile25 Aug 2024 07:04:41 -
@@ -72,10 +72,20 @@
TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH} \
devel/py-mock${MODPY_FLAVOR} \
devel/py-parameterized${MODPY_FLAVOR} \
+ devel/py-test-forked${MODPY_FLAVOR} \
www/py-jwt${MODPY_FLAVOR}
do-configure:
@${MODCARGO_configure}
+
+MODPY_PYTEST_ARGS =--forked
+
+# some tests fail, but they need a previously running synapse process, not
just a database
+# E synapse.storage.prepare_database.UpgradeDatabaseException: Uninitialised
database:
+# run the main synapse process to prepare the database schema before starting
worker processes.
+# make sure that the rust library is found
+pre-test:
+ ln -sf
${WRKSRC}/build/lib.openbsd-${OSREV}-${ARCH}-cpython-${MODPY_MAJORMINOR}/synapse/synapse_rust.abi3.so
${WRKSRC}/synapse/
# to generate rust modules.inc:
# make modcargo-gen-crates and modcargo-gen-crates-licenses
Landry
Re: net/synapse: fix tests
Le Thu, Aug 22, 2024 at 09:40:23AM +0200, Landry Breuil a écrit :
> Le Wed, Aug 21, 2024 at 06:11:32PM +0200, Kirill A. Korinsky a écrit :
> > On Wed, 21 Aug 2024 17:16:11 +0200,
> > Landry Breuil wrote:
> > >
> > > Le Wed, Aug 21, 2024 at 05:00:21PM +0200, Landry Breuil a écrit :
> > > > Le Wed, Aug 21, 2024 at 03:49:45PM +0200, Kirill A. Korinsky a écrit :
> > > > > ports@,
> > > > >
> > > > > Here a ping from another diff from my
> > > >
> > > > can you explain the dance about dropping/copying tests in pre-test ?
> > > > why was that needed ? isn't doing MODPY_PYTEST_ARGS = --forked enough ?
> > >
> > > now that i've tested, this fails with a rather strange error (strange as
> > > in "i dont understand why moving tests/ around helps") on all test files:
> > >
> >
> > and I confirm that this is the problem I am overlooking by moving tests.
> >
> > I had discovered this problem at archivers/py-zstandard which I made for
> > mitmproxy, but it was more than two months ago I and can not easily recall
> > why it's help and how I discovered this hack.
> >
> > Probably it doesn't have the correct PYTHONPATH and I can't figure out how
> > to set it correctly in case of cffi on this port.
>
> i've tried playing with MODPY_TEST_LIBDIR to give it the right path to
> the synapse_rust.abi3.so file, but everything i've tried so far fails.
here's something that 'works' standalone:
[09:58]
c64:/usr/obj/ports/synapse-1.112.0/synapse-1.112.0/build/lib.openbsd-7.6-amd64-cpython-311/
$python3
>>> import sys
>>> sys.path.append('/usr/obj/ports/synapse-1.112.0/synapse-1.112.0/')
>>> import tests.api.test_auth
>>>
but integrated in the portstree this way:
MODPY_PYTEST_ARGS =--forked ${WRKSRC}/tests
MODPY_TEST_DIR =
${WRKSRC}/build/lib.openbsd-${OSREV}-${ARCH}-cpython-${MODPY_MAJORMINOR}/
MODPY_TEST_LIBDIR = ${WRKSRC}
trying with make -n do-test, this is the command run (env stripped for
readability) and taht fails:
cd
/usr/obj/ports/synapse-1.112.0/synapse-1.112.0/build/lib.openbsd-7.6-amd64-cpython-311/
&& env PYTHONPATH=/usr/obj/ports/synapse-1.112.0/synapse-1.112.0:src:lib
/usr/local/bin/python3.11 -m pytest --forked
/usr/obj/ports/synapse-1.112.0/synapse-1.112.0/tests
it feels we're getting close.. but not yet.
Landry
Re: net/synapse: fix tests
Le Wed, Aug 21, 2024 at 06:11:32PM +0200, Kirill A. Korinsky a écrit : > On Wed, 21 Aug 2024 17:16:11 +0200, > Landry Breuil wrote: > > > > Le Wed, Aug 21, 2024 at 05:00:21PM +0200, Landry Breuil a écrit : > > > Le Wed, Aug 21, 2024 at 03:49:45PM +0200, Kirill A. Korinsky a écrit : > > > > ports@, > > > > > > > > Here a ping from another diff from my > > > > > > can you explain the dance about dropping/copying tests in pre-test ? > > > why was that needed ? isn't doing MODPY_PYTEST_ARGS = --forked enough ? > > > > now that i've tested, this fails with a rather strange error (strange as > > in "i dont understand why moving tests/ around helps") on all test files: > > > > and I confirm that this is the problem I am overlooking by moving tests. > > I had discovered this problem at archivers/py-zstandard which I made for > mitmproxy, but it was more than two months ago I and can not easily recall > why it's help and how I discovered this hack. > > Probably it doesn't have the correct PYTHONPATH and I can't figure out how > to set it correctly in case of cffi on this port. i've tried playing with MODPY_TEST_LIBDIR to give it the right path to the synapse_rust.abi3.so file, but everything i've tried so far fails. one can easily reproduce the issue: - go to WRKSRC - LD_DEBUG=1 python3 >>> import tests.api.test_auth dlopen: loading: /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so objname [/usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so], dynp 0xdbef10a3840, objtype 4 lbase dbef107b000, obase dbef107b000 flags /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so = 0x0 head /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so obj /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so has /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so as head linking /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so as dlopen()ed head [/usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so] examining: '/usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so' loading: libsodium.so.10.2 required by /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so objname [/usr/local/lib/libsodium.so.10.2], dynp 0xdbe3db09858, objtype 3 lbase dbe3da87000, obase dbe3da87000 flags /usr/local/lib/libsodium.so.10.2 = 0x1 obj /usr/local/lib/libsodium.so.10.2 has /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so as head linking dep /usr/local/lib/libsodium.so.10.2 as child of /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so examining: '/usr/local/lib/libsodium.so.10.2' loading: libpthread.so.27.1 required by /usr/local/lib/libsodium.so.10.2 linking dep /usr/lib/libpthread.so.27.1 as child of /usr/local/lib/libsodium.so.10.2 tail /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so protect RELRO [0xdbe3db08090,0xdbe3db0a000) in /usr/local/lib/libsodium.so.10.2 doing ctors obj 0xdbe9f5ba000 @0xdbe3db05ac0: [/usr/local/lib/libsodium.so.10.2] protect RELRO [0xdbef10a10f0,0xdbef10a5000) in /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so doing ctors obj 0xdbe9f5b9000 @0xdbef109e4e0: [/usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so] dlopen: /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so: done (success). dlsym: PyInit__sodium in /usr/local/lib/python3.11/site-packages/nacl/_sodium.abi3.so: 0xdbef108b060 Traceback (most recent call last): File "", line 1, in File "/usr/obj/ports/synapse-1.112.0/synapse-1.112.0/tests/api/test_auth.py", line 28, in from synapse.api.auth.internal import InternalAuth File "/usr/obj/ports/synapse-1.112.0/synapse-1.112.0/synapse/__init__.py", line 32, in from synapse.util.rust import check_rust_lib_up_to_date File
Re: net/synapse: fix tests
Le Wed, Aug 21, 2024 at 05:00:21PM +0200, Landry Breuil a écrit :
> Le Wed, Aug 21, 2024 at 03:49:45PM +0200, Kirill A. Korinsky a écrit :
> > ports@,
> >
> > Here a ping from another diff from my
>
> can you explain the dance about dropping/copying tests in pre-test ?
> why was that needed ? isn't doing MODPY_PYTEST_ARGS = --forked enough ?
now that i've tested, this fails with a rather strange error (strange as
in "i dont understand why moving tests/ around helps") on all test files:
collected 0 items / 273 errors
ERRORS
___ ERROR collecting tests/api/test_auth.py
ImportError while importing test module
'/usr/obj/ports/synapse-1.112.0/synapse-1.112.0/tests/api/test_auth.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/local/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
tests/__init__.py:24: in
from synapse.util.patch_inline_callbacks import do_patch
synapse/__init__.py:32: in
from synapse.util.rust import check_rust_lib_up_to_date
synapse/util/rust.py:27: in
from synapse.synapse_rust import get_rust_file_digest
E ImportError: cannot import name 'get_rust_file_digest' from
'synapse.synapse_rust' (unknown location)
>
> > > On 6/10/24 4:01 PM, Kirill A. Korinsky wrote:
> > > > ports@
> > > >
> > > > I discovered that make test for net/synapse doesn't work, all tests
> > > > fail.
> > > >
> > > > Thus, tests seems to be leaked and it consumes near 8G of RAM before it
> > > > was
> > > > killed due to hit the hard limit on my system.
> > > >
> > > > To avoid that I had added pytest-forked to run each test in dedicated
> > > > process that allows to limit memory consumption to 200-300 mb.
> > > >
> > >
> > > That's OK for me, but if you find a way so that it passes psql tests
> > > too, like Landry@ suggested, that would be nice.
> > >
> >
> > diff --git net/synapse/Makefile net/synapse/Makefile
> > index 5af1b855170..6554cad5b50 100644
> > --- net/synapse/Makefile
> > +++ net/synapse/Makefile
> > @@ -72,11 +72,19 @@ RUN_DEPENDS += www/py-requests${MODPY_FLAVOR}
> > TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH} \
> > devel/py-mock${MODPY_FLAVOR} \
> > devel/py-parameterized${MODPY_FLAVOR} \
> > + devel/py-test-forked${MODPY_FLAVOR} \
> > www/py-jwt${MODPY_FLAVOR}
> >
> > do-configure:
> > @${MODCARGO_configure}
> >
> > +MODPY_PYTEST_ARGS =--forked tests/
> > +MODPY_TEST_DIR = ${WRKDIR}
> > +
> > +pre-test:
> > + @rm -fr ${WRKDIR}/tests
> > + @cp -r ${WRKSRC}/tests ${WRKDIR}/
> > +
> > # to generate rust modules.inc:
> > # make modcargo-gen-crates and modcargo-gen-crates-licenses
> > .include "modules.inc"
> >
> >
> > --
> > wbr, Kirill
>
Re: net/synapse: fix tests
Le Wed, Aug 21, 2024 at 03:49:45PM +0200, Kirill A. Korinsky a écrit :
> ports@,
>
> Here a ping from another diff from my
can you explain the dance about dropping/copying tests in pre-test ?
why was that needed ? isn't doing MODPY_PYTEST_ARGS = --forked enough ?
> > On 6/10/24 4:01 PM, Kirill A. Korinsky wrote:
> > > ports@
> > >
> > > I discovered that make test for net/synapse doesn't work, all tests fail.
> > >
> > > Thus, tests seems to be leaked and it consumes near 8G of RAM before it
> > > was
> > > killed due to hit the hard limit on my system.
> > >
> > > To avoid that I had added pytest-forked to run each test in dedicated
> > > process that allows to limit memory consumption to 200-300 mb.
> > >
> >
> > That's OK for me, but if you find a way so that it passes psql tests
> > too, like Landry@ suggested, that would be nice.
> >
>
> diff --git net/synapse/Makefile net/synapse/Makefile
> index 5af1b855170..6554cad5b50 100644
> --- net/synapse/Makefile
> +++ net/synapse/Makefile
> @@ -72,11 +72,19 @@ RUN_DEPENDS +=www/py-requests${MODPY_FLAVOR}
> TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH} \
> devel/py-mock${MODPY_FLAVOR} \
> devel/py-parameterized${MODPY_FLAVOR} \
> + devel/py-test-forked${MODPY_FLAVOR} \
> www/py-jwt${MODPY_FLAVOR}
>
> do-configure:
> @${MODCARGO_configure}
>
> +MODPY_PYTEST_ARGS = --forked tests/
> +MODPY_TEST_DIR = ${WRKDIR}
> +
> +pre-test:
> + @rm -fr ${WRKDIR}/tests
> + @cp -r ${WRKSRC}/tests ${WRKDIR}/
> +
> # to generate rust modules.inc:
> # make modcargo-gen-crates and modcargo-gen-crates-licenses
> .include "modules.inc"
>
>
> --
> wbr, Kirill
Re: [wip] devel/py-pydantic 2.8.2 devel/py-pydantic-core-2.21.0
Le Mon, Aug 19, 2024 at 05:29:44PM +0200, Renaud Allard a écrit : > > > On 8/19/24 5:12 PM, Stuart Henderson wrote: > > Dirty-equals uses hatchling not setuptools_scm, see pyproject.toml > > > > "method to make python code easier" - pfft. How about this instead? > > "simplify asserts in tests by misusing __eq__"? > > > Indeed, that didn't mean much. this version is ok with me, or i can import it with another ok. as for the last iteration of the rust-based py-pydantic-core, the last submission had a n empty patches/ subdir and PLIST.orig in the tarball, but those can be skipped with cvs import too.
firefox & vaapi [was: Enable VA-API in graphics/ffmpeg]
Le Wed, Aug 14, 2024 at 10:57:46AM +0200, Jan Stary a écrit : > > Can AMD users play https://www.youtube.com/watch?v=LXb3EKWsInQ in > > 2160p60 on FF without blowing the CPU? > > On this AMD machine (dmesg and vainfo below), > firefox-129.0 plays this video eating about 14% of CPU. > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND > 23106 hans 20 362M 414M sleep/0 kqread1:14 14.16% firefox > 77528 hans 20 427M 467M sleep/3 kqread1:32 11.38% firefox > 60891 hans 20 97M 98M idle kqread0:20 3.27% firefox > > That's with "media.ffmpeg.vaapi.enabled true" in about:config; > and about the same with "media.ffmpeg.vaapi.enabled false", > which confuses me. > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND > 77528 hans 20 429M 470M sleep/5 kqread1:44 14.06% firefox > 23106 hans 20 379M 429M sleep/4 kqread1:25 12.94% firefox > 60891 hans 20 97M 98M sleep/3 kqread0:26 4.69% firefox > > Is there a better metric of how much firefox video playing > is helped (or not) by vaapi? How can I even tell FF is using it? whatever knob you frob, firefox is not using vaapi, because vaapi is *not* compatible as-is with the current sandboxing config. there are wip patches in the vaapi branch of my git repo (which is on top of the beta branch), cf https://cgit.rhaalovely.net/mozilla-firefox/?h=vaapi but right now it doesnt work because: - it tries dlopening libs with fixed .so.X version we dont have (easy to fix) - it tries opening the drm device read-write after sandboxing (harder to fix) - the xenocara/mesa gl stack itself also tries to open the drm device rw when creating some gl context at some point so things to explore: - pushing sandbox initialization 'later' once every needed fd is opened/saved somewhere - add the required paths/pledge class for the various syscalls used when decoding (eg during process main loop) if you dont care about sandboxing, ofc you can disable it, but then you're on your own. and that wont work anyway because of the .so.X paths, but ppl like to workaround that by doing symlinks, which is no the correct 'fix' either. check https://bugzilla.mozilla.org/show_bug.cgi?id=1911635 for the details of the various things i've tried so far. to know the status of vaapi at runtime, try with env MOZ_LOG="FFmpegVideo:5,Dmabuf:5,OpenBSDSandbox:5" MOZ_GFX_DEBUG=1 firefox and of course a separate profile. Landry
Re: [update] devel/py-rpds-py 0.20.0
Le Mon, Aug 19, 2024 at 04:04:34PM +0200, Renaud Allard a écrit : > > > On 8/19/24 3:56 PM, Landry Breuil wrote: > > Le Wed, Aug 14, 2024 at 10:54:54AM +0200, Renaud Allard a écrit : > > > > > > > > > On 8/13/24 10:23 PM, Stuart Henderson wrote: > > > > For py-pydantic-core, please get rid of pip as a build dep; see > > > > www/py-adblock for an example. I didn't figure out how to do tests > > > > without but at least let's not drag that mess into build at least. > > > > Ideally do the same for whichever port that bit was copied from too :) > > > > > > > > > > Here is a diff which upgrades devel/py-rpds-py to 0.20.0 and removes the > > > install dep on pip > > > > my understanding of this diff is that now instead of pip, do-install > > uses py-installer, so... devel/py-pip should move to TDEP, and > > devel/py-installer should be added to BDEP, like www/py-adblock does ? > > > > Indeed, this one should be better. my comment was about py-rpds, and this diff is py-inflect, which now shouldnt have py-pydantic as a dep :)
Re: [update] devel/py-rpds-py 0.20.0
Le Wed, Aug 14, 2024 at 10:54:54AM +0200, Renaud Allard a écrit : > > > On 8/13/24 10:23 PM, Stuart Henderson wrote: > > For py-pydantic-core, please get rid of pip as a build dep; see > > www/py-adblock for an example. I didn't figure out how to do tests > > without but at least let's not drag that mess into build at least. > > Ideally do the same for whichever port that bit was copied from too :) > > > > Here is a diff which upgrades devel/py-rpds-py to 0.20.0 and removes the > install dep on pip my understanding of this diff is that now instead of pip, do-install uses py-installer, so... devel/py-pip should move to TDEP, and devel/py-installer should be added to BDEP, like www/py-adblock does ? Landry
Re: [wip] devel/py-pydantic 2.8.2 devel/py-pydantic-core-2.21.0
Le Wed, Aug 14, 2024 at 11:13:43AM +0200, Renaud Allard a écrit : > > > Here is an update to textproc/py-inflect 7.3.1. > make test passes both on textproc/py-inflect and textproc/py-jaraco-text coming back to this, according to upstream changelog, the dependency on pydantic was replaced by typeguard, so your diff should reflect that ? Landry
Re: [update] www/nginx 1.26.2
Le Mon, Aug 19, 2024 at 10:43:59AM +0200, Landry Breuil a écrit :
> hi,
>
> simple update:
> *) Security: processing of a specially crafted mp4 file by the
>ngx_http_mp4_module might cause a worker process crash
>(CVE-2024-7347).
>
> builds fine here
updated diff after stuart's commit
? nginx-1.18.0.diff
? nginx-mjs.diff
Index: Makefile
===
RCS file: /cvs/ports/www/nginx/Makefile,v
diff -u -r1.183 Makefile
--- Makefile19 Aug 2024 08:50:45 - 1.183
+++ Makefile19 Aug 2024 09:08:20 -
@@ -19,11 +19,9 @@
COMMENT-stream=nginx TCP/UDP proxy module
COMMENT-xslt= nginx XSLT filter module
-VERSION= 1.26.1
+VERSION= 1.26.2
DISTNAME= nginx-${VERSION}
CATEGORIES=www
-REVISION-main= 2
-REVISION= 1
PKGNAME-main= ${DISTNAME}
PKGNAME-cache_purge= nginx-cache_purge-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/www/nginx/distinfo,v
diff -u -r1.87 distinfo
--- distinfo19 Aug 2024 08:50:45 - 1.87
+++ distinfo19 Aug 2024 09:08:20 -
@@ -4,7 +4,7 @@
SHA256 (leev-ngx_http_geoip2_module-3.4.tar.gz) =
rXL8IzSNcVozCZSYRTH6ubNgbhYEgyNnN/mkppV9lFI=
SHA256 (nbs-system-naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) =
2+IXdBFFfxy6mO5Gc84xh2mUrQa9zl7MDuZjhO8OQg4=
SHA256 (nginx-1.20.1-chroot.patch) =
SS1TB0j8N4/dn5pUTGT6WvkN3aAUuKz5+R0Nt+MG0gk=
-SHA256 (nginx-1.26.1.tar.gz) = +Rh0aP8usVkmC/1Thnwl/44zRyYjes8ie56HDlPT42s=
+SHA256 (nginx-1.26.2.tar.gz) = Yn/ghiCbuoCihToK3Z2VjX673/oahGeleEyaa08D1zg=
SHA256
(nginx-modules-ngx_http_hmac_secure_link_module-48c4625fbbf51ed5a95bfec23fa444f6c3702e50.tar.gz)
= ZXpA2rODS1enIREzlD1OqWwpWcv3NOUXH4eUOgOAmqg=
SHA256 (nginx-njs-0.8.4.tar.gz) = /hl+JUIEwV6fHfCs83Wt1XvjQWkB7I17hzGdzLSQ+Q0=
SHA256 (openresty-headers-more-nginx-module-v0.34.tar.gz) =
DA0s7SzolbP0XrKyMM2QUIqyp3MpnxU94UpD5EwSCbM=
@@ -16,7 +16,7 @@
SIZE (leev-ngx_http_geoip2_module-3.4.tar.gz) = 8877
SIZE (nbs-system-naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) =
237272
SIZE (nginx-1.20.1-chroot.patch) = 8783
-SIZE (nginx-1.26.1.tar.gz) = 1244738
+SIZE (nginx-1.26.2.tar.gz) = 1244789
SIZE
(nginx-modules-ngx_http_hmac_secure_link_module-48c4625fbbf51ed5a95bfec23fa444f6c3702e50.tar.gz)
= 6159
SIZE (nginx-njs-0.8.4.tar.gz) = 743910
SIZE (openresty-headers-more-nginx-module-v0.34.tar.gz) = 28827
[update] www/nginx 1.26.2
hi,
simple update:
*) Security: processing of a specially crafted mp4 file by the
ngx_http_mp4_module might cause a worker process crash
(CVE-2024-7347).
builds fine here
? nginx-1.18.0.diff
? nginx-mjs.diff
Index: Makefile
===
RCS file: /cvs/ports/www/nginx/Makefile,v
diff -u -r1.182 Makefile
--- Makefile8 Jul 2024 20:42:28 - 1.182
+++ Makefile19 Aug 2024 08:42:29 -
@@ -18,15 +18,9 @@
COMMENT-rtmp= nginx module for RTMP streaming
COMMENT-securelink=nginx HMAC secure link module
-VERSION= 1.26.1
+VERSION= 1.26.2
DISTNAME= nginx-${VERSION}
CATEGORIES=www
-REVISION-geoip2= 0
-REVISION-lua= 0
-REVISION-main= 1
-REVISION-njs= 0
-REVISION-passenger= 0
-REVISION-rtmp= 0
PKGNAME-main= ${DISTNAME}
PKGNAME-image_filter= nginx-image_filter-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/www/nginx/distinfo,v
diff -u -r1.86 distinfo
--- distinfo8 Jul 2024 20:42:28 - 1.86
+++ distinfo19 Aug 2024 08:42:29 -
@@ -3,7 +3,7 @@
SHA256 (leev-ngx_http_geoip2_module-3.4.tar.gz) =
rXL8IzSNcVozCZSYRTH6ubNgbhYEgyNnN/mkppV9lFI=
SHA256 (nbs-system-naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) =
2+IXdBFFfxy6mO5Gc84xh2mUrQa9zl7MDuZjhO8OQg4=
SHA256 (nginx-1.20.1-chroot.patch) =
SS1TB0j8N4/dn5pUTGT6WvkN3aAUuKz5+R0Nt+MG0gk=
-SHA256 (nginx-1.26.1.tar.gz) = +Rh0aP8usVkmC/1Thnwl/44zRyYjes8ie56HDlPT42s=
+SHA256 (nginx-1.26.2.tar.gz) = Yn/ghiCbuoCihToK3Z2VjX673/oahGeleEyaa08D1zg=
SHA256
(nginx-modules-ngx_http_hmac_secure_link_module-48c4625fbbf51ed5a95bfec23fa444f6c3702e50.tar.gz)
= ZXpA2rODS1enIREzlD1OqWwpWcv3NOUXH4eUOgOAmqg=
SHA256 (nginx-njs-0.8.4.tar.gz) = /hl+JUIEwV6fHfCs83Wt1XvjQWkB7I17hzGdzLSQ+Q0=
SHA256 (openresty-headers-more-nginx-module-v0.34.tar.gz) =
DA0s7SzolbP0XrKyMM2QUIqyp3MpnxU94UpD5EwSCbM=
@@ -14,7 +14,7 @@
SIZE (leev-ngx_http_geoip2_module-3.4.tar.gz) = 8877
SIZE (nbs-system-naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) =
237272
SIZE (nginx-1.20.1-chroot.patch) = 8783
-SIZE (nginx-1.26.1.tar.gz) = 1244738
+SIZE (nginx-1.26.2.tar.gz) = 1244789
SIZE
(nginx-modules-ngx_http_hmac_secure_link_module-48c4625fbbf51ed5a95bfec23fa444f6c3702e50.tar.gz)
= 6159
SIZE (nginx-njs-0.8.4.tar.gz) = 743910
SIZE (openresty-headers-more-nginx-module-v0.34.tar.gz) = 28827
Re: lyx 2.4.1 crashes at startup (including patch)
Le Sun, Aug 18, 2024 at 08:03:52PM +0200, Robert Klein a écrit : > Hi, > > on -current LyX crashes at startup with "Abort trap" and writes > "backwards memcpy" into /var/log/messages. > > Exchanging memcpy in src/support/gzstream.cpp helps. (Tested with > manually applying the patches from ports to downloaded source on 7.5 and > newly sysupgraded snapshot.) I successfully started LyX, created a > document, compiled, viewed and saved it. > > My patch to gzstream.cpp below. many thanks for the detailed report and patch, applied!
Re: [wip] devel/py-pydantic 2.8.2 devel/py-pydantic-core-2.21.0
Le Mon, Aug 12, 2024 at 03:19:28PM +0200, Renaud Allard a écrit :
>
>
> On 8/12/24 3:05 PM, Renaud Allard wrote:
> > Hello,
> >
> > Here is a WIP for devel/py-pydantic 2.8.2 devel/py-pydantic-core-2.21.0
> >
> > It will more than likely break geo/pygeoapi unless this patch is
> > applied: https://github.com/geopython/pygeoapi/pull/1353/files
> >
> > But it should "unbreak" net/synapse.
> >
> > It's all untested ATM.
> >
> > Any comments?
> >
> > Best Regards
>
> Sorry, I had forgotten to "CVS rm" the patches.
> -MODPY_PYBUILD = setuptools
> +MODPY_PYBUILD = hatchling
>
> -BUILD_DEPENDS = lang/cython${MODPY_FLAVOR}
> -RUN_DEPENDS =devel/py-typing-extensions${MODPY_FLAVOR}
> +BUILD_DEPENDS = devel/py-hatchling${MODPY_FLAVOR} \
there's no need for hatchling in BDEP if its used in PYBUILD.
i wont make comments on mixed python/rust ports, but with the attached
diff the pygeoapi command doesnt blow upon startup.
you also have to check py-pydantic-compat and py-inflect.
Landry
? patch-pygeoapi_util_py
? files/pygeoapi-config.yml
Index: Makefile
===
RCS file: /cvs/ports/geo/pygeoapi/Makefile,v
diff -u -r1.25 Makefile
--- Makefile29 Jul 2024 06:46:22 - 1.25
+++ Makefile12 Aug 2024 13:56:34 -
@@ -2,6 +2,7 @@
MODPY_EGG_VERSION =0.17.0
DISTNAME = pygeoapi-${MODPY_EGG_VERSION}
+REVISION = 0
CATEGORIES = geo devel
@@ -23,6 +24,7 @@
devel/py-dateutil${MODPY_FLAVOR} \
devel/py-jsonschema${MODPY_FLAVOR} \
devel/py-pydantic${MODPY_FLAVOR} \
+ devel/py-typing-extensions${MODPY_FLAVOR} \
devel/py-tz${MODPY_FLAVOR} \
geo/mapserver,-python \
geo/py-geofilter${MODPY_FLAVOR} \
Index: patches/patch-pygeoapi_models_config_py
===
RCS file: patches/patch-pygeoapi_models_config_py
diff -N patches/patch-pygeoapi_models_config_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-pygeoapi_models_config_py 12 Aug 2024 13:56:34 -
@@ -0,0 +1,28 @@
+https://github.com/geopython/pygeoapi/pull/1353
+
+Index: pygeoapi/models/config.py
+--- pygeoapi/models/config.py.orig
pygeoapi/models/config.py
+@@ -36,7 +36,7 @@ from pydantic import BaseModel, Field
+
+ class APIRules(BaseModel):
+ """ Pydantic model for API design rules that must be adhered to. """
+-api_version: str = Field(regex=r'^\d+\.\d+\..+$',
++api_version: str = Field(pattern=r'^\d+\.\d+\..+$',
+ description="Semantic API version number.")
+ url_prefix: str = Field(
+ "",
+@@ -62,11 +62,11 @@ class APIRules(BaseModel):
+ """ Returns a new APIRules instance for the current API version
+ and configured rules. """
+ obj = {
+-k: v for k, v in rules_config.items() if k in APIRules.__fields__
++k: v for k, v in rules_config.items() if k in
APIRules.model_fields
+ }
+ # Validation will fail if required `api_version` is missing
+ # or if `api_version` is not a semantic version number
+-return APIRules.parse_obj(obj)
++return APIRules.model_validate(obj)
+
+ @property
+ def response_headers(self) -> dict:
Index: patches/patch-pygeoapi_models_cql_py
===
RCS file: patches/patch-pygeoapi_models_cql_py
diff -N patches/patch-pygeoapi_models_cql_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-pygeoapi_models_cql_py12 Aug 2024 13:56:35 -
@@ -0,0 +1,650 @@
+https://github.com/geopython/pygeoapi/pull/1353
+
+Index: pygeoapi/models/cql.py
+--- pygeoapi/models/cql.py.orig
pygeoapi/models/cql.py
+@@ -35,234 +35,235 @@
+ from datetime import date, datetime
+ from typing import Any, List, Literal, Optional, Union
+
+-from pydantic import BaseModel, Field
++from pydantic import RootModel, Field
++from typing_extensions import Literal
+
+
+-class CQLModel(BaseModel):
+-__root__: 'Union[\nComparisonPredicate,\n
SpatialPredicate,\nTemporalPredicate,\nAndExpression\n]'
++class CQLModel(RootModel):
++root: 'Union[\nComparisonPredicate,\nSpatialPredicate,\n
TemporalPredicate,\nAndExpression\n]'
+
+
+-class AndExpression(BaseModel):
++class AndExpression(RootModel):
+ and_: 'List[ComparisonPredicate]' = Field(..., alias='and')
+
+
+-class NotExpression(BaseModel):
++class NotExpression(RootModel):
+ not_: 'List[Any]' = Field(..., alias='not')
+
+
+-class OrExpression(BaseModel):
++class OrExpression(RootModel):
+ or_: 'List[Any]' = Field(..., alias='or')
+
+
+-class PropertyRef(BaseModel):
++class PropertyRef(RootModel):
+ property: 'Optional[str]' = None
+
+
+-cla
[update] mail/meli 0.8.7
hi,
there's been two releases, and it now uses the newer ring (cf
https://git.meli-email.org/meli/meli/issues/391) which might
give it a chance on more archs.. so ive dropped the dependency on
rust-ring port.
cf https://git.meli-email.org/meli/meli/releases/tag/v0.8.7 &
https://git.meli-email.org/meli/meli/releases/tag/v0.8.6
testing welcome.
Landry
? build-0.8.4.log
? build-0.8.5
? patch-meli_Cargo_toml
Index: Makefile
===
RCS file: /cvs/ports/mail/meli/Makefile,v
diff -u -r1.18 Makefile
--- Makefile25 Jul 2024 16:30:43 - 1.18
+++ Makefile5 Aug 2024 11:47:01 -
@@ -2,12 +2,8 @@
GH_ACCOUNT = meli
GH_PROJECT = meli
-GH_TAGNAME = v0.8.5
-REVISION = 0
+GH_TAGNAME = v0.8.7
-# ring-v0.16.20 does not support those archs
-# https://git.meli-email.org/meli/meli/issues/391
-NOT_FOR_ARCHS =powerpc64 riscv64 sparc64
# error[E0308]: mismatched types -->
melib/src/backends/notmuch.rs:82:13
ONLY_FOR_ARCHS = ${LP64_ARCHS}
@@ -21,17 +17,12 @@
MODCARGO_FEATURES += jmap
MODCARGO_INSTALL_TARGET_PATHS =meli
MODCARGO_CRATES_UPDATE += time time-core deranged
-# dep of time crate
-MODCARGO_CRATES += num-conv 0.1.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += powerfmt 0.2.0 # MIT OR Apache-2.0
MODCARGO_CRATES_KEEP += libsqlite3-sys
.include "crates.inc"
CONFIGURE_STYLE = cargo
SEPARATE_BUILD = Yes
-
-BUILD_DEPENDS += security/rust-ring
LIB_DEPENDS = net/curl
Index: crates.inc
===
RCS file: /cvs/ports/mail/meli/crates.inc,v
diff -u -r1.6 crates.inc
--- crates.inc 25 Jul 2024 16:30:43 - 1.6
+++ crates.inc 5 Aug 2024 11:47:01 -
@@ -1,3 +1,5 @@
+MODCARGO_CRATES += num-conv0.1.0 # MIT OR Apache-2.0
+MODCARGO_CRATES += powerfmt0.2.0 # MIT OR Apache-2.0
MODCARGO_CRATES += abnf-core 0.6.0 # MIT OR Apache-2.0
MODCARGO_CRATES += adler 1.0.2 # 0BSD OR MIT OR Apache-2.0
MODCARGO_CRATES += ahash 0.8.5 # MIT OR Apache-2.0
@@ -5,6 +7,8 @@
MODCARGO_CRATES += allocator-api2 0.2.16 # MIT OR Apache-2.0
MODCARGO_CRATES += android-tzdata 0.1.1 # MIT OR Apache-2.0
MODCARGO_CRATES += android_system_properties 0.1.5 # MIT/Apache-2.0
+MODCARGO_CRATES += anstyle 1.0.7 # MIT OR Apache-2.0
+MODCARGO_CRATES += assert_cmd 2.0.13 # MIT OR Apache-2.0
MODCARGO_CRATES += async-channel 1.9.0 # Apache-2.0 OR MIT
MODCARGO_CRATES += async-executor 1.5.1 # Apache-2.0 OR MIT
MODCARGO_CRATES += async-fs1.6.0 # Apache-2.0 OR MIT
@@ -20,12 +24,14 @@
MODCARGO_CRATES += autocfg 1.1.0 # Apache-2.0 OR MIT
MODCARGO_CRATES += base64 0.13.1 # MIT/Apache-2.0
MODCARGO_CRATES += base64 0.21.3 # MIT OR Apache-2.0
+MODCARGO_CRATES += base64 0.22.1 # MIT OR Apache-2.0
MODCARGO_CRATES += base64-compat 1.0.0 # MIT/Apache-2.0
MODCARGO_CRATES += bitflags1.3.2 # MIT/Apache-2.0
MODCARGO_CRATES += bitflags2.4.0 # MIT OR Apache-2.0
MODCARGO_CRATES += block 0.1.6 # MIT
MODCARGO_CRATES += blocking1.3.1 # Apache-2.0 OR MIT
-MODCARGO_CRATES += bufstream 0.1.4 # MIT/Apache-2.0
+MODCARGO_CRATES += bstr1.6.0 # MIT OR Apache-2.0
+MODCARGO_CRATES += bufstream-fresh 0.3.1 # MIT/Apache-2.0
MODCARGO_CRATES += bumpalo 3.13.0 # MIT/Apache-2.0
MODCARGO_CRATES += byteorder 1.4.3 # Unlicense OR MIT
MODCARGO_CRATES += bytes 1.4.0 # MIT
@@ -51,8 +57,10 @@
MODCARGO_CRATES += data-encoding 2.4.0 # MIT
MODCARGO_CRATES += dbus0.9.7 # Apache-2.0/MIT
MODCARGO_CRATES += deranged0.3.9 # MIT OR Apache-2.0
+MODCARGO_CRATES += difflib 0.4.0 # MIT
MODCARGO_CRATES += dirs-next 2.0.0 # MIT OR Apache-2.0
MODCARGO_CRATES += dirs-sys-next 0.1.2 # MIT OR Apache-2.0
+MODCARGO_CRATES += doc-comment 0.3.3 # MIT
MODCARGO_CRATES += either 1.9.0 # MIT OR Apache-2.0
MODCARGO_CRATES += encoding0.2.33 # MIT
MODCARGO_CRATES += encoding-index-japanese 1.20141219.5# CC0-1.0
@@ -72,21 +80,22 @@
MODCARGO_CRATES += fastrand2.0.0 # Apache-2.0 OR MIT
MODCARGO_CRATES += filetime0.2.22 # MIT/Apache-2.0
MODCARGO_CRATES += flate2 1.0.27 # MIT OR Apache-2.0
+MODCARGO_CRATES += float-cmp 0.9.0 # MIT
MODCARGO_CRATES += fnv 1.0.7 # Apache-2.0 / MIT
MODCARGO_CRATES += foreign-types 0.3.2 # MIT/Apache-2.0
MODCARGO_CRATES += foreign-types-shared0.1.1 # MIT/Apache-2.0
MODCARGO_CRATES += form_urlencoded 1.2.0 # MIT OR Apache-2.0
MODCARGO_CRATES += fsevent-sys 4.1.0 # MIT
-MODCARGO_CRATES += futures 0.3.28 # MIT OR Apache-2.0
-MODCARGO_CRATES += futures-channel 0.3.28 # MI
Re: [update] net/synapse 1.112.0
Le Wed, Jul 31, 2024 at 01:32:39PM +0200, Renaud Allard a écrit : > Hello, > > Here is an update to net/synapse 1.112.0 > > It needs a new port "python-multipart", also included in this mail. > I was not too sure about naming it python-multipart, but cannot really be > called py-multipart either and py-python-multipart looked strange. py-multipart would be fine, since the site-packages dir is named multipart...
Re: Enable VA-API in graphics/ffmpeg
Le Sun, Jul 28, 2024 at 09:43:55AM +0200, Landry Breuil a écrit : > Le Fri, Jul 26, 2024 at 08:49:49PM -0400, José Maldonado a écrit : > > El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil > > (lan...@openbsd.org) escribió: > > > > > > > There are numerous issues that will need to be fixed before va-api in > > > > firefox will actually work. Some of them are pledge/unveil related, > > > > others are firefox hardcoding specific library versions for dlopen > > > > without fallback. > > > > > > thanks tb for looking into that :) > > > > > > > With the symlinks below and various additions to pledge and unveil, > > > > I get sound to play in what looks like hardware decoded video. > > > > Unfortunately, the player remains dark... > > > > > > the symlinks shouldnt be needed in all cases, because in the code i can > > > find that wraps ffmpeg and tries to load the libva libs > > > (https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegLibWrapper.cpp#366) > > > and the libgbm libs > > > (https://searchfox.org/mozilla-central/source/third_party/gbm/libgbm/mozgbm.cpp#31), > > > (and maybe others ? havent seen libxaw in the source code) > > > it uses nspr's PR_LoadLibraryWithFlags() which is patched to drop what's > > > after the .so (cf > > > https://github.com/openbsd/ports/blob/master/devel/nspr/patches/patch-nspr_pr_src_linking_prlink_c#L32) > > > > > > > In my case, I am trying Firefox 128 from packages, and ffmpeg with > > VAAPI patches and obtain VAAPI hwaccel with this changes > > thanks, that's a start, because it makes us understand what files are > opened by which process. > > But you do realize this adds lots of capacities to those process types > that arent needed right now, thus shouldnt be added. > > The right process is to figure out _what_ codepaths open those > libs/paths, and try to move those initializations *before* sandboxing, > so that adding those capacities isnt needed. Preloading libs before > sandboxing is a trick that has been done before (cf > https://phabricator.services.mozilla.com/D193353 / > https://bugzilla.mozilla.org/show_bug.cgi?id=1856301) now we need to add > a bit more libs, make sure subsequent dlopens finds the preloaded lib, > and do the same for the drm device fd. Right now wpath is needed because > it tries to open /dev/dri/renderD128 read-write after sandboxing, doing > that before sandboxing is the way to go. > > > On the other hand, there is one additional positive point in creating > > the libgbm and libdrm symlinks (or patch hardcode name for this libs > > in Firefox): enabling general DMAbuf support for Firefox which is > > broken due to the library versioning not matching. > > creating the symlinks is a big no :) fixing hardcoded versions is easy, > and upstreaming that is generally welcome. > > > If I'm not mistaken this leaves us with two things: > > > > 1.- Apply the patches you mentioned to pre-load libva and VAAPI > > support without many changes in unveil/pledge, but I don't think this > > enables full DRM and DMAbuf support for Firefox. > > that's a work in progress. we'll see if we get somewhere. If you want to > help, try the patches in my branch (eg > https://cgit.rhaalovely.net/mozilla-firefox/log/patches?h=vaapi) > and if they dont work, start from that and move the code around... > https://searchfox.org is a great tool to find codepaths/callers/etc. with the latest version of the patchset, i have something that doesnt crash, but fails to properly initialize vaapi: [(null) 51070: Main Thread]: D/Dmabuf DMABufDevice::Configure() [(null) 51070: Main Thread]: D/Dmabuf Loading DMABuf system library libgbm.so ... [(null) 51070: Main Thread]: D/Dmabuf Using DRM device /dev/dri/renderD128 [(null) 51070: Main Thread]: D/Dmabuf DMABuf is enabled drmfd preopened, fd=12 [(null) 51070: Main Thread]: D/OpenBSDSandbox /tmp: unveil(/tmp, rwc) [(null) 51070: Main Thread]: D/OpenBSDSandbox /etc/firefox/pledge.rdd: pledge(stdio rpath tmppath recvfd sendfd unix) [RDD 51070: MediaSupervisor #1]: D/FFmpegVideo FFMPEG: FFmpegVideoDecoder::FFmpegVideoDecoder MIME video/avc Codec ID 27 [RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Initialising VA-API FFmpeg decoder [RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: codec h264 : H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Can't get DRM VA-API display. [RDD 51070: MediaPDecoder #1]: D/FFmpegVideo FFMPEG: Failed to create VA-API device context the gfxvars object isnt initialized yet, so it requires MOZ_DRM_DEVICE=/dev/dri/renderD128 in the env to find the right device. Landry
Re: Enable VA-API in graphics/ffmpeg
Le Fri, Jul 26, 2024 at 08:49:49PM -0400, José Maldonado a écrit : > El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil > (lan...@openbsd.org) escribió: > On the other hand, there is one additional positive point in creating > the libgbm and libdrm symlinks (or patch hardcode name for this libs > in Firefox): enabling general DMAbuf support for Firefox which is > broken due to the library versioning not matching. > > Enabling DMAbuf support can improve WebGL performance in certain > conditions and opens the way for using the full Wayland implementation > of Firefox, for those who want to experiment and develop support for > it. on this specific 'dmabuf' topic: from my understanding of https://docs.kernel.org/driver-api/dma-buf.html, and my previous experience in https://bugzilla.mozilla.org/show_bug.cgi?id=1840272 (which got 'fixed' by adding some ifdefs in https://hg.mozilla.org/integration/autoland/rev/15d494dac453), proper 'dmabuf' support (whatever that is) requires eventfd.h, and some kernel support. I dont think we have such thing in our drm support, and *think* freebsd has some, but i haven't looked much there.
Re: Enable VA-API in graphics/ffmpeg
Le Fri, Jul 26, 2024 at 08:49:49PM -0400, José Maldonado a écrit : > El vie, 26 jul 2024 a la(s) 8:56 a.m., Landry Breuil > (lan...@openbsd.org) escribió: > > > > > There are numerous issues that will need to be fixed before va-api in > > > firefox will actually work. Some of them are pledge/unveil related, > > > others are firefox hardcoding specific library versions for dlopen > > > without fallback. > > > > thanks tb for looking into that :) > > > > > With the symlinks below and various additions to pledge and unveil, > > > I get sound to play in what looks like hardware decoded video. > > > Unfortunately, the player remains dark... > > > > the symlinks shouldnt be needed in all cases, because in the code i can > > find that wraps ffmpeg and tries to load the libva libs > > (https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegLibWrapper.cpp#366) > > and the libgbm libs > > (https://searchfox.org/mozilla-central/source/third_party/gbm/libgbm/mozgbm.cpp#31), > > (and maybe others ? havent seen libxaw in the source code) > > it uses nspr's PR_LoadLibraryWithFlags() which is patched to drop what's > > after the .so (cf > > https://github.com/openbsd/ports/blob/master/devel/nspr/patches/patch-nspr_pr_src_linking_prlink_c#L32) > > > > In my case, I am trying Firefox 128 from packages, and ffmpeg with > VAAPI patches and obtain VAAPI hwaccel with this changes thanks, that's a start, because it makes us understand what files are opened by which process. But you do realize this adds lots of capacities to those process types that arent needed right now, thus shouldnt be added. The right process is to figure out _what_ codepaths open those libs/paths, and try to move those initializations *before* sandboxing, so that adding those capacities isnt needed. Preloading libs before sandboxing is a trick that has been done before (cf https://phabricator.services.mozilla.com/D193353 / https://bugzilla.mozilla.org/show_bug.cgi?id=1856301) now we need to add a bit more libs, make sure subsequent dlopens finds the preloaded lib, and do the same for the drm device fd. Right now wpath is needed because it tries to open /dev/dri/renderD128 read-write after sandboxing, doing that before sandboxing is the way to go. > On the other hand, there is one additional positive point in creating > the libgbm and libdrm symlinks (or patch hardcode name for this libs > in Firefox): enabling general DMAbuf support for Firefox which is > broken due to the library versioning not matching. creating the symlinks is a big no :) fixing hardcoded versions is easy, and upstreaming that is generally welcome. > If I'm not mistaken this leaves us with two things: > > 1.- Apply the patches you mentioned to pre-load libva and VAAPI > support without many changes in unveil/pledge, but I don't think this > enables full DRM and DMAbuf support for Firefox. that's a work in progress. we'll see if we get somewhere. If you want to help, try the patches in my branch (eg https://cgit.rhaalovely.net/mozilla-firefox/log/patches?h=vaapi) and if they dont work, start from that and move the code around... https://searchfox.org is a great tool to find codepaths/callers/etc. > 2.- Apply a patch to change the library lookup to match OpenBSD > versioning or directly make the symlinks and pledge/unveil settings so > that everything works as it is. i think you haven't been long enough in the openbsd community ;) if it's not done 'right', it's not done.
Re: aarch64 bulk build report
Le Fri, Jul 19, 2024 at 10:45:18AM +0200, Landry Breuil a écrit :
> Le Fri, Jul 19, 2024 at 08:49:54AM +0200, Peter Hessler a écrit :
> > On 2024 Jul 18 (Thu) at 21:35:47 -0600 (-0600), phess...@openbsd.org wrote:
> > :critical path missing pkgs:
> > http://build-failures.rhaalovely.net/aarch64/2024-07-16/summary.log
> >
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/mail/mozilla-thunderbird.log
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/firefox-esr.log
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/tor-browser/browser.log
> > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/qt5/qtwebengine.log
> >
> > the above 4 ports fail related to hwcap in the same way:
> >
> > /usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:84:27:
> > error: use of undeclared identifier 'getauxval'
> > uint32_t hwcaps = getauxval(AT_HWCAP);
>
> https://searchfox.org/mozilla-esr115/source/gfx/skia/skia/src/core/SkCpu.cpp#76
> for the surrounding code, i guess it now finds a sys/auxv.h header ?
the below patch goes past this build failure, but libipcclientcerts.so
doesn't link with lld:
rm -f libipcclientcerts.so.10.0
/usr/obj/ports/firefox-esr-115.13.0/bin/cc
-std=gnu99 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong
-Wno-backend-plugin -O2 -pipe -g -fPIC -ffunction-sections -fdata-sections
-fno-math-errno -pthread -pipe -gdwarf-4 -O2 -pipe -g -fomit-frame-pointer
-funwind-tables
-fprofile-use=/usr/obj/ports/firefox-esr-115.13.0/merged.profdata
-Wno-error=backend-plugin -shared -fPIC -Wl,--gc-sections
-Wl,-h,libipcclientcerts.so.10.0 -o libipcclientcerts.so.10.0 stub.o
-flto=thin -Wl,-plugin-opt=-import-instr-limit=10
-Wl,-plugin-opt=-import-hot-multiplier=30 -pthread -Wl,--threads=8
-Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc
-Wl,-Bsymbolic-functions -Wl,--build-id=sha1 -fstack-protector-strong
-Wl,-rpath-link,/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/dist/bin
-Wl,-rpath-link,/usr/local/lib -Wl,-rpath-link,/usr/X11R6/lib
/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/aarch64-unknown-openbsd/release/libipcclientcerts_static.a
-Wl,--version-script,libipcclientcerts.so.10.0.symbols
/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/_virtualenvs/build/bin/python
-m mozbuild.action.check_binary --target libipcclientcerts.so.10.0
BUILDTASK {"argv":
["/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/python/mozbuild/mozbuild/action/check_binary.py",
"--target", "libipcclientcerts.so.10.0"], "start": 12452.418140014,
"end": 12452.543060385, "context": null}
chmod +x libipcclientcerts.so.10.0
../../../../../config/nsinstall -R -m 644 'libipcclientcerts.so.10.0'
'../../../../../dist/bin'
gmake[3]: Leaving directory
'/usr/obj/ports/firefox-esr-115.13.0/build-aarch64/security/manager/ssl/ipcclientcerts/dynamic-library'
ld.lld: error: undefined hidden symbol: elf_aux_info
>>> referenced by SkCpu.cpp:85
>>> (/usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:85)
>>>
>>> lto.tmp:(SkCpu::CacheRuntimeFeatures())
clang-16: error: linker command failed with exit code 1 (use -v to see
invocation) i
i dunno which of the -Wl flags triggers this, but the elf_aux_info symbol is
present as a weak symbol in libc.so.100.2, but i see that it doesnt explicitely
link with -lc - though maybe it shouldnt be required.
$cat patches/patch-gfx_skia_skia_src_core_SkCpu_cpp
Fix build with auxv.h addition
Index: gfx/skia/skia/src/core/SkCpu.cpp
--- gfx/skia/skia/src/core/SkCpu.cpp.orig
+++ gfx/skia/skia/src/core/SkCpu.cpp
@@ -81,7 +81,8 @@
kHWCAP_ASIMDHP = (1<<10);
uint32_t features = 0;
-uint32_t hwcaps = getauxval(AT_HWCAP);
+uint32_t hwcaps = 0;
+elf_aux_info(AT_HWCAP, &hwcaps, sizeof(hwcaps));
if (hwcaps & kHWCAP_CRC32 ) { features |= SkCpu::CRC32; }
if (hwcaps & kHWCAP_ASIMDHP) { features |= SkCpu::ASIMDHP; }
>
> Landry
>
Re: aarch64 bulk build report
Le Fri, Jul 19, 2024 at 08:49:54AM +0200, Peter Hessler a écrit : > On 2024 Jul 18 (Thu) at 21:35:47 -0600 (-0600), phess...@openbsd.org wrote: > :critical path missing pkgs: > http://build-failures.rhaalovely.net/aarch64/2024-07-16/summary.log > > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/mail/mozilla-thunderbird.log > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/firefox-esr.log > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/www/tor-browser/browser.log > :http://build-failures.rhaalovely.net/aarch64/2024-07-16/x11/qt5/qtwebengine.log > > the above 4 ports fail related to hwcap in the same way: > > /usr/obj/ports/firefox-esr-115.13.0/firefox-115.13.0/gfx/skia/skia/src/core/SkCpu.cpp:84:27: > error: use of undeclared identifier 'getauxval' > uint32_t hwcaps = getauxval(AT_HWCAP); https://searchfox.org/mozilla-esr115/source/gfx/skia/skia/src/core/SkCpu.cpp#76 for the surrounding code, i guess it now finds a sys/auxv.h header ? Landry
Re: NEW: kde.port.mk
Le Wed, Jul 17, 2024 at 10:02:17PM +0200, Rafael Sadowski a écrit : > Would like to merge x11/kde-applications/kde-applications.port.mk to use > it in all KDE ports: > > The main reason is to have the versions also in meta/kde: > > MODKDE_GEAR_VERSION ?=24.05.2 > MODKDE_PLASMA_VERSION ?= 6.1.3 > > Full diff that has gone through a whole bulk build. > > Objections? Feedback? I've glanced over it and it makes sense to me
Re: geo/py-geojson: New port
Le Mon, Jul 15, 2024 at 07:52:23AM +, wen heping a écrit : > Hi, ports@: > > Here is a patch to create new port geo/py-geojson, which is the > RUN_D of geo/py-planet. Current py-planet in ports could > not work because of missing geo/py-geojson. are you sure about the conflict with laspy ? the upstream githu repo doesnt seem to have such file.. Landry
Re: [new] devel/libnfc
Le Sun, Jul 14, 2024 at 04:56:29PM +0200, Denis Bodor a écrit : > Hi ports! > > Attached is a port of libNFC > > libNFC is a library which allows userspace tools access to NFC > devices/readers (over serial, USB, PC/SC, etc). > > I decided to make PC/SC support a flavor because this library is usually > used directly with USB devices and very rarely with PC/SC, which induces > an often useless dependency. > > Build and run on amd64 without problems. > > Comments? Ok? looks good, minor nits: - you dont need to set PKGNAME when DISTNAME is set and has the same value - you dont need to add libusb1 to LIB_DEPENDS since libusb-compat depends on it. other than that, ok with me. Landry
[update] thunderbird 128.0 'nebula'
hi,
the next feature version of thunderbird is available, cf
https://www.thunderbird.net/en-US/thunderbird/128.0/whatsnew/
diff against -current attached, packages also available from my pkg repo
at https://packages.rhaalovely.net/ and the port is also at
https://cgit.rhaalovely.net/mozilla-thunderbird/?h=release
i intend to commit that in a not too distant future for it to be shipped
with 7.6.
testing welcome, been using the beta branch for the past months without
issues.
Landry
? beta-riscv64
? build.log
? bumpbeta.sh
? configure-gawk
? patch-toolkit_system_gnome_nsGIOService_cpp
? qless beta-riscv64
? t.patch
? todo
Index: Makefile
===
RCS file: /cvs/ports/mail/mozilla-thunderbird/Makefile,v
diff -u -p -r1.461 Makefile
--- Makefile19 Jun 2024 04:40:37 - 1.461
+++ Makefile12 Jul 2024 06:27:54 -
@@ -1,14 +1,15 @@
-ONLY_FOR_ARCHS = amd64 aarch64
+ONLY_FOR_ARCHS = amd64 aarch64 riscv64
COMMENT = Mozilla e-mail, calendar, rss and usenet client
# Don't forget to bump mail/thunderbird-i18n after updates.
-MOZILLA_VERSION = 115.12.1
+MOZILLA_VERSION = 128.0esr
MOZILLA_BRANCH = release
MOZILLA_PROJECT = thunderbird
MOZILLA_CODENAME = comm/mail
EXTRACT_SUFX = .tar.xz
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+PKGNAME = ${MOZILLA_PROJECT}-${MOZILLA_VERSION:S/esr//}
# XXX badly formed debug in libxul ?
DWZ = :
@@ -19,7 +20,7 @@ SO_VERSION = 38.0
# NOTE: Must bump minor version if any shlib's are removed from the
# components dir to avoid pkg_add -r issues.
-MOZILLA_LIBS = lgpllibs mozavcodec mozavutil mozgtk mozsqlite3 mozwayland xul
+MOZILLA_LIBS = gkcodecs lgpllibs mozavcodec mozavutil mozgtk mozsqlite3
mozwayland xul
CATEGORIES=mail news
@@ -30,7 +31,7 @@ MODULES = www/mozilla lang/python
MODPY_RUNDEP = No
COMPILER = ports-clang
-MODCLANG_ARCHS = amd64 aarch64
+MODCLANG_ARCHS = amd64 aarch64 riscv64
# 63 requires node because why not #1483595
BUILD_DEPENDS += lang/node
@@ -48,7 +49,7 @@ BUILD_DEPENDS += lang/wasi-sdk/compiler-
# mach uses pkg_resources
BUILD_DEPENDS += devel/py-setuptools${MODPY_FLAVOR}
-WRKDIST = ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//}
+WRKDIST =
${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//:C/esr//}
NO_TEST = Yes
@@ -75,13 +76,16 @@ BUILD_DEPENDS +=security/rnp
RUN_DEPENDS += security/rnp>=0.17.0
LIB_DEPENDS += devel/libffi
-WANTLIB += Xrandr Xtst ffi
+WANTLIB += Xrandr ffi
ALL_TARGET = default
-post-patch:
- sed -i 's/"files":{[^}]*}/"files":{}/' \
- ${WRKSRC}/third_party/rust/mp4parse/.cargo-checksum.json
+# not built on riscv64
+COMMENT_FFVPX ?=
+.if ${MACHINE_ARCH} == riscv64
+COMMENT_FFVPX =@comment # needs a trailing space
+.endif
+SUBST_VARS += COMMENT_FFVPX
post-install:
# install prefs
Index: distinfo
===
RCS file: /cvs/ports/mail/mozilla-thunderbird/distinfo,v
diff -u -p -r1.261 distinfo
--- distinfo19 Jun 2024 04:40:37 - 1.261
+++ distinfo12 Jul 2024 06:27:54 -
@@ -1,2 +1,2 @@
-SHA256 (mozilla/thunderbird-115.12.1.source.tar.xz) =
4ZZCdX6jlb4cQ+bybbhaiq2SR5w7tQ4D3xzpa2uvtis=
-SIZE (mozilla/thunderbird-115.12.1.source.tar.xz) = 535032092
+SHA256 (mozilla/thunderbird-128.0esr.source.tar.xz) =
oH6sPP9+D3IisttJdFLHLI5+nJiR8tF09QEFKuH2ldg=
+SIZE (mozilla/thunderbird-128.0esr.source.tar.xz) = 673307208
Index: patches/patch-intl_lwbrk_LineBreaker_cpp
===
RCS file:
/cvs/ports/mail/mozilla-thunderbird/patches/patch-intl_lwbrk_LineBreaker_cpp,v
diff -u -p -r1.1 patch-intl_lwbrk_LineBreaker_cpp
--- patches/patch-intl_lwbrk_LineBreaker_cpp2 Nov 2023 13:26:34 -
1.1
+++ patches/patch-intl_lwbrk_LineBreaker_cpp12 Jul 2024 06:27:54 -
@@ -4,7 +4,7 @@ https://hg.mozilla.org/try/rev/d5f3b0c4f
Index: intl/lwbrk/LineBreaker.cpp
--- intl/lwbrk/LineBreaker.cpp.orig
+++ intl/lwbrk/LineBreaker.cpp
-@@ -434,7 +434,13 @@ static int8_t GetClass(uint32_t u, LineBreakRule aLeve
+@@ -448,7 +448,13 @@ static int8_t GetClass(uint32_t u, LineBreakRule aLeve
/* REGIONAL_INDICATOR = 39, [RI] */ CLASS_CHARACTER,
/* E_BASE = 40, [EB] */ CLASS_BREAKABLE,
/* E_MODIFIER = 41, [EM] */ CLASS_CHARACTER,
Index: patches/patch-media_ffvpx_libavcodec_x86_fft_asm
===
RCS file: patches/patch-media_ffvpx_libavcodec_x86_fft_asm
diff -N patches/patch-media_ffvpx_libavcodec_x86_fft_asm
--- patches/patch-media_ffvpx_libavcodec_x86_fft_asm21 Jul 2023 09:35:55
- 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,42 +0,0 @@
-The x86 assembly FFT implementation uses disp
Re: NEW: databases/futuresql
Le Sun, Jun 30, 2024 at 09:47:06AM +0200, Rafael Sadowski a écrit : > New Qt/KDE dependency futuresql-0.1.1, OK to import? ok
Re: XScreenSaver and bsdauth
Le Mon, Jul 08, 2024 at 11:43:25AM +0200, Manuel Giraud a écrit : > Hi, > > I'm trying to make a patch to XScreenSaver to support bsdauth (hopefully > to have it upstream). you might want to have a look at https://github.com/openbsd/ports/blob/master/x11/xfce4/xfce4-screensaver/files/ask-pass.c & https://github.com/openbsd/ports/commit/3f12fe80e7ea1008e93764cf0418cba3e6f357a0 iirc it comes from what used to be in gnome-screensaver. also https://github.com/openbsd/ports/blob/master/x11/slock/patches/patch-slock_c for slock i have to admit i was pretty sure xscreensaver already supported bsdauth.. hth
Re: UPDATE: spdlog 1.14.1
Le Mon, Jul 08, 2024 at 03:59:20AM -0400, Brad Smith a écrit : > On 2024-07-08 2:46 a.m., Landry Breuil wrote: > > Le Sat, Jul 06, 2024 at 09:39:01PM -0400, Brad Smith a écrit : > > > On Sat, Jul 06, 2024 at 08:34:47PM -0400, Brad Smith wrote: > > > > Here is an update to spdlog 1.14.1. > > > Also disable building an example. > > i have more or less the same diff, what brings not building the examples > > ? also the symbols in the lib didnt change here, so why bumping the > > major ? > > The output of check_sym was questionable and bumps are cheap. right > The example does not serve any purpose, it's just wasting CPU cycles > building and > there is a pending issue getting in the way of newer fmt. ah, thanks for the explanation. much better :)
[update] nheko 0.12/mtxclient 0.10
hi,
here's a wip update for nheko 0.12 which switched upstream to qt6, cf
https://github.com/Nheko-Reborn/nheko/releases/tag/v0.12.0
there's also an update for mtxclient 0.10.0 cf
https://github.com/Nheko-Reborn/mtxclient/releases/tag/v0.10.0
wip packages are available on https://packages.rhaalovely.net/wip/amd64/
using the trick from
https://github.com/Nheko-Reborn/nheko/issues/1187#issuecomment-1255831124
i've been able to connect to a matrix account and verify this new
device.
portswise, it builds a bundled copy of
https://github.com/KDAB/KDSingleApplication for which we could have a
distinct port, opinion welcome on that.
testing welcome!
Landry
Index: Makefile
===
RCS file: /cvs/ports/net/nheko/Makefile,v
diff -u -r1.12 Makefile
--- Makefile20 Apr 2024 09:28:33 - 1.12
+++ Makefile8 Jul 2024 06:47:30 -
@@ -2,23 +2,22 @@
GH_ACCOUNT = Nheko-Reborn
GH_PROJECT = nheko
-GH_TAGNAME = v0.11.3
-REVISION = 1
+GH_TAGNAME = v0.12.0
CATEGORIES=net
# GPLv3
PERMIT_PACKAGE=Yes
-WANTLIB += ${COMPILER_LIBCXX} Qt5Concurrent Qt5Core Qt5DBus Qt5Gui
-WANTLIB += Qt5Multimedia Qt5Network Qt5Qml Qt5QmlModels Qt5Quick
-WANTLIB += Qt5QuickControls2 Qt5QuickWidgets Qt5Svg Qt5Widgets
+WANTLIB += ${COMPILER_LIBCXX} GL Qt6Core Qt6DBus Qt6Gui
+WANTLIB += Qt6Multimedia Qt6Network Qt6Qml Qt6QmlModels Qt6Quick
+WANTLIB += Qt6QuickControls2 Qt6OpenGL Qt6Svg Qt6Widgets
WANTLIB += c cmark coeurl crypto fmt glib-2.0 gobject-2.0 gstbase-1.0
-WANTLIB += gstreamer-1.0 gstsdp-1.0 gstwebrtc-1.0 intl lmdb m
-WANTLIB += matrix_client olm qt5keychain spdlog ssl xcb xcb-ewmh
+WANTLIB += gstreamer-1.0 gstsdp-1.0 gstwebrtc-1.0 gstgl-1.0 gstvideo-1.0 intl
lmdb m
+WANTLIB += matrix_client olm qt6keychain spdlog ssl xkbcommon
MODULES = devel/cmake \
- x11/qt5
+ x11/qt6
# C++20
COMPILER = base-clang ports-gcc
@@ -31,7 +30,7 @@
devel/boost \
textproc/asciidoc \
textproc/nlohmann-json \
- x11/qt5/qtbase
+ x11/qt6/qtbase
LIB_DEPENDS = databases/lmdb \
devel/coeurl>=0.3.0 \
@@ -40,14 +39,15 @@
devel/spdlog \
multimedia/gstreamer1/core \
multimedia/gstreamer1/plugins-base \
- security/qtkeychain \
+ security/qtkeychain,qt6 \
textproc/cmark \
- x11/qt5/qtmultimedia \
- x11/qt5/qtquickcontrols2 \
- x11/qt5/qtsvg
+ x11/qt6/qtdeclarative \
+ x11/qt6/qtmultimedia \
+ x11/qt6/qtsvg
# -DCMAKE_DISABLE_FIND_PACKAGE_GIT=ON (or _Git or _git) do not work
CONFIGURE_ARGS += -DGIT=OFF
+CONFIGURE_ARGS += -DUSE_BUNDLED_KDSINGLEAPPLICATION=ON
CONFIGURE_ARGS += -DCMAKE_DISABLE_PRECOMPILE_HEADERS=ON
.include
Index: distinfo
===
RCS file: /cvs/ports/net/nheko/distinfo,v
diff -u -r1.4 distinfo
--- distinfo23 Feb 2023 09:14:06 - 1.4
+++ distinfo8 Jul 2024 06:47:30 -
@@ -1,2 +1,2 @@
-SHA256 (nheko-0.11.3.tar.gz) = 8oUVaISjoMaHDz+6icE9H9cMhye9F52DELE4GfimOjc=
-SIZE (nheko-0.11.3.tar.gz) = 1780179
+SHA256 (nheko-0.12.0.tar.gz) = o6dXi9k4aguaQYj6Epb93bffD4RsOXKLgKmY+dBvNtE=
+SIZE (nheko-0.12.0.tar.gz) = 2094339
Index: patches/patch-src_Cache_cpp
===
RCS file: patches/patch-src_Cache_cpp
diff -N patches/patch-src_Cache_cpp
--- patches/patch-src_Cache_cpp 20 Apr 2024 09:28:33 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,26 +0,0 @@
-- "Fruquent lag due to db sync"
https://github.com/Nheko-Reborn/nheko/issues/1355
- Backout d8669ccf3d4429e44caa87e2592b3bc3afa4e41c
-- Fix build against fmt10
- e89e65dc17020772eb057414b4f0c5d6f4ad98d0
-
-Index: src/Cache.cpp
src/Cache.cpp.orig
-+++ src/Cache.cpp
-@@ -293,7 +293,7 @@ Cache::setup()
- //
- // 2022-10-28: Disable the nosync flags again in the hope to crack
down on some database
- // corruption.
--env_.open(cacheDirectory_.toStdString().c_str()); //, MDB_NOMETASYNC
| MDB_NOSYNC);
-+env_.open(cacheDirectory_.toStdString().c_str(), MDB_NOMETASYNC
| MDB_NOSYNC);
- } catch (const lmdb::error &e) {
- if (e.code() != MDB_VERSION_MISMATCH && e.code() != MDB_INVALID) {
- throw std::runtime_error("LMDB initialization failed" +
std::string(e.what()));
-@@ -438,7 +438,7 @@ Cache::loadSecretsFromStore(
- if (job->error() && job->error() !=
QKeychain::Error::EntryNotFound) {
- nhlog::db()->error("Restoring secret '{}' failed ({}):
{}",
-name.toStdString(),
-- job->error(),
-+ static_cast(job->error()),
-
Re: UPDATE: spdlog 1.14.1
Le Sat, Jul 06, 2024 at 09:39:01PM -0400, Brad Smith a écrit : > On Sat, Jul 06, 2024 at 08:34:47PM -0400, Brad Smith wrote: > > Here is an update to spdlog 1.14.1. > > Also disable building an example. i have more or less the same diff, what brings not building the examples ? also the symbols in the lib didnt change here, so why bumping the major ? Landry
Re: NEW: sysutils/victorialogs v0.26.1
Le Sat, Jul 06, 2024 at 10:27:00AM +0200, Denis Fondras a écrit : > On Tue, Jul 02, 2024 at 08:51:11PM +0200, Landry Breuil wrote: > > Le Tue, Jul 02, 2024 at 07:43:06PM +0200, Denis Fondras a écrit : > > > Le Tue, Jul 02, 2024 at 12:13:36PM +0200, Landry Breuil a écrit : > > > > Le Mon, Jul 01, 2024 at 07:42:39PM +0200, Denis Fondras a écrit : > > > > > VictoriaLogs is a fast and easy-to-use, open source logs solution. > > > > > > > > i havent tested it but: > > > > > > > > - same COMMENT as victoriametrics, i suppose an oversight ? > > > > > > Thank you :) > > > > > > > - if you want to reuse _vmetrics uid you shouldnt have @user/@group > > > > entries in plist, but i guess you want a separate uid/gid ? > > > > > > > > > > I used the same because it was simpler. But if it is OK for you if I use > > > another > > > one, I can do the change. > > > > well, unless you have a good reason to share the uid (storage ownership > > for example), you're supposed to use a distinct one, so please yes :) > > > > Here is a new version. > > - change user > - update to v0.27.1 reads good to me, ok; maybe it could be merged with the victoriametrics ports since it builds from the same source, but not from the same tag.. a bit strange, but oh well. with the go.mod patch ? could that get a comment explaining it ? Landry
Re: 回复: shall we create new port lang/cython3 ?
Le Thu, Jul 04, 2024 at 03:54:08PM +0100, Stuart Henderson a écrit : > On 2024/06/30 14:53, Stuart Henderson wrote: > > On 2024/06/28 18:44, Daniel Dickman wrote: > > > > These use python 2 and fail with cython 3: > > > > > > > > games/pygame_sdl2 > > > > games/renpy > > > > > > please mark these as BROKEN > > > > > > > The following ports didn't build and I don't have diffs to fix/update > > > > them. If anyone wants to push this forward then figuring out how to > > > > patch > > > > or update these would be helpful: > > > > > > > > math/mlpack ? > > > > math/py-h5py,python33.11.0 supports newer cython, but needs > > > > newer numpy > > > > math/py-pandas,python3 ? > > > > math/py-scikit-image,python30.22.0/newer, need newer numpy (0.22.0: > > > > 1.23.3, 0.23.x: 2.x) > > > > math/py-scipy,python3 ? > > > > > > please mark the above as BROKEN for now. > > > > > > I use scipy and pandas so will be motivated to fix once we have Cython > > > 3 in the tree. > > Here's the diff that I have doing the above, maintainers of touched ports > CC'd. > Alternatively for mlpack, there's an update which works with new cython at > https://junkpile.org/mlpack-4.4.0.diff but I have no idea how to test it. definitely ok for the geo/ subdir - thanks a lot !
[update] databases/pgbouncer 1.23.0
hi,
small update but minor breaking changes cf
https://www.pgbouncer.org/changelog.html#pgbouncer-123x
ok ?
Index: Makefile
===
RCS file: /cvs/ports/databases/pgbouncer/Makefile,v
diff -u -r1.42 Makefile
--- Makefile15 May 2024 14:30:09 - 1.42
+++ Makefile4 Jul 2024 14:33:42 -
@@ -1,6 +1,6 @@
COMMENT = lightweight connection pooler for PostgreSQL
-V =1.22.1
+V =1.23.0
DISTNAME = pgbouncer-${V}
CATEGORIES = databases
Index: distinfo
===
RCS file: /cvs/ports/databases/pgbouncer/distinfo,v
diff -u -r1.19 distinfo
--- distinfo15 May 2024 14:30:09 - 1.19
+++ distinfo4 Jul 2024 14:33:42 -
@@ -1,2 +1,2 @@
-SHA256 (pgbouncer-1.22.1.tar.gz) = KwGKps5/WSyYkrueD9kCYkhOtzk3/Sr5KXcKRTc7ohU=
-SIZE (pgbouncer-1.22.1.tar.gz) = 677351
+SHA256 (pgbouncer-1.23.0.tar.gz) = GAQhnDAe8DXn9B6pr/HlGAtLr4hF1hBh6aEIWTYyMiY=
+SIZE (pgbouncer-1.23.0.tar.gz) = 694845
Re: NEW: sysutils/victorialogs v0.26.1
Le Tue, Jul 02, 2024 at 07:43:06PM +0200, Denis Fondras a écrit : > Le Tue, Jul 02, 2024 at 12:13:36PM +0200, Landry Breuil a écrit : > > Le Mon, Jul 01, 2024 at 07:42:39PM +0200, Denis Fondras a écrit : > > > VictoriaLogs is a fast and easy-to-use, open source logs solution. > > > > i havent tested it but: > > > > - same COMMENT as victoriametrics, i suppose an oversight ? > > Thank you :) > > > - if you want to reuse _vmetrics uid you shouldnt have @user/@group > > entries in plist, but i guess you want a separate uid/gid ? > > > > I used the same because it was simpler. But if it is OK for you if I use > another > one, I can do the change. well, unless you have a good reason to share the uid (storage ownership for example), you're supposed to use a distinct one, so please yes :)
Re: NEW: sysutils/victorialogs v0.26.1
Le Mon, Jul 01, 2024 at 07:42:39PM +0200, Denis Fondras a écrit : > VictoriaLogs is a fast and easy-to-use, open source logs solution. i havent tested it but: - same COMMENT as victoriametrics, i suppose an oversight ? - if you want to reuse _vmetrics uid you shouldnt have @user/@group entries in plist, but i guess you want a separate uid/gid ? Landry
Re: UPDATE: devel/py-sip 6.8.3, x11/py-qt5 5.15.10, x11/py-sip-qt5 12.13.0
Le Thu, Jun 27, 2024 at 07:21:33PM +0200, Caspar Schutijser a écrit : > Hi, > > Below is a diff that updates devel/py-sip and related ports that must > be upgraded at the same time to their most recent versions (there is > no update for www/py-qtwebengine). As is noted in the Makefile of > devel/py-sip, these updates should be tested well. > > I have tested the following ports at build-time and run-time: > - textproc/calibre > > I have tested whether the following ports still build: > - devel/py-qt-builder > - editors/py-qscintilla > - geo/qgis i've runtime-tested qgis with all those updates and it starts fine, ok with me.
[update] nextcloud 27.1.10
hi, still works for me on 7.4 (yeah i know), and still maintained upstream according to https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule ok ? Landry Index: Makefile === RCS file: /cvs/ports/www/nextcloud/27/Makefile,v diff -u -r1.16 Makefile --- Makefile30 Apr 2024 12:22:36 - 1.16 +++ Makefile15 Jun 2024 07:05:11 - @@ -1,4 +1,4 @@ -NC_VERSION=27.1.9 +NC_VERSION=27.1.10 # default PHP version changed, so keep REVISION in -current higher # than -stable until 7.5-release. Index: distinfo === RCS file: /cvs/ports/www/nextcloud/27/distinfo,v diff -u -r1.12 distinfo --- distinfo30 Apr 2024 12:22:36 - 1.12 +++ distinfo15 Jun 2024 07:05:11 - @@ -1,2 +1,2 @@ -SHA256 (nextcloud-27.1.9.tar.bz2) = +P4QzLWFNJ+EUQ25tLAgjbfziV2vPXpejxfSNuzEEfU= -SIZE (nextcloud-27.1.9.tar.bz2) = 188979224 +SHA256 (nextcloud-27.1.10.tar.bz2) = lD4ScNdxp8gNqisy5ylM6MO3e56u9yrYs4SH1YyFB1Y= +SIZE (nextcloud-27.1.10.tar.bz2) = 186125614 Index: pkg/PLIST === RCS file: /cvs/ports/www/nextcloud/27/pkg/PLIST,v diff -u -r1.12 PLIST --- pkg/PLIST 30 Apr 2024 12:22:36 - 1.12 +++ pkg/PLIST 15 Jun 2024 07:05:11 - @@ -8,16 +8,7 @@ @sample nextcloud/.htaccess nextcloud/.user.ini nextcloud/3rdparty/ -nextcloud/3rdparty/.github/ -nextcloud/3rdparty/.github/dependabot.yml -nextcloud/3rdparty/.github/workflows/ -nextcloud/3rdparty/.github/workflows/block-merge-freeze.yml -nextcloud/3rdparty/.github/workflows/composer-auto.yml -nextcloud/3rdparty/.github/workflows/composer.yml -nextcloud/3rdparty/.github/workflows/lint-php.yml -nextcloud/3rdparty/.gitignore nextcloud/3rdparty/LICENSE INFO -nextcloud/3rdparty/README.md nextcloud/3rdparty/autoload.php nextcloud/3rdparty/aws/ nextcloud/3rdparty/aws/aws-crt-php/ @@ -9314,13 +9305,10 @@ nextcloud/apps/activity/appinfo/info.xml nextcloud/apps/activity/appinfo/routes.php nextcloud/apps/activity/appinfo/signature.json -nextcloud/apps/activity/check-handlebars-templates.sh -nextcloud/apps/activity/compile-handlebars-templates.sh nextcloud/apps/activity/composer.json nextcloud/apps/activity/composer.lock nextcloud/apps/activity/css/ nextcloud/apps/activity/css/style.css -nextcloud/apps/activity/cypress.config.ts nextcloud/apps/activity/docs/ nextcloud/apps/activity/docs/create.md nextcloud/apps/activity/docs/endpoint-v2.md @@ -9488,6 +9476,8 @@ nextcloud/apps/activity/l10n/fo.json nextcloud/apps/activity/l10n/fr.js nextcloud/apps/activity/l10n/fr.json +nextcloud/apps/activity/l10n/ga.js +nextcloud/apps/activity/l10n/ga.json nextcloud/apps/activity/l10n/gd.js nextcloud/apps/activity/l10n/gd.json nextcloud/apps/activity/l10n/gl.js @@ -9675,7 +9665,6 @@ nextcloud/apps/activity/templates/settings/personal.php nextcloud/apps/activity/templates/stream.app.navigation.php nextcloud/apps/activity/templates/stream.body.php -nextcloud/apps/activity/tsconfig.json nextcloud/apps/activity/vendor-bin/ nextcloud/apps/activity/vendor-bin/cs-fixer/ nextcloud/apps/activity/vendor-bin/cs-fixer/composer.json @@ -9752,6 +9741,8 @@ nextcloud/apps/admin_audit/l10n/fi.json nextcloud/apps/admin_audit/l10n/fr.js nextcloud/apps/admin_audit/l10n/fr.json +nextcloud/apps/admin_audit/l10n/ga.js +nextcloud/apps/admin_audit/l10n/ga.json nextcloud/apps/admin_audit/l10n/gl.js nextcloud/apps/admin_audit/l10n/gl.json nextcloud/apps/admin_audit/l10n/he.js @@ -9943,6 +9934,8 @@ nextcloud/apps/bruteforcesettings/l10n/fo.json nextcloud/apps/bruteforcesettings/l10n/fr.js nextcloud/apps/bruteforcesettings/l10n/fr.json +nextcloud/apps/bruteforcesettings/l10n/ga.js +nextcloud/apps/bruteforcesettings/l10n/ga.json nextcloud/apps/bruteforcesettings/l10n/gd.js nextcloud/apps/bruteforcesettings/l10n/gd.json nextcloud/apps/bruteforcesettings/l10n/gl.js @@ -10058,8 +10051,6 @@ nextcloud/apps/bruteforcesettings/lib/Settings/IPWhitelist.php nextcloud/apps/bruteforcesettings/package-lock.json nextcloud/apps/bruteforcesettings/package.json -nextcloud/apps/bruteforcesettings/screenshots/ -nextcloud/apps/bruteforcesettings/screenshots/1.png nextcloud/apps/bruteforcesettings/templates/ nextcloud/apps/bruteforcesettings/templates/ipwhitelist.php nextcloud/apps/bruteforcesettings/vendor/ @@ -10177,6 +10168,8 @@ nextcloud/apps/circles/l10n/fi.json nextcloud/apps/circles/l10n/fr.js nextcloud/apps/circles/l10n/fr.json +nextcloud/apps/circles/l10n/ga.js +nextcloud/apps/circles/l10n/ga.json nextcloud/apps/circles/l10n/gl.js nextcloud/apps/circles/l10n/gl.json nextcloud/apps/circles/l10n/he.js @@ -10976,6 +10969,8 @@ nextcloud/apps/comments/l10n/fi.json nextcloud/apps/comments/l10n/fr.js nextcloud/apps/comments/l10n/fr.json +nextcloud/apps/comments/l10n/ga.js +nextcloud/apps/comments/l10n/ga.json nextcloud/apps/comments/l10n/gl.js nextcloud/
Re: net/synapse: fix tests
Le Mon, Jun 10, 2024 at 03:01:23PM +0100, Kirill A. Korinsky a écrit : > ports@ > > I discovered that make test for net/synapse doesn't work, all tests fail. > > Thus, tests seems to be leaked and it consumes near 8G of RAM before it was > killed due to hit the hard limit on my system. > > To avoid that I had added pytest-forked to run each test in dedicated > process that allows to limit memory consumption to 200-300 mb, > thsu, py-test-forked had missed dependecy to py-py which is known issue: > https://github.com/pytest-dev/pytest-forked/issues/88 > > Anyway, some tests still fails due to requerement postgresql: there's some goo in postgresql ports to start a throwaway psql instance to run tests if you want to give it a shot. Landry
[update] gimp/stable 2.10.38
hi,
small update for the stable branch, probably the last according to
https://www.gimp.org/news/2024/05/05/gimp-2-10-38-released/
tests/oks welcome.
Landry
Index: Makefile
===
RCS file: /cvs/ports/graphics/gimp/stable/Makefile,v
diff -u -r1.168 Makefile
--- Makefile29 May 2024 08:30:36 - 1.168
+++ Makefile5 Jun 2024 06:47:34 -
@@ -1,8 +1,7 @@
COMMENT= GNU Image Manipulation Program
-DISTNAME = gimp-2.10.36
+DISTNAME = gimp-2.10.38
PKGSPEC = gimp->=2,<2.99
-REVISION = 0
.for i in gimp gimpbase gimpcolor gimpconfig gimpmath gimpmodule \
gimpthumb gimpui gimpwidgets
@@ -28,7 +27,7 @@
WANTLIB += OpenEXRUtil-3_2 SM X11 Xau Xcomposite Xcursor Xdamage
WANTLIB += Xdmcp Xext Xfixes Xi Xinerama Xmu Xpm Xrandr Xrender
WANTLIB += Xt aa aom atk-1.0 avahi-client avahi-common babl-0.1
-WANTLIB += bz2 c cairo cairo-gobject crypto cups curses dav1d
+WANTLIB += bz2 c cairo cairo-gobject crypto cups curses
WANTLIB += dbus-1 de265 execinfo exiv2 expat ffi fontconfig freetype
WANTLIB += fribidi gdk-x11-2.0 gdk_pixbuf-2.0 gegl-0.4 gexiv2
WANTLIB += gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 graphite2
@@ -38,6 +37,7 @@
WANTLIB += pcre2-8 pixman-1 png poppler poppler-glib rsvg-2 ssl tiff
WANTLIB += webp webpdemux webpmux wmf-0.2 wmflite-0.2 x265 xcb
WANTLIB += xcb-render xcb-shm xml2 z zstd sharpyuv deflate
+WANTLIB += INIReader inih jxl_cms
DEBUG_PACKAGES=${BUILD_PACKAGES}
Index: distinfo
===
RCS file: /cvs/ports/graphics/gimp/stable/distinfo,v
diff -u -r1.50 distinfo
--- distinfo11 Nov 2023 13:11:41 - 1.50
+++ distinfo5 Jun 2024 06:47:34 -
@@ -1,2 +1,2 @@
-SHA256 (gimp-2.10.36.tar.bz2) = PTvDxppL2zrqm6LVOF7ZjqA5U/OFeq/R1pdgEe1827I=
-SIZE (gimp-2.10.36.tar.bz2) = 31532334
+SHA256 (gimp-2.10.38.tar.bz2) = UKhF7sEciDH+hmFweVD1uERuNfMO37ms+Y+FwRM/hW4=
+SIZE (gimp-2.10.38.tar.bz2) = 31698453
Index: pkg/PLIST
===
RCS file: /cvs/ports/graphics/gimp/stable/pkg/PLIST,v
diff -u -r1.57 PLIST
--- pkg/PLIST 11 Nov 2023 13:11:41 - 1.57
+++ pkg/PLIST 5 Jun 2024 06:47:35 -
@@ -5594,6 +5594,7 @@
share/locale/ka/LC_MESSAGES/gimp20-script-fu.mo
share/locale/ka/LC_MESSAGES/gimp20-std-plug-ins.mo
share/locale/ka/LC_MESSAGES/gimp20.mo
+share/locale/kab/LC_MESSAGES/gimp20-libgimp.mo
share/locale/kab/LC_MESSAGES/gimp20-python.mo
share/locale/kab/LC_MESSAGES/gimp20-std-plug-ins.mo
share/locale/kk/LC_MESSAGES/gimp20-libgimp.mo
[update] print/lyx 2.4.0
Le Fri, May 31, 2024 at 09:22:27AM +0200, Landry Breuil a écrit :
> hi,
>
> here's a rather simple update to 2.3.8 cf
> https://www.lyx.org/announce/2_3_7.txt
> https://www.lyx.org/announce/2_3_8.txt
> for details. the 2.4.0 release should happen someday, with experimental
> support for qt6.
and here's the diff for 2.4.0
https://wiki.lyx.org/LyX/NewInLyX24
tests still welcome !
Landry
? patch-config_h_in
Index: Makefile
===
RCS file: /cvs/ports/print/lyx/Makefile,v
diff -u -r1.106 Makefile
--- Makefile31 May 2024 06:00:12 - 1.106
+++ Makefile4 Jun 2024 19:20:05 -
@@ -1,24 +1,21 @@
-PORTROACH= skipv:2.3.x
-
COMMENT= graphical frontend for LaTeX (nearly WYSIWYG)
-DISTNAME= lyx-2.3.6.1
-REVISION= 5
+DISTNAME= lyx-2.4.0
CATEGORIES=print editors
HOMEPAGE= https://www.lyx.org/
-SITES= https://ftp.lip6.fr/pub/lyx/stable/2.3.x/ \
- http://ftp.icm.edu.pl/packages/lyx/stable/ \
- http://mirror.ufs.ac.za/applications/lyx/stable/2.3.x/ \
- ftp://ftp.lyx.org/pub/lyx/stable/2.3.x/ \
- ftp://ftp.ntua.gr/pub/X11/LyX/stable/2.3.x/ \
- ftp://ftp.u-aizu.ac.jp/pub/tex/lyx/stable/2.3.x/
+SITES= https://ftp.lip6.fr/pub/lyx/stable/2.4.x/ \
+ http://ftp.icm.edu.pl/packages/lyx/stable/2.4.x/ \
+ http://mirror.ufs.ac.za/applications/lyx/stable/2.4.x/ \
+ ftp://ftp.lyx.org/pub/lyx/stable/2.4.x/ \
+ ftp://ftp.ntua.gr/pub/X11/LyX/stable/2.4.x/ \
+ ftp://ftp.u-aizu.ac.jp/pub/tex/lyx/stable/2.4.x/
WANTLIB+= ${COMPILER_LIBCXX} Qt5Concurrent Qt5Core Qt5Gui Qt5Svg
-WANTLIB+= Qt5Widgets Qt5X11Extras aspell c enchant-2 hunspell-1.7
-WANTLIB+= iconv m magic xcb z
+WANTLIB+= Qt5Widgets Qt5X11Extras aspell c enchant-2 execinfo
+WANTLIB+= hunspell-1.7 iconv m magic xcb z
COMPILER= base-clang ports-gcc
Index: distinfo
===
RCS file: /cvs/ports/print/lyx/distinfo,v
diff -u -r1.21 distinfo
--- distinfo22 Jan 2021 23:27:06 - 1.21
+++ distinfo4 Jun 2024 19:20:05 -
@@ -1,2 +1,2 @@
-SHA256 (lyx-2.3.6.1.tar.gz) = bW9UWOuqxkTN+jURTQKensV7TZMCaNbUC9l5XVx+eSk=
-SIZE (lyx-2.3.6.1.tar.gz) = 27558948
+SHA256 (lyx-2.4.0.tar.gz) = 663GMaF3Gl383CfBr26UGrXPrZGMX7u/ZuKl11KsmSQ=
+SIZE (lyx-2.4.0.tar.gz) = 30754969
Index: patches/patch-config_h_in
===
RCS file: patches/patch-config_h_in
diff -N patches/patch-config_h_in
--- patches/patch-config_h_in 11 Mar 2022 19:51:04 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-Index: config.h.in
config.h.in.orig
-+++ config.h.in
-@@ -436,7 +436,7 @@ char * strerror(int n);
- #endif
-
- #ifdef HAVE_LONG_LONG_INT
--#if SIZEOF_LONG_LONG > SIZEOF_LONG
-+#if SIZEOF_LONG_LONG >= SIZEOF_LONG
- #define LYX_USE_LONG_LONG
- #endif
- #endif
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-configure 4 Jun 2024 19:20:05 -
@@ -0,0 +1,12 @@
+Index: configure
+--- configure.orig
configure
+@@ -17170,7 +17170,7 @@ fi
+ lyx_win_res=false;
+ case ${host} in
+ *mingw*|*cygwin*) lyx_win_res=true;;
+-*freebsd*) { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for
library containing backtrace_symbols" >&5
++*freebsd*|*openbsd*) { printf "%s\n" "$as_me:${as_lineno-$LINENO}:
checking for library containing backtrace_symbols" >&5
+ printf %s "checking for library containing backtrace_symbols... " >&6; }
+ if test ${ac_cv_search_backtrace_symbols+y}
+ then :
Index: patches/patch-src_support_filetools_cpp
===
RCS file: patches/patch-src_support_filetools_cpp
diff -N patches/patch-src_support_filetools_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_support_filetools_cpp 4 Jun 2024 19:20:05 -
@@ -0,0 +1,14 @@
+for WEXITSTATUS
+
+Index: src/support/filetools.cpp
+--- src/support/filetools.cpp.orig
src/support/filetools.cpp
+@@ -69,6 +69,8 @@
+ #if defined (_WIN32)
+ #include
+ #include
++#else
++#include
+ #endif
+
+ using namespace std;
Index: pkg/PLIST
===
RCS file: /cvs/ports/print/lyx/pkg/PLIST,v
diff -u -r1.32 PLIST
--- pkg/PLIST 29 May 2024 10:36:06 - 1.32
+++ pkg/PLIST 4 Jun 2024 19:20:05 -
@@ -13,7 +13,6 @@
share/locale/bg/LC_MESSAGES/lyx.mo
share/locale/cs/LC_MESSAGES/lyx.mo
share/locale/de/LC_MESSAGES/lyx.mo
-share/locale/el/LC_MESSAGES/lyx.mo
share/locale/en/LC_MESSAGES/ly
www/nginx: add mjs to mime.types for nextcloud ?
hi,
as discussed for httpd in https://marc.info/?t=17161976911&r=1&w=2
(but apparently didnt get commited ?), same thing for nginx.
i have it locally in the nextcould vhost but ...
discussed upstream in https://trac.nginx.org/nginx/ticket/2216 but
apparently that hasn't been commited (neither in freenginx)
note that im not entering the heated 'text/javascript' vs
'application/javascript' discussions from
https://trac.nginx.org/nginx/ticket/1407 /
https://mailman.nginx.org/pipermail/nginx-devel/2022-May/7PN54GRH2S4ESBBTUTGZDXEKPEZGCWOJ.html
i'd trust the commitees but.. *shrug*
https://developer.mozilla.org/en-US/docs/Learn/Server-side/Configuring_server_MIME_types
Landry
? nginx-1.18.0.diff
? nginx-mjs.diff
Index: Makefile
===
RCS file: /cvs/ports/www/nginx/Makefile,v
diff -u -r1.179 Makefile
--- Makefile30 May 2024 12:41:00 - 1.179
+++ Makefile2 Jun 2024 08:51:26 -
@@ -21,6 +21,7 @@
VERSION= 1.26.1
DISTNAME= nginx-${VERSION}
CATEGORIES=www
+REVISION-main= 0
VERSION-njs= 0.8.2
VERSION-rtmp= 1.2.1
Index: patches/patch-conf_mime_types
===
RCS file: /cvs/ports/www/nginx/patches/patch-conf_mime_types,v
diff -u -r1.6 patch-conf_mime_types
--- patches/patch-conf_mime_types 30 May 2022 08:17:35 - 1.6
+++ patches/patch-conf_mime_types 2 Jun 2024 08:51:26 -
@@ -1,7 +1,17 @@
+chunk 1: https://trac.nginx.org/nginx/ticket/2216
+
Index: conf/mime.types
--- conf/mime.types.orig
+++ conf/mime.types
-@@ -58,6 +58,7 @@ types {
+@@ -3,6 +3,7 @@ types {
+ text/htmlhtml htm shtml;
+ text/css css;
+ text/xml xml;
++text/javascript mjs;
+ image/gifgif;
+ image/jpeg jpeg jpg;
+ application/javascript js;
+@@ -58,6 +59,7 @@ types {
application/x-java-archive-diff jardiff;
application/x-java-jnlp-file jnlp;
application/x-makeself run;
@@ -9,7 +19,7 @@
application/x-perl pl pm;
application/x-pilot prc pdb;
application/x-rar-compressed rar;
-@@ -78,6 +79,7 @@ types {
+@@ -78,6 +80,7 @@ types {
application/octet-stream iso img;
application/octet-stream msi msp msm;
@@ -17,7 +27,7 @@
audio/midi mid midi kar;
audio/mpeg mp3;
audio/oggogg;
-@@ -92,6 +94,7 @@ types {
+@@ -92,6 +95,7 @@ types {
video/webm webm;
video/x-flv flv;
video/x-m4v m4v;
Re: PHP old versions heads-up
Le Wed, May 29, 2024 at 12:25:29PM +0100, Stuart Henderson a écrit : > On 2024/05/22 12:43, Stuart Henderson wrote: > > I intend to drop php/7.4 and php/8.0 soon (both are out of security > > support). The following ports/subpackages are setup to use 7.4 at the > > moment, if anyone's interested in them could you take a look at updating > > or patching to support 8.1+ please? > > > ... > > www/phppgadmin (pea@, upstream doesn't seem very alive) > > This switches to a better maintained fork and works ok with PHP 8.2. > > OK? i had never used that thing, but i can vouch for it - works here with php 8.1, i've been able to connect to a database over localhost. Maybe we should amend pkg/README that still mentions Apache/DocumentRoot ? :) ok with me !
[update] print/lyx 2.3.8
hi,
here's a rather simple update to 2.3.8 cf
https://www.lyx.org/announce/2_3_7.txt
https://www.lyx.org/announce/2_3_8.txt
for details. the 2.4.0 release should happen someday, with experimental
support for qt6.
feedback from actual users welcome.
Landry
Index: Makefile
===
RCS file: /cvs/ports/print/lyx/Makefile,v
diff -u -r1.106 Makefile
--- Makefile31 May 2024 06:00:12 - 1.106
+++ Makefile31 May 2024 07:19:53 -
@@ -2,8 +2,7 @@
COMMENT= graphical frontend for LaTeX (nearly WYSIWYG)
-DISTNAME= lyx-2.3.6.1
-REVISION= 5
+DISTNAME= lyx-2.3.8
CATEGORIES=print editors
Index: distinfo
===
RCS file: /cvs/ports/print/lyx/distinfo,v
diff -u -r1.21 distinfo
--- distinfo22 Jan 2021 23:27:06 - 1.21
+++ distinfo31 May 2024 07:19:53 -
@@ -1,2 +1,2 @@
-SHA256 (lyx-2.3.6.1.tar.gz) = bW9UWOuqxkTN+jURTQKensV7TZMCaNbUC9l5XVx+eSk=
-SIZE (lyx-2.3.6.1.tar.gz) = 27558948
+SHA256 (lyx-2.3.8.tar.gz) = I/meGgu/8ANBeXLoTsTUB6p2jJhEdx3L6deSeu3hqQk=
+SIZE (lyx-2.3.8.tar.gz) = 28134692
Index: patches/patch-config_h_in
===
RCS file: /cvs/ports/print/lyx/patches/patch-config_h_in,v
diff -u -r1.2 patch-config_h_in
--- patches/patch-config_h_in 11 Mar 2022 19:51:04 - 1.2
+++ patches/patch-config_h_in 31 May 2024 07:19:53 -
@@ -1,7 +1,7 @@
Index: config.h.in
--- config.h.in.orig
+++ config.h.in
-@@ -436,7 +436,7 @@ char * strerror(int n);
+@@ -438,7 +438,7 @@ char * strerror(int n);
#endif
#ifdef HAVE_LONG_LONG_INT
Index: pkg/PLIST
===
RCS file: /cvs/ports/print/lyx/pkg/PLIST,v
diff -u -r1.32 PLIST
--- pkg/PLIST 29 May 2024 10:36:06 - 1.32
+++ pkg/PLIST 31 May 2024 07:19:53 -
@@ -2538,6 +2538,8 @@
share/lyx/lyx2lyx/${MODPY_PYCACHE}lyx_2_2.${MODPY_PYC_MAGIC_TAG}pyc
share/lyx/lyx2lyx/${MODPY_PYCACHE}lyx_2_3.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
share/lyx/lyx2lyx/${MODPY_PYCACHE}lyx_2_3.${MODPY_PYC_MAGIC_TAG}pyc
+share/lyx/lyx2lyx/${MODPY_PYCACHE}lyx_2_4.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+share/lyx/lyx2lyx/${MODPY_PYCACHE}lyx_2_4.${MODPY_PYC_MAGIC_TAG}pyc
share/lyx/lyx2lyx/${MODPY_PYCACHE}parser_tools.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
share/lyx/lyx2lyx/${MODPY_PYCACHE}parser_tools.${MODPY_PYC_MAGIC_TAG}pyc
share/lyx/lyx2lyx/${MODPY_PYCACHE}profiling.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -2569,6 +2571,7 @@
share/lyx/lyx2lyx/lyx_2_1.py
share/lyx/lyx2lyx/lyx_2_2.py
share/lyx/lyx2lyx/lyx_2_3.py
+share/lyx/lyx2lyx/lyx_2_4.py
share/lyx/lyx2lyx/parser_tools.py
share/lyx/lyx2lyx/profiling.py
share/lyx/lyx2lyx/test_parser_tools.py
[update] nginx 1.26.1
yo,
list of changes:
*) Security: when using HTTP/3, processing of a specially crafted QUIC
session might cause a worker process crash, worker process memory
disclosure on systems with MTU larger than 4096 bytes, or might have
potential other impact (CVE-2024-32760, CVE-2024-31079,
CVE-2024-35200, CVE-2024-34161).
Thanks to Nils Bars of CISPA.
*) Bugfix: reduced memory consumption for long-lived requests if "gzip",
"gunzip", "ssi", "sub_filter", or "grpc_pass" directives are used.
*) Bugfix: nginx could not be built by gcc 14 if the --with-atomic
option was used.
Thanks to Edgar Bonet.
*) Bugfix: in HTTP/3.
ok ?
? nginx-1.18.0.diff
Index: Makefile
===
RCS file: /cvs/ports/www/nginx/Makefile,v
diff -u -r1.178 Makefile
--- Makefile17 May 2024 12:36:29 - 1.178
+++ Makefile30 May 2024 10:27:53 -
@@ -18,7 +18,7 @@
COMMENT-rtmp= nginx module for RTMP streaming
COMMENT-securelink=nginx HMAC secure link module
-VERSION= 1.26.0
+VERSION= 1.26.1
DISTNAME= nginx-${VERSION}
CATEGORIES=www
Index: distinfo
===
RCS file: /cvs/ports/www/nginx/distinfo,v
diff -u -r1.84 distinfo
--- distinfo27 Apr 2024 07:24:04 - 1.84
+++ distinfo30 May 2024 10:27:53 -
@@ -2,7 +2,7 @@
SHA256 (lua-nginx-module-v0.10.11.tar.gz) =
wPuR/P0cbn3sNMpkgm74H/66/e9hdNJURnY284BWZiY=
SHA256 (naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) =
2+IXdBFFfxy6mO5Gc84xh2mUrQa9zl7MDuZjhO8OQg4=
SHA256 (nginx-1.20.1-chroot.patch) =
SS1TB0j8N4/dn5pUTGT6WvkN3aAUuKz5+R0Nt+MG0gk=
-SHA256 (nginx-1.26.0.tar.gz) = 0ubIQ51sbbUBXY6qskcKtSrvhae/NjGCh5l34IQ3BJc=
+SHA256 (nginx-1.26.1.tar.gz) = +Rh0aP8usVkmC/1Thnwl/44zRyYjes8ie56HDlPT42s=
SHA256 (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) =
aQxOW9sq4ZsP7nXNNW0YATRo20cmFrYJeloLvjRshGQ=
SHA256 (nginx-rtmp-module-v1.2.1.tar.gz) =
h6pZdACwtaBSdO4tI9jLgiThJoYiegq+MdeDs6ZF6jc=
SHA256 (ngx_devel_kit-v0.3.0.tar.gz) =
iOBamainQZBm9a51lm+x78QJutRSLRSYbaB0VUrmFhk=
@@ -13,7 +13,7 @@
SIZE (lua-nginx-module-v0.10.11.tar.gz) = 616653
SIZE (naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) = 237272
SIZE (nginx-1.20.1-chroot.patch) = 8783
-SIZE (nginx-1.26.0.tar.gz) = 1244118
+SIZE (nginx-1.26.1.tar.gz) = 1244738
SIZE (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) = 18542
SIZE (nginx-rtmp-module-v1.2.1.tar.gz) = 519919
SIZE (ngx_devel_kit-v0.3.0.tar.gz) = 66455
Re: databases/pg_statsinfo, databases/pg_stats_reporter
Le Tue, May 28, 2024 at 09:13:27PM +0100, Stuart Henderson a écrit : > On 2024/05/28 21:32, Landry Breuil wrote: > > Le Tue, May 28, 2024 at 02:34:17PM +0100, Stuart Henderson a écrit : > > > databases/pg_statsinfo includes a program and loadable module for > > > postgresql that's used to collect server stats. It seems to be fairly > > > specific to postgresql major versions but hasn't been updated since > > > 13.0. I've tried updating to 16.x (diff below) but am not getting > > > far in testing - after adding the suggested lines to postgresql.conf > > > and running the pg_statsinfo binary with various options I get errors > > > like > > > > > > ERROR: query failed: ERROR: schema "statsinfo" does not exist > > > > > > > > > databases/pg_stats_reporter is a PHP program taking data from the > > > above. The version in-tree is for PHP 7.4 only. Also it looks like it > > > should probably be tied to the pg_statsinfo version; currently it's > > > a much older 3.2.1. > > > > > > > > > Is anyone currently using one or both of these ports? > > > If not, I wonder if they should be removed. > > > if yes, does the update work? > > > > well, i've had to: > > - create /var/run/pg_statsinfo (hardcoded in source) owned by _postgres, it > > creates a pidfile there > > - start the db with all the lines added to postgresql.conf > > Got those, /var/run/pg_statsinfo seemed the best place to use instead of > upstream's /run for Linux (per-user), but it's unfortunately hard to add > via an rc-script because it needs creating before postgresql starts. > It's a fixed filename (/some/path/$pgsql_port.pid) so /tmp wouldn't be > nice at all. > > I suppose it could be patched to use /var/postgresql/pg_statsinfo, > maybe that's the least worst option. Would be better in a dir cleaned > at boot though, if a previous instance died uncleanly it could lose > the pid reuse lottery and kill something random. > > This is how it tries to protect the file. > > /* automatic removal of the lock file at exit */ > atexit(unlink_lock_file); > > wish I hadn't looked! > > > - \i /usr/local/share/postgresql/contrib/pg_statsinfo.sql > > that's what I missed, thanks. well, made a bit more progress, the 'repository1' database (mentioned in /etc/pg_stats_reporter.ini) needs to be created, but then at startup the log is filled with May 29 08:21:18 c64 postgres: [179-1] 2024-05-29 08:21:18 CEST 36385 - (pg_statsinfod, , , pg_statsinfod) ERROR: pg_statsinfo: query failed: ERROR: could not open file "/proc/meminfo": May 29 08:21:18 c64 postgres: [179-2] 2024-05-29 08:21:18 CEST 36385 - (pg_statsinfod, , , pg_statsinfod) DETAIL: query was: SELECT mem_total FROM statsinfo.meminfo() May 29 08:21:18 c64 postgres: [180-1] 2024-05-29 08:21:18 CEST 36385 - (pg_statsinfod, , , pg_statsinfod) ERROR: pg_statsinfo: query failed: ERROR: could not open file "/proc/cpuinfo": May 29 08:21:18 c64 postgres: [180-2] 2024-05-29 08:21:18 CEST 36385 - (pg_statsinfod, , , pg_statsinfod) DETAIL: query was: SELECT vendor_id, model_name, cpu_mhz, processors, threads_per_core, cores_per_socket, sockets FROM statsinfo.cpuinfo() i havent checked if the same code was already present in the version currently in-tree, but ... yuck. https://github.com/ossc-db/pg_statsinfo/blob/main/agent/lib/libstatsinfo.c#L2420 Landry
Re: databases/pg_statsinfo, databases/pg_stats_reporter
Le Tue, May 28, 2024 at 02:34:17PM +0100, Stuart Henderson a écrit : > databases/pg_statsinfo includes a program and loadable module for > postgresql that's used to collect server stats. It seems to be fairly > specific to postgresql major versions but hasn't been updated since > 13.0. I've tried updating to 16.x (diff below) but am not getting > far in testing - after adding the suggested lines to postgresql.conf > and running the pg_statsinfo binary with various options I get errors > like > > ERROR: query failed: ERROR: schema "statsinfo" does not exist > > > databases/pg_stats_reporter is a PHP program taking data from the > above. The version in-tree is for PHP 7.4 only. Also it looks like it > should probably be tied to the pg_statsinfo version; currently it's > a much older 3.2.1. > > > Is anyone currently using one or both of these ports? > If not, I wonder if they should be removed. > if yes, does the update work? well, i've had to: - create /var/run/pg_statsinfo (hardcoded in source) owned by _postgres, it creates a pidfile there - start the db with all the lines added to postgresql.conf - \i /usr/local/share/postgresql/contrib/pg_statsinfo.sql with that i had a statsinfo schema. for pg_stats_reporter i had to copy /var/www/htdocs/pg_stats_reporter/doc/files/pg_stats_reporter.ini.sample to ~/.pg_stats_reporter.ini and set the database host, but even with that i cant get much out of pg_stats_reporter command. As a php script, it runs with 8.1 or 8.2 so for that part at least it 'works'. i havent tried the 'online dashboard' variant, i feel dirty enough for now :)
Re: update: wayland-protocols 1.36
Le Sun, May 19, 2024 at 05:20:35PM +0200, Matthieu Herrb a écrit : > Hi, > > Here's an update to wayland-protocols 1.36 > It should probably go into a bulk build since it exposes new protocols > that could be used by various wayland components. (so far wlroot & > friends won't use them, but upcoming Xwayland 24.1.0 update requires > them). > > ok ? i dunno if that counts as a proper test; but with this update installed, all ports under wayland/ builds fine, that doesn't test all the ones depending on gtk/kde.. Landry
Re: [Bug]devel/py-buildbot/buildbot lacks dependency on sysutils/py-packaging
Le Fri, May 24, 2024 at 12:24:44PM +0200, Matthias Pitzl a écrit : > Hi! > > Just updated our buildbot master system to OpenBSD 7.5 and after pkg_add -u > rcctl -d start buildbot failed with: > > doing _rc_parse_conf > > buildbot_flags empty, using default >/var/buildbot< > > doing rc_check > > buildbot > > doing rc_start > > doing _rc_wait_for_start > > doing rc_check > > doing rc_check > > Traceback (most recent call last): > > File "/usr/local/bin/buildbot", line 5, in > > from buildbot.scripts.runner import run > > File > > "/usr/local/lib/python3.10/site-packages/buildbot/scripts/runner.py", line > > 32, in > > from buildbot.scripts import base > > File "/usr/local/lib/python3.10/site-packages/buildbot/scripts/base.py", > > line 28, in > > from buildbot.config.master import FileLoader > > File "/usr/local/lib/python3.10/site-packages/buildbot/config/master.py", > > line 43, in > > from buildbot.www import auth > > File "/usr/local/lib/python3.10/site-packages/buildbot/www/auth.py", line > > 21, in > > from packaging.version import parse as parse_version > > ModuleNotFoundError: No module named 'packaging' > > doing _rc_rm_runfile > > (failed) > > I think theres a missing run dependency on sysutils/py-packaging. > After installing py3-packaging is was able to continue with the buildbot > upgrade > without any further problems. thanks for the report, i'll check and fix that.
[new] print/pdf2timage 1.17
hi, quick new port for https://pypi.org/project/pdf2image/ which is a wrapper around pdftoppm and pdftocairo from poppler-utils to convert PDF to a PIL Image object Landry py-pdf2image-1.17.0.tgz Description: application/tar-gz
Re: PHP old versions heads-up
Le Wed, May 22, 2024 at 02:28:08PM +0200, Landry Breuil a écrit :
> Le Wed, May 22, 2024 at 12:43:20PM +0100, Stuart Henderson a écrit :
> > I intend to drop php/7.4 and php/8.0 soon (both are out of security
> > support). The following ports/subpackages are setup to use 7.4 at the
> > moment, if anyone's interested in them could you take a look at updating
> > or patching to support 8.1+ please?
> >
> > misc/gpsd,-php (is anyone using the php part? does it already work?)
>
> i've had a quick look at this one,
> https://gitlab.com/gpsd/gpsd/-/issues/231 seems to say it should work
> with php 8.1 using
> https://gitlab.com/neonkingfr/gpsd/-/commit/cedd5b49d38ccdb60786a1657528a92681bb0d12
>
> all that to say the port itself can be safely updated to 8.1, because i
> doubt anyone actually uses the php file :)
> wont be able to test shortly as i dont have my usb gps handy..
>
> > www/racktables (still active upstream, looks like it has php8+ fixes)
>
> will have a look at this one, since i wanted to test netbox, might
> aswell try racktables..
i've been able to run the racktables installed on php 8.1 with the
attached diff. I gave up trying to apply
https://github.com/RackTables/racktables/pull/285 the same way for php
8.2 because one of the commits patches test files which arent present in
the original distfile, and patch -f still returns an error code, so that
would require using directly github via DIST_TUPLE (can do that to pull
master which includes the PR for php 8.0).
Landry
Index: Makefile
===
RCS file: /cvs/ports/www/racktables/Makefile,v
diff -u -r1.30 Makefile
--- Makefile27 Sep 2023 19:13:05 - 1.30
+++ Makefile22 May 2024 13:14:48 -
@@ -1,8 +1,8 @@
COMMENT= web-based rack/IP management
DISTNAME= RackTables-0.22.0
-MODPHP_VERSION=7.4
PKGNAME= ${DISTNAME:L}
+REVISION= 0
CATEGORIES=www
HOMEPAGE= https://www.racktables.org/
@@ -11,6 +11,12 @@
PERMIT_PACKAGE=Yes
SITES= ${SITE_SOURCEFORGE:=racktables/}
+# php 8.0 https://github.com/RackTables/racktables/pull/280
+# php 8.1 https://github.com/RackTables/racktables/pull/282
+SITES.p= https://github.com/RackTables/racktables/commit/
+PATCHFILES.p=
racktables-pr280{3530ddc00e51d7476162a5d4a1f6eba4ff40fd7f}.patch \
+ racktables-pr282{118269b607bd957fa27d0296823d7e435e6900b9}.patch
+PATCH_DIST_STRIP = -p1
MODULES= lang/php
Index: distinfo
===
RCS file: /cvs/ports/www/racktables/distinfo,v
diff -u -r1.16 distinfo
--- distinfo2 Jul 2022 13:35:50 - 1.16
+++ distinfo22 May 2024 13:14:48 -
@@ -1,2 +1,6 @@
SHA256 (RackTables-0.22.0.tar.gz) =
SSRn65F6/cl/NpRACxcbJ13gydYVMa0igleJ4M9PUWk=
+SHA256 (racktables-pr280.patch) = qjGcDkNWUweBh2pTJ2+BrvGFjfLNIHY+pzNtFnaN7l8=
+SHA256 (racktables-pr282.patch) = qs3UdvVMEQ5U4HmynCjGtfAikT9xfDfvaIgLTjuba3g=
SIZE (RackTables-0.22.0.tar.gz) = 1002878
+SIZE (racktables-pr280.patch) = 1587
+SIZE (racktables-pr282.patch) = 4420
Re: PHP old versions heads-up
Le Wed, May 22, 2024 at 12:43:20PM +0100, Stuart Henderson a écrit : > I intend to drop php/7.4 and php/8.0 soon (both are out of security > support). The following ports/subpackages are setup to use 7.4 at the > moment, if anyone's interested in them could you take a look at updating > or patching to support 8.1+ please? > > misc/gpsd,-php (is anyone using the php part? does it already work?) i've had a quick look at this one, https://gitlab.com/gpsd/gpsd/-/issues/231 seems to say it should work with php 8.1 using https://gitlab.com/neonkingfr/gpsd/-/commit/cedd5b49d38ccdb60786a1657528a92681bb0d12 all that to say the port itself can be safely updated to 8.1, because i doubt anyone actually uses the php file :) wont be able to test shortly as i dont have my usb gps handy.. > www/racktables (still active upstream, looks like it has php8+ fixes) will have a look at this one, since i wanted to test netbox, might aswell try racktables..
Re: [update/wip] x11/lxqt 2.0.0
Le Thu, Apr 18, 2024 at 07:48:01PM +0200, Landry Breuil a écrit : > hi, > > so our lxqt port is quite outdated/unmaintained. rafael had a wip in > https://github.com/sizeofvoid/wip-ports/commit/79f5e47c05c4a8341e7873dd850e2077ca5e7293 > > upstream just released the new qt6-based version: > https://lxqt-project.org/release/2024/04/15/release-lxqt-2-0-0/ > > so i've taken rafael's work and updated it for qt6, so find attached: > - 4 new ports for new dependencies, build-tools2 is > https://github.com/lxqt/lxqt-build-tools/releases/tag/2.0.0 used by > all the components that migrated to qt6 > - libdbusmenu is an lxqt fork of the qt5 libdbusmenu we have > - build-tools is kept for now because some bits haven't migrated away > from qt5 (the terminal, etc..) > - a large gzipped diff from x11/lxqt new version of the large gzipped diff with some 2.0.1/2.0.2 bugfix versions applied. up-to-date wip packages still at doas env PKG_PATH=https://packages.rhaalovely.net/wip/%a/:installpath pkg_add lxqt lxqt-extras oks for the new ports (also attached) welcome ! Landry lxqt2-newports.tgz Description: application/tar-gz lxqt2.0.0_1.diff.gz Description: application/gunzip
[update] mail/meli 0.8.5
hi,
small update to meli 0.8.5,
https://git.meli-email.org/meli/meli/releases/tag/v0.8.5 lists the
changes. i had to change the build to keep building the bundled sqlite
since it now uses a feature that isn't present in our system sqlite.
testing/feedback welcome, i'll probably commit it within some days.
Landry
? build-0.8.4.log
? build-0.8.5
? patch-meli_Cargo_toml
Index: Makefile
===
RCS file: /cvs/ports/mail/meli/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile9 Jan 2024 16:03:15 - 1.16
+++ Makefile14 May 2024 14:47:34 -
@@ -2,7 +2,7 @@
GH_ACCOUNT = meli
GH_PROJECT = meli
-GH_TAGNAME = v0.8.4
+GH_TAGNAME = v0.8.5
# ring-v0.16.20 does not support those archs
NOT_FOR_ARCHS =powerpc64 riscv64 sparc64
@@ -18,6 +18,7 @@
MODULES = devel/cargo
MODCARGO_FEATURES += jmap
MODCARGO_INSTALL_TARGET_PATHS =meli
+MODCARGO_CRATES_KEEP += libsqlite3-sys
.include "crates.inc"
@@ -26,11 +27,9 @@
BUILD_DEPENDS += security/rust-ring
-LIB_DEPENDS = devel/pcre2 \
- net/curl \
- databases/sqlite3
+LIB_DEPENDS = net/curl
-WANTLIB += ${MODCARGO_WANTLIB} crypto curl m pcre2-8 sqlite3 ssl
+WANTLIB += ${MODCARGO_WANTLIB} crypto curl m ssl
PORTHOME = ${WRKDIR}
post-install:
Index: crates.inc
===
RCS file: /cvs/ports/mail/meli/crates.inc,v
retrieving revision 1.4
diff -u -r1.4 crates.inc
--- crates.inc 9 Jan 2024 16:03:15 - 1.4
+++ crates.inc 14 May 2024 14:47:34 -
@@ -31,7 +31,6 @@
MODCARGO_CRATES += bytes 1.4.0 # MIT
MODCARGO_CRATES += castaway0.1.2 # MIT
MODCARGO_CRATES += cc 1.0.83 # MIT OR Apache-2.0
-MODCARGO_CRATES += cfg-if 0.1.10 # MIT/Apache-2.0
MODCARGO_CRATES += cfg-if 1.0.0 # MIT/Apache-2.0
MODCARGO_CRATES += chrono 0.4.26 # MIT/Apache-2.0
MODCARGO_CRATES += clap2.34.0 # MIT
@@ -63,6 +62,7 @@
MODCARGO_CRATES += encoding-index-tradchinese 1.20141219.5#
CC0-1.0
MODCARGO_CRATES += encoding_index_tests0.1.4 # CC0-1.0
MODCARGO_CRATES += encoding_rs 0.8.33 # (Apache-2.0 OR MIT) AND
BSD-3-Clause
+MODCARGO_CRATES += equivalent 1.0.1 # Apache-2.0 OR MIT
MODCARGO_CRATES += errno 0.3.2 # MIT OR Apache-2.0
MODCARGO_CRATES += errno-dragonfly 0.1.2 # MIT
MODCARGO_CRATES += event-listener 2.5.3 # Apache-2.0 OR MIT
@@ -76,10 +76,7 @@
MODCARGO_CRATES += foreign-types 0.3.2 # MIT/Apache-2.0
MODCARGO_CRATES += foreign-types-shared0.1.1 # MIT/Apache-2.0
MODCARGO_CRATES += form_urlencoded 1.2.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += fsevent 0.4.0 # MIT
-MODCARGO_CRATES += fsevent-sys 2.0.1 # MIT
-MODCARGO_CRATES += fuchsia-zircon 0.3.3 # BSD-3-Clause
-MODCARGO_CRATES += fuchsia-zircon-sys 0.3.3 # BSD-3-Clause
+MODCARGO_CRATES += fsevent-sys 4.1.0 # MIT
MODCARGO_CRATES += futures 0.3.28 # MIT OR Apache-2.0
MODCARGO_CRATES += futures-channel 0.3.28 # MIT OR Apache-2.0
MODCARGO_CRATES += futures-core0.3.28 # MIT OR Apache-2.0
@@ -104,25 +101,25 @@
MODCARGO_CRATES += imap-codec 1.0.0 # MIT OR Apache-2.0
MODCARGO_CRATES += imap-types 1.0.0 # MIT OR Apache-2.0
MODCARGO_CRATES += indexmap1.9.3 # Apache-2.0 OR MIT
-MODCARGO_CRATES += inotify 0.7.1 # ISC
+MODCARGO_CRATES += indexmap2.0.1 # Apache-2.0 OR MIT
+MODCARGO_CRATES += inotify 0.9.6 # ISC
MODCARGO_CRATES += inotify-sys 0.1.5 # ISC
MODCARGO_CRATES += instant 0.1.12 # BSD-3-Clause
MODCARGO_CRATES += io-lifetimes1.0.11 # Apache-2.0 WITH
LLVM-exception OR Apache-2.0 OR MIT
-MODCARGO_CRATES += iovec 0.1.4 # MIT/Apache-2.0
MODCARGO_CRATES += isahc 1.7.2 # MIT
MODCARGO_CRATES += itoa1.0.9 # MIT OR Apache-2.0
MODCARGO_CRATES += jobserver 0.1.26 # MIT/Apache-2.0
MODCARGO_CRATES += js-sys 0.3.64 # MIT/Apache-2.0
-MODCARGO_CRATES += kernel32-sys0.2.2 # MIT
+MODCARGO_CRATES += kqueue 1.0.8 # MIT
+MODCARGO_CRATES += kqueue-sys 1.0.4 # MIT
MODCARGO_CRATES += lazy_static 1.4.0 # MIT/Apache-2.0
-MODCARGO_CRATES += lazycell1.3.0 # MIT/Apache-2.0
-MODCARGO_CRATES += libc0.2.147 # MIT OR Apache-2.0
+MODCARGO_CRATES += libc0.2.153 # MIT OR Apache-2.0
MODCARGO_CRATES += libdbus-sys 0.2.5 # Apache-2.0/MIT
MODCARGO_CRATES += libloading 0.7.4 # ISC
MODCARGO_CRATES += libnghttp2-sys 0.1.8+1.55.1# MIT/Apache-2.0
MODCARGO_CRATES += libsqlite3-sys 0.26.0 # MIT
MODCARGO_CRATES += libz-sys1.1.12 # MIT OR Apache-2.0
-MODCARGO_CRATES += linkify 0.8.1 # MIT OR Apache-2.0
+MODCARGO_CRATES += linki
[update] pgbouncer 1.22.1
hi,
small update cf https://www.pgbouncer.org/changelog.html#pgbouncer-122x
ok ?
? pgbouncer-1.22.1.diff
Index: Makefile
===
RCS file: /cvs/ports/databases/pgbouncer/Makefile,v
retrieving revision 1.41
diff -u -r1.41 Makefile
--- Makefile21 Feb 2024 16:53:09 - 1.41
+++ Makefile14 May 2024 06:21:14 -
@@ -1,6 +1,6 @@
COMMENT = lightweight connection pooler for PostgreSQL
-V =1.22.0
+V =1.22.1
DISTNAME = pgbouncer-${V}
CATEGORIES = databases
Index: distinfo
===
RCS file: /cvs/ports/databases/pgbouncer/distinfo,v
retrieving revision 1.18
diff -u -r1.18 distinfo
--- distinfo21 Feb 2024 16:53:09 - 1.18
+++ distinfo14 May 2024 06:21:14 -
@@ -1,2 +1,2 @@
-SHA256 (pgbouncer-1.22.0.tar.gz) = xu43qNfdvrv4RC2PCOwHw9pGr7Kq45ZziMFIFpineFg=
-SIZE (pgbouncer-1.22.0.tar.gz) = 670589
+SHA256 (pgbouncer-1.22.1.tar.gz) = KwGKps5/WSyYkrueD9kCYkhOtzk3/Sr5KXcKRTc7ohU=
+SIZE (pgbouncer-1.22.1.tar.gz) = 677351
Re: NEW: x11/kde-plasma ports
Le Mon, May 06, 2024 at 07:34:54AM +0200, Rafael Sadowski a écrit : > Here are the last ports that need to be imported to activate KDE6. > > - print-manager: > > Moved from KDE Gear x11/kde-applications/print-manager. This needs to > be re-versioned to the lower 6.0 so I added EPOCH and "@pkgpath > x11/kde-applications/print-manager". doesnt this also require an @conflict in the PLIST ? (im not fully sure ... just askin') > OK to import with UNLINKED=kf6? i glanced over the others and didnt spot anything, so ok
Re: NEW: kf6-kio-extras, kf6-ksanecore, kf6-libkcddb, kf6-libkcompactdisc, kf6-libkdcraw, kf6-libkexiv2 and incidenceeditor
Le Sun, May 05, 2024 at 11:17:39AM +0200, Rafael Sadowski a écrit : > On Sat Apr 27, 2024 at 09:13:48AM GMT, Landry Breuil wrote: > > Le Fri, Apr 26, 2024 at 07:25:31AM +0200, Rafael Sadowski a écrit : > > > Now that part of the KDE6 ecosystem is in-tree we can easily build and > > > import new KDE6 ports. All attached ports are marked UNLONKED=kf6 so you > > > need BUILD_UNLINKED=kf6 in /etc/mk.conf and the following diff. > > > > > > As described in the KDE release notes instructions, we need these ports > > > as Kf6 and Kf5. I would therefore like to import all ports with the > > > prefix kf6. > > > > > > https://community.kde.org/KDE_Gear/24.02_Release_notes > > > > > > incidenceeditor is an exception, this is a completely new port without > > > kf6-*. The only one that otherwise has to be imported. A new Pim6 > > > dependnecy. > > > > there's @conflict kdepimlibs-<=4 in incidenceeditor/pkg/PLIST and i dont > > see which file would conflict, copypaste error ? > > Merci Landry ... > > yes it's a leftover form the copypaste error. I'll fix it. Thanks > > > > > kcddb has an unneeded dependency/@tag about update-desktop-databases > > Hmm "MODKDE5_DESKTOP_FILE = yes" includes the dependency. i think my comment was because there's no desktop file in x11/kde-applications/kf6-libkcddb/pkg/PLIST so the dependency (and the @tag annotation) aren't needed :) > I only ask for an OK for the import of the new kf6 packages. > > New tarball attached. ok for those !
[update] www/dokuwiki 2024.02.06a
hi,
smallish mechanical diff, totally untested, cf
https://www.dokuwiki.org/changes#release_2024-02-06a_kaos for changes.
ok ?
Landry
? dokuwiki-2023-04-04.diff
Index: Makefile
===
RCS file: /cvs/ports/www/dokuwiki/Makefile,v
retrieving revision 1.46
diff -u -r1.46 Makefile
--- Makefile9 Feb 2024 14:22:26 - 1.46
+++ Makefile30 Apr 2024 18:54:08 -
@@ -1,9 +1,8 @@
COMMENT = standards compliant, simple to use Wiki
-VERSION = 2023-04-04
+VERSION = 2024-02-06a
DISTNAME = dokuwiki-${VERSION}
PKGNAME = dokuwiki-${VERSION:S/-/./g}
-REVISION = 2
CATEGORIES = www
HOMEPAGE = https://www.dokuwiki.org/dokuwiki
Index: distinfo
===
RCS file: /cvs/ports/www/dokuwiki/distinfo,v
retrieving revision 1.20
diff -u -r1.20 distinfo
--- distinfo20 Apr 2023 17:03:33 - 1.20
+++ distinfo30 Apr 2024 18:54:08 -
@@ -1,2 +1,2 @@
-SHA256 (dokuwiki-2023-04-04.tgz) = Pj+XtHokMy7lnqUihlh6ucNCeSuR8+7BjDvxSVcRe0Y=
-SIZE (dokuwiki-2023-04-04.tgz) = 4032792
+SHA256 (dokuwiki-2024-02-06a.tgz) =
JYZQSNk2qhNqXg24Lj2jiGxPQ/glLxtezw8sftXrA18=
+SIZE (dokuwiki-2024-02-06a.tgz) = 4201385
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/dokuwiki/pkg/PLIST,v
retrieving revision 1.20
diff -u -r1.20 PLIST
--- pkg/PLIST 23 Aug 2023 11:40:14 - 1.20
+++ pkg/PLIST 30 Apr 2024 18:54:09 -
@@ -82,6 +82,7 @@
dokuwiki/inc/Action/AbstractAliasAction.php
dokuwiki/inc/Action/AbstractUserAction.php
dokuwiki/inc/Action/Admin.php
+dokuwiki/inc/Action/Authtoken.php
dokuwiki/inc/Action/Backlink.php
dokuwiki/inc/Action/Cancel.php
dokuwiki/inc/Action/Check.php
@@ -157,6 +158,12 @@
dokuwiki/inc/Extension/PluginTrait.php
dokuwiki/inc/Extension/RemotePlugin.php
dokuwiki/inc/Extension/SyntaxPlugin.php
+dokuwiki/inc/Feed/
+dokuwiki/inc/Feed/FeedCreator.php
+dokuwiki/inc/Feed/FeedCreatorOptions.php
+dokuwiki/inc/Feed/FeedItemProcessor.php
+dokuwiki/inc/Feed/FeedMediaProcessor.php
+dokuwiki/inc/Feed/FeedPageProcessor.php
dokuwiki/inc/FeedParser.php
dokuwiki/inc/FeedParserFile.php
dokuwiki/inc/File/
@@ -194,6 +201,7 @@
dokuwiki/inc/Input/Input.php
dokuwiki/inc/Input/Post.php
dokuwiki/inc/Input/Server.php
+dokuwiki/inc/JWT.php
dokuwiki/inc/JpegMeta.php
dokuwiki/inc/Logger.php
dokuwiki/inc/Mailer.class.php
@@ -280,10 +288,30 @@
dokuwiki/inc/Remote/
dokuwiki/inc/Remote/AccessDeniedException.php
dokuwiki/inc/Remote/Api.php
+dokuwiki/inc/Remote/ApiCall.php
dokuwiki/inc/Remote/ApiCore.php
dokuwiki/inc/Remote/IXR/
dokuwiki/inc/Remote/IXR/Client.php
+dokuwiki/inc/Remote/JsonRpcServer.php
+dokuwiki/inc/Remote/LegacyApiCore.php
+dokuwiki/inc/Remote/OpenApiDoc/
+dokuwiki/inc/Remote/OpenApiDoc/ClassResolver.php
+dokuwiki/inc/Remote/OpenApiDoc/DocBlock.php
+dokuwiki/inc/Remote/OpenApiDoc/DocBlockClass.php
+dokuwiki/inc/Remote/OpenApiDoc/DocBlockMethod.php
+dokuwiki/inc/Remote/OpenApiDoc/DocBlockProperty.php
+dokuwiki/inc/Remote/OpenApiDoc/OpenAPIGenerator.php
+dokuwiki/inc/Remote/OpenApiDoc/Type.php
dokuwiki/inc/Remote/RemoteException.php
+dokuwiki/inc/Remote/Response/
+dokuwiki/inc/Remote/Response/ApiResponse.php
+dokuwiki/inc/Remote/Response/Link.php
+dokuwiki/inc/Remote/Response/Media.php
+dokuwiki/inc/Remote/Response/MediaChange.php
+dokuwiki/inc/Remote/Response/Page.php
+dokuwiki/inc/Remote/Response/PageChange.php
+dokuwiki/inc/Remote/Response/PageHit.php
+dokuwiki/inc/Remote/Response/User.php
dokuwiki/inc/Remote/XmlRpcServer.php
dokuwiki/inc/SafeFN.class.php
dokuwiki/inc/Search/
@@ -386,6 +414,7 @@
dokuwiki/inc/lang/ar/mailwrap.html
dokuwiki/inc/lang/ar/newpage.txt
dokuwiki/inc/lang/ar/norev.txt
+dokuwiki/inc/lang/ar/onceexisted.txt
dokuwiki/inc/lang/ar/password.txt
dokuwiki/inc/lang/ar/preview.txt
dokuwiki/inc/lang/ar/pwconfirm.txt
@@ -2640,8 +2669,10 @@
dokuwiki/lib/exe/indexer.php
dokuwiki/lib/exe/jquery.php
dokuwiki/lib/exe/js.php
+dokuwiki/lib/exe/jsonrpc.php
dokuwiki/lib/exe/manifest.php
dokuwiki/lib/exe/mediamanager.php
+dokuwiki/lib/exe/openapi.php
dokuwiki/lib/exe/opensearch.php
dokuwiki/lib/exe/taskrunner.php
dokuwiki/lib/exe/xmlrpc.php
@@ -3364,6 +3395,7 @@
dokuwiki/lib/plugins/authldap/conf/metadata.php
dokuwiki/lib/plugins/authldap/lang/
dokuwiki/lib/plugins/authldap/lang/ar/
+dokuwiki/lib/plugins/authldap/lang/ar/lang.php
dokuwiki/lib/plugins/authldap/lang/ar/settings.php
dokuwiki/lib/plugins/authldap/lang/bg/
dokuwiki/lib/plugins/authldap/lang/bg/settings.php
@@ -3498,6 +3530,9 @@
dokuwiki/lib/plugins/authpdo/conf/default.php
dokuwiki/lib/plugins/authpdo/conf/metadata.php
dokuwiki/lib/plugins/authpdo/lang/
+dokuwiki/lib/plugins/authpdo/lang/ar/
+dokuwiki/lib/plugins/authpdo/lang/ar/lang.php
+dokuwiki/lib/plugins/authpdo/lang/ar/settings.php
dokuwiki/lib/plugins/authpdo/lang/bg/
dokuwiki/lib/plugins/authpdo/lang/bg/lang.php
dokuwiki
Re: [security] net/synapse 1.105.1
Le Mon, Apr 29, 2024 at 10:18:24AM +0200, Renaud Allard a écrit : > > > On 4/29/24 9:43 AM, Landry Breuil wrote: > > Le Mon, Apr 29, 2024 at 09:38:25AM +0200, Renaud Allard a écrit : > > > Hello, > > > > > > This is a small update for net/synapse to 1.105.1 to solve CVE-2024-31208 > > > > can you assess whether this should be backported to 7.5-stable, only a > > single commit, the complete update ? > > > The commit for the fix is > https://github.com/element-hq/synapse/commit/55b0aa847a61774b6a3acdc4b177a20dc019f01a > > It seems it affects all versions prior to 1.105.1. > I don't think backporting the whole version is really an issue, it might be > more simple than to just add the fix. There are no breaking changes between > the versions and I have tested the backport on -stable. > > Given that it can more or less corrupt the database by filling the disk, it > might be a good idea to backport it to -stable. the only drawback i can see is that the fix bumps the database schema version, so it requires an update of the database after applying the fix ?
Re: [security] net/synapse 1.105.1
Le Mon, Apr 29, 2024 at 09:38:25AM +0200, Renaud Allard a écrit : > Hello, > > This is a small update for net/synapse to 1.105.1 to solve CVE-2024-31208 can you assess whether this should be backported to 7.5-stable, only a single commit, the complete update ?
Re: [Update] sysutils/loki: update to 3.0.0
Le Sun, Apr 28, 2024 at 03:42:43PM +0200, Kirill A. Korinsky a écrit : > ports@ > > I apologize that I missed the name of the port in the original email's > subject, it's fixed now. > > I also include updated diff. > > This version additionnaly brings support of OpenBSD syslogd which was > backported to upstream: https://github.com/grafana/loki/pull/12810 interesting, many thanks for the detailed config sample, time is short in the coming days but i'll definitely play with that at some point ! Landry
Re: update: wlroots 0.17.3
Le Sun, Apr 28, 2024 at 10:22:15AM +0200, Matthieu Herrb a écrit : > Bug fix release. trivial update. Ok ? > pas testé mais ok !
Re: NEW: kf6-kio-extras, kf6-ksanecore, kf6-libkcddb, kf6-libkcompactdisc, kf6-libkdcraw, kf6-libkexiv2 and incidenceeditor
Le Fri, Apr 26, 2024 at 07:25:31AM +0200, Rafael Sadowski a écrit : > Now that part of the KDE6 ecosystem is in-tree we can easily build and > import new KDE6 ports. All attached ports are marked UNLONKED=kf6 so you > need BUILD_UNLINKED=kf6 in /etc/mk.conf and the following diff. > > As described in the KDE release notes instructions, we need these ports > as Kf6 and Kf5. I would therefore like to import all ports with the > prefix kf6. > > https://community.kde.org/KDE_Gear/24.02_Release_notes > > incidenceeditor is an exception, this is a completely new port without > kf6-*. The only one that otherwise has to be imported. A new Pim6 dependnecy. there's @conflict kdepimlibs-<=4 in incidenceeditor/pkg/PLIST and i dont see which file would conflict, copypaste error ? kcddb has an unneeded dependency/@tag about update-desktop-databases kio-extras/ksanecore have subdirs containing an extra copy of the port, oversight ? > One more idea, we could also commit the following diff with: No > MODKDE_VERSION change and MODKDE_KF5 = yes as default. This should not > result in any changes. i totally dont understand that sentence relating to the diff you attached. what is the reasoning of the Makefile.inc diff ? should that diff contain other things (eg MODKDE_KF5=yes and no MODKDE_VERSION change ?) is this diff related to/required for the new ports you sent in that mail ? Landry
[update] nextcloud 27.1.9
hi, still running fine on 7.4, will have a REVISION bump in -current ? ok ? Landry Index: Makefile === RCS file: /cvs/ports/www/nextcloud/27/Makefile,v retrieving revision 1.15 diff -u -r1.15 Makefile --- Makefile30 Mar 2024 13:33:11 - 1.15 +++ Makefile27 Apr 2024 07:01:46 - @@ -1,5 +1,4 @@ -NC_VERSION=27.1.8 -REVISION= 0 +NC_VERSION=27.1.9 # default PHP version changed, so keep REVISION in -current higher # than -stable until 7.5-release. Index: distinfo === RCS file: /cvs/ports/www/nextcloud/27/distinfo,v retrieving revision 1.11 diff -u -r1.11 distinfo --- distinfo30 Mar 2024 13:33:11 - 1.11 +++ distinfo27 Apr 2024 07:01:46 - @@ -1,2 +1,2 @@ -SHA256 (nextcloud-27.1.8.tar.bz2) = Ciy5vRKCnlOq8XNUPsrQFPCeganXL6YeTEYNhOO47fs= -SIZE (nextcloud-27.1.8.tar.bz2) = 188482936 +SHA256 (nextcloud-27.1.9.tar.bz2) = +P4QzLWFNJ+EUQ25tLAgjbfziV2vPXpejxfSNuzEEfU= +SIZE (nextcloud-27.1.9.tar.bz2) = 188979224 Index: pkg/PLIST === RCS file: /cvs/ports/www/nextcloud/27/pkg/PLIST,v retrieving revision 1.11 diff -u -r1.11 PLIST --- pkg/PLIST 30 Mar 2024 13:33:12 - 1.11 +++ pkg/PLIST 27 Apr 2024 07:01:46 - @@ -14041,6 +14041,8 @@ nextcloud/apps/files_reminders/l10n/ar.json nextcloud/apps/files_reminders/l10n/cs.js nextcloud/apps/files_reminders/l10n/cs.json +nextcloud/apps/files_reminders/l10n/de.js +nextcloud/apps/files_reminders/l10n/de.json nextcloud/apps/files_reminders/l10n/de_DE.js nextcloud/apps/files_reminders/l10n/de_DE.json nextcloud/apps/files_reminders/l10n/el.js @@ -14057,6 +14059,8 @@ nextcloud/apps/files_reminders/l10n/gl.json nextcloud/apps/files_reminders/l10n/hu.js nextcloud/apps/files_reminders/l10n/hu.json +nextcloud/apps/files_reminders/l10n/ko.js +nextcloud/apps/files_reminders/l10n/ko.json nextcloud/apps/files_reminders/l10n/lt_LT.js nextcloud/apps/files_reminders/l10n/lt_LT.json nextcloud/apps/files_reminders/l10n/mk.js @@ -14067,8 +14071,12 @@ nextcloud/apps/files_reminders/l10n/pl.json nextcloud/apps/files_reminders/l10n/pt_BR.js nextcloud/apps/files_reminders/l10n/pt_BR.json +nextcloud/apps/files_reminders/l10n/ro.js +nextcloud/apps/files_reminders/l10n/ro.json nextcloud/apps/files_reminders/l10n/ru.js nextcloud/apps/files_reminders/l10n/ru.json +nextcloud/apps/files_reminders/l10n/sc.js +nextcloud/apps/files_reminders/l10n/sc.json nextcloud/apps/files_reminders/l10n/sr.js nextcloud/apps/files_reminders/l10n/sr.json nextcloud/apps/files_reminders/l10n/sv.js @@ -14077,6 +14085,8 @@ nextcloud/apps/files_reminders/l10n/tr.json nextcloud/apps/files_reminders/l10n/uk.js nextcloud/apps/files_reminders/l10n/uk.json +nextcloud/apps/files_reminders/l10n/zh_CN.js +nextcloud/apps/files_reminders/l10n/zh_CN.json nextcloud/apps/files_reminders/l10n/zh_HK.js nextcloud/apps/files_reminders/l10n/zh_HK.json nextcloud/apps/files_reminders/l10n/zh_TW.js @@ -15629,6 +15639,8 @@ nextcloud/apps/lookup_server_connector/l10n/es.json nextcloud/apps/lookup_server_connector/l10n/es_EC.js nextcloud/apps/lookup_server_connector/l10n/es_EC.json +nextcloud/apps/lookup_server_connector/l10n/es_MX.js +nextcloud/apps/lookup_server_connector/l10n/es_MX.json nextcloud/apps/lookup_server_connector/l10n/et_EE.js nextcloud/apps/lookup_server_connector/l10n/et_EE.json nextcloud/apps/lookup_server_connector/l10n/eu.js @@ -16354,18 +16366,12 @@ nextcloud/apps/password_policy/l10n/az.json nextcloud/apps/password_policy/l10n/bg.js nextcloud/apps/password_policy/l10n/bg.json -nextcloud/apps/password_policy/l10n/bn_BD.js -nextcloud/apps/password_policy/l10n/bn_BD.json nextcloud/apps/password_policy/l10n/br.js nextcloud/apps/password_policy/l10n/br.json -nextcloud/apps/password_policy/l10n/bs.js -nextcloud/apps/password_policy/l10n/bs.json nextcloud/apps/password_policy/l10n/ca.js nextcloud/apps/password_policy/l10n/ca.json nextcloud/apps/password_policy/l10n/cs.js nextcloud/apps/password_policy/l10n/cs.json -nextcloud/apps/password_policy/l10n/cy_GB.js -nextcloud/apps/password_policy/l10n/cy_GB.json nextcloud/apps/password_policy/l10n/da.js nextcloud/apps/password_policy/l10n/da.json nextcloud/apps/password_policy/l10n/de.js @@ -16422,8 +16428,6 @@ nextcloud/apps/password_policy/l10n/fa.json nextcloud/apps/password_policy/l10n/fi.js nextcloud/apps/password_policy/l10n/fi.json -nextcloud/apps/password_policy/l10n/fo.js -nextcloud/apps/password_policy/l10n/fo.json nextcloud/apps/password_policy/l10n/fr.js nextcloud/apps/password_policy/l10n/fr.json nextcloud/apps/password_policy/l10n/gl.js @@ -16448,14 +16452,8 @@ nextcloud/apps/password_policy/l10n/ka.json nextcloud/apps/password_policy/l10n/ka_GE.js nextcloud/apps/password_policy/l10n/ka_GE.json -nextcloud/apps/password_policy/l10n/km.js -nextcloud/apps/password_policy/l10n/k
Re: net/rsync: rrsync is a python3 script...
Le Fri, Apr 26, 2024 at 10:49:44AM +0100, Stuart Henderson a écrit : > On 2024/04/26 11:14, Landry Breuil wrote: > > hi, > > > > on a bare machine with only rsync installed, trying to use rrsync > > wrapper script fails: > > > > env: python3: No such file or directory > > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > > rsync error: error in rsync protocol data stream (code 12) at io.c(231) > > [sender=3.2.7] > > > > i know it's a bit unfortunate, but i suppose adding python3 as > > RUN_DEPENDS is a bit ... gross ? should it be mentioned in a MESSAGE ? a > > README ? > > > > Landry > > > > I don't really like README for such a small note and don't want to add > the run dep for something that many people won't use. Personally I think > a quick note in DESCR would be enough but it could be a MESSAGE. > > (the error message is pretty obvious though..) so, something like this.. Index: Makefile === RCS file: /cvs/ports/net/rsync/Makefile,v retrieving revision 1.100 diff -u -r1.100 Makefile --- Makefile27 Sep 2023 14:18:31 - 1.100 +++ Makefile26 Apr 2024 10:31:03 - @@ -1,7 +1,7 @@ COMMENT = mirroring/synchronization over low bandwidth links DISTNAME = rsync-3.2.7 -REVISION = 1 +REVISION = 2 CATEGORIES = net HOMEPAGE = https://rsync.samba.org/ Index: pkg/DESCR === RCS file: /cvs/ports/net/rsync/pkg/DESCR,v retrieving revision 1.5 diff -u -r1.5 DESCR --- pkg/DESCR 10 Oct 2013 12:01:31 - 1.5 +++ pkg/DESCR 26 Apr 2024 10:31:03 - @@ -12,3 +12,7 @@ Flavor: iconv extra dependency, for people wanting to bring files from other OSes with more versatile filenames. + +To use the rrsync wrapper, python3 should be installed. + +# pkg_add python3
net/rsync: rrsync is a python3 script...
hi, on a bare machine with only rsync installed, trying to use rrsync wrapper script fails: env: python3: No such file or directory rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(231) [sender=3.2.7] i know it's a bit unfortunate, but i suppose adding python3 as RUN_DEPENDS is a bit ... gross ? should it be mentioned in a MESSAGE ? a README ? Landry
Re: [new] lnav 0.12.1
Le Thu, Apr 25, 2024 at 05:00:26PM +0200, Frederic Cambus a écrit : > On Wed, Apr 24, 2024 at 08:21:38AM +0200, Landry Breuil wrote: > > > > I previously didn't notice this, it always ran fine here during my tests: > > > launching it in tmux worked both locally and through SSH. > > > > > > But launching it in alacritty outside of tmux indeed results in a crash, > > > although it works fine in xterm or in a framebuffer console. > > > > interestingly, it started working once i had rm -Rf ~/.lnav. so i guess > > something something corrupted internal database ? > > > > does it work again if you move away ~/.lnav on the machine where it > > crashes ? > > On my machine it creates ~/.config/lnav, not ~/.lnav, and removing the > ~/.config/lnav directory unfortunately doesn't change anything, it still > crashes early at startup. it probably does funky things depending on $TERM. it works fine within tmux where TERM=screen, it crashes in xfce4-terminal (where here TERM=xterm-256color) but works fine if i manually set TERM=xterm. same thing with alacritty, it crashes if TERM=alacritty (the default) but works fine with 'TERM=xterm lnav' you seem to be a guy with interest in low-level terminal stuff :) grep -r TERM yields many things in lnav's code... and there seem to be related issues upstream, cf https://github.com/tstack/lnav/issues/570 and https://github.com/tstack/lnav/issues/1192 at least. But it shouldnt crash like this :) in the meantime, here's a port of 0.12.2, still building here... it might give better results, or not. https://github.com/tstack/lnav/releases/tag/v0.12.2 Landry lnav-0.12.2.tgz Description: application/tar-gz
Re: Rd: [update/wip] x11/lxqt 2.0.0
Le Thu, Apr 25, 2024 at 09:43:48AM -0700, J. Scott Heppler a écrit : > > Thanks for the work on updating LXQt. > > amd64 runs with kwin which does bring up one issue. > x11/openbox and obconf-qt are hard dependencies which is not the case for > Debian Derivatives and Arch Linux. Not sure about *rpm based systems. > > In Debian, the default window manager is xfwm4 but openbox/kwin can be > installed and xfwm4 removed. Same in Arch. Wayland seems to be > steamrolling into the opensource ecosystem and upstream LXQt plans on > wayland for v2.1 and I'm not if this will exclude X11. There is some chatter > about LXQt coming up with it's own WM which likely will be a Qt based > derivative of Kwin. that's somewhat easy to do in the meta/lxqt package, instead of having x11/lxqt/obconf-qt in RUN_DEPENDS one could have obconf-qt-*|xfwm4-*|kwin-*:x11/lqxt/obconf-qt with that, installing the lxqt meta package will default to install obconf-qt (and its LIB_DEPENDS openbox) but it will do fine if xfwm4 or kwin is already installed (and won't install obconf-qt/openbox) > The other thing I had trouble with is pavucontrol-qt. Trying to add the > volume-control widget to the panel failed and I suspect this is because > pulseaudio is not running. My mailing list searchs and websearchs did not > get any helpful search hits. Do you not start sndio. My LXQt install has a > pkg-readme for jack but I'm not sure how this factors into pulseaudio. i despise pulseaudio so never used it, but pavucontrol-qt has a LIB_DEPENDS on pulseaudio so it should be installed. I dunno if one is supposed to manually start it from .xsession though. Landry
Re: influxdb not starting after upgrade to 7.5
Le Wed, Apr 24, 2024 at 03:20:53PM +0100, Zé Loff a écrit :
> On Tue, Apr 23, 2024 at 03:42:43PM +0200, Landry Breuil wrote:
> > Le Tue, Apr 23, 2024 at 07:50:53AM +0100, Zé Loff a écrit :
> > > On Mon, Apr 22, 2024 at 11:26:37PM +0100, Zé Loff wrote:
> > > >
> > > > Hi all
> > > >
> > > > After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
> > > > saying:
> > > >
> > > > 2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id":
> > > > "0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date":
> > > > "2024-04-22T22:07:42Z", "log_level": "info"}
> > > > 2024-04-22T22:07:42.601348Z error Failed opening bolt {"log_id":
> > > > "0oiySb1l000", "error": "function not implemented"}
> > > >
> > > > Starting with a clean /var/influxdb doesn't help, nor does doing it as
> > > > root (which also starts with a clean slate, at /root/.influxdbv2).
> > > > Removing and reinstalling the package didn't help either.
> > > >
> > > > Has anyone else seen the same thing and/or has any advice?
> > > >
> > > > Thanks in advance
> > > >
> > > > --
> > > >
> > > >
> > >
> > > Minor update: the same thing happens on -current.
> >
> > with the attached diff, influxd starts on -current. That's all the testing
> > i've done :)
> >
> > feedback from real world testing welcome !
> >
>
> Built the port with this diff against 7.5-stable (minus the Makefile
> changes, which are post-7.5), and everything appears to be running fine.
>
> Admittedly, mine isn't the most complex setup in the world (single user,
> a couple of datab... buckets, collecting data from a few different hosts
> via telegraf, reporting via grafana), but FWIW, it seems to run OK. I
> can report again in a few days, just to be sure, but, again, this seems
> to fix things.
thanks for testing ! meanwhile we've had positive off-list reports, so
it's been commited to current and backported to 7.5-stable.
Landry
[update] nginx 1.26.0
hi,
upstream just released 1.26.0, the attached diff builds fine. testing
for various modules welcome !
https://nginx.org/en/CHANGES-1.26
'the "http2" parameter of the "listen" directive is now deprecated.'
Landry
? nginx-1.18.0.diff
Index: Makefile
===
RCS file: /cvs/ports/www/nginx/Makefile,v
retrieving revision 1.175
diff -u -r1.175 Makefile
--- Makefile26 Oct 2023 13:51:38 - 1.175
+++ Makefile24 Apr 2024 13:42:30 -
@@ -18,7 +18,7 @@
COMMENT-rtmp= nginx module for RTMP streaming
COMMENT-securelink=nginx HMAC secure link module
-VERSION= 1.24.0
+VERSION= 1.26.0
DISTNAME= nginx-${VERSION}
CATEGORIES=www
@@ -40,11 +40,6 @@
PKGNAME-passenger= nginx-passenger-${VERSION}
PKGNAME-rtmp= nginx-rtmp-${VERSION}
PKGNAME-securelink=nginx-securelink-${VERSION}
-
-REVISION-main= 0
-REVISION-passenger=1
-REVISION-njs= 1
-REVISION-lua= 0
ONLY_FOR_ARCHS-passenger= aarch64 amd64 arm i386
Index: distinfo
===
RCS file: /cvs/ports/www/nginx/distinfo,v
retrieving revision 1.83
diff -u -r1.83 distinfo
--- distinfo26 Oct 2023 13:51:38 - 1.83
+++ distinfo24 Apr 2024 13:42:30 -
@@ -2,7 +2,7 @@
SHA256 (lua-nginx-module-v0.10.11.tar.gz) =
wPuR/P0cbn3sNMpkgm74H/66/e9hdNJURnY284BWZiY=
SHA256 (naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) =
2+IXdBFFfxy6mO5Gc84xh2mUrQa9zl7MDuZjhO8OQg4=
SHA256 (nginx-1.20.1-chroot.patch) =
SS1TB0j8N4/dn5pUTGT6WvkN3aAUuKz5+R0Nt+MG0gk=
-SHA256 (nginx-1.24.0.tar.gz) = d6JUFje5KmIePudndsi3tAz21wfmm6U6lAKD4w/y9V0=
+SHA256 (nginx-1.26.0.tar.gz) = 0ubIQ51sbbUBXY6qskcKtSrvhae/NjGCh5l34IQ3BJc=
SHA256 (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) =
aQxOW9sq4ZsP7nXNNW0YATRo20cmFrYJeloLvjRshGQ=
SHA256 (nginx-rtmp-module-v1.2.1.tar.gz) =
h6pZdACwtaBSdO4tI9jLgiThJoYiegq+MdeDs6ZF6jc=
SHA256 (ngx_devel_kit-v0.3.0.tar.gz) =
iOBamainQZBm9a51lm+x78QJutRSLRSYbaB0VUrmFhk=
@@ -13,7 +13,7 @@
SIZE (lua-nginx-module-v0.10.11.tar.gz) = 616653
SIZE (naxsi-d714f1636ea49a9a9f4f06dba14aee003e970834.tar.gz) = 237272
SIZE (nginx-1.20.1-chroot.patch) = 8783
-SIZE (nginx-1.24.0.tar.gz) = 1112471
+SIZE (nginx-1.26.0.tar.gz) = 1244118
SIZE (nginx-auth-ldap-83c059b73566c2ee9cbda920d91b66657cf120b7.tar.gz) = 18542
SIZE (nginx-rtmp-module-v1.2.1.tar.gz) = 519919
SIZE (ngx_devel_kit-v0.3.0.tar.gz) = 66455
Index: pkg/PLIST-njs
===
RCS file: /cvs/ports/www/nginx/pkg/PLIST-njs,v
retrieving revision 1.1
diff -u -r1.1 PLIST-njs
--- pkg/PLIST-njs 21 Jul 2023 06:51:59 - 1.1
+++ pkg/PLIST-njs 24 Apr 2024 13:42:30 -
@@ -1,3 +1,2 @@
-@comment $OpenBSD: PLIST-njs,v 1.1 2023/07/21 06:51:59 sthen Exp $
@so ngx_http_js_module.so
@so ngx_stream_js_module.so
Re: [new] lnav 0.12.1
Le Tue, Apr 23, 2024 at 02:20:21PM +0100, Stuart Henderson a écrit : > On 2024/04/23 10:29, Landry Breuil wrote: > > Le Sun, Apr 21, 2024 at 10:17:44PM +0200, Frederic Cambus a écrit : > > > On Fri, Apr 19, 2024 at 05:50:09AM +0200, Landry Breuil wrote: > > > > > > > this is a second attempt at a port for https://lnav.org, after > > > > https://marc.info/?t=15333968122&r=1&w=2 some years ago, which > > > > fcambus@ reminded me about. He pushed it to wip but had issues with it > > > > linking against two readline libs. > > > > > > Thanks for picking this up again! > > > > > > > i had originally put it under textproc/ but frederic had it in > > > > sysutils/, no strong opinion on that. > > > > > > FWIW both FreeBSD and NetBSD have it in sysutils, but no strong opinion > > > either. > > > > > > > the attached port links against only one readline (the one from ports), > > > > and i've tried to do my best to have tests running. For now it seems one > > > > hangs.. > > > > > > > > PASS: lnav_doctests > > > > PASS: test_abbrev > > > > PASS: test_ansi_scrubber > > > > PASS: test_auto_fd > > > > PASS: test_auto_mem > > > > PASS: test_bookmarks > > > > ../test-driver: line 112: 69425 Abort trap (core dumped) > > > > "$@" >> "$log_file" 2>&1 > > > > FAIL: test_date_time_scanner > > > > PASS: test_format_installer.sh > > > > > > > > > > > > in 0.12.1 a PRQL feature was added > > > > (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) > > > > but it relies on rust/cargo being run from gmake and at that point i've > > > > just disabled this feature. > > > > > > Makes sense, yes. > > > > > > > feedback & testing welcome > > > > > > The build fails at link time if devel/fmt is installed. > > > > i've tried it, and with fmt 10.2.1 installed the build doesnt fail. when > > you saw that failure i suppose that was with the previous fmt version > > installed ? > > It's preferring libfmt in /usr/local for headers in some of the compiler > commands lines - "-I/usr/local/include -I./.. -I./../fmtlib" - so even > if it works now, things will likely break again in the future. > > It would be best to figure out how to get the -I reordered so that > -I./../fmtlib comes before -Iusr/local/include. You can check by > installing fmt, editing /usr/local/include/fmt/format.h to add a > #error at the top, and make sure that lnav still builds. this version builds fine with a poisoned fmt/format.h $grep \#error /usr/local/include/fmt/format.h #error lnav/patches/patch-src_tailer_Makefile_in just reorders the includes as advised, and it works fine. i've cleaned up makefile, tests still hang but some of them run fine, there's still room from improvement here so i've left NO_TEST commented out - but at least it now runs, even producing some NULL vfprintf on the way :) Apr 24 09:07:30 c64 lnav: vfprintf %s NULL in " XDG_CONFIG_HOME=%s" Apr 24 09:07:30 c64 lnav: vfprintf %s NULL in " TZ=%s" Apr 24 09:07:31 c64 lnav: vfprintf %s NULL in "read next header %s %s" Landry lnav-0.12.1_2.tgz Description: application/tar-gz
Re: [new] lnav 0.12.1
Le Tue, Apr 23, 2024 at 07:47:37PM +0200, Frederic Cambus a écrit : > On Tue, Apr 23, 2024 at 03:41:20PM +0200, Landry Breuil wrote: > > > > It's preferring libfmt in /usr/local for headers in some of the compiler > > > commands lines - "-I/usr/local/include -I./.. -I./../fmtlib" - so even > > > if it works now, things will likely break again in the future. > > > > > > It would be best to figure out how to get the -I reordered so that > > > -I./../fmtlib comes before -Iusr/local/include. You can check by > > > installing fmt, editing /usr/local/include/fmt/format.h to add a > > > #error at the top, and make sure that lnav still builds. > > > > and on top of that im not even sure this is worth importing as is, > > because it crashes/segfaults at startup here anyway. > > I previously didn't notice this, it always ran fine here during my tests: > launching it in tmux worked both locally and through SSH. > > But launching it in alacritty outside of tmux indeed results in a crash, > although it works fine in xterm or in a framebuffer console. interestingly, it started working once i had rm -Rf ~/.lnav. so i guess something something corrupted internal database ? does it work again if you move away ~/.lnav on the machine where it crashes ?
yt-dlp 2024.04.09
hi,
quick diff, works on 7.5 w/ france.tv.
ok ?
diff --git a/www/yt-dlp/Makefile b/www/yt-dlp/Makefile
index baf691dd69b..0d778300136 100644
--- a/www/yt-dlp/Makefile
+++ b/www/yt-dlp/Makefile
@@ -1,6 +1,6 @@
COMMENT = CLI program to download videos from YouTube and other sites
-VERSION = 2024.03.10
+VERSION = 2024.04.09
MODPY_EGG_VERSION =${VERSION:S/.0/./g}
DISTNAME = yt-dlp-${VERSION}
diff --git a/www/yt-dlp/distinfo b/www/yt-dlp/distinfo
index a2dc839db88..8b47e72d35d 100644
--- a/www/yt-dlp/distinfo
+++ b/www/yt-dlp/distinfo
@@ -1,2 +1,2 @@
-SHA256 (yt-dlp-2024.03.10.tar.gz) =
Hbjq3p6GBUO2VfX5c+JnJ6wswgh03G/tmj54pKBe6Yk=
-SIZE (yt-dlp-2024.03.10.tar.gz) = 5515436
+SHA256 (yt-dlp-2024.04.09.tar.gz) =
WdPK7VzImeSGp7iHP2FDtqHSLFtcBQCbcJygEE9dnu0=
+SIZE (yt-dlp-2024.04.09.tar.gz) = 5589808
diff --git a/www/yt-dlp/pkg/PLIST b/www/yt-dlp/pkg/PLIST
index c2c81418375..b2f4d61d9b6 100644
--- a/www/yt-dlp/pkg/PLIST
+++ b/www/yt-dlp/pkg/PLIST
@@ -252,6 +252,8 @@
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}arte.$
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}arte.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}asobichannel.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}asobichannel.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}asobistage.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}asobistage.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}atresplayer.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}atresplayer.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}atscaleconf.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -654,6 +656,8 @@
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}facebo
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}facebook.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}fancode.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}fancode.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}fathom.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}fathom.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}faz.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}faz.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}fc2.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -1010,6 +1014,8 @@
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}livest
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}livestreamfails.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}lnkgo.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}lnkgo.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}loom.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}loom.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}lovehomeporn.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}lovehomeporn.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}lrt.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -1592,6 +1598,8 @@
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}seznam
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}seznamzpravy.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}shahid.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}shahid.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}sharepoint.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}sharepoint.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/yt_dlp/extractor/${MODPY_PYCACHE}sharevideos.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/pyt
Re: influxdb not starting after upgrade to 7.5
Le Tue, Apr 23, 2024 at 04:04:23PM +0200, Kirill A. Korinsky a écrit : > On Tue, 23 Apr 2024 15:42:43 +0200, > Landry Breuil wrote: > > > > with the attached diff, influxd starts on -current. That's all the testing > > i've done :) > > > > feedback from real world testing welcome ! > > > > I've open a PR to update used version of bbolt at upstream [1], shall this > patch be used? that also probably works. adapting the diff i sent to use yours and do some testing left as an exercise for actual influxdb users :)
Re: influxdb not starting after upgrade to 7.5
Le Tue, Apr 23, 2024 at 07:50:53AM +0100, Zé Loff a écrit :
> On Mon, Apr 22, 2024 at 11:26:37PM +0100, Zé Loff wrote:
> >
> > Hi all
> >
> > After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
> > saying:
> >
> > 2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id":
> > "0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date":
> > "2024-04-22T22:07:42Z", "log_level": "info"}
> > 2024-04-22T22:07:42.601348Z error Failed opening bolt {"log_id":
> > "0oiySb1l000", "error": "function not implemented"}
> >
> > Starting with a clean /var/influxdb doesn't help, nor does doing it as
> > root (which also starts with a clean slate, at /root/.influxdbv2).
> > Removing and reinstalling the package didn't help either.
> >
> > Has anyone else seen the same thing and/or has any advice?
> >
> > Thanks in advance
> >
> > --
> >
> >
>
> Minor update: the same thing happens on -current.
with the attached diff, influxd starts on -current. That's all the testing i've
done :)
feedback from real world testing welcome !
? build.log
? buildpkgconfig.log
? crates.inc.2.7.0
? crates2.inc
? influxdb.diff
? modules.inc.2.7.0
? modules.inc.ok
? modules.inc1.9.5
Index: Makefile
===
RCS file: /cvs/ports/databases/influxdb/Makefile,v
retrieving revision 1.33
diff -u -r1.33 Makefile
--- Makefile23 Apr 2024 09:31:30 - 1.33
+++ Makefile23 Apr 2024 13:40:19 -
@@ -1,9 +1,3 @@
-# bbolt needs to be at least 1.3.8 to avoid syscall
-# modernc.org/libc and modernc.org/sqlite might work in latest head versions
now but not in a release yet
-# https://gitlab.com/cznic/libc/-/issues/29
-# https://gitlab.com/cznic/libc/-/merge_requests/13
-BROKEN = some modules used by influxdb require syscall() access which is
no longer available outside libc
-
COMMENT = time-series datastore for metrics, events, and analytics
MODUI_VERSION =v2.7.1
Index: distinfo
===
RCS file: /cvs/ports/databases/influxdb/distinfo,v
retrieving revision 1.8
diff -u -r1.8 distinfo
--- distinfo14 Nov 2023 00:08:32 - 1.8
+++ distinfo23 Apr 2024 13:40:19 -
@@ -1468,8 +1468,8 @@
SHA256 (go_modules/github.com/zeebo/xxh3/@v/v1.0.1.zip) =
ADQvDUPSdAVOzNxQ+6pBpQEBRuisgnc30hzhT2eJh0U=
SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.2.mod) =
siQNmH3bNjz9n5PJ7VP5r19NefAOWRE8g3WvwbkcS28=
SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.3.mod) =
siQNmH3bNjz9n5PJ7VP5r19NefAOWRE8g3WvwbkcS28=
-SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.6.mod) =
XDjGXmmRaJ8LnkB0KADeRlxstzrPjr0VRzDNxinKE2Q=
-SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.6.zip) =
o1f8zZPoZdzj04We2FfOgn96Ly3FuQz6qVIC9dduSsI=
+SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.8.mod) =
P9EfiW+DDmdLHgJxBOk0xfcQkdytIkHvnl/L5bKwPq8=
+SHA256 (go_modules/go.etcd.io/bbolt/@v/v1.3.8.zip) =
GLq65n7M3SmCrQvUS7d6I46LbI2hkrWua9PA3UjVujE=
SHA256 (go_modules/go.etcd.io/etcd/@v/v0.0.0-20191023171146-3cf2f69b5738.mod)
= Aq68KyNI9Hgtq+/IP63YARn8NQNZRreMsAlkqJGeD74=
SHA256 (go_modules/go.etcd.io/etcd/@v/v0.0.0-20191023171146-3cf2f69b5738.zip)
= T6k0WCeXPTV73D0ZHzpS56EHQQEq6eXyJxLtQonpm0Q=
SHA256
(go_modules/go.mozilla.org/pkcs7/@v/v0.0.0-20200128120323-432b2356ecb1.mod) =
aKaMiAYDnR/VbMx/zzOQHyj4ZP5vPxuoQVx54HfhDlY=
@@ -3620,8 +3620,8 @@
SIZE (go_modules/github.com/zeebo/xxh3/@v/v1.0.1.zip) = 269263
SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.2.mod) = 24
SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.3.mod) = 24
-SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.6.mod) = 94
-SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.6.zip) = 118439
+SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.8.mod) = 280
+SIZE (go_modules/go.etcd.io/bbolt/@v/v1.3.8.zip) = 144978
SIZE (go_modules/go.etcd.io/etcd/@v/v0.0.0-20191023171146-3cf2f69b5738.mod) =
2182
SIZE (go_modules/go.etcd.io/etcd/@v/v0.0.0-20191023171146-3cf2f69b5738.zip) =
7085205
SIZE
(go_modules/go.mozilla.org/pkcs7/@v/v0.0.0-20200128120323-432b2356ecb1.mod) = 37
Index: modules.inc
===
RCS file: /cvs/ports/databases/influxdb/modules.inc,v
retrieving revision 1.6
diff -u -r1.6 modules.inc
--- modules.inc 14 Nov 2023 00:08:32 - 1.6
+++ modules.inc 23 Apr 2024 13:40:19 -
@@ -472,7 +472,7 @@
github.com/yudai/pp
v2.0.1+incompatible \
github.com/yuin/goldmark
v1.4.13 \
github.com/zeebo/xxh3
v1.0.1 \
- go.etcd.io/bbolt
v1.3.6 \
+ go.etcd.io/bbolt
v1.3.8 \
go.etcd.io/etcd
v0.0.0-2019102317
Re: [new] lnav 0.12.1
Le Tue, Apr 23, 2024 at 02:20:21PM +0100, Stuart Henderson a écrit : > On 2024/04/23 10:29, Landry Breuil wrote: > > Le Sun, Apr 21, 2024 at 10:17:44PM +0200, Frederic Cambus a écrit : > > > On Fri, Apr 19, 2024 at 05:50:09AM +0200, Landry Breuil wrote: > > > > > > > this is a second attempt at a port for https://lnav.org, after > > > > https://marc.info/?t=15333968122&r=1&w=2 some years ago, which > > > > fcambus@ reminded me about. He pushed it to wip but had issues with it > > > > linking against two readline libs. > > > > > > Thanks for picking this up again! > > > > > > > i had originally put it under textproc/ but frederic had it in > > > > sysutils/, no strong opinion on that. > > > > > > FWIW both FreeBSD and NetBSD have it in sysutils, but no strong opinion > > > either. > > > > > > > the attached port links against only one readline (the one from ports), > > > > and i've tried to do my best to have tests running. For now it seems one > > > > hangs.. > > > > > > > > PASS: lnav_doctests > > > > PASS: test_abbrev > > > > PASS: test_ansi_scrubber > > > > PASS: test_auto_fd > > > > PASS: test_auto_mem > > > > PASS: test_bookmarks > > > > ../test-driver: line 112: 69425 Abort trap (core dumped) > > > > "$@" >> "$log_file" 2>&1 > > > > FAIL: test_date_time_scanner > > > > PASS: test_format_installer.sh > > > > > > > > > > > > in 0.12.1 a PRQL feature was added > > > > (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) > > > > but it relies on rust/cargo being run from gmake and at that point i've > > > > just disabled this feature. > > > > > > Makes sense, yes. > > > > > > > feedback & testing welcome > > > > > > The build fails at link time if devel/fmt is installed. > > > > i've tried it, and with fmt 10.2.1 installed the build doesnt fail. when > > you saw that failure i suppose that was with the previous fmt version > > installed ? > > It's preferring libfmt in /usr/local for headers in some of the compiler > commands lines - "-I/usr/local/include -I./.. -I./../fmtlib" - so even > if it works now, things will likely break again in the future. > > It would be best to figure out how to get the -I reordered so that > -I./../fmtlib comes before -Iusr/local/include. You can check by > installing fmt, editing /usr/local/include/fmt/format.h to add a > #error at the top, and make sure that lnav still builds. and on top of that im not even sure this is worth importing as is, because it crashes/segfaults at startup here anyway.
Re: influxdb not starting after upgrade to 7.5
Le Tue, Apr 23, 2024 at 10:26:10AM +0100, Stuart Henderson a écrit : > On 2024/04/23 11:22, Kirill A. Korinsky wrote: > > On Tue, 23 Apr 2024 10:59:30 +0200, > > Landry Breuil wrote: > > > > > > > > > > > OpenBSD was changed so that syscalls can only be made by libc. However > > > > some software (especially software written in Go) still relies on being > > > > able to call syscalls directly from the main program and this will no > > > > longer run on OpenBSD. > > > > > > rejoice ! influxdb 3 is written in rust ! > > > > > > > Ports has 2x which is go-based and which was released last week [1], anyway, > > they had quite clear that they won't do anything with 2x except of bugfixing > > in README [2]. > > > > But I haven't found any influxdb3 release at GitHub [3] nor at website [4] > > nor at docker registry [5]. > > > > From where I stand it looks like influxdb3 aren't ready to be used. > > > > Have I missed something? > > That's the impression I get too. And 3 doesn't have some features > which are used by other software that uses influxdb v2. that was just to say that whatever the shitshow it was right now with go, it will be a different shitshow too with rust. https://www.influxdata.com/products/influxdb-overview/ https://www.influxdata.com/blog/the-plan-for-influxdb-3-0-open-source/
Re: influxdb not starting after upgrade to 7.5
Le Tue, Apr 23, 2024 at 10:59:30AM +0200, Landry Breuil a écrit :
> Le Tue, Apr 23, 2024 at 09:42:26AM +0100, Stuart Henderson a écrit :
> > On 2024/04/22 23:26, Zé Loff wrote:
> > >
> > > Hi all
> > >
> > > After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
> > > saying:
> > >
> > > 2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id":
> > > "0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date":
> > > "2024-04-22T22:07:42Z", "log_level": "info"}
> > > 2024-04-22T22:07:42.601348Z error Failed opening bolt {"log_id":
> > > "0oiySb1l000", "error": "function not implemented"}
> > >
> > > Starting with a clean /var/influxdb doesn't help, nor does doing it as
> > > root (which also starts with a clean slate, at /root/.influxdbv2).
> > > Removing and reinstalling the package didn't help either.
> > >
> > > Has anyone else seen the same thing and/or has any advice?
> > >
> > > Thanks in advance
> > >
> > > --
> > >
> > >
> >
> > OpenBSD was changed so that syscalls can only be made by libc. However
> > some software (especially software written in Go) still relies on being
> > able to call syscalls directly from the main program and this will no
> > longer run on OpenBSD.
>
> rejoice ! influxdb 3 is written in rust !
>
> > I'm not too familiar with influxdb but it seems bolt/bbolt is a required
> > part of it, so I think we might as well mark it broken for now, it's not
> > going to magically start working unless changes are made.
>
> seconded. i'm tired of this ecosystem.
after a quick look, it'd need bbolt 1.3.8 (cf
https://github.com/etcd-io/bbolt/pull/406) and as for modernc.org/sqlite
im not even sure its fixed as
https://gitlab.com/cznic/sqlite/-/issues/140 leads to
https://gitlab.com/cznic/libc/-/issues/29 and
https://gitlab.com/cznic/libc/-/merge_requests/13 that only got recently
merged. s
Re: influxdb not starting after upgrade to 7.5
Le Tue, Apr 23, 2024 at 09:42:26AM +0100, Stuart Henderson a écrit :
> On 2024/04/22 23:26, Zé Loff wrote:
> >
> > Hi all
> >
> > After upgrading an amd64 machine to 7.5-stable, influxdb fails to start,
> > saying:
> >
> > 2024-04-22T22:07:42.599907Z infoWelcome to InfluxDB {"log_id":
> > "0oiySb1l000", "version": "2.7.3", "commit": "none", "build_date":
> > "2024-04-22T22:07:42Z", "log_level": "info"}
> > 2024-04-22T22:07:42.601348Z error Failed opening bolt {"log_id":
> > "0oiySb1l000", "error": "function not implemented"}
> >
> > Starting with a clean /var/influxdb doesn't help, nor does doing it as
> > root (which also starts with a clean slate, at /root/.influxdbv2).
> > Removing and reinstalling the package didn't help either.
> >
> > Has anyone else seen the same thing and/or has any advice?
> >
> > Thanks in advance
> >
> > --
> >
> >
>
> OpenBSD was changed so that syscalls can only be made by libc. However
> some software (especially software written in Go) still relies on being
> able to call syscalls directly from the main program and this will no
> longer run on OpenBSD.
rejoice ! influxdb 3 is written in rust !
> I'm not too familiar with influxdb but it seems bolt/bbolt is a required
> part of it, so I think we might as well mark it broken for now, it's not
> going to magically start working unless changes are made.
seconded. i'm tired of this ecosystem.
Re: [new] lnav 0.12.1
Le Sun, Apr 21, 2024 at 10:17:44PM +0200, Frederic Cambus a écrit : > On Fri, Apr 19, 2024 at 05:50:09AM +0200, Landry Breuil wrote: > > > this is a second attempt at a port for https://lnav.org, after > > https://marc.info/?t=15333968122&r=1&w=2 some years ago, which > > fcambus@ reminded me about. He pushed it to wip but had issues with it > > linking against two readline libs. > > Thanks for picking this up again! > > > i had originally put it under textproc/ but frederic had it in > > sysutils/, no strong opinion on that. > > FWIW both FreeBSD and NetBSD have it in sysutils, but no strong opinion > either. > > > the attached port links against only one readline (the one from ports), > > and i've tried to do my best to have tests running. For now it seems one > > hangs.. > > > > PASS: lnav_doctests > > PASS: test_abbrev > > PASS: test_ansi_scrubber > > PASS: test_auto_fd > > PASS: test_auto_mem > > PASS: test_bookmarks > > ../test-driver: line 112: 69425 Abort trap (core dumped) > > "$@" >> "$log_file" 2>&1 > > FAIL: test_date_time_scanner > > PASS: test_format_installer.sh > > > > > > in 0.12.1 a PRQL feature was added > > (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) > > but it relies on rust/cargo being run from gmake and at that point i've > > just disabled this feature. > > Makes sense, yes. > > > feedback & testing welcome > > The build fails at link time if devel/fmt is installed. i've tried it, and with fmt 10.2.1 installed the build doesnt fail. when you saw that failure i suppose that was with the previous fmt version installed ? Landry
Re: Switch from devel/kf5 to kf6/{extra-cmake-modules,breeze-icons}
Le Sun, Apr 21, 2024 at 09:01:13AM +0200, Rafael Sadowski a écrit : > On Wed Apr 17, 2024 at 07:55:47PM +0200, Landry Breuil wrote: > > Le Wed, Apr 17, 2024 at 07:52:11PM +0200, Rafael Sadowski a écrit : > > > On Wed Apr 17, 2024 at 07:34:57PM +0200, Landry Breuil wrote: > > > > Le Wed, Apr 17, 2024 at 07:25:51PM +0200, Rafael Sadowski a écrit : > > > > > I would like to replace devel/kf5/extra-cmake-modules and breeze-icons > > > > > with the kf6 version. > > > > > > > > > > This is the recommended way and for me the first step to continue > > > > > working cleanly. > > > > > > > > > > - Only one version of extra-cmake-modules can be installed. The KF6 > > > > > version is backwards compatible and should also be used for KF5 > > > > > builds. > > > > > > > > M.. hadnt realized it when i first looked before, but why not > > > > then... update devel/kf5/extra-cmake-modules to 6, not touching pkgpath > > > > and PKGNAME for now ? since it replaces version 5.. and this way you > > > > don't have to deal with a migration path. > > > > > > > > maybe the same thing applies for breeze-icons ? > > > > > > Yes, that's the shortcut, but I think we can remove kf5 completely in > > > the mid-term. I would like to have a clean separation. Especially at > > > ports-folder level. > > > > > > Everything comes with a clean kf6- prefix. The same goes for > > > x11/kde-plasma and x11/kde-applications. No longer the kf5 suffix, > > > prefix, non-fix. > > > > ok your call, the more churn the more chances to miss something :) > > i'm fine with your diff then > > > > All new KDE6 ports are makred "UNLINKED = kf6". Here is a diff that > makes use of this. I think it is safe for bulk(8) and easer for testers. > (BUILD_UNLINKED=kf6). Still ok kn@ and landry@? i've checked that there was @pkgpath/@conflict so that the kf5 versions of extra-cmake-modules/breeze-icons will be upgraded to the kf6. still ok with me.
Re: UPDATE: spdlog 1.13.0
Le Fri, Apr 19, 2024 at 10:11:47PM -0400, Brad Smith a écrit : > Here is an update to spdlog 1.13.0. > > And adjustments for some of the downstream ports that use > spdlog as a dependency. so from my understanding: - spdlog shipped its own bundled fmt, which gets removed in this update as newer spdlog now links with the system fmt (or the dep could be enabled since fmt was updated) - and the downstream ports coeurl & nheko get new patches (from upstream) to build against the system fmt too ? right ? iirc in the past i tried to update coeurl & nheko and there were issues with the fmt version we had, but now that it's updated it might be another occasion to update those. I'll eventually look at that too. Landry
[new] lnav 0.12.1
hi, this is a second attempt at a port for https://lnav.org, after https://marc.info/?t=15333968122&r=1&w=2 some years ago, which fcambus@ reminded me about. He pushed it to wip but had issues with it linking against two readline libs. i had originally put it under textproc/ but frederic had it in sysutils/, no strong opinion on that. the attached port links against only one readline (the one from ports), and i've tried to do my best to have tests running. For now it seems one hangs.. PASS: lnav_doctests PASS: test_abbrev PASS: test_ansi_scrubber PASS: test_auto_fd PASS: test_auto_mem PASS: test_bookmarks ../test-driver: line 112: 69425 Abort trap (core dumped) "$@" >> "$log_file" 2>&1 FAIL: test_date_time_scanner PASS: test_format_installer.sh in 0.12.1 a PRQL feature was added (https://github.com/tstack/lnav/commit/bdc9c5a28d8308a53ba4f881b29c307cff7cd97a) but it relies on rust/cargo being run from gmake and at that point i've just disabled this feature. feedback & testing welcome Landry lnav-0.12.1.tgz Description: application/tar-gz
[update/wip] x11/lxqt 2.0.0
hi,
so our lxqt port is quite outdated/unmaintained. rafael had a wip in
https://github.com/sizeofvoid/wip-ports/commit/79f5e47c05c4a8341e7873dd850e2077ca5e7293
upstream just released the new qt6-based version:
https://lxqt-project.org/release/2024/04/15/release-lxqt-2-0-0/
so i've taken rafael's work and updated it for qt6, so find attached:
- 4 new ports for new dependencies, build-tools2 is
https://github.com/lxqt/lxqt-build-tools/releases/tag/2.0.0 used by
all the components that migrated to qt6
- libdbusmenu is an lxqt fork of the qt5 libdbusmenu we have
- build-tools is kept for now because some bits haven't migrated away
from qt5 (the terminal, etc..)
- a large gzipped diff from x11/lxqt
- a small diff for meta/lxqt
some ports rely on not-yet-in-tree kde6 (or plasma 6) ports, at least:
- x11/kde-plasma/libkscreen
- x11/kde-plasma/layer-shell-qt
- devel/kf6/kwindowsystem
- devel/kf6/solid
- devel/kf6/kidletime
those can be grabbed from rafael's github wip. I've built the complete
thing two or three times and cleaned up WANTLIB/LIB_DEPENDS/PLIST here
and there but more eyes could catch mistakes...
or one can try the wip packages via
doas env PKG_PATH=https://packages.rhaalovely.net/wip/%a/:installpath pkg_add
lxqt lxqt-extras
i've been able to start the desktop and saw no crashes, but haven't
played with it much.
feedback from users and portswise welcome !
Landry
Index: Makefile
===
RCS file: /cvs/ports/meta/lxqt/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile30 Jan 2023 20:15:36 - 1.5
+++ Makefile18 Apr 2024 16:08:00 -
@@ -1,13 +1,11 @@
COMMENT-main = desktop meta-package for LXQt (base installation)
COMMENT-extras = desktop meta-package for LXQt (full installation)
-V =1.0.0
+V =2.0.0
PKGNAME = lxqt-${V}
PKGNAME-main = lxqt-${V}
-REVISION-main =0
PKGNAME-extras = lxqt-extras-${V}
-REVISION-extras = 0
MULTI_PACKAGES = -main -extras
lxqt2.0.0.diff.gz
Description: application/gunzip
lxqt2-newports.tgz
Description: application/tar-gz
Re: UPDATE: shapelib-1.6.0
Le Thu, Apr 18, 2024 at 05:08:00PM +0200, Rafael Sadowski a écrit : > I'm annoyed that shapelib failed with MAKE_JOBS. So here is an update > diff that switches to camke. > > http://shapelib.maptools.org/release.html > > I bumped shp: that matches the relnotes at https://github.com/OSGeo/shapelib/releases/tag/v1.6.0 i guess shputils has no point now that gdal does everything. ok if the consumers build fine :)
Re: NEW: multimedia/phonon-qt6 and multimedia/phonon-backend/vlc-qt6
Le Thu, Apr 18, 2024 at 09:38:05AM +0200, Rafael Sadowski a écrit : > On Mon Apr 15, 2024 at 12:07:34PM +0200, Landry Breuil wrote: > > Le Mon, Apr 08, 2024 at 07:33:15AM +0200, Rafael Sadowski a écrit : > > > On Sat Apr 06, 2024 at 02:36:43PM +, Klemens Nanni wrote: > > > > 14.03.2024 23:42, Rafael Sadowski via ports пишет: > > > > > I would like to import multimedia/phonon-backend/vlc-qt6 > > > > > multimedia/phonon-qt6. Please find tarball attached. This import does > > > > > not create any conflicts but it needs a simple adjustment > > > > > > > > Why those LIB_DEPENDS those? > > > > No REVISION bumps? > > > > > > > > > > Nothing changes: I moved LIB_DEPENDS as it is from Makefile.inc to the > > > Makefile's. This change is necessary to import > > > multimedia/phonon-backend/vlc-qt6 otherwise > > > multimedia/phonon-backend/vlc-qt6 depends on "multimedia/phonon>=4.12.0" > > > which is qt5. > > > > that part is fine. I looked at the two ports, and it's still a bit sad > > to have 'new ports with a -qt6 suffix' from the same tarball building > > twice, once with qt5 and once with qt6, while it could only be built > > once with the two qt5/qt6 backends and shipped as subpackages.. that > > would be cleaner. Will that be only transitional, or both will coexist > > for years ? > > > > anybody else having a strong opinion on that subject ? > > > New flavor approach. I'm happy with this one and I want to push it into > a bulk build. it built fine here, and afaict an existing phonon-4.12.0 was upgraded to p0 fine, and both versions coexist. Two nits: - are the consumers fine with the renaming of the bin/phononsettings binary ? nothing hardcoding it in some desktop file in another port ? - vlc,qt6 should be added to multimedia/phonon-backend/Makefile :) with that checked and provided your bulk is fine, definitely ok with me !
Re: NEW: multimedia/phonon-qt6 and multimedia/phonon-backend/vlc-qt6
Le Thu, Apr 18, 2024 at 09:38:05AM +0200, Rafael Sadowski a écrit : > On Mon Apr 15, 2024 at 12:07:34PM +0200, Landry Breuil wrote: > > Le Mon, Apr 08, 2024 at 07:33:15AM +0200, Rafael Sadowski a écrit : > > > On Sat Apr 06, 2024 at 02:36:43PM +, Klemens Nanni wrote: > > > > 14.03.2024 23:42, Rafael Sadowski via ports пишет: > > > > > I would like to import multimedia/phonon-backend/vlc-qt6 > > > > > multimedia/phonon-qt6. Please find tarball attached. This import does > > > > > not create any conflicts but it needs a simple adjustment > > > > > > > > Why those LIB_DEPENDS those? > > > > No REVISION bumps? > > > > > > > > > > Nothing changes: I moved LIB_DEPENDS as it is from Makefile.inc to the > > > Makefile's. This change is necessary to import > > > multimedia/phonon-backend/vlc-qt6 otherwise > > > multimedia/phonon-backend/vlc-qt6 depends on "multimedia/phonon>=4.12.0" > > > which is qt5. > > > > that part is fine. I looked at the two ports, and it's still a bit sad > > to have 'new ports with a -qt6 suffix' from the same tarball building > > twice, once with qt5 and once with qt6, while it could only be built > > once with the two qt5/qt6 backends and shipped as subpackages.. that > > would be cleaner. Will that be only transitional, or both will coexist > > for years ? > > > > anybody else having a strong opinion on that subject ? > > > New flavor approach. I'm happy with this one and I want to push it into > a bulk build. oh, i really really like that :)
Re: 回复: 回复: x11/lxqt: Update to 1.2.0
Le Thu, Apr 27, 2023 at 07:24:08AM +, wen heping a écrit : > Thank you ! > > I shall recheck it again and update to 1.3. https://lxqt-project.org/release/2024/04/15/release-lxqt-2-0-0/ switches to QT6. Le Thu, Apr 27, 2023 at 07:24:08AM +, wen heping a écrit : > Thank you ! > > I shall recheck it again and update to 1.3. https://lxqt-project.org/release/2024/04/15/release-lxqt-2-0-0/ switches to QT6.
