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

[Manoj Srivastava]

Hi,

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.

The solution, in my case, was to  add the following star and
 stop functions to the relevant stanza's (edit for the  static dns
 servers) 

  # Extra stuff to do after setting up the interface
  start_fn () {
[ -x /sbin/resolvconf ]  && \
   echo "nameserver 127.0.0.1"| /sbin/resolvconf -a $DEVICE;
[ -x /sbin/resolvconf ]  && \
   echo "nameserver 192.168.1.10" | /sbin/resolvconf -a $DEVICE;
[ -x /sbin/resolvconf ]  && \
   echo "nameserver 198.6.1.4"| /sbin/resolvconf -a $DEVICE;
  }
  # Extra stuff to do before shutting down the interface
  stop_fn () { [ -x /sbin/resolvconf ]  && /sbin/resolvconf -d $DEVICE; }

manoj
-- 
What's love but a second-hand emotion? Tina Turner
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

[Andrew Suffield]

On Wed, Sep 24, 2003 at 02:39:01PM -0500, Manoj Srivastava wrote:
>   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.  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? 

Because they have no authority to make such statements?

>   This issue is not cut and dried (indeed, it took even the
>  mavens on -legal over a year to reach the current position). 

This is essentially false. It was fairly rapidly concluded that the
GFDL can be a non-free license under certain conditions, and that this
use qualifies. It took a bit longer to determine that it was non-free
under all conditions. We then spent over a year trying to find
alternatives to removing all the GFDL documentation from main, and
failed.

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


signature.asc
Description: Digital signature

Re: Timeout of ITP's

[Anthony Towns]

On Thu, Sep 25, 2003 at 08:38:53PM +0200, S?ren Boll Overgaard wrote:
> So, my question is, how long should an ITP be allowed to just sit there
> before someone else (in this case myself or anyone else who would be
> interested) can go ahead and "hijack" it? 

Consider ITP's as advisory locks. If you're interested in maintaining
a package then it's useful information on how to avoid work (email the guy,
get whatever he's done so far), or a useful advisory of who might be worth
cooperating with (do the work yourself, upload it, email the guy and offer
to pass along maintainership when he's ready, or co-maintain it if he's
interested).

In either case, if you don't get responses, just maintain it yourself. If
you get responses later - even months later - be appreciative of the help.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda


pgpCtDvxTJOwG.pgp
Description: PGP signature

Re: Bug#192101: We need gnucash in stable

[Steve Langasek]

On Fri, Sep 26, 2003 at 11:37:06PM +0200, Joachim Breitner wrote:
> sorry to bug you again, and for "escalating" this to debian-devel, but
> something needs to be done. For those just joining us:

> gnucash (the probably most complete wand fit-for-real-use financing
> program in debian) is not in testing for sarge at all. While the package
> works very well for all users that get a binary, it just does not build
> on some architectures (arm, hppa, m68k, mips{,el}). The problem lies in
> the deep of some guile test in the gnucash testsuite, and is somehow
> related to a random generater. Anyway, the maintainer tried to fix it,
> upstream worked on it, but nothing helped yet, and nothing probably
> won't help - at least within the next few weeks.

> I would argue that it would be the best for our users if we put gnucash
> in testing on the arches it builds, and leave the others out until they
> are fixed. This would 
>  * give the majority (i386, powerpc, etc) of our future sarge users this
> program
>  * have most of our woody users still have gnucash in their debian when
> they upgrade
>  * is absolutely no worse for those on the failing architectures, since
> they won't have gnucash either way
>  * if we fix the problem, we can add more architectures (for the same
> version) in a sarge-r1-release.

> The problem is that http://www.debian.org/devel/testing.en.html states:
> > 2. It must be compiled and up to date on all architectures it has
> previously been compiled for in unstable;

> So I am basically calling for an exception here.

What you are overlooking is that the main bug causing build failures
for gnucash is NOT architecture specific; rather, the potential for a
build failure appears to exist on all architectures, but the use of a
*pseudo*-RNG for generating test data tends to result in certain corner
cases being reliably hit in some build environments, and reliably
missed in others.

> PS: I wonder: why is the architecture count compared to prior versions
> in _unstable_, while the RC-Bug count is compared to the RC-Bug count of
> the perior version in _testing_? Seems to be inconsequent. Why not have
> the line say:
> > 2. It must be compiled and up to date on all architectures it has
> previously been compiled for in testing; ?

Because the principle is "if it built on the architecture at once, we
expect it to be buildable again unless given a good reason".

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Debian RC System/Init Scripts

[Andrew Suffield]

