Re: debian archive disk space requirements.

[Andreas Barth]

* Matt Zimmerman ([EMAIL PROTECTED]) [030831 00:05]:
> On Sat, Aug 30, 2003 at 11:40:34AM +1000, jason andrade wrote:

> > Is there any way to reduce the size of the archive over the next
> > 4-6 weeks ?

> Drop potato?

Or - allowing to act locally - put potato on an nfs-mounted volume
(assuming that not so many people are accessing potato now).


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: configure web proxy via DHCP server

[Andreas Barth]

* Brian May ([EMAIL PROTECTED]) [030831 01:35]:
> On Sat, Aug 30, 2003 at 10:30:31AM +0200, Javier Fern?ndez-Sanguino Pe?a 
> wrote:
> > All of these, IIRC, provide means to run user-defined scripts for
> > autoconfiguration. Setting up the proxy server might be just a manner of
> > setting up the http_proxy environment variable depending on your location
> > (although some browsers might not use it). 

> No, setting http_proxy wont work unless youo log out and back in again,
> or at least close all your terminal sessions.
> 
> It won't work for programs like Mozilla.

But it would be cool if this information is stored in "the proper
place" and we patch applications like mozilla that they have a
config-option to use this information. But that's probably a
post-sarge thing.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Accepted kaffe 1:1.1.1-1 (i386 source)

[Matt Zimmerman]

On Sun, Aug 31, 2003 at 02:27:16PM +1000, Herbert Xu wrote:

> Listing random upstream changes in debian/changelog just because they
> happen to fix bugs in the Debian BTS makes no sense.

It makes sense to me, and I do it whenever possible.  It is valuable to
include in the Debian changelog information about _how_ a Debian bug was
fixed, not only the fact that it was fixed.

-- 
 - mdz

Re: Accepted kaffe 1:1.1.1-1 (i386 source)

[Martin Schulze]

