| Summary: | net-misc/autoupnp: Support specifying the interface to use | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | A Schenck <galiven> |
| Component: | Current packages | Assignee: | Michał Górny <mgorny> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | PATCH |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Patch to support sperifying the interface to use via `getenv` | ||
- It's fine to not use github, but please attach a `git am`able patch to the gentoo repository (make a change in your local repo then use git format-patch) - We'd still prefer the patch got sent upstream first, as it's not really an "integration" change to do downstream. Have you sent it there? If so, where? (In reply to Sam James from comment #1) > - It's fine to not use github, but please attach a `git am`able patch to the > gentoo repository (make a change in your local repo then use git > format-patch) > - We'd still prefer the patch got sent upstream first, as it's not really an > "integration" change to do downstream. Have you sent it there? If so, where? Upstream is github.com/mgorny/autoupnp. Was actually hoping they would see it here and maybe decide to use it / rewrite a better version in upstream. This patch was actually created locally in /var/tmp/portage without any git repository to use `git am` on: ```sh ebuild autoupnp-0.4.7 unpack cd /var/tmp/portage/net-misc/autoupnp0.4.7/work cp --reflink=auto -r atuoupnp-0.4.7 autoupnp-0.4.7.orig vim autoupnp-0.4.7/src/upnp.c diff -ur autoupnp-0.4.7.orig autoupnp-0.4.7 > IF_envvar.patch mv IF_envvar.patch /etc/portage/patches/net-misc/autoupnp/ ``` (In reply to A Schenck from comment #2) > (In reply to Sam James from comment #1) > > - It's fine to not use github, but please attach a `git am`able patch to the > > gentoo repository (make a change in your local repo then use git > > format-patch) > > - We'd still prefer the patch got sent upstream first, as it's not really an > > "integration" change to do downstream. Have you sent it there? If so, where? > > Upstream is github.com/mgorny/autoupnp. Was actually hoping they would see > it here and maybe decide to use it / rewrite a better version in upstream. > Oh right, mgorny's upstream. Carry on then. > This patch was actually created locally in /var/tmp/portage without any git > repository to use `git am` on: The idea was that if you're submitting a patch for an ebuild, it's usually preferred to give it in `git am`able output format, but obviously that's irrelevant now. Thanks to you, now that I touch it, I'll have to rewrite it to use meson xP. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a2e7467898e33559a28b489989b08d34aa14bdc9 commit a2e7467898e33559a28b489989b08d34aa14bdc9 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2022-11-12 05:00:12 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2022-11-12 05:01:27 +0000 net-misc/autoupnp: Bump to 0.5.0 Closes: https://bugs.gentoo.org/881029 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-misc/autoupnp/Manifest | 1 + net-misc/autoupnp/autoupnp-0.5.0.ebuild | 33 +++++++++++++++++++++++++++++++++ net-misc/autoupnp/metadata.xml | 8 ++------ 3 files changed, 36 insertions(+), 6 deletions(-) (In reply to Michał Górny from comment #4) > Thanks to you, now that I touch it, I'll have to rewrite it to use meson xP. The curse of maintaining old software that mostly "just works"™. One other thing that probly isn't worth implementing unless it's very easy is trying to maintain the registry of autoupnp ports when a process forks. The use case was nginx which seems to open ports with the parent process, then hand them off to workers and the parent process exits. It was work-aroundable by setting `daemon off;` in `nginx.conf` and adding `--background` to `start-stop-daemon` args in the init script, but adding `env LD_PRELOAD;` to `nginx.conf` wasn't enough. I'm afraid that's too much work for something I didn't use for years (progress, they call it, ISPs putting you behind NAT). To be honest, autoupnp wasn't really meant to handle nginx-class complexity. Also, I'm not convinced about the design anymore — if I were to write it today, it'd use a daemon and have the LD_PRELOAD library hand off all the work to that daemon. That would naturally handle the problem with forks. |
Created attachment 831651 [details, diff] Patch to support sperifying the interface to use via `getenv` autoupnp doesn't specify an interface on to use when calling `upnpDiscover` in miniupnpc, so miniupnpc always defaults to using the first interface. In our home router use-case that is eth0 which is the local NAT-routed LAN, while wlan0 is the upstream with the UPnP device. It turned out pretty easy to use an environment var so the patch is attached. Not a big fan of microsoft/github so posting the patch here.