date:20031110

This one time, at band camp, Eduard Bloch wrote:
The fact of the too generic package name was mentioned before within
other arguments against your linux package. IIRC you prefered not to
answer to it but refered to an URL which did not contain the answers.

'linux' is a perfect name for the package.  The tarballs contain that very
name.

 2) I use the upstream name. If you don't like it, bitch upstream.

Sorry, how much did you drink to find an answer like this one? If Linus
changes the package name (which is unlikely to happen ;)), I am sure you
would rename your ITP to follow him.

Are you implying that you make up names for the software that you package,
rather than use the name given to it by upstream?  I believe you don't.

Given that there's a possibility that Debian will include non-linux kernels
in the future.  In that case, calling the linux kernel package
'kernel-image' doesn't give a lot of room for the other kernels to live in.
Calling the package 'linux' makes it pretty clear which software it is
packaging.

-- 
[EMAIL PROTECTED]   http://people.debian.org/~jaq

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

This one time, at band camp, Eduard Bloch wrote:
You repeat this again and again and got answers from me and others to
such an ultimate argument. But did you ask yourself why Herbert does not
participiate this discussion to help you?

Why does the lack of response from Herbert prove that this package is a bad
idea?  I'm saddened that you have to revert to intimidation in place of a
technical argument.

-- 
[EMAIL PROTECTED]   http://people.debian.org/~jaq

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

This one time, at band camp, Matthew Garrett wrote:
Robert Millan wrote:

But someone claimed there are critical problems with System.map in the way
my package is upgraded, which is not the case.

If I get a new linux package after doing apt-get ugprade which replaces
the one for my running kernel, then System.map and the kernel are going
to be out of sync until I reboot. Which would be bad.

I do not expect Robert's package to make any more of an attempt to convince
you a reboot is required than any of the other kernel packages.

I quote from the postinst generated by kernel-package:

   I repeat: you have to reboot in order for the modules file to be created
   correctly. Until you reboot, it may be impossible to load some modules.
   Reboot as soon as this install is finished (Do not reboot right now,
   since you may not be able to boot back up until installation is over, but
   boot immediately after). I can not stress that too much. You need to
   reboot soon.

-- 
[EMAIL PROTECTED]   http://people.debian.org/~jaq

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

This one time, at band camp, Marcelo E. Magallon wrote:
   * A package which requires a reboot on updates
  
  Oh, now I'm suposed to fix that, too? Bitch upstream for a run-time
  updatable Linux kernel.

 ROTFL

 That's not the point, I thought that was obvious, sorry.  The point is
 how do you guarantee that this reboot is going to happen?

How do the current kernel packages guarantee this?

Why would Robert's package need to behave any differently?

However, I do think your questions make very intersting challenges for this
project.  I do not expect Robert to have all the answers for them just now,
but with some experimentation we can hope to find them.

-- 
[EMAIL PROTECTED]   http://people.debian.org/~jaq

Re: problems with dpkg, apt, perl etc. ( wait/waitpid)

2003-11-10 Thread Cristian Rauta


ii  libc62.3.2.ds1-10 GNU C Library:
Shared libraries and Timezone data

ii  perl 5.8.2-1  Larry Wall's
Practical Extraction and Report Language.

arch = i386 


[EMAIL PROTECTED]:~# uname -a
Linux CR 2.4.22 #6 Sun Nov 9 00:27:15 EET 2003 i686 GNU/Linux

latest apt-get upgrade  dist-upgrade was two days ago .

I know, maybe -devel is inappropriate list for my problems, but i don`t
know another list for that. 
I think that problem was some time ago with woody  ( see bug # 206187)

btw my debian version is sid 

On Mon, 2003-11-10 at 01:02, Daniel Jacobowitz wrote:
 On Mon, Nov 10, 2003 at 12:40:31AM +0200, Cristian Rauta wrote:
  Donno if it`s because libc6 but look at this errors :
  
  Hit http://ftp.tiscali.de sid/non-free Release
  Err http://ftp.tiscali.de sid/main Sources
Waited, for gzip but it wasn't there
  Err http://ftp.tiscali.de sid/contrib Sources
Waited, for gzip but it wasn't there
  Err http://ftp.tiscali.de sid/non-free Sources
Waited, for gzip but it wasn't there
  [...]
  
  [EMAIL PROTECTED]:/var/cache/apt/archives# dpkg -i perl-doc_5.8.2-1_all.deb
  dpkg-deb: wait for gzip -dc failed: No child processes
  dpkg: error processing perl-doc_5.8.2-1_all.deb (--install):
   subprocess dpkg-deb --control returned error exit status 2
  Errors were encountered while processing:
   perl-doc_5.8.2-1_all.deb
  [EMAIL PROTECTED]:/var/cache/apt/archives#
  [...]
  [EMAIL PROTECTED]:/var/cache/apt/archives# perl -w -e 
  Can't ignore signal CHLD, forcing to default.
  [EMAIL PROTECTED]:/var/cache/apt/archives#
  
  Because of that i can`t update,upgrade and install packages.
  If anyone knows how to fix that .. please let me know how.
  Thanx 
 
 This is inappropriate for -devel.
 
 It's also like a quarter of a bug report.  What versions of libc, perl,
 etc are installed?  What architecture?  What kernel version?  What have
 you changed lately?

Re: problems with dpkg, apt, perl etc. ( wait/waitpid)

2003-11-10 Thread Mark Brown

On Mon, Nov 10, 2003 at 09:56:04AM +0200, Cristian Rauta wrote:

 I know, maybe -devel is inappropriate list for my problems, but i don`t
 know another list for that. 

debian-user might've been a better bet.

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

Re: Searching for mails in BTS by message-ID

2003-11-10 Thread Martin Schulze

Andreas Metzler wrote:
 Hello,
 Does anybody know a way to find a mail sent to the BTS with a specific
 Message-ID? Neither google nor lists.d.o. nor gmane.org archive
 debian-bugs-(rc|dist).

See ~debian/lists/debian-bugs-dist/ on master.

Regards,

Joey

-- 
If nothing changes, everything will remain the same.  -- Barne's Law

Please always Cc to me when replying to me on the lists.

Re: [OT] Re: Bug#219293: ITP: songwrite -- a tablatures editor and player

2003-11-10 Thread Roberto Suarez Soto

On Nov/10, Branden Robinson wrote:

 I've ever met a guitar player who wouldn't know what I meant if I said,
 hey, can you show me how to finger an F#7sus4 in the second position?

I think you've known too few guitar players, or too seasoned ones.
Most people that play guitar (not pro guitar players) that I know would
hesitate when confronted to a F#7sus4. Though maybe you're a Jazz or Fusion
player and use that chord extensively ;-)

 Well, okay, the ones who don't know any music theory wouldn't know what
 I meant, but fuck 'em -- all they know is pentatonic minor anyway.  :)

Hey, what's wrong with that? It's not what you know, but how you use
it :-P ;-)

-- 
Roberto Suarez Soto Alfa21 Outsourcing
[EMAIL PROTECTED]http://www.alfa21.com

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Andreas Metzler

Robert Millan [EMAIL PROTECTED] wrote:
 On Sun, Nov 09, 2003 at 02:50:33PM +0100, Andreas Metzler wrote:

  Sure. My users are those who like the advantages described in:

  http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html
 [...]

 This *IMHO* does not include a reason good enough to justify a 30MB
 source-package + resulting binary packages.

 Why not?

There is no equivalent amount of added value to the bound resources.
[EMAIL PROTECTED] SCNR.
 cu andreas

Re: Searching for mails in BTS by message-ID

2003-11-10 Thread Andreas Metzler

Martin Schulze [EMAIL PROTECTED] wrote:
 Andreas Metzler wrote:
 Does anybody know a way to find a mail sent to the BTS with a specific
 Message-ID? Neither google nor lists.d.o. nor gmane.org archive
 debian-bugs-(rc|dist).

 See ~debian/lists/debian-bugs-dist/ on master.

Thanks, that worked.
 cu andreas

Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86

2003-11-10 Thread Mattia Dongili

On Sun, Nov 09, 2003 at 10:58:17AM -0800, Keegan Quinn wrote:
 (As if this ITP hasn't been nit-picked quite enough...)
 
 On Sun, Nov 09, 2003 at 03:12:19PM +0100, Mattia Dongili wrote:
Description : Synaptics TouchPad driver for XFree86
  
  An input driver for the XFree86 X server to enable advanced features
  of the Synaptics Touchpad including:
  ...
 
 H...  In the first instance you use the capitalization TouchPad,
 in the second Touchpad.  Maybe they should be consistent?

sorry, a typo. I meant *TouchPad*

ciao
-- 
mattia
:wq!


pgpbiFYvMe1v0.pgp
Description: PGP signature

Re: libGL.so.1: cannot handle TLS data (nvidia-glx deb issue?)

2003-11-10 Thread Frederik Dannemare

Juergen Kreileder wrote:
Frederik Dannemare [EMAIL PROTECTED] writes:
Frederik Dannemare wrote:
[cut]
Read the (recently closed) bug reports for nvidia-glx
[cut]
and install the current version of that package.
,[ /usr/share/doc/nvidia-glx/changelog.Debian.gz ]
| nvidia-graphics-drivers (1.0.4496-8) unstable; urgency=low
-8 is in fact the version I have installed, and it seems that I'm not the only 
one having problems with this one: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219646

| 
|   * Correctly install tls libglx. 
| 
I'm not sure it really does. Not here at least.
B/R,
Frederik Dannemare

Bug#219942: ITP: zope-textindexng2 -- Fulltext index for Zope

2003-11-10 Thread Andreas Tille

Package: wnpp
Severity: wishlist

* Package name: zope-textindexng2
  Version : 2.0.2
  Upstream Author : Andreas Jung [EMAIL PROTECTED]
* URL : http://zope.org/Members/ajung/TextIndexNG/
* License : Several free llicenses (see below)
  Description : Fulltext index for Zope

 This is the new fulltext index for Zope and is the most feature-complete
 solution for fulltext indexing under Zope.

 Supported Formats: HTML, PDF, Postscript, WinWord, PowerPoint, OpenOffice

This package was debianized by Andreas Tille [EMAIL PROTECTED]  on
Tue,  28 Oct 2003 10:43:55 +0200

Homepage:
   http://zope.org/Members/ajung/TextIndexNG/
   
Download URL:

Upstream Author: 
   Copyright (c) 2003 Andreas Jung [EMAIL PROTECTED]

License: 
 
TextIndexNG is designed and written by Andreas Jung and published under the
Zope Public License ZPL (http://www.zope.org/Resources/ZPL)
(See below in this file.)

The following parts of TextIndexNG are not covered by the ZPL:

  - The PyStemmer and PySimilarity extensions for Python are (C) by Andreas
Jung and published under the MIT Public License.
(See below in this file.)

  - Some converters are based on code from the DocumentLibrary published under
the Kaivo license (Thanks to Casey Duncan).
(See below in this file.)

  - The QueryParser is (C) by Sidnei da Silva and published under the GPL.
(See /usr/share/common-licenses/GPL.)

  - The Snowball stemmer sources are (C) Dr. Martin Porter and published under
the MIT Public License.
(See below in this file.)

  - Matt Hamilton contributed code for compressed lists that uses header files
(C) by Neil Sherman and Alistair Moffat published under the GPL.
(See /usr/share/common-licenses/GPL.)

  - TXNGSplitter uses parts of the libdict packages. The package is published
under the Berkely License.  Copyright (C) 2001 Farooq Mela. All rights 
reserved.
(See below in this file.)

  - converters/stripogramm is Copyright (c) 2001 Chris Withers
(See below in this file.)

-

The MIT License

Copyright (c) 2001 Andreas Jung 

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the Software), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.


-

The hash* and dict* files are taken from the ''libdict'' package and
are distributed under the following license:


Copyright (C) 2001 Farooq Mela. All rights reserved.

This software is distributed under the so-called ``Berkeley License.''

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
   must display the following acknowledgement:
This product is developed by Farooq Mela.
4. The name Farooq Mela may not be used to endorse or promote products derived
   from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY Farooq Mela ``AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
EVENT SHALL Farooq Mela BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Sun, Nov 09, 2003 at 09:27:04PM +0100, martin f krafft wrote:
 also sprach Robert Millan [EMAIL PROTECTED] [2003.11.09.2118 +0100]:
  Anyway, discussing this is not useful anymore. I just said I'll
  provide it in the package.
 
 That won't do. Read Matthew's post carefully.

I read all posts (or at least, attempt to). So please don't send redundant
messages, they add more confusion.

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 06:59:44PM +1100, Jamie Wilkinson wrote:
 
 I do not expect Robert's package to make any more of an attempt to convince
 you a reboot is required than any of the other kernel packages.
 
 I quote from the postinst generated by kernel-package:
 
I repeat: you have to reboot in order for the modules file to be created
correctly. Until you reboot, it may be impossible to load some modules.
Reboot as soon as this install is finished (Do not reboot right now,
since you may not be able to boot back up until installation is over, but
boot immediately after). I can not stress that too much. You need to
reboot soon.

Thanks Jamie. So all these people are bugging me with a problem the current
packages _already_ have?

You know, I can copy+paste. Will someone be surprised to see the exact same
message in my package?

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86

2003-11-10 Thread Mattia Dongili

On Mon, Nov 10, 2003 at 03:59:48PM +1100, Daniel Stone wrote:
 On Sun, Nov 09, 2003 at 11:56:04PM -0500, Branden Robinson wrote:
  On Sun, Nov 09, 2003 at 10:03:14AM +1100, Daniel Stone wrote:
[...]
   I was thinking about xfree86-driver-synaptics, or
   xfree86-driver-input-synaptics, but the last one is too unnecessarily
   longwinded. (I was going to package this as an XSF project, post-exams).
  
  I thought about the latter as well.  It's not too long-winded if we
  expect having input and video modules with identical names.
 
 I can't particularly see this at the moment, but I'm sure something will
 rise up and prove us wrong.

I'd stick for the short version (I agree with Daniel though).

But, isn't this the first external module being packaged? If so we
should take a decision about their naming scheme.

  Is the XFree86 driver namespace subdivided in practice (i.e., in a
  name-resolution sense), or merely cosmetically via directory layout?
 
 I don't believe it's subdivided in a name-resolution sense, but I could
 be wrong.

looking at the Module section of my XF86Config-4 I can see a big mess of
drivers without an indication of being font/input/dri/...
So I suppose the directory layout is cosmetic and no real namespace is
present.

ciao
-- 
mattia
:wq!


pgp6pK5YJmOUG.pgp
Description: PGP signature

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 09:52:34AM +0100, Andreas Metzler wrote:
 
  This *IMHO* does not include a reason good enough to justify a 30MB
  source-package + resulting binary packages.
 
  Why not?
 
 There is no equivalent amount of added value to the bound resources.

Yes, there is.

 [EMAIL PROTECTED] SCNR.

I respond to every mail in this thread. You don't need to paste a reference.

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Sun, Nov 09, 2003 at 10:43:49PM +0100, Eduard Bloch wrote:
  1) You said before you were concerned about my package occupiing the package
  namespace in the archive. The fact that you don't like the name of my 
  package
  proves your previous argument was intentionaly bogus.
 
 The fact of the too generic package name was mentioned before within
 other arguments against your linux package.

