Re: -rpath with libtool and Debian Linux

[Jason Gunthorpe]

On 27 Jan 1999, Alexandre Oliva wrote:

> > You know, I seem to remember that there is another rather unpleasent
> > side-effect of rpath - it basically completely disables library searching
> > and thus disables LD_LIBRARY_PATH, once you have used rpath it is not easy
> > for a user replace that library (for whatever reason) and I find that
> > highly annoying.
> 
> Well, he could always move the library elsewhere and put whatever he
> wants in its place...  Some people might be consider it a bug in the
> dynamic linker, that could look at LD_LIBRARY_PATH before -rpath.  I
> think -rpath really means it, so I consider the behavior correct
> (albeit a bit inconvenient for us, maintainers of libtool)

Actually you want to know why I remember this? I used libtool a while back
and I installed a copy of my program in /usr/bin and /usr/lib and wanted
to us a new local copy of my libtool program. Of course libtool had used
-rpath to make sure that my local binary used /usr/lib (as it was intended
to be installed there someday) and then used LD_LIBRARY_PATH in the
wrapper script to try to override this. Needless to say it did not work
and it took me a bit of figuring to determine why my changes had no
effect. Even in an all libtool environment rpath causes pain.

Actually you might have something there with the search order. What if the
linker were to examine it's library list before examining rpath, rpath
would be like a compiled in default search path instead of a compiled in
search path override. The ld-linux people probably would not go for that
though.

Incidently from what I've read I think that description of rpath more
closely matches what you want to use it for than does it's current
behavior. 

> > The linux dynamic linker will resolve things in some magical way based on
> > the library dependencies and the program dependencies to locate the proper
> > library in many cases - rpath does cripples, not enhances, this function.
> 
> Since you do support -rpath in your system, you should probably extend
> your dynamic linker to work in this case too, or risk taking the blame
> for silently breaking applications, if the poor user ever understands
> what happened to his program.

Well then you change the meaning of rpath, if you accept rpath means 'use
this library not matter what the consequences' then it is arguable the
user should expect that from rpath.

> This is a good point.  But since all of you face this same problem,
> and all of you use the same major versions of libc, you can probably
> agree on a solution that would benefit you all.  Or arrange, via

Lol! There has been little luck in that area, the only way to do it would
really be to convince all the upstream maintianers to do that and then
force those changes on the distributions. In any event as we agree below
this is not an adaquate solution.

> inter-package dependencies, that required libraries are installed in
> the proper places.

No, we are talking about 3rd party binary applications such as netscape -
arguably they are a compelling reason why we use the scheme we do.

> It seems to me that the main problem has to do with library
> versioning.  Even though the existing library versioning mechanisms
> are great to describe the evolution of the API offerred by a library,
> they by no means describe the dependencies of a library, so we end up
> with libraries that have the same version numbers but that are not
> compatible at all.

Bingo. We have a dynamic linker that can complete the second half of the
puzzle if all available major versions of a library are in the search
path, it will pick the one with the matching dependencies, we as a
distribution vendor take steps to make sure that any compatibility
libraries remain within the linkers search path.
 
> What we all are desperately looking for is a mechanism to allow the
> dynamic loader to pick the right version of a shared library out of a
> set of multiple builds of the same version of a library, the main
> difference between them being their dependencies.

I belive we already have this capablility - the only problem is that rpath
disables it. If rpath did not break the normal library searching
mechanisms then nobody would care that libtool uses it. [See above]

> If there is more than one dependency, there is no way to ensure that
> the major version number is increased whenever it has to be.  Or I
> just can't find out how :-)

No, you will never be able to work this out because you have to get the
upstream author to do it, assume for instance that we changed our xlib6
soname to be libX11.so.6-C6-ICE6 then anything that is linked on our
system will not work on a redhat one unless they did the same and then
people who compile out of the tar ball would be in trouble and so on.

Permuting the soname is not a good enough solution because it cannot be
applied universally and consistently.

> > We must be able to turn it off for libraries used on our system!
> 
> I have already told you o

Re: GNOME in potato needs slink libs

[John Lapeyre]

ftp1.us.debian.org now has everything to install all the gnome stuff
   libgtop0 is there too.


-- 
John Lapeyre <[EMAIL PROTECTED]>
Tucson,AZ http://www.physics.arizona.edu/~lapeyre

Re: cron has gone to UTC time?

[Jason Gunthorpe]

On 27 Jan 1999, Douglas Bates wrote:

> Is there a chance that cron has switched to UTC?

It is a reported bug, if you stop and then restart cron it will go away,
you might want to not do that in case there is some way you can help Steve
find out what gives (ie wait for him to email you)

Jason

Re: Getting Slink compatible with Linux-2.2.0

[Steve McIntyre]

In article <[EMAIL PROTECTED]> you write:
>
>a) If you DO NEED a > 128 MB swap file you are in serious trouble.  You
>   should get more ram; the induced cost of extremely slow operation is much
>   higher than that of two lousy DIMMs.

Don't think so small. Some of us run quite big machines on Debian; my
workstation/server at work has ~300MB of swap configured from ~25GB of
disk. >128 MB of swap is _not_ very big...

-- 
Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED]
http://www.chiark.greenend.org.uk/~stevem/comp/>My PC page
"Can't keep my eyes from the circling sky, +--
"Tongue-tied & twisted, Just an earth-bound misfit, I..."  |Finger for PGP key

Re: Getting Slink compatible with Linux-2.2.0

[David Welton]

On Thu, Jan 28, 1999 at 12:58:41AM +, Steve McIntyre wrote:
> In article <[EMAIL PROTECTED]> you write:
> >
> >a) If you DO NEED a > 128 MB swap file you are in serious trouble.  You
> >   should get more ram; the induced cost of extremely slow operation is much
> >   higher than that of two lousy DIMMs.
> 
> Don't think so small. Some of us run quite big machines on Debian; my
> workstation/server at work has ~300MB of swap configured from ~25GB of
> disk. >128 MB of swap is _not_ very big...

Yeah, I agree.  Isn't it possible to create multiple swap partitions
though?  Infact, this makes more sense, in some ways, because you are
utilizing different devices, and, if you can swing it so that you put
your main swap on a different disk than the one that gets the most
use, you can speed things up...  Correct?  I think the size should be
increased, though.

-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: -rpath with libtool and Debian Linux

[Ben Gertzfield]

> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:

Ben> With Debian and Red Hat, it's totally the opposite. Moving
Ben> libraries around is what leads to upgrades being possible.

Alexandre> Then why do you find so much trouble with it?

Because of -rpath. :)

That's the only reason we've run into trouble with it.

-- 
Brought to you by the letters D and P and the number 9.
"What's green and sits in the corner? ... A naughty frog!"
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.

Re: Intent to package xfntbase, xfnt75, etc.

[Branden Robinson]

On Wed, Jan 27, 1999 at 08:01:28PM +0100, Santiago Vila wrote:
> I intend to package all the dummy packages we have been talking about. 
> They match the packages that changed its name in the great X
> reorganization.

You'll do no such thing or I will take drastic measures.  Those packages
are MINE.  If the dummy packages are going to be created, it's going to be
me who does it.

It only makes sense, since I am more familiar with the X packages than you
are.

> *) We have discussed enough, it's time to do something positive so that
> this issue is solved as soon as possible.

You've made it clear that your only definition of "something positive" is
whatever it is you want to do.  That definition is unacceptable to me.
John Hasler might like it but there are about 400 other people to ask.

If necessary, I will submit a proposal to the debian-policy group, which
seems to be populated by most of the developers who care to pick nits
over the details like this.  I'd ask you to, but your track record on
this issue does not inspire me with much confidence in your objectivity.

As evidence of that, I submit your "intent to package" message.  Rather
than sticking to points, you can't help but indulge in arrogant
condescention.  Such tactics are not how mature people settle technical
disputes.

> * (From Branden Robinson) "Ok, don't worry, I think I should be the one to
> do it, since I'm the X maintainer".

Barring a better solution, I will be the one to do this.  The xbase dummy
package is already implemented in my current build tree and it makes sense
for these all to be generated from the same source package.

> * "You should not create them because they are useless".
> 
> Not true, since lot of people expect the old packages to be upgraded by
> the new ones automatically, these packages are exactly which is needed
> (with existing tools) so that the upgrade is done automatically.

Non sequitur.  The packages *are* useless in a purely functional sense,
i.e., they are not ends in themselves, nor a means to anything but
overcoming limitations in the packaging system.

The "principle of least surprise" is a far better way of wording the above.
Ironic that it should be I who has to provide you with this term.

> * "Don't do it, they are ugly".
> 
> Having an ugly thing does not mean it may not be useful as well.
> Functionality is more important than aesthetics.

The problem is ugly.  So is your solution.  I will concede that there may
not be a pretty solution short of adding a feature to the packaging system.
It does not follow that your proposal is the best of all possible
solutions.

> * "There should be some better way".
> 
> Fine. Which one?

Is there a way to have a dpkg --set-selections call lurk in the background
until the current dpkg process ends, like update-menus does now?  That
would be a far cleaner solution.

E.g., in the xbase postinst, embed or call the following logic:
  while (dpkg running)
wait

  for oldpackage in xfntbase xfnt75 xfnt100 ... xslib xslibg; do
case $oldpackage in
  xfntbase) newpackage=xfonts-base ;;
  ...
  xslibg) newpackage=xlib6g-static ;;
esac
echo "$newpackage install" | dpkg --set-selections
  done

The second half is easy.  Waiting for dpkg to finish is what I don't know
how to do.  There is also the issue of guaranteeing that apt(?) is invoked
to realize the state of the new selections.

At any rate, other proposals need to be submitted and discussed.  The best
thing you could do would be to direct your energies into encouraging such
alternative proposals, rather than pursuing your own pet solution with such
monomania.

I will not let you make this decision for me.  I'm not going to disregard
the collective knowledge and experience of the other Debian developers just
to get you off my back.

I will not be bullied.  I will not be intimidated.  And I will not have
my package (or any of its components) hijacked by you.  If you feel I
have mismanaged or handled XFree86 irresponsibly, then I trust you will
submit the matter to the project leadership for appropriate due process.

Otherwise, I hope you will soon rediscover the concept of "friendly
cooperation".

-- 
G. Branden Robinson  |   Any man who does not realize that he is
Debian GNU/Linux |   half an animal is only half a man.
[EMAIL PROTECTED]   |   -- Thornton Wilder
cartoon.ecn.purdue.edu/~branden/ |


pgp2RuZaxpS5p.pgp
Description: PGP signature

Re: Getting Slink compatible with Linux-2.2.0

[Marcelo E. Magallon]

>> Steve McIntyre <[EMAIL PROTECTED]> writes:

 > Don't think so small. Some of us run quite big machines on Debian; my
 > workstation/server at work has ~300MB of swap configured from ~25GB of
 > disk. >128 MB of swap is _not_ very big...

 I'm NOT thinking small.  I'm thinking efficiency.  You are talking 6
 full orders of magnitude in terms of access time.  If you have the
 money to pay for 25 GB of hard disk, I'm sure you have the money to
 afford a motherboard that can take over 1 GB of RAM.  Even if 1 GB of
 RAM is way more expensive than 25 GB of HD, it's not 6 orders of
 magnitude more expensive.


 Marcelo

Re: Intent to package xfntbase, xfnt75, etc.

[Avery Pennarun]

On Wed, Jan 27, 1999 at 08:43:30PM -0500, Branden Robinson wrote:

> > * "There should be some better way".
> > 
> > Fine. Which one?
> 
> Is there a way to have a dpkg --set-selections call lurk in the background
> until the current dpkg process ends, like update-menus does now?  That
> would be a far cleaner solution.

Sure, why not do it in exactly the way update-menus does?  I think it just
looks for a lock file in some directory or another.

>   while (dpkg running)
> wait

Good...

>   for oldpackage in xfntbase xfnt75 xfnt100 ... xslib xslibg; do
> case $oldpackage in
>   xfntbase) newpackage=xfonts-base ;;
>   ...
>   xslibg) newpackage=xlib6g-static ;;
> esac
> echo "$newpackage install" | dpkg --set-selections
>   done

Be careful!  This way, you're forcing all of the above packages to be
installed, which you could just as easily have done with a dependency by
the dummy xbase.

 oldpackages="$(dpkg --get-selections 
| egrep '^(xfntbase|xfnt75|...)'
| awk '{print $1}')"
 for oldpackage in $oldpackages; do
[ "$oldpackage" = "xfntbase" ] && echo "xfonts-base install"
...
 done | dpkg --set-selections

Every invocation of dpkg is horribly slow, so we should try to limit it to
one call each of get-selections and set-selections.  The above should do the
job, but it's untested so there are probably syntax or logical errors.
 
> The second half is easy.  Waiting for dpkg to finish is what I don't know
> how to do.  There is also the issue of guaranteeing that apt(?) is invoked
> to realize the state of the new selections.

Hmm, I don't think that's necessary; apt only seems to cache _available_
packages, not user selections, I think.

Besides, if dselect/apt don't notice the preference changes immediately,
it's still okay -- just the "new" packages won't be installed until next
time dselect/apt are run.  Big deal.  As we know, the old packages aren't
hurting anything anyway.

Now, on with the flamewar!  Don't let me stand in your way.

Have fun,

Avery

Re: Uploaded util-linux 2.9g-6 (source i386) to master

[Brian White]

> > To do so would indicate that Slink officially supports v2.2 of the kernel,
> > which it does not.
>
> What about a README file that says: No, Debian doesn't officially
> support 2.2, but for those people who hadn't enough bandwidth but
> enough courage here are the sources.

I don't mind so much letting the kernel source in.  It can't be installed
without a sufficient amount of thought so won't be attempted by anybody
who doesn't have some idea what they're doing.

  Brian
  ( [EMAIL PROTECTED] )

---
   I am Homer of Borg.  Resistance is futi...  M, donuts!

Re: cron has gone to UTC time?

[Steve Greenland]

On 27-Jan-99, 16:54 (CST), Douglas Bates <[EMAIL PROTECTED]> wrote: 
> On a slink machine I have a crontab entry that should perform an rsync
> of a site that I mirror around 22:40 my time (-0600).  I have started to
> get the reports from the job a little after 16:40 my time which just
> happens to be 22:40 UTC.

If you have not yet restarted your cron daemon, could you add a command
to your cron file that does 'date' and 'date -u'? Set it to run more
than (your timezone offset) in the future...send me the output, the
crontab entry, and if possible the extract of cron.log that shows the
thing running. (If you are not currently logging cron, add this entry to
your syslog.conf and then do 'kill -HUP /var/run/syslogd.pid'

cron.*  /var/log/cron.log 

The other interesting thing would be a list of the packages you have
newly installed or upgraded recently -- Jason Gunthorpe thinks there may
be a relationship. Anything you can think of would be a help...

Assuming, of course, that the machine involved can be used in this way.
If it can't be done, no problem, but if you see it again, please do as
much as the above as you can before you restart cron.

debian-devel folks: if any of you see similar behaviour in cron, and if
you have the time, please try the above experiment.

Thanks
Steve

Re: Getting Slink compatible with Linux-2.2.0

[Avery Pennarun]

On Wed, Jan 27, 1999 at 08:13:30PM -0600, Marcelo E. Magallon wrote:

> >> Steve McIntyre <[EMAIL PROTECTED]> writes:
> 
>  > Don't think so small. Some of us run quite big machines on Debian; my
>  > workstation/server at work has ~300MB of swap configured from ~25GB of
>  > disk. >128 MB of swap is _not_ very big...
> 
>  I'm NOT thinking small.  I'm thinking efficiency.  You are talking 6
>  full orders of magnitude in terms of access time.  If you have the
>  money to pay for 25 GB of hard disk, I'm sure you have the money to
>  afford a motherboard that can take over 1 GB of RAM.  Even if 1 GB of
>  RAM is way more expensive than 25 GB of HD, it's not 6 orders of
>  magnitude more expensive.

Six orders of magnitude??  In the unlikely event that my 100 MHz SDRAM can
really handle 32 bits (4 bytes) per cycle, then it can transfer 400
megabytes per second.  It's not REALLY that fast, but I'll give it the
benefit of the doubt.

Meanwhile, a relatively lame IDE hard drive can sustain about 6 megs/sec. 
So if you swap to that drive, then our 400 megs/sec main memory is about 66
times faster (between 1 and 2 orders of magnitude, speaking in powers of 10).

That's a bunch faster, but not as much as you claim.  Plus, almost all the
memory that ends up in swap doesn't get accessed very much.  The more memory
you have, the more true this becomes.  I regularly take my 64-meg Linux
system about 50 megs into swap (yay for StarOffice), and it still flies
along nicely.

This works because of two things: first, Linux's swapping code has been
getting a LOT better (probably better than anyone else's) in the recent past;
lately, instead of churning constantly, the drive sits idle a lot, even when
I'm heavily into swap.  Secondly, most programs only have a relatively small
portion of memory that they access *A LOT*.  The rest is low-bandwidth stuff
that's kept in memory for simplicity more than anything.  For example,
netscape has a big cache of graphics and scripts, and StarOffice keeps lots
of mostly-unused shared libraries and gigantic documents all in memory.

That means that on tiny-memory systems (say, 8 megs or less) swapping will
still thrash because even the often-used parts don't all fit in memory at
once.  As memory gets larger, though, swapping becomes less painful.

Try it sometime.  It actually isn't so bad.  (And at about $0.04 CDN per
megabyte on a hard drive versus $2.19 in real memory, swap space is an AWFUL
LOT cheaper.)

Now, the inefficient programmers that burped out StarOffice and Netscape in
the first place are still pretty hard to explain.

Have fun,

Avery

Re: Intent to package xfntbase, xfnt75, etc.

[John Hasler]

Branden Robinson writes:
> John Hasler might like it but there are about 400 other people to ask.

I look forward to hearing from them.  I just want to see the damn thing
fixed.  Santiago has proposed a workable solution and offered to implement
it.

> Barring a better solution, I will be the one to do this.  The xbase dummy
> package is already implemented in my current build tree and it makes
> sense for these all to be generated from the same source package.

Good.  Do it and beat him to it, and then it will be done.

> Is there a way to have a dpkg --set-selections call lurk in the
> background until the current dpkg process ends, like update-menus does
> now?  That would be a far cleaner solution.

That requires that a complex and fragile program be used in an unusual and
complex way.  The dummy package solution is, by comparison, simple and
robust.  We know how to implement it and we can be confident that it will
work.  It's so damn simple that even I could do it (don't worry: I
won't).  That's a clean solution.

> At any rate, other proposals need to be submitted and discussed. 

The split/renaming problem has been known for months.  Variations on
Santiagos's proposal have been put forward several times.  There have been
no other workable ones I am aware of (I agree that backing out the name
change is not a good idea).  Doesn't it seem that they would have been
offered by now if they existed?
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Getting Slink compatible with Linux-2.2.0

[Marcelo E. Magallon]

On Wed, Jan 27, 1999 at 10:27:15PM -0500, Avery Pennarun wrote:

> Six orders of magnitude??  In the unlikely event that my 100 MHz SDRAM can
> really handle 32 bits (4 bytes) per cycle, then it can transfer 400
> megabytes per second.  It's not REALLY that fast, but I'll give it the
> benefit of the doubt.

 Let me note I was replying in the context of huge swap files on huge hard
 disks.

 Tim's (and I think Ben also) example is the best one in this case: the seek
 time for a hard disk (~ ms) vs the access time for ram (~ ns) suddenly
 become important when you are talking about ~ GB of RAM.  If you are
 talking about big databases where access is basically random, access time
 can become a serious bottleneck.

 But my original comment was posted because of someone's intention to put
 util-linux 2.9g on slink to get it "in sync" with 2.2 kernels (> 128 MB
 swap on a single partition) so this is rather off-topic.


Marcelo

Re: Intent to package wterm

[Marcelo E. Magallon]

On Wed, Jan 27, 1999 at 02:53:30PM -0800, Adam Klein wrote:
> On Wed, Jan 27, 1999 at 11:05:43AM -0600, Marcelo E. Magallon wrote:
> > I mean the debian patches. Some of them are incorporated upstream, some are
> > not.
> 
> Oh, fro the rxvt package?  hmm.  Do I need to incorporate those?

Well, they are there for a reason, aren't they?


Marcelo

kerberos, encrypted file systems, secure-linux 0.6, more

[Bear Giles]

I'm wrapping up my first beta disk for (*sigh*) US-only GNU/Linux
security tools.  As many of you know, this quasi-distribution was
the cause of some recent discussions.  See [1].

This quasi-distribution contains material which definitely *cannot* 
be exported without permission from my dear uncle:

 - an initial MIT Kerberos 5 package.  Kerberos 4 is available
   from non-US, but the foreign K5 package is apparently not ready
   for regular use.

 - several packages recompiled to use Kerberos 5/GSSAPI authentication:
   CVS, LPRNG, IMAP.  Packages which use Kerberos 4 authentication
   (e.g., AMANDA) have not been recompiled since they can be 
   distributed in non-US.

   Actually, these packages are already exported.  But nobody
   outside of the US/Canada can rebuild them. :-(
 
 - Kernels 2.0.35 and 2.0.36 rebuilt with support for the Berkeley 
   (cypherpunks) encrypted file system.  The loop device changed 
   significantly in 2.2.0, so I don't know when support will be 
   available in that line.  (uname: 2.0.x-efs).  See the article
   in Linux Journal about a year ago.  
   
   (This also requires a patched 'mount' from util-linux 2.9g, and 
   that in turn might require newer packages.)

   (These patches may also be available outside of the US; if so,
   someone else could package these kernels for nonus.)

 - xfree86 rebuilt with support for XDM-AUTHENTICATION-1.  Unlike
   MIT-COOKIES-1, this authentication method is secure even when a
   network sniffer is present.  The xfree86 MIT-KERBEROS-5 code 
   expects a different API than the MIT k5-1.0.5 distribution, so
   I don't have support for it yet.  (This is 3.3.3.1 with modified
   makefiles from a December slink snapshot.)

 - "non-US" mirrors for hamm and slink, since I'm not repackaging
   files already available from those sites.

Before you dismiss the entire idea of US-only packages, I need to
point out that several large companies are already folding Kerberos
authentication into their tools.  Windows NT 5 may not be out for
years, but some cable modem systems use Kerberos authentication
(or a derivative of it) today... and these same cable modem system
use the lack of Kerberos support in Linux as a reason for not 
supporting it.  (The Kerberos support in Windows 9x may only be a
crippled DLL... but it's on the "free software" disk these companies 
hand out.)  Likewise, some universities use Kerberos authentication 
for their on-campus networks.

In other words, is this glass "half full" or "half empty"?


This disk also contains some material which should be exportable,
and I'm offering them for incorporation into Debian (modulo the
comment below):

 - kernels 2.0.35 and 2.0.36 patched with "secure linux 0.6".
   (http://www.false.com/security/linux/).  I don't have too
   much doubt about the value of the patches (do a yahoo search
   on "+secure-linux +patch", but in light of "moduleinfect.c"
   and the problems with TCP-wrappers and util-linux I'm paranoid
   that the patches might have been corrupted.  Some documentation 
   follows.  (uname:  2.0.x-s).

 - rainbow: the "rainbow books" on computer security, from
   http://www.radium.ncsc.mil/tpep/library/rainbow/.  I don't
   recall seeing an explicit copyright statement, but government
   documents on a government site should be public domain.
   (I can always file a FOIA :-)

I would simply upload these packages, except my "new maintainer"
status has become controversial and I don't have access to the
upload area.

I'm also looking for a distribution site which can handle a large
amount of data subject to US export control; that eliminates cheap
host sites and all OSS sites with automatic mirrors.

A limited number of CD-R disks are available for beta testing.
Preference will be given to sites running Kerberos (typically,
large universities and some cable modem systems).  I'll also
send one to anyone (modulo below) for the price of materials
and postage; call it $5.00.

Due to export regulations, I can only ship the disks to US and
Canadian residents.  I also need your e-mail to state that you
do not intend to export it in violation of US or Canadian law.
I agree the law is stupid and grossly misguided, but I'm still
working to change the system from within.

Bear Giles
[EMAIL PROTECTED]
   
-
   
[1]
For the record, I highly value "fairness."  In the past, some of 
my employers have tried to claim that *any* code I work on at *any*
time and under *any* circumstances is their property.   I told them 
to take a flying leap.  I've had universities tell me that all code
developed for classes was their property... and as a graduate
student we weren't always talking about trivial programs.  I said 
no way, gave them a theoretical question involving research motivated
by a real world problem faced by my employer, then did all of my work
on my own hardware.

I firmly believe the same thing applies with volunteer efforts.
When I'm volunteering work for Debian, it c

i'll take netris was: Packages to give away

[chomsky]

I'm a fan of netris, so I'll adopt this proggy.

I already recompiled with ncurses4, seems to be OK so far but i'll do
some more testing (wheee gotta love testing games), churn out a manpage
or two, and upload it to potato.

Blert!

-- 
C. Thomas   |   -o) / /  (_)__  __   __
Penguin Fetishist & |   /\\/ /__/ / _ \/ // /\ \/ /
Debian GNU/Linux Developer  |  _\_v/_/_//_/\_,_/ /_/\_\
"When a foolish man hears of the Tao, he laughs out loud.
 If he didn't laugh, it wouldn't be the Tao."
 --Lao Tzu, Tao Te Ching

Re: Intent to package xfntbase, xfnt75, etc.

[Branden Robinson]

On Wed, Jan 27, 1999 at 09:18:22PM -0500, Avery Pennarun wrote:
>  oldpackages="$(dpkg --get-selections 
>   | egrep '^(xfntbase|xfnt75|...)'
>   | awk '{print $1}')"

