Created attachment 145052 [details]
Patch to configure to allow it to detect libprotobuf-c.so.1
When devel/protobuf-c is upgraded to version 1.0.0, it will break the build of audio/umurmur. Ideally this will be handled by the umurmur upstream, but the attached patches will unbreak the umurmur build in the meantime if they are added to the files/ directory.
Created attachment 145053 [details]
patch to src/Mumble.bp-c.c to allow build with protobuf-c 1.0.0
Created attachment 145054 [details]
patch to src/Mumble.bp-c.h to allow build with protobuf-c 1.0.0
Don, FYI the way you are providing changes is not committer friendly. IIUC, you provided 3 patches, but they are actually the contents of patches that need to go in the files subdirectory. So you are asking somebody to download each patch, rename it to patch-<path-to-final-file-whatever-they-want>, move it to files, and potentially revbump.
What committers expect is a single diff that creates the patches in files and makes any necessary changes to the other files (e.g. Makefile, pkg-plist, etc). In other words, one diff that makes all the necessary changes to update the port.
So if you make maintenance harder (unnecessarily), the volunteer committer may just move on looking for an easier PR to knock out.
I'm just letting you know because I assume you didn't realize that your approach wasn't friendly.
actually this is a maintained port, so it needs approval.
(In reply to John Marino from comment #4)
> actually this is a maintained port, so it needs approval.
It's also blocked by PR192175, so it can't go in right now anyway since it would break the port with the current version of devel/protobuf-c.
(In reply to John Marino from comment #3)
> Don, FYI the way you are providing changes is not committer friendly. IIUC,
> you provided 3 patches, but they are actually the contents of patches that
> need to go in the files subdirectory. So you are asking somebody to
> download each patch, rename it to
> patch-<path-to-final-file-whatever-they-want>, move it to files, and
> potentially revbump.
> What committers expect is a single diff that creates the patches in files
> and makes any necessary changes to the other files (e.g. Makefile,
> pkg-plist, etc). In other words, one diff that makes all the necessary
> changes to update the port.
> So if you make maintenance harder (unnecessarily), the volunteer committer
> may just move on looking for an easier PR to knock out.
> I'm just letting you know because I assume you didn't realize that your
> approach wasn't friendly.
This isn't a trivial patch and commit PR in any case, and I think my patches are
just the starting point for further discussion. Another approach is to make the change to configure and then run protobuf-c in pre-build to update the other two source files. I did that manually to generate the patches for the other two files.
Whatever approach is taken, it would be nice if someone could actually verify that the port still functions correction after it is updated. I've only verified that the changes that I made allow the port to build without error.
I'm not a user of this port, so I can't verify functionality. I'm just trying to be a bit proactive in filing this PR because I know that the port is going to be broken soon.
(In reply to Don Lewis from comment #5)
> It's also blocked by PR192175, so it can't go in right now anyway since it
> would break the port with the current version of devel/protobuf-c.
Right, that's implied by "Depends on: 192175" in the header. Bugzilla wouldn't let somebody close this ticket before that one although nothing would stop a committer from committing it prematurely other than a firm understanding of the situation. :)
Okay, it sounds like the maintainer needs to be intimately involved in the final solution then.
Created attachment 145061 [details]
consolidated patch that will create the three individual patch files under files/
As with the first patch set, this patch will tweak configure, src/Mumble.bp-c.c and src/Mumble.bp-c.h so that the port builds without error with devel/protobuf-c version 1.0.0.
Functionality has not been tested.
Created attachment 145063 [details]
alternate patch that runs protoc-c to update the .c and .h files
This is an alternate to patch 145061. It modifies the configure script the same way as 145061. However, instead of directly patching the Mumble.pb-c.c and Mumble.pb-c.h files, this patch adds a pre-build step to the port Makefile to run protoc-c to regenerate these source files from Mumble.proto.
Both this patch and the 145061 patch should give equivalent results. The approach taken is up to the maintainer's to choose.
(In reply to John Marino from comment #7)
> Okay, it sounds like the maintainer needs to be intimately involved in the
> final solution then.
Yes. I also noticed that there is a slightly newer distfile, so the maintainer may wish to also upgrade to the newer version of umurmur at the same time. Unfortunately that upgrade does not address the breakage introduced by the protobuf-c upgrade.
Created attachment 145804 [details]
patch to upgrade umurmur to version 0.2.15
The upstream has released umurmur version 0.2.15.
IPv6 dual-stack support (fmorgner).
CMake build system added alongside Autotools (fmorgner).
Update to use Protobuf-C 1.0.0.
Add 'silent' option to channel configuration.
Add 'position' option to channel configuration.
Support PolarSSL 1.3.x.
Handle PolarSSL compiled with zlib-support.
Use CLOCK_MONOTONIC instead of gettimeofday() which can cause mayhem if
time changes dramatically, e.g. when synchronizing with time
Add support for certificate chain delivery for OpenSSL via new option 'ca_path'.
This patch upgrades the FreeBSD umurmur port to version 0.2.15 and will first require upgrading devel/protobuf-c to version 1.0.x (see PR 192175).
Clean up portlint complaint about pkg-descr
A commit references this bug:
Date: Sat Aug 16 21:14:56 UTC 2014
New revision: 365135
audio/umurmur: update to 0.2.15
Submitted by: truckman
Approved by: maintainer (timeout)