Matt Zimmerman wrote:
> > > If I report "segmentation fault in ls", I--as a user of ls, not a
> > > developer--couldn't care less about why it was segfaulting or how the
> > > bug was fixed; I only care that it's been fixed.  If a developer wants
> > > to spend their limited time researching how the bug was fixed and
> > > summarizing it in a changelog, great, but it's certainly not something I'd
> > > expect everyone to do.
> > 
> > It's not about summarizing how the bug was fixed.  It's about summarizing 
> > the
> > bug *itself* in the changelog.
> 
> I certainly prefer it if the changelog tells how the bug was fixed.  This
> documents the difference between:
> 
>  * New upstream release
>- Removed the entire subsystem which contained this bug (Closes: #xxx)
> 
>  * New upstream release
>- Made the "foo" option create its file with sane permissions (Closes: 
> #xxx)

See

manpages (1.58-1) unstable; urgency=low

[..]
  * New upstream source (1.58) (closes: Bug#175564, Bug#175287)
[..]
. Updated deprecation information on getipnodebyname(3) (closes
  Bug#183112, Bug#176709, Bug#157746, Bug#152780)
. Updated realpath(3) now warns that MAXPATHLEN may not exist (closes:
  Bug#152136)
. Upstream added links for modfl(3) and modff(3) (partially fixes:
  Bug#17872)
. Upstream added undocumented(2) (closes: Bug#149397)
[..]

I hope this reflects good packaging practice.

Regards,

Joey

-- 
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi

Please always Cc to me when replying to me on the lists.

Re: overwriting files from modules packages

[Martin Schulze]

Matt Zimmerman wrote:
> On Sun, Aug 31, 2003 at 12:18:26AM +0200, martin f krafft wrote:
> 
> > also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.08.31.0013 +0200]:
> > > If you want two different versions of documentation, they need to
> > > be named differently.  Alternatively, you can just split the
> > > documentation into a separate package and allow only one version
> > > to be installed at once.
> > 
> > I don't think a single manpage warrants another binary package. So
> > the only real solution is to put the manpage into
> > /usr/share/doc//docs ...
> 
> Or name it -..

And maybe use dpkg-divert / update-alternatives for the .
version.

Regards,

Joey

-- 
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi

Please always Cc to me when replying to me on the lists.

Re: Accepted kaffe 1:1.1.1-1 (i386 source)

[Martin Michlmayr]

* Martin Schulze <[EMAIL PROTECTED]> [2003-08-31 10:24]:
> . Updated deprecation information on getipnodebyname(3) (closes
>   Bug#183112, Bug#176709, Bug#157746, Bug#152780)

You're missing a colon after "closes".

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Saludos desde Madrid

[Veronica]

Hola amig@:
Me llamo Verónica. Te escribo desde Madrid, España y formo parte de un equipo 
del Movimiento Humanista.

Hoy son ya millones de personas las que experimentan cómo la sociedad en que 
vivimos se deshumaniza día a día. El ser humano ha perdido todo valor, el mundo 
se mueve en torno al dinero y en base al egoísmo, mientras las personas van 
quedando cada vez más desamparadas. De este modo, mientras cada uno está  
preocupado de sus propios problemas, todos vivimos cada vez peor.

Sin embargo los humanistas sabemos que el absurdo de la globalización dirigida, 
pensada sólo en términos económicos por los grandes bancos y multinacionales, 
no va a triunfar. Existe otro proceso de mundialización donde el ser humano ha 
crecido internamente y se encamina a la formación de una Nación Humana 
Universal. Hay una nueva sensibilidad en el ser humano que experimenta que 
cualquier cosa que pase en cualquier punto del planeta termina por afectarle a 
uno mismo. Este es un proceso histórico irreversible y así lo sienten ya en su 
corazón millones de personas.

Todo ser humano tiene derecho a una vida digna por el simple hecho de haber 
nacido. Y en el interior de todo ser humano hay algo muy grande que está 
buscando expresarse en el mundo.

Nuestro proyecto consiste en conectar y organizar a esos millones de personas 
de sensibilidad humanista.

Si estás interesado en saber más de nuestra propuesta, por favor sigue estos 
pasos:
1- Abre un mensaje nuevo
2- Escribe en el asunto la palabra SI
3- Envíalo a la dirección: [EMAIL PROTECTED]

Esperamos tu mensaje.

Un saludo afectuoso.
Verónica

==
Este mensaje se envía una única vez, por tanto no es
necesario que te des de baja de ninguna lista. Si su
contenido no es de tu interés, disculpanos.

No obstante, si conoces a otras personas a quienes
pueda interesar nuestra propuesta, te pedimos que
les reenvies este mensaje. Gracias de antemano.

Re: Accepted kaffe 1:1.1.1-1 (i386 source)

[Martin Schulze]

Martin Michlmayr wrote:
> * Martin Schulze <[EMAIL PROTECTED]> [2003-08-31 10:24]:
> > . Updated deprecation information on getipnodebyname(3) (closes
> >   Bug#183112, Bug#176709, Bug#157746, Bug#152780)
> 
> You're missing a colon after "closes".

Eeeks. fixed.

Regards,

Joey

-- 
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi

Please always Cc to me when replying to me on the lists.

Re: Accepted kaffe 1:1.1.1-1 (i386 source)

[Nikolaus Rath]

Ross Burton <[EMAIL PROTECTED]> wrote:
>> > "The bug has been fixed" is everything I would need to know.  I don't
>> > really care if it was a typo, a new library, a rebuild or some magic
>> > incantation with black dribbling candles, the bug has been fixed.
> 
> On Fri, 2003-08-29 at 17:46, Mathieu Roy wrote:
>> This approach surely don't raise the level of Debian.
>> Maybe *you* do not care of the details about the bug you reported. But
>> a Debian developer is entitled, normally, to provide information
>> according to what *users* can expect.
> 
> On Fri, 2003-08-29 at 16:12, Nikolaus Rath wrote: 
>> I do.
> 
> If you want to see every change which was made to the source, read the
> upstream Changelog.  If you want to see Debian packaging changes, read
> the Debian Changelog.  It's simple really. :)

No. Ignoring the fact that not all packages have upstream changelogs,
it can be still quite complicated to find the corresponding entry to
your debian bug report in the upstream changelog.

   --Nikolaus

"non-free" installer packages in our supposedly Free sections.

[Tore Anderson]

  I've noticed there's quite a few almost-empty packages lurking in
 the archive, whose sole purpose seems to be to download non-free
 software and install it on a users' systems.

  I don't like the fact that these seem to be (randomly) scattered
 over main and contrib.  Although the installer packages themselves
 certainly are Free, I feel the social contract is being violated
 when I have main and contrib in my sources.list file, but after
 having completed the installation of a package from these sections,
 non-free software is installed on my system.

  Here's a quick list of suspected packages:

vtkdata-installer   optional
acl-installer   contrib/devel
acl-pro-installer   contrib/devel
atokx   contrib/utils
daemontools-installer   contrib/misc
djbdns-installercontrib/net
f-prot-installercontrib/utils
flashplugin-nonfree optional
hyperspec   optional
ibm-jdk1.1-installercontrib/devel
int-fiction-installer   contrib/games
lw-per-installercontrib/devel
lw-pro-installercontrib/devel
msttcorefonts   contrib/graphics
nvidia-kernel-src   contrib/x11
nvidia-glx-src  contrib/x11
qmailanalog-installer   contrib/mail
quake2-data contrib/games
roxen-ssl   contrib/web
roxen2-ssl  contrib/web
sdic-edict  contrib/text
sdic-gene95 contrib/text
setiathome  contrib/misc
realplayer  net

  I've not verified all of these being such installer packages for
 non-free software, nor do I claim it to be complete.  Just to give
 you a rough idea.  Also, they're of different nature -- some install
 the non-free software from their post-installation scripts, while
 others install a script in /usr/sbin/ which will do the installation
 of the non-free software when run.

  I'd like to submit bugs on these, asking them to move to non-free.
 So consider this email an invitation to discussion before a mass-bug
 filing.

  If the list agrees that bugs are warranted, which severity should I
 use?  In my opinion it's a violation of the social contract and thus
 serious, but I've been recently told I should probably not use my
 own opinion as a justification for using the RC levels, so mayhaps
 wishlist would be better?

-- 
Tore Anderson

Re: "non-free" installer packages in our supposedly Free sections.

[Ola Lundqvist]

Hi

On Sun, Aug 31, 2003 at 01:13:17PM +0200, Tore Anderson wrote:
> 
>   I've noticed there's quite a few almost-empty packages lurking in
>  the archive, whose sole purpose seems to be to download non-free
>  software and install it on a users' systems.
> 
>   I don't like the fact that these seem to be (randomly) scattered
>  over main and contrib.  Although the installer packages themselves
>  certainly are Free, I feel the social contract is being violated
>  when I have main and contrib in my sources.list file, but after
>  having completed the installation of a package from these sections,
>  non-free software is installed on my system.
> 
>   Here's a quick list of suspected packages:
> 
> vtkdata-installer   optional

Installs example reference data. It could probably stay there.

> acl-installer   contrib/devel
> acl-pro-installer   contrib/devel
> atokx   contrib/utils
> daemontools-installer   contrib/misc
> djbdns-installercontrib/net
> f-prot-installercontrib/utils

Contrib is a perfectly ok place for installers.

> flashplugin-nonfree optional

This is in contrib!

> hyperspec   optional

Also in contrib!

> ibm-jdk1.1-installercontrib/devel
> int-fiction-installer   contrib/games
> lw-per-installercontrib/devel
> lw-pro-installercontrib/devel
> msttcorefonts   contrib/graphics
> nvidia-kernel-src   contrib/x11
> nvidia-glx-src  contrib/x11
> qmailanalog-installer   contrib/mail
> quake2-data contrib/games
> roxen-ssl   contrib/web
> roxen2-ssl  contrib/web
> sdic-edict  contrib/text
> sdic-gene95 contrib/text
> setiathome  contrib/misc

Contrib is a ok place for installers.

> realplayer  net

I can not find this in the archives.

>   I've not verified all of these being such installer packages for
>  non-free software, nor do I claim it to be complete.  Just to give
>  you a rough idea.  Also, they're of different nature -- some install
>  the non-free software from their post-installation scripts, while
>  others install a script in /usr/sbin/ which will do the installation
>  of the non-free software when run.
> 
>   I'd like to submit bugs on these, asking them to move to non-free.
>  So consider this email an invitation to discussion before a mass-bug
>  filing.
> 
>   If the list agrees that bugs are warranted, which severity should I
>  use?  In my opinion it's a violation of the social contract and thus
>  serious, but I've been recently told I should probably not use my
>  own opinion as a justification for using the RC levels, so mayhaps
>  wishlist would be better?

I can not find any bugs in this list. So please do not fine anyone.

The contrib section is precisely for free software that depends on
non-free (or software outside the archives) to be able to work as
expected.

Regards,

// Ola

> -- 
> Tore Anderson
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED] 654 65 KARLSTAD  |
|  +46 (0)54-10 14 30  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: GDM in sid does not read /etc/environment anymore

[Andreas Rottmann]

Daniel Ruoso <[EMAIL PROTECTED]> writes:

> But this doesn't solve the problem that the login screen appears
> without locales... I already have pam_env.so in /etc/pam.d/gdm, but
> this only take effect (maybe I'm wrong) after the user logs in. The
> greeter will still appear without locales. (and that's the bug
> reported in bts).
>
Funny enough, I encountered this too, just a few hours ago. I resorted
to setting the LANG variable in /etc/init.d/gdm.

Regards, 
 Andy

PS: Please do prober quoting
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.

Re: "non-free" installer packages in our supposedly Free sections.

[Tore Anderson]

* Ola Lundqvist

 > Contrib is a perfectly ok place for installers.

  I disagree.  If I have contrib in my sources.list file, and try
 to install a package from there, I expect only Free software to
 be installed on my system.  That means I should get either:

1) A fully-functional package, which might have been built
   with non-free tools, for instance OpenOffice, or
2) A package which does require me to install additional
   software to be of use, for instance UAE, or
3) A 'could not be installed' error from apt-get, which would
   suggest that the package placed a strict Depends on a
   package outside of main or contrib.

  In none of these cases I have gotten non-free software on my
 system.  In the case of the installer packages, especially the
 ones which does the installation from their post-installation
 scripts, I get non-free software on my system from installing
 packages from the sections that should be DFSG-Free software
 only.

 >> flashplugin-nonfree optional
 >
 > This is in contrib!
 >
 >> hyperspec   optional
 >
 > Also in contrib!
 >
 >> realplayer  net
 >
 > I can not find this in the archives.

  Quite right, I've messed up these.  Thanks for correcting me.

-- 
Tore Anderson

Re: "non-free" software included in contrib

[Mathieu Roy]

Ola Lundqvist <[EMAIL PROTECTED]> a tapoté :

> Hi
> 
> On Sun, Aug 31, 2003 at 01:13:17PM +0200, Tore Anderson wrote:
> > 
> >   I've noticed there's quite a few almost-empty packages lurking in
> >  the archive, whose sole purpose seems to be to download non-free
> >  software and install it on a users' systems.
> > 
> >   I don't like the fact that these seem to be (randomly) scattered
> >  over main and contrib.  Although the installer packages themselves
> >  certainly are Free, I feel the social contract is being violated
> >  when I have main and contrib in my sources.list file, but after
> >  having completed the installation of a package from these sections,
> >  non-free software is installed on my system.
> > 
> >   Here's a quick list of suspected packages:
> > 
> > vtkdata-installer   optional
> 
> Installs example reference data. It could probably stay there.
> 
> > acl-installer   contrib/devel
> > acl-pro-installer   contrib/devel
> > atokx   contrib/utils
> > daemontools-installer   contrib/misc
> > djbdns-installercontrib/net
> > f-prot-installercontrib/utils
> 
> Contrib is a perfectly ok place for installers.
> 
> > flashplugin-nonfree optional
> 
> This is in contrib!
> 
> > hyperspec   optional
> 
> Also in contrib!
> 
> > ibm-jdk1.1-installercontrib/devel
> > int-fiction-installer   contrib/games
> > lw-per-installercontrib/devel
> > lw-pro-installercontrib/devel
> > msttcorefonts   contrib/graphics
> > nvidia-kernel-src   contrib/x11
> > nvidia-glx-src  contrib/x11
> > qmailanalog-installer   contrib/mail
> > quake2-data contrib/games
> > roxen-ssl   contrib/web
> > roxen2-ssl  contrib/web
> > sdic-edict  contrib/text
> > sdic-gene95 contrib/text
> > setiathome  contrib/misc
> 
> Contrib is a ok place for installers.
> 
> > realplayer  net
> 
> I can not find this in the archives.
> 
> >   I've not verified all of these being such installer packages for
> >  non-free software, nor do I claim it to be complete.  Just to give
> >  you a rough idea.  Also, they're of different nature -- some install
> >  the non-free software from their post-installation scripts, while
> >  others install a script in /usr/sbin/ which will do the installation
> >  of the non-free software when run.
> > 
> >   I'd like to submit bugs on these, asking them to move to non-free.
> >  So consider this email an invitation to discussion before a mass-bug
> >  filing.
> > 
> >   If the list agrees that bugs are warranted, which severity should I
> >  use?  In my opinion it's a violation of the social contract and thus
> >  serious, but I've been recently told I should probably not use my
> >  own opinion as a justification for using the RC levels, so mayhaps
> >  wishlist would be better?
> 
> I can not find any bugs in this list. So please do not fine anyone.
> 
> The contrib section is precisely for free software that depends on
> non-free (or software outside the archives) to be able to work as
> expected.


There is a difference between "software that depends on non-free
software to run" and "free installer of non-free software".

A software in contrib that have only the purpose of installing a
non-free software in is postinst script is, IMHO, maybe a good
candidate for non-free: it's not really a dependancy but a package
that include a non-free software -- even if the non-free software is
kept separated, outside the package.

A packaged installer is almost a subpackaging: we could include every
software in non-free in contrib, if we make free packages that download
from the net the non-free packages. So the distinction
non-free/contrib would be useless...

For instance, I make a package called satan-installer with a postinst
script that execute the following command:
http://ftp.de.debian.org/debian/dists/potato/non-free/binary-i386/admin/satan_1.1.1-18.deb
 && dpkg -i satan_1.1.1-18.deb
would you like to include that satan-installer script in contrib?

It's almost how works flashplugin-nonfree.
http://packages.debian.org/testing/web/flashplugin-nonfree.html



So I do not agree that "Contrib is a ok place for installers". While
basically these installer are free software, it's a little bit
hypocritical to claim that these package contains free software.

Finally, someone who install the contrib flashplugin-nonfree get on
his computer a non-free software, possibly without even noticing it,
because he never seen a dependancy against a package in non-free. 





-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native engli

Re: "non-free" installer packages in our supposedly Free sections.

[Andreas Metzler]

Tore Anderson <[EMAIL PROTECTED]> wrote:
>  I've noticed there's quite a few almost-empty packages lurking in
> the archive, whose sole purpose seems to be to download non-free
> software and install it on a users' systems.
[...]
>realplayer  net

Iirc realplayer has been removed from the archive a long time ago.
cu andreas

having troubles adding info to 1 and/or 2 an existing bug(s)

[Cristian Ionescu-Idbohrn]

Please CC, as I don't subscribe to this list.

Tried to get this info through a couple of times now, but no joy :(
Posted to [EMAIL PROTECTED], but no answer :(

Chopped some parts. Left the essencial, I hope. And yes, I know the latest
apt-listbugs version provides an alternative way (a server in Japan) to
get the buglist info.

On Thu, 28 Aug 2003, Cristian Ionescu-Idbohrn wrote:
>
> Date: Thu, 28 Aug 2003 08:28:32 +0200 (CEST)
> From: Cristian Ionescu-Idbohrn <[EMAIL PROTECTED]>
> Reply-To: Cristian Ionescu-Idbohrn <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: apt-listbugs: 302 "Found"

[snip]

> All right,
>
> Some more info. This is what apt-listbugs requires from bugs.debian.org:
>
> ,
> | Hypertext Transfer Protocol
> | GET /~taru/apt-listbugs/index.db-critical.gz HTTP/1.1\r\n
> | Request Method: GET
> `
>
> And this is what it gets back from bugs.debian.org:
>
> ,
> | Hypertext Transfer Protocol
> | HTTP/1.1 302 Found\r\n
> | Date: Thu, 28 Aug 2003 05:19:26 GMT\r\n
> | Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2\r\n
> | Location: http://bugs.debian.org/apt-listbugs.html\r\n
> | Connection: close\r\n
> | Transfer-Encoding: chunked\r\n
> | Content-Type: text/html; charset=iso-8859-1\r\n
> | \r\n
> | Data (232 bytes)
> |
> |   64 63 20 0d 0a 3c 21 44 4f 43 54 59 50 45 20 48   dc .. | 0010  54 4d 4c 20 50 55 42 4c 49 43 20 22 2d 2f 2f 49   TML PUBLIC "-//I
> | 0020  45 54 46 2f 2f 44 54 44 20 48 54 4d 4c 20 32 2e   ETF//DTD HTML 2.
> | 0030  30 2f 2f 45 4e 22 3e 0a 3c 48 54 4d 4c 3e 3c 48   0//EN">. | 0040  45 41 44 3e 0a 3c 54 49 54 4c 45 3e 33 30 32 20   EAD>.302
> | 0050  46 6f 75 6e 64 3c 2f 54 49 54 4c 45 3e 0a 3c 2f   Found. | 0060  48 45 41 44 3e 3c 42 4f 44 59 3e 0a 3c 48 31 3e   HEAD>.
> | 0070  46 6f 75 6e 64 3c 2f 48 31 3e 0a 54 68 65 20 64   Found.The d
> | 0080  6f 63 75 6d 65 6e 74 20 68 61 73 20 6d 6f 76 65   ocument has move
> | 0090  64 20 3c 41 20 48 52 45 46 3d 22 68 74 74 70 3a   d here. | 00d0  3e 0a 3c 2f 42 4f 44 59 3e 3c 2f 48 54 4d 4c 3e   >.
> | 00e0  0a 0d 0a 30 0d 0a 0d 0a   ...0
> `
>
> which it seems is unable to handle :(
>
> The text on that page:
>
>   http://bugs.debian.org/apt-listbugs.html
>
> says:
>
>   You are using a program called apt-listbugs. This program is called
>   automatically, by apt, when packages get upgraded. However, this
>   program was written, without consulting the BTS maintainers, nor
>   consideration of the increased load(both bandwidth and cpu) on the BTS
>   machine.
>
>   Because of this, all cgi requests by apt-listbugs are being
>   redirected to this page. We are sorry for this inconvience.
>
> Is there any alternative server which can deliver the data?
>
> Although I understand the reasons (I read #207415), IMHO this was a poor
> decision, as it does not provide an alternative.
>
> IMO, apt-listbugs increased popularity shows it is an great tool which
> enables people to use Debian unstable, with lesser risk for rendering
> their boxes useless because of occasional fatal bugs in new/upgraded
> packages.


Cheers,
Cristian

邀请你加入画眉旅游专线游

[rwqr]

黔东南州自然风光奇特秀丽，民族风情浓郁，旅游资源十分丰富。自然风光融山、水、洞、林为一体，国家级风景区舞阳河和神奇峻秀的云台山、雷公山、杉木河、剑河温泉是贵州省东线旅游的主要景区。民族风情以苗舞侗歌及苗家“三月三、四月八、芦笙节”等丰富多彩的民族节日为代表，同时，独具特色的古建筑群青龙洞、飞云洞和侗族鼓楼、风雨桥享誉国内外。
 
   
许多的将军鸟、玩鸟高手就群居于最原始的自然山区中。家家有画眉，户户闻鸟声，凯里画眉已经成为一种品牌，在国内中最富盛名。
 
   
我们此次旅游的是一群鸟迷，我们在饱览自然风光奇特秀丽，民族浓郁风情的同时，更主要是让大家到每处都有好鸟看，有精彩赛事玩，我想这样的旅游在国内也应算资讯鸟友的创举吧，快乐加入资讯鸟友的精彩之旅吧，还等待什么。
 


本次活动由上海鸟友欢喜佛伟嘎哩提起倡议，由资讯网站组织牵头，全国各地画眉鸟友自行参与，欢迎各地鸟友报名参加此次活动，到画眉之乡雷公山脉腹地――凯里一游。定有你想不到的收获。
我们的初步想法是：
一、时间：2003年十月一日开始，大约四到六天的时间吧

二、经费：找各地鸟协会赞助或资讯鸟友中愿意赞助的就赞助（尽量解决鸟友到目的地后的吃、住及交通问题）。
 

三、活动按排：先到凯里会集，然后到凯里看一场鸟赛（一天一夜），并参观一些画眉鸟场――到雷公山腹地――雷山县城看鸟赛并游雷公山自然风景区（一天）――台江观鸟赛（半天）――到剑河温泉洗温泉浴然后走剑河县城观一场鸟赛，然后走剑河原始森林区进行原始森林游，看鸟赛，有时间到剑河附近几个玩斗鸟较风行或出斗鸟的地方观光旅游、看鸟（一至两天）等等。最后是黄果树日游（也可先玩黄果树两日游），全程租26坐旅游公司全空调车）以上费用总共是每人480元（雷山、剑河只含车的费用，吃住不计算在内，一般50元一天能解决吃住问题）。最后有时间可到附近的施秉杉木河，享受一下漂流激情与欢乐。

四、此次活动，由每省找一个鸟友做本省鸟友的联系工作，并协同资讯网站共同筹划、管理此次活动。对此次活动过程，随时在资讯网站向全国鸟友报道。

欢迎大家多想点子，共同把此次活动做好。让我们有一个开心、终身难忘2003十一――画眉旅游专线游。
具体报名请到资讯论坛跟贴报名或电话0855-5221960报名。更多详情请到：http://www.chinanihao.com/cgi-bin/forums.cgi?forum=25
 

 

Re: "non-free" software included in contrib

[Pierre Machard]

On Sun, Aug 31, 2003 at 02:23:40PM +0200, Mathieu Roy wrote:
[...]
> So I do not agree that "Contrib is a ok place for installers". While
> basically these installer are free software, it's a little bit
> hypocritical to claim that these package contains free software.

From the policy :

Examples of packages which would be included in contrib or
non-US/contrib are:

* free packages which require contrib, non-free packages or packages
which are not in our archive at all for compilation or execution, and

* wrapper packages or other sorts of free accessories for non-free
programs.

In other words you do not agree with the Debian policy. It's quite
amazing since according to :

http://nm.debian.org/nmstatus.php?email=yeupou%40gnu.org

You passed the Philosophy and Procedure. 

 
> Finally, someone who install the contrib flashplugin-nonfree get on
> his computer a non-free software, possibly without even noticing it,
> because he never seen a dependancy against a package in non-free. 


This is the aim of contrib. In that case do not add contrib in your 
sources.lists and apt-get install vrms !

Cheers,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



pgpi4diiESMqW.pgp
Description: PGP signature

Re: GDM in sid does not read /etc/environment anymore

[Petter Reinholdtsen]

[Daniel Ruoso]
> I've actually sent him an email but got no answer. I've posted in
> debian-devel few days ago and nobody complained that GDM could source
> /etc/environment in the init script. That's an one-line patch (already
> tagged as patch in bts for more than a year)... 

Remember that the file /etc/environment is not a shell script, it is a
data file for the pam_env module.  The format happen to look like a
shell script, but it is not.

See for example http://linux.oreillynet.com/lpt/a/1263> for a
description of the format.

If you want to pass the values on to forked program, this might be
enough:

  for i in `cat /etc/environment`; do export $i; done

It will probably not handle space in the content.

[VAC] until september 9

[Arnaud Vandyck]

Hi all,

I'll be on holliday until september 9.

I'll unsubscribe this list and re-subscribe when I'll be back. 

Best regards,

-- 
  .''`.  ** Debian GNU/Linux **
 : :' : Arnaud   Vandyck
 `. `'   http://alioth.debian.org/users/arnaud-guest/
   `-http://alioth.debian.org/developer/diary.php?diary_user=2781
 jabber: [EMAIL PROTECTED]


pgpC7LXF4Ei2r.pgp
Description: PGP signature

Re: "non-free" software included in contrib

[Peter Makholm]

Pierre Machard <[EMAIL PROTECTED]> writes:

> In other words you do not agree with the Debian policy. It's quite
> amazing since according to :
>
> http://nm.debian.org/nmstatus.php?email=yeupou%40gnu.org
>
> You passed the Philosophy and Procedure. 

There are many developers not agreing completly with our current
policy. There is even a mailling list for those subversive people. It
is called debian-policy@lists.debian.org where they constantly discuss
changing of the policy.


Try look at the archive, quite amazing reading, don't you agree. Many
(now formely, I hope) respected developers has raised their voices at
that list.

-- 
 Peter Makholm |  I have no caps-lock but I must scream...
 [EMAIL PROTECTED] |   -- Greg
 http://hacking.dk |  

Re: /etc/shells management

[Petter Reinholdtsen]

[Bastian Blank]
> i think the scripts should follow the update-X naming schema.

I agree.  That would make it consistent of most of the Debian packages
providing such hooks.

Re: having troubles adding info to 1 and/or 2 an existing bug(s)

[Colin Watson]

On Sun, Aug 31, 2003 at 02:24:02PM +0200, Cristian Ionescu-Idbohrn wrote:
> Tried to get this info through a couple of times now, but no joy :(
> Posted to [EMAIL PROTECTED], but no answer :(

This has been dealt with now. Sorry for the delay.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: "non-free" software included in contrib

[Gustavo Noronha Silva]

Em Sun, 31 Aug 2003 14:48:46 +0200, Pierre Machard <[EMAIL PROTECTED]> escreveu:

> On Sun, Aug 31, 2003 at 02:23:40PM +0200, Mathieu Roy wrote:
> [...]
> > So I do not agree that "Contrib is a ok place for installers". While
> > basically these installer are free software, it's a little bit
> > hypocritical to claim that these package contains free software.
> 
> From the policy :
[...]
> In other words you do not agree with the Debian policy. It's quite
> amazing since according to :


While I agree with you that contrib is a good place for installers,
that is not a good reasoning. We did agree to respect the policy,
and to agree with it on our packaging work, but it does not mean
it is a holy book we cannot think about changing.

[]s!

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:   *  
Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br

control@bugs acknowledgements lost for a while

[Colin Watson]

Due to an insufficiently tested change, the copies normally sent to
package maintainers of [EMAIL PROTECTED] acknowledgements went
missing for a while. Sorry! The bug has now been fixed, but you may like
to have a look at your maintainer bug index using the web interface to
make sure that you haven't missed anything.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: "non-free" software included in contrib

[Mathieu Roy]

Gustavo Noronha Silva <[EMAIL PROTECTED]> a tapoté :

> Em Sun, 31 Aug 2003 14:48:46 +0200, Pierre Machard <[EMAIL PROTECTED]> 
> escreveu:
> 
> > On Sun, Aug 31, 2003 at 02:23:40PM +0200, Mathieu Roy wrote:
> > [...]
> > > So I do not agree that "Contrib is a ok place for installers". While
> > > basically these installer are free software, it's a little bit
> > > hypocritical to claim that these package contains free software.
> > 
> > From the policy :
> [...]
> > In other words you do not agree with the Debian policy. It's quite
> > amazing since according to :
> 
> While I agree with you that contrib is a good place for installers,
> that is not a good reasoning. We did agree to respect the policy,
> and to agree with it on our packaging work, but it does not mean
> it is a holy book we cannot think about changing.

Exactly.

I also contribute to a GNU project and follow every rules of GNU when
doing it. It does not mean that I agree with every words of RMS, it
just mean that I appreciate the GNU project a lot and when I
contribute to it, I accept the rules of the GNU project, even the
rules that I appreciate less.

The same goes for Debian. When doing something for Debian, I follow
the Debian policy. But I still keep my own judgment and keep the right
to express an opinion which may not be conform the policy.

I understand why these installers are in contrib (I said it in my
previous mail, basically they go in contrib as free software dependant
on non-free) according to the policy. If I was about to add such
package in Debian, I would add it, conform to the policy, in contrib.

But now we're discussing about it and I express my opinion: since these
packages in their postinst script install non-free stuff, I think that
even if there's no non-free stuff within the packages themselves, the
result of the installation of these packages (and not their
dependancies!) is to get non-free stuff. And so, it leads me to the
conclusion that, whatever the fact that the non-free part is downloaded
at the same time than the debian package or not, this package itself
contains non-free stuff.


Regards,


-- 
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 archive disk space requirements.

[Goswin von Brederlow]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:

> On Sat, Aug 30, 2003 at 12:18:50PM +0200, Josip Rodin wrote:
> 
>  > Pray to god that testing and unstable stop diverging so much? :)
> 
>  FYI, this is the size of all the binaries belonging to the given
>  architecture, in the specifies suites:

>  testing+testing-proposed-updates:

[resorted by size] 
>  architecture |size
> --+
>  i386 | 3378532922
>  ia64 | 3394287226
>  all  | 3113135590
>  alpha| 3050200486
>  powerpc  | 2996108486
>  hppa | 2850080658
>  sparc| 2740423638
>  s390 | 2713124396
>  arm  | 2667813072
>  m68k | 2571810596
>  mips | 2569942598
>  mipsel   | 2531507858

And people allways say that 64 Bit archs need much bigger executables.

Somehow alpha saves 328MB compared to i386 and a suggested 30-50% size
increase on binaries would mean a lot of packages are not available on
alpha, which isn't true.

Nice statistics.

MfG
Goswin

Re: LWN subscription for Debian developers

[Goswin von Brederlow]

Bdale Garbee <[EMAIL PROTECTED]> writes:

> Hello.
> 
> Last October, I announced a group subscription to lwn.net for Debian 
> developers, sponsored by HP.  I've recently received numerous queries 
> about whether this "deal" was still available, and/or whether HP intended
> to continue sponsoring the subscription.  
> 
> The answer to both questions is yes!

What about NMs?

MfG
Goswin

ruby-defauls and ruby1.6 go into unstable

[Fumitoshi UKAI]

Hi,

Today, ruby-defaults and ruby1.6 packages move queue/new to queue/accepted,
so ruby-defaults and ruby1.6 will go into unstable.

I'll change the default version of ruby in unstable to 1.8 next week,
because Sept 15th is the day of "Last major changes to major packages uploaded
to unstable", according to current sarge release dateline.

Regards,
Fumitoshi UKAI

个性化经理通讯录 客户数据 非常准确

[my1183]

使用准确客户通讯录，绕开秘书，直接找到负责人。   
包括总经理、人事、财务、技术 、销售等部门经理.   
内容详细、准确包括:姓名、单位、职务、电话、传真、邮编、email、

 个性化名录（A4纸打印件）
  
 北京职业经理人名单，中国部分大中型企业经理名单
 中国各地部分人事经理、培训专员名录  证券、电信、铁路各类管理人员
 中国民营企业500强名单   IT信息业代理商、客户
 企业、学校设备采购、网络负责人. 北京市写字楼入住单位名单
 经理培训班、会议参会人员通讯录. 
 
 重点介绍   
  
 
最新全国企业名录，区别于目前市场上所有的名录光盘，开放式数据库，可以自由添加删除，总量700万家，2003年完成。准确率75％以上
 普通个人消费者信息，只允许用于市场调查 直投 邮购销售。
  
 普通名录

  全国31个省市41个行业名录 中国拟建和在建项目数据库 
(工程信息与甲方乙方负责人简历联系方法)
  中国医院大全 美国进口商综合版 
  北京工商信息总揽 中国拟在建项目汇编   

  跨国公司驻华代表处,中国分公司2003北京最新注册企业名录 
(截至2003年4月注册企业,有注册时间)   
  
  特价名录 
 
  中国上网企业数据库 （原价560元，现价98元）
世界500强中国投资企业（原价 480元 现价98元）
  中国大黄页 （100元）  北京企事业名录光盘 
最新（240元）
  

  email群发软件（100元）  
每小时发送成功1-2万email,可以发送文件、图片、甚至网站，客户打开邮件看见的就是你的网址。
 

 email搜索软件（100元）   
可以指定关键词搜索如：经理、北京、建材等，搜出的email就是跟经理、北京、建材有关的email,

  还可以搜索两个以上的关键词如：北京 
公司，搜出的就是各种北京公司的email.
  
 网址email扫描软件,（100元）   可以扫描sohu、163等任何网站下的email. 
全套软件260元，赠送邮件地址。
 （负责安装，调试，技术指导）
 IP地址信息轰炸机 (160元）
可以以消息框的形势弹出，不像垃圾邮件一样被人反感。

 传真群发软件 （180元）
下班之前设置好传真列表，按动鼠标，传真就会通宵自动发送。

 了解更详细情况登陆   www.great2008.com, 拨打 010 82784384 13671269551  许阳
 
 回复请用 [EMAIL PROTECTED],[EMAIL PROTECTED]
　
　北京准确客户名录  

Re: debian archive disk space requirements.

[Steve Langasek]

On Sun, Aug 31, 2003 at 04:27:57PM +0200, Goswin von Brederlow wrote:
> "Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:
> 
> > On Sat, Aug 30, 2003 at 12:18:50PM +0200, Josip Rodin wrote:
> > 
> >  > Pray to god that testing and unstable stop diverging so much? :)
> > 
> >  FYI, this is the size of all the binaries belonging to the given
> >  architecture, in the specifies suites:
> 
> >  testing+testing-proposed-updates:
> 
> [resorted by size] 
> >  architecture |size
> > --+
> >  i386 | 3378532922
> >  ia64 | 3394287226
> >  all  | 3113135590
> >  alpha| 3050200486
> >  powerpc  | 2996108486
> >  hppa | 2850080658
> >  sparc| 2740423638
> >  s390 | 2713124396
> >  arm  | 2667813072
> >  m68k | 2571810596
> >  mips | 2569942598
> >  mipsel   | 2531507858

> And people allways say that 64 Bit archs need much bigger executables.

> Somehow alpha saves 328MB compared to i386 and a suggested 30-50% size
> increase on binaries would mean a lot of packages are not available on
> alpha, which isn't true.

It probably achieves this through the cunning, space-saving strategy of
rendering poorly written software un-buildable on 64-bit architectures.
;)

-- 
Steve Langasek
postmodern programmer


pgphhS2my5DS9.pgp
Description: PGP signature

Re: "non-free" software included in contrib

[Bruce Sass]

On Sun, 31 Aug 2003, Mathieu Roy wrote:
<...>
> But now we're discussing about it and I express my opinion: since these
> packages in their postinst script install non-free stuff, I think that
> even if there's no non-free stuff within the packages themselves, the
> result of the installation of these packages (and not their
> dependancies!) is to get non-free stuff. And so, it leads me to the
> conclusion that, whatever the fact that the non-free part is downloaded
> at the same time than the debian package or not, this package itself
> contains non-free stuff.

When your conclusion is at odds with reality you should rethink your
argument... if Debian was to start classifying packages based on
the probable or possible results of using the package, instead of
the code in the package itself, contrib would disappear and a case
could be made to place all editors in non-free because they can be
used to create non-free stuff.


- Bruce

Re: debian archive disk space requirements.

[Marcelo E. Magallon]

On Sun, Aug 31, 2003 at 04:27:57PM +0200, Goswin von Brederlow wrote:

 > And people allways say that 64 Bit archs need much bigger executables.
 > 
 > Somehow alpha saves 328MB compared to i386 and a suggested 30-50% size
 > increase on binaries would mean a lot of packages are not available on
 > alpha, which isn't true.

 Interesting theory...

 architecture |size| count
--++---
 mipsel   | 2531507858 |  7022
 mips | 2569942598 |  7041
 m68k | 2571810596 |  7267
 arm  | 2667813072 |  7272
 s390 | 2713124396 |  7259
 sparc| 2740423638 |  7292
 hppa | 2850080658 |  7104
 powerpc  | 2996108486 |  7379
 alpha| 3050200486 |  7283
 i386 | 3378532922 |  7889
 ia64 | 3394287226 |  7204

 Funny that the count difference is so large... let me double check:

[EMAIL PROTECTED]:dists$ zcat 
testing{,-proposed-updates}/{main,contrib,non-free}/binary-alpha/Packages.gz | 
grep-dctrl -s Package -F Architecture -v all | wc -l
   7283
[EMAIL PROTECTED]:dists$ zcat 
testing{,-proposed-updates}/{main,contrib,non-free}/binary-i386/Packages.gz | 
grep-dctrl -s Package -F Architecture -v all | wc -l
   7889

 Yup.

-- 
Marcelo

Re: LWN subscription for Debian developers

[Wouter Verhelst]

On Sun, Aug 31, 2003 at 04:33:22PM +0200, Goswin von Brederlow wrote:
> Bdale Garbee <[EMAIL PROTECTED]> writes:
> 
> > Hello.
> > 
> > Last October, I announced a group subscription to lwn.net for Debian 
> > developers, sponsored by HP.  I've recently received numerous queries 
> > about whether this "deal" was still available, and/or whether HP intended
> > to continue sponsoring the subscription.  
> > 
> > The answer to both questions is yes!
> 
> What about NMs?

Wait until you can drop the N, I guess.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.

Re: debian archive disk space requirements.

[Joshua Kwan]

On Sun, Aug 31, 2003 at 09:05:24PM +0200, Marcelo E. Magallon wrote:
>  Funny that the count difference is so large... let me double check:
> 
> [EMAIL PROTECTED]:dists$ zcat 
> testing{,-proposed-updates}/{main,contrib,non-free}/binary-alpha/Packages.gz 
> | grep-dctrl -s Package -F Architecture -v all | wc -l
>7283
> [EMAIL PROTECTED]:dists$ zcat 
> testing{,-proposed-updates}/{main,contrib,non-free}/binary-i386/Packages.gz | 
> grep-dctrl -s Package -F Architecture -v all | wc -l
>7889
> 
>  Yup.

I'd not include non-free in the batch because many non-free on i386 are
i386 only, i.e. binary driver installers.

What does it look like then?

-- 
Joshua Kwan


pgpyJn00Sb8qd.pgp
Description: PGP signature

Re: debian archive disk space requirements.

[Marcelo E. Magallon]

On Sun, Aug 31, 2003 at 12:56:19PM -0700, Joshua Kwan wrote:

 > > [alpha]7283
 > > [i386] 7889
 > 
 > I'd not include non-free in the batch because many non-free on i386 are
 > i386 only, i.e. binary driver installers.

 Ah, well spotted, but still there's some significant difference:

[EMAIL PROTECTED]:~/ftp/dists$ zcat 
testing{,-proposed-updates}/main/binary-alpha/Packages.gz | grep-dctrl -s 
Package -F Architecture -v all | wc -l
   7105
[EMAIL PROTECTED]:~/ftp/dists$ zcat 
testing{,-proposed-updates}/main/binary-i386/Packages.gz | grep-dctrl -s 
Package -F Architecture -v all | wc -l
   7628

 A lot of that is due to the gazillion kernel flavors and their modules,
 some compilers, some sensors and sensor-related stuff, a few acpi
 packages, old libc5 stuff, and the good old "uh?" stuff (firebird for
 example).

-- 
Marcelo

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Riku Voipio]

On Sat, Aug 30, 2003 at 11:49:40PM +, Brian May wrote:
> 2. All checks have to be automatic, and there is no chance of manual
> review to ensure that the messages where geniune before bouncing it.

Actually, I'm pretty sure SA is statistically better than an average
person scanning subject lines of an unfiltered inbox. And if a real 
user gets his message bounced as spam, he/she has a chance to retry 
the message via some alternative transport, like POTS or snailmail,
instead of getting the message buried in the reciepents spam folder.

-- 
Riku Voipio|[EMAIL PROTECTED] |
kirkkonummentie 33 |+358 40 8476974  --+--
02140 Espoo|   |
dark> A bad analogy is like leaky screwdriver  |


pgpBxKSYrZ0ON.pgp
Description: PGP signature

Re: debian archive disk space requirements.

[Joey Hess]

Goswin von Brederlow wrote:
> And people allways say that 64 Bit archs need much bigger executables.

But the numbers quoted are for compressed executables.

-- 
see shy jo


pgpJrjjbpIoUt.pgp
Description: PGP signature

BLOCKED ATTACHMENT (Replaced with text)

[Exchange Administrator]

* eManager Notification **

Your message contained an attachment type that has been blocked in order to 
prevent *potential* viruses from entering Attachmate's mail servers.  The best 
method for sending file attachments to Attachmate employees is to compress the 
file and send it as a .ZIP file.  If you have any questions, you can contact 
the intended Attachmate recipient for more information.

Destination mailbox(es): [EMAIL PROTECTED]
Policy: Replaced with text
Attachment file name: your_details.pif - application/octet-stream
Action: Attachment Removal

*** End of message ***

Re: "non-free" software included in contrib

[Matthew Palmer]

On Sun, Aug 31, 2003 at 12:47:11PM -0600, Bruce Sass wrote:
> On Sun, 31 Aug 2003, Mathieu Roy wrote:
> <...>
> > But now we're discussing about it and I express my opinion: since these
> > packages in their postinst script install non-free stuff, I think that
> > even if there's no non-free stuff within the packages themselves, the
> > result of the installation of these packages (and not their
> > dependancies!) is to get non-free stuff. And so, it leads me to the
> > conclusion that, whatever the fact that the non-free part is downloaded
> > at the same time than the debian package or not, this package itself
> > contains non-free stuff.
> 
> When your conclusion is at odds with reality you should rethink your
> argument... if Debian was to start classifying packages based on
> the probable or possible results of using the package, instead of
> the code in the package itself, contrib would disappear and a case
> could be made to place all editors in non-free because they can be
> used to create non-free stuff.

Ah, reductio ad absurdum.  Such a wonderful means of demonstrating that you
can't think up a decent argument, so you'll take something to it's illogical
extreme to try and scare some people.

To address the original point, however:

I do believe that policy is correct in it's reasoning in this instance.  By
my understanding, packages go into contrib for one of three reasons:

1) They strictly depend on non-free software;

2) They build-depend on non-free software, but otherwise depend entirely on
free software; or

3) They install non-free software.

In each case, the actual contents of the package itself is DFSG-free.

Apart from item (2), which I can't think of a major example of at present
(OOo is in main because they just don't build the Java parts, AIUI), all of
the software in contrib is there because correctly installing the binary
package will result in non-free software on your system, either because it
depends on it or because it will install it (as part of postinst or via an
install script).

The mechanism by which the non-free software will come to be on your system
(by hook or by crook, as it were) isn't a fundamental difference, IMO.

- Matt

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Karsten M. Self]

on Sat, Aug 30, 2003 at 09:41:39PM -0500, John Hasler ([EMAIL PROTECTED]) wrote:
> I wrote:
> > This is about a quarter of my incoming mail.
> 
> Karsten writes:
> > Which?  Bounces to spoofed senders, or improperly addressed mail?
> 
> Bounces.

Thanks.

> > What prevents you from 550ing this at SMTP connect?
> 
> The absence of any such connections.  I'm on a dialup.

Fair enough.  I'm in the same boat.

Peace.

-- 
Karsten M. Self http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
   A guide to GNU/Linux browsers:
 http://twiki.iwethey.org/twiki/Main/NixBrowsers


pgpYbdiLuITO6.pgp
Description: PGP signature

Debian Linux kernel for sh4

[丛明]

Hi！
   Thank for your repeat. I have a question this time :
I went to build the Debian Linux OS on sh4 target board and add IPv6 on 
this OS. I knew that the Debian Linux has done some change aginst the stand 
kernel, where can I find the source of Debian Linux kernel 2.4.18 for sh4?

Thank you


　　　Best Regard!


Cong Ming
[EMAIL 
PROTECTED]
　  　2003-09-01

Re: MEI Whitelist Autoresponse

[Andrew Pollock]

On Sat, Aug 30, 2003 at 01:45:18PM +0300, Richard Braakman wrote:
> 
> I think virus scanners are in a different class, though.  Mailing list
> software isn't designed to recognize viruses, while virus scanners are.
> It's disgustingly incompetent to recognize a mail as Sobig.F, which is
> known to fake the sender, and then reply to it anyway.  (And yes, I
> get a lot of "notifications" that mention Sobig.F by name.)

The (granted, commercial) SMTP virus scanners that I've had experience
with don't allow you to modify the notification behavior on a per virus
signature basis, it's either all on or all off.

Andrew


pgpfYuxEA3y0C.pgp
Description: PGP signature

Re: MEI Whitelist Autoresponse

[John Hasler]

Andrew writes:
> The (granted, commercial) SMTP virus scanners that I've had experience
> with don't allow you to modify the notification behavior on a per virus
> signature basis, it's either all on or all off.

The signature file sent out by the vendor should tell the scanner whether
or not to send notices.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: "non-free" software included in contrib

[Steve Langasek]

On Mon, Sep 01, 2003 at 09:47:46AM +1000, Matthew Palmer wrote:

> To address the original point, however:

> I do believe that policy is correct in it's reasoning in this instance.  By
> my understanding, packages go into contrib for one of three reasons:

> 1) They strictly depend on non-free software;

> 2) They build-depend on non-free software, but otherwise depend entirely on
> free software; or

> 3) They install non-free software.

> In each case, the actual contents of the package itself is DFSG-free.

> Apart from item (2), which I can't think of a major example of at present
> (OOo is in main because they just don't build the Java parts, AIUI),

Still in contrib, last I knew.

> The mechanism by which the non-free software will come to be on your system
> (by hook or by crook, as it were) isn't a fundamental difference, IMO.

The fundamental difference is that, in your first two cases above,
you're actually installing some free software that has value of its own
and presumably would be moved to main if the non-free software it
depended on was reimplemented or otherwise freed; whereas in the third
case, the free software is only useful *so long as* the non-free
software in question is non-free.

-- 
Steve Langasek
postmodern programmer


pgpM2AKNJ3kOJ.pgp
Description: PGP signature

Re: "non-free" software included in contrib

[Matthew Palmer]

On Sun, Aug 31, 2003 at 08:45:37PM -0500, Steve Langasek wrote:
> > Apart from item (2), which I can't think of a major example of at present
> > (OOo is in main because they just don't build the Java parts, AIUI),
> 
> Still in contrib, last I knew.

Whoops, it is too.  I thought I'd left contrib and non-free off the sources
list on this box.  Seems I didn't.  Bad assumption on my part for that one.

> > The mechanism by which the non-free software will come to be on your system
> > (by hook or by crook, as it were) isn't a fundamental difference, IMO.
> 
> The fundamental difference is that, in your first two cases above,
> you're actually installing some free software that has value of its own
> and presumably would be moved to main if the non-free software it
> depended on was reimplemented or otherwise freed; whereas in the third
> case, the free software is only useful *so long as* the non-free
> software in question is non-free.

Indeed.  However, the point I was refuting was that installers shouldn't be
in contrib because they caused non-free software to appear on the user's
system.  I was merely pointing out that there is no substantive difference
in that point between non-free dependencies and installers.

Personally, I'd love it if installers could go away because the software
became DFSG-free and so could be packaged directly.  But, the unfortunate
reality is that it isn't at present, and installer packages are a reasonable
compromise between effectively telling our users "no, you can't manage that
software using dpkg" and compromising the DFSG.

I don't know if the presence of installers encourages or discourages the OSS
implementation of various pieces of non-free software.  I'm leaning towards
the not case, though.

- Matt

Re: Accepted kaffe 1:1.1.1-1 (i386 source)

[Herbert Xu]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>
>> Well the credit should definitely be directed at the submitter.  The
>> blame however is squarely at the feet of the maintainer.
> 
> This is not at all the case.  A large percentage of patches that I apply to
> my packages are done more or less blindly.  Specifically, the message
> translations.

This might be OK for translations.  But for anything else, if something
goes wrong, then it's the maintainer's fault since he is the one who
decided to let the patch in.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Craig Sanders]

On Sat, Aug 30, 2003 at 10:42:17AM +1000, Brian May wrote:
> On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote:
> > the point that you keep on missing is that TMDA and similar programs send
> > "confirmation" emails to innocent third-parties who did *NOT* send an
> > email.
> > 
> > TMDA and all C-R systems are broken-by-design, just as many stupid end-user
> > "autoresponders" and AV-scanners that send notifications back to the forged
> > sender address are broken-by-design.
> 
> You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail
> addresses is also broken?

no, i am not saying that.

> That is the idea behind autorespoonders after all, to tell the sender
> that his mail didn't get through because it didn't meet some required
> criteria.

the difference are :

1. a bounce is NOT the same thing as generating a new "notification" or
"confirmation" message.


2. with modern MTAs that can reject mail from spammers/spamware/viruses during
the SMTP session, there is no bounce message at all.  by issuing a "5xx" reject
code during the smtp session, it leaves the task of bouncing the message up to
the senderand very few (none, to my knowledge) virus or spamware programs
have any code at all to send bounces.  they just ignore the reject and move on
to spamming the next victim address.

this is beneficial both to the mail server itself (which is not clogged up with
thousands of undeliverable bounces) and also to the poor bastard who has had
their address forged by spamware or virus.

reasons for rejecting during the smtp session include: unknown recipient, relay
access denied, blacklisting (open relay, dialup/dynamic pool, known spam domain
etc), local policies (message size, quota, etc), obvious spam/virus (e.g.
content-filtering) and many others.


3. it is reasonable and correct for an MTA to assume that the sender
address is correct.  that is its job.

it is not at all reasonable for an anti-virus or anti-spam system to make that
assumption - almost all spam and most viruses are "from" forged addresses.
this has been known for years, it is absolutely inexcusable that any anti-virus
or anti-spam tool has been programmed without this knowledge in mind.


4. if an anti-virus or anti-spam mail system can NOT reject the mail during the
smtp session then it MUST NOT send any notification/bounce back to the sender.
the correct thing to do is to either tag the message and deliver it to the
recipient address (perhaps after removing or de-fanging any virus), or to
quarrantine it (and optionally send the *recipient* a notification message, or
just let them check their quarranitine box every so often).



> The other option which many people seem to want is to discard the E-Mail
> without giving either party any indication of what happened.
>
> E-Mail that looks suspicious can be valid mail at times, for instance
> somebody I knew tried to send a ZIP file that happened to be executable via
> E-Mail.
> 
> Do you simply discard such E-Mails (which gives no indication that something
> went wrong), or do you try to contact the sender to indicate that something
> went wrong?

the answer to this is obvious:

you reject it and leave it up to the sending mta/client to deal with it.

if the sender is spamware or virus, there won't be any bounce message (nor
should there be).

if the sender is a legitimate client, then the user will be notified (usually
via a dialog box) and the message will stay in the outbound queue or be bounced
to the inbox or an error mbox.

if the sender is a mail server, then it will bounce the message back
to the original sender.  if it was a legitimate email that bounced (e.g. 
unknown recipient) then that is what is supposed to happen.  the only time this
is a problem is when the sending MTA is an open relay, and the address was 
forged.
there isn't much that can be done about that, however bounces from an open
relay server will be rejected by any MTA that uses an open-relay blacklist (so 
no
bounce will be delivered to the forged address).


> One approach for instance would be to modify the SMTP standard, and say if a
> host accepts the E-Mail then it is guaranteed to get it to the destination
> (ie. it signal OK until the message has been delivered), but that would break
> store-and-forward capabilities of secondary mail servers.

that is pretty much the standard now, except that a host which accepts a
message MUST either deliver it (directly or forward it on to the next hop), or
it MUST bounce it.

that word "accept" is crucial, however.  if you don't accept the message (i.e.
if you reject it with a 5xx reject code) then it's not your responsibility to
either deliver or bounce it...it is the responsibility of the sending client or
server.

