Bug#860870: marked as done (RFS: docopt.cpp/0.6.2-2)
Your message dated Fri, 21 Apr 2017 08:00:31 + (UTC) with message-id <1899357629.7088582.1492761631...@mail.yahoo.com> and subject line Re: Bug#860867: RFS: xtensor/0.9.0-1 has caused the Debian Bug report #860870, regarding RFS: docopt.cpp/0.6.2-2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 860870: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860870 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "docopt.cpp" * Package name: docopt.cpp Version : 0.6.2-2 Upstream Author : Jared Grubb * URL : https://github.com/docopt/docopt.cpp * License : MIT / BSL Section : libs One can check out the package by visiting the following URL: https://anonscm.debian.org/git/debian-science/packages/docopt.cpp.git Changes since the last upload: * Switch from git-dpm to gbp - Drop git-dpm configuration - Unapply patch queue - Add gbp configuration * Refresh and drop numbering of the patch queue * Fixup the VCS-Browser URI * Support the nocheck build profile - Add versioned b-dep on dpkg-dev - Mark test b-deps as !nocheck - Use DEB_BUILD_PROFILES in nocheck guards * Run the tests using Python 3 instead of Python 2 - Testing now depends on any Python 3 interpreter - New patch Make-tests-compatible-with-Python-3.patch * Fixup the Maintainer and Uploaders fields - Move myself from Maintainer to Uploaders - Set the Debian Science Team as Maintainer Best regards, Ghis --- End Message --- --- Begin Message --- Hi, all done! G.--- End Message ---
Bug#860868: marked as done (RFS: xtensor-python/0.10.0-1)
Your message dated Fri, 21 Apr 2017 08:00:31 + (UTC) with message-id <1899357629.7088582.1492761631...@mail.yahoo.com> and subject line Re: Bug#860867: RFS: xtensor/0.9.0-1 has caused the Debian Bug report #860868, regarding RFS: xtensor-python/0.10.0-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 860868: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860868 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, * Package name: xtensor-python Version : 0.10.0-1 Upstream Author : Johan Mabille and Sylvain Corlay * URL : http://quantstack.net/xtensor * License : BSD Section : libs One can check out the package by visiting the following URL: https://anonscm.debian.org/git/debian-science/packages/xtensor-python.git Changes since the last upload: * New upstream version 0.10.0 * Refresh the patch queue * Build depends on xtensor >= 0.9.0 Best regards, Ghis -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Hi, all done! G.--- End Message ---
Bug#860867: marked as done (RFS: xtensor/0.9.0-1)
Your message dated Fri, 21 Apr 2017 08:00:31 + (UTC) with message-id <1899357629.7088582.1492761631...@mail.yahoo.com> and subject line Re: Bug#860867: RFS: xtensor/0.9.0-1 has caused the Debian Bug report #860867, regarding RFS: xtensor/0.9.0-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 860867: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860867 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, * Package name: xtensor Version : 0.9.0-1 Upstream Author : Johan Mabille and Sylvain Corlay * URL : http://quantstack.net/xtensor * License : BSD Section : libs One can check out the package by visiting the following URL: https://anonscm.debian.org/git/debian-science/packages/xtensor.git Changes since the last upload: * New upstream version 0.9.0 Best regards, Ghis -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Hi, all done! G.--- End Message ---
I have some questions about alioth repository
Hi, I was analyzing repositories of debian packages by debcheckout tool. I've known there are 7 types of version control system. (Arch, Bazzar, CVS, Darcs, Git, Mercurial, Subversion) My questions are below... 1 All version control systems are using actively? or moving to git progressively ? Are there projects managed by CVS, Arch system ? 2. In case of vim package, there are two repositories(git, mercurial). I cloned the repository from mercurial in debian Jessie. I also saw the repository of git is more active than mercurial base on a latest commit date. Those are different versions for each of debian version? 3. In case of darcs package, debcheckout tried to download source code from Darcs repository. (anonscm.debian.org/cgi-bin/darcsweb.cgi) But, that failed. Because, the project doesn’t exist in the repository. Is this working well? 4. Some packages don't have repository(No repository found by debcheckout tool) like acpi, alsamixergui, apg, aspell-en, autoconf. Are there repositories for source code of those packages ? If you give a answer, I'd appreciate it :) Regards, Junghwan Kang
Re: I have some questions about alioth repository
On Fri, 2017-04-21 at 17:37 +0900, JungHwan Kang wrote: > Hi, > I was analyzing repositories of debian packages by debcheckout tool. > I've known there are 7 types of version control system. > (Arch, Bazzar, CVS, Darcs, Git, Mercurial, Subversion) > My questions are below... > > 1 All version control systems are using actively? or moving to git > progressively ? > Are there projects managed by CVS, Arch system ? Most packaging teams are now converging to using Git. If you were to start packaging a new piece of software, you would likely be using Git, unless your team's policy advises otherwise. > 2. In case of vim package, there are two repositories(git, mercurial). > I cloned the repository from mercurial in debian Jessie. > I also saw the repository of git is more active than mercurial base on a > latest commit date. > Those are different versions for each of debian version? Your answer is in the changelog. > 3. In case of darcs package, debcheckout tried to download source code from > Darcs repository. > (anonscm.debian.org/cgi-bin/darcsweb.cgi) > But, that failed. Because, the project doesn’t exist in the repository. Is > this working well? If it failed, probably the answer is no. > 4. Some packages don't have repository(No repository found by debcheckout > tool) > like acpi, alsamixergui, apg, aspell-en, autoconf. > Are there repositories for source code of those packages ? If the corresponding Vcs-* fields in d/control are missing for these packages, then the packaging work is not stored in a VCS. You may generate one by calling `gbp import-dscs $PACKAGE` which will download all previous uploads and record them as successive Git commits. > If you give a answer, I'd appreciate it :) You're welcome. Ghis
Re: I have some questions about alioth repository
Hi, >> 3. In case of darcs package, debcheckout tried to download source code from >> Darcs repository. >> (anonscm.debian.org/cgi-bin/darcsweb.cgi) >> But, that failed. Because, the project doesn’t exist in the repository. Is >> this working well? > >If it failed, probably the answer is no. debcheckout looks only at the VCS fields of the actual available package, not the one in unstable/testing. So, if you run stable, debcheckout darcs will point to nowhere (since we moved darcs to git, LOL). the package in unstable/stretch points to git, like the other haskell tools https://sources.debian.net/src/darcs/2.12.4-2/debian/control/ use debcheckout only when running testing/unstable is preferred, since we like to add VCS or move them between releases :p G.
Bug#860496: RFS: drgeo/1.1.0-10.3 [NMU, RC]
drgeo is not in jessie and won't be in stretch, so there is no need to hurry with patching this upstream version from 2005. https://git.gnome.org/browse/archive/drgeo/log/ This looks very dead. #736535 mentions an active fork (that seems to be quite different). Yes, it use the pharo framework (smalltalk) now but it's released as a vm snapshot so harder to package... What drgeo needs is an active maintainer who packages code that is also maintained upstream. Trying to revive 2005 code after it has already missed two Debian releases doesn't make much sense. Indeed, this package fill the gap while we are waiting for the newer version to be packaged. do you really need to patch: Makefile.in.in I'm afraid so, otherwise intltoolize gives an error. and add a new config.rpath file? No indeed, I added gettext as a dependency and I'm copy the file before the build instead. also, please drop the last part of the patch: @@ -443,4 +443,4 @@ ;(new-figure "Ma figure") ;(define a (Numeric "a" 'free 0 0 1)) -;(define p (Point "o" 'intersection a a)) \ Pas de fin de ligne à la fin du fichier +;(define p (Point "o" 'intersection a a)) Done. The new version is here: https://mentors.debian.net/debian/pool/main/d/drgeo/drgeo_1.1.0-10.3.dsc Patrick
Bug#855354: RFS: alot/0.5.1-1 [ITA]
On 21-Feb-2017, Jordan Justen wrote: > I uploaded a new 0.5.1-1 to mentors.debian.net. […] > > On 2017-02-17 05:29:44, Johannes Schauer wrote: > > Feel free to contact me for sponsorship as I'm an alot user and > > also fixed/filed a couple of bugs together with upstream. I'm thus > > very interested in keeping this package in Debian. > > Thanks! Let me know if you'd like any additional changes made. How is this going? Jordan, have you made more changes that should be released? Johannes, are you waiting on any changes before you approve and upload this package? -- \ “It seems intuitively obvious to me, which means that it might | `\ be wrong.” —Chris Torek | _o__) | Ben Finney signature.asc Description: PGP signature
Bug#855354: RFS: alot/0.5.1-1 [ITA]
Hi Ben, Quoting Ben Finney (2017-04-21 14:44:52) > How is this going? thanks a lot for the ping! > Jordan, have you made more changes that should be released? > > Johannes, are you waiting on any changes before you approve and upload > this package? Jordan and I were writing each other privately in February. Currently progress is stalled on the question of how to maintain the package. The options are: 1. maintaining it under the umbrella of the Python Applications Packaging Team but they use svn which Jordan wants to avoid in favour of git. There is the question of whether it would be acceptable to use PAPT+git: http://lists.alioth.debian.org/pipermail/python-apps-team/2017-February/013126.html But as the last message indicates, there seems to be no consensus yet whether to use git-dpm or switch to gbp-pq when moving python-apps from svn to git... 2. using collab-maint with whatever git packaging workflow but it seems that Jordan isn't sure yet which one to pick for maintenance of alot Jordan, are you still on board? Otherwise I just pick the option I like and start committing your work. :) Thanks! cheers, josch signature.asc Description: signature
Bug#860466: RFS: equivs/2.0.10 [QA] -- Circumvent Debian package dependencies
Control: tag -1 -moreinfo Dear Sean, On Thu, 20 Apr 2017 09:36:24 -0700 Sean Whitton wrote: > I'd like to note that I'm planning to upload with dgit, so you shouldn't > rebase after the upload. It's okay to rebase before the upload. Understand. I always cut the final releasing commit and append with new commit, or amend the last commit, which you may call it rebase, and finally add a new releasing commit and push to a new branch, such as mentors2 or qa_upload2. Old branch is also kept, you you can easily "git show-branch" or "git diff" between branches. So you can know what has been changed. > The changelog still doesn't say that the Maintainer: field has been updated. > > If you're able to address the issues I've raised in this message, please > remove the moreinfo tag in this bug, and don't forget to re-run `dch -r` > to refresh the changelog timestamp. It's fixed and pushed to qa_upload4. _source package is also uploaded to mentors & DoM, for your reference. Thanks for your help! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpYlVqqIhtM7.pgp Description: PGP signature
someone knows about https://archive.debian.net/
some one noted or using any time the https://archive.debian.net/ service.. was usefully for packagin notes and test over other versions.. archived of course.. was usefully for my lives due most old hardware like framegrabber capture devices does not have support today in current klernels... today this service are changed and now only put a static page in frontend.. anybocy knows about related? -- Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Re: I have some questions about alioth repository
On Fri, Apr 21, 2017 at 05:37:19PM +0900, JungHwan Kang wrote: > 4. Some packages don't have repository(No repository found by debcheckout > tool) > > like acpi, alsamixergui, apg, aspell-en, autoconf. > > Are there repositories for source code of those packages ? > % dgit clone acpi -- Sean Whitton signature.asc Description: PGP signature
Re: someone knows about https://archive.debian.net/
have you also read that page?.. more info: the person who was nominally maintaining it was not maintaining it, as he let the SSL certificate expire, and so DSA took repointed the DNS to an error page. On Fri, Apr 21, 2017 at 4:04 PM PICCORO McKAY Lenz wrote: > some one noted or using any time the https://archive.debian.net/ service.. > > was usefully for packagin notes and test over other versions.. > archived of course.. was usefully for my lives due most old hardware > like framegrabber capture devices does not have support today in > current klernels... > > today this service are changed and now only put a static page in > frontend.. anybocy knows about related? > > -- > Lenz McKAY Gerardo (PICCORO) > http://qgqlochekone.blogspot.com > >
Bug#860905: RFS: libdsk/1.5.4+dfsg-1 [ITP]
Package: sponsorship-requests Severity: wishlist Control: blocks -1 168591 Dear mentors, I am looking for a sponsor for my package "libdsk" * Package name: libdsk Version : 1.5.4+dfsg-1 Upstream Author : John Elliott * URL : http://www.seasip.info/Unix/LibDsk/ * License : LGPL-2+ / MIT Section : ilbs It builds those binary packages: libdsk-utils - library for accessing discs and disc image file (utilities) libdsk4- library for accessing discs and disc image file libdsk4-dev - library for accessing discs and disc image file (development head To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libdsk Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libd/libdsk/libdsk_1.5.4+dfsg-1.dsc Changes since the last upload: libdsk (1.5.4+dfsg-1) unstable; urgency=low * Initial release (Closes: #168591) -- Dominik George Wed, 19 Apr 2017 18:26:06 +0200 Regards, Dominik George -- PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296 Dominik George · Hundeshagenstr. 26 · 53225 Bonn Phone: +49 228 92934581 · https://www.dominik-george.de/ Teckids e.V. · FrOSCon e.V. Fellowship of the FSFE · Piratenpartei Deutschland Opencaching Deutschland e.V. · Debian Maintainer LPIC-3 Linux Enterprise Professional (Security)
Re: someone knows about https://archive.debian.net/
yeah, that's why i asked! obviusly i asked due if some one are working on sometihing.. 2017-04-21 11:20 GMT-04:00, Mattia Rizzolo : > have you also read that page?.. > > more info: the person who was nominally maintaining it was not maintaining > it, as he let the SSL certificate expire, and so DSA took repointed the DNS > to an error page. > > On Fri, Apr 21, 2017 at 4:04 PM PICCORO McKAY Lenz > wrote: > >> some one noted or using any time the https://archive.debian.net/ >> service.. >> >> was usefully for packagin notes and test over other versions.. >> archived of course.. was usefully for my lives due most old hardware >> like framegrabber capture devices does not have support today in >> current klernels... >> >> today this service are changed and now only put a static page in >> frontend.. anybocy knows about related? >> >> -- >> Lenz McKAY Gerardo (PICCORO) >> http://qgqlochekone.blogspot.com >> >> > -- Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Re: someone knows about https://archive.debian.net/
On Fri, Apr 21, 2017 at 11:54:08AM -0400, PICCORO McKAY Lenz wrote: > yeah, that's why i asked! obviusly i asked due if some one are working > on sometihing.. Is http://snapshot.debian.org/ not enough for your tasks? -- WBR, wRAR signature.asc Description: PGP signature
Re: someone knows about https://archive.debian.net/
the http://snapshot.debian.org/ its the great tool and resource for retrieve the specific package.. and study cases ONCE a specific objetive are found... my novice aprendices get into it after some web serach into the debian archive web search interface.. al already knows that with apt-cache and apt-file i can made it, but i try to able to made friendly the system before introducing in a more complex and advanced world of debian.. in archive.debian.net the old web package search tool was available and its a good starter point for search into older packages specialy for squeeze and lenny distributions widelly used here for most hardware (with our own patcheds backported from debian stable and lts) 2017-04-21 12:02 GMT-04:00, Andrey Rahmatullin : > On Fri, Apr 21, 2017 at 11:54:08AM -0400, PICCORO McKAY Lenz wrote: >> yeah, that's why i asked! obviusly i asked due if some one are working >> on sometihing.. > Is http://snapshot.debian.org/ not enough for your tasks? > > -- > WBR, wRAR > -- Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Bug#855354: RFS: alot/0.5.1-1 [ITA]
On 2017-04-21 06:12:21, Johannes Schauer wrote: > Quoting Ben Finney (2017-04-21 14:44:52) > > Jordan, have you made more changes that should be released? > > > > Johannes, are you waiting on any changes before you approve and upload > > this package? > > Jordan and I were writing each other privately in February. Currently progress > is stalled on the question of how to maintain the package. The options are: > > 1. maintaining it under the umbrella of the Python Applications Packaging > Team > but they use svn which Jordan wants to avoid in favour of git. There is > the > question of whether it would be acceptable to use PAPT+git: > > http://lists.alioth.debian.org/pipermail/python-apps-team/2017-February/013126.html > But as the last message indicates, there seems to be no consensus yet > whether to use git-dpm or switch to gbp-pq when moving python-apps from > svn > to git... I was trying to see if I could work with Stefano (Cc'd) to help with the PAPT svn=>git transition, but that didn't end up going anywhere. :\ > 2. using collab-maint with whatever git packaging workflow but it seems that > Jordan isn't sure yet which one to pick for maintenance of alot > > Jordan, are you still on board? Otherwise I just pick the option I like and > start committing your work. :) Yes, I am still interested. I'd convinced myself that I just needed to give up on using git for now, so I planning to commit the patches to svn under the current PAPT packaging area. I'll do that and then work with you (Johannes) to upload the new package. -Jordan signature.asc Description: signature
Bug#860921: RFS: python-ordered-set/2.0.2-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, * Package name: python-ordered-set Version : 2.0.2-1 Upstream Author : Luminoso Technologies, Inc. * URL : https://github.com/LuminosoInsight/ordered-set/ * License : Expat Section : python One can check out the package by visiting the following URL: https://anonscm.debian.org/git/python-modules/packages/python-ordered-set.git Changes since the last upload: * Initial release. (Closes: #860768) Best regards, Ghis
Bug#860804: RFS: highwayhash/0~20170419-g1f4a24f-1 [ITP] -- tensorflow dependency library
On Fri, Apr 21, 2017 at 04:20:24AM +, Lumin wrote:
> Updated package was uploaded to mentors:
> https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20170419-g1f4a24f-1.dsc
>
> Changes:
> * fixed the mistaken /lib//libxxx.a install path.
> The static library didn't drop
> sip_tree_hash.o object.
> * patched upstream makefile to produce a shared object file
> (sip_tree_hash.o is dropped from so file)
> * added symbols control file
> * override dh_auto_test to run upstream test binaries (except for the
> "benchmark").
>
> Is it acceptable now?
It does look uploadable, yeah, even though there's a bunch of issues. It's
up to you whether you want to get it good first or to upload present state
then improve it incrementally. Please say what you prefer.
The bad news is, it succeeded only on amd64.
On other architectures, the closest it came on x32 (a non-release arch) --
builds ok, fails only at dpkg-gensymbols due to symbol mismatches.
One warning: left shift count >= width of type [-Wshift-count-overflow]
sounds like it might be broken, though[1].
On arm64 it fails with:
g++: error: unrecognized command line option '-mavx2'
On armhf there's both the shift width issue, and:
error: #error "Port"
On i386, all of the above, plus:
error: '_mm_cvtsi64_si128' was not declared in this scope
I assume you neither have access to porterboxes nor an array of hardware at
home (and qemu can be tricky), so it might be easiest for you to abuse the
buildds or someone who can test.
Other issues:
Please add:
Multi-Arch: same
to libhighwayhash0's section in the control file. You install stuff to the
proper paths so there's no reason for it to be not coinstallable.
Some simple docs would be nice -- RTFSing the headers is not pretty.
This could work:
.--[ highwayhash.3 ]
.TH highwayhash 3
.SH NAME
highwayhash \- fast strong 64-bit hash functions
.SH SYNOPSIS
.B #include
uint64_t SipHashC(const uint64_t* key, const char* bytes, const uint64_t size);
uint64_t SipHash13C(const uint64_t* key, const char* bytes, const uint64_t
size);
uint64_t HighwayHash64(const HHKey key, const char* bytes, const uint64_t size);
.SH DESCRIPTION
blah blah blah, SipHash wants an uint64_t[2] key while HighwayHash
uint64_t[4]
`
(with blah blah replaced with the prose)
The C interface looks more comfortable to use even from C++, so I'd describe
it first (or even exclusively for now).
Manually mucking with optimization variant selection provides only a very
minor speedup, so I wouldn't bother describing those. Especially that with
gcc-6 per-ISA variants can be bound at library load time -- if the library
uses that functionality it could eliminate the overhead altogether. That's
a matter for the upstream, though.
Lemme share a sanity test I used:
.--
#include
#include
#include
static const uint64_t shkey[2]={0xdeadbeef,0xcafebabe};
static const HHKey hhkey={3,14,15,926}; // 4×uint64_t
int main()
{
printf("%016"PRIx64"\n", SipHashC(shkey, "meow", 4));
printf("%016"PRIx64"\n", SipHash13C(shkey, "meow", 4));
printf("%016"PRIx64"\n", HighwayHash64(hhkey, "meow", 4));
return 0;
}
produces:
af0a25067c014659
600708416bfbe7ad
01aeb7e482f04c46
`
[1]. Such shifts produce only a warning, but are notorious for giving wrong
results:
int lines = 32;
u32 mask = (1 << lines) - 1;// on x86
u32 mask = (1 << lines) - 1;// on arm (32)
u32 mask = (1 << lines) - 1;// on arm64
u32 mask = (1ULL << lines) - 1; // everywhere
--
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!
Re: someone knows about https://archive.debian.net/
On Fri, Apr 21, 2017 at 10:02 PM, PICCORO McKAY Lenz wrote: > some one noted or using any time the https://archive.debian.net/ service.. ... > today this service are changed and now only put a static page in > frontend.. anybocy knows about related? The service will not be available until the maintainer has time to work on it. It is only for obsolete insecure Debian releases, we strongly recommend you upgrade to a supported release and use packages.debian.org instead. squeeze and lenny should *definitely* not be used any longer. What is blocking your upgrade to wheezy/jessie/stretch? -- bye, pabs https://wiki.debian.org/PaulWise
