Bug#158013: ITP: libevent-perl -- Generic Perl event loop

[Steve Kowalik]

Package: wnpp
Version: N/A; reported 2002-08-24
Severity: wishlist

  Package name: libevent-perl
  Version : 0.86
  Upstream Author : Joshua Nathaniel Pritikin <[EMAIL PROTECTED]>
  URL : http://search.cpan.org/CPAN/authors/id/J/JP/JPRIT
  License : Same as Perl itself. (GPL, or Artistic)
  Description : Generic Perl event loop
   Provides a simple and optimized event loop for a rather broad number of
   applications. It allows Perl programs to register interest in events that
   concern it, and will recieve those events.

I will upload tomorrow for i386, sparc, hppa and ia64, given there are no
objections.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux broken 2.4.19-k7 #1 Thu Aug 8 23:19:38 EST 2002 i686
Locale: LANG=C, LC_CTYPE=C

-- no debconf information


-- 
   Steve

想做网站的就进来看

[中国服务]

  域名注册主机申请网站建设一条龙为您服务


 中国服务全球专业的域名注册提供商，现推出主机、域名注册优惠服务：

 “特惠1+1企业上网套餐”是中国服务器网络有限公司为您推出的超值服务，

“先服务，后收费！”内容包括：

 　　
  30M asp cgi,php +ACCESS 数据库,送国际顶级域名一个 250元/年

  100M asp cgi,php +ACCESS 数据库,送国际顶级域名一个，只需 350元/年

  200N  asp cgi,php +ACCESS 数据库,送国际顶级域名一个,只需 600元/年  

特惠1+1上网套餐是企业上网，企业商务化的理想选择，现正火爆选购中

 快速度申请(请点击）： http://www.cnserver.com/webmaster/eje-form.htm

欢迎访问我司网站进一步了解：http://www.cnserver.net  http://www.cnserver.com  
http://www.linemail.net

 联系电话:0592-2516932 QQ:93767793

Re: RFC: OpenLDAP and TLS/SSL

[Henrique de Moraes Holschuh]

On Sat, 24 Aug 2002, Brian May wrote:
> On Wed, Aug 21, 2002 at 02:13:47PM -0300, Henrique de Moraes Holschuh wrote:
> > Now, apps often want libsasl2.  ldap uses libsasl1.  nss segfaults. It is
> > the same libdb2/libdb3 hell we had a while back.
> 
> This sounds very similar to breakage that can occur when with
> MIT vs Heimdal libraries.

Nice, new example to add to my ever-growing list.

> Sam Hartman thought there were issues on some architectures when the
> libdb issue was resolved, and it wasn't simply a matter of just using
> versioned symbols.

Well, *every* arch Debian runs on needs proper ld support, and as usual it
is Debian who hits the bugs first. Big deal, they get fixed...

> Maybe this is related to bug #140490?
Err, let me see...

Well, it is rather obvious one wants to version only the symbol he provides,
and not ANY symbols he got from anywhere else.  #140490 is a bug alright,
but not with versioning per si.  It is a bug caused by improper versioning
of symbols one does not 'own'.

> Changing to versioned symbols would also break every binrary
> already around too, I am not sure how to solve this issue.

No, it would not.  It would break NEW binaries if they get installed in OLD
systems without versioned libraries.

-- 
  "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: How to get rid of non-free packers?

[Frank Copeland]

On Fri, 23 Aug 2002 14:06:50 + (UTC), Juhapekka Tolvanen <[EMAIL 
PROTECTED]> wrote:

> How about contacting authors of AmigaOS-versions of LHA?
> 
> http://lha.warped.com/index.html

I was going to point out that the (de)compression routines had been
written in M68K assembly, but according to
 that's no longer the case.

> Maybe they could release those sources under some free licence and then
> somebody could port them to Unix?

May be worth a try. The current maintainer has suggested the
possibility of releasing the source, and since development seems to
have stalled (no new release in 3 years) he may be more open to the
suggestion.

It remains to be seen how easy it is to port code written for a defunct
proprietary (but supposedly ANSI-compliant) compiler on a vaguely
unix-like but non-POSIX OS.

Frank
-- 
Home Page: http://thingy.apana.org.au/~fjc/> 
Not the Scientology Home Page: http://xenu.apana.org.au/ntshp/>

Re: How to get rid of non-free packers?

[Brian May]

On Fri, Aug 23, 2002 at 04:01:15PM +0300, Juhapekka Tolvanen wrote:
> It is not very bad thing if we can't create archives in formats like
> ACE, ARJ, LHA or RAR with free software. But it is more important to

Ideally, amavis needs access for all archive formats so it can check
for viruses in E-Mail...

> ARC:
> 
> This is very old archive-format. We only need some way to unpack those
> files. Fortunately, this was just announced at c.o.l.a:
> 
> http://rus.members.beeb.net/nomarch.html
>
> It is meant to be free replacement for arc. It is under GNU GPL. It can
> also unpack Spark-files (common under Acorn Archimedes).

This is already in Debian.

> P.S: I don't subscribe to mailing-lists of Debian, so please Cc: your
> replies to me. And I am not Debian developer.

Please set your Mail-Followup-To: header correctly in future, that
way mutt will automatically do the right thing.

I think this is off-topic for debian-legal, but I am not sure.
-- 
Brian May <[EMAIL PROTECTED]>

Re: RFC: OpenLDAP and TLS/SSL

[Brian May]

On Wed, Aug 21, 2002 at 02:13:47PM -0300, Henrique de Moraes Holschuh wrote:
> Now, apps often want libsasl2.  ldap uses libsasl1.  nss segfaults. It is
> the same libdb2/libdb3 hell we had a while back.

This sounds very similar to breakage that can occur when with
MIT vs Heimdal libraries.

eg. if ssh-krb5 (which is compiled against MIT kerberos) is told to use
libpam-heimdal, the result is a segmentation fault.

> The proper fix is to have libsasl with versioned symbols, libldap with
> versioned symbols (so that we don't go all over the same problem when
> libldap gets updated -- right now the problem is sasl, not libldap).

How do you do this?

Sam Hartman thought there were issues on some architectures when the
libdb issue was resolved, and it wasn't simply a matter of just using
versioned symbols.

Maybe this is related to bug #140490?

Changing to versioned symbols would also break every binrary
already around too, I am not sure how to solve this issue.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Dock Apps packaging, round 2

[Colin Walters]

On Fri, 2002-08-23 at 19:20, Josselin Mouette wrote:

> gnome-applets contains 5 clocks, I'm proposing 7.

This was a bug; it's been fixed in GNOME 2.

企业商机-尽在商智网络推销软件

[[EMAIL PROTECTED]]

商智网上营销套件





  

  

http://www.webpost.com.cn/images/logo.gif"; 
align="left" width="149" height="46">  山东地区总代理：http://www.qiye.net.cn";>潍坊科信网络发展中心  
销售热线：0536-8583256

  

  

  
商智网上营销套件集中了智能化信息发布和采集、产品推广以及贸易撮合的网络营销软件,是企业开拓市场,获得商机的理想帮手。它具信息搜索、信息发布、邮件搜索、邮件发送四大功能，完整实现网络营销之重中之重邮件营销、交易平台营销两种方案。

  

  
四 
大 功 能

  


商智信息发布 

将产品信息，供求信息几分钟之内同步发布至一千多家相关交易场。客户可随意增加网站，满足不同行业不同需求。中英文兼容，简繁体自动转换，信息内容自动智能生成；配合大型商业数据库，自动在线升级，并以每周新增五十个网站的速度递增。  独创web与软件两种使用形式，随时随地享受商智便捷快速的服务。交易场现已增至1100家。
商智信息搜索

全面搜索产品供求信息，掌握第一手市场资料，搜索信息精确，具二次搜索功能，交易场所现已增至1100家，且已每周50家的速度递增。可自动将搜集来的email地址编辑成册，配合商智邮件发送，将网络营销进行到底。 
商智邮件搜索
领先国内技术，搜索邮件的同时搜索全套公司联系方式。人工智能自动识别任何公司信息、收信人姓名。傻瓜化操作、全模板设置，用户只要(1)选择行业或地域、(2)选择模板，(3)填入关键字，就能实现任何地域的海量精确搜索。可搜索任何综合性网站、行业性网站、交易场如上千个国内外交易场、同学录、国内任何大小黄页。数据精确无误。
商智邮件发送

集成了email服务器，1分钟可发送邮件上百封,自带smtp服务器完成发送目标发送,使对方根本无法拒收。有失败邮件列表，支持发送任务管理、端点续发，十万级的在线邮件屏蔽列表，可以避免不必要的法律纠纷。支持图片群发、信件加密传输，可携带任意数量的附件。支持邮件监控以便客户随时了解发送状况。

  

  
成 功 案 
例

  

我用的是商智网上营销套件，我的软件有四大功能：

一：按关键词、行业、地区搜索邮件地址；目前，我已经储存了超过一千万真实的邮件地址；

二：高速、稳定地发送邮件广告：我的系统能一天二十四小时，一周七天，一年三百六十五天连续运行，风雨无阻；你能找到这样的职员吗？

三：按照产品或关键字在国内、国际网站不断地搜索求购信息，起到立杆见影带动业务的作用；

四：自动将你的产品和服务信息发布到超过一千个大网站上，让数以万计的消费者查阅、点击和浏览。

>--> 
请记住：我邹勇就是成功案例！我用这个产品仅八个月挣了三十万！ 
本产品适合在家上班者（soho一族）、个人创业、小公司、新奇产品；
如果你想低成本、迅速地获得收入，请大胆使用！

 
如果你不希望收到我的信件，请按回复表示删除，在此表示抱歉

  

  
第 三 类 
服 务

  

如果您对网络营销还有疑问，那么请看这里？

我们将提供销售前一个月的服务周期，帮助企业逐步走上成熟的网络营销道路。

具体的服务方法是由我们帮助您开展产品推广与网络营销活动，包括产品信息发布，供求信息搜索，潜在客户邮址搜索，目标客户邮件群发。四个环节，层层递进，促成定单。在一个月的服务周期后，我们还将为客户提供有效的网络营销技巧与方法，真正帮助客户实现网络营销。
产品加服务费：4200元/例(包括一个月的服务以及一套商智软件)。服务周期内，您只需交纳10%作为定金即可。
如果没有任何效果，我们将全额退还!!!

免费试用： http://www.qiye.net.cn/shangzhi";>   
http://www.qiye.net.cn/shangzhi 
电话：0536-8583256
email:mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]
地址：潍坊市健康东街289号


  
山东地区总代理（科信网络）

  
  

