Re: xforms0.86 package insanity

1998-01-02 Thread Ben Gertzfield
> "Scott" == Scott Hanson <[EMAIL PROTECTED]> writes:

Scott> As soon as someone packages xforms0.88, I'll rebuild both
Scott> xmysql and xmysqladmin with it...

Well, I guess I'll do so, since nobody else is stepping forward to do
it.

Should I distribute the binary-only .tar.gz as the .orig.tar.gz, and
make the diff as usual?

-- 
Brought to you by the letters W and X and the number 16.
"Make a little birdhouse in your soul." -- They Might Be Giants
Ben Gertzfield  Finger me for my public
PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: xforms0.86 package insanity

1998-01-02 Thread Scott Hanson
[EMAIL PROTECTED] (Richard Braakman) writes:
 
> Ben Gertzfield wrote:
> [xforms0.86]
> > 
> > I think this more than warrants a non-maintainer upload..
> 
> Heh, it wouldn't be a non-maintainer upload.  If xforms 0.88 is
> packaged, it will become a new package named xforms0.88.  Whoever
> packages it will simply be the maintainer of that package.
> 

As soon as someone packages xforms0.88, I'll rebuild both xmysql and
xmysqladmin with it...

-- 
Scott Hanson <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>
Johmsweg 9a, D-21266 Jesteburg, Germany


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: xforms0.86 package insanity

1998-01-02 Thread Richard Braakman
Ben Gertzfield wrote:
[xforms0.86]
> 
> I think this more than warrants a non-maintainer upload..

Heh, it wouldn't be a non-maintainer upload.  If xforms 0.88 is
packaged, it will become a new package named xforms0.88.  Whoever
packages it will simply be the maintainer of that package.

Richard Braakman


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



libotcl1 package completed

1998-01-02 Thread Michael Borella
I've finally packaged up the shared and static versions of the otcl
libraries.  Otcl allows embedded objects in tcl and is used by a 
number of interesting applications.  I've only compiled them against
libc5 but will upgrade them to libc6 soon, I hope.  Testing is 
encouraged.  Take a look at:

http://www.xnet.com/~cathmike/MSB/Software/

-Mike


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



xforms0.86 package insanity

1998-01-02 Thread Ben Gertzfield
>From the bug reprts on the xforms0.86 package, I've been able to
ascertain the following:

xforms0.86 currently depends on elf-x11r6, a virtual package that is
now obsolete.

xforms0.86 is libc5, and available in binary form only.

xforms0.88 is available, and is distributed compiled for libc6.

The maintainer for xforms0.86 seems to have disappeared.


What's going on with xforms0.86? There are new packages (xmysqladmin)
that are appearing that depend on it! But xforms0.86 cannot be
installed without a --force.

I think this more than warrants a non-maintainer upload..

-- 
Brought to you by the letters A and G and the number 19.
"Mmm.. Soylent Green.." -- Homer Simpson
Ben Gertzfield  Finger me for my public
PGP key. I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re^2: dhelp 0.2 - a online help system

1998-01-02 Thread Marco Budde
Am 01.01.98 schrieb fog # perosa.alpcom.it ...

Moin [EMAIL PROTECTED]

f> I like it but...

Fine :).

f> 1) How about dwww? (Yes, I know dwww needs a web server...)

On my notebook dwww is very slow when your're accessing documents. And  
building the index produces a very high load on this system. Third the  
index of dwww is never uptodate.

f> 3) The policy says the preferred doc format is HTML (fine) but
f> it says nothing about how to access it. Any ideas before we poor
f> developer have to write a dozen of different conf files to support
f> all that new help systems? (menu entries, .dwww-index, .dhelp, etc...)

We could write a converter :)? I would suggest that we add dhelp and dwww  
support to the debstd tool.

cu, Marco

--
Uni: [EMAIL PROTECTED]  Fido: 2:240/5202.15
Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: menu: suggestions - extending the menu files

1998-01-02 Thread Karl M. Hegbloom
> "joost" == joost witteveen <[EMAIL PROTECTED]> writes:

joost> Uhm, there's a slight problem with ifeq($visable,
joost> "false",...). If we assign booleans to the string variables
joost> ($visable etc are essentially strings), then I'd prefer
joost> them to by default to have the "0" value.

 I wonder if `guile' would be a better language to implement the menu
system with?  I've never even looked at it yet... so have not thought
about the problem at all from that perspective.  It might assist
placing a GUI around it all when `gnome' becomes more usable. (ie:
documented).

>> Maybe if Joost isn't too busy, we'll see something similar in
>> menu someday..

 There's so much to read, so much to do, so little time...  as we've
all experienced.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Linking shared libraries with -lc

1998-01-02 Thread Richard Braakman
I made a list of packages that include shared libraries for which ldd
says "statically linked".  I plan to use this list to automatically
generate bug reports (about 50).  However, I am unsure of the text 
to use.  This is my first try:


Package: %s
Version: %s

This is an automated bugreport.

The package %s contains a shared library that should be
explicitly linked with the libraries it depends on.
Filename:  %s

Explicit linking of shared libraries has several advantages, the most
important of which is that it allows the dynamic linker to detect
conflicts between library versions.

Every shared library should at least be linked explicitly with libc,
by passing -lc to the linker.

