Bug#221806: ITP: mmsclient -- mms streaming media download utility

[Wesley J. Landaker]

Package: wnpp
Severity: wishlist

* Package name: mmsclient
  Version : 0.0.3
  Upstream Author : "Major MMS" (http://www.geocities.com/majormms/)
* URL : http://www.geocities.com/majormms/
* License : GPL
  Description : mms streaming media download utility

mmsclient is a simple client to download streaming audio and/or video media
from the internet using the MMS protocol. Downloaded streams can then be
replayed offline at your leisure, using any compatible media player of your
choice (not included).



NOTES:

Most media streamed with MMS is in Microsoft media format, so some non-free
codecs or players may be required to actually play back some downloaded
streams. This package, however, just understands the MMS protocol and saves
streams for later use; it's not concerned with decoding the actually media.

The upstream author posted his work at the URL given above. However, he or she
does not give an e-mail address or name either on the web site or in the
downloaded package. The source is explicitly marked as being licensed under
the GPL, so I don't believe this is a problem.

I will attempt to track down more info about the upstream author, 
but if that is not possible, I will happily take over as the upstream
maintainer as well as doing the packaging. (The package works very well as is,
but is sorely in need of UI updates!)


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux saidin 2.4.22-1-686-smp #5 SMP Sat Oct 4 14:35:05 EST 2003 i686
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8

Bug#220289: section science/geography vs. geography

[Dan Jacobson]

Regarding science/geography etc., wouldn't plain geography be better?
I see there is already a electronics, not a science/electronics.

On the other hand, perhaps remodel the categories after the Usenet
newsgroup name tree.

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

[Rick Moen]

Quoting Florian Weimer ([EMAIL PROTECTED]):

["debian-legalint":]

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

So, "dfsg-lint", maybe.

-- 
Cheers, * Contributing Editor, Linux Gazette *
Rick Moen   -*- See the Linux Gazette in its new home: -*-
[EMAIL PROTECTED]    

V i @ g r @ --> 80% D.I.S.C.O.U.N.T!! bprcu rhteb

[Debian-devel-changes]

zfxvbnpukh chvtf fdxkya kunfluntj nkwaqcvq
-- uniqlzjz -- qmajfl -- owqqksfcew --

V i @ g r @. The new medication got it's name from two words: "Vigour" and 
"Niagara". 

Yes, over 27,000,000 men worldwide use it. It hepls them to regain their s e x 
u @ l ego, fullfill sexual energy!
http://[EMAIL PROTECTED]/discounts/index.php?pid=evaph8559

It's a choice of millions, it's safe and extremely efficient! 

We offer you a Generic V i @ g r @ (the same medication as V l @ g r @, just a 
full chemical equivalent).

Our prices are really low, they are just shocking! Go and compare!

0-R-D-E-RT-0-D-A-Y: http://[EMAIL 
PROTECTED]/discounts/index.php?pid=evaph8559

Maybe this letter is sent to you occasional/ly!
If so, please un-subscri-be:
http://[EMAIL PROTECTED]/applepie.php?fkmqgoohte

mhtywodbas uxdxryu twfmichmvv mrdscabzle nccmu
zbynzfvo asmly tkbfpmtqhi xmyhukjtsr lgadeelxk

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

