Re: RES: /usr/lib vs /usr/libexec

[Russ Allbery]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> The difference being that Debian has already split /usr from / and
>> therefore is only paying the marginal cost of maintaining it, whereas
>> Debian has not split /usr/lib from /usr/libexec and would have to pay
>> the (far larger) initial cost of moving everything around.

> It's a very easily spread cost.  Indeed, merely making it permissible
> for maintainers to use libexec when upstream does would be a help.

> You're not counting that there is a cost to each niggling little
> idiosyncracy where Debian differs from upstream.  Most of the cost of
> managing upgrades from upstream and the like is re-porting all those
> little niggling bits.

I don't personally care on /usr/lib vs. /usr/libexec, except that the idea
of going through and changing all the packages in Debian really doesn't
appeal to me (and however easily spread that cost, it's a lot of work --
it's more work than the /usr/doc migration, and that was a PITA).  I do
care a *lot* about consistency.  Having a mix of /usr/lib and /usr/libexec
is, in my opinion, significantly worse than either one or the other.

Yes, every divergence from upstream is more work.  That's why I believe
Debian should pick a standard and follow it rather than going our own
direction.  Consistency is extremely important, more important in my
opinion than following the layout of upstream -- that's one of the things
that makes Debian such a high-quality distribution.  However, we should at
least give upstream a fighting chance to already be doing things the way
we want.  The best chance we have of that is to use the most widely
adopted existing standard, and right now that's FHS, and FHS doesn't have
/usr/libexec.

That pretty much closes the conversation as far as I'm concerned (not that
I have any grand say or anything, just letting you know where I personally
come from).  If you got FHS changed to mandate /usr/libexec, I'd support
changing all of Debian to follow, even with the transition cost.  I would,
however, argue strongly against FHS saying that either one is allowed, for
the reason stated above.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: RES: /usr/lib vs /usr/libexec

[Anthony DeRobertis]

Thomas Bushnell BSG wrote:
I do believe you've missed the point.  Splitting /usr from / helps in
a teeny percentage of cases, and most of the cases where it "helps"
that have been mentioned here, it actually doesn't.
Well, I think it helps in the case of network mounting it; it is easier 
to mount a non-root FS than the root fs. Given this isn't a huge 
benefit, and isn't for a huge number of people either.

Personally, I don't have /usr on a different partition on any machine. 
No need for it.

Yet, splitting
/usr/lib, which is grotesquely huge and hard to deal with, is treated
as an impossible thing, needing a great level of proof before it can
be considered.  This is very foolish.
Well, I didn't ask for great levels of proof. I asked for /any/ proof. 
The /usr split has already been done; it'd be more work to re-merge /usr 
and / than it would be to leave it the way it is. The same can't be said 
for libexec.

We've been told that /usr is necessary to allow network sharing.  Of
course, you can network share any directory, not just /usr.  If you
want executables to be shared, then share /bin.  It's not a problem.
I've done it.
Sharing the root fs is possible via special kernel support or via 
initrd. /bin I guess is doable alone, but would require some nice initrd 
hacking.

We've been told that /usr is necessary because then you reduce the
chance that the system will be hosed from disk corruption.
This is, of course, BS; use a journaled file system for that. Either 
that, or make /home, /tmp, /var, etc. separate and then / will hardly 
ever be dirty, so it won't suffer corruption. You could even mount it ro.

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

Re: RES: /usr/lib vs /usr/libexec

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I do believe you've missed the point.  Splitting /usr from / helps in
> a teeny percentage of cases, and most of the cases where it "helps"
> that have been mentioned here, it actually doesn't.  Yet, splitting
> /usr/lib, which is grotesquely huge and hard to deal with, is treated
> as an impossible thing, needing a great level of proof before it can
> be considered.  This is very foolish.

Thats why we need proof that it helps. Nobody  has provided any numbers,
here.

> If you are against unnecessary things, then geez, you should be
> getting rid of nearly every separate directory.  

You missed the point. It is not about getting rid of directories it is about
creating a new one. And nobody has yet shown numbers which provide good
reasons to introduce the new dir (with all the hard work required for the
transition)

Gruss
Bernd


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

Re: RES: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> Thomas Bushnell BSG wrote:
>
>> I do believe you've missed the point.  Splitting /usr from / helps in
>> a teeny percentage of cases, and most of the cases where it "helps"
>> that have been mentioned here, it actually doesn't.
>
> Well, I think it helps in the case of network mounting it; it is
> easier to mount a non-root FS than the root fs. Given this isn't a
> huge benefit, and isn't for a huge number of people either.

You can mount /bin from the network on top of a boot-time /bin.  It's
very easy.  "mount foo:.../shared-bin /bin" or whatever the syntax is
for your filesystem type.

> Well, I didn't ask for great levels of proof. I asked for /any/
> proof. The /usr split has already been done; it'd be more work to
> re-merge /usr and / than it would be to leave it the way it is. The
> same can't be said for libexec.

Actually, the Hurd has shown it's trivial.  "ln -s / /usr" is really
sufficient.  Then you can phase things out over time.

> Sharing the root fs is possible via special kernel support or via
> initrd. /bin I guess is doable alone, but would require some nice
> initrd hacking.

No hacking is necessary.  Sharing / is a bad idea, but sharing any
subdirectory is trivial.


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

Re: RES: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Russ Allbery <[EMAIL PROTECTED]> writes:

> The difference being that Debian has already split /usr from / and
> therefore is only paying the marginal cost of maintaining it, whereas
> Debian has not split /usr/lib from /usr/libexec and would have to pay the
> (far larger) initial cost of moving everything around.

It's a very easily spread cost.  Indeed, merely making it permissible
for maintainers to use libexec when upstream does would be a help.

