Re: ITP: nbd -- supporting utilities for the Linux Kernel's Network Block Device

[wouter]

On Mon, 7 May 2001, Dimitri Maziuk wrote:

> On Mon, May 07, 2001 at 10:32:54PM +0200, [EMAIL PROTECTED] wrote:
> > I intent to package the nbd utilities by Pavel Machek, that support the
> > Network Block Device in the Linux Kernel. 
> 
> There is E (enhanced) NBD by Peter Breuer at http://www.it.uc3m.es/~ptb/nbd
> Any reason you picked nbd over enbd? 

I didn't know it exists... I'll have to look at that.

> -- from what Peter says, enbd has
> a few improvements over nbd...

Probably, if he calls it "enhanced" ;-)

Re: emu10k1-mixer?

[Joseph Carter]

On Tue, May 08, 2001 at 12:12:56AM +0200, Jan Niehusmann wrote:
> Is there a mixer available that supports the advanced mixing features
> of the emu10k1 chip (found on Soundblaster Live) ?

Three of them, actually.


> The only one I know is 'dm', a little but very usefull command line
> tool. As it's not yet in debian, I will ITP it if there are no 
> alternatives.

I've tried to convince Alan Cox and Rui Sousa (primary emu10k1 developer)
that the current CVS version needs to be packaged.  Rui's made the patch
and Alan's considering it for the 2.2.20pres and 2.4.whatever-acs..

You can get the CVS version of the driver at Creative's Linux non-support
site, http://opensource.creative.com ..

In that driver source there are utils/as10k1 and utils/mixer subdirs,
these are what would be really nice to have packaged.  The names of the
binaries in the mixer dir are not really very good, but there's talk of
changing mgr_text to emu_mgr, mixer to emu_mixer, and cmd_line to who
knows what - I'm not even rightly sure how to use that tool yet.  =)


> There is another point I'm not sure about:
> dm is part of the emu10k1-driver-package from http://opensource.creative.com/.
> This package contains some other tools. Although I don't use these tools,
> and I don't know much about them, I think they should be packaged together
> with dm in a package called emu10k1-utils or something like that. On the
> other hand, as I don't even know how to use these tools, it's not clear to
> me if they are working.

Perhaps we cannot retire dm yet, but you definitely want mgr_text and
mixer packaged if for no other reason than that they're a good incentive
to get the CVS driver installed on your machine, they're THAT MUCH nicer
than dm.

FWIW, I've spent some time working on figuring out how mgr_text works.  I
have a pretty good grasp of it now and have written a script to set up my
own settings.  I'd also like to write some scripts which can load and save
mixer settings (OSS and emu10k1) so the handcrafted script config method
will not be needed anymore.

I need a few evenings to turn my notes into user docs on how things work
now and something to load and save settings is going to take a lot more
work or risk being a total hack.


> As Soundblaster Live is a fairly common soundcard, I wonder why there
> are so few tools to use it's features. Being able to route sound from
> any of it's inputs to any output independently is a great thing. And 
> having a programmable DSP should be even greater to people who need it.

I'd attribute it to many factors.  There are two incompatible drivers for
one and they require different tools.  The tools have minimal docs.  If
you have a question about the inner workings of the driver, probably Rui
is the best person to ask - which means most everybody does and the guy
has to be swamped.

I think getting the current driver in the kernels is the best bet.  Once
that happens and the tools are better documented, I think you'll see a bit
more interest in making better tools for the SBLive.

-- 
Joseph Carter <[EMAIL PROTECTED]>Free software developer

I am practicing a fine point of ethics.  It is acceptable to shoot back.
It is not acceptable to shoot first.
-- Zed Pobre



pgppaZLxJI8hx.pgp
Description: PGP signature

Re: PostgreSQL in testing

[Anthony Towns]

On Mon, May 07, 2001 at 06:09:10PM +0100, Oliver Elphick wrote:
> Anthony Towns wrote:
>   >Nah, it's the other way around: one of the php3 binaries in testing
>   >doesn't work with the postgresql in unstable, and the php3 in unstable
>   >doesn't work with the postgresql in testing; ditto some other php3 binary
>   >and apache, and a few other similar things. It gets quite complicated :)
> Is the automatic system capable of handling that (when the versions in
> unstable work together)? or will it need manual intervention?

Nominally the former, but generally the latter. Most of the confusing
transitions like this don't get the point where eveything works together
completely, so I usually end up allowing some part of it to break. (At
least, that's been the case with X4, gcc, and Gnome)

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)


pgpWYOcXp34ly.pgp
Description: PGP signature

Re: Woody Freeze Plans - Progress Report II

[Roland Bauerschmidt]

Adrian Bunk wrote:
> I did perhaps only miss it: You did post some weeks ago a list how much
> each architecture is keeping up with unstable (how many % of the packages
> in unstable are compiled on this architecture). Is there a website with
> these figures regularly updated for all ten architectures (six in potato
> plus the four you mention here)?

http://ftp-master.debian.org/testing/testing_outdate.txt (resp.
unstable_outdate.txt) shows which packages are out of date and at the
end there seem to be some statistics...

Roland

-- 
Roland Bauerschmidt

aptitude 0.1.6 in experimental, please test

[Daniel Burrows]

  Greetings,

  Over the last weekend, I uploaded aptitude 0.1.6 "Are We There Yet?" to
experimental.  This version is mostly just a rewrite around a new UI library,
but has a few bugfixes and often-requested features (such as splitscreening)
that were kept out of 0.0.x for design reasons.

  I would like to declare it fit for human consumption fairly soon, after a
couple more releases to clean up some of the remaining rough edges.  (I also
need to rewrite some of the documentation)  I need people to test it and tell
me what important things from the version currently in unstable are not
available in this version, and of course to find bugs.

  As I said, it's in experimental.  I recommend that you add experimental to
your sources.list and use the pinning feature of a recent apt, but if you
want to download by hand, here's the URL:

http://http.us.debian.org/debian/pool/main/a/aptitude/aptitude_0.1.6-1_i386.deb

(replace http.us with your local mirror; source is available in the same
 directory)

   Thanks,
  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|The only thing worse than infinite recursion |
|is infinite recursion.   |
\ Real Programmers don't have braces. -- http://www.python.org ---/

Re: support for older distributions

[Kenshi Muto]

Hi,

At Mon, 7 May 2001 09:51:24 -0700 (PDT),
Ian Eure wrote:
> i have libssl & openssh 2.5.2p2 for potato at
> http://people.debian.org/~ieure/potato_ssh

Good job.
If you execute 'dpkg-scanpackages . /dev/null | gzip -9 > Packages.gz'
in this directory, we'll be more happy :-)
-- 
Kenshi Muto
[EMAIL PROTECTED]


pgpoMpWk21qMB.pgp
Description: PGP signature

Re: emu10k1-mixer?

[Paul Martin]

On Tue, May 08, 2001 at 12:12:56AM +0200, Jan Niehusmann wrote:
> Is there a mixer available that supports the advanced mixing features
> of the emu10k1 chip (found on Soundblaster Live) ?
> 
> The only one I know is 'dm', a little but very usefull command line
> tool. As it's not yet in debian, I will ITP it if there are no 
> alternatives.

dm is deprecated:

| The dm utility doesn't work with driver versions > 0.7, this may be
| you problem.

mgr_text is the current text mode "mixer", with mixer being the GTK
mixer application.

-- 
Paul Martin <[EMAIL PROTECTED]>

Re: support for older distributions

[Chad C. Walstrom]

On Mon, May 07, 2001 at 02:45:53PM +0200, Russell Coker wrote:
> I would like a version of potato that is not entirely frozen. 
> ...
> I am willing to be involved in back-porting packages (there's many
> things that I back-port for my own use and should share).  
> ... 
> Also we have to consider the long-term view of this.  I would
> like to see back-ports to woody being done in a year's time...

It's not an easy request to address, really.  Opinion is largely
subjective as to what one would find valuable for potato, and you run
into the problem of making "slushy" potato look more like woody.  It's
a catch 22 if you take it too far.

I think the long view on this subject focuses less on back-ports and
more on shorter release cycles.  If we can get release cycles for
stable down to a year or less, back-ports would simply be less
important.

So, contribute your efforts to improving and stabilizing woody, so we
can get it out the door! ;-)

-- 
Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie
http://www.wookimus.net/| s.k.a. gunnarr
Key fingerprint = B4AB D627 9CBD 687E 7A31  1950 0CC7 0B18 206C 5AFD



pgpJiiJ72kfIV.pgp
Description: PGP signature

Re: RFC: Potential solution for module building

[Sam Hartman]

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

Herbert> Sam Hartman <[EMAIL PROTECTED]> wrote:
>> for needs to be determined by the architecture maintainers.
>> For Sparc, modversions are not used so you can probably build
>> one sparc and one sparc64 module.  For i386, you need to build
>> a module for each

Herbert> I haven't read the whole message yet.  But I'd just like
Herbert> say that modversions is not the reason to compile modules
Herbert> for each kernel-image package.  Modversions help you to
Herbert> identify when you need to do that.  

Sure, agreed.  I was being sloppy.  Basically it's up to you as a
kernel-image maintainer to decide what sets of modules you need to
build against.  Since we are looking for an automated solution, we're
going to have to be conservative and may end up building slightly more
modules than we strictly need, but we will at least have modules that work.

Re: New Package snmptrapfmt / Orphaned Package snmptraplogd

[Joey Hess]

Bernd Schumacher wrote:
> I have orphaned snmptraplogd.

Um, I hope you have plans to file a bug on ftp.debian.org to get it
removed eventually, or did you intend to just walk away from it and
leave an obsolete and unmaintained package clutting up the archive?

-- 
see shy jo

Re: ITP: axmail

[Steve Langasek]

Hello Joop,

On Mon, 7 May 2001, Joop Stakenborg wrote:

> I intend to package axmail: a simple mail user agent intended to provide the
> mail functions in xNOS in a Linux ax.25 environment.

