Re: Questions about testing

[Branden Robinson]

On Tue, Jan 02, 2001 at 02:15:29PM +1000, Anthony Towns wrote:
> The idea is that for a package to get into testing it should:
> 
>   * be synchronised across architectures
>   * have all its dependencies met, and not break the dependencies
> of other packages
>   * not have any RC bugs
> 
> The first two of those points can be automatically checked, and are. The
> latter point, though, requires people to actually try the package,
> and report any problems.
> 
> For the latter to be of any value, there are two further requirements. One
> is that you give people a little time, both to install the package and to
> leave it around long enough that people have a chance to see if it breaks
> in normal use, or similar.

Yeah, well, "long enough" means different things for different packages.

For some toy package it could be well over the current requirements.

On the other hand, severe (== RC) breakage in an Essential package, or even
those that are non-essential but still very popular (the emacsen, vim,
XFree86), is typically noticed right away.

Consider that when I manage to hork up X, I know about it within hours of
dinstall.  Likewise, a few days ago when Wichert busted the vim postinst,
he was told about it quite fast indeed.

I don't have any concrete recommendations for how to take this into
account, but I certainly think that a 14-day waiting period for packages
like these is excessive.

-- 
G. Branden Robinson | To stay young requires unceasing
Debian GNU/Linux| cultivation of the ability to unlearn
[EMAIL PROTECTED]  | old falsehoods.
http://www.debian.org/~branden/ | -- Robert Heinlein


pgpYXGUoeAvZE.pgp
Description: PGP signature

Re: Questions about testing

[Anthony Towns]

On Mon, Jan 01, 2001 at 02:04:51PM -0600, Manoj Srivastava wrote:
> >>"Anthony" == Anthony Towns  writes:
>  Anthony> Well, even Joey Hess has slipped up in his religious debconf
>  Anthony> uploads and had four or five delays longer than a fortnight
>  Anthony> between updates. Basically, though, at some point the
>  Anthony> maintainer has to decide "I'm happy with this" and leave
>  Anthony> well enough alone for a little while.
>   Umm. This is an artifact of the implementation, and does not
>  seem to have a rational design principle behind it, unless I am being
>  very dense. 

The idea is that for a package to get into testing it should:

* be synchronised across architectures
* have all its dependencies met, and not break the dependencies
  of other packages
* not have any RC bugs

The first two of those points can be automatically checked, and are. The
latter point, though, requires people to actually try the package,
and report any problems.

For the latter to be of any value, there are two further requirements. One
is that you give people a little time, both to install the package and to
leave it around long enough that people have a chance to see if it breaks
in normal use, or similar.

Given the way Debian generally works: most people running apt-get
dist-upgrade every day, then the only package that's going to get any
testing at all in normal use is the very latest one, not one from a few
days ago that's already been obsoleted.

There are a host of technical problems as well: you can't tell whether
bugs apply to the new or the old version, there's no way to get at the
appropriate old versions, the code was written expecting there to be
exactly one candidate for each source package and does break if that's
violated, the number of possible combinations of packages to try is
fairly unreasonable already, trying old versions as well is non-trivial,
and so on.

The times (14 days for low, and 7 days for medium) were taken from
the time it usually seems to take the autobuilders to get a package
sync'ed across multiple architectures, which is usually around a week
or a little longer. If you're doing the upload every other day thing,
you'll tend to fail the first check in any case.

>  >> 4. How can I know precisely why my package has not been included in
>  >> testing. I know update_excuse.html on ajt website ... but that's not
>  >> enough. I want to know for example that my libdbd-pg-perl package is
>  >> waiting on perl-5.6 (or on postgresql) to be integrated ...
>  Anthony> You have to look at your dependency list, and investigate it
>  Anthony> yourself. :( 
>   Where does the pice of code reside that determines whether or
>  not a package is going to be moved into testing? Can one extract that
>  code into a purely reporting agent?

auric:~ajt/testing/testing/dpkg.c:check_installable() and
~ajt/testing/testing.xs, and ~ajt/testing/update_out.pl. And you can
try. :-/

Cheers,
aj

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

 ``Thanks to all avid pokers out there''
   -- linux.conf.au, 17-20 January 2001

Re: Problem with pcmcia-modules and kernel-image

[Brian Mays]

> Sure ? Actually pcmcia-modules-2.2.18 depends on kernel-image-2.2.18...

The pcmcia-modules-2.2.18 package shipped with Debian depends on 
kernel-image-2.2.18, but pcmcia-modules packages in general -- e.g., those 
built locally by users to accompany their custom kernels --- do not have 
this dependency.

Such an assumption would be imperfect, at best.  I still think that this 
should be the job of the kernel maintainer, not the PCMCIA package.

- Brian

Re: Huh, gcc 2.95.3?

[Ben Collins]

On Tue, Jan 02, 2001 at 12:31:52PM +1100, Daniel Stone wrote:
> > On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote:
> > > > On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote:
> > > > > Happy new year to everyone!
> > > > > 
> > > > > gcc 2.95.3 appeared in Sid, but it hasn't been announced by the 
> > > > > GCC steering committee yet. Is this some kind of early access 
> > > > > version?
> > > > 
> > > > It's based on the CVS branch, which is noted in the changelog if you had
> > > > bothered to read it. There's no such thing as "early access", this is
> > > > open source you know :)
> > > 
> > > Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like
> > > myself) are willingly sado-masochists, but a CVS GCC?
> > 
> > Uh, GCC 2.95.3 CVS NOT 2.96 OR 2.97! Please be careful what you say. We
> > are talking about a stable release here, not a dripping wet development
> > snapshot.
> 
> So what was the CVS branch reference?

Because the upcoming 2.95.3 release is currently only available via a
CVS branch maybe?

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: ITP kimberlite - was Re: High Availability..

[Russell Coker]

Josh Huber from mission critical Linux wants to do it.  I think he's in a 
better position to do it than me so I have let him have it...


Russell Coker

> > Do you have any patches for creating Debian packages for kimberlite?  If
> > so
> > please send them to me.
> >
> > I intend to package it.  It is under the GPL license.  It is a system
> > for
> > managing clusters of Linux machines.
>
> Unpack the tar-ball, cd the source dir and run "dpkg-buildpackage" and you
> are already set =)

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: Huh, gcc 2.95.3?

[Daniel Stone]

> On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote:
> 
> > Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like
> > myself) are willingly sado-masochists, but a CVS GCC?
> 
> GCC 2.95.3 is in final testing and due for release RSN, making it a
> somewhat different situation.  It's also binary-compatible with 2.95.2.

That's why the "I hope" and the question-mark - I just saw the CVS branch
bit, and wel-l-l-l ...
EOT(tm).

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Michael Meding]

On Tuesday,  2. January 2001 00:07, Josip Rodin wrote:
> On Mon, Jan 01, 2001 at 11:59:19PM +0100, Josip Rodin wrote:
> > > > MM> Of course a quick search in there revealed nothing poping up for
> > > > cdda.
> > > >
> > > > Very strange. I've find that in unstable :
> > > > usr/include/cdda_interface.hsound/libcdparanoia0-dev
> > > > usr/include/cdda_paranoia.h sound/libcdparanoia0-dev
> > >
> > > Ah. The mirror (the Contents-* files in it) on the machine where that
> > > CGI runs is outdated. Known issue.
> >
> > Actually, wait, wrong. Investigating...
>
> Well, I've checked and re-checked and everything seems fine. Entered both
> of those files in the search form and the script returned those results.
>
> Too much alcohol, Michael? :)
Now got it sraight. Maybe your guess was nat that wrong :)

Ok,

did use the wrong search engine. Problem is the headline of the search engine 
in the german translation was a little miguiding. It talks about "search 
published", didn't read the rest though. Someone really should change the 
translation there ;))

Sorry for causing that mess.

Thanks anyway.

Greetings

Michael

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Michael Meding]