Some proposals about the Email-subsystem, was Re: RFC: OpenLDAP and TLS/SSL

[Georg Lehner]

El jue, 22-08-2002 a las 12:47, Roland Bauerschmidt escribió:
...
> How about moving postfix to priority important and exim to optional? :)
> LDAP support in postfix is already split off into a separate package.
...

I planned to start an elaborate proposal for the mailing-subsystem,
however real-live has it busy on my and it will have to wait a while to
polish it.

However, hooked on Rolands remark and Bdale's anouncment of a policy
rewrite at least I want to throw it in in quality of short remarks:

- Opcional MTA's:

Not every system uses an MTA, in fact a wealth of end-user PC's (the
mayority) would be just fine with local delivery, and eventually
utilities to fetch mail from a remote box, and pipe a queue of messages
to a remote server.

On the other hand there are various popular alternatives for MTA's so a
general choice in a lot of cases fails.

Proposal: By default no MTA will be installed.

- Configurable Local Delivery:

The default mail delivery method is to a unix-style mbox in
/var/mail/.

MH-, and even more, Maildir-delivery are often chosen as an alternative
(Maildir is of my interest here). Almost all MTA's and MUA's can
nowadays deal with them, however reconfiguration of the Mail system is
painful.

Proposal:

At some point in the installation process a choice of the default
delivery method can be made.  The choice is recorded e.g. in
/etc/defaults/maildelivery

Al MTA's and MUA's take into account the systems mail delivery method
upon post-installation and configure themselves acordingly, or give a
warning if it is not supported.

--
This two proposals are of high priority in my opinion, now some
proposals which have their "issues" in one or the other way:

- MUA Configuration:

Good old plain-text MUA's almost always support tilde- or environment
variable-expansion, and hence allow to elaborate global- or pre-made
user-configuration files (in /etc/skel), which contain references
relative to the user's home directory.

In "modern" MUA's like Balsa, and Evolution (correct me if I'm right)
absolute path's have to be given in the configuration, requiring a
manual setup of the mail system for every single user.

Proposal:

MUA's in Debian should be patched, or upstream be bothered to do so, so
that they allow tilde and/or environment variable expansion in the
respective configuration files or databases.

MUA's which don't support this features should have a corresponding note
in README.Debian and eventually a popup (with low priority) at
pre-configuration.

- Qmail Interoperability:

Qmail installations grow fast and a lot of Debian Users choose it as
their MTA.  There are source packages *in* Debian, and there are License
compatible binary packages on the net, however they can not be part of
the Debian Distribution because of conflicts with Debian Policy (binary
re-distribution is restricted, in short: no modifications to author's
version allowed).

Qmail's security concept requires seven different unix accounts and two
groups to be created.  Qmail - mailqueues on two systems where the uid's
of these users are different are incompatible - an issue when migrating,
re-installing and with distributed servers with nfs-mounted spools.

Proposal:

Fixed assigned Qmail-users uid's/gid's.

- Mailservice-switch:

The current Internet Mail System is giving increasingly trouble by
inherent problems.  Alternatives exist (qmtp) and are developed (im2000,
as well as others) and in the future a System Administrator (or user)
may want to change the way messages are sent and received in it's
system.

Also, the actual way of installing an alternative MTA on a Debian system
is "take it or leave it" - there is only one MTA installed at one time
and it has to be removed to install an alternative.

An "alternatives" system could be provided by Debian, that reduces the
MTA's installation/configuration responsabilities from "conflicting" to
cooperating, by dropping sendmail compatiblity on a package level and
introducing it on a global configuration level.

This can be done in a homebrew-fashion with alternatives, or taking into
account the /etc/mta/ configuration switch proposal found at
http://cr.yp.to/etc-mta.html (of course adapted to FHS ;->)

Proposal:

MTA's provide a set of generic, sendmail-compatible executables in
/usr/lib// either as binaries or as symlinks

The actual chosen MTA will be selected by an "alternatives" like method.

-

Best Regards,

Jorge-León

Re: How to get rid of non-free packers?

[Peter De Wachter]

On Fri, Aug 23, 2002 at 04:01:15PM +0300, Juhapekka Tolvanen wrote:
> ACE:
> 
> http://www.winace.com/
> 
> They provide some statically linked Linux-binary for unpacking
> ACE-archives. If that file-format is not very secret, somebody might be
> able to create free unpacking-software for ACE-files. But feel free to
> negotiate with authors of WinAce.

Old versions of ACE came with the source for a simple unpacker. I
believe the only things lacking are support for encrypted and multi-file
archives. It works fine on Linux.

It has the following license:
-- UNACE-SOURCE v1.2b (extract-util) --
the source may be distributed and used, 
but I,Marcel Lemke, retain ownership of
the copyrights to the source.
---

I think this makes it non-free (it doesn't explicitly allow
modifications), but it may help to figure out the algorithm.

You can find it at http://wilma.vub.ac.be/~pdewacht/unace-1.2b.tar.gz

Mvg,
Peter De Wachter

Re: Dock Apps packaging, round 2

[Josselin Mouette]

Le sam 24/08/2002 à 00:40, Jesus Climent a écrit :

> The main difference is that gnome-applets does not contain 30 clocks, 20
> network status applets, 35 battery status applets... while OTOH your
> package system will end up in a complete set of clocks... to use 1 or
> not at the end.

gnome-applets contains 5 clocks, I'm proposing 7.

> I would go, in any case, for a set of complete dockapps, keeping 1 or 2
> of the different areas, but not more.

The problem is that the perfect dockapp for every task doesn't exist.
Also, you should have read after the "dockapps-clock" proposal, because
the other proposed bundles are like what you describe.
Still, you pointed that there are too many clocks, and I have to agree
with that.

> Or even a metapackage which lets you select from different clocks/net
> status apps/battery status/... and installs the ones you select.
> 
> Could be text based, or using a graphical frontend

Well, with screenshots of the dockapps running, this could be nice,
indeed.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: PGP signature

Re: Make python2.2 the python default

[Matthias Klose]