> Although the README says: Don't give this one to anyone yet... it is NOT ready
> for distribution!; it seems to work well.

If the README says it's not ready for distribution, have you spoken with the
upstream maintainer yet?  It's wise to take the upstream's feelings into
consideration, since you will have to work with them for as long as you
maintain this package for Debian -- best not to start out on the wrong foot.
:)

Also, please note that you should submit ITPs by filing a bug against the wnpp
package, sending email to [EMAIL PROTECTED] with 'Severity: wishlist' and
subject line 'ITP: '.

Regards,
Steve Langasek
postmodern programmer

ITP: axmail

[Joop Stakenborg]

I intend to package axmail: a simple mail user agent intended to provide the
mail functions in xNOS in a Linux ax.25 environment.

Although the README says: Don't give this one to anyone yet... it is NOT ready
for distribution!; it seems to work well.

Joop
--
Joop Stakenborg - Debian GNU/Linux developer <[EMAIL PROTECTED]>

--> Upgrade from NT to Linux to replace your Microsoft with a
Woody!

emu10k1-mixer?

[Jan Niehusmann]

Is there a mixer available that supports the advanced mixing features
of the emu10k1 chip (found on Soundblaster Live) ?

The only one I know is 'dm', a little but very usefull command line
tool. As it's not yet in debian, I will ITP it if there are no 
alternatives.

There is another point I'm not sure about:
dm is part of the emu10k1-driver-package from http://opensource.creative.com/.
This package contains some other tools. Although I don't use these tools,
and I don't know much about them, I think they should be packaged together
with dm in a package called emu10k1-utils or something like that. On the
other hand, as I don't even know how to use these tools, it's not clear to
me if they are working.

As Soundblaster Live is a fairly common soundcard, I wonder why there
are so few tools to use it's features. Being able to route sound from
any of it's inputs to any output independently is a great thing. And 
having a programmable DSP should be even greater to people who need it.

Jan

-- 
OpenPGP-signierte bzw. -verschlüsselte Mail erwünscht
EMail-Key: 1024D/F12DA065 (=> Keyserver oder auf Anfrage)

Re: New Package snmptrapfmt / Orphaned Package snmptraplogd

[Branden Robinson]

On Mon, May 07, 2001 at 08:49:57PM +0200, Bernd Schumacher wrote:
> snmptrapfmt is an upgrade path to the obsolete debian package snmptraplogd.

Well, thank God for upgrade paths *TO* obsolete software...

-- 
G. Branden Robinson |   You don't just decide to break Kubrick's
Debian GNU/Linux|   code of silence and then get drawn away
[EMAIL PROTECTED]  |   from it to a discussion about cough
http://www.debian.org/~branden/ |   medicine.


pgpM59qJf6v1l.pgp
Description: PGP signature

Re: [users] Re: Where's lame

[Rahul Jain]

On Mon, May 07, 2001 at 10:29:17PM +0200, Joost Kooij wrote:
> On Mon, May 07, 2001 at 03:22:33PM -0400, MaD dUCK wrote:
> > package tree. i would like to adopt the lame mp3 encoder as a debian
> > package and was wondering if there are any objections? is there
> > already a maintainer? can this packet be debianized?
> 
> Alas, you hit on a faq.
> 
> Please look at:
>   http://www.debian.org/devel/wnpp/unable-to-package  
>
> 
> The most recent iteration of the lame discussion can be found at:
>   http://bugs.debian.org/90091
> 
> Maybe looking on the web for "unofficial apt sources" will help you
> find some .debs (or should I say ".debz"? ;-)

the offical lame sources (latest beta) include a debian/ directory, so building
a deb is as easy as debian/rules binary (after you get the build-deps :)

-- 
-> -/-   - 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: RFC: Potential solution for module building

[Herbert Xu]

Sam Hartman <[EMAIL PROTECTED]> wrote:

> for needs to be determined by the architecture maintainers.  For
> Sparc, modversions are not used so you can probably build one sparc
> and one sparc64 module.  For i386, you need to build a module for each

I haven't read the whole message yet.  But I'd just like say that
modversions is not the reason to compile modules for each kernel-image
package.  Modversions help you to identify when you need to do that.
-- 
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]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

>Out of curiosity, apart from linux/autoconf.h; what is the
> difference between the header packages on i386?