[Kenshi Muto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At 19 Nov 03 18:12:44 GMT,
Osamu Aoki wrote:
> On Sun, Nov 16, 2003 at 11:20:21AM -0600, Steve Langasek wrote:

I'm sorry but I missed this mail.

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

Hmm, "we don't accept what is Hitachi said". This is consensus of us?
I agree Hitachi make a mess, but it's not reason to kick them.

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

The phase of whether legal or illegal was really old issue.

LABO-123 32dot was fully-copied without license agreement from Hitachi.
Watanabe font/xfonts-intl-japanese-big(<1.2.1) is copied from LABO-123
as is.
Kochi font was copied some part from Watanabe.

IMHO Japanese font stands very weak about legal basis, but LABO-123
creates by license violation. Dead-copy should be
removed also. Hitachi/Typebank continue to sell original font.

And kochi font upstream author recommends to use new font strongly.
Do we ignore his intent also?
Goto-san has already uploaded newer packages to woody, but Martin's
list don't include them. But xfonts-intl-japanese-big is included.

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

Steve, do you want to make distributors/users in Japan to teststone?
I don't agree this idea.
Debian Project has the responsibility about distribution.

If we continue to distribute claimed fonts, we must announce our
consensus and tell how to protect our distributors/users.

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

Finally, you are not font maintainer, Osamu.

Maintainers ACCEPTED and AGREED to remove, and has already
reassigned to ftp.debian.org. All of we(especially ftp maintainer)
must do is removing such apackage from ftp.debian.org ASAP, don't we?

Thanks,
- -- 
Kenshi Muto
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iEYEARECAAYFAj+8N9EACgkQQKW+7XLQPLE1bQCeMS8yhC4wOofaK/6dSzjo+kr/
b3wAn2Tvc4NR+vVUXjkGOb3ID/H1uh9H
=a34O
-END PGP SIGNATURE-

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

[Miles Bader]

Osamu Aoki <[EMAIL PROTECTED]> writes:
> One question to ask is "is this useful fonts?"  If not, we have totally
> different ground to remove this package based on uselessness :-)

Are there any other good-looking japanese TTF fonts in debian?

I ttf-kochi-{gothic,mincho} and I remember every other japanese font
looked horrible (but maybe I missed something).

[Is ttf-kochi-gothic not a problem?]

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

Re: First pass all buildds before entering unstable

[Andrew Suffield]

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.

So your proposal is merely that we ignore non-FTBFS bugs until all the
FTBFS bugs have been fixed? That doesn't sounds like a good idea to
me. Certainly it won't speed up the process of fixing all the bugs.

I suspect that you have fallen into the trap of seeing testing as an
end in itself. It isn't; the objective is stable. Once we're in a fit
state for that, testing will sort itself out. It doesn't really matter
whether postgresql goes into testing today or in three months, it just
has to do so before the next stable release.

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


signature.asc
Description: Digital signature

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

[GOTO Masanori]

At Wed, 19 Nov 2003 19:08:24 +0100,
Martin Schulze wrote:
> Steve Langasek wrote:
> > 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 you expose our debian users to font right war.  It's not fair and
admirable attitude.

In Japan, making fonts need a lot of money.  There are font market.
Font vendor claims such infringement.  Font right is difficult
problem, but AFAIK in Japan there is a precedent that said not to
sell a pirated fonts.

In addition, font right is like "design right", not intellectual
property.

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

Please replace the newer package which have been queue in r3.  Keep in
mind that ttf-kochi-* fonts are widely used in Japan.

Regards,
-- gotom

Re: Tabs v.s. spaces

[Cameron Patrick]