Oops.  I was thinking this part but didn't type it.  Yes, of course -- we
don't want to select newpackage for installation if the corresponding
oldpackage is not present.

Thanks.

-- 
G. Branden Robinson  |
Debian GNU/Linux |   If God had intended for man to go about
[EMAIL PROTECTED]   |   naked, we would have been born that way.
cartoon.ecn.purdue.edu/~branden/ |


pgpE22scpMsdD.pgp
Description: PGP signature

Re: Looking for someone to take over Imlib

[Branden Robinson]

On Wed, Jan 27, 1999 at 01:23:17PM -0500, Brian Almeida wrote:
> On Wed, Jan 27, 1999 at 11:57:39AM -0600, Ossama Othman wrote:
> > If no one else will take your Imlib packages, I will.  Let me know what
> > you think.
> They're yours. 

God save us.

-- 
G. Branden Robinson  |   You can have my PGP passphrase when you
Debian GNU/Linux |   pry it from my cold, dead brain.
[EMAIL PROTECTED]   |   -- Adam Thornton
cartoon.ecn.purdue.edu/~branden/ |


pgpj2MrJWdzaS.pgp
Description: PGP signature

Re: What's needed for kernel 2.2

[Michael Meskes]

On Wed, Jan 27, 1999 at 12:19:44AM +, Mark Brown wrote:
> While the userland binaries appear to work fine, the PCMCIA kernel module 
> source in slink will not build with 2.2 kernels.  Version 3.0.8 fixes
> this.

This appears to be a minor problem. I just put -DEXPORT_SYMTAB into
clients/Makefile and all is working well with 3.0.6 and 2.2.0.

Michael

-- 
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: [EMAIL PROTECTED]  | Use PostgreSQL!

Re: Intent to package: olex

[Tommi Virtanen]

On Wed, Jan 27, 1999 at 01:33:30PM -0200, Lalo Martins wrote:
> While doing my necessary daily check of Slashdot and Freshmeat,
> I noticed two programs I will most likely use - one is irssi, a
> GTK IRC client that runs in the panel, but I can't package it
> now because none of my GTK-1.1 stuff is working (figures I'll
> have to give a nasty day to my poor low bandwidth to fix). If
> anyone's interested in trying, its homepage is at
> http://www.sicom.fi/~ikioma/irssi.html (wnpp - this may be added
> to "software that should be packaged) and it's from the guy who
> originally wrote yagirc.

I'll package that, if you don't get your system to work.
I'm using a privately .debbed irssi right now.
-- 
foo | +358505486010 | [EMAIL PROTECTED] | mknod /dev/trash c 1 3

PLEASE remember to vote!

[Joseph Carter]

On Thu, Jan 28, 1999 at 06:06:04AM -, Project Secretary wrote:
> This is the last and final ballot.  In a weeks time, we will have a new 
> leader *or* we'll have to start this process over again because "NONE"
> won.  If you havn't voted, please cast your ballot now.

I know I speak for all four of us candidates when I say that your vote IS
important.  This is your project leader you're voting for here.  Please
do not forget and please do make your opinion heard!  Or if not heard at
least make it be tallied...  =>

This is the last week of voting and as our secretary has pointed out, if
nobody wins this election we start all over again and some of us would be
made insane in that process, probably starting with Mr. Secretary
himself I suspect.  =>  And we can't have an insane secretary now can we? 
He'd then be forced to run for project leader himself then wouldn't he?

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

/usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version

[Ivan E. Moore II]

/usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version

This happens with some of the GNOME based packages I've installed
from both slink and potatoe lately...

Any ideas what I'm missing or what I did???

thanks

Ivan
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ivan E. Moore II  Rev. Krusty
http://www.tdyc.com  [EMAIL PROTECTED]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Imagination is more important than knowledge  - Albert Einstien
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
GPG KeyID=0E1A75E3
GPG Fingerprint=3291 F65F 01C9 A4EC DD46 C6AB FBBC D7FF 0E1A 75E3
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: /usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version

[Mikolaj J. Habryn]

> "IEM" == Ivan E Moore <[EMAIL PROTECTED]> writes:

IEM> /usr/lib/libgnomeui.so.0: undefined symbol:
IEM> argp_program_version This happens with some of the GNOME
IEM> based packages I've installed from both slink and potatoe
IEM> lately...
IEM> Any ideas what I'm missing or what I did???

  One of the backend libraries changed. libimlib, from memory, caused
this going from 1.8 to 1.9. Make sure you've upgraded everything, and
if it still doesn't work, rebuild things in the right order.

m, who did this for alpha just a few days ago.

Re: PLEASE remember to vote!

[Andreas Tille]

On Wed, 27 Jan 1999, Joseph Carter wrote:

> I know I speak for all four of us candidates when I say that your vote IS
> important.  This is your project leader you're voting for here.  Please
> do not forget and please do make your opinion heard!  Or if not heard at
> least make it be tallied...  =>
> 
> This is the last week of voting and as our secretary has pointed out, if
> nobody wins this election we start all over again and some of us would be
> made insane in that process, probably starting with Mr. Secretary
> himself I suspect.  =>  And we can't have an insane secretary now can we? 
> He'd then be forced to run for project leader himself then wouldn't he?
Sorry for my ignorance when deleting the mails under this topic.  I
was absend from the net for a longer time and couldn't read all my
E-Mails.  Please repeate the link where to vote for those like me
who ignored the mails.  I couldn't find a site to vote.

Kind regards

   Andreas.

Re: Reality check! [was: Re: Debian goes big business?]

[Stephane Bortzmeyer]

On Wednesday 27 January 1999, at 14 h 40, the keyboard of Paul Seelig 
<[EMAIL PROTECTED]> wrote:

> Sorry, i currently don't have any access to the sources of the boot
> floppies and therefore don't know about the TODO list's contents.  

You can get the last version by CVS:

:ext:[EMAIL PROTECTED]:/debian/home/sr1/lib/cvs/boot-floppies

> i downloaded the boot and base floppies and did a base install with
> them.  Strange enough the yes/no answering at the configuration stage
> right after the first booting from the freshly installed base system
> didn't work. 

This bug has been reported #32324 and fixed since.

> What i miss after the base install is:
> 
>   - a default entry with the correct block device as used for the
> installation for accessing the CD drive in /etc/fstab like:
> 
>  /dev/hdc  /cdrom  iso9660  ro,noauto,user 0   0

A small possible problem: it conflicts with the default access method for 
dselect, multi_cd, which does not expect the CD to be already mounted (even 
with "noauto", this is a risk). So, it would require a reorganization. But the 
/dev/cdrom link is there and is more important, IMHO. It allows multi_cd to go 
on smoothly.
 
> The preselection "profiles/Admin" contains *three* Emacs variants
> (emacs19/20 and xemacs20). The same case in "profiles/Devel_comp",
> "profiles/Devel_std", "profiles/Dialup", "profiles/Work_sci",
> "profiles/Work_std" and "profiles/Standard" contains both emacs19/20.
> That's somewhat pretty insane IMHO because usually one single emacs
> (preferably the smallest and fastest) should definitely suffice

Well, I'll suggest that for potato. It will start a nice flame-war on 
debian-devel "emacs vs. xemacs".

> leaving all other variants as an option for later installation to the
> installer's discretion.  Likewise for the vi variations.  Which emacs
> or vi to use is a matter of personal choice of the installer.  

This contradicts the whole idea of profiles. A profile is a predefined set of 
choices that *we* think OK and the installer which chooses a profile trusts us 
blindly. I regard the Average User as unable to choose between emacs and 
xemacs at the beginning (or between exim and sendmail or between apache and 
roxen). So, we choose for him.

> I think it is a very bad habit to first fill up the disk with
> redundant selections and then expect the installer to deinstalll what
> [s]he doesn't like/want in order to make room for other software.  

This is a typical example of the main problem with the "Let's make everything 
easier for Joe User" approach: nobody agrees on what is easier.