Anthony Towns writes:
> On Fri, Aug 23, 2002 at 11:33:10PM +1000, Donovan Baarda wrote:
> > On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote:
> > > I'm planning to make python2.2 the python default version for unstable
> > > next week (uploading the packages on 2002-08-28). Preliminary packages
> > > can be found at
> > >   http://ftp-master.debian.org/~doko/python/
> > > Please send packaging problems with the packages to debian-python.
> > Are these then going to propogate into testing in the normal manner (all
> > dependencies met, no conflicts, no bugs etc)?
> > I hope so :-)
> 
> Ha. Haha. Hahahahahaha.
> 
> (You're going to have to get _everything_ that has a "python-"
> all in sync, including everything it depends on, with no RC bugs all at
> the same time, and keep it that way for a week... Well, it's not quite that
> bad, but it's close)

That's the price we have to be able use /usr/bin/python, not the
versioned binary :-(

Re: Make python2.2 the python default

[Matthias Klose]

Mark Brown writes:
> On Sat, Aug 24, 2002 at 12:21:41AM +1000, Donovan Baarda wrote:
> 
> > I would say yes. We need 2.1 in sarge at least, so that each generation of
> > Debian still has support for the previous generation's standard python.
> 
> Why?  If you're upgrading then you can always leave the 2.1 packages
> installed can't you?

zope-2.5.1 needs 2.1

Re: Dock Apps packaging, round 2

[Jesus Climent]

On Sat, Aug 24, 2002 at 12:05:50AM +0200, Josselin Mouette wrote:
> 
> Second, there is the famous... TADA ! Packages file size !
> While this shouldn't be a limit for what we package, we can't increase
> its size indefinitely. This one of the reasons why the gnome applets
> were put in a single package. I think the dockapps problem is a good
> example to think about what to do with the Packages file : we can "save"
> tens of packages by using bundles, or increase their number by a score.
> So we have to decide now what to do : either we begin to save some
> packages to avoid a too big Packages file, or we find NOW another way of
> downloading the debs list. If we keep the things the way they are going,
> APT will probably be unusable in sarge+1.

The main difference is that gnome-applets does not contain 30 clocks, 20
network status applets, 35 battery status applets... while OTOH your
package system will end up in a complete set of clocks... to use 1 or
not at the end.

I would go, in any case, for a set of complete dockapps, keeping 1 or 2
of the different areas, but not more.

Or even a metapackage which lets you select from different clocks/net
status apps/battery status/... and installs the ones you select.

Could be text based, or using a graphical frontend

my .02 euros.

-- 
Jesus Climent | Unix System Admin | Helsinki, Finland.
http://www.HispaLinux.es/~data/  |  data.pandacrew.org
--
Please, encrypt mail address to me: GnuPG ID: 86946D69
FP: BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69
--
Registered Linux user #66350 Debian 3.0 & Linux 2.4.19

Don't "Sir" me young man, you have no idea who you're dealing with.
--Kay (Men in Black)


pgp1cuDojHhi6.pgp
Description: PGP signature

Re: Dock Apps packaging, round 2

[Adam Heath]

On Fri, 23 Aug 2002, Sean 'Shaleh' Perry wrote:

> Or
> remove all of the Java packages since we still don't have a free Java
> implementation.

kaffe/gcj.

Re: Dock Apps packaging, round 2

[Sean 'Shaleh' Perry]

On Friday 23 August 2002 03:05 pm, Josselin Mouette wrote:
> Second, there is the famous... TADA ! Packages file size !
> While this shouldn't be a limit for what we package, we can't increase
> its size indefinitely. This one of the reasons why the gnome applets
> were put in a single package. I think the dockapps problem is a good
> example to think about what to do with the Packages file : we can "save"
> tens of packages by using bundles, or increase their number by a score.
> So we have to decide now what to do : either we begin to save some
> packages to avoid a too big Packages file, or we find NOW another way of
> downloading the debs list. If we keep the things the way they are going,
> APT will probably be unusable in sarge+1.
>

The problem is most packages in Debian will not benefit from this style of 
packaging.  So you take 10,040 packages and have 10,000 packages.  No real 
win.  If we start heading down this road we might as well kill all of the 
-doc packages and stop splitting libraries into libfoo and libfoo-dev.  We 
could also remove all of the perl modules since CPAN also has them.  Or 
remove all of the Java packages since we still don't have a free Java 
implementation.  Then we could just choose KDE or GNOME and remove the other 
one along with things like ROX.  And so on.  But that is not the Debian I 
joined and I doubt that is really what you want either.

I agree there is a problem with how we currently deal with our packages and 
the archive.  But it is a techical problem requiring a technical solution.  
Making a few bundle packages is just like putting a bandage on a gaping 
wound.

Re: Dock Apps packaging, round 2

[Josselin Mouette]

Le ven 23/08/2002 à 22:31, Sean 'Shaleh' Perry a écrit :

> And as I told Josselin when he started this -- so what.  Let the old school 
> group complain all they want.  I have always enjoyed that Debian's developers 
> are also its users and largely we are user driven.  If I want to package 
> something I will, even if it is small and simple.
> 
> We have a beautiful packaging system which supports tasks and meta packages 
> and we should use it.

We can use meta packages for those packages, it would even be simpler
for me. But it has two drawbacks : first, users will have lots of little
packages installed, making things unclear ; also, they probably won't
deinstall packages they don't use. (These are only suppositions, but I
don't think our average user takes care of 3 MB of unused packages.) So
little packages are advantages for some users, but mainly a pain for
some other users.
Second, there is the famous... TADA ! Packages file size !
While this shouldn't be a limit for what we package, we can't increase
its size indefinitely. This one of the reasons why the gnome applets
were put in a single package. I think the dockapps problem is a good
example to think about what to do with the Packages file : we can "save"
tens of packages by using bundles, or increase their number by a score.
So we have to decide now what to do : either we begin to save some
packages to avoid a too big Packages file, or we find NOW another way of
downloading the debs list. If we keep the things the way they are going,
APT will probably be unusable in sarge+1.

Greetings,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: PGP signature

Re: How to get rid of non-free packers?

[Adam Heath]

On Fri, 23 Aug 2002, Juhapekka Tolvanen wrote:

> [snip]

I've been working on an interface to several archive formats.  Currently, I
have .ar, .cpio(binary and compat) and .tar(sysv, gnu, posix).  I've used it
to make a .deb with pure java code, and then install it with dpkg.

I'm currently adding .cab support.

The present implementation is in java, but I plan on porting to perl/python/c
when I get the right amount of features done.

I don't consider a format implemented, until I have both reading and writing
done, AND test cases for it.

The name of this project is Altar(Abstract Library To ARchives).  It's not yet
released.

Re: Dock Apps packaging, round 2

[Sean 'Shaleh' Perry]

On Friday 23 August 2002 01:12 pm, Bas Zoetekouw wrote:
> Hi Sean!
>
> You wrote:
> > Asking maintainers to give up their packages so you can bundle them
> > just seems wrong.  Why not just make your bundles be meta packages?
>
> Because people keep complaining about ITP's of packages they consider
> crap and that are bloating the Packages files, according to those
> people.

And as I told Josselin when he started this -- so what.  Let the old school 
group complain all they want.  I have always enjoyed that Debian's developers 
are also its users and largely we are user driven.  If I want to package 
something I will, even if it is small and simple.

We have a beautiful packaging system which supports tasks and meta packages 
and we should use it.

Re: Dock Apps packaging, round 2

[Bas Zoetekouw]

Hi Sean!

You wrote:

> Asking maintainers to give up their packages so you can bundle them
> just seems wrong.  Why not just make your bundles be meta packages?  

Because people keep complaining about ITP's of packages they consider
crap and that are bloating the Packages files, according to those
people.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

re: First experience with gcc-3.2 recompiles

[Jack Howarth]

Gerhard,
   I would be cautious about installing a gcc-3.2-built glibc
unless you first purge your system of all binaries that
were built with gcc < 3.1. Jakub Jelinek said he was uncertain
if s390/s390x was an arch that would require a libgcc-compat
be added to glibc. If a libgcc-compat is required you will
see certain old binaries fail under the new gcc 3.2 built
glibc. According to Jakub you can see if this will be the
case by doing the following...


>Basically, you take the list of libgcc.a (formerly) exported symbols
>and scan all binaries/libraries if they have undefined references to any
>of these symbols (as libc.so exports those on ia32/sparc and a few
>others only, they will not be exported on other arches from libc, thus
>are resolved to some unintentionally exported symbol in some other library
>which is going away after rebuild with 3.2).
>
>Jakub

...on a machine built entirely with a gcc < 3.1. If you do
find that binaries are showing undefined references to 
any of the libgcc symbols (which are now .hidden in gcc >= 3.1)
you need to construct a sysdeps/s390/libgcc-compat.c or .S
that makes these libgcc symbols available for run-time
resolution (but not exporting them for linking). 
   Hope that helps.
Jack

Out of Office AutoReply: Look,my beautiful girl friend

[Recruitment]

Thank you for your interest in Liggett Vector Brands Inc.  We have
received your email and will review all resumes.  Only those candidates
whose qualifications meet our current hiring requirements will be
contacted.  Please do not contact us for further confirmation or to
check status.

Re: How to get rid of non-free packers?

[Drew Scott Daniels]

On Fri, 23 Aug 2002, Juhapekka Tolvanen wrote:

>
> When I run command "vrms" in my Debian GNU/Linux, most of those non-free
> packages it finds are packers and/or unpackers. How about you? I like to
>
There may be patent issues. I'd check with the authors of the archivers.
Additionally reading the compression newsgroup FAQ may provide some
information regarding archivers and patents. Mark Nelson also recently
commented that Unisys's patent on LWZ will be expiring soon. I'd check
into that if it's applicable to any archiver you're looking at.

A good list of archivers for DOS/Windows and Macs can be found through
http://www.compression.ca and http://www.datacompression.info

>
> It is not very bad thing if we can't create archives in formats like
> ACE, ARJ, LHA or RAR with free software. But it is more important to
> have free software for unpacking of those archives. If we want to create
> new archives, we can always use free software like GNU tar, gzip and
> Bzip2 and tell other people to use some free or non-free software to
> unpack them. .tar-, .tar.gz-, .gz- and even .bz2- and .tar.bz2-files are
> well understood by many general-purpose archivers, like Winzip,
> PowerArchiver, UltimateZip and Stuffit. And GNU Tar, gzip and Bzip2
> themselves have been ported to many Operating systems already (Unixes
> (both free and proprietary), Windows, MacOS, AmigaOS, OS/2 etc.)).

In
http://lists.debian.org/debian-user/2002/debian-user-200207/msg04836.html
I talk a bit about archivers and compression. An interesting archiver that
I'd like to become part of debian is Charles Bloom's ppmz2 (found at
http://www.cbloom.com ), but I believe it's license is currently not
Debian compatible (it may be good for non-free).

> ZOO:
>
> IMHO creating new ZOO-archives is not very important for us.
>
Some BBS sysops (if there still are any) may require zoo, especially for
fidonet like networks.

> ARJ:
>
> http://testcase.newmail.ru/
>
> It is under GNU GPL. I think it can also create ARJ-archives.
>
https://sourceforge.net/projects/arj is also under the GNU GPL and is
worth looking at too.

>
> RAR:
>
> http://www.unrarlib.org/
>
> that commandline tool. I don't know, if source code of that library
> has some code from Eugene Roschal.
>
Maybe it's worth asking Eugene Roschal (roshal at rarlab.com)? I'd check
the resources available at http://www.rarlab.com/rar_add.htm such as
http://www.rarlab.com/rar/unrarsrc.tar.gz tucow's gpl'd console un-rar may
be based on this code.

> LHA:
>
If desired I'll check more into this archiver (again useful in ways zoo is
useful).

> ACE:
>
> They provide some statically linked Linux-binary for unpacking
> ACE-archives. If that file-format is not very secret, somebody might be
> able to create free unpacking-software for ACE-files. But feel free to
> negotiate with authors of WinAce.
>
Worth a try if anyone feels this is worth while. I haven't really seen
much packed with ace and ace doesn't rank well on
http://www.compression.ca

> ARC:
>
> This is very old archive-format. We only need some way to unpack those
> files. Fortunately, this was just announced at c.o.l.a:
>
> http://rus.members.beeb.net/nomarch.html
>
> It is meant to be free replacement for arc. It is under GNU GPL. It can
> also unpack Spark-files (common under Acorn Archimedes).
>
Interesting. For several people to be involved I would image that research
relating to patents and other lha archivers would have already been done
so I won't do any checking unless requested to.

 Drew Daniels

I'm looking for work. If you can help see:
http://home.cc.umanitoba.ca/~umdanie8/resume.html

Re: How to get rid of non-free packers?

[Juhapekka Tolvanen]

On Fri, 23 Aug 2002, +16:01:15 EEST (UTC +0300),
Juhapekka Tolvanen <[EMAIL PROTECTED]> pressed some keys:

Wow! wotsit.org have some docs about archive file formats, too:

http://www.wotsit.org/search.asp?s=archive

http://www.wotsit.org/search.asp?page=2&s=archive


Docs about format of LHA or LZH is here:

http://www.osirusoft.com/joejared/lzhformat.html

It has also some links to LHA-related WWW-pages.

I just got an idea: What if some old version of LHA has free enough
licence, so somebody could could create better free LHA-software out of
it? I mean that maybe somebody could do OpenSSH-like things with LHA.


-- 
Juhapekka "naula" Tolvanen * * University of Jyväskylä * * [EMAIL PROTECTED]
http://www.cc.jyu.fi/~juhtolv/index.html * * * * "STRAIGHT BUT NOT NARROW!!"
"Vesi hakkaa minua maahan, kuin tuhat lekaa ja miljoona vasaraa. Niinkuin
lauletaan, niin happi räjähtää ja kauniista kaunein kädet ojentaa." Apulanta

Re: How to get rid of non-free packers?

[Branden Robinson]

On Fri, Aug 23, 2002 at 04:01:15PM +0300, Juhapekka Tolvanen wrote:
> When I run command "vrms" in my Debian GNU/Linux, most of those non-free
> packages it finds are packers and/or unpackers.

While not the best team in their league, I think you'll find that even
the Packers aren't so bad that they play for free.



-- 
G. Branden Robinson|
Debian GNU/Linux   | Music is the brandy of the damned.
[EMAIL PROTECTED] | -- George Bernard Shaw
http://people.debian.org/~branden/ |


pgptmrr2EHKI7.pgp
Description: PGP signature

seeking information

[Shubyn Bhandari]

Dear sir,
 Iam one of the undergradute international student from Nepal, but now I am 
studying Aeronautics in Florida Tech, USA with 20% scholarship.Still I am 
not able to afford the cost.
Iam looking for the sponsor who can help me at this situation. So that I can 
fully concentrate on my studies. Please can you help me to find a sponsor. 
It will be grate.
Thanks.

_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: Dock Apps packaging, round 2

[Sean 'Shaleh' Perry]

On Friday 23 August 2002 11:03 am, Josselin Mouette wrote:
> After the little discussion 2 weeks ago about the packaging of dock
> apps, I come with a proposal.
>
> Granularity is good. Until now, all dock apps have been packaged
> separately to achieve best granularity. However, this is growing to an
> impressive number of packages, which both bloats the archive and lacks
> of convenience for users. Furthermore, toy/funny dockapps are often not
> packaged, as they are often very simple and qualified as "useless crap"
> on this list.
> To solve this, an approach similar to that of the gnome-applets package
> is proposed, except that, due to the number of dockapps that can be
> included, there would be several packages. To put in these bundles, I
> have selected a number of dockapps, with these conditions :
> 1) Being "popular" : I considered dock apps that are already in the
> archive, dock apps that were the most downloaded on
> http://dockapps.org/, and also dockapps that I would like to package ;)
> Of course, the selection is very subjective, and this is the right place
> to flame me if you think some choices are inappropriate, or if you would
> like to see other dockapps in these bundles.
> 2) Having no dependencies, other than xlibs and libdockapp. Note that,
> as many dockapps not using libdockapp share a file named wmgeneral.c, I
> will try to make a library with it (I say "try", because many dockapps
> use different versions of this file, with sometimes some incompatible
> changes).

