On Fri, Feb 25, 2011 at 09:29:01PM -0600, Steve M. Robbins wrote:
> Hi,
>
> The buildd system is generally quite fabulous, but why does
> https://buildd.debian.org/build.cgi?pkg=insighttoolkit show version
> 3.8.0-1? This version is neither sid, not stable, nor oldstable.
I'm not involved with t
On Sat, Feb 26, 2011 at 10:05:44AM +, Roger Leigh wrote:
> On Fri, Feb 25, 2011 at 09:29:01PM -0600, Steve M. Robbins wrote:
> > Hi,
> >
> > The buildd system is generally quite fabulous, but why does
> > https://buildd.debian.org/build.cgi?pkg=insighttoolkit show version
> > 3.8.0-1? This ve
On Fri, Feb 25, 2011 at 11:43:50AM +0100, Tollef Fog Heen wrote:
> ]] Timo Weingärtner
>
> | service (8) does that already.
>
> The right way to do this is, IMNSHO, what systemd does and just have
> init handle starting and stopping the job. That ensures there's no
> inconsistency between boot-
On Fri, Feb 25, 2011 at 9:55 AM, Peter Palfrader wrote:
> We should probably start a campaign in Debian to have all init scripts
> sanitize the environment of daemons they start.
>
> I usually run initscripts using "env -i /etc/init.d/$foo start" to
> achieve exactly that, but ideally the init scr
Timo Weingärtner wrote:
>> Maybe start-stop-daemon should have an option to delete all but a
>> specified set of environment variables, maybe even enabled by default.
>
> service (8) does that already.
Exactly, and it is supposed to be the interface used by humans to
start/stop/etc services sinc
Hello guys.
I've filed a bug on reportbug, but its maintainer ignores it, and continues
to close it without any troubleshooting or debug. I did a simple
troubleshooting by myself, but maintainer ignored it and closed the bug
again. With whom I can talk about this strange situation? The bug itself:
Yves-Alexis Perez wrote:
> On Wed, 2011-02-23 at 22:47 -0600, Raphael Geissert wrote:
>> As a consequence of these changes, the new Lintian release will cause
>> many existing overrides to no longer apply. We recognise that this will
>> lead to some noise in the short term but are convinced that
On Sat, 26 Feb 2011 17:52:02 +0200 Dmitry Baryshev wrote:
> Hello guys.
>
> I've filed a bug on reportbug, but its maintainer ignores it, and continues
> to close it without any troubleshooting or debug. I did a simple
> troubleshooting by myself, but maintainer ignored it and closed the bug
> ag
On Sat, 2011-02-26 at 14:32 +0100, Michael Banck wrote:
> >
> > The right way to do this is, IMNSHO, what systemd does and just have
> > init handle starting and stopping the job. That ensures there's no
> > inconsistency between boot-time starting and starting later by hand.
>
> Right, but it m
On Sat, Feb 26, 2011 at 05:54:23PM +0100, Sean Finney wrote:
> On Sat, 2011-02-26 at 14:32 +0100, Michael Banck wrote:
> > >
> > > The right way to do this is, IMNSHO, what systemd does and just have
> > > init handle starting and stopping the job. That ensures there's no
> > > inconsistency betw
* Simon Josefsson schrieb:
> Wookey writes:
>
> > At this points it calls the linker and adds -L/usr/lib on the front -
> > thereby adding this path in front of the default cross-compiler path.
>
> Please try to debug where the -L/usr/lib comes from, I don't believe
> libtool is adding this by
Hi,
On Sat, Feb 26, 2011 at 11:45:46AM -0500, Michael Gilbert wrote:
> On Sat, 26 Feb 2011 17:52:02 +0200 Dmitry Baryshev wrote:
>
> > Hello guys.
> >
> > I've filed a bug on reportbug, but its maintainer ignores it,
No maintainer did not ignore it. He responded reasonably.
> and continues
[ adding -qa for the neglected-packages-busting part ]
On Fri, Feb 25, 2011 at 03:59:33PM +0100, Stefano Zacchiroli wrote:
> My own reading of this thread is that we can go ahead with this MBF.
> You can find attached the template and actual package list, ready for
> mass-bug invocation. Barring n
Package: general
Severity: grave
Justification: renders package unusable
Some programs can not start because of missing libtiff.so.3 file.
I found libtiff.so.3 dependencies in this files on my system:
/usr/bin/gnuplot
/usr/bin/xfe
/usr/bin/xfview
/usr/bin/xfwrite
/usr/bin/multiget
/usr/bin/xfi
Processing commands for cont...@bugs.debian.org:
> severity 615476 important
Bug #615476 [general] general: many binaries are linked with non-existent
libtiff.so.3 library
Severity set to 'important' from 'grave'
> tag 615476 + unreproducible
Bug #615476 [general] general: many binaries are link
severity 615476 important
tag 615476 + unreproducible
thanks
On Sat, 2011-02-26 at 21:25 +0300, sergey wrote:
> Some programs can not start because of missing libtiff.so.3 file.
I suspect this is a local problem, as none of the packages in question
depends on libtiff at all; I'm therefore lowerin
Am Samstag 26 Februar 2011, 18:50:41 schrieb Osamu Aoki:
> > It looks like its an issue with your choice of .gtkrc files.
I really do not recommend the setting in KDE to influence the themes of GTK
programs. For me, it makes iceweasel using 100% _after_ closing it. It drove
me almost nuts on my
* Osamu Aoki , 2011-02-27, 02:50:
I've filed a bug on reportbug, but its maintainer ignores it,
No maintainer did not ignore it. He responded reasonably.
He did not. Declaring "it's not a bug in my package" without even trying
to diagnose the problem is not only unreasonable but also rude.
On 02/26/2011 12:43 PM, Adam D. Barratt wrote:
severity 615476 important
tag 615476 + unreproducible
thanks
On Sat, 2011-02-26 at 21:25 +0300, sergey wrote:
Some programs can not start because of missing libtiff.so.3 file.
I suspect this is a local problem, as none of the packages in question
perl has had a long-outstanding bug, #230308, concerning packages,
particularly long-running daemons, breaking on a major perl upgrade.
This is a similar situation to libc6, which currently has a debconf
prompt asking the local administrator for permission to restart related
daemons.
The preferred
On Sat, 2011-02-26 at 13:08 -0600, Ron Johnson wrote:
> > On Sat, 2011-02-26 at 21:25 +0300, sergey wrote:
> >> Some programs can not start because of missing libtiff.so.3 file.
> >
> > I suspect this is a local problem, as none of the packages in question
> > depends on libtiff at all; I'm therefo
]] Harald Dunkel
(This is from bug #602490, but it's more of a generic problem)
| Would it be possible to add an "enable" flag to
| /etc/default/nagios3 to control if the daemon is
| started at boot time?
I'd like us to decide on a policy about enable/disable flags in
/etc/default in general.
Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum
* Package name: simgrid
Version : 3.5
Upstream Author : Simgrid core team
* URL : http://simgrid.gforge.inria.fr/
* License : LGPL
Programming Lang: C
Description : Toolkit for scalable simulation o
On Sat, Feb 26, 2011 at 09:44:07PM +0100, Tollef Fog Heen wrote:
> ]] Harald Dunkel
>
> (This is from bug #602490, but it's more of a generic problem)
>
> | Would it be possible to add an "enable" flag to
> | /etc/default/nagios3 to control if the daemon is
> | started at boot time?
>
> I'd lik
On Sat, 2011-02-26 at 21:44 +0100, Tollef Fog Heen wrote:
> I'd like us to decide on a policy about enable/disable flags in
> /etc/default in general. Either all daemons should have them or no
> daemons should have them, and if we have them, I think we should have
> the value in the default file s
Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber
* Package name: libtest-cpan-meta-yaml-perl
Version : 0.17
Upstream Author : Barbie
* URL : http://search.cpan.org/dist/Test-CPAN-Meta-YAML/
* License : Perl
Programming Lang: Perl
Description :
On Feb 26, 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 mes
Hi,
On Sat, Feb 26, 2011 at 07:41:18PM +0100, Jakub Wilk wrote:
> * Osamu Aoki , 2011-02-27, 02:50:
> >>>I've filed a bug on reportbug, but its maintainer ignores it,
> >
> >No maintainer did not ignore it. He responded reasonably.
>
> He did not. Declaring "it's not a bug in my package" withou
On Sat, 26 Feb 2011 21:05:19 -0500 (EST), Osamu Aoki wrote:
> On Sat, Feb 26, 2011 at 07:41:18PM +0100, Jakub Wilk wrote:
>> Yes, ideally one should also be omniscient...
>
> I am not sure what is "omniscient".
> ...
I hope this does not sound too patronizing, Osamu; but since
English is not your
Aren't there any checks in place to prevent a package from becoming
uninstallable?
E.g., bug #615530, #615528.
--
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/8762s5j
30 matches
Mail list logo
