Re: MIPS port backlog, autobuilder machines and some arrogance

[Ingo Juergensmann]

On Wed, Nov 19, 2003 at 02:32:53PM +1100, Martin Michlmayr - Debian Project 
Leader wrote:

> And since we're on topic: people interested in SGI hardware (for
> example to work on debian-installer) in the USA, please get in contact
> with me.

Hmm, regarding to Goswin Brederlow debian-installer build fine yesterday on
our SGI and I'll test it today on my private Indy. 
Perl is building fine as well now on mips, although it is marked as
not-for-us. See
http://m68k.bluespice.org/cgi/package_status?mips_pkg=perl&searchtype=go

paco:/home/ij# ls -l *.deb
-rw-r--r--1 root root35172 Nov 18 22:24 
libcgi-fast-perl_5.8.2-2_all.deb
-rw-r--r--1 root root   651210 Nov 18 22:32 
libperl-dev_5.8.2-2_mips.deb
-rw-r--r--1 root root 1002 Nov 18 22:31 
libperl5.8_5.8.2-2_mips.deb
-rw-r--r--1 root root   766386 Nov 18 22:27 
perl-base_5.8.2-2_mips.deb
-rw-r--r--1 root root  4320256 Nov 18 22:31 
perl-debug_5.8.2-2_mips.deb
-rw-r--r--1 root root  5901334 Nov 18 22:25 perl-doc_5.8.2-2_all.deb
-rw-r--r--1 root root  2158282 Nov 18 22:26 
perl-modules_5.8.2-2_all.deb
-rw-r--r--1 root root32032 Nov 18 22:31 
perl-suid_5.8.2-2_mips.deb
-rw-r--r--1 root root  3325030 Nov 18 22:38 perl_5.8.2-2_mips.deb

-- 
Ciao...  // 
  Ingo \X/

Minneapolis, MN USA BSP + Keysigning

[Scott Dier]

Thanks to Chad Walstrom for really coming up with the idea!

** PLEASE RSVP privately to [EMAIL PROTECTED] **

I need to know how many people and if you are planning on a laptop
(wireless or wired) or a full computer (I've only got so much space).

>  What: "Bug Squashing Party (BSP) and Keysigning"
> Start: Saturday, 13 Dec 2003 12:00:00 CDT
>  Stop: assert(not_exhausted(personal->state)) /* core dump */
> Where: Scott Dier's Residence (Coon Rapids, MN, USA)
  10675 Quince St NW #100
  Coon Rapids, MN 55433
  [black helicopter parking is across the street]

  One way to get here from there:
  Take Hwy 10 to Foley Blvd., go south.
  Take a right at 99th Ave NW
  Take a right at Woodcrest
  At Foley continue straight, the road becomes Quince at this
  point.  Be careful of the transformer box to the left at this
  two-way stop, it can sometimes hide cars.
  Take a right at the 2nd street (its an access road)
  Find a parking spot in guest parking, if none are avaliable,
  park in the driveway to unload and then we will find some
  parking for you.

  There is no mass transit near my house that runs extended
  hours.  I can provide a shuttle to/from Northtown Mall if
  required.

** PLEASE RSVP **

If you can't seem to convince MapQuest to get you good directions, feel
free to email me and I can help out or call 763-390-3261.

Thanks!

-- 
Scott Dier <[EMAIL PROTECTED]> KC0OBS http://www.ringworld.org/
Free USA from energy dependence, http://www.apolloalliance.org/


pgpm5DTIlbQIn.pgp
Description: PGP signature

Re: Minneapolis, MN USA BSP + Keysigning

[Scott Dier]

Important directions correction below:

* Scott Dier <[EMAIL PROTECTED]> [031119 00:01]:
>   One way to get here from there:
>   Take Hwy 10 to Foley Blvd., go south.
>   Take a right at 99th Ave NW
>   Take a right at Woodcrest
>   At Foley continue straight, the road becomes Quince at this
   ^  Should read Egret, not Foley
>   point.  Be careful of the transformer box to the left at this
>   two-way stop, it can sometimes hide cars.
>   Take a right at the 2nd street (its an access road)
>   Find a parking spot in guest parking, if none are avaliable,
>   park in the driveway to unload and then we will find some
>   parking for you.
-- 
Scott Dier <[EMAIL PROTECTED]> KC0OBS http://www.ringworld.org/
Free USA from energy dependence, http://www.apolloalliance.org/


pgpnH62iNz57u.pgp
Description: PGP signature

First pass all buildds before entering unstable

[Andreas Tille]

Hi,

just an idea from a completely uneducated person regarding buildd:

   What about if each freshly uploaded package which contains architecture any
   packages would enter kind of a staging area first and buildds grab these
   files from there.  After each buildd was able to build a package the whole
   set with all architectures enters unstable at once.

This would get us rid of all those packages in unstable with "Does not build
on ..." and several dependencies could be easier solved.  Moreover it would
enhance the preasure on developers to care for this kind of bugs.

I guess this would be not really hard to implement.

Just ignore me if this is a stupid idea

 Andreas.

Re: Bug#220301: ITP: entropy -- Emerging Network To Reduce Orwellian Potency Yield

[Mike Beattie]

On Tue, Nov 18, 2003 at 11:18:39PM -0500, Joe Drew wrote:
> This doesn't really tell me anything about ENTROPY. How about
> "anti-censorship network client"?

That would do.

> The acronym ENTROPY should be defined in the first line of the long
> description.

Right, better than the short description.

[snip]

> This is a good, though perhaps too detailed, long description.

Taken directly from the web page... (I'm lazy)

> A general (non-ITP-related) question: Is ENTROPY related to Freenet in
> any way?

It supports the freenet protocol, yes. But it's written in C, not Java.

I actually havent had a chance to package it yet, I've been too busy at
work. If anyone else wants to take this one, feel free, just let me know.
I'll retitle it to RFP in a week or two if I dont get a chance to get to it.

Mike.
-- 
Mike Beattie <[EMAIL PROTECTED]>  ZL4TXK, IRLP Node 6184

  "In the beginning the Universe was created. This has made a lot of people
 very angry and been widely regarded as a bad move." - Douglas Adams

Re: First pass all buildds before entering unstable

[Michael Piefel]

Am 19.11.03 um 07:42:18 schrieb Andreas Tille:
>After each buildd was able to build a package the whole
>set with all architectures enters unstable at once.

Yeah, cool. That would get rid of many buggy packages. And many clean
ones. Some buildd are horribly behind time. No offence meant, it's not
necessarily sloppy maintainers, rather it's slow computers and extremely
complex packages.

Take workrave, for instance. Perfectly stable, as far as I can tell. Not
built recently on m68k (because of libgnomeuimm2.0-dev), not built on
alpha for a very long time (same reason). It's not in testing, which is
bad enough, with your idea only ancient versions would be in unstable.

Don't get me wrong. I actually quite like the thought. It just won't
work. Perhaps limit it to "when it's built for i386, powerpc, hppa and
arm". (That's were I got all my architecture-dependent bugs from, and
they are all quite current.)

Bye,
Mike

-- 
|=| Michael Piefel
|=| Humboldt-Universität zu Berlin
|=| Tel. (+49 30) 2093 3831

2004年3月广州广交会专业展会的通知！！

[洪小姐]

本信息旨在给你提供信息并帮你开拓业务，如果打扰你，请你随手删除，谢谢！

尊敬的先生/小姐：你好！
如果你正在为生产的产品寻找销售市场，或者正在考虑开拓华南地区的贸易业务，考虑参加当地的专业展会将为你解决一切的问题，而且展会现场可以为你提供一个供需双方面对面的洽谈机会，参会的费用也很便宜，真值得你好好考虑！现特向你推荐以下专业展会供你参考：

   第8届广州春季礼品、赠品暨流行饰品展览会
  2004广州春季雨伞展览会


 时间：2004 年3月3---6日
地址：广州.中国出口商品交易会展览馆
  （广州市流花路117号东方宾馆正对面）

1、展会的宗旨：为生产企业寻找客户，为参展产品寻找市场；为参展商推广名牌产品，为经销商寻找货源，为供需双方搭起贸易洽谈的桥梁。

2、宣传的策略：通过国内外的宣传媒体如：专业杂志、网络、报纸、电视、广播媒体定时发布展会的信息，专人到全国各地的专业市场和各地的专业展会作现场的宣传，务求更多的人了解本届展会，以保证本展展会的质量，从而提高参展商的参展效果。

3、观众范围：国内外相关的分销商、进出口公司、百货业、外国驻华商务处、政府机构、行业主管部门负责人、零售业等决策人仕

查询详情请联络：   广州星晖贸易展览有限公司
地址：广州市珠江新城花城大道3号南天广场皇朝阁3101室（510623）
电话：020--38250412、38250413 传真:  38250932 联系人：洪小姐
mailto:[EMAIL PROTECTED] 
网站：http://www.gzxinghui.com

Re: First pass all buildds before entering unstable

[Luca - De Whiskey's - De Vitis]

On Wed, Nov 19, 2003 at 08:48:10AM +0100, Michael Piefel wrote:
> Am 19.11.03 um 07:42:18 schrieb Andreas Tille:
> >After each buildd was able to build a package the whole
> >set with all architectures enters unstable at once.

I like the idea.

> Yeah, cool. That would get rid of many buggy packages. And many clean
> ones. Some buildd are horribly behind time. No offence meant, it's not
> necessarily sloppy maintainers, rather it's slow computers and extremely
> complex packages.

I don't think the speed of some of our buildd would be the point. Sooner or
later the new packages will be compiled on our buildd: better before entering
Debian than after and..

> Take workrave, for instance. Perfectly stable, as far as I can tell. Not
> built recently on m68k (because of libgnomeuimm2.0-dev), not built on
> alpha for a very long time (same reason). It's not in testing, which is
> bad enough, with your idea only ancient versions would be in unstable.

I think this is not what Andreas ment: I suppose he was trying to drop FTBFS
bugs for those new packages missing correct Build-* fields. Packages that
cannot be built because of correct source fields but missing dependencies,
should not receive bugs (AFAICT)

> Don't get me wrong. I actually quite like the thought. It just won't
> work. Perhaps limit it to "when it's built for i386, powerpc, hppa and
> arm". (That's were I got all my architecture-dependent bugs from, and
> they are all quite current.)

IMHO it would indeed work, if only we consider meaningful buildd reports (for
what is our purpose).

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: First pass all buildds before entering unstable

[ij]

In article <[EMAIL PROTECTED]> you wrote:

> Take workrave, for instance. Perfectly stable, as far as I can tell. Not
> built recently on m68k (because of libgnomeuimm2.0-dev), not built on
> alpha for a very long time (same reason). It's not in testing, which is
> bad enough, with your idea only ancient versions would be in unstable.

http://m68k.bluespice.org/cgi/package_status?m68k_pkg=libgnomeuimm2.0-dev&searchtype=go
->  libgnomeuimm2.0-dev not registered

http://m68k.bluespice.org/cgi/package_status?m68k_pkg=libgnomeuimm2.0&searchtype=go
-> libs/libgnomeuimm2.0_2.0.0-4: Installed by younie-crest 
[optional:out-of-date]
  Previous state was Uploaded until 2003 Nov 18 11:28:19

http://m68k.bluespice.org/cgi/package_status?m68k_pkg=workrave&searchtype=go
-> gnome/workrave_1.4.1-1: Failed by schmitz-q650 [optional:out-of-date]
  Reasons for failing:
[Category: none]
uninstallable b-d
E: Couldn't find package libgnomeuimm2.0-dev
  Previous state was Building until 2003 Nov 07 02:46:31


Maybe you want to request a rebuild on [EMAIL PROTECTED]

-- 
Ciao...  // 
  Ingo \X/

Re: Tabs v.s. spaces

[Florent Rougon]

Darren Salt <[EMAIL PROTECTED]> wrote:

> I find myself wondering if Duff's Device is implementable in Python...

The closest beast I can think of would generate the unrolled loop at
runtime and use 'exec' to run it. But this is a bit off topic for d-d.

-- 
Florent

Re: First pass all buildds before entering unstable

[Giacomo A. Catenazzi]

Andreas Tille wrote:
Hi,
just an idea from a completely uneducated person regarding buildd:
   What about if each freshly uploaded package which contains architecture any
   packages would enter kind of a staging area first and buildds grab these
   files from there.  After each buildd was able to build a package the whole
   set with all architectures enters unstable at once.
No!!! it would delay to much the entry of some important packages in 
unstable. It would maybe improve some architectures, but definitely 
would reduce extensive testing of newer versions.

Unstable IMHO should be more near to upstream-side as possible, to 
improve GNU/Linux at whole, not only the Debian distributions.

BTW: How many developers have access and know how to test packages in
*all* other architectures? So it would be more pressure on developers 
with architectures specific knowelenge.

ciao
giacomo

Re: First pass all buildds before entering unstable

[Wouter Verhelst]

On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote:
> Hi,
> 
> just an idea from a completely uneducated person regarding buildd:
> 
>What about if each freshly uploaded package which contains architecture any
>packages would enter kind of a staging area first and buildds grab these
>files from there.  After each buildd was able to build a package the whole
>set with all architectures enters unstable at once.

I don't think people would like it if their package stayed in incoming
for multiple weeks because there's a backlog on some architecture.
People are bickering enough as it is when packages don't move into
testing that we don't need this extra reason for them to bicker :-)

> This would get us rid of all those packages in unstable with "Does not build
> on ..."

Unstable is there for that kind of things. And to detect other kinds of
bugs, too. If you're going to keep packages in incoming like this,
people won't be able to test it until it's built on all architectures.

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


signature.asc
Description: Digital signature

Re: Tabs v.s. spaces

[Cameron Patrick]

On Tue, Nov 18, 2003 at 09:58:54PM -0800, Steve Lamb wrote:
| Cameron Patrick wrote:
| >I don't think it is.  Python doesn't have a switch/case equivalent.  It'd
| >have to be done with a bunch of if's or something.
| 
| Well, depends.  Do you consider its dictionary to be a switch?

Nope, no fall-through in that one, so it doesn't help.  It /is/ nifty
though :-)

