Re: GPG as a PGP replacement

[Steve Haslam]

On Thu, May 13, 1999 at 05:19:44PM -0600, Jason Gunthorpe wrote:
> > (I did "gpg --no-options --load-extension rsa --load-extension idea \
> > --clearsign -u 0x6494661D --secret-keyring ~/.pgp/secring.pgp \
> > < testfile > testfile.out")
> 
> Try using cat, gpg may try to use fstat to get the file size..

Still works; the only difference between testfile and the result of
running testfile-out through pgp2 is that pgp doesn't write a
terminating newline...

SRH
-- 
Steve Haslam   Debian GNU/Linux   [EMAIL PROTECTED]
gnome-libs, gnome-core, gnome-control-center, gdm, p3nfs.what, me worry?


pgpunScKhrnYE.pgp
Description: PGP signature

Re: GPG as a PGP replacement

[Jason Gunthorpe]

On Thu, 13 May 1999, Steve Haslam wrote:

> gpg --clearsign works, gpg --sign doesn't, seemingly. (ERROR: Nested
> data has unexpected format.  CTB=0xCB)
> 
> (I did "gpg --no-options --load-extension rsa --load-extension idea \
> --clearsign -u 0x6494661D --secret-keyring ~/.pgp/secring.pgp \
> < testfile > testfile.out")

Try using cat, gpg may try to use fstat to get the file size..

Jason

intent to package august

[Andrea Fanfani]

Hi all, i would like package august, a good html editor 
written in tcl/tk and released under gpl.

You can  find more information about august at:
http://www.lls.se/~johanb/august/

and contact the developer of this program at
[EMAIL PROTECTED]

please put Cc: [EMAIL PROTECTED] for any kind of answer
because the account where i'm subscribed to -devel is k.o.
(I'm sorry for the problem)

Best regards

Andrea Fanfani
-- 
Andrea Fanfani
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


pgp6lo6On6vih.pgp
Description: PGP signature

Re: jdk117v3 package?

[Sudhakar Chandrasekharan]

Vincent Murphy proclaimed:
>  a new version of jdk117 from blackdown (v3) has been released.  apparently,
> the problems with glibc2.1 have been resolved, though i haven't checked this
> out myself.
> 
>  is anybody working on packaging it?  can i help?

It is already in Incoming.

S.
-- 
"Son, this is the only time I'm ever going to say this.  It is not OK
 to lose."  -- Homer J. Simpson
Sudhakar C13n http://people.netscape.com/thaths/ Lead Indentured Slave

Re: Release Plans (1999-05-10)

[Adam Di Carlo]

Richard Braakman <[EMAIL PROTECTED]> writes:

> We have a long history of overly optimistic freeze dates :-)  I'd like
> to try something else this time.  I note, though, that if we do manage
> to freeze on July 1, we'll be able to have a release in time for the
> Linuxworld Expo in August.  That would be cool.

I'd like to point out that expecting freeze to be shorter than 10
weeks is lunacy.  We have 5 architectures now Consider that
archive changes at any point in freeze imply changes in boot floppies
(well, for anything in base) and in the CD system.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Release Plans (1999-05-10)

[Phillip R. Jaenke]

On Thu, 13 May 1999, Hartmut Koptein wrote:

> The OF of my LongTrail works perfectly but i don't know how to set it up for
> autobooting. Booting from floppy is not (yet) possible (for initrd) because
> the kernel cannot read the floppy. So net or cd booting are the only choices. 

assuming it's similar to openboot,

set boot-device disk
setenv autoboot true

are you getting any specific errors reading from floppy?
 
> Currently i wait for manoj's update for his kernel-package with my
> changes. After  that, compiling will be easier. But then i need
> kernel-diffs for apus, pmac, prep and also mbx for the 2.2.x tree.
> Which class is rs/6000, chrp or prep? 

no offense intended, but you'd probably be best holding off till i get my
images/source done for the rs/6000 against 2.2.6 or 2.2.8. 2.2.8 after
looking at the code, will *not* boot on any rs64 (i had 2.2.6 booting on
single rs64 in 32bit mode). the problem is in cort's code; it's simply not
rs64 ready. and barely 604e rs/6k ready. i will HOPEFULLY have this done
by the end of tomorrow. i broke gcc early last week, and finally got it
fixed today, so soon. very soon. 

as to chrp/prep, most are neither. s70's are chrp, but s70 advanced
servers don't appear to be. h70's are chrp as well. f50's i still haven't
figured out. *some* f40's are chrp. (only single cpu f40's from what i can
tell so far.)

what i really need is *physical* access to rs/6000's to tell. gotta get
into the openfirmware via aix to figure out what platform it is. and then
from there, it's generally very easy.

btw, i am working on smp support.. i have dual on f40 non-chrp, but single
on everything else still. give me a few months on that. ;)

-Phillip R. Jaenke, Head Unix Guru, Unicent Telecom
 216-344-2603 / 9a->~5p Eastern - PESTER ME!

Re: PROPOSAL: preparation for freezes, release coordination

[Drake Diedrich]

In linux.debian.devel, you wrote:
>
>I hope to fix this in the long run by having more frequent releases,
>so that maintainers are less anxious to get their packages in the
>upcoming release.  In the short term... let's just hope :-)
>

   How about creating woody at the freeze announcement instead of at
the actual freeze?   Then you could rail at new-package uploaders and
they'd have no excuses, plus we could compete to be the first
uploader..  It would also give the archive maintainers a chance to
spread out their workload: freeze would be independent of creating the
new distribution area.

-Drake

Re: Splitting debian-devel-changes to separate lists

[Joseph Carter]

On Thu, May 13, 1999 at 12:59:12PM +0200, Wichert Akkerman wrote:
> > The topic to split debian-devel-changes in a -$ARCH and -sources list was
> > proposed a while ago. What happened to it and what are the sentiments on
> > splitting it?? I think it's quite high volume because most lists aren't
> > intresting to me, but some are.
> 
> I've been told that if we used listar for that list we can let
> subscribers simply toggle flags for what they want to receive. That
> sounded like a perfect solution to me... in the meantime I'm using
> this procmail-recipe to filter out binary-only uploads:
> 
> :0
> * ^Subject:.*\((alpha|arm|powerpc|m68k|sparc)\)
> /dev/null


A slight mod:

:0
* ^Subject:.*\((alpha|arm|powerpc|m68k|sparc)\)
* !^Subject:.*source
/dev/null

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
* Simunye is so happy she has her mothers gene's
 you better give them back before she misses them!


pgpqJ42467fxf.pgp
Description: PGP signature

Re: GPG as a PGP replacement

[Steve Haslam]

On Thu, May 13, 1999 at 02:33:49PM -0600, Jason Gunthorpe wrote:
> 
> On Thu, 13 May 1999, Marco d'Itri wrote:
> 
> > AFAIK this is not needed. The only compatibility options I have in my
> > ~/.gnupg/options file are:
> 
> I was unable to make it work without the --rfc-1991 argument 

afaicr, you need --rfc-1991 to make encryption work, but not signatures.

> >  >Note: You cannot pipe input to gpg and get a PGP 2.x compatible sig.
> > I do that for it.* CFVs and I'm quite sure the signatures can be
> > verified with PGP 2.x.
> > If anyone cares I can provide my generic GPG.pm module for signing and
> > verifying.
> 
> Well, I tried many many times and went so far as to ask on the mailing
> list (was told it wouldn't work), never once was I able to make gpg create
> a signature that pgp 2.6 would accept using a pipe. You might want to
> double check that your sigs do work.. 

gpg --clearsign works, gpg --sign doesn't, seemingly. (ERROR: Nested
data has unexpected format.  CTB=0xCB)

(I did "gpg --no-options --load-extension rsa --load-extension idea \
--clearsign -u 0x6494661D --secret-keyring ~/.pgp/secring.pgp \
< testfile > testfile.out")

SRH
-- 
Steve Haslam   Debian GNU/Linux   [EMAIL PROTECTED]
gnome-libs, gnome-core, gnome-control-center, gdm, p3nfs.what, me worry?


pgpgbrybw4b7B.pgp
Description: PGP signature

Re: Splitting debian-devel-changes to separate lists

[Turbo Fredriksson]

> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:

Wichert> Previously Bart Warmerdam wrote:
>> The topic to split debian-devel-changes in a -$ARCH and
>> -sources list was proposed a while ago. What happened to it and
>> what are the sentiments on splitting it?? I think it's quite
>> high volume because most lists aren't intresting to me, but
>> some are.

Wichert> I've been told that if we used listar for that list we
Wichert> can let subscribers simply toggle flags for what they
Wichert> want to receive. That sounded like a perfect solution to
Wichert> me... in the meantime I'm using this procmail-recipe to
Wichert> filter out binary-only uploads:

And just if someone are using gnus, here's my split's...

- s n i p -
(setq gnus-auto-expirable-newsgroups "mail.sent.*\\|debian.changes"
  nnmail-split-methods 'nnmail-split-fancy
  
  ;; Aliases for the splitting...
  nnmail-split-abbrev-alist
  '((any . 
"[Ff]rom\\|[Tt]o\\|[Cc]c\\|sender\\|resent-to\\|resent-from\\|apparently-to\\|Delivered-To")
 
(from . "From\\|from")
(ToCc . "to\\|To\\|cc\\|Cc")
(ToCcReSentTo . "[Tt]o\\|[Cc]c\\|resent-to\\|Delivered-To")
(mail . "mailer-daemon\\|postmaster\\|MAILER-DAEMON")
(subj . "Subject")
(ml . "Mailing-List\\|X-From-Line\\|X-Mailing-List"))
  
  ;; The actual splitting...
  nnmail-split-fancy
  '(|
