Re: Bug#219507: ITP: gtkscintilla2 -- Gtk-2 wrappers for the Scintilla source editing components

[Joe Drew]

On Thu, 2003-11-06 at 19:23, Jonathan Oxer wrote:
> * Package name: gtkscintilla2
>   Description : Gtk-2 wrappers for the Scintilla source editing components

GTK+ is spelled with all CAPS and a "+" at the end. Also, I think you
can omit the "-2" - it is implied in the dependencies. (Also, I don't
think many people (if any!) are doing new development based on GTK 1.2.)

If you do decide to include the "2" information, however, don't say
GTK+-2; instead, "GTK+ 2.n" (where n is specified) or "GTK+ 2" (if it
doesn't care, which is hopefully the case).

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library

[Peter Palfrader]

On Thu, 06 Nov 2003, John Belmonte wrote:

> However in your package, assuming it is compiling GPL'd modules and 
> including them in the library, is producing an object file governed by 
> the terms of the GPL.  Therefore your license field should read only "GPL".

Last time I checked we didn't have License fields, so this discussion is
pointless.

Peter
-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/


signature.asc
Description: Digital signature

medieval horizontal

[Wyman Passamonti]

braze polyploidy accordions anabaptist testamentary tenebrous brains achiever mayst midweek booky televisions midget crabs talk blurted angora exacter meanest bookings messiahs polygonal mattress augustus illnesses icon say merciless talus medics $RANDO
MIZE miasma thanking pornographic taxicabs matchmake thanklessly exemplary andrea achievements postposition scribbles accounted adverbs thallophyte teleconference accidentally meridian bible mildly polling tasking scene millenia tell tags bogs benedictine memorizes activism tester $RANDOM
IZE adducting evolved councilwomen exalting tanks technologist crosstalk immaculately bluntly exclaiming pokerface scudding hotbox bologna tarantara taxes hostility biltmore memorizes creepy medlar
 


 posters adjusting euphorbia midwinter hungriest position migrates illume coveting mechanist horsepower adherents tawny blueprints cries hyena breaker husky brays postage illuminating almaden blum hundredth polemic math scratched season adopter brassiere $RANDOM
IZE banbury scaffolds alpert scraper bounding scat across bodice midshipmen bangor crisis methods sank bluet possemen illusionary terribly theme boxcar horselike ibex bottoming menace creosote archimedes adopt meaningless admirations merlin howdy $RANDOMI
ZE metallurgic satisfaction than tampon plowman bluefish sanding popularized bonding scoffing illegitimate cress schoolroom housewives tented tasteless craftiness expectedly pledge bluestocking taper

Re: Bug#217265 acknowledged by developer (Bug#217265: fixed in abiword 2.0.1+cvs.2003.11.07-1)

[Joe Drew]

reopen 217265
thanks

On Fri, 2003-11-07 at 00:18, Debian Bug Tracking System wrote:
>* New upstream release (CVS snapshot)
>   - Now uses STABLE branch - closes: #217265

No, please, use only *released* versions. I have been hurt many times by
AbiWord being broken because of something which is broken in CVS but
works in the latest released version.

If there is a specific, localized patch in any branch which fixes a bug,
by all means apply it. But please use *released* versions always as a
base.

-- 
Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

My weblog doesn't detail my personal life: http://me.woot.net

Trying to understand "updating orbit2 makes 79 packages unintallable ..."

[Joe Buck]

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

http://bjorn.haxx.se/debian/testing.pl?package=orbit2

I understand the problem in principle: there is/are some package/s that
needs the older version of orbit2, and the other "uninstallable"
packages depend on these.  Ideally, though, there should be a way
to figure out some minimal set of packages that is causing the
conflict, rather than displaying a set of 79 and a set of 50.

Is there any way to figure things like this out?  And is there any
way to fix Bjorn's script to show such problems more clearly?

Joe

Re: Bug#217265: acknowledged by developer (Bug#217265: fixed in abiword 2.0.1+cvs.2003.11.07-1)

[Masayuki Hatta]

severity 217265 wishlist
thanks

> In <[EMAIL PROTECTED]> 
>   Joe Drew <[EMAIL PROTECTED]> wrote:
> On Fri, 2003-11-07 at 00:18, Debian Bug Tracking System wrote:
> >* New upstream release (CVS snapshot)
> >   - Now uses STABLE branch - closes: #217265

> No, please, use only *released* versions. I have been hurt many times by
> AbiWord being broken because of something which is broken in CVS but
> works in the latest released version.

Hmm, the STABLE blanch is the latest released version + (sometimes
crucial) patches backported from the development blanch, so I don't
think it causes much problem anymore.

Regards,
MH

--
Masayuki Hatta
Graduate School of Economics, University of Tokyo
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
[EMAIL PROTECTED] / [EMAIL PROTECTED]

Re: Exec-Shield vs. PaX

[Henning Makholm]

Scripsit Yven Johannes Leist <[EMAIL PROTECTED]>

> Well, I for one would love to see a security announcement one day, which 
> contains something like: 
> 
> "All users running the standard Debian kernel are not affected, since the 
> special security features the Debian kernel contains prevent the 
> exploit/attack in question." :)

Hm, what I've been able to glean from the discussions seems to imply
that any software that's vulnerable to a remote access exploit
*without* the kernel-level protection in question, would still at
least be vulneable to a DoS attack, killing the server (or whatever)
process instead of giving the attacker actual control. So we'd still
want to provide security updates to the same extent as without.

-- 
Henning Makholm   "Hele toget raslede imens Sjælland fór forbi."

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

[Eduard Bloch]

#include 
* GOTO Masanori [Fri, Nov 07 2003, 01:43:15PM]:

> > Sorry, users will still ask.  They always ask.  Users still think that
> > updating /usr/include/linux to point to /usr/src/linux/include/linux is the
> > right thing to do.
> 
> And then, which package does provide /usr/src/linux directory?

Mh, missing smiley? Run "module-assistant prepare" once and you get it.

MfG
Eduard.

Re: Re: Re: Advices on choosing a documentation license for an upstreamproject

[Nathanael Nerode]

Joe Buck wrote, in 
http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00376.html:

The GPL requires that anyone who receives the work also either receives
the source for the work (the preferred form for making changes), or...
Not quite; it requires that anyone *given* the work is also *given* the 
source... as you note below, they can decline to take it.

>If he declines to take the
>source, he can't pass it on (unless he wants to sign up for the 
>three-year offer or somehow obtain the source).

Actually, the first sale doctrine applies.  He can pass it on, he just 
can't pass on a *copy*.

If he wants to pass on a copy, he can darn well find the source or the 
written offer (since he was offered one of them).

>You might want to add an exception to the GPL for your documentation,
>saying that a distributor is exempt from including source if they
>leave in a notice saying where on the web the latest source can be
>found, otherwise they must fully comply. The license would still be 
>GPL-compatible.

Perfectly reasonable exception, although I'd add that the distributor 
should guarantee that the source *can* be found on the web at that 
location for three years.  ;-)  Which gets us pretty close to the 
written offer again

Re: Bug#219277: ITP: gnusound -- Powerful sound editor

[Duck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Coin,

Gnusound is using OSS only.
Yet, afaik there's no plan to add Alsa/Esd/Arts/...  support.

The included TODO file reads that the upstream author is likely to fix
many technical and cosmetic bug before adding big features.

Duck
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE/q3MIsczZcpAmcIYRAiXHAJ0bw42qtykTvTHODAkiKJrtOwhXxwCfeFm/
6bhuUya/xkFLG3MKQcZzjT8=
=OgIr
-END PGP SIGNATURE-

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

[Colin Watson]

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,
> see
> 
> http://bjorn.haxx.se/debian/testing.pl?package=orbit2
> 
> I understand the problem in principle: there is/are some package/s that
> needs the older version of orbit2, and the other "uninstallable"
> packages depend on these.  Ideally, though, there should be a way
> to figure out some minimal set of packages that is causing the
> conflict, rather than displaying a set of 79 and a set of 50.
> 
> Is there any way to figure things like this out?  And is there any
> way to fix Bjorn's script to show such problems more clearly?

Right now, you figure this out by talking to the RM or one of his
assistants, I'm afraid; debian-release is a good contact address.
Björn's script just reformats the output of update_excuses.html and
update_output.txt, and making that more explanatory would take a good
deal more CPU power which isn't really available. (The script which
computes all this stuff is already very resource-intensive.)

Library changes often require what we call a "hint", where a human tells
the testing script to ignore the fact that e.g. orbit2 breaks lots of
things for a moment, and to see if going round and upgrading other
packages based on orbit2 will get the number of uninstallable packages
back down to the level it was before trying orbit2. This is very
difficult to automate because you might have to try hinting an arbitrary
number of packages at once which are all interdependent: five is the
highest number I've ever seen needed (lcms, libmng, libwmf, imagemagick,
plotutils).

Last I checked, which was a few days ago, the last piece needed to make
a hint for orbit2 work is to get the current version of nautilus to
build on m68k.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

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

[Jonathan Dowland]

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?

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

Re: binary patch

[Goswin von Brederlow]

Jonathan Oxer <[EMAIL PROTECTED]> writes:

> On Thu, 2003-11-06 at 10:50, Martin Pitt wrote:
> 
> > But isn't rsync supposed to do this? I don't know exactly how
> > efficiently it detects and compresses binary differences, but it
> > definitely does it and not too bad. With rsync, you get both the easy
> > management of complete debs and the bandwidth-saving of binary diffs.
> > The only problem is that apt does not support rsync IIRC, but this
> > could be solved by separately download the new debs into apt's cache
> > with a script using rsync.
> 
> Actually IIRC there was some work to make Apt support rsync. Goswin
> Brederlow was talking about adding it in Jan 2001. And a lot of mirrors
> actually are set up to support rsync.
>
> The problem is that most mirrors are loaded up pretty hard already, and
> if everyone started using rsync they'd probably melt.
> 
> So it's a tradeoff, bandwidth vs CPU. At the moment CPU seems to be the
> factor for mirror admins.

rsync has two problems for this:

1. gzip streams are pretty much uniq. A one character change in the
deb will create a completly different gzip stream (after that
character). The --rsyncable option for gzip tries to flush the gzip
dictionary at certain points so that rsync can catch on again.