For me, I think that most users expect things to be already there ("I've read 
in an Unix manual about tcpdump and Debian hasn't it. This distribution is 
broken.") without a new installation, which will certainly be painful for the 
typical user.

> machine, but possibly far less capable hardware.  The wealth of
> software coming with Debian doesn't mean that everything and the
> kitchen sink should be installed.

Most of the messages I received, as the maintainer of the list of pre-defined 
profiles are "XXX is missing, why don't you add it?".

> What i'd like to see is something like "profiles/Textprocessing" for
> the writing people containing the TeX system and text/PostScript
> related utilities.  In any case i'll try to make up such a selection
> and send it to you ASAP.

Be my guest.

Re: Reality check! [was: Re: Debian goes big business?]

[Christian Meder]

On Thu, Jan 28, 1999 at 10:08:40AM +0100, Stephane Bortzmeyer wrote:
> On Wednesday 27 January 1999, at 14 h 40, the keyboard of Paul Seelig 
> <[EMAIL PROTECTED]> wrote:
> > What i'd like to see is something like "profiles/Textprocessing" for
> > the writing people containing the TeX system and text/PostScript
> > related utilities.  In any case i'll try to make up such a selection
> > and send it to you ASAP.
> 
> Be my guest.

Hmmm 
I remember I made a pretty complete TeX profile when I created the profiles
for hamm. Isn't it there anymore ?

Greetings,



Christian

PS.: Thanks for taking over the profiles and tasks, Stephane, you did a 
splendid job so far. And no, I didn't use any sophisticated scripts for 
generating the set of profiles for hamm, your perl scripts are a big
improvement.

Now back to getting Debian/Sparc done ;-)
-- 
Christian Meder, email: [EMAIL PROTECTED]
 
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows, 
It sets the sand a-blowing,
And the blackberries a-growing.
  (Henry David Thoreau)
 

Re: Reality check! [was: Re: Debian goes big business?]

[Stephane Bortzmeyer]

On Thursday 28 January 1999, at 11 h 23, the keyboard of Christian Meder 
<[EMAIL PROTECTED]> wrote:

> I remember I made a pretty complete TeX profile when I created the profiles
> for hamm. Isn't it there anymore ?

There is a TeX *task* (not a profile) of 201 Mb (it includes all the 
dependencies, so it goes down to lprng, cpio, perl...). Very complete I hope, 
giving the size :-)

XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86

[Branden Robinson]

This is what I hope to be the final test build of XFree86 3.3.2.3a-9; if
there are no significant problems it will be released with that version
number.  This test build addresses all four release-critical bugs currently
outstanding against XFree86.

There are exactly 5 things I want to do for -10, and then I will declare
slink X done (barring any nasty bugs that crop up).

* have XF86Setup mung /etc/X11/Xserver (and call correct X server during
  test)
* deal with new font and static library packages in the upgrade department
* XKB and locale fixes for our non-American friends
  (bugs.debian.org/xlib6g)
* merge alpha patches
* merge sparc patches

The xf86config program has already been modified to edit /etc/X11/Xserver,
thanks to Robert Woodcock.  XF86Setup is more difficult, mainly because
it's written in tcl.  Any volunteers to do this are strongly encouraged to
step forward.

I don't know yet exactly how the new font and static library packages will
be handled.  I want to build developer consensus on a solution.

Alpha and sparc patches need to be i386-safe.  I don't know that they
aren't; I haven't checked closely yet.  My next test build will likely
incorporate the alpha patches and I will want to see if it works okay on
i386.  Almost all of the Alpha patches have to do with 64-bit alignment
issues, and should not affect the i386.  But there's always the chance of
something lurking...

If some sparc folks could confirm that their patches are similarly safe for
i386 consumption I'll subsequently add those.  I imagine the Alpha patches
will make life easier for the sparc64/UltraLinux port (do we have one
yet?).

And that's it...

People who used test build 5 should probably remove or purge (and
optionally reinstall an earlier, official version of) the XFree86 packages.
In test build 5 xbase-clients was renamed to xclients-misc, but it was
recently brought to my attention just how awful package renaming can be.
So I backed that change out.  The current control file has no notion of any
xclients-misc package.

There are a few things in particular that I'd really like tested:

*) Upgrades from hamm xbase (3.3.2.3-2 or earlier) should automatically
suck in xterm, xdm, xfs, xbase-clients, and so forth.

*) No damn circular symlinks.  Check the /etc/X11/xinit and
/etc/X11/xserver directories for them.  Some of my postinsts, and dpkg
itself, should scream at upgrade time if this happens, but it never hurts
to be sure.

*) Make sure /usr/doc/xbase/README.Debian is present.  For reasons I cannot
fathom, on some systems it just isn't being installed.  I got a bug about
this and reassigned it to dpkg since dpkg-deb --contents xbase said the
file should be there (so did dpkg -L xbase).

*) Make sure the locales directory is present (/usr/lib/X11/locales).

*) If you have xlib6 installed, ensure the following link is present:

usr/i486-linuxlibc1/lib/X11/locale -> ../../../X11R6/lib/X11/locale

*) Run the xf86config program in xserver-common and verify that it writes
the name of the selected X server to /etc/X11/Xserver if asked to (and that
it doesn't if the user says not to).  It should create this file if it is
not present, and not modify anything other than the first line if it does.

*) Disable local X server checking in xdm (see /etc/X11/xdm/xdm.options and
man xdm.options), then sabotage the XF86Config file so that the server will
bomb.  Check that with startx.  Then start xdm, have it run the local
server, and see if you get the loop of death.  I got a patch from Marcelo
Magallon that should prevent this.  xdm should now obey the startAttempts
resource, and only try to start the X server 4 times.  man xdm for more
info.

The XF86Config file is easily sabotaged by a line like:
   VertRefresh 50---120
in the Monitor section.

Those are the big ones.  Folks with lots of energy may want to step
through the almost 200-line changelog, look at the many bug reports that
are referenced, and attempt to confirm the fixes.

-- 
G. Branden Robinson  |
Debian GNU/Linux |// // //  / /
[EMAIL PROTECTED]   |EI 'AANIIGOO 'AHOOT'E
cartoon.ecn.purdue.edu/~branden/ |
xfree86 (3.3.2.3a-8pre9v6) frozen unstable; urgency=low

  * Test release.  DO NOT use the Debian Bug Tracking system to report bugs
in this release of XFree86; instead mail them directly to
<[EMAIL PROTECTED]>.
  * thanks to David Huggins-Daines and Rene Hojbjerg Larsen for finding some
annoying bugs
  * xbase is now a pseudo-package used to smooth upgrades from hamm or
earlier systems
  * what was the new xbase is now xfree86-common
  * moved xinit and startx from xserver-common to xbase-clients; xinit is
linked against the X libs, so it is out of place in xserver-common
(Fixes: #29166)
  * moved xvidtune from xf86setup to xbase-clients
  * removed xmodmap package, its contents are now in xbase-clients
  * config/cf/xfree86.cf: apply m68k patch
  * programs/Xserver/Xp

voting instructions on the web [was: PLEASE remember to vote!]

[Gordon Matzigkeit]

Hi!

> Andreas Tille writes:

 AT> Sorry for my ignorance when deleting the mails under this topic.
 AT> I was absend from the net for a longer time and couldn't read all
 AT> my E-Mails.  Please repeate the link where to vote for those like
 AT> me who ignored the mails.  I couldn't find a site to vote.

After some searching, I found it at:

http://www.debian.org/Lists-Archives/debian-devel-announce-9901/msg00017.html

In the future, could somebody please put the ballot on the debian web
site in an obvious place (such as a link from the same page that
describes the alternatives and/or results).

Thanks,

-- 
 Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/)
Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
[Unfortunately, www.fig.org is broken.  Please stay tuned for details.]

Re: voting instructions on the web [was: PLEASE remember to vote!]

[Jules Bean]

On 28 Jan 1999, Gordon Matzigkeit wrote:

> Hi!
> 
> > Andreas Tille writes:
> 
>  AT> Sorry for my ignorance when deleting the mails under this topic.
>  AT> I was absend from the net for a longer time and couldn't read all
>  AT> my E-Mails.  Please repeate the link where to vote for those like
>  AT> me who ignored the mails.  I couldn't find a site to vote.
> 
> After some searching, I found it at:
> 
> http://www.debian.org/Lists-Archives/debian-devel-announce-9901/msg00017.html
> 
> In the future, could somebody please put the ballot on the debian web
> site in an obvious place (such as a link from the same page that
> describes the alternatives and/or results).

Well, it's on http://vote.debian.org, which is fairly obvious.

I also received information about the ballot on the following lists:

-private, -devel, -devel-announce and -vote.

That's not exactly hiding the information..

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/

Re: Looking for someone to take over Imlib

[Brian Almeida]

On Thu, Jan 28, 1999 at 01:30:31AM -0500, Branden Robinson wrote:
> On Wed, Jan 27, 1999 at 01:23:17PM -0500, Brian Almeida wrote:
> > On Wed, Jan 27, 1999 at 11:57:39AM -0600, Ossama Othman wrote:
> > > If no one else will take your Imlib packages, I will.  Let me know what
> > > you think.
> > They're yours. 
> 
> God save us.
Was that really necessary? I can name a number of people offhand who aren't
exactly satisfied with your stuff, either.  Let's all remember that we're
SUPPOSED to be working towards the same goal, not fighting each other.

Re: libtool & rpath

[Hamish Moffatt]

