Duplicate and growing number of entries in Universal Plug and Play: Status

[xpendable]

It does seem that this miniupnpd package is modified a fair bit from the upstream version from the original developer. I think maybe calling it a port is not really accurate, probably closer to say that it's a fork from the main developer.

Which blurs the lines a bit, but either way I do think that the FreeBSD maintainers seem to be lacking on maintaining their packages, or at least this one in particular.

I'm sure things will get sorted out eventually, it's just a shame on how this bug was handle by the FreeBSD maintainers. Notablely the individual that caused the issue in the past commit and then ultimately fixed it... although in a completely different repository :(

[franco]

We will get this sorted. I published the verbatim patch there (it applies cleanly) and asked for assistance.


Cheers,
Franco

[AhnHEL]

Please keep us updated on all the upcoming details.  I got my popcorn ready.   ;)

[AlpAne]

@franco, is it not possible to have the new version of miniupnp as a Hotfix as a temporary solution?

[franco]

No, I'm not going to touch this mess. libctl was introduced to the FreeBSD port in October last year. If the maintainer of libpfctl wants to maintain it he can, but so far he doesn't seem to be interested. I'm not going to spend more time on it than I already have.


Cheers,
Franco

[AlpAne]

@franco, to be honest it's really hard to understand who is responsible for what??  :o

Who should we try to put some pressure on to get this mess sorted?

[franco]

Ok so it was actually November 2023 when this was introduced:

https://github.com/freebsd/freebsd-ports/commit/81e8bb983432251

libpfctl use was added via custom patches not found in upstream.

So now when we try to update to upstream 2.3.6 we have to deal with breakage in that custom scripting and I don't see why anyone else than the author should deal with this.

You can also see nobody cared to add 2.3.4 and 2.3.5 in the meantime.

Now the FreeBSD bug report exists since February 2024. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277226

The maintainer of libpfctl has not cared to work on it most likely because the report comes from OPNsense and as per his view we should fix our own problems.

Now in May 2024 this was also reported to pfSense proving that is not an OPNsense issue. It's a FreeBSD issue. https://redmine.pfsense.org/issues/15470

It was fixed within two days with the patch here https://github.com/pfsense/FreeBSD-ports/commit/6e7d96166c051

Apparently that is the same author from November who said we should work on our own issues... updating miniupnpd and adjusting the libpfctl code accordingly.

But that code never went to FreeBSD ports where it belongs. Incidentally the author is on CC in the February issue raised in FreeBSD.

I have appended his patch to the FreeBSD ticket. The standard procedure is that someone with a commit bit will bring it into the tree. I can't do more than this.

I also believe that I shouldn't have to chase an issue for a couple of months only to find out the author doesn't even want to bring his patch to FreeBSD ports and/or isn't interested in maintaining miniupnpd after making it unmaintainable for 99% of the contributors by adding libpfctl custom patches instead of working with upstream to integrate them.

I've fixed several libpfctl issues in FreeBSD base in the past that have negatively impacted our production releases because they were added to FreeBSD 13 stable branch hastily.

I know some people don't see it this way but intentionally harming OPNsense and effectively also FreeBSD with a power play over who can do what commit in FreeBSD is not a good idea.

In closing: the ball is in the court of FreeBSD now. A bug report was raised and a seemingly appropriate patch was posted. Somebody with a commit bit needs to commit it. It's the standard procedure, but it should (and could) have been taking care of weeks ago in my opinion.


Cheers,
Franco

[xpendable]

FYI, It looks like the FreeBSD maintainer that caused all this is trying to work with the upstream dev.
https://github.com/miniupnp/miniupnp/pull/671

However progress only just picked back up again by the looks of it.

[franco]

Fair enough. Doesn't help to rectify the situation of the past 3 months though.

[franco]

It has been committed to FreeBSD ports now.


Cheers,
Franco

[franco]

# opnsense-revert -z miniupnpd

Final confirmation would be good. Obviously thanks to all involved in making this happen.

[AlpAne]

# opnsense-revert -z miniupnpd

Final confirmation would be good. Obviously thanks to all involved in making this happen.

Does this mean we have a working version for OPNsense now???  ;D ;D ;D

"# opnsense-revert -z miniupnpd", is this the command to update miniupnpd without waiting for next OPNsense patch?

[franco]

Yes, opnsense-revert will give you the latest snapshot in this case. One caveat applies: your firmware mirror needs to sync the latest snapshots or use the main mirror as a workaround.


Cheers,
Franco

[AlpAne]

Yes, opnsense-revert will give you the latest snapshot in this case. One caveat applies: your firmware mirror needs to sync the latest snapshots or use the main mirror as a workaround.


Cheers,
Franco

The results of my testing so far seems to be good  :)

A big thank you to all involved sorting this out, I wish I had more knowledge and comeptence to contribute.

[BondiBlueBalls]

Will the updated code be included in 24.1.9? Also, thank you!