;; Debian stuff
(any "[EMAIL PROTECTED]"
 (|
  ;; Messages from the debian-private list...
  (ml "debian-private.*"
  (| (subj "Recently.*accepted.*maintainer.*" 
"debian.new-maints")
 "debian.private"))
  
  ;; Messages from the debian-changes OR debian-devel-changes 
mailinglist...
  (ml "debian-devel-changes.*\\|debian-changes"
  (| (subj "New Debian.*" "debian.changes-new")
 (subj "RETRACTING.*" "debian.changes-retract")
 (subj "Installed.*"  "debian.changes-installed")
 ;;
 (subj "Uploaded.*i386.*\\|Uploaded.*all.*"
   ;; Package uploads that we are specially intrested 
of...
   (| (subj 
"\\(.*util-linux.*\\|.*leafnode.*\\|.*roxen.*\\|.*gnudip.*\\|.*pike.*\\|.*chooser.*\\|.*vpnd.*\\)"
"debian.changes-watch")

  (subj 
"\\(.*mrouted.*\\|.*xipmsg.*\\|.*minfo.*\\|.*ipac.*\\|.*barcode.*\\|.*licq.*\\|.*dhis.*\\)"
"debian.changes-watch")

  (subj ".*dhcp.*"
"debian.dhcp")))
 ;;
 (subj ".*hurd-i386.*""debian.changes-hurd")
 (subj ".*m68k.*" "debian.changes-m68k")
 (subj ".*i386.*" "debian.changes-i386")
 (subj ".*sparc.*"
"debian.changes-sparc")
 (subj ".*arm.*"  "debian.changes-arm")
 (subj ".*alpha.*"
"debian.changes-alpha")
 (subj ".*powerpc.*"  
"debian.changes-powerpc")
 (subj "lintian"  "debian.lintian")
 "debian.changes"))

  ;; Messages from the debian-boot mailinglist...
  (ml "debian-boot"
  (| (subj "Debian Boot Floppies CVS:.*" "debian.boot-cvs")
  "debian.boot"))
  
  ;; Messages from the other debian lists...
  (ml "debian-mentors" "debian.mentors")
  (ml "debian-email" "debian.email")
  (ml "debian-admintool" "debian.admintool")
  (ml "debian-devel" "debian.devel")
  (ml "debian-maintainer" "debian.maintainer")
  (ml "debian-alpha" "debian.alpha")
  (ml "debian-devel-announce" "debian.announce")
  (ml "debian-announce" "debian.announce")
  (ml "debian-testing" "debian.testing")
  (ml "debian-68k" "debian.m68k")
  (ml "debian-arm" "debian.arm")
  (ml "debian-java" "debian.java")
  (ml "netwinder" "debian.netwinder")
  (ml "deity" "debian.deity")
  (ml "beowulf" "debian.beowulf")

  ;; Messages from the debian administrators etc...
  (from "maor-installer" "debian.installed")
  (ml   "maor-installer" "debian.installed")
  (from "owner" "debian.bugs")
  (ToCc "submit" "debian.bugs")
  (ToCc "security" "debian.bugs")
- s n i p -

-- 
We are GNU.  You will be GPL'ed.  Resistance is futile.
 / \ / \ / \ / \ / \ / \  Turbo Fredriksson <[EMAIL PROTECTED]>
( 

Re: Splitting debian-devel-changes to separate lists

[Wichert Akkerman]

Previously Bart Warmerdam wrote:
> The topic to split debian-devel-changes in a -$ARCH and -sources list was
> proposed a while ago. What happened to it and what are the sentiments on
> splitting it?? I think it's quite high volume because most lists aren't
> intresting to me, but some are.

I've been told that if we used listar for that list we can let
subscribers simply toggle flags for what they want to receive. That
sounded like a perfect solution to me... in the meantime I'm using
this procmail-recipe to filter out binary-only uploads:

:0
* ^Subject:.*\((alpha|arm|powerpc|m68k|sparc)\)
/dev/null

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/


pgpCZCQA0eGDh.pgp
Description: PGP signature

libmysqlclient in potato not work with php3-mysql-3.0.7-2

[Yifang Dai]

After I upgrade to mysql 3.22.20a-3 in potato, my php3 scripts connecting to 
mysql database stoped working. It complains with 

Fatal error: Call to unsupported or undefined function mysql_connect() 

After some investigation, I found out the php3-mysql module (mysql.so) is 
looking for libmysqlclient.so.4, while we have libmysqlclient.so.6 in the 
package now. 

Can someone update the package php3 and the modules please? Thanks.


-- 
---
Yifang Dai

Fax: (847)628-0255

Re: Haskell in Debian

[Giuliano P Procida]

On Thu, May 13, 1999 at 09:10:48PM +0100, Giuliano P Procida wrote:
> I've hit two problems so far:
> 
> a) happy is unhappy [1]
> b) ghc runs out of heap compiling its parser

Well, I spoke to soon. I have a compile failure with no error message:

../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O 
-split-objs -odir PrelBase  -H10m  -c PrelBase.lhs -o PrelBase.o -osuf o
make[3]: *** [PrelBase.o] Error 1

and that is as far as I get (make -k doesn't get much more done).

Giuliano.

Re: GPG as a PGP replacement

[Jason Gunthorpe]

On Thu, 13 May 1999, Marco d'Itri wrote:

>  >PGP 2.x compatible signatures can be generated using this command:
>  >  gpg --rfc-1991 -a --clearsign foo.txt

> AFAIK this is not needed. The only compatibility options I have in my
> ~/.gnupg/options file are:

I was unable to make it work without the --rfc-1991 argument 

>  >Note: You cannot pipe input to gpg and get a PGP 2.x compatible sig.
> I do that for it.* CFVs and I'm quite sure the signatures can be
> verified with PGP 2.x.
> If anyone cares I can provide my generic GPG.pm module for signing and
> verifying.

Well, I tried many many times and went so far as to ask on the mailing
list (was told it wouldn't work), never once was I able to make gpg create
a signature that pgp 2.6 would accept using a pipe. You might want to
double check that your sigs do work.. 

Jason

Re: debian-upload-queue in Japan (Re: Homapages in list of maintainers)

[Taketoshi Sano]

Thank you for your quick action :)

In article <[EMAIL PROTECTED]>
 Fumitoshi UKAI <[EMAIL PROTECTED]> writes:

> I've already set up debian upload queue daemon on master.debian.or.jp.
> It seems to work fine, Susumu Osawa has uploaded aumix package as powerpc 
> binary NMU via this upload queue yesterday:)

Then we should inform [EMAIL PROTECTED] about this 
to make update the /etc/dupload.conf file, as Josip Rodin told here and me
(Thank you Josip :).

> Now, I'm wondering what nickname is used for this upload queue.
> Since "master-jp" is already used for nickname to dupload for JP archives
> (in Debian JP Project), different name is better to distinguish, I think.  
> Any idea?

Even if the "master-jp" was not used, I think it is not suitable,
because it resembles "master". I don't like "master-??" coming
all over the world ;) 

How is the other nicname "chiark", "elrangen", and "giano" named ?
Are they named after the name of the location ?

I personally prefer "sakura", a Cherry blossom, kind of flower. 
It is famous in Japan, as a gift from Japan to be planted 
along the Potomac(?) river in the Washington D.C.

But another member of JP project said that name is used for
another host which is used to build the sparc binary...

Then, how about "tokyo" ? It is the name of a famous city that 
can be recognisable globally, I suppose.

Or "fuji" ? the name of the highest mountain in Japan.

-- 
  Taketoshi Sano: <[EMAIL PROTECTED]>

Re: Haskell in Debian

[Giuliano P Procida]

Hi.

On Wed, May 12, 1999 at 06:21:19PM +0200, Rui Zhu wrote:
> On Wed, May 12, 1999 at 07:00:31PM +0300, Antti-Juhani Kaijanaho wrote:
> > In related note, according to unofficial information from Simon Peyton
> > Jones (the primary author of GHC), the Glasgow Haskell Compiler (GHC) will
> > become free RSN.  Currently GHC has no license.  I've tried to bootstrap
> > it but it is so big a beast that I'll probably let it pass.  I hope
> > someone else packages it when it becomes free. 
> 
> It is good news though it is only unofficial one.  I've tried to build
> 4.02, it took me 4 hours on my K6-233 box and costed more than 100MB
> disk.  I'd like to apply to become a Debian maintainer and package it,
> if no one want to take it.

Well, for about the fifth time over the years, I'm having a go at
compiling ghc (I finally have plenty of disk and a decent amount of RAM).

I've hit two problems so far:

a) happy is unhappy [1]

 I have mailed Simon M? regarding this. Binary is distributed for use
 with libc5, "source" is distributed with a libc5-dependent bootstrap. I
 couldn't compile from the source due to ghc being unhappy with the
 options happy wanted (-fhaskell-1.3) and various hard-codings of the
 ghc path and the ghc version.

 I would happy to take on happy, once it's happy. This may just be a
 case of the GHC people making their latest CVS snapshot available. Oh,
 and there is the small question of the lack of a licence (I also queried
 this).

b) ghc runs out of heap compiling its parser

 The file ParseIface.hs (in ghc/compiler) needs more than 64M but no more
 than 128M of heap to compile. With 64M of RAM and not too much else
 (X and ntpd) running you are looking at 1500+ garbage collections for
 about 1.5G of allocation. This file took 10-20 minutes on my machine.

If you have >64M of RAM you should probably be the maintainer. I'm
thinking of upgrading in the next month of so, funds permitting.

In any case, given the quantity of stuff that makes up ghc (the compiler,
the profiling tools, the parallel simulation package, etc.), some division
of labour might be sensible.

If that turns out to be a bad idea... well, I have an alpha on which
I could _try_ to get ghc up and running, presupposing a diff.gz and a
working bootstrap compiler. I would need to find some more memory for
the poor thing though.

Lastly, the ghc-users list seems to be rather quiet, but I've only just
subscribed.

Giuliano.

[1] note for the bemused: happy is a yacc for Haskell

Re: GPG as a PGP replacement

[Marco d'Itri]

On May 13, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:

 >PGP 2.x compatible signatures can be generated using this command:
 >  gpg --rfc-1991 -a --clearsign foo.txt
AFAIK this is not needed. The only compatibility options I have in my
~/.gnupg/options file are:

compress-algo 1
force-v3-sigs
no-comment

 >Note: You cannot pipe input to gpg and get a PGP 2.x compatible sig.
I do that for it.* CFVs and I'm quite sure the signatures can be
verified with PGP 2.x.
If anyone cares I can provide my generic GPG.pm module for signing and
verifying.

-- 
ciao,
Marco

debbugs not on Freshmeat?

[Ossama Othman]

Hi,

I noticed that debbugs isn't listed in Freshmeat's bug tracking
software site:

http://freshmeat.net/appindex/development/bug-tracking.html

Is there any reason why it isn't listed?

-Ossama
-- 
Ossama Othman <[EMAIL PROTECTED]>
Center for Distributed Object Computing, Washington University, St. Louis
58 60 1A E8 7A 66 F4 44  74 9F 3C D4 EF BF 35 88  1024/8A04D15D 1998/08/26

Re: Package to give away/orphan: GNU acct

[Kenneth Scharf]

>acct is user login/use accounting, NOT money matters.
oops.  Yeah that was Xacct or something like that.  Oh well never mind.
===
Amateur Radio, when all else fails!

http://www.qsl.net/wa2mze

Debian Gnu Linux, Live Free or .


_
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com

Intent to create: nfs-client

[Anders Hammarquist]

In order for the kernel nfs daemon to function properly wrt file locking,
clients must be running rpc.statd. I will therefore, as part of moving
knfs to unstable, create a nfs-client package containing rpc.statd.

I plan to include showmount in it as well (with an approproate replaces for
nfs-server), since it is a handy tool on clients as well.

/Anders

-- 
 -- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist  | [EMAIL PROTECTED],iko.pp}.se