Cameron.

Re: Debian packages of 7.4

[Roger Leigh]

Stephen Frost <[EMAIL PROTECTED]> writes:

> It would be really nice to have 7.4 in sarge..  Personally I think there
> should probably be enough time given the lack of messages on d-d-a
> regarding freezes and the like.  7.4 adds alot of nice things and speeds
> up a number of operations, etc.

Further to that... would it be acceptable to upload the new stable
libpqxx release (2.0.0) built against 7.4 once 7.4 has entered
unstable.  It would be fantastic to have the new libpqxx in sarge,
too.


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

New Tutorials: Slideshows in Flash MX plus Thanksgiving Video

[Wildform Newsletter]

Wildform Newsletter:
The Resource for Wildform Product News
Wednesday, November 19, 2003

http://www.wildform.com 

==
NEW:

1. New Tutorial: Flash MX Slideshow with Listeners 
2. New Tutorial: Flash MX Slideshow with Pause Button
3. New Tutorial: EXIF to Flash MX
4. Featured Gallery Sites
5. New Wild FX Reviews
6. Complimentary Video: Thanksgiving Video Clip
7. Sites We Like

We have some great new tutorials written by the Actionscript 
expert, Helen Triolo. We also have a complimentary clip from 
the Wildform Video Library in honor of Thanksgiving holiday. 

Have a very happy Thanksgiving!

Best wishes,
The Wildform Team

==
1. NEW TUTORIAL: FLASH MX SLIDESHOW WITH LISTENERS 
“Flash MX Slideshow with Listeners”
By Helen Triolo
http://www.wildform.com/tutorials/slideshowcomponent/ 

This tutorial and sample FLA explains how to use Macromedia 
Flash MX to sequentially load jpgs and display them with fade-in 
transitions, using a broadcasting Slideshow component.

For more tutorials please visit:
http://www.wildform.com/tutorials/

=
2. NEW TUTORIAL: FLASH MX SLIDESHOW WITH PAUSE BUTTON

“Flash MX Slideshow with Pause Button”
By Helen Triolo
http://www.wildform.com/tutorials/slideshowcomponent2/ 

This tutorial and sample FLA explains how to add a stop/restart 
button to the slideshow described in the tutorial above.

=
3. NEW TUTORIAL: EXIF TO FLASH MX

”EXIF To Flash”
By Helen Triolo
http://www.wildform.com/tutorials/exiftoflash/ 

This tutorial and sample FLA describes how to read EXIF data 
(or any CSV-formatted data) from a jpg into Flash

For more tutorials please visit:
http://www.wildform.com/tutorials/

==
4. FEATURED GALLERY SITE

THE BEST OF HUBBLE
http://wires.news.com.au/special/mm/030811-hubble.htm
Uses Flix and Linx. From news.com.au.

RYAN FORSMAN
http://www.onewaypublishing.net/forsman/ 
Click on “player video” to view Flix-encoded video in a Flix 
custom player.

BROOKSIDE.ORG 
http://www.wildform.com/resources/flashtexteffectsgallery.php#brook 
 
"Wild FX is a great solution. We were able to add sparkle 
to our website with your application."
-- Russ Block, Webmaster, BrooksideGlen.org

Visit our gallery:
http://www.wildform.com/resources/gallery.php

==
5. NEW WILD FX REVIEWS

"We were super impressed by the ability to create text animations 
and effects in seconds that would've taken some considerable time 
to create manually...During our testing of “Wild FX” we found 
that it produced exceptionally small file sizes and clean output."
--Dave Paris, http://www.flashtrix.com

"Wild FX Pro is incredible software! This software is s easy 
to use and offers fantastic effects at such an unbelievably low 
price. Thanks so much for such a great product." 
-- Dave Williams, Virtual Renderings

==
6. COMPLIMENTARY VIDEO: THANKSGIVING CLIP 

All of us here at Wildform wish you a very happy Thanksgiving!
http://www.wildform.com/cm/turkey_displaying_4_col_mos.zip

(.Avi, 1.78 MB download.
This download will be available until November 30, 2003)

Visit the Wildform Video Library for great video clips
http://www.wildform.com/videolibrary/

==
7. SITES WE LIKE

ERIC CONVEYS AN EMOTION
http://www.emotioneric.com/ 

INFOURM
http://www.infourm.com
Design magazine recently update.

FLASHEUR FORMAT PRODUCTIONS
http://www.flasheur.fr.st/
French design site.

MOLUV’s PICKS
http://www.moluv.com
Nice design resource site.

FIND TUTORIALS
http://www.findtutorials.com/

==
ADVERTISEMENT – ADVERTISEMENT – ADVERTISEMENT

R Blank Interactive Design provides high-performance solutions 
including e-learning engines, PC and web applications, and 
immersive web sites - for businesses and agencies through a range 
of services including design, development, consulting and training. 
R Blank is a certified Macromedia Flash Developer and Designer. 
For more information, please visit: www.rblank.com 
R Blank Interactive Design also hosts LA Flash, the Macromedia User 
Group for LA and Santa Monica area Flash developers. Meetings are 
monthly, there is no charge for membership, and we have great 
online resources. For more information please visit: 
www.rblank.com/laflash 

==
PRIVACY
Wildform does NOT sell or rent the email addresses belonging
to our subscribers; we respect your privacy.
=
Wildform  http://www.wildform.com 
Purchase Page   http://ww

Re: First pass all buildds before entering unstable

