Re: Two debconf issues

[Brendan O'Dea]

On Sat, May 05, 2001 at 02:03:59AM +0300, Shaul Karl wrote:
>Can you compare Perl speed to Python? 
>Just curious, have no prior knowledge on this.

Can you?  Of course you can.  Has someone?  Very probably, although I
can't recall seeing an instance off-hand.

"Compare Perl speed to Python" is pretty open ended question though.  In
general?  For task X?  Task Y?

While it doesn't mention Python specifically, there is a very
interesting paper by Kernighan and Van Wyk describing some experiments
with various tasks in different languages which is germane to this
thread:

Timing Trials, or, the Trials of Timing
http://www.cs.bell-labs.com/cm/cs/who/bwk/interps/pap.html

Regards,
-- 
Brendan O'Deabod@compusol.com.au
Compusol Pty. Limited  (NSW, Australia)  +61 2 9810 3633

Re: gcc error - xfsprogs, ppc

[Keith Owens]

>> gcc -O1 -g -DNDEBUG -funsigned-char -Wall  -I../include '-DVERSION="1.2.4"' 
>> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 
>> -DXFS_BIG_FILESYSTEMS=1 -o xfs_db -L../libxfs  addr.o agf.o agfl.o agi.o 
>> attr.o attrshort.o bit.o block.o bmap.o bmapbt.o bmroot.o bnobt.o check.o 
>> cntbt.o command.o convert.o data.o dbread.o debug.o dir.o dir2.o dir2sf.o 
>> dirshort.o dquot.o echo.o faddr.o field.o flist.o fprint.o frag.o freesp.o 
>> hash.o help.o init.o inobt.o inode.o input.o io.o malloc.o mount.o output.o 
>> print.o quit.o sb.o uuid.o sig.o strvec.o type.o write.o main.o   -lxfs 
>> /usr/lib/libuuid.a
>> ../libxfs/libxfs.a(xfs_inode.o): In function `libxfs_xlate_dinode_core':
>> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: undefined 
>> reference to `__fswab64'
>> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: relocation 
>> truncated to fit: R_PPC_REL24 __fswab64

Ignore "relocation truncated to fit", it is a spurious error message
caused by __fswab64 being undefined, __fswab64 is treated as 0 and a
ppc rel24 offset is not enough to represent 0 when the program is
loaded above address 2**23.

As for why __fswab64 is undefined, try using -O2 instead of -O1.  AFAIK
functions are not inlined at -O1.

Re: Finishing the FHS transition

[Chris Waters]

On Sun, May 06, 2001 at 06:29:05PM -0400, Joey Hess wrote:
> Chris Waters wrote:
> > > - A change in the policy to remove the obsolete /usr/doc symlinks.

> > This is supposed to happen once enough packages make the transition.

> No, it is supposed to happen one release _after_ a release in which
> all the packages have made the transition. So sarge at the earliest,
> not woody.

Right.  Even better point.
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Finishing the FHS transition

[Chris Waters]

On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote:
> On Sun, 6 May 2001, Chris Waters wrote:

> > Didn't we already have this discussion?  The Standards-Version field
> > is not a reliable indication of much of anything.  I strongly object

> Policy says:

"Policy says" doesn't make the packages comply.  And you can file all
the bugs reports you want, but that doesn't magically fix the
packages.  And until they're fixed, you can't use them as a reliable
indicator of FHS compatibility.  QED.

We have many packages with old Standards-Versions which actually
comply with newer standards and *are* FHS compatible, and we have
packages with newer Standards-Versions that are NOT FHS compatible.

I think that if you really want to focus on FHS compatibility, you're
better off ignoring the Standards-Version issues for now.  Its just
another can of worms.  Picking the minimum Standards-Version for
release is something we normally do at freeze time.

>  In the source package's `Standards-Version' control field, you must
>  specify the most recent version number of this policy document with
>  which your package complies.  The current version number is 3.5.4.0.

You're misinterpreting this.  It does not mean that every package must
be reuploaded every time policy changes.  "Most recent" should be
checked at the time you create the source package, not rechecked
daily.

Note that the next paragraph mentions filing bug reports if the
package becomes "too much out of date".  If any is too much, why
bother to say "too much"?

> > to removing packages because of what amount to cosmetic issues, and an

> Where did I say that I want to remove the packages???
> I said that I want to send bug reports.

RC bugs mean the package must be removed from the next release if it's
not fixed.  Unless you can guarantee that the bugs will be fixed
(i.e., you're volunteering to fix them yourself), you _are_ asking for
package to be removed when you file RC bugs.

Anyway, I apologize for a reminder I'm sure you don't need.  It's just
a habit of mine, please forgive me.

Bottom line, I think there remains a lot of work checking the subtle
and not-so-obvious stuff in the FHS before we can confidently claim
FHS compatibility (and even *begin* to work on actual compliance).

The easy stuff, as your evidence shows, we're actually quite close on.
It's the harder stuff, like /var/lib/games (which Kamion was going to
investigate) and the random hard-to-identify files that need to move
from /usr/lib to /usr/share that needs the most attention.

So, anyway, that's a nice list of packages you made, and I think it's
probably very useful -- all those packages should inspected -- I just
don't think it's very useful for the purpose you intended.

And I think mass filings of RC bugs would be premature at best.

cheers
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: RaiserFS PPC status

[Rahul Jain]

On Mon, May 07, 2001 at 12:03:43AM +0200, Just a friendly Jedi Knight wrote:
>  You mean XFS from Linus kernel tree? there are some patches on
>  penguinppc.org

This is not in Linus's kernel tree. Are you using SGI's 1.0 release?
In any case, that should not affect the compilation of the tools much.

>  Anyway i have trouble compiling mkfs.xfs I tried:
>  gcc version 2.95.4 20010319 (Debian prerelease)
>  gcc version 3.0 20010402 (Debian prerelease) and xfsprogs 1.2.4 Debian
>  source package as well as source taken from penguinppc.org. I always get
>  this:

you should stick to gcc 2.95 for compiling the kernel, and probably the
userspace tools, too.

> gcc -O1 -g -DNDEBUG -funsigned-char -Wall  -I../include '-DVERSION="1.2.4"' 
> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DXFS_BIG_FILES=1 
> -DXFS_BIG_FILESYSTEMS=1 -o xfs_db -L../libxfs  addr.o agf.o agfl.o agi.o 
> attr.o attrshort.o bit.o block.o bmap.o bmapbt.o bmroot.o bnobt.o check.o 
> cntbt.o command.o convert.o data.o dbread.o debug.o dir.o dir2.o dir2sf.o 
> dirshort.o dquot.o echo.o faddr.o field.o flist.o fprint.o frag.o freesp.o 
> hash.o help.o init.o inobt.o inode.o input.o io.o malloc.o mount.o output.o 
> print.o quit.o sb.o uuid.o sig.o strvec.o type.o write.o main.o   -lxfs 
> /usr/lib/libuuid.a
> ../libxfs/libxfs.a(xfs_inode.o): In function `libxfs_xlate_dinode_core':
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: undefined 
> reference to `__fswab64'
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: relocation 
> truncated to fit: R_PPC_REL24 __fswab64
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: undefined 
> reference to `__fswab64'
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:563: relocation 
> truncated to fit: R_PPC_REL24 __fswab64
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:564: undefined 
> reference to `__fswab64'
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:564: relocation 
> truncated to fit: R_PPC_REL24 __fswab64
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:564: undefined 
> reference to `__fswab64'
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_inode.c:564: relocation 
> truncated to fit: R_PPC_REL24 __fswab64
> ../libxfs/libxfs.a(xfs_mount.o): In function `libxfs_xlate_sb':
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_mount.c:205: undefined 
> reference to `__fswab64'
> /opt/src/robert/XFS/xfsprogs-1.2.4/libxfs/xfs_mount.c:205: relocation 
> truncated to fit: R_PPC_REL24 __fswab64
> collect2: ld returned 1 exit status
> make[2]: *** [xfs_db] Error 1
> make[1]: *** [default] Error 2
> make[1]: Leaving directory `/opt/src/robert/XFS/xfsprogs-1.2.4'
> make: *** [built] Error 2

grepping my xfsprogs tree, I get:
./include/libxfs.h:extern __inline__ __const__ __u64 __fswab64 (__u64 x);

maybe your GCC isn't inlining the function?
note that this declaration has "/* ick */" on the line above it. But I think
the relocation truncated to fit: R_PPC_REL24 __fswab64 messages are important.
I'll leave it to someone more knowledgable about GCC and ELF to comment on
that.

> These are the only errors I get... This must be some bug in gcc on powerpc as
> it compiles cleanly on i386 (and from looking on ftp.debian.org on other
> platforms also). I don't even have idea how to bite this...

I'm only on x86 here, so all I can say is "yeah" :)

-- 
-> -/-   - Rahul Jain -   -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--||--||-|--|-|-|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

Re: Bug#96224: libgmp3: Move documentation in the -dev package

[Steve M. Robbins]

Hi Christian & Dale,

On Sun, May 06, 2001 at 11:11:14PM +0200, Christian Marillat wrote:
>  "DS" == Dale Scheetz <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> DS> I can be convinced on either count. How would you feel about my presenting
> DS> this issue to the "developers" at large, with you and I agreeing to follow
> DS> the concensus of the group?
> >> 
> >> Go ahead.

I'd be happy to give an opinion.  However, based on this one message
and the bug report, I can't figure out what the contentious issue is.

It is evident to me that the (programmer) docs and example code does
not belong in the runtime libgmp3 package.

Christian seems to be asking that they get moved to the -dev package,
which seems logical enough to me.

Dale seems to be arguing that a new -doc package should be created,
and the docs moved there, instead.  To me, that seems like overkill.
But if the packager (Dale) is doing the work, who am I to argue?

If Dale has agreed to do move the docs (either to -dev or to -doc),
that seems to me to answer the bug report.  I don't understand what
question Christian's posting to -devel is supposed to raise.

-S

Re: Finishing the FHS transition

[Martin Michlmayr]

* Adrian Bunk <[EMAIL PROTECTED]> [20010506 21:27]:
> See above: I want to file a RC bug either because
> a) the package follows a too old policy or

For the /usr/doc problem, bugs with severity: normal have already been
filed by doogie and joeyh.  For these packages, you simply have to
change the severity.  At the moment, 103 of these bugs are still open
(248 bugs were filed originally):


Package: acm
Maintainer: Enrique Zanardi <[EMAIL PROTECTED]>
  91371 Package acm still has at least one file in /usr/doc
  91382 Package acm still has at least one file in /usr/doc

