Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[exa]

On Sat, Jan 06, 2001 at 11:03:57PM -0600, Steve Langasek wrote:
> The display manager
> starts the X server, not the other way around, which means that the X server
> has no control over the display manager's behavior; and the authentication
> failure you reported came from the display manager and PAM, /not/ from the X
> server.
>

Hmm. Well, I know about that. The display managers start all right. The
problem occurs when I login. I'd tried xdm, wings and gdm. How come all
of them failed then?

> Is it possible you missed a debconf question that controls authentication for
> display managers when you upgraded?  Yes, but it certainly wasn't in the X
> packages.

?? I'm not sure, but when I downgraded to the version in sid, everything got
back to normal.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Obsolete software in /usr/local

[Greg Stark]

Ben Armstrong <[EMAIL PROTECTED]> writes:

> On Sat, Jan 06, 2001 at 03:49:07PM -0500, Greg Stark wrote:
> > I've been meaning to bring this up for a while: 
> > Why on earth was this change ever made?
> 
> I can't speak for whoever made the change, but I suspect that it is
> because LD_LIBRARY_PATH can be used to support libraries in /usr/local/lib
> for programs in /usr/local/bin without messing up anything that ships with
> Debian.  

There's no difference between having /usr/local/lib in LD_LIBRARY_PATH and
just adding it at the end of /etc/ld.so.conf except for:

1) It won't be cached so it'll be slightly slower
2) setuid binaries will break
3) Each user manually has to add it

This violates the more general principle in the debian policy that no
environment variables should have to be set for things to work right. Of
course there's no specific package that doesn't "work right" since this only
affects locally installed software. So it doesn't violate the specific meaning
of that requirement, but it definitely breaks with the model.

-- 
greg

Bug#81396: root shell fscked after upgrade to woody

[Adam Conrad]

Hate to state the obvious, but on a DEFAULT Debian install, if nothing is
changed, root's default path with be dictated by /root/.profile ... Maybe
the machine behaving fine still has this file, and the other has had it
deleted, and then (and only then) is login/whatever providing you with a
default user env...

... Adam Conrad

-Original Message-
From: Eray Ozkural (exa) [mailto:[EMAIL PROTECTED] Behalf Of
Eray Ozkural (exa)
Sent: Saturday, January 06, 2001 9:46 PM
To: Aaron Lehmann
Cc: Eray Ozkural (exa); [EMAIL PROTECTED];
debian-devel@lists.debian.org
Subject: Bug#81396: root shell fscked after upgrade to woody


On Sat, Jan 06, 2001 at 08:25:54PM -0800, Aaron Lehmann wrote:
> Debian has always exhibited this behavior for me. There's a simple
> workaround: don't log in as root.
>
> I don't know which is more distasteful: That you have telnet enabled, or
> that you have enabled remote root logins via telnet.
>

I was surprised to find that I'd enabled remote root logins via telnet, too.
he he. I'll close it after projects are over...

About having telnet enabled: everybody on the campus knows how to use telnet
but would be very surprised I didn't let them connect easily from windows
clients. For me, using telnet is of course a bit insecure but when I'm
not able to use an ssh client... it's easier.


> Interesting, RedHat 5.1 (and up?) exhibits exactly the opposite
> phenomenon. Log in as root and you get the right paths. su without '-'
> and you don't.

Hmmm. This is most probably directly related to login program. :/

Now, the interesting thing is this happens only on machines which have
upgraded, and sometimes it won't happen even on upgraded ones. ?

For instance, this machine is on woody latest, and it doesn't have the
bug. I login as root from console, and I get all the sbin paths here.
On borg, the bug occurs as you say, I login as root and I'm in like
a normal user. I have to do a 'su' to get things right.

What might be the reason for this?

--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

Bug#81396: root shell fscked after upgrade to woody

[exa]

Hi Adam,

On Sat, Jan 06, 2001 at 10:55:32PM -0700, Adam Conrad wrote:
> Hate to state the obvious, but on a DEFAULT Debian install, if nothing is
> changed, root's default path with be dictated by /root/.profile ... Maybe
> the machine behaving fine still has this file, and the other has had it
> deleted, and then (and only then) is login/whatever providing you with a
> default user env...

Thanks for the suggestion. That's it. Please close the bug. That file has
somehow gone and replacing it will solve the problem.

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Bug#81396: root shell fscked after upgrade to woody

[exa]

On Sun, Jan 07, 2001 at 04:36:09PM +1100, Craig Sanders wrote:
> why not?
> 
> the most you'd have to do is put up a single web page with links to
> local copies of ssh clients for various platforms...and optionally
> replace telnetd with a script (or tcp-wrapper's "twist" capability)
> which printed a message displaying the URL and advising the user to
> install an ssh client. telnet problem solved with a minimum of user
> support calls.
> 
> there's really no excuse for running (non-ssl) telnetd any more. good
> free ssh clients are available for just about every operating system.

In fact, I was preparing an RFC for suggesting that ssh ports should be opened
on the firewall and ssh clients and servers should be installed on machines
throughout the network. That Java ssh client would also be cool to put
on a web page.

It isn't smart to transmit cleartext passwords while the network is full
of people snooping packets.

Thanks for the idea,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: tar -I incompatibility

[Michael Stone]

On Sun, Jan 07, 2001 at 04:25:43AM +0100, Marcus Brinkmann wrote:
> On Sun, Jan 07, 2001 at 03:28:46AM +0100, Goswin Brederlow wrote:
> > "tar -xIvvf file.tar.bz2" has been in use under linux for over a year
> > by pretty much everybody. Even if the author never released it as
> > stable, all linux distributions did it. I think that should count
> > something.
> 
> It tells a lot about the people making the distributions at least.

Before making such snide comments, take a look at the changelog.Debian
entries relating to the switch from 1.13 to 1.13.x.

-- 
Mike Stone

can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Nathan E Norman]

On Sun, Jan 07, 2001 at 08:29:03AM +0200, Eray Ozkural wrote:
> On Sat, Jan 06, 2001 at 10:55:32PM -0700, Adam Conrad wrote:
> > Hate to state the obvious, but on a DEFAULT Debian install, if nothing is
> > changed, root's default path with be dictated by /root/.profile ... Maybe
> > the machine behaving fine still has this file, and the other has had it
> > deleted, and then (and only then) is login/whatever providing you with a
> > default user env...
> 
> Thanks for the suggestion. That's it. Please close the bug. That file has
> somehow gone and replacing it will solve the problem.

I apologize for prolonging this thread - it's quite annoying.
However, after reading this enlightened response I wonder if it's
possible for a user to close the (silly) bug he or she reported after
he or she solves the problem.  bugs.debian.org doesn't seem to
indicate a way for a bug to be closed other than action by the
maintainer.

Thanks,

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Inc. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgprvAzkUGnZ9.pgp
Description: PGP signature

Bug#81396: root shell fscked after upgrade to woody

[Nathan E Norman]

On Sun, Jan 07, 2001 at 04:38:10AM +0200, Eray Ozkural (exa) wrote:
> Hi Matt!!
> 
> I don't report a bug due to misconfiguration. Let's see if what you
> see applies, though.
[ snip rude and silly reply ]

[ time passes ]

On Sun, Jan 07, 2001 at 08:29:03AM +0200, Eray Ozkural wrote:
> Hi Adam,
> 
> On Sat, Jan 06, 2001 at 10:55:32PM -0700, Adam Conrad wrote:
> > Hate to state the obvious, but on a DEFAULT Debian install, if nothing is
> > changed, root's default path with be dictated by /root/.profile ... Maybe
> > the machine behaving fine still has this file, and the other has had it
> > deleted, and then (and only then) is login/whatever providing you with a
> > default user env...
> 
> Thanks for the suggestion. That's it. Please close the bug. That file has
> somehow gone and replacing it will solve the problem.

Golly, there _was_ a misconfiguration.  Now that you've made your
disdain for Branden's sharp tongue well known, I hope you plan to
apologize to Matt Zimmerman for your rudeness.

Have a super-nice day,

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Inc. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpEyeKHQZVuo.pgp
Description: PGP signature

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Jason Henry Parker]

Eray Ozkural (exa) <[EMAIL PROTECTED]> writes:

> On Sat, Jan 06, 2001 at 11:03:57PM -0600, Steve Langasek wrote:
> > The display manager
> > starts the X server, not the other way around, which means that the X server
> > has no control over the display manager's behavior; and the authentication
> > failure you reported came from the display manager and PAM, /not/ from the X
> > server.
> Hmm. Well, I know about that. The display managers start all right. The
> problem occurs when I login. I'd tried xdm, wings and gdm. How come all
> of them failed then?

Why does that mean the problem is with the X server?

jason
-- 
``Banks *are* bastards.'' -- John Laws

Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Gordon Sadler]

On Sun, Jan 07, 2001 at 01:14:40AM -0600, Nathan E Norman wrote:
> I apologize for prolonging this thread - it's quite annoying.
> However, after reading this enlightened response I wonder if it's
> possible for a user to close the (silly) bug he or she reported after
> he or she solves the problem.  bugs.debian.org doesn't seem to
> indicate a way for a bug to be closed other than action by the
> maintainer.

Actually under /usr/doc/debian the doc-debian package provides a number
of files, including bug-main-mailcontrol.txt.

A message to [EMAIL PROTECTED] of this format:

close $(bugnumber)
thanks

will close a bug. Only submitters or maintainers should close a bug as
noted in the docs.

Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Gordon Sadler]

On Sun, Jan 07, 2001 at 01:57:11AM -0600, Gordon Sadler wrote:
> Actually under /usr/doc/debian the doc-debian package provides a number
> of files, including bug-main-mailcontrol.txt.
> 
> A message to [EMAIL PROTECTED] of this format:
> 
> close $(bugnumber)
> thanks
> 
> will close a bug. Only submitters or maintainers should close a bug as
> noted in the docs.
Ugh late night.

s;/usr/doc;/usr/share/doc
s/bug-main-mailcontrol.txt/bug-maint-mailcontrol.txt

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[exa]

On Sun, Jan 07, 2001 at 05:43:52PM +1000, Jason Henry Parker wrote:
> Eray Ozkural (exa) <[EMAIL PROTECTED]> writes:
> 
> > Hmm. Well, I know about that. The display managers start all right. The
> > problem occurs when I login. I'd tried xdm, wings and gdm. How come all
> > of them failed then?
> 
> Why does that mean the problem is with the X server?
> 

Okay. Since I've downgraded X now and the behavior has gone, I'd think it
was due to some component in X. May not be the server of course.

If the same problem recurs, I will report it. Until then, I close it because
I don't think it's a problem with gdm. I use the same gdm and users can login 
now.

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Processed: Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> close 81396
Bug#81396: root shell fscked after upgrade to woody
Bug closed, send any further explanations to "Eray 'exa' Ozkural" <[EMAIL 
PROTECTED]>

> thanks,
Stopping processing here.

Please contact me if you need assistance.

Darren Benham
(administrator, Debian Bugs database)

Re: How to report bugs (was glibc thing)

[Eray Ozkural \(exa\)]

Greg Stark wrote:
> Just writing in your conclusions is useless 90% of the time. Your conclusions
> may be right but the maintainer doesn't have ESP and can't necessarily deduce
> where they came from and what the bug is.

I will try to assemble a test case as soon as I have some time. It's
been a long time, but I hope I will be able to replicate the bug.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: lilo.conf

[Russell Coker]

On Sunday 07 January 2001 05:50, Manoj Srivastava wrote:
> Hi,
>
> >>"Russell" == Russell Coker <[EMAIL PROTECTED]> writes:
>
>  Russell> other=/dev/ide/host0/bus0/target0/lun0/part1
>  Russell> label=part1
>  Russell> table=/dev/ide/host0/bus0/target0/lun0/disc
>
>   Eh? I have an SCSI only machine which does not do devfs. Does
>  the postinst handle that?

