Plexhometheater will fail to build from ports if ffmpeg is already installed on the system (via ports or package). The first build errors are in target Goom : In file included from /tmp/svn.redports.org/woodsb02/multimedia/plexhometheater/work/plexinc-plex-home-theater-public-bdd03dd/xbmc/cores/dvdplayer/DVDCodecs/Audio/DVDAudioCodecFFmpeg.cpp:21: In file included from /tmp/svn.redports.org/woodsb02/multimedia/plexhometheater/work/plexinc-plex-home-theater-public-bdd03dd/xbmc/cores/dvdplayer/DVDCodecs/Audio/DVDAudioCodecFFmpeg.h:23: In file included from /tmp/svn.redports.org/woodsb02/multimedia/plexhometheater/work/plexinc-plex-home-theater-public-bdd03dd/xbmc/cores/dvdplayer/DVDCodecs/Audio/DVDAudioCodec.h:30: /tmp/svn.redports.org/woodsb02/multimedia/plexhometheater/work/plexinc-plex-home-theater-public-bdd03dd/lib/DllAvCodec.h:75:46: error: ISO C++ forbids forward references to 'enum' types virtual AVCodec *avcodec_find_decoder(enum CodecID id)=0; ^ /tmp/svn.redports.org/woodsb02/multimedia/plexhometheater/work/plexinc-plex-home-theater-public-bdd03dd/lib/DllAvCodec.h:213:64: error: variable has incomplete type 'enum CodecID' DEFINE_METHOD1(AVCodec*, avcodec_find_decoder, (enum CodecID p1))
Reported by two users: Miguel Clara and fyr
I am missing some vital information. You are the maintainer and also introduced the port to the tree a few days ago (21 august). You are the person that is responsible for fixing reported errors like this. So why are you reporting them here? If somebody else reported this error, I would open the PR and CC you to provide a solution. So what information am I missing? Are you expecting somebody else to fix your port? I am not trying to be harsh, I'm honestly perplexed by this.
Hi John, I am listed as the maintainer as I did the original porting work, however I do not have a commit bit and adamw committed the original port for me. Since I do not have a commit bit, I raised this PR as I have been notified of a problem, and it seemed the right place for me to attach the patch once I have it ready. Regards, Ben
(In reply to woodsb02 from comment #3) > Hi John, > I am listed as the maintainer as I did the original porting work, however I > do not have a commit bit and adamw committed the original port for me. Which is a completely normal situation. The majority of maintainers don't have commit bits. > Since I do not have a commit bit, I raised this PR as I have been notified > of a problem, and it seemed the right place for me to attach the patch once > I have it ready. You don't need to do that. Open a PR when you have a fix. We can't do anything with PRs like this except open them (which currently sends them to limbo and it could get buried). It will be much more effective for you to submit with a solution. OPENING - MAINTAINER and SUBMITTER are the same
Created attachment 146886 [details] mark default ports include path as -isystem See bug 193187 comment 0 for rationale.
Created attachment 146887 [details] |poudriere bulk| log (10.0R amd64) $ cat Makefile.local BUILD_DEPENDS+=ffmpeg>0:${PORTSDIR}/multimedia/ffmpeg
Tested with both patches: build OK with ffmpeg from ports installed (no running test) Thanks.
Thanks for your help Jan, I can confirm that has resolved the problem for me. How do we go about getting your patch committed?
I think you have to incorporate the Makefile.local into the Makefile to start with.
Hi John, That is not necessary. The Makefile.local was merely Jan's test file to ensure ffmpeg was installed on the system when the build was done, to confirm that the port would build on the system regardless. ffmpeg is not a dependency.
so attachment 146886 [details] is the entire patch? If so, all we need to do is change the PR status to "patch-ready" and it will eventually get picked up by a committer (it's a pool PRs purportedly ready to be committed)
Yes, that is the entire patch.
The maintainer approves the patch from Jan, it's ready to be committed. No revbump is necessary in my opinion.
Committed