Re: enable/disable flags in /etc/default

[Christian Pohl]

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 we should fix that rather than invent multiple ways of disabling
>>> daemons, but the current mess is, well, a mess.
>>
>>I would also love to have a way to easily configure which daemons should
>>be started at boot time. I don't know whether switching to insserv made
>>things simpler in that regard though.

Isn't update-rc.d the way to configure the rc.d scripts? Or am I
old-fashioned.

My bits the /etc/default/scripts:
I would not use them to enable or disable deamons - only to "tune" the
init.d scripts behaviour. E.g. command line arguments), that must be given
at deamon-start and are not configurable in some /etc/mydeamon.conf.
See e.g. /etc/default/ntp.

Chris

-- 
Christian Pohl
w...@pohlcity.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e5763d573777f2d36471896816e1f7e5.squirrel@aringill

Re: What bug reports are for

[Holger Levsen]

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 bugs are bugs, but 
rather the submitters. 

If maintainers go out of their way to help reproducing bugs, great. But if 
they don't want to, thats totally fine too.

And then it's also fine to close unreproducable bugs which one suspects are 
due to local, aeh, constraints. Reopening once they are found to be 
reproducable is easy :-)


cheers,
Holger




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

Re: Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Vincent Danjean]

  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 directories in
> $HOME by default (e.g. via /etc/skel.d) -- how to organize this should
> be the users' choice.  I for example use
> --prefix="$HOME/.system/stow/" for each individual software
> package, so I can quickly remove and reinstate them using GNU
> Stow. Having ~/lib and ~/share, ~/bin, etc. unconditionally created in
> my home directory would just be useless clutter.

I also use stow but in a slightly different way : with your setup,
the software has the knowledge of the stow directory structure.
For examples, it would search its plugins in
$HOME/.system/stow//share/
If I try to install other plugins with stow in
$HOME/.system/stow//share/
they won't be found (nor in $HOME/.system/share/
where symlinks are created by stow).

So, I configure my software with :
./configure --prefix="$HOME/.system" ...
But I install them with :
make install DESTDIR=$HOME/.system/stow/
mv $HOME/.system/stow//$HOME/.system/* $HOME/.system/stow/
rmdir --parents $HOME/.system/stow//$HOME/.system
cd $HOME/.system/stow/
stow 

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6cb977.1030...@debian.org

Re: Are circular dependencies inside a source package OK?

[Vincent Danjean]

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 not specify with which ruby interpreter
he will work ?
This means that nothing can 'depend' on ruby-foo without also
depending on a ruby-foo

Reading latter, it seems that you want that ruby-foo installs
what it needed for the default ruby implementation. So, do what
Josselin suggests:
- ruby-foo-common: arch indep, no depends (or depends on other software)
- ruby-foo: arch dep, Depends: ruby-foo
- ruby-foo: arch indep, empty package, Depends: ruby-foo

> - ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo
>   installed
> 
> What we would like to do to reflect this is:
> - ruby-foo depend on the implementation-specific package for the default
>   version of Ruby (so Depends: ruby1.8-foo)
> - ruby-foo Depends: ruby-foo

With your proposal, in addition to the circular dependencies, I cannot
install foo for jruby without *also* installing foo for the default
interpreter...

  Regards,
Vincent

> However, that creates many small dependency cycles. I am under the
> impression that dependency cycles are considered bad, but that we have
> many of them already, and that no important part of our infrastructure
> or tools really has problems with them. Also, they are limited to a
> single source package here.
> 
> Is there a good reason not to do the above?
> 
> - Lucas
> 
> 


-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6cbc22.6030...@free.fr

Re: Are circular dependencies inside a source package OK?

[Bernd Zeimetz]

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're basically at a point where Python was years ago - one binary
package for every supported version. i think you should find a way to
move the whole stuff for all ruby versions into one package and find a
proper way to handle dependencies and whatever else is needed.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6cc012.1000...@bzed.de

Re: enable/disable flags in /etc/default

[Tollef Fog Heen]

]] "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 about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipw3rwxh@qurzaw.varnish-software.com

Re: enable/disable flags in /etc/default

[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 separate interfaces. If I
want to make sure that a service is never started I need to modify both:

1) policy-rc.d to make sure that the service does not start when the
package is installed/upgraded/logrotated

2) update-rc.d to make sure that the service does not start on boot.

In

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584865

I tried to draft a solution that'd give me centralized control over
services.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/841v2rno2v@sauna.l.org

Re: Are circular dependencies inside a source package OK?

[Lucas Nussbaum]

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-dep part of the foo library, built for ruby1.9.1
> 
> Here you're basically at a point where Python was years ago - one binary
> package for every supported version. i think you should find a way to
> move the whole stuff for all ruby versions into one package and find a
> proper way to handle dependencies and whatever else is needed.

Here we are only discussing Ruby libraries that ship .so files. For
pure-ruby libs (which is the vast majority of ruby libs), we have a
solution already, with only one binary package.

I think it's reasonable to have one package per ruby implementation for
native packages.

- Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110301101724.ga11...@xanadu.blop.info

Re: What bug reports are for

[Bernhard R. Link]

* 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's the maintainers duty to prove that bugs are bugs, but
> rather the submitters.

It's the maintainers interest and the job they volunteered for to look
after the package and thus also find bugs and fix them in the one or
other way (for example by reporting them upstream in a way upstream can
properly deal with that). The bug reporter is someone simply helping
here.

It makes sense to focus on bugs one can deal with and ask the submitter
for more help with bugs one cannot deal with yourself. It can be
acceptable to close bug reports once there is no hope a bug can be
identified and fixed with it (so the costs of having the report open
(like making bug lists harder to read thus making it harder to report
and fix bugs) are bigger than the expected benefits of having it
(probability this is an actual bug * probability it can be found due to
this report * probability it hits again * costs it causes).

Of course packages with many bugs and little maintainer man-power
usually have heigher costs per bug (more crowded bug lists) and smaller
expected benefits (smaller probability the bug will be found), so it can
for some packages make more sense to close a report than for smaller
packages.

But still a bug report is mostly an try to help us improve the software
we care for. Like every other attempt to help it can be counterproductive,
but we should be careful to not discourage people trying to help us.

> And then it's also fine to close unreproducable bugs which one suspects are
> due to local, aeh, constraints. Reopening once they are found to be
> reproducable is easy :-)

That means someone must be actually looking at it. Closed bugs are not
that often looked at in my experience.


Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110301103752.ga12...@pcpool00.mathematik.uni-freiburg.de

Re: enable/disable flags in /etc/default

[Tollef Fog Heen]

]] 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 separate interfaces. If I
| want to make sure that a service is never started I need to modify both:
| 
| 1) policy-rc.d to make sure that the service does not start when the
| package is installed/upgraded/logrotated

The only reason for having a policy-rc.d would be to make sure it does
not start on initial installation.  If invoke-rc.d starts services on
upgrades after you've done update-rc.d disable $service, that sound like
a bug.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762s3rtxz@qurzaw.varnish-software.com

Re: What bug reports are for

[Holger Levsen]

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.

Re: Are circular dependencies inside a source package OK?

[Bernd Zeimetz]

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 library, built for ruby1.8
>>> ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1
>>
>> Here you're basically at a point where Python was years ago - one binary
>> package for every supported version. i think you should find a way to
>> move the whole stuff for all ruby versions into one package and find a
>> proper way to handle dependencies and whatever else is needed.
> 
> Here we are only discussing Ruby libraries that ship .so files.

That shouldn't make a difference if you find a way to handle the
dependencies to whatever they link properly. Unfortunately i don't know
enough about th einternals of Ruby to make a really useful suggestion,
but I'm sure it would be possible to find a proper solution which
doesn't involve a lot of additional packages.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6cdd44.5060...@bzed.de

Potential memory leaks reported by Valgrind against some frequently used commands

[ximalaya]

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 6.0, 5.0.7 and 4.0. These commands include netstat, ps -ef, 
ls -latr, top, etc.

I post the reports here, hope someone can look into this issue and get it 
resolved(pay attention to function calls in libc-2.7.so).

Environment
==
OS: debian 5.07
debian:~# uname -a
Linux debian 2.6.26-2-686 #1 SMP Sat Nov 20 23:06:30 UTC 2010 i686 GNU/Linux

debian:/lib/i686/cmov# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' 
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu 
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)

debian:/lib/i686/cmov# /usr/local/valgrind/bin/valgrind --version
valgrind-3.6.1


Valgrind reports

1. netstat
debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full netstat
==2591==
==2591== HEAP SUMMARY:
==2591== in use at exit: 15,122 bytes in 1,125 blocks
==2591==   total heap usage: 1,367 allocs, 242 frees, 42,343 bytes allocated
==2591==
==2591== 66 (48 direct, 18 indirect) bytes in 4 blocks are definitely lost in 
loss record 6 of 11
==2591==at 0x40221CA: malloc (vg_replace_malloc.c:236)
==2591==by 0x804FE96: ??? (in /bin/netstat)
==2591==by 0x8049E1A: ??? (in /bin/netstat)
==2591==by 0x804A3DC: ??? (in /bin/netstat)
==2591==by 0x804CD14: ??? (in /bin/netstat)
==2591==by 0x4047454: (below main) (in /lib/i686/cmov/libc-2.7.so)
==2591==
==2591== LEAK SUMMARY:
==2591==definitely lost: 48 bytes in 4 blocks
==2591==indirectly lost: 18 bytes in 4 blocks
==2591==  possibly lost: 0 bytes in 0 blocks
==2591==still reachable: 15,056 bytes in 1,117 blocks
==2591== suppressed: 0 bytes in 0 blocks
==2591== Reachable blocks (those to which a pointer was found) are not shown.
==2591== To see them, rerun with: --leak-check=full --show-reachable=yes
==2591==
==2591== For counts of detected and suppressed errors, rerun with: -v

2. ps -ef
debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full ps -ef
==2597==
==2597== HEAP SUMMARY:
==2597== in use at exit: 966 bytes in 44 blocks
==2597==   total heap usage: 390 allocs, 346 frees, 20,255 bytes allocated
==2597==
==2597== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in 
loss record 28 of 30
==2597==at 0x40221CA: malloc (vg_replace_malloc.c:236)
==2597==by 0x4144AA0: ??? (in /lib/i686/cmov/libc-2.7.so)
==2597==by 0x414539B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so)
==2597==by 0x470AF5B: ???
==2597==by 0x470D0B4: ???
==2597==by 0x40EC011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so)
==2597==by 0x40EB996: getpwuid (in /lib/i686/cmov/libc-2.7.so)
==2597==by 0x4035FCB: user_from_uid (in /lib/libproc-3.2.7.so)
==2597==by 0x403735C: ??? (in /lib/libproc-3.2.7.so)
==2597==by 0x4037D7E: readproc (in /lib/libproc-3.2.7.so)
==2597==by 0x8049A8D: ??? (in /bin/ps)
==2597==by 0x804A382: ??? (in /bin/ps)
==2597==
==2597== LEAK SUMMARY:
==2597==definitely lost: 36 bytes in 1 blocks
==2597==indirectly lost: 120 bytes in 10 blocks
==2597==  possibly lost: 0 bytes in 0 blocks
==2597==still reachable: 810 bytes in 33 blocks
==2597== suppressed: 0 bytes in 0 blocks
==2597== Reachable blocks (those to which a pointer was found) are not shown.
==2597== To see them, rerun with: --leak-check=full --show-reachable=yes
==2597==

3. ls -latr
debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full ls -latr
==2592== HEAP SUMMARY:
==2592== in use at exit: 12,680 bytes in 41 blocks
==2592==   total heap usage: 276 allocs, 235 frees, 39,123 bytes allocated
==2592==
==2592== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in 
loss record 27 of 29
==2592==at 0x40221CA: malloc (vg_replace_malloc.c:236)
==2592==by 0x414DAA0: ??? (in /lib/i686/cmov/libc-2.7.so)
==2592==by 0x414E39B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so)
==2592==by 0x4714F5B: ???
==2592==by 0x47170B4: ???
==2592==by 0x40F5011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so)
==2592==by 0x40F4996: getpwuid (in /lib/i686/cmov/libc-2.7.so)
==2592==by 0x8053982: ??? (in /bin/ls)
==2592==by 0x804AA7B: ??? (in /bin/ls)
==2592==

Re: Potential memory leaks reported by Valgrind against some frequently used commands

[Olaf van der Spek]

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikrvavkxvzjgltmgrqerca7fxii9hdl8mhvp...@mail.gmail.com

Re: Potential memory leaks reported by Valgrind against some frequently used commands

[Aron Xu]

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 generally not a problem.
> --
> Olaf
>

It would be good if we fix them, :)

-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktint9f0+ppndptnkcemgiabbxvvwwhnkab9z_...@mail.gmail.com

Re: Potential memory leaks reported by Valgrind against some frequently used commands

[Michael Tokarev]

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.
>>
>> For short-running processes that's generally not a problem.

> 
> It would be good if we fix them, :)


There are at least two kinds of "memory leaks" which may be present
and reported here.  One is a single memory buffer allocated (and may
be reallocated) for some one-time task and not freed.  And another
may be a missing free for every object a program iterates - like
in case of ls, a memleak of an object for every file it lists.

First kinds of memory "leaks" are definitely _not_ worth to fix,
because if we'll exit right away anyway, kernel will free all our
memory in one go after process termination, and by using free()
we just wating CPU time and gains nothing at all.

But second kind of leaks is definitely worth to fix, for obvious
reason: tools like ls(1) should not grow their memory without
bounds.

But I suspect there are only kind-1 "leaks" you found, at least
the ones which are reported are all of this sort.

Thanks!

/mjt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6ce0c0.7050...@msgid.tls.msk.ru

Potential memory leaks reported by Valgrind against some frequently used commands

[ximalaya]

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 5.0.7 and 4.0. Don't have a chance to try later releases, 
but I think the problem may still be there. These commands include netstat, ps 
-ef, ls -latr, top, etc.

I post the reports here, hope someone can look into this issue and get it 
resolved(pay attention to function calls in libc-2.7.so).

Environment
==
OS: debian 5.07
debian:~# uname -a
Linux debian 2.6.26-2-686 #1 SMP Sat Nov 20 23:06:30 UTC 2010 i686 GNU/Linux

debian:/lib/i686/cmov# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' 
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu 
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)

debian:/lib/i686/cmov# /usr/local/valgrind/bin/valgrind --version
valgrind-3.6.1


Valgrind reports

1. netstat
debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full netstat
==2591==
==2591== HEAP SUMMARY:
==2591== in use at exit: 15,122 bytes in 1,125 blocks
==2591==   total heap usage: 1,367 allocs, 242 frees, 42,343 bytes allocated
==2591==
==2591== 66 (48 direct, 18 indirect) bytes in 4 blocks are definitely lost in 
loss record 6 of 11
==2591==at 0x40221CA: malloc (vg_replace_malloc.c:236)
==2591==by 0x804FE96: ??? (in /bin/netstat)
==2591==by 0x8049E1A: ??? (in /bin/netstat)
==2591==by 0x804A3DC: ??? (in /bin/netstat)
==2591==by 0x804CD14: ??? (in /bin/netstat)
==2591==by 0x4047454: (below main) (in /lib/i686/cmov/libc-2.7.so)
==2591==
==2591== LEAK SUMMARY:
==2591==definitely lost: 48 bytes in 4 blocks
==2591==indirectly lost: 18 bytes in 4 blocks
==2591==  possibly lost: 0 bytes in 0 blocks
==2591==still reachable: 15,056 bytes in 1,117 blocks
==2591== suppressed: 0 bytes in 0 blocks
==2591== Reachable blocks (those to which a pointer was found) are not shown.
==2591== To see them, rerun with: --leak-check=full --show-reachable=yes
==2591==
==2591== For counts of detected and suppressed errors, rerun with: -v

2. ps -ef
debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full ps -ef
==2597==
==2597== HEAP SUMMARY:
==2597== in use at exit: 966 bytes in 44 blocks
==2597==   total heap usage: 390 allocs, 346 frees, 20,255 bytes allocated
==2597==
==2597== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in 
loss record 28 of 30
==2597==at 0x40221CA: malloc (vg_replace_malloc.c:236)
==2597==by 0x4144AA0: ??? (in /lib/i686/cmov/libc-2.7.so)
==2597==by 0x414539B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so)
==2597==by 0x470AF5B: ???
==2597==by 0x470D0B4: ???
==2597==by 0x40EC011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so)
==2597==by 0x40EB996: getpwuid (in /lib/i686/cmov/libc-2.7.so)
==2597==by 0x4035FCB: user_from_uid (in /lib/libproc-3.2.7.so)
==2597==by 0x403735C: ??? (in /lib/libproc-3.2.7.so)
==2597==by 0x4037D7E: readproc (in /lib/libproc-3.2.7.so)
==2597==by 0x8049A8D: ??? (in /bin/ps)
==2597==by 0x804A382: ??? (in /bin/ps)
==2597==
==2597== LEAK SUMMARY:
==2597==definitely lost: 36 bytes in 1 blocks
==2597==indirectly lost: 120 bytes in 10 blocks
==2597==  possibly lost: 0 bytes in 0 blocks
==2597==still reachable: 810 bytes in 33 blocks
==2597== suppressed: 0 bytes in 0 blocks
==2597== Reachable blocks (those to which a pointer was found) are not shown.
==2597== To see them, rerun with: --leak-check=full --show-reachable=yes
==2597==

3. ls -latr
debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full ls -latr
==2592== HEAP SUMMARY:
==2592== in use at exit: 12,680 bytes in 41 blocks
==2592==   total heap usage: 276 allocs, 235 frees, 39,123 bytes allocated
==2592==
==2592== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in 
loss record 27 of 29
==2592==at 0x40221CA: malloc (vg_replace_malloc.c:236)
==2592==by 0x414DAA0: ??? (in /lib/i686/cmov/libc-2.7.so)
==2592==by 0x414E39B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so)
==2592==by 0x4714F5B: ???
==2592==by 0x47170B4: ???
==2592==by 0x40F5011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so)
==2592==by 0x40F4996: getpwuid (in /lib/i686/cmov/libc-2.7.so)
==2592==by 

Re:Re:Re: Potential memory leaks reported by Valgrind against some frequently used commands

[ximalaya]

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 for your timely 
comments! Several days ago, I ever posted todebian-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"  wrote:

>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.
>>>
>>> For short-running processes that's generally not a problem.
>
>> 
>> It would be good if we fix them, :)
>
>
>There are at least two kinds of "memory leaks" which may be present
>and reported here.  One is a single memory buffer allocated (and may
>be reallocated) for some one-time task and not freed.  And another
>may be a missing free for every object a program iterates - like
>in case of ls, a memleak of an object for every file it lists.
>
>First kinds of memory "leaks" are definitely _not_ worth to fix,
>because if we'll exit right away anyway, kernel will free all our
>memory in one go after process termination, and by using free()
>we just wating CPU time and gains nothing at all.
>
>But second kind of leaks is definitely worth to fix, for obvious
>reason: tools like ls(1) should not grow their memory without
>bounds.
>
>But I suspect there are only kind-1 "leaks" you found, at least
>the ones which are reported are all of this sort.
>
>Thanks!
>
>/mjt
>
>
>-- 
>To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>Archive: http://lists.debian.org/4d6ce0c0.7050...@msgid.tls.msk.ru
>

Re:Re: Potential memory leaks reported by Valgrind against some frequently used commands

[ximalaya]

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"  wrote:

>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.
>>>
>>> For short-running processes that's generally not a problem.
>
>> 
>> It would be good if we fix them, :)
>
>
>There are at least two kinds of "memory leaks" which may be present
>and reported here.  One is a single memory buffer allocated (and may
>be reallocated) for some one-time task and not freed.  And another
>may be a missing free for every object a program iterates - like
>in case of ls, a memleak of an object for every file it lists.
>
>First kinds of memory "leaks" are definitely _not_ worth to fix,
>because if we'll exit right away anyway, kernel will free all our
>memory in one go after process termination, and by using free()
>we just wating CPU time and gains nothing at all.
>
>But second kind of leaks is definitely worth to fix, for obvious
>reason: tools like ls(1) should not grow their memory without
>bounds.
>
>But I suspect there are only kind-1 "leaks" you found, at least
>the ones which are reported are all of this sort.
>
>Thanks!
>
>/mjt
>
>
>-- 
>To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>Archive: http://lists.debian.org/4d6ce0c0.7050...@msgid.tls.msk.ru
>

Re: potential MBF: first alternate depends not available in main

[Ian Jackson]

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), sudo" and timeout 
> is only available in lenny and etch, thus piuparts cannot test secvpn in 
> squeeze, wheezy and sid. That's a bug in piuparts.

Would it be possible to make piuparts cope by ignoring dependencies
which are not available in the target suite ?

That would make it easier to test against a different suite to the one
intended, too.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19820.61423.343813.790...@chiark.greenend.org.uk

Re: potential MBF: first alternate depends not available in main

[Holger Levsen]

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 the Package and PackagesDB classes 
from piupartslib/packagesdb.py... 

Actually, I think it's really hard to change the code to cope as it's also far 
from trivial to use another dependency parser, esp. for master-slave mode. 

But still, while this is definitly a bug in piuparts, what do you think about 
the topic in subject?

> That would make it easier to test against a different suite to the one
> intended, too.

Why? A suite should be self contained. (Or, explicitly "support" other suites 
like security supports main.)


cheers,
Holger


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

Re: enable/disable flags in /etc/default

[Steve Langasek]

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
> >>> controlled by the rcN.d links and if that interface is too hard for
> >>> people we should fix that rather than invent multiple ways of disabling
> >>> daemons, but the current mess is, well, a mess.

> >>I would also love to have a way to easily configure which daemons should
> >>be started at boot time. I don't know whether switching to insserv made
> >>things simpler in that regard though.

> 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 there's an 'update-rc.d enable/disable', but even that, I think,
was intended to be a backend for the 'service' command.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#615984: ITP: out-of-order -- comedy science fiction adventure game

[Tobias Hansen]

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: SLUDGE
  Description : comedy science fiction adventure game

It is available in the form of a compiled game file that is interpreted
by the SLUDGE engine, which I also intend to package (ITP bug #612862).
The source code of the game is not available. I hope that the package
will be included in non-free.

Here is the license, in DEP-5 format:

Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=166
Upstream-Name: Out Of Order
Upstream-Contact: Tim Furnish 
Source: http://outoforder.adventuredevelopers.com

Files: *
Copyright: 2000 - 2003 Tim Furnish
License: Custom
 Greetings, Linux user. I see you can open and read text files. You're
 quite the computer expert, aren't you? Ace. With a spot of luck, then,
 you may also happen to be quite proficient at a game called Out Of Order.
 And, as good fortune would have it, that game should be provided in the
 same packagey bundle as this text file. Or vice versa, depending on point
 of view. My point is this: Out Of Order is a comedy sci-fi adventure game,
 set somewhere in some time period, featuring a guy in silly slippers and
 written originally for Windows. Or, rather, it was originally written for
 the freeware SLUDGE adventure game engine back in the day when there was
 only a Windows version. However, the times are very much a-changin' and
 the engine has since been ported to other platforms. Hooray for people
 with more time on their hands than myself! I admire and adore them all.
 As should you, because without them you'd not be able to play this fine
 game on your non-Windows machine. Hang on, was that actually my point?
 No, wait. THIS was my point: the initial distribution of Out Of Order
 contained the Windows engine. But I hereby give permission for you to
 possess a copy of the data file and a copy of the engine for another
 operating system of your choosing and experience the joys of the former
 via the modern miracle of the latter. But please - don't charge for it.
 And don't break the package apart and distribute bits of it individually.
 And don't try to reverse engineer it. And don't prod and poke at it with a
 HEX editor to make the characters say rude things about people you know,
 or to make it look like you wrote it. Just play it and love it and get in
 a grump with it when you can't get past some part of it. On which topic, a
 few hints for those who've read this far: everyone else's is on the
 outside of their door, read it out loud, and try using thing A in thing B
 in thing C, not just thing A in thing C. (Sorry about that third one.)
 .
 - Tim Furnish, June 2010
Comment:
 While the license text does not explicitly mention redistribution, Tim
 Furnish wrote in the same mail to me (Tobias Hansen) that also contained
 the license:
 .
 "Sore, by all means make the existing OOO data file available for Linux
 - with the engine if that's what you're suggesting. I must admit, despite
 having used Linux on and off for over 10 years, I've never packaged
 anything up for it for distribution so don't really have that much of a
 clue about what's involved. But yeah, go for it. The data file's freely
 distributable at the moment as part of the installer... so I guess there's
 no harm whatsoever in make it available outside of it." 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110301144627.2527.44475.report...@tobi-laptop.lan

Bug#615153: exec: 58: /usr: Permission denied

[Bernhard R. Link]

* 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 again (now called Wheezy)...

A full upgrade is a very complicated thing to reproduce. And you seem to
have 3rd party repositories, so there are packages from other people
that might have bugs, so finding this will be complicated.

> so I rename all my source packages like this source.list:
>[...]
> #mirror multimídia
> deb http://ftp.br.debian.org/debian-multimedia/ testing main
> #deb http://ftp.debian-unofficial.org/debian testing main contrib non-free
>
> #mirror wine:
> #deb http://www.lamaresh.net/apt/ squeeze/main

As those are 3rd party repositories, there is some probability the bug
is there.

> So, I went to my Lxterminal and type: "sudo aptitude update". After I type:
> "sudo aptitude safe-upgrade".
>
> The system make a download of 839mb of data. Everything was made without any
> errors reported... I not use any login manager... I do my login in getty and
> after I start my X and window manager (fluxbox). So, when I restart my
> machine
> and try to start my X with the command "startx", the system returns the
> error:
> "xinit: connection to X server lost" and after said "Wait for X server to
> shut
> down" and stayed with prompt flashing again. So, I tried invoke X with root
> and
> I had sucess! When I went to the .xsession-errors I saw this error:
>
> Xsession: X session started for invisiblemanguard at Ter Fev 22 16:36:02 BRT
> 2011
> exec: 58: /usr: Permission denied

Could you check the actual permissions of those directories?
Perhaps the output of "ls -la /" would be best.

Where things are mounted might also be interesting, i.e. the /etc/fstab
and the /proc/mounts files.

Other information interesting might be the /var/log/dpkg.* files
covering the interesting timespan.

(Saving /root/.bash_history and looking into it for anything interesting
might also be sensible).

Bernhard R. Link



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110301152011.ga13...@pcpool00.mathematik.uni-freiburg.de

Re: enable/disable flags in /etc/default

[Olaf van der Spek]

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 there's an 'update-rc.d enable/disable', but even that, I think,
> was intended to be a backend for the 'service' command.

So what *is* the proper UI?

Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=3M7q=KgNVmY5q=hvfb8bwmhelkbjp4jdxl...@mail.gmail.com

Re: enable/disable flags in /etc/default

[Steve Langasek]

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

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: enable/disable flags in /etc/default

[Olaf van der Spek]

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 manage init scripts.
>
>> >> Or am I old-fashioned.
>
>> > 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 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?
What's the reason update-rc.d is limited to maintainer scripts?

Olaf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=s+yx_pgdg_+inbutmbg4fn4hrd-njphgug...@mail.gmail.com

Bug#615996: ITP: librole-identifiable-perl -- Moose roles to identify things

[Alessandro Ghedini]

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
  Description : Moose roles to identify things

The Role::Identifiable distribution provides several Moose roles for
identifying things.
.
This distribution provides the following roles:
 * Role::Identifiable::HasIdent - Adds a required ident attribute that
   stores a simple string, meant to identify exceptions.
 * Role::Identifiable::HasTags - Adds the ability for your class and its
   composed parts (roles, superclasses) as well as instances of it to
   contribute to a pool of tags describing each instance.

NOTE: This is needed by the new version of libconfig-mvp-perl



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110301162312.12155.60228.reportbug@localhost6.localdomain6

building crafty (non-free) automagically

[Oliver Korff]

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 works for: amd64 ia64 powerpc s390 sparc

On: alpha, hppa, hurd-i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel
autobuilding seems not to work.

On: armel the message is: Not-For-Us, so I assume, that crafty is banned
here.

Any help would be very kind and please tell me a single e-mail address,
that is connected to the problem, then I will not "spam" all arch@buildd
adresses.

Regards,

Oliver

Note: It might be, that crafty does not compile on some of these
architectures.





-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6d2686.5030...@xynyx.de

Re: building crafty (non-free) automagically

[Philipp Kern]

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?pkg=crafty
>
> It says, that auto-building works for: amd64 ia64 powerpc s390 sparc
>
> On: alpha, hppa, hurd-i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel
> autobuilding seems not to work.

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

> On: armel the message is: Not-For-Us, so I assume, that crafty is banned
> here.

There you'd want to mail armel@buildd for a nfu drop, if you think it's
buildable on that arch.  (nfu indicates that at one point it didn't.)

In general debian-wb-team@lists.d.o sounds like a better contact address
than d-devel@.  The page you linked shouldn't be used anymore[*],
instead https://buildd.debian.org/status/package.php?p=crafty also has
the right contact address (albeit it talks about the (web) pages only,
I think that should be fixed).

Ciao
Philipp Kern

[*] But I guess it's still linked from several places.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnimqaua.kip.tr...@kelgar.0x539.de

Re: enable/disable flags in /etc/default

[Ben Hutchings]

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 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 there's an 'update-rc.d enable/disable', but even that, I think,
> >> > was intended to be a backend for the 'service' command.
> >
> >> 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?
> What's the reason update-rc.d is limited to maintainer scripts?
 
No, they use chkconfig.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110301181606.gf19...@decadent.org.uk

Re: enable/disable flags in /etc/default

[Sean Finney]

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 is more common than service for
enabling/disabling.  

> What's the reason update-rc.d is limited to maintainer scripts?

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.d, without having the changes lost the next
time the package is upgraded.  i mean, it's not even that great for
maintainer scripts, as evidenced by the total inconsistency for how
developers are managing enabling/disabling of their services.

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.  i think someone tried to
start something like this up long ago[1] but it never picked up steam.
maybe now that we have two new different init systems at the gates and
also people wanting to have continued support of "traditional"
sysv/file-rc, we should consider trying to revitalize that discussion?


sean

[1] this would be the initscripts-ng alioth project


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

Re: What bug reports are for

[Jesús M. Navarro]

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
> > closed without reassigning to proper package. Hence this investigation
> > should be done by maintainer, not user.
> 
> 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.

Good to know.

Is *that* Debian's official position?  That the bug report system is not there 
to offer a service to Debian users?

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103011947.58328.jesus.nava...@undominio.net

Re: What bug reports are for

[Ian Jackson]

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.
> 
> Good to know.
> 
> Is *that* Debian's official position?  That the bug report system is
> not there to offer a service to Debian users?

Debian doesn't have an "official position" on this question.  But I
would guess it is the position of the vast majority of Debian's
maintainers.

This has been standard wisdom for Free Software for decades now.  See
for example this extract from the GNU "Information for Maintainers"
document:

  The main purpose of bug reports is to help you contribute to the
  community by improving the next version of the program. Many of the
  people who report bugs don't realize this-they think that the point is
  for you to help them individually. Some will ask you to focus on that
  instead of on making the program better. If you comply with their
  wishes, you will have been distracted from the job of maintaining the
  program.

  ...

  When people ask you to put your time into helping them use the
  program, it may seem "helpful" to do what they ask. But it is much
  less helpful than improving the program, which is the maintainer's
  real job.

http://www.gnu.org/prep/maintain/maintain.html#Replying-to-Mail

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19821.16552.732033.436...@chiark.greenend.org.uk

Re: What bug reports are for

[Jesús M. Navarro]

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 between:
> >>  1. packaging a new upstream release that fixes a lot of bugs;
> >>  2. fixing a nicely reported bug with a reproducible and
> >>  
> >> well-identified cause;
> >>  
> >>  3. investigating a dubious bug report that seems to be triggered by
> >>  
> >> a broken user configuration;
> >> 
> >> only masochistic maintainers will spend time on #3 when they can help a
> >> lot more users on #1 and #2. It’s not that it’s easier (I remember
> >> spending entire days on single bugs), but it’s more useful.
> > 
> > True, and I don't think anybody would expect any more.
> > 
> > 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'm not telling this is the case for this bug since I really don't know
> > it but as a general matter, but *if* that were the case, no, I don't
> > think sweeping bugs under the carpet is a proper policy.
> 
> Well, maybe #3 is still a bug.  That's the problem, right?  We don't know
> that.

No, I don't think it is.  #3 *is* a bug since the moment somebody has referred 
it as such.

> The trouble with things that fall into category #3, apart from just taking
> way more time to investigate, is that they may or may not actually be
> bugs.  Frequently once one investigates, one finds that it's not a bug in
> any useful fashion (it's already fixed, it's caused by something on the
> user side against which it's not reasonable for the package to take
> precautions, the user's system was in some broken state, or no one can
> reproduce the problem and the user isn't replying).

That maybe the case, but you won't know till you take the time to research it.  
All you know prior to that is that it is there, on the bug tracking system, 
therefore it is a bug.

> And it can take a lot
> of time to get to that point of realizing that something in #3 isn't an
> actionable bug.
> 
> Meanwhile, #1 and #2 are much more efficient in terms of maintainer time
> to fixed bug ratio.
> 
> The #3 reports aren't *useless* in aggregate (although individual cases of
> #3 often are individually useless), but they are almost always less useful
> in improving the package quality than #1 and #2.  This means that they're
> probably still worth spending time on if all #1 and #2 tasks are complete,
> but if there are #1 and #2 tasks pending, #3 is probably not worth paying
> attention to.

Completly agreed, but absolutly unrelated.  That it is no worth paying 
attention to it (even if that's truly the case) makes it any less of a bug.

> Now, for most packages, #1 and #2 bugs tend to get resolved relatively
> quickly, or at least end up in some stable state (such as understanding a
> #2 bug but realizing it's going to take a ton of work to fix), so
> maintainers get to the #3 bugs.  But what happens with a package that gets
> so many bugs that maintainers can't get to all the #1 and #2 bugs?  Are #3
> bugs actually even useful to track at that point?
> 
> I think one of the arguments being made in recent discussions is that if
> one is already overwhelmed with bugs of type #1 and #2, even tracking bugs
> of type #3 may be more trouble than it's worth.  The additional overhead
> of having the appear in bug listings and the additional users who file
> duplicate bugs because the bug list is so long they fail to check for
> duplicates at all may cause more aggregate work than the #3 bugs provide
> in utility for that package.

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.

What it usually happens (at least in my experience) is that too long a bug 
list hurts the ego of the one that think of himself as being responsible for 
that so we, being humans the way we are, feel a strong inclination to 
"resolve" it by whatever means we find and being an easy scape path sweeping 
them under the carpet, that's what we'll do.  It takes a strong and well-
ballanced ego just to recognize that, well, there's simply not enough man-
power to deal with it, so focus must be centered on what brings better cost-
benefit ratio (bugs #1 and #2) and let #3 accumulate even if that makes for an 
"ugly" bug list for the package.

> And we have a fair number of packages in
> Debian that get enough bug reports on an ongoing basis, relative to the
> number of people working on them, that the chances of us ever cleaning out
> all the #1 and #2 bugs and having it 

Re: What bug reports are for

[Don Armstrong]

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 maintainers
to fix their bugs.

While it's certainly not optimal, closing bugs which are
unreproducible or incomplete are sometimes necessary because we do not
have an infinite amount of maintainers to fix bugs. If there are
people who feel strongly about helping to get these unreproducible or
incomplete bugs in a state where someone can actually resolve them,
then please, form a crew, and start working on them. Feel free to let
ow...@bugs.debian.org know how you want to know about these bugs if
you need some additional features in the BTS. We certainly could use
more bug triagers.

Haranguing maintainers who are doing a best-effort job or further
discussion on -devel about this should not be necessary.


Don Armstrong

-- 
Your village called.
They want their idiot back.
 -- xkcd http://xkcd.com/c23.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110301191519.gq5...@teltox.donarmstrong.com

Re: What bug reports are for

[Russ Allbery]

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

I completely disagree.  And that's also an informed opinion.  :)

> What it usually happens (at least in my experience) is that too long a
> bug list hurts the ego of the one that think of himself as being
> responsible for that so we, being humans the way we are, feel a strong
> inclination to "resolve" it by whatever means we find and being an easy
> scape path sweeping them under the carpet, that's what we'll do.

You've basically said here that everyone who disagrees with you on what
methods are practically effective in bug management is just suffering from
a bruised ego.  This comes across as condescending rather than as a
foundation for a useful discussion.

I pointed out in my previous message some of the practical problems with
leaving all the type 3 bugs active in the BTS, and in previous threads on
this topic others have pointed similar issues in considerably more depth.
If you want to convince people not to close type 3 bugs on packages where
there's no resources to deal with them, you're going to have to engage
with those arguments and understand the problems that they're trying to
solve by closing those bugs (and recognize that they *are* solving
problems, not just assuaging their egos).

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bp1uzlva@windlord.stanford.edu

Re: What bug reports are for

[Jesús M. Navarro]

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
> > > paid support. Bug reports are here to help improving the distribution.
> > 
> > Good to know.
> > 
> > Is *that* Debian's official position?  That the bug report system is
> > not there to offer a service to Debian users?
> 
> Debian doesn't have an "official position" on this question.  But I
> would guess it is the position of the vast majority of Debian's
> maintainers.
> 
> This has been standard wisdom for Free Software for decades now.  See
> for example this extract from the GNU "Information for Maintainers"
> document:
> 
>   The main purpose of bug reports is to help you contribute to the
>   community by improving the next version of the program. Many of the
>   people who report bugs don't realize this-they think that the point is
>   for you to help them individually. Some will ask you to focus on that
>   instead of on making the program better. If you comply with their
>   wishes, you will have been distracted from the job of maintaining the
>   program.
> 
>   ...
> 
>   When people ask you to put your time into helping them use the
>   program, it may seem "helpful" to do what they ask. But it is much
>   less helpful than improving the program, which is the maintainer's
>   real job.

Please pay attention that those are related to upstream maintainers, not 
developers; it is doubtful that it can be of application to packagers, since 
packager's self-appointed duty is for the software to be easily accesable and 
integrated for the user (were it not the case, the end user could simply take 
the tarball directly from the developer).

And with regards of Debian and the thread at hand, maybe there's not an 
official 
position on what the bug tracking system exactly is for but certainly there's 
quite an interesting document you may have some notice of: Debian Social 
Contract, points 3 and 4.

(/me fastly ducks away after having the balls of telling *that* to Ian Jackson 
no less)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103012024.36619.jesus.nava...@undominio.net

Re: enable/disable flags in /etc/default

[Olaf van der Spek]

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.d, without having the changes lost the next
> time the package is upgraded.  i mean, it's not even that great for
> maintainer scripts, as evidenced by the total inconsistency for how
> developers are managing enabling/disabling of their services.

Isn't that handled by DH for simple cases?

-- 
Olaf


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTinPMkd44DNhmiE=1uP4NWsC56T4Z=avxvmt5...@mail.gmail.com

Re: What bug reports are for

[Neil Williams]

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
> > > debug this. If user don't know how to debug this, his bug report
> > > will be closed without reassigning to proper package. Hence this
> > > investigation should be done by maintainer, not user.
> > 
> > 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.
> 
> Good to know.
> 
> Is *that* Debian's official position?  That the bug report system is
> not there to offer a service to Debian users?

Service != support.

Debian and Debian systems like the BTS are there to support users and
to support Debian, that's clear in the Social Contract but that does not
mean that Debian provides a contractual service of any kind. Support is
one thing but all such support comes from volunteers and there is no
"customer service", no "service contract", no warranties, no guarantees.
Volunteers do what they can in their own free time. There's no room
there for formal services to users or anyone else.

If you want a service contract, find a GNU/Linux distribution capable
of supplying one, it is not Debian. Debian exists to support users, not
enter a service contract with users.

http://www.debian.org/social_contract

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpt17MUrPGJn.pgp
Description: PGP signature

Re: What bug reports are for

[Jesús M. Navarro]

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 bugs in their
> packages. The service to users comes from the BTS enabling maintainers
> to fix their bugs.
> 
> While it's certainly not optimal, closing bugs which are
> unreproducible or incomplete are sometimes necessary because we do not
> have an infinite amount of maintainers to fix bugs.

Certainly my fault for not being able to make myself clear enough: of course 
it's OK to close unreproducible/incomplete bugs, specially if the bug tracking 
system allows to close them as such.  But only after due dilligence to really 
be able to asses them as such.

I.e.: I don't have any problem with a bug being answered by its maintainer in 
a line something like "in order to be able to reproduce this bug I need you to 
provide me with foo and bar.  Failing that I'll close it in 30 days with Zoot 
status" (of course being "foo and bar" something sensible, not just a way to 
take it from over my roof).

> If there are
> people who feel strongly about helping to get these unreproducible or
> incomplete bugs in a state where someone can actually resolve them,
> then please, form a crew, and start working on them. Feel free to let
> ow...@bugs.debian.org know how you want to know about these bugs if
> you need some additional features in the BTS. We certainly could use
> more bug triagers.

That's a worthy idea.  I'll take a time to think about it.

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103012033.59513.jesus.nava...@undominio.net

Re: What bug reports are for

[Jesús M. Navarro]

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 just an opinion
> > nevertheless) that there's no thing such too long a bug list.
> 
> I completely disagree.  And that's also an informed opinion.  :)
> 
> > What it usually happens (at least in my experience) is that too long a
> > bug list hurts the ego of the one that think of himself as being
> > responsible for that so we, being humans the way we are, feel a strong
> > inclination to "resolve" it by whatever means we find and being an easy
> > scape path sweeping them under the carpet, that's what we'll do.
> 
> You've basically said here that everyone who disagrees with you on what
> methods are practically effective in bug management is just suffering from
> a bruised ego.  This comes across as condescending rather than as a
> foundation for a useful discussion.

If that's what I said, then take it for deleted.

What I *tried* to say, is that I've been there, I've felt my ego hurted, and 
after lenghty conversations with those working under my responsibility more 
times than not that was the case too.  And after assesing that as the main 
problem we were able to find ways for better issue management both for those 
filling the issues and those having to deal with them.

> I pointed out in my previous message some of the practical problems with
> leaving all the type 3 bugs active in the BTS

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 it be untouched) and telling that longer opened 
bug lists take more overhead to deal with (which is not something my 
experience can relate to -not at least in any significant manner).

> , and in previous threads on
> this topic others have pointed similar issues in considerably more depth.

Well, I'll have to re-read those threads then since that's not what I can 
remember of them right now.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103012052.41404.jesus.nava...@undominio.net

Re: building crafty (non-free) automagically

[Oliver Korff]

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

OK, I didn't know. Will there be auto-builders for non-free in the future?

>> On: armel the message is: Not-For-Us, so I assume, that crafty is banned
>> here.
> 
> There you'd want to mail armel@buildd for a nfu drop, if you think it's
> buildable on that arch.  (nfu indicates that at one point it didn't.)

I did as you suggested.

> In general debian-wb-team@lists.d.o sounds like a better contact address
> than d-devel@.  The page you linked shouldn't be used anymore[*],
> instead https://buildd.debian.org/status/package.php?p=crafty also has
> the right contact address (albeit it talks about the (web) pages only,
> I think that should be fixed).

I always use the PTS and this links first to

https://buildd.debian.org/pkg.cgi?pkg=crafty

and only as the second link to:

https://buildd.debian.org/status/package.php?p=crafty

Thanks for the quick reply,

Oliver


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6d5322.2030...@linuxchess.org

Re: What bug reports are for

[Russ Allbery]

"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 it be untouched)

That wasn't the part that I was referring to; that's a different part of
the analysis.  (However, I believe you're wrong in your contention that a
bug triager can only estimate the work/benefit ratio after studying the
bug in depth.)

> and telling that longer opened bug lists take more overhead to deal with
> (which is not something my experience can relate to -not at least in any
> significant manner).

Your experience doesn't match the experience of many other people who have
posted to these threads.  I think you're going to have to show us the
details of what we're doing wrong.  :)

I also mentioned the affect of long bug lists on increased duplicate bug
filings via reportbug, which I've noticed and which can have significant
impact (particularly on the annoyance factor of duplicate bugs).

There was rather extensive discussion earlier with lots more examples in
one of the other threads (we've had lots) about this topic.  I thought you
were also participating them, but I could be misremembering.

Some of these may be technical issues with the BTS that could be
resolvable by making it easier to stick bugs into an easily-ignored
bucket, but one of the points that has been raised in the past is that
it's very unclear to many of us that sticking bugs into a bucket that, in
practice, guarantees no one will look at them within the next five years
is actually doing our users any favors over simply closing the bug.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5aqy3m2@windlord.stanford.edu

Re: building crafty (non-free) automagically

[Adam Borowski]

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" (see mips*) and "there are no non-free
> > autobuilders for $arch" (see the others).
> 
> OK, I didn't know. Will there be auto-builders for non-free in the future?

I wouldn't hold my breath.

If you care enough, you can use qemu to build and test them yourself.
Not sure if there are newer images around, but you can use these:

http://people.debian.org/~aurel32/qemu/

and upgrade from lenny.


-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110301210937.ga23...@angband.pl

Re: Are circular dependencies inside a source package OK?

[Dominique Dumont]

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

Correct me if I'm wrong, but ruby1.8-foo, ruby1.9.1-foo, jruby-foo are not 
broken without ruby-foo, they're just useless. So this may be interpreted as 
not being a dependency.

Moreover, I have the impression that any ruby package needing foo 
*functionality* will depend on ruby-foo and not on any arch/interpreter 
specific package. In this case the dependency between ruby1.8-foo, ruby1.9.1-
foo, jruby-foo, rubinius-foo will probably never be actually used ..

Thoughts ?

HTH

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103012235.46134.domi.dum...@free.fr

Re: re buildd's resolver and package's build deps

[Wouter Verhelst]

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 defines the allowed syntax for
> > > Build-Depends.  It does not however, make any mention of existing
> > > conventions and best practices, which I feel should be addressed.
> > > 
> > > The current "internal" build dependency resolver does not make
> > > any use of the alternative dependencies.  It always picks the first.
> > 
> > It was my understanding that there are some corner cases in which it
> > would select the second:
> > 
> > - where one build-dependency (indirectly) depends on a secondly-listed
> >   alternative, it could install the second.
> > - sbuild will not worry about installing the first alternative if the
> >   second has already been installed.
> > 
> > but I might be mistaken about one or both of the above.
> 
> I'm not totally sure either, to be honest.  The internal resolver code
> is horrible.

Yeah, I know -- I've written a patch for experimental support once, and
it took me several days just to figure out where to add two characters,
or some such...

> It looks like it still has relics of manual source-deps entangled in
> there as well (but I don't dare to touch it since it will probably
> break horribly if I delete it).  The alternatives processing is in
> Sbuild::InternalResolver::parse_one_srcdep and filter_dependencies,
> and it looks like it could well be OK with second alternatives if
> installed.

Right, so I probably wasn't dreaming that up, then.

Not that it matters all that much.

> > At any rate, if a maintainer would wish to support backports easily
> > (ever more relevant now that it's on debian.org systems), having
> > alternative build-dependencies would make perfect sense; in those cases,
> > sbuild would need to pick one set of dependencies for unstable, and the
> > second set for backports.
> 
> Agreed.  Note that we now support strict 'first-only' alternatives
> handling with the 'apt' and 'aptitude' resolvers.  See the notes for
> 0.60.0 and 0.60.1 pertaining to resolvers here:
> 
> http://git.debian.org/?p=buildd-tools/sbuild.git;a=blob;f=NEWS;h=f4576f0e3b3c0fcd66abcd93898697246b9a;hb=HEAD
> 
> We have made the alternative resolving configurable, so that you can
> use strict 'first only' or all alternatives.  It defaults to
> 'first only', which will give resolution almost entirely like the
> internal resolver.

Good.

> > True, but the right solution for this problem is not to remove support
> > for alternative build-dependencies; instead, policy should make it clear
> > that when a package is built in unstable, no differences in alternatives
> > should cause a change in functionality or support for file formats.
> 
> Please see #614807: debian-policy: Please document autobuilder-imposed
> build-dependency alternative restrictions, which is the current
> proposal for documenting the existing behaviour (and it does preserve
> the ability for maintainers to use alternatives).  Comments would be
> appreciated.

I'll have a look.

> > > I would recommend keeping backports on a separate VCS branch rather than
> > > having a single unified package.
> > 
> > I vehemently disagree with this recommendation. It works now, properly;
> > what you suggest requires merging branches every time you wish to update
> > the package. That introduces an extra maintenance burden for, IMHO, no
> > good reason.
> 
> I've been doing this on e.g. a 'lenny-backports' branch, and it's been
> a model of simplicity.  I just 'git merge ' and it's done
> except for updating the changelog (and fixing up the rare conflict).
> 
> http://git.debian.org/?p=buildd-tools/schroot.git;a=shortlog;h=refs/heads/schroot-lenny-backport
> 
> Certainly more reliable and convenient than doing things by hand.

Sure. I'm not saying you shouldn't work on a separate branch if that
works for you. But the mere fact that it works for you does not have to
mean that it will work for everyone, and enforcing that for no
particularly good reason does not sound like a good option to me.

(anyway, that's moot, given your solution)

[...]
> > > The need for concrete|virtual is a fundamental deficiency in our
> > > package management that's been unaddressed for years (see old -devel
> > > discussions).
> > 
> > Pointer?
> 
> The one I could find:
> http://lists.debian.org/debian-devel/2006/08/msg01281.html
> 
> An ancient proposed solution (probably suboptimal):
> http://people.debian.org/~rleigh/virtual-policy_1.dsc
> 
> AJ did say back then (though I can't find the mail, sorry), that he was
> working on a solution, but I don't know what happened to that.
> 
> The main issue here is that every package with a "concrete|virtual"
> alternative dep is specifying its own idea of what the ideal
> concrete package should be.  

Re: building crafty (non-free) automagically

[Wouter Verhelst]

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 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 others).
> > 
> > OK, I didn't know. Will there be auto-builders for non-free in the future?
> 
> I wouldn't hold my breath.
> 
> If you care enough, you can use qemu to build and test them yourself.

... or you can acquire the necessary hardware and set up a non-free buildd
yourself. I'm sure that'd be welcome.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110301225244.gc3...@celtic.nixsys.be

Re: enable/disable flags in /etc/default

[Stig Sandbeck Mathisen]

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 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
starting and stopping services, enabling and disabling services when
booting, installing and upgrading, and setting a global policy for what
the initial status of an installed service should be.

The end user wants to select which services start at boot, and also
directly control (start,stop,restart,status,foo,bar) services,
regardless of whether the service is set to be started at boot.

Having the enable/disable functionality inside the /etc/default/example
script ensures that the service does not start in any case, not even
when started manually, or from another service manager. Just this fact
would make it a poor solution.

The package maintainer scripts will need a way to stop a service on
uninstall or upgrade, and start after configuration, unless prevented by
policy-rc.d.

Currently, our packaged services start automatically, unless explicitly
disabled in /etc/default/, or by missing configuration. 

Compare this to the policy of RHEL, which does not enable or start its
services on package install.

A RHEL service can be started manually, but will not be started at
system boot unless explicitly configured to do so with "chkconfig".

What I'd like to be able to do, is to set a policy after system install,
and have all packages _obey_ this policy. :)

-- 
Stig Sandbeck Mathisen
  ooo, shiny!


pgpWObDPnfscO.pgp
Description: PGP signature

Re: enable/disable flags in /etc/default

[Russ Allbery]

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
> starting and stopping services, enabling and disabling services when
> booting, installing and upgrading, and setting a global policy for what
> the initial status of an installed service should be.

Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
variables in some of my packages, I think you have the order reversed
here.  I agree that those settings are horrible, but as horrible as they
are, they're less weird than our current user interface for disabling init
scripts.  (Users have at least a hope of finding it, which is not really
true in my experience of the init method at present.)  I'm therefore not
inclined to remove them until we provide a non-horrible user interface
that can really replace them.

Once there's a good general solution, I'll be happy to remove any
package-specific hacks in favor of taking advantage of it.

> What I'd like to be able to do, is to set a policy after system install,
> and have all packages _obey_ this policy. :)

Yup, I think that's the right order.  :)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd02v357@windlord.stanford.edu

Re: Potential memory leaks reported by Valgrind against some frequently used commands

[Ron Johnson]

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d6dadb2.4010...@cox.net

Re: enable/disable flags in /etc/default

[Raphael Geissert]

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 what *is* the proper UI?

Interesting that everyone talks about update-rc.d but it appears that nobody 
has read its documentation:

> A common system administration error is to delete the links with
> the thought that this will "disable" the service, i.e., that this will
> prevent the service from being started.  However, if all links have
> been deleted then the next time the package is upgraded, the package's  
> postinst script will run update-rc.d again and this will reinstall links
> at their factory default locations.  The correctc way to disable
> services is to configure the service as stopped in all runlevels in
> which it is started by default.  In the System V init system this means 
> renaming the service's symbolic links from S to K.

That means:
# mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2
# insserv # this bit is not documented, it seems

And that's it, apache2 won't be started on runlevel 2.

Want to enable it again? make it an S and run insserv (so that the link's 
number and makefile-like list is updated)

Want to start it on that runlevel? "service apache2 start"

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ikkda7$9qi$1...@dough.gmane.org

Re: enable/disable flags in /etc/default

[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 something the next time update-rc.d is run.)

No, it doesn't.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/ikkdae$9qi$2...@dough.gmane.org

Re: potential MBF: first alternate depends not available in main

[Scott Kitterman]

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
> timeout is only available in lenny and etch, thus piuparts cannot test
> secvpn in squeeze, wheezy and sid. That's a bug in piuparts.
> 
> Another popular example is a depends on "apache | apache2"...
> 
> So I think it's also a bug in those packages, of which there are more then
> 100 but less than 200.
> (To my regret I have to admit there is another bug in piuparts and
> http://piuparts.debian.org/sid/state-dependency-does-not-exist.html lists a
> few packages incorrectly.)
> 
> But, anyway, I believe that the first depends of an alternate depends
> relation should be available in main and propose to file bugs about this.
> 
> Do you agree this warrants a mass bug filing? I couldn't find this written
> out in policy so these bugs would be wishlist, which probably would make
> them not warrant a mass bug filing...
> 
> Comments?

It seems to me not worth a mass bug filing.  This doesn't seem like something 
that would affect user's systems.  Is there a rationale for imposing this 
ordering other than puiparts can't deal with it?

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103012324.24545.deb...@kitterman.com

Re: Potential memory leaks reported by Valgrind against some frequently used commands

[sean finney]

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

given that RH9 is like what, 10 years old, i'd think that it's just as
likely that the utilities just weren't leaky at the time.


sean


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302064339.ga27...@cobija.connexer.com

Re: Potential memory leaks reported by Valgrind against some frequently used commands

[Adrian von Bidder]

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 determining them worthwhile?

Or is it an eglibc <> libc issue? (Not sure what libc RH is using.)


-- vbi


-- 
Vertrauen ist gut.  Anwalt ist saugeil.


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

Re: enable/disable flags in /etc/default

[Tollef Fog Heen]

]] 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 something the next time update-rc.d is run.)
| 
| No, it doesn't.

Oh, indeed, it just ignores the fact that a required service is disabled
without warning.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3maou4o@qurzaw.varnish-software.com