Re: new port: and the winner is....

[Junichi Uekawa]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> immo vero scripsit

> Someone could always port Debian to the Windows kernel, but they should not
> call it Debian anymore, and it has no place in our archives (because it is
> contrib [or non-free?] and too big to be inserted in the contrib
> distribution).

Of course, if we manage to have a working ReactOS,
things will be different.

Until then, we will have a very "contrib" system.



regards,
junichi

-- 
[EMAIL PROTECTED]  http://www.netfort.gr.jp/~dancer

Re: new port: and the winner is....

[Manuel Segura]

I agree totaly with you..

Manuel Segura

"Richard B. Kreckel" a écrit :
> 
> Hi,
> 
> On Thu, 30 Aug 2001, A Mennucc1 wrote:
> [...]
> >  -why is the 'win' port important?
> [...]
> 
> (Sorry for dropping in late to this thread, I was too busy lately to
> follow debian-devel tightly.)
> 
> The social contract says "Our Priorities are Our Users and Free Software".
> Such a win-port might indeed serve some users.  But for my own part, I do
> have some personal problems with making all free software win-compatible.
> Does it serve Free Software?  Such ports frequently lead to crippled
> design [1] and frankly, I do not like to give people more excuses for not
> switching to an entirely free OS.
> 
> The one argument I am missing from the discussion is this: The porters
> find some problem with package foo and file a bugreport (most probably
> critical) to the maintainer of foo who has to look into the problem,
> withdrawing time for more important things than a weird port.  It has
> happened before [2] and it will happen again.  We really shouldn't invite
> everything into Debian.  It will distract us from providing a really
> useful free OS.
> 
> For my own part, the mere thought of receiving reports like "package bar
> doesn't build on win" gives me the creeps.  I would have to log in to one
> of those crippled machines, try to fix scripts, makefiles, code, whatnot.
> Ugh.
> 
> Instead, I would consider downgrading the bugreport to wishlist/wontfix.
> 
> Regards
>  -richy.
> 
> [1] Why does Apache have to abstract away their threads?  Right, because
> Winsux doesn't have pthreads.  Admittedly, this might be a little
> off-topic because that is for a native port, but that's the basic
> pattern.
> [2] Look at the parisc port: GCC-3.0 is not even officially supported
> upstream and the entire toolchain seems to be changing frequently.
> Some packages build one day but not the next.  I wonder how they
> want to release that stuff.
> --
>   .''`.  Richard B. Kreckel
>  : :' :  <[EMAIL PROTECTED]>
>  `. `'   <[EMAIL PROTECTED]>
>`-
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
---
Manuel Segura
ESCPI - CNAM
---

Re: bind9-chroot (was: questions on ITP)

[Richard Atterer]

WRT chrooting certain applications - wouldn't it make sense to mandate
one consistent way for the user to do this if the package supports it? 
That way, chrooting daemons is much more user-friendly, which in turn
will (hopefully) lead to more people doing it.

One idea: In a configuration file, the user lists those daemons he
wants to run chrooted. init.d scripts that support it read this
information and act on it, copying the required files to a chroot
before starting the daemon there.

(The config file should probably not be read directly, instead the
init.d script should call a small query script. That way, file format
changes are possible.)

Furthermore, IMHO init.d scripts that support chrooting should clearly
print "[chrooted]" or "[non-chrooted]" in their startup message, both
to make the user aware that chrooting is possible, and to make it
clear whether it takes place.

So:
- If I were to put together a "chroot-helper" package, would people be
  interested in using it for their package?