(This is waaay off-topic but what the heck, I'll keep going...)

On Wed, Nov 19, 2003 at 08:08:51AM -0800, Steve Lamb wrote:
| 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.

I meant fall through in the sense that
switch(foo) {
case 1:
blah();  /* no "break;" */
case 2:
blurgh();
}
will run blurgh() if foo==1 or foo==2.

The original poster was talking about Duff's device:
http://www.lysator.liu.se/c/duffs-device.html
which relies on this (and other foul properties of C's switch/case) to
unroll a loop.

Cameron.

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

[Henning Makholm]

Scripsit Oliver Kurth <[EMAIL PROTECTED]>

> The firmware is needed. Without it, the device is completely dumb.
> But there are some devices which can store the fw permanently. Also,
> the fw is distributed on their (windows) installation CDs.

Do these CDs accompany the hardware when bought? In that case, and
assuming there are no other license problems, the driver could go
into contrib, and ask the user to supply the CD after installation.

-- 
Henning Makholm "Elses pels blev alt for trang."

Re: MIPS port backlog, autobuilder machines and some arrogance

[Matt Zimmerman]

On Thu, Nov 20, 2003 at 12:54:07AM +0100, Goswin von Brederlow wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> > 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.
> 
> Exactly my point.
> 
> As a non DD running a buildd I have much more and anonymous access to
> packages being build. I and some others are aparently trustworthy
> enough by their DD friends but not by the DAM.

The burden lies with whomever is doing the signing.  They are accepting
responsibility for what they upload, and if that involves trusting you, then
they are taking responsibility for you as well.

-- 
 - mdz

Re: MIPS port backlog, autobuilder machines and some arrogance

[Goswin von Brederlow]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

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

Exactly my point.

As a non DD running a buildd I have much more and anonymous access to
packages being build. I and some others are aparently trustworthy
enough by their DD friends but not by the DAM.

MfG
Goswin

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

[John Hasler]

Oliver Kurth writes:
> Unfortunately, in this thread it turned out we can't. Unless we convince
> Atmel to not license the files under the GPL, but just as freely
> distributable.

You don't need to get them to remove the GPL.  Just get them to add an
"It's ok to distribute these without source" statement.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Wed, Nov 19, 2003 at 10:41:05AM +0100, Yann Dirson wrote:
>...
> That could be done either by a rebuild, or, less costly, by a simple
> unpack/edit-changelog/repack.

Repacking breaks with every
  Depends: somepackage (= ${Source-Version})

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

These version numbers are currently assigned to binary only NMUs, it 
would create big confusion if they were also used for a different 
purpose.

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: sarge release

[martin f krafft]

also sprach martin f krafft <[EMAIL PROTECTED]> [2003.11.13.0800 +0100]:
> I get your point, and I will tend to the RC bug as soon as somehow
> possible. Right now I am swamped, and I simply wanted to get a feel
> whether I am already in the crowd of those upholding the release, or
> whether I am just another developer that currently has more
> important things to do than tend to Debian. Unfortunately, I do
> still have a life outside Debian (and a need for income, and the
> like). ;^> This may soon change, however...

For your information, I am now free of RC bugs (and necessary sleep
levels).

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpjmt3xzGfuq.pgp
Description: PGP signature

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

[Oliver Kurth]

On Wed, Nov 19, 2003 at 01:25:24PM -0800, Don Armstrong wrote:
> 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?

The firmware is needed. Without it, the device is completely dumb.
But there are some devices which can store the fw permanently. Also,
the fw is distributed on their (windows) installation CDs.

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

I am not sure about this. I think this is true only for the devices with
Intersil radio.

But anyway, it is annoying.

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 10:41:58PM +0100, Guido Guenther wrote:
> 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.

Unfortunately, in this thread it turned out we can't. Unless we convince
Atmel to not license the files under the GPL, but just as freely
distributable.

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

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

[Joachim Breitner]

Hi,

Am Mi, den 19.11.2003 schrieb Oliver Kurth um 21:28:
> 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.
But won't be made, and I guess it's no use discussing this way.

> 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.
Better this way: Ask Atmel whether they allow unmodified distribution
independent of the GPL (which does not work anyway), and then
a) put the whole package in non-free
or
b) put the .hex files in non-free and the rest of the driver in main, if
the driver code is any use without the .hex files.

 It looks as if everytime we can get rid of a good reason for
non-free (e.g. viable acroread alternatives), new reasons (firmware for
drivers) arise. Sigh.

nomeata
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#221744: ITP: libgnome2-perl -- Perl interface to the Gnome libraries

[Marc Brockschmidt]

Package: wnpp
Severity: wishlist

* Package name: libgnome2-perl
  Version : 0.38
  Upstream Author : Gtk2-Perl Team <[EMAIL PROTECTED]>
* URL : http://gtk2-perl.sourceforge.net/
* License : LGPL-2
  Description : Perl interface to the Gnome libraries
 The Gnome2 module allows a perl developer to use the Gnome libraries.
 Find out more about Gnome+ at http://www.gnome.org.
 .
 The perl bindings follow the C API very closely, and the C reference
 documentation should be considered the canonical source.

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

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

[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: 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: 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

[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: 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

[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: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

[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

[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

vhi

[REN]

vhi 

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

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: 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: 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: 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: 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: 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: 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)

[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

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

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

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]

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

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

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

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

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]

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.

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#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?

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

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

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: 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/

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

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: 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)

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

[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

[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: 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: 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: 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: 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: 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: 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

[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: 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 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: 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

[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

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

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

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

[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: 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 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

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

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

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.