2. rsync has a huge cpu and IO load on the servers. If every user
would use rsync the server would break down.


Several people, me including, have made rsync retrievers for apt with
various features but due to the two problems above it never got picked
up by the apt maintainer. In short rsync support is not wanted.

> 
> Cheers  :-)
> 
> Jonathan Oxer

Way back (somewhere in 2001 iirc) I suggested implementing cnysr
(rsync backwards), which is a rsync with reversed roles. The checksum
files for the server can then be precalculated and stored along the
debs (2% mirror increase with 1K block size, less for bigger blocks)
or calculated (and cached) on demand.

Since no calculation needs to be done at the server side any http 1.1
server has all the features (Range statement) needed for cnysr. This
means that any http debian mirror could directly be used without any
changes apart from the client.

I also did some tests on using checksums of the uncompressed data
along with checksums for the compressed data and a more complex
algorithm to simulate "rsyncing" the uncompressed data while only
serving the compressed files on the server. That works even better
than the --rsyncable patch to gzip but takes a lot of round-robins to
the server and back (takes time) and an increased checksum file (2-4%
mirror increase).

MfG
Goswin

Re: Bug#219277: ITP: gnusound -- Powerful sound editor

[Duck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Coin,

You'r right, "Powerful" is not adequate, i just took author's descriptionw 
without taking care of it.
I asked the author if it was possible to use it without gnome support and he 
said it was not, so i suggest this :
s/Powerful /gnome /

Proposed Description :
GNUsound is a gnome sound editor. It supports multiple tracks,
multichannel output, and 8, 16, or 24/32 bit samples. It can read
a number of audio formats, modify them, and saves them as WAV files.
GNUsound supports a large number of high-quality audio effects,
filters, and converters through the LADSPA plugin architecture (band pass
filter, frequency shifter, reverb, flanger, pitch scaler, pink noise,
stereo to mono converter, and many others).

Duck
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE/q3ydsczZcpAmcIYRAnUAAJ4+6bImG5bE/DtOb10iMq2Igcck6ACfc4Z2
QMc3LQ0XNdLDyOWcvnCDmpI=
=bEOJ
-END PGP SIGNATURE-

Re: Exec-Shield vs. PaX

[pageexec]

> "The test incorrectly assumes that thread stacks are executable" is not
> equivalent to "thread stacks are non-executable". And there's no conflict
> in what i say above.

ok, i was quoting too much and you interpreted the wrong part. the bit
i was referring to is this:

> I suspect we both agree that it's desirable to have thread stacks
> non-executable as well.

on one hand you acknowledge that it's better to have non-exec thread
stacks but on the other hand you argued that

> it's not a bugfix to break apps that rely on an executable stack - the
> stack _is_ executable.
  ^

as they say, you can't have it both ways.

> > also, the test does not only demonstrate that thread stacks are
> > executable or not, it demonstrates a fundemental design flaw in
> > Exec-Shield: whenever an executable region is created in the address
> > space, *everything* below that becomes executable as well. [...]
> 
> thanks, the cat is finally out of the bag - you admit here that the
> incriminating paxtest code is there to demonstrate what you characterise
> as a flaw in exec-shield.

the cat has always been out of the bag, way back in my very first mail
in this thread (and it's now the second time i've quoted this bit):

> Executable anonymous mapping : Vulnerable
> Executable bss   : Vulnerable
> Executable data  : Vulnerable
> Executable heap  : Vulnerable
> Executable stack : Vulnerable
> 
>   the above changes are the result of Ingo's approach to create
>   non-executable memory on i386, they're not per page as a simple
>   mprotect on the top of the stack shows. before i get accused of
>   specifically rigging the tests, i'll tell you that running
>   multithreaded apps would have almost the same effect (only the
>   main stack would stay non-exec under Exec-Shield). needless to
>   say, PaX passes all the above as before.

since you have such a problem with paxtest doing the explicit
mprotect() itself i decided to change it to a simple nested
function, it will achieve the same and hopefully satisfy you
as well.

> Note that none of your arguments tries to claim
> that any real application indeed does "mprotect(argv)", which is pretty
> telling by itself.

indeed. if you read my mails again (i'm getting tired of quoting
myself all over again), i told you explicitly what paxtest is for:
testing for regressions, situations when stuff fails. Exec-Shield
fails under the above mentioned situation. it also fails when gcc
nested functions are used, you'll see that in 0.9.6. i hope you
won't argue that no real application uses nested functions (and
before you object even to that, as you said yourself, nested functions
are just one way to trigger the heuristics in gcc, other code
constructs from real life would do the same as well).

> As i have explained it a hundred times, this behavior is a well-known
> property of exec-shield, and that we've done a quite good job of reducing
> this effect. In fact i've put it into my exec-shield announcement:

*none* of your public postings discusses the inherent problem with
memory regions becoming executable when something above them does.
the quote from your README talks about the ascii-armor region and
data being executable in there. it does not talk about how the main
application's data or the heap or even the entire stack can become
unexpectedly executable. on a related note, PT_GNU_STACK support
as implemented in Exec-Shield suffers from the same problem: you
make not only the stack executable but *everything* else below it,
i could not find a note from you talking about it.

> ( sorry, but i'm going to stop contributing to this thread. You are
> getting increasingly irrational and emotional, there's nothing more i
> could add to this thread. I do acknowledge that PaX is more secure, but i
> also say that exec-shield is a hell alot of a difference from a stock
> distro. You expressed your feelings that exec-shield is insecure in one
> area and apparently you conclude that it's thus useless. There's nothing i
> can do to change this irrational bad logic of yours. )

Ingo, if you read one of my previous posts, you will realize that
i did say that Exec-Shield was mostly good enough against current
exploit methods (which blindly expect their injected payload to be
executable). what it's not good enough for is protecting against
future attacks which will (because they can) adapt and circumvent
Exec-Shield in certain cases. this is not true for PaX and obviously
that decides what i'm going to use (and have been for all these
past 3 years). and finally on a personal note: you're quick to
call people by names, that's not professional especially when none
of the facts support your position.

---

i was not cc'd on this, but i'd still like to reply here:

Henning Makholm said:

> Hm, what I've been able

Re: Exec-Shield vs. PaX

[Cameron Patrick]

On Fri, Nov 07, 2003 at 12:15:06PM +0100, [EMAIL PROTECTED] wrote:

| > I suspect we both agree that it's desirable to have thread stacks
| > non-executable as well.
| 
| on one hand you acknowledge that it's better to have non-exec thread
| stacks but on the other hand you argued that
| 
| > it's not a bugfix to break apps that rely on an executable stack - the
| > stack _is_ executable.
|   ^
| 
| as they say, you can't have it both ways.

He's saying that there's no reason to have an executable stack for
programs which never attempt to execute code on the stack---and having a
non-executable stack in such circumstances gives you a security
advantage---but it is not okay for the operating system to break those
programs which /do/ rely on the stack being executable.

Now could you please stop wasting everybody's time by continuing this
thread?  Ingo has already stated that he won't continue arguing with
you, and I don't intend to continue posting in this thread after this
message either.

Cameron.

Re: ITP: ircd-ptlink -- IRC Server from PTlink