- Any chance of getting a recommendation for this into policy?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  CS student at the Technische  |  GnuPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  0x888354F7
  ¯ ´` ¯


pgpRpbNdfnvwh.pgp
Description: PGP signature

building a new debian package

[Søren Boll Overgaard]

Hello

I am having trouble making a debian package that I building install a binary
file the directory of my choice.
I've been looking at
http://www.debian.org/doc/maint-guide/ch-modify.html#s-destdir to change the
install directory, but I can't seem to get it to work. 

After running dpkg-buildpackage the Makefile of the program I trying to
build looks like this (irrelevant parts have been cut away) :

[...]
# Edited for Debian GNU/Linux.
DESTDIR =

[...]
prefix = /usr/local
exec_prefix = ${prefix}
#exec_prefix = $(DESTDIR)/usr/X11R6/bin
#bindir = ${exec_prefix}/bin
bindir = $(DESTDIR)/usr/X11R6/bin
sbindir = ${exec_prefix}/sbin
[...]

And debian/rules contains the following for the configure command:

[...]
configure-stamp:
dh_testdir
# Add here commands to configure the package.
#   ./configure --prefix=/usr --mandir=\$${prefix}/share/man
--infodir=\$${p
refix}/share/info
./configure 

touch configure-stamp

[...]

However, even with the above parameters, the binary is installed in /bin/,
which in this case is not desirable.
Any input would be greatly appreciated.

-- 
Søren O.

Re: madison

[Admar Schoonen]

On Fri, Sep 21, 2001 at 05:15:31PM -0400, Matt Zimmerman wrote:
> On Fri, Sep 21, 2001 at 12:52:37PM +0200, Martin F Krafft wrote:
> 
> > madison seems to be what the debian.org webpage sports as the package
> > search over distributions. is it packaged? do you need someone to package
> > it?
> 
> madison requires connectivity to a Debian database which is not publicly
> accessible, so it is only useful on a couple of internal Debian machines.
> For this reason, it probably isn't worthwhile to package it.

I think it can be useful for those who want to create their own flavour of
Debian or want to (partially) mirror Debian. dpkg-scanpackages/apt-ftparchive
doesn't work very well for packages which are located in the pool, and the only
way to generate correct packagelists is to put all information from all packages
in a database and query that database when packagelists are generated; thus
people who want to partially mirror or create their own Debian-flavour should
create their own Debian database from information gathered from packagelists
which are downloaded by apt.

[I'm not a developer, and this is just my humble opinion.]

Admar Schoonen

ITP: kernel-patch-selinux

[Russell Coker]

I intend to package the kernel patch for NSA Security Enhanced Linux.

Below is all the details on licenses.  My interpretation of the below license 
details (copied from the web site) is that the kernel patch is under the GPL 
and everything is fine.

However is the issue about "warranty exclusion" etc which requires "agreement 
before download" going to force me to use non-free for my package?

I know I could ask upstream for clarification of this issue, however the NSA 
takes a long time to prepare public statements, and I imagine that things 
will take longer now than they would have a few weeks ago...



License statement from http://www.nsa.gov/selinux/license.html :
 
All source code found on this site is released under the same terms and
conditions as the original sources. For example, the patches to the Linux
kernel, patches to many existing utilities, and new programs and libraries
available here are released under the terms and conditions of the GNU General
Public License (GPL). The patches to some existing utilities and libraries
available here are released under the terms and conditions of the BSD license.
 
I downloaded the patch from http://www.nsa.gov/selinux/src-disclaim.html
which has the following disclaimer:

Before downloading this software, you must accept the warranty exclusion and
limitation of liability which appears below.
 
WARRANTY EXCLUSION
 
I expressly understand and agree that this software is a non-commercially
developed program that may contain "bugs" (as that term is used in the
industry) and that it may not function as intended. The software is licensed
"as is". NSA makes no, and hereby expressly disclaims all, warranties,
express, implied, statutory, or otherwise with respect to the software,
including noninfringement and the implied warranties of merchantability and
fitness for a particular purpose.
 
LIMITATION OF LIABILITY
 
In no event will NSA be liable for any damages, including loss of data, lost
profits, cost of cover, or other special, incidental, consequential, direct or
indirect damages arising from the software or the use thereof, however caused
and on any theory of liability. This limitation will apply even if NSA has
been advised of the possibility of such damage. I acknowledge that this is a
reasonable allocation of risk.

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

Re: bind9-chroot (was: questions on ITP)

[Bernhard R. Link]

* Richard Atterer <[EMAIL PROTECTED]> [010922 16:26]:
> One idea: In a configuration file, the user lists those daemons he
> wants to run chrooted. init.d scripts that support it read this
> information and act on it, copying the required files to a chroot
> before starting the daemon there.
> 
> (The config file should probably not be read directly, instead the
> init.d script should call a small query script. That way, file format
> changes are possible.)

Help, please no. More supports for chroots may be nice. But not this
way! init.d-scripts calling scripts, that parse global config files
is ugly and one of the many points to make people switch from Suse or
Redhat to debian. 
And why should there be an global config file for all daemons? Beeing
chrooted is an quite personal thing for every package. Why should
an daemon that run chroot (and there are not that many, that can
can be run there) parse a file which is of no interest for him but
for the other daemons?

Hochachtungsvoll,
  Bernhard R. Link

Re: bind9-chroot (was: questions on ITP)

[Martin F Krafft]

also sprach Richard Atterer (on Sat, 22 Sep 2001 03:28:21PM +0200):
> One idea: In a configuration file, the user lists those daemons he
> wants to run chrooted. init.d scripts that support it read this
> information and act on it, copying the required files to a chroot
> before starting the daemon there.

well, you might just use SuSE then...
i don't think this is a good idea. for one, it is not necessary to
copoy the chroot files over and over again with each init.d start.
this interferes with tripwire installations, and it's in violation of
the "never touch a running system" philosophy. even if libc is
updated, if bind runs happily in its chroot. and if some security
patch or otherwise crucial update is pending for a library that bind
also uses, then the bind9 and bind9-chroot packages should be updated
anyway. sure, this requires more work on the maintainer side, but it's
the best way to do it.

> - If I were to put together a "chroot-helper" package, would people be
>   interested in using it for their package?

i don't think a global solution is a good choice here. if i install
bind9-chroot (hypothetically speaking), then bind9 should not possibly
ever run non-chrooted again. this should be done via diversions.

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
you will be run over by a beer truck.


pgpNLq6IqYszk.pgp
Description: PGP signature

Re: building a new debian package

[Gergely Nagy]

It seems to be an autoconf/automake based project, from what you
included in your mail, how about using make install
DESTDIR=$(CURDIR)/debian/tmp from the install target of your
debian/rules? Or if that doesn't work, you can still use make install
bindir=$(CURDIR)/debian/tmp/usr/bin or something like that..

Cheers,
-- 
Gergely Nagy \ mhp/|8]


pgpS3dP2SXClJ.pgp
Description: PGP signature

(None)

[Cong ty Luat Gia Pham]

Title: Cong ty Luat Gia Pham







http://www.giapham.com 

KÝnh göi: 	Quý b¹n hµng!

C«ng ty LuËt Gia Ph¹m xin göi lêi chµo tr©n träng tíi quý doanh nghiÖp!

C«ng ty LuËt Gia Ph¹m, mét C«ng ty chuyªn ho¹t ®éng trong lÜnh vùc t­ vÊn víi ®éi ngò luËt gia, t­ vÊn viªn chuyªn nghiÖp giµu kinh nghiÖm ®¶m b¶o cung cÊp cho kh¸ch hµng nh÷ng dÞch vô t­ vÊn hoµn h¶o vµ chÊt l­îng.

Trong thêi gian qua ®­îc sù tin cËy cña Céng ®ång c¸c Doanh nghiÖp, chóng t«i th­êng xuyªn nhËn ®­îc sù ñy quyÒn, nh÷ng yªu cÇu t­ vÊn vµ thùc hiÖn c¸c dÞch vô hç trî c¸c doanh nghiÖp trong nh÷ng lÜnh vùc sau:

  Thµnh lËp míi doanh nghiÖp, thay ®æi, bæ sung ®¨ng ký kinh doanh, më chi nh¸nh, v¨n phßng ®¹i diÖn t¹i Hµ Néi vµ c¸c tØnh phÝa B¾c;
  §¨ng ký b¶o hé ®éc quyÒn nh·n hiÖu s¶n phÈm, kiÓu d¸ng c«ng nghiÖp, s¸ng chÕ, gi¶i ph¸p h÷u Ých;
  §¨ng ký b¶o hé quyÒn t¸c gi¶ ®èi víi c¸c t¸c phÈm v¨n häc, nghÖ thuËt, khoa häc;
  §¨ng ký m· sè m· v¹ch  tiªu chuÈn quèc tÕ cho c¸c s¶n phÈm 
  T­ vÊn th­êng xuyªn hç trî c¸c doanh nghiÖp trong c¸c lÜnh vùc ph¸p lý, thuÕ, tµi chÝnh, qu¶n trÞ doanh nghiÖp;
  Tham gia tranh tông, ®µm ph¸n gi¶i quyÕt c¸c xung ®ét vÒ lao ®éng, c¸c tranh chÊp kinh tÕ, d©n sù;
  ChuÈn hãa tÝnh ph¸p lý cña hå s¬ doanh nghiÖp, hîp ®ång vµ c¸c v¨n b¶n, tµi liÖu kh¸c.


Víi bÒ dµy kinh nghiÖm, tÝnh chuyªn nghiÖp cña c¸c c¸n bé t­ vÊn, chóng
t«i ®¶m b¶o cung cÊp c¸c dÞch vô t­ vÊn toµn diÖn vµ ®a ngµnh, lu«n lµm tháa m·n mäi yªu cÇu kh¾t khe nhÊt cña kh¸ch hµng. Sù g¾n bã cña kh¸ch hµng víi c¸c dÞch vô hç trî tæng thÓ ®· ®em l¹i thµnh
c«ng cho chóng t«i nh­ ngµy h«m nay!
Chóng t«i lµm ®iÒu ®ã bëi nhËn thÊy r»ng Doanh nghiÖp tù phßng vÖ ch­a ®ñ mµ cÇn ph¶i thiÕt lËp c¸c quan hÖ ph¸p lý ®Ó b¶o vÖ m×nh tr­íc khi bÞ tÊn c«ng. ThÕ m¹nh cña c«ng ty chóng t«i lµ sù kÕt hîp gi÷a kinh nghiÖm vµ sù t×m tßi c¸c gi¶i ph¸p thùc tiÔn nh­ng ®¶m b¶o tÝnh chuyªn nghiÖp trong chÊt l­îng dÞch vô.
Mäi ho¹t ®éng cña chóng t«i còng kh«ng n»m ngoµi môc tiªu chung cña tÊt c¶ c¸c nhµ ®Çu t­:
 "Hîp t¸c ®Ó cïng ph¸t triÓn".

Tr©n träng
LuËt Gia Ph¹m Thµnh Long
C«ng ty LuËt Gia Ph¹m
Tel: 84-4-  55 838 55  Fax: 55
809 55

§Þa chØ:  240 Phè Quan Nh©n, Thanh Xu©n, Hµ Néi
http://www.giapham.com


Scope of business:

-Advisory of procedures and documentation for establishment of enterprises, branch, representative office;
-Registration of stamp, tax code, import- export code ;
-Regitration of scopes of conditional professional, business licenses of profession practising, petroleum and oil , LPG, advisory of designing, etc;
-Registration of indutrial intellectual  protection, invention, industrial style, useful solutions, goods trademarks, goods origination names;
-Registration of licensing of code international line codes for commodities.

please visiting our website: http://www.giapham.com

Re: madison

[Andrew Suffield]

On Sat, Sep 22, 2001 at 04:44:46PM +0200, Admar Schoonen wrote:
> I think it can be useful for those who want to create their own flavour of
> Debian or want to (partially) mirror Debian. dpkg-scanpackages/apt-ftparchive
> doesn't work very well for packages which are located in the pool, and the 
> only
> way to generate correct packagelists is to put all information from all 
> packages
> in a database and query that database when packagelists are generated; thus
> people who want to partially mirror or create their own Debian-flavour should
> create their own Debian database from information gathered from packagelists
> which are downloaded by apt.

Those people are going to want all of dak (katie) anyway, which
contains madison. It's not packaged either, but is available from
anonymous cvs at cvs.debian.org.

However, the value of a package that would be used by about half a
dozen people in total is probably not all that high.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' : | Dept. of Computing,
 `. `'  | Imperial College,
   `-http://www.debian.org/ | London, UK