[Luca - De Whiskey's - De Vitis]

On Wed, Nov 19, 2003 at 09:44:31AM +0100, Giacomo A. Catenazzi wrote:
> No!!! it would delay to much the entry of some important packages in 
> unstable. It would maybe improve some architectures, but definitely 
> would reduce extensive testing of newer versions.

In which way would it improve some architectures and not the overall Debian
quality? why would it reduce extensive testing of newer versions? Rejecting a
package which is not buildable on a spacific architecture, because of an
unpstream or maintainer fault, is a semi-automatic testing that can be
implemented.

If we let it in and then we auto-build it, we get a new package with FTBFS
(i.e RC) bugs and slow down release even more.
If we auto-build it first and, if no upstream/package faults, we let it in, we
get less RC bugs.

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: First pass all buildds before entering unstable

[Luca - De Whiskey's - De Vitis]

On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote:
> I don't think people would like it if their package stayed in incoming
> for multiple weeks because there's a backlog on some architecture.

Neither i. This is why i would like to receive baklogs mailed to maintainer if
autobuild fails. But i would like to receive backlogs even for pre-autobuilds,
so that i could fix the problem, contact the upstream etc.

BTW, i think that the correct workflow would be:
Move package from incoming to autobuild. If all architectures build, continue
(as before this change); else, if not builded but is not upstrea/maintainer
fault, continue (as before this change). Else reject the package.

> Unstable is there for that kind of things. And to detect other kinds of
> bugs, too. If you're going to keep packages in incoming like this,
> people won't be able to test it until it's built on all architectures.

If we stay as it is, we'll continue to get slowed by badly built
packages/softwares.

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.


pgpykhdfZUnbE.pgp
Description: PGP signature

好家长的选择

[[EMAIL PROTECTED]]

现在，电脑在家庭越来越普及，很多家庭的未成年人都有自己的电脑，
电脑的使用带来了新的资讯、知识和娱乐，但也带来了新的问题。电脑
和网络游戏盛行，互联网的资讯多姿多彩，QQ上又有无数的聊友，使得
很多青少年人都沉浸在电脑的世界里，耽误了学习，影响了正常的生活
，甚至还产生了严重的后果! 网上的相关报导多不胜数。

所以,我们开发了合丰--好家长2.0，免费下载试用。
产品的功能：   
 限制上网的时间，能对网址进行过滤，
-屏蔽不必要的网址
限制运行或禁止运行各种程序，
-当然也可以对游戏和QQ控制；
记录QQ的聊天内容
-对网络交友进行了解和引导；
记录访问过的网址；
-了解孩子的兴趣，进行必要引导
记录使用过的程序；
-了解孩子聊天与玩游戏的频率；
能对屏幕进行录像，并压缩，方便日后查看；
-综合了解您的孩子。
您只要花较少的时间，就可以对您的孩子有较全面的了解，然后进行必要引导与交流。 

详情请看：
http://www.hefeng-it.com/product1.htm
下载：
http://www.hefeng-it.com/download.htm
请先看说明书再使用！

Re: Some observations regardig the progress towards Debian 3.1

[Yann Dirson]

Adrian wrote:
> Your proposal wouldn't have been able to shorten the move of KDE 3 into 
> testing by one single day.

Yes, my comment was misplaced wrt what you said, this problem still
has to be addressed.  My proposal, however, is more targetted to
packages which would build with, say, KDE2, but are held into unstable
because here they are build with KDE3.

KDE may not be a good example.  libgc is a much better example,
although the number of packages held here is quite low compared to
KDE.


> testsuites must be written, and testsuites for GUI programs are even 
> more work.

Fortunately several of the packages we ship already have one.

And for the bunch of non-gui programs, we could surely add some
minimal testing, say to ensure it does not segfault on trivial use
cases.  Just like what we already do for manpages.

GUI programs are another story, but that's not a reason not to do it
for non-GUI ones.


> > > There might be new problems e.g. with inter-library dpendencies for 
> > > libraries without versioned symbols if your proposal would be 
> > > implemented.
> > 
> > Hm ?  I'm not sure I understand what the problem you mention is.
> 
> An example:
> 
> unstable:
> 
> Package: libfoo0
> Depends: libbar1
> 
> Package: mypackage
> Depends: libfoo0, libbar1
> 
> testing:
> 
> Package: libbar0

s/testing/pre-testing/


> IOW:
> The program in mypackage is in this situation linked with two different 
> so-versions of libbar at the same time.

That's a good point.  In my mind the libfoo0 package just rebuilt
would only show up in pre-testing.  We need to keep the original
package in unstable, while increasing its version at the same time.
That could be done either by a rebuild, or, less costly, by a simple
unpack/edit-changelog/repack.

In that case, if we had libfoo0_1.0-1 in pre-testing, and
libfoo0_1.0-2 in unstable, we'd end up with libfoo0_1.0-2.0.1 in
pre-testing, and libfoo0_1.0-2.0.2 in unstable, whether the latter was
rebuilt or just repacked.

Regards,
-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

Re: debian-installer beta 1

[Bart Schuller]

On Sun, Nov 16, 2003 at 10:42:11PM +0100, David Weinehall wrote:
> On Mon, Nov 17, 2003 at 07:52:32AM +1100, Brian May wrote:
> > 
> > 1. Linux 2.6.0?
> 
> Not released yet. Yes, it has a _lot_ of nice features, but it is beta
> software..

It (or patches to 2.4.22) is also needed if you decide to buy a modern
machine right now. I've had to dig up an old plain IDE disk to stage a
Linux install to my dual SATA drives in my new machine.

Otherwise the beta installer worked fine.

The strange thing with SATA support is that I couldn't get the modules
in debian's 2.6.0-test9 kernel to recognize my drives, but a self
compiled 2.6.0-test9-bk19 kernel with the SATA drivers (for promise and
via) compiled in did work.

-- 
Bart.

Re: First pass all buildds before entering unstable

[Andreas Tille]

On Wed, 19 Nov 2003, Luca - De Whiskey's - De Vitis wrote:

> If we let it in and then we auto-build it, we get a new package with FTBFS
> (i.e RC) bugs and slow down release even more.
> If we auto-build it first and, if no upstream/package faults, we let it in, we
> get less RC bugs.
Exactly this was the idea.  I'm unsure whether experimental could serve as
this kind of staging area.

Kind regards

Andreas.

perl 5.8.2-2 & mips buildd

[Domenico Andreoli]

hi,

i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd.

why it is in this state? it blocks the build of a lot of software.

cheers
dom

-[ Domenico Andreoli, aka cavok
 --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: First pass all buildds before entering unstable

[Francesco P. Lovergine]

On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote:
> 
>What about if each freshly uploaded package which contains architecture any
>packages would enter kind of a staging area first and buildds grab these
>files from there.  After each buildd was able to build a package the whole
>set with all architectures enters unstable at once.
> 

I cannot see any real advantage for that, but for avoiding a FTBFS
reports proliferation. Also

a. Packages could become FTBFS later, when their dependency pkgs change.

b. They are already kept off testing (if there is a regression), 
   so what's the problem?

c. Very few packages are seriuosly broken on some archs. Their problems are
   generally due either to compiler/binutils problems or upstream
   coding. In both cases removing them on some archs could be a
   profitable solution for releasing.

-- 
Francesco P. Lovergine

Re: First pass all buildds before entering unstable

[Andreas Tille]

On Wed, 19 Nov 2003, Francesco P. Lovergine wrote:

> b. They are already kept off testing (if there is a regression),
>so what's the problem?
The problem is that other packages which might depend from a package
which is broken on one architecture will not move into testing.  If you
would keep those packages out of unstable you can be sure that you
build your own package based on packages which have all the same version
in unstable.  This is the relevant bit of the suggestion.  See the lot
of packages which can not enter testing because a dependency is not
fulfilled on a certain architecture.

Kind regards

Andreas.

Re: First pass all buildds before entering unstable

[Francesco P. Lovergine]

On Wed, Nov 19, 2003 at 11:10:14AM +0100, Andreas Tille wrote:
> On Wed, 19 Nov 2003, Luca - De Whiskey's - De Vitis wrote:
> 
> > If we let it in and then we auto-build it, we get a new package with FTBFS
> > (i.e RC) bugs and slow down release even more.
> > If we auto-build it first and, if no upstream/package faults, we let it in, 
> > we
> > get less RC bugs.
> Exactly this was the idea.  I'm unsure whether experimental could serve as
> this kind of staging area.
> 
A FTBFS for a new package is not a RC error. Only regressions are RC.

-- 
Francesco P. Lovergine

Re: MIPS port backlog, autobuilder machines and some arrogance

[Andreas Metzler]

Ingo Juergensmann <[EMAIL PROTECTED]> wrote:
[...]
> Perl is building fine as well now on mips, although it is marked as
> not-for-us. See
> http://m68k.bluespice.org/cgi/package_status?mips_pkg=perl&searchtype=go

> paco:/home/ij# ls -l *.deb
> -rw-r--r--1 root root35172 Nov 18 22:24 
> libcgi-fast-perl_5.8.2-2_all.deb
> -rw-r--r--1 root root   651210 Nov 18 22:32 
> libperl-dev_5.8.2-2_mips.deb
> -rw-r--r--1 root root 1002 Nov 18 22:31 
> libperl5.8_5.8.2-2_mips.deb
[...]

Can somebody please give it a kick or an upload? Afaict Perl's testing
migration is only blocked by missing builds for mips and mipsel.
 cu andreas

Re: First pass all buildds before entering unstable

[Giacomo A. Catenazzi]

Luca - De Whiskey's - De Vitis wrote:
(...)
Why developers should care more about packages not entering
into unstable that packages not entering into testing?
I worry about indirect delays. Scenario: developer A@ do good job with 
packages A, but A requires packages B. What should A do?
Waiting and not lose the motivation?
Help B@, maybe with a NMU, but still waiting the canonical time for NMU 
(on normal time)?

Do A@ have knows enought about B to help? (Maybe B is in a other 
language, for glibc, XFree86,.. specific architectures knowelenge are 
maybe required,...

If you want to implement such pre-autobuild I would like to see:
- relaxed NMU time
- the developers (maybe requiring not only uploader) could override the 
waiting status in pre-unstable queue.
- ..

ciao
giacomo

Re: First pass all buildds before entering unstable

[Luca - De Whiskey's - De Vitis]

On Wed, Nov 19, 2003 at 11:10:14AM +0100, Andreas Tille wrote:
> Exactly this was the idea.  I'm unsure whether experimental could serve as
> this kind of staging area.

I would keep experimental only for experiments (:P), while i see your proposal
as a new step to be included in our packages workflow; thus i would use
unstable. Moreover, experimental is not autobuilded because of high chances of
broken packages in it.

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Bug#221632: ITP: jaabc2ps -- Converts abc text music notation to postscript sheet music

[Raphael Goulais]

Package: wnpp
Severity: wishlist

* Package name: jaabc2ps
  Version : 1.1.0
  Upstream Author : John Atchley <[EMAIL PROTECTED]>
* URL : http://www.guitarnut.com/
* License : GPL
  Description : Converts abc text music notation to postscript sheet music

Produces postscript sheet music and tinwhistle and stringed-instrument
tablature from abc music  notation (text) files.  A child of abcm2ps
version 0.9.5, many features have been added.  abcm2ps is a child of
abc2ps.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux babasse 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: First pass all buildds before entering unstable

[Francesco P. Lovergine]

On Wed, Nov 19, 2003 at 11:33:05AM +0100, Andreas Tille wrote:
> On Wed, 19 Nov 2003, Francesco P. Lovergine wrote:
> 
> > b. They are already kept off testing (if there is a regression),
> >so what's the problem?
> The problem is that other packages which might depend from a package
> which is broken on one architecture will not move into testing.  If you
> would keep those packages out of unstable you can be sure that you
> build your own package based on packages which have all the same version
> in unstable.  This is the relevant bit of the suggestion.  See the lot
> of packages which can not enter testing because a dependency is not
> fulfilled on a certain architecture.
> 
Ah so, the staging area is for a program with all its dependencies?
Isn't testing simply thought for this?

-- 
Francesco P. Lovergine

Re: First pass all buildds before entering unstable

[Luca - De Whiskey's - De Vitis]

On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote:
> I worry about indirect delays. Scenario: developer A@ do good job with 
> packages A, but A requires packages B. What should A do?
> Waiting and not lose the motivation?
> Help B@, maybe with a NMU, but still waiting the canonical time for NMU 
> (on normal time)?
> 
> Do A@ have knows enought about B to help? (Maybe B is in a other 
> language, for glibc, XFree86,.. specific architectures knowelenge are 
> maybe required,...

IMHO, We should not warry about indirect delay/problems. It's not A's fault,
thus A should be warranted to be released (in a way or in another): A not
being in testing because of B is "part of the game". The problem which must be
handled is B, and who or how to handle it is too case specific to be
considered here. We have 'help' tag on BTS and specific mailing lists to ask
for help on specific topic.

BTW, when i did NMU i based the delay either on the best practice and on the 
need
of the fix. I thought it to be reasonable.

> - the developers (maybe requiring not only uploader) could override the 
> waiting status in pre-unstable queue.

I do not understand this: what do you mean?

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: First pass all buildds before entering unstable

[Andreas Metzler]

Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote:
>> I don't think people would like it if their package stayed in incoming
>> for multiple weeks because there's a backlog on some architecture.

> Neither i. This is why i would like to receive baklogs mailed to maintainer if
> autobuild fails. But i would like to receive backlogs even for pre-autobuilds,
> so that i could fix the problem, contact the upstream etc.
[...]

backlog: Package is stuck in queue of autobuilder, no build failure.

e.g. linuxtv-dvb_1.0.1-6 was uploaded on Oct 31 and Mips still has not
_tried_ not build it.
   cu andreas

Re: Debian communication and attitude [was: Re: Example of really nasty DD behavior]

[Jonathan Dowland]

On Sun, Nov 16, 2003 at 12:44:03PM +0100, Henning Makholm wrote:
 
> No, but if you don't do it, you forfeit your right to whine about
> duplicate work when it turns out that you're not the only one who has
> been doing work without telling anybody about it.

So, _both_ people involved should have ITPd, early.

-- 
Jon Dowland
http://jon.dowland.name/

Re: First pass all buildds before entering unstable

[Andreas Tille]

On Wed, 19 Nov 2003, Giacomo A. Catenazzi wrote:

> I worry about indirect delays. Scenario: developer A@ do good job with
> packages A, but A requires packages B. What should A do?
> Waiting and not lose the motivation?
But the problem can be the other way around: A builds his package against
package of B which has no chance to enter testing.  This is frustrating.
Or even A builds his package against a version of package B which is fine
but will be overriden by a new version of B which has an FTBFS bug before
the old version of package B had a chance to enter testing.

> Help B@, maybe with a NMU, but still waiting the canonical time for NMU
> (on normal time)?
Perhaps.  Or rather B might be try harder to get his package into unstable.

> If you want to implement such pre-autobuild I would like to see:
> - relaxed NMU time
> - the developers (maybe requiring not only uploader) could override the
> waiting status in pre-unstable queue.
> - ..
Hmmm, why not, but this is not necessaryly connected to my suggestion.

Kind regards

  Andreas.

--
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)

Re: Build-depends for Rekall?

[Goswin von Brederlow]

Tom <[EMAIL PROTECTED]> writes:

> This seems on topic for the list's stated purpose: "Discussion about 
> technical development topics."
> 
> I'm trying to build rekall from rekallrevealed.org.  It seems like it's 
> going to have lots of build dependencies.  If anyone has ever built it 
> on debian, or can provide a probable list of build-depends I'll need, 
> I'd appreciate it.
> 
> I've already done an "apt-get build-depends kcontrol".  I haven't made 
> any special effort to get postgres or mysql build-depends on my system.  
> (I intend to use it with the xbase driver for tiny personal databases).
> 
> Thanks

Use a clean chroot with just base and build-essential. After that you
have to look for build errors or warnings thats some feature gets
disabled due to missing libs or programs.

MfG
Goswin

Re: First pass all buildds before entering unstable

[Goswin von Brederlow]

Andreas Tille <[EMAIL PROTECTED]> writes:

> Hi,
> 
> just an idea from a completely uneducated person regarding buildd:
> 
>What about if each freshly uploaded package which contains architecture any
>packages would enter kind of a staging area first and buildds grab these
>files from there.  After each buildd was able to build a package the whole
>set with all architectures enters unstable at once.
> 
> This would get us rid of all those packages in unstable with "Does not build
> on ..." and several dependencies could be easier solved.  Moreover it would
> enhance the preasure on developers to care for this kind of bugs.
> 
> I guess this would be not really hard to implement.
> 
> Just ignore me if this is a stupid idea

You are ignoring all the packages that don't build and never have been
build for some architecture. Mainly that happens if some
build-depends, like the compiler needed, wasn't yet ported.

All the packages that are excluded from an arch indirectly because
some other package is not for that arch would need to be changed to
specifically exclude that arch. And once the actualy faulty package
gets ported the change has to be reversed.

There is a reason testing script only require archs that did
previously build.

MfG
Goswin

Re: Some observations regardig the progress towards Debian 3.1

[Andrew Suffield]

On Tue, Nov 18, 2003 at 10:15:25AM -0600, John Goerzen wrote:
> On Sat, Nov 15, 2003 at 05:35:19PM +, Andrew Suffield wrote:
> > On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> > > - Debian 3.0 doesn't support much of the hardware curently available -
> > >   the old 2.4.18 kernel on the boot floppies doesn't even boot on many
> > >   new computers (some Promise IDE chipsets require a more recent 2.4 
> >^^^
> > >   kernel), and much hardware from nearly all currently abailable 
> > ^^
> > 
> > This is false. All the promise IDE chipsets are adequetely supported
> > by 2.4.18, albeit not in anything above ata-33 mode. The only problem
> > is that autodetection fails for some of the newer ones, and you have
> > to manually specify the controller ports.
> 
> That's false.

Bull. I've used several on 2.4.18 through 2.4.21 for years, and I'm
fairly certain I covered all the chipsets (there aren't many). Don't
try to tell me that it doesn't work.

> I still can't use my Promise drive in DMA mode (must use -d 0 with hdparm)
> because heavy write activity causes the kernel to hang.

We are not talking about Promise hard drives (I didn't know they sold
IDE drives, I've only seen SCSI ones under their label). And that does
sound like a hard drive bug (or a bad cable) to me, I've seen a few
drives do that before.

This is not evidence of a lack of controller support.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Bug#217017: ITP: Sagasu - GNOME tool to find strings in a set of files

[Daniel Gubser]

Sorry for my late reply:

Am Don, 2003-10-23 um 15.17 schrieb Joe Drew:
> > * Package name: sagasu
> Er, what does this add over the standard "Search for files" GNOME
> action?

- use of Perl regex
- max. directory recursion depth

-- 
Daniel Gubser <[EMAIL PROTECTED]>

Re: perl 5.8.2-2 & mips buildd

[Roland Mas]

Domenico Andreoli, 2003-11-19 11:30:17 +0100 :

> i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd.
>
> why it is in this state? it blocks the build of a lot of software.

I'm currently building it by hand.

Roland.
-- 
Roland Mas

Qu'est-ce qui est petit, jaune et vachement dangereux ?
Un canari avec le mot de passe de root.

Re: Is vrms really still a Virtual Richard M. Stallman?

[Florian Weimer]

Roland Stigge wrote:

> debian-legalint

I don't think this is a good idea.  "non-free" doesn't mean "illegal".

Re: Some observations regardig the progress towards Debian 3.1

[Andrew Suffield]

On Wed, Nov 19, 2003 at 10:41:05AM +0100, Yann Dirson wrote:
> > testsuites must be written, and testsuites for GUI programs are even 
> > more work.
> 
> Fortunately several of the packages we ship already have one.

Most do not.

> And for the bunch of non-gui programs, we could surely add some
> minimal testing, say to ensure it does not segfault on trivial use
> cases.  Just like what we already do for manpages.

"Could"? Yes. Do you have any notion of how much work this would be?
It's somewhere in the region of "lots". Actually writing real test
suites for them all would be more of a Herculean task.

> GUI programs are another story, but that's not a reason not to do it
> for non-GUI ones.

Right. It's a reason not to do any of it (test suites, or the
building/migration goo) for GUI programs.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: First pass all buildds before entering unstable

[Giacomo A. Catenazzi]

Luca - De Whiskey's - De Vitis wrote:
On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote:

- the developers (maybe requiring not only uploader) could override the 
waiting status in pre-unstable queue.

I do not understand this: what do you mean?
I don't like automatic system without possibility to have human overide.
I want to be able to upload packages in unstable also if there are 
errors on some architectures, but only on very EXCEPTIONAL cases.

OT: In testing happens that a packages will not uploaded in testing 
because package is "buggier", but often the it is buggier because it is 
in unstable for a long time. You could not tell (AFAIK) that a bug was 
also present in the old testing version, but passed unnoticed.

For this reason, I would like that smarted people (vs "stupid" script 
[Stupid from KISS definition]) can eventualy overide/upload packages in 
unstable. Surelly we need a strict policy about when and how it is allowed.

ciao
giacomo

Re: First pass all buildds before entering unstable

[Andrew Suffield]

On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote:
> just an idea from a completely uneducated person regarding buildd:
> 
>What about if each freshly uploaded package which contains architecture any
>packages would enter kind of a staging area first and buildds grab these
>files from there.  After each buildd was able to build a package the whole
>set with all architectures enters unstable at once.
> 
> This would get us rid of all those packages in unstable with "Does not build
> on ..." and several dependencies could be easier solved.  Moreover it would
> enhance the preasure on developers to care for this kind of bugs.

This seems like a solution in search of a problem. What problem are
you actually trying to solve? Start by describing it, then we can try
dreaming up ways to solve it. [Given your vague description of what
this would accomplish, I have a few guesses about what you might be
trying to do, and I think there are probably less intrusive and more
effective approaches].

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: First pass all buildds before entering unstable

[Andreas Tille]

On Wed, 19 Nov 2003, Goswin von Brederlow wrote:

> You are ignoring all the packages that don't build and never have been
> build for some architecture. Mainly that happens if some
> build-depends, like the compiler needed, wasn't yet ported.
But this is no FTBFS bug than.  I just want to keep packages which will
have FTBFS bugs which can be automatically detected out of the door.
Currently we have more than 100 FTBFS bugs.  It is hard to say which
of them could be detected at upload time.  But if there is an
automatic method to sort out packages even before they enter unstable
we should do so to stop their influence to other dependant packages.

> There is a reason testing script only require archs that did
> previously build.
Well, but this is done automatically.  I do not want to change anything
here.

Kind regards

  Andreas.

--
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)

Re: First pass all buildds before entering unstable

[Andreas Tille]

On Wed, 19 Nov 2003, Andrew Suffield wrote:

> This seems like a solution in search of a problem. What problem are
> you actually trying to solve? Start by describing it, then we can try
> dreaming up ways to solve it. [Given your vague description of what
> this would accomplish, I have a few guesses about what you might be
> trying to do, and I think there are probably less intrusive and more
> effective approaches].
Sorry if my English is not as brilliant to explain the problem clearly
to everybody.  So I try a simple example:

 http://qa.debian.org/developer.php?excuse=postgresql

If there would be a recent perl for each architecture postgresql
would have entered testing.  I guess there was a working perl before
there was trouble with MIPS buildd which wuold have enabled postgresql
to enter testing.

Feel free to search for other examples whose show stoppers are FTBFS
bugs.

Kind regards

   Andreas.

--
Sie schaffen eine Wüste und nennen es Frieden.
-- Publius Cornelius Tacitus (55-120)

New kernel headers break LVM build

[Patrick Caulfield]

LVM1 includes kernel headers in its build - yeah, I know, but it does interface
(rather too) tightly into the kernel.

The problem now is that the linux-kernel-headers package has Linux 2.6 files in
it rather than 2.4 and LVM(1) is not supported in 2.6. so it doesn't build. 

This isn't a new problem with LVM. ie: not upgrading to 1.0.7 isn't the answer
as 1.0.7 won't build in this environment either.
Bug: #221663

The only solution I can think of is for the lvm10 package to build-depend on
(eg) kernel-source-2.4.19, then in the build script untar the header
files, make the arch symlink (ugh) and compile against that.

Does anyone else have any nicer ideas? apart from getting everyone to migrate to
LVM2 :-)
-- 

patrick

Re: Is vrms really still a Virtual Richard M. Stallman?

[Roland Stigge]

On Wed, 2003-11-19 at 14:41, Florian Weimer wrote:
> > debian-legalint
> 
> I don't think this is a good idea.  "non-free" doesn't mean "illegal".

In contrast to the common German denotation of the word "legal"
("allowed"), consider the one implied by the usage of "legal" in names
like "debian-legal" ("rechtlich", "gesetzlich").

bye,
  Roland


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

Re: Some observations regardig the progress towards Debian 3.1

[Wookey]

+++ Yann Dirson [03-11-18 22:54 +0100]:
> On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote:

> But that last point raises another issue: does anyone really use
> testing ?  Would anyone use pre-testing after all ?

I used testing for a couple of years on my laptop and non-critical machines.
I found it a satisfactory compromise between the 'too old' of stable and the
massive churn, ever-changing packages and general need-for undating and
maintenance of unstable.

The primary reason I changed was the 'no security for testing' problem. So I
have moved them both to unstable, but it's a lot of extra work and downloads
for little gain (I get new packages sooner which is interesting but rarely
actually useful) - the only other advantage I get (and the secondary reason
I changed) is that I can do test-builds of my packages before uploading on
an unstable machine. Doing my builds on a testing machine, then uploading to
unstable can mean I introduce packages compiled against the wrong library
versions. Source-only uploads would solve this and I could do test-compiles
on some debian machine.

So I'd say yes, testing is useful to real people, especially those with
low-bandwidth net connections but for whom stable is a bit too old. The only
thing we need to change to make it more widely useful is to make security
updates happen for it in a timely fashion. That would be a sensible use of
resources I think. More people using testing ought to help keep it
releasable.

> > Is testing actually worth the effort?

> I suppose many of use have a number of problems to mention.  Could we
> just (attempt to) list them all, and see if they can be fixed easily ?
> Or if they require some in-depth restructuring ?
> 
> I'll start with:
> 
> - build-deps are ignored, causing unbuildable stuff
>  => handle build-deps in exactly the same way deps are

Could someone explain to me why this is the case? Was it an attempt to get
things into testing faster that if build-deps were honoured, or was it just
expediency. It does seem more sensible to enforce build-deps too to me, but
I may be missing something.

> - insufficiently-narrowed deps, causing stuff to migrate where it
>   should not
>  => this looks like a real non-trivial problem to me.  Ideas anyone ?

Obviously it can be tricky for a maintainer to get right as they can't
necessarily try all (any!) of the possibilities but it should be aspired-to.
On the other hand, in my experience build-deps are sometimes
unecessaily-narrowed and require new versions of things for no particular
reason I can determine. I suspect the shlibdeps automation contributes to
this?

> > testing with its lack of security fixes, aprox. 500 RC bugs and daily 
> > changing packages is not usable for production systems.
> 
> What's the problem with daily changing packages ?  By nature, only
> different packages can change each day.  That could make it a good
> compromise between stable and unstable, eg. for people in need for
> up-to-date desktops.  But precisely, one of the problems for those
> people, is that _some_ packages _do_not_ change rapidly enough...

It's all a compromise, but it's a useful compromise IMHO. It makes sense to
me to view testing as a releasable version of unstable and try to keep it
that way as much as possible. Build-deps being added to the
unstable->testing migration criteria seems to me to be the most fundamental
change needed to make that more true, and security support to make it
practical for people to use/test in the real world.

All the above IMHO as I don't claim to have a deep understanding of all the
dependency and trnsitionning issues. I do have an interest in consistent
buildability for embedded Debian though.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/

Hercules Stingray 128 3D Driver

[Foster William MSgt AF/XPI-ES]

Would you have a 
Win2K/WinXP driver?  Thanks.
 
 
WILLIAM E. FOSTER
Chief, Information Technology & 
Security
DCS/Plans and Programs
mailto:[EMAIL PROTECTED]
comm:  703 
695-3539
DSN:  
225-3539  
<>

Re: New kernel headers break LVM build

[Christoph Hellwig]

On Wed, Nov 19, 2003 at 02:18:34PM +, Patrick Caulfield wrote:
> The only solution I can think of is for the lvm10 package to build-depend on
> (eg) kernel-source-2.4.19, then in the build script untar the header
> files, make the arch symlink (ugh) and compile against that.
> 
> Does anyone else have any nicer ideas? apart from getting everyone to migrate 
> to
> LVM2 :-)

Fix LVM1 to keep copies of the headers it needs in it's source tree.

Re: Is vrms really still a Virtual Richard M. Stallman?

[Florian Weimer]

Roland Stigge wrote:

> On Wed, 2003-11-19 at 14:41, Florian Weimer wrote:
> > > debian-legalint
> > 
> > I don't think this is a good idea.  "non-free" doesn't mean "illegal".
> 
> In contrast to the common German denotation of the word "legal"
> ("allowed"), consider the one implied by the usage of "legal" in names
> like "debian-legal" ("rechtlich", "gesetzlich").

Sorry, I don't understand what you are trying to say.

Let me rephrase my statement.  "non-free" does not mean "not conforming
to the law".

Re: Trouble Compiling Simple Glade.

[Mark Howard]

Hi,
  debian-devel is a list for development of the Debian distribution, not
a general programming list. For a more appropriate list, look on the
glade website at glade.gnome.org.

I'm afraid I can't help you with this problem, but I do offer some
advice: use libglade to load the glade xml dynamically from your program
rather than generating c code from the glade xml and then editing that -
you will then find it far easier to modify your interface in the future.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: Hercules Stingray 128 3D Driver

[Greg Folkert]

On Wed, 2003-11-19 at 09:14, Foster William MSgt AF/XPI-ES wrote:
> Would you have a Win2K/WinXP driver?  Thanks.
>  
>  
> WILLIAM E. FOSTER
> Chief, Information Technology & Security
> DCS/Plans and Programs
> mailto:[EMAIL PROTECTED]
> comm:  703 695-3539
> DSN:  225-3539

Sorry this is a mailing list for the Development of the Debian Linux
Distribution. If you would like help with Windoze anything, please look
elsewhere.

By the way, messages sent to any [EMAIL PROTECTED] is very
much a Debian Linux thing. Please choose your recipients more carefully.
  
-- 
greg, [EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry

Oh, how your melodic chewing of cotton balls cancels the stamp on my
papyrus telegram from the Queen of England.


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

Re: First pass all buildds before entering unstable

[Colin Watson]

On Wed, Nov 19, 2003 at 03:12:42PM +0100, Andreas Tille wrote:
> On Wed, 19 Nov 2003, Andrew Suffield wrote:
> > This seems like a solution in search of a problem. What problem are
> > you actually trying to solve? Start by describing it, then we can try
> > dreaming up ways to solve it. [Given your vague description of what
> > this would accomplish, I have a few guesses about what you might be
> > trying to do, and I think there are probably less intrusive and more
> > effective approaches].
> 
> Sorry if my English is not as brilliant to explain the problem clearly
> to everybody.  So I try a simple example:
> 
>  http://qa.debian.org/developer.php?excuse=postgresql
> 
> If there would be a recent perl for each architecture postgresql
> would have entered testing.  I guess there was a working perl before
> there was trouble with MIPS buildd which wuold have enabled postgresql
> to enter testing.

And if we hadn't had perl 5.8.1 in unstable, then we would never have
spotted its binary incompatibility with 5.8.0. Upstream released 5.8.2
precisely because the problem had been discovered in Debian unstable.
Under your proposal, we would have remained unaware of the problem for
much longer, which would have been a bad thing.

This is in fact an excellent example of how fixing build problems isn't
enough to ensure a quality distribution, and how it's often important to
parallelize fixing build problems and other problems rather than
serializing the two tasks.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: perl 5.8.2-2 & mips buildd

[Colin Watson]

On Wed, Nov 19, 2003 at 11:05:49AM +0100, Domenico Andreoli wrote:
> i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd.
> 
> why it is in this state? it blocks the build of a lot of software.

I'm told that getting it past the test suite requires a newer kernel,
which our mips buildds don't currently have installed.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: [debian-devel] Re: Is vrms really still a Virtual Richard M. Stallman?

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Florian Weimer a következőeket írta:
> Let me rephrase my statement.  "non-free" does not mean "not conforming
> to the law".

Non-free does mean "not conforming to the internal law of the project".

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

Re: [debian-devel] Re: Is vrms really still a Virtual Richard M. Stallman?

[Florian Weimer]

MagosÃnyi ÃrpÃd wrote:

> A levelezÅm azt hiszi, hogy Florian Weimer a kÃvetkezÅeket Ãrta:
> > Let me rephrase my statement.  "non-free" does not mean "not conforming
> > to the law".
> 
> Non-free does mean "not conforming to the internal law of the project".

The Social Contract mandates that Debian offers non-free software for
download, so you can hardly argue that doing so breaks Debian's own
laws.

Bug#221679: ITP: libglib-perl -- Perl interface to the Glib and GLib's GObject libraries

[Marc Brockschmidt]

Package: wnpp
Severity: wishlist

* Package name: libglib-perl
  Version : 1.011
  Upstream Author : Gtk2-Perl Team <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~mlehmann/Glib-1.011/
* License : LGPL-2
  Description : Perl interface to the Glib and GLib's GObject libraries

This module provides perl access to GLib and GLib's GObject libraries.
GLib is a portability and utility library; GObject provides a generic
type system with inheritance and a powerful signal system.  Together
these libraries are used as the foundation for many of the libraries
that make up the Gnome environment, and are used in many unrelated
projects.

Re: [debian-devel] Re: Is vrms really still a Virtual Richard M. Stallman?

[David Weinehall]

On Wed, Nov 19, 2003 at 04:04:49PM +0100, Florian Weimer wrote:
> Magosányi Árpád wrote:
> 
> > A levelez??m azt hiszi, hogy Florian Weimer a következ??eket írta:
> > > Let me rephrase my statement.  "non-free" does not mean "not
> > > conforming to the law".
> > 
> > Non-free does mean "not conforming to the internal law of the
> > project".
> 
> The Social Contract mandates that Debian offers non-free software for
> download, so you can hardly argue that doing so breaks Debian's own
> laws.

Ehhh?

"Thus, although non-free software isn't a part of Debian, we
 support its use, and we provide infrastructure (such as our
 bug-tracking system and mailing lists) for non-free software
 packages." -- Excerpt from the social-contract

This definitely does not _mandate_ that Debian offers non-free software,
it says that we currently do so.  Something mandatory is something that
has to be done.  Debian does not _have_ to offer non-free software
(at least not to the best of my knowledge.  If we do, I might have to go
 looking for a new project to be a part of...)


Note: I'm not arguing against your protest regarding "Debian's own
laws", but rather your incorrect use of the word mandate.


Regards: David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

Bug#221687: ITP: libextutils-pkgconfig -- simplistic perl interface to pkg-config

[Marc Brockschmidt]

Package: wnpp
Severity: wishlist

* Package name: libextutils-pkgconfig
  Version : 1.00
  Upstream Author : muppet <[EMAIL PROTECTED]>
* URL : http://gtk2-perl.sourceforge.net/
* License : LGPL
  Description : simplistic perl interface to pkg-config

 The pkg-config program retrieves information about installed libraries,
 usually for the purposes of compiling against and linking to them.
 .
 ExtUtils::PkgConfig is a very simplistic interface to this utility, intended
 for use in the Makefile.PL of perl extensions which bind libraries that
 pkg-config knows. It is really just boilerplate code that you would've
 written yourself.

Bug#221684: ITP: libextutils-depends-perl -- easily build XS extensions that depend on XS extensions

[Marc Brockschmidt]

Package: wnpp
Severity: wishlist

* Package name: libextutils-depends-perl
  Version : 0.102
  Upstream Author : Paolo Molaro <[EMAIL PROTECTED]>
* URL : http://gtk2-perl.sf.net/
* License : ? (Mailed upstream)
  Description : easily build XS extensions that depend on XS extensions

This module tries to make it easy to build Perl extensions that use
functions and typemaps provided by other perl extensions. This means
that a perl extension is treated like a shared library that provides
also a C and an XS interface besides the perl one.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux Asfaloth 2.4.21-rc2-ac2 #2 Don Mai 22 14:13:00 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: New kernel headers break LVM build

[Patrick Caulfield]

On Wed, Nov 19, 2003 at 03:33:53PM +0100, Christoph Hellwig wrote:
> On Wed, Nov 19, 2003 at 02:18:34PM +, Patrick Caulfield wrote:
> > The only solution I can think of is for the lvm10 package to build-depend on
> > (eg) kernel-source-2.4.19, then in the build script untar the header
> > files, make the arch symlink (ugh) and compile against that.
> > 
> > Does anyone else have any nicer ideas? apart from getting everyone to 
> > migrate to
> > LVM2 :-)
> 
> Fix LVM1 to keep copies of the headers it needs in it's source tree.

including asm directories for all 18 architectures. Ah well; if it's already
gross, making it hugely gross is not much of a descent.

-- 

patrick

Re: Tabs v.s. spaces

[Steve Lamb]

Cameron Patrick wrote:
Nope, no fall-through in that one, so it doesn't help.  It /is/ nifty
though :-)
Uh, there was a fall through there.  Notice that if x has a value that 
isn't in the dictionary the if will fall through to the else.

--
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
   PGP Key: 8B6E99C5   | main connection to the switchboard of souls.
---+-


pgpM33yGILlrf.pgp
Description: PGP signature

Re: Some observations regardig the progress towards Debian 3.1

[Martin Quinson]

I like this idea of pre-testing. It would allow to cut down the versionned
dependencies caused by automatic detection and allow a quicker move to
testing. 

The issue I see however is that a package rebuilded that way would go into
testing without being tested by anyone. What if a given package fail to work
when compiled with libs in testing? I agree that would be a missing
versionning in the build-dep, but who would detect it?

I'm afraid that such mistakes would lead to the disparition of the package
from testing until its versionned build-dep comes into testing, which would
be even more problematic than outdated content of testing, IMHO.

Thanks, Mt.


signature.asc
Description: Digital signature

Re: New kernel headers break LVM build

[Andres Salomon]

You might be able to get away w/ simply including the lvm-specific kernel
headers in your package, as long as the lower level asm stuff that it uses
haven't changed their interface in 2.6.  OTOH, it also might introduce
subtle bugs.  Maybe you're better off build-dep'ing.

Sigh.  I should probably rebuild lvm2 to see if the new kernel-headers
package breaks it; I currently include 2.4 kernel headers in the package.



On Wed, 19 Nov 2003 15:53:58 +, Patrick Caulfield wrote:

> On Wed, Nov 19, 2003 at 03:33:53PM +0100, Christoph Hellwig wrote:
>> On Wed, Nov 19, 2003 at 02:18:34PM +, Patrick Caulfield wrote:
>> > The only solution I can think of is for the lvm10 package to build-depend 
>> > on
>> > (eg) kernel-source-2.4.19, then in the build script untar the header
>> > files, make the arch symlink (ugh) and compile against that.
>> > 
>> > Does anyone else have any nicer ideas? apart from getting everyone to 
>> > migrate to
>> > LVM2 :-)
>> 
>> Fix LVM1 to keep copies of the headers it needs in it's source tree.
> 
> including asm directories for all 18 architectures. Ah well; if it's already
> gross, making it hugely gross is not much of a descent.

will we freeze?

[Graham Wilson]

On Tue, Nov 18, 2003 at 08:58:17AM -0500, Stephen Frost wrote:
> It would be really nice to have 7.4 in sarge..  Personally I think
> there should probably be enough time given the lack of messages on
> d-d-a regarding freezes and the like.  7.4 adds alot of nice things
> and speeds up a number of operations, etc.

Will a freeze be announced? Is that how it has been done in the past?

-- 
gram


signature.asc
Description: Digital signature

Re: will we freeze?

[Andreas Metzler]

On Wed, Nov 19, 2003 at 10:43:22AM -0600, Graham Wilson wrote:
> On Tue, Nov 18, 2003 at 08:58:17AM -0500, Stephen Frost wrote:
> > It would be really nice to have 7.4 in sarge..  Personally I think
> > there should probably be enough time given the lack of messages on
> > d-d-a regarding freezes and the like.  7.4 adds alot of nice things
> > and speeds up a number of operations, etc.
> 
> Will a freeze be announced? Is that how it has been done in the past?

Yes. Check the debian-devel-announce archives June-2001 to June-2002
for mails with subject "Woody Freeze Plans" or Release Status Update
by aj if you want to know how it (did not;-) work last time.
   cu andreas

Re: Some observations regardig the progress towards Debian 3.1

[Yann Dirson]

On Wed, Nov 19, 2003 at 02:03:08PM +, Wookey wrote:
> Doing my builds on a testing machine, then uploading to
> unstable can mean I introduce packages compiled against the wrong library
> versions. Source-only uploads would solve this and I could do test-compiles
> on some debian machine.

Off topic - you can have an unstable chroot on your testing machine
for this, eg. with pbuilder.


> > - insufficiently-narrowed deps, causing stuff to migrate where it
> >   should not
> >  => this looks like a real non-trivial problem to me.  Ideas anyone ?
> 
> Obviously it can be tricky for a maintainer to get right as they can't
> necessarily try all (any!) of the possibilities but it should be aspired-to.
> On the other hand, in my experience build-deps are sometimes
> unecessaily-narrowed and require new versions of things for no particular
> reason I can determine. I suspect the shlibdeps automation contributes to
> this?

Hm, the shlibdeps automation should not have an influence on
build-deps, which belong to *source* packages only.

One thing I see about this, however, is that sometimes a rebuild with
more recent libs is required to get rid of some bug.  And since
there's no guaranty that a buildd has all latest versions (see
http://people.debian.org/~dirson/buildinfo/ for a demo), I (and
probably others) tend to add versionned builddeps as >=, whereas it
should probably be an unversionned build-dep, together with a
version range in build-conflicts.

There may also be the case where one cannot exactly determine from
changelogs (debian _and_ upstream) what version of a builddep is
needed, and make a safe bet.

Regards,
-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
Debian-related: <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
Pro:<[EMAIL PROTECTED]> |  Freedom, Power, Stability, Gratuity
 http://ydirson.free.fr/| Check 

Re: perl 5.8.2-2 & mips buildd

[Colin Watson]

On Wed, Nov 19, 2003 at 06:03:39PM +0100, Karsten Merker wrote:
> On Wed, Nov 19, 2003 at 02:58:16PM +, Colin Watson wrote:
> > On Wed, Nov 19, 2003 at 11:05:49AM +0100, Domenico Andreoli wrote:
> > > i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd.
> > > 
> > > why it is in this state? it blocks the build of a lot of software.
> > 
> > I'm told that getting it past the test suite requires a newer kernel,
> > which our mips buildds don't currently have installed.
> 
> Yes, at least on mipsel it needs a newer kernel. On mips there was an
> additional problem with glibc, for which a patch was in the works but
> I currently do not know whether it is already in the current unstable
> glibc. Thiemo?

Should be:

glibc (2.3.2.ds1-8) unstable; urgency=low

  [...]
- Fix msqid_ds on MIPS.  Dpatch from Guido Guenther, patch by
  Thiemo Seufer (Closes: #215273, #200215, #217593).
  [...]

 -- Daniel Jacobowitz <[EMAIL PROTECTED]>  Tue, 28 Oct 2003 18:29:09 -0500

-- 
Colin Watson  [EMAIL PROTECTED]

Re: First pass all buildds before entering unstable

[Goswin von Brederlow]

Andreas Tille <[EMAIL PROTECTED]> writes:

> On Wed, 19 Nov 2003, Goswin von Brederlow wrote:
> 
> > You are ignoring all the packages that don't build and never have been
> > build for some architecture. Mainly that happens if some
> > build-depends, like the compiler needed, wasn't yet ported.

It gets fetches, unpaked and then checkbuilddepends find problems. and
puts it in Dep_wait.

> But this is no FTBFS bug than.  I just want to keep packages which will
> have FTBFS bugs which can be automatically detected out of the door.
> Currently we have more than 100 FTBFS bugs.  It is hard to say which
> of them could be detected at upload time.  But if there is an
> automatic method to sort out packages even before they enter unstable
> we should do so to stop their influence to other dependant packages.
> 
> > There is a reason testing script only require archs that did
> > previously build.
> Well, but this is done automatically.  I do not want to change anything
> here.

You can only detect if the package is uploaded. Anything else would
need intelligend parsing of buildd logs.

Checking only archs with previously build depends screens out any of
the above cases, you should do the same in yor proposal.

MfG
Goswin

make-kpkg question

[Liberty Young]

I'm building kernels for an embedded x86 product, and I'm falling in
love with make-kpkg. My only problem is that 
make-kpkg --added-modules pcmcia-cs kernel_image modules_image 
doesn't do a depmod on the pcmcia-cs modules against the built kernel. I
assume others have not run into this problem as default debian startup
scripts do a depmod on the system...however, in an embedded product,
every second that can be spared is needed. My goal is to just have
make-kpkg build up images that can be just installed on a separate
file-system (Compact Flash in my case) without any other work..

Am i just missing something here, or is this truley just a 'feature
request' bug that should be submitted to the maintainers of make-kpkg? 

Re: First pass all buildds before entering unstable

[Goswin von Brederlow]

"Giacomo A. Catenazzi" <[EMAIL PROTECTED]> writes:

> Luca - De Whiskey's - De Vitis wrote:
> 
> > On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote:
> 
> >> - the developers (maybe requiring not only uploader) could override
> >> the waiting status in pre-unstable queue.
> 
> > I do not understand this: what do you mean?
> 
> 
> I don't like automatic system without possibility to have human overide.
> I want to be able to upload packages in unstable also if there are
> errors on some architectures, but only on very EXCEPTIONAL cases.
> 
> 
> OT: In testing happens that a packages will not uploaded in testing
> because package is "buggier", but often the it is buggier because it
> is in unstable for a long time. You could not tell (AFAIK) that a bug
> was also present in the old testing version, but passed unnoticed.

Test it and tag the bug sarge.

MfG
Goswin

Re: MIPS port backlog, autobuilder machines and some arrogance

[Matt Zimmerman]

On Mon, Nov 17, 2003 at 03:56:44PM +0100, Goswin von Brederlow wrote:

> DDs have to sign and upload a package with a backdoor.
> 
> On the buildd I can install a gcc or other tool that will silently add
> a backdoor to anything getting compiled and the buildd admin will sign
> and upload the package for me.
> 
> Much more anonymous.

The whole point of signing packages is that it is not anonymous at all, but
traceable back to the signer.  Assuming the keyholder protects his key
adequately, there is reasonable assurance that the keyholder and the signer
are the same person.

-- 
 - mdz

Re: MIPS port backlog, autobuilder machines and some arrogance

[Guido Guenther]

On Wed, Nov 19, 2003 at 06:43:00AM +0100, Ingo Juergensmann wrote:
> Perl is building fine as well now on mips, although it is marked as
> not-for-us. See
> http://m68k.bluespice.org/cgi/package_status?mips_pkg=perl&searchtype=go
This might be due to the fact that the autobuilders don't run recent
enough kernels. I offered to binary NMU perl at least two weeks ago, but
I was told that this will be taken care of soon.
Cheers,
 -- Guido


signature.asc
Description: Digital signature

Re: First pass all buildds before entering unstable

[Adam Heath]

On Wed, 19 Nov 2003, Andreas Tille wrote:

> just an idea from a completely uneducated person regarding buildd:
>
>What about if each freshly uploaded package which contains architecture any
>packages would enter kind of a staging area first and buildds grab these
>files from there.  After each buildd was able to build a package the whole
>set with all architectures enters unstable at once.
>
> This would get us rid of all those packages in unstable with "Does not build
> on ..." and several dependencies could be easier solved.  Moreover it would
> enhance the preasure on developers to care for this kind of bugs.
>
> I guess this would be not really hard to implement.

You just described one of the many features of testing.

Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Guido Guenther]

Package: wnpp
Severity: wishlist

* Package name: at76c503a-source
  Version : 0.11.beta5
* URL : Oliver Kurth 
* License : GPL
  Description : at76c503a driver source

 .
 Alternative driver for the Atmel AT76C503A based USB WLAN adapters. This driver
 is for linux kernel versions 2.4.X.
 .
 Currently, the driver has some limitations:
* no promiscous, monitor or station mode and no support for libpcap, i.e.
  it does not work with Kismet or Airsnort and it cannot act as an WLAN
  access point. This is a restriction imposed by the current firmware.
* The firmware for Intersil radios is old (Atmel doesn't update it anymore)
  and has more restrictions.

-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux bogon 2.4.23-pre5-ben0-bogon #1 Mon Nov 17 15:45:41 CET 2003 ppc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

Re: Preparation of Debian GNU/Linux 3.0r2 (II)

[Osamu Aoki]

Hi,

On Sun, Nov 16, 2003 at 11:20:21AM -0600, Steve Langasek wrote:
> On Sun, Nov 16, 2003 at 04:30:26PM +0100, Martin Schulze wrote:
> > Kenshi Muto wrote:
> > > At Tue, 11 Nov 2003 11:59:24 +0100,
> > > Martin Schulze wrote:
> > > > Preparation of Debian GNU/Linux 3.0r2
> > > > =
> 
> > > > An up-to-date version is at .
> 
> > > > I am preparing the second revision of the current stable Debian
> > > > distribution (woody) which will probably be released soon.  This
> > > > report is to allow people to comment on it and intervene whenever
> > > > this is required.
> 
> > > > If you disagree with one bit or another, please reply to this mail and
> > > > explain why these things should be handled differently.  There is
> > > > still time to reconsider.
> 
> > > Please, please wait.
> > > Before you release r2, we must solve Japanese Watanabe font problem.
> > > See 
> > > http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00142.html
> 
> > If I understood you correctly, you want me to remove these packages:
> 
> > ttf-kochi-mincho
> > ttf-kochi-mincho-naga10
> > ttf-xwatanabe-mincho
> > watanabe-vfont
> > ttf-xtt-wadalab-gothic (source ttf-xtt)
> > ttf-xtt-watanabe-mincho (source ttf-xtt)
> 
> > from the stable distribution due to license problems, right?
> 
> > That is possible.
> 
> I'm not sure there's any reason to believe that there are licensing
> problems with these fonts.
> 
> The official reply from Hitachi on this question, as posted at
> ,

This does not sound like something the real lawyer reviewed.

> seems quite unambiguous: they acknowledge that there are no laws on the
> books, in Japan or elsewhere, which give them grounds to claim that
> these fonts infringe their intellectual property rights.  Rather, they
> have referenced previous out-of-court settlements as precedent.  

I agree.  

> Unless Japanese law is created in a much different manner than it is
> in the rest of the world, the results of out-of-court settlements do
> not constitute legal precedents; they may provide insight into the
> legal counsel's assessment of their chances of winning a suit, but
> there are other factors that contribute to such an assessment besides
> the letter of the law -- most notably, the respective depths of the
> parties' pockets.

If the party who is using HITACHI font is commercial entity, they may
likely to pay some money to avoid costly litigation if settlement
includes no actual financial impact.  It does not even say how much they
gained.   

I do not think the Japanese law is created in a much different manner.

> I don't believe that Debian should ingratiate itself to corporations who
> throw their weight around to carve out intellectual property without the
> sanction of the courts.  Unless and until Hitachi is taking legal action
> against our distributors or users in Japan, I think Debian ought to
> ignore these apparently baseless claims.

I agree.  

One question to ask is "is this useful fonts?"  If not, we have totally
different ground to remove this package based on uselessness :-)

If we ever remeve this package, reason should not be "We must do this
because HITACH said so".   That is dangerous path.

Osamu

Re: perl 5.8.2-2 & mips buildd

[Guido Guenther]

On Wed, Nov 19, 2003 at 05:42:29PM +, Colin Watson wrote:
>   [...]
> - Fix msqid_ds on MIPS.  Dpatch from Guido Guenther, patch by
>   Thiemo Seufer (Closes: #215273, #200215, #217593).
>   [...]
...additionally the current 2.4.22 mips kernel packages have the
necessary fixes. The mips buildd needs a kernel update and we have
binaries for this, mipsel kernels don't need to be updated since
msqid64_ds already has the correct padding. 
 -- Guido
 


signature.asc
Description: Digital signature

Re: Preparation of Debian GNU/Linux 3.0r2 (II)

[Martin Schulze]

Steve Langasek wrote:
> > If I understood you correctly, you want me to remove these packages:
> 
> > ttf-kochi-mincho
> > ttf-kochi-mincho-naga10
> > ttf-xwatanabe-mincho
> > watanabe-vfont
> > ttf-xtt-wadalab-gothic (source ttf-xtt)
> > ttf-xtt-watanabe-mincho (source ttf-xtt)
> 
> > from the stable distribution due to license problems, right?
> 
> > That is possible.
> 
> I'm not sure there's any reason to believe that there are licensing
> problems with these fonts.
> 
> The official reply from Hitachi on this question, as posted at
> ,
> seems quite unambiguous: they acknowledge that there are no laws on the
> books, in Japan or elsewhere, which give them grounds to claim that
> these fonts infringe their intellectual property rights.  Rather, they
> have referenced previous out-of-court settlements as precedent.  Unless
> Japanese law is created in a much different manner than it is in the
> rest of the world, the results of out-of-court settlements do not
> constitute legal precedents; they may provide insight into the legal
> counsel's assessment of their chances of winning a suit, but there are
> other factors that contribute to such an assessment besides the letter
> of the law -- most notably, the respective depths of the parties'
> pockets.
> 
> I don't believe that Debian should ingratiate itself to corporations who
> throw their weight around to carve out intellectual property without the
> sanction of the courts.  Unless and until Hitachi is taking legal action
> against our distributors or users in Japan, I think Debian ought to
> ignore these apparently baseless claims.

So...  the situation won't be changed for r2 and we can discuss this
for r3.

Regards,

Joey

-- 
Never trust an operating system you don't have source for!

Re: Bug#220301: ITP: entropy -- Emerging Network To Reduce Orwellian Potency Yield

[Henning Makholm]

Scripsit Mike Beattie <[EMAIL PROTECTED]>

> > This is a good, though perhaps too detailed, long description.

> Taken directly from the web page... (I'm lazy)

The description left me wondering whether this is just anonter
peer-to-peer filesharing network, or there is something else to
it. Either way, it should probably be mentioned in the description.
If it *is* just another p2p, then explicitly mentioning this in the
beginning of the description will save the reader the trouble of
recognising the concept in an explanation from basic principles.
If it is something else than just another p2p, the difference should
probably be stated explicitly.

-- 
Henning Makholm  "Det är alldeles för ansvarsfullt att skaffa en
flickvän. Det är ju som att skaffa en hundvalp."

Re: Debian communication and attitude [was: Re: Example of really nasty DD behavior]

[Henning Makholm]

Scripsit Jonathan Dowland <[EMAIL PROTECTED]>
> On Sun, Nov 16, 2003 at 12:44:03PM +0100, Henning Makholm wrote:

> > No, but if you don't do it, you forfeit your right to whine about
> > duplicate work when it turns out that you're not the only one who has
> > been doing work without telling anybody about it.

> So, _both_ people involved should have ITPd, early.

Only if they want whining rights. It's perfectly legitimate to package
some software as a personal learning experience, and afterwards, if
and when the packaging happens to work, decide to contribute the
package to the Debian archive.

-- 
Henning Makholm"What the hedgehog sang is not evidence."

Re: MIPS port backlog, autobuilder machines and some arrogance

[Ingo Juergensmann]

On Wed, 19 Nov 2003 19:20:09 +0100, Guido Guenther wrote:

> On Wed, Nov 19, 2003 at 06:43:00AM +0100, Ingo Juergensmann wrote:
>> Perl is building fine as well now on mips, although it is marked as
>> not-for-us. See
>> http://m68k.bluespice.org/cgi/package_status?mips_pkg=perl&searchtype=go
> This might be due to the fact that the autobuilders don't run recent
> enough kernels. I offered to binary NMU perl at least two weeks ago, but I
> was told that this will be taken care of soon. Cheers,

Well, when it would be a real kernel issue, I wonder why I was able to
successfully built perl 5.8.2-2 on 2.4.19-r4k-ip22? ;-)
But I think we have either to wait until the buildd maintainer takes care
of it or lolando finishes building perl on casals.d.o. ;-))