On Tuesday,  2. January 2001 00:07, Josip Rodin wrote:
> On Mon, Jan 01, 2001 at 11:59:19PM +0100, Josip Rodin wrote:
> > > > MM> Of course a quick search in there revealed nothing poping up for
> > > > cdda.
> > > >
> > > > Very strange. I've find that in unstable :
> > > > usr/include/cdda_interface.hsound/libcdparanoia0-dev
> > > > usr/include/cdda_paranoia.h sound/libcdparanoia0-dev
> > >
> > > Ah. The mirror (the Contents-* files in it) on the machine where that
> > > CGI runs is outdated. Known issue.
> >
> > Actually, wait, wrong. Investigating...
>
> Well, I've checked and re-checked and everything seems fine. Entered both
> of those files in the search form and the script returned those results.
>
> Too much alcohol, Michael? :)
Hi guys,

thanks for your help. But putting cdda into the search engine didn't reveal 
anything at all for me. But I still have no result when typing in 
cdda_interface.h. I did go to www.debian.org/distrib/packages then punched in 
cdda_interface.h into "Schlüsselwörter" (I guess that means keyword in 
english :-)) then search for descriptions, all for versions and all for 
release. Still didn't worked out, it came to no results. Could you recheck 
that ?

Where else coud the error be ?

Thanks for your help anyway, at least now I know the package name ;-).

Greetings

Michael

Re: Huh, gcc 2.95.3?

[Daniel Stone]

> On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote:
> > > On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote:
> > > > Happy new year to everyone!
> > > > 
> > > > gcc 2.95.3 appeared in Sid, but it hasn't been announced by the 
> > > > GCC steering committee yet. Is this some kind of early access 
> > > > version?
> > > 
> > > It's based on the CVS branch, which is noted in the changelog if you had
> > > bothered to read it. There's no such thing as "early access", this is
> > > open source you know :)
> > 
> > Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like
> > myself) are willingly sado-masochists, but a CVS GCC?
> 
> Uh, GCC 2.95.3 CVS NOT 2.96 OR 2.97! Please be careful what you say. We
> are talking about a stable release here, not a dripping wet development
> snapshot.

So what was the CVS branch reference?

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Santiago Vila wrote:
> First, there is no hurry for this. Second, it would probably take only
> one more release if we stop using symlinks right now. I already made a
> policy proposal to stop using symlinks, but there were objections from
> Manoj and Raul

I'm sure they objected since dropping symlinks right now would completly
ignore the entire point of the technical committee's decision. You would
have some documentation only in /usr/doc and some only in
/usr/share/doc. I'm sorry, but that is unacceptable.

> what do they think about this single-script idea which
> is clearly against what the T.C. decided? (I guess they are on vacation).

Since the situation has changed since their decision, a new method
which takes advantage of the change in the situation should be ok, I
think.

> I do not follow your argument, anyway: If 6 people fix one package a
> day until woody is frozen, everything will be (physically) in
> /usr/share/doc at release time.

Indeed yes. Are you volenteering to be one of the six? I didn't get any
volenteers last time.

> You can be done today if you want (just use your script in *your*
> system, at your *own* risk), but this does not necessarily mean we
> have to risk hundreds of thousand of systems out there which do not have
> a real need to be converted in a single step.

I'd like to see your source of numbers that hundreds of thousands of
people track unstable.

I don't understand why you are assuming that any bugs that turn up in
the script won't be fixable anyway. It's not as if a temporary problem
with /usr/doc is going to cripple a debian system.

-- 
see shy jo

Re: finishing up the /usr/share/doc transition

[Santiago Vila]

On Mon, 1 Jan 2001, Joey Hess wrote:

> Santiago Vila wrote:
> > No, we don't *need* any script to do this. One thing is that dpkg
> > allows this to be done and another different one is that we *have* to
> > do it. We agreed to make the transition on a per package basis. If we
> > consider the transition almost finished and we want an empty /usr/doc
> > we have just to *stop* requiring symlinks in maintainer scripts (which
> > is something that we would do sooner or later). Once we stop making
> > symlinks in /usr/doc, this directory will be emptied by itself,
> > cleanly, and without risking the integrity of the system by complex
> > scripts.
>
> Take another look at where we are now. If 6 people fix one package a
> day until woody is frozen, we might just manage to convert all packages
> that do not yet use /usr/share/doc. If that is done, we only have to wait 2
> more releases of debian until the transition is complete.

First, there is no hurry for this. Second, it would probably take only
one more release if we stop using symlinks right now. I already made a
policy proposal to stop using symlinks, but there were objections from
Manoj and Raul, what do they think about this single-script idea which
is clearly against what the T.C. decided? (I guess they are on vacation).

I do not follow your argument, anyway: If 6 people fix one package a
day until woody is frozen, everything will be (physically) in
/usr/share/doc at release time. In such case it should be extremely
easy to remove /usr/doc by hand *if one wants to*. Why do you need a
complex script then? I think it is much better to leave this to the user's
discretion.

> On the other hand, if we use a script now, we can be done tomorrow.

You can be done today if you want (just use your script in *your*
system, at your *own* risk), but this does not necessarily mean we
have to risk hundreds of thousand of systems out there which do not have
a real need to be converted in a single step.

> As for risking the integrity of the system with complex scripts, take a
> look at the tremendous number of ways that people have managed to screw
> this up doing it one package at a time (I just discovered a package that
> puts files in /usr/doc/foo with a symlink /usr/share/doc/foo to it;
> completly backwards from what policy requires.).

Yes, I *always* thought these symlinks were a really bad idea, but
the solution is to stop requiring them, not writing yet another script.

> Perhaps a single script is actually likely to be better?

Perhaps no script at all and stop requiring symlinks is even better
than a complex script.

Re: Huh, gcc 2.95.3?

[Ben Collins]

On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote:
> > On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote:
> > > Happy new year to everyone!
> > > 
> > > gcc 2.95.3 appeared in Sid, but it hasn't been announced by the 
> > > GCC steering committee yet. Is this some kind of early access 
> > > version?
> > 
> > It's based on the CVS branch, which is noted in the changelog if you had
> > bothered to read it. There's no such thing as "early access", this is
> > open source you know :)
> 
> Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like
> myself) are willingly sado-masochists, but a CVS GCC?

Uh, GCC 2.95.3 CVS NOT 2.96 OR 2.97! Please be careful what you say. We
are talking about a stable release here, not a dripping wet development
snapshot.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Huh, gcc 2.95.3?

[Mark Brown]

On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote:

> Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like
> myself) are willingly sado-masochists, but a CVS GCC?

GCC 2.95.3 is in final testing and due for release RSN, making it a
somewhat different situation.  It's also binary-compatible with 2.95.2.

-- 
Mark Brown  mailto:[EMAIL PROTECTED]   (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/


pgpxUWpYjngZj.pgp
Description: PGP signature

Re: Huh, gcc 2.95.3?

[Daniel Stone]

> On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote:
> > Happy new year to everyone!
> > 
> > gcc 2.95.3 appeared in Sid, but it hasn't been announced by the 
> > GCC steering committee yet. Is this some kind of early access 
> > version?
> 
> It's based on the CVS branch, which is noted in the changelog if you had
> bothered to read it. There's no such thing as "early access", this is
> open source you know :)

Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like
myself) are willingly sado-masochists, but a CVS GCC?

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Cristian Ionescu-Idbohrn]

Retrieve the relevant Contents-${ARCH}.gz file and search:

  # wget ftp://ftp.se.debian.org/debian/dists/unstable/Contents-i386.gz
  # zgrep cdda_interface.h Contents-i386.gz

Cheers,
Cristian

On 1 Jan 2001, Christian Marillat wrote:

>  "MM" == Michael Meding <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >> http://www.debian.org/distrib/packages
>
> [...]
>
> MM> that was really funny. I am still laughing. Of course a quick search in 
> there
> MM> revealed nothing poping up for cdda. But I did the search before I posted 
> to
> MM> the list.
>
> MM> Anyway,
>
> MM> I still haven't been able to locate the desired files. Anybody would be so
> MM> kind as to point me to the corresponding package ?
>
> Very strange. I've find that in unstable :
>
> usr/include/cdda_interface.hsound/libcdparanoia0-dev
> usr/include/cdda_paranoia.h sound/libcdparanoia0-dev

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Ben Collins wrote:
> Maybe this should be something like:
> 
>   if cp -a $OLDDOC/$item $NEWDOC; then
>   rm -rf $OLDDOC/$item
>   else
>   rm -rf $NEWDOC/$item
>   exit 1
>   fi
> 
> That should handle filesystem full errors a bit better.