Modifying upstream sources is quite wrong.  Now if you would like to tie this 
in with #3 and become the upstream for many of these and clean them all up, 
great.

> 3) Not being actively maintained upstream. This is the case of most of
> dockapps, as they represent a small amount of code and are based on
> stable APIs.
>

Asking maintainers to give up their packages so you can bundle them just seems 
wrong.  Why not just make your bundles be meta packages?  I would much rather 
see a package maintained by someone who actually uses it and is thus capable 
of dealing with bug reports.  That's what Debian has always been about -- the 
developers using what they package.

I used to maintain wmixer and recently gave it over to another devel who is 
actively working on it.  Asking him to give up his work just because you want 
to make neat, pretty packages is plain silly.

Re: Dock Apps packaging, round 2

[Jesus Climent]

On Fri, Aug 23, 2002 at 08:03:59PM +0200, Josselin Mouette wrote:
> After the little discussion 2 weeks ago about the packaging of dock
> apps, I come with a proposal.
> 
> The proposed packages include many of the dockapps already in the
> archive. Of course, if the current maintainer of a dockapp package
> doesn't want me to bundle the dockapp, I will skip it, and put it in the
> Recommends field instead.
> 
> So, here are the bundle propositions. I have put a * after dockapps
> already packaged.
> 
> - dockapps-clocks :