How many software programs called linux are around?

 IIRC you prefered not to
 answer to it but refered to an URL which did not contain the answers.

I don't recall seeing this question before. So unless you provide a link to
that, you're liing.

  2) I use the upstream name. If you don't like it, bitch upstream.
 
 Sorry, how much did you drink to find an answer like this one? If Linus
 changes the package name (which is unlikely to happen ;)), I am sure you
 would rename your ITP to follow him.

Untill Linus changes the package name, this issue is not my problem.

  The FTP masters will have to dig through the smoke curtain you and others
  attempted to rise. Fortunately, there are two reasons why this shouldn't be
  a problem:
  
  - The current Linux kernel maintainer welcomes my work:

  http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00452.html
 
 You repeat this again and again and got answers from me and others to
 such an ultimate argument.

I don't recall seeing such ultimate argument before. So unless you provide
a link to that, you're liing again.

 But did you ask yourself why Herbert does not
 participiate this discussion to help you?

I guess Herbert has better things to do than wasting his time in this stupid
flame. Btw, stupid flame is your choice of words, not mine:

http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00415.html

  - Noone managed to beat the advantages I listed before:

  http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html
 
 And after removing bogus and irrelevant ones from that list, it became
 empty.

Indeed.

 Why cannot you invent something new to convince us?

As I said before I'm unwilling to understand your sarcasm.

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Matthew Garrett

Jamie Wilkinson wrote:

I do not expect Robert's package to make any more of an attempt to convince
you a reboot is required than any of the other kernel packages.

The current kernel packages include the version number in the package
name, whereas Robert seems to be suggesting that his package would
maintain the same name. As a result, if I upgrade a stable box, I'm
going to need to reboot the system, whereas currently I can upgrade
everything other than the kernel and then deal with the kernel at my
leisure. I think this is a regression.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread martin f krafft

also sprach Robert Millan [EMAIL PROTECTED] [2003.11.10.1204 +0100]:
  That won't do. Read Matthew's post carefully.
 
 I read all posts (or at least, attempt to). So please don't send redundant
 messages, they add more confusion.

... says the one who's ignoring Mail-Followup-To and explicit
requests:

  Please do not CC me when replying to lists; I read them!

talk about redundancy... ha!

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


pgplWJ4rLabub.pgp
Description: PGP signature

Bug#219959: ITP: mozilla-locale-eu -- Mozilla Basque Language Package

2003-11-10 Thread Jordi Mallach

Package: wnpp
Severity: wishlist

* Package name: mozilla-locale-eu
  Version : 1.5
  Upstream Author : Librezale.org
* URL : http://www.librezale.org/mozilla/
* License : (GPL, LGPL, MPL)
  Description : Mozilla Basque Language Package

 Basque menu/message resource package for Mozilla.
 .
 Homepage: http://www.librezale.org/mozilla/

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux nubol 2.6.0-test7 #1 Tue Oct 14 14:38:50 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86

2003-11-10 Thread Andrew Lau

On Thu, Nov 06, 2003 at 08:04:21PM +0100, Mattia Dongili wrote:
 I'll package it. I'm a bit unsure about XFree configuration after
 installation. I'll simply provide a sample configuration and big fat
 README.Debian

Hey everyone,

Yeah, the configuration is a mess. I recently tried out 0.12.0 [1] on my
IBM ThinkPad R40 which comes with an UltraNav [2]. UltraNav is IBM's
marketing lingo for 3 button trackpoint + 2 button touchpad in the
same laptop.

[1] http://w1.894.telia.com/~u89404340/touchpad/ 
[2] http://www.pc.ibm.com/ww/healthycomputing/trkpnta.html

Both devices will respond if I use the GlidePointPS/2 XFree86 driver as
my CorePointer, but the middle button of the trackpoint is disabled
while the touchpad is dumb (i.e. all presses are Mouse1).

However, when I tried out the synaptics driver as my CorePointer, it
turned on all my touchpad's funky features at the cost of disabling all
my trackpoint's buttons. It was just plain bizarre. I can't remember if
the trackpoint continued to point at the time though. So I'll have to
try.

But anyway Mattia, if you're going to package it, please do it right and
try and it get the xserver-xfree86's debconf scripts to do all the
configuration, otherwise it'll cause the user too much grief. Best of
luck.

Cheers,
Andrew Netsnipe Lau

-- 
---
  Andrew Netsnipe LauComputer Sci. UNSW  Debian GNU/Linux
 netsnipe(+)users.sf.net\0alau(+)cse.unsw.edu.au\0
 GnuPG 1024D/2E8B68BD:  0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD
 -
  Nobody expects the Debian Inquisition!
 Our two weapons are fear and surprise...and ruthless efficiency!
---


signature.asc
Description: Digital signature

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Marcelo E. Magallon

  How do the current kernel packages guarantee this?
  
  Why would Robert's package need to behave any differently?

 The current kernel packages don't make the old stuff just dissappear,
 so it's less of an issue in that case.  In fact, the only bad
 situation with the current kernel packages is when you update between
 package releases of the same kernel version, and the current kernel
 packages make plenty of noise in that situation.

-- 
Marcelo

Re: debian-installer beta 1

2003-11-10 Thread Sven Luther

On Sun, Nov 09, 2003 at 07:02:33PM -0500, Joey Hess wrote:
 We are pleased to announce the first beta release of debian-installer, the
 new installation system for sarge. This first beta is for the following
 architectures only:
 
   * i386.
   * PowerPC, with support for the subarchitectures Apple Newworld, Pegasus
 ^^^
It's Pegasos, the pegasus is a USB-ethernet adapter, or maybe a
console clone in eastern eurpoean countries.

 PPC and IBM RS/6000 (PrEP, CHREP).

That said, i had the understanding that only Apple Newworld was going to
be supported with the beta1 ? Or did you finally change minds and accept
my kernel upload ?


Friendly,

Sven Luther

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Matthew Garrett

Robert Millan wrote:
On Sun, Nov 09, 2003 at 10:43:49PM +0100, Eduard Bloch wrote:
 The fact of the too generic package name was mentioned before within
 other arguments against your linux package.

How many software programs called linux are around?

When people refer to linux, they often mean the entire OS. How about
calling it linux-kernel? Upstram seems happy with this, given that the
mailing list for its discussion is linux-kernel rather than linux,
and it would remove any ambiguity. It would also allow for consistency
with other kernels - netbsd doesn't necessarily refer to the kernel,
but netbsd-kernel is unambigous. 

 IIRC you prefered not to
 answer to it but refered to an URL which did not contain the answers.

I don't recall seeing this question before. So unless you provide a link to
that, you're liing.

Technically, no - even if he doesn't provide a link, it may be true. And
even if the question wasn't asked before, he may be mistaken. Accusing
people of deliberately telling falsehoods (and note the IIRC - for
this to be a lie, Eduard would have to have known absolutely that what
he was saying was not true) makes you look like a fanatic.

I don't recall seeing such ultimate argument before. So unless you provide
a link to that, you're liing again.

Cough.

 And after removing bogus and irrelevant ones from that list, it became
 empty.

Indeed.

You may want to actually read that. He's referring to the advantages
list.

 Why cannot you invent something new to convince us?

As I said before I'm unwilling to understand your sarcasm.

But at the time you were referring to my sarcasm, which confuses me a
bit.
-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Changes in t1lib.

2003-11-10 Thread Hamish Moffatt

On Mon, Nov 10, 2003 at 12:04:18AM -0500, Branden Robinson wrote:
 On Sat, Nov 08, 2003 at 10:57:32PM +0100, Artur R. Czechowski wrote:
  These arguments are good, but...
  
  All packages which use this library depend on t1lib1. Of course, I can
  provide dummy t1lib1 package which depends on libt1-1 but I do not like
  this idea.
 
 I strongly urge you to overcome that dislike.  IMO a package should
 never disappear across a Debian release unless the functionality has
 gone missing.  

Agreed, so why rename it at all? (ie why t1lib - libt1 if the dummy
package is always going to be required anyway).

 What's wrong with libt1-dev?  Do you expect to have to support
 development against multiple versions of t1lib?

Apparently so.

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

Re: Changes in t1lib.

2003-11-10 Thread Hamish Moffatt

