Re: Make python2.2 the python default

2002-08-24 Thread Donovan Baarda
On Sat, Aug 24, 2002 at 12:52:33AM +0200, Matthias Klose wrote:
> 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)

I realise that, I just wanted to make sure there were no special plans to
hold it back from testing.
 
> That's the price we have to be able use /usr/bin/python, not the
> versioned binary :-(

This is also the benefit... it can't go into testing until it's ready.

I think it would be possible for an updated python to drop into testing with
a handful of python- packages holding them back... just file an RC bug
against them saying they need to be upgraded, they vanish from testing, and
the updated stuff drops in.

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




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

2002-08-24 Thread Eduard Bloch
#include 
* Peter De Wachter [Sat, Aug 24 2002, 01:25:54AM]:

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

Worse. I considered packaging it (*) but stopped after discussing the
license issue. You are only allowed to use the source, nothing is said
about the binary created. Looks like the qmail-src story.

(*) while extending the support in the unp 

Gruss/Regards,
Eduard.
-- 
Linux - aus klaren Quellen wird ein starker Strom.




Re: png2/3 problem apparently successfully solved with -Bsymbolic

2002-08-24 Thread Junichi Uekawa
On Tue, 20 Aug 2002 14:53:56 -0500

> >sing -Bsymbolic ensures that whenever the libpng library makes a call to
> one of its own functions, the symbol is resolved internally instead of to
> another version of libpng that's loaded.  This may account for a majority
> of the segfaults that people are seeing.  It does not affect how symbols
> are resolved when something /outside/ of libpng tries to call a function
> belonging to libpng.

I am yet to see a segfault caused by libpng[23].

regards,
junichi


[1] http://www.netfort.gr.jp/~dancer/software/downloads/png-danger -- libpng3 
without 
  version checks, to allow libpng2-compiled applications to work with libpng3.



-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer






Re: When bind9 reinstalls, no db.root

2002-08-24 Thread Anthony DeRobertis
On Wed, 2002-08-21 at 16:08, 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.

Off the top of my head, try "ls -ld /etc/cron.* /etc/*.d" That should
give you a very incomplete list of directories in which it might happen.



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


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

2002-08-24 Thread Marcelo E. Magallon
>> Steve Kowalik <[EMAIL PROTECTED]> writes:

 >   URL : http://search.cpan.org/CPAN/authors/id/J/JP/JPRIT

 Just a note, for CPAN modules it's much more useful if one provides a
 link to something like http://search.cpan.org/author/JPRIT/Event-0.86/.
 That gives you a link to the download page, access to other releases
 and to the documentation as well in a much friendlier format.

-- 
Marcelo | "Go ahead, bake my quiche"
[EMAIL PROTECTED] | -- Magrat instructs the castle cook
|(Terry Pratchett, Lords and Ladies)




Re: Dock Apps packaging, round 2

2002-08-24 Thread Marcelo E. Magallon
>> Josselin Mouette <[EMAIL PROTECTED]> writes:

 > 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 doubt that's really the case.  gnome-applets is a single package
 upstream[0] and it has little duplication.  I'd be *extremely* annoyed
 if asclock suddendly gets replaced by asclock + pclock + wmtime + ...
 because I use asclock.  On a multiuser system it makes sense to have
 all the others installed, but ignoring border cases, normal people have
 one clock on the desktop at most, so single user systems don't need
 more than package with one clock in it.

 [0] http://cvs.gnome.org/lxr/source/gnome-applets; I'm sure there's a
 much better link elsewhere, but this serves the point.

-- 
Marcelo | "In a word -- im-possible!"  "That's two words,"
[EMAIL PROTECTED] | said Dibbler.
| -- (Terry Pratchett, Moving Pictures)




Re: Dock Apps packaging, round 2

2002-08-24 Thread Anthony Towns
On Sat, Aug 24, 2002 at 09:48:12AM +0200, Marcelo E. Magallon wrote:
> >> Josselin Mouette <[EMAIL PROTECTED]> writes:
>  [...] but ignoring border cases, normal people have
>  one clock on the desktop at most, so single user systems don't need
>  more than package with one clock in it.

Ignoring border cases, a few kb here and there for some extra clocks is
*nothing*; spending extra time to find the right packages, or to maintain
the packages, otoh, can be a signficant cost.

Anyway, back to the pointless bickering.

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

2002-08-24 Thread Richard Braakman
On Sat, Aug 24, 2002 at 02:35:31AM +, Frank Copeland wrote:
> 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.

I would be happy to help with that, for what it's worth.  I don't
have experience with the platform in question, but I have experience
with ugly code.  The experience should be similar :-)