[Duck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


This ITP was badly written as it was my first attempt, sorry.
Here is a better one with an improved Description :

* Package name: ircd-ptlink
  Version : 2.23.6
  Upstream Author : PTlink Coders team <[EMAIL PROTECTED]>
* URL or Web page : http://www.ptlink.net/
* License : GPL
  Description : PTlink IRC server


ircd-ptlink provides an advanced IRC server, fast and reliable, 
with support for SSL client connections, ziplinks, halfops, advanced
channel modes (anti-spam, no nickchange, flood control, ...), sxlines,
and some other nice features.

Re: ITP: ircd-ptlink -- IRC Server from PTlink

[Duck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Coin,

This ITP was badly written as it was my first attempt, sorry.
Here is a better one with an improved Description :

* Package name: ircd-ptlink
  Version : 6.16.1
  Upstream Author : PTlink Coders team <[EMAIL PROTECTED]>
* URL or Web page : http://www.ptlink.net/
* License : GPL
  Description : PTlink IRC server

ircd-ptlink provides an advanced IRC server, fast and reliable,
with support for SSL client connections, ziplinks, halfops, advanced
channel modes (anti-spam, no nickchange, flood control, ...), sx-lines,
and some other nice features.

Bug#219575: ITP: sound-icons -- Sounds to be used for event signalization in speech enabled applications

[Milan Zamazal]

Package: wnpp
Severity: wishlist

* Package name: sound-icons
  Version : 0.1
  Upstream Author : Brailcom, o.p.s. <[EMAIL PROTECTED]>
* URL : http://www.freebsoft.org/pub/projects/sound-icons/
* License : GPL
  Description : Sounds to be used for event signalization in speech enabled 
applications

This package contains sound icons that are useful especially when running
Speech Dispatcher.

Re: Accepted vile 9.4-c1 (powerpc sparc i386 source all)

[Thomas Dickey]

In article <[EMAIL PROTECTED]> you wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1

> Format: 1.7
> Date: Thu,  6 Nov 2003 20:04:54 +1100
> Source: vile
> Binary: xvile vile-filters vile vile-common
> Architecture: all i386 powerpc source sparc 
> Version: 9.4-c1
> Distribution: unstable
> Urgency: low
> Maintainer: Brendan O'Dea <[EMAIL PROTECTED]>
> Changed-By: Brendan O'Dea <[EMAIL PROTECTED]>
> Description: 
>  vile   - VI Like Emacs - vi work-alike
>  vile-filters - VI Like Emacs - highlighting filters for vile/xvile
>  xvile  - VI Like Emacs - vi work-alike (X11)
> Changes: 
>  vile (9.4-c1) unstable; urgency=low

oh - my first reaction was startled that it didn't say "9.4c".

>  .
>* New upstream patch version.
>* Build filters as shared objects rather than executables.

I ran some tests seeing if I could use the same filters between vile/xvile,
and (surprisingly) it does seem to work.  That might simplify packaging.

>* Change build depends to specify flex-old due to problems with new

I did notice that (and have noticed new-flex upstream hasn't done anything
since May).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Re: Debconf in Brazil?

[Andre Filipe de Assuncao e Brito]

On Tue, 21 Oct 2003 09:13:46 -0200
Michelle Ribeiro <[EMAIL PROTECTED]> wrote:

> Em Mon, 20 Oct 2003 15:42:03 +0100
> Steve McIntyre <[EMAIL PROTECTED]> escreveu:
> 
> Hi, 
> 
> > Hmm, yes. Anyone speak Portuguese? :-)
> 
> 
> We are talking in english in the list. Fell free to join us. 

Hi
Me too! Nice to meet you!
> 
> Cheers, 
> 
> -- 
> --
> Michelle Ribeiro
> 
> Debian GNU/Linux - Your next Linux distribution
> http://www.debian.org/ || http://www.spi-inc.org/
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

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

[Robert Millan]

Package: wnpp
Severity: wishlist

* Package name: linux
  Version : 2.4.22
  Upstream Author : Linus Torvalds <[EMAIL PROTECTED]> and others, see:
http://www.kernel.org/pub/linux/kernel/CREDITS
* URL : http://www.kernel.org/
* License : GPL
  Description : Linux 2.4 kernel

Linux 2.4 kernel re-packaged as a standard Debian package. For details, see:

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

Package sources available in:

  http://people.debian.org/~rmh/linux/

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux aragorn 2.4.22 #1 dt nov 4 17:09:49 CET 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

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

[Ryan Underwood]

Hi,

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.

-- 
Ryan Underwood, <[EMAIL PROTECTED]>

Re: Bug#218832: ITP: libnettle -- a low-level cryptographic library

[John Belmonte]

Peter Palfrader wrote:
Last time I checked we didn't have License fields, so this discussion is
pointless.
Indeed, I was imagining some other world.  In any case, I'd assume that 
the license field of the ITP is going to reflect the contents of the 
package copyright file.


--
http:// if  ile.o g/

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

[Marcelo E. Magallon]

On Fri, Nov 07, 2003 at 02:37:35PM +0100, Robert Millan wrote:

 > * Package name: linux
 >   Version : 2.4.22
 >   Upstream Author : Linus Torvalds <[EMAIL PROTECTED]> and others, see:
 > http://www.kernel.org/pub/linux/kernel/CREDITS
 > * URL : http://www.kernel.org/
 > * License : GPL
 >   Description : Linux 2.4 kernel
 > 
 > Linux 2.4 kernel re-packaged as a standard Debian package. For details, see:
 > 
 >   http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00204.html

 I object.

 As an academic exercise this is fine and dandy, but having two
 competing packagings of the same _basic_ component can't do us any
 good.  If you have a problem with the way kernel packages are handled
 (upgrades in particular, which seems to be your problem), go talk with
 the official kernel image packages maintainer and work something out.
 This creates _more_ work for everybody.  What do you want to do with
 binaries of kernel modules?  Have more duplication of effort?

 Marcelo

buildd dpkg was interrupted

[Paul Telford]

One of my packages just failed to build on m68k with the message:

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct 
the problem. 


I noticed that a couple of other packages on this arch have also just 
failed to build with the same message.  Does the buildd require manual 
attention, or is my package broken?  My package log is: 
http://buildd.debian.org/build.php?&pkg=digikam&ver=0.5.1-1&arch=m68k

Thanks,


 Paul.

--
Paul Telford | 1024D/431B38BA | [EMAIL PROTECTED] | [EMAIL PROTECTED]
   C903 0E85 9AF5 1B80 6A5F  F169 D7E9 4363 431B 38BA

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

[Robert Millan]

Hi!

I think you haven't read my previous mail:

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

Please have a look at it, my response below assumes you did.

On Fri, Nov 07, 2003 at 08:56:38AM -0600, Marcelo E. Magallon wrote:
> 
>  As an academic exercise this is fine and dandy, but having two
>  competing packagings of the same _basic_ component can't do us any
>  good.

This isn't a "competing" package. As I said before, the standard way Linux
kernel packaging is handled is "a good choice for the power user". I don't
intend to "replace" it or the like, just add more options for the people who
like them.

>  If you have a problem with the way kernel packages are handled
>  (upgrades in particular, which seems to be your problem), go talk with
>  the official kernel image packages maintainer and work something out.

If I had a "problem" with some package, I'd use the BTS or speak with the
maintainer. This is not the case here. As explained before, my package
build-depends on "kernel-patch-debian" and uses the standard patchset in
that package. Rather than "duplicating work", it is "building on top of
existing work".

When I announced it (previous mail), Herbert Xu was on CC. He's the maintainer
of "kernel-patch-debian" which does the real work for this package. My package
is simply an extension for Herbert's work. I don't know wether he's interested
or not in this extension, but I do obviously welcome his participation.

>  This creates _more_ work for everybody.

Who is "everybody" (asides Linux kernel module maintainers)?

>  What do you want to do with
>  binaries of kernel modules?  Have more duplication of effort?

That's up to the module maintainers. Adding support for the Linux kernel when
packaged as a standard Debian package is easy for them, since in packaging
terms it's not much different than linking your package against a library.

Certainly, if they choose to "duplicate effort" and support both alternatives,
that will prove me right in the fact that both of them are interesting for the
end user.

-- 
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: buildd dpkg was interrupted

[Wouter Verhelst]

Op vr 07-11-2003, om 17:21 schreef Paul Telford:
> One of my packages just failed to build on m68k with the message:
> 
> E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to 
> correct the problem. 

That's kullervo.

> I noticed that a couple of other packages on this arch have also just 
> failed to build with the same message.  Does the buildd require manual 
> attention, or is my package broken?

It's the buildd, obviously. No need to worry, I'm sure Roman will fix
this ASAP :)

>   My package log is: 
> http://buildd.debian.org/build.php?&pkg=digikam&ver=0.5.1-1&arch=m68k

-- 
Wouter Verhelst
BVBA NixSys
Louizastraat 15, 2800 Mechelen
+32 15 27 69 50


signature.asc
Description: Dit berichtdeel is digitaal ondertekend

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

[Michael Poole]

Robert Millan <[EMAIL PROTECTED]> writes:

> On Fri, Nov 07, 2003 at 08:56:38AM -0600, Marcelo E. Magallon wrote:
>> 
>>  As an academic exercise this is fine and dandy, but having two
>>  competing packagings of the same _basic_ component can't do us any
>>  good.
>
> This isn't a "competing" package. As I said before, the standard way Linux
> kernel packaging is handled is "a good choice for the power user". I don't
> intend to "replace" it or the like, just add more options for the people who
> like them.

Having options for the sake of having options is, frankly, a hideously
stupid design doctrine.  Whose life will this package make easier?  As
a user, I have never been confused by Debian's "normal" Linux kernel
packages.  What specific benefits would your proposed package offer?

Michael Poole

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

[Andreas Metzler]

On Fri, Nov 07, 2003 at 05:22:08PM +0100, Robert Millan wrote:
[another version of the linux-kernel in tha archive]
> I think you haven't read my previous mail:
> 
>   http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00204.html
> 
> Please have a look at it, my response below assumes you did.
> 


a good choice for the power user, who typicaly wants to re-compile Linux
perself, apply per's own set of patches, etc. However, I feel that an option
for newbie users to "install & forget" just like we do for every Debian
package is missing for what the Linux kernel is concerned.


I don't understand. How is your solution better than
*prompt* apt-get install kernel-image-2.4-386?

I also object this ITP.
   cu andreas

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Joel Baker]

On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
> On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote: 
> > I'm in two minds whether or not to ask this, but I've been wondering
> > about the naming scheme for linux packages - kernel-*. Why not
> > linux-kernel-* or linux-* ? If alternative kernels in debian become
> > more popular, is there a potential for confusion in the future?
> 
> Surely these won't all show up in the same Packages file...if you're
> running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the
> Linux and Hurd kernels even be in the list?

*-kernel-image-* is a binary image, and should, of course, have an
appropriate architecture (or tagging, if we ever move to that). However,
*-kernel-source-*, *-kernel-headers-*, and *-kernel-doc-* (off the top
of my head) are all Arch: all, or at least potentially so, since they're
non-binary data that could (arguably) be useful across the board (even on
other kernels, since cross-compiling a kernel is often a supported concept,
even if userland is far nastier as a rule).

Certainly 'netbsd-kernel-source-*' will be Arch: all, even if the package
one uses to build them (the equivalent of kernel-package, also a candidate
for renaming if it comes to pass) is arch-specific.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgpabHx6Zuzrl.pgp
Description: PGP signature

some packages from incoming are not going into sid

[Noèl Köthe]

Hello,

is there any reason why packages, which are already accepted and now are
in incoming.d.o are not moving to the archives?

for example http://incoming.debian.org/wget_1.9-1_m68k.deb is there
since 2003-11-04.
Other packages like xmule or webmin are having the same "problem".

Whats the problem?

thx.

-- 
NoÃl KÃthe 
Debian GNU/Linux, www.debian.org


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: some packages from incoming are not going into sid

[Jaldhar H. Vyas]

On Fri, 7 Nov 2003, Noèl Köthe wrote:

> Hello,
>
> is there any reason why packages, which are already accepted and now are
> in incoming.d.o are not moving to the archives?
>
> for example http://incoming.debian.org/wget_1.9-1_m68k.deb is there
> since 2003-11-04.
> Other packages like xmule or webmin are having the same "problem".
>

Most of webmin went in yesterday.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Re: some packages from incoming are not going into sid

[James Troup]

Noèl Köthe <[EMAIL PROTECTED]> writes:

> is there any reason why packages, which are already accepted and now are
> in incoming.d.o are not moving to the archives?
>
> for example http://incoming.debian.org/wget_1.9-1_m68k.deb is there
> since 2003-11-04.
> Other packages like xmule or webmin are having the same "problem".

It was a bug in 'kelly' triggered by a recent scsh upload.  Anything
alphabetically after that wasn't being processed.  The bug has been
fixed and everything should be processed as normal tonight.

-- 
James

Re: some packages from incoming are not going into sid

[Santiago Vila]

On Fri, 7 Nov 2003, Noèl Köthe wrote:

> is there any reason why packages, which are already accepted and now are
> in incoming.d.o are not moving to the archives?
>
> for example http://incoming.debian.org/wget_1.9-1_m68k.deb is there
> since 2003-11-04.