Physics Student, root, Debian Maintainer| Tel: +46.31.47 69 27
Jag ska b|rja plugga i l{svecka 1...| Cel: +46.707.27 86 87

Re: Release Plans (1999-05-10)

[Raphael Hertzog]

[ I'm responding to myself in order to precise things, there was some
  informations missing in the previous message ]
[ Followup on debian-perl, please ]
Le Thu, May 13, 1999 at 06:32:00PM +0200, Raphael Hertzog écrivait:
> This is true if perl5.004 will still be used, but as you know, perl5.005 
> has some binary incompatiblity for binary modules. And actual binary
> modules will be replaced by newly compiled ones and will depend on
> perl5.005. So if you have one binary module on your system and if
> people upgrade it, perl5.005 will be automatically installed. And
> /usr/bin/perl will be changed. And then the problems may arise.

In fact, we must agree to use the latest perl. Because there's the
same problem with non-binary perl modules. If they are built with
the latest perl, they'll be installed in a versionned directory and
therefore they will have to depend on perl5.005

Zephaniah, you must understand that the fact we decided to have multiple
perls do not ONLY have to do to the fact that we want a smooth upgrade but
also that we do want to make multiple perl available so that we can
use #!/usr/lib/perl5.004 in script that do specifically need such
a perl.

And we CAN have a smooth upgrade even with perl5.005 as the default
perl. The important point is that all modules in Debian must have
been built with the same perl version and that perl keeps /usr/lib/perl5
in @INC (only for potato release, after that we'll get rid of it because
the scripts that would break will already be corrected).

And I do not want to minimize the importance of the perl5.005 upgrade,
there are many little issues affecting MANY packages :
- of course perl modules must be rebuilt
- postint scripts of some packages must be corrected
- all package depending on perl will have to depend on perl5. If they
  need a specific version of perl, they'll have to set a dependency to
  perl5.XXX. This is not mandatory, but should be done for consistency,
  because the perl package will only be a fake package (like xbase was)
  depending on perl5.004. BTW, I think that perl should depend on
  perl5.004 | perl5.005 ... otherwise with perl5.005 installed, a
  package depending on perl would have dependencies problems. :-)

Cheers,
-- 
Hertzog Raphaël >> 0C4CABF1 >> http://prope.insa-lyon.fr/~rhertzog/

Re: GPG as a PGP replacement

[Alexander N. Benner]

Hi

Ship's Log, Lt. Jason Gunthorpe, Stardate 120599.2134:
> 
> Hi all,
> 
> I have been doing some reasearch here and I have been able to determine
> that right now GPG represents (with the non-free RSA and IDEA modules) a
> functional replacement for PGP 2.x for both checking signatures and
> creating signatures.
> 
> It is remarkably easy to do, I am surprised that someone else has not
> mentioned it.. Put this in your .gnupg/options file:
> 
> load-extension rsa
> load-extension idea
> keyring /usr/share/keyrings/debian-keyring.pgp
> keyring /usr/share/keyrings/debian-keyring.gpg
> keyring /home/jgg/.pgp/pubring.pgp
> secret-keyring /home/jgg/.pgp/secring.pgp

oops .. have you looked at the debian gpg?
It is actually a script callin gpg.gnupg (the binary) with exactly these
options (except the debian-keyring)

Greetings
-- 
Alexander N. Benner   [EMAIL PROTECTED]   #Ixthys #Darmstadt #LinuxGer
The grit in your eye soon enters your heartAnne Clark
And all that was strength is just falling apart
We're jumping from one bed and into anotherSELF DESTRUCT
Searching for something that we'll never discover  Joined Up Writing

Re: Release Plans (1999-05-10)

[Raphael Hertzog]

Le Thu, May 13, 1999 at 09:16:11AM -0400, Zephaniah E. Hull écrivait:
> Specificly the path issues and the mention of the bug reports..

About the bugs, here they are :
http://www.debian.org/Bugs/db/35/35236.html
http://www.debian.org/Bugs/db/35/35446.html

And there are path problems IF perl5.005 is used and IF perl5.005 is
compiled without /usr/lib/perl5 in @INC.

But with the solutions proposed in those bug reports, there won't be
any problems at all (with perl5.004 or perl5.005 and any further version).

> This gives the impression that you are quite unaware that perl5.005
> should have little to no effect on ANY packages which are currently in
> use, as perl5.004 will continue to be used by things..

This is true if perl5.004 will still be used, but as you know, perl5.005 
has some binary incompatiblity for binary modules. And actual binary
modules will be replaced by newly compiled ones and will depend on
perl5.005. So if you have one binary module on your system and if
people upgrade it, perl5.005 will be automatically installed. And
/usr/bin/perl will be changed. And then the problems may arise.