Richard Braakman




域名注册主机申请网站建设

2002-08-24 Thread guest
域名注册主机申请网站建设一条龙为您服务


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

 “特惠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: Dock Apps packaging, round 2

2002-08-24 Thread Frank Lenaerts
on Fri, Aug 23, 2002 at 03:20:49PM -0700, Sean 'Shaleh' Perry wrote about Re: 
Dock Apps packaging, round 2:

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

Indeed, instead of creating work-arounds for a technical problem, the
root cause should be tackled. Moreover, solving this technical problem
should be easier than trying to produce another set of rules which
everybody agrees with.

Actually, the person doing the packaging itself should not even be
concerned about the Packages.gz file, because someone else is (or
should be) taking care of it.

-- 
[EMAIL PROTECTED]

Those who do not understand Unix are condemned to reinvent it, poorly."
-- Henry Spencer



pgpvKaLRdMjYr.pgp
Description: PGP signature


Re: Are libtool .la files in non-dev library packages bugs?

2002-08-24 Thread Marcus Brinkmann
On Tue, Aug 20, 2002 at 02:10:18PM +0200, Eduard Bloch wrote:
> Because of naivity of some programers. I suggest to begin getting rid of
> such kludges and forbid usage of .la files at runtimer in the Policy for
> Sarge.

Policy is not a stick to beat with.  If there is a bug, report it as such,
and leave it to the maintainer and upstream developers to fix it if in
doubt.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU  http://www.gnu.org[EMAIL PROTECTED]
Marcus Brinkmann  The Hurd http://www.gnu.org/software/hurd/
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de/




dpkg should prompt re missing conffiles [was Re: When bind9 reinstalls, no db.root]

2002-08-24 Thread Oliver Elphick
On Thu, 2002-08-22 at 21:40, Steve Greenland wrote:
> 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.

The problem is not that it doesn't override, which would not be
desirable, but that it doesn't flag a missing conffile during
upgrading.  Deletion of a file should be regarded as a change, and
should merit a question about whether the default package file should be
installed.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "For yourselves know perfectly that the day of the Lord
  so cometh as a thief in the night. For when they shall
  say, Peace and safety; then sudden destruction cometh 
  upon them, as travail upon a woman with child; and 
  they shall not escape."  I Thessalonians 5:2,3 




Re: dpkg should prompt re missing conffiles [was Re: When bind9 reinstalls, no db.root]

2002-08-24 Thread Steve Greenland
On 24-Aug-02, 09:48 (CDT), Oliver Elphick  wrote: 
> On Thu, 2002-08-22 at 21:40, Steve Greenland wrote:
> > 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.
> 
> The problem is not that it doesn't override, which would not be
> desirable, but that it doesn't flag a missing conffile during
> upgrading.  Deletion of a file should be regarded as a change, and
> should merit a question about whether the default package file should be
> installed.

It does. But you are asked about replacing only if *both* of the following
are true:

A. You've modified the conffile.
B. The maintainer has modified the conffile.

If only A is true, the conffile is left alone with no question. If only B is
true, then the conffile is replaced with no question.

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




Ginseng Tea£¨ ×Éѯ£¡£¡£©

