Package: pdfarranger
Version: 1.6.2-3
The debian/upstream/metadata URLs for the pdfarranger package are no
longer correct, the GitHub repo has moved. The correct URLs are now:
Bug-Database: https://github.com/pdfarranger/pdfarranger/issues
Bug-Submit:
Hi Boyuan,
Removing the package from the archive seems like the right decision
here. Upstream hasn't been updated since 2015.
Thanks for offering to ITS, though.
Allison
On Tue, 22 Jan 2019 14:45:36 + Anil Madhavapeddy
wrote:
> Dear Debian project leader (CCed), we’ve resolved the rather
> simple technical matter in this thread amicably by directly
> communicating with the upstream software projects involved.
Glad to hear it, that's the way it should be. :)
IIRC, in the OpenStack packaging sprint at DebCamp last week we agreed
to remove vmware-nsx from unstable. (The package never made it to
testing or any stable release.)
On 02/27/2017 05:34 PM, Thomas Goirand wrote:
>
> Yes, because it FTBFS as well.
Thanks Thomas. How important would you rate vmware-nsx? It's currently
removed from testing. It has no rdepends, so I'm thinking it's probably
fine to leave it out of stretch, and fix it in unstable for future
The version of the neutron package currently in unstable and stretch
(9.1.1) is incompatible with the version of vmware-nsx in unstable
(8.0.0). During the Newton release cycle, Neutron was changed to move
SecurityGroup from:
neutron.db.securitygroups_db
to:
neutron.db.models.securitygroup
For
Package: ftp.debian.org
Please remove parrot from unstable, since the upstream project is
no longer developed or maintained. It has no rdeps in the archive. This
removal includes:
libparrot-dev | 6.6.0-1+b1 | mips64el
libparrot-dev | 6.6.0-1+b2 | amd64, arm64, armel, armhf, hurd-i386,
i386,
Package: quassel-client
Version: 1:0.12.3-1
Severity: normal
On the Cinnamon desktop in Stretch, when a quassel-client notification
is set to "Mark taskbar entry" (which is set for all notifications by
default), it has two effects:
- Notification events immediately shift focus back to the
Package: libsvn-web-perl
Version: 0.63-1
The 0.63-1 version of libsvn-web-perl sets the locale for running tests
in debian/rules with:
override_dh_auto_test:
dh_auto_test -- LC_CTYPE=C.UTF-8
On Ubuntu, this causes an FTBFS, which is resolved by changing it to:
override_dh_auto_test:
I'm happy to work on this update, if the current maintainer doesn't
mind. I'll wait for a bit to give Patrick time to comment.
Allison
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Hamish,
What's the status on the upstream work here? Is it worth waiting for a
new upstream release, or is it better to go ahead and package 2.11?
Could the fixes for mapnik be applied to the 2.11 packages as patches,
or are the changes too extensive for that?
Note that this FTBFS has been
The details on these two CVE's are 403 for me:
CVE-2012-5120
https://code.google.com/p/chromium/issues/detail?id=150729
CVE-2012-5128
https://code.google.com/p/chromium/issues/detail?id=157124
So presumably they're still embargoed and only accessible to certain
members of pkg-javascript.
On 03/30/2012 04:10 PM, Miriam Ruiz wrote:
It works for me with squeak-vm 4.0.3.2202 (squeeze) but when trying to
run it on squeak-vm 4.4.7 (wheezy) I just get a black screen [1] [2]
According to jredrejo, the modification causing this problem might be
related to the changes made to the
2012/3/28 Amos Blanton a...@scratch.mit.edu:
The Scratch Team has re-released the Scratch 1.4 source code under the GPL
v2.
This is great news! :)
On 03/28/2012 01:34 PM, Miriam Ruiz wrote:
Yay! I'm going to package it for Debian
Double-check on the DFSG and the Scratch trademark policy.
/dynamic_link.patch to add
+-lm -lquadmath -lgfortran.
+
+ -- Allison Randal alli...@lohutok.net Tue, 06 Dec 2011 10:43:17 -0800
+
magics++ (2.12.9-5) unstable; urgency=low
* Recommends: pkg-config in -dev package.
=== modified file 'debian/patches/dynamic_link.patch'
--- debian/patches
On 12/06/2011 01:15 PM, Julien Cristau wrote:
On Tue, Dec 6, 2011 at 11:41:00 -0800, Allison Randal wrote:
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libemosR64.so:
undefined reference to `sqrtq'
That sounds like a bug in libemos.
It's actually an expected (even intended) result
On 12/06/2011 02:48 PM, Julien Cristau wrote:
I know about no-add-needed, but that doesn't make it ok for a library
such as libemosR64.so to have undefined symbols.
It's also possible to make the fix for the linking flags in libemos
instead. If -lm -lquadmath -lgfortran are really only used
The attached file is an update for the as-needed.patch file, and applies
cleanly during the build. However, the package is still FTBFS with this
change, failing later in override_dh_auto_configure with:
dh_auto_configure: ./configure --build=x86_64-linux-gnu --prefix=/usr
+
+ * Transition to multiarch.
+
+ -- Allison Randal alli...@lohutok.net Sun, 04 Dec 2011 22:32:53 +
+
libsoup2.4 (2.36.1-1) unstable; urgency=low
[ Martin Pitt ]
diff -Nru libsoup2.4-2.36.1/debian/compat libsoup2.4-2.36.1/debian/compat
--- libsoup2.4-2.36.1/debian/compat 2011-07-29 01
+--
+
+* Gpsdrive is incompatible with the new APIs of mapnik 2.0.0. This
+ optional library is now disabled in the package.
+
+ -- Allison Randal alli...@canonical.com Thu, 01 Dec 2011 12:48:22 -0800
+
Upgrading from gpsdrive 2.09 (etch
Package: wnpp
Severity: normal
The package 4digits was orphaned and removed from Debian in 2008:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479098
But, the upstream developer has continued working on it, and recently
submitted it to Ubuntu's Application Review Board. Rather than making
Package: libnet-server-perl
Version: 0.99-2
Severity: normal
Downstream in Ubuntu, we've had an FTBFS in libnet-server-perl (version
0.99-2ubuntu1) in Oneiric, caused by a missing value for $version in the
file Net-Server.spec.PL. This appears to be related to changes in the
behavior of
On 08/09/2011 05:03 PM, Dominique Dumont wrote:
IMHO, there are 2 long-term solutions:
- without ffi: as kibi suggested, this requires a --with{,out}-libffi flag in
parrot's Configure.pl. In the meantime, the binNMU on i386 will achieve the
same result.
- with ffi: parrot needs a build-dep on
Package: debian-maintainers
Severity: normal
Tags: patch
Please add my key to the DM keyring. I've attached a jetring changeset.
My primary GPG UID is alli...@lohutok.net, but I use the UID
alli...@parrot.org for packaging Parrot.
Thanks,
Allison
Comment: Add Allison Randal alli...@lohutok.net
Package: password-gorilla
Version: 1.4-4.1
Severity: wishlist
The packages for the Gorilla password manager are several versions out
of date from the current stable release, 1.5.3.4. (It looks like the 1.4
release was July 2006. The Debian package for 1.4 was certainly shipped
in Ubuntu's
Package: bsdmainutils
Version: 8.2.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu natty ubuntu-patch
I was working on this bug independently, didn't realize Kees was working
on it too.
Here's an additional patch, it catches the same problem in
On 6/4/10 11:32 AM, Matt Kraai wrote:
Oh. I asked because the latest Rakudo release appears to require the
latest Parrot release. Would it be possible to package the latest
development release of Parrot in experimental?
Parrot 2.5 will be out next Tuesday, is that soon enough?
Uploading
Parrot 2.4 is not a stable release, it's a developer release. We only
package the stable releases, which happen on a 3-month cycle (x.0, x.3,
x.6, and x.9).
On 6/4/10 5:05 AM, Matt Kraai wrote:
Source: parrot
Severity: wishlist
Hi,
Parrot 2.4.0 was released on 2010-05-18. Would you please
Ryan Niebur wrote:
ya. preparing an experimental upload would be great. Do you want to
wait for the September release or package the SVN version?
Let's wait for the releases. Parrot and Rakudo are carefully sync'd at
release points, but there's no guarantee of compatibility at random
Ryan Niebur wrote:
please keep the ITP bug CCed.
Apologies, was replying from my phone.
On Mon, Aug 31, 2009 at 03:45:07PM -0700, Allison Randal wrote:
they're actually in unstable. anyways, I need the unreleased versions
of parrot (more recent than 1.5.0 even). I'm using r40789 from SVN
Thanks Petr,
Could you try the attached patch? The 1.4 production release is next
Tuesday, so I could get this into the next version of of Debian packages
if it works for you.
Allison
Index: config/init/hints.pm
===
---
Petr Salinger wrote:
Unfortunately, it does not work.
This one (also tested) is better:
Excellent. Are there remaining build problems after your modified patch,
or does that resolve the issue?
Allison
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Petr Salinger wrote:
It would help if you could provide more details on the failure to build.
The best is if you can provide a full dump of the build process output.
https://buildd.debian.org/fetch.cgi?pkg=parrotarch=kfreebsd-amd64ver=1.0.0-1stamp=1243831790file=logas=raw
Oh, it builds
Thanks for the report Petr. Simply copying the hints file from linux to
another name isn't going to help. The configuration hints files provide
needed information for Parrot to know how to compile on a particular
platform, so either kFreeBSD is exactly the same as linux (and should
use the
Pugs is irrelevant now (mostly dead, and not using Parrot anymore), but
the shared library is still necessary for Parrot, especially for the
bytecode compiled to executable produced by the pbc_to_exe tool.
We will only be packaging the stable releases of Parrot (which happen
every six
Hi Michael,
Yes, we've been generating regular packages. The 1.0 release of Parrot
is coming up in March, and it would be nice to get that one in. I'll
check in with our debian sponsors.
Thanks,
Allison
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
John Lightsey wrote:
Hi there,
Do you still intend to adopt the Debian Parrot packages? From what I
can see, there was some talk in December about setting up group
maintenance of Parrot, but it doesn't look like that ever took off.
The group is in place, and we have 3 Debian Developers as
Hmmm... Russ and Gunnar seem to have traded positions. Whatever the
policy group decides is, of course, fine. Just let us know. I'll check
back in a few months if I don't hear anything more.
Gunnar Wolf wrote:
I'm more worried about the tons of changes this will inflict on the
pkg-perl group
Russ Allbery wrote:
That's additional information that I didn't have. Are all hundred of
those modules covered under the Artistic 2.0 license?
Yes, with the exception of 3 explicitly mentioned in the README.
I was under the impression that the Perl 6 modules in the archive were
being
Russ Allbery wrote:
Licenses are included in common-licenses primarily on the basis of how
commonly they're used in the archive. Currently, there are only about
five packages in the archive covered by this license, so I don't believe
this is warranted at this time. Basically, the license
Russ Allbery wrote:
Gunnar Wolf [EMAIL PROTECTED] writes:
Many Perl modules are just licensed under the same terms as Perl
itself, so as soon as Perl is released under this license, we will have
several hundreds of packages automagically under it.
Of course, this will require
Package: base-files
Version: 4.0.1
Severity: wishlist
I'd like to request the addition of the file:
http://www.perlfoundation.org/attachment/legal/artistic-2_0.txt
as Artistic-2 in /usr/share/common-licenses/.
Thanks,
Allison
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
42 matches
Mail list logo
