man page “passes the buck” to a dead end for .netrc docs

Re 1 - Ubuntu's packaging bug. It is the distributor's obligation to properly integrate packages.

Re 2 - not a bug in fetchmail.

Re 3 - Yes, users can expect as much, but you are right that this is not really viable because there is no such thing as a standard ftp(1). It is not part of IEEE 1003.1. Some systems also have a netrc(5), for instance, Fedora 36's netkit ftp. So: Valid wishlist item.

However, regarding the guessing: you can have the source code, so USTL: use the source, Luke. Or whoever you are.

Will consider documenting netrc for upstream as I am the upstream maintainer, but it is not in my interest to get this back into distros. Package maintainers in Ubuntu and Debian will need to see to that. https://gitlab.com/fetchmail/fetchmail/-/issues/46

Thanks for the report, Bill. And thanks for willing to solve this upstream, Matthias!

Since upstream is aware and will provide the requested docs in a future release, we can wait for that patch to be ready, then we can pull that into the development release and consider SRUing it if we can make a good case for that.

Athos, just to make sure we do not misunderstand: there has been no word of patches from me.
Any downstream backporting will be "pluck the commits from Git repo and integrate them yourselves". I may answer questions, but I will not sort out the SRU merge for Ubuntu Linux.

Hi Matthias,

Thanks for the reply.

> Any downstream backporting will be "pluck the commits from Git repo and integrate them yourselves".

That's what I meant for after https://gitlab.com/fetchmail/fetchmail/-/issues/46 gets fixed.

Let me rephrase things here:

Once https://gitlab.com/fetchmail/fetchmail/-/issues/46 is fixed upstream, the fix can make it into an Ubuntu development release. This will preferably happen through Debian (this is already the most likely path since the package is currently a sync).

Then, if anyone is interested in driving it, I'd suggest going through [1]. Realistically, since fetchmail has not received SRUs since bionic (and a minor documentation issue will hardly justify an SRU), I would not expect this to be fixed in a stable release any time soon (if at all).

With that, this makes this bug mostly a tracker for https://gitlab.com/fetchmail/fetchmail/-/issues/46, so we can ensure it does land in Ubuntu once it gets fixed.

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Staging_low_priority_uploads

Yeah, so then let's just assess that Ubuntu give a shit for stable upstream releases and does not care about users. I will ignore Ubuntu henceforth. If you have important bugs, file them through Debian.

>> can users really expect fetchmail to use the same syntax rules as the FTP client?
> Re 3 - Yes, users can expect as much

When attempting to escape quote characters using a backslash (“…\'…”), fetchmail does not treat the quote char as literal (it probably treats the backslash as literal). According to Tim Ruehsen, netkit-ftp treats the backslash as an escape so the char that follows it is taken literally:

https://savannah.gnu.org/bugs/index.php?62586#comment1

If that’s true, then it would be wrong for fetchmail docs to simply refer to netkit-ftp docs (even if netkit-ftp is installed). The netrc man page in the FTP pkg currently only gives a partial spec for .netrc as it neglects password syntax. But what if one day they were to correct that oversight and explicitly state that the backslash is an escape char?

Perhaps the fetchmail man page should say something like:

“See the ftp(1) man page for the general layout of the ~/.netrc file, but not for password syntax.”

Upstream fix: https://gitlab.com/fetchmail/fetchmail/-/commit/7bf92fc5a616c68b8ed6abb01098b08edc74f0d3

As Athos mentioned in comment #4 I will only fix it in the current devel.

I need to unassign myself due to the small amount of time for now.
Sorry