Re: /run and read-only /etc

[Blars Blarson]

In article <[EMAIL PROTECTED]> 
[EMAIL PROTECTED] writes:
>I won't debate whether this is true in general, bug it is certainly
>unnecessary in the case of pump.  I have specifically added code to
>deal with the inability to write to /var/run by making pump fall back
>to using TCP sockets.

It will also need to cope with writing to /var/run on the root
partition, having /var mounted, and later processes not being able to
open the file since the /var/run directory on the root disk is
inaccessable.

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
"Text is a way we cheat time." -- Patrick Nielsen Hayden

Re: /run and read-only /etc

[Herbert Xu]

Blars Blarson <[EMAIL PROTECTED]> wrote:
> 
> It will also need to cope with writing to /var/run on the root
> partition, having /var mounted, and later processes not being able to
> open the file since the /var/run directory on the root disk is
> inaccessable.

It does.  If the Unix-domain socket does not exist pump will use TCP
to detect an existing server.
-- 
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: Upcoming removal of orphaned packages

[Tollef Fog Heen]

* Fumitoshi UKAI 

| At Fri, 11 Apr 2003 13:52:12 -0400 (EDT),
| Joe Nahmias wrote:
| > 
| > Will these packages will still be available through archive.d.o or will
| > they be purged from there as well?
| 
| These packages will be available through http://snapshot.debian.net/,
| as much as I can afford to maintain.

How does the disk space situation look?  I think snapshot.d.n is a so
useful service that Debian should consider using funds for paying for
hard drives for it, assuming the growth isn't «too bad», for some
value of that.

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

Bug#188825: ITP: sonar -- console chat via ICMP (ping) echo-request packets

[Alexander Neumann]

Package: wnpp
Version: unavailable; reported 2003-04-13
Severity: wishlist


* Package name: sonar
  Version : 0.2
  Upstream Author : Philipp Lay <[EMAIL PROTECTED]>
* URL : http://platon.intra-tec.de
* License : BSD
  Description : console chat via ICMP (ping) echo-request packets

 sonar implements a chat using ICMP (ping) echo-request packets, which
 means nearly stealth communication between two hosts ;)



pgpzdq84omsfU.pgp
Description: PGP signature

Re: Work-needing packages report for Apr 11, 2003

[Josselin Mouette]

Le sam 12/04/2003 à 15:34, Andrew Suffield a écrit :

> > phpgroupware
> 
> Again, several alternatives.

Sorry ?

> > pppoeconf
> 
> Yay, another config tool. Just what we need.

Sure. Instead of being able to set up a DSL line in a few seconds, we
should let users handle all those configuration files by themselves.
I suggest we drop networking support from d-i too. People unable to make
a /etc/network/interfaces file don't deserve using Debian.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: PGP signature

LDAP slow (was: Update on alioth)

[Andreas Metzler]

On Sat, Apr 12, 2003 at 10:02:33PM +0200, Wichert Akkerman wrote:
[...]
> * Logging in on quantz (the machine running Alioth) is slow. Very slow.
> 
>   It seems that OpenLDAP as running on quantz is not very fast. We are
>   already using all the useful indices on the LDAP database and using
>   nscd, but especially initial logins will still take a while. At this
>   moment we do not know if we can improve this.

If I had known this a little bit earlier I wouldn't have bothered you
with
http://alioth.debian.org/tracker/index.php?func=detail&aid=300017&group_id=1&atid=21
;-)
   thanks, cu andreas

Re: /run and read-only /etc

[Thomas Hood]

On Sat, 2003-04-12 at 23:56, Herbert Xu wrote:
> >> * Change /sbin/pump to:
> >>   * Store PID in /run, not in /var/run

> I won't debate whether this is true in general, bug it is certainly
> unnecessary in the case of pump.  I have specifically added code to
> deal with the inability to write to /var/run by making pump fall back
> to using TCP sockets.

Unnecessary; but would using /run for the pidfile be a better
(e.g., simpler) solution?

If not then do you think the TCP-socket approach is the way
to deal with every program that writes a pidfile when /var/
may be absent?
-- 
Thomas Hood <[EMAIL PROTECTED]>

Re: /run and read-only /etc

[Thomas Hood]

On Sat, 2003-04-12 at 10:12, Anthony DeRobertis wrote:
> On Wed, 2003-04-09 at 14:17, Thomas Hood wrote:
> >   * ppp
> > * Change /usr/sbin/pppd to:
> >   * Store PID in /run/, not in /var/run/
> Why? Is the goal to make PPP-mounter /var to work?!

I suppose someone might want to mount /var/ across a ppp link.
If we are making the other changes then we might as well make
this one too, unless there is absolutely no point in doing so
(... because it is impossible to mount /var/ across a ppp link
for some reason I am overlooking?).

> If so, pppd has to be moved to /sbin.

Well, /usr/ could be local but /var/ remote.

> > The proposed new directory is for files similar to those in /var/run/
> > that are not just variable and unshareable but also local -- i.e., they
> > must be writable independently of network connectivity.
> 
> No, they must be on the root file system, like /bin and /sbin. Remember
> the root FS can be network mounted, e.g., over NFS.

How about this then:
   The proposed new directory is for files that serve similar
   purposes to those in /var/run and that are not just variable
   and unshareable but also available early enough to be used
   by programs in /sbin and /bin.

-- 
Thomas Hood <[EMAIL PROTECTED]>

Re: Upcoming removal of orphaned packages

[Bernhard R. Link]

* Bernd Eckenfels <[EMAIL PROTECTED]> [030412 15:49]:
> > I guess you thought about http://snapshot.debian.net/ instead of archive? 
> > s.d.n main page explicitely says that removed pkgs will be retained there.
> > So there's no problem recovering the latest version from sid of a package.
> 
> Well, they have to be stored on archive, too. Mainly for GPL licensing
> issues.

Why that? I thought we use 3a and not 3b for distribution thus avoiding
such problems?

Hochachtungsvoll,
  Bernhard R. Link

-- 
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.

Re: Update on alioth

[Joerg Wendland]

Wichert Akkerman, on 2003-04-12, 22:02, you wrote:
> * Logging in on quantz (the machine running Alioth) is slow. Very slow.
> 
>   It seems that OpenLDAP as running on quantz is not very fast. We are
>   already using all the useful indices on the LDAP database and using
>   nscd, but especially initial logins will still take a while. At this
>   moment we do not know if we can improve this.

When debugging an application of mine using OpenLDAP I found out, that
each single ACL makes not queries but return of results significantly
slower. Maybe you want to try to tune these...

HTH, Joerg

-- 
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A  F318 57A3 7FBD 51CF 8417


pgpEBqH0eLLUN.pgp
Description: PGP signature

Re: Update on alioth

[Wichert Akkerman]

Previously Joerg Wendland wrote:
> When debugging an application of mine using OpenLDAP I found out, that
> each single ACL makes not queries but return of results significantly
> slower. Maybe you want to try to tune these...

ACL can make LDAP horribly slow, but we already have a pretty minimal
set. I did change the libnss-ldap configuration a bit yesterday which
seems to have helped a lot. Just doesn't try to benchmark using commands
like id: they grab the complete list of accounts and groups which will
be slow, as well as incomplete since there is a limit on the number of
responses slapd will return.

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>   http://www.wiggy.net/
A random hacker

[desktop] Patched kernels

[Mark Howard]

Hi,
  When the debian-desktop project was started, there was a lot of talk
about creating kernel images patched for improved performance. Most
people agreed that this would be a good idea. Unfortunately no such
packages seem to have been created.
  Is anybody working on this? What problems are stopping the packages
from being created?

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: Work-needing packages report for Apr 11, 2003

[Adrian 'Dagurashibanipal' von Bidder]

On Saturday 12 April 2003 15:34, Andrew Suffield wrote:
> On Fri, Apr 11, 2003 at 10:57:34PM +0200, Lars Bahner wrote:

> > pptp-linux
>
> AIUI, you have to rebuild your kernel with a patch, and the version of
> the patch in the archive doesn't work on recent kernels. So I doubt
> many people will be hugely affected.

FWIW, I use that one without the kernel patch (you only need the kernel patch 
for encription). I sometimes want to access some library websites with 
IP-based authentication (IEEE etc.), so I go through the university (ETHZ) 
net. They offer VPN as unencrypted pptp or as some cisco specific variant of 
IPsec that doesn't work with normal IPsec clients (there is a Linux cisco VPN 
client, but it does some very weird stuff with the network interfaces, so I 
can't use it on my router at home :-(

Not about to offer to take pptp-linux, though - it's not essential for me, and 
I guess as a non-DD, it would be a bit tough to take on as a first package.

cheers
-- vbi

-- 
The prablem with Manoca is thot it's difficult ta tell the difference
between o cauple af the letters.
-- Jacob W. Haller on alt.religion.kibology


pgpsJxrPz89R3.pgp
Description: signature

Re: Fwd: ITP: oscommerce -- Online shop e-commerce solution with PHP/MySQL

[Adrian 'Dagurashibanipal' von Bidder]

On Saturday 12 April 2003 18:57, Bruno David Rodrigues wrote:
> - Mensagem Reenviada de [EMAIL PROTECTED] -

>  With no restrictions or special requirements, osCommerce is able
>  to run on any PHP3 or PHP4 enabled web server, on any environment
>  that PHP and MySQL supports, which includes Linux, Solaris, BSD,
>  and Microsoft Windows environments.

IMHO it doesn't make sense to mention this in the package description.

-- vbi

-- 
featured link: http://fortytwo.ch/gpg/intro


pgpVWcedHwyTt.pgp
Description: signature

Re: Nameserver-pushing mechanism

[Thomas Hood]

On Sat, 2003-04-12 at 02:34, Jeremie Koenig wrote:
> Sounds quite good. But I have a suggestion about going one step further:
> include the whole thing into ifupdown.
[...]

In the following, where you write '/etc/resolv-update.d' I guess you
meant to say '/etc/network/resolv-update.d' since /etc/network is
where ifupdown stores its configuration files.

> Underlying programs to configure interfaces (dhcpcd, pppd, ...) would
> put their resolv.conf data in /run/network/resolv.d/. They
> have no need to call any script to do the update, ifupdown manages it
> itself.
> [...]

To change my suggestion into yours:
* Move files from /run/resolver/interfaces/ to /run/network/resolv.d/
* Move files from /etc/resolver/update.d to /etc/network/resolv-update.d
* Make the latter scripts get their resolv.conf data from stdin
  instead of from the /run/network/resolv.d/* files
* Rename "/etc/init.d/resolver reload" to "push-resolvers"
* Make ifupdown call push-resolvers instead of using a script in
  /etc/network/if-up.d.

The only significant difference is that you would put everything in
the ifupdown package.  Why do that?

> We will also need that ifupdown waits until ppp/dhcp has finished before
> exiting. This has to be done someday, anyway. /run makes it possible,
> since we can create, for instance, a /run/network/pid.ppp0 file to be
> killed -HUP from /etc/ppp/ip(up|down).d/0ifupdown.

I don't understand this.  Why do you want ifupdown not to exit
until while ppp or dhclient are running?

if(up|down) wasn't designed to run as a daemon.

Cheers
-- 
Thomas Hood <[EMAIL PROTECTED]>

Re: Work-needing packages report for Apr 11, 2003

[Michael Banck]

On Sun, Apr 13, 2003 at 03:16:00PM +0200, Adrian 'Dagurashibanipal' von Bidder 
wrote:
> Not about to offer to take pptp-linux, though - it's not essential for me, 
> and 
> I guess as a non-DD, it would be a bit tough to take on as a first package.

If you change your mind and need a sponsor, let me know.

Michael

/usr/{share/man,bin} vs /usr/X11R6/{man,bin} (policy 12.8.7)

[Marcin Owsiany]

Hi!

There is a package I adopted (bugsx), which uses Imake. However the
previous maintainer didn't use upstream makefile install{,.man} targets
(which put the binary and manpage in /usr/X11R6/{man,bin}), and instead
installed them manually into /usr/{share/man,bin}.

My question is: how to interpret policy section 12.8.7. Is to mean:

 "All packages using imake should puth files where imake-generated
 makefile would put them, period."

or

 "Everything should go to /usr/{bin,share/man}, but if your package uses
 imake, you're allowed to be lazy and leave it the old way".

regards,

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216

Porting lpr from OpenBSD to Debian - any tips?

[Kalle Kivimaa]

I'm trying to port the latest lpr release from OpenBSD to Debian (the
package has been orphaned and I'm trying to take it over) and the
process is not entirely straightforward. Are there any tips (common
pitfalls etc) for porting applications from *BSD to Linux?

-- 
* Kettering's Law: Logic is an organized way of going wrong   *
* with confidence.*
*   PGP public key available @ http://www.iki.fi/killer   *

Re: /usr/{share/man,bin} vs /usr/X11R6/{man,bin} (policy 12.8.7)

[John H. Robinson, IV]

Marcin Owsiany wrote:
> 
> My question is: how to interpret policy section 12.8.7. Is to mean:
> 
>  "All packages using imake should puth files where imake-generated
>  makefile would put them, period."
> 
> or
> 
>  "Everything should go to /usr/{bin,share/man}, but if your package uses
>  imake, you're allowed to be lazy and leave it the old way".

quoting §12.8.7:

The `/usr/X11R6/' directory hierarchy should be regarded as
deprecated for all packages except the X Window System itself, and
those which use the `imake' program it provides, in which case the
packages may transition out of the `/usr/X11R6/' directory at the
maintainer's discretion.[1]

i beleive that is pretty clear: since bugsx uses imake, you may leave it
as is. if you want to put it into /usr, you may also do that. it is up
to you.

all the footnote says is that imake Does The Right Thing, which is why
it is exempted.

-john

Re: Nameserver-pushing mechanism

[Jeremie Koenig]

On Sun, Apr 13, 2003 at 03:54:58PM +0200, Thomas Hood wrote:
> In the following, where you write '/etc/resolv-update.d' I guess you
> meant to say '/etc/network/resolv-update.d' since /etc/network is
> where ifupdown stores its configuration files.

Sure.

> > Underlying programs to configure interfaces (dhcpcd, pppd, ...) would
> > put their resolv.conf data in /run/network/resolv.d/. They
> > have no need to call any script to do the update, ifupdown manages it
> > itself.
> > [...]
> 
> To change my suggestion into yours:

My suggestion was meant to improve your proposal (on the few points that
still didn't fully convinced me), not to replace it.

> * Move files from /run/resolver/interfaces/ to /run/network/resolv.d/
> * Move files from /etc/resolver/update.d to /etc/network/resolv-update.d
> * Make the latter scripts get their resolv.conf data from stdin
>   instead of from the /run/network/resolv.d/* files

This is important. It must be possible to control which nameservers go
to which recipient script. For instance bind mustn't be fed with
himself, but must be fed to others.

> * Rename "/etc/init.d/resolver reload" to "push-resolvers"

And make its usage more exceptional.

> * Make ifupdown call push-resolvers instead of using a script in
>   /etc/network/if-up.d.
>
> The only significant difference is that you would put everything in
> the ifupdown package.

Quite true. But IMHO ifupdown is a better place than glibc. And the idea
was not just putting everything into the ifupdown package, but
integrating it to the ifupdown mechanism.

> Why do that?

Bringing one interface up makes some nameservers available. In a way,
these nameservers belong to the interface. Making the set of available
nameservers managed by ifupdown is a logical consequence of this.

Your proposal adresses the following problem : the list of nameservers
is no more static, and resolv.conf is no more fitting. On the other
hand, ifupdown handles mixing static and dynamic configuration of
interfaces quite gracefully. Extending ifupdown to integrate the changes
you are proposing seems appropriate.

Having the nameserver list as a part of each interface's configuration
may be useful/handy/logical.


> > We will also need that ifupdown waits until ppp/dhcp has finished before
> > exiting. This has to be done someday, anyway. /run makes it possible,
> > since we can create, for instance, a /run/network/pid.ppp0 file to be
> > killed -HUP from /etc/ppp/ip(up|down).d/0ifupdown.
> 
> I don't understand this.  Why do you want ifupdown not to exit
> until while ppp or dhclient are running?
> 
> if(up|down) wasn't designed to run as a daemon.

Sorry, I was unclear. I meant that ifup should wait until the interface
is effectively brought up before exiting. In the case of ppp (I don't
know about dhcp), ifupdown just launches pppd, then exit.

Ifup should wait for success (SIGHUP) or failure (pppd dies). This way
it can know the status of the interface better, and full configuration
or failure to configure is made when ifup exits.


I hope i've been a bit more clear.

-- 
Jeremie Koenig <[EMAIL PROTECTED]>

Re: Bug#188665: RC issue

[Manoj Srivastava]

clone 188665 -1 -2 
reassign -1 binutils
reassign -2 openoffice.org
reassign 188665 xfree86-common
thanks
Hi,

[Since flex is standard, perhaps this migration issue needs
 wider audience, hence the CC to debian-devel]

The behaviour of flex has changed in the latest release, yes. 
 This is part of the gcc migration process; flex has been updated (the
 buggy, rickety set of patches required to make it work with gcc was
 dumped in favour of a well engineered upstream migration). Please
 look at the upstream Changelog for details. 

Flex has also grown an extensive test suite, and there is a
 test for each of the features reported below. I strongly think that
 these changes, which require changes in source, and not a bug, are
 causing the vast majority of failures. 

 As you may see, flex scanners have become reentrant, the c++ versions
 are compatible with recent c++ compilers (conform to ANSI C++, gcc
 3.2), supports bison variables yylval and yylloc. Some variables have
 been renamed. Flex generates C99 defs now; see
 YY_TRADITIONAL_FUNC_DEFS yylineno is present in all
 scanners. yylineno is per-buffer in reentrant scanners. flex tries
 its best to output only the relevant portions of the skeleton when
 generating a scanner, thus avoiding as much conditional compilation
 as possible

The signature of all functions has changed. flex has new
 command line options, and option parsing has changed (now also
 supports POSIX conventions optionally). Handles POSIXLY_CORRECT
 environment variable.  Various i18n translations are included in the
 distribution. flex now works with recent bison versions

I understand that this requires all packages using lex to
 massage their lexers to conform to the new behaviour of flex; but the
 gains in reduced complexity of the scanner and reentrancy and
 standards compliance are well worth it. 

manoj
-- 
Everybody is going somewhere!!  It's probably a garage sale or a
disaster Movie!!
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#188665: RC issue

[Sean 'Shaleh' Perry]

>   I understand that this requires all packages using lex to
>  massage their lexers to conform to the new behaviour of flex; but the
>  gains in reduced complexity of the scanner and reentrancy and
>  standards compliance are well worth it.
>

and like the gcc 3.2 change over, the upstreams will eventually have to make 
this change as well so Debian can help out and make this task easier for 
them.

However, are these new lexer files backwards compatible?  I would have a hard 
time getting an upstream to accept a patch that would prevent their source 
from building anyhere but the new flex.

Bug#188885: ITP: kxl -- a multimedia library for game development

[Sam Hocevar]

Package: wnpp
Version: unavailable; reported 2003-04-13
Severity: wishlist

* Package name: kxl
  Version : 1.1.7
  Upstream Author : Katsuyoshi Sato <[EMAIL PROTECTED]>
* URL : http://kxl.hn.org/kxl1xx.php
* License : LGPL
  Description : a multimedia library for game development

 KXL (Kacchan X Windows System Library) is a library targeted at game
 development that provides functions for simple image and sound output
 as well as higher level functions for text drawing, timer and events
 handling and image manipulation.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux c18 2.5.53 #1 Fri Jan 3 19:04:02 CET 2003 i686
Locale: LANG=C, LC_CTYPE=fr_FR

Re: Bug#188665: RC issue

[Jarno Elonen]

I'm now getting a redefinition error and couldn't easily figure it out:

In file included from conf_analysis_yy.h:5,
 from conf_analysis.yy:7:
/usr/include/FlexLexer.h:112: redefinition of `class yyFlexLexer'
/usr/include/FlexLexer.h:112: previous definition of `class yyFlexLexer'

Is there a more detailed explanation/tutorial on what has changed and how to 
update packages using Flex?

- Jarno

Re: Update on alioth

[Donald J Bindner]

On Sun, Apr 13, 2003 at 02:27:10PM +0200, Wichert Akkerman wrote:
> Previously Joerg Wendland wrote:
> > When debugging an application of mine using OpenLDAP I found out, that
> > each single ACL makes not queries but return of results significantly
> > slower. Maybe you want to try to tune these...
> 
> ACL can make LDAP horribly slow, but we already have a pretty minimal
> set. I did change the libnss-ldap configuration a bit yesterday which
> seems to have helped a lot. Just doesn't try to benchmark using commands
> like id: they grab the complete list of accounts and groups which will
> be slow, as well as incomplete since there is a limit on the number of
> responses slapd will return.
> 
> Wichert.

Not to add extra work for you, but others might find it
illuminating to have your LDAP experience written up in some
detail (before you forget all the things you learned).

I am planning on redo-ing an LDAP setup this summer, and I have
found case studies of others' experiences very enlightening while
I plan for it.  My scale is small, but even the case studies of
very large directories have been very useful.

Don

-- 
Don Bindner <[EMAIL PROTECTED]>

Re: Nameserver-pushing mechanism

[Thomas Hood]

On Sun, 2003-04-13 at 19:25, Jeremie Koenig wrote:
>> * Make the latter scripts get their resolv.conf data from stdin
>>   instead of from the /run/network/resolv.d/* files
>
> This is important. It must be possible to control which nameservers go
> to which recipient script. For instance bind mustn't be fed with
> himself, but must be fed to others.

In my proposal, "/etc/init.d/resolver reload" generates
/run/resolv.conf, so this isn't an problem.

Sending the resolv.conf data through a pipe makes it only
slightly (if at all) easier to write the update script, and it
elides information (viz., the interface with which the nameserver
is associated) for which the script could have some use.

> [...] the idea
> was not just putting everything into the ifupdown package, but
> integrating it to the ifupdown mechanism.

Yes, it is a good idea to integrate resolver updating
closely with ifupdown.  I am not sure it is appropriate
to use ifupdown directories, though, as if we were
extending ifupdown proper.  The resolver is not part of
ifupdown.

> Having the nameserver list as a part of each interface's configuration
> may be useful/handy/logical.

I think this part of your proposal can be regarded as a wish
for ifupdown to be extended so that one can specify nameservers
for each logical interface.  Listed nameservers would be added
through the resolver update mechanism that we will be providing.
Good idea for the future; I've added it to the TODO list.

> Sorry, I was unclear. I meant that ifup should wait until the interface
> is effectively brought up before exiting. In the case of ppp (I don't
> know about dhcp), ifupdown just launches pppd, then exit.

OK, comprendo.

> Ifup should wait for success (SIGHUP) or failure (pppd dies). This way
> it can know the status of the interface better, and full configuration
> or failure to configure is made when ifup exits.

Yes, ifupdown should handle interface-up failures better than
it does.  There are several bug reports open about this already,
e.g., #82339 and those merged with it.

And yes, in order to check for ppp's success ifup would have to
wait for some signal from ppp.  You might want to file a wish
for this, including your SIGHUP idea or a patch if you have one.
Perhaps a wish should be filed against ppp too, because the 
basic problem is that pon doesn't wait to see if the interface
comes up successfully.

In any case, this functionality is absent from the present
ppp and ifupdown and may continue to be absent for a long time.
Therefore, we have to make the resolver update stuff work with
ifupdown in its present form.  That means adding scripts to the
/etc/ppp/ip-(up|down).d/ and /etc/network/if-(up|down).d/ dirs.

If ifupdown is enhanced so that (as mentioned above) it
* waits to see if pppd succeeds, and
* handles nameserver addition on ifup, deletion on ifdown,
then the scripts can be eliminated.

-- 
Thomas Hood <[EMAIL PROTECTED]>

Re: Debian for x86-64 (AMD Opteron)

[Colin Walters]

On Sat, 2003-04-12 at 02:02, Eduard Bloch wrote:
> #include 
> * Drew Scott Daniels [Thu, Apr 10 2003, 02:11:36PM]:
> > I don't quite understand all the concepts being discussed but the
> > following web pages may be worth reading.
> > http://master.debian.org/~brinkmd/arch-handling.txt
> 
> The idea is great and I came to very similar concept looking for a
> solution for various dynamic dependency problems. However I think that
> too many methods are hardcoded in Debian's packagement system 

I am hoping build-common will help solve that. 

Re: Debian for x86-64 (AMD Opteron)

[Darren Salt]

I demand that José Luis Tallón may or may not have written...

[snip]
> Sorry, i must me missing something obvious, but why would we need lib64foo
> ? Why not just define the new architecture x86-64 and have katie/buildd do
> the rest?
[snip]
> Anything to do with the ability to mix-and-match 32 and 64-bit code in this
> processors?

If this is fairly easy, would it be better to compile 64-bit code and
generate 32-bit wrappers?

This would ideally be automated via libtool: if the install path is $FOO/lib,
put the wrappers there and the libraries in $FOO/lib64, first ensuring that
it exists. Also, for debian/*.files, an implicit
  sed -re '%^lib/[^/]*.so[^/]*$% { p; s%^lib/([^/]*.so[^/]*)$%lib64/\1%; }
   %/lib/[^/]*.so[^/]*$% { p; s%/lib/([^/]*.so[^/]*)$%/lib64/\1%; }'
would help.

It could be that I'm missing something here, but ISTM that that would get
things up and running without any need to modify (m)any packages.

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

4 food groups: fast, frozen, microwaved, and junk.

Bug#188890: ITP: geki3 -- a horizontal shoot'em-up

[Sam Hocevar]

Package: wnpp
Version: unavailable; reported 2003-04-13
Severity: wishlist

* Package name: geki3
  Version : 1.0.3
  Upstream Author : Katsuyoshi Sato <[EMAIL PROTECTED]>
* URL : http://kxl.hn.org/games.php
* License : GPL
  Description : a horizontal shoot'em-up

 Geki 3 is a horizontal shoot'em-up game similar to classic arcade games
 such as R-Type or Zero "All Your Base Are Belong To Us" Wing. It features
 four levels and various weapons.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux c18 2.5.53 #1 Fri Jan 3 19:04:02 CET 2003 i686
Locale: LANG=C, LC_CTYPE=fr_FR

Re: [desktop] Patched kernels

[Colin Walters]

On Sun, 2003-04-13 at 08:52, Mark Howard wrote:
> Hi,
>   When the debian-desktop project was started, there was a lot of talk
> about creating kernel images patched for improved performance. Most
> people agreed that this would be a good idea. Unfortunately no such
> packages seem to have been created.
>   Is anybody working on this? What problems are stopping the packages
> from being created?

Anthony Towns has mentioned a few times that he thinks sarge will use
Linux 2.6, which comes with most of the goodies like preemption already
included.  We'll probably just need a separate kernel-image-preempt
package or something that debian desktop can have installed by default.
 

Bug#188891: ITP: grande -- a vertical shoot'em-up

[Sam Hocevar]

Package: wnpp
Version: unavailable; reported 2003-04-13
Severity: wishlist

* Package name: grande
  Version : 0.6
  Upstream Author : Katsuyoshi Sato <[EMAIL PROTECTED]>
* URL : http://kxl.hn.org/games.php
* License : GPL
  Description : a vertical shoot'em-up

 Grande is a vertical shoot'em-up game similar to classic arcade games such
 as Xenon, Target Renegade or Gunhed. It features four levels and five types
 of special weapons.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux c18 2.5.53 #1 Fri Jan 3 19:04:02 CET 2003 i686
Locale: LANG=C, LC_CTYPE=fr_FR

Bug#188892: ITP: geki2 -- a vertical shoot'em-up

[Sam Hocevar]

Package: wnpp
Version: unavailable; reported 2003-04-13
Severity: wishlist

* Package name: geki2
  Version : 2.0.3
  Upstream Author : Katsuyoshi Sato <[EMAIL PROTECTED]>
* URL : http://kxl.hn.org/games.php
* License : GPL
  Description : a vertical shoot'em-up

 Geki 2 is a vertical shoot'em-up game similar to classic arcade games such
 as Xenon, Target Renegade or Gunhed. It features 6 levels and 2 different
 weapons.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux c18 2.5.53 #1 Fri Jan 3 19:04:02 CET 2003 i686
Locale: LANG=C, LC_CTYPE=fr_FR

Re: [devel] Re: Fwd: ITP: oscommerce -- Online shop e-commerce solution with PHP/MySQL

[Bruno David Rodrigues]

Citando Adrian 'Dagurashibanipal' von Bidder <[EMAIL PROTECTED]>:

> On Saturday 12 April 2003 18:57, Bruno David Rodrigues wrote:
> > - Mensagem Reenviada de [EMAIL PROTECTED] -
> 
> >  With no restrictions or special requirements, osCommerce is able
> >  to run on any PHP3 or PHP4 enabled web server, on any environment
> >  that PHP and MySQL supports, which includes Linux, Solaris, BSD,
> >  and Microsoft Windows environments.
> 
> IMHO it doesn't make sense to mention this in the package description.

Thanks for your help, I'll remove it

-- 

 21:55:38 up 141 days, 22:08,  2 users,  load average: 0.23, 0.13, 0.10
BOFH excuse #205:
Quantum dynamics are affecting the transistors

Re: [desktop] Patched kernels

[Tollef Fog Heen]

* Colin Walters 

| Anthony Towns has mentioned a few times that he thinks sarge will use
| Linux 2.6, which comes with most of the goodies like preemption already
| included.  We'll probably just need a separate kernel-image-preempt
| package or something that debian desktop can have installed by default.

Nobody has even begun thinking about getting d-i to work with 2.5/2.6.
Until that is tested and works this won't fly at all.  (Yes, this is a
«somebody, please step forward and test/fix d-i with 2.5/2.6»)

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

Re: Work-needing packages report for Apr 11, 2003

[Matijs van Zuijlen]

On Sat, Apr 12, 2003 at 02:34:32PM +0100, Andrew Suffield wrote:
> On Fri, Apr 11, 2003 at 10:57:34PM +0200, Lars Bahner wrote:
> > pptp-linux
> 
> AIUI, you have to rebuild your kernel with a patch, and the version of
> the patch in the archive doesn't work on recent kernels. So I doubt
> many people will be hugely affected.

No patching of the kernel is needed to use this package. The bug
referring to kernel-patch-mppe (#180538) only mentions suggesting or
recommending the patch.

Additionally, pptp-linux seems to be the only/preferred/recommended? way
to use ADSL on Linux in the Netherlands (which is where I live). See
also http://www.maniac.nl/adsl.html.

IANADD, but since the only outstanding bugs are wishlist items, I would
be happy to take this package.

-- 
Matijs van Zuijlen

... designed to fill holes or cracks of not more than two cubic vims.
-- Robert Sheckley, Untouched by Human Hands


pgpUs7l94aMPf.pgp
Description: PGP signature

Why is only the latest unstable package considered for testing?

[Björn Stenberg]

Hi.

(I first submitted this question to debian-testing, but was referred here for 
discussion.)

I have been looking at the "excuses" page[0] and was struck by how very old 
some packages are in testing, yet only the very latest bleeding edge version 
from unstable appears to be considered for inclusion.

Am I misunderstanding something, or does this approach "punish" projects that 
adhere to the Open Source motto to release often?

Hypothetical example:

Project X makes an effort to prepare a solid release, squashing all RC bugs and 
making sure each target builds flawlessly. They pack it up, label it "3.0" or 
whatever and release it. The package goes into unstable and, being a 
non-critical update, needs 10 days to become a "Valid Candidate"[1] for testing.

For a while, people have been working on a big patch to move project X from 
gnome to gnome2. This was submitted to the project but was delayed until after 
3.0. Now that 3.0 is out the door and the users have a stable version to work 
with, the gnome2 patch goes in and a new version, 3.1, is released only a few 
days later. This version is not a valid testing candidate, since gnome2 is not 
yet included in testing, but it's a welcome update for those running 
gnome2/unstable.

Now the catch: Since the testing scripts only consider the latest unstable 
version, the testing-ready 3.0 version is never considered. Instead, the 3.1 
version is rejected (due to depending on gnome2) and the old 2.0 version is 
kept.

Is there a good reason for this? Would it not be better to track all versions 
of a package and include the latest (if any) that fulfills all requirements? It 
seems to me that the current system leaves testing with older versions than 
necessary.

Note that I'm not advocating relaxing the inclusion criteria for testing. I am 
just asking why they are not applied equally to all versions.

[0] http://ftp-master.debian.org/testing/update_excuses.html
[1] http://www.debian.org/devel/testing

-- 
Björn

Bug#188914: ITP: phpscribe -- a documentation generator for PHP applications

[Rafael de Oliveira Jannone]

Package: wnpp
Version: unavailable; reported 2003-04-13
Severity: wishlist


* Package name: phpscribe
  Version : 0.5.0
  Upstream Author : Marcos Pont <[EMAIL PROTECTED]>
* URL : http://phpscribe.sourceforge.net
* License : GPL
  Description : a documentation generator for PHP applications

phpScribe is a documentation generator written in PHP with mySQL support
to parse the comment lines of the source codes of a project, in order to
generate on-line HTML-based documentation files. Currently, the target
languages are PHP and Javascript. The user can customize the "skin" of
the documentation.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux shinobu 2.4.20-686 #1 Mon Jan 13 22:22:30 EST 2003 i686
Locale: LANG=pt_BR, LC_CTYPE=pt_BR

Re: /run and read-only /etc

[Herbert Xu]

Thomas Hood <[EMAIL PROTECTED]> wrote:
> 
> Unnecessary; but would using /run for the pidfile be a better
> (e.g., simpler) solution?
> 
> If not then do you think the TCP-socket approach is the way
> to deal with every program that writes a pidfile when /var/
> may be absent?

Pump doesn't write pid files.  It uses a Unix-domain socket to
communicate with its previous incarnation, and failing that, a
TCP socket.
-- 
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: [desktop] Patched kernels

[David Nusinow]

On Sun, Apr 13, 2003 at 11:11:27PM +0200, Tollef Fog Heen wrote:
> * Colin Walters 
> 
> | Anthony Towns has mentioned a few times that he thinks sarge will use
> | Linux 2.6, which comes with most of the goodies like preemption already
> | included.  We'll probably just need a separate kernel-image-preempt
> | package or something that debian desktop can have installed by default.
> 
> Nobody has even begun thinking about getting d-i to work with 2.5/2.6.
> Until that is tested and works this won't fly at all.  (Yes, this is a
> ?somebody, please step forward and test/fix d-i with 2.5/2.6?)

How much is broken with 2.5 right now? Could someone who's familiar
with the issues give an approximation as to how much work it would take
to adapt d-i to 2.5?

In addition, why does d-i have to run 2.6 at all? Couldn't it run 2.4,
and install a 2.6 kernel for normal use for those that want it?

 - David

A donde vas en Semana Santa ?

[Camping Tours]

Title: Que haras en Semana Santa ?



 

  
  



  


  
  


  
Este 
mensaje no puede ser considerada SPAM mientras incluya la forma
de 
ser removido. Para ser removido de la lista y no recibir
futuros 
emails simplemente envíe un mensaje en blanco a [EMAIL PROTECTED]. 


  
Publicacion:
.ephekto™ | soluciones 
publicitarias

  

Re: Why is only the latest unstable package considered for testing?

[Bob Proulx]

Bj?rn Stenberg wrote:
> 
> (I first submitted this question to debian-testing, but was referred here for 
> discussion.)

[If you would be so kind as to word wrap your messages before you send
them it would make reading and replying to them much easier.]

Well, actually I was hoping you would search the debian-devel archives
first and then bring up _new_ points as you saw fit.  I did not expect
you to post your original question again verbatim.  You did have at
least two answers to your original question already.

Why is only the latest unstable package considered for testing?
  
http://lists.debian.org/debian-testing/2003/debian-testing-200304/msg00028.html

Since I helped stir the pot I will at least do some homework.  Just
minor searching through the archive turned these up with relevent
discussion.  These are all in the very recent history and not even
back very far.  I am sure I could find some choice gems if I looked
into prior years.  Before anyone posts a follow up at the very least
the following threads of discussion on this list should be mandatory
reading.

Subject: why is it not moving to testing
  http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg01277.html
Subject: Some myths regarding apt pinning
  http://lists.debian.org/debian-devel/2003/debian-devel-200301/msg01644.html
Subject: Freeze Please?
  http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00317.html
Subject: testing, unstable, and dependencies
  http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg00302.html

Bob


pgpvrjx8vcuwF.pgp
Description: PGP signature

W3C recommendations

[Thomas Bliesener]

Almost the whole Debian website meets the HTML standards except some
online documentation which seems to be a problem of debiandoc2html
(#188117).

In a quick survey I found more packages which generate code which
doesn't pass the check on http://validator.w3.org:

gallery
latex2hmtl
netsaint
squid
squirrelmail
texi2html
twiki
usemod-wiki
viewcvs

or whose HTML documentation isn't valid according to the validator:

cvsbook
gnupg-doc
icewm-common
imagemagick
impress
mozilla-browser
mrtg
mysql-doc
netsaint
sambadoc
xfree86-common

or which consist in invalid HTML:

lg-base
lg-issue*

Do you consider the recommendations of the W3 Consortium as binding or
optional for the Debian project? Shall I file a bug report against these
packages (and probably others)?
-- 
bli

Re: [desktop] Patched kernels

[Russell Coker]

On Mon, 14 Apr 2003 09:39, David Nusinow wrote:
> How much is broken with 2.5 right now? Could someone who's familiar
> with the issues give an approximation as to how much work it would take
> to adapt d-i to 2.5?

2.5 has a replacement set of utilities for loading kernel modules.  The 
installer would need to handle this (not difficult though).

2.5 apparently has a replacement for initrd which may require some changes.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

x86-64 tool chain works

[Arnd Bergmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've found the bug in bochs that was stopping me from testing my
biarch tool chain and all the basic stuff seems to work fine now.
Anyone interested in an x86-64 debian port can now experiment
with the packages I have uploaded to http://www.arndb.de/debian/.

Just like on s390 and sparc, you should be able to install the 
biarch tool chain on a 32 bit machine without breaking native 
compiles. So far, I could test 64 bit binaries only in bochs,
but I don't expect them to break on a real hammer if anyone
has one.

There is a lot that can be done before the hardware is available,
so if there is enough interest, we should start a coordinated
effort soon.

Arnd <><
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+mbMN5t5GS2LDRf4RAhNFAJ0VcyP4y1guSas4OEQxIVO6bSzZfQCeLbNs
GJyVZRahODuk1H4kg4+dchU=
=0GVN
-END PGP SIGNATURE-

Re: [desktop] Patched kernels

[Herbert Xu]

Russell Coker <[EMAIL PROTECTED]> wrote:
> 
> 2.5 apparently has a replacement for initrd which may require some changes.

initramfs is currently 100% backwards compatible.  So no changes
are needed for initrd users.
-- 
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