On Thu, Sep 25, 2003 at 08:16:22AM -0500, Steve Greenland wrote:
> On 24-Sep-03, 20:48 (CDT), Jerry Haltom <[EMAIL PROTECTED]> wrote: 
> > Please don't denounce my efforts as "Debian doesn't need parallel
> > starts!" Because I'd like to make it for myself, regardless what Debian
> > needs.
> > 
> > Anyways, mandated inclusion of lines such as DESC, NAME, etc in the
> > scripts would help me...
> 
> Am I the only one who sees the disconnect between these two statements?

No. I think he's tripping.

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


signature.asc
Description: Digital signature

Re: Timeout of ITP's

[Andrew Suffield]

On Thu, Sep 25, 2003 at 08:38:53PM +0200, S?ren Boll Overgaard wrote:
> So, my question is, how long should an ITP be allowed to just sit there
> before someone else (in this case myself or anyone else who would be
> interested) can go ahead and "hijack" it?

As a general rule, until you run out of patience.

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


signature.asc
Description: Digital signature

Re: Timeout of ITP's

[Adam McKenna]

On Thu, Sep 25, 2003 at 08:38:53PM +0200, Søren Boll Overgaard wrote:
> Hi,
> 
> An ITP[1] on thunderbird[2] was originally submitted to the BTA back in
> June. Since then, for various reasons, no package has been uploaded, and
> someone other then the original submitter of the ITP has committed to
> uploading a package. However, nothing has happened for nearly a month
> now, and the ping I sent just over a week ago has gone unanswered.
> 
> So, my question is, how long should an ITP be allowed to just sit there
> before someone else (in this case myself or anyone else who would be
> interested) can go ahead and "hijack" it? I couldn't seem to find any
> relevant information regarding this in the developers reference, the
> policy manual or on google.

Thunderbird is too important a package for us not to be distributing.  I
think a month is more than generous.

--Adam

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

Re: [PATCH] 2.2 kernel bug in utimes() and its results (m4 FTBFS, coreutils breakage, etc.)

[Herbert Xu]

[EMAIL PROTECTED] wrote:
> 
>1) Source of the bug: in 2.2 (and 2.4 prior to 2.4.19-rc2) sys_utimes()
> lacks a test on times==NULL branch.  It should have the same behaviour as
> sys_utime() - if we ask to set timestamps to present (second argument of
> syscall is NULL), caller must either have write permissions to file or
> be its owner.  In 2.2 the second part is missing.

I'll include your patch in my 2.2 tree.

But there probably won't be another 2.2 upload to unstable for Debian as
I'm trying to get it removed.

Cheers,
-- 
Debian GNU/Linux 3.0 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: Bug#212525: Package contains non-free GNU FDL material

[Branden Robinson]

On Fri, Sep 26, 2003 at 10:31:59AM -0700, Brian Nelson wrote:
> Branden Robinson <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Sep 24, 2003 at 02:40:07PM -0500, Manoj Srivastava wrote:
> >>I did. I feel my packages are not buggy, lacking a position
> >>  statement by the project.
> >
> > So, what we ship in main shall not be a function of whether the works in
> > it are DFSG-free or not, but shall instead depend on whether or not the
> > Debian Project has passed a General Resolution specifically withdrawing
> > them.
> 
> If the software has been in Debian since the beginning and has always
> had non-free political texts (AIUI, this is true of GNU/Emacs and
> probably other various older GNU software), I think that's a reasonable
> stance.

Even if a legitimate position, that's not a complete solution to the
problem.  The FSF has been relicensing GNU Manuals that were previously
under DFSG-free terms under the GNU FDL, and adding Invariant Sections
to manuals that previously had none.

This fact has been documented several times on the debian-legal mailing
list.  Examples include the GAWK Manual, the GDB Manual, the GNU Make
Manual, the Texinfo Manual.

-- 
G. Branden Robinson| I suspect Linus wrote that in a
Debian GNU/Linux   | complicated way only to be able to
[EMAIL PROTECTED] | have that comment in there.
http://people.debian.org/~branden/ | -- Lars Wirzenius


signature.asc
Description: Digital signature

Re: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]

[Andreas Metzler]

Brian White <[EMAIL PROTECTED]> wrote:
[...]
> I've avoided changing to OpenSSH at home because I'm unsure how to
> convert the keys from the SSH2 format to the OpenSSH format.
[...]

