Bug#758178: general: screen resolution reverts to minimum when not selected by KVM

2014-08-15 Thread Bob Michael
Package: general
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
I have 3 or 4 debian machines attached to a Zonet KVM3304 4 port KVM switch.  I
usually keep at least 2 of them on most of the time.  Thus only one is selected
at any one time.  I try to keep separate projects for clients on separate
machines.  When I select a machine that has not been selected for a while, say
2 hours or longer, the screen resolution has been set to the minimum.  It is
almost like some process goes out and queries about the display resolution and
when the machine is not selected it either does not get an answer or the answer
it gets is 600x480.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I went to the System Settings - Displays to try to reset the resolution.  I
have done this both with Gnome Classic and the new Gnome.  I am rather sure
that the problem is somewhere in Gnome, but I have no idea which subsystem.
   * What was the outcome of this action?
In every case, the display goes black and the computer becomes unresponsive.  I
have to reboot.  I have tried this with fresh installs of debian 7.1, 7.2, 7.3,
and now 7.6.  This makes debian 7 unusable because when I am working on a
project, I usually leave multiple GVIM editor sessions open (sometimes a dozen
or more sessions) and sometimes for days at a time.
   * What outcome did you expect instead?
This never happened under debian 6 or debian 5 or debian 4.  The resolution
stays the same no matter how long the machine has
been unselected by the KVM.  I have had to revert to debian 6 in order to get
any work done on any machine that I need to leave on for more than a few hours.
Last week I installed openSUSE just to see what it did.  I left its machine
unselected overnight and when I reselected it, it came back with the screen
resolution unchanged.  So openSUSE seems to have fixed this bug.

*** End of the template - remove these lines ***



-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815061315.3847.42292.reportbug@debian7.6



Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-15 Thread Thomas Goirand
On 08/14/2014 11:59 PM, The Wanderer wrote:
 On 08/14/2014 11:27 AM, Thomas Goirand wrote:
 
 On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
 
 On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
 
 Also ive offered my resignation in the past. I do still offer to
 resign from the FFmpeg leader position, if it resolves this split
 between FFmpeg and Libav and make everyone work together again.
 
 Why not just take the offer, and move on?
 
 Probably because of the condition he attached to it, which also dates
 back to the arguments preceding the original split:
 
 The part i insist on though is that everyone must be able to work
 on their code without people uninvolved in that specific parts
 maintaince or authorship being able to block their work.
 
 In other words, as I think I understand it from the discussion back
 then: people not involved with a particular area of the code can't NACK
 the work of someone who is working on it, and someone who works on a
 particular area of the code doesn't have to wait on review of people who
 aren't involved with that area of the code.
 
 Since one of the motivations of the people behind the libav side of the
 split seems, IIRC, to have been no code gets in without having been
 reviewed by someone other than the author, this was apparently deemed
 an unacceptable condition.

Hum... Well, to me, what's important is that the code gets
peer-reviewed. Setting-up something like gerrit may help, as it can be
setup in a way that review becomes mandatory. Then discussing who's
core-reviewer and can approve this or that part of the code can be setup
within gerrit. This should be discussed, and setup based on technical merit.

Having a NACK review is often disappointing. It goes the wrong way if
there's only a NACK with no comments on how to improve things, so that
the code becomes acceptable. Absolutely everyone should *always* be able
to leave comments, be it positive or negative. With Gerrit, it's
possible to comment directly in the patch, which helps going in the
right direction.

Of course, a technical solution will not solve all social issues, but it
may improve the workflow and process, and avoid frictions.

I hope this helps,
Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53edae55.4090...@debian.org



Re: Uploading python-xstatic-* packages in Debian

2014-08-15 Thread Thomas Goirand
On 08/15/2014 12:28 AM, Jonas Smedegaard wrote:
 Quoting Thomas Goirand (2014-08-14 09:26:05)
 Note that the XStatic python modules aren't just meta packages, they 
 also offer a mechanism for a Python script to discover where to find a 
 given static file in the system (which really, isn't obvious, as the 
 Debian archive is a bit messy in this regard, especially when dealing 
 with static files that aren't javascript like .css or .less files).
 
 You are quite welcome to propose tp relevant teams streamlining which 
 could ease your packaging.  A cleanup might take time to coordinate, and 
 agreeing on tidying the structure may take time too, but that shouldn't 
 discourage you from initiating that process :-)
 
 I recommend to discuss that in those smaller teams rather than here.

Well, unfortunately, I'm not sure there's a solution, or at least, I
don't have it. Things are the way they are because upstream decided to
put this or that file in this or that folder, and then every upstream
has his own convention. Then we just follow upstream, and that is a good
thing. But at the end, we end up with no convention. A more broad
standard should, at some point, be establish, so that everyone (and by
this, I mean also upstream authors...) sorts files in the same way.

Anyway, this was just a few thoughts, I didn't intend to start a troll
thread about this. :)

 For some XStatic packages, the embedded static files are not present 
 in Debian. That is the case for example with python-xstatic-hogan, 
 python-xstatic-jasmine, or python-xstatic-bootstrap-scss. For the 
 above 3 packages, the upstream source code is part of a much larger 
 project.
 
 Please don't embed reusable non-Python code into Python-specific 
 packages - then you end up with same problem as you ran into yourself 
 with ruby-bootstrap-sass (see right below).  Instead, package (or 
 request others like the Javascript ot Sass team) to package those which 
 you need.

I'm doing the libjs-* packages whenever that's not too big, and
manageable by myself. I did that for libjs-twitter-bootstrap-datepicker
for example, then I just depend on that package.

 See for example bootstrap-scss, which comes with a huge Ruby 
 framework. I have no intention to package all of that...
 
 I guess you mean ruby-bootstrap-sass - please see bug#739783.

Oh, swt! What I need is in compass-bootstrap-sass-plugin :)
Thanks a lot for the pointer, Jonas. This is really helpful.

Indeed, #739783 is important to be fixed for me as well, as I wont be
using ruby at all, and I don't think it's reasonable to get 10MB of
non-useful ruby stuff for Horizon ! :)

 As I know very little about packaging of some upstream code (for 
 example, I have never maintained ruby or nodejs packages), and that I 
 don't need them anyway (I only need a few javascript files from them, 
 I will have no use of Ruby or nodejs code), then I decided to *not* 
 package the full upstream package, and leave the embedded copy inside 
 the python-xstatic-* packages. This is until someone needs the full 
 upstream package, at which point I will remove the embedded copy, and 
 point to the relevant files inside the recently uploaded package.
 
 Please don't postpone proper packaging until others eventually steps up.

Theoretically, you are right. Unfortunately, this isn't practical.

I'm sorry, but I just can't package stuff that I have no use for, or for
which I have no knowledge (ruby is a good example of this). This will be
bad work, and I don't want to upload crap which I wont even be able to
check by myself. It would also sometimes be too much work, for which I
wont have time for.

I also don't believe that just writing an RFP will make it happen. If
this was the case, I'd just do that, always, and stop doing any sort of
packaging myself...

So, I'm going to do this only as much as I can, when possible. I hope
you'll understand.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53edb61c.7050...@debian.org



Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-15 Thread Paul Wise
On Fri, Aug 15, 2014 at 2:53 PM, Thomas Goirand wrote:

 Hum... Well, to me, what's important is that the code gets
 peer-reviewed.

... by both humans and by automatically by computers; compiler
warnings, static analysis tools, fuzz testers etc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6E5Ow=ywhmzjqt-wotwolikj6_cveeqyyzzk4rxno4...@mail.gmail.com



Re: Uploading python-xstatic-* packages in Debian

2014-08-15 Thread Jonas Smedegaard
Quoting Thomas Goirand (2014-08-15 09:26:20)
 On 08/15/2014 12:28 AM, Jonas Smedegaard wrote:
 Quoting Thomas Goirand (2014-08-14 09:26:05)
 Note that the XStatic python modules aren't just meta packages, they 
 also offer a mechanism for a Python script to discover where to find 
 a given static file in the system (which really, isn't obvious, as 
 the Debian archive is a bit messy in this regard, especially when 
 dealing with static files that aren't javascript like .css or .less 
 files).
 
 You are quite welcome to propose tp relevant teams streamlining which 
 could ease your packaging.  A cleanup might take time to coordinate, 
 and agreeing on tidying the structure may take time too, but that 
 shouldn't discourage you from initiating that process :-)
 
 I recommend to discuss that in those smaller teams rather than here.

 Well, unfortunately, I'm not sure there's a solution, or at least, I 
 don't have it.

I don't expect you to have solutions, only - maybe - ideas.

That s exactly why I suggest doing it as teamwork :-)


 Please don't embed reusable non-Python code into Python-specific 
 packages - then you end up with same problem as you ran into yourself 
 with ruby-bootstrap-sass (see right below).  Instead, package (or 
 request others like the Javascript ot Sass team) to package those 
 which you need.
[...]
 Please don't postpone proper packaging until others eventually steps up.

 Theoretically, you are right. Unfortunately, this isn't practical.

 I'm sorry, but I just can't package stuff that I have no use for, or 
 for which I have no knowledge (ruby is a good example of this). This 
 will be bad work, and I don't want to upload crap which I wont even be 
 able to check by myself. It would also sometimes be too much work, for 
 which I wont have time for.
 
 I also don't believe that just writing an RFP will make it happen. If 
 this was the case, I'd just do that, always, and stop doing any sort 
 of packaging myself...
 
 So, I'm going to do this only as much as I can, when possible. I hope 
 you'll understand.

What I suggest is that you package stuff you have no use for, nor that 
you just write RFPs.  What I suggest is that you collaborate with teams.


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Re: Reverting to GNOME for jessie's default desktop

2014-08-15 Thread Svante Signell
Please don't top post!

On Thu, 2014-08-14 at 15:12 +0100, envite wrote:
 Why not MATE for all and put a11y into it?
 
 Makes more sense for e.g. small computers like those in 3rd World talked 
 before. 
 
 Enviado de Samsung Mobile

I'm all for it, and am willing to help making it happen. With MATE all
architectures could have the same desktop default. Who are the packaging
teams to join?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1408093348.2372.5.camel@PackardBell-PC



Re: Uploading python-xstatic-* packages in Debian

2014-08-15 Thread Thorsten Glaser
On Thu, 14 Aug 2014, Thomas Goirand wrote:

 What would probably work better would be to add the python library
 inside upstream code.

That would work as well.

 But then we have another issue: the Python module is supposed to be
 packaged as python-something, and the JS libs are supposed to be
 packaged as libjs-something. So we'd have to break one or the other
 convention.

No. Provides exist for a reason.

 I don't think that's desirable to do. We don't want to break automatic
 dependency calculation by dh_python{2,3} either.

You can add those to the libjs-* source packages.

 The important bit is that upstream requires version X of
 python-xstatic-jquery because it needs version X of jquery. When we have

That is *even more* reason to merge the packaging of the
xstatic things with the packaging of the libraries they
provide!

 The XStatic package itself doesn't contain much but the Python
 wrapper, so it's not a big deal (it's very simplistic Python code).

That’s a good argument in favour of integrating the python
side into the Debian packages of the upstreams of the xstatic
packages.

 static files libraries. In fact, XStatic has been created upstream with
 distributions in mind, and I find it very nice of them. It's indeed
 solving the problem, even if that's some non-negligible work at first to
 do the python-xstatic-* packaging.

That doesn’t mean we have to implement the API the same way.
Integrating something into the libjs-* packages to provide
xstatic would also fulfil that, and use the very nice thing
upstream made, just not the same way to there.

bye,
//mirabilos
-- 
[16:04:33] bkix: veni vidi violini
[16:04:45] bkix: ich kam, sah und vergeigte...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1408151115370.23...@tglase.lan.tarent.de



Re: First steps towards source-only uploads

2014-08-15 Thread Johannes Schauer
Hi,

Quoting Guillem Jover (2014-08-13 13:48:11)
 On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote:
  There are also other problems that need to be eventually addressed: as far
  as I know there are some source packages producing arch:all binaries that
  cannot be built on all architectures. A Build-Architecture-Indep field was
  proposed to indicate where it should be built in this case[1], but for now
  I think we can require that maintainers have to upload the arch:all
  packages in this case.
 
 I think all proposed field names in that thread are rather confusing.
 In Debian packaging lingo build means several things, it can mean at
 least the build machine (!= host machine), or it can mean the act of
 building.
 
 In the case of Build-Depends style fields, it's referring to the act
 of building, but Architecture is related to the host system/compiler,
 so mixing the different meanings would be messy, think for example
 about cross-compiling.

But is the question not *on* which architecture arch:all packages are built,
and would the term build in Build-Architecture-Indep thus not be correct in
both of its meanings (as the architecture I'm building *on* as well as the
act of building)?

cheers, josch


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815092700.14069.93664@hoothoot



Bug#758195: ITP: solarus -- Open-source Zelda-like game engine

2014-08-15 Thread Pierre Rudloff
Package: wnpp
Severity: wishlist
Owner: Pierre Rudloff cont...@rudloff.pro

* Package name: solarus
  Version : 1.2.1
  Upstream Author : Nathan Moore nathanmo...@cox.net
* URL : http://www.solarus-games.org/
* License : GPL
  Programming Lang: C++
  Description : Open-source Zelda-like game engine


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815093459.24742.51928.report...@home.rudloff.pro



Re: Reverting to GNOME for jessie's default desktop

2014-08-15 Thread Mike Gabriel

Hi Svante, hi all,

On  Fr 15 Aug 2014 11:02:28 CEST, Svante Signell wrote:


Please don't top post!

On Thu, 2014-08-14 at 15:12 +0100, envite wrote:

Why not MATE for all and put a11y into it?

Makes more sense for e.g. small computers like those in 3rd World  
talked before.


Enviado de Samsung Mobile


I'm all for it, and am willing to help making it happen. With MATE all
architectures could have the same desktop default. Who are the packaging
teams to join?


The DDPO page is found at [1].

Active DDs in the MATE team are John Paul Adrian Glaubitz and $me.

The MATE packaging is also supported by several non-DDs. The MATE team  
intensely cooperates with those people bringing MATE into Ubuntu. One  
of the main upstream devs (Stefano Karapetsas) is also member of the  
MATE packaging team.


We meetwork on Freenode (#debian-mate) and plan to migrate smoothly  
to OFTC sooner or later (#debian-mate).


Greets,
Mike

[1]  
https://qa.debian.org/developer.php?login=pkg-mate-t...@lists.alioth.debian.org#mate-power-manager

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgp5nvdrW1as7.pgp
Description: Digitale PGP-Signatur


Re: First steps towards source-only uploads

2014-08-15 Thread Hector Oron
Hello,

2014-08-13 22:59 GMT+02:00 Philipp Kern pk...@debian.org:
 On 2014-08-13 14:34, Raphael Hertzog wrote:
 On Wed, 13 Aug 2014, Colin Watson wrote:

 I don't think there's a good reason to build them separately, and some
 good reasons not to (for example, it would waste a good deal of buildd
 time for a number of packages without very hygienic separation of their
 build rules).  My suggestion would be to just build them along with the
 architecture-dependent binaries for some nominated architecture, which
 could be package-specific or not depending on what you all have time
 for, and be done with it.

 In kali, that's exactly what I have been doing. Any package that builds
 an arch: all is sent to an amd64 buildd and sbuild on the amd64 buildd
 gets
 called with -A.

 It doesn't matter whether it builds only the arch: all or another package
 too.

 We need to convey if the arch:all is actually needed, though, otherwise dak
 will reject the package. Or could we simply build it always and have it
 discarded if the maintainer's copy had been accepted?

Even building arch:all packages in one architecture might solve the
issue, I do not like that approach, as it holds other arches from
building until that primary arch has built arch:all packages. It
also leads to not fully buildable packages for the rest of
architectures, i.e. #690260 (openjdk-7: build empty doc packages on
arm).

Building arch:all on every architecture can also be seen as a waste of
build time but effective.

Another approach would be to find out if arch:all packages are
available for build, if not, then build them along package in
whichever architecture, otherwise skip them. That looks the most fair
approach to me, but it can possibly lead to interesting races,
depending on implementation.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caodfwegv40bnpuj_u5i-4nzvr5ua4wdo5wy+8xj+7wqs1lu...@mail.gmail.com



Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-15 Thread Michael Niedermayer
On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote:
 On 08/14/2014 11:59 PM, The Wanderer wrote:
  On 08/14/2014 11:27 AM, Thomas Goirand wrote:
  
  On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
  
  On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
  
  Also ive offered my resignation in the past. I do still offer to
  resign from the FFmpeg leader position, if it resolves this split
  between FFmpeg and Libav and make everyone work together again.
  
  Why not just take the offer, and move on?
  
  Probably because of the condition he attached to it, which also dates
  back to the arguments preceding the original split:
  
  The part i insist on though is that everyone must be able to work
  on their code without people uninvolved in that specific parts
  maintaince or authorship being able to block their work.
  
  In other words, as I think I understand it from the discussion back
  then: people not involved with a particular area of the code can't NACK
  the work of someone who is working on it, and someone who works on a
  particular area of the code doesn't have to wait on review of people who
  aren't involved with that area of the code.
  
  Since one of the motivations of the people behind the libav side of the
  split seems, IIRC, to have been no code gets in without having been
  reviewed by someone other than the author, this was apparently deemed
  an unacceptable condition.
 
 Hum... Well, to me, what's important is that the code gets
 peer-reviewed.

Yes, the tricky part in FFmpeg and Libav in relation to this is that
theres quite a bit of code that is only well understood by a single
person even if you would combine both projects together.
So if that person posts a patch for review, theres noone who could
do a real review


 Setting-up something like gerrit may help, as it can be
 setup in a way that review becomes mandatory. Then discussing who's
 core-reviewer and can approve this or that part of the code can be setup
 within gerrit. This should be discussed, and setup based on technical merit.

Not commenting about gerrit as i dont have experience with it, but
FFmpeg currently uses a simple file in main ffmpeg git that lists
which part is maintained by whom, and these developers would in the
rare case of a dispute have the final say in each area.

OTOH, Libav early deleted their forked version of this file, and
iam not aware of any replacement. But others should explain how it
works in Libav ...


 
 Having a NACK review is often disappointing. It goes the wrong way if
 there's only a NACK with no comments on how to improve things, so that
 the code becomes acceptable.

 Absolutely everyone should *always* be able
 to leave comments, be it positive or negative.

yes, i fully agree and this also was always so in FFmpeg. In that
sense everyone is welcome to subscribe to ffmpeg-devel and review and
comment patches. That of course includes Libav developers and everyone
else. And more reviewers would also certainly help, so yeah anyone
reading this and wanting to help review patches, you are welcome!

Thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


signature.asc
Description: Digital signature


Re: First steps towards source-only uploads

2014-08-15 Thread Raphael Hertzog
On Fri, 15 Aug 2014, Hector Oron wrote:
 Even building arch:all packages in one architecture might solve the
 issue, I do not like that approach, as it holds other arches from
 building until that primary arch has built arch:all packages.

I understand the concern at the philosophical level but on a practical
level, using the fastest architecture we have is actually the way to
ensure that all arches get their arch all packages in the fastest possible
way.

 It also leads to not fully buildable packages for the rest of
 architectures, i.e. #690260 (openjdk-7: build empty doc packages on
 arm).

Those are bugs that can be found as part of QA activities, we don't have
to complicate our build infrastructure just to ensure that this specific
class of bugs gets found during build.

On the contrary, this is a sure way to create unexpected problems (by
letting bad arch all packages enter the archive) that
maintainers won't be able to anticipate as they do test-build their packages
on i386/amd64 mainly.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815130004.gc17...@x230-buxy.home.ouaza.com



Re: First steps towards source-only uploads

2014-08-15 Thread Henrique de Moraes Holschuh
On Fri, 15 Aug 2014, Raphael Hertzog wrote:
 On Fri, 15 Aug 2014, Hector Oron wrote:
  Even building arch:all packages in one architecture might solve the
  issue, I do not like that approach, as it holds other arches from
  building until that primary arch has built arch:all packages.
 
 I understand the concern at the philosophical level but on a practical
 level, using the fastest architecture we have is actually the way to
 ensure that all arches get their arch all packages in the fastest possible
 way.

And any package that cannot build arch:all on a released arch for which it
produces binary packages potentially has a FTBFS bug, anyway, which can be
reported by any interested parties.  Exceptions would be arches that are too
resource-constrained to build it in the first place.

IMHO, it is NOT the job of the autobuilders to track down and find every
FTBFS bug in Debian.  They cannot be expected to waste resources tracking
down FTBFS bugs that have no effect on the current operations of the
autobuilder network.

  It also leads to not fully buildable packages for the rest of
  architectures, i.e. #690260 (openjdk-7: build empty doc packages on
  arm).
 
 Those are bugs that can be found as part of QA activities, we don't have
 to complicate our build infrastructure just to ensure that this specific
 class of bugs gets found during build.

Agreed.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815133712.gc26...@khazad-dum.debian.net



Re: First steps towards source-only uploads

2014-08-15 Thread Ondřej Surý
On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote:
 And any package that cannot build arch:all on a released arch for which
 it produces binary packages potentially has a FTBFS bug, anyway, which
 can be reported by any interested parties.  Exceptions would be arches
 that are too resource-constrained to build it in the first place.

I have encountered a situation where the FTBFS bug was caused
by segfault in other package. This has forced me to split opendnssec-doc
to arch:all package (which was good thing anyway), so there are cases
where you want to build the arch:all on most stable and fastest arch.

Could we just pick amd64 and be done? :)

Cheers,
-- 
Ondřej Surý ond...@sury.org
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1408111452.213427.153089893.5c8a7...@webmail.messagingengine.com



Re: First steps towards source-only uploads

2014-08-15 Thread Henrique de Moraes Holschuh
On Fri, 15 Aug 2014, Ondřej Surý wrote:
 On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote:
  And any package that cannot build arch:all on a released arch for which
  it produces binary packages potentially has a FTBFS bug, anyway, which
  can be reported by any interested parties.  Exceptions would be arches
  that are too resource-constrained to build it in the first place.
 
 I have encountered a situation where the FTBFS bug was caused
 by segfault in other package. This has forced me to split opendnssec-doc
 to arch:all package (which was good thing anyway), so there are cases
 where you want to build the arch:all on most stable and fastest arch.
 
 Could we just pick amd64 and be done? :)

Yes, please :-)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815140823.ga1...@khazad-dum.debian.net



Standardizing the layout of git packaging repositories

2014-08-15 Thread Raphael Hertzog
Hello,

while git is the most popular VCS for packaging, there's no clear rules
on what you can expect in a random git packaging repository listed
in Vcs-Git. I would like to fix this so that:
- we can extract more useful data from the git repositories
- we can more easily share our git repositories with upstreams
  and downstreams
- we start to converge on some conventions even though we might
  continue to use different git helper tools

I want to use the DEP process for this. But before I can write a first
draft I would like to have your ideas of what we should include
in such a document.

Some initial questions and possible answers:

- how do we name the various branches?

  - vendor/master for the main development trunk (aka unstable in Debian)
  - vendor/codename for alternate versions

  The goal here is to be able to host in the same repository the branches for
  multiple cooperating distributions (at least so that downstream can
  clone the debian respository and inject their branches next to the
  debian branches).

- how do we tag the upstream releases?

  - upstream/version
  (note: we don't need an upstream branch, having the good tag for any
  release that the distros are packaging is enough, it can point to a
  synthetic commit built with tools like git-import-orig or to a real
  upstream commit)

- how do we tag the package releases?

  - pkg/version
  (note: git-buildpackage uses debian/version but I find this confusing
  as we then also have the debian/ prefix for ubuntu or kali uploads, we
  don't need the vendor prefix as the usual versioning rules embed the
  downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
  any conflict on the namespace, keeping a prefix is important to easily
  differentiate tags created by upstream developers from tags created
  by packagers)

- where should the HEAD point to in the public repository?

- shall we standardize the pristine-tar branch?

- the above layout is for the traditional case of non-native packages,
  what would be the layout for native packages? how can be differentiate
  between native/non-native layout?
  
- version encoding (due to git restrictions):
: - %
~ - _

- are there other important things to standardize?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815141601.ga11...@x230-buxy.home.ouaza.com



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Matteo F. Vescovi
Hi!

On 2014-08-15 at 16:16 (CEST), Raphael Hertzog wrote:
 [...] 
 - are there other important things to standardize?
 
Well, I don't know but I love this idea.

+1 for me.

Cheers.


-- 
Matteo F. Vescovi | Debian Maintainer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: Digital signature


Bug#758222: ITP: libjs-jsencrypt -- RSA Encryption in JavaScript

2014-08-15 Thread Thomas Goirand
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org

* Package name: libjs-jsencrypt
  Version : 2.0.0+dfsg1
  Upstream Author : Travis Tidwell travist...@gmail.com
* URL : http://travistidwell.com/jsencrypt/
* License : Expat
  Programming Lang: JavaScript
  Description : RSA Encryption in JavaScript

 JSEncrypt provides a simple wrapper around the fantastic work done by Tom Wu
 for RSA Encryption in JavaScript (ie: the jsbn Javascript library). JSEncrypt
 works hand-in-hand with openssl.
 .
 With JSEncrypt, you can generate private and public keypairs (it takes less
 than 6 seconds for generating a 2048 bits keypair on my laptop), then use them
 to encrypt and decrypt.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140815144422.24811.23525.report...@buzig.gplhost.com



Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-15 Thread Thomas Goirand
On 08/15/2014 08:20 PM, Michael Niedermayer wrote:
 Yes, the tricky part in FFmpeg and Libav in relation to this is that
 theres quite a bit of code that is only well understood by a single
 person even if you would combine both projects together.

Hum... Hang on here then! Does this mean that, in FFmpeg and/or Libav,
there's some parts of the code which are understood by no-one? Scary!

 So if that person posts a patch for review, theres noone who could
 do a real review

Then the person who posts the patch can leave it for review for a while
(you should define a policy so that for a while means something: for
example 2 or 3 weeks), and then if there's no negative review, he can
self-approve his patch.

 Absolutely everyone should *always* be able
 to leave comments, be it positive or negative.
 
 yes, i fully agree and this also was always so in FFmpeg. In that
 sense everyone is welcome to subscribe to ffmpeg-devel and review and
 comment patches. That of course includes Libav developers and everyone
 else. And more reviewers would also certainly help, so yeah anyone
 reading this and wanting to help review patches, you are welcome!

