kernel packages skeleton

[Wichert Akkerman]

I've finally gotten around to making a simple skeleton for packaging
kernel modules. When I have some more free time I'll expand it a bit
and write some documentation to go with it. Oh, and I might test it
since it's currently completely untested :).

Anyway, for the interested the files are at
http://www.wi.leidenuniv.nl/~wichert/debian/

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/


pgp7jR7peuHNj.pgp
Description: PGP signature

Re: kernel packages skeleton

[Joey Hess]

Wichert Akkerman wrote:
> I've finally gotten around to making a simple skeleton for packaging
> kernel modules. When I have some more free time I'll expand it a bit
> and write some documentation to go with it. Oh, and I might test it
> since it's currently completely untested :).
> 
> Anyway, for the interested the files are at
> http://www.wi.leidenuniv.nl/~wichert/debian/

I wrote up some basic docs on this a while ago and gave them to Manoj. here
they are again.

Kernel-package add on modules from the packager's perspective.
-

This explains how you, a developer, can integrate your package with
kernel-package, so when the user runs "make-kpkg modules_image",
kernel-package builds your kernel modules.

First, you need to make your package pack up its _source_ into a .deb file.
When this .deb is installed, it should place the source in
/usr/src/modules/, or something similar. Or it can just install a
tarball in /usr/src/ that the user must manually unpack. There are
advantages and disadvantages to both approaches.

When the user runs make-kpkg, kernel-package looks at all
the directories in /usr/src/modules/. It cd's into each of them, and runs
"./debian/rules ". The rest is up to you; your debian/rules file
must provide the various targets kernel-package calls, which are:

  a) kdist_image  Compiles the modules and generates a .deb file containing 
them.
  b) kdist_configure  Configures your package.
  c) kdistGenerates the .deb, and also generates a .changes file
 so the package may be uploaded.

Additionally, the following information is provided in the environment to
your debian/rules:
  a) KVERS  Contains the kernel version
  b) KSRC   Contains the location of the kernel sources 
  c) KMAINT Contains the Name of the maintainer to pass to PGP
  d) KEMAIL Caontains the email address of the maintainer

You typically want to put the .deb file you create in $(KSRC)/.. , which is
typically /usr/src, but may be something different.

You should encode the version of the kernel the modules are built for in the
package name, so you might use somthing like "_$(KVERS)" as the
package name.

KMAINT and KEMAIL should be used in the .changes file generated by the kdist
target.

-- 
see shy jo

Re: User-selected window-manager in an easy way

[Wichert Akkerman]

Previously Stig Sandbeck Mathisen wrote:
> ssh-add is already started from /etc/X11/Xsession, if you have ssh
> installed. Other than that, you're right, of course.

Actually ssh-agent is started.

> I was thinking of some simple, global solution, available from the menu. I
> suspect that "simple" and "global" does not belong together on this issue.
> It might need some more thinking.
 
Make a menu option which calls a script similar to the following:

--
#! /bin/sh

TMPFILE=`tempfile`
wmlist="/etc/X11/window-managers"
xsession=$HOME/.xsession

options=`sed -ne '/^[^#]/s#.*/\(.*\)#\1 ""#p' $wmlist | sort -u`

whiptail --title "Select windowmanager" --fb --noitem \
--menu "Make your choice" 15 50 5 $options 2>$TMPFILE
result=`cat $TMPFILE`
rm $TMPFILE
cat < $xsession
#! /bin/sh
`grep $result $wmlist`
EOF
chmod 755 $xsession

--

(this needs some changes: check if you don't overwrite a non-generated
.xsession for example, or use gdialog instead of whiptail if available,
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/


pgpLlIZa6zuST.pgp
Description: PGP signature

Re: Current problems with libc6_2.1.1-2

[Michael Beattie]

On Mon, 10 May 1999, Branden Robinson wrote:

> On Mon, May 10, 1999 at 09:58:16AM -0400, Collins M.  Ben  wrote:
> > glibc 2.1+ in potato is going to require a 2.2 kernel so this wont help.
> > To be honest I am not sure how you passed the preinst phase since it
> > should fail to even unpack the glibc 2.1.1. I'll look into why that
> > happened.
> 
> What?
> 
> Linux apocalypse 2.0.36 #1 Mon Nov 16 21:24:03 EST 1998 i586 unknown
^^

 
> ii  libc6   2.1.1-3GNU C Library: Shared libraries and 
> timezone
> 
> Is my machine a ticking time bomb or something?  Will it not boot up next
> time I have to reboot?


Well.

 Michael Beattie ([EMAIL PROTECTED])

   PGP Key available, reply with "pgpkey" as subject.
 -
   CONNECT 300...   Connect 300?!?!?! #%^# NO CARRIER
 -
Debian GNU/Linux  Ooohh You are missing out!

Re: install report for Debian 2.1 and some comments on installation profiles

[Martin Bialasinski]

>> "EZ" == Enrique Zanardi <[EMAIL PROTECTED]> writes:

EZ> with its changelog, control file, rules file and so on...). That
EZ> may probably be fixed by implementing a debhelper tool just for
EZ> building metapackages.

This is exactly the thing the equivs package will do.

Ciao,
Martin

Re: Freeze stuff, summary.. (perl 5.005, etc)

[Dirk Eddelbuettel]

  Adam>  It wouldn't hurt but I don't think it's necessary. glibc2.1 can
  Adam> drop-in replace 2.0 (unless you have a program that depends on
  Adam> certain internal stuff which it shouldn't be using anyway).

Octave doesn't depend on internal stuff, but still fails when a glibc2.0
compiled version is used under glibc2.1. The bug can be reproduced by the
program below which, like Octave, segfault under 2.1 when compiled under 2.0.
It is due to some C++ streams <-> libc io issue.  The bugs have been
reassigned to libc6, but I haven't heard anything yet.


#include 
#include 

int
main (void)
{
  ostrstream buf;
  for (int i = 32; i < 127; i++)
buf << (char) i;
  buf << endl;
  buf << ends;
  cout << buf.str ();
  return 0;
}





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

Re: install report for Debian 2.1 and some comments on installation profiles

[Adam Di Carlo]

Martin Bialasinski <[EMAIL PROTECTED]> writes:

> This is exactly the thing the equivs package will do.

Does equivs implement this through skullduggery, or does it make nice
metapackages which play nice?

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

Re: install report for Debian 2.1 and some comments on installation profiles

[Adam Di Carlo]

Enrique Zanardi <[EMAIL PROTECTED]> writes:

> > Voila.  Elegant, uses the existing packaging system (i.e., no need to
> > skip the select step in dselect),
> 
> This is the main point against your approach. We introduced the tasks and
> profiles to avoid going through the list of 3000 packages in dselect. It
> could be a nightmare to find those new metapackages in that huge list. 

You misunderstand.  You could still have the *identical* metapackage
selection interface presented to the user as we currently have.
However, it would simply mark the metapacakges for installation,
rather than a ton of "atomic" (i.e., normal packages).

The select step could be either skipped or not skipped.

Any good package installation method (um, well, only apt is this good
I guess) would automatically pull in dependancies.

So I guess a weakness of my scheme is that it presupposes apt and only
apt.  Or else the user needs to go through the "[S]elect" step.

> Don't get me wrong, I like the idea of using metapackages, but those
> metapackages must be shown in a different level/screen on our package
> selection tools (gnome-apt, dselect, whatever...). Until our tools are
> modified to do that, I guess metapackages won't be that useful.

There's no reason this could not be adopted to metapackages, where it
now uses, ahem, "proprietary" text files.

> Another point against metapackages is that it's trivial for a new user
> to make a new "task" (it's just a list of packages, one name on each
> line)

I would hardly call that trivial.  They might as well just go into
dselect and pick out the pkgs they want.  Moreover (and this is the
primary weakness), the current system completely ignores internal
archive dependancies, i.e., those have to be manually satisfied by the
tasks.

> but it's not so easy to make a metapackage (it's a deb package,
> with its changelog, control file, rules file and so on...). That may
> probably be fixed by implementing a debhelper tool just for building
> metapackages.