Ciao...
  Ingo

Re: MIPS port backlog, autobuilder machines and some arrogance

[Joerg Wendland]

Martin Michlmayr - Debian Project Leader, on 2003-11-19, 14:32, you wrote:
> * Ingo Juergensmann <[EMAIL PROTECTED]> [2003-11-16 15:40]:
> > > Yes, a fairly powerful machine has recently been donated to Debian and
> > > we're currently working out where to host it.
> > 
> > Where is it located?
> 
> In the States; not really worth shipping to Germany.  However, I'll
> see whether we can find some nice systems in Germany as well.

As I already said at LinuxTag in Karlsruhe earlier this year, my
employer is willing to host machines for Debian in Germany.  So if need be, 
I can offer rackspace and connectivity in Ulm or Frankfurth.

Joerg

-- 
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A  F318 57A3 7FBD 51CF 8417


signature.asc
Description: Digital signature

Re: Is vrms really still a Virtual Richard M. Stallman?

[Henning Makholm]

Scripsit Florian Weimer <[EMAIL PROTECTED]>
> Roland Stigge wrote:

> > debian-legalint

> I don't think this is a good idea.

Me neither. A "virtual debian-legal" would be something that analyzed
licenses:

$ debian-legalint COPYRIGHT.foo
COPYRIGHT.foo:33: warning: mentions specific protocol standard
COPYRIGHT.foo:57: talks about "best efforts" to contact upstream
COPYRIGHT.foo:64: US export control laws
$ echo $?
1
$ debian-legalint /usr/share/common-licences/GPL && echo success
success
$ debian-legalint xterm
/usr/share/doc/xterm/copyright:557: warning: obnoxious BSD advertising clause
/usr/share/doc/xterm/copyright:571: warning: obnoxious BSD advertising clause
$