2002-08-24 Thread ginsengremove

 
 

     
  台北市侨兴商贸公司诚寻贵地合作伙伴,销售笔记本电脑、配件、手机。我司保证产品为全新原装,货到付款。有不详可来人来电咨询: 
    电话: 0
  13850707737  联系人:邓 宇新一、内存:
  单位/元金士顿KingstonKVR133X64C3/128 SD128MB/168PIN/PC133
  60KVR133X64C3/256 SD256MB/168PIN/PC133 120KVR133X64C3/512
  SD512MB/168PIN/PC133 300KVR133X72C3/128 ECC/SD128MB/PC133
  140KVR133X72C3/256 ECC/SD256MB/PC133 280KVR133X72C3/512
  ECC/SD512MB/PC133 600KVR266*64C25/128 DDR128MB/184PIN/PC266
  65KVR266*64C25/256 DDR256MB/184PIN/PC266 130KVR266*64C25/512
  DDR512MB/184PIN/PC266 310KVR133*64SC3/128 笔记本SD128M/144PIN/PC133
  100KVR133*64SC3/256 笔记本SD256M/144PIN/PC133 259KVR800*16-8/128
  RB128MB/800MHZ/Non-ECC/8-Device 140KVR800*16-16/256
  RB256MB/800MHZ/Non-ECC/16-Device 260KVR800*16-16/512
  RB512MB/800MHZ/Non-ECC/16-Device 465Hy128M T-H/168PIN SDRAM/PC133
  48256M T-H/168PIN SDRAM/PC133 96512M T-S/168PIN SDRAM/PC133
  200256M DDR 184PIN DDR RAM 130Kingmax128M 6ns/168PIN
  SDRAM/PC150(2.0版) 50256M 6ns/168PIN SDRAM/PC150(2.0版) 100128MB 128MB
  DDR RAM/PC2700 70256MB 256MB DDR RAM/PC3200 130三星256M ECC
  7.5ns/168PIN SDRAM/ECC/服务器内存/原厂内存/PC133 130512M ECC 7.5ns/168PIN
  SDRAM/ECC/服务器内存/原厂内存/PC133 270128M DDR 184PIN DDR SDRAM/原厂内存/2100MHz/CL2.0
  65256M DDR 184PIN DDR SDRAM/原厂内存/2100MHz/CL2.0
  150二、cpu:Intel奔腾Ⅲ 1G Socket 370/256K/133兆/盒装 350奔腾Ⅲ 933 Socket
  370/256K/133兆/盒装 320奔腾4 1.5G Socket 478/256KB/400MHz /盒装 370奔腾4 1.7G
  Socket 478/256KB/400MHz/盒装 400奔腾4 2.0A Socket 478/512KB/400MHz/盒装
  580奔腾4 2.2A Socket 478/512KB/400MHz/盒装 700奔腾4 2.4A Socket
  478/512KB/400MHz/盒装 920赛扬1.1G Socket 370/Tualatin核心/256K/散装 210赛扬1.3
  Socket 370/Tualatin核心/256K/散装 235赛扬1.8G Socket 478/128KB/400MHz/散装
  310AMDAthlon XP 1500+ Socket-A/256K/133外频/散装 205Athlon XP 1700+
  Socket-A/256K/133外频/散装 260Athlon XP 2100+ Socket-A/256K/133外频/散装
  520Athlon XP 2200+ Socket-A/256K/133外频/散装
  710三、硬盘:Maxtor美钻二代/2B020H2 20GB/UDMA 100/5400rpm/2M/IDE 保三年
  290星钻三代/4D040H2 40GB/UDMA 100/5400rpm/2M/IDE/单碟40GB/ 保三年
  300星钻三代/4D080H4 80GB/UDMA 100/5400rpm/2M/IDE/单碟40GB/ 保三年
  390金钻七代/6L040J2 40GB/UDMA 133/7200rpm/2M/IDE/单碟40GB/ 保三年
  300金钻七代/6L060J3 60GB/UDMA 133/7200rpm/2M/IDE/单碟40GB/ 保三年
  430金钻七代/6L080J4 80GB/UDMA 133/7200rpm/2M/IDE/单碟40GB/ 保三年 480希捷U6系列
  ST320410A 20.4GB/UDMA 100/2M/5400rpm/IDE/3.5" 200U6系列 ST340810A 40GB/UDMA
  100/2M/5400rpm/IDE/3.5" 220酷鱼Ⅳ系列 ST340016A
  40.8GB/UDMA100/2MB/7200rpm/IDE/3.5" 230酷鱼Ⅳ系列 ST360021A 60GB/UDMA
  100/2MB/7200rpm/IDE/3.5" 260酷鱼Ⅳ系列 ST380021A 80GB/UDMA
  100/2MB/7200rpm/IDE/3.5" 320IBM腾龙四代DTLA-307040 40GB/UDMA
  100/2M/7200rpm/IDE/3.5" 210腾龙四代60GXP 60AVER07 60G/UDMA
  100/2M/7200rpm/IDE/3.5"单碟20GB 240腾龙四代DTLA-307080 80GB/UDMA
  100/2M/7200rpm/IDE/3.5" 320腾龙四代DTLA-307120 120GB/UDMA
  100/2M/7200rpm/IDE/3.5" 420四、主板:微星845 Ultra Intel 845D/Socket
  478/FSB 400/AGP 4X/AC97/ATX 400845 Ultra-c Intel 845D/Socket 478/FSB
  400/AGP 4X/AC97/ATX 360845E Max2-L Intel 845E/Socket 478/FSB 533/AGP
  4X/AC97/ATX/USB2.0 480845E Max2-BLR Intel 845E/Socket 478/FSB
  533/ATA133/AGP 4X/AC97/ATX/Raid/USB2.0 580845E MX2 Intel 845E/Socket
  478/FSB 533/ATA133/AGP 4X/AC97/ATX/USB2.0 330845G Max Intel 845G/Socket
  478/FSB 533/AGP 4X/AC97/ATX 450845Pro2-C Intel 845/Socket 478/DMA 100/AGP
  Pro/CMI 8738声卡/AC 97/ATX 290845 Pro2LE Intel 845/Socket 478/FSB 400/AGP
  4X/AC97/ATX 300815EPT Pro-NL Intel 815EP/Socket 370/ATA100/AGP 4X/AC97/ATX
  250Pro266TD Master-LR VIA Pro266T/Socket 370-Tulatin/ATA133/AGP
  4X/AC97/ATX/Raid 430KT3 Ultra VIA KT333/Socket A/8738硬声卡/AC 97/ATX
  380KT3 Ultra-ARU VIA KT133/Socket A/ATA133/Raid/AC 97/USB 2.0
  440技嘉GA-8IRXP Intel 845D/Socket 478/FSB 400/DMA 133/AGP
  4X/RAID/CT5880/ATX 4208IRX Intel 845D/Socket 478/FSB 400/DMA 100/AGP
  4X/CT5880/ATX 320GA-8IDX3 Intel 845/Socket 423/FSB400/DMA 100/AGP
  4X/AC97/ATX 310GA-60XT Intel 815EP/Socket 370/FSB 133//DMA 100/AGP 4X/ATX
  230GA-7VTXE VIA KT266A/Socket A/FSB 266/DMA 100/AGP 4X/AC 97/ATX
  250GA-6VTXE VIA 694T/Socket 370/FSB 150/DMA100/AGP 4X/AC 97/ATX
  200GA-6VEM VIA PLE133T/ATX/Socket 370/FSB 150/DMA100/AGP 4X/AC 97/整合显卡/ATX
  1708SDX SIS 645/Socket 478/FSB 400/DMA 100/AGP 4X/CT5880/ATX
  310华硕P4B533-M Intel 845E/Socket 478/FSB 533/ATA 100/AGP 4X/AC
  97/MicroATX/USB2.0 390P4B266-C Intel 845D/Socket 478/FSB 400/ATA 100/ATX
  330P4T-E Intel 850/Socket 478/FSB 400/ATA 100/AGP 4X/ATX
  520奔驰P4-845G Intel 845G/Socket 478/AGP 4X/DMA100/ATX 320P4-845A
  Intel 845/Socket 478/AGP 4X/DMA100/ATX 290五、激光打印机:惠普1200
  分辨率600*600dpi/A4/15页/分钟 14002200D 分辨率720*1440dpi/A4/10页/分钟 29005000
  分辨率600*1200dpi/A3/16页/分钟 5000六、喷墨打印机:惠普DJ-656c
  最高分辩率600*600dpi/A4/6PPM(黑色)3PPM(彩色)/USB接口 160190 DJ-845c
  最高分辩率600*1200dpi/A4/8PPM(黑色)5PPM(彩色)/USB接口 220扫描仪:惠普SJ5300C
  光学分辨率1200*2400dpi/36bit/EPP/USB接口 900SJ5370C
  光学分辨率1200*2400dpi/42bit/EPP/USB接口 1300SJ6300C
  光学分辨率1200*2400dpi/最大分辨率无点/36bit/A4/USB/SCSI接口 1500七、crt 显示器:三星551S
  15"/0.28mm/1024*768 330763MB 17"/0.20mm/1024*768/100MHz/Magic Bright技术
  550757DFX 17"纯平/0.20mm/1600*1200/205MHz/TCO99 700索尼G220
  17"/1600*1200 1700G420 19"/0.24mm/1800*1440 2700G520 21"/1920*1440
  4000飞利浦107P 17"纯平/0.25mm/1920*1440/23

