Comment 1 Kurt Jaeger 2019-01-07 21:24:44 UTC

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

Comment 2 Kurt Jaeger 2019-01-07 21:27:29 UTC

This is how I found the list of depends:

cd /usr/ports/
grep -Rl 'devel/upnp' * > /tmp/upnp

Comment 3 Lorenzo Salvadore 2019-01-09 14:07:53 UTC

(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.

Comment 4 Raphael Kubo da Costa 2019-03-30 18:17:37 UTC

Have the tests worked?

Comment 5 Lorenzo Salvadore 2019-03-30 20:04:53 UTC

(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.

Comment 6 Lorenzo Salvadore 2019-04-02 21:33:04 UTC

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).

Comment 7 Lorenzo Salvadore 2019-04-02 21:44:01 UTC

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.

Comment 8 Raphael Kubo da Costa 2019-04-07 18:14:39 UTC

Thanks for the patch, I'll try to take a look at this over the week.

Comment 9 commit-hook 2019-04-20 07:26:27 UTC

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

Comment 10 Tobias Kortkamp 2019-04-20 07:53:55 UTC

> 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 11 Lorenzo Salvadore 2019-04-24 09:37:00 UTC

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.

Comment 12 Lorenzo Salvadore 2019-05-08 17:01:55 UTC

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}.

Comment 13 Lorenzo Salvadore 2019-05-08 17:05:40 UTC

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}.

Comment 14 Lorenzo Salvadore 2019-05-08 17:17:56 UTC

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).

Comment 15 Tobias Kortkamp 2019-05-08 20:10:14 UTC

(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.

Comment 16 Tobias Kortkamp 2019-05-15 04:20:13 UTC

*** Bug 236974 has been marked as a duplicate of this bug. ***

Comment 17 commit-hook 2019-05-15 04:27:57 UTC

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