And last I talked with Darren, he said that he will need to add /usr/lib/perl5
to @INC at least for potato (woody's perl may get rid of it) in order
not to have to conflict with specific version of netstd and/or netbase.

Because actually there are postinst script that do NOT run if you use
perl5.005 without /usr/lib/perl5 in @INC. Look at netstd's and netbase's
postints. BTW, I think there's a similar problem for the PDL package.

> (There are a few minor issues which still need to be worked out, for
> instance perl-base and deciding which perl will become essential,
> however the basic upgrade path is that NOTHING breaks as perl5.004
> continues to be used by things)

That's ok, as long as you do not upgrade binary perl modules.

Cheers,
-- 
Hertzog Raphaël >> 0C4CABF1 >> http://prope.insa-lyon.fr/~rhertzog/

Re: Release Plans (19990513)

[Collins M. Ben]

On Thu, May 13, 1999 at 07:03:37AM -0600, Marcelo E. Magallon wrote:
> On Thu, May 13, 1999 at 02:28:16PM +0200, Richard Braakman wrote:
> 
> >   PAM:
> > Ben Collins sponsored full pamification as a release goal.  The main
> > packages that need work are the shadow suite, and xdm.
> 
> /me blinks...
> 
> has nis (the package) been PAMified?  I positively hate PAM because it's an
> all or nothing "solution".  After helping some people set nis up on a couple
> of RH boxes, we all agreed RH sucks big time.  They PAMified what they
> considered important, and their nis package wasn't on that list.  End
> result: you have lots of PAMified stuff, but you can't use most of PAM's
> features.

The reason for this is because RH uses libpwdb with their PAM apps and
pam_pwdb as a module. This means you have to setup /etc/nsswitch.conf
_and_ /etc/pwdb.conf to use NIS. We don't use libpwdb in our pam, and
pam_pwdb.so is not to be used as a default module for PAM applications.
Instead pam_unix_*.so is used and works fine with NIS.

PAM notes... [was Re: Release Plans (19990513)]

[Collins M. Ben]

On Thu, May 13, 1999 at 10:13:59AM -0600, Marcelo E. Magallon wrote:
> > I'm not entirely sure what you're talking about here.  
> > 
> > I use NIS and PAM all the time on RedHat (and Debian - although half
> > of our stuff is not yet pamified).  What exactly has to be pamified in
> > the nis package?  (In RH 6.0, setting up an NIS client is as easy as
> > typing the domain name into a text widget during the install.)
> 
> IIRC, the nis server was running Debian and the nis client was running RH
> 5.2; until I switched everything to unix_auth, the client wouldn't verify
> passwords using the NIS server.  On a different setup, both the system and
> the server were running RH 5.2, and NIS wouldn't work until unix_auth was
> used in /etc/pam.d/login; what's the point of using PAM if you end up using
> unix_auth?

The unix modules do not imply using /etc/{shadow,passwd}, they mean you
will be using the native libc calls which in turn use /etc/nsswitch.conf.
NIS should work fine with PAM without _any_ changes as long as you have
nis listed in nsswitch.conf for the proper listings (just the same as you
would have to do without PAM).

IOW, PAM does not have anything to do with NIS support. Please NOTE!!! Do
not use pwdb as defaults in the pam.d for packages which support PAM, we
ran into this problem with ssh/PAM, it does initially break NIS support
unless you also modify /etc/pwdb.conf, and this has been looked down on,
and should _not_ be used as default for our packages.

Re: Release Plans (19990513)

[Marcelo E. Magallon]

> I'm not entirely sure what you're talking about here.  
> 
> I use NIS and PAM all the time on RedHat (and Debian - although half
> of our stuff is not yet pamified).  What exactly has to be pamified in
> the nis package?  (In RH 6.0, setting up an NIS client is as easy as
> typing the domain name into a text widget during the install.)

IIRC, the nis server was running Debian and the nis client was running RH
5.2; until I switched everything to unix_auth, the client wouldn't verify
passwords using the NIS server.  On a different setup, both the system and
the server were running RH 5.2, and NIS wouldn't work until unix_auth was
used in /etc/pam.d/login; what's the point of using PAM if you end up using
unix_auth?


Marcelo

RE: Release Plans (1999-05-10)

[Brent Fulgham]

> > > (ask Brent Fulgham, maybe there were more),
> > 
> > Would it be possible to at least have one of those in potato?
> 
> Maybe. Question is - do we want another five thousand 
> wishlist bug reports
> from users screaming for something 'better'? ;(
> 
> I think you should look in http://va.debian.org/~bfulgham/ 
> and download
> the version of mozilla that is (hopefully) still there. If it 
> works, and
> if more people agree with it, I'll put it in potato.
> 
The only problem I had with the versions in my home directory
is that they were somewhat slow.  They were not built using
optimization, so they suffer some performance hits.

Everything seems to build fine according to Tinderbox.  Let's
try another build Josip and see how it works out.  If we can't
get it to build cleanly, I will pull CVS over my phone line at
home and try building on my Potato system there...

-Brent

Re: Old Library dependencies Re: Release Plans (19990513)

[Michael Alan Dorman]

Steve Dunham <[EMAIL PROTECTED]> writes:
>   Remove as many dependencies on old libraries as possible, this
>   includes:
> 
> libjpegg6a, libncurses3.4, newt0.25, libpgsql, tk4.2, tcl7.6,
> libwraster1, libpng0g
> 
>   and various older gtk/gnome libraries.

Looking at some of these, it occurs to me that one thing that may
cause this to happen accidentally is when a -dev package includes a
soname---because developers have to take an additional explicit step
to be sure to compile with the new version---as an example, the
existence of libpng0g-dev (rather than libpng-dev) would make it easy
for people to miss the new -dev library.

Should we try and remove sonames from -dev package names?

Mike.

Old Library dependencies Re: Release Plans (19990513)

[Steve Dunham]

Richard Braakman <[EMAIL PROTECTED]> writes:

> (Please send followups to this mail to debian-devel, not
> debian-devel-announce)

> This is what I learned from the responses to the previous announcement.

>   Boot disks:
>   CD Images:
>   Architectures:
>   PAM:
>  Perl 5.005:

Library dependencies:

  Remove as many dependencies on old libraries as possible, this
  includes:

libjpegg6a, libncurses3.4, newt0.25, libpgsql, tk4.2, tcl7.6,
libwraster1, libpng0g

  and various older gtk/gnome libraries.

Problematic packages can be found using "apt-cache showpkg libjpegg6a"
(replace libjpegg6a with the outdated library).  A whole list of
packages can be done with a script like:

  (LIBS="libpng0g newt0.25 ncurses3.4 libpgsql libjpegg6a tcl7.6 libwraster1"
  for pkg in $LIBS; do 
apt-cache showpkg $pkg|sed -e '/^Reverse D/,/^[^ ]/p;d'|grep -v Depend
  done)| sort -u 

(We should filter out an exceptions list too - these lists will have
to be seperately generated for each architecture.)  It might also be a
good idea to add a filter to dinstall to keep new packages that depend
on one of these libraries from being uploaded (with a suitable
exceptions list).  A raw list of "bad" packages is at the end of this
message.


Steve
[EMAIL PROTECTED]


  abiword,libpng0g
  angband,ncurses3.4
  boot-floppies,newt0.25
  cqcam,libjpegg6a
  cti-ifhp,ncurses3.4
  dbf2pg,libpgsql
  fbtv,libjpegg6a
  ftape-util,tk4.2
  gettyps,ncurses3.4
  gicon,libjpegg6a
  gnotes,libjpegg6a
  gtksql,libpgsql
  gzilla,libjpegg6a
  hdlant,ncurses3.4
  hfsutils-tcltk,libjpegg6a
  imagemagick,libjpegg6a
  imaptool,libjpegg6a
  ircii,ncurses3.4
  itcl3.0,ncurses3.4
  jpeginfo,libjpegg6a
  kerberos4kth-clients,ncurses3.4
  kerberos4kth-services,ncurses3.4
  kerberos4kth-user,ncurses3.4
  knews,libjpegg6a
  libch,libpgsql
  libhdf4g,libjpegg6a
  libjpeg6a,libjpegg6a
  libjpegg-dev,libjpegg6a
  libmagick4g,libjpegg6a
  libmagick4g-lzw,libjpegg6a
  libpgsql2,libpgsql
  libterm-readline-gnu-perl,ncurses3.4
  libtiff3,libjpegg6a
  malaga-bin,tk4.2
  mgt,ncurses3.4
  mosaic,libjpegg6a
  mosaic,libpng0g
  mush,ncurses3.4
  netris,ncurses3.4
  netstd,ncurses3.4
  nn,ncurses3.4
  oneliner,ncurses3.4
  perlmagick,libjpegg6a
  pfe,ncurses3.4
  prc-tools,ncurses3.4
  rat,ncurses3.4
  rscheme,ncurses3.4
  scilab,ncurses3.4
  scottfree,ncurses3.4
  sniffit,ncurses3.4
  socks4-clients,ncurses3.4
  speak-freely,ncurses3.4
  streamer,libjpegg6a
  tcd,ncurses3.4
  tcl7.6-dev,tcl7.6
  tcl76,tcl7.6
  tela,ncurses3.4
  telnet98,ncurses3.4
  telnetd98,ncurses3.4
  tf,ncurses3.4
  tk4.2,tcl7.6
  tk4.2-dev,tk4.2
  tk42,tk4.2
  tkdesk,tcl7.6
  tkdesk,tk4.2
  tkgofer,ncurses3.4
  tkgofer,tcl7.6
  tkgofer,tk4.2
  tkstep4.2,tcl7.6
  trn,ncurses3.4
  ultra-utils,ncurses3.4
  uudeview,tcl7.6
  uudeview,tk4.2
  vice,ncurses3.4
  webcam,libjpegg6a
  wmss,libwraster1
  worklog,ncurses3.4
  www-pgsql,libpgsql
  x11iraf,ncurses3.4
  xacc,libjpegg6a
  xawtv,libjpegg6a
  xfig,libjpegg6a
  xlife,ncurses3.4
  xloadimage,libjpegg6a
  xpaint,libjpegg6a
  xpcd,libjpegg6a
  yagirc,libjpegg6a

Re: Release Plans (19990513)

[Steve Dunham]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:

> On Thu, May 13, 1999 at 02:28:16PM +0200, Richard Braakman wrote:
> 
> >   PAM:
> > Ben Collins sponsored full pamification as a release goal.  The main
> > packages that need work are the shadow suite, and xdm.

> /me blinks...

> has nis (the package) been PAMified?  I positively hate PAM because it's an
> all or nothing "solution".  After helping some people set nis up on a couple
> of RH boxes, we all agreed RH sucks big time.  They PAMified what they
> considered important, and their nis package wasn't on that list.  End
> result: you have lots of PAMified stuff, but you can't use most of PAM's
> features.

I'm not entirely sure what you're talking about here.  

I use NIS and PAM all the time on RedHat (and Debian - although half
of our stuff is not yet pamified).  What exactly has to be pamified in
the nis package?  (In RH 6.0, setting up an NIS client is as easy as
typing the domain name into a text widget during the install.)

In fact, on Debian I use my own pamified versions of rsh because the
non-pam versions _don't_ work with NIS.  (They don't grok netgroups in
hosts.equiv.)


Steve
[EMAIL PROTECTED]

Re: Adding a global UID/GID?

[Mitch Blevins]

In foo.debian-devel, Brian wrote:
> On Thu, May 13, 1999 at 03:13:39AM -0400, Adam Di Carlo wrote:
> > > "Mitch" == Mitch Blevins <[EMAIL PROTECTED]> writes:
> > 
> > Mitch> GENERAL QUESTION: What is the procedure for getting a UID in
> > Mitch> the 0-99 range added to Debian?
> > 
> > Add a wishlist bug to 'base-passwd' I believe.
> And pray. :-) (http://bugs.debian.org/28158)

hmmm.  Maybe this is better suited for a dynamic system ID (101-1000)?
It doesn't look like we have much room to expand in the 0-100 range.

-Mitch
(minorly annoyed that a non-free package like qmail uses up 5% of our
 global UID space)

Re: Bug#37606: /var/spool/texmf/ls-R unwritable

[Julian Gilbey]

> Glad to hear all of this.  I just have one comment:
> 
> >  - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
> >If they are, anyone could run them, which is unnecessary.  Any
> >extra privileges they require will be gained when they are called
> >from other setuid processes.
> 
> It seems to me that *only* these three should be setuid, since only
> these three need elevated privileges.  mktextfm, etc. should be
> changed to write the output into a scratch directory, and have
> mktexupd move it into place.
> 
> Yes, this does mean anyone can invoke them, but if properly designed
> no damage can be done, and this restricts the scope of the changes and
> the scope of the specially privileged code much better.

No, absolutely not.  If mktexupd is setuid, then anyone can make it do
anything to the ls-R file, I would guess.  And having mktex{mf,tfm,pk}
writing to a scratch directory defeats the purpose of making the fonts
directory read only, as anyone could then create a corrupt font file
in the scratch directory and run mktexupd.  The mktexupd program is
essentially only used in two situations: (1) when called from
mktex{mf,tfm,pk} and (2) when called from texconfig or a postinst.  In
the latter situations, it will be running as root if it is doing
anything useful, and all that must be done in that case is to ensure
that the ownership of the ls-R files is unchanged.  This is not too
difficult to arrange if you are running as root!

   Julian

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

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
 Debian GNU/Linux Developer.  [EMAIL PROTECTED]
   -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-

Re: Release Plans (1999-05-10)

[Brian Almeida]

On Thu, May 13, 1999 at 01:02:10PM +0200, Richard Braakman wrote:
> Hmm... then why isn't it used on my system?  devpts is mounted, I
> have /dev/ptmx, but /dev/pts is empty.
Perhaps you aren't using anything that uses unix98 ptys?  Not everything
uses them by default, you know. Sometimes patches are required.  Try ssh'ing to 
localhost, or install Eterm, or grab some of the packages from 
ftp.espy.org/pub/debian (I think that's the correct path).  In there is patched 
packages for screen, telnet, etc to use Unix98 ptys.

Brian

Re: Package to give away/orphan: GNU acct

[shaleh]

acct is user login/use accounting, NOT money matters.

Intent to upload vflib2, watanabe-vfont and asiya24-vfont

[Keita Maehara]

I'll upload debian packaged version of vflib2 and two vfonts.

VFlib:

VFlib is a library for converting vector fonts (also known as outline
fonts) to bit map data. Its functions include rotation, shrinking, and
changing the slant of characters.  VFlib is used by localized software
for Japanese document processing that requires Kanji fonts, for
example xdvi, dvi2ps, ghostscript.

asiya24-vfont:

Vector fonts made from Abe's asiya24 font.

watanabe-vfont:

Vector fonts made from labosystem123 32dots font.

-- 
Keita Maehara <[EMAIL PROTECTED]>

Re: Release Plans (1999-05-10)

[Joel Klecker]

At 22:10 -0700 1999-05-12, Matt Porter wrote:
The non-mac CHRP boards (LongTrails etc.) also use OF I believe.  Are
their OF's so broken that they don't work properly as well?  Perhaps APUS
and PReP (and I'm talking PPCBUG firmware not OF systems) are the only
ones we need to worry about.  Interestingly enough, Motorola dropped OF
because it was so damn buggy.
No, CHRP boards tend to have good OF.
Most of the Macs had such broken OF because Apple did not rely on it 
for booting Mac OS (it only had to be enough to boot up and hand 
control to the Mac ROM).

In the "new world" architecture introduced with the iMac, Apple 
finally began relying on OF to boot Mac OS, thus it has to be stable.
--
Joel Klecker (aka Espy)Debian GNU/Linux Developer
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>

Re: Release Plans (1999-05-10)

[Joel Klecker]

At 10:25 +0200 1999-05-13, Hartmut Koptein wrote:
The OF of my LongTrail works perfectly but i don't know how to set it up for
autobooting. Booting from floppy is not (yet) possible (for initrd) because
the kernel cannot read the floppy. So net or cd booting are the only choices.
Currently i wait for manoj's update for his kernel-package with my 
changes. After
that, compiling will be easier. But then i need kernel-diffs for 
apus, pmac, prep
and also mbx for the 2.2.x tree.
Linus' tree is fine on pmac, from what I hear. The only patches pmac 
would need is stuff for the iMac and Blue G3, hopefully OHCI will 
start to work in the in-kernel USB driver soon, then I will have just 
the Blue G3 stuff to deal with.
--
Joel Klecker (aka Espy)Debian GNU/Linux Developer
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>

Re: Release Plans (1999-05-10)

[Joel Klecker]

At 13:02 +0200 1999-05-13, Richard Braakman wrote:
Joel Klecker wrote:
At 19:06 +0200 1999-05-10, Richard Braakman wrote:
>  * glibc 2.1 upgrade
>As far as I know, this project is largely complete.  There are one or two
>bugs left in the backward compatibility code, and there's the question
>of what to do with /dev/pts.
No there isn't, /dev/pts is taken care of.
Hmm... then why isn't it used on my system?  devpts is mounted, I
have /dev/ptmx, but /dev/pts is empty.
Most programs do not use UNIX98 ptys, is that what you meant about 
what to "do" with it?

>  Potato Architectures:
>As far as I know it will be the same set as in slink, i.e. i386, m68k,
>sparc, and alpha.  If any other architectures want to make a release
>they will have to decide soon.
powerpc wishes to try for potato.
Excellent.  Would someone like to be a "sponsor" for that, in the sense
that I described last March?
I am willing to be the sponsor for the powerpc release.
--
Joel Klecker (aka Espy)Debian GNU/Linux Developer
mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED]>
http://web.espy.org/>   http://www.debian.org/>

Re: Release Plans (1999-05-10)

[Anthony Towns]

Hi Richard,

On Thu, May 13, 1999 at 01:02:10PM +0200, Richard Braakman wrote:
> Excellent.  Would someone like to be a "sponsor" for that, in the sense
> that I described last March?
> 
> :   * Don't try to keep track of everything.  Find a "sponsor" for each
> : release goal, who keeps track of progress, makes sure it happens, and
> : gives advance warning of any problems.  That way the release manager
> : only has to stay in touch with the sponsor.

Could you please add "IPv6 Support" as a Release Goal? I'm willing to
act as a sponsor for this (especially since it looks like everyone else
is more than happy to do the actual work :).

We're aiming, more or less, to get the base system IPv6 capable for potato,
and, I guess, most of the networky programs of priority Standard or higher
for woody [0].

We're currently at the point where:

In potato:
* bind supports  records (and has for ages)
* netbase supports IPv6 interfaces, has a working ping6, and traceroute6

In progress: [1]

* telnet/telnetd (support for both IPv6 and IPv4 in one binary)
* inetd, tcp-wrappers
* apache
* zmailer
* radvd

Under consideration: (working packages aren't available yet)

* Exim
Mark Baker <[EMAIL PROTECTED]> (the exim.deb maintainer)
* GNU Zebra
Matthew Schlegel <[EMAIL PROTECTED]> (tentative intent to package)
Craig Sanders <[EMAIL PROTECTED]) (from the WNPP)
* apt
Remco van de Meent <[EMAIL PROTECTED]> (currently just trying things 
out)

Still to do for potato:

* ftp, ftpd
* finger, fingerd
* identd
* tcpdump
* lynx
* ssh

We're also working on getting a 6-bone subnet (or something similar) to help
testing all this.

Cheers,
aj

[0] ...or whatever.

[1] Packages have been made, and are available for testing from either of:

deb http://www.debian.org/~ajt/ipv6 ipv6 unstable
deb ftp://ftp.ipv6.nl/pub debian/

The sites are more or less synced; they're also i386 only at the
moment. All packages in the staging area *need* testing, btw: if you
try one and it does/doesn't work, please send a mail to the -ipv6
list so we know when things are ready to be mashed into potato.

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

   ``There's nothing worse than people with a clue.
 They're always disagreeing with you.'' 
 -- Andrew Over


pgpL91bHvu2CW.pgp
Description: PGP signature

Package to give away/orphan: GNU acct

[Kenneth Scharf]

>
>GNU acct is still broken for 2.2 kernels. I thought a >recompile would
>fix it,
>but it doesn't.  The upstream author, with whom I >generally had very
>good
>(albeit sporadic) contact is MIA.  AFAICT the other >dists don't
>distribute
>acct.

>The package needs a kernel hacker type who can debug >and hopefully
fix
>it.
>Unless someone steps forward to adopt it, I will ask >that acct be
>removed
>prior to the release of potato

In looking at the gnucash site I got the impression that work on gnu
acct was being phased out in favor of gnucash.  Has anyone tried to
complile gnucash, I think they have made the move from motif/lesstif to
gtk.  As soon as I get the time to install gnome on my slink system,
trying out gnucash is on my todo list (if I can get a replacement for
quicken and turbotax I can get my wife off windows and on to linux.  I
already have a replacement for wordperfect, wordperfect!)

===
Amateur Radio, when all else fails!

http://www.qsl.net/wa2mze

Debian Gnu Linux, Live Free or .


_
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com

Re: Release Plans (1999-05-10)

[Zephaniah E. Hull]

Sorry it took me so long to reply, life decided to give me my yearly
supply of 'fun' in a small amount of time, and I had deleted the
message I was replying to..

I'm also sorry about how I jumped, I over reacted a bit, as I said, this
has been a very interesting week...

On Tue, May 11, 1999 at 07:51:31AM +0200, Raphael Hertzog wrote:
> Le Mon, May 10, 1999 at 07:12:55PM -0400, Zephaniah E. Hull écrivait:
> > I highly question your ability to fill this role as it is quite clear
> > that you have not been following the perl5.005 stuff, specificly the
> > debian-perl list and the massages on -devel before -perl existed about
> > how to attack it..
> 
> I've read everything, I'm subscribed to -perl. I know that Darren is
> working hard on the perl package.
> 
> What do you have against me ? I'm ready for helping and you criticize
> me. If you want to do the job, it's ok for me. 
> 
> > The current plan cleanly addresses the case of things ending up broken,
> > and the perl maintainer is a bit busy but spending his time working on
> > it instead of jumping up every thread where incorrect info is mentioned.
> 
> What was wrong in the message you're replying to ?

Specificly the path issues and the mention of the bug reports..

(From the message I replied to in the first place)
> Many of them were only paths problems (that may not appear with the
> official perl5.005 package). And I've already filled some bugs against
> netbase and netstd so that the packages do not break when perl5.005 is
> uploaded.

This gives the impression that you are quite unaware that perl5.005
should have little to no effect on ANY packages which are currently in
use, as perl5.004 will continue to be used by things..

(There are a few minor issues which still need to be worked out, for
instance perl-base and deciding which perl will become essential,
however the basic upgrade path is that NOTHING breaks as perl5.004
continues to be used by things)


As far as the coordinator position, I don't think I'm up to keeping
track of everything, but I would definitely like to stay just a little
off to the side of the middle...

Once again, sorry for snapping at you, hopefully I'll still be living
here tomorrow, and be in a state to do anything. (Don't ask, unless
you really want a nice long rant about things)

Zephaniah E. Hull..
> 
> Cheers,
> -- 
> Raphaël Hertzog >> 0C4CABF1 >> http://prope.insa-lyon.fr/~rhertzog/

-- 
 PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
   CCs of replies from mailing lists are encouraged.


pgp065hyL6CwB.pgp
Description: PGP signature

Re: Release Plans (19990513)

[Marcelo E. Magallon]

On Thu, May 13, 1999 at 02:28:16PM +0200, Richard Braakman wrote:

>   PAM:
> Ben Collins sponsored full pamification as a release goal.  The main
> packages that need work are the shadow suite, and xdm.

/me blinks...

has nis (the package) been PAMified?  I positively hate PAM because it's an
all or nothing "solution".  After helping some people set nis up on a couple
of RH boxes, we all agreed RH sucks big time.  They PAMified what they
considered important, and their nis package wasn't on that list.  End
result: you have lots of PAMified stuff, but you can't use most of PAM's
features.


Marcelo

Re: Adding a global UID/GID?

[Brian Almeida]

On Thu, May 13, 1999 at 03:13:39AM -0400, Adam Di Carlo wrote:
> > "Mitch" == Mitch Blevins <[EMAIL PROTECTED]> writes:
> 
> Mitch> GENERAL QUESTION: What is the procedure for getting a UID in
> Mitch> the 0-99 range added to Debian?
> 
> Add a wishlist bug to 'base-passwd' I believe.
And pray. :-) (http://bugs.debian.org/28158)

Re: Release Plans (1999-05-10)

[Josip Rodin]

On Thu, May 13, 1999 at 10:12:46PM +1000, Anthony Towns wrote:
> > > > >  mozilla should work for potato 
> > > > Maybe it will ;) We'll try.
> > > If it doesn't, I guess the current mozilla should be removed?  It's sort
> > > of old now, and it doesn't work with glibc 2.1.
> > I was kidding - newer mozilla *does* work, just not the versions people
> > expect from us. We had it working just fine in versions 19990323 and 
> > 19990402
> > (ask Brent Fulgham, maybe there were more),
> 
> Would it be possible to at least have one of those in potato?

Maybe. Question is - do we want another five thousand wishlist bug reports
from users screaming for something 'better'? ;(

I think you should look in http://va.debian.org/~bfulgham/ and download
the version of mozilla that is (hopefully) still there. If it works, and
if more people agree with it, I'll put it in potato.

> I was using Mozilla 19981008 for a while with some happiness, but
> eventually got annoyed by some of its bugs and that it wasn't getting
> updated. :-/
> 
> It'd be nice to have a free, frames & java & such -capable browser to
> install, without having to wrestle with the big green dragon...

I'm all for it, but it ain't so easy :)

BTW is there a fast potato i386 machine somewhere on the net for us
developers to use? I'm sick of mailing debian-admin to install
one-thousand-and-one little library from potato for building mozilla...

-- 
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Re: Bug#37606: /var/spool/texmf/ls-R unwritable

[Zack Weinberg]

On Thu, 13 May 1999 11:25:10 +0100 (BST), Julian Gilbey wrote:
>[Cc'ing to -devel]
>
>> Package: tetex-base
>> Version: 0.9.990406-1
>> 
>> Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644.
>> Therefore all font generation operations get an error:
>> 
>> /usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable.
>> 
>> Changing it to mode 666 works around the problem, but the right thing
>> would be to make mktexupd setgid to some group (daemon?) and make
>> /var/spool/texmf/ls-R writable by that group.  Possibly the same thing
>> should be done to the subdirectories of /var/spool/texmf, mode 1777
>> can be problematic.
>
>You are correct.  A fully working solution which closes the security
>holes is not straightforward, though.  I am currently working on a
>project to solve this problem.  In the meantime though, note that the
>font _is_ generated and stored, will be found by kpathsea on the next
>occasion that it is needed, and will be written into the ls-R file the
>next time the tetex cron job runs.

Glad to hear all of this.  I just have one comment:

>  - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
>If they are, anyone could run them, which is unnecessary.  Any
>extra privileges they require will be gained when they are called
>from other setuid processes.

It seems to me that *only* these three should be setuid, since only
these three need elevated privileges.  mktextfm, etc. should be
changed to write the output into a scratch directory, and have
mktexupd move it into place.

Yes, this does mean anyone can invoke them, but if properly designed
no damage can be done, and this restricts the scope of the changes and
the scope of the specially privileged code much better.

zw

Re: Release Plans (1999-05-10)

[Anthony Towns]

On Thu, May 13, 1999 at 01:53:11PM +0200, Josip Rodin wrote:
> On Thu, May 13, 1999 at 01:13:10PM +0200, Richard Braakman wrote:
> > > >mozilla should work for potato 
> > > Maybe it will ;) We'll try.
> > If it doesn't, I guess the current mozilla should be removed?  It's sort
> > of old now, and it doesn't work with glibc 2.1.
> I was kidding - newer mozilla *does* work, just not the versions people
> expect from us. We had it working just fine in versions 19990323 and 19990402
> (ask Brent Fulgham, maybe there were more),

Would it be possible to at least have one of those in potato? I was
using Mozilla 19981008 for a while with some happiness, but eventually
got annoyed by some of its bugs and that it wasn't getting updated. :-/

It'd be nice to have a free, frames & java & such -capable browser to
install, without having to wrestle with the big green dragon...

Cheers,
aj

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

   ``There's nothing worse than people with a clue.
 They're always disagreeing with you.'' 
 -- Andrew Over


pgpPKmHspPVJQ.pgp
Description: PGP signature

Re: Release Plans (1999-05-10)

[Josip Rodin]

On Thu, May 13, 1999 at 01:13:10PM +0200, Richard Braakman wrote:
> > >  mozilla should work for potato 
> > 
> > Maybe it will ;) We'll try.
> 
> If it doesn't, I guess the current mozilla should be removed?  It's sort
> of old now, and it doesn't work with glibc 2.1.

