sendmail 8.12.0 problem

[J. R. Westmoreland]

I installed sendmail 8.12.0 and had problems delivering mail to local users.
I get a "Service Unavailable".
If I send from the local machine root gets a message indicating that
setreuid got a "Operation not permitted".
What am I doing wrong?

Please reply to me direct since I have not yet resubscribed to the mailing list.

J.R.


-- 
J.R. Westmoreland  (W7JR)
E-mail: [EMAIL PROTECTED]

Re: problems with binary NMU and apt

[Gerhard Tonn]

>Which packages are these? It's probably a bug in the package source, in
>that it's coded in such a way that bin-nmu's aren't possible. There're
>a bunch of packages like that. (ie, a Depends: otherpkg (= myver) line)

In my case it's esound-common, which in turn makes the entire gnome tree not 
installable.

Regards,
Gerhard

Re: problems with binary NMU and apt

[Gerhard Tonn]

On Saturday 15 September 2001 07:29, you wrote:
> In my case it's esound-common, which in turn makes the entire gnome tree
> not installable.

Most of the esound packages have a 'esound-common (>= ${Source-Version})'
dependency in debian/control. Is there any generic solution for the problem?

Regards,
Gerhard

Re: Orphaning all packages

[Lars Wirzenius]

On 14 Sep 2001 16:37:20 +0200, Martin Albert wrote:
> > I'm about to take an extended vacation from being a Debian developer,
> Think i would miss you, but to take your word: how about prototyping 
> co-maintenance on publib-dev? With a good upstream ... ;)
> Some pkg i happen to have to compile now&then depends on it, so i 
> wouldn't be too happy to see it go ;)
> 
> I'm not keen on having another pkg, want to get back more on cthugha 
> upstream myself, but ..., may be even somebody else steps forward?

I'm afraid I don't really want to be co-maintainer either. Sorry.

-- 
Lars Wirzenius <[EMAIL PROTECTED]>

Re: root rm: Permission denied - solution found

[Edward Betts]

"Tille, Andreas" <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Sep 2001, Edward Betts wrote:
> 
> > I had the same problem, just worked out how to fix it, I used the chattr
> > program, see the chattr man page for more details.
> Could you please be a little bit more detailed?
> 
> # chattr -V -i postgres.log.7.gz
> chattr 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09
> chattr: Permission denied while trying to stat postgres.log.7.gz

chattr -V -ai postgres.log.7.gz maybe?

-- 
Edward Betts (GPG: 1BC4E32B)

RMMODing a console font

[Marvin Stodolsky]

Debian was easily installed on my Gateway Solo 3500 laptop, with ATI
Mach64 Rage Mobility graphics card
The best VGA console fonts are obtained by 
# insmod atyfb
providing slim 80x30 fonts.  However Xwindows does not stabilize
subsequently with this driver active, AND
# rmmod atyfb
fails because the driver is in use on the active console.

To circumvent this problem short of rebooting,
I've tried variants of a script executed in background (&)

#!/bin/sh
deallocvt 
deallocvt tty$0
rmmod atyfb
chvt tty$0
--
to kill the console
remove atyfb
restart the console.

But thus far attempts have failed.
Can anyone skilled in console issues provide some advice.

MarvS


[3]+  Exit 1  ./KC 0
stodolsklap:~# ./KC 0 &
[2] 1564
deallocvt: 0: illegal VT number
stodolsklap:~# chvt: VT_ACTIVATE: No such device or address like:

Re: New update_excuses output

[Paul Slootman]

On Sat 15 Sep 2001, Anthony Towns wrote:

> As of the next dinstall/testing run (a few hours away yet) there'll be a
> new set of lines in the update_excuses output [0] (NB: it's now over a MB so
> it's quite long and tedious). They look like:

Would it be possible to also offer a compressed version of these files
(update_excuses.html, update_output.txt, etc)? Most browsers can handle
uncompressing these on the fly and it makes accessing these lists MUCH
faster. As a porter I often use update_excuses for tracking down
packages that are out of date (on alpha) for longer than normal (usually
indicating a problem that can't be handled by the build daemon), and
hence look at that list quite regularly.


Thanks,
Paul Slootman

Re: proposal for an Apache (web server) task force

[Martin F Krafft]

also sprach Ardo van Rangelrooij (on Fri, 14 Sep 2001 07:06:52PM -0500):
> Please do.  Something like '[EMAIL PROTECTED]' or so?  I'm still gonna
> file against lists.debian.org.  Once that is created we can move over.  Do you
> also support archiving?  That would be really great.

alright. doing so right now. if you could give me the email addys of
the involved.

> > >  - putting together a web page similar to that of the X Strike Force
> > >with a link to the packages and their bug lists, a todo list, etc.
> > 
> > i can host.
> 
> Great.  Can you give all involved access?

sure thing. *** PLEASE CONTACT ME DIRECTLY IF YOU NEED ACCESS ***

> > >  - setting up a CVS archive somewhere 
> > 
> > ditto.
> 
> Great.  I'm sitting behind an analog line of 24k or so and I'll
> probably keep my own local CVS archive but will of course keep in
> sync with the official one.

word up.

> Thanks for providing all this. :-)

no problem. i do have to say a couple of things, mainly that my server
is 4000 miles away. i can administer it fine, but if it goes down,
then there may not be anything i can do for you. we'll just make it a
temporary solution... i am not worried, just saying that we should not
rely on it too much and keep backups at other places - easy to do with
CVS...

on a related note, i just got a change of pace for work and i am
starting to question, how much activity i can contribute. i'll host
all the stuff, and i'll be subscribed, but in terms of helping, i'll
see what goes on, and jump in if i can.

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
i took an iq test and the results were negative.


pgpPUNrhCMgjr.pgp
Description: PGP signature

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Josip Rodin]

On Fri, Sep 14, 2001 at 06:37:08PM -0400, Matt Zimmerman wrote:
> > > ...and the new prerm remove it, and future versions of these scripts
> > > until the end of ti^W^W^Wrelease after next...
> > 
> > Actually, if you'd also ship the symlink in the new .deb, dpkg would
> > remove it. Or am I missing your point?
> 
> I haven't actually tried this, so I'll take your word for it that dpkg
> wouldn't complain about the symlink in the new .deb vs. the directory in
> the filesystem.

Yes, it won't complain, but unless you handle it manually it won't create the
symlink, it will just leave an empty directory.

-- 
 2. That which causes joy or happiness.

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Edward Betts]

Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 13-Sep-01, 18:37 (CDT), Edward Betts <[EMAIL PROTECTED]> wrote: 
> > Debconf question: do you want a symlink.
> 
> Please, no. The fact that debconf provides an easy, consistent way to
> interact with the user does not mean that every possible choice that
> a package makes needs to ask the user. If I wanted to make all the
> choices, I'll build from source :-). Either put in the symlink, or
> don't, but don't bug me about it.

Your scheme works, but at least tell the sys admin what is going on with a
debconf note.

If you don't want to be bugged change the debconf priority.

-- 
Edward Betts (GPG: 1BC4E32B)

Debugging help for dhelp needed

[Stefan Hornburg Racke]

Hello, fellow Debian developers !

dhelp was recently orphaned. IMHO a online help is quite a good idea,
but the code hasn't touched quite a while.

I ported the source code from db1 to db2, which is definitely needed
to make it work for woody.

Unfortunately dhelp_parse -r get stucked in the second call 
of db_write (db->put). I debugged it, but I have still no
clue why this happens.

Any help on this is greatly appreciated. I attached the source code
for dhelp_parse and the Makefile.

Bye
Racke

-- 
Racke happily hacks Interchange and maintains Debian packages like Courier.

