Re: firma chiave GPG a Terni
On Sun, Sep 21, 2003 at 10:08:22PM +0200, Samuele Giovanni Tonon wrote: C'e' qualcuno che abita + vicino o che magari passa di la' per firmargliela ? Non ho in programma di passare da Terni, il massimo che posso fare e' girargli il contatto di un amico di Terni che fa spesso Terni-Bologna e ritorno, possono sentirsi per dividere un viaggio in macchina? Per ora e' il massimo aiuto che mi viene in mente ... Ciao -- Stefano Zacchiroli -- Master in Computer Science @ Uni. Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} - http://www.bononia.it/zack/ I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! -- G.Romney signature.asc Description: Digital signature
Re: firma chiave GPG a Terni
* il Sun, Sep 21, 2003 at 10:08:22PM +0200, Samuele Giovanni Tonon scriveva: ciao, [...] purtroppo il primo problema da superare e' la firma della chiave, lui e' di Terni, io di Bologna ( TR -- 350 km -- BO ) . Ciao, io sono di Roma, se vuole possiamo incontrarci qui. Contattatemi in privato qualora servisse per num. di telefono e altri dettagli. Gaetano pgpjdBrH4VOLk.pgp Description: PGP signature
Re: Traduction de menus et Gnome....UTF-8eries
On Sun, Sep 21, 2003 at 09:12:40AM +0200, Christian Perrier wrote: Suis-je le seul au monde qui, dans le Menu Debian de Gnome, a des entrées vides pour tous les répertoires dont le nom, traduit en français, comporte des accentués ? Exemple : Menu Debian/Applications/Outils Système Mmm, chez moi (LANG=fr_FR.ISO-8859-1) j'ai le menu gnome correcte (en francais et avec accent) mais le menu debian en anglais :((( Amicalement, Sen Luther
Experimental?
Existe-t-il une page qui donne des détails sur l'utilisation de experimental ? Notamment la façon d'y uploader des paquets, etc (j'ai une version beta d'un de mes paquets qui me semble bien appropriée pour experimental) --
Re: Experimental?
On Mon, Sep 22, 2003 at 11:18:29AM +0200, Christian Perrier wrote: Existe-t-il une page qui donne des détails sur l'utilisation de experimental ? Pas sur. Notamment la façon d'y uploader des paquets, etc Il te suffit de mettre experimental a la place de unstable dans le changelog. Amicalement, Sven Luther
Re: Experimental?
* Sven Luther [EMAIL PROTECTED] [2003-09-22 11:33:35 +0200]: On Mon, Sep 22, 2003 at 11:18:29AM +0200, Christian Perrier wrote: Existe-t-il une page qui donne des détails sur l'utilisation de experimental ? Pas sur. http://www.debian.org/doc/developers-reference/ch-resources#s-experimental -- Igor Genibel http://www.answare.fr/ [EMAIL PROTECTED] http://www.tuxfamily.org/[EMAIL PROTECTED] http://people.debian.org/~igenibel [EMAIL PROTECTED] GPG: 1024D/9D735B4F: 4F61 8D8F 05AC 8D2C 5F92 9B99 C44B 0266 9D73 5B4F
Re: Experimental?
Sven Luther a écrit : [...] Il te suffit de mettre experimental a la place de unstable dans le changelog. question con, au passage : c'est quoi exactement, experimental ? Je connaît stable/testing/unstable, mais experimental ? Claude
Re: Experimental?
On Mon, Sep 22, 2003 at 02:44:45PM +0200, claude wrote: Sven Luther a écrit : [...] Il te suffit de mettre experimental a la place de unstable dans le changelog. question con, au passage : c'est quoi exactement, experimental ? Je connaît stable/testing/unstable, mais experimental ? Mmm, tu n'a pas lu le message de aj a propos de experimental et de la release de sarge, je vois. Experimental est un pool additionel pour des packages trop experimental pour unstable. Experimental fut jusqu'a maintenant rarement utilise, et apt-get ne va pas installer des packages de experimental tout seul, meme si tu a experimental dans ton sources.list. Le nouveau plan prevoit d'utiliser plus experimental, pour des snapshots CVS ou des versions de developpement de packages, en attendant qu'il soit pret pour entrer dans unstable. Il s'agit en fait du niveau supplementaire apres testing et unstable qui a ete reclame souvent depuis des annees. Amicalement, Sven Luther
Re: Experimental?
On Mon, Sep 22, 2003 at 02:44:45PM +0200, claude wrote: question con, au passage : c'est quoi exactement, experimental ? Je connaît stable/testing/unstable, mais experimental ? Le même sujet vient juste d'être posté sur debian-devel. cf: http://www.debian.org/doc/developers-reference/ch-resources#s-experimental Phil -- Philippe Hétroy, [EMAIL PROTECTED]
Re: Traduction de menus et Gnome....UTF-8eries
On Sun, Sep 21, 2003 at 09:12:40AM +0200, Christian Perrier wrote:
[...]
Je précise que mes locales sont fr_FR.ISO-8859-15 (c'est dans
/etc/environment et c'est aussi ce que je choisis avec gdm, donc
GDM_LANG=fr_FR.ISO-8859-15)
T'es sûr ? Cette locale n'existe pas, tu devrais être en
[EMAIL PROTECTED]
Du coup, update-menus s'exécute avec LANG=fr_FR.ISO-8859-15.
Si, par contre, je le force à s'exécuter avec LANG=fr_FR.UTF-8, tout
va alors bienmême quand je fais afficher les menus dans un
environnement en ISO-8859-15
As-tu essayé de positionner la variable d'envireonnement G_BROKEN_FILENAMES ?
Update-menus crée des fichiers en codant le nom dans la locale en cours,
et donc tu dois positionner cette variable si tu n'es pas en UTF-8.
C'est quand même un beau bordel (ou alors un truc simple vachement mal
expliqué) tout ce fourbi. J'ai d'ailleurs beau faire des tas de
tentatives pour faire du tout UTF-8, je finis toujours par revenir au
bon vieil ISO-8859-{1|15} quand j'en ai marre de voir ou d'envoyer des
hiéroglyphes.
C'est pas logique, tu dis que ça marche mieux en UTF-8 ;)
Denis
RE: apt-get'able Release file format
Matt Zimmerman wrote: That sounds backwards. Component is the one recognized by apt, and (naturally) the one used by official Release files in the Debian archive. Components: updates/main updates/contrib updates/non-free [1] ... Adam [1] http://klecker.debian.org/debian-security/dists/woody/updates/Release
Re: apt-get'able Release file format
On Sun, Sep 21, 2003 at 10:20:36PM -0600, Adam Conrad wrote:
Matt Zimmerman wrote:
That sounds backwards. Component is the one recognized by apt, and
(naturally) the one used by official Release files in the
Debian archive.
Components: updates/main updates/contrib updates/non-free [1]
... Adam
[1] http://klecker.debian.org/debian-security/dists/woody/updates/Release
apt doesn't read that Release file (yet; this is part of the apt-secure
enhancements). It currently only pays attention to
{main,contrib,non-free}/{binary-*,source}/Release.
Even in apt-secure, I don't think it presently pays attention to that
Components field.
--
- mdz
Re: Maintaining kernel source in sarge
On Mon, 22 Sep 2003 11:27, Manoj Srivastava wrote: The scripts handle ordering by testing each dependency, and if it is not already applied, invoking the corresponding apply script. In this way, all dependencies should be applied in proper order. Rollback could presumably be implemented by unapplying all patches if any patch fails (dh-kpatches should now implement correct ordering for unapplication as well). Well, if I have asked for 5 patches to be applied (preempt, lowlatency, skas, device-mapper, lsm2, and debianlogo, in a recent invocation), the lsm2 script indeed failed -- but only after preempt, lowlatency, skas, and device-mapper patches were applied (I did not have acl kernel-patch on the machine). It would have been nice to know about that before all the patches were applied. I think that's a bug. The next upload of the kernel-patch-2.4-lsm package will depend on the ACL patch package. Also I will split the package and put the patch for the old SE Linux in a separate package on my web site. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bug#212049: dependency used backwards
On Mon, 2003-09-22 at 00:24, Daniel B. wrote in part: Debian seems to use the word dependency backwards a lot, making things confusing and hard to understand. [...] If A depends on B, then A is a dependency (A is dependent on B). B is _not_ a dependency of A. The word 'dependency' can denote the relation between A and B ; then it isn't oriented one way or the other, e.g., 'There is a dependency between A and B'. To indicate the orientation you have to say something like 'A depends on B'. I think you make a worthwhile point that in some cases the direction of the dependency should be indicated more clearly. In Debian (documentation, executable output, e-mail), uses of dependency in sense 1 are usually fine. However, uses in sense 2 are usually backwards (see bugs 212028, 212013, and especially 212034, which also shows how weak an understanding some Debian developers have of the word). You meant #212031. Since merely using dependency correctly would be ambiguous given all the incorrect usage, Debian should probably refer to depended-on package (or library, etc., as the case may be). That construct would be unambiguous and perfectly clear (and wouldn't be much longer than dependency). Suppose we are talking about A. Then your complaint is that A's dependencies is ambiguous between denoting the packages that depend on A and the packages upon which A depends. I don't see how A's depended-on packages is any clearer. Actually it seems worse to me. I suggest using packages upon which A depends and packages that depend on A wherever the ambiguity matters. -- Thomas Hood [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
On Sunday 21 September 2003 14:41, Herbert Xu wrote: martin f krafft [EMAIL PROTECTED] wrote: I am the kernel-patch-2.4-grsecurity maintainer, and I have been flooded with grave and important bugs ever since kernel version 2.4.20, since grsecurity does not apply to these kernel versions anymore. It doesn't apply to the Debianised versions of these kernels anymore, it applies to the vanilla kernel just fine. I've got a few points for you: * The vanilla kernel source is readily available: Yes, but it is not available in a finest way possible. apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22 tar xjf /usr/src/kernel-source-2.4.22.tar.bz2 cd kernel-source-2.4.22 /usr/src/kernel-patches/all/2.4.22/unpatch/debian This is misleading by the way of kernel source tree you provide. kernel-source-2.4.22 must contain just plain vanilla kernel sources + debian/ directory. Then if I want your backported patches (or anything else) I'll apt-get install kernel-patch-debian-2.4.22 and patch (NOTE: not to *unpatch*) the 2.4.22 source tree. * The IPSEC backport can be easily reversed by unapplying the patches given in the README.Debian file. it is better to provide in README.Debian patches (made as debian pacvkages) you suggest to be applied not to unapplied. * The IPSEC backport has minimal effect on the binary images. It has no effect unless you load the relevant modules. The increase in size is tiny compared to the increases brought on by ACPI and compiler changes. I agree it is nice to have kernel patches as debian packages, but if the name of kernel source tree is kernel-source-2.4.22 it should provide 2.4.22 vanilla sources otherwise name it kernel-source-2.4.22-vendor-debian. So either get the people who're complaining to you to unapply the IPSEC patch, or fix your patch instead. it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is useless, leave to users to patch if they want) then all other kernel-patch-whatever packages will be fine. -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: Debian should not modify the kernels!
On Sunday 21 September 2003 16:04, Josip Rodin wrote: On Sun, Sep 21, 2003 at 02:44:03PM +0200, martin f krafft wrote: * The vanilla kernel source is readily available: I don't consider this readily available. It's faster to just download it from kernel.org. Frankly, I doubt that. Debian mirror network seems better to me. I am biased, but still. :) because debian's readily available's and to save bandwidth when updating I use some of the followings to get vanillas, then I use the awesome make-kpkg: Subversion (http://svnbook.red-bean.com/) === Trunk (main/latest) - 2.4, 2.5, 2.6 -- # svn co svn://kernel.bkbits.net/linux-2.4/trunk linux-2.4-trunk # svn co svn://kernel.bkbits.net/linux-2.5/trunk linux-2.5-trunk # svn co svn://kernel.bkbits.net/linux-2.6/trunk linux-2.6-trunk Revisions - 2.4, 2.5 - # svn co svn://kernel.bkbits.net/linux-2.4/tags/v2.4.X linux-2.4.X # svn co svn://kernel.bkbits.net/linux-2.5/tags/v2.5.X linux-2.5.X # cd kernel-src-dir # svn log ChangeLog CVS (http://www.cvshome.org/) === Trunk (main/latest) - 2.4, 2.5 -- # cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co linux-2.4-trunk # cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co linux-2.5-trunk -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: Debian should not modify the kernels!
Hi! Am 2003-09-21 13:09 +0200 schrieb martin f krafft: If I install kernel-source-2.4.21, I want the 2.4.21 kernel source, I don't want the 2.4.21 kernel source with 2.5's IPsec stack patched in and hundreds of little fixes. I fully agree with this. Speaking as an user, it is perfectly okay and desirable to have a _default_ installation Debian kernel which is patched (security, ALSA, whatever). Those users who don't care or don't know about kernel compiling issues will rest in peace and will benefit from updated packages from time to time. But as soon as I plan to compile a kernel by myself, I expect that the content delivers what its label promises! Thats a matter of principle, not a matter of measure. yeah, but look at distribution xyz, they do it even worse is IMHO not the best approach, Debian should not clone other's faults but try to be better. Thus, I propose: - a package kernel-debian-default (or similar), which is patched at the maintainer's will and regularly updated with new features and security patches. This is for users that don't compile their own kernels, thus the package should not contain the source code. - packages kernel-x.y.z which contains an _unmodified_ upstream kernel source; patches can be applied to it by installing kernel-patch-x.y.z-patchname (the way it currently is intended) Thanks and have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED] pgprqaPMRehw8.pgp Description: PGP signature
Re: apt-get'able Release file format
Hello,
On Mon, Sep 22, 2003 at 12:48:24AM -0400, Matt Zimmerman wrote:
On Sun, Sep 21, 2003 at 10:20:36PM -0600, Adam Conrad wrote:
Matt Zimmerman wrote:
That sounds backwards. Component is the one recognized by apt, and
(naturally) the one used by official Release files in the
Debian archive.
...
apt doesn't read that Release file (yet; this is part of the apt-secure
enhancements). It currently only pays attention to
{main,contrib,non-free}/{binary-*,source}/Release.
Even in apt-secure, I don't think it presently pays attention to that
Components field.
^^
Component?
Jochen
--
http://seehuhn.de/
signature.asc
Description: Digital signature
Re: Debian should not modify the kernels!
On Sun, Sep 21, 2003 at 05:05:46PM +0200, martin f krafft wrote: also sprach Mark Brown [EMAIL PROTECTED] [2003.09.21.1644 +0200]: effects (better hardware support, more features, better performance or what have we) are generally seen to be worthwhile. ... in addition to possibly more bugs and the inability of interaction with the kernel and the rest of the world. linux-kernel Well, yes. This is one reason for not just slinging in any old patches and being willing to provide support for the kernel you ship. Things like 2.5 backports are reasonably safe even if they introduce ABI changes, for example - the kernel maintainers have made some commitment to providing that ABI already. I am not saying that all this shouldn't happen. I am just saying it shouldn't be the default. Debian is about choice, isn't it? Well, opt-in choice it should be! Well, what you seem to want is to have the kernel source avaliable in a format that makes packaging kernel patches easy. That seems like a different issue to me. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Debian should not modify the kernels!
On Sun, Sep 21, 2003 at 12:00:05PM -0700, Erik Steffl wrote: if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as a debian package, not something else... any debian specific changes should result in kernel name change, that's what's expected in kernel world (when I get ac kernel I get 2.4.22-ac3) Me too - if we have to have significantly modified kernels, they should be labelled as being such. If the issue here is the grsec patch distributed as a debian package cannot cleanly apply to the debian kernel sources because they have been significantly modified; why aren't those modifications distributed as seperate kernel patches / debian packages in the same way grsec is? -- Jon Dowland http://jon.dowland.name/
HP40%
8HP HP6L450420400200 HP5000135013001800450150 HP021-32270228www.savemoney.com.cn(
Bug#212137: ITP: trm -- calculate the TRM acoustic fingerprint for an audio file
Package: wnpp Version: unavailable; reported 2003-09-22 Severity: wishlist * Package name: trm Version : 0.2.1 Upstream Author : Robert Kaye [EMAIL PROTECTED] * URL : ftp://ftp.musicbrainz.org/pub/musicbrainz/ * License : GPL Description : calculate the TRM acoustic fingerprint for an audio file The trm program will decode the first 30 seconds of the audio file and then spit out a TRM id (see http://www.relatable.com for details) on stdout. If some error occurs, the error message is printed to stderr. TRM is an audio fingerprinting technology that generates a unique fingerprint for an audio file based on an analysis of the acoustic properties of the audio itself. Each audio fingerprint is unique and can be used to identify a track precisely, regardless of whether any associated text identifiers are present or accurate. The program takes and understands OGG, MP3 and WAV as input files. It calculates the TRM with the help of the Musicbrainz library libmusicbrainz2. This package also contains trmtest.pl. The script will call cdparanoia to rip the first 30 seconds of each track of a audio CD in your primary CD-ROM drive, encode to mp3 with lame (if present), to ogg/vorbis with oggenc and then use the trm utility to get the TRM for each of the three versions. Once the entire CD has been processed, it writes a CSV (comma separated values) file as the output file. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux schuh 2.4.22-jj1 #12 Tue Sep 9 22:20:42 UTC 2003 i686 Locale: LANG=C, LC_CTYPE=en_US.UTF-8
Re: Debian should not modify the kernels!
* Martin Pitt [EMAIL PROTECTED] [030922 10:40]: Speaking as an user, it is perfectly okay and desirable to have a _default_ installation Debian kernel which is patched (security, ALSA, whatever). Those users who don't care or don't know about kernel compiling issues will rest in peace and will benefit from updated packages from time to time. But as soon as I plan to compile a kernel by myself, I expect that the content delivers what its label promises! Thats a matter of principle, not a matter of measure. yeah, but look at distribution xyz, they do it even worse is IMHO not the best approach, Debian should not clone other's faults but try to be better. Speaking as a user, too, I want something I can compile a kernel from. I'm no kernel hacker and do not intend to become one. Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. Escecially as an unmodified source-tree is in my experience almost only useful for i386. (Perhaps getting better in the last time, but anything not a debian kernel used to be even a larger nightmare than the debian-kernels). So your complain reduces in my eyes to an incomplete label. I personally think not having the term linux in it more of an issue than having -debian in it... Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Debian should not modify the kernels!
Hi! Am 2003-09-22 12:13 +0200 schrieb Bernhard R. Link: Speaking as a user, too, I want something I can compile a kernel from. I'm no kernel hacker and do not intend to become one. Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. I agree. I never use Debian kernel packages anyway and even if they were unpatched, they were only of little use to _me_ (apart from problems like faster mirror/cd distributions). However, they might be useful to people using make-kpkg and patch packages to get the right dependencies and ease the download. Thus I would not vote to throw them out completely. So your complain reduces in my eyes to an incomplete label. Partly. But it also extends to the technical level: When shipping kernel-patch packages, then Debian should have a common codebase to diff against; the straightforward choice is IMHO the pristine upstream version, shipped in a kernel package. Escecially as an unmodified source-tree is in my experience almost only useful for i386. I don't know much about other arches, but patching the source tree is certainly arch independent. The i386 won't help if a grsecurity patch does not apply because the source is messed up and the user does not know about it (since it _claimed_ to be the original code). Platform-specific patches should certainly go into the Debian default installation kernel, but that is a completely different issue. Have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
hi, On Mon, Sep 22, 2003 at 12:13:51PM +0200, Bernhard R. Link wrote: Speaking as a user, too, I want something I can compile a kernel from. I'm no kernel hacker and do not intend to become one. Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. Escecially as an unmodified source-tree is in my experience almost only useful for i386. (Perhaps getting better in the last time, but anything not a debian kernel used to be even a larger nightmare than the debian-kernels). i have to say, that an vanilla kernel-source in Debian would be nice, but i never had Problems with compiling the source Packages which are in the Distribution now. I think the Kernel-Source-Package Maintainers know what they are doin, and if the Patches are limited to Security Fixes and things which make the Kernel more stable and secure i don't have Problems with the current situation. People which do not want to take the Debian Sources because, the're patched, have the possibility to use the Kernel Sources from kernel.org, and use make-kpkg to create an Debian Package. bye, - michael
Re: Debian should not modify the kernels!
#include hallo.h * George Danchev [Mon, Sep 22 2003, 10:40:10AM]: This is misleading by the way of kernel source tree you provide. kernel-source-2.4.22 must contain just plain vanilla kernel sources + debian/ directory. Then if I want your backported patches (or anything else) I'll apt-get install kernel-patch-debian-2.4.22 and patch (NOTE: not to *unpatch*) the 2.4.22 source tree. Let's create a package called linux-2.4.22 or linux-2.4.22-pure-vanilla-source-for-you-to-patch with a script which does exactly this. MfG, Eduard. -- Das Unglück der Weiber ist, daß sie nicht imstande sind, Männer so keck zu verachten als Weiber. -- Jean Paul
Re: Debian should not modify the kernels!
#include hallo.h * Jonathan Dowland [Mon, Sep 22 2003, 10:05:13AM]: if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as a debian package, not something else... any debian specific changes should result in kernel name change, that's what's expected in kernel world (when I get ac kernel I get 2.4.22-ac3) Me too - if we have to have significantly modified kernels, they should be labelled as being such. They are - look at the last part of the kernel-image-KVERS image. And if you meant the kernel-source package, then please think twice before you request a such thing. Your idea would require dozens of versions of kernel-source-NUMBER-foo every time when I a small fix had to be applied. If you prefer to sponsor new harddisks for all Debian mirrors (because the archive size explodes), please do. If the issue here is the grsec patch distributed as a debian package cannot cleanly apply to the debian kernel sources because they have been Reality check please. grsec modifies the kernel so heavily that it will ALWAYS conflict with something when you modify the kernel a bit more that with trivial bugfixes. The same would happen if it conflicts with ANY of the 93 kernel-patches in the archive - there is no reason for rants on -devel. significantly modified; why aren't those modifications distributed as seperate kernel patches / debian packages in the same way grsec is? Martin can _simply_ create an alternative apply script which unpatches the Debian source when needed before applying the grsec patch. Quiet, transparent solution. MfG, Eduard. -- Als Passwort nahm er seinen Namen, bis eines Nachts die Hacker kamen.
Re: Debian should not modify the kernels!
On Monday 22 September 2003 13:13, Bernhard R. Link wrote: * Martin Pitt [EMAIL PROTECTED] [030922 10:40]: Speaking as an user, it is perfectly okay and desirable to have a _default_ installation Debian kernel which is patched (security, ALSA, whatever). Those users who don't care or don't know about kernel compiling issues will rest in peace and will benefit from updated packages from time to time. But as soon as I plan to compile a kernel by myself, I expect that the content delivers what its label promises! Thats a matter of principle, not a matter of measure. yeah, but look at distribution xyz, they do it even worse is IMHO not the best approach, Debian should not clone other's faults but try to be better. Speaking as a user, too, I want something I can compile a kernel from. I'm afraid that more people here speak as maintainers and the point is about what kind(s) of kernel-source packages Debian provides... it is not just something you compile kernel images from... it has reasonable names following the content it provides;-) I'm no kernel hacker and do not intend to become one. Thus I see absolutely no reason, why I should want a debian-package with a unmodified source-tree. Let me point out that Debian has always provided upstream (unmodified/ pristine) kernel source by the means of kernel-source-x.y.z packages and kernel-patch-whatever ... and so on ... Now with kernel-source-2.4.22 the situation has been changed... Please read /usr/share/doc/kernel-source-2.4.22/README.Debian.gz for more. Nice patch has been applied to vanilla sources (note: provided by kernel-source-2.4.22) instead just being distributed as regular kernel-patch-ipsec-or-so ... Note that this patch doesn't fix security issue(s), but instead adds a feature. It is all fine, but let the user decides if s/he wants to have it applied against vanilla sources and do it his/herself... Otherwise you convey debian users to kernel.org or bkbits.net to get pristine sources and then apply patches if any. Escecially as an unmodified source-tree is in my experience almost only useful for i386. (Perhaps getting better Not true ;-) So called by you unmodified has all architecture-specific code inside. Get a kernel from kernel.org or svn from bkbits.net and cd arch/ in the last time, but anything not a debian kernel used to be even a larger nightmare than the debian-kernels). Now you have a real nightmare with kernel-source-2.4.22 (named to bring the upstream 2.4.22, but instead patched and that was documented of course, but that is not the Debian way of dealing with kernels) breaking bunch of usefull kernel-patch-whatever. Again, if the aboves continue to happen, then most likely bunch of users will get their pristine kernel sources not from debian archive (which is sad) and patch on-their-demand. Reasonable names following the spirit of debian imho are: kernel-source-2.4.22 (strict vanilla) kernel-patch-debian-2.4.22 (patch applied by Debian, Hurray ! yet another vendor specific kernel source tree ;-) kernel-patch-other-features-version (other usefull patches) -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Bug#141179: marked as done (rcconf should depend on whiptail-provider instead of whiptail)
Your message dated Sun, 21 Sep 2003 13:17:06 -0400
with message-id [EMAIL PROTECTED]
and subject line Accepted rcconf 1.6 (all source)
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 4 Apr 2002 16:16:06 +
From [EMAIL PROTECTED] Thu Apr 04 10:16:06 2002
Return-path: [EMAIL PROTECTED]
Received: from laweleka.austria.eu.net [193.154.160.152]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 16t9u9-0006m1-00; Thu, 04 Apr 2002 10:16:05 -0600
Received: from asgard.pte.at (fidix.fidentia.at [195.230.46.26])
by laweleka.austria.eu.net (8.12.1/8.12.1) with ESMTP id g34GG3aY015269
for [EMAIL PROTECTED]; Thu, 4 Apr 2002 18:16:03 +0200 (MEST)
Received: from alfie by asgard.pte.at with local (Exim 3.35 #1 (Debian))
id 16t9rT-0001M4-00
for [EMAIL PROTECTED]; Thu, 04 Apr 2002 18:13:19 +0200
Date: Thu, 4 Apr 2002 18:13:19 +0200
From: Gerfried Fuchs [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: rcconf should depend on whiptail-provider instead of whiptail
Message-ID: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-Reportbug-Version: 1.49
Mail-Copies-To: nobody
X-Editor: Vi Improved http://www.vim.org/
X-Signature-Color: cyan
X-Signature-Prg: sigd/0.9.1 (Perl) http://alfie.ist.org/sigd/
X-Face: `Q5\Ix+YG'{KDq5mcZL8Sp7$[L|%#^MSk'{QppJ8.RP*P9{{6$8%_~*:6c{);e:s
!:C2%IH-5:GT,Sf3Xx}di,JDbDRH/;-eb{n`VSi*}-R2,[EMAIL PROTECTED]
{3w}E7d}+GN|v=gDc;.c(xiy{Og_=2cy)T1JLu}y6Onsr
Sender: Gerfried Fuchs [EMAIL PROTECTED]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by laweleka.austria.eu.net
id g34GG3aY015269
Delivered-To: [EMAIL PROTECTED]
Package: rcconf
Version: 1.3
Severity: important
Hi!
rcconf should be able to be installable with whiptail-utf8. whiptail
and whiptail-utf8 both have the Provides: whiptail-provider control line
which seems to be a virtual package to let the user decide which version
of whiptail s/he wants to use.
If you dislike this idea you should at least let it
Depends: whiptail | whiptail-utf8
for letting it work.
Have fun, and thanks,
Alfie
--=20
Erich Aquariophile: aber du k=F6nntest mal mit man reden, der kennt
fast alles...
Aquariophile wo ist der?
Aquariophile ne, stop -- habs kapier
---
Received: (at 141179-done) by bugs.debian.org; 22 Sep 2003 10:20:20 +
From [EMAIL PROTECTED] Mon Sep 22 05:20:19 2003
Return-path: [EMAIL PROTECTED]
Received: from bangpath.uucico.de [195.71.9.197]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1A1Nnn-0001He-00; Mon, 22 Sep 2003 05:20:19 -0500
Received: by bangpath.uucico.de (Postfix, from userid 10)
id D7C7E26BC3; Mon, 22 Sep 2003 12:20:18 +0200 (CEST)
Received: by deprecation.cyrius.com (Postfix, from userid 1000)
id A88BBFF05; Mon, 22 Sep 2003 20:19:00 +1000 (EST)
Resent-From: [EMAIL PROTECTED]
Resent-Date: Mon, 22 Sep 2003 20:19:00 +1000
Resent-Message-ID: [EMAIL PROTECTED]
Resent-To: [EMAIL PROTECTED]
X-Original-To: [EMAIL PROTECTED]
Received: by deprecation.cyrius.com (Postfix, from userid 10)
id 682D31018C; Mon, 22 Sep 2003 09:42:50 +1000 (EST)
Received: from murphy.debian.org (murphy.debian.org [146.82.138.6])
by bangpath.uucico.de (Postfix) with ESMTP id 130B326B2E
for [EMAIL PROTECTED]; Sun, 21 Sep 2003 19:59:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by murphy.debian.org (Postfix) with QMQP
id E07A81FC12; Sun, 21 Sep 2003 12:59:31 -0500 (CDT)
Old-Return-Path: [EMAIL PROTECTED]
Received: from auric.debian.org (auric.debian.org [206.246.226.45])
by murphy.debian.org (Postfix) with ESMTP id 9C87F20170
for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:23:22
-0500 (CDT)
Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian))
id 1A17pa-sP-00; Sun, 21 Sep 2003 13:17:06 -0400
From: Atsushi KAMOSHIDA [EMAIL PROTECTED]
To: debian-devel-changes@lists.debian.org
X-Katie: $Revision: 1.35 $
Subject: Accepted rcconf 1.6 (all source)
Message-Id: [EMAIL PROTECTED]
Sender: Archive Administrator [EMAIL PROTECTED]
Date: Sun, 21 Sep 2003 13:17:06 -0400
Reply-To: debian-devel@lists.debian.org
Mail-Followup-To: debian-devel@lists.debian.org
X-Spam-Status: No, hits=-2.9 required=4.0
Bug#166518: marked as done (rcconf conflicts with file-rc but its description tells it is compatible with file-rc)
Your message dated Sun, 21 Sep 2003 13:17:06 -0400 with message-id [EMAIL PROTECTED] and subject line Accepted rcconf 1.6 (all source) has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 26 Oct 2002 20:48:52 + From [EMAIL PROTECTED] Sat Oct 26 15:48:51 2002 Return-path: [EMAIL PROTECTED] Received: from guerard.net1.nerim.net (corbeaunoir.org) [62.212.108.247] (foobar) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 185XrX-00024Y-00; Sat, 26 Oct 2002 15:48:51 -0500 Received: from yakkuru (dauphingris.nulle.part [172.16.16.68]) by corbeaunoir.org (Postfix) with ESMTP id 7C23A4B8E6; Sat, 26 Oct 2002 22:48:49 +0200 (CEST) Received: by yakkuru (Postfix, from userid 1000) id 6B3CC33671E; Sat, 26 Oct 2002 22:07:05 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit From: =?iso-8859-15?q?Jean-Philippe_Gu=E9rard?= [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: rcconf conflicts with file-rc but its description tells it is compatible with file-rc X-Mailer: reportbug 2.8 Date: Sat, 26 Oct 2002 22:07:05 +0200 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=0.6 required=5.0 tests=SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: Package: rcconf Version: 1.3 (not installed) Severity: normal The rcconf description indicates : Rcconf works with both System-V style and file-rc runlevel = configuration. But rcconf conflicts with file-rc. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux yakkuru 2.4.20-pre7-ac3 #1 lun sep 30 13:15:46 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] --- Received: (at 166518-done) by bugs.debian.org; 22 Sep 2003 10:20:28 + From [EMAIL PROTECTED] Mon Sep 22 05:20:28 2003 Return-path: [EMAIL PROTECTED] Received: from bangpath.uucico.de [195.71.9.197] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1A1Nnn-0001Hd-00; Mon, 22 Sep 2003 05:20:19 -0500 Received: by bangpath.uucico.de (Postfix, from userid 10) id C47FC26BC2; Mon, 22 Sep 2003 12:20:18 +0200 (CEST) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 64D33FF05; Mon, 22 Sep 2003 20:18:47 +1000 (EST) Resent-From: [EMAIL PROTECTED] Resent-Date: Mon, 22 Sep 2003 20:18:47 +1000 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Received: by deprecation.cyrius.com (Postfix, from userid 10) id 682D31018C; Mon, 22 Sep 2003 09:42:50 +1000 (EST) Received: from murphy.debian.org (murphy.debian.org [146.82.138.6]) by bangpath.uucico.de (Postfix) with ESMTP id 130B326B2E for [EMAIL PROTECTED]; Sun, 21 Sep 2003 19:59:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E07A81FC12; Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from auric.debian.org (auric.debian.org [206.246.226.45]) by murphy.debian.org (Postfix) with ESMTP id 9C87F20170 for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:23:22 -0500 (CDT) Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 1A17pa-sP-00; Sun, 21 Sep 2003 13:17:06 -0400 From: Atsushi KAMOSHIDA [EMAIL PROTECTED] To: debian-devel-changes@lists.debian.org X-Katie: $Revision: 1.35 $ Subject: Accepted rcconf 1.6 (all source) Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 13:17:06 -0400 Reply-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org X-Spam-Status: No, hits=-2.9 required=4.0 tests=PGP_SIGNATURE version=2.55-lists.debian.org_2003_9_21 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55-lists.debian.org_2003_9_21 (1.174.2.19-2003-05-19-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel-changes@lists.debian.org X-Mailing-List: debian-devel-changes@lists.debian.org archive/latest/162713 X-Loop: debian-devel-changes@lists.debian.org List-Id: debian-devel-changes.lists.debian.org List-Post: mailto:debian-devel-changes@lists.debian.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe:
Bug#60405: marked as done (rcconf: Please translate manpage to English :))
Your message dated Sun, 21 Sep 2003 13:17:06 -0400 with message-id [EMAIL PROTECTED] and subject line Accepted rcconf 1.6 (all source) has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 14 Mar 2000 23:41:37 + Received: (qmail 30213 invoked from network); 14 Mar 2000 23:41:35 - Received: from ppp3.math.bme.hu (HELO utopia) ([EMAIL PROTECTED]) by master.debian.org with SMTP; 14 Mar 2000 23:41:35 - Received: (qmail 1529 invoked by uid 1000); 14 Mar 2000 23:18:28 - Date: 14 Mar 2000 23:18:28 - Message-ID: [EMAIL PROTECTED] From: KORN Andras [EMAIL PROTECTED] Subject: rcconf: Please translate manpage to English :) To: [EMAIL PROTECTED] X-Mailer: bug 3.3.2 Package: rcconf Version: 0.2 Severity: normal Hi, rcconf's manpage is in rather poor English (no offense meant), and so more than hard to understand. Perhaps you could ask someone with a better grasp of the language to rephrase it for you? (I would gladly do that; alas, I don't understand the text myself.) Andrew -- Andrew Korn (Korn Andras) [EMAIL PROTECTED] http://goliat.eik.bme.hu/~korn Finger [EMAIL PROTECTED] for pgp key. Homepage is obsolete. QOTD: Stop vandalism - or we'll smash your window! -- System Information Debian Release: woody Kernel Version: Linux utopia 2.2.14 #67 Sun Jan 23 11:54:12 CET 2000 i586 unknown --- Received: (at 60405-done) by bugs.debian.org; 22 Sep 2003 10:20:20 + From [EMAIL PROTECTED] Mon Sep 22 05:20:20 2003 Return-path: [EMAIL PROTECTED] Received: from bangpath.uucico.de [195.71.9.197] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1A1Nno-0001Hu-00; Mon, 22 Sep 2003 05:20:20 -0500 Received: by bangpath.uucico.de (Postfix, from userid 10) id 047F426BBF; Mon, 22 Sep 2003 12:20:19 +0200 (CEST) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id D6747FF09; Mon, 22 Sep 2003 20:19:49 +1000 (EST) Resent-From: [EMAIL PROTECTED] Resent-Date: Mon, 22 Sep 2003 20:19:49 +1000 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED], [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Received: by deprecation.cyrius.com (Postfix, from userid 10) id 682D31018C; Mon, 22 Sep 2003 09:42:50 +1000 (EST) Received: from murphy.debian.org (murphy.debian.org [146.82.138.6]) by bangpath.uucico.de (Postfix) with ESMTP id 130B326B2E for [EMAIL PROTECTED]; Sun, 21 Sep 2003 19:59:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E07A81FC12; Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from auric.debian.org (auric.debian.org [206.246.226.45]) by murphy.debian.org (Postfix) with ESMTP id 9C87F20170 for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:23:22 -0500 (CDT) Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 1A17pa-sP-00; Sun, 21 Sep 2003 13:17:06 -0400 From: Atsushi KAMOSHIDA [EMAIL PROTECTED] To: debian-devel-changes@lists.debian.org X-Katie: $Revision: 1.35 $ Subject: Accepted rcconf 1.6 (all source) Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 13:17:06 -0400 Reply-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org X-Spam-Status: No, hits=-2.9 required=4.0 tests=PGP_SIGNATURE version=2.55-lists.debian.org_2003_9_21 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55-lists.debian.org_2003_9_21 (1.174.2.19-2003-05-19-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel-changes@lists.debian.org X-Mailing-List: debian-devel-changes@lists.debian.org archive/latest/162713 X-Loop: debian-devel-changes@lists.debian.org List-Id: debian-devel-changes.lists.debian.org List-Post: mailto:debian-devel-changes@lists.debian.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Archive: http://lists.debian.org/debian-devel-changes/ Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Delivered-To: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 01:41:31 +0900 Source: rcconf Binary: rcconf Architecture: source all Version: 1.6 Distribution: unstable Urgency: low Maintainer:
Bug#144053: marked as done (rcconf: Rcconf does not clean up after exiting (when running as normal user))
Your message dated Sun, 21 Sep 2003 13:17:06 -0400 with message-id [EMAIL PROTECTED] and subject line Accepted rcconf 1.6 (all source) has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 22 Apr 2002 14:07:25 + From [EMAIL PROTECTED] Mon Apr 22 09:07:25 2002 Return-path: [EMAIL PROTECTED] Received: from buzz.etsit.upm.es [138.100.17.60] by master.debian.org with smtp (Exim 3.12 1 (Debian)) id 16zeTU-0002BE-00; Mon, 22 Apr 2002 09:07:24 -0500 Received: (qmail 15150 invoked from network); 22 Apr 2002 14:07:19 - Received: from localhost (127.0.0.1) by localhost with SMTP; 22 Apr 2002 14:07:19 - Received: (qmail 15147 invoked from network); 22 Apr 2002 14:07:19 - Received: from avalon.dat.etsit.upm.es (138.100.17.15) by buzz.etsit.upm.es with SMTP; 22 Apr 2002 14:07:19 - Received: (qmail 2471 invoked by uid 1013); 22 Apr 2002 14:07:23 - Message-ID: [EMAIL PROTECTED] From: Javier Fernandez-Sanguino Pena [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: rcconf: Rcconf does not clean up after exiting (when running as normal user) X-Mailer: reportbug 1.44 Date: Mon, 22 Apr 2002 16:07:23 +0200 Delivered-To: [EMAIL PROTECTED] Package: rcconf Version: 1.2 Severity: normal When a user runs rcconf it will not check that he will not be able to do any changes (i.e. modify /var/lib/rcconf/services). However it will lock the program at /var/lock/. When the user selects ok it will bail out with : Cannot write file /var/lib/rcconf/services: Permission denied at /usr/bin/rcconf line 762. But: $ ls -la /var/lock/ total 8 drwxrwxrwt2 root root 4096 abr 22 15:58 . drwxr-xr-x 19 root root 4096 abr 19 23:33 .. -rw-r--r--1 jfernand jfernand0 abr 22 15:58 rcconf And if the superuser tries to execute rcconf: $ sudo rcconf Another rcconf is running, or still remain lock file(/var/lock/rcconf). at /usr/bin/rcconf line 785. This could be easily be prevented by checking if the user can make the changes (for example, he = root) before running rcconf or by cleaning up the lock files when expected errors occur (user is not root and cannot write a file). This is not an important bug, since the user himself can remove the file. Regards Javier Fernandez-Sanguino -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux avalon 2.4.18 #1 SMP mié abr 3 12:47:49 CEST 2002 i686 Locale: LANG=spanish, LC_CTYPE=spanish --- Received: (at 144053-done) by bugs.debian.org; 22 Sep 2003 10:20:20 + From [EMAIL PROTECTED] Mon Sep 22 05:20:19 2003 Return-path: [EMAIL PROTECTED] Received: from bangpath.uucico.de [195.71.9.197] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1A1Nnn-0001Hb-00; Mon, 22 Sep 2003 05:20:19 -0500 Received: by bangpath.uucico.de (Postfix, from userid 10) id B266A26BC1; Mon, 22 Sep 2003 12:20:18 +0200 (CEST) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 7FFD0FEE2; Mon, 22 Sep 2003 20:18:33 +1000 (EST) Resent-From: [EMAIL PROTECTED] Resent-Date: Mon, 22 Sep 2003 20:18:33 +1000 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Received: by deprecation.cyrius.com (Postfix, from userid 10) id 682D31018C; Mon, 22 Sep 2003 09:42:50 +1000 (EST) Received: from murphy.debian.org (murphy.debian.org [146.82.138.6]) by bangpath.uucico.de (Postfix) with ESMTP id 130B326B2E for [EMAIL PROTECTED]; Sun, 21 Sep 2003 19:59:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E07A81FC12; Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from auric.debian.org (auric.debian.org [206.246.226.45]) by murphy.debian.org (Postfix) with ESMTP id 9C87F20170 for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:23:22 -0500 (CDT) Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 1A17pa-sP-00; Sun, 21 Sep 2003 13:17:06 -0400 From: Atsushi KAMOSHIDA [EMAIL PROTECTED] To: debian-devel-changes@lists.debian.org X-Katie: $Revision: 1.35 $ Subject: Accepted rcconf 1.6 (all source) Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 13:17:06 -0400 Reply-To: debian-devel@lists.debian.org Mail-Followup-To:
Bug#147047: marked as done (libjcode-pm-perl: new upstream version)
Your message dated Sun, 21 Sep 2003 13:47:07 -0400 with message-id [EMAIL PROTECTED] and subject line Accepted libjcode-pm-perl 0.83-1 (i386 source) has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 15 May 2002 04:40:56 + From [EMAIL PROTECTED] Tue May 14 23:40:56 2002 Return-path: [EMAIL PROTECTED] Received: from mizuho.linux.or.jp (lists.linux.or.jp) [210.171.226.47] (postfix) by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 177qat-0004eS-00; Tue, 14 May 2002 23:40:55 -0500 Received: from localhost (localhost [127.0.0.1]) by lists.linux.or.jp (Postfix) with ESMTP id 67C1A5FD8A for [EMAIL PROTECTED]; Wed, 15 May 2002 13:40:54 +0900 (JST) Date: Wed, 15 May 2002 13:40:45 +0900 From: ISHIKAWA Mutsumi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: libjcode-pm-perl: new upstream version User-Agent: Wanderlust/2.9.11 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - Ushinoya) Content-Type: text/plain; charset=US-ASCII Message-Id: [EMAIL PROTECTED] X-Dispatcher: imput version 2414(IM141) Lines: 14 Delivered-To: [EMAIL PROTECTED] Package: libjcode-pm-perl Version: 0.73-1 Severity: wishlist Current version of libjcode-pm-perl.deb package is 0.75 But Newest upstream version is 0.80. http://www.perl.com/CPAN/authors/id/D/DA/DANKOGAI/Jcode-0.80.tar.gz Please update. -- ISHIKAWA Mutsumi [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] --- Received: (at 147047-done) by bugs.debian.org; 22 Sep 2003 10:20:28 + From [EMAIL PROTECTED] Mon Sep 22 05:20:19 2003 Return-path: [EMAIL PROTECTED] Received: from bangpath.uucico.de [195.71.9.197] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1A1Nnn-0001Hc-00; Mon, 22 Sep 2003 05:20:19 -0500 Received: by bangpath.uucico.de (Postfix, from userid 10) id 9E7D626BC0; Mon, 22 Sep 2003 12:20:18 +0200 (CEST) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 0F89EFF05; Mon, 22 Sep 2003 20:18:23 +1000 (EST) Resent-From: [EMAIL PROTECTED] Resent-Date: Mon, 22 Sep 2003 20:18:23 +1000 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Received: by deprecation.cyrius.com (Postfix, from userid 10) id 94E7110114; Mon, 22 Sep 2003 09:42:55 +1000 (EST) Received: from murphy.debian.org (murphy.debian.org [146.82.138.6]) by bangpath.uucico.de (Postfix) with ESMTP id 5C6DF26B2E for [EMAIL PROTECTED]; Sun, 21 Sep 2003 20:22:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id 835DB1FC29; Sun, 21 Sep 2003 13:22:42 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from auric.debian.org (auric.debian.org [206.246.226.45]) by murphy.debian.org (Postfix) with ESMTP id ACD7C1FBC7 for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:53:14 -0500 (CDT) Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 1A18Id-0001kE-00; Sun, 21 Sep 2003 13:47:07 -0400 From: Atsushi KAMOSHIDA [EMAIL PROTECTED] To: debian-devel-changes@lists.debian.org X-Katie: $Revision: 1.35 $ Subject: Accepted libjcode-pm-perl 0.83-1 (i386 source) Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 13:47:07 -0400 Reply-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org X-Spam-Status: No, hits=-2.9 required=4.0 tests=PGP_SIGNATURE version=2.55-lists.debian.org_2003_9_21 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55-lists.debian.org_2003_9_21 (1.174.2.19-2003-05-19-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel-changes@lists.debian.org X-Mailing-List: debian-devel-changes@lists.debian.org archive/latest/162715 X-Loop: debian-devel-changes@lists.debian.org List-Id: debian-devel-changes.lists.debian.org List-Post: mailto:debian-devel-changes@lists.debian.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Archive: http://lists.debian.org/debian-devel-changes/ Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Sun, 21 Sep 2003 13:22:42 -0500 (CDT) Delivered-To: [EMAIL PROTECTED]
Bug#67852: marked as done (rcconf: correcting Engilish in package description)
Your message dated Sun, 21 Sep 2003 13:17:06 -0400 with message-id [EMAIL PROTECTED] and subject line Accepted rcconf 1.6 (all source) has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 28 Jul 2000 05:29:12 + From [EMAIL PROTECTED] Fri Jul 28 00:29:12 2000 Return-path: [EMAIL PROTECTED] Received: from adsl-63-193-116-241.dsl.snfc21.pacbell.net (kitenet.net) [63.193.116.241] (postfix) by master.debian.org with esmtp (Exim 3.12 2 (Debian)) id 13I2hr-0007IQ-00; Fri, 28 Jul 2000 00:29:11 -0500 Received: by kitenet.net (Postfix, from userid 500) id 51CA7BC05E; Thu, 27 Jul 2000 22:29:10 -0700 (PDT) From: Joey Hess [EMAIL PROTECTED] Subject: rcconf: correcting Engilish in package description To: [EMAIL PROTECTED] X-Mailer: bug 3.2.10 Message-Id: [EMAIL PROTECTED] Date: Thu, 27 Jul 2000 22:29:10 -0700 (PDT) Delivered-To: [EMAIL PROTECTED] Package: rcconf Version: N/A Severity: normal rcconf is the configuration tool of rc?.d/ directory, which is CUI interface to the update-rc.d command. This description doesn't tell me enough to understand what this program does, or I would attempt to send you a description that uses proper English. -- System Information Debian Release: 2.2 Kernel Version: Linux kite 2.2.16 #1 Sun Jun 11 15:30:48 PDT 2000 i686 unknown --- Received: (at 67852-done) by bugs.debian.org; 22 Sep 2003 10:20:20 + From [EMAIL PROTECTED] Mon Sep 22 05:20:20 2003 Return-path: [EMAIL PROTECTED] Received: from bangpath.uucico.de [195.71.9.197] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1A1Nno-0001Hu-00; Mon, 22 Sep 2003 05:20:20 -0500 Received: by bangpath.uucico.de (Postfix, from userid 10) id 047F426BBF; Mon, 22 Sep 2003 12:20:19 +0200 (CEST) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id D6747FF09; Mon, 22 Sep 2003 20:19:49 +1000 (EST) Resent-From: [EMAIL PROTECTED] Resent-Date: Mon, 22 Sep 2003 20:19:49 +1000 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED], [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Received: by deprecation.cyrius.com (Postfix, from userid 10) id 682D31018C; Mon, 22 Sep 2003 09:42:50 +1000 (EST) Received: from murphy.debian.org (murphy.debian.org [146.82.138.6]) by bangpath.uucico.de (Postfix) with ESMTP id 130B326B2E for [EMAIL PROTECTED]; Sun, 21 Sep 2003 19:59:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E07A81FC12; Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from auric.debian.org (auric.debian.org [206.246.226.45]) by murphy.debian.org (Postfix) with ESMTP id 9C87F20170 for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:23:22 -0500 (CDT) Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 1A17pa-sP-00; Sun, 21 Sep 2003 13:17:06 -0400 From: Atsushi KAMOSHIDA [EMAIL PROTECTED] To: debian-devel-changes@lists.debian.org X-Katie: $Revision: 1.35 $ Subject: Accepted rcconf 1.6 (all source) Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 13:17:06 -0400 Reply-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org X-Spam-Status: No, hits=-2.9 required=4.0 tests=PGP_SIGNATURE version=2.55-lists.debian.org_2003_9_21 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55-lists.debian.org_2003_9_21 (1.174.2.19-2003-05-19-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel-changes@lists.debian.org X-Mailing-List: debian-devel-changes@lists.debian.org archive/latest/162713 X-Loop: debian-devel-changes@lists.debian.org List-Id: debian-devel-changes.lists.debian.org List-Post: mailto:debian-devel-changes@lists.debian.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Archive: http://lists.debian.org/debian-devel-changes/ Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Delivered-To: [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 01:41:31 +0900 Source: rcconf Binary: rcconf Architecture: source all Version: 1.6 Distribution: unstable Urgency: low Maintainer: Atsushi KAMOSHIDA [EMAIL PROTECTED]
Bug#144560: marked as done (rcconf: claims it works with file-rc but conflicts with it)
Your message dated Sun, 21 Sep 2003 13:17:06 -0400 with message-id [EMAIL PROTECTED] and subject line Accepted rcconf 1.6 (all source) has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 25 Apr 2002 22:48:49 + From [EMAIL PROTECTED] Thu Apr 25 17:48:49 2002 Return-path: [EMAIL PROTECTED] Received: from falcon.mail.pas.earthlink.net (falcon.prod.itd.earthlink.net) [207.217.120.74] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 170s2i-00034T-00; Thu, 25 Apr 2002 17:48:48 -0500 Received: from sdn-ar-002ilchicp176.dialsprint.net ([206.133.102.216] helo=satellite) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 170s2h-0004cY-00; Thu, 25 Apr 2002 15:48:48 -0700 Received: by satellite (Postfix, from userid 1000) id A9D99DC029; Thu, 25 Apr 2002 17:48:45 -0500 (CDT) From: Chris Lawrence [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: rcconf: claims it works with file-rc but conflicts with it X-Mailer: reportbug 1.99.12 Date: Thu, 25 Apr 2002 17:48:45 -0500 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Package: rcconf Version: N/A; reported 2002-04-25 Severity: important The description of rcconf claims that it works with either sysvinit or file-rc, yet it conflicts with file-rc, hence it only works with sysvinit. Please either fix the conflicts field or the description. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux satellite 2.4.18 #1 Sun Apr 21 17:44:02 CDT 2002 i686 Locale: LANG=C, LC_CTYPE=en_US --- Received: (at 144560-done) by bugs.debian.org; 22 Sep 2003 10:20:28 + From [EMAIL PROTECTED] Mon Sep 22 05:20:28 2003 Return-path: [EMAIL PROTECTED] Received: from bangpath.uucico.de [195.71.9.197] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1A1Nnn-0001Hd-00; Mon, 22 Sep 2003 05:20:19 -0500 Received: by bangpath.uucico.de (Postfix, from userid 10) id C47FC26BC2; Mon, 22 Sep 2003 12:20:18 +0200 (CEST) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 64D33FF05; Mon, 22 Sep 2003 20:18:47 +1000 (EST) Resent-From: [EMAIL PROTECTED] Resent-Date: Mon, 22 Sep 2003 20:18:47 +1000 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Received: by deprecation.cyrius.com (Postfix, from userid 10) id 682D31018C; Mon, 22 Sep 2003 09:42:50 +1000 (EST) Received: from murphy.debian.org (murphy.debian.org [146.82.138.6]) by bangpath.uucico.de (Postfix) with ESMTP id 130B326B2E for [EMAIL PROTECTED]; Sun, 21 Sep 2003 19:59:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E07A81FC12; Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from auric.debian.org (auric.debian.org [206.246.226.45]) by murphy.debian.org (Postfix) with ESMTP id 9C87F20170 for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:23:22 -0500 (CDT) Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 1A17pa-sP-00; Sun, 21 Sep 2003 13:17:06 -0400 From: Atsushi KAMOSHIDA [EMAIL PROTECTED] To: debian-devel-changes@lists.debian.org X-Katie: $Revision: 1.35 $ Subject: Accepted rcconf 1.6 (all source) Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 13:17:06 -0400 Reply-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org X-Spam-Status: No, hits=-2.9 required=4.0 tests=PGP_SIGNATURE version=2.55-lists.debian.org_2003_9_21 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55-lists.debian.org_2003_9_21 (1.174.2.19-2003-05-19-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel-changes@lists.debian.org X-Mailing-List: debian-devel-changes@lists.debian.org archive/latest/162713 X-Loop: debian-devel-changes@lists.debian.org List-Id: debian-devel-changes.lists.debian.org List-Post: mailto:debian-devel-changes@lists.debian.org List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Archive: http://lists.debian.org/debian-devel-changes/ Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Sun, 21 Sep 2003 12:59:31 -0500 (CDT)
Bug#151968: marked as done (Copyright file points to the wrong location (patch enclosed))
Your message dated Sun, 21 Sep 2003 13:17:06 -0400 with message-id [EMAIL PROTECTED] and subject line Accepted rcconf 1.6 (all source) has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 4 Jul 2002 23:30:06 + From [EMAIL PROTECTED] Thu Jul 04 18:30:06 2002 Return-path: [EMAIL PROTECTED] Received: from server1.mpc.com.br [200.246.0.242] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 17QG33-0006Uf-00; Thu, 04 Jul 2002 18:30:05 -0500 Received: (from [EMAIL PROTECTED]) by server1.mpc.com.br (8.11.3/8.11.3) id g64NU2Q97287; Thu, 4 Jul 2002 20:30:02 -0300 (BRT) (envelope-from [EMAIL PROTECTED]) Received: from socrates.dnsalias.org (200-171-244-52.customer.telesp.net.br [200.171.244.52]) (authenticated) by server1.mpc.com.br (8.11.3/8.11.3av) with ESMTP id g64NU0q97269; Thu, 4 Jul 2002 20:30:00 -0300 (BRT) (envelope-from [EMAIL PROTECTED]) Received: from localhost (localhost [127.0.0.1]) by socrates.dnsalias.org (Postfix) with ESMTP id C89F442D86; Thu, 4 Jul 2002 20:29:20 -0300 (BRT) Received: by socrates.dnsalias.org (Postfix, from userid 1001) id 7AC6E42D8A; Thu, 4 Jul 2002 20:29:20 -0300 (BRT) Subject: Copyright file points to the wrong location (patch enclosed) Reply-To: Jeronimo Pellegrini [EMAIL PROTECTED] From: Jeronimo Pellegrini [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] X-Mailer: reportbug 1.99.45 Date: Thu, 04 Jul 2002 20:29:20 -0300 Message-Id: [EMAIL PROTECTED] X-Virus-Scanned: by AMaViS snapshot-20010714 Delivered-To: [EMAIL PROTECTED] Package: rcconf Version: 1.3 Severity: minor Tags: patch Hi. Thatnks to lintian (and linda), I noticed that the copyright file points to the old location. The following patch fixes that. J. --- rcconf-1.3-orig/debian/copyrightSun Jan 9 12:11:15 2000 +++ rcconf-1.3-new/debian/copyright Thu Jul 4 20:24:10 2002 @@ -3,6 +3,6 @@ Copyright: -This software is distributed under GPL Ver.2 . -Please reference to the file '/usr/doc/copyright/GPL'. +This software is distributed under the GNU GPL Ver.2 . +Please refer to the file '/usr/share/common-licenses/GPL'. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux socrates 2.4.19-rc1-fx-o1 #1 Thu Jul 4 03:38:08 BRT 2002 i686 Locale: LANG=en_US, LC_CTYPE=ISO-8859-1 (ignored: LC_ALL set) Versions of packages rcconf depends on: ii whiptail 0.50.17-9.6 Displays user-friendly dialog boxe -- no debconf information --- Received: (at 151968-done) by bugs.debian.org; 22 Sep 2003 10:20:28 + From [EMAIL PROTECTED] Mon Sep 22 05:20:19 2003 Return-path: [EMAIL PROTECTED] Received: from bangpath.uucico.de [195.71.9.197] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1A1Nnn-0001Hf-00; Mon, 22 Sep 2003 05:20:19 -0500 Received: by bangpath.uucico.de (Postfix, from userid 10) id EBFA526BBE; Mon, 22 Sep 2003 12:20:18 +0200 (CEST) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id B1AC1FF08; Mon, 22 Sep 2003 20:19:10 +1000 (EST) Resent-From: [EMAIL PROTECTED] Resent-Date: Mon, 22 Sep 2003 20:19:10 +1000 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Received: by deprecation.cyrius.com (Postfix, from userid 10) id 682D31018C; Mon, 22 Sep 2003 09:42:50 +1000 (EST) Received: from murphy.debian.org (murphy.debian.org [146.82.138.6]) by bangpath.uucico.de (Postfix) with ESMTP id 130B326B2E for [EMAIL PROTECTED]; Sun, 21 Sep 2003 19:59:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E07A81FC12; Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from auric.debian.org (auric.debian.org [206.246.226.45]) by murphy.debian.org (Postfix) with ESMTP id 9C87F20170 for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:23:22 -0500 (CDT) Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 1A17pa-sP-00; Sun, 21 Sep 2003 13:17:06 -0400 From: Atsushi KAMOSHIDA [EMAIL PROTECTED] To: debian-devel-changes@lists.debian.org X-Katie: $Revision: 1.35 $ Subject: Accepted rcconf 1.6 (all source) Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 21 Sep 2003
Bug#168414: marked as done (rcconf works with file-rc Conflicts: file-rc)
Your message dated Sun, 21 Sep 2003 13:17:06 -0400 with message-id [EMAIL PROTECTED] and subject line Accepted rcconf 1.6 (all source) has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at maintonly) by bugs.debian.org; 9 Nov 2002 10:16:49 + From [EMAIL PROTECTED] Sat Nov 09 04:16:48 2002 Return-path: [EMAIL PROTECTED] Received: from uucp.gnuu.de [151.189.0.84] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18ASfX-0004qq-00; Sat, 09 Nov 2002 04:16:47 -0600 Received: from alea.gnuu.de ([EMAIL PROTECTED]) by uucp.gnuu.de (8.11.1/8.11.1) with bsmtp id gA9AGjv73306 for [EMAIL PROTECTED]; Sat, 9 Nov 2002 11:16:45 +0100 (CET) Received: from [192.168.0.2] (helo=joerg.localnet) by alea.gnuu.de with smtp (Exim 3.35 #1 (Debian)) id 18AScl-0001tB-00 for [EMAIL PROTECTED]; Sat, 09 Nov 2002 11:13:55 +0100 Received: by joerg.localnet (sSMTP sendmail emulation); Sat, 9 Nov 2002 11:13:55 +0100 Date: Sat, 9 Nov 2002 11:13:55 +0100 From: Joerg Sommer [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: rcconf works with file-rc Conflicts: file-rc Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Reportbug-Version: 1.50 Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-4.6 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.41 X-Spam-Level: Package: rcconf Version: N/A; reported 2002-11-09 Severity: minor $ apt-cache show rcconf Package: rcconf Version: 1.3 Conflicts: file-rc Description: Debian Runlevel configuration tool Rcconf works with both System-V style and file-rc runlevel configuration. This is somewaht confusing. Does rcconf work with file-rc or not? Joerg. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux joerg 2.4.19 #1 Son Aug 11 11:35:10 MEST 2002 i586 Locale: LANG=de_DE, LC_CTYPE=de_DE --- Received: (at 168414-done) by bugs.debian.org; 22 Sep 2003 10:20:28 + From [EMAIL PROTECTED] Mon Sep 22 05:20:19 2003 Return-path: [EMAIL PROTECTED] Received: from bangpath.uucico.de [195.71.9.197] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1A1Nnn-0001Hd-00; Mon, 22 Sep 2003 05:20:19 -0500 Received: by bangpath.uucico.de (Postfix, from userid 10) id C47FC26BC2; Mon, 22 Sep 2003 12:20:18 +0200 (CEST) Received: by deprecation.cyrius.com (Postfix, from userid 1000) id 64D33FF05; Mon, 22 Sep 2003 20:18:47 +1000 (EST) Resent-From: [EMAIL PROTECTED] Resent-Date: Mon, 22 Sep 2003 20:18:47 +1000 Resent-Message-ID: [EMAIL PROTECTED] Resent-To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] X-Original-To: [EMAIL PROTECTED] Received: by deprecation.cyrius.com (Postfix, from userid 10) id 682D31018C; Mon, 22 Sep 2003 09:42:50 +1000 (EST) Received: from murphy.debian.org (murphy.debian.org [146.82.138.6]) by bangpath.uucico.de (Postfix) with ESMTP id 130B326B2E for [EMAIL PROTECTED]; Sun, 21 Sep 2003 19:59:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by murphy.debian.org (Postfix) with QMQP id E07A81FC12; Sun, 21 Sep 2003 12:59:31 -0500 (CDT) Old-Return-Path: [EMAIL PROTECTED] Received: from auric.debian.org (auric.debian.org [206.246.226.45]) by murphy.debian.org (Postfix) with ESMTP id 9C87F20170 for debian-devel-changes@lists.debian.org; Sun, 21 Sep 2003 12:23:22 -0500 (CDT) Received: from katie by auric.debian.org with local (Exim 3.35 1 (Debian)) id 1A17pa-sP-00; Sun, 21 Sep 2003 13:17:06 -0400 From: Atsushi KAMOSHIDA [EMAIL PROTECTED] To: debian-devel-changes@lists.debian.org X-Katie: $Revision: 1.35 $ Subject: Accepted rcconf 1.6 (all source) Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Sun, 21 Sep 2003 13:17:06 -0400 Reply-To: debian-devel@lists.debian.org Mail-Followup-To: debian-devel@lists.debian.org X-Spam-Status: No, hits=-2.9 required=4.0 tests=PGP_SIGNATURE version=2.55-lists.debian.org_2003_9_21 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55-lists.debian.org_2003_9_21 (1.174.2.19-2003-05-19-exp) Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-devel-changes@lists.debian.org X-Mailing-List: debian-devel-changes@lists.debian.org archive/latest/162713 X-Loop:
Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]
* Brian White [EMAIL PROTECTED] [2003-09-20 07:37]: Neither SCP nor anonymous-FTP methods work and I want to get that fixed. SSH works. SCP doesn't. Well, it works for everyone else. So it would be good if you'd find out why it doesn't work for you. In the meantime, you can put your signed upload somewhere and someone can simply upload it to ftp-master on your behalf. If you ask on debian-devel@lists.debian.org, I'm sure someone will do that. -- Martin Michlmayr [EMAIL PROTECTED]
Re: apt-get'able Release file format
On Mon, Sep 22, 2003 at 10:31:50AM +0200, Jochen Voss wrote:
Hello,
On Mon, Sep 22, 2003 at 12:48:24AM -0400, Matt Zimmerman wrote:
On Sun, Sep 21, 2003 at 10:20:36PM -0600, Adam Conrad wrote:
Matt Zimmerman wrote:
That sounds backwards. Component is the one recognized by apt, and
(naturally) the one used by official Release files in the
Debian archive.
...
apt doesn't read that Release file (yet; this is part of the apt-secure
enhancements). It currently only pays attention to
{main,contrib,non-free}/{binary-*,source}/Release.
Even in apt-secure, I don't think it presently pays attention to that
Components field.
^^
Component?
No, Components (the one in the top-level Release file).
--
- mdz
Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]
Martin Michlmayr [EMAIL PROTECTED] a tapoté : * Brian White [EMAIL PROTECTED] [2003-09-20 07:37]: Neither SCP nor anonymous-FTP methods work and I want to get that fixed. SSH works. SCP doesn't. Well, it works for everyone else. So it would be good if you'd find out why it doesn't work for you. Maybe an odd .dotfile. I seen that problem 5 days ago at my office, something ugly in the default dotfile provided by the nice institution where I am currently that completely broke scp but not ssh (however, the problematic dotfile was on the server side, not the client side). -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Debian should not modify the kernels!
Hi! Am 2003-09-22 11:55 +0200 schrieb Eduard Bloch: significantly modified; why aren't those modifications distributed as seperate kernel patches / debian packages in the same way grsec is? Martin can _simply_ create an alternative apply script which unpatches the Debian source when needed before applying the grsec patch. Quiet, transparent solution. When Debian claims to ship kernels with security patches, then another Debian package should not silently remove them; that would be very dangerous (and IMHO silly). I could live with this solution if such an unpatch is verbosely announced to the user (let's say, with a debconf note of priority high). Have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
martin f krafft wrote: also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.21.1= 614 +0200]: Should we stop shipping security fixes backported from development code? It always depends, doesn't it? We are backporting *security* fixes to packages, but we take care not to introduce new features. I don't oppose some small modifications to the kernel, fixes and security backports, but including a 2.5 IPsec stack in 2.4.21 is kinda not in accordance with that policy, now is it? It would be inappropriate to do it within a stable release, sure, but it is something that Debian do do in general. In this case it's a chunk of code that has almost nothing to do with the core kernel code - it just so happens that in the pathological case of a kernel patch, there's some awkwardness. That's an indication that our kernel patching system should be rationalised, not that shipping modified kernels is wrong. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Horrific new levels of changelog abuse
Matt Zimmerman [EMAIL PROTECTED] wrote:
- The bug submitter should receive a reasonable explanation for the bug's
closure in the -done message
Well can you please give an operable definition of what a reasonable
explanation is?
A reasonable explanation includes enough information for:
- the submitter to recognize that their bug was in fact fixed
Agreed. However I must say that this is pretty obvious when you get
a closure message.
For those who're only satisfied with detailed analysis of how a bug
is fixed, may I remind you that no matter how long the bug closure
message is, the possibility remains that the bug was not fixed at all.
In fact, it is only common courtesy for any bug sumitter to verify
that a bug is indeed fixed. After all, it would be terrible waste
for the maintainer to spend time and effort in correcting a bug, only
to be foiled by what may be a simple mistake/misunderstanding that could
be picked up by the submitter.
- a user to be able to read the changelog, with an idea of the bug in his
head, and find where it was fixed. For example, a stable user reading an
unstable changelog to see if a bug affecting him is fixed
This is not relevant I'm afraid since we're talking about messages sent
to the -done address, possibly by hand.
- a developer to be able to determine what version of the package he needs
to depend on if he requires a certain fix which was requested through the
BTS
This is a good idea and we probably should get people to start doing it.
However it would be good if the BTS provided a formal way of specifying
it.
In any case, this is implicit when the closure message comes from
debian/changelog.
- the changelog to stand on its own, and be useful without digging through
the BTS
Again this is not relevant as we're talking about messages that may be
sent by hand.
So to summarise, you haven't given me an operable definition of what
a reasonable explanation is that applies to both debian/changelog messages
and closure messages sent by hand.
I've read a number of closure messages on bugs of your packages, and
they really coveyed no more information than a message which simply
said that the bug is fixed in version x.
Can you provide an example? The rootstrap example you gave certainly
provided more information than bug # was fixed; it documented the
addition of a feature which justified the closure of the bug.
In this particular case, you closed a bug requesting for feature X with
the message that feature X was added. Well I must say that this piece
of information could have been obtained with elementary deduction
even if you just said that this bug had been fixed in version Y :)
As another example:
#204614: initrd couldn't detect EVMS root correctly
Closure: Detect EVMS root correctly
My position on changelogs is completely unrelated to the BTS, because I
think that the changelog should stand on its own, documenting all changes to
the package which are considered relevant to Debian.
Fair enough. In that case the basis on which upstream changes are listed
in debian/changelog should not be dictated by whether they fix Debian
bugs. Otherwise this would appear to be farily arbitrary as it
depends on the following three conditions to be true:
* The bug is filed in the Debian BTS.
* The bug is filed before the relevant upstream release is uploaded to Debian.
* The bug is analysed and determined to be fixed before the said upload.
I do feel strongly that changes in the package which are relevant to Debian
users and developers, whether they happen to be in the debian/ directory or
not, should be documented in debian/changelog.
That's OK with me. However, if you wish to make everyone do that, then
may I suggest that you draw up a less arbitrary criterion than whether
someone has filed a bug about it in the Debian BTS.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
Matt Zimmerman [EMAIL PROTECTED] wrote:
So, I'm curious why you chose to make it a part of the Debian kernel source,
rather than a separate patch (kernel-patch-ipsec or such).
Well the reason for it to be in the default kernel-source is simple:
The patch should be used on all default Debian kernel images unless
the arch maintainer chooses to override it.
I suppose the more fundamental question is, what is your vision for the
Debian kernel source? What do you feel belongs there, and what does not?
Perhaps vision is too strong a word.
I have some simple checks when it comes to patch inclusion:
* Is it actively maintained by someone?
If it's not maintained then there is very little chance for me to
include it as I have no time in fixing random breakages.
* If it's a feature, can it be disabled/enabled at runtime?
Sinec we're making generic kernels, this is a must. The presence
of the patch should not prevent me from doing something that I would
otherwise be able to do.
If the patch only produces a module then it obviously passes this test.
* If it's a bug fix, how bad are its side-effects?
I'm not going to accept any bug fix that makes the kernel better for
10% of the users but worse for the other 90%.
* What size impact does it have to the binary kernel image?
This is very important for the debian-boot team.
Again it would be best if it was completely modularised.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debian should not modify the kernels!
George Danchev [EMAIL PROTECTED] wrote:
it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is useless,
leave to users to patch if they want) then all other kernel-patch-whatever
packages will be fine.
It is unacceptable for us to distribute kernels with known (security) bugs.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]
On Sat, Sep 20, 2003 at 03:48:35PM +0200, Andreas Metzler wrote:
Brian White [EMAIL PROTECTED] wrote:
SSH works. SCP doesn't.
It is easy to circumvent non-working scp:
tar cf - foo bar | ssh ftp-master.debian.org tar xf -
or
rsync -vtaz foo bar ftp-master.debian.org:
Scp works for me, I always use rsync though. I've read in usenet about
problems with using the scp from commercial ssh against an OpenSSH
server, iirc the commercial client internally uses sftp if running in
SSH-protocol v2 modus.
Yes, very brain-dead.
And sftp does not work on ftp-master:
[EMAIL PROTECTED]:/tmp sftp ftp-master.debian.org
Connecting to ftp-master.debian.org...
Enter passphrase for key '/home/ametzler/.ssh/debiangluck_rsa':
Request for subsystem 'sftp' failed on channel 0
Couldn't read packet: Connection reset by peer
Protocol 1 works ('sftp -1'). I haven't looked into what's broken with
protocol 2 sftp on ftp-master.
--
Colin Watson [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
On Monday 22 September 2003 14:20, Matthew Garrett wrote: martin f krafft wrote: also sprach Matthew Garrett [EMAIL PROTECTED] [2003.09.21.1= 614 +0200]: Should we stop shipping security fixes backported from development code? It always depends, doesn't it? We are backporting *security* fixes to packages, but we take care not to introduce new features. I don't oppose some small modifications to the kernel, fixes and security backports, but including a 2.5 IPsec stack in 2.4.21 is kinda not in accordance with that policy, now is it? It would be inappropriate to do it within a stable release, sure, but it is something that Debian do do in general. Then all kernel-source-x.y.z prepared like this kernel-source-2.4.22 2.4.22-1 will never be release-ready or candidates for Stable (so sad). Then why it has been introduced to official Debian archive? In this case it's a chunk of code that has almost nothing to do with the core kernel code - it just This is very arguable. Have you apt-get source kernel-source-2.4.22 then looked at the patch ? so happens that in the pathological case of a kernel patch, there's some awkwardness. it is not a pathological case, this is how the patch program works: it reads the patch file (prepared with diff) and tries to find the relevent rows in files within the tree it is patchng, if these rows are missing or fuzzy then what do you expect the patch program to do, it simply can not replace them out ? it is not like a programmer to merge it manually and checks to ensure that there are no logical errors introduced during the merge. That's an indication that our kernel patching system should be rationalised, not that shipping modified kernels is wrong. No, that is an indication that kernel-source-x.y.x is moving target and you will always have issues paching it ... Do not get me wrong. I'm not against shipping modified kernels, but do not it Red Hat way having 2.6 stuff shipped with names like kernel-...-2.4... It is not 2.4.x then ... If I want such behaviour I'll run Red Hat... so please do not kill the only one and true/safest/sanest GNU/Linux harbor around ... e.g. Debian. The proposed solution of silently unpatching the debian-patched 2.4.22 kernel tree with maintainer scripts of any other package is dangerous... it is even funny ... Why cause problem, then struggle how to fix it ... it is better just not cause trouble. One does not hit the wall intentionally, then go to doctor ;-) -- pub 4096R/0E4BD0AB 2003-03-18 keyserver.bu.edu 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Re: Debain-Edu and Skolelinux
On Mon, 22 Sep 2003, Andreas Schuldei wrote: better with Debian, and for that reason thankfully accepts Raphael Herzogs offer to continue its effords as the Debian-Edu subproject, taking it over. Congratulations! * To avoid the Knoppix-effect. This is a great wording! Good luck for your project Andreas.
Re: Horrific new levels of changelog abuse
On Mon, Sep 22, 2003 at 09:22:40PM +1000, Herbert Xu wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: A reasonable explanation includes enough information for: - the submitter to recognize that their bug was in fact fixed Agreed. However I must say that this is pretty obvious when you get a closure message. For those who're only satisfied with detailed analysis of how a bug is fixed, may I remind you that no matter how long the bug closure message is, the possibility remains that the bug was not fixed at all. Detailed analysis is not necessary, but I think that at a minimum a description of what bug was _believed_ to be fixed is valuable, as this helps to catch errors with closing the wrong bug, misinterpreting the submitter's problem, etc. - a user to be able to read the changelog, with an idea of the bug in his head, and find where it was fixed. For example, a stable user reading an unstable changelog to see if a bug affecting him is fixed This is not relevant I'm afraid since we're talking about messages sent to the -done address, possibly by hand. I think it is a disservice to close a bug without making a notation in the changelog, if a change in the software fixed the bug. - a developer to be able to determine what version of the package he needs to depend on if he requires a certain fix which was requested through the BTS This is a good idea and we probably should get people to start doing it. However it would be good if the BTS provided a formal way of specifying it. I believe Colin Watson is working on this, but I imagine it is a major undertaking. In any case, this is implicit when the closure message comes from debian/changelog. It is only implicit if the bug and/or the fix are described in the changelog. Otherwise, Closes: # by itself does not provide the required information. - the changelog to stand on its own, and be useful without digging through the BTS Again this is not relevant as we're talking about messages that may be sent by hand. So to summarise, you haven't given me an operable definition of what a reasonable explanation is that applies to both debian/changelog messages and closure messages sent by hand. Both should record the change in the package which caused the bug to be closed. The change may be described at a high level (fixed the problem which caused behaviour) or a low level (fixed low-level problem in subsystem which caused behaviour), but it must be described. In the case of closure messages sent by hand, there may not have been a change to the package, and so that does not apply. Can you provide an example? The rootstrap example you gave certainly provided more information than bug # was fixed; it documented the addition of a feature which justified the closure of the bug. In this particular case, you closed a bug requesting for feature X with the message that feature X was added. Well I must say that this piece of information could have been obtained with elementary deduction even if you just said that this bug had been fixed in version Y :) No, it would not. The difference is between these two entries: * Closes: #30 * Correctly parse comments in the config file (Closes: #30) If I am having a problem with comments in my config file, the first is worthless, and the second is very valuable. The difference is that the change to the package is described, rather than hiding the change behind an opaque bug number. As another example: #204614: initrd couldn't detect EVMS root correctly Closure: Detect EVMS root correctly A high-level description of the change which was made. Infinitely superior to Closes: #204614. My position on changelogs is completely unrelated to the BTS, because I think that the changelog should stand on its own, documenting all changes to the package which are considered relevant to Debian. Fair enough. In that case the basis on which upstream changes are listed in debian/changelog should not be dictated by whether they fix Debian bugs. Otherwise this would appear to be farily arbitrary as it depends on the following three conditions to be true: * The bug is filed in the Debian BTS. * The bug is filed before the relevant upstream release is uploaded to Debian. Obviously bug fixes cannot be documented if the maintainer is not aware of them at the time. * The bug is analysed and determined to be fixed before the said upload. Bugs should only ever be fixed when they are analyzed (at some level) and determined to be fixed. Too often maintainers mass-close bugs when they upload a new release after some time of inactivity, because they cannot be bothered to check (or even ask that the submitter check). I do feel strongly that changes in the package which are relevant to Debian users and developers, whether they happen to be in the debian/ directory or not, should be documented in debian/changelog. That's OK with me.
Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
Herbert Xu [EMAIL PROTECTED] writes: Matt Zimmerman [EMAIL PROTECTED] wrote: So, I'm curious why you chose to make it a part of the Debian kernel source, rather than a separate patch (kernel-patch-ipsec or such). Well the reason for it to be in the default kernel-source is simple: The patch should be used on all default Debian kernel images unless the arch maintainer chooses to override it. That doesn't sound like it really answers the question... I suppose the more fundamental question is, what is your vision for the Debian kernel source? What do you feel belongs there, and what does not? Perhaps vision is too strong a word. I have some simple checks when it comes to patch inclusion: * Is it actively maintained by someone? * If it's a feature, can it be disabled/enabled at runtime? * If it's a bug fix, how bad are its side-effects? * What size impact does it have to the binary kernel image? ...do you include *everything* that comes by you that meets these criteria? Because from this it sounds like anything that has an upstream that can be built as modules would be included. My particular directed thought right now is a somewhat invasive patch that updates the 2.4 kernels to use i2c-2.8, which would solve some headaches for me (somewhat invasive, in that it also goes off and modifies all of the other drivers that depend on i2c); if I were the kernel maintainer, it'd trip a too different from kernel.org flag for me, but it sounds like it does meet your four criteria here. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: popsneaker vs. bandwidth consumption
[EMAIL PROTECTED] (Richard Atterer) writes: Of those packages in the archive, mailfilter is the best IMHO. However, I ended up *not* using it because it doesn't support ANDing of conditions AFAICT (size 100k AND header spelling SUBJECT:). Then maybe you should have a look at popsneaker. With popsneaker you can filter your mail by assigning scores. Here's the relevant portion of /usr/share/doc/popsneaker/index-3.html: --- snip --- The score filter rule changes the current score of a message by a given value if the rule matches. score -10 ^subject: .*for free The score_reset instruction sets the score value back to 0. This can be useful, if you have more than one block of independant score rules. And the score_eval instruction makes a decision based upon the score value. The condition is set via options, possible settings are: -lt value True if the score is less than value. -le value True if the score is less or equal value. -gt value True if the score is greater than value. -ge value True if the score is greater or equal value. A short example: score_reset score +10 ^References: .*mydomain\.net score +10 ^In-Reply-To: .*mydomain\.net score -5 ^Content-Type: text/html score -5 ^Message-ID: [EMAIL PROTECTED] score -10 ^(to|cc): .*,.*,.*,.*,.*, score_eval -gt 0 accept score_eval -lt 0 deny score_reset score -10 -case ^Subject: .*FREE score -10 -case ^Subject: .*BUY score -10 -case ^Subject: .*CASH score -5 -case ^Subject: .*free score -5 -case ^Subject: .*buy score -5 -case ^Subject: .*cash score_eval -lt 5 deny --- snip --- popsneaker is Free Software (GPL'ed) according to the DFSG and is freely available at http://www.ixtools.de/popsneaker;.
Re: Bug #47039: renaming slang.
On Mon, Sep 22, 2003 at 04:15:19PM -, Alastair wrote: I've been reviewing bugs in slang, and closing those that are fixed, and examining #47039. This may be too drastic a change at this time. What do debian-devel, and particular the Release Manage, think? I'd say definitely too drastic to do now. It's also for too little benefit; personally I'd be inclined to not change the package name until you have to -- ie, when the upstream soname changes. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgpKWqfRNqL51.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, Sep 22, 2003 at 04:04:22PM +0300, George Danchev wrote: Let me point out that Debian has always provided upstream (unmodified/ pristine) kernel source by the means of kernel-source-x.y.z packages and kernel-patch-whatever ... and so on ... Now with kernel-source-2.4.22 the situation has been changed... Er...what? kernel-source-x.y.z has not been unmodified since before I used Debian, if ever. Even the .orig.tar.gz has not been pristine since 2.4.10, due to the need to remove non-free firmware. Shipping modified kernel source is not a new idea in Debian. Escecially as an unmodified source-tree is in my experience almost only useful for i386. (Perhaps getting better Not true ;-) So called by you unmodified has all architecture-specific code inside. Get a kernel from kernel.org or svn from bkbits.net and cd arch/ Very clever. Now try actually building a kernel for most of those architectures. The reality of compiling working kernels involves a lot more than the presence of a few directories. -- - mdz
Re: eek, phpgroupware
On Mon, Sep 22, 2003 at 04:59:57PM +, Thomas Viehmann wrote: I have some phpgw packages ready at http://vman.de/debian/. They seem to fix some of the more pressing problems in phpgw/sid, however they don't correspond to Luca's package split. At this point it doesn't matter any more: i dont' want to care phpgroupware any longer. I can review your package and eventually upload them by the end of this week. I also can be an uploader/sponsor for your packages untill you'll able to upload them by your self or trough some other developer just more interested then me. Any one willing to step in is wellcome. Anyhow, my lack of response (hopefully resolved by end of next week) is not a result of disinterest or anything, but rather of lack of connectivity. I'm very honored by Luca's offer and intend to accept once I'm able to communicate and build debian packages again. (But I just found this mail in the haystack of 400 Spam mails, teaches me about client-side filtering...) By now, 0.9.14.006 is good enough and the week end is a good timespan IMHO. 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: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)
On Mon, Sep 22, 2003 at 09:30:28PM +1000, Herbert Xu wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: So, I'm curious why you chose to make it a part of the Debian kernel source, rather than a separate patch (kernel-patch-ipsec or such). Well the reason for it to be in the default kernel-source is simple: The patch should be used on all default Debian kernel images unless the arch maintainer chooses to override it. But what are the criteria for what should be used on all default Debian kernel images? You seem to address this below... I suppose the more fundamental question is, what is your vision for the Debian kernel source? What do you feel belongs there, and what does not? Perhaps vision is too strong a word. I have some simple checks when it comes to patch inclusion: * Is it actively maintained by someone? If it's not maintained then there is very little chance for me to include it as I have no time in fixing random breakages. * If it's a feature, can it be disabled/enabled at runtime? Sinec we're making generic kernels, this is a must. The presence of the patch should not prevent me from doing something that I would otherwise be able to do. If the patch only produces a module then it obviously passes this test. * If it's a bug fix, how bad are its side-effects? I'm not going to accept any bug fix that makes the kernel better for 10% of the users but worse for the other 90%. * What size impact does it have to the binary kernel image? This is very important for the debian-boot team. Again it would be best if it was completely modularised. OK, these are very minimal criteria, and I think that probably many of the kernel-patch packages in Debian would fit them. Where would you draw the line? I currently patch my kernels with device-mapper, a few evms-related patches and skas3. It would be very convenient if device-mapper and the evms patches could be included in the the stock kernel; then users could use EVMS or LVM2 in stock kernel images. This is especially useful in the installer kernels. -- - mdz
Re: Debian should not modify the kernels!
George Danchev wrote: Let me point out that Debian has always provided upstream (unmodified/ pristine) kernel source by the means of kernel-source-x.y.z packages and kernel-patch-whatever ... and so on ... Now with kernel-source-2.4.22 the situation has been changed... Nonsense. As a trivial counterexample, take a look at the changelog.Debian from kernel-source-2.0.36. Not true ;-) So called by you unmodified has all architecture-specific code inside. Get a kernel from kernel.org or svn from bkbits.net and cd arch/ And then try to compile it on anything other than i386. For some architectures, on some kernel versions, it'll work. Most of the time, it won't. Now you have a real nightmare with kernel-source-2.4.22 (named to bring the upstream 2.4.22, but instead patched and that was documented of course, but that is not the Debian way of dealing with kernels) breaking bunch of usefull kernel-patch-whatever. Historical precedent is against you. That's not to say that the current situation is ideal, but statements like this don't help. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Debian should not modify the kernels!
On Sun, Sep 21, 2003 at 01:09:08PM +0200, martin f krafft wrote: I am the kernel-patch-2.4-grsecurity maintainer, and I have been flooded with grave and important bugs ever since kernel version 2.4.20, since grsecurity does not apply to these kernel versions anymore. It doesn't apply to the Debianised versions of these kernels anymore, it applies to the vanilla kernel just fine. This is *not* my fault. No it isn't, but it's also not the fault of your fellow DDs. It's a well accepted fact among kernel developers that vanilla kernel.org kernels should not be used by end users. Debian has to patch the kernel, too. There isn't much choice.
Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]
On Mon, Sep 22, 2003 at 11:57:14PM +1000, Martin Michlmayr wrote: * Brian White [EMAIL PROTECTED] [2003-09-20 07:37]: Neither SCP nor anonymous-FTP methods work and I want to get that fixed. SSH works. SCP doesn't. Well, it works for everyone else. So it would be good if you'd find out why it doesn't work for you. In the meantime, you can put your signed upload somewhere and someone can simply upload it to ftp-master on your behalf. If you ask on debian-devel@lists.debian.org, I'm sure someone will do that. What didn't work about anonymous FTP? -- - mdz
Re: Virus emails
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.
The list of hardware required to stop this spam unfortunately seems to
include a time machine.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
One principle object of good-breeding is to suit our behavior to the three
several degrees of men -- our superiors, our equals, and those below us.
-- Jonathan Swift
Re: Virus emails
Hi, Daniel Burrows wrote:
On Fri, Sep 19, 2003 at 10:45:57AM -0500, Luca - De Whiskey's - De Vitis
[EMAIL PROTECTED] was heard to say:
I'm getting one evry 30 minutes, more or less... but i've read on irc that
this is quite common now...
You mean seconds, not minutes, right? :-(
Sounds about right for my mailbox. 2000+/day, and no sign of slowing down.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
:hungry puppy: n. Syn. {slopsucker}.
Re: Debian should not modify the kernels!
On Sun, 21 Sep 2003, Martin Michlmayr wrote: * martin f krafft [EMAIL PROTECTED] [2003-09-21 14:44]: What you distribute as 2.4.22 is not 2.4.22. So what? Most packages in Debian devate from upstream in one way or another. That's the added value we provide. I'm happy that Herbert carefully selects what to backport and I appreciate this effort. (Also note that Red Hat modify the upstream kernel and libc in a quite drastic way; in fact, their kernel is much more modified than ours). But source packages have an orig.tar.gz/diff.gz combo. kernel-source-foo packages should produce the same.
Re: Debian should not modify the kernels!
On Mon, 22 Sep 2003, Eduard Bloch wrote: They are - look at the last part of the kernel-image-KVERS image. And if you meant the kernel-source package, then please think twice before you request a such thing. Your idea would require dozens of versions of kernel-source-NUMBER-foo every time when I a small fix had to be applied. If you prefer to sponsor new harddisks for all Debian mirrors (because the archive size explodes), please do. Haha, very funny. kernel-source-2.4.22-1: Never gets modified. Only uploaded once. kernel-source-debian-2.4.22-1: Gets modified as needed, when new features/fixes come out. The latter depends on the former. This will *reduce* mirror traffic. Keeping it all in one *increases* mirror traffic, as a small change(fix or feature) requires uploading the entire source.
Re: Debian should not modify the kernels!
On Mon, 22 Sep 2003, Martin Pitt wrote: When Debian claims to ship kernels with security patches, then another Debian package should not silently remove them; that would be very dangerous (and IMHO silly). I could live with this solution if such an unpatch is verbosely announced to the user (let's say, with a debconf note of priority high). No. a debconf note during *installation* has nothing to do with the actual application of a kernel patch, nor the sebsequent building thereof.
Re: IMPORTANT: your message to html-tidy
On Wed, 2003-09-10 at 04:02, Craig Sanders wrote: sorry, a system that only works sometimes (or even most of the time) is a broken system. i prefer to know that my system's behaviour will be consistent and correct. Shamless plug: sign up for totally spam-free forwarding address at http://pay2send.com
Re: Virus emails
On Monday 22 September 2003 16:53, 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. 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. Mike
Bug #47039: renaming slang.
I've been reviewing bugs in slang, and closing those that are fixed, and examining #47039. This requires/recommends that the package names be changed to policy standards: slang1 - libslang1 slang1-dev - libslang1-dev slang1-pic - libslang1-pic slang1-utf8-dev - libslang1-utf8-dev slang1a-utf8 - libslang1-utf8 slang1-utf8-pic - libslang1-utf8-pic slang1-utf8-dev - libslang1-utf8-dev slang1a-utf8-udeb - libslang1-utf8-udeb Doing this is straightforward, but will require work by others: the following packages (other than slang newt, which I maintain), require changes as a result, according to apt-cache: (change Build-Depends, Depends and recompile): dosemu xjed xine-ui xaos ttv timidity ticker tasksel slsc slrnpull slrn slmon pdmenu most lpe libterm-slang-perl jed-common jed gstreamer-aa gphone gimp1.3 gimp fte-terminal francine bb aview asciijump aalib1 aalib-bin util-linux partimage-server partimage nano-tiny lokkit cfdisk-utf8 cdebconf finally, build-essential would need changing, as it lists slang, and it its change would need to be timed with libslang entering testing. This may be too drastic a change at this time. What do debian-devel, and particular the Release Manage, think? Regards, Alastair McKinstry Message sent using UebiMiau 2.7.2
Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]
Matt Zimmerman [EMAIL PROTECTED] writes: What didn't work about anonymous FTP? 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. -- James
Re: Virus emails
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. So I noticed. Very few (only 2-3 out of about 500/day for about 5 days now) actually managed to get past my bogofilter+SA setup, but it's using up a lot of bandwidth. I'd hate to have to pay for wasted bandwidth. The list of hardware required to stop this spam unfortunately seems to include a time machine. [snip] 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. This is only since 2pm today. The problem with this is that you have to hand-pick subnets to prevent inadvertently blocking legitimate mails. I hate to be spending so much time on this, but I really can't see myself paying for extra bandwidth caused by this spam. It's sorta a last-resort thing. Unfortunately, this is not a safe thing to do on the Debian mailing list servers. T -- Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the window.
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. 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) 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: Virus emails
Mike Hommey dijo [Tue, Sep 23, 2003 at 12:28:44AM +0200]: 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. 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. I don't think so - And if so, this could break many client MTAs. According to the protocol definition [1], after the DATA command the server will reply with a 354 code, which means 'Start mail input; end with CRLF.CRLF'. The client might not be expecting anything until the CRLF.CRLF has been sent. If you suddenly send a 5xx error code, the client might never receive it. You may close the connection, but th client might then retry - and consume your bandwith over and over. Greetings, [1] http://www.ietf.org/rfc/rfc0821.txt -- 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
Bug#212049: dependency used backwards
Thomas Hood wrote: On Mon, 2003-09-22 at 00:24, Daniel B. wrote in part: Debian seems to use the word dependency backwards a lot, making things confusing and hard to understand. [...] If A depends on B, then A is a dependency (A is dependent on B). B is _not_ a dependency of A. The word 'dependency' can denote the relation between A and B ; then it isn't oriented one way or the other, e.g., 'There is a dependency between A and B'. Right, that's that primary meaning of dependency (sense 1 in the dictionary I quoted). In Debian, *most* uses of dependency seem to refer to a relationship, and are not a problem. (Although a few might be slightly ambiguous, they're not incorrect.) However, recall that dependency has a second meaning: something that depends on something else. (Consider for example the U.S. dependencies listed at http://falcon.jmu.edu/~ramseyil/states.htm#C ). It's the cases where Debian erroneously uses dependency to refer to the thing that is depended on (instead of the thing that depends on something else) that are a problem. To indicate the orientation you have to say something like 'A depends on B'. Yes, that is certainly the clearest way to indicate the orientation. I think you make a worthwhile point that in some cases the direction of the dependency should be indicated more clearly. ...see bug ...212013... You meant #212031. Yep; sorry to make you search for it. Since merely using dependency correctly would be ambiguous given all the incorrect usage, Debian should probably refer to depended-on package (or library, etc., as the case may be). That construct would be unambiguous and perfectly clear (and wouldn't be much longer than dependency). Suppose we are talking about A. Then your complaint is that A's dependencies is ambiguous between denoting the packages that depend on A and the packages upon which A depends. Yes, is ambiguous are you described, but to clarify: My core complaint is that saying A's dependencies when one means the things that A depends on is plain old wrong (and therefore confusing). I was only saying that A's dependencies would be ambiguous because, given all the incorrect usage, you can't tell whether it was written correctly and means the things that depends on A, or whether it was written incorrectly and means the opposite, the things on which A depends. I don't see how A's depended-on packages is any clearer. Actually it seems worse to me. I suggest using packages upon which A depends and packages that depend on A wherever the ambiguity matters. Yes, that would be even clearer than A's depended-on packages. I had suggested A's depended-on packages because I thought people would object to the longer phrasing you suggested. Actually, another replacement for one case would be prerequisite. The two main cases would be: - referring to the relationship: Apt analyzes dependencies - referring to the depended-on items (the items upon which some given item depends): perl's prerequisites must be installed to install perl (The third case, which is much less common, is referring to items that depend on a given item. Technically, it is correct to call those items dependencies of the given item (in sense 2). However, saying A's dependencies is ambiguous in two ways: - A's dependencies is ambiguous between referring to the dependency relationships and referring to the items that depend on A. - It is ambiguous between current incorrect use referring to the items on which A depends and correct use referring to the items which depends on A. Therefore, any instances of the third case should probably use something like packages that depend on A as you suggest.) Daniel -- Daniel Barclay [EMAIL PROTECTED]
Re: eek, phpgroupware
Hi. Just for the record: My vacation terminated in favor of relocation and trouble with the phone and internet company. (Heck, I don't even have a mailbox or doorbell, yet.) I have some phpgw packages ready at http://vman.de/debian/. They seem to fix some of the more pressing problems in phpgw/sid, however they don't correspond to Luca's package split. Anyhow, my lack of response (hopefully resolved by end of next week) is not a result of disinterest or anything, but rather of lack of connectivity. I'm very honored by Luca's offer and intend to accept once I'm able to communicate and build debian packages again. (But I just found this mail in the haystack of 400 Spam mails, teaches me about client-side filtering...) Cheers T. Luca - De Whiskey's - De Vitis ([EMAIL PROTECTED]) wrote: On Sat, Sep 20, 2003 at 03:54:48PM +1000, Martin Michlmayr wrote: Hey Luca, what's up with this? Maintainer: Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] 163911 [P ] [SX] phpgroupware: missing dependency: php3-xml 164354 [ + ] [UX] phpgroupware postrm halt the purge/uninstalltion process 170820 [] [X] phpgroupware does not preservs user changes in configuration file 183896 [ + ] [X] phpgroupware: postrm shouldn't depend on wwwconfig-common Package: phpgroupware-addressbook (debian/main) Maintainer: Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] 163917 [P+ ] [SX] phpgroupware-addressbook: Fatal error class.uiaddressbook.inc.php on line 821 Package: phpgroupware-core (debian/main) Maintainer: Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] 207797 [ S ] [X] phpgroupware-core: /var/lib/phpgroupware/files are installed globally writeable Package: phpgroupware-todo (debian/main) Maintainer: Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] 163910 [P+ ] [SX] phpgroupware-todo: Php shows a syntax error when entering the todo section I gived up. I'm tired of php4 co, and the project itself is splitting and forking because of contrasts among core developers. More over it seems that my opinion on managing that package(s) (apart from not fixing bug) drastically differs from most peple mailing me: at this time i don't see the point in maintaining it. I've already mailed Thomas (who worked on closing the security bug for stable) about leaving the package(s) to him: he was willing on taking this package a while ago, and would be surely willing on taking it today. He now is on vacation, but should be coming back. Sorry for the inconvenience.
Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]
* Brian White [EMAIL PROTECTED] [2003-09-20 07:37]: Neither SCP nor anonymous-FTP methods work and I want to get that fixed. SSH works. SCP doesn't. Well, it works for everyone else. So it would be good if you'd find out why it doesn't work for you. In the meantime, you can put your signed upload somewhere and someone can simply upload it to ftp-master on your behalf. If you ask on debian-devel@lists.debian.org, I'm sure someone will do that. SCP doesn't work (I suspect) because I'm using the SSH2 package once found in non-free. I mentioned this (and the reasons why) some time back. What I've been doing is using SSH to get to ftp-master and the wget to fetch the files from my machine at home. I could use the tar method you gave, though. What I would _like_ to do is use the anonymous-ftp method of dupload. However, I get tons of errors from the queue daemon about it not being able to find my GPG key. This is what I would like to get fixed. Brian ( [EMAIL PROTECTED] ) --- Touch passion when it comes your way. It's rare enough as it is. Don't walk away when it calls you by name. -- Marcus (Babylon 5)
Re: Virus emails
On Mon, 22 Sep 2003 19:34:58 -0400
H. S. Teoh [EMAIL PROTECTED] wrote:
I've resorted to blocking port 25 to subnets from which these spams
What would help is to be able to block an IP once it's been hit. Thing is
I cannot for the life of me figure out a way to do it. Here's the first 25
that hit me today:
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.166.16.7]
[12.17.134.9]
[128.143.2.219]
[128.143.2.219]
[128.146.216.43]
[128.146.216.45]
[129.82.100.130]
[129.82.100.130]
[130.244.199.129]
[130.244.199.132]
[132.64.1.17]
[142.165.19.3]
[142.165.19.5]
[142.169.1.100]
[144.135.24.153]
[144.135.24.153]
Notice the duplicates. Now if I could enter a blacklist entry into
shorewall after the first hit...
[EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print $5}' |
sort
| wc -l
743
[EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print $5}' |
sort
| uniq | wc -l
336
I'd drop the load from 743 down to 336. Assuming all of those are Swen or
some variant then it would be a savings of about 4Mb so far today.
Of course that's what's gotten past the IPs I've already blacklisted.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
pgpqCXSI4C5gg.pgp
Description: PGP signature
Re: Virus emails
On Mon, 22 Sep 2003 18:48:58 -0500 Gunnar Wolf [EMAIL PROTECTED] wrote: [1] http://www.ietf.org/rfc/rfc0821.txt And what does RFC2821 have to say about it? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpcssJgAdQlp.pgp Description: PGP signature
Re: Virus emails
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. -- gram signature.asc Description: Digital signature
Re: Virus emails
On Mon, Sep 22, 2003 at 07:18:56PM -0700, Steve Lamb wrote:
On Mon, 22 Sep 2003 19:34:58 -0400
H. S. Teoh [EMAIL PROTECTED] wrote:
I've resorted to blocking port 25 to subnets from which these spams
What would help is to be able to block an IP once it's been hit. Thing is
I cannot for the life of me figure out a way to do it. Here's the first 25
that hit me today:
[12.166.16.7]
[snip]
Strange, I didn't get any from 12.0.0.0/8 at all.
[128.143.2.219]
[128.143.2.219]
Now *this* looks familiar.
[128.146.216.43]
[128.146.216.45]
[129.82.100.130]
[snip]
Didn't see these either.
[132.64.1.17]
Saw this one, and none of the others.
Notice the duplicates. Now if I could enter a blacklist entry into
shorewall after the first hit...
There is definitely a lot of duplicates, which was what drove me to ban it
at the IP level in the first place. Looking at my firewall counters, I've
had 138 attempts from 212.216.0.0/16 alone. (Granted, that was a wide
netblock, but I don't get mail from .it, and tons of virus mails were
coming from there.)
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.
[snip]
[EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print $5}'
| sort
| wc -l
743
[EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print $5}'
| sort
| uniq | wc -l
336
What are the exim rules you used to catch these things?
I'd drop the load from 743 down to 336. Assuming all of those are Swen
or some variant then it would be a savings of about 4Mb so far today.
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).
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. Caution is advised, though---some Swen mails
are coming through the Debian lists, so you want to make sure you don't
accidentally blacklist murphy or gluck. :-)
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.
Of course that's what's gotten past the IPs I've already blacklisted.
[snip]
I can literally watch the firewall counters go up every minute. Sometimes
it's 3 or 4 per second. The stuff that still gets through ends up in my
spam box at about 2-3 per 20 minutes or so. (Much better than the 120/hour
during the weekend.)
T
--
Too many people have open minds but closed eyes.
Re: IMPORTANT: your message to html-tidy
On Mon, Sep 22, 2003 at 05:09:30PM -0500, david nicol wrote: On Wed, 2003-09-10 at 04:02, Craig Sanders wrote: sorry, a system that only works sometimes (or even most of the time) is a broken system. i prefer to know that my system's behaviour will be consistent and correct. Shamless plug: sign up for totally spam-free forwarding address at http://pay2send.com would this message be blocked? -- gram signature.asc Description: Digital signature
Re: Virus emails
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.
[snip]
[EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print
$5}' |
sort| wc -l
743
[EMAIL PROTECTED]:/var/log/exim4# grep -i malware mainlog | awk '{print
$5}' |
sort| uniq | wc -l
336
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).
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?
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.
Caution is advised, though---some Swen mails are coming through the Debian
lists, so you want to make sure you don't accidentally blacklist murphy or
gluck. :-)
... Carp, so much for that idea, eh? :/
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 can literally watch the firewall counters go up every minute. Sometimes
it's 3 or 4 per second. The stuff that still gets through ends up in my
spam box at about 2-3 per 20 minutes or so. (Much better than the 120/hour
during the weekend.)
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?
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
---+-
pgpsg99Ynf1Pk.pgp
Description: PGP signature
Accepted dbus 0.12-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 12:13:06 +1000 Source: dbus Binary: dbus-glib-1 dbus-1-doc dbus-glib-1-dev dbus-1-utils dbus-1 dbus-1-dev Architecture: source i386 all Version: 0.12-4 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: dbus-1 - simple inter-process messaging system dbus-1-dev - simple inter-process messaging system (development headers) dbus-1-doc - simple inter-process messaging system (documentation) dbus-1-utils - simple inter-process messaging system (utilities) dbus-glib-1 - simple inter-process messaging system (GLib-based shared library) dbus-glib-1-dev - simple inter-process messaging system (GLib interface) Closes: 209143 Changes: dbus (0.12-4) unstable; urgency=low . * debian/control: + Taking over from Colin as maintainer. + Bump debhelper Build-Dep to =4.1.46, when dh_installlogcheck was first introduced. + Bump Standards-Version to 3.6.1. + Add Replaces/Provides/Conflicts on earlier dbus-1 versions to dbus-1-utils. * debian/dbus-1.init: + Clean up after the daemon's pidfile mess, ensuring smooth upgrades. (closes: #209143) Files: 90affa86093d9781e52b86ffe3e8482b 694 devel optional dbus_0.12-4.dsc 574ad3afb8301a8ac0d6a90e35ae00d4 7916 devel optional dbus_0.12-4.diff.gz 6a74f4c034bcaf8c7a925216cfde8167 756528 doc optional dbus-1-doc_0.12-4_all.deb b992900a1f45a25dff6d8bf836ac0e84 242468 devel optional dbus-1_0.12-4_i386.deb 1c9baf2f3af9c931a06b42d3a5c373af 60022 libs optional dbus-glib-1_0.12-4_i386.deb 549a5fd096f746cfd748ead58aef6a4b 66362 utils optional dbus-1-utils_0.12-4_i386.deb 90375300b5ca9ccaafc1382c313793b4 156594 libdevel optional dbus-1-dev_0.12-4_i386.deb a277a85dddbd52a3a6bc057a0b57c22a 59734 libdevel optional dbus-glib-1-dev_0.12-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/br9yKb5dImj9VJ8RAs3CAJ9kr7AEWk1YivSyAbGKWM8QJxg9HQCbBse0 itFldq6dKSHrHYTHs3Puy9s= =P+H+ -END PGP SIGNATURE- Accepted: dbus-1-dev_0.12-4_i386.deb to pool/main/d/dbus/dbus-1-dev_0.12-4_i386.deb dbus-1-doc_0.12-4_all.deb to pool/main/d/dbus/dbus-1-doc_0.12-4_all.deb dbus-1-utils_0.12-4_i386.deb to pool/main/d/dbus/dbus-1-utils_0.12-4_i386.deb dbus-1_0.12-4_i386.deb to pool/main/d/dbus/dbus-1_0.12-4_i386.deb dbus-glib-1-dev_0.12-4_i386.deb to pool/main/d/dbus/dbus-glib-1-dev_0.12-4_i386.deb dbus-glib-1_0.12-4_i386.deb to pool/main/d/dbus/dbus-glib-1_0.12-4_i386.deb dbus_0.12-4.diff.gz to pool/main/d/dbus/dbus_0.12-4.diff.gz dbus_0.12-4.dsc to pool/main/d/dbus/dbus_0.12-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dupload 2.6.3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 11:39:54 +0200 Source: dupload Binary: dupload Architecture: source all Version: 2.6.3 Distribution: unstable Urgency: medium Maintainer: Josip Rodin [EMAIL PROTECTED] Changed-By: Josip Rodin [EMAIL PROTECTED] Description: dupload- utility to upload Debian packages Closes: 212093 Changes: dupload (2.6.3) unstable; urgency=medium . * Fixed package build directory to actually include the contents in the .deb (d'oh!), closes: #212093. Files: 0deb3090d25cd837e17ef04e87b5bffe 529 devel optional dupload_2.6.3.dsc ebb059be445f7f6d4c0a911dd9a49268 20859 devel optional dupload_2.6.3.tar.gz 4e155b0ac75a0486602ca8daaf8b9d49 27462 devel optional dupload_2.6.3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/bsO7C1RHoiANFZYRArxuAJ4kzoePAd93qhNyiAD9XKFLXESbxgCgjdyX GK104xdiwXvlDj9uVLB9OVM= =w+wX -END PGP SIGNATURE- Accepted: dupload_2.6.3.dsc to pool/main/d/dupload/dupload_2.6.3.dsc dupload_2.6.3.tar.gz to pool/main/d/dupload/dupload_2.6.3.tar.gz dupload_2.6.3_all.deb to pool/main/d/dupload/dupload_2.6.3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gossip 0.5-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 11:15:00 +0100 Source: gossip Binary: gossip Architecture: source i386 Version: 0.5-3 Distribution: unstable Urgency: low Maintainer: Ross Burton [EMAIL PROTECTED] Changed-By: Ross Burton [EMAIL PROTECTED] Description: gossip - Friendly Jabber client for GNOME Closes: 211581 Changes: gossip (0.5-3) unstable; urgency=low . * Add a missing comma to the Depends (closes: #211581) Files: d1bff08933d491920ead100e4a505b71 599 gnome optional gossip_0.5-3.dsc 36facc014e2649a11f2ada2e2ed466b0 1765 gnome optional gossip_0.5-3.diff.gz 84fab00f0a1d103cddd6d1de99687fe7 393900 gnome optional gossip_0.5-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/bsw6LQnkR9C0M98RAlfJAKDnb30fWlalei7UMP42/rkjF/xw/gCgyJ0L JA5n3GKi1k6xBS7W4eE4eTA= =+BEI -END PGP SIGNATURE- Accepted: gossip_0.5-3.diff.gz to pool/main/g/gossip/gossip_0.5-3.diff.gz gossip_0.5-3.dsc to pool/main/g/gossip/gossip_0.5-3.dsc gossip_0.5-3_i386.deb to pool/main/g/gossip/gossip_0.5-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lifelines 3.0.32-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 08:30:14 +0200 Source: lifelines Binary: lifelines lifelines-reports lifelines-doc Architecture: source i386 all Version: 3.0.32-1 Distribution: experimental Urgency: low Maintainer: Christian Perrier [EMAIL PROTECTED] Changed-By: Christian Perrier [EMAIL PROTECTED] Description: lifelines - Text-based genealogy software lifelines-doc - Documentation for lifelines, a genealogy software system lifelines-reports - Reports for lifelines, a genealogy software system Changes: lifelines (3.0.32-1) experimental; urgency=low . * New upstream version. Uploaded to experimental as this is tagged beta by upstream which recommends waiting for a next stable version Files: b7170c20d1811688dfb17b67a6861f37 707 misc optional lifelines_3.0.32-1.dsc 5373642ec8d2263497c8e3cd0778cc37 2028857 misc optional lifelines_3.0.32.orig.tar.gz 582cc6ecdc13e180180af7741c6202f1 18704 misc optional lifelines_3.0.32-1.diff.gz 615bdac120c91b71902b4c4a2ef31d74 658964 doc optional lifelines-doc_3.0.32-1_all.deb c0f68c3802800453e1ffd4222b7064cc 304684 misc optional lifelines-reports_3.0.32-1_all.deb 554f86037797a3feae6da7108527cfd8 830918 misc optional lifelines_3.0.32-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/br0XiONoszDJNIoRArojAJ45WN90Iyhn4TfI94NiAgyiWyr7CgCfTmqW FiVyipQXbxWpEfVzD/tdklU= =sE6P -END PGP SIGNATURE- Accepted: lifelines-doc_3.0.32-1_all.deb to pool/main/l/lifelines/lifelines-doc_3.0.32-1_all.deb lifelines-reports_3.0.32-1_all.deb to pool/main/l/lifelines/lifelines-reports_3.0.32-1_all.deb lifelines_3.0.32-1.diff.gz to pool/main/l/lifelines/lifelines_3.0.32-1.diff.gz lifelines_3.0.32-1.dsc to pool/main/l/lifelines/lifelines_3.0.32-1.dsc lifelines_3.0.32-1_i386.deb to pool/main/l/lifelines/lifelines_3.0.32-1_i386.deb lifelines_3.0.32.orig.tar.gz to pool/main/l/lifelines/lifelines_3.0.32.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted abook 0.5.0-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 10:42:44 + Source: abook Binary: abook Architecture: source i386 Version: 0.5.0-2 Distribution: unstable Urgency: low Maintainer: Gerfried Fuchs [EMAIL PROTECTED] Changed-By: Gerfried Fuchs [EMAIL PROTECTED] Description: abook - A text-based ncurses address book application Closes: 205120 205838 208953 Changes: abook (0.5.0-2) unstable; urgency=low . * Added po-debconf translations: - Polish by Bartosz Zapalowski (closes: #208953) - Frensh by Pierre Machard (closes: #205120) - Brazilian Portuguese by Andre Luis Lopes (closes: #205838) * Updated to policy 3.6.1 (no changes needed). Files: cdce9aa1de0888f3d4c55bbb8264fbc0 579 mail optional abook_0.5.0-2.dsc 1ef55335df7dd64d81c176f4b8d9 33443 mail optional abook_0.5.0-2.diff.gz 8cd2fc9932ccc7e30592c31150303ae7 54736 mail optional abook_0.5.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/btyYELuA/Ba9d8YRAq2CAKClkJKdLkx9uEgPkfty8TCFK4QLMACff/iY +qDOxY50AH0RW1Wst8EIJAU= =XsbE -END PGP SIGNATURE- Accepted: abook_0.5.0-2.diff.gz to pool/main/a/abook/abook_0.5.0-2.diff.gz abook_0.5.0-2.dsc to pool/main/a/abook/abook_0.5.0-2.dsc abook_0.5.0-2_i386.deb to pool/main/a/abook/abook_0.5.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mozilla-firebird 0.6.1-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 00:00:08 -0400 Source: mozilla-firebird Binary: mozilla-firebird-dom-inspector mozilla-firebird Architecture: source i386 Version: 0.6.1-7 Distribution: unstable Urgency: low Maintainer: Eric Dorland [EMAIL PROTECTED] Changed-By: Eric Dorland [EMAIL PROTECTED] Description: mozilla-firebird - a light-weight browser based on Mozilla mozilla-firebird-dom-inspector - A tool for inspecting the DOM of pages in Mozilla Firebird Closes: 209339 211146 211286 211706 212011 Changes: mozilla-firebird (0.6.1-7) unstable; urgency=low . * Rebuild with the latest and greatest from unstable. This seems to fix the problems with bookmarks people were having, at least for me. No idea why. Please reopen if this doesn't fix it for you. (Closes: #209339, #211706, #211286, #211146, #212011) Files: 2cbbb03256136cea167f93663f85e699 797 web optional mozilla-firebird_0.6.1-7.dsc 354e5067edc74b6491a54b3639a1130b 140456 web optional mozilla-firebird_0.6.1-7.diff.gz 621bc1b95b1186c57a696cf24e44fe9b 10295666 web optional mozilla-firebird_0.6.1-7_i386.deb 508d6d64ac2108a61f137da92155f4a5 132746 web optional mozilla-firebird-dom-inspector_0.6.1-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/btq2YemOzxbZcMYRApaUAJ0dXvDXZlpxTf9mYwhOGZRm0n+aOwCgqO95 2OtFjY76Ejo4lyLg7OwqETA= =BICB -END PGP SIGNATURE- Accepted: mozilla-firebird-dom-inspector_0.6.1-7_i386.deb to pool/main/m/mozilla-firebird/mozilla-firebird-dom-inspector_0.6.1-7_i386.deb mozilla-firebird_0.6.1-7.diff.gz to pool/main/m/mozilla-firebird/mozilla-firebird_0.6.1-7.diff.gz mozilla-firebird_0.6.1-7.dsc to pool/main/m/mozilla-firebird/mozilla-firebird_0.6.1-7.dsc mozilla-firebird_0.6.1-7_i386.deb to pool/main/m/mozilla-firebird/mozilla-firebird_0.6.1-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sendmail 8.12.10-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE-
Format: 1.7
Date: Mon, 22 Sep 2003 15:00:00 -
Source: sendmail
Binary: libmilter-dev sendmail-doc sendmail
Architecture: source all i386
Version: 8.12.10-3
Distribution: unstable
Urgency: low
Maintainer: Richard A Nelson (Rick) [EMAIL PROTECTED]
Changed-By: Richard A Nelson (Rick) [EMAIL PROTECTED]
Description:
libmilter-dev - Sendmail Mail Filter API (Milter)
sendmail - A powerful, efficient, and scalable Mail Transport Agent
sendmail-doc - A powerful, efficient, and scalable Mail Transport Agent
Closes: 211813 212178
Changes:
sendmail (8.12.10-3) unstable; urgency=low
.
* /etc/init.d/sendmail status didn't work with queue daemon
* Check {QUEUE,MSP}_INTERVAL for 0 when updating crontab closes: #212178
* Correct case of cron/inet checks in update_conf closes: #211813
Files:
79a31bad1b93ac7de31aedc011cc653e 900 mail extra sendmail_8.12.10-3.dsc
37a83141e6b1061afa1dfcadd6d869db 413753 mail extra sendmail_8.12.10-3.diff.gz
94e0627ac23702b52f8e4fc42208fbd7 796342 doc extra sendmail-doc_8.12.10-3_all.deb
6fc0dc750332a2502913b045fc508669 1019520 mail extra sendmail_8.12.10-3_i386.deb
1be055125a9957a53483becd82be18d0 280958 libdevel extra
libmilter-dev_8.12.10-3_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
iQCVAwUBP28Q9KVTksHk9ElFAQHfUQQAoSY0teK4F2Or7f4p3vkwPMnMCRGJQZw/
xNsGeeJC0b5EMfaEuzgopq9pmgvsvMPjt/XmM9tJn4dnuGe6cZV593hWqBnpmWDY
mLCCtufkwViH5J6YCuExe8lvSEUckeoMPToETwoiqL0FQHc0hP0ibGTMNKAnTA/T
SjqVXgwPcME=
=k6QF
-END PGP SIGNATURE-
Accepted:
libmilter-dev_8.12.10-3_i386.deb
to pool/main/s/sendmail/libmilter-dev_8.12.10-3_i386.deb
sendmail-doc_8.12.10-3_all.deb
to pool/main/s/sendmail/sendmail-doc_8.12.10-3_all.deb
sendmail_8.12.10-3.diff.gz
to pool/main/s/sendmail/sendmail_8.12.10-3.diff.gz
sendmail_8.12.10-3.dsc
to pool/main/s/sendmail/sendmail_8.12.10-3.dsc
sendmail_8.12.10-3_i386.deb
to pool/main/s/sendmail/sendmail_8.12.10-3_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted caudium 2:1.2.31-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 17:49:02 +0200 Source: caudium Binary: caudium-ultralog caudium-pixsl caudium-perl caudium caudium-dev caudium-modules Architecture: source i386 Version: 2:1.2.31-4 Distribution: unstable Urgency: high Maintainer: Marek Habersack [EMAIL PROTECTED] Changed-By: Marek Habersack [EMAIL PROTECTED] Description: caudium- An extensible WWW server written in Pike caudium-dev - Development files for Caudium caudium-modules - C modules for Caudium caudium-perl - Perl script support for Caudium caudium-pixsl - Pike XSLT module for Caudium caudium-ultralog - Log Parser module for Caudium Closes: 212054 Changes: caudium (2:1.2.31-4) unstable; urgency=high . * Removed a stray dot from the build depends line (closes: Bug#212054) Files: 78e05e7e04cb1f8b7b7800ce55b486bc 798 web optional caudium_1.2.31-4.dsc dd830978f055f7967129019c9fd5823c 63552 web optional caudium_1.2.31-4.diff.gz c5792d20db0a62e8b1a8f607eeb62673 2770540 web optional caudium_1.2.31-4_i386.deb 0b66fdfb214c65ae549855ab971030a2 34292 web optional caudium-modules_1.2.31-4_i386.deb 29826ada28019109ecfb7d0afe8bafd1 30420 web optional caudium-pixsl_1.2.31-4_i386.deb ebe840bcffe7d11b448b368426dc26a2 69470 web optional caudium-ultralog_1.2.31-4_i386.deb b52b8244b4d0e1784c4acc5523ef2919 18816 devel optional caudium-dev_1.2.31-4_i386.deb a18c7f2a29279e109869048f3a145c50 26462 web optional caudium-perl_1.2.31-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/byGkq3909GIf5uoRAtszAJ9MW5KfHeh1t9zAUhZLWpLNgZtsvACghv8h DdtxENFykFUFuYOr4eQZ+C4= =D7uz -END PGP SIGNATURE- Accepted: caudium-dev_1.2.31-4_i386.deb to pool/main/c/caudium/caudium-dev_1.2.31-4_i386.deb caudium-modules_1.2.31-4_i386.deb to pool/main/c/caudium/caudium-modules_1.2.31-4_i386.deb caudium-perl_1.2.31-4_i386.deb to pool/main/c/caudium/caudium-perl_1.2.31-4_i386.deb caudium-pixsl_1.2.31-4_i386.deb to pool/main/c/caudium/caudium-pixsl_1.2.31-4_i386.deb caudium-ultralog_1.2.31-4_i386.deb to pool/main/c/caudium/caudium-ultralog_1.2.31-4_i386.deb caudium_1.2.31-4.diff.gz to pool/main/c/caudium/caudium_1.2.31-4.diff.gz caudium_1.2.31-4.dsc to pool/main/c/caudium/caudium_1.2.31-4.dsc caudium_1.2.31-4_i386.deb to pool/main/c/caudium/caudium_1.2.31-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kde-icons-noia 1.0-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 14:13:20 +0200 Source: kde-icons-noia Binary: kde-icons-noia Architecture: source all Version: 1.0-2 Distribution: unstable Urgency: low Maintainer: Morten Hustveit [EMAIL PROTECTED] Changed-By: Morten Hustveit [EMAIL PROTECTED] Description: kde-icons-noia - Noia icon theme for KDE 3 Closes: 212144 Changes: kde-icons-noia (1.0-2) unstable; urgency=low . * Fixed copy/paste errors in copyright file (Closes: #212144). Files: c8087b083fc42408e456cdba63a4bc89 597 kde optional kde-icons-noia_1.0-2.dsc 32c5cbee483fdde1de07fbbeb9106d11 1435 kde optional kde-icons-noia_1.0-2.diff.gz df7431a2de442100a95627a5302ff82d 11764982 kde optional kde-icons-noia_1.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/bumm4996V3ZlqLcRAlNCAJ9z7FmnllTmBVgFVMxjAZ48QYqqlgCfWDY7 uCn1XTXvTQKMSBUFzfuWVzY= =P3CN -END PGP SIGNATURE- Accepted: kde-icons-noia_1.0-2.diff.gz to pool/main/k/kde-icons-noia/kde-icons-noia_1.0-2.diff.gz kde-icons-noia_1.0-2.dsc to pool/main/k/kde-icons-noia/kde-icons-noia_1.0-2.dsc kde-icons-noia_1.0-2_all.deb to pool/main/k/kde-icons-noia/kde-icons-noia_1.0-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rep-gtk 0.18-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 14:23:01 +0200 Source: rep-gtk Binary: rep-gtk-gnome rep-gtk Architecture: source i386 Version: 0.18-2 Distribution: unstable Urgency: low Maintainer: Christian Marillat [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: rep-gtk- GTK binding for librep rep-gtk-gnome - GNOME 2 binding for librep Closes: 212118 Changes: rep-gtk (0.18-2) unstable; urgency=low . * Build with --with-gnome (Closes: #212118) * Move examples files in rep-gtk-gnome, some example need gnome extension Files: e69acca580bfbb2c7b662604461d53a9 675 interpreters optional rep-gtk_0.18-2.dsc 87e6d9fe845f3c59ee081d6c946ed702 2649 interpreters optional rep-gtk_0.18-2.diff.gz b52b7bcc3591f9f80612b3fc66658de4 195790 interpreters optional rep-gtk_0.18-2_i386.deb 65ecbb03d59125445f3be5f50b626945 85738 interpreters optional rep-gtk-gnome_0.18-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/buxaB9xWPR9BuQcRAm/hAJ0Z1OoE7HU5oIWshHMu8D/0cMIJYACdGLQ5 3lnMnb1deSpBltjEAwRb/pw= =KibP -END PGP SIGNATURE- Accepted: rep-gtk-gnome_0.18-2_i386.deb to pool/main/r/rep-gtk/rep-gtk-gnome_0.18-2_i386.deb rep-gtk_0.18-2.diff.gz to pool/main/r/rep-gtk/rep-gtk_0.18-2.diff.gz rep-gtk_0.18-2.dsc to pool/main/r/rep-gtk/rep-gtk_0.18-2.dsc rep-gtk_0.18-2_i386.deb to pool/main/r/rep-gtk/rep-gtk_0.18-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apg 2.2.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 12:43:10 + Source: apg Binary: apg Architecture: source i386 Version: 2.2.3-1 Distribution: unstable Urgency: low Maintainer: Marc Haber [EMAIL PROTECTED] Changed-By: Marc Haber [EMAIL PROTECTED] Description: apg- Automated Password Generator - Standalone version Changes: apg (2.2.3-1) unstable; urgency=low . * new upstream version * set -t both in wrapper and default apg.conf Files: fc3e0919715e95d8ddb1bd14176eea39 556 admin optional apg_2.2.3-1.dsc 3b3fc4f11e90635519fe627c1137c9ac 108186 admin optional apg_2.2.3.orig.tar.gz ff07a9521f48065e7a03326ffe5cb738 3666 admin optional apg_2.2.3-1.diff.gz e67d8619d0d8f609594315b25bb25a20 49788 admin optional apg_2.2.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/bu8jgZalRGu6PIQRAqecAJ9Gxpu9r6dyABN9gFm/wjvRIh/r5QCePMQx 7CRHmTTNTjdo5fnLcCu6m00= =GCE+ -END PGP SIGNATURE- Accepted: apg_2.2.3-1.diff.gz to pool/main/a/apg/apg_2.2.3-1.diff.gz apg_2.2.3-1.dsc to pool/main/a/apg/apg_2.2.3-1.dsc apg_2.2.3-1_i386.deb to pool/main/a/apg/apg_2.2.3-1_i386.deb apg_2.2.3.orig.tar.gz to pool/main/a/apg/apg_2.2.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kernel-patch-2.4-supermount-ng 1.2.9-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 22 Sep 2003 14:45:52 +0200 Source: kernel-patch-2.4-supermount-ng Binary: kernel-patch-2.4-supermount-ng Architecture: source all Version: 1.2.9-3 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Mika Fischer [EMAIL PROTECTED] Description: kernel-patch-2.4-supermount-ng - Automatically mount and unmount removable media Closes: 212061 Changes: kernel-patch-2.4-supermount-ng (1.2.9-3) unstable; urgency=low . * Rebuild to get rid of ARRAY(0x82c) in Build-Depends-Indep (closes: #212061) Files: 32e21abea65cf1d1cd828a8a94e3ccf1 677 devel extra kernel-patch-2.4-supermount-ng_1.2.9-3.dsc 73e9c578e8dd6c1d814a7560628aa732 42071 devel extra kernel-patch-2.4-supermount-ng_1.2.9-3.diff.gz 6b2d792885affa41d129764d64bda83a 131804 devel extra kernel-patch-2.4-supermount-ng_1.2.9-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iEYEARECAAYFAj9u8DUACgkQUN8Zkye7QvAS6wCgsGoUZAyVmacEY1wecrT3jcwX sRsAn3B7Xy7A4YjcQf467WItOJJY21Zm =xJHl -END PGP SIGNATURE- Accepted: kernel-patch-2.4-supermount-ng_1.2.9-3.diff.gz to pool/main/k/kernel-patch-2.4-supermount-ng/kernel-patch-2.4-supermount-ng_1.2.9-3.diff.gz kernel-patch-2.4-supermount-ng_1.2.9-3.dsc to pool/main/k/kernel-patch-2.4-supermount-ng/kernel-patch-2.4-supermount-ng_1.2.9-3.dsc kernel-patch-2.4-supermount-ng_1.2.9-3_all.deb to pool/main/k/kernel-patch-2.4-supermount-ng/kernel-patch-2.4-supermount-ng_1.2.9-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted liboptparse-ruby 0.12-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 13 Sep 2003 15:46:30 +0900 Source: liboptparse-ruby Binary: liboptparse-ruby1.6 Architecture: source all Version: 0.12-1 Distribution: unstable Urgency: low Maintainer: akira yamada [EMAIL PROTECTED] Changed-By: akira yamada [EMAIL PROTECTED] Description: liboptparse-ruby1.6 - Command line option parser class for Ruby 1.6 Changes: liboptparse-ruby (0.12-1) unstable; urgency=low . * new upstream version. * rebuild with ruby1.6. * renamed to liboptparse-ruby1.6 from liboptparse-ruby. Files: 0ce9460f64053b92e110369f3b3d5652 611 interpreters optional liboptparse-ruby_0.12-1.dsc 94a429a471f3d5736d310c6d4a737b31 77027 interpreters optional liboptparse-ruby_0.12.orig.tar.gz 5bc794b20f3404fa0a391f984d0a3684 3146 interpreters optional liboptparse-ruby_0.12-1.diff.gz b411bd42efef834fd962025d8427e8b8 73806 interpreters optional liboptparse-ruby1.6_0.12-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/YsSWXzkxpuIT8aARAoKMAJ0TbW32AkJkDEnz20VHqfrSaau8vACfS5k6 3+tjrtkysGjz5VJzX5gutvk= =T+3+ -END PGP SIGNATURE- Accepted: liboptparse-ruby1.6_0.12-1_all.deb to pool/main/libo/liboptparse-ruby/liboptparse-ruby1.6_0.12-1_all.deb liboptparse-ruby_0.12-1.diff.gz to pool/main/libo/liboptparse-ruby/liboptparse-ruby_0.12-1.diff.gz liboptparse-ruby_0.12-1.dsc to pool/main/libo/liboptparse-ruby/liboptparse-ruby_0.12-1.dsc liboptparse-ruby_0.12.orig.tar.gz to pool/main/libo/liboptparse-ruby/liboptparse-ruby_0.12.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libhtml-parser-ruby 0.19990912.p2-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 13 Sep 2003 15:32:26 +0900 Source: libhtml-parser-ruby Binary: libhtml-parser-ruby1.6 libhtml-parser-ruby1.8 Architecture: source all Version: 0.19990912.p2-2 Distribution: unstable Urgency: low Maintainer: akira yamada [EMAIL PROTECTED] Changed-By: akira yamada [EMAIL PROTECTED] Description: libhtml-parser-ruby1.6 - HTML parser library for Ruby 1.6 libhtml-parser-ruby1.8 - HTML parser library for Ruby 1.8 Changes: libhtml-parser-ruby (0.19990912.p2-2) unstable; urgency=low . * rebuild with ruby1.6 and ruby1.8. * renamed to libhtml-parser-ruby1.6 from libhtml-parser-ruby. * new sub-package libhtml-parser-ruby1.8 for Ruby 1.8. Files: d07a3271a102b73469c4335c03248281 702 interpreters optional libhtml-parser-ruby_0.19990912.p2-2.dsc 94e2f8d991d3d6c13e30394bfcbb113b 3274 interpreters optional libhtml-parser-ruby_0.19990912.p2-2.diff.gz 845f690569830913857a56081da27f6d 10050 interpreters optional libhtml-parser-ruby1.6_0.19990912.p2-2_all.deb 765bdafebd6efbd1174ad36906cbda3c 8020 interpreters optional libhtml-parser-ruby1.8_0.19990912.p2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/YrraXzkxpuIT8aARAk9mAJ4nu1TvM1YNNI7hOhCWicpfNgTZ/gCeNrok 6SYdtNrcsNVkh4HQPC1Xpoo= =aIUE -END PGP SIGNATURE- Accepted: libhtml-parser-ruby1.6_0.19990912.p2-2_all.deb to pool/main/libh/libhtml-parser-ruby/libhtml-parser-ruby1.6_0.19990912.p2-2_all.deb libhtml-parser-ruby1.8_0.19990912.p2-2_all.deb to pool/main/libh/libhtml-parser-ruby/libhtml-parser-ruby1.8_0.19990912.p2-2_all.deb libhtml-parser-ruby_0.19990912.p2-2.diff.gz to pool/main/libh/libhtml-parser-ruby/libhtml-parser-ruby_0.19990912.p2-2.diff.gz libhtml-parser-ruby_0.19990912.p2-2.dsc to pool/main/libh/libhtml-parser-ruby/libhtml-parser-ruby_0.19990912.p2-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libnet-acl-ruby 1.0.1-4 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 13 Sep 2003 16:18:26 +0900 Source: libnet-acl-ruby Binary: libnet-acl-ruby1.6 Architecture: source all Version: 1.0.1-4 Distribution: unstable Urgency: low Maintainer: akira yamada [EMAIL PROTECTED] Changed-By: akira yamada [EMAIL PROTECTED] Description: libnet-acl-ruby1.6 - Simple Access Control Class for Ruby 1.6 Changes: libnet-acl-ruby (1.0.1-4) unstable; urgency=low . * Conflicts/Replaces: libnet-acl-ruby ( 1.0.1-3). Files: 964685698eae95ef0db1aa2301d49fdb 616 interpreters extra libnet-acl-ruby_1.0.1-4.dsc 6b42a5336c3a5682bc0e59dbd3b49d88 2845 interpreters extra libnet-acl-ruby_1.0.1-4.diff.gz 42682dbfa852e7132c76773ce6a9b0f7 6872 interpreters extra libnet-acl-ruby1.6_1.0.1-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/YsUyXzkxpuIT8aARAoLJAJ9v6ajSxC/T1p0r1RsQG6kq3Wfu0gCbB7OV vd168GKO/gIGMrZYNR4/mPw= =chOB -END PGP SIGNATURE- Accepted: libnet-acl-ruby1.6_1.0.1-4_all.deb to pool/main/libn/libnet-acl-ruby/libnet-acl-ruby1.6_1.0.1-4_all.deb libnet-acl-ruby_1.0.1-4.diff.gz to pool/main/libn/libnet-acl-ruby/libnet-acl-ruby_1.0.1-4.diff.gz libnet-acl-ruby_1.0.1-4.dsc to pool/main/libn/libnet-acl-ruby/libnet-acl-ruby_1.0.1-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnucash-docs 1.8.3-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Mon, 22 Sep 2003 10:41:21 -0400 Source: gnucash-docs Binary: gnucash-docs Architecture: source all Version: 1.8.3-2 Distribution: unstable Urgency: low Maintainer: James A. Treacy [EMAIL PROTECTED] Changed-By: James A. Treacy [EMAIL PROTECTED] Description: gnucash-docs - Documentation for gnucash, a personal finance tracking program Closes: 212091 Changes: gnucash-docs (1.8.3-2) unstable; urgency=low . * Fix libdb-dev dependency in Build-Depends. Closes: #212091 Files: fb66308a08fabaf59c3251d5f48681bf 726 doc extra gnucash-docs_1.8.3-2.dsc 262662b6a88e47e88a39816b88035804 314985 doc extra gnucash-docs_1.8.3-2.diff.gz cf4657e5d8e89aa7ca251ca0593189e4 2732004 doc extra gnucash-docs_1.8.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUBP28OVw9y7Te6Cn61AQHzCgP7BOTnzAzOs2ULV26RiZUvI7pg0g5LvRk8 cmCsAzA1LtVGQBrfs66LkbfKN7K0l1tx8su8/63PgjR60vSFwbJc6aedhTh5fZ11 PZ4UW5VwLbfj7nq5lJhocNLK6umxwlZ8S3F6Z638XkokJpM+IiRpF9HHTbPemTyo Rpm/lfACUMI= =+h+5 -END PGP SIGNATURE- Accepted: gnucash-docs_1.8.3-2.diff.gz to pool/main/g/gnucash-docs/gnucash-docs_1.8.3-2.diff.gz gnucash-docs_1.8.3-2.dsc to pool/main/g/gnucash-docs/gnucash-docs_1.8.3-2.dsc gnucash-docs_1.8.3-2_all.deb to pool/main/g/gnucash-docs/gnucash-docs_1.8.3-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted conglomerate 0.7.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Fri, 19 Sep 2003 16:20:37 +
Source: conglomerate
Binary: conglomerate
Architecture: source i386
Version: 0.7.2-1
Distribution: unstable
Urgency: low
Maintainer: Geert Stappers [EMAIL PROTECTED]
Changed-By: Sven Luther [EMAIL PROTECTED]
Description:
conglomerate - userfriendly XML editor
Changes:
conglomerate (0.7.2-1) unstable; urgency=low
.
* new upstream version.
.
* control
- recommending xml-core.
- suggesting docbook-xml and docbook-xsl.
- avoiding short desc. in long desc. warning from Linda.
.
* compat, new file, now we are debhelper V4. That had these effects:
- The control file has added ${misc:Depends} to ${shlib:Depends}.
- Building is done in debian/conglomerate instead of debian/tmp.
.
* rules
- does call dh_scrollkeeper.
- installs conglomerate_icon.xpm.
.
* Trimmed changelog further.
.
* watch file: Get upstream tarball from Ireland.
.
* first release with a debian NEWS file.
Files:
956313234c81dbfa06d7796dc8294c20 768 editors optional conglomerate_0.7.2-1.dsc
d0dca94d30880fb0e942e8005f554786 752629 editors optional
conglomerate_0.7.2.orig.tar.gz
b67c0cd9455fe4524d101f397e6aa574 9817 editors optional conglomerate_0.7.2-1.diff.gz
7aaf68d4bbc9f744c3fe62f4dbe93647 351496 editors optional conglomerate_0.7.2-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/bw6d2WTeT3CRQaQRAvUPAKCiXlD4JGIi6htemFTq+1dng5MbTQCghT/q
fi0HikprXTv8rvVJEIsMxF4=
=vYHA
-END PGP SIGNATURE-
Accepted:
conglomerate_0.7.2-1.diff.gz
to pool/main/c/conglomerate/conglomerate_0.7.2-1.diff.gz
conglomerate_0.7.2-1.dsc
to pool/main/c/conglomerate/conglomerate_0.7.2-1.dsc
conglomerate_0.7.2-1_i386.deb
to pool/main/c/conglomerate/conglomerate_0.7.2-1_i386.deb
conglomerate_0.7.2.orig.tar.gz
to pool/main/c/conglomerate/conglomerate_0.7.2.orig.tar.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted magicdev 1.1.4-8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 15 Sep 2003 00:17:23 -0500 Source: magicdev Binary: magicdev Architecture: source i386 Version: 1.1.4-8 Distribution: unstable Urgency: low Maintainer: Sean Harshbarger [EMAIL PROTECTED] Changed-By: Sean Harshbarger [EMAIL PROTECTED] Description: magicdev - A GNOME daemon for automatically mounting/playing CDs Changes: magicdev (1.1.4-8) unstable; urgency=low . *The About time release - First upload to the main archive - Thanks goes to Ross Burton *debian/control - Bump CDBS deps to 0.4.4 - Bump debhelper deps to 4.1.54 - Bump standards version to 3.6.1 * New upstream cvs update Files: 4d2fa6432b9f0a639304fd9903aa0007 620 gnome optional magicdev_1.1.4-8.dsc 0cb485e7c0cb3e7f562a745c828019c6 159019 gnome optional magicdev_1.1.4.orig.tar.gz d4bd0c7e4f961704ee7417834d8f5019 4783 gnome optional magicdev_1.1.4-8.diff.gz 217ca79e0496e1190fc971ce1c504b5f 48524 gnome optional magicdev_1.1.4-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ZbhlLQnkR9C0M98RAtoeAKDEl82X/2m9UnXvJJuDDg6OZQfl+gCgrQDT 0fjFPbOAvMXT8eMVp/jr6hQ= =XNxY -END PGP SIGNATURE- Accepted: magicdev_1.1.4-8.diff.gz to pool/main/m/magicdev/magicdev_1.1.4-8.diff.gz magicdev_1.1.4-8.dsc to pool/main/m/magicdev/magicdev_1.1.4-8.dsc magicdev_1.1.4-8_i386.deb to pool/main/m/magicdev/magicdev_1.1.4-8_i386.deb magicdev_1.1.4.orig.tar.gz to pool/main/m/magicdev/magicdev_1.1.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libiconv-ruby 0.4.5-2.1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 17 Sep 2003 03:50:48 +0900 Source: libiconv-ruby Binary: libiconv-ruby1.6 Architecture: source i386 Version: 0.4.5-2.1 Distribution: unstable Urgency: low Maintainer: akira yamada [EMAIL PROTECTED] Changed-By: Fumitoshi UKAI [EMAIL PROTECTED] Description: libiconv-ruby1.6 - A Wrapper class of iconv for the Ruby 1.6.x Changes: libiconv-ruby (0.4.5-2.1) unstable; urgency=low . * NMU - add file pointer in debian/copyright Files: 874a03a5d2dc57ea2d1ae63dc0e5d5bd 619 interpreters optional libiconv-ruby_0.4.5-2.1.dsc 0ca120309559c5880542d9f5c1c930f1 2439 interpreters optional libiconv-ruby_0.4.5-2.1.diff.gz e63f9fc8789045fb4ea54eeadcea7e8d 14134 interpreters optional libiconv-ruby1.6_0.4.5-2.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/Z1vn9D5yZjzIjAkRAkMpAJ0cmvbflsLZACkwez5LDBlsfmoRBgCggRBr uOUZMOOULvDAFHCxVEkf94A= =0dxR -END PGP SIGNATURE- Accepted: libiconv-ruby1.6_0.4.5-2.1_i386.deb to pool/main/libi/libiconv-ruby/libiconv-ruby1.6_0.4.5-2.1_i386.deb libiconv-ruby_0.4.5-2.1.diff.gz to pool/main/libi/libiconv-ruby/libiconv-ruby_0.4.5-2.1.diff.gz libiconv-ruby_0.4.5-2.1.dsc to pool/main/libi/libiconv-ruby/libiconv-ruby_0.4.5-2.1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libhttp-access2-ruby 0.0.J-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 Sep 2003 13:06:13 +0900 Source: libhttp-access2-ruby Binary: libhttp-access2-ruby libhttp-access2-ruby1.8 libhttp-access2-ruby1.6 Architecture: source all Version: 0.0.J-2 Distribution: unstable Urgency: low Maintainer: Fumitoshi UKAI [EMAIL PROTECTED] Changed-By: Fumitoshi UKAI [EMAIL PROTECTED] Description: libhttp-access2-ruby - HTTP accessing library for ruby libhttp-access2-ruby1.6 - HTTP accessing library for ruby libhttp-access2-ruby1.8 - HTTP accessing library for ruby Changes: libhttp-access2-ruby (0.0.J-2) unstable; urgency=low . * copy Ruby's license from ruby source. Files: 66b0e5e19dd353a8693d6fa2cb4a3ac6 669 web optional libhttp-access2-ruby_0.0.J-2.dsc 043bc89ae3fdfa85629a21d2469665ce 10157 web optional libhttp-access2-ruby_0.0.J.orig.tar.gz da57fc8c30f5af15e5bd220b32a311a7 3020 web optional libhttp-access2-ruby_0.0.J-2.diff.gz 71e06b9163addd7cea781a53365936ec 4384 web optional libhttp-access2-ruby_0.0.J-2_all.deb 53760ccaf23c6a84bc9590cca1f2e770 11438 web optional libhttp-access2-ruby1.8_0.0.J-2_all.deb 08d714f74dd02c3e854459d5f5b7323b 11430 web optional libhttp-access2-ruby1.6_0.0.J-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ZoxY9D5yZjzIjAkRAsJhAJ99l1RGm0FZHyRPMpG7AQPxwYPwYQCfecTe 4pORdyoFy1AZMLS5WAv0LLk= =60rt -END PGP SIGNATURE- Accepted: libhttp-access2-ruby1.6_0.0.J-2_all.deb to pool/main/libh/libhttp-access2-ruby/libhttp-access2-ruby1.6_0.0.J-2_all.deb libhttp-access2-ruby1.8_0.0.J-2_all.deb to pool/main/libh/libhttp-access2-ruby/libhttp-access2-ruby1.8_0.0.J-2_all.deb libhttp-access2-ruby_0.0.J-2.diff.gz to pool/main/libh/libhttp-access2-ruby/libhttp-access2-ruby_0.0.J-2.diff.gz libhttp-access2-ruby_0.0.J-2.dsc to pool/main/libh/libhttp-access2-ruby/libhttp-access2-ruby_0.0.J-2.dsc libhttp-access2-ruby_0.0.J-2_all.deb to pool/main/libh/libhttp-access2-ruby/libhttp-access2-ruby_0.0.J-2_all.deb libhttp-access2-ruby_0.0.J.orig.tar.gz to pool/main/libh/libhttp-access2-ruby/libhttp-access2-ruby_0.0.J.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ruby-bsearch 1.5-4 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 Sep 2003 12:58:17 +0900 Source: ruby-bsearch Binary: libbsearch-ruby1.8 libbsearch-ruby Architecture: source all Version: 1.5-4 Distribution: unstable Urgency: low Maintainer: Fumitoshi UKAI [EMAIL PROTECTED] Changed-By: Fumitoshi UKAI [EMAIL PROTECTED] Description: libbsearch-ruby - a binary search library for Ruby libbsearch-ruby1.8 - a binary search library for Ruby Changes: ruby-bsearch (1.5-4) unstable; urgency=low . * copy Ruby's license from ruby source. Files: a734be9294e4944635d682d4de2bad12 623 interpreters optional ruby-bsearch_1.5-4.dsc eb94eb9a33c071b75e41d4f7447f3cba 3195 interpreters optional ruby-bsearch_1.5-4.diff.gz f58ffc6ca569832a0430786a87ed5705 5778 interpreters optional libbsearch-ruby_1.5-4_all.deb fb13e8b36f4f0440766fbf3b1c06e941 3710 interpreters optional libbsearch-ruby1.8_1.5-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/Zop69D5yZjzIjAkRAumaAJ92FEtJg5GeINJmYpLD1vjWz47Y9QCfb5R1 re0Oaj/tpp0F5mn9tBBqxo4= =r4UI -END PGP SIGNATURE- Accepted: libbsearch-ruby1.8_1.5-4_all.deb to pool/main/r/ruby-bsearch/libbsearch-ruby1.8_1.5-4_all.deb libbsearch-ruby_1.5-4_all.deb to pool/main/r/ruby-bsearch/libbsearch-ruby_1.5-4_all.deb ruby-bsearch_1.5-4.diff.gz to pool/main/r/ruby-bsearch/ruby-bsearch_1.5-4.diff.gz ruby-bsearch_1.5-4.dsc to pool/main/r/ruby-bsearch/ruby-bsearch_1.5-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