While such a tool would certainly be useful, I'm afraid that it is
an AI-complete problem.

-- 
Henning Makholm  "En tapper tinsoldat. En dame i
 spagat. Du er en lykkelig mand ..."

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Oliver Kurth]

On Wed, Nov 19, 2003 at 07:04:45PM +0100, Guido Guenther wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: at76c503a-source
>   Version : 0.11.beta5
> * URL : Oliver Kurth 
> * License : GPL
>   Description : at76c503a driver source

That is my email addrss in the URL field... not the site to
download. It is really
http://at76c503a.berlios.de/
My name is correct for upstream, but you should also add Joerg Albert.

>  .
>  Alternative driver for the Atmel AT76C503A based USB WLAN adapters. This 
> driver
>  is for linux kernel versions 2.4.X.
>  .
>  Currently, the driver has some limitations:
> * no promiscous, monitor or station mode and no support for libpcap, i.e.
>   it does not work with Kismet or Airsnort and it cannot act as an WLAN
>   access point. This is a restriction imposed by the current firmware.
> * The firmware for Intersil radios is old (Atmel doesn't update it 
> anymore)
>   and has more restrictions.
> 
> -- System Information:
> Debian Release: testing/unstable
> Architecture: powerpc
> Kernel: Linux bogon 2.4.23-pre5-ben0-bogon #1 Mon Nov 17 15:45:41 CET 2003 ppc
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