You're not counting that there is a cost to each niggling little
idiosyncracy where Debian differs from upstream.  Most of the cost of
managing upgrades from upstream and the like is re-porting all those
little niggling bits.


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

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>2. change the /etc/apt/sources.list to point to "stable"

I wish all documentation is using the distribution names not the symbolic
names. If you put "stable" in a file this will cause major trouble a few
years later. Beside it is unclear to the reader when you have written the
text and which stable you mean. (I think you mean sarge?)

Gruss
Bernd


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

Re: RES: /usr/lib vs /usr/libexec

[Russ Allbery]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> I do believe you've missed the point.  Splitting /usr from / helps in a
> teeny percentage of cases, and most of the cases where it "helps" that
> have been mentioned here, it actually doesn't.  Yet, splitting /usr/lib,
> which is grotesquely huge and hard to deal with, is treated as an
> impossible thing, needing a great level of proof before it can be
> considered.  This is very foolish.

The difference being that Debian has already split /usr from / and
therefore is only paying the marginal cost of maintaining it, whereas
Debian has not split /usr/lib from /usr/libexec and would have to pay the
(far larger) initial cost of moving everything around.

I think it's quite reasonable for that far larger initial cost to require
substantial justification, far more justification than is required for
preserving a property that Debian has already paid the cost to establish
and is just maintaining.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: RES: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

> On May 13, 2005, at 11:28, Humberto Massa GuimarÃes wrote:
>>
>> You said it yourself. Even if your 256MB machine were typical (it's
>> not), the less cache memory you use to cache dentries of /usr/lib,
>> the better (more memory for your apps, or to cache other, more
>> useful stuff).
>
> If you suspect that separating /usr/lib into multiple directories
> will improve performance, please bring reasonable benchmarks, not
> speculation.

I do believe you've missed the point.  Splitting /usr from / helps in
a teeny percentage of cases, and most of the cases where it "helps"
that have been mentioned here, it actually doesn't.  Yet, splitting
/usr/lib, which is grotesquely huge and hard to deal with, is treated
as an impossible thing, needing a great level of proof before it can
be considered.  This is very foolish.

We've been told that /usr is necessary so that the boot partition can
be small.  Of course, the boot loaders generally don't care, and for
the small minority of cases where they do, make a separate /boot
partition.

We've been told that /usr is necessary to allow network sharing.  Of
course, you can network share any directory, not just /usr.  If you
want executables to be shared, then share /bin.  It's not a problem.
I've done it.

We've been told that /usr is necessary because then you reduce the
chance that the system will be hosed from disk corruption.  Of course,
it might seem that the chance of hosage actually now doubles, because
if either of two filesystems die, your system is unusable.  It's also
been suggested that if /usr breaks and / doesn't you can helpfully
repair /usr.  Of course, you can still repair /: you should use a boot
CD, or a repair partition you've set up for that purpose.  This is far
better than setting up / as a double-duty repair partition and live
filesystem.  If you want reliability, this is a very bad way to get
it.

Now if you want /usr, go to it; but it's insane to say that /usr is a
great thing, supported by very weak arguments and nothing so much as
mindless inertia, while libexec is a foolish and pointless thing.

If you are against unnecessary things, then geez, you should be
getting rid of nearly every separate directory.  

Thomas

Re: [Fwd: RFS: eaccelerator - PHP script cacher]

[Roberto C. Sanchez]

Jonathan Oxer wrote:
> On Thu, 2005-05-12 at 12:07 -0400, Roberto C. Sanchez wrote:
> 
>>Quoting Florian Weimer <[EMAIL PROTECTED]>:
>>
>>
>>>* Roberto C. Sanchez:
>>>
>>>
I forwarding this to d-d since after a couple of days I
still have no response from anyone on d-m willing to sponsor
this package.
>>>
>>>Please have a look at the following discussions:
>>>
>>>
>>>
>>
>>Thanks.  I was not aware.  Is there a problem with me providing the 
>>eAccelerator
>>packages?
> 
> 
> Yes, it's a problem. This has been a long ongoing debate originally
> among Turck-mmcache users (I'm the turck-mmcache maintainer) and now
> among eAccelerator users / developers (I've also created eAccelerator
> packages, but I haven't submitted them to the archive because the legal
> situation needs to be resolved first).
> 
OK.  I have removed the packages so they are no longer available from
my website.
> In fact there are now two problems with eAccelerator. The first problem
> which was carried over from Turck-mmcache was the GPL/PHP licence
> linking problem, and now there is also possibly a copyright problem
> because when the project was forked the new developers simply removed
> all the Turcksoft copyrights and added their own.
> 
This is lamentable.  It would be tragic if such an excelent piece of
free software were lost because of what amounts to carelessness.

> 
>>I am not distributing PHP at all, and I also have the eAccelerator
>>source available with the binary.
> 
> 
> Unfortunately that doesn't solve the problem because it would mean
> distributing binaries that have been linked against PHP, which has a
> GPL-incompatible licence.
> 
I see.

> One of the suggestions a long time ago was to replace the Turck-mmcache
> package with a 'loader' package that grabbed the source tarball and
> built it on the target machine, but I resisted that idea because it
> would require the target machine to have all sorts of things installed
> including a compiler, the C dev libs, the PHP source, and a bunch of
> other things that wouldn't typically exist on a deployment server. It
> would also be a rather jarring experience for the admin, with a package
> install taking quite a few minutes and chewing up all the CPU time
> rather than the fractions of a second required to install a binary
> package. It would technically work and it would be legal, but it would
> be a very ugly kludge.
> 
I agree.  Personally, I like to keep my servers as light as possible.
Development tools add quite a bit to the foot print and open the door
to the possibility of rootkits that make use of a compiler.

> 
>>I really hope that this is worked out.
> 
> 
> So do I. I've had a brief informal chat to Jeremy Malcolm of iLaw (who
> also happens to be Linux Australia's legal counsel) about the situation
> and I'll probably follow this up with him in a more formal way when I
> get a chance. I'm happy to pay the $$$ to get formal legal advice on
> this issue if it helps resolve things.
> 
> The primary issue to resolve is the ownership of the codebase so that it
> can be re-licenced. At present the copyright of Turck-mmache resides
> with Turcksoft, a Russian company that now seems to be out of business.
> As a result there's no-one to re-licence the code to LGPL or similar,
> which would then make binaries built against PHP legal to distribute.
> 
I hope that this happens soon.  :-)