When this is done, the package should use dpkg-shlibdeps on the shared
libraries to generate a correct Depends: line automatically.


I would like to add a "For more information, see..." paragraph to
that, but I could not find a reference.  I dug up some things from the
mailing list, though:

 From Brian White's "Upcoming Debian Releases" mailings 
* Link shared libs against other shared libs instead of static [14]

14 - Link shared libraries themselves against other shared libs, instead of
 including their code static (e.g. as current S-Lang already does); this
 can reduce memory use.  -- [EMAIL PROTECTED] (J.H.M.Dassen)

  See H.J. Lu's "ELF: From The Programmer's Perspective"
  ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz> for details.


 From an update Ray Dassen mailed on Sep 23 
14 - Link shared libraries themselves against other shared libs, instead 
 of including their code statically. This has several advantages. It
 allows the linker to warn about "mixed libc5/libc6 binaries", and,
 more general, makes the dependencies of shared libraries themselves
 more explicit; this should be used in generating the Depends: line of
 a library package (e.g. through dpkg-shlibdeps). This could prevent
 subtle bugs resulting from interactions between code (statically
 included) from incompatible library versions. Also, it can reduce
 memory use. -- [EMAIL PROTECTED] (J.H.M. Dassen)

 See H.J. Lu's "ELF: From The Programmer's Perspective"
 ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz> for
 details.


 From a comment Mark Baker made on Nov 23 
> * Link shared libs against other shared libs instead of static [14]

What you mean is `link shared libs so they contain dependency information'.

If you don't do that, ldd says `statically linked' but that's just a very
misleading error, since libraries are never statically linked.
--

I hope that someone can take this information and straighten it out to
turn it into a nice proposal for the policy manual.

Richard Braakman


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: menu: suggestions - extending the menu files

1998-01-02 Thread joost witteveen
> The menu package is amazingly flexible. :-)


(thanks!). (And, BTW, I agree with all that you said and I didn't
repeat).

> >  wait="t" or wait="nil" - some programs exit after output, but I want
> >  to read it first. (like how mc says push a key after it runs a cmd.)
> 
> This is a good idea, and can be implemented simalarly to my example with
> geometry. Some programs already implement this themselves, but it makes
> sense to put this in the menu files. For example, if we do this, pdmenu will
> be able to run programs in it's "pause" mode. (But, please, not 't' or
> 'nil', let's use true or false; we're not all emacs fans. ;-)
> 
> Another idea, which I have been using for a while: it's possible, and
> sometimes desirable to make an xterm not show up in "who", when it's running
> some random program. For example, I don't want to get write messages in the 
> xterm where I'm playing bsdgame's go fish (heck, I don't even want casual 
> users of my system to see me playing it ;-), so it'd be nice to be able to 
> pass -ut to xterm. I suggest we add a visible="" flag to the menu files, 
> which if set to "false", makes xterm get -ut. 
> 
> Combining that and the geometry, I get this:
> 
> function term()=\
> "xterm " ifeq($visible,"false","-ut") \
>   ifnmpty($geometry,"-geometry ") $geometry \
>   " -T \"" title() "\"" ifnempty(icon()," -n " icon()) " -e " $command

Uhm, there's a slight problem with ifeq($visable, "false",...). If we assign
booleans to the string variables ($visable etc are essentially strings),
then I'd prefer them to by default to have the "0" value. But as
"" (the default value of the strings) is unequal to "false" the booleans
will by default be "true". This is indeed what you intend to happen in the
above case, but I'd rather it be reversed. Add to that that there is
already a (rather poorly documented --  I had to look for it
in the sources myself) "false" value for the strings (it's called "none", for
compatibilty reasons with the very old (pre menu-0.0) programmes), I'd 
prefer the following:

function term()=\
"xterm " ifnempty($visible,"-ut") \
ifnempty($geometry,"-geometry ") $geometry \
" -T \"" title() "\"" ifnempty(icon()," -n " icon()) " -e " $command

> Maybe if Joost isn't too busy, we'll see something similar in menu someday..

The above is added to my menu.h (for the next release of menu). There
I've also added the following to menu.sgml ("+-"=changed, "+"= added):


+-  Preferred variables:
The following aren't special for install-menus, but it's nice 
(read: essential) to use the same variables for the same things.
So, I'll suggest some here. If you want to invent new ones, please
do so and mail them to me so that I can include them here.

icon:The location of the iconfile for this menuentry.
 If you don't have an iconfile, just leave out the icon=
 in the menuentry.
longtitle: For people that like descriptive titles (about one line)
 It is probably best to include this in your menuentries,
 while the window-managers don't (by default) put it in the
 menus. That way, people who want descriptive titles can
 turn them on, but others don't need to use them.
description:An even longer description (about 5 lines).
 For example, a description of the documentation in
 the dwww generated html pages.

+  Suggested variables:
+The following variables probably shouldn't appear often (or at
+all) in the menu files supplied with packages. They are mostly
+intended for use by local system managers. Nevertheless, it is
+adviced that all debian systems use the following variable names:
+
+visable: Some apps add entries to utmp the utmp file, so that
+ "who" and friends know they are running (this is
+ especially true for xterms etc). If $visable set
+ (to anything other than "" or "none"), xterms &c will
+ not write logging info to utmp. (may not work for
+ your window manager).
+geometry: For X apps, this will be the size of the (main) window
+ that will be created (units in eighter chars or pixels,
+ depending on type of main window (xterm or graphic)).
+ If you as package maintainer want to use this, you should
+ probably think about setting this variable somewhere
+ in an Xresources file.
  

