Re: Resolvconf -- a package to manage /etc/resolv.conf

[Manoj Srivastava]

On Fri, 26 Sep 2003 21:37:21 +0200, Thomas Hood <[EMAIL PROTECTED]> said: 

> On Fri, 2003-09-26 at 20:25, Manoj Srivastava wrote:
>> I have a laptop that sometimes is on fixed ip wireless
>> networks. Since dhcp is not involved, there is nothing that updates
>> resolvconf, which could be pointing to an inaccurate set of
>> servers.

> If you bring the interface up with ifup then the solution is to put
> the nameserver address on a "dns-nameservers" line in the interface
> definition stanza.  E.g.,

I use that for my non-pcmcia interface.

> You must be referring to /etc/pcmcia/network.opts here.  Hmm, yes.
> If you are using the /etc/pcmcia/ stuff to configure PCMCIA network
> interfaces then this is a sensible thing to do.

Well, I've been using pcmcia way before there was hotplug, but
 I'm willing to learn.


> My own preference is to disable everything in
> /etc/pcmcia/network.opts and set things up so that hotplug does ifup
> and ifup configures the interface in the standard way.  Then I can
> use dns-nameservers lines for PCMCIA network interfaces too.

I would be interested in knowing how you set it up  equivalent
 to cardctl scheme allows me to set up pcmcia networks. Please mail e
 offlist if you wish.

manoj
-- 
In a great romance, each person basically plays a part that the other
really likes. Elizabeth Ashley
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Building kernel modules for stock kernels is a hell of a job!

[Manoj Srivastava]

On Tue, 23 Sep 2003 20:39:04 +0200, Manuel Bilderbeek <[EMAIL PROTECTED]> said: 

> Hello, Kernel 2.4.22 got into testing, so I have to go to the
> procedure again.

>> #include 
>> * Manuel Bilderbeek [Sun, Aug 24 2003, 04:32:45PM]:
>>
>>> The procedure I'm going through is as follows (being root all the
>>> time)
>>> 1) install the kernel source for the kernel,
>>> e.g. kernel-source-2.4.21
>>> 2) go to /usr/src and tar xjvf kernel-source-2.4.21.tar.bz2
>> Why don't you use the kernel-headers packages and use them as
>> partial kernel source? They provide header files (including the
>> complete kernel version) and the .config that belongs to them.

> OK, but that doesn't work! See this:

He said use the kernel-headers package, not
 kernel-package. Any debian packaged module shall work with something
 like:

 ./debian/rules KVERS="2.4.21" KSRC="/usr/src/kernel-headers-2.4.21" 
KPKG_DEST_DIR="../" KDREV="blah" kdist_image

> So, only with a full kernel source tree and the copied .config you
> seem to be able to use make-kpkg. I can't help it. Please tell me
> I'm wrong. :)

I think you may well be.

manoj
-- 
I find you lack of faith in the forth dithturbing. Darse ("Darth")
Vader
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian should not modify the kernels!

[Adam Borowski]

On Sat, 27 Sep 2003, George Danchev wrote:
> > Why not? It's a package. We modify it as we need to in order to provide
> > functionality and satisfy the needs of our users. I'm perfectly willing
> > to bet that more of our users are interested in a functional ipsec stack
> > than are interested in the grsecurity patch.
> 
> I think this is not a gamble story to make a bet. I as an debian user am 
> sorry 
> to hear that from you. This is simply unfair. Do in mind that there is no 
> sane way to understand if users prefer ipsec or grsec to be included by 
> default in kernel-source-. Both ipsec (freeswan) and grsec kernel 
> patches are not security fixes, they do not fix existing security holes, they 
> are security enhancements. They both deserve to be included as 
> kernel-patch- packages...
Well... as 2.6 is coming out really soon, ipsec is in a lot better 
position than grsec.  Also, you will _have_ to port grsec to 2.6 (or 
abandon it), and 2.6 will have ipsec in the upstream sources.  The only 
difference lies in needing to do the porting work a bit sooner.

1KB

/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: correct directorys for www.ltsp.org (for swap)

[Robert Jordens]

Hello!

[Sun, 28 Sep 2003] Daniel Josua Priem wrote:
> Hello,
> im have debianized www.ltsp.org.

Have you looked at

http://termserv.berlios.de/debian/dists/stable/non-free/binary-i386/

?

> the root-filesystem will now point to /usr/share/ltsp/ and mounted
> read-only by the clients

/usr/share is for architecture independent data. As the root fs for the
clients can be regenerated, that should go into
/var/lib/ltsp/.

> Now i need to have a swapfile folder where all the NFS_Swap files for
> the clints can be. Please tell me wich directory would be fine.
> I thinking about /var/cache/ltsp  because refering to the FHS
> 
> 5.2 /var/cache : Application cache data
> 
>  Package specific cache data
> ..Such data is locally generated as a result of time-consuming I/O
> or calculation. The application must be able to regenerate or restore
> the data. 
> 
> (if you dont delete when the client will be up no problem)

I guess you are implying the question whether this is the right place or
not... ;-] It seems to me.

Robert.

-- 
Despite the best efforts of a quantum bigfoot drive (yes I know everyone
told me they suck, now I know they were right) 2.1.109ac1 is now available
-- Alan Cox announcing Linux 2.1.109ac1


pgprRnmNZ6RAb.pgp
Description: PGP signature

Re: correct directorys for www.ltsp.org (for swap)

[Cameron Patrick]

On Sun, Sep 28, 2003 at 09:54:03AM +0200, Robert Jordens wrote:
| > the root-filesystem will now point to /usr/share/ltsp/ and mounted
| > read-only by the clients
| 
| /usr/share is for architecture independent data. As the root fs for the
| clients can be regenerated, that should go into
| /var/lib/ltsp/.

No, in LTSP the one root filesystem image is static data shared between
all clients of a given arch and can't be regenerated except by
reinstalling LTSP: thus it belongs in /usr not /var.  Also it is
"architecture independent" from a Debian packaging perspective as the
architecture of the clients need not match the architecture of the file
server; it would make sense to have an i386 LTSP root fs stored on a
Sparc NFS server, for instance.  Thus /usr/share is the correct
location.

| > Now i need to have a swapfile folder where all the NFS_Swap files for
| > the clints can be. Please tell me wich directory would be fine.
| > I thinking about /var/cache/ltsp  because refering to the FHS
[...]
| 
| I guess you are implying the question whether this is the right place or
| not... ;-] It seems to me.

Possibly /var/tmp or /var/lib would also be an option?  Not sure which
of the three is best, though.

Cameron.

Re: correct directorys for www.ltsp.org (for swap)

[Robert Jordens]

Hello!

[Sun, 28 Sep 2003] Cameron Patrick wrote:
> | /usr/share is for architecture independent data. As the root fs for the
> | clients can be regenerated, that should go into
> | /var/lib/ltsp/.
> 
> No, in LTSP the one root filesystem image is static data shared between
> all clients of a given arch and can't be regenerated except by
> reinstalling LTSP: thus it belongs in /usr not /var.  Also it is

Oh yes. You are right. I thought the root tree was still being gererated
from the host server's tree, but those times seem to have passed.

But this is strange. Why does lts-core include it's own version of
busybox and X and other packages? Why not use the Debian packages and
unpack them into the lts-root? What about security fixes as the recent
one in xfree86? Those don't get onto the lts-clients until a new lts is
uploaded.

Robert.

-- 
I asked the engineer who designed the communication terminal's keyboards
why these were not manufactured in a central facility, in view of the
small number needed [1 per month] in his factory.  He explained that this
would be contrary to the political concept of local self-sufficiency.
Therefore, each factory needing keyboards, no matter how few, manufactures
them completely, even molding the keypads.
-- Isaac Auerbach, IEEE "Computer", Nov. 1979


pgp0S3AkADwOZ.pgp
Description: PGP signature

Re: correct directorys for www.ltsp.org (for swap)

[Daniel J. Priem]

Am Son, 2003-09-28 um 10.55 schrieb Robert Jordens:
> Hello!
> 
> [Sun, 28 Sep 2003] Cameron Patrick wrote:
> > | /usr/share is for architecture independent data. As the root fs for the
> > | clients can be regenerated, that should go into
> > | /var/lib/ltsp/.
> > 
> > No, in LTSP the one root filesystem image is static data shared between
> > all clients of a given arch and can't be regenerated except by
> > reinstalling LTSP: thus it belongs in /usr not /var.  Also it is
> 
> Oh yes. You are right. I thought the root tree was still being gererated
> from the host server's tree, but those times seem to have passed.
> 
> But this is strange. Why does lts-core include it's own version of
> busybox and X and other packages? Why not use the Debian packages and
> unpack them into the lts-root? What about security fixes as the recent
> one in xfree86? Those don't get onto the lts-clients until a new lts is
> uploaded.
All this things will be fixed by me. i'm actuallay only use the
directory tree and some specials like get_ltscfg all the other binarys
are copied by me from hand so on my ltsp package you run only (excluding
the lstconfs) "debian-binarys" ( i actually write a script wich will do
that) to the right place. long before i run dpkg-buildpackage.
so if lets say busybox get e security hole in this moment when i get an
update from sec.d.oi build a new package with the fixed holes.


Daniel
> 
> Robert.
> 
> -- 
> I asked the engineer who designed the communication terminal's keyboards
> why these were not manufactured in a central facility, in view of the
> small number needed [1 per month] in his factory.  He explained that this
> would be contrary to the political concept of local self-sufficiency.
> Therefore, each factory needing keyboards, no matter how few, manufactures
> them completely, even molding the keypads.
>   -- Isaac Auerbach, IEEE "Computer", Nov. 1979
-- 
Retrieve my key from: 
www.keyserver.de 
blackhole.pca.dfn.de 
horowitz.surfnet.nl 
keyID 7B196671
or send email with subject "fetch key"


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Processed: closing, fixed in python2.3

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 204751 general
Bug#204751: dupload should check for ancient time stamps
Bug reassigned from package `python2.3-pyvtk' to `general'.

> retitle 204751 checking timestamps of files in uploaded packages
Bug#204751: dupload should check for ancient time stamps
Changed Bug title.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: [EVEN MORE OFFTOPIC] Re: /etc/shells management

[Tollef Fog Heen]

* Steve Greenland 

| 
| 
| Except Solaris, whose /bin/sh doesn't support ~. Or aliases. Or brace
| expansion. Or the pattern matching expansions (i.e. ${VAR%foo} and
| friends). Or return outside of functions. Or shell arithmetic with let.
| Or '-p' for prompting on read. Etc. and so forth.

or «local», which leads to nice and clean code like:

#! /bin/sh

# SunOS /bin/sh is broken wrt local. *sigh*
if test "`uname -s`" = "SunOS" -a "$RUNNING_UNDER_BASH" = ""; then
RUNNING_UNDER_BASH=1
export RUNNING_UNDER_BASH
exec bash $0 "$@"
fi

hoping that bash is somewhere in the path.

| 

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Bug#213045: ITP: astats -- Stats for aMule

[Anthony DeRobertis]

On Sat, 2003-09-27 at 18:59, Julien Delange wrote:

>   Description : Stats for aMule
> 

what? even apt-cache search aMule doesn't help (seems to pull up a lot
of nethack --- damn Amulet).

> 
> aStats is the successor of the well known xStats Statistics

so well known I've never heard of it.

> Generator, since bigbob have forked xMule to aMule, there's
> no need to use xStats anymore, so he modified scripts to 
> handle properly aMule statistics (by the way, xStats is not
> anymore supported).

I hope you don't plan on using that for the description...


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

您的网站有在线支付功能吗？

[特易在线支付]

debian-devel:您好!

支付问题是电子商务的最大难题，要申请一个在线支付接口经过烦杂的手续和高达数千元的接入费＋年费＋交易费等。并且结算周期长。


   
很多网站只能通过给网易、新浪等短信提成来变相实现收费。如用户支付12元给新浪，加盟网站只能得到3元。这样对站长和用户都很不利。
而且用户如果要选择手机支付前，总会担心手机会被重复扣款，或注册后无法取消而放心使用手机支付。并且现在中国移动清查短信联盟，
收费问题再一次摆到广大中小网站面前。如果有了在线支付平台，用户愿意支付8元，站长也能收获将近8元，达到双赢。

针对此现状，本公司推出了零风险的特易在线支付方案套餐组合。

特易在线支付方案的服务标准灵活、多样、便宜：
国庆前申请有特别优惠：200元年费，交易费率5%
常规方案：
无风险放心方案A：免服务费（0元，交易费率10%）。
无风险舒心方案B：月费(60元, 交易费率8%)，
无风险动心方案C：季度费(150元, 交易费率7%)，
无风险开心方案D：年费（500元，交易费率5%）。
为何要选择特易在线支付方案：
1.  能提供在线支付，很大地提高了网站地信誉度，增强了用户购买您产品的可能性。
2.  
相比手机支付，用户总会担心登记后是否会每个月都被扣钱，担心注册后无法取消，而银行卡在线支付就不存在此问题。
3.  提供方便快捷的在线支付功能，能触发用户的购买欲。
4.  
它的购买群体存在一种不成熟性，购物中的冲动性非常明显。如果即时支付不成功，要延后或手续麻烦，顾客的购买冲动往往已经消失了，这会直接导致业务的流失。因此虽然采用在线支付要支付少量的手续费，但是能把您的潜在客户变成真实的客户。
5.  
特易在线支付方案不需技术对接，即申请即可用，降低了技术难度。您只要注册为我们的代理商后，用代理商身份登陆后，选择"提交申请"，按照说明填写提交后，等待管理员审核后会给您一个商品的地址链接，您只要将这个链接放到您的网站上就可以了。
您的客户从您的网站上点击这个商品链接到达本站，就可以进行购买支付。同时您会收到订单生成、支付成功的邮件通知，然后到本站进行发货处理。
6.  
特易在线支付方案收费标准＝服务费+交易额*交易费率。免收初装费，为您节省数千元。
7.  如果您有自己的购物车、订单系统，我们也可以为您提供在线支付接口。
8.  
为商户提供详尽的订单查询功能，可以按支付情况，支付时间，用户名等关键字查询。
9.  
当您的客户购买了您的商品后，您会收到邮件通知，当用户支付成功后，您也会收到邮件通知，让您及时、准确了解商品销售、支付情况。因此您注册时一定要填写常用、准确的EMAIL地址。
10. 
您登陆后，可以查到所有购买您的商品的成功订单（支付成功），并根据此进行发货处理。
11. 
我们可以给客户定制一些个性化项目，如专业级购物车，订单系统，页面等这是其他供应商没有提供的。
12. 
原则上我们的结算期是每月的15日和31日，这是因为我们也要对最终的消费者的权利负责，您的消费者有15天的申诉有效期。如果15天内用户没有申诉，我们就会马上将您的销售额扣除交易费用后转帐给您。



www.payonline.com.cn
www.mypic.com.cn
email:[EMAIL PROTECTED]


致
礼!
  　　 特易在线支付
  　　 [EMAIL PROTECTED]
  　　 2003-09-28

做人，应该对生活充满自信!

[郑杨悟]

尊敬的debian-devel： 
 迎国庆大优惠[特卖] ！

因艾商城为了答谢新老顾客的厚爱！决定在2003年09月25日―2003年10月30日
VP-RX阴茎增大疗程装 9 折大优惠。欢迎新老顾客光临选购！注册会员订购有产品增送！

详细介绍和图片请看：http://www.yinlove.net   

电话订购：021-56728806

联系人：  李小姐

QQ咨询：  202963

Re: Converting configure.in for use with new auto* tools - what a mess!

[Martin Quinson]

On Sat, Sep 27, 2003 at 01:54:36PM -0500, Branden Robinson wrote:
> On Sat, Sep 27, 2003 at 02:45:20PM +0200, Martin Quinson wrote:
> > I use the attached bootstrap script to build the autotools scripts. the
> > version of autotools are hardcoded in it, which is a Bad Thing (TM). Feel
> > free to steal anyway ;)
> 
> As far as I could tell, this message had no attachment (apart from the
> message body and signature).

Ups
#!/bin/sh

##
## Some defs
##

PKG_NAME="w3c-libwww"
# a list of all dirs containing possibly some macros
acmacrodirs="${HOME}/share/aclocal ${PWD}/tools/acmacro ${PWD}/m4"
 
##
## End of conf part
##
for dir in $acmacrodirs ; do
   if test -d $dir ; then
   aclocalinclude="$aclocalinclude -I $dir";
   fi
done

srcdir=`dirname $0`
test -z "$srcdir" && srcdir=.

echo "Autoregenerate package \`$PKG_NAME' in directory \`$srcdir'";

(test -f $srcdir/configure.ac \
  && test -f $srcdir/Robot/src/RobotMain.c) || {
echo -n "**Error**: Directory "\`$srcdir\'" does not look like the"
echo " top-level $PKG_NAME directory"
exit 1
}

##
## Some tests (borrowed from Mt who borrowed it from 
## macros/autogen.sh from achtung)
##
DIE=0

(autoconf --version) < /dev/null > /dev/null 2>&1 || {
  echo
  echo "**Error**: You must have \`autoconf' installed to compile $PKG_NAME."
  echo "Download the appropriate package for your distribution,"
  echo "or get the source tarball at ftp://ftp.gnu.org/pub/gnu/";
  DIE=1
}

(grep "^AM_PROG_LIBTOOL" $srcdir/configure.ac >/dev/null) && {
  (libtool --version) < /dev/null > /dev/null 2>&1 || {
echo
echo "**Error**: You must have \`libtool' installed to compile $PKG_NAME."
echo "Get ftp://ftp.gnu.org/pub/gnu/libtool-1.4.tar.gz";
echo "(or a newer version if it is available)"
DIE=1
  }
}

(automake-1.7 --version) < /dev/null > /dev/null 2>&1 || {
  echo
  echo "**Error**: You must have \`automake' 1.7 installed to compile 
$PKG_NAME."
  echo "Get ftp://ftp.gnu.org/pub/gnu/automake-1.7.tar.gz";
  echo "(or a newer version if it is available)"
  DIE=1
  NO_AUTOMAKE=yes
}

# if no automake, don't bother testing for aclocal
test -n "$NO_AUTOMAKE" || (aclocal --version) < /dev/null > /dev/null 2>&1 || {
  echo
  echo "**Error**: Missing \`aclocal'.  The version of \`automake'"
  echo "installed doesn't appear recent enough."
  echo "Get ftp://ftp.gnu.org/pub/gnu/automake-1.3.tar.gz";
  echo "(or a newer version if it is available)"
  DIE=1
}

if test "$DIE" -eq 1; then
  exit 1
fi
## END of test part


##
## Action part
##
if test -z "$*"; then
  echo "**Warning**: I am going to run \`configure' with no arguments."
  echo "If you wish to pass any to it, please specify them on the"
  echo \`$0\'" command line."
  echo
fi
echo "Generating configuration files for $PKG_NAME, please wait"
echo;

case $CC in
xlc )
  am_opt=--include-deps;;
esac

#for coin in  `find $srcdir -name configure.ac -print `\
# `find $srcdir -name configure.in -print`
for coin in $srcdir/configure.ac
do 
  dr=`dirname $coin`
  if test -f $dr/NO-AUTO-GEN; then
echo skipping $dr -- flagged as no auto-gen
  else
echo ""
echo "* Processing directory $dr"
echo ""

if [ -e $dr/configure.in ] ; then
   configfile="configure.in"
else 
   configfile="configure.ac"
fi
macrodirs=`sed -n -e 's,AM_ACLOCAL_INCLUDE(\(.*\)),\1,gp' < $coin`
  pwd=`pwd`
  cd $dr
  if grep "^AM_PROG_LIBTOOL" $configfile >/dev/null; then
if test -z "$NO_LIBTOOLIZE" ; then 
  echo "Running libtoolize --force --copy in "`pwd`"..."
  libtoolize --force --copy
fi
  fi
  echo "Running aclocal-1.7 $aclocalinclude..."
  aclocal-1.7 $aclocalinclude 
  if grep "^AM_CONFIG_HEADER" $configfile >/dev/null; then
echo "Running autoheader in "`pwd`"..."
autoheader
  fi
  echo "Running automake-1.7 --gnu --add-missing $am_opt ..."
  automake-1.7 --gnu --add-missing $am_opt
#  echo "Running automake m4/Makefile ..."
#  automake m4/Makefile
  echo "Running autoconf..."
  autoconf
  cd $pwd
  fi
done

#conf_flags="--enable-maintainer-mode"

if test x$NOCONFIGURE = x; then
  echo ""
  echo "* Running $srcdir/configure $conf_flags $@ ..."
  echo ""

  $srcdir/configure $conf_flags "$@" || exit 1
else
  echo Skipping configure process.
fi

echo Now type \`make\' to compile $PKG_NAME



pgp7O9BmjPUFR.pgp
Description: PGP signature

Re: correct directorys for www.ltsp.org (for swap)

[Daniel J. Priem]

So as total summary:

rootfs will be /usr/share/ltsp/where  means CLIENT arch

rootswap will be /var/cache/ltspbecause refering to FHS "/var/cache
: Application _cache_ dataset different disk and backup policies.."

If anybody willing to tell other directorys.
Tell but please say why. 
It's a "nice" work for me to rebuild over 30 packages due to dirchanges.

Daniel


-- 
Retrieve my key from: 
www.keyserver.de 
blackhole.pca.dfn.de 
horowitz.surfnet.nl 
keyID 7B196671
or send email with subject "fetch key"


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#212988: ITP: turck-mmcache -- Precompiler and cache to improve performance of PHP scripts

[Tollef Fog Heen]

* Jonathan Oxer 

| Turck MMCache is a PHP Accelerator, Optimizer, Encoder and Dynamic 
| Content Cache. It increases performance of PHP scripts by caching 
| them in a compiled state, so that the overhead of compiling is almost 
| completely eliminated. It also uses some optimizations for speedup 
| of PHP script execution. Turck MMCache typically reduces server 
| load and increases the speed of PHP code by 1-10 times.

You probably want a patch similar to this to enable it to mkdir the
cache dir (unless you enable the cache_dir to be a directory which is
shipped in the package).  Also sending this upstream might be a good
idea, I haven't gotten around to it.

diff -ru turck-mmcache-2.4.0/mmcache.c turck-mmcache-2.4.0.tfheen/mmcache.c
--- turck-mmcache-2.4.0/mmcache.c   2003-09-22 09:51:51.0 +0200
+++ turck-mmcache-2.4.0.tfheen/mmcache.c2003-09-25 11:23:10.0 
+0200
@@ -812,9 +814,33 @@
  (v & 0xff));
 }
 
+static void mmcache_make_cache_dir_if_missing() {
+  int ret;
+  struct stat statbuf;
+  /* Ensure cache_dir exists */
+
+  ret = stat(MMCG(cache_dir), &statbuf);
+  if (ret == 0) {
+/* It exists, check that it is a directory */
+if (!S_ISDIR(statbuf.st_mode)) {
+  zend_error(E_ERROR, "cache_dir is not a directory");
+} /* else, all is well */
+  } else {
+if (errno == ENOENT) {
+  if (mkdir(MMCG(cache_dir), 0700) != 0) {
+zend_error(E_ERROR, "something weird happened mkdir-ing cache_dir: 
%s", strerror(errno));
+  }
+} else {
+  zend_error(E_ERROR, "something weird happened stat-ing cache_dir: %s", 
strerror(errno));
+  
+}
+  }
+} 
+
 #ifdef MMCACHE_USE_INODE
 static int mmcache_inode_key(char* s, dev_t dev, ino_t ino TSRMLS_DC) {
   int n;
+  mmcache_make_cache_dir_if_missing();
   strncpy(s, MMCG(cache_dir), MAXPATHLEN-1);
   strlcat(s, "/mmcache-", MAXPATHLEN-1);
   n = strlen(s);
@@ -849,6 +876,8 @@
   if (call_user_function(CG(function_table), (zval**)NULL, &md5, &retval, 1, 
params TSRMLS_CC) == SUCCESS &&
   retval.type == IS_STRING &&
   retval.value.str.len == 32) {
+
+mmcache_make_cache_dir_if_missing();
 strncpy(s, MMCG(cache_dir), MAXPATHLEN-1);
 strlcat(s, prefix, MAXPATHLEN);
 strlcat(s, retval.value.str.val, MAXPATHLEN);

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Bug#213127: ITP: extlib -- extended standard library for OCaml

[Stefano Zacchiroli]

Package: wnpp
Version: unavailable; reported 2003-09-28
Severity: wishlist

* Package name: extlib
  Version : 1.0b
  Upstream Author : Nicolas Cannasse, Brian Hurt, Yamagata Yoriyuki
* URL : http://ocaml-lib.sourceforge.net/
* License : LGPL
  Description : extended standard library for OCaml

ExtLib is a project aiming at providing a complete - yet small -
standard library for the OCaml programming langage.

Re: Debian should not modify the kernels!

[Greg Folkert]

On Sat, 2003-09-27 at 23:10, Herbert Xu wrote:
> Greg Folkert <[EMAIL PROTECTED]> wrote:
> > 
> > So  which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what
> > is the rational that they *REQUIRE* that piece. 
> 
> As for the criteria for inclusion, I have already outlined some simple
> rules earlier in this thread.  I would recommend you to read it if you
> are interested.

Yes but those criterion fail to mention why it is required in the Debian
Kernel Source. I understand it should be in the default Binary images...
but as for inclusion into the default source, still begs the question
_why_ is it required, as your simple statement doesn't cover that.

As far as benefits it provides *I* can see it being beneficial, but
still fail to see why since the entire "thrust" of Debian is all about
choice and not including everything by default and making some things
optional. I really have no problem with the distributed Binary Kernels
including this patch, but do think additional feature should be included
as a patch *to* the source, not *for removal*. 

And, just for grins and giggles here, if lets say that 90% of the
patches available to the patch system were, in fact, actively maintained
and have been/are candidates for inclusion in the Kernel by the Kernel
Core Team (err maybe just Linus) would you then be including all of them
as included patches and backports to the Debian Kernel source 2.4?

One more thing, why have you not included the IPSEC piece in the 2.2
Source then? 

> >> If someone wants to make a kernel-patch package out of it, go right
> >> ahead.
> > 
> > Would that then allow you to NOT include it in the kernel-source
> > package, but then make it a "standard" patch to be installed by default
> > then? And have a Variable "NO_IPSEC_PATCH" or something similar so that
> > kpkg doesn't apply it... but does apply other patches.
> 
> No, the purpose of such a kernel-patch package would be to allow a user
> to easily obtain the IPSEC patch should they wish to either apply it
> to a vanilla kernel, or unapply it from the Debian kernel.
> 
> Its existence is orthogonal to whether this patch is included in the
> Debian kernel source.

Again, why should it be orthogonal, seems opposite about why we even
HAVE the Kernel Patching in kpkg at all then. Let us go back to using
patch then.
 
> > But exactly why should this particular patch (IPSEC backport) cause so
> > much grief for the patch system, if it were to be so standard?
> 
> I do not believe that this patch has caused excessive grief for the
> benefits that it brings.  In fact, conflicts between the Debian kernel
> source and random kernel patches floating around are a fact of life.
> 
> For example, the grsecurity patch has had a history of conflicts with
> various patches in the Debian kernel source.  Most of those patches that
> caused conflicts were in fact essential security fixes.  You can review
> this for yourself by visiting to the BTS entry for the grsecurity
> package.

To be honest you are very right in this, in general though, why should
you add insult to injury on this by making the the situation worse? 
Granted grsecurity and a few other patches, really "screw" with the
source quite a bit, but I still fail to see why these need to be
included by default

Might just be we agree to disagree? And if I felt compelled to... could
I maintain a kernel-source that only has bug and security fixes in it
with no additional features added? Would you sponsor it? (Rhetorically
asked)
-- 
greg, [EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry

Your eyes are much like milky pools of pantyhose.


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

Re: correct directorys for www.ltsp.org (for swap)

[Steve Langasek]

On Sun, Sep 28, 2003 at 10:55:56AM +0200, Robert Jordens wrote:
> Hello!

> [Sun, 28 Sep 2003] Cameron Patrick wrote:
> > | /usr/share is for architecture independent data. As the root fs for the
> > | clients can be regenerated, that should go into
> > | /var/lib/ltsp/.

> > No, in LTSP the one root filesystem image is static data shared between
> > all clients of a given arch and can't be regenerated except by
> > reinstalling LTSP: thus it belongs in /usr not /var.  Also it is

> Oh yes. You are right. I thought the root tree was still being gererated
> from the host server's tree, but those times seem to have passed.

> But this is strange. Why does lts-core include it's own version of
> busybox and X and other packages? Why not use the Debian packages and
> unpack them into the lts-root? What about security fixes as the recent
> one in xfree86? Those don't get onto the lts-clients until a new lts is
> uploaded.

FWIW, last time I tried I found that it was rather difficult to run
debootstrap from within a package postinst script... at least with
debconf using an interactive frontend. :)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: correct directorys for www.ltsp.org (for swap)

[Robert Jordens]

Hello!

[Sun, 28 Sep 2003] Steve Langasek wrote:
> > But this is strange. Why does lts-core include it's own version of
> > busybox and X and other packages? Why not use the Debian packages and
> > unpack them into the lts-root? What about security fixes as the recent
> > one in xfree86? Those don't get onto the lts-clients until a new lts is
> > uploaded.
> 
> FWIW, last time I tried I found that it was rather difficult to run
> debootstrap from within a package postinst script... at least with
> debconf using an interactive frontend. :)

Yes. debootstrap in postinst is not a good idea. It is likely to fail
and takes tool long. But a tool on top of debootstrap and the ltsp
generation scripts should allow that kind of updating and would not
require new ltsp packages for every security advisory.

Robert.

-- 
Kiss your keyboard goodbye!


pgpteK7enaE3C.pgp
Description: PGP signature

做人，应该对生活充满自信!

[郑杨悟]

尊敬的debian-devel： 
 迎国庆大优惠[特卖] ！

因艾商城为了答谢新老顾客的厚爱！决定在2003年09月25日―2003年10月30日
VP-RX阴茎增大疗程装 9 折大优惠。欢迎新老顾客光临选购！注册会员订购有产品增送！

详细介绍和图片请看：http://www.yinlove.net   

电话订购：021-56728806

联系人：  李小姐

QQ咨询：  202963

Re: correct directorys for www.ltsp.org (for swap)

[Daniel J. Priem]

Am Son, 2003-09-28 um 17.24 schrieb Robert Jordens:
> Hello!
> 
> [Sun, 28 Sep 2003] Steve Langasek wrote:
> > > But this is strange. Why does lts-core include it's own version of
> > > busybox and X and other packages? Why not use the Debian packages and
> > > unpack them into the lts-root? What about security fixes as the recent
> > > one in xfree86? Those don't get onto the lts-clients until a new lts is
> > > uploaded.
> > 
> > FWIW, last time I tried I found that it was rather difficult to run
> > debootstrap from within a package postinst script... at least with
> > debconf using an interactive frontend. :)
> 
> Yes. debootstrap in postinst is not a good idea. It is likely to fail
> and takes tool long.
and i get a lot of uneeded files in the filesystem

 But a tool on top of debootstrap and the ltsp
do you think something like this 

ltsp-core has something similar(or debootstrap with --options) to
debootstrap lets say 

build_rootfs.sh  clientarch=i386/mips/ppc xservers=all/svga/vga16  
from=f.d.o  saveconf=/etc/ltsp/rootfs.conf

on secupdates we update ltsp-core

in postinst.ex have something like 
build_rootfs.sh readconf /etc/ltsp/rootfs.conf --update rootfs 
wich then will do nothing other then looking for newer debs download
them unpack them to the rootfs.

Please critic me if i'm wrong. i need to learn and figure out this.

Daniel

> generation scripts should allow that kind of updating and would not
> require new ltsp packages for every security advisory.
> 
> Robert.
> 
> -- 
> Kiss your keyboard goodbye!
-- 
Retrieve my key from: 
www.keyserver.de 
blackhole.pca.dfn.de 
horowitz.surfnet.nl 
keyID 7B196671
or send email with subject "fetch key"


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: correct directorys for www.ltsp.org (for swap)

[Robert Jordens]

Hello!

[Sun, 28 Sep 2003] Daniel J. Priem wrote:
> build_rootfs.sh  clientarch=i386/mips/ppc xservers=all/svga/vga16  
> from=f.d.o  saveconf=/etc/ltsp/rootfs.conf
> 
> on secupdates we update ltsp-core

This seems unnecessary and won't work as desired. If ltsp is in stable
you cannot ask for a security update of ltsp-core everytime a security
advisory for busybox or xfree86 happens. So people will have to update
their rootfs manually anyway.

> in postinst.ex have something like 

The local admin should realize that his reaction to a security advisory
should not only be "apt-get update && apt-get upgrade" but also:

> build_rootfs.sh readconf /etc/ltsp/rootfs.conf --update rootfs 

That should be sufficient. That should be put into README.Debian.

> wich then will do nothing other then looking for newer debs download
> them unpack them to the rootfs.

Nice. Well done. Are you in contact with the skolelinux people? LTSP is
something really useful for a school (it was for mine).

Robert.



pgp4hw4rAJ91t.pgp
Description: PGP signature

Re: Debian should not modify the kernels!

[Marco d'Itri]

On Sep 28, Greg Folkert <[EMAIL PROTECTED]> wrote:

 >Yes but those criterion fail to mention why it is required in the Debian
 >Kernel Source. I understand it should be in the default Binary images...
 >but as for inclusion into the default source, still begs the question
 >_why_ is it required, as your simple statement doesn't cover that.
If you want an unmodified kernel then download it from a kernel.org
mirror. Debian is supposed to ship an *useful* kernel.

-- 
ciao, |
Marco | [2150 os5doX61yZxwg]


signature.asc
Description: Digital signature

Re: Bug#213045: ITP: astats -- Stats for aMule

[Julien Delange]

On Sun, Sep 28, 2003 at 07:06:08AM -0400, Anthony DeRobertis wrote:
> what? even apt-cache search aMule doesn't help (seems to pull up a lot
> of nethack --- damn Amulet).

I've made an ITP for aMule, and I will upload aMule package soon.

> so well known I've never heard of it.

http://freshmeat.net/projects/xstats/?topic_id=1011%2C861
xStats was developped by the same person as aStats.

> I hope you don't plan on using that for the description...


No, the upstream author tell me this description, because, I'm not
famous
in english, and I have no idea for this description.
Be sure that it will change !


-- 
:: Julien Delange (julien AT gunnm DOT org) | :: GPG ::   
   / 
 x http://gunnm.org   / 8F36 4FD5 3845 6565 71DC 
 x http://julien.gunnm.org| F440 14D0 D2C0 FF1C EFB3

Bug#213149: ITP: libhtml-template-associate-perl -- Helps use HTML::Template in conjunction with other modules

[Gunnar Wolf]

Package: wnpp
Severity: wishlist


* Package name: libhtml-template-associate-perl
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.cpan.org/modules/by-module/HTML/
* License : GPL, Artistic
  Description : Helps use HTML::Template in conjunction with other modules
  Simplifies managing the relation between the HTML::Template module 
  (found in the libhtml-template-perl package in Debian) and other modules.  
  Support is now provided for Data::FormValidator (found in the  
  libdata-formvalidator-perl package), but it can be extended to use other  
  modules. 

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux shmate 2.4.21-gwolf #1 Fri Jun 27 13:04:09 CDT 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Re: correct directorys for www.ltsp.org (for swap)

[Bernd Eckenfels]

On Sun, Sep 28, 2003 at 05:59:15PM +0200, Robert Jordens wrote:
> This seems unnecessary and won't work as desired. If ltsp is in stable
> you cannot ask for a security update of ltsp-core everytime a security
> advisory for busybox or xfree86 happens.

Why not? I mean I do agree that it is not the nices solution, but I dont see
a reason for not fixing security problems.

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

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Neil Roeth]

On Sep 28, Manoj Srivastava ([EMAIL PROTECTED]) wrote:
 > On Fri, 26 Sep 2003 21:37:21 +0200, Thomas Hood <[EMAIL PROTECTED]> said: 
 > 
 > > On Fri, 2003-09-26 at 20:25, Manoj Srivastava wrote:
 > >> I have a laptop that sometimes is on fixed ip wireless
 > >> networks. Since dhcp is not involved, there is nothing that updates
 > >> resolvconf, which could be pointing to an inaccurate set of
 > >> servers.
 > 
 > > If you bring the interface up with ifup then the solution is to put
 > > the nameserver address on a "dns-nameservers" line in the interface
 > > definition stanza.  E.g.,
 > 
 >  I use that for my non-pcmcia interface.
 > 
 > > You must be referring to /etc/pcmcia/network.opts here.  Hmm, yes.
 > > If you are using the /etc/pcmcia/ stuff to configure PCMCIA network
 > > interfaces then this is a sensible thing to do.
 > 
 >  Well, I've been using pcmcia way before there was hotplug, but
 >  I'm willing to learn.
 > 
 > 
 > > My own preference is to disable everything in
 > > /etc/pcmcia/network.opts and set things up so that hotplug does ifup
 > > and ifup configures the interface in the standard way.  Then I can
 > > use dns-nameservers lines for PCMCIA network interfaces too.
 > 
 >  I would be interested in knowing how you set it up  equivalent
 >  to cardctl scheme allows me to set up pcmcia networks. Please mail e
 >  offlist if you wish.

I switched from using cardctl to hotplug earlier this year.  I didn't care to
use any of the packages that do automatic detection of the network, so I set
up a system just like cardctl scheme that allows me to choose which scheme to
use manually.  I no longer have pcmcia-cs installed at all.  I just execute
"hpscheme default" or "hpscheme bs9" and then plug the card in.  It works from
there (don't expect any beeps, though).

I put this in /etc/network/interfaces:


mapping hotplug
script /usr/local/bin/map-scheme

iface default inet static
address ppp.ppp.ppp.ppp
netmask 255.255.255.0
gateway qqq.qqq.qqq.qqq

iface bs9 inet static
address nnn.nnn.nnn.nnn
netmask 255.255.255.128
gateway mmm.mmm.mmm.mmm

iface dhcp inet dhcp


The "mapping" stanza is what figures out which interface to associate with
eth0, i.e., default, bs9, or dhcp.  Here is the script
/usr/local/bin/map-scheme:


#!/bin/bash

# Used with /etc/network/interfaces mapping function, which passes the
# interface name as the first argument.

/usr/local/bin/hpscheme get


Here is the script /usr/local/bin/hpscheme:


#!/bin/bash -e

# Set or display a scheme, used by my hotplug setup to choose network settings
# for PCMCIA card.  Similar to what 'cardctl scheme' did in old pcmcia-cs pkg.

DIR=/var/lib/hpscheme
FL=${DIR}/scheme
[ -d ${DIR} ] || mkdir -p ${DIR}
[ -f ${FL} ] || echo default>${FL}

USAGE="USAGE: $(basename $0) {get|put }"

if [ $# -lt 1 ]; then
echo "$USAGE"
exit 1
elif [ "$1" = "get" ]; then
cat ${FL}
elif [ "$1" = "put" ]; then
echo "Current scheme is '$(cat ${FL})'; setting to '$2'" && echo $2>${FL}
else
echo "$USAGE"
exit 1
fi


You can also add dns-search and dns-nameservers lines to the stanzas in
/etc/network/interfaces if you are using resolvconf, or add scripts to
if-up.d/ and if-down.d/ to muck about with resolv.conf, or whatever you like.
I've done both, though I just switched to resolvconf (thanks, Thomas!).

In addition, of course, you need to set up hotplug, i.e., compile your kernel
with the appropriate options and drivers, etc.

-- 
Neil Roeth

Re: correct directorys for www.ltsp.org (for swap)

[Robert Jordens]

Hello!

[Sun, 28 Sep 2003] Bernd Eckenfels wrote:
> On Sun, Sep 28, 2003 at 05:59:15PM +0200, Robert Jordens wrote:
> > This seems unnecessary and won't work as desired. If ltsp is in stable
> > you cannot ask for a security update of ltsp-core everytime a security
> > advisory for busybox or xfree86 happens.
> 
> Why not? I mean I do agree that it is not the nices solution, but I dont see
> a reason for not fixing security problems.

I guess you overread the alternative: choose between new lts-core
advisories and a simple

 build_rootfs.sh readconf /etc/ltsp/rootfs.conf --update rootfs

for every advisory.

Robert.

-- 
System restarting, wait...


pgpKoZBpqFkr4.pgp
Description: PGP signature

Re: Format of Release file and tools to create

[debacle]

On Wed, Sep 24, 2003 at 08:39:06PM +, [EMAIL PROTECTED] wrote:
> Which is the tool (of choice) to create the files?

I wrote a small script myself now, but I'm sure, that other
people did better.  See attachment.  At least it seems to
work with the apt-get/apt-move/FAI tool-chain.

Cheers!

#!/bin/sh

ORIGIN="Debian"
LABEL="Debian"
SUITE="testing"
CODENAME="sarge"
DESC="Debian Testing distribution - Not Released"

args=`getopt c:d:l:o:s: $*`
for o
do case "$o" in
-c) CODENAME="$2"; shift; shift;;
-d) DESC="$2"; shift; shift;;
-l) LABEL="$2"; shift; shift;;
-o) ORIGIN="$2"; shift; shift;;
-s) SUITE="$2"; shift; shift;;
--) shift; break;;
esac
done



DATE=`date -u`
PACKAGES=`find . -name Packages -o -name Packages.gz -o \
-name Sources -o -name Sources.gz`
DIRS=`for p in $PACKAGES; do dirname $p; done|sort -u`
COMPS=`for d in $DIRS; do echo $d | \
sed 's,[^A-Za-z0-9-]*\([A-Za-z0-9-]*\)/.*,\1,'; done|sort -u`
ARCHS=`for d in $DIRS; do echo $d | \
sed 's,.*binary-\([A-Za-z0-9-]*\),\1,'; done|sort -u`

for d in $DIRS; do
cd $d
ARCH=`echo $d | sed 's,.*binary-\([A-Za-z0-9-]*\),\1,'`
COMP=`echo $d | sed 's,[^A-Za-z0-9-]*\([A-Za-z0-9-]*\)/.*,\1,'`
echo "Archive: $SUITE
Component: $COMP
Origin: $ORIGIN
Label: $LABEL
Architecture: $ARCH" > Release
cd -
done

rm -f Release
MD5FILES=`find . -name Packages -o -name Packages.gz -o \
-name Sources -o -name Sources.gz -o -name Release \
| sed 's,^[^/]*/,,'`

echo "Origin: $ORIGIN
Label: $LABEL
Suite: $SUITE
Codename: $CODENAME
Date: $DATE
Architectures:" `echo $ARCHS`"
Components:" `echo $COMPS`"
Description: $DESC
MD5Sum:" > Release

for m in $MD5FILES; do
echo -n " " >> Release
SIZE=`wc -c $m | sed 's/ *\([0-9]*\).*/\1/'`
SUM=`md5sum $m | sed 's/^ *\([A-Fa-f0-9]*\) .*/\1/'`
printf "%s %16d %s\n" $SUM $SIZE $m >> Release
done

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Thomas Hood]

Manoj wrote:
> > I would be interested in knowing how you set it up  equivalent
> > to cardctl scheme allows me to set up pcmcia networks.

cardmgr's system of configuring things dependently upon
"scheme,socket,instance,hwaddr" is quite powerful but it is
possible to configure interfaces dependently on these variables
using ifupdown too (... though not so conveniently).  See below.

On Sun, 2003-09-28 at 21:03, Neil Roeth wrote:
> I switched from using cardctl to hotplug earlier this year.  I didn't care to
> use any of the packages that do automatic detection of the network, so I set
> up a system just like cardctl scheme that allows me to choose which scheme to
> use manually.  I no longer have pcmcia-cs installed at all.  I just execute
> "hpscheme default" or "hpscheme bs9" and then plug the card in.  It works from
> there (don't expect any beeps, though).

The simplest way to activate hotplug control of network interfaces
is to add this stanza to /etc/network/interfaces:

mapping hotplug
script echo

This makes "ifup eth0=hotplug" equivalent to "ifup eth0".  Once this
is added you can add mapping stanzas that cause a logical interface
to be chosen according to the network environment (as guessnet and
ifscout[1] do), according to a scheme (as your script and ifscout do),
according to hwaddr (as /usr/share/doc/ifupdown/examples/get-mac-address.sh
does), and so on.

mapping eth0
script guessnet
map foo
map bar

iface foo inet static
...

iface bar inet dhcp

[1] http://panopticon.csustan.edu/thood/ifupdown-roam.html
--
Thomas

Re: The size of debian packages

[Florian Weimer]

On Fri, Sep 26, 2003 at 11:12:48AM +1000, Jonathan Oxer wrote:

> Consider also not just what packages are installed but other things that
> could be using space: logs, caches etc. Not too many machines would have
> 3GB of actual packages installed unless you'd been *really* liberal with
> dselect  ;-)

kdirstat is nice for discovering the offenders when you have no idea
where they might be located (although it's quite slow with many files).

Re: Converting configure.in for use with new auto* tools - what a mess!

[Scott James Remnant]

On Sat, 2003-09-27 at 11:23, Richard Atterer wrote:

> I've fixed a critical bug in w3c-libwww and now want to regenerate all the 
> libtool/autoconf/automake files. Not trivial!
> 
> With the same libtoolize/aclocal-1.4/autoheader2.13 under unstable, the
> latter gives "FATAL ERROR: Autoconf version 2.50 or higher is required for
> this script".
> 
/usr/share/doc/libtool/README.Debian

If you are developing software that still uses Autoconf 2.13 you will
be unable to use this version of Libtool.  It is strongly recommended
that you update the software to use Autoconf 2.5x.  If that is not
possible you will need to install the deprecated GNU Libtool 1.4
release available in Debian as the 'libtool1.4' package.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


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

Bug#213183: ITP: cabber -- Easy and basic jabber console client

[David Fernández Vaamonde]

Package: wnpp
Version: unavailable; reported 2003-09-29
Severity: wishlist

* Package name: cabber
  Version : 0.4.0-test5
  Upstream Author : A. J. Macías <[EMAIL PROTECTED]>
* URL : http://cabber.sourceforge.net
* License : GPL
  Description : Easy and basic jabber console client

Very easy and basic jabber console client based in ncurses, customizable
and useful for use in a remote console.

-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux hogwarts 2.4.22 #11 lun sep 8 00:23:29 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to es_ES)

Bug#213187: ITP: cabber -- Easy and basic jabber console client

[David Fernández Vaamonde]

Package: wnpp
Version: unavailable; reported 2003-09-29
Severity: wishlist

* Package name: cabber
  Version : 0.4.0-test5
  Upstream Author : A. J. Macías <[EMAIL PROTECTED]>
* URL : http://cabber.sourceforge.net/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Description : Easy and basic jabber console client

Very easy and basic jabber console client based in ncurses, customizable
and useful for use in a remote console.

-- System Information:
Debian Release: 3.0
Architecture: i386
Kernel: Linux hogwarts 2.4.22 #11 lun sep 8 00:23:29 CEST 2003 i686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to es_ES)

Re: Debian should not modify the kernels!

[Matt Zimmerman]

On Sun, Sep 28, 2003 at 06:08:45PM +0200, Marco d'Itri wrote:

> On Sep 28, Greg Folkert <[EMAIL PROTECTED]> wrote:
> 
>  >Yes but those criterion fail to mention why it is required in the Debian
>  >Kernel Source. I understand it should be in the default Binary images...
>  >but as for inclusion into the default source, still begs the question
>  >_why_ is it required, as your simple statement doesn't cover that.
> If you want an unmodified kernel then download it from a kernel.org
> mirror. Debian is supposed to ship an *useful* kernel.

Hear, hear.  IPsec in particular is long overdue in the Linux kernel and I
am glad to see it.

-- 
 - mdz

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Manoj Srivastava]

On Sun, 28 Sep 2003 21:49:28 +0200, Thomas Hood <[EMAIL PROTECTED]> said: 

> Manoj wrote:
>> > I would be interested in knowing how you set it up equivalent to
>> > cardctl scheme allows me to set up pcmcia networks.

> cardmgr's system of configuring things dependently upon
> "scheme,socket,instance,hwaddr" is quite powerful but it is possible
> to configure interfaces dependently on these variables using
> ifupdown too (... though not so conveniently).  See below.

One can also modify  /etc/pcmcia/network; line 109:

<  cat $RESOLV >> $RESOLV.N; mv $RESOLV.N $RESOLV
>  cat $RESOLV >> $RESOLV.N; resolvconf -a $DEVICE < $RESOLV.N

Anyway, I think I am goinf to use start_fn and stop_fn in
 /etc/pcmcia/network.opts instead of using either hotplug or modifying
 /etc/pcmcia/network;  I am already comfortable with my network.opts,
 and it is all working together very nicely now.

Thanks for resolvconf.

manoj
-- 
Wow, I'm being shot at from both sides.  That means I *must* be right.
:-) Larry Wall in <[EMAIL PROTECTED]>
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#212525: Package contains non-free GNU FDL material

[Manoj Srivastava]

On Fri, 26 Sep 2003 11:12:06 -0400, Peter S Galbraith <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> I understand that debian-legal acts in an advisory capacity, and is
>> very useful to maintainers who need advice on licensing issues. And
>> I shall stipulate that there is a rough consensus on debian-legal
>> about the GFDL.

> Right. There is consensus in -legal that the GFDL is not a free
> software license (even RMS agrees).

>> This decision to exclude GNU documentation from Debian, given the
>> sheer volume of GNU software in Debian, is likely to be
>> controversial. And we need to have a common stance on this issue.

> Huh?  It's not a free software license, but because we use `so much
> of it', it's not a bug until 50% of developers agree?  That doesn't
> make sense.  Quantity is not an issue here.

It is not a bug unless there is a firm position statement by
 Debian, or I, as the maintainer, am convinced of the fact.

>> If this is all so very obvious and clear cut, why is it so hard to
>> first get a position statement from the DPL, and possibly the
>> release manager?

> Note that they haven't publicably disagreed with -legal.  The
> release manager says he won't treat it as an RC bug for sarge, but
> he didn't say it wasn't a bug.

I am taking the position that the release manager would not
 put forth a release in gross violation of the social contract.
 Unless there is evidence to the contrary, I believe in our RM.

>> Why should we not have a common solution?

> Everyone is free to discuss it on -legal.  It's not a closed list.

I have no objection to people discussing whatever they wish on
 legal either.

>> Should I just move make, make-doc, and Gnus to non-free, in
>> accordance with the spirit of upstreams desires (do not separate
>> the political text from software)?

> That would be your choice to make, as maintainer.  It wouldn't be
> very productive, but it's your choice.

> If fixing this bug is a lot a work, then leave it open until you can
> do it.  It's apparently not even RC for sarge.  But you are saying
> it's not a bug because there are many affected packages.

If I determine that my packages are indeed shipping non free
 material, than I shall ask for them to be removed from testing and
 unstable; since not doing so would violate the social contract.

I am afraid the social contract trumps what the RM may say.

manoj
-- 
Dawn, n.: The time when men of reason go to bed. Ambrose Bierce, "The
Devil's Dictionary"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

l/O/5/5/1/8/6 Ì/î/ñ/ê/â/à / Ð/à/ç/ã/î/â î ð í û é à í ãë/è/é/ñ ê è é ÿ/ç/û/ê c ïð/å// ï î ä à â à ò å/ë/ÿ/ì è èç Ñ/Ø/À bmB6lhCRQybhgKelzUl26tCBR

[stevef]

Добрый день Debian-devel!

К ак д ела?

Ц.ент.р А.мери.к.а.н.ско.г.о А.нгли.й.с.кого. Go9l4fp

П.риг.лашаем к се.бе. Моск.ва Ро.ссия prPfVkt

Пре.дл.агае.м б.ыстро выу.чить  Р а .з. г о.. вор н ы й   а.н..г ли й.с.кий  я 
зык 

Уникальная  м е тоди к а  обу че н и я  
HCXcwpMdqK9JTH6D3M2c96r

М Ы Ш ЛЕН И Е, п р о и з н о ш е н и е, с т и л ь  р е ч и.
AxUpLOKgwneIUFw77t


Тел. l..O5.-.5.1.-8.6  M.o..s.cow Russia gQbXYN1

Звон и тес ейч а с! П р и х о д и т е  с е г о д н я! KQdVY
Ame r i c a n   L ang u a ge   C ent e r -  s tar t   l ear nin g   e ngl i sh  
  T oda y!

Желаем вам успешного дня.

GvwAVio HzW5MF0t c7 AvnqHlpwm 

Debian and the GNU Free documentation license

[Manoj Srivastava]

Hi folks,

Beginning in 2001, concerns regarding the compatibility of the
 GNU Free Documentation License with the Debian Free Software
 Guidelines came to the attention of the debian-legal mailing list.

In early 2002, the Free Software Foundation announced that it
 would be revising the GNU FDL and producing a new version, issued a
 draft, and solicited feedback from the community.

Towards the end of 2002, the FSF released version 1.2 of the
 GNU FDL, but their new version did not address several of the
 DFSG-related concerns of the Debian Project. An additional year's
 worth of discussions with representatives of the GNU FDL did not
 persuade the Debian Project that its interpretation of the license or
 its own guidelines are incorrect; neither did they persuade the FSF
 that substantial alteration of the FDL's terms were warranted.

Unfortunately, most of this discussion has been confined to
 the debian-legal mailing list, with the result that people like me
 who do not follow debian-legal are not aware of the situation, and,
 for the most, do not know the details of the issue involved.

If the concerns of the people on debian-legal are shared by
 the developer body at large, we may have a potentially serious
 issue. The first step to determine this is making people aware of
 the issues involved.  The next would be to see if we can reach a
 determination of the position the project at large want to take on
 this issue.

Having a common position for the project on this issue would
 also help in trying to resolve the concerns; having a common voice,
 and knowing what the project wishes to do about packages that ship
 with GFDL licensed material would help our representative to better
 project Debian's position.

I have prepared a document that encapsulates the concerns that
 Debian folks have raised over in debian-legal, along with an
 annotated version of the GFDL. I have tried to be inclusive, and have
 incorporated in this one document all the concerns that have been
 voiced by various people on debian-legal. This is a work in progress,
 it is meant to be discussed and modified by the developer body. It
 needs to be integrated into a coherent position statement, and it the
 polish that it currently lacks needs to be remedied.

At this stage, I have distinguished between my commentary
 (which has largely not been honed in a discussion), and mature
 commentary from mavens on debian-legal; and I have attributed each
 contributor separately. Over time, I hope to use this document as the
 basis for crafting a common position statement by the developers,
 which we can issue under section 4.1.5 of the debian constitution.

   I need your help to create and refine this position statement.

Thanks for your patience. The URL of the document is:
 http://people.debian.org/%7Esrivasta/Position_Statement.xhtml>

manoj
-- 
Be consistent.  --Larry Wall in the perl man page
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian should not modify the kernels!

[Greg Folkert]

On Sun, 2003-09-28 at 12:08, Marco d'Itri wrote:
> On Sep 28, Greg Folkert <[EMAIL PROTECTED]> wrote:
> 
>  >Yes but those criterion fail to mention why it is required in the Debian
>  >Kernel Source. I understand it should be in the default Binary images..