> Cheers   :-)
> 
> Jonathan Oxer

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


signature.asc
Description: OpenPGP digital signature

Re: [Fwd: RFS: eaccelerator - PHP script cacher]

[Jonathan Oxer]

On Thu, 2005-05-12 at 12:07 -0400, Roberto C. Sanchez wrote:
> Quoting Florian Weimer <[EMAIL PROTECTED]>:
> 
> > * Roberto C. Sanchez:
> >
> >> I forwarding this to d-d since after a couple of days I
> >> still have no response from anyone on d-m willing to sponsor
> >> this package.
> >
> > Please have a look at the following discussions:
> >
> > 
> > 
> 
> Thanks.  I was not aware.  Is there a problem with me providing the 
> eAccelerator
> packages?

Yes, it's a problem. This has been a long ongoing debate originally
among Turck-mmcache users (I'm the turck-mmcache maintainer) and now
among eAccelerator users / developers (I've also created eAccelerator
packages, but I haven't submitted them to the archive because the legal
situation needs to be resolved first).

In fact there are now two problems with eAccelerator. The first problem
which was carried over from Turck-mmcache was the GPL/PHP licence
linking problem, and now there is also possibly a copyright problem
because when the project was forked the new developers simply removed
all the Turcksoft copyrights and added their own.

> I am not distributing PHP at all, and I also have the eAccelerator
> source available with the binary.

Unfortunately that doesn't solve the problem because it would mean
distributing binaries that have been linked against PHP, which has a
GPL-incompatible licence.

One of the suggestions a long time ago was to replace the Turck-mmcache
package with a 'loader' package that grabbed the source tarball and
built it on the target machine, but I resisted that idea because it
would require the target machine to have all sorts of things installed
including a compiler, the C dev libs, the PHP source, and a bunch of
other things that wouldn't typically exist on a deployment server. It
would also be a rather jarring experience for the admin, with a package
install taking quite a few minutes and chewing up all the CPU time
rather than the fractions of a second required to install a binary
package. It would technically work and it would be legal, but it would
be a very ugly kludge.

> I really hope that this is worked out.

So do I. I've had a brief informal chat to Jeremy Malcolm of iLaw (who
also happens to be Linux Australia's legal counsel) about the situation
and I'll probably follow this up with him in a more formal way when I
get a chance. I'm happy to pay the $$$ to get formal legal advice on
this issue if it helps resolve things.

The primary issue to resolve is the ownership of the codebase so that it
can be re-licenced. At present the copyright of Turck-mmache resides
with Turcksoft, a Russian company that now seems to be out of business.
As a result there's no-one to re-licence the code to LGPL or similar,
which would then make binaries built against PHP legal to distribute.

Cheers   :-)

Jonathan Oxer
-- 
The Debian Universe: Installing, managing and using Debian GNU/Linux
http://www.debianuniverse.com/


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

Re: need help on #271678 (sizefo struct?)

[Ben Pfaff]

[EMAIL PROTECTED] (Vincent Zweije) writes:

> On Mon, May 16, 2005 at 12:06:37PM +0200, Bernd Eckenfels wrote:
>
> ||  In article <[EMAIL PROTECTED]> you wrote:
>
> ||  {
> ||struct x25_route_struct rt;
> ||struct sockaddr_x25 sx25;
> ||  ...
> ||memset((char *) &rt, 0, sizeof(struct x25_route_struct));
>
>   memset((char *) &rt, 0, sizeof rt);

The cast is unnecessary:
memset(&rt, 0, sizeof rt);
-- 
"A computer is a state machine.
 Threads are for people who cant [sic] program state machines."
--Alan Cox


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

Re: packages missing from sarge

[Anthony DeRobertis]

On May 15, 2005, at 22:16, Steve Langasek wrote:
Still, the concerns about re-adding this software version (which  
has been
out of testing for months) via t-p-u remain.
Its hard to see it being any worse than freeswan, which has been  
abandoned for a while by its upstream. And if it turns out to be a  
problem, it could just be removed again, right?

racoon doesn't have all the features that freeswan and openswan have;  
not sure about isakmpd and pipsecd.

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

Re: RES: /usr/lib vs /usr/libexec

[Anthony DeRobertis]

On May 13, 2005, at 11:28, Humberto Massa Guimarães wrote:
You said it yourself. Even if your 256MB machine were typical (it's  
not), the less cache memory you use to cache dentries of /usr/lib,  
the better (more memory for your apps, or to cache other, more  
useful stuff).
If you suspect that separating /usr/lib into multiple directories  
will improve performance, please bring reasonable benchmarks, not  
speculation.

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Adrian Bunk]

On Mon, May 16, 2005 at 08:12:04PM +0200, Adrian Bunk wrote:
> On Mon, May 16, 2005 at 07:44:37PM +0200, Adeodato Simó wrote:
>...
> >   Note that in (4), the command is aptitude, not apt-get.
> 
> Does this make any difference?
>...

It does.

My fault, I confused (4) with (3).

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: removing ipfwadm