--

Welcomming comments, typing errors, sweets, etc,

joostje
-- 
joost witteveen, [EMAIL PROTECTED]

Potentially offensive files, part 5: /dev/random.
`head -c 4 /dev/random` may print 4-letter words (once every approx 4e8 tries).


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: gmp_2.0.2-3.deb in hamm/devel ?

1998-01-02 Thread Dale Scheetz
On Fri, 2 Jan 1998, Gregor Hoffleit wrote:

> Pardon my ignorance, but why is there an gmp_2.0.2-3.deb in hamm's devel  
> directory when we have gmp2_2.0.2-4.deb in hamm/libs ?
> 
As the maintainer, I have no idea. I uploaded both gmp2 and gmp2-dev and
they are both where they belong. gmp2 will conflict with and remove gmp,
so there really is no problem, but I guess you could make this a bug
report against ftp.debian.org...

Luck,

Dwarf
-- 
_-_-_-_-_-_-   Author of "The Debian User's Guide"_-_-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (904) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re[6]: My own libc6 progress, and package adoption drive. Give me an account on master!

1998-01-02 Thread Adam Heath
>>
>> Ok.  I will try to isolate all the patches that affect these programs.  Some
>> bugs, however, should be merged(see majordomo), and I don't know if a
>> non-developer(yet!) can do it.

> Everybody who has access to the bugtracking system can merge bugreports.
> And as you only need to have mail access you're probably able to merge them.

Ok.  I will merge the reports that I have need to be.  Majordomo is not the
only one.

>> >> majordomo   closes (12976, 14196, 14959, 15100), 14434
>> >> closes 4572, 9774, 13463, 13585, 15995, 15996 not yet u/l

> Are you going to take over that package, too?  If not I might take
> it in a few weeks when my upgrading procedure is finished.

I thought about it.  Since I will be closing all but one bug, I might as well.

>> >> mdutils closes 8062, 15319
>> 
>> > Somebody said that it is opsoleted by raidtools which need to be
>> > packaged?
>> 
>> I saw that bug report, to.  Should the debian package still be name mdutils,
>> but use the raidtools source?  If not, how should the dependencies be set to
>> make sure that someone upgrading will get raidtools, and have mdutils
>> deselected.

> No, the new package should be named similar to the upstream source but
> the control file should contain these lines:

>   Conflicts: mdutils
>   Replaces: mdutils
>   Provides: mdutils

But what if they currently have mdutils selected, and they don't notice that a
new package called raidtools is there?  I want the package raidtools to be
automatically installed if mdutils is installed.  How about this?

Package: mdutils
Pre-depends: raidtools

Package: raidtools
Conflicts: mdutils
Replaces: mdutils
Provides: mdutils

This way, as I see it, raidtools will have to be installed before mdutils, and
when raidtools is installed, it will deselect mdutils.  Any problems with this?


2B OR NOT 2B=FF

Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H.323 effort.  Email
http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with
http://wwp.mirabilis.com/3375265 - Page Me  the word subscribe in the body.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: Not Allowed == Policy? (libbfd)

1998-01-02 Thread Mark W. Eichin

I was wondering about that too -- because gdb has an older bfd in it
that doesn't support sparc-linux, but we've got a current sparc-linux
libbfd; if gdb could use the common package and shared lib, it would
save a lot of porting work.  (Of course, I was hoping someone else
would do it -- trying to hunt down why libc6 2.0.90 select doesn't
work is not fun, without strace or gdb...) 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



tecra patch?

1998-01-02 Thread bruce
Who maintains the "tecra patch", and where can I find it?

Bruce


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: killall is removed from procps

1998-01-02 Thread Raul Miller
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Two options:
>   I merge the psmic into procps
>   I create a new package called psmisc.

procps is required.  pure compatability would argue that
psmisc also be required (or something very close).

-- 
Raul


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: gmp_2.0.2-3.deb in hamm/devel ?

1998-01-02 Thread Scott Ellis
Package: ftp.debian.org

On Fri, 2 Jan 1998, Gregor Hoffleit wrote:

> Pardon my ignorance, but why is there an gmp_2.0.2-3.deb in hamm's devel  
> directory when we have gmp2_2.0.2-4.deb in hamm/libs ?

Probably because Guy missed removing it.  I'm forwarding this as a bug
against ftp.debian.org where Guy will see it :)

-- 
Scott K. Ellis <[EMAIL PROTECTED]> http://www.gate.net/~storm/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: multiple jobs with buildpackage?

1998-01-02 Thread Vincent Renardias

On Fri, 2 Jan 1998, Douglas Bates wrote:

> If I am running "make" on a multi-processor system I can use the -j
> switch to allow multiple jobs to be spawned.  Is there a similar
> facility with dpkg-buildpackage or a way I can pass a '-j 4' option to 
> calls to debian/rules?

I think setting "setenv MAKE 'make -j 4'" before to start dpkg-build
should to it.
(Or "export MAKE='make -j 4'" if you use bash)