On Sun, Nov 09, 2003 at 09:20:36PM +0100, Artur R. Czechowski wrote:
 On Sun, Nov 09, 2003 at 12:22:14PM +1100, Hamish Moffatt wrote:
  On Tue, Nov 04, 2003 at 11:09:27PM +0100, Artur R. Czechowski wrote:
   I changed the naming scheme. All binary packages contain version in its
   name, i.e.: t1lib-dev is now named t1lib1-dev. Of course old packages are
  Hmm. Why?
 Incompatibility in API. Software which want to use t1lib 5.x needs changes
 in source code.
 
  It seems quite common to provide libxyz-dev which always matches the
  latest libxyzN package, even when libxyz1 becomes libxyz2 etc.
 So, for now there is t1lib-dev which depends on t1lib1-dev. Any chages after
 sarge release (didn't I write it earlier?).
 
  It also means that if package X doesn't require any particular version,
 You now know this is a false assumption.

OK, that makes sense. Thanks.

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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 12:55:21PM +0100, martin f krafft wrote:
 also sprach Robert Millan [EMAIL PROTECTED] [2003.11.10.1204 +0100]:
   That won't do. Read Matthew's post carefully.
  
  I read all posts (or at least, attempt to). So please don't send redundant
  messages, they add more confusion.
 
 ... says the one who's ignoring Mail-Followup-To and explicit
 requests:
 
   Please do not CC me when replying to lists; I read them!
 
 talk about redundancy... ha!

I apologise. But note my redundancy was unintentional while yours was explicit.

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Sun, Nov 09, 2003 at 08:33:00PM +, Matthew Garrett wrote:
 Robert Millan wrote:
 
 How bad? I'm happily running the Linux kernel without System.map right now.
 
 klogd will be unable to look up symbols, and ps and top need it for
 wchan to be displayable.

I'm so scared. wchan won't be displayable!

 That doesn't deal with the problem I described. How do you prevent
 System.map and the running kernel getting out of sync when you upload a
 new version of the linux package? 

I don't see why should I address that. But don't worry, if it turns out
there's a reason to, I'm pretty capable of solving it.

You're mixing trivial maintainer issues with this ITP. It's very pity of you
if you're doing it on purpose.

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Sun, Nov 09, 2003 at 07:47:37PM -0600, Marcelo E. Magallon wrote:
 On Sun, Nov 09, 2003 at 02:40:11PM +0100, Robert Millan wrote:
 
   The packaging method is the whole point. And indeed, some people like
   the ability to do standard things like apt-get source foo and get
   foo's sources.
 
  Since you like playing word games... what else do you get when you do
  apt-get source kernel-image-2.4.22-1-k7 if not
  kernel-image-2.4.22-1-k7's source package?
 
  Do you want the Linux Kernel sources with all the patches as used by
  kernel-image-* _already_ applied and available in a well known
  location?  apt-get install kernel-tree-x.y.z.

apt-get source kernel-image-* doesn't bring me the real source. Instead, if
I want the real source I must be root and install a binary package. Do you
deny that this is confusing?

 an alternative.  Having a gazillion variations of a theme might be
 a good software developing methodology, but I've got news for you:
 Debian is a distribution.
   
   You just messed up. Debian is The Universal Operating System. At
   least, we claim that in the website title.
 
  Look, if you want to waste time, waste _yours_.  OTOH, if you want to
  take part in the discussion, do bother to address the issues you are
  being presented with.

I'd really LOVE to. But this is my discussion. If I don't take part in it,
who will respond to all these bogus arguments some people enjoy sending in?

Rather, this is you and the other trolls who are wasting my time.

  If all you are going to do is nitpick on
  wording, piss off.

You said: I've got news for you: Debian is a distribution.

Who started the nitpick wording?

  Again, your complain is that there are too many kernel-foo packages,

Don't put words in my mouth. I said the current package set is confusing,
which it is.

  but you are adding more.  How does that improve on the problem you
  perceive?

In what way the presence of 136 separate kernel-* packages affects the
confusability of my pair of linux-* ones?

  I was addressing this:
 
   - Easy understanding of the package. Developers looking at the
 package will find every piece in the place Debian packages
 normaly put it.  The binaries are in .deb, pristine upstream
 sources are in .orig.tar.gz, the debian/ dir is in .diff.gz
 
 I could finaly work out where everything is, but the current
 situation is confusing. [...]
 
  and keeping in mind that you have a problem with the current way the
  kernel is packaged, I have to conclude that you think that using CDBS
  is a better choice, because if it isn't you wouldn't be using it in the
  first place.

No, I could do the same with plain dh-make'ed templates. It'd have the
advantage that I wouldn't have to discuss silly arguments with you.

But your arguments are not that relevant, so I'll stick with CDBS.

  Futhermore, you argue that the packaging is confusing and
  non-standard.  I take you think that CDBS is somehow standard and easy
  to understand.  It's neither.  After apt-get source foo, foo-x.y still
  _does not_ contain the sources used to build the package.  You have to
  take extra steps to do that.

dpkg-buildpackage

  And since there are a couple of these
  hacks floating around, how to get the unpacked patched source is
  non-obvious.

It's as easy as in the rest of packages in Debian, no more, no less: Read
debian/rules.

  Now do go ahead and do tell me that the packaging is easy to
  understand.  Define easy then, because with the information I have
  at hand the only reasonable interpretation is easy for Robert Millan
  to understand.

It's easy for people who are already used to Debian de-facto standards.
Since I am and you're not [1], that makes a difference. Therefore don't
expect to understand it.

[1] Your reasoning shows either you're not used to them, or you're plainly
trolling. I'll assume the first at your convenience.

  Debian provides a _distribution_.  In this context less is more.  We
  have a gazillion emacs (to pick a random example) packages because
  there are _users_ for these packages who _do_ require the different
  versions.  This is not about survival of the fittest, this is about
  satisfying users' needs.

Some people publicly said in this thread they like the package. Herbert said
he likes it at least as an experiment. I got other private mails from
well-known developers who like my proposal and pity your trolling attempts.

But the real results are shown through Popularity Contest [1] when my package
reaches unstable. So keep your arguments on this for later.

[1] http://people.debian.org/~apenwarr//popcon/

  My objection is based on the fact that you are packaging something that
  we _already_ provide,

I responded to this before. We don't provide the Linux kernel packaged as a
standard Debian package.

  without adding any significant value for users
  and along the way creating more problems (you still haven't addressed

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 11:38:38AM +, Matthew Garrett wrote:
 Jamie Wilkinson wrote:
 
 I do not expect Robert's package to make any more of an attempt to convince
 you a reboot is required than any of the other kernel packages.
 
 The current kernel packages include the version number in the package
 name, whereas Robert seems to be suggesting that his package would
 maintain the same name. As a result, if I upgrade a stable box, I'm
 going to need to reboot the system, whereas currently I can upgrade
 everything other than the kernel and then deal with the kernel at my
 leisure. I think this is a regression.

In some way, it is. The point Jamie holds is that such regression is not
really relevant in comparison with the problem the current packages have
of updating a package with the same version.

And even if it was, I claimed my packages has some advantages, but didn't
claim it doesn't have any disadvantages.

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Trying to understand updating orbit2 makes 79 packages unintallable ...

2003-11-10 Thread Sebastian Rittau

On Thu, Nov 06, 2003 at 10:24:05PM -0800, Joe Buck wrote:

 I'm trying to figure out the reason why orbit2 is blocked from testing,

I can only guess, but I think it is because of orbit2's conflict with
liblinc-dev. I would really like to see ORBit2 2.8 to go into testing,
since I plan to remove the liblinc-dev package. But on the other hand I
do not want to remove the liblinc-dev package as long as ORBit2 2.8 is
not testing, because doing so would make stuff unbuildable in testing
alone. (You need either ORBit2 2.8 or Linc and ORBit2 2.6 to compile
stuff for ORBit.) It's a hen-and-egg problem.

 - Sebastian

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Matthew Garrett

Robert Millan wrote:
On Sun, Nov 09, 2003 at 08:33:00PM +, Matthew Garrett wrote:
 klogd will be unable to look up symbols, and ps and top need it for
 wchan to be displayable.

I'm so scared. wchan won't be displayable!

What were you saying about sarcasm? The fact remains that it's a bug,
and it's a bug that you should already have thought of. Put simply, if
this is the level of research you've done, I don't think you're suitable
for packaging something as important as the kernel. This doesn't mean
that you shouldn't do it (as an academic exercise it'd be a wonderful
learning experience, and lessons learned may be well applied else where)
- I just don't think it should go anywhere near the archive.

 That doesn't deal with the problem I described. How do you prevent
 System.map and the running kernel getting out of sync when you upload a
 new version of the linux package? 

I don't see why should I address that. But don't worry, if it turns out
there's a reason to, I'm pretty capable of solving it.

Because it's a bug, and if you're going to maintain your packages then
you need to address bugs.

You're mixing trivial maintainer issues with this ITP. It's very pity of you
if you're doing it on purpose.

No, I'm saying that you're proposing to package a major piece of
infrastructure and give it a name that may attract users into installing
it, and the amount of thought and consideration that you seem to have
put in is insufficiently large for me to consider that it'll do anything
other than convince people that Debian kernel packagers are on crack.
Which would, again, be bad.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 06:44:55AM -0600, Marcelo E. Magallon wrote:
   How do the current kernel packages guarantee this?
   
   Why would Robert's package need to behave any differently?
 
  The current kernel packages don't make the old stuff just dissappear,
  so it's less of an issue in that case.  In fact, the only bad
  situation with the current kernel packages is when you update between
  package releases of the same kernel version, and the current kernel
  packages make plenty of noise in that situation.

In what way is updating between releases worse than updating within the
same release?

If there is such, do you pretend it's worse enough to justify not attempting
to provide my package at all? How is that?

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 12:42:48PM +, Matthew Garrett wrote:
 
 How many software programs called linux are around?
 
 When people refer to linux, they often mean the entire OS.

Yes. And when I refer to something, I just mean something.

  IIRC you prefered not to
  answer to it but refered to an URL which did not contain the answers.
 
 I don't recall seeing this question before. So unless you provide a link to
 that, you're liing.
 
 Technically, no - even if he doesn't provide a link, it may be true. And
 even if the question wasn't asked before, he may be mistaken. Accusing
 people of deliberately telling falsehoods (and note the IIRC - for
 this to be a lie, Eduard would have to have known absolutely that what
 he was saying was not true) makes you look like a fanatic.

That's right. I withdraw my accusation, although I still suspect that's the
case: I'm still waiting for Eduard's link.

 I don't recall seeing such ultimate argument before. So unless you provide
 a link to that, you're liing again.
 
 Cough.

This one is different. Eduard claimed there's an ultimate argument, which
there isn't. Now instead of coughing, bring me a link to such
ultimate argument.

  And after removing bogus and irrelevant ones from that list, it became
  empty.
 
 Indeed.
 
 You may want to actually read that. He's referring to the advantages
 list.

 - Noone managed to beat the advantages I listed before:
   
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html

And after removing bogus and irrelevant ones from that list, it became
empty. Why cannot you invent something new to convince us?

Uhm.. that's right. At first glance it sounded more like sarcasm.

Well, my answer is simple: I yet have to see a justification why these are
bogus and irrelevant.

  Why cannot you invent something new to convince us?
 
 As I said before I'm unwilling to understand your sarcasm.
 
 But at the time you were referring to my sarcasm, which confuses me a
 bit.

I was referring to Eduard's sarcasm. But it could well be a confusion of mine.

-- 
Robert Millan

[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.

 -- J.R.R.T, Ainulindale (Silmarillion)

Re: Trying to understand updating orbit2 makes 79 packages unintallable ...

On Mon, Nov 10, 2003 at 02:22:14PM +0100, Sebastian Rittau wrote:
 On Thu, Nov 06, 2003 at 10:24:05PM -0800, Joe Buck wrote:
  I'm trying to figure out the reason why orbit2 is blocked from testing,
 
 I can only guess, but I think it is because of orbit2's conflict with
 liblinc-dev. I would really like to see ORBit2 2.8 to go into testing,
 since I plan to remove the liblinc-dev package. But on the other hand I
 do not want to remove the liblinc-dev package as long as ORBit2 2.8 is
 not testing, because doing so would make stuff unbuildable in testing
 alone. (You need either ORBit2 2.8 or Linc and ORBit2 2.6 to compile
 stuff for ORBit.) It's a hen-and-egg problem.

If I were you I'd leave it alone for now and wait until everything else
is ready to be updated at once. Unfortunately it's now going to have to
wait behind the new glibc.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 12:03:38PM +0100, Robert Millan wrote:
 On Sun, Nov 09, 2003 at 08:33:00PM +, Matthew Garrett wrote:
  klogd will be unable to look up symbols, and ps and top need it for
  wchan to be displayable.
 
 I'm so scared. wchan won't be displayable!

As a prospective maintainer of an important package, it ill behooves you
to make fun of legitimate bug reports. In particular, klogd not being
able to look up symbols means that you and upstream will get less useful
bug reports when the kernel oopses.

  That doesn't deal with the problem I described. How do you prevent
  System.map and the running kernel getting out of sync when you upload a
  new version of the linux package? 
 
 I don't see why should I address that. But don't worry, if it turns out
 there's a reason to, I'm pretty capable of solving it.

How do you propose to do that without changing the package name, and
without leaving old System.map junk around for eternity? I don't see how
it can be possible.

(This is exactly the same question as Matthew asked, of course; but it
is an important question relative to this ITP and I want to see it
answered.)

 You're mixing trivial maintainer issues with this ITP. It's very pity
 of you if you're doing it on purpose.

You're proposing a packaging scheme where the package name is not
changed for new kernel versions. It is entirely legitimate for people to
bring up potential problems with this scheme. I'm disappointed that you
feel it necessary to brush them off just to railroad your proposal
through.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 12:57:02PM +0100, Robert Millan wrote:
 On Sun, Nov 09, 2003 at 07:47:37PM -0600, Marcelo E. Magallon wrote:
   Look, if you want to waste time, waste _yours_.  OTOH, if you want to
   take part in the discussion, do bother to address the issues you are
   being presented with.
 
 I'd really LOVE to. But this is my discussion. If I don't take part in
 it, who will respond to all these bogus arguments some people enjoy
 sending in?
 
 Rather, this is you and the other trolls who are wasting my time.

Oh, I see: anybody who disagrees with you is a troll. That's
interesting.

   Debian provides a _distribution_.  In this context less is more.  We
   have a gazillion emacs (to pick a random example) packages because
   there are _users_ for these packages who _do_ require the different
   versions.  This is not about survival of the fittest, this is about
   satisfying users' needs.
 
 Some people publicly said in this thread they like the package.
 Herbert said he likes it at least as an experiment. I got other
 private mails from well-known developers who like my proposal and pity
 your trolling attempts.

Oh, wow, I was wondering how long it would take for this to appear!

  The lurkers support me in email
  They all think I'm great don't you know.
  You posters just don't understand me
  But soon you will reap what you sow.

  Lurkers, lurkers, lurkers support me, you'll see, you'll see
  off in e-mail the lurkers support me, you'll see.

  Oh it's true, and you know they support me.
  There's thousands of lurkers out there!
  They all understand my intentions
  you posters are not being fair!

  Lurkers etc.

  The lurkers support me in email
  So why don't they post? you all cry
  They're scared of your hostile intentions
  they're not as courageous as I.

  Lurkers etc.

  One day I'll round up all my lurkers
  we'll have a newsgroup of our own
  without all this flak from you morons
  my lurkers will post round my throne.

  Lurkers etc.

(credit to Jo Walton)

   Let's have a look at the number of kernel-(image|source) packages for
   i386, and let's just assume that your scheme succeeds and becomes the
   preferred way of distributing Debian kernels, what would we have?  The
   following:
 
 I haven't even thought of my scheme as becoming the preferred way of
 distributing Debian Linux. So I'll ignore your bogus hipothesis.

Why not call it linux-experimental or linux-rmh or similar then? I'm
sure a lot of people would be much happier with your proposal if it
didn't claim the important namespace of linux, which implies that it
is the preferred kernel package.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Michael Poole

Robert Millan writes:

 And even if it was, I claimed my packages has some advantages, but didn't
 claim it doesn't have any disadvantages.

Please explain why the putative advantages outweigh the disadvantages.

1) I haven't built a 2.4 kernel lately, but in linux-2.6, selecting
some mandatory features in upstream for 386 (FPU and 486 instruction
emulation) disables SMP support.  How will you build a package for
both 386 and x86 SMP machines?  Keep in mind your claim that your
system would get rid of the many kernel-image-* packages.

2) With your packages, how will someone be able to keep a known-good
kernel on her machine when updating from one version of Linux to
another?  Complaining that bootloaders have the same problem is
specious: they are considerably smaller, so it's more likely that
changed code paths were tested by the packager.  User space also
differs: you can have many system utilities statically linked. If you
have just one kernel installed, though, you better have both rescue
disk and physical access to the machine.

3) One of the benefits you claim is that people can apt-get source
to get the source.  You have also said that your target audience
excludes those who build their own kernels.  To me, this is
inconsistent.  What is the target audience for this benefit?

4) Another benefit you claim is that people on less commonly used
architectures can get autobuilt kernels in the case of security
patches.  The only suggestion I saw to deal with multi-platform
testing was that some per-architecture team would do that.  Who has
volunteered to be on such teams?

5) How will you handle architectures where the current upstream kernel
is not based on the same version as your package?  The main suggestion
I see is that they'd have to use the current system for their kernels,
which seems very bad for consistency.