That's because wget starts with "w".

> Other packages like xmule or webmin are having the same "problem".

That's because their names start with "x" and "w".

> Whats the problem?

I don't know, but 18 packages for hurd-i386 which I uploaded yesterday
with initials from "s" to "x" are not in the archive yet either.

Seems like an alphabetical conspiration from katie.

Bug#219631: ITP: multi-aterm -- X terminal emulator with multiple tabbed sessions

[Michael Mayer]

Package: wnpp
Version: unavailable; reported 2003-11-07
Severity: wishlist


* Package name: multi-aterm
  Version : 0.0.5
  Upstream Author : Alexis <[EMAIL PROTECTED]>
* URL : http://www.materm.tuxfamily.org/materm.html
* License : GPL
  Description : X terminal emulator with multiple tabbed sessions

 Multi-aterm is a small and fast terminal emulator with efficent pseudo
 transparency, like aterm. It is a tabbed terminal emulator like GMT
 (gnome-multi-terminal). It does not require GNOME or KDE libs, just
 written in X-lib (for people not using GNOME nor KDE).

 I'm already done with packaging and now I'm looking for a sponsor.
 The upstream version 0.0.5 is getting really useable and very well
 suited for my personal needs.

 For download use
 deb http://mentors.debian.net/debian unstable main contrib non-free
 deb-src http://mentors.debian.net/debian unstable main contrib non-free

 If you are interesting in beeing my sponsor please contact me:
 Michael Mayer <[EMAIL PROTECTED]>

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux ernie 2.4.22mm1 #1 Sa Nov 1 22:33:39 CET 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set)

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

[Santiago Vila]

On Fri, 7 Nov 2003, Michael Poole wrote:

> As a user, I have never been confused by Debian's "normal" Linux
> kernel packages.  What specific benefits would your proposed package
> offer?

At least, the ability to do

apt-get source linux

as it should always have been.


I think it's time we put an end to this euphemism called "the kernel"
and start calling it by its proper name (if we refer to Linux, that is).

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

[Robert Millan]

[ Please keep CC to [EMAIL PROTECTED] ]

On Fri, Nov 07, 2003 at 11:57:28AM -0500, Michael Poole wrote:
> 
> Having options for the sake of having options is, frankly, a hideously
> stupid design doctrine.  Whose life will this package make easier?  As
> a user, I have never been confused by Debian's "normal" Linux kernel
> packages.  What specific benefits would your proposed package offer?

There are (at least) the following benefits:

 - 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. In my apt database, there are 136 packages that match "kernel-*",
   from which 19 are "kernel-image-*", 7 are "kernel-source-*", 14 are
   "kernel-headers-*", and 70 are "kernel-patch-*".

  - Handled by autobuilders, which means new versions are compiled automaticaly
for all Debian architectures. Normaly, users of non-i386 would have to
wait untill a maintainer for each port compiles it manualy for their CPU.

This is specialy important for security updates. Remember DSA-358 and
DSA-336, for which the security team had to build the Linux kernel manualy
for all our architectures, delaying the advisory?

 - Automatical major updates (the x in 2.x.y). When 2.6 is suitable to be
   the default version, a simple change in -defaults package (ala gcc) would
   enforce updating on all existing systems that use this method. This prevents
   us from encountering ABI incompatibility problems, like this recent one in
   Glibc:
 #215010: Illegal instruction with 2.2 kernel

   This is not unusual. IIRC, Woody's Glibc wasn't supported by Linux 2.0 (I
   once tried an upgrade from Slink after the Woody release)

   Note: as pointed by Andreas, this doesn't apply to minor updates

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

[Eduard Bloch]

#include 
* Robert Millan [Fri, Nov 07 2003, 02:37:35PM]:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: linux
>   Version : 2.4.22
>   Upstream Author : Linus Torvalds <[EMAIL PROTECTED]> and others, see:
> http://www.kernel.org/pub/linux/kernel/CREDITS
> * URL : http://www.kernel.org/
> * License : GPL
>   Description : Linux 2.4 kernel
> 
> Linux 2.4 kernel re-packaged as a standard Debian package. For details, see:

Before you do any such things, please ask whether anybody has more
important things to change on the kernel packagement. And, believe me,
there are ideas for the post-Herbert era.

And now make you ready for the stupid flamewar that I expect to follow
RSN.

MfG,
Eduard.
-- 
Kommt der Knecht mit Chorgesang, sucht die Magd den Notausgang.

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

[Robert Millan]

Hi Eduard,

On Fri, Nov 07, 2003 at 05:58:36PM +0100, Eduard Bloch wrote:
> 
> Before you do any such things, please ask whether anybody has more
> important things to change on the kernel packagement. And, believe me,
> there are ideas for the post-Herbert era.
> 
> And now make you ready for the stupid flamewar that I expect to follow
> RSN.

I welcome all feedback (specialy, positive feedback!). So if you or anyone has
suggestions, I'm waiting for them.

As for the "post-Herbert" era, I think it's not accurate.. Herbert is the real
maintainer behind my package, he provides the Debian patchset from
"kernel-patch-debian", although the actual packaging is done completely
differently.

I'd specialy appreciate (positive) feedback from Herbert, actualy.

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

[Robert Millan]

On Fri, Nov 07, 2003 at 06:12:20PM +0100, Andreas Metzler wrote:
> 
> 
> a good choice for the power user, who typicaly wants to re-compile Linux
> perself, apply per's own set of patches, etc. However, I feel that an option
> for newbie users to "install & forget" just like we do for every Debian
> package is missing for what the Linux kernel is concerned.
> 
> 
> I don't understand. How is your solution better than
> *prompt* apt-get install kernel-image-2.4-386?

See my other mail (in response to Michael Poole).

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

[Daniel Jacobowitz]

On Fri, Nov 07, 2003 at 08:19:23PM +0100, Robert Millan wrote:
> 
> [ Please keep CC to [EMAIL PROTECTED] ]
> 
> On Fri, Nov 07, 2003 at 11:57:28AM -0500, Michael Poole wrote:
> > 
> > Having options for the sake of having options is, frankly, a hideously
> > stupid design doctrine.  Whose life will this package make easier?  As
> > a user, I have never been confused by Debian's "normal" Linux kernel
> > packages.  What specific benefits would your proposed package offer?
> 
> There are (at least) the following benefits:
> 
>  - 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. In my apt database, there are 136 packages that match 
> "kernel-*",
>from which 19 are "kernel-image-*", 7 are "kernel-source-*", 14 are
>"kernel-headers-*", and 70 are "kernel-patch-*".

You have not obsoleted any of the kernel patch packages.

>   - Handled by autobuilders, which means new versions are compiled 
> automaticaly
> for all Debian architectures. Normaly, users of non-i386 would have to
> wait untill a maintainer for each port compiles it manualy for their CPU.
> 
> This is specialy important for security updates. Remember DSA-358 and
> DSA-336, for which the security team had to build the Linux kernel manualy
> for all our architectures, delaying the advisory?

Have you perhaps noticed that the kernels from every architecture build
from different source packages?  Why don't you spend a little time
working out why this is so, what the issues are with trying to do it
from one package, and why we don't do that already?

>  - Automatical major updates (the x in 2.x.y). When 2.6 is suitable to be
>the default version, a simple change in -defaults package (ala gcc) would
>enforce updating on all existing systems that use this method. This 
> prevents
>us from encountering ABI incompatibility problems, like this recent one in
>Glibc:
>  #215010: Illegal instruction with 2.2 kernel
> 
>This is not unusual. IIRC, Woody's Glibc wasn't supported by Linux 2.0 (I
>once tried an upgrade from Slink after the Woody release)

I fail to see how a bug in the 2.2 kernel, triggered by a recent glibc
update, dictates anything at all.  A substantial portion of Debian
users won't run the kernel we supply anyway, no matter how we choose to
supply it.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

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

[Michael Poole]

Robert Millan <[EMAIL PROTECTED]> writes:

> There are (at least) the following benefits:
>
>  - 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. In my apt database, there are 136 packages that match 
> "kernel-*",
>from which 19 are "kernel-image-*", 7 are "kernel-source-*", 14 are
>"kernel-headers-*", and 70 are "kernel-patch-*".

This is a meaningless observation in the context of how the package
should be structured.

Out of those 19 kernel-image-* packages and more kernel-module*
packages, how many would go away with your proposal?  Do you offer
some way to address the binary incompatibility between variants of one
architecture -- for example, 386 vs 686 SMP vs AMD-64 kernels?

Out of the 70 kernel-patch-* files, how many would go away?  How will
you resolve the conflicts and functional overlap between patches like
kgdb, grsecurity, lsm, etc?

There are many packages because they address different users' needs.
So far I have seen only handwaving and hope to suggest the number or
complexity will be reduced in practice.

>   - Handled by autobuilders, which means new versions are compiled 
> automaticaly
> for all Debian architectures. Normaly, users of non-i386 would have to
> wait untill a maintainer for each port compiles it manualy for their CPU.
>
> This is specialy important for security updates. Remember DSA-358 and
> DSA-336, for which the security team had to build the Linux kernel manualy
> for all our architectures, delaying the advisory?

Non-i386 users regularly get burned by upstream bugs.  Is it really a
good idea to automatically extend that to Debian's users?  There was
just a heated discussion about the desirability of autobuilding
packages, and if I recall correctly, the consensus was that
maintainers should build *and test* their packages before inflicting
them on unstable.

This becomes even more of an issue if you start throwing more patches
into a common source package, since those patch maintainers will
generally have only one or two architectures to test on.

>  - Automatical major updates (the x in 2.x.y). When 2.6 is suitable to be
>the default version, a simple change in -defaults package (ala gcc) would
>enforce updating on all existing systems that use this method. This 
> prevents
>us from encountering ABI incompatibility problems, like this recent one in
>Glibc:
>  #215010: Illegal instruction with 2.2 kernel
>
>This is not unusual. IIRC, Woody's Glibc wasn't supported by Linux 2.0 (I
>once tried an upgrade from Slink after the Woody release)
>
>Note: as pointed by Andreas, this doesn't apply to minor updates

