On su, 2011-02-27 at 15:49 +0800, jida...@jidanni.org wrote:
> Aren't there any checks in place to prevent a package from becoming
> uninstallable?
> E.g., bug #615530, #615528.
We don't care if something is temporarily uninstallable in unstable. The
only way to prevent that from happening would
On Sun, Feb 27, 2011 at 4:02 PM, Lars Wirzenius wrote:
> We don't care if something is temporarily uninstallable in unstable. The
> only way to prevent that from happening would be to keep packages from
> entering unstable unless all their dependencies are in unstable already,
> and that would pr
On Du, 27 feb 11, 16:15:40, Paul Wise wrote:
>
> Something that might work would be to keep the old source/binary
> packages around (as well as the new ones) until nothing depends on
> them. IIRC the release team have the ability to (temporarily) have
> multiple versions of a source package in tes
Well OK, but can't the package owners get a friendly mail once a day
"yoo hoo Holmes, your package is now broken", lest they relax at the
beach totally unaware one day Auntie Nelda might suddenly have the urge
to use their package in a hurry?
--
To UNSUBSCRIBE, email to debian-devel-requ...@list
On Sun, Feb 27, 2011 at 04:42:28PM +0800, jida...@jidanni.org wrote:
> Well OK, but can't the package owners get a friendly mail once a day
> "yoo hoo Holmes, your package is now broken", lest they relax at the
> beach totally unaware one day Auntie Nelda might suddenly have the urge
> to use their
On Sun, Feb 27, 2011 at 03:49:43PM +0800, jida...@jidanni.org wrote:
> Aren't there any checks in place to prevent a package from becoming
> uninstallable? E.g., bug #615530, #615528.
We have tool to detect that and we periodically monitor the
uninstallable packages in the various suites using ed
On 2011-02-27, Paul Wise wrote:
> On Sun, Feb 27, 2011 at 4:02 PM, Lars Wirzenius wrote:
>> We don't care if something is temporarily uninstallable in unstable. The
>> only way to prevent that from happening would be to keep packages from
>> entering unstable unless all their dependencies are in
Processing commands for cont...@bugs.debian.org:
> reassign 615153 general
Bug #615153 [other] exec: 58: /usr: Permission denied
Warning: Unknown package 'other'
Bug reassigned from package 'other' to 'general'.
> --
Stopping processing here.
Please contact me if you need assistance.
--
615153:
Is it possible that this problem exists because I have some old programs in
/usr/local that I moved from my previous Slackware system?
I have no gnuplot in /usr/local/bin.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact lis
Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber
* Package name: libio-handle-util-perl
Version : 0.01
Upstream Author : Yuval Kogman
* URL : http://search.cpan.org/dist/IO-Handle-Util/
* License : Perl
Programming Lang: Perl
Description : IO::
jida...@jidanni.org writes:
> Well OK, but can't the package owners get a friendly mail once a day
> "yoo hoo Holmes, your package is now broken"
They can monitor the package's QA page.
> lest they relax at the beach totally unaware one day Auntie Nelda
> might suddenly have the urge to use thei
2011/2/27 Osamu Aoki
> 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. Declarin
On Saturday 26 February 2011 21.44:07 Tollef Fog Heen wrote:
> I'd like us to decide on a policy about enable/disable flags in
> /etc/default in general.
+1 on those who don't like to have them.
The init scripts (or whatever) need to
* provide a sane default for startup order
* allow users to
2011/2/26 Osamu Aoki
> 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 r
Hi,
there are a number of NMUs currently in the delayed queue, adding armhf
support to some packages. The bugs referenced in those uploads have
seen no notification of any such upload, and no NMU diff has been sent.
Please fix this. And in the future, do that before you upload, per
http://www.de
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 do
On Sun, 2011-02-27 at 14:33 +0300, sergey wrote:
> Is it possible that this problem exists because I have some old
> programs in /usr/local that I moved from my previous Slackware system?
Yes, I suspect that's the problem; specifically:
/usr/local/lib/libwx_gtk2u_core-2.8.so.0:
The version of th
Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers
* Package name: lightdm
Version : 0.2.3
Upstream Author : Robert Ancell
* URL : https://launchpad.net/lightdm
* License : GPL-3
Programming Lang: C/
Description : simple display manager wi
At http://www.debian.org/Bugs/Reporting is is said that we should not send
bugs to program authors, but to only Debian BTS. Imagine some system service
reads configuration file, and has critical bug in parsing it. User cannot
debug this. Maintainer closes this bug report with explanation "this is a
Hi,
In the pkg-ruby-extras team, we are currently discussing some big
changes in our packaging tools.
A problem arises for libraries that have a large
architecture-independent part that can be shared between the various
implementations of ruby interpreters (ruby1.8, ruby1.9.1, jruby,
rubinius), b
[Lucas Nussbaum]
> 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
I also reported this problem to gnuplot's maintainers as bug #615289 before I
found how many programs is depend on libtiff.so.3 on my system.
With Julien's help I have discovered that gnuplot gets dependencies from old
libraries in /usr/local:
$ ldd /usr/bin/gnuplot | grep /usr/local
l
On Sun, 27 Feb 2011 15:02:36 +
"Adam D. Barratt" wrote:
> On Sun, 2011-02-27 at 14:33 +0300, sergey wrote:
> > Is it possible that this problem exists because I have some old
> > programs in /usr/local that I moved from my previous Slackware system?
>
> Yes, I suspect that's the problem; spe
Hello,
2011/2/15 Gerrit Pape :
> Hi, I'm looking for a new maintainer for the dietlibc package.
I would be interested to help out and co-maintain it within some team.
Best regards,
--
Héctor Orón
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will
Le dimanche 27 février 2011 à 16:31 +0100, Lucas Nussbaum a écrit :
> 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 f
Le dimanche 27 février 2011 à 17:00 +0100, Matthias Klose a écrit :
> Fix build failures with ld --as-needed
> - --
>
> [Note this is not turned on by default]
>
> Many packages fail to build when the linker is passed --as-needed as the
> default. These issue
On Sat, Feb 19, 2011 at 10:49 AM, Olaf van der Spek
wrote:
> On Fri, Feb 18, 2011 at 9:19 AM, Stephen Gran wrote:
>> I don't want to prolong this thread, but this seemed useful to answer.
>>
>> I certainly have no intention of changing the default on my own.
>
> Could you at least fix the origina
* Loïc Minier schrieb:
> On Thu, Feb 10, 2011, Wookey wrote:
> > Loic Minier in October last year, to libtool list
> > http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7626
> > (response: yes that seems to be a bug, no time to fix now, does sysroot
> > option fix it? 'Not for me' said lool)
>
Hi.
sergey (27/02/2011):
> Is it normal that Debian's programs in my system gets dependencies
> from non-Debian libraries?
Phrased otherwise, it's normal to get to look into /usr/local/lib
since that's the linker's configuration, see /etc/ld.so.conf.d/libc.conf
(which has a comment about its bei
Hi,
On Sun, Feb 27, 2011 at 1:00 PM, Matthias Klose wrote:
[...]
> The latter change is described in [1] (section [2]). To summarize: If a
> library
> symbol is directly used by an object without explicitly linking this library,
> the link step now fails. The fix is to pass the library explict
On Sun, Feb 27, 2011 at 7:45 PM, Fernando Lemos wrote:
> Those are valid points, of course, but many Boost projects will fail
> to build now and I see no good solution[1][2][3]. Some libraries like
I do: http://en.wikipedia.org/wiki/Auto-linking
First has to be implemented in GCC though.
--
Ol
Olaf,
On Sun, Feb 27, 2011 at 3:54 PM, Olaf van der Spek wrote:
> On Sun, Feb 27, 2011 at 7:45 PM, Fernando Lemos wrote:
>> Those are valid points, of course, but many Boost projects will fail
>> to build now and I see no good solution[1][2][3]. Some libraries like
>
> I do: http://en.wikipedia.
Package: wnpp
Severity: wishlist
Owner: Jan Dittberner
* Package name: setuptools-git
Version : 0.3.4
Upstream Author : Yannick Gingras
* URL : http://pypi.python.org/pypi/setuptools-git/
* License : Public Domain
Programming Lang: Python
Description
Hello,
testing with the version from experimental yielded the following additional
messages compared to unstable (all overrides were correctly detected).
W: openswan-doc: spelling-error-in-readme-debian allows to allows one to
W: openswan-modules-source: spelling-error-in-readme-debian allows to
Thank you for detailed explanation.
Please note that most software that is not included in Debian are distributed
in source tarballs. Most of this software installs to /usr/local by default now.
(You type configure && make && make install - and program installed)
So, default way is dangerous way
Hello,
2011/2/27 Julien Cristau :
> there are a number of NMUs currently in the delayed queue, adding armhf
> support to some packages. The bugs referenced in those uploads have
> seen no notification of any such upload, and no NMU diff has been sent.
> Please fix this. And in the future, do th
Processing commands for cont...@bugs.debian.org:
> close 615476
Bug#615476: general: many binaries are linked with non-existent libtiff.so.3
library
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to sergey
> thanks
Stopping pro
[removing most CCs and setting reply to -devel]
Hi,
On Sunday 27 February 2011 14:21:25 Hector Oron wrote:
> 2011/2/27 Julien Cristau :
> > there are a number of NMUs currently in the delayed queue, adding armhf
> > support to some packages. The bugs referenced in those uploads have
> > seen no
On Sun, Feb 27, 2011 at 08:21:25PM +, Hector Oron wrote:
> I do really apologize in case we have miss something, we'll try to do
> better next time.
Thanks for this followup Hector.
FWIW, no one said those NMUs were not welcome and it's in fact nice to
see you're pushing for armhf. Julien's (
On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
> If you ask me, I would say that providing a magic for file(1) as I said on
> debian-arm[1] would be more useful that NMUing a few hanging fruits.
> Lintian will annoy people with one tag per ELF object otherwise.
Um, that'll be a
Steve Langasek wrote:
> On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
>> If you ask me, I would say that providing a magic for file(1) as I said
>> on debian-arm[1] would be more useful that NMUing a few hanging fruits.
>> Lintian will annoy people with one tag per ELF object o
On Sun, Feb 27, 2011 at 03:29:05PM -0600, Raphael Geissert wrote:
> Steve Langasek wrote:
> > On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
> >> If you ask me, I would say that providing a magic for file(1) as I said
> >> on debian-arm[1] would be more useful that NMUing a few
[sergey]
> It is a good reason to think about Debian's (or GNU/Linux) usability and
> ways to increase it.
>
> It all was about installing software system-wide by administrator.
Well, putting /usr/local/lib in the default library search path, and
upstream software using /usr/local/lib by default
Hello Raphael,
2011/2/27 Raphael Geissert :
>> I do really apologize in case we have miss something, we'll try to do
>> better next time.
> Let's list a few things:
> * I didn't like that there was no notification on the bug report
We note that one for next time.
IMHO, BTS should acknowledge th
On Mon, Feb 28, 2011 at 12:04 AM, Peter Samuelson wrote:
> Unfortunately (from your perspective) there is not a way to configure a
> default library search path differently for binaries in different
> places. So if you want /usr/local/bin binaries to see /usr/local/lib
> by default (that's what D
On Mon, 28 Feb 2011, Olaf van der Spek wrote:
> > places. So if you want /usr/local/bin binaries to see /usr/local/lib
> > by default (that's what Debian and other Linux systems do, on purpose),
> > then all your system binaries will see them too. Anyway, it's not a
> > bug or even really a desig
On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
wrote:
>> But there is an ordering choice. local has priority.
>
> By default, we assume the local administrator knows what he is doing.
>
> That is not going to change.
Sure. But Sergey has a good point: why are there no bin and lib in
Olaf van der Spek writes:
> On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
> wrote:
>>> But there is an ordering choice. local has priority.
>>
>> By default, we assume the local administrator knows what he is doing.
>>
>> That is not going to change.
>
> Sure. But Sergey has a goo
On Mon, 28 Feb 2011, Olaf van der Spek wrote:
> Sure. But Sergey has a good point: why are there no bin and lib inside
> /home so normal users can safely install software without risking
AFAIK, there are strong security concerns. You cannot have unprotected
directories in the default linker paths
Hi!
On Fri, 2011-02-25 at 16:59:58 +, David Banks wrote:
> Package: wnpp
> Severity: wishlist
> Owner: David Banks
>
> * Package name: quakespasm
> Version : 0.85.3
> Upstream Author : David Banks
> * URL : http://quakespasm.sourceforge.net/
> * License :
]] Hector Oron
Hi,
| > * Raising the severity doesn't really imply anything
|
| True. Would you suggest some better way to proceed with porter-NMU?
I would think it quite rushed to be pushing NMUs for an archicture not
in Debian and not even in dpkg yet. Even more so when it's not accepted
as
On Sun, 27 Feb 2011, Matthias Klose wrote:
> Unreflected usage of symbols files for C++ libraries
> -
>
> These seem to be limited to Qt and KDE related libraries.
>
> Apparently g++-4.4 did emit references to symbols defined in header files of
52 matches
Mail list logo
