On Tue, May 3, 2016 at 10:10 AM, Laurent Bigonville
wrote:
>
>
> Do you have a policy installed on your machine?
>
I do not - I was unable to install the latest selinux-policy-default
package from unstable due to dependency problems that I was unable to
resolve.
The following packages have unmet
Package: selinux-basics
Version: 0.5.4
Severity: grave
Justification: renders package unusable
Dear Maintainer,
Thank you for your work bringing SELinux to Debian!
I regret that my knowledge of both SELinux and systemd is limited, so I do not
know what diagnostics to collect or how to collect it
These errors are very strange indeed. I would suggest either disabling the
tests or removing this package (I have no strong feeling either way). I
could do the same in the upstream version (or pass co-maintainership to
someone else), but I guess it would be good to know what caused this
breakage in
I've been investigating this today, and it appears that the debugger is now
faulty (I am still not sure whether it is related to the bug report filed
regarding the changes in YAML).
Running the yaml.pl script manually (turning on warnings for good measure),
we get the following output:
> perl -w
Hi all,
In August 2011, gregor mentioned that we could attempt to replace
libgtk2-mozembed-perl (which is currently FTBFS) with libgtk2-webkit-perl,
which was never uploaded (since being packaged in 2009). I am wondering if
there are comments as to whether we could solve BTS#636133 by replacing
li
Hi,
I have successfully reproduced this issue in a sid chroot, and
subsequently confirmed that this issue (the immediate issue, but not
the FTBFS) can be fixed by rebuilding libgtk2-perl:
[ XS xs/GtkMozEmbed.xs ]
[ CC xs/GtkMozEmbed.c ]
In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:3
Package: libdbd-odbc-perl
Severity: grave
Tags: security
Justification: user security hole
Because of changes that Microsoft made to the ODBC specification, the previously
32-bit binary protocol now supports 64-bit values on systems that support it
(e.g.
on amd64 and possibly the ia64 architectu
Hi all,
I propose that we consider removing libjavascript-perl. It looks like
it has been failing to build for quite some time, but we have not
known because there have not been any new versions of
libjavascript-perl.
Thanks to Lucas Nussbaum, we have discovered that the package doesn't
build tod
I am able to reproduce this issue on my sid chroot. From a quick
glance at the error messages, it looks like the header files include
C++ code (namespace, new), which is unexpected when trying to link
with it in C-land...
Cheers,
Jonathan
On Mon, Jul 18, 2011 at 6:02 PM, Lucas Nussbaum
wrote:
>
To whoever might stumble upon this bug,
I looked into it quickly and it looks like libmodule-pluggable-perl has
already been removed from squeeze. I guess we need to leave this bug
here to prevent it from being migrated to testing.
Cheers,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-rc-
To whoever might stumble upon this bug,
I looked into it quickly and it looks like libfile-temp-perl has
already been removed from squeeze. I guess we need to leave this bug
here to prevent it from being migrated to testing.
Cheers,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...
Damyan,
I was initially unable to reproduce the issue because sbuild by
default does mount /home inside the chroot.
However, Salvatore told me via IRC that the buildd's are configured in
such a way that they do not have a writable home.
I don't know whether this is an issue with sbuild (though w
tag 615963 unreproducible
severity 615963 important
thanks
Hello,
I cannot reproduce this issue on my system -- downgrading to important.
Here is the build log:
aven'jon(~/pkg-perl/trunk/libvendorlib-perl)> build
Copying package data to temporary build area...
Downloading latest upstream version
block 603737 by 614067
thanks
To all interested parties:
I have requested that this package be removed from the archive. Please
see BTS#614067 for details.
This bug can be closed once 614067 is resolved.
Cheers,
Jonathan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
w
Dominic,
It looks like the dependencies might've changed recently...
who-uploads for both libogre-dev and libgtk2.0-dev give me nothing,
however:
libgtk2.0-dev | 2.20.1-2 | squeeze | amd64, armel,
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc,
s390, sparc
libg
Hi,
We've spoken to the upstream maintainers, who say that removing the
offending swfupload parts should be okay.
I'll spend some time (hopefully tonight) repacking to remove those
parts. My only concern was that swfupload should be made available in
non-free prior to the removal of those parts f
Hi,
On Sat, May 8, 2010 at 4:51 AM, Sandro Tosi wrote:
>> I think the issue has been open for long enough without clear consensus.
>> Hence all packages should rename their /usr/bin/pip to something else and
>> document the difference vs upstream in README.Debian.
>>
>> BTW, finding new names is
On Sun, Apr 18, 2010 at 3:00 PM, Ivan Kohler wrote:
> On Sun, Apr 18, 2010 at 02:42:08PM -0400, Jonathan Yu wrote:
>> On Sun, Apr 18, 2010 at 2:18 PM, Ivan Kohler wrote:
>> > So I am considering just running with libmodern-perl-perl (via pkg-perl
>> > svn) and asking f
On Sun, Apr 18, 2010 at 2:18 PM, Ivan Kohler wrote:
> Originally I had uploaded libmodern-perl-perl by accident and was
> surprised it made it through NEW. I was planning on asking for removal
> (and for libmodern-perl to be renamed to or Provide:
> libmodern-perl-perl).
>
> However it seems that
Package: libcairo-perl
Severity: grave
Justification: renders package unusable
This package seems to be unusable with the newest version of
libdirectfb.
Building Graphics::Primitive::Driver::Cairo yielded the following
test output (see libgraphics-primitive-driver-cairo-perl in the
Debian Perl G
On Tue, Feb 9, 2010 at 3:08 AM, Damyan Ivanov wrote:
> -=| Jonathan Yu, Mon, Feb 08, 2010 at 07:49:16PM -0500 |=-
>> It looks like the best way to fix this issue is to add a
>> "HAS_INTERNET" (or perhaps in this case, HAS_LOCALHOST or HAS_NETWORK)
>> style flag to d
Hi all:
I have confirmed this bug with sbuild/schroot + amd64. As with
Salvatore, I did not have the issue with x86.
I'm hesitant to apply gregoa's patch because it seems like it might
have problems where machines *cannot* left-shift 62 bits... If the
register is only 32-bits wide (as with i386 o
Hi Lucas,
Thanks for the bug report.
It looks like the best way to fix this issue is to add a
"HAS_INTERNET" (or perhaps in this case, HAS_LOCALHOST or HAS_NETWORK)
style flag to disable tests unless it is known that localhost is
available.
Cheers,
Jonathan
On Sat, Jan 9, 2010 at 5:38 AM, Luca
Lucas,
Thanks for these reports. Unfortunately, both of these have new
versions (which may or may not fix these FTBFS), except they are
themselves failing to build (which is why I haven't uploaded them
yet).
Now that this affects packages currently in the repository, we'll
prioritize them and loo
Here are some reasons why:
1. We discussed this in the ITP for libleocharre-perl [0]; the whole
idea of the LEOCHARRE:: modules is flawed in many ways, and also
exports random symbols to the 'main' namespace with no way of stopping
it from doing so.
2. The overhead involved with patching in the n
Hi:
Thank you for your bug report.
It should be noted that this module is destined for removal from
unstable and testing due to some new dependencies (LEOCHARRE::
modules) which we would rather not package. The code quality of those
files was questionable (such as dumping random things into the m
Hi:
[Cc'ing Adam Kennedy since I'm not sure if he's subscribed to debian-devel]
Since Adam mentions that Perl's pip predates Python's pip by a
significant margin, I think we should close this issue by renaming
Python's installer back to pyinstall. It doesn't seem fair for someone
who came on the
On Tue, Nov 17, 2009 at 8:59 PM, Jonathan Yu wrote:
> Hi:
>
> Recommended resolution: remove libclass-xsaccessor-array-perl from
> unstable (and thus testing). It does not exist in stable or oldstable.
>
> On Mon, Nov 16, 2009 at 11:20 AM, gregor herrmann wrote:
>> Pack
Hi:
Recommended resolution: remove libclass-xsaccessor-array-perl from
unstable (and thus testing). It does not exist in stable or oldstable.
On Mon, Nov 16, 2009 at 11:20 AM, gregor herrmann wrote:
> Package: libclass-xsaccessor-perl
> Version: 1.05-1
> Severity: serious
> Justification: upgrad
On Tue, Sep 22, 2009 at 5:46 AM, Niko Tyni wrote:
> On Tue, Sep 01, 2009 at 09:13:35PM +0200, gregor herrmann wrote:
>> On Tue, 01 Sep 2009 12:57:12 +0300, Damyan Ivanov wrote:
>>
>> > > The new upstream release 0.092280-1 doesn't FTBFS anymore.
>> > > At the moment it waits for the new (build) de
On Mon, Sep 21, 2009 at 10:41 AM, gregor herrmann wrote:
> On Mon, 21 Sep 2009 13:46:37 +0300, Niko Tyni wrote:
>
>> > JFTR: #547631 and #547628 address the same problem.
>> Lintian::Output uses multiple inheritance, and Class::Accessor introduced
>> an import subroutine in 0.34 that wins over Exp
Hi Joerg:
On Wed, Sep 2, 2009 at 3:23 AM, Joerg Jaspert wrote:
> Package: libfilehandle-unget-perl
> Severity: serious
>
> jaw...@cpan.org
> SMTP error from remote mail server after RCPT TO::
> host cpan.mx.develooper.com [207.171.7.216]: 550 the lights are out, no
> such recipient (sf)
T
Package: libmodule-cpants-analyse-perl
Version: latest unstable
Severity: grave
Justification: renders package unusable
Running a Kwalitee t est using Module::CPANTS causes this error:
t/01kwalitee.t .. cannot load Module::CPANTS::Kwalitee::Files: Can't locate
Software/LicenseUtils.pm in @IN
Perl::Critic is an author test. Sometimes authors may write tests that
are broken and not bother to fix them, because they're run only by
authors. Likely the author saw those failures while building and chose
to ignore them for one reason or another. A fix would be to provide a
perlcriticrc file wh
t the specifics of these, but I'd encourage you to
post something to the RT and get back to us if there is no activity
On Mon, Mar 30, 2009 at 9:30 PM, Jonathan Yu wrote:
> Hi:
>
> These seem like changes which should be proposed on the RT upstream.
>
> After being unmaintained
Hi:
These seem like changes which should be proposed on the RT upstream.
After being unmaintained for many months, it's now starting to get
some support and teams have been put together to take over the
project. So I encourage you to submit patches or bug reports upstream
so they can get fixed. I
36 matches
Mail list logo