--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo.com,debian.org} -
- Debian/GNU Linux:   Pipo:WAW:   -
- http://www.fr.debian.orghttp://www.pipo.com  http://www.waw.com -
---
- "La fonctionnalite Son Visuel vous delivre des avertissements visuels." -
-  [Message durant l'installation de Windows95] :wq


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Announce: Yet Another Text Editor (Yate)

1998-01-02 Thread Magossa'nyi A'rpa'd
Hi!

[first of all sorry for the heavy crossposting]
[second of all please cc: your replies to me (either this address, or the
one at the bottom)]

I hereby announce the existence of Yate (Yet Another Text Editor).

It is in GPL and in embrionic state, still it makes a linuxdoc-sgml file
(and if you don't overlap tags incorrectly, etc then it will be a correct
one). It even creates and shows a DVI.

I think it is a cool idea (arcom, arcom, széles vállam), but I want to be sure
if it isn't a duplicate effort, and that someone wants to overtake it.

I unfortunately don't have much time to spend on it, hence the announcement
in this early stage.

It can be seen at http://www.hal.vein.hu/~mag/yate

Please send any comment regarding this to me ([EMAIL PROTECTED])


---
GNU GPL: Csak tiszta forrásból


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .



multiple jobs with buildpackage?

1998-01-02 Thread Douglas Bates
If I am running "make" on a multi-processor system I can use the -j
switch to allow multiple jobs to be spawned.  Is there a similar
facility with dpkg-buildpackage or a way I can pass a '-j 4' option to 
calls to debian/rules?


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



gmp_2.0.2-3.deb in hamm/devel ?

1998-01-02 Thread Gregor Hoffleit
Pardon my ignorance, but why is there an gmp_2.0.2-3.deb in hamm's devel  
directory when we have gmp2_2.0.2-4.deb in hamm/libs ?

Gregor


---
|Gregor Hoffleit   Mathematisches Institut, Uni HD|
| [EMAIL PROTECTED]   INF 288, 69120 Heidelberg, Germany |
|   (NeXTmail, MIME)   (49)6221 54-5771fax  54-8312   |
|  "We will make windows invisible"   |


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: need libc5 non-maintainer upgrade

1998-01-02 Thread Chris Fearnley
'[EMAIL PROTECTED] wrote:'
>
>Actually, I'm not sure there is a problem with libc5-altdev. There definitely
>is a dependency clash between libc5 and libc6, which David Engel thinks we
>should patch by producing an upgrade for libc5. This will have to be installed
>before hamm. It's not yet clear to me that we can make this automatic with
>pre-depends or not.

I don't think we should make it automatic.  But it should be
documented in the libc5 -> libc6 transition FAQ.

-- 
Christopher J. Fearnley  |  Linux/Internet Consulting
[EMAIL PROTECTED]   |  Design Science Revolutionary
http://www.netaxs.com/~cjf   |  Explorer in Universe
ftp://ftp.netaxs.com/people/cjf  |  "Dare to be Naive" -- Bucky Fuller


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: Re[4]: My own libc6 progress, and package adoption drive. Give me an account on master!

1998-01-02 Thread Martin Schulze
On Fri, Jan 02, 1998 at 04:25:09AM -0500, Adam Heath wrote:

> >> dbview  closes 14563
> > Please do not close this.  The package needs some investigation
> > and will be libc6'ed by that time.  If you have patches to it, please
> > send it to [EMAIL PROTECTED]
> 
> Ok.  I will try to isolate all the patches that affect these programs.  Some
> bugs, however, should be merged(see majordomo), and I don't know if a
> non-developer(yet!) can do it.

Everybody who has access to the bugtracking system can merge bugreports.
And as you only need to have mail access you're probably able to merge them.

> >> majordomo   closes (12976, 14196, 14959, 15100), 14434
> >> closes 4572, 9774, 13463, 13585, 15995, 15996 not yet u/l

Are you going to take over that package, too?  If not I might take
it in a few weeks when my upgrading procedure is finished.

> >> mdutils closes 8062, 15319
> 
> > Somebody said that it is opsoleted by raidtools which need to be
> > packaged?
> 
> I saw that bug report, to.  Should the debian package still be name mdutils,
> but use the raidtools source?  If not, how should the dependencies be set to
> make sure that someone upgrading will get raidtools, and have mdutils
> deselected.

No, the new package should be named similar to the upstream source but
the control file should contain these lines:

  Conflicts: mdutils
  Replaces: mdutils
  Provides: mdutils

This way the new package would completely replace the old package.

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 /Erfahrung ist eine nützliche Sache /
/ Leider macht man sie immer erst kurz nachdem man sie brauchte /


pgpEzs65Qrpwm.pgp
Description: PGP signature


Re: Re[4]: My own libc6 progress, and package adoption drive. Give me an account on master!

1998-01-02 Thread Eloy A. Paris
Adam Heath <[EMAIL PROTECTED]> wrote:

: I saw that bug report, to.  Should the debian package still be name mdutils,
: but use the raidtools source?  If not, how should the dependencies be set to
: make sure that someone upgrading will get raidtools, and have mdutils
: deselected.

See the packaging manual in Developer's Corner at www.debian.org for
the exact details but you need:

Package: raidtools
[...]

Replaces: mdutils
Conflicts: mdutils
[...]

E.-

-- 

Eloy A. Paris
Information Technology Department
Rockwell Automation de Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re[4]: My own libc6 progress, and package adoption drive. Give me an account on master!

1998-01-02 Thread Adam Heath
| On Thursday, 1 January 98, at 8:55:02 PM
| Martin wrote about "My own libc6 progress, and package adoption drive.  Give 
me an account on master!"
> On Thu, Jan 01, 1998 at 02:46:11PM -0500, Adam Heath wrote:

>> YEs, that is the whole point.  I need to be have an account on master, and
>> added to the keyring, etc, for this all to work.  I am going to keep working 
>> on

> This will be done, but everything needs some time.

I know.  I just got a phone call last night from someone from debian.

>> compiling for libc6, and trying to fix bugs.  Currently, by the list I have:
>> 
>> defrag  closes 15445

>> dbview  closes 14563
> Please do not close this.  The package needs some investigation
> and will be libc6'ed by that time.  If you have patches to it, please
> send it to [EMAIL PROTECTED]

Ok.  I will try to isolate all the patches that affect these programs.  Some
bugs, however, should be merged(see majordomo), and I don't know if a
non-developer(yet!) can do it.

>> majordomo   closes (12976, 14196, 14959, 15100), 14434
>> closes 4572, 9774, 13463, 13585, 15995, 15996 not yet u/l
>> mdutils closes 8062, 15319

> Somebody said that it is opsoleted by raidtools which need to be
> packaged?

I saw that bug report, to.  Should the debian package still be name mdutils,
but use the raidtools source?  If not, how should the dependencies be set to
make sure that someone upgrading will get raidtools, and have mdutils
deselected.


I wish I had a life outside Quake.

Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H.323 effort.  Email
http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with
http://wwp.mirabilis.com/3375265 - Page Me  the word subscribe in the body.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re[2]: My own libc6 progress, and package adoption drive. Give me an account on master!

1998-01-02 Thread Adam Heath
| On Friday, 2 January 98, at 12:15:19 AM
| Bruce wrote about "My own libc6 progress, and package adoption drive.  Give 
me an account on master!"
--- pacman-10.orig/board.cc
+++ pacman-10/board.cc
@@ -119,7 +119,7 @@
  oldtemp=oldlist;
  while (oldtemp) { //delete elements in the now previous sprite list
   oldnext=oldtemp->next;
-  delete oldnext;
+  delete oldtemp;
   oldtemp=oldnext;
  }
 if (zero && oldlist) { //personal thingie used for debug, not useful
> The memory doesn't necessarily go away when you free or delete an object,
> unless you are running Electric Fence. Thus, it's perfectly possible
> that the program would work sometimes, with some libraries.

oldtemp is the current item.  oldnext comes after it.  When nothing is next, it
exits like it should.  The problem is that it is deleting what comes next, then
trying to get that address, which is most likely ok.  However, what is at that
address might be change, and so when it returns to the top of the loop, to get
the next oldnext, it gets something unusal, and the delete call fails.  In any
case, I believe that this should be a bug with libc5, has something shouldn't
be referenced after it is deleted.

This was obviously a typo, and the old libc5 allowed a badly written program to
continue working.  When that happens, you have buffer overruns, security
breaks, etc.

> By the way, the security folks said they got your new maintainer application
> four days ago and are processing it. They usually take longer than that.

Cool!  I got a phone call last night from someone about that.  I had been sent
an email, saying that I should send my key to pgp.net.  However, it was not
mentioned in the docs on the web site that this should be done.  If it had, I
would have already done it and saved some time.  From the same docs, it said
that to verify who I was, I could get my key signed from some other debian
developer.  I contacted Ben Pfaff, who lives about 35 minutes away, and he
signed it.  I then included it into an email, signed said email, and mailed it
to new-developer.  In the documentation, it said that that would be enough.  I
didn't know that a phone call would also have to be placed.  This resulted in
more delay, also.

> Thanks

No prob.  I love programming, and so I thought it would be fun to try to work
on the 'difficult' programs.  I got pacman to work, and omirr also compiles
now.  I might go back through all the packages that I am doing, in attempt to
make the libc6 patches uniform, and to make some type of informal howto(most
likely to be used by myself).


Get a maintainable operating system:  http://www.debian.org

Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H.323 effort.  Email
http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with
http://wwp.mirabilis.com/3375265 - Page Me  the word subscribe in the body.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: mysql: mysql won't compile with libc6-2.0.6 (Debian)

1998-01-02 Thread Scott Hanson
<[EMAIL PROTECTED]> writes:
 
> > "Scott" == Scott Hanson <[EMAIL PROTECTED]> writes:
> 
-
> Scott> /usr/lib/libc.a(connect.o): In function `__libc_connect':
> Scott> connect.o(.text+0x0): multiple definition of `__connect'
> Scott> /usr/lib/libpthread.a(wrapsyscall.o)(.text+0x3b0): first defined here
> Scott> ld: Warning: size of symbol `__connect' changed from 62 to 30 in 
> connect.o
> Scott> /usr/lib/libc.a(send.o): In function `__libc_send':
> Scott> send.o(.text+0x0): multiple definition of `__send'
> Scott> /usr/lib/libpthread.a(wrapsyscall.o)(.text+0x4d0): first defined here
> Scott> ld: Warning: size of symbol `__send' changed from 66 to 30 in send.o
> 
> Are you sure that /usr/lib/libpthread.a is also from glibc 2.0.6 ?
> It looks like you are using a linuxthread library from 2.0.5 with
> glibc 2.0.6 !

Yes, I'm sure I have the right library. I've even tried rebuilding
glibc 2.0.6 (including all the linuxthread stuff) myself, and I still
get the same results.

Scott
-- 
Scott Hanson <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>
Johmsweg 9a, D-21266 Jesteburg, Germany


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: need libc5 non-maintainer upgrade

1998-01-02 Thread Dale Scheetz
On 2 Jan 1998 [EMAIL PROTECTED] wrote:

> It looks as if Richard has taken care of libc5, and libc5-altdev doesn't
> need a change. Dale, did you do the ae-using-slang upload? I'm going to
> need that soon.
> 
I've been out of town, and just got back this evening. I already have the
patches, (got them before I left) but haven't integrated them yet. I hope
to get to it this weekend.

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-   Author of "The Debian User's Guide"_-_-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (904) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: need libc5 non-maintainer upgrade

1998-01-02 Thread bruce
It looks as if Richard has taken care of libc5, and libc5-altdev doesn't
need a change. Dale, did you do the ae-using-slang upload? I'm going to
need that soon.

Thanks

Bruce


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: Financial support

1998-01-02 Thread bruce
It's not _my_ corporation. It's got 4 people on the board.

Bruce


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: need libc5 non-maintainer upgrade

1998-01-02 Thread bruce
OK, I think the patch is only necessary for libc5 run-time. 

Thanks

Bruce


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: killall is removed from procps

1998-01-02 Thread bruce
Nobody's going to be upset if you create the new package. I think you should
go ahead.

Thanks

Bruce


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: My own libc6 progress, and package adoption drive. Give me an account on master!

1998-01-02 Thread bruce
The memory doesn't necessarily go away when you free or delete an object,
unless you are running Electric Fence. Thus, it's perfectly possible
that the program would work sometimes, with some libraries.

By the way, the security folks said they got your new maintainer application
four days ago and are processing it. They usually take longer than that.

Thanks

Bruce


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: need libc5 non-maintainer upgrade

1998-01-02 Thread Dale Scheetz
On 1 Jan 1998 [EMAIL PROTECTED] wrote:

> We need someone to do a non-maintainer upgrade of libc5-altdev, installing
> the patch in David Engel's mail. I'm busy with boot floppies. Can someone
> pretty please do this?

I have been talking with David about helping out here. I'll take a look at
his patches this weekend and see if I can get something out.

> 
> Also, it looks to me as if libc6 depends on versions of kernel-headers
> and kernel-source that are _not_ in hamm at the moment.
> 
This is truely bothersome. I'll see what I can come up with.

I will be relying on David's input until I get up the learning curve some,
but our preliminary discussions indicate we are at least thinking on the
same page. Do I need to let anyone else know what I'm doing? (the various
intermediate maintainers)

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-   Author of "The Debian User's Guide"_-_-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (904) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: Re[2]: My own Libc6 progress and package adoption drive, and I nee

1998-01-02 Thread Eloy A. Paris
Kai Henningsen <[EMAIL PROTECTED]> wrote:

: > Did you let the maintainer of the list (I think it was Phillipe Troin)
: > know you were taking maintenance of this package? I guess leting
: > debian-devel know is not enough.

: Why would I do that, when I took over directly from the former maintainer?  
: Why would the list even become involved at all?

: That is what I don't understand - why did the package _ever_ get into the  
: wnpp list? Who decided to put it there, and on what grounds?

Good questions. I really don't know the answers but probably you could
talk to the maintainer of the list. He might have the answers ;-)

