dependency on base package adduser ?

[Matthijs Mohlmann]

Hi,

We got a bug on pdns-server #308409.

In the preinst we do an adduser to let pdns run with another user then root.

The bug submitter says that we need an dependency on adduser. But i'm
not really sure about it because adduser is a base package. And i
thought you don't have to depend on a base package.

Regards,

Matthijs Mohlmann


signature.asc
Description: OpenPGP digital signature

Re: dependency on base package adduser ?

[Petter Reinholdtsen]

[Matthijs Mohlmann]
> But i'm not really sure about it because adduser is a base
> package. And i thought you don't have to depend on a base package.

Where did you get that idea?  Any references to documentation stating
this?

I suspect you confuse this with build-dependencies, where you can drop
dependencies on build essesials.  A package is supposed to have a
complete and correct list of dependencies for its binary packages.
Just look at how all binaries depend on libc.  It is a base package,
but still listed as a dependency.


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

Bug#308433: ITP: helpdeco -- decompile Microsoft WinHelp files

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise <[EMAIL PROTECTED]>

* Package name: helpdeco
  Version : 2.1.1
  Upstream Author : Manfred Winterhoff <[EMAIL PROTECTED]>
* URL : http://sf.net/projects/helpdeco/
* License : GPL
  Description : decompile Microsoft WinHelp (.hlp) files

helpdeco dissects HLP help files (WinHelp) of Windows 3.0, 3.1, 3.11,
and Win95 and many MVB multi media viewer titles into all files required
for a rebuild using the appropriate help compiler HC30, HC31, HCP, HCW,
HCRTF, WMVC, MMVC or MVC.

This software is in the process of relicencing from a no-commercial-use
licence to the GNU General Public Licence >= 2. Upstream (which I
suppose I am now part of, having initiated the relicencing and done the
commits) is checking the current CVS version before release. I will
begin packaging it and send an RFS after the newly relicenced release is
out. Along with the original author, we invited the helpdeo NetBSD
maintainer to join us in maintaining the code and he accepted.

-- 
bye,
pabs


signature.asc
Description: This is a digitally signed message part

Re: packages missing from sarge

[Rene Mayrhofer]

Am Dienstag, 10. Mai 2005 02:40 schrieb Anthony DeRobertis:
> Seconded! The only RC-bug in openswan is for a newer version of the
> kernel which will not ship with Sarge.
Yes, that's true. I have to admit that I messed up in not marking this bug 
sid. My current best solution would be to put 2.2.0-4 back into testing 
(which got removed because of that RC bug that's for 2.3.0). What is the 
general opinion on this?

with best regards,
Rene


pgpOPG0kUiSok.pgp
Description: PGP signature

Re: dependency on base package adduser ?

[Eduard Bloch]

#include 
* Matthijs Mohlmann [Tue, May 10 2005, 09:05:25AM]:

> In the preinst we do an adduser to let pdns run with another user then root.
> 
> The bug submitter says that we need an dependency on adduser. But i'm
> not really sure about it because adduser is a base package. And i
> thought you don't have to depend on a base package.

"base" is not a priority level or so, it is just a term for packages
that are installed by the original installer. And nothing forbids the
local administrator to remove one of these, unless they have "required"
priority (eg. libc6) which adduser does not belong to.

Regards,
Eduard.
-- 
 Lieber Kinder zuhause, bitte nicht poppen, da ist am ende
alles kleiner als am Anfang :)


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

Re: dependency on base package adduser ?

[Gergely Nagy]

On Tue, 2005-05-10 at 09:12 +0200, Petter Reinholdtsen wrote:
> [Matthijs Mohlmann]
> > But i'm not really sure about it because adduser is a base
> > package. And i thought you don't have to depend on a base package.
> 
> Where did you get that idea?  Any references to documentation stating
> this?
> 
> I suspect you confuse this with build-dependencies, where you can drop
> dependencies on build essesials.  A package is supposed to have a
> complete and correct list of dependencies for its binary packages.
> Just look at how all binaries depend on libc.  It is a base package,
> but still listed as a dependency.

Furthermore, as adduser is used in preinst, the package must Pre-Depend
on it (according to my reading of Policy 7.2).

-- 
Gergely Nagy


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

Re: dependency on base package adduser ?

[Russ Allbery]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Matthijs Mohlmann]

>> But i'm not really sure about it because adduser is a base package. And
>> i thought you don't have to depend on a base package.

> Where did you get that idea?  Any references to documentation stating
> this?

> I suspect you confuse this with build-dependencies, where you can drop
> dependencies on build essesials.  A package is supposed to have a
> complete and correct list of dependencies for its binary packages.  Just
> look at how all binaries depend on libc.  It is a base package, but
> still listed as a dependency.

I think he might be confused by the difference between essential, priority
required, and section base.

So far as I know, a base package (section base) has no particular special
meaning from a dependency perspective, although I believe that section may
be reserved for required packages (but am not sure).

The Policy statement is that one does not have to depend on *essential*
packages:

Packages are not required to declare any dependencies they have on
other packages which are marked Essential (see below), and should not
do so unless they depend on a particular version of that package.

Essential is a special flag that's separate from the priority.  You still
have to depend on even Priority: required packages that you use if they're
not essential.

Anyway, adduser is only Priority: important, which means that it's quite
possible for it to not be installed.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: dependency on base package adduser ?

[Eduard Bloch]

#include 
* Eduard Bloch [Tue, May 10 2005, 09:20:38AM]:

> "base" is not a priority level or so, it is just a term for packages
> that are installed by the original installer. And nothing forbids the
> local administrator to remove one of these, unless they have "required"
> priority (eg. libc6) which adduser does not belong to.

Self-correction: I meant the Essential flag and not the "required"
priority.

Eduard.
-- 
Ambassador Londo Mollari: Everyone around me dies, Mr. Morden, except those who
most deserve it.
 -- Quotes from Babylon 5 --


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

Re: dependency on base package adduser ?

[Matthijs Mohlmann]

Hi,

I mixed up stuff.

Thanks for helping out.

Regards,

Matthijs Mohlmann

Eduard Bloch wrote:
> #include 
> * Eduard Bloch [Tue, May 10 2005, 09:20:38AM]:
>
>
>>"base" is not a priority level or so, it is just a term for packages
>>that are installed by the original installer. And nothing forbids the
>>local administrator to remove one of these, unless they have "required"
>>priority (eg. libc6) which adduser does not belong to.
>
>
> Self-correction: I meant the Essential flag and not the "required"
> priority.
>
> Eduard.


signature.asc
Description: OpenPGP digital signature

Re: dependency on base package adduser ?

[Michael Koch]

On Tue, May 10, 2005 at 09:47:11AM +0200, Eduard Bloch wrote:
> #include 
> * Eduard Bloch [Tue, May 10 2005, 09:20:38AM]:
> 
> > "base" is not a priority level or so, it is just a term for packages
> > that are installed by the original installer. And nothing forbids the
> > local administrator to remove one of these, unless they have "required"
> > priority (eg. libc6) which adduser does not belong to.
> 
> Self-correction: I meant the Essential flag and not the "required"
> priority.

libc6 is not and may not be marked Essential, as the NM process taught me.
So its a bad example.


Michael
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/


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

Re: packages missing from sarge

[Anthony DeRobertis]

On Tue, May 10, 2005 at 09:32:49AM +0200, Rene Mayrhofer wrote:
> Am Dienstag, 10. Mai 2005 02:40 schrieb Anthony DeRobertis:
> > Seconded! The only RC-bug in openswan is for a newer version of the
> > kernel which will not ship with Sarge.
> Yes, that's true. I have to admit that I messed up in not marking this bug 
> sid. My current best solution would be to put 2.2.0-4 back into testing 
> (which got removed because of that RC bug that's for 2.3.0). What is the 
> general opinion on this?

If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why
not just get 2.3.x pushed into sarge? Are there any other big issues
with it, that weren't in 2.2.x? Some people might certainly like the
agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is
fine for me though --- anything but 2.1.x for me :-)

> 
> with best regards,
> Rene



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

Re: /usr/lib vs /usr/libexec

[GOMBAS Gabor]

On Tue, May 10, 2005 at 05:42:31AM +0200, Bernd Eckenfels wrote:

> > - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing
> > problems for /boot.
> 
> Why is that?

Missing bootloader support.

> > - a larger FS has more chance of failing so you risk having a fully
> > broken system more often
> 
> And two file systems have even more chance. One read only file system is
> pretty stable.

Sure, that's why I have /usr mounted read-only.

> > - /usr can be easily network (shared accross the same arch) mounted
> > while / (due to /etc) can't
> > - / needs functioning device nodes on it while usr can be mounted nodev
> 
> I agreee, those arguments and the netboot stuff is an argment for a smaller
> root partition. However our root filesystem is too big anyway.

That's true:

$ df -h
FilesystemSize  Used Avail Use% Mounted on
/dev/hda5  99M   75M   19M  80% /
[...]

$ du -sh /etc/gconf
26M /etc/gconf

That's 1/3 of my root fs. It's damn too much.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Location of Web Application Data, Policy 11.5.3

[Alexis Sukrieh]

* Christoph Berg ([EMAIL PROTECTED]) disait :
> Re: Marc Haber in <[EMAIL PROTECTED]>
> > Am I missing something or is this part of policy widely ignored?
> 
> I had my own problems with that paragraph and would appreciate to have
> it clarified.
> 
> There's a new mailing list for webapps since last week, shouldn't the
> discussion go there?

Definitely :)

> http://lists.debian.org/debian-webapps/

We are currently writing a new policy for giving guidelines and
requirments on packaging web applications.

Feel free to sign up.

-- 
  Alexis Sukrieh <[EMAIL PROTECTED]>
   http://www.sukria.net

« Quidquid latine dictum sit, altum sonatur. » 
Whatever is said in Latin sounds profound.


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

Re: packages missing from sarge

[Steve Langasek]

On Tue, May 10, 2005 at 04:17:41AM -0400, Anthony DeRobertis wrote:
> On Tue, May 10, 2005 at 09:32:49AM +0200, Rene Mayrhofer wrote:
> > Am Dienstag, 10. Mai 2005 02:40 schrieb Anthony DeRobertis:
> > > Seconded! The only RC-bug in openswan is for a newer version of the
> > > kernel which will not ship with Sarge.
> > Yes, that's true. I have to admit that I messed up in not marking this bug 
> > sid. My current best solution would be to put 2.2.0-4 back into testing 
> > (which got removed because of that RC bug that's for 2.3.0). What is the 
> > general opinion on this?

> If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why
> not just get 2.3.x pushed into sarge? Are there any other big issues
> with it, that weren't in 2.2.x? Some people might certainly like the
> agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is
> fine for me though --- anything but 2.1.x for me :-)

Because 2.2.3 is no longer in the archive, and resurrecting new binaries via
t-p-u gives us even less than the usual protection against breakage caused
by a lack of testing. :/

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: /usr/lib vs /usr/libexec

[Cameron Hutchison]

Once upon a time GOMBAS Gabor said...
> 
> $ df -h
> FilesystemSize  Used Avail Use% Mounted on
> /dev/hda5  99M   75M   19M  80% /
> [...]
> 
> $ du -sh /etc/gconf
> 26M /etc/gconf
> 
> That's 1/3 of my root fs. It's damn too much.

I discovered this a while ago and learned that most of it can be
removed. I think they must be conf files so were never automatically
removed, but you should find newer versions of all the files in the
/etc/gconf directory in /usr/share/gconf. I've got only a couple of
schemas left in /etc/gconf and if I check, those may be able to be
removed by now as well.


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

Re: packages missing from sarge

[Rene Mayrhofer]

Steve Langasek schrieb:
>>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why
>>not just get 2.3.x pushed into sarge? Are there any other big issues
>>with it, that weren't in 2.2.x? Some people might certainly like the
>>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is
>>fine for me though --- anything but 2.1.x for me :-)
Mainly because 2.3.x causes other openswan boxes to crash in some
(reproducable) cases - that's a pretty bad regression from 2.2.0 and I
keep bugging upstream with it for at least 3 months. No fix until now,
so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or
even 2.2.0-5).

> Because 2.2.3 is no longer in the archive, and resurrecting new binaries via
> t-p-u gives us even less than the usual protection against breakage caused
> by a lack of testing. :/
Does that mean that the only way to get the known stable 2.2.0-x back
into testing is an upload to unstable with an epoch? I really wouldn't
like to go that route if I can avoid it

with best regards,
Rene


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

Re: /usr/lib vs /usr/libexec

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>> > - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing
>> > problems for /boot.
>> 
>> Why is that?
> 
> Missing bootloader support.

the bootloader does not need to access the root filesystem. It only loads
the kernel and the initrd from /boot.

Greetings
Bernd


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

Re: dependency on base package adduser ?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> libc6 is not and may not be marked Essential, as the NM process taught me.
> So its a bad example.

Even if it is marked as essential, you have a versioned dependency, anyway.

Gruss
Bernd


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

Re: /usr/lib vs /usr/libexec

[Andrew Suffield]