Package: authbind
Maintainer: Ian Jackson <[EMAIL PROTECTED]>
  91376 Package authbind still has at least one file in /usr/doc
  91387 Package authbind still has at least one file in /usr/doc

Package: bock
Maintainer: Charles Briscoe-Smith <[EMAIL PROTECTED]>
  91396 Package bock still has at least one file in /usr/doc

Package: cqcam
Maintainer: Daniel Martin <[EMAIL PROTECTED]>
  91415 Package cqcam still has at least one file in /usr/doc

Package: cracklib-runtime
Maintainer: Jean Pierre LeJacq <[EMAIL PROTECTED]>
  91407 Package cracklib-runtime still has at least one file in /usr/doc

Package: cracklib2
Maintainer: Jean Pierre LeJacq <[EMAIL PROTECTED]>
  91414 Package cracklib2 still has at least one file in /usr/doc

Package: cracklib2-dev
Maintainer: Jean Pierre LeJacq <[EMAIL PROTECTED]>
  91429 Package cracklib2-dev still has at least one file in /usr/doc

Package: csound-doc
Maintainer: Guenter Geiger <[EMAIL PROTECTED]>
  91433 Package csound-doc still has at least one file in /usr/doc

Package: cup
Maintainer: Charles Briscoe-Smith <[EMAIL PROTECTED]>
  91422 Package cup still has at least one file in /usr/doc

Package: doc-debian-fr
Maintainer: Christophe Le Bars <[EMAIL PROTECTED]>
  91417 Package doc-debian-fr still has at least one file in /usr/doc

Package: dtlk
Maintainer: [EMAIL PROTECTED] (James R. Van Zandt)
  91438 Package dtlk still has at least one file in /usr/doc

Package: dtmfdial
Maintainer: [EMAIL PROTECTED] (Stephen J. Carpenter)
  91450 Package dtmfdial still has at least one file in /usr/doc

Package: dvidvi
Maintainer: [EMAIL PROTECTED] (David A. van Leeuwen)
  91439 Package dvidvi still has at least one file in /usr/doc

Package: emacs20-el
Maintainer: Rob Browning <[EMAIL PROTECTED]>
  91554 Package emacs20-el still has at least one file in /usr/doc

Package: emacsen-common
Maintainer: Rob Browning <[EMAIL PROTECTED]>
  91457 Package emacsen-common still has at least one file in /usr/doc

Package: f77reorder
Maintainer: Alex Romosan <[EMAIL PROTECTED]>
  91444 Package f77reorder still has at least one file in /usr/doc

Package: faqomatic
Maintainer: [EMAIL PROTECTED] (Scott K. Ellis)
  91465 Package faqomatic still has at least one file in /usr/doc

Package: ftape-doc
Maintainer: Christian Meder <[EMAIL PROTECTED]>
  91463 Package ftape-doc still has at least one file in /usr/doc

Package: ftape-util
Maintainer: Christian Meder <[EMAIL PROTECTED]>
  91462 Package ftape-util still has at least one file in /usr/doc

Package: gap4-gdat
Maintainer: Markus Hetzmannseder <[EMAIL PROTECTED]>
  91470 Package gap4-gdat still has at least one file in /usr/doc

Package: gap4-tdat
Maintainer: Markus Hetzmannseder <[EMAIL PROTECTED]>
  91469 Package gap4-tdat still has at least one file in /usr/doc

Package: gbdk-dev
Maintainer: Masato Taruishi <[EMAIL PROTECTED]>
  91472 Package gbdk-dev still has at least one file in /usr/doc

Package: gbdk-examples
Maintainer: Masato Taruishi <[EMAIL PROTECTED]>
  91471 Package gbdk-examples still has at least one file in /usr/doc

Package: gcc-m68k-linux
Maintainer: Martin Mitchell <[EMAIL PROTECTED]>
  91476 Package gcc-m68k-linux still has at least one file in /usr/doc

Package: gerstensaft
Maintainer: Martin Schulze <[EMAIL PROTECTED]>
  91477 Package gerstensaft still has at least one file in /usr/doc

Package: glimpse
Maintainer: Marco Budde <[EMAIL PROTECTED]>
  91484 Package glimpse still has at least one file in /usr/doc

Package: gs-aladdin-manual
Maintainer: Marco Pistore <[EMAIL PROTECTED]>
  91486 Package gs-aladdin-manual still has at least one file in /usr/doc

Package: gs-aladdin-manual-de
Maintainer: Marco Pistore <[EMAIL PROTECTED]>
  91483 Package gs-aladdin-manual-de still has at least one file in /usr/doc

Package: gsfonts
Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
  91489 Package gsfonts still has at least one file in /usr/doc

Package: gsfonts-other
Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
  91485 Package gsfonts-other still has at least one file in /usr/doc

Package: htget
Maintainer: Troy Hanson <[EMAIL PROTECTED]>
  91497 Package htget still has at least one file in /usr/doc

Package: id-utils
Maintainer: Brad Bosch <[EMAIL PROTECTED]>
  91555 Package id-utils 

Re: build depends on kernel-headers

[Adrian Bunk]

On Mon, 7 May 2001, Herbert Xu wrote:

> > What do you suggest in my specific case with util-linux?
>
> Which specific program in util-linux and what specific headers?
>...

