Re: Becoming a developer
Kenneth Scharf wrote: > The program is QSSTV (the ONLY slow scan TV program > that I know of that works on Linux.) As the name > implies, it is based on QT. It now (version 3.0m) > works with both qt1.44 and 2.0.2. It is also GPL'ed. > Hope it can go in main, or at least contrib. > The URL is > http://ourworld.compuserve/homepages/on1mh/qsstv No, it is QPLed, not GPLed. This is important because if it was GPLed it wouldn't be distributable. >From qsstv.cpp: > As this program is based on the Qt Free Edition, it is released under > Q Public Licence. Read this licence carefully before using, > distributing or modifying this program. Included with this > distribution is the QPL licence, a copy is also available at > www.troll.no -- Brian Kimball
Re: The nature of unstable (was: Danger Will Robinson! Danger!)
Steve Greenland: > > Hmm, it's ok for you to "misrepresent" other people's arguments, but not > > the other way around, as follows: Craig Sanders: > > > so why do you have a problem with infrastructure (i.e. package pools in > > > one form or another) which makes it easier to build a snapshot image? Steve Greenland: > > (And you *are* mispresenting my point, because you completely ignored > > the next paragraph where I spoke favorably about package pools.) Here's what Steve wrote: > > > > If you want to work on the unstable stuff, I think the > > > > package-pool implementation would good place to start. Craig Sanders: > notice that i asked questions. it up to you to confirm or deny or ignore > a question. Statements are confirmed or denied, not questions. Questions are answered. There's a gigantic difference between these two questions: "do you have a problem with infrastructure (i.e. package pools ...)?" "why do you have a problem with infrastructure (i.e. package pools ...)?" You wrote the latter, which clearly misrepresents what Steve wrote. You seem like a smart guy, so I can only assume you were being dishonest, and not just incompetent. Combine that with your selfishness, your arrogance, and your excessive, unnecessary, and juvenile obscenity, and here's what you get: *plonk* -- Brian Kimball
Re: Bug#60399: crashes on installation
Ben Collins wrote: > That simply produces a tarfile. I was suggesting to actually extract, > which unpacks the tarball itself. > > Anyway, if the problem is gone, it's going to be hard to track it > down. For the record, I did a clean install yesterday with the standard boot floppies and experienced the same problem during dselect's installation of all the standard packages. I hit enter and saw that on the second go around man-db unpacked just fine. I don't have a spare machine lying around and don't feel like hosing my man install so I can't go back and reproduce it. Any clean install would have the problem though, I guess. (BTW, at what point should we trim To: and Cc:? If I had sent this to just the bug database and debian-devel would that have been enough to have it propogate to the right people?) -- Brian Kimball
Re: Should MUA only Recommend mail-transfer-agent?
Eduard Bloch wrote: > It is allowing _few_ users to work around a dependency > which makes sence for everybody else, but is not really useful for > _those_ few users in their special environment. What few users? What special environment? Can anyone provide a real world example of a Debian system that will have mutt but no mta (or other package that depends on an mta)? This is all seems very contrived.
Re: [Fwd: major problem with gnome-games dependency]
Ben Armstrong wrote: > This property of metapackages has always irked me. If I install > gnome and then remove gnome-games, I won't automatically benefit in > the next release from any other goodies the gnome maintainers have > added to "gnome" package. Amen brother. Why aren't metapackages using Recommends instead of Depends? It seems like that would solve this, at least for us aptitude users. brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating scanners and filters in Debian stable (3.1)
On Wednesday 06 October 2004 04:12 pm, Thomas Bushnell BSG wrote: > For example, a new set of virus definitions, we are told, may include > a new library and a new strategy for catching viruses. Makes sense > to me. But when you add that, are you just going to add in the > latest upstream version of the virus-catcher? In which case, you are > *also* going to be adding in new substantive features, like say a new > command-line syntax, or a new interface to the mail system, or other > things that are not connected to catching a new category of viruses. > > It is *those* changes which are not allowed for security updates, and > should not be allowed for these packages either. Who wants to install Spamassassin-more-than-2-but-not-quite-3? Snort-more-than-2.2-but-not-yet-2.3? This will just confuse your users and piss off upstream. Oh, and how many new bugs will you create when you have to backport large chunks of code to avoid those "dreaded" new features that your users couldn't possibly want? Either 1) allow new features when appropriate, 2) speed up the release cycle, or 3) leave this as a job for the unofficial repositories. cheers, brian
