Re: Bug#95801: won't let me upgrade perl from stable to unstable

[Jason Gunthorpe]

On 1 May 2001, Brian May wrote:

> > "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> 
> Jason> On Mon, 30 Apr 2001, Brian May wrote:
> 
> >> WARNING: The following essential packages will be removed This
> >> should NOT be done unless you know exactly what you are doing!
> >> perl-5.004-base (due to perl-base)
> 
> Jason> I'm confused, why is this a bug? You asked it to remove a
> 
> No I didn't! I asked to upgrade to the latest perl from unstable!

 Please read exactly what I am saying, I already discussed this
problem with Brendan before I replied to you. The fact that dist-upgrade
works makes this not-a-bug.

By asking it to remove some packages, that implicitly implies others need
to be upgraded, which implies that some perl packages need to be removed.
You asked for that, you have to accept that. You may suggest it not remove
perl-5.004 base by also listing that on the command line, but you may find
it removes more packages that you'd like it to.

> It is a bug. It means that I cannot upgrade from stable to unstable.

No, it means you can't do this specific situation you asked for, you said
dist-upgrade works, so you can in fact upgrade to unstable!
 
> >> The thing is, I can't even see how this is meant to work:
> >> 
> >> dewey:~# dpkg --print-avail perl-base
  
 
> Jason> Try looking at the current version of perl-base, and then
   

> conflicts. Perhaps you are confused? Please check the version number
> again.

Read it. Carefully. Your output has no relevence what so ever for 2
reasons, the first being that it is not the installed package, and the
second being that it is dpkg 'avail' output which is not used by APT.

In fact the output you quote below demonstrates exactly what I was talking
about.

> If you do close this bug again without resolving it, then I guess you
> have just demonstrated that Debian has grown too large and

Why are you arguing with me? Instead of taking the time to reopen the bug,
you should have reassgned it to a perl package, or accept that it is
Not-A-Bug. I have already provided sufficient explanation in the first
message to show that it is not an APT bug. 

Since I am not convinced this is even a bug at all, I am not going to
foist it on anyone else. If you still belive something is wrong then it is
up to you to talk to Brendan yourself - that is why I closed the bug, why
you reopened it in spite of my explaination of why it is not an apt bug is
beyond me...

Jason

Re: (OT) Storage (8*IDE HDs) any experiences?

[Mike Fedyk]

On Sun, Apr 29, 2001 at 10:14:35AM +0200, Russell Coker wrote:
> On Sunday 29 April 2001 06:48, Brandon High wrote:
> > On Sat, Apr 28, 2001 at 11:50:26PM +0200, Andreas Bombe wrote:
> > > The IBM SCSI disk I have here has a jumper to delay spin up depending on
> > > SCSI ID so that an array of those would spin up sequentially if they all
> > > had those jumper set (and different IDs, which they need anyway).  Maybe
> > > there are IDE drives built with RAIDs in mind offering some similar
> > > option?
> >
> > I doubt it, but with a sufficiently large case (or small power supply) it
> > may be possible to stick a 2nd (or 3rd) power supply in. Drives could be
> > plugged into the second PS while the MB is powered off of the primary PS.
> 
> That sounds like a really bad idea to me.
> 
> In a regular setup the IDE controller and the drive get power from the same 
> source.  So if the signals on the cable have more current going one way than 
> the other then the difference will be made up on the 0V line on the PSU.  If 
> you have separate PSU's then the difference will go through other lines of 
> the data cable.  This is something that is likely to be fatal to drives and 
> motherboards.
> 
> But if you try it please let me know how it works.  ;)
I've used a second power supply just to test out some hard drives, because I
didn't want them to hang off the PS.

It worked great.

Mike

Re: Proposing task-debian

[Matt Zimmerman]

On Mon, Apr 30, 2001 at 11:10:47PM -0400, Joey Hess wrote:

> Matt Zimmerman wrote:
> > I think it makes as much sense as the existing task packages.
> 
> Existing brokenness is no excuse for new brokenness though. I have gone
> into detail about how the current task system is fubar, and I think I've
> filed bugs on most of the task packages you mention since they should
> not exist.

A few sentences in policy, or a small web page on /devel might help keep this
from happening.  More effective though, I think, would be to give developers a
good way to express what they are trying to express with these broken task
packages.  I think they want to give users a way to easily select common
packages at installation time.  When I first installed Debian, I spent hours in
dselect figuring out what I wanted, and today there are several times as many
packages.

I think most packages that fall into this category are server programs.
Desktop systems tend to be installed once and last a long time.  I seem to
build servers many times more frequently than desktop systems, either to bring
more capacity online or to experiment with different applications.  Maybe what
is needed is a "Server installation" menu which allows the user to install
packages like these without searching around for them.

Or, maybe we just need a better dselect.

-- 
 - mdz

Re: Proposing task-debian

[Anthony Towns]

On Mon, Apr 30, 2001 at 11:10:47PM -0400, Joey Hess wrote:
> Matt Zimmerman wrote:
> > I think it makes as much sense as the existing task packages.
> Existing brokenness is no excuse for new brokenness though. I have gone
> into detail about how the current task system is fubar, and I think I've
> filed bugs on most of the task packages you mention since they should
> not exist.

Here are the assumptions:

* emacs is used and desired by enough people that they should be
  able to get it "easily"

* emacs is large and not used by enough people that it should be
  easily avoidable in the default install

In both cases, "easily" probably involves not going into dselect or
console-apt or using apt-get by hand.

The conclusion is that there should be some way, using something like
tasksel, to choose whether you want emacs installed or not.

Likewise, there ought to be some way, using something like tasksel, to
choose whether you want an X environment or not, and whether you want
a fancy desktop like Gnome or KDE. Lots of people do want them. Lots of
people don't. They're not exactly "tasks", though.

Would:

[ ] X Desktop (Gnome/KDE)
[ ] Emacs

[ ] Dialup
[ ] Printing
[ ] Laptop

[ ] Russian
[ ] German
[ ] Japanese
[ ] Chinese
[ ] Spanish
[ ] Polish

[ ] Office software (word processing, spreadsheet, etc)
[ ] Desktop Publishing (TeX)
[ ] Database software (Postgresql)
[ ] Science
[ ] Games
[ ] Junior

[ ] C
[ ] C++
[ ] Fortran
[ ] Objectionable C
[ ] Python
[ ] SGML
[ ] Tcl/Tk

[ ] Web Server (Apache)
[ ] Windows Filesharing (Samba)
[ ] DNS Server (bind)
[ ] News Server (INN)
[ ] Cluster node
[ ] Mail Server (IMAP, etc)

...really be unreasonable? 

They're not all "tasks" ("I speak Russian", "I want to use Emacs",
"I want pretty little icons, just like Windows", "my computer has a
printer"), and even the ones that are aren't tasks in the same sense
("I want to be able to..." vs "I want my computer to...")

But they're not hard for a user to work through, and they seem likely
to be useful.

(They could be further categorised by naming them like:
task-devel-c
task-lang-polish
task-user-wordprocessing
task-server-dns
task-hardware-dialup
And having tasksel know about the conventions we might use)

Cheers,
aj

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

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgp1CQHsCJ2FE.pgp
Description: PGP signature

Fwd: Re: [GB]Conflict with name libgb.so

[Ben Burton]

Hi.. just received this from the primary Gnome Basic author.

I'll make the suggested changes and merge the Gnome Basic stuff into 
/usr/lib/libgbrun.so; Stanford GraphBase need not be touched.

Ben.

--  Forwarded Message  --
Subject: Re: [GB]Conflict with name libgb.so
Date: Mon, 30 Apr 2001 23:36:12 -0400 (EDT)
From: Michael Meeks <[EMAIL PROTECTED]>
To: Ben Burton <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]


Hi Ben,

On Mon, 30 Apr 2001, Ben Burton wrote:
> Hi.  I am currently preparing Gnome Basic packages for Debian.  As it
> happens, there is another package (Stanford GraphBase, package sgb)
> which also provides /usr/lib/libgb.so.  Thus one of us will have to
> have Debian packages with libraries named differently from the
> upstream sources.

Ok, well - I would be fairly happy to move to integrating libgb.so
into libgbrun and just installing libgbrun [ which sounds somewhat more
unlikely to conflict with anything ].

> What is the severity of renaming the Debian libraries to libgbparse.so
> or something similar?  Do people currently expect it to be installed
> as libgb.so and will more people expect this in the future?  How
> "standard" is libgb.so and how standard is it likely to become?

Not very standard.

> Sorry, I realise these questions are vague but we're trying to resolve
> the conflict with Debian packages and any input is helpful.

Sounds fine, a patch to the automake stuff to create a
non-installed libgb.a and merge that with libgbrun.so would be
appreciated.

Regards,

Michael.

--
 [EMAIL PROTECTED]  <><, Pseudo Engineer, itinerant idiot

---

-- 

Ben Burton ([EMAIL PROTECTED])
http://baasil.humbug.org.au/bab/

Director of Training
Australian Informatics Olympiad Committee

If you have the same ideas as everybody else but have them one week
earlier than everyone else then you will be hailed as a
visionary. But if you have them five years earlier you will be
named a lunatic.
- Barry Jones

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Alan Shutko]

Alan Shutko <[EMAIL PROTECTED]> writes:

> There are billions and billions of ways you can tweak environment
> variables to break shell scripts that don't bother.  What's your
> point?  If I can tweak IFS to change parsing, I can also tweak PATH.

So far, all I've come up with are programs passing unvalidated and
untrusted info to scripts... but there was a mention of Solaris sh no
longer accepting IFS from scripts.  

-- 
Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors!
To be or not to be, that is the bottom line.

¶W§C»ù15¦TTFT LCD ¿Ã¹õ

[ªü±l]

阿祥,

還在用映像管的螢幕嗎? 到時後太多輻射線沒有辦法"翹"起來!!!
[EMAIL PROTECTED] LCD TFT 的螢幕喔!!

http://www.megarats.com

小咪

Re: Proposing task-debian

[Joey Hess]

Matt Zimmerman wrote:
> I think it makes as much sense as the existing task packages.

Existing brokenness is no excuse for new brokenness though. I have gone
into detail about how the current task system is fubar, and I think I've
filed bugs on most of the task packages you mention since they should
not exist.

-- 
see shy jo

Re: debbugs can now send bug mails to someone different than the maintainer

[Adam Heath]

On Mon, 30 Apr 2001, Julian Gilbey wrote:

> On Mon, Apr 30, 2001 at 11:50:59PM +0200, Wichert Akkerman wrote:
> > Previously Julian Gilbey wrote:
> > > But I'm *not* the maintainer; I'm one of a group of maintainers.  If
> > > we do this, then every time one of us uploads, we need to change the
> > > maintainer name in the control file.
> >
> > You needed to do that anyway. The problem you have is that dinstall
> > has no way to figre out if you are one of the official maintainers.
>
> No; at present, we only have to enter the correct entry in the
> changelog, keeping "Debian policy list "
> in the control file Maintainer field.  Then all of our uploads are
> considered NMUs and we have to close the bugs manually thereafter (how
> lazy we have become!).

Um, why not set 'Debian policy list ' in the
changelog, but just sign the files with the key of the uploader?

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Alan Shutko]

Zack Weinberg <[EMAIL PROTECTED]> writes:

> Irrelevant.  Look up IFS in a bugtraq archive.
> I shan't do your homework for you.

You're reporting a bug.  The standards say this isn't a requirement or
a problem.  Prove your case or at least take it to private email.

There are billions and billions of ways you can tweak environment
variables to break shell scripts that don't bother.  What's your
point?  If I can tweak IFS to change parsing, I can also tweak PATH.

-- 
Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors!
Please take note:

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Zack Weinberg]

severity 95430 critical
quit

I can keep this up just as long as you can.

...
> > (tests) ... except that ash does honor IFS from the environment.  You
> > realize that this is a gaping security hole, even if IFS is only used
> > to split the results of expansion?  You realize that it is trivial to
> > break any shell script on the entire machine that way?
> 
> Get a clue, Linux does not allow setuid scripts.

Irrelevant.  Look up IFS in a bugtraq archive.
I shan't do your homework for you.

> > What the standard says is IRRELEVANT.  You cannot change consensus
> > shell behavior even if it is in direct conflict with the standard.
> 
> You're the one who doesn't get it.  If you are writing shell functions
> and you need to save the IFS, then you need to save it properly.

You don't seem to comprehend the difference between shell *functions*
and shell *scripts*.

zw

Re: debbugs can now send bug mails to someone different than the maintainer

[Henrique M Holschuh]

On Mon, 30 Apr 2001, Rahul Jain wrote:
> On Mon, Apr 30, 2001 at 09:06:01PM -0400, Matt Zimmerman wrote:
> > The client side of fetchmail will (by default) feed each message into your
> > local MTA for delivery, but you'll have to figure a way to get the mail 
> > into it
> > from the remote mailbox without IMAP or POP services (which I don't think
> > master provides).  I think someone was working on ETRN recently, which is 
> > also
> > supported by fetchmail...
> 
> hrm... having fetchmail ssh in and grab the mail directly from the spool would
> be kind of cool... :)

Well, I am the fetchmail maintainer and I use a non-fetchmail based (but ssh
and cron-based) solution.  Make of that what you will. 

I think you could also ask Branden what he thinks of using fetchmail to get
mail from master.d.o... he should have some colorful thoughts on the issue,
I believe :-P  Why, he might even have wounded my feelings when he made
those comments in IRC, were I already NOT using fetchmail to get mail
from master.d.o   ;-)

Fetchmail is not the best tool for dealing with the Debian developer mail
accounts, plain and simple.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


pgpPLl7yfxK6Q.pgp
Description: PGP signature

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Herbert Xu]

severity 95430 wishlist
quit

On Mon, Apr 30, 2001 at 06:35:53PM -0700, Zack Weinberg wrote:
> 
> (tests) ... except that ash does honor IFS from the environment.  You
> realize that this is a gaping security hole, even if IFS is only used
> to split the results of expansion?  You realize that it is trivial to
> break any shell script on the entire machine that way?

Get a clue, Linux does not allow setuid scripts.

> What the standard says is IRRELEVANT.  You cannot change consensus
> shell behavior even if it is in direct conflict with the standard.

You're the one who doesn't get it.  If you are writing shell functions
and you need to save the IFS, then you need to save it properly.
-- 
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

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Alan Shutko]

Zack Weinberg <[EMAIL PROTECTED]> writes:

> Uh, no it can't.  I'm talking about self-contained shell scripts,
> not functions.  IFS does not inherit through the environment.
> Self-contained scripts can count on its being set to
> "" when execution begins.

Says who?

SUS says:

IFS

Input field separators : a string treated as a list of characters
that is used for field splitting and to split lines into words
with the read command. See Field Splitting . If IFS is not set,
the shell behaves as if the value of IFS were the space, tab and
newline characters. Implementations may ignore the value of IFS in
the environment at the time sh is invoked, treating IFS as if it
were not set.

That seems to indicate that sh is not required to ignore IFS in the
environment.


-- 
Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors!
In specifications, Murphy's Law supersedes Ohm's.

Re: Bug#95801: won't let me upgrade perl from stable to unstable

[Steve Langasek]

On Mon, 30 Apr 2001, xsdg wrote:

> I'm not sure if this is the correct answer, but do
> you have the newest apt, apt-utils, debconf,
> debconf-utils, and dpkg installed on that box?

Does that really address the problem?  A user upgrading from potato to woody
once woody is released will also not have the newest versions of these tools
installed.

Steve Langasek
postmodern programmer

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Zack Weinberg]

[EMAIL PROTECTED] on Tue, May 01, 2001 at 07:30:14AM +1000

# Let's try this again
reopen 95430
severity 95430 critical
retitle 95430 [SECURITY] ash honors IFS in environment
quit

On Tue, May 01, 2001 at 07:30:14AM +1000, Herbert Xu wrote:
> 
> > I have consulted the Single Unix Standard and can find only dubious
> > justification for this assertion.  It never flat out says whether IFS
> > is to be set on entry to the shell or not.  However, I note this
> > paragraph:
> 
> It's wrong regardless of whether the shell sets it.  The whole point of
> saving IFS is so that you can restore it to its original value, which can
> be whatever the previous user has set it to, including the case of it not
> being set at all.  If your code can't handle that, then please don't save
> the value at all.

Uh, no it can't.  I'm talking about self-contained shell scripts, not
functions.  IFS does not inherit through the environment.
Self-contained scripts can count on its being set to
"" when execution begins.

(tests) ... except that ash does honor IFS from the environment.  You
realize that this is a gaping security hole, even if IFS is only used
to split the results of expansion?  You realize that it is trivial to
break any shell script on the entire machine that way?

Both 0.3.8 and 0.3.7-x are affected by *that* bug, incidentally.

[...]
> > In any case, your change is a gratuitous divergence from the upstream
> > code and a deliberate breakage of consensus shell behavior.  My script
> > functions correctly with every Bourne-descended shell I have access to
> > except ash 0.3.8-1.  (In addition to bash, pdksh, and previous
> > versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX,
> > and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by
> > Solaris.)  Irrespective of what the standard says, you cannot
> > introduce changes into /bin/sh which make it behave differently from
> > every other shell out there.  Especially if they have the potential to
> > break every shell script which uses some feature.
> 
> I can understand how frustrating it is to have your scripts broken by
> this.  But the fact remains that it's the scripts that are broken, not the
> shell.
>
> Are your functions supposed to be called by other scripts in general? If
> so, then it's particularly important to handle the case of an unset IFS.

You don't get it, do you?

What the standard says is IRRELEVANT.  You cannot change consensus
shell behavior even if it is in direct conflict with the standard.

Find me ONE other implementation of a Bourne shell, which does not set
IFS to "" on initialization, ignoring the value
in the environment, and which postdates 4.4BSD and SVR4, and I'll shut
up.  The burden is on you to do this.  I believe I have adequately
demonstrated what the proper behavior is.

zw

Re: debbugs can now send bug mails to someone different than the maintainer

[Rahul Jain]

On Mon, Apr 30, 2001 at 09:06:01PM -0400, Matt Zimmerman wrote:
> The client side of fetchmail will (by default) feed each message into your
> local MTA for delivery, but you'll have to figure a way to get the mail into 
> it
> from the remote mailbox without IMAP or POP services (which I don't think
> master provides).  I think someone was working on ETRN recently, which is also
> supported by fetchmail...

hrm... having fetchmail ssh in and grab the mail directly from the spool would
be kind of cool... :)

-- 
-> -/-   - Rahul Jain -   -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:[EMAIL PROTECTED] -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--||--||-|--|-|-|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

Re: Proposing task-debian

[Matt Zimmerman]

On Mon, Apr 30, 2001 at 07:31:48PM -0400, Alan Shutko wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
> > In many Linux distributions, Emacs is a high-level installation task, like
> > "Games" or "Mail".  This makes sense to the average user, who usually either
> > wants Emacs or does not.
> 
> For a little amplification, while "Emacs as an editor" may not make
> much sense as a task (only a couple packages), a task which installed
> most Emacs add-ons might be useful.

I think the general idea is to get Emacs out of standard, since a lot of people
don't want it, but still offer it as a straightforward option during the
installation process.  Currently, the choices for package selection at install
time are tasksel and dselect.  With the "straightforward" restriction I gave
above, tasksel is the only option.

Maybe this will change with debian-installer, or some future device.

-- 
 - mdz

Re: Bug#95801: won't let me upgrade perl from stable to unstable

[xsdg]

I'm not sure if this is the correct answer, but do
you have the newest apt, apt-utils, debconf, 
debconf-utils, and dpkg installed on that box?

--xsdg
-- 
 ___
/   Sun Microsystems. We put the dot in ./exploit   \
\   /
/http://xsdg.hypermart.net|[EMAIL PROTECTED]\
\___/

Re: 404's

[Matt Zimmerman]

On Mon, Apr 30, 2001 at 02:00:18PM -0700, Adam McKenna wrote:

> It seems like an easy way to prevent the following would be to update the
> Packages.gz file LAST, after syncing up the other files, IE:
> 
> rsync --exclude "Packages*" debian/pool
> rsync --delete debian/pool  (If old packages are even deleted)

As I pointed out in another message, this will cause additional disk space on
the mirrors (the number of changed packages each day seems to be increasing
steadily), and also, with this rsync implementation, will cause nearly every
file in the archive to be checksum-compared twice instead of once.  I doubt the
additional resource consumption is acceptable to all of the mirror operators.
If it is, go for it.

-- 
 - mdz

Re: debbugs can now send bug mails to someone different than the maintainer

[Matt Zimmerman]

On Tue, May 01, 2001 at 09:17:21AM +1000, Brian May wrote:

> > "Matt" == Matt Zimmerman <[EMAIL PROTECTED]> writes:
> 
> Matt> Unless, of course, you can do your filtering on the mail
> Matt> server, as I do.
> 
> In my case, my MTA server is on the wrong side of my permanent
> 28.8kbps modem link.
> 
> Of course, I could make master.debian.org my server, too. Just not as
> convenient (I would need to implement something, eg. fetchmail based
> for retrieving the mail.) One day, I need to investigate fetchmail,
> and how it works. Or that BSMTP stuff.

The client side of fetchmail will (by default) feed each message into your
local MTA for delivery, but you'll have to figure a way to get the mail into it
from the remote mailbox without IMAP or POP services (which I don't think
master provides).  I think someone was working on ETRN recently, which is also
supported by fetchmail...

-- 
 - mdz

Re: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Zack Weinberg]

On Mon, Apr 30, 2001 at 06:34:19PM -0400, Ben Darnell wrote:
> This thread is directed at the wrong bug number - the discussion is about
> #95430, but the messages are going to #95420.  Please adjust the recipients
> appropriately in your replies.

My apologies, I mistyped the bug number.

zw

Re: Bug#95801: won't let me upgrade perl from stable to unstable

[Brian May]

reopen 95801
thanks

(note: skip to "rehash of problem" to see what this problem is all
about.  I am writing this to debian-devel, because I consider this a
serious problem which shouldn't be ignored).

> "Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:

Jason> On Mon, 30 Apr 2001, Brian May wrote:

>> WARNING: The following essential packages will be removed This
>> should NOT be done unless you know exactly what you are doing!
>> perl-5.004-base (due to perl-base)

Jason> I'm confused, why is this a bug? You asked it to remove a

No I didn't! I asked to upgrade to the latest perl from unstable!

Jason> key component of perl, perl is an essential package, doing
Jason> this may not actually complete, and it may break *inst/*rm
Jason> scripts that need to be run, so it complains.

It is a bug. It means that I cannot upgrade from stable to unstable.

If you don't think it is a bug in apt, well fine, reassign it, but
please don't close it!

If you don't have time to read my report properly, ignore it, but
please don't close it

>> The thing is, I can't even see how this is meant to work:
>> 
>> dewey:~# dpkg --print-avail perl-base

Jason> Try looking at the current version of perl-base, and then
Jason> look at the thing that actually provides the pre-depends it
Jason> needs, which in this case will be perl-5.004-base. This has
Jason> very little to do with the packages you are going to
Jason> install.

Did you even look at the output I quoted of perl-base? You seem to
contradict it, as it doesn't have any predepends, only a
conflicts. Perhaps you are confused? Please check the version number
again.

(Or perhaps my mirror ftp.au.debian.org is badly out of date?)

If you do close this bug again without resolving it, then I guess you
have just demonstrated that Debian has grown too large and
bureaucratic, that we are no longer interested in getting upgrades
from stable to unstable to work anymore.

Otherwise, if you want to read some constructive suggestions for how
to improve the upgrade process in Debian from stable to unstable, read
on...

=
= rehash on problem =
=

Trying to upgrade perl from unstable to unstable requires
perl-5.004-base be removed, which is marked as required. So you get
this serious looking error saying an essential package is going to be
removed. Please read the bug report for details.

(note: what is odd is on my first computer apt-get cleanly removed
perl-5.004-base without any complaints. Weird. Perhaps this
perl-5.004-base was only just recently removed from unstable, and
previously had Priority: <= required).


= THE OLD STABLE VERSION OF perl-base: =

Package: perl-base
Essential: yes
Status: install ok installed
Priority: required
Section: base
Installed-Size: 10
Maintainer: Darren Stalder <[EMAIL PROTECTED]>
Version: 5.004.05-1.1
Pre-Depends: perl5-base
Description: Fake package assuring that one of the -base package is installed
 This package predepends on perl5-base that is provided by
 the various perl-...-base package. It's essential.

=
= THE NEW UNSTABLE VERSION OF PERL-BASE =
=
snoopy:unstable:~# dpkg --print-avail perl-5.004-base
Package `perl-5.004-base' is not available.

snoopy:unstable:~# dpkg --print-avail perl-base
Package: perl-base
Essential: yes
Priority: required
Section: base
Installed-Size: 2520
Maintainer: Brendan O'Dea <[EMAIL PROTECTED]>
Architecture: i386
Source: perl
Version: 5.6.0-21
Replaces: perl-5.005-base (<< 6), perl-5.6-base (<< 6), perl-modules (<< 
5.6.0-19)
Provides: perl5-base, perlapi-5.005, perlapi-5.6.0, data-dumper
Depends: libc6 (>= 2.2.1-2)
Suggests: perl
Conflicts: perl-5.004-base, perl-5.005-base (<< 6), perl-5.6-base (<< 6), 
data-dumper
Filename: pool/main/p/perl/perl-base_5.6.0-21_i386.deb
Size: 839538
MD5sum: e60552c2c1dceda92c22b6273be953c3
Description: The Pathologically Eclectic Rubbish Lister.
 A scripting language with delusions of full language-hood, Perl is used
 in many system scripts and utilities.
 .
 This is a stripped down Perl with only essential libraries.  To make
 full use of Perl, you'll want to install the `perl', `perl-modules' and
 optionally `perl-doc' packages which supplement this one.



All I want to do is upgrade from stable perl to unstable perl.

apt-get upgrade says that this is impossible without removing an essential
package.

When I look at the latest version of Packages on my official Debian mirror,
it says that

1) perl-base is priority required.
2) perl-base conflicts with perl-5.004-base.
3) perl-5.004-base is priority required.
4) perl-5.004-base no longer exists in unstable.

I would assume that this means perl-5.004 is consider obsolete, and
this means some clean way is required to remove it wi

Re: looking for missing mail

[Filip Van Raemdonck]

Hello,

The gap has been filled in... thanks to everyone.

Regards,

Filip

-- 
War does not prove who is right, it proves who is left.


pgpCgyOwW683v.pgp
Description: PGP signature

Re: Many ports open by default

[mdanish]

On Mon, Apr 30, 2001 at 11:52:46PM +, Will Lowe wrote:
> > > I think it's safe to assume that your system MUST have a working MTA of
> > > some sort (even if it's local-only, which is supported by eximconfig).
> > This is true, but does it need to be world-accessible?  There should
> > be a way to either have it listen on localhost only, or not listen on
> 
> Sure, don't run the daemon at all.  When you install exim, "rm
> /etc/init.d/rc?.d/S*exim" and it won't start.  Local processes will be
/etc/rc?.d/S*exim
> able to send mail via the /usr/sbin/sendmail link, and there's a cronjob
> in /etc/cron.d/exim that'll try to clear the queue twice an hour.
> 
There was a discussion on this list earlier about creating a better way
than just removing a link from /etc/rc?.d.  Either it should work through
update-rc.d or debconf.  This is a lot neater than removing a link from
the startup directories, which IMHO should not have to be touched
directly by the administrator.

> > and perhaps this should be the default (correct me if this is already
> > the case, but I don't recall it being so).  Would it be feasible to
> 
> There isn't a default, it just leaves the package unconfigured, IIRC.
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; GPG public key available from:'finger [EMAIL PROTECTED]' ;;
;;


pgptIU8VUjFTI.pgp
Description: PGP signature

Re: problems with atari800

[Ben Armstrong]

On Mon, Apr 30, 2001 at 05:58:42PM -0400, Dale Scheetz wrote:
> http://atari800.atari.org/
> 
> is listed as the canonical source for all things atari, but a ping of this
> address simply hangs.

$ whois atari.org
...
   NS1.ATARI.ORG212.73.17.43
   NS2.GEMSOFT.NET  195.10.254.4

The primary nameserver, ns1.atari.org is apparently down (currently not
pingable).  Although ns2.gemsoft.net is up (I can ping it) it is not
answering my queries regarding atari800.atari.org.  It does, on the
other hand, have an NS record for atari.org itself, and a CNAME for
www.atari.org -> gem.atari.org (212.73.17.43) which we already determined
is down.  My guess is that all the atari.org stuff (DNS, web, mail)
is run off one box and since that is down, we have no atari800.atari.org
either.

> On the other hand:
> 
> http://www.signus.demon.co.uk/david/atari/atari.html

This one is a bit different.

$ host -a www.signus.demon.co.uk
www.signus.demon.co.uk  MX  10 punt-1.mail.demon.net
www.signus.demon.co.uk  MX  10 punt-2.mail.demon.net

So, it seems there are at least MX records for this address, but no A or
CNAME records.  So the web site, it seems, does not exist for the moment.
You may, however, be able to contact someone via email to that address.

In short, no, it's not just you.

Ben
-- 
nSLUG   http://www.nslug.ns.ca  [EMAIL PROTECTED]
Debian  http://www.debian.org   [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0  1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387  2D9E 5A94 F3CA 0B27 13C8 ]

Re: Many ports open by default

[Will Lowe]

> > I think it's safe to assume that your system MUST have a working MTA of
> > some sort (even if it's local-only, which is supported by eximconfig).
> This is true, but does it need to be world-accessible?  There should
> be a way to either have it listen on localhost only, or not listen on

Sure, don't run the daemon at all.  When you install exim, "rm
/etc/init.d/rc?.d/S*exim" and it won't start.  Local processes will be
able to send mail via the /usr/sbin/sendmail link, and there's a cronjob
in /etc/cron.d/exim that'll try to clear the queue twice an hour.

> and perhaps this should be the default (correct me if this is already
> the case, but I don't recall it being so).  Would it be feasible to

There isn't a default, it just leaves the package unconfigured, IIRC.

Bug#95890: ITP: gfax -- the GNU HaliFAX Sender

[Wolfgang Sourdeau]

Package: wnpp
Version: 0.4.2-1
Severity: wishlist

Licence: GNU General Public License version 2

This program is the GNU HaliFAX project's sender. It is able to
send ps data and tiff fax files through HylaFAX(tm) systems as well as
any other G3/G4-encoded TIFF fax file. Besides this, the package
includes a wrapper around the lpr command to make it possible to
launch gfax when "-Pfax" is passed as an argument.

More informations about the GNU HaliFAX project are avail=AD
able at the GNU HaliFAX official website:

http://www.gnu.org/software/halifax/


Wolfgang

Re: Many ports open by default

[mdanish]

On Mon, Apr 30, 2001 at 08:12:59PM +, Will Lowe wrote:
> > Actually there are some packages that depend on a mail-transport-agent,
> > (such as lilo->logrotate->mailx), yet one may not want to have an MTA
> > running on certain systems.  I suppose a dummy or minimal MTA may be
> 
> I think it's safe to assume that your system MUST have a working MTA of
> some sort (even if it's local-only, which is supported by eximconfig).
> Running a Unix system without an MTA *at*all* means that you won't get
> notified of failing cron jobs, etc. ...
This is true, but does it need to be world-accessible?  There should be a
way to either have it listen on localhost only, or not listen on TCP at all,
and perhaps this should be the default (correct me if this is already
the case, but I don't recall it being so).  Would it be feasible to shoot
for a base install with no daemons listening on INADDR_ANY?

> 
> > used (and may exist, I'm not aware), but this certainly highlights the
> 
> "apt-get install ssmtp".  Note that this has terrible behaviour on even
> transient failure -- it just drops messages into dead-letter.  Exim (don't
> run the daemon, just the cronjob that cleans the queue) works better for
> me.
> 
> The OTHER daemons (certainly xdm) are optional.  But I think it's probably
> safe to say that running Debian without an MTA is "unsupported".
> 
>   Will
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; GPG public key available from:'finger [EMAIL PROTECTED]' ;;
;;


pgpk7UZBqhFsa.pgp
Description: PGP signature

Re: Bug#95818: libpgsql2.1: should not depend on ident-server

[Brian May]

> "Oliver" == Oliver Elphick  writes:

Oliver> It is indeed the case that ident is needed to allow local
Oliver> access without a password.  I understand that this
Oliver> presents a small security risk on the server.  However,
Oliver> without it, it is necessary for the postgres
Oliver> administrator's database password to be held in clear in
Oliver> some file, so that the automatic clean-up processes will
Oliver> be able to operate.

Could be a disaster on some systems. I think same ident servers, like
oidentd, allow individual users to customise their own responses:

[...]

   -s Allow identd reply spoofing. In order  for  a  non-
  root  user  to spoof its identd reply, the username
  must be listed in /etc/identd.spoof.   The  spoofed
  reply   can   optionally   be   specified   in  the
  /etc/identd.spoof   file. Forexample,if
  "user:string"  were  an entry in /etc/identd.spoof,
  any successful lookups for "user" would  result  in
  the reply "string" being returned.  If the reply is
  not specified in the  /etc/identd.spoof  file,  the
  spoofed  reply will be read from an .ispoof file in
  the user's home directory. If a user is not allowed
  to  spoof identd replies or there is an error read­
  ing the .ispoof file,  if  the  -r  flag  has  been
  passed to identd, a randomized identd reply will be
  returned. If  not,  the  user's  username  will  be
  returned.  Non-root  users  are  allowed  to  spoof
  identd replies on ports greater than 1023. Non-root
  users  may spoof identd replies on all ports if the
  -A option is specified.

   -S Same as '-s' but allow all users  to  spoof  identd
  replies  except  for  those  users  listed  in  the
  /etc/identd.spoof file.

[...]

   $HOME/.ispoof
  File containing username to return when oidentd  is
  run with the -s flag.

[note: the above requires careful reading; in order to enable non-root
spoofing you have to pass -s *and* put the user in the
/etc/identd.spoof file *without* a reply; -S is different]

This isn't something I like (read: hate), but I am bringing it up
because it could be a serious security hole when used by programs like
postgresql.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Proposing task-debian

[Alan Shutko]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> In many Linux distributions, Emacs is a high-level installation task, like
> "Games" or "Mail".  This makes sense to the average user, who usually either
> wants Emacs or does not.

For a little amplification, while "Emacs as an editor" may not make
much sense as a task (only a couple packages), a task which installed
most Emacs add-ons might be useful.

-- 
Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors!
I used to have a drinking problem.  Now I love the stuff.

Re: Proposing task-debian

[John Hasler]

Matt Zimmerman writes:
> I think it makes as much sense as the existing task packages.

Many of which make no more sense than would task-emacs.

> Perhaps task-devel-emacs would be the logical analogue.

Why would someone who wants emacs so that he can read news and mail with
gnus and work on his Web page install task-devel-emacs?  That's obviously
for people who want to hack on emacs.

How about an ordinary meta-package named "emacs"?
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: debbugs can now send bug mails to someone different than the maintainer

[Brian May]

> "Matt" == Matt Zimmerman <[EMAIL PROTECTED]> writes:

Matt> Unless, of course, you can do your filtering on the mail
Matt> server, as I do.

In my case, my MTA server is on the wrong side of my permanent
28.8kbps modem link.

Of course, I could make master.debian.org my server, too. Just not as
convenient (I would need to implement something, eg. fetchmail based
for retrieving the mail.) One day, I need to investigate fetchmail,
and how it works. Or that BSMTP stuff.
-- 
Brian May <[EMAIL PROTECTED]>

imp broken in unstable?

[Brian May]

Hello,

Recently, not long after I upgraded imp and horde to unstable, it broke :-(

Now whenever I try to use it I can compilation warnings like this:

Warning: This compilation does not support pg_cmdtuples() in 
/etc/horde/db_pgsql.inc on line 122

Warning: PostgresSQL query failed: ERROR: Cannot insert a duplicate key into 
unique index active_sessions_pkey in
/etc/horde/db_pgsql.inc on line 52

(the first line always occurs every-time, the second line is
intermittent).

The Debian maintainer said he was unable to help (see bug #95683),
however he suggested it was a postgresql problem. He also downgraded
the bug to normal

However, if I run apache from my stable chroot, which uses the stable
version of horde and imp, then everything works fine, even with
postgresql 7.0 (I am going to refrain from upgrading again until I get
this sorted out).

So, any ideas how I should solve this? Or do I conclude that imp in
unstable is broken, and unusable in my given configuration?
-- 
Brian May <[EMAIL PROTECTED]>

Re: kernel-{image,headers} package bloat

[Tollef Fog Heen]

* "Vince Mulhollon" 

| But what happens when people provide / request / demand optimized
| versions of Gnome, KDE, and Apache for every possible combination of
| optimization?

You point them to pentium-builder, or Debian moves to a 'make world'
paradigm.  Or we bloat the archives a lot.  I hope for the first most
and the last least.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Ben Darnell]

This thread is directed at the wrong bug number - the discussion is about
#95430, but the messages are going to #95420.  Please adjust the recipients
appropriately in your replies.

-Ben
- Original Message -
From: "Zack Weinberg" <[EMAIL PROTECTED]>
To: "Debian Bug Tracking System" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; 
Sent: Monday, April 30, 2001 3:16 PM
Subject: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash:
word-splitting changes break shell scripts)


> reopen 95420
> quit
>
> ...
> > On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote:
> > >
> > > ash 0.3.8-1 incorporates changes in word splitting which break common
> > > shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used
> > > when compiling GCC.
> > >
> > > #! /bin/ash
> > > OIFS=$IFS
> > > IFS=,
> > > set `echo fnord,a,b,c`
> > > IFS=$OIFS
> > > CMD="echo $@"
> > > $CMD
> >
> > Sorry, but this is broken.  This assumes that IFS is set to begin with
> > which may not be the case.
>
> I have consulted the Single Unix Standard and can find only dubious
> justification for this assertion.  It never flat out says whether IFS
> is to be set on entry to the shell or not.  However, I note this
> paragraph:
>
> # IFS
> #Input field separators: a string treated as a list of characters
> #that is used for field splitting and to split lines into fields
> #with the read command. If IFS is not set, the shell will behave
> #as if the value of IFS were the space, tab and newline
> #characters. (See Field Splitting .)
>
> I could read that as requiring that if IFS is unset, then you get
> "" if you inspect its value, NOT the null string.
>
> In any case, your change is a gratuitous divergence from the upstream
> code and a deliberate breakage of consensus shell behavior.  My script
> functions correctly with every Bourne-descended shell I have access to
> except ash 0.3.8-1.  (In addition to bash, pdksh, and previous
> versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX,
> and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by
> Solaris.)  Irrespective of what the standard says, you cannot
> introduce changes into /bin/sh which make it behave differently from
> every other shell out there.  Especially if they have the potential to
> break every shell script which uses some feature.
>
> I had hoped that you had learned your lesson from the last time you
> pulled a stunt like this.  It seems I was wrong.
>
> zw
>
>

Re: debbugs can now send bug mails to someone different than the maintainer

[James Troup]

Julian Gilbey <[EMAIL PROTECTED]> writes:

> What I am suggesting is that katie has a list of such cases (although
> I'm not proposing a particular format):

>From my point of view, such information would ideally be:

  o not centrally controlled, but package/maintainer(s) controlled[0]
  o trivial (both in terms of code and CPU use) for katie to obtain[1]
  o not unnecessarily waste space in places it's not needed[2]
 
I'd love to see suggestions that satisfy those criteria, but was
eventually someday going to fall back on something like Julian just
suggested if I couldn't find anything better.

-- 
James

[0] There's already too much centrally controlled information and no
need for this information to be controlled centrally.

[1] Although correctness is far more important for katie than speed,
it is a (minor) issue and katie is already relatively slow.  

[2] i.e. not in somewhere like the .dsc file.

Re: debbugs can now send bug mails to someone different than the maintainer

[Julian Gilbey]

On Mon, Apr 30, 2001 at 11:50:59PM +0200, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > But I'm *not* the maintainer; I'm one of a group of maintainers.  If
> > we do this, then every time one of us uploads, we need to change the
> > maintainer name in the control file.
> 
> You needed to do that anyway. The problem you have is that dinstall
> has no way to figre out if you are one of the official maintainers.

No; at present, we only have to enter the correct entry in the
changelog, keeping "Debian policy list "
in the control file Maintainer field.  Then all of our uploads are
considered NMUs and we have to close the bugs manually thereafter (how
lazy we have become!).

What I am suggesting is that katie has a list of such cases (although
I'm not proposing a particular format):

[...]
debian-policy: Manoj Srivastava <[EMAIL PROTECTED]>
debian-policy: Julian Gilbey <[EMAIL PROTECTED]>
[...]

(or perhaps one file per special package containing the names one per
line would be easier), then katie would do something like the
following test:

if ($source_upload) then
  if ($maintainer == $uploader or
  "$package: $uploader" is line in special maintainers file)
  then
<>
  else
<>
  fi
else
  <>
fi

   Julian

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

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Herbert Xu]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:

> Of course, it seems that this behavior is different from that of traditional
> Bourne shell implementations, so I think I have to agree that ash should avoid
> diverging from tradition in order to adhere to a relatively new standard.

I will probably change it back in the next release due to all the autoconf
breakage.  However, it still remains that these scripts need to be fixed
since their caller can also unset IFS.
-- 
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

Re: Proposing task-debian

[Matt Zimmerman]

On Mon, Apr 30, 2001 at 04:36:14PM -0500, John Hasler wrote:

> Matt Zimmerman writes:
> > I think Emacs as a task makes good sense.
> 
> I think getting it out of standard makes good sense, but I'm not convinced
> that it makes sense as a "task".

I think it makes as much sense as the existing task packages.  For example, we
have task packages for roxen (task-webserver-roxen), roxen2
(task-webserver-roxen2), and PostgreSQL (task-database-pg).  These refer to
specific implementations of a task, not just an abstract task.  Perhaps
task-devel-emacs would be the logical analogue.

In many Linux distributions, Emacs is a high-level installation task, like
"Games" or "Mail".  This makes sense to the average user, who usually either
wants Emacs or does not.

-- 
 - mdz

problems with atari800

[Dale Scheetz]

I've been working on getting the newest atari800 code to build for Debian,
and I've run into some problems. (Well, yes, I'm having some compilation
problems as well, but this isn't about those...)

There are several sites that are pretty critical to the proper opperation
of this package that I can't get to at all.

I've been having problems with my new 2.2.19 kernel and mozilla's proper
behavior, however this behavior is also seen when running 2.2.17, like I
am using now. Also, on a clean running kernel and netscape I get
consistantly poor results.

http://atari800.atari.org/

is listed as the canonical source for all things atari, but a ping of this
address simply hangs. On the other hand:

http://www.signus.demon.co.uk/david/atari/atari.html

is even more important as it is the repository of all the various machine
ROM images needed to make the emulator do something useful.

If I ping www.signus.demon.co.uk I get an immediate "unknown host" error.

I _can_ ping other sites with no particular problem. If my local network
configuration is fragged, it is a very subtle situation, and not likely
anything I intentionally set up ;-)

Even once I can compile the current release, I'm not happy doing all this
work, only to be unable to make it work to any good purpose when complete.

Can anyone verify the existance/non-existance of these sites?

The site that _does_ work for me is:

ftp://ftp.sophics.cz/pub/Atari800

and you can pick up the source for 1.0.6 (the latest version) that
includes several other links in materials found in the DOC subdirectory.

I'm not sure whether I can trust my browser (or ping) to tell me the
truth, as I currently have my Sparc in such a state that I can't ping out
the ppp connections ;-( so it wouldn't surprise me to find something
subtly broken on my main intel machine as well...

And I know from extensive testing that an NFS enabled 2.2.19 kernel will
royally fragg mozilla's ability to make certain kinds of connections.
These symptoms go away when the previous kernel is booted.

So at this point I don't feel like I can trust anything I "know" about my
system, or what it's doing to me this time. 

Does any of this make any sense at all?

Are the above sites really unavailable?

Help,

Dwarf
--
_-_-_-_-_-   Author of "Dwarf's Guide to Debian GNU/Linux"  _-_-_-_-_-_-
_-_-
_- aka   Dale Scheetz   Phone:   1 (850) 656-9769 _-
_-   Flexible Software  11000 McCrackin Road  _-
_-   e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308_-
_-_-
_-_-_-_-_-  Released under the GNU Free Documentation License   _-_-_-_-
  available at: http://www.polaris.net/~dwarf/

Re: debbugs can now send bug mails to someone different than the maintainer

[Wichert Akkerman]

Previously Julian Gilbey wrote:
> But I'm *not* the maintainer; I'm one of a group of maintainers.  If
> we do this, then every time one of us uploads, we need to change the
> maintainer name in the control file.

You needed to do that anyway. The problem you have is that dinstall
has no way to figre out if you are one of the official maintainers.

Wichert.

-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Matt Zimmerman]

On Mon, Apr 30, 2001 at 12:16:16PM -0700, Zack Weinberg wrote:

> [whose words are these? unattributed in your mail]
> > Sorry, but this is broken.  This assumes that IFS is set to begin with
> > which may not be the case.
> 
> I have consulted the Single Unix Standard and can find only dubious
> justification for this assertion.  It never flat out says whether IFS
> is to be set on entry to the shell or not.  However, I note this
> paragraph:
> 
> # IFS
> #Input field separators: a string treated as a list of characters
> #that is used for field splitting and to split lines into fields
> #with the read command. If IFS is not set, the shell will behave
> #as if the value of IFS were the space, tab and newline
> #characters. (See Field Splitting .)
> 
> I could read that as requiring that if IFS is unset, then you get
> "" if you inspect its value, NOT the null string.

I have to disagree with this interpretation.  The sentence above specifies that
"the shell will behave _as if_ the value of IFS were..." (emphasis added).
This implies that IFS does not necessarily have any value at all, and its value
certainly should not be relied upon.  If the intention were to have a default
value for the IFS variable, it would have been much more straightforward to say
"If IFS is not set, the shell will assign it the value..."

Of course, it seems that this behavior is different from that of traditional
Bourne shell implementations, so I think I have to agree that ash should avoid
diverging from tradition in order to adhere to a relatively new standard.

-- 
 - mdz

Re: debbugs can now send bug mails to someone different than the maintainer

[Julian Gilbey]

On Mon, Apr 30, 2001 at 05:35:54AM -0500, Adam Heath wrote:
> > I've got another request, but I reckon it's a katie one: it would be
> > really nice if the Maintainer could be a mailing list (eg,
> > [EMAIL PROTECTED]) and that katie would recognise one of a small
> > list of names and emails for the Changed-By field as being maintainers
> > for the package.  I'm sure there are several packages like this which
> > would benefit from such a change.  If I learn Python one day, I would
> > happily write a patch for this.
> 
> That's why this change is for.  You set the Maintainer in debian/control to be
> the uploader.  This way, katie will do the right thing.  However, using the
> above debbugs feature, bug reports can go elsewhere, your above mentioned
> list.

But I'm *not* the maintainer; I'm one of a group of maintainers.  If
we do this, then every time one of us uploads, we need to change the
maintainer name in the control file.

   Julian

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

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Proposing task-debian

[John Hasler]

Matt Zimmerman writes:
> I think Emacs as a task makes good sense.

I think getting it out of standard makes good sense, but I'm not convinced
that it makes sense as a "task".
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: package servers inconsistent?

[Matt Zimmerman]

On Mon, Apr 30, 2001 at 08:50:06PM +0200, Harald Dunkel wrote:

> Is it possible to keep an eye upon package consistency on the
> hosts 'http.us.debian.org'?
> 
> Each time I run 'apt-get update', some of the package lists on my
> machine seem to be outdated, even if the last update has been done
> just a few jiffies ago. But usually the following 'apt-get ugrade' 
> fails due to missing packages. 
> 
> I have to repeat this procedure several times until the upgrade can 
> be completed successfully. Sometimes this doesn't work at all.
> I tried to install a caching proxy, but this did not help.

This happens because the Packages files on the mirrors are updated before all
of the .debs have been transferred.  The errors are transient, and only happen
during the mirror updates.  It is probably more trouble than it is worth to try
to fix this.  The solution would involve syncing all new .debs (without
deleting any), then updating the Packages files, then removing the old .debs.
This has the nice side effect of ensuring that things are consistent even if
the update is interrupted, but would consume a lot of additional mirror space
during the updates, and complicate the process.

Another "solution" would be to remove the Packages files during the update, but
I think almost everyone would rather have an inconsistent Packages file than
none at all.

-- 
 - mdz

Perl module location

[Julian Gilbey]

(The following is based on the information in the Contents-i386 file
on ftp-master.)

I just filed bugs on about 5 packages which install Perl modules into
/usr/share/perl/5.6.0 against the perl policy.  But then I checked to
see if there are any packages installing into /usr/lib/perl/5.6.0, and
I discovered that there are 16 which shouldn't, and I'm a little more
loathe to file 16 identical bug reports.

The next thing I checked was for dependencies.  These are somewhat
important due to the @INC restructuring.  There are 212 packages which
have files in /usr/lib/perl5.  Their perl dependencies look like this:

 Perl dependency number of packages
 --- --
Probably correct packages:
  perl (>= 5.6.0-x), perlapi-5.6.0  58  (where x>=16)
  perl-base (>= 5.6.0-x), perlapi-5.6.0  1

Almost certainly incorrect packages:
   8
  perl  23
  perl (>= 5.006), perlapi-5.6.0 1
  perl (>= 5.6.0-16) 3
  perl | perl5   2
  perl, perl-5.005 | perl-5.61
  perl-5.005 7
  perl-5.005 | perl-5.6, perl5   1
  perl-5.6  12
  perl-modules (>= 5.6.0), perl  1
  perl5 84
  perl5 | perl   3
  perl5 | perl (>= 5.002)2
  perl5 | perl (>=5.004) 1
  perl5|perl 1
  perl5|perl5-base   1

  Total incorrect: 153

And now for those using /usr/share/perl5, of which there are 94
packages:

 Perl dependency number of packages
 --- --
Probably correct packages:
  perl (>= 5.6.0-16) 1

Almost certainly incorrect packages:
   2
  perl  85
  perl (>= 5.6.0)1
  perl, perl (>= 5.6.0)  1
  perl, perl51
  perl-base (>= 5.6.0-4) 1
  perl5  2

So only one of them has it right.

The current debhelper (>=3.0.18, in particular dh_perl), if it's used,
gets it right.  I haven't even bothered to try checking that the
Build-Depends(-Indep) on debhelper is versioned (>= 3.0.18), but it
needs to be.

Any suggestions where to go from here?  A post on -devel-announce,
perhaps?

   Julian

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

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Herbert Xu]

Zack Weinberg <[EMAIL PROTECTED]> wrote:
>> On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote:
>> > 
>> > ash 0.3.8-1 incorporates changes in word splitting which break common
>> > shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used
>> > when compiling GCC.
>> > 
>> > #! /bin/ash
>> > OIFS=$IFS
>> > IFS=,
>> > set `echo fnord,a,b,c`
>> > IFS=$OIFS
>> > CMD="echo $@"
>> > $CMD
>> 
>> Sorry, but this is broken.  This assumes that IFS is set to begin with
>> which may not be the case.

> I have consulted the Single Unix Standard and can find only dubious
> justification for this assertion.  It never flat out says whether IFS
> is to be set on entry to the shell or not.  However, I note this
> paragraph:

It's wrong regardless of whether the shell sets it.  The whole point of
saving IFS is so that you can restore it to its original value, which can
be whatever the previous user has set it to, including the case of it not
being set at all.  If your code can't handle that, then please don't save
the value at all.

BTW, there is a shorter way of saving it:
OIFS="${IFS-
"

> # IFS
> #Input field separators: a string treated as a list of characters
> #that is used for field splitting and to split lines into fields
> #with the read command. If IFS is not set, the shell will behave
> #as if the value of IFS were the space, tab and newline
> #characters. (See Field Splitting .)

> I could read that as requiring that if IFS is unset, then you get
> "" if you inspect its value, NOT the null string.

I think this is stretching it a bit.  Please try this in any shell:

unset IFS
echo ${IFS+yes}

If you get yes from any shell, then you might have a point.  I've certainly
never seen one that hehaved like that.

> In any case, your change is a gratuitous divergence from the upstream
> code and a deliberate breakage of consensus shell behavior.  My script
> functions correctly with every Bourne-descended shell I have access to
> except ash 0.3.8-1.  (In addition to bash, pdksh, and previous
> versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX,
> and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by
> Solaris.)  Irrespective of what the standard says, you cannot
> introduce changes into /bin/sh which make it behave differently from
> every other shell out there.  Especially if they have the potential to
> break every shell script which uses some feature.

I can understand how frustrating it is to have your scripts broken by
this.  But the fact remains that it's the scripts that are broken, not the
shell.

Are your functions supposed to be called by other scripts in general? If
so, then it's particularly important to handle the case of an unset IFS.
-- 
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

latex2html/netpbm/undefined symbol: pm_optParseOptions2

[Thomas R. Shemanske]

I have a production machine which was 95% potato.  I had to update the
libc6 libraries to install a couple of woody packages which were needed
by
others.

I found today that latex2html was broken.  

The error I am trying to track down is:

/usr/bin/pnmcrop: error while loading shared libraries: 
 /usr/bin/pnmcrop: undefined symbol: pm_optParseOptions2


I should point out that latex2html is not broken on potato nor on
sid.  Unfortunately this machine is now in an in between state.

Since the libc libraries had already been updated, there was no going
back to potato, so I began a very gradual upgrade of pieces of the
system,
in particular latex2html, gs-aladdin, and netpbm (and perl to 5.6).

Running latex2html with the -debug option yields (processing the first
image):

Converting image #20
Debug (syswait): Running "/usr/bin/perl /usr/bin/pstoimg -type png
-debug -tmp /tmp/l2h23593 -discard -interlace -antialias -depth 1 -scale
1.6 -geometry 33x19 -margins 42,72 -crop abls -transparent -out
img20.png /tmp/l2h23593/image020.ps" at /usr/bin/latex2html line 4181
pstoimg V2K.1beta (Revision 1.11, Perl 5.006)
pstoimg: Temporary directory is /tmp/l2h23593
pstoimg: Processing /tmp/l2h23593/image020.ps
pstoimg: EPSF dimensions are 38x27
pstoimg: Running /usr/bin/gs  -sDEVICE=ppmraw -g61x44  -r115
-dTextAlphaBits=4  -sOutputFile=/tmp/l2h23593/p23606.pnm 
GS>-41 -694 translate
GS>(/tmp/l2h23593/image020.ps) run
GS>showpage
GS>quit

AFPL Ghostscript 6.50 (2000-12-02)
Copyright (C) 2000 Aladdin Enterprises, Menlo Park, CA.  All rights
reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>GS>Loading NimbusRomNo9L-ReguItal font from
/usr/local/share/ghostscript/fonts/n021023l.pfb... 1937100 587299
1717732 395678 0 done.
Loading StandardSymL font from
/usr/local/share/ghostscript/fonts/s05l.pfb... 1977292 626066
1717732 403659 0 done.
>>showpage, press  to continue<<
GS>>>showpage, press  to continue<<
GS>Running "/usr/bin/pnmcrop < /tmp/l2h23593/p23606.pnm |
/usr/bin/pnmcrop -bot | /usr/bin/pnmcrop -l  > /tmp/l2h23593/p23606.t01"
/usr/bin/pnmcrop: error while loading shared libraries:
/usr/bin/pnmcrop: undefined symbol: pm_optParseOptions2
/usr/bin/pnmcrop: error while loading shared libraries:
/usr/bin/pnmcrop: undefined symbol: pm_optParseOptions2
/usr/bin/pnmcrop: error while loading shared libraries:
/usr/bin/pnmcrop: undefined symbol: pm_optParseOptions2
pstoimg: Error: "/usr/bin/pnmcrop < /tmp/l2h23593/p23606.pnm |
/usr/bin/pnmcrop -bot | /usr/bin/pnmcrop -l  > /tmp/l2h23593/p23606.t01"
failed: 
Debug (syswait): Finished child process: #23606
 at /usr/bin/latex2html line 4181

Error while converting image

Error: Cannot read 'img20.png': No such file or directory





The error occurs with pcmcrop provided by netpbm (current with sid),
but I have had no luck tracking down the undefined symbol:
pm_optParseOptions2.

I *really* would prefer not to upgrade this machine to sid, so any
help in tracking this down would be greatly appreciated.

Many thanks,

Tom


-- 
Thomas R. Shemanske
(Mailing Address)  (Office/Internet Information)
Department of Mathematics  203 Choate House
6188 Bradley Hall  [EMAIL PROTECTED]
Dartmouth College  http://www.math.dartmouth.edu/~trs/
Hanover, NH 03755-3551 (603) 646 - 3179 

Directions:  http://www.math.dartmouth.edu/~trs/choatehouse.html
Office hours: 
http://www.math.dartmouth.edu/~trs/frontmatter/office.html

Spring Term Office Hours:  By appointment

Re: kernel-{image,headers} package bloat

[Paul Martin]

On Thu, Apr 26, 2001 at 05:39:34PM +0200, Kenneth Vestergaard Schmidt wrote:
> If instead, you were able to type something akin to "update-kernel" or 
> whatever, and then have a kernel built suited to your arch, but with the 
> "default" Debian-options (ie. lotsa modules), wouldn't that be better? I 
> mean, just make a note to the user, to switch to another console, or minimize 
> the window in case of X. Then he'll get a kernel freshly built. IMHO, that's 

A compromise would be for the kernel-image- build environment for each
kernel-image- to be packaged as, say "kernel-builder-2.4.4-686-smp",
which would (I guess) consist of a depends on kernel-package,
initrd-tools and mkcramfs, a script to make and install the kernel using
make-kpkg, and the linux/.config file needed for that particular
configuration.

I'd suspect that each of these packages would be of the order of
64kbytes maximum.

-- 
Paul Martin <[EMAIL PROTECTED]>

Processed: RE: Bug#95875: Package 'console-data' missing in woody

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 95875 console-data
Bug#95875: Package 'console-data' missing in woody
Bug reassigned from package `general' to `console-data'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Darren Benham
(administrator, Debian Bugs database)

Re: Proposing task-debian

[Matt Zimmerman]

On Mon, Apr 30, 2001 at 10:03:49AM -0500, John Hasler wrote:

> Anthony Towns writes:
> > ...what would people think of making a task-emacs and moving both tetex
> > and emacs out from standard?
> 
> As an emacs user I think this is an excellent idea, but I worry that
> such stretching of the definition of "task" may confuse users.

I think Emacs as a task makes good sense.  Policy seems to agree (Chapter 2,
where the "standard" priority is defined: "this is more of a piece of
infrastructure than an application").

-- 
 - mdz

Re: debbugs can now send bug mails to someone different than the maintainer

[Adam Heath]

On Mon, 30 Apr 2001, Julian Gilbey wrote:

> On Tue, Apr 24, 2001 at 04:25:16AM -0500, [EMAIL PROTECTED] wrote:
> > I have just added support to debbugs in cvs, and on master, so that the
> > maintainer address for a package can be overriden.  This allows the real
> > maintainer to be someone different than the person or list that gets the 
> > bugs.
> >
> > This is useful, when the real maintainer is doing the upload, and dinstall
> > compares the uploader to the real maintainer, but an entire list of people
> > should actually get the bug reports.
>
> I've got another request, but I reckon it's a katie one: it would be
> really nice if the Maintainer could be a mailing list (eg,
> [EMAIL PROTECTED]) and that katie would recognise one of a small
> list of names and emails for the Changed-By field as being maintainers
> for the package.  I'm sure there are several packages like this which
> would benefit from such a change.  If I learn Python one day, I would
> happily write a patch for this.

That's why this change is for.  You set the Maintainer in debian/control to be
the uploader.  This way, katie will do the right thing.  However, using the
above debbugs feature, bug reports can go elsewhere, your above mentioned
list.

404's

[Adam McKenna]

It seems like an easy way to prevent the following would be to update the
Packages.gz file LAST, after syncing up the other files, IE:

rsync --exclude "Packages*" debian/pool
rsync --delete debian/pool  (If old packages are even deleted)

--Adam

[EMAIL PROTECTED]:~$ sudo apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages have been kept back
  dnsutils sysklogd 
96 packages upgraded, 0 newly installed, 0 to remove and 2  not upgraded.
Need to get 24.4MB/57.0MB of archives. After unpacking 1949kB will be used.
Do you want to continue? [Y/n] 
Err http://http.us.debian.org unstable/main rpm 4.0.2-6
  404 Not Found [IP: 192.25.206.10 80]
Err http://http.us.debian.org unstable/main libpopt0 1.6.2-5
  404 Not Found [IP: 192.25.206.10 80]
Err http://http.us.debian.org unstable/main lilo 1:21.7.1-4
  404 Not Found [IP: 192.25.206.10 80]
Err http://http.us.debian.org unstable/main modutils 2.4.5-1
  404 Not Found [IP: 192.25.206.10 80]
Err http://http.us.debian.org unstable/main libmysqlclient10 3.23.37-3
  404 Not Found [IP: 192.25.206.10 80]
Err http://http.us.debian.org unstable/main librpm0 4.0.2-6
  404 Not Found [IP: 192.25.206.10 80]
Err http://http.us.debian.org unstable/main libxaw6 4.0.3-1
  404 Not Found [IP: 192.25.206.10 80]
Err http://http.us.debian.org unstable/main libxaw7 4.0.3-1
  404 Not Found [IP: 192.25.206.10 80]

-- 
Adam McKenna  <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>

Re: kernel-{image,headers} package bloat

[Vince Mulhollon]

On 04/30/2001 03:21:55 PM "Christopher C. Chimelis" wrote:

>> Basically, I can understand everyone's desires for a kernel that covers
>> their cases (SMP, UP, 686, 386, etc), but the bloat issue that initially

I can't understand that desire for such a small gain, but whatever.

>> this thread gets more and more Intel/AMD-centric, I'm beginning to
wonder
>> what the larger implications may be...

I would think an even scarier larger implication is that on my desktop
machines, it's not unusual to have less than 10% kernel utilization.  Thus
even in the wildest dreams, no level of "optimization" can have more than a
2% effect on overall CPU speed.  But what happens when people provide /
request / demand optimized versions of Gnome, KDE, and Apache for every
possible combination of optimization?  I'm sure an optimized libc would
have more impact that an optimized kernel.  I'm sure my webserver would
benefit far more from "optimized" Apache and Perl than it would from an
"optimized" kernel, based on crude observations of the "top" command.

The problem is not providing "optimized" versions of one "little" package,
the problem is opening the floodgates to recompiles of every package in
Debian with every possible combination of optimization.

In an example that is fairly silly, if I recompile the kernel for a machine
with a CPU that costs $300 (my processors are usually cheaper) and it gets
a 20% kernel performance boost (totally unrealistic daydream) and it
typically spends 10% of it's time in kernel space (probably less), that's
the equivalent of saving me $6 over the cost of just buying the next faster
processor.  Now compare $6 to the cost of the electricity to run the box,
or my salary to properly install and test the "optimized" kernel and I just
don't see the payoff.  Then there are the non-monetary costs, someone
spending time making 20 different compilations of the same package is not
spending time fixing bugs or playing Quake or drinking beer.

Or on my firewall and kiosk machines using $50 special computers, the
processor is probably worth $5 so I'd figure the optimizations save me 10
cents over the cost of upgrading the CPU to a faster one.

Bug#95875: Package 'console-data' missing in woody

[Michael Karcher]

Package: general
Version: N/A; reported 2001-04-30
Severity: important

There is no package 'console-data' in the woody distribution. This means
no keyboard except US is supported. The package 'console-data' from sid
does work.

-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux spartacus.karcher.de 2.4.2 #3 Fri Apr 27 09:16:33 CEST 2001 i486

Re: Many ports open by default

[Matt Zimmerman]

On Tue, May 01, 2001 at 12:22:47AM +1000, Craig Sanders wrote:

> On Sun, Apr 29, 2001 at 10:29:58PM -0600, Dwayne C. Litzenberger wrote:
> > I suspect it's already been discussed before, so I'll ask instead of
> > flaming.  (See!  I can learn!)
> 
> many times before.
> 
> > Why does a server automatically get run just because it's installed?
> 
> because if you didn't want it to run, you wouldn't have installed it.
> 
> if you want to install it but not run it, then edit the startup script.
> 
> simple.

Or, rm /etc/rc?.d/S??package, and not have to worry about merging in future
changes to the init script.

-- 
 - mdz

looking for missing mail

[Filip Van Raemdonck]

Hi,

Due to dissappearance of my mail provider I have missed the mail from this
list from friday til sunday (until I resubscribed with another address).

I'd be very thankfull if someone could send me a file with the missing mails.

For mutt users I can even tell how to do this; in the index view type in

T ~d 27/04/2001-29/04/2001 ;C somefile ;t

then the `somefile' can be mailed over to me.

Thanks,

Filip

-- 
 "well, I use Linux instead of Windows. that's why I cant use that
program." "but isnt it a PC?" "Yes." "then it isnt a mac. you can use
it" "No, I cant. I use Linux." ..
 it goes on to "linux is an OS. not a program." "OS?"


pgpR1KP5uATgw.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[Scott Dier]

* Daniel Stone <[EMAIL PROTECTED]> [010424 07:03]:
> ONE HUNDRED AND TEN MEGABYTES PER KERNEL RELEASE DOES NOT HELP MIRRORS WHICH 
> HAVE 
> OUT OF SYNC PACKAGES FILES AND ACTUAL PACKAGES HALF THE TIME.

Being a maint. of two debian mirrors, I don't get your point. :)

Could you please turn this into something that is worth arguing about,
and find some mirrors that are actually configured to mirror at times
that wont create a un-synched unstable area?

This is a mirror-admin-setup-problem, and not a problem of the 'size' of
the mirror.

-- 
Scott Dier <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
http://www.ringworld.org/  [EMAIL PROTECTED]

So little time, so little to do.-- Oscar Levant


pgpoPtJ5ax9Yv.pgp
Description: PGP signature

Re: kernel-{image,headers} package bloat

[Christopher C. Chimelis]

On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote:

> Unfortunately it seems that a kernel that supports both i386 and SMP
> would have to use very slow methods for locking since instructions
> allowing faster locking only came in with the 486 and above.

I'm wondering when this whole discussion will include other ports and
their kernel requests...

Basically, I can understand everyone's desires for a kernel that covers
their cases (SMP, UP, 686, 386, etc), but the bloat issue that initially
started this thread would be multiplied if the same type of solutions were
implemented for the other archs.  Alpha is now simplified, for the most
part, and can use a "generic" kernel that doesn't suffer performance-wise,
but we still have some exceptions (Ruffian, SMP, etc).  If UP and SMP
kernels were provided on i386, then we would request the same.  I would
assume sparc, powerpc, etc may also request the same.  This could lead to
an even larger archive bloat than this thread is trying to prevent...

I've been clueless on how to solve this problem (or even what kind of
solution may be needed to begin with since I don't see the current
situation as being "a problem"), so I haven't spoken until now, but as
this thread gets more and more Intel/AMD-centric, I'm beginning to wonder
what the larger implications may be...

C

Re: debbugs can now send bug mails to someone different than the maintainer

[Julian Gilbey]

On Tue, Apr 24, 2001 at 04:25:16AM -0500, [EMAIL PROTECTED] wrote:
> I have just added support to debbugs in cvs, and on master, so that the
> maintainer address for a package can be overriden.  This allows the real
> maintainer to be someone different than the person or list that gets the bugs.
> 
> This is useful, when the real maintainer is doing the upload, and dinstall
> compares the uploader to the real maintainer, but an entire list of people
> should actually get the bug reports.

I've got another request, but I reckon it's a katie one: it would be
really nice if the Maintainer could be a mailing list (eg,
[EMAIL PROTECTED]) and that katie would recognise one of a small
list of names and emails for the Changed-By field as being maintainers
for the package.  I'm sure there are several packages like this which
would benefit from such a change.  If I learn Python one day, I would
happily write a patch for this.

   Julian

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

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Many ports open by default

[Will Lowe]

> Actually there are some packages that depend on a mail-transport-agent,
> (such as lilo->logrotate->mailx), yet one may not want to have an MTA
> running on certain systems.  I suppose a dummy or minimal MTA may be

I think it's safe to assume that your system MUST have a working MTA of
some sort (even if it's local-only, which is supported by eximconfig).
Running a Unix system without an MTA *at*all* means that you won't get
notified of failing cron jobs, etc. ...

> used (and may exist, I'm not aware), but this certainly highlights the

"apt-get install ssmtp".  Note that this has terrible behaviour on even
transient failure -- it just drops messages into dead-letter.  Exim (don't
run the daemon, just the cronjob that cleans the queue) works better for
me.

The OTHER daemons (certainly xdm) are optional.  But I think it's probably
safe to say that running Debian without an MTA is "unsupported".

Will

Re: Keysigning request in New York City

[Jimmy Kaplowitz]

I don't think I'll need it - Dave Baker <[EMAIL PROTECTED]> and Itai Zukerman
<[EMAIL PROTECTED]> both seem to be able and willing to sign my key. If
that fails for some reason, I'll contact you, but don't plan on it.

Thanks very much for the offer though.

- Jimmy Kaplowitz
[EMAIL PROTECTED]

On Sun, Apr 29, 2001 at 01:29:19PM -0400, [EMAIL PROTECTED] wrote:
> I will be back in the NYC area on May 16th, if no one else has signed your
> key by then, I will do it.
> 
> On Sun, Apr 29, 2001 at 12:33:39PM -0400, Jimmy Kaplowitz wrote:
> > Hi, I have recently started maintaining a Debian package for Althea, an IMAP
> > email client for GTK+. That package, thanks to the sponsorship of current
> > Debian developer Bas Zoetekouw <[EMAIL PROTECTED]>, is now in unstable. I 
> > would
> > like to become a Debian developer so that I can upload that package by 
> > myself,
> > so is there anyone in the New York City area who can sign my GPG key?
> > 
> > Please CC me on any replies, for until I have time to set up a procmail 
> > filter
> > that works with Maildir and separates out messages from this list, I am not
> > subscribed to debian-devel.
> > 
> > Thanks.
> > 
> > - Jimmy Kaplowitz
> > [EMAIL PROTECTED]
> > 
> > 
> > -- 
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> > 
> 
> -- 
> ;;
> ;; Matthew Danish email: [EMAIL PROTECTED] ;;
> ;; GPG public key available from:'finger [EMAIL PROTECTED]' ;;
> ;;

Re: Many ports open by default

[mdanish]

On Mon, Apr 30, 2001 at 02:25:34AM -0400, Andres Salomon wrote:
> Why would you keep something around if you don't want to run it?  Debian
> makes the (correct) assumption that if you've installed something, you
> want to run it.  If i install bind, it will assume i want it to run.  If
> i install exim, it will first configure it for me (prompting me), and
> then assume i want to run it.  Why should portmap be any different?
> The question you should be asking is, why is portmap installed by default?
> Similiarly, is there something that can be done during installation that
> asks the user if certain things (nfs) that require portmap should be
> installed.  If there's nothing that depends on portmap, then default
> to not installing portmap.  Having daemons shut off by default is
> not the way to go, however.
Actually there are some packages that depend on a mail-transport-agent,
(such as lilo->logrotate->mailx), yet one may not want to have an MTA
running on certain systems.  I suppose a dummy or minimal MTA may be
used (and may exist, I'm not aware), but this certainly highlights the
need to be able to disable daemons but still have them installed; especially
since most MTA's still have certain functionality even when not listening
on port 25.

Another common one is xdm (even though it's more than just a network daemon), 
which task-x-window-system depends on, and to remove xdm one must remove 
task-x-window-system.
> 
> 
> On Sun, Apr 29, 2001 at 10:29:58PM -0600, Dwayne C. Litzenberger wrote:
> > 
> > Why does a server automatically get run just because it's installed?  For
> > instance, portmap is installed by default whether you're using NFS or not, 
> > and
> > bnetd runs even if I just installed the package for bnchat.  Shouldn't the
> > default be to not run daemons unless they are explicitly enabled, like an
> > "exit" at the beginning of all daemon-starting init scripts that must be
> > commented out?
> > 
> > -- 
> > Dwayne C. Litzenberger - [EMAIL PROTECTED]
> 
> 
> 
> -- 
> "... being a Linux user is sort of like living in a house inhabited
> by a large family of carpenters and architects. Every morning when
> you wake up, the house is a little different. Maybe there is a new
> turret, or some walls have moved. Or perhaps someone has temporarily
> removed the floor under your bed." - Unix for Dummies, 2nd Edition
> -- found in the .sig of Rob Riggs, [EMAIL PROTECTED]
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; GPG public key available from:'finger [EMAIL PROTECTED]' ;;
;;


pgpKIPOOicAnS.pgp
Description: PGP signature

ITP: ardour -- professional multitrack audio editing tool

[ericvb]

Package: wnpp
Severity: wishlist

a "professional" multitrack multichannel audio recorder and DAW using
ALSA-supported audio interfaces. Supports up to 32-bit samples, 24+ channels at
up to 96 kHz, non-destructive, non-linear editing.

Licence is GPL.

http://ardour.sourceforge.net

-- 
Eric VAN BUGGENHAUT

[EMAIL PROTECTED]


pgpffMfGkVjlB.pgp
Description: PGP signature

Re: Many ports open by default

[Wolfgang Sourdeau]

> As always, that would be true if they weren't installed by default. The
> current method requires too much prior knowledge.

This could be put as a question whenever someone installs Debian
GNU/Linux. Something like "Do you want to enable the installed server
software by default. Beware that this might cause security problems on
your system since it is recommended to only run server programs if and
only if needed. If you do not feel confident enough with system
administration, you should answer No here."

This seems to be a reasonable thing to me.


W.

Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)

[Zack Weinberg]

reopen 95420
quit

...
> On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote:
> > 
> > ash 0.3.8-1 incorporates changes in word splitting which break common
> > shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used
> > when compiling GCC.
> > 
> > #! /bin/ash
> > OIFS=$IFS
> > IFS=,
> > set `echo fnord,a,b,c`
> > IFS=$OIFS
> > CMD="echo $@"
> > $CMD
> 
> Sorry, but this is broken.  This assumes that IFS is set to begin with
> which may not be the case.

I have consulted the Single Unix Standard and can find only dubious
justification for this assertion.  It never flat out says whether IFS
is to be set on entry to the shell or not.  However, I note this
paragraph:

# IFS
#Input field separators: a string treated as a list of characters
#that is used for field splitting and to split lines into fields
#with the read command. If IFS is not set, the shell will behave
#as if the value of IFS were the space, tab and newline
#characters. (See Field Splitting .)

I could read that as requiring that if IFS is unset, then you get
"" if you inspect its value, NOT the null string.

In any case, your change is a gratuitous divergence from the upstream
code and a deliberate breakage of consensus shell behavior.  My script
functions correctly with every Bourne-descended shell I have access to
except ash 0.3.8-1.  (In addition to bash, pdksh, and previous
versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX,
and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by
Solaris.)  Irrespective of what the standard says, you cannot
introduce changes into /bin/sh which make it behave differently from
every other shell out there.  Especially if they have the potential to
break every shell script which uses some feature.

I had hoped that you had learned your lesson from the last time you
pulled a stunt like this.  It seems I was wrong.

zw

Re: Bug#95818: libpgsql2.1: should not depend on ident-server

[Steve Langasek]

On Mon, 30 Apr 2001, Oliver Elphick wrote:

>>This works for Unix sockets under Linux 2.2 and Linux 2.4, at least.  I don't
>>know how portable the interface is beyond that, and lack of portability might
>>prevent upstream from adopting it.  It would be interesting to see this as an
>>option for Debian, though.  (Does Hurd implement SO_PEERCRED?)

> Yes; this makes it look possible - I am pretty sure it is not portable,
> though, so it won't be an upstream option.

> How portable is it within Linux?  I just tried looking for the documentation
> on it in libc.info and couldn't find anything.

I seem to recall first being tipped off to the existence of this facility in a
book on generic SysV programming, but this might just be my memory playing
tricks on me.  At the very least, it works on all Linux kernels we support in
Debian (unstable).

An earlier interface I had been using, trying to pop SCM_CREDENTIALS messages
off the socket manually, is apparently less portable, as my code started
segfaulting when run under 2.4. :)

Steve Langasek
postmodern programmer

package servers inconsistent?

[Harald Dunkel]

Hi folks,

Is it possible to keep an eye upon package consistency on the
hosts 'http.us.debian.org'?

Each time I run 'apt-get update', some of the package lists on my
machine seem to be outdated, even if the last update has been done
just a few jiffies ago. But usually the following 'apt-get ugrade' 
fails due to missing packages. 

I have to repeat this procedure several times until the upgrade can 
be completed successfully. Sometimes this doesn't work at all.
I tried to install a caching proxy, but this did not help.


Regards

Harri

Re: Bug#95818: libpgsql2.1: should not depend on ident-server

[Oliver Elphick]

Robert Bihlmeyer wrote:
  >That's not true for Linux 2.[24].x at least. One can use
  >getsockopt(..., SO_PEERCRED, ...) to get the uid of the other end.
  >
  >It would be nice if you could request that as an upstream feature.
 
The upstream developers are not friendly to non-portable features; I
might be able to get it added under a config option.

(portable means BSD Linux AIX HP-UX VAX Solaris Windows ...)

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "For whosoever will save his life shall lose it. But 
  whosoever will lose his life for my sake, the same 
  shall save it."  Luke 9:24 

Re: FWD: Popularity-contest submission doesn't go through to apenwarr-survey@klecker.debain.org

[Josip Rodin]

On Mon, Apr 30, 2001 at 05:05:20PM +0200, Christian Kurz wrote:
> > $ host -v -t MX -A debian.org
> > Query about debian.org for record types MX
> > Found 1 address for debian.org
> > Checking debian.org address 198.186.203.20
> >  !!! debian.org address 198.186.203.20 maps to klecker.debian.org
> [...]
> > So, mail to debian.org is the same as mail to klecker.debian.org 
> 
> No! This is absolutely wrong. The output just shows that the MX
> (Mail-Exchange) for the domain debian.org is klecker.debian.org.

ITYM s/domain/host/.

> Never assume from an MX output something about the mail-address and
> local-parts in a domain and/or it's subdomains.

Actually, everything would be fine had he not used -A.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: debbugs can now send bug mails to someone different than the maintainer

[Matt Zimmerman]

On Sun, Apr 29, 2001 at 10:51:45PM -0800, Ethan Benson wrote:

> On Mon, Apr 30, 2001 at 02:36:21AM -0400, Matt Zimmerman wrote:
> > 
> > Unless, of course, you can do your filtering on the mail server, as I do.
> 
> and how many isps allow this?

Some IMAP servers support server-side filtering, which would allow an ISP to
provide this service without allowing .procmailrc, etc.  Or, as someone else
pointed out in this thread, you could do the filtering on master.

-- 
 - mdz

¾Ç©f³Q....XXX...

[ªü±l]

龍哥,
今年真的不好過,[EMAIL PROTECTED]
[EMAIL PROTECTED]@家公司蠻好玩的..
[EMAIL PROTECTED]
[EMAIL PROTECTED]
按下面的連
結-

周美雲...
p.s. 星期六 Friday's 見面!!

Re: Bug#95818: libpgsql2.1: should not depend on ident-server

[Robert Bihlmeyer]

"Oliver Elphick"  writes:

> It is indeed the case that ident is needed to allow local access without
> a password.  I understand that this presents a small security risk on the
> server.

I think README.Debian or somesuch should tell why ident is necessary,
and perhaps also how one can restrict ident access (e.g. by
firewalling port 113 except for localhost).

> In case anyone should ask why the server cannot authenticate directly,
> communication between front- and back-ends is done through a Unix socket
> and therefore it is not possible for the back-end to know the identity
> of the user at the front-end.

That's not true for Linux 2.[24].x at least. One can use
getsockopt(..., SO_PEERCRED, ...) to get the uid of the other end.

It would be nice if you could request that as an upstream feature.

-- 
Robbe


signature.ng
Description: PGP signature

Re: Bug#95818: libpgsql2.1: should not depend on ident-server

[Oliver Elphick]

Steve Langasek wrote:
  >> In case anyone should ask why the server cannot authenticate directly,
  >> communication between front- and back-ends is done through a Unix socket
  >> and therefore it is not possible for the back-end to know the identity
  >> of the user at the front-end.  The only options for Unix socket access
  >> are password-protection or trust (that is, a completely open database).
  >
  >...
... [code] ...
  >
  >This works for Unix sockets under Linux 2.2 and Linux 2.4, at least.  I 
don't
  >know how portable the interface is beyond that, and lack of portability 
might
  >prevent upstream from adopting it.  It would be interesting to see this as 
an
  >option for Debian, though.  (Does Hurd implement SO_PEERCRED?)
 
Yes; this makes it look possible - I am pretty sure it is not portable,
though, so it won't be an upstream option.

How portable is it within Linux?  I just tried looking for the documentation
on it in libc.info and couldn't find anything.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "For whosoever will save his life shall lose it. But 
  whosoever will lose his life for my sake, the same 
  shall save it."  Luke 9:24 

Re: Proposing task-debian

[Matt Zimmerman]

On Sat, Apr 28, 2001 at 10:55:22PM -0400, Joey Hess wrote:

> Christian Hammers wrote:
> > Would it be good to have a package task-debian that had dependencies to such
> > "meta" packages (including the latest version of apt,debconf and dpkg) to 
> > ensure that users always get the latest Debian "maintenance"/"meta" 
> > packages 
> > if they wish so?
> 
> Er, what would you think/do if you were a new user, and saw a list of tasks
> like "Web Server", "X Desktop", and so on, and nestled in aoung them was
> one titled, inexplicably. just "Debian"?
> 
> If these tools become widly enough accepted that we think everyone
> should have them available by default, we can make them standard
> priority.

Perhaps it would be useful to create a new archive section for Debian-specific
tools.  There seem to be more written all the time, and it would be nice to be
able to easily browse a list of them.  Things like apt-zip, grep-dctrl,
deborphan, debfoster, dlocate, debsums, dpkg-dev-el, dput, and reportbug come
to mind as likely candidates for such a section.  There's no reason to make
them standard, as only a small percentage of users are likely to be be
interested in them, and a meta-package doesn't make sense as they don't
represent a group of packages that should be installed together.

-- 
 - mdz

Re: (OT) Storage (8*IDE HDs) any experiences?

[Dimitri Maziuk]

On Mon, Apr 30, 2001 at 09:01:16AM +1000, Brian May wrote:
...
> I would assume (hope!) the original poster plans to run both power
> supplies from the same central switch, in order to minimise problems
> here.

OP doesn't plan to run anything. OP informed Powers That Be of the
options and is waiting for their decision. :)
(the feeling here is that paying more and not having to deal with 
crappy peecee hardware is a much better option.)

As I mentioned before, I don't think load-sharing PSUs are a good
idea anyway. Fail-over hot-swappable PSUs, yes; load-sharing -- no.

Dima
-- 
E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home)
http://www.bmrb.wisc.edu/descript/gpgkey.dmaziuk.ascii -- GnuPG 1.0.4 public key
We're sysadmins. Sanity happens to other people. -- Chris King in asr

Re: FWD: Popularity-contest submission doesn't go through to apenwarr-survey@klecker.debain.org

[Christian Kurz]

On 01-04-30 Matthijs Melchior wrote:
> Christian Kurz wrote:
> > On 01-04-29 Joey Hess wrote:
> > > Anyone have a clue?

> > > Received: from myhostname.my.isp.com ([EMAIL PROTECTED] [127.0.0.1])
> > >   by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with
> > > +ESMTP id f3QDlYZ2018784
> > > for <[EMAIL PROTECTED]>; Thu, 26 Apr 2001 07:47:34
> > > +-0600

> > Suddenly here the email is address to [EMAIL PROTECTED]
> > while in the previous line:

> > > Received: (from [EMAIL PROTECTED])
> > >   by myhostname.my.isp.com (8.12.0.Beta7/8.12.0.Beta7/Debian
> > > +8.12.0.Beta7-1) id f3QDkJuS015600
> > >   for [EMAIL PROTECTED]; Thu, 26 Apr 2001 07:46:19 -0600

> > Here it's addressed to [EMAIL PROTECTED] So I would assume
> > that something on myhostname.my.isp.com is rewriting the email
> > @debian.org to @klecker.debian.org. And I don't think that this
> > localpart apenwarr-survey is available in the sub-domain
> > klecker.debian.org but instead in the domain debian.org. So I would
> > suggest that the configuration of this mail-server myhostname.my.isp.com
> > will be checked to see why suddenly the rcpt-to changes.

> 

>   Please look at the following:

> $ host -v -t MX -A debian.org
> Query about debian.org for record types MX
> Found 1 address for debian.org
> Checking debian.org address 198.186.203.20
>  !!! debian.org address 198.186.203.20 maps to klecker.debian.org
> $ host -v -A http.us.debian.org
[...]
> So, mail to debian.org is the same as mail to klecker.debian.org 

No! This is absolutely wrong. The output just shows that the MX
(Mail-Exchange) for the domain debian.org is klecker.debian.org. This
has absolutely nothing to do with the email-address under the domain
@debian.org. Never assume from an MX output something about the
mail-address and local-parts in a domain and/or it's subdomains.

Christian
-- 
   Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgpCoX7U7Qe36.pgp
Description: PGP signature

¾Ç©f³Q§Ú"©ì"¤F

[ªüÀs]

龍哥,
今年真的不好過,[EMAIL PROTECTED]
[EMAIL PROTECTED]@家公司蠻好玩的..
[EMAIL PROTECTED]
[EMAIL PROTECTED]
按下面的連
結-

隆隆.
p.s. 星期六 Friday's 見面!!

Re: libdb3.so and libdb-3.so

[Ben Collins]

On Tue, May 01, 2001 at 12:27:38AM +0900, GOTO Masanori wrote:
> At Mon, 30 Apr 2001 10:59:24 -0400,
> Ben Collins wrote:
> > > I cannot find out why `libdb-3' is used and spreaded over the gnome
> > > packages. Naming soname is sensitive issue, IMHO.
> > 
> > As I said the *upstream* soname is libdb-3.so, and Debian's soname is
> > libdb3.so.3. The former is not very conformant to soname schemes, the
> > latter is. Gnome can use whatever it wants to link with it, but the
> > soname is still libdb3.so.3.
> 
> Thanks for your explanation, Ben. I understand.
> 
> In addition, I insist that all gnome developer should use
> `libdb3' instead of `libdb-3'. Yes, there is no problem in
> binary's soname compatibility, but db-3 is not appropriate name,
> the reason is said above by Ben.

No, it is perfectly fine for them to use -ldb-3, since the soname will
still be libdb3.so.3. The link does not affect the soname, since it is
hardcoded in the library no matter what they use to link to it.

Ben

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

Re: kernel-{image,headers} package bloat

[james]

On Mon, Apr 30, 2001 at 12:41:22PM +0200, Torsten Landschoff wrote:
> This is the point where I disagree. I really hate having to build my
> own kernel just to do some tests with a fresh installation. I think
> the standard kernel should support SMP. I don't know if it causes
> any problems with UP machines though...

Unfortunately it seems that a kernel that supports both i386 and SMP
would have to use very slow methods for locking since instructions
allowing faster locking only came in with the 486 and above.

Maybe there really ought to be exactly two kernels:

  1) Uniprocessor kernel compiled for i386 (kernel-image-foo)
  2) SMP kernel compiled for a suitable least common denominator of
 95+% of SMP boards out there but using newer instructions for
 decent locking performance.  Might not run on older UP boards
 or maybe a few really ancient SMP boards.

The UP kernel would be used in the installer, but maybe the SMP
version could be installed automatically on systems that support it.

This would allow virtually everyone to get a kernel on their machine
that would run at least very good (not perfect) performance while
keeping the archive even less bloated than the old 'flavors' system.

-- 
James Deikun, Techie(tm), CSI Multimedia
The opinions expressed &c.

Re: Gnome bug 94684

[Christian Marillat]

 "JB" == Jules Bean <[EMAIL PROTECTED]> writes:

[...]

>> Ha, somebody understand me :)

JB> In which case, it's perfectly reasonable to just leave the bug open
JB> and not fix it.  But don't close it.  And do forward it upstream.

Already done.

Christian

Re: Many ports open by default

[Warren A. Layton]

On Tue, May 01, 2001 at 12:28:49AM +1000, Craig Sanders wrote:

> 1. ssh and sshd should be split into separate packages.  if it bothers you
> enough, file a bug report.  i'm happy with the way it is.
> 
> or
> 
> 2. the handful of people who want the ssh client but not the ssh daemon
> can learn how to edit /etc/init.d/ssh

It has been pointed out that ssh actually handles this correctly with
debconf, giving users the choice. I was just trying to use it as an
example but it seems that everything has already been taken care of.

Warren

-- 
Warren A. Layton
http://www.netwinder.org/~zeevon
GPG Fingerprint: F54C 019D 18BE 6ED8 678D  39D0 21FD D515 BFB8 80A3 


pgp8YNaRYZODm.pgp
Description: PGP signature

Re: libdb3.so and libdb-3.so

[GOTO Masanori]

At Mon, 30 Apr 2001 10:59:24 -0400,
Ben Collins wrote:
> > I cannot find out why `libdb-3' is used and spreaded over the gnome
> > packages. Naming soname is sensitive issue, IMHO.
> 
> As I said the *upstream* soname is libdb-3.so, and Debian's soname is
> libdb3.so.3. The former is not very conformant to soname schemes, the
> latter is. Gnome can use whatever it wants to link with it, but the
> soname is still libdb3.so.3.

Thanks for your explanation, Ben. I understand.

In addition, I insist that all gnome developer should use
`libdb3' instead of `libdb-3'. Yes, there is no problem in
binary's soname compatibility, but db-3 is not appropriate name,
the reason is said above by Ben.

Regards,
-- GOTO Masanori

Re: libdb3.so and libdb-3.so

[Christian Marillat]

 "GM" == GOTO Masanori <[EMAIL PROTECTED]> writes:

It is possible to stop all Cc ?

Christian

Re: Bug#95818: libpgsql2.1: should not depend on ident-server

[Steve Langasek]

On Mon, 30 Apr 2001, Oliver Elphick wrote:

> Robert Bihlmeyer wrote:
>   >Package: libpgsql2.1
>   >Version: 7.1release-2
>   >Severity: normal

>   >identds are considered mild privacy/security risks, therefore I don't
>   >think libpgsql2.1 and postgresql-client[1] should depend on
>   >ident-server.

>   >The main use seems to be to allow local connections without further
>   >authentication. A noble goal that should be reached via local
>   >transport instead.

>   >Maybe there's more reasoning why this dependency is necessary. In this
>   >case, please put it in the documentation.

> It is indeed the case that ident is needed to allow local access without
> a password.  I understand that this presents a small security risk on the
> server.  However, without it, it is necessary for the postgres
> administrator's database password to be held in clear in some file, so that
> the automatic clean-up processes will be able to operate.

> It seems to me that the obvious security risks of the latter process
> outweigh the minor risks of having ident available.  However, it is only
> strictly necessary for the server to have ident available, so I propose to
> move the dependency from libpgsql2.1 (and postgresql-client) to postgresql
> itself.

> In case anyone should ask why the server cannot authenticate directly,
> communication between front- and back-ends is done through a Unix socket
> and therefore it is not possible for the back-end to know the identity
> of the user at the front-end.  The only options for Unix socket access
> are password-protection or trust (that is, a completely open database).

...

#include 

struct ucred peercred;
int so_len = sizeof(peercred);

retval = getsockopt(sock, SOL_SOCKET, SO_PEERCRED, &peercred, &so_len);
if (retval != 0 || so_len != sizeof(peercred)) {
/* We didn't get a valid credentials struct.
   Close socket and continue. */
close(sock);
continue;
}

if (peercred.uid != ...) {

}



This works for Unix sockets under Linux 2.2 and Linux 2.4, at least.  I don't
know how portable the interface is beyond that, and lack of portability might
prevent upstream from adopting it.  It would be interesting to see this as an
option for Debian, though.  (Does Hurd implement SO_PEERCRED?)

Steve Langasek
postmodern programmer

Re: Proposing task-debian

[John Hasler]

Anthony Towns writes:
> ...what would people think of making a task-emacs and moving both tetex
> and emacs out from standard?

As an emacs user I think this is an excellent idea, but I worry that
such stretching of the definition of "task" may confuse users.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: Many ports open by default

[Michael Stone]

On Tue, May 01, 2001 at 12:22:47AM +1000, Craig Sanders wrote:
> On Sun, Apr 29, 2001 at 10:29:58PM -0600, Dwayne C. Litzenberger wrote:
> > Why does a server automatically get run just because it's installed?
> 
> because if you didn't want it to run, you wouldn't have installed it.

As always, that would be true if they weren't installed by default. The
current method requires too much prior knowledge.

-- 
Mike Stone

Re: Gnome bug 94684

[Jules Bean]

On Fri, Apr 27, 2001 at 07:04:52PM +0200, Christian Marillat wrote:
>  "CW" == Colin Walters <[EMAIL PROTECTED]> writes:
> 
> CW> Jules Bean <[EMAIL PROTECTED]> writes:
> >> Programs shouldn't gratuitously break configurations which worked.
> >> When woody is released, and people upgrade en masse to it, they will
> >> want their configurations to carry on working.
> 
> CW> In my experience, GNOME has had this problem since version 1.0; almost
> CW> every time I've upgraded, something has broken.  Most of the time I've
> CW> just given up and nuked ~/.gnome and ~/.gnome-private, and then
> CW> recreated my desktop configuration.
> 
> CW> It doesn't seem very reasonable to expect the Debian packagers to try
> CW> to fix upstream bugs like this.
> 
> Ha, somebody understand me :)

In which case, it's perfectly reasonable to just leave the bug open
and not fix it.  But don't close it.  And do forward it upstream.

Jules

Re: libdb3.so and libdb-3.so

[Ben Collins]

On Mon, Apr 30, 2001 at 11:51:55PM +0900, GOTO Masanori wrote:
> 
> I cannot find out why `libdb-3' is used and spreaded over the gnome
> packages. Naming soname is sensitive issue, IMHO.
> 

As I said the *upstream* soname is libdb-3.so, and Debian's soname is
libdb3.so.3. The former is not very conformant to soname schemes, the
latter is. Gnome can use whatever it wants to link with it, but the
soname is still libdb3.so.3.

Ben

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

Re: libdb3.so and libdb-3.so

[GOTO Masanori]

At Mon, 30 Apr 2001 10:04:48 -0400,
Ben Collins wrote:
> > I wonder why libdb3 package includes 
> > /usr/lib/libdb3.so.3.0.2 ,
> > /usr/lib/libdb-3.so ,
> > however libdb3-dev package includes
> > /usr/lib/libdb3.so .
> 
> That .so is not a link name. It is only there so that things compiled
> against the upstream soname will work.

Ah, sorry. `link name' is not proper expression.
`soname' is proper :-)

I saw the Debian db3 source package, and found in debian/rules:
# Symlinks for non-Debian db3 compiled apps
ln -sf libdb3.so.3.0.2 debian/tmp/usr/lib/libdb-3.so
ln -sf libdb3_cxx.so.3.0.2 debian/tmp/usr/lib/libdb_cxx-3.so
Ben, why did you decide making links for libdb-3 ?

Currently some gnome package have `-ldb-3' entries as compile options.
For example, /usr/bin/gnome-config in libgnome-dev has some such
`-ldb-3' fields. If the soname of `libdb-3' is decided for only gnome,
should it be all changed to `libdb3'... ?

I cannot find out why `libdb-3' is used and spreaded over the gnome
packages. Naming soname is sensitive issue, IMHO.

Regards,
-- GOTO Masanori

Re: X-Medium in /var/lib/dpkg/available

[Wichert Akkerman]

Previously Nils Rennebarth wrote:
> Short problem description:
> dpkg complains about wrong syntax in /var/lib/dpkg/available, and in
> fact there are a lot of package descriptions where the last line
> read something like (from memory)

Already fixed in dpkg 1.9.1, which will hit the mirroors in about 5
hours.

Wichert.


-- 
   
 / Generally uninteresting signature - ignore at your convenience  \
| [EMAIL PROTECTED]  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: Many ports open by default

[Frederico Muñoz]

Warren A. Layton wrote:
On Mon, Apr 30, 2001 at 02:25:34AM -0400, Andres Salomon wrote:
Why would you keep something around if you don't want to run it?  Debian
makes the (correct) assumption that if you've installed something, you
want to run it.  If i install bind, it will assume i want it to run. 

Well, not everyone that installs ssh wants to run the server (some may just
want to use the client to connect to other machines). This is just one
example; I'm sure that there are many more.
There could be, but in the specific case of ssh, and IIRC, debiconf asks 
if you wan't to run the server or not;
I even think that the default field selected is 'No'. Of course, if you 
say 'Yes' then the server will run and the port
will open.

My 2 cents,
Regards,
fsm
--
Frederico Muñoz
[EMAIL PROTECTED]

Re: postgresql and libssl - Bug#95146

[PiotR]

On Sun, Apr 29, 2001 at 09:13:49PM +0100, Oliver Elphick wrote:
> I have to reiterate a query about what to do with postgresql in view of its
> now being linked with libssl.
> 
> Since this question is currently being referred to legal advice, do you
> want me to move postgresql into non-us, which will force any packages
> depending on it into non-us too, or should I leave it alone pending
> resolution of the legal question?
> 
> (I do not propose to do anything to remove the ssl code from PostgreSQL.)
> 
> -- 
> Oliver Elphick[EMAIL PROTECTED]
> Isle of Wight  http://www.lfix.co.uk/oliver
> PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
> GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
>  
>  "And he said to them all, If any man will come after 
>   me, let him deny himself, and take up his cross daily,
>   and follow me."  Luke 9:23 
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
When I connect to ftp.kernel.org I see this:

"Due to U.S. Exports Regulations, all cryptographic software on this
 site is subject to the following legal notice:

 This site includes publicly available encryption source code
 which, together with object code resulting from the compiling of
 publicly available source code, may be exported from the United
 States under License Exception "TSU" pursuant to 15 C.F.R. Section
 740.13(e).

 This legal notice applies to cryptographic software only.  Please see
 the Bureau of Export Administration (http://www.bxa.doc.gov/) for more
 information about current U.S. regulations."

Does that mean that there is no need for debian non-US anymore?

-- 
Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr/
[EMAIL PROTECTED]

Re: Many ports open by default

[Craig Sanders]

On Mon, Apr 30, 2001 at 07:37:21AM -0500, Warren A. Layton wrote:
> Well, not everyone that installs ssh wants to run the server (some may
> just want to use the client to connect to other machines). This is
> just one example; I'm sure that there are many more.

that means either:

1. ssh and sshd should be split into separate packages.  if it bothers you
enough, file a bug report.  i'm happy with the way it is.

or

2. the handful of people who want the ssh client but not the ssh daemon
can learn how to edit /etc/init.d/ssh

craig


--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: Many ports open by default

[Craig Sanders]

On Mon, Apr 30, 2001 at 02:25:34AM -0400, Andres Salomon wrote:

> If there's nothing that depends on portmap, then default to not
> installing portmap.

speaking of portmap, debian's portmap is not an insecure thing to run by
default because it is compiled with tcp-wrappers support and rejects all
non-localhost connections that aren't explicitly allowed (by ip address)
in /etc/hosts.allow

> Having daemons shut off by default is not the way to go, however.

yep.


craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: Many ports open by default

[Craig Sanders]

On Sun, Apr 29, 2001 at 10:29:58PM -0600, Dwayne C. Litzenberger wrote:
> I suspect it's already been discussed before, so I'll ask instead of
> flaming.  (See!  I can learn!)

many times before.

> Why does a server automatically get run just because it's installed?

because if you didn't want it to run, you wouldn't have installed it.

if you want to install it but not run it, then edit the startup script.

simple.

> Shouldn't the default be to not run daemons unless they are explicitly
> enabled, [...]

no, users shouldn't install daemon packages if they don't want the
daemon to run - or they should learn how to edit the startup scripts (or
inetd.conf) if they want non-standard behaviour.

craig


--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: kernel-{image,headers} package bloat

[Craig Sanders]

On Mon, Apr 30, 2001 at 12:41:22PM +0200, Torsten Landschoff wrote:
> On Mon, Apr 30, 2001 at 05:19:12PM +1000, Craig Sanders wrote:
> > anyone running SMP ought to have enough of a clue to compile their
> > own kernel.
>
> This is the point where I disagree. I really hate having to build my
> own kernel just to do some tests with a fresh installation.

so you have spent good money on a high-end SMP machine but you're not
willing to put in 5(*) minutes work (running "make config" or menuconfig or
xconfig) to build a kernel which is optimised for your hardware.

strange.

IMO, it's even stranger when you consider that it's 5 minutes work only
for the first time that you compile a kernel for that machine (or type
of machine if you have a bunch of similar or identical machines). after
that, it's less work because you can re-use the old .config file and
just run "make oldconfig" to handle any new compile-time options.



(*) i'm not including the 3-15 minutes (depending on CPU and disk speed
and memory) it takes to actually compile the kernel because that can run
in the background - it's not work, it's just waiting (or getting on with
something else while it's compiling)

craig

--
craig sanders <[EMAIL PROTECTED]>

  GnuPG Key: 1024D/CD5626F0 
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57  52C3 EC32 6810 CD56 26F0

Re: (OT) Storage (8*IDE HDs) any experiences?

[PiotR]

On Sun, Apr 29, 2001 at 10:14:35AM +0200, Russell Coker wrote:
> On Sunday 29 April 2001 06:48, Brandon High wrote:
> > On Sat, Apr 28, 2001 at 11:50:26PM +0200, Andreas Bombe wrote:
> > > The IBM SCSI disk I have here has a jumper to delay spin up depending on
> > > SCSI ID so that an array of those would spin up sequentially if they all
> > > had those jumper set (and different IDs, which they need anyway).  Maybe
> > > there are IDE drives built with RAIDs in mind offering some similar
> > > option?
> >
> > I doubt it, but with a sufficiently large case (or small power supply) it
> > may be possible to stick a 2nd (or 3rd) power supply in. Drives could be
> > plugged into the second PS while the MB is powered off of the primary PS.
> 
> That sounds like a really bad idea to me.
> 
> In a regular setup the IDE controller and the drive get power from the same 
> source.  So if the signals on the cable have more current going one way than 
> the other then the difference will be made up on the 0V line on the PSU.  If 
> you have separate PSU's then the difference will go through other lines of 
> the data cable.  This is something that is likely to be fatal to drives and 
> motherboards.
> 
> But if you try it please let me know how it works.  ;)

A good solution for this might be to connect the first PS's output to the
other, so the voltage is the same, and there's no massive current flow across
the data cables. 

Anyone desagrees to this?
-- 
Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr/
[EMAIL PROTECTED]

Re: Proposing task-debian

[Anthony Towns]

On Mon, Apr 30, 2001 at 08:34:04AM -0400, Sam Hartman wrote:
> > "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
> In the new universe (debbootstrap, tasksel, etc) where a user might
> never run dselect, what makes sure that in the default configuration,
> standard priority packages get installed?  

They'll choose to select tasks, and "tasksel -ris" will presumably be run
for them, which'll install all required, important and standard packages.
This wasn't the case in potato originally, but I think that's been/going to
be changed.

> [I'm not interested in a flamewar about whether emacs20 should be
>  standard; currently it is.]

tetex and emacs are the packages that people usually want out of standard;
tetex already has its own task (task-tex), what would people think of
making a task-emacs and moving both tetex and emacs out from standard?

Cheers,
aj (alternately, we could expand tasksel so that it'd take note of a
religion-emacs metapackage...)

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

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpUmloiWWggo.pgp
Description: PGP signature