Marc Haber wrote:
> On Mon, 28 Feb 2011 22:26:56 +0100, Arthur de Jong
> wrote:
>>On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
>>> Personally, I'd rather we didn't have them, as this is supposed to be
>>> controlled by the rcN.d links and if that interface is too hard for
>>> people
Hi,
On Montag, 28. Februar 2011, Jesús M. Navarro wrote:
> But #3. is still a bug and unless it's been at least tried to be reproduced
> is no good behaviour to close it just "because I've not the time and I
> prefer focusing on #1 and #2".
I don't think it's the maintainers duty to prove that bu
Hi,
On 28/02/2011 02:01, Andreas Rottmann wrote:
> Most software allows this without issues -- just run "./configure
> --prefix=$HOME". You need to adjust $PATH and $LD_LIBRARY_PATH inside
> your shell startup scripts, and you're done.
>
> I'd however strongly suggest not adding any additional
On 27/02/2011 16:31, Lucas Nussbaum wrote:
> But then, we have a problem, because:
> - ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo,
> rubinius-foo) installed to work correctly
I find this dependency tedious. If someone installs ruby-foo, how can
he expect it to work if he does no
On 02/27/2011 04:31 PM, Lucas Nussbaum wrote:
> Ideally, we would have binary packages named like that:
> ruby-foo: arch-indep part of the foo library
> ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
> ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1
Here you'
]] "Christian Pohl"
| Isn't update-rc.d the way to configure the rc.d scripts? Or am I
| old-fashioned.
The problem was at least until update-rc.d grew the «disable» argument
that disabling a daemon using update-rc.d was quite hard.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky abo
Tollef Fog Heen writes:
> The problem was at least until update-rc.d grew the «disable» argument
> that disabling a daemon using update-rc.d was quite hard.
update-rc.d foo disable is indeed convenient.
update-rc.d and policy-rc.d are currently two separate interfaces. If I
want to make sure tha
On 01/03/11 at 10:44 +0100, Bernd Zeimetz wrote:
> On 02/27/2011 04:31 PM, Lucas Nussbaum wrote:
> > Ideally, we would have binary packages named like that:
> > ruby-foo: arch-indep part of the foo library
> > ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
> > ruby1.9.1-foo: arch-
* Holger Levsen [110301 09:56]:
> On Montag, 28. Februar 2011, Jesús M. Navarro wrote:
> > But #3. is still a bug and unless it's been at least tried to be reproduced
> > is no good behaviour to close it just "because I've not the time and I
> > prefer focusing on #1 and #2".
>
> I don't think it'
]] Timo Juhani Lindfors
| Tollef Fog Heen writes:
| > The problem was at least until update-rc.d grew the «disable» argument
| > that disabling a daemon using update-rc.d was quite hard.
|
| update-rc.d foo disable is indeed convenient.
|
| update-rc.d and policy-rc.d are currently two separat
Hi Bernhard,
"Debian Bug report logs - #615153
exec: 58: /usr: Permission denied
Package: general; Maintainer for general is debian-devel@lists.debian.org;"
I think you just volunteered ;-)
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
On 03/01/2011 11:17 AM, Lucas Nussbaum wrote:
> On 01/03/11 at 10:44 +0100, Bernd Zeimetz wrote:
>> On 02/27/2011 04:31 PM, Lucas Nussbaum wrote:
>>> Ideally, we would have binary packages named like that:
>>> ruby-foo: arch-indep part of the foo library
>>> ruby1.8-foo: arch-dep part of the foo li
Hi,
As you may have known, valgrind is a powerful and easy to use tool that can be
used to detect many memory management issues on Linux. Details regarding
valgrind can be seen here,
http://valgrind.org
I notice that, valgrind reports memory leaks against some frequently used
commands on Debian
2011/3/1 ximalaya :
> I notice that, valgrind reports memory leaks against some frequently used
> commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps
> -ef, ls -latr, top, etc.
For short-running processes that's generally not a problem.
--
Olaf
--
To UNSUBSCRIBE, email to
On Tue, Mar 1, 2011 at 19:54, Olaf van der Spek wrote:
> 2011/3/1 ximalaya :
>> I notice that, valgrind reports memory leaks against some frequently used
>> commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps
>> -ef, ls -latr, top, etc.
>
> For short-running processes that's
01.03.2011 14:56, Aron Xu wrote:
> On Tue, Mar 1, 2011 at 19:54, Olaf van der Spek wrote:
>> 2011/3/1 ximalaya :
>>> I notice that, valgrind reports memory leaks against some frequently used
>>> commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps
>>> -ef, ls -latr, top, etc.
Hi,
As you may have known, valgrind is a powerful and easy to use tool that can be
used to detect many memory management issues on Linux. Details regarding
valgrind can be seen here,
http://valgrind.org
I notice that, valgrind reports memory leaks against some frequently used
commands of Debian
Agree with you all. For process that will terminate anyway, this may be not a
problem really.
While if there is any problem with the underlying libraries, it is worth
looking into...
At 2011-03-01 20:19:39，ximalaya wrote:
Hi all,
It's a surprise that you replied this email so quickly. Thanks f
Hi all,
It's a surprise that you replied this email so quickly. Thanks for your timely
comments! Several days ago, I ever posted to debian-u...@lists.debian.org, but
got no response.
BTW, I ever tried on Redhat Linux 9, no such problem.
Thanks,
Xmly
At 2011-03-01 20:04:16，"Michael Tokarev" wr
Holger Levsen writes ("potential MBF: first alternate depends not available in
main"):
> piuparts in master-slave mode currently cannot test packages which first
> alternate depends is not available in main, ie the secvpn package depends
> on "adduser, bc, ssh, ppp, timeout | coreutils (>= 7.5-1
Hi Ian,
On Dienstag, 1. März 2011, Ian Jackson wrote:
> Would it be possible to make piuparts cope by ignoring dependencies
> which are not available in the target suite ?
sure - patches welcome ;-)
But... that's not as easy as one would wish. Look
at /piupartslib/dependencyparser.py and at th
On Tue, Mar 01, 2011 at 09:50:27AM +0100, Christian Pohl wrote:
> Marc Haber wrote:
> > On Mon, 28 Feb 2011 22:26:56 +0100, Arthur de Jong
> > wrote:
> >>On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
> >>> Personally, I'd rather we didn't have them, as this is supposed to be
> >>> con
Package: wnpp
Severity: wishlist
Owner: Tobias Hansen
* Package name: out-of-order
Version : 1.0
Upstream Author : Tim Furnish
* URL : http://outoforder.adventuredevelopers.com
* License : Freeware with permission to redistribute, see below
Programming Lang
* Debian_bug_report [110301
14:57]:
> My problem happen after I did the distro upgrade... I pass 2 months out of
> my debian distro, and I used the testing version (Squeeze), but I return
> yesterday to my debian distro and the Squeeze becomes stable... so I did
> the change to Debian testing aga
On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote:
>> Isn't update-rc.d the way to configure the rc.d scripts?
>
> No, it's a way for *maintainer scripts* to manage init scripts.
>
>> Or am I old-fashioned.
>
> You are using an interface that was never meant for administrator use.
> Nowadays th
On Tue, Mar 01, 2011 at 04:26:23PM +0100, Olaf van der Spek wrote:
> On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote:
> >> Isn't update-rc.d the way to configure the rc.d scripts?
> > No, it's a way for *maintainer scripts* to manage init scripts.
> >> Or am I old-fashioned.
> > You are us
On Tue, Mar 1, 2011 at 5:13 PM, Steve Langasek wrote:
> On Tue, Mar 01, 2011 at 04:26:23PM +0100, Olaf van der Spek wrote:
>> On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote:
>> >> Isn't update-rc.d the way to configure the rc.d scripts?
>
>> > No, it's a way for *maintainer scripts* to mana
Package: wnpp
Severity: wishlist
Owner: Alessandro Ghedini
* Package name: librole-identifiable-perl
Version : 0.005
Upstream Author : Ricardo Signes
* URL : http://search.cpan.org/dist/Role-Identifiable/
* License : GPL-1+ or Artistic
Programming Lang: Perl
Hi,
I just want to know, if there is anything, that I can do to make crafty
(non-free) to be built on all architectures. Of cause there is a
XS-Autobuild: yes in the control file, and the build was officially
requested.
https://buildd.debian.org/pkg.cgi?pkg=crafty
It says, that auto-building wor
On 2011-03-01, Oliver Korff wrote:
> I just want to know, if there is anything, that I can do to make crafty
> (non-free) to be built on all architectures. Of cause there is a
> XS-Autobuild: yes in the control file, and the build was officially
> requested.
>
> https://buildd.debian.org/pkg.cgi?p
On Tue, Mar 01, 2011 at 05:19:37PM +0100, Olaf van der Spek wrote:
> On Tue, Mar 1, 2011 at 5:13 PM, Steve Langasek wrote:
> > On Tue, Mar 01, 2011 at 04:26:23PM +0100, Olaf van der Spek wrote:
> >> On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote:
> >> >> Isn't update-rc.d the way to configu
On Tue, 2011-03-01 at 17:19 +0100, Olaf van der Spek wrote:
> >> So what *is* the proper UI?
> >
> > The sensible abstraction for this is 'service' - but it doesn't appear that
> > service has support for enable/disable yet :(
>
> Do other distro's use service for this?
actually i think chkconfig
Hi, Josselin:
En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió:
> Le dimanche 27 février 2011 à 14:50 +0200, Dmitry Baryshev a écrit :
> > Who should do this investigation? I did it because I know how to debug
> > this. If user don't know how to debug this, his bug report will be
Jesús M. Navarro writes ("Re: What bug reports are for"):
> Hi, Josselin:
> > You seem to forget the very reason bug reports are here. Their point is
> > not to offer a service to our users - if you want that, you?ll need paid
> > support. Bug reports are here to help improving the distribution.
>
Hi, Russ:
En fecha Martes, 1 de Marzo de 2011, Russ Allbery escribió:
> "Jesús M. Navarro" writes:
> > En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió:
> >> Now, maintainers receive a lot of bug reports, and have limited time to
> >>
> >> spare on Debian. Given the choice betw
On Tue, 01 Mar 2011, Jesús M. Navarro wrote:
> Is *that* Debian's official position? That the bug report system is
> not there to offer a service to Debian users?
The BTS exists to help maintainers fix and track fixed bugs in their
packages. The service to users comes from the BTS enabling mainta
"Jesús M. Navarro" writes:
> I think I'll go here into troubled waters but It's my opinion (as
> somebody that has worked implementing and policying issue tracking
> systems, so I think it's an informed opinion, but just an opinion
> nevertheless) that there's no thing such too long a bug list.
Hi, Ian:
En fecha Martes, 1 de Marzo de 2011, Ian Jackson escribió:
> Jesús M. Navarro writes ("Re: What bug reports are for"):
> > Hi, Josselin:
> > > You seem to forget the very reason bug reports are here. Their point is
> > > not to offer a service to our users - if you want that, you?ll need
On Tue, Mar 1, 2011 at 7:25 PM, Sean Finney wrote:
> well, for starters the interface sucks from a sysadmin point of view
> compared to stuff like chkconfig/service. i also think that there's (a
> perhaps shrunken, haven't checked in a while) set of things that you
> just can't do with update-rc.
On Tue, 1 Mar 2011 19:47:58 +0100
"Jesús M. Navarro" wrote:
> Hi, Josselin:
>
> En fecha Domingo, 27 de Febrero de 2011, Josselin Mouette escribió:
> > Le dimanche 27 février 2011 à 14:50 +0200, Dmitry Baryshev a écrit :
> > > Who should do this investigation? I did it because I know how to
> >
Hi, Don:
En fecha Martes, 1 de Marzo de 2011, Don Armstrong escribió:
> On Tue, 01 Mar 2011, Jesús M. Navarro wrote:
> > Is *that* Debian's official position? That the bug report system is
> > not there to offer a service to Debian users?
>
> The BTS exists to help maintainers fix and track fixed
Hi, Russ:
En fecha Martes, 1 de Marzo de 2011, Russ Allbery escribió:
> "Jesús M. Navarro" writes:
> > I think I'll go here into troubled waters but It's my opinion (as
> > somebody that has worked implementing and policying issue tracking
> > systems, so I think it's an informed opinion, but jus
On 01.03.2011 18:24, Philipp Kern wrote:
> Needs-Build means that no builder has come around to build it yet. This
> includes reasons like "because non-free's not important, it's only built
> when there's nothing else to do" (see mips*) and "there are no non-free
> autobuilders for $arch" (see the
"Jesús M. Navarro" writes:
> No, you didn't (not at least that I managed to understand as such).
> What you did was telling what happened (that #3 bugs tend to cost too
> much time for too short a benefit, a thing the bug triager is only able
> to know after the fact, or else he could simply let
On Tue, Mar 01, 2011 at 09:12:18PM +0100, Oliver Korff wrote:
> On 01.03.2011 18:24, Philipp Kern wrote:
> > Needs-Build means that no builder has come around to build it yet. This
> > includes reasons like "because non-free's not important, it's only built
> > when there's nothing else to do" (se
Le dimanche 27 février 2011 16:31:29, Lucas Nussbaum a écrit :
> But then, we have a problem, because:
> - ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo,
> rubinius-foo) installed to work correctly
ok
> - ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo
> instal
On Mon, Feb 28, 2011 at 07:12:00PM +, Roger Leigh wrote:
> On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote:
> > On Tue, Feb 22, 2011 at 05:08:18PM +, Roger Leigh wrote:
> > > This is correct. I was thinking about drafting a patch for Policy
> > > about this. Current Policy
On Tue, Mar 01, 2011 at 10:09:37PM +0100, Adam Borowski wrote:
> On Tue, Mar 01, 2011 at 09:12:18PM +0100, Oliver Korff wrote:
> > On 01.03.2011 18:24, Philipp Kern wrote:
> > > Needs-Build means that no builder has come around to build it yet. This
> > > includes reasons like "because non-free's
Sean Finney writes:
> imho i think we need to step back and re-think the entire way we're
> currently handling init scripts, both from the packaging point of view
> and from the end-user/admin point of view.
Yes.
There are two issues here.
The "short term" issue is figuring out if the current
Stig Sandbeck Mathisen writes:
> There are two issues here.
> The "short term" issue is figuring out if the current practice of
> DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
> we want to keep doing.
> The "long term" issue is having a toolset, for the end user, for
>
On 03/01/2011 06:19 AM, ximalaya wrote:
Hi all,
[snip]
BTW, I ever tried on Redhat Linux 9, no such problem.
This is the interesting part. Is RH keeping their patches, or are
upstream and other distros just not determining them worthwhile?
--
I prefer banana-flavored energy bars made fr
Olaf van der Spek wrote:
> On Tue, Mar 1, 2011 at 4:16 PM, Steve Langasek wrote:
>> You are using an interface that was never meant for administrator use.
>> Nowadays there's an 'update-rc.d enable/disable', but even that, I think,
>> was intended to be a backend for the 'service' command.
>
> So
Tollef Fog Heen wrote:
> I think insserv makes it even more complicated, since I believe services
> might
> be pulled in, even if they're disabled. (Or it might be that insserv
> just throws its hands into the air and tells you it doesn't know how to
> do something the next time update-rc.d is run
On Monday, February 28, 2011 10:05:22 am Holger Levsen wrote:
> Hi,
>
> piuparts in master-slave mode currently cannot test packages which first
> alternate depends is not available in main, ie the secvpn package depends
> on "adduser, bc, ssh, ppp, timeout | coreutils (>= 7.5-1), sudo" and
> time
On Tue, Mar 01, 2011 at 08:38:42PM -0600, Ron Johnson wrote:
> On 03/01/2011 06:19 AM, ximalaya wrote:
>> BTW, I ever tried on Redhat Linux 9, no such problem.
>>
>
> This is the interesting part. Is RH keeping their patches, or are
> upstream and other distros just not determining them worthwhi
Hi!
On Wednesday 02 March 2011 03.38:42 Ron Johnson wrote:
> On 03/01/2011 06:19 AM, ximalaya wrote:
> > Hi all,
>
> [snip]
>
> > BTW, I ever tried on Redhat Linux 9, no such problem.
>
> This is the interesting part. Is RH keeping their patches, or are
> upstream and other distros just not de
]] Raphael Geissert
| Tollef Fog Heen wrote:
| > I think insserv makes it even more complicated, since I believe services
| > might
| > be pulled in, even if they're disabled. (Or it might be that insserv
| > just throws its hands into the air and tells you it doesn't know how to
| > do somethin
57 matches
Mail list logo