Well, as someone pointed out, equivs fulfills this function.

> > Another nice benefit to my scheme is that each task/profile can be
> > maintained independantly by different Debian developers.  In fact, I
> > volunteer to take over the SGML environment task if we do move to this
> > scheme.
> 
> Why wait? You can build that metapackage now, and we may use it as a
> "test case" to see if any strange problem arises. A "gnome" metapackage
> would be a nice one too. Volunteers?  

Ugh, I guess I volunteered myself.  Well, not biggie -- I've been
maintaining an sgml metapackage internally for onShore for months now.

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

Re: install report for Debian 2.1 and some comments on installation profiles

[Martin Bialasinski]

>> "ADC" == Adam Di Carlo <[EMAIL PROTECTED]> writes:

ADC> Martin Bialasinski <[EMAIL PROTECTED]> writes:
>> This is exactly the thing the equivs package will do.

ADC> Does equivs implement this through skullduggery, or does it make
ADC> nice metapackages which play nice?

Well, It could be extended, but I hope, I have written it nicely.

$ cat /usr/doc/equivs/examples/webserver.ctl 
Section: web
Package: webserver-dummy
Provides: httpd
Description: Webserver dummy package
 This package provides dpkg with the information that
 there is a local webserver installed.
 .
 Installing dwww, man2html etc. won't bug you to
 install apache any more

$ make-equivs /usr/doc/equivs/examples/webserver.ctl 
[creates the package]

$ dpkg --info webserver-dummy_1.0_all.deb 
 new debian package, version 2.0.
 size 2258 bytes: control archive= 538 bytes.
 390 bytes,14 lines  control  
 211 bytes, 3 lines  md5sums  
 Package: webserver-dummy
 Version: 1.0
 Section: web
 Priority: optional
 Architecture: all
 Provides: httpd
 Installed-Size: 8
 Maintainer: Martin Bialasinski <[EMAIL PROTECTED]>
 Description: Webserver dummy package
  This package provides dpkg with the information that
  there is a local webserver installed.
  .
  Installing dwww, man2html etc. won't bug you to
  install apache any more

Basically the controlfile used by make-equivs is a usual control file
(I fil in default values, if fields are not present [like maintainer
in theis example]).

So you could just place a appropriate Depends: header, any there you
go.

As the package tree is not deleted, one can also use equivs to quickly 
create a vaid tree, change some files like the README and do a
debuild.

If there are specific things to add to equivs to create the
metapackages, I will happily add them. 

The netscape metapackages in unstable are a good thing. no need to
hunt down all the packages with the right versions.

I also really like to see a GNOME metapackage like this.

Ciao,
Martin

A setuid bash doesn't give up root.

[Karl M. Hegbloom]

I've discovered something interesting.

# cp /bin/bash /tmp
# chmod u+s /tmp/bash

$ /tmp/bash
$ whoami
karlheg

# cp /usr/bin/zsh /tmp
# chmod u+s /tmp/zsh

$ /tmp/zsh
# whoami
root

 Perhaps we should have a policy that says all of our shells should
 follow the Bash behaviour?

Re: A setuid bash doesn't give up root.

[Ben Gertzfield]

> "Karl" == Karl M Hegbloom <[EMAIL PROTECTED]> writes:

Karl>  Perhaps we should have a policy that says all of our shells
Karl> should follow the Bash behaviour?

This would help a *tiny* bit, but there are many many programs other
than shells that will wreak havoc if they're made set-uid. Emacs, or
vi, or netscape.. well, you get the drift.

-- 
Brought to you by the letters D and M and the number 18.
"Bill Gates is a talented evil man."
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: Perl 5.005 stability

[Chip Salzenberg]

According to Aaron Van Couwenberghe:
> On Sun, May 09, 1999 at 08:14:24PM -0700, Jim Lynch wrote:
> > This means that upgrading perl (whenever it is done) will need the same 
> > degree
> > of care applied as for dpkg, dselect, boot-floppies, debian-cd and all other
> > essential parts of debian infrastructure, and -not- that of "just another 
> > app".
> 
> You forget to mention some important points -- those new features in perl
> 5.005 are both underdeveloped and buggy.

The only part of Perl 5.005 that could be described as "underdeveloped
and buggy" is the threading.  So I wouldn't suggest that Debian's
default Perl have threading enabled.  Otherwise, though, 5.005 is
plenty stable -- it's on its third maintenance patch.

All IMO, of course.  But I am one of the core Perl developers, so my
opinion is at least educated.
-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
  "When do you work?"   "Whenever I'm not busy."

Re: Perl 5.005 features

[Chip Salzenberg]

According to Michael Stone:
> The only thing [new in Perl 5.005] I've heard so far is threading,
> which AFAIK is too unstable to be in stable.

Agreed about threading.
But the list of New Stuff also includes:

  * References as thrown exceptions ('die $object', '[EMAIL PROTECTED]>method')
  * Pseudo-hashes (fast hash-like behavior from arrays)
  * Closely related to the above: 'use fields' pragma
  * Significantly smarter regexes and the qr// quoting mechanism
  * Global keyword overriding with CORE::GLOBAL::keyword
  * Tied arrays are complete; tied handles are more complete
  * $/ can be used for fixed-length records ('$/ = \80')

And some guts things:

  * More robust embedding support (for e.g. mod_perl)
  * Numerous core dump bugs fixed, largely through the internal
feature known as "stack of stacks"

Don't get me wrong; as the father (or at least midwife) of Perl 5.004,
I think it's a great program.  But 5.005 has much to recommend it, too.
-- 
Chip Salzenberg  - a.k.a. -  <[EMAIL PROTECTED]>
  "When do you work?"   "Whenever I'm not busy."

Re: Release Plans (1999-05-10)

[Joseph Carter]

On Mon, May 10, 1999 at 12:33:45PM -0500, Ossama Othman wrote:
>  >   * GNOME
>  > I wasn't there to see it, but I hear that the GNOME staging area has
>  > now been folded into potato and is ready for the freeze.
> 
> It has.  However, there are still some packages that may not have made
> it in to the archive that need to be in there (e.g. libgtop1,
> libghttp1).  I posted to the debian-gtk-gnome list about this issue but
> haven't received a response yet.

Not to mention that imlib has this tendancy to core frequently if it
doesn't like the image it's getting fed

--
Joseph Carter <[EMAIL PROTECTED]>Debian GNU/Linux developer
PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First!
-
 red dye causes cancer, haven't you heard? (;
 fucking everything causes cancer, haven't you heard?
 =>
 no, that causes aids


pgpKNhApvLhvQ.pgp
Description: PGP signature

cdgrab on hold? read this (Re: Intent To Package: cd-discid)

[Robert Woodcock]

On Fri, May 07, 1999 at 09:06:27PM -0700, Robert Woodcock wrote:
> Hmmm, now that I've uploaded cd-discid I guess I better write an intent to
> package for it :)
> 
> cd-discid has long been bundled in cdgrab, but since cdgrab changes so much
> more quickly, and is a simple shell script, the other architectures don't
> get updated versions of it as quickly as desired. cd-discid is a package
> that won't change as often.
> 
> So, now cd-discid is in its own package, putting cdgrab in binary-all where
> it belongs. It has also been rewritten to not use libcdaudio, at the expense
> of 44 more lines of code, bloating this copy to an alarming 95 lines.

One thing I forgot was dinstall isn't instant for new packages, and
cd-discid is still in Incoming. For those of you wanting to try out cdgrab,
or for those of you pondering a message like this:

The following packages have been kept back
  cdgrab

This is whatcha do:

wget http://frantica.lly.org/~rcw/cd-discid/cd-discid_0.2-1_i386.deb
wget http://frantica.lly.org/~rcw/cdgrab/cdgrab_0.7-1_all.deb

dpkg -i cdgrab_0.7-1_all.deb cd-discid_0.2-1_i386.deb
-- 
Robert Woodcock - [EMAIL PROTECTED]
"Now we'll have to kill you." -- Linus Torvalds

Intent to package t-gnus

[Takuro KITAME]

Hi,I'm packaging software, t-gnus.
(ftp://ftp.jaist.ac.jp/GNU/elisp/chamonix/gnus/)

t-gnus is latest branch of Semi-gnus.
Semi-gnus is "Replacement of Gnus with gnus-mime for SEMI."
and Debian package is available. (main/news).

SEMI is "Library to provide MIME feature for GNU Emacs."
Debian package is available. (main/mail).


From README:

* New codename: "T-gnus"

  In order to distinguish "ichikawa" branch from other branches, codename
  was changed to "T-gnus" , gnu with T-Shirt.

* New Features

  Use T-gnus in offline(Unplugged) status using gnus-offline.
  T-gnus have also features that have "shuhei-k" branch, "chao-6_9" branch
  , "keiichi" branch and the MainTrunk.



Liesence: GPL

Replaces: gnus, semi-gnus
Provides: gnus, semi-gnus, news-reader, mail-reader
Depends: emacsen, custom | emacs20 | xemacs20, apel, flim, semi | wemi
Conflicts: gnus, semi-gnus


Regards.

-- 
Takuro KITAME

Re: Homapages in list of maintainers

[Atsuhito Kohda]

From: Adam Di Carlo <[EMAIL PROTECTED]>
Subject: Re: Homapages in list of maintainers
Date: 10 May 1999 15:02:11 -0400

> Yes, well, it takes from 4 weeks to 6 months or longer for *all*
> people.  I agree this should be shorter...  Anyhow Debian-JP is *not*
> getting singled out.  Everyone has this issue.

Yes, of course this is general issue, not specific to Debian JP.
But this is still a BIG problem to be pointed out.

> There is no requirement that I know of that any identification must be
> written in English.

It is practically very important to know what is acceptable and
what is not as identification. Does this mean Japanese driver's
license (written completely in Japanese) is acceptable in real ?

# If so, I will stop the plan to obtain my passport for the certification.

> IF there's not way the guy can get a phone call, I'm afraid there's no
> way they can be confirmed and become a developer.

Well, of course he has a way to get a phone call, but

> I mean, common sense, people.

by your common sense which has practical meaning in the process
of verification for Japanese candidates

- communication on a phone between foreigners short on substance, or
- communication on a phone between Japanese with much more substance

under the condition that there are highly trustable people in Japan :-)

By the way, there are about 50 (local) maintainers in Debian JP and
among them, there are already eight official maintainers.

Thanks in advance,  1999.5.11

--
 **
 Atsuhito Kohda
 Dep. Math., Tokushima Univ.
 [EMAIL PROTECTED]

Re: Homapages in list of maintainers

[Atsuhito Kohda]

From: John Lapeyre <[EMAIL PROTECTED]>
Subject: Re: Homapages in list of maintainers
Date: Mon, 10 May 1999 13:26:29 -0700

>   I think it would be great for Debian JP and Debian to find someone
> in Japan who can do interviews in Japan and report to the new-maintainer
> people in Debian proper (in Europe or U.S.)  That is to say, it would
> be good to have a new-maintainer person located in Japan.
> This could speed up the process and improve communications.

This is the main point that I want to discuss. The above method,
which I also proposed several days ago, is the most practical,
efficient and reliable solution, I believe.

Official maintainers of Debian JP have already much information on
the reliability, ability and identity of the candidates from Debian JP
through their activity in Debian JP. So he can communicate much more
details on a phone call with candidates and if necessary he can
report the results to members of new-maintainer with e-mail which is
much easier than with a phone call for Japanese.

But members of new-maintainer team in (for example) the U.S. get such
information only through a phone call which may result short on substance
because of language problem.

Which is more reasonable ?

Thanks in advance,  1999.5.11

--
 **
 Atsuhito Kohda
 Dep. Math., Tokushima Univ.
 [EMAIL PROTECTED]

Re: Release Plans (1999-05-10)

[Raphael Hertzog]

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 ?

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

Re: Pandora is born

[Heiko Schlittermann]

On Mon, May 10, 1999 at 03:33:54PM -0700, Joseph Carter wrote:
: > > Um, non-us has been terribly broken since BEFORE I was a developer.  In
: > > fact, it was broken when I first installed Bo a year and a half ago.
: 
: And the biggest rub of all has been that the archive maintainers couldn't
: do anything about the problems.  They would have liked to.

The maintainers that wanted to help (Richard (?) and Guy) had and have
the same archive access as me.

And as far as I can remember -- the problem were in order of occurence:

- backlog in incoming (yes, was not solved for a long time)
- archive layout similar to the main archive (not yet solved -- some 
coordination needed)
- downtime (due to broken hardware - has been solved with a donated
  harddisk (paid by me with donations from selling Debian CDs))
- archive access for archive maintainers (not solved for a long
  time due to administrative restrictions -- would have been solved
  if we had have a new, separate machine ... you know, where the machine is
  now)