6) Autobuilding from your source package may speed up releasing
security patches.  Cannot a similar speedup can be achieved by writing
some scripts (much smaller and less time to maintain) to automatically
build the current kernel packages?  Your integration of multiple
architectures will also slow down normal updates, since you have to
get the new package revisions and then resolve any conflicts.

7) #include System.map.discussion, but s/System.map/modules/g for
the kernel being replaced.  Currently, installing a different version
of the kernel (not just a different revision of the package) makes
both sets of modules available.  We should not require users to reboot
so quickly after making a currently safe upgrade: I suspect I am not
alone in preferring to update packages on a different schedule than
when I reboot.

I may have overlooked some of the advantages you claim.  (I certainly
hope so, since none of the above are clearly in the ITP's favor.)  If
so, please remind me.

Michael

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Michael Poole

Robert Millan [EMAIL PROTECTED] writes:

 On Mon, Nov 10, 2003 at 06:44:55AM -0600, Marcelo E. Magallon wrote:
   How do the current kernel packages guarantee this?
   
   Why would Robert's package need to behave any differently?
 
  The current kernel packages don't make the old stuff just dissappear,
  so it's less of an issue in that case.  In fact, the only bad
  situation with the current kernel packages is when you update between
  package releases of the same kernel version, and the current kernel
  packages make plenty of noise in that situation.

 In what way is updating between releases worse than updating within the
 same release?

It is worse because a lot more code changes.  I am sure that you have
enough packaging (and Debian user) experience to recognize that.  I am
willing to assume that enough testing of Debian's package revision 2
(relative to revision 1) went on that my machine won't die.  I am not
willing to make the same assumption regarding Linux 2.4.23 relative to
Linux 2.4.22, whether they are from a Debian package or from upstream.

Michael

Re: rename linux-kernel-headers to system-headers

2003-11-10 Thread Jonathan Dowland

On Fri, Nov 07, 2003 at 10:45:24PM -0600, Graham Wilson wrote:
 On Fri, Nov 07, 2003 at 09:37:16PM +0100, Otto Wyss wrote:
   On Fri, Nov 07, 2003 at 10:45:32AM +, Jonathan Dowland wrote:
On Thu, Nov 06, 2003 at 07:55:03PM +0100, Eduard Bloch wrote:
 
 What not rename linux-kernel-headers to simple system-headers-linux?
 This will prevent confused users (or: lazy to read the description 
 users)
 from asking this again and again.

system-headers-linux is a bit vague and without knowing could be
associated with the kernel just as strongly as with libc.

How about libc-linux-headers?
   
   I second that, or perhaps libc6-linux-headers.
  
  If the package would have been named libc6-linux-headers to show its
  strong relationship with libc6 I had never started this thread. I'm not
  a fan of renaming but in this case IMO it seems to be appropriate.
 
 But then the package would have to be changed for a new SONAME. And I
 don't see any benefits of using libc6-linux-headers, as opposed to
 libc-linux-headers.

Would the package libc6 not have to be changed in the same way? So the
work would have to be done for part of the system. libc6-* would be more
consistent with libc6 (although I have little objection to libc-*, as it
is still a great deal clearer than the present situation)

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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Steve Greenland

I *know* I'm going to regret this...

On 10-Nov-03, 05:57 (CST), Robert Millan [EMAIL PROTECTED] wrote: 
 On Sun, Nov 09, 2003 at 07:47:37PM -0600, Marcelo E. Magallon wrote:
 
 I'd really LOVE to. But this is my discussion. If I don't take part in it,
 who will respond to all these bogus arguments some people enjoy sending in?

But you haven't responded to any of the *legitimate* arguments, except
to say they're bogus, and that you solve them by ignoring them.

 Rather, this is you and the other trolls who are wasting my time.

No, they're a bunch of experienced Debian developers trying to explain,
in the face of overwhelming willful ignorance, *why* the kernel packages
are set up the way they are, and why what you're wanting to do is a bad
idea.

 
 dpkg-buildpackage

That doesn't give me the source, except by side effect, and I don't want
to have to build the package just to get the source.

(Yes, I'm well aware that there are other ways to see the source, but
you didn't answer the question as stated.)

   And since there are a couple of these
   hacks floating around, how to get the unpacked patched source is
   non-obvious.
 
 It's as easy as in the rest of packages in Debian, no more, no less: Read
 debian/rules.

No, most of the packages in Debian give me the source with a simple
'dpkg-source -x'. No rules file reading necessary.

 It's easy for people who are already used to Debian de-facto standards.
 Since I am and you're not [1], that makes a difference. Therefore don't
 expect to understand it.

CDBS is *NOT* a de-facto standard, nor is DBS, nor any other of the
*BS. I'm not saying that they aren't useful, but they are by no means
any where near a majority. Each of the has a different way of unpacking
source, and it's non-trivial to find out how the first time you run
accross one.

That you can make such claim shows that you're the one unfamiliar with
standard Debian packaging.

 I responded to this before. We don't provide the Linux kernel packaged
 as a standard Debian package.

apt-get install kernel-image-2.4-386

 But certainly, you must be very scared of that possiblity, since you're
 wasting your time and inventing bogus arguments just to prevent it from even
 being in Debian at all.

The people objecting to your proposal have no vested interest in
anything except a working Debian distribution. Your package is
inherently likely to lead to breakage and confusion. Are you just
completely incapable of conceiving or admitting that you've made a
mistake, and that you need to solve the problems being presented rather
than just ignoring them and insulting people by assuming that they're
making personal attacks?

 Less risky? That's interesting. If you have some suggestions, perhaps you
 can help me improve my package.

Oh, that's a hoot, since you've been ignoring or belittling every one
who has been trying to improve it.

 Of course it does. Tell me what is inconsistent in my list of
 advantages. (And please, don't repeat the same arguments over again).

Which is it? Do you want the answer, or are you going to continue to
ignore the answer?

what's 2+2

4

No, what's 2+2, and don't keeping answering 4


Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Debconf Templates Style Guide: round 2

2003-11-10 Thread Christian Perrier

After publishing my first draft of the so-called Debconf Templates
Style Guide (DTSGmaybe this acronym is too close from the
DFSG) on October 28th, I have received many input and I have
completed some parts of the document.

Thanks to all people who already commented or encouraged me to
continue this work. There are too much of you guys and I'm a bit too
lazy for mentioning you all, but consider I owe you a beer à la
terrasse d'un café.

Below is the now second draft of the document.

Again, feel free to comment, either privately, or publicly (this mail
is still crossposted to -boot, -devel and -l10n-english).

Debconf Templates Style Guide
-

History:

0.0110/28/2003  Initial public release
0.0211/10/2003  Basic proofreading by Debian contributors

TODO:

- Use something else than crude text format. Help and advices welcome
- Add Rationale at the beginning of the document
- Details and guidelines for Choices fields
- Probably lot of stuff I didn't even think about.. :)

1. Do not abuse debconf
---

Since debconf appeared in Debian, it has been widely abused and
several criticisms received by the Debian distribution come from
debconf abuse with the need of answering a wide bunch of questions
before getting any little thing installed.

Keep usage notes to what they belong: the NEWS.Debian, or
README.Debian file. Only use notes for important notes which may
directly affect the package usability. Remember that notes will always
block the install until confirmed or bother the user by email.

Carefully choose the questions priorities in maintainer scripts. See
man debconf-devel(7) for details about priorities. Most questions
should use medium and low priorities.

2. General recommendations for authors and translators
--

2.1 Write correct English
-

Most Debian package maintainers are not native English speakers. So,
writing properly phrased templates may not be easy for them.

Please use (and abuse) debian-l10n-english@lists.debian.org mailing
list. Have your templates proofread.

Badly written templates give a poor image of your package, of your
work...or even of Debian itself.

Avoid technical jargon as much as possible. If some terms sound common
to you, they may be impossible to understand for others. If you cannot
avoid them, try to explain them (use the extended description). When
doing so, try to balance between verbosity and simplicity.

2.2 Be kind to translators
--

Debconf templates may be translated. Debconf, along with its sister
package po-debconf offers a simple framework for getting
templates translated by translation teams or even individuals.

Please use gettext-based templates. Install po-debconf on your
development system and read its documentation (man po-debconf is a
good start).

Avoid changing templates too often. Changing templates text induces
more work to translators which will get their translation fuzzied. If
you plan changes to your original templates, please contact
translators. Most active translators are very reactive and getting
their work included along with your modified templates will save you
additional uploads. If you use gettext-based templates, the
translator's name and e-mail addresses are mentioned in the po files
headers.

If in doubt, you may also contact the translation team for a given
language ([EMAIL PROTECTED]), or the
debian-i18n@lists.debian.org mailing list.

2.3 Do not make assumptions about interfaces


Templates text should not make reference to widgets belonging to some
debconf interfaces. Sentences like If you answer Yes... have no
meaning for users of graphical interfaces which use checkboxes for
boolean questions.

More generally speaking, try to avoid referring to user actions. Just
give facts.


3. Templates fields definition
--

This part gives some information which is mostly taken from the
debconf-devel(7) manual page.

3.1 Type


3.1.1 string 


Results in a free-form input field that the user can type  any string into.

3.1.2 password
--

Prompts the user for a password. Use this with caution; be aware that
the password the user enters will be written to debconf's
database. You should probably clean that value out of the database as
soon as is possible.

3.1.3 boolean
-

A true/false choice.

3.1.4 select 


A choice between one of a number of values. The choices must be
specified in a field named 'Choices'.  Separate the possible values
with commas and spaces, like this: Choices: yes, no, maybe

3.1.5 multiselect
-

Like the select data type, except the user can choose any number of
items from the choices list (or chose none of them).

3.1.6 note   
--

Rather than being a question per se, this datatype indicates a note
that

Removal of LaTeX2HTML from main

2003-11-10 Thread Roland Stigge

Hi,

working on the legal issues for LaTeX2HTML [1], at debian-legal [2], we
concluded that LaTeX2HTML will have to be removed from main because it
is considered non-free in the sense of the DFSG. After dozens of emails
with upstream and a thread [3] on the LaTeX2HTML mailing list, the
upstream maintainer doesn't consider changing the main license soon,
although at some point in the future, LaTeX2HTML will possibly be
GPL'ed. But that won't happen before 2005 because of historical reasons.

As suggested, I prepared a simple wrapper script [4] around TeX4ht to
emulate latex2html. Unfortunately, during the regression tests with the
38 build-depending packages that list latex2html in their
Build-Depends{,-Indep}, I noticed that only a few packages migrate
flawlessly to TeX4ht with the simple automated wrapper.

With /usr/bin/latex2html substituted, many packages render bad results
or even FTBFS because of several reasons:
- They rely on special generated files the original latex2html generates
  but htlatex doesn't
- TeX4ht/htlatex is not latex2html. Both have special features that
  are hard to mimick with a simple wrapper
- Some even FTBFS anyway (I will file that if not done yet)
- Different behaviour of htlatex and latex2html when called from other
  directories
- htlatex creates files not cleaned up (see the current tex4ht debian bugs)

Take this as an excuse for the simplicity of the wrapper [4], but it
seems to be hard to mimic latex2html with htlatex without investing very
much time. (If you volunteer, please send in improvements but I doubt
that we can easily sort out all the problems in an automated way.)
Instead, I propose the following plan which includes individual devotion
to the Build-Depending packages in question:

I will:
* Upload a latex2html package just containing the aforementioned wrapper
  and depending on tex4ht (and what else it needs to fulfill)
* File serious bugs against packages now rendered FTBFS
* File normal bugs against packages that render bad docs now
* File wishlist bugs against packages that actually don't need latex2html
* File wishlist bugs against packages that work well now but which could
  directly depend on tex4ht or another alternative
* Upload the original LaTeX2HTML as latex2html-nonfree. Ideally, no
  package build-depending on latex2html remains, so the name latex2html
  can remain

Here's a list of the packages in question:

Packages that work well with my wrapper script (don't need adjustments):
- cfitsio
- gnucap
- gnustep-make
- iacd
- tochnog

Packages that actually don't (seem to me to) need to depend on
latex2html because they don't use it at build time:
- abntex
- babel (contrib)
- fpc
- glibc
- hypre (non-free)
- pam
- python-crack
- sbm

Packages that have problems with the automated migration and need manual
adjustments:
- cherrypy (bad result)
- chktex (FTBFS)
- cmucl (FTBFS)
- debian-guide (bad result)
- debian-guide-es (FTBFS)
- debian-guide-zh (FTBFS)
- debian-zh-faq (FTBFS)
- dwarfs-debian-guide (FTBFS)
- ecasound2.2 (bad result)
- freefem (FTBFS)
- gnutls7 (FTBFS)
- illuminator (FTBFS)
- jed (FTBFS)
- libgocr (FTBFS)
- libnasl (FTBFS)
- mlton (FTBFS)
- pica (FTBFS)
- pointless (bad result)
- psp (FTBFS)
- pyopenssl (FTBFS)
- python2.1 (FTBFS)
- python2.2 (FTBFS)
- python2.3 (FTBFS)
- uudeview (FTBFS)
- sdcc (FTBFS)

As the maintainer of one of the aforementioned packages you have the
choice between the following options (exclusively):
* Remove the dependency on latex2html
* Check how the package builds now and manually adjust it to htlatex.
  The package should build-depend on TeX4ht now
* Build-Depend on hevea or hyperlatex if you figure out that one of
  these alternatives are better than TeX4ht (htlatex)
* Put the package to contrib as soon as latex2html-nonfree is in
  non-free and Build-Depend on it.

Thanks for reading all this and for considering.

bye,
  Roland

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204684
[2] http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00383.html
(and followups)
[3] http://tug.org/pipermail/latex2html/2003-October/thread.html
[4] http://www.antcom.de/debian/latex2html.sh


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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Lukas Geyer

Robert Millan [EMAIL PROTECTED] writes:

 apt-get source kernel-image-* doesn't bring me the real source. Instead, if
 I want the real source I must be root and install a binary package. Do you
 deny that this is confusing?

I don't understand why you must be root, could you elaborate? I am no
expert in Debian kernel packaging, but why not fetch the source of
kernel-image-*, see what kernel-patch-* packages it depends on and get
the source of them and kernel-source-*? It is not what I would do, as
I build my kernels with make-kpkg, but it doesn't seem impossible. To
a new user this will all be confusing, but they should not compile
their own kernels anyway.

 But this is my discussion. If I don't take part in it,
 who will respond to all these bogus arguments some people enjoy sending in?
 
 Rather, this is you and the other trolls who are wasting my time.

Yeah, sure, if 90% of the people disagree with you, they must all be
trolls. Reminds me of that guy on the wrong lane on the highway...

 On Sun, Nov 09, 2003 at 07:47:37PM -0600, Marcelo E. Magallon wrote:

   Now do go ahead and do tell me that the packaging is easy to
   understand.  Define easy then, because with the information I have
   at hand the only reasonable interpretation is easy for Robert Millan
   to understand.
 
 It's easy for people who are already used to Debian de-facto standards.
 Since I am and you're not [1], that makes a difference. Therefore don't
 expect to understand it.
 
 [1] Your reasoning shows either you're not used to them, or you're plainly
 trolling. I'll assume the first at your convenience.

What makes you think that Marcelo doesn't use Debian standards? Do you
have any evidence or is this just trolling on your side?

 Some people publicly said in this thread they like the package.

Many more stated the opposite opinion, but I guess you see them all as
trolls.

 Herbert said he likes it at least as an experiment. I got other
 private mails from well-known developers who like my proposal and
 pity your trolling attempts.

Yeah, anonymous sources, and what does well-known mean? The cabal?
People who hold an opinion on this and don't weigh in publicly can't
be accounted for. (The exception being the ftpmasters who can just
reject your package on upload...)


 But the real results are shown through Popularity Contest [1] when my package
 reaches unstable. So keep your arguments on this for later.
 
 [1] http://people.debian.org/~apenwarr//popcon/

Since when do we package everything and then see if it makes the
popularity contest? In my opinion you are adding to archive bloat and
this package should not hit unstable. Once it is there, it will take
ages until it gets removed. Why not upload to experimental or such and
if Herbert really likes it, then at some point it can replace the
current kernel packages. I still see a lot of substantial problems, in
particular the removal of the old kernel on upgrade. I never remove an
old kernel before I have thoroughly tested the new one. Last example
where this was necessary was the vanilla 2.4.22 which leads to hard
lock-ups after suspend from sleep on this iBook. Not unusable but
pretty annoying, and always good to have an older kernel to boot into
handy.

 I haven't even thought of my scheme as becoming the preferred way of
 distributing Debian Linux. So I'll ignore your bogus hipothesis.

So you want to add to the archive bloat? Just to have the Linux kernel
as a standard Debian package? So should we all start repackaging our
favorite applications where the maintainer packaging or default
configuration or compiler options are not to our taste? I hope you
would not want that, but I see your package doing exactly that for the
kernel.

 But certainly, you must be very scared of that possiblity, since you're
 wasting your time and inventing bogus arguments just to prevent it from even
 being in Debian at all.

Why is that wasting time? It is called quality assurance, first of all
trying to keep non-needed stuff out of the archive, second (at least
in my opinion) to make sure the maintainers understand their
packages. (For the record, I consider your repeated statement that
Herbert is the real maintainer and you are only the packaging monkey a
quite lame excuse. I don't want Debian maintainers to be just
repackagers, not for upstream, not for another maintainer.)

 How is deinstalling a known-to-be working {libc,bash,coreutils} not an issue?

libc and coreutils are an issue, less so bash. However, for the kernel
there is a good mechanism to keep backup kernels and choose them in a
bootloader. This is a feature, in my opinion, and that this doesn't
work for other packages is no excuse to stop it from working for the
kernel.

 And as I've seen in some other message, quoting kernel-package generated
 postinst, the current packages _do_ suffer of the same problem.

Only if you update a new Debian revision of the same kernel
version. Furthermore, you can always tweak EXTRAVERSION to

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Eduard Bloch

#include hallo.h
* Matthew Garrett [Mon, Nov 10 2003, 12:42:48PM]:

  IIRC you prefered not to
  answer to it but refered to an URL which did not contain the answers.
 
 I don't recall seeing this question before. So unless you provide a link to
 that, you're liing.
 
 Technically, no - even if he doesn't provide a link, it may be true. And
 even if the question wasn't asked before, he may be mistaken. Accusing
 people of deliberately telling falsehoods (and note the IIRC - for
 this to be a lie, Eduard would have to have known absolutely that what
 he was saying was not true) makes you look like a fanatic.

Thanks for addressing this. Well, it is in
[EMAIL PROTECTED] - instead of answering what
actually justifies that name, there is only another subset of {look in
the first proposal|look at Herbert agreeing (vague)|there are others who
support me so stop wasting my time}.

  Why cannot you invent something new to convince us?
 
 As I said before I'm unwilling to understand your sarcasm.

Oh Robert... Faster detection of sarcasm demonstrates how good someone
understands the stuff in question.

MfG,
Eduard.
-- 
Wie verschieden, ob man sich in die Ober- oder Unterlippe beißet!
-- Jean Paul

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread A.J. Rossini

Jamie Wilkinson [EMAIL PROTECTED] writes:

 This one time, at band camp, Eduard Bloch wrote:
You repeat this again and again and got answers from me and others to
such an ultimate argument. But did you ask yourself why Herbert does not
participiate this discussion to help you?

 Why does the lack of response from Herbert prove that this package is a bad
 idea?  I'm saddened that you have to revert to intimidation in place of a
 technical argument.

Herbert did respond with a single message, somewhat positively if I
recall.  Check the archives on this thread.

-- 
[EMAIL PROTECTED]http://www.analytics.washington.edu/ 
Biomedical and Health Informatics   University of Washington
Biostatistics, SCHARP/HVTN  Fred Hutchinson Cancer Research Center
UW (Tu/Th/F): 206-616-7630 FAX=206-543-3461 | Voicemail is unreliable
FHCRC  (M/W): 206-667-7025 FAX=206-667-4812 | use Email

CONFIDENTIALITY NOTICE: This e-mail message and any attachments may be
confidential and privileged. If you received this message in error,
please destroy it and notify the sender. Thank you.

Bug#219996: ITP: oinkmaster -- Simple snort rules manager

2003-11-10 Thread Roberto Moreda

Package: wnpp
Severity: wishlist

* Package name: oinkmaster
  Version : 0.8
  Upstream Author : Andreas Östling [EMAIL PROTECTED]
* URL : http://www.algonet.se/~nitzer/oinkmaster/
* License : BSD without advertising clause 
  Description : Simple snort rules manager

 Oinkmaster is simple Perl script that helps you update your Snort
 2.0+ rules and comment out the unwanted ones after each update. It
 also has a few other useful features regarding rules management.
 .  
 Oinkmaster will tell you exactly what had changed since the last
 update, hence giving you good control of your rules.
  

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux tales 2.4.22-xfs #2 vie nov 7 13:27:52 CET 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL 
PROTECTED])

Re: Removal of LaTeX2HTML from main

2003-11-10 Thread Sven Luther

On Mon, Nov 10, 2003 at 04:06:02PM +0100, Roland Stigge wrote:
 Hi,
 
 working on the legal issues for LaTeX2HTML [1], at debian-legal [2], we
 concluded that LaTeX2HTML will have to be removed from main because it
 is considered non-free in the sense of the DFSG. After dozens of emails
 with upstream and a thread [3] on the LaTeX2HTML mailing list, the
 upstream maintainer doesn't consider changing the main license soon,
 although at some point in the future, LaTeX2HTML will possibly be
 GPL'ed. But that won't happen before 2005 because of historical reasons.
 
 As suggested, I prepared a simple wrapper script [4] around TeX4ht to
 emulate latex2html. Unfortunately, during the regression tests with the
 38 build-depending packages that list latex2html in their
 Build-Depends{,-Indep}, I noticed that only a few packages migrate
 flawlessly to TeX4ht with the simple automated wrapper.

Notice that there is also Hevea, which has the latex2html functionality.
I don't know if it provides a latex2html wrapper functionality, but i
can ask upstream (not my package though, but i have contact with
upstream). It is said to provide quite nice HTML output.

$ apt-cache show hevea
Package: hevea
Priority: optional
Section: tex
Installed-Size: 1572
Maintainer: Ralf Treinen [EMAIL PROTECTED]
Architecture: all
Version: 1.07-1
Depends: gs, netpbm (= 2:9.10-1), tetex-bin, ocaml-base-3.07
Suggests: netpbm-nonfree, hevea-doc
Filename: pool/main/h/hevea/hevea_1.07-1_all.deb
Size: 297130
MD5sum: 864446c7d06cbd8dd3aac71651030757
Description: Translator from LaTeX to HTML, info, or text
 Its remarkable features are
  - It produces good output. By default (can be turned off) it uses
in case of HTML output the symbol face for math symbols. Either way
it usually avoids generating zillions of picture files.
  - It is highly configurable through (La)TeX macros. Though aimed at
LaTeX input it understands a fair subset of TeX' macro language.
  - It runs fast.
 .
 This version of HeVeA is patched to generate by default picture files
 in the PNG format instead of the GIF format.
 .
 See also http://para.inria.fr/~maranget/hevea/index.html.

Friendly,

Sven Luther

create new Debian-Kernel project (was: ITP: linux -- Linux 2.4 kernel)

2003-11-10 Thread Eduard Bloch

#include hallo.h
* Jamie Wilkinson [Mon, Nov 10 2003, 06:54:22PM]:

 The fact of the too generic package name was mentioned before within
 other arguments against your linux package. IIRC you prefered not to
 answer to it but refered to an URL which did not contain the answers.
 
 'linux' is a perfect name for the package.  The tarballs contain that very
 name.

Note that the name is choosen not only to attract the user, but also to
catch that who blindly use apt-get source linux. The user wouldn't get
the well-known and good kernel-source packages but something which is
under control of Robert. Further, what they would get is not a clean
source but something with debian/ dir inside which would confuse
make-kpkg. I would not mind if he had called it linux-rmh or such.

  2) I use the upstream name. If you don't like it, bitch upstream.
 
 Sorry, how much did you drink to find an answer like this one? If Linus
 changes the package name (which is unlikely to happen ;)), I am sure you
 would rename your ITP to follow him.
 
 Are you implying that you make up names for the software that you package,
 rather than use the name given to it by upstream?  I believe you don't.