7 entries

> - dockapps-monitor :

~15 entries

> - dockapps-net :
> - dockapps-sound :
> - dockapps-toys :

same here

> - dockapps-utils :

even more here

> Considering dockapps with binary sizes in the 20-100KB range, this
> should make packages of accpetable sizes.
> 
> Finally, two meta-packages :
> - dockapps, which would depend on all the above
> - dockapps-extra, which would depend on dockapps + almost all dockapps

So it would mean that if I am looking for just one clock or just one
specific monitor I will have to install and keep installed (unless I
manually erase them) 7 clocks and 15 monitors.

It was (IIRC) agreed that we will package every dock and we will create
bundles of specific functionality, to maybe install all of them, try
them, select the one we like and erase the rest, using small packages.

Please, correct me if I am wrong.

J

-- 
Jesus Climent | Unix System Admin | Helsinki, Finland.
http://www.HispaLinux.es/~data/  |  data.pandacrew.org
--
Please, encrypt mail address to me: GnuPG ID: 86946D69
FP: BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69
--
Registered Linux user #66350 Debian 3.0 & Linux 2.4.19

It's called a change-over. The movie goes on and nobody knows the 
difference.
--Narrator (Fight club)


pgpp5pBpQwUDu.pgp
Description: PGP signature

Re: How to get rid of non-free packers?

[Juhapekka Tolvanen]

On Fri, 23 Aug 2002, +19:26:12 EEST (UTC +0300),
Clint Adams <[EMAIL PROTECTED]> pressed some keys:

> > So, where is that public-domain software for extracting ZOO-files?
> > Somebody must find it and then create Debian-package of it. IMHO
> > creating new ZOO-archives is not very important for us.
> 
> IIRC, the ZOO extracters were Ooz and Looz.

Cool! With a little help from FTP Search, that was moved to Alltheweb, I
wandered to the garbo.uwasa.fi:

http://garbo.uwasa.fi/cgi-bin/gsearch.cgi?search_string=ooz&ignore_case=&search_section=pc&maxmatch=100

http://garbo.uwasa.fi/cgi-bin/gsearch.cgi?search_string=ooz&ignore_case=&search_section=unix&maxmatch=100

ftp://garbo.uwasa.fi/unix/arcers/booz.Z


-- 
Juhapekka "naula" Tolvanen * * University of Jyväskylä * * [EMAIL PROTECTED]
http://www.cc.jyu.fi/~juhtolv/index.html * * * * "STRAIGHT BUT NOT NARROW!!"
"Vesi hakkaa minua maahan, kuin tuhat lekaa ja miljoona vasaraa. Niinkuin
lauletaan, niin happi räjähtää ja kauniista kaunein kädet ojentaa." Apulanta

Dock Apps packaging, round 2

[Josselin Mouette]

After the little discussion 2 weeks ago about the packaging of dock
apps, I come with a proposal.

Granularity is good. Until now, all dock apps have been packaged
separately to achieve best granularity. However, this is growing to an
impressive number of packages, which both bloats the archive and lacks
of convenience for users. Furthermore, toy/funny dockapps are often not
packaged, as they are often very simple and qualified as "useless crap"
on this list.
To solve this, an approach similar to that of the gnome-applets package
is proposed, except that, due to the number of dockapps that can be
included, there would be several packages. To put in these bundles, I
have selected a number of dockapps, with these conditions :
1) Being "popular" : I considered dock apps that are already in the
archive, dock apps that were the most downloaded on
http://dockapps.org/, and also dockapps that I would like to package ;)
Of course, the selection is very subjective, and this is the right place
to flame me if you think some choices are inappropriate, or if you would
like to see other dockapps in these bundles.
2) Having no dependencies, other than xlibs and libdockapp. Note that,
as many dockapps not using libdockapp share a file named wmgeneral.c, I
will try to make a library with it (I say "try", because many dockapps
use different versions of this file, with sometimes some incompatible
changes).
3) Not being actively maintained upstream. This is the case of most of
dockapps, as they represent a small amount of code and are based on
stable APIs.

The proposed packages include many of the dockapps already in the
archive. Of course, if the current maintainer of a dockapp package
doesn't want me to bundle the dockapp, I will skip it, and put it in the
Recommends field instead.

So, here are the bundle propositions. I have put a * after dockapps
already packaged.

- dockapps-clocks :
pclock*
wmbeats
wmcalclock*
wmclock*
wmdate*
wmitime*
wmtz*

- dockapps-monitor :
asmon*
wmavgload*
wmcpu*
wmcpuload*
wmcube*
wmfire*
wmfsm*
wmload*
wmmemload*
wmmemmon*
wmsmpmon*
wmsysmon*
wmtop*

- dockapps-net :
wmail (this is NOT wmmail)
wmifinfo*
wmifs*
wminet*
wmisdn
wmisdncid
wmmultipop3
wmnd*
wmymail
wmnet*
wmnetselect*
wmpload* (if I can get rid of the dependency on ppp)
wmppp.app*
wmwave*
xlassie*

- dockapps-sound :
ascd*
mixer.app*
volume.app*
wmcdplay*
wmix*
wmmixer*
wmmp3 (will need a wrapper to test if mpg123 is installed)
wmrack*
wmradio
wmrecord
wmscope*
wmsmixer
wmtune (if it ever works - this dockapp is slightly old and I cannot
test it without a radio card)

- dockapps-toys :
wmbio*
wmeyes
wmfirew
wmflame
wmfortune (will need a wrapper to test if fortune is installed)
wmjulia
wmmand*
wmmatrix*
wmmoonclock*
wmomikuzi
wmpuzzle*
wmtictactoe*
wmtetris

- dockapps-utils :
nonlock*
ticker.app*
temperature.app
washerdryer
wmappl
wmbutton*
wmcalc*
wmcb*
wmcp
wmfrog
wmlpq
wmmount*
wmnetscapekiller*
wmpinboard*
wmplot
wmswallow
wmwork*
wmxres*
wmsetimon*

Considering dockapps with binary sizes in the 20-100KB range, this
should make packages of accpetable sizes.

There could be two other bundles, with more dependencies, but I don't
know if it's worth the deal :

- dockapps-power :
wmab
wmacpi*
wmapm*
wmbattery*
xbatt*

- dockapps-xmms :
wmalbum
wmusic*
wmxmms-spectrum*
xmms-wmdiscotux*

Finally, two meta-packages :
- dockapps, which would depend on all the above
- dockapps-extra, which would depend on dockapps + almost all dockapps
that are packaged separately.

Comments are welcome.

Greetings,
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: PGP signature

Bug#157975: ITP: unzoo -- zoo archive extractor

[Thomas Schoepf]

Package: wnpp
Version: N/A; reported 2002-08-23
Severity: wishlist

* Package name: unzoo
  Version : 4.4
  Upstream Author : Martin Schoenert
* URL : 
http://archives.math.utk.edu/software/multi-platform/gap/util/
* License : Public Domain
  Description : zoo archive extractor

A zoo archive is a file that contains several files, called its
members, usually in compressed form to save space. 'unzoo' can list
all or selected members or extract all or selected members, i.e.,
uncompress them and write them to files. It cannot add new members or
delete members. For this you need the zoo archiver, called 'zoo'.


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux ganymed 2.4.19 #1 Fri Aug 9 16:07:14 CEST 2002 i686
Locale: LANG=C, LC_CTYPE=de_DE