Dig up information on your FRIENDS, NEIGHBORS, or BOSS!.! debian-devel

2002-08-24 Thread mirrors



The Magic Is In The Software 
 



The Magic Is In The Software 
And Its Called NetSpy-ProThe

Ultimate Investigating Software 
o
Find out everything you ever wanted to know 
about:
o
your friends

o
your family

o
your enemies

o
your employees

o
yourself - Is Someone Using Your Identity?

o
even your boss! 
o
Did you know that you can search for anyone, anytime, 
anywhere, right on the Internet? 
Click here: 
http://webpost.net/ne/netspy";>Download -- This mammoth collection of Internet 
investigative tools & research sites will provide you with nearly 400 
gigantic research resources to locate information online and offline 
on:---
people you trust, people you work with 
screen new tenants, roommates, nannys, 
housekeepers current or past employment 
license plate numbers, court records, 
even your FBI file unlisted & reverse 
phone number lookup 

 
Click
 Here: http://pages.sbcglobal.net/sirus";
target=_blank>Download 
o Dig up information on your FRIENDS, NEIGHBORS, or 
BOSS!
o Locate transcripts and 
COURT ORDERS from all 50 states.
o CLOAK your EMAIL so your 
true address can't be discovered.
o Find out how much ALIMONY 
your neighbor is paying.
o Discover how to check your 
phones for WIRETAPS.
o Or check yourself 
out--you may be shocked at what you find!!
These are only 
a few thingsthat you can do with this software...
To download this software, and 
have it in less than 5 minutes, click & visit our 
website:Click Here: http://pages.sbcglobal.net/tom99
"
target=_blank>Download 

 
mailto:href="[EMAIL PROTECTED]" href="mailto:[EMAIL PROTECTED]">RemoveMe