On Wed, Jan 27, 1999 at 08:29:42PM +, James Troup wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> 
> > +case ${host} in
> > +  *-pc-linux-gnu)
>^^
> 
> s/pc/*/ (pc==non-i386 unfriendly)

Good point. However, /usr/doc/lintian/libtool-workarounds.txt suggestions
the above, which is why I have it. No discrimination intended!

I've just started using the debian/rules version of the fix rather
than the configure.in version anyway.

Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: voting instructions on the web [was: PLEASE remember to vote!]

[Andreas Tille]

On 28 Jan 1999, Gordon Matzigkeit wrote:

> After some searching, I found it at:
> 
> http://www.debian.org/Lists-Archives/debian-devel-announce-9901/msg00017.html
> 
> In the future, could somebody please put the ballot on the debian web
> site in an obvious place (such as a link from the same page that
> describes the alternatives and/or results).
For sure.  I was looking through www.debian.org but failed.
In my opinion it is necessary to set up an election page.
I have to state that I am not able to vote because I don't know
anybody of the candidates.  The election page has to have links to
a page or pages from the candidates that a potentional elector has
a chance to get to know its favourite candidate.  I'm sure all
of them are OK but how should I decide, who of them is better than
the other if I don't know them.

Sorry for leaving my vote and good luck for the future leader.

Kind regards

  Andreas.

Re: Looking for someone to take over Imlib

[Branden Robinson]

On Thu, Jan 28, 1999 at 07:34:45AM -0500, Brian Almeida wrote:
> Was that really necessary? I can name a number of people offhand who aren't
> exactly satisfied with your stuff, either.  Let's all remember that we're
> SUPPOSED to be working towards the same goal, not fighting each other.

It *was* a joke, you know.

And people who'd like to fix bugs in XFree86 are most cordially invited to
submit working, tested patches to fix them.

-- 
G. Branden Robinson  |   Human beings rarely imagine a god that
Debian GNU/Linux |   behaves any better than a spoiled child.
[EMAIL PROTECTED]   |   -- Robert Heinlein
cartoon.ecn.purdue.edu/~branden/ |


pgp0NN3756p4j.pgp
Description: PGP signature

Re: voting instructions on the web [was: PLEASE remember to vote!]

[Andreas Tille]

On Thu, 28 Jan 1999, Andreas Tille (THAT's ME) wrote:

> For sure.  I was looking through www.debian.org but failed.
> In my opinion it is necessary to set up an election page.
> I have to state that I am not able to vote because I don't know
> anybody of the candidates.  The election page has to have links to
> a page or pages from the candidates that a potentional elector has
> a chance to get to know its favourite candidate.  I'm sure all
> of them are OK but how should I decide, who of them is better than
> the other if I don't know them.
> 
> Sorry for leaving my vote and good luck for the future leader.
Forget this garbage.  I've found it.  Sorry for this.

Kind regards

  Andreas.

Intend to package Kaffe

[Virgilio Gómez Rubio]

Hi all!

This is my first to the list so I don't really know what to say. I would
like to join to the debian developers community by "debianizing" Kaffe.
Kaffe is a JAVA Virtual Machine wich is under the GPL. Is anyone doing it?

I haven´t sent a mail to be admited into the developers group, but I'll do
it soon, when I have my PGP key ready.

Read you soon.

   Virgilio

 "Dios mio, hemos caido en manos de ingenieros"
Ian Malcom, el matemático  de "Parque Jurásico"

  http://mural.uv.es/virgoru

Re: Intend to package Kaffe

[wnpp]

"=?iso-8859-1?Q?Virgilio" == =?iso-8859-1?Q?Virgilio G=F3mez Rubio?= 
 writes:

=?iso-8859-1?Q?Virgilio> to join to the debian developers community by
=?iso-8859-1?Q?Virgilio> "debianizing" Kaffe.  Kaffe is a JAVA Virtual


Kaffe is in Incoming.


 _  _ _  
  __| | ___| |__ (_) __ _ _ __   __  ___ __  _ __  _ __  
 / _` |/ _ \ '_ \| |/ _` | '_ \  \ \ /\ / / '_ \| '_ \| '_ \ 
| (_| |  __/ |_) | | (_| | | | |  \ V  V /| | | | |_) | |_) |
 \__,_|\___|_.__/|_|\__,_|_| |_|   \_/\_/ |_| |_| .__/| .__/ 
   Debian Linux: Because Size DOES Matter   |_|   |_|

Re: Looking for someone to take over Imlib

[Brian Almeida]

On Thu, Jan 28, 1999 at 08:06:58AM -0500, Branden Robinson wrote:
> It *was* a joke, you know.
It's hard to tell sometimes. :p

building shlibs

[Hamish Moffatt]

Confused about building shlibs. I've got a package which 
contains both binaries and a library [don't flame me just yet].

The problem is that dpkg-shlibdeps says that the package depends on itself,
which lintian doesn't like.

So I'm trying to split the package. I run "dh_makeshlibs -V", since it's
alpha software and the library can be expected to change a lot. But
when dpkg-shlibdeps runs for the binary package, it uses the version
information from the currently installed version of the library,
not from the version that's being built.

Can anyone suggest a way out? I guess it must be a pretty common problem.


thanks,
Hamish
-- 
Hamish Moffatt VK3TYD  [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org

Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86

[Brandon Mitchell]

About the xfonts problem.  I haven't been following close enough to pardon
my ignorance on the subject.  What if we make the pseudo xbase package
conflict with xfnt* packages < version x (a versioned conflict)?  How will
dselect handle this, will it upgrade the fonts to the new name?  If it
works, this would seem to be a solution that everyone can live with.

Comments are welcome,
Brandon

+---  ---+
| Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ |
| The above is a completely random sequence of bits, any relation to |
|   an actual message is purely accidental.  |

RE: -rpath with libtool and Debian Linux

[Bernard Dautrevaux]

> -Message d'origine-
> De:   Ulrich Drepper [SMTP:[EMAIL PROTECTED]
> Date: jeudi 28 janvier 1999 00:54
> À:Jules Bean
> Cc:   Alexandre Oliva; Debian Developers; [EMAIL PROTECTED]
> Objet:Re: -rpath with libtool and Debian Linux
> 
> Jules Bean <[EMAIL PROTECTED]> writes:
> 
> > rpath is broken.  You said as much yourself.  rpath is broken
> because it
> > *overrides* all other sorts of library searching.
> 
> I think people here do not know about $ORIGIN.  This allows to define
> relative rpaths.  E.g., a package with a program foo and a library
> libbar.so where foo is installed in $PATH/bin and libbar.so is defined
> in $PATH/lib should use
> 
>   -rpath \$ORIGIN/../lib
> 
> The $ORIGIN is defined relative to the location of the object
> containing the reference.
> 
> This is available in Solaris 7 (maybe 2.6?) and Linux w/ glibc 2.1.
> 
This is the perfect way of doing if the same package install a common
shared library and a set of programs using it; then relative paths are
OK. By this does not solve the problem of finding independently
installed libraries or system ones... There -rpath will force to use the
absolute path of these libraries on the development system and if
installed as a binary package, these may be in slightly differing places
(I'm sure there is system libs that are in /usr/lib in some Linux
distribs but in /lib or /usr/local/lib in others...)

AFAIK this is the subject of this whole thread about -rpath: how could
we create binary distributions that WORK... (other than statically
linking all executables of course...)

Regards,

Bernard
 

--
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:+33 (0) 1 47 68 80 80
Fax:+33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]

--

Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86

[Robert Woodcock]

Branden Robinson wrote:
>*) No damn circular symlinks.  Check the /etc/X11/xinit and
>/etc/X11/xserver directories for them.  Some of my postinsts, and dpkg
>itself, should scream at upgrade time if this happens, but it never hurts
>to be sure.

I just upgraded from 3.3.2.3a-8 to 3.3.2.3a-8pre9v6 with apt-get, and they're
still there (note - they might have been there in -8 before as well - I didn't
check)

lrwxrwxrwx   1 root root   24 Nov 29 15:07 xinit/xserverrc -> 
/etc/X11/xinit/xserverrc
lrwxrwxrwx   1 root root   31 Nov 29 15:07 xserver/SecurityPolicy 
-> /etc/X11/xserver/SecurityPolicy
-- 
Robert Woodcock - [EMAIL PROTECTED]
"It's like a love-hate relationship, but without the love." -- jwz, on linux

Re: voting instructions on the web [was: PLEASE remember to vote!]

[Kevin Dalley]

Jules Bean <[EMAIL PROTECTED]> writes:


> Well, it's on http://vote.debian.org, which is fairly obvious.
> 

No, it actually isn't obvious, any more than www.debian.org/election
is obvious.  A link from the Debian home page, or the developers page,
to vote.debian.org seems like a good idea.

By the way, http://www.vote.debian.org, under current events, states
that nominations for project leader are open.  Perhaps this should be
changed to state that elections are in progress and almost over.

--
Kevin Dalley
[EMAIL PROTECTED]

Re: Intent to package wterm

[Brian Mays]

> Adam Klein wrote:

>> Oh, fro the rxvt package?  hmm.  Do I need to incorporate those?

Marcelo E. Magallon wrote:

> Well, they are there for a reason, aren't they?

Some of the patches will not need to be added, unless you are also
planning to make a Kanji, Greek, or Chinese version of wterm.

Brian

RE: voting instructions on the web [was: PLEASE remember to vote

[Darren Benham]

On 28-Jan-99 Gordon Matzigkeit wrote:
> Hi!
> After some searching, I found it at:
> 
> http://www.debian.org/Lists-Archives/debian-devel-announce-9901/msg00017.html
> 
> In the future, could somebody please put the ballot on the debian web
> site in an obvious place (such as a link from the same page that
> describes the alternatives and/or results).
> 
The site is/will be http://vote.debian.org  
This still being build but if you need information, you can always try there,
first.

-- 
Please cc all mailing list replies to me, also.
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=


pgpIDcP8ekUGh.pgp
Description: PGP signature

RE: -rpath with libtool and Debian Linux

[Bernard Dautrevaux]

> -Message d'origine-
> De:   Alexandre Oliva [SMTP:[EMAIL PROTECTED]
> Date: mercredi 27 janvier 1999 20:53
> À:J.H.M. Dassen
> Cc:   debian-devel@lists.debian.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Objet:Re: -rpath with libtool and Debian Linux
> 
> On Jan 27, 1999, "J.H.M. Dassen" <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Jan 27, 1999 at 17:07:30 -0200, Alexandre Oliva wrote:
> >> You might have included my suggestion to prevent having to move
> libraries
> >> in the first place: creating a libc6-specific directory right now,
> instead
> >> of installing libraries in /usr/lib and having to move them into
> another
> >> directory when libc7 should be released.
> 
> > I'm sorry, but this is IMHO completely backwards. On Linux systems,
> there is
> > nothing wrong with moving libraries around as the need arises.
> 
> Except that you risk replacing a library with an incompatible one.
> That's what has caused you so much trouble.  If, instead of moving the
> 
> X11 libraries to another dir and creating new, incompatible versions
> under the same pathname, you had created new versions in other
> directories, no unexpected crashes would have occurred.
> 
> > Having libtool default to -rpath is what's causing problems.
> 
> This is IMHO completely backwards :-)
> 
> When a program is linked with a shared library, a contract is
> established between them stating that the library (or any newer but
> compatible version thereof, on systems that support library
> versioning) will supply the symbols that the program resolved from it,
> and the program will be able to find the library at that point.  If
> you move the library and replace it with an incompatible one, you're
> breaking the contract and the versioning mechanism, so you can't blame
> the program for crashing, nor the tool that created the program.
> 
You mark a point here: everything is about a contract passed by you,
using the compiler, to the system on which you install. The problem is
with the exact contract passed, and interpretation of this contract. 

You say the contract is "I want to find THERE the lib that does THIS.x
and THAT.x"; I think (and that's at least true for Linux) the contract
the compiler and linker has signed was twofold; it says:
  1)   "I will give you the library that makes THIS.x and THAT.x"
  2)   "The prefered library I want you to use to obtain THIS and THAT
is there and makes THIS.x and THAT.x"
Now you trick it with -rpath in finding both the ".x" and THERE and all
the problem comes from there...

An analogy: When I wand to get hot water in restrooms, I just look at
the tap, and turn the red one; I do not INSIST on opening the left one,
risking to get cold water...

> > I've seen one too many instances of " crashes on Debian" that
> turned
> > out to be " is a libc5 binary with an RPATH of /usr/X11R6/lib"
> which on
> > any reasonably up to date Debian system contains libc6 X libraries.
> 
> See?  You replaced one library with an incompatible one without
> modifying its version number to mark it as incompatible.  Isn't this
> breaking the contract?  How could you expect it to work?
> 
Moving the library was just fulfilling the 2nd part of the contract:
"You will find here the prefered library to use for THIS and THAT".

> > The X example also shows that the problem isn't limited to /usr/lib
> either.
> > What's next? /usr/local/lib/libc6 ?
> 
> Maybe some library versioning mechanism that allows incompatible
> changes to be marked as such.  Maybe an environment variable or some
> file in /etc containing a number that will be added to the major
> version number of any library libtool creates, so that they will be
> marked as incompatible.
> 
Under Linux at least the incompatibilities we are talking here ARE
managed by the dynamic linker, IFF we do not trick it saying him (using
-rpath) "Do not be smart, just load the library from there". YOU are
breaking the Linux contract...

It's possible the way you are using -rpath correspond to the "contract"
of some OSes, but surely not LINUX :-(; and if there is different
contracts to be adhered to depending on the OS, it seems that exaactly
why we use autoconf/automake/libtool: allow us NOT to bother about OS
diferences but rather be able to ask libtool: "Do what teh OS expect you
to do to fulfill its contracts"

So my opinion, at least on Linux, would be not to use -rpath, except if
we need to access shared libraries that WE install together with the
executables; and then install it in some package-dependant directory
where we have no risk to get ANY other lib, pass ONLY this dir to the
exec using -rpath, and then all should be OK.

Now for the one that want to compile and install a set of interdependant
packages in it's home directory on some OS where he is not able to pass
some kind of an LD_LIBRARY_PATH to the exec, then it may use some option
to each compiles asking that -rpath be passed for all links, and warn
him he should not try to

Back to the logo license (semi-formal proposal)

[Chris Waters]

We have free software guidelines, we have a logo.  There may be room for
improvement in both, but we do have them.  What we lack is a license for
the logo.  This may be a minor issue, but I believe that it's rather
critical right now.

It has been suggested that we trademark the logo.  This is a good idea,
however, it requires time, money, and paperwork.  Plus, if we want to
change the logo later, we'll need to spend *more* time and money to get
a new trademark for the new logo.  Thus, I propose that we instead use
the following license, which can be applied to any of our logos:

   DEBIAN LOGO LICENSE

   The Debian logo may be used AS IF it were a trademark of the
   Debian Project.  It may be used freely within any software
   that is included in a Debian system.  Outside of the Debian
   project, it may be used to refer to the Debian project.

Short, sweet, and to the point.  Feedback welcomed.  Seconds welcomed.

I would really like to see if we can avoid drowning in legalese for
once.  :-)

cheers
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.

Re: PLEASE remember to vote!

[Joseph Carter]

> Sorry for my ignorance when deleting the mails under this topic.  I
> was absend from the net for a longer time and couldn't read all my
> E-Mails.  Please repeate the link where to vote for those like me
> who ignored the mails.  I couldn't find a site to vote.

Instructions are found at http://vote.debian.org, just follow the links
from elections and whatnot, it'll tell you how to request a ballot and
how to sign it with PGP and stuff..

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

RE: -rpath with libtool and Debian Linux

[Bernard Dautrevaux]

> -Message d'origine-
> De:   Alexandre Oliva [SMTP:[EMAIL PROTECTED]
> Date: mercredi 27 janvier 1999 22:23
> À:Jules Bean
> Cc:   J.H.M. Dassen; debian-devel@lists.debian.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Objet:Re: -rpath with libtool and Debian Linux
> 
> On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote:
> 
> > On 27 Jan 1999, Alexandre Oliva wrote:
> 


> > We even support separate versions of software, to some extent,
> although
> > I'd agree completely that our support in this area is not what it
> might
> > be.
> 
> And that's the very reason why I've never been able to adopt any of
> the available packaging systems: the only way to keep multiple
> working versions is to use a separate directory for each version of
> each package.
> 
Good point. I'm not either using any "standard" packaging system like
rpm or deb, just due to this. I use a (quite primitive :-)) homegrown
packaging system taht allows my users to install each realease in a
different location, anywhere they want on their disk. Period. (I think
difficult to be more opened...) 

My problem is that if in my package I create a shared library that will
be used by the exec in this package, and I use libtool for this, then
the use of -rpath for this cause the user to have to install exactly
where I build it (that is in some highly non-standard place due to our
complex development environment), or else the -rpath will point in some
unexistent place and (as Linux will ignore LD_LIBRARY_PATH) I can't
override it...

Not to talk about having to cope with you, Linux packagers, moving
system libraries from release to release :-) But I'm confident your
tools are coherent and that if you move libraries, your linker will find
them in the proper place.

So I think -rpath may be useful INSIDE packages, IFF we use relative
pathnames (that \$ORIGIN I saw in a message yesterday I think), but
should only be used for standard libraries if the OS distributor advised
us to, and NOT USED IF THE CONTRACT I PROPOSE US say NOT TO USE IT!

The purpose of libtool is to help us build portable code, whose built
rules are adapted to the build platform, isn't-it :-), so let's do it:
if Linux distribution maintainers advise us not to use -rpath on their
distribution, we must trust them (and blame them if the solution they
recommend do not work 8-(, but then THEY have to correct their
implementation! :-))

> >> How does the current packaging system allows me to test one version
> of
> >> a package while other users of the same host are running a stable
> >> version of that tool?  Or are the GNU/Linux distributions all
> moving
> >> towards the Micro$oft model of single-user workstations?
> 
> > Of course not ;-)
> 
> Jeez!, I was sure I had added a smiley after that last sentence.
> Sorry about that...
> 
> > If you want to test one version, you simply run it with
> 
> > ./configure --prefix /home/me/nicepackage
> 
> But isn't this exactly what the packaging systems are trying to avoid,
> i.e., that people have to compile systems on their own?  And then, how
> could I make sure that my test build works exactly as the pre-compiled
> 
> upgrade, so that I could use the packaging system for the update?
> 
> 
> This is something that I feel that should be taken care of by the
> existing GNU/Linux distributions.  In fact, I've got a bunch of ideas
> that I'll probably never find time to implement :-( about how to
> maintain multiple versions of packages installed and allowing each
> user to select which version he wants to use, either by explicit
> version number or by tags such as `stable', `test', `old', etc, tags
> that are determined by the system manager when he installs the
> package.
> 
I think this is slightly off topic, or we may have to start a whole new
mailing list to discuss packaging systems (I don't know but I'm quite
sure there exist mailing lists or newsgroups on RPM, DEB, etc. :-)) Here
we are talking about how libtool could help isolate us from the
peculiarities of different OSes, and I think this is enough work :-)

Regards,

Bernard


--
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:+33 (0) 1 47 68 80 80
Fax:+33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]

--

Call for mascot! :-)

[Chris Waters]

While I'm on the topic of the logo, it occurred to me that it might be
nice to choose a mascot for the Debian project.  Some sort of beast that
we can use in the logo and in other Debian-related images.  Much as
Linux has its penguin, BSD has its devil, and GNU has its, erm, gnu. 
Debian should have its own mascot, IMO, separate from any of these.

This is just an idea, and I won't be offended if it's rejected.

Anyway, I just thought that if we picked a mascot, then we could mention
it in the rules for the proposed GIMP contest for a new Debian logo.

I brought this up on IRC, and got the following suggestions:

1.  Dragon (well-liked choice on IRC)
2.  Octopus (my own suggestion)
3.  Monkey
4.  Ant
5.  Bee

Personally, I think octopi are really cute, they're smart (for
invertebrae), and I kind of like the symbolism of many arms working
together as part of a whole, but perhaps I'm a little crazy.  :-)
-- 
Chris Waters   [EMAIL PROTECTED] | I have a truly elegant proof of the
  or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.

Re: Call for mascot! :-)

[Anderson MacKay]

On Thu, 28 Jan 1999, Chris Waters wrote:
> 1.  Dragon (well-liked choice on IRC)
> 2.  Octopus (my own suggestion)
> 3.  Monkey
> 4.  Ant
> 5.  Bee

Ants and Bees are probably the easiest to do cool 3d raytracings with, if
that's any thing.  I'd have to take ants.  Lots of little creatures doing
their own thing, but cooperatively building something really cool as a
result. Hmmm, that sounds familiar. :)

Andy

Re: Call for mascot! :-)

[M.C. Vernon]

> 1.  Dragon (well-liked choice on IRC)
Cool. As long as it's a decent dragon
> 2.  Octopus (my own suggestion)
OK
> 3.  Monkey
No
> 4.  Ant
no
> 5.  Bee
no

:)

Matthew

-- 
Elen sila lumenn' omentielvo

[EMAIL PROTECTED],
Steward of the Cambridge Tolkien Society
Selwyn College Computer Support
http://www.cam.ac.uk/CambUniv/Societies/tolkien/
http://pick.sel.cam.ac.uk/

Re: Call for mascot! :-)

[David Welton]

On Thu, Jan 28, 1999 at 10:14:15AM -0800, Chris Waters wrote:

> This is just an idea, and I won't be offended if it's rejected.

I kind of like it...

> I brought this up on IRC, and got the following suggestions:

With 400 some odd developers, there are likely to be just about as
many proposals...  Maybe we should take this debate to
debian-publicity.  Infact, I have a feeling that the logo debate
should probably migrate there, as well.

Ciao,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Call for mascot! :-)

[servis]

*- On 28 Jan, Chris Waters wrote about "Call for mascot!  :-)"

> 2.  Octopus (my own suggestion)

I like this.  It would be great for CD covers were each tentacle could
have text overlayed for each architecture: i386, arm, hurd, sparc,
alpha, m68k, powerpc.  Well that is seven but there may be more later
or some other text could go over it.

-- 
Brian 
-
"Never criticize anybody until you have walked a mile in their shoes,  
 because by that time you will be a mile away and have their shoes." 
   - unknown  

Mechanical Engineering[EMAIL PROTECTED]
Purdue University   http://www.ecn.purdue.edu/~servis
-

Re: Intent to package manpages-fi

[Fabrizio Polacco]

Teemu Hukkanen wrote:
> 
> from the README:
> ->8-clip->8-
> This package contains a first, fixed release of Linux man pages in Finnish.
> 
> There are 132 pages from sections 1 and 6.
> 
> If you want to contribute, point your browser to
> www.redhat.sot.com/Man-pages-fi.shtml
> 
> Copyrights: These man pages are under GPL.
> ->8-clip->8-
> 
> upstream package at
> 
> only as .rpm. I'm still trying to get them to distribute also as something
> else than .rpm


Please, pay attention that on redhat some programs are different from
those on debian.
For example, debian has man-db instead of man, so the manpages for man,
whatis, apropos, makewhatis shouldn't go into debian.
Instead the man-db program installs all its translations (manpages and
messages), so you should get its source and translate them.

thank you.

fab

Re: voting instructions on the web [was: PLEASE remember to vote

[Darren Benham]

On 28-Jan-99 Kevin Dalley wrote:
>> Well, it's on http://vote.debian.org, which is fairly obvious.
>> 
> 
> No, it actually isn't obvious, any more than www.debian.org/election
> is obvious.  A link from the Debian home page, or the developers page,
> to vote.debian.org seems like a good idea.
check http://www.debian.org/devel/ (that's the developer section that you'd get
to if you clicked on it from the main page).  I think it's in the first column
first few lines down.

> By the way, http://www.vote.debian.org, under current events, states
> that nominations for project leader are open.  Perhaps this should be
> changed to state that elections are in progress and almost over.
You're right. 


-- 
Please cc all mailing list replies to me, also.
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=


pgpSARLAmZiQw.pgp
Description: PGP signature

Re: [Fwd: [Jikes-License] Jikes Parser Generator now available in source form]

[Marco d'Itri]

On Jan 27, Mike Goldman <[EMAIL PROTECTED]> wrote:
 >For license-fans: It uses a license based on the revised Jikes license,
 >i.e., it's the new Jikes license with 'Compiler' changed to 'Parser
 >Generator'.  The termination clause now uses the same language as the
 >SecureMailer license (also available from alphaworks).
Then it's still not free:

In the event an intellectual property claim is made or appears likely
to be made with respect to the Software, you agree to permit IBM to
enable you to continue to use the Software, or to modify it, or replace
it with software that is at least functionally equivalent.  If IBM
determines that none of these alternatives is reasonably available, you
agree, at IBM's request, upon notice to you, to discontinue further
distribution of the Software and to delete or destroy all copies of the
Software you possess.  This is IBM's entire obligation to you regarding
any claim of infringement.

-- 
ciao,
Marco

Re: Call for mascot! :-)

[Ruud de Rooij]

On 1999/01/28, Anderson MacKay wrote:
> On Thu, 28 Jan 1999, Chris Waters wrote:
> > 1.  Dragon (well-liked choice on IRC)
> > 2.  Octopus (my own suggestion)
> > 3.  Monkey
> > 4.  Ant
> > 5.  Bee
> 
> Ants and Bees are probably the easiest to do cool 3d raytracings with, if
> that's any thing.  I'd have to take ants.  Lots of little creatures doing
> their own thing, but cooperatively building something really cool as a
> result. Hmmm, that sounds familiar. :)

In that case, we should name our releases after characters from
"a Bug's Life" :-)

- Ruud de Rooij.

-- 
Ruud de Rooij
[EMAIL PROTECTED]
http://sepc.twi.tudelft.nl/~derooij/

RE: Call for mascot! :-)

[Darren Benham]

On 28-Jan-99 Chris Waters wrote:
> While I'm on the topic of the logo, it occurred to me that it might be
> nice to choose a mascot for the Debian project.  Some sort of beast that
> we can use in the logo and in other Debian-related images.  Much as
> Linux has its penguin, BSD has its devil, and GNU has its, erm, gnu. 
> Debian should have its own mascot, IMO, separate from any of these.
> 
> This is just an idea, and I won't be offended if it's rejected.
> 
> Anyway, I just thought that if we picked a mascot, then we could mention
> it in the rules for the proposed GIMP contest for a new Debian logo.
> 
> I brought this up on IRC, and got the following suggestions:
> 
> 1.  Dragon (well-liked choice on IRC)
> 2.  Octopus (my own suggestion)
> 3.  Monkey
> 4.  Ant
> 5.  Bee
> 
> Personally, I think octopi are really cute, they're smart (for
> invertebrae), and I kind of like the symbolism of many arms working
> together as part of a whole, but perhaps I'm a little crazy.  :-)

If we go with one, I'd go for 2,1 or 5 in that order.  I *hate* Monkey's and I
step on ants.  Bee seems a little... well.. not in the spirit but I could live
with it.

-- 
Please cc all mailing list replies to me, also.
=
* http://benham.net/index.html <><  *
*  * -BEGIN GEEK CODE BLOCK- ---*
*Darren Benham * Version: 3.1   *
*  <[EMAIL PROTECTED]>  * GCS d+(-) s:+ a29 C++$ UL++> P+++$ L++>*
*   KC7YAQ * E? W+++$ N+(-) o? K- w+++$(--) O M-- V- PS--   *
*   Debian Developer   * PE++ Y++ PGP++ t+ 5 X R+ !tv b DI+++ D++   *
*  <[EMAIL PROTECTED]>  * G++>G+++ e h+ r* y+*
*  * --END GEEK CODE BLOCK-- ---*
=


pgpDIJqmOwm1E.pgp
Description: PGP signature

Re: Hardcore baby!!! Yeah!!!!

[Oscar Levi]

On Wed, Jan 27, 1999 at 01:10:46AM -0800, Joseph Carter wrote:
> On Tue, Jan 26, 1999 at 10:45:57PM -0600, [EMAIL PROTECTED] wrote:
> [ pathetic attempt at sex spam snipped ]
> 
> Can we PLEASE enforce our spam policy and make these people pay for their
> crimes against humanity?
> 
> -- 
> "I'm working in the dark here."  "Yeah well rumor has it you do your best
> work in the dark."
>-- Earth: Final Conflict

There is something missing from the header.  I'd guess that qmail is
supressing it.  Usually, we can see the name (IP) of the sending host
in the headers.

Re: Call for mascot! :-)

[Jaldhar H. Vyas]

On Thu, 28 Jan 1999, Chris Waters wrote:

> 2.  Octopus (my own suggestion)

How about Cthulhu?  That would also tie into Linuxes world domination
theme. :-)

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Re: Call for mascot! :-)

[Joseph Carter]

On Thu, Jan 28, 1999 at 10:14:15AM -0800, Chris Waters wrote:
> 1.  Dragon (well-liked choice on IRC)

Why not a phoenix?

/me poses for gimp artists being that he'd make a cute mascott...  =>


(that was supposed to be funny, why aren't you laughing?)

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

Re: Call for mascot! :-)

[Joseph Carter]

On Thu, Jan 28, 1999 at 02:38:49PM -0500, Jaldhar H. Vyas wrote:
> > 2.  Octopus (my own suggestion)
> 
> How about Cthulhu?  That would also tie into Linuxes world domination
> theme. :-)

Nah, that's the NT logo...

"Win95 or WinNT?  Why settle for the lesser of two evils when you can pay
twice as much for half as much stability!?"

-- 
"I'm working in the dark here."  "Yeah well rumor has it you do your best
work in the dark."
   -- Earth: Final Conflict

Intent to package : xmem

[David Welton]

I think it's kind of silly that we no have this more or less
'elementary' X package, so I'm offering to package it.  Is it
generated from the X sources (in which case, maybe I'll just limit
myself to pestering Branden:-), or proc, or is it its own thing?

Thanks,
-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Intent to package : xmem

[David Welton]

On Thu, Jan 28, 1999 at 02:01:09PM -0600, David Welton wrote:

> I think it's kind of silly that we no have this more or less
   ^ longer

Sorry...:-/

-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Call for mascot! :-)

[Amos Shapira]

On Thu, January 28 1999, Anderson MacKay <[EMAIL PROTECTED]> wrote:
|On Thu, 28 Jan 1999, Chris Waters wrote:
|> 1.  Dragon (well-liked choice on IRC)
|> 2.  Octopus (my own suggestion)
|> 3.  Monkey
|> 4.  Ant
|> 5.  Bee
|
|that's any thing.  I'd have to take ants.  Lots of little creatures doing
|their own thing, but cooperatively building something really cool as a
|result. Hmmm, that sounds familiar. :)

I'd second that (especially after watching Antz :).

--Amos

--Amos Shapira| "Of course Australia was marked for
133 Shlomo Ben-Yosef st.  |  glory, for its people had been chosen
Jerusalem 93 805  |  by the finest judges in England."
ISRAEL[EMAIL PROTECTED] | -- Anonymous

Re: Call for mascot! :-)

[Joey Hess]

Edward John M. Brocklesby wrote:
> > 1.  Dragon (well-liked choice on IRC)
> 
> Obviously a dragon is the best choice.
> 
> > 2.  Octopus (my own suggestion)
> 
> Too complex.

Er, less complex than a _dragon_! Anyone can draw a recognizable octopus,
drawing a decent dragon takes some talent.

-- 
see shy jo, in favor of octopus

Re: Hardcore baby!!! Yeah!!!!

[Alexander Koch]

On Thu, 28 January 1999 11:33:46 -0800, Oscar Levi wrote:
> > [ pathetic attempt at sex spam snipped ]
> > Can we PLEASE enforce our spam policy and make these people pay for their
> > crimes against humanity?
[..]
> There is something missing from the header.  I'd guess that qmail is
> supressing it.  Usually, we can see the name (IP) of the sending host
> in the headers.

It is being cut from the mails before being sent out.
It is on murphy "somewhere" and I simply lack the time
to even read the debian lists at all right now (I am
down to ~ 3k mails unread from about 9k yesterday).

This will change in the near future (moving is no fun).

Alexander,
1/3 of [EMAIL PROTECTED]

-- 
Heute nacht war mir fuenf Minuten langweilig... -- Gabriel Krabbe
Alexander Koch - <>< - aka Efraim - PGP - 0xE7694969 - Hannover - Germany

The Debian Logo-team

[Wichert Akkerman]

After getting a few volunteers and asking a few other people I present
to you the Debian logo-team, who will select the best logos for your
voting pleasure:

  * Wichert Akkerman <[EMAIL PROTECTED]>
  * Teemu Hukkanen <[EMAIL PROTECTED]>
  * Nils Lohner <[EMAIL PROTECTED]>
  * James Treacy <[EMAIL PROTECTED]>
  * M. Vernon <[EMAIL PROTECTED]>
  
Besides our own personal taste we will use the following criteria to
select the best logos:
* easily recognizable
* must look good in black & white
* must be scalable
* not too detailed so it works in low resolution
* works both with and without text at the bottom (can be ignore if the
  text `Debian' is part of the logo)

Of course an important item is: what exactly constitutes a logo? Bruce
Perens gave the following description of a logo once (Nov 1997):

  I think it's important to look at a logo for a very short time without any
  prejudice (less than 1/2 second), and then think to yourself "what did I
  see?". The immediate answer should be "the debian logo". It should not be
  confused with anything else like two letters, the "Tux" the penguin, etc.

Wichert.


-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpxDZ6mi7qdv.pgp
Description: PGP signature

Re: Call for mascot! :-)

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 28 Jan 1999 21:04:05 +, Edward John M. Brocklesby wrote:

>Yeah, but I mean Octopi are really weird, and you never see them around
>anywhere, so some people might not recognise them. Whereas with dragons, you
>see them all the time, so they are easily recognisable.

>I mean, how often do you see an Octopus flying across the sky?

I can honestly say that I'm more likely to see an octopus fly across the
sky than a dragon.

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBNrDSknpf7K2LbpnFEQJYSgCgslrQ+X8WV5mfN61WLusdtIAsmOoAoKCA
LdoGOKMz6BGDL+7hPmUpjfQd
=lJYb
-END PGP SIGNATURE-

Packages I am orphaning.

[Joel Klecker]

I am now orphaning[0] or previously orphaned the following:
knl - This is a fairly nice replacement for rdev and friends
the package is bug-free and lintian-clean
vgrind - Run-off preprocessor for program sources
One lintian warning
Our vgrind is out of date with regard to upstream
(Net|Free|Open)BSD, it should probably be upgraded.
pciutils - Utils for listing/tweaking PCI devices in 2.1/2.2 kernels
Bug-free, lintian-clean
There are some upstream alpha releases that would be nice to
have packaged somewhere, but not essential
zile - A small editor that tries to be emacs-like
One bug, lintian-clean
macutils - Utils for dealing with specially encoded Mac OS files
		Three bugs, none of which are really fixable (they 
are about the
		inability to deal with some proprietary archive formats)
		Lintian-clean

Tarballs of my current devel tree for all of these are at: 


[0] However, WNPP may consider knl and pciutils as "Packages you need 
a new maintainer for"
--
Joel Klecker (aka Espy) http://web.espy.org/>
mailto:[EMAIL PROTECTED]>  mailto:[EMAIL PROTECTED]>
Debian GNU/Linux PowerPC -- http://www.debian.org/ports/powerpc/>

mirror problems with ftp.debian.org

[Dale Scheetz]

I had my mirror fail today with the following message:

package=source ftp.debian.org:/debian/dists/slink/main/source ->
/mnt/c/4/debian/dists/slink/main/source
Cannot get remote directory listing because: 200 Type set to A.
Cannot get remote directory details (/debian/dists/slink/main/source)

The binary-i386, and binary-all parts work just fine. It is only when the
source section (package) runs that I get this error.

I can ftp in with mc and get dirctory listings just fine.

Anyone have any idea what the problem is?

Thanks,

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

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

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

Re: Call for mascot! :-)

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 28 Jan 1999 21:28:29 +, Edward John M. Brocklesby wrote:

>> >I mean, how often do you see an Octopus flying across the sky?

>> I can honestly say that I'm more likely to see an octopus fly across the
>> sky than a dragon.

>I don't think so - Octopi can't fly! (Unless they flap their arms (legs?)
>really hard, and then they'd run out of energy and die from falling :)

Octopi are real, dragons are mytical.  I am more apt to see something
real flying through the air, no matter how improbable, than something
mythical, which I cannot ever see at all.

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBNrDYHHpf7K2LbpnFEQJQMwCfazNK3wmq2K0+Qyov2hR57mMYAtQAoK3j
H5GXprM8f8jq0nSNj9DKtAY+
=xc/A
-END PGP SIGNATURE-

Re: Call for mascot! :-)

[David Welton]

On Thu, Jan 28, 1999 at 09:28:29PM +, Edward John M. Brocklesby wrote:

> > >I mean, how often do you see an Octopus flying across the sky?
> > 
> > I can honestly say that I'm more likely to see an octopus fly across the
> > sky than a dragon.
 
> I don't think so - Octopi can't fly! (Unless they flap their arms (legs?)
> really hard, and then they'd run out of energy and die from falling :)

Sigh.. ok, so I guess it's too late, and we spam -devel with this
stuff.  Did you people not read my request to move this to -publicity?
Personally, I like talking about these things, but I imagine that, as
is the case with all the junk on -legal, there are people who really
don't care at all, and don't really want to read about it.

In any case.. Penguins don't fly either, even though they are birds,
and 'should' fly!  And that doesn't stop us from loving them;-)
Although, personally, I think the BSD demon is way cooler than the
penguin...

-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Call for mascot! :-)

[Joey Hess]

Steve Lamb wrote:
> Octopi are real, dragons are mytical.  I am more apt to see something
> real flying through the air, no matter how improbable, than something
> mythical, which I cannot ever see at all.

Well I for one have seen dragons fly. (Dragon kites, that is.)

-- 
see shy jo

Re: Call for mascot! :-)

[Steve Lamb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 28 Jan 1999 13:44:20 -0800, Joey Hess wrote:

>Well I for one have seen dragons fly. (Dragon kites, that is.)

Ah, but that is not a dragon, is it?  And the picture on that "dragon"
kite could be a octopus making it, then, an octopus kite?  ;)

- -- 
 Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
 ICQ: 5107343  | main connection to the switchboard of souls.
- ---+-
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc

iQA/AwUBNrDd8npf7K2LbpnFEQJI8gCghAAEeryiLYnElymSsWTK7JA0+5EAoIC4
KaEmRr/LypJAQpQl6aUGTIQf
=Cce5
-END PGP SIGNATURE-

Re: [Re: Call for mascot! :-)]

[John Travers]

>On Thu, 28 Jan 1999, Chris Waters wrote:
>> 1.  Dragon (well-liked choice on IRC)
>> 2.  Octopus (my own suggestion)
>> 3.  Monkey
>> 4.  Ant
>> 5.  Bee

>Ants and Bees are probably the easiest to do cool 3d raytracings with, if
>that's any thing.  I'd have to take ants.  Lots of little creatures doing
>their own thing, but cooperatively building something really cool as a
>result. Hmmm, that sounds familiar. :)

>Andy

I would definately have to agree. Ants (like in the film Antz) look really
cool. They work together, co-operate and produce super human (or super ant)
achivements.
Octopi are silly and unrelated, dragons are just meaningless symbols that
could look really good or bad. Ants (or bees) have something really catchy
about them.

travs




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



More than just email--Get your FREE Netscape WebMail account today at 
http://home.netscape.com/netcenter/mail

Re: Call for mascot! :-)

[James Troup]

"Edward John M. Brocklesby" <[EMAIL PROTECTED]> writes:

> I don't think so - Octopi can't fly!

Someone who obviously hasn't read RFC 1925...

-- 
James
"Never trust trucks"

Re: libtool & rpath

[James Troup]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> On Wed, Jan 27, 1999 at 08:29:42PM +, James Troup wrote:
> > Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > 
> > > +case ${host} in
> > > +  *-pc-linux-gnu)
> >^^
> > 
> > s/pc/*/ (pc==non-i386 unfriendly)
> 
> Good point. However, /usr/doc/lintian/libtool-workarounds.txt suggestions
> the above [ ... ]