Of course the (broken) dir merging code in the stanza just above should
deal with recovering from this case if the script is run again after a
larger partition becomes available.

I guess what you're doing is ok though. Although it may use 2x as much
space temporarily..

-- 
see shy jo

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Joey Hess wrote:
> It should handle all the edge cases except:

Well it also has a bug in the subdirectory merging code. Merging
/usr/doc/HOWTO and /usr/share/doc/HOWTO is difficult. cp alone doesn't
cut it.

-- 
see shy jo

Re: finishing up the /usr/share/doc transition

[Ben Collins]

On Mon, Jan 01, 2001 at 03:05:14PM -0800, Joey Hess wrote:
> 
> # Move any remaining directories and symlinks from OLDDOC to NEWDOC.
> for item in `find $OLDDOC -maxdepth 1 \( -type d -or -type l \) -printf 
> '%P\n'`; do
>   if [ "$item" -a -e "$NEWDOC/$item" ]; then
>   echo "$item exists in $NEWDOC too; should never happen" >&2
>   exit 1
>   fi
>   mv -f $OLDDOC/$item $NEWDOC
> done
> 

Maybe this should be something like:

if cp -a $OLDDOC/$item $NEWDOC; then
rm -rf $OLDDOC/$item
else
rm -rf $NEWDOC/$item
exit 1
fi

That should handle filesystem full errors a bit better.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: finishing up the /usr/share/doc transition

[Ben Collins]

On Mon, Jan 01, 2001 at 11:58:07PM +0100, Goswin Brederlow wrote:
> 
> So bugs won't be noticed. Maybe a simple grep in the Contents files
> would be enough to find all such packages.
> Does lintian check for /usr/[share/]doc?
> 

Yes, lintian does complain about /usr/doc and /usr/man

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Huh, gcc 2.95.3?

[Matthijs Melchior]

Josip Rodin wrote:
> 
> On Mon, Jan 01, 2001 at 11:58:04PM +0100, Matthijs Melchior wrote:
> > > > To read the changelog I have to download and install it. But I don't
> > > > like to install unknown compilers on my development machines. Especially
> > > > since there is no undo operation for dpkg -i.
> > >
> > > To read the changelog, you do not have to install it.
> >
> > Yes, this is something I want to know how to do.  The Debian changelog is
> > available through the web access to the packages, but how do I get the
> > upstream changelog that is also part of that package [Or to make
> > the question even more general, how do I download the package list of files
> > and than one specific file from that list...?..]
> 
> dpkg-deb -x package.deb directory # and you'll have the package's files
>   # extracted in directory/
> 
> See the manual page for more information.
> 
Yes, OK,  I was expecting a method that did not require to
download the full package, just the index and a specific file



-- 
Thanks,
  -o)
Matthijs Melchior   Maarssen  /\\
mailto:[EMAIL PROTECTED]   +31 346 570616   Netherlands _\_v
 

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Josip Rodin]

On Mon, Jan 01, 2001 at 11:59:19PM +0100, Josip Rodin wrote:
> > > MM> Of course a quick search in there revealed nothing poping up for cdda.
> > > 
> > > Very strange. I've find that in unstable :
> > > usr/include/cdda_interface.hsound/libcdparanoia0-dev
> > > usr/include/cdda_paranoia.h sound/libcdparanoia0-dev
> > 
> > Ah. The mirror (the Contents-* files in it) on the machine where that CGI
> > runs is outdated. Known issue.
> 
> Actually, wait, wrong. Investigating...

Well, I've checked and re-checked and everything seems fine. Entered both of
those files in the search form and the script returned those results.

Too much alcohol, Michael? :)

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Attached is my conversion script. It's parameterized at the top, so you
can make copies of /usr/doc and /usr/share doc and point it at them
instead. I have done that in my testing and it seems to work perfectly.

It should handle all the edge cases except:

1. /usr/share mounted elsewhere and not big enough to contain all of
   /usr/doc. One of the mv or cp's will fail, and the script will die.
   Is this sufficient?
2. If /usr/doc/foo is a link to ../share/doc/bar, and /usr/share/doc/foo
   does not exist, it ends up with /usr/share/doc/foo being a link to
   ../share/doc/bar, which will not work. I could add some complex code
   to deal with this, but it seems unlikely and a bug in any package
   that did that anyway.
3. Relative links from /usr/doc/foo/bar to elsewhere will break. I just
   thought of this one, and it probably needs to be fixed.

-- 
see shy jo
NEWDOC=/usr/share/doc
OLDDOC=/usr/doc

set -e

# Remove all symlinks in OLDDOC that correspond to
# symlinks or directories with the same names in NEWDOC
for link in `find $OLDDOC -maxdepth 1 -type l -printf '%P\n'`; do
if [ "$link" -a -e "$NEWDOC/$link" ]; then
rm -f "$OLDDOC/$link"
fi
done

# Remove all symlinks in NEWDOC that correspond to directories with the
# same name in OLDDOC. No, this should not happen. Yes, it does. Sigh.
for link in `find $NEWDOC -maxdepth 1 -type l -printf '%P\n'`; do
if [ "$link" -a -e "$OLDDOC/$link" ]; then
rm -f "$NEWDOC/$link"
fi
done

# If there are any directories with the same names in OLDDOC and  
# NEWDOC, merge them. (And whine about it, since that's a bug.)
for dir in `find $OLDDOC -maxdepth 1 -type d -printf '%P\n'`; do
if [ "$dir" -a -d "$NEWDOC/$dir" ]; then
echo "Both /usr/doc/$dir and /usr/share/doc/$dir exist; 
merging." >&2
cp -a $OLDDOC/$dir $NEWDOC/$dir
rm -rf $OLDDOC/$dir
fi
done

# Move any remaining directories and symlinks from OLDDOC to NEWDOC.
for item in `find $OLDDOC -maxdepth 1 \( -type d -or -type l \) -printf 
'%P\n'`; do
if [ "$item" -a -e "$NEWDOC/$item" ]; then
echo "$item exists in $NEWDOC too; should never happen" >&2
exit 1
fi
mv -f $OLDDOC/$item $NEWDOC
done

# If there are any files left in OLDDOC, move those too if we can.
# This will probably only happen if the admin (or something broken)
# put them there.
for file in `find $OLDDOC -maxdepth 1 -type f -printf '%P\n'`; do
if [ -e "$NEWDOC/$file" ]; then
# TODO: deal with this somehow instead of bailing?
# It is a fairly unlikely edge case though.
echo "$item exists in $NEWDOC too. Please delete one of them." 
>&2
exit 1
fi
mv -f $OLDDOC/$file $NEWDOC
done

# Try to delete OLDDOC now; it should be empty.
rmdir $OLDDOC || ( echo "rmdir $OLDDOC failed" >&2 && exit 1)

# Now make the symlink. 
ln -sf share/doc $OLDDOC

Re: Huh, gcc 2.95.3?

[Josip Rodin]

On Mon, Jan 01, 2001 at 11:58:04PM +0100, Matthijs Melchior wrote:
> > > To read the changelog I have to download and install it. But I don't
> > > like to install unknown compilers on my development machines. Especially
> > > since there is no undo operation for dpkg -i.
> > 
> > To read the changelog, you do not have to install it.
> 
> Yes, this is something I want to know how to do.  The Debian changelog is
> available through the web access to the packages, but how do I get the
> upstream changelog that is also part of that package [Or to make
> the question even more general, how do I download the package list of files
> and than one specific file from that list...?..]

dpkg-deb -x package.deb directory # and you'll have the package's files
  # extracted in directory/

See the manual page for more information.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: Huh, gcc 2.95.3?

[Matthijs Melchior]