Best Regards from Dresden/Germany
Heiko
-- 
[internet & unix support - Heiko Schlittermann]
[http://debian.schlittermann.de/";> Debian 2.1 CD ]
[Heiko Schlittermann HS12-RIPE finger:[EMAIL PROTECTED] -]
[pgp: A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 ---]

Re: Intent to package t-gnus

[Adam Di Carlo]

Takuro KITAME <[EMAIL PROTECTED]> writes:

> Hi,I'm packaging software, t-gnus.
> (ftp://ftp.jaist.ac.jp/GNU/elisp/chamonix/gnus/)
> 
> t-gnus is latest branch of Semi-gnus.
> Semi-gnus is "Replacement of Gnus with gnus-mime for SEMI."
> and Debian package is available. (main/news).
> 
> SEMI is "Library to provide MIME feature for GNU Emacs."
> Debian package is available. (main/mail).

Are these two JP specific?  I noticed from your uploads that the
install fails if LANG is unset or set as "C".  This kinda warned me
that maybe it wouldn't work for english?

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

Re: Homapages in list of maintainers

[Adam Di Carlo]

Atsuhito Kohda <[EMAIL PROTECTED]> writes:

> From: Adam Di Carlo <[EMAIL PROTECTED]>
> > There is no requirement that I know of that any identification must be
> > written in English.
> 
> It is practically very important to know what is acceptable and
> what is not as identification. Does this mean Japanese driver's
> license (written completely in Japanese) is acceptable in real ?
> 
> # If so, I will stop the plan to obtain my passport for the certification.

I would hope that we could accept official Japanese identification.
I'd have to leave it up to James to say for sure.

> by your common sense which has practical meaning in the process
> of verification for Japanese candidates
> 
> - communication on a phone between foreigners short on substance, or
> - communication on a phone between Japanese with much more substance
> 
> under the condition that there are highly trustable people in Japan :-)
> 
> By the way, there are about 50 (local) maintainers in Debian JP and
> among them, there are already eight official maintainers.

Yes -- it really sounds like we need a native Japanese new maintainer
processor, or at least someone fluent.  I hope this *does* happen but
it may take a while to happen.  Remember that approving new maintainer
is a very _sensitive_ area -- I know James is a little (justifiably)
paranoid about delegating this to others.

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

Re: RFC: debhelper v2

[dirson]

About debian/tmp and friends:  something I'd like would be to run make 
install on some dir like debian/INSTALL/, and have dh_movefiles take
files from this one.  This would provide greater consistency between
binary packages (get rid of this concept of "main package"), and
simplify things when moving some files from an "Arch: any" to an
"Arch: all" package (no need to change debian/rules lines, just move
them).

--
  /\   Yann Dirson<[EMAIL PROTECTED]>
 \\ \
\ \\ / Sun Microsystems Inc.   
   / \/ / /Consumer and Embedded / ChorusOS Support
  / /   \//\
  \//\   / /   Phone: +33 139 44 74 50
   / / /\ /Phone: 44450   
/ \\ \
 \ \\
  \/   Subcontractant from Logatique  

Re: Pandora is born

[Christian T. Steigies]

Hi,
several of my uploads to non-us have been processed last night. Now I have
only one question, were have the uploads landed? I mean, I am very happy
that I got confirmation messages, but now I have REJECTED:
 Rejected: gnupg_0.9.5-1_m68k.deb: Old version 9.5-1' >= new version  9.5-1'.
but I cant find it on nonus in Incoming/REJECTED?
And what does this mean:
 (new) pgp-us_2.6.3a-5_m68k.deb optional non-us/utils
 WARNING: Already present in non-free distribution.
I got this kind of message for several pacakges. This is wrong, isnt it?

Ciao,
Christian.

Here's my .xsession (was Re: User-selected window-manager in an easy way)

[jim]

Here's my .xsession... it assumes the window manager is not the session
controller, and something else is (but that can be changed pretty easily)

---

file: .xsession

---
#!/bin/bash

#
# logout button .xsession allowing fav window mgr by Jim Lynch
#
# This .xsession prepares for gnome by having something other than
# the window mgr be in the foreground, such as a logout button.
#
# As always, when the foreground process goes away, the session ends.
# This is true whether the fore is a wm, a logout-button or a session
# manager separate from the wm.
#
# This .xsession has logout-button be the foreground process. Pushing the
# logout button causes the logout button process to end, which implies 
# the .xsession foreground process ends, which ends the session.
#
# This .xsession will also launch xearth and an xterm.

# Now find a window manager... we want one that's installed... run it...

# start by assuming that before we start looking, we haven't found anything
foundWM=false

echo "1 $foundWM"

# Favorite window manager

# set this to your favorite WM, or to nothing if you're willing to accept
# whatever comes
myWM=fvwm2

if [ "$foundWM" = "false" ]
then
favWM=`grep $myWM /etc/X11/window-managers | head -1`
aWM=`echo $favWM | sed 's/#.*//'`

if [ -x "$aWM" ]
then
theWM=$aWM
foundWM=true
fi
fi

echo "2 $foundWM"

if [ "$foundWM" = "false" ]
then
if [ -e /etc/X11/window-managers ]
then
for i in `sed 's/#.*//' /etc/X11/window-managers`
do
if [ -x $i ]
then
theWM=$i
foundWM=true
break
fi
done
fi
fi

echo "3 $foundWM"

# still didn't find a wm?? OK, twm isn't the best, but we'll settle

if [ "$foundWM" = "false" ]
then
theWM=twm
foundWM=true
fi

echo "4 $foundWM"

# launch the selected or otherwise found window manager in the background.

$theWM &

# launch xearth and an xterm.
xearth &
#xfishtank &
#xterm -ls &

# launch the session-controlling process. If it dies, so does the session.

#exec logout-button
exec gnome-session

# end of .xsession

# Here's the original .xsession

# #!/bin/bash
# 
# # NOTE: this part taken from the else part of the final "if"
# # in the global /etc/X11/Xsession by [EMAIL PROTECTED]
# #
# # i.e., look at this code as the default behavior and
# # modify to taste
#
# xterm -ls &
# if [ -e /etc/X11/window-managers ]; then
#   for i in `sed 's/#.*//' /etc/X11/window-managers`; do
# if [ -x $i ]; then
#   exec $i
# fi
#   done
# fi
# exec twm
---

Re: Release Plans (1999-05-10)

[Chris Lawrence]

On May 10, Hartmut Koptein wrote:
> > There's also another thing that need to be worked on, the CDs. The
> > script creating the images is not smart enough to select just the
> > good number of packages for each CDs. Currently, the two binary CDs
> > can still be generated for potato but not the source images (they are too
> > big). And many dependencies on the first CD are not met.
> 
> For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). 

slink-cd makes HFS hybrid CDs for m68k already; I'm pretty sure I
asked Steve to use the HFS options for PowerPC too (so the code's
already there...)


Chris
-- 
=
|Chris Lawrence| The Linux/m68k FAQ |
|   <[EMAIL PROTECTED]>   |   http://www.linux-m68k.org/faq/faq.html   |
|  ||
|Amiga A4000 604e/233Mhz   | This address has been spam-proofed.|
| with Linux/APUS 2.2.3|  All spam goes to your postmaster. |
=

Re: Homapages in list of maintainers

[Keita Maehara]

At Mon, 10 May 1999 13:26:29 -0700,
John Lapeyre <[EMAIL PROTECTED]> wrote:

>   By the way,  I want to see ruby packaged !   I hear that
> it is already packaged for Debian JP.  I ran the fibonacci test in the
> source and it really beat perl badly.  I even improved the perl version
> and ruby still won.  

The ruby packages is just suffering from the problem (I'm not
criticizing the new-maintainer members. I really respect them and
their jobs). The Debian JP maintainer of the ruby packages is waiting
for the answer from new-maintainer members. He'll do them as soon as
he'll be registered as a official Debian developer.

The current Debian JP version is available from:

ftp://ftp.jp.debian.org/debian-jp/
dists/potato-jp/main/binary-i386/interpreters/

-- 
Keita Maehara <[EMAIL PROTECTED]>

Re: Release Plans (1999-05-10)

[Hartmut Koptein]

> > For m68k-mac and powermac we need 'hybrid' cd-images (msdos + hfs). 
> 
> slink-cd makes HFS hybrid CDs for m68k already; I'm pretty sure I
> asked Steve to use the HFS options for PowerPC too (so the code's
> already there...)

Great! One point i can strike off from my todo list. Thanks.

Re: Wish to orphan or kill: dbuild; Or: Is it of any actual use?

[Sven LUTHER]

On Tue, May 11, 1999 at 11:06:22AM +, Lars Wirzenius wrote:
> My nightly dbuild cron job has started to fail. I haven't had time to
> investigate why, and before I allocate the time, I'd like to offer the
> package for someone else to maintain and run. I don't have the
> time to do a good job on it: either for developing the script itself
> (it has needed a rewrite for a long time, preferably in a better
> language than /bin/sh) or for running it on a Debian source
> mirror and examining the results.
> 
> Dbuild is a tool for unpacking Debian source packages and
> building Debian binary packages from them. It has competition:
> the buildd daemon that is actually being used to compile many
> of the architectures being worked on by Debian. Unlike dbuild,
> buildd actually works well. :)
> 
> Because of this situation, before anyone else adopts the
> package, the question should be asked whether there is any
> point in keeping the package alive. Specifically: Is anyone using 
> dbuild?

Don't, ...

i actually use dbuild quite often to recompile packages, sure i am not
aware of other posibilities, (does buildd have a package ? can it be
used interactively, and not as a demon ?). It is very nice stuff, and
works quite well, despite its shortcommings.

i just type dbuild package.dsc, and it compiles me the package, i like
it much ...