> Even encryption does not help here, or at least I have not seen any proposals
> for any system that could scale to the Internet. GPG for instance only
> verifies the sender to the receiver, it could not be used to verify every

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Craig Sanders]

On Sat, Aug 30, 2003 at 04:01:19PM +1000, Russell Coker wrote:
> Backup MX servers serve no useful purpose in the modern Internet, this is why 
> big sites such as microsoft.com and hotmail.com don't have them.

agreed.

> If you have a backup MX then it should know all the acceptable email
> addresses in your domain and enforce all rules regarding acceptable content.
> Then it can block content through SMTP 550 and 450 codes.

yes.

if you don't have 100% administrative control over your backup MX server(s) 
then you
should NOT be using them.


craig

Re: Bug#207300: tmda: Challenge-response is fundamentally broken

[Craig Sanders]

On Sat, Aug 30, 2003 at 11:49:40PM +, Brian May wrote:
> On Sat, Aug 30, 2003 at 04:01:19PM +1000, Russell Coker wrote:
> > > That is the idea behind autorespoonders after all, to tell the sender
> > > that his mail didn't get through because it didn't meet some required
> > > criteria.
> > 
> > A SMTP 550 code can convey all the information that is needed for bounces.
> 
> There are two problems with this.
> 
> 1. The modular design of SMTP agents like postfix do not allow 
> scanning of messages before the message has been accepted by the
> MTA at the SMTP session. I think you would have to add hooks
> into smtpd, but that is going to complicate the code.

not true.

postfix header_checks and body_checks check the message *before* it is accepted
by the MTA.  if it fails the test, a final 5xx reject code is issued rather
than a 2xx "accepted" code.


recent experimental versions of postfix also allow the same thing to be
done with content-filters, although use of this feature is not recommended
by Wietse due to the time it takes for a filter like spamassassin to run - there
is a risk of smtp timeouts, especially on busy servers.


> 2. All checks have to be automatic, and there is no chance of manual
> review to ensure that the messages where geniune before bouncing it.
> 
> The list of known solutions follows:
> 
> (nil)

actually, the known solution is:

 - reject if you possibly can, tag and deliver otherwise.

craig