Re: Bug#480563: Doesn't strip binary NMU version (+b1, +bN etc.) when reporting bugs

[Sandro Tosi]

On Sat, Jul 19, 2008 at 02:23, Don Armstrong <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Jul 2008, Sandro Tosi wrote:
>> should we strip-off the binNMU extension from the package version in
>> reportbug?
>
> No. The BTS is more than capable of resolving binary versions to
> source versions, and knows far better what the source version of a
> particular binary version than an arbitrary regex in reportbug.

Thanks Don (and others) for this clarification, hence I'm closing this bug.

Kindly,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Re: Call for keys for keysigning in Mar del Plata during DebConf8

[Aníbal Monsalve Salazar]

On Tue, Jul 15, 2008 at 10:09:27PM +1000, Anibal Monsalve Salazar wrote:
>Hello All,
>
>As part of the 9th Debian Conference in Mar del Plata, Argentina, there
>will be OpenPGP (pgp/gpg) keysignings. If you intend to participate in
>the DebConf8 keysignings, please send your ascii armored public key as
>explained at [0] not later than 23:59 UTC on Saturday 26th of July,
>2008.
>
>More (and up-to-date) information is available at [0], so keep watching
>it.
>
>[0] http://people.debian.org/~anibal/ksp-dc8/ksp-dc8.html

We'are about a week away from the deadline, 23:59 UTC on Saturday 26th
of July, 2008.

If you sent your key and is not listed at

http://people.debian.org/~anibal/ksp-dc8/names.html

please resend it.


signature.asc
Description: Digital signature

Clarification about bug #463538 is needed

[Sergei Golovan]

Hi!

Currently APT fails to start all services which are based on Erlang
(see bug #463538, [1]). It starts the service successfully but after
apt-get finishes the service process get killed.

I've found a one-line-patch which fixes this bug (see [2]) but I'm not
sure if it's correct and doesn't break something else.

Could someone review the patch and either apply it to the next APT
version or may be help to fix this in some other way? (It might be an
Erlang fault but I can't find anything wrong in how it detaches from a
controlling terminal.)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463538
[2] 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=tty.diff;att=1;bug=463538

Cheers!
-- 
Sergei Golovan


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Gunnar Wolf]

Guido Günther dijo [Fri, Jul 18, 2008 at 04:34:25PM -0230]:
> On Fri, Jul 11, 2008 at 08:37:01AM +0100, Ian Campbell wrote:
> [..snip..] 
> > dom0 support is being worked on by Fedora people (I think) but there are
> > no patches upstream yet.
> We could recommend kvm+xenner+libvirt as "dom0" for people with
> hardware virtualization support:
>  http://kraxel.fedorapeople.org/xenner/
> I don't think we have this packaged yet though. If anybody wants to work
> on this I'd be happy to help.

Umh... AFAICT, that would only work for people using Xen for
paravirtualization, not for full virtualization. Nowadays, Xen's
administration tools are still way more complete than KVM's - But I
think it is in place to tell people... That KVM is the way.

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


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

Re: Clarification about bug #463538 is needed

[Martijn van Oosterhout]

On Sat, Jul 19, 2008 at 3:21 PM, Sergei Golovan <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Currently APT fails to start all services which are based on Erlang
> (see bug #463538, [1]). It starts the service successfully but after
> apt-get finishes the service process get killed.
>
> I've found a one-line-patch which fixes this bug (see [2]) but I'm not
> sure if it's correct and doesn't break something else.

Umm, if that patch fixes it (removing the TIOCSCTTY) then it seems to
me that the erlang-based service will instead exit when the user who
installed the server logs out. Evidently the services in erlang are
not properly disassociating themselves from the terminal and this
patch just makes it more obvious...

Have a nice day,

>
> Could someone review the patch and either apply it to the next APT
> version or may be help to fix this in some other way? (It might be an
> Erlang fault but I can't find anything wrong in how it detaches from a
> controlling terminal.)
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463538
> [2] 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=tty.diff;att=1;bug=463538
>
> Cheers!
> --
> Sergei Golovan
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>



-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


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

Re: Clarification about bug #463538 is needed

[Sergei Golovan]

On 7/19/08, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
>
> Umm, if that patch fixes it (removing the TIOCSCTTY) then it seems to
>  me that the erlang-based service will instead exit when the user who
>  installed the server logs out. Evidently the services in erlang are
>  not properly disassociating themselves from the terminal and this
>  patch just makes it more obvious...

Erlang does exactly the following when detaches from a terminal:

 if (start_detached) {
   int status = fork();
   if (status != 0)
 return 0;
   status = fork();
   if (status != 0)
 return 0;

   close(0);
   open("/dev/null", O_RDONLY);
   close(1);
   open("/dev/null", O_WRONLY);
   close(2);
   open("/dev/null", O_WRONLY);
 }
 {
   execv(emu, Eargsp); /* executing the main Erlang emulator */
 }

Is this behavior incorrect?

-- 
Sergei Golovan


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

Re: Clarification about bug #463538 is needed

[Stephen Gran]

This one time, at band camp, Sergei Golovan said:
> On 7/19/08, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> >
> > Umm, if that patch fixes it (removing the TIOCSCTTY) then it seems to
> >  me that the erlang-based service will instead exit when the user who
> >  installed the server logs out. Evidently the services in erlang are
> >  not properly disassociating themselves from the terminal and this
> >  patch just makes it more obvious...
> 
> Erlang does exactly the following when detaches from a terminal:
> 
>  if (start_detached) {
>int status = fork();
>if (status != 0)
>  return 0;
>status = fork();
>if (status != 0)
>  return 0;
> 
>close(0);
>open("/dev/null", O_RDONLY);
>close(1);
>open("/dev/null", O_WRONLY);
>close(2);
>open("/dev/null", O_WRONLY);
>  }
>  {
>execv(emu, Eargsp); /* executing the main Erlang emulator */
>  }
> 
> Is this behavior incorrect?

I don't see setsid?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Clarification about bug #463538 is needed

[Mike Hommey]

On Sat, Jul 19, 2008 at 09:28:03PM +0400, Sergei Golovan wrote:
> On 7/19/08, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> >
> > Umm, if that patch fixes it (removing the TIOCSCTTY) then it seems to
> >  me that the erlang-based service will instead exit when the user who
> >  installed the server logs out. Evidently the services in erlang are
> >  not properly disassociating themselves from the terminal and this
> >  patch just makes it more obvious...
> 
> Erlang does exactly the following when detaches from a terminal:
> 
>  if (start_detached) {
>int status = fork();
>if (status != 0)
>  return 0;
>status = fork();
>if (status != 0)
>  return 0;
> 
>close(0);
>open("/dev/null", O_RDONLY);
>close(1);
>open("/dev/null", O_WRONLY);
>close(2);
>open("/dev/null", O_WRONLY);
>  }
>  {
>execv(emu, Eargsp); /* executing the main Erlang emulator */
>  }
> 
> Is this behavior incorrect?

It should also open /dev/tty and ioctl(fd, TIOCNOTTY, 0) on it.

Mike


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

Re: Clarification about bug #463538 is needed

[Vincent Bernat]

OoO  Pendant le repas  du samedi  19 juillet  2008, vers  19:28, "Sergei
Golovan" <[EMAIL PROTECTED]> disait :

> Erlang does exactly the following when detaches from a terminal:

>  if (start_detached) {
>int status = fork();
>if (status != 0)
>  return 0;
>status = fork();
>if (status != 0)
>  return 0;

>close(0);
>open("/dev/null", O_RDONLY);
>close(1);
>open("/dev/null", O_WRONLY);
>close(2);
>open("/dev/null", O_WRONLY);
>  }
>  {
>execv(emu, Eargsp); /* executing the main Erlang emulator */
>  }

> Is this behavior incorrect?

This can  be replaced  by a call  to daemon()  that just does  the right
thing. For example, it misses chdir() and setsid().
-- 
BOFH excuse #372:
Forced to support NT servers; sysadmins quit.


pgp8VNyq2lOzP.pgp
Description: PGP signature

Re: Clarification about bug #463538 is needed

[Russ Allbery]

"Sergei Golovan" <[EMAIL PROTECTED]> writes:

> Erlang does exactly the following when detaches from a terminal:
>
>  if (start_detached) {
>int status = fork();
>if (status != 0)
>  return 0;
>status = fork();
>if (status != 0)
>  return 0;
>
>close(0);
>open("/dev/null", O_RDONLY);
>close(1);
>open("/dev/null", O_WRONLY);
>close(2);
>open("/dev/null", O_WRONLY);
>  }
>  {
>execv(emu, Eargsp); /* executing the main Erlang emulator */
>  }
>
> Is this behavior incorrect?

It's missing either setsid or ioctl("/dev/tty", TIOCNOTTY).  The
semi-standard daemon() function does the right thing.  Here's a public
domain replacement (which assumes you have an Autoconf probe for whether
setsid is available).  It depends on a wrapper around standard system
headers, but I expect you get the idea and could fix that.

/* $Id: daemon.c 4022 2008-03-31 06:11:07Z rra $
 *
 * Replacement for a missing daemon.
 *
 * Provides the same functionality as the library function daemon for those
 * systems that don't have it.
 *
 * Written by Russ Allbery <[EMAIL PROTECTED]>
 * This work is hereby placed in the public domain by its author.
 */

#include 
#include 

#include 
#include 
#include 
#include 

int
daemon(int nochdir, int noclose)
{
int status, fd;

/*
 * Fork and exit in the parent to disassociate from the current process
 * group and become the leader of a new process group.
 */
status = fork();
if (status < 0)
return -1;
else if (status > 0)
_exit(0);

/*
 * setsid() should take care of disassociating from the controlling
 * terminal, and FreeBSD at least doesn't like TIOCNOTTY if you don't
 * already have a controlling terminal.  So only use the older TIOCNOTTY
 * method if setsid() isn't available.
 */
#if HAVE_SETSID
if (setsid() < 0)
return -1;
#elif defined(TIOCNOTTY)
fd = open("/dev/tty", O_RDWR);
if (fd >= 0) {
if (ioctl(fd, TIOCNOTTY, NULL) < 0) {
status = errno;
close(fd);
errno = status;
return -1;
}
close(fd);
}
#endif /* defined(TIOCNOTTY) */

if (!nochdir && chdir("/") < 0)
return -1;

if (!noclose) {
fd = open("/dev/null", O_RDWR, 0);
if (fd < 0)
return -1;
else {
if (dup2(fd, STDIN_FILENO) < 0)
return -1;
if (dup2(fd, STDOUT_FILENO) < 0)
return -1;
if (dup2(fd, STDERR_FILENO) < 0)
return -1;
if (fd > 2)
close(fd);
}
}
return 0;
}

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: [Pkg-xen-devel] Xen status in lenny?

[LM Jogbäck]

On Wed, Jul 16, 2008 at 2:54 AM, Ben Hutchings <[EMAIL PROTECTED]> wrote:

>
> SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> available any day now from
> .  Is it
> possible that those patches will be usable in lenny, as I believe the
> kernel team expects to release with Linux 2.6.26?
>

Is the forward-ported Xen patch for 2.6.26 available somewhere, so
that an unofficial build of a dom0 2.6.26 for debian could be build?

/LM


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Ben Hutchings]

On Sat, Jul 19, 2008 at 09:15:09PM +0200, LM Jogbäck wrote:
> On Wed, Jul 16, 2008 at 2:54 AM, Ben Hutchings <[EMAIL PROTECTED]> wrote:
> 
> >
> > SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> > available any day now from
> > .  Is it
> > possible that those patches will be usable in lenny, as I believe the
> > kernel team expects to release with Linux 2.6.26?
> >
> 
> Is the forward-ported Xen patch for 2.6.26 available somewhere, so
> that an unofficial build of a dom0 2.6.26 for debian could be build?

Not yet.  Keep watching that directory.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp


signature.asc
Description: Digital signature

Downgrading Bug#474736 to important

[Rodrigo Gallardo]

Eric Cooper <[EMAIL PROTECTED]>
> When I click on this feed: http://www.borowitzreport.com/, the first
> item is (currently) the following.  Liferea pops up a browser window
> for the embedded URL in the  whenever I try to display
> headlines -- I'm not even trying to read the body of the item.
>
> The fact that the link points to a site in Changzhou, China, and the
> strange nesting of the end tag --  -- makes me think
> this feed was hijacked, so liferea's behavior is a security hole.

As I stated in the original bug report, I don't quite agree with the
security hole characterization of this bug, as it is essentially
imposible for liferea to detect a hijacked feed.

This bug is currently the only reason for liferea not to be in lenny.
Since upstream has stated that the 1.4 series will *not* be updated to
deal with this issue, and I lack the time for now to attempt a backport,
this means a fix for this will not be ready before the freeze.

Would I be justified in downgrading this to important?


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

Re: esound [was: Re: Non-related 'Recommends' dependencies - bug or not?]

[Jason D. Clinton]

On Tue, Jun 17, 2008 at 9:21 AM, Loïc Minier <[EMAIL PROTECTED]> wrote:

> On Tue, Jun 17, 2008, Martin Pitt wrote:
> > That's interesting indeed! So you avoid that by using an OSS driver
> > instead of the ALSA one? I can really not imagine how esound on top of
> > a broken ALSA driver would sound better than just using the ALSA
> > output directly?
>
>  It might normalize which sampling rate / sample width is used


Hi,

Pardon me for resurrecting this slightly old thread but there's been an
important development. Jeffrey Stedfast has resolved the esd deadlocking
issues when used with PulseAudio. Among other things, this solves the Pidgin
and Flash crashing problems (both of whom consume esd output while Pulse is
running with -compat).

http://jeffreystedfast.blogspot.com/2008/07/pulseaudio-i-told-you-so.html

It appears that he also made a correct release by merging our downstream
changes to libesd that were rotting in Gnome's Bugzilla.

Loïc, you offered to NMU this package here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422590

This vastly improves the Gnome sound situation. Hope we can get this in for
Lenny.

Re: Clarification about bug #463538 is needed

[Brian May]

Sergei Golovan wrote:

   int status = fork();
   if (status != 0)
 return 0;
   status = fork();
   if (status != 0)
 return 0;
  
Apart from what everyone else has said, I can't help put being slightly 
puzzled that it calls fork two times. This just seems weird...


Or did I miss something?

Brian May


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

Re: Clarification about bug #463538 is needed

[The Fungi]

On Sun, Jul 20, 2008 at 09:14:48AM +1000, Brian May wrote:
> Apart from what everyone else has said, I can't help put being slightly
> puzzled that it calls fork two times. This just seems weird...
>
> Or did I miss something?

See chapter 13 from "Advanced Programming in the UNIX Environment"
(ISBN 0201563177):

"Under System V–based systems, some people recommend calling fork
again at this point and having the parent terminate. The second
child continues as the daemon. This guarantees that the daemon is
not a session leader, which prevents it from acquiring a controlling
terminal under the System V rules (Section 9.6). Alternatively, to
avoid acquiring a controlling terminal, be sure to specify O_NOCTTY
whenever opening a terminal device."
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


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

FHS and /var/www

[Carl Fürstenberg]

FHS 2.3 specifies in
http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
to use /srv for "Data for services provided by this system", for
example /srv/www for web root.
In the policy, the section
9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
specifies that FHS 2.3 is mandatory, except for some exception, and
the use of /var/www isn't included in that list.

Should we force all httpd:s to use /srv/www instead of /var/www, or
should an exception to the policy be added? Per
http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
support for /srv/www, but it's still defaulting to /var/www.

-- 
/Carl Fürstenberg <[EMAIL PROTECTED]>

Re: FHS and /var/www

[Roberto C . Sánchez]

On Sun, Jul 20, 2008 at 01:43:12AM +0200, Carl Fürstenberg wrote:
> FHS 2.3 specifies in
> http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM
> to use /srv for "Data for services provided by this system", for
> example /srv/www for web root.
> In the policy, the section
> 9.1.1(http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.1)
> specifies that FHS 2.3 is mandatory, except for some exception, and
> the use of /var/www isn't included in that list.
> 
> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added? Per
> http://wiki.debian.org/Apache2LennyGoals it states that apache2 has
> support for /srv/www, but it's still defaulting to /var/www.
> 
Personally, I would be against such a change.

On some systems, I NFS mount parts of /srv (or all of it).  Such is not
the case for /var.  That is, people know better than NFS mount /var.
That guarantee does not exist, since by nature /srv should mountable by
NFS (e.g., for a web cluster, or something like that).

Regards,

-Roberto
-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: FHS and /var/www

[Ben Finney]

"Carl Fürstenberg" <[EMAIL PROTECTED]> writes:

> Should we force all httpd:s to use /srv/www instead of /var/www, or
> should an exception to the policy be added?

I think there's no hardship if we support the FHS location, so an
exception shouldn't be made.

What do you mean by "force all [HTTP servers] to use /srv/www instead
of /var/www"? Why do you think that's desirable?

Conformance with the FHS would seem to require only that such files
must be addressible under the '/srv/www' location. I don't see support
for the "instead of /var/www" part of your question.

We could deal with this as we did for '/usr/share/doc' vs '/usr/doc';
that is, make '/srv/www/foo' the canonical location but allow a long
transition period where '/var/www/foo' is permitted as a symlink to
'/srv/www/foo'.

> Per http://wiki.debian.org/Apache2LennyGoals it states that apache2
> has support for /srv/www, but it's still defaulting to /var/www.

This could be dealt with as per above, along with the usual package
maintainer role of negotiating the Debian-specific change into the
upstream package.

-- 
 \   “Always do right. This will gratify some people, and astonish |
  `\the rest.” —Mark Twain |
_o__)  |
Ben Finney


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

Bug#491512: no man page for ulimit command

[Robert A Marder]

Package: general
Severity: serious
Justification: Policy 12.1

The "ulimit" command has no manual page, which violates DP 12.1

Because this command has no binary (an internal command?) i've put 
it as "general" although "base" may be a better psudeopackage.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-vserver-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your 
desktop!
Check it out at http://www.inbox.com/marineaquarium



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

Bug#491512: marked as done (no man page for ulimit command)

[Debian Bug Tracking System]

Your message dated Sun, 20 Jul 2008 10:46:18 +0800
with message-id <[EMAIL PROTECTED]>
and subject line ulimit is documented
has caused the Debian Bug report #491512,
regarding no man page for ulimit command
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)


-- 
491512: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491512
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: general
Severity: serious
Justification: Policy 12.1

The "ulimit" command has no manual page, which violates DP 12.1

Because this command has no binary (an internal command?) i've put 
it as "general" although "base" may be a better psudeopackage.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-vserver-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your 
desktop!
Check it out at http://www.inbox.com/marineaquarium


--- End Message ---
--- Begin Message ---
ulimit should be documented in the manual page for your shell.

For example:

$ man bash
/ulimit
q
$ man dash
/ulimit
q

Please file a wishlist bug on your shell if it doesn't provide
documentation on ulimit. If you are looking for the ulimit function,
install manpages-dev and run this:

$ man 3 ulimit

Please investigate a bit more before filing bugs, or ask on the user
support areas:

irc://irc.debian.org/debian
http://lists.debian.org/debian-user/
http://forums.debian.net/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Clarification about bug #463538 is needed

[Sergei Golovan]

On 7/19/08, Russ Allbery <[EMAIL PROTECTED]> wrote:
> It's missing either setsid or ioctl("/dev/tty", TIOCNOTTY).  The
>  semi-standard daemon() function does the right thing.  Here's a public
>  domain replacement (which assumes you have an Autoconf probe for whether
>  setsid is available).  It depends on a wrapper around standard system
>  headers, but I expect you get the idea and could fix that.

Huge thanks to all of you who took your time to answer! Indeed if I
add a call to setsid() the services become starting and daemonizing
fine. So, it's really a bug in Erlang and I'm going to report it
upstream (together with fixing in current version in unstable and
eventually in testing).

-- 
Sergei Golovan


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

Bug#491113: ITP: eekboek -- Bookkeeping software for small and medium-size businesses

[Joost van Baal]

retitle 491113 ITP: eekboek -- Bookkeeping software for small and medium-size 
businesses
owner 491113 !
thanks

Hi,

Op Wed 16 Jul 2008 om 08:35:18 +0200 schreef Joost van Baal:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: eekboek
>   Version : 1.03.13
>   Upstream Author : Johan Vromans 
> * URL : http://www.eekboek.nl/
> * License : either GPL v1 or later, or Artistic License
>   Programming Lang: Perl
>   Description : Bookkeeping software for small and medium-size businesses
> 
> EekBoek is a bookkeeping package for small and medium-size businesses.
> Unlike other accounting software, EekBoek has both a command-line
> interface (CLI) and a graphical user-interface (GUI).  Furthermore, it
> has a complete Perl API to create your own custom applications.
> 
> EekBoek is designed for the Dutch/European market and currently
> available in Dutch only.

My first attempt at packaging this is available from
http://mdcc.cx/tmp/eekboek/.  Beware!  The packages there are untested;
they are only useful for people interested in helping with packaging.
Don't use them for anything else.

I'll try to get eekboek shipped with Debian lenny+1; currently it should
not enter testing.

I expect to be able to upload the software this month.

Bye,

Joost



signature.asc
Description: Digital signature

Pls help me

[Jithesh Chandran]

My acer aspire 5310 notebook doesn't perform good with the debian os..
The soundcard, the wirelan and the shortcut keys doesn't work..
I need help from you atleast for makin the soundcard work..
May be it will work with the help of some driver.



  Explore your hobbies and interests. Go to 
http://in.promos.yahoo.com/groups/

Re: FHS and /var/www

[Tollef Fog Heen]

]] Ben Finney 

| We could deal with this as we did for '/usr/share/doc' vs '/usr/doc';
| that is, make '/srv/www/foo' the canonical location but allow a long
| transition period where '/var/www/foo' is permitted as a symlink to
| '/srv/www/foo'.

You can't know the structure of /srv, see the FHS rationale:

  The methodology used to name subdirectories of /srv is unspecified
  as there is currently no consensus on how this should be done. One
  method for structuring data under /srv is by protocol, eg. ftp,
  rsync, www, and cvs. On large systems it can be useful to structure
  /srv by administrative context, such as /srv/physics/www,
  /srv/compsci/cvs, etc. This setup will differ from host to
  host. Therefore, no program should rely on a specific subdirectory
  structure of /srv existing or data necessarily being stored in
  /srv. However /srv should always exist on FHS compliant systems and
  should be used as the default location for such data.

As long as the structure is unspecified, it is just about impossible
to me to have a sane default pointing to anywhere in /srv (except
directly at /srv itself) as that directory might very well not exist.
I would argue shipping a /srv/www is a bug if the site does not use
that layout.

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


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