I was kidding - newer mozilla *does* work, just not the versions people
expect from us. We had it working just fine in versions 19990323 and 19990402
(ask Brent Fulgham, maybe there were more), but since then they (the
mozilla.org guys) released the fourth and fifth milestone (that's their
way of calling the big public releases), and everybody expects us (Debian)
to package them. Unfortunately, M4 instantly coredumps on every fscking
computer we've tried it on, and I can't even build M5 :(

I'm trying to build some newer versions right now, actually.
What more can I say - we'll just keep trying. If we don't manage to do it
before freeze, then I'll file a bug against ftp.debian.org, asking for
mozilla package to be removed.

-- 
enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Please adopt: prc-tools

[John Goerzen]

Hi,

prc-tools is a gcc, gdb, and binutils cross-development package that
generates and works with binaries for use on the Palm
Pilot/PalmIII/IIIX/V line of products.  I tried giving it away last
December, but apparently the person that took it didn't have time to
upload it, so I'm trying again.  The reason I'm giving it away is that 
it is i386-only and I do not have an i386 system on which to maintain
it.

Thanks,
John

Re: PROPOSAL: preparation for freezes, release coordination

[Richard Braakman]

Adam Di Carlo wrote:

> * Release Critical Bugs
> 
> With respect to fixing release critical bugs, I think there are two
> components to lowering this as a big problem.  The first, as pointed
> out, is to *not* try to cram heavily broken things into unstable just
> prior to freeze, and it just requires a little self-discipline from
> developers.  

I hope to fix this in the long run by having more frequent releases,
so that maintainers are less anxious to get their packages in the
upcoming release.  In the short term... let's just hope :-)

> The second solution for fixing release-critical bugs is a revived and
> healthy Debian QA group.  I believe Joey is trying to revive this, and
> I wish him the best of luck.

I'm following this development with interest, too.  We could use an
active Bug-Hunting team.  (Nobody expects the Bug Inquisition!)
I don't know if the QA team wants to be that, though.  If not,
could we create a separate team for chasing release-critical bugs?

> * Release Coordination
> 
> I propose that we create a new list (argh, yet another list!),
> 'debian-release'.  Next, we ask that representatives from all
> interested teams (including boot-floppies, cd, archive mgmt, porters,
> the QA team, testers, security team) be subscribed to the list.  This
> would be a low-volume list for the increased communication between
> these teams.  The consensus reached on this list must be implemented
> in an prompt fashion, i.e., moving packages into the archive.

I support this idea.  Among other things, it would be an excellent
forum for constructing a step-by-step plan for the release, so that
no details are missed and everything happens in the right order.

Richard Braakman

Re: Release Plans (1999-05-10)

[Richard Braakman]

Joel Klecker wrote:
> At 19:06 +0200 1999-05-10, Richard Braakman wrote:
> >  * glibc 2.1 upgrade
> >As far as I know, this project is largely complete.  There are one or two
> >bugs left in the backward compatibility code, and there's the question
> >of what to do with /dev/pts.
> 
> No there isn't, /dev/pts is taken care of.

Hmm... then why isn't it used on my system?  devpts is mounted, I
have /dev/ptmx, but /dev/pts is empty.

> >  * glibc 2.1 source compatibility
> >A larger task is to ensure that all packages still compile on a glibc
> >2.1 development system.  The sparc people may have a list of problem
> >packages.
> 
> Most problems in this area have been fixed by the combined effort of 
> the sparc, arm, and powerpc porters.
> 
> However, many of the patches are sitting in the BTS and have yet to be 
> applied.

That is what I meant, actually.  We should get those patches into the
packages.  The issue was delayed during the slink release, I don't think
we can in good conscience delay it again.  Debian packages should
compile from source!

> >  Potato Architectures:
> >As far as I know it will be the same set as in slink, i.e. i386, m68k,
> >sparc, and alpha.  If any other architectures want to make a release
> >they will have to decide soon.
> 
> powerpc wishes to try for potato.

Excellent.  Would someone like to be a "sponsor" for that, in the sense
that I described last March?

:   * Don't try to keep track of everything.  Find a "sponsor" for each
: release goal, who keeps track of progress, makes sure it happens, and
: gives advance warning of any problems.  That way the release manager
: only has to stay in touch with the sponsor.

Richard Braakman

Re: Release Plans (1999-05-10)

[Richard Braakman]

Hartmut Koptein wrote:
> Hi,
> 
> > BTW, I think it's good to set an *optimistic* freeze date, so people
> > aren't shocked.  I would set it at July 1, or maybe Bastille day
> > (Debian pomme de terre?).

We have a long history of overly optimistic freeze dates :-)  I'd like
to try something else this time.  I note, though, that if we do manage
to freeze on July 1, we'll be able to have a release in time for the
Linuxworld Expo in August.  That would be cool.