On Mon, May 09, 2005 at 08:38:02AM -0700, Thomas Bushnell BSG wrote:
> Martin Waitz <[EMAIL PROTECTED]> writes:
> 
> > The BSDs use libexec but I don't really see a good reason why it exists.
> 
> It reduces search times in libraries, which is important.

We do not have that bug, so it's not important to us.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Tricky library packaging question

[Enrico Zini]

On Mon, May 09, 2005 at 08:18:37PM -0700, Steve Langasek wrote:

> > I cannot think of any other options.  I'm short of clues for the best
> > way of doing this, and I'd be happy to give access to the svn repository
> > of people who could help and work on it together.
> I imagine these libraries are fairly small, and therefore IMHO there's no
> real reason to create a separate -pic package for each.  However, you do
> need to provide the library in PIC form if you're going to be linking to it
> from other packages that provide DSOs (i.e., perl and python modules).  I
> would suggest simply bundling a libfoo_pic.a (static, PIC) library in the
> respective -dev package.

Wow!  Thanks, thanks, thanks Steve, this sounds quite ideal.

Now I'll have to figure out the automake/autoconf machinery to have that
working, but at least now I have quite clear what needs to be done.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

I need a Rolex watch

[Dora]

Rolex GMT
http://billions.mfek.com/replica/vron/Grosset.html
Vote: Rolex or Cartier or Breitling

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

Re: GPL and linking

[Humberto Massa]

Raul Miller wrote:
On 5/9/05, Humberto Massa <[EMAIL PROTECTED]> wrote:
 

You can't re-state something saying a different thing. GPL#0 says
that "a work based on the Program" is "a derivative work under
copyright law", and then says "that is to say, a work
containing...", which is NOT a re-statement of a "derivative work
under copyright law".
   

That's another re-statement of what "a work based on the Program"
means.
 

The GPL just equated the two, before the colon! It states, clearly, that 
the "a work based on the program" is "a derivative work under copyright 
law", and then, using a colon and the introductory phrase "that is to 
say", it states that "a work based on the program" is "a work 
containing...". My point is that the second statement is not stating the 
same thing, so it can NOT be a re-statement. It must be something else.

 

Yes and no. The GPL is the authoritative document on whatever it
wants to define and whatever it CAN define (the GPL CANNOT define
what is "a derivative work under copyright law", for instance)...
but IF AND ONLY IF it defines it without ambiguity.
   

The GPL is not defining what a derivative work under copyright law
means.  It's defining what a "work based on the Program" means.
 

It had equated the two of them in the first part of the phrase.
 

What the GPL actually does is defining a cat this way: '' a cat is
the animal on the page 3 of the Domestic Pets Handbook, that is to
say, an animal with four legs and whiskers. ''. Does this defines
all animals with four legs and whiskers as being cats?
   

Not actually.  Cats are outside the scope of copyright law.
 

But cats are not outside the scope of the Domestic Pets Handboook. If 
you were not trying to win the argument at all costs, you would see that 
my paragraph in quotes, above, has EXACTLY the same grammatical 
structure as GPL#0. And the interpretation you are giving to this 
disposition of the GPL#0 is exactly the same I am giving for cats. You 
*are* saying that every work that "contains the Program or a portion of 
it" is a "work based on the Program", as per the GPL. But it's not! Now, 
every "derivative work under copyright law" is a "work based on the 
Program"... nothing more, nothing less...


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

Re: /usr/lib vs /usr/libexec

[Humberto Massa]

Thomas Bushnell BSG wrote:
Martin Dickopp <[EMAIL PROTECTED]> writes:
 

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
   

If there is a reason to separate /usr from / (which so many people
think there is, though I don't understand why, since it has no
semantic significance at all), why separate /lib from /etc?
 

I don't see a semantic difference between /bin and /usr/bin (or /lib
   

and
 

/usr/lib). IMHO, the only reason for /bin and /lib is that some
   

programs
 

and libraries need to be available before is /usr is mounted.
   

That doesn't make sense.  If you get rid of the /usr vs / distinction,
then there is no "before /usr is mounted".  
 

Have you considered that for some (eg embedded) applications, the block 
device containing "/" does not have enough space to contain everything 
that is under "/usr"? And that, as a result, it would have to mount it 
as a network drive, for instance?

 

That wasn't my argument. My argument is that I don't consider shared
libraries and internal executables "different kinds of things." They
are both binaries loaded and executed by a program.
   

Sure, and documentation and libraries are both "files opened by
programs".
The difference is that libraries are also generic things that are
shared by many programs, and searched by the linker, whereas
executables are not.
In fact, a library is "loaded and executed" by only two programs (ld
and ld.so) in the normal scheme of things.  
 

The difference between /usr/lib and /usr/shared is more clear: what is 
under /usr/lib depends on the arch; what is under /usr/share doess not. 
So, /usr/lib can be mounted in a network drive, shared by a lot of 
machines of the same arch in a network. And /usr/shared can be (hmpf)... 
shared... between all machines in a network, independently of arch.

Thomas
 

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

Re: /usr/lib vs /usr/libexec

[Humberto Massa]

Thomas Bushnell BSG wrote:
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
 

That doesn't make sense.  If you get rid of the /usr vs /
 

distinction,
 

then there is no "before /usr is mounted".  
 

But then you have a minimum 1-5GB /. That sucks.
   

Why, exactly?  I know people think it's obvious, but the lack of
stated reasons worries me.
I know the *original* reasons why / needed to be small, but they don't
apply anymore.  So I'll buy the "it's obvious" if you can state the
original reasons and explain why you think they still apply.  If not,
then what is the current reason?
Thomas
 

What do you think are the original reasons "/" needed to be small?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /usr/lib vs /usr/libexec

[Josselin Mouette]

Le mardi 10 mai 2005 à 10:21 +0200, GOMBAS Gabor a écrit :
> On Tue, May 10, 2005 at 05:42:31AM +0200, Bernd Eckenfels wrote:
> 
> > > - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing
> > > problems for /boot.
> > 
> > Why is that?
> 
> Missing bootloader support.

Which bootloader doesn't support reiserfs?

> $ du -sh /etc/gconf
> 26M /etc/gconf
> 
> That's 1/3 of my root fs. It's damn too much.

Almost all the schemas were already moved out to /usr/share. We plan to
move the defaults directory structure to /var/lib/gconf after the
release - at least, the defaults brought by package; we have to keep a
defaults structure in /etc for local modifications.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: /usr/lib vs /usr/libexec

[Russell Coker]

On Tuesday 10 May 2005 02:18, Goswin von Brederlow 
<[EMAIL PROTECTED]> wrote:
> Russell Coker <[EMAIL PROTECTED]> writes:
> > It seems to me that /usr/libexec is a better name for such things, and
> > having the same directory names used across distributions provides real
> > benefits (copying config files and binaries from other distributions when
> > a bug stops a server working and it's REALLY important to get it fixed
> > fast).
> >
> > Should we change some of these to /usr/libexec?
>
> That would be /usr/libexec/arch-os/postfix vs /usr/lib/arch-os/postfix
> then.
>
> If you consider any change then please include the multiarch changes
> at the same time. No point doing 2 transitions for etch.

Why would it be desirable to have arch-os directories under libexec?

By definition anything in libexec is a program that is a part of another 
program.  In the case of Postfix there are many cooperating programs running 
with different privs (different UID and different SE Linux domain) that are 
used for different aspects of Postfix functionality.  Why would you want one 
of those programs to be 32bit and another to be 64bit?

Firstly there is little performance to be gained by running Postfix 64bit.  
Any performance issues that a Postfix server will experience will be related 
to disk IO (not a word size issue) or the speed of external programs such as 
virus scanners and Postgrey (which interoperate with Postfix via TCP sockets 
and have no inter-dependencies on word size etc).

Secondly there is no benefit to using different word sizes for different parts 
of Postfix.  I can't imagine any reason for using different word sizes.  
There is a possibility of having Postfix call external shared objects which 
may make some dependencies on word size.  But if you have two shared objects 
one of which is 32bit and another 64bit then trying to get Postfix processes 
to use both will be a losing game.  AFAIK there is no design documentation 
which precisely states which Postfix sub-process will use a given shared 
object.

Finally no-one has tested Postfix for such things.  I think that Postfix is 
very well written and should work even if you had parts of it being 64bit and 
parts being 32bit.  But this is not tested or guaranteed.  If there was a bug 
in this regard then it could have security implications, do you want to take 
the chance?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
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/~russell/  My home page


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

Re: /usr/lib vs /usr/libexec

[Russell Coker]

On Tuesday 10 May 2005 10:36, Goswin von Brederlow 
<[EMAIL PROTECTED]> wrote:
> - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing
> problems for /boot.

I believe that there are LILO patches for /boot on LVM.  There's no reason why 
GRUB and other boot loaders couldn't be updated in the same manner.  The most 
obvious solution is to have the LV containing /boot being marked in the LVM 
setup as contiguous.  Then the boot loader merely has to use a different 
method of finding the first block.

ReiserFS has been supported for /boot for ages.  When I took over maintenance 
of LILO it was initially to get the ReiserFS patches included.

RAID-0 could be supported by boot loaders.  The only real complication is the 
need to correctly identify two boot disks (correctly identifying one is 
enough pain as anyone who has worked with boot loader code knows well).  In 
fact I'm reasonably sure that the only reason for not having support for 
RAID-0 in boot loaders is the fact that it's so painful to identify two disks 
correctly.  When you have N disks the difficulty (for programmer and for 
sys-admin) will be of order N*(N-1) instead of being of order N.

But generally the best solution to such problems is to have a separate 
partition for /boot.  Red Hat defaults to an LVM install (including LVM root) 
with a regular 100M partition for /boot, that works well.

> - a larger FS has more chance of failing so you risk having a fully
> broken system more often

I doubt that.

I think that a FS that is written less has less chance of failing, which is an 
extra reason for having /var and /home on different file systems to /.  If 
you have /var and /home on separate partitions then / should not get many 
writes and should have little chance of corruption regardless of size.

> - /usr can be easily network (shared accross the same arch) mounted
> while / (due to /etc) can't

Why is this desirable in the days of large disks?  There is no machine for 
which I am responsible which has a disk space issue other than my laptop.  
None of my machines has /usr taking any significant portion of the disk 
space.

> - / needs functioning device nodes on it while usr can be mounted nodev

The current Fedora setup of having an initrd create device nodes on a tmpfs is 
working quite well and could be copied for Debian.

> - a small / can be replicated across many disks to ensure the system
> always comes up and e.g. at least send an email to the admin. / can
> even be an initrd

How big can an initrd be?  The default is 4M which isn't going to do well 
for /.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
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/~russell/  My home page


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

removing packages unexpected behaviour

[Matthijs Mohlmann]

Hi,

When i try to remove pdns-server while one of the backends is installed
i got the following behaviour:

monster:/usr/src# apt-get remove --purge pdns-server
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
  pdns-backend-mysql* pdns-server*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 1782kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 9343 files and directories currently installed.)
Removing pdns-backend-mysql ...
Stopping PowerDNS authoritative nameserver: Scheduling exit
sed: can't read -: No such file or directory
dpkg: error processing pdns-backend-mysql (--purge):
 subprocess post-removal script returned error exit status 2
Restarting PowerDNS authoritative nameserver: stopping and waiting..done
Starting PowerDNS authoritative nameserver: started
dpkg: pdns-server: dependency problems, but removing anyway as you request:
 pdns-backend-mysql depends on pdns-server (= 2.9.17-12).
Removing pdns-server ...
Stopping PowerDNS authoritative nameserver: Scheduling exit
Purging configuration files for pdns-server ...
Errors were encountered while processing:
 pdns-backend-mysql
E: Sub-process /usr/bin/dpkg returned an error code (1)

This is not my intention, when pdns-backend-mysql fails when removing
then pdns-server should also fail or am i wrong ?

Attached the debian/control file.

Regards,

Matthijs Mohlmann
Source: pdns
Section: net
Priority: extra
Standards-Version: 3.6.1.1
Maintainer: Debian PowerDNS Maintainers <[EMAIL PROTECTED]>
Uploaders: Christoph Haas <[EMAIL PROTECTED]>, Matthijs Mohlmann <[EMAIL 
PROTECTED]>
Build-Depends: debhelper (>= 4.2.0), po-debconf, dpatch (>= 2.0.0), libtool, 
flex, bison, docbook-utils, libmysqlclient12-dev, postgresql-dev, tdb-dev, 
libgdbm-dev, libldap2-dev, libsqlite0-dev, dpkg-dev (> 1.10.17)

Package: pdns
Architecture: any
Depends: pdns-server, pdns-recursor
Description: meta package for the pdns nameserver
 PowerDNS is a versatile nameserver which supports a large number
 of different backends ranging from simple zonefiles to relational
 databases and load balancing/failover algorithms.
 PowerDNS tries to emphasize speed and security.
 .
 This package is added for compatibility reasons because it has been split into
 pdns-server and pdns-recursor. It does not need to be installed any more.