See ya!

E.-

-- 

Eloy A. Paris
Information Technology Department
Rockwell Automation de Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: Bleeding edge FTP repository updated to glibc2 + egcs.

1998-01-02 Thread Jim Pick

Paul Seelig <[EMAIL PROTECTED]> writes:

> Has anybody already noted this here?

[ Cut - Posting about Yggdrasil packages - RPM/deb/slackware/yggdrasil from
common source ]

Looks interesting!

I wonder if they are proposing a new source packaging format - or if they
are building all the binary packages from an unpacked tree.  Judging by
the contents of their build.log and install.log files, it seems they just
have one huge FreeBSD-style "make world" happening.

I looked at one of the SRPMs, and saw no Debian stuff.  I don't think they
have a source packaging format.  Too bad.  But they must have all the
source in place to do multiple binary packages...  they just haven't
put it up yet.

I'd like to see a common source packaging format that could be used to
generate any type of binary package.  I'd advocate using such a source
format for Debian - because then we could help organize people who want to
do 'contrib' packages for other distributions - and as a spin-off, reduce
some of the duplicated work in the free software community.  It would also
be an excellent step towards a unified binary packaging format. 

Whether or not we want to deal with 'outsiders' is another matter altogether.
We might get distracted somewhat from our Debian integration work if we are
trying to produce portable packages.