For projects and other business stuff please refer to COBOLT NetServices
(URL: http://www.cobolt.net; Email: [EMAIL PROTECTED]; Phone: 0041-1-3884400)


dhelp_parse.c
Description: Binary data


Makefile
Description: Binary data

Re: New update_excuses output

[Steve Kowalik]

On Sat, Sep 15, 2001 at 01:53:03PM +0200, Paul Slootman uttered:
> Would it be possible to also offer a compressed version of these files
> (update_excuses.html, update_output.txt, etc)? Most browsers can handle
> uncompressing these on the fly and it makes accessing these lists MUCH
> faster. As a porter I often use update_excuses for tracking down
> packages that are out of date (on alpha) for longer than normal (usually
> indicating a problem that can't be handled by the build daemon), and
> hence look at that list quite regularly.
> 
That may also involve installing mod_gzip on ftp-master.
-- 
Steve
"What are we going to do tonight, Bill?"
"Same thing we do every night Steve, try to take over the world!"


pgpvpLg1cAm6o.pgp
Description: PGP signature

Re: Debugging help for dhelp needed

[Christian Marillat]

 "SH" == Stefan Hornburg <[EMAIL PROTECTED]> writes:

> Hello, fellow Debian developers !

Hi,

> dhelp was recently orphaned. IMHO a online help is quite a good idea,
> but the code hasn't touched quite a while.

> I ported the source code from db1 to db2, which is definitely needed
> to make it work for woody.

db3 would be better.

 $ dpkg -s dhelp
Package: dhelp
Status: install ok installed
Priority: optional
Section: doc
Installed-Size: 119
Maintainer: Marco Budde <[EMAIL PROTECTED]>
Version: 0.3.23.2
Depends: libc6 (>= 2.2.3-7), libdb3 (>= 3.2.9-1)

> Unfortunately dhelp_parse -r get stucked in the second call 
> of db_write (db->put). I debugged it, but I have still no
> clue why this happens.

For me with db3 this work fine.

Tell me if you need some help.

Christian

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Steve Greenland]

On 15-Sep-01, 09:14 (CDT), Edward Betts <[EMAIL PROTECTED]> wrote: 
> Steve Greenland <[EMAIL PROTECTED]> wrote:
> > On 13-Sep-01, 18:37 (CDT), Edward Betts <[EMAIL PROTECTED]> wrote: 
> 
> Your scheme works, but at least tell the sys admin what is going on with a
> debconf note.
> 
> If you don't want to be bugged change the debconf priority.

I've got it set to "high". Apparently a number of maintainers think that
every little thing is of "high" importance.

There is already a standard, reliable way of communicating package
changes to the admin. Amazingly enough, it's called a "changelog". I
usually find them under /usr/share/doc//...

Steve
-- 
Steve Greenland <[EMAIL PROTECTED]>

Re: New update_excuses output

[Simon Richter]

Hi,

> Would it be possible to also offer a compressed version of these files
> (update_excuses.html, update_output.txt, etc)? Most browsers can handle
> uncompressing these on the fly and it makes accessing these lists MUCH
> faster. As a porter I often use update_excuses for tracking down
> packages that are out of date (on alpha) for longer than normal (usually
> indicating a problem that can't be handled by the build daemon), and
> hence look at that list quite regularly.

It may also be an idea to generate per-arch excuses files.

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: DC26 EB8D 1F35 4F44 2934  7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: problems with binary NMU and apt

[Matt Zimmerman]

On Sat, Sep 15, 2001 at 07:41:21AM +0200, Gerhard Tonn wrote:

> On Saturday 15 September 2001 07:29, you wrote:
> > In my case it's esound-common, which in turn makes the entire gnome tree
> > not installable.
> 
> Most of the esound packages have a 'esound-common (>= ${Source-Version})'
> dependency in debian/control. Is there any generic solution for the problem?

You could manually tweak debian/substvars during the build to set
Source-Version to the maintainer's version.  I don't think this would
violate the _principle_ of a binary NMU, but I don't know if there are
codified rules somewhere.

-- 
 - mdz

Re: [woodm@equire.com: XFree86 common]

["Jürgen A. Erhard"]

> "Roland" == Roland Mas <[EMAIL PROTECTED]> writes:

Just a comment...

Roland> Branden Robinson (2001-08-30 21:26:18 -0500) :
>> On Thu, Aug 30, 2001 at 09:40:03PM +0100, Jules Bean wrote:

>> > Build a fire for a man, an he'll be warm for a day.  Set a
>> > man on fire, and he'll be warm for the rest of his life.

>> Bwa ha, this should be my epitaph.

>> Did you make that up yourself?  It's going in my sig file.

Roland> I read it in a book by Terry Pratchett (Jingo).  I think
Roland> Mr. Pratchett is original enough not to have copied that
Roland> elsewhere.

Roland> http://www.co.uk.lspace.org/books/pqf/jingo.html>

I know that "proverb"(?) as "Give a man fire and he will be warm for a
day.  Set a man on fire and he will be warm for the rest of his
life." (have it in my quotes file)

Don't know where I got that from, but it was surely not from Jingo
(even though I love everything by pterry, I haven't read it yet).

Don't know *when* I came across it, so can't say whether it was before
or after Jingo came out.

Bye, J

PS: Yes, pterry is great, and pretty original... but I don't think
he's above using a great quote when he sees one. ;-)

-- 
  Jürgen A. Erhard  ([EMAIL PROTECTED], [EMAIL PROTECTED])
 MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html
Debian GNU/Linux (http://www.debian.org)
"MCSE: Minesweeper Champion and Solitare Expert"


pgpoiOc2CGwYj.pgp
Description: PGP signature

Re: problems with binary NMU and apt

[Simon Richter]

Package: debhelper
Version: 3.0.44
Severity: normal

On Sat, 15 Sep 2001, Matt Zimmerman wrote:

> > Most of the esound packages have a 'esound-common (>= ${Source-Version})'
> > dependency in debian/control. Is there any generic solution for the problem?

> You could manually tweak debian/substvars during the build to set
> Source-Version to the maintainer's version.  I don't think this would
> violate the _principle_ of a binary NMU, but I don't know if there are
> codified rules somewhere.

Hrm, I just tried to build a package using

DH_OPTIONS=--dpkg-gencontrol-params=-v0.1-1.0.1 dpkg-buildpackage -B

In principle this could work, however current debhelper treats
--dpkg-gencontrol-params as equivalent to -u in
Debian::Debhelper::Dh_Getopt, so the -v option get passed to dpkg as well.

If that would be fixed (and I think this is a real bug since it passes the
args to dpkg, which differs from the behaviour in the man pages, hence the
bug report), one could build binary NMUs for packages that use debhelper
and don't override DH_OPTIONS in their debian/rules with this option.

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: DC26 EB8D 1F35 4F44 2934  7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

why is gtk+extra out of date?

[Bradley Bell]

help!
I'm the maintainer of gtk+extra (libgtkextra16, libgtkextra-dev) which is
quite out of date in testing, and I have no idea why.  It has no RC bugs and
the dependencies are satisfied.  Maybe I'm missing something that someone
can clue me into?

gtkmm (day 10) sorely needs to make it in as well, hopefully it will have no
similar problems.

thanks,
Brad

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Josip Rodin]

On Sat, Sep 15, 2001 at 11:11:20AM -0500, Steve Greenland wrote:
> > Your scheme works, but at least tell the sys admin what is going on with
> > a debconf note.
> > 
> > If you don't want to be bugged change the debconf priority.
> 
> I've got it set to "high". Apparently a number of maintainers think that
> every little thing is of "high" importance.

You should file bug reports against those.

> There is already a standard, reliable way of communicating package
> changes to the admin. Amazingly enough, it's called a "changelog". I
> usually find them under /usr/share/doc//...

We can't really expect the admins to parse through hundreds of changelogs;
README.Debian would be a good place, though.

-- 
 2. That which causes joy or happiness.

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[David Starner]

On Sat, Sep 15, 2001 at 08:24:32PM +0200, Josip Rodin wrote:
> We can't really expect the admins to parse through hundreds of changelogs;
> README.Debian would be a good place, though.

OTOH, apt-listchanges displays the changelog upon upgrade, whereas there's
no automated way to display changes to README.Debian. I rarely read 
README.Debian after first installation, so IMO, it's a bad place to put
things that change after installation.

-- 
David Starner - [EMAIL PROTECTED]
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Josip Rodin]

On Sat, Sep 15, 2001 at 06:34:38PM -0500, David Starner wrote:
> > We can't really expect the admins to parse through hundreds of changelogs;
> > README.Debian would be a good place, though.
> 
> OTOH, apt-listchanges displays the changelog upon upgrade, whereas there's
> no automated way to display changes to README.Debian. I rarely read 
> README.Debian after first installation, so IMO, it's a bad place to put
> things that change after installation.

People shouldn't have to sift through a bunch of entries of boring and
meaningless text (to them, at least :) to get such information...

-- 
 2. That which causes joy or happiness.

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Matt Zimmerman]

On Sat, Sep 15, 2001 at 06:34:38PM -0500, David Starner wrote:

> On Sat, Sep 15, 2001 at 08:24:32PM +0200, Josip Rodin wrote:
> > We can't really expect the admins to parse through hundreds of
> > changelogs; README.Debian would be a good place, though.
> 
> OTOH, apt-listchanges displays the changelog upon upgrade, whereas there's
> no automated way to display changes to README.Debian. I rarely read
> README.Debian after first installation, so IMO, it's a bad place to put
> things that change after installation.

Currently, most users probably don't read README.Debian unless they have a
good reason, so while it's the correct place to put things like this, they
aren't always seen.  In the future, though, package management frontends
should make it easy to view README.Debian at installation time.

-- 
 - mdz

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Steve Greenland]

On 15-Sep-01, 13:24 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: 
> On Sat, Sep 15, 2001 at 11:11:20AM -0500, Steve Greenland wrote:
> 
> > There is already a standard, reliable way of communicating package
> > changes to the admin. Amazingly enough, it's called a "changelog". I
> > usually find them under /usr/share/doc//...
> 
> We can't really expect the admins to parse through hundreds of changelogs;

But if it becomes common place to list changes in debconf notes, then
the admins will be overwhelmed by them as well, if every upgrade leads
to 50 new e-mails.

Consider what we're talking about: A package is moving files from one
directory to another, and replacing the original directory with a
symlink to the new one (assuming that's what Elie decides to do). Why
does every admin need to be notified? Nothing should break, and there's
really nothing the admin needs to do. There's no harm in the symlink.
What about this deserves anything more than a note in the changelog?

Now if Elie decides that he does what to move the files, but not deal
with the symlink, then yes, it does deserve more than a changelog
note, because we can expect at least some people will have things stop
working.

No, I don't actually expect most users/admins to read every changelog:
I certainly don't. But *any* channel that gets overused loses
significance, I'd hate to see that happen to debconf.

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>

Re: splitting /var/lib/dpkg/status and handling desc translation

[Herbert Xu]

Michael Bramer <[EMAIL PROTECTED]> wrote:

> 1.) notification mails
>This is already fixed.