It was fixed in 0.9.5.

-- 
James
"Never trust trucks"

Re: Call for mascot! :-)

[Martin Bialasinski]

>> "SL" == Steve Lamb <[EMAIL PROTECTED]> writes:

SL> On Thu, 28 Jan 1999 21:28:29 +, Edward John M. Brocklesby wrote:

SL> Octopi are real, dragons are mytical.  I am more apt to see
SL> something real flying through the air, no matter how improbable,
SL> than something mythical, which I cannot ever see at all.

Hmm, with a strong enough improbability field, you will see dragons in 
the sky.

You can also plase kysh on a catapult to see a flying dragon :-)

Ciao,
Martin

Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86

[Steve Dunham]

Note to Def


Branden Robinson <[EMAIL PROTECTED]> writes:

> This is what I hope to be the final test build of XFree86 3.3.2.3a-9; if
> there are no significant problems it will be released with that version
> number.  This test build addresses all four release-critical bugs currently
> outstanding against XFree86.

> There are exactly 5 things I want to do for -10, and then I will declare
> slink X done (barring any nasty bugs that crop up).

> * have XF86Setup mung /etc/X11/Xserver (and call correct X server during
>   test)
> * deal with new font and static library packages in the upgrade department
> * XKB and locale fixes for our non-American friends
>   (bugs.debian.org/xlib6g)
> * merge alpha patches
> * merge sparc patches