It seems like those could be solved with a simple virtual package
provided by kernel packages.  This is one case where versioned virtual
depends would be useful.  Having all versions of the kernel use the
same package name, though, will be error-prone during reboots.  How
would I have both linux-kernel-${old} and linux-kernel-${new}
installed and bootable, so that I have at least one known working
kernel?  It is easy to roll back standard packages (except, perhaps,
dpkg).  It is not so easy to roll back the kernel.

Michael

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

[Robert Millan]

On Fri, Nov 07, 2003 at 03:00:26PM -0500, Daniel Jacobowitz wrote:
> 
> You have not obsoleted any of the kernel patch packages.

It's not my intention to obsolete anything, but whenever I have to add my own
patches they will be in debian/patches directory where people expect them to
be, not in a separate binary.

You're getting out of the point, though. The confusion I explained would still
remain without the "kernel-patch-*" packages.

> Have you perhaps noticed that the kernels from every architecture build
> from different source packages?  Why don't you spend a little time
> working out why this is so, what the issues are with trying to do it
> from one package, and why we don't do that already?

I haven't noticed, so thanks for pointing this out. The fix is trivial, btw.

> >Glibc:
> >  #215010: Illegal instruction with 2.2 kernel
> > 
> >This is not unusual. IIRC, Woody's Glibc wasn't supported by Linux 2.0 (I
> >once tried an upgrade from Slink after the Woody release)
> 
> I fail to see how a bug in the 2.2 kernel, triggered by a recent glibc
> update, dictates anything at all.  A substantial portion of Debian
> users won't run the kernel we supply anyway, no matter how we choose to
> supply it.

Indeed. And the point is: a small portion will run my package and will be safe
from hitting this sort of bugs.

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

[Daniel Jacobowitz]

On Fri, Nov 07, 2003 at 09:32:02PM +0100, Robert Millan wrote:
> On Fri, Nov 07, 2003 at 03:00:26PM -0500, Daniel Jacobowitz wrote:
> > Have you perhaps noticed that the kernels from every architecture build
> > from different source packages?  Why don't you spend a little time
> > working out why this is so, what the issues are with trying to do it
> > from one package, and why we don't do that already?
> 
> I haven't noticed, so thanks for pointing this out. The fix is trivial, btw.

If you think that, then you don't understand why they are all built
separately.

They all require different patches.

They all require different kernel versions, in general.

They all require different binaries to be shipped and different tools
to be used to build them.

And suggesting autobuilding kernels for an architecture other than the
one the maintainer tests them on seems like an extremely bad idea.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

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

[Andrew Suffield]

On Fri, Nov 07, 2003 at 09:32:02PM +0100, Robert Millan wrote:
> > Have you perhaps noticed that the kernels from every architecture build
> > from different source packages?  Why don't you spend a little time
> > working out why this is so, what the issues are with trying to do it
> > from one package, and why we don't do that already?
> 
> I haven't noticed, so thanks for pointing this out. The fix is trivial, btw.

No, the fix is a fucking huge amount of work, which is why nobody has
done it before, even for the upstream kernel.

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


signature.asc
Description: Digital signature

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

[Otto Wyss]

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

O. Wyss

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

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

[Robert Millan]

On Fri, Nov 07, 2003 at 03:19:20PM -0500, Michael Poole wrote:
> 
> This is a meaningless observation in the context of how the package
> should be structured.

You said before:
  "I have never been confused by Debian's \"normal\" Linux kernel packages."

I understand the confusion in the current structure is not meaningful to you,
but that doesn't mean it isn't meaningful for people who are actualy still
confused with it (like me).

> Out of those 19 kernel-image-* packages and more kernel-module*
> packages, how many would go away with your proposal?

All but two: linux and linux-2.4 (which are actualy the same thing. I.e:
installing one will bring the other).

(I assume by "go away" you mean "not use in your package", since I don't intend
to replace the current package set.)

> Do you offer
> some way to address the binary incompatibility between variants of one
> architecture -- for example, 386 vs 686 SMP vs AMD-64 kernels?

No, I compile without optimisation.

> Out of the 70 kernel-patch-* files, how many would go away?

All but those I Build-Depend on (i.e, -debian-* and the arch-specific patches).

> How will
> you resolve the conflicts and functional overlap between patches like
> kgdb, grsecurity, lsm, etc?

I won't. There's a reason why they're not in kernel-patch-debian.

> There are many packages because they address different users' needs.
> So far I have seen only handwaving and hope to suggest the number or
> complexity will be reduced in practice.

As I said before, my package is not targeted at "power users" who compile their
own Linux kernels, apply their preferred patches, optimise for their CPU, etc..

So if you're one of such users, just don't use my package.

> Non-i386 users regularly get burned by upstream bugs.  Is it really a
> good idea to automatically extend that to Debian's users?  There was
> just a heated discussion about the desirability of autobuilding
> packages, and if I recall correctly, the consensus was that
> maintainers should build *and test* their packages before inflicting
> them on unstable.

As a maintainer, I test all my packages on i386 before uploading on unstable. I
don't test them on non-i386 unless there's a special reason to do so, and don't
plan to do it regularly untill I own a non-i386 box myself.

However, this is offtopic on this discussion.

> It seems like those could be solved with a simple virtual package
> provided by kernel packages.  This is one case where versioned virtual
> depends would be useful.  Having all versions of the kernel use the
> same package name, though, will be error-prone during reboots.  How
> would I have both linux-kernel-${old} and linux-kernel-${new}
> installed and bootable, so that I have at least one known working
> kernel?  It is easy to roll back standard packages (except, perhaps,
> dpkg).  It is not so easy to roll back the kernel.

I don't see why should I address that. The same happens when you update your
bootloader, or sysvinit, or coreutils, glibc, etc.

My advice: Have a rescue disk at hand.

-- 
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: rename linux-kernel-headers to system-headers

[Adam Heath]

On Fri, 7 Nov 2003, GOTO Masanori wrote:

> And then, which package does provide /usr/src/linux directory?

none should.

debian-devel@lists.debian.org

[JWinters]

 
-Original Message-From: Kerri Bowman 
[mailto:[EMAIL PROTECTED]Sent: Friday, November 07, 2003 
2:48 PMTo: [EMAIL PROTECTED]Subject: Half Priced 
Viag&ra

FW: Inventory Count Test

[JWinters]

>  -Original Message-
> From: Wagner,Kirby,GREENWICH,SAP Team  
> Sent: Wednesday, November 05, 2003 11:10 AM
> To:   Winters,John,GREENWICH,Information Services
> Cc:   Halliday,Steve,GREENWICH,Information Services
> Subject:  RE: Inventory Count Test
> 
> John,
> Please e-mail below from Danielle Baccaglini showing the layout set and
> path name for RMS data to be used in the Route FG Shrink Auto Upload
> Report.
> 
> Kirby Wagner
> Nestlé Waters North America Inc.
> SAP Solutions Analyst
> (203) 629-7489
> 
>  -Original Message-
> From: Halliday,Steve,GREENWICH,Information Services  
> Sent: Wednesday, November 05, 2003 8:50 AM
> To:   Wagner,Kirby,GREENWICH,SAP Team
> Subject:  RE: Inventory Count Test
> 
> The shrink program.  Please let who ever is working on it know it is out
> there and forward the email.
> 
>-Original Message-
>   From:   Wagner,Kirby,GREENWICH,SAP Team  
>   Sent:   Tuesday, November 04, 2003 4:36 PM
>   To: Halliday,Steve,GREENWICH,Information Services
>   Subject:RE: Inventory Count Test
> 
>   What is this for?
> 
>   Kirby Wagner
>   Nestlé Waters North America Inc.
>   SAP Solutions Analyst
>   (203) 629-7489
> 
>-Original Message-
>   From:   Baccaglini,Danielle,GREENWICH,Information Services  
>   Sent:   Tuesday, November 04, 2003 2:14 PM
>   To: Halliday,Steve,GREENWICH,Information Services;
> Wagner,Kirby,GREENWICH,SAP Team
>   Cc: Stronge,William,GREENWICH,Information Services
>   Subject:Inventory Count Test
> 
>   Steve and Kirby,
> 
>   I updated our test machine with data for October's EOM and
> ran a test for the Ozarka database.
> 
>   The name of the file is 'ozk_invcnt.dat' and I put it in the
> /INTERFACES/DV3/in/RMS directory.
>   The file is fixed length and the layout is as follows:
>   Field Name  Justification   Length
> Format
>   EOM  Date   Left8
> MMDD
>   Plant   Left4
>   Prod Code   Left3
>   Mat Num Left10
>   Count   Right   13
> 
>   Let me know how it looks and when you are ready for further
> testing.
> 
>   Thanks,
>   Danielle Baccaglini
>   x0233
> 
> 

FW: Resolved Deduction Report

[JWinters]

>  -Original Message-
> From: Bryant,Susan,GREENWICH,Information Services  
> Sent: Tuesday, November 04, 2003 1:24 PM
> To:   Winters,John,GREENWICH,Information Services
> Subject:  RE: Resolved Deduction Report
> 
> Thanks for confirming.  I think we will just leave it lie unless someone
> else complains.  I had just never seen these results before.  
> 
> 
>  -Original Message-
> From: Winters,John,GREENWICH,Information Services  
> Sent: Tuesday, November 04, 2003 1:22 PM
> To:   Bryant,Susan,GREENWICH,Information Services;
> Melody,Thomas,GREENWICH,Information Services
> Cc:   Daley,Tom,GREENWICH,Information Services
> Subject:  RE: Resolved Deduction Report
> 
> You are correct - it is not finding any RV documents and is bypassing the
> Customer and Hierarchy read routines.
> 
>  -Original Message-
> From: Bryant,Susan,GREENWICH,Information Services  
> Sent: Tuesday, November 04, 2003 1:19 PM
> To:   Winters,John,GREENWICH,Information Services;
> Melody,Thomas,GREENWICH,Information Services
> Cc:   Daley,Tom,GREENWICH,Information Services
> Subject:  RE: Resolved Deduction Report
> 
> I've figured it out.  When the only deductions that are cleared are those
> cleared through FI rather than SD then for some reason the program does
> not hit the section where name texts are brought in.  This is not perfect
> but no one in the field has had an issue with it yet (it's been like this
> for over 2 years).  The only time this will happen is in the first couple
> of days of the month when Unearned Cash Discounts and Ded below the ded
> tolerance are cleared.  In the past months when I've run this in the first
> three days, there has always been at least one SD document which makes the
> program hit the section that pulls in names.  In the perfect world, they
> wouldn't clear anything in the first couple of days (deduction activity is
> supposed to be frozen) but this never happens.  
> 
> At this point I don't think we need to change anything.  With this report
> we can do more harm than good sometimes.  We may want to look at it when
> we make adjustments with the new unauthorized deduction project.
> 
> Thanks.
> Sue
> 
>-Original Message-
>   From:   Winters,John,GREENWICH,Information Services  
>   Sent:   Tuesday, November 04, 2003 10:33 AM
>   To: Melody,Thomas,GREENWICH,Information Services;
> Bryant,Susan,GREENWICH,Information Services
>   Cc: Daley,Tom,GREENWICH,Information Services
>   Subject:RE: Resolved Deduction Report
> 
>   Fortunately or Unfortunately - nothing has changed. This is the only
> version of the program.
> 
>-Original Message-
>   From:   Melody,Thomas,GREENWICH,Information Services  
>   Sent:   Monday, November 03, 2003 5:06 PM
>   To: Bryant,Susan,GREENWICH,Information Services;
> Winters,John,GREENWICH,Information Services
>   Cc: Daley,Tom,GREENWICH,Information Services
>   Subject:FW: Resolved Deduction Report
> 
> 
> 
>   Sue,
> 
>   We may have inadvertently caused an issue here with our change to
> the download program.
>   I am assigning this program to John with top priority to implement
> the new Z_NWNA_DOWNLOAD ,
>   and make sure this issue is corrected.
> 
>   Tom
> 
> 
>-Original Message-
>   From:   Bryant,Susan,GREENWICH,Information Services  
>   Sent:   Monday, November 03, 2003 4:15 PM
>   To: Melody,Thomas,GREENWICH,Information Services
>   Cc: Daley,Tom,GREENWICH,Information Services
>   Subject:Resolved Deduction Report
> 
>   Tom,
> 
>   I'm getting output for this report that I have never seen before.
> If I run the report for Clearing Date 10/31/03.  The download is fine.  If
> I run the report for Clearing Dates 11/01/03-11/03/03 then the download is
> missing the partner names and hierarchy names.
> 
>   I've created two variants for you to look at in PRD.  Run ZDEDSRPT
> with  variant 10/31/03 then variant 11/01/03 and you will see the output I
> am getting.  You need to delete or rename the first spreadsheet before
> running the second.  You can run them in foreground if you like.  They
> don't take too long.
> 
>   Could you please help me understand what has changed???
> 
>   Thanks,
>   Sue