>Verybody can stop the server to send this mails. And I send a

No it's not.  You have to send an email for every package that you maintain.
This is simply unacceptable.  If I don't stop receiving these mails soon, I
will have to impose a site-wide ban on mail from that location.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

apache-debian going live

[Martin F Krafft]

whatever the call is on how we should proceed in terms of Debian
apache package task force, i have created a mailing list, webpage, and
cvs repository for the crew.

you can subscribe at

  https://lists.madduck.net/mailman/listinfo/debian-apache

you can post with
  
  debian-apache at pantsfullofunix.net

you can view the homepage (nothing there yet) at

  http://debian-apache.pantsfullofunix.net

and if you are registered with the task force (through me), you can
get ssh-only cvs access for module "debian-apache" on server
debian-apache.pantsfullofunix.net.

just wanted to let you all know.

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
give me ambiguity or give me something else.


pgpw4Wm27j8Zn.pgp
Description: PGP signature

Problem with resolv.conf and search list

[Bruno BEAUFILS]

There is something I do not understand about resolving hostnames. It seems the
search primitive of resolv.conf does not work properly in sid, nor in woody.

Let's see some of my configuration files :

 resolv.conf
search lifl.fr univ-lille1.fr iut-info.univ-lille1.fr
nameserver 134.206.10.18
nameserver 134.206.1.4
nameserver 134.206.1.15
-

 host.conf
order hosts,bind
multi on
-

Then I know a host which is called sole.iut-info.univ-lille1.fr and want to be
able to call it by its short name sole. 

The resolver is unable to find it. Let's see it with an example :

{watney-root-/etc}# host sole
sole.lifl.fr does not exist (Authoritative answer)

{watney-root-/etc}# host sole.iut-info.univ-lille1.fr
sole.iut-info.univ-lille1.frA   134.206.40.114

Why did the resolver stop searching after the first search entry (not trying
univ-lille1.fr and so on) ?

Did I miss something or is it a bug ?

--
-- Bruno

Re: Problem with resolv.conf and search list

[Philippe Troin]

[moving the discussion to [EMAIL PROTECTED]

Bruno BEAUFILS <[EMAIL PROTECTED]> writes:

> There is something I do not understand about resolving hostnames. It seems the
> search primitive of resolv.conf does not work properly in sid, nor in woody.
> 
> Let's see some of my configuration files :
> 
>  resolv.conf
> search lifl.fr univ-lille1.fr iut-info.univ-lille1.fr
> nameserver 134.206.10.18
> nameserver 134.206.1.4
> nameserver 134.206.1.15
> -

The parser for resolv.conf is very stupid.
Try:

   search lifl.fr univ-lille1.fr
   search iut-info.univ-lille1.fr
   nameserver 134.206.10.18
   nameserver 134.206.1.4
   nameserver 134.206.1.15

Phil.

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[David Starner]

On Sun, Sep 16, 2001 at 01:49:34AM +0200, Josip Rodin wrote:
> People shouldn't have to sift through a bunch of entries of boring and
> meaningless text (to them, at least :) to get such information...

The same being true of README.Debian. I like to know what changes
on my box, so I can anticipate problems (like this one), so
the changelog is usually more interesting than the README.Debian.

-- 
David Starner - [EMAIL PROTECTED]
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[David Starner]

On Sat, Sep 15, 2001 at 07:46:52PM -0400, Matt Zimmerman wrote:
> Currently, most users probably don't read README.Debian unless they have a
> good reason, so while it's the correct place to put things like this, they
> aren't always seen.  In the future, though, package management frontends
> should make it easy to view README.Debian at installation time.

Why? It's not that hard to do "less /usr/share/doc/foo/README.Debian",
or better yet, "cd /usr/share/doc/foo; ls; less whatever". I see no
value in having the README.Debian displayed everytime I upgrade 
xfree86-common, and I seriously doubt I would catch anything important
and new.

-- 
David Starner - [EMAIL PROTECTED]
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: problems with binary NMU and apt

[Joey Hess]

Simon Richter wrote:
> Hrm, I just tried to build a package using
> 
> DH_OPTIONS=--dpkg-gencontrol-params=-v0.1-1.0.1 dpkg-buildpackage -B
> 
> In principle this could work, however current debhelper treats
> --dpkg-gencontrol-params as equivalent to -u in
> Debian::Debhelper::Dh_Getopt, so the -v option get passed to dpkg as well.

I'm afraid that what you're trying to do is not something I can sanely
support with debhelper's current method of option parsing. I could
support it, but the level of pain and ugliness and added cruftiness in
debhelper's code required would be greater than the gain of being able
to do that, in my opinion. I may be able to support this better in the
next interation of debhelper's options parsing code, but I haven't even
fully designed that yet.

Also, all methods of passing parameters to wrapped programs, via -u or
--dpkg-gencontrol-params or similar things, are mildly deprecated, in
favour of passing the parameters after '--'. The latter works much
better and is less ugly and more clear.

I also have to wonder if it is a good idea at all to build a binary
NMU in this way. Yes, you have not modified the source, but nobody will
be able to reproduce the build without using the exact same command line
you used to build it, and that command line will not be recorded
anyhere. It may technically be a binary-only NMU that does not modify
the source, but you're walking a very thin line, and I don't know that
the distinction between doing this and modifying debian/rules or
debian/control has any value.

-- 
see shy jo

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Matt Zimmerman]

On Sat, Sep 15, 2001 at 09:18:39PM -0500, David Starner wrote:

> On Sat, Sep 15, 2001 at 07:46:52PM -0400, Matt Zimmerman wrote:
> > Currently, most users probably don't read README.Debian unless they have
> > a good reason, so while it's the correct place to put things like this,
> > they aren't always seen.  In the future, though, package management
> > frontends should make it easy to view README.Debian at installation
> > time.
> 
> Why? It's not that hard to do "less /usr/share/doc/foo/README.Debian", or
> better yet, "cd /usr/share/doc/foo; ls; less whatever". I see no value in
> having the README.Debian displayed everytime I upgrade xfree86-common, and
> I seriously doubt I would catch anything important and new.

It's not that hard to do this for a single package, but it is a completely
different matter to do it by hand for every newly-installed package.  This
is something that frontends should simplify.

In the above text I wrote "at installation time", meaning when a package is
initially installed, not "everytime I upgrade".

-- 
 - mdz

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[David Starner]

On Sat, Sep 15, 2001 at 10:30:21PM -0400, Matt Zimmerman wrote:
> It's not that hard to do this for a single package, but it is a completely
> different matter to do it by hand for every newly-installed package.  This
> is something that frontends should simplify.

I have over a thousand packages installed, with ~300 README.Debian files.
I don't anticipate sitting and reading them all, one after another.

And why should I? I just glanced at the xteddy README.Debian; it doesn't
work right with sawfish, due to various X arcana. If I were using 
sawfish and had a problem, that would be one of the first files I read.
As I don't run sawfish, I really don't care.
 
> In the above text I wrote "at installation time", meaning when a package is
> initially installed, not "everytime I upgrade".

Which doesn't solve this problem. 

-- 
David Starner - [EMAIL PROTECTED]
Pointless website: http://dvdeug.dhis.org

how to install from local mirror?

[Lindsay Allen]

I'm trying to do a fresh sid install using my local partial mirror and I
get stuck with a debootstrap error "2".  The problem is with
dists/sid/Release.

Is there a script which creates this file?   I have tried to create a
valid version to match my mirror but had no success.

TIA
Lindsay
-- 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lindsay Allen   <[EMAIL PROTECTED]>Perth, Western Australia
voice +61 8 9316 2486, 0403 272 564   32.0125S 115.8445E   Debian Linux
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: Issue with Bug#112121: procmail-lib: Recipes belong in /usr/share, not /usr/lib

[Matt Zimmerman]

On Sat, Sep 15, 2001 at 09:44:23PM -0500, David Starner wrote:

> On Sat, Sep 15, 2001 at 10:30:21PM -0400, Matt Zimmerman wrote:
> > It's not that hard to do this for a single package, but it is a completely
> > different matter to do it by hand for every newly-installed package.  This
> > is something that frontends should simplify.
> 
> I have over a thousand packages installed, with ~300 README.Debian files.
> I don't anticipate sitting and reading them all, one after another.

Would you knock it off with the flamebait?  I am not suggesting that anyone
be forced to read any number of README.Debian files, just that it will,
quite naturally, become part of the package installation process with the
help of package management UIs.

> And why should I? I just glanced at the xteddy README.Debian; it doesn't
> work right with sawfish, due to various X arcana. If I were using 
> sawfish and had a problem, that would be one of the first files I read.
> As I don't run sawfish, I really don't care.

Not all README.Debians are alike.  Many of them contain information of the
form "here is how Debian's foobar differs from upstream foobar, which you
may be familiar with".  As such, it is not "in case of emergency"
instructions, but a README in the traditional sense, to be read _before_
using the software.

Information about issues which will affect _new_ users of the software
should go there, regardless of whether it has to do with a change from a
previous version, because that is where they are supposed to look.  Changes
which will only affect users of a previous version should display a note if
it's important, otherwise just include a changelog entry (which should be
there in any case).

Upgrading users are not expected to have to read the changelogs _or_
README.Debian to hear about things that will break on their system.

-- 
 - mdz

Re: New update_excuses output

[Martijn van Oosterhout]