Ben Collins wrote:
> 
> On Mon, Jan 01, 2001 at 04:47:55PM +0100, Harald Dunkel wrote:
> > Ben Collins wrote:
> > >
> > > On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote:
> > > > Happy new year to everyone!
> > > >

> > To read the changelog I have to download and install it. But I don't
> > like to install unknown compilers on my development machines. Especially
> > since there is no undo operation for dpkg -i.
> 
> To read the changelog, you do not have to install it.

Yes, this is something I want to know how to do.  The Debian changelog
is
available through the web access to the packages, but how do I get the
upstream changelog that is also part of that package  [Or to make
the
question even more general, how do I download the package list of files
and than one specific file from that list...?..]

> 

-- 
Thanks,
  -o)
Matthijs Melchior   Maarssen  /\\
mailto:[EMAIL PROTECTED]   +31 346 570616   Netherlands _\_v
 

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Josip Rodin]

On Mon, Jan 01, 2001 at 11:56:21PM +0100, Josip Rodin wrote:
> On Mon, Jan 01, 2001 at 11:47:51PM +0100, Christian Marillat wrote:
> > MM> Of course a quick search in there revealed nothing poping up for cdda.
> > 
> > Very strange. I've find that in unstable :
> > usr/include/cdda_interface.hsound/libcdparanoia0-dev
> > usr/include/cdda_paranoia.h sound/libcdparanoia0-dev
> 
> Ah. The mirror (the Contents-* files in it) on the machine where that CGI
> runs is outdated. Known issue.

Actually, wait, wrong. Investigating...

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: finishing up the /usr/share/doc transition

[Goswin Brederlow]

> " " == Joey Hess <[EMAIL PROTECTED]> writes:

 > Goswin Brederlow wrote:
>> What is the reason for linking /usr/doc to /usr/hare/doc (or
>> share/doc)?

 > So that packages that are not policy complient and contain
 > files only in /usr/doc still end up installing them in
 > /usr/share/doc.

So bugs won't be noticed. Maybe a simple grep in the Contents files
would be enough to find all such packages.
Does lintian check for /usr/[share/]doc?

/debian/dists/woody% zgrep "usr/doc" Contents-i386.gz \
  | while read FILE PACKAGE; do echo $PACKAGE; done | sort -u | wc
748 748   12849

Seems to be a lot of packages still using /usr/doc.

>> Maybe I have architecure dependent documentation that should
>> not be in share.

 > Er. Well policy does not allow for this at all. If you do
 > actually have such a thing (it seems unlikely), perhaps you
 > should bring it up on the policy list and ask for a location to
 > put it.

I don't have any and I don't think anyone can make a good point for
any. What reason could there be that I can't read some i386 specific
dokumentation on an alpha and use that e.g. in plex or bochs?
Only exception would be documentation in an executable form, which is
a) evil and b) should be in /usr/bin.

MfG
Goswin

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Josip Rodin]

On Mon, Jan 01, 2001 at 11:47:51PM +0100, Christian Marillat wrote:
> MM> Of course a quick search in there revealed nothing poping up for cdda.
> 
> Very strange. I've find that in unstable :
> usr/include/cdda_interface.hsound/libcdparanoia0-dev
> usr/include/cdda_paranoia.h sound/libcdparanoia0-dev

Ah. The mirror (the Contents-* files in it) on the machine where that CGI
runs is outdated. Known issue.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Christian Marillat]

 "MM" == Michael Meding <[EMAIL PROTECTED]> writes:

[...]

>> http://www.debian.org/distrib/packages

[...]

MM> that was really funny. I am still laughing. Of course a quick search in 
there 
MM> revealed nothing poping up for cdda. But I did the search before I posted 
to 
MM> the list.

MM> Anyway,

MM> I still haven't been able to locate the desired files. Anybody would be so 
MM> kind as to point me to the corresponding package ?

Very strange. I've find that in unstable :

usr/include/cdda_interface.hsound/libcdparanoia0-dev
usr/include/cdda_paranoia.h sound/libcdparanoia0-dev

Christian

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Michael Meding]

On Monday,  1. January 2001 23:25, Christian Marillat wrote:
>  "MM" == Michael Meding <[EMAIL PROTECTED]> writes:
>
> MM> Hi all,
>
> Hi,
>
> MM> in which paket do I find the desired files ?
>
> Here :
>
> http://www.debian.org/distrib/packages
>
> Christian

Hi Christian,

that was really funny. I am still laughing. Of course a quick search in there 
revealed nothing poping up for cdda. But I did the search before I posted to 
the list.

Anyway,

I still haven't been able to locate the desired files. Anybody would be so 
kind as to point me to the corresponding package ?

Thanks in advance

Michael

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Ben Collins wrote:
> How can anything that's a "document" only work on a particular arch? If
> you are talking about pre-compiled examples, well uh, don't precompile
> them.

Actually, policy does allow for that:

 Architecture-specific example files should be installed in a directory
 `/usr/lib//examples', and files in
 `/usr/share/doc//examples' symlink to files in it.  Or the
 latter directory may be a symlink to the former.

And I suppose if there is actually some arch-specific non-example file, by
analogy it can be put in /usr/lib too with a similar symlink.

-- 
see shy jo

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Josip Rodin]

On Mon, Jan 01, 2001 at 11:25:58PM +0100, Christian Marillat wrote:
> MM> in which paket do I find the desired files ?
> 
> Here :
> 
> http://www.debian.org/distrib/packages

And for those who are lazy to type,

http://packages.debian.org/

Heck, most browsers will accept simply "packages.debian.org" :)

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Santiago Vila wrote:
> No, we don't *need* any script to do this. One thing is that dpkg
> allows this to be done and another different one is that we *have* to
> do it. We agreed to make the transition on a per package basis. If we
> consider the transition almost finished and we want an empty /usr/doc
> we have just to *stop* requiring symlinks in maintainer scripts (which
> is something that we would do sooner or later). Once we stop making
> symlinks in /usr/doc, this directory will be emptied by itself,
> cleanly, and without risking the integrity of the system by complex
> scripts.

Take another look at where we are now. If 6 people fix one package a
day until woody is frozen, we might just manage to convert all packages
that do not yet use /usr/share/doc. If that is done, we only have to wait 2
more releases of debian until the transition is complete.

On the other hand, if we use a script now, we can be done tomorrow.

As for risking the integrity of the system with complex scripts, take a
look at the tremendous number of ways that people have managed to screw
this up doing it one package at a time (I just discovered a package that
puts files in /usr/doc/foo with a symlink /usr/share/doc/foo to it;
completly backwards from what policy requires.). Perhaps a single script is
actually likely to be better?

-- 
see shy jo

Re: finishing up the /usr/share/doc transition

[Ben Collins]

On Mon, Jan 01, 2001 at 02:25:24PM -0800, Joey Hess wrote:
> Goswin Brederlow wrote:
> 
> > Maybe I have architecure dependent documentation that should not be in
> > share.
> 
> Er. Well policy does not allow for this at all. If you do actually have
> such a thing (it seems unlikely), perhaps you should bring it up on the 
> policy list and ask for a location to put it.
> 

How can anything that's a "document" only work on a particular arch? If
you are talking about pre-compiled examples, well uh, don't precompile
them.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: finishing up the /usr/share/doc transition

[Santiago Vila]

Ben Collins wrote:
> We just need a script/program that sanely does this transition, then
> creates the /usr/doc -> share/doc symlink.

No, we don't *need* any script to do this. One thing is that dpkg
allows this to be done and another different one is that we *have* to
do it. We agreed to make the transition on a per package basis. If we
consider the transition almost finished and we want an empty /usr/doc
we have just to *stop* requiring symlinks in maintainer scripts (which
is something that we would do sooner or later). Once we stop making
symlinks in /usr/doc, this directory will be emptied by itself,
cleanly, and without risking the integrity of the system by complex
scripts.

Re: Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Christian Marillat]

 "MM" == Michael Meding <[EMAIL PROTECTED]> writes:

MM> Hi all,

Hi,

MM> in which paket do I find the desired files ?

Here :