> For slink update or for potato? For potato we new min. two months and
> only if we start now working very hard (all maintainers, not only 10 people 
> or so)
> on bad packages & boot-floppies & cd-images.

Two months means fixing 2 release-critical bugs per day, starting now.
I may have to "re-evaluate" a few...

In any case, my next step will be to mark the packages that I plan to
remove from "frozen" if they aren't fixed at freeze time.  This way,
their maintainers have advance warning, and the bughunters can concentrate
on bugs that will actually delay the freeze.

> The QA-team must then also have the power to do massive NMU's.
> How many open bugs have we, more then 7000?  This must be down to ~1000. 

Wow, you're more ambitious than I am :-)  I'll be happy enough if we
can get the release-critical bugs under control.  The rest are, well,
not critical to the release, and I'll let someone else worry about them.

That said, though, I would like to encourage maintainers to fix up
existing packages, rather than packaging more and more new ones.
I don't think we can ever reduce the number of bugs unless the
ratio of maintainers to packages goes up.

Richard Braakman

Re: Release Plans (1999-05-10)

[Richard Braakman]

Josip Rodin wrote:
> On Mon, May 10, 1999 at 08:55:44PM +0200, Hartmut Koptein wrote:
> >mozilla should work for potato 
> 
> Maybe it will ;) We'll try.

If it doesn't, I guess the current mozilla should be removed?  It's sort
of old now, and it doesn't work with glibc 2.1.

Richard Braakman

Re: Bug#37606: /var/spool/texmf/ls-R unwritable

[Julian Gilbey]

[Cc'ing to -devel]

> Package: tetex-base
> Version: 0.9.990406-1
> 
> Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644.
> Therefore all font generation operations get an error:
> 
> /usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable.
> 
> Changing it to mode 666 works around the problem, but the right thing
> would be to make mktexupd setgid to some group (daemon?) and make
> /var/spool/texmf/ls-R writable by that group.  Possibly the same thing
> should be done to the subdirectories of /var/spool/texmf, mode 1777
> can be problematic.

You are correct.  A fully working solution which closes the security
holes is not straightforward, though.  I am currently working on a
project to solve this problem.  In the meantime though, note that the
font _is_ generated and stored, will be found by kpathsea on the next
occasion that it is needed, and will be written into the ls-R file the
next time the tetex cron job runs.

My current state of progress is:
  - Working Perl Kpathsea interface and Kpathsea module (although they
are labelled as alpha, there are some minor bugs apparently and
the Makefiles need cleaning up).  You can download it from
http://www.debian.org/~jdg.
  - I have rewritten all of the mktex scripts in Perl except for
mktex{mf,tfm,pk}.  (You might say, "Huh?  But that's all of them!"
But this means that I have dealt with mktex.opt, mktexnam,
mktexnam.opt, mktexdir, mktexdir.opt, mktexupd and mktexlsr.  Just
the three last ones to go.)  Unfortunately, these are currently on
paper only; you can have a photocopy of them if you really desire ;)

Still to go:
  - At present, I am working on making the Perl scripts behave
identically (modulo bugs) to the shell script counterparts.  When
this is working, I fully intend to introduce variant behaviour if
the script is running setuid.  We need the scripts to be setuid
tex if they are to be secure, as otherwise, the owner of the
process will still own any font files created, which is Not Good.
Then the writeable font trees would be owned by tex, mode 755, and
ls-R would be owned by tex with mode 644.

  - The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
