Re: LCC and blobs
On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote: > The social contract says "...but we will never make the system depend on > an item of non-free software." not "but we will never make the system > depend on an item of non-free software /which we must distribute/." We don't make the hardware. -- Raul
Re: LCC and blobs
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > Henning Makholm wrote: >> Scripsit Anthony DeRobertis <[EMAIL PROTECTED]> >> >>>That would, however, cover firmware and wind up sending X to >>>contrib. So maybe: ... iff it is stored on the local machine's file >>>system. >> That would be my *intuitive* understanding of how the mail/contrib >> difference works. >> > > So would a web-based firmware loader, that never saved the firmware to > disk allow the drivers to be in main? Of course not. It's fetching software, then using that software. ICQ software merely mentions messages, but doesn't use them. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
On Thu, Dec 30, 2004 at 03:09:52PM -0600, Gunnar Wolf wrote: > Hamish Moffatt dijo [Tue, Dec 28, 2004 at 04:26:26PM +1100]: > > Yet the ICQ client is not useful without a component which is not in > > Debian and in fact is not freely available. > > > > If the emulators were extended to be able to fetch some basic ROM images > > off the internet by themselves (eg via HTTP), could they go in main? > > The blobs for the in-kernel drivers are not to be executed by the host > CPU itself, neither is the non-free ICQ, MSN or Yahoo servers > (although Gaim can be seen useful by itself as it works with IRC and > Jabber... Well, brain, please don't hijack my message ;-) ). They will > be run on the other side of the abstraction (call it bus or > network). The ROM for an Amiga, Atari or similar machine _does_ get > used directly by your PC's CPU. Who cares which CPU is executing the code? That's a non-issue. If I have an SMP system, can I circumvent the spirit of the SC/DFSG by claiming that one CPU is primary, running Debian, and the second CPU is a secondary slave CPU, running a lot of non-free stuff--allowing me to have any non- free dependencies in main that I want? Of course not--and the same thing doesn't work if the secondary CPU is on a sound card's DSP or a SCSI card's processor. The CPU being used isn't an important metric here (even if it's not obvious what the real metric is). -- Glenn Maynard
Re: Happy new year 2003
Quoting Jean-Luc Picard ([EMAIL PROTECTED]): > yes, debian is still 2 years late to any other distro. Flame answer sent in private mail, in French, which makes me easier to share my feelings about the consideration the above mail shows towards a volunteer work.
Re: Happy new year 2003
El dv 31 de 12 del 2004 a les 23:50 +0100, en/na Jean-Luc Picard va escriure: > yes, debian is still 2 years late to any other distro. Are you sure? I win a lot of time using debian because all I can find is packaged and works directly, the quality and dependence system is enought hard to assure I'm not going to have problems. Ah another thing my Deebian says we are on 1-1-2005 ! > > _ > MSN Messenger : dialoguez en temps réel avec vos amis ! > http://g.msn.fr/FR1001/866 > > -- Miguel Gea Milvaques <[EMAIL PROTECTED]> Blog: http://www.livejournal.com/users/xerakko/ signature.asc Description: =?ISO-8859-1?Q?Aix=F2?= =?ISO-8859-1?Q?_=E9s?= una part d'un missatge, signada digitalment
Re: LCC and blobs
Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
> Henning Makholm wrote:
>> Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
>>>That would, however, cover firmware and wind up sending X to
>>>contrib. So maybe: ... iff it is stored on the local machine's file
>>>system.
>> That would be my *intuitive* understanding of how the mail/contrib
>> difference works.
> So would a web-based firmware loader, that never saved the firmware to
> disk allow the drivers to be in main?
Hmm. Maybe. If it was properly documented in the package description
for the driver that its proper function relies on an external website
that the user presumably has no control over, then perhaps. But I
don't think I would be really comfortable with it.
The line is difficult to draw in the area of relying on external
services.
At one end of the spectrum is cases where what a typical user really
wants to use is the external service; he knows that the service is
external and views the client as a mere conduit to access something
that he knows he does not control. I _think_ everybody agrees
intuitively that such clients can be in main. The canonical example
would be a client for proprietary IM systems, but the situation is
somewhat similar with, say. IRC clients. Even though main does contain
IRC server software, the vast majority of users want to connect to
existing external IRC networks, so having the source does not really
help them control the service that they use. Yet nobody would suggest
that the client does not belong in main for this reason (except
perhaps as part as a reductio-ad-absurdum argument about the true
meaning of the SC).
Things begin to get murky when the client provides a local service
that is useful in its own right, and only incidentally needs to
contact external network sites to provide it. One could imagine an
anti-spam tool that submitted checksums of message fragments to a
central server for correllation with other user's data. (Never mind
that such an anti-spam measure would probably not be effective, at
least not if it became popular). Or one could imagine a heuristic
keyword extractor for plain text files which, behind the scenes,
queried Google to find out how common cetain phrases. In these cases
the user is not primarily interested in interacting with an external
service but is probably still aware that the quality of the results he
gets owe something to the use of external resources.
At the extreeme other end is situations where the net service the user
actually wants ("I want to scan this photograph with my WinScanner")
has no *extrinsic* reason to require a non-local resource. Web-based
firmware loaders belong here.
I have definite qualms about including something of the latter
category in main, but I am not sure that I can support this judgement
with deductions from a short clear-cut definition of what each word in
the SC and Policy means. However, I don't think that such a deductive
development is a necessary requirement for which policy the project
should adopt. Bright-line tests are overrated anyway.
--
Henning Makholm"Jeg køber intet af Sulla, og selv om uordenen griber
planmæssigt om sig, så er vi endnu ikke nået dertil hvor
ordentlige mennesker kan tillade sig at stjæle slaver fra
hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."
Re: LCC and blobs
On Thu, Dec 30, 2004 at 03:09:52PM -0600, Gunnar Wolf wrote: > The blobs for the in-kernel drivers are not to be executed by the host > CPU itself, neither is the non-free ICQ, MSN or Yahoo servers > (although Gaim can be seen useful by itself as it works with IRC and > Jabber... Well, brain, please don't hijack my message ;-) ). They will > be run on the other side of the abstraction (call it bus or > network). The ROM for an Amiga, Atari or similar machine _does_ get > used directly by your PC's CPU. Not really - it is data for the emulator program only. It is not executable on your host CPU, just like the text of the bible. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Best way to wrap gcc/g++ calls?
Hello, I am the current maintainer of apt-build. I am looking for the best way to wrap all calls to gcc/g++. For now, apt-build makes a diversion like this in /usr/bin: lrwxrwxrwx 1 root root 11 Dec 31 14:27 gcc -> gcc-3.3 becomes: lrwxrwxrwx 1 root root 7 Nov 15 21:17 gcc.real -> gcc-3.3 And it installs a program called gcc.wrapper instead, which executes gcc.real with good options: lrwxrwxrwx 1 root root 11 Dec 31 14:27 gcc -> gcc.wrapper -rwxr-xr-x 1 root root 4656 Dec 31 14:26 gcc.wrapper But some programs call directly gcc-3.3 (like libc6 as I can see), or i386-linux-gcc. Do you have any idea about how to divert everything correctly ? I think I could provide a gcc-apt-build package which would do the job by replacing the gcc one and diverting some files, but I am bot happy with this solution. So, I am waiting for suggestions, Cheers, -- Julien Danjou .''`. Debian developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Orphaning some packages
Hello, I plan to orphan some of my packages. At the moment I have not enough time for those packages. cacti - Frontend to rrdtool for monitoring systems and services There is a new upstream version available, which fix a lot of outstanding bugs. Please let me known, if you are interested on this package. If no one is interested on those packages, I ask for removal from the archive: kernel-patch-systrace - Systrace kernel patch systrace - Enforce system call policies for applications xsystrace - Systrace frontend invoked by systrace Regards, Thorsten -- Thorsten Sauter <[EMAIL PROTECTED]> (Is there life after /sbin/halt -p?) signature.asc Description: Digital signature
Re: handling bugs of udev
Hallo Brian, * Brian May <[EMAIL PROTECTED]> [2004-12-27 00:56]: > > "Nico" == Nico Golde <[EMAIL PROTECTED]> writes: > > Nico> this bug: > Nico> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286257 > > I am not sure what the problem is here, according to the bug report, > the solution was: > > cd /etc/udev/rules.d/ > ln -s ../cd-aliases.rules . yes that solves my problem too. > However, on my system, this symlink was already created for me > (IIRC). Looking at the postinst script, this symlink is always > created(?). i think this should be created be default, but thats the decision of the maintainer. > My only problem I had is that I came from devfs, and it come as a > surprise that ide-cd wasn't automatically loaded. Sure, it was easy > for me to fix, and it is pointed out in the documentation too, but if > I was a Linux novice, I might get totally confused. yes right. > Also, certain paragraphs from README.Debian, of udev 0.048-2 rather > confused me: > > "If you prefer devfs-style names you can switch by removing this link > and creating new links to udev-devfs.rules (devfs-style devices) and > optionally udev-compat.rules (some compatibility symlinks) and > rebooting. As long as the directory is not empty, the package will > not modify the symlinks contained." > > On my system, the closest file I could find was devfs.rules (not > udev-devfs.rules), but there was already a symlink created for me. > > Maybe the documentation needs updating... i think yes, but marco will see it different. regards nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF ,'"`. [EMAIL PROTECTED] | http://www.ngolde.de ( grml.org VIM has two modes - the one in which it beeps`._,' and the one in which it doesn't -- encrypted mail preferred signature.asc Description: Digital signature
Re: Happy new year 2003
On Fri, 31 Dec 2004 23:50:52 +0100, Jean-Luc Picard <[EMAIL PROTECTED]> wrote: > yes, debian is still 2 years late to any other distro. If you're sleeping since Woody release, we're! Good morning Jean-Luc, for your information: - There' s a new Debian installer[0] that will be used in the upcoming release, called Sarge; - Some awards[1] since then; - It seems that our infrastructure and QA matters[2]; [0] = http://www.debian.org/devel/debian-installer [1] = http://www.debian.org/misc/awards [2] = http://www.debian.org/misc/children-distros There' s much more but i hope it' s enough to anyone sleeping for two years see that Debian isn't `too late`. It' s far away from state of art but the majority of work is being done by volunteers and without it you wouldn't be booting knoppix, ubuntu and others! -- Gustavo Franco -- <[EMAIL PROTECTED]>
Re: Best way to wrap gcc/g++ calls?
* Julien Danjou [Sat, 01 Jan 2005 15:22:16 +0100]: > Do you have any idea about how to divert everything correctly ? > I think I could provide a gcc-apt-build package which would do the job > by replacing the gcc one and diverting some files, but I am bot happy > with this solution. > So, I am waiting for suggestions, I wouldn't mess with the real /usr/bin/* binaries/symlinks, and would do something similar to what ccache does. have a look at /usr/lib/ccache. (so, apt-build would prepend /usr/lib/apt-build or similar to the PATH.) perhaps this has other drawbacks I can't think of, and must add that I'm completely unfamiliar with how apt-build works. but perhaps the above helps. cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges
Re: Happy new year 2003
On Fri, 2004-12-31 at 23:50 +0100, Jean-Luc Picard wrote: > yes, debian is still 2 years late to any other distro. WTF do you get by trolling? -- David Moreno Garza <[EMAIL PROTECTED]> | http://www.damog.net/ If you fall and break your leg, don't come running to me!
Re: Best way to wrap gcc/g++ calls?
On Jan 01, Adeodato Simó <[EMAIL PROTECTED]> wrote: > I wouldn't mess with the real /usr/bin/* binaries/symlinks, and would > do something similar to what ccache does. have a look at /usr/lib/ccache. > (so, apt-build would prepend /usr/lib/apt-build or similar to the PATH.) Agreed. This is what cross-compilers do as well. -- ciao, Marco signature.asc Description: Digital signature
Re: LCC and blobs
Anthony DeRobertis wrote: > The social contract says "...but we will never make the system depend on > an item of non-free software." not "but we will never make the system > depend on an item of non-free software /which we must distribute/." > > In order to allow the vast majority of hardware which actually contains > firmware in e.g., EEPROM, we must: > > a. Decide that somehow, the bits in EEPROM are not software. >Personally, this seems dishonest and silly. Every attempt >I've seen to do this somehow make dd into a magic hardware to >software conversion tool. > > b. Use a definition of 'require' like the "if it's on the fs" one >above. Not quite as silly as (a). Would get interesting if >the firmware loading helper I mentioned in another message never >stored the firmware to disk. > > c. Try and find a definition of require based on where the code >runs; however, this gives us a problem with both the BIOS >(sending lilo, grub, etc. to contrib, thus the kernel to contrib, >thus the whole system) and, even if we ignore that, X to contrib >(due to calls to video card BIOSes) and kernel (text console). > > d. Try and find a definition of require which talks about APIs and >abstraction. This would be hard, especially if we decide we want >to consider firmware on disk drivers contrib. > > e. Decide that having a few pieces of software --- hardware drivers >only --- requiring non-free software does not make "the system" >require non-free software, and thus does not violate the SC. >This would require a change to Debian Policy, too. This would >probably let firmware-on-disk drivers back into main (but their >firmware would of course be in non-free, if distributed at all). > > f. Decide to ignore the social contract, and document that, possibly >with an appology. > > g. Amend the social contract. I would like to suggest an additional option, which I think covers most cases quite well: If Debian were to package (a copy of) the non-free item in the non-free section, would the Free package express a Depends, Recommends, or Build-Depends on the non-free package? If so, the Free package should be in contrib. This is the same criteria we already use to prevent packages in main from depending on non-free, with the additional consideration that when the non-free item is so non-free that we can't package it, we should still consider the dependencies of the Free package, which we would express if we could package that non-free item. This criteria covers ICQ clients: if we were to ship an ICQ server, the ICQ client would at most Suggests: icq-server , because it runs non-locally, and you don't need one on your local machine to run a client. This criteria covers driver-loaded firmware: if we could legally ship the firmware, the driver would probably Depends: firmware, or perhaps Recommends: firmware if there is some obscure reason why we believe the user may want to supply a firmware file other than what we ship. This criteria covers firmware burned into the device (possibly reflashable): if we could legally ship the firmware, the driver would at most Suggests: firmware, because although you could certainly flash the firmware on the device, the driver doesn't need the firmware, and neither does the device. This also applies to X and video BIOSes, as well as bootloaders and BIOSes. Please suggest any case which you don't think this criteria adequately covers. The only change required to implement this criteria would be a minor change to Debian Policy: in section 2.2.1 "The main section", in the passage > In addition, the 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), , the parenthetical would need to be updated to make it clear that it still applies even if the dependencies are not expressed because the package is not in the archive. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: LCC and blobs
On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote: > Please suggest any case which you don't think this criteria adequately > covers. The bios. Unless, we decide that the bios we put in non-free isn't the bios we need to boot the machine. -- Raul
installing an alternative in /etc ?
Hi, is it OK to have a package install an alternative in /etc, like this: update-alternatives --install \ /etc/emacs/site-start.d/51caml-mode.el \ caml-mode-startup.el \ /usr/share/emacs/site-lisp/tuareg-mode/tuareg-startup.el \ 30 The question is whether update-alternatives will always respect local modifications, like replacing the symlink /etc/emacs/site-start.d/51caml-mode.el by a plain file. Another possible problem with symlinks pointing outside of /etc is that an unsuspecting sysadmin might modify a file he believes to reside in /etc but which in reality isn't. Should in this case the target of the symlink be registered as a conffile? -Ralf. --
Re: Best way to wrap gcc/g++ calls?
On Sat, Jan 01, 2005 at 07:46:48PM +0100, Marco d'Itri wrote: > On Jan 01, Adeodato Simó <[EMAIL PROTECTED]> wrote: > > > I wouldn't mess with the real /usr/bin/* binaries/symlinks, and would > > do something similar to what ccache does. have a look at /usr/lib/ccache. > > (so, apt-build would prepend /usr/lib/apt-build or similar to the PATH.) > Agreed. This is what cross-compilers do as well. Thanks, I will take a look on this. Cheers, -- Julien Danjou .''`. Debian developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: RFP: gaim-guifications -- Show events notifications of gaim in a popup window
* Luca Capello | on 05/03/2004 01:01 AM, Ramón Rey Vicente wrote: | > * Package name: gaim-guifications | > Version : 1.7 | > Upstream Author : Gary Kramlich <[EMAIL PROTECTED]> | > * URL : http://guifications.sourceforge.net/ | > * License : GPL | > Description : Show events notifications of gaim in a popup window | it seems that no one is working on this package. I'm debianizing it, but | this package needs 'gaim.pc' and 'VERSION' from the 'gaim' sources. I'm | going to fill a wishilist request for a 'gaim-dev' package to the gaim | maintainers. | | Once the problem will be solved, I'll prepare the .deb :-) I've actually already packaged it, but forgot to retitle the ITP. If you're not finished debianizing it, feel free to grab my sources from my Debian arch repository at http://arch.err.no/[EMAIL PROTECTED] (If you don't want to maintain it, I can; either way is fine with me.) gaim-dev is in NEW and waiting for ftp-master approval, so there is no need to bug the gaim maintainers further. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bug#283005: ITP: vhcs -- Virtual Hosting Control System
Am Freitag, den 31.12.2004, 13:24 -0600 schrieb Steve Greenland: > On 29-Dec-04, 09:30 (CST), Hendrik Frenzel <[EMAIL PROTECTED]> wrote: > > * License : MPL 1.1 > > Description : VHCS is a webhosting management system. > > VHCS delivers a complete hosting automation appliance by offering > > significant security, total-cost-of-ownership, and performance > > advantages over competing commercial solutions. > > Would it be possible to have a description of what the package *does*, > rather than marketing gobbledy-gook? > > Steve VHCS is a software for small Web/DomainHosting ISPs. With them, you can manage your virtual hosts, domains, mail/ftp users and databases. Its GUI is used to create administrator- reseller-, and customeraccounts and the vhcs engine will manage the appropiate services like apache, bind, postfix and stuff. It is a software like confixx, ensim or maybe plesk and a little bit webmin. VHCS supports apache2, php4, bind9, proftpd, mysql/pgsql, postfix and courier (pop3/imap) and is themeable. bye Hendrik -- I am chaos. I am the substance from which your artists and scientists build rhythms. I am the spirit with which your children an clowns laugh in happy anarchy. I am chaoss. I am alive and tell you, that you are free. - Eris, Goddess of Chaos, Discord and Confusion signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: LCC and blobs
Scripsit Raul Miller <[EMAIL PROTECTED]> > On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote: >> Please suggest any case which you don't think this criteria adequately >> covers. > The bios. > Unless, we decide that the bios we put in non-free isn't the bios we > need to boot the machine. On which architectures would we want to let anything declare a Depends: on a BIOS package? Granted, the only arch I'm really familiar with is i386, but most of those machines come with a sufficiently adequate BIOS in ROM that it would be rather silly for most packages, including stock kernels and boot loaders, to declare more than a Suggests: against an alternative BIOS. That would just bloat the user's file system without gaining him anything. -- Henning Makholm "Det er du nok fandens ene om at mene. For det ligger i Australien!"
whois 4.6.24+volatile3 accepted into woody-volatile
Hi, I just accepted whois 4.6.24+volatile3 into woody-volatile. This version reflects the changed address of the .org whois registrary and is adapted to the new query format of the .de whois registrary; besides of this, some IP address mappings were updated. Please see the package changelog for a full description of the changes. The updated package is available as source and as binary for all woody release architectures at http://volatile-ftp.debian.net/debian-volatile/pool/main/w/whois/ . You can also add deb http://volatile-ftp.debian.net/debian-volatile woody-volatile main deb-src http://volatile-ftp.debian.net/debian-volatile woody-volatile main to your sources.list to get all updates to woody-volatile. For further informations about volatile, please see volatile.debian.net. If there are any issues, please don't hesitate to speak with me. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: LCC and blobs
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Raul Miller <[EMAIL PROTECTED]> >> On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote: > >>> Please suggest any case which you don't think this criteria adequately >>> covers. > >> The bios. >> Unless, we decide that the bios we put in non-free isn't the bios we >> need to boot the machine. > > On which architectures would we want to let anything declare a > Depends: on a BIOS package? Granted, the only arch I'm really > familiar with is i386, but most of those machines come with a > sufficiently adequate BIOS in ROM that it would be rather silly for > most packages, including stock kernels and boot loaders, to declare > more than a Suggests: against an alternative BIOS. That would just > bloat the user's file system without gaining him anything. Some Alpha systems (I forgot which) came with only the inferior AlphaBIOS installed in flash. Later, an SRM version for this system was released, and installing this is generally considered a good thing. These firmwares required different boot loaders, and different kernel configurations, so a boot loader or kernel package could reasonably have some sort of dependency on one of the firmwares. -- Måns Rullgård [EMAIL PROTECTED]
dependancy issues
I'm trying to trim my system a little bit. I wanted to purge Evolution from my system since I use Mutt for email. But doing that wants to remove Gnome. Also, I wanted to update console-data to the recent version but it wants to remove Base-Config and Console-tools (I just upgraded base-config). Finally, for some strange reason, upgrading cupsys wants to install Samba EVEN THOUGH it's only a recommendation and not a true dependancy. What gives with these? Are they real bugs or is something awry? -- .''`. Carl B. Constantine : :' : [EMAIL PROTECTED] `. `'GnuPG: 135F FC30 7A02 B0EB 61DB 34E3 3AF1 DC6C 9F7A 3FF8 `- Debian GNU/Linux -- The power of freedom "Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world."
Re: dependancy issues
Re: Carl B. Constantine in <[EMAIL PROTECTED]> > I'm trying to trim my system a little bit. I wanted to purge Evolution > from my system since I use Mutt for email. But doing that wants to > remove Gnome. apt-cache is your friend: [0] [EMAIL PROTECTED]:~ $apt-cache show gnome Package: gnome [...] Depends: gnome-desktop-environment (= 62), gnome-office (= 62), bluefish, evolution (>= 2.0.2) | balsa, gnome-cups-manager (>= 0.25), gnome-nettool, ^ gnome-system-tools (>= 1.0.0), gnome-themes-extras, rhythmbox, synaptic (>= 0.53.4) | gnome-apt, totem, vino, xscreensaver Maybe you better ask on debian-user? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
How to ensure packages generated from -source are installable?
Kernel module source packages generated Debian packages which may not be installable. For instance, alsa-source does not depend on alsa-base, but the generated alsa-modules does. ndiswrapper-source does the same with ndiswrapper-utils. Is there a flag to dpkg to refuse to install unless dependencies are met? What ends up happening now is the package ends up installing broken. The generalized form of this question is how does one deal with missing dependencies when using dpkg and not apt.
Re: dependancy issues
On Sat, Jan 01, 2005 at 05:07:42PM -0800, Carl B. Constantine wrote: > I'm trying to trim my system a little bit. I wanted to purge Evolution > from my system since I use Mutt for email. But doing that wants to > remove Gnome. So it wants to remove the Gnome meta-package. So what? -- Marc Wilson | Some people say a front-engine car handles best. [EMAIL PROTECTED] | Some people say a rear-engine car handles best. | I say a rented car handles best. -- P.J. O'Rourke
Re: LCC and blobs
On Sun, Jan 02, 2005 at 01:27:21AM +0100, Måns Rullgård wrote: > Some Alpha systems (I forgot which) came with only the inferior > AlphaBIOS installed in flash. Later, an SRM version for this system > was released, and installing this is generally considered a good > thing. These firmwares required different boot loaders, and > different kernel configurations, so a boot loader or kernel package > could reasonably have some sort of dependency on one of the > firmwares. Stretching that line of thinking, a VGA driver "depends" on a card with a VGA BIOS. And I had once a card with a flashable VGA BIOS. And I had to flash it once because the Linux driver wouldn't work with the older one (anymore IIRC)... Unless you are saying that you have to reload the firmware each time you boot the machine (and I know you aren't because I had one of those at some point), I hope that you can understand that you have to modify the machine in order to use a particular piece of software, because that particular piece of software requires that particular machine. IOW, we could can the entire port because it depends on present on machine , being a BIOS, a certain chipset, a certain controller, a certain graphics card, or whatever else you wish. Darn! That's all of them. IMO we have to draw the line at some point that's *useful* and *practical*. Committing suicide is neither of those. I think the proposal that spawned this subthread is both. Marcelo
Re: LCC and blobs
Matthew Garrett <[EMAIL PROTECTED]> writes: > The parsimonious explanation is that the issue wasn't thought about in > that much detail when the social contract was written. The archives tend > to support this. The obvious thing to do here is not to attempt to find > a way that we can interpret the SC that makes sense - the obvious thing > to do here is to decide what we want the SC to say and then change it so > that it matches that desire. We already did that.
Re: murphy is listed on spamcop
Russell Coker <[EMAIL PROTECTED]> writes: > Any anti-spam measure that gets any large portion of the spam will have some > false positives. What is this, "you go to war with the army you have, not the army you want"? Thomas