http://www.debian.org/distrib/packages

Christian

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Goswin Brederlow wrote:
> What is the reason for linking /usr/doc to /usr/hare/doc (or
> share/doc)?

So that packages that are not policy complient and contain files only in
/usr/doc still end up installing them in /usr/share/doc.

> Maybe I have architecure dependent documentation that should not be in
> share.

Er. Well policy does not allow for this at all. If you do actually have
such a thing (it seems unlikely), perhaps you should bring it up on the 
policy list and ask for a location to put it.

-- 
see shy jo

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Ben Collins wrote:
> Exactly, except '6' should be "Link /usr/doc to share/doc", so chrooted
> systems can be more easily maintained.

Yes of course.

I should have a fairly robust script in anouther half hour or so.

-- 
see shy jo

Re: finishing up the /usr/share/doc transition

[Goswin Brederlow]

> " " == Joey Hess <[EMAIL PROTECTED]> writes:

 > So it will need to:

 > 1. Remove all symlinks in /usr/doc that correspond to symlinks
 >or directories with the same names in /usr/share/doc
 > 2. If there are any directories with the same names in /usr/doc
 >and /usr/share/doc, merge them. (And probably whine about it,
 >since that's a bug.)
 > 3. Move any remaining directories and symlinks that are in
 >/usr/doc to /usr/share/doc
 > 4. Move any files in /usr/doc to /usr/share/doc (shouldn't be
 >necessary, but just in case).
 > 5. Remove /usr/doc
 > 6. Link /usr/doc to /usr/share/doc

What is the reason for linking /usr/doc to /usr/hare/doc (or
share/doc)?

Maybe I have architecure dependent documentation that should not be in
share.

This got probably answered a thousand times, but please, just once
more for me.

MfG
Goswin

PS: and don't say so that users looking in /usr/doc find the docs in
/usr/share/doc, users should adapt. :)

Re: rsync'ing pools (Was: Re: DEBIAN IS LOOSING PACKAGES AND NOBODY CARES!!!)

[Joey Hess]

Goswin Brederlow wrote:
> Joey, can you put that where it originally came from? or next to the
> original script? Any changes to the script from your side?

This is much more complicated than anything I want to maintain. I'm
looking forward to making my mirror script simpler as the pool
situations stabalizes actually.

Once more, the url for my most recent version is
http://cvs.kitenet.net/joey-cvs/bin/debmirror

-- 
see shy jo

rsync'ing pools (Was: Re: DEBIAN IS LOOSING PACKAGES AND NOBODY CARES!!!)

[Goswin Brederlow]

> " " == Tinguaro Barreno Delgado <[EMAIL PROTECTED]> writes:

 > Hello again.

 > On Sun, Dec 31, 2000 at 02:22:45PM +, Miquel van
 > Smoorenburg wrote:
>>  Yes. The structure of the archive has changed because of
>> 'package pools'.  You need to mirror 'pool' as well.
>> 
>> Also, "woody" is no longer "unstable". "sid" is. "woody" is
>> "testing".
>> 
>> Mike.
>> 

 > Ok. Thanks to Peter Palfrader too. Then, there is a more
 > complicated issue for those who has a partial mirror (only i386
 > for me), but I think that is possible with rsync options.

There was a script posted here to do partial rsync mirrors.

I used that script and added several features to it. Whats missing is
support for the debian-installed in sid, but I'm working on that.

Changes:
- multiple architectures
- keep links from woody -> potato
- mirror binary-all
- mirror US and non-US pools
- use last version as template for new files
- mirror disks

People intrested in only one arch and only woody/sid should remove
binary-all and should resolve links.

Joey, can you put that where it originally came from? or next to the
original script? Any changes to the script from your side?

So heres the script for all who care:

--
#!/bin/sh -e
# Anon rsync partial mirror of Debian with package pool support.
# Copyright 1999, 2000 by Joey Hess <[EMAIL PROTECTED]>, GPL'd.
# Add ons by Goswin Brederlow <[EMAIL PROTECTED]>

# update potato/woody files and Packages.gz or use old once? If you
# already have the new enough once say yes. This is for cases when you
# restart a scan after the modem died.
# No is the save answere here, but wastes bandwith when resumeing.
HAVE_PACKAGE_FILES=no

# Should a contents file kept updated? Saying NO won't delete old
# Contents files, so when resuming you might want to say no here
# temporarily.
CONTENTS=yes

# Flags to pass to rsync. More can be specified on the command line.
# These flags are always passed to rsync:
FLAGS="$@ -rlpt --partial -v --progress"
# These flags are not passed in when we are getting files from pools.
# In particular, --delete is a horrid idea at that point, but good here.
FLAGS_NOPOOL="$FLAGS --exclude Packages --delete"
# And these flags are passed in only when we are getting files from pools.
# Remember, do _not_ include --delete.
FLAGS_POOL="$FLAGS"
# The host to connect to. Currently must carry both non-us and main
# and support anon rsync, which limits the options somewhat.
HOST=ftp.de.debian.org
# Where to put the mirror (absolute path, please):
DEST=/mnt/raid/rsync-mirror/debian
# The distribution to mirror:
DISTS="sid potato woody"
# Architecture to mirror:
ARCHS="i386 alpha m68k"
# Should source be mirrored too?
SOURCE=yes
# The sections to mirror (main, non-free, etc):
SECTIONS="main contrib non-free"
# Should symlinks be generated to every deb, in an "all" directory?
# I find this is very handy to ease looking up deb filenames.
SYMLINK_FARM=no

###

mkdir -p $DEST/dists $DEST/pool

# Snarf the contents file.
if [ "$CONTENTS" = yes ]; then
for DIST in ${DISTS}; do
for ARCH in ${ARCHS}; do
echo Syncing  $DEST/dists/${DIST}/Contents-${ARCH}.gz
rsync $FLAGS_NOPOOL \
$HOST::debian/dists/$DIST/Contents-${ARCH}.gz \
$DEST/dists/${DIST}/
echo Syncing  
$DEST/non-US/dists/${DIST}/non-US/Contents-${ARCH}.gz
rsync $FLAGS_NOPOOL \

$HOST::debian-non-US/dists/$DIST/non-US/Contents-${ARCH}.gz \
$DEST/non-US/dists/${DIST}/non-US/
done
done
fi

# Generate list of archs to download
ARCHLIST="binary-all"
DISKS_ARCHLIST=""
NONUS_ARCHLIST="binary-all"

for ARCH in ${ARCHS}; do
ARCHLIST="${ARCHLIST} binary-${ARCH}"
DISKS_ARCHLIST="${DISKS_ARCHLIST} disks-${ARCH}"
NONUS_ARCHLIST="${NONUS_ARCHLIST} binary-${ARCH}"
done

if [ "$SOURCE" = yes ]; then
ARCHLIST="${ARCHLIST} source"
NONUS_ARCHLIST="${NONUS_ARCHLIST} source"
fi

# Download packages files (and .debs and sources too, until we move fully
# to pools).

if [ x$HAVE_PACKAGE_FILES != xyes ]; then
for DIST in ${DISTS}; do
for section in $SECTIONS; do
for type in ${ARCHLIST}; do
echo Syncing  $DEST/dists/$DIST/$section/$type
mkdir -p $DEST/dists/$DIST/$section/$type
rsync $FLAGS_NOPOOL \
$HOST::debian/dists/$DIST/$section/$type \
$DEST/dists/$DIST/$section/
done
if [ $section = "main" ]; then
  if [ $DIST != "sid" ]; then
for type in ${DISKS_ARCHLIST}; do
echo Syncing  $DEST/dists/$DIST/$section/$type
mkdir -p $DEST/dists/$DIST/$section/$type
rsync $FLAGS_NOPO

Where to find cdda_inteface.h and cdda_paranoia.h in ?

[Michael Meding]

Hi all,

in which paket do I find the desired files ?

Thanks in advance

Michael Meding

Re: finishing up the /usr/share/doc transition

[Ben Collins]

