Re: magnetic synchronous motor water pumps
On Wed, 8 Mar 2000, Jules Bean wrote: > Faking mail is not something which should be undertaken trivially. Well call it "fudging", if you will. ;) > Making valid and useful actions impossible is not the way to fight > spam. To fight spam, our spam-masters work quite hard to block open > relays, etc. Alright, I really don't care as long as I don't get it in my mailbox. ;-) > One possible technique we could employ is to require that the list > address appear visibly in the headers (to: or cc:). This would > prevent Bcc'ing the lists which is a shame (and care would need to be > taken with -private, which is also security), but it might be worth > it. This is hardly a real solution. Spammers still could post stuff to the list. Do you use Orbs? -- "Fool me seven times, shame on you. Fool me eight or more times, shame on me." -- Amy
Re: aptitude
On Wed, Mar 08, 2000 at 08:26:00AM -0500, Daniel Burrows was heard to say: > > What gets me is that aptitude, apt-get, deselect, and gnome-apt all > > seem to give slightly different info on which packages > > are broken, will be deleted, or are on hold. Are the > > dependancy rules interperted differently between these > > programs? > > dselect probably uses a totally different algorithm from the others > > As for the apt-based programs: there are a number of ...argh..I need to get more sleep. Anyway, if you're talking about what happens when you modify a package state, there are a couple of variables that control what happens and a couple of different notions of "broken". For example, you can test separately whether a package is broken now or will be broken after all installs and so on are run. After fiddling with the options a little, I decided to display packages as 'broken' in either case. Selecting packages can also just select that package or select all its dependencies and remove conflicts. I don't remember what gnome-apt or console-apt do in this regard; to turn this behavior on in aptitude (which I don't like as it has hard-to-see side effects), set Aptitude::Auto-Install to "true" in /etc/apt/apt.conf. Also, aptitude tries by default to fix any broken packages, but doesn't use one of the canned routines (I tried and they didn't work well for my purposes..any suggestions on how to go back to them are accepted :) ) -- instead it directly accesses the problem-resolution code. Unfortunately that was a while ago and I don't remember precisely what the problem with pkgFixBroken and friends.. Daniel -- It is hard to think of anything less sentient than a pumpkin. -- Terry Pratchett, _Witches Abroad_
Re: magnetic synchronous motor water pumps
On Wed, Mar 08, 2000 at 02:43:37PM +0100, Nils Jeppe wrote: > On Wed, 8 Mar 2000, Jules Bean wrote: > > > Making valid and useful actions impossible is not the way to fight > > spam. To fight spam, our spam-masters work quite hard to block open > > relays, etc. > > Alright, I really don't care as long as I don't get it in my mailbox. ;-) Delete it. It's not that hard. The spammers win if you waste time talking about them. If you just delete the mails immediately, it's easy. > > > One possible technique we could employ is to require that the list > > address appear visibly in the headers (to: or cc:). This would > > prevent Bcc'ing the lists which is a shame (and care would need to be > > taken with -private, which is also security), but it might be worth > > it. > > This is hardly a real solution. Spammers still could post stuff to the > list. > But they never do. [Most] Auto-spam software can't be bothered to fake the headers for all 100,000 recipients, so they send the same body 100,000 times. > > Do you use Orbs? Ask the listmasters. I dunno. -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: Consistant Keyboard Configuration (was Re: Another packages wishlist)
On Tue, Mar 07, 2000 at 04:40:12PM +, Jules Bean wrote: > The problem in fact turned out to be that the stuff in > /etc/X11/Xsession which groks the /etc/X11/Xresources directory is > relatively new, ^^ Time to break out the flashlights and the moving trains. This transition occurred over a year ago. > and my /etc/X11/Xsession had been diverted by some > copy of kdebase which I installed a while ago, and had long since > purged (but it naughtily didn't clean up the diversion in the removal > scripts). Another reason why kdm should be split from kdebase, and another reason people should be assiduous about filing bugs against the KDE packages. -- G. Branden Robinson| We either learn from history or, Debian GNU/Linux | uh, well, something bad will happen. [EMAIL PROTECTED] | -- Bob Church roger.ecn.purdue.edu/~branden/ | pgpirzTpnEL5i.pgp Description: PGP signature
Re: Packages to remove from frozen
On Tue, Mar 07, 2000 at 11:26:12PM -0500, Michael Stone wrote: > How is it right to spit out an error message on every connection that > adds nothing to most people's use of the product? Especially when there > exists a verbose mode for people who want lots of gory details about the > efficacy of their connection? SSH doesn't tell me the key length of > connections *except* in this one case--which is not consistent, and > which is not unambiguously "*right*" behavior. I disagree with your analysis, but nevertheless... Use the Source, Luke. Quit whining and start coding. -- G. Branden Robinson|A celibate clergy is an especially good Debian GNU/Linux |idea, because it tends to suppress any [EMAIL PROTECTED] |hereditary propensity toward fanaticism. roger.ecn.purdue.edu/~branden/ |-- Carl Sagan pgpZfjGUNDsxY.pgp Description: PGP signature
Re: Packages NOT removed from frozen
On Wed, 8 Mar 2000, Ben Collins wrote: > > On Wed, Mar 08, 2000 at 11:59:41AM +0100, Santiago Vila wrote: > > > If we drop perl-5.004, is there a good reason why we do need to rename > > an essential package? (from perl-base to perl-5.005-base). > > > > I understand this was made to be able to install several releases of > > perl at the same time, but: Is this really worthy? Why do we need several > > releases of perl? The latest and the greatest should work with every app. > > It will make the next upgrade easier than this last one. So when 5.006 > comes out, we wont have to rengineer the whole package setup again. But we don't need 5.004 and 5.005 in the system at the same time in potato. If this is not needed for the 5.004 to 5.005 transition, why is it going to be needed for the 5.005 to 5.006 transition? Do we ever plan to release a distribution having a perl-in-the-middle-of-an-unfinished-transition? -- "8a170246cf9ffde92f90a48ebaa32665" (a truly random sig)
Re: Packages to remove from frozen
On Tue, Mar 07, 2000 at 11:26:12PM -0500, Michael Stone wrote: > On Tue, Mar 07, 2000 at 03:13:36PM -0800, Joey Hess wrote: > > Michael Stone wrote: > > > Not very backward-compatible, is it? In some environments it's desirable > > > to have the software behave the same on every platform; even if it's > > > buggy, the bugs need to be consistent. > > > > This is linux. We break backwards compatability if we have to do do things > > *right*. > > How is it right to spit out an error message on every connection that > adds nothing to most people's use of the product? Especially when there > exists a verbose mode for people who want lots of gory details about the > efficacy of their connection? SSH doesn't tell me the key length of > connections *except* in this one case--which is not consistent, and > which is not unambiguously "*right*" behavior. Eh, well, it is correct[1] behavior to toss out an error message in this case since it's notifying you of a *security* problem. In fact, it's telling you that the server key is half as secure as the server claims it is. If you and your users don't care about security then I'm sure the error is a real pain in the ass. Of course, if security isn't an issue then you really don't need to use ssh at all. Generally you complain about issues that have relevance. I think you've missed on this one. Cheers, -- Nathan Norman "Eschew Obfuscation" Network Engineer GPG Key ID 1024D/51F98BB7http://home.midco.net/~nnorman/ Key fingerprint = C5F4 A147 416C E0BF AB73 8BEF F0C8 255C 51F9 8BB7 [1] "Right" describes a direction, specifically the one opposite "left". pgpFY4jPH9kRJ.pgp Description: PGP signature
Re: Packages NOT removed from frozen
On Wed, Mar 08, 2000 at 03:53:13PM +0100, Santiago Vila wrote: > On Wed, 8 Mar 2000, Ben Collins wrote: > > > > On Wed, Mar 08, 2000 at 11:59:41AM +0100, Santiago Vila wrote: > > > > > If we drop perl-5.004, is there a good reason why we do need to rename > > > an essential package? (from perl-base to perl-5.005-base). > > > > > > I understand this was made to be able to install several releases of > > > perl at the same time, but: Is this really worthy? Why do we need several > > > releases of perl? The latest and the greatest should work with every app. > > > > It will make the next upgrade easier than this last one. So when 5.006 > > comes out, we wont have to rengineer the whole package setup again. > > But we don't need 5.004 and 5.005 in the system at the same time in potato. > If this is not needed for the 5.004 to 5.005 transition, why is it going > to be needed for the 5.005 to 5.006 transition? > > Do we ever plan to release a distribution having a > perl-in-the-middle-of-an-unfinished-transition? s/upgrade/transition/ By this I mean that it is needed the same way libraries are needed for transition. So we don't dump in 5.006, and then make all the 5.005 dependant things broken until they are recompiled. No, I don't think it is needed for releases, but mid-release transitions are important. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Packages NOT removed from frozen
I decided against removing the following packages because of unwelcome consequences. This list does not include packages that were not removed because they were fixed. Package: emacs19 (debian/main). Maintainer: Mark W. Eichin <[EMAIL PROTECTED]> 57636 gnus under emacs19 opens files in /tmp insecurely [Also takes out w3-el-e19, vm, emacs19-el, emacs-czech] Removing w3-el-e19 means removing all of w3-el, because it's a multi-binary package. That's a bit extreme, and I'd rather give Joey a bit more time to fix emacs19. Package: pdl (debian/main). Maintainer: Raul Miller <[EMAIL PROTECTED]> [Arch-specific, Raul doesn't know how to fix] 55268 [Strategy: use older version on alpha] PDL fails to compile on alpha [I may just remove the alpha package for this one] gimp1.1-perl depends on pdl, and gimp1.1-perl is part of gimp1.1. So removing this package means removing all of gimp1.1 and everything that depends on it. That's a bit too much. Package: tclx76 (debian/main). Maintainer: Philippe Troin <[EMAIL PROTECTED]> 56541 tclx76: cannot install [Also takes out tclx76-dev, emacspeak? and emacspeak-ss?] emacspeak depends on an impressive array of tclx packages, but tclx76 seems to be the last one we have. (I found no trace of tclx80). The situation was a bit too complex for me to investigate today. Richard Braakman P.S. I now live and work in Helsinki, but I don't have an internet connection at home yet (or, in fact, anything other than a bed). (IKEA, it's still in a box that looks far too small for its supposed contents). This is the reason for my recent slowness.
Re: Packages removed from frozen
Richard Braakman wrote: > I removed these packages from frozen today. > Package: xexec (debian/contrib). > Maintainer: Zed Pobre <[EMAIL PROTECTED]> > [Also removed from unstable] > 56762 xexec: GPLed software linked against non-compatible Qt2 According to this short description it needs to be removed entirely. Regards, Joey -- Let's call it an accidental feature. --Larry Wall Please always Cc to me when replying to me on the lists.
Re: aptitude
Just take my comments as a wish list for the future, I know this stuff is still alpha grade (but still very usefull). Nice thing about debian is that it not only has a bullet resistant package manager (not bullet proof as per some of the slink->potato upgrade horror stories I've been reading), but several different front ends. Gnome-apt looks good too, (but has a bug in that the 'terminal window' that shows the 'action' goes black after one screenfull scrolls up). I installed potato from scratch on a computer via the web (had to install the 'base' from floppies 'cause I couldn't get apt to use a proxy at first to see though a firewall) but got the rest via apt-get, dselect, gnome-apt, and aptitude. (can mixing package manager frontends screw up things?) Anyway it is LOOKING GOOD! Goodluck with the un-freeze process! --- Daniel Burrows <[EMAIL PROTECTED]> wrote: > On Wed, Mar 08, 2000 at 05:07:29AM -0800, Kenneth > Scharf was heard to say: > > I've been following this list (on and off) as I > have > > been using potato and uploading updated pacakges > > daily. I didn't even know about aptitude until I > read > > about it here, so I went and got it. Except for > the > > lack of a man page, --help option, or online key > > binding key it is a neat program. > > (/me cops out by pointing at the two zeros in > front of the version number) > > > What gets me is that aptitude, apt-get, deselect, > and gnome-apt all > > seem to give slightly different info on which > packages > > are broken, will be deleted, or are on hold. Are > the > > dependancy rules interperted differently between > these > > programs? > > dselect probably uses a totally different > algorithm from the others > > As for the apt-based programs: there are a number > of > > > Also how do you undo the result of the "f" key. > > You can't undo the 'f' key in the most recently > released version. Undo > support is sort of in CVS, but I need to fix it > before I release 0.0.7 > version. (and I have two major school projects due > in the near future, so it's > unlikely to happen soon (read: in the next week) :( > ) > > > Anyway if someone adds an online help key to > aptitude > > it would make a great replacement for deselect. > > (Looks great in color). > > The most recent version (0.0.6a, missed the potato > freeze) has online help, > although it's not very friendly (I just used the > README) 0.0.7 is mainly > a large amount of internal restructuring and > bugfixes and the addition of undo > support. 0.0.8 will hopefully address a number of > issues which have been > brought up in the last few days. > > Daniel > > -- > The New Testament offers the basis for modern > computer coding theory, > in the form of an affirmation of the binary number > system. > > But let your communication be Yea, yea; nay, > nay: > for whatsoever is more than these cometh of > evil. > -- Matthew 5:37 > = Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: Packages to remove from frozen
On Wed, Mar 08, 2000 at 08:56:34AM -0600, Nathan E Norman wrote: > Eh, well, it is correct[1] behavior to toss out an error message in this > case since it's notifying you of a *security* problem. In fact, it's > telling you that the server key is half as secure as the server claims > it is. But you *don't* get informed about what the server claims the key is unless you request verbosity. This isn't about displaying wrong info versus displaying right info. This is about displaying extra information for no reason. If the notice that the server was offering an invalid key length came in verbose mode, that would be great; if you got a warning when you first accept the key, that would be useful. What does seeing the message at every login buy you? > If you and your users don't care about security then I'm sure the > error is a real pain in the ass. Of course, if security isn't an > issue then you really don't need to use ssh at all. Are you really convinced that the security of a 1023 bit key is so much worse than the security of a 1024 bit key that any amount of effort necessary to transition to a new 1024 bit key is justified? In the overall scheme of things, that one bit is *not* a high-priority security problem. Changing keys around and getting users into the habit of replacing host keys is a *bigger* security problem than that stupid bit. -- Mike Stone pgpOaT7MmEkRB.pgp Description: PGP signature
Re: Packages to remove from frozen
On Wed, Mar 08, 2000 at 09:18:06AM -0500, Branden Robinson wrote: > Use the Source, Luke. Quit whining and start coding. Why? On hosts where this is an issue, f-secure's ssh does the job just fine. (Not to mention that I don't live in a free country and can't work on ssh...) -- Mike Stone pgpQc9EIx2b7L.pgp Description: PGP signature
Re: Packages to remove from frozen
In Wed, 8 Mar 2000 11:10:11 -0500, de profundis Michael Stone <[EMAIL PROTECTED]> cum veritas scribat mstone> Are you really convinced that the security of a 1023 bit key is so much mstone> worse than the security of a 1024 bit key that any amount of effort mstone> necessary to transition to a new 1024 bit key is justified? In the Isn't it that to decrypt 1024 key takes double the amount of CPU time than decrypting 1023 key, as long as there is no other method than brute-force method of trying every combination. IMO It is a serious security issue, when the system is half as secure and one is not notified. And the person is trying to use a ssh. --- dancer, a.k.a. Junichi Uekawa Dept. of Knowledge Engineering and Computer Science, Doshisha University. ... Long Live Free Software, LIBERTAS OMNI VINCIT.
Re: Packages removed from frozen
On Wed, Mar 08, 2000 at 03:56:51PM +0100, Richard Braakman wrote: > Package: transproxy (debian/main). > Maintainer: Adam Heath <[EMAIL PROTECTED]> > 56998 transproxy: daemon does not start What needs to be done to get this back into frozen? I've still got a machine running this. Or is there any other package better suited for redirecting direct web traffic to squid? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Re: Packages to remove from frozen
On Thu, 9 Mar 2000, Junichi Uekawa wrote: > Isn't it that to decrypt 1024 key takes double the amount of > CPU time than decrypting 1023 key, as long as there is no other > method than brute-force method of trying every combination. > > IMO It is a serious security issue, when the system is half as secure > and one is not notified. And the person is trying to use a ssh. Where 'n' is a "reasonable" amount of time to crack a key using brute-force, doubling 'n' does not equate to doubling the security of your system. At the most, you have caused the cracker the minor annoyance of having to wait twice as long for a result. Conversely, if '2n' is an "unreasonable" amount of time to crack a key using brute-force, halving it to 'n' does not equate to halving the security of your system. In other words, I rely on my ssh keys being several orders of magnitude more difficult to crack than weaker crypto that is crackable in a "reasonable" amount of time by brute force. Whether the keys are 1023 bit or 1024 bit is irrelevant. Both accomplish this goal. Ben -- nSLUG http://www.nslug.ns.ca [EMAIL PROTECTED] Debian http://www.debian.org [EMAIL PROTECTED] [ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] [ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
Re: magnetic synchronous motor water pumps
On Wed, Mar 08, 2000 at 07:55:49AM +0100, Nils Jeppe wrote: > > Can we please close the list from non-member submissions? This is not > the first spam that's come over debian-devel recently. Or set up that : - reply to thread can be done from anyone - new thread can be started by a) member b) non-member after mail is checked by someone
mod_perl unhappy with libxml-parser-perl
I have noticed a conflict between the versions of Expat in apache-perl 1.3.9.10-1.21-6 and libxml-parser-perl 2.27-6 that causes memory corruption. I assume that the DSO apache-1.3.9/libapache-mod-perl 1.21 in potato is similarly affected, as I first started getting segfaults when running under that version. The problem arises because the "expat-lite" version of the expat library is compiled into apache without defining XML_DTD. The libExpat.so in libxml-parser-perl is compiled with XML_DTD defined, which, among other things, changes the size and composition of various data structures. If an object is allocated by the expat-lite code, accesses to it from the libxml-parser-perl code can clobber memory. I can think of several ways to solve the problem: (1) Delete the expat-lite directory from the Apache build tree, or disable it somehow. Pro: simple. Con: perhaps somebody needs it. (2) Make the expat-lite version compile with XML_DTD defined also, so it is compatible with the libxml-parser-perl version. Pro: saves expat-lite in Apache. Con: fragile; perhaps there are other incompatibilities, even some insoluble ones due to Apache forking Expat. (3) Use preprocessor hackery to rename the symbols in the expat-lite version, so there is no possibility of code mixing and matching. Pro: Solves the Cons of the first two options. Con: more difficult to do, introduces what could be viewed as a gratuitous incompatibility with the mainstream Apache distribution. -- Robert Coie Implementor, Apropos Ltd.
Re: Bug#59907: emacs19: Unable to update to latest release
Michael Stevens wrote: > Package: emacs19 > Version: 19.34-21 > > Hi. > Unable to update to latest stable release -- typescript > of failure attached. > > Script started on Wed Mar 8 11:43:42 2000 > [EMAIL PROTECTED]:[1m~[m# [Kaapt-get upgrade > Reading Package Lists... 0%Reading Package Lists... 100%Reading Package > Lists... Done > Building Dependency Tree... 0%Building Dependency Tree... 0%Building > Dependency Tree... 50%Building Dependency Tree... 50%Building Dependency > Tree... Done > The following packages have been kept back > emacs20 emacs20-el > 1 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded. > 12 packages not fully installed or removed. > Need to get 0B/5307kB of archives. After unpacking 2048B will be used. > Do you want to continue? [Y/n] y > (Reading database ... 54937 files and directories currently installed.) > Preparing to replace emacs19 19.34-21 (using .../emacs19_19.34-21.1_i386.deb) > ... [..] > Unpacking replacement emacs19 ... > dpkg: error processing /var/cache/apt/archives/emacs19_19.34-21.1_i386.deb > (--unpack): > trying to overwrite `/usr/man/man1/ctags.1.gz', which is also in package > exuberant-ctags > dpkg-deb: subprocess paste killed by signal (Broken pipe) [..] I remember seing this at the slink release. What is the proposed action now? Regards, Joey -- Let's call it an accidental feature. --Larry Wall
Re: magnetic synchronous motor water pumps
On Wed, Mar 08, 2000 at 02:43:37PM +0100, Nils Jeppe wrote: > > One possible technique we could employ is to require that the list > > address appear visibly in the headers (to: or cc:). This would > > prevent Bcc'ing the lists which is a shame (and care would need to be > > taken with -private, which is also security), but it might be worth > > it. > > This is hardly a real solution. Spammers still could post stuff to the > list. Still, large portion of them do use Bcc:, IME - I have been filtering my mail on the same rule for ages, and I notice all mails that escape it, and those that are really personal/wanted mail, but don't escape it - the ratio is satisfactory. -- enJoy -*/\*- don't even try to pronounce my first name
PHP4 Beta 4
Hi, I have a question concerning the meaning of "Beta", "stable" and "frozen" and all that stuff. The current Potato tree contains the PHP4 Beta 3 Package. The woody tree contains the PHP4 Beta 4 PL1. Does that mean, that Potato will stay on Beta 3? Or is there a chance that Potato will contain the final version of PHP4? What if potato is released and PHP4 leaves the beta state a week later. Will there be an update for Potato? Or is a stable Beta version more stable than a final version? Bye K (PGP: 0xCBB1FD6B)
RE: 2.1r5 Master file
On 08-Mar-2000 Jim Westveer wrote: Anyone know how to get a message to Ben Pfaff <[EMAIL PROTECTED]> ??? his package w3-el-e20 in slink, needs to be updated for 2.1r5. [EMAIL PROTECTED] -- .forwards to [EMAIL PROTECTED] [EMAIL PROTECTED] -- bad email addr -- Jim Westveer <[EMAIL PROTECTED]> "Bother," said Pooh as he struggled with sendmail.cf. "It never does quite what I want." "I wish Christopher Robin were here.". E-Mail: Jim Westveer <[EMAIL PROTECTED]> phone 425-591-3002 fax 425-557-0660 Date: 08-Mar-2000 URL lcs.issaquah.wa.usTime: 11:55:36 Random number = DC 49 E8 7E 76 DD 30 2D 8D F1 B4 D8 A3 60 4C 04
spamblocking the lists
Jules Bean wrote: > > On Wed, Mar 08, 2000 at 10:45:07AM +0100, Nils Jeppe wrote: > > On Wed, 8 Mar 2000, Stephane Bortzmeyer wrote: > > > > > > Can we please close the list from non-member submissions? > > > > > > NO! > > > I, like many users of Debian, post from different mail addresses. Lists > > > which are closed that way are really painful. So sign on with multiple addresses and set all but one nomail. It's ludicrous to subject everyone to spam just to make things convenient for a minority of users, especially if a fix exists that only those people affected by the spamblock will have to implement. jpb -- Joe Block <[EMAIL PROTECTED]> CREOL System Administrator Social graces are the packet headers of everyday life.
Re: Packages removed from frozen
In article <[EMAIL PROTECTED]>, Michael Meskes <[EMAIL PROTECTED]> wrote: >On Wed, Mar 08, 2000 at 03:56:51PM +0100, Richard Braakman wrote: >> Package: transproxy (debian/main). >> Maintainer: Adam Heath <[EMAIL PROTECTED]> >> 56998 transproxy: daemon does not start > >What needs to be done to get this back into frozen? I've still got a machine >running this. Or is there any other package better suited for redirecting >direct web traffic to squid? It's been a long time since I tried it, but IIRC you do not need a special extra package to do transparent proxying with squid - squid can do it all itself. In fact I must RC, since I wrote the extensions for squid myself ;) Read /usr/share/doc/squid/README.transparent-proxy.gz Mike. -- #define ESPANISHINQ 1478/* Expect the Spanish Inquisition */
Re: Ghostscript 6.0
On Tue, Mar 07, 2000 at 08:19:47AM -0500, Branden Robinson wrote: > As I understand it, pdftotext is a new tool available in 5.5 but not 5.0. AFAIK pdftotext is included in xpdf - it's not part of gs 5.5. The differences between 5.10 and 5.50 are not that big and I do not want to risk a stable package just for being up to date. If anybody here is very interested in it please speak up and we will get something arranged. Otherwise I will just continue my work on gs 6.0 (it changed quite a bit compared to 5.5) and upload that to unstable when I am done. > I think this is a significant and useful addition (for all I know, 5.0 > might not support PDF at all). It's 5.1 and it supports pdf. > If that is true, I think it merits inclusion of 5.5 in main for potato, as > .pdf is a *very* widespread document format. > > If I'm mistaken about all this, then perhaps it isn't so urgent. My impression is that it is not very urgent (I switch between both gs packages from time to time and do not feel there is anything different). Thanks Torsten -- Torsten Landschoff [EMAIL PROTECTED] <[EMAIL PROTECTED]> Debian Developer and Quality Assurance Committee Member
dpkg: start-stop-daemon should check that the daemon has stopped
Package: dpkg Version: 1.6.9 Severity: wishlist There have been two bug reports submitted this week (Bug#59321 against dictd and Bug#59321 against pipsecd) that were caused by calling start-stop-daemon with -start immediately following a start-stop-daemon call using -stop. Occasionally the daemon has not been stopped when the start command is received. If the --quiet option has been used with start-stop-daemon, no error message is emitted. Both bugs were fixed by inserting a sleep command between the --stop and --start commands. This is not a guaranteed solution, however. If the system is busy and if the daemon has been swapped out, it might take an undetermined amount of time for it to shutdown. One solution would be for start-stop-daemon to wait on the PID of the process being killed, with a time limit so it would not hang if a process refused to shutdown when signalled. -- System Information Debian Release: 2.2 Kernel Version: Linux bobspc 2.2.12 #1 Tue Oct 12 14:21:00 EDT 1999 i586 unknown Versions of the packages dpkg depends on: ii libc6 2.1.3-5GNU C Library: Shared libraries and Timezone ii libncurses55.0-5 Shared libraries for terminal handling
ITP: gnofract
Hi! I've packed gnofract, a small gnome fractal generating program. I am not a debian developer yet, so I'll need a sponsor to upload this package. Futhermore, this is my first Debian package, so I'd appriciate it if somebody would check whether the package is all right and whether I did everything ok. Gnofract is written by Aurélien Alleaume, it's homepage is at http://www.multimania.com/mason, and it is licenced under the GPL. I've put the packages on http://medeia.dhs.org/~bas/Debian/gnofract/ Package: gnofract Version: 0.2-1 Section: x11 Priority: optional Installed-Size: 88 Description: a simple gnomish fractal browser gnofract is a gnome fractal browser. It lets you zoom in to and move through fractals. -- cu, dex. - ``As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality.'' Albert Einstein -
Secret Holy Code revealed to Seekers of Truth!
- This ad is being sent in compliance with Senate bill 1618, Title3, section 301. http://www.senate.gov~murkowski/commercialemail/S771index.html Further transmitions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line. - SECRET HOLY CODE REVEALED ALL GENUINE SEEKERS OF TRUTH. Esoteric Sacred Knowledge! Most fascinating web site on the Internet! Please see: www.webruler.com/torah Thank you!
Re: spamblocking the lists
On Wed, 8 March 2000 15:28:37 -0500, Joe Block wrote: > So sign on with multiple addresses and set all but one nomail. It's > ludicrous to subject everyone to spam just to make things convenient for > a minority of users, especially if a fix exists that only those people > affected by the spamblock will have to implement. nomail is not possible with smartlist, is it? Alexander -- heh, Nat Torkington says Perl's internals are "an interconnected mass of livers and pancreas and lungs and little sharp pointy things and the occasional exploding kidney." Alexander Koch - <>< - WWJD - aka Efraim - PGP 0xE7694969 - ARGH-RIPE