but not much time to adopt it ... :(

Friendly,

Sven LUTHER

Re: Install-time byte-compiling: Why bother?

[Martin Mitchell]

<[EMAIL PROTECTED]> writes:

> Chris Waters writes:
> 
> > I *strongly* oppose eliminating it, and I'm not real big on the idea
> > of making the default be "off".  Installing new packages takes a
> > while, I don't mind a few extra moments there.  I *do* mind run-time
> > delays, even if they're small,
> 
> There is always a delay; this is unavoidable.  The question is how big
> the delay is.
> 
> Run-time compilation of elisp would slow things down slightly.  In
> many cases if you didn't time it, you wouldn't even notice.
> 
> I know what I think is better for the novice!

I agree with Chris, and also oppose eliminating install time byte-compilation
by default. Actually I think the current system works well in general.

Martin.

Re: Wish to orphan or kill: dbuild; Or: Is it of any actual use?

[Roman Hodek]

> does buildd have a package ?

Not yet. James is working on it, but it's not trivial and may take
some time (and James and James<2> are constantly low on spare time :-)

> can it be used interactively, and not as a demon ?

Yes and no :-) buildd itself is non-interactive, of course, but it
uses a script sbuild for the actual unpacking and compiling, and
sbuild is rather similar in purpose to dbuild, with the addition that
it can also fetch source packages from different locations and that it
knows about source dependencies.

Roman

Uploaded new package: yada

[Charles Briscoe-Smith]

I've now uploaded a packaged version of YADA, the packaging helper
which I RFCed you about a couple of weeks ago, and which surprisingly
(to me, anyway) got a mention in Debian Weekly News.  Woo!

Lots of random thoughts follow.  Let me know if you have comments.  If
you're willing for the comments to be public, please submit them as
wishlist bugs against "yada"; it'll make it easier for me to be sure I
don't overlook them.

Some of the comments I got already:

 - Why do I have to write ../configure when I mean ./configure?  That's
   stupid.

Yes, I suppose it was.  It's now fixed so that an initial dot is
stripped only from lines containing only dots.  Hopefully this makes
more sense.

 - If you're trying to make your packages file like an RPM spec file,
   why don't you put the changelog in there too?  RPM does that.

Because I'm not trying to make it like an RPM spec file - I've never
packaged anything using RPM, or even looked very deeply at it, so any
similarity is (mostly) coincidental.  I really think the package
changelog is one meta level "up" from the stuff in debian/packages, so
I don't put it in debian/packages.  Besides, I don't want my packages
file growing without bound.  Think about it; eventually, you'd have to
scroll past miles of changelog before you got to the meat of your
packages file.  There are tools to edit debian/changelog easily, anyway
- Emacs modes and such (not that I use them).  They wouldn't work if
the changelog was embedded in another file.

I might consider making it optionally possible to put the changelog in
debian/packages, if there's the demand, but I still wouldn't advise
anyone to use that feature.

 - How do I easily create lots of directories under $ROOT?

I didn't think of that, since I normally install everything in my
packages "by hand", disregarding the upstream "make install"; using
"yada install" for this, you don't have to explicitly create
directories.  When I do use "make install", it usually creates all the
necessary directories itself, so I rarely need to create directories
explicitly.  If this is a problem, I'll work something out; see "For
the future" below.

 - Why do I have to put yada in my debian directory?

'coz it was easier to do it that way while I was writing it.  Nobody
had yada installed, and I didn't want to break all my source packages
for everyone else.  Also, yada's likely to change a lot as I work out
how it should work, and this will make sure the version used to build
your package is the same as the version that generated your
debian/rules.

I hope I'll eventually be able to allow either way, so that you can
hack your own copy and put it in debian/, or use the installed
version.

 - Package it!

All right, all right!  ;)

 - You should allow commands starting with "-" to fail like make does.

Good idea.  I was toying with the idea of a new script type, "make",
which would, amongst other things, allow this (and which would result
in prettier generated rules files).

 - Why do I need to write a description for the source package, too?

The source package description field isn't really what it says it is.
The first line is used in the copyright file, as the title of the
package; the rest is tacked onto the start of the description of each
binary package.  Mostly, you'll want to have no description for the
source package, apart from the one-line title.

At least two people seem to have misunderstood the source description
field.  I should really split it into two fields, perhaps "Title:" and
"Description-Prefix:" (or "Common-Description:") or some such.

 - Why is "Major-Changes:" required?  Sometimes there aren't any.

The reason it's required is to make you think about whether there were
any changes worth documenting.  If there aren't, leave the field
blank.  I never used to mention any changes in the copyright file,
because I didn't remember.  I hope yada will remind me.

If the package is native, "major-changes" isn't required (I hope).

 - You should do something about init.d scripts.

Indeed.  One idea I was sent was to have fields called "Init-Start:",
"Init-Stop:" and so on.  The init.d script would be built out of these,
and update-rc.d called at the appropriate points.

Changes to yada since the version in
http://master.debian.org/%7Ecpbs/yada/:

 * Packaged and released.
 * More consistent handling of fields with empty first lines.
 * If the copyright licence of the package isn't standard, the first
   line of the "Copyright:" field should now be a single dot, rather
   than being empty.
 * I thought that install-docs could cope with several documents in one
   doc-base file.  It can't.  Yada now looks for "Document:" tags
   within the doc-base field, splits up individual doc-base files, and
   calls install-docs for them each separately.
 * Bomb out if we see an unrecognised field in debian/packages.
 * "yada install -script" added (equivalent to "-bin -unstripped") to
   ease installing of binaries without having them auto

Help Wanted

[Nils Lohner]

  As many of you know, I'm currently the Debian Press Contact.  
Unfortunately, I've had less and less time to work on press and publicity 
related issues lately as other things (SPI work and 'real work') have come 
to to the forefront, as well as a move next month.  I'm looking for help in 
dealing with requests coming into the [EMAIL PROTECTED] address (not too 
much, maybe a mail or two a day at present).

  The help I'm looking for is people to deal with some of those emails, and 
also to help with other publicity related work- helping write Debians 
publicity materials, organizing and/or coordinating shows, writing articles 
for debian-news, posts for debian-announce, etc.

  Some familiarity with Debian is needed to do this work, but I'll be around 
to answer questions and help people as needed.  If anyone is interested, 
please subscribe to the debian-publicity mailing list, and drop me an email 
telling me what you are interested in doing.

This is a great opportunity to look into the public relations side of an 
organization, and so far has given me a lot of experience in dealing with 
the press, and in the publicity field in general.  This 'job' is basically 
what you make of it- if you're interested in doing something publicity 
related, you can just do it.  Plus, you get your name on /. every now and 
then (and not just with a 'First Post!':)

Thanks, Nils.

-- 
Nils Lohner E-Mail: [EMAIL PROTECTED]
Debian Press ContactPress:  [EMAIL PROTECTED]

request for package

[Wichert Akkerman]

Can someone please package plib, which is Steve's Portable Game Library.
It has a LGPL license so it can go into main without problem.