Also, I'm not sure if our one maintainer per source package system is flexible
enough to deal with supporting multiple architectures, languages, and multiple
distributions too.

I don't think it would be too much work rigging the ability to generate
RPMs into our package building process, or to use Red Hat 'spec' files
with dpkg-dev.  Someday I'm gonna figure out how to do that.

Cheers,

 - Jim



pgpOYsfsTWRG8.pgp
Description: PGP signature


Re: Re[2]: My own libc6 progress, and package adoption drive. Give me an account on master!

1998-01-02 Thread Martin Schulze
On Thu, Jan 01, 1998 at 02:46:11PM -0500, Adam Heath wrote:

> YEs, that is the whole point.  I need to be have an account on master, and
> added to the keyring, etc, for this all to work.  I am going to keep working 
> on

This will be done, but everything needs some time.

> compiling for libc6, and trying to fix bugs.  Currently, by the list I have:
> 
> defrag  closes 15445

> dbview  closes 14563
Please do not close this.  The package needs some investigation
and will be libc6'ed by that time.  If you have patches to it, please
send it to [EMAIL PROTECTED]

> majordomo   closes (12976, 14196, 14959, 15100), 14434
> closes 4572, 9774, 13463, 13585, 15995, 15996 not yet u/l
> mdutils closes 8062, 15319

