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
]] 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
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 :
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
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, 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
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 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
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
[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
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
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 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
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 (
[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
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
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
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,
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
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
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.
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
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
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
* 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)
>
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
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/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
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
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::
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
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:
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
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 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
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 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
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 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
52 matches
Mail list logo