The reason I want this is so I can try `Tuxedo T. Penguin, A Quest for
Herring' (http://www.woodsoup.org/projs/tux_aqfh/). If someone can
package that as well I'ld be really happy :)

Wichert.



pgpNxkuloUB8A.pgp
Description: PGP signature

a Chinese version of X-window system for Linux available

[liug]

Dear Sir,
I am not sure whether this is the right place to post
this mail.
We have developed a Chinese version of X-window system
several years ago, and now we have developed one for
Linux, 
It is fully compatible with X11R6, including a Chinese
IME(Input Method Editor).
This Chinese version can handle simplified Chinese
(GB: used in mainland of China)
as well as traditional Chinese (BIG5: used in Taiwan
and Hongkong).
We integrated Chinese-support into X-window system in
the way
that all applications built upon Xlib will become
Chinese-aware with
little modification. Our Chinese IME has more than 6
kind of input methods
built in, and it can be expaned too - by adding new
input method.
I am wondering whether our product could be integrated
into or bundled with
the new Debian Linux release.
We also have some document and screen shot of our
product.
Please do not hesitate to contact us if we can help.
We are looking forward to your answer.

Best Regards,

Gary Liu
President of Liu production Co.
1999/5/6


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Here's a diff to my .xsession (was Re: Here's my .xsession)

[jim]

Hi,

already found a problem: comment lines in /etc/X11/window-managers that
match the chosen favorite window manager cause the script to fail weirdly...
Problem reported by [EMAIL PROTECTED]

this patch filters comment lines first. (Note to Branden: you might want
to use this logic, or something like it, in the global Xsession.)

This also removes the debug echos that show which stanza finds the wm.

---
--- xs  Tue May 11 07:09:53 1999
+++ .xsession   Tue May 11 07:42:03 1999
@@ -21,28 +21,26 @@
 # start by assuming that before we start looking, we haven't found anything
 foundWM=false
 
-echo "1 $foundWM"
-
 # Favorite window manager
 
 # set this to your favorite WM, or to nothing if you're willing to accept
 # whatever comes
 myWM=fvwm2
 
+# try to find my favorite wm
 if [ "$foundWM" = "false" ]
 then
-favWM=`grep $myWM /etc/X11/window-managers | head -1`
-aWM=`echo $favWM | sed 's/#.*//'`
+tmpWM=`grep -v "^#" /etc/X11/window-managers | sed 's/#.*//'`
+favWM=`echo $tmpWM | grep $myWM | head -1`
 
 if [ -x "$aWM" ]
 then
-   theWM=$aWM
+   theWM=$favWM
foundWM=true
 fi
 fi
 
-echo "2 $foundWM"
-
+# try to find ANY wm (the first one found to be executable)
 if [ "$foundWM" = "false" ]
 then
 if [ -e /etc/X11/window-managers ]
@@ -59,8 +57,6 @@
 fi
 fi
 
-echo "3 $foundWM"
-
 # still didn't find a wm?? OK, twm isn't the best, but we'll settle
 
 if [ "$foundWM" = "false" ]
@@ -69,20 +65,19 @@
 foundWM=true
 fi
 
-echo "4 $foundWM"
-
 # launch the selected or otherwise found window manager in the background.
+# !!note!! the window manager is NOT the foreground process because it is
+#  NOT the session controller (as would be the traditional case).
 
 $theWM &
 
-# launch xearth and an xterm.
 xearth &
 #xfishtank &
 #xterm -ls &
 
 # launch the session-controlling process. If it dies, so does the session.
 
-#exec logout-button
+#exec logout-button # anyone wanna a logout button? send me mail :)
 exec gnome-session
 
 # end of .xsession
@@ -94,7 +89,7 @@
 # # NOTE: this part taken from the else part of the final "if"
 # # in the global /etc/X11/Xsession by [EMAIL PROTECTED]
 # #
-# # i.e., look at this code as the default behavior and
+# # i.e., look at this code as the default session behavior and
 # # modify to taste
 #
 # xterm -ls &
---

-Jim

Intent to package: ezbounce

[Tommi Virtanen]

I will package ezbounce (http://druglord.freelsd.org/ezbounce/)
- an irc proxy that lets you detach from your session and
reattach later. It's GPL.

ETA today.

-- 
Havoc Consulting | unix, linux, perl, mail, www, internet, security consulting
+358 50 5486010  | software development, unix administration, training

Re: Homapages in list of maintainers

[Fumitoshi UKAI]

At Mon, 10 May 1999 13:26:29 -0700,
John Lapeyre <[EMAIL PROTECTED]> wrote:

>   I think it would be great for Debian JP and Debian to find someone
> in Japan who can do interviews in Japan and report to the new-maintainer
> people in Debian proper (in Europe or U.S.)  That is to say, it would
> be good to have a new-maintainer person located in Japan.
> This could speed up the process and improve communications.

I can volunteer to do it, if it is really needed and anyone object to it.
I've been maintain Debian JP machines, ftp archive, web server,
mailing-list and Debian official mirror in Japan about two years or three.

Regards,
Fumitoshi UKAI

xterm warning

[Wichert Akkerman]

If you are following unstable and are using PAM, and more specifically
the pam-apps package. I highly suggest that you do not upgrade
to xterm 3.3.3.1-3.

I repeat: do NOT upgrade to xterm 3.3.3.1-3 if you use pam-apps.

The problem is that there is a rather annoying bug in the Unix98 pty
support of that xterm package that completely breaks the su from the
PAM suite.

Please don't file a bug about this, I already did that.

Wichert.



pgp01dJGE2iJk.pgp
Description: PGP signature

Intent to package ada-mode

[Samuel Tardieu]

Source: ada-mode
Maintainer: Samuel Tardieu <[EMAIL PROTECTED]>
Section: editors
Priority: optional
Standards-Version: 2.5.1.0

Package: ada-mode
Architecture: all
Depends: emacsen
Suggests: gnat
Description: Ada mode for Emacs and XEmacs
 This is a major mode for editing Ada files in Emacs/XEmacs.

Re: Freeze stuff, summary.. (perl 5.005, etc)

[Peter S Galbraith]

Adam Di Carlo wrote:

> Oscar Levi <[EMAIL PROTECTED]> writes:
> 
> > I've been distracted by revenue production for a couple of months.
> > Are we expected to upload our packages rebuilt for glibc2.1? 
> 
> It wouldn't hurt but I don't think it's necessary. glibc2.1 can
> drop-in replace 2.0 (unless you have a program that depends on certain
> internal stuff which it shouldn't be using anyway).
> 
> Really, what is more important and has changed is CC from gcc272 to
> egcs.  But again, it would probably be nice to recompile sometime over
> then next two months, but not really necessary AFAIK.

But doesn't that require glibc2.1 anyway?

Package: gcc 2.91.66-1 
depends: libc6 (>= 2.1) [etc]

(Hmmm. Looks like my slink box will need to go glibc2.1 after all.)
-- 
Peter Galbraith, research scientist  <[EMAIL PROTECTED]>
Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada
P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546
6623'rd GNU/Linux user at the Counter - http://counter.li.org/ 

Re: request for package

[Mitch Blevins]

In foo.debian-devel, Wichert wrote:
> Can someone please package plib, which is Steve's Portable Game Library.
> It has a LGPL license so it can go into main without problem.
> 
> The reason I want this is so I can try `Tuxedo T. Penguin, A Quest for
> Herring' (http://www.woodsoup.org/projs/tux_aqfh/). If someone can
> package that as well I'ld be really happy :)

I can't resolve that domain.  Are you sure of the URL?

-Mitch

Re: Here's a diff to my .xsession (was Re: Here's my .xsession)

[Chris Waters]

[EMAIL PROTECTED] writes:

> Hi,

> already found a problem: comment lines in /etc/X11/window-managers that
> match the chosen favorite window manager cause the script to fail weirdly...
> Problem reported by [EMAIL PROTECTED]

> this patch filters comment lines first. (Note to Branden: you might want
> to use this logic, or something like it, in the global Xsession.)

Seems to me like it might be easier if the existing global Xsession
simply had an option to check through ~/.window-managers if one exists,
and only check /etc/X11/window-managers if there is no
~/.window-managers, or if no valid executables are found there.

This would require less code, and would provide the user with more
flexibility (rather than just *a* favorite, wmanagers could be ranked,
as they are system-wide).

This can be done in a .Xsession file too (untested code follows):

wm=
if [ -e ~/.window-managers ]; then
  for i in $(sed 's/^#.*//' ~/.window-managers) ; do
if [ -x $i ]; then wm=$i;  break
fi
  done
fi
if [ -z "$wm" && -e /etc/X11/window-managers ]; then
  for i in $(sed 's/^#.*//' /etc/X11/window-managers) ; do
if [ -x $i ]; then wm=$i;  break
fi
  done
fi
if [ -z "$wm" ]; then 
  panic!!!  # this line may need some work :-)
fi
exec $wm

-- 
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: KDE debian stuff

[Sergey V Kovalyov]

On Mon, 10 May 1999, Ivan E. Moore II wrote:
> So if you have beefs with how kde is currently being done from a debian 
> package
> standpoint and would like to see them done differently please let me know.  
> Here
> is a current list of things that people have already stated needed to be 
> changed
> or was a "god it would be nice"
> 
> Ivan
> 
A few issues :