On Sun, Sep 16, 2001 at 01:05:31AM +1000, Steve Kowalik wrote:
> On Sat, Sep 15, 2001 at 01:53:03PM +0200, Paul Slootman uttered:
> > Would it be possible to also offer a compressed version of these files
> > (update_excuses.html, update_output.txt, etc)? Most browsers can handle
> > uncompressing these on the fly and it makes accessing these lists MUCH
> > faster. As a porter I often use update_excuses for tracking down
> > packages that are out of date (on alpha) for longer than normal (usually
> > indicating a problem that can't be handled by the build daemon), and
> > hence look at that list quite regularly.
> > 
> That may also involve installing mod_gzip on ftp-master.

Downloading gzipped files that automatically ungzip on the client doesn't
require any module. If someone supplies a update-excuses.gz it will work
without any changes to apache.

The module would be required if you want to autonegotiate the compression on
the file.
-- 
Martijn van Oosterhout 
http://svana.org/kleptog/
> Magnetism, electricity and motion are like a three-for-two special offer:
> if you have two of them, the third one comes free.

Re: New update_excuses output

[Anthony Towns]

On Sat, Sep 15, 2001 at 01:53:03PM +0200, Paul Slootman wrote:
> On Sat 15 Sep 2001, Anthony Towns wrote:
> > As of the next dinstall/testing run (a few hours away yet) there'll be a
> > new set of lines in the update_excuses output [0] (NB: it's now over a MB so
> > it's quite long and tedious). They look like:
> Would it be possible to also offer a compressed version of these files
> (update_excuses.html, update_output.txt, etc)? 

Should be there as of now, without the etc.

Cheers,
aj

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

 ``Freedom itself was attacked this morning by faceless cowards.
 And freedom will be defended.''   Condolences to all involved.

Debian testing - uninstallable packages

[Andrew M. Bishop]

[ I sent this to debian-testing a month ago, but the mailing list   ]
[ doesn't exist anymore - it is not archived at http://list.debian.org/ ]
[ If there is a more appropriate list for this discussion let me know.  ]

The debian FAQ (/usr/share/debian/FAQ) says the following:

: Packages are installed into the `testing' directory after they have undergone
: some degree of testing in unstable.  They must be in sync on all architectures
: where they have been built and mustn't have dependencies that make them
: uninstallable; they also have to have fewer release-critical bugs than the
: versions currently in testing.  This way, we hope that `testing' is always
: close to being a release candidate.

I have seen a problem with two packages that I wanted to install from
testing not being installable.  These were gnumeric and gnucash, so I
raised bug reports about them - currently unanswered.

I realise that there may be other packages that are also
uninstallable, so I wrote a script that parses /var/lib/dpkg/available
and lists those packages that have unmet dependencies, recommendations
or suggestions for packages that are not available.  The script only
checks the package names, not the version numbers, so they may be more
problems.

The list below was compiled from the current status of debian testing
as found in the following sources.list today.

 sources.list 
deb http://www.uk.debian.org/debian woody main
deb http://www.uk.debian.org/debian woody contrib
deb http://www.uk.debian.org/debian woody non-free
deb http://www.uk.debian.org/debian woody non-US/main
deb http://www.uk.debian.org/debian woody non-US/contrib
deb http://www.uk.debian.org/debian woody non-US/non-free
 sources.list 


Package  RelationDependency (not available)
---  --

glcpudepends on  libcommonc++1

gnucash  depends on  libguile9
gnucash  depends on  guile1.4
gnucash  depends on  guile1.4-slib
gnucash  depends on  libgwrapguile0

gnumeric depends on  libgal4

mozilla  depends on  mozilla-browser
mozilla  depends on  mozilla-mailnews

roxen-ssldepends on  pike-crypto

sphinx2-bin  depends on  sphinx2-hmm-6k


Package  RelationRecommendation (not available)
---  --

alamin-serverrecommends  gnokii

bibletimerecommends  sword-dict
bibletimerecommends  sword-comm

cdrecord recommends  mkisofs

cjk-latexrecommends  freetype1-tools

guile1.4-doc recommends  guile1.4

ibcs-source-2.0  recommends  kernel-source-2.0.36 | 
kernel-source-2.0.38

kernel-patch-2.4.0-ia64  recommends  kernel-source-2.4.0

kernel-patch-2.4.1-ia64  recommends  kernel-source-2.4.1

kernel-patch-2.4.3-arm   recommends  kernel-source-2.4.3

kernel-patch-2.4.4-ia64  recommends  kernel-source-2.4.4

kernel-patch-2.4.5-ia64  recommends  kernel-source-2.4.5

kernel-patch-2.4.5-s390  recommends  kernel-source-2.4.5

mozilla  recommends  mozilla-psm

pipsecd  recommends  userlink

quickppp recommends  pppd

tpctlrecommends  tpctl-modules

unp  recommends  unace

webmin-ssl   recommends  webmin-core

zope-pagetemplates   recommends  zope-parsedxml


Package  RelationSuggestion (not available)
---  --

alsa-basesuggestsalsadriver

alsa-utils   suggestsalsadriver

alsa-utils-0.4   suggestsalsadriver

alsa-utils-0.5   suggestsalsadriver

ant  suggestsjmf

aolserversuggestsaolserver-postgres
aolserversuggestsopenacs

atoolsuggestsbzip

cbedic   suggestskbedic

cdrtoaster   suggestsmkisofs

cpuburn  suggestskernel-patch-badram

crafty   suggestscraftywatcher

cupsys-clientsuggestskdelibs3-cups

cvsbook  suggestscvs-doc

cxterm-gbsuggestsintlfonts-chinese

cxterm-jis   suggestsintlfonts-japanese

dhelp