perl 5.6 dependent packages

2002-08-24 Thread Joey Hess
perl 5.8 will enter unstable at the next dinstall run. Before it can
make testing though, we have to update the following 84 packages which
still depend on perlapi-5.6.*. This list should take into account those
packages that were already NMU'd.

[EMAIL PROTECTED]:~>grep-available -F depends perlapi-5.6 -s package
package: libgd-perl
package: libxml-xerces-perl
package: libnet-ftpserver-perl
package: libsnmp-perl
package: libcrypt-blowfish-perl
package: libio-pty-perl
package: libfile-sync-perl
package: libdigest-md5-perl
package: libparted-swig-perl
package: libnet-tclink-perl
package: libcompress-zlib-perl
package: libscalar-list-utils-perl
package: libcyrus-imap-perl
package: libalias-perl
package: slice
package: libdbd-sybase-perl
package: liblockdev1-perl
package: libdigest-sha1-perl
package: libmdn-perl
package: libnet-ssleay-perl
package: libtext-unaccent-perl
package: libcorba-orbit-perl
package: librrds-perl
package: libdbd-sqlite-perl
package: libunix-syslog-perl
package: libastro-fits-cfitsio-perl
package: libtime-hires-perl
package: libnet-pcap-perl
package: wml
package: dcopperl
package: ipchains-perl
package: libswf-perl
package: libcdb-file-perl
package: libauthen-smb-perl
package: libtemplate-perl
package: libmime-base64-perl
package: libipc-sharelite-perl
package: libnewt-perl
package: libpda-pilot-perl
package: libtext-kakasi-perl
package: libcdk-perl
package: libhtml-embperl-perl
package: libapache-mod-perl
package: libjcode-pm-perl
package: libcrypt-rijndael-perl
package: libcurl-easy-perl
package: libft-perl
package: libquota-perl
package: libstorable-perl
package: libsafe-hole-perl
package: libproc-process-perl
package: libbsd-resource-perl
package: libunicode-japanese-perl
package: libdigest-md4-perl
package: libsocket6-perl
package: libcrypt-cracklib-perl
package: libstring-approx-perl
package: pgperl
package: libcrypt-des-perl
package: freewrl
package: libset-object-perl
package: libxmms-perl
package: axkit
package: speedy-cgi-perl
package: libgd-noxpm-perl
package: libconvert-uulib-perl
package: libgd-gd2-perl
package: libdigest-md2-perl
package: libberkeleydb-perl
package: libcflow-perl
package: libnet-rawip-perl
package: libplot-perl
package: libgnome-gnorba-perl
package: libsql-statement-perl
package: libapache-db-perl
package: libtext-csv-perl
package: libcurses-perl
package: libpcsc-perl
package: libstring-crc32-perl
package: libpsp-html-parser-perl
package: libauthen-sasl-cyrus-perl
package: libnet-patricia-perl
package: libopengl-perl
package: libapache-request-perl

And the following 24 which depend on libperl5.6:

package: gaim-gnome
package: gmoo
package: vim-perl
package: abiword-gtk
package: owl
package: entity
package: spidermonkey-bin
package: gnome-db
package: courier-mta
package: epic4
package: libpgperl
package: gaim
package: libapache-mod-perl
package: irssi-text
package: dchub
package: apache-perl
package: inn
package: abiword-gnome
package: xvile
package: inn2
package: vile
package: speedy-cgi-perl
package: bayonne
package: spidermonkey1

Updating most of these should be as simple as making a build-depends on
perl 5.8 so the autobuilders will build with the right version (may not
be necessary soon), and rebuilding, and testing. Anyone who has perl
code in the distribution should give it a run under perl 5.8, there are
various little gotchas and it would probably be good if we could catch
as many of those as possible before perl 5.8 enters testing. In general
it all works very well.