I wonder, is it only me and a screwed potato on my test computer or other
people as well have problems with kde 1.1.1 ?
The symptoms are at least:
  - can't run kappfinder: dies with $(install_root)/usr/share/applink file
not found
  - Mime types don't work: clicking on almost any file suggests to "Open With"
  - khelp freezes when trying to view "man:something"

I encounter the same problems in pre1.1.1, in current 1.1.1 at ftp.kde.org
and in 1.1.1 from snowcrash.tdyc.com 

Downgrading to 1.1 (from 19990306 series at ftp.kde.org) turns everything
to normal.
So, is it specific to me, to potato, or actually a problem with packages ?

Another thing:
I believe, for potato kdm should be compiled with PAM support (or at least
a separate packages kdm-pam, kcheckpass-pam etc. should be provided).

Sergey. 

Re: KDE debian stuff

[Ivan E. Moore II]

Quoting Sergey V Kovalyov <[EMAIL PROTECTED]>:


> I wonder, is it only me and a screwed potato on my test computer or other
> people as well have problems with kde 1.1.1 ?
> The symptoms are at least:
>   - can't run kappfinder: dies with $(install_root)/usr/share/applink file
> not found
>   - Mime types don't work: clicking on almost any file suggests to "Open
> With"
>   - khelp freezes when trying to view "man:something"

it's not you. :)  

> So, is it specific to me, to potato, or actually a problem with packages ?
> 

a problem with the packages.  There was little (if at all) work put into the
packaging of 1.1.1.  (Stephen was busy with KDE itself).  I'm still finding
things like this and am trying to fix this stuff as I go along.  I will figure
out where these issues are coming from and get them fixed.

> Another thing:
> I believe, for potato kdm should be compiled with PAM support (or at least
> a separate packages kdm-pam, kcheckpass-pam etc. should be provided).

yea...I was pondering this as well when I saw that pam support was being turned
off...

Ivan


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ivan E. Moore II  Rev. Krusty
http://snowcrash.tdyc.com[EMAIL PROTECTED]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
GPG KeyID=0E1A75E3
GPG Fingerprint=3291 F65F 01C9 A4EC DD46 C6AB FBBC D7FF 0E1A 75E3
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Intent to package ogonkify

[Piotr Roszatycki]

-BEGIN PGP SIGNED MESSAGE-

Source: ogonkify
Section: text
Priority: extra
Description: Package for printing ISO-Latin-2 on PostScript printers
Upstream-source: ftp://ftp.dcs.ed.ac.uk/pub/jec/programs/>
Home-Page: http://www.dcs.ed.ac.uk/home/jec/ogonkify/>
Copyright: GPL
Architecture: all
Depends: perl
Description: Package for printing ISO-Latin-2 on PostScript printers
 This package contains two programs: a utility for creating composite
 fonts in a semi-automatic fashion, and a program for converting PS
 output -- notably Netscape and Mosaic output -- to use these fonts.
 It has been tested with Netscape Navigator 1.1N, 2.02, 3.0 beta 4,
 3.01 and 4.04 and Mosaic 2.7b1, all of those under Unix.
 
- -- 

Piotr "Dexter" Roszatycki
mailto:[EMAIL PROTECTED]

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

iQCVAwUBNziZiXXdfzF5wrBBAQFoWQP+Jpa+pCaHAMopKi7fUC0McARLeHUxoDYx
1eynD0Er+P0M1tjUrWP4s4HF6iwRjiqIuQMqNwYpcb0bZf//XVmnWKJhhcru4Bm7
TR3AcetAzxK2rZikqWhsd7GFMBUS/8qwOtVHmLSbaYmiFw1X697+XP3SXjkdW7VG
QkihSDGDTVc=
=6+MB
-END PGP SIGNATURE-

Re: Intent to package ogonkify

[Michael Stone]

On Tue, May 11, 1999 at 10:56:34PM +0200, Piotr Roszatycki wrote:
> Description: Package for printing ISO-Latin-2 on PostScript printers

This is already part of the a2ps package. Are you coordinating with the
maintainter of that package?

Mike Stone



pgp4ABRu59oOQ.pgp
Description: PGP signature

Re: request for package

[Bart Warmerdam]