include/config/* and include/linux/modules/*.
-- 
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]

Sam Hartman <[EMAIL PROTECTED]> wrote:

> This brings up an interesting point.  While we should work with
> upstream maintainers to fix these problems, we should also try to
> avoid making these programs harder to build on Debian than other
> distributions.  If other distributions are still making headers
> available in such a way that existing software builds, and we do not,
> then we make lives harder for both our users and maintainers.  Yes, it
> may be more correct, but we need to be carefule not to correct our
> users into frustration.  Managing careful transition plans is also an
> important part of correctness.

This is not something that we're doing.  This is a decision taken by the
upstream kernel maintainer(s).
-- 
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

ITP: nbd -- supporting utilities for the Linux Kernel's Network Block Device

[wouter]

I intent to package the nbd utilities by Pavel Machek, that support the
Network Block Device in the Linux Kernel. This block device is essentially
a disk server-protocol, which makes it possible to do swapping over
TCP/IP, or use the device as a filesystem when NFS or other Network
Filesystem Protocols are not sufficient for some reason.

The upstream packages are (for now) available from
http://atrey.karlin.mff.cuni.cz/~pavel/nbd/nbd.html

(Please Cc me any replies, as I'm not subscribed to -devel)

Wouter

Re: [users] Re: Where's lame

[Joost Kooij]

On Mon, May 07, 2001 at 03:22:33PM -0400, MaD dUCK wrote:
> package tree. i would like to adopt the lame mp3 encoder as a debian
> package and was wondering if there are any objections? is there
> already a maintainer? can this packet be debianized?

Alas, you hit on a faq.

Please look at:
  http://www.debian.org/devel/wnpp/unable-to-package
 

The most recent iteration of the lame discussion can be found at:
  http://bugs.debian.org/90091

Maybe looking on the web for "unofficial apt sources" will help you
find some .debs (or should I say ".debz"? ;-)

Cheers,


Joost

RFC: Potential solution for module building

[Sam Hartman]

So, a week or so ago, I asked for comments on some problems I've been
having with the Debian kernel modules build system for modules not in
the Linux source tree.  I'm only dealing with modules for upload to
Debian.  The make-kpkg solution seems to work for individuals building
modules for their own systems, and any areas where it does not work
can probably be addressed with kernel-package bugs.  

I've received a few comments and have also had several informative
side discussions on the issue on IRC and with a few people in person.
I believe I'm ready to  look at proposing a solution to the problem.

First, here is what I want to accomplish:

I want to provide a mechanism for building binary modules for upload
to Debian in an automated manner.  The set of kernel images to build
for needs to be determined by the architecture maintainers.  For
Sparc, modversions are not used so you can probably build one sparc
and one sparc64 module.  For i386, you need to build a module for each
kernel image flavor.  

Ben wants architecture maintainers to be able to build binary
modules to go along with their kernel images.  Herbert implied he'd
rather see module maintainers set up source packages for each
architecture.  I tend to be somewhere in between.   So, it seems that
a solution that allows architecture maintainers to build modules and
that allows module maintainers to build modules would be preferable.
IN most cases you would choose on a module-by-module basis whether it
would be built by the architecture maintainer or by the module maintainer.


I propose creating a set of tools--say call them debmodbuilder--to
help in building modules.  The primary tool would be a script to take
a modules config file and an image-set config  file and to build
modules.

The modules config file would specify which modules to build and which
packages contained the source tarball.  This file would be located in
the debian directory of source packages.  Architecture kernel-image
maintainers could add a module config file to their kernel-image
packages to say what modules to build.  Module maintainers who
maintain modules not build by the kernel-image maintainers could
include trivial module config files in the debian directory of their source
package to identify that their module should be built.  A sample of
what a module config file might look like is included near the bottom
of the message.

The image-set config file would specify which kernel images to
build against.  For each image you would specify the kernel
version and subarchitecture.  For example, Herbert's 386 kernel might
specify a version of 2.4.3 and a subarchitecture of 386.  The
subarchitecture is part of the module package name, but not of the
module installation location under /lib/modules.  The kernel config
file would also specify which set of kernel headers to use; this is
required because for some architectures like sparc, kernel headers are
reused for multiple subarchitectures.  This file would be included in
the debian directory of the architecture-specific kernel-image source
package.  It would also be installed as discussed shortly.  A sample
of what this file might look like is included at the end of the
message. 

In addition to potentially using the tool to help build modules, the
kernel image source package would also include a binary package that
depended on all the appropriate  kernel headers and included a copy of
the kernel config file for module builders to use.


This would require kernel image maintainers for architectures with
binary modules to create such kernel image configuration tool.  I'd be
happy to work with people  to help build automation for this into
existing kernel image source packages.  Then, kernel image maintainers
could build any modules they want to build for their arch, as well as
making it is for module builders to build for their arch.

I'd also be happy to write the module building tools:  I envision
tools to:

* Build the module debs given a module and image-set config file,
  integrating the built debs into debian/files.  This could be called
  from the debian/rules file for architecture-specific kernel-image
  source packages and from the debian/rules files for source packages
  that module maintainers maintain to build their modules.

* Generate appropriate build-depends  for module source packages given
  a module config file.  

* Generate depends: line for the binary package including the kernel
  config file given a image-set config file.

* Generate stanzas for debian/control given a image-set and module config
  file set.  I'm not sure this is useful, although it could allow you
  to get the binary line in your source  dsc file right.


Comments?  If I write these tools and they don't suck, will people be
willing to try using them?


Sample modules config file:

Module: openafs # untars into modules/openafs
Source-Package: openafs-modules-source 
TarFile: /usr/src/openafs.tar.gz #sources of module live here
Archi

Re: [users] Re: Where's lame

[Peter Makholm]

MaD dUCK <[EMAIL PROTECTED]> writes:

> package tree. i would like to adopt the lame mp3 encoder as a debian
> package and was wondering if there are any objections? is there
> already a maintainer? can this packet be debianized?

Please read http://www.debian.org/devel/wnpp/unable-to-package

Make sure that there is a new situation with respect to
the Frauenhoffer patent before proceeding with this.

-- 
hash-bang-slash-bin-slash-bash

Re: [users] Re: Where's lame

[Henrique de Moraes Holschuh]

On Mon, 07 May 2001, MaD dUCK wrote:
> already a maintainer? can this packet be debianized?

See:
http://www.debian.org/devel/wnpp/unable-to-package

People should be using ogg instead of mp3 anyway (unless an ogg-less
hardware device is involved in the chain).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Giram: Request for removal

[Vince Mulhollon]

On 05/07/2001 02:03:33 PM Egon Willighagen wrote:

>> What about a Debian policy to remove packages for which alternatives are
>> available with same or similar functionality *and* for which development
has
>> stopped or almost stopped completely?

All you'll get is endless flamewars about "same or similar" and "stopped".

Personally, for my "Vince Special" Debian CDRoms, I'd like to toast about
seven of the eight vi clones, xemacs, all the "optimized" kernel-images,
original awk, and all the gnome stuff in favor of KDE, but I don't
realistically think my personal biases will have any effect, and I don't
think my personal biases should have any effect on the overall project...

If someone out there likes "Q" but I think it's not a good idea, all I can
do if try to talk them out of it, and thats the way it should be.

Need to clearly define who makes that decision, because obviously the
developers directly involved in the fight (and it will be a fight each
time) will be biased.

Also, that would be a major policy shift away from "if you care enough to
maintain it, we'll let it in if it's legal" to "we'll only let it in if the
cabal likes it".

Of course there is no cabal.

Re: [users] Re: Where's lame

[MaD dUCK]

also sprach David Whedon (on Mon, 07 May 2001 01:10:02PM -0700):
> Lame cannot be included in Debian, please see:
> http://www.debian.org/devel/wnpp/unable-to-package

thanks for the reply(ies). i hope i didn't inconvenience anyone with
my ignorant post. i'll be better in the future, promise!

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
echo Prpv a\'rfg cnf har cvcr | tr Pacfghnrvp Cnpstuaeic

Re: [users] Re: Where's lame

[David Whedon]

Lame cannot be included in Debian, please see:
http://www.debian.org/devel/wnpp/unable-to-package

-David

Mon, May 07, 2001 at 03:22:33PM -0400 wrote:
> hi developers,
> this is my first message, i hope it's appropriate. there's talk going
> on on the users mailing list about lame and its absence from the
> package tree. i would like to adopt the lame mp3 encoder as a debian
> package and was wondering if there are any objections? is there
> already a maintainer? can this packet be debianized?
> 
> thanks,
> 
> martin;  (greetings from the heart of the sun.)
>   \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
> -- 
> humpty was pushed.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

lame

[MaD dUCK]

hi developers,
this is my first message, i hope it's appropriate. there's talk going
on on the users mailing list about lame and its absence from the
package tree. i would like to adopt the lame mp3 encoder as a debian
package and was wondering if there are any objections? is there
already a maintainer? can this packet be debianized?

thanks,

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
humpty was pushed.

Clarifications [ Was Re: Giram: Request for removal ]

[Jérôme Marant]

Steve Greenland <[EMAIL PROTECTED]> wrote:

> Just in case you haven't done so, the standard way to remove a package
> is to file a bug against the package "ftp.debian.org" with subject like
> "Please remove giram packages from the archive", and then list the exact
> pacakages in the body.

There has been a misunderstanding about this thread. I guess I should have
written "I will request for removal" instead of "I'm requesting for removal".
I just intended to inform people about what I intend to do and what are the
reasons for the request. I'm sure some of my arguments applies to many
applications in Debian.

Regards,

--
Jérôme Marant <[EMAIL PROTECTED]>

Re: Finishing the FHS transition

[Chris Waters]

On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote:

> but you can't file 1060 RC bugs at the beginning of a freeze.

Why would you want to?  File 1060 normal bugs before the freeze! (If
you must file 1060 bugs at all -- I hope that's not a habit of yours.)
If we want, we can adjust the severity at freeze time, when,
hopefully, many of those bugs will have been closed.  Or we can say,
"there's just too many left open, realistically, we'll have to leave
this for the next release."

And you still seem to be implying that filing bugs fixes things.  I
may have to retract my earlier apology.  Filing RC bugs _is_ asking
for packages to be removed (especially this close to a freeze) unless
you're planning to NMU if necessary, or know for a fact that someone
else *will* fix the problem.  Saying "oh, it'll just get fixed at the
next bug-squashing party" is a seriously irresponsible attitude, IMO.

For a problem affecting that many packages, I'd rather tackle policy
and see about getting a change that would allow those packages to
remain in the system for a while longer.

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

> You mustn't have to upgrade the Standards-Version field when your package
> doesn't comply with a more recent policy -> a package that doesn't follow
> FHS will never rech Standards-Version 3.0 .

I'm having trouble parsing that.  It sounds like you're saying that
you think it means that if a change in policy does not affect your
package, you *must* reupload to change Standards-Version immediately
or it's an RC bug, but if a change in policy *does* affect your
package, then you don't have to reupload, and it's not a bug at all?

That would be insane.

Policy is not the word of God.  It's our feeble attempt to codify what
we consider to be best practices.  And it needs to be read in that
light.  If your interpretation of policy leads to an insane
conclusion, it's time to ask for a clarification or correction, not to
blindly engage in insane behavior.

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

> Reading the last three sentence I'm glad to hear that you volunteer to do
> all this checks...

I'm not the one who came here saying, "I want to suggest to finish the
FHS transition."  And I'm not the one who came up with a simple
two-step plan which fails to achieve that.

Yes, I have been working on the issue.  No, I probably can't do it
alone.  If you don't want to help, that's fine.  But when someone who
has been studying the issue for the last year tells you that it's not
so easy, maybe -- just maybe -- you should consider listening.

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

Re: Giram: Request for removal

[Jérôme Marant]

En réponse à Peter S Galbraith <[EMAIL PROTECTED]>:

> 
> Hope you're not relying on this message to get the packages
> removed.  You need to file a bug report against ftp.debian.org
> (but I'm sure you know that!  I'm just making sure.)

  Yes, I know this is not the standard procedure. This is just a warning
in order to make sure that noone is interested in adopting it. I probably
should have used a better subject like "RFA otherwise removing".

Jérôme.

Re: [users] Re: Where's lame

[MaD dUCK]

hi developers,
this is my first message, i hope it's appropriate. there's talk going
on on the users mailing list about lame and its absence from the
package tree. i would like to adopt the lame mp3 encoder as a debian
package and was wondering if there are any objections? is there
already a maintainer? can this packet be debianized?

thanks,

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
humpty was pushed.

New Package snmptrapfmt / Orphaned Package snmptraplogd

[Bernd Schumacher]

Hello,

I have orphaned snmptraplogd.
I have uploaded the new package snmptrapfmt.
The reasons can be read in the README.debian file of snmptrapfmt.
I have also attached the description of the control file of snmptrapfmt.

I hope everything is OK !?

Regards
Bernd Schumacher


=== README.debian file of snmptrapfmt 

snmptrapfmt for DEBIAN
-
 
snmptrapfmt is an upgrade path to the obsolete debian package snmptraplogd.
 
Snmptraplogd was developed in earlier days as the debian snmpd package did
not provide (or at least did not start) a snmptrapd. Therefore snmptraplogd
had all the code to receive traps itself and to format it. Now the debian
snmpd package has its own snmptrapd and only the formatting has to be done.
 
Snmptrapfmt offers the formatting functionality as snmptraplogd did but does
no longer conflict with package snmpd. Instead it depends on snmpd now.
 
To achieve this snmpd is configured to call snmptrapfmthdlr. This small
program is called for each trap by default. You could configure it to be
called only for selected traps.
 
The trap data is then forwarded to a local pipe from which snmptrapfmt
picks it up and does further processing.
 
See also: SNMPTRAPFMTHDLR(8) SNMPTRAPFMT(8)
 
Bernd Schumacher <[EMAIL PROTECTED]>  Fri,  4 May 2001 21:09:39 +0200


=== Description of control file of snmptrapfmt 
Package: snmptrapfmt
Description: A configurable snmp trap handler daemon for snmpd.
 This package contains a configurable snmp trap handler daemon for snmpd.
 The output of this trap handler daemon may be specified via a configuration
 file and written to a logfile or to the syslog daemon. During installation
 of this package, the configuration file for the snmptrapd daemon is changed
 (old version is saved) to activate the trap handler. The snmpd and snmptrapd
 daemons are restarted.

Re: Giram: Request for removal

[Egon Willighagen]

On Monday 07 May 2001 19:55, Jérôme Marant wrote:
> > Jérôme, could you please file a ITO (intent to orphan) or maybe even a
> > O:
> > (orphaned) bug against wnpp for giram* ?  The instructions on bug
> > severity
> > and how to do it are in http://www.debian.org/devel/wnpp.  If you've
> > already
> > done that, I apologise for the nitpick.
>
> I did not orphan it because I asked for its removal. The best way to make
> sure everyone is warned about it is mailing debian-devel.

With over 6000 packages in woody, i think this is an interesting point.
What about a Debian policy to remove packages for which alternatives are 
available with same or similar functionality *and* for which development has 
stopped or almost stopped completely?

Egon

²z°]³W¹º¨t¦C....

[¤ý«T¥Í]

Title: New Page 1






景氣不好時要好好規劃理財!
[EMAIL PROTECTED]@




　

debian-new-packages-announce@l.d.o ?

[Piotr Krukowiecki]

Hi

What do you think about making a new list which would be used to
announce new packages in Debian ?
It could be done automatically, when package is uploaded for the first
time. It would contain description of package etc.
DWN includes some info about new packages, but it's not very
informative.

 

-- 
Piotrek  (@ ~)
irc: #Debian.pl

Re: build depends on kernel-headers

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Ben Collins  <[EMAIL PROTECTED]> wrote:
>People should not be using them, but if they do, they should use a
>kernel-headers package, and not rely on the headers in libc6-dev which
>are different on all archs, and change almost every new glibc build. You
>are never guaranteed to get the prefered kernel headers for your program
>(be it a scsi level thing like cdrecord, or mount tools like
>util-linux).

The source of those userland programs should come with a copy of the
required kernel headers, or with its own private definitions of the
kernel interface being used.

At least I understand that is the consensus on linux-kernel nowadays

Mike.

Re: Giram: Request for removal

[Adrian Bunk]

On Mon, 7 May 2001, Henrique de Moraes Holschuh wrote:

>...
> Jérôme, could you please file a ITO (intent to orphan) or maybe even a O:
>...

s/ITO/RFA/
(Request for adoption)

cu
Adrian

-- 

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

Re: rfc1149

[Oliver Elphick]

Hilko Bengen wrote:
  >[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
  >
  >> No, no. Pigeons are ugly horrid things that infest cities and leave
  >> droppings on my car.
  >
  >You mean packet loss?
 
I think it's network overhead.

-- 
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
 
 "Dearly beloved, avenge not yourselves, but rather give
  place unto wrath. For it is written, Vengeance is 
  mine; I will repay, saith the Lord. Therefore if thine
  enemy hunger, feed him; if he thirst, give him drink;
  for in so doing thou shalt heap coals of fire on his 
  head. Be not overcome of evil, but overcome evil with 
  good."  Romans 12:19-21 

Dist-upgrading from potato 2.2r3 to testing

[Eduardo Trapani]

I really don't know where I should be posting this, or to which package
I should file a bug report.  I just hope this will be of use to
somebody.

I got this messages dist-upgrading a sparc *and* a i386 from potato to
testing (more or less the same messages):


Configuring packages ...
Use of uninitialized value at
/usr/lib/perl5/Debian/DebConf/ConfModule.pm line 118,  chunk 3.
Selecting previously deselected package libperl5.6.

(after more installation messages and another apt-get dist-upgrade)

Use of uninitialized value at
/usr/lib/perl5/Debian/DebConf/ConfModule.pm line 118,  chunk 3.

Reading Package Lists...
Building Dependency Tree...
You might want to run `apt-get -f install' to correct these.
Sorry, but the following packages have unmet dependencies:
  g++-2.95: Depends: libstdc++2.10-dev (>= 1:2.95.4) but 1:2.95.2-13 is
installed
  libc6-dev: Depends: libc6 (= 2.1.3-18) but 2.2.2-4 is installed
E: Unmet dependencies. Try using -f.


There were lots of others.  Everything is working now, so I *think* the
upgrade did not break anything.

Eduardo.

Re: Giram: Request for removal

[Jérôme Marant]

> Jérôme, could you please file a ITO (intent to orphan) or maybe even a
> O:
> (orphaned) bug against wnpp for giram* ?  The instructions on bug
> severity
> and how to do it are in http://www.debian.org/devel/wnpp.  If you've
> already
> done that, I apologise for the nitpick.

I did not orphan it because I asked for its removal. The best way to make sure
everyone is warned about it is mailing debian-devel.

> FYI (just in case...), filing a bug against wnpp is a way to document
> that a
> bit better than just emailing -devel.  Also, a bug against
> ftp.debian.org
> should be filled when you decide that nobody stepped up to adopt it, and
> that the package should be removed.

This is what I'm going to do.

Jérôme.

Re: Woody Freeze Plans - Progress Report II

[Peter S Galbraith]

I'll make my question clear.

debian-changelog-mode.el currently allows you to set the
distribution field for an upload to multiple distributions, e.g.

xwatch (2.11-8) frozen unstable; urgency=low

The list of possibilities is currently set to:

  unstable
  frozen
  stable
  frozen unstable
  stable unstable
  stable frozen
  stable frozen unstable
  experimental

I'd like to know if I should change this.

Thanks,
Peter


I wrote:
 
> Anthony Towns wrote:
> 
> > On Mon, May 07, 2001 at 11:32:31AM +0100, Julian Gilbey wrote:
> > > What do you intend doing with distros, BTW?  Will there be three or
> > > four distros?  (Freezing == testing?)  Will the "migration into
> > > testing" scripts be (partially) switched off?  What happens when
> > > someone uploads to unstable?  Will people be able to upload to frozen
> > > during the various parts of various freezes?
> > 
> > There'll probably be three+two: ie, stable, testing, unstable,
> > potato-proposed-updates and woody-proposed-updates.
> > woody-proposed-updates
> > will be for emergencies only.
> 
> So `frozen' will never again be used?
> 
> I wondering what to do with debian-changelog-mode.el (not that I
> need to hurry about this issue!).  Will we ever upload to more
> than one distribution again?  (e.g. "frozen unstable" or 
> "stable unstable")  Or should I delete this capability from
> debian-changelog-mode.el?
> 
> Thanks,
> Peter

Re: Questions to testing/unstable

[Julian Gilbey]

On Mon, May 07, 2001 at 02:49:36PM +0200, Michael Meskes wrote:
> Let's say it takes one week for a package to make it from unstable to
> testing. So what happens if package foo_1.0-1.deb is in testing and
> foo_1.0-2.deb is uploaded and then after five days foo_1.0-3.deb is uploaded
> to unstable. What happens if no grave bug exists againts foo? Is 1.0-2 moved
> to testing after 7 days, or is 1.0-3 moved or do the seven days start anew
> with the upload of 1.0-3? The latter holds if there was a grave bug in
> 1.0-1.

Have to have 10 clear days with the current unstable package in
unstable.  Otherwise, the package which is being proposed for moving
into testing won't have had 10 days of testing.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Question on UNIX sockets

[Dimitri Maziuk]

On Mon, May 07, 2001 at 06:11:13AM +, [EMAIL PROTECTED] wrote:
> Hi,
> 
> My question is :
> 
> Suppose a server is listening to 5 clients, and it has to send a
> message to all the clients, how does the server achieve this task?

A server typically consists of 2 programs: one that listens for
incoming connections, and one that services the connection (that
latter one can be a thread rather then full-weight process). In your
scenario there will be one "master" program and 5 "server"
programs/threads. So, the "master" program would send a 
signal/message/whatever to 5 "server" threads, and they would each 
forward the message to their clients.
This is one way of doing it.

Dima
-- 
E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home)
http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key
Well, lusers are technically human.   -- Red Drag Diva in asr

Re: Giram: Request for removal

[Henrique de Moraes Holschuh]

On Mon, 07 May 2001, Jérôme Marant wrote:
>   I'm requesting giram (giram, giram-gnome, giram-mesa, giram-gnome-mesa)
>   to be removed from Debian for the following reasons:

Jérôme, could you please file a ITO (intent to orphan) or maybe even a O:
(orphaned) bug against wnpp for giram* ?  The instructions on bug severity
and how to do it are in http://www.debian.org/devel/wnpp.  If you've already
done that, I apologise for the nitpick.

>   If someone thinks he/she can work out these problems and that giram is
>   worth staying in Debian (despite all what I said), please adopt it right
>   now. Otherwise, it'll definitly disappear from Debian.

FYI (just in case...), filing a bug against wnpp is a way to document that a
bit better than just emailing -devel.  Also, a bug against ftp.debian.org
should be filled when you decide that nobody stepped up to adopt it, and
that the package should be removed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgp3YsK9WU125.pgp
Description: PGP signature

Re: rfc1149

[Andreas Fuchs]

Today, Hilko Bengen <[EMAIL PROTECTED]> wrote:
>> No, no. Pigeons are ugly horrid things that infest cities and leave
>> droppings on my car.
> You mean packet loss?

ITYM "log entries" as defined in RFC2549.

-- 
Andreas Fuchs, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, antifuchs
Hail RMS! Hail Cthulhu! Hail Eris! All hail Discordia!


pgp5hpx8ODo4p.pgp
Description: PGP signature

Re: Woody Freeze Plans - Progress Report II

[Julian Gilbey]

On Mon, May 07, 2001 at 09:52:42PM +1000, Anthony Towns wrote:
> On Mon, May 07, 2001 at 11:32:31AM +0100, Julian Gilbey wrote:
> > What do you intend doing with distros, BTW?  Will there be three or
> > four distros?  (Freezing == testing?)  Will the "migration into
> > testing" scripts be (partially) switched off?  What happens when
> > someone uploads to unstable?  Will people be able to upload to frozen
> > during the various parts of various freezes?
> 
> There'll probably be three+two: ie, stable, testing, unstable,
> potato-proposed-updates and woody-proposed-updates. woody-proposed-updates
> will be for emergencies only.

So if I upload to "frozen", it will go to woody-proposed-updates?
Will you put in a frozen -> testing symlink?

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: PostgreSQL in testing

[Oliver Elphick]

Anthony Towns wrote:
  >Nah, it's the other way around: one of the php3 binaries in testing
  >doesn't work with the postgresql in unstable, and the php3 in unstable
  >doesn't work with the postgresql in testing; ditto some other php3 binary
  >and apache, and a few other similar things. It gets quite complicated :)

Is the automatic system capable of handling that (when the versions in
unstable work together)? or will it need manual intervention?

-- 
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
 
 "Dearly beloved, avenge not yourselves, but rather give
  place unto wrath. For it is written, Vengeance is 
  mine; I will repay, saith the Lord. Therefore if thine
  enemy hunger, feed him; if he thirst, give him drink;
  for in so doing thou shalt heap coals of fire on his 
  head. Be not overcome of evil, but overcome evil with 
  good."  Romans 12:19-21 

Re: xfs,powerpc, gcc (was Re: RaiserFS PPC status)

[Jason E. Stewart]

"Just a friendly Jedi Knight" <[EMAIL PROTECTED]> writes:

>  Anyway if there is somone outthere willing to try powerpc xfsprogs please
>  point your apt-get at 
> 
> deb ftp://ftp.plukwa.net/debian-local sid main

I would like to but your server is not responding to ftp requests...

jas.

Re: support for older distributions

[Ian Eure]

i have libssl & openssh 2.5.2p2 for potato at
http://people.debian.org/~ieure/potato_ssh

On Mon, 7 May 2001, Russell Coker wrote:
> 
> Currently there are two usable repositories of Potato packages.  There's a 
> repository of kernel-related packages to run 2.4.x kernels on Potato, and 
> there's a repository of LDAP related packages and other things that Wichert 
> is maintaining.
> 
> Both of these are good work, but even combined they don't provide what I 
> consider to be adequate support for Potato.
> 
> I would like a version of Potato that is not entirely frozen.  It should have 
> updates not only for security reasons but also for addition of new programs, 
> and for adding new programs which add significant functionality and don't 
> break things (such as Wichert's LDAP packages).
> 
> To manage this fully through the Debian system we will need support in the 
> BTS for reporting bugs to different people depending on the package version.  
> Is this possible?
> 
> Also we need space to maintain the packages (they shouldn't be THAT big).  
> The aim should be that the maintainer of the woody version should not need to 
> be involved in the backports (unless they want to be involved).
> 
> I am willing to be involved in back-porting packages (there's many things 
> that I back-port for my own use and should share).
> 
> Also we have to consider the long-term view of this.  I would like to see 
> back-ports to woody being done in a year's time...
> 
> 

Re: Questions to testing/unstable

[Henrique de Moraes Holschuh]

On Mon, 07 May 2001, Michael Meskes wrote:
> to unstable. What happens if no grave bug exists againts foo? Is 1.0-2 moved
> to testing after 7 days, or is 1.0-3 moved or do the seven days start anew

The quarantine time is restarted every upload.

> If it is also true with no grave bug, we should encourage developers to wait
> a week between two uploads or else their software won't make it into
> testing.

Developers are supposed to know what they're doing with the urgency field.
It can be used to decrease the quarantine time of a particular upload (and
all subsequent ones until the package manages to get installed in testing).

> wouldn't be suprised if the maintainers didn't even notice that. For

Most of us don't bother too much with testing, unless we're trying to get
something into testing for one particular reason or another (such as, the
package in testing is too damn buggy, or has a security hole).

There are only so many hours in a day, you see.

> instance webmin does not seem to have a release critical bug but it's not in
> testing at all.

This is usually caused by dependencies. A package cannot move into testing
if the packages it depends on are not in testing (or being moved into
testing as well).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpJ0CNBNxFLH.pgp
Description: PGP signature

Giram: Request for removal

[Jérôme Marant]

Hi,

  I'm requesting giram (giram, giram-gnome, giram-mesa, giram-gnome-mesa)
  to be removed from Debian for the following reasons:

  - the upstream author is not responsive (possibly because he's working at
MadrakeSoft)
  - it's development is very slow (8 months between 0.1.7 and 0.1.8)
  - the current version in Debian does not build any more. Neither does the
the current upstream version. Moreover, I'm not experienced enough with
autotools. I contacted the author may times but did not get a reply.
  - it is poorly featured and removing it won't be a big loss for Debian.
  - I'm not using it any more.

  If someone thinks he/she can work out these problems and that giram is
  worth staying in Debian (despite all what I said), please adopt it right
  now. Otherwise, it'll definitly disappear from Debian.

  Cheers,


--
Jérôme Marant <[EMAIL PROTECTED]>

Re: Finishing the FHS transition

[Manoj Srivastava]

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

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

My opinion about the intent that this was meant to convey is
 that when you are building your package, update the standards
 version field to reflect what you comply with.

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

I think this is a flaw in our current policy, and needs to be
 changed. If a package has no bugs (including policy violation bugs
 resulting from not following other must or should directives), then
 it should not need to be updated to just change the standards version
 field; and using the standards version field as a reason ti file bugs
 is just plain wrong.

manoj   
-- 
 What's a cult?  It just means not enough people to make a
 minority. Robert Altman
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]

>>"Sam" == Sam Hartman <[EMAIL PROTECTED]> writes:

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

 Sam> We do?  please explain what it is.

We call these packages kernel modules; and we have a process
 by which you inform make where the relevant kernel headers are to be
 found. make-kpkg automates that somewhat (and make-kpkg can be used
 for packages that are not kernel-modules, you know). 

A modification of this process would be possible; but I
 reietrate that any package that can not deal with the headers in
 /usr/include/linux is very closely dependent on kernel structures,
 and would need to ensure that the kernel-version running has the
 non-public API that it depends on. 

 Sam>  Herbert produces kernel headers packages for all flavors of
 Sam>  kernels he produces.  I do not believe the other arches do this.

This is not relevant.

Out of curiosity, apart from linux/autoconf.h; what is the
 difference between the header packages on i386?

manoj
-- 
 "Nuclear war would really set back cable." Ted Turner
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: rfc1149

[Hilko Bengen]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

> No, no. Pigeons are ugly horrid things that infest cities and leave
> droppings on my car.

You mean packet loss?

-Hilko

Re: xfs,powerpc, gcc (was Re: RaiserFS PPC status)

[Just a friendly Jedi Knight]

On Mon, May 07, 2001 at 04:27:18PM +0200, Just a friendly Jedi Knight wrote:
>  Nathan Scott from SGI send me patch but it didn't work. I now figured some
>  other way to fix that and it seems it partially worked (now it quits with:
 It looks like my "fix" made the trick (i mailed my solution to Nathan Scott
 already) and mkxfs works and now i have one little partition using xfs =o)))
 
> === mkfile ===
> gcc -g -DDEBUG -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   -c -o xfs_mkfile.o xfs_mkfile.c
> xfs_mkfile.c: In function `main':
> xfs_mkfile.c:144: `O_DIRECT' undeclared (first use in this function)
 This one bites me a bit. O_DIRECT is missing from bits/fcntl.h on powerpc
 (at least on my installation and i sure i didn't mess with libc6-dev). It's
 sid/unstable branch. I don't remeber if the intel box i compiled xfsprogs
 was running sid/unstable or woody/testing (and this box is down right now)
 but there was no problem in compiling xfs_mkfile.. Is this another wierdo of
 PowerPC arch? (as is with varargs).

 Anyway if there is somone outthere willing to try powerpc xfsprogs please
 point your apt-get at 

deb ftp://ftp.plukwa.net/debian-local sid main

(there are only xfsprogs, xfslibs-dev and reiserfsprogs patched to run on
powerpc)

-- 
 Robert Ramiega | [EMAIL PROTECTED]  IRC: _Jedi_ | Do not underestimate 
 UIN: 13201047  | http://www.plukwa.net/   | the power of  Source

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

[Dale Scheetz]

On 7 May 2001, Christian Marillat wrote:

>  "DS" == Dale Scheetz <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> DS> More to the point, what did you find wrong with my solution?
> 
> This is Monday syndrome, I've misread you post :-(

Well, I hope things have gotten better ;-)

> 
> I agree with your solution.

Great!

One point, I think you made, was that the demos should really go in
/usr/share/lib/libgmp3/demos.

As these are not really useful components of this packages, and mostly
intended as examples of how you might use the library to write code, I'm
not certain this policy applies.

If you still think they should move into this location, please drop me a
bug report so I don't forget it next weekend when I can next work on the
package again.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-_-
_- aka   Dale Scheetz   Phone:   1 (850) 656-9769 _-
_-   Flexible Software  11000 McCrackin Road  _-
_-   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308_-
_-_-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
  available at: http://www.polaris.net/~dwarf/

Re: Woody Freeze Plans - Progress Report II

[Peter S Galbraith]

Anthony Towns wrote:

> On Mon, May 07, 2001 at 11:32:31AM +0100, Julian Gilbey wrote:
> > What do you intend doing with distros, BTW?  Will there be three or
> > four distros?  (Freezing == testing?)  Will the "migration into
> > testing" scripts be (partially) switched off?  What happens when
> > someone uploads to unstable?  Will people be able to upload to frozen
> > during the various parts of various freezes?
> 
> There'll probably be three+two: ie, stable, testing, unstable,
> potato-proposed-updates and woody-proposed-updates.
> woody-proposed-updates
> will be for emergencies only.

So `frozen' will never again be used?

I wondering what to do with debian-changelog-mode.el (not that I
need to hurry about this issue!).  Will we ever upload to more
than one distribution again?  (e.g. "frozen unstable" or 
"stable unstable")  Or should I delete this capability from
debian-changelog-mode.el?

Thanks,
Peter

¬ü°ê¥Jµo°]¹Ú

[¥¬§Æ]

喂!你想賺錢嗎?   
不要懷疑...我這個美國仔已經開始賺了!
每個月的撥接上網及目前的ADSL都有
了這家公司幫我負擔! 不如馬上行動吧!  
帶
我去A錢=  
　

Re: build depends on kernel-headers

[Sam Hartman]

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


Herbert> I won't look at all of them as this is really the
Herbert> upstream maintainer's job.

This brings up an interesting point.  While we should work with
upstream maintainers to fix these problems, we should also try to
avoid making these programs harder to build on Debian than other
distributions.  If other distributions are still making headers
available in such a way that existing software builds, and we do not,
then we make lives harder for both our users and maintainers.  Yes, it
may be more correct, but we need to be carefule not to correct our
users into frustration.  Managing careful transition plans is also an
important part of correctness.

Re: Woody Freeze Plans - Progress Report II

[Adrian Bunk]

On Mon, 7 May 2001, Anthony Towns wrote:

>...
> There are four ports, any of which may want to try for a woody release:
> hurd-i386, mips, hppa and ia64. If they do, they need to ensure that
>...

I did perhaps only miss it: You did post some weeks ago a list how much
each architecture is keeping up with unstable (how many % of the packages
in unstable are compiled on this architecture). Is there a website with
these figures regularly updated for all ten architectures (six in potato
plus the four you mention here)?

> Cheers,
> aj

Thanks in advance
Adrian

-- 

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

xfs,powerpc, gcc (was Re: RaiserFS PPC status)

[Just a friendly Jedi Knight]

On Mon, May 07, 2001 at 08:03:57AM -0500, Rahul Jain wrote:
> On Mon, May 07, 2001 at 12:00:34PM +0200, Just a friendly Jedi Knight wrote:
> > On Sun, May 06, 2001 at 09:58:02PM -0500, Rahul Jain wrote:
> > > On Mon, May 07, 2001 at 12:03:43AM +0200, Just a friendly Jedi Knight 
> > > wrote:
> ...
> > > you should stick to gcc 2.95 for compiling the kernel, and probably the
> > > userspace tools, too.
> >  Most probably you are right.. I used gcc-3.0 because i heard that it
> >  compiles reiserfs code (big endian) correctly. So far i have no problems
> >  with kernel built with gcc-3.0 
> 
> I don't really know of anyone who's using a gcc-3.0-compiled XFS kernel. You
> might want to check on the mailing list as to how well it does with XFS.
 I guess that my mention about using gcc-3.0 was not that good. To clearify a
 bit kernel compiled with gcc-3.0 runs just fine (ok XFS part is not used
 now). The real point thou is that kernel compiles without problems and
 xfsprogs do not compile. 
 Nathan Scott from SGI send me patch but it didn't work. I now figured some
 other way to fix that and it seems it partially worked (now it quits with:
=== mkfile ===
gcc -g -DDEBUG -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   -c -o xfs_mkfile.o xfs_mkfile.c
xfs_mkfile.c: In function `main':
xfs_mkfile.c:144: `O_DIRECT' undeclared (first use in this function)
xfs_mkfile.c:144: (Each undeclared identifier is reported only once
xfs_mkfile.c:144: for each function it appears in.)
make[1]: *** [xfs_mkfile.o] Error 1

(i'm writing this at the same as it's compiling). This should be easier to
solve 

> You need MORE optimization to enable inlining. Inlining reduces debuggability
> and increases executable size for the benefit of not having to set up a whole
> new stack frame and possibly being able to optimize the function in the 
> special
> context of where it's called from. Maybe -O2 will fix it?
 Already tried this.

-- 
 Robert Ramiega | [EMAIL PROTECTED]  IRC: _Jedi_ | Do not underestimate 
 UIN: 13201047  | http://www.plukwa.net/   | the power of  Source

Re: PostgreSQL in testing

[Anthony Towns]

On Mon, May 07, 2001 at 03:50:28PM +0200, Michael Meskes wrote:
> > The real problem will've been that postgresql probably needs to be
> > updated at the same time as php3 and apache and python and a handful of
> IMO it shouldn't depend on any of these and it probably does not. :-)

Nah, it's the other way around: one of the php3 binaries in testing
doesn't work with the postgresql in unstable, and the php3 in unstable
doesn't work with the postgresql in testing; ditto some other php3 binary
and apache, and a few other similar things. It gets quite complicated :)

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)


pgpFQu5BwI8Ii.pgp
Description: PGP signature

Re: PostgreSQL in testing

[Michael Meskes]

On Mon, May 07, 2001 at 10:22:19PM +1000, Anthony Towns wrote:
> A serious bug is enough to keep a package out of testing; it's even enough
> to get it pulled from testing if it's already there, especially one that's
> almost a year old...

Sure. I meant to say that I was surprised that this bug is still open.

> The real problem will've been that postgresql probably needs to be
> updated at the same time as php3 and apache and python and a handful of

IMO it shouldn't depend on any of these and it probably does not. :-)

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

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

[Gerd Flaig]

Alexander Hvostov <[EMAIL PROTECTED]> writes:

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

you may be interested in

   http://user-mode-linux.sourceforge.net/

Goodbyte, Gerd.
-- 
Gerd Flaig Technik[EMAIL PROTECTED]
Bei Schlund + Partner AG   Erbprinzenstr. 4-12  D-76133 Karlsruhe


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Christian Marillat]

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

[...]

DS> More to the point, what did you find wrong with my solution?

This is Monday syndrome, I've misread you post :-(

I agree with your solution.

Christian

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

[Gerd Flaig]

Alexander Hvostov <[EMAIL PROTECTED]> writes:

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

you may be interested in

   http://user-mode-linux.sourceforge.net/

Goodbyte, Gerd.
-- 
Gerd Flaig Technik[EMAIL PROTECTED]
Bei Schlund + Partner AG   Erbprinzenstr. 4-12  D-76133 Karlsruhe

Re: RaiserFS PPC status

[Rahul Jain]

On Mon, May 07, 2001 at 12:00:34PM +0200, Just a friendly Jedi Knight wrote:
> On Sun, May 06, 2001 at 09:58:02PM -0500, Rahul Jain wrote:
> > On Mon, May 07, 2001 at 12:03:43AM +0200, Just a friendly Jedi Knight wrote:
...
> > you should stick to gcc 2.95 for compiling the kernel, and probably the
> > userspace tools, too.
>  Most probably you are right.. I used gcc-3.0 because i heard that it
>  compiles reiserfs code (big endian) correctly. So far i have no problems
>  with kernel built with gcc-3.0 

I don't really know of anyone who's using a gcc-3.0-compiled XFS kernel. You
might want to check on the mailing list as to how well it does with XFS.

...
>  If it's not clear it's libxfs.a (which is in the same source tree) that
>  causes problems.. There is no error while compiling sources of libxfs
>  itself. Only when ld tries to link with that (freshly built) library
> 
> > 
> > maybe your GCC isn't inlining the function?
>  most probably this is the case.. I thought it's matter of optimization but i
>  get the same even if i turn off optimization (-O0)

You need MORE optimization to enable inlining. Inlining reduces debuggability
and increases executable size for the benefit of not having to set up a whole
new stack frame and possibly being able to optimize the function in the special
context of where it's called from. Maybe -O2 will fix it?

> > 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.
> 
>  From what i gather it just can't find code for __fswab64 "function".

I have no idea how an extern inline function should be compiled, so I can't
really say what gcc should be doing here...

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

Questions to testing/unstable

[Michael Meskes]

Let's say it takes one week for a package to make it from unstable to
testing. So what happens if package foo_1.0-1.deb is in testing and
foo_1.0-2.deb is uploaded and then after five days foo_1.0-3.deb is uploaded
to unstable. What happens if no grave bug exists againts foo? Is 1.0-2 moved
to testing after 7 days, or is 1.0-3 moved or do the seven days start anew
with the upload of 1.0-3? The latter holds if there was a grave bug in
1.0-1.

If it is also true with no grave bug, we should encourage developers to wait
a week between two uploads or else their software won't make it into
testing.

I switched my system from unstable to testing and after several weeks I
still have packages installed that are not available in testing and I
wouldn't be suprised if the maintainers didn't even notice that. For
instance webmin does not seem to have a release critical bug but it's not in
testing at all.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

support for older distributions

[Russell Coker]

Currently there are two usable repositories of Potato packages.  There's a 
repository of kernel-related packages to run 2.4.x kernels on Potato, and 
there's a repository of LDAP related packages and other things that Wichert 
is maintaining.

Both of these are good work, but even combined they don't provide what I 
consider to be adequate support for Potato.

I would like a version of Potato that is not entirely frozen.  It should have 
updates not only for security reasons but also for addition of new programs, 
and for adding new programs which add significant functionality and don't 
break things (such as Wichert's LDAP packages).

To manage this fully through the Debian system we will need support in the 
BTS for reporting bugs to different people depending on the package version.  
Is this possible?

Also we need space to maintain the packages (they shouldn't be THAT big).  
The aim should be that the maintainer of the woody version should not need to 
be involved in the backports (unless they want to be involved).

I am willing to be involved in back-porting packages (there's many things 
that I back-port for my own use and should share).

Also we have to consider the long-term view of this.  I would like to see 
back-ports to woody being done in a year's time...

-- 
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: PostgreSQL in testing

[Anthony Towns]

On Mon, May 07, 2001 at 11:22:46AM +0200, Michael Meskes wrote:
> But more important I wonder why postgresl 6.5.3 is still in testing and not
> 7.0.*. After all 7.1 has been released some weeks ago. 
> Looking into the bug tracking system I found that there is one bug against
> postgresql tagged serious. Is this the reason? But the bug is 345 days old!

A serious bug is enough to keep a package out of testing; it's even enough
to get it pulled from testing if it's already there, especially one that's
almost a year old...

The real problem will've been that postgresql probably needs to be
updated at the same time as php3 and apache and python and a handful of
other software, which hasn't all been stable and consistent and bug-free
since testing got rolled out. (It's problem at the moment is it's getting
uploaded every few days. Hopefully when that settles down it'll go in)

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)


pgp2Nm2SYiVV2.pgp
Description: PGP signature

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

[Dale Scheetz]

On 7 May 2001, Christian Marillat wrote:

>  "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:
> 
> SMR> Hi Christian & Dale,
> 
> Hi,
> 
> [...]
> 
> SMR> If Dale has agreed to do move the docs (either to -dev or to -doc),
> SMR> that seems to me to answer the bug report.  I don't understand what
> SMR> question Christian's posting to -devel is supposed to raise.
> 
> Dale said in his conclusion :
> 
> 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 ;-)

So, asside from "screw 'em" what's wrong with this statement?

Putting the docs in a separate package means that you can choose to read
the docs without installing either the runtime or the -dev packages. You
are also free to install any combination of the three that suites your
needs. As the runtime and the docs packages are both about the same size,
I saw no reason to bulk up the -dev package with unnecessary cruft.

Luck,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-_-
_- aka   Dale Scheetz   Phone:   1 (850) 656-9769 _-
_-   Flexible Software  11000 McCrackin Road  _-
_-   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308_-
_-_-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
  available at: http://www.polaris.net/~dwarf/

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

[Dale Scheetz]

On 6 May 2001, 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.
> 
> 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.

So, the demo code is not really to be built, but is just for study. If you
really want to build it, you are obviously going to need the devel
package. I guess the docs could suggest -dev.

> 6. Example files should be installed in /usr/lib//examples
> According to the Debian Policy chapter 13.7

This doesn't determine what package it goes in...

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

YOU think the info docs are only for developers. I think anyone could wish
to read and understand them. I'm not sure I understand your last sentance.
What does the fact that the runtime contains libraries have to do with
programming the library?

More to the point, what did you find wrong with my solution?

Waiting is,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-_-
_- aka   Dale Scheetz   Phone:   1 (850) 656-9769 _-
_-   Flexible Software  11000 McCrackin Road  _-
_-   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308_-
_-_-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
  available at: http://www.polaris.net/~dwarf/

PostgreSQL in testing

[Michael Meskes]

What's up with that package? The files in /var/lib/apt/lists/ say:
Filename: dists/potato/main/binary-i386/misc/postgresql_6.5.3-23.deb

I do not have stable listed in my apt-sources file btw.

Looking into /var/lib/dpkg/available I do not find postgresql at all and
dselect says:
*** Opt misc postgresql   7.0.3-4 7.0.3-4 Object-relational SQL[...]

So the first question is, why do these sources differ in the information the
give me?

But more important I wonder why postgresl 6.5.3 is still in testing and not
7.0.*. After all 7.1 has been released some weeks ago. 

Looking into the bug tracking system I found that there is one bug against
postgresql tagged serious. Is this the reason? But the bug is 345 days old!

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: Woody Freeze Plans - Progress Report II

[Anthony Towns]

On Mon, May 07, 2001 at 11:32:31AM +0100, Julian Gilbey wrote:
> What do you intend doing with distros, BTW?  Will there be three or
> four distros?  (Freezing == testing?)  Will the "migration into
> testing" scripts be (partially) switched off?  What happens when
> someone uploads to unstable?  Will people be able to upload to frozen
> during the various parts of various freezes?

There'll probably be three+two: ie, stable, testing, unstable,
potato-proposed-updates and woody-proposed-updates. woody-proposed-updates
will be for emergencies only.

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)


pgp1AWGHDI927.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Julian Gilbey]

On Sun, May 06, 2001 at 03:52:57PM -0500, Steve Greenland wrote:
> Uhh, when did that become a "must"? In 3.5.2 the first paragraph
> says
> 

Probably during the policy/packaging merger.  I intend at some point
to go through policy and fix all of these confusions.  Furthermore, it
makes no sense for the issue to be talked about in two different
places, either.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Woody Freeze Plans - Progress Report II

[Julian Gilbey]

On Mon, May 07, 2001 at 06:56:45PM +1000, Anthony Towns wrote:
> Being optimistic, this means:
> 
>   * Policy goes into debugging mode on 1st June, and no further
> changes may be made after about 20th June.
> 
>   * Base packages must have all release-critical bugs fixed by
> 1st July, and no further changes may be made after about 20th July.
> [...]

Great stuff!

What do you intend doing with distros, BTW?  Will there be three or
four distros?  (Freezing == testing?)  Will the "migration into
testing" scripts be (partially) switched off?  What happens when
someone uploads to unstable?  Will people be able to upload to frozen
during the various parts of various freezes?

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Many ports open by default

[Turbo Fredriksson]

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

>> *beep, wrong* :)
>> 
>> update-rc.d -f exim remove
>> 

Steve> *beep*, *wrong* :)

Steve> The problem with "update-rc.d -f exim remove" is that it
Steve> removes *all* the links, not just the S*exim links.

Yes. That's a bug in the tool, not a fault in the solution :)

-- 
 Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just 
 ^/ /(_)_ __  _   ___  __  selective about who its friends are 
 / / | | '_ \| | | \ \/ /   Debian Certified Linux Developer  
  _ /// / /__| | | | | |_| |>  <  Turbo Fredriksson   [EMAIL PROTECTED]
  \\\/  \/_|_| |_|\__,_/_/\_\ Stockholm/Sweden

counter-intelligence kibo cracking Peking quiche munitions attack SDI
radar Delta Force tritium toluene president Uzi Iran
[See http://www.aclu.org/echelonwatch/index.html for more about this]

Re: gcc error - xfsprogs, ppc

[Just a friendly Jedi Knight]

On Mon, May 07, 2001 at 12:13:30PM +0200, Just a friendly Jedi Knight wrote:
> > As for why __fswab64 is undefined, try using -O2 instead of -O1.  AFAIK
> > functions are not inlined at -O1.
>  I;ll try that but hmm shouldn't compile also fail on f.ex. i386 ? 
 -O2 doesn't fix this... any other ideas? 

-- 
 Robert Ramiega | [EMAIL PROTECTED]  IRC: _Jedi_ | Do not underestimate 
 UIN: 13201047  | http://www.plukwa.net/   | the power of  Source

Re: build depends on kernel-headers

[Herbert Xu]

On Mon, May 07, 2001 at 01:50:45AM +0200, Adrian Bunk wrote:
> 
> (I tried my best but I can't garuantee this is 100% complete...)

I won't look at all of them as this is really the upstream maintainer's job.

> fdisk:
> linux/unistd.h

This one is always OK for obvious reasons.

> linux/hdreg.h

A local header is sufficient.

> linux/blkpg.h

Doesn't seem to be used?

> linux/types.h

The same types are available from glibc.

> linux/major.h

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

[Tollef Fog Heen]

* Torsten Landschoff 

| On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
|  
| > Package: gsfonts
| > Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
| >   91489 Package gsfonts still has at least one file in /usr/doc
| 
| Package is ready so far and installed locally. But I can't build a
| new package since /usr/bin/install suddenly decided to stop working *arg*

Broken fileutils - install the one in incoming or the one which went
into unstable last evening.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: gcc error - xfsprogs, ppc

[Just a friendly Jedi Knight]

On Mon, May 07, 2001 at 02:21:11PM +1000, Keith Owens wrote:
> >> /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.
 I;ll try that but hmm shouldn't compile also fail on f.ex. i386 ? 
 on second thougt i now remeber that on i386 CCFLAGS haven't any -O option
 (and i tried this on PowerPC also with no luck... maybe compilator defaults
 with respect to optimisation are different?)

 Should i file a bug on this? and bug agains what ? xfsprogs ? gcc ?


-- 
 Robert Ramiega | [EMAIL PROTECTED]  IRC: _Jedi_ | Do not underestimate 
 UIN: 13201047  | http://www.plukwa.net/   | the power of  Source

Re: Finishing the FHS transition

[Adrian Bunk]

On Mon, 7 May 2001, Torsten Landschoff wrote:

> On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
>
> > Package: gsfonts
> > Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
> >   91489 Package gsfonts still has at least one file in /usr/doc
>
> Package is ready so far and installed locally. But I can't build a
> new package since /usr/bin/install suddenly decided to stop working *arg*
>...

This bug is fixed in fileutils version 4.1-2 that is in the archive since
yesterday evening.

> cu
>   Torsten

cu
Adrian

-- 

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

Re: Two debconf issues

[Paolo Molaro]

On 05/07/01 Brendan O'Dea wrote:
> 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?

Here it is a comparison for one specific task: starting a graphical
application that uses the gtk bindings for either python or perl.
The comparison involves also disk and runtime memory issues as well
as completeness of the binding.
If you want more context search the gnome-hackers archives.

=cut cut=

On 03/21/01 Alan Cox wrote:
> Perl bothers me - which perl 5.6 5.005 ... all of them are syntatically subtly
> incompatible. Perl is also about a 20Mb minimum footprint on disk.

Currently the perl binding is tested with 5.005 and 5.6, but should
work with 5.004 and probably with 5.003 too. As for the version
required by the applications I'm not aware of any significant
incompatibility at least between 5.005 -> 5.6 (check the perldelta 
manpage).

Also I'd like to point out that 20 Mb minimum footprint is really
20 M_b_ and not 20 MB:-)

$ dpkg -s perl-base |grep ^Installed-Size
Installed-Size: 2520

This is version 5.6. It's likely older versions are smaller.
Note that this includes 300 KB of changelogs, so the minimum perl
installation is more like 2200 KB. A more complete perl package
will get us to about 6 MB including the development files and other
utilities written in perl.
The documentation amounts to slightly more than 6 megs for a total
of about 13 MB.

The python situation is similar:
$ dpkg -s python-base python-dev python-doc |grep ^In
Installed-Size: 2696
Installed-Size: 1132
Installed-Size: 6968

For a total of about 11 MB (remember that the perl packages contain
500 KB of compressed changelogs more than python and a number of
utilities, from the profiler to sed and awk replacements).

So the difference in size doesn't hold: if redhat uses a single
big package for all of perl, it's redhat's fault:-) I wonder how
it gets to the 20 Mb figure, though, maybe it includes other
modules from CPAN?

And now to some other issues:

Loading speed in ms (on my K6 400 with 128 MB RAM):
The python program are 'from gtk import *' and 'from gnome.ui import *'.
The perl programs are 'perl -MGtk=-init -e 0' and 
'perl -MGnome -e "init Gnome $0"'.

python  perl
gtk 0.715   0.680   (took the best result for python and the worse for
perl in a number of runs each after a find /)
gtk
cached  0.715   0.280  (values taken after running the same program a few 
times, best value for python, worst for perl: the
average for perl is about 0.230)
gnome   1.083   0.777   (same as above for the Gnome support)
gnome
cached  1.085   0.379

So, the perl binding loads 3 times faster when there is an already running
interpreter. It would be interesting to have the numbers for smaller
machines, though.
I'd like to have the numbers for other scripting langages bindings, too.
FYI, for C programs I get 0.105 (gtk) and 0.230 (gnome).

Memory requirements: I used the same programs as above running under
memprof (after adding a sleep() call at the end) and noting the max 
memory usage. Please point out if there are better ways to do this
or if the results from this procedure are not significant for some 
reason.

python  perl
gtk 1032 KB 915 KB
gnome   1576 KB 1341 KB

I have already implemented a lazy-loading mechanism in cvs gnome-perl
that reduces the perl numbers to 710 KB and 1031 KB (if the
program uses _all_ the widgets in gtk and gnome there is no change
in the end, but this is unlikely).

Completeness: it's really hard to find a way to measure this, but let's
try anyway, since the results I get seem to imply the perl binding is the
more complete:-) The program I used is attached. It works this way:
for a number of libraries (libgtk, libgdk, libgnome etc. in the gnome
core) it checks the exported symbols and matches them against the
symbols required by the langauge bindings dynamic modules. I used to
use the program to find what functions are missing in my binding, but I
added a check for the python and guile modules while I was at it:-)
Note that some of the missing functions are bogus or useless for
a binding implementation. I think I have an almost complete perl,
python and guile gnome devel environment: let me know what numbers you
get (it's possible I'm missing some module or maybe the guile binding
doesn't have symbol references for all the functions it supports?).

Missing funcs in perl binding: 972/3201 total
Missing funcs in python binding: 1479/3201 total
Missing funcs in guile binding: 2220/3201 total

Executive summary:
Perl and python use basically the same disk space.
The perl binding loads faster, uses less m

Bug#96638: ITP: libkudzu

[Bas Zoetekouw]

Package: wnpp
Severity: wishlist

I have made a package of the library part of kudzu, Redhat's hardware
detection program. I need it to package a new upstream version of
sndconfig.

The upstream source was taken from RedHat 7.1
(ftp://ftp.redhat.com/redhat/redhat-7.1-en/os/i386/SRPMS/). 
Copyright is GPL v2.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: RaiserFS PPC status

[Just a friendly Jedi Knight]

On Sun, May 06, 2001 at 09:58:02PM -0500, Rahul Jain wrote:
> 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?
 No.. This is APUS kernel tree (based on bitkeeper PowerPC IIRC)
 Kernel compiles just fine (with gcc-3.0; haven't tried gcc-2.95.4). And yes
 XFS patches are from 1.0 release (and i;m running this kernel just now)
 This is 2.4.3 kernel source

> 
> >  Anyway i have trouble compiling mkfs.xfs I tried:

 It should rather read that "i have trouble compiling xfsprogs" which is
 more apropriate
 
> >  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.
 Most probably you are right.. I used gcc-3.0 because i heard that it
 compiles reiserfs code (big endian) correctly. So far i have no problems
 with kernel built with gcc-3.0 
> 
> > 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
> 

 If it's not clear it's libxfs.a (which is in the same source tree) that
 causes problems.. There is no error while compiling sources of libxfs
 itself. Only when ld tries to link with that (freshly built) library

> 
> maybe your GCC isn't inlining the function?
 most probably this is the case.. I thought it's matter of optimization but i
 get the same even if i turn off optimization (-O0)
> 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.

 From what i gather it just can't find code for __fswab64 "function".
 

-- 
 Robert Ramiega | [EMAIL PROTECTED]  IRC: _Jedi_ | Do not underestimate 
 UIN: 13201047  | http://www.plukwa.net/   | the power of  Source

Re: Finishing the FHS transition

[Anthony Towns]

On Mon, May 07, 2001 at 11:19:57AM +0200, Adrian Bunk wrote:
> > Standards-Version you have, you still have to follow the FHS, you have
> > to use /usr/share/doc, and if you specify build-dependencies they have
> > to be correct.
> That means you can file RC bugs on all packages that don't follow the FHS,
> independent from the Standards-Version?

More or less. The less part is when the FHS doesn't really offer a better
alternative (for things like /var/cvs), or things where we're not aiming
for exact compliance (like having symlinks in /usr/doc, rather than not
having anything). That's still independent of Standards-Version, though.

Policy still needs to be changed to say that documentation should be
referenced from /usr/share/doc rather than /usr/doc, iirc.

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)


pgpbS0U1aihul.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Torsten Landschoff]

On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
 
> Package: gsfonts
> Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
>   91489 Package gsfonts still has at least one file in /usr/doc

Package is ready so far and installed locally. But I can't build a
new package since /usr/bin/install suddenly decided to stop working *arg*

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

Likewise.

cu
Torsten


pgpT3rcxmk2R0.pgp
Description: PGP signature

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

[Christian Marillat]

 "SMR" == Steve M Robbins <[EMAIL PROTECTED]> writes:

SMR> Hi Christian & Dale,

Hi,

[...]

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

Dale said in his conclusion :

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

Christian

Re: Finishing the FHS transition

[Adrian Bunk]

On Mon, 7 May 2001, Anthony Towns wrote:

>...
> Standards-Versions aren't release critical. You can put it as
> "Standards-Version: 526.7.8.9.13-Foo.6" if you want. And no matter what

I will practice your suggestion and upload my packages with
"Standards-Version: 526.7.8.9.13-Foo.6".

> Standards-Version you have, you still have to follow the FHS, you have
> to use /usr/share/doc, and if you specify build-dependencies they have
> to be correct.

That means you can file RC bugs on all packages that don't follow the FHS,
independent from the Standards-Version?

> Cheers,
> aj

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

[Torsten Landschoff]

On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
 
> List of packages with Standards-Version < 3.0
> 
> <--  snip  -->
> [...]
> Torsten Landschoff ([EMAIL PROTECTED])  gsfonts-other
> Torsten Landschoff ([EMAIL PROTECTED])  gsfonts

Guess I should really upload my local packages :)

Greetings

Torsten


pgpGAIVzC0G2m.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Anthony Towns]

On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote:
> Standards-Version < 3 :
> a not FHS compliant package is at most a "normal" bug
> Standards-Version >= 3:
> a not FHS compliant package is at most a "serious" bug

This is not correct. You can't change the severity of a bug by twiddling
a field with a purely indicative use.

> > 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.
> Please file RC bug on packages with Standards-Version >= 3 that are not
> FHS compatible.

No. Don't. I'll just downgrade them as soon as I see them, so you'll
be just wasting your own time and mine. Policy is simply wrong in using
the word "must" in regards to the "Standards-Version" field.

And no, this isn't an opportunity for discussion. Everything there is
to be said on this matter has been said, repeatedly. Check the -policy
archives if you really must.

Standards-Versions aren't release critical. You can put it as
"Standards-Version: 526.7.8.9.13-Foo.6" if you want. And no matter what
Standards-Version you have, you still have to follow the FHS, you have
to use /usr/share/doc, and if you specify build-dependencies they have
to be correct.

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)


pgpR12t7DVI1B.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Bas Zoetekouw]

Hi Adam!

You wrote:

> Actually, I already did a mass bug filing, on the usr/doc issue(did a grep on
> Contents-i386, which wasn't fully accurate(other archs, stale data(up to a
> week or so))).  I have seen several of the bugs closed, probably more than
> half now.  I need to do another scan, to see where we stand on that.

There is already a list on http://qa.debian.org/fhs.html

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: Finishing the FHS transition

[Adrian Bunk]

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.

Standards-Version < 3 :
a not FHS compliant package is at most a "normal" bug

Standards-Version >= 3:
a not FHS compliant package is at most a "serious" bug

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

Please file RC bug on packages with Standards-Version >= 3 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.

I think it's important that our packages follow a not too outdated policy
and the "Standards-Version" field is the indicator for this. Freeze time
is too late for picking the minimum Standards-Version for release - the
right time would be shortly after the last stable was released. An
example: It would be nice to have a minimum Standards-Version of 3.1 (that
includes build dependencies), but you can't file 1060 RC bugs at the
beginning of a freeze.

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

You mustn't have to upgrade the Standards-Version field when your package
doesn't comply with a more recent policy -> a package that doesn't follow
FHS will never rech Standards-Version 3.0 .

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

These bugs are relatively easy to fix bugs and many of them will be fixed
at a bug squashing party - and yes, I do fix many "easy to fix bugs" at
each bug squashing party. But BTW: When a maintainer doesn't even when
there's a RC bug starts to work on upgrading the package to comply with a
policy that is nearly two years old there's the question of he's MIA.

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

Reading the last three sentence I'm glad to hear that you volunteer to do
all this checks...

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

It's perhaps really late because we are relatively close too a freeze but
it's definitely not premature.

> 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

[Tollef Fog Heen]

* Adam Heath 

| Um, when was it decided that woody+1=sarge?  When was this flamewar?

It wasn't yet.  aj needed a name for woody+1 and picked sarge as an
interim name.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

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

[Tollef Fog Heen]

* Christian Marillat 

|  "DS" == Dale Scheetz <[EMAIL PROTECTED]> writes:
|
| 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.

Sometimes, a library is installed because it is needed to fulfill a
Build-dependency, not because the one installing it is interested in
using it to program anything.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Question on UNIX sockets

[nadeem_mistry]

Hi,

My question is :

Suppose a server is listening to 5 clients, and it has to send a
message to all the clients, how does the server achieve this task?

Regards,
Nadeem

Re: Finishing the FHS transition

[Adam Heath]

On Sun, 6 May 2001, 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.

Um, when was it decided that woody+1=sarge?  When was this flamewar?

Re: Finishing the FHS transition

[Adam Heath]

On Sun, 6 May 2001, Chris Waters wrote:

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

Actually, I already did a mass bug filing, on the usr/doc issue(did a grep on
Contents-i386, which wasn't fully accurate(other archs, stale data(up to a
week or so))).  I have seen several of the bugs closed, probably more than
half now.  I need to do another scan, to see where we stand on that.