On 2024-03-31, Kirill A. Korinsky wrote:
> Folks,
>
> I just run: pkg_add -D snap -u
>
> After that I've discovered that some Qt apps are crashing with errors like:
>
> Cannot add multiple registrations for QtQuick
> Abort trap (core dumped)
>
> for example telegram-desktop crashes but wireshark doesn't.
>
> --
> wbr, Kirill
>
Telegram-desktop (net/tdesktop) also crashed here after a package update.
I then noticed it was caused by linking issues with the qt6 libraries.
Deleting and adding net/tdesktop simply solved that.
That should not be a problem tho. Applications are normally reinstalled
after the library is updated (or does that only happen when a major
version of the library is installed?).
Sunday, March 31, 2024
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
This thread is now closed, please don't try to continue it.
- todd
- todd
Re: I DEMAND TO KNOW (re recent activity)
On 2024-03-31, Peter N. M. Hansteen <peter@bsdly.net> wrote:
> Some recent activity here (you will remember the threads) had me want to post
> this earlier, but I was bowled over by a stomach bug and only found the reference
> again now -
Just block the senders, ignore the threads and move on.
> Some recent activity here (you will remember the threads) had me want to post
> this earlier, but I was bowled over by a stomach bug and only found the reference
> again now -
Just block the senders, ignore the threads and move on.
Re: I DEMAND TO KNOW (re recent activity)
El Sun, 31 Mar 2024 22:59:01 +0200
"Peter N. M. Hansteen" <peter@bsdly.net> escribió:
> Friends,
>
> Some recent activity here (you will remember the threads) had me want
> to post this earlier, but I was bowled over by a stomach bug and only
> found the reference again now -
>
> https://mastodon.social/deck/@danielbowen/112173051434619556
>
> which reads:
>
> Daniel Bowen @danielbowen@mastodon.social
>
> From a tweet of mine from 2011, but evergreen:
>
> I DEMAND TO KNOW WHY YOUR GROUP OF OVERWORKED VOLUNTEERS, WHICH
> I AM NOT A MEMBER OF, IS NOT PURSUING MY PERSONAL GRIEVANCE.
>
> Mar 28, 2024, 12:22 PM
>
They demand, but they do not collaborate in any way. They do not lift a
finger to improve things, but they demand and demand that their designs
be fulfilled.
Trolls, who only know how to do one thing: cry loudly.
Don't give them importance, filter the garbage and we continue our
lives.
--
*********************************************************
Dios en su cielo, todo bien en la Tierra
"Peter N. M. Hansteen" <peter@bsdly.net> escribió:
> Friends,
>
> Some recent activity here (you will remember the threads) had me want
> to post this earlier, but I was bowled over by a stomach bug and only
> found the reference again now -
>
> https://mastodon.social/deck/@danielbowen/112173051434619556
>
> which reads:
>
> Daniel Bowen @danielbowen@mastodon.social
>
> From a tweet of mine from 2011, but evergreen:
>
> I DEMAND TO KNOW WHY YOUR GROUP OF OVERWORKED VOLUNTEERS, WHICH
> I AM NOT A MEMBER OF, IS NOT PURSUING MY PERSONAL GRIEVANCE.
>
> Mar 28, 2024, 12:22 PM
>
They demand, but they do not collaborate in any way. They do not lift a
finger to improve things, but they demand and demand that their designs
be fulfilled.
Trolls, who only know how to do one thing: cry loudly.
Don't give them importance, filter the garbage and we continue our
lives.
--
*********************************************************
Dios en su cielo, todo bien en la Tierra
I DEMAND TO KNOW (re recent activity)
Friends,
Some recent activity here (you will remember the threads) had me want to post
this earlier, but I was bowled over by a stomach bug and only found the reference
again now -
https://mastodon.social/deck/@danielbowen/112173051434619556
which reads:
Daniel Bowen @danielbowen@mastodon.social
From a tweet of mine from 2011, but evergreen:
I DEMAND TO KNOW WHY YOUR GROUP OF OVERWORKED VOLUNTEERS, WHICH
I AM NOT A MEMBER OF, IS NOT PURSUING MY PERSONAL GRIEVANCE.
Mar 28, 2024, 12:22 PM
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Some recent activity here (you will remember the threads) had me want to post
this earlier, but I was bowled over by a stomach bug and only found the reference
again now -
https://mastodon.social/deck/@danielbowen/112173051434619556
which reads:
Daniel Bowen @danielbowen@mastodon.social
From a tweet of mine from 2011, but evergreen:
I DEMAND TO KNOW WHY YOUR GROUP OF OVERWORKED VOLUNTEERS, WHICH
I AM NOT A MEMBER OF, IS NOT PURSUING MY PERSONAL GRIEVANCE.
Mar 28, 2024, 12:22 PM
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
If I'm explaining security or lack of security, or saying things like "this is not enough", it's not as part of a speech that's meant to whine. I'll explain: I could've just asked, in my first message, whether OpenBSD has a mechanism like Ctrl-Alt-Delete on Windows, and whether it has sandboxing for desktop apps, without explaining the rationale of having such security features. Then, someone could've come and tell me that these security features aren't necessary, or that I'm focusing on a minor security aspect. I wanted an informed discussion, so I was explaining the rationale behind these to make readers understand why I was asking about them. Furthermore, in my recent message about the faking of a doas/sudo prompt and User Account Control (UAC) on Windows, there was a part where I said that the sandboxing that OpenBSD provides for certain apps "[that alone] is not enough"; I said that in the context of explaining the security that UAC provides on Windows compared to what there seems to be with the default installation of OpenBSD, notice the rest of the message and how that comment of mine was in parantheses. It may sound like I'm completely knowledgeable about OpenBSD, but I'm not. I understand certain generally-applying concepts, but I don't know if, for example, there's a sysctl(2) or something that can optionally toggle into that. (As an example, until recently, I didn't know there was an optional sysctl(2) that can enable extra hardening for malloc.) I hope this clears up why I'm writing things the way I do.
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
On Sunday, March 31, 2024, Jose Maldonado <josemald89@gmail.com> wrote:
El Sun, 31 Mar 2024 01:10:15 +0000
Dan <dan.peretz.my@gmail.com> escribió:
> On Wednesday, March 27, 2024, Dan <dan.peretz.my@gmail.com> wrote:
>
Hi @list!
Lots of discussion and useless talk when the solution is in your hands
@Dan:
1.- Are you worried about the fact that apps on X11 may suffer
Emphasis on "may".
input-spoofing? Great, start writing all the code necessary to prevent
that from happening and help us improve the security of OpenBSD and any
other OS that uses X11.
There's already rootless X on OpenBSD, it may prevent that? The thing is, I don't know. So I asked. And there's already efforts to replace X11 with Wayland, and already efforts to port Wayland to OpenBSD.
Coming here and saying that we are not attentive to security and that
Where did I say that? False accusation.
is why we "HAVE" to do something, is utter
Where did I say anybody has to do anything? False accusation.
idiocy. Start doing
something yourself, if you want to collaborate beyond a stupid speech.
"Speech"? These are important questions.
2.- Do you want a mechanism that prevents logins being stolen? Same
Why should I want something to be added when it might already exist and I'm missing it? Again, I asked.
story, start writing kid, crying at the list doesn't help.
Where did I "cry" or whine about OpenBSD? False accusation. Quite the contrary, I praised OpenBSD at various times, and I wouldn't have come here in the first place if I wouldn't have had appreciation for OpenBSD.
3.- Do you want more applications to have pledge/unveil to improve
Which "more" applications? I do not know whether this:
Is the exhaustive list of all third-party apps that are sandboxed with pledge/unveil. I asked whether people knew of other programs or whether it's possible to list other programs beyond that. It seems that you expect me to assume that these links list all sandboxed programs exhaustively, but I do not assume, I ask.
security? Same story...start writing the code necessary for it and stop
crying.
Where did I "cry" or whine about OpenBSD? False accusation.
Nobody is here to serve your designs or needs.
Which ones? I didn't know I had any.
Want something? Write it
down, it contributes to the project more than
What if it's already written down?
tantrums and tears.
Which ones?
My last and unique message in this thread: Don´t feed the fucking
troll!
In case you're referring to me feeding trolls rather than being the troll: Peter N. M. Hansteen said he blocked me after merely my second message in this thread. Because of his reputation, I lost sense of whether I'm perceived as a troll here.
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
El Sun, 31 Mar 2024 01:10:15 +0000
Dan <dan.peretz.my@gmail.com> escribió:
> On Wednesday, March 27, 2024, Dan <dan.peretz.my@gmail.com> wrote:
>
Hi @list!
Lots of discussion and useless talk when the solution is in your hands
@Dan:
1.- Are you worried about the fact that apps on X11 may suffer
input-spoofing? Great, start writing all the code necessary to prevent
that from happening and help us improve the security of OpenBSD and any
other OS that uses X11.
Coming here and saying that we are not attentive to security and that
is why we "HAVE" to do something, is utter idiocy. Start doing
something yourself, if you want to collaborate beyond a stupid speech.
2.- Do you want a mechanism that prevents logins being stolen? Same
story, start writing kid, crying at the list doesn't help.
3.- Do you want more applications to have pledge/unveil to improve
security? Same story...start writing the code necessary for it and stop
crying.
Nobody is here to serve your designs or needs. Want something? Write it
down, it contributes to the project more than tantrums and tears.
My last and unique message in this thread: Don´t feed the fucking
troll!
This thread to /dev/null
--
*********************************************************
Dios en su cielo, todo bien en la Tierra
Dan <dan.peretz.my@gmail.com> escribió:
> On Wednesday, March 27, 2024, Dan <dan.peretz.my@gmail.com> wrote:
>
Hi @list!
Lots of discussion and useless talk when the solution is in your hands
@Dan:
1.- Are you worried about the fact that apps on X11 may suffer
input-spoofing? Great, start writing all the code necessary to prevent
that from happening and help us improve the security of OpenBSD and any
other OS that uses X11.
Coming here and saying that we are not attentive to security and that
is why we "HAVE" to do something, is utter idiocy. Start doing
something yourself, if you want to collaborate beyond a stupid speech.
2.- Do you want a mechanism that prevents logins being stolen? Same
story, start writing kid, crying at the list doesn't help.
3.- Do you want more applications to have pledge/unveil to improve
security? Same story...start writing the code necessary for it and stop
crying.
Nobody is here to serve your designs or needs. Want something? Write it
down, it contributes to the project more than tantrums and tears.
My last and unique message in this thread: Don´t feed the fucking
troll!
This thread to /dev/null
--
*********************************************************
Dios en su cielo, todo bien en la Tierra
Re: small tweaks for editors/litexl
Le Sun, Mar 31, 2024 at 07:53:25PM +0200, Antoine Jacoutot a écrit :
> Hi.
>
> - install desktop files and icon
> - enable kqueue support
> - drop useless patch and use CONFIGURE_ARGS instead
> - don't hardcode lua version nor patch to lite-xl
>
> OK?
>
Thank you Antoine for the improvement.
OK denis@
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/editors/litexl/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile 11 Feb 2024 11:41:04 -0000 1.3
> +++ Makefile 31 Mar 2024 17:51:54 -0000
> @@ -5,6 +5,7 @@ GH_ACCOUNT = lite-xl
> GH_PROJECT = lite-xl
> GH_TAGNAME = v$V
> PKGNAME = litexl-$V
> +REVISION = 0
>
> CATEGORIES = editors
> HOMEPAGE = https://lite-xl.com
> @@ -26,5 +27,14 @@ MODLUA_VERSION =5.4
>
> LIB_DEPENDS = devel/sdl2 \
> devel/pcre2
> +
> +RUN_DEPENDS = devel/desktop-file-utils \
> + x11/gtk+4,-guic
> +
> +CONFIGURE_ARGS = -Duse_system_lua=true \
> + -Ddirmonitor_backend=kqueue
> +
> +pre-configure:
> + ${SUBST_CMD} ${WRKSRC}/{meson.build,src/main.c}
>
> .include <bsd.port.mk>
> Index: patches/patch-meson_build
> ===================================================================
> RCS file: /cvs/ports/editors/litexl/patches/patch-meson_build,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-meson_build
> --- patches/patch-meson_build 11 Feb 2024 11:41:04 -0000 1.2
> +++ patches/patch-meson_build 31 Mar 2024 17:51:54 -0000
> @@ -5,7 +5,16 @@ Index: meson.build
> # Lua has no official .pc file
> # so distros come up with their own names
> lua_names = [
> -+ 'lua54', # OpenBSD
> ++ 'lua${MODLUA_DEP_VERSION}', # OpenBSD
> 'lua5.4', # Debian
> 'lua-5.4', # FreeBSD
> 'lua', # Fedora
> +@@ -204,7 +205,7 @@ else
> + lite_bindir = 'bin'
> + lite_docdir = 'share/doc/lite-xl'
> + lite_datadir = 'share/lite-xl'
> +- if host_machine.system() == 'linux'
> ++ if host_machine.system() == 'linux' or host_machine.system() == 'openbsd'
> + install_data('resources/icons/lite-xl.svg',
> + install_dir : 'share/icons/hicolor/scalable/apps'
> + )
> Index: patches/patch-meson_options_txt
> ===================================================================
> RCS file: patches/patch-meson_options_txt
> diff -N patches/patch-meson_options_txt
> --- patches/patch-meson_options_txt 11 Feb 2024 11:41:04 -0000 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -0000
> @@ -1,9 +0,0 @@
> -Index: meson_options.txt
> ---- meson_options.txt.orig
> -+++ meson_options.txt
> -@@ -4,4 +4,4 @@ option('portable', type : 'boolean', value : false, de
> - option('renderer', type : 'boolean', value : false, description: 'Use SDL renderer')
> - option('dirmonitor_backend', type : 'combo', value : '', choices : ['', 'inotify', 'fsevents', 'kqueue', 'win32', 'dummy'], description: 'define what dirmonitor backend to use')
> - option('arch_tuple', type : 'string', value : '', description: 'Specify a custom architecture tuple')
> --option('use_system_lua', type : 'boolean', value : false, description: 'Prefer System Lua over a the meson wrap')
> -+option('use_system_lua', type : 'boolean', value : true, description: 'Prefer System Lua over a the meson wrap')
> Index: patches/patch-src_api_dirmonitor_kqueue_c
> ===================================================================
> RCS file: patches/patch-src_api_dirmonitor_kqueue_c
> diff -N patches/patch-src_api_dirmonitor_kqueue_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_api_dirmonitor_kqueue_c 31 Mar 2024 17:51:54 -0000
> @@ -0,0 +1,18 @@
> +Nove include so __uintptr_t gets defined when needed.
> +
> +Index: src/api/dirmonitor/kqueue.c
> +--- src/api/dirmonitor/kqueue.c.orig
> ++++ src/api/dirmonitor/kqueue.c
> +@@ -1,10 +1,10 @@
> +-#include <sys/event.h>
> +-#include <sys/stat.h>
> + #include <stdlib.h>
> + #include <errno.h>
> + #include <fcntl.h>
> + #include <unistd.h>
> + #include <time.h>
> ++#include <sys/event.h>
> ++#include <sys/stat.h>
> +
> + struct dirmonitor_internal {
> + int fd;
> Index: patches/patch-src_main_c
> ===================================================================
> RCS file: /cvs/ports/editors/litexl/patches/patch-src_main_c,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-src_main_c
> --- patches/patch-src_main_c 11 Feb 2024 11:41:04 -0000 1.2
> +++ patches/patch-src_main_c 31 Mar 2024 17:51:54 -0000
> @@ -9,7 +9,7 @@ Index: src/main.c
> + if (strchr(argv[0], '/') != NULL)
> + lua_pushstring(L, argv[0]);
> + else
> -+ lua_pushstring(L, "/usr/local/bin/lite-xl");
> ++ lua_pushstring(L, "${PREFIX}/bin/lite-xl");
> }
> lua_setglobal(L, "EXEFILE");
>
> Index: pkg/PLIST
> ===================================================================
> RCS file: /cvs/ports/editors/litexl/pkg/PLIST,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST
> --- pkg/PLIST 11 Feb 2024 11:41:04 -0000 1.2
> +++ pkg/PLIST 31 Mar 2024 17:51:54 -0000
> @@ -1,6 +1,8 @@
> @bin bin/lite-xl
> +share/applications/org.lite_xl.lite_xl.desktop
> share/doc/lite-xl/
> share/doc/lite-xl/licenses.md
> +share/icons/hicolor/scalable/apps/lite-xl.svg
> share/lite-xl/
> share/lite-xl/colors/
> share/lite-xl/colors/default.lua
> @@ -93,3 +95,7 @@ share/lite-xl/renderer.lua
> share/lite-xl/string.lua
> share/lite-xl/system.lua
> share/lite-xl/utf8extra.lua
> +share/metainfo/
> +share/metainfo/org.lite_xl.lite_xl.appdata.xml
> +@tag update-desktop-database
> +@tag gtk-update-icon-cache %D/share/icons/hicolor
>
>
> --
> Antoine
> Hi.
>
> - install desktop files and icon
> - enable kqueue support
> - drop useless patch and use CONFIGURE_ARGS instead
> - don't hardcode lua version nor patch to lite-xl
>
> OK?
>
Thank you Antoine for the improvement.
OK denis@
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/editors/litexl/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile 11 Feb 2024 11:41:04 -0000 1.3
> +++ Makefile 31 Mar 2024 17:51:54 -0000
> @@ -5,6 +5,7 @@ GH_ACCOUNT = lite-xl
> GH_PROJECT = lite-xl
> GH_TAGNAME = v$V
> PKGNAME = litexl-$V
> +REVISION = 0
>
> CATEGORIES = editors
> HOMEPAGE = https://lite-xl.com
> @@ -26,5 +27,14 @@ MODLUA_VERSION =5.4
>
> LIB_DEPENDS = devel/sdl2 \
> devel/pcre2
> +
> +RUN_DEPENDS = devel/desktop-file-utils \
> + x11/gtk+4,-guic
> +
> +CONFIGURE_ARGS = -Duse_system_lua=true \
> + -Ddirmonitor_backend=kqueue
> +
> +pre-configure:
> + ${SUBST_CMD} ${WRKSRC}/{meson.build,src/main.c}
>
> .include <bsd.port.mk>
> Index: patches/patch-meson_build
> ===================================================================
> RCS file: /cvs/ports/editors/litexl/patches/patch-meson_build,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-meson_build
> --- patches/patch-meson_build 11 Feb 2024 11:41:04 -0000 1.2
> +++ patches/patch-meson_build 31 Mar 2024 17:51:54 -0000
> @@ -5,7 +5,16 @@ Index: meson.build
> # Lua has no official .pc file
> # so distros come up with their own names
> lua_names = [
> -+ 'lua54', # OpenBSD
> ++ 'lua${MODLUA_DEP_VERSION}', # OpenBSD
> 'lua5.4', # Debian
> 'lua-5.4', # FreeBSD
> 'lua', # Fedora
> +@@ -204,7 +205,7 @@ else
> + lite_bindir = 'bin'
> + lite_docdir = 'share/doc/lite-xl'
> + lite_datadir = 'share/lite-xl'
> +- if host_machine.system() == 'linux'
> ++ if host_machine.system() == 'linux' or host_machine.system() == 'openbsd'
> + install_data('resources/icons/lite-xl.svg',
> + install_dir : 'share/icons/hicolor/scalable/apps'
> + )
> Index: patches/patch-meson_options_txt
> ===================================================================
> RCS file: patches/patch-meson_options_txt
> diff -N patches/patch-meson_options_txt
> --- patches/patch-meson_options_txt 11 Feb 2024 11:41:04 -0000 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -0000
> @@ -1,9 +0,0 @@
> -Index: meson_options.txt
> ---- meson_options.txt.orig
> -+++ meson_options.txt
> -@@ -4,4 +4,4 @@ option('portable', type : 'boolean', value : false, de
> - option('renderer', type : 'boolean', value : false, description: 'Use SDL renderer')
> - option('dirmonitor_backend', type : 'combo', value : '', choices : ['', 'inotify', 'fsevents', 'kqueue', 'win32', 'dummy'], description: 'define what dirmonitor backend to use')
> - option('arch_tuple', type : 'string', value : '', description: 'Specify a custom architecture tuple')
> --option('use_system_lua', type : 'boolean', value : false, description: 'Prefer System Lua over a the meson wrap')
> -+option('use_system_lua', type : 'boolean', value : true, description: 'Prefer System Lua over a the meson wrap')
> Index: patches/patch-src_api_dirmonitor_kqueue_c
> ===================================================================
> RCS file: patches/patch-src_api_dirmonitor_kqueue_c
> diff -N patches/patch-src_api_dirmonitor_kqueue_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-src_api_dirmonitor_kqueue_c 31 Mar 2024 17:51:54 -0000
> @@ -0,0 +1,18 @@
> +Nove include so __uintptr_t gets defined when needed.
> +
> +Index: src/api/dirmonitor/kqueue.c
> +--- src/api/dirmonitor/kqueue.c.orig
> ++++ src/api/dirmonitor/kqueue.c
> +@@ -1,10 +1,10 @@
> +-#include <sys/event.h>
> +-#include <sys/stat.h>
> + #include <stdlib.h>
> + #include <errno.h>
> + #include <fcntl.h>
> + #include <unistd.h>
> + #include <time.h>
> ++#include <sys/event.h>
> ++#include <sys/stat.h>
> +
> + struct dirmonitor_internal {
> + int fd;
> Index: patches/patch-src_main_c
> ===================================================================
> RCS file: /cvs/ports/editors/litexl/patches/patch-src_main_c,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-src_main_c
> --- patches/patch-src_main_c 11 Feb 2024 11:41:04 -0000 1.2
> +++ patches/patch-src_main_c 31 Mar 2024 17:51:54 -0000
> @@ -9,7 +9,7 @@ Index: src/main.c
> + if (strchr(argv[0], '/') != NULL)
> + lua_pushstring(L, argv[0]);
> + else
> -+ lua_pushstring(L, "/usr/local/bin/lite-xl");
> ++ lua_pushstring(L, "${PREFIX}/bin/lite-xl");
> }
> lua_setglobal(L, "EXEFILE");
>
> Index: pkg/PLIST
> ===================================================================
> RCS file: /cvs/ports/editors/litexl/pkg/PLIST,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST
> --- pkg/PLIST 11 Feb 2024 11:41:04 -0000 1.2
> +++ pkg/PLIST 31 Mar 2024 17:51:54 -0000
> @@ -1,6 +1,8 @@
> @bin bin/lite-xl
> +share/applications/org.lite_xl.lite_xl.desktop
> share/doc/lite-xl/
> share/doc/lite-xl/licenses.md
> +share/icons/hicolor/scalable/apps/lite-xl.svg
> share/lite-xl/
> share/lite-xl/colors/
> share/lite-xl/colors/default.lua
> @@ -93,3 +95,7 @@ share/lite-xl/renderer.lua
> share/lite-xl/string.lua
> share/lite-xl/system.lua
> share/lite-xl/utf8extra.lua
> +share/metainfo/
> +share/metainfo/org.lite_xl.lite_xl.appdata.xml
> +@tag update-desktop-database
> +@tag gtk-update-icon-cache %D/share/icons/hicolor
>
>
> --
> Antoine
small tweaks for editors/litexl
Hi.
- install desktop files and icon
- enable kqueue support
- drop useless patch and use CONFIGURE_ARGS instead
- don't hardcode lua version nor patch to lite-xl
OK?
Index: Makefile
===================================================================
RCS file: /cvs/ports/editors/litexl/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile 11 Feb 2024 11:41:04 -0000 1.3
+++ Makefile 31 Mar 2024 17:51:54 -0000
@@ -5,6 +5,7 @@ GH_ACCOUNT = lite-xl
GH_PROJECT = lite-xl
GH_TAGNAME = v$V
PKGNAME = litexl-$V
+REVISION = 0
CATEGORIES = editors
HOMEPAGE = https://lite-xl.com
@@ -26,5 +27,14 @@ MODLUA_VERSION =5.4
LIB_DEPENDS = devel/sdl2 \
devel/pcre2
+
+RUN_DEPENDS = devel/desktop-file-utils \
+ x11/gtk+4,-guic
+
+CONFIGURE_ARGS = -Duse_system_lua=true \
+ -Ddirmonitor_backend=kqueue
+
+pre-configure:
+ ${SUBST_CMD} ${WRKSRC}/{meson.build,src/main.c}
.include <bsd.port.mk>
Index: patches/patch-meson_build
===================================================================
RCS file: /cvs/ports/editors/litexl/patches/patch-meson_build,v
retrieving revision 1.2
diff -u -p -r1.2 patch-meson_build
--- patches/patch-meson_build 11 Feb 2024 11:41:04 -0000 1.2
+++ patches/patch-meson_build 31 Mar 2024 17:51:54 -0000
@@ -5,7 +5,16 @@ Index: meson.build
# Lua has no official .pc file
# so distros come up with their own names
lua_names = [
-+ 'lua54', # OpenBSD
++ 'lua${MODLUA_DEP_VERSION}', # OpenBSD
'lua5.4', # Debian
'lua-5.4', # FreeBSD
'lua', # Fedora
+@@ -204,7 +205,7 @@ else
+ lite_bindir = 'bin'
+ lite_docdir = 'share/doc/lite-xl'
+ lite_datadir = 'share/lite-xl'
+- if host_machine.system() == 'linux'
++ if host_machine.system() == 'linux' or host_machine.system() == 'openbsd'
+ install_data('resources/icons/lite-xl.svg',
+ install_dir : 'share/icons/hicolor/scalable/apps'
+ )
Index: patches/patch-meson_options_txt
===================================================================
RCS file: patches/patch-meson_options_txt
diff -N patches/patch-meson_options_txt
--- patches/patch-meson_options_txt 11 Feb 2024 11:41:04 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,9 +0,0 @@
-Index: meson_options.txt
---- meson_options.txt.orig
-+++ meson_options.txt
-@@ -4,4 +4,4 @@ option('portable', type : 'boolean', value : false, de
- option('renderer', type : 'boolean', value : false, description: 'Use SDL renderer')
- option('dirmonitor_backend', type : 'combo', value : '', choices : ['', 'inotify', 'fsevents', 'kqueue', 'win32', 'dummy'], description: 'define what dirmonitor backend to use')
- option('arch_tuple', type : 'string', value : '', description: 'Specify a custom architecture tuple')
--option('use_system_lua', type : 'boolean', value : false, description: 'Prefer System Lua over a the meson wrap')
-+option('use_system_lua', type : 'boolean', value : true, description: 'Prefer System Lua over a the meson wrap')
Index: patches/patch-src_api_dirmonitor_kqueue_c
===================================================================
RCS file: patches/patch-src_api_dirmonitor_kqueue_c
diff -N patches/patch-src_api_dirmonitor_kqueue_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_api_dirmonitor_kqueue_c 31 Mar 2024 17:51:54 -0000
@@ -0,0 +1,18 @@
+Nove include so __uintptr_t gets defined when needed.
+
+Index: src/api/dirmonitor/kqueue.c
+--- src/api/dirmonitor/kqueue.c.orig
++++ src/api/dirmonitor/kqueue.c
+@@ -1,10 +1,10 @@
+-#include <sys/event.h>
+-#include <sys/stat.h>
+ #include <stdlib.h>
+ #include <errno.h>
+ #include <fcntl.h>
+ #include <unistd.h>
+ #include <time.h>
++#include <sys/event.h>
++#include <sys/stat.h>
+
+ struct dirmonitor_internal {
+ int fd;
Index: patches/patch-src_main_c
===================================================================
RCS file: /cvs/ports/editors/litexl/patches/patch-src_main_c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-src_main_c
--- patches/patch-src_main_c 11 Feb 2024 11:41:04 -0000 1.2
+++ patches/patch-src_main_c 31 Mar 2024 17:51:54 -0000
@@ -9,7 +9,7 @@ Index: src/main.c
+ if (strchr(argv[0], '/') != NULL)
+ lua_pushstring(L, argv[0]);
+ else
-+ lua_pushstring(L, "/usr/local/bin/lite-xl");
++ lua_pushstring(L, "${PREFIX}/bin/lite-xl");
}
lua_setglobal(L, "EXEFILE");
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/editors/litexl/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 11 Feb 2024 11:41:04 -0000 1.2
+++ pkg/PLIST 31 Mar 2024 17:51:54 -0000
@@ -1,6 +1,8 @@
@bin bin/lite-xl
+share/applications/org.lite_xl.lite_xl.desktop
share/doc/lite-xl/
share/doc/lite-xl/licenses.md
+share/icons/hicolor/scalable/apps/lite-xl.svg
share/lite-xl/
share/lite-xl/colors/
share/lite-xl/colors/default.lua
@@ -93,3 +95,7 @@ share/lite-xl/renderer.lua
share/lite-xl/string.lua
share/lite-xl/system.lua
share/lite-xl/utf8extra.lua
+share/metainfo/
+share/metainfo/org.lite_xl.lite_xl.appdata.xml
+@tag update-desktop-database
+@tag gtk-update-icon-cache %D/share/icons/hicolor
--
Antoine
- install desktop files and icon
- enable kqueue support
- drop useless patch and use CONFIGURE_ARGS instead
- don't hardcode lua version nor patch to lite-xl
OK?
Index: Makefile
===================================================================
RCS file: /cvs/ports/editors/litexl/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile 11 Feb 2024 11:41:04 -0000 1.3
+++ Makefile 31 Mar 2024 17:51:54 -0000
@@ -5,6 +5,7 @@ GH_ACCOUNT = lite-xl
GH_PROJECT = lite-xl
GH_TAGNAME = v$V
PKGNAME = litexl-$V
+REVISION = 0
CATEGORIES = editors
HOMEPAGE = https://lite-xl.com
@@ -26,5 +27,14 @@ MODLUA_VERSION =5.4
LIB_DEPENDS = devel/sdl2 \
devel/pcre2
+
+RUN_DEPENDS = devel/desktop-file-utils \
+ x11/gtk+4,-guic
+
+CONFIGURE_ARGS = -Duse_system_lua=true \
+ -Ddirmonitor_backend=kqueue
+
+pre-configure:
+ ${SUBST_CMD} ${WRKSRC}/{meson.build,src/main.c}
.include <bsd.port.mk>
Index: patches/patch-meson_build
===================================================================
RCS file: /cvs/ports/editors/litexl/patches/patch-meson_build,v
retrieving revision 1.2
diff -u -p -r1.2 patch-meson_build
--- patches/patch-meson_build 11 Feb 2024 11:41:04 -0000 1.2
+++ patches/patch-meson_build 31 Mar 2024 17:51:54 -0000
@@ -5,7 +5,16 @@ Index: meson.build
# Lua has no official .pc file
# so distros come up with their own names
lua_names = [
-+ 'lua54', # OpenBSD
++ 'lua${MODLUA_DEP_VERSION}', # OpenBSD
'lua5.4', # Debian
'lua-5.4', # FreeBSD
'lua', # Fedora
+@@ -204,7 +205,7 @@ else
+ lite_bindir = 'bin'
+ lite_docdir = 'share/doc/lite-xl'
+ lite_datadir = 'share/lite-xl'
+- if host_machine.system() == 'linux'
++ if host_machine.system() == 'linux' or host_machine.system() == 'openbsd'
+ install_data('resources/icons/lite-xl.svg',
+ install_dir : 'share/icons/hicolor/scalable/apps'
+ )
Index: patches/patch-meson_options_txt
===================================================================
RCS file: patches/patch-meson_options_txt
diff -N patches/patch-meson_options_txt
--- patches/patch-meson_options_txt 11 Feb 2024 11:41:04 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,9 +0,0 @@
-Index: meson_options.txt
---- meson_options.txt.orig
-+++ meson_options.txt
-@@ -4,4 +4,4 @@ option('portable', type : 'boolean', value : false, de
- option('renderer', type : 'boolean', value : false, description: 'Use SDL renderer')
- option('dirmonitor_backend', type : 'combo', value : '', choices : ['', 'inotify', 'fsevents', 'kqueue', 'win32', 'dummy'], description: 'define what dirmonitor backend to use')
- option('arch_tuple', type : 'string', value : '', description: 'Specify a custom architecture tuple')
--option('use_system_lua', type : 'boolean', value : false, description: 'Prefer System Lua over a the meson wrap')
-+option('use_system_lua', type : 'boolean', value : true, description: 'Prefer System Lua over a the meson wrap')
Index: patches/patch-src_api_dirmonitor_kqueue_c
===================================================================
RCS file: patches/patch-src_api_dirmonitor_kqueue_c
diff -N patches/patch-src_api_dirmonitor_kqueue_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_api_dirmonitor_kqueue_c 31 Mar 2024 17:51:54 -0000
@@ -0,0 +1,18 @@
+Nove include so __uintptr_t gets defined when needed.
+
+Index: src/api/dirmonitor/kqueue.c
+--- src/api/dirmonitor/kqueue.c.orig
++++ src/api/dirmonitor/kqueue.c
+@@ -1,10 +1,10 @@
+-#include <sys/event.h>
+-#include <sys/stat.h>
+ #include <stdlib.h>
+ #include <errno.h>
+ #include <fcntl.h>
+ #include <unistd.h>
+ #include <time.h>
++#include <sys/event.h>
++#include <sys/stat.h>
+
+ struct dirmonitor_internal {
+ int fd;
Index: patches/patch-src_main_c
===================================================================
RCS file: /cvs/ports/editors/litexl/patches/patch-src_main_c,v
retrieving revision 1.2
diff -u -p -r1.2 patch-src_main_c
--- patches/patch-src_main_c 11 Feb 2024 11:41:04 -0000 1.2
+++ patches/patch-src_main_c 31 Mar 2024 17:51:54 -0000
@@ -9,7 +9,7 @@ Index: src/main.c
+ if (strchr(argv[0], '/') != NULL)
+ lua_pushstring(L, argv[0]);
+ else
-+ lua_pushstring(L, "/usr/local/bin/lite-xl");
++ lua_pushstring(L, "${PREFIX}/bin/lite-xl");
}
lua_setglobal(L, "EXEFILE");
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/editors/litexl/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 11 Feb 2024 11:41:04 -0000 1.2
+++ pkg/PLIST 31 Mar 2024 17:51:54 -0000
@@ -1,6 +1,8 @@
@bin bin/lite-xl
+share/applications/org.lite_xl.lite_xl.desktop
share/doc/lite-xl/
share/doc/lite-xl/licenses.md
+share/icons/hicolor/scalable/apps/lite-xl.svg
share/lite-xl/
share/lite-xl/colors/
share/lite-xl/colors/default.lua
@@ -93,3 +95,7 @@ share/lite-xl/renderer.lua
share/lite-xl/string.lua
share/lite-xl/system.lua
share/lite-xl/utf8extra.lua
+share/metainfo/
+share/metainfo/org.lite_xl.lite_xl.appdata.xml
+@tag update-desktop-database
+@tag gtk-update-icon-cache %D/share/icons/hicolor
--
Antoine
[Update] www/gallery-dl-1.26.9
Attached is an update for gallery-dl to version 1.26.9. Tested on amd64.
Changelog: https://github.com/mikf/gallery-dl/releases/tag/v1.26.9
-grodzio1
Index: Makefile
===================================================================
RCS file: /cvs/ports/www/gallery-dl/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile 26 Jan 2024 06:42:41 -0000 1.6
+++ Makefile 31 Mar 2024 15:24:47 -0000
@@ -1,6 +1,6 @@
COMMENT = CLI program to mass download images from various websites
-MODPY_EGG_VERSION = 1.26.7
+MODPY_EGG_VERSION = 1.26.9
DISTNAME = gallery_dl-${MODPY_EGG_VERSION}
PKGNAME = ${DISTNAME:S/_/-/}
CATEGORIES = www
Index: distinfo
===================================================================
RCS file: /cvs/ports/www/gallery-dl/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo 26 Jan 2024 06:42:41 -0000 1.6
+++ distinfo 31 Mar 2024 15:24:47 -0000
@@ -1,2 +1,2 @@
-SHA256 (gallery_dl-1.26.7.tar.gz) = +aoXcxJVBp9nXKS+3+CG7XkDMemSgvExMXtnR2FDhYs=
-SIZE (gallery_dl-1.26.7.tar.gz) = 493678
+SHA256 (gallery_dl-1.26.9.tar.gz) = PgbfppyJCpgFupBQng8MUPihbDmit4C+xWnSzCJyu5k=
+SIZE (gallery_dl-1.26.9.tar.gz) = 505390
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/www/gallery-dl/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST 26 Jan 2024 06:42:41 -0000 1.6
+++ pkg/PLIST 31 Mar 2024 15:24:47 -0000
@@ -123,6 +123,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}behance.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}blogger.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}blogger.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}bluesky.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}bluesky.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}booru.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}booru.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}bunkr.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -397,8 +399,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}tcbscans.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}telegraph.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}telegraph.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}test.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
-lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}test.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}tmohentai.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}tmohentai.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}toyhouse.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -469,6 +469,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/bbc.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/behance.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/blogger.py
+lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/bluesky.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/booru.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/bunkr.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/catbox.py
@@ -606,7 +607,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/tapas.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/tcbscans.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/telegraph.py
-lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/test.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/tmohentai.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/toyhouse.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/tsumino.py
Changelog: https://github.com/mikf/gallery-dl/releases/tag/v1.26.9
-grodzio1
Index: Makefile
===================================================================
RCS file: /cvs/ports/www/gallery-dl/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile 26 Jan 2024 06:42:41 -0000 1.6
+++ Makefile 31 Mar 2024 15:24:47 -0000
@@ -1,6 +1,6 @@
COMMENT = CLI program to mass download images from various websites
-MODPY_EGG_VERSION = 1.26.7
+MODPY_EGG_VERSION = 1.26.9
DISTNAME = gallery_dl-${MODPY_EGG_VERSION}
PKGNAME = ${DISTNAME:S/_/-/}
CATEGORIES = www
Index: distinfo
===================================================================
RCS file: /cvs/ports/www/gallery-dl/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo 26 Jan 2024 06:42:41 -0000 1.6
+++ distinfo 31 Mar 2024 15:24:47 -0000
@@ -1,2 +1,2 @@
-SHA256 (gallery_dl-1.26.7.tar.gz) = +aoXcxJVBp9nXKS+3+CG7XkDMemSgvExMXtnR2FDhYs=
-SIZE (gallery_dl-1.26.7.tar.gz) = 493678
+SHA256 (gallery_dl-1.26.9.tar.gz) = PgbfppyJCpgFupBQng8MUPihbDmit4C+xWnSzCJyu5k=
+SIZE (gallery_dl-1.26.9.tar.gz) = 505390
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/www/gallery-dl/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST 26 Jan 2024 06:42:41 -0000 1.6
+++ pkg/PLIST 31 Mar 2024 15:24:47 -0000
@@ -123,6 +123,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}behance.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}blogger.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}blogger.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}bluesky.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}bluesky.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}booru.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}booru.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}bunkr.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -397,8 +399,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}tcbscans.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}telegraph.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}telegraph.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}test.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
-lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}test.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}tmohentai.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}tmohentai.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/${MODPY_PYCACHE}toyhouse.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -469,6 +469,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/bbc.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/behance.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/blogger.py
+lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/bluesky.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/booru.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/bunkr.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/catbox.py
@@ -606,7 +607,6 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/tapas.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/tcbscans.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/telegraph.py
-lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/test.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/tmohentai.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/toyhouse.py
lib/python${MODPY_VERSION}/site-packages/gallery_dl/extractor/tsumino.py
Booting with secure boot enabled
Is it possible to boot OpenBSD with secure boot enabled?
I'd like to try unattended installation over WiFi on ThinkPad X1 and
my UEFI firmware supports PXE over WiFi, but it works only in Secure
Boot mode.
Best regards,
Chris Narkiewicz
I'd like to try unattended installation over WiFi on ThinkPad X1 and
my UEFI firmware supports PXE over WiFi, but it works only in Secure
Boot mode.
Best regards,
Chris Narkiewicz
Re: silence logging of dhcpd deny unknown-clients
> Is there any way to silence these logs? I only want to hand out a
> small number of IPv4 addresses on my IPv6 network to those machines
> that won't function properly without them. That leaves many machines
> on my network constantly requesting IPv4 addresses, and dhcpd is
> clogging my /var/log/daemon file:
>
>> ... dhcpd[13399]: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via igc3
>> ... dhcpd[13399]: no free leases on subnet 192.168.3.0
>
> ... over and over and over again.
>
> I didn't see any logging options in dhcpd(8) or dhcpd.conf(5).
I wasn't able to figure out how silence specific messages from a given
daemon at a specific level. I read up on syslog.conf(5) and saw that I
could silence all warnings from dhcpd, but I don't want to do thatâ€"just
those for this specific directive.
In the meantime, I realized that my list of machines that need IPv4
addresses is so small I'm probably better off statically-assigning those
machines their addresses instead of running dhcpd at all, so I've done
that.
If there is a way to silence a log message from a "facility" at a given
"level" without affecting other messages at the same "facility" and
"level," I'd be curious to know, as I'm sure I'll run into this issue
again with something else.
> small number of IPv4 addresses on my IPv6 network to those machines
> that won't function properly without them. That leaves many machines
> on my network constantly requesting IPv4 addresses, and dhcpd is
> clogging my /var/log/daemon file:
>
>> ... dhcpd[13399]: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via igc3
>> ... dhcpd[13399]: no free leases on subnet 192.168.3.0
>
> ... over and over and over again.
>
> I didn't see any logging options in dhcpd(8) or dhcpd.conf(5).
I wasn't able to figure out how silence specific messages from a given
daemon at a specific level. I read up on syslog.conf(5) and saw that I
could silence all warnings from dhcpd, but I don't want to do thatâ€"just
those for this specific directive.
In the meantime, I realized that my list of machines that need IPv4
addresses is so small I'm probably better off statically-assigning those
machines their addresses instead of running dhcpd at all, so I've done
that.
If there is a way to silence a log message from a "facility" at a given
"level" without affecting other messages at the same "facility" and
"level," I'd be curious to know, as I'm sure I'll run into this issue
again with something else.
Re: configure rad for ULA addresses
Ok, think I figured it out.
My core problem was that I was assigning prefixes manually in rad.conf,
then assigning each interface an address *in the same prefix*. This
created some kind of conflictâ€"the nature of which I still don't fully
understand.
This was the key line I missed in rad.conf(5):
> The default is to discover prefixes to announce by inspecting the IPv6
> addresses configured on an interface.
So as long as my interface has both addresses assigned in their
respective prefixes, rad can serve those without any extra
configuration.
Here's my final /etc/hostname.igc1:
inet 192.168.1.1 255.255.255.0 NONE
inet6 autoconf
inet6 alias fdd0:c720:85fa:100::1 64
And my final /etc/rad.conf:
interface igc1 {
dns {
nameserver {
fdd0:c720:85fa:100::1
}
}
}
Now devices on my network are getting both GUA and ULA addresses
assigned automatically through SLAAC.
My core problem was that I was assigning prefixes manually in rad.conf,
then assigning each interface an address *in the same prefix*. This
created some kind of conflictâ€"the nature of which I still don't fully
understand.
This was the key line I missed in rad.conf(5):
> The default is to discover prefixes to announce by inspecting the IPv6
> addresses configured on an interface.
So as long as my interface has both addresses assigned in their
respective prefixes, rad can serve those without any extra
configuration.
Here's my final /etc/hostname.igc1:
inet 192.168.1.1 255.255.255.0 NONE
inet6 autoconf
inet6 alias fdd0:c720:85fa:100::1 64
And my final /etc/rad.conf:
interface igc1 {
dns {
nameserver {
fdd0:c720:85fa:100::1
}
}
}
Now devices on my network are getting both GUA and ULA addresses
assigned automatically through SLAAC.
Re: Minimum viable HW for OpenBSD
On 3/30/24 14:18, Peter J. Philipp wrote:
>
> PS: I'll probably do this next week I have a need for different
> hardware in my 9U rackmount cabinet. And one particular one needs
> powercycles (and possibly console) as well. It's the mango pi, which
> is currently in panic mode most likely or it's hung up, I was building
> ports on it and the 100 Mbit connection went down.
Hi,
I rebooted the mango pi, btw and I've enabled the watchdogd, hoping it
will work. It's awesome that sxidog(4) configures on these!
Best,
-pjp
>
> PS: I'll probably do this next week I have a need for different
> hardware in my 9U rackmount cabinet. And one particular one needs
> powercycles (and possibly console) as well. It's the mango pi, which
> is currently in panic mode most likely or it's hung up, I was building
> ports on it and the 100 Mbit connection went down.
Hi,
I rebooted the mango pi, btw and I've enabled the watchdogd, hoping it
will work. It's awesome that sxidog(4) configures on these!
Best,
-pjp
Re: No coloring with colorls
This method also works! Instead of vt220 I now used xterm-256color.
Thank you!
Op 30-03-2024 om 11:51 schreef Stuart Henderson:
> On 2024-03-29, Karel Lucas <cahlucas@planet.nl> wrote:
>> What should I put in /etc/ttys, taking into account that I regularly use
>> multiple virtual consoles? And where in that file do I place that? At
>> the beginning or the end? Or somewhere in between?
> Replace "vt220" with your preferred option on "console" and "ttyC" lines.
>
>
Thank you!
Op 30-03-2024 om 11:51 schreef Stuart Henderson:
> On 2024-03-29, Karel Lucas <cahlucas@planet.nl> wrote:
>> What should I put in /etc/ttys, taking into account that I regularly use
>> multiple virtual consoles? And where in that file do I place that? At
>> the beginning or the end? Or somewhere in between?
> Replace "vt220" with your preferred option on "console" and "ttyC" lines.
>
>
Today's snapshot brokes some Qt app?
Folks,
I just run: pkg_add -D snap -u
After that I've discovered that some Qt apps are crashing with errors like:
Cannot add multiple registrations for QtQuick
Abort trap (core dumped)
for example telegram-desktop crashes but wireshark doesn't.
--
wbr, Kirill
I just run: pkg_add -D snap -u
After that I've discovered that some Qt apps are crashing with errors like:
Cannot add multiple registrations for QtQuick
Abort trap (core dumped)
for example telegram-desktop crashes but wireshark doesn't.
--
wbr, Kirill
[update] wayfire 0.8.1
Index: Makefile
===================================================================
RCS file: /cvs/ports/wayland/wayfire/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile 11 Jan 2024 09:48:05 -0000 1.6
+++ Makefile 31 Mar 2024 10:12:47 -0000
@@ -1,15 +1,7 @@
COMMENT = modular and extensible wayland compositor
-V = 0.8.0pl17
+V = 0.8.1
DISTNAME = wayfire-${V}
-GH_ACCOUNT = WayfireWM
-GH_PROJECT = wayfire
-GH_COMMIT = c48194e055219dcb3a603b59ca37f330a64cac12
-REVISION = 1
-
-# git submodules when not building a release
-DIST_TUPLE += github ${GH_ACCOUNT} wf-utils 15f8e16721585ae3eaf278ba71d7064237eb23f5 subprojects/wf-utils
-DIST_TUPLE += github ${GH_ACCOUNT} wf-touch 8974eb0f6a65464b63dd03b842795cb441fb6403 subprojects/wf-touch
SHARED_LIBS += wf-utils 0.0 # 0.0
CATEGORIES = wayland
@@ -18,11 +10,8 @@
# MIT
PERMIT_PACKAGE = Yes
-# we need to use a git branch because last release doesnt support wlroots 0.17 yet
-# https://github.com/WayfireWM/wayfire/issues/1781
-# https://github.com/WayfireWM/wayfire/pull/2024
-#SITES = https://github.com/WayfireWM/wayfire/releases/download/v${V}/
-#EXTRACT_SUFX = .tar.xz
+SITES = https://github.com/WayfireWM/wayfire/releases/download/v${V}/
+EXTRACT_SUFX = .tar.xz
HOMEPAGE = https://wayfire.org
MODULES = devel/meson
Index: distinfo
===================================================================
RCS file: /cvs/ports/wayland/wayfire/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- distinfo 21 Dec 2023 16:22:14 -0000 1.1.1.1
+++ distinfo 31 Mar 2024 10:12:47 -0000
@@ -1,6 +1,2 @@
-SHA256 (WayfireWM-wf-touch-8974eb0f6a65464b63dd03b842795cb441fb6403.tar.gz) = CQYcik09lk6Nz9GnuX99xD0PwwdDsJk1hUOcaSPOQi8=
-SHA256 (WayfireWM-wf-utils-15f8e16721585ae3eaf278ba71d7064237eb23f5.tar.gz) = XwoPUjspvXPg8R1jB5MV06Cjw8rmzptVfgQz4ltaDZI=
-SHA256 (wayfire-0.8.0pl17-c48194e0.tar.gz) = Rdw3AIQIij/t0VNd8oDa15eIOO8jS1vIVmGb97vwus8=
-SIZE (WayfireWM-wf-touch-8974eb0f6a65464b63dd03b842795cb441fb6403.tar.gz) = 9874
-SIZE (WayfireWM-wf-utils-15f8e16721585ae3eaf278ba71d7064237eb23f5.tar.gz) = 48535
-SIZE (wayfire-0.8.0pl17-c48194e0.tar.gz) = 437555
+SHA256 (wayfire-0.8.1.tar.xz) = isGUe2iKnsbE2e4tdzEbs1eo6tJWZbgADtqWlSMoKQ0=
+SIZE (wayfire-0.8.1.tar.xz) = 856364
Index: patches/patch-meson_build
===================================================================
RCS file: /cvs/ports/wayland/wayfire/patches/patch-meson_build,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-meson_build
--- patches/patch-meson_build 21 Dec 2023 16:22:14 -0000 1.1.1.1
+++ patches/patch-meson_build 31 Mar 2024 10:12:47 -0000
@@ -1,7 +1,7 @@
Index: meson.build
--- meson.build.orig
+++ meson.build
-@@ -30,7 +30,6 @@ libinput = dependency('libinput', version: '>=1.
+@@ -33,7 +33,6 @@ libinput = dependency('libinput', version: '>=1.
pixman = dependency('pixman-1')
threads = dependency('threads')
xkbcommon = dependency('xkbcommon')
@@ -9,16 +9,7 @@
# We're not to use system wlroots: So we'll use the subproject
if get_option('use_system_wlroots').disabled()
-@@ -58,7 +57,7 @@ if get_option('use_system_wfconfig').disabled()
-
- elif get_option('use_system_wfconfig').enabled()
- use_system_wfconfig = true
-- wfconfig = dependency('wf-config', version: ['>=0.9.0', '<0.10.0'], required: true)
-+ wfconfig = dependency('wf-config', version: ['>=0.8.0', '<0.10.0'], required: true)
-
- elif get_option('use_system_wfconfig').auto()
- wfconfig = dependency('wf-config', version: ['>=0.9.0', '<0.10.0'], required: false)
-@@ -72,7 +71,7 @@ endif
+@@ -75,7 +74,7 @@ endif
wfutils = subproject('wf-utils').get_variable('wfutils')
wftouch = subproject('wf-touch').get_variable('wftouch')
@@ -27,22 +18,3 @@
libinotify = dependency('libinotify', required: needs_libinotify)
jpeg = dependency('libjpeg', required: false)
-@@ -84,18 +83,6 @@ backtrace = meson.get_compiler('cpp').find_library('ex
- conf_data = configuration_data()
-
- version = '"@0@"'.format(meson.project_version())
--git = find_program('git', native: true, required: false)
--if git.found()
-- git_commit = run_command([git, 'rev-parse', '--short', 'HEAD'], check: false)
-- git_branch = run_command([git, 'rev-parse', '--abbrev-ref', 'HEAD'], check: false)
-- if git_commit.returncode() == 0 and git_branch.returncode() == 0
-- version = '"@0@-@1@ (" __DATE__ ", branch \'@2@\')"'.format(
-- meson.project_version(),
-- git_commit.stdout().strip(),
-- git_branch.stdout().strip(),
-- )
-- endif
--endif
- add_project_arguments('-DWAYFIRE_VERSION=@0@'.format(version), language: 'cpp')
- conf_data.set('WAYFIRE_VERSION', '-DWAYFIRE_VERSION=@0@'.format(version))
-
Index: patches/patch-src_meson_build
===================================================================
RCS file: /cvs/ports/wayland/wayfire/patches/patch-src_meson_build,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-src_meson_build
--- patches/patch-src_meson_build 21 Dec 2023 16:22:14 -0000 1.1.1.1
+++ patches/patch-src_meson_build 31 Mar 2024 10:12:47 -0000
@@ -3,7 +3,7 @@
Index: src/meson.build
--- src/meson.build.orig
+++ src/meson.build
-@@ -62,7 +62,7 @@ wayfire_sources = ['geometry.cpp',
+@@ -63,7 +63,7 @@ wayfire_sources = ['geometry.cpp',
'output/workspace-impl.cpp']
wayfire_dependencies = [wayland_server, wlroots, xkbcommon, libinput,
@@ -12,7 +12,7 @@
wfconfig, libinotify, backtrace, wfutils, xcb, wftouch]
if conf_data.get('BUILD_WITH_IMAGEIO')
-@@ -114,6 +114,7 @@ shared_module('default-config-backend', 'default-confi
+@@ -131,6 +131,7 @@ shared_module('default-config-backend', 'default-confi
dependencies: wayfire_dependencies,
include_directories: [wayfire_conf_inc, wayfire_api_inc],
cpp_args: debug_arguments,
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/wayland/wayfire/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 PLIST
--- pkg/PLIST 21 Dec 2023 16:22:14 -0000 1.1.1.1
+++ pkg/PLIST 31 Mar 2024 10:12:47 -0000
@@ -64,7 +64,6 @@
include/wayfire/plugins/ipc/ipc-activator.hpp
include/wayfire/plugins/ipc/ipc-helpers.hpp
include/wayfire/plugins/ipc/ipc-method-repository.hpp
-include/wayfire/plugins/ipc/ipc.hpp
include/wayfire/plugins/scale-signal.hpp
include/wayfire/plugins/vswitch.hpp
include/wayfire/plugins/wm-actions-signals.hpp
@@ -93,6 +92,7 @@
include/wayfire/unstable/
include/wayfire/unstable/translation-node.hpp
include/wayfire/unstable/wlr-surface-node.hpp
+include/wayfire/unstable/wlr-text-input-v3-popup.hpp
include/wayfire/unstable/wlr-view-events.hpp
include/wayfire/unstable/wlr-view-keyboard-interaction.hpp
include/wayfire/unstable/xdg-toplevel-base.hpp
@@ -131,6 +131,7 @@
@so lib/wayfire/libgrid.so
@so lib/wayfire/libgtk-shell.so
@so lib/wayfire/libidle.so
+@so lib/wayfire/libinput-method-v1.so
@so lib/wayfire/libinvert.so
@so lib/wayfire/libipc-rules.so
@so lib/wayfire/libipc.so
@@ -177,6 +178,7 @@
share/wayfire/metadata/gtk-shell.xml
share/wayfire/metadata/idle.xml
share/wayfire/metadata/input-device.xml
+share/wayfire/metadata/input-method-v1.xml
share/wayfire/metadata/input.xml
share/wayfire/metadata/invert.xml
share/wayfire/metadata/ipc-rules.xml
hi,
little update to wayfire 0.8.1, simplifies a bit the port since we can
now build from a release. have a local problem on my wayland testing
laptop so havent been able to run it, but tests are welcome.
Landry
===================================================================
RCS file: /cvs/ports/wayland/wayfire/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- Makefile 11 Jan 2024 09:48:05 -0000 1.6
+++ Makefile 31 Mar 2024 10:12:47 -0000
@@ -1,15 +1,7 @@
COMMENT = modular and extensible wayland compositor
-V = 0.8.0pl17
+V = 0.8.1
DISTNAME = wayfire-${V}
-GH_ACCOUNT = WayfireWM
-GH_PROJECT = wayfire
-GH_COMMIT = c48194e055219dcb3a603b59ca37f330a64cac12
-REVISION = 1
-
-# git submodules when not building a release
-DIST_TUPLE += github ${GH_ACCOUNT} wf-utils 15f8e16721585ae3eaf278ba71d7064237eb23f5 subprojects/wf-utils
-DIST_TUPLE += github ${GH_ACCOUNT} wf-touch 8974eb0f6a65464b63dd03b842795cb441fb6403 subprojects/wf-touch
SHARED_LIBS += wf-utils 0.0 # 0.0
CATEGORIES = wayland
@@ -18,11 +10,8 @@
# MIT
PERMIT_PACKAGE = Yes
-# we need to use a git branch because last release doesnt support wlroots 0.17 yet
-# https://github.com/WayfireWM/wayfire/issues/1781
-# https://github.com/WayfireWM/wayfire/pull/2024
-#SITES = https://github.com/WayfireWM/wayfire/releases/download/v${V}/
-#EXTRACT_SUFX = .tar.xz
+SITES = https://github.com/WayfireWM/wayfire/releases/download/v${V}/
+EXTRACT_SUFX = .tar.xz
HOMEPAGE = https://wayfire.org
MODULES = devel/meson
Index: distinfo
===================================================================
RCS file: /cvs/ports/wayland/wayfire/distinfo,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 distinfo
--- distinfo 21 Dec 2023 16:22:14 -0000 1.1.1.1
+++ distinfo 31 Mar 2024 10:12:47 -0000
@@ -1,6 +1,2 @@
-SHA256 (WayfireWM-wf-touch-8974eb0f6a65464b63dd03b842795cb441fb6403.tar.gz) = CQYcik09lk6Nz9GnuX99xD0PwwdDsJk1hUOcaSPOQi8=
-SHA256 (WayfireWM-wf-utils-15f8e16721585ae3eaf278ba71d7064237eb23f5.tar.gz) = XwoPUjspvXPg8R1jB5MV06Cjw8rmzptVfgQz4ltaDZI=
-SHA256 (wayfire-0.8.0pl17-c48194e0.tar.gz) = Rdw3AIQIij/t0VNd8oDa15eIOO8jS1vIVmGb97vwus8=
-SIZE (WayfireWM-wf-touch-8974eb0f6a65464b63dd03b842795cb441fb6403.tar.gz) = 9874
-SIZE (WayfireWM-wf-utils-15f8e16721585ae3eaf278ba71d7064237eb23f5.tar.gz) = 48535
-SIZE (wayfire-0.8.0pl17-c48194e0.tar.gz) = 437555
+SHA256 (wayfire-0.8.1.tar.xz) = isGUe2iKnsbE2e4tdzEbs1eo6tJWZbgADtqWlSMoKQ0=
+SIZE (wayfire-0.8.1.tar.xz) = 856364
Index: patches/patch-meson_build
===================================================================
RCS file: /cvs/ports/wayland/wayfire/patches/patch-meson_build,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-meson_build
--- patches/patch-meson_build 21 Dec 2023 16:22:14 -0000 1.1.1.1
+++ patches/patch-meson_build 31 Mar 2024 10:12:47 -0000
@@ -1,7 +1,7 @@
Index: meson.build
--- meson.build.orig
+++ meson.build
-@@ -30,7 +30,6 @@ libinput = dependency('libinput', version: '>=1.
+@@ -33,7 +33,6 @@ libinput = dependency('libinput', version: '>=1.
pixman = dependency('pixman-1')
threads = dependency('threads')
xkbcommon = dependency('xkbcommon')
@@ -9,16 +9,7 @@
# We're not to use system wlroots: So we'll use the subproject
if get_option('use_system_wlroots').disabled()
-@@ -58,7 +57,7 @@ if get_option('use_system_wfconfig').disabled()
-
- elif get_option('use_system_wfconfig').enabled()
- use_system_wfconfig = true
-- wfconfig = dependency('wf-config', version: ['>=0.9.0', '<0.10.0'], required: true)
-+ wfconfig = dependency('wf-config', version: ['>=0.8.0', '<0.10.0'], required: true)
-
- elif get_option('use_system_wfconfig').auto()
- wfconfig = dependency('wf-config', version: ['>=0.9.0', '<0.10.0'], required: false)
-@@ -72,7 +71,7 @@ endif
+@@ -75,7 +74,7 @@ endif
wfutils = subproject('wf-utils').get_variable('wfutils')
wftouch = subproject('wf-touch').get_variable('wftouch')
@@ -27,22 +18,3 @@
libinotify = dependency('libinotify', required: needs_libinotify)
jpeg = dependency('libjpeg', required: false)
-@@ -84,18 +83,6 @@ backtrace = meson.get_compiler('cpp').find_library('ex
- conf_data = configuration_data()
-
- version = '"@0@"'.format(meson.project_version())
--git = find_program('git', native: true, required: false)
--if git.found()
-- git_commit = run_command([git, 'rev-parse', '--short', 'HEAD'], check: false)
-- git_branch = run_command([git, 'rev-parse', '--abbrev-ref', 'HEAD'], check: false)
-- if git_commit.returncode() == 0 and git_branch.returncode() == 0
-- version = '"@0@-@1@ (" __DATE__ ", branch \'@2@\')"'.format(
-- meson.project_version(),
-- git_commit.stdout().strip(),
-- git_branch.stdout().strip(),
-- )
-- endif
--endif
- add_project_arguments('-DWAYFIRE_VERSION=@0@'.format(version), language: 'cpp')
- conf_data.set('WAYFIRE_VERSION', '-DWAYFIRE_VERSION=@0@'.format(version))
-
Index: patches/patch-src_meson_build
===================================================================
RCS file: /cvs/ports/wayland/wayfire/patches/patch-src_meson_build,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-src_meson_build
--- patches/patch-src_meson_build 21 Dec 2023 16:22:14 -0000 1.1.1.1
+++ patches/patch-src_meson_build 31 Mar 2024 10:12:47 -0000
@@ -3,7 +3,7 @@
Index: src/meson.build
--- src/meson.build.orig
+++ src/meson.build
-@@ -62,7 +62,7 @@ wayfire_sources = ['geometry.cpp',
+@@ -63,7 +63,7 @@ wayfire_sources = ['geometry.cpp',
'output/workspace-impl.cpp']
wayfire_dependencies = [wayland_server, wlroots, xkbcommon, libinput,
@@ -12,7 +12,7 @@
wfconfig, libinotify, backtrace, wfutils, xcb, wftouch]
if conf_data.get('BUILD_WITH_IMAGEIO')
-@@ -114,6 +114,7 @@ shared_module('default-config-backend', 'default-confi
+@@ -131,6 +131,7 @@ shared_module('default-config-backend', 'default-confi
dependencies: wayfire_dependencies,
include_directories: [wayfire_conf_inc, wayfire_api_inc],
cpp_args: debug_arguments,
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/wayland/wayfire/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 PLIST
--- pkg/PLIST 21 Dec 2023 16:22:14 -0000 1.1.1.1
+++ pkg/PLIST 31 Mar 2024 10:12:47 -0000
@@ -64,7 +64,6 @@
include/wayfire/plugins/ipc/ipc-activator.hpp
include/wayfire/plugins/ipc/ipc-helpers.hpp
include/wayfire/plugins/ipc/ipc-method-repository.hpp
-include/wayfire/plugins/ipc/ipc.hpp
include/wayfire/plugins/scale-signal.hpp
include/wayfire/plugins/vswitch.hpp
include/wayfire/plugins/wm-actions-signals.hpp
@@ -93,6 +92,7 @@
include/wayfire/unstable/
include/wayfire/unstable/translation-node.hpp
include/wayfire/unstable/wlr-surface-node.hpp
+include/wayfire/unstable/wlr-text-input-v3-popup.hpp
include/wayfire/unstable/wlr-view-events.hpp
include/wayfire/unstable/wlr-view-keyboard-interaction.hpp
include/wayfire/unstable/xdg-toplevel-base.hpp
@@ -131,6 +131,7 @@
@so lib/wayfire/libgrid.so
@so lib/wayfire/libgtk-shell.so
@so lib/wayfire/libidle.so
+@so lib/wayfire/libinput-method-v1.so
@so lib/wayfire/libinvert.so
@so lib/wayfire/libipc-rules.so
@so lib/wayfire/libipc.so
@@ -177,6 +178,7 @@
share/wayfire/metadata/gtk-shell.xml
share/wayfire/metadata/idle.xml
share/wayfire/metadata/input-device.xml
+share/wayfire/metadata/input-method-v1.xml
share/wayfire/metadata/input.xml
share/wayfire/metadata/invert.xml
share/wayfire/metadata/ipc-rules.xml
hi,
little update to wayfire 0.8.1, simplifies a bit the port since we can
now build from a release. have a local problem on my wayland testing
laptop so havent been able to run it, but tests are welcome.
Landry
Saturday, March 30, 2024
Re: update lang/sbcl to 2.4.3 (test wanted on arm, powerpc, powerpc64)
On Sat, 30 Mar 2024 11:49:45 +0100
Sebastien Marie <semarie@kapouay.eu.org> wrote:
> The following patch updates lang/sbcl to 2.4.3
>
> I am interested to have it tested on:
> - arm
> - powerpc
> - powerpc64
> ...
> A build test is enough (running 'make' and see if it build successfully
> or error-out).
My powerpc has succeeded to 'make' sbcl-2.4.3.
powerpc64 can't build sbcl. I observed in September 2023 that the
broken lang/rust on powerpc64 was blocking a chain of 12 ports (from
librsvg to psutils). Today, the missing psutils continues to prevent
'pkg_add texinfo', which blocks both lang/ecl and lang/sbcl.
I am working on a powerpc64 fix for base llvm/unwind, which would
prevent crashes in devel/gdb. Soon, gdb might be able to debug
problems with rust on powerpc64.
--gkoehler
Sebastien Marie <semarie@kapouay.eu.org> wrote:
> The following patch updates lang/sbcl to 2.4.3
>
> I am interested to have it tested on:
> - arm
> - powerpc
> - powerpc64
> ...
> A build test is enough (running 'make' and see if it build successfully
> or error-out).
My powerpc has succeeded to 'make' sbcl-2.4.3.
powerpc64 can't build sbcl. I observed in September 2023 that the
broken lang/rust on powerpc64 was blocking a chain of 12 ports (from
librsvg to psutils). Today, the missing psutils continues to prevent
'pkg_add texinfo', which blocks both lang/ecl and lang/sbcl.
I am working on a powerpc64 fix for base llvm/unwind, which would
prevent crashes in devel/gdb. Soon, gdb might be able to debug
problems with rust on powerpc64.
--gkoehler
Re: UPDATE: OpenImageIO 2.5.9
On Sat, Mar 30, 2024 at 07:49:16PM -0400, Brad Smith wrote:
> On Sat, Mar 30, 2024 at 07:55:58PM +0000, Stuart Henderson wrote:
> > On 2024/03/30 11:34, Stuart Henderson wrote:
> > > On 2024/03/29 08:20, Stuart Henderson wrote:
> > > > On 2024/03/28 21:51, Brad Smith wrote:
> > > > > On Thu, Mar 28, 2024 at 04:12:55PM +0000, Stuart Henderson wrote:
> > > > > > On 2024/03/25 23:07, Brad Smith wrote:
> > > > > > > Here is an update to OpenImageIO 2.5.9.
> > > > > >
> > > > > > 2.4.17.0 is broken on i386 - 2.5.9 doesn't fix it
> > > > >
> > > > > I noticed a package missing on amd64 for the last two bulk builds but
> > > > > haven't seen anything from naddy@ yet. It builds for me on my amd64
> > > > > build host.
> > > >
> > > > That will have been due to the problem with the cmake update and
> > > > tiff - it built on amd64 in the current bulk.
> > > >
> > > > > This appears to have something to do with the last commit to strutil_test.cpp.
> > > > > Try the following..
> > > >
> > > > Will do.
> > >
> > > FAILED: src/libutil/CMakeFiles/strutil_test.dir/strutil_test.cpp.o
> >
> > oops, missed -p0 on the patch command. will try again in the next bulk.
>
> I filed a bug report. Upstream provided a proper fix.
And it was commited.
Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/openimageio/Makefile,v
retrieving revision 1.69
diff -u -p -u -p -r1.69 Makefile
--- Makefile 22 Mar 2024 12:25:32 -0000 1.69
+++ Makefile 31 Mar 2024 04:06:35 -0000
@@ -7,6 +7,7 @@ GH_ACCOUNT = AcademySoftwareFoundation
GH_PROJECT = OpenImageIO
GH_TAGNAME = v2.4.17.0
PKGNAME = ${DISTNAME:L}
+REVISION = 0
SHARED_LIBS += OpenImageIO 14.0 # 2.4.10
SHARED_LIBS += OpenImageIO_Util 9.0 # 2.4.10
Index: patches/patch-src_include_OpenImageIO_detail_farmhash_h
===================================================================
RCS file: patches/patch-src_include_OpenImageIO_detail_farmhash_h
diff -N patches/patch-src_include_OpenImageIO_detail_farmhash_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_include_OpenImageIO_detail_farmhash_h 31 Mar 2024 04:06:35 -0000
@@ -0,0 +1,15 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/commit/004a04fc1d5f5a949598b18978f8f960fc604d1b
+
+Index: src/include/OpenImageIO/detail/farmhash.h
+--- src/include/OpenImageIO/detail/farmhash.h.orig
++++ src/include/OpenImageIO/detail/farmhash.h
+@@ -2097,7 +2097,7 @@ STATIC_INLINE uint64_t Hash64(const char* s, size_t le
+ // May change from time to time, may differ on different platforms, may differ
+ // depending on NDEBUG.
+ STATIC_INLINE size_t Hash(const char* s, size_t len) {
+- return sizeof(size_t) == 8 ? Hash64(s, len) : Hash32(s, len);
++ return sizeof(size_t) == 8 ? size_t(Hash64(s, len)) : size_t(Hash32(s, len));
+ }
+
+ // Hash function for a byte array. For convenience, a 64-bit seed is also
Index: patches/patch-src_include_OpenImageIO_strutil_h
===================================================================
RCS file: patches/patch-src_include_OpenImageIO_strutil_h
diff -N patches/patch-src_include_OpenImageIO_strutil_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_include_OpenImageIO_strutil_h 31 Mar 2024 04:06:35 -0000
@@ -0,0 +1,20 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/commit/004a04fc1d5f5a949598b18978f8f960fc604d1b
+
+Index: src/include/OpenImageIO/strutil.h
+--- src/include/OpenImageIO/strutil.h.orig
++++ src/include/OpenImageIO/strutil.h
+@@ -370,11 +370,11 @@ std::string OIIO_UTIL_API wordwrap (string_view src, i
+
+
+ /// Our favorite "string" hash of a length of bytes. Currently, it is just
+-/// a wrapper for an inlined, constexpr (if C++ >= 14), Cuda-safe farmhash.
++/// a wrapper for an inlined, constexpr, Cuda-safe farmhash.
+ inline constexpr size_t
+ strhash (size_t len, const char *s)
+ {
+- return OIIO::farmhash::inlined::Hash(s, len);
++ return size_t(OIIO::farmhash::inlined::Hash64(s, len));
+ }
+
+
Index: patches/patch-src_libutil_strutil_test_cpp
===================================================================
RCS file: patches/patch-src_libutil_strutil_test_cpp
diff -N patches/patch-src_libutil_strutil_test_cpp
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_libutil_strutil_test_cpp 31 Mar 2024 04:06:35 -0000
@@ -0,0 +1,24 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/commit/004a04fc1d5f5a949598b18978f8f960fc604d1b
+
+Index: src/libutil/strutil_test.cpp
+--- src/libutil/strutil_test.cpp.orig
++++ src/libutil/strutil_test.cpp
+@@ -346,13 +346,13 @@ void
+ test_hash()
+ {
+ using namespace Strutil;
+- OIIO_CHECK_EQUAL(strhash("foo"), 6150913649986995171);
+- OIIO_CHECK_EQUAL(strhash(std::string("foo")), 6150913649986995171);
+- OIIO_CHECK_EQUAL(strhash(string_view("foo")), 6150913649986995171);
++ OIIO_CHECK_EQUAL(strhash("foo"), size_t(6150913649986995171));
++ OIIO_CHECK_EQUAL(strhash(std::string("foo")), size_t(6150913649986995171));
++ OIIO_CHECK_EQUAL(strhash(string_view("foo")), size_t(6150913649986995171));
+ OIIO_CHECK_EQUAL(strhash(""), 0); // empty string hashes to 0
+ // Check longer hash and ensure that it's really constexpr
+ constexpr size_t hash = Strutil::strhash("much longer string");
+- OIIO_CHECK_EQUAL(hash, 16257490369375554819ULL);
++ OIIO_CHECK_EQUAL(hash, size_t(16257490369375554819ULL));
+ }
+
+
> On Sat, Mar 30, 2024 at 07:55:58PM +0000, Stuart Henderson wrote:
> > On 2024/03/30 11:34, Stuart Henderson wrote:
> > > On 2024/03/29 08:20, Stuart Henderson wrote:
> > > > On 2024/03/28 21:51, Brad Smith wrote:
> > > > > On Thu, Mar 28, 2024 at 04:12:55PM +0000, Stuart Henderson wrote:
> > > > > > On 2024/03/25 23:07, Brad Smith wrote:
> > > > > > > Here is an update to OpenImageIO 2.5.9.
> > > > > >
> > > > > > 2.4.17.0 is broken on i386 - 2.5.9 doesn't fix it
> > > > >
> > > > > I noticed a package missing on amd64 for the last two bulk builds but
> > > > > haven't seen anything from naddy@ yet. It builds for me on my amd64
> > > > > build host.
> > > >
> > > > That will have been due to the problem with the cmake update and
> > > > tiff - it built on amd64 in the current bulk.
> > > >
> > > > > This appears to have something to do with the last commit to strutil_test.cpp.
> > > > > Try the following..
> > > >
> > > > Will do.
> > >
> > > FAILED: src/libutil/CMakeFiles/strutil_test.dir/strutil_test.cpp.o
> >
> > oops, missed -p0 on the patch command. will try again in the next bulk.
>
> I filed a bug report. Upstream provided a proper fix.
And it was commited.
Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/openimageio/Makefile,v
retrieving revision 1.69
diff -u -p -u -p -r1.69 Makefile
--- Makefile 22 Mar 2024 12:25:32 -0000 1.69
+++ Makefile 31 Mar 2024 04:06:35 -0000
@@ -7,6 +7,7 @@ GH_ACCOUNT = AcademySoftwareFoundation
GH_PROJECT = OpenImageIO
GH_TAGNAME = v2.4.17.0
PKGNAME = ${DISTNAME:L}
+REVISION = 0
SHARED_LIBS += OpenImageIO 14.0 # 2.4.10
SHARED_LIBS += OpenImageIO_Util 9.0 # 2.4.10
Index: patches/patch-src_include_OpenImageIO_detail_farmhash_h
===================================================================
RCS file: patches/patch-src_include_OpenImageIO_detail_farmhash_h
diff -N patches/patch-src_include_OpenImageIO_detail_farmhash_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_include_OpenImageIO_detail_farmhash_h 31 Mar 2024 04:06:35 -0000
@@ -0,0 +1,15 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/commit/004a04fc1d5f5a949598b18978f8f960fc604d1b
+
+Index: src/include/OpenImageIO/detail/farmhash.h
+--- src/include/OpenImageIO/detail/farmhash.h.orig
++++ src/include/OpenImageIO/detail/farmhash.h
+@@ -2097,7 +2097,7 @@ STATIC_INLINE uint64_t Hash64(const char* s, size_t le
+ // May change from time to time, may differ on different platforms, may differ
+ // depending on NDEBUG.
+ STATIC_INLINE size_t Hash(const char* s, size_t len) {
+- return sizeof(size_t) == 8 ? Hash64(s, len) : Hash32(s, len);
++ return sizeof(size_t) == 8 ? size_t(Hash64(s, len)) : size_t(Hash32(s, len));
+ }
+
+ // Hash function for a byte array. For convenience, a 64-bit seed is also
Index: patches/patch-src_include_OpenImageIO_strutil_h
===================================================================
RCS file: patches/patch-src_include_OpenImageIO_strutil_h
diff -N patches/patch-src_include_OpenImageIO_strutil_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_include_OpenImageIO_strutil_h 31 Mar 2024 04:06:35 -0000
@@ -0,0 +1,20 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/commit/004a04fc1d5f5a949598b18978f8f960fc604d1b
+
+Index: src/include/OpenImageIO/strutil.h
+--- src/include/OpenImageIO/strutil.h.orig
++++ src/include/OpenImageIO/strutil.h
+@@ -370,11 +370,11 @@ std::string OIIO_UTIL_API wordwrap (string_view src, i
+
+
+ /// Our favorite "string" hash of a length of bytes. Currently, it is just
+-/// a wrapper for an inlined, constexpr (if C++ >= 14), Cuda-safe farmhash.
++/// a wrapper for an inlined, constexpr, Cuda-safe farmhash.
+ inline constexpr size_t
+ strhash (size_t len, const char *s)
+ {
+- return OIIO::farmhash::inlined::Hash(s, len);
++ return size_t(OIIO::farmhash::inlined::Hash64(s, len));
+ }
+
+
Index: patches/patch-src_libutil_strutil_test_cpp
===================================================================
RCS file: patches/patch-src_libutil_strutil_test_cpp
diff -N patches/patch-src_libutil_strutil_test_cpp
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_libutil_strutil_test_cpp 31 Mar 2024 04:06:35 -0000
@@ -0,0 +1,24 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/commit/004a04fc1d5f5a949598b18978f8f960fc604d1b
+
+Index: src/libutil/strutil_test.cpp
+--- src/libutil/strutil_test.cpp.orig
++++ src/libutil/strutil_test.cpp
+@@ -346,13 +346,13 @@ void
+ test_hash()
+ {
+ using namespace Strutil;
+- OIIO_CHECK_EQUAL(strhash("foo"), 6150913649986995171);
+- OIIO_CHECK_EQUAL(strhash(std::string("foo")), 6150913649986995171);
+- OIIO_CHECK_EQUAL(strhash(string_view("foo")), 6150913649986995171);
++ OIIO_CHECK_EQUAL(strhash("foo"), size_t(6150913649986995171));
++ OIIO_CHECK_EQUAL(strhash(std::string("foo")), size_t(6150913649986995171));
++ OIIO_CHECK_EQUAL(strhash(string_view("foo")), size_t(6150913649986995171));
+ OIIO_CHECK_EQUAL(strhash(""), 0); // empty string hashes to 0
+ // Check longer hash and ensure that it's really constexpr
+ constexpr size_t hash = Strutil::strhash("much longer string");
+- OIIO_CHECK_EQUAL(hash, 16257490369375554819ULL);
++ OIIO_CHECK_EQUAL(hash, size_t(16257490369375554819ULL));
+ }
+
+
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
On Wednesday, March 27, 2024, Dan <dan.peretz.my@gmail.com> wrote:
Hello, I have 3 security-related questions:(1) Does OpenBSD have a mechanism like Ctrl-Alt-Delete on Windows (Secure Attention Key, or SAK) to prevent malware (or a website in fullscreen, for example) from faking a logout process and/or faking a login prompt? On Windows the kernel ensures that the operating system captures this key combination and takes over with a real login prompt that malware can't fake without first defeating the OS security.
(Let me clarify for the rest of this message: malware is any program that acts maliciously; it doesn't *necessarily* bypass exploit mitigations or security features of the OS (e.g. it could work around them, or abuse the lack of them).)
Something recent that I found that's relevant:
(From March 28, 2024. Note that this isn't a vulnerability in how the OS separates users or enforces security, this is a vulnerability that could be used to make a convincing "phishing" attack.)
This isn't exactly the issue that SAK prevents, because the SAK is meant to be used at login time (not when already logged in as one user and trying to doas/sudo one program/command into another user), but I'll repeat the two links I sent before:
The second link being the more relevant one. Notice how Microsoft describes that User Account Control takes over the screen with a secure desktop mode. UAC is the equivalent of doas/sudo. There's an additional problem though: malware and websites in fullscreen could mimic the sound and visual dimming effect that UAC does on Windows. While UAC doesn't ask the user to press a privileged key combination like Ctrl-Alt-Delete (so the user has no guarantee that the UAC prompt is authentic, even with the said perceptual effects), it does something else: it asks for authorization (and details what is authorized exactly) without relying on knowledge of the passphrase as proof for authorization. Malware on OpenBSD that knows the root passphrase, or the passphrase of a doas-capable/sudoer user, can escalate its privileges; malware on Windows (including web content that escapes the browser's sandbox) that knows the passphrase of a user in the Administrators group cannot escalate its privileges without first compromising the integrity of Windows, because asking Windows to escalate privileges would ensure that the user authorizes the escalation regardless of the passphrase (let's assume that UAC is set to its highest (fourth) level, rather than the default (third) level that excepts some system programs from causing a UAC prompt when escalating). (Web content that escapes the browser's sandbox of Chromium, Firefox, and Tor Browser on OpenBSD would need to compromise the integrity of OpenBSD, because it sandboxes them further using pledge(2) and unveil(2) (or find a weakness in how these two are set up). So that's already a very good thing, but that alone is not enough.) It's important to emphasize that it doesn't matter whether UAC asks or doesn't ask for a passphrase to authorize, rather the important thing here is that it takes over the computer temporarily in a way that cannot be interfered with by normal programs and asks for explicit authorization; it could as well ask for a passphrase too as a second factor. Malware that fakes a UAC prompt and get "authorized" by the user would achieve nothing, as it hasn't really asked Windows to escalate, whereas malware on OpenBSD that convincingly fakes a doas prompt and gets "authorized" by the user can then impersonate the "authorizing" user going forward.
Re: UPDATE: OpenImageIO 2.5.9
On Sat, Mar 30, 2024 at 07:55:58PM +0000, Stuart Henderson wrote:
> On 2024/03/30 11:34, Stuart Henderson wrote:
> > On 2024/03/29 08:20, Stuart Henderson wrote:
> > > On 2024/03/28 21:51, Brad Smith wrote:
> > > > On Thu, Mar 28, 2024 at 04:12:55PM +0000, Stuart Henderson wrote:
> > > > > On 2024/03/25 23:07, Brad Smith wrote:
> > > > > > Here is an update to OpenImageIO 2.5.9.
> > > > >
> > > > > 2.4.17.0 is broken on i386 - 2.5.9 doesn't fix it
> > > >
> > > > I noticed a package missing on amd64 for the last two bulk builds but
> > > > haven't seen anything from naddy@ yet. It builds for me on my amd64
> > > > build host.
> > >
> > > That will have been due to the problem with the cmake update and
> > > tiff - it built on amd64 in the current bulk.
> > >
> > > > This appears to have something to do with the last commit to strutil_test.cpp.
> > > > Try the following..
> > >
> > > Will do.
> >
> > FAILED: src/libutil/CMakeFiles/strutil_test.dir/strutil_test.cpp.o
>
> oops, missed -p0 on the patch command. will try again in the next bulk.
I filed a bug report. Upstream provided a proper fix.
Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/openimageio/Makefile,v
retrieving revision 1.69
diff -u -p -u -p -r1.69 Makefile
--- Makefile 22 Mar 2024 12:25:32 -0000 1.69
+++ Makefile 30 Mar 2024 23:05:59 -0000
@@ -7,6 +7,7 @@ GH_ACCOUNT = AcademySoftwareFoundation
GH_PROJECT = OpenImageIO
GH_TAGNAME = v2.4.17.0
PKGNAME = ${DISTNAME:L}
+REVISION = 0
SHARED_LIBS += OpenImageIO 14.0 # 2.4.10
SHARED_LIBS += OpenImageIO_Util 9.0 # 2.4.10
Index: patches/patch-src_include_OpenImageIO_detail_farmhash_h
===================================================================
RCS file: patches/patch-src_include_OpenImageIO_detail_farmhash_h
diff -N patches/patch-src_include_OpenImageIO_detail_farmhash_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_include_OpenImageIO_detail_farmhash_h 30 Mar 2024 23:05:59 -0000
@@ -0,0 +1,15 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4213
+
+Index: src/include/OpenImageIO/detail/farmhash.h
+--- src/include/OpenImageIO/detail/farmhash.h.orig
++++ src/include/OpenImageIO/detail/farmhash.h
+@@ -2097,7 +2097,7 @@ STATIC_INLINE uint64_t Hash64(const char* s, size_t le
+ // May change from time to time, may differ on different platforms, may differ
+ // depending on NDEBUG.
+ STATIC_INLINE size_t Hash(const char* s, size_t len) {
+- return sizeof(size_t) == 8 ? Hash64(s, len) : Hash32(s, len);
++ return sizeof(size_t) == 8 ? size_t(Hash64(s, len)) : size_t(Hash32(s, len));
+ }
+
+ // Hash function for a byte array. For convenience, a 64-bit seed is also
Index: patches/patch-src_include_OpenImageIO_strutil_h
===================================================================
RCS file: patches/patch-src_include_OpenImageIO_strutil_h
diff -N patches/patch-src_include_OpenImageIO_strutil_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_include_OpenImageIO_strutil_h 30 Mar 2024 23:05:59 -0000
@@ -0,0 +1,20 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4213
+
+Index: src/include/OpenImageIO/strutil.h
+--- src/include/OpenImageIO/strutil.h.orig
++++ src/include/OpenImageIO/strutil.h
+@@ -370,11 +370,11 @@ std::string OIIO_UTIL_API wordwrap (string_view src, i
+
+
+ /// Our favorite "string" hash of a length of bytes. Currently, it is just
+-/// a wrapper for an inlined, constexpr (if C++ >= 14), Cuda-safe farmhash.
++/// a wrapper for an inlined, constexpr, Cuda-safe farmhash.
+ inline constexpr size_t
+ strhash (size_t len, const char *s)
+ {
+- return OIIO::farmhash::inlined::Hash(s, len);
++ return size_t(OIIO::farmhash::inlined::Hash64(s, len));
+ }
+
+
Index: patches/patch-src_libutil_strutil_test_cpp
===================================================================
RCS file: patches/patch-src_libutil_strutil_test_cpp
diff -N patches/patch-src_libutil_strutil_test_cpp
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_libutil_strutil_test_cpp 30 Mar 2024 23:05:59 -0000
@@ -0,0 +1,24 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4213
+
+Index: src/libutil/strutil_test.cpp
+--- src/libutil/strutil_test.cpp.orig
++++ src/libutil/strutil_test.cpp
+@@ -346,13 +346,13 @@ void
+ test_hash()
+ {
+ using namespace Strutil;
+- OIIO_CHECK_EQUAL(strhash("foo"), 6150913649986995171);
+- OIIO_CHECK_EQUAL(strhash(std::string("foo")), 6150913649986995171);
+- OIIO_CHECK_EQUAL(strhash(string_view("foo")), 6150913649986995171);
++ OIIO_CHECK_EQUAL(strhash("foo"), size_t(6150913649986995171));
++ OIIO_CHECK_EQUAL(strhash(std::string("foo")), size_t(6150913649986995171));
++ OIIO_CHECK_EQUAL(strhash(string_view("foo")), size_t(6150913649986995171));
+ OIIO_CHECK_EQUAL(strhash(""), 0); // empty string hashes to 0
+ // Check longer hash and ensure that it's really constexpr
+ constexpr size_t hash = Strutil::strhash("much longer string");
+- OIIO_CHECK_EQUAL(hash, 16257490369375554819ULL);
++ OIIO_CHECK_EQUAL(hash, size_t(16257490369375554819ULL));
+ }
+
+
> On 2024/03/30 11:34, Stuart Henderson wrote:
> > On 2024/03/29 08:20, Stuart Henderson wrote:
> > > On 2024/03/28 21:51, Brad Smith wrote:
> > > > On Thu, Mar 28, 2024 at 04:12:55PM +0000, Stuart Henderson wrote:
> > > > > On 2024/03/25 23:07, Brad Smith wrote:
> > > > > > Here is an update to OpenImageIO 2.5.9.
> > > > >
> > > > > 2.4.17.0 is broken on i386 - 2.5.9 doesn't fix it
> > > >
> > > > I noticed a package missing on amd64 for the last two bulk builds but
> > > > haven't seen anything from naddy@ yet. It builds for me on my amd64
> > > > build host.
> > >
> > > That will have been due to the problem with the cmake update and
> > > tiff - it built on amd64 in the current bulk.
> > >
> > > > This appears to have something to do with the last commit to strutil_test.cpp.
> > > > Try the following..
> > >
> > > Will do.
> >
> > FAILED: src/libutil/CMakeFiles/strutil_test.dir/strutil_test.cpp.o
>
> oops, missed -p0 on the patch command. will try again in the next bulk.
I filed a bug report. Upstream provided a proper fix.
Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/openimageio/Makefile,v
retrieving revision 1.69
diff -u -p -u -p -r1.69 Makefile
--- Makefile 22 Mar 2024 12:25:32 -0000 1.69
+++ Makefile 30 Mar 2024 23:05:59 -0000
@@ -7,6 +7,7 @@ GH_ACCOUNT = AcademySoftwareFoundation
GH_PROJECT = OpenImageIO
GH_TAGNAME = v2.4.17.0
PKGNAME = ${DISTNAME:L}
+REVISION = 0
SHARED_LIBS += OpenImageIO 14.0 # 2.4.10
SHARED_LIBS += OpenImageIO_Util 9.0 # 2.4.10
Index: patches/patch-src_include_OpenImageIO_detail_farmhash_h
===================================================================
RCS file: patches/patch-src_include_OpenImageIO_detail_farmhash_h
diff -N patches/patch-src_include_OpenImageIO_detail_farmhash_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_include_OpenImageIO_detail_farmhash_h 30 Mar 2024 23:05:59 -0000
@@ -0,0 +1,15 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4213
+
+Index: src/include/OpenImageIO/detail/farmhash.h
+--- src/include/OpenImageIO/detail/farmhash.h.orig
++++ src/include/OpenImageIO/detail/farmhash.h
+@@ -2097,7 +2097,7 @@ STATIC_INLINE uint64_t Hash64(const char* s, size_t le
+ // May change from time to time, may differ on different platforms, may differ
+ // depending on NDEBUG.
+ STATIC_INLINE size_t Hash(const char* s, size_t len) {
+- return sizeof(size_t) == 8 ? Hash64(s, len) : Hash32(s, len);
++ return sizeof(size_t) == 8 ? size_t(Hash64(s, len)) : size_t(Hash32(s, len));
+ }
+
+ // Hash function for a byte array. For convenience, a 64-bit seed is also
Index: patches/patch-src_include_OpenImageIO_strutil_h
===================================================================
RCS file: patches/patch-src_include_OpenImageIO_strutil_h
diff -N patches/patch-src_include_OpenImageIO_strutil_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_include_OpenImageIO_strutil_h 30 Mar 2024 23:05:59 -0000
@@ -0,0 +1,20 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4213
+
+Index: src/include/OpenImageIO/strutil.h
+--- src/include/OpenImageIO/strutil.h.orig
++++ src/include/OpenImageIO/strutil.h
+@@ -370,11 +370,11 @@ std::string OIIO_UTIL_API wordwrap (string_view src, i
+
+
+ /// Our favorite "string" hash of a length of bytes. Currently, it is just
+-/// a wrapper for an inlined, constexpr (if C++ >= 14), Cuda-safe farmhash.
++/// a wrapper for an inlined, constexpr, Cuda-safe farmhash.
+ inline constexpr size_t
+ strhash (size_t len, const char *s)
+ {
+- return OIIO::farmhash::inlined::Hash(s, len);
++ return size_t(OIIO::farmhash::inlined::Hash64(s, len));
+ }
+
+
Index: patches/patch-src_libutil_strutil_test_cpp
===================================================================
RCS file: patches/patch-src_libutil_strutil_test_cpp
diff -N patches/patch-src_libutil_strutil_test_cpp
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-src_libutil_strutil_test_cpp 30 Mar 2024 23:05:59 -0000
@@ -0,0 +1,24 @@
+fix: Restore internals of strhash to compile on 32 bit architectures
+https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4213
+
+Index: src/libutil/strutil_test.cpp
+--- src/libutil/strutil_test.cpp.orig
++++ src/libutil/strutil_test.cpp
+@@ -346,13 +346,13 @@ void
+ test_hash()
+ {
+ using namespace Strutil;
+- OIIO_CHECK_EQUAL(strhash("foo"), 6150913649986995171);
+- OIIO_CHECK_EQUAL(strhash(std::string("foo")), 6150913649986995171);
+- OIIO_CHECK_EQUAL(strhash(string_view("foo")), 6150913649986995171);
++ OIIO_CHECK_EQUAL(strhash("foo"), size_t(6150913649986995171));
++ OIIO_CHECK_EQUAL(strhash(std::string("foo")), size_t(6150913649986995171));
++ OIIO_CHECK_EQUAL(strhash(string_view("foo")), size_t(6150913649986995171));
+ OIIO_CHECK_EQUAL(strhash(""), 0); // empty string hashes to 0
+ // Check longer hash and ensure that it's really constexpr
+ constexpr size_t hash = Strutil::strhash("much longer string");
+- OIIO_CHECK_EQUAL(hash, 16257490369375554819ULL);
++ OIIO_CHECK_EQUAL(hash, size_t(16257490369375554819ULL));
+ }
+
+
Re: UPDATE: libcares 1.28
On Fri, Mar 29, 2024 at 02:58:53PM -0400, Brad Smith wrote:
> Here is an update to libcares 1.28.0.
>
>
> ## c-ares version 1.28.0 - Mar 29 2024
>
> This is a feature and bugfix release.
>
> Features:
>
> * Emit warnings when deprecated c-ares functions are used. This can be
> disabled by passing a compiler definition of `CARES_NO_DEPRECATED`.
> [PR #732](https://github.com/c-ares/c-ares/pull/732)
> * Add function `ares_search_dnrec()` to search for records using the new DNS
> record data structures. [PR #719](https://github.com/c-ares/c-ares/pull/719)
> * Rework internals to pass around `ares_dns_record_t` instead of binary data,
> this introduces new public functions of `ares_query_dnsrec()` and
> `ares_send_dnsrec()`. [PR #730](https://github.com/c-ares/c-ares/pull/730)
>
> Changes:
>
> * tests: when performing simulated queries, reduce timeouts to make tests run
> faster
> * Replace configuration file parsers with memory-safe parser.
> [PR #725](https://github.com/c-ares/c-ares/pull/725)
> * Remove `acountry` completely, the manpage might still get installed otherwise.
> [Issue #718](https://github.com/c-ares/c-ares/pull/718)
>
> Bugfixes:
>
> * CMake: don't overwrite global required libraries/definitions/includes which
> could cause build errors for projects chain building c-ares.
> [Issue #729](https://github.com/c-ares/c-ares/issues/729)
> * On some platforms, `netinet6/in6.h` is not included by `netinet/in.h`
> and needs to be included separately.
> [PR #728](https://github.com/c-ares/c-ares/pull/728)
> * Fix a potential memory leak in `ares_init()`.
> [Issue #724](https://github.com/c-ares/c-ares/issues/724)
> * Some platforms don't have the `isascii()` function. Implement as a macro.
> [PR #721](https://github.com/c-ares/c-ares/pull/721)
> * CMake: Fix Chain building if CMAKE runtime paths not set
> * NDots configuration should allow a value of zero.
> [PR #735](https://github.com/c-ares/c-ares/pull/735)
Here is an update to libcares 1.28.1.
## c-ares version 1.28.1 - Mar 30 2024
This release contains a fix for a single significant regression introduced
in c-ares 1.28.0.
* `ares_search()` and `ares_getaddrinfo()` resolution fails if no search domains
are specified. [Issue #737](https://github.com/c-ares/c-ares/issues/737)
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/libcares/Makefile,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 Makefile
--- Makefile 23 Feb 2024 20:42:46 -0000 1.27
+++ Makefile 30 Mar 2024 21:58:55 -0000
@@ -1,12 +1,12 @@
COMMENT= asynchronous resolver library
-V= 1.27.0
+V= 1.28.1
DISTNAME= c-ares-${V}
PKGNAME= libcares-${V}
CATEGORIES= net devel
SITES= ${HOMEPAGE}download/
-SHARED_LIBS += cares 3.5 # 8.1.6
+SHARED_LIBS += cares 3.6 # 8.1.6
HOMEPAGE= https://c-ares.haxx.se/
@@ -19,7 +19,13 @@ WANTLIB+= pthread
MODULES= devel/cmake
-CONFIGURE_ARGS+=-DCARES_BUILD_TOOLS=OFF \
+# C++
+COMPILER= base-clang ports-gcc
+
+BUILD_DEPENDS+= devel/gtest
+
+CONFIGURE_ARGS+=-DCARES_BUILD_TESTS=ON \
+ -DCARES_BUILD_TOOLS=OFF \
-DCARES_STATIC=ON \
-DCARES_SYMBOL_HIDING=ON
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/libcares/distinfo,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 distinfo
--- distinfo 23 Feb 2024 20:42:46 -0000 1.15
+++ distinfo 30 Mar 2024 21:58:55 -0000
@@ -1,2 +1,2 @@
-SHA256 (c-ares-1.27.0.tar.gz) = CnK+ZpWZVcQ+KvL70DQY6Cor1UZGBOyaYhR+N6zrQgs=
-SIZE (c-ares-1.27.0.tar.gz) = 1301440
+SHA256 (c-ares-1.28.1.tar.gz) = Z1pp/FTdv0LmgwvGce62zYnuykOCjrQTJD/SwKdggJ0=
+SIZE (c-ares-1.28.1.tar.gz) = 1312102
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/net/libcares/pkg/PLIST,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 PLIST
--- pkg/PLIST 23 Feb 2024 20:42:46 -0000 1.14
+++ pkg/PLIST 30 Mar 2024 21:58:55 -0000
@@ -37,6 +37,7 @@ lib/pkgconfig/libcares.pc
@man man/man3/ares_dns_record.3
@man man/man3/ares_dns_record_create.3
@man man/man3/ares_dns_record_destroy.3
+@man man/man3/ares_dns_record_duplicate.3
@man man/man3/ares_dns_record_get_flags.3
@man man/man3/ares_dns_record_get_id.3
@man man/man3/ares_dns_record_get_opcode.3
@@ -44,10 +45,13 @@ lib/pkgconfig/libcares.pc
@man man/man3/ares_dns_record_query_add.3
@man man/man3/ares_dns_record_query_cnt.3
@man man/man3/ares_dns_record_query_get.3
+@man man/man3/ares_dns_record_query_set_name.3
+@man man/man3/ares_dns_record_query_set_type.3
@man man/man3/ares_dns_record_rr_add.3
@man man/man3/ares_dns_record_rr_cnt.3
@man man/man3/ares_dns_record_rr_del.3
@man man/man3/ares_dns_record_rr_get.3
+@man man/man3/ares_dns_record_rr_get_const.3
@man man/man3/ares_dns_rr.3
@man man/man3/ares_dns_rr_get_addr.3
@man man/man3/ares_dns_rr_get_addr6.3
@@ -119,10 +123,16 @@ lib/pkgconfig/libcares.pc
@man man/man3/ares_parse_uri_reply.3
@man man/man3/ares_process.3
@man man/man3/ares_query.3
+@man man/man3/ares_query_dnsrec.3
+@man man/man3/ares_queue.3
+@man man/man3/ares_queue_active_queries.3
+@man man/man3/ares_queue_wait_empty.3
@man man/man3/ares_reinit.3
@man man/man3/ares_save_options.3
@man man/man3/ares_search.3
+@man man/man3/ares_search_dnsrec.3
@man man/man3/ares_send.3
+@man man/man3/ares_send_dnsrec.3
@man man/man3/ares_set_local_dev.3
@man man/man3/ares_set_local_ip4.3
@man man/man3/ares_set_local_ip6.3
> Here is an update to libcares 1.28.0.
>
>
> ## c-ares version 1.28.0 - Mar 29 2024
>
> This is a feature and bugfix release.
>
> Features:
>
> * Emit warnings when deprecated c-ares functions are used. This can be
> disabled by passing a compiler definition of `CARES_NO_DEPRECATED`.
> [PR #732](https://github.com/c-ares/c-ares/pull/732)
> * Add function `ares_search_dnrec()` to search for records using the new DNS
> record data structures. [PR #719](https://github.com/c-ares/c-ares/pull/719)
> * Rework internals to pass around `ares_dns_record_t` instead of binary data,
> this introduces new public functions of `ares_query_dnsrec()` and
> `ares_send_dnsrec()`. [PR #730](https://github.com/c-ares/c-ares/pull/730)
>
> Changes:
>
> * tests: when performing simulated queries, reduce timeouts to make tests run
> faster
> * Replace configuration file parsers with memory-safe parser.
> [PR #725](https://github.com/c-ares/c-ares/pull/725)
> * Remove `acountry` completely, the manpage might still get installed otherwise.
> [Issue #718](https://github.com/c-ares/c-ares/pull/718)
>
> Bugfixes:
>
> * CMake: don't overwrite global required libraries/definitions/includes which
> could cause build errors for projects chain building c-ares.
> [Issue #729](https://github.com/c-ares/c-ares/issues/729)
> * On some platforms, `netinet6/in6.h` is not included by `netinet/in.h`
> and needs to be included separately.
> [PR #728](https://github.com/c-ares/c-ares/pull/728)
> * Fix a potential memory leak in `ares_init()`.
> [Issue #724](https://github.com/c-ares/c-ares/issues/724)
> * Some platforms don't have the `isascii()` function. Implement as a macro.
> [PR #721](https://github.com/c-ares/c-ares/pull/721)
> * CMake: Fix Chain building if CMAKE runtime paths not set
> * NDots configuration should allow a value of zero.
> [PR #735](https://github.com/c-ares/c-ares/pull/735)
Here is an update to libcares 1.28.1.
## c-ares version 1.28.1 - Mar 30 2024
This release contains a fix for a single significant regression introduced
in c-ares 1.28.0.
* `ares_search()` and `ares_getaddrinfo()` resolution fails if no search domains
are specified. [Issue #737](https://github.com/c-ares/c-ares/issues/737)
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/libcares/Makefile,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 Makefile
--- Makefile 23 Feb 2024 20:42:46 -0000 1.27
+++ Makefile 30 Mar 2024 21:58:55 -0000
@@ -1,12 +1,12 @@
COMMENT= asynchronous resolver library
-V= 1.27.0
+V= 1.28.1
DISTNAME= c-ares-${V}
PKGNAME= libcares-${V}
CATEGORIES= net devel
SITES= ${HOMEPAGE}download/
-SHARED_LIBS += cares 3.5 # 8.1.6
+SHARED_LIBS += cares 3.6 # 8.1.6
HOMEPAGE= https://c-ares.haxx.se/
@@ -19,7 +19,13 @@ WANTLIB+= pthread
MODULES= devel/cmake
-CONFIGURE_ARGS+=-DCARES_BUILD_TOOLS=OFF \
+# C++
+COMPILER= base-clang ports-gcc
+
+BUILD_DEPENDS+= devel/gtest
+
+CONFIGURE_ARGS+=-DCARES_BUILD_TESTS=ON \
+ -DCARES_BUILD_TOOLS=OFF \
-DCARES_STATIC=ON \
-DCARES_SYMBOL_HIDING=ON
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/libcares/distinfo,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 distinfo
--- distinfo 23 Feb 2024 20:42:46 -0000 1.15
+++ distinfo 30 Mar 2024 21:58:55 -0000
@@ -1,2 +1,2 @@
-SHA256 (c-ares-1.27.0.tar.gz) = CnK+ZpWZVcQ+KvL70DQY6Cor1UZGBOyaYhR+N6zrQgs=
-SIZE (c-ares-1.27.0.tar.gz) = 1301440
+SHA256 (c-ares-1.28.1.tar.gz) = Z1pp/FTdv0LmgwvGce62zYnuykOCjrQTJD/SwKdggJ0=
+SIZE (c-ares-1.28.1.tar.gz) = 1312102
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/net/libcares/pkg/PLIST,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 PLIST
--- pkg/PLIST 23 Feb 2024 20:42:46 -0000 1.14
+++ pkg/PLIST 30 Mar 2024 21:58:55 -0000
@@ -37,6 +37,7 @@ lib/pkgconfig/libcares.pc
@man man/man3/ares_dns_record.3
@man man/man3/ares_dns_record_create.3
@man man/man3/ares_dns_record_destroy.3
+@man man/man3/ares_dns_record_duplicate.3
@man man/man3/ares_dns_record_get_flags.3
@man man/man3/ares_dns_record_get_id.3
@man man/man3/ares_dns_record_get_opcode.3
@@ -44,10 +45,13 @@ lib/pkgconfig/libcares.pc
@man man/man3/ares_dns_record_query_add.3
@man man/man3/ares_dns_record_query_cnt.3
@man man/man3/ares_dns_record_query_get.3
+@man man/man3/ares_dns_record_query_set_name.3
+@man man/man3/ares_dns_record_query_set_type.3
@man man/man3/ares_dns_record_rr_add.3
@man man/man3/ares_dns_record_rr_cnt.3
@man man/man3/ares_dns_record_rr_del.3
@man man/man3/ares_dns_record_rr_get.3
+@man man/man3/ares_dns_record_rr_get_const.3
@man man/man3/ares_dns_rr.3
@man man/man3/ares_dns_rr_get_addr.3
@man man/man3/ares_dns_rr_get_addr6.3
@@ -119,10 +123,16 @@ lib/pkgconfig/libcares.pc
@man man/man3/ares_parse_uri_reply.3
@man man/man3/ares_process.3
@man man/man3/ares_query.3
+@man man/man3/ares_query_dnsrec.3
+@man man/man3/ares_queue.3
+@man man/man3/ares_queue_active_queries.3
+@man man/man3/ares_queue_wait_empty.3
@man man/man3/ares_reinit.3
@man man/man3/ares_save_options.3
@man man/man3/ares_search.3
+@man man/man3/ares_search_dnsrec.3
@man man/man3/ares_send.3
+@man man/man3/ares_send_dnsrec.3
@man man/man3/ares_set_local_dev.3
@man man/man3/ares_set_local_ip4.3
@man man/man3/ares_set_local_ip6.3
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
On Saturday, March 30, 2024, hahahahacker2009 <hahahahacker2009@gmail.com> wrote:
Và o Th 7, 30 thg 3, 2024 vào lúc 11:19 Dan <dan.peretz.my@gmail.com> đã viết:
>>
>>
>> > I've looked at the
>> > source code and issue tracker of upstream Firefox in the past and it has
>> > upstream support for pledge(2) and unveil(2).
>>
>> Great, you figured it out: if you want to know if a given piece of
>> software uses pledge, grep its source code for pledge.
>
>
> Sounds very tiresome and cumbersome to check. You failed to point at any rule according to which I'm not permitted to ask a general question about such software without resorting to tiresome and cumbersome manual methods like what you're suggesting here, and you consistently ignore this by bringing the same manual grep/find suggestion again and again with no sensible reason given what I explained now.
Even "friendly" linux communities would tell you to check yourself.
There's no problem in being told to do that, just as there's no problem in asking if people know about such programs without me having to tiresomely check everything. Perhaps there's a website somewhere that lists all pledged/unveiled apps and I'd be duplicating the effort needlessly?
You are wasting people's time.
Subjective.
And before spamming in the list can you make your message
fit 72 character per line and disable HTML?
First, I'm not spamming. Second, no, I can't. The Gmail web interface for mobile (which I'm using) doesn't let me disable HTML, and I don't see how I could limit line length except by manually counting characters and breaking lines, and I'm obviously not gonna do that. Sorry. I may switch to a different email client/interface in the future, this Gmail interface seems to not be paid much attention to by Google.
>
>>
>> You really need to shut the fuck up now.
>>
>> Please note that I am replying to you directly, off-list.
>> Hint: there is a reason for that.
>
>
> I am deliberately shaming you on a public mailing list because you're a troll. I may also block you in my Gmail settings if I'll find the setting in mobile. I'm giving you a middle finger.
>
> ~ | ~ | ~ | ~ | ~ | ~
>
> (Note for everyone: This message is intended to shame a troll; if you're here to follow the technical discussion only, feel free to skip reading this message.)
Dan, I see you are a troll too.
False. I asked legitimate questions and I answer honestly and precisely.
You are sending HTML emails and it doesn't fit 72 char per line.
Ditto.
It is annoying. Your message include a bunch of not needed trash.
I answer everything that's brought up as comprehensively as needed, so I don't see what's "not needed".
You ask the whole list things that you can research yourself, they are
Ditto.
not highly advanced topics. These topics are repeatedly asked by people
who will never read man pages or faq. That
That doesn't appear in the man pages or FAQ, and in my very first message I've already mentioned how Chromium, Firefox, and Tor Browser are sandboxed, so I obviously did look up things before asking here. So you're wrong here in two aspects.
attitude should only exist
on reddit/lemmy and other linux communities which tries to be "friendly".
Please elaborate, what attitude are you referring to precisely? That's a vague statement. Also, please explain the reasoning (or point to a rule) whereby the attitude should not exist here.
So please:
> Do your homework before you post.
Ditto.
I saw Jan Stary's messages
(https://marc.info/?a=108635072100004&r=1&w=2 )
are mostly answering people's question.
But your messages are asking people to do research for you.
False. I didn't tell anyone to do anything for me. I asked questions.
If you can't do research yourself, why expecting people to do it for you?
Both premises are false. Ditto.
They might think that you don't have any knowledge and thus ignore you
(for example, they think you might not understand what they are writing).
I'm not sure what logic follows from asking questions about specific things (specific as they are in the question) to drawing a conclusion that the asker lacks knowledge about things not specified/asked about in the questions. Regarding the things that are specified/asked about in the question, it's obvious that the asker doesn't know about them, because I wasn't presenting a riddle, and this is true universally to everyone. I don't understand how I'm special here from any other people that ask questions here.
Or simply, if you cannot respect yourself, why expect others to respect you?
Excuse me?
In Viet Nam, you are simply called "animals" (súc váºt, very offensive) and
then ignored.
Excuse me? What the fuck did you call me??
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
On Saturday, March 30, 2024, hahahahacker2009 <hahahahacker2009@gmail.com> wrote:
Và o Th 6, 29 thg 3, 2024 vào lúc 07:40 Dan <dan.peretz.my@gmail.com> đã viết:
> This only lists third-party packages that have an OpenBSD ports-originated addition of pledge/unveil configuration files; packages that use pledge/unveil without configuration files, or whose pledge/unveil configuration files originate from the upstream distribution, are not listed. Chromium, Ungoogled Chromium, Firefox, Firefox ESR, and Tor Browser are sandboxed, which is excellent because Web browsing is one of the most popular desktop activity and browsers are meant to use networking and execute untrusted JavaScript/WebAssembly code, and parse untrusted data like media, CSS, etc. Contrary to servers, that if they're hacked then some business might be ruined, personal computers are used to do banking and shopping online, chat with distant friends/family members/doctors/lawyers/coworkers/etc., and hold our personal thoughts and memories, so I believe that they shouldn't get compromised just because the user entered the wrong website on a bad day, or opened the wrong video, or the wrong file, etc. OpenBSD already has the excellent system calls pledge(2) and unveil(2), and already uses them extensively in the base system and for the aforementioned browsers, but what about other programs?
You can help on applying pledge and unveil to your other programs
now, instead of spamming on mailing list like this. Are you the
Nowarez Market guy again?
What spam exactly? I have no idea who is "Nowarez Market guy".
Re: UPDATE: OpenImageIO 2.5.9
On 2024-03-30 3:55 p.m., Stuart Henderson wrote:
On 2024/03/30 11:34, Stuart Henderson wrote:On 2024/03/29 08:20, Stuart Henderson wrote:On 2024/03/28 21:51, Brad Smith wrote:On Thu, Mar 28, 2024 at 04:12:55PM +0000, Stuart Henderson wrote:On 2024/03/25 23:07, Brad Smith wrote:Here is an update to OpenImageIO 2.5.9.2.4.17.0 is broken on i386 - 2.5.9 doesn't fix itI noticed a package missing on amd64 for the last two bulk builds but haven't seen anything from naddy@ yet. It builds for me on my amd64 build host.That will have been due to the problem with the cmake update and tiff - it built on amd64 in the current bulk.This appears to have something to do with the last commit to strutil_test.cpp. Try the following..Will do.FAILED: src/libutil/CMakeFiles/strutil_test.dir/strutil_test.cpp.ooops, missed -p0 on the patch command. will try again in the next bulk.
Fired up an i386 VM. Verified it fails before and builds with the diff.
Re: UPDATE: OpenImageIO 2.5.9
On 2024/03/30 11:34, Stuart Henderson wrote:
> On 2024/03/29 08:20, Stuart Henderson wrote:
> > On 2024/03/28 21:51, Brad Smith wrote:
> > > On Thu, Mar 28, 2024 at 04:12:55PM +0000, Stuart Henderson wrote:
> > > > On 2024/03/25 23:07, Brad Smith wrote:
> > > > > Here is an update to OpenImageIO 2.5.9.
> > > >
> > > > 2.4.17.0 is broken on i386 - 2.5.9 doesn't fix it
> > >
> > > I noticed a package missing on amd64 for the last two bulk builds but
> > > haven't seen anything from naddy@ yet. It builds for me on my amd64
> > > build host.
> >
> > That will have been due to the problem with the cmake update and
> > tiff - it built on amd64 in the current bulk.
> >
> > > This appears to have something to do with the last commit to strutil_test.cpp.
> > > Try the following..
> >
> > Will do.
>
> FAILED: src/libutil/CMakeFiles/strutil_test.dir/strutil_test.cpp.o
oops, missed -p0 on the patch command. will try again in the next bulk.
> On 2024/03/29 08:20, Stuart Henderson wrote:
> > On 2024/03/28 21:51, Brad Smith wrote:
> > > On Thu, Mar 28, 2024 at 04:12:55PM +0000, Stuart Henderson wrote:
> > > > On 2024/03/25 23:07, Brad Smith wrote:
> > > > > Here is an update to OpenImageIO 2.5.9.
> > > >
> > > > 2.4.17.0 is broken on i386 - 2.5.9 doesn't fix it
> > >
> > > I noticed a package missing on amd64 for the last two bulk builds but
> > > haven't seen anything from naddy@ yet. It builds for me on my amd64
> > > build host.
> >
> > That will have been due to the problem with the cmake update and
> > tiff - it built on amd64 in the current bulk.
> >
> > > This appears to have something to do with the last commit to strutil_test.cpp.
> > > Try the following..
> >
> > Will do.
>
> FAILED: src/libutil/CMakeFiles/strutil_test.dir/strutil_test.cpp.o
oops, missed -p0 on the patch command. will try again in the next bulk.
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
James Huddle <james.r.huddle@gmail.com>:
> I live in post-2016 USA and have essentially given up hope of any sort of computer security.
Personal thought and from USA where the core of private data business resides.
Due to different reasons and the env I work in I results attacked very often under OpenBSD, in X.
Having the name of the vulnerability makes not such a difference to me, thanks for the insight anyway.
However, I think to not say it wrong recalling that most of people are here for the sempliticy applied to security and portability subjects
In OpenBSD. Minimize the security subject at this point seems having a purpose, wrong.
-Dan
Mar 30, 2024 18:23:38 James Huddle <james.r.huddle@gmail.com>:
> I live in post-2016 USA and have essentially given up hope of any sort of computer security.
> I live in post-2016 USA and have essentially given up hope of any sort of computer security.
Personal thought and from USA where the core of private data business resides.
Due to different reasons and the env I work in I results attacked very often under OpenBSD, in X.
Having the name of the vulnerability makes not such a difference to me, thanks for the insight anyway.
However, I think to not say it wrong recalling that most of people are here for the sempliticy applied to security and portability subjects
In OpenBSD. Minimize the security subject at this point seems having a purpose, wrong.
-Dan
Mar 30, 2024 18:23:38 James Huddle <james.r.huddle@gmail.com>:
> I live in post-2016 USA and have essentially given up hope of any sort of computer security.
Re: lcamtuf on the recent xz debacle
I will briefly add a few links where the issue is further debated for those who are interested:
30. 3. 2024 v 11:33, Peter N. M. Hansteen <peter@bsdly.net>:
While this issue does not in fact affect OpenBSD, I think it will still be
of interest to OpenBSD users -- a lot of us deal with Linux in our dayjobs,
after all.
This is one of the best explanations of the matter I have seen so far:
https://lcamtuf.substack.com/p/technologist-vs-spy-the-xz-backdoor
and it leads in with a quote to remember -
"This dependency existed not because of a deliberate design decision
by the developers of OpenSSH, but because of a kludge added by some
Linux distributions to integrate the tool with the operating
system's newfangled orchestration service, systemd."
Enjoy!
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: [stu@spacehopper.org: Re: [NEW]: misc/openhab - open Home Automation Bus (openHAB)]
On Mon, Mar 04, 2024 at 08:25:47PM +0000, Stuart Henderson wrote:
> Hi Antoine, do you have any feedback on the rc.d parts please?
> Do you think the variabke setting bits are alright for rc.d or would
> they be better split off to a different script?
>
>
> ----- Forwarded message from Stuart Henderson <stu@spacehopper.org> -----
>
> From: Stuart Henderson <stu@spacehopper.org>
> Date: Mon, 26 Feb 2024 18:10:57 +0000
> To: Chaz Kettleson <chaz@pyr3x.com>
> Cc: A Tammy <openbsd.ports@aisha.cc>, Kirill Bychkov <kirby@linklevel.net>,
> ports@openbsd.org
> Subject: Re: [NEW]: misc/openhab - open Home Automation Bus (openHAB)
> Mail-Followup-To: Chaz Kettleson <chaz@pyr3x.com>, A Tammy
> <openbsd.ports@aisha.cc>, Kirill Bychkov <kirby@linklevel.net>,
> ports@openbsd.org
>
> Here are some tweaks on top (sent as a diff for commentary and a new
> tar).
>
> I'd like the opinion of someone with a hand in the rc.d system to
> comment on that part. Maybe they'll be ok with it, but it's a bit
> complicated and not something that I think we do in any other ports.
> On the other hand I'm not sure I can think of a nice alternative..
>
> : diff --git a/misc/openhab/Makefile b/misc/openhab/Makefile
> : index 3ff4984..dc582de 100644
> : --- a/misc/openhab/Makefile
> : +++ b/misc/openhab/Makefile
> : @@ -28,16 +28,12 @@ pre-extract:
> : @mkdir ${WRKDIST}
> :
> : do-install:
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/
> : + ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/openhab/
>
> the ${PKGSTEM} indirection isn't really useful imho and makes it harder
> to read, I've replaced with openhab throughout
>
> : - ${INSTALL_DATA} ${FILESDIR}/${PKGSTEM}.conf \
> : - ${PREFIX}/share/examples/${PKGSTEM}/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/libexec/${PKGSTEM}/
> : - @cd ${WRKDIST} && openrsync --rsync-path=openrsync -a \
> : - --exclude={'./conf','./userdata'} . ${PREFIX}/libexec/${PKGSTEM}/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/etc/
> : - @cd ${WRKDIST}/conf && pax -rw . ${PREFIX}/share/examples/${PKGSTEM}/etc/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/var/
> : - @cd ${WRKDIST}/userdata && pax -rw . \
> : - ${PREFIX}/share/examples/${PKGSTEM}/var/
> : + ${INSTALL_DATA} ${FILESDIR}/openhab.conf \
> : + ${PREFIX}/share/examples/openhab/
> : + ${INSTALL_DATA_DIR} ${PREFIX}/libexec/openhab/
> : + cd ${WRKDIST} && pax -rw . ${PREFIX}/libexec/openhab/
> : + mv ${PREFIX}/libexec/openhab/conf ${PREFIX}/share/examples/openhab/
> : + mv ${PREFIX}/libexec/openhab/userdata ${PREFIX}/share/examples/openhab/
>
> not really a fan of using openrsync to copy files around, so I've
> replaced it by copying all files with pax to libexec, then moving the
> couple of dirs which should end up in examples. I kept the original
> dir names and adjusted PLIST to match.
>
> : diff --git a/misc/openhab/pkg/PLIST b/misc/openhab/pkg/PLIST
> : index 1e76d42..8144a30 100644
> : --- a/misc/openhab/pkg/PLIST
> : +++ b/misc/openhab/pkg/PLIST
> : @@ -1,6 +1,5 @@
> : -@newgroup _openhab:896
> : -@newuser _openhab:896:_openhab::openHAB user:/nonexistent:/sbin/nologin
> : +@newgroup _openhab:897
> : +@newuser _openhab:897:_openhab::openHAB user:/nonexistent:/sbin/nologin
>
> 896 is taken now, switch to 897
>
> : -@exec-add usermod -G dialer _openhab
>
> I don't think the package should auto-add itself to what in some
> circumstances could be a sensitive group. Could maybe be suggested
> in the readme (I haven't done so myself because I don't know which
> circumstances need it and I think that should be explained).
>
> : @rcscript ${RCDIR}/openhab
> : libexec/openhab/
> : libexec/openhab/LICENSE.TXT
> : @@ -1225,203 +1224,203 @@ libexec/openhab/start_debug.sh
> : share/doc/pkg-readmes/${PKGSTEM}
> : share/examples/openhab/
> : @sample ${SYSCONFDIR}/openhab/
> : -share/examples/openhab/etc/
> : +share/examples/openhab/conf/
> ...
> <snip mechanical changes relating to paths in share/examples>
>
> : diff --git a/misc/openhab/pkg/openhab.rc b/misc/openhab/pkg/openhab.rc
> : index ea7a859..4284a62 100644
> : --- a/misc/openhab/pkg/openhab.rc
> : +++ b/misc/openhab/pkg/openhab.rc
> : @@ -1,7 +1,7 @@
> : #!/bin/ksh
> :
> : -JAVA="$(${LOCALBASE}/bin/javaPathHelper -c ${PKGSTEM})"
> : -JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h ${PKGSTEM})"
> : +JAVA="$(${LOCALBASE}/bin/javaPathHelper -c openhab)"
> : +JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h openhab)"
>
> avoid indirection again
>
> : # Read configuration variable file if it is present
> : if [ -r /etc/openhab.conf ]; then
> : @@ -13,12 +13,12 @@ if [ -z "${EXTRA_JAVA_OPTS}" ]; then EXTRA_JAVA_OPTS="-Dsun.nio.fs.watchservice
> : if [ -z "${OPENHAB_HTTP_ADDRESS}" ]; then OPENHAB_HTTP_ADDRESS="127.0.0.1"; fi
> : if [ -z "${OPENHAB_HTTP_PORT}" ]; then OPENHAB_HTTP_PORT=8080; fi
> : if [ -z "${OPENHAB_HTTPS_PORT}" ]; then OPENHAB_HTTPS_PORT=8443; fi
> : -if [ -z "${OPENHAB_HOME}" ]; then OPENHAB_HOME="${PREFIX}/libexec/${PKGSTEM}"; fi
> : -if [ -z "${OPENHAB_CONF}" ]; then OPENHAB_CONF="${SYSCONFDIR}/${PKGSTEM}"; fi
> : +if [ -z "${OPENHAB_HOME}" ]; then OPENHAB_HOME="${PREFIX}/libexec/openhab"; fi
> : +if [ -z "${OPENHAB_CONF}" ]; then OPENHAB_CONF="${SYSCONFDIR}/openhab"; fi
> : if [ -z "${OPENHAB_RUNTIME}" ]; then OPENHAB_RUNTIME="${OPENHAB_HOME}/runtime"; fi
> : -if [ -z "${OPENHAB_USERDATA}" ]; then OPENHAB_USERDATA="/var/db/${PKGSTEM}"; fi
> : +if [ -z "${OPENHAB_USERDATA}" ]; then OPENHAB_USERDATA="/var/db/openhab"; fi
> : if [ -z "${OPENHAB_BACKUPS}" ]; then OPENHAB_BACKUPS="${OPENHAB_USERDATA}/backups"; fi
> : -if [ -z "${OPENHAB_LOGDIR}" ]; then OPENHAB_LOGDIR="/var/log/${PKGSTEM}"; fi
> : +if [ -z "${OPENHAB_LOGDIR}" ]; then OPENHAB_LOGDIR="/var/log/openhab"; fi
> :
> : ENV="JAVA_HOME=${JAVA_HOME} \
> : EXTRA_JAVA_OPTS=\"${EXTRA_JAVA_OPTS}\" \
>
>
>
>
> ----- End forwarded message -----
ping...it's been a while. Is this OK for commit now?
--
Chaz
> Hi Antoine, do you have any feedback on the rc.d parts please?
> Do you think the variabke setting bits are alright for rc.d or would
> they be better split off to a different script?
>
>
> ----- Forwarded message from Stuart Henderson <stu@spacehopper.org> -----
>
> From: Stuart Henderson <stu@spacehopper.org>
> Date: Mon, 26 Feb 2024 18:10:57 +0000
> To: Chaz Kettleson <chaz@pyr3x.com>
> Cc: A Tammy <openbsd.ports@aisha.cc>, Kirill Bychkov <kirby@linklevel.net>,
> ports@openbsd.org
> Subject: Re: [NEW]: misc/openhab - open Home Automation Bus (openHAB)
> Mail-Followup-To: Chaz Kettleson <chaz@pyr3x.com>, A Tammy
> <openbsd.ports@aisha.cc>, Kirill Bychkov <kirby@linklevel.net>,
> ports@openbsd.org
>
> Here are some tweaks on top (sent as a diff for commentary and a new
> tar).
>
> I'd like the opinion of someone with a hand in the rc.d system to
> comment on that part. Maybe they'll be ok with it, but it's a bit
> complicated and not something that I think we do in any other ports.
> On the other hand I'm not sure I can think of a nice alternative..
>
> : diff --git a/misc/openhab/Makefile b/misc/openhab/Makefile
> : index 3ff4984..dc582de 100644
> : --- a/misc/openhab/Makefile
> : +++ b/misc/openhab/Makefile
> : @@ -28,16 +28,12 @@ pre-extract:
> : @mkdir ${WRKDIST}
> :
> : do-install:
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/
> : + ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/openhab/
>
> the ${PKGSTEM} indirection isn't really useful imho and makes it harder
> to read, I've replaced with openhab throughout
>
> : - ${INSTALL_DATA} ${FILESDIR}/${PKGSTEM}.conf \
> : - ${PREFIX}/share/examples/${PKGSTEM}/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/libexec/${PKGSTEM}/
> : - @cd ${WRKDIST} && openrsync --rsync-path=openrsync -a \
> : - --exclude={'./conf','./userdata'} . ${PREFIX}/libexec/${PKGSTEM}/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/etc/
> : - @cd ${WRKDIST}/conf && pax -rw . ${PREFIX}/share/examples/${PKGSTEM}/etc/
> : - ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${PKGSTEM}/var/
> : - @cd ${WRKDIST}/userdata && pax -rw . \
> : - ${PREFIX}/share/examples/${PKGSTEM}/var/
> : + ${INSTALL_DATA} ${FILESDIR}/openhab.conf \
> : + ${PREFIX}/share/examples/openhab/
> : + ${INSTALL_DATA_DIR} ${PREFIX}/libexec/openhab/
> : + cd ${WRKDIST} && pax -rw . ${PREFIX}/libexec/openhab/
> : + mv ${PREFIX}/libexec/openhab/conf ${PREFIX}/share/examples/openhab/
> : + mv ${PREFIX}/libexec/openhab/userdata ${PREFIX}/share/examples/openhab/
>
> not really a fan of using openrsync to copy files around, so I've
> replaced it by copying all files with pax to libexec, then moving the
> couple of dirs which should end up in examples. I kept the original
> dir names and adjusted PLIST to match.
>
> : diff --git a/misc/openhab/pkg/PLIST b/misc/openhab/pkg/PLIST
> : index 1e76d42..8144a30 100644
> : --- a/misc/openhab/pkg/PLIST
> : +++ b/misc/openhab/pkg/PLIST
> : @@ -1,6 +1,5 @@
> : -@newgroup _openhab:896
> : -@newuser _openhab:896:_openhab::openHAB user:/nonexistent:/sbin/nologin
> : +@newgroup _openhab:897
> : +@newuser _openhab:897:_openhab::openHAB user:/nonexistent:/sbin/nologin
>
> 896 is taken now, switch to 897
>
> : -@exec-add usermod -G dialer _openhab
>
> I don't think the package should auto-add itself to what in some
> circumstances could be a sensitive group. Could maybe be suggested
> in the readme (I haven't done so myself because I don't know which
> circumstances need it and I think that should be explained).
>
> : @rcscript ${RCDIR}/openhab
> : libexec/openhab/
> : libexec/openhab/LICENSE.TXT
> : @@ -1225,203 +1224,203 @@ libexec/openhab/start_debug.sh
> : share/doc/pkg-readmes/${PKGSTEM}
> : share/examples/openhab/
> : @sample ${SYSCONFDIR}/openhab/
> : -share/examples/openhab/etc/
> : +share/examples/openhab/conf/
> ...
> <snip mechanical changes relating to paths in share/examples>
>
> : diff --git a/misc/openhab/pkg/openhab.rc b/misc/openhab/pkg/openhab.rc
> : index ea7a859..4284a62 100644
> : --- a/misc/openhab/pkg/openhab.rc
> : +++ b/misc/openhab/pkg/openhab.rc
> : @@ -1,7 +1,7 @@
> : #!/bin/ksh
> :
> : -JAVA="$(${LOCALBASE}/bin/javaPathHelper -c ${PKGSTEM})"
> : -JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h ${PKGSTEM})"
> : +JAVA="$(${LOCALBASE}/bin/javaPathHelper -c openhab)"
> : +JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h openhab)"
>
> avoid indirection again
>
> : # Read configuration variable file if it is present
> : if [ -r /etc/openhab.conf ]; then
> : @@ -13,12 +13,12 @@ if [ -z "${EXTRA_JAVA_OPTS}" ]; then EXTRA_JAVA_OPTS="-Dsun.nio.fs.watchservice
> : if [ -z "${OPENHAB_HTTP_ADDRESS}" ]; then OPENHAB_HTTP_ADDRESS="127.0.0.1"; fi
> : if [ -z "${OPENHAB_HTTP_PORT}" ]; then OPENHAB_HTTP_PORT=8080; fi
> : if [ -z "${OPENHAB_HTTPS_PORT}" ]; then OPENHAB_HTTPS_PORT=8443; fi
> : -if [ -z "${OPENHAB_HOME}" ]; then OPENHAB_HOME="${PREFIX}/libexec/${PKGSTEM}"; fi
> : -if [ -z "${OPENHAB_CONF}" ]; then OPENHAB_CONF="${SYSCONFDIR}/${PKGSTEM}"; fi
> : +if [ -z "${OPENHAB_HOME}" ]; then OPENHAB_HOME="${PREFIX}/libexec/openhab"; fi
> : +if [ -z "${OPENHAB_CONF}" ]; then OPENHAB_CONF="${SYSCONFDIR}/openhab"; fi
> : if [ -z "${OPENHAB_RUNTIME}" ]; then OPENHAB_RUNTIME="${OPENHAB_HOME}/runtime"; fi
> : -if [ -z "${OPENHAB_USERDATA}" ]; then OPENHAB_USERDATA="/var/db/${PKGSTEM}"; fi
> : +if [ -z "${OPENHAB_USERDATA}" ]; then OPENHAB_USERDATA="/var/db/openhab"; fi
> : if [ -z "${OPENHAB_BACKUPS}" ]; then OPENHAB_BACKUPS="${OPENHAB_USERDATA}/backups"; fi
> : -if [ -z "${OPENHAB_LOGDIR}" ]; then OPENHAB_LOGDIR="/var/log/${PKGSTEM}"; fi
> : +if [ -z "${OPENHAB_LOGDIR}" ]; then OPENHAB_LOGDIR="/var/log/openhab"; fi
> :
> : ENV="JAVA_HOME=${JAVA_HOME} \
> : EXTRA_JAVA_OPTS=\"${EXTRA_JAVA_OPTS}\" \
>
>
>
>
> ----- End forwarded message -----
ping...it's been a while. Is this OK for commit now?
--
Chaz
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
When X11 came to my attention, in the 1980's, it was called X11. "What," I wondered back then, "could that mean?"
Back then, we would get to know new software long before version 11, so it seemed an odd name. Back then.
It's been X11 for millennia. I discovered Exfiltrator (or Exfiltration, 'ex'+10) about a year ago. LOL.
I actually did not know about the vulnerability. Thanks, Matthew.
And yes, I was voicing the untested theory of precisely what you articulated, Luke.
I live in post-2016 USA and have essentially given up hope of any sort of computer security.
The mantra I developed, as my coworkers insisted on using (for instance) the React JS package
that had "Exfil" as a dependency, was:
"When in Rome."
On Fri, Mar 29, 2024 at 4:44 PM <chohag@jtan.com> wrote:
Luke A. Call writes:
>
> On 2024-03-29 09:01:07-0400, James Huddle <james.r.huddle@gmail.com> wrote:
> > Exfiltrator. There's an 11-letter word that starts with "ex". X11.
>
> After a quick web search, I'm not sure I follow. Is that a reference to
> a program that exfiltrates data after a computer is compromised? Can you
> elaborate a little? I realize this is an ignorant question.
In short, there is a well known shortcoming or feature depending
on who you ask inherent in the X protocol's design where any
application which uses the X server (ie. can access the tcp port
or unix socket and has the correct xauth key, which is to say all
of them) can request (and get) the ability to read all of the X
events, which includes every key press and mouse movement in every
application.
Exfiltrator is 11 letters and we are at X protocol version 11.
There are common mitigations against this problem, such as not
giving strangers the ability to run unknown programs on your console.
Matthew
Re: wifi hotspot workaround
On Sat, Mar 30, 2024 at 08:59:49PM +0500, ofthecentury wrote:
> And now something else happened, which seems like a big
> bug.
> athn0 sent a reason 6 deauthentication to my wifi client
> after I cycled the athn0 wifi interface!
> Reason 6 death is class 2 frame received from a nonauthenticated
> station. Correct me if I'm wrong, but this sounds like a major
> bug in the driver.
Or shitty hardware with a helping of possibly not-too-great firmware.
With a bit of luck, any errors from the card itself should be possible to glean
from dmesg output.
(on a side note, I am on the list, the Cc:s are not necessary and in fact
a bit annoying)
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> And now something else happened, which seems like a big
> bug.
> athn0 sent a reason 6 deauthentication to my wifi client
> after I cycled the athn0 wifi interface!
> Reason 6 death is class 2 frame received from a nonauthenticated
> station. Correct me if I'm wrong, but this sounds like a major
> bug in the driver.
Or shitty hardware with a helping of possibly not-too-great firmware.
With a bit of luck, any errors from the card itself should be possible to glean
from dmesg output.
(on a side note, I am on the list, the Cc:s are not necessary and in fact
a bit annoying)
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: wifi hotspot workaround
And now something else happened, which seems like a big
bug.
athn0 sent a reason 6 deauthentication to my wifi client
after I cycled the athn0 wifi interface!
Reason 6 death is class 2 frame received from a nonauthenticated
station. Correct me if I'm wrong, but this sounds like a major
bug in the driver. It's basically the wifi driver deauthenticates
a client who is AUTHENTICATED but just not associated at the
moment of receipt of that class 2 frame? The logical thing would
be for the driver/AP to re-associate the client because it's already
authenticated, versus what it's doing now - deauthenticating
an already authenticated client. I don't even understand why
the athn0 hostap wouldn't just re-associate the already authenticated
client, especially since I have the nwflag "stayauth" turned on
on the interface.
On Sat, Mar 30, 2024 at 8:30 PM ofthecentury <ofthecentury@gmail.com> wrote:
>
> Ok, I also just got reason 16 deauth happen. It says it was
> sending msg 1/2 of the group key handshake to my wifi client,
> it repeated it twice, and then the reason 16 deauth happened.
> Then it says deauth to the wifi client and then wifi client was
> purged from node cache. And now, the network SSID does not
> show up in the list of wireless network on my wifi client!
> athn0 appears as "UP" in ifconfig.
> THEN, I cycle athn0 down/up, and then the wifi client finds
> the network immediately and reconnects.
> What is going on here??
>
> On Sat, Mar 30, 2024 at 7:47 PM Peter N. M. Hansteen <peter@bsdly.net> wrote:
> >
> > On Sat, Mar 30, 2024 at 05:44:32PM +0500, ofthecentury wrote:
> > > On Sat, Mar 30, 2024 at 5:29 PM Peter N. M. Hansteen <peter@bsdly.net> wrote:
> > > >
> > > > why?
> > >
> > > I got "disassoc"s events in the log.
> >
> > disassociations can happen for a number of different reasons. The event
> > should log a reason code, which you can look up with a simple web search.
> >
> > In order to debug properly it would likely help to have ifconfig debug
> > output from both sides (access point and client both).
> >
> > I would suspect banal radio interference by such things as improperly
> > shielded equipment somewhere close by, but with no actual data it's
> > only guesswork from here.
> >
> > --
> > Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
> > "Remember to set the evil bit on all malicious network traffic"
> > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> >
bug.
athn0 sent a reason 6 deauthentication to my wifi client
after I cycled the athn0 wifi interface!
Reason 6 death is class 2 frame received from a nonauthenticated
station. Correct me if I'm wrong, but this sounds like a major
bug in the driver. It's basically the wifi driver deauthenticates
a client who is AUTHENTICATED but just not associated at the
moment of receipt of that class 2 frame? The logical thing would
be for the driver/AP to re-associate the client because it's already
authenticated, versus what it's doing now - deauthenticating
an already authenticated client. I don't even understand why
the athn0 hostap wouldn't just re-associate the already authenticated
client, especially since I have the nwflag "stayauth" turned on
on the interface.
On Sat, Mar 30, 2024 at 8:30 PM ofthecentury <ofthecentury@gmail.com> wrote:
>
> Ok, I also just got reason 16 deauth happen. It says it was
> sending msg 1/2 of the group key handshake to my wifi client,
> it repeated it twice, and then the reason 16 deauth happened.
> Then it says deauth to the wifi client and then wifi client was
> purged from node cache. And now, the network SSID does not
> show up in the list of wireless network on my wifi client!
> athn0 appears as "UP" in ifconfig.
> THEN, I cycle athn0 down/up, and then the wifi client finds
> the network immediately and reconnects.
> What is going on here??
>
> On Sat, Mar 30, 2024 at 7:47 PM Peter N. M. Hansteen <peter@bsdly.net> wrote:
> >
> > On Sat, Mar 30, 2024 at 05:44:32PM +0500, ofthecentury wrote:
> > > On Sat, Mar 30, 2024 at 5:29 PM Peter N. M. Hansteen <peter@bsdly.net> wrote:
> > > >
> > > > why?
> > >
> > > I got "disassoc"s events in the log.
> >
> > disassociations can happen for a number of different reasons. The event
> > should log a reason code, which you can look up with a simple web search.
> >
> > In order to debug properly it would likely help to have ifconfig debug
> > output from both sides (access point and client both).
> >
> > I would suspect banal radio interference by such things as improperly
> > shielded equipment somewhere close by, but with no actual data it's
> > only guesswork from here.
> >
> > --
> > Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
> > "Remember to set the evil bit on all malicious network traffic"
> > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> >
Subscribe to:
Posts (Atom)