On Tue, May 11, 1999 at 01:41:25PM -0400, Mitch Blevins wrote:
> In foo.debian-devel, Wichert wrote:
> > Can someone please package plib, which is Steve's Portable Game Library.
> > It has a LGPL license so it can go into main without problem.
> > 
> > The reason I want this is so I can try `Tuxedo T. Penguin, A Quest for
> > Herring' (http://www.woodsoup.org/projs/tux_aqfh/). If someone can
> > package that as well I'ld be really happy :)
> 
> I can't resolve that domain.  Are you sure of the URL?

  http://129.186.82.31/projs/tux_aqfh/

  B.

--
B. Warmerdam  GNU/Debian Linux
[EMAIL PROTECTED], [EMAIL PROTECTED] (Keyid: 10A0FDD1)   

Re: request for package

[Wichert Akkerman]

Previously Mitch Blevins wrote:
> I can't resolve that domain.  Are you sure of the URL?

Yes, but the DNS seems to be down now. Be patient :)

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/


pgp4yRFvyRDeq.pgp
Description: PGP signature

Re: Debian coding style?

[John Goerzen]

I say that the coding style ought to be as follows:

 * Everyone ought to write code such that indentation and placement of
   block elements on code are such that the ability of others to read
   the code is maximized.

Additionally, I should mention that the below guidelines are very
C++-centric; better guidelines will apply to any language that has
similar syntax.  Again, better to go up to the concepts that cover
these then drilling down to the specific implementation.



[EMAIL PROTECTED] (Amy Fong) writes:

> Linux Coding guidelines say... (follows). A few note-worthy ones are:
>   - tabs: 2 spaces

This is very nasty.  Tabs are defined as occuring at every 8th
character; they are not a fixed width, and not every two spaces.

>   - curly braces alway on next line
>   ie if (...)
>{
>}
>else
>{
>}

I have no problems reading code like that but I prefer to not write it 
such.  Cf "bsd" mode in xemacs.

>   - hungarian notation

Aiee!  That's scary.  :-)

>* Compiling: all code must compile clean at warning level 3 with warnings
>  as errors.

Probably you mean -Wall -Werror here.

> 3. Tabs should be set to 2, and they should be kept as tabs, no spaces
> please.

This only compounds the error set above.

> 4. Code width: The complete line of code should be visible without having to
> scroll horizontally - i.e. it should normally not pass the 78th column.

Good one.

> 5. Naming conventions:
> 
> a) Class names always start with upper-case 'C', followed by an upper-case
> letter, followed by mixed upper/lower case and must always take the form of
> a descriptive noun.

I think that this is a bit overboard on the control side, and leads to 
the Java-esqe problem of spending all one's time typing long names and 
no time coding :-)

> c) Variable names must use hungarian notation (see below) followed by

I think that the whole premise behind Hungarian notiation is faulty.
That is, Hungarian notation is only used to clarify differences
between types of variables.  This indicates that the programmer is
probably not using consistent variable types, which is bad anyway, and 
moreover, are writing functions of such a length that they can't
remember the types of variables used.  Both are bad.

In other words, Hungarian treats a symptom, not the problem.

>* Magic numbers must not be embedded directly in the source code. Use a
>  const int variable to hold the magic number rather than a #define.

There are certain cases in which it is desirable to use a macro
instead; most frequently, one might find this with doing bitwise
arithmetic.

> 7. Comments : Please comment your code, it makes everyone's life easier.

Certainly.

> 10. Function/method size: bigger is not better. Functions and methods should
> be kept to a maximum of 40-50 lines. Larger methods should be broken down
> into several smaller methods.

Agreed on priciples, but there are cases in which exceptions are
desirable and cood.

> 14. Compilation conditionals, with the exception of debug code noted above,
> should be avoided since they make the source code difficult to read and
> maintain. Old or unwanted code should be deleted from the source files prior
> to check-in. Source safes history feature can be used to retrieve an old
> version of the file if the old code is ever required again.

Many times, compilation conditionals are the only way to make
something compile on the dozens of platforms that we work with today.

> 16. Goto statements should not be used.

Bad idea.  Yes I know what people say, but there *are* times when
gotos and far jumps can be good.  While not strictly necessary, they
can help.

> 17. Return: functions and methods should be structured to have a single
> return.

This is also not a good idea.  I often find myself checking input and
returning from the function early if it's not what I want to deal
with.

> 18. Switch statements must always handle the default: case. If all expected
> cases have otherwise been handled, the default: case should force an
> assertion failure. Case statements should be indented by 1 tab and separated
> from each other by 1 blank line. Code within each case should be kept to a
> minimum - i.e. call a function from the case statement if more than a few
> lines of code are needed.

There is not always a special "default" case.  (ie, enums)  While
strictly it is there, the compiler will give you a warning if you
don't handle every option anyway.

> 20. Header files must not include other header files (to prevent header file
> bloat). Use forward class references to inform compiler of required data
> types.

Header files including others are often great ways to simplify the
code and make it easier to read.

> 22. Localization: text which will be visible to the user should never be
> embedded within the source code. All string literals should be p

Re: Release Plans (1999-05-10)

[Steve McIntyre]

Raphael Hertzog writes:
>
>There's also another thing that need to be worked on, the CDs. The
>script creating the images is not smart enough to select just the
>good number of packages for each CDs. 

Agreed. Help on this aspect gratefully received...

>Currently, the two binary CDs
>can still be generated for potato but not the source images (they are too
>big). And many dependencies on the first CD are not met.

Really? If you have a list, I'd love to see it...

-- 
Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED]
http://www.rpg-soc.ucam.org/curs/>CURS home page
"Can't keep my eyes from the circling sky, +--
"Tongue-tied & twisted, Just an earth-bound misfit, I..."  |Finger for PGP key

Re: Release Plans (1999-05-10)

[Steve McIntyre]

Chris Lawrence writes:
>
>slink-cd makes HFS hybrid CDs for m68k already; I'm pretty sure I
>asked Steve to use the HFS options for PowerPC too (so the code's
>already there...)

Yep, you're correct.

-- 
Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED]
http://www.rpg-soc.ucam.org/curs/>CURS home page
"Can't keep my eyes from the circling sky, +--
"Tongue-tied & twisted, Just an earth-bound misfit, I..."  |Finger for PGP key

Re: Release Plans (1999-05-10)

[Steve McIntyre]

Adam Di Carlo writes:
>
>Debian-CD has a number of problems that need fixing; see the Bugs
>against the package.  Join  to help.

That would be useful. I _am_ working on things when I get a chance, even
if I have been a little quiet of late.

>Are we going to go ahead and try out my new "Release Team" concept?
>If so, let's make the mailing list and troll the right people to join.

Count me in...

-- 
Steve McIntyre, CURS CCE, Cambridge, UK. [EMAIL PROTECTED]
http://www.rpg-soc.ucam.org/curs/>CURS home page
"Can't keep my eyes from the circling sky, +--
"Tongue-tied & twisted, Just an earth-bound misfit, I..."  |Finger for PGP key

Re: Homapages in list of maintainers

[Atsuhito Kohda]

From: Fumitoshi UKAI <[EMAIL PROTECTED]>
Subject: Re: Homapages in list of maintainers
Date: Wed, 12 May 1999 01:23:21 +0900

> > I think it would be great for Debian JP and Debian to find someone
> > in Japan who can do interviews in Japan and report to the new-maintainer
> > people in Debian proper (in Europe or U.S.)  That is to say, it would
> > be good to have a new-maintainer person located in Japan.
> > This could speed up the process and improve communications.
> 
> I can volunteer to do it, if it is really needed and anyone object to it.
> I've been maintain Debian JP machines, ftp archive, web server,
> mailing-list and Debian official mirror in Japan about two years or three.

As I am a mathematician I must be strict with logic ;-)
Perhaps "anyone object to it" is a typo of "no one object to it"

About the point "if it is really needed", it is really, really needed
and if Mr. UKAI can do it, it is really great for both Debian and
Debian JP.

Thanks in advance,  1999.5.12

--
 **
 Atsuhito Kohda
 Dep. Math., Tokushima Univ.
 [EMAIL PROTECTED]

Re: Homapages in list of maintainers

[Taketoshi Sano]

Hi. Thank you for your replies. I got relief to know 
this "long waiting queue" issue is rather common to all newcomers.

In article <[EMAIL PROTECTED]>
 Adam Di Carlo <[EMAIL PROTECTED]> writes:

> Yes, well, it takes from 4 weeks to 6 months or longer for *all*
> people.  I agree this should be shorter...  Anyhow Debian-JP is *not*
> getting singled out.  Everyone has this issue.

I remeber the mail about 6 months waiting recently on this list.
It's surely uncomfortable state which should be avoidable as much 
as we can.

> IF there's not way the guy can get a phone call, I'm afraid there's no
> way they can be confirmed and become a developer.

Maybe he can get a call on holiday, I suppose. He is only afraid
that he can't set time windows to new maitainers team, and 
he thought that the time of getting the call is unpredictable at all.

> According to James, all he says is "it's unlikely to be between 8AM
> and 4PM British time on Monday-Friday".
> 
> No one is asking you to sit by the phone for 3 months.  But if you can
> only be reached at number XX-YYY at the hours of 3-7 GMT on Saturday,
> then tell the new maintainers that.  Give them time windows that work
> for you.  Give them a few different numbers and suggested times.  I
> mean, common sense, people.

Thanks for your information. That is what I want to know.

> Sure, but put people in the queue.  It may take up to 3 months or
> longer if you're hard to reach on the phone -- so just plan on that.

3 months or longer ! (sigh) but if it is required condition, 
all we can do is just to wait in the queue ...

> Well, I think it's pretty clear that we need more active people in the
> New Maintainer Group.  I hereby volunteer (I'm in the US, NYC area,
> and only speak English and smidgeons of Spanish, German, and French).

I respect the people in the New Maintainer Group including you
for their work. I hope there were the one in Japan, but no one can
force the current official maintainer in JP to take charge of it,,,

> > P.S.
> > I think, and hope that the Debian is "open" project.
> 
> It is -- don't get paranoid.  The New Maintainer Group is just swamped
> a bit.  I think it needs more people -- highly trustable people, of
> course.

I hope the New Maintaier Group can find the highly trustable and 
active "official" maintainer as their member in Japan, or somewhere 
in the far-east area.

-- 
  Taketoshi Sano: <[EMAIL PROTECTED]>

Re: Homapages in list of maintainers

[Taketoshi Sano]

Thank you for your reply. I'm impressed your idea.

In article <[EMAIL PROTECTED]>
 John Lapeyre <[EMAIL PROTECTED]> writes:

>   I think it would be great for Debian JP and Debian to find someone
> in Japan who can do interviews in Japan and report to the new-maintainer
> people in Debian proper (in Europe or U.S.)  That is to say, it would
> be good to have a new-maintainer person located in Japan.

I think so. and more, I hope that the site for dupload established
in Japan so that we can select the near site to upload our packages.

In current standard /etc/dupload.conf contains "chiark" (uk), "master" (us?), 
"erlangen" (de), and "giano" (it). I hope that one of the JP's site is
registered as the official upload site. But it may takes some effort in
JP project also, and I am only just plain member in JP project, so I have to
debate about it in JP project also, not only here,,,

> This could speed up the process and improve communications.

I am glad to hear from you :) Thank you.

-- 
  Taketoshi Sano: <[EMAIL PROTECTED]>