-- 
see shy jo




Bug#158059: ITP: metacity-themes -- Themes for the Gtk2 metacity window manager

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


* Package name: metacity-themes
  Description : Themes for the Gtk2 metacity window manager

 This collection of themes for the metacity window manager has been carefully
 compiled from a number of sources. Each one is publically available under a
 license which complies with the Debian free software guidelines, most commonly
 the GPL license. The themes have been individually checked to ensure that they
 are all of high quality: they have a consistent design; include high quality
 graphics; and handle all types of window.
 .
 The themes have primarily been gathered from http://themes.freshmeat.net and
 http://sunshineinabag.co.uk. I would like to hear suggestion for other high
 quality themes to be included, however please be sure to read the
 /usr/share/doc/metacity-themes/README.Debian file first, as it documents 
reasons why a
 number of themes were not included. 


Initial packages for this are available at
http://tildemh.com/tmp/metacity-themes/
The package currently only includes three groups of themes - partially
due to the recent changes in the way themes are done in metacity. 

I am not yet a Debian developer; I am at the 'waiting for an AM' stage
of the NM process. So, if anyone's listening who has an interest in themes
or metacity, please volunteer to sponsor this package.






Problem with autobuilders installing python

2002-08-24 Thread James A. Treacy
All the autobuilders failed in building gramps 0.8.0-3 giving the
following:

Checking for source dependency conflicts...
  /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install 
debhelper python-dev python-xml python-gnome python-glade docbook-utils 
scrollkeeper gettext
Reading Package Lists...
Building Dependency Tree...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Sorry, but the following packages have unmet dependencies:
  python-dev: Depends: python (>= 2.1) but it is not going to be installed
  Depends: python (< 2.2) but it is not going to be installed
  Depends: python2.1-dev (>= 2.1.3-5) but it is not going to be 
installed
  python-glade: Depends: python-gtk (= 0.6.9-3) but it is not going to be 
installed
  python-gnome: Depends: python-gtk (>= 0.6.9-3) but it is not going to be 
installed
Depends: python-gdk-imlib (>= 0.6.9-3) but it is not going to 
be installed
  python-xml: Depends: python (>= 2.1) but it is not going to be installed
  Depends: python (< 2.2) but it is not going to be installed
  Depends: python2.1-xml (>= 0.8-2) but it is not going to be 
installed
E: Sorry, broken packages
apt-get failed.
Package installation failed

This worked on every previous build of the package. The only change in
the Build-Depends is the addition of scrollkeeper and gettext.

Are the python packages screwed up? Do entire dependency chains need
to be specified for Build-Depends? What needs to be done to fix this?

-- 
James (Jay) Treacy
[EMAIL PROTECTED]




MAKEDEV Replacement status

2002-08-24 Thread Don Armstrong
I was just about to file a wishlist against makedev to get support for
dpti0 .. dptiX (adaptec i2o raid cards) added to MAKEDEV, but remembered that
there had been some talk in July about it's replacement.[1]

Could Andreas Salmon, Bdale Garbee, and Sean Perry comment on the
status of a replacement MAKEDEV if one is in the works? [Or point me
to relevant documentation?]

If not, I'll just file a bug w/ patch.


Don Armstrong

1: 
http://lists.debian.org/debian-devel/2002/debian-devel-200207/threads.html#00270

-- 
Always try to do things in chronological order.
It's less confusing that way.

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


pgpAgkPqdLgww.pgp
Description: PGP signature


Re: perl 5.6 dependent packages

2002-08-24 Thread Brendan O'Dea
On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote:
>perl 5.8 will enter unstable at the next dinstall run. Before it can
>make testing though, we have to update the following 84 packages which
>still depend on perlapi-5.6.*. This list should take into account those
>packages that were already NMU'd.
>
>[EMAIL PROTECTED]:~>grep-available -F depends perlapi-5.6 -s package

Note that in addition, since perl 5.8.0 includes some modules which were
previously stand-alone, any package declaring a versioned[0] dependency
on:

  libdigest-md5-perl, libmime-base64-perl, libnet-perl,
  libtime-hires-perl, libstorable-perl,
  libattribute-handlers-perl, libcgi-perl, libi18n-langtags-perl,
  liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl,
  libtest-harness-perl, libtest-simple-perl

needs to either have the version for that dependency removed, or just to
depend on perl (>= 5.8.0).

[0] The 5.8.0 perl packages do provide these so un-versioned
dependencies are fine, dpkg/apt just don't support versioned
provides.

