Re: OpenLanParty: resoconto della serata
On Tue, Sep 23, 2003 at 01:18:23PM +0200, Emanuele Rocca wrote: Vero. Però in tale data l'evento avrebbe una visibilità infinitamente maggiore rispetto a qualunque altro giorno dell'anno. Si, ma il debcamp non e` una conferenza o un convegno. E` un incontro tra sviluppatori per sedersi (finalmente) uno a fianco a l'altro e lavorare insieme su alcune problematiche, software o qualunque cosa riguardi Debian. Non necessita di grande visibilita` verso terzi/utenti, ma, se proprio vogliamo, piu` di un resoconto della produttivita` dell'incontro: una cosa che convinca altri sviluppatori ad unirsi e sponsor a finanziare. Quando si propone, allora? Direi sicuramente non a cavallo con altre importatnti eventi legati al mondo opensource, ma piuttosto prima (com'e` avvenuto per l'ultimo debcamp) o dopo. Pensavo alla possibilita` di estendere l'evento al mondo open source in generale. Coinvolgere anche altre realta` di sviluppatori sicuramente ci permetterebbe di essere in piu` persone (piu` appetibile per i finanziatori) e sarebbe piu` stimolante: in fondo, noi facciamo i pacchetti di altri software, e molti di questi hanno comunita` sparse in giro per il mondo. Pensavo ad alcune realta` come quella di Zope italia che e` molto attiva, ma anche perl/python e chi piu` ne ha piu ne metta. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Pacchettizzazione di un'applicazione
On Tue, Sep 16, 2003 at 12:00:36PM +0200, Stefano Zacchiroli wrote: Personalmente trovo che questa soluzione sia comunque problematica in quanto se installi 15 prodotti zope, tutti quanti fanno ripartire ... ehm ... qualcosa ... :-) ... Niente impedisce di rendere tale restart opzionale dopo opportuna richiesta all'admin via debconf. Viene gia' fatto per altri package. -- Francesco P. Lovergine
Re: firma chiave GPG a Terni
a volte il mio cervello rimane in panne per piu' di 24 ore .. non mi ero accorto che la mail era anche per ddi quindi la rigiro li' On Mon, Sep 22, 2003 at 02:07:03PM +0200, Davide Puricelli wrote: On Sun, Sep 21, 2003 at 10:08:22PM +0200, Samuele Giovanni Tonon wrote: Caro Samu, mi permetto di fare un breve commento alla tua mail; io stesso, in passato, ho fatto da sponsor a delle persone che poi sono diventate dei maintainer e, di base, non ho nulla contro tale pratica. Nei mesi scorsi sono stato contattato su IRC dal nostro Daniele che mi chiedeva consigli su dei software che stava impacchettando e, in breve, siamo diventati buoni amici; in seguito Daniele mi chiese di fargli da sponsor e io decisi di non farlo, per un semplice motivo: ritengo che la persona sponsorizzata debba essere qualcuno che ha gi? la ferma intenzione di aderire al progetto e che, possibilmente, ha gi? la chiave firmata da uno sviluppatore. Certo, Daniele sembra sia a me che a te un bravo ragazzo, ma se fra un po non avesse pi? voglia di entrare nel progetto? Il pacchetto verrebbe orphaned, adottato da QA etc. etc. .. insomma sbattimenti per tante persone. Se ben ricordo, inoltre (non me ne volere Daniele), il nostro maintainer di aspell-it all'epoca (due-tre mesi fa), non era ferratissimo in materia di Policy, spero tu ti sia accertato delle sue conoscenze :) [vedo su bugs.debian.org che aveva settato Architecture=i386, umm ..] Concludendo, spero di essermi preoccupato per niente e di vedere presto Daniele su nm.debian.org. li' c'e' stato anche un errore da parte mia nel non essermene accorto (e ti giuro che avevo controllato il tutto). Il giorno che Daniele non fosse interessato e non volesse diventare DM allora prendero' io in consegna il pacchetto, o chi per me oppure diventera' un pacchetto orfano come tanti altri di debian, ma almeno ci sara' una qualche versione (seppur obsoleta) disponibile per debian , credo bisogni dare fiducia a priori ai ragazzi nuovi che vogliono dare un aiuto a debian, altrimenti se ci mettiamo sospettosi su tutti si finisce che passiamo tutti a suse. Credo inoltre che aspell-it serva molto ad avvicinare l'italiano medio alla debian . In generale sono per dare fiducia, non muore nessuno se si fanno errori (specie quando si fa upload su sid) e anche se si fanno (siamo umani alla fine), beh l'importante prima di tutto e' l'entusiasmo e la voglia di fare. ciao Samuele -- While various networks have become deeply rooted, and thoughts have been sent out as light and electrons in a singular direction, this era has yet to digitize/computerize to the degree necessary for individuals to become a singular complex entity. KOUKAKU KIDOUTAI Stand Alone Complex
Re: OpenLanParty: resoconto della serata
On Sun, Sep 21, 2003 at 10:06:40PM +0200, Marco d'Itri wrote: On Sep 21, Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] wrote: E poi, ora che ci penso, l'ILS ha trovato dei finanziatori privati per fare una riunione (io ne so almeno una), vuoi che un gruppo di sviluppatori, Il massimo che ILS ha trovato è il datore di lavoro di un socio che ci ha concesso l'uso di una sala riunioni. Tutte le spese le ha pagate di tasca propria chi è venuto. Ammazza, state messi male allora. Noi per un fesso - passatemi l'espressione - linuxday in loco (in quel di terronia, la periferia dell'impero quindi) siamo riusciti a farci pagare l'aereo A/R per un ospite da Milano a Bari. E non è che ci siamo sforzati molto. Qualche societa' locale ha anche sponsorizzato Rubini e Genoni per un intervento in un meeting decisamente microscopico, sicuramente molto + di un LD, ecc. Sara' mica che nel centro dell'impero, le societa' sono alquanto 'tight fist', per non usare una espressione + colorita delle mie parti :) -- Francesco P. Lovergine
Re: Traduction de menus et Gnome....UTF-8eries
Le Tuesday 23 September 2003, Christian Perrier écrit : [...] Cela dit, je m'accroche à passer en UTF-8, Laurent Defours m'ayant redonné l'espoir de cesser d'envoyer des hiéroglyphes... :-) tu nous fais une petite doc. quand tu auras réussi ? histoire qu'on puisse faire pareil :) Nicolas --
Re: Traduction de menus et Gnome....UTF-8eries
Je suis trés intéressé par cette histoire de cessé l'envoi de hieroglyphes. Peut t-on en savoir plus au sujet de cet espoir ? B. Le Tuesday 23 September 2003, Christian Perrier écrit : [...] Cela dit, je m'accroche à passer en UTF-8, Laurent Defours m'ayant redonné l'espoir de cesser d'envoyer des hiéroglyphes... :-) tu nous fais une petite doc. quand tu auras réussi ? histoire qu'on puisse faire pareil :) Nicolas --
Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]
On Tue, Sep 23, 2003 at 12:14:02AM +0100, James Troup wrote: The queue daemon can no longer handle PGP 2.x keys; I don't know why and since a) the number of developers still using these kind of keys for uploads can be counted on the fingers of a mutilated hand, b) there are alternative methods of uploads available to the few who do, c) queued is in perl and d) has plenty of other more vicious bugs, I haven't done anything about it. If anyone else cares to fix it, feel free to send me a tested patch. Well, we all know how vigorously active Brian White has been since around the time GPG hit 1.0... He may not have even heard that the RSA patent expired, or about that court case...what was it? _Bush v. Gore_? -- G. Branden Robinson| The key to being a Southern Debian GNU/Linux | Baptist: It ain't a sin if you [EMAIL PROTECTED] | don't get caught. http://people.debian.org/~branden/ | -- Anthony Davidson signature.asc Description: Digital signature
Re: IMPORTANT: your message to html-tidy
On Mon, Sep 22, 2003 at 05:09:30PM -0500, david nicol wrote: | Shamless plug: sign up for totally spam-free forwarding address | at http://pay2send.com Ewww! *recoils in disgust* You don't pay to send, we make others pay to send to you. - if this system become widespread, then you surely /would/ have to pay to send to others. In terms of spam prevention, this has no advantages over TMDA that I can think of, but it seems like a bloody good way to piss off people sending you sending you unsolicited but nevertheless legitimate email[1]. Also, like TMDA and similar systems, it does nothing to help spam that comes from e.g. Debian mailing lists. Cameron. [1] Where the definition of legitimate email may vary from person to person.
Re: Virus emails
On ma, 2003-09-22 at 17:53, Matthias Urlichs wrote: The list of hardware required to stop this spam unfortunately seems to include a time machine. Oh, that's not required at all. A simple couch will do. The couch will require a team of psychiatrists surrounding it, of course. They will then interview, for extended periods of time, whoever sends spam, writes viruses, or runs an insecure computer attached to the Internet. After the healing process is done, the culprits can then rejoin society as productive and wholesome individuals. I favor this approach over simple applications of violence, such as using an axe on any computer infected by a virus. -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: Virus emails
On Tuesday 23 September 2003 01:45, Bernd Eckenfels wrote: On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote: Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized body doesn't have to get the whole body before rejecting the mail. Based on this, it should be possible to reject the mail before it gets fully transfered to the server. Well, you can reject on the size argument, if you see one, and if it is not faked. Otherwise you have to read up to x bytes until you can drop the conncetion. But this has nothing to do with the worms, unless you want to limit your mails to max 10k :) In case of spam and virus checking you have to read at least the headers, and most likely a lot of the body (till you know the attachement type) Indeed, but you don't have to get the whole 150KB of mail... Mike -- I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'enculé de ta mère. It's like wiping your ass with silk! I love it. -- The Merovingian, in the Matrix Reloaded
(forw) How to deal with debconf translations and templates
modifications when using po-debconf (was: Re: Fwd: French translation for PHPWiki) Reply-To: X-message-flag: Outlook is a good virus spreading tool. It can send mail, too. X-Republicain: 1 vendmiaire an CCXII (Raisin) Below is a message which may be of some interest for developers who are not used to debconf/po-debconf translation stuff. Matthew Palmer, maintainer of the phpwiki package, asked to Frederic Zulian (f1sxo), who translated phpwiki's tempaltes to french for some adive about how to deal properly with modifications he plans to do on the original english templates Below is the answer I made...which gives some clues about all this po-debconf stuff. This may have some interest for some of you...or this may sound rather trivial to others..:-) (both agreed for me to forward this publicly) - Forwarded message from Christian Perrier [EMAIL PROTECTED] - Date: Tue, 23 Sep 2003 07:07:22 +0200 From: Christian Perrier [EMAIL PROTECTED] To: f1sxo [EMAIL PROTECTED], Christian Perrier [EMAIL PROTECTED], Matthew Palmer [EMAIL PROTECTED] Subject: Re: Fwd: French translation for PHPWiki Frederic forwarded your mail to me.. OK, I changed the templates file provided by the po-debconf patch - but I didn't change the templates.pot file. How do I regenerate that, then, so I can send the updated version to you? I'm an absolute babe-in-the-woods when it comes to translation work. Sorry. Just put Frdric's original fr.po file in debian/po. Then run debconf-updatepo from debian. NEVER manually modify files in debian/po, especially templates.pot and POTFILES.inunless you really knwo what you are doing. After running debconf-updatepo, have a look at debian/po/fr.po : you will see that strings you modified in the original templates file will be marked fuzzy. This means that the translated version has been identified as not corresponding to the new english version. Fuzzying strings is very easy: any change, even minor (double space replaced by one space) will fuzzy the corresponding translation. When a template has at least one fuzzy string, debconf will NOT use the translation. This prevents outdated translations to be used. After running debconf-updatepo, just send Frederic the new fr.po file: he will make the appropriate corrections and then send the file back to you -- just replace your old file with that one and voila. When you build your package, provided you use debhelper, dh_installdebconf will run debconf-updatepo anyway...so you don't have to run it manually. However, this is a Good Thing to run it before building your package and then check the translations: for i in debian/po/*.po do echo $i msgfmt -o /dev/null --statistics $i done If some of these show anything else than: NN translated messages but something like: 1 translated message, 3 fuzzy translations. Then it needs some update. You may look at the Last-Translator field and then ask this individual for an update by sending him the new XX.po file. You may build a package with fuzzied or untranslated strings in some translation files. This won't break your package.but trying to deal with these translations before bilding is IMHO Good Practice (but don't wait too much for translators anyway...) (Matthew, Frederic, do you mind if I forward this to debian-devel.? This may be of some interest for other developers. I may remove the babe-in-the-woods comment, if you like...:-))) - End forwarded message - --
Re: Virus emails
On Tue, Sep 23, 2003 at 12:28:44AM +0200, Mike Hommey wrote: Maybe I'm wrong, but I think an MTA rejecting a mail because of oversized body doesn't have to get the whole body before rejecting the mail. You can issue a permanent error only after you have received the body.
Re: Virus emails
Hi, Is there something similar for exim (woody version)? I don't care too much about the incoming bandwidth, but more about the resources that the spam and virus checks consume, especially during these spam virus waves. So I could add a (hopefully) cheap check at MTA level to reject these mails until the wave is over. Joachim Am Di, 2003-09-23 um 04.29 schrieb Graham Wilson: On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote: Hi, Mike Hommey wrote: helps catching 95%... But the bandwidth is still used... I'm still looking for a pure MTA solution... A pure MTA solution would still need to scan the body and thus would still eat your bandwidth. i have postfix's body_checks setup to reject lines that match the following regular expression (this is the first line of the base64 encoded virus): /^TVqQAAME\/\/8AALgAQAAA$/ i'm not sure when postfix closes the connection, whether its after recieving a matching line, or after the client is done sending data. if the former though, this would be a good pure mta solution that doesn't conserve too much bandwidth. as to effectiveness, i've blocked 664 messages since saturday afternoon. i still get some swen messages through, but they have had the virus stripped already, so the message is considerably smaller. -- Joachim nomeata Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Virus emails
On Mon, Sep 22, 2003 at 07:34:58PM -0400, H. S. Teoh wrote: I've resorted to blocking port 25 to subnets from which these spams originate. Currently I have about 45 subnets (/24 and a few /16) on my blacklist, and so far 409 connections have been dropped. The sad thing about this is that there are parts of the Internet that aren't subnet'ed properly. My mail server happens to be in the same /16 as about two hundred entirely different locations, so whenever someone gets one of those from whatever lamer in some shithole 900km away from me, my IPs get blocked as well. Our NOC, collateral damage, and life in general for that matter, suck. :) -- 2. That which causes joy or happiness.
Re: Virus emails
On Mon, Sep 22, 2003 at 08:46:15PM -0700, Steve Lamb wrote: On Mon, 22 Sep 2003 22:44:50 -0400 H. S. Teoh [EMAIL PROTECTED] wrote: Another major source is rr.com, which not only gives me tons of Swen, but also other spam in general. I've blacklisted rr.com in /etc/hosts.deny, but obviously I'm missing something obvious, 'cos rr.com spam still gets through unless I block them on the firewall. rr.com pisses me off. They RBL other ISP provider's customer blocks so we can't complain about their mess. Pathetic. Apparently rr.com has a reputation for being a spamhaus since years ago, in spite of their advertisements to the contrary. [snip] What are the exim rules you used to catch these things? exiscan-acl calling clamav and dropping it with a 550. A full log line would be: 2003-09-22 07:38:05 1A1RpB-0007Xd-Of H=(smtp21.singnet.com.sg) [165.21.101.201] F=[EMAIL PROTECTED] rejected after DATA: This message contains a viru s or other malware (Worm.Gibe.F). I see. Thanks for the info, I'll look it up. [snip] For me, I just created a special iptables chain in the NAT table and wrote a script to put DROP rules into it. Then I have a rule in PREROUTING that diverts all port 25 traffic to that chain (so that other stuff doesn't incur too much overhead---the chain is quite long and growing rapidly). True. I'm just doing a blanket blacklist since I figure if they're infected with this, what else will they hit? So far, I haven't got anything except port 25 connections from infected hosts. But then again, I have very few open ports on my machine, so who knows. If you want to automate this more, you could write a spamassassin rule that matches Swen mails, then use procmail to filter it (match against the rule name in X-Spam-Status) through a script that grabs the IP address and enters it into the firewall. Except it never hits SA nor do I even have procmail installed. Can't stand the ugly beast. It never hits SA? Almost all Swen mails I got were caught by my bogofilter + SA setup. (It only missed like 2-3 out of at least 5000 per day.) [snip] But according to my observations from today, it's not a big deal if the first few messages get through---all my firewall rules were hand-added (only partially automated with some scripts), and they still catch a lot of subsequent crap. From the looks of it, infected machines are liable to repeatedly resend messages to the same target. The fact that you *did* blackhole the IP or subnet probably saves you from a lot of subsequent crap. True. Right now I'm just adding IPs by awking out the IPs, cleaning off the brackets and tacking it onto the end of shorewall's blacklist. I've resorted to blocking wide subnets. 202.248.37.0/24 alone has had 3858 hits since yesterday, and still counting. Last night alone (about the past 8 hours or so) the firewall blocked about 6000+ port 25 connections, and shows no sign of slowing down. In fact, the rate seems to be increasing from the per minute scale and approaching the per second scale. [snip] Ahhh, here's an interesting tidbit. From shorewall's status. Chain blacklst (2 references) pkts bytes target prot opt in out source destination 40 2400 DROP all -- * * 128.118.141.31 0.0.0.0/0 48 2880 DROP all -- * * 128.118.141.35 0.0.0.0/0 0 0 DROP all -- * * 128.83.126.136 0.0.0.0/0 1087 52176 DROP all -- * * 129.79.1.71 0.0.0.0/0 686 32928 DROP all -- * * 129.79.1.72 0.0.0.0/0 This in interesting. Some of these are hitting me a LOT and others have not hit at all. I guess this means I can drop the ones with a 0 count, reset the counts and let it go. This would, in theory, weed out the cleaned up hosts while leaving in the infected, no? [snip] I noticed this also. However, I found that some of the subnets I blocked rested for several hours, and then started bombarding me again. So I'm leaving the rules in for at least a couple o' days before cleaning out those with 0 count. T -- To err is human; to forgive is not our policy. -- Samuel Adler
Re: Virus emails
On Tue, Sep 23, 2003 at 02:31:22PM +0200, Josip Rodin wrote: On Mon, Sep 22, 2003 at 07:34:58PM -0400, H. S. Teoh wrote: I've resorted to blocking port 25 to subnets from which these spams originate. Currently I have about 45 subnets (/24 and a few /16) on my blacklist, and so far 409 connections have been dropped. The sad thing about this is that there are parts of the Internet that aren't subnet'ed properly. My mail server happens to be in the same /16 as about two hundred entirely different locations, so whenever someone gets one of those from whatever lamer in some shithole 900km away from me, my IPs get blocked as well. Our NOC, collateral damage, and life in general for that matter, suck. :) [snip] Which is why I've mostly refrained from /16's unless there are a lot of different addresses therein that have been infected. Although I admit to having a /8 for 212.* since there is just an amazing variety of addresses in that block that flood me with Swen. Ah, that ipv6 would be widely adopted soon... T -- LINUX = Lousy Interface for Nefarious Unix Xenophobes.
Re: Virus emails
Lars Wirzenius writes: I favor this approach over simple applications of violence, such as using an axe on any computer infected by a virus. Psychiatry just for sending viruses? I don't know. Seems pretty extreme to me. Are you sure simple beatings would not suffice? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Virus emails
On Tue, Sep 23, 2003 at 08:39:02AM -0400, H. S. Teoh wrote:
What are the exim rules you used to catch these things?
exiscan-acl calling clamav and dropping it with a 550. A full log
line would be:
2003-09-22 07:38:05 1A1RpB-0007Xd-Of H=(smtp21.singnet.com.sg)
[165.21.101.201] F=[EMAIL PROTECTED] rejected after DATA: This
message contains a viru s or other malware (Worm.Gibe.F).
I see. Thanks for the info, I'll look it up.
exim4-daemon-heavy includes the Exiscan patch that allows one to scan for
malformed MIME, viruses and spam during the SMTP dialogue.
Install clamav-daemon and in the general settings block add:
av_scanner = clamd:/var/run/clamd.ctl
And in the ACL block after DATA, you put something like:
deny message = Message contains malware ($malware_name)
demime = *
malware = *
Works wonders.
There are also similar low-level interfaces to SpamAssassin: one is via a
sa-exim.so that is loaded via the local_scan() interface,
local_scan_path = .../somewhere/sa-exim-3.0.so
And another one is via an exiscan ACL setting for it (also in the DATA ACL),
deny message = Classified as spam (score $spam_score)
condition = ${if {$message_size}{80k}{1}{0}}
condition = ${if {$spam_score_int}{120}{1}{0}}
spam = nobody
(that 120 is 12.0 in SA terms)
For now I'm using the SA-Exim method because even though it's clumsy (needs
the .so file compiled from source so distribution isn't as trivial as an
apt-get invocation), I used it before the Exiscan patch was available and it
was reliable. (I'd welcome suggestions from other users about this issue.)
If you want to automate this more, you could write a spamassassin rule
that matches Swen mails, then use procmail to filter it (match against the
rule name in X-Spam-Status) through a script that grabs the IP address and
enters it into the firewall.
Except it never hits SA nor do I even have procmail installed. Can't
stand the ugly beast.
It never hits SA?
Because his antivirus ACL kills it before that.
--
2. That which causes joy or happiness.
Re: Virus emails
Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: Gunnar Wolf [EMAIL PROTECTED] wrote: [1] http://www.ietf.org/rfc/rfc0821.txt And what does RFC2821 have to say about it? I would not trust every MTA to implement newer versions of the RFC - However, it is up to you to decide ;-) -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Bug#212399: ITP: libdate-leapyear-perl -- Simple module to determine whether or not a year is a leapyear
Package: wnpp Version: unavailable; reported 2003-09-23 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libdate-leapyear-perl Version : 1.7.1 Upstream Author : Rich Bowen [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Date-Leapyear/ * License : Artistic Description : Simple module to determine whether or not a year is a leapyear This is a simple, non-OO module to determine whether or not a year is a leap year. It exports one function, isleap, which returns 1 or 0, which determines whether a year is leap or not This is a relatively simple module, but it's a distinct component necessary for libdate-ical-perl, which in turn is used by one of the upstream examples for libtest-class-perl (and is thus a Suggests: on it, and should be furfilled.) Unless there are any objections from debian-devel, this will be in new/ later today. - -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux starlite 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cHULZNh5D+C4st4RAo0XAJ4t0CwRAIIaDjaGi9A7+LlgU0f9rgCfae0z 7nd1X6Cs1KlmAZ6aNWYKTiU= =v1HG -END PGP SIGNATURE-
Re: Virus emails
You are aware Mutt is perfectly capable of responding to the list. Learn it, love it, USE IT! On Tue, 23 Sep 2003 10:20:46 -0500 Gunnar Wolf [EMAIL PROTECTED] wrote: Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: Gunnar Wolf [EMAIL PROTECTED] wrote: [1] http://www.ietf.org/rfc/rfc0821.txt And what does RFC2821 have to say about it? I would not trust every MTA to implement newer versions of the RFC - However, it is up to you to decide ;-) Well that's the thing, isn't it. At some point we will have to work with that document and not legacy documents. Besides, you're operating under the impression that spamming software follow either. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpUaCpPytag6.pgp Description: PGP signature
Re: Virus emails
On Tue, 23 Sep 2003 08:39:02 -0400 H. S. Teoh [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2003 at 08:46:15PM -0700, Steve Lamb wrote: Except it never hits SA nor do I even have procmail installed. Can't stand the ugly beast. It never hits SA? Almost all Swen mails I got were caught by my bogofilter + SA setup. (It only missed like 2-3 out of at least 5000 per day.) Exiscan-ACL gets the message before Spamassassin does. So the checks are: Exiscan-ACL says Malformed MIME? Reject. Clamav says Malware (virus, worms, trojans, etc)? Reject. Spamassassin says its spam? Reject. I noticed this also. However, I found that some of the subnets I blocked rested for several hours, and then started bombarding me again. So I'm leaving the rules in for at least a couple o' days before cleaning out those with 0 count. Hrm, well the cycle of when to remote and reset could be tuned for daily or weekly operation. :) -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpzy3zr8Pr0U.pgp Description: PGP signature
Re: Virus emails
On Tue, 23 Sep 2003 16:45:55 +0200 Josip Rodin [EMAIL PROTECTED] wrote: For now I'm using the SA-Exim method because even though it's clumsy (needs the .so file compiled from source so distribution isn't as trivial as an apt-get invocation), I used it before the Exiscan patch was available and it was reliable. (I'd welcome suggestions from other users about this issue.) Same here though I am sticking with SA-Exim because it saves the mail in a certain range so I can throw it at the Bayesian classifier. It also has the option of teergrubing. It's generally accepted that for robust handling of Spam SA-Exim is the better route. For simple handling as well as virus scanning Exiscan-ACL is the better route. Lots of people just use both. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpczfRvlVnu7.pgp Description: PGP signature
Re: Virus emails
Steve Lamb dijo [Tue, Sep 23, 2003 at 10:29:51AM -0700]: Gunnar Wolf [EMAIL PROTECTED] wrote: Steve Lamb dijo [Mon, Sep 22, 2003 at 07:21:05PM -0700]: Gunnar Wolf [EMAIL PROTECTED] wrote: [1] http://www.ietf.org/rfc/rfc0821.txt And what does RFC2821 have to say about it? I would not trust every MTA to implement newer versions of the RFC - However, it is up to you to decide ;-) Well that's the thing, isn't it. At some point we will have to work with that document and not legacy documents. Besides, you're operating under the impression that spamming software follow either. Ok... You got me on this one - I just went and checked the document. It is, however, quite a recent document (April 2001), and there are still too many people using older software. I prefer having the old, trusted phylosophy - Be strict on what you send, relaxed on what you receive. Now, I am not reading the whole document just to check this out. Skimming it, I found many reasons for the 'DATA' command to return a 4xx or 5xx error code, but didn't find a reason to interrupt the client. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Virus emails
On Tue, Sep 23, 2003 at 10:43:30AM -0700, Steve Lamb wrote: For now I'm using the SA-Exim method because even though it's clumsy (needs the .so file compiled from source so distribution isn't as trivial as an apt-get invocation), I used it before the Exiscan patch was available and it was reliable. (I'd welcome suggestions from other users about this issue.) Same here though I am sticking with SA-Exim because it saves the mail in a certain range so I can throw it at the Bayesian classifier. I usually don't have large enough partitions to hold all the spam (!) It also has the option of teergrubing. I'm a bit scared of turning it on, didn't (see|read) enough documentation for it. It's generally accepted that for robust handling of Spam SA-Exim is the better route. For simple handling as well as virus scanning Exiscan-ACL is the better route. Lots of people just use both. Isn't that pretty wasteful? -- 2. That which causes joy or happiness.
Re: Virus emails
On Tue, 23 Sep 2003 21:07:46 +0200 Josip Rodin [EMAIL PROTECTED] wrote: On Tue, Sep 23, 2003 at 10:43:30AM -0700, Steve Lamb wrote: Same here though I am sticking with SA-Exim because it saves the mail in a certain range so I can throw it at the Bayesian classifier. I usually don't have large enough partitions to hold all the spam (!) Certain range. Here it is things scored between 5 and 8. 5 is where things are considered spam. 8 is where I reject things outright. 12 is where autolearn is set. I want to send things in that range to the Bayesian classifier so the score would creep up hopefully to the point of being rejected. Comes out to about 1-2 a day. It also has the option of teergrubing. I'm a bit scared of turning it on, didn't (see|read) enough documentation for it. Simple concept, if a message scores high enough (25 is default) you just string the connection out for 5 minutes. It's generally accepted that for robust handling of Spam SA-Exim is the better route. For simple handling as well as virus scanning Exiscan-ACL is the better route. Lots of people just use both. Isn't that pretty wasteful? Depends on what you consider wasteful. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpAfnIiHxhgH.pgp Description: PGP signature
Bug#212439: ITP: libdate-ical-perl -- Perl extension for ICalendar date objects
Package: wnpp Version: unavailable; reported 2003-09-23 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libdate-ical-perl Version : 1.72 Upstream Author : Rich Bowen [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/Date-ICal/ * License : GPL / Artistic Description : Perl extension for ICalendar date objects Date::ICal talks the ICal date format, and is intended to be a base class for other date/calendar modules that know about ICal time format also. This is to satisfy a Suggests: in libtest-class-perl - -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux starlite 2.4.19-686 #1 Mon Nov 18 23:59:03 EST 2002 i686 Locale: LANG=C, LC_CTYPE=C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cK96ZNh5D+C4st4RAmfVAJ9FCNp4OdL/86+57FmyzPeKobSLHACff1Qi +q9xXYJRvIPa24rucvH8U4A= =FxhI -END PGP SIGNATURE-
Rotation of /var/log/mail.log
Hello, fellow developers ! While /var/log/mail.log is rotated nicely on my (woody) boxes, I have no idea which package is responsible for that. Any suggestions ? That would help me to solve bug #212237. Any help is welcome. Thanks Racke -- LinuXia Systems = http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP = http://www.icdevgroup.org/ Interchange Development Team
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 11:18:27PM +0200, [EMAIL PROTECTED] wrote: While /var/log/mail.log is rotated nicely on my (woody) boxes, I have no idea which package is responsible for that. Any suggestions ? /etc/cron.weekly/sysklogd This script rotates all the files which are output from running: /usr/sbin/syslogd-listfiles --weekly That would help me to solve bug #212237. If you make sure there is an entry for mail in /etc/syslog.conf then these files will be output from the 'syslogd-listfiles' and rotated correctly. Alternatively you could drop a file in /etc/logrotate.d/ to force the issue. I hope that helps; and thanks for the great work with courier. Steve -- www.steve.org.uk
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 11:18:27PM +0200, [EMAIL PROTECTED] wrote: While /var/log/mail.log is rotated nicely on my (woody) boxes, I have no idea which package is responsible for that. Any suggestions ? logrotate. -- gram signature.asc Description: Digital signature
Re: Rotation of /var/log/mail.log
On Tue, 23 Sep 2003 23:18:27 +0200 [EMAIL PROTECTED] wrote: While /var/log/mail.log is rotated nicely on my (woody) boxes, I have no idea which package is responsible for that. Any suggestions ? That would help me to solve bug #212237. Perhaps /etc/cron.weekly/sysklogd, from package sysklogd? -- Carlos Sousa http://vbc.dyndns.org/
Re: Rotation of /var/log/mail.log
Steve Kemp said on Tue, Sep 23, 2003 at 10:45:11PM +0100: While /var/log/mail.log is rotated nicely on my (woody) boxes, I have no idea which package is responsible for that. Any suggestions ? /etc/cron.weekly/sysklogd This script rotates all the files which are output from running: /usr/sbin/syslogd-listfiles --weekly That would help me to solve bug #212237. If you make sure there is an entry for mail in /etc/syslog.conf then these files will be output from the 'syslogd-listfiles' and rotated correctly. Alternatively you could drop a file in /etc/logrotate.d/ to force the issue. Please do this instead. I'm not sure why sysklogd does it's own rotation, but most other stuff uses logrotate, and it works well. M pgp597srBnu1y.pgp Description: PGP signature
Re: Rotation of /var/log/mail.log
On Tue, 23 Sep 2003 22:45:11 +0100 Steve Kemp [EMAIL PROTECTED] wrote: On Tue, Sep 23, 2003 at 11:18:27PM +0200, [EMAIL PROTECTED] wrote: While /var/log/mail.log is rotated nicely on my (woody) boxes, I have no idea which package is responsible for that. Any suggestions ? /etc/cron.weekly/sysklogd This script rotates all the files which are output from running: /usr/sbin/syslogd-listfiles --weekly Ah, ok. I tried to find it by grepping /etc, but to no avail. That would help me to solve bug #212237. If you make sure there is an entry for mail in /etc/syslog.conf then these files will be output from the 'syslogd-listfiles' and rotated correctly. Alternatively you could drop a file in /etc/logrotate.d/ to force the issue. I wonder if both rotating methods may conflict ... Thank you very much for your prompt help ! Bye Racke -- LinuXia Systems = http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP = http://www.icdevgroup.org/ Interchange Development Team
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 02:59:02PM -0700, Mark Ferlatte wrote: Please do this instead. I'm not sure why sysklogd does it's own rotation[...] Because sysklogd doesn't have a fixed set of log files. -- - mdz
Re: Rotation of /var/log/mail.log
Matt Zimmerman said on Tue, Sep 23, 2003 at 07:43:04PM -0400: On Tue, Sep 23, 2003 at 02:59:02PM -0700, Mark Ferlatte wrote: Please do this instead. I'm not sure why sysklogd does it's own rotation[...] Because sysklogd doesn't have a fixed set of log files. It does have a _default_ set of log files, which should be rotated by default. Apache doesn't have a fixed set of log files, either, but it uses logrotate just fine. As far as that goes, so does the syslog-ng syslogd replacement. It doesn't seem unreasonable to expect that if you change log file locations that you should/would have to change logrotation configuration, and having syslogd be seperate and special is just adding confusion without much gain. M pgp58Vz68q1vv.pgp Description: PGP signature
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 04:46:01PM -0700, Mark Ferlatte wrote: Matt Zimmerman said on Tue, Sep 23, 2003 at 07:43:04PM -0400: On Tue, Sep 23, 2003 at 02:59:02PM -0700, Mark Ferlatte wrote: Please do this instead. I'm not sure why sysklogd does it's own rotation[...] Because sysklogd doesn't have a fixed set of log files. It does have a _default_ set of log files, which should be rotated by default. Apache doesn't have a fixed set of log files, either, but it uses logrotate just fine. As far as that goes, so does the syslog-ng syslogd replacement. It doesn't seem unreasonable to expect that if you change log file locations that you should/would have to change logrotation configuration, and having syslogd be seperate and special is just adding confusion without much gain. sysklogd tries to be better; it adapts to the current configuration rather than leaving it up to the user to update a logrotate.d file if they change the configuration. -- - mdz
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 07:43:04PM -0400, Matt Zimmerman wrote: Please do this instead. I'm not sure why sysklogd does it's own rotation[...] Because sysklogd doesn't have a fixed set of log files. I prefer to have a default logrotate script which has some missingok,notifempty statements, because it is quite unlikely that all syslog files should be rotate in the same manner and with the same permissions. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Rotation of /var/log/mail.log
On Tue, Sep 23, 2003 at 07:51:51PM -0400, Matt Zimmerman wrote: sysklogd tries to be better; it adapts to the current configuration rather than leaving it up to the user to update a logrotate.d file if they change the configuration. # If you want to rotate other logfiles daily, edit # this script. An easy way is to add them manually # or to add -a to syslogd-listfiles and add some grep # stuff. and fails... Greetings bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Accepted binutils 2.14.90.0.6-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 23 Sep 2003 01:32:08 +0100 Source: binutils Binary: binutils-dev binutils-multiarch binutils binutils-doc Architecture: source all i386 Version: 2.14.90.0.6-3 Distribution: unstable Urgency: low Maintainer: James Troup [EMAIL PROTECTED] Changed-By: James Troup [EMAIL PROTECTED] Description: binutils - The GNU assembler, linker and binary utilities binutils-dev - The GNU binary utilities (BFD development files) binutils-doc - Documentation for the GNU assembler, linker and binary utilities binutils-multiarch - Binary utilities that support multi-arch targets Closes: 211668 212029 Changes: binutils (2.14.90.0.6-3) unstable; urgency=low . * 100_null_owner_ld_fix.dpatch: new patch from Alan Modra [EMAIL PROTECTED] to fix an ld crash with null owner sections. Closes: #212029 . * debian/rules: don't compile with gcc-2.95 on arm; the only failures are a) testsuite-only (i.e. don't appear to affect real world applications) and b) fixed by upcoming gcc patches by Phil Blundell [EMAIL PROTECTED] in any event. * debian/control (Build-Depends): likewise don't build-depend on gcc-2.95 for arm. . * 101_ppc_as_shf_and_rel_fix.dpatch: new patch from Alan Modra [EMAIL PROTECTED] to fix an as regression where it refused to compile utils.S from Linux/PPC 2.6. Closes: #211668 Files: 1302f4af69f33b42e804ec12cf02820a 869 devel standard binutils_2.14.90.0.6-3.dsc 5d6931b459fa2056f10ee77e9cef29b9 34982 devel standard binutils_2.14.90.0.6-3.diff.gz f7cda71694515efb2e5691b6ec6a72c5 418200 doc optional binutils-doc_2.14.90.0.6-3_all.deb 099085a3d4b1bf0f2a828e10b0c7fc83 2428540 devel standard binutils_2.14.90.0.6-3_i386.deb 39e71f14169bd02953648a9f593d92cd 2816324 devel extra binutils-dev_2.14.90.0.6-3_i386.deb 7c2ba3f903af0ab67b192a1b7ffac315 7959726 devel extra binutils-multiarch_2.14.90.0.6-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj9wQRMACgkQgD/uEicUG7C3WQCeIlLgpTZdmNKya6K7uzb//Yhe cbIAn3e3ftte4aJzOKYrYG6uQSlMBXTS =c8AD -END PGP SIGNATURE- Accepted: binutils-dev_2.14.90.0.6-3_i386.deb to pool/main/b/binutils/binutils-dev_2.14.90.0.6-3_i386.deb binutils-doc_2.14.90.0.6-3_all.deb to pool/main/b/binutils/binutils-doc_2.14.90.0.6-3_all.deb binutils-multiarch_2.14.90.0.6-3_i386.deb to pool/main/b/binutils/binutils-multiarch_2.14.90.0.6-3_i386.deb binutils_2.14.90.0.6-3.diff.gz to pool/main/b/binutils/binutils_2.14.90.0.6-3.diff.gz binutils_2.14.90.0.6-3.dsc to pool/main/b/binutils/binutils_2.14.90.0.6-3.dsc binutils_2.14.90.0.6-3_i386.deb to pool/main/b/binutils/binutils_2.14.90.0.6-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted vsftpd 1.2.0-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 23 Sep 2003 09:28:22 -0400 Source: vsftpd Binary: vsftpd Architecture: source i386 Version: 1.2.0-4 Distribution: unstable Urgency: high Maintainer: Daniel Jacobowitz [EMAIL PROTECTED] Changed-By: Daniel Jacobowitz [EMAIL PROTECTED] Description: vsftpd - The Very Secure FTP Daemon Closes: 212210 Changes: vsftpd (1.2.0-4) unstable; urgency=high . * Tweaks for init.d script, including starting the server if listen_ipv6 is specified (from Paul van Tilburg) (Closes: #212210). * Check for a listen configuration, but not in inetd - let the daemon start on an alternate port if it's configured to. Files: f7f92e2d2cc11307e74099026b5bd6ea 598 net extra vsftpd_1.2.0-4.dsc b744e4c39f26a9c473da07fd9a85203f 5697 net extra vsftpd_1.2.0-4.diff.gz 3b5ea959511fbc954c19c5d3c7328243 92628 net extra vsftpd_1.2.0-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cEsdbgOPXuCjg3cRAs7OAJ42VuWwHAsBc7YsN0SmHSwIkx3U/ACfX7uc f4UwmqlCjFaEdCwW0RlSlHY= =Wxix -END PGP SIGNATURE- Accepted: vsftpd_1.2.0-4.diff.gz to pool/main/v/vsftpd/vsftpd_1.2.0-4.diff.gz vsftpd_1.2.0-4.dsc to pool/main/v/vsftpd/vsftpd_1.2.0-4.dsc vsftpd_1.2.0-4_i386.deb to pool/main/v/vsftpd/vsftpd_1.2.0-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libinti-gconf1.0 1.0.5-5 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 23 Sep 2003 13:28:49 + Source: libinti-gconf1.0 Binary: libinti-gconf-doc libinti-gconf1.0 libinti-gconf-dev Architecture: source i386 all Version: 1.0.5-5 Distribution: unstable Urgency: low Maintainer: Goedson Teixeira Paixao [EMAIL PROTECTED] Changed-By: Goedson Teixeira Paixao [EMAIL PROTECTED] Description: libinti-gconf-dev - GConf bindings for Inti - development files libinti-gconf-doc - GConf bindings for Inti - documentation libinti-gconf1.0 - GConf bindings for Inti - shared libraries Changes: libinti-gconf1.0 (1.0.5-5) unstable; urgency=low . * Make debian policy 3.6.1 compliant * Recompile against libinti 1.2 * debian/rules: do not rebuild reference documentation. * debian/control: remove doxygen build-dependency. * Use dpatch to apply patches. Files: 5e8e38f92a427b01f9c84d707b6c19e8 710 libs optional libinti-gconf1.0_1.0.5-5.dsc b0d376c1d7928f54e2ceeb1eaa021d96 3491 libs optional libinti-gconf1.0_1.0.5-5.diff.gz 222694eaab75bb2d972a4d05a6a14d01 55666 doc optional libinti-gconf-doc_1.0.5-5_all.deb de1d4c1e593f2ddaaccba084a9015b04 63758 libdevel optional libinti-gconf-dev_1.0.5-5_i386.deb cbb757602de4722553913562ecc24b3f 37650 libs optional libinti-gconf1.0_1.0.5-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cFBz7tjUzB3rjq4RAlCyAKCBXhJO9zlSrT/KNlU4mHbKHw0n3ACeJVMB pwQ3hMR/t0yDdl1PqnuoPRw= =Pw1T -END PGP SIGNATURE- Accepted: libinti-gconf-dev_1.0.5-5_i386.deb to pool/main/libi/libinti-gconf1.0/libinti-gconf-dev_1.0.5-5_i386.deb libinti-gconf-doc_1.0.5-5_all.deb to pool/main/libi/libinti-gconf1.0/libinti-gconf-doc_1.0.5-5_all.deb libinti-gconf1.0_1.0.5-5.diff.gz to pool/main/libi/libinti-gconf1.0/libinti-gconf1.0_1.0.5-5.diff.gz libinti-gconf1.0_1.0.5-5.dsc to pool/main/libi/libinti-gconf1.0/libinti-gconf1.0_1.0.5-5.dsc libinti-gconf1.0_1.0.5-5_i386.deb to pool/main/libi/libinti-gconf1.0/libinti-gconf1.0_1.0.5-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dvd+rw-tools 5.12.4.7.4-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 9 Sep 2003 08:00:56 +0900 Source: dvd+rw-tools Binary: dvd+rw-tools Architecture: source i386 Version: 5.12.4.7.4-1 Distribution: unstable Urgency: low Maintainer: Keita Maehara [EMAIL PROTECTED] Changed-By: Keita Maehara [EMAIL PROTECTED] Description: dvd+rw-tools - DVD+-RW/R tools Closes: 207687 Changes: dvd+rw-tools (5.12.4.7.4-1) unstable; urgency=low . * New upstream release (closes: Bug#207687). Files: 07ae3fa70fe3fda80ec00aa2eab27014 612 utils optional dvd+rw-tools_5.12.4.7.4-1.dsc 931d47588a21a6484d946f9af6a3afbf 72139 utils optional dvd+rw-tools_5.12.4.7.4.orig.tar.gz c971e6def49301a5cd25b5672b9b0007 10042 utils optional dvd+rw-tools_5.12.4.7.4-1.diff.gz 695f7324442ec13c160a9171c7f75258 77060 utils optional dvd+rw-tools_5.12.4.7.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/cGZwJxItQqZ0o1kRAkf2AKCWmIROOrd9/MEM985iaBgQjkUU+gCeJouT glAQ21nLI4DEu15I54TG8ao= =e912 -END PGP SIGNATURE- Accepted: dvd+rw-tools_5.12.4.7.4-1.diff.gz to pool/main/d/dvd+rw-tools/dvd+rw-tools_5.12.4.7.4-1.diff.gz dvd+rw-tools_5.12.4.7.4-1.dsc to pool/main/d/dvd+rw-tools/dvd+rw-tools_5.12.4.7.4-1.dsc dvd+rw-tools_5.12.4.7.4-1_i386.deb to pool/main/d/dvd+rw-tools/dvd+rw-tools_5.12.4.7.4-1_i386.deb dvd+rw-tools_5.12.4.7.4.orig.tar.gz to pool/main/d/dvd+rw-tools/dvd+rw-tools_5.12.4.7.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libinti1.0 1.2.0-5 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 23 Sep 2003 17:11:03 + Source: libinti1.0 Binary: libinti1.0-1.2 libinti-dev inti-examples libinti-doc Architecture: source all i386 Version: 1.2.0-5 Distribution: unstable Urgency: low Maintainer: Goedson Teixeira Paixao [EMAIL PROTECTED] Changed-By: Goedson Teixeira Paixao [EMAIL PROTECTED] Description: inti-examples - Integrated Foundation classes - examples libinti-dev - Integrated Foundation classes - development files libinti-doc - Integrated Foundation classes - documentation libinti1.0-1.2 - Integrated Foundation classes - shared library Changes: libinti1.0 (1.2.0-5) unstable; urgency=low . * Fix some syntax errors in the source to make it buildable with current gcc-snapshot. Files: 329ed96b2957280e7bf11e7675f81338 718 libs optional libinti1.0_1.2.0-5.dsc 9e78bc90a0f323ff21750e61eb09d6d1 5168 libs optional libinti1.0_1.2.0-5.diff.gz 071c5630bdf16db17000e64359da7e1d 3914796 doc optional libinti-doc_1.2.0-5_all.deb e3f86beaf81f24b86da3a0848fbe9124 1598226 libdevel optional libinti-dev_1.2.0-5_i386.deb cac06210ee9a6098c89411b66bbc03bf 676330 libs optional libinti1.0-1.2_1.2.0-5_i386.deb ec94b5c36e4023c90ce8be4e34077630 362756 devel optional inti-examples_1.2.0-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/cLMi7tjUzB3rjq4RAuYhAJsGq8wXArAC96jSappiwKXIxeXi8wCfZjke 6buNehDvrgbzCKpI4ufD5Ts= =z487 -END PGP SIGNATURE- Accepted: inti-examples_1.2.0-5_i386.deb to pool/main/libi/libinti1.0/inti-examples_1.2.0-5_i386.deb libinti-dev_1.2.0-5_i386.deb to pool/main/libi/libinti1.0/libinti-dev_1.2.0-5_i386.deb libinti-doc_1.2.0-5_all.deb to pool/main/libi/libinti1.0/libinti-doc_1.2.0-5_all.deb libinti1.0-1.2_1.2.0-5_i386.deb to pool/main/libi/libinti1.0/libinti1.0-1.2_1.2.0-5_i386.deb libinti1.0_1.2.0-5.diff.gz to pool/main/libi/libinti1.0/libinti1.0_1.2.0-5.diff.gz libinti1.0_1.2.0-5.dsc to pool/main/libi/libinti1.0/libinti1.0_1.2.0-5.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