Ah, that is a good base to start a discussion. Of course it is better to
keep the upstreams name but make exceptions if they are too generic, to
confusing or to offensive (though we did already accept such ones, eg.
pornview ;)).

 Given that there's a possibility that Debian will include non-linux kernels
 in the future.  In that case, calling the linux kernel package
 'kernel-image' doesn't give a lot of room for the other kernels to live in.
 Calling the package 'linux' makes it pretty clear which software it is
 packaging.

I would not call any package linux or freebsd, not even in the
source package name. In fact, for a future development of debian-kernel
packaging, I have written something down few days ago.

... 
 # create debian-kernel mailing list, found a new project called
 # debian-kernel alias DK. Keep the project files in a project-internal
 # repository unless the stuff is mature enough to see the daylight of Sid,
 # post-sarge.

In addition to the others plan on the mentioned Wiki page, we need
following packages:

 linux-kernel-setup: setup utility for the Linux kernel packages created
by the debian-kernel project
(s/linux/Hurd/ or *BSD)

 linux-initrd-builder: adapted version of initrd-tools; supposed to
   work with d-k kernel packages but not limited to them
 
 packages following the following naming strategy:

 linix-kernel-source-2.4.XY:  basicaly the upstream source
 
 lk-patch-essential-2.4.XY: hot fixes like for security issues,
compiling problems etc.

 lk-patch-recommended-2.4.XY: important but optional patches like
  initrd-on-cramfs fix discuss that,
  vesafb-as-module, bigphysarea...

 lk-patch-suggested-2.4.XY: sensible patches but not sensible for
everyone: ipsec backports,

 dk-meta-linux-2.4.23: meta package with dependencies/conflicts
  to keep the *-2.4.XY packages above in sync

The binary kernel packages would not be longer distributed with
auto-installing script and all the modules inside. Instead, they would use
the linux|...-kernel-setup utility. No longer one big package, but create:

linux-kernel-$KVERS: meta package with strong dependency on lki-$KVERS and
maybe some modules packages, see below.
linux-kernel-image-$KVERS: the image itself, including System.map, config, etc.
linux-modules-general-$KVERS: all the general modules, including common
  componentes like scsi-hd/cd support used by
  usb/firewire/... drivers
linux-modules-ide-$KVERS: includes all the low-level ide drivers
linux-modules-scsi-$KVERS: same for scsi
linux-modules-usb-...: ...
linux-modules-firewire-...: ...
linux-modules-multimedia-...: sound drivers, v4l, joystick drivers, etc.

end-of-brainstorming

I am open for discussions about that.

MfG,
Eduard.
-- 
Was die neuen Unwissenden holen müssen:
Siemens-Lufthaken

Re: libGL.so.1: cannot handle TLS data (nvidia-glx deb issue?)

2003-11-10 Thread Juergen Kreileder

Frederik Dannemare [EMAIL PROTECTED] writes:

[...]

 -8 is in fact the version I have installed, and it seems that I'm
 not the only one having problems with this one:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219646

Ah, I see.  Some games seem to try to load /usr/lib/libGL.so by
default.  That's broken, they should try to use libGL.so.1.