Somebody said that it is opsoleted by raidtools which need to be
packaged?

Regards

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 /Erfahrung ist eine nützliche Sache /
/ Leider macht man sie immer erst kurz nachdem man sie brauchte /


pgpqFShCoLEHQ.pgp
Description: PGP signature


The next dwww (was Re: Financial support)

1998-01-02 Thread Jim Pick

> > Look for an updated dwww package and a new "kaffe+kore" package this week
>   
> 
> Yuhuu!
> 
> Is it the version with the "big step forward", you promised some time ago?

Unfortunately, not.  It's more of a "fix as many of the 40 bugs as possible"
release.  It'll be a little step forward, setting the stage for the
"big step forward" release in a month or so.

Don't expect much new for the next release, except support for the index
on multiple heirarchial pages (I haven't tried menu's support for that yet),
and maybe support for .dhelp files too.

The "big step forward" release should have much better support for a
wider range of meta-data, a DSSSL-based menu building system (yes, yet
another menu building system), better search capabilities, and an extensible
architecture.  I've got some additional plans that go beyond that release
too.

(oh yeah, since Brian is still cc'd to this - I should mention that I'd
 like to do a pgsql package too, now that we have an updated postgresql
 package again)

Cheers,

 - Jim



pgpr6gOMexbxY.pgp
Description: PGP signature


Re: Financial support

1998-01-02 Thread Marcus Brinkmann
On Thu, Jan 01, 1998 at 04:54:29PM -0800, Jim Pick wrote:
> 
> Look for an updated dwww package and a new "kaffe+kore" package this week
  

Yuhuu!

Is it the version with the "big step forward", you promised some time ago?

It would be nice if dwww could evolve to the main debian documentation
center it is supposed to be, as we have policy that preferred doc format is
html, havn't we?

> from me.

Thank you,
Marcus


-- 
"Rhubarb is no Egyptian god." Debian GNU/Linux
Marcus Brinkmann  http://www.debian.org
[EMAIL PROTECTED]
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/  PGP Key ID 36E7CD09


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: dhelp 0.2 - a online help system

1998-01-02 Thread Jim Pick

[EMAIL PROTECTED] writes:

> I like it but...

I like it too.
 
> 1) How about dwww? (Yes, I know dwww needs a web server...)

I think I'll add support for .dhelp files to dwww too.

> 2) I really dont like to have 2/3/... methods of building indexes
> of documentation installed in the debian system. What about integrating
> all that stuff? (menu, dwww, dhelp, etc...)

I agree - we should eventually have only have one index.

I've been working on yet another way of building an index, but I'm been
very slow working on it.

> 3) The policy says the preferred doc format is HTML (fine) but
> it says nothing about how to access it. Any ideas before we poor
> developer have to write a dozen of different conf files to support
> all that new help systems? (menu entries, .dwww-index, .dhelp, etc...)

I'd consider all documentation menu systems "experimental" at this
point, so I wouldn't worry about it yet.  Just support a particular
menu style if you feel like playing with it.

FWIW, the menu system I'm working on was going to be SGML/DSSSL based,
so Marco's .dhelp menu format is perfect for that.  I'll be able to
use the .dhelp format as input.

Short term (in the next few days), I'm also going to enhance the
dwww menu-package based menus.  I'll see if I can write a .dhelp to
"menu" converter.  That way, package authors can write a single
.dhelp file, and support all the menu-building packages (dhelp,
menu, and dwww-next-generation).

The next dwww should be ready by Sunday, at least.

Cheers,

 - Jim



pgpI4G57nF7q9.pgp
Description: PGP signature


Re: need libc5 non-maintainer upgrade

1998-01-02 Thread Richard Braakman
[EMAIL PROTECTED] wrote:

> Actually, I'm not sure there is a problem with libc5-altdev. There
> definitely is a dependency clash between libc5 and libc6, which
> David Engel thinks we should patch by producing an upgrade for
> libc5. This will have to be installed before hamm. It's not yet
> clear to me that we can make this automatic with pre-depends or not.

I think the advantage of this patch is that it gives an upgrade path
that doesn't involve first removing all -dev packages.  The conversion
from libc5 development to libc6 development can then be delayed until
the (tricky) libc6 install has been dealt with.

I don't think dselect is capable of handling the entire bo->hamm
upgrade automatically, no matter what dependency information we put in
the package files.  It would need significant improvements to its
handling of versioned conflicts and dependencies, and a way to specify
more intricate upgrade sequences.