If they are, anyone could run them, which is unnecessary.  Any
extra privileges they require will be gained when they are called
from other setuid processes.  The mktex{mf,tfm,pk} scripts should
do the following if they are running setuid (and do the same as
present if not):
 . In a child process, drop any privileges and check the
   locations of the files which would need to be created (by
   calling mktexnam).  Report back to the parent process.
 . In the parent process, compare the results against the value of
   SYSTEXMF obtained from the system texmf.cnf files, having
   cleared (but saved) any environment variables.  If the location
   which would be used is not within the SYSTEXMF trees, then drop
   privileges, reinstate the old environment and create the font.
   Since the process is now running as the user with no
   privileges, any nasty settings in their personal texmf.cnf or
   environment will be ignored.
 . Otherwise, we continue with privileges and a sanitised
   environment to figure out where *we* would like to place the
   created fonts by calling mktexnam again.  If it is not in one
   of the recognised places (SYSTEXMF, VARFONTS), give up.
   Otherwise, go ahead and create the font.

  - Issues which need to be addressed for this to work:
 . mktexnam currently makes assumptions about the location of a
   font based on the writeability of a directory.  We must ensure
   that these assumptions are correct in this scheme.

 . We must be very careful to fork a child process to do the font
   creation *before* invoking any of the Kpathsea routines, as the
   texmf.cnf files cannot be reinitialised easily.  A better
   solution may well be to have mktex{mf,tfm,pk} be setuid C
   wrappers which call the non-setuid mktex{mf,tfm,pk}.pl scripts;
   then they can simply exec another copy of themselves and load
   the Kpathsea library afresh.  (This also avoids people needing
   to have suidperl around if they don't want it.)  Doing this
   properly is probably a bit painful (will probably use parts of
   Kpathsea's proginit.c to get the right location of the mktex
   scripts).

 . This sound like a lot of computational work, and that it will
   be a lot slower than the present system, but since the ls-R
   databases will need loading only a handful of times, this
   should turn out to be much faster.

Comments appreciated!

   Julian

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

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
 Debian GNU/Linux Developer.  [EMAIL PROTECT

Re: Splitting debian-devel-changes to separate lists

[Julian Gilbey]

On Wed, 12 May, 1999, Bart Warmerdam wrote:
> 
>   Hi,
> 
>   The topic to split debian-devel-changes in a -$ARCH and -sources
>   list was proposed a while ago. What happened to it and what are
>   the sentiments on splitting it?? I think it's quite high volume
>   because most lists aren't intresting to me, but some are.

This isn't really something to vote on.  The situation is this:

dinstall (the program on master which installs packages into the
archive) has been modified to make announcements automatically when
the .changes file has format version 1.6.  This is produced by an
experimental version of dpkg(-dev).  Once these changes are added to
the standard dpkg(-dev) and all of the maintainers have upgraded to it
(say, after the next release), it will be a trivial matter to modify
dinstall to announce to the appropriate list (and I believe that Guy
intends to do this).  Until then, we will continue the way it is.

   Julian

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

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
 Debian GNU/Linux Developer.  [EMAIL PROTECTED]
   -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-

Re: Release Plans (1999-05-10)

[Hartmut Koptein]

> The non-mac CHRP boards (LongTrails etc.) also use OF I believe.  Are
> their OF's so broken that they don't work properly as well?  Perhaps APUS
> and PReP (and I'm talking PPCBUG firmware not OF systems) are the only
> ones we need to worry about.  Interestingly enough, Motorola dropped OF
> because it was so damn buggy.

The OF of my LongTrail works perfectly but i don't know how to set it up for
autobooting. Booting from floppy is not (yet) possible (for initrd) because
the kernel cannot read the floppy. So net or cd booting are the only choices. 

Currently i wait for manoj's update for his kernel-package with my changes. 
After
that, compiling will be easier. But then i need kernel-diffs for apus, pmac, 
prep
and also mbx for the 2.2.x tree. Which class is rs/6000, chrp or prep? 

Thnx,

   Hartmut

Retraction of Intend to Package: root framework

[Jens Ritter]

-BEGIN PGP SIGNED MESSAGE-


Dear wnpp maintainers, Dear fellow developers,

when I recently had a look at the wnpp list, I saw that I once intended to
package the root framework ( http://root.cern.ch/ ).

Unfortunatly I am currently working on my diploma (on my master) and as
some of you might have noticed, I am even not paying the needed attention
to my existing packages (kbackup e.g.). 

In addition, the license accompanying the root framework prohibits
distribution of patches without the permission of the authors. 

Because of this I want to retract my Intent to package. 

But I would like to point out, that root extensively uses a C/C++
interpreter with licensing terms, which are more free (cint). 

Maybe some of you would like to have cint packaged and have enough time to
split it from the root. 

Greetings,

Jens

P.S.: Please vote against Spam! At
 http://www.politik-digital.de/spam/
(Sorry Europeans only)
- ---
[EMAIL PROTECTED]   [EMAIL PROTECTED]
Key ID: 2048/E451C639 Jens Ritter
Key fingerprint: 5F 3D 43 1E 24 1E CC 48  1E 05 93 3A A7 10 73 37 

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv

iQEVAwUBNzqCubIME9PkUcY5AQGuRQgAsYhrFSpg8f3yH5n+/g4Lk7BuGEZKgUoV
boQbciqAaeVYVj5KFSzdiW7/Dg4qoJHr56nA/+oVXvfoJcuJJYtoBqEGADUv9v7L
3CvOyt0DGKc1YuPeZRt4TvH2K1HFziOAC+r222k/w7cct7379kgMW/wjF9cHvQ1/
vxscSptB68tJWEfD+FlyKkU320+LRDf0ahqN7W2ctKUJCUxA8krj/CHUh9RLyjwW
njbflU/u1YkYSBrW3Tux1wut2fjuLWRyd/FWQamfWyouNRxHIlVpPBFdKSdTeXih
9eFn8Yx0GaDmBYtIxAA/HzdMU/spRPvetecYw5YqVVS/Kbh7o7803w==
=V53m
-END PGP SIGNATURE-

Re: Splitting debian-devel-changes to separate lists

[Zephaniah E. Hull]

On Wed, May 12, 1999 at 07:36:27PM +0100, Edward Betts wrote:
> On Wed, 12 May, 1999, Bart Warmerdam wrote:
> > 
> >   Hi,
> > 
> >   The topic to split debian-devel-changes in a -$ARCH and -sources
> >   list was proposed a while ago. What happened to it and what are
> >   the sentiments on splitting it?? I think it's quite high volume
> >   because most lists aren't intresting to me, but some are.
> 
> seconded

Also seconded, but I think this should be on -policy as (IIRC) the lists
are mentioned in policy..

Zephaniah E. Hull..
> 
> -- 
> I consume, therefore I am



-- 
 PGP EA5198D1-Zephaniah E. Hull <[EMAIL PROTECTED]>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
   CCs of replies from mailing lists are encouraged.


pgp6Ts5MVmVKo.pgp
Description: PGP signature

Re: doc-base and obnoxious unknown format warnings

[Ben Gertzfield]

> "Adam" == Adam Di Carlo <[EMAIL PROTECTED]> writes:
> "Ben" == Ben Gertzfield <[EMAIL PROTECTED]> writes:
> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

Joey> "warning: ignoring unknown format `$$format_data{'format'}'"
Joey> if $ENV{DOC_BASE_GRIPE}; }
 
Ben> This is a nice solution.

Adam> Well, actually, in tonight's upload, I only enabled this
Adam> warning if the -v or --verbose switch it used.  Much
Adam> cleaner.  I hate env vars anyway.

Fine by me! :)

-- 
Brought to you by the letters E and L and the number 0.
"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: Release Plans (1999-05-10)

[Gordon Deane]

Hi, everyone.
I've successfully built most of Gnome on a stock Slink system.
Three cheers for the Gnome project and the packaging team!

On 12 May 1999 15:41:04 +0200, Martin Bialasinski wrote :
> BTW: compiling gnome is a pain. We _need_ source dependencies
Hear, hear.

Just for flavour, the gotchas I've found include:
- Need to upgrade autoconf, automake, libtool and debhelper
- Make sure libjpeg62-dev and not libjpeg6a-dev is installed, or
  Imlib builds linked against both, and weird stuff happens.
- There are a number of minor build breaks or hassles which I
  don't have time to reproduce and document.  An autobuilder would
  have a lot of trouble just right now.  Eg. bug #37226 and more.

I think Debian should have high quality Slink gnome binaries, because
not everyone can afford to run unstable and building from source is 
quite a lot of work.  Also, Redhat have this shipped :-)

Good luck,

Gordon


Building Gnome is pretty mind-blowing:  tens of megabytes of code
and data wrapped in two-million, five hundred thousand tonnes of
spinning build-script...  

PS: Can debian-gtk-gnome be web-archived?

-- 
We knew we were in trouble when we needed the 
seventh power-board for the coffee machines.
// Gordon Deane // Engineering/Maths // Aust. Nat. Uni //

Re: doc-base and obnoxious unknown format warnings

[Adam Di Carlo]

> "Ben" == Ben Gertzfield <[EMAIL PROTECTED]> writes:

> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> "warning: ignoring unknown format `$$format_data{'format'}'" if
Joey> $ENV{DOC_BASE_GRIPE}; }
 
Ben> This is a nice solution.

Well, actually, in tonight's upload, I only enabled this warning if
the -v or --verbose switch it used.  Much cleaner.  I hate env vars
anyway.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

Re: Adding a global UID/GID?

[Adam Di Carlo]

> "Mitch" == Mitch Blevins <[EMAIL PROTECTED]> writes:

Mitch> GENERAL QUESTION: What is the procedure for getting a UID in
Mitch> the 0-99 range added to Debian?

Add a wishlist bug to 'base-passwd' I believe.

--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>

alternative man page reader?

[Bradley Bell]

has anybody thought about packaging an alternative to the man-db/groff
combination for reading man pages?  4mb is a lot for small systems, and
reading man pages is pretty much a neccessity.

-Brad
-Brad

Re: Release Plans (1999-05-10)

[Chris Lawrence]

On May 12, Matt Porter wrote:
> The non-mac CHRP boards (LongTrails etc.) also use OF I believe.  Are
> their OF's so broken that they don't work properly as well?  Perhaps APUS
> and PReP (and I'm talking PPCBUG firmware not OF systems) are the only
> ones we need to worry about.  Interestingly enough, Motorola dropped OF
> because it was so damn buggy.

IMHO there's no point in making the APUS installer boot from
CD... people will need to select video cards, etc.  Besides which,
most Amigas can't boot from CD anyway...

Guess that narrows it to PReP ;-)


Chris
-- 
=
| Chris Lawrence  |   Visit my home page!   |
|<[EMAIL PROTECTED]> | http://www.lordsutch.com/chris/ |
| | |
| Amiga A4000 604e/233Mhz |  Visit the Amiga Web Directory  |
|  with Linux/APUS 2.2.3  | http://www.cucug.org/amiga.html |
=

Re: Release Plans (1999-05-10)

[Phillip R. Jaenke]

On Wed, 12 May 1999, Matt Porter wrote:

> The non-mac CHRP boards (LongTrails etc.) also use OF I believe.  Are
> their OF's so broken that they don't work properly as well?  Perhaps APUS
> and PReP (and I'm talking PPCBUG firmware not OF systems) are the only
> ones we need to worry about.  Interestingly enough, Motorola dropped OF
> because it was so damn buggy.

that reminds me, now that i have my home email working again. (yeah, i'm
baack. head for the hills while you can.;)

does anybody actually have a list of non-MCG/non-IBM/non-Apple PowerPC
CHRP/PReP boards? I'm trying to hunt those little buggers down. Me, being
the crazy little bastard I am, plan to get those suckers booting somehow.
(Don't ask how; I really dunno yet. Probably hack up lilo or something.:)

Also, for those of you who aren't subscribed to debian-powerpc, and have
RS/6000's - I am working on bootable kernel images, both UP and SMP, for
every RS/6000 that I currently have *REASONABLY* stable. The problem is
that I *have* to use 2.2.x kernels, due to the fact that, well, 2.0.x
kernels are just quite unsuitable for use on RS/6000's. Too many various
issues that I've run into. I'm having some.. ISSUES *grumble*.. with kpkg
still, but I'll be sure and let everyone know when they're done. I bugged
up gcc again, so it'll be a few days probably.

-Phillip R. Jaenke, Head Unix Guru, Unicent Telecom
 216-344-2603 / 9a->~5p Eastern - Pester me!

Re: Release Plans (1999-05-10)

[Matt Porter]

On Wed, 12 May 1999, Joel Klecker wrote:

> At 15:14 +0200 1999-05-12, Sven LUTHER wrote:
> >I think the issue is the different way that different ppc systems uses to 
> >boot
> >from the CD. I am not entirely sure how amigaos does this, but i bet it is
> >different from macos ...
> >
> >Sure, we could choose not to be cd-bootable, best would be to d othis the 
> >same
> >way it is done for linux/m68k cds ..
> 
> For power macs, we don't need to worry about bootable CDs, most of 
> them have Open Firmware that is too broken to even be capable of 
> booting from either a cdrom drive or a iso9660 filesystem.
> The few macs that have reasonable OF should be able to boot from an 
> arbitrary executable residing anywhere on the filesystem.

The non-mac CHRP boards (LongTrails etc.) also use OF I believe.  Are
their OF's so broken that they don't work properly as well?  Perhaps APUS
and PReP (and I'm talking PPCBUG firmware not OF systems) are the only
ones we need to worry about.  Interestingly enough, Motorola dropped OF
because it was so damn buggy.

--
Matt Porter
[EMAIL PROTECTED]
This is Linux Country. On a quiet night, you can hear Windows reboot.

Re: Release Plans (1999-05-10)

[Aaron Van Couwenberghe]

On Wed, May 12, 1999 at 11:29:10PM -0400, Branden Robinson wrote:
> I've been told that this is pretty much Christian Hudon's decision.
> Perhaps an exception could be made for X, given that it is so huge and
> onerous to download, and requires gargantuan amounts of space and time to
> build.  But my feelings won't be hurt if he decides against it.
> 
> In the meantime, Johnie Ingram has been making glibc 2.0 versions of my
> potato XFree86 packages available at .

Which work quite well, by the way ;P. I was forced to get them for my
laptop.

-- 
..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED]
Berlin: http://www.berlin-consortium.org
Debian GNU/Linux:   http://www.debian.org

"...Nothing astonishes men so much as common sense and plain dealing..."
-- Ralph Waldo Emerson

GPG as a PGP replacement

[Jason Gunthorpe]

Hi all,

I have been doing some reasearch here and I have been able to determine
that right now GPG represents (with the non-free RSA and IDEA modules) a
functional replacement for PGP 2.x for both checking signatures and
creating signatures.

It is remarkably easy to do, I am surprised that someone else has not
mentioned it.. Put this in your .gnupg/options file:

load-extension rsa
load-extension idea
keyring /usr/share/keyrings/debian-keyring.pgp
keyring /usr/share/keyrings/debian-keyring.gpg
keyring /home/jgg/.pgp/pubring.pgp
secret-keyring /home/jgg/.pgp/secring.pgp

(for instance)

GPG will directly read your existing PGP 2 key rings, the distributed RSA
ring and the DSS ring. It also able to directly parse the encrypted secret
key ring.

PGP 2.x compatible signatures can be generated using this command:

  gpg --rfc-1991 -a --clearsign foo.txt

Note: You cannot pipe input to gpg and get a PGP 2.x compatible sig.
Werner says it enters a different mode when you use a pipe..

Sigs can be checked using 
  cat foo.asc | gpgm

Much like PGP.. (gpgm is a version that does not need root privlage to
lock memory)

You can also generate a DSS key and have both your RSA and DSS key
available to GPG for signing, the -u option can select between them.

I am hoping that information like this will help us to adopt gpg and free
algorithms more quickly. With any luck we should be able to eliminate the
use of PGP in the archive checking scripts using instead GPG (which would
finally allow DSS keys to be used for uploads)

As a final note, I have not yet found out the fate of RSA in a years time,
I would hope that it will be moved into the main GPG distribution and
become a fully free algorithm. IDEA won't be, but IDEA is unnecessary for
signatures and GPG can use other ciphers with RSA keys for encryption.

Jason

Re: Release Plans (1999-05-10)

[Branden Robinson]

On Wed, May 12, 1999 at 02:06:24PM -0700, David Bristel wrote:
> It seems to me that since there will always be patches and updates to packages
> between releases, and since we have the "proposed" updates, perhaps we could
> add an "updates" area, in addition to the non-free, contrib, and main 
> sections.
> This would work VERY nicely for users who want to grab the latest patches.  A
> good example of why this would be good is the XFree 3.3.2 being released in
> slink, and everyone wanting 3.3.3.

I am perfectly willing to package a version of XFree86 3.3.3.1 for slink
(and thus built against glibc 2.0), if I can get assurance that these will
be accepted.  Except for the Unix98 pty problem which just popped up with
xterm, and some kind of strangeness with detecting a particular IBM RAMDAC
chip in the I128 X server, reports appear to be that the potato 3.3.3.1
packages are better than the 3.3.2.3 ones in slink in every respect.
Namely, there are several packaging-level bugs that I have fixed in the
potato version of X.  None of these are security matters, however, and that
is typically the sole criterion upon which packages for stable-updates are
judged.

I've been told that this is pretty much Christian Hudon's decision.
Perhaps an exception could be made for X, given that it is so huge and
onerous to download, and requires gargantuan amounts of space and time to
build.  But my feelings won't be hurt if he decides against it.

In the meantime, Johnie Ingram has been making glibc 2.0 versions of my
potato XFree86 packages available at .

-- 
G. Branden Robinson  |Yesterday upon the stair,
Debian GNU/Linux |I met a man who wasn't there.
[EMAIL PROTECTED]   |He wasn't there again today,
cartoon.ecn.purdue.edu/~branden/ |I think he's from the CIA.


pgpasgYQtHADR.pgp
Description: PGP signature

Re: Upload queue software?

[Jason Gunthorpe]

On Wed, 12 May 1999, Roman Hodek wrote:

> > Does anyone know where I can find the software to run a debian
> > upload queue? I thought it was packaged but I can't seem to find it
> > using the obvois searches..
> 
> It's in project/misc/debianqueued-0.8.tar.gz. It's no proper Debian
> package because it runs on other Unixes, too (mine runs under
> Solaris).

Hmm, why does that prevent you from packaging it? :>

Jason

Package to give away/orphan: GNU acct

[Dirk Eddelbuettel]

GNU acct is still broken for 2.2 kernels. I thought a recompile would fix it,
but it doesn't.  The upstream author, with whom I generally had very good
(albeit sporadic) contact is MIA.  AFAICT the other dists don't distribute
acct.

The package needs a kernel hacker type who can debug and hopefully fix it.
Unless someone steps forward to adopt it, I will ask that acct be removed
prior to the release of potato

A bug has also been reported on the installation, but I cannot replicate it
here on a 2.2 machine.

-- 
According to the latest figures, 43% of all statistics are totally worthless.

Re: Release Plans (1999-05-10)

[Julian Gilbey]

[Please restrict your line length to around 70-72 characters, as
otherwise it overruns 80 chars when quoted.]

> It seems to me that since there will always be patches and updates
> to packages
> between releases, and since we have the "proposed" updates, perhaps we could
> add an "updates" area, in addition to the non-free, contrib, and
> main sections. 

Yes, and these patches live in the unstable distribution.  How do you
know that a patch won't (a) cause some other part of the program to
fall over, or (b) cause some other program to fall over (due to some
unforeseen interaction)?  That's why patches and updates only go into
the unstable distribution.  (The sole exception to this is security
updates or other critical bugs which are allowed into stable because
of the serious damage the problem might otherwise cause.)

> This would work VERY nicely for users who want to grab the latest patches.  A
> good example of why this would be good is the XFree 3.3.2 being released in
> slink, and everyone wanting 3.3.3.

Who's everyone?  I'm quite happy with 3.3.2.3a-11 here.  But if you
*must* have 3.3.3, then you can either compile it yourself or move to
unstable.  But with XFree86 being the huge beast which it is, how do
you know whether 3.3.3 might interact in bad ways with other pieces of
software?  That's the purpose of unstable.

> Also, for potato, since it WILL
> be glibc 2.1 
> based, I suspect a large number of people would want versions of
> XFree, gnome, 
> and other packages without having to upgrade their systems.  By setting up an

Should we provide libc5 versions as well for those who are still
running Debian versions pre-2.0?  (My department have machines running
1.2 and 1.3 and are now planning to "upgrade" to Red Hat 5.2 :-( .
And they wanted XFree86 3.3.3, so they downloaded it and compiled it
themselves.)  I think that it is quite enough work for the developers
to ensure that two versions work as well as possible (stable and
unstable, and even sometimes frozen), without expecting them to work
on a random mix of packages from different versions.  GNOME has been
discussed in other mails, but for the other stuff, it seems quite
reasonable to expect those people who are desperate to download the
binaries directly from XFree86's site, for example.

> extension to our current directory structure for updates, we make it
> VERY simple 
> for people to add these in.  I THINK it might also make it easier to release
> maintenance releases in this manner.  Simply have all the updated packages in
> the updates section.  If apt and dselect do their jobs, it should grab the
> proper NEWer version of the package.

Yes, it would make it much easier to have interim releases, but the
stability is guaranteed to suffer.  And as the stated purpose of
stable is to be just that: stable, it is not reasonable to put routine
upgrades of individual packages in stable.  There is a new release of
Debian approximately every six months: those people who cannot wait
that long are welcome to live on the unstable distribution.

   Julian

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

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
 Debian GNU/Linux Developer.  [EMAIL PROTECTED]
   -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-