Bug#759545: Ceni - Curses user interface for configuring network interfaces with ifupdown
Hi On Thursday 28 August 2014, Carlos Alberto Lopez Perez wrote: > Package: wnpp > Severity: wishlist > X-Debbugs-CC: k...@otaku42.de, bernard.g...@gmail.com, x-u...@berlios.de, > s@gmx.de, andre...@debian.org > > * Package name: ceni > Version : 2.28 > Upstream Author : Kel Modderman > * URL : https://github.com/fullstory/ceni > * License : GPL-2+ > Programming Lang: Perl > Description : Ceni - Curses interface to /etc/network/interfaces > > A Curses user interface for configuring network interfaces with ifupdown. > Ceni can manage basic network interface ifupdown configuration stanzas for > ethernet and wireless devices. Please note that Ceni doesn't have IPv6 support[1], which is the reason why neither of us has pushed it to Debian so far. Adding support for the various IPv6 flavours (static, SLAAC with and without privacy extensions, dhcpv6) would be reasonably possible, but isn't on the immediate to-do list, patches are of course welcome. Likewise for supporting the various IPv6 related tunneling protocols (6in4, 6t4, 6rd) or additional imginable functionality (PPPoE, VPN tunnels, etc.). If anyone were to step up to maintain this in Debian despite this known problem, we'd be happy to accommodate Ceni and help with its (existing) packaging as needed. Regards Stefan Lippers-Hollmann [1] Ceni doesn't deal with inet6 stanzas, which effectively means that ifupdown falls back to SLAAC (if available by the router) without privacy extensions enabled (privext 0). signature.asc Description: This is a digitally signed message part.
Bug#524403: please add support for the IguanaWorks USB IR Transceiver
retitle 524403 please add support for the IguanaWorks USB IR Transceiver reassign 524403 src:linux found 524403 3.6.4-1~experimental.1 tags 524403 + patch thanks Hi On Wednesday 01 August 2012, Stefan Lippers-Hollmann wrote: > Hi > > Today this patch has been merged into the linux kernel (3.6.0~rc0): > > commit 26ff63137c45886169ed102bddd6e90d6c27f00d > Author: Sean Young > Date: Sun Jul 15 13:31:00 2012 -0300 > > [media] Add support for the IguanaWorks USB IR Transceiver > > Signed-off-by: Sean Young > Signed-off-by: Mauro Carvalho Chehab > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=26ff63137c45886169ed102bddd6e90d6c27f00d > > While I can not confirm if, or how well it works (no IguanIR hardware), > I'd suggest to give it a try and discuss success/ failure with Debian's > kernel maintainers. Looking through the patch, it should be rather easy > to backport it to kernel 3.2/ wheezy as well (probably no changes > needed). Therefore I'd suggest to close or reassign src:_linux/ retitle > "please 'Add support for the IguanaWorks USB IR Transceiver'" this > bugreport. > > With my lirc maintainer hat, this kernel driver should work as-is, > configured as dev/input, using the new(ish) RC_CORE subsystem. You > can check the supported IR protocols with: > > $ cat /sys/class/rc/rc0/protocols > rc-5 nec rc-6 jvc sony sanyo mce_kbd [lirc] > [this output is taken from a mceusb device] > > The iguanair userspace tools should not be necessary anymore, depending > on your use case even lirc might not be strictly required anymore, as > the defaults -if left unconfigured- are to expose a normal input > device. > > In case there are problems, an additional follow-up patch has been > submitted a few days ago[1], but didn't make it into 3.6.0~rc0 yet. > > Feel free to contact me/ the lirc maintainer team, if you have problems > with configuring lirc for using this new kernel driver. > > Regards > Stefan Lippers-Hollmann > > [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg49730.html Please set CONFIG_IR_IGUANA=m for kernel >= 3.6, to enable RC_CORE support for IguanaIR USB IR receivers. Although this patch should be trivial to backport to kernel 3.2 without any actual code changes, I'd suggest to wait for feedback about this module first, given that I can neither test this particular hardware myself nor were able to solicit any feedback from the affected persons yet. While reviewing the RC_CORE configuration, it might make sense to enable these Kconfig symbols as well: CONFIG_IR_ITE_CIR=m <-- CIR header on some Asus x86 Mainboards CONFIG_IR_SANYO_DECODER=m <-- just another IR protocol CONFIG_IR_FINTEK=m <-- CIR header on some Jetway x86 mainboards CONFIG_IR_NUVOTON=m <-- CIR header on some ASRock x86 mainboards CONFIG_IR_WINBOND_CIR=m <-- CIR header on some Intel x86 mainboards CONFIG_IR_GPIO_CIR=m<-- probably less common Regards Stefan Lippers-Hollmann Index: debian/config/config === --- debian/config/config (Revision 19473) +++ debian/config/config (Arbeitskopie) @@ -1177,6 +1177,7 @@ # CONFIG_IR_NUVOTON is not set CONFIG_IR_REDRAT3=m CONFIG_IR_STREAMZAP=m +CONFIG_IR_IGUANA=m CONFIG_RC_LOOPBACK=m ## Index: debian/changelog === --- debian/changelog (Revision 19473) +++ debian/changelog (Arbeitskopie) @@ -1,7 +1,11 @@ linux (3.6.4-1~experimental.2) UNRELEASED; urgency=low + [ Uwe Kleine-König ] * [rt] bump to 3.6.4-rt10 + [ Stefan Lippers-Hollmann ] + * media/rc: Enable IR_IGUANA as module (Closes: #524403). + -- Uwe Kleine-König Mon, 29 Oct 2012 15:50:12 +0100 linux (3.6.4-1~experimental.1) experimental; urgency=low signature.asc Description: This is a digitally signed message part.
Bug#524403: Add support for the IguanaWorks USB IR Transceiver
Hi Today this patch has been merged into the linux kernel (3.6.0~rc0): commit 26ff63137c45886169ed102bddd6e90d6c27f00d Author: Sean Young Date: Sun Jul 15 13:31:00 2012 -0300 [media] Add support for the IguanaWorks USB IR Transceiver Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=26ff63137c45886169ed102bddd6e90d6c27f00d While I can not confirm if, or how well it works (no IguanIR hardware), I'd suggest to give it a try and discuss success/ failure with Debian's kernel maintainers. Looking through the patch, it should be rather easy to backport it to kernel 3.2/ wheezy as well (probably no changes needed). Therefore I'd suggest to close or reassign src:_linux/ retitle "please 'Add support for the IguanaWorks USB IR Transceiver'" this bugreport. With my lirc maintainer hat, this kernel driver should work as-is, configured as dev/input, using the new(ish) RC_CORE subsystem. You can check the supported IR protocols with: $ cat /sys/class/rc/rc0/protocols rc-5 nec rc-6 jvc sony sanyo mce_kbd [lirc] [this output is taken from a mceusb device] The iguanair userspace tools should not be necessary anymore, depending on your use case even lirc might not be strictly required anymore, as the defaults -if left unconfigured- are to expose a normal input device. In case there are problems, an additional follow-up patch has been submitted a few days ago[1], but didn't make it into 3.6.0~rc0 yet. Feel free to contact me/ the lirc maintainer team, if you have problems with configuring lirc for using this new kernel driver. Regards Stefan Lippers-Hollmann [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg49730.html signature.asc Description: This is a digitally signed message part.
Bug#655618: [Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries
Hi On Friday 13 January 2012, Mike Gabriel wrote: > Hi Reinhard, dear all, > > On Fr 13 Jan 2012 11:31:00 CET Reinhard Tartler wrote: > > > http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs.git;a=tree > > and, from what I see, is appropriate for being uploaded to unstable. For > > clarity, I think we should rename the git repository from nx-libs.git to > > nx-libs-light.git. Mike, can you please handle that? > > Renamed! > http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs-lite.git;a=tree [...] Thanks, this makes it a lot more reviewable (I stumbled into the full nx-libs in the master branch last night). nxcomp and nxproxy indeed don't pose the problems I mentioned last night. But I wonder, why do you need a merged source for this? The current versions of nxcomp and nxproxy, each built from their own upstream tarballs, is already at the 3.2 version state and should work (given that it's in the archive already) for client uses. If it's stability, as mentioned in some other string of this thread, that would be a mere - fixable - bug, but the only reason I can see is making the server parts buildable - and that's where my concerns of massive code duplication of the full X.org 6.9 source tree return. Yes, I'm aware of how well the NX protocol works over high latency and low bandwidth links, but I also know how much of a nightmare it is to work on that imake hell of the forked X.org 6.9, aka nx-x11, source. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201131714.11684.s@gmx.de
Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries
Hi On Friday 13 January 2012, Mike Gabriel wrote: > Package: wnpp > Version: N/A; reported 2012-01-06 > Severity: wishlist > > * Package name : nx-libs >Version : 3.5.0.3 >Upstream Author : Mike Gabriel, Oleksandr Shneyder, Reinhard Tartler > * URL : wiki.x2go.org > * License : GPLv2 >Description : NX protocol libraries and binaries [...] >NX (redist) aka nx-libgs.git on: http://git.x2go.org >http://code.x2go.org/gitweb?p=nx-libs.git;a=summary >- full code base -> master branch >- lite/client-only code base -> client-only branch This appears to still contain a full (according to its size and a short look at your packaging git), forked monolithic X.org 6.9 source tree. Most likely with little to no bug-/ security fixes since 2005 - or am I missing anything vital in that packaging git? Likewise the current debian/copyright appears to lack all copyright notices of the original XFree86/ X.org code, which makes up, by far, most of the source. What are the plans for its future maintenance, given that NoMachine NX4 appears to switch to a closed source development model and is likely to abandon the NX 3.5 code base rather soon? In a similar fashion FreeNX appears to be dead upstream since November 2008 (and already was dead way before that). Wouldn't it make more sense to concentrate on filling the gaps to re-use something like Red Hat's SPICE protocol for remote desktop uses? Regards Stefan Lippers-Hollmann Disclaimer: I've had my bite with trying to package early NX 1.x, NX 2.x versions intended for Debian, but the sheer amount of forked upstream code (in particular nx-x11) and, back then, nxssh, samba, rdesktop, esound made those attempts appear to be an endeavour in futility. However I didn't actually follow development in this arena since the early NX 3 era. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201130037.59101.s@gmx.de
Bug#642198: ITP: r8168 -- dkms source for the r8168 network driver
Hi On Tuesday 20 September 2011, Andreas Beckmann wrote: > Package: wnpp > Severity: wishlist > Owner: Andreas Beckmann > > * Package name: r8168 > Version : 8.025.00 > Upstream Author : Realtek NIC software team > * URL : > http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#2 > * License : GPL2+ > Programming Lang: C > Description : dkms source for the r8168 network driver > > r8168 is the Linux device driver released for RealTek RTL8168B/8111B, > RTL8168C/8111C, RTL8168CP/8111CP, RTL8168D/8111D, and RTL8168DP/8111DP, and > RTK8168E/8111E Gigabit Ethernet controllers with PCI-Express interface. > . > This driver should only used for devices not yet supported by the in-kernel > driver r8169. Personally speaking I'd assume this package would create much more problems than it would solve, due to the PCI ID overlap with r8169.ko shipped by the kernel packages themselves. This driver claims 10ec:8168, which is also taken by the in-kernel r8169.ko module. Upstream, all r8168 devices are (or will be) supported by the r8169.ko module (r8168.ko doesn't exist in the kernel) and RealTek recently started to participate in developing r8169.ko mainline. Which means the overlap will only increase from kernel version to kernel version in unstable, even if you'd restrict this package to squeeze (and it's not likely that a completely new packages would be accepted for upcoming point releases) the package would conflict with the kernel team's efforts to backport support for newer devices[1], as those also backport support for newer devices in stable. Please also consider that systems using both onboard PCIe r8168 and additional PCI r8169 cards are not an uncommon situation, which is not possible using this proposed driver. > This package provides the dkms source code for the r8168 kernel modules. > Kernel source or headers are required to compile these modules. > > I just came along this in #debian last week, helping someone to get this > module built and installed (upstream build system does not work properly > on kernel 3.x) because the in-kernel module r8169 did not support his > NIC. Is this driver really needed with kernel 3.0, what about 3.1~rc in experimental? If it's still missing, looking at net-next[2] it might be easier to backport a small patch adding support for the affected device than dealing with conflicting modules both claiming the same device IDs. from 2.6.39 to 3.0, r8169.ko gained support for: - RTL8168E/RTL8111E and learned about new chipset variants for: - RTL8105 - RTL8168DP from 3.0 to 3.1~rc, r8169.ko gained support for: - RTL8111E-VL and learned about new cards like: - D-Link DGE-530T rev C1 (DLG10028C) For even longer, r8169.ko supports (looking at 3.1~rc): - 3 different RTL8168b/8111b variants - 4 RTL8168c/8111c variants - 3 RTL8168cp/8111cp variants - 2 RTL8168d/8111 variants - 3 RTL8168dp/8111dp variants - 2 RTL8168e/8111e variants …which doesn't leave much of r8168.ko uncovered. > I did this package just as a first experiment with dkms, the module > builds fine with squeeze and sid kernels. I don't have the hardware to > actually test it. So if someone who actually needs it wants to take over > maintainership, he is welcome. Regards Stefan Lippers-Hollmann [1] http://lists.debian.org/debian-kernel/2011/09/msg00540.html [2] git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git git://github.com/davem330/net-next.git (temporarily) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201109201423.29489.s@gmx.de
Bug#513974: any news?
retitle 513973 RFP: b43-asm -- assembler and disassembler for Broadcom BCM43xx firmware retitle 513974 RFP: openfwwf -- Open Firmware for Broadcom b43 wlan devices thanks Hi On Wednesday 16 February 2011, xavier wrote: > Since last time, is there any news about openfwwf in debian? With the > new squeeze, will it be included in sid? A free package should be > better than nnon-free broadcom-sta, don't you think? [ Most of the talk below is about OpenFWWF and doesn't apply to b43-asm, but the only reason to upload b43-asm is in order to build OpenFWWF - so it's closely related ] The big problem I see with OpenFWWF, is upstream maintenance, which appears to be almost dead. One of the main reasons why I didn't push for getting it uploaded to Debian yet, is "We received reports about firmware problems with PCMCIA 4306/18 based cards. We are working to support them." [1], [2], which was acknowledged as a bug at 2009-05-08, but nothing has happened since... (and no, the Maranello firmware release is not a solution and doesn't work for "normal" IEEE802.11 operations and is neither usable by an unpatched linux kernel). While I personally haven't noticed these issues on my BCM4306/3 based devices (also in actual use as an access point) in practice and have gotten good feedback for bcm4311/1 (just like with some light testing on BCM4318/2), there have been according bugreports on the b43 mailing list and b43 upstream still doesn't accept bugreports in combination with OpenFWWF because of these known bugs. This means for uploading OpenFWWF to Debian, that the potential maintainer has to effectively become upstream in order to react to inevitable bugreports, which is everything but simple for OpenFWWF. Yes, OpenFWWF really is "the preferred form of modification" and it's commented exceptionally well. Yes, there are high level design specifications on [1] and in depth reverse engineering specifications at [3]. But the problem remains that actually changing this firmware is everything but easy and requires an intimate familiarity with those specifications and access to spectrum analyzers and related gear, to retain a minium of conformance testing - which is rather important for transmitting devices. At this moment, I unfortunately don't feel qualified to take that burden without an active upstream, who could take a look at eventual (and known buggy) issues. Therefore I can't be a responsible maintainer for OpenFWWF in Debian. b43-asm is actively maintained, but my only reason for maintaining b43-asm is in order to build OpenFWWF, so it doesn't make a lot of sense to upload it without OpenFWWF on the horizon. The packaging for both b43-asm [4] and OpenFWWF [5] themselves should be in a good state. OpenFWWF is up to date and the packaging should be basically complete, b43-asm just needs a few minutes of work to add a "get-orig-source" target (it's maintained solely in git and there are no upstream tarballs or formal releases) and to update it to current git HEAD. Given that I'm successfully using OpenFWWF myself, I will continue to maintain the packaging for both packages and would be willing to co-maintain both in Debian, but I simply can't effectively provide upstream maintenance for OpenFWWF - which prevents me from being a responsible maintainer for it in Debian. It's a pity, but I can't upload anything with known bugs - even if I've never noticed them myself - to Debian. Regards Stefan Lippers-Hollmann [1] http://www.ing.unibs.it/~openfwwf/ [2] http://www.spinics.net/lists/linux-wireless/msg57293.html [3] http://bcm-v4.sipsolutions.net [4] Vcs-Svn: svn://svn.berlios.de/fullstory/b43-asm/trunk Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/b43-asm/trunk [5] Vcs-Svn: svn://svn.berlios.de/fullstory/openfwwf/trunk Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/openfwwf/trunk/ signature.asc Description: This is a digitally signed message part.
Bug#602358: ITP: rtl8192ce-dkms -- Realtek RTL8192CE driver in DKMS format.
Hi On Sunday 21 November 2010, Keng-Yu Lin wrote: > 2010/11/5 Stefan Lippers-Hollmann : > > On Thursday 04 November 2010, Ben Hutchings wrote: > >> On Thu, 2010-11-04 at 19:21 +0100, Julien Cristau wrote: > >> > On Thu, Nov 4, 2010 at 10:59:41 +0800, Keng-Yu Lin wrote: > > [...] > >> > > * Package name: rtl8192ce-dkms > >> > > Version : 2.6.0003.0628.2010+dfsg > >> > > Upstream Author : Realtek Semiconductor Corporation > >> > > * URL : http://www.realtek.com > >> > > * License : GPLv2 > >> > > Programming Lang: C > >> > > Description : Realtek RTL8192CE driver in DKMS format. > >> > > > >> > > This package contains Realtek 802.11 Linux wireless driver > >> > > for use with Realtek RTL8192CE-based hardware. > >> > > >> > Why is that driver not in the standard kernel package? > >> > >> Because it's not upstream. So the next question is, why is it not > >> upstream (in staging)? > > > > This appears to be scheduled for 2.6.38: > >http://www.spinics.net/lists/linux-wireless/msg58284.html > >Message-ID: <4ccd856e.9010...@lwfinger.net> [...] > It will be very nice if someone is already working and getting this > driver in staging. Just as a follow up, the new driver has been posted for review yesterday: http://www.spinics.net/lists/linux-wireless/msg59559.html Message-ID: <4ce88170.vctqm4wju1n+oet7%larry.fin...@lwfinger.net> Given that it's already using mac80211, it may pass staging and might even enter mainline for 2.6.38. I'm sure that Larry Finger would appreciate feedback regarding it (be aware that it targets current wireless development code and might not compile against older kernels without backporting). > think to close this bug soon and please re-open it if there is still > need for this package. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101122.07204.s@gmx.de
Bug#602358: ITP: rtl8192ce-dkms -- Realtek RTL8192CE driver in DKMS format.
Hi On Thursday 04 November 2010, Ben Hutchings wrote: > On Thu, 2010-11-04 at 19:21 +0100, Julien Cristau wrote: > > On Thu, Nov 4, 2010 at 10:59:41 +0800, Keng-Yu Lin wrote: [...] > > > * Package name: rtl8192ce-dkms > > > Version : 2.6.0003.0628.2010+dfsg > > > Upstream Author : Realtek Semiconductor Corporation > > > * URL : http://www.realtek.com > > > * License : GPLv2 > > > Programming Lang: C > > > Description : Realtek RTL8192CE driver in DKMS format. > > > > > > This package contains Realtek 802.11 Linux wireless driver > > > for use with Realtek RTL8192CE-based hardware. > > > > Why is that driver not in the standard kernel package? > > Because it's not upstream. So the next question is, why is it not > upstream (in staging)? This appears to be scheduled for 2.6.38: http://www.spinics.net/lists/linux-wireless/msg58284.html Message-ID: <4ccd856e.9010...@lwfinger.net> as follow up to http://www.spinics.net/lists/linux-wireless/msg58273.html Message-ID: <4ccce60f.6090...@lwfinger.net> at least the required firmware for RTL8192CE and RTL8712U (replacing RTL8192SU/ r8192s_usb in 2.6.37) has been merged into linux-firmware.git http://lkml.indiana.edu/hypermail/linux/kernel/1011.0/00610.html Message-ID: <4cd014ec.e0ho4xdm0+tov1xt%larry.fin...@lwfinger.net> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=rtlwifi Assuming RTL8192CE support gets merged for 2.6.38, introducing a new package providing dkms support it during a freeze might not be very effective. Once it gets actually merged, a backport to (then current) 2.6.37 should be relatively trivial. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201011042253.51671.s@gmx.de
Bug#513974:
Hi Sorry about the late reply, I've been traveling till this evening and am still a little busy till the end of the week. On Monday 09 November 2009, Onkar Shinde wrote: > I am interested in testing this in Debian. My laptop has wireless card > based on 4306 chipset. Please let me know when you have a package > ready for testing. The packages (b43-asm and openfwwf) are basically ready since february and have just waited for a compatible kernel (>=2.6.31) to enter Debian/ unstable, because the proposed (kernel-) backports have been ignored by the kernel team so far. Vcs-Svn: svn://svn.berlios.de/fullstory/b43-asm/trunk Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/b43-asm/trunk http://sidux.com/debian/pool/fix.main/b/b43-asm/ Vcs-Svn: svn://svn.berlios.de/fullstory/openfwwf/trunk Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/openfwwf/trunk/ http://sidux.com/debian/pool/fix.main/o/openfwwf/ I've been successfully using them with BCM4306 and BCM4318 (and have positive feedback for BCM4311) since kernel 2.6.28 (with the required backports): http://svn.berlios.de/svnroot/repos/fullstory/openfwwf/trunk/debian/README.Debian What's left to do, in order to upload them to Debian proper (I hope I can find a little time next weekend to do the final cosmetics and talk with the potential sponsor): - add get-orig-source to b43-asm, to fetch sources from upstream git (there are no release tarballs, nor "ever" will according to upstream) - either add a boilerplate README.source to explain quilt usage or moving to source version "3.0 (quilt)", given that I really hate those useless README.source boilerplates just for standard quilt (or dpatch) usage, I'd personally tend to v3.0 - but this depends on the preferences of the potential sponsor of coourse. - adding lintian overrides where needed <-- neither upstream has any intention to drop an upstream changelog in a standard location - bump standards version to 3.8.3 for b43-asm, no (further) changes necessary OpenFWWF isn't perfect, the hardware coverage is severely limited and there are known bugs (under investigation upstream)[1], furthermore the source, even though being the genuine preferred form of modification is basically read-only, without learning the bcm-v4 specifications by heart and serious efforts to understand the state-machine and having access to good signal analyzers and wlan testing equipment - but it still just works for rev 5 core b43 cards, including ap support and noisy environments. > Cheers, > Onkar Regards Stefan Lippers-Hollmann [1] http://www.ing.unibs.it/openfwwf/ [2] http://bcm-v4.sipsolutions.net/ signature.asc Description: This is a digitally signed message part.
Bug#513973: OpenFWWF requires kernel 2.6.31
block 513974 by 533357
thanks
While most of the patches erquired for OpenFWWF have been merged upstream for
2.6.30,
b43: Add fw capabilities" 403a3a136122457165321e90b7569a321cc9ac12 [1]
to automatically disable QoS support for b43 in case of using OpenFWWF is
still missing from Debian's kernels (it's upstream for 2.6.31). Without
this patch, OpenFWWF would have to install a module-init-tools override [2]
for a mere ~6-8 weeks in unstable and handle the subsequent removal of a
bogus Debian Conffile, which has negative side effects on the alternative
proprietary firmware (or future QoS supporting OpenFWWF versions).
What holds the future:
- lenny, kernel 2.6.26 + potential backports.d.o:
- OpenFWWF is ignored by the kernel
- it's technically possible to use OpenFWWF by coaxing the kernel into
believing OpenFWWF were the proprietary firmware (installing to
/lib/firmware/b43/ + module-init-tools overrides), see [2].
- sid/ squeeze, kernel <2.6.30:
- OpenFWWF is ignored by the kernel
- sid, kernel == 2.6.30 (not available for squeeze):
- without the proprietary firmware installed, b43 can associate with
OpenFWWF, without the afforementioned patch (#533357) or a
module-init-tools override, and goes into a futile cycle of probe
timeouts, MAC suspend errors and firmware restarts (netdev watchdog
triggered)
- sid/ squeeze, kernel >=2.6.31 (or with the patch in [1]):
- working out-of-the-box
- lenny-and-a-half, assuming kernel >=2.6.31 + potential backports:
- working out-of-the-box, not active backporting necessary (OpenFWWF
has no declared runtime dependencies, it just needs a kernel
supporting it)
This indirectly also blocks b43-asm from being useful in the archive.
Regards
Stefan Lippers-Hollmann
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=403a3a136122457165321e90b7569a321cc9ac12
[2]
http://svn.berlios.de/svnroot/repos/fullstory/openfwwf/trunk/debian/README.Debian
signature.asc
Description: This is a digitally signed message part.
Bug#513974: ITP: openfwwf -- Open Firmware for Broadcom b43 wlan devices
Package: wnpp Owner: "Stefan Lippers-Hollmann" Severity: wishlist X-Debbugs-CC: Rene Engelhard * Package name: openfwwf Version : 5.1 Upstream Author : Lorenzo Nava Francesco Gringoli Michael Buesch University of Brescia * URL : http://www.ing.unibs.it/openfwwf/ * License : GPL-2 Programming Lang: assembler (b43-asm) Description : Open firmware for Broadcom BCM43xx (b43) wlan devices This package contains the open source firmware alternative for Broadcom AirForce BCM43xx wireless lan chipsets, which can be used in combination with the in-kernel b43 module of kernel 2.6.30 or above. . Known supported boards: * BCM4306 * BCM4311/1 * BCM4318 * BCM4320 This package build-depends on b43-asm, which is the required assembler to build the binary microcode for Broadcom AirForce BCM43xx wlan chipsets with a core revision >= 5. OpenFWWF in this packaging form requires kernel >=2.6.30 (current wireless-testing) to function without further changes, as the following commit[1] is required to look for the firmware at /etc/modprobe.d/openfwwf/ (and to disable hardware encryption automatically). Testing on kernel >= 2.6.25 should succeed by symlinking /lib/firmware/b43/ to /lib/firmware/b43-open/ (attention, this would clash with b43-fwcutter!) and adding "options b43 nohwcrypt=1 qos=0" to /etc/modprobe.d/openfwwf. A preliminary packaging (tested with BCM4306 and a patched kernel 2.6.28) can be found at: Vcs-Svn: svn://svn.berlios.de/fullstory/openfwwf/trunk Vcs-Browser: http://svn.berlios.de/svnroot/repos/fullstory/openfwwf/trunk/ http://svn.berlios.de/wsvn/fullstory/openfwwf/trunk/ Given that the development of OpenFWWF is currently very active, team maintenance would be ideal and moving the project to alioth or adding additional developers to the current subversion repository should be considered. CC'ing the b43-fwcutter maintainer as requested. The following information explains the current limitations of OpenFWWF and their influence on the packaging. http://svn.berlios.de/svnroot/repos/fullstory/openfwwf/trunk/debian/README.Debian Regards Stefan Lippers-Hollmann [1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commitdiff;h=0faa1094b4f6bae7705d845fee87a1b4a3501178 From: Michael Buesch Subject: b43: Automatically probe for opensource firmware -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) signature.asc Description: This is a digitally signed message part.
Bug#513973: ITP: b43-asm -- assembler and disassembler for Broadcom BCM43xx firmware
Package: wnpp Owner: "Stefan Lippers-Hollmann" Severity: wishlist X-Debbugs-CC: "Rene Engelhard" * Package name: b43-asm Version : 0~20080619 Upstream Author : Michael Buesch * URL : http://git.bu3sch.de/git/b43-tools.git * License : GPL-2 Programming Lang: C Description : assembler and disassembler for Broadcom BCM43xx firmware b43-asm is an (dis-)assembler for Broadcom AirForce BCM43xx wireless lan chipsets with a core revision >= 5. . It is capable of compiling and disassembling the opensource 'OpenFWWF' firmware used by Linux' b43 driver. This package is a build-dependency of OpenFWWF http://www.ing.unibs.it/openfwwf/ an opensource (GPL-2) firmware for Broadcom AirForce BCM43xx wlan devices, while this firmware is still in an early development stage, it allows to drive BCM4306 (tested), BCM4318, BCM4311/1 and BCM4320 in combination with the b43 (kernel >= 2.6.20) without non-free components. A preliminary packaging (which successfully compiles OpenFWWF 5.0/ 5.1) can be found at: Vcs-Svn: svn://svn.berlios.de/fullstory/b43-asm/trunk Vcs-Browser: http://svn.berlios.de/svnroot/repos/fullstory/b43-asm/trunk/ http://svn.berlios.de/wsvn/fullstory/b43-asm/trunk/ At the time of this writing, particularly the manpages and a (manual) "get-upstream" target (to fetch future updates from the upstream git repository and to assemble an orig.tar.gz) need some further attention; there is no released version of b43-asm yet, which explains the strange version number referring to the last commited patch. The, so far included, disassembler is not required to build OpenFWWF and could be omitted from the preliminary packaging (it is currently only used for running a test suite during the package build and may be useful for firmware debugging). Even though there isn't much development going on for b43-asm, I would prefer to maintain this and OpenFWWF in a team. CC'ing the b43-fwcutter maintainer as requested. Regards Stefan Lippers-Hollmann -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) signature.asc Description: This is a digitally signed message part.
Bug#470622: ITP: qtnx -- NX client for QT
Hi On Montag, 17. März 2008, Fathi Boudra wrote: > > Description: NX client for QT > > NX is a differential X compression protocol for X11. > > . > > This package provides the QT client. > > Have you sync'ed with sidux people ? I am aware of these uploads and welcome them a lot. So far there hasn't been any serious FOSS client to access NX servers available. While 2X software's 2X nxclient 1.6 has been released under the GPL v2 about 2 years ago [1], it is not really packageable for Debian due the amount of code duplication (openssh, esound, tightvnc) and would have required further extensive changes to accept the NX 3.x protocol or to obey the FHS. While qtnx suffered partly from the same code duplication issues so far, Matthew has been able to convince qtnx/ freenx upstream (George Wright and Fabian Franz) to provide a patch [2] (which is used for these uploads) to nxproxy that allows using the system's openssh packages instead of the forked nxssh. This means the current set of ITPs required for NX client functionality - nxcomp (NoMachine, GPL v2) - nxproxy (NoMachine, GPL v2) - nxcl (FreeNX, GPL) - qtnx (FreeNX, GPL) is original code of the mentioned upstreams and doesn't duplicate other packages already i the Debian archive and is released under the GPL v2 as a whole. Packaging the server components still remains to be a problem though, as that would require - FreeNX (FreeNX, GPL v2) - nxcompext (NoMachine, GPL v2) - nx-X11 (X.org 6.6 fork, GPL v2 only) - nxagent (NoMachine, built as part of nx-X11, GPL v2 only) - nxcompshad (NoMachine, GPL v2) and optionally (for printing support) - nxspool (samba 3.0.0 fork, GPL v2) in addition. > AFAIK, someone from their team work on NX related stuff. > It could be a good idea to not duplicate effort with them. While it is possible to provide "working" packages for the server components, to beat them into the FHS constraints (which isn't prepared or even intended upstream) and to link (after some patching) against Debian's variants of libjpeg62-dev libpng12-dev libssl-dev libx11-dev libxaw7-dev zlib1g-dev instead of ancient private copies of these libraries, the nx-X11 fork, whose license (GPL v2 only as a whole) prevents merging the patches into X.org upstream, remains the major blocker for Debian inclusion (or any reasonable distribution). These issues, combined with the missing security awareness/ support for the forked X.org 6.6 copy [3], [4] and personal time constraints (it is simply not possible to fix these long standing issues alone in reasonable time, it requires deeper knowledge of X11 internals, Imake, a lot of endianess and 64 bit safety awareness and a lot of time/ patience (compile times rival kernel building)), forced me to cease distribution for NX/ FreeNX about a year ago. As a whole, the situation looks better than it did in 2004 (or the NX 1.x era for that matter), as there are less forks involved than back then (and finally a decent FOSS client), but it would still require a lot of manpower and dedication to package it in a way that would stand a chance for Debian inclusion. If there is a chance for this (namely a plan to get rid off nx-X11 and a few more code contributors), I am very interested in participating in that endeavour, but as it stands, chances for that don't seem to be very encouraging. > cheers, > > Fathi Regards Stefan Lippers-Hollmann (with his sidux hat on) [1] http://code.2x.com/linuxterminalserver/browser/trunk/client [2] http://mail.kde.org/pipermail/freenx-knx/2008-March/006793.html [3] http://lists.alioth.debian.org/pipermail/pkg-nx-group/2008-January/000209.html [4] http://lists.alioth.debian.org/pipermail/pkg-nx-group/2008-January/000193.html Disclaimer: I do not claim accuracy for "GPL v2 only" versus "GPL v2 or later" for all involved packages in their most recent (development-) versions, traditionally all sources provided by NoMachine are only available under the "GPL v2 only" and a quick sample reconfirms that. signature.asc Description: This is a digitally signed message part.