I finished compiling libc5 with David Engel's patch.  I have put the
results in ~dark/libc5/ on master.  I haven't tested it much, but I
did install it on my own system and it didn't break my smail.  I've
compiled a libc5 hello-world program with the libc5-altdev package.
The other packages are completely untested; someone with a bo system
will have to do that.

I'm going to bed now, so I'll leave the rest to you :-)

Richard Braakman


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: Financial support

1998-01-02 Thread Jim Pick

> Pardon me for a nosy question.  Does Debian have any money flowing in
> from users that is used to compensate full-time Debian developers?

Debian does solicit donations to Bruce Peren's "Software in the Public
Interest, Inc." non-profit to help defray costs (like Internic fees,
etc.).

Here's a list of the donations so far:

http://www.buoy.com/debian/misc/donations.pl

Unfortunately, there is no record of outflows there. I imagine that SPI will
have to do an annual report eventually where all that info is public.  

SPI is in the business of giving out "grants".  Most notably, they have
committed $1000 to the Gnome project (www.gnome.org).  I'm not sure what
the Miguel and the other Gnomers are going to do with the money, but it
is a nice token of political support.

Personally, I have no problem spending business time to contribute to
Debian - it's a good image/reputation builder.  I do have to keep myself
in check to make sure I don't "overcommit" my time to the project though.

Look for an updated dwww package and a new "kaffe+kore" package this week
from me.

Cheers,

 - Jim



pgpfxZDfPhuUF.pgp
Description: PGP signature


Re[2]: need libc5 non-maintainer upgrade

1998-01-02 Thread Adam Heath
| On Thursday, 1 January 98, at 3:06:02 PM
| Richard wrote about "need libc5 non-maintainer upgrade"
> [EMAIL PROTECTED] wrote:
>> Is libc5-altdev OK in its present state? 

> Hmm... OK for what?  You said you needed David Engel's patch, you
> didn't say why :-)

> The effect of this patch on libc5-altdev will be to remove the
> "Conflicts: libc5-dev" line from its package description.  This is
> part of the scheme worked out in bug report #15859 to allow libc5
> users to install libc6 while keeping a development environment that
> generates libc5 binaries.  (I.e. they keep libc5-dev and all the other
> libc5-based -dev packages, and do not install libc6-dev.  They also
> refrain from upgrading gcc.  The hamm versions of gcc conflict with
> libc5-dev, so that's ok.)

> Is this the patch you meant?  It is [based on] the one David Engel
> mailed to debian-private on Monday.

> I'm having some problems building it on my hamm system, by the way.
> I had to install altgcc and libc5-altdev because the build process
> referred to files in /usr/i486-linuxlibc1.  I'm trying again now,
> so it will take a couple of hours more.

I have already successfully compiled(last night) libc5 on hamm.  I don't,
however, have the patch in question.  Maybe I could do it.  It took about an
hour, if I remember correctly.


Computers are like air conditioner. Both stop working, if you open windows.

Adam Heath of Borg-Linux [EMAIL PROTECTED] Join the H.323 effort.  Email
http://www.debian.org - Get Your Own Linux! [EMAIL PROTECTED] with
http://wwp.mirabilis.com/3375265 - Page Me  the word subscribe in the body.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: need libc5 non-maintainer upgrade

1998-01-02 Thread Richard Braakman
[EMAIL PROTECTED] wrote:
> Is libc5-altdev OK in its present state? 

Hmm... OK for what?  You said you needed David Engel's patch, you
didn't say why :-)

The effect of this patch on libc5-altdev will be to remove the
"Conflicts: libc5-dev" line from its package description.  This is
part of the scheme worked out in bug report #15859 to allow libc5
users to install libc6 while keeping a development environment that
generates libc5 binaries.  (I.e. they keep libc5-dev and all the other
libc5-based -dev packages, and do not install libc6-dev.  They also
refrain from upgrading gcc.  The hamm versions of gcc conflict with
libc5-dev, so that's ok.)

Is this the patch you meant?  It is [based on] the one David Engel
mailed to debian-private on Monday.

I'm having some problems building it on my hamm system, by the way.
I had to install altgcc and libc5-altdev because the build process
referred to files in /usr/i486-linuxlibc1.  I'm trying again now,
so it will take a couple of hours more.

Richard Braakman


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: Device files

1998-01-02 Thread James R. Van Zandt

Martin -
>I'm packaging a kernel driver for the Gravis Ultrasound sound card.
>It requires some special device files to be created (in addition to
>those normally used by the OSS driver) in order for all of its
>features to work.  My question is, how should I create the device
>files?

The same issue came up when I packaged my kernel module for the
DoubleTalk PC.  I suggest using the same method as the dtlk package.
You will need to contact the /dev/MAKEDEV maintainer to get your
device included in the official configuration files.  However, you can
work with previous versions of MAKEDEV by making your own additions to
/etc/conf.modules and /etc/devinfo in the postinst script.

- Jim Van Zandt


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .



Re: killall is removed from procps

1998-01-02 Thread Joey Hess
BTW, could you make a procps-dev package with a libproc.a, and libproc's .h
files in it? I need this for a package I would like to make called
w.bassman, it's a different version of 'w', that links with libproc, and
needs whattime.h to build.

-- 
see shy jo


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .