libX11 bug
Hi all, I have a problem and I guess it's a bug. I can't play anymore with zsnes since the last apt-get upgrade (5 hours ago I think). I have the following error (traced with gcc) : 0xb7abed57 in XLookupString () from /usr/X11R6/lib/libX11.so.6 (gdb) where #0 0xb7abed57 in XLookupString () from /usr/X11R6/lib/libX11.so.6 #1 0xb7e6fbf7 in X11_TranslateKey () from /usr/lib/libSDL-1.2.so.0 #2 0xb7e701c3 in X11_SetKeyboardState () from /usr/lib/libSDL-1.2.so.0 #3 0xb7e706d9 in X11_PumpEvents () from /usr/lib/libSDL-1.2.so.0 #4 0xb7e89305 in SDL_PumpEvents () from /usr/lib/libSDL-1.2.so.0 #5 0xb7e89347 in SDL_PollEvent () from /usr/lib/libSDL-1.2.so.0 #6 0xb7e89518 in SDL_EventState () from /usr/lib/libSDL-1.2.so.0 #7 0xb7e8bf10 in SDL_JoystickEventState () from /usr/lib/libSDL-1.2.so.0 #8 0x080d7caa in ?? () #9 0x0001 in ?? () #10 0x0001 in ?? () #11 0x0013 in ?? () #12 0xb7c67480 in _IO_list_all () from /lib/tls/libc.so.6 But i don't remember what packages I've upgraded :( Thx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354560: ITP: iaxmodem -- software modem with IAX2 connectivity
Package: wnpp Severity: wishlist Owner: Julien BLACHE [EMAIL PROTECTED] * Package name: iaxmodem Version : 0.0.13 Upstream Author : Lee Howard [EMAIL PROTECTED] * URL : http://iaxmodem.sf.net * License : GPL Description : software modem with IAX2 connectivity IAXmodem is a software modem written in C that uses an IAX channel (commonly provided by an Asterisk PBX system) instead of a traditional phone line and uses a DSP library instead of DSP hardware chipsets. . IAXmodem was originally conceived to function as a fax modem usable with HylaFAX, and it does that well. However IAXmodem also has been known to function with mgetty+sendfax and efax. Note that iaxmodem includes modified versions of libiax2 and spandsp, both libraries being GPL-licensed and statically linked into the iaxmodem binary. The packaged version of the libraries cannot be used, either because they're not current enough (as in CVS HEAD 2 hours ago) or because of the modifications applied for iaxmodem. I am currently finishing up the packaging and feeding my patches to make iaxmodem a daemon upstream. JB. -- System Information: Debian Release: testing/unstable Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 08:51:16AM -0800, Jurij Smakov wrote: On Fri, 24 Feb 2006, Bastian Blank wrote: On Fri, Feb 24, 2006 at 04:54:24PM +0100, Julien Danjou wrote: As far as I understand, you will just maintain Xen kernel images. (for dom0 only ?). No. The kernel team will maintain xen (in variants 3.0 and unstable). Bastian, as far as I know, you are the *only* person on the kernel team interested in maintaining xen (at least I haven't heard others talking about it). I imagine that it is fairly complicated package, and there is already a whole team of people dedicated to packaging it. Definitely, it would be more productive to just include xen kernel images into linux-2.6 and play nicely with the xen team to make sure that it runs smoothly. Telling them to take a hike at this point just because you are on the kernel team appears a lot like hijacking of the xen package to me. The kernel patches for XEN should be maintained inside the kernel team and in linux-2.6, they are free to join the kernel team to handle this, but it is unacceptable to have some kind of external patch to the kernel floating around, and having no cooperation between the XEN team and the kernel team will kind of encourage people to build their own xen kernel from mainline upstream sources, which i believe is not what we want. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: multixterm -- drive multiple xterms separately or together
Am 2006-02-21 18:10:39, schrieb gregor herrmann: Thanks for your hint, I didn't know clusterssh. Just checked it out and it does pretty much the same (and has more options), so I close the ITP for multixterm hereby. As I understand the description of clusterssh right, it open xterms with SSH sessions not plain xterm. If I have no sshd running on the local machine, clusterssh won't work. BTW, the KDE konsole can also feed keypresses into multiple terminals. This is what I use. For those who like to install kde(-libs) ;-) ACK! Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-18 13:42:38, schrieb Robert Millan: On Sat, Feb 18, 2006 at 12:49:48PM +0100, Wouter Verhelst wrote: Does the lack of a free driver which can be used with ndiswrapper mean that it is impossible to use ndiswrapper with such a free driver, should one eventually be written? If a free driver/datafile/whatever existed, it would be possible to run Foo without requiring non-free stuff, therefore it belongs to main If someone use only main she/he will never install ndiswraper and will not code a free version. Let ndiswraper stay in main will animate developers to code stuff. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Am 2006-02-18 13:58:20, schrieb Jérôme Marant: Robert Millan [EMAIL PROTECTED] writes: Is your point that contrib should therefore be empty and has no reason for existance? If not, please explain me the difference between ndiswrapper and all the other packages that belong to contrib and already are in. Contrib is for free packages that have a real Depends: or Recommends: dependency on a non-free package. If there isn't any reason for ndiswrapper to depends on a non-free package, then there is no reason to move it to contrib. Right, and because it DOES NOT depends on non-free it should stay in main. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 11:13:19, schrieb Daniel Stone: On Sat, Feb 18, 2006 at 06:12:36PM +0200, Lars Wirzenius wrote: la, 2006-02-18 kello 10:43 -0500, Michael Poole kirjoitti: What's the purpose of an assembler without assembly code to use it on? It can be used, for example, to assemble code you write yourself. That is, after all, the primary purpose of programming tools: to help programmers develop programs. Surely ndiswrapper can also run drivers you write yourself. Right and most people will not write a driver, IF ndiswraper is not in main. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 02:11:30, schrieb Peter Samuelson: No, the point of Java is to allow users to run Java software, which they may or may not have written themselves, and which may or may not be free software. Examples of all permutations of the above are really ndiswraper is to allow users to write drivers, which they may or may not have written themselves and which may or may not be free software. So, -- what now? If you give peoples not the chance to do it, OSS has allready lost. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 08:40:44, schrieb Michael Poole: Again, there is no mention of pointless software in Policy -- if there were, some large fraction of main would be moved because it is duplicative, trivial or otherwise pointless to have. Likewise, there is no mention of Windows driver developers ... who really wish they could conveniently test their Windows drivers on Debian. Policy only says the packages in main must not require a package outside of main for compilation or execution. This mean, IF I HAVE written a driver, it will not go into main even if IS GPLed because ndiswraper is in contrib. In clear: Such driver will never be written. Michael Poole Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 00:44:29, schrieb Josselin Mouette: I wonder why all people go on trying to build up tons of different fallacious reasonings to keep firmwares in main. Non-free is here for a reason, we just have to use it. Technical solutions to have the driver in the kernel or in contrib, and the firmware in non-free, exist. If I have a hardware which comes with a CD/DVD/Floppy with the firmware and there is a free firmware loader but it must stay in contrib it will not realy productiv. It is a big disavantage. I think, programs and packages which help to use firmware and drivers for hardware, where the firmware and drivers can be obtained from the ORIGINAL media shiped with the hardware should stay in main because Debian has nothing to do with shiping of firmware and drivers. It is generaly the responsability of the hardware manufacturers. In general: 1) Debian should provide FREE (GPLed) wraper and firmware (userspace) loader. 2) drop non-free because it stress Debian. Oh yes, I read often that $USER glame the Linux-Community not to ship Drivers!!! - Arghhh!!! I know tonns of Hwardware, where I have NO drivers or software in Winblow and I need the, from the hardware manufactirer provided DriverCD. - So why should Debian care about firmware and drivers? We can provide wraper and loaders and thats is. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 01:52:05, schrieb Marco d'Itri: On Feb 19, Josselin Mouette [EMAIL PROTECTED] wrote: I wonder why all people go on trying to build up tons of different fallacious reasonings to keep firmwares in main. Because it's good for Debian and is good for our users. Sorry Marco, but even under Windows, there are many Drivers missing for Hardware. You need the from the hardware manufacturers DriverCD. Why should Debian care about it? If you like to see $USER using Hardware, you know they have the DriverCD and you can create a wraper or loader for the hardware. I have done this for two enterprises here in Strasbourg and I use cabextract to get the Firmwares out of the Windows-installer. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Hi Thomas, Am 2006-02-18 17:18:37, schrieb Thomas Bushnell BSG: Regardless, we already have a commitment: to remove non-DFSG bits from the main archive. What dou you think about the idea, that because non-free drivers and firmwares are droped from main we write wrapers and loaders which GET the drivrs and firmwares from the manufacturer provided DriverCD's. I have allready done this for two Enterprises here in Strasbourg using cabextract or unzip to get the stuff... I have done this wit an experimental win32codec-graber whichget the windows codecs from the original Win95, Win98, Win2000 and WinXP CD's. This will solv all problems distributing non-free stuff because $USER which want to use non-free stuf must provide a legal licence to use it which is generaly fullfiled if you have the Win-CD's. Just an Idea. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 08:46:16, schrieb Josselin Mouette: Please stop these lies. I repeat: technical solutions do exist. For hardware unnecessary at installation's first stage, it is only a matter of making non-free available. ACK! For hardware necessary for the first stage, it would be possible to make the installer load udebs from alternate sources, but the people who'd be interested in it are spreading lies on debian-devel instead of working on the code. FullACK! If $USER have such hardware, they have the DriverCD or other media provided by the manufacturers and I think, Debian should only provide FREE wrapers and loaders to get the things running. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-19 08:46:42, schrieb Michael Poole: Exactly what is the technical solution for installing drivers for firmware-requiring hardware if you only have Debian proper (i.e. main) available? That is the situation I described, and I really do not see any technical solution for it, no matter how much you call it a lie. This is, WHY ndiswraper should be in main and NOT contrib. ndiswraper is GPLed and if the $USER can provide a DriverCD she/he should be able to load firmware and drivers into Debian. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Hello Peter, Am 2006-02-19 01:51:31, schrieb Peter Samuelson: Good, then we can stop talking about including it in main. We don't ship hardware, so if firmware is part of the hardware, we don't need to ship it either. If it's part of the hardware, then it is the hardware vendor's responsibility, not Debian's, to make sure it is available. (It might be nice, for the convenience of the hardware vendors, to produce some sort of specification for CD layouts and metadata so that they can provide firmware to their customers in a way that's easy to use with Debian.) :-) FullACK! And if some Developers oand/or Maintaines have spare time or the need for such hardware, they can do the Job too. I think, this would be the best idea. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-21 15:36:16, schrieb Anthony Towns: That's a mistaken view; the purpose of contrib is to give us a place to ship free software that we can't ship in Debian proper (ie, main) because it would violate We will never make the system require the use of a non-free component or, historically, ... we will never make the system depend on an item of non-free software. I have read the social contract, developers-reference and much more documentation to Debian and for me it is clear: ndiswraper does NOT depend on non-free software because Debian support the creation of FREE software. So ndiswraper should be in main to give developers the ability to code such stuff. Pushing ndiswraper into contrib prevent such evolution. ndiswrapper doesn't depend (in a control file sense) on stuff in non-free, The Depends: field isn't really that relevant. Right, because ndiswraper can run at any time a FREE driver which can be written IF many peoples are naoyed about the Win-NDIS and begin to code one... And ndiswraper should not be in contrib because it CAN BE USED to load non-free Win-NDIS driver in Debian. Cheers, aj Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am 2006-02-20 23:38:53, schrieb Adam McKenna: Practically, it's to avoid shipping things on our CDs that depend on stuff that's not on our CDs. In this case, even in the absence of free NDIS Right, I do not like the Idea, to ship a coupe of CD's with Firmware and drivers in Debian. Insteed we should only provide Wrapers and loaders to get the things from the manufacturers provided DriverCD's What is relevant is that ndiswrapper technically meets all requirements for inclusion into main. Did I miss a solid argument refuting that assertion? I think not. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: debian/control file to include new License: field
Hello Jari, AFAIK is this already done with debtags. Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PROPOSAL: debian/control file to include new License: field
Am 2006-02-21 02:45:12, schrieb Kevin Mark: Hi, would it provide any automation or easier processing for the NEW queue(ftpmasters)? would it allow for reducing package size by removing license text from all packages and having them installed in a seperate essential package stored in a canonical location (/usr/share/doc/dfsg-license-texts/) (dfsg-license-texts.deb) and have a file-license.txt to list which files are licensed under which license? We have allready sich directory in /usr/share/common-licences/ and if you use pbuilder it complains about include Full-Text licences (my Experience with my OWN packages). Greetings Michelle Konzack Systemadministrator -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Sat, Feb 25, 2006 at 08:39:13AM +0100, Guido Trotter wrote: On Fri, Feb 24, 2006 at 05:40:04PM -0800, Steve Langasek wrote: Hi, FWIW, the policy on kernel patches for sarge was that if it didn't apply to the kernel sources we shipped, it didn't need to be included as a package in stable. We're obviously not shipping a 2.6.12 kernel for etch, so I wouldn't bother uploading that part... And if they do they can probably be integrated anyway! Ok then, we can probably withraw the patch! Even though that can make things a bit harder for those not running debian kernels since xen is not yet integrated in there... I guess that if people are able to find a kernel source tree outside of debian, they are perfectly capable of downloading and applying a patch too. Just include an URL to wherever such a patch is in the README.Debian of the packages, should be enough. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Mon, Feb 27, 2006 at 01:51:51PM +0100, Sven Luther wrote: Hi, The kernel patches for XEN should be maintained inside the kernel team and in linux-2.6, they are free to join the kernel team to handle this, but it is unacceptable to have some kind of external patch to the kernel floating around, and having no cooperation between the XEN team and the kernel team will kind of encourage people to build their own xen kernel from mainline upstream sources, which i believe is not what we want. Absolutely true! The current xen team is fully agrees on this position! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 25, 2006 at 05:01:25PM +0100, Michelle Konzack wrote: If I have a hardware which comes with a CD/DVD/Floppy with the firmware and there is a free firmware loader but it must stay in contrib it will not realy productiv. It is a big disavantage. Why? I've been using Debian for quite some time but I've never checked that the package I'm about to install is coming from main or from contrib. Yes, I understand that there are technical/legal reasons for putting packages in contrib instead of main, but with my dumb user hat on, I simply _do not care_. I simply can not understand why you all are making such a big fuss about ndiswrapper being in contrib or in main. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: multixterm -- drive multiple xterms separately or together
On Sat, Feb 25, 2006 at 11:10:03AM +0100, Michelle Konzack wrote: Thanks for your hint, I didn't know clusterssh. Just checked it out and it does pretty much the same (and has more options), so I close the ITP for multixterm hereby. As I understand the description of clusterssh right, it open xterms with SSH sessions not plain xterm. If I have no sshd running on the local machine, clusterssh won't work. Taking a second look at both tools, I think you are right: clusterssh opens xterms with ssh sessions, multixterm opens multiple xterms (with whatever contents). So if you want to control several xterms at the same time that are not ssh sessions multixterm can handle this but clusterssh can't. If you would like to try multixterm the packages are still available at deb-src http://www.toastfreeware.priv.at/debian unstable/ or http://www.toastfreeware.priv.at/debian/unstable/ Greetings, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : infos zur usenet-hierarchie at.*: http://www.usenet.at/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-NP: Bob Dylan: Million Miles signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
* Michelle Konzack [EMAIL PROTECTED] [2006-02-27 14:21]: ndiswraper is to allow users to write drivers, which they may or may not have written themselves and which may or may not be free software. Wrong, its purpose ist to let them run these drivers. yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System yath lol, mein feuermelder ist dausicher yath im batteriefach unter der batterie steht yath WARNUNG: BATTERIE ENTFERNT -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
pe, 2006-02-24 kello 18:27 -0300, Gustavo Franco kirjoitti: What i thought in a first look to the Lars' list. I think that the best thing would include piuparts as a infrastructural test (oficially as a part of our archive code), or due to restrict admin time to do that, opt for something like piuparts.debian.org as we have lintian.d.o. Do you mean that the archive should automatically reject uploads that don't pass a piuparts check? I think that sounds like a nice idea, but we're not yet in a situation where it is feasible. For example, the reason piuparts testing fails may be due to a bug in an unrelated package. This needs to be dealt with manually, and that requires quite a bit of effort. For the time being, at least, I think it is better for Debian to let uploads run smoothly, and do piuparts testing separately. If we are to start doing checks on packages before accepting uploads, I think it would be best to start with some subset of lintian and linda errors. Lintian and linda are faster to run, anyway, and less risky, and less likely to hang. I would be glad to help with a web interface to show the piuparts html results in a organized way Something like piuparts-report.py? Anyway, I think it is more productive if package maintainers run piuparts themselves, and then people running piuparts centrally reporting bugs. The lintian.debian.org experience seems to be that having lots of info on the web is nice, but filing bug reports actually gets things fixed. As it happens, however, there is work going on in getting a centralized machine to run piuparts testing, and that machine will be used to publish logs and statistics. I haven't done that so far because the logs are big, and I don't have gigabytes of disk space and bandwidth to spend on them. Since Lars already did the check (for i386 only, i think), I haven't tested the entire i386, either, only about half or so. The rest is waiting for their dependencies to be fixed, or for something to happen with regards to circular dependencies (which at the moment are likely to make piuparts testing fail). -- Boilerplate programming mean tools lack power. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
Lars Wirzenius [EMAIL PROTECTED] writes: pe, 2006-02-24 kello 18:27 -0300, Gustavo Franco kirjoitti: I would be glad to help with a web interface to show the piuparts html results in a organized way Something like piuparts-report.py? Anyway, I think it is more productive if package maintainers run piuparts themselves, and then people running piuparts centrally reporting bugs. The lintian.debian.org experience seems to be that having lots of info on the web is nice, but filing bug reports actually gets things fixed. As it happens, however, there is work going on in getting a centralized machine to run piuparts testing, and that machine will be used to publish logs and statistics. I haven't done that so far because the logs are big, and I don't have gigabytes of disk space and bandwidth to spend on them. I think it would be best for the buildd to run this and append the result to the buildd log. Errors will be different on some archs and buildd admins can sometimes catch serious issues before signing the package. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/lib/modules/kernelversion/volatile on tmpfs
I have this directory on an Ubuntu system and it seems to be present on recent Debian systems too... It is on tmpfs. Can anybody tell me what is its purpose (as many other distros don't have it) and when it gets mounted? Thanks! Sergio -- Dr. Sergio Callegari Via Fontanelle 40 Researcher 47100 Forlì II School of Engineering Tel. +39.0543.786927 University of BolognaFax. +39.0543.786926 Affiliated with: DEIS - Dept. of Electronics, Computer Sciences and Systems, University of Bologna (www.deis.unibo.it) ARCES - Advanced Research Center on Electronic Systems for Information and Communication Technologies Unversity of Bologna (www.arces.unibo.it) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
ma, 2006-02-27 kello 18:39 +0100, Goswin von Brederlow kirjoitti: I think it would be best for the buildd to run this and append the result to the buildd log. I don't, because, as I said, piuparts tests often fail for reasons completely unrelated to the package itself, and there is no point in preventing an upload from happening. Also, it would put more burden on buildd maintainers and it's important to remove bottlenecks, not increase them. -- On a clear disk, you seek forever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
On Mon, 2006-02-27 at 18:40 +0200, Lars Wirzenius wrote: If we are to start doing checks on packages before accepting uploads, I think it would be best to start with some subset of lintian and linda errors. Since these tools can already differentiate between errors and warnings, it would make sense to define the subset for rejection as all errors. Thijs signature.asc Description: This is a digitally signed message part
Re: Problems found by piuparts
Thijs Kinkhorst wrote: On Mon, 2006-02-27 at 18:40 +0200, Lars Wirzenius wrote: If we are to start doing checks on packages before accepting uploads, I think it would be best to start with some subset of lintian and linda errors. Note that individual maintainers can already configure dput to stop the upload on lintian/linda errors. You can also add hooks to that end to pbuilder. Since these tools can already differentiate between errors and warnings, it would make sense to define the subset for rejection as all errors. I'm afraid I have to disagree here. An old FSF address doesn't warrant a reject. Neither do false positives in lintian, they do happen (e.g. the last C++ transition would have been impeded, in fact l.d.o still shows lintian errors for libfoo0c2a). Effectively, this would only foster an increase in questionable overrides. Lintian is a useful tool, but it's results need to be subject to review before filing bugs or doing rejects. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Mon, Feb 27, 2006 at 03:33:51PM +0100, Gabor Gombas wrote: I simply can not understand why you all are making such a big fuss about ndiswrapper being in contrib or in main. Taking it out of main moves us in the wrong direction if our goal is to give our users a *usable* operating system, as opposed to some kind of 'proof of concept' OS that some people here seem to want to create, but that the majority of our users will not want to use. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michelle Konzack [EMAIL PROTECTED] writes: If someone use only main she/he will never install ndiswraper and will not code a free version. Let ndiswraper stay in main will animate developers to code stuff. My understanding is that it is currently in main, right? How many people have been animated to write free code for it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: Taking it out of main moves us in the wrong direction if our goal is to give our users a *usable* operating system, as opposed to some kind of 'proof of concept' OS that some people here seem to want to create, but that the majority of our users will not want to use. How does putting ndiswrapper in contrib make Debian less usable? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michelle Konzack [EMAIL PROTECTED] writes: What dou you think about the idea, that because non-free drivers and firmwares are droped from main we write wrapers and loaders which GET the drivrs and firmwares from the manufacturer provided DriverCD's. This is a very suboptimal solution. Such wrappers are necessarily in contrib, and are a second-best approach. Better we spend our time actually supporting the hardware with free software. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 10:33:47AM -0800, Thomas Bushnell BSG wrote: Adam McKenna [EMAIL PROTECTED] writes: Taking it out of main moves us in the wrong direction if our goal is to give our users a *usable* operating system, as opposed to some kind of 'proof of concept' OS that some people here seem to want to create, but that the majority of our users will not want to use. How does putting ndiswrapper in contrib make Debian less usable? Do you actually read entire threads for context when you reply, or do you just pick particular posts to nitpick and needle people over? Don't answer that, it's rhetorical. As I said earlier, it prevents us from integrating ndiswrapper-supported devices into the installer so that users can enable their wireless devices during install. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /lib/modules/kernelversion/volatile on tmpfs
On Mon, 27 Feb 2006, Sergio Callegari wrote: I have this directory on an Ubuntu system and it seems to be present on recent Debian systems too... I have never seen that in a Debian system. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: As I said earlier, it prevents us from integrating ndiswrapper-supported devices into the installer so that users can enable their wireless devices during install. I'm afraid I don't see how this works out. Why can't you integrate such things into the installer? What is the technical difficulty here? It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I am using GPG and am still learning.
I revoked a key, but need to use this key again, is that possible, as I was sent a new key but can not seem to get this key imported and in the key ring. Please help me? Ron Kirchner Software Developer Acxiom Corporation Conway, Arkansas 72033 Bldg 9 - 3rd Floor (Office #3125) Ron.Kirchner@Acxiom.com Work Phone# 501-342-0078 Cell Phone #501-514-4953 Fax # 501-342-3516 smime.p7s Description: S/MIME cryptographic signature * The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. *
Re: Bug#353277: ndiswrapper in main
On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Better we spend our time actually supporting the hardware with free software. There is almost none. At most you can choose if you want to get your proprietary firmware on board or not. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 08:41:29PM +0100, Marco d'Itri wrote: On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Better we spend our time actually supporting the hardware with free software. There is almost none. At most you can choose if you want to get your proprietary firmware on board or not. Not only that, there are obviously other considerations when buying a laptop than whether the wireless card has free drivers or not. Things such as price, combination of features, etc. Our users shouldn't be forced to buy a GNU anointed laptop (if such a thing even exists) in order to get support for their devices. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFA: all packages (except already co-maintained ones)
Hi This is a fairly generic request, but Im looking for Co-Maintainers for all my packages that don't already have one. You can find the list of my packages at http://qa.debian.org/[EMAIL PROTECTED] If you are interested in helping with one of those - mail me *off-list* and we discuss the way it goes on. You should know how to handle a Debian package, I dont have the time[1] to explain the basics. Oh: You dont need to be a DD. Would help, but not really neccessary. [1] Guess why I ask for help? :) -- bye Joerg ribnitz Ganneff: NM-queue ist das schnellste zu uploadrechten für ein paket, oder? youam ach aqua^Wribnitz pgpJQmfIvS3uV.pgp Description: PGP signature
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
[EMAIL PROTECTED] (Marco d'Itri) writes: On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Better we spend our time actually supporting the hardware with free software. There is almost none. At most you can choose if you want to get your proprietary firmware on board or not. The supposition was about people who wanted to use ndiswrapper to write free drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 08:41:29PM +0100, Marco d'Itri wrote: On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Better we spend our time actually supporting the hardware with free software. There is almost none. At most you can choose if you want to get your proprietary firmware on board or not. Not only that, there are obviously other considerations when buying a laptop than whether the wireless card has free drivers or not. Things such as price, combination of features, etc. Our users shouldn't be forced to buy a GNU anointed laptop (if such a thing even exists) in order to get support for their devices. Please keep track of the threads. Marco pruned crucial context. Nobody is talking about forcing people to buy anything. The current criteria for contrib do not make reference to technical convenience as a factor. Perhaps this is a mistake, in which case it should be corrected. I'm still unable to see how the classification of ndiswrapper in contrib somehow causes a major technical inconvenience. It can, for example, be put on the first CD. I certainly do not think that the installer should be limited to software in main (and perhaps not even software in main+contrib, provided it still works correctly without non-free things around). Is that the root issue? Are there people who insist that the installer should be limited to things in main? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 12:49:59PM -0800, Thomas Bushnell BSG wrote: Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Because ndiswrapper belongs in main. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 12:49:59PM -0800, Thomas Bushnell BSG wrote: Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Because ndiswrapper belongs in main. So I said why not put it in contrib and you said because then it can't be used by the installer. Now you are saying that even if this wasn't a problem, it still shouldn't be in contrib. Why? I'm flabbergasted that it matters at all. What does it matter? If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? People wrongly arguing to move packages from main to contrib. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: So I said why not put it in contrib and you said because then it can't be used by the installer. Now you are saying that even if this wasn't a problem, it still shouldn't be in contrib. Why? I'm flabbergasted that it matters at all. What does it matter? If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? It has been argued in this thread that if ndiswrapper were put in main, it would mean that contrib has no point at all. One could equally well argue that if ndiswrapper were put in contrib, main would have no point at all. There are benefits to users for putting software into the innermost category for which it qualifies; consciously putting a package in contrib when it could go into main raises questions of *why* it was put in contrib -- and which other packages might get the same treatment. If putting it in contrib were simply an accident, then that bug could just be fixed with no policy implications. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
[EMAIL PROTECTED] (Marco d'Itri) writes: On Feb 27, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? People wrongly arguing to move packages from main to contrib. And what bad things happen if a package is miscategorized? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michael Poole [EMAIL PROTECTED] writes: It has been argued in this thread that if ndiswrapper were put in main, it would mean that contrib has no point at all. One could equally well argue that if ndiswrapper were put in contrib, main would have no point at all. I'm afraid that's not an answer to my question. There are benefits to users for putting software into the innermost category for which it qualifies; consciously putting a package in contrib when it could go into main raises questions of *why* it was put in contrib -- and which other packages might get the same treatment. If putting it in contrib were simply an accident, then that bug could just be fixed with no policy implications. You are suggesting that there is some mistreatment in putting a package in the wrong category. As in might get the same treatment. Is the idea that you somehow wound the ego of a package by putting it in contrib? That surely isn't right, of course. But I'm stuck for wondering. If a package is wrongly put in lib when it belongs in libdevel, for example, or vice versa, there is no huge flame war, nothing bad happens, we just carry on. Such a state could continue for years without anybody getting upset or much caring. I just *assume* that errors in categorization will be made. That doesn't mean errors are good, of course. But my question is: what *harm* does this particular error (if it is an error) cause? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 01:14:54PM -0800, Thomas Bushnell BSG wrote: So I said why not put it in contrib and you said because then it can't be used by the installer. Now you are saying that even if this wasn't a problem, it still shouldn't be in contrib. Correct. Why? I'm flabbergasted that it matters at all. What does it matter? If it were put in contrib (by accident, say), how would this cause a problem, assuming that the installer problem was fixed? What specific problems are you concerned about? The question is not what problems it would cause. The problems are side effects. It should stay in main because it is free software that is able to be used by at least some subset of our users, without any non-free software. In addition, there are other potential issues with having it in contrib, one of which is inaccessibility to the installer. The overall effect is decreased utility for our users. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: The question is not what problems it would cause. The problems are side effects. It should stay in main because it is free software that is able to be used by at least some subset of our users, without any non-free software. Ok, this seems to be a simple factual question, and I have been unable to see the answer despite careful reading of the thread and the bug log. What is the subset of our users which would find ndiswrapper useful, without the use of free software? I have heard some say that there are no free drivers around for ndiswrapper to wrap. If that's true, then wouldn't that make the subset in question the empty set? Or is there some use to ndiswrapper without a driver to wrap with it? Or, perhaps it's not true that there are no free drivers for it. The claim was also made that there was a single free driver out there for use with ndiswrapper, but others claimed that the hardware in question is already supported, and better, without the use of that driver. I don't know whether this is true, but if it is true, I would appreciate hearing why that should be treated differently than there being no such free driver at all. (BTW: I have no problem saying that a thing is in contrib while it can support only non-free software, and as soon as a realistic case of it supporting free software comes along, it moves into main. Some people seemed to have been assuming in this thread that this is a ludicrous possibility, but it seems perfectly natural to me.) In addition, there are other potential issues with having it in contrib, one of which is inaccessibility to the installer. The overall effect is decreased utility for our users. Once again, this is not a real issue. This is a bug in the installer, and not a categorization mistake. If the installer is fixed, there is no decreased utility of this sort for putting the package in contrib. So let's pretend that the installer bug has been fixed. Moreover, the standards for contrib do not (at present) make any reference to utility or convenience. Perhaps this should be changed, but I'm assuming that we keep the standards alone. (I make this presumption only because the argument seems to be that ndiswrapper belongs in main under the *current* standards, and not some hypothetical improved standards.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mirror split, amd64 update
Philip Charles [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I have built up a fine-grained mirroring script over time which not only selects the architecture but also the version (stable, testing etc) to be mirrored. Unfortunately this script will require ftp/http access to ../debian-all. Is there any reason to restrict access to ../debian-all to rsync? It looks like nobody else responded to your message, so I will. (IANADD) Allowing http or ftp access to ftp.debian.org/debian-all is somewhat dangerous. Anybody blindly mirroring ALL of ftp.debian.org via http or ftp would end up with two copies of the major architectures. However, doing that is a stupid thing anyway, and Debian has no obligation to protect fools who do that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Using /cdrom/.disk/udeb_(in|ex)clude to load custom udebs instead of d-i's?
Hi guys, I'm playing with the latest debian-testing-i386-businesscard.iso. One of the things I want to do is automate the network configuration process in an environment where DHCP is not an option. Actually, what I want is for the debian installer to look up the network settings according to the hardware addresses it finds. So what I've done is I've created my own netcfg udeb package, which I've named tiem.netcfg, that provides configured-network. On the iso image, I've created a .disk/ directory and placed within the file udeb_exclude, which contains the single line: netcfg And the file udeb_include, which contains the single line: tiem.netcfg If I understand available-hooks.txt right, this should tell the debian installer to load my tiem.netcfg udeb instead of the debian installer's netcfg, but it doesn't. It loads netcfg anyway. As the installer runs and d-i's netconfig sits there waiting for me to type in an address I can switch to another terminal and load my udebs by hand using udpkg, and my udebs work, they're just not being loaded *instead of* the default udeb. Anyone have an idea what I've done wrong? Thanks in advance, Michael Peek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: Michael Poole [EMAIL PROTECTED] writes: It has been argued in this thread that if ndiswrapper were put in main, it would mean that contrib has no point at all. One could equally well argue that if ndiswrapper were put in contrib, main would have no point at all. I'm afraid that's not an answer to my question. It wasn't intended to be an answer to your question, just a reminder that actions have consequences. There are benefits to users for putting software into the innermost category for which it qualifies; consciously putting a package in contrib when it could go into main raises questions of *why* it was put in contrib -- and which other packages might get the same treatment. If putting it in contrib were simply an accident, then that bug could just be fixed with no policy implications. You are suggesting that there is some mistreatment in putting a package in the wrong category. As in might get the same treatment. Is the idea that you somehow wound the ego of a package by putting it in contrib? That surely isn't right, of course. But I'm stuck for wondering. If a package is wrongly put in lib when it belongs in libdevel, for example, or vice versa, there is no huge flame war, nothing bad happens, we just carry on. Such a state could continue for years without anybody getting upset or much caring. I just *assume* that errors in categorization will be made. That doesn't mean errors are good, of course. But my question is: what *harm* does this particular error (if it is an error) cause? Under the default configuration the last time I installed Debian, the contrib section is not used; arguing that some future technical change might change that behavior leaves the issue open until that change is actually made. Fixing a main-contrib error is likely to require much greater effort and debate than a libdevel-lib error, since Policy defines the distinction between main and contrib but not the one between libdevel and devel. Personally, the effort to fix the error is why I prefer to decide a grey area sooner rather than later. The suggestion that wrongly putting a package in contrib is the kind of error that one can live with seems like little more than a way to push it into contrib without addressing the question of whether or not it actually belongs there. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 01:50:16PM -0800, Thomas Bushnell BSG wrote: Adam McKenna [EMAIL PROTECTED] writes: The question is not what problems it would cause. The problems are side effects. It should stay in main because it is free software that is able to be used by at least some subset of our users, without any non-free software. Ok, this seems to be a simple factual question, and I have been unable to see the answer despite careful reading of the thread and the bug log. What is the subset of our users which would find ndiswrapper useful, without the use of free software? I have heard some say that there are no free drivers around for ndiswrapper to wrap. If that's true, then wouldn't that make the subset in question the empty set? Or is there some use to ndiswrapper without a driver to wrap with it? You read the thread so closely that you missed all the references to CIPE? --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Adam McKenna [EMAIL PROTECTED] writes: On Thu, Feb 23, 2006 at 01:30:25PM -0800, Thomas Bushnell BSG wrote: Help me out then. You seemed to suggest that not putting ndiswrapper in main would be to ignore rules that are very clearly laid out in the SC and DFSG. I suggested that the CTTE overriding the developer's judgement in this instance would be an abuse of power, since the DFSG and SC (not to mention policy) clearly spell out the requirements for main, and ndiswrapper clearly meets them. I think this is clearly incorrect. The DFSG and the SC do not say anything about the requirements for main that I can see. This is a clear misunderstanding, AFAICT. Point 1 of the SC says that We will never make the system require the use of a non-free component, and the DFSG define the difference between free and non-free. Since require in the technical sense is expressed through dependencies (although I have seen someone assert with explanation that package dependencies don't matter here, for some reason), it is rather clear to me that ndiswrapper meets the criteria for main. I will try to be clear about what I think is so wrong headed about this thread, and what I worry it represents. ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. The fact that most people use it to enable non-free drivers to work is largely irrelevant - most people use wine and various other emulators for similar purposes. We have historically allowed all of these in main because we have defined the criteria for main in the SC and the DFSG. Repeatedly over the past year or two, several people have been trying to incrementally rewrite the foundation documents by stealth through a slow process of arguing for new interpretations of what these documents meant. I see this entire thread as yet one more attempt at this incremental revisionist work, and it is worrisome. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Michael Poole [EMAIL PROTECTED] writes: Under the default configuration the last time I installed Debian, the contrib section is not used; arguing that some future technical change might change that behavior leaves the issue open until that change is actually made. As I have said, we should (in my opinion) fix the installer to allow the use of contrib packages. As I have repeatedly said, however, this is irrelevant to the question of whether ndiswrapper meets the tests for main rather than contrib, because those tests do not refer to such things as convenience for the installer and the like. This may mean that the tests should be changed, of course. Fixing a main-contrib error is likely to require much greater effort and debate than a libdevel-lib error, since Policy defines the distinction between main and contrib but not the one between libdevel and devel. Personally, the effort to fix the error is why I prefer to decide a grey area sooner rather than later. Policy does specify that packages belong in the correct sections, actually. The suggestion that wrongly putting a package in contrib is the kind of error that one can live with seems like little more than a way to push it into contrib without addressing the question of whether or not it actually belongs there. Um, I actually have no opinion right now about whether ndiswrapper belongs in main or contrib. I haven't got enough facts to understand. I'm trying to understand the question, and one oddity is that some people seem to think it's *extremely important* in a way which is out of kilter with the issues as I understand them. This suggests to me that I must be missing something, so I'd like to know why it's *extremely important*. In other words, if it is pushed into contrib, what bad things happen? If the answer is none, then why the level of anger I've seen in this thread? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: What is the subset of our users which would find ndiswrapper useful, without the use of free software? I have heard some say that there are no free drivers around for ndiswrapper to wrap. If that's true, then wouldn't that make the subset in question the empty set? Or is there some use to ndiswrapper without a driver to wrap with it? You read the thread so closely that you missed all the references to CIPE? Let's see, maybe you didn't read the paragraph where I said: Or, perhaps it's not true that there are no free drivers for it. The claim was also made that there was a single free driver out there for use with ndiswrapper, but others claimed that the hardware in question is already supported, and better, without the use of that driver. I don't know whether this is true, but if it is true, I would appreciate hearing why that should be treated differently than there being no such free driver at all. Is this CIPE? Or is that some other case? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Feel free to submit patches to d-i to have packages from contrib on the first CD and available to the installer. Historically this has not been the case, and I assume it won't be unless someone presents a convincing argument for why it should be, and then does some of the work of getting it done. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. The fact that most people use it to enable non-free drivers to work is largely irrelevant - most people use wine and various other emulators for similar purposes. We have historically allowed all of these in main because we have defined the criteria for main in the SC and the DFSG. Repeatedly over the past year or two, several people have been trying to incrementally rewrite the foundation documents by stealth through a slow process of arguing for new interpretations of what these documents meant. I see this entire thread as yet one more attempt at this incremental revisionist work, and it is worrisome. If you are arguing that people are acting in bad faith, then please take the argument elsewhere. I find far more worrisome this attitude that other developers are lying. I trust my fellow developers to be honest with me; if you do not, please do not infect threads with such suspicions. I do not see anywhere in the SC or the DFSG reference to the main vs. contrib distinction. Perhaps I have missed it; can you please point me to it? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mirror split, amd64 update
Joe Smith [EMAIL PROTECTED] wrote: Anybody blindly mirroring ALL of ftp.debian.org via http or ftp would end up with two copies of the major architectures. However, doing that is a stupid thing anyway, and Debian has no obligation to protect fools who do that. Though you'll agree with me that protecting our mirror sponsors from such a waste of resources is a sensible thing to do. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Feel free to submit patches to d-i to have packages from contrib on the first CD and available to the installer. Historically this has not been the case, and I assume it won't be unless someone presents a convincing argument for why it should be, and then does some of the work of getting it done. This is, however, irrelevant to the present question. The standards for main/contrib do not make reference to convenience for the installer. Perhaps they should be; if you think such a question should be taken into account, then you should... do some of the work of making that change happen. thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using /cdrom/.disk/udeb_(in|ex)clude to load custom udebs instead of d-i's?
On 16:51 Mon 27 Feb , Michael S. Peek wrote: I'm playing with the latest debian-testing-i386-businesscard.iso. One of the things I want to do is automate the network configuration process in an environment where DHCP is not an option. Actually, what I want is for the debian installer to look up the network settings according to the hardware addresses it finds. So what I've done is I've created my own netcfg udeb package, which I've named tiem.netcfg, that provides configured-network. On the iso image, I've created a .disk/ directory and placed within the file udeb_exclude, which contains the single line: netcfg And the file udeb_include, which contains the single line: tiem.netcfg If I understand available-hooks.txt right, this should tell the debian installer to load my tiem.netcfg udeb instead of the debian installer's netcfg, but it doesn't. It loads netcfg anyway. As the installer runs and d-i's netconfig sits there waiting for me to type in an address I can switch to another terminal and load my udebs by hand using udpkg, and my udebs work, they're just not being loaded *instead of* the default udeb. Hi, The debian-boot[1] ml is used for the debian installer, so post on this list about questions related to the debian installer. [EMAIL PROTECTED] Friendly, -- Xavier Oswald -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: Policy does specify that packages belong in the correct sections, actually. Where is that? I did not see anything like that in section 2.4 when I looked before, and I do not see anything like it in 5.6.5. The suggestion that wrongly putting a package in contrib is the kind of error that one can live with seems like little more than a way to push it into contrib without addressing the question of whether or not it actually belongs there. Um, I actually have no opinion right now about whether ndiswrapper belongs in main or contrib. I haven't got enough facts to understand. I'm trying to understand the question, and one oddity is that some people seem to think it's *extremely important* in a way which is out of kilter with the issues as I understand them. This suggests to me that I must be missing something, so I'd like to know why it's *extremely important*. In other words, if it is pushed into contrib, what bad things happen? If the answer is none, then why the level of anger I've seen in this thread? One reason to argue so loudly is if one thinks that this is a specific case of the general question of how hard-line or strict Debian should be about defining main, and that it may be cited as precedent for future decisions. An alternative hypothesis is that since this was argued a year ago, ndiswrapper-in-main advocates think it is a waste of time and want to convey their arguments so that everyone remembers and does not want to argue again in another year. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Stephen Gran [EMAIL PROTECTED] writes: ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. The fact that most people use it to enable non-free drivers to work is largely irrelevant - most people use wine and various other emulators for similar purposes. We have historically allowed all of these in main because we have defined the criteria for main in the SC and the DFSG. Repeatedly over the past year or two, several people have been trying to incrementally rewrite the foundation documents by stealth through a slow process of arguing for new interpretations of what these documents meant. I see this entire thread as yet one more attempt at this incremental revisionist work, and it is worrisome. If you are arguing that people are acting in bad faith, then please take the argument elsewhere. I find far more worrisome this attitude that other developers are lying. I trust my fellow developers to be honest with me; if you do not, please do not infect threads with such suspicions. I said neither that anyone was lying, nor that they were acting in bad faith. I think that they are working for something they believe in and that they are going about it poorly. We have a procedure for changing what the foundation documents say, and it is not by filing bugs or appealing to the tech ctte. If people want the SC to say We will never make the system require the use of a non-free component, and additionally we will not include in our main distribution software that is mostly used for running non-free code, I think they should just say so, rather than trying to advance that agenda in round about manner. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: Stephen Gran [EMAIL PROTECTED] writes: ndiswrapper is a piece of free software. It does not need non-free tools to build, and it will execute as a standalone app without any drivers. The fact that most people use it to enable non-free drivers to work is largely irrelevant - most people use wine and various other emulators for similar purposes. We have historically allowed all of these in main because we have defined the criteria for main in the SC and the DFSG. Repeatedly over the past year or two, several people have been trying to incrementally rewrite the foundation documents by stealth through a slow process of arguing for new interpretations of what these documents meant. I see this entire thread as yet one more attempt at this incremental revisionist work, and it is worrisome. If you are arguing that people are acting in bad faith, then please take the argument elsewhere. I find far more worrisome this attitude that other developers are lying. I trust my fellow developers to be honest with me; if you do not, please do not infect threads with such suspicions. I said neither that anyone was lying, nor that they were acting in bad faith. I think that they are working for something they believe in and that they are going about it poorly. You used the word stealth and revisionist. These are not contributions to an attitude of openness and trust. We have a procedure for changing what the foundation documents say, and it is not by filing bugs or appealing to the tech ctte. The tech-ctte is there to address technical disputes. If people want the SC to say We will never make the system require the use of a non-free component, and additionally we will not include in our main distribution software that is mostly used for running non-free code, I think they should just say so, rather than trying to advance that agenda in round about manner. Once more, the SC does not address the main/contrib distinction at all, as far as I can tell. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Stephen Gran writes: I said neither that anyone was lying, nor that they were acting in bad faith. I think that they are working for something they believe in and that they are going about it poorly. We have a procedure for changing what the foundation documents say, and it is not by filing bugs or appealing to the tech ctte. Although I think ndiswrapper meets the requirements for main, I think this presentation misrepresents what the other side claims. Policy section 2.2.1: In addition, the packages in main: * must not require a package outside of main for compilation or execution (this, the package must not declare a 'Depends', 'Recommends' or 'Build-Depends' relationship on a non-main package) This lists several signs that a package requires another package, but it is not presented as an exhaustive list. If you use a broad definition of require, it is reasonable to exclude ndiswrapper from main on the grounds that there are no NDIS drivers in main. I think that is a too-broad definition of require, but using it does not require changing foundation documents. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Stephen Gran [EMAIL PROTECTED] writes: This one time, at band camp, Thomas Bushnell BSG said: Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 11:29:38AM -0800, Thomas Bushnell BSG wrote: It seems to me that there is no reason ndiswrapper can't be available to the installer whether it's in main or contrib. AFAIK, it would need to be on the first CD. Ok, then we could put selected packages from contrib on the first CD, provided they are DFSG-free, without causing any problems. Since ndiswrapper certainly is DFSG-free, why not do this? Feel free to submit patches to d-i to have packages from contrib on the first CD and available to the installer. Historically this has not been the case, and I assume it won't be unless someone presents a convincing argument for why it should be, and then does some of the work of getting it done. This is, however, irrelevant to the present question. The standards for main/contrib do not make reference to convenience for the installer. Perhaps they should be; if you think such a question should be taken into account, then you should... do some of the work of making that change happen. Well parroted. Since I can see you don't understand the difference between main and contrib, I will point you to it. Please see 2.2.1 and 2.2.2 in policy. If you diff the first set of bullet points that lay out criteria for main and contrib, you'll see that the only differnece is that packages in main : must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) Do you see a Depends, Recommends, or Build-Depends on non-free or contrib software somewhere in the ndiswrapper source or binary packages? I don't. So why is there an argument for changing it? Since there is no foundation in policy, do the benefits or technical merits (of which exactly none have been presented) outweigh ignoring a rather clear statement from policy? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: I am using GPG and am still learning.
On Monday 27 February 2006 11:12, Kirchner Ron - rkirch wrote: I revoked a key, but need to use this key again, is that possible, as I was sent a new key but can not seem to No way to do that. Once you revoke a key, it's done. -- Paul Johnson Email and IM (XMPP Google Talk): [EMAIL PROTECTED] Jabber: Because it's time to move forward http://ursine.ca/Ursine:Jabber -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: Well parroted. Since I can see you don't understand the difference between main and contrib, I will point you to it. Please see 2.2.1 and 2.2.2 in policy. If you diff the first set of bullet points that lay out criteria for main and contrib, you'll see that the only differnece is that packages in main : must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) This is not a complete list. It may not require a package outside of main for compilation or execution. One consequence of that, is that it must not Depend on such packages. But this is not the *only* consequence, it is merely the one being spelled out. It is certainly not true that a package in contrib can be moved to main just be removing the package dependencies. The further question is: can it be run without the non-free software? I still am not sure, having not yet received a complete answer to the factual questions I raised. (Adam gave recently a partial answer, but I'm still not clear on the facts to which he was alluding.) Do you see a Depends, Recommends, or Build-Depends on non-free or contrib software somewhere in the ndiswrapper source or binary packages? I don't. So why is there an argument for changing it? Since there is no foundation in policy, do the benefits or technical merits (of which exactly none have been presented) outweigh ignoring a rather clear statement from policy? The question is not whether there is such a dependency declared; the question is whether the software is useful without the use of non-free software. At first blush, it looks as if the only purpose of the software is to run NDIS drivers. So the question is: are all NDIS drivers non-free software? (Actually, the question is slightly more complex, so please see the previous message in which I gave a more full version of that question.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Thomas Bushnell BSG writes: I do not see anywhere in the SC or the DFSG reference to the main vs. contrib distinction. Perhaps I have missed it; can you please point me to it? I think he addressed this in the first paragraph of that mail: Stephan Gran writes: This is a clear misunderstanding, AFAICT. Point 1 of the SC says that We will never make the system require the use of a non-free component, and the DFSG define the difference between free and non-free. This part of SC#1 would be redundant if it were just a reference to the main versus non-free sections, since it already says We promise that the Debian system and all its components will be free according to these guidelines. Thus, it requires that the Debian system not include packages that meet Policy's definition of contrib but not main. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Michael Poole [EMAIL PROTECTED] writes: Thomas Bushnell BSG writes: I do not see anywhere in the SC or the DFSG reference to the main vs. contrib distinction. Perhaps I have missed it; can you please point me to it? I think he addressed this in the first paragraph of that mail: He said that ndiswrapper is a piece of free software, which is not in doubt, but also not the point. Contrib only includes free software, remember, so saying but it *is* free only proves that it belongs in either main or contrib; it does not establish which. The first paragraph of Stephen's mail said: : ndiswrapper is a piece of free software. It does not need non-free tools : to build, and it will execute as a standalone app without any drivers. : The fact that most people use it to enable non-free drivers to work is : largely irrelevant - most people use wine and various other emulators : for similar purposes. Nothing here, it seems to me, is about the social contract or the DFSG; there is no doubt that ndiswrapper is free software, but the DFSG and the SC do not say anything like all free software can go in main, and indeed, the DFSG and the SC don't seem to say anything about main or contrib anyway. But then, maybe I'm missing it: so please, where in the text of the DFSG or the SC is reference to the main/contrib distinction made? Stephan Gran writes: This is a clear misunderstanding, AFAICT. Point 1 of the SC says that We will never make the system require the use of a non-free component, and the DFSG define the difference between free and non-free. This part of SC#1 would be redundant if it were just a reference to the main versus non-free sections, since it already says We promise that the Debian system and all its components will be free according to these guidelines. Thus, it requires that the Debian system not include packages that meet Policy's definition of contrib but not main. Ah, I see. So pretend I have no non-free components at all. What do I gain by having ndiswrapper around? What does it let me do that I cannot do without it? Please be specific; don't speak in hypothetical terms about software that might or might not exist. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote: Let's see, maybe you didn't read the paragraph where I said: I did. Is this CIPE? Or is that some other case? No, it's not CIPE. I guess you have some more reading to do. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote: Let's see, maybe you didn't read the paragraph where I said: I did. Is this CIPE? Or is that some other case? No, it's not CIPE. I guess you have some more reading to do. Can you point me to the place I should look? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:48:51PM -0800, Thomas Bushnell BSG wrote: The question is not whether there is such a dependency declared; the question is whether the software is useful without the use of non-free software. All right, who pushed the 'thread reset' button? --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:19:05PM -0800, Thomas Bushnell BSG wrote: Let's see, maybe you didn't read the paragraph where I said: I did. Is this CIPE? Or is that some other case? No, it's not CIPE. I guess you have some more reading to do. Ah, a brief search turns up. CIPE is then the sort of thing I was thinking about when I wrote: Or, perhaps it's not true that there are no free drivers for it. The claim was also made that there was a single free driver out there for use with ndiswrapper, but others claimed that the hardware in question is already supported, and better, without the use of that driver. I don't know whether this is true, but if it is true, I would appreciate hearing why that should be treated differently than there being no such free driver at all. According to what I've read, the driver is already supported, and better, without the use of ndiswrapper. But perhaps what I've read is inaccurate? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354654: general: fat32 gets corrupted
Package: general Severity: critical Dear all, I had two vfat crashes, rather similar in two machines (laptops) with debian, dual boot windows xp: - machine1 (compaq nx9010 with celeron): ide disk 30GB (-- System Information: Debian Release: 3.1, Architecture: i386 (i686), Kernel: Linux 2.6.8-1-686, Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15), libc6 Version: 2.3.2.ds1-22) - machine2 (ibm thinkpad r52 with pentium M): etch, kernel: 2.6.12-1-386, sata disk 80GB, (no physical access at the moment to this machine so no way for more system information). In machine1 vfat, 40% of directories where lost (however recoverable under windows using a commercial crash recovery soft). In machine2, 100% was lost in a first crash, but it is random, since the problem is repeating from time to time, and not always everything is lost. Sometimes we lost what was used the day before, and sometimes everithing except the files we used. Lost directories are not located always at the same level. I do not find any logical explanation. No strange message in syslog, we used normal programs (konqueror, thunderbird, oowriter) when sudenly when try to save a file or read mail, an error appears just saying that the directories did not exist any more. In both cases, fat32 was formated under windows. I had smartd running on machine1, nothing strange (maybe a high temperature of the disk +-53°C). On machine2, smartd is not installable since it does not work with sata. Here below the fstab files, plus a smart test on machine1. It was difficult to install sata support in machine2, the strange procedure I used is also described below. Find also a lspci for machine1 and 2. - machine1: cat /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc proc defaults0 0 #cd-rom /dev/hdc/media/cdrom0 iso9660 ro,user,noauto 0 0 #hard disk /dev/hda3 / ext3 defaults,errors=remount-ro 0 1 /dev/hda2 noneswap sw 0 0 /dev/hda6 /mnt/hda6 ext3 defaults0 2 /dev/hda1 /mnt/hda1 ntfs gid=1002,user,ro,umask=002,noexec,nosuid 0 0 /dev/hda5 /mnt/hda5 vfat gid=1002,user,rw,umask=002,noexec,nosuid *** #smartctl -A /dev/hda smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000d 100 100 050 Pre-fail Offline - 51 2 Throughput_Performance 0x0005 100 100 050 Pre-fail Offline - 3950 3 Spin_Up_Time0x0007 100 100 050 Pre-fail Always - 0 4 Start_Stop_Count0x0032 099 099 000 Old_age Always - 1912 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 100 050 Pre-fail Always - 932 8 Seek_Time_Performance 0x0005 100 100 050 Pre-fail Offline - 1224 9 Power_On_Minutes0x0032 092 092 000 Old_age Always - 4066h+47m 10 Spin_Retry_Count0x0013 100 100 050 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1876 191 G-Sense_Error_Rate 0x000a 100 100 000 Old_age Always - 7 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 285 193 Load_Cycle_Count0x0032 077 077 000 Old_age Always - 143904/143618 194 Temperature_Celsius 0x0022 076 052 000 Old_age Always - 52 (Lifetime Min/Max 64/8) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 2 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count0x003e 200 200 000 Old_age Always - 9 200 Multi_Zone_Error_Rate 0x0012 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate0x0012 100 100 000 Old_age Always - 0 223 Load_Retry_Count0x0012 100 100 000 Old_age Always - 0 230 Head_Amplitude 0x0032 094 094 000 Old_age Always - 198978 250 Read_Error_Retry_Rate 0x000a 100 100
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 02:36:54PM -0800, Thomas Bushnell BSG wrote: The tech-ctte is there to address technical disputes. This isn't a technical dispute, it's an ideological one. The technical details very clearly support keeping ndiswrapper in main. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:48:51PM -0800, Thomas Bushnell BSG wrote: The question is not whether there is such a dependency declared; the question is whether the software is useful without the use of non-free software. All right, who pushed the 'thread reset' button? Unlike some, I do not have a perfect memory. Moreover, I do not appreciate vague we already discussed this references. I've read the damn thread; I ask the question because the previous discussion did not seem to actually *answer* the question. If the answer is so blindingly obvious, then really, it can simply be put down. Or a reference given if that's too much trouble. What I'm worried about is a question that I do not think *has* been answered, and that rather than answer it, we get we already answered that without any answer actually having appeared. So, while this question has been asked before--indeed--it has not been answered AFAICT. I've heard it asserted; you mentione the CIPE case. Is that the only case? Is ndiswrapper useful for CIPE? More to the point, it was said that it should be in main if there was a subset of users who would benefit from its presence there, even without the use of any non-free software. What is this subset of users, exactly? Are they users with CIPE hardware? (But they benefit more from the direct support of cipe anway.) Or what? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 02:36:54PM -0800, Thomas Bushnell BSG wrote: The tech-ctte is there to address technical disputes. This isn't a technical dispute, it's an ideological one. The technical details very clearly support keeping ndiswrapper in main. Well, all the questions I've asked, which it seems to me could resolve the dispute, have been technical ones. I'm not sure what the ideological positions are that you think are driving the discussion. I haven't got any, since I haven't formed any opinion about the question one way or the other. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First call for votes for the GFDL position statement
On Sat, Feb 25, 2006 at 05:21:00PM -0600, Debian Project Secretary wrote: - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 25a628e9-d88e-40b7-8e1c-888cff421ea5 [ ] Choice 1: GFDL-licensed works are unsuitable for main in all cases [ ] Choice 2: GFDL-licensed works without unmodifiable sections are free [ ] Choice 3: GFDL-licensed works are compatible with the DFSG [needs 3:1] [ ] Choice 4: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Hi all, Since the way these choices are proposed to you is misleading, I have to sent this specifying message to you all. I am the proposer of Choice 3. According to the Constitution of Debian a supermajority of 3:1 is required for decisions that change a Foundation Document (DFSG in particular). According to the Project Secretary my proposal changes DFSG and thats why he added the comment [needs 3:1]. When you vote, please understand, that the whole point of my proposal is that GFDL is compatible with the current text of DFSG. That is - with proper reading of DFSG, GFDL is compatible with our current guidelines. Of course, it is possible to include in the voting procedure a choice that GFDL is a free license and because of that DFSG have to be corrected. However my proposal [1] is not that. I think the text of my proposal makes completely clear that its whole point is that GFDL is compatible with the current text of DFSG. I hope that with this message I have corrected somewhat the procedural mistake of the Project Secretary so the voting procedure is not completely compromised. My proposal is not what the Project Secretary proposed to you as third choice. Since many of you have not followed the discussions in debian-vote I am taking the opportunity to explain some things. The Project Secretary is the author of the text that was used as a basis for the proposal in Choice 1. Of course as a sympathiser of a position somewhat opposite to my position it comes natural to him to try to oppose my proposal[2]. Nevertheless during the discussions in debian-vote he made some statements that make me think very seriously whether he is ruling conscientiously his office as Project Secretary and whether he is taking illegally advantage of his position. As an illustration, please read the following quotation: Thankfully, Debian is not a democracy. We may vote on some issues, but that does not mean we are a democratically run organisation. The powers of various offices is spelled out in the constitution. In this specific case, I am not going to let the spectre of democracy spur me into doing something I consider wrong. In a true democracy, I would either do what my constituency required even if I thought it wrong, or resign. In Debian, I am permitted to do what I think is right, in as unbiased a manner as I can, until I am removed from my post. Let me explain in short why according to me the reading of DFSG that makes GFDL a free license is more than a possible reading -- it is the only reasonable reading. The third rule of DFSG says: The license must allow modifications and derived works. At first sight it seams that must allow modifications means that the license must allow us to make arbitrary modifications. As a matter of fact this interpretation is impossible because according to it even GPL would be a non-free license (please refer to my proposal for an explanation). With the help of Richard Stallman I could propose an interpretation of DFSG that explains what the words must allow modifications should mean [3]. In debian-vote I asked the supporters of the other choices to explain what their interpretation of DFSG is. So far nobody could tell another reasonable interpretation of DFSG that makes GPL a free license. This is why I am still considering my interpretation of DFSG as the only possible interpretation. Of course an alternative opinion is also possible - the opinion that GPL is a non-free license that contradicts the rules of DFSG and the only reason we accept it as a free license is that DFSG explicitly lists GPL as a free license. It is somewhat strange, but there are Debian developers that hold this position. One of them is our Project Secretary. Please read the following quotation: So, the DFSG are what they say they are -- guidelines. However, some licenses were deemed by the project to be de-facto free, even if they do contravene some of the guidelines, hence explicitly naming the GPL and the bsd licenses. The naming them specifically removes the requirement that they meet all the guidelines. But this does not automatically mean that the dispensation offered to the GPL automatically extends to any other license -- we would need to list any licenses like that explicitly, or modify the guidelines to not conflict. While you are deciding how to vote, please think
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 05:42:51PM -0500, Michael Poole wrote: This lists several signs that a package requires another package, but it is not presented as an exhaustive list. If you use a broad definition of require, it is reasonable to exclude ndiswrapper from main on the grounds that there are no NDIS drivers in main. I don't think this is a valid argument, the requirement is that it must not depend on software outside of main, not that it must have software in main on which to depend. There are in fact free NDIS drivers available. There have been various, uncompelling arguments offered so far as to why these free NDIS drivers do not count for satisfying policy. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 05:42:51PM -0500, Michael Poole wrote: This lists several signs that a package requires another package, but it is not presented as an exhaustive list. If you use a broad definition of require, it is reasonable to exclude ndiswrapper from main on the grounds that there are no NDIS drivers in main. I don't think this is a valid argument, the requirement is that it must not depend on software outside of main, not that it must have software in main on which to depend. Oh, your point here is certainly well-taken. I think the point is not so much whether there is an NDIS driver in main, as whether there is a free NDIS driver for use with ndiswrapper, which is not a toy, and which is best-supported by ndiswrapper and not, say, directly. There are in fact free NDIS drivers available. There have been various, uncompelling arguments offered so far as to why these free NDIS drivers do not count for satisfying policy. I guess I think the right test is: Is this package useful in a system with only free software on it? Useful is a pragmatic question; if every proposed use has a better solution already ready and implemented, then I think the proposed use should not count. I'm prepared to be pretty liberal, in applying such a test. For example, if there were two free drivers to support a piece of hardware, one used through ndiswrapper and one linked into the kernel, such that everyone thought the in-kernel one was better, but there was some class of users for which the ndiswrapper driver would be better, say, because it has some single weird feature that might help, then I would say that the ndiswrapper version is useful, despite the availibility of a generally better alternative. And the mere hypothetical existence of the alternative wouldn't count either. If there is, here and now, a free driver available through ndiswrapper, and there is not any existing alternative (even though, as free software, there theoretically could be), then I would say that counts as useful, even if in an ideal world the use might vanish. So this comes down, for me, to the simple question: what are the free drivers for use with ndiswrapper, and if they are drivers for which there are already generally better alternatives, what makes the ndiswrapper version better for some class of users? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gnucash 1.9.1
I have uploaded gnucash 1.9.1 to the experimental archive today. This is the long-awaited GNOME-2 version of gnucash. Users of gnucash who are willing to use this experimental software are desired. It is not a good idea for every casual user to use it (or I would have put it in unstable), but testing will help the process along. It should be noted that there is no good documentation for it yet (anyone interested in that is eagerly asked to help out), and there are features and parts of the software which are infrequently used and may be quite buggy. Indeed, if they stay uncertain, they will probably be dropped from the 2.0 release when it happens. That means that if you like those features (such things as quicken imports, for example), you are especially wanted as a tester, given the warning that they are extremely fragile. I do not intend to upload the 1.9 series to unstable ever; I will upload 2.0 to unstable once it appears. At that point, I will not be supported the old gnome-1 version of gnucash any longer, and I will orphan the gnome-1 libraries that I have been maintaining. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354654: general: fat32 gets corrupted
On Mon, Feb 27, 2006 at 11:33:19PM +0100, Juan Piñeros wrote: 1 Raw_Read_Error_Rate 0x000d 100 100 050 Pre-fail Offline - 51 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 2 199 UDMA_CRC_Error_Count0x003e 200 200 000 Old_age Always - 9 This is where your issue seems to live. I have never seen the read error and ecc corrected number not matching. It would mean that an error occurs but there has been no way to make it right so I would expect the read to be garbage... Did you see any corruption in your files? I mean data corrupted instead of metadata? Also, you say that sata does not support smart. That is not true, with one of the very recent kernels (2.6.15.4), you can get them. I have not much experience with the kernels shipped with debian. I always recompile my own. But some problems I had with an nfs server (in an HPC system) vanished when I upgraded from 2.6.12 to 2.6.14. There was a bug with the futex, and I think that was the source of my problems (race conditions are always nasty). As for the udma crc? That usually means that your controller/cable is going bad. Each time I have seen that, the whole system crashed corrupting files everywhere... That is pretty odd that you see the thig on two different system though. jacques PS: With development kernels, always try to use the latest. Especially when you see a problem. (And I still consider the 2.6 as being a development version) signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 03:47:22PM -0800, Thomas Bushnell BSG wrote: I guess I think the right test is: Is this package useful in a system with only free software on it? Useful is a pragmatic question; if every proposed use has a better solution already ready and implemented, then I think the proposed use should not count. I think it's the task of those who would ask the tech committee to overrule the maintainer's judgement and remove ndiswrapper from Debian to prove that ndiswrapper is not useful without non-free software, not the other way around. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 03:47:22PM -0800, Thomas Bushnell BSG wrote: I guess I think the right test is: Is this package useful in a system with only free software on it? Useful is a pragmatic question; if every proposed use has a better solution already ready and implemented, then I think the proposed use should not count. I think it's the task of those who would ask the tech committee to overrule the maintainer's judgement and remove ndiswrapper from Debian to prove that ndiswrapper is not useful without non-free software, not the other way around. I'm not so much interested in the politics, and I'm not asking anyone to remove anything. Rather than argue about the burden of proof, which is something that neither of us really get to decide (since the tech-ctte will presumably make its own decision about who must prove what), I'm interested in understanding the technical facts. So I'm still at a loss; the only use of ndiswrapper, on a free-software-only system, seems to be CIPE. Is that correct, or is there some other? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Adam McKenna said: On Mon, Feb 27, 2006 at 03:47:22PM -0800, Thomas Bushnell BSG wrote: I guess I think the right test is: Is this package useful in a system with only free software on it? Useful is a pragmatic question; if every proposed use has a better solution already ready and implemented, then I think the proposed use should not count. I think it's the task of those who would ask the tech committee to overrule the maintainer's judgement and remove ndiswrapper from Debian to prove that ndiswrapper is not useful without non-free software, not the other way around. Additionally, the use of the phrase useful in a system with only free software on it is not something I can find in either 2.2.1 or 2.2.2 (where the difference between main and contrib is spelled out) or anywhere in our foundation documents. Can you point me to where this requirement is mentioned in our policy and/or foundation documents? If it is not currently in policy or our foundation documents, can you explain why this new requirement should be applied for technical reasons? This certainly seems like an ideological problem, rather than a technical one, making the tech ctte a poor choice for conflict resolution. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: Additionally, the use of the phrase useful in a system with only free software on it is not something I can find in either 2.2.1 or 2.2.2 (where the difference between main and contrib is spelled out) or anywhere in our foundation documents. Can you point me to where this requirement is mentioned in our policy and/or foundation documents? It's not in the foundation documents, it's in the definition of contrib. Please remember, the Debian Policy Manual is not a foundation document. In any case, the real point here is the following statement from 2.2.2, which says that contrib is for wrapper packages or other sorts of free accessories for non-free programs. So the question is, is ndiswrapper for free programs, or only for non-free programs? If there are no uses of it (actual *uses*, where it is *useful*) with free programs, then it sure seems like a wrapper for non-free programs. But I don't know; everyone seems to be dancing around the actual question: are there any free drivers for which ndiswrapper is useful? CIPE has been mentioned, but it has also been said that ndiswrapper was not useful in this particular case. Moreover, the statements in 2.2.1 and 2.2.2 are *exemplars*, not final absolute standards. Remember, Policy is not a foundation document. It is a *technical* document. There is no statement in 2.2.1 that everything which meets the test there belongs in main; it is a list of requirements, but does not pretend to be exhaustive. There are some examples of things which belong in contrib, and at first blush, ndiswrapper looks like one of those: to use ndiswrapper, you need a driver to wrap, and there are no such drivers in our archive. And, with only one exception (an exception which it has been said is irrelevant since ndiswrapper is not actually *needed* for CIPE), ndiswrapper is only good for wrapping non-free programs (speaking *right now*; if the facts change, it can easily be moved). But rather than argue about what *might* be so, geez, can *somebody* PLEASE, just answer the factual question? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 04:25:01PM -0800, Thomas Bushnell BSG wrote: So I'm still at a loss; the only use of ndiswrapper, on a free-software-only system, seems to be CIPE. Is that correct, or is there some other? There are plenty of others to be dreamed up. AFAIK, nobody is compiling evidence that any of those others are actually being done, however, the ndiswrapper-in-main proponents (including myself) are arguing that that is beside the point. Packages are not required to be useful in order to be in Debian. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: On Mon, Feb 27, 2006 at 04:25:01PM -0800, Thomas Bushnell BSG wrote: So I'm still at a loss; the only use of ndiswrapper, on a free-software-only system, seems to be CIPE. Is that correct, or is there some other? There are plenty of others to be dreamed up. AFAIK, nobody is compiling evidence that any of those others are actually being done, however, the ndiswrapper-in-main proponents (including myself) are arguing that that is beside the point. Packages are not required to be useful in order to be in Debian. The definition of contrib is that it is for a package which is a wrapper for non-free-software. If there isn't any free software for ndiswrapper to wrap, and the reason we care about having it in the installer is to help support users who are stuck with non-free NDIS drivers as the only way to get their hardware working (and I think this is an *excellent* reason to have it in the installer, btw), it sure seems like its purpose is to wrap non-free software. Maybe I could understand your point better if you could give me an example of a wrapper for non-free software which you *do* think belongs in contrib, so that I can understand what's different about that case and ndiswrapper? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Stephen Gran [EMAIL PROTECTED] writes: Additionally, the use of the phrase useful in a system with only free software on it is not something I can find in either 2.2.1 or 2.2.2 (where the difference between main and contrib is spelled out) or anywhere in our foundation documents. Can you point me to where this requirement is mentioned in our policy and/or foundation documents? It's not in the foundation documents, it's in the definition of contrib. Please remember, the Debian Policy Manual is not a foundation document. I see you have failed to notice the 'and/or' construct in the part that you quoted. Now that I have drawn your attention to it, we can leave Reading Comprehension 101 behind us. In any case, the real point here is the following statement from 2.2.2, which says that contrib is for wrapper packages or other sorts of free accessories for non-free programs. Since ndiswrapper's main purpose is to create a kernel API to allow drivers designed for a different API to communicate with the kernel, I don't think this counts as a wrapper. ndiswrapper does what it sets out to do, whether or not any software (free or not) uses that API. So the question is, is ndiswrapper for free programs, or only for non-free programs? No, the question is, is ndiswrapper a functionally complete program? Other pieces of software, both free and non-free, are free to use it in order to run, but I can't imagine that makes any difference to the freeness of ndiswrapper. But I don't know; everyone seems to be dancing around the actual question: are there any free drivers for which ndiswrapper is useful? This is an irrelevant question, which is why you're not getting an answer you're happy with. Moreover, the statements in 2.2.1 and 2.2.2 are *exemplars*, not final absolute standards. Remember, Policy is not a foundation document. We left this class earlier, you may remember. But rather than argue about what *might* be so, geez, can *somebody* PLEASE, just answer the factual question? Yes. Non-free drivers need ndiswrapper. ndiswrapper does not need non-free drivers. There is no dependency. Does that help? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
Stephen Gran [EMAIL PROTECTED] writes: In any case, the real point here is the following statement from 2.2.2, which says that contrib is for wrapper packages or other sorts of free accessories for non-free programs. Since ndiswrapper's main purpose is to create a kernel API to allow drivers designed for a different API to communicate with the kernel, I don't think this counts as a wrapper. ndiswrapper does what it sets out to do, whether or not any software (free or not) uses that API. That's curious. It's described as a wrapper in the package name, the Debian package description, and the upstream webpage. In both cases, it is specifically documented as being for use with non-free software. It's specifically said that its purpose is to deal with the fact that some vendors refuse to release hardware specifications and that for such hardware, users are stuck with non-free NDIS drivers. While we are trusting the package maintainer, surely we should trust the package maintainer to be correctly documenting the program? However, if the description is incorrect, then perhaps it should be changed. I don't really know, because I'm not an expert on the technical question here. No, the question is, is ndiswrapper a functionally complete program? Are you saying that ndiswrapper is useful all by itself, without any drivers at all? I have asked this question before, but didn't get an answer; I really don't know. What functions does it provide, in the absence of an NDIS driver? But I don't know; everyone seems to be dancing around the actual question: are there any free drivers for which ndiswrapper is useful? This is an irrelevant question, which is why you're not getting an answer you're happy with. Well, if it's true that ndiswrapper is useful even without any drivers, then yeah, that would be an irrelevant question. I haven't seen any descriptions of its functionality except that it is useless without drivers to wrap. But rather than argue about what *might* be so, geez, can *somebody* PLEASE, just answer the factual question? Yes. Non-free drivers need ndiswrapper. ndiswrapper does not need non-free drivers. There is no dependency. Does that help? Perhaps we disagree about what a wrapper is. Can you give me an example of a wrapper that you think does belong in contrib? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354654: general: fat32 gets corrupted
Juan Piñeros wrote: I do not find any logical explanation. No strange message in syslog, we used normal programs (konqueror, thunderbird, oowriter) when sudenly when try to save a file or read mail, an error appears just saying that the directories did not exist any more. In the past i had a similar problem: sometimes, with no appearing regularity, some files simply got corrupted (filesystem was ext3). I simply couldn't understand what could be, since the hard disk seemed to be ok. Until i have remembered to have played with hdparm and put an optimized hdparm command line in a boot script. After i commented out that line, i hadn't no more corruption. I don't know if this can be your case. Regards. Cesare.
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 05:03:25PM -0800, Thomas Bushnell BSG wrote: The definition of contrib is that it is for a package which is a wrapper for non-free-software. [EMAIL PROTECTED] --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On Mon, Feb 27, 2006 at 04:45:04PM -0800, Thomas Bushnell BSG wrote: But I don't know; everyone seems to be dancing around the actual question: are there any free drivers for which ndiswrapper is useful? CIPE has been mentioned, but it has also been said that ndiswrapper was not useful in this particular case. [EMAIL PROTECTED] --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
This one time, at band camp, Thomas Bushnell BSG said: Stephen Gran [EMAIL PROTECTED] writes: In any case, the real point here is the following statement from 2.2.2, which says that contrib is for wrapper packages or other sorts of free accessories for non-free programs. Since ndiswrapper's main purpose is to create a kernel API to allow drivers designed for a different API to communicate with the kernel, I don't think this counts as a wrapper. ndiswrapper does what it sets out to do, whether or not any software (free or not) uses that API. That's curious. It's described as a wrapper in the package name, the Debian package description, and the upstream webpage. In both cases, it is specifically documented as being for use with non-free software. It's specifically said that its purpose is to deal with the fact that some vendors refuse to release hardware specifications and that for such hardware, users are stuck with non-free NDIS drivers. While we are trusting the package maintainer, surely we should trust the package maintainer to be correctly documenting the program? I would actually expect all of them to describe the package in a way that is useful to users. I would not expect anyone to describe the package in terms of how it works or what it actually does. Most people wouldn't bother to read it, their eyes would glaze over, and they would miss out on a potentially useful piece of free software. No, the question is, is ndiswrapper a functionally complete program? Are you saying that ndiswrapper is useful all by itself, without any drivers at all? I have asked this question before, but didn't get an answer; I really don't know. What functions does it provide, in the absence of an NDIS driver? It provides a kernel API that can be used to allow the NDIS stack to communicate with the linux network stack. But I and others have answered this question already. The fact that you're asking it again leads me to believe that either you didn't like the first answer, or that you can't go back to the millions of previous mails in this thread. But I don't know; everyone seems to be dancing around the actual question: are there any free drivers for which ndiswrapper is useful? This is an irrelevant question, which is why you're not getting an answer you're happy with. Well, if it's true that ndiswrapper is useful even without any drivers, then yeah, that would be an irrelevant question. I haven't seen any descriptions of its functionality except that it is useless without drivers to wrap. Then please do minimal research before answering every single email in a thread. But rather than argue about what *might* be so, geez, can *somebody* PLEASE, just answer the factual question? Yes. Non-free drivers need ndiswrapper. ndiswrapper does not need non-free drivers. There is no dependency. Does that help? Perhaps we disagree about what a wrapper is. Can you give me an example of a wrapper that you think does belong in contrib? As far as I know, we have so far held 'wrapper' to mean things like installers that installed non-free software, or hardware emulators that require non-free roms to even start. There are dozens of those already in contrib. I assume you can look for yourself and get a reasonable idea. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Mon, 27 Feb 2006 14:48:51 -0800 Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Stephen Gran [EMAIL PROTECTED] writes: Well parroted. Since I can see you don't understand the difference between main and contrib, I will point you to it. Please see 2.2.1 and 2.2.2 in policy. If you diff the first set of bullet points that lay out criteria for main and contrib, you'll see that the only differnece is that packages in main : must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) This is not a complete list. It may not require a package outside of main for compilation or execution. One consequence of that, is that it must not Depend on such packages. But this is not the *only* consequence, it is merely the one being spelled out. It is certainly not true that a package in contrib can be moved to main just be removing the package dependencies. The further question is: can it be run without the non-free software? I still am not sure, having not yet received a complete answer to the factual questions I raised. (Adam gave recently a partial answer, but I'm still not clear on the facts to which he was alluding.) Do you see a Depends, Recommends, or Build-Depends on non-free or contrib software somewhere in the ndiswrapper source or binary packages? I don't. So why is there an argument for changing it? Since there is no foundation in policy, do the benefits or technical merits (of which exactly none have been presented) outweigh ignoring a rather clear statement from policy? The question is not whether there is such a dependency declared; the question is whether the software is useful without the use of non-free software. At first blush, it looks as if the only purpose of the software is to run NDIS drivers. So the question is: are all NDIS drivers non-free software? (Actually, the question is slightly more complex, so please see the previous message in which I gave a more full version of that question.) I am not a DD, so maybe my opinion is idiotic. But: the thing is free, it allows people to use non-free drivers, but it is entirerly up to the user to use those drivers. I don't know, but for me this discussion is pointless. Does ndiswrapper require non-free packages? no. if the user decides to use non-free drivers, then it's his choice, not debian's, so what. and no, I don't care much, because i do not use ndiswrapper, but this is starting to get silly. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