For Q3A based games you can fix this by setting r_gldriver in the
config file (seta r_gldriver libGL.so.1) or when starting the game.
(e.g.: wolfsp +set r_gldriver libGL.so.1)


Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://www.blackdown.org/java-linux/java2-status/

Re: On linux kernel packaging issue

2003-11-10 Thread Paul Hampson

On Sat, Nov 08, 2003 at 10:58:03AM +0100, Eduard Bloch wrote:
 #include hallo.h
 * Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:

  Optimization is a serious issue too. Unlike most user space software, using
  386 kernel on modern PC will cause serious performance loose. Especially if
  you consider mmx/sse/... and SMP issues. Note also that not all drivers are
  compatible with SMP, etc.

 Except of SMP, how exactly does optimisation of the KERNEL CODE help you?
 Your filesystem driver may become 2-3% faster, but the disk won't speed
 up at all, haha.

Don't you have to compile the kernel for a CPU with MMX support to be
able to use MMX in userspace? I understood something like that from the
mplayer docs recently, but I may have misunderstood...

-- 
---
Paul TBBle Hampson
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

No survivors? Then where do the stories come from I wonder?
-- Capt. Jack Sparrow, Pirates of the Caribbean

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: problems with dpkg, apt, perl etc. ( wait/waitpid)

2003-11-10 Thread Matt Zimmerman

