wayland/input-event-codes: new port for wayland compat (bulk wanted)
Hi, wayland/input-event-codes intents is to provide input-event-codes definition from linux headers. Wayland defines several constants as "code as defined in the Linux kernel's linux/input-event-codes.h header file". This port exports linux/input-event-codes.h header (only comments and #define) and linux/input.h (which only include the previous header). including linux/input.h is the usual way to get input-event-codes definition. Such headers is necessary to properly build some libraries or programs with wayland support (without defining the constants like BTN_LEFT with patches). The port itself is very simple, but the fallout to have ports picking is somehow important. If possible, I would like to have a bulk build with wayland/input-event-codes installed, in order to see if the presence of linux/input.h header makes problems or not. Thanks. -- Sebastien Marie input-event-codes.tgz Description: application/tar-gz
Re: net/rsync: CVE-2022-29154 fix
"T.J. Townsend" writes: >> https://www.openwall.com/lists/oss-security/2022/08/02/1 >> https://github.com/WayneD/rsync/commit/b7231c7d02.patch Here is a diff that updates to 3.2.5pre1 to cover tj@'s backported fix + additional related fixes. This way, no local patches are needed. I am a bit concerned about the stability of rsync 3.2.5 since it is a prerelease and the "false alerts" from the announcement. It might be worth it in this case? announcement: https://lists.samba.org/archive/rsync-announce/2022/000112.html > > Updated diff that also fixes CVE-2022-37434 in the bundled zlib: zlib fix is not needed because inflateGetHeader is not called. "NOTE: only applications that call inflateGetHeader are affected." see: https://www.cve.org/CVERecord?id=CVE-2022-37434 OK? Index: Makefile === RCS file: /cvs/ports/net/rsync/Makefile,v retrieving revision 1.93 diff -u -p -u -p -r1.93 Makefile --- Makefile23 May 2022 00:24:58 - 1.93 +++ Makefile6 Aug 2022 03:42:44 - @@ -1,6 +1,6 @@ COMMENT = mirroring/synchronization over low bandwidth links -DISTNAME = rsync-3.2.4 +DISTNAME = rsync-3.2.5pre1 CATEGORIES = net HOMEPAGE = https://rsync.samba.org/ @@ -12,8 +12,7 @@ PERMIT_PACKAGE = Yes WANTLIB = c crypto -MASTER_SITES = https://rsync.samba.org/ftp/rsync/src/ \ - https://ftp.funet.fi/pub/mirrors/samba.org/pub/rsync/src/ +MASTER_SITES = https://rsync.samba.org/ftp/rsync/src-previews/ MODULES = lang/python Index: distinfo === RCS file: /cvs/ports/net/rsync/distinfo,v retrieving revision 1.32 diff -u -p -u -p -r1.32 distinfo --- distinfo23 May 2022 00:24:58 - 1.32 +++ distinfo6 Aug 2022 03:42:44 - @@ -1,2 +1,2 @@ -SHA256 (rsync-3.2.4.tar.gz) = b3YYONCAUrC2V5z39nN9k+R/AfTaBMXSTTRHt/Kl+tE= -SIZE (rsync-3.2.4.tar.gz) = 1114853 +SHA256 (rsync-3.2.5pre1.tar.gz) = wBhH4x3zI183EQMLxNIP3xkhi0zTzTthj0WcD0K1YjY= +SIZE (rsync-3.2.5pre1.tar.gz) = 1126641
Re: [NEW] math/datamash
On Fri, Aug 05 2022, Job Snijders wrote: > $ pkg_info datamash > Information for inst:datamash-1.8p0 > > Comment: > perform basic numeric, textual and statistical operations > > Description: > GNU datamash is a command-line program which performs basic numeric, textual > and statistical operations on input textual data files. > > Maintainer: The OpenBSD ports mailing-list > > WWW: https://www.gnu.org/software/datamash/ A few issues addressed: - drop REVISION (not needed for a new port or an update) - add #uses pledge() marker - add missing LIB_DEPENDS and WANTLIB: this uses libiconv and gettext (make port-lib-depends-check). Drop directories from the PLIST which are shipped by the gettext port (make plist). Also add libm to WANTLIB. - move bash-completion to the standard bash-completion directory Updated tarball attached, ok jca@ to import datamash.tgz Description: Binary data -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: coturn: specify pidfile and create directory in rc_pre
Andre Stoebe wrote: > On 05.08.2022 18:28, Omar Polo wrote: >> which version? are you using some custom flags in /etc/rc.conf.local? >> By any chance, did you enabled(/uncommented) the `pidfile' directive >> in /etc/turnserver.conf? > > I'm also running 4.5.2p2 on OpenBSD 7.1-stable without any custom flags > in /etc/rc.conf.local. The following is logged to syslog after startup: > > turnserver: 0: : Cannot create pid file: /var/run/turnserver.pid > turnserver: 0: : pid file created: /var/tmp/turnserver.pid > > And the pidfile exists: > > $ ls -l /tmp/turnserver.pid > -rw-r--r-- 1 _turnserver wheel 6 Aug 5 22:18 /tmp/turnserver.pid > > I certainly don't have pidfile set in /etc/turnserver.conf, but maybe > any of these options I use are responsible for this: > > # egrep -v -e '^#' -e '^$' /etc/turnserver.conf | cut -d= -f1 | sort -u > alt-listening-port > listening-ip > no-cli > no-dtls > no-multicast-peers > no-software-attribute > no-tcp > no-tcp-relay > no-tls > realm > relay-ip > static-auth-secret > syslog > use-auth-secret > > I have to check this in more detail tomorrow. So, I removed all options and the pidfile is still created: # egrep -v -e '^#' -e '^$' /etc/turnserver.conf # ls -l /tmp/turnserver.pid ls: /tmp/turnserver.pid: No such file or directory # rcctl start turnserver turnserver(ok) # ls -l /tmp/turnserver.pid -rw-r--r-- 1 _turnserver wheel 6 Aug 6 01:15 /tmp/turnserver.pid You really don't see the same behaviour, Omar? I don't have anything set, neither in /etc/rc.conf.local nor in /etc/rc.d/turnserver.
Re: coturn: specify pidfile and create directory in rc_pre
Hey, On 05.08.2022 18:28, Omar Polo wrote: > which version? are you using some custom flags in /etc/rc.conf.local? > By any chance, did you enabled(/uncommented) the `pidfile' directive > in /etc/turnserver.conf? I'm also running 4.5.2p2 on OpenBSD 7.1-stable without any custom flags in /etc/rc.conf.local. The following is logged to syslog after startup: turnserver: 0: : Cannot create pid file: /var/run/turnserver.pid turnserver: 0: : pid file created: /var/tmp/turnserver.pid And the pidfile exists: $ ls -l /tmp/turnserver.pid -rw-r--r-- 1 _turnserver wheel 6 Aug 5 22:18 /tmp/turnserver.pid I certainly don't have pidfile set in /etc/turnserver.conf, but maybe any of these options I use are responsible for this: # egrep -v -e '^#' -e '^$' /etc/turnserver.conf | cut -d= -f1 | sort -u alt-listening-port listening-ip no-cli no-dtls no-multicast-peers no-software-attribute no-tcp no-tcp-relay no-tls realm relay-ip static-auth-secret syslog use-auth-secret I have to check this in more detail tomorrow. On 05.08.2022 18:31, Stuart Henderson wrote: > the "daemon" variable should only be what's _required_ to run it, > something like --pidfile (if it is indeed required) should be in daemon_flags > so it can be overridden Right, my bad, sorry. I will send a correct diff when this is clarified and indeed required.
Repeated gimp crashes?
I'm not a heavy user of gimp, but I've noticed it segfaulting regularly (e.g. when saving, adjusting colours) whenever I've tried using it in the last couple of weeks or more. Having updated my amd64 snapshot + packages this morning to I'm still seeing problems. Here's an example backtrace from github which suggests the problem might be in bable? I wonder if anyone else has seen this problem, or has any idea what it might be (or what might have caused it)? Program received signal SIGSEGV, Segmentation fault. [Switching to thread 523403] 0x0445260f63ec in rgbaf_to_Labaf_sse2 () from /usr/local/lib/babl-0.1/x86-64-v3-CIE.so (gdb) bt #0 0x0445260f63ec in rgbaf_to_Labaf_sse2 () from /usr/local/lib/babl-0.1/x86-64-v3-CIE.so #1 0x088ef45c in babl_fish_lut_process_maybe () from /usr/local/lib/libbabl-0.1.so.1.8 #2 0x088eddab in babl_fish_path_process () from /usr/local/lib/libbabl-0.1.so.1.8 #3 0x088ee04c in babl_process_rows () from /usr/local/lib/libbabl-0.1.so.1.8 #4 0x044526c67852 in gegl_buffer_iterate_read_simple () from /usr/local/lib/libgegl-0.4.so.0.5 #5 0x044526c6626d in gegl_buffer_iterate_read_dispatch () from /usr/local/lib/libgegl-0.4.so.0.5 #6 0x044526c625ed in _gegl_buffer_get_unlocked () from /usr/local/lib/libgegl-0.4.so.0.5 #7 0x044526c6a05b in load_rects () from /usr/local/lib/libgegl-0.4.so.0.5 #8 0x044526c69e82 in gegl_buffer_iterator_next () from /usr/local/lib/libgegl-0.4.so.0.5 #9 0x044526ca4751 in thread_process () from /usr/local/lib/libgegl-0.4.so.0.5 #10 0x044526c45c10 in gegl_parallel_distribute_area_func () from /usr/local/lib/libgegl-0.4.so.0.5 #11 0x044526c45d90 in gegl_parallel_distribute_thread_func () from /usr/local/lib/libgegl-0.4.so.0.5 #12 0x052ba715 in g_thread_proxy () ---Type to continue, or q to quit--- from /usr/local/lib/libglib-2.0.so.4201.8 #13 0x08b05a01 in _rthread_start (v=Unhandled dwarf expression opcode 0xa3 ) at /usr/src/lib/librthread/rthread.c:96 #14 0x0444f396197a in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 #15 0x0444f396197a in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 Previous frame identical to this frame (corrupt stack?) (gdb) I don't rule out that I'm doing something stupid, though I must admit that I'm not sure what that might be! Laurie
Re: net/rsync: CVE-2022-29154 fix
> https://www.openwall.com/lists/oss-security/2022/08/02/1
> https://github.com/WayneD/rsync/commit/b7231c7d02.patch
Updated diff that also fixes CVE-2022-37434 in the bundled zlib:
Index: Makefile
===
RCS file: /cvs/ports/net/rsync/Makefile,v
retrieving revision 1.93
diff -u -p -r1.93 Makefile
--- Makefile23 May 2022 00:24:58 - 1.93
+++ Makefile5 Aug 2022 20:25:11 -
@@ -1,6 +1,7 @@
COMMENT = mirroring/synchronization over low bandwidth links
DISTNAME = rsync-3.2.4
+REVISION = 0
CATEGORIES = net
HOMEPAGE = https://rsync.samba.org/
Index: patches/patch-exclude_c
===
RCS file: patches/patch-exclude_c
diff -N patches/patch-exclude_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-exclude_c 5 Aug 2022 20:25:11 -
@@ -0,0 +1,182 @@
+CVE-2022-29154
+
+Index: exclude.c
+--- exclude.c.orig
exclude.c
+@@ -27,16 +27,22 @@ extern int am_server;
+ extern int am_sender;
+ extern int eol_nulls;
+ extern int io_error;
++extern int xfer_dirs;
++extern int recurse;
+ extern int local_server;
+ extern int prune_empty_dirs;
+ extern int ignore_perishable;
++extern int old_style_args;
++extern int relative_paths;
+ extern int delete_mode;
+ extern int delete_excluded;
+ extern int cvs_exclude;
+ extern int sanitize_paths;
+ extern int protocol_version;
++extern int list_only;
+ extern int module_id;
+
++extern char *filesfrom_host;
+ extern char curr_dir[MAXPATHLEN];
+ extern unsigned int curr_dir_len;
+ extern unsigned int module_dirlen;
+@@ -44,8 +50,10 @@ extern unsigned int module_dirlen;
+ filter_rule_list filter_list = { .debug_type = "" };
+ filter_rule_list cvs_filter_list = { .debug_type = " [global CVS]" };
+ filter_rule_list daemon_filter_list = { .debug_type = " [daemon]" };
++filter_rule_list implied_filter_list = { .debug_type = " [implied]" };
+
+ int saw_xattr_filter = 0;
++int trust_sender_filter = 0;
+
+ /* Need room enough for ":MODS " prefix plus some room to grow. */
+ #define MAX_RULE_PREFIX (16)
+@@ -292,6 +300,125 @@ static void add_rule(filter_rule_list *listp, const ch
+ }
+ }
+
++/* Each arg the client sends to the remote sender turns into an implied
include
++ * that the receiver uses to validate the file list from the sender. */
++void add_implied_include(const char *arg)
++{
++ filter_rule *rule;
++ int arg_len, saw_wild = 0, backslash_cnt = 0;
++ int slash_cnt = 1; /* We know we're adding a leading slash. */
++ const char *cp;
++ char *p;
++ if (old_style_args || list_only || filesfrom_host != NULL)
++ return;
++ if (relative_paths) {
++ cp = strstr(arg, "/./");
++ if (cp)
++ arg = cp+3;
++ } else {
++ if ((cp = strrchr(arg, '/')) != NULL)
++ arg = cp + 1;
++ }
++ arg_len = strlen(arg);
++ if (arg_len) {
++ if (strpbrk(arg, "*[?")) {
++ /* We need to add room to escape backslashes if
wildcard chars are present. */
++ cp = arg;
++ while ((cp = strchr(cp, '\\')) != NULL) {
++ arg_len++;
++ cp++;
++ }
++ saw_wild = 1;
++ }
++ arg_len++; /* Leave room for the prefixed slash */
++ rule = new0(filter_rule);
++ if (!implied_filter_list.head)
++ implied_filter_list.head = implied_filter_list.tail =
rule;
++ else {
++ rule->next = implied_filter_list.head;
++ implied_filter_list.head = rule;
++ }
++ rule->rflags = FILTRULE_INCLUDE + (saw_wild ? FILTRULE_WILD :
0);
++ p = rule->pattern = new_array(char, arg_len + 1);
++ *p++ = '/';
++ cp = arg;
++ while (*cp) {
++ switch (*cp) {
++case '\\':
++ backslash_cnt++;
++ if (saw_wild)
++ *p++ = '\\';
++ *p++ = *cp++;
++ break;
++case '/':
++ if (p[-1] == '/') /* This is safe because of
the initial slash. */
++ break;
++ if (relative_paths) {
++ filter_rule const *ent;
++ int found = 0;
++ *p = '\0';
++ for (ent = implied_filter_list.head;
ent; ent = ent->next) {
++ if (ent != rule &&
strcmp(ent->pattern, rule->pattern) == 0)
+
kibana in OpenBSD 7.1
Hello Pavel, ports, contacting you as a maintainer of kibana, logstash and elasticsearch; Does kibana still work for you in OpenBSD 7.1? I was able to get it running on OpenBSD 7.0 by hardcoding node version (10.x->12.22.6) in /usr/local/kibana/package.json, but same trick stopped working in 7.1, where system node is at 16.16.0. Kibana starts, but in web browser, it just shows loading animation and eventually ends up with cryptic error. # rcctl -d start kibana doing _rc_parse_conf doing _rc_quirks kibana_flags empty, using default >< doing rc_check kibana doing rc_start doing _rc_wait_for_start doing rc_check No home directory /nonexistent! Logging in with home = "/". doing rc_check Alarm clock doing _rc_write_runfile (ok) ... Kibana does not support the current Node.js version v16.16.0. Please use Node.js v12.16.1. Elastic runs on same host at localhost:9200 The error is: NetworkError when attempting to fetch resource. Version: 7.10.0 Build: 35949 Error: NetworkError when attempting to fetch resource. _construct@http://localhost:5601/35949/bundles/core/core.entry.js:6:4859 Wrapper@http://localhost:5601/35949/bundles/core/core.entry.js:6:4249 _createSuperInternal@http://localhost:5601/35949/bundles/core/core.entry.js:6:3388 HttpFetchError@http://localhost:5601/35949/bundles/core/core.entry.js:6:6016 _callee3$@http://localhost:5601/35949/bundles/core/core.entry.js:6:58583 l@http://localhost:5601/35949/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:380:1740519 s/o._invokehttp://localhost:5601/35949/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:380:1740273 _/http://localhost:5601/35949/bundles/kbn-ui-shared-deps/kbn-ui-shared-deps.js:380:1740876 fetch_asyncGeneratorStep@http://localhost:5601/35949/bundles/core/core.entry.js:6:52652 _throw@http://localhost:5601/35949/bundles/core/core.entry.js:6:53084 What would be the best approach to getting this fixed? Trying to bundle node-12 again (seems to be EOL though)? Trying to port over the Amazon opensource flavor that forked from 7.10? What do you think? Thank you, JV
Re: coturn: specify pidfile and create directory in rc_pre
On 2022/08/05 18:28, Omar Polo wrote:
> Andre Stoebe wrote:
> > Hello,
> >
> > turnserver tries to create a pidfile at /var/run/turnserver.pid, but
> > this fails due to permissions. It falls back to /var/tmp/turnserver.pid,
> > so this ends up in /tmp.
>
> which version? are you using some custom flags in /etc/rc.conf.local?
> By any chance, did you enabled(/uncommented) the `pidfile' directive
> in /etc/turnserver.conf?
>
> I'm running 4.5.2p2 on OpenBSD 7.1-STABLE with a minimal config and
> don't see it:
>
> antartica# find / -iname turnserver.pid
> antartica# rcctl check turnserver
> turnserver(ok)
> antartica# pkg_info | grep ^turnserver
> turnserver-4.5.2p2 coturn STUN/TURN server
> antartica# grep pidfile /etc/turnserver.conf
> #pidfile="/var/run/turnserver.pid"
>
also,
-daemon="${TRUEPREFIX}/bin/turnserver --daemon"
+daemon="${TRUEPREFIX}/bin/turnserver --daemon
--pidfile=/var/run/turnserver/turnserver.pid"
the "daemon" variable should only be what's _required_ to run it,
something like --pidfile (if it is indeed required) should be in daemon_flags
so it can be overridden
Re: coturn: specify pidfile and create directory in rc_pre
Andre Stoebe wrote: > Hello, > > turnserver tries to create a pidfile at /var/run/turnserver.pid, but > this fails due to permissions. It falls back to /var/tmp/turnserver.pid, > so this ends up in /tmp. which version? are you using some custom flags in /etc/rc.conf.local? By any chance, did you enabled(/uncommented) the `pidfile' directive in /etc/turnserver.conf? I'm running 4.5.2p2 on OpenBSD 7.1-STABLE with a minimal config and don't see it: antartica# find / -iname turnserver.pid antartica# rcctl check turnserver turnserver(ok) antartica# pkg_info | grep ^turnserver turnserver-4.5.2p2 coturn STUN/TURN server antartica# grep pidfile /etc/turnserver.conf #pidfile="/var/run/turnserver.pid"
Re: [tmuxinator] Failed to parse config
On 2022/08/05 15:50, ten wrote: > Hello > > updated tmuxinator to 1.1.3p3 and it stopped wotking. > > Even with creating new project and starting it it throws an error: "Failed > to parse config file: wrong number of arguments (given 4, expected 1)" > > Looks like this is an old error: > > https://github.com/tmuxinator/tmuxinator/issues/819 > This port was quite out of date. I've committed updates to tmuxinator and ruby-thor (a newer version of which is needed for newer tmuxinator). Only lightly tested but seems OK.
Re: arm-trusted-firmware: update to 2.7.0
On Thu, Aug 04, 2022 at 02:59:32PM +, Klemens Nanni wrote: > > I gave this a try on the Pinebook Pro to see if any of the issues I have > got fixed/improved, but it still remains nothing but a toy device. > > Besides existing flaws, I have not noticed any regression. > > I bumped and rebuilt u-boot's aarc64 FLAVOR and dd'ed the files as > documented in INSTALL.aarc64 onto eMMC. > > Does anyone else want to test this on their devices? > Feedback? OK? Working here with: PINE H64 ver B (Allwinner H6): http://ix.io/46Io ROCKPro64 (RK3399): http://ix.io/46Jv ok kevlo@
[NEW] math/datamash
$ pkg_info datamash Information for inst:datamash-1.8p0 Comment: perform basic numeric, textual and statistical operations Description: GNU datamash is a command-line program which performs basic numeric, textual and statistical operations on input textual data files. Maintainer: The OpenBSD ports mailing-list WWW: https://www.gnu.org/software/datamash/ datamash.tar.gz Description: application/tar-gz
[tmuxinator] Failed to parse config
Hello updated tmuxinator to 1.1.3p3 and it stopped wotking. Even with creating new project and starting it it throws an error: "Failed to parse config file: wrong number of arguments (given 4, expected 1)" Looks like this is an old error: https://github.com/tmuxinator/tmuxinator/issues/819
Re: audio/quodlibet & devel/libsoup
Quodlibet uses libsoup via GI. I have had issues with this in the past, I
will see if I can figure something out, but just updating the RUN_DEPENDS
isn't the answer
--
Sent from a phone, apologies for poor formatting.
On 5 August 2022 12:15:16 Antoine Jacoutot wrote:
On Fri, Aug 05, 2022 at 11:17:19AM +0100, Laurence Tratt wrote:
I updated my amd64 snapshot & packages this morning and quodlibet now
refuses to load:
$ quodlibet
(io.github.quodlibet.QuodLibet:63315): libsoup-ERROR **: 11:07:18.501:
libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process
is not supported.
zsh: trace trap (core dumped) quodlibet
Which looks a bit odd as only devel/libsoup is listed as a direct dependency
in the Makefile and `pkg_info -S` doesn't list it either:
$ pkg_info -S quodlibet
Information for inst:quodlibet-4.4.0p0
Signature:
quodlibet-4.4.0p0,8,@desktop-file-utils-0.26,@gstreamer1-plugins-good-1.20.3,@gstreamer1-plugins-libav-1.20.3,@gtk-update-icon-cache-3.24.34,@libsoup-2.74.2,@py3-cairo-1.21.0,@py3-dbus-1.2.18p0,@py3-feedparser-6.0.10,@py3-gobject3-3.42.2,@py3-musicbrainzngs-0.7.1p2,@py3-mutagen-1.45.1p0,@python-3.9.13p1,@xine-lib-1.2.12p2
If I try deleting libsoup2 I end up with quodlibet as a dependency:
$ doas pkg_delete libsoup-2.74.2
can't delete libsoup-2.74.2 without deleting darktable-3.6.1
geoclue2-2.6.0p2 inkscape-1.2.1 osm-gps-map-1.1.0p3 quodlibet-4.4.0p0
webkitgtk4-2.36.5 yelp-42.1
And if I try deleting libsoup3:
$ doas pkg_delete libsoup3-3.0.7
can't delete libsoup3-3.0.7 without deleting gstreamer1-plugins-good-1.20.3
gvfs-1.50.2
Delete them as well ? [y/N/a] y
can't delete gvfs-1.50.2 without deleting gstreamer1-plugins-base-1.20.3
thunar-4.16.11p0
Delete them as well ? [y/N/a] y
can't delete gstreamer1-plugins-base-1.20.3 without deleting
gstreamer1-plugins-bad-1.20.3 gstreamer1-plugins-libav-1.20.3
gstreamer1mm-1.10.0p7 libreoffice-7.3.5.2v0 opencv-4.6.0
phonon-backend-gstreamer-4.10.0p1 pulseaudio-16.1 qtmultimedia-5.15.5
webkitgtk4-2.36.5 yelp-42.1
Fortunately it seems that simply updating RUN_DEPENDS from libsoup to
libsoup3 solves the problem and I end up with a quodlibet that runs
(although I'm slightly unsure *why* this solves things, as I don't know
where quodlibet would pick up the impact of RUN_DEPENDS, but that's probably
my ignorance). If someone who understands this could check whether this
change is sensible or not, I'd be grateful! Patch at the end of this email.
I think having an RDEP on libsoup or libsoup3 is just wrong.
What's the rational for this?
Laurie
Index: Makefile
===
RCS file: /cvs/ports/audio/quodlibet/Makefile,v
retrieving revision 1.39
diff -u -p -u -r1.39 Makefile
--- Makefile 11 Mar 2022 18:20:29 - 1.39
+++ Makefile 5 Aug 2022 10:14:56 -
@@ -3,7 +3,7 @@ COMMENT= audio player and tagger for GTK
MODPY_EGG_VERSION= 4.4.0
DISTNAME= quodlibet-${MODPY_EGG_VERSION}
PORTROACH= skipv:release-${MODPY_EGG_VERSION}
-REVISION= 0
+REVISION= 1
CATEGORIES= audio
@@ -25,7 +25,7 @@ RUN_DEPENDS= audio/py-musicbrainzngs${MO
# others
RUN_DEPENDS+= devel/desktop-file-utils \
- devel/libsoup \
+ devel/libsoup3 \
multimedia/gstreamer1/plugins-good \
multimedia/gstreamer1/plugins-libav \
multimedia/xine-lib \
--
Antoine
Re: audio/quodlibet & devel/libsoup
On Fri, Aug 05, 2022 at 11:17:19AM +0100, Laurence Tratt wrote:
> I updated my amd64 snapshot & packages this morning and quodlibet now
> refuses to load:
>
> $ quodlibet
> (io.github.quodlibet.QuodLibet:63315): libsoup-ERROR **: 11:07:18.501:
> libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is
> not supported.
> zsh: trace trap (core dumped) quodlibet
>
> Which looks a bit odd as only devel/libsoup is listed as a direct dependency
> in the Makefile and `pkg_info -S` doesn't list it either:
>
> $ pkg_info -S quodlibet
> Information for inst:quodlibet-4.4.0p0
>
> Signature:
> quodlibet-4.4.0p0,8,@desktop-file-utils-0.26,@gstreamer1-plugins-good-1.20.3,@gstreamer1-plugins-libav-1.20.3,@gtk-update-icon-cache-3.24.34,@libsoup-2.74.2,@py3-cairo-1.21.0,@py3-dbus-1.2.18p0,@py3-feedparser-6.0.10,@py3-gobject3-3.42.2,@py3-musicbrainzngs-0.7.1p2,@py3-mutagen-1.45.1p0,@python-3.9.13p1,@xine-lib-1.2.12p2
>
> If I try deleting libsoup2 I end up with quodlibet as a dependency:
>
> $ doas pkg_delete libsoup-2.74.2
> can't delete libsoup-2.74.2 without deleting darktable-3.6.1
> geoclue2-2.6.0p2 inkscape-1.2.1 osm-gps-map-1.1.0p3 quodlibet-4.4.0p0
> webkitgtk4-2.36.5 yelp-42.1
>
> And if I try deleting libsoup3:
>
> $ doas pkg_delete libsoup3-3.0.7
> can't delete libsoup3-3.0.7 without deleting gstreamer1-plugins-good-1.20.3
> gvfs-1.50.2
> Delete them as well ? [y/N/a] y
> can't delete gvfs-1.50.2 without deleting gstreamer1-plugins-base-1.20.3
> thunar-4.16.11p0
> Delete them as well ? [y/N/a] y
> can't delete gstreamer1-plugins-base-1.20.3 without deleting
> gstreamer1-plugins-bad-1.20.3 gstreamer1-plugins-libav-1.20.3
> gstreamer1mm-1.10.0p7 libreoffice-7.3.5.2v0 opencv-4.6.0
> phonon-backend-gstreamer-4.10.0p1 pulseaudio-16.1 qtmultimedia-5.15.5
> webkitgtk4-2.36.5 yelp-42.1
>
> Fortunately it seems that simply updating RUN_DEPENDS from libsoup to
> libsoup3 solves the problem and I end up with a quodlibet that runs
> (although I'm slightly unsure *why* this solves things, as I don't know
> where quodlibet would pick up the impact of RUN_DEPENDS, but that's probably
> my ignorance). If someone who understands this could check whether this
> change is sensible or not, I'd be grateful! Patch at the end of this email.
I think having an RDEP on libsoup or libsoup3 is just wrong.
What's the rational for this?
> Laurie
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/audio/quodlibet/Makefile,v
> retrieving revision 1.39
> diff -u -p -u -r1.39 Makefile
> --- Makefile 11 Mar 2022 18:20:29 - 1.39
> +++ Makefile 5 Aug 2022 10:14:56 -
> @@ -3,7 +3,7 @@ COMMENT= audio player and tagger for GTK
> MODPY_EGG_VERSION= 4.4.0
> DISTNAME=quodlibet-${MODPY_EGG_VERSION}
> PORTROACH= skipv:release-${MODPY_EGG_VERSION}
> -REVISION=0
> +REVISION=1
>
> CATEGORIES= audio
>
> @@ -25,7 +25,7 @@ RUN_DEPENDS=audio/py-musicbrainzngs${MO
>
> # others
> RUN_DEPENDS+=devel/desktop-file-utils \
> - devel/libsoup \
> + devel/libsoup3 \
> multimedia/gstreamer1/plugins-good \
> multimedia/gstreamer1/plugins-libav \
> multimedia/xine-lib \
>
--
Antoine
audio/quodlibet & devel/libsoup
I updated my amd64 snapshot & packages this morning and quodlibet now
refuses to load:
$ quodlibet
(io.github.quodlibet.QuodLibet:63315): libsoup-ERROR **: 11:07:18.501:
libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is
not supported.
zsh: trace trap (core dumped) quodlibet
Which looks a bit odd as only devel/libsoup is listed as a direct dependency
in the Makefile and `pkg_info -S` doesn't list it either:
$ pkg_info -S quodlibet
Information for inst:quodlibet-4.4.0p0
Signature:
quodlibet-4.4.0p0,8,@desktop-file-utils-0.26,@gstreamer1-plugins-good-1.20.3,@gstreamer1-plugins-libav-1.20.3,@gtk-update-icon-cache-3.24.34,@libsoup-2.74.2,@py3-cairo-1.21.0,@py3-dbus-1.2.18p0,@py3-feedparser-6.0.10,@py3-gobject3-3.42.2,@py3-musicbrainzngs-0.7.1p2,@py3-mutagen-1.45.1p0,@python-3.9.13p1,@xine-lib-1.2.12p2
If I try deleting libsoup2 I end up with quodlibet as a dependency:
$ doas pkg_delete libsoup-2.74.2
can't delete libsoup-2.74.2 without deleting darktable-3.6.1 geoclue2-2.6.0p2
inkscape-1.2.1 osm-gps-map-1.1.0p3 quodlibet-4.4.0p0 webkitgtk4-2.36.5 yelp-42.1
And if I try deleting libsoup3:
$ doas pkg_delete libsoup3-3.0.7
can't delete libsoup3-3.0.7 without deleting gstreamer1-plugins-good-1.20.3
gvfs-1.50.2
Delete them as well ? [y/N/a] y
can't delete gvfs-1.50.2 without deleting gstreamer1-plugins-base-1.20.3
thunar-4.16.11p0
Delete them as well ? [y/N/a] y
can't delete gstreamer1-plugins-base-1.20.3 without deleting
gstreamer1-plugins-bad-1.20.3 gstreamer1-plugins-libav-1.20.3
gstreamer1mm-1.10.0p7 libreoffice-7.3.5.2v0 opencv-4.6.0
phonon-backend-gstreamer-4.10.0p1 pulseaudio-16.1 qtmultimedia-5.15.5
webkitgtk4-2.36.5 yelp-42.1
Fortunately it seems that simply updating RUN_DEPENDS from libsoup to
libsoup3 solves the problem and I end up with a quodlibet that runs
(although I'm slightly unsure *why* this solves things, as I don't know
where quodlibet would pick up the impact of RUN_DEPENDS, but that's probably
my ignorance). If someone who understands this could check whether this
change is sensible or not, I'd be grateful! Patch at the end of this email.
Laurie
Index: Makefile
===
RCS file: /cvs/ports/audio/quodlibet/Makefile,v
retrieving revision 1.39
diff -u -p -u -r1.39 Makefile
--- Makefile11 Mar 2022 18:20:29 - 1.39
+++ Makefile5 Aug 2022 10:14:56 -
@@ -3,7 +3,7 @@ COMMENT=audio player and tagger for GTK
MODPY_EGG_VERSION= 4.4.0
DISTNAME= quodlibet-${MODPY_EGG_VERSION}
PORTROACH= skipv:release-${MODPY_EGG_VERSION}
-REVISION= 0
+REVISION= 1
CATEGORIES=audio
@@ -25,7 +25,7 @@ RUN_DEPENDS= audio/py-musicbrainzngs${MO
# others
RUN_DEPENDS+= devel/desktop-file-utils \
- devel/libsoup \
+ devel/libsoup3 \
multimedia/gstreamer1/plugins-good \
multimedia/gstreamer1/plugins-libav \
multimedia/xine-lib \