Well, using a mailing list to review patches is something we were doing
10 years ago. You should really consider using Gerrit (or something
equivalent, but I don't know anything that works the way Gerrit does).
The workflow will influence a lot the way contributors interact with
each other. Almost certainly in a *good* way.

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee25d9.7020...@debian.org



Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-15 Thread The Wanderer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 08/15/2014 11:23 AM, Thomas Goirand wrote:

 On 08/15/2014 08:20 PM, Michael Niedermayer wrote:

 Absolutely everyone should *always* be able to leave comments, be
 it positive or negative.
 
 yes, i fully agree and this also was always so in FFmpeg. In that
 sense everyone is welcome to subscribe to ffmpeg-devel and review
 and comment patches. That of course includes Libav developers and
 everyone else. And more reviewers would also certainly help, so
 yeah anyone reading this and wanting to help review patches, you
 are welcome!
 
 Well, using a mailing list to review patches is something we were
 doing 10 years ago.

It's also something the Linux kernel is still doing, with apparent
success.

I for one consider it to be a much more public, transparent, and
discoverable way to let proposed patches and the review of same be open
to public view, compared to the way various other projects seem to do
it.

Making sure everything passes through the mailing list, and most if not
all substantive discussion happens on the mailing list, is a lot better
than having some discussion on the mailing lists and some on a bug
tracker and some on IRC and some via private mail and so on. (The most
ridiculously extreme example of this fragmentation that I know of is
probably the Mozilla project.)

There's nothing wrong with having discussion in those various areas, of
course; it's probably inevitable, and it's even a good thing. It's just
that it's a lot harder for someone not intimately involved with the
project to follow discussion if it happens in such a variety of places,
and there's value to be found in making sure that everything passes
through one central (discussion-enabled) point before landing.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJT7izqAAoJEASpNY00KDJr8PwP+gNPrmz3G1SDFBP0WPW7WEn/
BBFAFkWXEkezThYnjqYfHxUjwHBZOOpLfykfhlx7uV5O+nqy5BDDMHLzBxVEvaKp
5On9SaRB6/DYzAf9HvSJm+teHqRtNP0xKrcjRI+AgQ9n3Meax3OWi7jiNSIijAlX
srvhfjqgRAdNIB+dAnv8uhWhsAbN0njAPqegolFunAG8ZlWA4kcA5zt5uVaQrWPZ
y8LqZ/bB7xYbqTAO+kENhNoMzItqANUKZNhJKW/Fk6Dln/kIKWYE5Uiiil2BOHc7
KNyPxvrfjAj/LYdazgknu2tcAlgHbPBbbjjqYFivkc2sG+9s1t5QkEdkdJw7w3v8
OQpUwwF3gRGHebp1ODtyCuVC8jsmtBAwM+s0H5aqF0Tp6NyjgYFxtYrfHvvnvXmX
1lew8VW6WogIlJ1wDXCS8057gR877wMa8r61d6XbdHXcnARxoFYI1ngUUsKYjXyU
YJkRgxTZTtUZ9QNfex8sdja1PiIw96m4XLeW1uTozRR0EcQRBarphBCscQhmp0Sm
pdopwrFYMnZtNOE2nEqbwQtkNm1AXmABG18GbhcPX7LqEXsys6Odn8o1zqJYpx2h
7aQzpXbhjHUwihelR5yV6dASRt1LBD3icCR0uoWaAb80b0Li9cdV07FLon20XExS
mwURtzhiqxowV931+Bvh
=Jxa+
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee2cea.1080...@fastmail.fm



Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

2014-08-15 Thread Michael Biebl
Am 15.08.2014 17:47, schrieb Gerrit Pape:
 Package: rsyslog
 Version: 8.2.2-3
 Severity: serious
 Justification: Policy 2.5
 
 Hi, the current rsyslog package version in testing is priority important
 and depends on packages with priority extra.  Policy 2.5 states:
 
 Packages must not depend on packages with lower priority values
 (excluding build-time dependencies).
 
 $ apt-cache show rsyslog |grep -E '^Version:|^Priority|^Depends'
 Version: 8.2.2-3
 Depends: libc6 (= 2.17), libestr0 (= 0.1.4), libjson-c2 (= 0.10), 
 liblogging-stdlog0 (= 1.0.2), liblognorm1 (= 0.3.0), libuuid1 (= 2.16), 
 zlib1g (= 1:1.1.4), init-system-helpers (= 1.18~), lsb-base (= 3.2-14), 
 initscripts (= 2.88dsf-13.3)
 Priority: important
 $ apt-cache show libestr0 libjson-c2 liblognorm1 init-system-helpers |grep 
 ^Priority
 Priority: extra
 Priority: extra
 Priority: extra
 Priority: extra
 $ 
 
 Regards, Gerrit.
 


I'm going to re-assign this bug to debian-policy as I want clarification
why debian-policy demands this.
So far, nobody was able to explain that requirement to me and the policy
text doesn't either.

That this rule is violated in hundreds of cases [1] clearly shows that
there is something wrong which needs to be addressed in a more idiomatic
way.

Michael


[1] https://qa.debian.org/debcheck.php?dist=sidlist=priorityarch=ANY
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Christian Kastner
On 2014-08-15 16:16, Raphael Hertzog wrote:
   - pkg/version
   (note: git-buildpackage uses debian/version but I find this confusing
   as we then also have the debian/ prefix for ubuntu or kali uploads, we
   don't need the vendor prefix as the usual versioning rules embed the
   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
   any conflict on the namespace, keeping a prefix is important to easily
   differentiate tags created by upstream developers from tags created
   by packagers)

On the contrary, I believe the argument can be made that mixing tags
from different distributions under one prefix -- as you propose -- would
be much more confusing.

Ideally speaking, debian/version currently tells me that every tag in
there corresponds to a Debian upload, and vice versa. Consequently, I
don't want to see a tag in there from downstream distros, as that
relationship would no longer hold.

That argument also holds from a downstream distro's POV.
ubuntu/1.0-0ubuntu1 might look redundant, but I find the upload-tag
relationship much more important that having slightly prettier tag names.

I think vendor/version is the way to go.

 - are there other important things to standardize?

dfsg branches are also common.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee30f7.7090...@kvr.at



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Alessandro Ghedini
On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
 - how do we tag the package releases?
 
   - pkg/version
   (note: git-buildpackage uses debian/version but I find this confusing
   as we then also have the debian/ prefix for ubuntu or kali uploads, we
   don't need the vendor prefix as the usual versioning rules embed the
   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
   any conflict on the namespace, keeping a prefix is important to easily
   differentiate tags created by upstream developers from tags created
   by packagers)

Letting aside the fact that pkg/... looks really ugly IMO, you are breaking
backwards compatibility with most git-buildpackage repositories for no real
benefit. If adopting this policy means that I have to somehow convert all my
repositories (possibly losing mildly useful information such as tag creation
date, tagger identity, tagger gpg signature, etc...), I'm not gonna do it.

Yes, if someone uses debian/... for e.g. ubuntu tags too (or uses some other
tag naming scheme), they'd have to change them, but I think it would be a much
smaller subset of both repositories and tags within a repsoitory.

Obviously one wouldn't be forced to convert their repositories to be compliant
to this policy, but if e.g. tooling based on this proposal is developed for
extracting information from repositories, and if there are very few repositories
actually compliant because it's too much of a PITA to convert, it's all gonna
be pretty useless.

Additionally, using the vendor/version scheme would allow for very simple
enumeration of debian vs. ubuntu vs. other with something like git tag | grep
^vendor/ without the need to actually parse debian/changelog or the specific
version of the tag (dunno if this would actually be useful for anything, but
it's a possibiliy).

Also, does every downstream distribution actually embed the distribution name
in the upload version or is it just ubuntu? Do they use the same scheme? Would
it be ok for this policy to depend on this?

 - where should the HEAD point to in the public repository?

Not sure what you mean by this.

 - shall we standardize the pristine-tar branch?

While I use pristine-tar, I feel like it's more of an implementation detail of
the building tools for the how to generate the orig tarball problem, than
something that should be standardized.

Also FWIW, pristine-tar is orphaned (see #737871, which contains some reasoning
about why using pristine-tar may not be a good idea).

 - the above layout is for the traditional case of non-native packages,
   what would be the layout for native packages? how can be differentiate
   between native/non-native layout?

I've never maintained a native package so I don't really know what are the
common practices, but AFAICT the only difference would be missing upstream/...
tags. Would that be enough for differentiating them?

 - are there other important things to standardize?

GPG signatures for tags? Although, I'm not sure if mandating signing tags would
be a good idea.

Cheers


signature.asc
Description: Digital signature


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Henrique de Moraes Holschuh
On Fri, 15 Aug 2014, Raphael Hertzog wrote:
 - how do we tag the package releases?
 
   - pkg/version
   (note: git-buildpackage uses debian/version but I find this confusing

 - shall we standardize the pristine-tar branch?

IMHO it should be reserved for pristine-tar usage (as in don't use it for
something else), but use of the pristine-tar tool should be optional at
best.

pristine-tar has been orphaned *upstream*, it has design problems, and lots
of real world issues.  I'm seriously considering a git branch -D
pristine-tar on my packages :(

 - the above layout is for the traditional case of non-native packages,
   what would be the layout for native packages? how can be differentiate
   between native/non-native layout?

Please don't.  It would be Really Troublesome should a package need to
switch from native to non-native, or the opposite.

If you're worried about an useless master branch, one can do away with it
with help of git symbolic-ref on bare repositories:

git symbolic-ref HEAD refs/heads/debian/master

will change a bare repo's default branch to debian/master, you can remove
the master branch after that.

 - version encoding (due to git restrictions):
 : - %
 ~ - _
 
 - are there other important things to standardize?

What to do with packages that already adopt other schemes?  A lot of
packages already use dgit, git-buildpackage, etc and have signed tags they
might want to preserve.

Also, tag namespace is shared with upstream, so it has to be somewhat
flexible in case the recommended scheme cannot be used.

What about commit and tag signing?  Release tags ought to always be signed
really, but should we recommend something about commits or just ignore that?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815162930.ga2...@khazad-dum.debian.net



Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

2014-08-15 Thread Michael Biebl
Am 15.08.2014 18:10, schrieb Michael Biebl:
 Am 15.08.2014 17:47, schrieb Gerrit Pape:
 Severity: serious
 Justification: Policy 2.5

[..]

 That this rule is violated in hundreds of cases [1] clearly shows that
 there is something wrong which needs to be addressed in a more idiomatic
 way.

 [1] https://qa.debian.org/debcheck.php?dist=sidlist=priorityarch=ANY

Gerrit, I see you started filing RC bugs for this.

Let's see if what the release team thinks about having an additional
~1800 RC bugs.


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

2014-08-15 Thread Bill Allombert
On Fri, Aug 15, 2014 at 06:31:39PM +0200, Michael Biebl wrote:
 Am 15.08.2014 18:10, schrieb Michael Biebl:
  Am 15.08.2014 17:47, schrieb Gerrit Pape:
  Severity: serious
  Justification: Policy 2.5
 
 [..]
 
  That this rule is violated in hundreds of cases [1] clearly shows that
  there is something wrong which needs to be addressed in a more idiomatic
  way.
 
  [1] https://qa.debian.org/debcheck.php?dist=sidlist=priorityarch=ANY
 
 Gerrit, I see you started filing RC bugs for this.

Please do not report RC bug for this. Priorities are adjusted by the FTP master
team by batch using the overrides file. There is no need to report bugs against
the packages.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815165144.GB27464@yellowpig



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Henrique de Moraes Holschuh
On Fri, 15 Aug 2014, Christian Kastner wrote:
 On 2014-08-15 16:16, Raphael Hertzog wrote:
- pkg/version
(note: git-buildpackage uses debian/version but I find this confusing
as we then also have the debian/ prefix for ubuntu or kali uploads, we
don't need the vendor prefix as the usual versioning rules embed the
downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
any conflict on the namespace, keeping a prefix is important to easily
differentiate tags created by upstream developers from tags created
by packagers)
 
 On the contrary, I believe the argument can be made that mixing tags
 from different distributions under one prefix -- as you propose -- would
 be much more confusing.
 
 Ideally speaking, debian/version currently tells me that every tag in
 there corresponds to a Debian upload, and vice versa. Consequently, I
 don't want to see a tag in there from downstream distros, as that
 relationship would no longer hold.

FWIW, I agree with you.  I'd also prefer to keep downstream release tags in
the vendor/mangled_version namespace.  Using vendor/mangled_version
for the downstream release tags is not that likely to clash with upstream,
as that's already somewhat common practice.

And IME it is no trouble to have vendor/* branches and vendor/* tags,
they rarely clash and they *are* on separate namespaces (if you specify the
full ref/ path, anyway).

 That argument also holds from a downstream distro's POV.
 ubuntu/1.0-0ubuntu1 might look redundant, but I find the upload-tag
 relationship much more important that having slightly prettier tag names.

Indeed.

And there is nothing confusing about ubuntu/master and debian/master
cross-merging, or merging from a common feature/development branch.  It
works well.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815170914.gb2...@khazad-dum.debian.net



Bug#758238: RFP: cool-old-term -- eye-candy terminal emulator which mimics old cathode displays

2014-08-15 Thread Axel Beckert
Package: wnpp
Severity: wishlist

* Package name: cool-old-term
  Version : no released version yet as it seems
  Upstream Author : Filippo Scognamiglio flsco...@gmail.com
* URL or Web page : https://github.com/Swordifish90/cool-old-term
* License : GPLv3+ (some parts seem also GPLv2)
  Description : eye-candy terminal emulator which mimics old cathode 
displays

cool-old-term is a terminal emulator which tries to mimic the look and
feel of the old cathode tube screens. It has been designed to be
eye-candy, customizable, and reasonably lightweight.

It uses the Konsole engine(*) which is powerful and mature.

This terminal emulator requires Qt 5.2 or higher to run.

(*) Some more details about this seem on

https://swordfishslabs.wordpress.com/2014/07/29/brace-yourself-cool-old-term-is-coming/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761htllww@kiva6.ethz.ch



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Thomas Goirand
On 08/15/2014 10:16 PM, Raphael Hertzog wrote:
 Some initial questions and possible answers:
 
 - how do we name the various branches?
 
   - vendor/master for the main development trunk (aka unstable in Debian)
   - vendor/codename for alternate versions
 
   The goal here is to be able to host in the same repository the branches for
   multiple cooperating distributions (at least so that downstream can
   clone the debian respository and inject their branches next to the
   debian branches).

I generally use debian/unstable, but sometimes, it's best to follow
upstream (for OpenStack, I use debian/icehouse, debian/juno, etc.), so
there's no one-size-fit-all here.

 - how do we tag the upstream releases?
 
   - upstream/version
   (note: we don't need an upstream branch, having the good tag for any
   release that the distros are packaging is enough, it can point to a
   synthetic commit built with tools like git-import-orig or to a real
   upstream commit)

Why would you tag the upstream release? I mean, it's upstream's job to
do so, and it's natural to use their git tagging and their git
repository, no?

 - how do we tag the package releases?
 
   - pkg/version
   (note: git-buildpackage uses debian/version but I find this confusing
   as we then also have the debian/ prefix for ubuntu or kali uploads, we
   don't need the vendor prefix as the usual versioning rules embed the
   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
   any conflict on the namespace, keeping a prefix is important to easily
   differentiate tags created by upstream developers from tags created
   by packagers)

Shouldn't ubuntu or kali use ubuntu/version and kali/version? I
don't see a problem here.

 - where should the HEAD point to in the public repository?

IMO, it should point to the packaging branch for Sid, but YMMV. Why is
this important?

 - shall we standardize the pristine-tar branch?

As in, always use pristine-tar? No! The point of using git packaging is
also to be able to use upstream git repo.

 - the above layout is for the traditional case of non-native packages,
   what would be the layout for native packages? how can be differentiate
   between native/non-native layout?

Sorry, which layout are you talking about? With pristine-tar? Well, I
don't think using pristine-tar is in any way traditional, it's just
one of the workflow, which I always avoid if upstream is using Git and
has correct tagging.

 - version encoding (due to git restrictions):
 : - %
 ~ - _

I do use ~ - _ myself. Very useful.

 - are there other important things to standardize?

Yes. Producing orig.tar.xz out of upstream tag should be industrialized,
and written in some tools, which we would all be using. I currently
do: ./debian/rules gen-orig-xz, but that shouldn't be specific to my own
packages.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ee4041.2090...@debian.org



Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

2014-08-15 Thread Henrique de Moraes Holschuh
On Fri, 15 Aug 2014, Michael Biebl wrote:
 Am 15.08.2014 17:47, schrieb Gerrit Pape:
  Package: rsyslog
  Version: 8.2.2-3
  Severity: serious
  Justification: Policy 2.5
  
  Hi, the current rsyslog package version in testing is priority important
  and depends on packages with priority extra.  Policy 2.5 states:
  
  Packages must not depend on packages with lower priority values
  (excluding build-time dependencies).

This rule was once really useful when we had tools that could not do
dependency resolution very well by themselves to sort out what needs to go
into d-i images, etc.

I am not sure it is still relevant, though, as the tools are a lot better
now.  This question should be asked in debian-boot@l.d.o, debian-cd@l.d.o,
and maybe even debian-release@l.d.o.

 That this rule is violated in hundreds of cases [1] clearly shows that
 there is something wrong which needs to be addressed in a more idiomatic
 way.

Maybe update the policy text to match reality?

Any packages depended upon by a higher priority package are, effectively,
raised to that package's priority.

That said, AFAIK the current text was also supposed to get people to think
twice before adding new dependencies to high-priority packages, and to get
some external input before they do it.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815172233.gc2...@khazad-dum.debian.net



Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra

2014-08-15 Thread Gerrit Pape
On Fri, Aug 15, 2014 at 06:51:44PM +0200, Bill Allombert wrote:
 Please do not report RC bug for this. Priorities are adjusted by the FTP 
 master
 team by batch using the overrides file. There is no need to report bugs 
 against
 the packages.

Hi, I filed three bugs for the extreme, where priority required depends
on priority extra in current jessie.  No fear, I won't do mass filing.

I queried all the numbers on this beforehand.  And I don't think it's
good to solve all this through ftp master's override[0].  This will
bloat the installations using high priority packages more and more.

In stable we have the following violations (packages)
 important: 8
 required: 2
 standard: 21
In current testing:
 important: 15
 required: 5
 standard: 43

It's not hundreds, or thousands.  Keep cool.
rsyslog was fine when we raised its priority in wheezy.

I personally don't care that much about the standard priority, but for
the higher ones, and definitely think we should stop this trend before
it's too late.

You can play with the tiny dash script attached, it was fun to write
it, call
 ./check-prio required
 ./check-prio required important
 ./check-prio required important standard

Regards, Gerrit.

[0] current signs are that this will pull perl into the required
packages set:
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-August/thread.html#3161
#!/bin/sh
set -e

priorities=${*:=required important standard optional}

aptitudeprios=$(for i in $priorities; do echo ~p$i\ ; done)
aptitude search $aptitudeprios -F%p | sed -e's/^ *//;s/ *$//' |
while read package; do
  depends=$(apt-cache show $package |grep '^Depends: ' || :)
  depends=${depends#Depends: }
  buggy=; broken=
  IFS=,
  for dep in $depends; do
dep=${dep%%| *}
dep=${dep##[ *]}; dep=${dep%%[ *]}
dep=${dep%% (*)}; dep=${dep%%\[*\]}; dep=${dep%% (*)}
prio=$(apt-cache show $dep |grep '^Priority: ' |head -n1)
test -n $prio ||
  { echo \ warning: $package: depends $dep: no priority; continue; }
prio=${prio#Priority: }
broken=yes
IFS=\ 
for i in $priorities; do
  test $prio != $i || broken=
done
test -z $broken ||
  { echo \ broken: $package: depends $dep, priority $prio.; buggy=yes; }
  done
  test -z $buggy || echo buggy: $package
done


Python 3.4

2014-08-15 Thread Diogene Laerce
Hi,

Does someone have any clue or hint on the upgrade of Debian to Python3
natively ?

Thank you,

-- 
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

  Diogene Laerce





signature.asc
Description: OpenPGP digital signature


Re: Python 3.4

2014-08-15 Thread Paul Tagliamonte
On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:
 Hi,
 
 Does someone have any clue or hint on the upgrade of Debian to Python3
 natively ?
 
 Thank you,

Hey Diogene,

Python 3.4 is in Jessie, ready for action. I can confirm it works great,
It's all I use for my personal projects (in fact, I actually complain a
lot when I have to use Python 2 for some reason).

the /usr/bin/python command is unlikely to change soon; more information
on how this should be treated on UNIX like systems can be found at PEP 0394.


There's currently a big push to ensure we're all Python 3 compatable,
but that's something distinct from changing /usr/bin/python to point at
/usr/bin/python3.


Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte paul...@debian.org  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature


Re: Debian Installer Jessie Beta 1 release

2014-08-15 Thread Stephen Allen
On Wed, Aug 13, 2014 at 06:15:05PM +0200, Cyril Brulebois wrote:
 The Debian Installer team[1] is pleased to announce the first beta
 release of the installer for Debian 8 Jessie.

Thanks.
 
[ ...] 
 
 Known bugs in this release
 ==
 
  * Firmware handling: udev no longer reports missing firmware
(#725714), and patches for the kernel need polishing before we are
able to restore support for loading missing firmware.
  * GNU/kFreeBSD installation images suffer from various important bugs
(#757985, #757986, #757987, #757988). Porters could surely use some
helping hands to bring the installer back into shape!
 
 See the errata[2] for details and a full list of known issues.

[ ...]
 
 
  1. http://wiki.debian.org/DebianInstaller/Team
  2. http://www.debian.org/devel/debian-installer/errata
  3. http://www.debian.org/devel/debian-installer

---end quoted text---

Any changes between alpha errata to beta?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815175903.GA32385@Jessie



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Simon McVittie
On 15/08/14 15:16, Raphael Hertzog wrote:
 Some initial questions and possible answers:

I've been hesitating on whether to ask this because it gets into
questions of workflow and repo structure that are very much a matter of
taste and don't have a single widely-declared-to-be-good answer, but I
think one of the important questions is: what is actually on the vendor
(e.g. Debian) branch?

The big question is are vendor patches pre-applied or not? but a
follow-up question, for 3.0 (quilt) packages, is does .pc reflect that?

I use gbp-pq for my own packages, so I would appreciate it if people who
actively use the other repo structures/helper tools could correct my
mistakes and discuss their advantages and disadvantages.

gbp-pq (from git-buildpackage), with imported tarballs in git
-

gbp-pq encourages the answer to be pristine contents of tarball plus a
debian/ directory containing a quilt patch series, those patches are
*not* applied to the upstream sources as they appear in the repo, .pc
does not exist. This is the policy in all the teams in which I'm active
(possibly excluding pkg-games which might not have an overall policy)
and the one I personally prefer, at least at the moment. It has the
advantage that you don't have to rebase a published branch (which is
Bad™) in order to rebase the vendor patches onto new upstream versions
(which is something you'll be doing all the time in most packages). It
has the disadvantage that you can't just cherry-pick an upstream commit,
you have to do non-git-ish things like dropping a git-format-patch into
debian/patches or using gbp-pq.

systemd's current README.source
http://sources.debian.net/src/systemd/208-7/debian/README.source/ is a
good set of instructions for doing common maintainer/NMUer things in a
gbp-pq tree. You can also build from such a tree with a plain
`dpkg-buildpackage`.

I conjecture that maintainers who are used to things that are not git
(particularly svn, as used by pkg-perl, pkg-gnome, pkg-python-* etc.)
will also feel at home with this structure: it is entirely possible to
not use gbp-pq, and instead apply/unapply patches with quilt.

git-import-orig knows how to merge upstream VCS tags into an upstream
branch that is otherwise based on imported tarballs, so it is possible
to have the upstream/* commits reflect what was in imported tarballs but
still have your upstream's git commits as an ancestor.

gbp-pq (from git-buildpackage), with upstream git as base
-

As long as you don't need to patch any files that do not exist in
upstream git but only in the tarball (e.g. use dh-autoreconf instead of
patching Makefile.in), and you don't have to drop any upstream files
(e.g. for DFSG reasons), it is possible to use upstream git as your
basis for branching, instead of importing tarballs. That's how systemd
is packaged at the moment.

git-buildpackage --git-export, with only debian/ in git
---

It is possible to use git-buildpackage with --git-export (either
explicitly, or configured in debian/gbp.conf) for packages that only
keep debian/ in git. In this situation, the only possibility is to have
patches *not* pre-applied, because there is nothing there to patch. This
matches how teams like pkg-gnome have traditionally used svn.

I would strongly recommend having upstream source in git, not just
debian/, with one exception: packages like openarena-data, which mostly
contain giant binary files that cannot meaningfully be patched.

git-dpm
---

git-dpm encourages the contents of the vendor branch to be exactly the
source that will be built, vendor patches *are* applied and uses a
relatively elaborate merging structure to avoid rebasing
(http://git-dpm.alioth.debian.org/). I don't know whether .pc is
typically present in the tree for 3.0 (quilt) packages or not, or
whether users of git-dpm avoid 3.0 (quilt) format altogether.

gitpkg
--

As far as I can tell, gitpkg encourages the answer to be exactly the
source that will be built, vendor patches *are* applied, but .pc is not
present in git. However, I could be wrong. When I tried to apply
downstream patches to a version of systemd that used gitpkg, I got
confused enough to just give up on using the maintainers' git tree and
re-import it with git-import-dsc instead.

(systemd has since switched to the gbp-pq layout, which I found much
easier to deal with.)

dgit


dgit encourages the answer to be exactly the source that will be built,
vendor patches *are* applied, if the package uses 3.0 (quilt) then .pc
also exists and reflects the state of the tree. I'm not sure what
techniques dgit users use to deal with non-native packages that have
vendor patches without rebasing a published branch - git-dpm seems like
it might be a good fit?

There seems to be a strong correlation between happy dgit users, and
those who either only do 

Bug#758245: ITP: libcli-framework-perl -- standardized, flexible, testable CLI applications framework for Perl

2014-08-15 Thread Bálint Réczey
Package: wnpp
Owner: Balint Reczey bal...@balintreczey.hu
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcli-framework-perl
  Version : 0.05
  Upstream Author : Karl Erisman keris...@cpan.org
* URL : https://metacpan.org/release/CLI-Framework
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : standardized, flexible, testable CLI applications
framework for Perl

 CLI::Framework (CLIF) provides a framework and conceptual pattern for
 building full-featured command line applications. It intends to make
 this process simple and consistent. It assumes the responsibility of
 implementing details that are common to all command-line applications,
 making it possible for new applications adhering to well-defined
 conventions to be built without the need to repeatedly write the same
 command-line interface code.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpzpmTJf2Xc-6R-CVE7U4B7j=tfoFW5ON=tppagd368...@mail.gmail.com



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Marco d'Itri
On Aug 15, Raphael Hertzog hert...@debian.org wrote:

 - we can more easily share our git repositories with upstreams
   and downstreams
Did they ask for this?

 - how do we tag the upstream releases?
   - upstream/version
Some of my packages just use the real upstream git tree as their 
upstream branch, so the upstream releases are already tagged using the 
upstream scheme.

 - how do we tag the package releases?
   - pkg/version
Other people already shot down this with good arguments.

 - shall we standardize the pristine-tar branch?
Shall we kill pristine-tar instead, since it is mostly a waste of space 
for everybody without an md5 fetish?

 - are there other important things to standardize?
Do not try to make other people change their workflows without evident 
benefits (pro tip: standardization in itself is not one) or they will 
be annoyed and just ignore your work.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-15 Thread Bálint Réczey
Hi,

2014-08-15 14:20 GMT+02:00 Michael Niedermayer michae...@gmx.at:
 On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote:
 On 08/14/2014 11:59 PM, The Wanderer wrote:
  On 08/14/2014 11:27 AM, Thomas Goirand wrote:
 
  On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
 
  On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
 
  Also ive offered my resignation in the past. I do still offer to
  resign from the FFmpeg leader position, if it resolves this split
  between FFmpeg and Libav and make everyone work together again.
 
  Why not just take the offer, and move on?
 
  Probably because of the condition he attached to it, which also dates
  back to the arguments preceding the original split:
 
  The part i insist on though is that everyone must be able to work
  on their code without people uninvolved in that specific parts
  maintaince or authorship being able to block their work.
 
  In other words, as I think I understand it from the discussion back
  then: people not involved with a particular area of the code can't NACK
  the work of someone who is working on it, and someone who works on a
  particular area of the code doesn't have to wait on review of people who
  aren't involved with that area of the code.
 
  Since one of the motivations of the people behind the libav side of the
  split seems, IIRC, to have been no code gets in without having been
  reviewed by someone other than the author, this was apparently deemed
  an unacceptable condition.

 Hum... Well, to me, what's important is that the code gets
 peer-reviewed.

 Yes, the tricky part in FFmpeg and Libav in relation to this is that
 theres quite a bit of code that is only well understood by a single
 person even if you would combine both projects together.
 So if that person posts a patch for review, theres noone who could
 do a real review
This situation is not totally unique to FFmpeg/Libav. IMO in this
real-life situation peers can do a best-effort review and people doing
so would sooner or later will get familiar with those parts of the
code as well.
In case of a widely used library like this the biggest issue is
breaking the ABI or modifying the ABI in a way which does not align
with the team's vision about the ABI roadmap. That type of change can
be pointed out by less experienced developers, too.
Internal regressions in the code can be easily fixed even if they are
not discovered during testing and enter the release.



 Setting-up something like gerrit may help, as it can be
 setup in a way that review becomes mandatory. Then discussing who's
 core-reviewer and can approve this or that part of the code can be setup
 within gerrit. This should be discussed, and setup based on technical merit.

 Not commenting about gerrit as i dont have experience with it, but
 FFmpeg currently uses a simple file in main ffmpeg git that lists
 which part is maintained by whom, and these developers would in the
 rare case of a dispute have the final say in each area.
Using Gerrit and file ownersip are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to Gerrit at the
Wireshark project and it helps a lot in coordinating the reviews.

Cheers,
Balint


 OTOH, Libav early deleted their forked version of this file, and
 iam not aware of any replacement. But others should explain how it
 works in Libav ...



 Having a NACK review is often disappointing. It goes the wrong way if
 there's only a NACK with no comments on how to improve things, so that
 the code becomes acceptable.

 Absolutely everyone should *always* be able
 to leave comments, be it positive or negative.

 yes, i fully agree and this also was always so in FFmpeg. In that
 sense everyone is welcome to subscribe to ffmpeg-devel and review and
 comment patches. That of course includes Libav developers and everyone
 else. And more reviewers would also certainly help, so yeah anyone
 reading this and wanting to help review patches, you are welcome!

 Thanks

 [...]
 --
 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

 it is not once nor twice but times without number that the same ideas make
 their appearance in the world. -- Aristotle


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpwaj1irea2ymdznjqwkw+hhep3yg-vvuy8mp8hje3d...@mail.gmail.com



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Scott Kitterman
On August 15, 2014 10:16:01 AM EDT, Raphael Hertzog hert...@debian.org wrote:
Hello,

while git is the most popular VCS for packaging, there's no clear rules
on what you can expect in a random git packaging repository listed
in Vcs-Git. I would like to fix this so that:
- we can extract more useful data from the git repositories
- we can more easily share our git repositories with upstreams
  and downstreams
- we start to converge on some conventions even though we might
  continue to use different git helper tools

I want to use the DEP process for this. But before I can write a first
draft I would like to have your ideas of what we should include
in such a document.

Some initial questions and possible answers:

- how do we name the various branches?

- vendor/master for the main development trunk (aka unstable in
Debian)
  - vendor/codename for alternate versions

The goal here is to be able to host in the same repository the branches
for
  multiple cooperating distributions (at least so that downstream can
  clone the debian respository and inject their branches next to the
  debian branches).

- how do we tag the upstream releases?

  - upstream/version
 (note: we don't need an upstream branch, having the good tag for any
  release that the distros are packaging is enough, it can point to a
  synthetic commit built with tools like git-import-orig or to a real
  upstream commit)

- how do we tag the package releases?

  - pkg/version
(note: git-buildpackage uses debian/version but I find this confusing
as we then also have the debian/ prefix for ubuntu or kali uploads,
we
  don't need the vendor prefix as the usual versioning rules embed the
downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't
be
 any conflict on the namespace, keeping a prefix is important to easily
  differentiate tags created by upstream developers from tags created
  by packagers)

- where should the HEAD point to in the public repository?

- shall we standardize the pristine-tar branch?

- the above layout is for the traditional case of non-native packages,
 what would be the layout for native packages? how can be differentiate
  between native/non-native layout?
  
- version encoding (due to git restrictions):
: - %
~ - _

- are there other important things to standardize?

We don't even agree on if repositories should be full source or Debian 
directory only. Not sure how we can even start to discuss the rest if we don't 
agree on that. 

Scott K



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/dd4ca987-e3ca-4304-b8c4-e9afa0e5a...@email.android.com



Re: Python 3.4

2014-08-15 Thread Scott Kitterman
On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte paul...@debian.org wrote:
On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:
 Hi,
 
 Does someone have any clue or hint on the upgrade of Debian to
Python3
 natively ?
 
 Thank you,

Hey Diogene,

Python 3.4 is in Jessie, ready for action. I can confirm it works
great,
It's all I use for my personal projects (in fact, I actually complain a
lot when I have to use Python 2 for some reason).

the /usr/bin/python command is unlikely to change soon; more
information
on how this should be treated on UNIX like systems can be found at PEP
0394.

s/soon/ever/

It's more likely /usr/bin/python will someday be removed than someday point to 
a python3 version. 

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cb3f3e44-09ec-4e0c-abbf-3c11025b3...@email.android.com



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Andrew Kelley
On Fri, Aug 15, 2014 at 11:17 AM, Marco d'Itri m...@linux.it wrote:

  - shall we standardize the pristine-tar branch?
 Shall we kill pristine-tar instead, since it is mostly a waste of space
 for everybody without an md5 fetish?


Can you explain what you mean by this, for someone who is relatively new to
packaging? What is the alternative to pristine-tar?


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Marco d'Itri
On Aug 15, Andrew Kelley superjo...@gmail.com wrote:

   - shall we standardize the pristine-tar branch?
  Shall we kill pristine-tar instead, since it is mostly a waste of space
  for everybody without an md5 fetish?
 Can you explain what you mean by this, for someone who is relatively new to
 packaging? What is the alternative to pristine-tar?
The first step is to determine which problem you are trying to solve.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Debian Installer Jessie Beta 1 release

2014-08-15 Thread David Prévot
Hi,

Le 15/08/2014 13:59, Stephen Allen a écrit :
 On Wed, Aug 13, 2014 at 06:15:05PM +0200, Cyril Brulebois wrote:
 The Debian Installer team[1] is pleased to announce the first beta
 release of the installer for Debian 8 Jessie.
 
 Thanks.

+1

 Any changes between alpha errata to beta?

http://anonscm.debian.org/viewvc/webwml/webwml/english/devel/debian-installer/errata.wml?r1=1.200r2=1.201

Regards

David





signature.asc
Description: OpenPGP digital signature


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Steve Langasek
On Fri, Aug 15, 2014 at 01:36:24PM -0700, Andrew Kelley wrote:
 On Fri, Aug 15, 2014 at 11:17 AM, Marco d'Itri m...@linux.it wrote:

   - shall we standardize the pristine-tar branch?
  Shall we kill pristine-tar instead, since it is mostly a waste of space
  for everybody without an md5 fetish?

 Can you explain what you mean by this, for someone who is relatively new to
 packaging? What is the alternative to pristine-tar?

The alternative is handwaving and ignoring the fact that your package
repository is not a complete representation of your package as it exists in
the archive.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Re: Python 3.4

2014-08-15 Thread Diogene Laerce


On 08/15/2014 07:42 PM, Paul Tagliamonte wrote:
 On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:
 Does someone have any clue or hint on the upgrade of Debian to Python3
 natively ?
 
 Python 3.4 is in Jessie, ready for action. I can confirm it works great,
 It's all I use for my personal projects (in fact, I actually complain a
 lot when I have to use Python 2 for some reason).
 
 the /usr/bin/python command is unlikely to change soon; more information
 on how this should be treated on UNIX like systems can be found at PEP 0394.
 
 There's currently a big push to ensure we're all Python 3 compatable,
 but that's something distinct from changing /usr/bin/python to point at
 /usr/bin/python3.

I just downloaded Jessie, going to VM it.

Thanks for the link as well. :)
-- 
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

  Diogene Laerce



signature.asc
Description: OpenPGP digital signature


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Marco d'Itri
On Aug 15, Steve Langasek vor...@debian.org wrote:

 The alternative is handwaving and ignoring the fact that your package
 repository is not a complete representation of your package as it exists in
 the archive.
It is not obvious why this would be a problem.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: Python 3.4

2014-08-15 Thread Diogene Laerce


On 08/15/2014 10:20 PM, Scott Kitterman wrote:
 On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte paul...@debian.org 
 wrote:
 On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:

[...]


 the /usr/bin/python command is unlikely to change soon; more
 information
 on how this should be treated on UNIX like systems can be found at PEP
 0394.
 
 It's more likely /usr/bin/python will someday be removed than someday point 
 to a python3 version. 

No python on the OS ? Regard to the number of applications that rely on
python, that's kind of unlikely no ?

Cheers,
-- 
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

  Diogene Laerce



signature.asc
Description: OpenPGP digital signature


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Guido Günther
On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote:
 Hello,
 
 while git is the most popular VCS for packaging, there's no clear rules
 on what you can expect in a random git packaging repository listed
 in Vcs-Git. I would like to fix this so that:
 - we can extract more useful data from the git repositories
 - we can more easily share our git repositories with upstreams
   and downstreams
 - we start to converge on some conventions even though we might
   continue to use different git helper tools
 
 I want to use the DEP process for this. But before I can write a first
 draft I would like to have your ideas of what we should include
 in such a document.
 
 Some initial questions and possible answers:
 
 - how do we name the various branches?
 
   - vendor/master for the main development trunk (aka unstable in Debian)
   - vendor/codename for alternate versions

The gbp manual has a recommended branch layout:

  
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING

which could serve as a basis. There's plenty of room for improvement,
e.g. the case where one tracks upstream git isn't yet mentioned (I
started to follow the above layout also in this case).

   The goal here is to be able to host in the same repository the branches for
   multiple cooperating distributions (at least so that downstream can
   clone the debian respository and inject their branches next to the
   debian branches).
 
 - how do we tag the upstream releases?
 
   - upstream/version
   (note: we don't need an upstream branch, having the good tag for any
   release that the distros are packaging is enough, it can point to a
   synthetic commit built with tools like git-import-orig or to a real
   upstream commit)

Agreed, although having a branch (and recommended naming convention)
can be useful.

 - how do we tag the package releases?
 
   - pkg/version
   (note: git-buildpackage uses debian/version but I find this confusing
   as we then also have the debian/ prefix for ubuntu or kali uploads, we
   don't need the vendor prefix as the usual versioning rules embed the
   downstream distribution name (e.g. 1.0-0ubuntu1) and thus there can't be
   any conflict on the namespace, keeping a prefix is important to easily
   differentiate tags created by upstream developers from tags created
   by packagers)

The tag format is configurable in gbp and I'd expect downstreams to
use a different name space (e.g. ubuntu/version). This makes it
simpler to tab complete (or delete) certain groups of tags. A patch to
make the tag message configurable too is waiting to be applied. pkg/
is too generic since we'll have more of the RPM support upstreamed
soonish.

Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815191055.ga2...@bogon.m.sigxcpu.org



Re: Python 3.4

2014-08-15 Thread Scott Kitterman
On August 15, 2014 4:57:19 PM EDT, Diogene Laerce me_buss...@yahoo.fr wrote:


On 08/15/2014 10:20 PM, Scott Kitterman wrote:
 On August 15, 2014 1:42:04 PM EDT, Paul Tagliamonte
paul...@debian.org wrote:
 On Fri, Aug 15, 2014 at 07:28:06PM +0200, Diogene Laerce wrote:

[...]


 the /usr/bin/python command is unlikely to change soon; more
 information
 on how this should be treated on UNIX like systems can be found at
PEP
 0394.
 
 It's more likely /usr/bin/python will someday be removed than someday
point to a python3 version. 

No python on the OS ? Regard to the number of applications that rely on
python, that's kind of unlikely no ?

Cheers,

Pointing /usr/bin/python at a python3 version is not providing python in that 
sense. If something uses python3, it should use /usr/bin/python3.  Someday, in 
the distant future, /usr/bin/python should become irrelevant. It should never 
point at a python3 version. 

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/831ef6a7-6f9d-4f45-954e-ea30a10ff...@email.android.com



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread brian m. carlson
On Fri, Aug 15, 2014 at 08:17:16PM +0200, Marco d'Itri wrote:
 On Aug 15, Raphael Hertzog hert...@debian.org wrote:
  - are there other important things to standardize?
 Do not try to make other people change their workflows without evident
 benefits (pro tip: standardization in itself is not one) or they will
 be annoyed and just ignore your work.

I send a lot of one-off patches to packages.  I like to file a bug and
follow it up with a patch.  Unfortunately, everybody doing things a
different way makes it unpleasant to do that.  (And yes, I know about
README.source.)

Right now, I just build the source package repeatedly until it works,
unless the package doesn't build twice in a row, in which case I swear
repeatedly and no patch is sent.  If there's a standard workflow, it
makes my life easier and results in a patch that works better for the
maintainer.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Don Armstrong
On Fri, 15 Aug 2014, Marco d'Itri wrote:
 On Aug 15, Steve Langasek vor...@debian.org wrote:
  The alternative is handwaving and ignoring the fact that your package
  repository is not a complete representation of your package as it exists in
  the archive.

 It is not obvious why this would be a problem.

Because you're a Debian Developer and might want to upload a package to
the archive without downloading the uploaded tarball which substantially
duplicates what you have in your source tree? Or you're collaborating
with someone and need to use a repacked tarball?

-- 
Don Armstrong  http://www.donarmstrong.com

I'm wrong to criticize the valor of your brave men. It's important to
die for one's country when it means being the subject of a king who
wears a ruffled collar or a pleated one.
 -- Cyrano de Bergerac


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815230917.gl22...@teltox.donarmstrong.com



Bug#758178: screen resolution reverts to minimum when not selected by KVM

2014-08-15 Thread Tomasz Nitecki
tag 758178 + moreinfo
thanks


Hey,

Can you please provide us with some more details about your problem?

1. Are there any suspicious messages in dmesg or gnome log after the
screen resolution drops to 600x480? Can you please attach them both?

2. Can you ssh to an affected machine after it black outs (that is after
trying to reset the resolution)? If so, are there any error messages in
dmesg or gnome log? Please attach them if you can connect.

3. If you restart X server after the screen resolution drops, does it
get back to normal?

4. Did you (or can you) try if this problem also occurs while using any
other desktop environment?


Regards,
T.



signature.asc
Description: OpenPGP digital signature


Processed: screen resolution reverts to minimum when not selected by KVM

2014-08-15 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tag 758178 + moreinfo
Bug #758178 [general] general: screen resolution reverts to minimum when not 
selected by KVM
Added tag(s) moreinfo.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
758178: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758178
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.c.140814453026469.transcr...@bugs.debian.org



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Jeremy Stanley
On 2014-08-16 01:15:45 +0800 (+0800), Thomas Goirand wrote:
[...]
 Yes. Producing orig.tar.xz out of upstream tag should be industrialized,
 and written in some tools, which we would all be using. I currently
 do: ./debian/rules gen-orig-xz, but that shouldn't be specific to my own
 packages.

However upstream may build tarballs through a (hopefully
repeatable/automated) process at release time, publish checksums and
signatures for them, et cetera, and prefer packagers use those as
the original tarballs for official release versions. I understand
needing to create original tarballs yourself in cases where there
are none (for example making development snapshot packages), but
when upstream provides them it seems like it would make sense to use
those tarballs in lieu of trying to recreate your own from tags in
their version control system.

I have become increasingly wary now that more and more slipshod
upstreams with no release process have created a need for package
maintainers to fabricate one on their behalf, the kludge can get
turned back around on upstreams with formal, traditional release
processes and used as a convenient excuse to discard their output in
the name of consistency. *Please* don't replace upstream's release
tarballs just because they have a VCS.
-- 
Jeremy Stanley


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140815230550.gp1...@yuggoth.org



Re: Python 3.4

2014-08-15 Thread Brian May
On 16 August 2014 03:42, Paul Tagliamonte paul...@debian.org wrote:

 There's currently a big push to ensure we're all Python 3 compatable,


Note that there is a huge number of Python packages in Debian. It is very
possible that your favourite packages aren't available as Python3 Debian
packages, either because upstream doesn't support Python 3, or because
nobody has done the work yet to make the Python 3 package.

For me, at least, the list of packages in demand is steadily going down,
especially if you consider the packages currently stuck in NEW.

On that note, is it ok for me to upload packages that depend on packages
stuck in NEW, or do I have to wait for the packages to clear NEW first? I
have at least one pending Python3 package in this situation.
-- 
Brian May br...@microcomaustralia.com.au


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Scott Kitterman
On Friday, August 15, 2014 23:04:54 brian m. carlson wrote:
 On Fri, Aug 15, 2014 at 08:17:16PM +0200, Marco d'Itri wrote:
  On Aug 15, Raphael Hertzog hert...@debian.org wrote:
   - are there other important things to standardize?
  
  Do not try to make other people change their workflows without evident
  benefits (pro tip: standardization in itself is not one) or they will
  be annoyed and just ignore your work.
 
 I send a lot of one-off patches to packages.  I like to file a bug and
 follow it up with a patch.  Unfortunately, everybody doing things a
 different way makes it unpleasant to do that.  (And yes, I know about
 README.source.)
 
 Right now, I just build the source package repeatedly until it works,
 unless the package doesn't build twice in a row, in which case I swear
 repeatedly and no patch is sent.  If there's a standard workflow, it
 makes my life easier and results in a patch that works better for the
 maintainer.

This gets to why, for teams I work in where full source git branches are used, 
I really like git-dpm.  The output of the git-dpm workflow is a version 3.0 
(quilt) package with all the upstream changes in segregated patches per commit 
so they make logical sense.  That way, any third party that needs to address 
an issue in the package can do so with no reference at all to a VCS repo.  
They just work on the Debian source package that is available in the most 
common type that is used in the archive.

The packager's VCS is mostly useful for the people who normally work on the 
package.  For others, the source package is the most useful thing.  About the 
only thing I use the VCS of packages that aren't normally ones I work on for 
is to understand the history of something to try and figure out where it went 
wrong.

Whatever is standardized it really, really ought to produce a useful source 
package as that's the preferred form of modification in the project.

Scott K


signature.asc
Description: This is a digitally signed message part.


Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Russ Allbery
m...@linux.it (Marco d'Itri) writes:
 On Aug 15, Andrew Kelley superjo...@gmail.com wrote:

 Can you explain what you mean by this, for someone who is relatively
 new to packaging? What is the alternative to pristine-tar?

 The first step is to determine which problem you are trying to solve.

I want to be able to check out a git repository and do packaging work and
an upload, without having to pull any external artifacts from somewhere
else.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ha1djj45@hope.eyrie.org



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Henrique de Moraes Holschuh
On Fri, 15 Aug 2014, Steve Langasek wrote:
 The alternative is handwaving and ignoring the fact that your package
 repository is not a complete representation of your package as it exists in
 the archive.

What's wrong with storing the upstream tarballs themselves on a separate
branch, if you're that desperate to have them inside the same git repo as
the code?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816015310.ga22...@khazad-dum.debian.net



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Russ Allbery
Henrique de Moraes Holschuh h...@debian.org writes:
 On Fri, 15 Aug 2014, Steve Langasek wrote:

 The alternative is handwaving and ignoring the fact that your package
 repository is not a complete representation of your package as it
 exists in the archive.

 What's wrong with storing the upstream tarballs themselves on a separate
 branch, if you're that desperate to have them inside the same git repo
 as the code?

I like Git repositories that are about 10MB rather than 200MB or more.
(And yes, I have used exactly that approach in the past, and know exactly
how painful having all the tarballs in the revision control system is.
Never again.)

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738cxjhbm@hope.eyrie.org



Re: Standardizing the layout of git packaging repositories

2014-08-15 Thread Charles Plessy
Le Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog a écrit :
 
 while git is the most popular VCS for packaging, there's no clear rules
 on what you can expect in a random git packaging repository listed
 in Vcs-Git. I would like to fix this so that:
 - we can extract more useful data from the git repositories
 - we can more easily share our git repositories with upstreams
   and downstreams
 - we start to converge on some conventions even though we might
   continue to use different git helper tools
 
 I want to use the DEP process for this. But before I can write a first
 draft I would like to have your ideas of what we should include
 in such a document.

Bonjour Raphaël,

I think that it is a good idea to propose a standard that packaging team and
individual developers can follow optionally if they like it.  In the Debian Med
packaging team, I would be glad to be able to replace the guidelines in our
group with a pointer to the DEP that you propose to write.

Here are a few comments.

Regarding the name of the branches, I think that it would be preferable to
systematically use a prefix, ‘debian’, and I think that ‘debian/unstable’ is
more consistent than ‘debian/master’.  For the backports, I have been using
‘debian/wheezy-backports’, etc.  Altogether, the pattern is ‘debian/suite’. 

The ‘pristine-tar’ branch, while mostly used for Debian, is universal in
principle (who would knowingly release a tarball with the same name and a
different content from an alreadly circulating tarball ?), and therefore
probably does not need a ‘debian’ prefix.  Pristine-tar has been useful to
avoid preparing an upload with a tarball that has the same content but a
different MD5 sum than the one in the archive (because of time stamps, etc).
The interest for this is a bit reduced now that we have source-only uploads
(which are easier to prepare), but I think that it is still a good thing to
have for source packages based on upstream tarballs.

The ‘upstream’ branch generated and used by the tools from ‘git-buildpackage’
is usually different from the master branch of the upstream Git repository when
it exists.  While this branch name is well-established in Debian, I think that
it is misleading and for my new packages I try to avoid it.  When it is still
necessary to import upstream tarballs, I would rather use a name under the 
‘debian/’
prefix.  When the upstream master branch is enough, I prefer to leave it under
the name ‘master’.

Of course, the Debian clones of the repository should use a debian branch by
default, like ‘debian/unstable’.

For the Debian tags, I think that we definitely need a prefix, as I have seen
upstream releases like 1.0 being followed by 1.0-1…  The tag prefix debian
can be seen as identifying the distribution or the format; I would not mind if
there were Ubuntu packages tagged with a debian prefix.

The following is probably too rarely used to standardise, but maybe somebody
has an insightful comment to make ?  I have been storing build logs in the Git
repositories of some source packages I maintain.  At the beginning, I called
the branch ‘meta‘ and had all the logs in the same branch, and later I tried
things like debian/logs/unstable to separate suites, or build/amd64, etc, with
one log in each branch, so that ‘git diff’ can do the right thing.

Lastly, perhaps off-topic, would it make sense to give a recommendation on how
to manage upstream sources that use Git and ‘gnulib’ ?  I have met such a
situation, where the version number of the program was not availalbe in any
other way than through a Git tag, and could not find better than importing the
release tarball with ‘git-import-orig’ instead of following Upstream's master
branch.

Have a nice week-end,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816045106.ga5...@falafel.plessy.net



Accepted wfmath 1.0.2+dfsg1-0.2 (source amd64 all) into unstable

2014-08-15 Thread Tobias Frost
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 13 Aug 2014 09:21:29 +0200
Source: wfmath
Binary: libwfmath-1.0-1 libwfmath-1.0-dev libwfmath-doc libwfmath-1.0-1-dbg
Architecture: source amd64 all
Version: 1.0.2+dfsg1-0.2
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
Changed-By: Tobias Frost t...@debian.org
Description:
 libwfmath-1.0-1 - WorldForge math library
 libwfmath-1.0-1-dbg - WorldForge math library - debugging library
 libwfmath-1.0-dev - WorldForge math library - development files
 libwfmath-doc - WorldForge math library - API documentation
Changes:
 wfmath (1.0.2+dfsg1-0.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Upload to unstable.
Checksums-Sha1:
 e9a2be2f114165886cef719dbcedb1f1200ef23f 2164 wfmath_1.0.2+dfsg1-0.2.dsc
 76399485c0c7f2ea7578eeab257c5b33070ef806 9312 
wfmath_1.0.2+dfsg1-0.2.debian.tar.xz
 c7f4d63f1c68b4262fcea1912792b8c3f7cf544c 116588 
libwfmath-1.0-1_1.0.2+dfsg1-0.2_amd64.deb
 8e48290e933998f80e7b2f420488bfd8ec4b25f9 66254 
libwfmath-1.0-dev_1.0.2+dfsg1-0.2_amd64.deb
 2f22803cc1f80ad63221a5c6f1a8e3a72ced503b 158078 
libwfmath-doc_1.0.2+dfsg1-0.2_all.deb
 f38aa744bfcf06c9237973f59f992e1554dcbb4e 706336 
libwfmath-1.0-1-dbg_1.0.2+dfsg1-0.2_amd64.deb
Checksums-Sha256:
 d0b1a57ed4b9f7c6e662fb6e087e7ca36c364e19811e7c652e353265a19dea92 2164 
wfmath_1.0.2+dfsg1-0.2.dsc
 04560e73b48da04f4a5d8db2e5d8209cc14f5881aee6d0369f7234b947ad9b13 9312 
wfmath_1.0.2+dfsg1-0.2.debian.tar.xz
 6b28cbd5feaf2a6dd5e902f472301d7363f49a1b5880d89be92371177b8ceeb9 116588 
libwfmath-1.0-1_1.0.2+dfsg1-0.2_amd64.deb
 95ac22671975b1071cb7964621da01d98a97fa1dcdfb30a8b04573801a82c90c 66254 
libwfmath-1.0-dev_1.0.2+dfsg1-0.2_amd64.deb
 c3bd55751d5ba20b868a95deed9c04e565163b0acd22f776218c65620fed3ff7 158078 
libwfmath-doc_1.0.2+dfsg1-0.2_all.deb
 78ee91d583df5bdf6cf65823583389e9a27fb6c0de760b4360479682d6fecb68 706336 
libwfmath-1.0-1-dbg_1.0.2+dfsg1-0.2_amd64.deb
Files:
 65298511304358db007ac0abeb7196a2 116588 libs optional 
libwfmath-1.0-1_1.0.2+dfsg1-0.2_amd64.deb
 e7dbb0ce5cf795a2071ea41a01d11373 66254 libdevel optional 
libwfmath-1.0-dev_1.0.2+dfsg1-0.2_amd64.deb
 8dec2708169012f59ed05afb51ac2914 158078 doc optional 
libwfmath-doc_1.0.2+dfsg1-0.2_all.deb
 0a5f2d6db45dddb4392467b4bc5a12d4 706336 debug extra 
libwfmath-1.0-1-dbg_1.0.2+dfsg1-0.2_amd64.deb
 78cb186a096ca0ca871c2ed7b2a74b35 2164 libs optional wfmath_1.0.2+dfsg1-0.2.dsc
 ceb8b7524f692171b6bfb72611d1653f 9312 libs optional 
wfmath_1.0.2+dfsg1-0.2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT6xMpAAoJEJFk+h0XvV029qgQANs6sK5KJ8Tdv0fg/27EIdHm
iQidWKPE5k9hGokunaBw91YmRrmbpsL5JNVkFz9GJ/A5WdBJ5SPPbDqigajSbunv
a15dRp3dgaCWO3CajvCQXAGfG3RZKt3rpAq1bQ8j/S15FegpRNQEyxP3ao7bdZGp
5RYbNagA2uUiIwR0JTMHqBmw1jCUAD8E52aDItY3e4G9qlTt8idQ56ddAa9vvaaB
iKOzgejxDEjkaMfpcgx8IGCutIyHNChBUCGoCmOgzZbBBx4BEHtsZ9ztjjDJaDBS
n4rpv09aN2/9jKuAK7X/9lhLMZutdFfgz0X0QNvZulDJ8nuqUrc5/ZOG4jyHpoVe
7p7JcM/yVXLdMG4dvi67RbJp777jTVVBH8sRHxy5lFBHrZS3Bq1eC9SmC2ofTHc/
NTIxZEhCQSeuuR1C2iSuC1xcszSgCJZ4wNhB3oqUgv1s0dG3Th6et6CsvPiTC4db
C2dXb7OSTp7U6zO/gayAqxPMpwySuSJqTLzQIWzm0ZIvLE/JVQfJw6WDam+ajFX8
GolG+D1h8cmhaPrIK7BfhfbDh3V5W7/1Ecbs3N+D9GKACXOX985torPfs7Qxoid5
iW5bR8IpSYsdVYx/3/CLxHevimigN368/DwEVz8lsuV5OFKdCa5JARLBRIr12/Da
BoIQXTZdKSVgQF1OskEk
=dlsJ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xicfr-0001pf...@franck.debian.org



Accepted cpuid 20140123-2 (source) into unstable

2014-08-15 Thread Andrey Rahmatullin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 14 Aug 2014 02:04:26 +0600
Source: cpuid
Binary: cpuid
Architecture: source
Version: 20140123-2
Distribution: unstable
Urgency: medium
Maintainer: Andrey Rahmatullin w...@debian.org
Changed-By: Andrey Rahmatullin w...@debian.org
Description:
 cpuid  - tool to dump x86 CPUID information about the CPU(s)
Closes: 745515
Changes:
 cpuid (20140123-2) unstable; urgency=medium
 .
   * Add hurd-i386 to the Architecture field (Closes: #745515)
   * Set --one-cpu as default on Hurd (patch by Svante Signell)
Checksums-Sha1:
 35188d75329a8f531e003631de7abc7d98bb2e80 1941 cpuid_20140123-2.dsc
 6de78563d8347921b408e36cca7b2a540a4dbc0e 4896 cpuid_20140123-2.debian.tar.xz
Checksums-Sha256:
 dd69ea7e8481d748745db42b307607b397436b39ca430f560507fe83c8177889 1941 
cpuid_20140123-2.dsc
 1a541ca9e3be8c41fac31cd63017f0a162d7f437952f89dd15ab951acd145a7c 4896 
cpuid_20140123-2.debian.tar.xz
Files:
 bec2dba038855e038f3983f98bd9bb2e 1941 admin optional cpuid_20140123-2.dsc
 8036b343652bc50a2b7ca5233b879d89 4896 admin optional 
cpuid_20140123-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT68VLAAoJEDNi9wMaSZLhllcP/jIruaOKnzeBPdG0HTMFFpNl
8tlZwOexR0Rl7EjNZoE9nM2ecMTmThx5WZD8ChprTAcaLZisFJn1HXyO+U33chqI
6APjxMF7/BbekODZY1N/II8G2tLp4km2VdVQw3e3eqqEqwgOqVZ1wOMdPk0vc7dJ
E49yL0vv2fajUMdPiQ2bjzPO6jr9Vejn5BDhU60O7juEP0fr4JXdVy7oWlIvp2ZS
ueMEVeB9WzxAX6LFGH38/HI3qPOnNfytfjGF8eKqgWfdpn/SYe8Gy0J62ajliDrA
BjpFF2RDJwZaiPDfzR+vCAZfu4n7x5w0nXNPOa3Mdz/tOJduQVOb9eH29di32n+0
NmjYHeMLrJkJ25vI4xXkTgdVadhmKNzfuN7R2KMkkD5Xj0Xa/B7PRAMqwiJBm62J
EoHJmY+KQDxOTOFzmuXh4tLn5eO6W9xYoBHviw/4dQ/GNbieCANZ40h9UZPTaqAi
OFb+BCrr2PuxAtIi5H0hPWYPOEITdEwYS54oL1iH3BsLio2nRijbO2XeCccQ3UvH
l4y3GXhIIhY2/XuHd8zfn/PSWUvOyS37dpkTTZCIVNnk4JDzxiRzeivFSMfKqNgb
psTDbZ5Sb4jIeRa8NtTTSy1s058okpw7ip/jykSpHiewiBSbT1bdJE0+MdrNovax
Umbdm5fx5DTRa54qQ7TN
=4WQE
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xidtv-0007va...@franck.debian.org



Accepted python-xstatic 1.0.0-3 (source all) into unstable

2014-08-15 Thread Thomas Goirand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 16:27:01 +0800
Source: python-xstatic
Binary: python-xstatic python3-xstatic python-xstatic-doc
Architecture: source all
Version: 1.0.0-3
Distribution: unstable
Urgency: medium
Maintainer: PKG OpenStack openstack-de...@lists.alioth.debian.org
Changed-By: Thomas Goirand z...@debian.org
Description:
 python-xstatic - XStatic base package with minimal support code - Python 2.x
 python-xstatic-doc - XStatic base package with minimal support code - doc
 python3-xstatic - XStatic base package with minimal support code - Python 3.x
Changes:
 python-xstatic (1.0.0-3) unstable; urgency=medium
 .
   * Update VCS URLs, as well as the upstream ones.
Checksums-Sha1:
 08e8ead57580d5e88c4890c1654f226fb0c8b537 2285 python-xstatic_1.0.0-3.dsc
 d345206c0ae7a557f826bc485a6b502b4826e92c 3240 
python-xstatic_1.0.0-3.debian.tar.xz
 9e4b8308f95591225f961a2df16d3f4dbbe83432 4992 python-xstatic_1.0.0-3_all.deb
 1ce69e0790550727c0920676fac185e9afe9a698 4884 python3-xstatic_1.0.0-3_all.deb
 304ea1805813f1a57772b9c1c1e0975610468bfa 24630 
python-xstatic-doc_1.0.0-3_all.deb
Checksums-Sha256:
 5904da0a305b16cbbb9647554341a7a9dd7d75ebde2b299ad95ad7a58d9d0178 2285 
python-xstatic_1.0.0-3.dsc
 6d57bfc17b5bde2f7518e44048dddf06d863088a7eb641e97951775a5e2196e5 3240 
python-xstatic_1.0.0-3.debian.tar.xz
 f05aa81641df116f79321ee384cdad120edfda6fd3aa747c0c409d109356ad95 4992 
python-xstatic_1.0.0-3_all.deb
 2414615a3de9ba59eae5ae24b3c21dfc6944658131793ec03b493059d8f82943 4884 
python3-xstatic_1.0.0-3_all.deb
 61f4ffe6adaf04b4fad5328580454c6ff7c8a0ab92b1ab98415261ff3616 24630 
python-xstatic-doc_1.0.0-3_all.deb
Files:
 07f6de91254af11b631f1ce69a3e2a76 4992 python optional 
python-xstatic_1.0.0-3_all.deb
 ea25d0a9458b4e283887f1e7dc3681c3 4884 python optional 
python3-xstatic_1.0.0-3_all.deb
 4ddd92e3aa23795ced58fcd1b2e423ad 24630 doc optional 
python-xstatic-doc_1.0.0-3_all.deb
 355890e29ecd46eb77e7cc572bd314f2 2285 python optional 
python-xstatic_1.0.0-3.dsc
 739af41a56f73066db3af5df08cbb83a 3240 python optional 
python-xstatic_1.0.0-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7clpAAoJENQWrRWsa0P++OQP/1ai4lOm3r9uSED3hOBP2v5T
xABWRt/A/KjZfrF03ulAwDlP+JPf8su0DliGERFnGkt70ejpSwwW+Paq/VEG6Xum
S0hVyz/ScOfEdK81P92E6emb6A/cqK71/SYJGMdXIdGguoSt+uMJhrGbYZvKfQU0
yBrVOjtzXqlqcc3JdikYeCUqPl0lSwqjbmNGLaQF6L2dW9KodwDpafm/uCIo3Jc1
N8YeARyTMSQZhsUYC8gXPlvYEhsIt8eOKyWTVrKSPjO9L9JLfVHcs0r7szfHwbwi
gnJB+XV3sg+ID8o/DedBSri3f8gPcnjvlJxhNmt/qgfr0RSBQf7nNCjZtvSM9lCO
sk1Tu0L/0635UWVQ7wGgE3lOml+Filev62NwPmNiiFt9JBD9xUS5NpGmqHdbgDDg
/0zEPoeJ02ODOs+tfTi7lytU48bMZlHzWceczpndeb3Wn49k6THg/1alaIJwxFsW
yhy6jyW4MoCIhA/2pj4FJtePZhO3USJAu4hSDTCmzS171CJb9s7tOCrex7xi0+zI
qefhlUbDnECdsWPY1FdXpsf6Q4Lm7qnm3Ygkskt1J4V3bezeRk+8xer3b5DGncS/
JZnWBECvjXhU8Yz+RIZRiL5h6GBbnkm2CL8+eKrsYdghXc7xVllC9PMHZTVQ/VTn
YYPgH/jUAEiEjYtn/+zo
=/1hJ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xiduy-0008ga...@franck.debian.org



Accepted ffindex 0.9.9.3-2 (source amd64) into unstable

2014-08-15 Thread Andreas Tille
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 09:25:28 +0200
Source: ffindex
Binary: ffindex libffindex0 libffindex0-dev ffindex-dbg
Architecture: source amd64
Version: 0.9.9.3-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Andreas Tille ti...@debian.org
Description:
 ffindex- simple index/database for huge amounts of small files
 ffindex-dbg - simple index/database for huge amounts of small files (debug)
 libffindex0 - library for simple index/database for huge amounts of small files
 libffindex0-dev - library for simple index/database for huge amounts of small 
files
Closes: 758149
Changes:
 ffindex (0.9.9.3-2) unstable; urgency=medium
 .
   * Build with clang (thanks for the patch to Alexander sanek23...@gmail.com)
 Closes: #758149
   * debian/control:
  - add myself to Uploaders
  - Priotity: optional
  - debhelper 9
  - cme fix dpkg-control
Checksums-Sha1:
 cbb19e7dd5d52e440f0a7b51ed8e9f17a538a363 2174 ffindex_0.9.9.3-2.dsc
 aa056988a54acd47a76a03d3e73b8901dd644b9e 13300 ffindex_0.9.9.3-2.debian.tar.xz
 4f81564b837d43d9c1e694750439d44131ceecc8 23330 ffindex_0.9.9.3-2_amd64.deb
 949c61df067bfcd996f70ffafdd060e9120cf133 15818 libffindex0_0.9.9.3-2_amd64.deb
 0d249d4d8189455733ea1f325b66c3f785f26e88 15686 
libffindex0-dev_0.9.9.3-2_amd64.deb
 33460e8ce827eb33fcd932e75b9fc545972505be 50760 ffindex-dbg_0.9.9.3-2_amd64.deb
Checksums-Sha256:
 524ccb043fb5913fd7427d2917bbd7cb1c42975d18c026f237e204d5d2e37918 2174 
ffindex_0.9.9.3-2.dsc
 2d5a41d14db7fbdea2cf8f71633a4f53e9602612567c53a17cddd8d29860fbf9 13300 
ffindex_0.9.9.3-2.debian.tar.xz
 0c12abbaa758a9eef9f781c69209ce316615607840e30425696ec3292bb7372a 23330 
ffindex_0.9.9.3-2_amd64.deb
 5cbcc82f8eb39094da5c71f9af195cad5d9a044339c8024d46bd203c44bb0c13 15818 
libffindex0_0.9.9.3-2_amd64.deb
 cee108ead44a5e35fdbc7807aa214be97db9e5a65f0368a0b8d688df4c90b25e 15686 
libffindex0-dev_0.9.9.3-2_amd64.deb
 dcf86c1dac074dd17df83764ecd23bbc791075d70bda445c3687dcde5fca286c 50760 
ffindex-dbg_0.9.9.3-2_amd64.deb
Files:
 f7c1a3912b8a5b6d7661168a2d232ecd 23330 science optional 
ffindex_0.9.9.3-2_amd64.deb
 66c20854811870bc0a591f2c1173d44d 15818 libs optional 
libffindex0_0.9.9.3-2_amd64.deb
 576ec7be2b0a55331b7b2e9bbfd84c61 15686 libdevel optional 
libffindex0-dev_0.9.9.3-2_amd64.deb
 ce8b9f5aed41860c292595a6aa620bdd 50760 debug extra 
ffindex-dbg_0.9.9.3-2_amd64.deb
 9559c4e6ae2840640a4c442a83fbbd0a 2174 science optional ffindex_0.9.9.3-2.dsc
 402f8270b5024f78db5d337fbb8ec5f3 13300 science optional 
ffindex_0.9.9.3-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7cADAAoJEFeKBJTRxkbRaekP/RUxMQUwJYC+Madca7JKioT1
UinnBQPNi4P8Z87sz9+HQlfI8ChYFh+Mxan8VAokt/pNoMQueRMf01BeaRe3
W7cH4SLZ+ISIsSapZeFXUIA+mpJP5kbBf0uKqGn2xATCJD8E2FitufPy3wmZ3WA8
bm48Fz3n8GRvHvlCNCLfimbPOG7WggMRvnWPcAdBb+JsTgpCENQN5gwTIFjfxyO8
epW6g+yTjSlIGLMgzU+bfbkEn7gyBJixxIiqiOmkGsHXHJOHanKeCehcLy/6j24m
7z/P+1iBqgPK0dI9X4MwbYC4OrjtM+4SJLrSlAf85k1EggYU0IcSj32AEmhM2/HN
QYlu5uAKg4Rdh+5Kpj7Pk74WW+yHBdXH1Opv9pnRHfOrZGhC7CprXoeGPkboMl6z
xw1KUEANvey752CgUvvUBOeBiacYcd16E5cZmrdbwWNNdAIXRPzs9rUyvyG+lc3l
+qXmeX0SnXVzy5e46hAVYOkgmsUjXDKsJ2GdJYRanq80clbY5nC4bkxQxKwcK+z/
c7tFwbWNOASGv4GDTC5DBALoGXbP8+/PEKRZ5F/xU+VmWSfhvf7BbQNCjkBCYJDj
KrXkAA0gNYsl3fw9cg03e7QY8YwEBINbLb1Nuh0MdBSonUgfBiUhpN/mxWM47rJY
aI50RRq3TKBcHHGHJC5W
=zqxb
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xiduq-0008ae...@franck.debian.org



Accepted cwdaemon 0.10.1-1 (source amd64) into unstable

2014-08-15 Thread Colin Tuckley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 25 Jun 2014 11:07:45 +0100
Source: cwdaemon
Binary: cwdaemon
Architecture: source amd64
Version: 0.10.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Hamradio Maintainers debian-h...@lists.debian.org
Changed-By: Colin Tuckley col...@debian.org
Description:
 cwdaemon   - morse daemon for the parallel or serial port
Changes:
 cwdaemon (0.10.1-1) unstable; urgency=medium
 .
   [ Kamil Ignacak ]
   * New version of upstream package that fixes two major errors and
 two minor errors. It is recommended to use libcw 6.1.1 from
 unixcw 3.3.1 with this version of cwdaemon
   * Bump Standards-Version to 3.9.5
 .
   [ Colin Tuckley ]
   * Remove the NMU (not needed with new upstream).
   * Fix unescaped hyphens in man page.
Checksums-Sha1:
 27f27dbbfaaf352747a84c0e4498c59a8b55f567 1898 cwdaemon_0.10.1-1.dsc
 fb295ac6d6ef491826216495b9c72b1f67cb1557 314733 cwdaemon_0.10.1.orig.tar.gz
 afd9a09ae2d55b8b1cb1aa04a7ddbb8e62969734 8384 cwdaemon_0.10.1-1.debian.tar.xz
 fd092bcd8ce58675252d36810a662a67d183b55f 133120 cwdaemon_0.10.1-1_amd64.deb
Checksums-Sha256:
 91fafefab3c4820df41d626c6f80bfbff04e201a63f8eb95a77fe67c89672ea4 1898 
cwdaemon_0.10.1-1.dsc
 5c914140aba395b5d52ba5d822bec9c22e05e93e38af9cfd212242adcaf6abcc 314733 
cwdaemon_0.10.1.orig.tar.gz
 d4841bfe8a7c8eaea024a556beb3b892b98f7825c76f1c6bd79a0ec3e5d9ead9 8384 
cwdaemon_0.10.1-1.debian.tar.xz
 47a2580a1cf7381ce3401dfc903a1695af5f68b2783a74cf955015185c12b7b3 133120 
cwdaemon_0.10.1-1_amd64.deb
Files:
 33c3f3ac8a72620156fcbca150d5731c 133120 hamradio optional 
cwdaemon_0.10.1-1_amd64.deb
 9648d07d848f06c9fb2cbee05384109c 1898 hamradio optional cwdaemon_0.10.1-1.dsc
 681e02e48fb5a05c2e7bea0e63f5d94d 314733 hamradio optional 
cwdaemon_0.10.1.orig.tar.gz
 4499536f4cc64719dba6fe46aeda86cc 8384 hamradio optional 
cwdaemon_0.10.1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7cDaAAoJEPoMQQc4ydkDQZcQAOLvRpuutiR70hSXuLMyeYtI
Yu1qylHaOQVvT3X4bonWIM4L+dcezbx6X6QNCSk+r+q3/fZBWBr1KSo1cOBBm9+Y
G8tYAjLUroS2Fo63MyZp5EQZLBx55ygqEVkT8KCV/SKKEiG7iYbFqKWBz7AqBho0
/cc6cQhTMs+VcF2xmzywiw2557ABkOxE2nVbWzkmQsnusSk63Dy5YHdtb1M7She2
X3pUQzYg6JuSAgKMxrU+zTCwXVp5Z/RWbnaM7CC5xCGH7aX0HT+zbvKdsfNTqZJy
c6BCLme3K92qBUWFdzZZr+vsDxIuhQ8nIFzaeMx2xMqp5X5LsC8dr4cBKv4WcsqC
C7ImMVX9r0ASNQbpKYCtby4B4tRcyLwsJ9x5jORBm0eS+1XH1IfiMBgX0yXzgXUo
ihLojBYC5Tml9DSzokrW4KWNhQJerOI2lunWsViWsbzANyd91MTDYRddhRWT4+qS
cCECc2+czRlnKU+D4aQENQfdwCLdMu1kmMNtvooamjS6//D3ksKe3zi+4U7sqc35
uQMd99+Jn057LHMEwYZbRXWOAIbThUVaAaMpLC1xiPSTy1AiGimf95jXS6AiOtjr
INicicptpTZmuqBaqOcCbHZ2jLsCTSXpTZ64Nnv5a9rd767FPOQg/Fh+c91ukI5s
fZWno+RCIzMe8o14alZT
=fDMe
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xidug-00083v...@franck.debian.org



Accepted python-biopython 1.64+dfsg-3 (source amd64 all) into unstable

2014-08-15 Thread Andreas Tille
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 11:41:23 +0200
Source: python-biopython
Binary: python-biopython python3-biopython python-biopython-doc 
python-biopython-sql python3-biopython-sql
Architecture: source amd64 all
Version: 1.64+dfsg-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Andreas Tille ti...@debian.org
Description:
 python-biopython - Python library for bioinformatics (implemented in Python 2)
 python-biopython-doc - Documentation for the Biopython library
 python-biopython-sql - Biopython support for the BioSQL database schema 
(Python 2)
 python3-biopython - Python library for bioinformatics (implemented in Python 3)
 python3-biopython-sql - Biopython support for the BioSQL database schema 
(Python 3)
Changes:
 python-biopython (1.64+dfsg-3) unstable; urgency=medium
 .
   * Skip test on mips architecture which is known to fail
   * Versioned (Build-)Depends wise (= 2.4.1-16) to make sure tests
 will pass on each architecture (problems with previous wise on
 powerpc, s390x)
Checksums-Sha1:
 c1af1f9c7c54994ac7ed176e9dbbef860f9623e2 2898 python-biopython_1.64+dfsg-3.dsc
 71a937d9fc82cdfee34c3af08135cd7a8481ee2f 11168 
python-biopython_1.64+dfsg-3.debian.tar.xz
 9f4ecffb49c968b319183ec68c9a164b62c96479 1164128 
python-biopython_1.64+dfsg-3_amd64.deb
 209fbbcdf5447cd7b518f0614ddf5570ce1bfb5a 1132468 
python3-biopython_1.64+dfsg-3_amd64.deb
 e418176e8481a83758fea833af458a61223b9b62 9758924 
python-biopython-doc_1.64+dfsg-3_all.deb
 ced371079ee7f4316fe31cb65f2e4db2b3627178 27414 
python-biopython-sql_1.64+dfsg-3_all.deb
 811560f73aeef76c8d919ac885a9cb6a6c355d1d 27486 
python3-biopython-sql_1.64+dfsg-3_all.deb
Checksums-Sha256:
 54cdddbdb3ad12794b22b369e6bd9ff4e07525b0427434633042dcdc4010e3af 2898 
python-biopython_1.64+dfsg-3.dsc
 46565786f2d0d1d90cf0cde83b56c285f46f90a481a5033e940b6cb2b01d07c1 11168 
python-biopython_1.64+dfsg-3.debian.tar.xz
 6e47df0b69f5ade0e0b368a6c9cf6cabb6ed81c7693b9a4277bd51b6a1e75fa3 1164128 
python-biopython_1.64+dfsg-3_amd64.deb
 bc99c6fa3b6486f5752aef973cdf3e5a4f4ecc63452f3c7a084502a076388500 1132468 
python3-biopython_1.64+dfsg-3_amd64.deb
 2693aa9488e8a40609e7de94dfb40ae7458a117fa8728f14364f40af6f163749 9758924 
python-biopython-doc_1.64+dfsg-3_all.deb
 99ea7109cfe0949d6de766457008d991bd4273f7a35066c7ee29a599287e7673 27414 
python-biopython-sql_1.64+dfsg-3_all.deb
 604918ac996769f41f748d76e4bee59b6c1fd6e6094653d584fd9abd8d76 27486 
python3-biopython-sql_1.64+dfsg-3_all.deb
Files:
 4cd391b31228bcc44d0726cd687defe0 1164128 python optional 
python-biopython_1.64+dfsg-3_amd64.deb
 1f4186f6d991444a7487bf3ed8f9d03b 1132468 python optional 
python3-biopython_1.64+dfsg-3_amd64.deb
 c5327e959b560be80f37f83d572f60c7 9758924 doc optional 
python-biopython-doc_1.64+dfsg-3_all.deb
 9462e1138ccdbbef8c21046f6c19967b 27414 python optional 
python-biopython-sql_1.64+dfsg-3_all.deb
 f28657ee512a65e4799353a824a33f49 27486 python optional 
python3-biopython-sql_1.64+dfsg-3_all.deb
 0f3a372ea4c7d5ddb26c8643fc1310aa 2898 python optional 
python-biopython_1.64+dfsg-3.dsc
 8d00461b0c1525d6f161b51309cfa89c 11168 python optional 
python-biopython_1.64+dfsg-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7d1lAAoJEFeKBJTRxkbRRRsP/2tQ9q+XQkUl8kkPPgIcZCE+
Ilj9MHELSvYU4vuGN3j3BfSjBEmFk2Rx1OzqR6EbhnNpPjOZAZj75YCRqithjcpx
ipHrSlYhgow3vzoTG6MvJ3VS+q3WMeUKppVFScXXPwmBSnUzqSfu7ueDMI4OegU0
rXLCS2FhhCUncDf2zvGI33ltLpn45FfvJvyOrKAqNM8jU/xJ5H3k7TkOf5Tlit71
Z910UpZ8fgLc7+p4EAawhoSLMCHduUOAndf1E7ONmjczD6lMOCX01yQIosZEBVd9
r3umKyftjbcC76nZWBrZT1iuVl0Dy5R7VugqEfhCb7eZxgbiM5TM0QqT5kzTbjAR
P9jOxcgRAOoM780uOqcy8ckHol6Eapd6AOvBZiA3mpGDagSFe5t7fAKz2MMgTVg5
cvYr3fpQj1wF2XukoJ6WvzOxPcUMjEP7X5rgxJJ90ZXA7nnO1UyzVDSlgY0OWH6a
qIDDm/jI5gdWtfS5bj7hgeCO3qGOtdRqXROird+VRPCLX5xsBEbv6YkpTtaYCqVe
7Uhdv+nqGHVVsIWmmjtblCmxSpKUorJ4wd/78dGq/PgVXSazMQ4l7D2VKBjgUB84
RfIBIqwmpdpUabj/gyh5WAE6iCN9POADdQUwMVuCRfDQN1xAHI76wrmF9MiH+9OT
5Ik/boJHDNWMNC4eEiCq
=dJvu
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xies1-0003pq...@franck.debian.org



Accepted eximdoc4 4.84-1 (source all) into unstable

2014-08-15 Thread Andreas Metzler
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Aug 2014 13:23:28 +0200
Source: eximdoc4
Binary: exim4-doc-info exim4-doc-html
Architecture: source all
Version: 4.84-1
Distribution: unstable
Urgency: medium
Maintainer: Exim4 Maintainers pkg-exim4-maintain...@lists.alioth.debian.org
Changed-By: Andreas Metzler ametz...@debian.org
Description:
 exim4-doc-html - documentation for the Exim MTA (v4) in html format
 exim4-doc-info - documentation for the Exim MTA (v4) in info format
Changes:
 eximdoc4 (4.84-1) unstable; urgency=medium
 .
   * New upstream version.
   * Refresh patches.
Checksums-Sha1:
 1d042831b810b013e6b30d8961421a0f0cfafc89 2171 eximdoc4_4.84-1.dsc
 cf86edb795c6a6b656448853ea775531f1eb4453 537288 eximdoc4_4.84.orig.tar.xz
 ccf30212b9330cd65719f328cdbc688802caa1cf 8508 eximdoc4_4.84-1.debian.tar.xz
 c0a3c40750718f3a27db75788e068c47f98fdcd7 566962 exim4-doc-info_4.84-1_all.deb
 a84dca0fe09aeda1375e021d8973afe92a8a8784 464308 exim4-doc-html_4.84-1_all.deb
Checksums-Sha256:
 842a7a8ee992b7c2907e7610b354866fc6e6adafa10f3cf5b028bff95f5f3ff7 2171 
eximdoc4_4.84-1.dsc
 c36e462b47af4f6903b1faff91cf9f0a9aed338a047255d198fd3d41ea83398b 537288 
eximdoc4_4.84.orig.tar.xz
 184f509a8e8386b396bcb693618824cea1d708c2967c87e8dfb3ecf2094f96c8 8508 
eximdoc4_4.84-1.debian.tar.xz
 f253a5e1b07e805cd9c2d2dc6013d88d49387bc5e9fcefabb5f19db76ec6ba67 566962 
exim4-doc-info_4.84-1_all.deb
 9002d200fd8f31b5c7b6b2bd01d971484747c9633a49295ce4509e8426e36ccf 464308 
exim4-doc-html_4.84-1_all.deb
Files:
 9b079718253e0d440819a117b3cc0d1a 566962 doc optional 
exim4-doc-info_4.84-1_all.deb
 e1d8e16cb06786659673b8d974207a5a 464308 doc optional 
exim4-doc-html_4.84-1_all.deb
 9ffde99929e8dab26160db6bef00db95 2171 doc optional eximdoc4_4.84-1.dsc
 984e3e5b09103fa78b71cb5082f7c77f 537288 doc optional eximdoc4_4.84.orig.tar.xz
 2cf54952d7e70d1998f2278b48507150 8508 doc optional 
eximdoc4_4.84-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJT7e6IAAoJEKVPAYVDghSE+WYP/1RpdXpmCg3aVXrabsxabIFY
ltZQpNP2NfpzVkfqJvzOivW/VYNV8SabtBe08B5yi7V+T8sBYCsCRo3tkdJVsYjm
O4EYLjMGP5bX/QqbM70PkTfjn7Quzb2HIcT5kIZ8LH5C7nUwfnYy2cRm9LBnT6HO
4wXTFFqHryRTKkUYygrQ5QtR/GkWzBstmqGzsRr9uq5o1J3inraiyfksj2wD6IgU
TkZdkkEQFgxHDsNbQGein1oaNgIxRsA2BbkOgJe6vNecPqWPViZePm2HDQCGUgfJ
ojGNvHdnz/Shtu2BI/ezuPMBZlJJ/NxNblLYC8UI+S7WhEQiDqfEc8/1PGmjX5kT
wXJEW9ofLJPowXmjkSRTbQXfhAUXaRkQXmTqYbWUTm5g/qmT600l+6WnM6hz351x
h5sPYu8wKkPnHKhMrt9q/UwfVI1ubZje15OcK0T56sZI00gnjCeTDmfxBPXouWkn
dXCur3QuVKBEGQLw0tCeCITTf40xT923aMFpMpimSgas3tL7BX1bPDtc3KJfrPzM
J2xMMB8UNoCbxR6vKzzmB1mYK2mqlPHPuXzLxe8XOoxINwXfwLr9kCn4pI2FAWJP
c7L7UHSJZ5Qr/r6Qc2sjEA1ZrIzcCkes1NqD6W/7Iquth7pDkA5DMFZ2cGpH9k1F
g33jAQoyV51rvn+6rB8u
=k5aT
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xiflj-0007rd...@franck.debian.org



Accepted yample 0.30-3 (source all) into unstable

2014-08-15 Thread Morten Werner Forsbring
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 13:19:03 +0200
Source: yample
Binary: yample
Architecture: source all
Version: 0.30-3
Distribution: unstable
Urgency: low
Maintainer: Morten Werner Forsbring wer...@debian.org
Changed-By: Morten Werner Forsbring wer...@debian.org
Description:
 yample - Yet Another Mail Processing Language
Closes: 614918
Changes:
 yample (0.30-3) unstable; urgency=low
 .
   * Added recommended targets to debian/rules.
   * Added misc:Depends to the binary package in debian/control.
   * Changed dependency from libmime-perl to libmime-tools-perl.
 (Closes: #614918)
   * Bumped standards version from 3.6.2 to 3.9.5.
  - added the homepage-filed in debian/control
   * Update my lastname in debian/control and debian/copyright.
Checksums-Sha1:
 6450cd658f5c67f2b0a95efb63e7ad9e7ebce0e0 1021 yample_0.30-3.dsc
 7576a54dc1cb6fb207396e66ad22cc5ab78a9c52 2933 yample_0.30-3.diff.gz
 b0c5a03e39e5321692ca0e9d90b4be437883408c 16098 yample_0.30-3_all.deb
Checksums-Sha256:
 556121f6f88be9ffbdcb0f7843a0cd6a1567270278bf036b97af0192779165f9 1021 
yample_0.30-3.dsc
 517bb2114042b1ab9e5f00274ca647ea6251a22ca659101721fdd139497b7835 2933 
yample_0.30-3.diff.gz
 cebd8cf6fa08e7eec493c96c3509158080646fd141b7c6deead9398bcea09827 16098 
yample_0.30-3_all.deb
Files:
 c0fe356a846f5ba6d4109267d64cdec7 16098 mail optional yample_0.30-3_all.deb
 490376d2ce7e93e5f7c7e0e8063e8d45 1021 mail optional yample_0.30-3.dsc
 96eab130388288fc7ee6455c44c8e413 2933 mail optional yample_0.30-3.diff.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlPt8loACgkQw951rgNrq41DMgCfVh2V6VNgixgPDN9Y+O1sBtQO
KAwAnRF48gUsLdnzH/PGXLx6GlFXYZBA
=jAvJ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xig2k-0005yp...@franck.debian.org



Accepted igraph 0.7.1-1 (source amd64) into unstable

2014-08-15 Thread Andreas Tille
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 08 Aug 2014 16:12:35 +0200
Source: igraph
Binary: libigraph0 libigraph0-dev
Architecture: source amd64
Version: 0.7.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Andreas Tille ti...@debian.org
Description:
 libigraph0 - library for creating and manipulating graphs
 libigraph0-dev - library for creating and manipulating graphs - development 
files
Changes:
 igraph (0.7.1-1) unstable; urgency=medium
 .
   * New upstream version
Checksums-Sha1:
 6e6ead01a80cb83d2c0e33ea6ecf25482105292d 2144 igraph_0.7.1-1.dsc
 2cf3528a60c52810a3d5ed9f117692f8f639aac1 2967134 igraph_0.7.1.orig.tar.gz
 a07672c9558197b92889f9bacf2980ada7e39e58 2720 igraph_0.7.1-1.debian.tar.xz
 ff4877d2483b3fe84f6e0337cd6dd0ab6c6b76e1 819936 libigraph0_0.7.1-1_amd64.deb
 c545ee8479b4e5369f295c1dd27d783f614f0098 55926 libigraph0-dev_0.7.1-1_amd64.deb
Checksums-Sha256:
 8d4abf58b8d78a91955ba7ef2b04cc3e667a6e3feeadaf70e6c897fb6f62e167 2144 
igraph_0.7.1-1.dsc
 d978030e27369bf698f3816ab70aa9141e9baf81c56cc4f55efbe5489b46b0df 2967134 
igraph_0.7.1.orig.tar.gz
 18d43146cf5e1212eddc086d5a7377655cc1a6c7ceec0ebdb9412c1b9a483fbf 2720 
igraph_0.7.1-1.debian.tar.xz
 6fe20261c0e7375ed40f36a6d3ddc907c48a88071491e386dde16401b8cb3415 819936 
libigraph0_0.7.1-1_amd64.deb
 00be93df0d15783b8720b9aa944281a25d958ffdc4bca501fdc4a1e77aa707b7 55926 
libigraph0-dev_0.7.1-1_amd64.deb
Files:
 3f51a176929a344a4335c40a80fbaf2d 819936 libs optional 
libigraph0_0.7.1-1_amd64.deb
 e26c8c295c638bf035a4c46bf723c2ae 55926 libdevel optional 
libigraph0-dev_0.7.1-1_amd64.deb
 6de18db1e6a3b5ab2066bf46f70ceaac 2144 libs optional igraph_0.7.1-1.dsc
 4f6e7c16b45fce8ed423516a9786e4e8 2967134 libs optional igraph_0.7.1.orig.tar.gz
 cdcffc6864c3667fd8f3dfc0ab071b57 2720 libs optional 
igraph_0.7.1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7fbYAAoJEFeKBJTRxkbR6GQP/1SEUTbRlH4/VG7UjOIiYUGF
B6xb8zSKe3Tmb40KSwdA1F4ZvERcnodnBSVF82TG5i1An0MSMUaNiZAI4x9+gBLW
Pc5sbbqaJg3iWBpO55vLA9XaAPBwe0E9fjtA70BmAwQKqO0jWzQS9OTQqRRmvIyy
iuRDCL+wLKkyOZ12c5EuMC6awZq3jZWl6xxXu56Wk9XL/wANDSK5nmZ0MJ/J7Ynp
PLAFsGWABusA3mM1WGxUuvDV2FAlMygVBDBPb9jer3tXjQJ1YeFT8FEVnUHlmoYr
CUbQ9yN9DPD2U4inQwrtKvN8fO8ITKqMagQN3R4tzgq56uEFHMC0V/EM7fDWmAcF
VClDQltJyTFuD7AMr95Q5IMPWDqo2ZSpiZQ7IvQdBio4J0vwjJuSydSZvlevHxqE
RCrg1WV0R4/Ab2ySjRkZ9DzPeakm5uG+VDdzddO4ykE+TobPiZ0ksFKdph18ehcH
AmBmPZGCF0qPMbOKQZ4ygECsynqn0uJ21wJNYaxnr2gnxkd7eSf/LlEQJ5MfDlNu
iJqliMvlDanjBeQkRQCgWwYpYD6zAGr4IOrnnQRvpfkdwEO7VM/qeihiSQkgX8QQ
qWy/WEGRRRMZN3TGMplPmDkogNQfMb/du55cyHp2WcN/9RSHco0VJK1XCplxhlzK
8HHAS7nrG4gRSiPjN5Cu
=uUnV
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xigfy-0002se...@franck.debian.org



Accepted libbitcoin 2.0-2 (source amd64) into unstable

2014-08-15 Thread Jonas Smedegaard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Aug 2014 13:48:13 +0200
Source: libbitcoin
Binary: libbitcoin0 libbitcoin0-dbg libbitcoin-dev
Architecture: source amd64
Version: 2.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Bitcoin Team pkg-bitcoin-de...@lists.alioth.debian.org
Changed-By: Jonas Smedegaard d...@jones.dk
Description:
 libbitcoin-dev - Bitcoin toolkit library for asynchronous apps - development 
heade
 libbitcoin0 - Bitcoin toolkit library for asynchronous apps
 libbitcoin0-dbg - Bitcoin toolkit library for asynchronous apps - debugging 
symbols
Changes:
 libbitcoin (2.0-2) unstable; urgency=medium
 .
   * Add patch 1001 to fix include Boost endian include.
 Fixes FTBFS on big-endian archs.
   * Tighten build-dependency on d-shlibs to versions supporting both
 multiarch and skipping .la files, and simplify rules file.
Checksums-Sha1:
 608809142d30f5ab04d4c308c03e07ab33811577 2499 libbitcoin_2.0-2.dsc
 0d90e023e4794cca5add41171ee7fddd7e2b3b49 18860 libbitcoin_2.0-2.debian.tar.xz
 75719de2d3d2dc4e133ee7815c2221672fb85d1b 455120 libbitcoin0_2.0-2_amd64.deb
 2f345f248c8735f0b91e8f39132916e5e19ee5b0 5520422 
libbitcoin0-dbg_2.0-2_amd64.deb
 9cdd48cfb34d4e79a88c79c55611704773752679 650414 libbitcoin-dev_2.0-2_amd64.deb
Checksums-Sha256:
 1aa2a1bcd9f57d843fad5f0e17add2f83773145e240819907b5ddf01a92208df 2499 
libbitcoin_2.0-2.dsc
 ce7cb6e4154d489cb53955d7d7f7925f2176060f2e458921de7b4434e82af0a3 18860 
libbitcoin_2.0-2.debian.tar.xz
 1110726538e2c804a0ac19ad9034e1e1f4cb6f2fbee75674638ae47ddacf6b73 455120 
libbitcoin0_2.0-2_amd64.deb
 01bef13c868212e4c3559bf96262cf773ddab7fcd295245967dd7fb356043927 5520422 
libbitcoin0-dbg_2.0-2_amd64.deb
 6cd4a8681fd8130b52adbc1bd14ee5a2a76c42a9c93f4e1c00ff0aa0744bf146 650414 
libbitcoin-dev_2.0-2_amd64.deb
Files:
 12b2152d0b90c2e3019fbd725e25e8f9 455120 libs optional 
libbitcoin0_2.0-2_amd64.deb
 53b1efa33bed96a68c0e198ca157aff6 5520422 debug extra 
libbitcoin0-dbg_2.0-2_amd64.deb
 4fe63b91f5de05b929c2966d7e33fcd6 650414 libdevel optional 
libbitcoin-dev_2.0-2_amd64.deb
 f2396b8c306b5f817ff5f8b4bf26463b 2499 libs optional libbitcoin_2.0-2.dsc
 f8633021dbf1470ee697c70457372266 18860 libs optional 
libbitcoin_2.0-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJT7f3PXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy
QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEh5BIP/RWXnsLzhXhLKRBbPjBsr6dU
a5oXUe2+C6fTHhchPSLcWfzeT4dBL45H254F4DSDCstVonobHvrS9YMiCnkzP3vZ
J5IkwGU6yorvq8ac+YqLuDffsPncv7/8MG54hzSbdM0JZw/9lawln/GXRq6Wkrel
qoQTuWuDBmQCvMCJxPjQcpeO+b2j4GkfHRkM6J6xpSvKz9qyNFlVmxT3ZW3CZNF/
HYYzXlhpgBAexGjofiMeZc/tRW7CIEGVKqgUqVtrYWraAUzpPNA8eIpZuzhsrGch
KyQbNyXdTuyTC12NDKen6Vp9JKZVVJyohgxL475zruuCK/QrxuEVThc5t7A5Z4M7
d/+vLmLls7wndXI7A8GZmlIyl9DH0v4KcBF6MEGKjcPRtt8wUA8IFkdOhPmFklNW
w4yy32qgeK5wUZOLqgHBTAW98UBai+aqC35Trp7EbfPZShWlvMA8vLNf3Dj09P4L
hFyYOFAo2GQLnvvsFpy9M0dGKk33RdRujNrCpfX0puvdD+upIPCfcIlI6LkIw8YF
ELGKIbj7ScuBfuJntMvzySzFBGQ7HxZz38NuhFSEG/WQO8YqCc8Akofkv9yQ2App
G1UET7/lKQWIjKLTcUtKam5udCTZb7WMbNw+Q9ic55eGDInmUgXpW+iz9BGQHlxx
+inQ7h5XT0I6Yordzpyg
=RZTv
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xigw0-0002vo...@franck.debian.org



Accepted ants 2.1.0~rc2+git3-g9103999-1 (source amd64) into unstable

2014-08-15 Thread Yaroslav Halchenko
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Wed, 13 Aug 2014 12:12:07 -0400
Source: ants
Binary: ants
Architecture: source amd64
Version: 2.1.0~rc2+git3-g9103999-1
Distribution: unstable
Urgency: medium
Maintainer: NeuroDebian Team t...@neuro.debian.net
Changed-By: Yaroslav Halchenko deb...@onerussian.com
Description:
 ants   - advanced normalization tools for brain and image analysis
Closes: 757595
Changes:
 ants (2.1.0~rc2+git3-g9103999-1) unstable; urgency=medium
 .
   * Newer upstream pre-release
 - should be compatible with ITK v4.6.0 and VTK 6.1 (Closes: #757595)
 - explicitly include libhdf5-dev into build-depends to mitigate
   problem with insufficient depends of ITK -dev (see #757594)
   * debian/patches
 - removed debian/patches/up_use_bash (upstreamed)
 - Add-soname-and-local-data.patch - deb_local-data.patch
   (SONAME and SOVERSIONing is done now by upstream)
   * debian/{control,rules}
 - build without VTK support for now
 - added libpng12-dev to build-depends
   * debian/rules
 - fixed up installation of versioned ants modulefile
Checksums-Sha1:
 12ff294f97495e08df91b9395192f798ddfbfe4e 1661 
ants_2.1.0~rc2+git3-g9103999-1.dsc
 2b9f061c3a64306cafb185bf8e06032ca56150fb 2210436 
ants_2.1.0~rc2+git3-g9103999.orig.tar.gz
 cb8104d9990a43dbb726c742f08154d89cd8b3d5 114804 
ants_2.1.0~rc2+git3-g9103999-1.debian.tar.xz
 314ac931ce0e94d698efac3a365dd8e0ec148070 22171784 
ants_2.1.0~rc2+git3-g9103999-1_amd64.deb
Checksums-Sha256:
 b9e986cc2c0b0013435ca6f90e49837321d4e185c09b81edfbc8811f8b453d50 1661 
ants_2.1.0~rc2+git3-g9103999-1.dsc
 f04338417f17b9e90db4d4068201e31075f62397e788e65441cca3c44f2871dd 2210436 
ants_2.1.0~rc2+git3-g9103999.orig.tar.gz
 6f3ad33f1ff79e9e9309476b5eadf855717b0305ebc3c2ca06f251ddaff2c519 114804 
ants_2.1.0~rc2+git3-g9103999-1.debian.tar.xz
 abbf9276bbca3329d2dd6b6086a8e416274aaf2daff86c77603acd15a5aca9c4 22171784 
ants_2.1.0~rc2+git3-g9103999-1_amd64.deb
Files:
 0e573f639123b30e3d315600909e42e4 22171784 science extra 
ants_2.1.0~rc2+git3-g9103999-1_amd64.deb
 c0c5d867bc6696b1d5815d275991 1661 science extra 
ants_2.1.0~rc2+git3-g9103999-1.dsc
 d292d66f3fb2c7e6d3ce988112bd1e22 2210436 science extra 
ants_2.1.0~rc2+git3-g9103999.orig.tar.gz
 aef9d10937fd4f0951290c18bad08999 114804 science extra 
ants_2.1.0~rc2+git3-g9103999-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlPuBx4ACgkQjRFFY3XAJMj8uwCgqMwUVJqFfPhteCvj2+8Z7Cxp
3dkAoLcWRnayk/PxxhMRkuMLcOFP3oJg
=qeXZ
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xihpo-ws...@franck.debian.org



Accepted raxml 8.1.1-1 (source amd64) into unstable

2014-08-15 Thread Andreas Tille
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 14:40:09 +0200
Source: raxml
Binary: raxml
Architecture: source amd64
Version: 8.1.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Andreas Tille ti...@debian.org
Description:
 raxml  - Randomized Axelerated Maximum Likelihood of phylogenetic trees
Closes: 729537 756392
Changes:
 raxml (8.1.1-1) unstable; urgency=medium
 .
   * New upstream version
   * enable SIMD and threading support
 Closes: #756392, #729537
Checksums-Sha1:
 7b3caded5759253964e693ebfb7e29d56baa1bd3 1985 raxml_8.1.1-1.dsc
 7c5214a4bb8f001297f395d4a318f1ea73d89153 797132 raxml_8.1.1.orig.tar.xz
 19872eeb0f88aae61763adac464da815c2f9e0fe 3984 raxml_8.1.1-1.debian.tar.xz
 3c63aecb41164f421341a9415556271b7c8e5d05 1080236 raxml_8.1.1-1_amd64.deb
Checksums-Sha256:
 5a32c89d133e98f69ba173b4fa92625fb883a72ad0405470349fb3bf0930c8a6 1985 
raxml_8.1.1-1.dsc
 55b618360a236ed7e40cfc051683e8b1a689d2a1ef245507da112327d55e2e69 797132 
raxml_8.1.1.orig.tar.xz
 6c4b9aad374997acbb342b152ca6814788bfdf856ef54f06079c4dc6c8d6676a 3984 
raxml_8.1.1-1.debian.tar.xz
 f99403b855f208ecb56899203ba00c634ea31d86727ee35f4af542cd559e8300 1080236 
raxml_8.1.1-1_amd64.deb
Files:
 c67861b40ce2679cbf15f8c816ad2c7f 1080236 science optional 
raxml_8.1.1-1_amd64.deb
 b48d136531647a82180c1628437db616 1985 science optional raxml_8.1.1-1.dsc
 a76976d0fba60ffe4e8b7db6ef19c4ea 797132 science optional 
raxml_8.1.1.orig.tar.xz
 6f9c274559cb0784614af4500993e3f5 3984 science optional 
raxml_8.1.1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7gRlAAoJEFeKBJTRxkbRpJYQAJvHQUkGjRklec9EKpgca11P
MOfJgoANfwzpF8C/HYpShVa9N+ovUnPFUM6zQ345dYIejdKY/bU37spzv2dqSy06
8cWEYLLxKzKjw+BbUTbSN12ydvPiJHXrMjbfCPTdolEoRHnK9ycvTB2Uvwem1Z4E
Spj6PuUiFgEmX3C063Uui4cQuTDIm3BXGK2MzwCGQLRKrUB2trr36MB4P2UftMEc
MVScTtLRp/bKnjWfUxephiya+KfsIcFoAg8dBDnsgne+XvFd+0tGar7HPtTAe0YY
8Ze4gmJupz21svf83tWE6PglohSRbFYSqqxJb/7lTywMI8NBrNUhyEyuQWsDNKfn
kHf/YLdcsoMktw0g8pkaiTsU115Upfy+zBDl2ubIKlT0k9DKX1W64DJp/iM48nm3
AnwW2z9F3Ir7jLN0X0vHLNIDSR6F05eeV+N72ujFcoulS8cDXWwfvudNvO4D3n/J
MTBMzd5BYAh4xze3+ymdr0H89yeNK6vf1HLRDoT1XrFFP4aleyXqis5eKkNfBytf
C5vg7ZcvdB/cXuvS21F+mmbQm4IkCn4HuX6hlg8T8y0WcOU8XSUUZ92rKUBXPRdj
aaL3yf8pe64tnwlmTCLaqIKllUoutvwwtocrVNQIXqU0uesAbULs782h+OGQL1ku
6j1T8lRV6lGxn9jmBJDT
=wSKq
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xihsd-00016c...@franck.debian.org



Accepted album 4.12-2 (source all) into unstable

2014-08-15 Thread Joao Eriberto Mota Filho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 10:32:11 -0300
Source: album
Binary: album
Architecture: source all
Version: 4.12-2
Distribution: unstable
Urgency: medium
Maintainer: Joao Eriberto Mota Filho eribe...@debian.org
Changed-By: Joao Eriberto Mota Filho eribe...@debian.org
Description:
 album  - HTML photo album generator with theme support
Changes:
 album (4.12-2) unstable; urgency=medium
 .
   * New maintainer email address.
   * debian/control: updated the Vcs-Browser field.
Checksums-Sha1:
 dda6f9eca3c69f44369315db9c17b7abd9b1809c 1800 album_4.12-2.dsc
 51bc444a5134baefd0f54e2e15dc07dae865dfee 5084 album_4.12-2.debian.tar.xz
 c62f7cc490c9302531a098d4954d94c0bf9608ac 89488 album_4.12-2_all.deb
Checksums-Sha256:
 8a062b9c1d2633d63deb9a58a26180eb8fb7373f675b741abfdba37d4ef7353f 1800 
album_4.12-2.dsc
 f63d588fb73f332c9eca5cf4b00b089b4a66e1f71b6d2ae20db29b615cd776a4 5084 
album_4.12-2.debian.tar.xz
 46182c7043760dd85b867b3bdb38039160051112c26e42971d9eaccd9251f18f 89488 
album_4.12-2_all.deb
Files:
 3c59e00aeb2ec090883c6b091eb92379 89488 non-free/web extra album_4.12-2_all.deb
 4ffd25a462974ae383337a151775740e 1800 non-free/web extra album_4.12-2.dsc
 178637997e90f887a2039a1545d57a6a 5084 non-free/web extra 
album_4.12-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJT7gygAAoJEN5juccE6+nvTxEP/iWlJZAmbYSDBeAs9vb+6sbw
MLDx25nBt9AGf13i/OJw7bI3jEpOtrsF+iYQ28KD/lIy1kE8+bKB2mmfVaHfD5v7
c+Oz1reUOiKbk1WHz7jKv7Z97z3zyBQceqm8voyc69izbdmDQ2rPjcBRxsV8/1Ph
EECl/HRKDSUnI7+RlVeIhNQNdR9wuKHBugpMeZpdLVjeuorLiydVWxHrhLA5tN2G
yPIDST6jx7SGOKCqVjpdgOXQqo14UFtzZutxt0p4zKuS4wXvNQabaNHqFuQZWKiB
yhj9Hlc3N9liE+wNq5fcESeZSUEYXWsG2n6/+02wqR8uHbkqRXuJPVx4vfj0ksTo
jvQXjsVVqli1Oq24YQNwpVm85fQ++Inwew+JRS09CCj+JDuPByRLUCwDV0YcghDX
7VZ/deAn03kx19t95JTmmVRWa4p7Ft8KomqqxDSUqrmyA+c8KTwQaRMDwCtabICu
irGFIiNYA64tDkXvH2W1zrYrmNJOp1896VjTaVm51LKCbz03AgOEAYxnfIMFdN2q
oQUe0MkvlyidQX6BDvkZltUmDvxxe+IgeFM6f0C3D3/LX6TPTtThA+VFRHo7UO0F
sRrXuPDEFaRapHOCy7MQ3Eqz9FgBPj+FUkxxwv4HeF5GuIMPnwW9XkvxVDL5DEf4
jlrpm4lkOLwkvvxN82jK
=uXi3
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xihro-000600...@franck.debian.org



Accepted libtest-command-simple-perl 0.04-4 (source all) into unstable

2014-08-15 Thread Casper Gielen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Aug 2014 13:52:42 +0200
Source: libtest-command-simple-perl
Binary: libtest-command-simple-perl
Architecture: source all
Version: 0.04-4
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Casper Gielen casper-ali...@gielen.name
Description:
 libtest-command-simple-perl - Perl module to test external commands
Changes:
 libtest-command-simple-perl (0.04-4) unstable; urgency=low
 .
   [ Casper Gielen ]
   * control: update to standards version 3.9.5 (no changes needed).
   * control: Use package name in long description.
   * control: Use libtest-pod-perl and libtest-pod-coverage-perl for extra 
tests.
   * copyright: Remove deprecated Format-Specification: and replace Name:.
 .
   [ gregor herrmann ]
   * Strip trailing slash from metacpan URLs.
Checksums-Sha1:
 0b683c890fe4d88d729ec848047b4cd6a97152f1 2375 
libtest-command-simple-perl_0.04-4.dsc
 9841d369f338d3ab860d3435a85b1054e185945a 2024 
libtest-command-simple-perl_0.04-4.debian.tar.xz
 b3a093412799c6a66d675088b40b74edbdac3c29 10116 
libtest-command-simple-perl_0.04-4_all.deb
Checksums-Sha256:
 d6600a656f38cbe52859bfb79090c0b6426d54ea8e9b62278aff851f602038c0 2375 
libtest-command-simple-perl_0.04-4.dsc
 0374b4ede169313585ab2634f85b94a9c9d7714ca87ddb6dd027d2ff15d0d427 2024 
libtest-command-simple-perl_0.04-4.debian.tar.xz
 d124dbce7ead11463c6a26c5a73adc0b8b7285a9610fbe95edb287048e4a2693 10116 
libtest-command-simple-perl_0.04-4_all.deb
Files:
 65dfc9baf6a5ecb4645fcb653c91d26d 10116 perl optional 
libtest-command-simple-perl_0.04-4_all.deb
 00df220b61ee1d14e24efad5dd7bb8ff 2375 perl optional 
libtest-command-simple-perl_0.04-4.dsc
 d4311c92d6266b80d92e95f04bca964a 2024 perl optional 
libtest-command-simple-perl_0.04-4.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJT7g7vXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGnUMQALOaEzf/par1XE194KLc59EB
DHYEyxyK0eIs8+VovniKQ0VyejDq6FZc1zl4NGIIuIBlzsOqvk5lzEDh1V1xx+UL
Ghr08bU6Z5R0KQJq/qe6rSU/3iNjU3SdLc1cnEVWbAQmvo6i+qk5/iQ4+CaRE8bf
T/0R6M+qZzBXpimP//jY0y+xPFVPJEaFkc51GoKFy8yS3IkMhqGF0iqxmQhPB0vf
SAWu6XG3OlpLEu7AoOobeT14kYoWgqpSWj0L6ybfcqwuJqtQEZvePLW9X3+XVmi0
dSGJo/Cx8WRqbGWCwV4kwYsYzv9tDO8aZ9hpnsFye/LDujyLodkD2TfWmIidrU8F
tvUMv/eYrVVFgNZ0aRq66lubKedcj+mpUPlOgOk8dS8RoHynpi5CmffqoU6lewRo
NJ5+rgxlzE7FU2RKPMUFLlb6smlpfnEjDxXVtc00pf/bW5Ygq40vjP0oWA15odie
q56Wkj2Z4iDNyMw/1SGB1IFcca4hhGiHkHnO7scWOq9CUVIkCXtkagOTmNKJxfC9
DnSDAhQLVVHntpvuWYx2T2xMK7RC+JuQ77gFRlP20WCGZ5IunsiY0TEnJOVK8rTT
Se3xVdwBg4+EHMlU1zQ1J5J2FTnMccpoAu2ZPfHQcTfXWk+cW3gU36G9VjREQnax
TnUBJNu4ParHmmqUPpB9
=6di7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xihu6-0006ji...@franck.debian.org



Accepted servefile 0.4.3-1 (source all) into unstable

2014-08-15 Thread Sebastian Lohff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 12 Aug 2014 22:10:49 +0200
Source: servefile
Binary: servefile
Architecture: source all
Version: 0.4.3-1
Distribution: unstable
Urgency: low
Maintainer: Sebastian Lohff s...@someserver.de
Changed-By: Sebastian Lohff s...@someserver.de
Description:
 servefile  - serve or receive files from shell via a small HTTP server
Closes: 753716
Changes:
 servefile (0.4.3-1) unstable; urgency=low
 .
   * New upstream version
   * Updated recommendation from iproute to iproute2 (Closes: #753716)
Checksums-Sha1:
 218ebd2078fce05b75bf046c464c646b94438ac1 1711 servefile_0.4.3-1.dsc
 41b3c1b77194d884aa5d17daed102812058cbb30 13880 servefile_0.4.3.orig.tar.gz
 ac61f3cb9a8fcf9eaa8f0ac9340d0e45c7728388 1812 servefile_0.4.3-1.debian.tar.xz
 03067c73cfd2d8868ecd4fa2c2d4e66dcebcf4cb 15922 servefile_0.4.3-1_all.deb
Checksums-Sha256:
 7c3d0879aebde02d696dc1004541085865364273e28e969b99bff13578c54a69 1711 
servefile_0.4.3-1.dsc
 53564c0cf4791ce2dbe86aeae9b7f436d85a1b6d0d2d04de1afd237943363c83 13880 
servefile_0.4.3.orig.tar.gz
 ae20f7e78d2eb10d9119235e762844d11231aa84a645c9ac695b3a9a019c8f9b 1812 
servefile_0.4.3-1.debian.tar.xz
 da94f4a84ecd10b949dbae79ae19095cf41aa03b707a77970a1a1bab090c6688 15922 
servefile_0.4.3-1_all.deb
Files:
 0fefc77129d77d9f9df0bad206248c52 15922 net optional servefile_0.4.3-1_all.deb
 364472ac89f473bd8acd6c2af7b74d70 1711 net optional servefile_0.4.3-1.dsc
 5e4a1fceed0139017f814f72c1cb4410 13880 net optional servefile_0.4.3.orig.tar.gz
 4d0a6ddb6bbadcaca402e82d7e132667 1812 net optional 
servefile_0.4.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJT7g41AAoJEMcrUe6dgPNtkJIP/jdyx9fpCSZZe4U3nWMiwNcD
DGb2ReSxEJUNjt7/Ed5iImaTb9iupPZrqfUYXANtTsIZXtr613qK5yH32D62g3Y+
I9waXnLKTBLr9LnfO4dAEbaeXRL1PD0voOfq1+NJ8bNpDoPLGN8UVTRbQjELMFkb
K9eT5B3nXpr9N4d+wmPuyKDhxLgCmSWXYKMMBGRYiF24PvxQ246sxsd8k2nxttpb
CyLQGvay4RBptCyw+nD2MxfoRaTuyXZUjslyie4qb4bxcFRYNfs5fcCf4r/ZvQQK
T+y3HW5z0SR4dZtxLX90Y3RTtOeqo6g7OytiFXU29G4aOGyBaIfqPv8yz7FAdnq3
6Xp5eLrYmWZKhSqcewLbeCywcaYIxMzaEPS78PVFjU66o+BCn0KZZNZfPCmZCAvo
OWo1KpJprU2uvDYH/VxFmm8Zej3arxlJdfnw4WxLDanzU1R8DZ5n6FwD2YX6WzQQ
SFsC1ytT98dNl13QP6VRGR2s8lRfjxD7p/9Ymzm/9V6LbnGTT4S7vUFrpN3N6XrC
Do0GThy0lzfzPWsj96x80JAhcWj5AAn1yTEutlGA7M7X+2jqnQTpZvJQgRROX8+K
wHJp83tdDW9B8kweY0768zgtDM1et/nalZ21BaPD6QHbgYlUGa8kwfuvccEiRf1z
1plb7OqTSjTzrFQlGIhE
=QWMG
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xihuo-0006qw...@franck.debian.org



Accepted octave-io 2.2.3-1 (source amd64) into unstable

2014-08-15 Thread Sébastien Villemot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 15:37:40 +0200
Source: octave-io
Binary: octave-io
Architecture: source amd64
Version: 2.2.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Octave Group pkg-octave-de...@lists.alioth.debian.org
Changed-By: Sébastien Villemot sebast...@debian.org
Description:
 octave-io  - input/output data functions for Octave
Changes:
 octave-io (2.2.3-1) unstable; urgency=medium
 .
   * Imported Upstream version 2.2.3
   * Remove Thomas Weber from Uploaders.
Checksums-Sha1:
 9a8a7bc68ec4a800330a677198534f8691751215 2010 octave-io_2.2.3-1.dsc
 96b99e9731e72347861e8dc59fef6933e7c4edd7 245151 octave-io_2.2.3.orig.tar.gz
 aaf43845ebdaf4f1c9963426b408b8ec740ca484 119372 octave-io_2.2.3-1.debian.tar.xz
 07f799c41bae53a715e182e0b0087d1fb7d60581 230030 octave-io_2.2.3-1_amd64.deb
Checksums-Sha256:
 76c56ac442f91b7829be4b91e9444ec8fbedbeb7befb7b52b4520104994a6939 2010 
octave-io_2.2.3-1.dsc
 84569d77d9a5cdf49fd80e3956db1b4dd1e1efa358cba9ab1020bc4969656192 245151 
octave-io_2.2.3.orig.tar.gz
 bac1e2782d1ab27e7a44c10c1b4f5f3aad582aaf698a09c82bffd5c69e9fa144 119372 
octave-io_2.2.3-1.debian.tar.xz
 5ed71ef5b7eeaeb66597f7b44a40d648b9180cad49317576129773ab9c0b6b95 230030 
octave-io_2.2.3-1_amd64.deb
Files:
 dad4c216310894ed2a622053c36f9706 230030 math optional 
octave-io_2.2.3-1_amd64.deb
 978e7316d0d5954823cb69c5f765ef57 2010 math optional octave-io_2.2.3-1.dsc
 cbb95206580bcd484be9562b462e801c 245151 math optional 
octave-io_2.2.3.orig.tar.gz
 6e89d7b31f4ae8dd16320cd3d1fe73e6 119372 math optional 
octave-io_2.2.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7g5EAAoJECzs6TUOzr5KFa4QAJV5ic94K5NVJN9Lh19SsEgW
N+5WkZ8t8wtNjgC86/JQ12PidGFZxpkvqa/Uxz9v71J16e3gWaQpe0TEC8yKY60e
fgxlfGOC8450Awsm4ZGWL0qi7PpsXHaPXuWvMaJTT7Ga0V0Hg0xpZvT79Jj9HCF4
Du3nhVd6nDl6/bUwTyVyPbqY11FvA4ooXqsIsWkZf5lO3xL8BO9xfpqESBgdkQZ9
IbC/svxgnSbOc//j80LWoxMu1Gi0wL8jFWvgrpRd1ykOxnO/ckOcl2a35T72VmBd
qs4PQOUMp3W/CocHmaRqliP77+14vpgmztnDphfxIUVFbfHiIDIMt6BClvrn+jE2
seZPv0F6Qnd1SCNelictxpWdA+9aShEvj4+DyDcYPCs3euDVOKNGUktnn1dXRSEx
buJi1AQwvGuqkICp8yS3Lif/f1rW5PmvO6dqjkAvFb4VQ462L46mBMzRGwmh1EnT
EonkCI9wFInJBvzWoodipcQoJ1e3tThgcyLORLUqQiM7pcYaP+C9vd4e0UoyhXb5
18+rFlhmpNy52GsZzlsd+SWhm3ToXEiaTwAq/T7kBe8rppBqVNplIZHgMU/qvfTx
0vt3WL7fQiyfvgVLoQoSzzfYxQgzMXESxuSAu262P8O77+/IM/DtwrodmLpZ17lB
LRjTa0OcvNdnozlZKBmH
=B56n
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xihuh-0006o3...@franck.debian.org



Accepted album-data 4.05-4 (source all) into unstable

2014-08-15 Thread Joao Eriberto Mota Filho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 10:39:05 -0300
Source: album-data
Binary: album-data
Architecture: source all
Version: 4.05-4
Distribution: unstable
Urgency: medium
Maintainer: Joao Eriberto Mota Filho eribe...@debian.org
Changed-By: Joao Eriberto Mota Filho eribe...@debian.org
Description:
 album-data - themes, plugins and translations for album
Changes:
 album-data (4.05-4) unstable; urgency=medium
 .
   * New maintainer email address.
   * debian/control:
   - Updated Standards-Version to 3.9.5.
   - Updated the Vcs-Browser field.
   * debian/copyright: updated the packaging copyright years.
   * debian/watch: improved.
Checksums-Sha1:
 b74c923faa89fb6f32e85a95db73aef6665d4977 1861 album-data_4.05-4.dsc
 c8b1a951a5fca549120d5f6950aad974ca872aa7 15720 album-data_4.05-4.debian.tar.xz
 c210255c6b5964e079ec45ce7b72bf1de1fc1d0d 5476776 album-data_4.05-4_all.deb
Checksums-Sha256:
 944b61c29d0bac79a161532236a80a4729fc1ac69e2b75f1d2bc1f342971ad72 1861 
album-data_4.05-4.dsc
 c3247a8f32a2744ad7708d856208e565255b1385bfe03f0ed1a7cdbb8fb9a18c 15720 
album-data_4.05-4.debian.tar.xz
 36fb253eef1a62d51be340848a620f45df7bd87801bb7ddf23b345b20c38ca8c 5476776 
album-data_4.05-4_all.deb
Files:
 14e4d4a0576adb775e3fa9f873dc6234 5476776 non-free/web extra 
album-data_4.05-4_all.deb
 73cc4d840c3d239d65acd9991a78201c 1861 non-free/web extra album-data_4.05-4.dsc
 a083fd7e0e2af73a597f224a45c1d9e5 15720 non-free/web extra 
album-data_4.05-4.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJT7g9MAAoJEN5juccE6+nvNRUP/j6wjQYayXPq105nWfwhKhUK
NyaFuo3eLmHdOyaQYBVH2gVRzvygNM1l0/up2Q2Ww6CusTLmw19xQo//SNE13OeN
2ZUKuM61F4EIqzCkc079CCB41ok6Umvqlx82aiR2O8xXyKdf4DfmqsgvSm6Dk9O9
elQ0ATl5t5JpjXQsqgZglURaxzUs01wEcpGQeQA+QJo4vWevVPi4CMAMFklT1u6o
DXf5YSVSEb3OkDfjkZoiJThjynbOWYy6dtLvf6+M8N1185OypoSfqEPOhqliAQ9s
PtBPDV3BM/1CibjlBoJHotlQw0P7309NC03s4ZsCCQeHw8XZswu8DWPZyzK0MHwq
rPDOl9e5N7Or0pg2aoth515MxJkKEq7SKkdTIfgUuYqSfwjpmkyKX7fSgH5Lmebu
xiU1bA7hjzsBz0sozEvl3DduUonWj49x1xj8WEhj+QpfyTsdgfuoUDRQK6W89U1i
uZ3hZKyNcbyd91OqQZlpHH88DkU+7ZdST/4HpSEGkITojWcAno5gu+BbcLCsk/2d
c/5c7sbQEJ97AhZm5NlqAj87sQpkNlEz7AnQT197gkQmVoT+4zqFYYKxh0iWgx3o
NBQXUdIIbGbzyeEHIJilmGiSxp3Y0sqH/2ddJPF9qyBc6Ai/vuqYeQ34CfeSbSsc
RjC+F1qTYNBchPZPrIxO
=3Gxw
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xijkw-0004fh...@franck.debian.org



Accepted erlang 1:17.1-dfsg-5 (source all amd64) into unstable

2014-08-15 Thread Sergei Golovan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 14 Aug 2014 13:44:54 +0400
Source: erlang
Binary: erlang-base erlang-base-hipe erlang-asn1 erlang-common-test 
erlang-corba erlang-crypto erlang-debugger erlang-dialyzer erlang-diameter 
erlang-doc erlang-edoc erlang-eldap erlang-erl-docgen erlang-et erlang-eunit 
erlang-gs erlang-ic erlang-ic-java erlang-inets erlang-manpages erlang-megaco 
erlang-mnesia erlang-observer erlang-odbc erlang-os-mon erlang-parsetools 
erlang-percept erlang-pman erlang-public-key erlang-reltool 
erlang-runtime-tools erlang-snmp erlang-ssh erlang-ssl erlang-syntax-tools 
erlang-test-server erlang-toolbar erlang-tools erlang-tv erlang-typer 
erlang-webtool erlang-wx erlang-xmerl erlang-dev erlang-dbg erlang-src 
erlang-examples erlang-jinterface erlang-mode erlang-nox erlang-x11 erlang
Architecture: source all amd64
Version: 1:17.1-dfsg-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Erlang Packagers pkg-erlang-de...@lists.alioth.debian.org
Changed-By: Sergei Golovan sgolo...@debian.org
Description:
 erlang - Concurrent, real-time, distributed functional language
 erlang-asn1 - Erlang/OTP modules for ASN.1 support
 erlang-base - Erlang/OTP virtual machine and base applications
 erlang-base-hipe - Erlang/OTP HiPE enabled virtual machine and base 
applications
 erlang-common-test - Erlang/OTP application for automated testing
 erlang-corba - Erlang/OTP applications for CORBA support
 erlang-crypto - Erlang/OTP cryptographic modules
 erlang-dbg - Erlang/OTP symbol files
 erlang-debugger - Erlang/OTP application for debugging and testing
 erlang-dev - Erlang/OTP development libraries and headers
 erlang-dialyzer - Erlang/OTP discrepancy analyzer application
 erlang-diameter - Erlang/OTP implementation of RFC 6733 protocol
 erlang-doc - Erlang/OTP HTML/PDF documentation
 erlang-edoc - Erlang/OTP module for generating documentation
 erlang-eldap - Erlang/OTP LDAP library
 erlang-erl-docgen - Erlang/OTP documentation stylesheets
 erlang-et  - Erlang/OTP event tracer application
 erlang-eunit - Erlang/OTP module for unit testing
 erlang-examples - Erlang/OTP application examples
 erlang-gs  - Erlang/OTP graphics system
 erlang-ic  - Erlang/OTP IDL compiler
 erlang-ic-java - Erlang/OTP IDL compiler (Java classes)
 erlang-inets - Erlang/OTP Internet clients and servers
 erlang-jinterface - Java communication tool to Erlang
 erlang-manpages - Erlang/OTP manual pages
 erlang-megaco - Erlang/OTP implementation of Megaco/H.248 protocol
 erlang-mnesia - Erlang/OTP distributed relational/object hybrid database
 erlang-mode - Erlang major editing mode for Emacs
 erlang-nox - Erlang/OTP applications that don't require X Window System
 erlang-observer - Erlang/OTP application for investigating distributed systems
 erlang-odbc - Erlang/OTP interface to SQL databases
 erlang-os-mon - Erlang/OTP operating system monitor
 erlang-parsetools - Erlang/OTP parsing tools
 erlang-percept - Erlang/OTP concurrency profiling tool
 erlang-pman - Erlang/OTP process manager
 erlang-public-key - Erlang/OTP public key infrastructure
 erlang-reltool - Erlang/OTP release management tool
 erlang-runtime-tools - Erlang/OTP runtime tracing/debugging tools
 erlang-snmp - Erlang/OTP SNMP applications
 erlang-src - Erlang/OTP applications sources
 erlang-ssh - Erlang/OTP implementation of SSH protocol
 erlang-ssl - Erlang/OTP implementation of SSL
 erlang-syntax-tools - Erlang/OTP modules for handling abstract Erlang syntax 
trees
 erlang-test-server - Erlang/OTP server for automated application testing
 erlang-toolbar - Erlang/OTP graphical toolbar
 erlang-tools - Erlang/OTP various tools
 erlang-tv  - Erlang/OTP table viewer
 erlang-typer - Erlang/OTP code type annotator
 erlang-webtool - Erlang/OTP helper for web-based tools
 erlang-wx  - Erlang/OTP bindings to wxWidgets
 erlang-x11 - Erlang/OTP applications that require X Window System
 erlang-xmerl - Erlang/OTP XML tools
Changes:
 erlang (1:17.1-dfsg-5) unstable; urgency=medium
 .
   * Enabled systemd support in epmd. The epmd unit is not enabled by default
 though.
   * Fixed SVN URL in the source package debian/control Vcs field.
Checksums-Sha1:
 97c2829dbb8ff2971f948a72712d6c127d8b5d9b 5001 erlang_17.1-dfsg-5.dsc
 76df114c573dc4a048e36e4d78bba5322778b218 63820 erlang_17.1-dfsg-5.debian.tar.xz
 f1196a3dcbf193bc46e2138e64784ea723d4c616 16361130 
erlang-doc_17.1-dfsg-5_all.deb
 d2f3b6418f9a57de00be07c9e752a442db81be71 68680 
erlang-ic-java_17.1-dfsg-5_all.deb
 0adcbd674d0bf6222012f2367bbb937109910962 1670050 
erlang-manpages_17.1-dfsg-5_all.deb
 2e5495ca4f80911c887d018504f7e448ad62c1a3 5393524 erlang-src_17.1-dfsg-5_all.deb
 3140b996bef887f5d9bd708f0dfe1895c8783b6a 1038514 
erlang-examples_17.1-dfsg-5_all.deb
 101cc9d31f6411043b4d1894545183ae44f39442 119486 
erlang-jinterface_17.1-dfsg-5_all.deb
 cabeb6e4464ae61962e56f1b728e4d934653425f 100274 erlang-mode_17.1-dfsg-5_all.deb
 06de138175d0c8d1146d3f255b2916dcfc0fdf36 37174 

Accepted lime-forensics 1.3~svn.r21-1 (source all) into unstable

2014-08-15 Thread Joao Eriberto Mota Filho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 11:18:17 -0300
Source: lime-forensics
Binary: lime-forensics-dkms
Architecture: source all
Version: 1.3~svn.r21-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Forensics forensics-de...@lists.alioth.debian.org
Changed-By: Joao Eriberto Mota Filho eribe...@debian.org
Description:
 lime-forensics-dkms - kernel module to memory dump (DKMS)
Changes:
 lime-forensics (1.3~svn.r21-1) unstable; urgency=medium
 .
   * New upstream release.
   * debian/control: updated the Vcs-Browser field.
Checksums-Sha1:
 3a8e0a45ad646d4a736f919933415556dc089a65 2029 lime-forensics_1.3~svn.r21-1.dsc
 67fb3653841dacd2660c9b8ffa2ce28ade2a43c4 648167 
lime-forensics_1.3~svn.r21.orig.tar.gz
 fc7a8662ab8eeb4cc952e519629ab722a4fc4877 3168 
lime-forensics_1.3~svn.r21-1.debian.tar.xz
 0e4773168d5f5900ba45d489015f3a9751624764 621122 
lime-forensics-dkms_1.3~svn.r21-1_all.deb
Checksums-Sha256:
 37e436efbd89274b9852833d6f60906e59cbe4872ca02480f57104f9523fdb42 2029 
lime-forensics_1.3~svn.r21-1.dsc
 d13c21c74bedd74bfa7b5593a4589365e35a3a2eebaa67cf4f32050dcfceee7c 648167 
lime-forensics_1.3~svn.r21.orig.tar.gz
 8e2551f30cb18ef16d67a082c598dd3cf04c5ffb79a52f47601a0d4f3e398e48 3168 
lime-forensics_1.3~svn.r21-1.debian.tar.xz
 5db319aadc0e3a53e7ca45617fc6ab262bdd4ef3bb752dbf24d1f61117c985b6 621122 
lime-forensics-dkms_1.3~svn.r21-1_all.deb
Files:
 3eda8ac39f1f5661192a398be09f6595 621122 kernel optional 
lime-forensics-dkms_1.3~svn.r21-1_all.deb
 9e1ae63b06c45ebb1fba1930ce8b3491 2029 kernel optional 
lime-forensics_1.3~svn.r21-1.dsc
 5805da21a9926262a97ed7a72e595b0f 648167 kernel optional 
lime-forensics_1.3~svn.r21.orig.tar.gz
 ba2fbefc8629f23fe7708b861b509241 3168 kernel optional 
lime-forensics_1.3~svn.r21-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJT7hhoAAoJEN5juccE6+nvdHQP/0fuTOevT902LxbXwCdChwkH
CP3etSeajJYRbjV2ABILumUoQyKOoRkL4yw+fuJZhRUpN8h4HJnhPDR0spwrgOys
0cPEIlrpfQjM4d6I5IdlbO4OaZUhjvxK5iHmDzC3DUReH3RHA1hoV2m6FeyP8HSj
rXSc16U32SQwfyApv/c3vWq1aLtfn5lN1MuoUj9IzF0RxSjOQHNE4kkKrP9MAaqY
nyW7ghuTuXCwRItbwsWnRWthFRVoVi7IcSzn0Unhj40i9Cv2D97huRMFR3NK/T71
IWeKiFX1gccmD/zWXGLUXIXw4xDBzJaSEsdd393WUGtUTOzCBMbGW7cPQFUpxSYC
pyWKuuzG+6bvzOA5wBEnbaRTFnE9HYsgEtfVOVkeXbUAvoHt5kp+y+61kDdwonTP
LW3UYJPXRYNWyghLHY52zmTp6TCYo1uoeKQ2GDPjr6yJjv74vqOZJ0rLMSciXjs6
fZujJmS8DtBU/ITU2zMhirDQ4Gny5L34t0RdmbzFAUomk8hG1MUBGYDsmQWbjbYx
7bN3IqNPc2/8z++eF/eJXhDnGMQxTENJ2OCFk3U0pkqCN1V14pW4+Y57EzxrDoQf
6yGfmbKZtH55e0QELNAAAScMUgP73KcFU8uAbHkBoYN5uIAgZHQOzInOS/mAIQCd
jNRt6m5pfd65a4+H5nQt
=c4Ak
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xijzu-ly...@franck.debian.org



Accepted openhackware 0.4.1+git-20140423.c559da7c-2 (source all) into unstable

2014-08-15 Thread Aurelien Jarno
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 15:35:20 +0200
Source: openhackware
Binary: openhackware
Architecture: source all
Version: 0.4.1+git-20140423.c559da7c-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QEMU Team pkg-qemu-de...@lists.alioth.debian.org
Changed-By: Aurelien Jarno aure...@debian.org
Description:
 openhackware - OpenFirmware emulator for PowerPC
Closes: 322300 339870 704624
Changes:
 openhackware (0.4.1+git-20140423.c559da7c-2) unstable; urgency=medium
 .
   * Switch to dh.
   * Build-depends on binutils-source and gcc-4.9-source to build a
 minimal powerpc cross-compile.  Closes: #322300, #339870, #704624.
Checksums-Sha1:
 d0a22b853566b9a907bc7c1e81d0866165c40fe1 2140 
openhackware_0.4.1+git-20140423.c559da7c-2.dsc
 0d6e11f4f5102ea2694ce396dd6c2b6a235eaa3d 5108 
openhackware_0.4.1+git-20140423.c559da7c-2.debian.tar.xz
 389e237bde940e18e60268a92fa3cc45ce5bbaa4 62852 
openhackware_0.4.1+git-20140423.c559da7c-2_all.deb
Checksums-Sha256:
 0fcb0ffcba928053af3786991ad29d9ab7e76ad25ab01e955a6a8da1c76718be 2140 
openhackware_0.4.1+git-20140423.c559da7c-2.dsc
 73c4daba154938484d6588dde5a4eae7c1454dff0f4ef5317fc8f728f0858336 5108 
openhackware_0.4.1+git-20140423.c559da7c-2.debian.tar.xz
 44845dd57a7ba47a709d1b1c9f413b927e0a518a31c62f158ac6649639313e0d 62852 
openhackware_0.4.1+git-20140423.c559da7c-2_all.deb
Files:
 72ff980cefcbcb0549e18cbc6c95c6d4 62852 misc optional 
openhackware_0.4.1+git-20140423.c559da7c-2_all.deb
 0da182379a261ef26435ef347b5df237 2140 misc optional 
openhackware_0.4.1+git-20140423.c559da7c-2.dsc
 7414d85ebd66890f020053b2dad22c12 5108 misc optional 
openhackware_0.4.1+git-20140423.c559da7c-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBU+4Pd7qceAYd3YybAQh1SQ//Y3MTgcP00TwaEXaNA/d8dUHEVwsht3c+
eqjkqI3Q7C6x6VnQdyYF6WN8BnC7bdmdVCw2ZkhrM95EM9Y++Rsqk0RgaW4DPylV
VLPgrwMg8lF7UcCBM1fryfv1qX4JDWc4ugEqfbq9Wzb0snqObr2cTsfvuJsLTbw9
yirwju2517Omx1n3MqNm0EqZ7JcMu4gOHQzv5JTkkoVqfdmkvOerLYRBU1/lEQRc
PUABnufEITsTaNMKDlpDMrN/8X7gtwj79v82C9tAhotG3uQpGwXApr/Z6qawjAdC
kfrMxivQ3yU0oTZO+Q6ALN8nHfZEBvNmm7fz20QIRiropmm3fAtIfwEwavPT0Lth
BHBf5r4iNvWUOC0POnj5AuzmM0uNTdxJOM1yn+HxyKI+7NI4WXvLtQ85FQO4TRYG
W9pUGwzZVZ4B+Hrhj+ZamfvItdwhIrhyAB+JncO5WbeVpadXG50vaQwoIngm4yUQ
avZ/vEon24cxdkyOxbswP7Vm4RhPKrUA4qHENpYGG8ZAe81emTZFZPSExmcv2BZg
g1e95YtZ7oOMGnti4IQWBzI8DRNiIaGRG4T95GPjONDNuoe1Yox4cyNaTZ7TrYTH
6AvBrppHw0/M1VJ96JH+iXEIZf/JLgD3jXDoz/rI5spYKhw9xG2qnK9uq+OLqnJf
pwgKspka2SA=
=1mFI
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xik0p-00011k...@franck.debian.org



Accepted pytables 3.1.1-3 (source all amd64) into unstable

2014-08-15 Thread Antonio Valentino
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 07:37:41 +
Source: pytables
Binary: python-tables python-tables-lib python-tables-dbg python3-tables 
python3-tables-lib python3-tables-dbg python-tables-doc python-tables-data
Architecture: source all amd64
Version: 3.1.1-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 
debian-science-maintain...@lists.alioth.debian.org
Changed-By: Antonio Valentino antonio.valent...@tiscali.it
Description:
 python-tables - hierarchical database for Python based on HDF5
 python-tables-data - hierarchical database for Python based on HDF5 - test data
 python-tables-dbg - hierarchical database for Python based on HDF5 (debug 
extension)
 python-tables-doc - hierarchical database for Python based on HDF5 - 
documentation
 python-tables-lib - hierarchical database for Python based on HDF5 (extension)
 python3-tables - hierarchical database for Python3 based on HDF5
 python3-tables-dbg - hierarchical database for Python 3 based on HDF5 (debug 
extension
 python3-tables-lib - hierarchical database for Python3 based on HDF5 
(extension)
Changes:
 pytables (3.1.1-3) unstable; urgency=medium
 .
   * New patch:
 0007-Temporay-desable-tests-that-use-the-lz4-conpressor.patch
 The patch temporay desables tests that use the lz4 conpressor
 on the s390x platform (see #757581 for more details).
Checksums-Sha1:
 7fa267fb8c65cd6f74c752d36489aa993d2e 2351 pytables_3.1.1-3.dsc
 7aa722b537094212382d763fb216a1ef6b01a919 16544 pytables_3.1.1-3.debian.tar.xz
 50c94198267acbf73099d73c5256337b91d374f5 336886 python-tables_3.1.1-3_all.deb
 7b21d972e571a5b4848b59f88564dd1650f6ebc5 350366 
python-tables-lib_3.1.1-3_amd64.deb
 baae5ddd286184a238c861589b5aa9d22c3b1464 437262 
python-tables-dbg_3.1.1-3_amd64.deb
 cfb4e837bdda4e5edeff39715226e149983b180c 328800 python3-tables_3.1.1-3_all.deb
 c484bf6c1f94602ed589c62e8346020e267cb6c5 339468 
python3-tables-lib_3.1.1-3_amd64.deb
 3c53285e036651ce5bf41848a06d3bcfef18bde2 429676 
python3-tables-dbg_3.1.1-3_amd64.deb
 daec331ab3aa8273de9fb9f71df651246d5ccb83 4232306 
python-tables-doc_3.1.1-3_all.deb
 0fd2e89c2b1e555b77b1b4cfb33ec34375887308 48516 
python-tables-data_3.1.1-3_all.deb
Checksums-Sha256:
 261f0db9e9b6ee1e20483f6c55db3cc6d184100d8e1845793c4bba3aa7ec70b2 2351 
pytables_3.1.1-3.dsc
 27ddad8800c6b8ddaacf4ca99113b9ef2cb9334177b267786b6ec617b97badfd 16544 
pytables_3.1.1-3.debian.tar.xz
 880152a49d2e21714de5d38c16193747c810d7454146e09cb068e88602a7a8c0 336886 
python-tables_3.1.1-3_all.deb
 88badf7ef603772278a7f4c8a2856fdb0997c8bb5f5f20a1020b86c45d19e99d 350366 
python-tables-lib_3.1.1-3_amd64.deb
 976cb09884b8141ff824e9ad85578e4b96fabcfce95d3b9c5c02a116cb91100f 437262 
python-tables-dbg_3.1.1-3_amd64.deb
 18e6f220b307a8edf8efafebac4b6e1fff8420db656ea1087da05f40594c5561 328800 
python3-tables_3.1.1-3_all.deb
 507f632dc0fda259f801e9cf1c63fb1827a1aa3d19eea91f85aa7ea170c3bfcc 339468 
python3-tables-lib_3.1.1-3_amd64.deb
 841a4122756ca9cd0f49516251ce4a0a1326c4f67f3e26ab1d232ba4367b28a8 429676 
python3-tables-dbg_3.1.1-3_amd64.deb
 3b4cacb2d5b25c2699f8de20fafdd59866bbcc445e7552424afd76994756bf8e 4232306 
python-tables-doc_3.1.1-3_all.deb
 20fa50510261626d39cf29186dd00e7acb0660bc5ce97e71108edbb63ea8b810 48516 
python-tables-data_3.1.1-3_all.deb
Files:
 f4a6d1ca0e57024c3435fe54578a1b76 336886 python optional 
python-tables_3.1.1-3_all.deb
 000dec34c8575b7f40220fbc0acfc811 350366 python optional 
python-tables-lib_3.1.1-3_amd64.deb
 0c71bc976050e02b45072d09f2a1a1a7 437262 debug extra 
python-tables-dbg_3.1.1-3_amd64.deb
 49a793c79244949dbd62af5ebfbcccd1 328800 python optional 
python3-tables_3.1.1-3_all.deb
 fb55c1360db4afa3e173a97050a0d199 339468 python optional 
python3-tables-lib_3.1.1-3_amd64.deb
 9474d286683c435225525189541db5c4 429676 debug extra 
python3-tables-dbg_3.1.1-3_amd64.deb
 0d18c80e90973dd4da2889b995d1f152 4232306 doc optional 
python-tables-doc_3.1.1-3_all.deb
 5e7910896ef7e8b00a5f118454e939ea 48516 python optional 
python-tables-data_3.1.1-3_all.deb
 d5341743f837253794b2804bf588f9b2 2351 python optional pytables_3.1.1-3.dsc
 bdfcfb08cb090ceacc16c36090cd4ad2 16544 python optional 
pytables_3.1.1-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlPuFAEACgkQjRFFY3XAJMhtnQCdHnd6cgmrux0sezkMzzjC9kn0
phMAoKmhHLNxc3nNsSKpXavMmWYxtvYe
=sWt+
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xik1v-0001lc...@franck.debian.org



Accepted r-cran-ape 3.1-4-1 (source amd64) into unstable

2014-08-15 Thread Dylan Aïssi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 29 Jul 2014 19:26:39 +0200
Source: r-cran-ape
Binary: r-cran-ape
Architecture: source amd64
Version: 3.1-4-1
Distribution: unstable
Urgency: low
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Dylan Aïssi bob.dyb...@gmail.com
Description:
 r-cran-ape - GNU R package for Analyses of Phylogenetics and Evolution
Changes:
 r-cran-ape (3.1-4-1) unstable; urgency=low
 .
   * New upstream release.
Checksums-Sha1:
 9b621388dd54d125dc6eb4fbfc1080e6d46be9ce 2013 r-cran-ape_3.1-4-1.dsc
 e9736352d10d4defdfcdcdb864c3638c848bc86d 721895 r-cran-ape_3.1-4.orig.tar.gz
 92836b04c3e2e9d8c7f3902ff696fe50979c 3328 r-cran-ape_3.1-4-1.debian.tar.xz
 df03e8339f3998fb982e3f262b0caaab8d064a13 1234232 r-cran-ape_3.1-4-1_amd64.deb
Checksums-Sha256:
 a74d07c69b9d704c5b18d880b38559551bf3767c7228da73cb89c05a207d53fa 2013 
r-cran-ape_3.1-4-1.dsc
 3aa1054b12bdd83405b9f23e6a6576a503734916510641acd03b212ff1fa7313 721895 
r-cran-ape_3.1-4.orig.tar.gz
 d379f8fb9c513e2971bfd2e61e6fb7ddb6025a63a67b0e5153c17a47c9cd6c6e 3328 
r-cran-ape_3.1-4-1.debian.tar.xz
 54cb718659d7414f276a80e8b176db934e3df79aa0732651d08e6012e57acc51 1234232 
r-cran-ape_3.1-4-1_amd64.deb
Files:
 cda4993e6dda40fb46ac81b07d3ede54 1234232 gnu-r optional 
r-cran-ape_3.1-4-1_amd64.deb
 7d7aca1ee2b466fdfaa966c3f7094f61 2013 gnu-r optional r-cran-ape_3.1-4-1.dsc
 81603fb53ee02ce30bea3c57f2a8ec4f 721895 gnu-r optional 
r-cran-ape_3.1-4.orig.tar.gz
 1e4822b3c0bf3e1c110f2fc6a22677bf 3328 gnu-r optional 
r-cran-ape_3.1-4-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJT7iqXAAoJEFeKBJTRxkbRyY0P/3uAWtgqasQemLSxA8rXadQW
ttEBKkhUauya1ND+LOc56Fpp/FE5B6vcDnHFrDTCvWX16X41nC8lUO2GnZB1SRn1
NtnnIgusvGxWkFT5EIHDHerbJKvJNz+3kgX+gpyF06hTbzLwaZ+h1eZjzl5ztp0e
VdYUnc/V3gg9x0r1hccRrJ72AePx0203dYnBXN/OmaVTCX1OoU4Qm6W+47FmfcN+
onQjfpbhkbkfFRrBoVBKAaGR7sYtfo5DlL1fkJ0Fzici4qPDE7EsjHJtTUCiEABd
SJhj48UBG5Dp8KUxJFeQugL0tJVU5ztjPh/D42kehDQViLW/3a84d/eN93Lvzk9M
tAXOclnIw5lr7lwzeTgXU7qNw2oykToZYcPcU/LAQtP5ms+tQmuuyRpoExnHUuwB
7NGKy+Eebf+TkcABMHhgI3J/3w864/6FENnuRMDge8jnU4VaHHSma+69jENfUqcn
ufXNmFiESlNHJYl5wvXPZHRQr42jkmjNCpEtO+7oSkzdkANsrPgEqN4z3aMiPJkV
7IM5sqBiY5zH9fWsPyKIpAm4GBhTqSqzjwKmCBfWqV8ubwq6ijc5MAxpaHQDljLu
T2EymXaFx3JwcnVd4A8beM02ESoWBTf5OIBwk0el4Bi1sLjUG8aYau3PsnidNzCP
jYNeVVyMOkLhK5sLlXIc
=9jwD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xik2f-0001os...@franck.debian.org



Accepted serd 0.20.0~dfsg1-1 (source amd64 all) into unstable

2014-08-15 Thread Alessio Treglia
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Aug 2014 15:59:51 +0100
Source: serd
Binary: libserd-dev libserd-0-0 serdi libserd-doc serd-dbg
Architecture: source amd64 all
Version: 0.20.0~dfsg1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
pkg-multimedia-maintain...@lists.alioth.debian.org
Changed-By: Alessio Treglia ales...@debian.org
Description:
 libserd-0-0 - lightweight RDF syntax library
 libserd-dev - lightweight RDF syntax library - development files
 libserd-doc - lightweight RDF syntax library - documentation
 serd-dbg   - lightweight RDF syntax library - debugging symbols
 serdi  - lightweight RDF syntax library - serdi tool
Changes:
 serd (0.20.0~dfsg1-1) unstable; urgency=medium
 .
   [ Jaromír Mikeš ]
   * New upstream release.
   * Added myself as uploader
   * Tuned get-orig-source.
   * Remove --debug from configure to cppflags be passed.
   * Bump Standards.
 .
   [ Alessio Treglia ]
   * Refresh patches.
Checksums-Sha1:
 25726e12990b87b5213730e34445a1cc11f6c4a1 2263 serd_0.20.0~dfsg1-1.dsc
 de139555bd30e768ba84d8bdad348e57cd71ebee 230164 serd_0.20.0~dfsg1.orig.tar.xz
 035a6e7af939564b61a8c58ee7cee6a9cf654e05 6438 serd_0.20.0~dfsg1-1.debian.tar.gz
 3dda208da1b4bba8252734f6ab2e078e16add463 13378 
libserd-dev_0.20.0~dfsg1-1_amd64.deb
 4dbc37c18b840a15fa1dff6e97c42804f2086d16 42144 
libserd-0-0_0.20.0~dfsg1-1_amd64.deb
 58312ac2ee32fcdc4b46c9c0f54441a67742 11392 serdi_0.20.0~dfsg1-1_amd64.deb
 528d7627f61026faa4e40d3b757703db7be68386 30020 
libserd-doc_0.20.0~dfsg1-1_all.deb
 6ba1e781e514e4cc40b5a005758cf31af2847eed 116016 
serd-dbg_0.20.0~dfsg1-1_amd64.deb
Checksums-Sha256:
 6189fe81ccbb061b6b117c847bca62aa046b88a63488c54e8c4c590b55756f55 2263 
serd_0.20.0~dfsg1-1.dsc
 18492304a56e206f6332f0577fe951ee4118c544611f2414849483771ace735d 230164 
serd_0.20.0~dfsg1.orig.tar.xz
 1e26391c933d863a05cf6cd449547c6795330ca994afeb566e6e4f1068f9301d 6438 
serd_0.20.0~dfsg1-1.debian.tar.gz
 e813e21e8fc19ca3213c802ced63039f5995cc06b355b1809b726e79ee369c85 13378 
libserd-dev_0.20.0~dfsg1-1_amd64.deb
 a6c60b9ab785e4a3750d84bf67741a0b0c90f507591ee491b4ec238b39fefcad 42144 
libserd-0-0_0.20.0~dfsg1-1_amd64.deb
 5ff7dd63dd608fb309d0fc7fe6deb974e5af6d01edac512b5b33f83488e1d195 11392 
serdi_0.20.0~dfsg1-1_amd64.deb
 4537dd7858c6c31f824f6d3af1158ddf4186e56877ceba92a66d26f4c548ce4d 30020 
libserd-doc_0.20.0~dfsg1-1_all.deb
 2e9048c81e5910b57a6cc800cfb06ea2cd11b451cd737856e29db8a365efce4c 116016 
serd-dbg_0.20.0~dfsg1-1_amd64.deb
Files:
 b0c89b6436c052c15004bd2ac40c6b73 13378 libdevel optional 
libserd-dev_0.20.0~dfsg1-1_amd64.deb
 cc3f05f2754dc72a53cd4b385235324e 42144 libs optional 
libserd-0-0_0.20.0~dfsg1-1_amd64.deb
 f2ab3c6b32207ed0c87e0011f3539736 11392 text optional 
serdi_0.20.0~dfsg1-1_amd64.deb
 853e1fd5018528098703196d72af8d25 30020 doc optional 
libserd-doc_0.20.0~dfsg1-1_all.deb
 64896be58f17338063fb11076d925897 116016 debug extra 
serd-dbg_0.20.0~dfsg1-1_amd64.deb
 86557ad7853b246fb0c649cecaea0319 2263 libs optional serd_0.20.0~dfsg1-1.dsc
 308effc95a2a98016d870d17e898d921 230164 libs optional 
serd_0.20.0~dfsg1.orig.tar.xz
 b8f012f8eb732d0a9f698bf2543fa9cf 6438 libs optional 
serd_0.20.0~dfsg1-1.debian.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJT7iJBAAoJEOikiuUxHXZaopYP/Ahpbp4Yb9ncALEuygefp7Kn
k2M84W+wcEoqzgY223GeeYKPJ8fbSJ1xT78rNpmjx3P2cGGOI2S0TQFNuFc4oYLA
N9zLDTFsKHCmYumOpkPu6Np0QeYWS99VUv/u4uKqxLl9kmKyCSnmMyJLRVVb0CBJ
RAkS/9hjT/VZIBLg807aeacpN3oxJX7bGR1AL+3NfYJaoTafAiNJ4408+EAeCbqR
jk66kfSDCt38+Nq2MFvORfg+1SZQbO2icic7ajPez0lQORQaVycAHT4+yj1zw9My
bBz0IZ1f7LpqeM+ylD7OFVojtRHq5Acm/S6kVCmeNmgWCLXR/eRdHXGnqV6vdl4Z
hOf569ES5Wz66KcwRkYxCR5yaF+FHeo0x+jrYXw6JYa1vyzcgtDXzk+MC+bx0icZ
fvuM4l0Z7dS2cb4yTm8jc4c3lpkv37TYpjw+W7FoWv8Rx8W9Los/q5ZyRgbLBLfK
BUf8iPpKm4MSxFMQ/p+tcSgwGZRG6tXqpL3fSnHbVVdMqX9/kbhc3wuzE41jckkK
Mx3DBOtZS9BVtADfYvGY4e2FnzlslsdnI8HABMyhyaLZ849kBYTk4zR8bt/4HZyu
Vl5mhvX7dJz8fK+hNzk80nvd0nFbAJgcWje+F8Ls29Mo44YBKe+XnUnzWtNTCfil
ynQJcOdchDljIycNtoS6
=ssJ+
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xik2y-0001m7...@franck.debian.org



Accepted sord 0.12.2~dfsg0-1 (source amd64 all) into unstable

2014-08-15 Thread Jaromír Mikeš
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 14 Aug 2014 09:03:47 +0200
Source: sord
Binary: libsord-0-0 libsord-dev sordi libsord-doc sord-dbg
Architecture: source amd64 all
Version: 0.12.2~dfsg0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
pkg-multimedia-maintain...@lists.alioth.debian.org
Changed-By: Jaromír Mikeš mira.mi...@seznam.cz
Description:
 libsord-0-0 - library for storing RDF data in memory
 libsord-dev - library for storing RDF data in memory (development files)
 libsord-doc - library for storing RDF data in memory (documentation)
 sord-dbg   - library for storing RDF data in memory (debugging symbols)
 sordi  - library for storing RDF data in memory - utilities
Changes:
 sord (0.12.2~dfsg0-1) unstable; urgency=medium
 .
   * New upstream release.
   * Added myself as uploader
   * Tuned get-orig-source.
   * Remove --debug from configure to cppflags be passed.
   * Bump Standards.
Checksums-Sha1:
 869b2fb407765f5e218c0b408b9578e6bc9ec271 2275 sord_0.12.2~dfsg0-1.dsc
 659f0b6b262dfbff59b1757bb0de06b41555b93a 196356 sord_0.12.2~dfsg0.orig.tar.xz
 6be2174f1bf2a1307d5d2aec10871ccabdb2ad83 5008 sord_0.12.2~dfsg0-1.debian.tar.gz
 f85bddb369caf7fd933a005cd0f1de9e17c0ebaf 17852 
libsord-0-0_0.12.2~dfsg0-1_amd64.deb
 16bba39f75e951df58a846dc15c98c8c6154b7d8 12252 
libsord-dev_0.12.2~dfsg0-1_amd64.deb
 4ce45cd8b1caca90af380eb95290c1ad1934dc16 14282 sordi_0.12.2~dfsg0-1_amd64.deb
 3e8557bdb13a91035c4c95911b9c2b218052b244 19040 
libsord-doc_0.12.2~dfsg0-1_all.deb
 83cd8ceb60245a5dc7251fefe7ac1239f0a704a0 37740 
sord-dbg_0.12.2~dfsg0-1_amd64.deb
Checksums-Sha256:
 0e8921a1ff8b907feb92569501c1ec95ce83074ccbcf1731caf5eed5610c9188 2275 
sord_0.12.2~dfsg0-1.dsc
 fc0c8e47014c3890a1a4268dd2682363da06864f38716b0520996e92693e1c35 196356 
sord_0.12.2~dfsg0.orig.tar.xz
 b719057e630a5736d3c194e6f49cf4efa235d32cfb2eff3d5186e46a15ecd62f 5008 
sord_0.12.2~dfsg0-1.debian.tar.gz
 398344f12f3176e891c551361790ddce853f24c7f3b7228715182b777b5c7398 17852 
libsord-0-0_0.12.2~dfsg0-1_amd64.deb
 5e02c873f9462b7132b8ee823e9fcbf3d7fcc27a5470b63c77ea574afe24b8b2 12252 
libsord-dev_0.12.2~dfsg0-1_amd64.deb
 19045762aa7e88eb6b7e6d48c6880821adda07eeaecc3b41fa07da1bbcaad98d 14282 
sordi_0.12.2~dfsg0-1_amd64.deb
 a6fed2db5a1d77c6e1d6e132a4d7e1fac76492c94e160344d7dff1fd37ed3ab4 19040 
libsord-doc_0.12.2~dfsg0-1_all.deb
 3152498acb0d8ff2c1dd74dff2e8a8797234953e1c134207f2083751df379efb 37740 
sord-dbg_0.12.2~dfsg0-1_amd64.deb
Files:
 e5af209af2490f3dd5f393a8d96980bf 17852 utils optional 
libsord-0-0_0.12.2~dfsg0-1_amd64.deb
 a39891c91281c354369a648a763c18d5 12252 libdevel optional 
libsord-dev_0.12.2~dfsg0-1_amd64.deb
 f2ede359f64c571ef4c8535ff4da8847 14282 text optional 
sordi_0.12.2~dfsg0-1_amd64.deb
 0c9255cea739cfd1b82fbde97851be0b 19040 doc optional 
libsord-doc_0.12.2~dfsg0-1_all.deb
 cc581f724bfd8198db8b87fbbcdb3c52 37740 debug extra 
sord-dbg_0.12.2~dfsg0-1_amd64.deb
 6654a98d3f9cbc68e2f949ccf02fe348 2275 libs optional sord_0.12.2~dfsg0-1.dsc
 4d78f81a69383355d686040c71c30bc4 196356 libs optional 
sord_0.12.2~dfsg0.orig.tar.xz
 0ae5eda3e9210c499e22f033f5cf3705 5008 libs optional 
sord_0.12.2~dfsg0-1.debian.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJT7iTiAAoJEOikiuUxHXZa1s4P/Ar0QuDopyXj+RTH5KBzd2AI
sI31vJRKb3LzWzIZqZApw2IWFfCOrWoeOJevfXQ4J3eksS6NCWhuJ9DL6bUwfszE
inC0eK5SLwy//f6UbkQ3alOZ5VUkkAZ9PS5bfJHCtGRuvKeIoLYcIgCtDZOo8WXM
SwQAomI8Utz0iQi01LhMwOu/nqF5Q56qBv5akV38CNH5ahDrbUUHz3SctcU1WIou
YcoLdzQu+/S5R/avoj0gQAV+oaycEw/eIpSs451Dg2nufHhqNgGbbrliGML2FdAX
jRdqOykhMSNejGQKHHmQEYFmcb2IvdB8/THAYSzDob5GEAAv+JPtP7ccn9W5gJ2E
RIszS2DRqtcxNqrwYWsR+g8hrpwgdgvC35KajUiCh6w2PYJ7wC6lKxrEshwu9rcj
09c5LooZDLqOUFFPCufqOk7ZVpbeX588CiypVZHHYSv/Iyvy/YSL1hHOjj8Au4bl
6sjf5M2vV3UGuY58YBCHSRmG/DobEJd7l7i/GTaBSrhe6JjbQb7cWZgZydwYh+8d
2H4yr2gwoXZ0xu8LFeUMf27C9DtXc7N+aA5DrYOTjdGSnmjSaYrcbZiNgiKYlejy
fdQ3MhWR27CcBr3m7hqSkAZySYonQ/ahuoZCr81sNkenj10oL6JTT9VcTJ//OU0N
sU6J51SyGV5b35OIpOha
=Wi0i
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xik39-0001ri...@franck.debian.org



Accepted axiom 20140801-2 (source all amd64) into unstable

2014-08-15 Thread Camm Maguire
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 14:07:54 +
Source: axiom
Binary: axiom axiom-source axiom-test axiom-doc axiom-databases axiom-tex 
axiom-graphics axiom-graphics-data axiom-hypertex axiom-hypertex-data
Architecture: source all amd64
Version: 20140801-2
Distribution: unstable
Urgency: medium
Maintainer: Camm Maguire c...@debian.org
Changed-By: Camm Maguire c...@debian.org
Description:
 axiom  - General purpose computer algebra system: main binary and modules
 axiom-databases - General purpose computer algebra system: generated text 
databases
 axiom-doc  - General purpose computer algebra system: documentation
 axiom-graphics - General purpose computer algebra system: graphics subsystem
 axiom-graphics-data - General purpose computer algebra system: graphics 
subsystem
 axiom-hypertex - General purpose computer algebra system: hypertex subsystem
 axiom-hypertex-data - General purpose computer algebra system: hypertex 
subsystem
 axiom-source - General purpose computer algebra system: source files
 axiom-test - General purpose computer algebra system: regression test inputs
 axiom-tex  - General purpose computer algebra system: style file for TeX
Changes:
 axiom (20140801-2) unstable; urgency=medium
 .
   * build-dep latest gcl
Checksums-Sha1:
 b9f694a4a5cb2d641b1e24674d0682eb069c4dba 1800 axiom_20140801-2.dsc
 2d9f20de55c66bd7ec55c595911f9c08407110e1 739708 axiom_20140801-2.debian.tar.xz
 8161a6d484013719432d499dc31e0d5d5b6c98e9 138456 axiom-source_20140801-2_all.deb
 5031820f34f385e2a0d0c938fef0869b2087ea7b 9762640 axiom-test_20140801-2_all.deb
 c064568e67feceb7f27d5718a6ce30e44390b0a7 81093058 axiom-doc_20140801-2_all.deb
 d3ae077e6af8f561d6eea7cf513c4dc334f8c05d 906550 
axiom-databases_20140801-2_all.deb
 77df7a3a6476a7983d76c8de50cb1585eb1e8481 158986 axiom-tex_20140801-2_all.deb
 bddee112674e3c3c01ea8e2c3bc6da494ad91031 1570478 
axiom-graphics-data_20140801-2_all.deb
 857337bc9314b190ad316cbdd439f1980d65ccd0 27277716 
axiom-hypertex-data_20140801-2_all.deb
 c74ea52e99816c210d3d434dcf584e97e63668b2 10014864 axiom_20140801-2_amd64.deb
 d3db3dd45adae83130c82efc6aed2d7937a00e4a 254102 
axiom-graphics_20140801-2_amd64.deb
 655e9a428b33aad1b53ff28e60091865d5f5e8c3 221612 
axiom-hypertex_20140801-2_amd64.deb
Checksums-Sha256:
 c2e088604ab837cd872295a1e168db9466a4b1e4e21d25c56afbe3e9d7361e08 1800 
axiom_20140801-2.dsc
 9f84b90289b0a8307fe5dfab9a64cebb0a4342fd16dc661bc669f6fbf2639c29 739708 
axiom_20140801-2.debian.tar.xz
 fb8a7982f86981acbdec10b850e5b610163f8dc48c75d2f0fca70cb59380fd6e 138456 
axiom-source_20140801-2_all.deb
 c2febcb7e27b01686735a300d4b4771ffa00d24513b44e3ac700703e7de05a07 9762640 
axiom-test_20140801-2_all.deb
 540555dcd5c4d76fdea6abd58cb17c13483775b091c1738c268fe37e9083a7d1 81093058 
axiom-doc_20140801-2_all.deb
 5b857a1d78539627ee8a039d8629c2976a18455033bbf24bc495e7af0261e5df 906550 
axiom-databases_20140801-2_all.deb
 408c55f6aa96396987042520a307cc7d7beafb2909ae5169368aa7b292264c5b 158986 
axiom-tex_20140801-2_all.deb
 d0b9ad74b08d961b8df327337d8df186f5ea777278545d47103245710bc59670 1570478 
axiom-graphics-data_20140801-2_all.deb
 94887642e6c4bf42793a29d2fdc821939094c21163e9658f824d0db079c886c8 27277716 
axiom-hypertex-data_20140801-2_all.deb
 1bf307d4feab1c88f5f19a3fc89f1c9342fa80589e3082600e9c525b42a231bb 10014864 
axiom_20140801-2_amd64.deb
 72b26ab3506b2897704e52b852c638cd6890c9323a4cc050e87ca2ee8bb6e394 254102 
axiom-graphics_20140801-2_amd64.deb
 b082e60226f2e5455e21a3fb1546852ed264b6dab3ad556b3869d4690d6a1a74 221612 
axiom-hypertex_20140801-2_amd64.deb
Files:
 c39d777d2ad3b79bab4adc1200f80ad1 138456 math optional 
axiom-source_20140801-2_all.deb
 f1f131b5b6e65063af805a5cb2fc03f8 9762640 math optional 
axiom-test_20140801-2_all.deb
 9b1f4c3454e70d6dbffd93ae3bad777f 81093058 doc optional 
axiom-doc_20140801-2_all.deb
 d6c08be747fd5720591773943b4e133d 906550 math optional 
axiom-databases_20140801-2_all.deb
 50ef27e6c5d89cb76b0698c9eb952c14 158986 math optional 
axiom-tex_20140801-2_all.deb
 7aac3ca918dd77043ff3a7b8650db6fd 1570478 math optional 
axiom-graphics-data_20140801-2_all.deb
 bda0ed381a32c102bf013df780c7b311 27277716 math optional 
axiom-hypertex-data_20140801-2_all.deb
 126fc1e3cc5b6b393fb67c37ba1a35f2 10014864 math optional 
axiom_20140801-2_amd64.deb
 6e1f2c82f307efc8de61ebbdd3d3ee84 254102 math optional 
axiom-graphics_20140801-2_amd64.deb
 8083482e9971bf0d1df823e18322f43c 221612 math optional 
axiom-hypertex_20140801-2_amd64.deb
 ce162d551569946dd486fefff43b1490 1800 math optional axiom_20140801-2.dsc
 faf75f452ffc6141a2fb1fb2771a9f75 739708 math optional 
axiom_20140801-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlPuMxsACgkQczG1wFfwRdylLACgmi/RCPKrwkKzP1hFMlNQQJQJ
j0IAn1vcekzNwhHuJ9u06YKfN3J1bVu6
=F5z9
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact 

Accepted graphite-web 0.9.12+debian-5 (source all) into unstable

2014-08-15 Thread Jonas Genannt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 18:34:55 +0200
Source: graphite-web
Binary: graphite-web
Architecture: source all
Version: 0.9.12+debian-5
Distribution: unstable
Urgency: low
Maintainer: Debian Graphite Group pkg-graphite-ma...@lists.alioth.debian.org
Changed-By: Jonas Genannt jonas.gena...@capi2name.de
Description:
 graphite-web - Enterprise Scalable Realtime Graphing
Closes: 755638
Changes:
 graphite-web (0.9.12+debian-5) unstable; urgency=low
 .
   * Team upload.
   * Graphite works now with Django 1.6 and 1.7 (Closes: #755638)
   * d/README.Debian: use service to restart apache
Checksums-Sha1:
 ab38824291b8773d3c3a1d3c2de0995d497625ce 2127 graphite-web_0.9.12+debian-5.dsc
 0bfa08eda738d097cb68e24429dad9300856a2e7 328696 
graphite-web_0.9.12+debian-5.debian.tar.xz
 9dd6e3be1283b6bc421cf30c149a694c4f24ca7c 1133278 
graphite-web_0.9.12+debian-5_all.deb
Checksums-Sha256:
 79c10dcb4a53850614241ed9cf8ebb3923c272783e3eb4875c9af575e892dc66 2127 
graphite-web_0.9.12+debian-5.dsc
 a6c0d9cb0db1a381d9cf3f64f4393fec306941f9fb604dc8218c7b0ab9bb081e 328696 
graphite-web_0.9.12+debian-5.debian.tar.xz
 83ae04c594ceba1b07af1786d5608a1d0f64ea927845edec4db9f8e300d589e3 1133278 
graphite-web_0.9.12+debian-5_all.deb
Files:
 c6887a938089b25c70b39725911cd8b7 1133278 web extra 
graphite-web_0.9.12+debian-5_all.deb
 745a9da3f254078292bcd0e900c16276 2127 web extra 
graphite-web_0.9.12+debian-5.dsc
 ca32f6f8385293c46e3f60d93d267724 328696 web extra 
graphite-web_0.9.12+debian-5.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJT7jhhAAoJEPBM7/YBbP/QIjQP/A0RWauLpjoF68/kQgByVWLu
C36EHMechJpJa+lJQhKr9Vlt08a9Iztlf6FR4jp5CNIH836Kh1jz0PUFPWL6W1xe
TTb4zFkNbUi1aaBmys5bkWzXtOiD58tBY+KSqBRHKgB50E0g/q7+Pk009X14P+L7
PKhUUlFiF32e1r7Jf32doTQV7vQad8wm8j1ZWILIRZRF5pIpDt3dSfNKDA33CkL1
AgvvYC+yGPKEbXRfD9V9rOTrLykUiafonq5laEtSXl/ea72tXru671eddAALO7Q7
VctqtQjJX2dY8uzr/HOmQmDGYfZrUf1F8vYAklCPVtxwrH46yAMjty5op4FAQuNg
FhOkmMij2ZXIFh1hd8NheBMfoL4hWVr/wtIXO9KT9Zy8xwv2FP6CCi8ahvJ+V8Nl
m+Ar0Y4nV8DbcFfxGtJSmzqNbNoGyb2fe2l7UPTALhyaWUanCSSEFxFpSlS9leVW
gK9xedU92/BcTt2liSV2ml38Xnu2X8dOqt8gYb/99eHa2wKoQiwOOacfXew17/mL
NF1VWqU2a5iqdKMNsLIi4RpV5dnqtS6aF6UOzlAPp28FVEpWwoWgnpRjuxJJnCNC
koYwZtq2HktE36oNYC9CliEzEz0bfiLgudo/mA0IXamzdLnziorcnRlvSxcAlvve
rJARONkIwBXjJqxYgdiJ
=Tp5v
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xikm2-0001pq...@franck.debian.org



Accepted lyskom-elisp-client 0.48+git.20140815.afa49c26-1 (source all) into unstable

2014-08-15 Thread Joel Rosdahl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 17:41:02 +0200
Source: lyskom-elisp-client
Binary: lyskom-elisp-client
Architecture: source all
Version: 0.48+git.20140815.afa49c26-1
Distribution: unstable
Urgency: medium
Maintainer: Joel Rosdahl j...@debian.org
Changed-By: Joel Rosdahl j...@debian.org
Description:
 lyskom-elisp-client - emacs client for LysKOM
Changes:
 lyskom-elisp-client (0.48+git.20140815.afa49c26-1) unstable; urgency=medium
 .
   * New upstream release 0.48+git.20140815.afa49c26
   * Remove obsolete patch
   * Get upstream version automatically
Checksums-Sha1:
 12587256146583f1ab9768e7b48a4e07ee766220 1252 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1.dsc
 9063eed40b55264629f91c399c97afca06e6d5b7 649101 
lyskom-elisp-client_0.48+git.20140815.afa49c26.orig.tar.gz
 2430eaa912ef75b366273e1d77d18ad0a1b2f4ee 10352 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1.debian.tar.xz
 0895525a1d993fda9d52f5d12df6fa7738212044 573452 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1_all.deb
Checksums-Sha256:
 10ef948bc26d106a18c7e4662fecb50b29b48a68efe161aea4dc158d132aae07 1252 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1.dsc
 629d267e51d0f7684eaff657d7e5eb9eb23734dad4686680cf8c34852cc6bf0b 649101 
lyskom-elisp-client_0.48+git.20140815.afa49c26.orig.tar.gz
 6a31eddf49a22758770b1c387f912aa03726dbe5998e15ea94fd6cf4e19d4920 10352 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1.debian.tar.xz
 d0a2a096da3d3c1ec42d1de951d2c4c182985b782111fefa187b1eb6a77a0df8 573452 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1_all.deb
Files:
 424d4f5b34c50f44c7922b17613994c5 573452 net optional 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1_all.deb
 199556f429ebfd3439948dd1d9f6f6fe 1252 net optional 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1.dsc
 c84919720044c917cf69943b3bede896 649101 net optional 
lyskom-elisp-client_0.48+git.20140815.afa49c26.orig.tar.gz
 d8fcb31b8e3182df69334d03d32495db 10352 net optional 
lyskom-elisp-client_0.48+git.20140815.afa49c26-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlPuKkAACgkQAGT5/7uEXpcwyQCgkMtPEyoqRHevtawXTtFTXI19
9PIAn1sMygR2wdr67/BXiPUwIb12t46R
=utBH
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xikpf-0002fn...@franck.debian.org



Accepted insighttoolkit4 4.6.0-2 (source amd64 all) into unstable

2014-08-15 Thread Steve M. Robbins
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 11 Aug 2014 21:55:42 -0500
Source: insighttoolkit4
Binary: libinsighttoolkit4.6 libinsighttoolkit4-dev libinsighttoolkit4-dbg 
insighttoolkit4-examples insighttoolkit4-python
Architecture: source amd64 all
Version: 4.6.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Steve M. Robbins s...@debian.org
Description:
 insighttoolkit4-examples - Image processing toolkit for registration and 
segmentation - exam
 insighttoolkit4-python - Image processing toolkit for registration and 
segmentation - Pyth
 libinsighttoolkit4-dbg - Debugging information for the Insight Toolkit
 libinsighttoolkit4-dev - Image processing toolkit for registration and 
segmentation - deve
 libinsighttoolkit4.6 - Image processing toolkit for registration and 
segmentation - runt
Closes: 757594
Changes:
 insighttoolkit4 (4.6.0-2) unstable; urgency=medium
 .
   * control.in: add libhdf5-dev dep to -dev package.  Closes: #757594.
   Migrate previous control fixes to control.in.
Checksums-Sha1:
 7e1ed7361a78e8b9238dc9c923c49351d670198d 1981 insighttoolkit4_4.6.0-2.dsc
 9f5b3bf5981dc66d82458128b10a52e2b9e18000 24568 
insighttoolkit4_4.6.0-2.debian.tar.xz
 4a492fc10e812d58d2fc635f679c8065418d9152 4640498 
libinsighttoolkit4.6_4.6.0-2_amd64.deb
 ebc58f7caf136d8d6f2e740e07b68823109855d1 3759588 
libinsighttoolkit4-dev_4.6.0-2_amd64.deb
 bf101c4ee213bc9ef3aaaca763d206a69718f311 36640278 
libinsighttoolkit4-dbg_4.6.0-2_amd64.deb
 803e89746029af78d3d6e53aeab47908b79bfead 2406426 
insighttoolkit4-examples_4.6.0-2_all.deb
 23d45bc2dd1c083b3ab630a60c08f5afbaa02f2c 63947708 
insighttoolkit4-python_4.6.0-2_amd64.deb
Checksums-Sha256:
 f8bdea5600100b8e8831edd7c65af6e2c0622ef66e3862dea79d765b61bd08b5 1981 
insighttoolkit4_4.6.0-2.dsc
 804bf47cd49ddc082096bebe7ea1ce6fd5c7bc448080bdd3a6c2dedcd9954176 24568 
insighttoolkit4_4.6.0-2.debian.tar.xz
 6efc152f7cd2f9eb3857d8c1bad25676466a0e5beede4a45acc41bf6b16668b1 4640498 
libinsighttoolkit4.6_4.6.0-2_amd64.deb
 5aae2e8b006069a77b80cd644cbbfad9f2687e88559ae8f07de2b09718e99834 3759588 
libinsighttoolkit4-dev_4.6.0-2_amd64.deb
 8d5edf3fdf2fbb12426bb31250437b1c567d2d4969830d8155677f2819145c93 36640278 
libinsighttoolkit4-dbg_4.6.0-2_amd64.deb
 04f8ae27d088e817456d4ada7f68893208fc315aaf60bfa6e03677749a3f74e1 2406426 
insighttoolkit4-examples_4.6.0-2_all.deb
 63ff47120993544efa9c6f5d06dc2c88487607c8fa5a055785e5c9acdf01e51e 63947708 
insighttoolkit4-python_4.6.0-2_amd64.deb
Files:
 bb65c53393f133f652536acc64091ca5 4640498 libs optional 
libinsighttoolkit4.6_4.6.0-2_amd64.deb
 5ec727a5a613619e880ea933b109cbaf 3759588 libdevel optional 
libinsighttoolkit4-dev_4.6.0-2_amd64.deb
 e407f50e7b540a87d299079bbc5d501d 36640278 debug extra 
libinsighttoolkit4-dbg_4.6.0-2_amd64.deb
 120f9194a20484c64b7026a9b5ca76df 2406426 devel optional 
insighttoolkit4-examples_4.6.0-2_all.deb
 a85b850c54967733db66e4c42fd38f9c 63947708 python optional 
insighttoolkit4-python_4.6.0-2_amd64.deb
 3b0de8c90b0d175c9d16b93b077e4a14 1981 science optional 
insighttoolkit4_4.6.0-2.dsc
 b235df296359e123d989582cba080c0b 24568 science optional 
insighttoolkit4_4.6.0-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iD8DBQFT7jct0i2bPSHbMcURAujDAKCRessPFufwYD23fQSnDT3X/V1ojACfbe4t
zVWvdbRUaCoWIKf/N6njq/U=
=7RaT
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xilfe-0006dk...@franck.debian.org



Accepted ikiwiki 3.20140815 (source all) into unstable

2014-08-15 Thread Joey Hess
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 12:58:08 -0400
Source: ikiwiki
Binary: ikiwiki
Architecture: source all
Version: 3.20140815
Distribution: unstable
Urgency: medium
Maintainer: Joey Hess jo...@debian.org
Changed-By: Joey Hess jo...@debian.org
Description:
 ikiwiki- a wiki compiler
Closes: 757679 757680
Changes:
 ikiwiki (3.20140815) unstable; urgency=medium
 .
   * Add google back to openid selector. Apparently this has gotten a stay
 of execution until April 2015. (It may continue to work until 2017.)
   * highlight: Add compatibility with highlight 3.18, while still supporting
 3.9+. Closes: #757679
 Thanks, David Bremner
   * highlight: Add support for multiple language definition directories
 Closes: #757680
 Thanks, David Bremner
Checksums-Sha1:
 33ae55c43ab18f3436aca829028ccf426e8a1241 1883 ikiwiki_3.20140815.dsc
 069b14c8cc22ef7db1a4f162763312c54379042d 3261039 ikiwiki_3.20140815.tar.gz
 77fd6a24354e235d8ecd67a6770adfcef5fe663e 1907538 ikiwiki_3.20140815_all.deb
Checksums-Sha256:
 087d004e0ac345be46120d42671ef4b86d51371fd11c5155d47810a10165638a 1883 
ikiwiki_3.20140815.dsc
 990fde69dbbc3ef5903cc9402a61c85389a1813c624635fb174c614ae3771651 3261039 
ikiwiki_3.20140815.tar.gz
 06f0ecbd90b160bcda29d65b2abfcbe85f9e18d9a7d2f8cbeb47420684bc3869 1907538 
ikiwiki_3.20140815_all.deb
Files:
 f52a7c0397dc7d4e393c508044eb6464 1907538 web optional 
ikiwiki_3.20140815_all.deb
 8f716aa3722c64d8e70179f332e23540 1883 web optional ikiwiki_3.20140815.dsc
 7290df17473c9e200c5296f793e74f85 3261039 web optional ikiwiki_3.20140815.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBU+5A0ckQ2SIlEuPHAQLJew//aQxBpriCsx4hBPmlVs43jLhnY0Yu5cbt
I2BLcILfSq5xkmi9VIZF/CCXRHaNwz/Z0VsL4Ib15y/bcyvTrkwfvB5B+73ZZF8w
+fsm3pnqrQn+HpxRk0r/C7B3XLQcHuRfVGnZXqc32GKcEbkec3MCTg/jSL6p+VJo
bjvA4NdhjQj7i2+7auH2USl3R7ZLxuEgNfgr6+4yhjY6dRfbbm8bEQFf4AAKW5oC
PkCIBbl9FPkRrCUucgu/o7DuPTNtC8NFzsC1UQO6+5O1Zfky8A20c0M9R3Qb86tN
Mtv3JPBtgHnkeWeHdflaUO0tre7izPXJZ7gOvs+RXpq2Lc05nnX0siH1tQtnOoCz
08d8qb5FRILlAzG87N3iewpyTBgLLme0oY1+nPLlzPhaMpw2/lyVBkdFEY5aPen+
xfaiksM0prAGPwCVVA7tT/iaDTsscT0A3Ww8HLyV8nLHAfxK52lqsuvKYZXV0sNi
BAB4x7GklDPrpb4LqsNvS9utYN90o250TAKDu0W7n6ug/qlLdromujkXIk6eodO3
lisCre3L0CayWDQF98kvlsrGx2bGZjp7PU3CunwDWnbo3tkSbI/tGxMTNb+In7tR
gJWaJcPQixfEhMwbVha7He+aYxMknyWY/8el/2fSWIBISOkfRVk54uQW23HOg0mz
iIEkIit4inA=
=VzRX
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xilde-0001mg...@franck.debian.org



Accepted liblist-allutils-perl 0.08-1 (source all) into unstable

2014-08-15 Thread gregor herrmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Aug 2014 19:41:08 +0200
Source: liblist-allutils-perl
Binary: liblist-allutils-perl
Architecture: source all
Version: 0.08-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: gregor herrmann gre...@debian.org
Description:
 liblist-allutils-perl - Perl wrapper for modules List::Util and List::MoreUtils
Closes: 746600
Changes:
 liblist-allutils-perl (0.08-1) unstable; urgency=low
 .
   * Team upload.
 .
   [ gregor herrmann ]
   * debian/control: update {versioned,alternative} (build) dependencies.
 .
   [ Salvatore Bonaccorso ]
   * Change Vcs-Git to canonical URI (git://anonscm.debian.org)
   * Change search.cpan.org based URIs to metacpan.org based URIs
 .
   [ Florian Schlichting ]
   * Import Upstream version 0.05
   * Update upstream copyright year and license (switch to Artistic 2.0)
   * Add dependency on List::Util 1.31 / Perl 5.19.3
   * Bump Standards-Version to 3.9.4 (no change)
 .
   [ gregor herrmann ]
   * New upstream release 0.07.
   * Add build dependency on libtest-warnings-perl.
   * Strip trailing slash from metacpan URLs.
 .
   * New upstream release 0.08.
 Closes: #746600.
   * Update years of upstream copyright.
   * Declare compliance with Debian Policy 3.9.5.
Checksums-Sha1:
 82fbd395ae2d74a5f25425f8aec124b1a1357fdf 2373 liblist-allutils-perl_0.08-1.dsc
 24dd3e1444d2a2539cd08ab9de0ae3e061b741e2 19283 
liblist-allutils-perl_0.08.orig.tar.gz
 3087e72b4a445d8e4c5e9121ef729f8993fd2607 5216 
liblist-allutils-perl_0.08-1.debian.tar.xz
 a448d4eb4f9823cbcded48233d6245b086db93d0 20024 
liblist-allutils-perl_0.08-1_all.deb
Checksums-Sha256:
 81797a28ba97f0069ffcdc186ea327e7c57d692856367dbf4d3aacdb269f11db 2373 
liblist-allutils-perl_0.08-1.dsc
 27ddc2f0d47656cd3e08846ffe19f765bbd6c1d0e3c751ce4bb704e2b0b7ad1f 19283 
liblist-allutils-perl_0.08.orig.tar.gz
 f03b9478eb09f5fe797d016c70c3ef30db4fdb461c5c0c79d170dca05f4af31e 5216 
liblist-allutils-perl_0.08-1.debian.tar.xz
 3fddeb636a441684b14f6db20bddbddb8755a8faa9901941cbbe42b70dd7dd84 20024 
liblist-allutils-perl_0.08-1_all.deb
Files:
 512e509b1e259ca04ab1c60305101fff 20024 perl optional 
liblist-allutils-perl_0.08-1_all.deb
 cfadc79c1e459e7d3a6143af572ce787 2373 perl optional 
liblist-allutils-perl_0.08-1.dsc
 0becef45aaf3556685ab798a132c014e 19283 perl optional 
liblist-allutils-perl_0.08.orig.tar.gz
 1ec437ca0286bb1d6b4412b1a6d46a77 5216 perl optional 
liblist-allutils-perl_0.08-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJT7kZYXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoG6GMP/3ekdhg4/J0ra+ySFW3CshqY
l/NOyei4PC04wXtM6HD2CVtE1ZVsRb7iQd7pw+STyz4hXklEzFVXIY0FWLSXaBoL
fPvWGKaELZXWEn4cMqcXsZi9RM7Vd7kemgqWLvr6+AISnyJI5eUjSWKH1o5f4m6A
QexNN7zlQSO2NCzU4DylC1BETPjSGpZ805nk0esJRP4P6216kSQoqliwwAf9acIX
peYgaGlzz2im7Up3ayytuWzHZKYxAKMk98Amn1bRwG3gvZgAPhOWiuRk6uICjnA0
l+506VpfP2SBaNdINqEni+uFee9HwK9epG+hQqlazyGttIgH4+fX3y9SazN+zDBZ
nj9B/ab1wHrcuohPJMOA7kT4szrIZAbeHzz+tcJ6eY6Kydsz4jCRyXwlOjJX6asm
xa1dJdagW8vpL8f8TefC09XAvhRpJ/elrwxOw6cUFhDxbCA0Ji3vIrMy2vOLgejp
14GQVoMxgQ7Xx6BgDsawisj+6bGqkbpKGSx3QPBWcqkmyvvLZRCdZtYXomP+x8dR
cQ+AzVhmgdGMiDAMZh9/rrYAl4rYfKcKXvr0Y2PTbNMttjx/xojhfFGVZ8UpdgFT
TrOdyFEQ+L7f5Xh/jDuE+0uYL4/9IFxq/j1mujRmX2CAnAZHkY7rhW6nsCuo+6eu
+p2qu+r7W2vnJ2+b6kvc
=pqqg
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xilfr-0002fn...@franck.debian.org



Accepted libmodule-load-conditional-perl 0.62-1 (source all) into unstable

2014-08-15 Thread gregor herrmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Aug 2014 19:26:06 +0200
Source: libmodule-load-conditional-perl
Binary: libmodule-load-conditional-perl
Architecture: source all
Version: 0.62-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: gregor herrmann gre...@debian.org
Description:
 libmodule-load-conditional-perl - module for looking up information about 
modules
Changes:
 libmodule-load-conditional-perl (0.62-1) unstable; urgency=medium
 .
   * New upstream releases 0.60, 0.62.
   * Update years of packaging copyright.
   * Update (build) dependencies.
   * debian/control: remove Nicholas Bamber from Uploaders on request of
 the MIA team.
   * Strip trailing slash from metacpan URLs.
   * Declare compliance with Debian Policy 3.9.5.
Checksums-Sha1:
 ef0681124d577d5ad59d2927f6c74a1c5802a89d 2574 
libmodule-load-conditional-perl_0.62-1.dsc
 3e208af28c32bcb9c9e6b47c3730ab3d8eb8f77d 13100 
libmodule-load-conditional-perl_0.62.orig.tar.gz
 352200a1cf1d86de13538dc08d261e52719249c3 3388 
libmodule-load-conditional-perl_0.62-1.debian.tar.xz
 9eaaa550be4475fabab66021bd2bf87347e4fabc 17408 
libmodule-load-conditional-perl_0.62-1_all.deb
Checksums-Sha256:
 2007c951ba6d767b8a74971c45d9cbb7d8dde4e75b5f2416ea01d5db468cc8bf 2574 
libmodule-load-conditional-perl_0.62-1.dsc
 6148e6189a635b7fe2b35a0992a1d128b679d2f05d2c5222eaef6c53c93b2cac 13100 
libmodule-load-conditional-perl_0.62.orig.tar.gz
 0bb9beb59b82527c1c29aafc599fd0b74eb893f52359c603ab8416b7188b7630 3388 
libmodule-load-conditional-perl_0.62-1.debian.tar.xz
 fad5679b17fedf8890ee52bf5bf3152a4c40d3fd667237c69f4fa8e0bd8241af 17408 
libmodule-load-conditional-perl_0.62-1_all.deb
Files:
 89f27a665b1edb7ae45769c4bc021d89 17408 perl optional 
libmodule-load-conditional-perl_0.62-1_all.deb
 f000a3c44dca79182ac0ce7347a479ba 2574 perl optional 
libmodule-load-conditional-perl_0.62-1.dsc
 93481bb58cb008b235825cb9bcee89da 13100 perl optional 
libmodule-load-conditional-perl_0.62.orig.tar.gz
 c00656851a3620a516adf5bbcf1d1611 3388 perl optional 
libmodule-load-conditional-perl_0.62-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJT7kLNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoG7JYP/1RWMebVEqUV09qnK0M+PCxr
NRpcLJaYMI3u4PDRbtyzvilzrLRpFApGnsahQsPLSEq0kYPQcFdfyLvUJbLz6JRV
HCoFV8EMGBuEUoK2mLvWemCUu+bVQDD4+nzRyaD4g4BKLGbkGSwKP95OZhldIEP9
NVCksriSKslEEs2CBPkzS6fMEcpS8DeMXbWbUD+mVt2PfV6dMShUp0ckNrCdlUhC
/ax58wmngwSgG1Ylysg1BqrttUPmoufCHfV6dFpHKjJawMOoIRqCaa8RvHPBHWTB
JrEYMnefZw9pPFQ0ZN/1H9+9J2pM1JXoF+ZnVsT5vRGwEniBBu0WNjSLrBoDjxQT
r7erb7lAvqJ97ITbuzd14p74nWaE2YHVWHgKu1EmVdUXlkxo3D96Wjp0zUkF/024
/vKxPoWfUmLClQYSlSleOO4uDF3LZtm/pP8FqPScXzRAO6p9aHx0RZ+3ZyJkkwBI
5Po99hGRug6XBi5gh4O2Hc8l0Z4t3Lzw+5qWpAXdIzwBMhZqq4Kdu5FR7/M0nN8G
6FgJw73OsmIEJs1tHx9xIfK/7SGXUfQTmBrm0znEGZkpsMDYjVrIY3PPkvbW9MEH
nyrlPgpnXHDUvs2KGOrj5UV/cr7HjRBLhE+EdtSow+7vXchUUDFuhsrNrW/5lMZ9
KKnSZh24qltpaiQnZCl9
=tbZx
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xilfz-0002pl...@franck.debian.org



Accepted libobject-insideout-perl 3.98-1 (source all) into unstable

2014-08-15 Thread gregor herrmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Aug 2014 19:17:26 +0200
Source: libobject-insideout-perl
Binary: libobject-insideout-perl
Architecture: source all
Version: 3.98-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: gregor herrmann gre...@debian.org
Description:
 libobject-insideout-perl - comprehensive inside-out object construction kit
Changes:
 libobject-insideout-perl (3.98-1) unstable; urgency=low
 .
   * New upstream release.
   * Bump versioned build dependency on perl/libscalar-list-utils-perl.
   * Strip trailing slash from metacpan URLs.
   * Update years of packaging copyright.
   * Declare compliance with Debian Policy 3.9.5.
Checksums-Sha1:
 7eb26234573ebb56e3c357cb12ebfa6cd7e56189 2545 
libobject-insideout-perl_3.98-1.dsc
 1bf1a2709f130c4d29a16c76db3118a609e6e439 127352 
libobject-insideout-perl_3.98.orig.tar.gz
 d913bc16a72658c2fad64aaa95605f95a627ea41 2572 
libobject-insideout-perl_3.98-1.debian.tar.xz
 8fa71995104570fb34211e1320d239740586bcda 129730 
libobject-insideout-perl_3.98-1_all.deb
Checksums-Sha256:
 16a92bb21e3810d7cff365e07b0c7ffe721774697205bb33e54c2eaa1afe4976 2545 
libobject-insideout-perl_3.98-1.dsc
 3fb8543b55c99d17145deeae8f65c7fdbe4a9432ed2dbb754b0bdd938ea8aeff 127352 
libobject-insideout-perl_3.98.orig.tar.gz
 888d33f8dcbe6f5c9ff26ed6f2bfa9c88b70462f7fd25d6e7428a11b20b2e2fe 2572 
libobject-insideout-perl_3.98-1.debian.tar.xz
 a9332b8d20aeead7978cd2546fc36fc9c9520bd282cc4e30d9b1619b9cdbadda 129730 
libobject-insideout-perl_3.98-1_all.deb
Files:
 3d0373bf8dd6605263c0fe3d15198281 129730 perl optional 
libobject-insideout-perl_3.98-1_all.deb
 b3cda7e4991dda8628d2be0790a48825 2545 perl optional 
libobject-insideout-perl_3.98-1.dsc
 d565588b54de0f9ec56e60c9cee80b8e 127352 perl optional 
libobject-insideout-perl_3.98.orig.tar.gz
 b7cb277cb2daafa900e3f243756ae121 2572 perl optional 
libobject-insideout-perl_3.98-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJT7kDbXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGihQQALx21nOtDE2wlvUyeXyznYYo
MWc2f2yTvxUlZ3jT1Iss24/uBAzopA8b0ABMW+t0TyUIKUgas5YHk0mLeDcZBKIJ
EEEmCL1r6OBDQcV15cNIPtvhybfk+vbqT7nIkqBnG/GFpUko0Ssc7v4tYAOMHWxj
XZ3hQtPndMK8r/o1X58O4G47ql3PmE7mRT/oubL3K+gI2FTvwDU/ol97yG/Kzth8
BZVeQ9OJAWqUThiHZJpjAQvujoBDAhOeAmG0uLcMmp+QBWTUEWxVvqsXSSePg4xe
/2/wZ09u2SAeLm8JlYxN9XZ+H2PhPquboPKqIndXEgA8kHe4aVKRmmLRfffXv1fM
+7M/cH4k7pRQI+EUmS6YM33iF3OYBnV2U/l4RS3KWSjgD/MrZLdWmz34zxovcfqZ
H6r9qDDuk/DHea2R8iJWJsZjrXnxLWI7cL+GOLZ8fPT01T3r94j4SVyD+YkVwKgy
UgCwAgUj5R4a0IEV+1iG+DaodaEh+qs++dBCNNhPTvqtEm366ddkoWO9QgasskD2
ayKKDktTVq9TbDWjWi69nYSngzflWohwKPVn+hkh96aN3Av6Gvi0GG2ep/j0uWYh
faEbtS2AYe3n+uodlR/a09NEPlY91nVi4FSlBUOtpJgZgYuqExsOoFTHchyuNd6n
l+p17ng6qxzPS9pmpQAW
=45S4
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xilg6-0002xb...@franck.debian.org



Accepted redeclipse-data 1.4-3 (source all) into unstable

2014-08-15 Thread Martin Erik Werner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 09 Aug 2014 18:32:07 +0200
Source: redeclipse-data
Binary: redeclipse-data
Architecture: source all
Version: 1.4-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
Changed-By: Martin Erik Werner martinerikwer...@gmail.com
Description:
 redeclipse-data - data for the Red Eclipse FPS game
Closes: 740565
Changes:
 redeclipse-data (1.4-3) unstable; urgency=medium
 .
   [ Markus Koschany ]
   * Update copyright file. Add missing public-domain licenses.
 Remove obsolete font license.
   * Move redeclipse-data to the main archive because it fully complies with the
 DFSG. (Closes: #740565)
Checksums-Sha1:
 b2e7d74cff23a7a0b6544243da91e282a4fcedcb 1991 redeclipse-data_1.4-3.dsc
 0250d9c3543686b82816d2172f7bedc306a5 18808 
redeclipse-data_1.4-3.debian.tar.xz
 21781f39f41e49f3a467ba12369061918aa97612 654891192 
redeclipse-data_1.4-3_all.deb
Checksums-Sha256:
 97cd45d6a401d3c491a4debb5076f617f9e158440d5bf3676669a1e820e0512e 1991 
redeclipse-data_1.4-3.dsc
 fabe7e05da2f553f5f06dc69cfd9b759e4a29ab20193b831f4b240176fd96a7f 18808 
redeclipse-data_1.4-3.debian.tar.xz
 706cee5425e366375b1ce0b5442a50beb6870f188b690185bb26661e15361591 654891192 
redeclipse-data_1.4-3_all.deb
Files:
 f62334094c1b1df638d68f97d64932a4 654891192 games optional 
redeclipse-data_1.4-3_all.deb
 db5d3ca2bbc88e5ac1c0150548e67d1e 1991 games optional redeclipse-data_1.4-3.dsc
 4224876b89e5b36da1b2f2f34d619692 18808 games optional 
redeclipse-data_1.4-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT5p4yAAoJEI7tzBuqHzL/ecgQAIDshNWr84m5K41mswh89SMP
aI45wJT5rQ2zfaiZqYPwbERtiHPouf9Jlx2SrxC8m00rlVRPomuOgB97DKvdDh23
C5mAKF0qjB5bwOwZfkPVrHAOSWpYVvtFb7o3RrycEF8Nyf75ldbWBQj8C+KsNdeo
7DhNzTovGkjmTptzdE6gvS2InZH9RkAzHaKY0N0yoQ7O+dWn7u8vRN+0MNLmwe3H
L5LkcfLcUSDoMiG9QiOm/O67olQu6WO3TzHPZ5qFgpcGp9f7AmxfC1zTDTE6UK/A
XH+OTio/SPhLiu8uCc36nodnEVeL2QRrc9sPkguETIRSYbbZy1CiFM6GKjHKyw5I
cmqE5anzFGOBpklWEFewDtnpenvT8gXqh9OvUKaVYlsPtMn5blz+YLyqu9Tc8z15
vJWMpKYbHwpAcvjsJ5P+Tqxfc79hmCwGomK03oUSdm62PWtj9bSswlqfbSKyWdAV
asBsHJCuhPDesi1+YgsRP/87MIp5emp9napijYd2UNFGJuZyNBB8hAsKBGVbXh74
jpjn+5WerdqY5wYurfPcQfYeLYw40Jl0L7wlrEI9e3AsSsPHG/ouGnS9lJtBbpUg
DnRk+38YCy6hGVomDnsRkZ3L6kdENdY5hlg8QUE4Vdgqxola0Vcn76jkSxTyrJx3
xFGmLsxmmLmlpUUjeziI
=uR8K
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xilko-00037h...@franck.debian.org



Accepted git-repair 1.20140815 (source amd64) into unstable

2014-08-15 Thread Joey Hess
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 15 Aug 2014 13:49:09 -0400
Source: git-repair
Binary: git-repair
Architecture: source amd64
Version: 1.20140815
Distribution: unstable
Urgency: medium
Maintainer: Joey Hess jo...@debian.org
Changed-By: Joey Hess jo...@debian.org
Description:
 git-repair - repair various forms of damage to git repositorie
Changes:
 git-repair (1.20140815) unstable; urgency=medium
 .
   * Removing bad objects could leave fsck finding no more unreachable objects,
 but some branches no longer accessible. Fix this, including support for
 fixing up repositories that were incompletely repaired before.
   * Merge from git-annex.
Checksums-Sha1:
 7c61f938a06460fb407c2d02122d3c5d9461caac 1785 git-repair_1.20140815.dsc
 4f7006db83d9271a97418c2d17db7ff20ec15425 76953 git-repair_1.20140815.tar.gz
 ee0e6c4ddb7789a440f00910e377c0c42618657a 665036 git-repair_1.20140815_amd64.deb
Checksums-Sha256:
 174817e67bfeee07fbc15d55dadd81f084c8662d77744e476c9318969b0583ed 1785 
git-repair_1.20140815.dsc
 913ac8b5009d6a8f65d965cdff254fbb80c66e699ffed3f4095f44f65b40b1ee 76953 
git-repair_1.20140815.tar.gz
 d5465f6a9e7dbb3857b9d2a16334993f9f550f8fa4a18c2cb0ca58ee5260fb8d 665036 
git-repair_1.20140815_amd64.deb
Files:
 e7f90bb2a540fe840eef36d93417cd07 665036 utils optional 
git-repair_1.20140815_amd64.deb
 7940642ad0b21d7892564301ba6fff44 1785 utils optional git-repair_1.20140815.dsc
 a81a22dac0dacbcf2b82cef7c53645a8 76953 utils optional 
git-repair_1.20140815.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBU+5JX8kQ2SIlEuPHAQIthg//b2mTdKzTEBnLfQrMbkczjABughCV5Th2
jML0hTYPf/OPg3Nmrx8gxE61C6J9/QNy94BxyULu8QfyHPz35z/VYlnBCdxHSYZR
KOcvvEEJW0iix+RPAW+satSfVQWz/HCXhv+6y+C3pP5Mlfzx1oAKLOnkAzGqB4vs
CbYjPtI5zNC9XGaDv7Oe09DjLi7UAc38nvH8NpmjeCgT5Mhpb8dUl/h7fQT3PoG7
rWNIxlj9J4+X4aIwq6v7OHYXUs2w4U2D8Sb+7dxg9DYqdAFaHdnIVhNzcvaePq/w
WraBuBOMC1JGn/olmOlPqYH6/+ura5bZ1th5nibgmbsgJsQJ5dN8xDGpwrHBOsWS
41MbhoK0aL+leANvYHzHbxQBGwFB+VtpJkP4iTsW+ccxSCKptPRUACV5yM2lNE1t
1xPeETvvT3UMXZfy6jlht63HS2Yancn1IkXKfdJ5vFEBbkv9bucjwOVcPmRnXQTU
Tp484164r8MfFpKi/kUwrvEHY2cjFlClsZrpveo1au/kFk63L9/SMbkrX8mxq0fV
OK3XDVXP+92tTdh11R1n3lRbfZgTNgrGuv9GG9V+HSF0XojOt04mebJwvYKVQVTA
QNvAAWPI171qkNQCOxoeaapv9qhi5kqsVA94Pgi7Y92Dx1GeGF4CUbNCvOCHzSlL
xLLZc43nZF8=
=M2ga
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ximmb-000719...@franck.debian.org



Accepted clamtk 5.07-1 (source all) into unstable, unstable

2014-08-15 Thread Scott Kitterman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 14 Aug 2014 11:59:26 -0400
Source: clamtk
Binary: clamtk clamtk-nautilus
Architecture: source all
Version: 5.07-1
Distribution: unstable
Urgency: medium
Maintainer: ClamAV Team pkg-clamav-de...@lists.alioth.debian.org
Changed-By: Scott Kitterman sc...@kitterman.com
Description:
 clamtk - graphical front-end for ClamAV
 clamtk-nautilus - Nautilus MenuProvider extension for clamtk
Changes:
 clamtk (5.07-1) unstable; urgency=medium
 .
   * New upstream version
 - Drop depends on zenity, no longer used
 - Add depends on cron, libtext-csv-perl, libjson-perl,
   liblwp-protocol-https-perl, and gnome-icon-theme
 - Bump minimum libgtk2-perl version to 1.241
 - Drip depends on libdate-calc-perl, no longer used
   * Add new clamtk-nautilus binary for nautilus plugin
 - Depends nautilus-python and python, separate package allows clamtk GUI
   to be used without nautilus installed
   * Update Homepage: and debian/watch
   * Remove unneeded debian/dirs
   * Rename existing install, docs, manpages, menu files for multi-binary
 package
   * add clamtk-nautilus.install
   * Update debian/copyright
   * Agreed maintainer change to pkg-clamav
 - Move David Paleino to uploaders
 - Add myself, Sebastian Andrzej Siewior, and Andreas Cadhalpun as
   uploaders
   * Add Vcs-* for pkg-clamav
Checksums-Sha1:
 4a5cf8063a84cb55935272c983ef156d52af8f54 2130 clamtk_5.07-1.dsc
 ccfd95909ea61fbfc1b814dd6624329140661d82 893296 clamtk_5.07.orig.tar.gz
 d00be613c43cdac76a3cdf4db87c2023e36b4536 9996 clamtk_5.07-1.debian.tar.xz
 c3cd4e68c44188605e7e310be20ea49cf1d410ff 188304 clamtk_5.07-1_all.deb
 d7e4134d97268cd794eb985921686643c0731660 30772 clamtk-nautilus_5.07-1_all.deb
Checksums-Sha256:
 324f0e5766ecc114fe29d3e60581fe771ec0d4d53be00dcf36a5a3c6f52c564e 2130 
clamtk_5.07-1.dsc
 983a0862eed5af31f6e9f230d5081abc2a744ed8c5ac622f310d1c07dac4f9cb 893296 
clamtk_5.07.orig.tar.gz
 2b3809353373d28a0203a7046335853affb7240791556e24e85851505badd9da 9996 
clamtk_5.07-1.debian.tar.xz
 71ba2065d3abaa351862f94a97e32b4c5c95441242fe2016a43636ccf2968ae2 188304 
clamtk_5.07-1_all.deb
 873fd462135d74c7f3be7cf0750299906923cec9326d32cb6ba2bb4d05fda134 30772 
clamtk-nautilus_5.07-1_all.deb
Files:
 6979252f4a5a6f2cd5fde54434bf521c 188304 utils optional clamtk_5.07-1_all.deb
 6fdc01825fec4d427473fb13e9bb7420 30772 utils optional 
clamtk-nautilus_5.07-1_all.deb
 8087ceb3f7514696424713f566ef570b 2130 utils optional clamtk_5.07-1.dsc
 668333cf12d28f37da0971c964e8fcd3 893296 utils optional clamtk_5.07.orig.tar.gz
 129d0d87509346f6c7524b79eff75259 9996 utils optional 
clamtk_5.07-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7PTnAAoJEHjX3vua1Zrx/LMP/2yjXb6mzfwoQGX7eaA6ZInR
xnccClYV9LA0hGxB/4hDI3xHHXteLpvHGORhf9pvQ7R6Me4cajhp3zcBPKIhTW9i
CwjNLDB6obSulIbS7kMPIgFLADCKeiaE9bAS137uq7Hd6BG785DlfU1J3l0NOw0g
oxNZldJWpkcZI9DDoXL3EtSX45KyziOfTTLdO4yhxw2PDI8lLeJsiML6BSY38X+A
1CaFfmdViKUrX1B4qoxRPwHrd5P/v0mj2VGp+Pq+AB5zoeOaXtOertnyF9PFObuO
oaIyDF6FHUvVb21uiavl2J1VqY813pnkMBtoX9NYqb+rfa2dx6/0B6DknjGGTJZr
wUrP89Ea30Ot+PHByoeYq4p2FCcKPyL+kReRyoZbQzknVT7LV3BL4yituPGCc9Uw
tt420HIPe4+EzOTx8PGUhOtulJZawrz9FqxaxeGKvVwyHUcCLGUQoN212dXYH8Yq
HsY/f2Kq8ur0hVJnhM/C4wYk3Is4GYTEE0+C38DWmWfFenvawV01VmJdgkAITnwQ
YXLkmpLFJS68PACidtcazU1qZ7c8ByJmJAa59oDoXDFoQvyWl6Mv/bsSI03obNm9
Zwn9YYqgh/Id6fZevPuFxMBxxDT3A9FAVFmRugpHpwR0FR5w1GmYmSrMIbbpGXHB
L5NmFAHbJk1aNbHDI9Bq
=qkSu
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ximjo-00026n...@franck.debian.org



Accepted dbusada 0.3-1 (source amd64) into unstable, unstable

2014-08-15 Thread Reto Buerki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 14 Aug 2014 16:38:12 +0200
Source: dbusada
Binary: libdbusada0.3 libdbusada1-dev libdbusada-dbg
Architecture: source amd64
Version: 0.3-1
Distribution: unstable
Urgency: medium
Maintainer: Reto Buerki r...@codelabs.ch
Changed-By: Reto Buerki r...@codelabs.ch
Description:
 libdbusada-dbg - Ada bindings to the D-Bus message bus system
 libdbusada0.3 - Ada bindings to the D-Bus message bus system
 libdbusada1-dev - Ada bindings to the D-Bus message bus system
Closes: 755076
Changes:
 dbusada (0.3-1) unstable; urgency=medium
 .
   * Update gbp.conf settings
   * Set debian/compat level to 9
   * Update to release 0.3
   * Drop obsolete 'dynamic/static libs in separate dirs' patch
   * Update copyright information
   * Remove obsolete DM-Upload-Allowed from debian/control
   * Update to Standards-Version 3.9.5
   * Specify debian branch in Vcs-Git field
   * Update binary package names
   * Enable dpkg-buildflags hardening options
   * Transition to gnat-4.9 compiler (Closes: #755076)
   * Update ahven Build-Depends to libahven4-dev
   * Adjust paths in debian/*.install files
   * Remove obsolete rm calls from override_dh_auto_install
   * Decouple the aliversion from the soversion
   * Remove soversion from libdbusada-dbg package
Checksums-Sha1:
 3c971fa7a3a42b1b03be0a866acad1dee6d6020f 2001 dbusada_0.3-1.dsc
 26416f80bdc71b559d7180088e024a8e08cdb7ac 42542 dbusada_0.3.orig.tar.bz2
 af60c2e7e0b98d2fd05bbfacacebd3aefca90c33 3064 dbusada_0.3-1.debian.tar.xz
 f0d1e4e5087bc9a221ff20c45602d95c7f44dc92 96646 libdbusada0.3_0.3-1_amd64.deb
 5ad2877895664140c4f940da7b63d1817a5f59b7 148716 libdbusada1-dev_0.3-1_amd64.deb
 00b79a4e103f4b097cde26856ec7a674afaa778c 162452 libdbusada-dbg_0.3-1_amd64.deb
Checksums-Sha256:
 e97cf19c7369db1e417b74f76d2845d7ddccf4179eb967ea4666ffc9f90748a9 2001 
dbusada_0.3-1.dsc
 0369fa41543845f2d3cb336b9565b2d6125a98cf0558133ebc75d15f4e21b82a 42542 
dbusada_0.3.orig.tar.bz2
 8fdf719a8423c9486ef5cbd1c274c47ac28ebd7b9ba727da7f06dcc52a4360a3 3064 
dbusada_0.3-1.debian.tar.xz
 cb6545a06eef99ea817e84074fb400737d99529cd24b67340ff40f7802889a47 96646 
libdbusada0.3_0.3-1_amd64.deb
 42bcb8ff3be10dae287e7132e3e2fe579d4b13f7836a733f2863e963b0cca41d 148716 
libdbusada1-dev_0.3-1_amd64.deb
 0f7e8bc915c764a666015a645bef64ad2391936e2add9c2dee6e4bed305d9a2d 162452 
libdbusada-dbg_0.3-1_amd64.deb
Files:
 5eaf994a61ee8314c9f347e29512b15f 96646 libs optional 
libdbusada0.3_0.3-1_amd64.deb
 b28f76d019f0a83aad8b33c88140b356 148716 libdevel optional 
libdbusada1-dev_0.3-1_amd64.deb
 38b836b305cde31cd6ce107a390a644c 162452 debug extra 
libdbusada-dbg_0.3-1_amd64.deb
 98ba486501958d4d4a929c7f685c70fd 2001 libs optional dbusada_0.3-1.dsc
 deb575881f1807a5b799b9ee2dbc481c 42542 libs optional dbusada_0.3.orig.tar.bz2
 9e5d13b5f8f5cb25b8c5173ca5cc5cd9 3064 libs optional dbusada_0.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJT7Z/hAAoJENPhc4PPp/8GMmsP/0U3dtxucrGXGHL44iqD8gQz
NH9laVuq4IMQcQkzJPnxYb+ZLUkO1ksqirCe5LVG3zuSmdF1MocWNhCOr7opHs/M
W8SrjLdQbrQ6IaRltTNkh1Sl4vqtDctidNTUeeL/1DcvXlFZhyhKOUlvHTmhX+gT
Q7vU0L5AHdlgH3pbS3bvRiyxrrrzw/UFmw2/1dbDjDrIP5LfoOSMdMKtLGzV7/4a
WE/nAdUsNerewBcJTMlYbU5SMbSzs3sRAyGuT1isVBOYi9PpQU9k5lzgKYZZZjPL
s9umMQEaZylELy5Gb3i1NS6SQrDm1vn/uLuInRr20VYuCFOd7H+n25cjnV+YeDUZ
YYk9M6kf8X3gf6xZKnc3NiCKt/SNOjsU8flCXaC79nLYVysCfijtef/v8wxHzvNK
xXDWrCsSraaq98PMvEjPTI3/p+mq9lqGYm1GP7bezkVS9uQxwXNmguwIcORrGMZj
6z5u4mTwFQTaB4wR6a1DlTMPiFQBf/b2G8MR2upVOKbqyuucl6wlFcK5QO6yWpaC
B3d3hqt6KeSrgCr2z3i+zxTnNld8RRHBRsUHCZ3mmi75qqNx2e86hBsANVn53CQJ
IfT0OCsHZGcCB/DEXPQvfa5uDihdh+QRFt7/bujMvmgxFevSmXf0SbTVrNN2R4mC
FhS5Agw44HFUJsg9dTPk
=kJfK
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ximjo-00026c...@franck.debian.org



Accepted openal-soft 1:1.15.1-4 (source i386 all) into unstable, unstable

2014-08-15 Thread Bret Curtis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 4 Aug 2014 08:38:25 +0100
Source: openal-soft
Binary: libopenal-dev libopenal1 libopenal1-dbg openal-info makehrtf 
libopenal-data
Architecture: source i386 all
Version: 1:1.15.1-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
Changed-By: Bret Curtis psi...@gmail.com
Description:
 libopenal-data - Software implementation of the OpenAL audio API (data files)
 libopenal-dev - Software implementation of the OpenAL audio API (development 
file
 libopenal1 - Software implementation of the OpenAL audio API (shared library)
 libopenal1-dbg - Software implementation of the OpenAL audio API (debug 
library)
 makehrtf   - HRTF Processing and Composition Utility
 openal-info - Informational utility for the OpenAL audio API
Closes: 659364 755862 756891
Changes:
 openal-soft (1:1.15.1-4) unstable; urgency=medium
 .
   * Added etcconf.patch to bring back the default conf file,
 closes: 755862, 756891
   * Added debug packages. (Closes: 659364)
   * Made the additional binaries into separate packages.
Checksums-Sha1:
 1d2daa79dd99a6070a03da989e7bcc0ffc6218c7 2411 openal-soft_1.15.1-4.dsc
 62ed6023673da0e0fc8ee12d48462ce3d4f66843 10788 
openal-soft_1.15.1-4.debian.tar.xz
 7b538e83a3de9c7f306c95adce3cd5425e19b406 23552 libopenal-dev_1.15.1-4_i386.deb
 77abf56e01f0b52402719a37ddf7990dc0e45dc5 169908 libopenal1_1.15.1-4_i386.deb
 bf160dedcb508412a4a21ccf0cc033fe1bfeaed8 301540 
libopenal1-dbg_1.15.1-4_i386.deb
 8e9e5ce6b4761b8d2ee83c96ef177a59962f7584 11882 openal-info_1.15.1-4_i386.deb
 6e934741720b7728c435351dc89c62f3629ffebb 24678 makehrtf_1.15.1-4_i386.deb
 ca551515be4843c13c2ce049f450a9e5fd3fd058 11478 libopenal-data_1.15.1-4_all.deb
Checksums-Sha256:
 51eb04b2c2eb500d9dec58149edede06e9abc5a0b21593c208d7ada13672a7f1 2411 
openal-soft_1.15.1-4.dsc
 91d796af3486421602092c73e295629389f1d19ff0a3e5bb0859080caa1155cd 10788 
openal-soft_1.15.1-4.debian.tar.xz
 eb48f3fada9cf7e108bbd2fd06ce2bd405591575153d2a2a2189d73eacc48264 23552 
libopenal-dev_1.15.1-4_i386.deb
 78a845aa80c05ced336acdfb9cf21ce06d1d52a67707c8452c5b37a3e3676c78 169908 
libopenal1_1.15.1-4_i386.deb
 9b537083ad8dcdd95cd7d494dce3b09172f459a3e7113212b384e82de17eaaa2 301540 
libopenal1-dbg_1.15.1-4_i386.deb
 82535c124971c9b439a0fe07500b06323e575f3fcf1845dfb0ca89d60a55438a 11882 
openal-info_1.15.1-4_i386.deb
 1b0b5d760a43142ecadb7b28aeb87f48d83264445f62fc7b68338d5fc82df49a 24678 
makehrtf_1.15.1-4_i386.deb
 0d0c392799022d582fac7bbdb83c7d7c1d68a36177a684ba8eeb0992587566e9 11478 
libopenal-data_1.15.1-4_all.deb
Files:
 51da38704d69cc6432a0e855f6b05300 23552 libdevel optional 
libopenal-dev_1.15.1-4_i386.deb
 3ef12dbe5eeb0e0b957653776da01b85 169908 libs optional 
libopenal1_1.15.1-4_i386.deb
 b9f11c622c60120213e64ab0b9694fed 301540 debug extra 
libopenal1-dbg_1.15.1-4_i386.deb
 241994fe27e04b1edade59c530a33c2f 11882 sound optional 
openal-info_1.15.1-4_i386.deb
 66d94df8874679bba8b67165b3ce6153 24678 sound optional 
makehrtf_1.15.1-4_i386.deb
 8f8ac128b45a084f968e229b1f17ce4c 11478 libs optional 
libopenal-data_1.15.1-4_all.deb
 16443f8e5570009d57655f886c6a3ccb 2411 libs optional openal-soft_1.15.1-4.dsc
 57f505e31704c3998ea529183e81d807 10788 libs optional 
openal-soft_1.15.1-4.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJT6qlnAAoJEI7QYGkDfiTyRcUP/0X2nOPON24SBKpB1jSwgK3p
APYI3GHtpPTAvFbX0w8vZtdek6OWRkDAVeAdVTpTHPDHKoV/nERt4ddPutsR+vvN
OkbBpklZgKT+wi594vGV/3nlppDOoZ349BXtd0AQTu7IPiQOtek14i/yPtk+hxAn
yHHnt9KktHvxitMDePFrJ78dSaF+s6bekfzlQwUWmEgpmCrcTc2wg3nnSF2QIv0y
AyfFdj6HIu1SDe5emi7DKjJERfFFw054oY3CuyUyLvIJlAVswzc9zzaeos6FR8sc
RhlU4qi8jZLwH733zlJ5adc5aEWUAqWmMbxfX+5HShbQWc6gCA9LjEelUAjQqKvx
3vk/f3EvkkIeUPSCsP3KzIOfOakELKP9aJWSFPda4MbBgAWJGRihvYdPBvmWMEqI
9Bgj/i5SsvLfMmuVoYaNROK61OMql2W2HC9SsyfSJHwSvqCg4JjKjcvDi6lcCOk1
jUfto5E4bFfJJ1fAxGSPRDLcyt5cVHyf0JecWIrSJBX6hDH0oUF9KL09xBShMeBH
Knc151M763LyDNQls/U1p4WMsCZrZEwC2934f6jwGombwz04YgFesM+he9VnD/BV
xjjaHhg6faOGwuxWWQWGWbP8xSLY7qbU3NRgxv61xxporKuIj52bYt6Za2IiMiVe
jDeG+6SUTIQNFju5AnS5
=8WFn
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ximjp-00026v...@franck.debian.org



Accepted redeclipse 1.4-6 (source amd64) into unstable, unstable

2014-08-15 Thread Martin Erik Werner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 09 Aug 2014 18:32:43 +0200
Source: redeclipse
Binary: redeclipse redeclipse-dbg redeclipse-server redeclipse-server-dbg
Architecture: source amd64
Version: 1.4-6
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team pkg-games-de...@lists.alioth.debian.org
Changed-By: Martin Erik Werner martinerikwer...@gmail.com
Description:
 redeclipse - multiplayer FPS game based on Cube2
 redeclipse-dbg - debug symbols for the Red Eclipse FPS game
 redeclipse-server - server for the Red Eclipse FPS game
 redeclipse-server-dbg - debug symbols for the Red Eclipse dedicated server
Changes:
 redeclipse (1.4-6) unstable; urgency=medium
 .
   [ Markus Koschany ]
   * Move Red Eclipse to the main archive since it fully complies with the DFSG.
Checksums-Sha1:
 72a3633dfabb765a58a677c88b064b8525773271 2250 redeclipse_1.4-6.dsc
 f993423ece60779a06535ef765623b21adfd113b 16284 redeclipse_1.4-6.debian.tar.xz
 12dca52d9496d7dd65c2d9faaf617915dd386485 1513216 redeclipse_1.4-6_amd64.deb
 f07c9a56fcee8f7958cd6501a4c7f10f9f8f3e56 5296130 redeclipse-dbg_1.4-6_amd64.deb
 a71e93fb8eb5f925d281871aa491a8e24ca6e309 316206 
redeclipse-server_1.4-6_amd64.deb
 232c8aedf3bbfb58d24e0b8865cb414c68e713d4 810928 
redeclipse-server-dbg_1.4-6_amd64.deb
Checksums-Sha256:
 4c5707bcb45951092c673e25aeaf99a6ea7dafb93353ef83497bd3084815b38e 2250 
redeclipse_1.4-6.dsc
 2403d2c857ca5c4311822cc73407ff71951e1edac3ae9faa4b920f8abea531ec 16284 
redeclipse_1.4-6.debian.tar.xz
 c2b1070cdf8cfbc17bfd56f90e3d8acd58cc8f5d550a22d49e663f213c1e524e 1513216 
redeclipse_1.4-6_amd64.deb
 8982909984b4352103cd6c7d6a213962bc24edc09468c489a5068b14ec4b754a 5296130 
redeclipse-dbg_1.4-6_amd64.deb
 25f6db60fccac48108f83e60a15c3395b51e04174d1fa92970f5667d806ee317 316206 
redeclipse-server_1.4-6_amd64.deb
 2dfd6aef1114bc08799cfabfaa049d0d907fb7d13198de84b17bf2892dafc331 810928 
redeclipse-server-dbg_1.4-6_amd64.deb
Files:
 46544978552f4c466cf489622e920aa2 1513216 games optional 
redeclipse_1.4-6_amd64.deb
 f61b29516e8bc6bd6ae2fe97d682c2a6 5296130 debug extra 
redeclipse-dbg_1.4-6_amd64.deb
 c56f99a247fd1bf4a72f218d80ba88d9 316206 games optional 
redeclipse-server_1.4-6_amd64.deb
 0803ece6385e514d796b6f9646b3b168 810928 debug extra 
redeclipse-server-dbg_1.4-6_amd64.deb
 53d93577a448a09e6e2b9eaf44c9355b 2250 games optional redeclipse_1.4-6.dsc
 1c68a683ba7553d95d07cca037570017 16284 games optional 
redeclipse_1.4-6.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT5yVCAAoJEI7tzBuqHzL/y2gP/iPIf692cVW+AjM7y23XkQ82
1nqP0cLJ3qwECUj2JWHpgVhKGUjuDGzOxSJ9j/4UmaYgiQQBLx/SMSrBbbGnHgk+
iDEI969nzxX+6Jyx7l+U7M4K+XBTX8tWNynz45YwuNm5S9PiLzqAgqT8V+/nYZOG
SKjFhNwDoYKZ4QJyydUwOoEQ0BmZMn8dCThz1IdHx5v3z6FtM5+U0kBqQ/VIWhVA
qs7rOaNM/9H4OWPruxNpRjx0KWmG6Vq1JWTonzDsHAV8MeSE8YhrmGaiTOjulFlk
KTrCKPzu4DeKe4LBed/48v/fZ/tehfF0jLmSEWoGSgFk9noX8r9ehl+y9rJf5Kdo
v7rY5O4IwQVXb44DRV5G/NkGkyKB68ZiVrpe8JYXcuDnKb6cRvAod7Fq2oIL5exn
pFRgDlxzwLOeeznevCyLE0pwFWOwVfimmwDypIp9PrscOpU03+gFRflRE9CmQxU+
jMEyMYE0tr2MTFhW/S9slxEqlNz9YrUMgWrMUFPsyYyi3gGhU/zb3ni/VlBuXtig
hjaLpEcaQH3hJ8krkHe6xOZ7mW4PzP+uqVERdjSNJ5IPZog0T5BejtUe/offGnc2
M2ms8CNHX5hdognzBNiVjnW7ESzx7Mte63deXZxivWnvR6USeEEPsjDYt1C0FkGv
4bUkJgF9njMMpvHnHX2l
=5Lbk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ximjs-00028f...@franck.debian.org



Accepted r-cran-maptools 1:0.8-30-1 (source amd64) into unstable, unstable

2014-08-15 Thread Andreas Tille
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 23 Jun 2014 14:22:43 +0200
Source: r-cran-maptools
Binary: r-cran-maptools
Architecture: source amd64
Version: 1:0.8-30-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team 
debian-science-maintain...@lists.alioth.debian.org
Changed-By: Andreas Tille ti...@debian.org
Description:
 r-cran-maptools - GNU R Tools for reading and handling spatial objects
Changes:
 r-cran-maptools (1:0.8-30-1) unstable; urgency=medium
 .
   * New upstream version
   * debian/copyright: exclude files with unclear license
   * Upload to Debian main since no non-free parts are remaining
   * debian/README.source: document binary data files
   * debian/README.Debian: Hint about removed data files
Checksums-Sha1:
 db835eeb589f79c591c799c3b02f3be169ac949e 2086 r-cran-maptools_0.8-30-1.dsc
 9c0b1064150f5fa8b7f96a0da1325f26d87ffcbd 976188 
r-cran-maptools_0.8-30.orig.tar.xz
 9eb74d0766b8bf33d215c6afde202d978eff3ded 6468 
r-cran-maptools_0.8-30-1.debian.tar.xz
 f04b299f1711f9161a331fbed9e3ed549afd06aa 1218690 
r-cran-maptools_0.8-30-1_amd64.deb
Checksums-Sha256:
 caad35cda2efb3e3bdc6e8f3af41c4a06f747f0ee0b1177da81c0dae4f398ef1 2086 
r-cran-maptools_0.8-30-1.dsc
 fb6513c8b4b2462938833963accad3d5356d5578543cbb3d1a3bea631e03f2b2 976188 
r-cran-maptools_0.8-30.orig.tar.xz
 9231d92729613246db2fd9b3f235a0b09270bea5532c9435e90fa60e214bcd71 6468 
r-cran-maptools_0.8-30-1.debian.tar.xz
 9537f6933720f8c0d2ca8440921a2dfc215237aa6a95d12a6563aeac44ddea4a 1218690 
r-cran-maptools_0.8-30-1_amd64.deb
Files:
 95f2bf3f818725a909a96604f199c78b 1218690 gnu-r optional 
r-cran-maptools_0.8-30-1_amd64.deb
 0a8f1c769f3a4e0599d1c5d0ccc0d02e 2086 gnu-r optional 
r-cran-maptools_0.8-30-1.dsc
 92fe0ac2f8796b8731124cc673e3b3e9 976188 gnu-r optional 
r-cran-maptools_0.8-30.orig.tar.xz
 660a6e10cd9031356a40baf603ac084e 6468 gnu-r optional 
r-cran-maptools_0.8-30-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJTqZhsAAoJEFeKBJTRxkbR2YEP/jwM7mfeGPn3u5bHnqoM4urr
szJ70G2y6xRLN0wGn0CO5P6Zip8S/8fJ2EKww4M4vzm6YvALF+lqnoyc+uWoVQfu
hjTghNqJHffZLse/55VxubMcQt+Bn2+HnaTl2ct9zy4uT/vu6xO0iXTVT16UY9i5
TfKFK4JKbF+vnucQzEMYUZdJh7cCunffTtCujxB33t4oGnT4kTun73+HlVQHhuVw
nweENfcAtES4z2pJ0ITk0K0FnzjZitvtSX2QUkkHkfgouwQhJ3Oz2wgXBxm237Pk
sbGy8ecGDkxRxjQFAbUVbvNnTP1ZTAWkbJj6g4onTlUQKquiZ6kiPxtu1QZSSjvr
gBoq0pZ9E+YH0Df/P4tIJEY4DuTCzkaBE0BuMlM3ywOPx8blz5nhxVSJ68m6b5R+
DYlTMsehs729ku4Ct2V3SUIC8qnmgQgKa3kBgxthwu1tmBjL8vtVbbjvQ4Vsjy7+
SjV1mM9kj16tVl/Cu1pQA0zIEDd4ybt8FqR7r7RukJnWX177kPf79NahDVOmcSos
9QkDCiVLkvjtjYbaKtKUAC05XcRiqSZbh5WejzvvnUcYa5cek+459KqdD1T0dUZR
I22cgPRZtcu5EYib/7bhGkFvuTAbJxmacnojfOXsIa/6wUndRDNdjRUNr8bdSMfC
cVJC3SoirWHhG6LLkYlR
=mU5v
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ximjr-00028f...@franck.debian.org



  1   2   >