Re: FHS and /var/www

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

Pls help me

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 inte

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

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

Re: Clarification about bug #463538 is needed

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 d

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

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

Bug#491512: no man page for ulimit command

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:

Re: FHS and /var/www

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

Re: FHS and /var/www

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

FHS and /var/www

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

Re: Clarification about bug #463538 is needed

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" (ISB

Re: Clarification about bug #463538 is needed

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 someth

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

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

Downgrading Bug#474736 to important

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

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

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

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

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

Re: Clarification about bug #463538 is needed

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

Re: Clarification about bug #463538 is needed

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

Re: Clarification about bug #463538 is needed

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

Re: Clarification about bug #463538 is needed

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 ou

Re: Clarification about bug #463538 is needed

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 disa

Re: Clarification about bug #463538 is needed

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

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

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 p

Clarification about bug #463538 is needed

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 bre

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

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 ke

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

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 f