--bod




Re: MAKEDEV Replacement status

2002-08-24 Thread Ian Zimmerman

Don> I was just about to file a wishlist against makedev to get
Don> support for dpti0 .. dptiX (adaptec i2o raid cards) added to
Don> MAKEDEV, but remembered that there had been some talk in July
Don> about it's replacement.[1]

Don> Could Andreas Salmon, Bdale Garbee, and Sean Perry comment on the
Don> status of a replacement MAKEDEV if one is in the works? [Or point
Don> me to relevant documentation?]

Mine is still ready:

http://www.speakeasy.net/~itz/hacks/makedev_3.3-1.tar.gz

-- 
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087  9C0F 194F 203A 63F7 B1B8  6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.




Re: Are libtool .la files in non-dev library packages bugs?

2002-08-24 Thread Henrique de Moraes Holschuh
On Sat, 24 Aug 2002, Marcus Brinkmann wrote:
> On Tue, Aug 20, 2002 at 02:10:18PM +0200, Eduard Bloch wrote:
> > Because of naivity of some programers. I suggest to begin getting rid of
> > such kludges and forbid usage of .la files at runtimer in the Policy for
> > Sarge.
> 
> Policy is not a stick to beat with.  If there is a bug, report it as such,
> and leave it to the maintainer and upstream developers to fix it if in
> doubt.

It is also our best-practices document.  I certainly would expect policy to
tell us ("should") not to let libtool leave its crap behind.  This is not
using policy as a stick.

-- 
  "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: perl 5.6 dependent packages

2002-08-24 Thread Henrique de Moraes Holschuh
On Sun, 25 Aug 2002, Brendan O'Dea wrote:
> Note that in addition, since perl 5.8.0 includes some modules which were
> previously stand-alone, any package declaring a versioned[0] dependency
> on:
> 
>   libdigest-md5-perl, libmime-base64-perl, libnet-perl,
>   libtime-hires-perl, libstorable-perl,
>   libattribute-handlers-perl, libcgi-perl, libi18n-langtags-perl,
>   liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl,
>   libtest-harness-perl, libtest-simple-perl
> 
> needs to either have the version for that dependency removed, or just to
> depend on perl (>= 5.8.0).

litian and linda checks for these, please!

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




New version of libphp-adodb

2002-08-24 Thread Thorsten Sauter

Hi all,

a new version of the libphp-adodb package is entered in unstable.
The version is based on the new adodb 2.31 version.

I have also change the path from /usr/lib/adodb to /usr/share/adodb/!

The following package is now broken, because it doesn't include the new
path:
[EMAIL PROTECTED]:~$ grep-available -F depends libphp-adodb -s package
package: acidlab



Please check your packages against this new version.


Bye
Thorsten


-- 
Thorsten Sauter
<[EMAIL PROTECTED]>

(Is there life after /sbin/halt -p?)



pgpPTZdseSG4g.pgp
Description: PGP signature


Re: Possible mass filing of bugs, take #2.1

2002-08-24 Thread Josip Rodin
On Wed, Aug 21, 2002 at 02:14:16AM +1000, Anthony Towns wrote:
> We've _finally_ got lintian running over the archive again, and it looks like
> we'll have some chance of keeping it working. The URL is
> 
>   http://people.debian.org/~joy/
> 
> until lintian.debian.org gets updated to point at the right site.

As some may already have noticed, the above URL is no longer functional,
and http://lintian.debian.org/ is moderately up to date instead.

-- 
 2. That which causes joy or happiness.




Bug#158079: ITP: aseqview -- ALSA Sequencer Event Viewer

2002-08-24 Thread Stefan Schwandter
Package: wnpp
Version: N/A; reported 2002-08-25
Severity: wishlist

* Package name: aseqview
  Version : 0.1.4
  Upstream Author : Takashi Iwai <[EMAIL PROTECTED]>
* URL : http://www.alsa-project.org/~iwai/
* License : GPL
  Description : ALSA Sequencer Event Viewer

ASeqView is an ALSA sequencer user-client which works as event
viewer. It visualizes received events, e.g. note-on/off, controls,
pitch wheels, using bar graphs.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux TK150122 2.4.19 #1 Tue Aug 6 20:38:52 CEST 2002 i586
Locale: LANG=C, [EMAIL PROTECTED]

-- no debconf information





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

2002-08-24 Thread Martijn van Oosterhout
On Fri, Aug 23, 2002 at 07:08:31PM -0600, Georg Lehner wrote:
> El jue, 22-08-2002 a las 12:47, Roland Bauerschmidt escribió:
> ...
> - 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.