On Mon, Nov 10, 2003 at 09:56:04AM +0200, Cristian Rauta wrote:

 I know, maybe -devel is inappropriate list for my problems, but i don`t
 know another list for that. 
 I think that problem was some time ago with woody  ( see bug # 206187)
 
 btw my debian version is sid 

Yes, see bug #206187, where I asked you yet again to provide some details
about this problem, and you ignored my request.  I originally asked you in
#199653, and instead of responding, you filed a duplicate bug report 

I will ask again for the following information:

- your login shell (getent passwd `whoami`)
- how you log in (console, ssh, xdm, gdm, etc.)
- what terminal program you use (gnome-terminal, xterm, rxvt, etc.)
- the output from this command: perl -w -e 

-- 
 - mdz

Re: create new Debian-Kernel project (was: ITP: linux -- Linux 2.4 kernel)

2003-11-10 Thread viro

On Mon, Nov 10, 2003 at 05:11:45PM +0100, Eduard Bloch wrote:
   initrd-on-cramfs fix discuss that,

You mean the kludge that craps in fs/block_dev.c?  If so, feel free to
can it - the proper fix is to switch cramfs_read() to use of pagecache
and it's going upstream.

Bug#220007: ITP: spampd -- Spam proxy daemon using spamassassin

2003-11-10 Thread Roberto Suarez Soto

Package: wnpp
Severity: wishlist

* Package name: spampd
  Version : 2.11-1
  Upstream Author : Maxim Paperno [EMAIL PROTECTED]
* URL : http://www.WorldDesign.com/index.cfm/rd/mta/spampd.htm
* License : GPL
  Description : Spam proxy daemon using spamassassin

  spampd is an SMTP/LMTP proxy that marks (or tags) spam
  using SpamAssassin (http://www.SpamAssassin.org/). The
  proxy is designed to be transparent to the sending and
  receiving mail servers and at no point takes responsibility
  for the message itself. If a failure occurs within spampd
  (or SpamAssassin) then the mail servers will disconnect and
  the sending server is still responsible for retrying the
  message for as long as it is configured to do so.

Packages are available at http://retrincos.net/~robe/spampd.
I'll upload them in a couple days, after I have received no This
package broke my system beyond repair! messages :-)

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux onix 2.4.22 #1 Wed Oct 15 11:19:20 CEST 2003 i686
Locale: LANG=es_ES, LC_CTYPE=es_ES (ignored: LC_ALL set to es_ES)

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Marcelo E. Magallon

On Mon, Nov 10, 2003 at 12:57:02PM +0100, Robert Millan wrote:

Since you like playing word games... what else do you get when you
do apt-get source kernel-image-2.4.22-1-k7 if not
kernel-image-2.4.22-1-k7's source package?
   
Do you want the Linux Kernel sources with all the patches as used by
kernel-image-* _already_ applied and available in a well known
location?  apt-get install kernel-tree-x.y.z.
  
  apt-get source kernel-image-* doesn't bring me the real source.
  Instead, if I want the real source I must be root and install a
  binary package. Do you deny that this is confusing?

 Non-intuitive?  Yes, I grant you that.  Confusing?  No, I don't find it
 confusing.

 But you conveniently ignored a bit of my message: after installing
 kernel-tree-x.y.z you have the source _with_ patches applied.  I don't
 really mind either way, but I'm looking for consistency in your
 argumentation, and I'm not finding it.  You seem to claim the source
 package is of paramount importance to you, yet I don't understand how
 you are happy with a source package format which _does not_ give you
 the sources of the package as used to generate the binaries.

Look, if you want to waste time, waste _yours_.  OTOH, if you want
to take part in the discussion, do bother to address the issues
you are being presented with.
  
  I'd really LOVE to.

 Then go ahead and address them.  I'm not stopping you.

  You said: I've got news for you: Debian is a distribution.
 
  Who started the nitpick wording?

 Go back to [EMAIL PROTECTED] and, for a change,
 _read_ what I wrote.

Again, your complain is that there are too many kernel-foo packages,
  
  Don't put words in my mouth. I said the current package set is
  confusing, which it is.

 So that's not the source of the confusion?  Then why do you bring the
 number of packages into the discussion?  Look at what you said in
 [EMAIL PROTECTED].  _You_ are the one making
 the explicit connection between confusing and the number of packages.

 So we are back to square one where the confusion rests at the source
 package format.  This is starting to look like nothing but a tantrum.

but you are adding more.  How does that improve on the problem you
perceive?
  
  In what way the presence of 136 separate kernel-* packages affects
  the confusability of my pair of linux-* ones?

 Oh, right, you don't want to solve a problem in Debian, you want to
 solve it in a little corner of your mind and just ignore whatever else.

  No, I could do the same with plain dh-make'ed templates. It'd have
  the advantage that I wouldn't have to discuss silly arguments with
  you.

 1.  CDBS doesn't preclude the use of debhelper.  You already know this.

 2.  This specific point wouldn't exist, but that doesn't mean I'd
 still be objecting to your ITP.  If you go back and read
 [EMAIL PROTECTED] you'll notice that I didn't
 object to your particular choice of source packaging.  The only
 reason why we are discussing that matter is because you claim this
 is a significant advantage of your work (you keep referring people
 back to [EMAIL PROTECTED], where this is
 one out three points you list as benefits)

  But your arguments are not that relevant, so I'll stick with CDBS.

 Whatever.

Futhermore, you argue that the packaging is confusing and
non-standard.  I take you think that CDBS is somehow standard and
easy to understand.  It's neither.  After apt-get source foo,
foo-x.y still _does not_ contain the sources used to build the
package.  You have to take extra steps to do that.
  
  dpkg-buildpackage

 LOL... good one.  (it was a joke, right?)

 If I bother to apt-get source foo, it's not because I want to
 dpkg-buildpackage it right away, is it?  Not having a standard way to
 patch source (or unpack and patch, in cases such as libc6 and xfree86),
 means that you have to use debian/rules something to get the source
 that's actually used to build the package.  There are good reasons for
 needing such a system, but this should be the exception, not the rule.
 But I'm drifting...

 Point is 'apt-get source linux-2.4' won't give you the sources used to
 generate the binaries.  If you claim this is the case, then you have to
 accept that 'apt-get source kernel-image-2.4.22-i386' also does.  Both
 packages have build dependencies which pull _additional sources_ into
 the tree.  If you are serious about that dpkg-buildpackage thing,
 then you are making no sense whatsoever, because apt-get source --build
 foo will work fine in _both_ cases.

 Have you noticed that with your packaging it is quite an adventure to
 figure out which .config file is used to build the kernel, because you
 don't even bother to provide something like debian/rules .config.  I
 mean, the way it was written the last time I looked at it you stuff a
 whole lot of actions together in a single target.  My question is how
 do you intend for people to

Re: On linux kernel packaging issue

2003-11-10 Thread Nikita V. Youshchenko


 On Sat, Nov 08, 2003 at 10:58:03AM +0100, Eduard Bloch wrote:
  #include hallo.h
 
  * Nikita V. Youshchenko [Sat, Nov 08 2003, 12:39:58PM]:
   Optimization is a serious issue too. Unlike most user space
   software, using 386 kernel on modern PC will cause serious
   performance loose. Especially if you consider mmx/sse/... and SMP
   issues. Note also that not all drivers are compatible with SMP,
   etc.
 
  Except of SMP, how exactly does optimisation of the KERNEL CODE help
  you? Your filesystem driver may become 2-3% faster, but the disk
  won't speed up at all, haha.

 Don't you have to compile the kernel for a CPU with MMX support to be
 able to use MMX in userspace? I understood something like that from the
 mplayer docs recently, but I may have misunderstood...

In theory, for proper context-switch-safe support for MMX, SSE and all 
other modern x86 capabilities, corresponding code should present in 
context-switch routins of the kernel.

That code definitly exists in kernel compiled for 686 or k7. I don't know 
if it is compiled it when compiling 386 kernel. Anyone interested can 
look in the sources :).

2.6 kernels seem to have more CPU selection related options, including CPU 
selection and compile support for other CPUs switch.

I believe that it is generally beter to use kernel that corresponds to the 
CPU. This will make system more consistent.

Re: Inittab runlevel problem

2003-11-10 Thread Tobias Wolter

On 2003-11-10T17:28:10+0100 (Monday), François TOURDE wrote:
 Runlevels are distro dependants. Debian default is 2. Red Hat, for
 example is 2-text login, 3-[x|g|?]dm graphic login.

I had to retrofit my runlevels with the LSB-proposed run level usage.

*: Are there any plans to migrate to LSB runlevels? Should be fairly
easy to accomplish by a small adjustion to the rulefiles..

Though that small adjustion would have to be done with, oh, about
every third package, I guess. *coughs*
-- 
'Have you lost your senses?'
'Yes, but I may have found some better ones.'


signature.asc
Description: Digital signature

Re: [OT] Re: Bug#219293: ITP: songwrite -- a tablatures editor and player

2003-11-10 Thread Henning Makholm

Scripsit Roberto Suarez Soto [EMAIL PROTECTED]
 On Nov/10, Branden Robinson wrote:

  I've ever met a guitar player who wouldn't know what I meant if I said,
  hey, can you show me how to finger an F#7sus4 in the second position?

 Most people that play guitar (not pro guitar players) that I know would
 hesitate when confronted to a F#7sus4. Though maybe you're a Jazz or Fusion
 player and use that chord extensively ;-)

They might not know the answer, but they'd certainly be able to parse
the question, right?

-- 
Henning Makholm  Det er jo svært at vide noget når man ikke ved det, ikke?

Bug#220034: ITP: gtk-acl -- GTK front end to manage ACL permissions

2003-11-10 Thread Sebastian D.B. Krause

Package: wnpp
Severity: wishlist

* Package name: gtk-acl
  Version : 0.1.1
  Upstream Author : Frédéric Gaudy [EMAIL PROTECTED]
* URL : http://savannah.nongnu.org/projects/gtk-acl/
* License : GPL
  Description : GTK front end to manage ACL permissions

gtk-acl is a GTK front end to manage ACL permissions on files and
directories. You can set write, read and execute attributes to ACL and
unix files permissions, change user and group owner of unix file and
add or delete ACL users and groups.

I've already built a package for testing. You can get it on
http://buug.de/~sheskar/debian/gtk-acl/

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux pillbox 2.6.0-test9-1-386 #1 Sun Oct 26 22:32:52 EST 2003 i686
Locale: LANG=C, [EMAIL PROTECTED]

Re: Changes in t1lib.

2003-11-10 Thread Artur R. Czechowski

On Mon, Nov 10, 2003 at 12:04:18AM -0500, Branden Robinson wrote:
 Recall that Apt figures out dependency chains for most people.  The only
 people you're going to offend with the ugliness are people who already
 think like Debian developers.  And in my experience, one can't cross the
 street without offending a Debian developer, so don't worry about it.
 ;-)
If you say so. I just tried to be friendly :)

 You might as well.  You're going to end up carrying a dummy package
 sooner or later.
Indeed.

  The 1.3.1 release is really old. I would like to have it in a good condition
  for sarge, then focus on 5.0.0 and, later, ask to remove 1.3.1.
 Well, if you don't want to unleash 5.0.0 into sarge, then that *is* a
 good reason for waiting.
I have no idea - see below.

  The 5.0.0 package will be consistent with DP 8.1. BTW, how should
  package with development files be named: t1lib5-dev or libt1-5-dev?
 What's wrong with libt1-dev?  Do you expect to have to support
 development against multiple versions of t1lib?
No.

Let me make myself clear.

There is t1lib 1.3.1 package in Debian. This is old and unsupported. My goal
is to remove it from Debian.
There is t1lib 5.0.0. I would like to have it as an only t1lib in distribution.
As I wrote it, it has some changes in API. Just replacing old version with
current one result with FTBFS in some packages (well, probably in all
dependant packages), what is not intended behavior. So we need a way to 
both version available in archive. Policy requests, that packages should
contain a soname in this case. That's why I did this fuss about changing
packages name. If there is any error in my thinking, please point it out to
me.

OTOH, other scenario is possible:
1. I left package with 1.3.1 version with names: t1lib1, t1lib-dev,
   t1lib-doc, t1lib1-bin. Version 5.0.0 is uploaded with names: libt1-5,
   libt1-dev, libt1-doc, t1lib-bin.
2. Dependant packages are modified and recompiled to use v5.0.0
3. 1.3.1 is removed, we left with libt1-5, libt1-dev, libt1-doc and
   t1lib-bin, for users convenience empty t1lib-dev and t1lib-doc with
   dependencies only will be added.

But it is not consist with Policy, section 8.1. If we agree, that this
migration should be done before sarge release then I go on. If not - the
first way will be realized. Most of all I would like to know RM's opinion
(Anthony, are you there?).

Cheers
Artur
-- 
jabber:[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#220036: ITP: mudpit -- Spool processor for Snort's unified log/alert files

2003-11-10 Thread Roberto Moreda

Package: wnpp
Severity: wishlist

* Package name: mudpit
  Version : 1.3
  Upstream Author : G Savchuk [EMAIL PROTECTED]
* URL : http://www.fidelissec.com/mudpit.html
* License : GPL
  Description : Spool processor for Snort's unified log/alert files

 Mudpit is a modular spool processor for log/alert files generated by
 Snort IDS using the unified output format. Among its features:
 
 * Ability to process both alert and log files in parallel,
   choosing one that contains more information on a particular
   event.
 * Ability to independently handle outputs of more than one
   Snort processes on the same computer under separate permission sets.
 * Stability, including support for automatic recovery from network
   failures and outages with no information loss (checkpoints).
 * Modularity and ability to assign more than one output plugin to each
   spool processor.
 * A generic locking facility that allows separate spool processors
   to write to the same back-end database simultaneously.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux tales 2.4.22-xfs #2 vie nov 7 13:27:52 CET 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL 
PROTECTED])

Re: Inittab runlevel problem

2003-11-10 Thread Miquel van Smoorenburg

In article [EMAIL PROTECTED],
Tobias Wolter  [EMAIL PROTECTED] wrote:
On 2003-11-10T17:28:10+0100 (Monday), François TOURDE wrote:
 Runlevels are distro dependants. Debian default is 2. Red Hat, for
 example is 2-text login, 3-[x|g|?]dm graphic login.

I had to retrofit my runlevels with the LSB-proposed run level usage.

*: Are there any plans to migrate to LSB runlevels? Should be fairly
easy to accomplish by a small adjustion to the rulefiles..

Though that small adjustion would have to be done with, oh, about
every third package, I guess. *coughs*

Well, please have a look at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216028

If we're going to do that, an override file that says which
services have to run in what runlevel could be added as well.

Mike.

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Sun, Nov 09, 2003 at 08:17:58PM +0100, Robert Millan wrote:
  - I'm not trying to make a package, the package is already made and it works
fine. I'm using it right now.

Okay, please don't write software or maintain any packages.

I can't think of anything more indicative of total inexperience than
it works fine.

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


signature.asc
Description: Digital signature

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 12:57:02PM +0100, Robert Millan wrote:
 But the real results are shown through Popularity Contest [1] when my package
 reaches unstable. So keep your arguments on this for later.

That is possibly the stupidest thing I have seen all week.

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


signature.asc
Description: Digital signature

Library packages and their use

2003-11-10 Thread Otto Wyss

The discussion about the libc6-dev package and its headers let me to the
impression that the Debian package structure isn't optimal for
libraries. If anyone wants to build his own version of a package (i.e.
libwxgtk2.4) he has to get all the dependent underlying dev packages as
well. This is a long line of dependencies which mostly aren't wished and
shouldn't be necessary. The problem arises because the 2 usual package
lines (normal and dev packages) don't fit well with the needs of the
users.

There are 3 kinds of dissimilar user groups of a package:
1. Users just using a library linked to other packages
2. Developers building packages which depends on a library package
3. Developers building his own version of this library package

Currently group 1 just uses the normal packages while group 2 + 3 have
both to use the dev packages. Especially for group 2 this isn't a good
solution leading to a long line of unnecessary dependencies.

Solution 1: Splitting the 2 packages into 3. Not very attractive, it
will more confuse than improve the situation. Maybe the dbg packages
could take over the role of the 3. group.

Solution 2: Packages are changed that group 1 + 2 can use the normal
packages and only group 3 uses the dev. That means the normal library
packages contain enough so that other packages depending on this can be
build.

Solution 3: Normal packages are for group 1, dev packages are for group
2 and group 3 has to get anything needed by other means (i.e. CVS).
Usually group 3 is rather small and they tend to get anything by CVS
anyway.

I'm not sure if any of the above solutions will improve the situation
but we should all try to remove dependencies wherever possible. And I'm
not sure if any library package can be split this way but it should be
tried.

O. Wyss

-- 
See http://wxguide.sourceforge.net/; for ideas how to design your app.

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 11:58:46AM +0100, Robert Millan wrote:
 On Sun, Nov 09, 2003 at 10:43:49PM +0100, Eduard Bloch wrote:
   1) You said before you were concerned about my package occupiing the 
   package
   namespace in the archive. The fact that you don't like the name of my 
   package
   proves your previous argument was intentionaly bogus.
  
  The fact of the too generic package name was mentioned before within
  other arguments against your linux package.
 
 How many software programs called linux are around?

Dozens. Lots of people have created variations on the theme of
linux. You're not even talking about packaging the one released from
kernel.org, you're talking about creating your own fork (vis. patches
to make it work on different architectures).

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


signature.asc
Description: Digital signature

Why you are wrong [Was: On linux kernel packaging issue]

[If, after reading this mail, you continue to make the same invalid
assertions and broken arguments, then you should not be surprised when
people write you off as a troll].

On Mon, Nov 10, 2003 at 09:01:01AM +1100, Glenn McGrath wrote:
 On Mon, 10 Nov 2003 01:32:44 +0800
 Cameron Patrick [EMAIL PROTECTED] wrote:
 
  Well, Glenn didn't really put many words around his output from timing
  bzip2, so any claims about what he was trying to prove are
  speculative.
 
 The point i was trying to make is that architecture specific
 optimisations do make programs run faster.

You failed. Your experiment was flawed, as has been described in great
detail in this thread.

Also, your experiment couldn't have proven this even if it were
correct. All it could have shown is that one particular set of
optimisations worked better than another for one particular
program.

Now, if you were to assert that architecture specific optimisations
can make *some* program run faster, then I doubt you would have any
trouble getting people to agree with you. However, this assertion does
not lead to the conclusion we should use these particular
architecture specific optimisations for all programs - instead, it
leads to the question which is asked every time this comes up:

Does this particular set of architecture specific optimisations make
this program run faster?

And which is almost invariably not answered. On the rare occasions
when there is a valid answer, and it's yes, then we find a way to
make it happen (eg, libssl).

 There is no point taking discussions any further if people refuse to
 accept that very basic and simple principle on face value.

We refuse to accept it blindly because it's wrong. There have been
cases when architecture-specific optimisations have made programs run
slower (recently the instruction ordering for that via i686 chip
comes to mind); GCC gets it wrong from time to time, and there's no
reason to think it's currently right (since everybody who asserts it
is has failed to provide anything but circumstancial evidence, and
we all know that software sucks).

Sometimes it even causes programs to stop functioning entirely
(athlon and p4, gcc 3.0.0 until sometime in 3.1.x).

There are also an unknown number of cases where the optimum object
code for i386 is the same as the optimum object code for i686 (it is
trivial to empirically prove these exist [hello world]; it is very
hard to know how many there are).

There's certainly no evidence to support your assertion that it always
makes programs run faster, and considerable *empirical proof* that
it's wrong (disproving statements like Y is true for all X is easy;
proving them is hard).

So don't whine about people refusing to accept it.

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


signature.asc
Description: Digital signature

Re: Sarge Jigdo files incompatible with Debian mirror (fwd)

2003-11-10 Thread Santiago Garcia Mantinan

On Wed, Nov 05, 2003 at 02:17:59PM +0100, Andreas Tille wrote:
 I wanted to try Sarge installer for a new box and thus I used jigdo with

 
 http://gluck.debian.org/cdimage/testing/jigdo-area/i386/sarge-i386-1.jigdo

 Unfortunately one package seems to be removed from the mirrors (see the
 log below and search for serial-modules-2.4.22-1-386-di_0.9_i386.udeb).

 Any hints?

I have just replied to a similar mail to this one, sorry for the late reply,
I believe that your problem is that the image you are trying to download is
old, so the file you need to complete it has been removed even from the
backup server we have, as the image got replaced with a new one, however you
can get that file from this url:

http://snapshot.debian.net/archive/2003/10/31/debian/pool/main/l/linux-kernel-di/serial-modules-2.4.22-1-386-di_0.9_i386.udeb

snapshot.debian.net keeps track of the last months of Debian's packages, so
you can always get to it as a final resource ;-)

Hope this helps!

Regards...
-- 
Manty/BestiaTester - http://manty.net

Bug#219447: Last Microsoft Security Pack

2003-11-10 Thread MS Customer Assistance

ALERT!This e-mail, in its original form, contained one or more attached files that were infected with a virus, worm, or other type of security threat. This e-mail was sent from a Road Runner IP address. As part of our continuing initiative to stop the spread of malicious viruses, Road Runner scans all outbound e-mail attachments. If a virus, worm, or other security threat is found, Road Runner cleans or deletes the infected attachments as necessary, but continues to send the original message content to the recipient. Further information on this initiative can be found at http://help.rr.com/faqs/e_mgsp.html.Please be advised that Road Runner does not contact the original sender of the e-mail as part of the scanning process. Road Runner recommends that if the sender is known to you, you contact them directly and advise them of their issue. If you do not know the sender, we advise you to forward this message in its entirety (including full headers) to the !
Road Runner Abuse Department, at [EMAIL PROTECTED]

Microsoft

All Products|
Support|
Search|

Microsoft.com Guide

Microsoft Home

MS User
this is the latest version of security update, the
"November 2003, Cumulative Patch" update which eliminates
all known security vulnerabilities affecting
MS Internet Explorer, MS Outlook and MS Outlook Express
as well as three new vulnerabilities.
Install now to help protect your computer
from these vulnerabilities, the most serious of which could
allow an attacker to run executable on your system.
This update includes the functionality of all previously released patches.

System requirements

Windows 95/98/Me/2000/NT/XP

This update applies to

MS Internet Explorer, version 4.01 and later
MS Outlook, version 8.00 and later
MS Outlook Express, version 4.01 and later

Recommendation
Customers should install the patch at the earliest opportunity.

How to install
Run attached file. Choose Yes on displayed dialog box.

How to use
You don't need to do anything after installing this item.

Microsoft Product Support Services and Knowledge Base articles
can be found on the Microsoft Technical Support web site. For security-related information about Microsoft products, please visit the
Microsoft Security Advisor web site, or Contact Us.

Thank you for using Microsoft products.
Please do not reply to this message. It was sent from an unmonitored e-mail address and we are unable to respond to any replies.

The names of the actual companies and products mentioned herein are the trademarks of their respective owners.

Privacy Statement|
Accessibility

file attachment: update.exe

This e-mail in its original form contained one or more attached files that were
infected with the [EMAIL PROTECTED] virus or worm. They have been removed.
For more information on Road Runner's virus filtering initiative, visit our
Help Member Services pages at http://help.rr.com, or the virus filtering
information page directly at http://help.rr.com/faqs/e_mgsp.html.

Re: Why you are wrong [Was: On linux kernel packaging issue]

2003-11-10 Thread Tom Badran

On Monday 10 November 2003 19:54, Andrew Suffield wrote:
 Sometimes it even causes programs to stop functioning entirely
 (athlon and p4, gcc 3.0.0 until sometime in 3.1.x).

Especially on other architechtures (like arm) that have seen some horrific 
bugs creep into gcc to do with certain optimisations. There hasnt even been a 
good pipeline optimisation scheme until very recently in gcc, so any piplined 
architechture (read pretty much all) is even harder to work out wheter some 
cpu specific optimisation is _good_. Do people even understand how difficult 
it is to write an optimising compiler (and prove some optimisation actually 
works) for a complex architecture like the P4 or a modern powerPC chip?

Im getting sick of these arguments too and have to agree with Andrew on this 
one, this is getting old and boring and being argues by too many people who 
simply dont understand how modern processors and compilers work.

Tom

-- 
 ^__^| Tom Badran
 (oo)\__ | Imperial College
 (__)\   )\/\| Department of Computing
||w || ---
|| ||| Using Debian SID


pgps7ASy7ZpJa.pgp
Description: signature

Re: Library packages and their use

2003-11-10 Thread David Z Maze

[EMAIL PROTECTED] (Otto Wyss) writes:

 The discussion about the libc6-dev package and its headers let me to the
 impression that the Debian package structure isn't optimal for
 libraries. If anyone wants to build his own version of a package (i.e.
 libwxgtk2.4) he has to get all the dependent underlying dev packages as
 well. This is a long line of dependencies which mostly aren't wished and
 shouldn't be necessary.

Why is this a problem?  I don't really understand, for example, why
you want to recompile libraries, or what the problem is with needing
to have -dev packages installed to get header files for libraries.

 There are 3 kinds of dissimilar user groups of a package:
 1. Users just using a library linked to other packages

(...who don't want the header files, static libraries, or .so links;
they're just users.)

 2. Developers building packages which depends on a library package

(...who need the header files, etc.)

 3. Developers building his own version of this library package

I don't understand this category in particular.  Do you mean
maintainer?  Or do you really want to install home-built versions of
libraries?  Supporting home-built versions of system things (not just
libraries, but also things like MTAs) is something Debian has
traditionally been bad at; if I was going to optimize for this, I'd
probably use a BSD distribution over anything Linux-based.

 Currently group 1 just uses the normal packages while group 2 + 3 have
 both to use the dev packages. Especially for group 2 this isn't a good
 solution leading to a long line of unnecessary dependencies.

Again, what makes them unnecessary?  If myapp.c includes foo/foo.h,
and foo/foo.h includes bar/bar.h, then you can't compile myapp.c
without having bar/bar.h around, period.  Which means that, in the
Debian world, you need to have libbar-dev installed, even if myapp.c
doesn't include anything out of bar.h directly.

 Solution 1: Splitting the 2 packages into 3. Not very attractive, it
 will more confuse than improve the situation. Maybe the dbg packages
 could take over the role of the 3. group.

...what is the proposed split here?  All of your proposals are kind of
hand-wavy, and I really don't understand what you're getting at.

 Solution 2: Packages are changed that group 1 + 2 can use the normal
 packages and only group 3 uses the dev. That means the normal library
 packages contain enough so that other packages depending on this can be
 build.

That sounds like a proposal to get rid of -dev packages entirely.  Is
that what you're actually proposing?

 I'm not sure if any of the above solutions will improve the situation
 but we should all try to remove dependencies wherever possible.

Dependencies are bad?  Yeah, there are lots of ways to get around
them (static linking and the like) but they come with lots of costs
(binary bloat, need to rebuild every package when libc changes).

-- 
David Maze [EMAIL PROTECTED]  http://people.debian.org/~dmaze/
Theoretical politics is interesting.  Politicking should be illegal.
-- Abra Mitchell

possible compromise for ITP: linux?

2003-11-10 Thread Eike Sauer

Hello!

The discussion doesn't seem to be very productive any more.
Time to come to a compromise?

Obviously, Robert is not going to retreat.
He has put much time in posting already and hopefully will 
spend much more time in making a good package (if this is 
possible). So let him build his package.

OTOH, most people (publicly) stating anything about his ITP
had objections against the package as a whole or the name 
or missing features or other things.

What about letting Robert build and upload (if ftp-masters agree)
his package, *if* he puts it in experimental, uses a description
that contains a warning about the experimental status of the
package in a prominent place, and not calling it linux, but... 
(Robert, please choose. linux-tng, linux-experimental and other 
names have been proposed). If all works out fine and such packages 
eventually become the standard way of installing the linux kernel, 
the name could be changed then (as well as distrubution and description).
If it's not working, an important package name stays usable.

All who object on such packaging could help improve the package
- or show that it's not feasible - by testing it and filing 
(serious, fair) bug reports.

Just my 2 Euro cents,
Eike

-- 
Computer games don't affect kids; I mean if Pac-Man affected 
us as kids, we'd all be running around in darkened rooms, 
munching magic pills and listening to repetitive electronic music.
Kristian Wilson, Nintendo, Inc, 1989

Re: Why you are wrong [Was: On linux kernel packaging issue]

2003-11-10 Thread Glenn McGrath

A program that is CPU bound will benefit from compiler optimisations.

Compiler optimisation wont make any noticable improvment on largely IO
bound applications.

I was deliberatly speaking generally because it is a grey area, there
are very few practical programs that are completely CPU bound or
completely IO bound, compression certianly uses the CPU a lot, which
is why i used it as an example, and it was about 15 seconds faster.

I am not going to individually check every debian package just to give
you evidence and some sort of blanket statment covering all released
packages at a particualr instant in time.

You comments on compiler bugs are irrelevent, it is not debians role to
try and predict future compiler bugs, just to work around previous ones.

Other than exposing bugs (which is a good thing) compiler optimisations
do no harm.



Glenn

Re: Why you are wrong [Was: On linux kernel packaging issue]

2003-11-10 Thread Matt Zimmerman

On Tue, Nov 11, 2003 at 08:46:50AM +1100, Glenn McGrath wrote:

 A program that is CPU bound will benefit from compiler optimisations.

It is not wise to make generalizations about the effects of compiler
optimizations, because they vary widely from one chunk of code to the next.

 Other than exposing bugs (which is a good thing) compiler optimisations do
 no harm.

This is not a true statement.

-- 
 - mdz

using freedesktop.org libs

2003-11-10 Thread Anthraxz __

The freebsd developpers are making some changes to the XFree86 ports to 
reduce the pain associated with upgrading and maintaining XFree86.

http://www.freebsdforums.org/forums/showthread.php?threadid=16052
I found this idea very interesting. I think that the debian project should 
take more advantage of the freedesktop.org libs. I also think that it is a 
good moment to do some planification in order to work on more recent release 
of X.

Best Regards
_
MSN Messenger : discutez en direct avec vos amis !  
http://messenger.fr.msn.ca/

Re: Why you are wrong [Was: On linux kernel packaging issue]

2003-11-10 Thread Joe Wreschnig

On Mon, 2003-11-10 at 15:46, Glenn McGrath wrote:
 A program that is CPU bound will benefit from compiler optimisations.

A program that is CPU-bound *and* can be encoded more efficiently will
benefit from compiler optimizations. Some CPU bound things just aren't
going to be helped much by vectorization, instruction reordering, etc. I
mean, integer multiply is integer multiply.

 I am not going to individually check every debian package just to give
 you evidence and some sort of blanket statment covering all released
 packages at a particualr instant in time.

You don't need to check every Debian package; like you said yourself,
nothing that isn't CPU-bound is going to get helped at all. That cuts
out a whole lot of programs. Especially since this discussion involves
the Linux kernel, you only need to make your point for one program --
the Linux kernel.

 You comments on compiler bugs are irrelevent, it is not debians role to
 try and predict future compiler bugs, just to work around previous ones.

This sounds like the talk of someone who never got bit by a compiler
bug... I had a hell of a time when a number of Gentoo users compiled
broken glibc at one point (some combination of -O3 and i686); the only
thing that consistently failed on their systems was a piece of software
I wrote (and the minimal test cases I put together after being
completely confused for a few weeks).

Debugging compiler problems is *not fun*. They are incredibly difficult
to trace (pydance crashed generating arrow events, due to problems with
Python's floating point processing, due to problems with glibc that only
occurred on a handful of systems -- how quickly could you have figured
that out?) from the perspective of an application developer. They can be
incredibly difficult to fix from the perspective of a compiler
developer.

As for trying to predict future bugs, Debian does this all the time.
That's why we have things like the testing distribution. We know that
essentially all software has mistakes; we should try and mitigate the
damage from those mistakes as much as possible.

 Other than exposing bugs (which is a good thing) compiler optimisations
 do no harm.

Unless it rearranges the instructions so that they run slower through
common pipelines, e.g. optimizing for i586 seems to do this on Athlons
and P4s. Optimizations happen in both new instructions *and* new
instruction ordering; the former is usually upwards-compatible, but the
latter is not.
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

2003-11-10 Thread Carlos Sousa

On Mon, 10 Nov 2003 14:29:48 + Colin Watson wrote:

   The lurkers support me in email
   They all think I'm great don't you know.
   You posters just don't understand me
   But soon you will reap what you sow.
 
   Lurkers, lurkers, lurkers support me, you'll see, you'll see
   off in e-mail the lurkers support me, you'll see.
 
   Oh it's true, and you know they support me.
   There's thousands of lurkers out there!
   They all understand my intentions
   you posters are not being fair!
 
   Lurkers etc.
 
   The lurkers support me in email
   So why don't they post? you all cry
   They're scared of your hostile intentions
   they're not as courageous as I.
 
   Lurkers etc.
 
   One day I'll round up all my lurkers
   we'll have a newsgroup of our own
   without all this flak from you morons
   my lurkers will post round my throne.
 
   Lurkers etc.
 
 (credit to Jo Walton)

Do you happen to have the music for the lyrics?

-- 
Carlos Sousa
http://vbc.dyndns.org/

Re: Why you are wrong [Was: On linux kernel packaging issue]

2003-11-10 Thread Adam Heath

On Mon, 10 Nov 2003, Joe Wreschnig wrote:

 A program that is CPU-bound *and* can be encoded more efficiently will
 benefit from compiler optimizations. Some CPU bound things just aren't
 going to be helped much by vectorization, instruction reordering, etc. I
 mean, integer multiply is integer multiply.

But if the target cpu supports pipelining, and has multiple multiplication
units(which means it can do them in parallel), or can do a 128bit multiple, or
1 64 bit multiple, at once, then it's more efficient to do a partial loop
unroll, and thereby have faster code, because of more efficient parallization.

(sorry, read Dr. Dobbs last week).

Sarge-i386-1.iso via jigdo-lite

2003-11-10 Thread Otto Wyss

Currently there seems to be a problem with the Sarge-i386-1.jigdo file.
I tried to build/download a new CD but it complains 57 files where
missing. Even getting the .jigdo/.template files again or choosing
another mirror didn't help. The script can only be stopped so I don't
know how to proceed further.

O. Wyss

-- 
See http://wxguide.sourceforge.net/; for ideas how to design your app.

Re: Removal of LaTeX2HTML from main

2003-11-10 Thread Roland Stigge

Hi,

some additional info:

On Mon, 2003-11-10 at 16:54, Adrian Bunk wrote to #204684:
 after reading through #204684, I'd suggest a different approach for 
 latex2html:
 - move latex2html to non-free without renaming it
 - file RC bugs against packages in main build depending on latex2html
 
 Rationale:
 
 latex2html doesn't change it's name. As you said, your wrapper script 
 produces a different output, so a silent change isn't user-friendly.
 
 It will still take many months until Debian 3.1 will be released, and 
 a small number of usually easy to fix or at least easy to work around 
 bugs shouldn't do much harm.
 
 According to your list, only 5 packages need to be changed to use TeX4ht 
 and 6 packages might simply have to drop the build dependency. All the 
 other packages listed need under all circumstances manual intervention.
 IOW: Easy changes to 11 packages are needed, the bigger problems in
 25 other packages aren't affected by my proposal.

Good idea. My priority was to minimize the number of RC bugs. But
considering that the aforementioned additional RC bugs are the least
difficult ones (and they are still a small minority), I will possibly
follow your suggestion.

Thanks.

bye,
  Roland


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

Re: possible compromise for ITP: linux?

2003-11-10 Thread Lars Wirzenius

ma, 2003-11-10 kello 19:22, Eike Sauer kirjoitti:
 The discussion doesn't seem to be very productive any more.
 Time to come to a compromise?

Yes, please.

I am surprised at the vehemence at someone who dares do something new. I
don't care whether his approach is technically valid or not: as long as
he doesn't harm anyone, there's no point in preventing him. Mass
attacking someone who actually does things, and doesn't just rant and
whine, is quite horribly anti-productive.

-- 
http://liw.iki.fi/liw/photos/swordmaiden/

Re: Why you are wrong [Was: On linux kernel packaging issue]

2003-11-10 Thread Joe Wreschnig

On Mon, 2003-11-10 at 16:27, Adam Heath wrote:
 On Mon, 10 Nov 2003, Joe Wreschnig wrote:
 
  A program that is CPU-bound *and* can be encoded more efficiently will
  benefit from compiler optimizations. Some CPU bound things just aren't
  going to be helped much by vectorization, instruction reordering, etc. I
  mean, integer multiply is integer multiply.
 
 But if the target cpu supports pipelining, and has multiple multiplication
 units(which means it can do them in parallel), or can do a 128bit multiple, or
 1 64 bit multiple, at once, then it's more efficient to do a partial loop
 unroll, and thereby have faster code, because of more efficient parallization.
 
 (sorry, read Dr. Dobbs last week).

I knew someone would chime in with this. :) AIUI this is only possible
when there is no data dependency issue (i.e. multiply no. n+1 does not
depend on no. n), otherwise you still have to serialize them.

This is also a good example where optimizing for one chip might slow
another one; say you've got 2 multiplication units on chip A, but only 1
on chip B. You unroll the loop partially when compiling. On A, this
helps, because you can do both multiplies at once. On B, this may slow
it down because of greater icache usage from the unrolled loop, or
because B could be doing (e.g.) an add and a multiply but not two
multiplies.

Of course, I'm far from a compiler and chip design expert (or even
novice); this is what I remember from my classes last year. :) But it
shows how complicated optimizing compilers can get, and why you can't
say any optimization is always good/safe/faster/etc. The only truly safe
way to tell is extensive, controlled benchmarking.
-- 
Joe Wreschnig [EMAIL PROTECTED]


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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Mon, Nov 10, 2003 at 10:20:42PM +, Carlos Sousa wrote:
 On Mon, 10 Nov 2003 14:29:48 + Colin Watson wrote:
The lurkers support me in email
They all think I'm great don't you know.
You posters just don't understand me
But soon you will reap what you sow.
[...]
  (credit to Jo Walton)
 
 Do you happen to have the music for the lyrics?

It's a filk of My Bonnie Lies Over The Ocean; it's a very old song, so
I guess Google can probably find it fairly easily.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: possible compromise for ITP: linux?

On Mon, Nov 10, 2003 at 06:22:13PM +0100, Eike Sauer wrote:
 The discussion doesn't seem to be very productive any more.
 Time to come to a compromise?
 
 Obviously, Robert is not going to retreat.

He doesn't need to, he can be slapped down.

 OTOH, most people (publicly) stating anything about his ITP
 had objections against the package as a whole or the name 
 or missing features or other things.

This is a mischaracterisation. Debian developers are usually good at
avoiding making excessive duplicate comments; in this case, there were
a lot of minor issues and misfeatures, and a few showstoppers. Given
these two things together, you can expect to see more mails about the
minor issues, simply because it takes more eyes to spot them all. We
don't ignore minor issues just because there are major ones.

That doesn't excuse the showstoppers. These are two big ones, off the
top of my head:

 - this packages adds nothing, and would occupy a fair chunk of space
   in the archive. The advantages cited were rapidly debunked and no
   more were given.

 - this package cannot be safely upgraded (without forcing a reboot).

The latter prohibits it from being in a Debian release. The former
should keep it out of the archive entirely.

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


signature.asc
Description: Digital signature

Re: using freedesktop.org libs