[Bug 210548] audio/pulseaudio: Update to 9.0

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210548

--- Comment #23 from lightside <lightside at gmx.com> ---
Created attachment 173073
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=173073&action=edit
Single patch (Update to 9.0 and PORTREVISION bumps for LIB_DEPENDS)

Hello Kubilay Kocak.

(In reply to comment #22)
> I see two patches here (for separate ports) and it is unclear from the history
> what is required to progress the issue.
The second patch (current attachment #173025) was created because of following
statement in audio/pulseaudio/Makefile file:
https://svnweb.freebsd.org/ports/head/audio/pulseaudio/Makefile?revision=412344&view=markup#l4
-8<--
# !!!NOTE!!! Any PORTVERSION update to this port must be accompanied by
# PORTREVISION bumps of depending ports.
-->8-

The links to ABI tracker for PulseAudio in comment #19 shows, that 8.0 and 9.0
versions are backward compatible, which means, that there should be no breakage
for dependent ports (and no requirement for exp-run, I guess).

(In reply to comment #22)
> I also note that both attachments were created 2016-07-26, which means the
> maintainer-timeout period has not passed (for those proposed changes).
The new attachments were created because of updates by other committers for
related ports. The previous attachments were iterative updates (which didn't
change the meaning of the first attachment), because of no feedback from
maintainer, but raised issues (e.g. about USES+=localbase ssl).

(In reply to comment #22)
> Can you please combine the attachments into a single unified diff please
This is not practical, in my opinion, because the proposed patch for
audio/pulseaudio and dependent ports related to different revisions. I
submitted second patch for informative purposes (the committer may know what
ports needs PORTREVISION bumps, I think), because the possible changes for
dependent ports may invalidate some parts of it. Either way, this is just two
patch commands, instead of one.

I can post single patch, of course.

The statement in comment #21 about no maintainer-feedback is still true, as
well as for maintainer timeout, based on many unresolved PRs (with gnome@
assignee) currently and closed recently with similar maintainer timeout
statement(s). There is no point to do further work on this PR because of this
(or possible changes by other committers outside of this PR, which may do (and
did) similar things, proposed in this PR).

Thanks for your attention.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.