Packaging programs with all features or with most used?

[Marcin Juszkiewicz]

  Hi

  I used 'sid' for two years but now (as I don't have net access in
home) I switched to 'woody' as base system and upgraded it a little with
some sid packages. Yesterday ,when I want to install sylpheed-claws
0.8.1 from sid package, I discovered that I didn't get some packages to
make it - but that's ok - I can live with it (or someday get source and
recompile).

  The question is other: Do packages have to be build with all possible
features or with most used (in sylpheed palm pda support is compiled by
default - but does 50% of syl users needs it?) ?


PS I think that I will start to change my Debian 'testing/unstable' to
some kind of DFS (Debian From Scratch) - libgtk2.0-0 2.0.6-1 provides
libgtk2.0-0png3 at my system ;)

-- 
Marcin 'Szczepan|Hrw' Juszkiewicz
mailto: marcinamigapl
my Debian packages: deb http://users.stone.pl/szczepan/ apt/

Re: ELF extension for starting symbol search from module dependencies

[Roland McGrath]

I think you can get the effect you need just by using -Bsymbolic.  In your
example, build the GTK+ library with -Bsymbolic.  If that causes problems
because some of the library's references should be resolved in the normal
global scope, then confine the code that uses libpng to a wrapper library
that you build with -Bsymbolic.  Then link the GTK+ library against that
shared object, and I think you will get the result you need: the GTK+
library code that uses libpng will be in a DT_SYMBOLIC object and thus
resolve according to its own dependency on the desired libpng soname,
while the application is free to link a conflicting libpng in directly.

Update excuses - please explain

[Andreas Tille]

Hello

   http://ftp-master.debian.org/testing/update_excuses.html#paul

says:

# paul (- to 0.1.0.2-5)

* Maintainer: Andreas Tille
* 76 days old (needed 2 days)
* paul/m68k unsatisfiable Depends: libgtkdatabox (>= 0.1.3)
* paul/sparc unsatisfiable Depends: libgtkdatabox (>= 0.1.3)
* Valid candidate

Moreover:

auric:~> madison paul
  paul |  0.1-1 | oldstable | source, alpha, arm, i386, m68k, 
powerpc, sparc
  paul |  0.1.0.2-5 |  unstable | source, alpha, arm, hppa, i386, ia64, 
m68k, mips, mipsel, powerpc, s390, sparc
auric:~> madison libgtkdatabox
libgtkdatabox | 0.1.12.3-1 | oldstable | source, alpha, arm, i386, m68k, 
powerpc, sparc
libgtkdatabox | 1:0.1.13.0-6 |   testing | source
libgtkdatabox | 1:0.1.13.0-6 |  unstable | source


Sorry I can't verify the problem why paul has unsatisfiable Depends on
m68k and sparc.  Could anybody please enlighten me?

Kind regards

Andreas.

Re: Update excuses - please explain

[Anthony Towns]

On Thu, Aug 22, 2002 at 08:26:20AM +0200, Andreas Tille wrote:
> # paul (- to 0.1.0.2-5)
> * paul/m68k unsatisfiable Depends: libgtkdatabox (>= 0.1.3)
> * paul/sparc unsatisfiable Depends: libgtkdatabox (>= 0.1.3)
> Moreover:
> auric:~> madison libgtkdatabox
> libgtkdatabox | 0.1.12.3-1 | oldstable | source, alpha, arm, i386, m68k, 
> powerpc, sparc
> libgtkdatabox | 1:0.1.13.0-6 |   testing | source
> libgtkdatabox | 1:0.1.13.0-6 |  unstable | source

[EMAIL PROTECTED]:~$ madison libgtkdatabox-0.1.13-0
libgtkdatabox-0.1.13-0 | 1:0.1.13.0-6 |   testing | alpha, arm, hppa, i386, 
ia64, m68k, mips, mipsel, powerpc, s390, sparc
libgtkdatabox-0.1.13-0 | 1:0.1.13.0-6 |  unstable | alpha, arm, hppa, 
hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc

> Sorry I can't verify the problem why paul has unsatisfiable Depends on
> m68k and sparc.  Could anybody please enlighten me?

Which is to say "libgtkdatabox" no longer exists, but it used to, and
that's what the m68k and sparc buildds used to build paul. The sparc and
m68k debs need to be updated to reflect the new library.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

先服务满意后付款

[北航清华开发团队]

如果本邮件不是你所需要的，我们表示抱歉，请随手删除或按回复删除
++
 业务说明（先提供服务，客户满意后再付款）

我们是powersoftteam软件团队，我们的成员来自北航与清华的软件工程的硕士以及博士，我们在北京、广州、深圳、上海等都有工作室，我们提供如下服务：
1、客户关系管理（CRM）、进削存系统、销售管理系统、办公自动化系统（OA）、文挡管理系统、ERP、MRP、MIS等各类软件的定制开发，我们可以提交源程序，我们有这方面丰富的经验与众多的成功案例；
2、各类行业性软件的开发以及系统集成（例如：电信的网管软件、医院的信息管理系统、校园管理系统、酒店信息管理系统……）；
3、电子政务、电子商务等大型系统的开发；
4、专业为国内人士提供软件破解和加密服务，破解效果可以达到两个层次，一个是密码或使用期限制的解除，另一个层次是在以上基础上进一步按客户需求修改软件界面，方便客户按照自己的习惯使用。方便大家使用国内外价格高达几万、几十万的大型或专业软件。该项服务需要客户简单介绍软件并提供未破密的软件的下载地址或光盘方式；
5、专业为本土软件提供加密保护；本工作室保障良好的破解和加密质量，充分满足用户的需求！
6、我们承接全国各地的以上方面的业务！

联系方式：powersoftteam软件团队[EMAIL PROTECTED]  [EMAIL PROTECTED]
（与我们联系，请按照以上两个邮件地址，不要直接回复你所接收到的邮件）
++
  备注

1、我们可以给最终用户开发，也可以给软件公司或相关企业开发，客户可以在我们软件上面指明为客户自己开发（既软件版权可以给客户）
2：我们不提供破解工具和培训教程，考虑到操作问题，暂时不提供单片机、IC芯片和CPU的破解服务；
3：单价人民币5000元以下的软件，建议购买正版或请我们进行开发，我们不提供破解服务；
4：不出售大众软件、源代码和注册号，请勿来信索取；
5：不提供网站和电子邮箱的密码破解服务

联系方式：powersoftteam软件团队[EMAIL PROTECTED]  [EMAIL PROTECTED]
（与我们联系，请按照以上两个邮件地址，不要直接回复你所接收到的邮件）
++
请保留此邮件以备不时之需

Re: Update excuses - please explain

[Andreas Tille]

On Thu, 22 Aug 2002, Anthony Towns wrote:

> Which is to say "libgtkdatabox" no longer exists, but it used to, and
Oh well, yes - I remember ;)

> that's what the m68k and sparc buildds used to build paul. The sparc and
> m68k debs need to be updated to reflect the new library.
But what to do that these debs will be updated?  The autobuilder
leaves no trace that there went something wrong and I can see the
debs in the archive.  Isn't it strange?

Kind regards

 Andreas.

Re: Sympa package: Seeking for co-developers

[Jérôme Marant]

On Wed, Aug 21, 2002 at 11:35:52PM +0200, Jérôme Marant wrote:
> 
> Hi,
> 
>   I'm seeking for co-developers who have some interests in the

  Perhaps I should have said "co-maintainers" than co-developers.

-- 
Jérôme Marant

Re: When bind9 reinstalls, no db.root

[Colin Watson]

On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:
> I was asking for real examples in order to discuss how the case of
> bind and db.root is *not* a member of that set and how there may be a
> genuine problem with the handling of installing over missing
> configuration files.

Maybe db.root just shouldn't be a conffile, that's all.

> As far as I can tell there is no way to pass --force-confmiss to dpkg
> when using apt-get.  Perhaps this is the only real omission.  

Sure there is: it's something like -o DPkg::Options=--force-confmiss.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: OpenSSL-linked exim

[Philip Hazel]

On Wed, 21 Aug 2002, J.H.M. Dassen (Ray) wrote:

> :In addition, for the avoidance of any doubt, permission is granted to link
> :this program with OpenSSL or any other library package.
>
> This seems to be intended as the kind of exception statement Debian needs in
> order to be able to include OpenSSL-linked exim binaries (or
> OpenLDAP-linked-against-OpenSSL exim binaries) in its main archive, although
> people on debian-legal would probably point out that this doesn't spell out
> permission to redistribute the result of such linking.
>
> Philip, if I recall correctly, previous discussions on debian-legal have
> resulted in a recommended phrasing for such an exception statement
> (unfortunately, I can't seem to find a link for it at the moment); would you
> please consider getting the NOTICE updated along the lines of that phrasing
> so as to make it clear that redistribution of OpenSSL-linked exim binaries
> is allowed?

Oh, how I hate having to deal with licencing issues. I am not a legally
competent person. (Also, I am not on any Debian lists.)

If Debian would like such a statement, then please can somebody send me
the wording that they want, and I will probably have no problem
inserting it. Basically, I don't apply any restriction on linking Exim
with any library you like, and distributing the resulting binary.
(Obviously, the licencing terms of the library must be respected.)
However, the usual GPL conditions apply: the people to whom it is
distributed must have access to all the source of the Exim part.

Philip

-- 
Philip HazelUniversity of Cambridge Computing Service,
[EMAIL PROTECTED]  Cambridge, England. Phone: +44 1223 334714.

Re: Update excuses - please explain

[Anthony Towns]

On Thu, Aug 22, 2002 at 09:21:39AM +0200, Andreas Tille wrote:
> On Thu, 22 Aug 2002, Anthony Towns wrote:
> > that's what the m68k and sparc buildds used to build paul. The sparc and
> > m68k debs need to be updated to reflect the new library.
> But what to do that these debs will be updated?  The autobuilder
> leaves no trace that there went something wrong and I can see the
> debs in the archive.  Isn't it strange?

No, nothing stange about it at all. paul got rebuilt before the new
libgtkdatabox-* was available. It either needs to be binNMUed on those
architectures, or a new source needs to be uploaded to get it rebuilt.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Re: When bind9 reinstalls, no db.root

[Marc Singer]

On Thu, Aug 22, 2002 at 08:47:46AM +0100, Colin Watson wrote:
> On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:
> > I was asking for real examples in order to discuss how the case of
> > bind and db.root is *not* a member of that set and how there may be a
> > genuine problem with the handling of installing over missing
> > configuration files.
> 
> Maybe db.root just shouldn't be a conffile, that's all.

{Gesturing} That's what I'm saying. 

> 
> > As far as I can tell there is no way to pass --force-confmiss to dpkg
> > when using apt-get.  Perhaps this is the only real omission.  
> 
> Sure there is: it's something like -o DPkg::Options=--force-confmiss.

OK.  You got me.  Is there any hope that's you'll at least cede that
that's not as straightforward as we *could* be?

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

Re: Update excuses - please explain

[Andreas Tille]

On Thu, 22 Aug 2002, Anthony Towns wrote:

> No, nothing stange about it at all. paul got rebuilt before the new
> libgtkdatabox-* was available. It either needs to be binNMUed on those
> architectures, or a new source needs to be uploaded to get it rebuilt.
Well, now I understand the trouble.  New upload just went to incoming.
On the other hand I insist on my statement that this is not obviously
to see using the update_excuses and madison and needs some guessing
on developers side.

Next question:  Is there any trace of packages which are uploaded to
stable and should go to woody-proposed-updates?  How can I check if
the moove to there is progressing or whether I need to do something?

Kind regards

 Andreas.

Re: ELF extension for starting symbol search from module dependencies

[Maciej W. Rozycki]

On 21 Aug 2002, Luca Barbieri wrote:

> This is a proposal (including patches) for a GNU extension to the ELF
> executable format that adds a flag that causes the dynamic loader to
> start searching for symbols referenced by modules with the flag set from
> the module itself and its immediate dependencies. If the symbol is not
> found in this way, the dynamic linker continues the search as usual. 
> 
> This extension would be useful to allow to load in the same address
> space multiple libraries that define identical symbols, that would be
> used by different modules possibly unaware of each other's use of such
> symbols. 

 Hmm, what if two functions which get imported from different versions of
the same library operate on a static (private to the library) variable
that is needed for a proper operation for some reason?  You'd better
rebuild the sources to use a single version of each library instead. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+

Re: When bind9 reinstalls, no db.root

[Arthur de Jong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 21 Aug 2002, Marc Singer wrote:

> On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote:
> > > > Sounds like you want dpkg --force-confmiss.
> > >
> > > I wouldn't expect that since the documentation states:
> > >
> > >  confmiss: Always install  a  missing  configuration
> > >   file.  This  is  dangerous, since it means not pre-
> > >   serving a change (removing) made to the file.
> > >
> > > How could it be dangerous to install a *missing* configuration file?
> >
> > If the default configuration data in the file do something you don't want.
>
> For example...

Logcheck has a number of files under /etc/logcheck/ignore.d... that are
marked as configuration files. Removing a configuration files means that
more information is present in the log summary. (automaticly) Replacing
these configuration files would result in unwanted behaviour.

- -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE9ZKQgVYan35+NCKcRAoZSAJ4u1IeVFKCujBEuSr3yj9L9CZpCxQCfYgZO
e+MVu8TbK1ViLL5zA6i9ui8=
=W8zs
-END PGP SIGNATURE-

Re: orphaning most (of my) packages

[Javier Fernández-Sanguino Peña]

On Tue, Aug 20, 2002 at 10:43:52PM +0200, Ivo Timmermans wrote:
> Robert van der Meulen wrote:
> > kernel-patch-int (should be superseded by cryptoapi; i can't find the time).
> > 
> > Then there's some ITP's i (enthousiastically) did; i'm going to be closing
> > them too. Interested people can upload and close at will, if they're faster
> > than me: ricochet, loop-aes, cryptoapi, ipsec-tunnel.
> 
> I would like to take over your ITP for cryptoapi.  If noone else wants
> it, I can take kernel-patch-int too.
> 
Now that you are taking them over, some documentation to be
included in the "Debian Securing Manual" regarding these packages could be
useful too BTW. There's currently not a single paragraph on how to setup
these patches to the kernel in Debian.

Regards

Javi

Re: When bind9 reinstalls, no db.root

[Colin Watson]

On Thu, Aug 22, 2002 at 01:18:35AM -0700, Marc Singer wrote:
> On Thu, Aug 22, 2002 at 08:47:46AM +0100, Colin Watson wrote:
> > On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:
> > > As far as I can tell there is no way to pass --force-confmiss to dpkg
> > > when using apt-get.  Perhaps this is the only real omission.  
> > 
> > Sure there is: it's something like -o DPkg::Options=--force-confmiss.
> 
> OK.  You got me.  Is there any hope that's you'll at least cede that
> that's not as straightforward as we *could* be?

Yep, certainly.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: When bind9 reinstalls, no db.root

[Arthur de Jong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 22 Aug 2002, Arthur de Jong wrote:

> > For example...
>
> Logcheck has a number of files under /etc/logcheck/ignore.d... that are
> marked as configuration files. Removing a configuration files means that
> more information is present in the log summary. (automaticly) Replacing
> these configuration files would result in unwanted behaviour.

Oh I just thought of a better one: a lot of packages have configfiles in
/etc/cron.{daily,monthly,weekly}. Removind a configfile is clearly not the
same as having a default in this case.

Bluntly overwriting the db.root file is also not a good idea since some
people use alternative root nameservers. If you screwed up your package
configuration you should do:
  apt-get --purge remove bind9
  apt-get install bind9
(maybe apt-get --purge --reinstall install bind9 would be nice)
You either replace you whole configuration or just your binaries. I don't
think tat changing dpkg to do vodoo for you is a good idea.

- -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE9ZKg+VYan35+NCKcRAoRDAKDpCk9sGyA1IhYEOx4uYSNfaivl3gCdHu+d
8wFw7M3PKUaMpmIiSTbEz3s=
=8G62
-END PGP SIGNATURE-

Re: ELF extension for starting symbol search from module dependencies

[Jakub Jelinek]

On Thu, Aug 22, 2002 at 10:35:33AM +0200, Maciej W. Rozycki wrote:
> On 21 Aug 2002, Luca Barbieri wrote:
> 
> > This is a proposal (including patches) for a GNU extension to the ELF
> > executable format that adds a flag that causes the dynamic loader to
> > start searching for symbols referenced by modules with the flag set from
> > the module itself and its immediate dependencies. If the symbol is not
> > found in this way, the dynamic linker continues the search as usual. 
> > 
> > This extension would be useful to allow to load in the same address
> > space multiple libraries that define identical symbols, that would be
> > used by different modules possibly unaware of each other's use of such
> > symbols. 
> 
>  Hmm, what if two functions which get imported from different versions of
> the same library operate on a static (private to the library) variable
> that is needed for a proper operation for some reason?  You'd better
> rebuild the sources to use a single version of each library instead. 

Or, even better, introduce symbol versioning for libpng.so and maintain it
ABI compatible from this point on...

Jakub

Re: When bind9 reinstalls, no db.root

[Marc Singer]

On Wed, Aug 21, 2002 at 10:19:49PM -0400, Scott K. Ellis wrote:
> > Still, breaking bind's access to root name servers is particularly
> > troublesome because it may tend to break all net access.  It may be
> > worthwhile to remove db.root from the list of configuration files.
> > Especially, because this list isn't something anyone should need to
> > change.
> 
> I beg to disagree.  Changing db.root is the primary way to use an alternate
> DNS root (either for an all-internal DNS, or to utilize an alternate DNS
> root than NetSol's).  Just because you can't see why something might be
> configured differently doesn't mean other people can't.

One can change the database reference in named.conf to do this.  The
difference is that db.root references 'the' root servers.  You can
choose which ones you want to use in the zone file:

  // prime the server with knowledge of the root servers
  zone "." {
  type hint;
  file "/etc/bind/db.alternative_root";
  };

The trouble with removing db.root is that it may not be obvious how to
recover when it is missing.

Re: orphaning most (of my) packages

[Robert van der Meulen]

Quoting Mako Hill ([EMAIL PROTECTED]):
> > razor   ('needed' by spamasassin; needs updating)
> 
> I've check out the bug list and the package and I'd like to take this
> on unless some more qualified wants it.

Taken - sorry ! :)

Greets,
Robert
-- 
( o>  Linux Generation  

pgpRxLKmXujIV.pgp
Description: PGP signature

Re: orphaning most (of my) packages

[Robert van der Meulen]

Quoting Thorsten Sauter ([EMAIL PROTECTED]):
> > libphp-adodb (a php database abstraction layer, required for 'acidlab')
> 
> I'll like to adopte the libphp-adodb package from you.

Too late :/

Greets,
Robert
-- 
( o>  Linux Generation  

pgpJU3s4BF443.pgp
Description: PGP signature

¡°ËÉÆÕ¡±ÎªÄúµÄ²¼Ïß·½°¸ÌṩǿÓÐÁ¦µÄÖ§³ÖÓë±£ÕÏ

[¡°ËÉÆÕ¡±---ÎâÌÎ]

总经理：
   你好！
   国际知明品牌“松普”为您的布线方案提供强有力的支持与保障。
   
   深圳市百年松普信息技术有限公司，是一家研发、生产、销售宽
带网络接入设备及为不同行业客户提供定制化高性价比的"宽带网络
连接"解决方案的高科技公司，是英国百年投资顾问集团与台湾上市
公司松普科技（SUNPU Technology Co., Ltd.）在中国大陆的合作
公司，为"松普"品牌布线系列产品在中国地区的市场研究、推广、行
销、服务、支持的机构，向各类客户提供具有绝对质高价优的高性能
的产品。现在深圳设有二家工厂。
   
   根据宽带网络的发展趋势，我们向客户提供高性价比的的产品：
   1、超五类、六类屏蔽及非屏蔽双绞线。
   2、接插元件。
   3、连接配件等。
   
   松普布线产品及应用系统，最长可扩展至一百年性能品质保证，
该保证由我公司通过中国人民保险公司承担，使您在网络上的投资，
获得最大的保障。
   欢迎浏览我们的网站：http://www.broadlinker.com
   或者电话与我们联系，索取更详细的资料。
   我们将有专业的人员为您服务。
   联系电话：0755-8366441183664422 83664433
   传真：0755-83664499
   联 系 人：吴  涛   13823338529
   E---mail: [EMAIL PROTECTED]


==

中资源公司http://www.net001.net 提供域名先注册后付款;主机先开通后收费服务,
中途可退款。特惠推荐：域名+100M主机并附送5个10M企业邮箱，每年只需350元！！

使用极星邮件群发，无须通过邮件服务器，直达对方邮箱，速度绝对一流！
下载网址：http://www.lovexin.com，更多免费的超酷软件等你来下……;

Re: When bind9 reinstalls, no db.root

[David Schmitt]

On Wed, Aug 21, 2002 at 01:08:53PM -0700, Marc Singer wrote:
> Without a single example, I don't see how installing a configuration
> file where there is none can have *any* affect on the system.

Removing /etc/snmp/snmpd.conf causes snmpd to _NOT_ start.

Reinstalling the conffile would reenable snmpd, which is - given the
history of snmp-related security-problems - dangerous.


Regards, David
-- 
Afrika kommt nach Europa. Das ist der Kontinentaldrift. Da kann man auch
mit einem neuen Asylgesetz nichts dagegen machen. Das sollte mal wer
denen von der FPÖ erklären!
-- Dieter Nuhr (www.nuhr.de) in der Wiener Remise, 2002-08-02


pgpmc4wfwv0wW.pgp
Description: PGP signature

先开发满意后付款

[北航\清华\华中科大开发团队]

如果本邮件不是你所需要的，我们表示抱歉，请随手删除或按回复删除
++
 业务说明（先提供服务，客户满意后再付款）

我们是powersoftteam软件团队，我们的成员来自北航与清华的软件工程的硕士以及博士，我们在北京、广州、深圳、上海等都有工作室，我们提供如下服务：
1、客户关系管理（CRM）、进削存系统、销售管理系统、办公自动化系统（OA）、文挡管理系统、ERP、MRP、MIS等各类软件的定制开发，我们可以提交源程序，我们有这方面丰富的经验与众多的成功案例；
2、各类行业性软件的开发以及系统集成（例如：电信的网管软件、医院的信息管理系统、校园管理系统、酒店信息管理系统……）；
3、电子政务、电子商务等大型系统的开发；
4、专业为国内人士提供软件破解和加密服务，破解效果可以达到两个层次，一个是密码或使用期限制的解除，另一个层次是在以上基础上进一步按客户需求修改软件界面，方便客户按照自己的习惯使用。方便大家使用国内外价格高达几万、几十万的大型或专业软件。该项服务需要客户简单介绍软件并提供未破密的软件的下载地址或光盘方式；
5、专业为本土软件提供加密保护；本工作室保障良好的破解和加密质量，充分满足用户的需求！
6、我们承接全国各地的以上方面的业务！

联系方式：powersoftteam软件团队[EMAIL PROTECTED]  [EMAIL PROTECTED]
（与我们联系，请按照以上两个邮件地址，不要直接回复你所接收到的邮件）
++
  备注

1、我们可以给最终用户开发，也可以给软件公司或相关企业开发，客户可以在我们软件上面指明为客户自己开发（既软件版权可以给客户）
2：我们不提供破解工具和培训教程，考虑到操作问题，暂时不提供单片机、IC芯片和CPU的破解服务；
3：单价人民币5000元以下的软件，建议购买正版或请我们进行开发，我们不提供破解服务；
4：不出售大众软件、源代码和注册号，请勿来信索取；
5：不提供网站和电子邮箱的密码破解服务

联系方式：powersoftteam软件团队[EMAIL PROTECTED]  [EMAIL PROTECTED]
（与我们联系，请按照以上两个邮件地址，不要直接回复你所接收到的邮件）
++
请保留此邮件以备不时之需

Re: RFC: OpenLDAP and TLS/SSL

[Panu A Kalliokoski]

On Wed, Aug 21, 2002 at 07:11:52PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Aug 2002, Luca Barbieri wrote:
> > This is an another problem that would be easily and compatibly solved by
> > my ELF extension (until the library gets properly fixed upstream).
> Yes and no. Versioned symbols are here NOW and can be used NOW, and they fix
> the issue cleanly without drawbacks:  they are as painful as a
> do-it-only-once global soname increase (which is quite painful though).

If "versioned symbols" means including the versions of the dependencies
in the SONAME, the biggest drawback I see is that it using it will
render all libraries binary-incompatible with programs / libraries
developed elsewhere... or have I missed something?

In the sense of "being a widely-adopted standard", versioned symbols are
*not* here now. 

Panu

Re: When bind9 reinstalls, no db.root

[Matt Zimmerman]

On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:

> This terse reply is obviously inappropriate.  If you are annoyed, stop
> writing.

No less appropriate than your one-line dismissal of a reasonable and tactful
response.

> I was asking for real examples in order to discuss how the case of bind
> and db.root is *not* a member of that set and how there may be a genuine
> problem with the handling of installing over missing configuration files.

Are you saying that you think that the situation with this particular
conffile is different enough, and that there are enough other similar
conffiles, that it justifies different handling by dpkg?  If so, I think
that I would disagree.

In the particular case of BIND, it is entirely reasonable to move the entire
configuration somewhere else (such as into a chroot) and remove /etc/bind
and its contents.  It would be confusing to have them reappear when BIND is
upgraded.

> As far as I can tell there is no way to pass --force-confmiss to dpkg
> when using apt-get.  Perhaps this is the only real omission.  

man 5 apt.conf, search for 'dpkg', 6th match.

> Still, breaking bind's access to root name servers is particularly
> troublesome because it may tend to break all net access.  It may be
> worthwhile to remove db.root from the list of configuration files.
> Especially, because this list isn't something anyone should need to
> change.

The conffile system does nothing to break BIND's access to root nameservers;
this only happens if an administrator explicitly removes db.root.  If this
was an accident, they need to reinstall with --force-confmiss.  If not, then
their change is preserved as it should be.  What purpose would be served by
making db.root not a conffile?

-- 
 - mdz

DVD(DivX)´Ù¿îÁ· ¸Å´Ï¾Æ ºÐµé¿¡°Ô...

[adult82.com]

!!! 무조건 환불 합니다. !!!
가입후 둘러보시고 마음에 들지 않으시면 무조건 환불합니다.
1400 GB 이상의 DVD급 동영상이 앞으로 계속 업데이트 됩니다.
지금 현재 20GB 이상 업로드 완료가 되어있습니다.
다운만 받아가시면 됩니다.
1주일에 최소 5GB 이상씩 계속 추가 됩니다.
!!! 돈만 챙기고 막상 볼것 없는 기존 성인싸이트에 속지 마시기 바랍니다. !!!
매니아 이신 분들은 무슨 말인지 잘 아실것입니다.
DVD급 화질의 600MB 이상의 Full 동영상 입니다.
많은 매니아 분들... 예를 들어 팝폴더 같은곳에서 어차피 유료 모드로 다운을 받느니 한번결제로
한달내내 편히 계속 다운받으세요. 얼마를 다운받으시던지 한달동안 계속 사용가능 합니다.
!!! 가입후 둘러보신 후 마음에 들지 않으면 무조건 환불 합니다. !!!
어차피 그리 손해볼것도 없으니 일단 한번 구경이나 해보세요.
-> adult82.com <-
!!! 팝업광고창을 띄우지 않습니다. !!!
본 메일은 메일 수집기와 발송기로 보낸것이 아니라 하나하나 직접 보낸것입니다.
저희 adult82.com 은 스팸 메일을 보내지 않습니다.
한번 발송한 메일은 DB 에서 메일주소가 자동으로 삭제되므로
걱정하지 않으셔도 됩니다.
감사합니다.

Re: ELF extension for starting symbol search from module dependencies

[Luca Barbieri]

On Thu, 2002-08-22 at 08:13, Roland McGrath wrote:
> I think you can get the effect you need just by using -Bsymbolic.  In your
> example, build the GTK+ library with -Bsymbolic.  If that causes problems
> because some of the library's references should be resolved in the normal
> global scope, then confine the code that uses libpng to a wrapper library
> that you build with -Bsymbolic.  Then link the GTK+ library against that
> shared object, and I think you will get the result you need: the GTK+
> library code that uses libpng will be in a DT_SYMBOLIC object and thus
> resolve according to its own dependency on the desired libpng soname,
> while the application is free to link a conflicting libpng in directly.
But -Bsymbolic only puts the module that uses it in front of the search
list so the wrapper will use the library used by the program and will
fail.

You could do this by dlopen'ing libpng and getting symbols from it with
dlsym but this requires source modifications and isn't exactly elegant
(and lazy lookups require even more modifications).



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

Re: ELF extension for starting symbol search from module dependencies

[Luca Barbieri]

>  Hmm, what if two functions which get imported from different versions of
> the same library operate on a static (private to the library) variable
> that is needed for a proper operation for some reason?  You'd better
> rebuild the sources to use a single version of each library instead. 
I don't see how this could cause problems. Each png library should bind
its own references to its own symbols.



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

Re: MailMan Security patch for Woody Broken?

[Tollef Fog Heen]

* Matt Zimmerman 

| If that is the only issue, then it is a simple matter to prepare fixed
| packages which use string.lower('string') rather than 'string'.lower(),
| which should work with both python 1.5 and python 2.x.  Please let me know
| as soon as you are able to test this.

Fixed in proposed-updates now.

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

Re: Next Debconf

[Tollef Fog Heen]

* Joe Drew 

| On Thu, 2002-08-15 at 12:20, Tollef Fog Heen wrote:
| > since nobody else has taken up the thread:
| 
| I long ago declared my intention to organize debconf 3 in montreal or
| vancouver, but I am absolutely not opposed to having the "in-between"
| debconf outside of Canada.

Ok, sorry about that, then.  I guess you'll host debconf4 then. :)

| > I am planning Debconf 3 to be held in Oslo, from Friday July 18th to
| > Sunday July 20th.
| 
| You'll be interested in bug#152529, which details the request for a
| debian-conference list. This will help all debconfs in the future,
| whenever it gets created.

yup, looks good.

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

Re: ELF extension for starting symbol search from module dependencies

[Luca Barbieri]

On Thu, 2002-08-22 at 11:23, Jakub Jelinek wrote:
> On Thu, Aug 22, 2002 at 10:35:33AM +0200, Maciej W. Rozycki wrote:
> > On 21 Aug 2002, Luca Barbieri wrote:
> > 
> > > This is a proposal (including patches) for a GNU extension to the ELF
> > > executable format that adds a flag that causes the dynamic loader to
> > > start searching for symbols referenced by modules with the flag set from
> > > the module itself and its immediate dependencies. If the symbol is not
> > > found in this way, the dynamic linker continues the search as usual. 
> > > 
> > > This extension would be useful to allow to load in the same address
> > > space multiple libraries that define identical symbols, that would be
> > > used by different modules possibly unaware of each other's use of such
> > > symbols. 
> > 
> >  Hmm, what if two functions which get imported from different versions of
> > the same library operate on a static (private to the library) variable
> > that is needed for a proper operation for some reason?  You'd better
> > rebuild the sources to use a single version of each library instead. 
> 
> Or, even better, introduce symbol versioning for libpng.so and maintain it
> ABI compatible from this point on...
Yes, you could compatibly introduce versioning in libraries and continue
to build unversioned binaries and it will work.

However, this introduces a minor ABI modification that will cause
libraries to break if they are used with libraries created by someone
else that decided to do the same but invented a different versioning
scheme.

So this should be done in accordance with the library maintainers and
other distributors while this extension can be introduced immediately
and used until there is a universally accepted plan to add versioning.

Also, libpng is not the only target: this can similarly be used in all
the cases where the library maintainers decide to inconvenience everyone
else by creating two incompatible libraries with conflicting symbols.

BTW, how is RedHat handling this?



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

Re: orphaning most (of my) packages

[Kyle McMartin]

On Thu, Aug 22, 2002 at 11:57:39AM +0200, Robert van der Meulen wrote:
> Too late :/
> 
Has kernel-patch-int been adopted? As one of the upstream authors I
would be glad to take it over.

Regards,
Kyle
-- 
Kyle McMartin


pgpkJ92sIv4YC.pgp
Description: PGP signature

Re: orphaning most (of my) packages

[Robert van der Meulen]

Quoting Kyle McMartin ([EMAIL PROTECTED]):
> On Thu, Aug 22, 2002 at 11:57:39AM +0200, Robert van der Meulen wrote:
> > Too late :/
> > 
> Has kernel-patch-int been adopted? As one of the upstream authors I
> would be glad to take it over.

I have agreed with Ivo ([EMAIL PROTECTED]), that he can take over the package.
If you're interested - or more suitable, or whatever :) - you should discuss
things with him; I Cc'd him on this message.

Greets,
Robert

-- 
( o>  Linux Generation  

pgpK8VEXqAKLR.pgp
Description: PGP signature

gluck is down

[Scott Dier]

To avoid the 'only heard on IRC' problem, gluck is down right now.  I've
been told (via irc) that an HP-er has been notified and that it is being
worked on.

-- 
Scott Dier <[EMAIL PROTECTED]> http://www.ringworld.org/

Re: When bind9 reinstalls, no db.root

[Bernd Eckenfels]

On Wed, Aug 21, 2002 at 11:38:36PM -0700, Marc Singer wrote:
> The trouble with removing db.root is that it may not be obvious how to
> recover when it is missing.

the questions to replace/diff/keep a modified conffile, why dont they apply
to missing conffiles, too?

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: When bind9 reinstalls, no db.root

[Marc Singer]

On Thu, Aug 22, 2002 at 08:44:04AM -0400, Matt Zimmerman wrote:
> On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:
> 
> > This terse reply is obviously inappropriate.  If you are annoyed, stop
> > writing.
> 
> No less appropriate than your one-line dismissal of a reasonable and tactful
> response.

So let me get this straight.  You equate "shut up" with a request for
concrete examples.  How unfortunate.

> 
> > I was asking for real examples in order to discuss how the case of bind
> > and db.root is *not* a member of that set and how there may be a genuine
> > problem with the handling of installing over missing configuration files.
> 
> Are you saying that you think that the situation with this particular
> conffile is different enough, and that there are enough other similar
> conffiles, that it justifies different handling by dpkg?  If so, I think
> that I would disagree.
> 
> In the particular case of BIND, it is entirely reasonable to move the entire
> configuration somewhere else (such as into a chroot) and remove /etc/bind
> and its contents.  It would be confusing to have them reappear when BIND is
> upgraded.

The idea is that db.root is a different kind of file.  Most of the
time, configuration files reflect the personality of the user's
machine.  db.root contains information about the root name servers.  I
would differentiate the presence of this information on a user's
machine with the application of that information.  It has a closer
relationship to terminfo files or the POSIX timezone files than the
global bash rc file.

> 
> > As far as I can tell there is no way to pass --force-confmiss to dpkg
> > when using apt-get.  Perhaps this is the only real omission.  
> 
> man 5 apt.conf, search for 'dpkg', 6th match.

That's a global change.  Someone else pointed out that it can be
passed with -o.

> 
> > Still, breaking bind's access to root name servers is particularly
> > troublesome because it may tend to break all net access.  It may be
> > worthwhile to remove db.root from the list of configuration files.
> > Especially, because this list isn't something anyone should need to
> > change.
> 
> The conffile system does nothing to break BIND's access to root nameservers;
> this only happens if an administrator explicitly removes db.root.  If this
> was an accident, they need to reinstall with --force-confmiss.  If not, then
> their change is preserved as it should be.  What purpose would be served by
> making db.root not a conffile?

Albeit, this isn't a grave consideration, but one that make repairing
a broken name server a little easier.  Because --force-confmiss isn't
a very desirable switch to use, because there is no compelling reason
to keep db.root a configuration file, and because making this change
would make restoring a missing db.root simple it seems that real
question is qhy not?.

Re: exim vs. exim-tiny (was: RFC: OpenLDAP and TLS/SSL)

[Hilko Bengen]

David Pashley <[EMAIL PROTECTED]> writes:

> As the main person in #exim on OPN, I've seen several people ask
> about exim with mysql or postgres support. There is a bug about
> having mysql support in exim in debian. (Wouldn't it be nice to have
> voting in debbugs?). I realise that exim does not have the sanest of
> build systems, but is there any chance of getting two exim packages
> built? 

Yes, there is. It requires quite a few modifications to debian/rules. 
I have done this before for building our internal Exim packages with
embedded Perl support. I just keep multpile EDITME files in the
debian/ directory and have debian/rules copy them as needed.

I have contacted Mark Baker about this before, but he seems not to
have had the time to look at my patches.

-Hilko

Re: When bind9 reinstalls, no db.root

[Matt Zimmerman]

On Thu, Aug 22, 2002 at 10:26:45AM -0700, Marc Singer wrote:

> On Thu, Aug 22, 2002 at 08:44:04AM -0400, Matt Zimmerman wrote:
> > No less appropriate than your one-line dismissal of a reasonable and
> > tactful response.
> 
> So let me get this straight.  You equate "shut up" with a request for
> concrete examples.  How unfortunate.

You are expecting others to do your homework for you.  If you take a casual
look around your system, it should be clear why things are done the way they
are.

> > In the particular case of BIND, it is entirely reasonable to move the
> > entire configuration somewhere else (such as into a chroot) and remove
> > /etc/bind and its contents.  It would be confusing to have them reappear
> > when BIND is upgraded.
> 
> The idea is that db.root is a different kind of file.  Most of the time,
> configuration files reflect the personality of the user's machine.
> db.root contains information about the root name servers.  I would
> differentiate the presence of this information on a user's machine with
> the application of that information.  It has a closer relationship to
> terminfo files or the POSIX timezone files than the global bash rc file.

It sounds like you are arguing that DNS zone files should not be considered
configuration files.  If you read section 11.7.1 of the policy manual, it is
clear that DNS zone files meet the policy manual's definition of
configuration files.

> > > As far as I can tell there is no way to pass --force-confmiss to dpkg
> > > when using apt-get.  Perhaps this is the only real omission.  
> > 
> > man 5 apt.conf, search for 'dpkg', 6th match.
> 
> That's a global change.  Someone else pointed out that it can be
> passed with -o.

I pointed you to the documentation for the configuration option.  You are
complaining that it is a global configuration option, and in the same
paragraph explaining how to set it for a particular invocation.  This does
not make sense to me.

> > The conffile system does nothing to break BIND's access to root
> > nameservers; this only happens if an administrator explicitly removes
> > db.root.  If this was an accident, they need to reinstall with
> > --force-confmiss.  If not, then their change is preserved as it should
> > be.  What purpose would be served by making db.root not a conffile?
> 
> Albeit, this isn't a grave consideration, but one that make repairing a
> broken name server a little easier.  Because --force-confmiss isn't a very
> desirable switch to use, because there is no compelling reason to keep
> db.root a configuration file, and because making this change would make
> restoring a missing db.root simple it seems that real question is qhy
> not?.

If you want a db.root that is easy to restore, file a wishlist bug asking
the maintainer to include a copy of the default db.root in
/usr/share/doc/bind9/examples.

-- 
 - mdz

Re: RFC: OpenLDAP and TLS/SSL

[Roland Bauerschmidt]

Tore Anderson wrote:
> As far as I know, exim is the only package with priority: important that
> depend on libldap2. Howevery, the basic configuration generated by exim's
> postinst doesn't use the LDAP functionality (AFAIK). So, I think exim
> should be fixed so that it doesn't depend on libldap2 anymore.

How about moving postfix to priority important and exim to optional? :)
LDAP support in postfix is already split off into a separate package.
The postfix package still depends on postfix-ldap though. I suppose that
dependency was added to prevent breaking LDAP support on upgrades. Now
that woody is released, couldn't that dependency be dropped?

/me runs

Roland

-- 
Roland Bauerschmidt

Re: Bug#152778: DBS feature request vs dpkg-source v2

[Jeff Bailey]

On Thu, Aug 08, 2002 at 09:22:56AM +1000, Brian May wrote:

> I received this wish list request for dbs.

> Ideally, I want to make the transition as easy as possible from dbs to
> dpkg-source v2 once it comes out of being experimental. So I do not want
> to add new features to dbs that may make this transition harder because
> they are not supported by dpkg-source v2.

> However, I don't have time to look at dpkg-source v2 now, not until it
> becomes feasible to convert Heimdal (and this won't be while uploads are
> being rejected).

> So what should I do with this wishlist request?

Hey Brian, sorry about the delay in responding.  If you're comfortable
that dpkg-source v2 is actually going to see the light in the next 6
months or so, I wouldn't worry about it.  Because it's in
experimental, I haven't looked at it at all, but I've been intending
to move to it as soon as it's even minimally ready.

If you have the feeling that it will take longer than 6 months to hit
unstable, then you should maybe nudge me to write a patch for you. =)

Tks,
Jeff Bailey

-- 
I reincarnated for this?

Re: ELF extension for starting symbol search from module dependencies

[Maciej W. Rozycki]

On 22 Aug 2002, Luca Barbieri wrote:

> >  Hmm, what if two functions which get imported from different versions of
> > the same library operate on a static (private to the library) variable
> > that is needed for a proper operation for some reason?  You'd better
> > rebuild the sources to use a single version of each library instead. 
> I don't see how this could cause problems. Each png library should bind
> its own references to its own symbols.

 Do you suggest your proposed change should only be activated for the png
library? 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+

Re: pam_console for debian

[Sam Clegg]

On Thu, Jul 25, 2002 at 10:23:09AM -0700, David Caldwell wrote:
> Sounds like what you really want is a way to take exclusive access to the 
> camera device somehow. Can you exclusively open the device and prevent 
> others from opening it too? I suppose even that would have a timing 
> splinter: Someone could take exclusive control before you got a chance...

I would like to see someting like this for hotpluggable storage as well.

If I want to keep private data (private keys etc) on a USB keyring I
would like to be sure that nobody else can mount it before me.

Perhaps the hotplug system could implement some kind of method for a
user to say "any device plugged in the next 1 minute is mine".  Clearly
this is vulnerable to DoS by others but this is far better than others
being able to mount your disks/read your photos.

sam
-- 
sam clegg
:: [EMAIL PROTECTED]
:: http://superduper.net/ 
:: PGP :: D91EE369
$superduper: .signature,v 1.5 2002/05/17 10:23:59 samc Exp $


pgp9E4KeulXHJ.pgp
Description: PGP signature

Re: ELF extension for starting symbol search from module dependencies

[Luca Barbieri]

On Thu, 2002-08-22 at 21:35, Maciej W. Rozycki wrote:
> On 22 Aug 2002, Luca Barbieri wrote:
> 
> > >  Hmm, what if two functions which get imported from different versions of
> > > the same library operate on a static (private to the library) variable
> > > that is needed for a proper operation for some reason?  You'd better
> > > rebuild the sources to use a single version of each library instead. 
> > I don't see how this could cause problems. Each png library should bind
> > its own references to its own symbols.
> 
>  Do you suggest your proposed change should only be activated for the png
> library? 
The proposed change is activated for everything that is compiled with
the -Blocal linker option.

For the specific case of libpng, the problem can be solved by linking
libpng.so.2 and libpng.so.3 with -Bsymbolic and all libraries that use
them with -Blocal (alternatively you can also solve this with versioned
symbols but this causes more potential compatibility problems).



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

Re: pam_console for debian

[Russell Coker]

On Thu, 22 Aug 2002 21:46, Sam Clegg wrote:
> On Thu, Jul 25, 2002 at 10:23:09AM -0700, David Caldwell wrote:
> > Sounds like what you really want is a way to take exclusive access to the
> > camera device somehow. Can you exclusively open the device and prevent
> > others from opening it too? I suppose even that would have a timing
> > splinter: Someone could take exclusive control before you got a chance...
>
> I would like to see someting like this for hotpluggable storage as well.
>
> If I want to keep private data (private keys etc) on a USB keyring I
> would like to be sure that nobody else can mount it before me.
>
> Perhaps the hotplug system could implement some kind of method for a
> user to say "any device plugged in the next 1 minute is mine".  Clearly
> this is vulnerable to DoS by others but this is far better than others
> being able to mount your disks/read your photos.

Ivo is apparently taking over crypto-api and hopefully he'll have it in sarge 
soon.  That should solve your problem, just encrypt the device and only the 
user with the password can get access.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

Re: When bind9 reinstalls, no db.root

[Steve Greenland]

On 21-Aug-02, 19:16 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: 
> 
> It does appear that there are a couple of good examples.  In fact,
> this is not one of them since what you ought to ship is a cron.allow
> that blocks everything, right?  

No, because that is not the expected, traditional behaviour in cron. If
I included an empty cron.allow, I'd be inundated by bug reports about
how crontab didn't work.

> As far as I can tell, there aren't many 'dangerous' examples.  A
> package may install a crontab file in cron.d that is deleted by the
> user.  Apparently, apache2 performs directory scanning for
> configuration files, too.  Examples such as BASH are definitely *not*
> dangerous since the default file contains a single, innocuous
> directive.  

While I'll grant you that "dangerous" is probably not the correct
adjective, the current behaviour is correct. Debian policy is that
packages don't override admin modifications to configuration files.
Removing a file is a modification. End of story.

> As I wrote in another message, given that there is an override switch
> in dpkg, that switch would be helpful if available in apt-get.

apt-get --option Dpkg::Options=--force-confmiss 

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: When bind9 reinstalls, no db.root

[Steve Greenland]

On 22-Aug-02, 11:12 (CDT), Bernd Eckenfels <[EMAIL PROTECTED]> wrote: 
> On Wed, Aug 21, 2002 at 11:38:36PM -0700, Marc Singer wrote:
> > The trouble with removing db.root is that it may not be obvious how to
> > recover when it is missing.
> 
> the questions to replace/diff/keep a modified conffile, why dont they apply
> to missing conffiles, too?

Because you only get that question if the distributed version of the 
conffile is changed also.

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: When bind9 reinstalls, no db.root

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>because there is no compelling reason
>to keep db.root a configuration file


But there IS a compelling reason to keep db.root a configuration file:
alternic

I don't use them, but debian shouldn't trash files that a sysadmin needs
to change to use them just because they arn't recomended.

(See http://www.alternic.org/ for info on alternic.  While I have my
problems with the way icann runs the DNS, alternic doesn't show signs
of being run better, just differently.)

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
"Text is a way we cheat time." -- Patrick Nielsen Hayden

Re: When bind9 reinstalls, no db.root

[Marc Singer]

On Thu, Aug 22, 2002 at 01:49:39PM -0700, Blars Blarson wrote:
> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> >because there is no compelling reason
> >to keep db.root a configuration file
> 
> 
> But there IS a compelling reason to keep db.root a configuration file:
> alternic
> 
> I don't use them, but debian shouldn't trash files that a sysadmin needs
> to change to use them just because they arn't recomended.
> 
> (See http://www.alternic.org/ for info on alternic.  While I have my
> problems with the way icann runs the DNS, alternic doesn't show signs
> of being run better, just differently.)

Perhaps the file is poorly named

  db.root -> db.internic-root

IO::Socket::INET question

[Brian May]

Hello, on my mostly woody system, this line in /usr/sbin/amavisd
works fine:

my $sock = IO::Socket::INET->new('127.0.0.1:8127');

However, on another prewoody system where I have upgraded
all of perl and all perl modules to the woody version, it keeps
coming up with the following error:

Cannot determine remote port

Which appears to come from /usr/share/perl/5.6.1/IO/Socket/INET.pm,
in the configure routine. This file is from perl-base, and
it is the same version as in woody, and the same version that works
on all my other systems.

Does anyone have any ideas of why this doesn't work, but only on one
system that appears to be identical to every other system that does
work?

Am I missing some depends from amavis-postfix? I don't think so,
but still, this would be the most obvious source of the problem.

Thanks in advance.
-- 
Brian May <[EMAIL PROTECTED]>

Re: When bind9 reinstalls, no db.root

[Adam Heath]

On Thu, 22 Aug 2002, Steve Greenland wrote:

> apt-get --option Dpkg::Options=--force-confmiss 


apt-get \
 -o Dpkg::Options::=--force-confmiss \
 -o Dpkg::Options::=--force-somethingelse \
 

Note the trailing ::

Re: RFC: OpenLDAP and TLS/SSL

[Henrique de Moraes Holschuh]

On Thu, 22 Aug 2002, Panu A Kalliokoski wrote:
> If "versioned symbols" means including the versions of the dependencies
> in the SONAME, the biggest drawback I see is that it using it will

Nothing of the sort. It stores the soname of the library along with its
symbols, which then become known as soname + symbol.  Dependencies are not
in the scope at all.

> In the sense of "being a widely-adopted standard", versioned symbols are
> *not* here now. 

No, they are not, except where the breakage is so bad even RedHat and the
other vendors can't ignore them with an straight face.  That means libc
(upstream does it), and I believe we (Debian) forced down their throats
versioning for libdb2 and libdb3 as well.

-- 
  "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: IO::Socket::INET question

[Brian May]

On Fri, Aug 23, 2002 at 07:50:21AM +1000, Brian May wrote:
> Which appears to come from /usr/share/perl/5.6.1/IO/Socket/INET.pm,
> in the configure routine. This file is from perl-base, and
> it is the same version as in woody, and the same version that works
> on all my other systems.

Russell Coker suggested I run cruft on the system, and I did so.
It produced a long list of files several screen fulls long.

I found some interesting entries:

sat# grep usr.*perl /tmp/out
/usr/lib/perl5/CGI/Carp.pm
/usr/lib/perl5/CGI/Carp_dist.pm

These files don't seem to exist, I am not sure why cruft reported them.

More importantly:

/usr/lib/perl5/IO/Socket.pm

I strongly suspect this was the cause of my problems.

Anyway I backed up all of these files with:

sat# tar czvf /root/oldperl.tar.gz `grep usr.*perl /tmp/out`

and deleted the originals, and now it seems to work fine.

Thanks!
-- 
Brian May <[EMAIL PROTECTED]>

question about --print-architecture

[Martijn van Oosterhout]

rum$ CC= dpkg --print-architecture
i386-none
rum$ CC=gcc dpkg --print-architecture
i386

flow$ CC= dpkg --print-architecture
i386-none
flow$ CC=gcc dpkg --print-architecture
i386

This is a problem when using make-kpkg because it can't find the
architecture. dpkg complains about i386-none not being in it's mapping
table.

By using HOSTCC=gcc make-kpkg it works fine.

kernel-package version 7.04.potato.3
dpkg version 1.9.9

Thanks,
-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.

proposal for the gcc 3.2 transition

[Jack Howarth]

Hello,
I would like to make a proposal for one aspect of the
gcc 3.2 migration in sid. A critical part of this transition
will be the discovery of how many arches still require creation
of libgcc-compat code in glibc. Currently we are told by Jakub
Jelinek that i386 is fine. Franz Sirl has just finished ppc in
both branches of the glibc cvs. The ia64 arch has a version available
in the glibc trunk that could be backported. Jakub also said alpha
and sparc32 should be fine (not sure if that needs backported from 
the trunk though into glibc-2-2-branch). The rest will have to be
handled by the arch maintainers here.
After talking to Daniel Stone, I found out that the kde 3.0.3
introduction to sid was being delayed until the gcc 3.2 switchover
has occurred. Since the scheme above will greatly delay kde 3.0.3
being added to sid, I would like to propose the following. Assuming
each arch passes their gcc 3.2 testsuite and the most current binutils
is mandated for use with gcc 3.2, we should be able to short-circuit
the process as follows.

1) adjust the debian/control in glibc to build all arches at their
current gcc < 3.1 regardless if gcc 3.2 is installed.
2) switch the gcc-default to gcc 3.2
3) as each arch can demonstrate that their libgcc-compat issues are
resolved, their arch would be switched over in the glibc debian/control
file to build glibc with gcc 3.2.

This approach has the advantages of making the transition to
gcc 3.2 go much faster while removing the need for each arch
to immediately resolve their issues with libgcc-compat. 
 All comments and suggestions are welcome.
 Jack

CMap files to be shared

[Atsuhito Kohda]

Hi all,

PDF-viewers recently can handle CMap files to display
mutibyte characters (CJK, for example).

As far as I know, there are ghostscript(gs-cjk or cmap-adobe-japan1),
xpdf(xpdf-japanese, for example) and dvipdfm-cjk which
provide CMap files independently.

Is it impossible to provide only one set of CMap files to be
shared among these binaries?

As I am not an expert of fonts nor PDF so I might misunderstand
something important.

Best regards,  2002/8/23

-- 
 Debian Developer & Debian JP Developer - much more I18N of Debian
 Atsuhito Kohda <[EMAIL PROTECTED]>
 Department of Math., Univ. of Tokushima