My sparc patches or the older ones that Anders sent you?

> Alpha and sparc patches need to be i386-safe.  I don't know that they
> aren't; I haven't checked closely yet.  My next test build will likely
> incorporate the alpha patches and I will want to see if it works okay on
> i386.  Almost all of the Alpha patches have to do with 64-bit alignment
> issues, and should not affect the i386.  But there's always the chance of
> something lurking...

> If some sparc folks could confirm that their patches are similarly safe for
> i386 consumption I'll subsequently add those.  I imagine the Alpha patches
> will make life easier for the sparc64/UltraLinux port (do we have one
> yet?).

The patches that I sent you should be completely safe. But the
resulting packages have only been tested by me.  (As I said, I took
out the -pedantic flag on the altdev stuff - the other changes don't
touch x86 at all.)

BTW, There are two kinds of sparc64 support: usermode and kernel mode.
Usermode stuff is a _long_ way off, currently Debian runs 32-bit sparc
stuff on a 64-bit kernel.  So Alpha patches don't help much there.
The biggest issue on the 32-bit sparc is unaligned memory accesses.


I don't really want to step on any feet here, but it would be nice if
we could get the X source for Sparc into slink - and get the
UltraSparc support in there.  (Eric plans on making the install work,
so X support would be an added bonus.)