Afaict ssh-keygen from OpenSSH can do that:
-i  This option will read an unencrypted private (or public) key file
in SSH2-compatible format and print an OpenSSH compatible private
(or public) key to stdout.  ssh-keygen also reads the `SECSH
Public Key File Format'.  This option allows importing keys from
several commercial SSH implementations.

"unencrypted" probably refers to "empty passphrase".
   cu andreas

Re: Debian should not modify the kernels!

[Andreas Metzler]

martin f krafft <[EMAIL PROTECTED]> wrote:
> This thread has been going on for a while, and I think the general
> voice has been that security backports and other vital patches are
> totally alright for kernel-source. However, I think the general
> agreement is that feature backports are not okay. That's what
> kernel-patches are for.

> I would like to hear an official statement by Herbert on this. We
> should not let this thread extend to infinity, but come to
> conclusions and implement them in time for the Sarge release.

What I'd really like to hear is a reaction from Herbert to:
Osamu Aoki <[EMAIL PROTECTED]> in <[EMAIL PROTECTED]>
| Can your patch file to be more modular like X package?  It is a big
| chunk.

Which could make both sides happy. Instead of one big patch containing
bugfixes, security fixes and feature additions to make them separately
available in the kernel-source-package.
cu andreas

Re: Debian should not modify the kernels!

[George Danchev]

On Thursday 25 September 2003 01:44, Matthew Garrett wrote:
> martin f krafft wrote:
> >also sprach Matthew Garrett <[EMAIL PROTECTED]>
> > [2003.09.22.1=
> >
> >320 +0200]:
> >> It would be inappropriate to do it within a stable release, sure,
> >> but it is something that Debian do do in general. In this case
> >> it's a chunk of code that has almost nothing to do with the core
> >> kernel code - it just so happens that in the pathological case of
> >> a kernel patch, there's some awkwardness. That's an indication
> >> that our kernel patching system should be rationalised, not that
> >> shipping modified kernels is wrong.
> >
> >First, you should not compare kernel packages to the rest of the
> >Debian system. Second, read again what you wrote. Are you kidding
> >me?
>
> 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... Then users will be informed that as of 
2.4.22 these are conflicting patches and will use just one of them on their 
demand. Do you really know how many kernel-patches as debian packages are 
broken because of they expext to patch the vanilla 2.4.22 tree. Then if those 
maintainers try to adjust those unapplyable kernel patches to apply to ipsec 
patched debian's  kernel tree they will rather introduce new (even security) 
bugs than fix the situation. I personally won't trust such sources. The fair 
solutions IMHO is to have a clear target to apply external feature patches.

> >"it's a chunk of code that has almost nothing to do with the core
> >kernel code"

I just plain do not trust such explanations about the kernel subsystems. 
One bit could be crucial ! But this is not the real issue here, the real one 
is that this is just not fair to break other people's work in the name of  
testing purposes covered by baseless explanations.

> In that it can be inserted without modifying behaviour of things that
> other parts of the kernel or userland depend upon.
>
> >You don't consider the IP stack to be core? Are you a Windows user?
>
> I'm a Windows user when I'm paid to be, yes. Have you stopped beating
> your wife yet?

Then do not come with laughts like 'my toy is better that yours, so your does 
not  deserve to exist' ... This is not a real resolution of that issue.

-- 
pub  4096R/0E4BD0AB 2003-03-18 
1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
  
   

Re: Debian should not modify the kernels!

[Benoit Mortier]

Le Mardi 23 Septembre 2003 18:21, Steve Greenland a écrit :
> On 22-Sep-03, 14:14 (CDT), Florian Weimer <[EMAIL PROTECTED]> wrote:
> > It's a well accepted fact among kernel developers that vanilla
> > kernel.org kernels should not be used by end users.  Debian has to
> > patch the kernel, too.  There isn't much choice.
>
> Agreed, but there's a significant difference between including bug fixes
> and de-facto required architecture-specific updates and including a
> completely new subsystem backported from 2.5 yet calling it 2.4. For
> $DIETY's sake, we keep ALSA as a separate patch/module, why is putting
> in IPSEC justified?

i agree with that what i like most in debian is the kernel-patch- 
system, i regulary build freeswan, mppe enabled kernel and the 2.422 i am 
testing now give me loots of problems.

i surely will prefer a separate kernel-patch-ipsec package an if not 
possible  at least two patch files in the kernel 2.4.22 package, one with 
all the classical bits like bigmem etc.. and one other with the ipsec patch 
so we can desactive this one if needed.

thanks
-- 
OpenSides sprl
Free Software Specialist
Benoit Mortier - Linux Engineer


pgp91zlXP9x15.pgp
Description: signature

Re: Timeout of ITP's

[Søren Boll Overgaard]

lør, 2003-09-27 kl. 03:29 skrev Glenn Maynard:
> On Thu, Sep 25, 2003 at 08:38:53PM +0200, Søren Boll Overgaard wrote:
> > An ITP[1] on thunderbird[2] was originally submitted to the BTA back in
> 
> Your footnotes are dangling.

My apologies:
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196504
[2] http://www.mozilla.org/projects/thunderbird/

-- 
Søren O.,''`.
   : :' :
