Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63891 - [hostapd] 2.9-2 removes noscan patch

Attached to Project: Community Packages
Opened by viktor (dviktor) - Sunday, 22 September 2019, 23:44 GMT
Last edited by David Runge (dvzrv) - Sunday, 03 November 2019, 11:17 GMT
Task Type General Gripe
Category Packages
Status Closed
Assigned To David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

I can't find any info why 2.9-2 update has dropped support for noscan patch? Are there any issues with it?
This task depends upon

Closed by  David Runge (dvzrv)
Sunday, 03 November 2019, 11:17 GMT
Reason for closing:  Not a bug
Additional comments about closing:  The functionality is not upstreamed and should therefore be upstreamed or live in the AUR.
Comment by Alexander Schnaidt (Namarrgon) - Sunday, 22 September 2019, 23:49 GMT
https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/hostapd&id=3b5dea5b58d22e6699398901d82ff464fd54a031

I'm usually complaining about bad commit messages in the arch repos but this isn't one of them.

"[…]Removing non-standard/ not-upstreamed (and undocumented) patches.[…]"
Comment by Eli Schwartz (eschwartz) - Sunday, 22 September 2019, 23:51 GMT
The "issue with it", is that it's an undocumented patch, which diverges from upstream with no clear rationale for "why". It was removed as part of a general package cleanup.

Since you apparently know why this patch exists, and why it might be useful, perhaps you could explain, for the record, why you think it should be there?

While you are at it: has the desired change been discussed with upstream? What does upstream think about it, and why don't they merge it for everyone to benefit from?
Comment by viktor (dviktor) - Monday, 23 September 2019, 17:17 GMT
@Namarrgon, thank you for provided information, I was bit inattentive.

@eschwartz, as far as I know (and for what I used it) this patch gives hostapd admin possibility to ignore nearby routers while creating 40 MHz-wide channels. Standard recommends not to use 40 MHz-wide channels if that will worsen link quality for nearby routers, so if you've set proper capabs in hostapd.conf and RF interference is the case then hostapd will complain about interfering with other channels nearby and will use only 20 MHz-wide mode. However, this decision is based on internal calculations and may not always be true/reasonable. For example, as far as I know D-Link routers often discard this recommendation and create 40 MHz-wide channels anyway. I think that upstream doesn't merge it because of possible violation of local laws about RF hardware/software.
Comment by viktor (dviktor) - Monday, 23 September 2019, 19:06 GMT
IMHO it would be nice to have such feature and give access point admins the possibility to choose. Of course, we can have AUR package for that purpose...
Comment by David Runge (dvzrv) - Sunday, 03 November 2019, 11:16 GMT
@dviktor: Sorry for the late reply (I just came across this issue, because it was not assigned to me, but I remember writing with someone on IRC in regards to this topic, too, maybe it was you?).

In general the Arch policy is to follow upstream. By merging in patches for additionally functionality and of dubious quality (some of them were deemed not more than "a mere hack" even by their authors!) this policy has been broken.

If you require this additional functionality, please try to work with upstream to get it included, or use the AUR to track it for your use-case.

Thanks for bringing this up though and leaving a very informative message as to *what* this patch is actually supposed to do.

Loading...