Summary: | devel/upnp: Adds new options; updates to 1.8.4 or prepares port for being used as masterport | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Lorenzo Salvadore <salvadore> | ||||||||||||
Component: | Individual Port(s) | Assignee: | Tobias Kortkamp <tobik> | ||||||||||||
Status: | Closed FIXED | ||||||||||||||
Severity: | Affects Only Me | CC: | decke, pi, rakuco | ||||||||||||
Priority: | --- | ||||||||||||||
Version: | Latest | ||||||||||||||
Hardware: | Any | ||||||||||||||
OS: | Any | ||||||||||||||
See Also: | https://github.com/RetroShare/RetroShare/issues/1498 | ||||||||||||||
Bug Depends on: | 237404, 237406, 237407, 237408, 237409 | ||||||||||||||
Bug Blocks: | 236974 | ||||||||||||||
Attachments: |
|
Can you check that depends build ? I tested on 13amd64: multimedia/vdr-plugin-upnp (fails in build) multimedia/vlc (ok) net/linuxigd (fails in build) net-p2p/amule (ok) net-p2p/amule-devel (ok) net-p2p/retroshare (fails in build) sysutils/djmount (fails in configure) ChangeLog: https://github.com/mrjimenez/pupnp/blob/master/ChangeLog This is how I found the list of depends: cd /usr/ports/ grep -Rl 'devel/upnp' * > /tmp/upnp (In reply to Kurt Jaeger from comment #1) I'm working on the tests. Please observe that multimedia/vdr-plugin-upnp is marked as broken on 12 and 13. Have the tests worked? (In reply to Raphael Kubo da Costa from comment #4) Yes and no. It turned out that upnp-1.6.* and upnp-1.8.* are two distinct and incompatible branches of the project, both in development: this is similar to the python27/36 issue. Thus, - I've reverted original upnp to 1.6.25, applying to it the rest of the patch. I tested the dependent ports with upnp built with default options and it worked; - I've created a new port named upnp18 to track the upnp-1.8.* development branch. I tested the build and it worked. However I have not submitted the patch for 1.6.25 nor the new upnp18 port yet because I still have to solve the conflict between them: I think it is an easy fix and I hope to have it ready in a few days. Created attachment 203328 [details]
upnp - more options
And finally, here it is.
This patch is a patch for the same version that was already in ports tree, but it brings many new options to choose from.
Moreover, it includes some changes for using it as masterport for the new port upnp18.
I tested it successfully with poudriere on 11.2/12.0-RELEASE amd64/i386, including dependent ports. However, I suggest that someone repeats the test: I made a few minor changes since testing and I have not checked again (I have an old and slow machine, such tests take ages for me).
Created attachment 203330 [details]
upnp - 1.6.25 with more options (correction 1)
Sorry, I put COMMENT?= in the slave port instead of master. This fix it.
Thanks for the patch, I'll try to take a look at this over the week. A commit references this bug: Author: tobik Date: Sat Apr 20 07:25:31 UTC 2019 New revision: 499428 URL: https://svnweb.freebsd.org/changeset/ports/499428 Log: Deprecate net/linuxigd It does not build with libupnp >= 1.8 and upstream is dead. net/miniupnpd is a maintained alternative. PR: 234669 Changes: head/net/linuxigd/Makefile > It turned out that upnp-1.6.* and upnp-1.8.* are two distinct and
> incompatible branches of the project, both in development: this is
> similar to the python27/36 issue.
It would be better not to fragment libupnp and fix/remove/mark
broken the consumers that do not build with libupnp >= 1.8. There
are not that many.
Comment on attachment 200843 [details]
upnp - update to 1.8.4
I remove obsolete flag to the patch for update for 1.8.4, since it seems we can avoid maintaining the two branches.
Created attachment 204273 [details]
upnp - 1.6.25 with more options (correction 2)
This patch fixes a small issue with pkg-plist: upnptools.h is installed only if TOOLS option is enabled.
Tested successfully with poudriere on {11.2-12.0}-RELEASE {i386,amd64}.
Created attachment 204274 [details]
upnp - update to 1.8.4
This patch restores some patch files that I removed before: since there was no reason to remove them, I put them back.
Tested successfully with poudriere on {11.2-12.0}-RELEASE {i386,amd64}.
I tried to work on bug #237404 and #237409 to fix them, but I think the two softwares are too old to use upnp branch 1.8.x: - djmount is more than 10 years old and everytime I fix a problem a new problem comes up (and the last one looks to be too big to be solvable without rewriting much of the source code); - I am still working on vdr-plugin-upnp; the actual version looks to be quiet difficult to build with upnp 1.8.x, but I have discovered that the port is out of dat, then I will try to update it (but still the last release is from 2013). Moreover, the port is unmaintained: maybe nobody is really interested in it. As I said, I will keep trying with vdr-plugin-upnp, but I think we have to possibilities: 1) maintain two ports -- upnp and upnp18 (or upnp16 and upnp)-- as I initially suggested, so that we do not lose any port; 2) update the original upnp port to the 1.8.x branch, but this will require removing from the ports tree those ports that can not be built with the new branch (djmount and, probably, vdr-multimedia-plugin). (In reply to Lorenzo Salvadore from comment #14) > I tried to work on bug #237404 and #237409 to fix them, but I think the two > softwares are too old to use upnp branch 1.8.x: > > - djmount is more than 10 years old and everytime I fix a problem a new > problem comes up (and the last one looks to be too big to be solvable > without rewriting much of the source code); > - I am still working on vdr-plugin-upnp; the actual version looks to be > quiet difficult to build with upnp 1.8.x, but I have discovered that the > port is out of dat, then I will try to update it (but still the last release > is from 2013). Moreover, the port is unmaintained: maybe nobody is really > interested in it. I would not waste your time on vdr-plugin-upnp. All multimedia/vdr* ports should probably be removed as they haven't really been updated in 6 years and are based on an old developer snapshot of vdr. I doubt updates of it are trivial either given the amount of patches in some of them. I wonder if there are even users of it left too. I deprecated djmount and vdr-plugin-upnp with expiration date of next week. Let's see if somebody complains and if not go ahead with the update to 1.8. *** Bug 236974 has been marked as a duplicate of this bug. *** A commit references this bug: Author: tobik Date: Wed May 15 04:27:32 UTC 2019 New revision: 501684 URL: https://svnweb.freebsd.org/changeset/ports/501684 Log: devel/upnp: Update to 1.8.4 - Bump revision of consumers for shared library change Changes: http://pupnp.sourceforge.net/ChangeLog PR: 234669 Submitted by: Lorenzo Salvadore <phascolarctos@protonmail.ch> (maintainer) Changes: head/devel/upnp/Makefile head/devel/upnp/distinfo head/devel/upnp/files/ head/devel/upnp/pkg-plist head/multimedia/vlc/Makefile head/net-p2p/amule/Makefile head/net-p2p/amule-devel/Makefile |
Created attachment 200843 [details] upnp - update to 1.8.4 Update to 1.8.4. There is a changelog file in ${WRKSRC}/ChangeLog but it is most probably out of date: last update is 2017-11-17 while the 1.8.4 release is dated 25 Oct 2018. Port changelog: - Uses GitHub. On GitHub release-1.6.25 is labeled latest release, however release-1.8.4 is released with a later date. - Defines DISTVERSION instead of PORTVERSION to better integrate with GitHub (increasing of PORTVERSION has been checked). - Defines many options based on configure script. - Provides a TEST option. Tested successfully with portlint and with poudriere on 11.2-RELEASE and 12.0-RELEASE i386/amd64. Testing on poudriere with TEST option enabled requires network access (add upnp to ALLOW_NETWORKING_PACKAGES variable in poudriere.conf).