pgpmwwHifndOR.pgp
Description: PGP signature

Re: madison

[Matt Zimmerman]

On Sat, Sep 22, 2001 at 04:44:46PM +0200, Admar Schoonen wrote:

> On Fri, Sep 21, 2001 at 05:15:31PM -0400, Matt Zimmerman wrote:
> > madison requires connectivity to a Debian database which is not publicly
> > accessible, so it is only useful on a couple of internal Debian
> > machines.  For this reason, it probably isn't worthwhile to package it.
> 
> I think it can be useful for those who want to create their own flavour of
> Debian or want to (partially) mirror Debian.
> dpkg-scanpackages/apt-ftparchive doesn't work very well for packages which
> are located in the pool, and the only way to generate correct packagelists
> is to put all information from all packages in a database and query that
> database when packagelists are generated; thus people who want to
> partially mirror or create their own Debian-flavour should create their
> own Debian database from information gathered from packagelists which are
> downloaded by apt.

There's no need for a database unless you want to maintain multiple
distributions out of cross-sections of the pool, as Debian does.  If you
only want to make a single set of packages available, or you only have one
version of each package, then you don't need to worry about it.
apt-ftparchive and dpkg-scanpackages will work fine.  It doesn't matter how
the files are arranged (in a pool-like hierarchy or section hierarchy or a
flat directory).

If you want to create your own flavour that contains different versions of
certain packages, or excludes certain packages, the situation is the same,
just with a different set of packages.  Partial mirrors should use the
Packages files on the mirrors to decide which files need to be downloaded.

Or is there a different goal you're describing that I don't understand?

-- 
 - mdz

Re: bind9-chroot (was: questions on ITP)

[Bdale Garbee]

[EMAIL PROTECTED] (Martin F Krafft) writes:

> i don't think a global solution is a good choice here. if i install
> bind9-chroot (hypothetically speaking), then bind9 should not possibly
> ever run non-chrooted again. this should be done via diversions.

Eee.  Diversions are so, well, messy.  I think the obvious right way to 
handle this is to add debconf support to the bind9 package asking whether to
run in a chroot or not, and if the answer is yes, just do it.  As has been
pointed out by Marco and others, bind9 is substantially easier to chroot than
previous versions, so this shouldn't be a big deal.

Having said that, since I don't personally run bind9 in a chroot, I continue 
to be willing to accept a clueful patch to the current bind9 source in non-US
to implement this... but am in no big rush to implement it myself.

Bdale

Re: dpkg logging

[Bdale Garbee]

[EMAIL PROTECTED] (Wichert Akkerman) writes:

> Previously Steve Greenland wrote:
> > Stdout and stderr from the maintainer scripts. (This may be obvious, but
>> you didn't explicitly list it.)
>
> No, they should use debconf.

Regardless of whether packages are using debconf, I have wondered for *years*
why we didn't at least have the option of logging stdout and stderr from
everything in the install/update process.  I think it's a good idea.

Bdale

Re: bind9-chroot (was: questions on ITP)

[Richard Atterer]

On Sat, Sep 22, 2001 at 05:39:20PM +0200, Bernhard R. Link wrote:
> Help, please no. More supports for chroots may be nice. But not this
> way! init.d-scripts calling scripts, that parse global config files
> is ugly and one of the many points to make people switch from Suse
> or Redhat to debian.

On Sat, Sep 22, 2001 at 05:46:57PM +0200, Martin F Krafft wrote:
> well, you might just use SuSE then...

:-)

The config script was only a suggestion, and maybe there is a better
way. But my main point was: Chrooting a daemon should be possible in a
uniform way for all daemons that support it.

What alternative possibilities for implementing this do you see? The
package will have to contain the necessary chrooting script somewhere,
and the admin will have to perform some action to trigger its
execution. After he has done that, the init.d script should execute
the chrooted daemon.

It is possible to tell the admin to edit the init.d script, changing
some variable assignment to "chroot=yes", but somehow I don't think
this is very clean, either...

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  CS student at the Technische  |  GnuPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  0x888354F7
  ¯ ´` ¯


pgp2CxJpGiE30.pgp
Description: PGP signature

Re: bind9-chroot (was: questions on ITP)

[Martin F Krafft]

also sprach Bdale Garbee (on Sat, 22 Sep 2001 12:06:37PM -0600):
> Eee.  Diversions are so, well, messy.  I think the obvious right
> way to handle this is to add debconf support to the bind9 package
> asking whether to run in a chroot or not, and if the answer is yes,
> just do it.  As has been pointed out by Marco and others, bind9 is
> substantially easier to chroot than previous versions, so this
> shouldn't be a big deal.

well, okay then. i'll paste together a script that will chroot bind
right after it was successfully installed as bind9 package, and one
which will remove the chroot again.

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
if loving linux is wrong, i don't want to be right.


pgpSS5gaKw8IH.pgp
Description: PGP signature

Re: bind9-chroot (was: questions on ITP)

[Martin F Krafft]

also sprach Richard Atterer (on Sat, 22 Sep 2001 10:03:55PM +0200):
> What alternative possibilities for implementing this do you see? The
> package will have to contain the necessary chrooting script somewhere,
> and the admin will have to perform some action to trigger its
> execution. After he has done that, the init.d script should execute
> the chrooted daemon.

i believe that chroot should be an install time choice, not a runtime
one (as in config script).

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
la lune, c'est comme les canards
il faut aimer caresser les chats
pour avoir envie d'y aller.


pgpYni67FCDuI.pgp
Description: PGP signature

New attempt to build debhelper 3 for potato

[Marc Haber]

Hi,

tonight, I tried a second time to build debhelper 3 for potato.
Because of the radical changes that have taken place especially with
the SGML stuff, I have now successfully built 37 .deb files and am -
again - beginning to wonder if it is really this major an effort to
get a basic tool like debhelper built.

For example, is it really necessary to update debconf to have a
current debhelper? debhelper 3.0.45 build-depends on debconf-utils
which is not present in potato's debconf.

I have now a debconf 1.0.01 for potato which doesn't install since
perl 5.005 has its include files in a different place, and the debconf
postinst looks for Debconf/Db.pm in a bunch of other places instead of
/usr/share/perl5/Debconf where the backported debconf places it. I
certainly won't backport perl 5.6 to potato, and I am quite reluctant
to look that deeply into debconf 1.0.01's sources to figure out where
the perl modules should go with potato's perl.

I'd appreciate any hints. I am now off to bed ;) See you tomorrow.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29

Re: New attempt to build debhelper 3 for potato

[Marc Haber]

On Sun, 23 Sep 2001 00:02:16 +0200, Marc Haber
<[EMAIL PROTECTED]> wrote:
>tonight, I tried a second time to build debhelper 3 for potato.

And obviously goofed with my From: address. Sorry 'bout that.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: bind9-chroot (was: questions on ITP)

[Bryan Andersen]

Martin F Krafft wrote:
> 
> also sprach Richard Atterer (on Sat, 22 Sep 2001 10:03:55PM +0200):
> > What alternative possibilities for implementing this do you see? The
> > package will have to contain the necessary chrooting script somewhere,
> > and the admin will have to perform some action to trigger its
> > execution. After he has done that, the init.d script should execute
> > the chrooted daemon.
> 
> i believe that chroot should be an install time choice, not a runtime
> one (as in config script).

For the long term, this is the safer choice.

For even better security, just make the standard install chrooted
if it is of wise security reasons to.  I've long questioned why 
this hasn't been done for many daemons already.  I know some people
may feel that because it breaks something or another one shouldn't
do this, but I know bind doesn't break anything by being chrooted.
What about others?

-- 
|  Bryan Andersen   |   [EMAIL PROTECTED]   |   http://www.nerdvest.com   |
| Buzzwords are like annoying little flies that deserve to be swatted. |
|   -Bryan Andersen|

Re: bind9-chroot (was: questions on ITP)

[Ethan Benson]

On Sat, Sep 22, 2001 at 05:39:20PM +0200, Bernhard R. Link wrote:
> * Richard Atterer <[EMAIL PROTECTED]> [010922 16:26]:
> > One idea: In a configuration file, the user lists those daemons he
> > wants to run chrooted. init.d scripts that support it read this
> > information and act on it, copying the required files to a chroot
> > before starting the daemon there.
> > 
> > (The config file should probably not be read directly, instead the
> > init.d script should call a small query script. That way, file format
> > changes are possible.)
> 
> Help, please no. More supports for chroots may be nice. But not this
> way! init.d-scripts calling scripts, that parse global config files
> is ugly and one of the many points to make people switch from Suse or
> Redhat to debian. 

very much agreed.

> And why should there be an global config file for all daemons? Beeing
> chrooted is an quite personal thing for every package. Why should
> an daemon that run chroot (and there are not that many, that can
> can be run there) parse a file which is of no interest for him but
> for the other daemons?

yes the proper way is usually /etc/default/package  which has config
variables for the initscript, such as CHROOT=yes 

-- 
Ethan Benson
http://www.alaska.net/~erbenson/


pgpMr4lCrK712.pgp
Description: PGP signature

Re: bind9-chroot (was: questions on ITP)

[Martin F Krafft]

also sprach Bryan Andersen (on Sat, 22 Sep 2001 05:42:23PM -0500):
> For even better security, just make the standard install chrooted
> if it is of wise security reasons to.  I've long questioned why 
> this hasn't been done for many daemons already.  I know some people
> may feel that because it breaks something or another one shouldn't
> do this, but I know bind doesn't break anything by being chrooted.
> What about others?

my postfix runs in a total chroot (even more than standard debian). so
does my proftpd. problem with the latter is, of course, that no users
can use ftp to access their homedirectories, which i don't consider a
problem. i could enable it with 
'mount --bind /home /chroot/proftpd/home'
but i don't mind imposing sftp on everyone for security reasons
anyway!

other than that, i have long wanted to set up an apache chroot. i
don't know of other daemons (read: i don't use other daemons), which
would profit from a chroot...

martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
-- 
laugh alone and the world thinks you're an idiot.


pgpVBMmCiDN7p.pgp
Description: PGP signature

Re: Bug#66135: libtool_1.3.5-1(unstable): wrapping of binaries fails with -D__LIBTOOL_IS_A_FOOL__

[Brian May]

> "Domenico" == Domenico Andreoli <[EMAIL PROTECTED]> writes:

Domenico> how to find these evil packages?

Just "grep __LIBTOOL_IS_A_FOOL__ debian/rules" (for every source
package) should find most of them, I think (not tested).

Since the hack is probably exactly the same in every instance, it
might even be possible to develop a simple script for automatically
removing the hack (not sure if this would be worthwhile or not).

Just don't remove the hack unless the program uses a recent version of
libtool (look at the version on the initial bug report for a general
idea, do any packages still fall into this category?)
-- 
Brian May <[EMAIL PROTECTED]>

URGENT AND CONFIDENTIAL

[hassan bellob]

Hassan Bello.
#20  LOUIS BOTHA CRESCENT
SADTON SOUTH AFRICA,
Fax: 874-762-727949. 
Tel: 874-762-727947.
 
{URGENT AND   CONFIDENTIAL} 
Dear sir,  

In order to transfer out (USD 126 M) One hundred and
twenty six million United States Dollars) from African
Development Bank. I have the courage to ask you to
look for a reliable and honest person who will be
capable for
this important business believing that you will never
let me down either now or in future.

I am Hassan Bello the Chief auditor of African
Development Bank (ADB). There is an account opened in
this bank in 1980 and since 1990 nobody has operated
on this account again. after going through some old
files in the records I discovered that if I do not
remit this money out urgently it will be forfeited for
nothing. the owner of this account is Mr. Smith B.
Andreas, a foreigner, and a miner at kruger gold co.,
a geologist by profession and  he died since 1990. no
other person knows about this account or any thing
concerning it, the account has no other beneficiary
and my investigation proved to me as well that this
company does not know anything about this account and
the amount involved is (USD 126M) One hundred and
twenty six million United States Dollars million
dollars. I want to first transfer USDM twenty six
million United States Dollars from this money into a
safe foreigners account abroad before the rest, but I
don't know any foreigner, I am only contacting you as
a foreigner because this money can not be approved to
a local bank here, but can only be approved to any
foreign account because the money is in ,us dollars
and
the former owner of the account is Mr. Smith B.
Andreas is  a foreigner too.  I know that this message
will come to you as a surprise as we  don't know our
selves before, we will sign agreement, but be sure
that it is real and a genuine business. I
only got your contact address  from my secretary who
operates computer,
with believe in God that you will never let me down in
this business you are the only person that I have
contacted in this business, so please reply urgently
so that I will inform you the next step to take
urgently. Send also your private telephone and fax
number including the full details of the account to be
used for the deposit.

I want us to meet face to face or sign a binding
agreement to bind us together so that you can receive
this money into a foreign account or any account of
your choice where the fund will be safe. and I will
fly to your country for withdrawal and sharing and
other investments.

I am contacting you because of the need to involve a
foreigner with foreign account and foreign
beneficiary. I need your full co-operation to make
this work fine. because the management is ready to
approve this payment to any foreigner who has correct
information of this account, which I will give to you
later immediately, if you are able and with capability
to handle such amount in strict confidence and trust
according to my instructions and advice for our mutual
benefit because this opportunity will never come again
in my life. I need truthful person in this business
because I don't want to make mistake I need your
strong assurance and trust.

With my position now in the office I can transfer this
money to any foreigner's reliable account which you
can provide with assurance that this money will be
intact pending my physical arrival in your country for
sharing. I will destroy all documents of transaction
immediately we receive this money leaving no trace to
any place. you can also come to discuss with me face
to face after which I will make this remittance in
your presence and two of us will fly to your country
at least two days ahead of the money going into the
account.

I will apply for annual leave to get visa immediately
I hear from you that you are ready to act and receive
this fund in your account. I will use my position and
influence to effect legal approvals and onward
transfer of this money to your account with
appropriate clearance forms of the ministries and
foreign exchange departments.

At the conclusion of this business, you will be given
35% of the total amount, 60% will be for me, while 5%
will be for expenses both parties might have incurred
during the process of transferring.

I look forward to your earliest reply through my email
address or by my tel: 874-762-727947,fax: 874-762
727949.

yours truly


Hassan Bello.



__
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. 
http://im.yahoo.com

Re: madison

[Wichert Akkerman]

Previously Andrew Suffield wrote:
> However, the value of a package that would be used by about half a
> dozen people in total is probably not all that high.

We have packages that nobody uses. I wouldn't mind seeing the whole
archive management suite being packaged properly, and I think it 
would be used more then you might think.

Wichert.

-- 
  _
 /   Nothing is fool-proof to a sufficiently talented fool \
| [EMAIL PROTECTED]   http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: bind9-chroot

[Herbert Xu]

Bryan Andersen <[EMAIL PROTECTED]> wrote:

> do this, but I know bind doesn't break anything by being chrooted.
> What about others?

Last I checked bind when chrooted can't listen on interfaces that are
brought up after it has been started.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Preview of new Ghostscript packages - please test

[Yasuhiro Take]

[ Ccing to [EMAIL PROTECTED] for notice ]
Hello,

At 21 Sep 2001 15:39:27 +0300,
Samuli Suonpaa wrote:
> 
> 
> Torsten Landschoff <[EMAIL PROTECTED]> wrote:
> > Please take a look at these packages and tell me about any problems
> > which are not obvious - there is a lot of stuff still lacking and I
> > only want to upload the packages to the archive when they are
> > feature complete.
> 
> I really do not know much about gs, but it seems there's something
> wrong with fontpaths here. When trying to configure my PSC500 (using
> hpijs and DJ8xx drivers now included in GhostScript, thank you for
> that), I only get complaint: "Error: /invalid font in findfont" and
> something like that.

If you are using defoma 0.4.10, it may be a bug of defoma.
Please look into /var/lib/defoma/gs.d/dirs/fonts, where is one of the
font paths of gs and is managed by defoma.
The bug makes creating Fontmap file fail so you may find out that there're
symlinks of pfb files of gsfonts but no Fontmap file in the directory.

Please update to defoma 0.4.11 i'm just duploading and run:
defoma-app update gs

Thanks,

hirot



pgp6xoTdVk25L.pgp
Description: PGP signature

Re: gpg and trustdb very slow

[Karsten M. Self]

on Tue, Sep 18, 2001 at 08:37:33AM -0300, Henrique de Moraes Holschuh ([EMAIL 
PROTECTED]) wrote:
> On Tue, 18 Sep 2001, Christian Kurz wrote:
> > On 01-09-18 Joey Hess wrote:
> > > It'd be nice if someone would look at optimizing it sometime; the
> > > behavior I see with strace is absurd, and could easily be done with no
> > > syscalls, at least, by just reading the whole trustdb into memory.
> > 
> > I know that the Werner revamped the whole keyring code about 1 or two
> > weeks ago. I just tried the --list-keys with my private and the debian
> > keyring specified in the options file and I didn't took more then 5
> > minutes for me. (AMD K6-200). So I don't think if anyone would really
> > want to optimize the code more, he should look at the current cvs code.
> 
> As well as reading the docs, where it is said that one must reinsert
> all keys in the trustdb to take advantage of a new caching
> algorithm...

Could you point us to the relevant docs and/or the command for
re-reading keys?

Peace.

-- 
Karsten M. Self http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?  Home of the brave
  http://gestalt-system.sourceforge.net/Land of the free
   Free Dmitry! Boycott Adobe! Repeal the DMCA!  http://www.freesklyarov.org
Geek for Hire  http://kmself.home.netcom.com/resume.html


pgpmTtP8aIl64.pgp
Description: PGP signature

Re: gpg and trustdb very slow

[Henrique de Moraes Holschuh]

On Sat, 22 Sep 2001, Karsten M. Self wrote:
> on Tue, Sep 18, 2001 at 08:37:33AM -0300, Henrique de Moraes Holschuh ([EMAIL 
> PROTECTED]) wrote:
> > On Tue, 18 Sep 2001, Christian Kurz wrote:
> > > On 01-09-18 Joey Hess wrote:
> > > > It'd be nice if someone would look at optimizing it sometime; the
> > > > behavior I see with strace is absurd, and could easily be done with no
> > > > syscalls, at least, by just reading the whole trustdb into memory.
> > > 
> > > I know that the Werner revamped the whole keyring code about 1 or two
> > > weeks ago. I just tried the --list-keys with my private and the debian
> > > keyring specified in the options file and I didn't took more then 5
> > > minutes for me. (AMD K6-200). So I don't think if anyone would really
> > > want to optimize the code more, he should look at the current cvs code.
> > 
> > As well as reading the docs, where it is said that one must reinsert
> > all keys in the trustdb to take advantage of a new caching
> > algorithm...
> 
> Could you point us to the relevant docs and/or the command for
> re-reading keys?

Nope, I have no idea where the hell I read that. I'd try the changelogs of
upstream and the Debian package, however: that rings a bell on my mind.

As for the useful information, that I can help you with. All you have to do
is to let gnupg readd all your keys to a keyring (as in 'new insertions to a
keyring are made in the new cache scheme'). Simple enough to do with any RW
keyrings you might have:

1. move every keyring out of the way, including the RO ones.
2. feed a keyring to gnupg. You might want to use --fast-import followed by
an --update-trustdb for that.
3. replace the old keyring you fed gnupg with with the new one
4. repeat as needed.

I actually find it better to have just one RW keyring, and feed any RO
keyrings I might need (such as Debian's) to gnupg to get them added to that
RW keyring.  Since gnupg's handling of multiple keyrings is not really that
hot, keeping track of only a simple RW keyring helps a lot.

> Peace.
Hmm, sorry about that. I sounded far more annoyed/annoying ;) than I should
have.

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

doc-html-w3

[Joseph Schlecht]

I am seriously considering adopting [1]doc-html-w3. I use many of these 
recommendation on a daily basis where I work. It would be nice to have a 
current local copy of them. However, before I decide to go any further with 
the adoption process, I want to get some feedback for an idea that I have. 

I would like to change doc-html-w3's name to one that is more descriptive of 
its current and potential contents. I think that the name of this package is 
currently too narrow; besides HTML, indicated by the name, it also contains 
CSS2, SMIL, XPATH and many other recommendations. What do you think?

Here are a couple of the names I've been kicking around:
   a) doc-w3 (most general, my favorite; perhaps even doc-w3c)
   b) doc-markup-w3 (but this name excludes style: CSS2, XSLT, etc)
   c) doc-w3c-recommend
   d) [your suggestion here]

Feel free to CC me, thanks.

Joe Schlecht

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no\&bug=110945