It should.  But not having a machine with SCSI disks I haven't been able to 
properly test.  It fails on LVM (haven't had a chance to write the relevant 
code) but works well with /dev/md and IDE disks (both devfs and non-devfs).

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

Re: lilo.conf

[Russell Coker]

On Saturday 06 January 2001 23:33, Peter Makholm wrote:
> Russell Coker <[EMAIL PROTECTED]> writes:
> > boot=/dev/ide/host0/bus0/target0/lun0/disc
> > root=/dev/ide/host0/bus0/target0/lun0/part3
>
> Don't assume devfs! A lot of us uses it, but before our standard
> kernel uses it our lilo package shouldn't assume it unless it is very
> sure that it will work.

The root= entry is derived from /etc/fstab .  The boot= entry is derived from 
the root= entry in a fashion that has been exhaustingly discussed on this 
list already.  It works equally well with devfs and with non-devfs.

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

Re: lilo.conf

[Russell Coker]

On Saturday 06 January 2001 23:04, Lars Wirzenius wrote:
> Russell Coker <[EMAIL PROTECTED]>:
> > I am working on the Debian package of lilo and am writing code for
> > auto-generating lilo.conf files.
>
> Presumably, if there is a /etc/lilo.conf file already on the system, you
> will ask whether to keep that as it is or whether to create a new one?
> (I'd like confirmation about this, in light of the other lilo related
> thread.)

The latest package is supposed to ask you whether you want to generate a new 
lilo.conf or keep the manually created one (default keep the manual one).  If 
you select to keep the manual one and you have no lilo.conf file then it'll 
create one anyway, but after that it won't touch it.
If you run "liloconfig -f" then you can create a new lilo.conf even though 
you've setup debconf to not overwrite old files.  Liloconfig also takes a 
parameter for an alternate name for lilo.conf (so you can create 
/tmp/lilo.conf to see what it would do).

I have had a report that my new package does not behave properly WRT the
"Manually edit lilo.conf" option.  I have been unable to reproduce this on 
the 6 machines (with different configurations) that I have access to.  I am 
still looking into this.

The latest package is on http://www.coker.com.au/lilo/ .  If you can help me 
track down this last problem then I would really appreciate it!

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

XFree4.0.2 / wdm interaction bug?

[William Lee Irwin III]

I've experienced a bug and I'm not entirely sure what to file it against.
I'm also not sure if anyone else has ever seen this, and was hoping
someone else might try such a setup and verify the bug exists before
really reporting it.

I set up wdm to run X on multiple vt's thusly in /etc/X11/wdm/Xservers:

:0 local /usr/X11R6/bin/XFree86 :0 vt7
:1 local /usr/X11R6/bin/XFree86 :1 vt8
...

A similar sort of thing can be done with gdm (and I've seen it fail
under X3 + gdm). This is XFree4.0.2 + TNT2 + wdm 1.19-4.1.

The effect I was trying to achieve was being able to switch between vt's
to different wdm/gdm login sessions, served up by different X servers.

What I actually saw was that after I switched vt's a couple of times,
screen corruption occurred. The images from the two Xservers running on
different vt's were overlaid. In the XFree3 + I128 + gdm instance, the
screen gets blanked and one of the XFree3 servers spins hard.

If anyone can verify these or help clarify what I should file the bugs
against, I would be much obliged.


Thanks,
Bill


pgpXmc5xYoChY.pgp
Description: PGP signature

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Martin Bialasinski]

* "Eray Ozkural (exa)" <[EMAIL PROTECTED]>

> Users here are not at all interested in the psychological state of a
> particular developer. On the contrary, every developer should be
> required to deal with every bug report in an objective manner.

> Inappropriate dismissal or incorrect evaluation of bug reports could
> be dealt with if bug reports were subject to peer review. I think
> that review by wider audience may be instrumental in that...

Let me tell you frankly:

You behaviour wrt bugs is more than lacking. You report something,
without making a report that has enough relevant info to deal with it
(read <[EMAIL PROTECTED]> again and understand it). When
asked about specific info, you take it as an attack on your
personality and spam debian-devel. Then you don't even give all the
answers you were asked to give.

Your behaviour on this bugreport is a deja-vu of your behaviour on
#80544.

You are more than annoying, and I am sick of it.

If you want your glory peer review, subscribe to debian-bugs-dist and
read every mail the BTS sends. I am sure your excelent bug analysis
skills are greatly appreciated.

But leave debian-devel out of this.

Martin

Optimisations query

[Michel Alexandre Salim]

Hello,

I was just thinking about one thread of discussion that happens quite
some time ago on having optimised Debian packages, which resulted in the
conclusion that it

1. not enough speed benefit
2. uses up too much bandwith

However Red Hat seems to have solved the same problem with RH 7.0 -
despite whatever else that release is. They do this by compiling to a
target CPU of i686 but keeping the target platform to i386. Not too
ideal for AMD users I suppose (I have one Intel and one AMD box myself)
but better than nothing?

This comes to mind when thinking about some assertions I've seen made
that glibc 2.2 only works on i486 and better on Intels. If so, all the
better - since Woody will be based on it why not compile all to a target
CPU of i686 and target platform of i486?

The 2 cents of a Debian user.

Regards,

Michel Salim
PS Please include my address in your reply - not subscribed to DDML

-- 
A classic is something that everyone wants to have read
and nobody wants to read.
-- Mark Twain, "The Disappearance of Literature"

Re: update excuses.. how to read them

[Paul Slootman]

On Sun 07 Jan 2001, Anthony Towns wrote:
> On Sun, Jan 07, 2001 at 01:05:57AM +0100, Paul Slootman wrote:

> > jed-sl-ja is not built anymore (note that it is "out of date" on
> > ALL architectures).  Does this mean it won't be installed into
> > woody until someone manually removes jed-sl-ja_0.98.7.j055-2.deb from
> > all architectures in sid?
> 
> Right. Is there a bug against ftp.debian.org about this? That's the done

Apparently not, submitting now.


Paul Slootman
-- 
home:   [EMAIL PROTECTED] http://www.wurtel.demon.nl/
work:   [EMAIL PROTECTED]   http://www.murphy.nl/
debian: [EMAIL PROTECTED]  http://www.debian.org/
isdn4linux: [EMAIL PROTECTED]  http://www.isdn4linux.org/

Re: lilo.conf

[Christian Kurz]

On 01-01-06 Matt Zimmerman wrote:
> On Sat, Jan 06, 2001 at 05:40:53PM +0100, Christian Kurz wrote:
> > On 01-01-06 Matt Zimmerman wrote:
> > > On Sat, Jan 06, 2001 at 01:58:48PM +0100, Cosimo Alfarano wrote:
> > > > On Sat, Jan 06, 2001 at 01:33:57PM +0100, Peter Makholm wrote:
> > > > > Don't assume devfs! A lot of us uses it, but before our standard
> > > > > kernel uses it our lilo package shouldn't assume it unless it is very
> > > > > sure that it will work.
> > > > 
> > > > He shouldn't assume it even if debian standard kernel package uses it.
> > > > A lot of users don't use them (both std kernel and devfs).
> > 
> > > Especially since devfs support is still considered experimental.
> > 
> > Hm, it's not marked as experimental in kernel 2.4.0, but as work in
> > progress. So support for it would be really good.

> mizar:[~/src/linux/2.4.0/linux] egrep 'VERSION|LEVEL' Makefile  | head -3
> VERSION = 2
> PATCHLEVEL = 4
> SUBLEVEL = 0
> mizar:[~/src/linux/2.4.0/linux] grep -B 1 ^CONFIG_DEVFS_FS 
> Documentation/Configure.help
> /dev file system support (EXPERIMENTAL)
> CONFIG_DEVFS_FS
> mizar:[~/src/linux/2.4.0/linux] grep ' CONFIG_DEVFS_FS ' fs/Config.in
> dep_bool '/dev file system support (EXPERIMENTAL)' CONFIG_DEVFS_FS 
> $CONFIG_EXPERIMENTAL

> It will only show up if CONFIG_EXPERIMENTAL is defined.

Hm, did you bother to read the explanation of devfs? There you find a
statement, that is "work in progress" and so I wouldn't consider it
experimental anymore.

Ciao
 Christian
-- 
  Debian Developer and Quality Assurance Team Member
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgpSdxtwDxNdz.pgp
Description: PGP signature

Re: XFree4.0.2 / wdm interaction bug?

[William Lee Irwin III]

On Sun, Jan 07, 2001 at 02:02:52AM -0800, William Lee Irwin III wrote:
> I've experienced a bug and I'm not entirely sure what to file it against.
> I'm also not sure if anyone else has ever seen this, and was hoping
> someone else might try such a setup and verify the bug exists before
> really reporting it.

> A similar sort of thing can be done with gdm (and I've seen it fail
> under X3 + gdm). This is XFree4.0.2 + TNT2 + wdm 1.19-4.1.

Under kernel 2.2.15 + reiserfs.

I just got a report that only very mild and easily recoverable screen
corruption occurs under the following configuration:

 wli: xserver-svga 3.3.6-13 ; matrox g200 ;
2.2.18 (with a bunch of random patches) ; gdm 2.0.0.beta4.9


Cheers,
Bill

Re: What is wrong with kde2.1 and unstable ?

[Michael Meskes]

On Sat, Jan 06, 2001 at 03:27:18PM -0700, Ivan E. Moore II wrote:
> no clue...I don't use apt to upgrade. :)  Your not alone tho, there is a 
> existing bug report on this (#81365)...so any help you can give me to track

I do use apt through dselect and did an upgrade un Thursday and on Friday.
It worked nicely expect that task-koffice was removed by apt. Don't know why
but since I usually don't use task I didn't care.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Hamish Moffatt]

On Sun, Jan 07, 2001 at 05:43:52PM +1000, Jason Henry Parker wrote:
> ``Banks *are* bastards.'' -- John Laws

Err, yeah.. takes one to know one?


Hamish, glad we don't have him down here.
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: ITA gnucash?

[Ola Lundqvist]

On Sat, Jan 06, 2001 at 08:22:10PM -0500, John Goerzen wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
> 
> > I just want to ask if somebody knows if the maintainer is still
> > active. Gnucash have now quite a lot of bugs and there is a new
> 
> I am here.  Had you cared enough to look at the bug report summary for
> me, you would see that I am closing bugs as well; there are about two
Yes I did that. But closed bugs have no date, so I checked the bugreport
about the new point release, and there was no reply.

> dozen ones listed there that I have fixed within the last 28 days.
> But obviously you didn't do that.

I'm sorry, my mistake, but please calm down. I do not want to mess up
your work. I just want to help. I have seen this new release for some while
so I checked the buglist and there were no reply on that so that is why I
asked.

> > stable version. If he is not active anymore I'll gladly adopt this package.
> 
> Yes, there is one new point release.  It required updating another
> package first.  It fixed one bug reported to Debian, dealing with sort
> order of transactions that occur within a single day.  There is one
> normal bug that I need to look at and see if it's even still relevant,
> but it is not an operational problem, and the rest are upstream bugs
> that were not fixed.  The other bug just required a recompile.

Why I'm interested is because the upstream author(s) have fixed a bug
that I'm quite interested in. It might be in the 1.5.x versions but
I do not know which one, sorry. Well it is not a hurry and I can wait.

> Please do not mistake bug triage for inactivity.  
That is why I asked, to make sure. :)

// Ola

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Björnkärrsgatan 5 A.11   \
|  [EMAIL PROTECTED] 584 36 LINKÖPING |
|  +46 (0)13-17 69 83  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Hamish Moffatt]

On Sun, Jan 07, 2001 at 01:57:11AM -0600, Gordon Sadler wrote:
> On Sun, Jan 07, 2001 at 01:14:40AM -0600, Nathan E Norman wrote:
> > I apologize for prolonging this thread - it's quite annoying.
> > However, after reading this enlightened response I wonder if it's
> > possible for a user to close the (silly) bug he or she reported after
> > he or she solves the problem.  bugs.debian.org doesn't seem to
> > indicate a way for a bug to be closed other than action by the
> > maintainer.
> 
> Actually under /usr/doc/debian the doc-debian package provides a number
> of files, including bug-main-mailcontrol.txt.

Yes, but also anyone, including the submitter, spammers, joe public
etc can email [EMAIL PROTECTED] to close a bug as well. The BTS doesn't care.


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

Re: lilo.conf

[Hamish Moffatt]

On Sun, Jan 07, 2001 at 08:53:29PM +1100, Russell Coker wrote:
> The latest package is supposed to ask you whether you want to generate a new 
> lilo.conf or keep the manually created one (default keep the manual one).  If 

If you already have a /etc/lilo.conf, why ask anything at all?

I like the grub package's approach. The new boot loader files appear
in /usr/share. If I want to upgrade them, I have to copy them manually
to /boot/grub and re-run the install process. The package itself
really keeps out of the way.


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

Re: What is wrong with kde2.1 and unstable ?

[Ivan E. Moore II]

> > no clue...I don't use apt to upgrade. :)  Your not alone tho, there is a 
> > existing bug report on this (#81365)...so any help you can give me to track
> 
> I do use apt through dselect and did an upgrade un Thursday and on Friday.
> It worked nicely expect that task-koffice was removed by apt. Don't know why
> but since I usually don't use task I didn't care.

because there are only 2 task-kde* packages that *should* exist now. The others
have yet to be removed from the archive.  (Bug#79708)

Ivan

-- 

Ivan E. Moore II
[EMAIL PROTECTED]
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD

Re: Optimisations query

[Hamish Moffatt]

On Sun, Jan 07, 2001 at 10:43:38AM +, Michel Alexandre Salim wrote:
> However Red Hat seems to have solved the same problem with RH 7.0 -
> despite whatever else that release is. They do this by compiling to a
> target CPU of i686 but keeping the target platform to i386. Not too
> ideal for AMD users I suppose (I have one Intel and one AMD box myself)
> but better than nothing?
> 
> This comes to mind when thinking about some assertions I've seen made
> that glibc 2.2 only works on i486 and better on Intels. If so, all the
> better - since Woody will be based on it why not compile all to a target
> CPU of i686 and target platform of i486?

Do all of these binaries actually run properly on 386, 486, Pentium,
K6*, Cyrix, IDT, and Athlon chips, and any other x86 compatibles?

No? Then forget it.

The configuration notes for the kernel, for example, specifically say:

  If you specify one of "486" or "586" or "Pentium" or "PPro", then
  the kernel will not necessarily run on earlier architectures (e.g. a
  Pentium optimized kernel will run on a PPro, but not necessarily on
  a i486).


Hamish.. no Intel chips in use at my place, thanks.
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Hamish Moffatt]

On Sun, Jan 07, 2001 at 04:40:03AM +0200, Eray Ozkural (exa) wrote:
> Hamish Moffatt wrote:
> > On Sat, Jan 06, 2001 at 11:34:04PM +0200, Eray Ozkural (exa) wrote:
> > > If you call your insults to another contributor to debian "deserved rant",
> > > then I'd think you are either misinterpreting your status or unaware of
> > > any social skills.
> > 
> > I'm sorry, WHO is misinterpeting their status?
> 
> I think the xfree86 maintainer is misinterpreting his status.
> As a prospective developer, I'd be greatly surprised if anybody
> told me that developers have the right to swear publicly in an outburst
> of adolescent frenzy.

Debian does not try to regulate the behaviour of its maintainers,
except where the quality of the distribution itself is involved.
What are your contributions to Debian Eray?

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

Re: package pool and big Packages.gz file

[Sam Vilain]

On Fri, 5 Jan 2001 09:33:05 -0700 (MST)
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:

> > If that suits your needs, feel free to write a bugreport on apt about
> > this.
> Yes, I enjoy closing such bug reports with a terse response.
> Hint: Read the bug page for APT to discover why!

>From bug report #76118:

No. Debian can not support the use of rsync for anything other than
mirroring, APT will never support it.

Why?  Because if everyone used rsync, the loads on the servers that supported 
rsync would be too high?  Or something else?
--
Sam Vilain, [EMAIL PROTECTED]WWW: http://sam.vilain.net/
GPG public key: http://sam.vilain.net/sam.asc

Processed: hmmm

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 81396 root shell fscked after admin fscked it
Bug#81396: root shell fscked after upgrade to woody
Changed Bug title.
(By the way, that Bug is currently marked as done.)

> thanks
Stopping processing here.

Please contact me if you need assistance.

Darren Benham
(administrator, Debian Bugs database)

Re: tar -I incompatibility

[Sam Couter]

Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> Just as linux-centric as the other way is solaris-centric.

Not true. There's the way GNU tar works, then there's the way every other
tar on the planet works (at least with respect to the -I option). GNU tar is
(used to be) the odd one out. Now you're saying that not behaving like the
odd man out is being Solaris-centric? I don't think so.

> 
> I like systems that don't change on a day to day basis. I don't want
> "ls *" to do "rm *" tomorrow just because some other unix does it and
> the author feels like it.
> 

I'm sure this has been said before, but:

Don't run unstable if you don't like stuff changing or breaking.

Unstable breaks stuff from time to time. It changes stuff more often than
that.

If options or behaviour changes from one update to the next, stiff bikkies.
Deal with it in your own quiet little way.

If that behaviour or option was non-standard to begin with, then think
yourself lucky that you had it working as long as you did.

> "tar -xIvvf file.tar.bz2" has been in use under linux for over a year
> by pretty much everybody. Even if the author never released it as
> stable, all linux distributions did it. I think that should count
> something. Enough to at least ease the transition.

Pretty much everybody? I'd say you could modify that statement to "pretty
much everybody who doesn't deal with non-Linux systems often". The
qualifier to that statement is very important.

Ask someone who's actually used a non-Linux UNIX or UNIX-like system to
explain it to you sometime.
-- 
Sam Couter  |   Internet Engineer   |   http://www.topic.com.au/
[EMAIL PROTECTED]|   tSA Consulting  |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


pgp9IMxwRKa2j.pgp
Description: PGP signature

Bug#81396: root shell fscked after upgrade to woody

[exa]

On Sun, Jan 07, 2001 at 08:29:03AM +0200, Eray Ozkural wrote:
> Thanks for the suggestion. That's it. Please close the bug. That file has
> somehow gone and replacing it will solve the problem.

And of course moving .bash_profile out of the way. Thanks again.

Please don't complain "why have you submitted this bug?". It occured to
me as a bug, and I wanted to report it as soon as I observed it. Sometimes
the bugs I see turn out to be bogus surely, but I have reported many
useful bugs as well. I invest a lot of time in testing stuff and reporting
bugs.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Bug#81396: root shell fscked after upgrade to woody

[exa]

On Sun, Jan 07, 2001 at 01:23:20AM -0600, Nathan E Norman wrote:
> Golly, there _was_ a misconfiguration.  Now that you've made your
> disdain for Branden's sharp tongue well known, I hope you plan to
> apologize to Matt Zimmerman for your rudeness.
> 

I'm glad the problem has been resolved. I could apologize to Matt
Zimmerman but I don't understand how this relates to the xfree86
maintainer. In addition to this, it was not obvious to me until it
has been solved. I wouldn't have reported it if I knew how to solve
it. I know it's kind of a trivial thing, but I honestly hadn't noticed
the existence of /root/.profile in the base system? until now. As a
matter of fact, I'd even thought this was some kind of a feature. I wish
I had the time to know about every detail but it's not possible. Sorry
if this bug has bothered you.

And well, you're the one who's calling what I wrote "rude and silly"
so who's offensive? My only objective is to resolve whatever problem
I had.

In reporting a bug, there's always the risk of having made a mistake
and looking silly. But in many cases, out of the many valid bugs I've reported
I believe that improvements have been made. Testing is part of contribution.

Could please one of you close this bug now? :>

Best Regards,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: XFree4.0.2 / wdm interaction bug?

[Bas Zoetekouw]

Hi William!

You wrote:

Content-Description: brief message
> I've experienced a bug and I'm not entirely sure what to file it against.
[...]
> What I actually saw was that after I switched vt's a couple of times,
> screen corruption occurred. The images from the two Xservers running on
> different vt's were overlaid. In the XFree3 + I128 + gdm instance, the
> screen gets blanked and one of the XFree3 servers spins hard.

This is most probably not a wdm bug. You should file a bug against one
of the X packages I think.

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: package pool and big Packages.gz file

[Sam Vilain]

On Fri, 5 Jan 2001 19:08:38 +0200
[EMAIL PROTECTED] (Sami Haahtinen) wrote:

> Or, can rsync sync binary files?
> hmm.. this sounds like something worth implementing..

rsync can, but the problem is with a compressed stream if you insert or alter 
data early on in the stream, the data after that change is radically different.

But... you could use it successfully against the .tar files inside the .deb, 
which are normally compressed.  This would probably require some special 
implementation of rsync, or to have the uncompressed packages on the server and 
put the magic in apt.

Or perhaps the program "apt-mirror" is called for, which talks its own protocol 
to other copies of itself, and will do a magic job of selectively updating 
mirror copies of the debian archive using the rsync algorithm.  This would be 
similar to the apt-get and apt-move pair, but actually sticking it into a 
directory structure that looks like the debian mirror.  Then, if you want to 
enable it, turn on the server version and share your mirror with your friends 
inside your corporate network!  Or an authenticated version, so that a person 
with their own permanent internet connection could share their archive with a 
handful of friends - having an entire mirror would be too costly for them.  I 
think this has some potential to be quite useful and reduce bandwidth 
requirements.  It could use GPG signatures to check that nothing funny is going 
on, too.

Either that or keep a number of patch files or .xd files for a couple of old 
revs per packages against the uncompressed contents of packages to allow small 
changes to packages to be quick.  Or perhaps implement this as patch packages, 
which are a special .deb that only contain the changed files and upgrade the 
package.
--
Sam Vilain, [EMAIL PROTECTED]WWW: http://sam.vilain.net/
GPG public key: http://sam.vilain.net/sam.asc

Re: tar -I incompatibility

[Hamish Moffatt]

On Mon, Jan 08, 2001 at 12:12:59AM +1100, Sam Couter wrote:
> Don't run unstable if you don't like stuff changing or breaking.
> Unstable breaks stuff from time to time. It changes stuff more often than
> that.

This is a bit different, Sam. The I switch works in tar in potato.
Your comment would apply if this were a temporary change and I would
again work (ie compress with bzip2) by the time woody is released,
but that's not the intention, is it?

Frankly, I don't see why gnu tar needs to be compatible with
OS-specific versions because most of those are feature-poor anyway.

I agree with the suggestion that we modify tar for Debian to
provide -I at least for compatibility for one more release.


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

Re: What to do about /etc/debian_version

[Martin Keegan]

Martijn van Oosterhout <[EMAIL PROTECTED]> writes:

> Joey Hess wrote:
> > I think /etc/mtab is on its way out. A 2.4.x kernel with devfs has a
> > /proc/mounts that actually has a proper line for the root filesystem.
> > Linking the two files would probably actually work on such a system
> > without breakage.
> 
> Does 2.4 now also include the information on which loop devices are
> related to which filesystems? AFAIK that's the only thing that went 
> strange after linking /proc/mounts and /etc/mtab; loop devices not being
> freed after unmounting.

When doing this I had a problem with the mount programme insisting on
explicitly checking whether /etc/mtab were a symlink and explicitly
breaking if it were. Why is this?

Mk

Re: tar -I incompatibility

[Martin Bialasinski]

* Sam Couter <[EMAIL PROTECTED]> wrote:

> I'm sure this has been said before, but:

Sure, but it doesn't apply here.

> Don't run unstable if you don't like stuff changing or breaking.

tar in potato uses -I for bzip2. So far, tar -I won't be bzip2 in
woody, the next stable.

So anyone using just stable will be bitten by it. This has nothing to
do with unstable.

Ciao,
Martin

Re: Compiling 2.0.38 kernel

[Chris L. Mason]

On Sun, Jan 07, 2001 at 02:08:17PM +0100, Stefan Frank wrote:
> 
> Hi Chris,
> 
> incidentally i tried to do the same yesterday.
> I got the same error message as you, but didn't bother to try to fix it.
> Maybe you need an older version of make?
> 
> If you manage to get this kernel working, would you mind updating me how
> you did it?
> 

Hi Stefan,

Unfortunately, no, I'm still having trouble.  :(  I might wind up
installing a fresh potato system on another partition to see if it works in
potato or not.  If not, I guess I should file a bug report.

I hope you don't mind, I will copy this to the mailing list so that people
are aware it's not an isolated problem.


Chris

Re: tar -I incompatibility

[Eduard Bloch]

#include 
Nicolás Lichtmaier wrote on Sat Jan 06, 2001 um 05:35:55PM:

>  Or alias -I to -j, but print a warning to stderr:
> 
> tar: warning: Using the -I option for bzip compression is an obsolete
> functionality and it will removed in future versions of tar,
> 
>  Then, in the woody+1 we make -I work as upstream tar does now.
 
IMHO we should do it this way, but arrange with tar maintainers in other
distributions first. So Debian should not use this as the only
distribution while all others follows the upstream.

Gr{us,eeting}s,
Eduard.
-- 

Eduard Bloch <[EMAIL PROTECTED]>; HP: http://eduard.bloch.com/edecosi
0xEDF008C5(GnuPG): E6EB 98E2 B885 8FF0 6C04 5C1D E106 481E EDF0 08C5
**
Das wahrlich arnoootische daran ist, das wahrscheinlich _alle_
Regulars diesem Thread absolut faziniert folgen, nur traut sich keiner
was zu sagen, weil man die beiden ja offiziell im Killfile hat.
Alexander Stielau in de.alt.arnooo

Re: package pool and big Packages.gz file

[Goswin Brederlow]

> " " == Sam Vilain <[EMAIL PROTECTED]> writes:

 > On Fri, 5 Jan 2001 09:33:05 -0700 (MST) Jason Gunthorpe
 > <[EMAIL PROTECTED]> wrote:

>> > If that suits your needs, feel free to write a bugreport on
>> apt about this.  Yes, I enjoy closing such bug reports with a
>> terse response.  Hint: Read the bug page for APT to discover
>> why!

>> From bug report #76118:

 > No. Debian can not support the use of rsync for anything other
 > than mirroring, APT will never support it.

 > Why?  Because if everyone used rsync, the loads on the servers
 > that supported rsync would be too high?  Or something else?  --
 > Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/ GPG
 > public key: http://sam.vilain.net/sam.asc

Actually the load should drop, providing the following feature add
ons:

1. cached checksums and pulling instead of pushing
2. client side unpackging of compressed streams

That way the rsync servers would have to first server the checksum
file from cache (being 200-1000 smaller than the real file) and then
just the blocks the client asks for. So if 1% of the file being
rsynced fits its even and everything above that saves bandwidth.

The current mode of operation of rsync works in the reverse, so all
the computation is done on the server every time, which of cause is a
heavy load on the server.

I hope both features will work without chaning the server, but if not,
we will have to wait till servers catch up with the feature.

MfG
Goswin

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

[Adrian Bunk]

On Mon, 1 Jan 2001, Joey Hess wrote:

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

I thought a maintainer is responsible for keeping his packages up to date?
Policy version 3.0.0 is out since 1,5 years now and if we decide to send
RC bugs on all packages with a lower Standards-Version and wait 2 months
that's a good chance to find packages whose maintainer is AWOL - all other
packages should have been updated until then.

cu,
Adrian

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
-- Mahatma Ghandi

Re: What to do about /etc/debian_version

[Goswin Brederlow]

> " " == Martin Keegan <[EMAIL PROTECTED]> writes:

 > Martijn van Oosterhout <[EMAIL PROTECTED]> writes:

>> Joey Hess wrote: > I think /etc/mtab is on its way out. A 2.4.x
>> kernel with devfs has a > /proc/mounts that actually has a
>> proper line for the root filesystem.  > Linking the two files
>> would probably actually work on such a system > without
>> breakage.
>> 
>> Does 2.4 now also include the information on which loop devices
>> are related to which filesystems? AFAIK that's the only thing
>> that went strange after linking /proc/mounts and /etc/mtab;
>> loop devices not being freed after unmounting.

No. Not that I saw a change for it. How could it?  Currently when
mounting a loop device, mount writes the filename that gets attached
to the loop device into /etc/mtab and then mounts /dev/loopX. Because
/etc/mtab is read-only mount can't write the filename and thus doesn't
know what to detach when unmounting.

mount can't know the difference between
"mount -oloop file path"
and
losetup /dev/loop0 file
"mount /dev/loop0 path"

Maybe the mount or loopback interface could be changed to record that
umount has to free the loop device upon umount.

 > When doing this I had a problem with the mount programme
 > insisting on explicitly checking whether /etc/mtab were a
 > symlink and explicitly breaking if it were. Why is this?

Never had that problem.

MfG
Goswin

Re: package pool and big Packages.gz file

[Falk Hueffner]

Sam Vilain <[EMAIL PROTECTED]> writes:

> On Fri, 5 Jan 2001 19:08:38 +0200
> [EMAIL PROTECTED] (Sami Haahtinen) wrote:
> 
> > Or, can rsync sync binary files?
> > hmm.. this sounds like something worth implementing..
> 
> rsync can, but the problem is with a compressed stream if you insert
> or alter data early on in the stream, the data after that change is
> radically different.
> 
> But... you could use it successfully against the .tar files inside
> the .deb, which are normally compressed.  This would probably
> require some special implementation of rsync, or to have the
> uncompressed packages on the server and put the magic in apt.
>
> [...]
> 
> Either that or keep a number of patch files or .xd files for a
> couple of old revs per packages against the uncompressed contents of
> packages to allow small changes to packages to be quick.  Or perhaps
> implement this as patch packages, which are a special .deb that only
> contain the changed files and upgrade the package.

I suggest you have a look at 'tje' by Joost Witteveen
(http://joostje.op.het.net/tje/index.html). It is specifically written
with the goal in mind to sync Debian mirrors with minimum bandwidth
use. It doesn't use the rsync algorithm, but something similar. It
understands .debs and claims to have less server CPU usage than rsync,
since it caches diffs and md5sums. It would be really nice if anybody
with an up-to-date mirror could volunteer to provide a machine to set
up a tje server to test it a little more...

Falk

Re: lilo.conf

[Matt Zimmerman]

On Sun, Jan 07, 2001 at 11:17:20AM +0100, Christian Kurz wrote:

> On 01-01-06 Matt Zimmerman wrote:
> > mizar:[~/src/linux/2.4.0/linux] egrep 'VERSION|LEVEL' Makefile  | head -3
> > VERSION = 2
> > PATCHLEVEL = 4
> > SUBLEVEL = 0
> > mizar:[~/src/linux/2.4.0/linux] grep -B 1 ^CONFIG_DEVFS_FS 
> > Documentation/Configure.help
> > /dev file system support (EXPERIMENTAL)
> > CONFIG_DEVFS_FS
> > mizar:[~/src/linux/2.4.0/linux] grep ' CONFIG_DEVFS_FS ' fs/Config.in
> > dep_bool '/dev file system support (EXPERIMENTAL)' CONFIG_DEVFS_FS 
> > $CONFIG_EXPERIMENTAL
> 
> > It will only show up if CONFIG_EXPERIMENTAL is defined.
> 
> Hm, did you bother to read the explanation of devfs? There you find a
> statement, that is "work in progress" and so I wouldn't consider it
> experimental anymore.

I did read the description; in fact, I use devfs.  Its description has had the
note:

  This is work in progress. If you want to use this you *must* read
  Documentation/filesystems/devfs/README

since it was first integrated into the 2.3 series (2.3.46).  Hell, the devfs
patches against 2.1 had exactly the same text, and there have certainly been a
number of bugfixes since then.  I wouldn't read "work in progress" to mean "no
longer experimental".

Hopefully, devfs will receive much more widespread testing with the release of
2.4.  Bugs will be chased out, or their rarity will be demonstrated, and
eventually it will no longer depend on CONFIG_EXPERIMENTAL (at which point it
will get much, much more widespread testing, etc. etc.).

That said, I think we should definitely support devfs as it seems destined to
become a standard feature (and makes life easier to boot).

-- 
 - mdz


pgpoLPJPHql7u.pgp
Description: PGP signature

RFDisscusion: Big Packages.gz and Statistics and Comparing solution

[zhaoway]

Hi,

[Sorry for the thread broken, my POP3 provider stopped.]
[Please Cc: me! <[EMAIL PROTECTED]>. Sorry! ;-)]

1. RFDiscussion on big Packages.gz

1.1. Some statistics

% grep-dctrl -P 
-sPackage,Priority,Installed-Size,Version,Depends,Provides,Conflicts,Filename,Size,MD5sum
 -r '.*' ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages | 
gzip -9 > test.pkg.gz
% gzip -9 ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages 
% ls -alF *.gz
-rw-r--r--1 zw   zw1157494 Jan  7 21:20 
ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages.gz
-rw-r--r--1 zw   zw 341407 Jan  7 21:23 test.pkg.gz
% 

This approach is simple and straight and almost compatible. But could
accpect 10K more packages come into Debian with little loss. Worth
consideration. IMHO.

Better, if `Description:' etc. could come into seperate gzipped file along
with the Debian package.

1.2. Little math

Suppose: 1) Site A get K hits of `apt-get update' per day. With everyday
passed, M extra hits added, as Debian goes more popular.
 2) N new packages come into Debian every day. After `gzip -9',
each contribute 206 byte to old package index file, and 61 to
new format index file. Current package number is P.
 3) Days passed as X axis.
 4) B as the byte size of the data flow for `apt-get update' for
that day. On the server side. (Client side K =1, M = 0)

  B = (K + M*X) * (P + N*X) * 206   is for old format package index
  B = (K + M*X) * (P + N*X) * 61is for new format package index
  
[It's still X^^2 function, anyway, so it's, in theory, not a big deal. ;-)]
[Only if we could eliminate the need for Package Index. That is possible. ]

  For K = 500, P = 6000, X = 0, Server side B is,
  [EMAIL PROTECTED] ~/tmp % echo $((6000*500*206))
  61800
  [EMAIL PROTECTED] ~/tmp % echo $((6000*500*61))
  18300
  [EMAIL PROTECTED] ~/tmp % 
  
[Though the caches could help a great lot for servers in such cases.]
 
2. Compare with DIFF and RSYNC method of APT

2.1. They need server support. (More than a directory layout and client tool
 changing.)

2.2. If you don't update for a long time, DIFF won't help. RSYNC help less.

3. Additional benefits

Seperate changelog.Debian and `Description:' etc. out into meta-info file
could help users: 1) reduce the bandwidth eaten 2) help their upgrade
decisions easily.

-- 
echo < */
EOF

Bug#81396: root shell fscked after upgrade to woody

[Matt Zimmerman]

On Sun, Jan 07, 2001 at 09:01:40AM +0200, Eray Ozkural wrote:

> On Sun, Jan 07, 2001 at 08:29:03AM +0200, Eray Ozkural wrote:
> > Thanks for the suggestion. That's it. Please close the bug. That file has
> > somehow gone and replacing it will solve the problem.
> 
> And of course moving .bash_profile out of the way. Thanks again.
> 
> Please don't complain "why have you submitted this bug?". It occured to
> me as a bug, and I wanted to report it as soon as I observed it. Sometimes
> the bugs I see turn out to be bogus surely, but I have reported many
> useful bugs as well. I invest a lot of time in testing stuff and reporting
> bugs.

Reporting a bug as soon as you observe it is not necessarily the best approach,
especially with a vague problem report.  The maintainer (or debian-devel) will
be unlikely to have an immediate answer for you, and they usually have no means
to investigate your particular configuration.

Better to investigate the problem further on your own, then provide a focused,
clear bug report (or else discover that you haven't found a bug at all).

-- 
 - mdz

Re: package pool and big Packages.gz file

[Matt Zimmerman]

On Sun, Jan 07, 2001 at 03:49:43PM +0100, Goswin Brederlow wrote:

> Actually the load should drop, providing the following feature add
> ons:
> [...]

The load should drop from that induced by the current rsync setup (for the
mirrors), but if many, many more client start using rsync (instead of
FTP/HTTP), I think there will still be a significant net increase in load.

Whether it would be enough to cause a problem is debatable, and I honestly
don't know either way.

-- 
 - mdz

Re: tar -I incompatibility

[Marcus Brinkmann]

On Sun, Jan 07, 2001 at 02:05:27AM -0500, Michael Stone wrote:
> On Sun, Jan 07, 2001 at 04:25:43AM +0100, Marcus Brinkmann wrote:
> > On Sun, Jan 07, 2001 at 03:28:46AM +0100, Goswin Brederlow wrote:
> > > "tar -xIvvf file.tar.bz2" has been in use under linux for over a year
> > > by pretty much everybody. Even if the author never released it as
> > > stable, all linux distributions did it. I think that should count
> > > something.
> > 
> > It tells a lot about the people making the distributions at least.
> 
> Before making such snide comments, take a look at the changelog.Debian
> entries relating to the switch from 1.13 to 1.13.x.

I see. Well, I don't think that Bdale did something wrong with including
1.13.x. But I find the reactions to the flag change shown here by some
people quite inappropriate. When using unreleased software, people have to
expect such changes, especially for non-standard extensions. It happens all
the time.

In any way, sorry for the snide comment, it didn't reflect what I wanted to
say, and thanks Michael for correcting me.

Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

ITP: cabextract -- file extractor for Microsoft CAB files

[sharkey]

cabextract is available at http://www.kyz.uklinux.net/cabextract.php3.
It allows Microsoft CAB files to be decompressed and unarchived.  It's
distributed under the GPL.

Eric Sharkey

Bug reports - copies to submitter

[Bob Hilliard]

 This is probably in the documentation somewhere, but I haven't
been able to find it.

 Which messages to the bug reporting system are automatically
forwarded to the submitter, and which must be explicitly copied to
[EMAIL PROTECTED]

Bob 
-- 
   _
  |_)  _  |_   Robert D. Hilliard  <[EMAIL PROTECTED]>
  |_) (_) |_)  1294 S.W. Seagull Way   <[EMAIL PROTECTED]>
   Palm City, FL  USA  GPG Key ID: 390D6559 
   PGP Key ID: A8E40EB9

Re: package pool and big Packages.gz file

[Goswin Brederlow]

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

 > On Sun, Jan 07, 2001 at 03:49:43PM +0100, Goswin Brederlow
 > wrote:
>> Actually the load should drop, providing the following feature
>> add ons: [...]

 > The load should drop from that induced by the current rsync
 > setup (for the mirrors), but if many, many more client start
 > using rsync (instead of FTP/HTTP), I think there will still be
 > a significant net increase in load.

 > Whether it would be enough to cause a problem is debatable, and
 > I honestly don't know either way.

When the checksums are cached there will be no cpu load caused by
rsync, since it will only transfer the file. And the checksum files
will be realy small as I said, so if some similarity is found the
reduction in data will make more than up for the checksum download.

The only increase is the space needed to store the checksums in some
form of cache.

MfG
Goswin

Re: Bug reports - copies to submitter

[Bas Zoetekouw]

Hi Bob!

You wrote:

>  Which messages to the bug reporting system are automatically
> forwarded to the submitter, and which must be explicitly copied to
> [EMAIL PROTECTED]

IIRC, only the [EMAIL PROTECTED] messages are sent to the submitter
-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: RFDisscusion: Big Packages.gz and Statistics and Comparing solution

[Goswin Brederlow]

> " " == zhaoway  <[EMAIL PROTECTED]> writes:

 > Hi, [Sorry for the thread broken, my POP3 provider stopped.]
 > [Please Cc: me! <[EMAIL PROTECTED]>. Sorry! ;-)]

 > 1. RFDiscussion on big Packages.gz

 > 1.1. Some statistics

 > % grep-dctrl -P
 > 
-sPackage,Priority,Installed-Size,Version,Depends,Provides,Conflicts,Filename,Size,MD5sum
 > -r '.*'
 > ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages
 > | gzip -9 > test.pkg.gz % gzip -9
 > ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages
 > % ls -alF *.gz -rw-r--r-- 1 zw zw 1157494 Jan 7 21:20
 > ftp.jp.debian.org_debian_dists_unstable_main_binary-i386_Packages.gz
 > -rw-r--r-- 1 zw zw 341407 Jan 7 21:23 test.pkg.gz %

Ahh, what does it do? Just take out the descriptions?

 > This approach is simple and straight and almost compatible. But
 > could accpect 10K more packages come into Debian with little
 > loss. Worth consideration. IMHO.

 > Better, if `Description:' etc. could come into seperate gzipped
 > file along with the Debian package.

The problem is that people want to browse descriptions to find a
package fairly often or just run "apt-cache show package" to see what
a package is about. So you need a method to download all descriptions.

Also many small files compress far less than one big file.


 > 2. Compare with DIFF and RSYNC method of APT

 > 2.1. They need server support. (More than a directory layout
 > and client tool changing.)

As far as I see theres no server support needed for rsync support to
operate better on compressed files.

 > 2.2. If you don't update for a long time, DIFF won't
 > help. RSYNC help less.

If you update often, saving 1 Byte every time is worth it. If you
update seldomely, it doesn't realy matter that you download a big
Packages.gz. You would have to downlaod all the small Packages.gz
files also.

And after that you download 500 MB of updates. So who cares about 2MB
packages.gz?

Also, diff and rsync do a great job even after a long time:

diff potato_Packages woody_Packages| gzip -9 | wc --bytes
 339831

% ls -l /debian/dists/woody/main/binary-i386/Packages.gz
-rw-r--r--1 mrvn mrvn   955259 Jan  6 21:03 
/debian/dists/woody/main/binary-i386/Packages.gz

So you see, between potato and woody diff saves about 60%.
Also note that rsync usually performs better than cvs, since it does
not include the to be removed lines in the download.

 > 3. Additional benefits

 > Seperate changelog.Debian and `Description:' etc. out into
 > meta-info file could help users: 1) reduce the bandwidth eaten
 > 2) help their upgrade decisions easily.

A global Description.gz might benefit from the fact that the
description doesn't change for each update, but the extra work needed
for this to realy work is not worth it. It would only benefit people
that do daily mirroring, where rsync would do just as good.

MfG
Goswin

Re: tar -I incompatibility

[Goswin Brederlow]

> " " == Marcus Brinkmann <[EMAIL PROTECTED]> writes:

 > On Sun, Jan 07, 2001 at 02:05:27AM -0500, Michael Stone wrote:
>> On Sun, Jan 07, 2001 at 04:25:43AM +0100, Marcus Brinkmann
>> wrote: > On Sun, Jan 07, 2001 at 03:28:46AM +0100, Goswin
>> Brederlow wrote: > > "tar -xIvvf file.tar.bz2" has been in use
>> under linux for over a year > > by pretty much everybody. Even
>> if the author never released it as > > stable, all linux
>> distributions did it. I think that should count > > something.
>> > > It tells a lot about the people making the distributions at
>> least.
>> 
>> Before making such snide comments, take a look at the
>> changelog.Debian entries relating to the switch from 1.13 to
>> 1.13.x.

 > I see. Well, I don't think that Bdale did something wrong with
 > including 1.13.x. But I find the reactions to the flag change
 > shown here by some people quite inappropriate. When using
 > unreleased software, people have to expect such changes,
 > especially for non-standard extensions. It happens all the
 > time.

On anything apart from Debian I wouldn't say a word about it.

BUT on Debian tar -I is a standard and its stable. So I start
screaming. Since the Debian maintainer made -I stable with a unstable
upstream source, its his responsibility to watch it.

Its the authors fault to have not resolved the problem for so long and
suddenly resolve it in such a disasterous way, but also the Debian
maintainers fault not to warn us and ease our transition.

Fault might be a to strong word, I just mean that there should be a
new upload asap that eigther reverts the -I change or tells the user
about it. Having -I silently just do something else is not an option
in my eyes.

MfG
Goswin

Re: tar -I incompatibility

[Michael Stone]

On Mon, Jan 08, 2001 at 12:12:59AM +1100, Sam Couter wrote:
> Goswin Brederlow <[EMAIL PROTECTED]> wrote:
> > Just as linux-centric as the other way is solaris-centric.
> 
> Not true. There's the way GNU tar works, then there's the way every other
> tar on the planet works (at least with respect to the -I option). GNU tar is
> (used to be) the odd one out. Now you're saying that not behaving like the
> odd man out is being Solaris-centric? I don't think so.

I have a lot of non-linux systems. Most of them don't have a -I operator
on tar--that's why this is such a ludicrous argument. (Specifically, I
checked Solaris, IRIX, AIX, HP/UX, and UNICOS. Only Solaris has a -I
with the meaning now used in gnu tar. So yes, IME solaris is the odd man
out and the change is solaris-centric.) Of the other flags I mentioned
in a previous email (-Fiklop), *several* are found with different
meanings on many tar implementations, yet no one seems interested in
changing them. If someone uses multiple tar implementations he needs to
read the man page; there is no other useful compatibility assumption.
Changing gnu tar to be compatible with one of many diverse proprietary
implementations, for only one of several incompatible flags, is a
rationalization rather than a justification.

> > 
> > I like systems that don't change on a day to day basis. I don't want
> > "ls *" to do "rm *" tomorrow just because some other unix does it and
> > the author feels like it.
> > 
> 
> I'm sure this has been said before, but:
> 
> Don't run unstable if you don't like stuff changing or breaking.

Bzzt. The stable version of tar is basically unusable because it
contains several known bugs and is unmaintained. Upstream maintainer
recommended following the so-called unstable tree to address those known
bugs.

> Unstable breaks stuff from time to time. It changes stuff more often than
> that.
> 
> If options or behaviour changes from one update to the next, stiff bikkies.
> Deal with it in your own quiet little way.
> 
> If that behaviour or option was non-standard to begin with, then think
> yourself lucky that you had it working as long as you did.

Most of the options in gtar are non-standard. Are you saying that users
should rely on none of them?

[snip]
> Ask someone who's actually used a non-Linux UNIX or UNIX-like system to
> explain it to you sometime.

See above, and lose the condescension. People who use multiple platforms
should know better than to assume behavior of tar flags across
implementations.

I don't know whether any amount of discussion will convince the upstream
tar maintainers to undo this, but I certainly hope that the debian
version at least prevents serious silent breakage by either reverting
the change to -I and printing a message that the option is deprecated or
removing the -I flag entirely.

-- 
Mike Stone

O: gstep-core -- GNUstep core libraries

[Matthias Klose]

Package: wnpp

The GNUstep libraires (together with gstep-extensions and
gstep-guile). See http://www.gnustep.org/ for more information.

Re: tar -I incompatibility

[Manoj Srivastava]

>>"Sam" == Sam Couter <[EMAIL PROTECTED]> writes:

 Sam> Not true. There's the way GNU tar works, then there's the way every other
 Sam> tar on the planet works (at least with respect to the -I option). GNU tar 
is
 Sam> (used to be) the odd one out. Now you're saying that not behaving like the
 Sam> odd man out is being Solaris-centric? I don't think so.

Could you please name the other unices that behave identically
 to solaris tar wrt the -I option? And which other unices even have
 the -I option in tar?

manoj
-- 
 Watch your mouth, kid, or you'll find yourself floating home. Han
 Solo
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: lilo.conf

[Manoj Srivastava]

>>"Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:

 Hamish> On Sun, Jan 07, 2001 at 08:53:29PM +1100, Russell Coker wrote:
 >> The latest package is supposed to ask you whether you want to generate a 
 >> new 
 >> lilo.conf or keep the manually created one (default keep the manual one).  
 >> If 

 Hamish> If you already have a /etc/lilo.conf, why ask anything at all?

 Hamish> I like the grub package's approach. The new boot loader files appear
 Hamish> in /usr/share. If I want to upgrade them, I have to copy them manually
 Hamish> to /boot/grub and re-run the install process. The package itself
 Hamish> really keeps out of the way.

I think that this would be the preferred behaviour as far as I
 am concenred.

manoj
-- 
 F: When into a room I plunge, I Sometimes find some VIOLET
 FUNGI. Then I linger, darkly brooding On the poison they're
 exuding. The Roguelet's ABC
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: tar -I incompatibility

[Chris Gray]

> Michael Stone writes:

(snip flamage)
ms> I don't know whether any amount of discussion will convince
ms> the upstream tar maintainers to undo this, but I certainly
ms> hope that the debian version at least prevents serious silent
ms> breakage by either reverting the change to -I and printing a
ms> message that the option is deprecated or removing the -I flag
ms> entirely.

The tar maintainer is closing bug reports related to this problem as
quickly as they come in, or else I would send this to the BTS, but for
the meantime, here is an uncompiled patch:



--- tar.c.orig  Sun Oct 29 17:36:32 2000
+++ tar.c   Sun Jan  7 12:39:57 2001
@@ -362,7 +362,7 @@
   PATTERNat list/extract time, a globbing PATTERN\n
\
   -o, --old-archive, --portability   write a V7 format archive\n\
   --posixwrite a POSIX format archive\n\
-  -j, --bzip2filter the archive through bzip2\n\
+  -I, -j --bzip2 filter the archive through bzip2\n\
   -z, --gzip, --ungzip   filter the archive through gzip\n\
   -Z, --compress, --uncompress   filter the archive through compress\n\
   --use-compress-program=PROGfilter through PROG (must accept -d)\n"),
@@ -371,7 +371,7 @@
 \n\
 Local file selection:\n\
   -C, --directory=DIR  change to directory DIR\n\
-  -T, -I, --files-from=NAMEget names to extract or create from file NAME\n\
+  -T, --files-from=NAMEget names to extract or create from file NAME\n\
   --null   -T reads null-terminated names, disable -C\n\
   --exclude=PATTERNexclude files, given as a globbing PATTERN\n\
   -X, --exclude-from=FILE  exclude globbing patterns listed in FILE\n\
@@ -674,6 +674,11 @@
ignore_zeros_option = 1;
break;
 
+  case 'I':
+  fprintf(stderr,
+"%s: Warning: the use of the I flag will soon mean --files-from
+for compatibility with Solaris tar.  Please use the j flag instead
+when you mean --bzip2.", program_name);
   case 'j':
set_use_compress_program_option ("bzip2");
break;
@@ -796,7 +801,7 @@
break;
 
   case 'T':
-  case 'I': /* for compatibility with Solaris tar */
+/*  case 'I': /* for compatibility with Solaris tar */
files_from_option = optarg;
break;
 
-- 
Got jag?  http://www.tribsoft.com

Re: tar -I incompatibility

[calvin]

Hello,

I think the -I ==> -j change is not that bad.
The only package I found using -I was devscripts' /usr/bin/uupdate.
I submitted this patch:

--- uupdate.origSun Jan  7 18:40:59 2001
+++ uupdate Sun Jan  7 18:43:13 2001
@@ -294,7 +294,7 @@
 X="${ARCHIVE##*/}"
 case "$X" in
*.tar.gz)  X="${X%.tar.gz}";  UNPACK="tar zxf" ;;
-   *.tar.bz2) X="${X%.tar.bz2}"; UNPACK="tar Ixf" ;;
+   *.tar.bz2) X="${X%.tar.bz2}"; UNPACK="tar --bzip2 -xf" ;;
*.tar.Z)   X="${X%.tar.Z}";   UNPACK="tar zxf" ;;
*.tgz) X="${X%.tgz}"; UNPACK="tar zxf" ;;
*.tar) X="${X%.tar}"; UNPACK="tar xf"  ;;


Bastian Kleineidam


pgprqVOBKNKm9.pgp
Description: PGP signature

Re: RFDisscusion: Big Packages.gz and Statistics and Comparing solution

[zhaoway]

[A quick reply. And thanks for discuss with me! And no need to Cc: me
anymore, I updated my DB info.]

On Sun, Jan 07, 2001 at 05:51:26PM +0100, Goswin Brederlow wrote:
> The problem is that people want to browse descriptions to find a
> package fairly often or just run "apt-cache show package" to see what
> a package is about. So you need a method to download all descriptions.

The big Packages.gz is still there. No conflict between the two method.
And the newest, most updated information is always on freshmeat.net. ;)

> As far as I see theres no server support needed for rsync support to
> operate better on compressed files.

Um, I don't know. But doesn't RSYNC need a server side RSYNC to run?
Or, can I expect a HTTP server to provide RSYNC? (Maybe I am stupid,
I'll read RSYNC man page, later.)

> If you update often, saving 1 Byte every time is worth it. If you
> update seldomely, it doesn't realy matter that you download a big
> Packages.gz. You would have to downlaod all the small Packages.gz
> files also.

There is an approach to help this. But that is another story. Later.

> So you see, between potato and woody diff saves about 60%.
> Also note that rsync usually performs better than cvs, since it does
> not include the to be removed lines in the download.

Pretty sounding argument. My only critic on DIFF or RSYNC now is just
server support now. (Again, I'll read RSYNC man page later. ;-)

The point is, can a storage server which provides merely HTTP and/or
FTP service do the job for apt-get?

-- 
echo < */
EOF

Configure error for lm-sensors (2.5.4-2)

[Svante Signell]

Setting up lm-sensors (2.5.4-2) ...
/sbin/MAKEDEV: major_ptym%d=2: command not found
/sbin/MAKEDEV: major_ptys%d=3: command not found
/sbin/MAKEDEV: major_tts%d=4: command not found
/sbin/MAKEDEV: major_cua%d=5: command not found
/sbin/MAKEDEV: major_pts%d=136: command not found

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[exa]

On Sun, Jan 07, 2001 at 11:36:24AM +0100, Martin Bialasinski wrote:
> You behaviour wrt bugs is more than lacking. You report something,
> without making a report that has enough relevant info to deal with it
> (read <[EMAIL PROTECTED]> again and understand it). When
> asked about specific info, you take it as an attack on your
> personality and spam debian-devel. Then you don't even give all the
> answers you were asked to give.
> 

Well, I will cc to debian-devel only when there is an affirmed conflict
with the developer about the bug report, OK?

And I have made substantial bug reports in the past, so I can't be said
to have a consistent history of false reports.

And some of the assessments of bug reports are truly personal insults.
For instance xfree86 maintainer's reassignment of the possibly unresolved
bug to gdm is full of offense.

> Your behaviour on this bugreport is a deja-vu of your behaviour on
> #80544.
> 

I think 80544 is a pretty valid bug. Have you been able to replicate
the bug and report upstream as I have suggested?

> You are more than annoying, and I am sick of it.
> 

Because I'm picky about bugs? I think we all need to be a bit picky
about bugs. I can understand why it might be desirable for a developer
to dismiss a bug; it takes less effort to do so. But then, only
valid dismissals should be allowed.

> If you want your glory peer review, subscribe to debian-bugs-dist and
> read every mail the BTS sends. I am sure your excelent bug analysis
> skills are greatly appreciated.
> 

Well, I guess I should.

I have developed a great liking for bug reports somehow.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[exa]

On Sun, Jan 07, 2001 at 11:57:08PM +1100, Hamish Moffatt wrote:
> Debian does not try to regulate the behaviour of its maintainers,
> except where the quality of the distribution itself is involved.
> What are your contributions to Debian Eray?

Non-regulation is a false claim. Maintainers are regulated in many ways;
including being confronted with bozos like the xfree86 maintainer.

What makes you think I haven't made any contributions?

orion:science$ ls ~/devel/debian/ | grep -e .*deb
insight_5.0-2_i386.deb
overkill-data_0.13-1_all.deb
overkill_0.13-1_i386.deb
sather-browser_1.2.1-2_i386.deb
sather-doc_1.2.1-2_all.deb
sather-lwp_1.2.1-2_i386.deb
sather-mode_1.2.1-2_all.deb
sather_1.2.1-2_i386.deb
sourcenav-doc_4.5.2-1_all.deb
sourcenav_4.5.2-1_i386.deb
tix41-dev_4.1.0.7-5_i386.deb
tix41_4.1.0.7-5_i386.deb
orion:science$ 

For now these are the concrete contributions. Plus a lot of bug reports, etc.

If the slow debian application process finalizes for me I'll be able to
do a lot more. [waiting for DAM approval, whenever that is supposed to
happen :(]

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Bug#81396: root shell fscked after upgrade to woody

[Paul Slootman]

On Sun 07 Jan 2001, Eray Ozkural wrote:
> 
> About having telnet enabled: everybody on the campus knows how to use telnet
> but would be very surprised I didn't let them connect easily from windows
> clients. For me, using telnet is of course a bit insecure but when I'm
> not able to use an ssh client... it's easier.

Search google for putty, if you need an ssh client for windows.


Paul Slootman
-- 
home:   [EMAIL PROTECTED] http://www.wurtel.demon.nl/
work:   [EMAIL PROTECTED]   http://www.murphy.nl/
debian: [EMAIL PROTECTED]  http://www.debian.org/
isdn4linux: [EMAIL PROTECTED]  http://www.isdn4linux.org/

[way OT] private emails

[Branden Robinson]

On Sat, Jan 06, 2001 at 06:26:24PM -0600, Bud Rogers wrote:
> It is spectacularly bad form to quote private email in a public forum,
> but it is not illegal.  And it is spectacularly naive to count on the
> privacy of anything you tell another human being in any medium,
> electronic or otherwise, unless that other human being is a doctor, a
> lawyer or a priest and thus bound by the ethics of their profession.

AIUI, communications with spouses are privileged as well.

Followups to debian-legal?  :)

-- 
G. Branden Robinson |   Optimists believe we live in the best of
Debian GNU/Linux|   all possible worlds.  Pessimists are
[EMAIL PROTECTED]  |   afraid the optimists are right.
http://www.debian.org/~branden/ |


pgpDaC5YNKLSC.pgp
Description: PGP signature

Re: Bug reports - copies to submitter

[Branden Robinson]

On Sun, Jan 07, 2001 at 11:25:37AM -0500, Bob Hilliard wrote:
>  This is probably in the documentation somewhere, but I haven't
> been able to find it.
> 
>  Which messages to the bug reporting system are automatically
> forwarded to the submitter, and which must be explicitly copied to
> [EMAIL PROTECTED]

As I understand it, *only* mail to -submitter and -done is seen by the
submitter.

-- 
G. Branden Robinson |  One man's "magic" is another man's
Debian GNU/Linux|  engineering.  "Supernatural" is a
[EMAIL PROTECTED]  |  null word.
http://www.debian.org/~branden/ |  -- Robert Heinlein


pgpHuDazyWwzK.pgp
Description: PGP signature

Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Nathan E Norman]

On Sun, Jan 07, 2001 at 11:42:57PM +1100, Hamish Moffatt wrote:
> On Sun, Jan 07, 2001 at 01:57:11AM -0600, Gordon Sadler wrote:
> > On Sun, Jan 07, 2001 at 01:14:40AM -0600, Nathan E Norman wrote:
> > > I apologize for prolonging this thread - it's quite annoying.
> > > However, after reading this enlightened response I wonder if it's
> > > possible for a user to close the (silly) bug he or she reported after
> > > he or she solves the problem.  bugs.debian.org doesn't seem to
> > > indicate a way for a bug to be closed other than action by the
> > > maintainer.
> > 
> > Actually under /usr/doc/debian the doc-debian package provides a number
> > of files, including bug-main-mailcontrol.txt.
> 
> Yes, but also anyone, including the submitter, spammers, joe public
> etc can email [EMAIL PROTECTED] to close a bug as well. The BTS doesn't care.

So does this mean the submitter can close their own bug or not?  I'm
not sure what you mean by "the BTS doesn't care"

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Inc. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgp62E0fSYvxi.pgp
Description: PGP signature

Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Samuel Hocevar]

On Sun, Jan 07, 2001, Nathan E Norman wrote:

> > Yes, but also anyone, including the submitter, spammers, joe public
> > etc can email [EMAIL PROTECTED] to close a bug as well. The BTS doesn't 
> > care.
> 
> So does this mean the submitter can close their own bug or not?  I'm
> not sure what you mean by "the BTS doesn't care"

   It means that anyone may close any bug. I think the maintainer would
easily notice abusers, so it's better to have it this way rather than
having complex authentication methods.

-- 
Sam.

Re: Configure error for lm-sensors (2.5.4-2)

[Martin Bialasinski]

* Svante Signell <[EMAIL PROTECTED]> wrote:

Hi,

[Some errors]

if it is a bug, use "reportbug" or "bug" to submit it to the
bug-tracking system.

If you can find out the cause, provide a patch. Thanks.

Ciao,
Martin

Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Mark Brown]

On Sun, Jan 07, 2001 at 01:09:12PM -0600, Nathan E Norman wrote:

> So does this mean the submitter can close their own bug or not?  I'm
> not sure what you mean by "the BTS doesn't care"

Anyone can close a bug - the BTS doesn't actually check where the close
command comes from.  The unenforced standard is that only the submitter
and the maintainer responsible for the package should close a bug.

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


pgpFdO3db8Wqq.pgp
Description: PGP signature

Solving the compression dilema when rsync-ing Debian versions

[Otto Wyss]

It's commonly agreed that compression does prevent rsync from profit of
older versions of packages when synchronizing Debian mirrors. All the
discussion about fixing rsync to solve this, even trough a deb-plugin is
IMHO not the right way. Rsync's task is to synchronize files without
knowing what's inside.

So why not solve the compression problem at the root? Why not try to
change the compression in a way so it does produce a compressed result
with the same (or similar) difference rate as the source? 

As my understanding of compression goes, all have a kind of lookup table
at the beginning where all compression codes where declared. Each time
this table is created new, each time slightly different than the
previous one depending on the source. So to get similar results when
compressing means using the same or at least an aquivalent lookup table.
If it would be possible to feed the lookup table of the previous
compressed file to the new compression process, an equal or at least
similar compression could be achieved. 

Of course using allways the same lookup table means a deceasing of the
compression rate. If there is an algorithmus which compares the old rate
with an optimal rate, even this could be solved. This means a completly
different compression from time to time. All depends how easy an
aquivalent lookup table could be created without loosing to much of the
compression rate.

O. Wyss

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Branden Robinson]

On Sat, Jan 06, 2001 at 08:34:31PM +0200, Eray Ozkural wrote:
> On Sat, Jan 06, 2001 at 12:01:42PM -0600, Steve Langasek wrote:
> > I don't know why you think your personal bug reports are so important
> > that they demand the attention of not only the package maintainer, but
> > *also* everyone subscribed to d-d, but please stop.
> 
> Only when I think it is important so that it requires the attention of more
> people or when there is a conflict with the maintainer. Taking into account
> the hostile and childish attitude of the maintainer, it is a very appropriate
> action I guess.

Ah, so you have a time machine which you used to tell your earlier self
that there was going to be trouble from me over bug 81397?

You CC'ed your *initial report* to debian-devel and debian-x, before I had
anything at all to say on the subject.

-- 
G. Branden Robinson |  One man's "magic" is another man's
Debian GNU/Linux|  engineering.  "Supernatural" is a
[EMAIL PROTECTED]  |  null word.
http://www.debian.org/~branden/ |  -- Robert Heinlein


pgpougBIN2OYf.pgp
Description: PGP signature

Re: dpkg-statoverride vs. suidmanager

[Wichert Akkerman]

Previously Joey Hess wrote:
> However, dpkg 1.8 implements dpkg-statoverride --import. We decided not
> to go that route, so why?

Because I got convinced that suidmanager is not capable to figure out
if something is an overide or a default. 

If we do decide to go that route and use the package==user|local
heuristic to check for overrides we still need to add a new step:
new packages not to unregister the statoverride that was imported from
suid.conf so it won't keep cluttering the db.

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: Configure error for lm-sensors (2.5.4-2)

[Bernd Eckenfels]

On Sun, Jan 07, 2001 at 07:46:09PM +0100, Svante Signell wrote:
> Setting up lm-sensors (2.5.4-2) ...
> /sbin/MAKEDEV: major_ptym%d=2: command not found
> /sbin/MAKEDEV: major_ptys%d=3: command not found
> /sbin/MAKEDEV: major_tts%d=4: command not found
> /sbin/MAKEDEV: major_cua%d=5: command not found
> /sbin/MAKEDEV: major_pts%d=136: command not found

It is a problem of makedev with devpts. I have already reported it. For now
you can ignore it. You may need to change /sbin/MAKEDEV:

search in line 147 for Character and change it to:
case "$major/$device" in
Character/*|Block/*|''/*|*/*%*)

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

Re: Solving the compression dilema when rsync-ing Debian versions

[Wichert Akkerman]

Previously Otto Wyss wrote:
> So why not solve the compression problem at the root? Why not try to
> change the compression in a way so it does produce a compressed result
> with the same (or similar) difference rate as the source? 

gzip --rsyncable, aloready implemented, ask Rusty Russell.

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 |

(open)ssh-2.3.0p1 when??

[Svante Signell]

Is openssh ever going to be upgraded? Latest unstable version is
2.2.0p1-1.1 from September? while the latest OpenBSD release is now
2.3.0p1! Maybe the package also should change name from ssh to openssh.

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Eray Ozkural \(exa\)]

Branden Robinson wrote:
> 
> Ah, so you have a time machine which you used to tell your earlier self
> that there was going to be trouble from me over bug 81397?
> 

No comments. :)

> You CC'ed your *initial report* to debian-devel and debian-x, before I had
> anything at all to say on the subject.

Yes, I did. At any rate, you didn't have to publicly insult me.

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: tar -I incompatibility

[Paul Eggert]

> Date: Sun, 7 Jan 2001 12:07:14 -0500
> From: Michael Stone <[EMAIL PROTECTED]>

> I certainly hope that the debian version at least prevents serious
> silent breakage by either reverting the change to -I and printing a
> message that the option is deprecated or removing the -I flag
> entirely.

Why would deprecating or removing the -I flag help prevent serious
silent breakage?  I would think that most people using -I in the
1.13.17 sense would use it like this:

tar -xIf archive.tar

and this silently breaks in 1.13.18 only in the unlikely case where
"f" is a readable tar file.

I'm not entirely opposed to deprecating -I for a while -- but I want
to know why it's helpful to do this before installing such a change.

Re: tar -I incompatibility

[Nicolás Lichtmaier]

> -  -j, --bzip2filter the archive through bzip2\n\
> +  -I, -j --bzip2 filter the archive through bzip2\n\

 If it's a deprecated option, don't document it in the online help. A note
in a COMPATIBILITY section in the manpage is more appropriate.

Re: IPv6 support in Debian

[Mark Baker]

On Wed, Jan 03, 2001 at 02:00:07PM +1100, Dancer Vesperman wrote:

> Certainly we have things like exim, lftp, ssh that work 'out of the box' 
> with v6...and apps that work with v6 work (equally) flawlessly in 
> v4-only environments.

That's not necessarily the case. There were lots of problems with the IPv6
support in exim breaking things for IPV4-only users, mostly in obscure cases
such as with subtly broken DNS. I believe they're all ironed out now, but
they caused a lot of problems.

Admittedly, very few things are as complicated as an MTA, and I wouldn't
expect any client software to break as a result of adding IPv4 support.

Re: Possible ITP: freebirth

[Matt Zimmerman]

On Fri, Jan 05, 2001 at 08:41:50AM -0500, Matt Zimmerman wrote:

> On Thu, Jan 04, 2001 at 10:04:55AM -0200, Eduardo Marcel Macan wrote:
> 
> > Yes, I've been in a packaging mood lately :)
> > 
> > I'd like to have Tk707 packaged. Tk707 is a software clone of the
> > Roland TR-707 rhythm composer, a drum machine.
> 
> Reading this reminded me of Freebirth, which doesn't seem to be packaged yet.
> 
> http://www.bitmechanic.com/projects/freebirth/
> 
> It seems to be dead upstream, with over a year since the last release, but it
> is quite usable.  Is anyone else interested in it?

A package is in Incoming now.

-- 
 - mdz

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Martin Bialasinski]

[ No need to Cc: me, I do read debian-devel ]

* Eray Ozkural (exa) <[EMAIL PROTECTED]> wrote:

> Well, I will cc to debian-devel only when there is an affirmed
> conflict with the developer about the bug report, OK?

>> Your behaviour on this bugreport is a deja-vu of your behaviour on
>> #80544.

> I think 80544 is a pretty valid bug.

It is a valid bug. Your initial report was useless and was lacking
information about the cause of the bug. So I asked you about specific
further details on the environment to find out when and why this
happens.

You took this as a personal attack and Cc: debian-devel where also
nobody could understand or figure out from your mails what the report
was about. And you denied me the info I was asking about.

And you call this "affirmed conflict with the developer about the bug
report"? Oh wait, you called it "your assessment of the bug is totally
wrong."

>> You are more than annoying, and I am sick of it.

> Because I'm picky about bugs?

No. Because your recent reports don't come close to the ones you sent
in even a half year ago. Your "bash is fscked up" report looks like
from some bloody beginner, not from a up-coming developer. You didn't
even try to find out what the cause was. You didn't even check the
bash manpage to see which startup files are processed. You didn't even
give such basic information like the shell used. Or at least you
didn't tell anything about what you did to find out about the cause.

It was a of "*whine*, it doesn't work" kind. You can do better than
that. Basically, you left anyone with guesswork. Your report was
useless. Take a another look at it.

And THEN you bitch around when people are annoyed about this.

Your breakage of privacy and netiquette is is another thing.

> Have you been able to replicate the bug 

I was able to work out by guessing and trying a szenario where this
bug happens and found the reason for it.

> and report upstream as I have suggested?

It was forwarded a day before your mail.

Everything is recorded in the BTS.

> I have developed a great liking for bug reports somehow.

Then you just need to develope some skill for a) analysing bugs and
writing useful reports and b) not going crazy when developers ask
further question if they don't have a cristal ball handy.

Martin

Re: (open)ssh-2.3.0p1 when??

[Damian M Gryski]

On Sun, 07 Jan 2001, Svante Signell wrote:
> Is openssh ever going to be upgraded? Latest unstable version is
> 2.2.0p1-1.1 from September? while the latest OpenBSD release is now
> 2.3.0p1! Maybe the package also should change name from ssh to openssh.

   openssh 2.3.0p1 was installed into unstable (sid) on Dec 30.  If you
   think you're tracking unstable, then you probably forgot to change
   the distribution from 'woody' to 'sid' in /etc/apt/sources.list for
   your non-us machine.

   Otherwise, wait another week and it should be moved into woody.

   HTH,

   Damian

-- 
Damian Gryski ==> [EMAIL PROTECTED] | Linux, the choice of a GNU generation
512 pt Hacker Test score = 37% | 500 pt Nerd Test score = 56%
   geek / linux zealot / coder / juggler

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Eray Ozkural \(exa\)]

Hi Martin,

please cc to me

Martin Bialasinski wrote:
> 
> > I have developed a great liking for bug reports somehow.
> 
> Then you just need to develope some skill for a) analysing bugs and
> writing useful reports and b) not going crazy when developers ask
> further question if they don't have a cristal ball handy.

When I have more time on my hands, the bug reports become more comprehensive.

Excuse me for being paranoid about bug reports, but some of the bug reports
are really being overlooked.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: [EMAIL PROTECTED]
www: http://www.cs.bilkent.edu.tr/~erayo

Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]

[Hamish Moffatt]

On Sun, Jan 07, 2001 at 01:09:12PM -0600, Nathan E Norman wrote:
> So does this mean the submitter can close their own bug or not?  I'm
> not sure what you mean by "the BTS doesn't care"

Yes, the BTS will allow the submitter to close their own bug that way.
So can anyone else. (AFAIK.)


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

Re: tar -I incompatibility

[Hamish Moffatt]

On Sun, Jan 07, 2001 at 07:21:29PM +0100, [EMAIL PROTECTED] wrote:
> I think the -I ==> -j change is not that bad.
> The only package I found using -I was devscripts' /usr/bin/uupdate.

The problem is not that it breaks our scripts -- it's
different for every end user of tar as well!

So if I'm used to using 'tar xIvf linux-2.4.0-test11.tar.bz2',
that no longer works. Instead it's 'tar xjvf ...' Which is no
better or worse than -I, except that it's different for reasons
which don't apply to Debian.


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

Re: Solving the compression dilema when rsync-ing Debian versions

[Sam Couter]

Otto Wyss <[EMAIL PROTECTED]> wrote:
> 
> So why not solve the compression problem at the root? Why not try to
> change the compression in a way so it does produce a compressed result
> with the same (or similar) difference rate as the source? 

Are you going to hack at *every* different kind of file format that you
might ever want to rsync, to make it rsync friendly?

Surely it makes more sense to make rsync able to more efficiently deal with
different formats easily.
-- 
Sam Couter  |   Internet Engineer   |   http://www.topic.com.au/
[EMAIL PROTECTED]|   tSA Consulting  |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


pgpy7IsSTN3dq.pgp
Description: PGP signature

Re: (open)ssh-2.3.0p1 when??

[Brian Frederick Kimball]

Damian M Gryski wrote:

> On Sun, 07 Jan 2001, Svante Signell wrote:
> > Is openssh ever going to be upgraded? Latest unstable version is
> > 2.2.0p1-1.1 from September? while the latest OpenBSD release is now
> > 2.3.0p1! Maybe the package also should change name from ssh to openssh.
> 
>openssh 2.3.0p1 was installed into unstable (sid) on Dec 30.

Just uploaded or actually installed?  It didn't show up on
non-us.debian.org until today (Jan 7th).

Re: tar -I incompatibility

[Sam Couter]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> 
>   Could you please name the other unices that behave identically
>  to solaris tar wrt the -I option? And which other unices even have
>  the -I option in tar?

My point is that the -I option *doesn't* mean "uncompress this file using
bzip2" for anything other than GNU tar. Now that it doesn't mean that for
GNU tar either, people are complaining. I think they probably shouldn't have
been using -I to start with, at least not as a matter of habit or in scripts
that might live for any decent length of time or have an application on any
non-GNU system.
-- 
Sam Couter  |   Internet Engineer   |   http://www.topic.com.au/
[EMAIL PROTECTED]|   tSA Consulting  |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C


pgpSPYMGYDdy5.pgp
Description: PGP signature

Re: Bug#81397: [authorization] fails silently for normal users, cannot start server

[Jason Henry Parker]

Eray Ozkural (exa) <[EMAIL PROTECTED]> writes:

> On Sun, Jan 07, 2001 at 11:36:24AM +0100, Martin Bialasinski wrote:
> > You behaviour wrt bugs is more than lacking. You report something,
> > without making a report that has enough relevant info to deal with it
> > (read <[EMAIL PROTECTED]> again and understand it). When
> > asked about specific info, you take it as an attack on your
> > personality and spam debian-devel. Then you don't even give all the
> > answers you were asked to give.
> And I have made substantial bug reports in the past, so I can't be said
> to have a consistent history of false reports.

That is not the claim that Martin made.

> And some of the assessments of bug reports are truly personal insults.
> For instance xfree86 maintainer's reassignment of the possibly unresolved
> bug to gdm is full of offense.

Oh, you've simply got to be joking.  You just agreed it was probably
not the X server's fault!

> I have developed a great liking for bug reports somehow.

*shudder*

jason
-- 
``Banks *are* bastards.'' -- John Laws

Re: Bug#81396: root shell fscked after upgrade to woody

[Colin Watson]

Paul Slootman <[EMAIL PROTECTED]> wrote:
>On Sun 07 Jan 2001, Eray Ozkural wrote:
>> About having telnet enabled: everybody on the campus knows how to use telnet
>> but would be very surprised I didn't let them connect easily from windows
>> clients. For me, using telnet is of course a bit insecure but when I'm
>> not able to use an ssh client... it's easier.
>
>Search google for putty, if you need an ssh client for windows.

http://www.chiark.greenend.org.uk/~sgtatham/putty/ (hmm, I appear to
have that memorized - I end up grabbing it any time I'm at a public
Windows-based Internet terminal).

For what it's worth, I discovered entirely by accident that if you
install telnetd-ssl then the telnet client in Windows 98 and above will
connect to it and seamlessly do SSL negotiation, while of course
non-SSL-capable telnet clients will still be able to connect insecurely.

-- 
Colin Watson [EMAIL PROTECTED]

Re: RFDisscusion: Big Packages.gz and Statistics and Comparing solution

[Goswin Brederlow]

> " " == zhaoway  <[EMAIL PROTECTED]> writes:

 > [A quick reply. And thanks for discuss with me! And no need to
 > Cc: me anymore, I updated my DB info.]

 > On Sun, Jan 07, 2001 at 05:51:26PM +0100, Goswin Brederlow
 > wrote:
>> The problem is that people want to browse descriptions to find
>> a package fairly often or just run "apt-cache show package" to
>> see what a package is about. So you need a method to download
>> all descriptions.

 > The big Packages.gz is still there. No conflict between the two
 > method.  And the newest, most updated information is always on
 > freshmeat.net. ;)

>> As far as I see theres no server support needed for rsync
>> support to operate better on compressed files.

 > Um, I don't know. But doesn't RSYNC need a server side RSYNC to
 > run?  Or, can I expect a HTTP server to provide RSYNC? (Maybe I
 > am stupid, I'll read RSYNC man page, later.)

Yes, eigther rsyncd or rshd/sshd needs to be running. But thats
already the case.

What I ment was that the new feature to uncompress archives before
rsyncing can (hoepfully) be done without any changes to existing
servers and without unpacking on the server side. All old servers
should do fine. Thats what I aim to archive.

>> If you update often, saving 1 Byte every time is worth it. If
>> you update seldomely, it doesn't realy matter that you download
>> a big Packages.gz. You would have to downlaod all the small
>> Packages.gz files also.

 > There is an approach to help this. But that is another
 > story. Later.

>> So you see, between potato and woody diff saves about 60%.
>> Also note that rsync usually performs better than cvs, since it
>> does not include the to be removed lines in the download.

 > Pretty sounding argument. My only critic on DIFF or RSYNC now
 > is just server support now. (Again, I'll read RSYNC man page
 > later. ;-)

 > The point is, can a storage server which provides merely HTTP
 > and/or FTP service do the job for apt-get?

Nope, but rsync servers already exist. Time to push people to convert
their services by pushing the users to use them.

Also think of the benefit when updating. With some extra code on the
client side (for example in apt) a pseudo deb can be created from the
installed version and then rsynced against the new version. You
wouldn't need a local mirror and you still save a lot of download.

Of cause this all needs support to rsync compressed archives
uncompressed in the rsync client.

MfG
Goswin

Re: (open)ssh-2.3.0p1 when??

[Christian Kurz]

On 01-01-07 Brian Frederick Kimball wrote:
> Damian M Gryski wrote:

> > On Sun, 07 Jan 2001, Svante Signell wrote:
> > > Is openssh ever going to be upgraded? Latest unstable version is
> > > 2.2.0p1-1.1 from September? while the latest OpenBSD release is now
> > > 2.3.0p1! Maybe the package also should change name from ssh to openssh.
> > 
> >openssh 2.3.0p1 was installed into unstable (sid) on Dec 30.

Huh? Where did you got this information? There was only an upload to
non-us on Dec 30.

> Just uploaded or actually installed?  It didn't show up on
> non-us.debian.org until today (Jan 7th).

I think the package should show up soon on non-us.

Ciao
 Christian
-- 
  Debian Developer and Quality Assurance Team Member
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853

Re: Bug#81396: root shell fscked after upgrade to woody

[Paul Slootman]

On Sun 07 Jan 2001, Colin Watson wrote:
> Paul Slootman <[EMAIL PROTECTED]> wrote:
> >
> >Search google for putty, if you need an ssh client for windows.
> 
> http://www.chiark.greenend.org.uk/~sgtatham/putty/ (hmm, I appear to
> have that memorized - I end up grabbing it any time I'm at a public
> Windows-based Internet terminal).

:-)

> For what it's worth, I discovered entirely by accident that if you
> install telnetd-ssl then the telnet client in Windows 98 and above will
> connect to it and seamlessly do SSL negotiation, while of course
> non-SSL-capable telnet clients will still be able to connect insecurely.

That's pretty amazing, I had no idea that something standard
in windows would have such features. Usually only by adding
all sorts of extras (such as putty) is windows capable of
doing anything remotely useful.


Paul Slootman
-- 
home:   [EMAIL PROTECTED] http://www.wurtel.demon.nl/
work:   [EMAIL PROTECTED]   http://www.murphy.nl/
debian: [EMAIL PROTECTED]  http://www.debian.org/
isdn4linux: [EMAIL PROTECTED]  http://www.isdn4linux.org/

apt maintainers dead?

[Goswin Brederlow]

Hi,

I tried to contact the apt maintainers about rsync support for
apt-get (a proof of concept was included) but haven't got an answere
back yet.

Is the whole team on vacation? Who is actually on that list?

>From the number of bugs open against apt-get I would think they are
all dead. Please proof me wrong.

MfG
Goswin