[Marco d'Itri]

On May 16, Adam McKenna <[EMAIL PROTECTED]> wrote:

> I am not sure whether the ipfwadm package should be removed.  Kernels up to
> 2.4 still have support for ipfwadm filtering rules, so theoretically people
> could still be using it with current kernels.
Wait until sarge has been released and then kill it.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Message from repair@core.com

[Repair]

Thank you for contacting the CoreComm online Residential Customer 
Care Repair Department! We have received your message and a 
Customer Care Representative will be responding to you within the 
next 48-72 business hours.

In the meantime, please feel free to visit our repair 
troubleshooting site, for basic problem resolution:

http://www.core.com/repair

Thank you for choosing CoreComm.


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

Bug#309371: ITP: python-pysqlite2 -- python interface to SQLite

[Joel Rosdahl]

Package: wnpp
Severity: wishlist

I intend to package PySQLite 2. It will happily coexist with the
current python-sqlite package, which has another API.

URL:

http://pysqlite.org

Description:

pysqlite a DB-API 2.0-compliant database interface for SQLite.

SQLite is a relational database management system contained in a
relatively small C library. It is a public domain project created
by D. Richard Hipp. Unlike the usual client-server paradigm, the
SQLite engine is not a standalone process with which the program
communicates, but is linked in and thus becomes an integral part
of the program. The library implements most of SQL-92 standard,
including transactions, triggers and most of complex queries.

pysqlite makes this powerful embedded SQL engine available to
Python programmers. It stays compatible with the Python database
API specification 2.0 as much as possible, but also exposes most
of SQLite's native API, so that it is for example possible to
create user-defined SQL functions and aggregates in Python.

If you need a relational database for your applications, or even
small tools or helper scripts, pysqlite is often a good fit. It's
easy to use, easy to deploy, and does not depend on any other
Python libraries or platform libraries, except SQLite. SQLite
itself is ported to most platforms you'd ever care about.

It's often a good alternative to MySQL, the Microsoft JET engine
or the MSDE, without having any of their license and deployment
issues.

License:

Copyright (c) 2004 Gerhard Häring

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any
damages arising from the use of this software.

Permission is granted to anyone to use this software for any
purpose, including commercial applications, and to alter it and
redistribute it freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you
   must not claim that you wrote the original software. If you
   use this software in a product, an acknowledgment in the
   product documentation would be appreciated but is not
   required.

2. Altered source versions must be plainly marked as such, and
   must not be misrepresented as being the original software.

3. This notice may not be removed or altered from any source
   distribution.

-- 
Joel Rosdahl <[EMAIL PROTECTED]>
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97

Re: removing ipfwadm

[Adrian Bunk]

On Mon, May 16, 2005 at 09:49:01AM -0700, Adam McKenna wrote:

> I am not sure whether the ipfwadm package should be removed.  Kernels up to
> 2.4 still have support for ipfwadm filtering rules, so theoretically people
> could still be using it with current kernels.
> 
> cc'ing debian-devel.  If the consensus there is that the package should be
> removed, I'll request its removal.

_All_ kernel versions in sarge support ipfwadm.

Not that I expect many people to use it, but I don't see a good reason 
for removing it.

> --Adam

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Receive your medications overnight DISCREETLY

[Linwood Russo]

100 Assorted Life Fixers 
http://www.q67.net/ph/coupon/patbeile   


Hate recieving these msgs q67.netf.php

He would, wouldn't he? 

removing ipfwadm

[Adam McKenna]

I am not sure whether the ipfwadm package should be removed.  Kernels up to
2.4 still have support for ipfwadm filtering rules, so theoretically people
could still be using it with current kernels.

cc'ing debian-devel.  If the consensus there is that the package should be
removed, I'll request its removal.

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


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

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Kurt Roeckx]

On Mon, May 16, 2005 at 07:44:37PM +0200, Adeodato Simó wrote:
> 
> 1. apt-get install aptitude
> 2. change the /etc/apt/sources.list to point to "stable"
> 3. aptitude update
> 4. aptitude install aptitude dpkg
> 5. aptitude -f --with-recommends dist-upgrade

0. change the /etc/apt/sources.list to point to "woody" ?


Kurt


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

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Adrian Bunk]

On Mon, May 16, 2005 at 07:44:37PM +0200, Adeodato Simó wrote:
> * Adrian Bunk [Mon, 16 May 2005 18:14:20 +0200]:
> > On Mon, May 16, 2005 at 05:58:24PM +0200, Frans Pop wrote:
> 
> > > The current version of the release notes tells users to (simplified):
> > > 1. apt-get install aptitude
> > > 2. change the /etc/apt/sources.list to point to "stable"
> > > 3. aptitude update
> > > 4. aptitude -f --with-recommends dist-upgrade
> 
> > > Therefore the question if it would be better to change the procedure to:
> > > 1. change the /etc/apt/sources.list to point to "stable"
> > > 2. apt-get update
> > > 3. apt-get install aptitude dpkg
> > > 4. aptitude -f --with-recommends dist-upgrade
> 
> > OTOH, at least in the woody installation I tried this,
> > "aptitude -f --with-recommends dist-upgrade" works fine.
> 
> > It seems aptitude in woody has a better Conflicts handling than apt in 
> > woody making the first step easier for users.
> 
>   So, to make that clear, you're proposing the following:
>...

I'm not proposing anything since I don't know enough about these issues 
for giving any recommendation.

All I said was that the way you proposed seems to be worse than the 
currently documented way (at least in my test cases).

>   Note that in (4), the command is aptitude, not apt-get.

Does this make any difference?

>   BTW, why "change sources.list to point to 'stable'" instead of
>   'sarge'? Probably there'll be a reason I'll love to here, but all are
>   disadvantages to me, e.g.:
>...

I'd agree that "stable" is a bad choice since this will lead to people 
accidentially upgrading to etch (without reading the etch release notes 
telling them how to do it best).

>   Cheers,
> Adeodato Simó

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Adeodato Simó]

* Adrian Bunk [Mon, 16 May 2005 18:14:20 +0200]:
> On Mon, May 16, 2005 at 05:58:24PM +0200, Frans Pop wrote:

> > The current version of the release notes tells users to (simplified):
> > 1. apt-get install aptitude
> > 2. change the /etc/apt/sources.list to point to "stable"
> > 3. aptitude update
> > 4. aptitude -f --with-recommends dist-upgrade

> > Therefore the question if it would be better to change the procedure to:
> > 1. change the /etc/apt/sources.list to point to "stable"
> > 2. apt-get update
> > 3. apt-get install aptitude dpkg
> > 4. aptitude -f --with-recommends dist-upgrade

> OTOH, at least in the woody installation I tried this,
> "aptitude -f --with-recommends dist-upgrade" works fine.

> It seems aptitude in woody has a better Conflicts handling than apt in 
> woody making the first step easier for users.

  So, to make that clear, you're proposing the following:

1. apt-get install aptitude
2. change the /etc/apt/sources.list to point to "stable"
3. aptitude update
4. aptitude install aptitude dpkg
5. aptitude -f --with-recommends dist-upgrade

  Note that in (4), the command is aptitude, not apt-get.

  BTW, why "change sources.list to point to 'stable'" instead of
  'sarge'? Probably there'll be a reason I'll love to here, but all are
  disadvantages to me, e.g.:

> > Step 1. is meant to install the Woody version of aptitude, but of course
> > it will not if the sources.list already points to "stable" and the user
> > has already done an 'apt-get update'.

  OTOH, if the original sources.list contains 'woody' and the
  instructions say to change it to 'sarge', the above does not happen,
  _plus_ the release notes work for upgrades to testing prior to
  release.

  Cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
One way to make your old car run better is to look up the price of a new model.


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

Best Buy - Rolex Replicas

[Lily]

Replica Rolex Swiss Watches
http://coders.q67.net/rolex/vron/collided.html
Wishlist : Rolex or Cartier or Breitling

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

Re: packages missing from sarge

[Darren Salt]

I demand that Steve Langasek may or may not have written...

> On Sat, May 14, 2005 at 05:44:33PM -0400, François-Denis Gonthier wrote:
>> On May 7, 2005 09:03 pm, Joey Hess wrote:
>>> erlang
>> Erlang and the related erlang-manpages and erlang-doc-html are being put
>> up-to-date by me.  I have a package ready which should be uploaded by my
>> sponsor in the coming week.
>> I guess that means that the package that reverse depends on Erlang would
>> also be allowed back on:

> No, this is a package that was not in woody, so it's going to be too late
> to get it (and its reverse-deps) into sarge.  The release team is not going
> to spend its time hand-holding packages that were nowhere near releasable
> at the time of freeze when there are still 50+ RC bugs that need to be
> fixed before we release.

gxine? Possibility of 0.4.4 in sarge? There are bugs other than the RC bug
(in the Debian BTS) which really should be fixed in unstable, preferably
(IMO) by uploading 0.4.4 - I suggest that you use the packaging in
http://zap.tartarus.org/~ds/debian/> as a starting point.

Any changes which you don't think should go into sarge - tell me and I'll
(probably) tell you why it should :-)

(It's probably still safe to assume that the maintainer doesn't have enough
time to prepare and upload the package.)

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Say NO to software patents

Be happy with the real pleasures in life.


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

Re: [Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Adrian Bunk]

On Mon, May 16, 2005 at 05:58:24PM +0200, Frans Pop wrote:
> Short version:
> Should users first upgrade dpkg and aptitude before upgrading the rest of 
> the system or can the upgrade safely be done using Woody's version of the 
> package tools?
> 
> Long version:
> The current version of the release notes tells users to (simplified):
> 1. apt-get install aptitude
> 2. change the /etc/apt/sources.list to point to "stable"
> 3. aptitude update
> 4. aptitude -f --with-recommends dist-upgrade
> 
> Step 1. is meant to install the Woody version of aptitude, but of course 
> it will not if the sources.list already points to "stable" and the user 
> has already done an 'apt-get update'.
> 
> There have of course been improvements in Sarges version of aptitude. Also 
> I wonder if upgrading the packaging tools as part of the dist-upgrade 
> could in itself be a source of problems.
> 
> Therefore the question if it would be better to change the procedure to:
> 1. change the /etc/apt/sources.list to point to "stable"
> 2. apt-get update
> 3. apt-get install aptitude dpkg
> 4. aptitude -f --with-recommends dist-upgrade
> ???
> 
> I have done an upgrade myself a while back using the second method [1] and 
> noticed:
> - 'apt-get install aptitude' does _not_ upgrade dpkg automatically;
>   as it seemed to me better to have all package tools from the same
>   version, I upgraded both aptitude and dpkg before continuing with the
>   rest of the upgrade;
> - in my test upgrading aptitude and dpkg also upgraded the following:
> apt apt-utils aptitude debconf debconf-utils debhelper dpkg dpkg-dev 
> libc6 libc6-dev libdbd-mysql-perl libdbi-perl libgcc1 libncurses5 
> libncurses5-dev libpopt0 locales perl perl-base perl-modules whiptail 
> zlib1g
>   and installed:
> debconf-i18n dselect gcc-3.3-base gettext intltool-debian
> libdb1-compat libdb4.2 libgdbm3 liblocale-gettext-perl
> libnet-daemon-perl libnewt0.51 libplrpc-perl libsigc++-1.2-5c102
> libstdc++5 libtext-charwidth-perl libtext-iconv-perl
> libtext-wrapi18n-perl linux-kernel-headers po-debconf slang1a-utf8
>   I understand that for some arches (hppa) this may necessitate upgrading
>   the kernel first.
> 
> Comments very, very welcome.

<--  snip  -->

# apt-get install aptitude dpkg
...
The following packages will be REMOVED:
  cyrus-imapd wine 
...
[answer n]
# apt-get install aptitude dpkg cyrus-imapd wine
...
The following packages will be REMOVED:
  autoconf2.13 
