Re: spamblocking the lists
On Wed, Mar 08, 2000 at 03:28:37PM -0500, Joe Block wrote: 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. [meta: this question is inappropriate for this list, but I can't resist answering. Maybe we need a debian lists FAQ] There are a variety of perfectly valid reasons to post to a list you aren't subscribed to. From time to time, interested members of the free software community cc: an email to debian-devel because they want to alert us to some issue which is relevant. I very, very rarely get spam through -devel (or any debian list) and I don't have a problem with the current system. If spam is too much, then the solution, I suggest is to use the various blocking lists (maybe we do) and just possibly, in extremis, require explicit addressing as I suggested earlier. Jules -- Jules Bean |Any sufficiently advanced [EMAIL PROTECTED],jellybean.co.uk} | technology is indistinguishable [EMAIL PROTECTED] | from a perl script
Re: magnetic synchronous motor water pumps
On Wed, 8 Mar 2000, Josip Rodin 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. As an additional requirement, you could limit the possible number of To: addresses to 10. This way, a spammer needs to send out different messages, so he/she/it has to send multiple messages over his personal dialup connection. I'm using these rules on my lists here, and I've never had any spam on them, even if the submission addresses are publicized on the web. Simon PGP public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: Secret Holy Code revealed to Seekers of Truth!
I rest my case. ;-) Best wishes, Nils -- Fool me seven times, shame on you. Fool me eight or more times, shame on me. -- Amy
Re: mesag3 vs libgl1 (Utah-GLX)
Previously J.H.M. Dassen Ray wrote: I hardly think lack of hardware acceleration support warrants making these bug reports release-critical. Please set them to 'normal'. Actually they were already filed as release-critical earlier, and are probably needed anyway since we have mega-ggi packages as well. Wichert. -- _ / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpjedWCBnUtC.pgp Description: PGP signature
Re: Ghostscript 6.0
On Wed, Mar 08, 2000 at 05:25:42PM +0100, Torsten Landschoff wrote: 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. Eh? There would be no real code changes at all. As I understand it, the license on 5.5 is all that has changed. So why not move it from non-free to main for potato? -- G. Branden Robinson| The first thing the communists do when Debian GNU/Linux | they take over a country is to outlaw [EMAIL PROTECTED] | cockfighting. roger.ecn.purdue.edu/~branden/ | -- Oklahoma State Senator John Monks pgp4wU2hX8LUi.pgp Description: PGP signature
Re: mesag3 vs libgl1 (Utah-GLX)
On Thu, Mar 09, 2000 at 03:08:31PM +1100, Wichert Akkerman wrote: Previously J.H.M. Dassen Ray wrote: I hardly think lack of hardware acceleration support warrants making these bug reports release-critical. Please set them to 'normal'. Actually they were already filed as release-critical earlier, and are probably needed anyway since we have mega-ggi packages as well. mesag3-glide and mesag3+ggi both Provides: mesag3 This was done to make the transition easier. Since the glx packages didn't get into potato, I didn't see a point in forcing the issue when we were so close to the freeze. Once potato is released, we will work on getting all the packages updated. -- James (Jay) Treacy [EMAIL PROTECTED]
ITP sqmgrlog - report generation utility for squid
Unless someone else has beat me to it (and I missed it) I'm going to be uploading soon sqmgrlog. Sqmgrlog generates reports per user/ip/name from squid log file. Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD pgpBY5n7hELET.pgp Description: PGP signature
Re: magnetic synchronous motor water pumps
On Wed, 8 Mar 2000, Stephane Bortzmeyer wrote: On Wednesday 8 March 2000, at 7 h 55, the keyboard of Nils Jeppe [EMAIL PROTECTED] 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. Register each of those addresses and either set them to not receive mail or filter it to /dev/null and file a bug against the lists if they don't have that ability. That's what I make everyone do for the lists I admin. As an admin I have to clean up some of the things that get caught, but one would hope -devel at least would have savvy members :). Personally I use roles to help keep things straight. That can be difficult if you don't operate off your own box. ciao, der.hans -- # +++=+++ # # [EMAIL PROTECTED] www.excelco.com # #http://home.pages.de/~lufthans/ # # I'm not anti-social, I'm pro-individual. - der.hans # # ===+=== #
Re: Packages to remove from frozen
isn't the problem here that the server is misrepresenting itself? a one bit difference may not make a less secure key, but it could quite possibly be an indication of some deception. i worry that altering the client to ignore this type of error will only open us up to attack, be it man-in-the-middle or otherwise. Ben Armstrong ([EMAIL PROTECTED]) wrote: 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 ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Secret Holy Code revealed to Seekers of Truth!
On Wed, 8 Mar 2000, it was written: SECRET HOLY CODE REVEALED ALL GENUINE SEEKERS OF TRUTH. I don't know. Is this dfsg-compliant? -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: Ghostscript 6.0
On Wed, 8 Mar 2000, Branden Robinson wrote: 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. Eh? There would be no real code changes at all. As I understand it, the license on 5.5 is all that has changed. So why not move it from non-free to main for potato? The Release Notes of GNU ghostscript 5.50 say: The content of GNU Ghostscript 5.50 is Aladdin Ghostscript 5.50 with two enhancements: - Approximately a dozen bug fixes that were posted on the Web site after the release. - The expanded URW++ fonts with the full Adobe PostScript 3 character set (the additions are mostly Eastern European characters). cu, Adrian -- A No uttered from deepest conviction is better and greater than a Yes merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
Re: Does dpkg-divert work on conf files?
Wichert == Wichert Akkerman [EMAIL PROTECTED] writes: Wichert Okay. In theory this works fine, however its not (very Wichert well) tested. If you try this I'm very interested to Wichert hear if it really works.. The problem with diverting Wichert conffiles is that scripts (such as postinst) will still Wichert use the old location, so you have to be careful. I think scripts should never modify conffiles anyway... It is in the packaging manual: Note that a package should not modify a dpkg-handled conffile in its maintainer scripts. Doing this will lead to dpkg giving the user confusing and possibly dangerous options for conffile update when the package is upgraded. I seem to remember often getting prompts for updating conffiles I never updated myself, so I guess at least some packages don't do this. (or if you meant configuration files in general, that is a different thing altogether, dpkg-divert wont work though unless it is a normal file or a conffile). -- Brian May [EMAIL PROTECTED]
Re: magnetic synchronous motor water pumps
Jules == Jules Bean [EMAIL PROTECTED] writes: Jules It is, for example, against the rules of the institution Jules I'm at (the university of cambridge) to emit mail with a Jules from: address other than a valid @cam.ac.uk from: Jules address. But when I'm at home, I use another address. This seems rather strict, there are valid reasons for doing this. the MTA should be able to add a Sender: address, too - have a look at this E-Mail for an example as to why you might want to use a different From: address. If anybody really wants to know where this message is getting sent from, it should be easy to check. -- Brian May [EMAIL PROTECTED] (who currently wants all Debian mail to be sent to [EMAIL PROTECTED] to aid sorting)
'lshell' as a shared object
(mail to Heiko Schlittermann [EMAIL PROTECTED] is bouncing; upon investigation you two appear to be mentioned in and around lshell so I'm sending this email to you and Cc:ing it to debian-devel for anyone else's perusal) Hi, I have code based on lshell, which you maintain for Debian, that implements the functionality as a shared object. I.e. you add a line such as /lib/rlimit.so to /etc/ld.so.preload, and you get magic support for resource limits in every dynamic executable. The code is based on lshell 2.01 but needs some polishing to come be able to parse the now-become-standard /etc/limits file. I was wondering if I do this (a trivial amount of work), are you interested in releasing a new lshell package in Debian? We may want to call it something else, or just give it a new version number. I don't believe any development has been done on lshell since 1996 so I think it's safe to say we can do that. (The reason I am writing now is that 3 years after I last touched this code, a friend has asked me for this exact functionality, which does not seem to exist in any other piece of software for linux.) You can see the obvious advantage in using code such as this; it makes it almost impossible to get around the limit settings by the user. Let me know what you think. Martin -- Martin Lucina http://www.kotelna.sk/mato/ Wellington, New Zealand I've always been mad I know I've been mad like the most of us are Pretty hard to explain why you're a madman even if you're not mad
tclx76 removed in favour of tclx8.0.4
James R. Van Zandt uploaded tclx8.0.4 to frozen and unstable today, with this in the changelog: * Replaces tclx76 which is no longer installable (closes:bug#56541) * Satisfy tclx dependency so emacspeak can be installed (closes:bug#59099) That takes care of my concerns with tclx76, so I've installed tclx8.0.4 and removed tclx76. The versions of tclx76 that I removed are still available in slink, so I didn't put any in project/orphaned. Richard Braakman
The headers of this spam suggest knowledge of debian server setup (was Re: Secret Holy Code revealed to Seekers of Truth!)
Hi, Also... could someone please forward me all logs in regard to this spam, as well as the original posting as it was received by the list (i.e., with all headers intact? I intend to take action on its basis. -Jim --- Jim Lynch Finger for pgp key as Laney College CIS admin: [EMAIL PROTECTED] http://www.laney.edu/~jim/ as Debian developer: [EMAIL PROTECTED] http://www.debian.org/~jwl/
Re: spamblocking the lists
On Wed, Mar 08, 2000 at 10:55:01PM +, Jules Bean 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. [meta: this question is inappropriate for this list, but I can't resist answering. Maybe we need a debian lists FAQ] There are a variety of perfectly valid reasons to post to a list you aren't subscribed to. From time to time, interested members of the free software community cc: an email to debian-devel because they want to alert us to some issue which is relevant. *nod vigorously* I very, very rarely get spam through -devel (or any debian list) and I don't have a problem with the current system. If spam is too much, then the solution, I suggest is to use the various blocking lists (maybe we do) and just possibly, in extremis, require explicit addressing as I suggested earlier. I guess you are not subscribed to debian-user-spanish. We get 1 or 2 daily. The rules described above, no Bcc: and limiting the to: addresses to 10 should work with us. None of the spam we get there has the debian-user-spanish@lists.debian.org header. There was a flame-thread about the convenience of closing the list to only-members, but I think that's a bad idea for the reasons you explain above. Now, can these rules be applied? We _really_ need them at the spanish list. Thanks Jordi -- Jordi Mallach Pérez || [EMAIL PROTECTED] || Rediscovering Freedom, ka Oskuro in RL-MUD || [EMAIL PROTECTED]|| Using Debian GNU/Linux http://sindominio.net GnuPG public information: pub 1024D/917A225E telnet pusa.uv.es 23 73ED 4244 FD43 5886 20AC 2644 2584 94BA 917A 225E pgpyJPN2cRzZy.pgp Description: PGP signature
Re: Packages to remove from frozen
On Thu 09 Mar 2000, Jacob Kuntz wrote: isn't the problem here that the server is misrepresenting itself? a one bit difference may not make a less secure key, but it could quite possibly be an indication of some deception. i worry that altering the client to ignore this type of error will only open us up to attack, be it man-in-the-middle or otherwise. Warning: my crypto knowledge is pretty poor. Someone somewhere in this thread said that the problem was that the old ssh could generate a key that had the MSbit off, and that was the cause of these messages. I'm now thinking: if the MSbit *MUST* be set, how does that increase the security? N bits of key is no less secure than N+1 bits where you know the value of one bit. Isn't openssh simply confused in this case? I myself notice that openssh complains about half the time when connecting to a random number of different hosts (I connect daily to a random 5-10 systems out of a collection 700 hosts (each running ssh 1.2.17), which IMHO means the sample is quite random, but then statistics lessons was a long time ago). Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
tiotest packaged, need sponsor
Hi, ive created a package of tiotest, which is a small relatively need benchmarking program being used a lot recently for raid benchmarks. Its the first package ive made, its only been packaged as i386, i havent tried getting it working on other platforms. Its a bit short on documentation, but if someone wants to look at it email me and ill send the package to you, its only 10KB Thanks Glenn McGrath
Re: Ghostscript 6.0
On Thu, Mar 09, 2000 at 06:59:01AM +0100, Adrian Bunk wrote: On Wed, 8 Mar 2000, Branden Robinson wrote: Eh? There would be no real code changes at all. As I understand it, the license on 5.5 is all that has changed. So why not move it from non-free to main for potato? The Release Notes of GNU ghostscript 5.50 say: The content of GNU Ghostscript 5.50 is Aladdin Ghostscript 5.50 with two enhancements: - Approximately a dozen bug fixes that were posted on the Web site after the release. Well, it would be good to have these! - The expanded URW++ fonts with the full Adobe PostScript 3 character set (the additions are mostly Eastern European characters). Given the fact that we have quite a few Eastern European users, this might not be a bad idea either. If dark would approve this, I think we should do it. I'd volunteer but I need to be occupying myself with XFree86 4.0. (They're on their second release candidate -- it is very close.) -- G. Branden Robinson| I am sorry, but what you have mistaken Debian GNU/Linux | for malicious intent is nothing more [EMAIL PROTECTED] | than sheer incompetence! roger.ecn.purdue.edu/~branden/ | -- J. L. Rizzo II pgpN9bOjURQlw.pgp Description: PGP signature
Re: Packages removed from frozen
On Wed, Mar 08, 2000 at 08:32:51PM +, Miquel van Smoorenburg wrote: 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 Okay, will check that. Just one question, my setup is that the firewall redirects all www queries except those coming from the proxy server to the transproxy daemon that than in turn ask the proxy whose connection is then allowed outwards. I've had problems with a similar setup when I tried using just ipchains and ipmasqadm to redirect some traffic. Since I didn't check in detail maybe there was just a typo on my side. But I wonder what's the best setup for a situation like this. ipchains/ipmasqadm or ipchains/ip with a special routing rule? 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!
better RSYNC mirroring , for .debs and others
hi everybody I have implemented a good idea for reducing download stress for everybody who is mirroring a lot of data using rsync, like, the people who are mirroring Debian GNU/Linux: currently, many Debian leaf mirrors are using rsync for mirroring from the main .debian.org hosts. rsync contains a wonderful algorithm to speedup downloads when mirroring files which have only minor differences; only problem is, this algorithm is ALMOST NEVER used when mirroring a debian repository ... indeed, whenever a new version of a package is entered in the debianrepository, this package has a different name: for this reason rsync does just a full download. Summarizing, rsync currently does some speedup only when it downloads Packages.gz files, or when it skips an already existing package. well, I have just implemented a simple way to use the algorithm even when downloading the .debs . here is a simple example suppose the current situation is $REMOTE::/pub/debian/dist/bin/dpkg_2.deb whereas locally we have /debian/dist/bin/dpkg_1.deb when rsync looks for a local version of /debian/dist/bin/dpkg_2.deb if there is none, then rsync does ls -t /debian/dist/bin/dpkg_* and looks for the most recent file it finds this way, rsync will use the file /debian/dist/bin/dpkg_1.deb to try to speedup the download of$REMOTE::/pub/debian/dist/bin/dpkg_2.deb (using its fabulous algorithm) BIG PRO: my new rsync is totally compatible with the old one Conclusion: this idea would make all debian mirror-people happier (specially if they mirror unstable; consider that, often, when a new version of a package is released, only small changes are made... sometimes, only the .postinst , or such, are really changed; this may , thou, masked by the compression, alas: but, see TODO) I attach two files: the first file is a diff, showing where, in the rsync 2.4.1 source code tree, I have done some modifications; the second is a .tgz of the all the new and modified files you need to build the new rsync: to build, first you need to download the source code (see rsync.samba.org/rsync/download.html) and then you unpack the file rsync.diffsrc.tgz in the tree code, and build. You may also get the compiled binary directly as ftp://tonelli.sns.it/pub/rsync/rsync and the new code alltogether in ftp://tonelli.sns.it/pub/rsync TODO: there are some potentially good ideas here: 1) the idea is to add modules to rsync: a gzip module, a deb module, and rpm module...; currently, modules just look for an older local version of the file; in a future version, any module would apply to a certain type of file, and create another file to pass to rsync so that this another file may probably lead to more speedup: e.g., the gzip module would unzip files before doing comparisons, and the deb module would unzip the data.tar.gz part of a package CONS: this would not be backward compatible, of course The idea is, a module may provide the following calls: find_alternative_version_MOD() receive_file_MOD() send_file_MOD() Currently, only find_alternative_version_deb() was implemented. If rsync uses only the find_alternative_version_MOD() calls, then it is backward compatible with the usual version: (in a sense , it is doing what the option --compare-dest already does, only in a smarter way) I have not currently implemented anyreceive_file_MOD() send_file_MOD() : these would need a change in the protocol: I hope that the rsync authors will give permission 1b) My idea (not sure) is that rsync may work if provided with named pipes instead of files: indeed, according to the technical report, it needs to read the local and remote files only once, and then, it writes the local file, without ever seeking backwards; then, the above modules would not need to actually use disk space and create temporary files. 2) for a faster apt-get downloading, it may be possible to do the same trick WHEN UPGRADING INSTALLED PACKAGES! Here is the idea: apt-get creates a local version of the package (using dpkg-repack) and do the rsync to get the remote version -- Andrea C. Mennucci, Scuola Normale Superiore, Pisa, Italy ? modules ? zlib/dummy Index: Makefile.in === RCS file: /cvsroot/rsync/Makefile.in,v retrieving revision 1.39 diff -r1.39 Makefile.in 24c24 lib/fnmatch.h lib/getopt.h lib/mdfour.h --- lib/fnmatch.h lib/getopt.h lib/mdfour.h modules/modules.h 32c32,33 OBJS=$(OBJS1) $(OBJS2) $(DAEMON_OBJ) $(LIBOBJ) $(ZLIBOBJ) --- MODULES_OBJ = modules/modules.o modules/deb.o OBJS=$(OBJS1) $(OBJS2) $(DAEMON_OBJ) $(LIBOBJ) $(ZLIBOBJ) $(MODULES_OBJ) Index: generator.c === RCS file: /cvsroot/rsync/generator.c,v retrieving revision 1.16 diff -r1.16 generator.c 19a20,23 #ifndef NODEBIANVERSIONER #include modules/modules.h #endif
Re: tiotest packaged, need sponsor
Seems ive been beaten to it. ftp://ftp.cm.nu/pub/debian/ Oh well, plenty more potential packages out there bug1 wrote: Hi, ive created a package of tiotest, which is a small relatively need benchmarking program being used a lot recently for raid benchmarks. Its the first package ive made, its only been packaged as i386, i havent tried getting it working on other platforms. Its a bit short on documentation, but if someone wants to look at it email me and ill send the package to you, its only 10KB Thanks Glenn McGrath -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian-devel@lists.debian.org
. . . 1. 2. 3. Enter Me!!
Re: Release-critical Bugreport for March 3, 2000
On Fri, Mar 03, 2000 at 03:15:05AM -0600, BugScan reporter wrote: Package: fetchmail (debian/main) Maintainer: Paul Haggart [EMAIL PROTECTED] [HELP] Maintainer is not responding. Someone should take over the package. (RB) 43139 fetchmail flushed after failed delivery [WAITING] Maintainer was contacted on Dec 12, awaiting reply. 48159 I had to downgrade to fetchmail_4.6.4-1.1 because I couldn't get my mail from the server! Fetchmail was able to query the IP of the server, but told me something about file not found. After downgrading fetchmail it worked without problems. I haven't touched any fetchmail relevant scripts! [WAITING] Maintainer was contacted on Dec 12, awaiting reply. 50990 fetchmail: mail was fetched and deleted from server but never sent to local MTA [WAITING] Maintainer was contacted on Dec 12, awaiting reply. I see today on freshmeat.net: application: fetchmail 5.3.1 author: Eric S. Raymond [EMAIL PROTECTED] license: GPL category: Console/eMail urgency: low homepage: http://apps.freshmeat.net/homepage/884576388/ download: http://apps.freshmeat.net/download/884576388/ description: Fetchmail is a free, full-featured, robust, well-documented remote-mail retrieval and forwarding utility intended to be used over on-demand TCP/IP links (such as SLIP or PPP connections). It supports every remote-mail protocol now in use on the Internet: POP2, POP3, RPOP, APOP, KPOP, all flavors of IMAP, and ESMTP ETRN. It can even support IPv6 and IPSEC. Changes: Fixes for a number of minor bugs, including two reported from the RH6.2 beta and a dozen or so from the Debian bug-tracking system. Is someone working on it? If no, I download the sources and make a new packages... Gruss Grisu -- Michael Bramer - a Debian Linux Developer http://www.debian.org PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Programming is like sex; one mistake and you have to support for a life time. pgpvVxWi7LjWl.pgp Description: PGP signature
Re: Release-critical Bugreport for March 3, 2000
On Thu, Mar 09, 2000 at 05:25:42PM +0100, Michael Bramer wrote: application: fetchmail 5.3.1 Changes: Fixes for a number of minor bugs, including two reported from the RH6.2 beta and a dozen or so from the Debian bug-tracking system. Is someone working on it? If no, I download the sources and make a new packages... If you look in woody, you'll find this version of fetchmail. -- David Starner - [EMAIL PROTECTED] Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU
Re: better RSYNC mirroring , for .debs and others
tom rothamel is working on a project called debdiff that works towards the same goal. please read his announcment thread, which is archived at http://www.debian.org/Lists-Archives/debian-devel-0002/msg00391.htm. i like the idea of rsync modules, but the concept you project misses is that even a small addition or subtraction in the beginning of a file ruins rsync's speed bonus because it then has to send everything. take a look at tom's code. i think you'll find it interesting. Andrea Mennucc1 ([EMAIL PROTECTED]) wrote: hi everybody I have implemented a good idea for reducing download stress for everybody who is mirroring a lot of data using rsync, like, the people who are mirroring Debian GNU/Linux: currently, many Debian leaf mirrors are using rsync for mirroring from the main .debian.org hosts. rsync contains a wonderful algorithm to speedup downloads when mirroring files which have only minor differences; only problem is, this algorithm is ALMOST NEVER used when mirroring a debian repository ... indeed, whenever a new version of a package is entered in the debianrepository, this package has a different name: for this reason rsync does just a full download. Summarizing, rsync currently does some speedup only when it downloads Packages.gz files, or when it skips an already existing package. well, I have just implemented a simple way to use the algorithm even when downloading the .debs . here is a simple example suppose the current situation is $REMOTE::/pub/debian/dist/bin/dpkg_2.deb whereas locally we have /debian/dist/bin/dpkg_1.deb when rsync looks for a local version of /debian/dist/bin/dpkg_2.deb if there is none, then rsync does ls -t /debian/dist/bin/dpkg_* and looks for the most recent file it finds this way, rsync will use the file /debian/dist/bin/dpkg_1.deb to try to speedup the download of$REMOTE::/pub/debian/dist/bin/dpkg_2.deb (using its fabulous algorithm) BIG PRO: my new rsync is totally compatible with the old one Conclusion: this idea would make all debian mirror-people happier (specially if they mirror unstable; consider that, often, when a new version of a package is released, only small changes are made... sometimes, only the .postinst , or such, are really changed; this may , thou, masked by the compression, alas: but, see TODO) I attach two files: the first file is a diff, showing where, in the rsync 2.4.1 source code tree, I have done some modifications; the second is a .tgz of the all the new and modified files you need to build the new rsync: to build, first you need to download the source code (see rsync.samba.org/rsync/download.html) and then you unpack the file rsync.diffsrc.tgz in the tree code, and build. You may also get the compiled binary directly as ftp://tonelli.sns.it/pub/rsync/rsync and the new code alltogether in ftp://tonelli.sns.it/pub/rsync TODO: there are some potentially good ideas here: 1) the idea is to add modules to rsync: a gzip module, a deb module, and rpm module...; currently, modules just look for an older local version of the file; in a future version, any module would apply to a certain type of file, and create another file to pass to rsync so that this another file may probably lead to more speedup: e.g., the gzip module would unzip files before doing comparisons, and the deb module would unzip the data.tar.gz part of a package CONS: this would not be backward compatible, of course The idea is, a module may provide the following calls: find_alternative_version_MOD() receive_file_MOD() send_file_MOD() Currently, only find_alternative_version_deb() was implemented. If rsync uses only the find_alternative_version_MOD() calls, then it is backward compatible with the usual version: (in a sense , it is doing what the option --compare-dest already does, only in a smarter way) I have not currently implemented anyreceive_file_MOD() send_file_MOD() : these would need a change in the protocol: I hope that the rsync authors will give permission 1b) My idea (not sure) is that rsync may work if provided with named pipes instead of files: indeed, according to the technical report, it needs to read the local and remote files only once, and then, it writes the local file, without ever seeking backwards; then, the above modules would not need to actually use disk space and create temporary files. 2) for a faster apt-get downloading, it may be possible to do the same trick WHEN UPGRADING INSTALLED PACKAGES! Here is the idea: apt-get creates a local version of the package (using dpkg-repack) and do the rsync to get the remote version -- Andrea C. Mennucci, Scuola Normale Superiore, Pisa, Italy -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems)
Re: better RSYNC mirroring , for .debs and others
On Thu, 9 Mar 2000, Andrea Mennucc1 wrote: rsync contains a wonderful algorithm to speedup downloads when mirroring files which have only minor differences; only problem is, this algorithm is ALMOST NEVER used when mirroring a debian repository Small detail here, .debs, like .gz files are basically not-rsyncable. gzip effectively randomizes the contents of the files making the available differences very, very small. This is particularly true for .debs when you add in the fact that gcc never produces binary identical output on consecutive runs. Please *do not* run a client with this type of patch connected to any of our servers, it will send the load sky high for no good reason, rsync is already responsible for silly amounts of load, do not make it worse. Jason
Re: better RSYNC mirroring , for .debs and others
On Thu, Mar 09, 2000 at 12:26:30PM -0700, Jason Gunthorpe wrote: differences very, very small. This is particularly true for .debs when you add in the fact that gcc never produces binary identical output on consecutive runs. I'm not arguing the rest of your points, but I'm curious about this one. IIRC, the last thing a full bootstrap of GCC does, after building stage one binaries with the native compiler, stage two binaries with the stage one binaries and stage three binaries with the stage two binaries, is compare the stage two and stage three binaries. If they're not the same, then you have a problem. I don't see how this fits with what you're saying. -- David Starner - [EMAIL PROTECTED] Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU
Re: better RSYNC mirroring , for .debs and others
On Thu, 9 Mar 2000, David Starner wrote: I'm not arguing the rest of your points, but I'm curious about this one. IIRC, the last thing a full bootstrap of GCC does, after building stage one binaries with the native compiler, Hum, It *used* to do this, can't seem to get it to do it today though oh well IIRC it only applied to debug information, it included timestamps or some such. Jason
Re: better RSYNC mirroring , for .debs and others
On Thu, Mar 09, 2000 at 12:46:05PM -0700, Jason Gunthorpe wrote: On Thu, 9 Mar 2000, David Starner wrote: I'm not arguing the rest of your points, but I'm curious about this one. IIRC, the last thing a full bootstrap of GCC does, after building stage one binaries with the native compiler, Hum, It *used* to do this, can't seem to get it to do it today though oh well IIRC it only applied to debug information, it included timestamps or some such. There is a small header at the beginning of an object file which is different each time, because it contains a time stamp. This is why 'make compare' removes the first 16 bytes of the object files before comparing. for file in *$(objext); do \ tail +16c ./$$file tmp-foo1; \ tail +16c stage$$stage/$$file tmp-foo2 \ (cmp tmp-foo1 tmp-foo2 /dev/null 21 || echo $$file differs .bad_compare) || true; \ done Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Mozilla
My latest apt-get update ; apt-get upgrade run this morning grabbed a new version of mozilla. It no longer works, it dies with a segmentation fault. Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin Profile Manager : Command Line Options : End Profile Manager : GetProfileDir Profile Manager : GetProfileDir Profile Manager : Profile Wizard and Manager activites : End Segmentation fault = 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: Mozilla
On Thu, Mar 09, 2000 at 01:04:59PM -0800, Kenneth Scharf wrote: My latest apt-get update ; apt-get upgrade run this morning grabbed a new version of mozilla. It no longer works, it dies with a segmentation fault. I heard that you have to remove ~/.mozilla directory. bye Christian -- | Christian Surchi | www.firenze.linux.it/~csurchi| www. | | [EMAIL PROTECTED] | [EMAIL PROTECTED] | gnu. | | FLUG: www.firenze.linux.it | Debian GNU/Linux: www.debian.org | org | Computers don't actually think. You just think they think. (We think.)
Re: Mozilla
Delete your preferences of M13, restart mozilla. You'll get the create profile wizard, and then mozilla works. Yes, it's still alpha software, why? ;-) On Thu, 9 Mar 2000, Kenneth Scharf wrote: My latest apt-get update ; apt-get upgrade run this morning grabbed a new version of mozilla. It no longer works, it dies with a segmentation fault. Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin Profile Manager : Command Line Options : End Profile Manager : GetProfileDir Profile Manager : GetProfileDir Profile Manager : Profile Wizard and Manager activites : End Segmentation fault = 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Fool me seven times, shame on you. Fool me eight or more times, shame on me. -- Amy
Re: Mozilla
My latest apt-get update ; apt-get upgrade run this morning grabbed a new version of mozilla. It no longer works, it dies with a segmentation fault. Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin Profile Manager : Command Line Options : End Profile Manager : GetProfileDir Profile Manager : GetProfileDir Profile Manager : Profile Wizard and Manager activites : End Segmentation fault Try removing ~/.mozilla , worked for me. -- Education is a system of imposed ignorance. -Noam Chomsky
Re: Mozilla
i had the same problem. just remove your ~/.mozilla and it works (you'll have to re-setup it, tough). regards Stefan On Thu, Mar 09, 2000 at 01:04:59PM -0800, Kenneth Scharf wrote: My latest apt-get update ; apt-get upgrade run this morning grabbed a new version of mozilla. It no longer works, it dies with a segmentation fault. Profile Manager : Profile Wizard and Manager activites : Begin Profile Manager : Command Line Options : Begin Profile Manager : Command Line Options : End Profile Manager : GetProfileDir Profile Manager : GetProfileDir Profile Manager : Profile Wizard and Manager activites : End Segmentation fault = 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpJdSQdAN2XO.pgp Description: PGP signature
login message on lully.debian.org
I'm not sure if this message should go to debian-devel or debian-project or ... For several days the login message on lully.debian.org has ended with *** This system is being repaired. Please refrain from using it for now. The system has been up for 14 days and /etc/motd was last modified on Jan 27. Is it possible that the repairs are complete and someone forgot to remove this line from /etc/motd?
Re: login message on lully.debian.org
On 9 Mar 2000, Douglas Bates wrote: The system has been up for 14 days and /etc/motd was last modified on Jan 27. Is it possible that the repairs are complete and someone forgot to remove this line from /etc/motd? No Jason
Re: better RSYNC mirroring , for .debs and others
On 9 Mar 2000 12:56:29 -0500, Jacob Kuntz wrote: tom rothamel is working on a project called debdiff that works towards the same goal. please read his announcment thread, which is archived at http://www.debian.org/Lists-Archives/debian-devel-0002/msg00391.htm. The code associated with this is now available at http://onegeek.org/~tom/software/ddiff/, for what it's worth. I do happen to think that rsync is an inefficent solution to archive mirroring, however, as it seems it would need to scan and checksum a huge number of files every time it runs. Probably a better way would be to have dinstall[1] generate a list of changes it makes to the archive, and have people mirroring the archive use those lists to figure out what needs to be downloaded. This would also have the benefit of making it easy to ensure that archive mirrors are always in a consistent state. (ie, Packages.gz is updated after new packages have been downloaded, but before old packages are deleted.) [1] At least, I think that's it. I'm not really sure how things work on the Debian end... I probably won't know for sure until hell freezes over^W^W^Wnew-maintainer reopens. -- Tom Rothamel - http://onegeek.org/~tom/ -- Using GNU/Linux The Moon is Waxing Crescent (16% of Full)
