Bug#655479: wpasupplicant: Please consider providing a libeap package.

2012-01-11 Thread Mathieu Trudel-Lapierre
Package: wpasupplicant
Version: 0.7.3-6
Severity: wishlist

Dear Maintainer,

I'm in the process of packaging wimax and wimax-tools in order to enable WiMAX
support in NetworkManager (and provide user-space libraries for manual use).

Unfortunately, the WiMAX sdk depends on a libeap package that should be built
from the wpasupplicant source. Fedora has included a patch, initially coming
from the linux-wimax people to achieve this; and mainly depends on building
wpasupplicant slightly differently and possibly providing an extra package
for a libeap library.

I've attached the patch for your convenience.

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (510, 'precise-updates'), (510, 'precise'), (500, 
'precise-updates'), (500, 'precise-security'), (500, 'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-8-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wpasupplicant depends on:
ii  adduser   3.113ubuntu2
ii  initscripts   2.88dsf-13.10ubuntu8
ii  libc6 2.13-24ubuntu2
ii  libdbus-1-3   1.4.16-1ubuntu2
ii  libnl-3-200   3.2.3-2ubuntu1
ii  libnl-genl-3-200  3.2.3-2ubuntu1
ii  libpcsclite1  1.7.4-2ubuntu1
ii  libreadline6  6.2-8
ii  libssl1.0.0   1.0.0e-2ubuntu4
ii  lsb-base  4.0-0ubuntu17

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  none
pn  wpaguinone

-- no debconf information
From 3de5e59b291b6f58317bb16736f8c0271754378e Mon Sep 17 00:00:00 2001
From: Inaky Perez-Gonzalez inaky.perez-gonza...@intel.com
Date: Sat, 2 Oct 2010 00:11:51 -0700
Subject: [PATCH] eap_peer: create a libeap library, with header files and pkg-config [v2]

This adds infrastructe in src/eap_peer to make libeap.so and install
the needed header files and pkg-config files.

Now, this is quite dirty and probably not what we want in the long
term, but serves as an starting point:

 - we don't build from the wpa_supplicant directory because the
   objects the .so have to be built with -fPIC. So if you need to
   build both the binary and the library:

   make -C wpa_supplicant
   make -C src/eap_peer clean
   make -C src/eap_peer

   As I said, it's dirty -- we'd need either wpa_supplicant linking
   against the library properly (but that seems not to be desirable)
   or a multiple object build approach ala automake.

 - need to use 'override CFLAGS' in src/eap_peer/Makefile, otherwise
   any CFLAGS setting will kill the build infrastructure. I miss
   AM_CFLAGS.

 - adds 'eap_register_methods()' that will register every compiled in
   method.

Signed-off-by: Inaky Perez-Gonzalez inaky.perez-gonza...@intel.com
---
 build_release  |   12 +++
 src/eap_peer/Makefile  |  191 ++--
 src/eap_peer/eap_methods.c |  114 ++
 src/eap_peer/eap_methods.h |1 +
 src/eap_peer/libeap0.pc|   10 +++
 5 files changed, 320 insertions(+), 8 deletions(-)
 create mode 100644 src/eap_peer/libeap0.pc

diff --git a/src/eap_peer/Makefile b/src/eap_peer/Makefile
index 3651056..58c067a 100644
--- a/src/eap_peer/Makefile
+++ b/src/eap_peer/Makefile
@@ -1,11 +1,190 @@
-all:
-	@echo Nothing to be made.
+LIBEAP_NAME = libeap
+LIBEAP_CURRENT = 0
+LIBEAP_REVISION = 0
+LIBEAP_AGE = 0
+
+LIBEAP = $(LIBEAP_NAME).so.$(LIBEAP_CURRENT).$(LIBEAP_REVISION).$(LIBEAP_AGE)
+LIBEAP_SO = $(LIBEAP_NAME).so.$(LIBEAP_CURRENT)
+
+.PHONY: all clean install uninstall
+
+all: $(LIBEAP)
+
+ifndef CC
+CC=gcc
+endif
+
+ifndef CFLAGS
+CFLAGS = -MMD -O0 -Wall -g
+endif
+
+CONFIG_TLS=openssl
+
+INCLUDE_INSTALL_DIR=/usr/include/eap_peer
+
+ifndef LIB
+LIB = lib
+endif
+
+# Got to use override all across the board, otherwise a 'make
+# CFLAGS=XX' will kill us because the command line's CFLAGS will
+# overwrite Make's and we'll loose all the infrastructure it sets.
+override CFLAGS += -I. -I.. -I../crypto -I../utils -I../common
+
+# at least for now, need to include config_ssid.h and config_blob.h from
+# wpa_supplicant directory
+override CFLAGS += -I ../../wpa_supplicant
+
+OBJS_both += ../utils/common.o
+OBJS_both += ../utils/os_unix.o
+OBJS_both += ../utils/wpa_debug.o
+OBJS_both += ../utils/base64.o
+OBJS_both += ../utils/wpabuf.o
+OBJS_both += ../crypto/md5.o
+OBJS_both += ../crypto/sha1.o
+OBJS_both += ../crypto/sha1-tlsprf.o
+OBJS_both += ../crypto/aes-encblock.o
+OBJS_both += ../crypto/aes-wrap.o
+OBJS_both += ../crypto/aes-ctr.o
+OBJS_both += ../crypto/aes-eax.o
+OBJS_both += ../crypto/aes-omac1.o
+OBJS_both += ../crypto/ms_funcs.o
+OBJS_both += ../crypto/sha256.o
+
+
+OBJS_both += ../eap_common/eap_peap_common.o
+OBJS_both += ../eap_common/eap_psk_common.o
+OBJS_both += ../eap_common/eap_pax_common.o
+OBJS_both += ../eap_common/eap_sake_common.o
+OBJS_both += ../eap_common/eap_gpsk_common.o
+OBJS_both += 

Bug#655479: [pkg-wpa-devel] Bug#655479: wpasupplicant: Please consider providing a libeap package.

2012-01-11 Thread Stefan Lippers-Hollmann
tags 655479 + wontfix
thanks

Hi

On Wednesday 11 January 2012, Mathieu Trudel-Lapierre wrote:
 Package: wpasupplicant
 Version: 0.7.3-6
 Severity: wishlist
 
 Dear Maintainer,
 
 I'm in the process of packaging wimax and wimax-tools in order to enable WiMAX
 support in NetworkManager (and provide user-space libraries for manual use).
 
 Unfortunately, the WiMAX sdk depends on a libeap package that should be built
 from the wpasupplicant source. Fedora has included a patch, initially coming
 from the linux-wimax people to achieve this; and mainly depends on building
 wpasupplicant slightly differently and possibly providing an extra package
 for a libeap library.
[…]

A patch like this needs upstream blessing, but I don't see anything 
like that in hostapd.git. While I wouldn't have a problem with 
backporting this from future wpasupplicant versions, I'm not going to 
carry this patch[1] for the indefinite future without any hope to ever 
get it merged upstream.

While I do see that Intel apparently proposed it to upstream more than
a year ago[2], I can't see that a consensus has been reached - nor any
follow-ups.

Sorry about it, but we will gladly reconsider once something like this
gets merged upstream.

Regards
Stefan Lippers-Hollmann

[1] which we can't teast easily within wpasupplicant or with simple 
IEEE 802.11abgn usage, so it would be doomed to bitrot from our
side.
[2] http://lists.shmoo.com/pipermail/hostap/2010-October/021795.html


signature.asc
Description: This is a digitally signed message part.