On Mon, Jan 01, 2001 at 12:20:32PM -0800, Joey Hess wrote:
> 
> So it will need to:
> 
> 1. Remove all symlinks in /usr/doc that correspond to
>symlinks or directories with the same names in /usr/share/doc
> 2. If there are any directories with the same names in /usr/doc and
>/usr/share/doc, merge them. (And probably whine about it, since
>that's a bug.)
> 3. Move any remaining directories and symlinks that are in /usr/doc to
>/usr/share/doc
> 4. Move any files in /usr/doc to /usr/share/doc (shouldn't be necessary,
>but just in case). 
> 5. Remove /usr/doc
> 6. Link /usr/doc to /usr/share/doc
> 

Exactly, except '6' should be "Link /usr/doc to share/doc", so chrooted
systems can be more easily maintained.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: finishing up the /usr/share/doc transition

[Joey Hess]

Ben Collins wrote:
> I think we need to reevaluate this decision based on the fact that the bug
> in dpkg that forced this implementation (as opposed to a clean /usr/doc
> symlink to share/doc) has been gone for awhile now (the potato dpkg is
> fixed).
> 
> For those that do not remember, the bug in dpkg would have caused doc
> files to go missing if /usr/doc was a symlink to share/doc, once a package
> was upgraded from the latter to the former (docs in /usr/share/doc).
> 
> That is no longer the case, so I would hope that our efforts would be
> better spent writing a transition script to handle the move (moving things
> from /usr/doc to /usr/share/doc, if needed, and removing symlinks).

Well I guess that would be ok; it would certianly be easier.

> We just need a script/program that sanely does this transition, then
> creates the /usr/doc -> share/doc symlink.

So it will need to:

1. Remove all symlinks in /usr/doc that correspond to
   symlinks or directories with the same names in /usr/share/doc
2. If there are any directories with the same names in /usr/doc and
   /usr/share/doc, merge them. (And probably whine about it, since
   that's a bug.)
3. Move any remaining directories and symlinks that are in /usr/doc to
   /usr/share/doc
4. Move any files in /usr/doc to /usr/share/doc (shouldn't be necessary,
   but just in case). 
5. Remove /usr/doc
6. Link /usr/doc to /usr/share/doc

-- 
see shy jo

Re: Questions about testing

[Manoj Srivastava]

>>"Anthony" == Anthony Towns  writes:

 Anthony> Well, even Joey Hess has slipped up in his religious debconf
 Anthony> uploads and had four or five delays longer than a fortnight
 Anthony> between updates. Basically, though, at some point the
 Anthony> maintainer has to decide "I'm happy with this" and leave
 Anthony> well enough alone for a little while.

Umm. This is an artifact of the implementation, and does not
 seem to have a rational design principle behind it, unless I am being
 very dense. If this is an implementation issue, we should note this
 flaw (and perhaps move on until someone can come up with a working
 solution)

 Anthony> At worst, this could be done just before the freeze,
 Anthony> although that seems like it'd be a bit risky. Alternatively,
 Anthony> the maintainer can just upload it with a faked medium or
 Anthony> high priority so that it'll go in earlier.

In the long term this needs to be reexamined. Perhaps
 da-katies successors need to be tweaked to allow more than one
 version in a distribution to stay in the pool, or something (I
 confess I have not looked deeply into the problem, so my suggestions
 may be totally (in the modern idiom), whack. I have little time to
 work on the tweaks, so I'll hold my peace. 

 >> 4. How can I know precisely why my package has not been included in
 >> testing. I know update_excuse.html on ajt website ... but that's not
 >> enough. I want to know for example that my libdbd-pg-perl package is
 >> waiting on perl-5.6 (or on postgresql) to be integrated ...

 Anthony> You have to look at your dependency list, and investigate it
 Anthony> yourself. :( 

Where does the pice of code reside that determines whether or
 not a package is going to be moved into testing? Can one extract that
 code into a purely reporting agent?

manoj
-- 
 I BET WHEN NEANDERTHAL KIDS would make a snowman, someone would
 always end up saying, "Don't forget the thick heavy brows."  Then
 they would get embarrassed because they remembered they had the big
 hunky brows too, and they'd get mad and eat the snowman. Jack
 Handley, The New Mexican, 1988.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Linux Progress Patch for Debian available!

[idalton]

On Sun, Dec 31, 2000 at 02:42:25PM -0800, Joey Hess wrote:
> Bernd Eckenfels wrote:
> > AFAIK there is a problem with this patch since some of the copyright
> > messages of the drivers are not displayed anymore. since some of them
> > require the Copyright announcement, this is a violation of the license. As
> > far as I know that was the reason for not putting that patch into the
> > kernel, long ago.
> 
> Can you show me an example of such a license?

And not to be pedantic or anything, but how are these Copyright
announcements handled on a machine that boots headless? I would think
that would be just the same violation of the license.

-- Ferret

Who recalls a cddb access program designed for blind people where
cddb.com DENIED a certification because the program couldn't display a
graphical logo where the blind people could see it.

Re: ITP: ttf-xtt, xfonts-xtt

[ISHIKAWA Mutsumi]

> In <[EMAIL PROTECTED]> 
>   Josip Rodin <[EMAIL PROTECTED]> wrote:
>> On Mon, Jan 01, 2001 at 05:57:35AM +0900, ISHIKAWA Mutsumi wrote:
>> >  ttf-xtt is Free Japanese TrueType fonts include watanabe-mincho and
>> > wadalab-gothic (converted by me, used cb2ttj)
>> > 
>> >  xfont-xtt is psude package to use ttf-xtt on X. It includes
>> > fonts.scale and fonts.alias
>> > 
>> > Package: ttf-xtt-watanabe-mincho, ttf-xtt-wadalab-gothic
>> > Package: xfonts-xtt-wadalab-gothic, xfonts-xtt-watanabe-mincho

>> Can't you include ttf-xtt-* inside xfonts-xtt-* packages?

 TrueType fonts are not only for X. I'll packaging tfm-xtt-* packge
to use these TrueType fonts on TeX like Anthony's ttf-arphic-*
xfonts-archic-*, tfm-arphic-* packages (These are provides nice
Chinese TrueType fonts :)

 So, I want to separate TrueType fonts and meta datas such that
fonts.scale and fonts.alias included in xfonts-xtt-*.

-- 
ISHIKAWA Mutsumi
 <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>

Re: ITP: ttf-xtt, xfonts-xtt

[Josip Rodin]

On Mon, Jan 01, 2001 at 05:57:35AM +0900, ISHIKAWA Mutsumi wrote:
>  ttf-xtt is Free Japanese TrueType fonts include watanabe-mincho and
> wadalab-gothic (converted by me, used cb2ttj)
> 
>  xfont-xtt is psude package to use ttf-xtt on X. It includes
> fonts.scale and fonts.alias
> 
> Package: ttf-xtt-watanabe-mincho, ttf-xtt-wadalab-gothic
> Package: xfonts-xtt-wadalab-gothic, xfonts-xtt-watanabe-mincho

Can't you include ttf-xtt-* inside xfonts-xtt-* packages?

-- 
Digital Electronic Being Intended for Assassination and Nullification

Potato r2 ChangeLog issues

[Steve McIntyre]

I've finally found the time to investigate further the problems I had
with the ChangeLog which cropped up when I started writing the
debian-cd update-cd script. The following files have changed in
between the 2.2r0 and 2.2r2 release but are NOT listed in the
ChangeLog. I've compared the contents of the .list files from CD image
production runs from r0 and r2, then compared that diff against the
ChangeLog.

Some of the changes are understandable - a few for other
architectures, and lots of powerpc changes that simply seem to be
recompiles needed to catch up with the released source versions - was
the powerpc autobuilder struggling to keep up before we released
potato r0?

The others are more annoying - it looks like the package pools change
has caused some source packages to move from their original sections
into the top-level source directory.

As far as I can tell this accounts for everything. The recompile
changes will be missed by the update-cd script, which is a pain. It
will also not see the source moves, but this is not a problem.

Comments?

=

dists/potato/contrib/binary-all/x11/metro-motif-bin_2.0-2.deb
dists/potato/contrib/binary-all/x11/metro-motif-demobin_2.0-2.deb
dists/potato/contrib/binary-all/x11/metro-motif-demosrc_2.0-2.deb
dists/potato/contrib/binary-all/x11/metro-motif-devel_2.0-2.deb
dists/potato/contrib/binary-all/x11/metro-motif-lib_2.0-2.deb
dists/potato/contrib/binary-arm/x11/gpgp_0.4-4.deb
dists/potato/main/binary-arm/interpreters/python-gdk-imlib_0.6.3-5.deb
dists/potato/main/binary-arm/interpreters/python-gnome_1.0.50-5.deb
dists/potato/main/binary-arm/math/gnumeric_0.47-1.deb
dists/potato/main/binary-powerpc/admin/gnome-print_0.10-5.deb
dists/potato/main/binary-powerpc/devel/adasockets_0.1.4-1.deb
dists/potato/main/binary-powerpc/devel/glutg3+ggi-dev_3.0-7.deb
dists/potato/main/binary-powerpc/devel/libape-dev_1.0.0-3.deb
dists/potato/main/binary-powerpc/devel/libaspell-dev_0.29.1-1.deb
dists/potato/main/binary-powerpc/devel/libgimp1.1.17-dev_1.1.17-3.deb
dists/potato/main/binary-powerpc/devel/libgnomemm-dev_1.0.3-1.1.deb
dists/potato/main/binary-powerpc/devel/libgtkmm-dev_1.0.3-1.1.deb
dists/potato/main/binary-powerpc/devel/libmhash-dev_0.6.1-1.deb
dists/potato/main/binary-powerpc/devel/libmm10-dev_1.0.11-1.deb
dists/potato/main/binary-powerpc/devel/libmm10_1.0.11-1.deb
dists/potato/main/binary-powerpc/devel/libnspr3-dev_M14-2.deb
dists/potato/main/binary-powerpc/devel/librep-dev_0.9-2.deb
dists/potato/main/binary-powerpc/devel/libsidplay1.36-dev_1.36.35-2.deb
dists/potato/main/binary-powerpc/devel/libsigc++-dev_0.8.5-2.deb
dists/potato/main/binary-powerpc/devel/libsmi1-dev_0.1.7-1.deb
dists/potato/main/binary-powerpc/devel/vibrant-dev_6.0.2-1.deb
dists/potato/main/binary-powerpc/editors/ted_2.6-1.deb
dists/potato/main/binary-powerpc/games/xsol_0.31-3.1.deb
dists/potato/main/binary-powerpc/graphics/gimp1.1-perl_1.1.17-3.deb
dists/potato/main/binary-powerpc/graphics/gimp1.1_1.1.17-3.deb
dists/potato/main/binary-powerpc/graphics/sane-gimp1.1_1.0.1-1999-10-21-12.deb
dists/potato/main/binary-powerpc/graphics/terraform_0.5.2-1.deb
dists/potato/main/binary-powerpc/graphics/xsane-gimp1.1_0.50-5.deb
dists/potato/main/binary-powerpc/interpreters/gimp-python_0.5-7.deb
dists/potato/main/binary-powerpc/interpreters/libmd5-ruby_1.4.3-5.deb
dists/potato/main/binary-powerpc/interpreters/rep-gtk_0.7-1.deb
dists/potato/main/binary-powerpc/interpreters/rep_0.9-2.deb
dists/potato/main/binary-powerpc/libs/glutg3+ggi_3.0-7.deb
dists/potato/main/binary-powerpc/libs/lesstifg_0.89.4-3.deb
dists/potato/main/binary-powerpc/libs/libape1_1.0.0-3.deb
dists/potato/main/binary-powerpc/libs/libaspell4_0.29.1-1.deb
dists/potato/main/binary-powerpc/libs/libgimp1.1.17_1.1.17-3.deb
dists/potato/main/binary-powerpc/libs/libgnomemm_1.0.3-1.1.deb
dists/potato/main/binary-powerpc/libs/libgtkmm_1.0.3-1.1.deb
dists/potato/main/binary-powerpc/libs/libmhash1_0.6.1-1.deb
dists/potato/main/binary-powerpc/libs/libnspr3_M14-2.deb
dists/potato/main/binary-powerpc/libs/librep5_0.9-2.deb
dists/potato/main/binary-powerpc/libs/libsidplay1.36_1.36.35-2.deb
dists/potato/main/binary-powerpc/libs/libsigc++5_0.8.5-2.deb
dists/potato/main/binary-powerpc/libs/libsmi1_0.1.7-1.deb
dists/potato/main/binary-powerpc/libs/vibrant6_6.0.2-1.deb
dists/potato/main/binary-powerpc/math/gnumeric_0.45-1.deb
dists/potato/main/binary-powerpc/math/xmgr_4.1.2-2.3.deb
dists/potato/main/binary-powerpc/misc/mysql-gpl-client_3.22.30-2.deb
dists/potato/main/binary-powerpc/misc/xacc_1.0.18-4.deb
dists/potato/main/binary-powerpc/net/rexec_1.5-2.deb
dists/potato/main/binary-powerpc/otherosfs/cdrdao_1.1.3-3.deb
dists/potato/main/binary-powerpc/sound/freeamp_1.3.1-5.deb
dists/potato/main/binary-powerpc/sound/sidplay_1.36.35-2.deb
dists/potato/main/binary-powerpc/sound/xsidplay_1.3.8-5.deb
dists/potato/main/binary-powerpc/text/aspell_0.29.1-1.deb
dists/potato/main/binary-powerpc/utils/gaspell_0.29.1-1.deb
dists/potato/main/binary-powerpc/x11

Re: ITP kimberlite - was Re: High Availability..

[Michael Boman]

Quoting Russell Coker <[EMAIL PROTECTED]>:

> On Thursday 28 December 2000 17:23, Michael Boman wrote:
> > Nate Duehr wrote:
> > > On Fri, Oct 06, 2000 at 01:13:50PM +0200, Roger Abrahamsson wrote:
> > > > Hello..
> > > > Has anyone tried to set up any such debian systems?? I'm thinking
> of
> > > > trying to set up two machines sharing the same raid disksystem as
> an
> > > > NFS server with some sort of ip-takeover between them.. There are
> > > > several things I'm seeing as possible problems, one is NFS file
> > > > locking, and another is two RAID cards accessing the same disk
> > > > subsystem...
> > > >
> > > > Any suggestions and comments are welcome, as this is totally new
> > > > territory to me.
> > >
> > > A good starting point for Linux High Availability projects is
> > > www.linux-ha.org -- good pointers/links to various open projects.
> >
> > I also recomend Kimberlite
> > (http://oss.missioncriticallinux.com/kimberlite). Kimberlite is GPL,
> is
> > debian ready (you need to create the .deb's yourself, but that's easy)
> > and is designed to work in a shared disk enviroment.
> 
> Do you have any patches for creating Debian packages for kimberlite?  If
> so 
> please send them to me.
> 
> I intend to package it.  It is under the GPL license.  It is a system
> for 
> managing clusters of Linux machines.

Unpack the tar-ball, cd the source dir and run "dpkg-buildpackage" and you are
already set =)

/Mike

> 
> -- 
> http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
> http://www.coker.com.au/projects.html Projects I am working on
> http://www.coker.com.au/~russell/ My home page
> 

Re: Problem with pcmcia-modules and kernel-image

[Raphael Hertzog]

Le Sun, Dec 31, 2000 at 05:07:33PM -0500, Brian Mays écrivait:
> > actually the postint does call depmod -a only if the current kernel is
> > the one for which the modules have been compiled, shouldn't it call
> > depmod -a  instead ?
> 
> Well, that only works if the appropriate kernel version has already
> been installed, something that the pcmcia-modules package cannot
> ensure.

Sure ? Actually pcmcia-modules-2.2.18 depends on kernel-image-2.2.18... so
when the pcmcia-modules postinst is called you can be sure that that the
kernel-image is at least unpacked (but it may not be configured, to ensure
that you'd need a pre-depends)... 

Cheers,
-- 
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Le bouche à oreille du Net : http://www.beetell.com
Naviguez sans se fatiguer à chercher : http://www.deenoo.com
Formation Linux et logiciel libre : http://www.logidee.com

Re: Huh, gcc 2.95.3?

[Ben Collins]

On Mon, Jan 01, 2001 at 04:47:55PM +0100, Harald Dunkel wrote:
> Ben Collins wrote:
> > 
> > On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote:
> > > Happy new year to everyone!
> > >
> > > gcc 2.95.3 appeared in Sid, but it hasn't been announced by the
> > > GCC steering committee yet. Is this some kind of early access
> > > version?
> > 
> > It's based on the CVS branch, which is noted in the changelog if you had
> > bothered to read it. 
> 
> To read the changelog I have to download and install it. But I don't
> like to install unknown compilers on my development machines. Especially
> since there is no undo operation for dpkg -i.

To read the changelog, you do not have to install it.

> > There's no such thing as "early access", this is
> > open source you know :)
> > 
> 
> My (personal) definition for 'Early Access Software' is that somebody 
> has grabbed a more or less stable version with the knowledge of the 
> maintainers before the official release date. I cannot see why 
> this definition shouldn't be applicable to GPL software.

To me "Early Access" is a commercial buzz word that means "some special
people get access before everyone else".

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: Huh, gcc 2.95.3?

[Harald Dunkel]

Ben Collins wrote:
> 
> On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote:
> > Happy new year to everyone!
> >
> > gcc 2.95.3 appeared in Sid, but it hasn't been announced by the
> > GCC steering committee yet. Is this some kind of early access
> > version?
> 
> It's based on the CVS branch, which is noted in the changelog if you had
> bothered to read it. 

To read the changelog I have to download and install it. But I don't
like to install unknown compilers on my development machines. Especially
since there is no undo operation for dpkg -i.

> There's no such thing as "early access", this is
> open source you know :)
> 

My (personal) definition for 'Early Access Software' is that somebody 
has grabbed a more or less stable version with the knowledge of the 
maintainers before the official release date. I cannot see why 
this definition shouldn't be applicable to GPL software.


Regards

Harri

Re: libgd's dependency on xlib stops netsaint from "testing"

[Sander Smeenk \(CistroN Medewerker\)]

Quoting Bernd Eckenfels ([EMAIL PROTECTED]):

> It would be nice if you can avoid using xlibs, which
> in turn depends in xfree86-common.

A simple solution for this would be to make libgd1 *suggest* xlibs, but
not depend on it. Since libgd1 will work when xlibs is not installed (eg.
purged with --force-depends), only xpm support will be broken.

I have not really tested this situation, but it's the most logical result.

Regards,
Sander.

-- 
| I'm a lousy dancer but my moods are swinging!
| CistroN Internet Services, Linux Specialists & Perl Experts
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D

Re: Huh, gcc 2.95.3?

[Ben Collins]

On Mon, Jan 01, 2001 at 04:03:45PM +0100, Harald Dunkel wrote:
> Happy new year to everyone!
> 
> gcc 2.95.3 appeared in Sid, but it hasn't been announced by the 
> GCC steering committee yet. Is this some kind of early access 
> version?

It's based on the CVS branch, which is noted in the changelog if you had
bothered to read it. There's no such thing as "early access", this is
open source you know :)

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Huh, gcc 2.95.3?

[Harald Dunkel]

Happy new year to everyone!

gcc 2.95.3 appeared in Sid, but it hasn't been announced by the 
GCC steering committee yet. Is this some kind of early access 
version?


Regards

Harri

lilo 21.6

[Russell Coker]

I have accepted Vincent's offer to take over packaging of LILO.

I have prepared a test package and it is online on 
http://www.coker.com.au/lilo/ .  I will upload it to unstable shortly if I 
don't receive any complaints and I don't discover that I have done anything 
wrong.

Currently there is no lilo-doc package.  I will create one as soon as one of 
two things happens:
1)  I work out how to get latex going properly without root access.
2)  The upstream maintainer releases a separate archive with the PS files as 
the documentation says he will.