FW: Invalid SAPOFFICE user ID in receiver list

[JWinters]

-Original Message-
From: Fine,Paul,GREENWICH,Information Systems 
Sent: Monday, November 03, 2003 4:31 PM
To: Winters,John,GREENWICH,Information Services;
Moffa,Robert,GREENWICH,Information Services
Cc: Daley,Tom,GREENWICH,Information Services
Subject: RE: Invalid SAPOFFICE user ID in receiver list 


John/Robert,
Any luck on the previous response below?...need me to add more info?
Please let me know
Thanks

Paul Fine
Nestle Waters North America
SAP Analyst
Phone-203-629-7234
Pager-1-888-22-WATER


-Original Message-
From: Fine,Paul,GREENWICH,Information Systems 
Sent: Friday, October 31, 2003 10:44 AM
To: Kaine,Ken,GREENWICH,IS; Winters,John,GREENWICH,Information Services
Subject: RE: Invalid SAPOFFICE user ID in receiver list 


John,
I think Ken's response is to the issue we have with the zbolexception report
to send to external users (vendors)
As far as the zvcaserr report there is an entry in table usr01 and usr02 for
PPSP in Production; however you are right there is none in DV3.   I have
left Robert Moffa a voice mail to create a user PPSP in DV3 so that tables
usr01 and usr02 should be populated.
Once this is done we still have to see if the Exchange directory for PPSP is
populated correctly.
Thanks

Paul Fine
Nestle Waters North America
SAP Analyst
Phone-203-629-7234
Pager-1-888-22-WATER


-Original Message-
From: Kaine,Ken,GREENWICH,IS 
Sent: Friday, October 31, 2003 10:35 AM
To: Winters,John,GREENWICH,Information Services;
Fine,Paul,GREENWICH,Information Systems
Subject: RE: Invalid SAPOFFICE user ID in receiver list 


If you look at program ZF_GELCO_RECURRING_PAYMENTS you can see a couple
examples of how to send an email to a non SAP user.  The standard
Z_PGA_DOWNLOAD function uses a receiver list of type somlreci1.  In this
structure there is a field called rec_type, which by default is space which
indicate the name you supplied to be a SAP user name.  If you change
rec_type to be 'U' for Internet address then you will be able to send to ids
that don't have an SAP user id.
Let me know if you me more information on this.
Ken

-Original Message-
From: Fine,Paul,GREENWICH,Information Systems 
Sent: Friday, October 31, 2003 9:51 AM
To: Kaine,Ken,GREENWICH,IS
Cc: Winters,John,GREENWICH,Information Services
Subject: RE: Invalid SAPOFFICE user ID in receiver list 


Ken,
Have you developed any functionality in the Gelco project where we send an
external email (non-NWNA) from SAP?
If so would you mind helping us out by looking at the program ZBOLEXCEPTION.
We would like to sort then send the output to an external email found in the
vendor master. 
It seems the current program finds the receivers to be invalid (see John's
email below).
Thanks

Paul Fine
Nestle Waters North America
SAP Analyst
Phone-203-629-7234
Pager-1-888-22-WATER

-Original Message-
From: Nestle Waters NA - SAP Development
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 11:13 AM
To: [EMAIL PROTECTED]
Subject: Invalid SAPOFFICE user ID in receiver list 


Program ZVRCASERR  contained invalid receviers in  the receiver list.
Either SAPUSER does not exist or SMTP forwarding addressmissing
See system admin if you cannot resolve this error
Mail has not been sent to the following receiver(s)

ppsp

FW: rice doc status

[JWinters]

>  -Original Message-
> From: Melody,Thomas,GREENWICH,Information Services  
> Sent: Wednesday, November 05, 2003 3:09 PM
> To:   Winters,John,GREENWICH,Information Services
> Cc:   Fine,Paul,GREENWICH,Information Systems
> Subject:  FW: rice doc status
> 
> 
> John,
> 
> Was this completed ?
> 
> Tom
> 
> 
>  -Original Message-
> From: Fine,Paul,GREENWICH,Information Systems  
> Sent: Wednesday, November 05, 2003 2:48 PM
> To:   Melody,Thomas,GREENWICH,Information Services
> Subject:  rice doc status
> 
> Tom,
> I am unsure if you have this rice doc or not
> If not here it is...it is to copy the ship-to to the shipment doc in dv3
> 240
> Thanks 
> 
> Paul Fine
> Nest <> e Waters North America
> SAP Analyst
> Phone-203-629-7234
> Pager-1-888-22-WATER
> 


Data Transfer for shipto.doc
Description: MS-Word document

FW: rice doc

[JWinters]

>  -Original Message-
> From: Fine,Paul,GREENWICH,Information Systems  
> Sent: Wednesday, October 29, 2003 9:28 AM
> To:   Winters,John,GREENWICH,Information Services;
> Melody,Thomas,GREENWICH,Information Services
> Subject:  RE: rice doc
> 
> I thought this was standard process...I guess not.
> If with any report currently in SAP we add to the field 'receiver' the
> output will be emailed to that address.
> So if we input 'PALL' into this field SAP maps this receiver to an outlook
> email directory.
> In this directory there is administration done where if it receives an
> email with a specific subject heading it forwards it to the appropriate
> parties listed in that directory.
> So somehow when the output is generated in this program a specific subject
> heading is required.   The receivers listed should be generated in
> accordance with the plants found in this report
> Does this help?
> If not perhaps we can meet Thursday to run through an example
> Paul Fine
> Nestle Waters North America
> SAP Analyst
> Phone-203-629-7234
> Pager-1-888-22-WATER
> 
>  -Original Message-
> From: Winters,John,GREENWICH,Information Services  
> Sent: Tuesday, October 28, 2003 5:19 PM
> To:   Fine,Paul,GREENWICH,Information Systems;
> Melody,Thomas,GREENWICH,Information Services
> Subject:  RE: rice doc
> 
> This doesn't help me at all. Sorry.
> 
> What does Outlook have to do with it ?
> 
>  -Original Message-
> From: Fine,Paul,GREENWICH,Information Systems  
> Sent: Tuesday, October 28, 2003 4:43 PM
> To:   Winters,John,GREENWICH,Information Services;
> Melody,Thomas,GREENWICH,Information Services
> Subject:  RE: rice doc
> 
> The receiver should equal the plant name.
> Outlook should take care of the actual email address by searching for the
> subject line
> This is the same concept used for 'missing standards report' where we
> email to 'SAPMAIL' and outlook uses the subject line as to where to send
> the email.
> The rice doc states that the receiver equal the plant name
> Does this help?
> 
> Paul Fine
> Nestle Waters North America
> SAP Analyst
> Phone-203-629-7234
> Pager-1-888-22-WATER
> 
>-Original Message-
>   From:   Winters,John,GREENWICH,Information Services  
>   Sent:   Tuesday, October 28, 2003 4:33 PM
>   To: Melody,Thomas,GREENWICH,Information Services;
> Fine,Paul,GREENWICH,Information Systems
>   Subject:RE: rice doc
> 
>   There are no specifications in this Document for determining the
> E-mail address of a Plant ??
> 
>-Original Message-
>   From:   Melody,Thomas,GREENWICH,Information Services  
>   Sent:   Tuesday, October 28, 2003 3:51 PM
>   To: Fine,Paul,GREENWICH,Information Systems;
> Winters,John,GREENWICH,Information Services
>   Subject:FW: rice doc
> 
> 
>   This request is assigned to John.
> 
>   Tom
> 
>-Original Message-
>   From:   Fine,Paul,GREENWICH,Information Systems  
>   Sent:   Tuesday, October 28, 2003 12:35 PM
>   To: Melody,Thomas,GREENWICH,Information Services
>   Subject:rice doc
> 
>   There is a requirement to email the output for the existing program
> zvrcaserr to the appropriate parties.
>   This program finds the BDC sessions with a prefix UFA* and CFA* plus
> related delivery information
>   Thanks << File: BDC Emailed.doc >> 
> 
>   Paul Fine
>   Nestle Waters North America
>   SAP Analyst
>   Phone-203-629-7234
>   Pager-1-888-22-WATER
> 

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

[Robert Millan]

On Fri, Nov 07, 2003 at 03:35:52PM -0500, Daniel Jacobowitz wrote:
> > 
> > I haven't noticed, so thanks for pointing this out. The fix is trivial, btw.
> 
> If you think that, then you don't understand why they are all built
> separately.

I don't need to understand that.

> They all require different patches.
> 
> They all require different kernel versions, in general.
> 
> They all require different binaries to be shipped and different tools
> to be used to build them.

Are you suggesting I can't deal with trivial packaging issues like that? I
know how Build-Depends work. I also know how to apply patches conditionaly.

> And suggesting autobuilding kernels for an architecture other than the
> one the maintainer tests them on seems like an extremely bad idea.

Why? Don't we autobuild Glibc? Do you think the Glibc maintainers don't test
their packages properly for non-i386? (Yes, I know you're one of them.)

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

[Daniel Jacobowitz]

On Fri, Nov 07, 2003 at 10:18:37PM +0100, Robert Millan wrote:
> On Fri, Nov 07, 2003 at 03:35:52PM -0500, Daniel Jacobowitz wrote:
> > > 
> > > I haven't noticed, so thanks for pointing this out. The fix is trivial, 
> > > btw.
> > 
> > If you think that, then you don't understand why they are all built
> > separately.
> 
> I don't need to understand that.

You don't need to understand the problem that prompted our existing
kernel packages in order to create a new one that "just works"? 
Really?

> > They all require different patches.
> > 
> > They all require different kernel versions, in general.
> > 
> > They all require different binaries to be shipped and different tools
> > to be used to build them.
> 
> Are you suggesting I can't deal with trivial packaging issues like that? I
> know how Build-Depends work. I also know how to apply patches conditionaly.

Then how do you suggest maintaining a kernel 2.4.20 for one
architecture and a 2.4.22 for another architecture, when you can't even
test on either of them?  And how do you expect to ever upgrade the
result without duplicating all the work done by all the existing kernel
package maintainers for all Debian architectures?

This doesn't even make any sense.  Might as well just set Architecture:
i386.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

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

[Robert Millan]

On Fri, Nov 07, 2003 at 08:35:54PM +, Andrew Suffield wrote:
> > 
> > I haven't noticed, so thanks for pointing this out. The fix is trivial, btw.
> 
> No, the fix is a fucking huge amount of work, which is why nobody has
> done it before, even for the upstream kernel.

Appliing patches dinamicaly and conditionaly is a huge amount of work?

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

[Robert Millan]

On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote:
> On Fri, Nov 07, 2003 at 10:18:37PM +0100, Robert Millan wrote:
> > > If you think that, then you don't understand why they are all built
> > > separately.
> > 
> > I don't need to understand that.
> 
> You don't need to understand the problem that prompted our existing
> kernel packages in order to create a new one that "just works"? 
> Really?

No. You're putting words in my mouth.

I don't need to understand why the patches can't be merged in order to apply
the corresponding patch for each architecture. As I said, it's a trivial
packaging issue.

> > Are you suggesting I can't deal with trivial packaging issues like that? I
> > know how Build-Depends work. I also know how to apply patches conditionaly.
> 
> Then how do you suggest maintaining a kernel 2.4.20 for one
> architecture and a 2.4.22 for another architecture, when you can't even
> test on either of them?  

I wouldn't. I'm going to track the latest minor version, just like the rest
of Debian packages do.

> And how do you expect to ever upgrade the
> result without duplicating all the work done by all the existing kernel
> package maintainers for all Debian architectures?

Build-Depends: [...], kernel-patch-2.4.22-powerpc [powerpc], [...]

> This doesn't even make any sense.  Might as well just set Architecture:
> i386.

Do you have any other point, asides of pretending I'm incompetent at packaging?

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

[Daniel Jacobowitz]

On Fri, Nov 07, 2003 at 10:48:06PM +0100, Robert Millan wrote:
> On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote:
> > On Fri, Nov 07, 2003 at 10:18:37PM +0100, Robert Millan wrote:
> > > > If you think that, then you don't understand why they are all built
> > > > separately.
> > > 
> > > I don't need to understand that.
> > 
> > You don't need to understand the problem that prompted our existing
> > kernel packages in order to create a new one that "just works"? 
> > Really?
> 
> No. You're putting words in my mouth.
> 
> I don't need to understand why the patches can't be merged in order to apply
> the corresponding patch for each architecture. As I said, it's a trivial
> packaging issue.
> 
> > > Are you suggesting I can't deal with trivial packaging issues like that? I
> > > know how Build-Depends work. I also know how to apply patches 
> > > conditionaly.
> > 
> > Then how do you suggest maintaining a kernel 2.4.20 for one
> > architecture and a 2.4.22 for another architecture, when you can't even
> > test on either of them?  
> 
> I wouldn't. I'm going to track the latest minor version, just like the rest
> of Debian packages do.

And then you won't build on any architecture unless the architecture
moves to that kernel version.  This has been known to take _years_.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

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

[Robert Millan]

On Fri, Nov 07, 2003 at 04:49:59PM -0500, Daniel Jacobowitz wrote:
> > 
> > I wouldn't. I'm going to track the latest minor version, just like the rest
> > of Debian packages do.
> 
> And then you won't build on any architecture unless the architecture
> moves to that kernel version.  This has been known to take _years_.

I realised that. But for 2.4.22 there are 5 architectures with native support
and 2 with up-to-date patches, which is enough for now.

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

Version Updating Question

[Mark Johnson]

Hi All,

I'm updating the docbook-simple package from V1.0cr2 to V1.0. Since
1.0cr2 > 1.0, I'm not sure how to handle the situation.

Policy & the Developers Reference imply that I upload V1.0 and file a
bug against ftp.debian.org to have V1.0CR2 removed from the
archive. This seems like an odd way to do it. 

Also, I'd rather not give V1.0 a version like 1.0really - unless I
'really' have to:)

Any help on this would be much appreciated.

Thanks,
Mark

-- 
_
Mark Johnson<[EMAIL PROTECTED]>
Debian XML/SGML <[EMAIL PROTECTED]>
Home Page:  
GPG fp: 50DF A22D 5119 3485 E9E4  89B2 BCBC B2C8 2BE2 FE81

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

[Frank Gevaerts]

On Fri, Nov 07, 2003 at 10:48:06PM +0100, Robert Millan wrote:
> > Then how do you suggest maintaining a kernel 2.4.20 for one
> > architecture and a 2.4.22 for another architecture, when you can't even
> > test on either of them?  
> 
> I wouldn't. I'm going to track the latest minor version, just like the rest
> of Debian packages do.

So you would recommend dropping support for architectures that do not
boot with the latest kernel ?

Frank

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

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

[viro]

On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote:
 
> Then how do you suggest maintaining a kernel 2.4.20 for one
> architecture and a 2.4.22 for another architecture, when you can't even
> test on either of them?  And how do you expect to ever upgrade the
> result without duplicating all the work done by all the existing kernel
> package maintainers for all Debian architectures?
> 
> This doesn't even make any sense.  Might as well just set Architecture:
> i386.

Situation when 2.4.22 does not work on architecture in question is a *bug*,
plain and simple.  Same as when 2.3.2 doesn't work on the same architecture.
And correct way to deal with that is to report these bugs upstream and/or
submit patches fixing them.

BTW, is there any reason why kernel-patch-2.4.22-powerpc-2.4.22 exists?

I'm looking through the splitup of that patch right now (and by $DEITY,
it should've been split from the very beginning - what with it being
pulled from ppc BK tree).  There we have:
1) sungem patch
2) minor cleanup in ne2k-pci (platform-independent)
3) extra PCI ID in tg3 table.
4) change in drivers/sound/config.in (affects only powerpc builds)
5) usb-ohci - more conservative alignment.
6) aty128fb.c ifdef changes (affects only powerpc builds)
7) additional constants defined in radeon.h (none of them used in
   #ifdef/#ifndef/defined())
8) drivers/video/Config.in change (affects only powerpc builds)
9) patches in arch/ppc and include/asm-ppc (affects only powerpc builds)
10) extra PCI IDs in pci_ids.h

Out of these, ##2--4,6--10 can and should be in the common tree.

#5 either should be arch-conditional (it's a couple of lines) or
it should be simply applied on all platforms - depends on the reasons
why it exists.

#1 needs testing on sparc.  Until it gets such, make it arch-conditional.

And there goes the bleeding package.  I mean, WTF?  We don't have separate
source packages for gcc-3.3/powerpc or gcc-3.3/alpha.  We certainly *do* have
patches unique to these platforms in there.  And gcc, glibc and binutils are
autobuilt.  I sincerely hope that it doesn't imply "Architecture: i386" on
those.

Sigh...

Re: Version Updating Question

[Daniel Jacobowitz]

On Fri, Nov 07, 2003 at 04:57:54PM -0500, Mark Johnson wrote:
> Hi All,
> 
> I'm updating the docbook-simple package from V1.0cr2 to V1.0. Since
> 1.0cr2 > 1.0, I'm not sure how to handle the situation.
> 
> Policy & the Developers Reference imply that I upload V1.0 and file a
> bug against ftp.debian.org to have V1.0CR2 removed from the
> archive. This seems like an odd way to do it. 

Won't work.

> Also, I'd rather not give V1.0 a version like 1.0really - unless I
> 'really' have to:)
> 
> Any help on this would be much appreciated.

Eventually, the right thing to do will be something like 1.0~cr2 which
is less than 1.0.  That won't be allowed till after sarge, IIRC.

For now, the right thing to do would have been 0.999, or some similarly
gross hack.