GPG Public key: finger boll  db.debian.org `. `'
GPG signed mail preferred.   `-

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

[Richard Atterer]

Hi,

I've fixed a critical bug in w3c-libwww and now want to regenerate all the 
libtool/autoconf/automake files. Not trivial!

The usual libtoolize/aclocal-1.4/autoheader2.13 etc works under testing,
but I get build errors there, so I suspect I should try the latest versions
in unstable. (The build error, incidentally, is that libtool wants to
access files named "foo/.libs/.libs/bar", when "foo/.libs/bar" would appear
to be correct.)

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

Hrm :-/ So next I tried to convert the configure.in to work with newer
versions of automake. I checked the quoting of strings containing commas,
replaced all AM_ macro calls except for AM_INIT_AUTOMAKE/AM_CONFIG_HEADER,
ran autoupdate and cleaned up the mess it made of the configure.in.

Now I've got a configure.in for which autoheader2.50 *still* gives me the
infamous "undefined macro: _m4_divert_diversion" error, even though I've 
followed the respective hints in the autoconf info pages.

I've uploaded the file to  - could 
some autoconf-knowledgeable person please have a look at getting it to work 
with the w3c-libwww sources, or give me some hints what I need to fix?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Timeout of ITP's

[Søren Boll Overgaard]

lør, 2003-09-27 kl. 07:14 skrev Anthony Towns:
[...]
> Consider ITP's as advisory locks. If you're interested in maintaining
> a package then it's useful information on how to avoid work (email the guy,
> get whatever he's done so far), or a useful advisory of who might be worth
> cooperating with (do the work yourself, upload it, email the guy and offer
> to pass along maintainership when he's ready, or co-maintain it if he's
> interested).
> 
> In either case, if you don't get responses, just maintain it yourself. If
> you get responses later - even months later - be appreciative of the help.

That's good advice. 
I will get to work on the package ASAP.

-- 
Søren O.,''`.
   : :' :
GPG Public key: finger boll  db.debian.org `. `'
GPG signed mail preferred.   `-

Re: Debian should not modify the kernels!

[Matthew Garrett]

George Danchev wrote:
>Do you really know how many kernel-patches as debian packages are 
>broken because of they expext to patch the vanilla 2.4.22 tree.

That's the crux of the matter. The current situation is broken because
it makes it difficult to add extra patches to the kernel-source package
without removing the entirity of the Debian patch, not because the
kernel-source package isn't vanilla. There is no good reason for the
grsec patch to require a vanilla kernel tree, merely one that is
slightly less patched than the current Debian one. The right way to deal
with this is to be able to trivially patch and unpatch the kernel source
as required during building.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: How to include symlinks to conffiles in a package?

[Marc Haber]

On Thu, 25 Sep 2003 23:23:20 +1000, Anthony Towns
 wrote:
>For symlinks? I doubt it. There are two things to worry about: one is
>where the symlink points, and the other is what it's called. sysvinit's
>symlinks don't generally change where they point, but do change what
>they're called (S30 -> K20 eg). I don't think renames like that are
>something you can reasonably handle in a conffile-esque manner.

Bad.

I will probably ship a conffile that will be used as source to
generate symlinks, and prominently document that changes to the
symlinks will be overwritten.

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: [cjwatson@debian.org: Re: Fwd: Processing of ferret_3.0-2_i386.changes]

[Brian White]

> Brian White <[EMAIL PROTECTED]> wrote:
> [...]
> > I've avoided changing to OpenSSH at home because I'm unsure how to
> > convert the keys from the SSH2 format to the OpenSSH format.
> [...]
> 
> Afaict ssh-keygen from OpenSSH can do that:
> -i  This option will read an unencrypted private (or public) key file
> in SSH2-compatible format and print an OpenSSH compatible private
> (or public) key to stdout.  ssh-keygen also reads the `SECSH
> Public Key File Format'.  This option allows importing keys from
> several commercial SSH implementations.
> 
> "unencrypted" probably refers to "empty passphrase".
>cu andreas

Thanks for the tip!  I figured it was probably available somewhere; I just
hadn't had a chance to really go looking.

There's still the problem of why the anonymous-ftp upload cannot find my
GPG key even though it's in the debian keyring.

  Brian
  ( [EMAIL PROTECTED] )

---
That which we persist in doing becomes easier.  It's not that the nature
  of the thing has changed but rather our ability at it has increased.

Re: [debian-i18n] i18n of man-db improved; please test

[Junichi Uekawa]

Hi,

> >  >> Another bug I noticed is that in the ru_RU.UTF-8 locale, man won't
> >  >> find the man pages under ru_RU.KOI8-R.
> >  >Hm. Yes, that is a bug (although not a regression; I think man-db
> >  >2.4.1 behaved the same way). I wonder how to solve that correctly
> >  >and generally.
> > 
> > Why not require UTF-8 man pages? Maybe dh_installwhatever could recode
> > them on the fly when the package is built.
> 
> I think that's an extremely bad idea until groff supports them.

Some kind of file, a table like : 
/usr/share/po-debconf/encodings

would be useful, perhaps.


regards,
junichi

Re: [debian-i18n] i18n of man-db improved; please test

[Colin Watson]

On Sat, Sep 27, 2003 at 08:53:22PM +0900, Junichi Uekawa wrote:
> Some kind of file, a table like : 
>   /usr/share/po-debconf/encodings
> 
> would be useful, perhaps.

That seems like a good idea, thanks. I'll think about it for 2.4.3.

-- 
Colin Watson  [EMAIL PROTECTED]

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

[Martin Quinson]

On Sat, Sep 27, 2003 at 12:23:54PM +0200, Richard Atterer wrote:
> Hi,
> 
> I've fixed a critical bug in w3c-libwww and now want to regenerate all the 
> libtool/autoconf/automake files. Not trivial!

[...]
 
> I've uploaded the file to  - could 
> some autoconf-knowledgeable person please have a look at getting it to work 
> with the w3c-libwww sources, or give me some hints what I need to fix?

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


First, remove acconfig.h from the archive. It triggers a warning in
autoheader and is unneeded. (also remove the occurence of its name in
Makefile.am) Do not erase it, but move it away. You'll need it afterward.

Then, rename configure.in to configure.ac to make clear to the autotool that
you are planing to use autoconf 2.50.


And most of your problems comes from the fact that the acinclude.m4 (ie, the
local definitions) contains macros of the same name than ones distributed by
default in modern autoconf versions.
Get rid of the definition of AC_C_VOLATILE and AC_HEADER_TIOCGWINSZ in
acinclude.m4 Those macros are not used in the w3c-libwww source code
(according to grep), and serve only to mess autoconf up.


Then, there is a bazillon of warnings in autoheader about "missing
templates". It does complain about AC_DEFINE without third argument (giving
the meaning of the define for comments in the www-config.h header). Get
those comments from the acconfig.h file and put them as third argument where
needed. If there is no second argument do:
AC_DEFINE(HAVE_READDIR_R_3,,[Define to use the three-argument variant of 
readdir_r])
I would say it is safer to put the comment between square braces like that.


Then automake-1.7 complains that way:
Library/src/Makefile.am:53: CPPFLAGS' is a user variable, you should not
override it;
Library/src/Makefile.am:53: use AM_CPPFLAGS' instead.

He is right. Defining CPPFLAGS from an Makefile.am is a Bad Thing (TM). Just
rename the variable the way it tells you, it will take care of adding this
to the right variable automatically.


And the configure runs. I guess it means that your issues are solved. It was
mainly the dupplicate definition of macros. autotools are always bitches
about error messages. That's why I like them so much ;)

If you need more help, please make available a tarball solving the bunch of
warning trigered by autotools.


HTH, Mt.

-- 
The unavoidable price of reliability is simplicity.
--Hoare



pgpr0RyEbCvj9.pgp
Description: PGP signature

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

[Jonathan Oxer]

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

* Package name: turck-mmcache
  Version : 2.4.0
  Upstream Author : TurckSoft <[EMAIL PROTECTED]>
* URL : http://turck-mmcache.sourceforge.net/
* License : GPL
  Description : Precompiler and cache to improve performance of PHP scripts

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.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux firewall2 2.4.22 #4 SMP Wed Sep 24 21:20:57 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C

欢迎免费索取在线激情电影网会员密码

[sms]

在线激情电影网地址: http://io.2hu.org

Bug#213025: ITP: animals-game -- Simple animals guessing game

[Tobias Toedter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

* Package name: animals-game
  Version : 0.7.0
  Upstream Author : Tobias Toedter <[EMAIL PROTECTED]>
* URL : http://www.bupp.de/debian
* License : Artistic
  Description : Simple animals guessing game

This is a trivial guessing game, intended for small children. You can think 
of an animal and the computer will try to guess which animal you were 
thinking of. The longer you play, the more animals are known to the 
computer.

The main feature is the support of different languages, since children 
won't be able to read and write English text. These are the languages 
currently supported: English and German.

So much for the long description, here are a few explanations why I want to 
include it in Debian:

The main reason why I wrote this little script is that there is a game 
called "animals" in Debian, which has RC bugs and isn't cared for. 
Moreover, it is a relatively large (considering the purpose) C-Project, and 
this script consists of some lines of perl code. The virtual package 
"junior-games-text" is still depending on animals. It could now replace 
that dependancy with this package.

Last but not least, this program is prepared for i18n - a crucial feature 
for the intended audience, IMHO.

- -- 

Tobias

"I never forget a face, but in your case I'll be glad
to make an exception."
  -- Groucho Marx
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ddGXCqqEJ0Fs8twRAuGpAJ40bTvrYOk/pw9eUXSGKgBvrAGVTACffcu5
vzPNyvg97rXrK/iIpZY67xs=
=sRGA
-END PGP SIGNATURE-

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

[Branden Robinson]

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

-- 
G. Branden Robinson|The first thing the communists do
Debian GNU/Linux   |when they take over a country is to
[EMAIL PROTECTED] |outlaw cockfighting.
http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks


signature.asc
Description: Digital signature

Re: Bug#192101: We need gnucash in stable

[Matthias Urlichs]

Hi, Steve Langasek wrote:

> What you are overlooking is that the main bug causing build failures for
> gnucash is NOT architecture specific; rather, the potential for a build
> failure appears to exist on all architectures, but the use of a
> *pseudo*-RNG for generating test data tends to result in certain corner
> cases being reliably hit in some build environments, and reliably missed
> in others.

... or not. In fact, the bug says quite clearly that the test currently
passes on x86 _only_ because it does 200 iterations of , and
increasing that number makes it fail on iteration 244.  :-(

Interestingly (also stated in bug 192101), it seems to work on RedHat. 

So there's definitely something wrong there, and playing with
Architecture: will _not_ be helpful for anybody.

I agree that gnucash is important. I use it myself. ;-)  However, if it's
that important then there's two more months to hunt down that bug...

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Classified material is considered lost when it cannot be found.

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

[Richard Atterer]

On Sat, Sep 27, 2003 at 02:45:20PM +0200, Martin Quinson wrote:
> [lots of useful stuff]

Many thanks indeed - that resolved all the problems! (But it took me a
while to track down the additional old-style AC_DEFINEs in acinclude.m4,
they also caused problems.)

Unfortunately it turns out that the libtool in unstable still accesses
"foo/.libs/.libs/bar" instead of "foo/.libs/bar". But I've kludged around
this by setting up a symlink ".libs -> ." in the respective .libs
directory, and that seems to work. Unless someone knows a better solution,
I'll upload the package like that...

Thanks again for your help!

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Bug#192101: We need gnucash in stable

[Steve Langasek]

On Sat, Sep 27, 2003 at 08:56:54PM +0200, Matthias Urlichs wrote:
> Hi, Steve Langasek wrote:

> > What you are overlooking is that the main bug causing build failures for
> > gnucash is NOT architecture specific; rather, the potential for a build
> > failure appears to exist on all architectures, but the use of a
> > *pseudo*-RNG for generating test data tends to result in certain corner
> > cases being reliably hit in some build environments, and reliably missed
> > in others.

> ... or not. In fact, the bug says quite clearly that the test currently
> passes on x86 _only_ because it does 200 iterations of , and
> increasing that number makes it fail on iteration 244.  :-(

> Interestingly (also stated in bug 192101), it seems to work on RedHat. 

Quite so.  Red Hat is a build environment where 'make check' succeeds,
though the bug is latent.  Debian i386 is a build environment where
'make check' succeeds, though the bug is latent.  On other Debian
architectures, the bug causes a build failure, due to differences in the
output of the PRNG.  Eliminating the randomness, it's probably possible
to construct valid test input that fails on all platforms, Red Hat
included.  So either the test itself is wrong for allowing these input
values, or there's a bug in gnucash.

Note that at any point, this bug could be effectively downgraded by
removing the call to 'make check' from debian/rules, if it was decided
that the impact of this bug on the program's viability is not
significant.  That's a decision for the maintainer to make, however;
it's certainly justified to be wary of *any* failures where financial
software is concerned.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Debian should not modify the kernels!

[Herbert Xu]

Andreas Metzler <[EMAIL PROTECTED]> wrote:
> martin f krafft <[EMAIL PROTECTED]> wrote:
>> This thread has been going on for a while, and I think the general
>> voice has been that security backports and other vital patches are
>> totally alright for kernel-source. However, I think the general
>> agreement is that feature backports are not okay. That's what
>> kernel-patches are for.

That has not been my impression at all.

As I have said before, kernel-source's primary purpose is for building
default Debian kernel images.  Thus it should contain all the patches
necessary so that the images are uniform across architectures.

Having said that, I do understand that users will use it for building
custom images.  But the presence of kernel-patch-debian fixes that
situation.  You can easily obtain a vanilla kernel that you can apply
patches too.

Now for those who want to get rid of just the ipsec patch, that can
be done as well.  Just download it from the URL specified in the README
file and unapply it.

If someone wants to make a kernel-patch package out of it, go right
ahead.

> What I'd really like to hear is a reaction from Herbert to:
> Osamu Aoki <[EMAIL PROTECTED]> in <[EMAIL PROTECTED]>
> | Can your patch file to be more modular like X package?  It is a big
> | chunk.
> 
> Which could make both sides happy. Instead of one big patch containing
> bugfixes, security fixes and feature additions to make them separately
> available in the kernel-source-package.

Again this is something that I have already stated my position on.
This is simply unmaintainable due to the complex relationships between
patches.

In any case, the kernel-source package's README file should contain all
the information you need to extract any particular patch that you're
interested in.
-- 
Debian GNU/Linux 3.0 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

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

[Julien Delange]

Package: wnpp
Severity: wishlist

* Package name: astats
  Version : 1.5.0
  Upstream Author : Stephane COLIN <[EMAIL PROTECTED]>
* URL : http://bigbob.chez.tiscali.fr/
* License : GPL
  Description : Stats for aMule


aStats is the successor of the well known xStats Statistics
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).

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux evira 2.6.0-test5 #7 SMP Sat Sep 27 19:27:12 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Re: Debian RC System/Init Scripts

[Arthur de Jong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> I'm curious if there has ever been any attempt to Policyize scripts
> located in init.d. Specifically requiring inclusion of such lines as
> DESC="description" or NAME="name". I ask because I am doing a little bit
> of work on the rc startup script.

I know there is some work in lsb. See this for details:
http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/initscrcomconv.html
But debian policy does not require these last time I checked.

- -- arthur - [EMAIL PROTECTED] - http://tiefighter.et.tudelft.nl/~arthur --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)

iD8DBQE/dhNNVYan35+NCKcRApraAKDpFqWY0FBihVX+LRlr5aEqNFXWAgCferxg
asu6komiQXQ+uaPtpK6cHoE=
=zn4p
-END PGP SIGNATURE-

Norton AntiVirus failed to scan an attachment in a message you sent.

[10AntiVirus]

Recipient of the attachment:  SEXCHANGE, RADIANT\RII, StellaHsieh(謝立欣)/收件匣
Subject of the message:  Re: That movie
No action was taken on the attachment.
  Attachment document_9446.pif was Logged Only for the following reasons:
Scan Engine Failure (0x80004005)

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

[Herbert Xu]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> 
>I am closing the bug again. You can, or course, call for the
> tech ctte to override this, or a GR, or get me removed from the
> project, as you wish.

I fully support your position on this.

When a law makes the majority of the population guilty of a crime,
one should not obey it without careful deliberation.
-- 
Debian GNU/Linux 3.0 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: Bug#212525: Package contains non-free GNU FDL material

[Branden Robinson]

On Sun, Sep 28, 2003 at 09:15:13AM +1000, Herbert Xu wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> > 
> >I am closing the bug again. You can, or course, call for the
> > tech ctte to override this, or a GR, or get me removed from the
> > project, as you wish.
> 
> I fully support your position on this.
> 
> When a law makes the majority of the population guilty of a crime,
> one should not obey it without careful deliberation.

...except the majority of the Debian Developer population isn't "guilty"
of shipping non-DFSG-free, GNU FDL-licensed materials in packages in
main.

-- 
G. Branden Robinson|I have a truly elegant proof of the
Debian GNU/Linux   |above, but it is too long to fit
[EMAIL PROTECTED] |into this .signature file.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Debian should not modify the kernels!

[Greg Folkert]

On Sat, 2003-09-27 at 18:12, Herbert Xu wrote:
> Andreas Metzler <[EMAIL PROTECTED]> wrote:
> > martin f krafft <[EMAIL PROTECTED]> wrote:
> >> This thread has been going on for a while, and I think the general
> >> voice has been that security backports and other vital patches are
> >> totally alright for kernel-source. However, I think the general
> >> agreement is that feature backports are not okay. That's what
> >> kernel-patches are for.
> 
> That has not been my impression at all.
> 
> As I have said before, kernel-source's primary purpose is for building
> default Debian kernel images.  Thus it should contain all the patches
> necessary so that the images are uniform across architectures.

So  which of the 11 platforms _REQUIRE_ the IPSEC backport? If any, what
is the rational that they *REQUIRE* that piece. 

> Having said that, I do understand that users will use it for building
> custom images.  But the presence of kernel-patch-debian fixes that
> situation.  You can easily obtain a vanilla kernel that you can apply
> patches too.
> 
> Now for those who want to get rid of just the ipsec patch, that can
> be done as well.  Just download it from the URL specified in the README
> file and unapply it.
> 
> 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.

> > What I'd really like to hear is a reaction from Herbert to:
> > Osamu Aoki <[EMAIL PROTECTED]> in <[EMAIL PROTECTED]>
> > | Can your patch file to be more modular like X package?  It is a big
> > | chunk.
> > 
> > Which could make both sides happy. Instead of one big patch containing
> > bugfixes, security fixes and feature additions to make them separately
> > available in the kernel-source-package.
> 
> Again this is something that I have already stated my position on.
> This is simply unmaintainable due to the complex relationships between
> patches.
> 
> In any case, the kernel-source package's README file should contain all
> the information you need to extract any particular patch that you're
> interested in.

But exactly why should this particular patch (IPSEC backport) cause so
much grief for the patch system, if it were to be so standard?
-- 
greg, [EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry

Your eyes glow like naked livers burning in the sun.


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

Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)

[Matt Zimmerman]

On Fri, Sep 26, 2003 at 08:08:39AM +1000, Herbert Xu wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > 
> > I ran it through diffstat, and removed the files which are created entirely 
> > by
> > the patch, so these are the changes to common code:
> 
> I've had a look and it appears to be acceptable.  Please file a bug
> report against kernel and I'll probably include it when 2.4.23 is
> released.

Done.  On a related note, there is some talk about device-mapper being
included in a later 2.4.x kernel, but nothing concrete.

-- 
 - mdz

Re: Debian should not modify the kernels!

[Herbert Xu]

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 the current maintainer of kernel-source, I decide which patches
are included per default.  The individual architecture maintainers
can choose to override my decisions through architecture patches.

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.

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

Cheers,
-- 
Debian GNU/Linux 3.0 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: Debian should not modify the kernels!

[viro]

On Sun, Sep 28, 2003 at 01:10:27PM +1000, Herbert Xu wrote:
> 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.

That has more to do with the fact that grsecurity is an intrusive pile of
garbage, splashed pretty much all over the tree (which, incidentally, is
a large part of reasons why it is unfit for upstream kernel).

For crying out loud, it's a half-megabyte monolitic patch.  Even devfs
was slightly smaller when it had finally dripped into the tree.  If
somebody wants to play with it - they'll have to either
a) split the damn thing into series of localized chunks and enjoy
relatively easy resolution of conflicts with other patches or
b) wear "I'm a sadomasochist and proud of it" T-shirt and leave
everybody else alone.

Look, it's that simple - authors of patch had chosen to be antisocial and
kept it a monolit; that makes it a second-class citizen as far as merges
are concerned.  Less intrusive patches get precedence.  End of story.

Re: Bug#192101: We need gnucash in stable

[Iustin Pop]

Hello,

After digging to see why gnucash fails the tests (as I use it daily and
wouldn't like to see it go away...), I found these:

On Sat, Sep 27, 2003 at 04:03:19PM -0500, Steve Langasek wrote:
> Quite so.  Red Hat is a build environment where 'make check' succeeds,
> though the bug is latent.  Debian i386 is a build environment where
> 'make check' succeeds, though the bug is latent.  On other Debian
> architectures, the bug causes a build failure, due to differences in the
> output of the PRNG.  Eliminating the randomness, it's probably possible
> to construct valid test input that fails on all platforms, Red Hat
> included.  So either the test itself is wrong for allowing these input
> values, or there's a bug in gnucash.
Playing with the random generator has shown this to be true. Introducing
additional calls to it (i.e. extracting more values, at random places)
has generated both successfull runs (with 400 tests) and failures after
130 tests.
> 
> Note that at any point, this bug could be effectively downgraded by
> removing the call to 'make check' from debian/rules, if it was decided
> that the impact of this bug on the program's viability is not
> significant.  That's a decision for the maintainer to make, however;
> it's certainly justified to be wary of *any* failures where financial
> software is concerned.
The test that fails is doing the following:
 for N number of times
   create a random query of up to 4 terms, which are (randomly) combined
   using operators from the set QUERY_AND, QUERY_OR, QUERY_NAND,
   QUERY_NOR, QUERY_XOR.
   transform the query to another format and back, and check to see that
   we have the same query.

Now the 244 test (in the original setup) that fails has 4 terms combined
such that in the end the query, broken down in its internal form has
more than 5000 sub-terms. Other tests that fail also have an big number
of sub-terms (>4000, etc.). However, there were also queries with 4
terms, but which broken down amounted to a small number of subterms,
that succeeded.

Reducing the maximum number of terms in the test from 4 to 3 has allowed
me to run > 120,000 iterations of the test (at which point I ran out of
memory, the test program was using 400MB).

I'd say that if we are not making searches in gnucash using 4 or more
terms combined strangely, and gnucash itself does not construct such
queries, it *could* be ok - e.g. no data or functionality loss. However,
this is clearly a bug in gnucash - they should either fix the
transformations of queries with big numbers or limit the maximum number
of terms allowed.

Hopefully this info will be of use to someone.

Regards,
Iustin Pop


signature.asc
Description: Digital signature

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

[Daniel Josua Priem]

Hello,
im have debianized www.ltsp.org.
the root-filesystem will now point to /usr/share/ltsp/ and mounted
read-only by the clients
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)

Daniel

Please don't CC me, i read the list



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