Umm, this may sound silly, but how will you do local delivery if there is no
MTA installed?

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




libwww-perl

2002-08-24 Thread Jack Howarth
   Has anyone had any luck building libwww-perl against perl 5.80
yet? 
   Jack




Re: libwww-perl

2002-08-24 Thread Clint Adams
>Has anyone had any luck building libwww-perl against perl 5.80
> yet? 

Check http://ftp-master.debian.org/~bod/perl/pool/libw/libwww-perl/

Incidentally, the libdbi-perl there has a lower delta (1.1) than the one
in sid (2).




compiling clamav with pbuilder

2002-08-24 Thread Brian May
Hello,

Wehn compiling clamav in a woody chroot with pbuilder, I get
the following error:

Font metrics written on cmr10.tfm.
Output written on cmr10.720gf (128 characters, 28572 bytes).
Transcript written on cmr10.log.
/usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable.
mktexpk: /var/spool/texmf/pk/ljfour/public/cm/cmr10.720pk: successfully 
generated.
<8r.enc>. [0] [1] [2] [3] [4] [5] 
[6] [7] [8] [9] [10] [11] [12] 
(cd docs && ps2pdf clamdeb.ps clamdeb.pdf)   
 Unable to open the initial device, quitting.
make: *** [build-stamp] Error 255
pbuilder: Failed autobuilding of package
 -> unmounting /proc filesystem
 -> unmounting /dev/pts filesystem
 -> cleaning the build env 

What is the problem here?

Why does ps2pdf need to open a device, and what device is it
trying to open?
-- 
Brian May <[EMAIL PROTECTED]>




Re: MAKEDEV Replacement status

2002-08-24 Thread Bdale Garbee
[EMAIL PROTECTED] (Don Armstrong) writes:

> If not, I'll just file a bug w/ patch.

That's the right thing to do for now, regardless.

Bdale




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

2002-08-24 Thread Georg Lehner
Hello!

El sáb, 24-08-2002 a las 17:28, Martijn van Oosterhout escribió:
...
> > Proposal: By default no MTA will be installed.
> 
> Umm, this may sound silly, but how will you do local delivery if there is no
> MTA installed?
...

Not silly.  MDA's like procmail can do local delivery standalone.
Obviously no queue needed.

Haven't (still) done it myself however.

Regards,

Jorge-León




Re: libwww-perl

2002-08-24 Thread Brendan O'Dea
On Sat, Aug 24, 2002 at 09:56:05PM -0400, Clint Adams wrote:
>>Has anyone had any luck building libwww-perl against perl 5.80
>> yet? 
>
>Check http://ftp-master.debian.org/~bod/perl/pool/libw/libwww-perl/

Everything from that pool with the exception of libwww-perl was pushed
into unstable last night.  libwww-perl was omitted by request of Joey,
who made the NMU:

   "I've uploaded libwww-perl since a lot of stuff needed it, but it
fails some regression tests and should be kept out of the main
archive, please."

The current version fails one test.  There is a newer version (5.65)
available upstream which appears to build cleanly; the changelog reads:

Make HTTP::Date compatible with perl 5.8.

>Incidentally, the libdbi-perl there has a lower delta (1.1) than the one
>in sid (2).

Entrirely possible.  In any case that staging repository is now gone.

--bod




Re: libwww-perl

2002-08-24 Thread Clint Adams
> >Incidentally, the libdbi-perl there has a lower delta (1.1) than the one
> >in sid (2).
> 
> Entrirely possible.  In any case that staging repository is now gone.

I forgot to specify that -2 is built for 5.6.




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

2002-08-24 Thread Martijn van Oosterhout
On Sat, Aug 24, 2002 at 10:10:24PM -0600, Georg Lehner wrote:
> Hello!
> 
> El sáb, 24-08-2002 a las 17:28, Martijn van Oosterhout escribió:
> ...
> > > Proposal: By default no MTA will be installed.
> > 
> > Umm, this may sound silly, but how will you do local delivery if there is no
> > MTA installed?
> ...
> 
> Not silly.  MDA's like procmail can do local delivery standalone.
> Obviously no queue needed.

Okay. I'm thinking specifically of cron here.  When it tries to send an
email it spawns /usr/sbin/sendmail to send it. This file will not exist
unless a mail server is installed. procmail is not interface compatable
with sendmail. Similarly MUAs like mutt, programs like at and debconf will
either use that program or connect to port 25.

What I'm saying is that to must have a mail-server install, even if it is
just ssmtp or something like that.

I hope this is clearer.
-- 
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.