Package: pdns-server
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Pre-Depends: adduser
Replaces: pdns
Recommends: pdns-doc
Suggests: pdns-backend, pdns-recursor
Description: extremely powerful and versatile nameserver
 PowerDNS is a versatile nameserver which supports a large number
 of different backends ranging from simple zonefiles to relational
 databases and load balancing/failover algorithms.
 PowerDNS tries to emphasize speed and security.
 .
 This is the authoritative nameserver that answers questions about
 domains that it knows about.

Package: pdns-recursor
Architecture: any
Depends: ${shlibs:Depends}
Replaces: pdns
Recommends: pdns-doc
Description: PowerDNS recursor
 PowerDNS is a versatile nameserver which supports a large number
 of different backends ranging from simple zonefiles to relational
 databases and load balancing/failover algorithms.
 PowerDNS tries to emphasize speed and security.
 .
 This is the recursive nameserver that goes out to the internet and
 resolve queries about other domains.

Package: pdns-doc
Section: doc
Architecture: all
Description: PowerDNS manual
 PowerDNS is a versatile nameserver which supports a large number
 of different backends ranging from simple zonefiles to relational
 databases and load balancing/failover algorithms.
 PowerDNS tries to emphasize speed and security.
 .
 This is the complete manual for PowerDNS, documenting both how to
 install and configure it as well as how to write new backend modules.

Package: pdns-backend-pipe
Architecture: any
Depends: pdns-server (= ${Source-Version}), ${shlibs:Depends}
Provides: pdns-backend
Description: pipe/coprocess backend for PowerDNS
 PowerDNS is a versatile nameserver which supports a large number
 of different backends ranging from simple zonefiles to relational
 databases and load balancing/failover algorithms.
 PowerDNS tries to emphasize speed and security.
 .
 This package contains the pipe backend for the PowerDNS nameserver. This
 allows PowerDNS to retrieve domain info from a process that accepts
 questions on stdin and returns answers on stdout.

Package: pdns-backend-ldap
Architecture: any
Depends: pdns-server (= ${Source-Version}), ${shlibs:Depends}, ${misc:Depends}
Provides: pdns-backend
Description: LDAP backend for PowerDNS
 PowerDNS is a versatile nameserver which supports a large number
 of different backends ranging from simple zonefiles to relational
 databases and load balancing/failover algorithms.
 PowerDNS tries to emphasize speed and security.
 .
 This package contains an LDAP back

really experimental sunbird calendar package available

[Alexander Sack]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Just uploaded a sunbird package to my experimental p.d.o. archive. It is still
not in a shape suitable for debian, but since upstream is quite a big step away
from a releasable state too, I have no problems with releasing this snapshot
today in such an experimental shape ... at least it works a bit :)

The apt line you need:

   deb http://people.debian.org/~asac/experimental ./

The package you (maybe not) want:

   sunbird - (so no mozilla- prefix :) )

Please read my annoucement [1] for infos on how to get started and please
remember to *not* use this for important things you really depend on.

Oh, and there are some screenshots [2] too.

BTW, I was not able to extract a good orig.tar.gz from upstreams archive. Hence,
I did not upload the really bloated 60 MB full mozilla tree source tarball that
I used to build this package from. Anyone interested in the diff, just drop a 
mail.


[1] - http://www.asoftsite.org/sunbird.html
[2] - http://www.asoftsite.org/sunbird_screens.html

- --
 GPG messages preferred.   |  .''`.  ** Debian GNU/Linux **
 Alexander Sack| : :' :  The  universal
 [EMAIL PROTECTED]   | `. `'  Operating System
 http://www.asoftsite.org  |   `-http://www.debian.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgK+zv8pLOKgkuT8RAlP3AJ0c6nRgaAWNa/SVPKNTF+1BU41nvQCbBcpg
15ulEfOxOBdxbq2vkIoenc0=
=IwN2
-END PGP SIGNATURE-


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

Re: GPL and linking

[Raul Miller]

On 5/10/05, Humberto Massa <[EMAIL PROTECTED]> wrote:
> Raul Miller wrote:
> >That's another re-statement of what "a work based on the Program"
> >means.
> >
> The GPL just equated the two, before the colon! It states, clearly, that
> the "a work based on the program" is "a derivative work under copyright
> law", and then, using a colon and the introductory phrase "that is to
> say", it states that "a work based on the program" is "a work
> containing...". My point is that the second statement is not stating the
> same thing, so it can NOT be a re-statement. It must be something else.

According to Wordnet, "that is to say" means "namely".

> It had equated the two of them in the first part of the phrase.

The GPL did not use the word "equals".

Neither "that is to say" nor "namely" are equal to "equals".

-- 
Raul

Re: cogito_0.10-1 available

[Sebastian Kuzminsky]

Ben Finney <[EMAIL PROTECTED]> wrote:
] It could be better described, yes. My understanding of /usr/share as
] "architecture-independent" (and read-only, as the description
] continues) is that /usr/share/can potentially be mounted read-only
] for multiple machines of different architectures.


Ok, I can deal with that.  Thanks for the explanation.


I'll move the Cogito shell fragments from /usr/lib/cogito to
/usr/share/cogito.  There is talk (of course) of reimplementing Cogito,
possibly in C -- if that happens I'll put the C libraries and binary
helper programs back in /usr/lib/cogito.  


I'll put up cogito_0.10-2 later today with this fix.




--
Sebastian


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

Re: dependency on base package adduser ?

[John Hasler]

Russ Allbery writes:
> So far as I know, a base package (section base) has no particular special
> meaning from a dependency perspective, although I believe that section
> may be reserved for required packages (but am not sure).

There are optional packages in base.
-- 
John Hasler


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

cas1no, play everywhere - cellphones, webtv, aol.....

[Scott]

Try your luck with our new brand cas1no. +30% for every diposit.
One hour payout, never fast before. Try play for free.
The real actor has a direct line to the collective heart. 
http://zelica.com.wehiuhef.com/ Acquaintance. A person whom we know well enough 
to borrow from, but not well enough to lend to. When an actor has money, he 
doesn't send letters, but telegrams.
to get out please read on page above It's no use saying, ''We are doing our 
best.'' You have got to succeed in doing what is necessary. In my hut this 
spring, there is nothing -- there is everything!

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

Re: Debian AMD64 Archive Move

[Ed Cogburn]

On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote:
> On 10283 March 1977, Ed Tomlinson wrote:
> >> Whats going on == someone needs to check it. Thats it.
> >
> > That was the point made by Ed Cogburn.  Its already been checked in the
> > other arch!  If this is not the case please explain why.  Without that
> > explanation I am forced to agree with Ed - the problem are political... 
> > Which is the bane of debian.
>
> We are *NOT* Debian


We ARE Debian for Heaven's sake!  This move to another server is just 
TEMPORARY!  We WILL be Debian as soon as sarge gets out and development on 
etch picks up.  Who in the world is going to get upset when they know we will 
soon be part of official Debian, and they've already given permission for 
Debian to distribute their stuff!  Get real people!

How many non-free packages have been cleared?  Why haven't you at least set up 
non-free and moved the packages known to be ok into it?  I know for sure that 
the rogue-like games in non-free are perfectly fine and can brought on-line 
now, since they and a lot of other stuff is in non-free just because they are 
"old" pre-GPL software with "don't sell for money" restrictions which make 
them fail the DFSG test on distribution, but are otherwise fully open-source 
(and who's earlier authors can no longer be found to ask them if they'd agree 
to a change to the GPL or some other Free license).

In fact, looking through the non-free docs section, most of that can go in 
right now because they don't require anyone's permission to distribute since 
they're in non-free because of the dispute between Debian and FSF over 
documentation.


> thats all you need to get!


Hogwash.  This sounds like an extremely defensive response.  How many packages 
have been cleared for non-free?  Why haven't you just put up a non-free 
section with the stuff thats been cleared?  Why has it been more than a week, 
with no non-free section at all, no indication of how the "vetting" process 
is going, and with you telling us above that we don't need to know anything 
more?  Now do you understand why I'm just a little bit skeptical?

Just establish the non-free section and move everything over.  If anyone 
complains then just drop the package they're complaining about.  Of course, 
NO ONE is going to complain since they know we will "become" Debian soon 
anyway (and for all intents we ARE Debian - just not on their server), and 
they've already given Debian permission to distribute.  For the rest of 
non-free, permission to distribute is not an issue, and not the reason 
they're in non-free to begin with.

Re-evaluating non-free is just silly when we're going to "officially" become 
Debian again in a few months, certainly less than a year, anyway (assuming 
Debian gets Sarge out soon).  Heck, Debian doesn't even advertise us, we're 
the bastard child they don't want to talk about, because when they do it 
reignites the argument about which architectures to "officially" support, and 
why... and why not.  NO ONE IS GOING TO CARE ABOUT OUR NON-FREE!


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

Re: /usr/lib vs /usr/libexec

[GOMBAS Gabor]

On Tue, May 10, 2005 at 11:16:54AM +0200, Bernd Eckenfels wrote:

> the bootloader does not need to access the root filesystem. It only loads
> the kernel and the initrd from /boot.

(I assume that /boot is on /. If not, the following still applies to
/boot.)

Well, grub _does_ access the filesystem directly so it needs explicit
support for every filesystem you want to boot from. I think reiserfs is
OK nowadays (I do not use it so I'm not sure). xfs + lilo (from the
XFS FAQ):

No, for root partition installations because the XFS superblock
is written at block zero, where LILO would be installed. This is
to maintain compatibility with the IRIX on-disk format, and will
not be changed.

lvm, raid0, raid5: the boot loader must understand the lvm/raid
descriptors to be able to determine where to load the kernel/initrd from
(and in case of raid5, it has to be able to reconstruct the data using
the parity disk if one of the non-parity chunks is inaccessible). AFAIK
neither lilo nor Grub supports these.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> We do not have that bug, so it's not important to us.

Still, nobody has said.  What filesystems available on Debian have a
better than linear search time for open, and are they used by a
default Debian install?



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

Re: Debian AMD64 Archive Move

[Matthew Garrett]

Ed Cogburn <[EMAIL PROTECTED]> wrote:

> NO ONE IS GOING TO CARE ABOUT OUR NON-FREE!

You're entirely right. After having to read that lot, I'd be impressed
if anyone cared about making sure amd64 shipped with non-free.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Humberto Massa <[EMAIL PROTECTED]> writes:

> What do you think are the original reasons "/" needed to be small?

I know what they are.  PDP-11 boot loaders couldn't access long block
addresses.  This was copied into 32V on the Vax, where it entered
4BSD.



Thomas


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

Re: /usr/lib vs /usr/libexec

[Russell Coker]

On Wednesday 11 May 2005 00:55, GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Tue, May 10, 2005 at 11:16:54AM +0200, Bernd Eckenfels wrote:
> > the bootloader does not need to access the root filesystem. It only loads
> > the kernel and the initrd from /boot.
>
> (I assume that /boot is on /. If not, the following still applies to
> /boot.)

Of course /boot only really needs to be about 20M in size.  It can be 
read-only mounted most of the time (or even entirely umounted), so it's in an 
entirely different category to the rest of the system.

> Well, grub _does_ access the filesystem directly so it needs explicit
> support for every filesystem you want to boot from.

On the system I use to write this email (Fedora):
/boot/grub/xfs_stage1_5
/boot/grub/reiserfs_stage1_5

So I guess that GRUB supports XFS and ReiserFS.

Incidentally if you have a separate partition for /boot (as some people 
recommend doing for reliability issues) then XFS and ReiserFS are bad options 
due to the journals which have overly large minimum sizes.  Ext2/3 really is 
the best option for a /boot file system.  It's only when /boot is on the root 
file system that some other file system may be desired.

> I think reiserfs is 
> OK nowadays (I do not use it so I'm not sure). xfs + lilo (from the
> XFS FAQ):
>
>   No, for root partition installations because the XFS superblock
>   is written at block zero, where LILO would be installed. This is
>   to maintain compatibility with the IRIX on-disk format, and will
>   not be changed.

The simple solution to this is that you don't install LILO on the first block 
of the partition but instead you install it as the boot block of the hard 
disk (IE use /dev/hda instead of /dev/hda1 or whatever).

If you wanted to use LILO with XFS and LVM then I guess that you would have to 
put the LILO boot block on /dev/hda anyway.

The only reason for installing the LILO boot block onto /dev/hda1 instead 
of /dev/hda is for a software RAID-1 installation where you want to have the 
Debian-MBR on /dev/hda and /dev/hdc while /dev/hda1 and /dev/hdc1 have the 
LILO boot blocks.  Apart from that I recommend putting the LILO boot loader 
in the partition table.

> lvm, raid0, raid5: the boot loader must understand the lvm/raid
> descriptors to be able to determine where to load the kernel/initrd from
> (and in case of raid5, it has to be able to reconstruct the data using
> the parity disk if one of the non-parity chunks is inaccessible). AFAIK
> neither lilo nor Grub supports these.

Here is the relevant section of the lilo changelog regarding LVM:

lilo (1:22.6.1-4) unstable; urgency=high

  * debian/patches/13_bad-partition-warn.dpatch:
- Rewrote. Now it adds LVM partitions as a secure partition type to 
install
  LILO in, while leaving the warning for really dangerous partition types.
  It also removes the prompt when the user wants to install LILO on a
  Windows(R) partition.
  * debian/lilo.config:
- Never set to 'false' lilo/runme template. (Closes: #284929)

 -- Andrs Roldn <[EMAIL PROTECTED]>  Thu,  9 Dec 2004 
20:22:14 +


-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
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/~russell/  My home page


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

Re: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

GOMBAS Gabor <[EMAIL PROTECTED]> writes:

> On Tue, May 10, 2005 at 11:16:54AM +0200, Bernd Eckenfels wrote:
>
>> the bootloader does not need to access the root filesystem. It only loads
>> the kernel and the initrd from /boot.
>
> (I assume that /boot is on /. If not, the following still applies to

You've missed the point.  Split / and /boot, that makes sense if it's
necessary.  Splitting / and /usr does not make sense.

Thomas


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

Re: Debian AMD64 Archive Move

[Goswin von Brederlow]

Ed Cogburn <[EMAIL PROTECTED]> writes:

> On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote:
>> On 10283 March 1977, Ed Tomlinson wrote:
>> >> Whats going on == someone needs to check it. Thats it.
>> >
>> > That was the point made by Ed Cogburn.  Its already been checked in the
>> > other arch!  If this is not the case please explain why.  Without that
>> > explanation I am forced to agree with Ed - the problem are political... 
>> > Which is the bane of debian.
>>
>> We are *NOT* Debian
>
>
> We ARE Debian for Heaven's sake!  This move to another server is just 
> TEMPORARY!  We WILL be Debian as soon as sarge gets out and development on 
 

You said it yourself.

> etch picks up.  Who in the world is going to get upset when they know we will 
> soon be part of official Debian, and they've already given permission for 
> Debian to distribute their stuff!  Get real people!
>
> How many non-free packages have been cleared?  Why haven't you at least set 
> up 
> non-free and moved the packages known to be ok into it?  I know for sure that 
> the rogue-like games in non-free are perfectly fine and can brought on-line 
> now, since they and a lot of other stuff is in non-free just because they are 
> "old" pre-GPL software with "don't sell for money" restrictions which make 
> them fail the DFSG test on distribution, but are otherwise fully open-source 
> (and who's earlier authors can no longer be found to ask them if they'd agree 
> to a change to the GPL or some other Free license).
>
> In fact, looking through the non-free docs section, most of that can go in 
> right now because they don't require anyone's permission to distribute since 
> they're in non-free because of the dispute between Debian and FSF over 
> documentation.

Will you pay us for the work and cover legal fees if any should arise?

Seriously, get some patience and don't inflame the situation
please. Things like "most of that" is of zero help in deciding what
can go in and what not. We know most of it can, the question is what
packages are those in particular. We can't just add all of non-free
and say it is mostly OK.

>> thats all you need to get!
>
>
> Hogwash.  This sounds like an extremely defensive response.  How many 
> packages 
> have been cleared for non-free?  Why haven't you just put up a non-free 
> section with the stuff thats been cleared?  Why has it been more than a week, 
> with no non-free section at all, no indication of how the "vetting" process 
> is going, and with you telling us above that we don't need to know anything 
> more?  Now do you understand why I'm just a little bit skeptical?

We had (an empty) non-free right after the dns switch so apt-get
wouldn't fail. And we told you exactly what the status is: "Someone
has to do the work".

> Just establish the non-free section and move everything over.  If anyone 
> complains then just drop the package they're complaining about.  Of course, 
> NO ONE is going to complain since they know we will "become" Debian soon 
> anyway (and for all intents we ARE Debian - just not on their server), and 
> they've already given Debian permission to distribute.  For the rest of 
> non-free, permission to distribute is not an issue, and not the reason 
> they're in non-free to begin with.

The pine author would for one thing.

> Re-evaluating non-free is just silly when we're going to "officially" become 
> Debian again in a few months, certainly less than a year, anyway (assuming 
> Debian gets Sarge out soon).  Heck, Debian doesn't even advertise us, we're 
> the bastard child they don't want to talk about, because when they do it 
> reignites the argument about which architectures to "officially" support, and 
> why... and why not.  NO ONE IS GOING TO CARE ABOUT OUR NON-FREE!

It will be at least 18 month going by the release plans till etch will
be stable and sarge amd64 can be dropped. Considering the track record
of past timelines 2-3 years is probably more accurate. That is a long
time for someone to start suing.

In one point you are right though:

NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With
the exception of nvidia* package it seems. That is the only package
that users missed so far. Please excuse us for not giving it higher
priority than fixing RC bugs or otherwise vital archive maintainance.

MfG
Goswin


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]> you wrote:
>> - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing
>> problems for /boot.
>
> Why is that?

Lvm has its backup data in /etc by default. If you ever need it you
are screwed with / on lvm. Also snapshots and pvmove don't work
(deadlock).

raid0/5 don't have support in the bootloaders.

reiserfs/xfs miss support in bootloaders or their tail usage feature
breaks them.

>> - a larger FS has more chance of failing so you risk having a fully
>> broken system more often
>
> And two file systems have even more chance. One read only file system is
> pretty stable.

Hardly anyone has it read-only nowadays.

>> - /usr can be easily network (shared accross the same arch) mounted
>> while / (due to /etc) can't
>> - / needs functioning device nodes on it while usr can be mounted nodev
>
> I agreee, those arguments and the netboot stuff is an argment for a smaller
> root partition. However our root filesystem is too big anyway.
>
> Greetings
> Bernd

Not all of those arguments work for everyone nor do they all work
together. Every user case is different.

MfG
Goswin


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

Re: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Lvm has its backup data in /etc by default. If you ever need it you
> are screwed with / on lvm. Also snapshots and pvmove don't work
> (deadlock).
>
> raid0/5 don't have support in the bootloaders.
>
> reiserfs/xfs miss support in bootloaders or their tail usage feature
> breaks them.

None of these are arguments for separating /usr and /; they are
arguments for separating /boot and /.

Thomas


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le mardi 10 mai 2005 à 10:21 +0200, GOMBAS Gabor a écrit :
>> On Tue, May 10, 2005 at 05:42:31AM +0200, Bernd Eckenfels wrote:
>> 
>> > > - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing
>> > > problems for /boot.
>> > 
>> > Why is that?
>> 
>> Missing bootloader support.
>
> Which bootloader doesn't support reiserfs?

milo, alilo, silo, ...

>> $ du -sh /etc/gconf
>> 26M /etc/gconf
>> 
>> That's 1/3 of my root fs. It's damn too much.

3.8M/etc/gconf

> Almost all the schemas were already moved out to /usr/share. We plan to
> move the defaults directory structure to /var/lib/gconf after the
> release - at least, the defaults brought by package; we have to keep a
> defaults structure in /etc for local modifications.

Some improvement but still way to big for my taste. Maybe /usr/etc
isn't such a bad idea.

MfG
Goswin


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

Russell Coker <[EMAIL PROTECTED]> writes:

> On Tuesday 10 May 2005 02:18, Goswin von Brederlow 
> <[EMAIL PROTECTED]> wrote:
>> Russell Coker <[EMAIL PROTECTED]> writes:
>> > It seems to me that /usr/libexec is a better name for such things, and
>> > having the same directory names used across distributions provides real
>> > benefits (copying config files and binaries from other distributions when
>> > a bug stops a server working and it's REALLY important to get it fixed
>> > fast).
>> >
>> > Should we change some of these to /usr/libexec?
>>
>> That would be /usr/libexec/arch-os/postfix vs /usr/lib/arch-os/postfix
>> then.
>>
>> If you consider any change then please include the multiarch changes
>> at the same time. No point doing 2 transitions for etch.
>
> Why would it be desirable to have arch-os directories under libexec?

32bit mozilla with flash plugin and 64bit mozilla without. A lot of
people seem to want that.

MfG
Goswin


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

Russell Coker <[EMAIL PROTECTED]> writes:

> On Tuesday 10 May 2005 10:36, Goswin von Brederlow 
> <[EMAIL PROTECTED]> wrote:
>> - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing
>> problems for /boot.
>
> I believe that there are LILO patches for /boot on LVM.  There's no reason 
> why 
> GRUB and other boot loaders couldn't be updated in the same manner.  The most 
>...

They don't now and there are way more bootloaders than just grub and
lilo.

> But generally the best solution to such problems is to have a separate 
> partition for /boot.  Red Hat defaults to an LVM install (including LVM root) 
> with a regular 100M partition for /boot, that works well.

No lvm backup data available in case of superblock corruption. Bad
idea. No booting with init=/bin/sh to patch things back together as /
can't be mounted. Bad idea again.

/ on lvm is a major pain in case of error and if you already need a
seperate / partition adding another for /boot is a bit stupid.

The best solution is a regular 100-200Mb partition for / including
/boot imho.

>> - a larger FS has more chance of failing so you risk having a fully
>> broken system more often
>
> I doubt that.
>
> I think that a FS that is written less has less chance of failing, which is 
> an 
> extra reason for having /var and /home on different file systems to /.  If 
> you have /var and /home on separate partitions then / should not get many 
> writes and should have little chance of corruption regardless of size.
>
>> - /usr can be easily network (shared accross the same arch) mounted
>> while / (due to /etc) can't
>
> Why is this desirable in the days of large disks?  There is no machine for 
> which I am responsible which has a disk space issue other than my laptop.  
> None of my machines has /usr taking any significant portion of the disk 
> space.

I have two recently bought systems without disk. Just a small flash to
boot from. Those mips based wireless and dsl routers from linksys and
similar are very popular as well as meshcubes.

>> - / needs functioning device nodes on it while usr can be mounted nodev
>
> The current Fedora setup of having an initrd create device nodes on a tmpfs 
> is 
> working quite well and could be copied for Debian.
>
>> - a small / can be replicated across many disks to ensure the system
>> always comes up and e.g. at least send an email to the admin. / can
>> even be an initrd
>
> How big can an initrd be?  The default is 4M which isn't going to do well 
> for /.

The limit is either 1GB or slightly below 2GB for 32bit (+amd64)
systems. Less for mips I guess due to the hardwired address space.

Enough ram provided of course (4GB ram for a 2GB ramdisk as it gets
copied around by the kernel).

The problem is more how much ram do you want to spend on it than how
much linux can use.

MfG
Goswin


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

cas1no, play everywhere - cellphones, webtv, aol.....

[Samson]

Try your luck with our new brand cas1no. +30% for every diposit.
One hour payout, never fast before. Try play for free.
In this country men seem to live for action as long as they can and sink into 
apathy when they retire. http://wtp.ca.wehiuhef.com/ An actor is a guy who, if 
you ain't talking about him, he ain't listening. To make oneself an object, to 
make oneself passive, is a very different thing from being a passive object.
to get out please read on page above To see him act is like reading 
Shakespeare by flashes of lightning. I just stopped playing bitches on wheels 
and peoples' mothers. I have only a few more years to kick up my heels!

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

Re: /usr/lib vs /usr/libexec

[Josselin Mouette]

Le mardi 10 mai 2005 à 17:27 +0200, Goswin von Brederlow a écrit :
> > Almost all the schemas were already moved out to /usr/share. We plan to
> > move the defaults directory structure to /var/lib/gconf after the
> > release - at least, the defaults brought by package; we have to keep a
> > defaults structure in /etc for local modifications.
> 
> Some improvement but still way to big for my taste. Maybe /usr/etc
> isn't such a bad idea.

Whoa? Once this move is made, there will be nothing in /etc unless the
system administrator explicitly does something about it.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Bug#308495: general: pmud does not turn off display

[Jeffrey B. Green]

Package: general
Severity: grave

When I close the lid on my iBook (clamshell, c.2000), pmud creates a
screen with text on it, e.g. black screen with white text, but does
not turn the screen off. It is definitely noticeable if the machine is
sitting in a dark room. The green power light does go into pulsating
mode.

apmd has been purged though it does have a remnant file in /etc/power,
e.g. apm|. (I assume it belongs to apmd.)


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.8-powerpc
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

mrtg package problems

[Laszlo Boszormenyi]

Hi,

The mrtg and related packages seems to be orphaned. Shiju p. Nair is
last done an upload at 2004 April the 6th. Since then, there are only
NMUs, like it was NMUed constantly since 2002. The package is a bit
bad shape, would be good if someone look into them; there are even
seven years old bugs, but well, others are only five or three years
old. Is there any better package for this task, so mrtg can be
dropped maybe? But as some bugs have patch included, maybe someone
else can prepare a bugfixing version.
On the other hand, I think 2.11.1-1.1 should be pushed to Sarge.

Regards,
Laszlo/GCS


signature.asc
Description: This is a digitally signed message part

Re: /usr/lib vs /usr/libexec

[Russell Coker]

On Wednesday 11 May 2005 01:39, Goswin von Brederlow 
<[EMAIL PROTECTED]> wrote:
> Russell Coker <[EMAIL PROTECTED]> writes:
> > On Tuesday 10 May 2005 10:36, Goswin von Brederlow
> >
> > <[EMAIL PROTECTED]> wrote:
> >> - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing
> >> problems for /boot.
> >
> > I believe that there are LILO patches for /boot on LVM.  There's no
> > reason why GRUB and other boot loaders couldn't be updated in the same
> > manner.  The most ...
>
> They don't now and there are way more bootloaders than just grub and
> lilo.

Yes there are way more boot loaders than GRUB and LILO.  The task for the 
developers of such boot loaders is easier because they can grab some source 
from GRUB and LILO for some of these things.

> > But generally the best solution to such problems is to have a separate
> > partition for /boot.  Red Hat defaults to an LVM install (including LVM
> > root) with a regular 100M partition for /boot, that works well.
>
> No lvm backup data available in case of superblock corruption. Bad
> idea. No booting with init=/bin/sh to patch things back together as /
> can't be mounted. Bad idea again.

If you are making backups of your machines (generally accepted to be a good 
idea) then LVM metadata will be included in such backups.  If you don't have 
any backups then just reinstall the machine - it apparently doesn't have any 
data worth keeping.

> / on lvm is a major pain in case of error and if you already need a
> seperate / partition adding another for /boot is a bit stupid.

/ on LVM allows for snapshot backups which are the most convenient method of 
backup.

> >> - /usr can be easily network (shared accross the same arch) mounted
> >> while / (due to /etc) can't
> >
> > Why is this desirable in the days of large disks?  There is no machine
> > for which I am responsible which has a disk space issue other than my
> > laptop. None of my machines has /usr taking any significant portion of
> > the disk space.
>
> I have two recently bought systems without disk. Just a small flash to
> boot from. Those mips based wireless and dsl routers from linksys and
> similar are very popular as well as meshcubes.

How much storage do the wireless and DSL routers have?

Flash devices up to 1G in size are quite common nowadays.  Distributions that 
can work with 32M of storage are still available (Familiar is one example).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
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/~russell/  My home page


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

Re: /usr/lib vs /usr/libexec

[Humberto Massa]

Thomas Bushnell BSG wrote:
Andrew Suffield <[EMAIL PROTECTED]> writes:
 

We do not have that bug, so it's not important to us.
   

Still, nobody has said.  What filesystems available on Debian have a
better than linear search time for open, and are they used by a
default Debian install?
 

These are two questions: Q: What filesystems... ? A: Every one of them 
with the possible exception of FAT and Minix. Q: are they used by a 
default? A: Last time I installed Debian (15 days ago), it asked me if I 
wanted my partition ext3, xfs, or reiserfs IIRC; I chose reiserfs, and I 
am pretty sure finding a file in a directory in reiserfs is O(log n) in 
the worse case. (Actually, I think that except for HUGE directories [far 
larger than /usr/lib] it accesses two or three blocks of disk in every 
case, hence being O(1)).

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

Re: /usr/lib vs /usr/libexec

[Russell Coker]

On Wednesday 11 May 2005 01:28, Goswin von Brederlow 
<[EMAIL PROTECTED]> wrote:
> > Why would it be desirable to have arch-os directories under libexec?

On fedora-devel Bill Nottingham suggested having /usr/lib vs /usr/lib64 for 
programs that care about such things and /usr/libexec for programs that 
don't.

> 32bit mozilla with flash plugin and 64bit mozilla without. A lot of
> people seem to want that.

Bill's idea seems to work in that case.  Although as you would need different 
names in /usr/bin it might make sense to just name the libexec files with the 
same extension as the file in /usr/bin that launches them.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
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/~russell/  My home page


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

Re: /usr/lib vs /usr/libexec

[Humberto Massa]

Thomas Bushnell BSG wrote:
You've missed the point.  Split / and /boot, that makes sense if it's
necessary.  Splitting / and /usr does not make sense.
 

Sure it does. Especially if you want / to be in a Flash disk and /usr to 
be somewhere else in the network.
HTH
Massa

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

Re: /usr/lib vs /usr/libexec

[Anthony DeRobertis]

Thomas Bushnell BSG wrote:

> Still, nobody has said.  What filesystems available on Debian have a
> better than linear search time for open,

reiserfs, ext2/3 (with dir_index), and probably others.


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

Re: /usr/lib vs /usr/libexec

[Christoph Hellwig]

On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote:
> These are two questions: Q: What filesystems... ? A: Every one of them 
> with the possible exception of FAT and Minix.

ext2 doesn't.


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

Re: /usr/lib vs /usr/libexec

[Humberto Massa]

Christoph Hellwig wrote:
On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote:
 

These are two questions: Q: What filesystems... ? A: Every one of them
   

 

with the possible exception of FAT and Minix.
   

ext2 doesn't.
 

With dir_index, yes it does.

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

cogito_0.10-2 available, and request for Sponsor

[Sebastian Kuzminsky]

cogito_0.10-2 is up, it now puts the internal scripts and the shell
library in /usr/share/cogito instead of /usr/lib/cogito.  Thanks to Ben
Finney and Peter Samuelson for cluing me in.


You can get the package here:

http://highlab.com/~seb/debian


The only problem I know of with the package now is the missing manpages.
The upstream people are working feverishly on this, so I want to wait
a week or so and see what they come up with.


I'm a wanna-be new maintainer starting out the New Maintainer process.
I'm looking for a Debian Sponsor to upload this package to the archive.
I'm also looking to have my GPG key signed (I live in Colorado, USA),
and for an Advocate.




--
Sebastian


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

Re: mrtg package problems

[Adam Majer]

Laszlo Boszormenyi wrote:

>Hi,
>
>The mrtg and related packages seems to be orphaned. Shiju p. Nair is
>last done an upload at 2004 April the 6th. Since then, there are only
>NMUs, like it was NMUed constantly since 2002. The package is a bit
>bad shape, would be good if someone look into them; there are even
>seven years old bugs, but well, others are only five or three years
>old. Is there any better package for this task, so mrtg can be
>dropped maybe? But as some bugs have patch included, maybe someone
>else can prepare a bugfixing version.
>On the other hand, I think 2.11.1-1.1 should be pushed to Sarge.
>
>

Currently there are two packages that he maintains,

http://qa.debian.org/[EMAIL PROTECTED]

*libnet**-easytcp-perl
**mrtg

I would like to maintain mrtg since I do use it. As to the other
package, it probably should be orphaned.

Anyway, I will try to take care of the problem. I'll see if I can
contact Shiju and if there is no response by end of the month, I'll
orphan the packages and take over mrtg, unless someone has a problem.

- Adam

*


signature.asc
Description: OpenPGP digital signature

Re: /usr/lib vs /usr/libexec

[Christoph Hellwig]

On Tue, May 10, 2005 at 02:21:50PM -0300, Humberto Massa wrote:
> >ext2 doesn't.
> >
> With dir_index, yes it does.

If you want to forward port a three year old patch full of bugs and
incompatible to the dir_index used in ext3 - all luck to you.

All debian kernel-image packages don't have it for sure.


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

Re: Test of upgrade from Woody -> Sarge

[Benjamin Mesing]

> Manual edit of /etc/apt/sources.list and apt-get update ; apt-get
> dist-upgrade. [NOTE: I'm fairly sure the archive layout changed for
> non-US/main between Woody -> Sarge and I had problems here. Could be a
> show stopper as not immediately obvious what to change]
As far as I've read the list recently, the recommanded way to update
your distribution is using "aptitude dist-upgrade", which should do a
much better job in resolving dependencies.

Greetings Ben

-- 
Please do not sent any email to the [EMAIL PROTECTED] - all email not
originating from the mailing list will be deleted automatically. Use the
reply to address instead.


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

Re: Debian AMD64 Archive Move

[Ed Cogburn]

On Tuesday 10 May 2005 11:19am, Goswin von Brederlow wrote:
> Ed Cogburn <[EMAIL PROTECTED]> writes:
> > On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote:
> > In fact, looking through the non-free docs section, most of that can go
> > in right now because they don't require anyone's permission to distribute
> > since they're in non-free because of the dispute between Debian and FSF
> > over documentation.
>
> Will you pay us for the work and cover legal fees if any should arise?


Sure.  Because any rational person knows it won't happen.  Give us one 
reasonable example of why some one would waste time and money to sue the 
amd64.debian.net server owner in this matter, when they have absolutely 
nothing to gain, and potentially a lot to LOSE if the judge gets angry about 
the pointlessness of their suit?  This would happen in Germany, and the 
German judicial system hasn't yet become as screwed up as the American 
system.  Besides, by the time they FIND OUT, we'll be officially part of 
Debian anyway!


> Seriously, get some patience and don't inflame the situation
> please. Things like "most of that" is of zero help in deciding what
> can go in and what not. We know most of it can, the question is what
> packages are those in particular. We can't just add all of non-free
> and say it is mostly OK.


Yes you can.  That's my point.  Non-free has already been vetted by Debian 
itself, and we are part of Debian.  Any rational judge will see that, if 
given evidence by the Debian organization itself (see below).


> > Just establish the non-free section and move everything over.  If anyone
> > complains then just drop the package they're complaining about.  Of
> > course, NO ONE is going to complain since they know we will "become"
> > Debian soon anyway (and for all intents we ARE Debian - just not on their
> > server), and they've already given Debian permission to distribute.  For
> > the rest of non-free, permission to distribute is not an issue, and not
> > the reason they're in non-free to begin with.
>
> The pine author would for one thing.


Then load everything up but pine, if that's the only one you know of.  I've 
already listed more packages that I know about, and I'm "just" a regular 
user.  I'll bet if you had asked on d.d you could have quickly put together a 
list of 30 - 50 packages which were ok.  So why nothing in over a week?  Are 
you holding up all of non-free just because of 1 package?

And what is the point?  We are Debian.  It doesn't matter which server we're 
on.


> It will be at least 18 month going by the release plans till etch will
> be stable and sarge amd64 can be dropped. Considering the track record
> of past timelines 2-3 years is probably more accurate. That is a long
> time for someone to start suing.


Hogwash again.  We aren't talking about *release* dates, Goswin, we're only 
talking about how long it takes before debian.org is ready to move the amd64 
port onto it.  Once sarge is out, everybody can get back to moving *forward*, 
as opposed to running in place right now, which means the ftpmasters of 
debian.org can do what they need to do to make room for pure64 *Sid*, and 
move it over so we get synced up as Etch.  Sarge can stay where it is, that's 
not the issue.  Getting the *next* Debian AMD64 port onto debian.org is not 
going to take 3 years.


> In one point you are right though:
>
> NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With
> the exception of nvidia* package it seems. That is the only package
> that users missed so far.


Right, only the relatively few users of this technically unofficial and mostly 
unknown-to-the-world official Debian port have noticed you left non-free 
behind.  So explain to us why you believe any copyright holder of one of 
these problem packages OUTSIDE OF DEBIAN is going to find out about this, and 
for some irrational reason bothers to sue amd64.debian.net, because it isn't 
on debian.org (but its contents *is* Debian)?  Geez, compared to that, I'd 
say me getting hit by a meteorite when I next leave my apartment is a 
guaranteed certainty... heck, let me go write my will before I go to the 
grocery store.

All you need is official blessing from Debian proper, in writing, or at least 
publicly announced on the net, that yes, the AMD64 port on amd64.debian.net 
is officially part of Debian, and isn't on debian.org only because of 
technical problems, but will be physically integrated soon (which is all 
true).  With that, you don't have to worry about any lawsuits.  So please 
stop with this weird excuse.


> Please excuse us for not giving it higher 
> priority than fixing RC bugs or otherwise vital archive maintainance.


But you do have the time to re-verify non-free all over again?  So you've 
wasted a whole week on this, *but* you'd rather be doing "vital" work.  
Uh-huh.  Well, I do agree with you on one thing Goswin, we all have important 
things that need to be done,  so please stop this pointless exe

Re: Debian AMD64 Archive Move

[Kenneth Pronovici]

On Tue, May 10, 2005 at 01:07:30PM -0400, Ed Cogburn wrote:
> On Tuesday 10 May 2005 11:19am, Goswin von Brederlow wrote:
> > Ed Cogburn <[EMAIL PROTECTED]> writes:
> > > On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote:
> > > In fact, looking through the non-free docs section, most of that can go
> > > in right now because they don't require anyone's permission to distribute
> > > since they're in non-free because of the dispute between Debian and FSF
> > > over documentation.
> >
> > Will you pay us for the work and cover legal fees if any should arise?
> 
> 
> Sure.  Because any rational person knows it won't happen.  

Odd.  I'm a rational person, and I don't know that.  Maybe I'm not
really rational.  I feel rational though.  Hmm.

> > Seriously, get some patience and don't inflame the situation
> > please. Things like "most of that" is of zero help in deciding what
> > can go in and what not. We know most of it can, the question is what
> > packages are those in particular. We can't just add all of non-free
> > and say it is mostly OK.
> 
> Yes you can.  That's my point.  Non-free has already been vetted by Debian 
> itself, and we are part of Debian.  Any rational judge will see that, if 
> given evidence by the Debian organization itself (see below).

Ah, there we go with that word again...

> > In one point you are right though:
> >
> > NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With
> > the exception of nvidia* package it seems. That is the only package
> > that users missed so far.
> 
> Right, only the relatively few users of this technically unofficial and 
> mostly 
> unknown-to-the-world official Debian port have noticed you left non-free 
> behind.  So explain to us why you believe any copyright holder of one of 
> these problem packages OUTSIDE OF DEBIAN is going to find out about this, 

Well, first off, you just posted about it on a public list...duh.

> and for some irrational reason bothers to sue amd64.debian.net,
> because it isn't on debian.org (but its contents *is* Debian)?  

And there's that word AGAIN.

> Geez, compared to that, I'd say me getting hit by a meteorite when I
> next leave my apartment is a guaranteed certainty... heck, let me go
> write my will before I go to the grocery store.

Well, we can hope, because then this stupid thread might die.

> All you need is official blessing from Debian proper, in writing, or at least 
> publicly announced on the net, that yes, the AMD64 port on amd64.debian.net 
> is officially part of Debian, and isn't on debian.org only because of 
> technical problems, but will be physically integrated soon (which is all 
> true).  With that, you don't have to worry about any lawsuits.  So please 
> stop with this weird excuse.

And you can categorically state this on what authority?  Can we assume
you're a lawyer in whatever municipality has jurisdiction?  Can you even
tell me what municipality has jurisdiction?  Sheesh, you might have a
decent argument if you constrained yourself to facts instead of
assertions...

> But you do have the time to re-verify non-free all over again?  So you've 
> wasted a whole week on this

Oh my.  A *whole week*?  I can't believe it.  Compared to how long it
took to release sarge, that's... let's see... er... insignificant.
That's the word I'm looking for.

You know what - I don't give a shit about this subject, but I'm getting
tired of posts like this one.   Chill out.

KEN

-- 
Kenneth J. Pronovici <[EMAIL PROTECTED]>


pgpfSDySjC09N.pgp
Description: PGP signature

Re: mrtg package problems

[Jeroen van Wolffelaar]

On Tue, May 10, 2005 at 06:07:44PM +0200, Laszlo Boszormenyi wrote:
> Hi,
> 
> The mrtg and related packages seems to be orphaned. Shiju p. Nair is
> last done an upload at 2004 April the 6th. Since then, there are only
> NMUs, like it was NMUed constantly since 2002. The package is a bit
> bad shape, would be good if someone look into them; there are even
> seven years old bugs, but well, others are only five or three years
> old. Is there any better package for this task, so mrtg can be
> dropped maybe? But as some bugs have patch included, maybe someone
> else can prepare a bugfixing version.
> On the other hand, I think 2.11.1-1.1 should be pushed to Sarge.

I contacted Shiju for the last time on 30 March 2005, no response yet.
While I'm waiting for a response/following up/possibly taking consequent
actions if no response is forthcoming, people can NMU his packages (as
one can do always) to fix bugs that are annoying people.

Shiju, can you please reply to my mail from March 30?

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

pine license

[Jaldhar H. Vyas]

[was Re: Debian AMD64 Archive Move]

On Tue, 10 May 2005, Goswin von Brederlow wrote:

> > Just establish the non-free section and move everything over.  If anyone
> > complains then just drop the package they're complaining about.  Of course,
> > NO ONE is going to complain since they know we will "become" Debian soon
> > anyway (and for all intents we ARE Debian - just not on their server), and
> > they've already given Debian permission to distribute.  For the rest of
> > non-free, permission to distribute is not an issue, and not the reason
> > they're in non-free to begin with.
>
> The pine author would for one thing.
>

Can we stop with that particular piece of FUD?  The authors of Pine have
no problems with third-party redistribution of of their software as long
as the version number contains an L to show it is not the pristine UW
version.  We don't distribute it because we follow the letter of their
license which unfortunately doesn't match their intentions and even more
unfortunately they are not in a hurry to fix.  But the authors of Pine
don't mind at all.  They even have a page of links to third party ports [1]
for heavens sake!

[1] http://www.washington.edu/pine/getpine/non-UW.html

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/


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

Bug#308521: ITP: mousepad -- simple Xfce oriented text editor

[Emanuele Rocca]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers <[EMAIL PROTECTED]>


* Package name: mousepad
  Version : 0.2.2
  Upstream Author : Erik Harrison <[EMAIL PROTECTED]>
* URL : http://www.xfce.org/~benny/apps.html
* License : GPL
  Description : simple Xfce oriented text editor

 Mousepad is a graphical text editor for Xfce based on Leafpad. 
 .
 The initial reason for Mousepad was to provide printing support, which would
 have been difficult for Leafpad for various reasons.
 .
 Although some features are under development, currently Mousepad has the
 following features:
   * Complete support for UTF-8 text
   * Cut/Copy/Paste and Select All text
   * Search and Replace
   * Font selecton
   * Word Wrap
   * Character coding selection
   * Auto character coding detection (UTF-8 and some codesets)
   * Manual codeset setting
   * Infinite Undo/Redo by word
   * Auto Indent
   * Multi-line Indent
   * Display line numbers
   * Drag and Drop
   * Printing

ciao,   
ema


signature.asc
Description: Digital signature

Re: packages missing from sarge

[Jaldhar H. Vyas]

On Sat, 7 May 2005, Joey Hess wrote:

> So here is a list (from update-excuses) of all 491 packages that is
> being held out of sarge[1]. If you've already done all you can on the RC
> bugs on packages in sarge, take a look over it and if you spot anything
> important or generally worth fixing, point it out, or just work on it.
> Remember that due to the freeze you'll need to ask on debian-release to
> get any fixed packages accepted back into sarge.
>

[...]

> pgp4pine

I fixed the RC and other bugs in this several weeks ago but it is in
contrib so does it need a nudge to be autobuilt?

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/


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

Re: Debian AMD64 Archive Move

[Wouter Verhelst]

On Tue, May 10, 2005 at 01:07:30PM -0400, Ed Cogburn wrote:
> On Tuesday 10 May 2005 11:19am, Goswin von Brederlow wrote:
> > Seriously, get some patience and don't inflame the situation
> > please. Things like "most of that" is of zero help in deciding what
> > can go in and what not. We know most of it can, the question is what
> > packages are those in particular. We can't just add all of non-free
> > and say it is mostly OK.
> 
> Yes you can.  That's my point.  Non-free has already been vetted by Debian 
> itself, and we are part of Debian.  Any rational judge will see that, if 
> given evidence by the Debian organization itself (see below).

Are you a lawyer?

If not, I'm not particularly inclined to believe you on this count.

> > > Just establish the non-free section and move everything over.  If anyone
> > > complains then just drop the package they're complaining about.  Of
> > > course, NO ONE is going to complain since they know we will "become"
> > > Debian soon anyway (and for all intents we ARE Debian - just not on their
> > > server), and they've already given Debian permission to distribute.  For
> > > the rest of non-free, permission to distribute is not an issue, and not
> > > the reason they're in non-free to begin with.
> >
> > The pine author would for one thing.
> 
> Then load everything up but pine, if that's the only one you know of.

It's the only one we know of /now/. There might be more. That's the
whole problem.

[rest of blatter snipped, doesn't make sense anyway]

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

GOMBAS Gabor <[EMAIL PROTECTED]> writes:

> On Tue, May 10, 2005 at 11:16:54AM +0200, Bernd Eckenfels wrote:
>
>> the bootloader does not need to access the root filesystem. It only loads
>> the kernel and the initrd from /boot.
>
> (I assume that /boot is on /. If not, the following still applies to
> /boot.)
>
> Well, grub _does_ access the filesystem directly so it needs explicit
> support for every filesystem you want to boot from. I think reiserfs is
> OK nowadays (I do not use it so I'm not sure). xfs + lilo (from the
> XFS FAQ):
>
>   No, for root partition installations because the XFS superblock
>   is written at block zero, where LILO would be installed. This is
>   to maintain compatibility with the IRIX on-disk format, and will
>   not be changed.

That only applies to the bootloader on the partition or the FS on the
drive directly. With partitions and the bootloader in the mbr that
should not matter. What I was talking about is using a block to store
the tail end of multiple files more efficiently. Didn't xfs do that?

> lvm, raid0, raid5: the boot loader must understand the lvm/raid
> descriptors to be able to determine where to load the kernel/initrd from
> (and in case of raid5, it has to be able to reconstruct the data using
> the parity disk if one of the non-parity chunks is inaccessible). AFAIK
> neither lilo nor Grub supports these.

It would be nice enough if it would work with a working raid. The
problem there (raid 0 and 5) is that it would need to gather the
scattered blocks from multiple devices.

> Gabor


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le mardi 10 mai 2005 à 17:27 +0200, Goswin von Brederlow a écrit :
>> > Almost all the schemas were already moved out to /usr/share. We plan to
>> > move the defaults directory structure to /var/lib/gconf after the
>> > release - at least, the defaults brought by package; we have to keep a
>> > defaults structure in /etc for local modifications.
>> 
>> Some improvement but still way to big for my taste. Maybe /usr/etc
>> isn't such a bad idea.
>
> Whoa? Once this move is made, there will be nothing in /etc unless the
> system administrator explicitly does something about it.

Ok, so we are just not there yet (or I have garbage left in etc).

MfG
Goswin


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

Re: Debian AMD64 Archive Move

[Joerg Jaspert]

On 10285 March 1977, Ed Cogburn wrote:

>> Will you pay us for the work and cover legal fees if any should arise?
> Sure.  Because any rational person knows it won't happen.

Laywers arent rationale.

> Give us one reasonable example of why some one would waste time and
> money to sue the  amd64.debian.net server owner in this matter, when
> they have absolutely nothing to gain, and potentially a lot to LOSE
> if the judge gets angry about the pointlessness of their suit?

With that logic: Why does SCO still exist?

> Yes you can.  That's my point.  Non-free has already been vetted by Debian 
> itself, and we are part of Debian.  Any rational judge will see that, if 
> given evidence by the Debian organization itself (see below).

No we cant. Just get a CLUE, we are *NOT* debian. We are as similar as
one can get, but the Debian stuff is on .d.o hosts.

> user.  I'll bet if you had asked on d.d you could have quickly put together a 
> list of 30 - 50 packages which were ok.  So why nothing in over a week?  Are 
> you holding up all of non-free just because of 1 package?

No. Because of all the crap that is in there and because WE HAVE MORE
IMPORTANT THINGS TODO - which includes reading crap from someone who
just trolls on lists and not does any work for it.

> And what is the point?  We are Debian.  It doesn't matter which server we're 
> on.

We arent, get a clue.

> Hogwash again.  We aren't talking about *release* dates, Goswin, we're only 
> talking about how long it takes before debian.org is ready to move the amd64 
> port onto it.  Once sarge is out, everybody can get back to moving *forward*, 
> as opposed to running in place right now, which means the ftpmasters of 
> debian.org can do what they need to do to make room for pure64 *Sid*, and 
> move it over so we get synced up as Etch.  Sarge can stay where it is, that's 
> not the issue.  Getting the *next* Debian AMD64 port onto debian.org is not 
> going to take 3 years.

Hell, please go and read what amd64.d.n is and you would see what a mess
you just wrote. amd64.d.n will exist as long as Sarge is there.

And actually there was one who just went over the non-free crap, looking
at the licenses, giving us something to work with.
If non-free is so important for you - why did you wasted time writing
such mails and havent done that work yourself?

Thats my last mail in this thread, I have more important things todo.

-- 
bye Joerg
Some AM after a mistake:
Sigh.  One shouldn't AM in the early AM, as it were.  


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

Christoph Hellwig <[EMAIL PROTECTED]> writes:

> On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote:
>> These are two questions: Q: What filesystems... ? A: Every one of them 
>> with the possible exception of FAT and Minix.
>
> ext2 doesn't.

Convert it to utilize directory hashing. The ability is there but iirc
isn't used by default.

MfG
Goswin


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

Re: pine license

[Goswin von Brederlow]

"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes:

> [was Re: Debian AMD64 Archive Move]
>
> On Tue, 10 May 2005, Goswin von Brederlow wrote:
>
>> > Just establish the non-free section and move everything over.  If anyone
>> > complains then just drop the package they're complaining about.  Of course,
>> > NO ONE is going to complain since they know we will "become" Debian soon
>> > anyway (and for all intents we ARE Debian - just not on their server), and
>> > they've already given Debian permission to distribute.  For the rest of
>> > non-free, permission to distribute is not an issue, and not the reason
>> > they're in non-free to begin with.
>>
>> The pine author would for one thing.
>>
>
> Can we stop with that particular piece of FUD?  The authors of Pine have
> no problems with third-party redistribution of of their software as long
> as the version number contains an L to show it is not the pristine UW
> version.  We don't distribute it because we follow the letter of their
> license which unfortunately doesn't match their intentions and even more
> unfortunately they are not in a hurry to fix.  But the authors of Pine
> don't mind at all.  They even have a page of links to third party ports [1]
> for heavens sake!
>
> [1] http://www.washington.edu/pine/getpine/non-UW.html

Ok, I stand corrected.

The pine author doesn't care, he just mistakenly wrote he would.

Doesn't solve the legal problem for us or debian. And it is just one
of many packages.

MfG
Goswin


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

Russell Coker <[EMAIL PROTECTED]> writes:

> On Wednesday 11 May 2005 01:39, Goswin von Brederlow 
> <[EMAIL PROTECTED]> wrote:
>> / on lvm is a major pain in case of error and if you already need a
>> seperate / partition adding another for /boot is a bit stupid.
>
> / on LVM allows for snapshot backups which are the most convenient method of 
> backup.

Except that the kernel freezes the device because the DM lock and
device node updating deadlock.

Might work with udev or devfs, haven't tried that.


>> >> - /usr can be easily network (shared accross the same arch) mounted
>> >> while / (due to /etc) can't
>> >
>> > Why is this desirable in the days of large disks?  There is no machine
>> > for which I am responsible which has a disk space issue other than my
>> > laptop. None of my machines has /usr taking any significant portion of
>> > the disk space.
>>
>> I have two recently bought systems without disk. Just a small flash to
>> boot from. Those mips based wireless and dsl routers from linksys and
>> similar are very popular as well as meshcubes.
>
> How much storage do the wireless and DSL routers have?
>
> Flash devices up to 1G in size are quite common nowadays.  Distributions that 
> can work with 32M of storage are still available (Familiar is one example).

16-64MB depending on model.

Adding a big usb stick or CF card for /usr makes a very nice and quite
router.

MfG
Goswin


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

Re: /usr/lib vs /usr/libexec

[Goswin von Brederlow]

Russell Coker <[EMAIL PROTECTED]> writes:

> On Wednesday 11 May 2005 01:28, Goswin von Brederlow 
> <[EMAIL PROTECTED]> wrote:
>> > Why would it be desirable to have arch-os directories under libexec?
>
> On fedora-devel Bill Nottingham suggested having /usr/lib vs /usr/lib64 for 
> programs that care about such things and /usr/libexec for programs that 
> don't.
>
>> 32bit mozilla with flash plugin and 64bit mozilla without. A lot of
>> people seem to want that.
>
> Bill's idea seems to work in that case.  Although as you would need different 
> names in /usr/bin it might make sense to just name the libexec files with the 
> same extension as the file in /usr/bin that launches them.

What about mips O32, N32, N64 abis?

/lib, /lib32 and /lib64?

What about i386 knetbsd and linux?

The multiarch /arch-os/ path is already present in the toolchain for
many things including include files and libs and works for all cases
of multiarch in a clean way. The lib{,32,64} subdirs are different on
every arch, confusing and insuffient for the bsd case.

MfG
Goswin


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

Re: mrtg package problems

[Laszlo Boszormenyi]

Hi,

On Tue, 2005-05-10 at 12:23 -0500, Adam Majer wrote:
> Currently there are two packages that he maintains,
 Yup.

> I would like to maintain mrtg since I do use it. As to the other
> package, it probably should be orphaned.
 OK, please check the bugs, review patches etc. for mrtg.
I may even sponsor it if you need it. A company I am contact
with, is just checking it, but they may switch to netmrg.

> Anyway, I will try to take care of the problem. I'll see if I can
> contact Shiju and if there is no response by end of the month, I'll
> orphan the packages and take over mrtg, unless someone has a problem.
 I am OK with it, even if I am only a simple DD without too much words.
Anyway, you can do NMUs meanwhile as Jeroen already wrote about it.

Regards,
Laszlo/GCS


signature.asc
Description: This is a digitally signed message part

Bug#308533: ITP: gstat -- A program for multivariable geostatistical modelling, prediction and simulation

[Francesco Paolo Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" <[EMAIL PROTECTED]>

* Package name: gstat
  Version : 2.4.4
  Upstream Author : Edzer J. Pebesma <[EMAIL PROTECTED]> et al.
* URL : http://www.gstat.org/
* License : GPL
  Description : A program for multivariable geostatistical modelling, 
prediction and simulation

Gstat is an open source (GPL) computer code for multivariable
geostatistical modelling, prediction and simulation, and has been around
from  1997. In the original  form, gstat  is a  stand-alone executable,
interfaced to various GIS (including GRASS 6). 
As  of 2003, the gstat functionaly  is also available as an S extension, 
either as R package or S-Plus library.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

-- 
Francesco P. Lovergine


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

Re: /usr/lib vs /usr/libexec

[Josselin Mouette]

Le mardi 10 mai 2005 à 21:37 +0200, Goswin von Brederlow a écrit :
> Josselin Mouette <[EMAIL PROTECTED]> writes:
> 
> > Le mardi 10 mai 2005 à 17:27 +0200, Goswin von Brederlow a écrit :
> >> > Almost all the schemas were already moved out to /usr/share. We plan to
> >> > move the defaults directory structure to /var/lib/gconf after the
> >> > release - at least, the defaults brought by package; we have to keep a
> >> > defaults structure in /etc for local modifications.
> >> 
> >> Some improvement but still way to big for my taste. Maybe /usr/etc
> >> isn't such a bad idea.
> >
> > Whoa? Once this move is made, there will be nothing in /etc unless the
> > system administrator explicitly does something about it.
> 
> Ok, so we are just not there yet (or I have garbage left in etc).

Yes, this is planned for etch. The exact implementation hasn't been
decided yet, because this is quite a drastic change.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: This is a digitally signed message part

Re: packages missing from sarge

[Adrian Bunk]

On Sun, May 08, 2005 at 03:54:46AM -0700, Steve Langasek wrote:
> 
> Yes, it's called "garbage in, garbage out".  If people aren't going to file
> bugs at the proper severity, and if package maintainers aren't going to
> treat release-critical bugs with the appropriate urgency when they *are*
> filed at the wrong severity, there's no way in hell anyone is going to know
> there's a problem.
> 
> It's not the metric that's broken here.

If your release management is based on the assumption all bugs in Debian 
were at the correct severity and tagged correctly, your release 
management is based on an assumption that isn't true.

See #302282 for an example where even you yourself tagged a bug wrongly 
as "sid"...


And since you say the package maintainers were responsible for correct 
bug severities:

How often does a quick NMU that gives a fast improvement in the RC 
bugs metric hide the real problem that the maintainer is completely or 
partially MIA?

> Steve Langasek

cu
Adrian

BTW: In case anyone of the release team takes the announced 30 May 2005
 release date (that already got some media coverage) seriously, I'd
 be glad to bet some some Euros against it...

-- 

   "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: packages missing from sarge

[Adrian Bunk]

On Mon, May 09, 2005 at 04:02:58PM +0200, Petter Reinholdtsen wrote:
> [Adrian Bunk]
> > The entry "packages:" was a bug in my quick&dirty scripting...
> 
> Thanks for making a nice summary of the relevant packages. :)
> 
> Feel free to include the script to generate the list when you generate
> dynamic list of packages like this.  It would make it easier for all
> of us to re-generate it on demand. :)

To be honest, I do not like to make ugly 5 minute hacks public.

I can send it to you privately, but is seems Javier has already sent 
a better looking script.

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: /usr/lib vs /usr/libexec

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Waitz <[EMAIL PROTECTED]> writes:

> hoi :)
>
> On Mon, May 09, 2005 at 03:45:32PM +1000, Russell Coker wrote:
>> Should we change some of these to /usr/libexec?
>
> well, it would be against the FHS, I think.
>
> The BSDs use libexec but I don't really see a good reason why it exists.

The only reason we don't have it is because of petty bickering and
politics between the FHS folks (several years ago).  There were few
technical objections to it on the FHS list, but it was dropped for
non-technical reasons.  Given that the FHS is supposed to codify
existing practice, it should be in there on that count alone.  Every
libexec-using package in Debian has been reconfigured not to use it;
upstreams do use it, and I'd like to use it myself.

I'd personally be very glad to have it, and would support using it in
Debian.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCgRvZVcFcaSW/uEgRAlcpAJ920/c0RktK+9FjORJNfNEushYhsgCg7H8h
tJo3qJd/a4eyOnGGHOXjdwc=
=7Ppv
-END PGP SIGNATURE-


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

Re: packages missing from sarge

[Andreas Tille]

On Tue, 10 May 2005, Adrian Bunk wrote:
Speaking as somebody who is quite unrelated to release issues (except
that I keep my packages bug free) I have some questions:
were at the correct severity and tagged correctly, your release
management is based on an assumption that isn't true.
Interesting statement but what is your suggestion to improve this?
And since you say the package maintainers were responsible for correct
bug severities:
How often does a quick NMU that gives a fast improvement in the RC
bugs metric hide the real problem that the maintainer is completely or
partially MIA?
Actually what is your opinion how to improve the QA process?
BTW: In case anyone of the release team takes the announced 30 May 2005
release date (that already got some media coverage) seriously, I'd
be glad to bet some some Euros against it...
What is the lesson whe should learn from this?
Just curious
   Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: packages missing from sarge

[Adrian Bunk]

On Tue, May 10, 2005 at 10:42:43PM +0200, Andreas Tille wrote:
> On Tue, 10 May 2005, Adrian Bunk wrote:
> 
> Speaking as somebody who is quite unrelated to release issues (except
> that I keep my packages bug free) I have some questions:
> 
> >were at the correct severity and tagged correctly, your release
> >management is based on an assumption that isn't true.
> Interesting statement but what is your suggestion to improve this?
> 
> >And since you say the package maintainers were responsible for correct
> >bug severities:
> >
> >How often does a quick NMU that gives a fast improvement in the RC
> >bugs metric hide the real problem that the maintainer is completely or
> >partially MIA?
> Actually what is your opinion how to improve the QA process?

It might sound strange, but I'd suggest to completely disallow NMUs 
without maintainer permission.

This would make it take longer until RC bugs are fixed, but it would 
help on speeding up the finding of maintainers who are for any reason 
not able to properly maintain their packages.

> >BTW: In case anyone of the release team takes the announced 30 May 2005
> >release date (that already got some media coverage) seriously, I'd
> >be glad to bet some some Euros against it...
> What is the lesson whe should learn from this?

I might be wrong and the release team really thinks this is a date they 
will reach.

But otherwise, the problem seems to be that in any other area I know the 
quality of release management is in a big part measured in how it 
manages to reach the goals.

Debian release management has the big advantage to setting their own 
goals.

But the last date (September 2004) set by the current release management 
failed because security support for sarge that was assumed to be ready 
six days after the announcement took more than six months.

I asked:

  Can you tell about the possible risks that may affect your release 
  plan and what you have done to ensure that they will not delay your 
  release plan?

but noone of the release team did bother to answer.

> Just curious
> 
>Andreas.

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: Bug#308533: ITP: gstat -- A program for multivariable geostatistical modelling, prediction and simulation

[Dirk Eddelbuettel]

Howdy,

Francesco Paolo Lovergine  debian.org> writes:
> Package: wnpp
> Severity: wishlist
> Owner: "Francesco P. Lovergine"  debian.org>
> 
> * Package name: gstat
>   Version : 2.4.4
>   Upstream Author : Edzer J. Pebesma  geog.uu.nl> et al.
> * URL : http://www.gstat.org/
> * License : GPL
>   Description : A program for multivariable geostatistical modelling,
prediction and simulation
> 
> Gstat is an open source (GPL) computer code for multivariable
> geostatistical modelling, prediction and simulation, and has been around
> from  1997. In the original  form, gstat  is a  stand-alone executable,
> interfaced to various GIS (including GRASS 6). 
> As  of 2003, the gstat functionaly  is also available as an S extension, 
> either as R package or S-Plus library.

Do you intend to package this as r-cran-gstat, in-line with the numerous other
R packages based on CRAN sources?

I'm just asking as gstat is also part of CRAN, e.g. can be found on
http://cran.r-project.org/src/contrib/ and its mirrros.   We have a 
never-quite-finalized Debian R Policy draft that several of us adhere 
to, and that we plan to expand -- i.e. we're working on getting all of
CRAN auto-built (and apt-get'able, though not necessarily inside Debian 
as adding 500+ packages may be madness). 

Feel free to follow-up off-line if you have questions.

Cheers,  Dirk








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

Re: cogito_0.10-2 available, and request for Sponsor

[Anibal Monsalve Salazar]

On Tue, May 10, 2005 at 11:22:17AM -0600, Sebastian Kuzminsky wrote:
>I'm a wanna-be new maintainer starting out the New Maintainer process.

Please refer to http://nm.debian.org/.

>I'm looking for a Debian Sponsor to upload this package to the archive.

I'll upload it. However, we'll have to wait until the license issue
raised by Florian Weimer is resolved. If the package is uploaded is
very likely to be rejected by the ftpmaster team.

>I'm also looking to have my GPG key signed (I live in Colorado, USA),
>and for an Advocate.

What city in Colorado. Maybe there is a DD in the same city as yours.
You really need a DD to sign your gpg key to start the NM process.

After you have been working with your sponsor for some time, your
sponsor may back your NM application and be your advocate.

Regards,

Anibal Monsalve Salazar
--
 .''`. Debian GNU/Linux
: :' : Free Operating System
`. `'  http://debian.org/
  `-   http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: /usr/lib vs /usr/libexec

[Andrew Suffield]

On Tue, May 10, 2005 at 08:12:38AM -0700, Thomas Bushnell BSG wrote:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
> 
> > We do not have that bug, so it's not important to us.
> 
> Still, nobody has said.  What filesystems available on Debian have a
> better than linear search time for open, and are they used by a
> default Debian install?

Who cares? What Debian systems spend a noticable amount of time
waiting for ld to search for libraries? I've never seen ld be anything
less than instantaneous to find libraries, even on old boxes with just
about everything installed. It spends all its time linking, not
waiting for open() to complete.

Arguing about the theoretical performance is a bloody waste of time in
the absence of an actual problem. As I said, we do not have that bug.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: /usr/lib vs /usr/libexec

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Still, nobody has said.  What filesystems available on Debian have a
> better than linear search time for open, and are they used by a
> default Debian install?

/etc/ld.so.cache

Gruss
Bernd


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

Re: /usr/lib vs /usr/libexec

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> No lvm backup data available in case of superblock corruption. Bad
> idea. No booting with init=/bin/sh to patch things back together as /
> can't be mounted. Bad idea again.

You can store the backup wherever you like, and an emergency boot via usb
stick,  netboot or standby volume is the default way to recover a server.

Gruss
Bernd


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

Re: /usr/lib vs /usr/libexec

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Why would it be desirable to have arch-os directories under libexec?

For sharing the /usr tree among multiple machines with different
architectures (I guess).

Gruss
Bernd


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

Re: dependency on base package adduser ?

[Brian M. Carlson]

On Tue, 2005-05-10 at 11:19 +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > libc6 is not and may not be marked Essential, as the NM process taught me.
> > So its a bad example.
> 
> Even if it is marked as essential, you have a versioned dependency, anyway.

But the point is, you cannot mark it essential; doing so is a severity
serious bug.  From the Policy, section 3.8:

   Since these packages cannot be easily removed (one has to specify an
   extra _force option_ to `dpkg' to do so), this flag must not be used
   unless absolutely necessary.  A shared library package must not be
   tagged `essential'; dependencies will prevent its premature removal,
   and we need to be able to remove it when it has been superseded.

Notice the the use of "must not"; that makes it severity serious.  Even
if there is no plan to change the name on GNU/Linux, that does not mean
that is the case on GNU/KFreeBSD, GNU/KNetBSD, or GNU/Hurd; that is why
glibc is not granted an exception.

-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



signature.asc
Description: This is a digitally signed message part

Re: cogito_0.10-2 available, and request for Sponsor

[Adeodato =?iso-8859-1?Q?Sim=F3?=]

* Sebastian Kuzminsky [Tue, 10 May 2005 11:22:17 -0600]:

> I'm also looking to have my GPG key signed (I live in Colorado, USA),

  http://nm.debian.org/gpg.php

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny..."
-- Isaac Asimov


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

re: packages missing from sarge

[Vincent McIntyre]

Hi

I'd like to raise the question of apt-proxy. I discussed offlist with
JoeyH and he wasn't keen, but now I've done a few tests and have more
confidence that this is worth raising.


apt-proxy comes in two flavours - the old shell-based one and a new shiny
python one. The most recent shell-based one is apt-proxy-1.3.7, in t-p-u.
The most recent python-based one is apt-proxy-1.9.28, in unstable.


Currently, the package is held out because of #304182. However, that is
against the python version, 1.9.28. AFAICT the shell version is fine.



Proposal: allow 1.3.7 into sarge, on the following basis -
 * woody has 1.3.0, ie it's used by current users of stable
 * I don't understand hinting-foo, but it appears it's been hinted in:
   http://ftp-master.debian.org/testing/hints/ajt

The package was removed from sarge in November, for some other RC problem.
JoeyH is concerned that there has been so much flux since then that
allowing the shell version back in will cause more problems than it's
worth.

To try to allay these fears, I made a few tests. So far it looks ok.

1. clean install of an x86 box with d-i rc3, just base.

2. install apt-proxy-1.3.7 from t-p-u, and then take t-p-u out of
   sources.list again

3. install a bunch o' packages on the host, with sources.list pointed
   at the proxy service (http://localhost:).

   This worked pretty well once I got apt-proxy.conf set up properly.
   The only problem I could see in /var/log/apt-proxy.log was warnings
   from /usr/bin/stat about using a deprecated argument.
   So Joey was right to worry. I've attached a patch that addresses
   the warnings.

4. clean install a second x86 machine (d-i rc3 again), using the proxy.
   This worked well, installing 400+ packages without missing a beat.

5. try a couple of simultaneous installs (eg rhythmbox & tons of depends)
   Again, things worked smoothly.

The above doesn't exercise all the code paths in apt-proxy.
For one, I haven't tried apt-proxy-import. The other main question mark
I guess is the rsync functionality, I don't know how much rsync has
changed over this period. Would someone care to try these things out?

Since it's a shell script, I'm going to assume there are no arch-specific
bugs...


Thanks for reading. I have the apt-proxy.log if that's needed.

Vince


diff -ruN apt-proxy-1.3.7.orig/usr/sbin/apt-proxy 
apt-proxy-1.3.7/usr/sbin/apt-proxy
--- apt-proxy-1.3.7.orig/usr/sbin/apt-proxy 2005-05-10 23:11:30.0 
+1000
+++ apt-proxy-1.3.7/usr/sbin/apt-proxy  2005-05-10 10:55:51.0 +1000
@@ -80,12 +80,12 @@
 #  file_size(file name)
 #
 if [ -x $STAT ] &&
-   [ "`$STAT -tl /dev/null | sed "s,/dev/null 0 .*,PASSED,"`" = "PASSED" ]
+   [ "`$STAT -tL /dev/null | sed "s,/dev/null 0 .*,PASSED,"`" = "PASSED" ]
 then
 file_size()
 {
[ -z "$1" -o ! -f "$1" ] && return 1
-   set -- `$STAT -tl "$1"`
+   set -- `$STAT -tL "$1"`
[ -z "$2" ] && return 1
echo $2
 }

Re: /usr/lib vs /usr/libexec

[Brian May]

> "Thomas" == Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

Thomas> You've missed the point.  Split / and /boot, that makes
Thomas> sense if it's necessary.  Splitting / and /usr does not
Thomas> make sense.

Bad example.

A better example might be if you want to mount /usr via NFS or some
other network file-system. I have heard people use AFS for this
purpose. I am sure there are other file-systems that could be used.

Yes, there are ways you can mount / via a network file-system:
* NFS Boot code in kernel that auto-configures the network.
* initramfs (anybody written code to do this?)

However, if all you want to do is share /usr between systems,
currently the simplest approach (and the only way I know this is
possible) is if /usr is a separate from /.

For starters, it only requires an extra entry in /etc/fstab. No
changes to the boot structure.

A relevant factor is that some directories (i.e. /etc and /var) cannot
always be shared, but must be available early on in the boot process
(i.e. /etc). So it might make sense to have a local private copy of /,
but have /usr shared.

Yes, this gets a bit messy in places (e.g. keeping /etc, /lib, and
/var synchronized with /usr), but my point is to prove that there
still are benefits in keeping /usr and / split.

The arguments presented hold true of any filesystem that is
complicated enough to require user-level tools to initialize, and for
some reason you don't want to use an initramfs to initialize it. Or if
you want /usr to be shared between computers but don't want to share
all of /.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
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

[Shaul Karl]

On Mon, May 09, 2005 at 01:14:27PM -0400, Stephen Gran wrote:
> This one time, at band camp, Marc Haber said:
> > On Mon, 09 May 2005 15:34:06 +0300, Shaul Karl <[EMAIL PROTECTED]> wrote:
> > >adduser(8) states that 
> > >
> > >With the --disabled-login option, the account will be created but
> > >will be disabled until a password is set. The --disabled-password
> > >option will not set a password, but login are still possible for
> > >example through SSH RSA keys.
> > >
> > >I wonder what is the difference?
> > 
> > One disables the account, the other sets an invalid password. I think
> > that the manpage is quite clear about that.
> >
> > >Perhaps what I really should have asked is about the contents of
> > >/etc/{passwd,shadow}'s password field for disabled accounts.
> > 
> > One is "*", the other is "!". I never know which is which.
> 
> * is disabled, IIRC, and ! is an invalid password (but would still allow
> logging in with, e.g, an ssh key).  Or so my (often faulty) memory says.


  According to shadow(5),

If the password field contains some string that is not valid result of
crypt(3), for instance ! or *, the user will not be able to use a unix
password to log in, subject to pam(7). 

The way I understand it, the effect of ! or * is identical.
Alternatively, the difference is set by the configuration of pam, which,
I believe, is out of adduser scope. This match my experience that login
through SSH RSA key is possible even if a '!' is used.
  In any case, am I right that adduser's --disabled-login and 
--disabled-password looks to be the same?


> Why didn't you ask the adduser maintainers?
> 


  I need to verify my experience: am I wrong that on a default Debian
system a '!' doesn't prevent login through SSH RSA key? Perhaps a
wishlist bug should be submitted against pam?


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

re: packages missing from sarge (apt-proxy)

[Vincent McIntyre]

sorry to followup my own post, but...
I did a few apt-proxy-import tests by removing a random set of .debs
out of the cache tree and importing again. This worked correctly.

Cheers
Vince


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

Re: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Humberto Massa <[EMAIL PROTECTED]> writes:

> with the possible exception of FAT and Minix. Q: are they used by a
> default? A: Last time I installed Debian (15 days ago), it asked me if
> I wanted my partition ext3, xfs, or reiserfs IIRC; I chose reiserfs,
> and I am pretty sure finding a file in a directory in reiserfs is
> O(log n) in the worse case. (Actually, I think that except for HUGE
> directories [far larger than /usr/lib] it accesses two or three blocks
> of disk in every case, hence being O(1)).

How many directory entries do you think fit in a block?


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

Re: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Christoph Hellwig <[EMAIL PROTECTED]> writes:
>
>> On Tue, May 10, 2005 at 02:03:01PM -0300, Humberto Massa wrote:
>>> These are two questions: Q: What filesystems... ? A: Every one of them 
>>> with the possible exception of FAT and Minix.
>>
>> ext2 doesn't.
>
> Convert it to utilize directory hashing. The ability is there but iirc
> isn't used by default.

What does the default Debian install do?


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

Re: /usr/lib vs /usr/libexec

[Thomas Bushnell BSG]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]> you wrote:
>> Still, nobody has said.  What filesystems available on Debian have a
>> better than linear search time for open, and are they used by a
>> default Debian install?
>
> /etc/ld.so.cache

Um, no.  ld.so.cache gives you the filename to open, but it's still
linear on ext2 to search the directory.


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

Re: packages missing from sarge

[Steve Langasek]

Hi Vince,

On Wed, May 11, 2005 at 08:22:28AM +1000, Vincent McIntyre wrote:
> apt-proxy comes in two flavours - the old shell-based one and a new shiny
> python one. The most recent shell-based one is apt-proxy-1.3.7, in t-p-u.
> The most recent python-based one is apt-proxy-1.9.28, in unstable.

> Currently, the package is held out because of #304182. However, that is
> against the python version, 1.9.28. AFAICT the shell version is fine.

> Proposal: allow 1.3.7 into sarge, on the following basis -
>  * woody has 1.3.0, ie it's used by current users of stable

This doesn't deal with questions of possible bit rot (which your tests
address to some extent, but not completely).  It also doesn't provide a
smooth upgrade path for users of sarge==testing who have a no-longer-present
version of apt-proxy 1.9 installed on their systems.  While support for
upgrades within testing are not "release-critical" because there's no
release involved, I'd rather that sarge users have apt-proxy show up under
"obsolete" than be caught running an unsupported, *newer* version with no
indication of trouble; and I feel strongly enough about this to not let
1.3.7 back in via t-p-u.

That means that if people want apt-proxy 1.3 in sarge, it should go through
unstable with an epoch, possibly kicking 1.9 out to experimental for the
duration.

>  * I don't understand hinting-foo, but it appears it's been hinted in:
>http://ftp-master.debian.org/testing/hints/ajt

That was a test hint; nothing below 'finished' is processed by britney.

> The package was removed from sarge in November, for some other RC problem.
> JoeyH is concerned that there has been so much flux since then that
> allowing the shell version back in will cause more problems than it's
> worth.

Indeed, that's still a concern that I have; I've heard before that apt-proxy
works flawlessly for some people, and not at all for others. :/

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Questions about apt-get upgrade/install semantic

[Gunnar Wolf]

Daniel J. Axtens dijo [Fri, May 06, 2005 at 01:36:06PM +0800]:
> > and not
> > "apt-get upgrade "
> 
> Possibly because apt-get upgrade is used to upgrade the whole system,
> not just one package. My guess is that the developers didn't want to
> overload the upgrade command.

It is not only that - It is because apt-get is an infrastructure
manager, not an individual package manager. dpkg does work on single
packages, but apt-get works on the whole collection - and it could
lead to inconsistencies if you let apt-get do a half-assed job and
upgrade just one out of many packages - There might be dependencies
down there, and this kind of command would not follow them (or would
be inconsistent with the user's wishes of upgrading _only_ that).

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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