Bug#572220: releasing ownership of crda/wireless-regdb ITP's
retitle 536502 RFP: crda -- wireless Central Regulatory Domain Agent noowner 536502 retitle 572220 RFP: wireless-regdb -- wireless regulatory database noowner 572220 thanks I've owned these ITP's for over a month now and failed to close them with an upload of this software to Debian; therefore I have failed and do not wish to block efforts from anyone else who is interested. I've lost all momentum/motivation required to get these into Debian. Upstream is no longer receptive to my opinion that their default to installing a prebuilt/presigned regulatory.bin is not an option for Debian, and I've come up with a few NAK'd patches which try to make the build system more sympathetic to my cause. Existing packages are at: svn://svn.debian.org/pkg-wpa/crda/trunk http://svn.debian.org/wsvn/pkg-wpa/crda/trunk/ svn://svn.debian.org/pkg-wpa/wireless-regdb/trunk http://svn.debian.org/wsvn/pkg-wpa/wireless-regdb/trunk/ -- 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/201005230845.45215@otaku42.de
Bug#536502: ITP: crda -- wireless Central Regulatory Domain Agent
On Sunday 25 April 2010 21:06:18 Petter Reinholdtsen wrote: Is this the same package that is already packaged for Ubuntu as URL: https://launchpad.net/ubuntu/+source/wireless-crda ? Same package, no. Same software, yes. Thanks, Kel. -- 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/201004252217.54562@otaku42.de
Bug#536502: change ITP to RFP
retitle 536502 ITP: crda -- wireless Central Regulatory Domain Agent owner 536502 Kel Modderman k...@otaku42.de thanks Package will be maintained by pkg-wpa group. Kel. -- 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/201003022305.02350@otaku42.de
Bug#572220: ITP: wireless-regdb -- wireless regulatory database
Package: wnpp Severity: wishlist Owner: Kel Modderman k...@otaku42.de * Package name: wireless-regdb Upstream Author : Luis R. Rodriguez mcg...@gmail.com * URL : http://wireless.kernel.org/en/developers/Regulatory/#Theregulatorydatabase * License : ISC Programming Lang: C, Python Description : wireless regulatory database This package contains the wireless regulatory database used by the Central Regulatory Database Agent (CRDA) to configure wireless devices to operate within the radio spectrum allowed in the local jurisdiction. . This regulatory information is provided with no warranty either expressed or implied. Only Linux drivers which use cfg80211 framework can make use of the regulatory database and CRDA. -- 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/20100302125850.1429.35665.report...@localhost
Bug#536502: Debian status of crda wireless-regdb?
Hi Paul, On Monday 17 August 2009 14:31:41 Paul Wise wrote: On Sun, 2009-08-16 at 21:34 +1000, Kel Modderman wrote: My take on packaging crda/wireless-regdb can be seen/tested at: crda: Vcs-Svn: svn://svn.debian.org/pkg-wpa/crda/trunk Vcs-Browser: http://svn.debian.org/wsvn/pkg-wpa/crda/trunk/ wireless-regdb: Vcs-Svn: svn://svn.debian.org/pkg-wpa/wireless-regdb/trunk Vcs-Browser: http://svn.debian.org/wsvn/pkg-wpa/wireless-regdb/trunk/ Comments from my point of view: * the legal consequences of disabling crypto verification of regulatory.bin concern me because I simply do not know if there could be any in the future. Ah, why was crypto verification disabled? In any case the software is FLOSS and anyone could patch it to set arbitrary regulatory info so a bit of crypto verification isn't more than a slight bump for someone who wants to violate spectrum regulations. It was disabled to build it sanely in Debian. Work to do this without patching can be done progressively, I think, by developing and sharing generic patches to build system with upstream. * other consequences of disabling crypto verification are keeping Debian specific patches in sync with upstream. They are pretty simple though. Upstream seemed fairly reasonable to me so I imagine they would accept anything implemented generically enough. Ack. * your previous comments contained something about developing a package for backporting to a theoretical lenny + 1/2 - I have no interest in targetting a package for anything other than current testing/sid and using all good features currently available there. If it is easy enough to make it backportable patches would be welcome. Fair enough. Given that the Debian release managers want to freeze for squeeze in December to sync with Ubuntu, lenny and a half is unlikely to happen or be needed. * enabled use of dpkg trigger to synchronise the country name - country code matrix parsed from tzdata's zone.tab file. The result is stored in /etc/default/crda in a section clearly labelled as automatically managed by maintainer scripts. All other modification to the conffile done by admin are preserved. That bit looks good to me, I haven't tested it though. Am not fully committed to maintaining these packages, would file ITP's if I was. Need to get (active) co-maintainers but haven't made a huge effort to do that yet. Fair enough. Would you be interested in being a co-maintainer or making package uploads with me? The most I could commit to would be sponsorship and review of the packaging and upstream's mechanisms. At first glance the current packaging looks generally good, although I think a fair bit of stuff could be pushed upstream, even the patches marked Debian-specific. Okay. I'm afraid I will be unable to work on this until November at the earliest due to relocating self internationally via a whole bunch of nice locations. It'd be nice if someone picks up my work, or at least finds some of it useful as they forge out their own package(s) in the next month or 3. Is upstream still embedding the RSA public keys in the crda binary? Yes. PS: any idea if GNOME/KDE will be using GeoClue or similar mechanisms to detect the appropriate regulatory domain and set it automatically? IIRC, Luis the crda upstream expressed his desire for this to happen somewhen but I am not personally aware of any work toward this. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510005: TouchFreeze
On Thursday 19 February 2009 21:43:00 Mike Arthur wrote: They aren't similar in this regard, it says on the KDE-apps page that ksynaptics ranks high on powertop whereas this isn't meant to. It uses a a little bit of cpu cycles. It would be good to get this included now that we don't have q/ksynaptics. http://ftp-master.debian.org/new/touchfreeze_0.2.3-1.html Thanks, Kel. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510005: ITP: touchfreeze -- a facility for disabling touchpad tap-to-click function
On Tuesday 30 December 2008 03:44:26 Josselin Mouette wrote: Le dimanche 28 décembre 2008 à 15:38 +0100, Evgeni Golov a écrit : On Mon, 29 Dec 2008 00:04:58 +1000 Kel Modderman wrote: Touchfreeze docks in your system tray and disables your touchpad while typing. It re-enables your touchpad when typing stops, using a configurable delay time. How does this compare to syndaemon from xserver-xorg-input-synaptics? Especially, does it avoid waking up the CPU several tens of times per seconds like syndaemon does? I think they are similar in that regard ... Thanks, Kel. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510005: ITP: touchfreeze -- a facility for disabling touchpad tap-to-click function
Package: wnpp Severity: wishlist Owner: Kel Modderman k...@otaku42.de * Package name: touchfreeze Upstream Author : Stefan Kombrink katako...@gmail.com * URL : http://qsynaptics.sourceforge.net/dl.html * License : GPL-3+ Programming Lang: C++ Description : a facility for disabling touchpad tap-to-click function Touchfreeze docks in your system tray and disables your touchpad while typing. It re-enables your touchpad when typing stops, using a configurable delay time. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510005: ITP: touchfreeze -- a facility for disabling touchpad tap-to-click function
On Monday 29 December 2008 00:38:09 Evgeni Golov wrote:
On Mon, 29 Dec 2008 00:04:58 +1000 Kel Modderman wrote:
Touchfreeze docks in your system tray and disables your touchpad
while typing. It re-enables your touchpad when typing stops, using a
configurable delay time.
How does this compare to syndaemon from xserver-xorg-input-synaptics?
It's a GUI application which sits in the system tray of desktop environments
that support that, whereas syndaemon is a command line utility.
Touchfreeze is a (limited) replacement for {k,q}synaptics, which were
developed by (to best of my knowledge) the same person/people, which have
since been declared abandonware and removed from Debian [0].
[0] http://bugs.debian.org/468941
Fathi Boudra intended to package touchfreeze, but didn't do so. I contacted
pkg-kde-extras team and co-ordinated to help maintain it under their
maintenance umbrella [1].
[1]
http://lists.alioth.debian.org/pipermail/pkg-kde-extras/2008-September/006333.html
Thanks, Kel.
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499537: ITP: iw -- tool for configuring Linux wireless devices
On Wednesday 24 September 2008 07:55:04 Guus Sliepen wrote: On Wed, Sep 24, 2008 at 07:05:20AM +1000, Kel Modderman wrote: * Package name: iw Description : tool for configuring Linux wireless devices Is this going to replace wireless-tools, or is it to be used in conjuction with wireless-tools? As I understand it, it would ultimately supercede wireless tools, but there would be an extremely long overlap period. During which time, I have no idea how they will co-operate, do you? No :) In the short term, I think that iw will not be useful in conjunction with any Debian provided linux-image [0], and only of interest to Debian-its using some wireless-testing tree (or branch of), thefore not much system integration is needed yet. It's probably more important to have a recent version of iw in experimental for the more curious people, and to send bug reports on to Johannes. During this period we may get an idea about how to intergrate it into Debian in a similar manner to wireless tools. [0] for example it won't work with 2.6.26 without first fixing nl80211 bugs You are the maintainer of wireless-tools, would you like to help with or have iw? Well, I don't have any hardware that works with software drivers (yet), so it would be very hard for me to test iw. But I would like to work together to make sure there are no conflicts between the two tools, and perhaps to merge functionality where it can and should be merged. Please consider being part of pkg-wpa team, or if that is undesirable the iw package could be moved somewhere else where you feel comfortable working on it in the future. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499537: ITP: iw -- tool for configuring Linux wireless devices
On Wednesday 24 September 2008 06:27:47 Guus Sliepen wrote: On Sat, Sep 20, 2008 at 01:06:06AM +1000, Kel Modderman wrote: * Package name: iw Description : tool for configuring Linux wireless devices Is this going to replace wireless-tools, or is it to be used in conjuction with wireless-tools? As I understand it, it would ultimately supercede wireless tools, but there would be an extremely long overlap period. During which time, I have no idea how they will co-operate, do you? You are the maintainer of wireless-tools, would you like to help with or have iw? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499537: ITP: iw -- tool for configuring Linux wireless devices
Package: wnpp Severity: wishlist Owner: Kel Modderman [EMAIL PROTECTED] * Package name: iw Upstream Author : Johannes Berg [EMAIL PROTECTED] * URL : http://wireless.kernel.org/en/users/Documentation/iw * License : BSD-3 Programming Lang: C Description : tool for configuring Linux wireless devices This package contains the `iw' tool which allows you to configure and show information about wireless networking. The tool is currently mainly used for drivers based on the mac80211 stack but work is under way to make it useful for other drivers as well. This package will be maintained by the Debian/Ubuntu wpasupplicant Maintainers [EMAIL PROTECTED] at: svn://svn.debian.org/pkg-wpa/iw/trunk http://svn.debian.org/wsvn/pkg-wpa/iw/trunk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499537: might conflict with aircrack-ng?
On Saturday 20 September 2008 06:01:52 Johannes Berg wrote: iw was intended to be put into /usr/bin but aircrack-ng ships a version in /usr/sbin/, see bug 499246 Indeed, I added a Conflicts: aircrack-ng to the debian/control file because of this when preparing the package this afternoon. What aircrack-ng is doing makes iw look bad for breaking policy: Section 2.5 Priorities Note that optional packages should not conflict with each other. Bad aircrack maintainer :) Once the bastard iw is removed from aircrack-ng, the Conflicts field can have a version conditional added to it. On a side note, iwconfig is currently installed to /sbin (and it doesn't link with anything on /usr/), as I understand it is there so that it may be used to configure a network device early in boot so that a network filesystem may be mounted (which might be /usr/). iw seems to make iwconfig redundant in the future. Currently iw links to /usr/lib/libnl.so.X, but if libnl was changed to reside in /lib sometime in the future, I can imagine some people picketing to have iw moved from /usr/bin/ to /bin or /sbin, what is your take on this? Note that i personally think mounting critical network filesystems over wireless to be crazy. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499537: might conflict with aircrack-ng?
On Saturday 20 September 2008 06:49:20 Johannes Berg wrote: On a side note, iwconfig is currently installed to /sbin (and it doesn't link with anything on /usr/), as I understand it is there so that it may be used to configure a network device early in boot so that a network filesystem may be mounted (which might be /usr/). iw seems to make iwconfig redundant in the future. Currently iw links to /usr/lib/libnl.so.X, but if libnl was changed to reside in /lib sometime in the future, I can imagine some people picketing to have iw moved from /usr/bin/ to /bin or /sbin, what is your take on this? Note that i personally think mounting critical network filesystems over wireless to be crazy. :) If you really want to go there... I'm thinking /usr/bin since I don't see it as that critical right now, but if anybody complains it can be changed I guess. I don't like sbin that much because it's not in the default $PATH, and the tool most definitely _is_ useful even for users who can only read. Even iwconfig/iwlist is, in my opinion, misplaced in sbin. Yep. I think either /usr/bin or /bin is most appropriate, but I just have this feeling that someone will want their wifi to get /usr/ mounted sometime (this is Debian, they want to do this crazy stuff all the time), which means that using /bin now would cause less headaches in the future (when everyones scripts are using absolute paths to /usr/bin/iw already...). If that is a realistic scenario, it would leave the choice of the Debian iw maintainer to a) say that use case is not possible, and stick to his guns, or b) move iw to /bin and thus possibly diverge from what the rest of the distro's, and you as upstream, are doing. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499537: might conflict with aircrack-ng?
On Saturday 20 September 2008 07:24:22 Johannes Berg wrote: On Sat, 2008-09-20 at 07:03 +1000, Kel Modderman wrote: Yep. I think either /usr/bin or /bin is most appropriate, but I just have this feeling that someone will want their wifi to get /usr/ mounted sometime (this is Debian, they want to do this crazy stuff all the time), which means that using /bin now would cause less headaches in the future (when everyones scripts are using absolute paths to /usr/bin/iw already...). It's pathogenic, and I'd suggest to put iw into the initramfs ;) If that is a realistic scenario, it would leave the choice of the Debian iw maintainer to a) say that use case is not possible, and stick to his guns, or b) move iw to /bin and thus possibly diverge from what the rest of the distro's, and you as upstream, are doing. Doesn't that depend on libnl upstream again? That installs to /usr/lib by default, so I don't think I should install to /bin as iw upstream. I'd be willing to change but it seems that it depends on libnl upstream changing too? For it to be an effective change, yep, it would depend on that. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396648: ITP: rt73 -- Linux device driver for Ralink RT73 a/b/g WLAN Card
On Thursday 02 November 2006 08:55, Piotr Roszatycki wrote: Package: wnpp Severity: wishlist Owner: Piotr Roszatycki [EMAIL PROTECTED] * Package name: rt73 Upstream author : Paul Lin [EMAIL PROTECTED] Version : 1.0.3.6 * URL : http://www.ralinktech.com/drivers/Linux/RT73_Linux_STA_Drv1.0.3.6.tar.gz * License : GPL Programming Lang: C Description : Linux device driver for Ralink RT73 a/b/g WLAN Card I am the owner of USB-stick Wi-Fi network interface (Edimax EW-7318Ug). The only working driver is Ralink RT73 original driver. I'd like to see this driver in Debian distribution. I want to provide rt73-source package which is compatible with module-assistant. The resulting package (rt73-module-$VERSION) contains rt73.ko driver. The driver loads firmware from separate file and has included the blob with the default firmware if separate file is not available. I think the driver can go to contrib with removed the blob from its sources and with the firmware rt73.bin file can go to non-free as rt73-firmware package. The rt73.bin file is marked as GPL. There is no real source code included but this license implies that it is redistributable file at least as non-free. I notice you quote upstream origin is ralinktech.com, but what about the rt73 drivers from rt2x00 project[1], that are maintained and bugfixed by a bunch of cool hackers, and are the origin of the existing rt2400, rt2500, rt2570 and rt2x00 source packages already in debian? Thanks, Kel. [1] http://rt2x00.serialmonkey.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391032: ITP: gspca -- source for the gspca v4l kernel module
Package: wnpp Severity: wishlist Owner: Debian spca5xx Maintainers [EMAIL PROTECTED] * Package name: gspca Version : 01.00.04 Upstream Author : Michel Xhaard [EMAIL PROTECTED] * URL : http://mxhaard.free.fr/index.html * License : GPL Programming Lang: C Description : source for the gspca v4l kernel module The gpsca video for linux (v4l) driver, provides support for webcams and digital cameras based on the spca5xx range of chips manufactured by SunPlus, Sonix, Z-star, Vimicro, Conexant, Etoms, Mars-semi, Pixart and Transvision. . The gspca driver is a rewrite of the well known spca5xx v4l kernel module from the same author, Michel Xhaard. . This package provides the source code for the gspca kernel modules. Kernel source or headers are required to compile these modules. For basic install steps see /usr/share/doc/gspca-source/README.Debian.gz . http://mxhaard.free.fr/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363967: [RFC]: new proposal for starting ipw3945d
Hi Steinar, I notice some of my ipw3945 efforts have been mentioned in ITP's. I'd love to see my efforts go directly into debian. I do not have the hardware, only a fair idea of how all the ipw3945 pieces should go together, so I'd love to hand off my work to an interested party with the hardware to test or have my work sponsored/co-maintained or whatever. I'd like to know if you'd be willing to comment on a new mechanism of starting ipw3945d, or verify if it even works. I've noticed on blogs and other google yields (but not ever been told directly via email) that users of my ipw3945 packages (and also users of other distro's) are experiencing difficulty with the initial module load + ipw3945d start. So I've adapted the comments from Md[1] and incorporated them into a new source package[2]. If you could check out the ugly hacks involved and see if they work more reliably than the previous approach, I'd appreciate that. Thanks, Kel. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381722 [2] http://users.tpg.com.au/sigm/misc/ipw3945d/ipw3945d_1.7.22-1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363967: Bug#372118: [RFC]: new proposal for starting ipw3945d
On Monday 14 August 2006 02:31, Daniel Baumann wrote: Kel Modderman wrote: I notice some of my ipw3945 efforts have been mentioned in ITP's. I'd love to see my efforts go directly into debian. I do not have the hardware, only a fair idea of how all the ipw3945 pieces should go together, so I'd love to hand off my work to an interested party with the hardware to test or have my work sponsored/co-maintained or whatever. I've had some severe hardware troubles while the last week (and the week before no own computer at all). However, I'm uploading ipw3945 modules package tomorrow evening. Great. For the daemon package, I'll offer to co-maintain it with you (for the next week, I do not have a ipw3945 notebook here because I lent it to someone else, but afterwards, it should have been come back then). I have no ipw3945 hardware to test, so my goal is that the existing packaging that I've worked on could be useful to someone with the hardware and willing to adopt. The package needs polish that I mostly cannot provide. The documented/suggested modprobe.d hack has proven to be unreliable, and I do not agree with an init script approach I've seen adopted by two other parties; so this udev based initialisation seems to be they way to go and will need some testing/tweaking. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304820: spcaview
Hi Le_Vert, I know it is a bit too late, but I thought I'd just let you know that spcaview has been prepared a long time ago at this location: http://svn.debian.org/wsvn/pkg-spca5xx/spcaview/ Maybe there are some things in there that could help improve your packaging of it. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339599: ITP: rt2570
Aurelien Jarno wrote: Looks like Aurelien either said yes silently or already had a package of his own. Either way rt2570 is in the NEW queue. It's seems one message never get out of my SMTP server. So yes, there is now a package in the NEW queue to support the rt2570 chip. It is however based on the rt2400/rt2500 packages so that I can easily maintain them by doing the same changes in all packages (if it applies). Thanks for following up on that, Aurelien. Otherwise I would have wasted time keeping my packaging in good shape. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339599: ITP: rt2570
Robert Chéramy wrote: Hi, it would be great to have the rt2570 module supported under debian. I used your package without big problems. The only thing I noticed is the kernel complaining in dmesg: rausb0 (WE) : Driver using old /proc/net/wireless support, please fix driver ! Perhaps Aurelien Jarno could help you regarding this package, as he already maintains rt2400 and rt2500. Aurelien, please say yes! ;-) Looks like Aurelien either said yes silently or already had a package of his own. Either way rt2570 is in the NEW queue. Kel.
Bug#354934: ITP: acerhk -- Acer Hotkey driver for Linux
Package: wnpp Severity: wishlist Owner: Kel Modderman [EMAIL PROTECTED] * Package name: acerhk Version : 0.5.32 Upstream Author : Olaf Tauber [EMAIL PROTECTED] * URL : http://www.informatik.hu-berlin.de/~tauber/acerhk/ * License : GPL Description : Acer Hotkey driver for Linux This driver will give access to the special keys on notebooks of the Acer Travelmate series, which are not handled by the keyboard driver. It also works on notebooks from other manufacturers (some Medion, Fujitsu-Siemens, ...). . It also has some other related functionality (depending on the model): - controlling LEDs (Mail, Wireless) - enable/disable wireless hardware . http://www.informatik.hu-berlin.de/~tauber/acerhk/ acerhk is i386 only. Current packages are available at the following location:- http://kanotix.com/files/debian/pool/main/a/acerhk/ Thanks, Kel. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (700, 'unstable'), (500, 'experimental'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-rc5-1 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300555: qc-usb-messenger debian package
Hi, I maintain the external module pool for the Kanotix project. qc-usb-messenger-source is one of them. If it can be used in Debian too, i would gladly help maintain this package based on what I have already developed. http://kanotix.com/files/debian/pool/main/q/qc-usb-messenger/ Note that i have changed the module name via a patch, this is because the module shares the same name with the original quickcam usb module. Beats me why . . . Thanks, Kel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333237: Kanotix package for adm8211
Jean-Marc Ranger wrote: Hi Kel, Due to a recently arrived ipw2200, I'm loosing some interest in continuing to package the adm8211 code for Debian. Are you interessed in taking the ownership of the ITP bug in Debian ? Jean-Marc The in-kernel wireless code is too turbulent right now, and adm8211 is specific to each new kernel version now also, so I am not sure it is really suitable for inclusion in the debian archive. Also, I do not own the hardware to test the driver personally. So, no I will not take sole ownership of this ITP. Having said that, there will always be an adm8211-source package available at the previously mentioned location that will try to remain compatible to the latest stable kernel version (from kernel.org), for any interested parties. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318022: Kanotix acerhk package
Hi, http://kanotix.com/files/debian/acerhk/ That package was made by your's truly for the Kanotix project. Although I am not officially involved with debian, I currently co-maintain some other module packages (spca5xx and madwifi) on alioth. If a developer would like to sponsor and co-maintain this in a similar fashion I'd be more than happy to help out. acer-acpi module may also be of interest. (for amd64 users) Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333237: Kanotix package for adm8211
Hi, Package for these drivers are here:- http://kanotix.com/files/debian/pool/main/a/adm8211/ I also track the experimental new version that depends on the common ieee80211 stack (=2.6.14) here:- ftp://debian.tu-bs.de/project/kanotix/experimental/pool/main/a/adm8211/ If you would like to use some of my efforts, I'd love to help out. Please contact me if you are interested. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339599: ITP: rt2570
Package: wnpp Severity: wishlist Hi, http://kanotix.com/files/debian/pool/main/r/rt2570/ Above are packages I developed as part of the Kanotix project. If there is any interest in them to be in debian (alongside the existing rt2400 rt2500 packages), feel free to contact me concerning these efforts. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333237: Kanotix package for adm8211
Jean-Marc Ranger wrote: Hi Kel, I'll definitely have a look at what you did. I'm fairly new at Debian packaging, so I sure can learn from what you did. My version of the 20050620 driver is available at http://web.ncf.ca/jmranger/adm8211/ if you're interessed to have a look. It was discussed on debian-mentors about a month ago - thread starts at http://lists.debian.org/debian-mentors/2005/10/msg00056.html - but no sponsor showed up, so package hasn't been integrated yet. A new upstream stable version is available at http://aluminum.sourmilk.net/adm8211/adm8211-20051031.tar.bz2 which I plan to package shortly. It'll probably depends on ieee80211-source, but I still have to figure out how it works when a module is both provided by the kernel and a separate package. I'd gladly accept hints on that if you have some available ! When that version is packaged, I'll restart searching for a sponsor. Stay tuned :) Jean-Marc Maybe you'd like to use alioth svn and work on this together? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304819: spca5xx debian package
Hi all, Stephen Birch wrote: Hi Guys Just to bring you all up to date. We have been using SVN on svn.debian.org to coordinate the package and will be maintaining it as a team using Alioth at: https://alioth.debian.org/projects/pkg-spca5xx/ If you wish you can check out the source from svn+alioth://svn.debian.org/svn/pkg-spca5xx/spca5xx/. Just remember Steve that svn+alioth is specific to the [tunnel] section of your own subversion config. Don't go to the alioth CVS archives, we will be deleting those, consider them obsolete. The package itself was uploaded to Debian on Saturday night by Otavio who helped review and polish the code, thanks Otavio. The biggest thankyou must go to Kel who did an absolutely first class job of creating this package in the first place. I am certain you will like what you see of his work. Thanks Kel Steve Otavio, I did some more thinking about the recent revamp of the rules, and i'd like to propose a small optimisation. diff -Nru spca5xx-20050906.1-current/debian/changelog spca5xx-20050906.1-new/debian/changelog --- spca5xx-20050906.1-current/debian/changelog2005-09-25 20:20:56.0 +1000 +++ spca5xx-20050906.1-new/debian/changelog2005-09-25 20:20:18.0 +1000 @@ -1,3 +1,11 @@ +spca5xx (20050906.1-2) UNRELEASED; urgency=low + + [Kel Modderman] + * Move staging area for module source from current dir to +debian/tmp and remove clean target rule in debian/rules. + + -- Kel Modderman [EMAIL PROTECTED] Sun, 25 Sep 2005 20:07:24 +1000 + spca5xx (20050906.1-1) unstable; urgency=low * Initial release from the Debian spca5xx Maintainers based diff -Nru spca5xx-20050906.1-current/debian/rules spca5xx-20050906.1-new/debian/rules --- spca5xx-20050906.1-current/debian/rules2005-09-25 20:20:56.0 +1000 +++ spca5xx-20050906.1-new/debian/rules2005-09-25 20:20:18.0 +1000 @@ -8,22 +8,19 @@ install/spca5xx-source:: # Enforce executable bit on debian/rules, and create directory structure for # modules source -install -D -m 0755 debian/rules.modules modules/spca5xx/debian/rules +install -D -m 0755 debian/rules.modules debian/tmp/modules/spca5xx/debian/rules # Prepare the other debian stuff for f in debian/*.modules.in debian/control debian/compat \ debian/copyright debian/changelog; do \ -install -m 0644 $$f modules/spca5xx/debian/; \ +install -m 0644 $$f debian/tmp/modules/spca5xx/debian/; \ done # Prepare upstream source find . -path ./debian/\* -type d -prune -o -printf %P\n | \ egrep -v 'debian' | \ -cpio -admp modules/spca5xx/ +cpio -admp debian/tmp/modules/spca5xx/ # Prepare the debian source tarball -tar jcf debian/spca5xx-source/usr/src/spca5xx-source.tar.bz2 modules -rm -rf modules - -clean:: -rm -rf modules +cd debian/tmp/ \ +tar jcf ../spca5xx-source/usr/src/spca5xx-source.tar.bz2 modules It would make me more comfortable if the module source tarball was assembled out of $(CURDIR), where upstream exists. I propose we stage the tarball in debian/tmp. Its more portable to apply to the numerous modules packages I maintain for Kanotix and does not allow the oppurtunity to remove upstream files in modules existed in it (of course you would be stupid not to check first). This of course not a critical change and i doubt we'll be releasing another revision until new upstream source is available, but I'd like to hear some opinions before I commit this patch to svn. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304819: spca5xx debian package
Hey Otavio, Otavio Salvador wrote: Kel Modderman [EMAIL PROTECTED] writes: Otavio, I did some more thinking about the recent revamp of the rules, and i'd like to propose a small optimisation. I agree with all this patch. Only one optimisation: you don't need to use clean target since cdbs already clean all contents of debian/tmp/ and debian/binaries. So it'll work without your new clean:: target. Do a test and commit :-D Thanks a lot. Clean target was also removed (if not in my patch, i meant it also to be removed). Will do it soon. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304819: spca5xx debian package
Hi, By the time I saw this, there were a volley of replies to this first attempt at contact. Stephen Birch wrote: Hi Kel and Itay One of the packages I have been planning for Debian is the spca5xx package for which I filed a ITP some time back. Since I believed my NM application was shortly to be completed I decided to not use my normal sponsor for this package preferring to wait until I could do my own uploads. Here is the ITP and associated comments: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304819 To my dismay the NM process is still not complete, the AM just has too much work on his plate to complete the application. Heh, i saw the comment on the spca5xx download page too ; ) (Waiting . . . Waiting . . . ) Recently several people have talked to me about using my sponsor for the spca5xx package and not keep waiting for the NM queue. Okay .. so I am now moving on this and want to get the package in Debian ASAP. Rechecking the ITP I noticed that Itay Ben-Yaacov pointed out that you guys both have a package already complete. There is no point in reinventing the wheel so Id like to use your work. Cool, How can I be of service? I plan on dropping the changelog (if that is ok) entries but, of course, give full credit in the README. I am writing to make sure you are okay with this direction and to make sure you are happy with the approach. Sounds like a crap idea to me. I don't care whether my particular package has never had contact with the official debian distribution before. I've tried my best to improve on my package with each release and adhere to the strict debian policies in part of the effort to make Kanotix 100% debian. Even if a package does not come from the official debian repositories, its up to Stefan and I to make sure it is of debian standard in every way. Having said that, should our efforts not be documented as if this was going to be released into debian itself? If you guys want to help with this (or even co-maintain) I'll put the package online for your review before uploading to my sponsor. Since you guys have already done the hard work it should be up quite soon. Steve Sure, make an Alioth account, I'd love to share the experience of maintaining a quality package with other people who share the same enjoyment and freedom that debian gives them. Well, I made a few small updates in the past hour to my package to make it more suitable to enter debian and am confident that my work is of high enough quality to make it trivial to add the finishing touches (depending on your packaginging style perhaps). That is not assuming anything about the work of the other gentlemen in this equation, Itay, who seems to have been made uncomfortable by previous dealings with prospective DD(s). Likewise, I have been introduced into the world of debian development in a sour way. The pkg-madwifi project on Alioth is based on my efforts and I did not even have the opportunity of being able to reply to the wannabe maintainers request to snatch my efforts, so for sending this message to me is appreciated. (Even now I do not have write access to that svn repository) Anyway, to cut the story short, I don't want to have another bad experience, so just put the project into svn on Alioth. Let everybody look at it, propose some items that could be improved or worked on and discuss what actually needs to be done and by who. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