...
[answer n]
# apt-get install aptitude dpkg cyrus-imapd wine autoconf2.13 
...
[nothing to be removed]

<--  snip  -->


OTOH, at least in the woody installation I tried this,
"aptitude -f --with-recommends dist-upgrade" works fine.


It seems aptitude in woody has a better Conflicts handling than apt in 
woody making the first step easier for users.


> Cheers,
> Frans Pop
> 
> [1] http://lists.debian.org/debian-release/2004/11/msg00105.html

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

[Release Notes] Use Woody's or Sarge's aptitude for upgrades?

[Frans Pop]

Short version:
Should users first upgrade dpkg and aptitude before upgrading the rest of 
the system or can the upgrade safely be done using Woody's version of the 
package tools?

Long version:
The current version of the release notes tells users to (simplified):
1. apt-get install aptitude
2. change the /etc/apt/sources.list to point to "stable"
3. aptitude update
4. aptitude -f --with-recommends dist-upgrade

Step 1. is meant to install the Woody version of aptitude, but of course 
it will not if the sources.list already points to "stable" and the user 
has already done an 'apt-get update'.

There have of course been improvements in Sarges version of aptitude. Also 
I wonder if upgrading the packaging tools as part of the dist-upgrade 
could in itself be a source of problems.

Therefore the question if it would be better to change the procedure to:
1. change the /etc/apt/sources.list to point to "stable"
2. apt-get update
3. apt-get install aptitude dpkg
4. aptitude -f --with-recommends dist-upgrade
???

I have done an upgrade myself a while back using the second method [1] and 
noticed:
- 'apt-get install aptitude' does _not_ upgrade dpkg automatically;
  as it seemed to me better to have all package tools from the same
  version, I upgraded both aptitude and dpkg before continuing with the
  rest of the upgrade;
- in my test upgrading aptitude and dpkg also upgraded the following:
apt apt-utils aptitude debconf debconf-utils debhelper dpkg dpkg-dev 
libc6 libc6-dev libdbd-mysql-perl libdbi-perl libgcc1 libncurses5 
libncurses5-dev libpopt0 locales perl perl-base perl-modules whiptail 
zlib1g
  and installed:
debconf-i18n dselect gcc-3.3-base gettext intltool-debian
libdb1-compat libdb4.2 libgdbm3 liblocale-gettext-perl
libnet-daemon-perl libnewt0.51 libplrpc-perl libsigc++-1.2-5c102
libstdc++5 libtext-charwidth-perl libtext-iconv-perl
libtext-wrapi18n-perl linux-kernel-headers po-debconf slang1a-utf8
  I understand that for some arches (hppa) this may necessitate upgrading
  the kernel first.

Comments very, very welcome.

Cheers,
Frans Pop

[1] http://lists.debian.org/debian-release/2004/11/msg00105.html


pgpF555xdnwJg.pgp
Description: PGP signature

Re: need help on #271678 (sizefo struct?)

[Russ Allbery]

Vincent Zweije <[EMAIL PROTECTED]> writes:

> If you happen to have a variable (or field or in fact any expression)
> of that type (either type "struct x25_address" or type "x25_address"),
> then you can take the size of the variable, instead of the size of the
> type. So you can do:

> memcpy(&rt.address, &sx25.sx25_addr, sizeof sx25.sx25_addr);

> This will work with either definition of sx25_address.

D'oh, yes, very good point.  That's the clearly better way of doing this;
I got too caught up in the wrong approach.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Debian Woody -> Sarge upgrade report

[Roberto C. Sanchez]