Nontheless, the current sparc binaries are a built by Anders from a
seperate tree.  (Anders - my tree was made by merging the latest
UltraPenguin patches - a superset of the Red Hat patches - into
Branden's tree.)  I would want some other sparc people to double check
my packages, before we actually include binary packages from my code
into slink.


If Anders has a tree that matches Branden's recent trees, I'll defer
to him (but ask that either he or I merge in the Mach64 and Creator
patches), otherwise, I'd like to the goahead from Anders et al to use
my stuff in slink (after appropriate testing).  It shouldn't matter
too much (as long as the binaries work), since I believe Anders is
planning on starting from scratch on the 3.3.3.x releases.


What do the other Debian Sparc people think?  Should we update the X
binaries in slink so that we are shipping source code and have
UltraSparc support?

(I'm 99% sure the binaries work, the only issues would be install
script &c, and they are mostly copied from the current binary
packages.  Also, I have to add a hard-coded XF86Config to the Sparc
Mach64 package - because XF86Setup doesn't work yet on the sparc
machines.)


Steve
[EMAIL PROTECTED]

Re: Call for mascot! :-) -- flying pigs

[Avery Pennarun]

On Thu, Jan 28, 1999 at 01:35:24PM -0800, Steve Lamb wrote:

> >> >I mean, how often do you see an Octopus flying across the sky?
> 
> >> I can honestly say that I'm more likely to see an octopus fly across
> >> the sky than a dragon.
> 
> >I don't think so - Octopi can't fly! (Unless they flap their arms (legs?)
> >really hard, and then they'd run out of energy and die from falling :)
> 
> Octopi are real, dragons are mytical.  I am more apt to see something
> real flying through the air, no matter how improbable, than something
> mythical, which I cannot ever see at all.

For that matter, how about a flying pig?  Then at least outsiders will get
the joke.

You know, a slightly lean, brightly smiling, winged angel-pig with what
might or might not be a curly tail.

Hey, he could have a cape, like Super Pig.

Think about it, you'll learn to love it.

The key here is "cute."  People don't want an ugly chicken-like creature
that is clearly ready to attack at the slightest provocation.

Octopi and ants may also be good, if they have wings.

Have fun,

Avery

Re: Intent to package wterm

[Anthony Wong]

On Thu, Jan 28, 1999 at 12:00:43PM -0500, Brian Mays wrote:
|> Adam Klein wrote:
|
|>> Oh, fro the rxvt package?  hmm.  Do I need to incorporate those?
|
|Marcelo E. Magallon wrote:
|
|> Well, they are there for a reason, aren't they?
|
|Some of the patches will not need to be added, unless you are also
|planning to make a Kanji, Greek, or Chinese version of wterm.
|
|Brian

Well, if the patching is not much a hassle, then I suggest those
patches should be applied too as long as the binary size doesn't
increase very much. I hate to see so many localized versions of
the same program floating around. Users will find it confusing.
The ftp server will carry fewer packages too (1 internationalized
version instead of several localized ones).

-- 
Regards,  [ E-mail: [EMAIL PROTECTED] / ICQ UIN: C30E6 ]
Anthony.  [ http://icqtrack.hk.st -- Track your ICQ friend ]

Re: Call for mascot! :-) -- flying pigs

[David Welton]

On Thu, Jan 28, 1999 at 06:14:17PM -0500, Avery Pennarun wrote:

> Octopi and ants may also be good, if they have wings.

Ants with wings would look like termites.  Ick...

-- 
David Welton  http://www.efn.org/~davidw 

Debian GNU/Linux - www.debian.org

Re: Call for mascot! :-)

[John Hasler]

Steve Lamb writes:
> Octopi are real, dragons are mytical.  I am more apt to see something
> real flying through the air, no matter how improbable, than something
> mythical, which I cannot ever see at all.

Mere nonexistence is a feeble excuse for declaring a thing unseeable.
You *can* see dragons.  You just have to look in the right direction.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Call for mascot! :-) -- flying pigs

[Anderson MacKay]

On Thu, 28 Jan 1999, Avery Pennarun wrote:
> For that matter, how about a flying pig?  Then at least outsiders will get
> the joke.

If we're going for flying barnyard animals, I really have to go with
flying cows.  I mean, I'm sure this is horribly english-language-centric
:), but you've got great material both from Python's _Holy_Grail_ and Gary
Larson's _The_Far_Side_.

> The key here is "cute."  People don't want an ugly chicken-like creature
> that is clearly ready to attack at the slightest provocation.

And furthermore, even if it -was- to attack, it really wouldn't do
anything.  Linus -was- able to give a convincing, -somewhat- alarming
description of an angry penguin and why you wouldn't want to mess with
him, but really ... chicken?  If it was a rooster, maybe it'd be a little
intimidating.  That's the great thing about the FreeBSD guy ... he looks
nice and all, but he's still got that spear-thing.

> Octopi and ants may also be good, if they have wings.

Octopi with wings?  Now -that- is a confusing bunch of appendages, if you
ask me. =)

Andy