(I tried my best but I can't garuantee this is 100% complete...)

fdisk:
linux/unistd.h
linux/hdreg.h
linux/blkpg.h
linux/types.h
linux/major.h

cfdisk:
linux/unistd.h
linux/types.h
linux/hdreg.h

sfdisk:
linux/unistd.h
linux/hdreg.h

mkswap:
asm/page.h

hwclock:
asm/io.h
asm/rtc.h
asm/cuda.h
linux/version.h
linux/mc146818rtc.h
linux/kd.h

setterm:
asm/ioctls.h

mount + umount:
asm/types.h
asm/page.h
linux/posix_types.h
linux/loop.h
linux/nfs.h
linux/unistd.h
linux/nfs_mount.h

swapon:
linux/unistd.h

pivot_root:
linux/unistd.h

fdformat:
linux/fd.h

setfdprm:
linux/fd.h

raw:
linux/raw.h
linux/major.h

fsck.minix:
linux/fs.h
linux/minix_fs.h

mkfs.minix:
linux/fs.h
linux/minix_fs.h

setterm:
linux/unistd.h

cytune:
linux/tty.h
linux/tqueue.h
linux/cyclades.h
linux/version.h

dmesg:
linux/unistd.h



cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: apt complaining about valid dependencies

[Tal Danzig]

Hi,

First I'd try:
apt-get -f install

Then I'd try to resolve each problem separately.  Eg:
apt-get install alsa-utils
apt-get install asclock
.

Also, have you tried a dist-upgrade?

- Tal

On Mon, May 07, 2001 at 12:15:19AM +0100, Oliver Elphick wrote:
> What is apt-get upgrade complaining about here?  On a cursory glance,
> there isn't anything wrong with any of these proposed installations:
> 
> This is apt 0.5.3.
> 
> 148 packages upgraded, 0 newly installed, 0 to remove and 11  not upgraded.
> Sorry, but the following packages have unmet dependencies:
>   alsa-utils: Depends: libc6 (>= 2.1.97) but 2.2.2-4 is to be installed
>   asclock: Depends: libc6 (>= 2.2.1-2) but 2.2.2-4 is to be installed
[...]

-- 
  .--.
 /  Tal Danzig: [EMAIL PROTECTED]  \
(Libranet GNU/Linux  http://www.libranet.com   )
 `'

Re: apt complaining about valid dependencies

[Jason Gunthorpe]

On Mon, 7 May 2001, Oliver Elphick wrote:

> What is apt-get upgrade complaining about here?  On a cursory glance,
> there isn't anything wrong with any of these proposed installations:

It's an error with how the message is printed, it is showing the wrong
number for 'is to be installed' IIRC.

Jason

apt complaining about valid dependencies

[Oliver Elphick]

What is apt-get upgrade complaining about here?  On a cursory glance,
there isn't anything wrong with any of these proposed installations:

This is apt 0.5.3.

148 packages upgraded, 0 newly installed, 0 to remove and 11  not upgraded.
Sorry, but the following packages have unmet dependencies:
  alsa-utils: Depends: libc6 (>= 2.1.97) but 2.2.2-4 is to be installed
  asclock: Depends: libc6 (>= 2.2.1-2) but 2.2.2-4 is to be installed
  asclock-themes: Conflicts: asclock (< 2.0.12) but 2.0.12-3 is to be installed
  awe-midi: Depends: libawe0.4 but 0.4.3.1-1.2 is to be installed
Depends: libc6 (>= 2.2.2-2) but 2.2.2-4 is to be installed
Depends: libncurses5 (>= 5.2.20010310-1) but 5.2.20010318-1 is to 
be installed
  battleball: Depends: libc6 (>= 2.1.97) but 2.2.2-4 is to be installed
  bluefish: Depends: libglib1.2 (>= 1.2.0) but 1.2.10-1.1 is to be installed
Depends: libtiff3g but 3.5.5-3 is to be installed
  c2man: Depends: libc6 (>= 2.1.2) but 2.2.2-4 is to be installed
  clanlib0-common: Depends: libbz2 but 0.9.5d-4 is to be installed
   Depends: libhdf4g (>= 4.1r3) but 4.1r4-5 is to be installed
  craft: Depends: libc6 (>= 2.2.1-2) but 2.2.2-4 is to be installed
  debhelper: Depends: file (>= 3.23-1) but 3.33-4 is to be installed
 Depends: lynx
  debmake: Depends: file but 3.33-4 is to be installed
   Depends: patch but 2.5.4-3 is to be installed
  deity-curses: Depends: libc6 (>= 2.2.2-2) but 2.2.2-4 is to be installed
  dhelp: Depends: libc6 (>= 2.1.2) but 2.2.2-4 is to be installed
  dia: Depends: dia-common (= 0.86-7) but 0.86-7 is to be installed
  diald: Depends: libc6 (>= 2.2.2-2) but 2.2.2-4 is to be installed
 Depends: ppp (> 2.2) but 2.4.1-1 is to be installed
  doc-base: Conflicts: dhelp (< 0.3.14) but 0.3.23 is to be installed
  dpkg-perl: Depends: perl5
 Depends: libnet-perl but 1.0703-4.1 is to be installed
  dupload: Depends: perl (>= 5.003) but 5.6.0-21 is to be installed
   Depends: libnet-perl but 1.0703-4.1 is to be installed
  dwww: Depends: perl but 5.6.0-21 is to be installed
  enlightenment: Depends: libungif4g (>= 4.1-1) but 4.1-6 is to be installed
  evolution: Depends: libjpeg62 but 6b-1.3 is to be installed
 Depends: libldap2 (>= 2.0.2-2) but 2.0.7-5 is to be installed
 Depends: liboaf0 (>= 0.6.5) but 0.6.5-5 is to be installed
 Depends: libtiff3g but 3.5.5-3 is to be installed
  flex: Depends: libc6 (>= 2.1.2) but 2.2.2-4 is to be installed
  freeciv-xaw3d: Depends: freeciv (>= 1.10) but 1.11.4-3 is to be installed
 Depends: xaw3dg (>= 1.3-1) but 1.5-7 is to be installed
  freetype2-dev: Depends: libc6-dev but 2.2.2-4 is to be installed
 Conflicts: freetype0-dev but it is not installable
 Conflicts: freetype1 (<= 1.0.0.1998-03-22-1) but 
1.0.0.1998-03-22-4 is to be installed
  gabber: Depends: libgnomemm1.1 but 1.1.17-1 is to be installed
  gglyph: Depends: libc6 but 2.2.2-4 is to be installed
  libgtkhtml7: Depends: libgtk1.2 (>= 1.2.10-1) but 1.2.10-1 is to be installed
   Depends: libunicode0 (>= 0.4.0-2) but 0.4.0-2 is to be installed
E: Internal Error, InstallPackages was called with broken packages!

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "If it is possible, as much as it depends on you, live 
  peaceably with all men."Romans 12:18 

Re: build depends on kernel-headers

[Sam Hartman]

> "Herbert" == Herbert Xu <[EMAIL PROTECTED]> writes:

Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> We do?  please explain what it is.  Herbert produces kernel
>> headers packages for all flavors of kernels he produces.  I do
>> not believe the other arches do this.

Herbert> You obviously weren't listening to me when I explained
Herbert> this in the bloat thread.  If you aren't compiling a
Herbert> kernel module, then the flavoued kernel headers packages
Herbert> do not exist for you, period.  

I thought Manoj's comments applied to modules.

Re: build depends on kernel-headers

[Herbert Xu]

Sam Hartman <[EMAIL PROTECTED]> wrote:

> We do?  please explain what it is.  Herbert produces kernel headers
> packages for all flavors of kernels he produces.  I do not believe the
> other arches do this.

You obviously weren't listening to me when I explained this in the bloat
thread.  If you aren't compiling a kernel module, then the flavoued kernel
headers packages do not exist for you, period.
-- 
Debian GNU/Linux 2.2 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: Finishing the FHS transition

[Joey Hess]

Chris Waters wrote:
> > - A change in the policy to remove the obsolete /usr/doc symlinks.
> 
> This is supposed to happen once enough packages make the transition.

No, it is supposed to happen one release _after_ a release in which all
the packages have made the transition. So sarge at the earliest, not woody.

-- 
see shy jo

Re: Caching Proxy for apt-get via http?

[idalton]

On Sun, May 06, 2001 at 03:05:12PM +0100, Andrew Suffield wrote:
> On Sun, May 06, 2001 at 07:54:17AM +0200, Harald Dunkel wrote:
> > Does anybody out there know what is the problem here? Maybe its
> > the failure of Apache. What are your suggestions for running a
> > cache for apt-get?
> 
> Umm... how about "apt-proxy"?

If you don't mind running (and debugging) experimental code..

Has a particularly hard time with round-robin mirrors not being in-sync,
or (I think) occationally a mirror not supporting rsync access at all.
Also has trouble with over-returning to the client. FE will return 5MB
of a 200k deb.. And it requires rsync access to the repository.

Despite all this, I did find it working a bit better on my dialup
connection than squid was.

Oh yeah, you'll want to give it a big cache, too. It doesn't seem to be
able to clean its own cache properly.

-- Ferret

Re: build depends on kernel-headers

[Sam Hartman]

> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:

>>> "Aaron" == Aaron Lehmann <[EMAIL PROTECTED]> writes:
Aaron> So you're saying it's better to hardcode syscall numbers
Aaron> and stuff than using the kernel headers? Sre...

Manoj>  We already have a process for packages that actually
Manoj> do need kernel headers, and are thus dependent on
Manoj> particular kernel versions. 

We do?  please explain what it is.  Herbert produces kernel headers
packages for all flavors of kernels he produces.  I do not believe the
other arches do this.

Re: build depends on kernel-headers

[Herbert Xu]

On Sun, May 06, 2001 at 03:45:39PM +0200, Adrian Bunk wrote:
> 
> What do you suggest in my specific case with util-linux?

Which specific program in util-linux and what specific headers?

> You mean every upstream source should ship it's own kernel headers?

Yes, they should ship their own headers for kernel data structures and they
need to maintain it so that it works across kernel versions.

> That's ugly and it reminds me that libtool does the same (every program
> tht uses libtool ships it's own copy of libtool) - and every time I
> compile a program that uses libtool under NetBSD/sparc-1.5 I must do a
> "libtoolize --force" to prevent a miscompilation of the libraries - it
> would be much more easy when the programs would use a locally installed
> libtool instead.

Well someone's got to maintain the kernel/user space interface.  If it
isn't glibc (which does it for most things), then it's whoever uses it.
-- 
Debian GNU/Linux 2.2 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: Bug#96224: libgmp3: Move documentation in the -dev package

[Christian Marillat]

 "DS" == Dale Scheetz <[EMAIL PROTECTED]> writes:

[...]

DS> I can be convinced on either count. How would you feel about my presenting
DS> this issue to the "developers" at large, with you and I agreeing to follow
DS> the concensus of the group?
>> 
>> Go ahead.

DS> At this point that seems a waste of time ... I've had a nights sleep on
DS> it, and I'm currently leaning toward the extreme solution.

So I forward this myself.

DS> Arguments:

DS> 1. It's been like this forever...
DS> 2. No one (with the exception of Christian) has ever asked that it be
DS> moved, and several requests have been made for additional documentation.
DS> 3. The documentation is development in nature, and should go into the -dev
DS> package.
DS> 4. The info, demos, and docs sections are about as large as the libraries
DS> themselves. Removing them from the runtime is a 50% savings.

5. You can't build demos source if the -dev package isn't installed.
6. Example files should be installed in /usr/lib//examples
According to the Debian Policy chapter 13.7

DS> Conclusion:

DS> While the principle of "least surprise" is important, it should not be
DS> used to stifle progress. Moving the docs and demos out of the runtime
DS> package is a significant "bloat" reduction. Moving them into -dev is not.
DS> Making a third package -doc, containing the info, doc, and demo sections
DS> now found in the runtime package makes the most sense. Thus a
DS> non-development system can still have complete documentation when needed
DS> without either the runtime or the -dev packages installed. (screw 'em if
DS> they can't find it ;-)

"My" conclusion:

You can't build demos source if the -dev package isn't installed. And the
info documentation is *really* for developper. This package contain
libraries, so an end user don't need to know how to program this library.

Christian

Re: Who uses ccmalloc?

[Gordon Sadler]

On Sun, May 06, 2001 at 10:28:56PM +0200, J.H.M. Dassen (Ray) wrote:
> On Sun, May 06, 2001 at 19:31:43 +0200, Adrian Bunk wrote:
> > J.H.M. Dassen (Ray) ([EMAIL PROTECTED])   ccmalloc
> 
> To the best of my knowledge, there's no upstream for ccmalloc anymore. I'm
> not using it myself, and there are several (possibly better) alternatives
> available. I'm therefore pondering dropping it, unless someone can convince
> me it's still being used.
>

It is maintained upstream, just moved a bit...:
http://www.inf.ethz.ch/personal/biere/projects/ccmalloc

Last change(webpage): 5 Feb 01
Version: 0.3.4 (dated 5 Mar 01)

I still use it sparingly, I'm no expert with it. Think I use dmalloc the
most, possible electric-fence as well.

Gordon Sadler

Re: Finishing the FHS transition

[Steve Greenland]

On 06-May-01, 14:27 (CDT), Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Policy says:
>
> <--  snip  -->
>
>  In the source package's `Standards-Version' control field, you must
>  specify the most recent version number of this policy document with
>  which your package complies.  The current version number is 3.5.4.0.
>
>  This information may be used to file bug reports automatically if your
>  package becomes too much out of date.
>
> <--  snip  -->

Uhh, when did that become a "must"? In 3.5.2 the first paragraph
says

 You should specify the most recent version of the packaging
 standards with which your package complies in the source package's
 `Standards-Version' field.

Even in 3.5.4, towards the end of that section it says
  
 You should regularly, and especially if your package has become out
 of date, check for the newest Policy Manual available and update   
 your package, if necessary. When your package complies with the new
 standards you should update the Standards-Version source package   
 field and release it.

It says nothing about uploading just to notify that you "are still
compliant".

Hmmm, I don't remember a proposal to change this; I suspect the "must"
slipped in during the recent rewrites, and as Chris Waters pointed out, it
is certainly inconsistent with the intent of the field according to recent
discussion.

> "you must specify the most recent version number of this policy document
> with which your package complies": You must upgrade this field when your
> package complies with a more recent policy - and when your package does
> already comply with a more recent policy nothing more than an upload with
> an updated Standards-Version field is needed.

Nonsense. I'm not going to upload new versions of packages simply to
change that field. Lot's of policy updates have zero effect on most
packages, and I doubt many of our users want to spend the time and
money downloading and installing a new version of a package to confirm
that.  I would strongly object if (for example) Branden suddenly started
uploading new versions of the X packages every time a new version of
policy was released.

I'll wait a few days for one of the policy editors to say "Oops, that
was an accident"; if that's not the case, I need to propose an ammendent
that clarifies reality, so that Adrian doesn't get mislead again :-).

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: libggi2 and testing?

[Adrian Bunk]

On Sun, 6 May 2001, Anthony Towns wrote:

> On Sun, May 06, 2001 at 11:27:13PM +1000, Drew Parsons wrote:
> > Is there any reason why libggi2 from unstable is not in testing?  All
> > architectures have now been compiled, being all present and up-to-date in
> > the pool, but update-excuses gives no hints as to why it hasn't been
> > accepted in testing.  It (update-output) mumbles something incoherent about
> > the package on alpha, but it's now been built for alpha.
>
> Yup, but the version on alpha depends libc6.1 >= 2.2.3-1 or so, and
> libc6 2.2.3-1 doesn't build on i386...

After two build failures (because of broken gcc and fileutils) it did
finally build and I did upload it to incoming.

If no new problems arise and Ben doesn't upload a new version it will go
into testing in four days.

> Cheers,
> aj

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Proposing task-debian

[Rob Browning]

John Hasler <[EMAIL PROTECTED]> writes:

> How about an ordinary meta-package named "emacs"?

That might be OK.  Bear in mind that there used to be a real package
named emacs, though, so you should be wary of breaking upgrades from
very old systems.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

Who uses ccmalloc?

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

On Sun, May 06, 2001 at 19:31:43 +0200, Adrian Bunk wrote:
> J.H.M. Dassen (Ray) ([EMAIL PROTECTED])   ccmalloc

To the best of my knowledge, there's no upstream for ccmalloc anymore. I'm
not using it myself, and there are several (possibly better) alternatives
available. I'm therefore pondering dropping it, unless someone can convince
me it's still being used.

Ray
-- 
Cyberspace, a final frontier. These are the voyages of my messages, 
on a lightspeed mission to explore strange new systems and to boldly go
where no data has gone before. 

Re: Finishing the FHS transition

[Marcus Brinkmann]

On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote:
> Policy says:
> 
> <--  snip  -->
> 
>  In the source package's `Standards-Version' control field, you must
>  specify the most recent version number of this policy document with
>  which your package complies.  The current version number is 3.5.4.0.
> 
>  This information may be used to file bug reports automatically if your
>  package becomes too much out of date.
> 
> <--  snip  -->

Ok, please ignore my other mail.

Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

Re: Finishing the FHS transition

[Marcus Brinkmann]

On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
>   If noone has a good argument against this I'll send
>   RC bugs in one week to force the upgrade of the Standards-Version.

The packages inetutils, gnumach, hurd and mig are only applicable to the Hurd,
and we have not determined yet how much and what of the FHS is applicable to
us. Most of it is, but we might need an appendix for the Hurd just as there is
an appendix for Linux.

In any way, I will bump the number if it makes you happy on my next update,
and Jeff Bailey took over maintenance of GNU inetutils, he is
preparing an update, but I wouldn't consider an old standards
version a release critical bug.  You will have to bother and check each
package individually if there is actually a violation of current policy or
a critical bug that warrants a release critical bug report.

> GNU Hurd Maintainers (bug-hurd@gnu.org)  gnumach
> GNU Hurd Maintainers (bug-hurd@gnu.org)  hurd
> GNU Hurd Maintainers (bug-hurd@gnu.org)  mig
> Marcus Brinkmann ([EMAIL PROTECTED])inetutils

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

Re: Bug#96102: ITP: serpento -- dictd server written in python

[Radovan Garabik]

On Sat, May 05, 2001 at 12:24:56PM +0200, I wrote:
> On Fri, May 04, 2001 at 09:19:29AM +0200, Tollef Fog Heen wrote:
> > * Radovan Garabik 
> > 
> > | > Can it be run from inetd? I'm really dying for a dict server that can be
> > | 
> > | More or less, yes, it can, but currently it is a bit unusable
> > | since it takes forever to start (it has to parse the index file(s),
> > | and parsing is written in python - rewritting it in C is on my TODO list)
> > 
> > Why not just using cPickle and smart caching?  It's pretty fast, ime.
> > 
> 
> well, that is a _really_ good idea, shame it did not occur to me :-)
> I am going to experiment with it a bit
> 

And it's done - using cPickle cut down startup time from 15 seconds
to about 4 sec.
Then I changed initialization to parse/unpickle index files only 
when the database is accessed for the first time, and 
startup time went down to about 1 second for biggest dictionary
(webster). All on PIII 600 MHz with plenty of memory (i.e. 
all necessary files were already in buffer cache)

Package is in incoming, you have to set up manually inetd.conf if
you want to run it from inetd (this will be improved later)

Also, it includes its own dictdconfig now, so automatic configuration
to include all installed databases should work.

-- 
 ---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

menu and FHS (was Re: Finishing the FHS transition)

[Chris Waters]

On Sun, May 06, 2001 at 09:13:26PM +0200, Arthur Korn wrote:

> /usr/lib/menu is not shareable

Yes, it is.  There's a reason why each entry starts:

  ?package()

Anyway, that's not really relevent -- /usr/share is for
architecture-independent static files.  The FHS doesn't grant
exceptions for files that would cause breakage if they actually were
shared between different machines.

cheers
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Finishing the FHS transition

[Adrian Bunk]

On Sun, 6 May 2001, Chris Waters wrote:

> > I want to suggest to finish the FHS transition. This includes the
> > following steps:
>
> > - Packages with Standards-Version >= 3.0 must follow the FHS.
>
> Didn't we already have this discussion?  The Standards-Version field
> is not a reliable indication of much of anything.  I strongly object

Policy says:

<--  snip  -->

 In the source package's `Standards-Version' control field, you must
 specify the most recent version number of this policy document with
 which your package complies.  The current version number is 3.5.4.0.

 This information may be used to file bug reports automatically if your
 package becomes too much out of date.

<--  snip  -->

> to removing packages because of what amount to cosmetic issues, and an

Where did I say that I want to remove the packages???
I said that I want to send bug reports.

> incorrect Standards-Version (one that doesn't reflect the version of
> policy that the package _actually_ complies with) is really no more
> than a cosmetic issue (no software actually uses that field).

"you must specify the most recent version number of this policy document
with which your package complies": You must upgrade this field when your
package complies with a more recent policy - and when your package does
already comply with a more recent policy nothing more than an upload with
an updated Standards-Version field is needed.

> I only have a few of the listed packages installed on my system, but
> most of the ones I checked did indeed use /usr/share/doc (and
> /usr/share/man, in those cases where man pages were present).  I
> suspect that this is due to the use of debhelper, but anyway
>
> Checking for FHS violations should be done by checking for FHS
> violations, not by checking an unreliable and all-but-meaningless
> field in some configuration file.
>...

See above: I want to file a RC bug either because
a) the package follows a too old policy or
b) because it violates the _must_ in the polict that says that the
   Standard-Version must get updated.

a) needs discussion whether we consider packages not following the FHS
"too much out of date", b) is a violation of the policy that doesn't need
discussion - that means the only question is whether anyone disagrees that
we want to have all packages in unstable to follow the FHS.

> cheers

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Finishing the FHS transition

[Arthur Korn]

Chris Waters schrieb:
> (Plus, as a side issue, by a strict reading of the FHS, we should be
> using /usr/share/menu rather than /usr/lib/menu, which means RC bugs
> against nearly every package in the system!)  :-)

/usr/lib/menu is not shareable, since it would be most confusing
to have a menu item that just doesn't work, because the package
it belongs to is installed on another machine with which
/usr/share is shared.

ciao, 2ri
-- 
Q: How does a Unix guru have sex?
A: gunzip && strip && touch && finger && mount && fsck && \
   more && yes && fsck && fsck && fsck && umount && sleep

mailq's fake output

[Stefano Zacchiroli]

Another change in sendmail = another little problem :)))

Seriously: few days ago mailq isn't runnable by normal user, as Richard
told me.
Now the things are changed, if an user (even if he is a member of mail
group) run mailq he always get:

  /var/spool/mqueue is empty
 Total requests: 0

even if there are mails in the sendmail queue !!!

I'm talking about sendmail 8.11.3+8.12.0.Beta7-6, it this problem fixed
in -7 version ?

Cheers!

-- 
- Zack -

Stefano Zacchiroli <[EMAIL PROTECTED]> ICQ# 33538863
Home Page: http://www.students.cs.unibo.it/~zacchiro
Undergraduate Student of Computer Science at University of Bologna, Italy
SysAdm of verdicchio.students.cs.unibo.it (130.136.3.134)
"Information wants to be Open"


pgpAHujwu53N2.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Chris Waters]

On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:

> I want to suggest to finish the FHS transition. This includes the
> following steps:

> - Packages with Standards-Version >= 3.0 must follow the FHS.

Didn't we already have this discussion?  The Standards-Version field
is not a reliable indication of much of anything.  I strongly object
to removing packages because of what amount to cosmetic issues, and an
incorrect Standards-Version (one that doesn't reflect the version of
policy that the package _actually_ complies with) is really no more
than a cosmetic issue (no software actually uses that field).

I only have a few of the listed packages installed on my system, but
most of the ones I checked did indeed use /usr/share/doc (and
/usr/share/man, in those cases where man pages were present).  I
suspect that this is due to the use of debhelper, but anyway

Checking for FHS violations should be done by checking for FHS
violations, not by checking an unreliable and all-but-meaningless
field in some configuration file.

(Plus, as a side issue, by a strict reading of the FHS, we should be
using /usr/share/menu rather than /usr/lib/menu, which means RC bugs
against nearly every package in the system!)  :-)

> - A change in the policy to remove the obsolete /usr/doc symlinks.

This is supposed to happen once enough packages make the transition.
Now, if we're really down to 253 packages that use /usr/doc (with no
symlink), then maybe it's time.  But, unfortunately, that number, 253,
measures *claimed* compliance, not actual compliance.

Now, my poking around suggests that there are actually far *fewer*
than 253 packages still using /usr/doc.  And if that's true, then it's
definitely time to remove the symlinks.  But it might be nice to have
some hard facts, rather than speculation based on unreliable claims
made by inattentive package maintainers.

> Ben Gertzfield ([EMAIL PROTECTED])  wmifs
> Eric Leblanc ([EMAIL PROTECTED])groovycd
> Eric Leblanc ([EMAIL PROTECTED])zangband
> Gene McCulley ([EMAIL PROTECTED])  xcopilot
> Javier Fernandez-Sanguino Pen a ([EMAIL PROTECTED])   spellcast
> Luis Francisco Gonzalez ([EMAIL PROTECTED])  xgammon
> Rob Browning ([EMAIL PROTECTED]) emacs20
> Robert Woodcock ([EMAIL PROTECTED]) cd-discid
> Takuo KITAME ([EMAIL PROTECTED])   bbdb
> Vincent Renardias ([EMAIL PROTECTED])   gdb
> Vincent Renardias ([EMAIL PROTECTED])   gnumeric
> Wichert Akkerman ([EMAIL PROTECTED])   sed

I inspected these packages.  Only emacs20 lacked the /usr/share/doc
directory.  If that ratio holds true (which I doubt), then we've only
got 21 packages left to transition! :-)

cheers
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Voltaire will be unavailable for a bit

[Daniel Jacobowitz]

Voltaire is about to move temporarily across the country.  It should be
available again in about a week; it might take as long as two.

Debian/PowerPC may languish a little bit in its absence :(

-- 
Daniel Jacobowitz   Debian GNU/Linux Developer
Monta Vista Software  Debian Security Team

Re: Finishing the FHS transition

[Adrian Bunk]

On Sun, 6 May 2001, Oliver Elphick wrote:

> Adrian Bunk wrote:
>  ...
>   >Oliver Elphick ([EMAIL PROTECTED])   libpgsql
>
> This package is obsolete and should not be included in any release.

Please ask the ftp admins to remove the package from unstable (file a bug
against ftp.debian.org).

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Finishing the FHS transition

[Oliver Elphick]

Adrian Bunk wrote:
 ...
  >Oliver Elphick ([EMAIL PROTECTED])   libpgsql

This package is obsolete and should not be included in any release.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "If it is possible, as much as it depends on you, live 
  peaceably with all men."Romans 12:18 

Finishing the FHS transition

[Adrian Bunk]

Hi,

I want to suggest to finish the FHS transition. This includes the
following steps:

- Packages with Standards-Version >= 3.0 must follow the FHS.
  Policy version 3.0.0.0 was released 30 Jun 1999 and I consider this
  enough time for every maintainer to switch to at least this
  Standards-Version. However, there are still 253 packages in unstable
  (including contrib, non-free and non-US/*) that have an older
  Standards-Version in the control file. The list (sorted by maintainer)
  follows below. Some of the maintainers are perhaps MIA, others are
  definitely not. If noone has a good argument against this I'll send
  RC bugs in one week to force the upgrade of the Standards-Version.

- A change in the policy to remove the obsolete /usr/doc symlinks.


List of packages with Standards-Version < 3.0

<--  snip  -->

Adam Di Carlo ([EMAIL PROTECTED])   onshore-timesheet
Adam Klein ([EMAIL PROTECTED])   ncompress
Alan Bain ([EMAIL PROTECTED]) nec
Alex Romosan ([EMAIL PROTECTED])   f77reorder
Alex Romosan ([EMAIL PROTECTED])   nte
Alex Romosan ([EMAIL PROTECTED])   vat
Alistair Cunningham ([EMAIL PROTECTED])xchain
Anders Hammarquist ([EMAIL PROTECTED])  sformat
Andreas Franzen ([EMAIL PROTECTED])   pgapack
Anthony Fok ([EMAIL PROTECTED])lexmark7000linux
Anthony Towns ([EMAIL PROTECTED])   cruft
Anthony Towns ([EMAIL PROTECTED])   distributed-net-pproxy
Apt Packaging Team ([EMAIL PROTECTED]) gnome-apt
Araki Yasuhiro ([EMAIL PROTECTED])   kcc
Arpad Magosanyi ([EMAIL PROTECTED])barracuda
Avery Pennarun ([EMAIL PROTECTED]) apmd
Avery Pennarun ([EMAIL PROTECTED]) netselect
Avery Pennarun ([EMAIL PROTECTED]) wvdial
Ben Gertzfield ([EMAIL PROTECTED])  gimp
Ben Gertzfield ([EMAIL PROTECTED])  wmifs
Bernd Schumacher ([EMAIL PROTECTED])   snmptraplogd
Björn Brenander ([EMAIL PROTECTED])   tcputils
Brad Bosch ([EMAIL PROTECTED])id-utils
Brent A. Fulgham ([EMAIL PROTECTED])   bbmail
Brent A. Fulgham ([EMAIL PROTECTED])   efuns
Brent A. Fulgham ([EMAIL PROTECTED])   openacs
Brian Bassett ([EMAIL PROTECTED])sml-nj
C. Thomas ([EMAIL PROTECTED])   wmheadlines
Carey W. Evans ([EMAIL PROTECTED])x3270
Chad Miller ([EMAIL PROTECTED]) sc
Charles Briscoe-Smith ([EMAIL PROTECTED])  bock
Charles Briscoe-Smith ([EMAIL PROTECTED])  cup
Charles Briscoe-Smith ([EMAIL PROTECTED])  gramofile
Charles Briscoe-Smith ([EMAIL PROTECTED])  infocom
Charles Briscoe-Smith ([EMAIL PROTECTED])  int-fiction
Charles Briscoe-Smith ([EMAIL PROTECTED])  jlex
Charles Briscoe-Smith ([EMAIL PROTECTED])  libggidemos
Charles Briscoe-Smith ([EMAIL PROTECTED])  propsel
Charles Briscoe-Smith ([EMAIL PROTECTED])  recite
Charles Briscoe-Smith ([EMAIL PROTECTED])  rocks-n-diamonds
Charles Briscoe-Smith ([EMAIL PROTECTED])  saytime
Charles Briscoe-Smith ([EMAIL PROTECTED])  strn
Charles Briscoe-Smith ([EMAIL PROTECTED])  xggi
Chris Leishman ([EMAIL PROTECTED])  cfs
Chris Leishman ([EMAIL PROTECTED])  urlredir
Christian Hammers ([EMAIL PROTECTED])myodbc2.50.26
Christian Leutloff ([EMAIL PROTECTED]) rxtx
Christian Meder ([EMAIL PROTECTED]) afbackup
Christian Meder ([EMAIL PROTECTED]) ftape-doc
Christian Meder ([EMAIL PROTECTED]) ftape-tools
Christoph Lameter ([EMAIL PROTECTED])wmf
Christoph Martin ([EMAIL PROTECTED]) pgp5i
Christophe Le Bars ([EMAIL PROTECTED])  doc-debian-fr
Chu-yeon Park ([EMAIL PROTECTED])rat
Clint Adams ([EMAIL PROTECTED])  set6x86
Craig Sanders ([EMAIL PROTECTED])   dlocate
Craig Sanders ([EMAIL PROTECTED])   libdevel-symdump-perl
Craig Sanders ([EMAIL PROTECTED])   libfile-tail-perl
Craig Sanders ([EMAIL PROTECTED])   speedy-cgi-perl
Craig Sanders ([EMAIL PROTECTED])   tkinfo
Dale E. Martin ([EMAIL PROTECTED])tyvis
Dale James Thompson ([EMAIL PROTECTED])   postilion
Daniel Martin ([EMAIL PROTECTED])cqcam
Daniel Martin ([EMAIL PROTECTED])tkdesk
Darren Benham ([EMAIL PROTECTED]) wmcpu
Darren Benham ([EMAIL PROTECTED]) wmdate
Darren Benham ([EMAIL PROTECTED]) wmgrabimage
Darren Benham ([EMAIL PROTECTED]) wmwe

Re: Installing debs in ~user/ or /usr/local?

[Marcus Brinkmann]

On Sat, May 05, 2001 at 02:33:45PM -0700, Alexander Hvostov wrote:
> I'm beginning to think a better solution would be an operating
> system within an operating system, and let the user play in her `own'
> system, and while it for all intents and purposes seems to be running on bare
> metal, it really is a virtual machine. That would be quite fantastic for doing
> normally privileged operations without a security risk, though.

In the Hurd, any user can boot a sub-Hurd system off a root filesystem
image. (root means root filesystem, has nothing to do with the user root).

In this sub-Hurd, it appears that the user has indeed control over a new
instance of the Hurd operating system.  The root filesystem can contain
different software than the "default" system.  From the default system, the
processes run under the id of the user, but within the sub-Hurd, the user
can acquire super-user privileges (uid 0).  No permissions leak outside the
sub Hurd.

sub-Hurds can be nested of course.

There is currently no virtualization implemented: All direct kernel accesses
(hardware access etc) are simply forwarded to the systems kernel. However,
the kernel is used for few things: As a microkernel based system, most of
the functionality lives in user space kernels (which are duplicated in the
sub Hurd).

However, the boot process (the command used to boot the sub-Hurd) can
intervene such kernel calls and virtualize them.  This is something that
interested people can work on.  Indeed, you can implement whatever
functionality you want.  Again, systems security is strictly preserved by
the default servers (modulo bugs ;).

> For that to work, you'd also need to set up a base system for each and
> every developer. That would waste a lot of disk space in a hurry. Perhaps
> copy-on-write file links would do the trick here, allowing root to keep a 
> central
> repository of a prototypical base system, and allowing each developer to 
> change it at
> will,

For the Hurd we plan something called "shadowfs".  shadowfs will allow to
stack filesystems in a single view.  For example, you could join a read-only
ext2fs filesystem and a tmpfs (in RAM) over it.  Files in the tmpfs would
shade the underlying ext2fs files, and new files would be created in the
tmpfs, too.  This way you get the "copy-on-write" trick you imagined.

But that's not all.  Ideally, such a shadowfs implementation would merge
multiple filesystem trees, for example the system tree (ro) plus a user
provided "root" filesystem.  Then you can use this shadowfs to boot a
sub-Hurd from, running from the default system usually but running from your
files where they exist.  This way you can test new servers in the sub Hurd
with minimal cost.  Oh, did I mention that all sub Hurd processes appear in
the parents sub Hurd process table? This way you can attach gdb to them
(from the outside) and debug them like any other process (even
"system-critical" servers).  Of course, if the sub Hurd crashes, the parent
systems are not affected.

> but without wasting disk space unless something actually changes. Of course,
> that means big changes in the kernel's VFS code and possibly elsewhere, but
> copy-on-write links would be way cool for other reasons as well[1-2].

In Linux, yes.  This would be close to impossible to implement securely
without rewriting major parts of the kernel (possibly all).  The Hurd
provides the substantial features and design paradigms today (there are
bugs, and there are missing features like full virtualization and shadowfs,
but booting a sub Hurd for example works).

> [3] I understand Microsoft has done something like that in one of their
> operating systems or another. It was on Slashdot a while back. Most people
> said that what they `invented' are really just symlinks, but the major
> difference is that they're copy-on-write, whereas writing to a symlink
> on Unix will write to the file pointed to, but overwriting a symlink will
> overwrite the symlink, not the file pointed to this; is a
> pseudo-copy-on-write behavior, but not real copy-on-write like what MS
> did. Of course, they attached some lame marketroid buzzword TLA to it,
> but `copy-on-write link' works for me. ;)

If you want such a thing, you can implement this as a Hurd filesystem server
and run it as a user. You don't need to recompile, install and boot a new
kernel.  You just attach your server to some directory ("mount" if you
want), and go.  You'd probably violate some POSIX requirements with such a
thing, but you don't need to limit yourself to it.  The Hurd is a POSIX
system in its default configuration, but the idea of the Hurd is that any
user can extend the system in such ways you describe (and others) without
asking anyone.

For the far future, giving shadowfs, I'd be interested in a simple packaging
system which allows to install multiple version of a single package, and
which allows users to install packages.  Basically, users packages would be
mirrored over the root filesystem 

Re: build depends on kernel-headers

[Manoj Srivastava]

>>"Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes:

 Adrian> I maintain util-linux that is a user space package that needs
 Adrian> many kernel headers (and the package in unstable compiles
 Adrian> only with 2.4 kernel headers). I do currently use the kernel
 Adrian> haeaders libc6-dev ships.  Would it be the right solution to
 Adrian> copy the 2.4.4 kernel headers into the package and use them?

Depends on how often the structures you depend on change. I
 would assume that you are OK with any fairly recent kernel includes,
 such as those provided by libc. If not, I would expect to see
 util-linux-2.4.4 out there soon. 

manoj
-- 
 Love IS what it's cracked up to be.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: build depends on kernel-headers

[Manoj Srivastava]

>>"Aaron" == Aaron Lehmann <[EMAIL PROTECTED]> writes:

 Aaron> So you're saying it's better to hardcode syscall numbers and stuff
 Aaron> than using the kernel headers? Sre...

We already have a process for packages that actually do need
 kernel headers, and are thus dependent on particular kernel
 versions. Are you also sure you have considered the impact of using
 one set of kernel structures, and linking with a libc that uses
 perhaps an incompatible set of kernel-structures? 

Kernel modules are loaded into the kernel, and thus are in the
 kernel's context, but user space modules, linked with libc, are
 playing with fire when they assume that the incompatible kernel
 structures they have been compiled with are not going to cause
 problems. 

If your package does meet the criteria, it is extremely rare,
 and I do not think it is wirth the infrastructure to cater to the
 very few packages that shall meet these criteria.

manoj
-- 
 Under deadline pressure for the next week.  If you want something, it
 can wait. Unless it's blind screaming paroxysmally hedonistic...
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: build depends on kernel-headers

[Manoj Srivastava]

>>"Itai" == Itai Zukerman <[EMAIL PROTECTED]> writes:

 Itai> Why not have the default KSRC be /usr/src/kernel-headers-X.X?  I
 Itai> think that's what Ben suggested...

Are you aware that that is what we used to do, circa libc5
 days? And that we have moved away from that, for all the reasons that
 have been posted here several time before? (look at README.headers in
 the kernel-package docs for a blow by blow account). 

manoj
-- 
 It's all magic.  :-) --Larry Wall in <[EMAIL PROTECTED]>
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: build depends on kernel-headers

[Manoj Srivastava]

>>"Anthony" == Anthony Towns  writes:

 Anthony> All I want is to be able to build ipmasqadm... (It needs ip_masq.h,
 Anthony> which used to be in libc6-dev, but isn't any longer)

 % cp /path/to/old/kerhnel/source/include/linux/ipmasq.h ipmasq.h

manoj

-- 
 The mosquito exists to keep the mighty humble.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

A Quebecer in France.

[Fabien Ninoles]

Sorry, this message is for people currently living in France where
I'm going this summer.  I'm a little too much lazy to translate it
currently and I expect the people interested will be able to read it
in French.  Thanks!

===

Bon, c'est juste un email envoyé sur plusieurs ML pour vous
avertir de ma visite en France du 23 juin au 9 juillet.

Je serai sur Paris du 23 au 25 juin, puis ensuite LaRochelle du 25 au 28
juin, suivi d'Audenges (Bassin d'Arcachon) le 28 et 29 juin pour
finalement terminé mon voyage à Bordeaux à partir du 30 (avec la
conférence sur Debian et le Logiciel Libre).

J'ai bien hâte de rencontrer tous ces visages électroniques, d'échanger
des poignées de mains et d'intéressantes discussions, et je serais aussi
disponible pour signer vos clefs PGP pour les intéressés.

Merci et à la prochaine,
Fabien.

PS: SVP, attention au reply... n'oubliez pas de retirer les ML dont vous ne
faites pas parti ou en m'écrivant directement à mon adresse personnel
(voir signature ci-bas).

-- 
---*  *-
Fabien Niñoles/  /  [EMAIL PROTECTED]
Chevalier Servant de Sa Dame /  /   C15D FE9E BB35 F596 127F
Veneur Gris par la Clef /  /BF7D 8F1F DFC9 BCE0 9436
Développeur pour Debian/  / http://www.tzone.org/~fabien
--*  *--

Re: About native packages

[Rob Browning]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> It's different when the Debian maintainer is also upstream. It is argued
> that then there's only one `debianization'. That's all right but please
> consider the following cases before making your package Debian native:
> - Do you want to release a new upstream version to fix a missing build
>   dependency?

And further-

  What if your program outlives your interest in it?  i.e. what if
  someone else takes it over upstream eventually, and they're not a
  Debian developer?

I tend to think that in many cases, preserving the upstream/Debian
distinction is wise, even if not totally necessary ATM.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

ITP: wmfinder -- A graphical file manager for WindowMaker

[Simon Richter]

retitle 80278 ITP: wmfinder -- A graphical file manager for WindowMaker
thanks

Hi,

I intend to package wmfinder, which is a Qt based file manager for
WindowMaker. The packaging will take some time, as the program currently
uses Qt 1.45, which has been dropped. I'm talking to upstream about
converting it to Qt 2.

Program home page is http://www.imago.ro/wmfinder , license is GPL 2.

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: DC26 EB8D 1F35 4F44 2934  7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: Caching Proxy for apt-get via http?

[Andrew Suffield]

On Sun, May 06, 2001 at 07:54:17AM +0200, Harald Dunkel wrote:
> Does anybody out there know what is the problem here? Maybe its
> the failure of Apache. What are your suggestions for running a
> cache for apt-get?

Umm... how about "apt-proxy"?

-- 
Andrew Suffield <[EMAIL PROTECTED]>


pgp1umND2vBVo.pgp
Description: PGP signature

Re: Chrony mailing list needs a home

[Filip Van Raemdonck]

On Fri, May 04, 2001 at 09:48:54PM -0500, John Hasler wrote:
> Joey Hess writes:
> > Well I guess you could use sourceforge.
> 
> I assume that the author has his reasons for not wanting to use
> Sourceforge.

I believe sunsite.auc.dk does provide services to opensource projects as
well, you may want to take a look at that.

regards,

Filip

-- 
When you are having a bad day, and it seems like everybody is trying to
tick you off, remember that it takes 42 muscles to produce a frown, but
only 4 muscles to  work the trigger of a good sniper rifle.
-- John Galt


pgpYzil3u8MIz.pgp
Description: PGP signature

Re: build depends on kernel-headers

[Adrian Bunk]

On Sun, 6 May 2001, Herbert Xu wrote:

> > I maintain util-linux that is a user space package that needs many kernel
> > headers (and the package in unstable compiles only with 2.4 kernel
> > headers). I do currently use the kernel haeaders libc6-dev ships.  Would
> > it be the right solution to copy the 2.4.4 kernel headers into the package
> > and use them?
>
> It needs to be looked at on a case-by-case basis.  In general though,
> if you need access to something that is not provided by glibc, you'll
> have to setup a local header file and maintain it yourself as new
> kernel releases come out.

What do you suggest in my specific case with util-linux?

> I wouldn't expect the Debian maintainer to have to go through this
> though, as this is something that must be dealt with in the upstream
> util-linux package.

You mean every upstream source should ship it's own kernel headers?
That's ugly and it reminds me that libtool does the same (every program
tht uses libtool ships it's own copy of libtool) - and every time I
compile a program that uses libtool under NetBSD/sparc-1.5 I must do a
"libtoolize --force" to prevent a miscompilation of the libraries - it
would be much more easy when the programs would use a locally installed
libtool instead.


cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: libggi2 and testing?

[Anthony Towns]

On Sun, May 06, 2001 at 11:27:13PM +1000, Drew Parsons wrote:
> Is there any reason why libggi2 from unstable is not in testing?  All
> architectures have now been compiled, being all present and up-to-date in
> the pool, but update-excuses gives no hints as to why it hasn't been
> accepted in testing.  It (update-output) mumbles something incoherent about
> the package on alpha, but it's now been built for alpha.

Yup, but the version on alpha depends libc6.1 >= 2.2.3-1 or so, and
libc6 2.2.3-1 doesn't build on i386...

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)

libggi2 and testing?

[Drew Parsons]

Is there any reason why libggi2 from unstable is not in testing?  All
architectures have now been compiled, being all present and up-to-date in
the pool, but update-excuses gives no hints as to why it hasn't been
accepted in testing.  It (update-output) mumbles something incoherent about
the package on alpha, but it's now been built for alpha.

I ask because my package mirrormagic seems to be held up by libsdl, and
libsdl appears to be held up by libggi2.

Drew

-- 
PGP public key available at http://dparsons.webjump.com/drewskey.txt
Fingerprint: A110 EAE1 D7D2 8076 5FE0  EC0A B6CE 7041 6412 4E4A

Re: build depends on kernel-headers

[Herbert Xu]

On Sun, May 06, 2001 at 12:28:32PM +0200, Adrian Bunk wrote:
> 
> I maintain util-linux that is a user space package that needs many kernel
> headers (and the package in unstable compiles only with 2.4 kernel
> headers). I do currently use the kernel haeaders libc6-dev ships.  Would
> it be the right solution to copy the 2.4.4 kernel headers into the package
> and use them?

It needs to be looked at on a case-by-case basis.  In general though,
if you need access to something that is not provided by glibc, you'll
have to setup a local header file and maintain it yourself as new
kernel releases come out.

I wouldn't expect the Debian maintainer to have to go through this
though, as this is something that must be dealt with in the upstream
util-linux package.
-- 
Debian GNU/Linux 2.2 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: Does BTS clean old bugs?

[Eray Ozkural \(exa\)]

Josip Rodin wrote:
> 
> On Sun, May 06, 2001 at 03:00:56PM +0300, Eray Ozkural (exa) wrote:
> > On the bts web interface, it's written that closed bugs are cleaned
> > up after a period of inactivity. Are they permanently erased?
> > I'd prefer that a complete history of all bugs is preserved.
> 
> They aren't, that sentence is unclear, a bug has already been filed.

Yes, it is a bit ambiguous indeed.

Thanks,

-- 
Eray Ozkural (exa)
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Does BTS clean old bugs?

[Ethan Benson]

On Sun, May 06, 2001 at 03:00:56PM +0300, Eray Ozkural (exa) wrote:
> On the bts web interface, it's written that closed bugs are cleaned
> up after a period of inactivity. Are they permanently erased?
> I'd prefer that a complete history of all bugs is preserved.

they are archived.  thats what the `search archived bugs' option in
the search page is for.  it would be quite a mess if bugs were listed
on packages for eternity after they are closed. 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpIaPrppsOaj.pgp
Description: PGP signature

Re: Does BTS clean old bugs?

[Josip Rodin]

On Sun, May 06, 2001 at 03:00:56PM +0300, Eray Ozkural (exa) wrote:
> On the bts web interface, it's written that closed bugs are cleaned
> up after a period of inactivity. Are they permanently erased?
> I'd prefer that a complete history of all bugs is preserved.

They aren't, that sentence is unclear, a bug has already been filed.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: Caching Proxy for apt-get via http?

[Harald Dunkel]

Harald Dunkel wrote:
> 
> Brian May wrote:
> >
> > Have you told squid that it can use greater then 100MByte (the
> > default)?
> >
> 
> I haven't tried Squid yet, cause Apache was already in place.
> Of course I will try it.
> 

I've got the same effect using Squid. When I tried to install
Xpilot (just for testing of course :-), then some files (not 
all!) were not cached, as it seems. Of course I checked the 
cache size, the maximum file size, etc.

???


Regards

Harri

Does BTS clean old bugs?

[Eray Ozkural \(exa\)]

On the bts web interface, it's written that closed bugs are cleaned
up after a period of inactivity. Are they permanently erased?
I'd prefer that a complete history of all bugs is preserved.

Thanks,

-- 
Eray Ozkural (exa)
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Bug#95975: mutt: doesn't use charset anymore

[Josip Rodin]

On Sun, May 06, 2001 at 07:27:16AM +, Alexander Koch wrote:
> > Just use LC_CTYPE=de_DE. It'll work fine in mutt. (The problem is, if
> > I remember correctly, that X uses ISO8859-1, without the first dash.)
> 
> Ok, but now I am confused...
> 
> LC_CTYPE=de_DE
> LANG=de_DE
> LC_MESSAGES=C
> 
> Should give me german umlauts and the prompts/messages
> should still be like before, right? Do I really not have
> to set ISO-8859-1 somewhere?

Yes, because the locale alias file will assume ISO-8859-1 automatically.

% grep ^de_DE'  ' /usr/lib/X11/locale/locale.alias
de_DE   de_DE.ISO8859-1

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: debian.org

[Rahul Jain]

On Sun, May 06, 2001 at 11:42:28AM +0200, [EMAIL PROTECTED] wrote:
> 
> Hello,
> 
> I hope you can help me. 
> 
> May I ask if your company/organization put MS Word files on your CD's?
> 
>  
> 
> We are the sole distributors of icWord, which is the Microsoft?? word viewer 
> for the Mac. Our SW allows Mac users to view, copy and print Word documents 
> without having to purchase or use Microsoft Word.
> 
> icWord?? viewer is also designed for CD distribution purposes.
> 
>  
> 
> Do you think you could find interest in such a viewer?
> 
> If you have any questions please feel free to contact me.
> 
> Your opinion will be appreciated.
> 

How interesting. I wonder what drugs posessed them to think we'd be
interested in this... :)

-- 
-> -/-   - Rahul Jain -   -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--||--||-|--|-|-|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

Re: build depends on kernel-headers

[Adrian Bunk]

On Sun, 6 May 2001, Herbert Xu wrote:

>...
> > the package not building with the changed kernel or not working after
> > being installed at x*1000 machines?
>
> What is better is a sane local header that works with all kernels.


I maintain util-linux that is a user space package that needs many kernel
headers (and the package in unstable compiles only with 2.4 kernel
headers). I do currently use the kernel haeaders libc6-dev ships.  Would
it be the right solution to copy the 2.4.4 kernel headers into the package
and use them?

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Bug#95975: mutt: doesn't use charset anymore

[Patrick von der Hagen]

On Sun, May 06, 2001 at 07:27:16AM +, Alexander Koch wrote:
[...]
> Should give me german umlauts and the prompts/messages
> should still be like before, right? Do I really not have
> to set ISO-8859-1 somewhere?
You have to set it in /etc/locale.gen. Make sure that there is a line
"de_DE ISO-8859-1" without "#" in front of it. Then call "locale-gen".
-- 
CU,
   Patrick.
"Never run on auto-pilot" - The Pragmatic Programmer


pgpbC2HN16yaH.pgp
Description: PGP signature

Re: Why why why!!???

[Russell Coker]

On Friday 04 May 2001 18:27, Noah L. Meyerhans wrote:
> On Fri, May 04, 2001 at 11:33:58AM -0400, Jaldhar H. Vyas wrote:
> > Oh crap.  Ok guys it's been a lot of fun.  I really enjoyed working with
> > you and meeting some of you in person but now that Debian is going to
> > be shut down I'll have to look for another operating system.
> >
> > Does anyone know if Microsoft Windows is any good?
>
> This should probably not have been sent to the person that originally
> sent in the erroneous "hack" notification.  We can make fun of their
> idiocy all we want, but we shouldn't email them personally with it.

When they repeatedly respond abusively when it is explained what they did 
wrong then why not send it to them?

Also do you really think we should make publically fun of people without 
giving them the courtesy of CCing them in on it?

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: build depends on kernel-headers

[Herbert Xu]

On Sun, May 06, 2001 at 10:43:25AM +0200, Torsten Landschoff wrote:
> On Sun, May 06, 2001 at 03:29:58PM +1000, Herbert Xu wrote:

> > Yes, because otherwise your code probably won't compile.
> 
> ... when the kernel interface changed. Now tell me what is better - 

Nope, they won't compile at all because kernel headers are not designed
to be used in user space programs.  On architectures like the alpha, there
are definitions such as current which will stop any programs that include
headers which in turn include it from compiling.

> the package not building with the changed kernel or not working after
> being installed at x*1000 machines?

What is better is a sane local header that works with all kernels.
-- 
Debian GNU/Linux 2.2 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: build depends on kernel-headers

[Herbert Xu]

Anthony Towns  wrote:

> All I want is to be able to build ipmasqadm... (It needs ip_masq.h,
> which used to be in libc6-dev, but isn't any longer)

For a legacy application like ipmasqadm, the solution is to simply copy
ip_masq.h from a 2.2 kernel tree and be done with it.
-- 
Debian GNU/Linux 2.2 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: build depends on kernel-headers

[Anthony Towns]

On Sat, May 05, 2001 at 03:06:11PM -0500, Manoj Srivastava wrote:
> >>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
>  Ben> False. That is the very thing I want to alleviate (people using kernel
>  Ben> headers from the libc6-dev package).
>   However, that is what 99% of the programs out there need to
>  do, since they really are not dependent on the specifics of kernel
>  structures, and we should discourage un needed dependency on kernel
>  structures. 

All I want is to be able to build ipmasqadm... (It needs ip_masq.h,
which used to be in libc6-dev, but isn't any longer)

>   Now, for the 1% or so of the packages that really are wedded
>  to kernel headers, that is correct. But then these packages should
>  not run on n a kernel version that they were compiled for. (HINT: if
>  your program can run on a kernel different from the one you compiled
>  for, the chances are that you do not need specific kernel headers; at
>  most, you need to say headers from a kernel later than blah). 

Sure, fine, wonderful. How do I do this, exactly?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)

Re: build depends on kernel-headers

[Torsten Landschoff]

On Sun, May 06, 2001 at 03:29:58PM +1000, Herbert Xu wrote:
> On Sun, May 06, 2001 at 01:25:32AM -0400, Itai Zukerman wrote:
> > Also chiming in: Suppose my code reads a struct from a device file.
> > That struct is defined in a kernel header (not part of glibc).  You're
> > saying I should duplicate that header in my source rather than
> > build-depend on kernel-headers-X.X?  Hmmm...
> 
> Yes, because otherwise your code probably won't compile.

... when the kernel interface changed. Now tell me what is better - 
the package not building with the changed kernel or not working after
being installed at x*1000 machines?

cu
Torsten


pgpoW2TD3BPmt.pgp
Description: PGP signature

debian.org

[penny]

 

Hello,
I hope you can help 
me. 
May I ask if your 
company/organization put MS Word files on your CD's?
 
We are the sole 
distributors of icWord, which is the Microsoftֲ® word viewer for the Mac. 
Our SW allows Mac users to view, copy and print Word documents without 
having to purchase or use Microsoft Word.
icWordֲ® viewer is 
also designed for CD distribution purposes.
 
Do you think you could 
find interest in such a viewer?
If you have any 
questions please feel free to contact me.
Your opinion will 
be appreciated.
Thank you,
Penny B.
 
Panergy 
Ltd.
[EMAIL PROTECTED]
 

Re: Bug#95975: mutt: doesn't use charset anymore

[Brian May]

> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes:

Steve> However,

Steve> $ LANG=hr_HR LC_COLLATE=C ls -A
Steve> .A  .B  .C  .a  .b  .c  A  B  C  a  b  c

Steve> which was Arthur's point, I believe.

That means you can't have ls sort in a different order though (as
defined by native language) without messing up the "hidden" files.

IMHO, it seems that ls should (perhaps with a special option which can
be aliased to be the default) treat files with a leading . as special,
and put these before the other files. After all, the leading . is not
defined by the language being used, rather it is a hack used by many
user level programs that consider the file a "hidden" file.

(sorry if I missed the point of all of this)
-- 
Brian May <[EMAIL PROTECTED]>

Re: Bug#95975: mutt: doesn't use charset anymore

[Alexander Koch]

On Sat, 5 May 2001 10:57:43 -0700, Ben Gertzfield wrote:
> Just use LC_CTYPE=de_DE. It'll work fine in mutt. (The problem is, if
> I remember correctly, that X uses ISO8859-1, without the first dash.)

Ok, but now I am confused...

LC_CTYPE=de_DE
LANG=de_DE
LC_MESSAGES=C

Should give me german umlauts and the prompts/messages
should still be like before, right? Do I really not have
to set ISO-8859-1 somewhere?

Alexander

-- 
Hackers confuse Xmas (25 Dec) with Halloween (31 Oct)
Alexander Koch - <>< - WWJD - aka Efraim - PGP 0xE7694969 - KOCH1-RIPE

Re: Caching Proxy for apt-get via http?

[Harald Dunkel]

Brian May wrote:
> 
> Have you told squid that it can use greater then 100MByte (the
> default)?
> 

I haven't tried Squid yet, cause Apache was already in place.
Of course I will try it.

Many thanx for your configuration hints.


Regards

Harri

Re: netscape in unstable and mouse capture

[Brian May]

> "Carlos" == Carlos Laviola <[EMAIL PROTECTED]> writes:

Carlos> Well, I don't know the solution for that, but one thing I
Carlos> know for sure now: you're a hell of a touch typist :)

Well... It was only the last paragraph which was completely hidden...

Ooops. Perhaps I shouldn't have said that .
-- 
Brian May <[EMAIL PROTECTED]>

RE: netscape in unstable and mouse capture

[Carlos Laviola]

Well, I don't know the solution for that, but one thing I know for sure now:
you're a hell of a touch typist :)

On 06-May-2001 Brian May wrote:
> Hello,
> 
> As usual I has several windows open. In one window, I had a list
> of options to select, which involved opening up a window with a list
> of selections I can choice.
> 
> At the same time, Netscape popped up a dialog box for another window
> "you are now loading a secure page". However, the mouse was still
> being captured by the pop up window, so I could not push the OK button.
> At the same time, I couldn't make a selection in this pop-up window,
> because Netscape required me to push OK at the first dialog box.
> 
> So feeling a bit irritated, I went to a text mode console, and killed
> netscape with -9 (as the standard kill never seems to work for
> Netscape). Now the mouse is still captured, and I can't access
> anything other then this E-Mail program. (Is this a bug in
> xserver-xfree86 that netscape is now dead, but the mouse is still
> captured, or is that an unavoidable side affect of kill -9?)
> 
> Is there anyway of resolving this situation without killing the X server?
> Sorry, I am currently typing blind, as this window is hidden by another
> window, and I can't change it, so lets see how it comes out
> 
> 
> -- 
> Brian May <[EMAIL PROTECTED]>
> 
> 

-- 
carlos laviola - icq #981913
$ chown us:us /your_base -R
chown: what you say!!

Re: how to implement a renamed package

[Dr. Guenter Bechly]

Hello,

On Sat, May 05, 2001 at 10:23:47PM -0500, Ben Burton wrote:
> Hi.. I've never done this myself, but I'm sure I've seen it happen in the 
> past:  If you're replacing foo with newfoo, you upload a new dummy package 
> foo that contains absolutely nothing, but depends on newfoo.  This way 
> apt-get upgrade will get the latest (empty) foo and thus drag in newfoo with 
> it.

Many thanks. That is probably the best solution currently possible.
I will do it this way, and will request the removal of the dummy package from
the archives after a sufficiently long transition period.

Cheers,
Guenter

-- 
Linux: Who needs GATES in a world without fences?

Re: Installing debs in ~user/ or /usr/local?

[Matt Zimmerman]

On Sat, May 05, 2001 at 02:15:58PM -0700, John H. Robinson, IV wrote:

> On Sat, May 05, 2001 at 10:00:14PM +0200, Egon Willighagen wrote:

> workaround: just extract the data.tar.gz where you want it.
> 
> dpkg-home () {
> [ "$1" ] || { echo "usage: $0  [dir_to_install]"
> return 1 }
> ( cd ${2:-$HOME}
> ar p $1 data.tar.gz | tar xzf - )
> }

Or simply:

dpkg --extract  

-- 
 - mdz

Re: Debconf and substitution in long description

[Simon Richter]

On Sat, 5 May 2001, Joey Hess wrote:

> > The first substitution worked, the second didn't. I suspect this may be
> > because I'm running testing instead of unstable at home. I'll try unstable
> > debconf now.

> That sounds similar to a bug I fixed in 0.9.36.

Indeed the version from unstable works. I'll make the package depend on
debconf >= 0.9.36 then.

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: DC26 EB8D 1F35 4F44 2934  7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: Caching Proxy for apt-get via http?

[Brian May]

> "Harald" == Harald Dunkel <[EMAIL PROTECTED]> writes:

Harald> Hi folks, To reduce network load and speed up upgrades I
Harald> have installed a caching proxy on one of my machines
Harald> (using Apache). But it doesn't work very well. Packages
Harald> are downloaded from http.us.debian.org, even if they
Harald> should have been taken from the cache due to an upgrade of
Harald> another machine just a few minutes ago.

Harald> The cache size is 300 MByte, so I doubt that this happens
Harald> due to lack of space. And cheating Round Robin by using an
Harald> IP address instead of 'http.us.debian.org' didn't help
Harald> either.

Have you told squid that it can use greater then 100MByte (the
default)?

(When I upgraded squid from unstable to stable, I told dpkg to install
the new config file, with the low default limit. squid was
automatically restarted, and it proceeded to remove files from my
cache.  Ooops. Something you have to watch out for)

Harald> Does anybody out there know what is the problem here? 
Harald> Maybe its the failure of Apache. What are your suggestions
Harald> for running a cache for apt-get?

In my squid file, I put in

refresh_pattern \.deb$  43200   100%43200
refresh_pattern Release$720 100%720
refresh_pattern Packages.gz$720 100%720
refresh_pattern Sources.gz$ 720 100%720

to try and eliminate this problem. Seems to work fine. So far...
-- 
Brian May <[EMAIL PROTECTED]>

Re: Caching Proxy for apt-get via http?

[Matt Zimmerman]

On Sun, May 06, 2001 at 07:54:17AM +0200, Harald Dunkel wrote:

> Does anybody out there know what is the problem here? Maybe its
> the failure of Apache. What are your suggestions for running a
> cache for apt-get?

As far as I am aware, Apache's caching functionality is rather primitive.  Try
Squid.

-- 
 - mdz

Re: Installing debs in ~user/ or /usr/local?

[Alexander Hvostov]

On Sat, 5 May 2001 22:35:58 -0400
Matt Zimmerman <[EMAIL PROTECTED]> wrote:

> On Sat, May 05, 2001 at 05:47:21PM -0700, Alexander Hvostov wrote:
> 
> > On Sat, 5 May 2001 19:01:03 -0400 Matt Zimmerman <[EMAIL PROTECTED]>
wrote:
> > > You should look into the S/390 port.
> > 
> > The S/390 port is hardware specific. For obvious reasons (how many
Debian
> > machines are S/390s?), this is inadequate. And anyway, I was referring
to a
> > Linux kernel in a process (ie, it behaves just like any other program,
albeit
> > rather large), not two Linux kernels running separately, which is what
I
> > understand the S/390 port does.
> 
> Hardware support is what is necessary to do what you described (in your
> previous message) at this time.  What you described above sounds more
like
> user-mode Linux.

That's what I was describing. I had forgotten the name. Thanks!

Regards,

Alex.

Caching Proxy for apt-get via http?

[Harald Dunkel]

Hi folks,

To reduce network load and speed up upgrades I have installed a 
caching proxy on one of my machines (using Apache). But it 
doesn't work very well. Packages are downloaded from http.us.debian.org, 
even if they should have been taken from the cache due to an 
upgrade of another machine just a few minutes ago.

The cache size is 300 MByte, so I doubt that this happens due to 
lack of space. And cheating Round Robin by using an IP address
instead of 'http.us.debian.org' didn't help either.

Does anybody out there know what is the problem here? Maybe its
the failure of Apache. What are your suggestions for running a
cache for apt-get?


Regards

Harri

netscape in unstable and mouse capture

[Brian May]

Hello,

As usual I has several windows open. In one window, I had a list
of options to select, which involved opening up a window with a list
of selections I can choice.

At the same time, Netscape popped up a dialog box for another window
"you are now loading a secure page". However, the mouse was still
being captured by the pop up window, so I could not push the OK button.
At the same time, I couldn't make a selection in this pop-up window,
because Netscape required me to push OK at the first dialog box.

So feeling a bit irritated, I went to a text mode console, and killed
netscape with -9 (as the standard kill never seems to work for
Netscape). Now the mouse is still captured, and I can't access
anything other then this E-Mail program. (Is this a bug in
xserver-xfree86 that netscape is now dead, but the mouse is still
captured, or is that an unavoidable side affect of kill -9?)

Is there anyway of resolving this situation without killing the X server? 
Sorry, I am currently typing blind, as this window is hidden by another window, 
and I can't change it, so lets see how it comes out


-- 
Brian May <[EMAIL PROTECTED]>

Re: build depends on kernel-headers

[Herbert Xu]

On Sun, May 06, 2001 at 01:25:32AM -0400, Itai Zukerman wrote:
> 
> Also chiming in: Suppose my code reads a struct from a device file.
> That struct is defined in a kernel header (not part of glibc).  You're
> saying I should duplicate that header in my source rather than
> build-depend on kernel-headers-X.X?  Hmmm...

Yes, because otherwise your code probably won't compile.
-- 
Debian GNU/Linux 2.2 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: build depends on kernel-headers

[Itai Zukerman]

> > The thing is, kernel-headers should not be used at all unless you're
> > compile glibc, or modules.  Anything else will break.
> 
> So you're saying it's better to hardcode syscall numbers and stuff
> than using the kernel headers? Sre...

Also chiming in: Suppose my code reads a struct from a device file.
That struct is defined in a kernel header (not part of glibc).  You're
saying I should duplicate that header in my source rather than
build-depend on kernel-headers-X.X?  Hmmm...

-itai

Re: Bug#95975: mutt: doesn't use charset anymore

[Steven Hanley]

On Fri, May 04, 2001 at 11:20:21PM +0200, Richard Atterer wrote:
> While we're at it: How on earth can I get rid of those
> 
>   Warning: locale not supported by Xlib, locale set to C
> 
> messages? I use LC_CTYPE=de_DE.ISO-8859-1 to get Umlauts etc in mutt. 
> Unfortunately, this produces the above error message with lots of X
> programs - especially annoying when you use at(1); you always get a
> mail with the error message.

I got an error very similar to this. possibly that error, though not only for
mutt. Basically it was for any X program pretty much.

Back when I had an X installation I had compiled myself (4.0.2) on potato. I
had compiled form the instructions with the X source, and got that error with
all programs, it was not till I read the DRI compile howto page a few months
later and saw this instruction

in http://dri.sourceforge.net/doc/DRIcompile.html
===
9.3 Update Locale Information 

To update your X locale information do the following: 

 cd ~/DRI-CVS/build/xc/nls
 ../config/util/xmkmf -a
 make
 make install
===

once I did that it all worked fine and I have not seen the message since.

See You
Steve

-- 
[EMAIL PROTECTED] http://wibble.net/~sjh/
Look Up In The Sky
   Is it a bird?  No
  Is it a plane?  No
 Is it a small blue banana?
YES