To correct it, at this point, you need either to append something or
add an epoch.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

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

[viro]

On Fri, Nov 07, 2003 at 10:59:51PM +0100, Frank Gevaerts wrote:
> On Fri, Nov 07, 2003 at 10:48:06PM +0100, Robert Millan wrote:
> > > Then how do you suggest maintaining a kernel 2.4.20 for one
> > > architecture and a 2.4.22 for another architecture, when you can't even
> > > test on either of them?  
> > 
> > I wouldn't. I'm going to track the latest minor version, just like the rest
> > of Debian packages do.
> 
> So you would recommend dropping support for architectures that do not
> boot with the latest kernel ?

Submit the fscking bug reports and patches.  Same as with toolchain
packages.

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

[Andreas Metzler]

Robert Millan <[EMAIL PROTECTED]> wrote:
[..]
> - Automatical major updates (the x in 2.x.y). When 2.6 is suitable to be
>   the default version, a simple change in -defaults package (ala
>   gcc) would enforce updating on all existing systems that use this
>   method. This prevents us from encountering ABI incompatibility
>   problems, like this recent one in Glibc:
> #215010: Illegal instruction with 2.2 kernel

>   This is not unusual. IIRC, Woody's Glibc wasn't supported by Linux
>   2.0 (I once tried an upgrade from Slink after the Woody release)

>   Note: as pointed by Andreas, this doesn't apply to minor updates

I don't think automatic (as in unless you press ctrl-C or set the
package on hold) major kernel-upgrades are wise, they should only be
done on user-request, when the the user has time to take care of it.
All my major kernel-upgrades required manual intervention, as I always
had to change the module options and configuration. (With 2.6 there is
sysfs and the abolishment of ide-scsi).
   cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

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

[Andreas Metzler]

Robert Millan <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 07, 2003 at 08:35:54PM +, Andrew Suffield wrote:
 
>> > I haven't noticed, so thanks for pointing this out. The fix is trivial, 
>> > btw.

>> No, the fix is a fucking huge amount of work, which is why nobody has
>> done it before, even for the upstream kernel.

> Appliing patches dinamicaly and conditionaly is a huge amount of work?

No, choosing, writing and testing the patches on the respective
machines is.
 cu andreas

供年[月]历；[电话0577-64213880]

[www.wztpy.com]

供应印刷设备:您好!



致
礼!
  　　 www.wztpy.com
  　　 [EMAIL PROTECTED]
  　　 2003-11-08

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

[Matthew Garrett]

Robert Millan wrote:

>I wouldn't. I'm going to track the latest minor version, just like the rest
>of Debian packages do.

You really, massively, hugely fail to understand the problem here. The
upstream kernel tree works on a small number of architectures. To deal
with this, several other architectures have their own trees. These trees
may be roughly synchronised with the kernel.org tree - in most cases,
they're not (they may be utterly broken at the point where 2.4.x comes
out, for instance, resulting in the next usable version of their kernel
being somewhere around 2.4.x+1). There are some sub-architectures where
the maintainer resynchronises their tree against the kernel.org one
every 6 months or so, and in the intermediate period is still working on
2.4.(x-5). Always packaging the latest minor version would kill Debian
on a wide range of machines.

But, of course, you know this already, because you've researched these
issues in advance.
-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Version Updating Question

[Andreas Metzler]

Mark Johnson <[EMAIL PROTECTED]> wrote:
> I'm updating the docbook-simple package from V1.0cr2 to V1.0. Since
> 1.0cr2 > 1.0, I'm not sure how to handle the situation.

> Policy & the Developers Reference imply that I upload V1.0 and file a
> bug against ftp.debian.org to have V1.0CR2 removed from the
> archive. This seems like an odd way to do it. 

Please give an exact reference, if Policy & the Developers Reference
imply this it is a bug that needs to fixed. Packages are only removed
from the archive if they are removed permanently.

Removing the package from the archive would not solve the problem,
because anybody who has already 1.0CR2 would not be upgraded
automatically if the new upload had a lower version-number.

> Also, I'd rather not give V1.0 a version like 1.0really - unless I
> 'really' have to:)

You can choose whether to use something like 1.0.rel or an epoch.
  cu and- I would not use an epoch unless I was forced to,
   ugly package versions go, epochs stay forever -reas

Re: rice doc status

[Jim Penny]

On Fri, 7 Nov 2003 15:55:25 -0500 
[EMAIL PROTECTED] wrote:

I don't know if you are virused, or if your sender has been spoofed, or
what.  Anyway, you might want to look into this.  You appear to be
spewing odd word documents people you don't know.

Jim Penny

> 
> 
> >  -Original Message-
> > From:   Melody,Thomas,GREENWICH,Information Services  
> > Sent:   Wednesday, November 05, 2003 3:09 PM
> > To: Winters,John,GREENWICH,Information Services
> > Cc: Fine,Paul,GREENWICH,Information Systems
> > Subject:FW: rice doc status
> > 
> > 
> > John,
> > 
> > Was this completed ?
> > 
> > Tom
> > 
> > 
> >  -Original Message-
> > From:   Fine,Paul,GREENWICH,Information Systems  
> > Sent:   Wednesday, November 05, 2003 2:48 PM
> > To: Melody,Thomas,GREENWICH,Information Services
> > Subject:rice doc status
> > 
> > Tom,
> > I am unsure if you have this rice doc or not
> > If not here it is...it is to copy the ship-to to the shipment doc in
> > dv3 240
> > Thanks 
> > 
> > Paul Fine
> > Nest <> e Waters North America
> > SAP Analyst
> > Phone-203-629-7234
> > Pager-1-888-22-WATER
> > 
> 

kde package description

[Bernd Eckenfels]

hello,

most of the debian kde packages start with a description, what KDE is. I am
not sure if it is a good idea to have such more geenric background info at
the beginning of a package description. I would suggest something like:


kuickshow:
--
KDE image/slideshow viewer

This package is part of the official KDE graphics module.

KDE is a powerful Open Source graphical desktop environment for Unix 
workstations. It
combines ease of use, contemporary functionality, and outstanding graphical 
design with the
technological superiority of the Unix operating system.
--

and not:

KDE is a powerful Open Source graphical desktop environment for Unix 
workstations. It
combines ease of use, contemporary functionality, and outstanding graphical 
design with the
technological superiority of the Unix operating system.

KDE image/slideshow viewer

This package is part of the official KDE graphics module.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

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

[Daniel Jacobowitz]

On Fri, Nov 07, 2003 at 10:20:25PM +, [EMAIL PROTECTED] wrote:
> On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote:
>  
> > Then how do you suggest maintaining a kernel 2.4.20 for one
> > architecture and a 2.4.22 for another architecture, when you can't even
> > test on either of them?  And how do you expect to ever upgrade the
> > result without duplicating all the work done by all the existing kernel
> > package maintainers for all Debian architectures?
> > 
> > This doesn't even make any sense.  Might as well just set Architecture:
> > i386.
> 
> Situation when 2.4.22 does not work on architecture in question is a *bug*,
> plain and simple.  Same as when 2.3.2 doesn't work on the same architecture.
> And correct way to deal with that is to report these bugs upstream and/or
> submit patches fixing them.
> 
> BTW, is there any reason why kernel-patch-2.4.22-powerpc-2.4.22 exists?

Nowadays?  No particular reason, but when I maintained it I simply
tracked the PPC BK tree.  Lately, it's been a nice small patch, and I
didn't have a chance to examine it (part of why I gave up the package).

It used to be more like 100K gzipped, around 2.4.14 or so.

> I'm looking through the splitup of that patch right now (and by $DEITY,
> it should've been split from the very beginning - what with it being
> pulled from ppc BK tree).  There we have:

It's a diff between two different lines of development, one of which
gets periodically merged into the other.  Splitting it by csets
wouldn't give you anything useful, because you'd get a few small
patches for changes since the last merge, and one patch representing
the merge cset.  It's a hard or impossible problem to preserve cset
boundaries across such a merge.  So, no, there is no easy way to split
it.

Especially, as I said, when the package used to be a whole lot larger
:)  I don't have time to merge-monkey for that tree, and it's not my
business to, since the maintainers do it quite well overall.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

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

[Brian May]

On Fri, Nov 07, 2003 at 08:13:18PM +0100, Santiago Vila wrote:
> At least, the ability to do
> 
> apt-get source linux
> 
> as it should always have been.
> 
> 
> I think it's time we put an end to this euphemism called "the kernel"
> and start calling it by its proper name (if we refer to Linux, that is).

apt-get source kernel-source-2.4.22
???
-- 
Brian May <[EMAIL PROTECTED]>

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

[Herbert Xu]

Robert Millan <[EMAIL PROTECTED]> wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: linux
>  Version : 2.4.22
>  Upstream Author : Linus Torvalds <[EMAIL PROTECTED]> and others, see:
>http://www.kernel.org/pub/linux/kernel/CREDITS
> * URL : http://www.kernel.org/
> * License : GPL
>  Description : Linux 2.4 kernel
> 
> Linux 2.4 kernel re-packaged as a standard Debian package. For details, see:
> 
>  http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00204.html
> 
> Package sources available in:
> 
>  http://people.debian.org/~rmh/linux/

I welcome this experiment in a new package of the Linux kernel.  I will
be observing its progress in the coming months.

Unlike other core components of the distribution, the kernel package
is easily replaced so there should be no problems hosting two packages
in Debian.

Cheers,
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Version Updating Question

[Herbert Xu]

Andreas Metzler <[EMAIL PROTECTED]> wrote:
> 
>  cu and- I would not use an epoch unless I was forced to,
>   ugly package versions go, epochs stay forever -reas

You know what, version numbers stay forever too.  Well, they would
if it weren't for the epoch...
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Version Updating Question

[Neil Roeth]

On Nov  7, Mark Johnson ([EMAIL PROTECTED]) wrote:
 > I'm updating the docbook-simple package from V1.0cr2 to V1.0. Since
 > 1.0cr2 > 1.0, I'm not sure how to handle the situation.

1.0.0 will do the trick, and I think that's cleaner than something like
1.0really.

-- 
Neil Roeth

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

[Graham Wilson]

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.

-- 
gram


signature.asc
Description: Digital signature