I already filed an ITP for it, but I did not yet package it, for lack of time.
It would be nice if I can work as co-maintainer for this package.

There may also be issues with the firmware: the source is /not/ GPL'ed, but the
hex files from Atmel are. I am not sure if this is possible, and if it is a 
problem
for Debian to get it into main.

Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-
When sending passwords, please use my gpg key. That's what it's good for.



signature.asc
Description: Digital signature

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Oliver Kurth]

On Wed, Nov 19, 2003 at 08:06:32PM +0100, Guido Guenther wrote:
> Hi Oliver,
> On Wed, Nov 19, 2003 at 07:43:30PM +0100, Oliver Kurth wrote:
> > That is my email addrss in the URL field... not the site to
> > download. It is really
> > http://at76c503a.berlios.de/
> > My name is correct for upstream, but you should also add Joerg Albert.
> Sure. It is (and always was) correct in the package (including Joergs
> Name). I just tried to keep things short in the ITP.

Okay, but you placed an email into the URL field.

> > I already filed an ITP for it, but I did not yet package it, for lack of 
> > time.
> > It would be nice if I can work as co-maintainer for this package.
> You're very welcome!

Thanks :-)

> > There may also be issues with the firmware: the source is /not/ GPL'ed, but 
> > the
> > hex files from Atmel are. I am not sure if this is possible, and if it is a 
> > problem
> > for Debian to get it into main.
> This looks bad:
> 
> /*  license agreement.  Any un-authorized use, duplication,
>  *  transmission, distribution, or disclosure of this software is expressly
>  *  forbidden.
> 
> Do you have an agreement with Atmel to distribute the firmware? With
> this license the package can't even go into non-free.

This is okay. Atmel allows to distribute those files, I have got a message
from one of their developers, it should also be on the mailing list of the
sf driver. I will try to find it again.

The problem is just that they do not give the source for these files, and
this may be a problem for Debian. Not for Atmel.

Cc to debian-devel.

Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-
When sending passwords, please use my gpg key. That's what it's good for.



signature.asc
Description: Digital signature

vhi

[REN]

vhi 

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Guido Guenther]

On Wed, Nov 19, 2003 at 08:01:40PM +0100, Oliver Kurth wrote:
> Okay, but you placed an email into the URL field.
Cut'n'Paste erro. It's correct in the package.

> This is okay. Atmel allows to distribute those files, I have got a message
> from one of their developers, it should also be on the mailing list of the
> sf driver. I will try to find it again.
I think this won't be sufficient. We also must be allowed to modify it
to put the package into main. The current license violates at least
clause 2 and 3 of the DFSG so there's no chance to put it into main. We
might be able to put it into non-free if we're at least allowed to
redistribute the files.
Cheers,
 -- Guido


signature.asc
Description: Digital signature

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Steinar H. Gunderson]

On Wed, Nov 19, 2003 at 07:52:22PM +0100, Oliver Kurth wrote:
> There may also be issues with the firmware: the source is /not/ GPL'ed, but
> the hex files from Atmel are. I am not sure if this is possible, and if it
> is a problem for Debian to get it into main.

IANAL, but...

If the hex files are GPLed, they are probably not distributable -- hex .c
files probably do not fall into the GPL's definition of source code ("the
preferred form of making alterations"); without the driver source we do not
have the source code and such can't distribute it without violating GPL.
Check with debian-legal, perhaps?

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Oliver Kurth]

On Wed, Nov 19, 2003 at 08:26:56PM +0100, Guido Guenther wrote:
> On Wed, Nov 19, 2003 at 08:01:40PM +0100, Oliver Kurth wrote:
> > Okay, but you placed an email into the URL field.
> Cut'n'Paste erro. It's correct in the package.

Fine.

> > This is okay. Atmel allows to distribute those files, I have got a message
> > from one of their developers, it should also be on the mailing list of the
> > sf driver. I will try to find it again.
> I think this won't be sufficient. We also must be allowed to modify it
> to put the package into main. The current license violates at least
> clause 2 and 3 of the DFSG so there's no chance to put it into main. We
> might be able to put it into non-free if we're at least allowed to
> redistribute the files.

I am sure these lines in the files can be removed, by bugging the
Atmel people, or at least 'override' it with an 'It is okay' message
from them.

But you do not seem to see my point: the human readable sources of the
firmware files are _not_ open. The hex files, ie. the compiled form,
in ACSII format they say _are_ GPL'ed (despite the disclaimer in those
files, see above).


Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-
When sending passwords, please use my gpg key. That's what it's good for.



signature.asc
Description: Digital signature

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Oliver Kurth]

On Wed, Nov 19, 2003 at 08:41:32PM +0100, Steinar H. Gunderson wrote:
> On Wed, Nov 19, 2003 at 07:52:22PM +0100, Oliver Kurth wrote:
> > There may also be issues with the firmware: the source is /not/ GPL'ed, but
> > the hex files from Atmel are. I am not sure if this is possible, and if it
> > is a problem for Debian to get it into main.
> 
> IANAL, but...
> 
> If the hex files are GPLed, they are probably not distributable -- hex .c
> files probably do not fall into the GPL's definition of source code ("the
> preferred form of making alterations"); without the driver source we do not
> have the source code and such can't distribute it without violating GPL.
> Check with debian-legal, perhaps?

Maybe there can be an exception because the code is not run on the host
but on the device?

CC'ing debian-legal.

Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-
When sending passwords, please use my gpg key. That's what it's good for.



signature.asc
Description: Digital signature

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Oliver Kurth]

On Wed, Nov 19, 2003 at 08:00:48PM +, Henning Makholm wrote:
> Scripsit Oliver Kurth <[EMAIL PROTECTED]>
> 
> > But you do not seem to see my point: the human readable sources of the
> > firmware files are _not_ open. The hex files, ie. the compiled form,
> > in ACSII format they say _are_ GPL'ed (despite the disclaimer in those
> > files, see above).
> 
> What you're missing is that if one applies the GPL is applied to
> compiled code alone, it does not give any permission to distribute
> at all. GPL allows compiled code to be distributed only if it is
> accompanied with source, which these firmware files are not according
> to the GPL's own definition. So in this context GPL is equivalent to
> "no permission to distribute".
> 
> That may not be a problem for the original author (who, owning the
> copyright, can permit himself to distribute no matter what the license
> he offers to others say), but it is certainly a problem for Debian.
> 
> Sourceless GPLed code cannot be distributed even in non-free.

Sigh. So if Atmel says these files are no longer GPL'ed, but are
just freely distributable, it could at least go to non-free? Sounds
ridiculous. (Law is too complicated to me, so I stick to programming
;-) )

Is there any way to get this into main, maybe regarding the fact
that this code is not run on the host but just on the device? I think
Atmel would be open to change the license, but I do not think they will
give the source to their holy (and btw buggy) firmware.

Also CC'ing deebian-legal.

Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-
When sending passwords, please use my gpg key. That's what it's good for.



signature.asc
Description: Digital signature

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Henning Makholm]

Scripsit Oliver Kurth <[EMAIL PROTECTED]>

> But you do not seem to see my point: the human readable sources of the
> firmware files are _not_ open. The hex files, ie. the compiled form,
> in ACSII format they say _are_ GPL'ed (despite the disclaimer in those
> files, see above).

What you're missing is that if one applies the GPL is applied to
compiled code alone, it does not give any permission to distribute
at all. GPL allows compiled code to be distributed only if it is
accompanied with source, which these firmware files are not according
to the GPL's own definition. So in this context GPL is equivalent to
"no permission to distribute".

That may not be a problem for the original author (who, owning the
copyright, can permit himself to distribute no matter what the license
he offers to others say), but it is certainly a problem for Debian.

Sourceless GPLed code cannot be distributed even in non-free.

-- 
Henning Makholm  "Jeg kunne ikke undgå at bemærke at han gik på hænder."

Re: First pass all buildds before entering unstable

[Wouter Verhelst]

On Wed, Nov 19, 2003 at 03:43:31AM -0600, Luca - De Whiskey's - De Vitis wrote:
> On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote:
> > I don't think people would like it if their package stayed in incoming
> > for multiple weeks because there's a backlog on some architecture.
> 
> Neither i. This is why i would like to receive baklogs mailed to maintainer if
> autobuild fails. But i would like to receive backlogs even for pre-autobuilds,
> so that i could fix the problem, contact the upstream etc.

Uh, I think we're not speaking the same English here. When I say "this
architecture has a backlog", I mean "this architecture can't keep up
with building". You can get the logs, they're at
http://buildd.debian.org/ -- mails to package maintainers are
superfluous; non-buildd people shouldn't be bothered with such stuff, as
it isn't their problem in 99% of the cases.

> BTW, i think that the correct workflow would be:
> Move package from incoming to autobuild. If all architectures build, continue
> (as before this change); else, if not builded but is not upstrea/maintainer
> fault, continue (as before this change). Else reject the package.
> 
> > Unstable is there for that kind of things. And to detect other kinds of
> > bugs, too. If you're going to keep packages in incoming like this,
> > people won't be able to test it until it's built on all architectures.
> 
> If we stay as it is, we'll continue to get slowed by badly built
> packages/softwares.

So we slow the system down even more by holding packages for no real
reason? I fail to see how that would help.

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


signature.asc
Description: Digital signature

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Oliver Kurth]

On Wed, Nov 19, 2003 at 08:25:44PM +, Henning Makholm wrote:
> Scripsit Oliver Kurth <[EMAIL PROTECTED]>
> 
> > > If the hex files are GPLed, they are probably not distributable -- hex .c
> > > files probably do not fall into the GPL's definition of source
> > > code
> 
> > Maybe there can be an exception because the code is not run on the host
> > but on the device?
> 
> Who do you imagine making such an exception? The only one who can make
> an exception from the GPL's conditions is the copyright holder. And he
> can make whatever exceptions he likes, irrespective of where the code
> runs.

See, the copyright holder has no problem if those files are distributed.
They will not care. I can also reconfirm this by asking them. So the
problem is if this can still comply with the DFSG. So the exception
should be made by Debian.

If this is not possible, maybe one workaround could be to make the
paxkage without the firmmware files, and put them elsewhere on the
web. So like libdvdread does it.

Greetings,
Oliver

-- 
  .''`.
 : :' :Oliver Kurth [EMAIL PROTECTED]
 `. `'   Debian GNU/Linux maintainer - www.debian.org
   `-
When sending passwords, please use my gpg key. That's what it's good for.



signature.asc
Description: Digital signature

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Henning Makholm]

Scripsit Oliver Kurth <[EMAIL PROTECTED]>

> > If the hex files are GPLed, they are probably not distributable -- hex .c
> > files probably do not fall into the GPL's definition of source
> > code

> Maybe there can be an exception because the code is not run on the host
> but on the device?

Who do you imagine making such an exception? The only one who can make
an exception from the GPL's conditions is the copyright holder. And he
can make whatever exceptions he likes, irrespective of where the code
runs.

-- 
Henning Makholm   "Uh ... a picture of me with my hair pinned up
in a towel and standing in front of a grid without a
trace of makeup? *Are you out of your rock-happy mind?*"

Re: Trouble Compiling Simple Glade.

[J.H.M. Dassen (Ray)]

On Wed, Nov 19, 2003 at 15:44:54 +1100, Peter Gatt wrote:
> [EMAIL PROTECTED]:~/Projects/project1$ ./autogen.sh 
> \**Warning**: I am going to run `configure' with no arguments.
> If you wish to pass any to it, please specify them on the
> `./autogen.sh' command line.
> 
> processing .
> Running aclocal  ...
> aclocal: configure.in: 12: macro `AM_PATH_GTK' not found in library

You don't have a package installed which defines this macro. Install
libgtk2.0-dev (assuming you are using sarge or sid) or gnome-common (if you
are using a system that still has a GNOME 1.4 environment).

HTH,
Ray
-- 
A Microsoft Certified System Engineer is to information technology as a
McDonalds Certified Food Specialist is to the culinary arts.
Michael Bacarella commenting on the limited value of certification.

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Don Armstrong]

On Wed, 19 Nov 2003, Oliver Kurth wrote:
> Sigh. So if Atmel says these files are no longer GPL'ed, but are just
> freely distributable, it could at least go to non-free?

Yes.

> Sounds ridiculous. (Law is too complicated to me, so I stick to
> programming ;-) )

Thats part and parcel of the GPL... if the company doesn't include the
prefered form for modification, no one else can distribute it.

> Is there any way to get this into main, maybe regarding the fact that
> this code is not run on the host but just on the device? I think
> Atmel would be open to change the license, but I do not think they
> will give the source to their holy (and btw buggy) firmware.

Ugh. That's always annoying. Perhaps just a non-free package
containing the firmware? (assuming we get permision to freely
distribute it.) Is the firmware even necessary for the driver to work?

One wonders why they don't just open up the source to the firmware
drivers since they aren't planning on making any more updates to it.


Don Armstrong

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on
a California license plate on a VW Beetle: 'FEATURE'..."
 -- Joshua D. Wachs - Natural Intelligence, Inc.

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


signature.asc
Description: Digital signature

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Guido Guenther]

On Wed, Nov 19, 2003 at 08:36:31PM +0100, Oliver Kurth wrote:
> I am sure these lines in the files can be removed, by bugging the
> Atmel people, or at least 'override' it with an 'It is okay' message
> from them.
O.k., we can upload to non-free then.

> But you do not seem to see my point: the human readable sources of the
> firmware files are _not_ open. The hex files, ie. the compiled form,
> in ACSII format they say _are_ GPL'ed (despite the disclaimer in those
> files, see above).
I fully see your point. Without the source code to the firmware we can't
upload into main IMHO.
 -- Guido


signature.asc
Description: Digital signature

Re: Help with init replacement

[Henrique de Moraes Holschuh]

On Tue, 18 Nov 2003, Marc A. Pelletier wrote:
> Now /that/ is interresting and smart and is indeed likely the most promising 
> avenue for quick and dirty daemond integration in debian; the problem is that 
> from what I have understood, update-rc.d suffers from, by design, exactly the 
> same problem that rc.d style inits suffer from: no proper way of specifying 
> dependencies and ordering other than by asigning a cardinal and a set of 

update-rc.d needs either another interface layer, or a sister command to
register dependencies, alright.

Want to take on the job?  It must be made _very_ generic, a dependency-rc.d
(or whatever) that would allow us to plug daemond, as well as the other
dependency-based init script systems is very welcome.

Don't forget invoke-rc.d either, and if you are mucking with init itself,
also telinit.

> The *correct* way of doing all this, of course, is for packages to create 
> their own service definition file and install them (possibly through some 

Nope.  The correct way is to have a proper init system layer that can handle
static and dynamic dependencies.  I actually like the idea of service
definition files, as long as they are generic (but I quite dislike the idea
that one would probably need to run a update-dependency-rc.d or whatever
script to "transfer" what is in the files to whatever init system is in
use).

> every package that possibly wants to add themselves to the bootstrap.  In 

No. You just have to add a "compatibility" service that runs the
non-dependency-based services as the stock sysv-init rc.d does.   Oh, OF
COURSE this doesn't give you all the imediate benefits, but it won't break
the entire system.

> other words, that can't be done before some time after daemond /already/ is 
> the de facto init process.

THAT won't happen easily.  OTOH, _IF_ a proper layer is written, tested and
deployed, it is feasible to switch all the packages to something that works
with it in optimal mode for the release after sarge.

We already have at least one very good dependency-based initscript system in
Debian, so daemond is not alone in its troubles.

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