Re: apt-get wants to upgrade package to same version?

[Ludovic Rousseau]

Le mercredi 21 août 2002 à 13:28:30, Brian May a écrit:
> Hello,

Hi,

> I have just being playing around with apt-proxy, and noticed something
> weird. Every time I run apt-get, it wants to upgrade the packages it
> just upgraded 5 seconds ago (it only happens on this computer, too):

[..]

> scrooge:/tmp# apt-cache policy kerberos4kth1
> kerberos4kth1:
>   Installed: 1.1-11-2
>   Candidate: 1.1-11-2
>   Version Table:
>  1.1-11-2 0
>  -1 http://snoopy.apana.org.au unstable/main Packages
>  1.1-11-2 0
> 700 http://snoopy.apana.org.au woody/main Packages
>  *** 1.1-11-2 0
> 100 /var/lib/dpkg/status
>  1.1-8-2 0
> 700 http://snoopy.apana.org.au woody/updates/main Packages
> 700 http://snoopy.apana.org.au woody/non-US/main Packages

I have just had the same problem (with different packages).

$ apt-cache policy libpisock8
libpisock8:
  Installed: 0.11.3-2
  Candidate: 0.11.3-2
  Version Table:
 0.11.3-2 0
500 http://http.us.debian.org unstable/main Packages
 0.11.3-2 0 
990 http://people.debian.org woody/. Packages
 *** 0.11.3-2 0   
100 /var/lib/dpkg/status

And apt-get wanted to reinstall the same packages again and again.

$ sudo apt-get -s upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be upgraded
  libpisock++0 libpisock8 pilot-link
3 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
Inst libpisock8 (0.11.3-2 Backports from sid:3.0/stable)
Inst libpisock++0 (0.11.3-2 Backports from sid:3.0/stable)
Inst pilot-link (0.11.3-2 Backports from sid:3.0/stable)
Conf libpisock8 (0.11.3-2 Backports from sid:3.0/stable)
Conf libpisock++0 (0.11.3-2 Backports from sid:3.0/stable)
Conf pilot-link (0.11.3-2 Backports from sid:3.0/stable)


After I changed the order of the lines in /etc/apt/sources.list the
"bug" was corrected.

I now have:

$ apt-cache policy libpisock8
libpisock8:  
  Installed: 0.11.3-2
  Candidate: 0.11.3-2
  Version Table:
 *** 0.11.3-2 0
990 http://people.debian.org woody/. Packages
100 /var/lib/dpkg/status
 0.11.3-2 0
500 http://http.us.debian.org unstable/main Packages

from sources.list(5) you can read:
  "The file lists one source per line, with the most preferred source
  listed first."

Try to reorder your sources.list file.

Hope this helps.

Regards,

-- 
 Dr. Ludovic Rousseau[EMAIL PROTECTED]
 -- Normaliser Unix c'est comme pasteuriser le Camembert, L.R. --

Re: How to get rid of non-free packers?

[Clint Adams]

> So, where is that public-domain software for extracting ZOO-files?
> Somebody must find it and then create Debian-package of it. IMHO
> creating new ZOO-archives is not very important for us.

IIRC, the ZOO extracters were Ooz and Looz.

Re: Menu system rewrite update (Aug 6 2002)

[Thimo Neubauer]

On Tue, Aug 20, 2002 at 09:26:55AM +0200, Andreas Tille wrote:
> On Mon, 19 Aug 2002, Joey Hess wrote:
> 
> > Andreas Tille wrote:
> > > In fact you are right.  I would vote for a mandatory menu entry for every
> > > program which has a user interface.
> >
> > I "vote" that you get to write the menu file for gnuplot, which after
> > all has a graphical user interface, if it's fed the proper data file.
> Well, gnuplot has in fact a user interface even if is just a text
> interface.  This could be opened via menu (even if I admit that this
> makes not much sense).

Sorry to interrupt your speculations about a gnuplot menu-entry but
it's been in the package for ages (about 1997)... Yes, opening a xterm
with the gnuplot commandline inside is a bit strange but nobody ever
complained and at least it can be found that way.

IMHO the menu is more a way of showing the user which programs are
installed on the machine, thus the entry makes (at least a bit of)
sense.

CU
 Thimo

-- 
Thimo Neubauer <[EMAIL PROTECTED]>
Debian GNU/Linux 3.0 "woody" is finally released! CD-Images are
available via http://cdimage.debian.org/, for detailed information 
about Debian see http://www.debian.org/


pgpvKJSDzKrRs.pgp
Description: PGP signature

报价单

[pzning]

请把你们的报价单发一份给我

Re: ELF extension for starting symbol search from module dependencies

[Luca Barbieri]

>  Then you have to deal with consistency issues.  They do not exist for
> self-contained libraries that act locally only like png, but they may
> arise with libraries that interact with the outer world, e.g. any that
> makes use of networking.  For example using different versions of the X11
> library by different parts of a process will certainly lead to surprises.
Well, yes, this doesn't work if the conflicting libraries structures are
exported by the libraries that use them.
In this case the structures become part of the ABI of the intermediary
library, so the situation is similar to a program linking directly to
two conflicting libraries.
However, this often isn't the case.



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

Re: Make python2.2 the python default

[Anthony Towns]

On Fri, Aug 23, 2002 at 11:33:10PM +1000, Donovan Baarda wrote:
> On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote:
> > I'm planning to make python2.2 the python default version for unstable
> > next week (uploading the packages on 2002-08-28). Preliminary packages
> > can be found at
> > http://ftp-master.debian.org/~doko/python/
> > Please send packaging problems with the packages to debian-python.
> Are these then going to propogate into testing in the normal manner (all
> dependencies met, no conflicts, no bugs etc)?
> I hope so :-)

Ha. Haha. Hahahahahaha.