Quoting Jonathan McDowell <[EMAIL PROTECTED]>:
On Mon, May 16, 2005 at 09:27:23AM -0400, Roberto C. Sanchez wrote:
Jonathan McDowell wrote:
> H. I run with my own CA signed cert and had no problems with a
> Woody -> Sarge upgrade of sslwrap on Friday. Can you send me your
> /etc/sslwrap/debian_conf and the output of
> "grep sslwrap /etc/inetd.conf" (assuming you're running it from inetd)?
Did you want to see what they looked like before or after the upgrade?
Both, if possible. Whatever you've got easily would be a good start
though.
J.
** BEGIN BEFORE **
# grep sslwrap inetd.conf
ssmtp   stream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/sslwrap  -cert
/etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 25
imaps   stream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/sslwrap  -cert
/etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 143
/etc/sslwrap/debian_config:
run_mode="inetd"
used_addr="127.0.0.1"
with_certificate="true"
certfile="/etc/ssl/server_key_and_cert.pem"
overwrite_corrupted_certfile="false"
check_cert="true"
ports="imaps, ssmtp"
*** END BEFORE ***
** BEGIN AFTER **
# grep sslwrap inetd.conf
ssmtp   stream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/sslwrap  -cert
/etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 25
imaps   stream  tcp nowait  root/usr/sbin/tcpd  /usr/sbin/sslwrap  -cert
/etc/ssl/server_key_and_cert.pem -addr 127.0.0.1 -port 143
/etc/sslwrap/debian_config:
run_mode="inetd"
used_addr="127.0.0.1"
with_certificate="true"
certfile="/etc/ssl/server_key_and_cert.pem"
overwrite_corrupted_certfile="false"
check_cert="true"
ports="imaps, ssmtp"
*** END AFTER ***
I no longer have sslwrap installed since postfix-tls now properly grabs port
465 without dying and cyrus21 supports imaps (though last night I switched
to courier, which also natively does imaps).  The problem, if you refer to my
original mail, is that something about the CA was confusing sslwrap, which
I believe tried to generate its own cert.
-Roberto
--
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Thanks for your email

[bhewitt]

Thank you for your comments!

Brian Hewitt
The Golf Channel


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

Re: Debian Woody -> Sarge upgrade report

[Jonathan McDowell]

On Mon, May 16, 2005 at 09:27:23AM -0400, Roberto C. Sanchez wrote:
> Jonathan McDowell wrote:
> > H. I run with my own CA signed cert and had no problems with a
> > Woody -> Sarge upgrade of sslwrap on Friday. Can you send me your
> > /etc/sslwrap/debian_conf and the output of
> > "grep sslwrap /etc/inetd.conf" (assuming you're running it from inetd)?
> Did you want to see what they looked like before or after the upgrade?

Both, if possible. Whatever you've got easily would be a good start
though.

J.

-- 
Web [ I don't bite. Well, that's wrong. I do bite. ]
site: http:// [  ]   Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.23


signature.asc
Description: Digital signature

Re: Debian Woody -> Sarge upgrade report

[Roberto C. Sanchez]

Jonathan McDowell wrote:
> H. I run with my own CA signed cert and had no problems with a
> Woody -> Sarge upgrade of sslwrap on Friday. Can you send me your
> /etc/sslwrap/debian_conf and the output of
> "grep sslwrap /etc/inetd.conf" (assuming you're running it from inetd)?
> 
> J.
> 

Did you want to see what they looked like before or after the upgrade?

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~sanchezr


signature.asc
Description: OpenPGP digital signature

Re:60 Jahre Befreiung: Wer feiert mit?

[Sophie & Luc Briand]

Merci de me supprimer de cette mail-liste

Le 15 mai 05 à 18:34, debian-devel@lists.debian.org a écrit :
http://www.unserforum.com/aff/include.php?path=content/ 
content.php&contentid=149

http://www.unserforum.com/aff/include.php?path=content/ 
content.php&contentid=54

http://www.unserforum.com/aff/include.php?path=content/ 
content.php&contentid=55

http://www.unserforum.com/aff/include.php?path=content/ 
content.php&contentid=56

Get latest version, cds and download under $99

[Septimus]

Do not have money , get software cds from here!
http://liztu.ipmflhitfs0pxji.turuntale.com

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

Re: need help on #271678 (sizefo struct?)

[Vincent Zweije]

On Mon, May 16, 2005 at 12:06:37PM +0200, Bernd Eckenfels wrote:

||  In article <[EMAIL PROTECTED]> you wrote:

||  {
||struct x25_route_struct rt;
||struct sockaddr_x25 sx25;
||  ...
||memset((char *) &rt, 0, sizeof(struct x25_route_struct));

  memset((char *) &rt, 0, sizeof rt);

It's actually better, because the consistency of this code doesn't depend
on the actual type of "rt".  Inform upstream.

||  ...
||/* x25_route_struct.address isn't type struct sockaddr_x25, Why? */
||memcpy(&rt.address, &sx25.sx25_addr, sizeof(struct x25_address));
||  ...

||  >memcpy(&rt.address, &sx25.sx25_addr, sizeof sx25.sx25_addr);
||  > This will work with either definition of sx25_address.
||
||  thanks  for your  help, will do that (however i prefer the paranteses :)

As you wish.  It's your package.

Ciao.Vincent.
-- 
Vincent Zweije <[EMAIL PROTECTED]>| "If you're flamed in a group you
  | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: Digital signature

Re: need help on #271678 (sizefo struct?)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> If you happen to have a variable (or field or in fact any expression)
> of that type (either type "struct x25_address" or type "x25_address"),
> then you can take the size of the variable, instead of the size of the
> type.

Yes thats a good point, hmm:


{
  struct x25_route_struct rt;
  struct sockaddr_x25 sx25;
...
  memset((char *) &rt, 0, sizeof(struct x25_route_struct));
...
  /* x25_route_struct.address isn't type struct sockaddr_x25, Why? */
  memcpy(&rt.address, &sx25.sx25_addr, sizeof(struct x25_address));
...


The 2.6 headers include:

#struct x25_address {
#char x25_addr[16];
#};
#
#/*
# *  Linux X.25 Address structure, used for bind, and connect mostly.
# */
#struct sockaddr_x25 {
#sa_family_tsx25_family; /* Must be AF_X25 */
#struct x25_address sx25_addr;   /* X.121 Address */
#};

and the 2.4 headers:

#typedef struct {
#charx25_addr[16];
#} x25_address;

#struct sockaddr_x25 {
#sa_family_t sx25_family;/* Must be AF_X25 */
#x25_address sx25_addr;  /* X.121 Address */
#};

>memcpy(&rt.address, &sx25.sx25_addr, sizeof sx25.sx25_addr);
> This will work with either definition of sx25_address.

thanks  for your  help, will do that (however i prefer the paranteses :)

Greetings
Bernd


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

Re: Debian Woody -> Sarge upgrade report

[Jonathan McDowell]

On Fri, May 06, 2005 at 04:21:13PM -0400, Roberto C. Sanchez wrote:
> Last night (when I should have been working a project for my advanced
> algorithms class) I decided it was time to upgrade my personal server
> from Woody to Sarge.  I am writing this email im the hopes that the
> release team and devs find it helpful and that other users who upgrade
> can make use of the information.
> 
> In summary, here are the things that I saw:
>
> 4. sslwrap upgrade completely choked over openssl
> 
> In detail:
> 
> 4.  The upgrade to sslwrap tried to generate an ssl certificate.  For
> some reason (I suspect becuase I have created my own CA), openssl
> errored out, causing the sslwrap postinst to fail.  This caused me
> repreated problems as it would hang up the postinst of other packages.
> I finally copied /etc/ssl and /etc/sslwrap off to another location,
> purge both openssl and sslwrap, reinstall both, remove /etc/ssl and
>  /etc/sslwrap, and replace them with my backup copies.  I am not sure
> why this happened, but I am pretty sure it is a bug.  I have not yet
> filed a bug since I am not sure if it should go against openssl or
> sslwrap.  Sugestions would be appreciated.

H. I run with my own CA signed cert and had no problems with a
Woody -> Sarge upgrade of sslwrap on Friday. Can you send me your
/etc/sslwrap/debian_conf and the output of
"grep sslwrap /etc/inetd.conf" (assuming you're running it from inetd)?

J.

-- 
Revd. Jonathan McDowell, ULC | noodles is angry with him


signature.asc
Description: Digital signature

Re: Marketing Laboral

[Mariana]

HOLA debian-devel!, INTERRUMPO TU TAREA PARA ALGO IMPORTANTE

ESTAS SON LAS RAZONES POR LAS QUE 
NO PODÉS DEJAR DE LEER ESTE TEXTO

Si vivís en Paraguay y…
estás pensando en cambiar de trabajo,
estás buscando trabajo,
conocés a alguien que está buscando trabajo y lo quieres ayudar,
estás ahora estudiando y pronto tendrás que ubicarte en una posición laboral

(SI NINGUNO DE ESTOS ES TU CASO, DEJÁ AQUÍ ESTE TEXTO Y DISCULPÁ LA MOLESTIA 
OCASIONADA, PERO SI EN ALGUNO COINCIDÍS DEJÁ TODO Y LEE COMO PODEMOS AYUDARTE)

LAS COSAS CAMBIARON Y BUSCAR TRABAJO YA NO ES IGUAL QUE ANTES

BUSCAR TRABAJO ES UN TRABAJO EN SÍ MISMO
Desde hace un tiempo …. (continuar leyendo haciendo clic aquí)
http://www.todosobreventas.com/texto_marketing.html

Re: adduser: what is the difference between --disabled-password and--disabled-login

[Frederik Dannemare]

On Monday 16 May 2005 11:12, Frederik Dannemare wrote:
> On Thursday 12 May 2005 20:18, Marc Haber wrote:
> [ ... ]
>
> > "UsePam yes" is generally a _big_ surprise for the local admin
> > since it allows passwords to be used even if
> > "UsePasswordAuthentification no" is set in sshd_config.
>
> [ ... ]
>
> I have exactly those set on a few hosts:
> foohost:/var/log# egrep "PasswordAuth|UsePAM" /etc/ssh/sshd_config
> PasswordAuthentication no
> UsePAM yes
>
> But from client hosts with no proper pubkey, I get :
> $ ssh foohost
> Permission denied (publickey).
>
> From what you mention above, I should actually be prompted for a
> password, right? I only remember setting "PasswordAuthentication no"
> in sshd_config and I haven't touched any PAM stuff (ie. default Sarge
> settings).

Btw, I have "ChallengeResponseAuthentication no" as well. I suspect this 
is why "UsePAM yes" is not a problem here (with respect to allowing 
passwords to be used).

-- 
Frederik Dannemare | http://sentinel.dk | http://linuxworlddomination.dk
http://qa.debian.org/developer.php?login=Frederik+Dannemare
http://www.ubuntulinux.org/wiki/FrederikDannemare
Key fingerprint = 30CF 7AD3 17D9 1A63 A730  ECA6 0D4C 2C97 9D9A 238E


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

Re: adduser: what is the difference between --disabled-password and--disabled-login

[Frederik Dannemare]

On Thursday 12 May 2005 20:18, Marc Haber wrote:
[ ... ]
> "UsePam yes" is generally a _big_ surprise for the local admin since
> it allows passwords to be used even if "UsePasswordAuthentification
> no" is set in sshd_config.
[ ... ]

I have exactly those set on a few hosts:
foohost:/var/log# egrep "PasswordAuth|UsePAM" /etc/ssh/sshd_config
PasswordAuthentication no
UsePAM yes

But from client hosts with no proper pubkey, I get :
$ ssh foohost
Permission denied (publickey).

From what you mention above, I should actually be prompted for a 
password, right? I only remember setting "PasswordAuthentication no" in 
sshd_config and I haven't touched any PAM stuff (ie. default Sarge 
settings).

Best regards,
-- 
Frederik Dannemare | http://sentinel.dk | http://linuxworlddomination.dk
http://qa.debian.org/developer.php?login=Frederik+Dannemare
http://www.ubuntulinux.org/wiki/FrederikDannemare
Key fingerprint = 30CF 7AD3 17D9 1A63 A730  ECA6 0D4C 2C97 9D9A 238E

Re: unsubscribe

[Bezecny Martin]

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

Re: need help on #271678 (sizefo struct?)

[Vincent Zweije]

On Sun, May 15, 2005 at 07:44:25PM -0700, Russ Allbery wrote:

||  This is a woody vs. sarge difference.  On sarge, linux/x25.h says:
||
||  struct x25_address {
||  char x25_addr[16];
||  };
||
||  so the current code, with sizeof(struct x25_address) is correct and
||  changing it would actually break the code.  On woody, linux/x25.h says:
||
||  typedef struct {
||  charx25_addr[16];
||  } x25_address;
||
||  which means that sizeof(x25_address) is correct and the current code won't
||  compile (because nothing ever creates a struct x25_address, just an
||  anonymous struct that is typedef'd to x25_address).  This is an
||  incompatible change in the kernel headers, and there isn't any way for the
||  code to compile on both systems without some additional portability work.

If you happen to have a variable (or field or in fact any expression)
of that type (either type "struct x25_address" or type "x25_address"),
then you can take the size of the variable, instead of the size of the
type. So you can do:

memcpy(&rt.address, &sx25.sx25_addr, sizeof sx25.sx25_addr);

This will work with either definition of sx25_address.

(sizeof is an operator and doesn't need parentheses.  If the argument
is a type, then *that* needs parentheses though.  But I digress.)

Ciao. Vincent.
-- 
Vincent Zweije <[EMAIL PROTECTED]>| "If you're flamed in a group you
  | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |-- Paul Tomblin on a.s.r.


signature.asc
Description: Digital signature