The sense of automake (Was: Processed: better make that 1.7.8... :-()

[Andreas Tille]

Hi,

regarding to bug #215554 I would like to ask for my personal clarification:
Which sens makes automake if the resulting output depends from every new
subsubversion?

I've thought that I would do the wordnet program some good if I would add
automake stuff.  Since I switched to auotmake1.7 I have continous trouble
with subsubversion dependencies which now convinced me that I had a really
stupid idea.  Is there any reason for this trouble I could understand?

If not I would revert my changes and will go back to just patching the
brocken upstream Makefiles.

Kind regards

 Andreas.

-- Forwarded message --
Date: Mon, 13 Oct 2003 10:33:19 -0500
From: Debian Bug Tracking System <[EMAIL PROTECTED]>
To: LaMont Jones <[EMAIL PROTECTED]>
Cc: Andreas Tille <[EMAIL PROTECTED]>
Subject: Processed: better make that 1.7.8... :-(

Processing commands for [EMAIL PROTECTED]:

> reopen 215554
Bug#215554: wordnet doesn't build from source
Bug reopened, originator not changed.

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

急招兼职

[网络兼职]

亲爱的朋友: 您好!你的人生成功吗?你渴望您的事业飞黄腾达吗?我就渴望. 当
我22岁的生日还要用妈妈的钱买生日蛋糕的时候,说真的,我恨自己, 人生能有几
个20岁?我怎么能还在花父母的血汗钱,怎么能没有自己的理想, 没有自己的事业,没
有自己的未来?我想到,未来是否有属于我的一块土地,一片蓝天, 一个生活在我的声誉
和气息下的群体?学生可在校兼职，每星期安排一些时间在网上宣传即可））） 当一
切还在迷惘,当事业的脚步原地徘徊的时候,我找到了即将而且正在改变我一生的SOHO商务
网 http://money66.com/soho/index.asp?user= 我义不容辞的加入了它, 成为它的代
理同时也完成了本人次生的第一笔投资.我立刻变的富有,我拥有了一个独立的自我的网站,
在我的网站上代理商品,提取30%的高额回报.我还可以为他人做广告来增加我的收入, 
可以得
到SOHO成功手册,学习他的真谛,创建以我为中心的电子列表,得到只有我们会员才可以享用的
最新的网络营销软件,同时我也得到了我下线为了获得和我一样的网站而向我支付酬金的权利.
 
一切就是这么简单,自然.在这里,你会找到事业的起步点,"天生我才必有用"以我们的勤劳, 
以
我们的智慧,以我们的坚韧不拔,生命的支点由此抬高,社会的地位由此改变! 一起向前吧! 
进入
我的网站,注册您的销售系统.
 http://money66.com/soho/index.asp?user= 
祝:事业有成,
财源滚滚!! 站长:树 有问题给我留言，一定帮助你 QQ:34777332
http://54king.com/club/bbs.cgi?id=  
我的个人论坛，有任何问题发帖子，会有很多人帮助你   
 (您的发展就是我的事业) 据我
们调查,每一百人登陆您的网站就会有一人加入,如果你勤劳,你每天可以发上万封邮件(用我们为

准备的软件),也可以用QQ,论坛发帖,效果都很好呦 

SOHO（SmallOfficeHomeOffice），起源于美
国八十年代中后期，意即"小型家庭办公室"
，也就是说，将办公场所放在家里或独自租用一个办公室。这种职业观自兴起后，迅速风靡
全球的经济发达地区。现如今，SOHO一词在中国也流行起来。1997年是一道分界线，之前，由于经济发展水平有限，国内SOHO市场尚未形成一定规模。之后，随着网络的普及和家庭办公概念的深入人心，家庭办公成为一种可行的选择，SOHO
 一族的群体不断扩大，SOHO市场得到迅速发展。 

Re: Hardcoding of .la file paths in .la files

[Josselin Mouette]

Le lun 13/10/2003 à 22:19, Steve Langasek a écrit :

> > You're right as for static linking, I thought pkg-config supported
> > --static while it doesn't. Well, maybe it is better that way; I
> > personally feel we should deprecate the whole static linking stuff.
> 
> In which case, we could easily fix all libtool installations by simply
> removing the .la files altogether, and we'll never have any more
> problems with mislinked dynamic executables or libraries.

Indeed.

> But if we're going to do that, then most of the available pkg-config
> settings are *still* wrong; in the above instance, the correct answer
> for dynamic linking is '-Wl,--export-dynamic -lgnomecanvas-2', and lose
> the other 50 entries on that line.

Of course, that means fixing many broken pkg-config files. I don't know
if we can do completely without them, as there are some (e.g. XFree86)
libraries which are still available only in static format.

> Both of these tools are designed primarily to solve problems that do not
> affect stock Debian packages.  We are not part of their target userbase,
> and as such, the tools are suboptimal for what we're trying to achieve.

Just like the whole auto* stuff.

I really feel we should get rid of all these static libraries. Who uses
static linking now that even our glibc doesn't support it correctly
across versions?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=

Re: Hardcoding of .la file paths in .la files

[Daniel Kobras]

On Tue, Oct 14, 2003 at 09:52:28AM +0200, Josselin Mouette wrote:
> I really feel we should get rid of all these static libraries. Who uses
> static linking now that even our glibc doesn't support it correctly
> across versions?

People who want their binaries to run across different Linux machines.
People who don't want to keep up with rapidly changing library APIs.
People who want to have reliable emergency recovery tools available.
People who use performance critical libs on register-starved machines.
People who need to minimize startup times.

To name but a few. Just because there's little incentive to use static
linkage when building Debian packages doesn't mean that we should
deprecate it. Unless you're willing to convince the admin of the
beowulf cluster next door to install libyoddafoo on several hundred
nodes for me.

Daniel.

Re: faster boot

[Gerrit Pape]

On Mon, Oct 13, 2003 at 12:05:24PM +0200, Andrea Mennucc wrote:
> there has been a lot of interest lately on tecniques to obtain a faster 
> boot; for example
[...]
> http://www.fefe.de/minit/
[...]
> is anyone trying to implement the above in Debian?

I've implemented the runit package, somewhat similar to minit, modeled
on the daemontools' service management concept, and available in Debian
sarge and sid:

 http://packages.debian.org/runit
 http://packages.debian.org/runit-run

But it's not a drop-in replacement for sysvinit as it's not compatible
with normal init scripts.  You may be interested though.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.

which policy checker?

[Magosányi Árpád]

Hi!

Which policy checker should I use?

Lintian apparently does not know about the new policy version.
#194257: lintian: Policy version 3.6.1.0 has been released
Package: lintian; Reported by: Jay Bonci <[EMAIL PROTECTED]>; 145 days old.

Linda apparently does not know about the new policy version.
It isn't even reported as a bug (filing it right now).

Do any of them check the package anyway?

-- 
GNU GPL: csak tiszta forrásból

Office2000增值软件

[office]

debian-devel:您好!
 向您推荐几款Office2000增值软件

推荐一
软件名称：Office2000财务系统
软件简介：
   
本套财务软件与微软Office2000系统紧密集成，包括帐务,报表等部分，帐务部分包括凭证管理、账簿
查询，辅助管理、系统管理等主要功能，具有符合财务工作习惯、使用简便、上手快等优点。具有数量核算、
外币核算、银行对帐、部门及个人核算、项目管理等辅助核算功能，并且融入了微软Office2000自动感知技术
等先进性能，具有完善的数据备份和恢复功能，保证财务数据的绝对安全。细致的权限管理功能使您可以对使
用人员分配不同的操作权限，预设总账科目及部分明细科目，期初设置简便，财务功能完善，可自动生成资产
负债表、损益表、现金流量表，特别适合中小企业使用。 

免费下载：
http://www.newhua.com/soft/4952.htm

―――
推荐二
软件名称：Office2000老板理财(进销存)
软件简介：
 
进销存财四位一体，特别为中小企业设计，它的功能范围包括货品管理、资金管理、债权债务管理，并
配备有功能完整、全面的经营报告系统。具有超强穿透力的查询功能，使您可以追溯到发生过的任何一笔业
务，是许多同类软件无法比拟的。革命性的自动记忆功能使您无需任何繁琐的期初设置，安装后马上可以开始
使用，是一款即装即用的软件。它的功能覆盖了中小型企业财务管理和货品进销存管理的方方面面，是一款非
常实用的软件。赶快下载吧，您将体验到强大功能与简单操作的完美结合！

免费下载：
http://www.onlinedown.net/soft/5959.htm


推荐三
软件名称：Office2000人事工资
软件简介：

　本系统简单易用，可方便的帮助你对人员状况和人员工资的管理。直观而强大的查询功 
能方便您对人
员各种信息的统计要求，协助您完成各种人事报表。工资管理方面，可自定义 
工资项目及公式方便您对工资
数据的处理。统一的打印格式使您可以简单的建立起自己的人 
事和工资数据系统。此外，系统还有输出银行
转账单功能和群发邮件工资单功能，方便您处 理工资发放工作。 
  另外，数据库已经加密处理，保证您的数据安全性、保密性，而且备份方便。 

免费下载： 
http://www.onlinedown.net/soft/15683.htm


致
礼!
  　
  　
  　　 2003-10-14

Re: which policy checker?

[Andreas Metzler]

Magosányi Árpád <[EMAIL PROTECTED]> wrote:
> Which policy checker should I use?

> Lintian apparently does not know about the new policy version.
> #194257: lintian: Policy version 3.6.1.0 has been released
> Package: lintian; Reported by: Jay Bonci <[EMAIL PROTECTED]>; 145 days old.

> Linda apparently does not know about the new policy version.
> It isn't even reported as a bug (filing it right now).

> Do any of them check the package anyway?

Sure. They are just warning you that some of the tests might not be
entirely correct, as the programs don't know the most recent changes.
  cu andreas

Re: Re: Virus emails

[Steve Saks]

Title: Message



MS Corporation Security Center 
[EMAIL PROTECTED]

Re: Packaging sysfsutils: static library?

[Martin Pitt]

Hi!

On 2003-10-13 21:08 +0200, Martin Pitt wrote:
> I sent a mail to upstream two days ago, but didn't receive an answer
> yet. I will wait with uploading (or rather, looking for a sponsor)
> until I get an answer or run out of patience (maybe after a week of
> silence).

FYI: I just got an answer from upstream. They are planning to release
0.3 next week. They will probably support a shared lib, and the
interface of 0.3 is supposed to be relatively stable.

Thus I will not upload the current package, but wait until next week.

Martin
-- 
Martin Pitt
home:  www.piware.de
eMail: [EMAIL PROTECTED]

Re: Simplicity Pattern Co. AutoReply

[Andrew Lau]

Dear Cindy/Robert

On Mon, Oct 13, 2003 at 03:32:23PM -0400, Robert Bulick wrote:
> I purchased "NEW LOOK HIS & HERS" Pattern # 6307.  The front pattern
> piece for all of the fronts for the tops was missing.  I'm going to
> Wal Mart to get another one, but thought I should let you know what
> happened.
> 
> Thank you,
> 
> Cindy Bulick

But did you hundreds of people on debian-devel have to know? *sigh*
Watch your CC: headers for crying out loud.

Yours sincerely,
Andrew "Netsnipe" Lau

-- 
***
 Andrew "Netsnipe" LauComputer Sci. UNSW & Debian GNU/Linux
   
   GnuPG 1024D/2E8B68BD:  0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD
   -
"Nobody expects the Debian Inquisition! 
   Our two weapons are fear and surprise...and ruthless efficiency!"
***


signature.asc
Description: Digital signature

Bug#215728: ITP: gngeogui -- GTK GUI-frontend for gngeo

[Julien Delange]

Package: wnpp
Severity: wishlist

* Package name: gngeogui
  Version : 0.1
  Upstream Author : Julien Delange <[EMAIL PROTECTED]>
* URL : http://gunnm.org/~soda/softwares/gngeogui
* License : GPL
  Description : GTK GUI-frontend for gngeo

gngeogui is a GUI-Frontend to gngeo writed in Perl language. So, it 
works on many computers. It can configure gngeo, and show all roms,
which are stored in a directory. It shows screenshot of each game.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux evira 2.6.0-test5 #11 SMP Sun Oct 12 17:52:52 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: which policy checker?

[Steve Kowalik]

At  6:46 pm, Tuesday, October 14 2003, Magos?nyi ?rp?d mumbled:
> Linda apparently does not know about the new policy version.
> It isn't even reported as a bug (filing it right now).
> 
It does! Stop spreading lies, Linda 0.2.21 deals with Policy 3.6.1
correctly, but does not drop to testing immediately.

Cheers,
-- 
   Steve
In the beginning was the word, and the word was content-type: text/plain

Re: Bug#202244 Speak-freely Removed from Debian

[Hamish]

> This package has been removed from Debian unstable because it is
> orphaned upstream and has reached its end-of-life.


Speak-freely is not abandoned and should remain in Debian.


It was orphaned upstream, but it has NOT reached its end-of-life.

Development has moved to http://speak-freely.sourceforge.net/

and it has been taken over by new developers who are listed here:
http://sourceforge.net/project/memberlist.php?group_id=87107


Speak-freely is a mature, stable program that works very well. Change of
upstream maintainers is quite irrelevant. The (fourmilab) mailing list
is still very active, receiving several messages a day last time I
checked. The program works well today, and will work well next year.


For the very reasons that John mentions in his "End of Life Announcement"[*]
I think it very important that speak-freely *STAYS* in Debian. The world 
needs a Free cross-platform VoIP program that will let a 486 in Mongolia 
on a crummy copper wire communicate with a broadband connected machine in 
London. X-Windows, anti-aliased toolkits, & broadband should not be a 
requirement as are needed with the available alternatives. The answer is 
surely not rolling over and giving up because of nefarious designs by 
some US corporates.
[*] http://www.fourmilab.ch/speakfree/

With the new version (7.6a) recently out, this package is both secure
and bug free for the most part. Also the new version removes the IDEA
code that was keeping this package in non-us/non-free and will allow
compilation with full duplex support (debian bug #24,674 from 1998!).


If you do not wish to maintain the package anymore please orphan it
instead of just removing it without warning. It's a simple package, I'm
sure someone else could take it up without too much of a burden (maybe
one of the Ham radio folk). Johannes has already gone to the trouble of
putting together a new package for it for Bob's sake!
(see this bug's log at http://bugs.debian.org/202244 for the package)



It's small, it works, it fills an important niche, people use it, it's
not woefully out of date (upstream anyway), I really don't see why it
should be removed.




regards,
Hamish


ps-
Where I am at the end of the world, we pay $0.25/megabyte for our
internet usage, on top of monthly and annual fees. The phone charges are
just as bad and I actually get better sound quality using Speak-freely.
Through two firewalls, NAT, and the cable modem cartels at the other end
even.

Re: Anyone interested in libical?

[Simon Richter]

Hi,

> >>Mozilla builds fine without libical.
> >What does happen, then? Will it still be able to read iCalendar events?

> I just uninstalled libical and mozilla calendar still seems 
> to work fine for me.

Sounds like it is okay to remove the build-dependency on libical, then.
I just wanted to point out that some configure script may decide to drop
iCalendar support if libical was not found. Since they have their own
libical (so it seems), the build-dep is outdated.

   Simon

-- 
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4


signature.asc
Description: Digital signature

Re: [debian-devel] Re: which policy checker?

[Magosányi Árpád]

Hi!

Please take my apologies for "spreading lies".
Linda in sid does check against policy version 3.6.1 .

Which road will you take to make linda fall into testing?
Wait until python2.3 provides python (>= 2.3), or change
the dependencies of linda?

Anyway I feel it is a pity that the almost-stable distribution
does not contain a checker for the current policy which is
in effect since at least two months.

2003-10-14, k keltezéssel Steve Kowalik ezt írta:
> At  6:46 pm, Tuesday, October 14 2003, Magos?nyi ?rp?d mumbled:
> > Linda apparently does not know about the new policy version.
> > It isn't even reported as a bug (filing it right now).
> > 
> It does! Stop spreading lies, Linda 0.2.21 deals with Policy 3.6.1
> correctly, but does not drop to testing immediately.

-- 
GNU GPL: csak tiszta forrásból

Re: [debian-devel] Re: which policy checker?

[Steve Kowalik]

At 10:05 pm, Tuesday, October 14 2003, Magos?nyi ?rp?d mumbled:
> Which road will you take to make linda fall into testing?
> Wait until python2.3 provides python (>= 2.3), or change
> the dependencies of linda?
> 
I'm going to wait. Like I usually do.

> Anyway I feel it is a pity that the almost-stable distribution
> does not contain a checker for the current policy which is
> in effect since at least two months.
> 
It isn't up to me. I leave it up to the testing scripts, and wait for it
drop. As long as Linda doesn't have any RC bugs, it should drop when it's
dependancies do. Anyway, building packages with Depends from testing is
frowned upon.

Cheers,
-- 
   Steve
WINDOWS = Will Install Needless Data On Whole System
-- CompuMan

Re: Hardcoding of .la file paths in .la files

[Steve Greenland]

On 14-Oct-03, 03:38 (CDT), Daniel Kobras <[EMAIL PROTECTED]> wrote: 
> On Tue, Oct 14, 2003 at 09:52:28AM +0200, Josselin Mouette wrote:
> > I really feel we should get rid of all these static libraries. Who uses
> > static linking now that even our glibc doesn't support it correctly
> > across versions?
> 
> People who want their binaries to run across different Linux machines.
> People who don't want to keep up with rapidly changing library APIs.
> People who want to have reliable emergency recovery tools available.
> People who use performance critical libs on register-starved machines.
> People who need to minimize startup times.

AOL. 

Which doesn't, in any way, promote the idea that we should keep the .la
files. People who need/want a statically linked binary often want to
control exactly *which* libraries are statically linked, and will build
the link command by hand.

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: [debian-devel] Re: which policy checker?

[Steve Greenland]

On 14-Oct-03, 07:00 (CDT), Magos?nyi ?rp?d <[EMAIL PROTECTED]> wrote: 
> Which road will you take to make linda fall into testing?

Why do you need it in testing? The whole point of it is to run against
packages you are building, and you should be building in unstable.

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: The sense of automake (Was: Processed: better make that 1.7.8... :-()

[Santiago Vila]

On Tue, 14 Oct 2003, Andreas Tille wrote:

> regarding to bug #215554 I would like to ask for my personal clarification:
> Which sens makes automake if the resulting output depends from every new
> subsubversion?
>
> I've thought that I would do the wordnet program some good if I would add
> automake stuff.  Since I switched to auotmake1.7 I have continous trouble
> with subsubversion dependencies which now convinced me that I had a really
> stupid idea.  Is there any reason for this trouble I could understand?
>
> If not I would revert my changes and will go back to just patching the
> brocken upstream Makefiles.

In general, Debian source packages should not need to build-depend on
automake. In theory, the author should already care to create an
original tarball with all the required things already created
(in fact, it is part of GNU standards that packages should not depend
on autoconf, automake, etc. to build).

There is of course a problem when you have to modify Makefile.am
(or any other similar file) in one of your packages and regenerate
files accordingly, and there are mainly two ways of doing this, none
of which is perfect. What you have probably done is to build-depend on
automake, and let the Makefiles do whatever needs to be done. This is
prone to error due to version mismatches, as you have already experienced.

The other way is to run automake yourself, using an automake version
which is known to work for your package, and ship the generated files
in the .diff.gz. This is closer to what the upstream author would do
to create a new tarball when he/she changes any of the Makefile.am
files. The problem with this approach is that make is usually confused
with the resulting timestamps at build time, since they are often a
mix between the original ones and the build time (because some of
those files were patched by dpkg-source), but if you add a couple of
touch commands in your debian/rules you might be able to convince make
that there is really nothing to regenerate. See the current gettext
package for an example of this. Not that I recommend this approach
over the other but you should be aware that this could be a way to
avoid a "build-depends: automake" and the problem you experienced.

Re: How come X seems insistent on managing my XF86Config now?

[Greg Stark]

Branden Robinson <[EMAIL PROTECTED]> writes:

> [CCing debian-x because if I get hit by a bus or arrested by Secretary
> Ashcroft today, the following will be important for the inheritor of our
> XFree86 packages to know.]

Ah, for some reason I had trouble finding this mailing list. I poked around
/usr/share/doc/xserver-xfree86 and the xsf web pages and couldn't find any
mention of a separate mailing list. I imagine it's there and I'm just blind.

> On Thu, Oct 09, 2003 at 12:20:01AM -0400, Greg Stark wrote:
> > Branden Robinson <[EMAIL PROTECTED]> writes:
> > 
> > > Just answer the questions.  
> > 
> > Well there seem to be a lot of them. And a lot of them don't seem to have
> > default answers. Or in some cases any reasonable answer given my setup. 
> 
> Actually, they all have default answers.  A few have blank default
> answers under most circumstances (like PCI bus ID and XKB variant),
> which it is safe to leave blank.

Uh, in that case something's broken. I held down the return key and it skipped
a bunch of questions but then got stuck on one. I had to choose an answer.
Then I held down the return key and it got stuck a few questions later. At
least 3-4 questions needed manual answers.

In any case I was more worried that it would touch my config file. With your
assurances I went ahead and answered the questions and there weren't nearly as
many of them as I feared.

> In the meantime, I suggest just hitting enter until the questions go
> away (if you're using the dialog frontend -- if not, do the equivalent
> for your frontend).

This was in an xterm.

-- 
greg

Re: recent spam to this list

[John Hasler]

Joel Baker writes:
> Many places do hosting of DNS domains (only; no web or mail, etc) for
> absurdly cheap rates ($5/mo in some cases), and allow either DDNS or an
> automateable webpage to do updates with.

I'm aware of these.  While interesting should they start supporting SPF
they are not really essential to anything I'd want to do.

> Your ISP probably doesn't permit outbound connections from dialups to port
> 25...

Actually, it does.  I don't use it though: when sending mail from home I'm
happy to use my ISP's smarthost.

> Not at all uncommon, though it might be worth trying to convince them
> to allow you to do *authenticated* relay from outside.

Authenticated relay is what I meant.  I don't expect or want them to run an
open relay.  It is, however, pointless to try to convince them to change
anything.  They do not listen to customers.  On the other hand, they
enforce no obnoxious policies, don't have silly terms of service, and seem
to be above-average in reliability.

> Mail* has an return path that includes domain names (normally). SMTP
> *sessions* have a source IP. All of the protocols I saw obviously listed
> on the ASRG page (including at least RMX, SPF, and Vixie's proposal) use
> the *claimed* domain (which can be anything), and the *actual* source IP
> (which cannot be forged without having access to the routing hardware in
> between the machines, at which point you can do damned near anything you
> want), to decide whether it's kosher. The library's domain is irrelevant,
> in this case, since you're not claiming a return address in the library's
> domain.

I understand all that, which is why I found statements such as those in
<[EMAIL PROTECTED]> confusing.  The fact is I can add SPF
records for any IP numbers I want to domains I control.  Thus if I want to
be able to send mail from the library or the university claiming to be from
my domain I just need to add the appropriate records to my domain.  The
library and university have nothing to say in the matter.

 > Look up "joe job".

Strictly speaking what I am suffering is not a "joe job".  The spammers
using my domain are not actively trying to defame me: they just find it
convenient to forge my domain.  Widespread implementation of SPF would stop
them.

I've read up some more on SPF (IMHO the best of the bunch) and the rest of
the ASRG proposals.  SPF works exactly as I thought it did.  I have no
problem with any of it: I'd like to see it adopted ASAP.

Some URLS:

http://www.mikerubel.org/computers/rmx_records/#introduction
http://spf.pobox.com/
http://spf.pobox.com/faq.html#noprevent
http://spf.pobox.com/dmpvsrmx.html
http://spf.pobox.com/dmpvsrmx.html
http://spf.pobox.com/draft-mengwong-spf-01.txt



-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Uploader field in debian/control?

[Andreas Metzler]

Andreas Metzler <[EMAIL PROTECTED]> wrote:
> Magosányi Árpád <[EMAIL PROTECTED]> wrote:
>> In the policy manual there is no mention of the Uploader field of
>> debian/control. (version 3.6.1.0)
[...]
> the package control files. However Uploaders ends up in the dsc file
> and is not unsupported. Afaict you are right, I'll try to come up with
> a patch.

[X] Done. Bug#203145 if somebody wants to second it.

If there is need to continue this discussion please do so on
debian-policy.
   cu andreas

Re: Hardcoding of .la file paths in .la files

[Daniel Jacobowitz]

I hate to jump in but I really feel the need to correct the below.  You
have a good number of points wrong.

On Tue, Oct 14, 2003 at 10:38:49AM +0200, Daniel Kobras wrote:
> On Tue, Oct 14, 2003 at 09:52:28AM +0200, Josselin Mouette wrote:
> > I really feel we should get rid of all these static libraries. Who uses
> > static linking now that even our glibc doesn't support it correctly
> > across versions?
> 
> People who want their binaries to run across different Linux machines.

Dynamic linking to an old version of glibc is more portable than
statically linking to any version.  Exhibit A is NSS; exhibit B is
iconv.  Neither works properly when statically linked unless run
against the exact same glibc version.

> People who don't want to keep up with rapidly changing library APIs.

That's a good reason to statically link to _specific_ libraries.

> People who want to have reliable emergency recovery tools available.

This is not hard to arrange using shared libraries.

> People who use performance critical libs on register-starved machines.

Another good reason for specific static libraries only.

> People who need to minimize startup times.

Static linking does _not_ minimize startup times; in fact it's quite
inefficient.  Dynamic linking + prelinking is much faster if you care
about startup times.

> To name but a few. Just because there's little incentive to use static
> linkage when building Debian packages doesn't mean that we should
> deprecate it. Unless you're willing to convince the admin of the
> beowulf cluster next door to install libyoddafoo on several hundred
> nodes for me.

Not that I'm disagreeing with your conclusions; just your reasoning.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: Hardcoding of .la file paths in .la files

[Daniel Kobras]

On Tue, Oct 14, 2003 at 08:09:32AM -0500, Steve Greenland wrote:
> Which doesn't, in any way, promote the idea that we should keep the .la
> files. People who need/want a statically linked binary often want to
> control exactly *which* libraries are statically linked, and will build
> the link command by hand.

This is probably true when performance tuning. However, when I prepare a
binary to submit to a supercomputer, or an executable for a CD (that
should Just Work when I pull it out after two years), I usually just
plonk in a '-static' and be done with it. I'd hate to see this
functionality go. If you ever tried to get, say, ten static libs in the
right order for a medium-sized application, you know what tedious task
I'm taking about. From my personal point of view, removal of .la files
would significantly degrade Debian's usability as a build platform.

Daniel.

Alioth services down?

[Oliver Elphick]

Alioth is not accepting ssh connections and mail to a mailing list is
neither arriving nor bouncing.

I have mailed [EMAIL PROTECTED], but it occurs to me that if mail
is not getting through to the lists, it may not have got to that address
either.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "I delight to do thy will, O my God; yea, thy law is 
  within my heart." Psalms 40:8 

Re: Hardcoding of .la file paths in .la files

[Daniel Kobras]

On Tue, Oct 14, 2003 at 11:57:40AM -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 14, 2003 at 10:38:49AM +0200, Daniel Kobras wrote:
> > On Tue, Oct 14, 2003 at 09:52:28AM +0200, Josselin Mouette wrote:
> > > I really feel we should get rid of all these static libraries. Who uses
> > > static linking now that even our glibc doesn't support it correctly
> > > across versions?
> > 
> > People who want their binaries to run across different Linux machines.
> 
> Dynamic linking to an old version of glibc is more portable than
> statically linking to any version.  Exhibit A is NSS; exhibit B is
> iconv.  Neither works properly when statically linked unless run
> against the exact same glibc version.

The sentence I refer to reads: 'I really feel we should get rid of all
these static libraries.' _All_ static libraries. glibc is quite special
in this regard because it's likely to be present even on a minimalist
system.

> > People who need to minimize startup times.
> 
> Static linking does _not_ minimize startup times; in fact it's quite
> inefficient.  Dynamic linking + prelinking is much faster if you care
> about startup times.

Prelinking is also quite recent and not yet available on any platform as
far as I know. Are you claiming that startup performance of statically
linked objects is equal to shared objects even without prelink?

Daniel.

Re: Hardcoding of .la file paths in .la files

[Daniel Jacobowitz]

On Tue, Oct 14, 2003 at 06:35:38PM +0200, Daniel Kobras wrote:
> On Tue, Oct 14, 2003 at 11:57:40AM -0400, Daniel Jacobowitz wrote:
> > On Tue, Oct 14, 2003 at 10:38:49AM +0200, Daniel Kobras wrote:
> > > On Tue, Oct 14, 2003 at 09:52:28AM +0200, Josselin Mouette wrote:
> > > > I really feel we should get rid of all these static libraries. Who uses
> > > > static linking now that even our glibc doesn't support it correctly
> > > > across versions?
> > > 
> > > People who want their binaries to run across different Linux machines.
> > 
> > Dynamic linking to an old version of glibc is more portable than
> > statically linking to any version.  Exhibit A is NSS; exhibit B is
> > iconv.  Neither works properly when statically linked unless run
> > against the exact same glibc version.
> 
> The sentence I refer to reads: 'I really feel we should get rid of all
> these static libraries.' _All_ static libraries. glibc is quite special
> in this regard because it's likely to be present even on a minimalist
> system.
> 
> > > People who need to minimize startup times.
> > 
> > Static linking does _not_ minimize startup times; in fact it's quite
> > inefficient.  Dynamic linking + prelinking is much faster if you care
> > about startup times.
> 
> Prelinking is also quite recent and not yet available on any platform as
> far as I know. Are you claiming that startup performance of statically
> linked objects is equal to shared objects even without prelink?

Often worse, due to the dramatically increased amount of data which
must be loaded from disk in a cold-cache situation.  Another 800K of
glibc you've got to read in.  The memory usage sucks too.

Prelinking is now available on almost all Debian architectures, so I'm
not sure what you mean.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: Hardcoding of .la file paths in .la files

[Greg Folkert]

On Tue, 2003-10-14 at 04:38, Daniel Kobras wrote:
> To name but a few. Just because there's little incentive to use static
> linkage when building Debian packages doesn't mean that we should
> deprecate it. Unless you're willing to convince the admin of the
> beowulf cluster next door to install libyoddafoo on several hundred
> nodes for me.

Okay, where do I show up? And do you think I'll need the Thumb-Clamps as
well as the Spiked Ball-Buster, Sawed-Off Shotgun and the Dirty Smelly
Sweat Socks?
-- 
greg, [EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry

Solitamente, quando emani profumi, mi ricordi lamette circonflesse.


signature.asc
Description: This is a digitally signed message part

Bug#215778: ITP: libphysfs -- A filesystem abstraction for game programmers

[Bartosz Fenski aka fEnIo]

Package: wnpp
Severity: wishlist

* Package name: libphysfs
  Version : 0.1.9
  Upstream Author : Ryan Gordon <[EMAIL PROTECTED]>
* URL : http://www.icculus.org/physfs/downloads/
* License : zlib
  Description : A filesystem abstraction for game programmers

 PhysicsFS filesystem abstraction library, is a library that
 provides a simple C interface to aid game programmers in utilizing game
 assets packaged in many different types of archive files.

Re: Hardcoding of .la file paths in .la files

[Tollef Fog Heen]

* Daniel Kobras 

| If you ever tried to get, say, ten static libs in the right order
| for a medium-sized application, you know what tedious task I'm
| taking about. From my personal point of view, removal of .la files
| would significantly degrade Debian's usability as a build platform.

You can also be lazy and just use --start-group and --end-group
(though note the last paragraph):

  --start-group archives --end-group
  The archives should be a list of archive files.  They may be either
  explicit file names, or -l options.

  The specified archives are searched repeatedly until no new
  undefined references are created.  Normally, an archive is
  searched only once in the order that it is specified on the
  command line.  If a symbol in that archive is needed to resolve
  an undefined sym- bol referred to by an object in an archive
  that appears later on the command line, the linker would not be
  able to resolve that ref- erence.  By grouping the archives,
  they all be searched repeatedly until all possible references
  are resolved.

  Using this option has a significant performance cost.  It is
  best to use it only when there are unavoidable circular
  references between two or more archives.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Bug#215783: ITP: netpanzer -- An online multiplayer tactical warfare game

[Bartosz Fenski aka fEnIo]

Package: wnpp
Severity: wishlist

* Package name: netpanzer
  Version : 0.1.1
  Upstream Authors: Matthias Braun <[EMAIL PROTECTED]>
Ivo Danihelka <[EMAIL PROTECTED]>
Tyler Nielsen <[EMAIL PROTECTED]>
Vlad Rahkoy <[EMAIL PROTECTED]>
Ingo Ruhnke <[EMAIL PROTECTED]>
* URL : http://savannah.nongnu.org/projects/netpanzer/
* License : GPL
  Description : An online multiplayer tactical warfare game

netPanzer is an online multiplayer tactical warfare game designed for
play across the Internet and over LAN systems. One on one games are
possible via direct connect or modem. netPanzer is designed for FAST
ACTION combat -- it is not another resource management clone. In fact,
there aren't any resources at all. Each player will have many units of
different types at their disposal. Players can fight until their units
are destroyed -- then respawn and keep on going. The game is real-time,
but it's based on quick tactical action and unit management. Battles
progress quickly and constantly; in fact, they never let up. There is no
stop in the action because there is no waiting for resources to be
collected and converted into weaponry. Players can join or leave
multiplayer games at any time.

Re: Hardcoding of .la file paths in .la files

[Daniel Kobras]

On Tue, Oct 14, 2003 at 12:48:28PM -0400, Daniel Jacobowitz wrote:
> Often worse, due to the dramatically increased amount of data which
> must be loaded from disk in a cold-cache situation.  Another 800K of
> glibc you've got to read in.  The memory usage sucks too.

That's glibc. It's already in memory. This is not necessarily the case
for less widespread libs. Depending on the contents of the .a, and the
number of functions actually used, you might end up reading in less data
from disk, and also save on filesystem and dynamic symbol lookup. I'm
not advocating to link in glibc statically. I'm advocating to leave it
up to the users to pick their preferred method of linking, and not put
up extra hurdles.

> Prelinking is now available on almost all Debian architectures, so I'm
> not sure what you mean.

I'm referring to

  % apt-cache showsrc prelink | grep Architecture
  Architecture: alpha i386 powerpc

I'm glad to hear that support for further architectures is apparently
getting along. Still, this whole prelink issue is tangent to the main
point: There are valid reasons for static linking, and I oppose the
blanket statement that we should deprecate this method.

Daniel.

Re: Bug#215778: ITP: libphysfs -- A filesystem abstraction for game programmers

[Joe Drew]

On Tue, 2003-10-14 at 13:06, Bartosz Fenski aka fEnIo wrote:
> * Package name: libphysfs
>   Version : 0.1.9
>   Upstream Author : Ryan Gordon <[EMAIL PROTECTED]>
> * URL : http://www.icculus.org/physfs/downloads/
> * License : zlib
>   Description : A filesystem abstraction for game programmers

Maybe "filesystem abstraction library for game programmers"?

>  PhysicsFS filesystem abstraction library, is a library that
>  provides a simple C interface to aid game programmers in utilizing game
>  assets packaged in many different types of archive files.

The PhysicsFS filesystem abstraction library provides a simple C
interface to aid game programmers in utilizing game assets packaged in
many different types of archive files.

(Maybe list some examples of this.)

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#215728: ITP: gngeogui -- GTK GUI-frontend for gngeo

[Joe Drew]

On Tue, 2003-10-14 at 06:48, Julien Delange wrote:
>   Description : GTK GUI-frontend for gngeo

"graphical frontend for gngeo"

> gngeogui is a GUI-Frontend to gngeo writed in Perl language. So, it 
> works on many computers. It can configure gngeo, and show all roms,
> which are stored in a directory. It shows screenshot of each game.

I will correct some poor english and make some editing changes too:

"gngeogui is a graphical frontend to gngeo which can configure gngeo as
well as show all ROM game files stored in a directory. It also shows
screenshots of each game.

gngeogui uses GTK for its graphical interface."

(Feel free to ignore the last sentence.)

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#215783: ITP: netpanzer -- An online multiplayer tactical warfare game

[Joe Drew]

On Tue, 2003-10-14 at 13:30, Bartosz Fenski aka fEnIo wrote:

>   Description : An online multiplayer tactical warfare game

Drop the "An."


> netPanzer is an online multiplayer tactical warfare game designed for
> play across the Internet and over LAN systems. One on one games are
> possible via direct connect or modem. netPanzer is designed for FAST
> ACTION combat -- it is not another resource management clone. In fact,
> there aren't any resources at all. Each player will have many units of
> different types at their disposal. Players can fight until their units
> are destroyed -- then respawn and keep on going. The game is real-time,
> but it's based on quick tactical action and unit management. Battles
> progress quickly and constantly; in fact, they never let up. There is no
> stop in the action because there is no waiting for resources to be
> collected and converted into weaponry. Players can join or leave
> multiplayer games at any time.

Might want to split that into multiple paragraphs, but looks good.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#215728: ITP: gngeogui -- GTK GUI-frontend for gngeo

[Tollef Fog Heen]

* Joe Drew 


[...]

| "gngeogui is a graphical frontend to gngeo which can configure gngeo as
| well as show all ROM game files stored in a directory. It also shows
| screenshots of each game.
| 
| gngeogui uses GTK for its graphical interface."

It should also describe (in one sentence) what gngeo is.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Hardcoding of .la file paths in .la files

[Andreas Metzler]

Daniel Kobras <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 14, 2003 at 08:09:32AM -0500, Steve Greenland wrote:
>> Which doesn't, in any way, promote the idea that we should keep the .la
>> files. People who need/want a statically linked binary often want to
>> control exactly *which* libraries are statically linked, and will build
>> the link command by hand.

> This is probably true when performance tuning. However, when I prepare a
> binary to submit to a supercomputer, or an executable for a CD (that
> should Just Work when I pull it out after two years), I usually just
> plonk in a '-static' and be done with it. I'd hate to see this
> functionality go.
[...]

It is already gone. If the binary uses NSS you have a good chance that
it won't work with a different glibc. Just
check http://bugs.debian.org/libc6 foor examples.
  cu andreas

Re: [debian-devel] Re: which policy checker?

[Josip Rodin]

On Tue, Oct 14, 2003 at 02:00:31PM +0200, Magosányi Árpád wrote:
> Anyway I feel it is a pity that the almost-stable distribution
> does not contain a checker for the current policy which is
> in effect since at least two months.

You assign way too much value to the latest two revisions. Try reading
upgrading-checklist.txt. In general, relying on automated tools to check
packages, rather than inspecting them manually based on actual (*gasp*!)
knowledge of policy, isn't particularly smart.

-- 
 2. That which causes joy or happiness.

Re: faster boot

[Bartosz Zapalowski]

> there has been a lot of interest lately on tecniques to obtain a faster
> boot

It depends of what is machine meant to do.
If it's just a X workstation with some services run just for testing
purposes you can start just after syslog and xfs-xtt and X server.

I managed to lower the start time to 23 seconds (from 35 seconds) - what
I need is to be able to login as fast as it is possible, but have the
services started.

I modified runlevel 2, so that it runs syslog, xfs-xtt, gdm which forks
off and them I pause for 5 seconds. During this time I can login fast
without any glitches and have WM started. After that, normal startup
sequence is being completed and I don't care how many services have to
be started.

I'd like this feature to be out-of-the-box by just saying in base config
or boot scripts debconf that this machine is workstation.


I'm not subscribe to this list, so please CC me.

-- 
Bartosz Zapalowski
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: Uploader field in debian/control?

[Josip Rodin]

On Mon, Oct 13, 2003 at 08:52:37PM +0200, Magosányi Árpád wrote:
> It seemed to me that only the fields explicitly mentioned and those
> starting with X should be in the control files, but I cannot find
> it explicitly stated.
> 
> Did I miss something?

Exactly what you wrote. The list of fields in the Policy manual is never
stated to be inclusive, so, um, it's not.

-- 
 2. That which causes joy or happiness.

perm of etc/zorp/ is 0700

[Magosányi Árpád]

Hi!

I am asking your advice per policy section 10.9. [*]

/etc/zorp is mode 0700 in upstream. In a typical setup, almost
every single file under this directory contains sensitive information:
firewall rules, cryptographic keys, etc.

I think it justifies a lintian override.

What do you think?

[*] The rules in this section are guidelines for general use. If
necessary you may deviate from the details below. However, if you do so
you must make sure that what is done is secure and you should try to be
as consistent as possible with the rest of the system. You should
probably also discuss it on debian-devel first. 

-- 
GNU GPL: csak tiszta forrásból

Re: perm of etc/zorp/ is 0700

[Ben Collins]

On Tue, Oct 14, 2003 at 10:51:14PM +0200, Magos?nyi ?rp?d wrote:
> Hi!
> 
> I am asking your advice per policy section 10.9. [*]
> 
> /etc/zorp is mode 0700 in upstream. In a typical setup, almost
> every single file under this directory contains sensitive information:
> firewall rules, cryptographic keys, etc.
> 
> I think it justifies a lintian override.
> 
> What do you think?
> 
> [*] The rules in this section are guidelines for general use. If
> necessary you may deviate from the details below. However, if you do so
> you must make sure that what is done is secure and you should try to be
> as consistent as possible with the rest of the system. You should
> probably also discuss it on debian-devel first. 

If the directory is justified, then the files should be 600 aswell.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: recent spam to this list

[Manoj Srivastava]

On Tue, 14 Oct 2003 10:21:23 -0500, John Hasler <[EMAIL PROTECTED]> said: 

> I understand all that, which is why I found statements such as those
> in
>> [EMAIL PROTECTED]> confusing.  The fact is I can add SPF
> records for any IP numbers I want to domains I control.  Thus if I
> want to be able to send mail from the library or the university
> claiming to be from my domain I just need to add the appropriate
> records to my domain.  The library and university have nothing to
> say in the matter.


Consider this use case: I travel a lot, and stay in hotels
 with network connections. Unfortunately, these  nigtly billed domains
 have very poor mail gateways; I've been burned before. I now connect
 directly and deliver mail from the MTA on my laptop.

I do not know, a priori, what the IP address is likely to be,
 and getting DNS changed for datasync.com would take days, not hours,
 by which time I would no longer be at the IP.

I do not have co-located servers; and my normal machine may
 not be accessible from outside to tunnel to. Just like the postcards
 I mail from the Hotel, the return address on my email points to a
 valid mbox. 

Would there be any way to implement tihs use case with
 everyone using SPF, and telling spamassassin to deep six failures?

manoj
-- 
Okay, Okay -- I admit it.  You didn't change that program that worked
just a little while ago; I inserted some random characters into the
executable.  Please forgive me.  You can recover the file by typing in
the code over again, since I also removed the source.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#215728: ITP: gngeogui -- GTK GUI-frontend for gngeo

[Julien Delange]

On Tue, Oct 14, 2003 at 08:14:55PM +0200, Tollef Fog Heen wrote:
> It should also describe (in one sentence) what gngeo is.

Yes, you're right. So, I take your ideas and I will change the
description when I will package gngeogui.

Please excuse me, but I'm french, and my english is maybe poor. But, I
try to write sentences, which can be understand.

Thank you for your ideas for my package.

-- 
:: Julien Delange (julien AT gunnm DOT org) | :: GPG ::   
   / 
 x http://gunnm.org   / 8F36 4FD5 3845 6565 71DC 
 x http://julien.gunnm.org| F440 14D0 D2C0 FF1C EFB3

Re: Bug#215728: ITP: gngeogui -- GTK GUI-frontend for gngeo

[Julien Delange]

On Tue, Oct 14, 2003 at 01:45:15PM -0400, Joe Drew wrote:


> I will correct some poor english and make some editing changes too:
> 
> "gngeogui is a graphical frontend to gngeo which can configure gngeo as
> well as show all ROM game files stored in a directory. It also shows
> screenshots of each game.
> 
> gngeogui uses GTK for its graphical interface."
> 
> (Feel free to ignore the last sentence.)

Thank you for correcting me and allow me a better description for my
package.

-- 
:: Julien Delange (julien AT gunnm DOT org) | :: GPG ::   
   / 
 x http://gunnm.org   / 8F36 4FD5 3845 6565 71DC 
 x http://julien.gunnm.org| F440 14D0 D2C0 FF1C EFB3

Re: recent spam to this list

[Henrique de Moraes Holschuh]

On Tue, 14 Oct 2003, Manoj Srivastava wrote:
>   I do not know, a priori, what the IP address is likely to be,
>  and getting DNS changed for datasync.com would take days, not hours,
>  by which time I would no longer be at the IP.

You'd just need something akin to the ddns services... but in this case, for
the SPF records.

There is no technical impossibility, at all.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Hardcoding of .la file paths in .la files

[Daniel Jacobowitz]

On Tue, Oct 14, 2003 at 07:44:05PM +0200, Daniel Kobras wrote:
> On Tue, Oct 14, 2003 at 12:48:28PM -0400, Daniel Jacobowitz wrote:
> > Often worse, due to the dramatically increased amount of data which
> > must be loaded from disk in a cold-cache situation.  Another 800K of
> > glibc you've got to read in.  The memory usage sucks too.
> 
> That's glibc. It's already in memory. This is not necessarily the case
> for less widespread libs. Depending on the contents of the .a, and the
> number of functions actually used, you might end up reading in less data
> from disk, and also save on filesystem and dynamic symbol lookup. I'm
> not advocating to link in glibc statically. I'm advocating to leave it
> up to the users to pick their preferred method of linking, and not put
> up extra hurdles.

Sure, if you statically include individual libraries this isn't an
issue.  The result is a dynamically linked application with no
dependency on that library, however.  .la files will _NOT_ help you do
this.  I don't think libtool can even grasp the idea.

> > Prelinking is now available on almost all Debian architectures, so I'm
> > not sure what you mean.
> 
> I'm referring to
> 
>   % apt-cache showsrc prelink | grep Architecture
>   Architecture: alpha i386 powerpc
> 
> I'm glad to hear that support for further architectures is apparently
> getting along. Still, this whole prelink issue is tangent to the main

Ask the prelink package maintainer why the heck that's so.  It also
works on (offhand) SH, ARM, ia64, s390, s390x, powerpc64, x86-64.  I
don't know about m68k or hppa.  MIPS is a holdout.  It works, in other
words, nearly everywhere.  This information is months old.

> point: There are valid reasons for static linking, and I oppose the
> blanket statement that we should deprecate this method.

I agree with you that it shouldn't be deprecated, as I said at the
beginning.  Sorry if I gave any different impression.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: recent spam to this list

[Mark Ferlatte]

Manoj Srivastava said on Tue, Oct 14, 2003 at 04:40:15PM -0500:
>   Consider this use case: I travel a lot, and stay in hotels
>  with network connections. Unfortunately, these  nigtly billed domains
>  have very poor mail gateways; I've been burned before. I now connect
>  directly and deliver mail from the MTA on my laptop.
> 
>   I do not know, a priori, what the IP address is likely to be,
>  and getting DNS changed for datasync.com would take days, not hours,
>  by which time I would no longer be at the IP.
> 
>   I do not have co-located servers; and my normal machine may
>  not be accessible from outside to tunnel to. Just like the postcards
>  I mail from the Hotel, the return address on my email points to a
>  valid mbox. 
> 
>   Would there be any way to implement tihs use case with
>  everyone using SPF, and telling spamassassin to deep six failures?

You've got an SMTP server somewhere that accepts mail, right?  (Otherwise, how
do you recieve?).

Configure that server to relay for people who are using SMTP AUTH, and then
configure your laptop to use that as a smart host using SMTP AUTH.  Then, you
SPF for your smart host only; no wacky Dynamic DNS hacks required.  Frankly,
that kind of setup works better anyway; you get your mail off of your
non-reliably connected laptop ASAP, and then let your smarthost worry about
queuing.

M


pgpFvWTY6V9xq.pgp
Description: PGP signature

Bug#215827: ITP: lartc -- Linux Advanced Routing and Traffic Control HOWTO

[Pedro Larroy]

Package: wnpp
Version: unavailable; reported 2003-10-15
Severity: wishlist


* Package name: lartc
  Version : 1.41-1
  Upstream Author : Thomas Graf <[EMAIL PROTECTED]>
* URL : http://www.lartc.org
* License : (Free)
  Description : Linux Advanced Routing and Traffic Control HOWTO

 This HOWTO documents the powerful capabilities of the iproute
 infraestructure for Linux kernels 2.2/2.4/2.6
 Some of the topics covered are:
  * Iproute
  * IPV4 and IPV6 tunnels
  * IPSEC
  * Multicast routing
  * Queueing disciplines for bandwidth management
  * Load balancing
  * Cookbook of recipes
  * Ethernet bridges
  * Dynamic routing (OSPF and BGP)


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux falafell 2.6.0-test6 #2 Wed Oct 1 18:53:04 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=es_ES

Re: Bug#215728: ITP: gngeogui -- GTK GUI-frontend for gngeo

[Joe Drew]

On Tue, 2003-10-14 at 18:30, Julien Delange wrote:
> Please excuse me, but I'm french, and my english is maybe poor. But, I
> try to write sentences, which can be understand.

Which is exactly why we send friendly corrections :)

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

chroot on debian hosts?

[Marc Singer]

(I thought I sent this, but now I cannot find it to be sure.)

I'd like to build against sid on a machine (ia64) I don't own but
which Debian does have available.

I tried the recipe from the developer's manual using fakeroot.  It
failed because it could not find a package.  Perhaps, this is a bug in
debootstrap.  Is that method supposed to work?

Re: recent spam to this list

[John Hasler]

Manoj writes:
> Consider this use case: I travel a lot, and stay in hotels with network
> connections. Unfortunately, these nigtly billed domains have very poor
> mail gateways; I've been burned before. I now connect directly and
> deliver mail from the MTA on my laptop.

> I do not know, a priori, what the IP address is likely to be, and getting
> DNS changed for datasync.com would take days, not hours, by which time I
> would no longer be at the IP.

> I do not have co-located servers; and my normal machine may not be
> accessible from outside to tunnel to. Just like the postcards I mail from
> the Hotel, the return address on my email points to a valid mbox.

Get a smtp.com account.   The sort of relaying you
need appears to be their business (I've never done business with them
myself).

-- 
John Hasler
[EMAIL PROTECTED]

Re: [debian-devel] Re: which policy checker?

[Blars Blarson]

In article <[EMAIL PROTECTED]> you write:
>Try reading upgrading-checklist.txt. 

Where do I get a copy of this document?  A summery of what to check
for when updating a package would be very useful.  (I've just agreed
to take over a few more packages, two which havn't been updated since
woody.)

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.

Re: Alioth services down?

[Peter S Galbraith]

Oliver Elphick  wrote:

> Alioth is not accepting ssh connections and mail to a mailing list is
> neither arriving nor bouncing.

I noticed the same from work earlier today, and the same from home now.

:-(

Re: chroot on debian hosts?

[Ben Collins]

On Tue, Oct 14, 2003 at 06:20:15PM -0700, Marc Singer wrote:
> (I thought I sent this, but now I cannot find it to be sure.)
> 
> I'd like to build against sid on a machine (ia64) I don't own but
> which Debian does have available.
> 
> I tried the recipe from the developer's manual using fakeroot.  It
> failed because it could not find a package.  Perhaps, this is a bug in
> debootstrap.  Is that method supposed to work?

You need to send email to [EMAIL PROTECTED] to get packages installed
in the chroots for your builds.

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: recent spam to this list

[Joel Baker]

On Tue, Oct 14, 2003 at 04:40:15PM -0500, Manoj Srivastava wrote:
> On Tue, 14 Oct 2003 10:21:23 -0500, John Hasler <[EMAIL PROTECTED]> said: 
> 
> > I understand all that, which is why I found statements such as those
> > in
> >> [EMAIL PROTECTED]> confusing.  The fact is I can add SPF
> > records for any IP numbers I want to domains I control.  Thus if I
> > want to be able to send mail from the library or the university
> > claiming to be from my domain I just need to add the appropriate
> > records to my domain.  The library and university have nothing to
> > say in the matter.
> 
> 
>   Consider this use case: I travel a lot, and stay in hotels
>  with network connections. Unfortunately, these  nigtly billed domains
>  have very poor mail gateways; I've been burned before. I now connect
>  directly and deliver mail from the MTA on my laptop.
> 
>   I do not know, a priori, what the IP address is likely to be,
>  and getting DNS changed for datasync.com would take days, not hours,
>  by which time I would no longer be at the IP.
> 
>   I do not have co-located servers; and my normal machine may
>  not be accessible from outside to tunnel to. Just like the postcards
>  I mail from the Hotel, the return address on my email points to a
>  valid mbox. 
> 
>   Would there be any way to implement tihs use case with
>  everyone using SPF, and telling spamassassin to deep six failures?
> 
>   manoj

Given that set of constraints? No. However, as I said before, the same
arguments have been used to defend open relays - and they are equally
valid, or invalid, depending on whether you consider the massive abuse
versus the few cases in which it is useful.

Both are, in fact, fairly readily solved by the same basic method (unless
port 25 is blocked outbound, which stops all chances of being able to send
email out directly, as well) - relay to a smarthost that accepts SMTP AUTH.
If your ISP won't do it, and your home box can't do it, perhaps it's time
to consider a business investment in maintaining a mailbox with an ISP who
does allow it - there are plenty to choose from.

In other words: I do not accept the argument that you should be able to
shift costs from you (the person wanting to do what is a fairly uncommon
and non-standard configuration) to me (the person who has to go through a
lot of spam to allow you to do so). In my world, my time is worth more than
your money - and it's my world that decides whether *I* use SPF, domain
verification, block dial-up addresses (which will also shoot you in the
foot), or filter all mail from your know addresses. Or none of the above.

If, and only if, much of the rest of the world makes the same value
judgement, then you might have issues sending email to them - because
they have said, on a policy level, that getting your email (through that
configuration) is *not as important* to them as *not* getting the spam.

So far, that policy seems to be a fairly popular one, if we go by the
fairly directly analagous situation of "who uses Open Relay lists as part
of their filtering" - though *most* of them that I've seen just use it as
an SA rule, rather than rejecting it outright.

A $19.95/mo dialup account hasn't bought you all that much of the Internet
for some years now; this is simply one more door that appears likely to
be closed. If you don't like that, there are perfectly workable ways to
buy the ability to do what you do want, for a very reasonable price, some
of which are unlikely to ever be blocked by any local ISP you may connect
through. TANSTAAFL; the Commons has long since been paved over.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgp3PMrpEwHAb.pgp
Description: PGP signature

Re: [debian-devel] Re: which policy checker?

[Joel Baker]

On Tue, Oct 14, 2003 at 06:31:01PM -0700, Blars Blarson wrote:
> In article <[EMAIL PROTECTED]> you write:
> >Try reading upgrading-checklist.txt. 
> 
> Where do I get a copy of this document?  A summery of what to check
> for when updating a package would be very useful.  (I've just agreed
> to take over a few more packages, two which havn't been updated since
> woody.)

Install debian-policy from unstable (conveniently possible even on
current-stable, at least, and probably just about anything...) and check
out /usr/share/doc/debian-policy/upgrading-checklist.txt.gz; all sorts of
spiffy goodness.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgpbvynS5VIxm.pgp
Description: PGP signature

Re: The sense of automake (Was: Processed: better make that 1.7.8... :-()

[Bob Proulx]

Andreas Tille wrote:
> regarding to bug #215554 I would like to ask for my personal clarification:
> Which sens makes automake if the resulting output depends from every new
> subsubversion?
> 
> I've thought that I would do the wordnet program some good if I would add
> automake stuff.  Since I switched to auotmake1.7 I have continous trouble
> with subsubversion dependencies which now convinced me that I had a really
> stupid idea.  Is there any reason for this trouble I could understand?

Note that a recent discussion of this is relevent.

  http://lists.debian.org/debian-devel/2003/debian-devel-200306/msg00533.html

> If not I would revert my changes and will go back to just patching the
> brocken upstream Makefiles.

Personally I would include touch commands to bring the timestamps
after the diff patch is applied into relative conformance with the
timestamps of the files for when the patch was made and remove the
build depends on automake.  Although the previous discussion made good
arguments both directions.  I believe either of the methods are good
as long as you champion the process to completion.

Bob


pgpEOgit0lNED.pgp
Description: PGP signature

Prospectus Intelligence (ASAP Translations Team) is your multilingual solutions provider

[Prospectus Intelligence & CO (ASAP Translation Team)]

Prospectus Intelligence (ASAP Translations Team) specializes in translating 
your documentation into any major foreign language so that it reads as though 
it were originally written in the language itself. 

When you need to: 
- Market your products & services internationally
- Create foreign language versions of your web site 
- Create foreign language versions of your software
- Support foreign customers
- Translate technical and scientific documents 
- Translate patent and legal documents 
- Translate international marketing materials

Prospectus Intelligence (ASAP Translations Team) is your multilingual solutions 
provider.

As a translation workshop based in Hong Kong and supported by a group of 
inter-cultural professionals in Hong Kong. We has experience with a full 
spectrum of subjects in global languages (English <> Chinese, Chinese/English 
<> Japanese and etc) including Journal Articles, Catalogs, Scripts, Brochures, 
Papers, Training / Product Manuals, News Release, Reports, Publications, 
website and software localization and many more. We can certainly help you 
overcome these two barriers to smoothly market your product(s) and service(s).

The reasons why you have to choose us as your business partner are:
1)  Invincible price in the street. We are now offering about half of the 
current market price in Hong Kong. The more works which are involved, the more 
discount you can get.
2)  Quality control and a team of industry professionals. We have a team of 
industry specialists from various background who are well-qualified checkers 
for every translation assignments.

Free Trial: (200-300 words)
You are most welcome to send us your work to be translated for trial purposes.

Should you have any question(s), please feel free to contact us. If you are 
interested in knowing more details, we are pleased to provide them to you.

Best Regards

Andrew Chiang
Marketing Manager
ASAP Translation Team
Prospectus Intelligence & CO.
21A Go-Up Commercial Building
998 Canton Road, Kowloon
Hong Kong
Tel : (852)2395 5090
Fax : (852)2751 1537
Email : [EMAIL PROTECTED]

Re: Bug#215728: ITP: gngeogui -- GTK GUI-frontend for gngeo

[Branden Robinson]

On Tue, Oct 14, 2003 at 01:45:15PM -0400, Joe Drew wrote:
> gngeogui uses GTK for its graphical interface."

Don't forget that (I believe) the official spelling of the library's
name is "GTK+".

-- 
G. Branden Robinson|It's like I have a shotgun in my
Debian GNU/Linux   |mouth, I've got my finger on the
[EMAIL PROTECTED] |trigger, and I like the taste of
http://people.debian.org/~branden/ |the gunmetal. -- Robert Downey, Jr.


signature.asc
Description: Digital signature

Re: Bug#215827: ITP: lartc -- Linux Advanced Routing and Traffic Control HOWTO

[Branden Robinson]

On Wed, Oct 15, 2003 at 02:05:40AM +0200, Pedro Larroy wrote:
> * Package name: lartc
>   Version : 1.41-1
>   Upstream Author : Thomas Graf <[EMAIL PROTECTED]>
> * URL : http://www.lartc.org

> * License : (Free)

Uh, that's not specific enough.

What actual license is used?

-- 
G. Branden Robinson|   If you want your name spelled
Debian GNU/Linux   |   wrong, die.
[EMAIL PROTECTED] |   -- Al Blanchard
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature