Page MenuHomeFreeBSD

audio/spotify-player: Update to v0.17.1
ClosedPublic

Authored by jfree on Mar 10 2024, 5:13 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 24, 5:11 PM
Unknown Object (File)
Wed, Nov 20, 10:41 PM
Unknown Object (File)
Wed, Nov 20, 9:23 PM
Unknown Object (File)
Thu, Nov 14, 11:01 PM
Unknown Object (File)
Sat, Nov 9, 11:49 AM
Unknown Object (File)
Fri, Nov 8, 1:21 AM
Unknown Object (File)
Fri, Nov 8, 1:14 AM
Unknown Object (File)
Thu, Nov 7, 10:37 PM
Subscribers
None

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jfree requested review of this revision.Mar 10 2024, 5:13 AM
jfree created this revision.

lgtm

portfmt has two suggestions:

% git diff
diff --git a/audio/spotify-player/Makefile b/audio/spotify-player/Makefile
index f54aae43b286..0f0c8f921235 100644
--- a/audio/spotify-player/Makefile
+++ b/audio/spotify-player/Makefile
@@ -10,7 +10,7 @@ WWW=      https://github.com/aome510/spotify-player
 LICENSE=   MIT
 LICENSE_FILE=  ${WRKSRC}/LICENSE

-NOT_FOR_ARCHS=     i386
+NOT_FOR_ARCHS= i386
 NOT_FOR_ARCHS_REASON=  fails to build

 LIB_DEPENDS=   libfontconfig.so:x11-fonts/fontconfig
@@ -28,7 +28,7 @@ PLIST_FILES=  bin/spotify_player
 PORTDOCS=  README.md

 OPTIONS_DEFINE=        CLIPBOARD DAEMON DBUS DOCS IMAGE LYRICS NOTIFY
-OPTIONS_DEFAULT=   CLIPBOARD DBUS PORTAUDIO NOTIFY
+OPTIONS_DEFAULT=   CLIPBOARD DBUS NOTIFY PORTAUDIO
 OPTIONS_SINGLE=        BACKEND
 OPTIONS_SINGLE_BACKEND=    PORTAUDIO PULSEAUDIO
This revision is now accepted and ready to land.Mar 14 2024, 6:30 PM
jfree retitled this revision from audio/spotify-player: Update to v0.17.0 to audio/spotify-player: Update to v0.17.1.Mar 17 2024, 10:21 PM
jfree edited the summary of this revision. (Show Details)
  • Included portfmt's suggestions thanks to Joe
  • Version change from v0.17.0 to v0.17.1
This revision now requires review to proceed.Mar 17 2024, 10:23 PM
This revision is now accepted and ready to land.Mar 17 2024, 10:43 PM

Hey @jrm, efnet seems to be down so I can't ask you this over IRC. I keep getting freefall build failures for i386-quarterly. Would it be ok to push my changes to the relevant quarterly branches?

Hey @jrm, efnet seems to be down so I can't ask you this over IRC. I keep getting freefall build failures for i386-quarterly. Would it be ok to push my changes to the relevant quarterly branches?

Hi Jake. In general, if an independent commit fixes a build, committing the fix to the quarterly branch is reasonable. I included "independent" because the commit that fixes the build may depend on many other commits that are only in the latest branch. In that case, we may want to wait until the start of the next quarter to avoid too much churn in the quarterly branch. If this update does fix the build on i386, don't forget to remove NOT_FOR_ARCHS=i386.

BTW, efnet isn't down. Maybe it's just irc.choopa.net that's down. Efnet has a round-robin server, irc.efnet.org. If you connect there, it will try different servers until you can connect.

In D44291#1012500, @jrm wrote:

Hey @jrm, efnet seems to be down so I can't ask you this over IRC. I keep getting freefall build failures for i386-quarterly. Would it be ok to push my changes to the relevant quarterly branches?

Hi Jake. In general, if an independent commit fixes a build, committing the fix to the quarterly branch is reasonable. I included "independent" because the commit that fixes the build may depend on many other commits that are only in the latest branch. In that case, we may want to wait until the start of the next quarter to avoid too much churn in the quarterly branch. If this update does fix the build on i386, don't forget to remove NOT_FOR_ARCHS=i386.

I see. In this case, I've made several commits since 2024Q1, so I'll hold off for now. This change itself does not fix the i386 build issue. I am still looking into that.

BTW, efnet isn't down. Maybe it's just irc.choopa.net that's down. Efnet has a round-robin server, irc.efnet.org. If you connect there, it will try different servers until you can connect.

I've always used irc.servercentral.net, but efnet.org (the http website) was taking very long to respond, so I just assumed the entire network was down. I will try irc.efnet.org.

Thanks :)

This revision was automatically updated to reflect the committed changes.