Here is the changelog:
lilo (1:21.6-0) unstable; urgency=MEDIUM
 
  * Debianized the new version.
Closes:#80551
Closes:#75386
Closes:#75387
 
  * Made liloconfig devfs aware and made it use mode 0600 for creating files.
Closes:#56906
Closes:#62540
 
  * Included lilo.conf(5)
Closes:#58202
Closes:#64783
Closes:#65120
Closes:#65820
Closes:#71053
Closes:#75902
Closes:#80482
 
  * Lilo adds the boot-menu.b file which gives a colored menu.  I think it
solves the problem of no color on boot.
Closes:#69253

 -- Russell Coker <[EMAIL PROTECTED]>  Mon, 1 Jan 2000 21:41:29 +1100

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: default mailbox for Netscape

[Daniel Stone]

> On Mon, Jan 01, 2001 at 02:35:46PM +1100, Daniel Stone wrote:
> > > I am running exim for my local network and would like to be able to pop 
> > > mail from the mail machine using netscape. What is the defaul
t ma
> > ilbox netscape tries to open on the mail server?
> > 
> > what the hell is this?
> > a) it's simple, RTFM RTFM RTFM.
> 
> It's a fair question. For example, do some of the POP servers support
> Maildir format? A mailbox could live in a couple of different places
> on the server... /var/spool/mail, or in a user's home directory,
> or maybe somewhere else entirely if root has configured it that way.