(You're going to have to get _everything_ that has a "python-"
all in sync, including everything it depends on, with no RC bugs all at
the same time, and keep it that way for a week... Well, it's not quite that
bad, but it's close)

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.''


pgpG7OCLQuErh.pgp
Description: PGP signature

Re: ELF extension for starting symbol search from module dependencies

[Maciej W. Rozycki]

On 22 Aug 2002, Luca Barbieri wrote:

> >  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.

 Then you have to deal with consistency issues.  They do not exist for
self-contained libraries that act locally only like png, but they may
arise with libraries that interact with the outer world, e.g. any that
makes use of networking.  For example using different versions of the X11
library by different parts of a process will certainly lead to surprises.

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

Re: Make python2.2 the python default

[Mark Brown]

On Sat, Aug 24, 2002 at 12:21:41AM +1000, Donovan Baarda wrote:

> I would say yes. We need 2.1 in sarge at least, so that each generation of
> Debian still has support for the previous generation's standard python.

Why?  If you're upgrading then you can always leave the 2.1 packages
installed can't you?

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Is there a limitation on swap parition size linux can use?

[Vincent Renardias]

On Fri, 23 Aug 2002, Walter Tautz wrote:

> I heard that 2Gb is the limit.

Used to be the case. Dunno if it still applies to 2.4 kernels through...

> If so I would have to create distinct swap partitions if I wanted to
> have more than 2Gb swap? Just wondering...

Yes. (I used to do this with the very early Linux kernels when the swap
partition size was limited to 128MB.

Cordialement,

--
Vincent RENARDIAS
Directeur Technique
StrongHoldNET / http://www.strongholdnet.com

Re: Make python2.2 the python default

[Bastian Kleineidam]

On Fri, Aug 23, 2002 at 03:26:00PM +0200, Jérôme Marant wrote:
>   Any reason to keep 2.1 ?
It would make the transition somewhat easier for NMUs, as you
would only have to update the dependencies.

Tschööö, Bastian

-- 
Bastian Kleineidam · [EMAIL PROTECTED] · GPG key ID 32EC6F3E


pgpPEXd8t3vCu.pgp
Description: PGP signature

Re: Make python2.2 the python default

[Donovan Baarda]

On Fri, Aug 23, 2002 at 03:26:00PM +0200, J?r?me Marant wrote:
> On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote:
> > I'm planning to make python2.2 the python default version for unstable
> > next week (uploading the packages on 2002-08-28). Preliminary packages
> > can be found at
> > 
> > http://ftp-master.debian.org/~doko/python/
> > 
> > Please send packaging problems with the packages to debian-python.
> > 
> > When preparing packages for multiple versions of python, please drop
> > python1.5 support and consider providing support for the experimental
> > python2.3 packages.
> 
>   Any reason to keep 2.1 ?

I would say yes. We need 2.1 in sarge at least, so that each generation of
Debian still has support for the previous generation's standard python.

Under the new policy having the old packages hang around doesn't hurt us in
any way except chew up disk space... these packages don't even need to be
mantained unless serious bugs are found in them, at which point it probably
does become easier to dispose of them rather than fix them.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--

Is there a limitation on swap parition size linux can use?

[Walter Tautz]

I heard that 2Gb is the limit. If so I would have
to create distinct swap partitions if I wanted to
have more than 2Gb swap? Just wondering...


-walter

Re: CMap files to be shared

[Hamish Moffatt]

On Fri, Aug 23, 2002 at 10:53:38AM +0900, Atsuhito Kohda wrote:
> 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?

I compared the contents of the CMap directory in xpdf-japanese and the
cmap-adobe-japan1 packages. xpdf-japanese contains a few additional
maps. Also, the maps in the xpdf package are dated 2001 while the
cmap-adobe-japan1 package's files are dated 1998.

If the cmap package can be updated it may be possible to remove the maps
from the xpdf-japanese package. Similarly for the other xpdf-* language
packages.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Make python2.2 the python default

[Donovan Baarda]

On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote:
> I'm planning to make python2.2 the python default version for unstable
> next week (uploading the packages on 2002-08-28). Preliminary packages
> can be found at
> 
>   http://ftp-master.debian.org/~doko/python/
> 
> Please send packaging problems with the packages to debian-python.

Are these then going to propogate into testing in the normal manner (all
dependencies met, no conflicts, no bugs etc)?

I hope so :-)

BTW, what is happening with python-central... is it becoming standard? If
so, the pythonX.X packages will need to use it.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--

Re: Make python2.2 the python default

[Jérôme Marant]

On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote:
> I'm planning to make python2.2 the python default version for unstable
> next week (uploading the packages on 2002-08-28). Preliminary packages
> can be found at
> 
>   http://ftp-master.debian.org/~doko/python/
> 
> Please send packaging problems with the packages to debian-python.
> 
> When preparing packages for multiple versions of python, please drop
> python1.5 support and consider providing support for the experimental
> python2.3 packages.

  Any reason to keep 2.1 ?

  Cheers,

-- 
Jérôme Marant

Re: When bind9 reinstalls, no db.root

[Hamish Moffatt]

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.  

Fortunately it is still possible and legal to run dpkg directly.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Next Debconf

[Ola Lundqvist]

On Thu, Aug 15, 2002 at 06:20:08PM +0200, Tollef Fog Heen wrote:
> * Andreas Tille 
> 
> | So I would suggest when the organizers of Debconf2 and some people from
> | Skandinavia would agree to organize a conference those to parties should
> | find an agreement where to meet in 2003 and where in 2004.
> 
> since nobody else has taken up the thread:
> 
> I am planning Debconf 3 to be held in Oslo, from Friday July 18th to
> Sunday July 20th.

Interesting. I'v just moved a bit closer to Oslo (now Karlstad, before
Linkping - in Sweden) so maybe I can help some. At least it makes it
easier for me to get there. :)

> Joeyh hess mentioned a good idea in the DebConf2 post-mortem thread:
> 
> : What I wouldn't mind seeing is 2 or 3 days either before or after
> : the next one that lack talks and are just there for ad-hoc
> : discussion and face time and hacking. It was nice to have the talks
> : but I really went for the other 3 items. Call it 'debcamp' or
> : something. Extra organizational overhead should be near-zero; the
> : people who stay on for debcamp just use the same facilities as does
> : the conference.
> 
> Since this will be the weekend after cofsino (Conference on Free
> Software in Norway), I'll try to get a debcamp thingy before DebConf.
> Hopefully it can be a full week, but I guess people can show up in the
> middle of the week if they'd like to.

Nice.

> Please don't ask for a lot of details yet -- things are still
> forming.  I'll post stuff on d-d-a when they are ripe.

Look forward for it.

> If you want to hold a presentation, don't hesitate to contact me.

I'll think about it.

Regards,

// Ola

> -- 
> Tollef Fog Heen,''`.
> UNIX is user friendly, it's just picky about who its friends are  : :' :
>   `. `' 
> `-  
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

How to get rid of non-free packers?

[Juhapekka Tolvanen]

When I run command "vrms" in my Debian GNU/Linux, most of those non-free
packages it finds are packers and/or unpackers. How about you? I like to
listen to music modules made under Amiga and many of those modules are
distributed in Aminet as LHA-archives. Sometimes I use DOS and its
software may be distributed as ARJ- or RAR-archives.

Of course free GUI-software like FileRoller can unpack many formats, but
actually most of them are just graphical front-ends for command-line
archivers, both free and non-free.

It is not very bad thing if we can't create archives in formats like
ACE, ARJ, LHA or RAR with free software. But it is more important to
have free software for unpacking of those archives. If we want to create
new archives, we can always use free software like GNU tar, gzip and
Bzip2 and tell other people to use some free or non-free software to
unpack them. .tar-, .tar.gz-, .gz- and even .bz2- and .tar.bz2-files are
well understood by many general-purpose archivers, like Winzip,
PowerArchiver, UltimateZip and Stuffit. And GNU Tar, gzip and Bzip2
themselves have been ported to many Operating systems already (Unixes
(both free and proprietary), Windows, MacOS, AmigaOS, OS/2 etc.)). I
have collected many links to archivers in the end of this WWW-page:

http://www.cc.jyu.fi/~juhtolv/mswordmail.html

But now back to the original problem:

 * * *

ZOO:

/usr/share/doc/zoo/copyright says:

"Currently, all extract-only programs, and all supporting utili-
ties, are fully in the public domain and are expected to remain so
for the forseeable future."

So, where is that public-domain software for extracting ZOO-files?
Somebody must find it and then create Debian-package of it. IMHO
creating new ZOO-archives is not very important for us.

 * * *

ARJ:

Here is free implementation of it:

http://testcase.newmail.ru/

It is under GNU GPL. I think it can also create ARJ-archives.

 * * *

RAR:

http://www.unrarlib.org/

This is kinda complicated. It is dual-licenced software. One of those
licences is GNU GPL. But please read that FAQ:

http://www.unrarlib.org/faq.html

It is just a library for extracting RAR-files. So somebody must create
some commandline tool that can unpack RAR-files and uses unrarlib for
that. Then somebody can create Debian-package of both unrarlib and
that commandline tool. I don't know, if source code of that library
has some code from Eugene Roschal.

 * * *

LHA:

Here is relevant sections from /usr/share/doc/lha/copyright

 Clip here 

Translated License Statement (translated by GOTO Masanori
<[EMAIL PROTECTED]>):

   It's free to distribute on the network, but if you distribute for
   the people who cannot access the network (by magazine or CD-ROM),
   please send E-Mail (Inter-Net address) to the author before the
   distribution. That's well where this software is appeard.
   If you cannot do, you must send me the E-Mail later.

 Original Source Code License Statement:

   /*Copyright (C) MCMLXXXIX Yooichi.Tagawa  */
   /*ModifiedNobutaka Watazaki   */
   /*   Thanks to H.Yoshizaki. (MS-DOS LHarc)*/

 Clip here 

I think, only way to get free unpacking software for LHA-files is to
negotiate with those Japanese persons. Here are some URL of Japanese
LHA-software:

http://shibuya.cool.ne.jp/lha/

http://www2m.biglobe.ne.jp/~dolphin/lha/lha.htm

How about contacting authors of AmigaOS-versions of LHA?

http://lha.warped.com/index.html

Maybe they could release those sources under some free licence and then
somebody could port them to Unix?

 * * *

ACE:

http://www.winace.com/

They provide some statically linked Linux-binary for unpacking
ACE-archives. If that file-format is not very secret, somebody might be
able to create free unpacking-software for ACE-files. But feel free to
negotiate with authors of WinAce.

 * * *

ARC:

This is very old archive-format. We only need some way to unpack those
files. Fortunately, this was just announced at c.o.l.a:

http://rus.members.beeb.net/nomarch.html

