Librewolf Port
Hello OpenBSD community, I was a user of librewolf on linux. But two days ago I switched to openbsd as my daily driver there is no librewolf on official package list. So I decided to port it. I want to know if anyone is working on librewolf, please inform me. If not then I will be working on porting it. I doesn't have any experience with patches of compiling a software. I have just a little bit of info about Makefile. I intend to follow port faq. Any help will be appreciated. Thanks Hari
Re: python3 module location (py3-junos-eznc broken)
> On Jan 21, 2024, at 10:14 PM, Chris Cappuccio wrote: > > With python 3.10, py3-junos-eznc is broken: Thanks for the report. > >class _FactCache(collections.MutableMapping): > AttributeError: module 'collections' has no attribute 'MutableMapping' > > I suspect the module may require python3.9 or earlier? Release 2.7.0 claims support for python 3.10 so I suggest updating the port to the latest release.
python3 module location (py3-junos-eznc broken)
With python 3.10, py3-junos-eznc is broken: class _FactCache(collections.MutableMapping): AttributeError: module 'collections' has no attribute 'MutableMapping' I suspect the module may require python3.9 or earlier? How the heck do you make a port python3 module install for 3.9 instead of 3.10?
Re: audio/shairport-sync: save config permissions, clearer sndio(7) instructions
On Fri, Jan 19, 2024 at 01:08:37AM +, Klemens Nanni wrote:
> Config may contain passwords, but is world-readable.
> I'd say /etc/ files are usually root-owned as well:
>
> -rw-r--r-- 1 _shairport _shairport 23340 Jan 19 01:24
> /etc/shairport-sync.conf
>
> Fix it in PLIST; daemon user's home ownership/permissions stay the same:
>
> -rw-r- 1 root_shairport 23340 Jan 19 01:53
> /etc/shairport-sync.conf
> drwxr-xr-x 3 _shairport _shairport512 Jan 19 01:56
> /var/spool/shairport-sync/
>
>
> Paul mentioned shairpoint-sync's instructions as reply to spotifyd,
> where I went with less repitition and more precise instructions.
>
> I suggest syncing with that so copy/paste after install just works.
> Playback on amd64 from an iPhone works for me without further config.
>
> (Pausing on the remote device crashes the daemon, but that's not news
> and we're due updating our port, anyways.)
>
> Feedback? OK?
Rebased after the pause crash fix went in.
Index: Makefile
===
RCS file: /cvs/ports/audio/shairport-sync/Makefile,v
diff -u -p -r1.4 Makefile
--- Makefile22 Jan 2024 01:40:28 - 1.4
+++ Makefile22 Jan 2024 01:41:44 -
@@ -3,7 +3,7 @@ COMMENT = AirPlay audio player
GH_ACCOUNT = mikebrady
GH_PROJECT = shairport-sync
GH_TAGNAME = 3.3.9
-REVISION = 2
+REVISION = 3
SITES.fix =https://github.com/mikebrady/shairport-sync/commit/
# "avoid recursive mutex acquisition in sndio backend" to fix crash on pause
@@ -35,6 +35,9 @@ CONFIGURE_ARGS += --with-ssl=openssl \
--with-sndio \
--with-os=openbsd
FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/shairport-sync
+
+HOME_DIR = ${LOCALSTATEDIR}/spool/${PKGSTEM}
+SUBST_VARS = HOME_DIR
post-install:
mv ${PREFIX}/man/man7/shairport-sync.7 \
Index: pkg/PLIST
===
RCS file: /cvs/ports/audio/shairport-sync/pkg/PLIST,v
diff -u -p -r1.2 PLIST
--- pkg/PLIST 1 May 2022 14:00:13 - 1.2
+++ pkg/PLIST 22 Jan 2024 01:41:44 -
@@ -1,12 +1,17 @@
@newgroup _shairport:876
-@newuser _shairport:876:876::Shairport-sync
Account:/var/spool/shairport-sync:/sbin/nologin
+@newuser _shairport:876:876::Shairport-sync Account:${HOME_DIR}:/sbin/nologin
@rcscript ${RCDIR}/shairport_sync
+@owner _shairport
+@group _shairport
+@sample ${HOME_DIR}/
+@extraunexec rm -rf ${HOME_DIR}
+@owner
+@group
@bin bin/shairport-sync
@man man/man1/shairport-sync.1
share/doc/pkg-readmes/${PKGSTEM}
share/examples/shairport-sync/
share/examples/shairport-sync/shairport-sync.conf
-@owner _shairport
+@mode 0640
@group _shairport
@sample ${SYSCONFDIR}/shairport-sync.conf
-@sample /var/spool/shairport-sync/
Index: pkg/README
===
RCS file: /cvs/ports/audio/shairport-sync/pkg/README,v
diff -u -p -r1.2 README
--- pkg/README 1 May 2022 14:00:13 - 1.2
+++ pkg/README 22 Jan 2024 01:41:44 -
@@ -8,16 +8,7 @@ boot time, the rc.conf.local(8) pkg_scri
rcctl enable messagebus avahi_daemon shairport_sync
rcctl order messagebus avahi_daemon shairport_sync
-sndiod(8) concurrent access by shairport-sync(1) and other users
-
+Follow sndio(7) Authentication if both dedicated and your own user shall be
+able to play audio at the same time, e.g. on a desktop system:
-sndiod(8) normally only allows access to audio by a single system user
-at a time. This is done by generating a random authentication token and
-storing it in $HOME/.sndio/cookie when a user first accesses audio,
-providing a limited capability to share with other users by copying
-the token to their home directory. See AUTHENTICATION in sndio(7) for
-more details.
-
-If you want to share sndiod(8) access with shairport-sync(1) running as
-the default _shairport user, you may copy .sndio/cookie from your user's
-home directory to /var/spool/shairport/.sndio/cookie.
+install -D -p -o _shairport -m 0600 ~/.sndio/cookie
${HOME_DIR}/.sndio/cookie
Index: pkg/shairport_sync.rc
===
RCS file: /cvs/ports/audio/shairport-sync/pkg/shairport_sync.rc,v
diff -u -p -r1.1.1.1 shairport_sync.rc
--- pkg/shairport_sync.rc 27 Apr 2022 02:19:25 - 1.1.1.1
+++ pkg/shairport_sync.rc 22 Jan 2024 01:41:44 -
@@ -6,4 +6,5 @@ daemon_user="_shairport"
. /etc/rc.d/rc.subr
rc_bg=YES
+
rc_cmd $1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/01/21 18:51:25 Modified files: games/cataclysm-dda: Makefile Log message: BDEP on abseil to fix sporadic build failure; OK kirby rsadowski Found by naddy, cataclysm-dda bundles flatbuffers which uses abseil-cpp. Neither checked during configure nor linked to; devel/flatbuffers does not pull in devel/abseil-cpp, but cataclysm-dda does not support using the system library, so satisfy the dependency to avoid dpb(1) junking it.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/01/21 18:40:28 Modified files: audio/shairport-sync: Makefile distinfo Log message: pull upstream fix for crash on pause; OK anton
Re: [NEW] misc/remindcal v0.1.0
Russ Sharek wrote (2024-01-21 20:18 CET):
> On January 10, 2024 12:16:50 AM EST, Russ Sharek wrote:
> >Hello!
> >
> >I found a cool little TUI front-end for the misc/remind calendar tool,
> >and have put together a port.
> >
> >homepage: https://github.com/realsirjoe/remindcal
> >
> >I've tested this on amd64.
> >
> >Notes? OK?
>
> Haven't heard anything regarding this port.
>
> Can someone please have a look?
>
Hi,
I can give some feedback.
I don't mind the README, but it should be correct. remincal has a
fallback to "vim". So when vim is installed, EDITOR is not required
to be set.
See: remind.go:160 if editor == "" { editor = "vim" }
$ cat distinfo
SHA256 (v0.1.0.tar.gz) = /81STC/8eMW46gcHCF1/3UQJYrHL9EagggXr0daVkiI=
SIZE (v0.1.0.tar.gz) = 66383
This is no good and can clash in DISTDIR. The distfile name can be
altered by using the construct fixed-filename{download-filename}.tgz.
Like so:
DISTFILES = remindcal-${V}{v${V}}${EXTRACT_SUFX}
You don't need to define EXTRACT_SUFX. It's ".tar.gz" by default.
There's a better way to do this port. Your approach would be good if
the author would have uploaded proper release tarballs. But as we're
grabbing a tagged version, we can use the DIST_TUPLE mechanism, which
also sets HOMEPAGE and DISTFILES correctly.
My proposal for the Makefile:
---
COMMENT = terminal frontend for remind
DIST_TUPLE =github realsirjoe remindcal v0.1.0 .
CATEGORIES =misc
MAINTAINER =Russ Sharek
# UNLICENSE: https://unlicense.org
PERMIT_PACKAGE =Yes
WANTLIB += c curses pthread
MODULES = lang/go
RUN_DEPENDS = misc/remind
ALL_TARGET =github.com/realsirjoe/remindcal
.include
---
Best Regards,
Stefan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2024/01/21 12:21:44 Modified files: www/links+ : Makefile Log message: Add missing LIB_DEPENDS on graphics/libavif. Pointed out by sthen@, thanks! Maintainer Tim Meunier is fine with the change.
Re: [NEW] misc/remindcal v0.1.0
On January 10, 2024 12:16:50 AM EST, Russ Sharek wrote: >Hello! > >I found a cool little TUI front-end for the misc/remind calendar tool, >and have put together a port. > >homepage: https://github.com/realsirjoe/remindcal > >I've tested this on amd64. > >Notes? OK? Haven't heard anything regarding this port. Can someone please have a look?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2024/01/21 12:18:26 Modified files: audio/amused : Makefile distinfo Log message: update audio/amused to 0.14 - added libao and oboe (android) audio backends - honour $TMPDIR if set - switched to new imsg APIs
Re: NEW: games/Bugdom2
On Sun, Jan 21, 2024 at 05:26:27PM +0100, Omar Polo wrote: > On 2024/01/19 13:06:36 -0600, izder456 wrote: > > Hey again, > > > > like my games/bugdom port, I Fixed up and patched to mirror > > games/nanosaur2 from omar. > > > > it was a simple enough patch. > > > > Attached is the port. > > > > Comments or O.K. to merge? > > Needs the same adjustments that thfr did on games/bugdom, i.e. > > - libsamplerate is not used at all >by the way, adding a library as both RUN_DEPENDS and BUILD_DEPENDS >smells of something wrong. > > - remove the last two paragraphs of trademarks from DESCR > > plus the makefile needs to be "tabified" :-) > > Attaching an updated tarball that's ok op@ to import. Thanks for > porting these games :-) > I imported this one, too. Thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/01/21 11:42:36 Modified files: games : Makefile Log message: +bugdom2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/01/21 11:41:55 Log message: import games/bugdom2 from izzy Meyer ( izder456 () disroot ! org ) tweaks and ok op@ DESCR: Three years after Rollie McFly's victory over King Thorax, the Bugdom remains a dangerous place. Skip, our new hero, has had his knapsack stolen by a Bully Bee. Your mission as Skip is to track down the Bully Bee and retrieve your knapsack in the chase that takes place around a house. Along the way, you'll receive assistance from new Bugdom friends like Sam the Snail and Sally the Chipmunk. Sam may require you to prove yourself before offering help, while Sally is preoccupied with collecting acorns. Make sure to have plenty of acorns to give to Sally. Additionally, the same Buddy Bugs that aided Rollie McFly will assist you in defeating hostile bugs you come across. Status: Vendor Tag: thfr Release Tags: thfr_20240121 N ports/games/bugdom2/Makefile N ports/games/bugdom2/distinfo N ports/games/bugdom2/pkg/DESCR N ports/games/bugdom2/pkg/PLIST N ports/games/bugdom2/patches/patch-Source_Boot_cpp No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/01/21 11:22:50 Modified files: security/rust-openssl-tests: Makefile crates.inc distinfo Log message: Update to rust-openssl-tests 20240121
Update from maintainer: devel/objfw 1.0.8
Patch attached. Please also import to 7.4, as this contains quite the list of bugfixes compared to the previous 1.0.3. -- JonathanIndex: Makefile === RCS file: /cvs/ports/devel/objfw/Makefile,v retrieving revision 1.5 diff -u -p -r1.5 Makefile --- Makefile 21 Sep 2023 09:50:01 - 1.5 +++ Makefile 21 Jan 2024 15:17:58 - @@ -1,6 +1,6 @@ COMMENT = portable, lightweight framework for the Objective-C language -DISTNAME = objfw-1.0.3 +DISTNAME = objfw-1.0.8 SHARED_LIBS += objfw 0.0 SHARED_LIBS += objfwrt 0.0 Index: distinfo === RCS file: /cvs/ports/devel/objfw/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo 19 Sep 2023 11:55:03 - 1.3 +++ distinfo 21 Jan 2024 15:17:58 - @@ -1,2 +1,2 @@ -SHA256 (objfw-1.0.3.tar.gz) = HIHX0DV4stkIT8XYci1OqkvcLz8JzkEjHnzquCEvrhc= -SIZE (objfw-1.0.3.tar.gz) = 787055 +SHA256 (objfw-1.0.8.tar.gz) = k14I4pbW5Anp99lyoEz96CyWBk0XV282znONBNtXHFY= +SIZE (objfw-1.0.8.tar.gz) = 799217
Re: FVWM3 as of a recent current no longer lets mouse scroll across to new windows
Re: FVWM3 as of a recent current no longer lets mouse scroll across :58:39PM +0100, Omar Polo wrote: > On 2024/01/21 18:51:15 +0100, Omar Polo wrote: > > On 2024/01/21 09:37:46 -0800, Chris Bennett > > wrote: > > > As of 1.0.9, I can't get mouse to cross windows, but I can move window > > > items with the mouse. > > > Someone in the forum said that the version after 1.0.9 has the fix for > > > this I saw in github. > > > > fvwm3 was updated to 1.0.9 on 2023/12/03, so I guess you're using > > -STABLE and not -CURRENT. > > Completely misunderstood your mail, apologize. > > the latest version published upstream seems 1.0.9, and in the 15 commits > done after the release I don't see bugfixes related to this. It's possible that I have a problem in my configuration. I can't use any browser other than Firefox because of the drm issues and I absolutely needed a working browser until just now. I just started making configuration changes now (but after noticing the problem, not before). -- Regards, Chris Bennett "Who controls the past controls the future. Who controls the present controls the past." George Orwell - 1984
Re: FVWM3 as of a recent current no longer lets mouse scroll across to new windows
On 2024/01/21 18:51:15 +0100, Omar Polo wrote: > On 2024/01/21 09:37:46 -0800, Chris Bennett > wrote: > > As of 1.0.9, I can't get mouse to cross windows, but I can move window > > items with the mouse. > > Someone in the forum said that the version after 1.0.9 has the fix for > > this I saw in github. > > fvwm3 was updated to 1.0.9 on 2023/12/03, so I guess you're using > -STABLE and not -CURRENT. Completely misunderstood your mail, apologize. the latest version published upstream seems 1.0.9, and in the 15 commits done after the release I don't see bugfixes related to this.
Re: FVWM3 as of a recent current no longer lets mouse scroll across to new windows
On 2024/01/21 09:37:46 -0800, Chris Bennett
wrote:
> As of 1.0.9, I can't get mouse to cross windows, but I can move window
> items with the mouse.
> Someone in the forum said that the version after 1.0.9 has the fix for
> this I saw in github.
fvwm3 was updated to 1.0.9 on 2023/12/03, so I guess you're using
-STABLE and not -CURRENT.
This diff should apply to the -STABLE port tree and build. There have
been several bugfixes between 1.0.6a (in -stable versions) and the
current 1.0.9 that it may be worthwile to backport.
However, I can't test it in -stable.
Index: Makefile
===
RCS file: /home/cvs/ports/x11/fvwm3/Makefile,v
diff -u -p -r1.8 Makefile
--- Makefile24 Jan 2023 18:05:35 - 1.8
+++ Makefile21 Jan 2024 17:49:32 -
@@ -1,6 +1,6 @@
COMMENT= multiple virtual desktop window manager
-VERSION= 1.0.6a
+VERSION= 1.0.9
DISTNAME= fvwm3-${VERSION}
CATEGORIES= x11
@@ -20,13 +20,14 @@ WANTLIB += readline rsvg-2 event_core ev
MASTER_SITES= https://github.com/fvwmorg/fvwm3/releases/download/${VERSION}/
+BUILD_DEPENDS+=textproc/asciidoctor
+
LIB_DEPENDS+= graphics/png \
x11/gnome/librsvg \
devel/libevent2
SUBST_VARS=VERSION
-SEPARATE_BUILD=Yes
CONFIGURE_STYLE= gnu
CONFIGURE_ARGS+= --enable-mandoc \
@@ -39,7 +40,14 @@ CONFIGURE_ENV+= CPPFLAGS="${CPPFLAGS} -
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+USE_GMAKE =yes
+
post-install:
+ cd ${WRKINST}/${TRUEPREFIX}/man/man1 && for m in Fvwm*.1; \
+ do mv {,fvwm3-}$$m; done
+ cd ${WRKINST}/${TRUEPREFIX}/man/man1/ && \
+ mv fvwm3-FvwmCommand{,3}.1 && \
+ ln -s fvwm3-FvwmCommand3.1 FvwmCommand3.1
mv ${WRKINST}/${TRUEPREFIX}/bin/FvwmCommand{,3}
mv ${WRKINST}/${TRUEPREFIX}/share/FvwmScript-* \
${WRKINST}/${TRUEPREFIX}/share/fvwm3/
Index: distinfo
===
RCS file: /home/cvs/ports/x11/fvwm3/distinfo,v
diff -u -p -r1.3 distinfo
--- distinfo22 Jan 2023 12:11:26 - 1.3
+++ distinfo21 Jan 2024 17:47:34 -
@@ -1,2 +1,2 @@
-SHA256 (fvwm3-1.0.6a.tar.gz) = RmWmYTPgcLeRkXsHlMxt9rdUZ56+kTBxhCfbZHm7W2g=
-SIZE (fvwm3-1.0.6a.tar.gz) = 4538100
+SHA256 (fvwm3-1.0.9.tar.gz) = xtBBGpe2IdjA7tNbxBZ4BBUUgOhH9kaUrcqOVd0ZBkg=
+SIZE (fvwm3-1.0.9.tar.gz) = 4525552
Index: patches/patch-configure
===
RCS file: /home/cvs/ports/x11/fvwm3/patches/patch-configure,v
diff -u -p -r1.3 patch-configure
--- patches/patch-configure 13 Oct 2022 16:00:45 - 1.3
+++ patches/patch-configure 21 Jan 2024 17:47:20 -
@@ -1,7 +1,7 @@
Index: configure
--- configure.orig
+++ configure
-@@ -11779,7 +11779,7 @@ then :
+@@ -11784,7 +11784,7 @@ then :
else $as_nop
with_intl=maybe
Index: patches/patch-default-config_Makefile_in
===
RCS file: /home/cvs/ports/x11/fvwm3/patches/patch-default-config_Makefile_in,v
diff -u -p -r1.3 patch-default-config_Makefile_in
--- patches/patch-default-config_Makefile_in13 Oct 2022 16:00:45 -
1.3
+++ patches/patch-default-config_Makefile_in21 Jan 2024 17:47:20 -
@@ -1,7 +1,7 @@
Index: default-config/Makefile.in
--- default-config/Makefile.in.orig
+++ default-config/Makefile.in
-@@ -593,9 +593,10 @@ uninstall-am: uninstall-configDATA
+@@ -575,9 +575,10 @@ uninstall-am: uninstall-configDATA
install-data-hook:
cp -r $(srcdir)/images $(inst_location)/default-config
FVWM3 as of a recent current no longer lets mouse scroll across to new windows
As of 1.0.9, I can't get mouse to cross windows, but I can move window items with the mouse. Someone in the forum said that the version after 1.0.9 has the fix for this I saw in github. I wanted to ask if you are working on an update right now? Is it possible to work on an update with the pinsyscall stuff happening until it settles down? In any case, thank you for bringing in FVWM3 and updating FVWM2. This mouse problem is only a very minor thing and not a show stopper at all. I have a key binding that does it anyway. -- Regards, Chris Bennett "Who controls the past controls the future. Who controls the present controls the past." George Orwell - 1984
Re: NEW: x11/emwm
On 2024/01/19 13:03:40 -0600, izder456 wrote: > On Thu, 18 Jan 2024 16:44:36 + > Stuart Henderson wrote: > > > On 2024/01/18 10:02, izder456 wrote: > > > Here is one with spaces favored, > > > > please don't, pretty much all the rest of the ports tree lines things > > up to some extent. when people do bulk work across the ports tree > > touching large numbers of ports it's helpful to have a bit of > > consistency, and it's easier to visually scan the Makefile that way. > > > > Okay, thanks for the feedback. > > Attached is a cleaned up version. > > I have done some mild testing locally, things seem to be in order and > functional. > > Comments or OK to merge? Here's an updated tarball with a few more tweaks on top: - use DIST_TUPLE instead of GH_* (takes less lines :-) - don't need to patch the makefile; just override the variables using MAKE_FLAGS and FAKE_FLAGS - use tabs for indenting the values I've tested it quickly with Xephyr and seems to work. it is ok op@ to import. Thanks, Omar Polo emwm.tar.gz Description: GNU Zip compressed data
Re: NEW: games/Bugdom
On Sun, Jan 21, 2024 at 05:10:20PM +0100, Omar Polo wrote: > On 2024/01/21 09:43:39 -0500, Thomas Frohwein wrote: > > On Fri, Jan 19, 2024 at 01:11:09PM -0600, izder456 wrote: > > > On Thu, 18 Jan 2024 10:15:14 -0600 > > > izder456 wrote: > > > > > > > On Thu, 18 Jan 2024 09:39:15 -0600 > > > > izder456 wrote: > > > > > > > > > Hey again, > > > > > > > > > > Fixed up and patched to mirror games/nanosaur2 from omar > > > > > > > > > > it was a simple enough patch. > > > > > > > > > > Comments or O.K. to merge? > > > > > > > > > > > > > Hey, sorry, > > > > > > > > Accidentally kept the files subdir, and didn't update the licensing > > > > info > > > > > > > > Attatched is the fix. > > > > > > > > Comments or OK? > > > > > > > > > > Sorry about the duplicate send earlier, my email provider was playing > > > weird with gmail. > > > > > > Attached is the port with more lined up formatting. > > > > > > That was all i had changed, Stuart mentioned that consistency is > > > favored in my x11/emwm port. > > > > > > Comments? > > > > Thanks for the updates to this! I made some small adjustments and > > attached a slightly modified tarball from yours: > > > > - I searched through the code and libsamplerate isn't used at all. > > Looks like upstream needs to update their ReleaseBuilds*.yml files... > > - I find the DESCR a lot more useful now, but went ahead and removed > > the last 2 paragraphs (trademark etc.) which isn't useful in DESCR. > > > > With these small adjustments, this is ok thfr@ for import... > > ok op@ too, thanks! It's imported now, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/01/21 09:33:00 Modified files: games : Makefile Log message: +bugdom
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/01/21 09:31:43 Log message: import games/bugdom by Stu (izder456 () disroot ! org) who also takes MAINTAINER - thanks! with contribution/review by me, op@, gkoehler@ ok op@ DESCR: In the Bugdom, the peaceful rule of the Rollie Pollies and Lady Bugs was recently toppled by the Fire Ants. They have captured all the Lady Bugs, who are now held captive. To bring back peace, Rollie McFly, the sole bug capable of saving the Lady Bugs, must defeat King Thorax, the leader of the Fire Ants. Starting from the Lawn area, Rollie will encounter various challenges, including crossing water, riding bugs, and battling enemy forces. Once King Thorax and the Fire Ants are defeated, Rollie will become the new ruler, restoring peace to the Bugdom. Bugdom was released in 1999 by Pangea Software as a pack-in game on Macs. It is known for being the most advanced game to use QuickDraw 3D. This port aims to provide the best Bugdom experience by adding modern comforts and fixing gameplay bugs, while staying true to the original game's spirit. No modifications to the game's design are included in this project. Status: Vendor Tag: thfr Release Tags: thfr_20240121 N ports/games/bugdom/Makefile N ports/games/bugdom/distinfo N ports/games/bugdom/patches/patch-src_Boot_cpp N ports/games/bugdom/pkg/DESCR N ports/games/bugdom/pkg/PLIST No conflicts created by this import
Re: NEW: games/Bugdom2
On 2024/01/19 13:06:36 -0600, izder456 wrote: > Hey again, > > like my games/bugdom port, I Fixed up and patched to mirror > games/nanosaur2 from omar. > > it was a simple enough patch. > > Attached is the port. > > Comments or O.K. to merge? Needs the same adjustments that thfr did on games/bugdom, i.e. - libsamplerate is not used at all by the way, adding a library as both RUN_DEPENDS and BUILD_DEPENDS smells of something wrong. - remove the last two paragraphs of trademarks from DESCR plus the makefile needs to be "tabified" :-) Attaching an updated tarball that's ok op@ to import. Thanks for porting these games :-) bugdom2.tar.gz Description: GNU Zip compressed data
audio/shairport-sync: fix crash on pause
Cherry-pick the following to fix crashes when pausing playback. This makes the shairport_sync rc.d daemon survive. OK? From 57af5f3c10c54947cf160fe46a580cf40669d412 Mon Sep 17 00:00:00 2001 From: Anton Lindqvist Date: Fri, 3 Dec 2021 20:45:51 +0100 Subject: [PATCH] avoid recursive mutex acquisition in sndio backend Ending a RTSP session while running on OpenBSD using sndio backend causes the following crash: #0 thrkill () #1 0x05208224403e in _libc_abort #2 0x0520821b77be in _rthread_mutex_trylock #3 _rthread_mutex_timedlock #4 0x051e0d54e2c0 in stop () #5 0x051e0d544e85 in player_thread_cleanup_handler #6 0x052082243126 in _libc_pthread_exit #7 0x05209a158700 in sigthr_handler #8 #9 _thread_sys_poll () #10 0x05208223533e in _libc_poll_cancel #11 0x0520df54c9a0 in sio_psleep #12 0x0520df54cc1f in sio_write #13 0x051e0d54e27a in play #14 0x051e0d547fc0 in player_thread_func #15 0x05209a158cc1 in _rthread_start #16 0x05208223565a in __tfork_thread The player thread is blocking inside sio_write() -> poll(2) while the thread is being terminated. The stop routine tied to the same backend is invoked through player_thread_cleanup_handler() which tries to acquire the mutex which it already acquired before invoking sio_write(). Avoiding blocking writes would require switching to async I/O which is quite an undertaking. The fact that there's only one `struct sio_hdl *' instance in the compilation unit sort of implies there can only be one player thread at a time. Therefore fix the crash by only trying to acquire the mutex and continue as usual if it's already acquired. --- audio_sndio.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) Index: Makefile === RCS file: /cvs/ports/audio/shairport-sync/Makefile,v diff -u -p -r1.3 Makefile --- Makefile5 Oct 2022 14:54:23 - 1.3 +++ Makefile21 Jan 2024 16:06:02 - @@ -3,7 +3,12 @@ COMMENT = AirPlay audio player GH_ACCOUNT = mikebrady GH_PROJECT = shairport-sync GH_TAGNAME = 3.3.9 -REVISION = 1 +REVISION = 2 + +SITES.fix =https://github.com/mikebrady/shairport-sync/commit/ +# "avoid recursive mutex acquisition in sndio backend" to fix crash on pause +PATCHFILES.fix = 57af5f3c10c54947cf160fe46a580cf40669d412.patch +PATCH_DIST_STRIP = -p1 CATEGORIES = audio Index: distinfo === RCS file: /cvs/ports/audio/shairport-sync/distinfo,v diff -u -p -r1.1.1.1 distinfo --- distinfo27 Apr 2022 02:19:25 - 1.1.1.1 +++ distinfo21 Jan 2024 16:06:07 - @@ -1,2 +1,4 @@ +SHA256 (57af5f3c10c54947cf160fe46a580cf40669d412.patch) = oXgaUppVX6sT9ZLReDyLZ9pRxB/s43puBLDsvSlmsWQ= SHA256 (shairport-sync-3.3.9.tar.gz) = F5kMsmIFUcqgehw7NxiJ5VgDBx6q2gTpWMNWVHp+F5U= +SIZE (57af5f3c10c54947cf160fe46a580cf40669d412.patch) = 2421 SIZE (shairport-sync-3.3.9.tar.gz) = 426827
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/01/21 09:16:19 Modified files: audio/fluidsynth: Makefile audio/fluidsynth/files: fluid_sndio.c audio/fluidsynth/patches: patch-src_CMakeLists_txt Added files: audio/fluidsynth/patches: patch-FluidSynthConfig_cmake_in patch-cmake_admin_report_cmake patch-src_config_cmake patch-src_drivers_fluid_adriver_c patch-src_drivers_fluid_adriver_h patch-src_drivers_fluid_mdriver_c patch-src_drivers_fluid_mdriver_h Log message: hook up sndio backend again post update, ok sebastia@
Re: NEW: games/Bugdom
On 2024/01/21 09:43:39 -0500, Thomas Frohwein wrote: > On Fri, Jan 19, 2024 at 01:11:09PM -0600, izder456 wrote: > > On Thu, 18 Jan 2024 10:15:14 -0600 > > izder456 wrote: > > > > > On Thu, 18 Jan 2024 09:39:15 -0600 > > > izder456 wrote: > > > > > > > Hey again, > > > > > > > > Fixed up and patched to mirror games/nanosaur2 from omar > > > > > > > > it was a simple enough patch. > > > > > > > > Comments or O.K. to merge? > > > > > > > > > > Hey, sorry, > > > > > > Accidentally kept the files subdir, and didn't update the licensing > > > info > > > > > > Attatched is the fix. > > > > > > Comments or OK? > > > > > > > Sorry about the duplicate send earlier, my email provider was playing > > weird with gmail. > > > > Attached is the port with more lined up formatting. > > > > That was all i had changed, Stuart mentioned that consistency is > > favored in my x11/emwm port. > > > > Comments? > > Thanks for the updates to this! I made some small adjustments and > attached a slightly modified tarball from yours: > > - I searched through the code and libsamplerate isn't used at all. > Looks like upstream needs to update their ReleaseBuilds*.yml files... > - I find the DESCR a lot more useful now, but went ahead and removed > the last 2 paragraphs (trademark etc.) which isn't useful in DESCR. > > With these small adjustments, this is ok thfr@ for import... ok op@ too, thanks!
Re: fluidsynth update 2.3.4
On Sunday, January 21, 2024 14:56 CET, Thomas Frohwein
wrote:
> On Sun, Jan 21, 2024 at 01:13:16PM +0100, Sebastian Reitenbach wrote:
> > Hi,
> >
> > On Sunday, January 21, 2024 00:07 CET, Thomas Frohwein
> > wrote:
> >
> > > Here is a version that restores sndio support again. I'm not sure how
> > > best to test that what audio I'm hearing is from sndio and not sdl2,
> > > but with this, sndio shows up again with fluidsynth -h as audio and
> > > midi driver and a quick test with shockolate and simutrans still gives
> > > me working audio.
> > >
> > > Please test and provide comments! I admit the CFLAGS+=-DSNDIO_SUPPORT
> > > is a hack, but was the quickest way to a solution to the build system
> > > pending a more thorough look where cmake needs to set this.
> >
> > it's not perfect yet, but makes it better. QSynth starts, takes input from
> > my midi controller,
> > but it also produces a humming noise. tested with a qsynth-0.9.12 (based on
> > @rsadowsi's
> > version he sent August last year)
> >
> > regarding CFLAGS, we should merge in some additional patches I sent
> > off-list, I got it
> > to propagate properly.
> >
> > Sebastian
>
> Thanks, new diff with your cmake-related changes that doesn't need the
> CFLAGS+=
> anymore.
with that patch, I can at least run:
fluidsynth -a sndio -m sndio -p midithru/0
/usr/local/share/generaluser-gs/GeneralUser_GS.sf2
and connect the midi controller via midish, and it works.
qsynth is updated, still has some odd troubles (bad humming noise) but at least
I can manually
get fluidsynth to work until I find time to look into qsynth.
OK sebastia@
>
> ok?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/audio/fluidsynth/Makefile,v
> retrieving revision 1.35
> diff -u -p -r1.35 Makefile
> --- Makefile 20 Jan 2024 20:01:56 - 1.35
> +++ Makefile 21 Jan 2024 13:53:23 -
> @@ -3,6 +3,7 @@ COMMENT = SoundFont2 software synthesiz
> GH_ACCOUNT = FluidSynth
> GH_PROJECT = fluidsynth
> GH_TAGNAME = v2.3.4
> +REVISION = 0
>
> SHARED_LIBS += fluidsynth 3.0 # 6.0
>
> Index: files/fluid_sndio.c
> ===
> RCS file: /cvs/ports/audio/fluidsynth/files/fluid_sndio.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 fluid_sndio.c
> --- files/fluid_sndio.c 29 Mar 2013 12:37:43 - 1.4
> +++ files/fluid_sndio.c 21 Jan 2024 13:53:23 -
> @@ -66,8 +66,6 @@ typedef struct {
>fluid_midi_parser_t *parser;
> } fluid_sndio_midi_driver_t;
>
> -int delete_fluid_sndio_audio_driver(fluid_audio_driver_t* p);
> -
> /* local utilities */
> static void* fluid_sndio_audio_run(void* d);
> static void* fluid_sndio_audio_run2(void* d);
> @@ -76,7 +74,7 @@ static void* fluid_sndio_audio_run2(void
> void
> fluid_sndio_audio_driver_settings(fluid_settings_t* settings)
> {
> - fluid_settings_register_str(settings, "audio.sndio.device", "default", 0,
> NULL, NULL);
> + fluid_settings_register_str(settings, "audio.sndio.device", "default", 0);
> }
>
> /*
> @@ -109,7 +107,7 @@ new_fluid_sndio_audio_driver(fluid_setti
>dev->data = NULL;
>dev->cont = 1;
>
> - if (!fluid_settings_getstr(settings, "audio.sndio.device", )) {
> + if (!fluid_settings_getstr_default(settings, "audio.sndio.device",
> )) {
> devname = NULL;
>}
>
> @@ -210,7 +208,7 @@ new_fluid_sndio_audio_driver2(fluid_sett
>dev->data = data;
>dev->cont = 1;
>
> - if (!fluid_settings_getstr(settings, "audio.sndio.device", )) {
> + if (!fluid_settings_getstr_default(settings, "audio.sndio.device",
> )) {
> devname = NULL;
>}
>
> @@ -286,19 +284,19 @@ error_recovery:
> /*
> * delete_fluid_sndio_audio_driver
> */
> -int
> +void
> delete_fluid_sndio_audio_driver(fluid_audio_driver_t* p)
> {
>fluid_sndio_audio_driver_t* dev = (fluid_sndio_audio_driver_t*) p;
>
>if (dev == NULL) {
> -return FLUID_OK;
> +return;
>}
>dev->cont = 0;
>if (dev->thread) {
> if (pthread_join(dev->thread, NULL)) {
>FLUID_LOG(FLUID_ERR, "Failed to join the audio thread");
> - return FLUID_FAILED;
> + return;
> }
>}
>if (dev->hdl) {
> @@ -308,7 +306,7 @@ delete_fluid_sndio_audio_driver(fluid_au
> FLUID_FREE(dev->buffer);
>}
>FLUID_FREE(dev);
> - return FLUID_OK;
> + return;
> }
>
> /*
> @@ -372,17 +370,17 @@ fluid_sndio_audio_run2(void* d)
>
> void fluid_sndio_midi_driver_settings(fluid_settings_t* settings)
> {
> - fluid_settings_register_str(settings, "midi.sndio.device", "default", 0,
> NULL, NULL);
> + fluid_settings_register_str(settings, "midi.sndio.device", "default", 0);
> }
>
> -int
> +void
> delete_fluid_sndio_midi_driver(fluid_midi_driver_t *addr)
> {
>int err;
>fluid_sndio_midi_driver_t *dev = (fluid_sndio_midi_driver_t *)addr;
>
>if (dev
Re: use subdirs to group FNA ports to streamline updates
On 2024/01/21 09:49:20 -0500, Thomas Frohwein wrote: > *ping* > > Re-attaching fna/ tarballed, including the @pkgpath. This is really > just a move of the other ports into games/fna/ subdirs. It would > streamline and simplify future updates significantly... > > ok? The diff between the current ports and the updated/moved ones looks fine to me. I haven't check in details the update itself. The @pkgpath annotations seems correct to me and I don't think more is needed for a move like this. ok op@
Re: sccache lifetime & ports infrastructure ?
On Tue, Dec 26, 2023 at 08:15:55AM +0100, Landry Breuil wrote: > Le Sat, Dec 23, 2023 at 04:09:19PM +0100, Caspar Schutijser a écrit : > > On Sat, Dec 23, 2023 at 09:07:24AM +0100, Landry Breuil wrote: > > > hi, > > > > > > sending to ports@ for more ideas, devel/sccache works pretty great here, > > > but for now its client/server model has some issues. from my > > > understanding, a server is spawned at the first invocation of sccache, > > > and it runs forever > > > > The running forever should only happen if SCCACHE_IDLE_TIMEOUT is > > set to 0, as far as I understand. Source: > > https://github.com/mozilla/sccache/blob/main/docs/Configuration.md > > > > > , or until it had nothing to do and > > > SCCACHE_IDLE_TIMEOUT expired. > > > > > > i've seen at occasion the make process 'waiting' at the end of the > > > build, from my understanding because sccache was used and thus a server > > > was spawned, and the server was still running. manually killing the > > > server process allows make build to finish and proceed with make fake. > > > > Does make wait indefinitely or does it succesfully finish after some > > time? > > i think it finishes, but after the timeout. if a rust file was built > recently, you end up waiting for nothing.. > > > And when you see this problematic behavior, did you set a custom value > > for SCCACHE_IDLE_TIMEOUT? Did you use any other SCCACHE-related > > environment variables? I can't remember seeing this behavior myself > > and I haven't changed SCCACHE_IDLE_TIMEOUT. So I wonder what the > > relevant difference is between our setups. > > i have SCCACHE_ENV=SCCACHE_CACHE_SIZE="25G" SCCACHE_IDLE_TIMEOUT=1200 > , i'll remove the last one, but im pretty sure if you build a single > rust port you might see sccache hanging around at the end, waiting for > the timeout.. which would make sense after all. i dont understand why > the make process waits for it since its not a child of make anymore. Apologies for the late answer. I've tried it a couple of times but I can't reproduce it here... Really strange. To be clear: I *do* see one sccache process (the server) still running when a Rust port is done compiling, but "make package" completes normally without waiting for that process to exit. I've tried it with the benchmarks/hyperbench and x11/xcolor ports. Can you try with those ports as well to see if you see the behavior there? I can try it with a Mozilla too but then I need to write a little script so that I can verify that the process indeed prevents it from continuing, while not having to sit behind my screen all the time to wait for it to happen. Caspar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: cas...@cvs.openbsd.org 2024/01/21 08:06:12 Modified files: devel/sccache : Makefile crates.inc distinfo Log message: devel/sccache: update to 0.7.5
Re: CVS: cvs.openbsd.org: ports
On Sun, Jan 21, 2024 at 05:19:23AM -0700, Sebastian Reitenbach wrote: > CVSROOT: /cvs > Module name: ports > Changes by: sebas...@cvs.openbsd.org2024/01/21 05:19:23 > > Modified files: > audio/qsynth : Makefile distinfo > audio/qsynth/pkg: PLIST > Removed files: > audio/qsynth/patches: patch-Makefile_in > patch-src_qsynthChannelsForm_cpp > > Log message: > update to 0.9.12 > > based on patch sent for 0.9.11 by rsadowski@ > switch to QT6 and cmake > Fails to build here, not sure if I'm missing something...: CMake Error at src/CMakeLists.txt:81 (qt_add_translation): Unknown CMake command "qt_add_translation". Full configure log: ===> Building from scratch qsynth-0.9.12 ===> qsynth-0.9.12 depends on: cmake-* -> cmake-3.27.7v0 ===> qsynth-0.9.12 depends on: ninja-* -> ninja-1.11.1 ===> qsynth-0.9.12 depends on: fluidsynth->=2.3.2 -> fluidsynth-2.3.4p0 ===> qsynth-0.9.12 depends on: qt6-qtsvg->=6.5.2,<6.6 -> qt6-qtsvg-6.5.2 ===> qsynth-0.9.12 depends on: qt6-qtbase->=6.5.2,<6.6 -> qt6-qtbase-6.5.2p1 ===> Verifying specs: c++ c++abi pthread GL Qt6Core Qt6Gui Qt6Network Qt6Svg Qt6Widgets c fluidsynth m ===> found c++.9.0 c++abi.6.0 pthread.27.1 GL.19.0 Qt6Core.3.0 Qt6Gui.4.0 Qt6Network.2.0 Qt6Svg.1.1 Qt6Widgets.1.1 c.98.0 fluidsynth.3.0 m.10.1 ===> Checking files for qsynth-0.9.12 `/usr/ports/distfiles/qsynth-0.9.12.tar.gz' is up to date. >> (SHA256) qsynth-0.9.12.tar.gz: OK ===> Extracting for qsynth-0.9.12 ===> Patching for qsynth-0.9.12 ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ ===> Generating configure for qsynth-0.9.12 ===> Configuring for qsynth-0.9.12 -- The C compiler identification is Clang 16.0.6 -- The CXX compiler identification is Clang 16.0.6 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/ports/pobj/qsynth-0.9.12/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/ports/pobj/qsynth-0.9.12/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done fatal: not a git repository (or any parent up to mount point /usr) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Check if compiler accepts -pthread -- Check if compiler accepts -pthread - yes -- Found Threads: TRUE -- Performing Test HAVE_STDATOMIC -- Performing Test HAVE_STDATOMIC - Success -- Found WrapAtomic: TRUE -- Found OpenGL: /usr/X11R6/lib/libGL.so.19.0 -- Found WrapOpenGL: TRUE -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") -- Found XKB: /usr/local/lib/libxkbcommon.so.2.0 (found suitable version "1.6.0", minimum required is "0.5.0") -- Found Vulkan: /usr/local/lib/libvulkan.so.1.1 (found version "1.3.261") found components: glslangValidator missing components: glslc -- Found WrapVulkanHeaders: /usr/local/include CMake Warning at CMakeLists.txt:116 (find_package): By not providing "FindQt6LinguistTools.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt6LinguistTools", but CMake did not find one. Could not find a package configuration file provided by "Qt6LinguistTools" with any of the following names: Qt6LinguistToolsConfig.cmake qt6linguisttools-config.cmake Add the installation prefix of "Qt6LinguistTools" to CMAKE_PREFIX_PATH or set "Qt6LinguistTools_DIR" to a directory containing one of the above files. If "Qt6LinguistTools" provides a separate development package or SDK, be sure it has been installed. -- Looking for lroundf -- Looking for lroundf - found -- Looking for 3 include files fcntl.h, ..., signal.h -- Looking for 3 include files fcntl.h, ..., signal.h - found -- Checking for module 'fluidsynth' -- Found fluidsynth, version 2.3.4 -- Looking for fluid_synth_system_reset -- Looking for fluid_synth_system_reset - found -- Looking for fluid_synth_set_bank_offset -- Looking for fluid_synth_set_bank_offset - found -- Looking for fluid_synth_unset_program -- Looking for fluid_synth_unset_program - found -- Looking for fluid_version_str -- Looking for fluid_version_str - found -- Looking for fluid_settings_dupstr -- Looking for fluid_settings_dupstr - found -- Looking for fluid_preset_get_banknum -- Looking for fluid_preset_get_banknum - found -- Looking for fluid_preset_get_num -- Looking for fluid_preset_get_num - found -- Looking for fluid_preset_get_name -- Looking for fluid_preset_get_name - found -- Looking for fluid_preset_get_sfont -- Looking for fluid_preset_get_sfont - found -- Looking for fluid_sfont_get_id -- Looking
Re: NEW: games/Bugdom
On Fri, Jan 19, 2024 at 01:11:09PM -0600, izder456 wrote: > On Thu, 18 Jan 2024 10:15:14 -0600 > izder456 wrote: > > > On Thu, 18 Jan 2024 09:39:15 -0600 > > izder456 wrote: > > > > > Hey again, > > > > > > Fixed up and patched to mirror games/nanosaur2 from omar > > > > > > it was a simple enough patch. > > > > > > Comments or O.K. to merge? > > > > > > > Hey, sorry, > > > > Accidentally kept the files subdir, and didn't update the licensing > > info > > > > Attatched is the fix. > > > > Comments or OK? > > > > Sorry about the duplicate send earlier, my email provider was playing > weird with gmail. > > Attached is the port with more lined up formatting. > > That was all i had changed, Stuart mentioned that consistency is > favored in my x11/emwm port. > > Comments? Thanks for the updates to this! I made some small adjustments and attached a slightly modified tarball from yours: - I searched through the code and libsamplerate isn't used at all. Looks like upstream needs to update their ReleaseBuilds*.yml files... - I find the DESCR a lot more useful now, but went ahead and removed the last 2 paragraphs (trademark etc.) which isn't useful in DESCR. With these small adjustments, this is ok thfr@ for import... bugdom-thfr.tgz Description: application/tar-gz
Re: use subdirs to group FNA ports to streamline updates
*ping*
Re-attaching fna/ tarballed, including the @pkgpath. This is really
just a move of the other ports into games/fna/ subdirs. It would
streamline and simplify future updates significantly...
ok?
On Wed, Jan 10, 2024 at 05:41:08AM -0500, Thomas Frohwein wrote:
> On Wed, Jan 10, 2024 at 07:43:14AM +0100, Marc Espie wrote:
> > On Tue, Jan 09, 2024 at 09:51:09PM -0500, Thomas Frohwein wrote:
> > > Hi,
> > >
> > > The FNA project consists of 3 ports, currently in games/fna (.NET
> > > library), audio/faudio (audio backend), and graphics/fna3d (graphics
> > > backend). They have been separate because they were released at
> > > different times and because it wasn't clear if other non-FNA port
> > > projects would start to rely on faudio or fna3d.
> > >
> > > After a few years of experience, it's become clear that the 3 ports
> > > have strong ties for updates and no OpenBSD-relevant use with any other
> > > projects. Updates for all 3 ports are published with a strict monthly
> > > schedule and the same YY.MM version number. For this reason, it would be
> > > useful to restructure the ports so that they can be updated together.
> > >
> > > Attached is my proposal to do this by moving all 3 under games/fna
> > > (without any PKGNAME changes):
> > >
> > > audio/faudio -> games/fna/faudio
> > > games/fna -> games/fna/fna
> > > graphics/fna3d-> games/fna/fna3d
> > >
> > > This way, many updates for all 3 ports would be as simple as updating
> > > ${V} in Makefile.inc and regenerating distinfo with make makesum.
> > > Attached as tarball, as the directory changes don't lend themselves for
> > > a diff.
> > >
> > > ok? Or alternative suggestions?
> >
> > Not okay.
> > All the PLIST need @pkgpath annotation for updates to work.
> > See the details of pkg_add -u as documented in pkg_add(1)
>
> Thanks, I knew I missed a step and now it's behaving as expected with
> `make update`! Updated tarball attached that includes the @pkgpath
> lines.
fnaports-24.01-rev1.tgz
Description: application/tar-gz
Re: [Fwd: Register me]
On Sun, 21 Jan 2024 13:12:55 - beecdadd...@danwin1210.de wrote: > Original Message > Subject: Register me > From:beecdadd...@danwin1210.de > Date:Fri, January 19, 2024 1:24 pm > To: ports@openbsd.org > -- > > register me please > > See here how to subscriber to openbsd mailing lists: https://www.openbsd.org/mail.html BR/Rob
Re: fluidsynth update 2.3.4
On Sun, Jan 21, 2024 at 01:13:16PM +0100, Sebastian Reitenbach wrote:
> Hi,
>
> On Sunday, January 21, 2024 00:07 CET, Thomas Frohwein
> wrote:
>
> > Here is a version that restores sndio support again. I'm not sure how
> > best to test that what audio I'm hearing is from sndio and not sdl2,
> > but with this, sndio shows up again with fluidsynth -h as audio and
> > midi driver and a quick test with shockolate and simutrans still gives
> > me working audio.
> >
> > Please test and provide comments! I admit the CFLAGS+=-DSNDIO_SUPPORT
> > is a hack, but was the quickest way to a solution to the build system
> > pending a more thorough look where cmake needs to set this.
>
> it's not perfect yet, but makes it better. QSynth starts, takes input from my
> midi controller,
> but it also produces a humming noise. tested with a qsynth-0.9.12 (based on
> @rsadowsi's
> version he sent August last year)
>
> regarding CFLAGS, we should merge in some additional patches I sent off-list,
> I got it
> to propagate properly.
>
> Sebastian
Thanks, new diff with your cmake-related changes that doesn't need the CFLAGS+=
anymore.
ok?
Index: Makefile
===
RCS file: /cvs/ports/audio/fluidsynth/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- Makefile20 Jan 2024 20:01:56 - 1.35
+++ Makefile21 Jan 2024 13:53:23 -
@@ -3,6 +3,7 @@ COMMENT = SoundFont2 software synthesiz
GH_ACCOUNT = FluidSynth
GH_PROJECT = fluidsynth
GH_TAGNAME = v2.3.4
+REVISION = 0
SHARED_LIBS += fluidsynth 3.0 # 6.0
Index: files/fluid_sndio.c
===
RCS file: /cvs/ports/audio/fluidsynth/files/fluid_sndio.c,v
retrieving revision 1.4
diff -u -p -r1.4 fluid_sndio.c
--- files/fluid_sndio.c 29 Mar 2013 12:37:43 - 1.4
+++ files/fluid_sndio.c 21 Jan 2024 13:53:23 -
@@ -66,8 +66,6 @@ typedef struct {
fluid_midi_parser_t *parser;
} fluid_sndio_midi_driver_t;
-int delete_fluid_sndio_audio_driver(fluid_audio_driver_t* p);
-
/* local utilities */
static void* fluid_sndio_audio_run(void* d);
static void* fluid_sndio_audio_run2(void* d);
@@ -76,7 +74,7 @@ static void* fluid_sndio_audio_run2(void
void
fluid_sndio_audio_driver_settings(fluid_settings_t* settings)
{
- fluid_settings_register_str(settings, "audio.sndio.device", "default", 0,
NULL, NULL);
+ fluid_settings_register_str(settings, "audio.sndio.device", "default", 0);
}
/*
@@ -109,7 +107,7 @@ new_fluid_sndio_audio_driver(fluid_setti
dev->data = NULL;
dev->cont = 1;
- if (!fluid_settings_getstr(settings, "audio.sndio.device", )) {
+ if (!fluid_settings_getstr_default(settings, "audio.sndio.device",
)) {
devname = NULL;
}
@@ -210,7 +208,7 @@ new_fluid_sndio_audio_driver2(fluid_sett
dev->data = data;
dev->cont = 1;
- if (!fluid_settings_getstr(settings, "audio.sndio.device", )) {
+ if (!fluid_settings_getstr_default(settings, "audio.sndio.device",
)) {
devname = NULL;
}
@@ -286,19 +284,19 @@ error_recovery:
/*
* delete_fluid_sndio_audio_driver
*/
-int
+void
delete_fluid_sndio_audio_driver(fluid_audio_driver_t* p)
{
fluid_sndio_audio_driver_t* dev = (fluid_sndio_audio_driver_t*) p;
if (dev == NULL) {
-return FLUID_OK;
+return;
}
dev->cont = 0;
if (dev->thread) {
if (pthread_join(dev->thread, NULL)) {
FLUID_LOG(FLUID_ERR, "Failed to join the audio thread");
- return FLUID_FAILED;
+ return;
}
}
if (dev->hdl) {
@@ -308,7 +306,7 @@ delete_fluid_sndio_audio_driver(fluid_au
FLUID_FREE(dev->buffer);
}
FLUID_FREE(dev);
- return FLUID_OK;
+ return;
}
/*
@@ -372,17 +370,17 @@ fluid_sndio_audio_run2(void* d)
void fluid_sndio_midi_driver_settings(fluid_settings_t* settings)
{
- fluid_settings_register_str(settings, "midi.sndio.device", "default", 0,
NULL, NULL);
+ fluid_settings_register_str(settings, "midi.sndio.device", "default", 0);
}
-int
+void
delete_fluid_sndio_midi_driver(fluid_midi_driver_t *addr)
{
int err;
fluid_sndio_midi_driver_t *dev = (fluid_sndio_midi_driver_t *)addr;
if (dev == NULL) {
-return FLUID_OK;
+return;
}
dev->status = FLUID_MIDI_DONE;
@@ -391,11 +389,11 @@ delete_fluid_sndio_midi_driver(fluid_mid
err = pthread_cancel(dev->thread);
if (err) {
FLUID_LOG(FLUID_ERR, "Failed to cancel the midi thread");
- return FLUID_FAILED;
+ return;
}
if (pthread_join(dev->thread, NULL)) {
FLUID_LOG(FLUID_ERR, "Failed to join the midi thread");
- return FLUID_FAILED;
+ return;
}
}
if (dev->hdl != NULL) {
@@ -405,7 +403,7 @@ delete_fluid_sndio_midi_driver(fluid_mid
delete_fluid_midi_parser(dev->parser);
}
FLUID_FREE(dev);
- return FLUID_OK;
+ return;
}
void *
@@ -493,7 +491,7 @@
[Fwd: Register me]
Original Message Subject: Register me From:beecdadd...@danwin1210.de Date:Fri, January 19, 2024 1:24 pm To: ports@openbsd.org -- register me please
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 06:12:33 Modified files: www/c-icap/c-icap: Makefile distinfo Log message: update to c-icap-0.5.12
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 06:12:22 Modified files: www/c-icap/modules: Makefile distinfo www/c-icap/modules/patches: patch-configure_ac Log message: update to c-icap-modules-0.5.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2024/01/21 05:24:11 Modified files: net/ngtcp2 : Makefile distinfo Log message: Update ngtcp2 to v1.2.0 https://github.com/ngtcp2/ngtcp2/releases/tag/v1.2.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2024/01/21 05:19:23 Modified files: audio/qsynth : Makefile distinfo audio/qsynth/pkg: PLIST Removed files: audio/qsynth/patches: patch-Makefile_in patch-src_qsynthChannelsForm_cpp Log message: update to 0.9.12 based on patch sent for 0.9.11 by rsadowski@ switch to QT6 and cmake
Re: fluidsynth update 2.3.4
Hi,
On Sunday, January 21, 2024 00:07 CET, Thomas Frohwein
wrote:
> Here is a version that restores sndio support again. I'm not sure how
> best to test that what audio I'm hearing is from sndio and not sdl2,
> but with this, sndio shows up again with fluidsynth -h as audio and
> midi driver and a quick test with shockolate and simutrans still gives
> me working audio.
>
> Please test and provide comments! I admit the CFLAGS+=-DSNDIO_SUPPORT
> is a hack, but was the quickest way to a solution to the build system
> pending a more thorough look where cmake needs to set this.
it's not perfect yet, but makes it better. QSynth starts, takes input from my
midi controller,
but it also produces a humming noise. tested with a qsynth-0.9.12 (based on
@rsadowsi's
version he sent August last year)
regarding CFLAGS, we should merge in some additional patches I sent off-list, I
got it
to propagate properly.
Sebastian
>
> On Sat, Jan 20, 2024 at 09:22:15PM +0100, Sebastian Reitenbach wrote:
> > On Saturday, January 20, 2024 20:51 CET, "Sebastian Reitenbach"
> > wrote:
> >
> > > Hi,
> > >
> > > qsynth doesn't seem to be happy. I tried @rsadowskis version from August
> > > last year, but also updated to 0.9.12.
> > >
> > > 20:40:55.637 Qsynth1: Synthesizer engine terminated.
> > > 20:40:58.001 Qsynth1: Creating synthesizer engine...
> > > 20:40:58.004 Qsynth1: Loading soundfont:
> > > "/usr/local/share/generaluser-gs/GeneralUser_GS.sf2" (bank offset 0)...
> > > 20:40:58.193 Qsynth1: Loading soundfont:
> > > "/home/sebastia/mucke/downloads/_MIDI/arachno/Arachno SoundFont - Version
> > > 1.0.sf2" (bank offset 1)...
> > > 20:40:58.794 Qsynth1: Creating audio driver (file)...
> > > 20:40:58.795 Qsynth1: Failed to create the audio driver (file). Cannot
> > > continue without it.
> > > fluidsynth: error: Unknown string setting 'midi.sndio.device'
> > > fluidsynth: error: Unknown string setting 'audio.jack.id'
> > > fluidsynth: error: Unknown integer parameter 'audio.jack.autoconnect'
> > > fluidsynth: error: Unknown integer parameter 'audio.jack.multi'
> > >
> > >
> > > also, in the past, the audio driver was "sndio", now fluidsynth only has
> > > "file" and "sdl2" available.
> > >
> >
> >
> > FluidSynth -h output of old version:
> >
> > -a, --audio-driver=[label]
> > The name of the audio driver to use.
> > Valid values: file, sndio
> > ...
> > -m, --midi-driver=[label]
> > The name of the midi driver to use.
> > Valid values: sndio
> > ...
> >
> > New FluidSynth version:
> > -a, --audio-driver=[label]
> > The name of the audio driver to use.
> > Valid values: file, sdl2
> > ...
> > -m, --midi-driver=[label]
> > The name of the midi driver to use.
> > Valid values:
> > ...
> >
> > Sebastian
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/audio/fluidsynth/Makefile,v
> retrieving revision 1.35
> diff -u -p -r1.35 Makefile
> --- Makefile 20 Jan 2024 20:01:56 - 1.35
> +++ Makefile 20 Jan 2024 23:03:10 -
> @@ -3,6 +3,7 @@ COMMENT = SoundFont2 software synthesiz
> GH_ACCOUNT = FluidSynth
> GH_PROJECT = fluidsynth
> GH_TAGNAME = v2.3.4
> +REVISION = 0
>
> SHARED_LIBS += fluidsynth 3.0 # 6.0
>
> @@ -36,6 +37,8 @@ CONFIGURE_ARGS =-DCMAKE_DISABLE_FIND_PA
> -Denable-oss=OFF \
> -Denable-pipewire=OFF \
> -Denable-pulseaudio=OFF
> +
> +CFLAGS +=-DSNDIO_SUPPORT
>
> post-patch:
> cp ${FILESDIR}/fluid_sndio.c ${WRKSRC}/src/drivers/
> Index: files/fluid_sndio.c
> ===
> RCS file: /cvs/ports/audio/fluidsynth/files/fluid_sndio.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 fluid_sndio.c
> --- files/fluid_sndio.c 29 Mar 2013 12:37:43 - 1.4
> +++ files/fluid_sndio.c 20 Jan 2024 23:03:10 -
> @@ -66,8 +66,6 @@ typedef struct {
>fluid_midi_parser_t *parser;
> } fluid_sndio_midi_driver_t;
>
> -int delete_fluid_sndio_audio_driver(fluid_audio_driver_t* p);
> -
> /* local utilities */
> static void* fluid_sndio_audio_run(void* d);
> static void* fluid_sndio_audio_run2(void* d);
> @@ -76,7 +74,7 @@ static void* fluid_sndio_audio_run2(void
> void
> fluid_sndio_audio_driver_settings(fluid_settings_t* settings)
> {
> - fluid_settings_register_str(settings, "audio.sndio.device", "default", 0,
> NULL, NULL);
> + fluid_settings_register_str(settings, "audio.sndio.device", "default", 0);
> }
>
> /*
> @@ -109,7 +107,7 @@ new_fluid_sndio_audio_driver(fluid_setti
>dev->data = NULL;
>dev->cont = 1;
>
> - if (!fluid_settings_getstr(settings, "audio.sndio.device", )) {
> + if (!fluid_settings_getstr_default(settings, "audio.sndio.device",
> )) {
> devname = NULL;
>}
>
> @@ -210,7 +208,7 @@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: de...@cvs.openbsd.org 2024/01/21 04:58:03 Modified files: databases/victoriametrics: Makefile distinfo Log message: update to v1.93.10
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 04:36:07 Modified files: devel/p5-Modern-Perl: Makefile distinfo Log message: update to p5-Modern-Perl-1.20240120
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 04:34:23 Modified files: mail/rspamd: Makefile distinfo mail/rspamd/pkg: PLIST Added files: mail/rspamd/patches: patch-src_libstat_backends_redis_backend_cxx Log message: update to rspamd-3.8.0 patch to avoid a conflict with the _L macro in ctype.h (not the first of these that we've seen recently)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2024/01/21 04:00:03 Modified files: databases/puppetdb/7: Makefile distinfo databases/puppetdb/7/patches: patch-Makefile Log message: update 7.15.0 -> 7.16.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2024/01/21 03:59:18 Modified files: devel/ruby-concurrent-ruby: Makefile distinfo devel/ruby-concurrent-ruby/pkg: PLIST Log message: update 1.2.2 -> 1.2.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2024/01/21 03:58:41 Modified files: sysutils/ruby-facter: Makefile distinfo sysutils/ruby-facter/patches: patch-lib_facter_framework_core_file_loader_rb sysutils/ruby-facter/pkg: PLIST Log message: update 4.5.1 -> 4.5.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2024/01/21 03:57:58 Modified files: sysutils/ruby-puppet/7: Makefile distinfo Log message: update 7.27.0 -> 7.28.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 03:54:16 Modified files: mail/roundcubemail: Tag: OPENBSD_7_4 Makefile distinfo mail/roundcubemail/pkg: Tag: OPENBSD_7_4 PLIST-main Log message: update to roundcubemail-1.6.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 03:52:21 Modified files: mail/roundcubemail: Makefile distinfo mail/roundcubemail/pkg: PLIST-main Log message: update to roundcubemail-1.6.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 03:52:14 Modified files: net/icinga/core2: Makefile distinfo Log message: update to icinga2-2.14.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 03:52:10 Modified files: lang/php/8.2 : Tag: OPENBSD_7_4 Makefile distinfo lang/php/8.2/patches: Tag: OPENBSD_7_4 patch-ext_openssl_openssl_c Log message: update to php-8.2.15
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 03:51:45 Modified files: lang/php/8.3 : Makefile distinfo lang/php/8.3/patches: patch-ext_openssl_openssl_c Log message: update to php-8.3.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2024/01/21 03:51:30 Modified files: lang/php/8.2 : Makefile distinfo lang/php/8.2/patches: patch-ext_openssl_openssl_c Log message: update to php-8.2.15
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2024/01/21 03:15:01 Modified files: security/libdigidocpp: Makefile distinfo Log message: pick slightly tweaked LibreSSL fix, merged months ago