mis-read the question, that's what happens on new year's, fuelled by liquid
un-coordination ;)

> > b) the sender name?!?
> 
> The email address is valid (or at least there is an MX record for the
> domain). 

yeah, I thought it could've been a bi-directional list feeder or something.

> > c) wtf is this kinda crap doing on debian-devel? (hope I don't cause a loop
> > here)
> 
> It belongs on debian-user.

too right

Re: default mailbox for Netscape

[Hamish Moffatt]

On Mon, Jan 01, 2001 at 02:35:46PM +1100, Daniel Stone wrote:
> > I am running exim for my local network and would like to be able to pop 
> > mail from the mail machine using netscape. What is the default ma
> ilbox netscape tries to open on the mail server?
> 
> what the hell is this?
> a) it's simple, RTFM RTFM RTFM.

It's a fair question. For example, do some of the POP servers support
Maildir format? A mailbox could live in a couple of different places
on the server... /var/spool/mail, or in a user's home directory,
or maybe somewhere else entirely if root has configured it that way.

> b) the sender name?!?

The email address is valid (or at least there is an MX record for the
domain). 

> c) wtf is this kinda crap doing on debian-devel? (hope I don't cause a loop
> here)

It belongs on debian-user.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: default mailbox for Netscape

[Hamish Moffatt]

On Sun, Dec 31, 2000 at 06:33:37PM -0700, developer list wrote:
> I am running exim for my local network and would like to be able to pop mail 
> from the mail machine using netscape. What is the default mailbox netscape 
> tries to open on the mail server?

Art,

POP always opens the inbox. The actual mailbox file used is up to
the POP daemon you're running, which could be cucipop, qpopper,
or ipopd or something else.

qpopper(8) says that qpopper gets mail from /var/spool/mail/.

If you need to access multiple mail folders on the server, try IMAP.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Boxed Penguin Prototype showcases customization of Debian to build infrastructure server

[Bernd Eckenfels]

Hello Sam,

On Sat, Dec 30, 2000 at 11:27:44PM -0500, Sam Hartman wrote:
>In order to actually get something done in an electronic office, we
>need a certain amount of infrastructure.

Thanks for your work. I'm now looking into it. I think besides the packages
you are working on, for a prototype, most of the work which needs to be
done, is have some documentation. Background info and so on. This is at
least needed, until your System is truely Plug+Play.

Since I currently need to set up a shared Account System on a Few Linux
Servers (CVS File Server, SourceForge Project Management and Bugzilla
Tracker) I may have a deeper look into writing some docu about it.

Unfortunatelly I dont have any idea about PAM/LDAP, Kerberos or AFS, so I
have to educate myself on those topics :)

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!