It is meant to be free replacement for arc. It is under GNU GPL. It can
also unpack Spark-files (common under Acorn Archimedes).

 * * *

P.S: I don't subscribe to mailing-lists of Debian, so please Cc: your
replies to me. And I am not Debian developer.


-- 
Juhapekka "naula" Tolvanen * * University of Jyväskylä * * [EMAIL PROTECTED]
http://www.cc.jyu.fi/~juhtolv/index.html * * * * "STRAIGHT BUT NOT NARROW!!"
"Vesi hakkaa minua maahan, kuin tuhat lekaa ja miljoona vasaraa. Niinkuin
lauletaan, niin happi räjähtää ja kauniista kaunein kädet ojentaa." Apulanta

Bug#157944: ITP: libmpeg2 -- free library for decoding mpeg-2 and mpeg-1 video streams

[Robert Millan]

Package: wnpp
Version: N/A; reported 2002-08-23
Severity: wishlist

* Package name: libmpeg2
  Version : 0.2.1
  Upstream Author : Aaron Holtzman <[EMAIL PROTECTED]> and others
* URL : http://libmpeg2.sourceforge.net/
* License : GPL
  Description : free library for decoding mpeg-2 and mpeg-1 video streams

 The main goals in libmpeg2 development are:

 * Conformance - libmpeg2 is able to decode all mpeg streams that conform to
 certain restrictions. For streams that follow these restrictions, libmpeg2 is
 probably 100% conformant to the mpeg standards - and there's a pretty
 extensive test suite to check this.

 * Speed - there has been huge efforts there, and libmpeg2 is probably the
 fastest library around for what it does.

 * Portability - most of the code is written in C, and when platform-specific
 optimizations are used, there always is a generic C routine to fall back on.
 This should be portable to all architectures - at least we have heard reports
 from people running this code on x86, ppc, sparc, arm and sh4.

 * Reuseability - libmpeg2 is not intended to include any project-specific
 code, but it should still include enough features to be used by very diverse
 projects.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux aragorn 2.2.21 #1 Thu Aug 8 13:53:32 CEST 2002 i586
Locale: LANG=ca_ES.ISO-8859-1, LC_CTYPE=ca_ES.ISO-8859-1

-- no debconf information

Make python2.2 the python default

[Matthias Klose]

I'm planning to make python2.2 the python default version for unstable
next week (uploading the packages on 2002-08-28). Preliminary packages
can be found at

http://ftp-master.debian.org/~doko/python/

Please send packaging problems with the packages to debian-python.

When preparing packages for multiple versions of python, please drop
python1.5 support and consider providing support for the experimental
python2.3 packages.

Thanks, Matthias

Re: What's up with testing??

[Anthony Towns]

On Fri, Aug 23, 2002 at 08:27:15PM +1000, Mark Purcell wrote:
> Can anyone advise why packages aren't getting though into testing?
> 
> On Fri, 23 Aug 2002 12:30, Cron Daemon wrote:
> >  * hpoj (0.8-11 to 0.90-1)
> >   + Maintainer: Mark Purcell
> >   + 13 days old (needed 10 days)
> >   + Valid candidate
> >   + Depends: hpoj glibc
^^^

hpoj needs a newer version of glibc than what's in testing. Follow
the links.

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: What's up with testing??

[Erich Schubert]

> Can anyone advise why packages aren't getting though into testing?
> >   + Depends: hpoj glibc

Dependencies.
glibc is holding them back.

Greetings,
Erich

What's up with testing??

[Mark Purcell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Can anyone advise why packages aren't getting though into testing?

Thanks,
Mark

On Fri, 23 Aug 2002 12:30, Cron Daemon wrote:

>  * hpoj (0.8-11 to 0.90-1)
>   + Maintainer: Mark Purcell
>   + 13 days old (needed 10 days)
>   + Valid candidate
>   + Depends: hpoj glibc
>  * smstools (1.7.0-1 to 1.7.1-2)
>   + Maintainer: Mark Purcell
>   + 18 days old (needed 10 days)
>   + Valid candidate
>   + Depends: smstools mm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9Zg4HoCzanz0IthIRAmZ7AJ9osCBV783uvJDey3M8o7VkFwGlyQCfWfWO
7HcWLekhzoVpqOgqVNw7VZE=
=AOrp
-END PGP SIGNATURE-

Dev arþive

[Murat 2]

TrMelodi, Kýrýk linkli çalýþmayan ve birtek mp3 ü indirirken bile insanlarý 
kahreden sözde mp3 sitelerine alternatif 
olarak sizler için özenle hazýrlanmýþtýr. Her yaþtan her kesimden müziksevere 
hitap edebilmek için tasarlanmýþ 13 GB 
lýk dev Mp3 listesiyle sýnýfýnda rakipsiz olacak þekilde donatýlmýþ ve siz 
müzikseverlerin hizmetine sunulmuþtur. 
http://www.trmelodi.com adresindeki dev arþivimizde sizi bekleyen en sevdiðiniz 
sanatçýlarýn en sevdiðiniz 
þarkýlarýný birkaç dakika içinde bilgisayarýnýza indirin ve keyifle dinlemeye 
baþlayýn. 

Ýyi Eðlenceler.. 
http://www.trmelodi.com

Re: question about --print-architecture

[Josip Rodin]

On Fri, Aug 23, 2002 at 10:08:19AM +1000, Martijn van Oosterhout wrote:
> 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

If it's still a problem, file a bug on kernel-package asking to switch to
dpkg-architecture.

-- 
 2. That which causes joy or happiness.

First experience with gcc-3.2 recompiles

[Gerhard Tonn]

As I have told in another thread, I am currently rebuilding all packages 
depending on c++ on s390. All packages have been touched now. The results are:

406 packages have been built successfully
222 packages depend on other packages built with gcc-3.2
   90 on qt libraries
   12 on libsigc++
 7 on gtkmm
 9 on fltk
 ...
246 packages haven't been built successfully

In most cases a compile error similar to

default argument given for parameter 12 of ...
after previous specification in ...

occurs.

The build logs of the packages can be found at
http://people.debian.org/~gt/gcc-3.2_transition


Gerhard

Unidentified subject!

[MR.Johnson S. Abu]

CENTRAL BANK OF NIGERIA
FOREIGN REMITTANCE DEPT.
TINUBU SQUARE, LAGOS  NIGERIA
[EMAIL PROTECTED]
23TH OF August 2002

ATTN:PRESIDENT/CEO


STRICTLY PRIVATE BUSINESS PROPOSAL
I am MR.Johnson S. Abu, the bills and exchange Director at the
ForeignRemittance Department of the Central Bank of Nigeria.  I am 
writingyou
this letter to ask for your support and cooperation to carrying thisbusiness
opportunity in my department.  We discovered abandoned the sumof
US$37,400,000.00 (Thirty seven million four hundred thousand unitedstates
dollars) in an account that belong to one of our foreign customers,an
American
late Engr. John Creek (Junior) an oil merchant with the federal government
of
Nigeria who died along with his entire family of a wifeand two children in
Kenya Airbus (A310-300) flight KQ430 in November2000.

Since we heard of his death, we have been expecting his next of kin tocome
over
and put claims for his money as the heir, because we cannotrelease the fund
from his account unless someone applies for claims asthe next  of kin to the
deceased as indicated in our banking guidelines. Unfortunately, neither
their
family member nor distant relative hasappeared to claim the said fund.  Upon
this discovery, I and other officialsin my department have agreed to make
business with you release the totalamount into your account as the heir of
the
fund since no one came forit or discovered either maintained account with
our
bank, other wisethe fund will be returned to the bank treasury as unclaimed
fund.

We have agreed that our ratio of sharing will be as stated thus: 30%for
you as
foreign partner and 70% for us the officials in my department.

Upon the successful completion of this transfer, my colleague and I
willcome to
your country and mind our share. It is from our 60% we intendto import
computer
accessories into my country as way of recycling thefund.  To commence this
transaction we require you to immediately indicateyour interest by calling
me
or sending me a fax immediately on the aboveTelefax # and enclose your
private
contact Telephone #, Fax #, full nameand address and your designated
banking co-
 ordinates to enable us fileletter of  claim to the appropriate department
for
necessary approvalsbefore the transfer can be made.

Note also, this transaction must be kept strictly confidential becauseof its
nature.

NB: Please remember to give me your Phone and Fax No

MR.Johnson Smith  Abu