Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Sat, Oct 09, 2004 at 05:04:43PM +0200, martin f krafft wrote: > also sprach Julien Louis <[EMAIL PROTECTED]> [2004.10.09.1616 +0200]: > > msmtp is an SMTP client that can be used as an "SMTP plugin" for Mutt and > > probably other MUAs (mail user agents). > > It forwards mails to an SMTP server (for example at a free mail provider) > > which > > does the delivery. > > How does this differ from nullmailer? Why should we have Yet Another > SMTP client in Debian? ssmtp seems to be its competitor, not nullmailer. (ssmtp and msmtp appear to provide /usr/bin/sendmail only, while nullmailer appears to provide port 25 only.) But otherwise it's a good question.. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Bug#275775: RFA: bplay -- Buffered audio file player/recorder
Package: wnpp Severity: normal I request an adopter for the bplay package. The package description is: The bplay package provides a simple command-line utility for playing and recording audio files in raw sample, VOC and WAV formats. . To use this program you need a soundcard of some kind and the appropriate driver configured into your kernel. . When run the program creates two processes which share a memory buffer. It does reading/writing on the disk and the sound device simultaneously, in order to be less liable to `pause' because the disk is too slow or too busy. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (999, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (ignored: LC_ALL set to en_US.UTF-8)
Re: TG3 firmware report...
Hi, Daniel Freedman wrote: > Anyway, just thought I'd see what people think of this, and how the > Debian community wants to proceed. Is there some way to enable > compability with this without downloading the firmware and violating > the DFSG? Since the tg3 driver doesn't work with my BCM5702 interface anyway (#240812), I'm using the bcm5700-source driver from non-free. I guess people running servers and using the advanced features of this driver are doing the same. Feel free to write a personal email to Broadcom asking for the source of their GPLed driver. bye, Roland
Bug#275779: RFA: fpc -- Free Pascal -- Compiler
Package: wnpp Severity: normal I request an adopter for the fpc package. I'd prefer that Peter Vreman <[EMAIL PROTECTED]>, who's the Free Pascal Project's main man on Debian packaging and who has provided me with most of the infrastructure needed to build FPC on Debian, take over this package. Peter, if you're interested, I'd be glad to sponsor you while I'm a developer. The package's description is: The Free Pascal Compiler is a Turbo Pascal 7.0 and Delphi compatible 32-bit Pascal Compiler. It comes with a fully compatible TP 7.0 runtime library. Some extensions are added to the language, like function overloading. Shared libraries can be linked and created. Basic Delphi support is already implemented (classes, exceptions, ansistrings). This package contains the command line compiler. You need at least the RTL package before you can start compiling anything. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (999, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (ignored: LC_ALL set to en_US.UTF-8)
Re: TG3 firmware report...
On Sat, Oct 09, 2004 at 07:10:33PM -0400, Daniel Freedman wrote: > Unfortunately, I believe that my server board contains one of the rare > on-board Broadcom chipsets that is completely unable to function (best > as I can tell), without downloading this firmware, or without at least > disabling the download of it... In other words, it works perfectly > with 2.4.26, but not at all with 2.6.8. It's recognized fine, get's > IP address fine, has kernel modules loaded etc., but simply drops > packets off the stack... > Anyway, just thought I'd see what people think of this, and how the > Debian community wants to proceed. Is there some way to enable > compability with this without downloading the firmware and violating > the DFSG? Surely you can grab the firmware yourself, dump it into the appropriate place in /lib/firmware (the boot message from the tg3 driver tells you) and then it'll work on next boot? This won't break the DFSG as far as I know, 'cause you're not distributing the firmware and Broadcom presumably are happy for you to download it yourself for use. Unless of course the firmware itself is GPL'd, and therefore no one can legally give it out without offering the source as well. I'm not sure this is the right list for this topic, anyway... -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: possible mass bug filing: spamassassin 3
On Sun, Oct 10, 2004 at 04:46:10AM +0200, Sven Mueller wrote: > The only official interfaces SpamAssassin ever provided (to the best of > my knowledge) are: > 1) calling spamassassin directly (as a commandline tool) > 2) calling the spamc client (again, as a commandline tool) > 3) accessing spamd over its defined interface (which is used by spamc) > > [...] > And given the fact that the SA3 API has been published more than 7 month > ago (more like 8: 2004-02-18 was the last date on which the API was > changed in an incompatible way), each tool had more than enough time to > adjust to this. I don't follow your logic here. First, you say that using SA via the Perl modules are not supported; then, you say that the SA Perl APIs were frozen and officially published seven months ago? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: possible mass bug filing: spamassassin 3
* Sven Mueller | Tollef Fog Heen [u] wrote on 07/10/2004 09:52: | > * Duncan Findlay | Umm... I'd like to see that | > 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd | > 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd | > | Furthermore, you should use the -m option to limit the number of | > | children to something sane, like 5 or so. | > This is per child, as I wrote. | | Do you have any additional rulesets like those SARE rules installed? No. | If so, how many/what total size? I have ~10 custom body matching rules. If that makes SA explode, something is seriously broken. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: possible mass bug filing: spamassassin 3
On Sun, Oct 10, 2004 at 12:23:26PM +0200, Steinar H. Gunderson wrote: > I don't follow your logic here. First, you say that using SA via the Perl > modules are not supported; then, you say that the SA Perl APIs were frozen > and officially published seven months ago? Oh, and checking on spamassassin.apache.org: "Flexible: SpamAssassin encapsulates its logic in a well-designed, abstract API so it can be integrated anywhere in the email stream. The Mail::SpamAssassin classes can be used on a wide variety of email systems including procmail, sendmail, Postfix, qmail, and many others." Or, http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin.html: "Mail::SpamAssassin is a module to identify spam using several methods [...]. If you wish to use a command-line filter tool, try the spamassassin or the spamd/spamc tools provided." This does not look like an internal unsupported interface to me. /* Steinar */ -- Homepage: http://www.sesse.net/
Re: possible mass bug filing: spamassassin 3
* Sven Mueller
| Tollef Fog Heen [u] wrote on 07/10/2004 10:00:
|
| > * Sven Mueller | Well, perl modules don't have an SO name.
| > : [EMAIL PROTECTED] /usr/lib > apt-cache show libvideo-capture-v4l-perl|
| > grep ^Depends
| > Depends: perlapi-5.8.3, perl (>= 5.8.3-2), libc6 (>= 2.3.2.ds1-4)
| > Seems like perl provides an API that the module depends on, no?
|
| perlapi seems to be some sort of a pseudo package.
It's a virtual package.
| But anyway: What does a package version have to do with SO names?
(I assume you meant package name, if not please explain a bit further
what you mean)
For packages including APIs, the package name should include the API
version number. For shared objects (libraries), that's the soname.
Perl modules don't really have a similar concept, but that's just
tradition and there's no reason why they couldn't.
| > | And actually, the "library" part of SA isn't intended to be the most
| > | often used one.
| > If it is provided, it must work.
|
| So if someone provides a huge program which consists of various
| specially crafted dynamic libraries (whose APIs are documented but not
| really intended for use outside of this specific program), these
| libraries may not change in a way which changes those APIs?
Yes, or rather it must bump the soname when changing those APIs.
Also, if they're not intended for general use, they shouldn't be put
in /usr/share/perl5 but in a private module directory. (Similarly,
not /usr/lib for private libraries, but a /usr/lib/$packagename/ or
something like that.)
| Sure seems strange to me.
| The only official interfaces SpamAssassin ever provided (to the best
| of my knowledge) are:
| 1) calling spamassassin directly (as a commandline tool)
| 2) calling the spamc client (again, as a commandline tool)
| 3) accessing spamd over its defined interface (which is used by spamc)
>From the front page of spamassassin.org:
: Flexible: SpamAssassin encapsulates its logic in a well-designed,
: abstract API so it can be integrated anywhere in the email
: stream. The Mail::SpamAssassin classes can be used on a wide variety
: of email systems including procmail, sendmail, Postfix, qmail, and
: many others.
| > If it is changed in an incompatible fashion, it must bump soname.
| > Or make SA into a library proper, with
| > libmail-spamassassin-perl being the module part and spamassassin
| > depending on that.
|
| Well, in that case, libmail-spamassassin-perl would be the size of the
| current spamassassin package, and the new spamassassin package (which
| depends on the libmail-spamassassin-perl package) is about 2k in size,
| description and packaging overhead included. Sorry, that doesn't make
| much sense.
: [EMAIL PROTECTED] ~ > for f in $(dpkg -L spamassassin | grep -v perl \
|grep -v man3 ); do [ -f $f ] && echo $f; done | xargs du -shc |
tail -1
1,1Mtotalt
SA currently ships nearly 600k of rules.
| > You'd still have to bump soname, but only for the library part.
|
| Go learn perl, than come back.
(Apology about writing mail after discussion with boss accepted. :)
| Perl Modules might have version numbers, but they certainly don't
| have SO names. BTW: Give a descend definition of what you refer to
| as soname, and I might apologize and say that you are right.
soname is here used a bit loosely meaning «ABI/API version»; this is
technically not correct (as you point out), but it's shorter than
writing «ABI/API version» all over the place.
(And, given that perl modules can be normal shared objects, they
certainly _can_ have sonames proper, but I agree that's not the norm.)
| > This is _not_ hard to get right, and there is really no exuse not get
| > it right.
|
| The only way to get it right (in your sense of the word) would be to
| rename the Perl Mail::SpamAssassin module (along with its sub-modules)
| to Mail::SpamAssassin3. However, this would make some programs break
| which are otherwise able to cope with v3 Mail:SpamAssasin quite well.
They can try to import Mail::SpamAssassin3 first, if that fails, try
Mail::SpamAssassin. A nice thing with this is you actually know what
API you use.
| spampd for example has a total of 10 lines which differentiate between
| versions v being < 2.7, 2.7 <= v < 3.0 and v >= 3.0 _and_ do what's
| needed to work with either of the three possible categories of
| SpamAssassin versions. If SpamAssasin v3 would be renamed to
| Mail::SpamAssassin3, the changes would be more like 120 lines.
BEGIN {
eval {
require Mail::SpamAssassin3;
import Mail::SpamAssassin3 qw(foo bar baz);
}
if ($@) {
require Mail::SpamAssassin;
import Mail::SpamAssassin qw(foo bar baz);
}
}
Doesn't look like 120 lines to me.
| And given the fact that the SA3 API has been published more than 7
| month ago (more like 8: 2004-02-18 was the last date on which the API
| was changed in an incompatible way), each tool had more than enough
| time to adjust to this.
Re: Smooth Debian Installer Experience
On Saturday 09 October 2004 15:56, Colin Watson wrote: > On Sat, Oct 09, 2004 at 12:48:27AM +0200, Tilo Schwarz wrote: > > Just one remark: When I was asked to enter a package server I would > > have liked to enter my local package repository (with all the base > > stuff in it), but either I couldn't or I didn't see it. But, never > > mind ... > > Scroll up to the top of the country list and you'll see "enter > information manually". Ahh, thank you for the hint. In my case, I simply didn't expect to find a "enter information manually"-possibility in the country list, but in the following ftp-server list. I actually scrolled a few times up and down the ftp-servers looking for a way to enter the server manually and I couldn't make the step back to the country list mentally ;-) Regards, Tilo
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Il dom, 2004-10-10 alle 01:32, Henning Makholm ha scritto: > > I think that msmtp simply will take the place of sendmail binary called > > by mutt. > > If it provides /usr/sbin/sendmail, then by definition it is a > mail-transport-agent and should, if packaged, declare itself as such. No. If you read the first things on msmtp home page (as I did it, before writing here), you'll read that simply you must use its binary (msmtp) from mutt and not "sendmail". > If it provides the same functionality as /usr/sbin/sendmail but with a > different command name, then somebody needs to explain why. I'm not msmtp fan or user, but I lost two minutes to read the home page trying to understand the differences. msmtp is simply a way to delivery mail to a remote smtp server. For example you cannot have it listening on 25 port, so I cannot see it as a sendmail alternative, just like nullmailer or ssmtp or other ones... bye Christian
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Il sab, 2004-10-09 alle 17:48, martin f krafft ha scritto: > > I think it's not a right comparison, nullmail is an MTA. and > > AFAIK, msmtp is not an MTA: > > it transports mail to the next relay, right? > nullmailer is a "simple relay-only mail transport agent." > > what's the difference? Deep difference. Our mail-transport-agents are able to behave as daemon, listening on 25 port. msmtp doesn't, and it's the same for nail. Do you think that nail could be an MTA? Do you think that any evolution of mail(1) could be seen as an MTA, only because is able to "speak" smtp? :o > oh well, msmtp has TLS and SASL and IPv6, so I guess it is more > featureful than nullmailer... They are two different projects with different targets. > > I think that msmtp simply will take the place of sendmail binary > > called by mutt. > > oh, and calling it a plugin make is sounds so much better. are these > guys marketing specialists or software hackers? > > did you know about lpr? it's the mutt print plugin which may also > work with other programmes. Do you know about a correct way to have a conversation with people? I don't like your attitude, I have simply exposed my idea about that program, reading its features. That's all. And I don't think that the real point of discussion could be the use of a single word. I thought we were trying to "understand" msmtp. I don't see any problems to change one word in long description of a debian package. bye Christian
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Christian Surchi <[EMAIL PROTECTED]> - Sun, Oct 10, 2004: > Deep difference. Our mail-transport-agents are able to behave as daemon, > listening on 25 port. msmtp doesn't, and it's the same for nail. Do you > think that nail could be an MTA? Do you think that any evolution of > mail(1) could be seen as an MTA, only because is able to "speak" smtp? > :o I think -- but I may be wrong -- that the mail-transport-agent virtual package was created to help programs using /usr/sbin/sendmail to have a depends, and programs providing /usr/sbin/sendmail to have a conflicts/replaces. If msmtp provides a compatible /usr/sbin/sendmail, it would be nice that it would also provide mail-transport-agent. What I don't think is that programs are relying on something listening on :25 when they depend on mail-transport-agent. I don't think this is the case because exim and postfix both offer a configuration where nothing listens on :25. Is there a text describing the contract of packages providing mail-transport-agent? Regards, -- Loïc Minier <[EMAIL PROTECTED]>
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
also sprach Christian Surchi <[EMAIL PROTECTED]> [2004.10.10.1321 +0200]: > Do you know about a correct way to have a conversation with > people? I don't like your attitude, I have simply exposed my idea > about that program, reading its features. That's all. I am sorry to have offended you, or anyone else. I should not have written back that day because I was occupied with some personal issues and let some steam off by being sarcastic. It was nothing personal, and I wish I could undo it. As I explained in my previous mail, I was first put off when I read about msmtp. You all have convinced me that it is in fact not Just Another, but rather a worthy addition to the Debian archive. I am sorry it took me so long, I should have checked first before writing back to the list. Thus I hope you accept my apologies. I would suggest not naming it an "smtp plugin for mutt" though because it works equally well with every other product that uses /usr/sbin/sendmail. If it is of any use, I would like to offer sponsorship for the package, in the hope to make peace over the issue. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Sun, Oct 10, 2004 at 01:21:44PM +0200, Christian Surchi wrote: > Il sab, 2004-10-09 alle 17:48, martin f krafft ha scritto: > > > I think it's not a right comparison, nullmail is an MTA. and > > > AFAIK, msmtp is not an MTA: > > > > it transports mail to the next relay, right? > > nullmailer is a "simple relay-only mail transport agent." > > > > what's the difference? > > Deep difference. Our mail-transport-agents are able to behave as daemon, > listening on 25 port. This is not true, since not required by policy. Policy says: 11.6. Mail transport, delivery and user agents | (...) the interface to send a mail message is `/usr/sbin/sendmail' (as | per the FHS). /usr/sbin/sendmail is guaranteed to work if you have mail-transport-agent, but port 25 to localhost isn't. So, any package providing /usr/sbin/sendmail, and, when correctly configured, gets mail on that interface off to the recipient, _is_ a mail-transport-agent, MTA. ssmtp is one, nullmailer is also one. Note that a MTA isn't required to know ANYTHING about smtp. Suppose a package provides an sendmail that is an alias for 'ssh mailhub /usr/sbin/sendmail', then that package is a MTA. > msmtp doesn't, and it's the same for nail. Do you think that nail > could be an MTA? Do you think that any evolution of mail(1) could be > seen as an MTA, only because is able to "speak" smtp? > :o mail currently is a MUA, it will communicate with sendmail, i.e., require a MTA to get its mail off. > > > I think that msmtp simply will take the place of sendmail binary > > > called by mutt. Then msmtp is just like any MTA, but accepts mail on a different binary (the msmtp binary in stead of sendmail), so it won't be used by any program unless specificially configured. IMHO, it'd be better if mstmp were packaged as a real MTA, providing /usr/sbin/sendmail, so that ALL programs (and not only mutt) can take advantage of it, and don't need special configuration. Then msmtp is an alternative to ssmtp and nullmailer, with a different featureset. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
also sprach Hamish Moffatt <[EMAIL PROTECTED]> [2004.10.10.0939 +0200]: > ssmtp seems to be its competitor, not nullmailer. (ssmtp and msmtp > appear to provide /usr/bin/sendmail only, while nullmailer appears to > provide port 25 only.) > > But otherwise it's a good question.. Yes, which I would like to answer myself: I am now in favour of msmtp simply because it provides for cryptography. In the long run, I would rather like to see ssmtp and nullmailer removed in favour of msmtp, because in the long run, unencrypted SMTP should not be supported. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Bug#275806: ITP: acx100-kernel-src -- kernel module for TI acx100 based wireless lan cards
Package: wnpp Severity: wishlist * Package name: acx100-kernel-src Version : 0.2.0pre8 Upstream Author : [EMAIL PROTECTED] * URL : http://acx100.sourceforge.net/ * License : MPLv1.1/GPLv2 Description : kernel module for TI acx100 based wireless lan cards This ia a kernel driver for Texas Instruments' ACX100/ACX111 wireless network chips. The driver needs firmware to function, so this package is going into crontrib. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8.1 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Sat, Oct 09, 2004 at 07:05:45PM +0300, George Danchev said > > oh well, msmtp has TLS and SASL and IPv6, so I guess it is more > > featureful than nullmailer... > > and much more ... also has msmtpqueue which is a pair of very simple shell > scripts that allows you to "queue" mails and send them all at a later time > (useful for dialup connections: write your mails offline and send them when > you are online). Hah, so unlike things like exim and postfix... -rob -- Words of the day: VX nerve gas Firewalls Audiotel Cocaine Rule Psix Hacker
Ihre Mail an alexander.rasch@sparkasse-ffb.de
Sehr geehrte Kundin, sehr geehrter Kunde, Ihre e-mail wird an den gewuenschten Empfaenger weitergeleitet. Haben Sie vielen Dank, wir freuen uns, dass Sie diesen schnellen und unkomplizierten Weg zu uns gewaehlt haben. Gerne sind wir fuer Sie da und stellen Ihnen all die Informationen zur Verfuegung, die Sie wuenschen. Geschaefte über e-mail sind leider nach wie vor noch mit rechtlichen und datenschutztechnischen Risiken verbunden. Deshalb bitten wir um Ihr Verstaendnis, dass wir Auftraege auf diesem Wege nur annehmen koennen, wenn sie unverzueglich nochmals schriftlich oder telefonisch von Ihnen bestaetigt werden. Mit freundlichen Gruessen Ihre Sparkasse Fuerstenfeldbruck
Re: Updating scanners and filters in Debian stable (3.1)
On Fri, 8 Oct 2004 10:59:39 +0100, paddy <[EMAIL PROTECTED]> wrote: >On Wed, Sep 15, 2004 at 09:37:57AM +0200, Marc Haber wrote: >> It will also happily write to /usr which is IMO a no-no for user >> binaries. > >Where should it write to ? > >Would /var/lib or /usr/local be right ? /usr/local is the domain of the local admin. /var/lib or /var/cache might be the right place. But it should be configurable, since some people mount /var noexec which might break the setup. The clean way would be to build .deb files from the downloaded plugins, and to install them via the package management. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Bug#275807: ITP: libperlio-eol-perl -- PerlIO layer for normalizing line endings
Package: wnpp Severity: wishlist * Package name: libperlio-eol-perl Version : 0.05 Upstream Author : Autrijus Tang <[EMAIL PROTECTED]> * URL : CPAN * License : GPL/Artistic Description : PerlIO layer for normalizing line endings This layer normalizes any of CR, LF, CRLF and Native into the designated line ending. It works for both input and output handles. (In case you wonder: This is a dependency of recent svk versions.)
Re: Updating scanners and filters in Debian stable (3.1)
On Sun, 3 Oct 2004 12:36:48 +0200, Francesco Paolo Lovergine <[EMAIL PROTECTED]> wrote: >Not always. In the past many backports have been built including perfectly >avoidable new dependencies. The volatile archive should have policy and >deb tools frozen. So no new debconf, no new ucf and so on. In many cases, backporting other tools and libs makes backporting much easier since a lot of packages use debhelper's latest features. And debhelper has a history of using perl features that are not present in stable's perl. And no, I won't do a perl backport for new debhelper. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
also sprach Rob Weir <[EMAIL PROTECTED]> [2004.10.10.1442 +0200]: > > and much more ... also has msmtpqueue which is a pair of very simple shell > > scripts that allows you to "queue" mails and send them all at a later time > > (useful for dialup connections: write your mails offline and send them when > > you are online). > > Hah, so unlike things like exim and postfix... It does have a merit over exim and postfix, mainly that it's designed for offline use and does not have to be configured specifically. Also, it's not as complex as exim and postfix (the debconf questions are going to be a lot easier to grok), more lightweight, and still has a nice featureset. /me wonders why he's now advocating... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Thank you for contacting Technical support/Customer service
Hello, thank you for contacting Technical support/Customer service. Please click on the link below to go to our online support site. http://support.vugames.com Do not respond to this message as we will not see it. Vivendi Universal Games- http://www.vugames.com: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Vivendi Universal Games which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.
Processed: Re: Bug#275388: mounting at boot time under grub
Processing commands for [EMAIL PROTECTED]: > reassign 275388 general Bug#275388: mounting at boot time under grub Bug reassigned from package `devfsd' to `general'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: Common set of debconf templates
On Fri, 8 Oct 2004 06:59:50 +0200, Christian Perrier <[EMAIL PROTECTED]> wrote: >Could *please* maintainers of packages interacting with RDBMS >establish a set of *common* debconf templates for prompting users ? > >-Database user >-Password for this user >-Database administrator username >-Database administrator password >-Database name >-Should the database be purge on package purge? Do we have infrastructure to handle different answers for the same question? Maybe I'd like to have a different dbadmin password on my postgresql database than on mysql? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Bug#275806: ITP: acx100-kernel-src -- kernel module for TI acx100 based wireless lan cards
retitle 275192 ITP: acx100-source -- ACX100/ACX111 wireless network drivers source thanks Hi Aurelien! You wrote: > Bas Zoetekouw a écrit : > >Package: wnpp > >Severity: wishlist > > > >* Package name: acx100-kernel-src > > Version : 0.2.0pre8 > > Upstream Author : [EMAIL PROTECTED] > >* URL : http://acx100.sourceforge.net/ > >* License : MPLv1.1/GPLv2 > > Description : kernel module for TI acx100 based wireless lan cards > > I have already packaged that software. Please see bug#275192. Currently > the package is stucked in the new queue. Ah, very well. It isn't listed on the wnpp page though, because the subject is broken. Fixing it. (and thanks for packaging this). -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Bug#275812: ITP: libio-digest-perl -- Calculate digests while reading or writing
Package: wnpp Severity: wishlist * Package name: libio-digest-perl Version : 0.10 Upstream Author : Chia-liang Kao (éåè) * URL : CPAN * License : GPL/Artistic Description : Calculate digests while reading or writing This module allows you to calculate digests while reading or writing file handles. Otherwise, you would have to reread the same file again after writing it, just to compute the digests. (Another svk depedency.)
python-apt: how to get ShortDesc and LongDesc
Hi, would someone write me a sample code on how to get the ShortDesc and LongDesc records from the PkgRecords class? I think it should start with something like: cache = apt_pkg.GetCache() records = apt_pkg.GetPkgRecords(cache) package = cache['my_pkg'] but I can't figure out how to go on.. cheers, free
Re: Updating scanners and filters in Debian stable (3.1)
On Sun, Oct 10, 2004 at 02:53:58PM +0200, Marc Haber wrote: > On Sun, 3 Oct 2004 12:36:48 +0200, Francesco Paolo Lovergine > <[EMAIL PROTECTED]> wrote: > >Not always. In the past many backports have been built including perfectly > >avoidable new dependencies. The volatile archive should have policy and > >deb tools frozen. So no new debconf, no new ucf and so on. > > In many cases, backporting other tools and libs makes backporting much > easier since a lot of packages use debhelper's latest features. Right, indeed volatile should not do things easy for maintainers, but do the right thing. Too easy backporting the whole dependency set to have something up with minimal work. > And > debhelper has a history of using perl features that are not present in > stable's perl. And no, I won't do a perl backport for new debhelper. > Yep, that's a good reason to not backporting infinity and behind. -- Francesco P. Lovergine
Bug#275816: ITP: libfile-type-perl -- determine file type using magic
Package: wnpp Severity: wishlist * Package name: libfile-type-perl Version : 0.22 Upstream Author : Paul Mison <[EMAIL PROTECTED]> * URL : CPAN * License : GPL/Artistic Description : determine file type using magic numbers File::Type uses magic numbers (typically at the start of a file) to determine the MIME type of that file. File::Type can use either a filename, or file contents, to determine the type of a file. (Another svk dependency.)
Re: possible mass bug filing: spamassassin 3
On Sun, Oct 10, 2004 at 10:43:14AM +0900, Clemens Schwaighofer wrote: > > Furthermore, we should all know that Anti-Spam, Anti-Virus is a CPU & > memory hog. It needs tons of memory and fastest cpu ... always. > I'm using now bogofilter and razor, without CPU and memory problems at all. So your always should probably be parsed sometimes. -- Francesco P. Lovergine
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Sun, Oct 10, 2004 at 02:05:06PM +0200, martin f krafft wrote: > also sprach Hamish Moffatt <[EMAIL PROTECTED]> [2004.10.10.0939 +0200]: > > ssmtp seems to be its competitor, not nullmailer. (ssmtp and msmtp > > appear to provide /usr/bin/sendmail only, while nullmailer appears to > > provide port 25 only.) > > > > But otherwise it's a good question.. > > Yes, which I would like to answer myself: I am now in favour of > msmtp simply because it provides for cryptography. In the long run, > I would rather like to see ssmtp and nullmailer removed in favour of > msmtp, because in the long run, unencrypted SMTP should not be > supported. ssmtp seems to support SSL/TLS connections also. The package depends on libssl and a quick glance at the source shows that support is there. Looks like my description of nullmailer above was wrong. I read its description "relay-only" to mean that it only does relaying, ie it's an SMTP proxy of some kind. However it seems to be yet another /usr/sbin/sendmail. However it sounds like msmtp doesn't provide /usr/sbin/sendmail, so it cannot provide: mail-transport-agent, nor replace ssmtp etc. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
also sprach Hamish Moffatt <[EMAIL PROTECTED]> [2004.10.10.1601 +0200]: > ssmtp seems to support SSL/TLS connections also. The package depends on > libssl and a quick glance at the source shows that support is there. What ssmtp are you talking about? cirrus:~> dpkg -p ssmtp | grep Depends Depends: libc6 (>= 2.2.4-4), debconf Oh darn, I used dpkg -p and not apt-cache show and thus used the stable one. Well, does it support SASL? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: about volatile.d.o/n
This one time, at band camp, Kevin Mark said:
> On Sat, Oct 09, 2004 at 10:43:05AM -0400, Stephen Gran wrote:
> > This one time, at band camp, Kevin Mark said:
> > > On Sat, Oct 09, 2004 at 11:00:51AM +0200, Francesco Paolo Lovergine wrote:
> > > > On Sat, Oct 09, 2004 at 03:01:11AM -0400, Kevin Mark wrote:
> > > > > Packages like virus checkers seem to be
> > > > > composed of 2 parts: the app program and the data where the data in
> > > > > this case are virus sigs and the app is say clamav. And the 'volitile'
> > > > > part is the virus sigs whereas the app (once it hits stable) shouldnt
> > > > > change unless it warrents a 'security' update. So, volitile should be
> > > > > for the data/virus sigs that need updating when new bugs hit the 'net.
> > > >
> > > > No, often such kind of programs need engine update. That's true for
> > > > both AV and antispam programs as well.
> > > >
> > > Hi Francesco,
> > > so:
> > > the program = engine part + (some un-named part) ???
> > > and the engine part and the data part are volitile
> >
> > In the case of clamav, most of the work of scanning is handled by
> > library functions, and these functions are called by the frontend
> > programs like clamscan, clamdscan, and the milter.
> Hi Stephen,
>
> so,
> email
> |
>\/
> {lib}clamav->clamav{frontend}<-clamav-{data}
> |
> \/
>mbox
This might be a more helpful diagram:
email
|
MTA<--->clam frontend
||
| library<-->data set (sigs)
mbox
Clam doesn't scan email in isolation - it's called by an MTA or a glue
application like amavis. The fact that the underlying library functions
or data sets have changed internally should not matter to the caller, so
long as the front ends have the same API. There is one application I
see outside of the clamav suite that links against libclamav1 directly,
and that will take careful coordination - all the others rely on the API
provided by frontends and will not break so long as the API remains
constant.
> would it be good to backport new dataformat to 'stable' dataformat or
> risk having to fix {lib} and {frontend}s? then they would be 'unstable'
> and need QA?
Not really - clam is dropping the ability to read unsigned datasets, and
while it would be technically possible to recreate signed signature sets
in an older format, the delay introduced by doing so would obviate the
advantage of having automatic updates. Also, clam currently relies on a
worldwide system of mirrors, each of which currently does about 10G of
traffic/month just for the clam updates. Where do you propose we host the
single mirror that will update all of the sarge installs that can't use
the newer data format? I don't have the bandwidth and I don't think
it's practical for p.d.o.
> what is the diff between
> stable.update,security.update,volitile.update?
> enquiring minds what to know? hope this is not too OT!
> -Kevin
My understanding is that stable-proposed-updates is for packages that
maintainers would like to see in the next point release, security is for
the security team and contains fixes for packages mentioned in DSA's,
and volatile is intended for packages that need to update more
frequently than point releases allow, but are not directly security
problems, and so are not the arena of the security team.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgpf2NIxOcJC4.pgp
Description: PGP signature
Re: about volatile.d.o/n
* Andreas Barth: > - volatile is not "just another place" for backports, but should only > contain changes to stable programs that are necessary to keep them > functional; Can volatile receive critical updates which are usually not applied to stable because backports are not available for some reason?
Re: TG3 firmware report...
hi * Roland Stigge <[EMAIL PROTECTED]> [2004-10-10 15:46]: > Daniel Freedman wrote: > > Anyway, just thought I'd see what people think of this, and how the > > Debian community wants to proceed. Is there some way to enable > > compability with this without downloading the firmware and violating > > the DFSG? > > Since the tg3 driver doesn't work with my BCM5702 interface anyway > (#240812), I'm using the bcm5700-source driver from non-free. I guess > people running servers and using the advanced features of this driver > are doing the same. > > Feel free to write a personal email to Broadcom asking for the source of > their GPLed driver. the source is included in the kernel sources :) regards nico -- Nico Golde - [EMAIL PROTECTED] [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ngolde.de GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF Is there life after /sbin/halt -p? signature.asc Description: Digital signature
Re: installing TCP programs when RPC programs are running
* Loïc Minier: > Florian Weimer <[EMAIL PROTECTED]> - Thu, Oct 07, 2004: > >> I think the best option would be to allow the system administrator to >> statically allocate the ports used by RPC programs. This would help >> packet filters, too. > > While I see the benefit of your suggestion, for packet filters, I don't > see how that would help average people experiencing the problem? Would > you require the admin to configure each port for each RPC service as it > is installed? Maybe there could be defaults for the most common ones? I'm not sure. The libc routines could also read /etc/services and skip ports listed there. There should still be enough remaining ports. > (BTW, I used to call rpcinfo -p to setup my iptables rules dynamically, > but that does not cover service restarts very well, something like a > rpc_conntrack would be better, and it seemed to exist too) One school of though in network security is that you don't have intelligent firewalls, based on the assumption that parsing complex protocols on firewall components is likely to make the firewall vulnerable to the same attacks as the application to be protected by the firewall. Static port assignments would be quite beneficial.
Re: pmount vs updfstab
Hi! Michael Banck [2004-10-09 12:25 +0200]: > But in the end, it depends on who does the work, so if Martin Pitt > (pmount author) should volunteer to integrate this into Debian, that > would be great I guess. It'll be my pleasure! :-) Of course I would prefer it if Debian and Ubuntu used the same solution. It has proven to work in Ubuntu and it's considerably more robust and safe than messing up the fstab IMHO. But I will not put that into Sarge because it is too late for these changes, and I don't see a point in having pmount without anything using it. I will file an ITP as soon as Sarge has released and discuss the further approach with Sjoerd. Have a nice Sunday everybody! Martin -- Martin Pitt http://www.piware.de Ubuntu Developerhttp://www.ubuntulinux.org Debian GNU/Linux Developer http://www.debian.org signature.asc Description: Digital signature
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Scripsit Christian Surchi <[EMAIL PROTECTED]> > I'm not msmtp fan or user, but I lost two minutes to read the home page > trying to understand the differences. msmtp is simply a way to delivery > mail to a remote smtp server. For example you cannot have it listening > on 25 port, so I cannot see it as a sendmail alternative, just like > nullmailer or ssmtp or other ones... Nullmailer is simply a way to deliver mail to a remote SMTP server. For example you cannot have it listening on port 25. Nevertheless it quite correctly provides mail-transport-agent, and so on. -- Henning Makholm"What a hideous colour khaki is."
Re: Common set of debconf templates
On Sun, Oct 10, 2004 at 03:18:52PM +0200, Marc Haber wrote: > On Fri, 8 Oct 2004 06:59:50 +0200, Christian Perrier > <[EMAIL PROTECTED]> wrote: > >Could *please* maintainers of packages interacting with RDBMS > >establish a set of *common* debconf templates for prompting users ? > > > >-Database user > >-Password for this user > >-Database administrator username > >-Database administrator password > >-Database name > >-Should the database be purge on package purge? > > Do we have infrastructure to handle different answers for the same > question? Maybe I'd like to have a different dbadmin password on my > postgresql database than on mysql? or more likely, a different username/password for each different *sql program. i think debconf could be tricked into using one template for prompting the user and feeding the answer into another one. however, as time goes on i'm thinking that this could be better done with a debhelper like application, which would be better for all the postinst/etc stuff anyway. sean -- signature.asc Description: Digital signature
Re: python-apt: how to get ShortDesc and LongDesc
Free Ekanayaka wrote: would someone write me a sample code on how to get the ShortDesc and LongDesc records from the PkgRecords class? I think it should start with something like: cache = apt_pkg.GetCache() records = apt_pkg.GetPkgRecords(cache) package = cache['my_pkg'] Since there are no API-docs for python-apt, there's only one option: use the source :) 8<== import apt_pkg PACKAGE_NAME = "my_pkg" IGNORE_DPKG_STATUS = 1 apt_pkg.init() cache = apt_pkg.GetCache() records = apt_pkg.GetPkgRecords(cache) package = cache[PACKAGE_NAME] for pack_vers in package.VersionList: for pack_file, index in pack_vers.FileList: records.Lookup((pack_file,index)) # ignore Debian dpkg status file lookups if pack_file.IndexType != 'Debian Package Index' and \ IGNORE_DPKG_STATUS == 1: continue print "ORIGIN:", pack_file.Site print "VERSION:", pack_vers.VerStr print "SHORT DESC:", records.ShortDesc print "LONG DESC:", records.LongDesc print 8<== HTH, Igor
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
On Sun, Oct 10, 2004 at 01:57:14PM +0200, martin f krafft wrote: > I would suggest not naming it an "smtp plugin for mutt" though > because it works equally well with every other product that uses > /usr/sbin/sendmail. I agree with the "smtp plugin for mutt" removal, I will adapt the description this week and send it next weekend, because I haven't internet during week :/ > If it is of any use, I would like to offer sponsorship for the > package, in the hope to make peace over the issue. Thank you :) -- GUEULE DE BOIS M : J'ai passé le réveillon le plus minable de ma vie... J'étais bourré, je me suis fait sucer par un hamster... P : Tu vas le revoir ? M : Il est mort d'une indigestion...
proposal: 'xterm' alternatives entry
As a happy use of rxvt-unicode-ml (thanks Zomb!), I am very annoyed at times by softwares that have 'xterm' hardcoded. Obviously, I report these as bugs to have it changed to x-terminal-emulator, but then again, I consider 'xterm' to be somewhat of a generic name by now that I think it should be put under control of the alternatives system. The procedure would be to upload a new 'xterm' package which moves /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm as alternatives symlink in addition to x-terminal-emulator. Then, progressively, the other x-terminal-emulator providers can start to add xterm to their postinst scripts. What do you think of this proposal. Are there any string points *against* it? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: First spam
On 09-Oct-04, 20:06 (CDT), Clemens Schwaighofer <[EMAIL PROTECTED]> wrote: > On 10/10/2004 07:38 AM, paddy wrote: > > I'm actually surprised it takes them that long. > > debian-devel must be way down the target list. > > probably geeks don't buy viagra, home loans, online medicine, etc :) People (aka scum) who harvest addresses only care about a numbers, not "target markets". Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Common set of debconf templates
Marc Haber wrote: > Do we have infrastructure to handle different answers for the same > question? Maybe I'd like to have a different dbadmin password on my > postgresql database than on mysql? This discussion is about having a common set of chunks of text available somewhere for use in the debconf templates of individual packages, not about having a common set of debconf database entries.
Re: proposal: 'xterm' alternatives entry
martin f krafft wrote: > What do you think of this proposal. Are there any string points > *against* it? I have written scripts that explicitly call xterm because other terminal emulator programs under X (which I had preferred otherwise) couldn't handle certain programs. So in those situations it was not a generic name, but a specific program with specific capabilities.
Re: proposal: 'xterm' alternatives entry
also sprach Peter Eisentraut <[EMAIL PROTECTED]> [2004.10.10.1934 +0200]: > I have written scripts that explicitly call xterm because other > terminal emulator programs under X (which I had preferred > otherwise) couldn't handle certain programs. So in those > situations it was not a generic name, but a specific program with > specific capabilities. Could you give us an example, please? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Company launch with Linux system
This is cory yearwood from Exsis. Please can you remove the e-mail from your website..
Re: proposal: 'xterm' alternatives entry
On Sun, Oct 10, 2004 at 06:43:09PM +0200, martin f krafft wrote: > The procedure would be to upload a new 'xterm' package which moves > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm > as alternatives symlink in addition to x-terminal-emulator. Then, > progressively, the other x-terminal-emulator providers can start to > add xterm to their postinst scripts. Wouldn't it be better to file bugs against the packages that don't use x-terminal-emulator? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ signature.asc Description: Digital signature
Re: proposal: 'xterm' alternatives entry
also sprach Frank Lichtenheld <[EMAIL PROTECTED]> [2004.10.10.2005 +0200]: > Wouldn't it be better to file bugs against the packages that don't > use x-terminal-emulator? What if those bugs get ignored? see: #275527 -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: proposal: 'xterm' alternatives entry
#include * martin f krafft [Sun, Oct 10 2004, 06:43:09PM]: > but then again, I consider 'xterm' to be somewhat of a generic name > by now that I think it should be put under control of the > alternatives system. > > The procedure would be to upload a new 'xterm' package which moves > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm It is not that easy. xterm obviosly has a bunch of settings that are used often but are not presented in many x-terminal-emulator providers. AFAICS the only common options are -T, -n and -e ..., you cannot rely on anything else. For example, I just looked at the list from apt-cache show rdepends xterm - and the first candidate (ddd) used the -fn option which is not provided by mlterm. Though luck. In theory, every maintainer should look trough the package that wants to use xterm and if there are no special options used anywhere, (s)he could replace xterm with x-terminal-emulator everywhere. I did that in icewm, no trouble so far. Regards, Eduard. -- geht nur in IE unter win autsch ich glaub das war ein eigentor signature.asc Description: Digital signature
Re: proposal: 'xterm' alternatives entry
On Sun, Oct 10, 2004 at 08:11:42PM +0200, martin f krafft wrote: > also sprach Frank Lichtenheld <[EMAIL PROTECTED]> [2004.10.10.2005 +0200]: > > Wouldn't it be better to file bugs against the packages that don't > > use x-terminal-emulator? > > What if those bugs get ignored? see: #275527 Hmm, I don't know anything about how uml works but the answers seems to imply that fixing it in user-mode-linux suffices... But that's something you have to discuss with mdz and not with me. Anyway, fixing a problem around maintainers may be necessary sometimes but should definetly be avoided. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ signature.asc Description: Digital signature
Re: proposal: 'xterm' alternatives entry
also sprach Frank Lichtenheld <[EMAIL PROTECTED]> [2004.10.10.2027 +0200]: > Hmm, I don't know anything about how uml works but the answers > seems to imply that fixing it in user-mode-linux suffices... But > that's something you have to discuss with mdz and not with me. Right, and I don't want to beat on this issue. user-mode-linux does fix it, but Manoj's kernel-package can also create UML kernels, which then call xterm. Thus, I would have thought this is best fixed in kernel-patch-uml. I consider s/xterm/x-terminal-emulator/ a necessary step of debianisation, wherever possible. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: proposal: 'xterm' alternatives entry
#include * Eduard Bloch [Sun, Oct 10 2004, 08:15:32PM]: > which is not provided by mlterm. Though luck. In theory, every Args, it should be pterm. Eduard. -- OpenBSD fails miserably in this respect, and makes for an example of how NOT to work with the community on security issues. Their approach is, roughly, "we fixed this a while ago but didn't tell anyone, so you're vulnerable and we're not, ha-ha-ha".
Re: installing TCP programs when RPC programs are running
Florian Weimer <[EMAIL PROTECTED]> - Sun, Oct 10, 2004: > > While I see the benefit of your suggestion, for packet filters, I don't > > see how that would help average people experiencing the problem? Would > > you require the admin to configure each port for each RPC service as it > > is installed? > Maybe there could be defaults for the most common ones? I'm not sure. > The libc routines could also read /etc/services and skip ports listed > there. There should still be enough remaining ports. Good ideas, I don't know if they'll be accepted, but I will report that. > > (BTW, I used to call rpcinfo -p to setup my iptables rules dynamically, > > but that does not cover service restarts very well, something like a > > rpc_conntrack would be better, and it seemed to exist too) > One school of though in network security is that you don't have > intelligent firewalls, based on the assumption that parsing complex > protocols on firewall components is likely to make the firewall > vulnerable to the same attacks as the application to be protected by > the firewall. Static port assignments would be quite beneficial. That's an interesting point of view, but I'm still quite happy that iptables has a conntrack for example. :) I tend to think that security simply implies less features, but I come to the same conclusions as yours. We need someone willing to patch portmap to let the port of RPC services be chosen based on other rules that "first free port", but I'll report that too. To summarize, four ideas have emerged: - only warn once when multiple RPC services are installed, - warn only when the RPC service doesn't request a static port, - permit the configuration of static ports in portmap, - autodetected assigned services in glibc and try to avoid RPC services on them. Regards, -- Loïc Minier <[EMAIL PROTECTED]>
Re: proposal: 'xterm' alternatives entry
On Sun, Oct 10, 2004 at 08:27:34PM +0200, Frank Lichtenheld wrote: > On Sun, Oct 10, 2004 at 08:11:42PM +0200, martin f krafft wrote: > > also sprach Frank Lichtenheld <[EMAIL PROTECTED]> [2004.10.10.2005 +0200]: > > > Wouldn't it be better to file bugs against the packages that don't > > > use x-terminal-emulator? > > > > What if those bugs get ignored? see: #275527 > > Hmm, I don't know anything about how uml works but the answers seems > to imply that fixing it in user-mode-linux suffices... But that's > something you have to discuss with mdz and not with me. That bug was closed because it was _already fixed_ and the submitter didn't check before filing it. -- - mdz
Re: proposal: 'xterm' alternatives entry
On Sun, Oct 10, 2004 at 08:32:12PM +0200, martin f krafft wrote: > Right, and I don't want to beat on this issue. user-mode-linux does > fix it, but Manoj's kernel-package can also create UML kernels, > which then call xterm. Thus, I would have thought this is best fixed > in kernel-patch-uml. > > I consider s/xterm/x-terminal-emulator/ a necessary step of > debianisation, wherever possible. I explained this to you on IRC already. If using kernel-package, the Debianization patches in user-mode-linux should be packaged as a kernel patch, which would be used with make-kpkg. -- - mdz
bug #275527 (was: proposal: 'xterm' alternatives entry)
also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2004.10.10.2101 +0200]: > That bug was closed because it was _already fixed_ and the > submitter didn't check before filing it. I am sorry, Matt, but it was not fixed. You should have tagged the bug wontfix and leave it open. also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2004.10.10.2102 +0200]: > I explained this to you on IRC already. If using kernel-package, > the Debianization patches in user-mode-linux should be packaged as > a kernel patch, which would be used with make-kpkg. What, and then require to always add two patches because UML by itself produces buggy packages? No, this is not a solution if you ask me. You are packaging a kernel patch that has 'xterm' hardcoded in it. Debian's alternatives system exists specifically to address this problem. So please, use it. I do not see a single point why the UML kernel patch should be as pristine as possible. This is a minor modification required to properly integrate with Debian. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: proposal: 'xterm' alternatives entry
Frank Lichtenheld <[EMAIL PROTECTED]> wrote: > --tKW2IUtsqtDRztdT > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > On Sun, Oct 10, 2004 at 06:43:09PM +0200, martin f krafft wrote: >> The procedure would be to upload a new 'xterm' package which moves >> /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm >> as alternatives symlink in addition to x-terminal-emulator. Then, >> progressively, the other x-terminal-emulator providers can start to >> add xterm to their postinst scripts. > Wouldn't it be better to file bugs against the packages that don't use > x-terminal-emulator? ...and those that do it inconsistently, of course -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: proposal: 'xterm' alternatives entry
martin f krafft <[EMAIL PROTECTED]> wrote: > --ZGiS0Q5IWpPtfppv > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > As a happy use of rxvt-unicode-ml (thanks Zomb!), I am very annoyed > at times by softwares that have 'xterm' hardcoded. Obviously, > I report these as bugs to have it changed to x-terminal-emulator, > but then again, I consider 'xterm' to be somewhat of a generic name > by now that I think it should be put under control of the > alternatives system. > The procedure would be to upload a new 'xterm' package which moves > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm Mandrake did something like that a while ago(*) - broke the application name for X resources. (*) I don't run Mandrake anymore, so I don't know what they do now... -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: proposal: 'xterm' alternatives entry
Peter Eisentraut <[EMAIL PROTECTED]> wrote: > martin f krafft wrote: >> What do you think of this proposal. Are there any string points >> *against* it? > I have written scripts that explicitly call xterm because other terminal > emulator programs under X (which I had preferred otherwise) couldn't > handle certain programs. So in those situations it was not a generic > name, but a specific program with specific capabilities. Does the package description mention the feature which is needed? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: TG3 firmware report...
Paul Hampson wrote: > On Sat, Oct 09, 2004 at 07:10:33PM -0400, Daniel Freedman wrote: >> Unfortunately, I believe that my server board contains one of the rare >> on-board Broadcom chipsets that is completely unable to function (best >> as I can tell), without downloading this firmware, or without at least >> disabling the download of it... In other words, it works perfectly >> with 2.4.26, but not at all with 2.6.8. It's recognized fine, get's >> IP address fine, has kernel modules loaded etc., but simply drops >> packets off the stack... > >> Anyway, just thought I'd see what people think of this, and how the >> Debian community wants to proceed. Is there some way to enable >> compability with this without downloading the firmware and violating >> the DFSG? > > Surely you can grab the firmware yourself, dump it into the appropriate > place in /lib/firmware (the boot message from the tg3 driver tells you) > and then it'll work on next boot? > > This won't break the DFSG as far as I know, 'cause you're not > distributing the firmware and Broadcom presumably are happy for you to > download it yourself for use. > > Unless of course the firmware itself is GPL'd, and therefore no one > can legally give it out without offering the source as well. It is GPLed. This is why it hasn't been put in non-free. :-P Contact Broadcom and ask them to do one of the following things: (1) Release source for the firmware (2) Release the firmware under a license which allows distribution without source Until they do one of these two things, the firmware is not safe to distribute. I don't know why upstream is distributing it; I believe they are simply being sloppy about licensing. > I'm not sure this is the right list for this topic, anyway... > -- This space intentionally left blank.
Re: Jörg Schilling is damage; the community should route around him
> Branden Robinson: > > It's time to fork. Let us work with the rest of the community to > standardize on a new set of tools based on the last free version of > cdrtools, thank Mr. Schilling for his valuable contributions, and leave him > be to pursue his interests in proprietary software without interference > or argument from us. He appears to regard placing his work under the plain > vanilla GNU GPL that works for so many projects as an act that he cannot > perform in good conscience. Let us stop placing him in that uncomfortable > position. > Jose Carlos Garcia Sogo: > > I agree with you. And I guess that the "good" direction would be > pushing libburn, which seems a bit stalled right now. Also, DVD[-R[W], > +R[W]] support should be added to it. On top of that library, it would > be easier to build command line and GUI oriented programs, which could > drop at that moment cdrecord. > > But what is needed there is people with time and access to different > drives. Perhaps people behind dvd+rw-tools could be interested, and some > company out there could sponsor this piece of software. In support of this statement, I'd like to add that my limited interactions with Andy Polyakov, the author of dvd+rw-tools, have been overwhelmingly positive. I'd also remind people that dvd+rw-tools is already able to write dvd-r and dvd-rw (even though its name implies dvd+r and dvd+rw) in some modes. I have used dvd+rw-tools for some time as my exclusive software for DVD authoring, even on dvd-r and dvd-rw. Also, cdrdao has some CD writing capability (not withstanding caveats and warnings in README.Debian) and is not, to my knowledge, related to cdrtools. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: TG3 firmware report...
Nico Golde wrote: > hi > * Roland Stigge <[EMAIL PROTECTED]> [2004-10-10 15:46]: >> Daniel Freedman wrote: >> > Anyway, just thought I'd see what people think of this, and how the >> > Debian community wants to proceed. Is there some way to enable >> > compability with this without downloading the firmware and violating >> > the DFSG? >> >> Since the tg3 driver doesn't work with my BCM5702 interface anyway >> (#240812), I'm using the bcm5700-source driver from non-free. I guess >> people running servers and using the advanced features of this driver >> are doing the same. >> >> Feel free to write a personal email to Broadcom asking for the source of >> their GPLed driver. > > the source is included in the kernel sources :) > regards nico Um, no, the firmware source isn't. There's just a hunk of hex. -- This space intentionally left blank.
Re: J?rg Schilling is damage; the community should route around him
On Sat, Oct 09, 2004 at 01:18:50PM +0200, Jose Carlos Garcia Sogo wrote: > El s??b, 09-10-2004 a las 00:04 -0500, Branden Robinson escribi??: > > It's time to fork. Let us work with the rest of the community to > > standardize on a new set of tools based on the last free version of > > cdrtools, thank Mr. Schilling for his valuable contributions, and leave him > > be to pursue his interests in proprietary software without interference > > or argument from us. He appears to regard placing his work under the plain > > vanilla GNU GPL that works for so many projects as an act that he cannot > > perform in good conscience. Let us stop placing him in that uncomfortable > > position. > > I agree with you. And I guess that the "good" direction would be > pushing libburn, which seems a bit stalled right now. Also, DVD[-R[W], > +R[W]] support should be added to it. On top of that library, it would > be easier to build command line and GUI oriented programs, which could > drop at that moment cdrecord. I wrote about this only a few days ago in a brief piece which was included in planet.d.o. At the time I was directed very quickly towards libburn. Using a library seems a lot saner than taking over any of the cdrecord codebase. If necessary a command line wrapper around the library could emulate the cdrecord command line options. I couldn't gain access to the libburn CVS repository, but I did download the .0.2 version and the test code worked for me. I was able to burn an image using it fairly quickly, although I can't say how stable the code is generally. (The API documentation was nice). > But what is needed there is people with time and access to different > drives. Perhaps people behind dvd+rw-tools could be interested, and some > company out there could sponsor this piece of software. I think a few individuals would be happy to host the code and work on it, but hardward testing really is the stumbling block - as is portability testing. > The problem with cdrecord is that it works, and though there are some > glitches that people would like to see fixed, writing another different > tool is only that: rewriting. And using the same language, i.e. there is > no perl vs. python, perl vs. php, ... It does seem a little tedious reimplimenting code which already exists, and mostly works. This either suggests: 1) It isn't worth doing, and we just put up with the maintainer. 2) It shuld be done in a better way (library based?) 3) Forking a free-er/older version. Given the vehemence of J?rg to SuSE and the other people "illegally distributing inofficial versions (sic)" I strongly suggest option 3 is not a good idea - if nothign else it will lead to confusion amongst users. Perhaps having a Debian package of libburn would be a good starting point - then popular programs can be patched to work with it? Steve -- pgpqWvt3Dw3xh.pgp Description: PGP signature
Re: possible mass bug filing: spamassassin 3
Tollef Fog Heen [u] wrote on 10/10/2004 13:01:
* Sven Mueller
From the front page of spamassassin.org:
: Flexible: SpamAssassin encapsulates its logic in a well-designed,
: abstract API so it can be integrated anywhere in the email
: stream. The Mail::SpamAssassin classes can be used on a wide variety
: of email systems including procmail, sendmail, Postfix, qmail, and
: many others.
You are right. This has changed since I last checked (two years ago or
so, not sure when). I should have re-checked this before posting.
| > [splitting SA into libmail-spamassassin-perl and spamassassin]
|
| Well, in that case, libmail-spamassassin-perl would be the size of the
| current spamassassin package, and the new spamassassin package (which
| depends on the libmail-spamassassin-perl package) is about 2k in size,
| description and packaging overhead included. Sorry, that doesn't make
| much sense.
: [EMAIL PROTECTED] ~ > for f in $(dpkg -L spamassassin | grep -v perl \
|grep -v man3 ); do [ -f $f ] && echo $f; done | xargs du -shc |
tail -1
1,1Mtotalt
SA currently ships nearly 600k of rules.
I don't understand what you are trying to say. If you yre trying to
say that libmail-spamassassin-perl wouldn't include the rules, but
spamassassin would, I would like to propose splitting into 3 packages:
libmail-spamassassin-perl, libmail-spamassassin-perl-rules and
spamassassin, so that Programs relying on libmail-spamassassin-perl can
also depend upon the rules package without depening on the spamassassin
package. Also note that we actually already have 2 packages:
spamassassin and spamc.
But what I meant to say is that it doesn't make much sense to split the
spamassasin package into several packages: neither the perl modules nor
spamassassin itself would be useful without the rules. So you would need
to include the rules in the modules-package (or a third package, upon
which the lib package would probably depend). After you did that, the
spamassassin executable doesn't add much to that package (29k to be
precise).
As a side note: SA3 ships with 452k of rules if you count
/etc/spamassassin/local.cf and 448k if not:
mail2:/tmp# dpkg -L spamassassin| grep -E 'etc|usr/share/spamassassin' |
grep .cf| xargs du -hc| tail -1
452Ktotal
mail2:/tmp# dpkg -L spamassassin| grep -E 'usr/share/spamassassin' |
grep .cf| xargs du -hc| tail -1
448Ktotal
You didn't exclude all man pages and you didn't exclude start scripts
and configuration ;-)
soname is here used a bit loosely meaning «ABI/API version»; this is
technically not correct (as you point out), but it's shorter than
writing «ABI/API version» all over the place.
OK.
(And, given that perl modules can be normal shared objects, they
certainly _can_ have sonames proper, but I agree that's not the norm.)
In a way, yes. But this is only true for binary modules.
They can try to import Mail::SpamAssassin3 first, if that fails, try
Mail::SpamAssassin. A nice thing with this is you actually know what
API you use.
Yes.
| spampd for example has a total of 10 lines which differentiate between
| versions v being < 2.7, 2.7 <= v < 3.0 and v >= 3.0 _and_ do what's
| needed to work with either of the three possible categories of
| SpamAssassin versions. If SpamAssasin v3 would be renamed to
| Mail::SpamAssassin3, the changes would be more like 120 lines.
BEGIN {
eval {
require Mail::SpamAssassin3;
import Mail::SpamAssassin3 qw(foo bar baz);
}
if ($@) {
require Mail::SpamAssassin;
import Mail::SpamAssassin qw(foo bar baz);
}
}
Doesn't look like 120 lines to me.
Problem is that SA doesn't work well with that sort of namespace
mangling. At least most programs which I looked at using SA modules use
it in a object oriented way (if you can call it that). So they have a
multitude of lines referring to Mail::SpamAssassin.
| [SA3 API published half a year ago]
This is orthagonal to the discussion -- how much and when the API
changed doesn't mean it shouldn't be done right.
Well, yes.
This is Debian. We don't break stuff arbitrarily.
I.e. "We try not to break stuff arbitrarily." ;-)
Problem with SA3 is that by renaming Mail::SpamAssassin to
Mail::SpamAssassin3 for SA3 makes it difficult for many programs to
adjust. Especially because this introduces a new modulename which isn't
used on any other platform, causing it to be a debian-only change to the
programs. Not renaming it breaks some programs, which had months to
adjust to the new API (upstream) with that adjustment being a pretty
small change. Also, the adjustment needs to be made in upstream versions
anyway.
I certainly don't want to see SA3 enter the testing/stable archive as
"spamassassin"/Mail::SpamAssassin before each and every program which
uses it can cope with the change or conflicts version >=3 [1] or is
removed from the archive.
However, I would like to see SA3 enter the testing/stable archive as
"spamassassin" as soon a
Re: python-apt: how to get ShortDesc and LongDesc
|--==> Igor Stroh writes: IS> Free Ekanayaka wrote: >>would someone write me a sample code on how to get the ShortDesc >>and LongDesc records from the PkgRecords class? >> >>I think it should start with something like: >> >>cache = apt_pkg.GetCache() records = apt_pkg.GetPkgRecords(cache) >>package = cache['my_pkg'] IS> Since there are no API-docs for python-apt, there's only one IS> option: use the source :) Thanks! :) Maybe we could at least include the code below in /usr/share/doc/python-apt/examples beside the other scripts... Shall I file a wishlist bug for this? Cheers, Free IS> 8<== IS> import apt_pkg IS> PACKAGE_NAME = "my_pkg" IS> IGNORE_DPKG_STATUS = 1 IS> apt_pkg.init() IS> cache = apt_pkg.GetCache() IS> records = apt_pkg.GetPkgRecords(cache) IS> package = cache[PACKAGE_NAME] IS> for pack_vers in package.VersionList: IS> for pack_file, index in pack_vers.FileList: IS> records.Lookup((pack_file,index)) IS> # ignore Debian dpkg status file lookups IS> if pack_file.IndexType != 'Debian Package Index' and \ IS>IGNORE_DPKG_STATUS == 1: IS> continue IS> print "ORIGIN:", pack_file.Site IS> print "VERSION:", pack_vers.VerStr IS> print "SHORT DESC:", records.ShortDesc IS> print "LONG DESC:", records.LongDesc IS> print IS> 8<== IS> HTH, IS> Igor
Re: TG3 firmware report...
On Oct 10, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > Until they do one of these two things, the firmware is not safe to > distribute. I don't know why upstream is distributing it; I believe they > are simply being sloppy about licensing. You know well that upstream is not "being sloppy", but disagrees with your interpretation of licensing. -- ciao, | Marco | [8468 qu1ZFFjpdB01A] signature.asc Description: Digital signature
Re: Strange behaviour at kernel upgrade
Le sam 09/10/2004 à 16:29, Wouter Verhelst a écrit : > On Sat, Oct 09, 2004 at 12:48:23PM +0200, Jérôme Warnier wrote: > > I got this strange behaviour on Sid today while upgrading > > kernel-image-2.6.8-1-686. Notice on the log that I answered "n" to "Do > > you want to stop now? [Y/n]", and it aborted just like if I answered > > "y". > > > > The only thing noticeable is that I took a long time (a few minutes) to > > answer. I suspect there should be no timeout in this case. > > > > I just wanted to let you know, just in case. > > > > > > > > Preparing to replace kernel-headers-2.6.8-1 2.6.8-3 (using > > .../kernel-headers-2.6.8-1_2.6.8-4_i386.deb) ... > > Unpacking replacement kernel-headers-2.6.8-1 ... > > Preparing to replace kernel-headers-2.6.8-1-686 2.6.8-3 (using > ^ > Notice the extra space here. It appears you inadvertently hit the space > bar while you were doing something else. As a result, you had that space > in your input buffer, so when you hit enter, it was the space, rather > than the 'n', which was processed. As this script interprets everything > which is not 'n' as the default value, it bailed out. You're perfectly right. This is just a problem of the input checking being really too weak. If you are all aware of it, I don't mind. -- Jérôme Warnier Consultant BeezNest http://beeznest.net
Re: PROPOSAL: debian-mozilla@lists.debian.org
Johannes Rohr a écrit : Dear all, due to the ever increasing number of mozilla-based packages I wonder if it would be a good thing to have a separate debian-mozilla mailing list. Personally I have big difficulties understanding the hacked way how mozilla extensions etc are being repackaged for Debian and I would be very happy if there was a place to discuss such matters. Looking forward to any comments & opinions, As still nobody has answer to Johannes, I start. I think that creating a such list is a very good idea. Currently the only way to contact mozilla package's maintainers is to do an apt-cache search mozilla and grep for the email adresses. FYI there is currently 49 source packages with mozilla in their name. A common list would improve communication between all such maintainers, supposing that they all subscribe to the new mailing list (I hope so). Moreover, it could improve the coordination between all mozilla package's maintainer. It could be useful to tell things like, "Hey I have uploaded a new version of mozilla-foo to experimental, feel free to also update the corresponding translation package", or "new version of mozilla-foo handles translation differently as before, here is how it works". I don't say there is a lack of communication, but I am sure that some duplicate work could be avoid by creating such a new mailing list. If nobody opposes, I volunteer to open a bug against lists.debian.org, unless somebody else want to do that. Cheers, Aurelien -- .''`. Aurelien Jarno GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Bug#275897: ITP: tiff2png -- TIFF to PNG converter with alpha channel (transparency) support
Package: wnpp Severity: wishlist * Package name: tiff2png Version : 0.91 Upstream Author : Willem van Schaik, Greg Roelofs * URL : http://www.libpng.org/pub/png/apps/tiff2png.html * License : BSD-like Description : TIFF to PNG converter with alpha channel (transparency) support This package can convert a TIFF image directly to a PNG image without the need of any intermediary format. Unlike the netpbm package, this program can preserve transparency information during the conversion. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: alpha Kernel: Linux 2.6.4-rc2 Locale: LANG=C, LC_CTYPE=C
Re: Bug#275897: ITP: tiff2png -- TIFF to PNG converter with alpha channel (transparency) support
On Sun, Oct 10, 2004 at 04:27:21PM -0500, John Goerzen wrote: > This package can convert a TIFF image directly to a PNG image without > the need of any intermediary format. Unlike the netpbm package, > this program can preserve transparency information during the > conversion. What's the gain of this over "convert file.tiff file.png"? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: proposal: 'xterm' alternatives entry
> > The procedure would be to upload a new 'xterm' package which moves > > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm Of course, you mean /usr/X11R6/bin/xterm... > Mandrake did something like that a while ago(*) - broke the > application name for X resources. I was also going to point out the issue of X resources. While remaining in favor of fixing other applications rather than changing xterm, I would point out that this issue could be mitigated by having xterm be moved into another directory so its base name would be the same. (I suppose /usr/lib/xterm/xterm could work...) That said, I am not able to convince myself that this is an issue here... if I clear my X resources, set HOME to a temporary directory, copy /usr/X11R6/bin/xterm (as root, preserving setuid) to /tmp/xterm.real, and invoke /tmp/xterm.real, I see a client class of UXTerm and a client name of xterm. Maybe this is debian-specific? I thought only uxterm did that. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Re: First spam
On Sun, Oct 10, 2004 at 11:32:06AM -0500, Steve Greenland wrote: > On 09-Oct-04, 20:06 (CDT), Clemens Schwaighofer <[EMAIL PROTECTED]> wrote: > > On 10/10/2004 07:38 AM, paddy wrote: > > > I'm actually surprised it takes them that long. > > > debian-devel must be way down the target list. > > > > probably geeks don't buy viagra, home loans, online medicine, etc :) > > People (aka scum) who harvest addresses only care about a numbers, not > "target markets". I would be surprised if there were no feedback loop at all, after all the motive appears to be the standard 'obtain economic transfers' one. But perhaps you're right and it is not that sophisticated. I don't know. Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall
Re: Bug#275897: ITP: tiff2png -- TIFF to PNG converter with alpha channel (transparency) support
Steinar H. Gunderson [u] wrote on 10/10/2004 23:41: On Sun, Oct 10, 2004 at 04:27:21PM -0500, John Goerzen wrote: This package can convert a TIFF image directly to a PNG image without the need of any intermediary format. Unlike the netpbm package, this program can preserve transparency information during the conversion. What's the gain of this over "convert file.tiff file.png"? I had the same question in mind ;-) One thing I can see: It's smaller and therefore probably less error prone. However, a note on the upstream homepage made me think even more: This can lead to the inadvertent loss of source files, at least on Unix >>> systems (where the shell would expand ``tiff2png *.tiff'' into a list >>> of actual filenames, the second of which would be treated by tiff2png >>> as the output filename). [Note that the issue of overwriting files is _not_ the problem with upstream 0.91] What makes me think is the fact that if given numerous filenames on the commandline, the programm takes the second one as the output filename (and probably ignores the rest). IMHO (IANADD), this should be fixed before this program enters the archive. There are two options of how to fix it _if_ it is accepted into the archive: 1) Bail out if more than two filenames are given 2) (which I would prefer) Take all the filenames, loop over them and use inputfilename (minus /\.tif+//) plus .png as output filenames However, if I have the software on a computer to create tiffs with transparency, I see no reason to use tiff2png in favor of ImageMagick/convert, especially as the latter has been around for years and is pretty well tested. regards, sven
Bug#275388: mounting at boot time under grub
> I dropped all references to specific boot loaders since there > are over a dozend different ones used with linux and people > beagan to complain that I didn't mention the one they use. To pull out a cliche, this is "letting the perfect be the enemy of the good". Covering the two most popular boot loaders (lilo and grub), together accounting for certainly well over 90% of the Debian users, and in particular nearly 100% of the less experienced users, is GOOD. Covering them all might be perfect, but just because it is impractical to do the perfect thing doesn't mean you should abandon a good thing. It is not a slight on other boot loaders to not cover them - it is completely reasonable to just cover the N most popular boot loaders, for some N, and leave it at that. -- Barak A. Pearlmutter <[EMAIL PROTECTED]> Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Automake & dependency tracking
Hi, Recent versions of automake add an option --disable-dependency-tracking to the generated configure script. If you don't use that option, the generated Makefile will wrap all calls to the compiler in a call to 'depcomp', which will generate a Makefile snippet in a .deps directory to better track dependencies. This would include dependencies in the to be built package, but also dependencies outside that package, e.g., system headers. While I can understand the value of this for an upstream developer, I would wonder whether this is of any value for Debian packages. Debian packages typically do not profit from this kind of optimization; after all, a call to 'dpkg-buildpackage' will start off by running a 'make clean', which means that all source files are (unconditionally) rebuilt anyway. Is there any other reason why we would still need to use automake's dependency tracking anyway? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: proposal: 'xterm' alternatives entry
Once upon a time martin f krafft said... > > The procedure would be to upload a new 'xterm' package which moves > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm > as alternatives symlink in addition to x-terminal-emulator. Then, > progressively, the other x-terminal-emulator providers can start to > add xterm to their postinst scripts. > > What do you think of this proposal. Are there any string points > *against* it? Perhaps this is a bit tangential, but I really wish that xterm replacements would not use the TERM string of "xterm" unless it completely supports the escape sequences that xterm(1) supports. In my bashrc, I use some query escape sequences to determine the text colour and expect to be able to read back a response. When using other terminal emulators that say they are TERM=xterm but aren't, they dont respond to the escape sequence query and my login hangs, waiting to read the response from the terminal. So, I propose the opposite to you. A terminal emulator should not identify itself as xterm in any way unless it completely and accurately supports the same interfaces that xterm(1) does.
Re: proposal: 'xterm' alternatives entry
Jay Berkenbilt <[EMAIL PROTECTED]> wrote: >> > The procedure would be to upload a new 'xterm' package which moves >> > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm > Of course, you mean /usr/X11R6/bin/xterm... I didn't notice that. Though the cygwin people have been moving everything out of /usr/X11R6 for some reason... >> Mandrake did something like that a while ago(*) - broke the >> application name for X resources. > I was also going to point out the issue of X resources. While > remaining in favor of fixing other applications rather than changing > xterm, I would point out that this issue could be mitigated by having > xterm be moved into another directory so its base name would be the > same. (I suppose /usr/lib/xterm/xterm could work...) That said, I am That probably would work. It's only the argv[0] that's used to get the application name, iirc. > not able to convince myself that this is an issue here... if I clear > my X resources, set HOME to a temporary directory, copy > /usr/X11R6/bin/xterm (as root, preserving setuid) to /tmp/xterm.real, > and invoke /tmp/xterm.real, I see a client class of UXTerm and a > client name of xterm. Maybe this is debian-specific? I thought only > uxterm did that. I thought so too - uxterm passes the "-class" option for this purpose. And that's one of the few that isn't implemented using a resource value, so it's unlikely that your xrdb setup could pass a -class option to it. (Usually I'm running whatever xterm I compiled - from /usr/local/bin - but should have noticed if Debian had modified that - was testing on Friday). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: First spam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2004 07:29 AM, paddy wrote: > On Sun, Oct 10, 2004 at 11:32:06AM -0500, Steve Greenland wrote: > >>On 09-Oct-04, 20:06 (CDT), Clemens Schwaighofer <[EMAIL PROTECTED]> wrote: >> >>>On 10/10/2004 07:38 AM, paddy wrote: >>> I'm actually surprised it takes them that long. debian-devel must be way down the target list. >>> >>>probably geeks don't buy viagra, home loans, online medicine, etc :) >> >>People (aka scum) who harvest addresses only care about a numbers, not >>"target markets". > > > I would be surprised if there were no feedback loop at all, after all > the motive appears to be the standard 'obtain economic transfers' one. > But perhaps you're right and it is not that sophisticated. I don't know. well if a spammer sends out 1.000.000 emails and only 0.5% answer back then you got 500 answers. And if they buy that stuff for $14.99, then he alrady made a win, because he himself never sent out the emails, so he had no spendings there. lg, clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBagH3jBz/yQjBxz8RAufGAKCc23IfvZZVlwDLu6vVWxW+VOGc7gCg1o9J W8OAYblC2tVCv21MSvNtM/Y= =yiYh -END PGP SIGNATURE-
[OT:HUMOR] Re: software
On Thu, 7 Oct 2004, wrote: > new software for the best price for you I am saying the same for my list > Adobe Illustrator CS - 90.00 inkscape - 0.00 > Adobe Acrobat 6.0 Professional - 100.00 xpdf - 0.00 > McAfee Personal Firewall Plus 2004 v. 5.0 - 20.00 Why? > Adobe Photoshop Elements 2.0 - 40.00 gimp-* - 0.00 > Macromedia Studio MX 2004 - 180.00 emacs - 0.00 > Abode InDesign CS - 100.00 scribus - 0.00 > Microsoft Windows Server 2003 Enterprise Edition - 200.00 www.debian.org - 0.00 > Adobe Photoshop 7.0 - 60.00 gimp - 0.00 > Adobe Premiere Pro 1.5 - 100.00 kino - 0.00 > QuickBooks Premier Edition 2004 - 80.00 gnucash - 0.00 > Microsoft Office XP Pro - 100.00 openoffice - 0.00 > Symantec pcANYWHERE 11.0 - 80.00 ssh - 0.00 > Macromedia Studio MX 2004 - 180.00 Duplicate listing > 3D Home Architect Landscape Design Deluxe 6.0 - 29.99 qcad, but only does 2d - 0.00 > and more http://yttoj.populationoem.info/ and more http://packages.debian.org/
