Bug 226544

I would suggest a few things:

At first please correct the license tag. Actually it is tagged as BSD but it's 
dual licensed GPLv2 and BSD. Take a look into the README.

Second thing is to take the latest stable release of wpa_supplicant (actually 
0.58). You can also update the madwifi-headers to the latest release, but this 
isn't essential.

Furthermore I think it's worse to patch this software in so many ways it is 
actually done. The problem that wpa_supplicant isn't working correctly in 
Fedora 7 and 8 does not come from wpa_supplicant itself, it's a major issue of 
DBUS in the kernel. It would be smarter to fix this issue then to patch a 
software to work with other buggy software.

(In reply to comment #1)
> Furthermore I think it's worse to patch this software in so many ways it is 
> actually done. The problem that wpa_supplicant isn't working correctly in 
> Fedora 7 and 8 does not come from wpa_supplicant itself, it's a major issue of 
> DBUS in the kernel. It would be smarter to fix this issue then to patch a 
> software to work with other buggy software.

Funny, it's been working correctly for me ever since I started using it. Unlike
NetworkManager, wpa_supplicant alone works fine with my WPA2+radius/AES/TLS cert
network at work.

(In reply to comment #2)
> Funny, it's been working correctly for me ever since I started using it. 
Unlike
> NetworkManager, wpa_supplicant alone works fine with my WPA2+radius/AES/TLS 
cert
> network at work.

Unfortunately not for everyone as you can see on a rising amount of Bugzilla 
entries for wpa_supplicant since some time.

Created attachment 275141 [details]
SPEC for latest wpa_supplicant

I have created a SPEC file for the latest development release of wpa_supplicant 
based on the FC6 package (see above).

This package actually runs with FC6 and Kernel 2.6.22. All changes since the 
original file are summed up and listed in the changelog. I know not everything 
is correct with this package (referring to rpmlint) but it works so far for me. 
Former versions of this SPEC worked also (running from FC6 till F8, also CentOS 
5).

A helping hand is needed with the license tag and some other warning by rpmlint.

The license _MUST_ be BSD because wpa_supplicant links to OpenSSL and does not
include the OpenSSL exception to the GPL license.

It does not make sense to update the F8 to wpa_supplicant 0.5.8 until there bug
fixes that make sense, which when I reviewed the 0.5.7 -> 0.5.8 diff/changelog 3
weeks ago, there weren't.  When more of the Fedora patches against
wpa_supplicant get usptream, then we'll likely rev wpa_supplicant just to get
rid of the delta.

F9 will get the latest wpa_supplicant (0.6.x) when the patches have been ported
to 0.6.x and pushed up to Jouni upstream.

I'll review it.

Meanwhile this entry is a year old, but the latest attached spec file has only changed in minor things (for my personal use). This includes an update to the latest development release 0.6.6 (it works) and an update of the madwifi headers to the latest subversion trunk.

I'd like to make the suggestion to ask the developer for support for the ath5k and ath9k driver, since it seems to me that those drivers don't work directly with the wpa_supplicant but only in connection with NetworkManager.

Thx

(In reply to comment #8)
> Meanwhile this entry is a year old, but the latest attached spec file has only
> changed in minor things (for my personal use). This includes an update to the
> latest development release 0.6.6 (it works) and an update of the madwifi
> headers to the latest subversion trunk.

The madwifi headers are no longer required as the ath5k and ath9k drivers cover that hardware, and are in the upstream kernel already.

> I'd like to make the suggestion to ask the developer for support for the ath5k
> and ath9k driver, since it seems to me that those drivers don't work directly
> with the wpa_supplicant but only in connection with NetworkManager.

NetworkManager uses wpa_supplicant for all connections, so if it works in NM, it works in plain wpa_supplicant too.  I've successfully used wpa_supplicant with ath5k hardware just fine...

Remarks:

* Latest development version is 0.6.6 - consider upgrading.
* %install section needs some cleanups:
** installation should preserve timestamps (e.g. %install should be invoked with -p key)
** no need to explicitly create directories - you should use key -D
** I don't see the need to cleanup something in $BUILD/%{name}-%{version}/%{name}/doc/

E.g. I propose you to shorten install section up to

========================================

%install
rm -rf %{buildroot}

# init scripts
install -D -p -m 0755 %{SOURCE3} %{buildroot}/%{_sysconfdir}/rc.d/init.d/%{name}
install -D -p -m 0644 %{SOURCE4} %{buildroot}/%{_sysconfdir}/sysconfig/%{name}
install -D -p -m 0644 %{SOURCE6} %{buildroot}/%{_sysconfdir}/logrotate.d/%{name}

# config
install -D -p -m 0600 %{SOURCE2} %{buildroot}/%{_sysconfdir}/%{name}/%{name}.conf

# binary
install -d %{buildroot}/%{_sbindir}
install -m 0755 %{name}/wpa_passphrase %{buildroot}/%{_sbindir}
install -m 0755 %{name}/wpa_cli %{buildroot}/%{_sbindir}
install -m 0755 %{name}/wpa_supplicant %{buildroot}/%{_sbindir}
install -D -p -m 0644 %{name}/dbus-wpa_supplicant.conf %{buildroot}/%{_sysconfdir}/dbus-1/system.d/wpa_supplicant.conf
install -D -p -m 0644 %{name}/dbus-wpa_supplicant.service %{buildroot}/%{_datadir}/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service

# gui
install -D -p -m 0755 %{name}/wpa_gui/wpa_gui %{buildroot}/%{_bindir}/wpa_gui

# running
mkdir -p %{buildroot}/%{_localstatedir}/run/%{name}

# man pages
install -d %{buildroot}%{_mandir}/man{5,8}
install -m 0644 %{name}/doc/docbook/*.8 %{buildroot}%{_mandir}/man8
install -m 0644 %{name}/doc/docbook/*.5 %{buildroot}%{_mandir}/man5

========================================

http://peter.fedorapeople.org/wpa_supplicant.spec

rpmlint:

[petro@Sulaco ppc]$ rpmlint wpa_supplicant-*
wpa_supplicant.ppc: E: non-readable /etc/wpa_supplicant/wpa_supplicant.conf 0600
wpa_supplicant.ppc: W: spurious-executable-perm /usr/share/doc/wpa_supplicant-0.6.4/examples/wpas-test.py
wpa_supplicant.ppc: W: non-conffile-in-etc /etc/dbus-1/system.d/wpa_supplicant.conf
wpa_supplicant.ppc: W: doc-file-dependency /usr/share/doc/wpa_supplicant-0.6.4/examples/wpas-test.py /usr/bin/python
wpa_supplicant.ppc: W: incoherent-subsys /etc/rc.d/init.d/wpa_supplicant $prog
wpa_supplicant-gui.ppc: W: no-documentation
2 packages and 0 specfiles checked; 1 errors, 5 warnings.
[petro@Sulaco ppc]$

I think that issue non-conffile-in-etc should be fixed, while other messages may be ignored.

Another one note - should we predefine -Dwext in DRIVERS section of wpa_supplicant.sysconfig? I think that's a generally good idea. E.g. change DRIVERS="" to DRIVERS="-Dwext" in the wpa_supplicant.sysconfig .

(In reply to comment #13)
> Another one note - should we predefine -Dwext in DRIVERS section of
> wpa_supplicant.sysconfig? I think that's a generally good idea. E.g. change
> DRIVERS="" to DRIVERS="-Dwext" in the wpa_supplicant.sysconfig .

That would be a good idea since most of the drivers use wireless extensions.

A question: Are those new patches really necessary? Since I build my own wpa_supplicant based on the elder spec file, I never experienced any of the mentioned problems in regular operations.

The right question is why they still not in the upstream :)

(In reply to comment #15)
> The right question is why they still not in the upstream :)

Which specific patches do you mean?

wpa_supplicant-0.5.10-dbus-service-file.patch :: disto specific customization for log paths, not suitable for upstream

wpa_supplicant-0.5.7-flush-debug-output.patch :: ensures that debug output gets flushed immediately to help diagnose driver bugs, not suitable for upstream

wpa_supplicant-0.5.7-qmake-location.patch :: build fix for Fedora, not suitable for upstream

wpa_supplicant-0.5.7-use-IW_ENCODE_TEMP.patch :: have already discussed this with upstream and Jouni wants more information about it

wpa_supplicant-0.6.4-handle-invalid-ies.patch :: backport

wpa_supplicant-0.6.4-scan-fixes-1.patch :: backport

wpa_supplicant-0.6.4-scan-fixes-2.patch :: backport

wpa_supplicant-0.6.4-set-mode-handler.patch :: backport

wpa_supplicant-0.6.4-validate-wext-event.patch :: backport

wpa_supplicant-assoc-timeout.patch :: distro specific customization and not suitable for upstream, works around busted drivers

I've aggressively upstreamed patches from wpa_supplicant for a long time.  Some patches never will go upstream, but there's only one patch here (IW_ENCODE_TEMP) that's a candidate for upstreaming.

Also note that many of the patches marked "backport" above were only made available in the quite recent 0.6.6 release on November 23rd.

(In reply to comment #17)

[sorry, skipped]

These comments should be added to spec-file. See

https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment

> I've aggressively upstreamed patches from wpa_supplicant for a long time.  Some
> patches never will go upstream, but there's only one patch here
> (IW_ENCODE_TEMP) that's a candidate for upstreaming.

(In reply to comment #18)
> Also note that many of the patches marked "backport" above were only made
> available in the quite recent 0.6.6 release on November 23rd.


Ok, understood.

Ok, I see those patches are necessary but at least the wpa_supplicant-0.5.7-qmake-location.patch could be (or become) obsolete since wpa_supplicant is able to use either qt3 or qt4 for the gui and the qt4 installation has a default installation path in Fedora. I guess for long time reasons qt4 should be used.

Sorry for the delay. I'm returning to this ticket again.

Ok, I applied proposed cosmetic changes in comment #10 to rawhide branch. So the remaining issues are:

- Adding DRIVERS="-Dwext" to sysconfig file
- Why not to update to latest stable 0.6.10?

Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:

  https://fedorahosted.org/fesco/ticket/1269

If you don't know what merge reviews are about, please see:

  https://fedoraproject.org/wiki/Merge_Reviews

How to handle this bug is left to the discretion of the package maintainer.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Ok, I've just reviewed this spec-file and I don't see any issues. I believe we should close the ticket now.