date:20140816

On 08/16/2014 09:07 AM, Brian May wrote:
 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.

... or because one of the (build-)dependencies of that package doesn't
support Python 3.

Cheers,

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/53ef09fe.2040...@debian.org

Re: Python 3.4

On 08/16/2014 02:46 PM, Brian May wrote:
 On 16 Aug 2014 16:19, Lars Wirzenius l...@liw.fi mailto:l...@liw.fi
 wrote:
 If you upload things to unstable that depend on things in NEW, nobody
 will be able to install or upgrade that package (until the dependency
 gets through NEW).
 
 In this case however the 2nd package will also get blocked in New
 (Python3 support requires adding at least one new package), so it really
 depends which order the ftp-masters approve the requests.
 
 I would hope they don't approve a package in New that depends on another
 package in New, but not sure if they are setup to handle this case.
 
 It really seriously limits the number of python3 packages we can get in
 for Jessie if I have to wait 3+ weeks to get packages approved before I
 can deal with the packages that depend on this one.

Don't wait, just upload them all.

FTP masters do check for dependencies, and wont approve a package for
which the dependencies aren't in Sid already (meaning: they *will*
process packages from the NEW queue in the correct order). So you don't
need to worry about this.

If you have a complex set of dependencies though, it's probably a good
idea to drop a few lines to the FTP masters, just to let them know.

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/53ef0a9f.6020...@debian.org

Re: Standardizing the layout of git packaging repositories

Hi,

On Fri, 15 Aug 2014, Alessandro Ghedini wrote:
 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).

Right, it also means we can more safely differentiate uploads from each
vendors in the case where we want to act on those... for example if a
signed git tag could trigger a server-side build  upload.

So I agree with the various commenters that pkg/version was a bad idea
and that we should use the vendor prefix for uploads too.

 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?

We do this for Kali Linux too but there are always cases where some
contributors forget about the suffix (in particular when we package stuff
not yet in Debian, or new upstream releases of packages that lag behind in
Debian).

  - where should the HEAD point to in the public repository?
 
 Not sure what you mean by this.

This is the default branch that you get when you do git clone without
specifiying -b something. It's usually master but one can update it to
point somewhere else.

  - 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?

Well native = debian is the upstream. So there is no upstream tags created
by Debian but there might be such tags created by downstreams distros that
use the Debian tarballs as upstream tarballs (although I have never seen
this in practice).

Possibly the best way to notice debian is the upstream is to detect the
lack of debian/master branch (i.e. we use directly master which is usually
for the upstream developers).

  - 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.

We can certainly recommend it but I don't see the point to mandate it.

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/20140816081829.gb13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

Hi Jeremy,

I don't agree with you on this one. Let me explain why.

On 08/16/2014 07:05 AM, Jeremy Stanley wrote:
 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.

And then? If I prefer to use their git repository, and create my own
orig.tar.xz out of a signed git tag, what is the problem, as long as I
use the tag they provided by upstream?

 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.

Why?!? Is there some sort of religion around tarballs? Shouldn't it be
the same stuff that git archive does? If it isn't, why is this the
case? Shouldn't one be able to use what's in the Git repository anyway?
Why can't it be fixed? Aren't we supposed to build from source anyway?
Isn't the upstream git repository the preferred form for modification,
closer to what someone should be using when contributing upstream? Why
is it the case that upstream prefers that we use something generated
from his git repository? Shouldn't all what upstream generates in the
release tarball also done by the Debian package build anyway?

Also, what if I need to build a Debian package out of an upstream
commit, because there's some bug fixes which I need, but there's no
upstream tarball available?

- In my case, I'd just tag with something like this:
2014.2~b2+20140816+git+11ed391c. Then I'll use my standard process to
generate the orig.tar.xz (which is: doing nothing but editing the
debian/changelog to match that tag, and my jenkins script will do the
rest for me, ready for testing...).

- If doing what you're proposing, I'd have to manually create the
tarball, upload it somewhere (which could be *very* slow from where I
live), etc.

 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.

If by traditional release process you mean wasting human time,
computer CPU, and network bandwidth, to build old 80ies fashioned
tarballs (that is: with .gz compression and no PGP checksums), which by
the way loose all the commit history and such, I am wondering what you
are worrying about. That's useless these days, if upstream is using Git.
A tag is enough, and it's even better.

 *Please* don't replace upstream's release
 tarballs just because they have a VCS.

Generally, upstream don't provide checksums, even less provide PGP
signatures, while tags in git repositories are often pgp signed (and I
collected a bunch of signatures already in my ring). And often, upstream
include in the tarball artifacts which we do not need, like generated
files and so on. In the case of Python modules, for example, stuff from
PyPi often contains the egg-info folder, which we do not need in the
orig tarball (it's in fact preferred not to have them, because they will
be generated at build time anyway, with possible difference from the
tarball, which is in the way of a 2nd rebuild). Also, the .gz
compression is so 80ies. We're in 2014, and it's still hard to find
upstream releasing with .xz compressions.

I also think it's best to be able to build from the git repository
rather than what's been generated out of it, because that's what you
will do if you want to contribute to the upstream project.

Last, it's extremely rare to have issues with upstream git tag. In the
case of OpenStack, the only small issues I had were with the MANIFEST.in
which is sometimes missing some file. But a small Debian specific patch
gets rapidly rid of the issue. Also, to some degree, this is a problem
upstream that should be fixed anyway.

So yes, please do generate orig.tar.xz out of PGP signed tags, and do
Debian git-buildpackage based on tags repository, using the upstream git
repository as source. That's the correct technical thing to do, and you
wont regret it! As an upstream: please accept progress and convenience.

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/53ef1638.9020

Bug#758278: ITP: python-xstatic-jsencrypt -- JSEncrypt XStatic support

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org

* Package name: python-xstatic-jsencrypt
  Version : 2.0.0.2
  Upstream Author : Radomir Dopieralski openst...@sheep.art.pl
* URL : https://github.com/stackforge/xstatic-jsencrypt
* License : Expat
  Programming Lang: Python
  Description : JSEncrypt XStatic support

 XStatic is a packaging standard to package external (often 3rd party) static
 files as a Python package, so they are easily usable on all operating systems,
 with any package management system or even without one.
 .
 Many Python projects need to use some specific data files, like javascript,
 css, java applets, images, etc. Sometimes these files belong to YOUR project
 (then you may want to package them separately, but you could also just put
 them into your main package). But in many other cases, those files are
 maintained by someone else (like jQuery javascript library or even much bigger
 js libraries or applications) and you definitely do not really want to merge
 them into your project. So, you want to have static file packages, but you
 don’t want to get lots of stuff you do not want. Thus, stuff required by
 XStatic file packages (especially the main, toplevel XStatic package) tries to
 obey to be a MINIMAL, no-fat thing. XStatic doesn't sell any web framework
 or other stuff you don't want. Maybe there will be optional XStatic extensions
 for all sorts of stuff, but they won't be required if you just want the files.
 .
 By having static files in packages, it is also easier to build virtual envs,
 support linux/bsd/... distribution package maintainers and even windows
 installs using the same mechanism.
 .
 This package provides JSEncrypt support as a Python module.


--
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/20140816085033.881.65680.report...@buzig.gplhost.com

Bug#758280: ITP: python-xstatic-qunit -- QUnit XStatic support

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org

* Package name: python-xstatic-qunit
  Version : 1.14.0.2
  Upstream Author : Radomir Dopieralski openst...@sheep.art.pl
* URL : https://github.com/stackforge/xstatic-qunit
* License : Expat
  Programming Lang: Python
  Description : QUnit XStatic support

 XStatic is a packaging standard to package external (often 3rd party) static
 files as a Python package, so they are easily usable on all operating systems,
 with any package management system or even without one.
 .
 Many Python projects need to use some specific data files, like javascript,
 css, java applets, images, etc. Sometimes these files belong to YOUR project
 (then you may want to package them separately, but you could also just put
 them into your main package). But in many other cases, those files are
 maintained by someone else (like jQuery javascript library or even much bigger
 js libraries or applications) and you definitely do not really want to merge
 them into your project. So, you want to have static file packages, but you
 don’t want to get lots of stuff you do not want. Thus, stuff required by
 XStatic file packages (especially the main, toplevel XStatic package) tries to
 obey to be a MINIMAL, no-fat thing. XStatic doesn't sell any web framework
 or other stuff you don't want. Maybe there will be optional XStatic extensions
 for all sorts of stuff, but they won't be required if you just want the files.
 .
 By having static files in packages, it is also easier to build virtual envs,
 support linux/bsd/... distribution package maintainers and even windows
 installs using the same mechanism.
 .
 This package provides QUnit support as a Python module.


--
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/20140816091639.3043.68248.report...@buzig.gplhost.com

Re: Python 3.4

2014-08-16 Thread Andreas Metzler

Brian May br...@microcomaustralia.com.au wrote:
 On 16 Aug 2014 16:19, Lars Wirzenius l...@liw.fi wrote:
 If you upload things to unstable that depend on things in NEW, nobody
 will be able to install or upgrade that package (until the dependency
 gets through NEW).

 In this case however the 2nd package will also get blocked in New (Python3
 support requires adding at least one new package), so it really depends
 which order the ftp-masters approve the requests.
[...]

Hello,

Then I would upload both packages to experimental.

Personally I use experimental for everything that gos through NEW
since I want to be able influence when they hit unstable.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
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/0on3cb-mp8@argenau.downhill.at.eu.org

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread intrigeri

Hi,

Marco d'Itri wrote (15 Aug 2014 18:17:16 GMT) :
 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?

Wrt. downstreams: I guess that Raphaël is implicitly asking for this
(with his Kali hat) in this proposal. With my Tails hat, I do concur.

Cheers,
-- 
intrigeri


--
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/85a974lmz7@boum.org

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Guido Günther

On Sat, Aug 16, 2014 at 10:18:29AM +0200, Raphael Hertzog wrote:
[..snip..]
 We do this for Kali Linux too but there are always cases where some
 contributors forget about the suffix (in particular when we package stuff
 not yet in Debian, or new upstream releases of packages that lag behind in
 Debian).

In order to avoid this with gbp it's simple to ship
/etc/git-buildpacakge/gbp.conf

[DEFAULT]
debian-tag = kali/%(version)s

in kali linux's git-buildpackage.

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/20140816112120.ga17...@bogon.m.sigxcpu.org

Re: Standardizing the layout of git packaging repositories

Hi,

On Sat, 16 Aug 2014, intrigeri wrote:
 Marco d'Itri wrote (15 Aug 2014 18:17:16 GMT) :
  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?
 
 Wrt. downstreams: I guess that Raphaël is implicitly asking for this
 (with his Kali hat) in this proposal. With my Tails hat, I do concur.

Exactly. In Kali we use exclusively git for all packaging work
and we use gbp import-dsc on a debian branch to make it easier to
merge the debian changes in our forked packages.

It seems natural to go one step further and share the packaging repository
when Debian already uses git.

And if you need another example, I just learned that the Debian and Ubuntu
KDE teams want to use shared git repositories:
see Future Changes in
https://blogs.kde.org/2014/08/13/upstream-and-downstream-why-packaging-takes-time

So yes, there's a need here.

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/20140816113325.gc13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

Hi,

On Fri, 15 Aug 2014, Guido Günther wrote:
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).

Some comments on this recommended layout:

1/ I suggested vendor/master rather than vendor/unstable (or sid)
because it means we don't have to know the default codename/suite used
for packaging of new upstream versions (in particular for downstreams)

2/ having multiple upstream/codename is bound to never be up-to-date
when I do git checkout debian/experimental git merge
debian/master, upstream/experimental will get out of sync and I
won't notice it because my package builds just fine

However multiple upstream/* branches can be useful, they should
just match real upstream branches... so things like upstream/master,
upstream/4.8.x, upstream/4.9.x, etc.

3/ I don't see the need for backports/codename, I would rather
use debian/wheezy-backports (which actually is just a specific case
of vendor/codename since wheezy-backports is the Codename in the
Release file)
and security/codename is just the continuation of vendor/codename
after a stable release, so again I don't see the need for a specific
branch here (and if we really need a separate branch, it can again
be vendor/codename-security)

- 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.

Yes.

- 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.

Anything that needs to be configured is a source of error. I'd rather
have gbp do the right thing and pull the information from dpkg-vendor.

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/20140816115946.gd13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

(Please trim the quoted mail when you answer)

On Fri, 15 Aug 2014, Scott Kitterman wrote:
 - 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. 

I don't know of any git helper tools that work on git repositories with
Debian directory only.

The vast majority (all?) of git packaging repositories have the upstream
sources.

I think this point is not really contentious.

And given the willingness to make it easier to collaborate with upstream
using git, it would be silly to not have the upstream sources in our git
repositories.

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/20140816120318.ge13...@x230-buxy.home.ouaza.com

Bug#758295: ITP: libjs-spin.js -- animated CSS3 loading spinner

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org

* Package name: libjs-spin.js
  Version : 1.2.8
  Upstream Author : Felix Gnass fgn...@neteye.de
* URL : https://github.com/fgnass/spin.js
* License : Expat
  Programming Lang: Javascript
  Description : animated CSS3 loading spinner

 Spin.js is an animated CSS3 loading spinner with VML fallback for IE. It
 features:
  * No images, no external CSS
  * No dependencies
  * Highly configurable
  * Resolution independent
  * Uses VML as fallback in old IEs
  * Uses @keyframe animations, falling back to setTimeout()
  * Works in all major browsers, including IE6
  * Small footprint (~1.9K gzipped)


-- 
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/20140816121515.7972.30185.report...@buzig.gplhost.com

Bug#758297: ITP: python-xstatic-spin -- Spin.js XStatic support

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org

* Package name: python-xstatic-spin
  Version : 1.2.8.0+dfsg1
  Upstream Author : Radomir Dopieralski openst...@sheep.art.pl
* URL : https://github.com/stackforge/xstatic-spin
* License : Expat
  Programming Lang: Python
  Description : Spin.js XStatic support

 XStatic is a packaging standard to package external (often 3rd party) static
 files as a Python package, so they are easily usable on all operating systems,
 with any package management system or even without one.
 .
 Many Python projects need to use some specific data files, like javascript,
 css, java applets, images, etc. Sometimes these files belong to YOUR project
 (then you may want to package them separately, but you could also just put
 them into your main package). But in many other cases, those files are
 maintained by someone else (like jQuery javascript library or even much bigger
 js libraries or applications) and you definitely do not really want to merge
 them into your project. So, you want to have static file packages, but you
 don’t want to get lots of stuff you do not want. Thus, stuff required by
 XStatic file packages (especially the main, toplevel XStatic package) tries to
 obey to be a MINIMAL, no-fat thing. XStatic doesn't sell any web framework
 or other stuff you don't want. Maybe there will be optional XStatic extensions
 for all sorts of stuff, but they won't be required if you just want the files.
 .
 By having static files in packages, it is also easier to build virtual envs,
 support linux/bsd/... distribution package maintainers and even windows
 installs using the same mechanism.
 .
 This package provides spin.js support as a Python module.


--
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/20140816123842.12284.57984.report...@buzig.gplhost.com

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Scott Kitterman

On August 16, 2014 8:03:18 AM EDT, Raphael Hertzog hert...@debian.org wrote:
(Please trim the quoted mail when you answer)

On Fri, 15 Aug 2014, Scott Kitterman wrote:
 - 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. 

I don't know of any git helper tools that work on git repositories with
Debian directory only.

The vast majority (all?) of git packaging repositories have the
upstream
sources.

I think this point is not really contentious.

And given the willingness to make it easier to collaborate with
upstream
using git, it would be silly to not have the upstream sources in our
git
repositories.

Silly or not in your opinion, the Qt-KDE team repositories are set up this way.

They seem to like it and I don't think the project as a whole ought to try and 
force them to do work a different way.

Additionally, other tools, like git-dpm, have their own requirements for branch 
naming. That's the one tool that got me using git for packaging, so it would be 
nice if it kept working. Please send patches so it works with the new scheme as 
well as conversion scripts for existing repositories. 

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/2b32f568-b3c2-43f8-b465-7e79bdd59...@email.android.com

Re: Standardizing the layout of git packaging repositories

On Sat, 16 Aug 2014, Scott Kitterman wrote:
 Silly or not in your opinion, the Qt-KDE team repositories are set up this 
 way.

Sorry, I wasn't aware of that and didn't want to imply anything on people
using such a scheme.

Still it would be interesting to know why the team made this choice and
what tools they are using to make this work. Anyone has pointers or can
explain us the choices made?

 Additionally, other tools, like git-dpm, have their own requirements for
 branch naming. That's the one tool that got me using git for packaging,
 so it would be nice if it kept working. Please send patches so it works
 with the new scheme as well as conversion scripts for existing
 repositories. 

That's certainly something that ought to happen once we have some
agreement on the desired layout.

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/20140816150954.gf13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

On Sat, 16 Aug 2014, Guido Günther wrote:
 On Sat, Aug 16, 2014 at 10:18:29AM +0200, Raphael Hertzog wrote:
 [..snip..]
  We do this for Kali Linux too but there are always cases where some
  contributors forget about the suffix (in particular when we package stuff
  not yet in Debian, or new upstream releases of packages that lag behind in
  Debian).
 
 In order to avoid this with gbp it's simple to ship
 /etc/git-buildpacakge/gbp.conf
 
 [DEFAULT]
 debian-tag = kali/%(version)s
 
 in kali linux's git-buildpackage.

Thanks for the tip but I don't want to have to fork Debian development
packages. However it would be nice if we could ship a configuration
snippet in /etc/git-buildpackage/gbp.conf.d/kali.conf (in a kali-dev
package for example).

BTW it's unrelated to the quoted sentence since I was speaking of the
kali suffix that we add in package versions (1.0-0kali1).

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/20140816151414.gg13...@x230-buxy.home.ouaza.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Nicolas George

L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
 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.

I am afraid this discussion on Gerrit or other similar tools is pointless:
this is trying to solve a human problem with technical means: it never
works.

Actually, I believe all this peer-review business to be a red herring. On
the FFmpeg side, most patches except the very simple ones are sent to the
mailing-list for peer-review, even patches by people with commit rights
working on their own code; they do so not because a rule states they have
too but because this is the best thing to achieve good code. On the other
hand, I remember having seen patches somewhat rushed through the mandatory
review on libav-devel and applied when someone else still had remarks; I
have not kept tabs on that though.

The real issue between the mandatory peer-review on the mailing-list is,
IMHO, control of the project orientation. Not is this patch correct? but
do we want this patch?.

If you are involved in the project, it is very obvious that both branches
have rather opposed views on the project orientation: libav has made a point
of trimming unnecessary features and rejecting new ones while FFmpeg kept
them and added some.

A few examples:

* Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
  message said appears simpler to write a new replacement from scratch,
  but in the meantime, users are left without the feature.

* Libav removed the framerate detection code, FFmpeg built on it to handle
  it in filtering too. I do not find them right now, but I have found a few
  files that avconv wanted to encode at an insane frame rate while ffmpeg
  correctly guessed; and right now, -vf fps does not work alone with very
  common formats in avconv.

* Libav removed the keyboard interaction (Press [q] to stop) while FFmpeg
  extended it.

Beyond these obvious cases, FFmpeg has gained quite a few features that, I
am pretty certain of it, would not have been accepted into libav: the concat
demuxer (has been called hack on the mailing-lists IIRC), the lavfi
sources made for testing, support for some obscure format through an
external library, subtitles hard-burning, etc.

The most galling in this issue is that there is no clear decision behind
this orientation. The fork's manifesto stated that everyone was equal
amongst equals, with or without commit rights, but the people who do have
the commit rights are few and of a common mind, they can just give the cold
shoulder to proposed changes that do not suit their personal view of the
project.

Considering these differences in policy, I do not believe the fork can be
merged. Speaking as someone who proposed a few of these unnecessary
features, because they were fun or immediately useful, I would not like to
work on a project that would reject them by principle. But I can recognize,
for someone who needs serious professional software, the need of working
on something driven with a firmer hand.


Having a fork is not inherently bad, and it becomes necessary when people
have different views for the orientation of the projects.

It becomes bad when people not involved in the project start to suffer from
the consequences of the fork. This is what is happening here, for two
reasons:

* distributions adopting one side of the fork for non-technical reasons;

* one side of the fork not caring about compatibility with the other side.

Of course, these reasons are interconnected.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

On 08/15/2014 11:53 PM, The Wanderer wrote:
 It's also something the Linux kernel is still doing, with apparent
 success.

Yes, the Linux kernel is a successful project. Does this mean using a
list for reviewing patches is a good thing? No! The workflow with a list
is simply horrible. Using git-review and gerrit is so much better.

 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.)

This reasoning may work when you have only a small amount of information
to read. When you are overwhelmed with it, having different places to do
different things is a much better approach. Sending patches to a list
simply doesn't scale.

Also, with a list, it's not convenient at all to point out a line in a
patch in a mailing list. You must extract the relevant lines, cut/past
them, and comment them. Instead, double clicking on the line of the
patch which is displayed on a web interface is much more convenient.

 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.

Lists are good tools for discussing where a project should go, release
goals, and so on. They aren't good tools to do patch reviews. I've used
both, and I'm convinced of that.

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/53ef78f4.2090...@debian.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Nicolas George

Le septidi 27 thermidor, an CCXXII, Thomas Goirand a écrit :
   If you guys could find a solution to try to work together
 again, and merge back both projects, that'd be best for everyone.

When people suggest that, I always wonder how they see that happening with
regard to the code.

In more than three years since the fork, development has continued on both
branches. Changes are continuously ported from libav to FFmpeg, but code was
also written for FFmpeg and never merged by libav. Some of this code, the
libav people have made very clear they specifically did not want it.

So what about the code? Shall the FFmpeg developers discard three years of
work and start working on libav? Or shall the libav developers accept to
work with the code from FFmpeg that they do not like?

I see neither as an option.

The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Pau Garcia i Quiles

On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org wrote:


 The only option is to make sure the users do not suffer from the fork, by
 making sure they can easily use the version that is most suited for their
 need without being sucked into the developers' disagreements.


Can we get back on topic?

With or without libav in Debian, there are solid technical reasons to have
ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although
they parted ways in a civilized way: different library names), and we
certainly have a ton of librarys which provide very similar features.

Since before the fork, the libav developers have been sabotaging ffmpeg as
much as possible, in every combat field: library names, library versions,
taking distributions hostage (ffmpeg package that installs libav!?), etc.
This is not the way to fork anything. This is a fact. I don't care whether
Michael Nidermayer was a dictator or not. I don't care whether the
code-review rules in libav are better or worse. I don't care what the Linux
kernel does. The only thing I care about is Debian is shipping a
less-capable (i. e. less multimedia formats supported) distribution due to
this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will most
certainly cause binary problems.

If libav and ffmpeg maintainers cannot reach an agreement regarding library
names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian. E.
g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done
in the past.

And before someone mentions it: I don't think it's too late. It's getting
too late because nobody with the right to act is doing anything. In the
end, our users are the ones being harmed and we are left wondering why they
are increasingly moving to other distributions or Mac OS X.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread wm4

On Sat, 16 Aug 2014 23:29:56 +0800
Thomas Goirand z...@debian.org wrote:

 On 08/15/2014 11:53 PM, The Wanderer wrote:
  It's also something the Linux kernel is still doing, with apparent
  success.
 
 Yes, the Linux kernel is a successful project. Does this mean using a
 list for reviewing patches is a good thing? No! The workflow with a list
 is simply horrible. Using git-review and gerrit is so much better.
 
  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.)
 
 This reasoning may work when you have only a small amount of information
 to read. When you are overwhelmed with it, having different places to do
 different things is a much better approach. Sending patches to a list
 simply doesn't scale.
 
 Also, with a list, it's not convenient at all to point out a line in a
 patch in a mailing list. You must extract the relevant lines, cut/past
 them, and comment them. Instead, double clicking on the line of the
 patch which is displayed on a web interface is much more convenient.

What? Most patches are posted inline (with git-send-email).
 
  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.
 
 Lists are good tools for discussing where a project should go, release
 goals, and so on. They aren't good tools to do patch reviews. I've used
 both, and I'm convinced of that.

What we need is solving the FFmpeg/Libav split, not well-meant
suggestions by outsiders how to change our development model.

 Thomas Goirand (zigo)
 ___
 ffmpeg-devel mailing list
 ffmpeg-de...@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-- 
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/20140816174433.1f3f496b@debian

Re: Standardizing the layout of git packaging repositories

Hi,

On Fri, 15 Aug 2014, Simon McVittie wrote:
 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?

I think we can answer this question without imposing the associated
workflow.

What's on the branch should be a directory where we can call
dpkg-buildpackage and have the build work.

I believe that most of the current workflows do respect this rule (except
for the case where you only store the debian directory).

 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.

Are you sure that --git-export is the right option? It needs a treeish so
I would expect that it can only use something that is in the git
repository.

Looking at the doc it's --git-overlay that is the important option,
obviously you need to combine this with --git-export-dir=../build-area/
to mimick what svn-buildpackage does.

(FWIW I do use --git-export-dir=../build-area/ but not --git-overlay)

 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.

I'm not a git-dpm user but I just tried. patches are applied but .pc
is not present. This means that you can't use quilt but you can
call dpkg-buildpackage and have it just work because dpkg-source
is smart enough to detect that patches are already applied.

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/20140816160946.gh13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

Thomas Goirand z...@debian.org writes:
 On 08/16/2014 07:05 AM, Jeremy Stanley wrote:

 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.

 And then? If I prefer to use their git repository, and create my own
 orig.tar.xz out of a signed git tag, what is the problem, as long as I
 use the tag they provided by upstream?

Suppose someone wants to check (possibly as part of a forensic
investigation) that the source in Debian matches the source released and
signed by upstream.  If you reuse the upstream tarball, the signature is
valid, so this is as simple as verifying the Debian *.orig.tar.xz file
against the upstream signature or a checksum of a good copy of the
upstream source.  If you regenerate the tarball, those checksums are no
longer valid, and now someone has to unpack both tarballs and compare all
of the files (and, depending on what they're checking, permissions and
other metadata) individually.

It's not a huge advantage, but for me at least it's a quality of
implementation issue to base the packaging on the tarball as released,
instead of on a tarball generated from the same file tree.

 Also, what if I need to build a Debian package out of an upstream
 commit, because there's some bug fixes which I need, but there's no
 upstream tarball available?

Then obviously these issues don't apply.  :)

 Generally, upstream don't provide checksums, even less provide PGP
 signatures, while tags in git repositories are often pgp signed (and I
 collected a bunch of signatures already in my ring).

I'm surprised that upstreams that sign their Git tags don't sign their
tarballs.  My experience is the opposite: signed tarballs are more common
than signed Git tags, at least for upstreams that do tarball releases at
all.

 And often, upstream include in the tarball artifacts which we do not
 need, like generated files and so on.

This is true, and opinions differ about the tradeoff there.  I personally
prefer to upload the source as released by upstream, including those
artifacts, to Debian, because I don't know how people who pull the source
from Debian might want to use it.  Yes, *we* don't need those artifacts,
but maybe someone wants to do an apt-get download and then run ./configure
and make for some reason without using the Debian packaging.

Basically, I see no harm, only a small amount of additional work once
pristine-tar and git-buildpackage are set up properly, and a moderate gain
to basing packaging on the upstream tarball as released.  I also do this
for packages for which I'm upstream.

-- 
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/87ha1cbe3a@hope.eyrie.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Pau Garcia i Quiles pgqui...@elpauer.org writes:

 If libav and ffmpeg maintainers cannot reach an agreement regarding
 library names and it's not possible to simply use either ffmpeg or libav
 indistinctly due missing features binary compatibility, etc, the obvious
 solution is that BOTH libav and ffmpeg rename their libraries in
 Debian. E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe
 even use alternatives to provide the binaries (ffmpeg, ffplay,
 etc). It's been done in the past.

None of this is why libav and FFmpeg can't both be in the archive.  They
can't both be in the archive because both the release team and the
security team have said that they're not interested in trying to support
both, due to the amount of work involved.

All the renaming and cordial co-existence in the world won't change this.
The things that would change this is for one or both projects to develop a
better security track record and a history of higher-quality code releases
that require less ongoing work in stable, or for the people who care
deeply about this to somehow find a way to relieve the impact on those
teams in some way acceptable to those teams.

Short of that, there's clearly a need for software of this type in Debian,
and at the same time it's clearly a ton of work.  The teams involved have
indicated that they're willing (if not necessarily happy) to deal with one
version of the source base, but not two.

-- 
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/878umobdj5@hope.eyrie.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Cyril Brulebois

Hi Russ,

Russ Allbery r...@debian.org (2014-08-16):
 None of this is why libav and FFmpeg can't both be in the archive.
 They can't both be in the archive because both the release team and
 the security team have said that they're not interested in trying to
 support both, due to the amount of work involved.

the release team only has a say on what ends up in testing (and then
in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from
entering the archive. FTP masters have the control over the archive
as a whole.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Philip Muskovac

On Saturday 16 August 2014 17:09:54 Raphael Hertzog wrote:
 On Sat, 16 Aug 2014, Scott Kitterman wrote:
  Silly or not in your opinion, the Qt-KDE team repositories are set up this 
  way.
 
 Sorry, I wasn't aware of that and didn't want to imply anything on people
 using such a scheme.
 
 Still it would be interesting to know why the team made this choice and
 what tools they are using to make this work. Anyone has pointers or can
 explain us the choices made?

I'm writing this from a Kubuntu POV which should be close to debian-qt-kde as 
we have a pretty close workflow (one of the reasons why we're talking about 
moving our branches to their repositories) as we also only keep the debian/ dir 
in the VCS.

a) Consistent VCS based packaging workflow
While upstream has switched most of their repositories to git, there's 
a couple (artwork related) repositories that are kept in SVN, so if we would 
use a git-based workflow with source and packaging together, we would have to 
manage different workflows for specific packages within the same release which 
is something I would prefer not to do.

b) Repository size
Cloning the upstream kdelibs repository is currently a ~158MiB 
download, and while that might be one of the largest repositories, a KDE SC 
release consists of ~170 tarballs so even leaving the SVN managed ones aside 
you have to download *a lot*. It is a lot easier to work with a couple MiB 
large packaging repositories that only manage the debian/ folder. (Add KDE 
Frameworks 5 and Plasma5 and you've far surpassed the 200 package mark)

c) Upstream tag management
The KDE release team currently publishes tarballs with checksums and 
git/svn revisions to packagers before the actual release for build testing and 
early Q/A. So when we build the packages, there is no git tag yet that we could 
use to generate a tarball ourselves, we would have to parse the tarball list 
for the commit hash that was used to generate the tarball and base our 
packaging on that - or wait for the tags and loose the chance to give the 
release team pre-release feedback.

I might've missed something else, but those are some of our reasons for not 
managing the source ourselves.
Both bzr builddeb and git buildpackage can download a tarball during the 
package build in case the upstream source isn't already there (I usually rely 
on watch files in the packages and deb-src entries in my apt configuration for 
that)


Aside from the different workflow, I do like the tagging proposal with 
vendor/version as that did not yet come up in my discussion with the 
debian-qt-kde folks.

Philip

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

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Cyril Brulebois k...@debian.org writes:
 Russ Allbery r...@debian.org (2014-08-16):

 None of this is why libav and FFmpeg can't both be in the archive.
 They can't both be in the archive because both the release team and
 the security team have said that they're not interested in trying to
 support both, due to the amount of work involved.

 the release team only has a say on what ends up in testing (and then
 in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from
 entering the archive. FTP masters have the control over the archive
 as a whole.

Sorry, yes, good point.  I should have been clearer.  I assume the goal
was to get both into a stable release.  If people wanted to upload FFmpeg
only to unstable without propagation to testing or making it part of a
release, that's a possibly different situation with different tradeoffs
and issues involved.

-- 
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/87y4uo9xr1@hope.eyrie.org

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Michael Biebl

Am 16.08.2014 18:20, schrieb Russ Allbery:
 Thomas Goirand z...@debian.org writes:
 On 08/16/2014 07:05 AM, Jeremy Stanley wrote:
 
 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.
 
 And then? If I prefer to use their git repository, and create my own
 orig.tar.xz out of a signed git tag, what is the problem, as long as I
 use the tag they provided by upstream?
 
 Suppose someone wants to check (possibly as part of a forensic
 investigation) that the source in Debian matches the source released and
 signed by upstream.  If you reuse the upstream tarball, the signature is
 valid, so this is as simple as verifying the Debian *.orig.tar.xz file
 against the upstream signature or a checksum of a good copy of the
 upstream source.  If you regenerate the tarball, those checksums are no
 longer valid, and now someone has to unpack both tarballs and compare all
 of the files (and, depending on what they're checking, permissions and
 other metadata) individually.

More importantly (at least in my experience): If you are working in a
team and you regenerate the tarball from git, it's very likely that the
md5sum of the generated tarball differs from what has been uploaded to
the archive by a different team maintainer in a previous upload,
resulting in a reject by dak.


-- 
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: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Ivan Kalvachev

On 8/16/14, Pau Garcia i Quiles pgqui...@elpauer.org wrote:
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org wrote:

The only option is to make sure the users do not suffer from the fork, by
making sure they can easily use the version that is most suited for their
need without being sucked into the developers' disagreements.

Can we get back on topic?

With or without libav in Debian, there are solid technical reasons to have
ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although
they parted ways in a civilized way: different library names), and we
certainly have a ton of librarys which provide very similar features.

Since before the fork, the libav developers have been sabotaging ffmpeg as
much as possible, in every combat field: library names, library versions,
taking distributions hostage (ffmpeg package that installs libav!?), etc.
This is not the way to fork anything. This is a fact. I don't care whether
Michael Nidermayer was a dictator or not. I don't care whether the
code-review rules in libav are better or worse. I don't care what the Linux
kernel does. The only thing I care about is Debian is shipping a
less-capable (i. e. less multimedia formats supported) distribution due to
this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will most
certainly cause binary problems.

If libav and ffmpeg maintainers cannot reach an agreement regarding library
names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian. E.
g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done
in the past.

AFAIK, Andreas' package uses libavcodec-ffmpeg.so .

FFmpeg configure does have option --build-suffix=_ffmpeg that would
append that suffix to library names and pkg-config files. Since
applications might have problem finding the ffmpeg libraries, the
pkg-config files should be with the old common names and this
creates a conflict in the -dev packages.

Libav and FFmpeg can coexist side by side.
There are no conflicts or overlap for binary users.

The current goal of FFmpeg is not replacing Libav.
The current goal is establishing a native presence in the most popular
distribution(s).

I'm quite sure the Security team is full of capable people who can
handle one more package.
FFmpeg takes security seriously.

The best scenario for everybody is:
1. Libav stays and all QA tested programs are not touched.
2. FFmpeg is included in a way that does not obstruct the rest of the ecosystem.
3. Optionally, programs that use _only_ FFmpeg could be included back
in Debian. Optionally.

The inclusion would allow for a real-life estimate to be done of the
FFmpeg performance, security, bug and feature wise.

Only after assessing real-life data, a final decision could be
reached, if there is still demand for such thing.

Best Regards
Ivan Kalvachev

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Bálint Réczey

Hi Nicolas,

2014-08-16 17:11 GMT+02:00 Nicolas George geo...@nsup.org:
 L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
 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.

 I am afraid this discussion on Gerrit or other similar tools is pointless:
 this is trying to solve a human problem with technical means: it never
 works.
I did not want to sell Gerrit over mailing-list discussion because the
work-flow is something which should be chosen by the development team
and not outsiders, but wanted to show that tools can help enforcing
some parts of the work-flow.

On the human problems vs. technical means questions I think we have
different opinions. Technical means are exceptionally great tools for
solving _some_ human problems. If the human problem is being not
satisfied with peers' behavior of not following a specific work-flow a
toll which enforces the work-flow would solve it. Making mistakes is
an other (mostly) human problem and we have lintian for example which
helps pointing them out.


 Actually, I believe all this peer-review business to be a red herring. On
 the FFmpeg side, most patches except the very simple ones are sent to the
 mailing-list for peer-review, even patches by people with commit rights
 working on their own code; they do so not because a rule states they have
 too but because this is the best thing to achieve good code. On the other
 hand, I remember having seen patches somewhat rushed through the mandatory
 review on libav-devel and applied when someone else still had remarks; I
 have not kept tabs on that though.

 The real issue between the mandatory peer-review on the mailing-list is,
 IMHO, control of the project orientation. Not is this patch correct? but
 do we want this patch?.

 If you are involved in the project, it is very obvious that both branches
 have rather opposed views on the project orientation: libav has made a point
 of trimming unnecessary features and rejecting new ones while FFmpeg kept
 them and added some.
IMO the trimming/rejecting strategy is not something which would ever
make Libav popular among developers/users and this is how we ended in
the current situation. While Libav's communicated release strategy can
attract integrators and distributions like Debian, FFmpeg attracts
developers/users of software based on Libav/FFmpeg due to more
features.
Sticking to those core strategies the two forks will compete forever
until one of them give up - which I see unlikely to happen voluntarily
- and users will keep complaining about Libav's missing features to
distributions' maintainers where FFmpeg is not packaged.

I think the best way out of this situation would be relaxing the
review requirements on Libav's side and letting not-yet-proven of
FFmpeg features in through an experimental/staging phase. If FFmpeg
devs could collaborate with them this way the two forks could be
converged and finally merged and the combined team could maintain a
lot better media library than the current forks are separately.

Cheers,
Balint


 A few examples:

 * Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
   message said appears simpler to write a new replacement from scratch,
   but in the meantime, users are left without the feature.

 * Libav removed the framerate detection code, FFmpeg built on it to handle
   it in filtering too. I do not find them right now, but I have found a few
   files that avconv wanted to encode at an insane frame rate while ffmpeg
   correctly guessed; and right now, -vf fps does not work alone with very
   common formats in avconv.

 * Libav removed the keyboard interaction (Press [q] to stop) while FFmpeg
   extended it.

 Beyond these obvious cases, FFmpeg has gained quite a few features that, I
 am pretty certain of it, would not have been accepted into libav: the concat
 demuxer (has been called hack on the mailing-lists IIRC), the lavfi
 sources made for testing, support for some obscure format through an
 external library, subtitles hard-burning, etc.

 The most galling in this issue is that there is no clear decision behind
 this orientation. The fork's manifesto stated that everyone was equal
 amongst equals, with or without commit rights, but the people who do have
 the commit rights are few and of a common mind, they can just give the cold
 shoulder to proposed changes that do not suit their personal view of the
 project.

 Considering these differences in policy, I do not believe the fork can be
 merged. Speaking as someone who proposed a few of these unnecessary
 features, because they were fun or immediately useful, I would not like to
 work on a project that would reject them by principle. But I can recognize,
 for someone who needs serious professional software, the need of

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Bálint Réczey

Hi Russ,

2014-08-16 18:59 GMT+02:00 Russ Allbery r...@debian.org:
 Cyril Brulebois k...@debian.org writes:
 Russ Allbery r...@debian.org (2014-08-16):

 None of this is why libav and FFmpeg can't both be in the archive.
 They can't both be in the archive because both the release team and
 the security team have said that they're not interested in trying to
 support both, due to the amount of work involved.

 the release team only has a say on what ends up in testing (and then
 in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from
 entering the archive. FTP masters have the control over the archive
 as a whole.

 Sorry, yes, good point.  I should have been clearer.  I assume the goal
 was to get both into a stable release.  If people wanted to upload FFmpeg
 only to unstable without propagation to testing or making it part of a
 release, that's a possibly different situation with different tradeoffs
 and issues involved.
For now the target is not stable, but unstable/experimental. Both the
Security and Release Teams could keep an RC bug on the package until
they are fine with letting it into testing.

Cheers,
Balint


-- 
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/cak0odpzp7jri7zwhd5t_bh+trbtznnx139lequ-+rkwkrbw...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Ivan Kalvachev ikalvac...@gmail.com writes:

 I'm quite sure the Security team is full of capable people who can
 handle one more package.

One, no, this statement is not correct.  Not because the security team is
not capable -- they are very capable -- but because they are not *full*.
You imply that the security team has tons of resources and time to spare.
Let me assure you that this is far from the case.  This isn't even the
case for security teams consisting of full-time staff paid by commercial
Linux distributions, let alone volunteers for the Debian project.

Two, the security team has already said that FFmpeg is not just one more
package, and that no, they can't handle the substantial incremental load
from adding FFmpeg without removing libav.  You may not think that should
be the case, but I'm afraid your opinion on the topic doesn't matter
unless you're finding a way to either reduce that work or add more
resources.

 FFmpeg takes security seriously.

I'm sure that it does.

The problem, however, is that taking security seriously, while possibly
necessary, is not sufficient.  I'm glad that FFmpeg takes security
seriously, but what FFmpeg needs is to *have fewer security bugs*.

This isn't about anyone's good intentions.  It's about the reality of
past, very negative experience with FFmpeg's security track record.

It's clear that efforts are underway to improve that, such as through the
fuzz testing work that Google (among others) has been doing.  That's
great, but I'm sure you can also understand that the past track record has
been sufficiently bad that everyone will continue to be leery for a while.
To change that impression, FFmpeg is going to have to substantially
improve on its past security track record and then *maintain* that new
level of security for some period of time.

Note that all of the above statements also apply to libav.  As near as I
can tell, this is not a distinguishing characteristic between the two
projects.

-- 
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/87fvgw9s6v@hope.eyrie.org

Re: Standardizing the layout of git packaging repositories

Hi Thomas,

On Sat, 16 Aug 2014, Thomas Goirand wrote:
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.

Branches are cheap so you can easily have both if the upstream-based
branches bring you value. But it's disconcerting for random Debian
contributors to not have a clear mapping with Debian 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?

Ideally, yes, but:
- not all upstreams use git (and in those case we want to create our own
  tags pointing to synthetic commits created by tools like gbp import-orig)
- among upstream using git, some are not creating proper tags/releases
  (and we are doing releases based on snapshot tarballs where we are
  creating our own version like 0~20140812)
- among upstream who are creating tags, there's no single naming
  convention that is shared (and it can be useful to duplicate the
  upstream tags in a namespace of our own)

Obviously, when upstream are already doing everything correctly, creating
the upstream/version tag should not become some administrative chore but
it could be done automatically as part of a some gbp upstream-merge
upstream-tag command for example.

  - 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?

It's the default branch one gets when you do git clone, it's better if
the user ends up on some useful branch. I agree with you, it should
probably be vendor/master (assuming we keep that branch naming).

  - 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.

This question had nothing to do with pristine-tar. It's just that if you look
at the dpkg repository, we are doing upstream development in Debian and
are thus using the master branch directly (and it would not make sense for
us to start using debian/master). Similarly, since we are also upstream,
it would not make much sense for us to create upstream/version tags...

Hence the question of how to adapt the conventions for this specific case.

  - 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.

Elsewhere you seem to imply that git archive should be enough. So what
is there to industrialize here?

That said I don't believe that this DEP should mandate anything on the
tarball to use (i.e. upstream provided tarballs vs something generated
with git archive).

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/20140816191315.gi13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Simon McVittie

On 16/08/14 17:09, Raphael Hertzog wrote:
 On Fri, 15 Aug 2014, Simon McVittie wrote:
 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.
 
 Are you sure that --git-export is the right option?
...
 Looking at the doc it's --git-overlay that is the important option,
 obviously you need to combine this with --git-export-dir=../build-area/
 to mimick what svn-buildpackage does.

Yes, you're right. In my only package that needs it (openarena-data,
which consists of large binaries that can't be patched) I configured it
in debian/gbp.conf, so I've never actually needed to remember the right
option :-)

S


-- 
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/53efb07a.2080...@debian.org

Re: Standardizing the layout of git packaging repositories

Hi,

On Sat, 16 Aug 2014, Philip Muskovac wrote:
 I'm writing this from a Kubuntu POV which should be close to
 debian-qt-kde as we have a pretty close workflow (one of the reasons why
 we're talking about moving our branches to their repositories) as we
 also only keep the debian/ dir in the VCS.

Thanks for your feedback! A couple of comments though:

 a) Consistent VCS based packaging workflow
   While upstream has switched most of their repositories to git,
   there's a couple (artwork related) repositories that are kept in
   SVN, so if we would use a git-based workflow with source and
   packaging together, we would have to manage different workflows
   for specific packages within the same release which is something I
   would prefer not to do.

In both cases upstream releases tarballs, no? So that could be the layer
that offers the consistency that you're looking for (with the help of gbp
import-orig).

 b) Repository size

It's clear that having the upstream sources takes a lot of space and
it takes a while if you download everything at once. But in my experience
it has never been a problem. I must test build every package that I modify
so I need the sources anyway.

And there's a lot of value in the history. I often do git log -p setup.py
or git log -p Build.PL to discover new dependencies introduced by a new
upstream release.

FWIW my Kali work directory contains 200 repositories (and linux is one
of them) and takes about 6 Gb. Hardly a problem with the size of current
harddisk. We use gbp import-orig and pristine-tar.

 c) Upstream tag management
   The KDE release team currently publishes tarballs with checksums
   and git/svn revisions to packagers before the actual release for
   build testing and early Q/A. So when we build the packages, there
   is no git tag yet that we could use to generate a tarball
   ourselves, we would have to parse the tarball list for the commit
   hash that was used to generate the tarball and base our packaging
   on that - or wait for the tags and loose the chance to give the
   release team pre-release feedback.

Again the upstream tarballs are sufficient if you use a workflow based
on gbp import-orig.

 Aside from the different workflow, I do like the tagging proposal with
 vendor/version as that did not yet come up in my discussion with the
 debian-qt-kde folks.

I wanted to have this discussion for a while, but when I learned of this
shared repository plan I decided to go forward thinking that it could be
useful in this specific case...

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/20140816193158.gj13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

Hi,

On Fri, 15 Aug 2014, Henrique de Moraes Holschuh wrote:
  - 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.

Why?

Until we have defined what the layout is for a native package, you can't
assume this. It's possibly a subset of the conventions for non-native
packages + some common conventions in all software projects.

Something like:
- branches
  - master: main development branch
  - vendor/codename: only for downstreams (not Debian which is upstream)
- tags
  - version: release tags
  - vendor/version: only for downstreams

 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.

That's a good idea anyway.

  - 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.

Ideally, once we have clear conventions, the various tools start to use
the new conventions. That said I don't see the need to rename all past
tags. But if enough people feel that such renames are useful, I'm sure
the operations can be scripted and integrated in new versions of the
various tools.

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

That's one of the reason why we use a prefix. Do you have a concrete
example of when it could be problematic?

The only problematic case I can think of is when upstream already has
a debian tag.

 Release tags ought to always be signed really,

Yes.

 but should we recommend something about commits or just ignore that?

I have no opinion on this and I have never done this.

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/20140816195205.gk13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Bastien ROUCARIES

On Sat, Aug 16, 2014 at 1:59 PM, Raphael Hertzog hert...@debian.org wrote:
Hi,

On Fri, 15 Aug 2014, Guido Günther wrote:
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).

Some comments on this recommended layout:

However multiple upstream/* branches can be useful, they should
just match real upstream branches... so things like upstream/master,
upstream/4.8.x, upstream/4.9.x, etc.

I use for debian patches a debian-patches/version branch. Friendly
upstream could cherry pick if they need it.

Bastien

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

Yes.

Anything that needs to be configured is a source of error. I'd rather
have gbp do the right thing and pull the information from dpkg-vendor.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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

Re: Standardizing the layout of git packaging repositories

On 08/16/2014 03:53 AM, Henrique de Moraes Holschuh wrote:
 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?

That would be a waste of space, especially for large tarballs. Even for large
upstream sources storing the pristine tar delta only takes a very small amount
of space compared to what is needed to store the original tarball.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/53efbd19.8030...@bzed.de

Re: Standardizing the layout of git packaging repositories

On 08/16/2014 02:03 PM, Raphael Hertzog wrote:
 I don't know of any git helper tools that work on git repositories with
 Debian directory only.

git-buildpackage --git-overlay

works just fine since ~2009.
I'm wondering if you actually ever investigated if there is a tool instead of
blindly assuming there is none.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/53efbe1d.60...@bzed.de

Re: Standardizing the layout of git packaging repositories

On Sat, 16 Aug 2014, Bernd Zeimetz wrote:
 On 08/16/2014 02:03 PM, Raphael Hertzog wrote:
  I don't know of any git helper tools that work on git repositories with
  Debian directory only.
 
 git-buildpackage --git-overlay
 
 works just fine since ~2009.

Thanks for the information.

 I'm wondering if you actually ever investigated if there is a tool instead of
 blindly assuming there is none.

I just said that I did not know, not that I investigated the topic
extensively. FWIW, I already made it clear that I see no value in
maintaining a debian directory only... but obviously others are free
to think differently, and apparently some do. :-)

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/20140816203656.gl13...@x230-buxy.home.ouaza.com

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Marco d'Itri

On Aug 16, Don Armstrong d...@debian.org wrote:

 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?
You only need this if you fail to correctly build the binary package, 
since in these cases you would not do a sourceful upload.
And anyway I'd say that downloading the original archive is simpler than 
having to deal with pristine-tar...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Standardizing the layout of git packaging repositories

m...@linux.it (Marco d'Itri) writes:

 And anyway I'd say that downloading the original archive is simpler than 
 having to deal with pristine-tar...

I'm mystified.  What is there to deal with?  I literally never touch it.
It just works, completely transparently and silently.

-- 
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/87mwb488p2@hope.eyrie.org

Re: incoming.debian.org opens its doors to the public

2014-08-16 Thread Cyril Brulebois

Ansgar Burchardt ans...@debian.org (2014-08-17):
 incoming.debian.org is used to publish recently uploaded source and
 binary packages before they reach the mirror network of the main
 archive. Until now, however, with the exception of the buildd network,
 it has not been possible to verify the integrity of the files. This was
 traditionally because we did not want to load ftp-master.debian.org by
 many users downloading files.
 
 Several people informed us that it would make their work on Debian
 easier, if they had a way to securely access these packages. So we
 decided to implement some changes to incoming.debian.org:
 
 First, the archive used by buildds is now publically accessible in
 http://incoming.debian.org/debian-buildd/. This location provides access
 to all recently uploaded packages, split into individual suites, and
 provides the neccessary metadata for APT to verify the integrity of the
 published files. See [1] for details.
 
   [1] http://incoming.debian.org/HEADER.html
 
 Secondly, source and binary packages are no longer published directly on
 http://incoming.debian.org/. Instead, people are encouraged to use the
 pool layout described above which is configured per-suite and contains
 Release files which have been signed in the normal way.
 
 We would also like to thank the Debian System Administration team who
 quickly setup the static mirror setup for the new incoming.d.o, thus
 making this possible.  We would also like to thank the wanna-build and
 buildd team for making the relevant changes to the buildds quickly so
 that we could make this change live.

Being one of the developers (particularly) enjoying such a move: thank
you very much, all of you.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread wm4

On Sat, 16 Aug 2014 11:59:20 -0700
Russ Allbery r...@debian.org wrote:

 The problem, however, is that taking security seriously, while possibly
 necessary, is not sufficient.  I'm glad that FFmpeg takes security
 seriously, but what FFmpeg needs is to *have fewer security bugs*.

That is very valuable advice. We'll get to work right away.

 Note that all of the above statements also apply to libav.  As near as I
 can tell, this is not a distinguishing characteristic between the two
 projects.

And that's an argument against switching to FFmpeg exactly how?


-- 
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/20140817002757.6516bd91@debian

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Andreas Cadhalpun

Hi,

On 16.08.2014 17:49, Pau Garcia i Quiles wrote:

On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org
mailto:geo...@nsup.org wrote:

The only option is to make sure the users do not suffer from the
fork, by
making sure they can easily use the version that is most suited for
their
need without being sucked into the developers' disagreements.

Can we get back on topic?

Yes. I have now sent the pkg-config patches to the BTS [1].

With or without libav in Debian, there are solid technical reasons to
have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick
(although they parted ways in a civilized way: different library names),
and we certainly have a ton of librarys which provide very similar features.

This is also my point of view.

It would be nice, if everyone, including you, would refrain from posting
such flamebaits on debian-devel.

Please try to follow Debian's code of conduct [2].

I don't care whether Michael Nidermayer was a dictator or not. I don't
care whether the code-review rules in libav are better or worse. I don't
care what the Linux kernel does. The only thing I care about is Debian
is shipping a less-capable (i. e. less multimedia formats supported)
distribution due to this conflict.

This has to stop.

ffmpeg is not yet in Debian due to the filename clashing, which will
most certainly cause binary problems.

This is wrong, because the FFmpeg Debian packaging avoids filename
conflicts.

If libav and ffmpeg maintainers cannot reach an agreement regarding
library names and it's not possible to simply use either ffmpeg or libav
indistinctly due missing features binary compatibility, etc, the obvious
solution is that BOTH libav and ffmpeg rename their libraries in Debian.
E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc.

This is already done in the FFmpeg Debian packages.

Maybe even use
alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been
done in the past.

This is not necessary, because the Libav binaries already have different
names, avconv, avplay and so on.

And before someone mentions it: I don't think it's too late. It's
getting too late because nobody with the right to act is doing anything.
In the end, our users are the ones being harmed and we are left
wondering why they are increasingly moving to other distributions or Mac
OS X.

Indeed it's getting late, because the FFmpeg package has been waiting in
the NEW queue for more than 3 months.

Best regards,
Andreas

1:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=andreas.cadhal...@googlemail.com

2: https://www.debian.org/code_of_conduct

--
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/53efdfea.8000...@googlemail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-08-16 Thread Derek Buitenhuis

On 8/16/2014 11:27 PM, wm4 wrote:
 That is very valuable advice. We'll get to work right away.

I've added it to my TODO:

* Don't write bugs.

- Derek


-- 
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/53efdcbe.5050...@gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

wm4 nfx...@googlemail.com writes:
 Russ Allbery r...@debian.org wrote:

 Note that all of the above statements also apply to libav.  As near as I
 can tell, this is not a distinguishing characteristic between the two
 projects.

 And that's an argument against switching to FFmpeg exactly how?

It's not.  Nor was I trying to make one.  This part of the thread was
discussing introducing FFmpeg into Debian alongside libav.

As I believe I mentioned previously, although the code base underlying
both projects has a bad past security track record, currently FFmpeg
appears to be doing somewhat better than libav.  I believe a member of the
security team made a similar observation.  So, when picking one, the
security argument seems to be at least partly in FFmpeg's favor.  That was
not my point; my point was that picking both of them is something that had
already been discussed and rejected for what to me feel like sound
reasons.

Security of course isn't the only consideration when picking one of the
two, and regardless I'm not the person who would be deciding anything.
Mostly I'm speaking up because it felt like people were going down blind
alleys arguing about things that aren't really at issue.

Note that experimental doesn't receive security support.  I may be missing
something (and here it's ftp-master that is the relevant decision-making
party), but I haven't seen any obvious reason why one shouldn't introduce
FFmpeg packages into experimental, particularly if people feel like
there's anything to be gained by seeing concrete packaging work, letting
people more easily experiment with the packages, and so forth.  Of course,
that by itself doesn't imply anything about the broader question of
replacing libav with FFmpeg or not.

-- 
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/878umo81wo@hope.eyrie.org

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

Derek Buitenhuis derek.buitenh...@gmail.com writes:
 On 8/16/2014 11:27 PM, wm4 wrote:

 That is very valuable advice. We'll get to work right away.

 I've added it to my TODO:

 * Don't write bugs.

That's a really bad way of avoiding security bugs.

I'm sure you know that and are just being flippant, but I have to say
that, as an outsider to the project who would like to use the software but
who cares a lot about not introducing security weaknesses, it's hard to
shake the feeling that this dismissive attitude is part of the problem.
There were earlier responses in the thread along the same lines, arguing
that the nature of FFmpeg means it will just inevitably have a bunch of
security bugs.  This sort of learned helplessness is really off-putting.

Thankfully, I get the impression from other research that I was doing
that it's *not* typical of FFmpeg as a whole, and that you all are, in
fact, doing exactly the sorts of things that I would recommend.  So this
is probably just one of those pointless Internet arguments where everyone
says things more aggressively than they actually mean them, and much heat
is created with little light.

But, for the record, what I was actually getting at is that the way to
avoid a bunch of security bugs is not to stop writing bugs, because no one
is going to achieve that.  It's to put in place supporting infrastructure
that makes it easier to write secure code and harder to write code where
bugs create security problems.  Trying to be closer to perfect in the code
you write is a horrible way to achieve security.  It doesn't work.  Adding
surrounding protective structure to the code so that the bugs do not
compromise security, and putting systems in place that let the computer do
lots more security sanity checking for you, are how other projects with
similar challenges have achieved considerable improvements in security bug
rates.

In case there's anyone reading this who doesn't have a feel for what this
looks like, the process the LibreSSL project is going through (regardless
of one's opinion on the desirability of an OpenSSL fork) is very
interesting.  I've personally learned quite a bit from it, have now
introduced reallocarray in my own code, and am planning on introducing
strtonum.

-- 
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/871tsg81dc@hope.eyrie.org

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Neil Williams

On Sat, 16 Aug 2014 14:03:18 +0200
Raphael Hertzog hert...@debian.org wrote:

 (Please trim the quoted mail when you answer)
 
 On Fri, 15 Aug 2014, Scott Kitterman wrote:
  - 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. 
 
 I don't know of any git helper tools that work on git repositories
 with Debian directory only.

git-buildpackage --git-overlay

 The vast majority (all?) of git packaging repositories have the
 upstream sources.

No. None of mine do, or will.
 
 I think this point is not really contentious.

Disagree. Having upstream sources in the packaging repository is a
retrograde action.
 
 And given the willingness to make it easier to collaborate with
 upstream using git, it would be silly to not have the upstream
 sources in our git repositories.

Wrong - it makes a lot of sense for upstream to *not* have packaging
files together with the upstream sources. It also makes good sense for
the packaging to be completely separate as a maintainer. 

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: Standardizing the layout of git packaging repositories

2014-08-16 Thread Neil Williams

On Sat, 16 Aug 2014 21:31:58 +0200
Raphael Hertzog hert...@debian.org wrote:

 Hi,
 
 On Sat, 16 Aug 2014, Philip Muskovac wrote:
  I'm writing this from a Kubuntu POV which should be close to
  debian-qt-kde as we have a pretty close workflow (one of the
  reasons why we're talking about moving our branches to their
  repositories) as we also only keep the debian/ dir in the VCS.
 
 Thanks for your feedback! A couple of comments though:
 
  a) Consistent VCS based packaging workflow
  While upstream has switched most of their repositories to
  git, there's a couple (artwork related) repositories that are kept
  in SVN, so if we would use a git-based workflow with source and
  packaging together, we would have to manage different
  workflows for specific packages within the same release which is
  something I would prefer not to do.
 
 In both cases upstream releases tarballs, no? So that could be the
 layer that offers the consistency that you're looking for (with the
 help of gbp import-orig).

There's no need to import the orig. It makes no sense. The packaging
lives elsewhere, it develops separately, it is used by multiple
upstream branches and it is used for interim builds where there has
been no upstream tarball released yet. The timescales are completely
separate and there is no benefit in upstream tags colliding with
packaging tags.

 And there's a lot of value in the history. I often do git log -p
 setup.py or git log -p Build.PL to discover new dependencies
 introduced by a new upstream release.

Then do that on the upstream git, not the packaging git.

  c) Upstream tag management
  The KDE release team currently publishes tarballs with
  checksums and git/svn revisions to packagers before the actual
  release for build testing and early Q/A. So when we build the
  packages, there is no git tag yet that we could use to generate a
  tarball ourselves, we would have to parse the tarball list for the
  commit hash that was used to generate the tarball and base our
  packaging on that - or wait for the tags and loose the chance to
  give the release team pre-release feedback.
 
 Again the upstream tarballs are sufficient if you use a workflow based
 on gbp import-orig.

No, not when tags are unrelated and could collide.

Standardising git packaging is a pointless and thankless task. Nothing
is likely to be gained, just a lot of time wasted on arguing on mailing
lists.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Bug#758390: ITP: python-xstatic-rickshaw -- Rickshaw JS XStatic support

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org

* Package name: python-xstatic-rickshaw
  Version : 1.5.0.0
  Upstream Author : Radomir Dopieralski openst...@sheep.art.pl
* URL : https://github.com/stackforge/xstatic-rickshaw
* License : Expat
  Programming Lang: Python
  Description : Rickshaw JS XStatic support

 XStatic is a packaging standard to package external (often 3rd party) static
 files as a Python package, so they are easily usable on all operating systems,
 with any package management system or even without one.
 .
 Many Python projects need to use some specific data files, like javascript,
 css, java applets, images, etc. Sometimes these files belong to YOUR project
 (then you may want to package them separately, but you could also just put
 them into your main package). But in many other cases, those files are
 maintained by someone else (like jQuery javascript library or even much bigger
 js libraries or applications) and you definitely do not really want to merge
 them into your project. So, you want to have static file packages, but you
 don’t want to get lots of stuff you do not want. Thus, stuff required by
 XStatic file packages (especially the main, toplevel XStatic package) tries to
 obey to be a MINIMAL, no-fat thing. XStatic doesn't sell any web framework
 or other stuff you don't want. Maybe there will be optional XStatic extensions
 for all sorts of stuff, but they won't be required if you just want the files.
 .
 By having static files in packages, it is also easier to build virtual envs,
 support linux/bsd/... distribution package maintainers and even windows
 installs using the same mechanism.
 .
 This package provides Rickshaw JS support as a Python module.


--
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/20140817025649.20865.68633.report...@buzig.gplhost.com

Re: Standardizing the layout of git packaging repositories

On 08/16/2014 04:18 PM, Raphael Hertzog wrote:
 - 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?
 
 Well native = debian is the upstream. So there is no upstream tags created
 by Debian but there might be such tags created by downstreams distros that
 use the Debian tarballs as upstream tarballs (although I have never seen
 this in practice).
 
 Possibly the best way to notice debian is the upstream is to detect the
 lack of debian/master branch (i.e. we use directly master which is usually
 for the upstream developers).

The best way to notice that the package is native, is to use what the
policy says: the VCS URLs must point to the Debian packaging branch,
then you just check the version number. Please don't try to second-guess
stuff using branch names.

By the way, I try to always avoid using master as a branch name. This
doesn't express anything at all.

 We can certainly recommend it but I don't see the point to mandate it.

Then *strongly* recommend it.

One of the reason to mandate it could be that we'd have an automated
build system which would clone the Git repository, and automatically
build using that. This is already what I'm doing with Jenkins, though
it's just using HEAD. Having a tagged signature (which would have to be
in the Debian maintainer keyring) could be a way to make sure that the
Git repository is valid before building.

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/53f01f50.1020...@debian.org

Re: Python 3.4

2014-08-16 Thread Brian May

On 16 August 2014 17:36, Thomas Goirand z...@debian.org wrote:

 On 08/16/2014 09:07 AM, Brian May wrote:
  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.

 ... or because one of the (build-)dependencies of that package doesn't
 support Python 3.


Yes, missed this reason.

In some cases this happens because the build-dependency is broken/obsolete
and should not be used any more. This can affect the Python2 packages too,
e.g. if there are RC bugs open on the dependency. Some of these
dependencies are optional, and can just be removed. Others may require a
rewrite of upstream code.
-- 
Brian May br...@microcomaustralia.com.au

Re: Standardizing the layout of git packaging repositories

On 08/16/2014 07:59 PM, Raphael Hertzog wrote:
Hi,

On Fri, 15 Aug 2014, Guido Günther wrote:
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).

Some comments on this recommended layout:

Well, I have nothing against derivative/downstream distros, but if
you're about to do a new DEP, please consider Debian first. In such
case, debian/unstable makes a lot more sense than just debian/master.
Like I wrote in another post, master doesn't express anything.

However multiple upstream/* branches can be useful, they should
just match real upstream branches... so things like upstream/master,
upstream/4.8.x, upstream/4.9.x, etc.

All of this is error prone. Using upstream tags and merging them rather
than branches avoid troubles. I have yet to see a case where using
upstream tags wasn't practical.

Right! :)

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/53f023e7.90...@debian.org

systemd service and /etc/default/

2014-08-16 Thread Ludovico Cavedon

Hi,

I am writing a systemd service file for a daemon (ntopng) and I would
like to know what you think is the best way to load some
configuration.

The ntopng daemon takes multiple interfaces in the format of multiple
-i command-line options. For example.
ntopng -i eth0 -i wlan0

Currently the interfaces are stored in /etc/default/ntopng
INTERFACES=eth0 wlan0

and the sysv init script takes care of adding -i for each one of them.

I would like to keep the sysv compatibility and do the same in systemd.

I tried in various ways, but the two solution I could think of are:
1) change the format of INTERFACES to require inclusion of -i.
I.e
INTERFACES=-i eth0 -i wlan0
and use EnvironmentFIle=/etc/default/ntopng. This changes the format,
complicated upgrades, and is more error prone.
2) instead of doing Exec=ntopng, Exec a script that does the mangling
and then execs ntopng.

Because both solutions do not look great to me, and I could not find
an example, I am asking your opinion.

After writing this email, I start to believe 2) is the right way, but
I would appreciate anybody's input.

Thanks,
Ludovico


-- 
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/CAEK95GG0kxxSt3NpWuDzz3gpuMuk+rwM=ke7akv_b0nlzv+...@mail.gmail.com

Accepted last-align 475-1 (source amd64) into unstable

2014-08-16 Thread Charles Plessy

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Aug 2014 15:20:37 +0900
Source: last-align
Binary: last-align
Architecture: source amd64
Version: 475-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Charles Plessy ple...@debian.org
Description:
 last-align - genome-scale comparison of biological sequences
Changes:
 last-align (475-1) unstable; urgency=medium
 .
   * New upstream release.
   * debian/rules:
 - removed compression command, as it is now the default.
 - removed manual page of last-merge-batches.py.
   * debian/control: suggest GNU parallel.
   * debian/README.source: removed as conversion from zip is now automagic.
Checksums-Sha1:
 e33e0c64ac275e0e84ac79941a4b7bb2a0744689 1992 last-align_475-1.dsc
 02bc4460ff9e03d9c28000b8c17db9194036f23a 386147 last-align_475.orig.tar.gz
 32e6c7e9b64bcc791a74bc5a137bb80447315e9f 7596 last-align_475-1.debian.tar.xz
 11f541104b14ed347ee8731dd07e7cbaccd8edf2 455772 last-align_475-1_amd64.deb
Checksums-Sha256:
 d9260c4617c39000f0f28641952388ccba17ef51ef312e766332266f47fcadf7 1992 
last-align_475-1.dsc
 9fb332b53cfe36d867e24ea035b871ee25a835fdef6c43b427a860b6f69bac4b 386147 
last-align_475.orig.tar.gz
 39c104b845975e7775fe849e1385ed8199820b3aa597e99cf24c98a711b96a9f 7596 
last-align_475-1.debian.tar.xz
 929cff7768488f01e308d93eabdc02e286c4b2bd24705b4dec643e0de1afb8a3 455772 
last-align_475-1_amd64.deb
Files:
 b08d5f1ede1bab6e37005a2db14ae2cd 455772 science optional 
last-align_475-1_amd64.deb
 c74d0cc4c0b4d5fece710aec64959477 1992 science optional last-align_475-1.dsc
 7081c02592d1c19c771dfefa0dc5b7db 386147 science optional 
last-align_475.orig.tar.gz
 7dee32cb977f0c97f570e0dfc375de3f 7596 science optional 
last-align_475-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJT7vq2AAoJEMW9bI8ildUCgLMP/12o/XNI5CloZ/Q2zRHOH1fw
9FUFQAsxVIbXmA3buT67gUQH/Q6xMVWfyafAr3D5ABhmdqfYJcrBqZdbmbiHbWu/
a8jWnuB/9VZzW/2p4Ak+ewXj6nUtBsyGuHjRBHpuD+nxeHl5ieBuf9TY9xwiQkZ7
DWiInB8X0SRwQUE3UqjIleEjOwfiMKQWGfIB8vuDuFSQTm9sKEkN9+5AvdU6cjLz
hNqm3Y6iT/r7yXA6RBmfVVXQQVu4Lt/+eBshGou8lmkymTDIC2EBYABmZir3Y/Ks
APntClgUMSnHFSobuFRDs9V58ibsiFUtRG/iaRwROy7+lmitUCTWPHo3X6KuiHx6
09L4vzzwaPprz9sLjO6K9m2Ldfx4DyqK+ZdXnKrgih83sFKx1QfHkjV7gN8Lg6+N
DVg2MoXB/xcAimLnrQsAGg3IDcdxckbcS74PyBO5gZXGj3qZiOud/Uzjh71rO9cL
zWG/6Pe7fF8ITH/neYwoX7Jlqni2lXaslLyglEOfw/BgKns2eFpvdvZ6AvxRD7ad
BIx5/1fRBxe6eQeYGdRE9ESQ9gd+SjymfHOhzooUa+iUw6VNA7Aci7lCquVc5tEi
Phl8WyAG+1YUB2Z7wArntJRW8sBidGi6IVUgrF3MM8J90+27sS1lBXsxcAygHgib
gAKZEipEpbgE6L4jubO/
=o44t
-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/e1xixyl-0007ek...@franck.debian.org

Accepted antpm 1.16-7 (source i386) into unstable

2014-08-16 Thread Kristof Ralovich

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 11 Aug 2014 11:40:58 +0200
Source: antpm
Binary: antpm antpm-dbg
Architecture: source i386
Version: 1.16-7
Distribution: unstable
Urgency: low
Maintainer: Debian running development group 
pkg-running-de...@lists.alioth.debian.org
Changed-By: Kristof Ralovich ralov...@in.tum.de
Description:
 antpm  - ANT+ information retrieval client for Garmin GPS products
 antpm-dbg  - ANT+ information retrieval client for Garmin GPS products
Closes: 757472
Changes:
 antpm (1.16-7) unstable; urgency=low
 .
   * Team upload
 .
   [ RALOVICH, Kristof ]
   * really link against boost_atomic
 Closes: #757472
Checksums-Sha1:
 56e65ca5e2c28cd22a4955e287302439ec9fb45a 2208 antpm_1.16-7.dsc
 18bac0d141eb5e8729db7ff7713e3c8051e925b7 334154 antpm_1.16.orig.tar.gz
 b944b5658ecc2e7a9915e889b27e10d1733784e1 5964 antpm_1.16-7.debian.tar.xz
Checksums-Sha256:
 8c066e76e19d4cdb3069335b3e9bdd217c6e3efe587d962ba8a1d8d0b81b0671 2208 
antpm_1.16-7.dsc
 58e13125e2c0c7644941e7452103fe83c99e4b4936871522d5f616c08fd1a4c7 334154 
antpm_1.16.orig.tar.gz
 69acc2494a07e2aa00ff0d25f72700839224ade1e006d3d301ff5a33e88ef079 5964 
antpm_1.16-7.debian.tar.xz
Files:
 c68017f24f2bb892d21acd8d626fbcae 2208 utils optional antpm_1.16-7.dsc
 d95330605754f164f361e057b2d8a06b 334154 utils optional antpm_1.16.orig.tar.gz
 5794f044e718c78ae93158fcc4adf826 5964 utils optional antpm_1.16-7.debian.tar.xz

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

iQIVAwUBU+8BF4cvcCxNbiWoAQIRDw//SpqQI0dZ2IvLW+ZOTcXWeQg8LIP4vR6E
H9JkJ3BSVVJhpCXbXvOASAce+50nOZhhSgeomArMEb5pGg79C/IBTWifdRx8nLM/
AVsP6fOCiYFeQpKfyxKucUP/WnfEoQbvb+MkVRmwxjxOofyTa+LhJ20WAKphY47T
QrPM7xQf7GAIs98shExIQYOZRkQS/nDcUf+QRpz8RzusR/P5uTyglw0JmAR49qdm
CZbCZED83fyBawEBqr1Dw6+3X6H9LkiKIHuv6eQStO4U6C8GctAOG9YEaYHFBlzZ
zRQeULzVrebqTx0psKZY+pv57NeEH2E+QIeC6zclGz08D5ZuXeevcXCRldSfgNYK
dezA3QqsI9AeurO0p6WLsQI2WtIh/cB0Pan6lCLFYPwg7LiDle69wvP47gLQIDsl
ItKTjbltlDjtpX7CBmslaeTJD8CJNC4eYFihMYa+Jnlc3jmeNKVx+1dwmLNE/ynX
WGLf+z8lgJ7EQkNlAlmU9XuckqayX+v1i6GEoJybkeV/2ifMEqUFXOQfAe2YsLvj
BkwR9C1MWA1wYJAJ8fnb02DYZyEWAifSwQgoz6sDXEysFXLxQx1a8jTVfjc0NifU
W5cYtcOsIuskG/bCUUVn7d1ufsmRnfklFzHI2M4rDrmd+ga48J0Ae+1GDVVcwRRq
0mzLweKHvWA=
=87Ia
-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/e1xiy1p-0002dt...@franck.debian.org

Accepted libsocket-perl 2.015-1 (source amd64) into unstable

2014-08-16 Thread Salvatore Bonaccorso

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Aug 2014 08:42:04 +0200
Source: libsocket-perl
Binary: libsocket-perl
Architecture: source amd64
Version: 2.015-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Salvatore Bonaccorso car...@debian.org
Description:
 libsocket-perl - networking constants and support functions
Changes:
 libsocket-perl (2.015-1) unstable; urgency=medium
 .
   * Team upload.
   * Imported Upstream version 2.015
Checksums-Sha1:
 c37a832427dacd41ae2fee11c4ba372fa6411fc8 2001 libsocket-perl_2.015-1.dsc
 3f7cb86d083b3c1f962fa20afdab17495c5322c5 39970 libsocket-perl_2.015.orig.tar.gz
 6dad5884e84c15c0848c123b55ba296ea3d86609 1980 
libsocket-perl_2.015-1.debian.tar.xz
Checksums-Sha256:
 63b8df392ead07aeb30a3d0f982c7bff2967da1f46b92f2ddc0cad499f1876a1 2001 
libsocket-perl_2.015-1.dsc
 16e34274bd650214b565a8b86c23406f1e0d5a86dc8c64aedd8843ce553875e2 39970 
libsocket-perl_2.015.orig.tar.gz
 a6ea491b9882a7d64137195b8f8dee16cc5c5ee6d3a8e0c14d992cb28954c0d5 1980 
libsocket-perl_2.015-1.debian.tar.xz
Files:
 03d5ceb3c128bd202394826acf7904db 2001 perl optional libsocket-perl_2.015-1.dsc
 d3bde8dd88d760437538541c53847b3c 39970 perl optional 
libsocket-perl_2.015.orig.tar.gz
 2f9f47d707a6419b5642002e2f16e03c 1980 perl optional 
libsocket-perl_2.015-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJT7v3FAAoJEAVMuPMTQ89EcyMP/3c/A2BmAn8Ck+7VrsJJ7e5r
PyvtcLqYLaPqn+eYGOSUd5wQHdHkoS6IWuWn6AE3iLiQA5tH+1XGPhU+2uQWv0mU
TEh+iQT/ZJnI03KKXK8mRAtw8KOD2dHPvK3zDRj/0GtrK9XZhgEKwPNyxWI9FrDV
+g+seDJR1dRMQJuBa79WelYgNvzEYdTWoQce81bjmCuLY+DwO0cK51y98s20/899
DKyWVnItzi6miZm5FZIeKBfepwa7sDX/B4sB1yPk9j0zswgiyEXJBF+sH50v0hDq
bE8rl/K6LOny5pOcPF2Vg9e0IqBn1hRg3EGZedpmjpVod+NxiJo6APhBZjvHTKuo
sT5kiRkP8JYHObCcTn8w+ZIf37D1FPa/vyKEwtROfWo40HlwNUEcUhHSdIkjQt5D
KTnsYP0jNLiD/q73Hfmdna9N+dKhcxhaHUSeO6eZiTVjaTZV0UbOG2ZOTE5sGxrv
JJJjwo38I9AM6cv1qNJY1gnV6ndhUAFDkuzYM6+zi9ko28goHcNIQ9wLRcTKkIAo
4SRG88zDAlvZbRJA75c/EdFJ54KlKcONtPQgz065Th/8ocMVfVHOol1m96hbEgWC
GUaoWF1hyDDTTvYaxJf5ZqDZrHAFj+ere5BAQYi1jrp1v8k8WC1ZdoXdxYGRqjxY
gYDWlmGKrJBjMtAq9fKu
=B9SW
-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/e1xiy2p-0002kd...@franck.debian.org

Accepted wmitime 0.3+20120605-1 (source amd64) into unstable

2014-08-16 Thread Doug Torrance

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 12 Aug 2014 01:27:57 -0500
Source: wmitime
Binary: wmitime
Architecture: source amd64
Version: 0.3+20120605-1
Distribution: unstable
Urgency: medium
Maintainer: Doug Torrance dtorra...@monmouthcollege.edu
Changed-By: Doug Torrance dtorra...@monmouthcollege.edu
Description:
 wmitime- clock dock app showing time and internet time
Closes: 714747 716466
Changes:
 wmitime (0.3+20120605-1) unstable; urgency=medium
 .
   * New upstream version.
   * New maintainer (Closes: #714747).
   * Include manpage rather than creating during build
 - Remove debian/*pod*.
 - Add debian/wmtime.1.
 - Remove man target from debian/rules.
   * debian/control
 - Bump Standards-Version to 3.9.5; no changes required.
 - Update Homepage and Vcs-* fields.
   * debian/copyright
 - Update Upstream-* and Source fields.
 - Remove deprecated X-Comment field.
   * debian/install
 - Remove installation of /usr/bin/wmitime; now installed by 
dh_auto_install.
   * debian/patches/*0-*.patch
 - Update keywords.
   * debian/patches/allow_display_with_no_args.patch
 - Print warning when user runs wmitime -display without an argument instead
   of segfaulting (Closes: #716466).
   * debian/patches/make-install.patch
 - Use DESTDIR when running make install.
 - Create installation directory.
   * debian/rules:
 - Use --sourcedirectory option instead of using overrides to pass -C to
   specify source directory.
 - Remove unnecessary variables.
 - Update override_dh_auto_build to use dh_auto_build instead of MAKE.
   * debian/wmitime.desktop
 - Fill in Generic and Comment fields.
 - Add Keywords field.
Checksums-Sha1:
 88be8cde42e23776df10c62b9efc323f39fd3722 1890 wmitime_0.3+20120605-1.dsc
 2843605420d65c53435c6301b2e3bd0195da6738 21086 wmitime_0.3+20120605.orig.tar.gz
 912cca4df015c36ef690732eea338f7e7d9a2f9d 6908 
wmitime_0.3+20120605-1.debian.tar.xz
 14c025ecf0bb85596b6db87002575c7da4c018a9 18478 wmitime_0.3+20120605-1_amd64.deb
Checksums-Sha256:
 ec8a843658e09551ead7eba7fedd0ec1e867fa64c2765f9c542535e7e34f77c3 1890 
wmitime_0.3+20120605-1.dsc
 c86620e2ec04f8913b0bbd0da62633bcd48632e4ceb9263155ad12d8f2b34429 21086 
wmitime_0.3+20120605.orig.tar.gz
 85135b26416fc970dd43421fd917ac6630ac08aafcfce78d55b2473193388be6 6908 
wmitime_0.3+20120605-1.debian.tar.xz
 e97142f0b46876454f6b210ec12eb298897e72beb5e3c54b8affc7214698f83f 18478 
wmitime_0.3+20120605-1_amd64.deb
Files:
 af79cab7158bdf25834c5f9b9dcd73dd 18478 x11 optional 
wmitime_0.3+20120605-1_amd64.deb
 9f67d7b9ae40dec96e2a4c1e31624e91 1890 x11 optional wmitime_0.3+20120605-1.dsc
 a39ac05b102e83dce73731ad1942058c 21086 x11 optional 
wmitime_0.3+20120605.orig.tar.gz
 54eda8ab445c0f41d1b0751bd2e31b5b 6908 x11 optional 
wmitime_0.3+20120605-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7yalAAoJEHQmOzf1tfkTnjwP/iZxSxM48EsLstfKSDdXGqu0
SkvrkdkJVO3F1R4IUgE9vs8o0AEKPLQdl+1V2AZlvBj0QWRCBUvJ3djnch9pfzzv
/lUSmsxFSuU4p5g2ddtkMX6XFWMjcZJr6Zxdr+jKeMWQWFQN+wyns+sRTnT4CBVb
J3Gy4gykqwqMkbLaCeDWiQqVZ79+EL+tLh+KeofiFY8CnZJxqruk6MOPzILDpCh5
PdcRohKPTOfzdxjKYuIDIxXVlCWf8DiZ/gIOweHU6dP3OXqYlIchkc3g9cEYnKwg
eKxqeWTOT6jU7dJ3tJTWNkL4dEiJLyIU45Qe7dYY5JtCBCTQD2nV6HzRDA9y6jZs
EHYMItfhpGRvnTJZqIQt3mZpaOnLhZf8RxSO4dsfQIJoIwCdaOVEnplYxuQS4gSp
SdMWdB+Xn5Owl0Z+fmMg1SfmYZKbPXEGoHO1jPoA/v7OjEgqzAiMZFzCZ32c/owV
Bu0ZXxCo/M5G3wMN2w7oEBTZu1Up6+h15IjNnz8V/feOmhQl6Q7wjOfRXF3c6fZU
SN8/KQJUOu+2hrit5TQku1rWGR0a2fkSldQA6/MRo05OiLCBhhoVItYHDeks2FZR
/mArXPOkhEt7fYdAqmXrYVJ8vJ3Yxt6KLglrlzcJ7wRjXwGD4caXKPuH359mS0K9
dV4nn7d+kBnZ3437Es/w
=m4h7
-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/e1xiac7-00027a...@franck.debian.org

Accepted sbcl 2:1.2.2-1 (source all) into unstable

2014-08-16 Thread Christoph Egger

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 17:24:32 +0200
Source: sbcl
Binary: sbcl sbcl-doc sbcl-source
Architecture: source all
Version: 2:1.2.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Common Lisp Team 
pkg-common-lisp-de...@lists.alioth.debian.org
Changed-By: Christoph Egger christ...@debian.org
Description:
 sbcl   - Common Lisp compiler and development system
 sbcl-doc   - Documentation for Steel Bank Common Lisp
 sbcl-source - Source code files for SBCL
Changes:
 sbcl (2:1.2.2-1) unstable; urgency=medium
 .
   * New upstream version
   * incompatible change: the #\` (backquote) reader macro was 
reimplemented
 to support robust pretty-printing. Reading a form involving #\` 
produces
 an invocation of the QUASIQUOTE ordinary macro which may contain 
subforms
 that are not lists. Code that unportably attempts operations on
 un-evaluated forms resulting therefrom, e.g.
   (SUBST a b (read-from-string `(x (,y
 might generate incorrect results and/or errors.
   * enhancement: support for GNU/kFreeBSD x86.
   * enhancement: ATOMIC-INCF and ATOMIC-DECF can operate on (CAR x), (CDR 
x)
 and DEFGLOBAL variables of type fixnum.
   * enhancement: arithmetic constant reduction is now performed on 
defconstant
 constants too. (lp#1337069).
   * bug fix: certain ftype proclamations containing optional t rest t no
 longer cause subsequent definitions to signal bogus style-warnings.
   * bug fix: #\Bell and #\Bel now read to different characters. 
(lp#1319452).
   * bug fix: CAS SYMBOL-VALUE on locally special variables didn't work.
 (lp#1098355)
Checksums-Sha1:
 850feb56df314ca9deea3fffaea145eb97458f06 2333 sbcl_1.2.2-1.dsc
 23449d376ac0b6112ad468adc11a5e521667d8fd 4437174 sbcl_1.2.2.orig.tar.bz2
 5b18cf40a2d13f2fc12e4056f6d523a76d074eb0 118004 sbcl_1.2.2-1.debian.tar.xz
 bfb5d3a3b651cb43519f7724a4faa4ff66d3f4f0 1356754 sbcl-doc_1.2.2-1_all.deb
 73e948290323efbb9053f3aadcb5c9d79c52a0a8 2688614 sbcl-source_1.2.2-1_all.deb
Checksums-Sha256:
 e56aefff978db6ef8de1348e78b613018a642628393135b67de0021c7c85ebf6 2333 
sbcl_1.2.2-1.dsc
 5b2c510cdd7300956428c3b9bad78bd730908f6841ff15097e078133e50a5322 4437174 
sbcl_1.2.2.orig.tar.bz2
 44b77706cef8c140091b5d029800d01dab9f2527ee6cea4b82ebff239cde9cda 118004 
sbcl_1.2.2-1.debian.tar.xz
 91f4ff214c0592b2d56da4a228abfaa77d26aadfb5d3c20ab8f41e20070bc452 1356754 
sbcl-doc_1.2.2-1_all.deb
 bfd29b3dfa12b489db8b738f73eadbf181c466f9596514bebf1264dd0de3881e 2688614 
sbcl-source_1.2.2-1_all.deb
Files:
 cdb60b855d35bf16a0567a299e0ae68b 1356754 doc optional sbcl-doc_1.2.2-1_all.deb
 348141aab1ffd3101a0c9764a0102585 2688614 lisp optional 
sbcl-source_1.2.2-1_all.deb
 d19d7f19b84f4ff1df7e31db40daed47 2333 lisp optional sbcl_1.2.2-1.dsc
 729479476e46bb40f054f8a454a0fbde 4437174 lisp optional sbcl_1.2.2.orig.tar.bz2
 26eb9db2c9f1074fe38c6a1c7843da4c 118004 lisp optional 
sbcl_1.2.2-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT7yX+AAoJEKv/7bJACMb5dEIP/AuS5Kym1QWLPJncpu9WJbR6
YwVM/kK0a+CHvEkzwcV0k1ob3B2nBRHT1j1wstXHINcWYE0oqd0nxwhv1H/x7pkk
HG1LL3Q5wzIcD9nDrMNerZyLjZUr3+na5sUHYvIDd7VuZr1GYQcUnhNk2v8S2/Y5
dkWkaN3Qc9k5vMmqbIDSOx56JAxzpiKc25BeYP8ehO9/xLKRdJ4TBc8HMbztD9Xf
srdK+5ER1Z3rIzRyCzHi+dd2cSug3khtKtzo5YPAWQgQKT8a1VPZa8mu+EfChhcS
lrIAP9PY9TA0YaOFuG9RwvuBayQu1XRqQdEOLALV09SrzvRRpxk5YLHwgUsiuJYc
GuEQMnHTLhND8BIejCLMVwMAWvi7H8u5JK9lIFmk2YE6lxqVWx7LDBg8erbNphNy
UODYZGYhC9n+kgFXzprl/sWWojNYpNBJ89evVgUzORVw/beVPH0e1D8bv5PFC5+B
TvNL36vu6JBRWmpXk829t7G2NcEj0Gd+X3lzgeoXg+/zwcRBPVcvGuvm2oMlSdHW
iAaofRstrYh/KQ+JLi5xzSX9VhWMnzXiW7Ualo+LWYZ3IGF0NOkzY6eIuGRD7Xfx
otuLBijCCDx84eiyerd1MP0h43dw9MqBzt0xgriSUKWEqofCIsttOsWxJE7aKMi9
9kvUlyCM1vCJdq+tarma
=39fZ
-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/e1xiac0-00023l...@franck.debian.org

Accepted xfce4-session 4.10.1-8 (source amd64) into unstable

2014-08-16 Thread Yves-Alexis Perez

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Aug 2014 12:48:09 +0200
Source: xfce4-session
Binary: xfce4-session xfce4-session-dbg
Architecture: source amd64
Version: 4.10.1-8
Distribution: unstable
Urgency: medium
Maintainer: Debian Xfce Maintainers pkg-xfce-de...@lists.alioth.debian.org
Changed-By: Yves-Alexis Perez cor...@debian.org
Description:
 xfce4-session - Xfce4 Session Manager
 xfce4-session-dbg - Xfce4 Session Manager (debug symbols)
Closes: 757649
Changes:
 xfce4-session (4.10.1-8) unstable; urgency=medium
 .
   * debian/patches:
 - 02_add-light-locker-to-xflock4 added, add light-locker support to
   xflock4 now that it's in Jessie.  closes: #757649
Checksums-Sha1:
 1610cae1005741060e479aa526cc51f98750b20c 2026 xfce4-session_4.10.1-8.dsc
 6afb183e6a4047c92ab26e9e5143e74cb61d0440 15076 
xfce4-session_4.10.1-8.debian.tar.xz
 35afe91f87722e82eeb7546e990caf365fe76b91 727798 
xfce4-session_4.10.1-8_amd64.deb
 deba9aa88c037343dc81ed452dbbc3d2439c05a7 536180 
xfce4-session-dbg_4.10.1-8_amd64.deb
Checksums-Sha256:
 540908cdfdd766ac4beea4529d32588c56d477d639d2c9c33952b202cbbab560 2026 
xfce4-session_4.10.1-8.dsc
 6c2bc5c90056d9acc127019cc75cdefa65c536b87724cd1b7f76bf6c93b5978c 15076 
xfce4-session_4.10.1-8.debian.tar.xz
 4ca712b39dfabfbf102c8d56551da7c6911f828137094e18ddfbef5a9ce84fcd 727798 
xfce4-session_4.10.1-8_amd64.deb
 28a2af4e4fef8efa62efa0a9595c7092c3d68d850ae8336af91e6aafb67f80c2 536180 
xfce4-session-dbg_4.10.1-8_amd64.deb
Files:
 60b8f77d8448099e45d8d0a001e86b73 727798 xfce optional 
xfce4-session_4.10.1-8_amd64.deb
 a1ccbbbf5348afb3626732fc2763ce99 536180 debug extra 
xfce4-session-dbg_4.10.1-8_amd64.deb
 259b9f4e4fa53d482268ee5bfb78b89f 2026 xfce optional xfce4-session_4.10.1-8.dsc
 b61e142ef7c23b2e019f966656919dd2 15076 xfce optional 
xfce4-session_4.10.1-8.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCgAGBQJT7zeNAAoJEG3bU/KmdcClAsYIAI2A17VzjyloUi8kQpvH+C5k
vLaJ5NuKmEaHgrvvimx8vY9I2RArDTRi8U499T2vo6rNS1giXj23SQCu3JJ0b7yL
6+b2Yldmw2nO4AM17LHoop/xn/6KTGH2RXOe8eNKiAM8IsGmY4eLeGusIVEedjBb
mQNRV60u+oZ8u3wUxnrJB+p9WBrFYPPUOHGfboe2qaLD9pI+3ScvOdpKNQxSPwcC
0dKotd4k5oediPfCKNHvv4pc6uRt/iUKdMpIKeNIDOIqEnsL6TnJ7zp0/gtF5xTO
Qq+MsqIok230wH6eAiCFD0PaDhbfK4mU2Hqqdvu+40KktJfoNXtHWVOuuhmKTcI=
=8+ZI
-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/e1xibmq-0001y7...@franck.debian.org

Accepted onioncat 0.2.2+svn559-2 (source amd64) into unstable

2014-08-16 Thread intrigeri

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Aug 2014 10:51:23 +0200
Source: onioncat
Binary: onioncat
Architecture: source amd64
Version: 0.2.2+svn559-2
Distribution: unstable
Urgency: medium
Maintainer: Anonymity Tools Debian Maintainers 
pkg-anonymity-to...@lists.alioth.debian.org
Changed-By: intrigeri intrig...@debian.org
Description:
 onioncat   - IP-Transparent Tor hidden service connector
Changes:
 onioncat (0.2.2+svn559-2) unstable; urgency=medium
 .
   * Update upstream homepage URL in debian/{control,copyright}.
   * Move maintenance under the umbrella of the Anonymity Tools Debian
 Maintainers team.
   * Specify copyright on debian/* for 2014.
   * Bump debhelper compatibility level to 9.
   * Declare compatibility with Standards-Version 3.9.5 (no change required).
   * Import upstream OpenPGP public key.
   * debian/watch: verify detached OpenPGP signature.
   * Get rid of pre-dh9 hardening bits in debian/rules.
   * 0002-updated-autotools.patch: new patch, cherry-picked from upstream
 SVN r566, that fixes hardening flags support when --enabled-debug is set.
   * Enable all hardening build flags.
Checksums-Sha1:
 9697e189134a62a9854eaf432624af7b3004de07 1998 onioncat_0.2.2+svn559-2.dsc
 f9548195f863f5ce4685ea1740c7af7a186639f9 31488 
onioncat_0.2.2+svn559-2.debian.tar.xz
 ec8eaba326eb56cd7a7e3b5aee2316b56e94a419 49496 
onioncat_0.2.2+svn559-2_amd64.deb
Checksums-Sha256:
 ef5393684b6ae9ac85d2249e67bb8ac2ef28a2039f88d6c18d2c8be5378ac680 1998 
onioncat_0.2.2+svn559-2.dsc
 f1df477e918215903900821f93d026562f87af1d5e46c5f5c2fdaaf054cd4c31 31488 
onioncat_0.2.2+svn559-2.debian.tar.xz
 704c1c0780bf5c23df287c7cabfb523de1abb729e53ab51a1652d9fac71f8521 49496 
onioncat_0.2.2+svn559-2_amd64.deb
Files:
 c79741a22ba5523b642274e48a2dc1bc 49496 comm optional 
onioncat_0.2.2+svn559-2_amd64.deb
 f3bfe3d3102cab2eac3cc01511f107dc 1998 comm optional onioncat_0.2.2+svn559-2.dsc
 1e332ab6cc72035d6b8307ff53c517ba 31488 comm optional 
onioncat_0.2.2+svn559-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJT7zf4AAoJELrOFdKldJj/MGgP/R4W4AxOyprgOIz2EeTQcrTS
GSKCAdTthFmRRgvH6Dfr9vjcddx5ss/VVr8Ih2n9sfoJxQHinUqXZ3Tmm+h4g7lk
yTY5lFxFGm+VQjQVNaXC3YbXqay1uX1l1QIFqUOKHW+eCwsjNm+jU1lbLtRMCwKe
KQxRqAQhpaC0KwLalv4mwjIJsV5RwiC2xDljhaqPQuqCQHDOwvi6seEAY//+0VL5
lEUvs1s34RtyyaDv4iff+nEOgYZmN4rzRSrxGTUwy9MuwTD7JGORD+RX6UUj7VI+
JHqvWwGgtaXc/EvgFN8BGGWNqSFLRhPI3qkJGFbxDKPGctoJ0DOXtd7pxCVYmt0e
4Rl4FiOagKIuTkHklGnvNDuX1iilkMwbLTuanjy2RustnPxhVQV6lXXd65aNLHQN
IlPSZkfmCcQqA+HUmbPIOm7xMGta24FrIalR/nti3nLt/9Na6x2zrtlJ3YNm+s/B
SYoovdxgZcOGwrWxoknP/JaIgI+LrO0rn0fTZNYQRuCppMv/VjiGM0vqmJItpCMd
VKlYhYwHRjveK4hqEMBcKhEy2k/D44fpeOUpUAs85Dp0kdgSNeL/EhdGsO/KqYy/
nzvae6Yr2lxzaSTVx6rklVGb5+iOQsFwk0s3ORy7kX2SoLFUhYCSBgBH+SoKQMKd
MPGErt9sTCi98jUK9nwk
=pzbL
-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/e1xic18-0006pb...@franck.debian.org

Accepted mozilla-gnome-keyring 0.6.11-3 (source amd64) into unstable

2014-08-16 Thread Ximin Luo

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Aug 2014 12:01:35 +0100
Source: mozilla-gnome-keyring
Binary: xul-ext-gnome-keyring
Architecture: source amd64
Version: 0.6.11-3
Distribution: unstable
Urgency: medium
Maintainer: Ximin Luo infini...@pwned.gg
Changed-By: Ximin Luo infini...@pwned.gg
Description:
 xul-ext-gnome-keyring - Store mozilla passwords in GNOME Keyring
Closes: 757933
Changes:
 mozilla-gnome-keyring (0.6.11-3) unstable; urgency=medium
 .
   * Build for iceweasel 31 and icedove 31. (Closes: #757933)
Checksums-Sha1:
 31e8b9ff178c7242ec8f0072d683a9cbf2fe3ff4 2095 
mozilla-gnome-keyring_0.6.11-3.dsc
 a20272df693aa89dda25703bb51e621a39e0e248 3024 
mozilla-gnome-keyring_0.6.11-3.debian.tar.xz
 0884ee15de7cf6765d8819657f077cda9d3bfdeb 50166 
xul-ext-gnome-keyring_0.6.11-3_amd64.deb
Checksums-Sha256:
 7b7c1423e55a5b8e4581e69c7b5c574c3861b2cae47e3407e8713eea6d5acb83 2095 
mozilla-gnome-keyring_0.6.11-3.dsc
 7ceca2a2dfb797df8cbeade3eba8a9ac324c896c11bb8b357851553693ca1784 3024 
mozilla-gnome-keyring_0.6.11-3.debian.tar.xz
 d73374b7d07b38272dfb1b8cf40da3fcad785a38d7978525dbbd54cdd732c0b2 50166 
xul-ext-gnome-keyring_0.6.11-3_amd64.deb
Files:
 e0d6ce2b98bf655ce9c564a8a0c7eb73 50166 web optional 
xul-ext-gnome-keyring_0.6.11-3_amd64.deb
 5a13f57eec777f19d4b738465c3fbe74 2095 web optional 
mozilla-gnome-keyring_0.6.11-3.dsc
 41fe1afde0e682b5e8ce23873c806867 3024 web optional 
mozilla-gnome-keyring_0.6.11-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJT7zqZAAoJEIYN7zuPZQt5HmAQALGh2V+jk9G1Y7Mt14jrAmiD
zjNjzsk0nrNA3rwwlfCx3fsotmKZCfpBjVZVX3v3iqX8snNRogMR5IAnXjeTCmud
ZTH/RDr2yQllYl142lpEvBJW3evr2exnrKu6J/u3iqsbzlLFdvUeeZqK7MO4FGNT
rr/Bn8oG2el2zssewyRhAV4e/dXowEgD932zCbb5h88AEEiy6aNx+XONdiJOsn4r
UzG+BptsBIM8vBBXVeqVj4syDi9oT6rXKeGF1zLgdwvEFMtsZeS7hcZ/QiZg621e
nCwRo5VVa7Au8EqHvQAwd+WyQqMjEL8cVfxcmyd19gHsfM8F5wwFAVAnjXgNU4JB
Ws5zdv2ecVmSOxDNN/trwLQqNldmWZlwJqJbM9FjMTm3zSIY8BIj3G/ipjsFLYtD
jw0ES9PNz+tn9MDpPhayEDNm5/P5JdUPJKC0aG025T/IgOAD5tMMUnIAC11Shghy
hEQFSWcAi8EGiq0o9RDwsKe6BBOzjOGeWqVqGywrNhIux8iqi8+zpx9nI3xJTNcR
N5l4+4zKJp9eOx71w7bji6TJf8mlhxo0VxAm8oAd1W3bSHP3JrkC6T82z43gyRMF
9DGfQ0K5baf8oXEv3YSukfBXN5f9ixPCCEx66Mh3tNYSaP5KsdPS5WYYOfYQdgoU
GA8f5UHWLhBHbm5u2AxA
=XwM2
-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/e1xic12-0006lp...@franck.debian.org

Accepted debian-edu 1.721 (source amd64) into unstable

2014-08-16 Thread Petter Reinholdtsen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 16 Aug 2014 13:09:04 +0200
Source: debian-edu
Binary: education-tasks education-menus education-astronomy education-chemistry 
education-common education-desktop-gnome education-desktop-kde 
education-desktop-lxde education-desktop-mate education-desktop-other 
education-desktop-sugar education-desktop-xfce education-development 
education-electronics education-geography education-graphics education-language 
education-laptop education-logic-games education-main-server 
education-mathematics education-misc education-music education-networked 
education-physics education-services education-standalone education-thin-client 
education-thin-client-server education-workstation
Architecture: source amd64
Version: 1.721
Distribution: unstable
Urgency: medium
Maintainer: Debian Edu Developers debian-...@lists.debian.org
Changed-By: Petter Reinholdtsen p...@debian.org
Description: 
 education-astronomy - Debian Edu astronomy related applications
 education-chemistry - Debian Edu chemistry related applications
 education-common - Debian Edu common packages
 education-desktop-gnome - Debian Edu GNOME desktop applications
 education-desktop-kde - Debian Edu KDE desktop applications
 education-desktop-lxde - Debian Edu LXDE desktop applications
 education-desktop-mate - Debian Edu MATE desktop applications
 education-desktop-other - Debian Edu non-GNOME- and non-KDE-specific desktop 
applications
 education-desktop-sugar - Debian Edu sugar desktop environment
 education-desktop-xfce - Debian Edu Xfce desktop applications
 education-development - Debian Edu software development related educational 
applications
 education-electronics - Debian Edu electronics related applications
 education-geography - Debian Edu applications for geography
 education-graphics - Debian Edu graphics related applications
 education-language - Debian Edu language related educational applications
 education-laptop - Debian Edu laptop packages
 education-logic-games - Debian Edu logic games
 education-main-server - Debian Edu main server packages
 education-mathematics - Debian Edu mathematical applications
 education-menus - Debian Edu menu reorganization
 education-misc - Debian Edu miscellaneous applications for education
 education-music - Debian Edu music and sound applications
 education-networked - Debian Edu networked minimal packages
 education-physics - Debian Edu physics related applications
 education-services - Debian Edu services for educational institutions
 education-standalone - Debian Edu standalone workstation packages
 education-tasks - Debian Edu tasks for tasksel
 education-thin-client - Debian Edu networked thin client packages
 education-thin-client-server - Debian Edu networked thin client server packages
 education-workstation - Debian Edu networked workstation packages
Closes: 722289
Changes: 
 debian-edu (1.721) unstable; urgency=medium
 .
   * Rename ffmpeg to libav-tools in tasks/desktop-other, to match the new
 name of the binary package (Closes: #722289).
   * Remove obsolete openjdk-6-jre and icedtea-6-plugin from 
tasks/desktop-other.
 Depend only on default-jre and icedtea-7-plugin instead.
   * Add lintian override for maintainer-script-empty postrm and preinst
 for education-desktop-mate, like the other desktop metapackages.
   * Replace obsolete myspell-fi with tmispell-voikko to keep a Finnish
 spell checker in the default installation.
   * Switch to 3.0 (native) source format.
   * Update from debhelper version 6 to 9.
Checksums-Sha1: 
 b25c6c5bf6d420001bbea183b3eaeafc9ab931fc 3369 debian-edu_1.721.dsc
 3cbcfedd88a5321c01d2fe0bf495cbddb0c85628 139719 debian-edu_1.721.tar.gz
 0775abe5e4d42c16ed440baae722f96e0ccafc3e 50548 education-tasks_1.721_amd64.deb
 084e69210e7cd3dadb5c95ccdf6913ac642732d0 82936 education-menus_1.721_amd64.deb
 6f8f535f882178b355185d1e8e50d7da9fd6b2ee 48262 
education-astronomy_1.721_amd64.deb
 2875ddd9203d9ecb5f9126048c67e43e6534decb 48252 
education-chemistry_1.721_amd64.deb
 979f058effc32d17ba9fb69cda5b4924cb3ca965 48872 education-common_1.721_amd64.deb
 52634f8994dcaf713bf99e252ed0093d99d70db5 48456 
education-desktop-gnome_1.721_amd64.deb
 e7f5ba0f6bba2a8fb974893e0e32f16d22e9a4f5 48752 
education-desktop-kde_1.721_amd64.deb
 aaea5769b8e100d59499c8799e93429adcf9e5df 48430 
education-desktop-lxde_1.721_amd64.deb
 cf3fc2afb488e28855312a8d36c0ccfd21924de0 48442 
education-desktop-mate_1.721_amd64.deb
 7c33c0db1d1bc00f742e801a416e5497618a59ed 49988 
education-desktop-other_1.721_amd64.deb
 27ac2d2ebce0572c71f1a9617c080a985dd175d9 48592 
education-desktop-sugar_1.721_amd64.deb
 1cea0d1d214ef2b7358a7b74b037cc321d5bf216 48298 
education-desktop-xfce_1.721_amd64.deb
 a279906b7d967827e20875eb437356fb9653b791 48524 
education-development_1.721_amd64.deb
 7dd1546a8808d172019fb50d0c30fe28ef28a3e8 48324 
education-electronics_1.721_amd64.deb
 587fe9f07822edaa045df24f79310e225e3c34d7 48278

Accepted kradio4 4.0.7+git20140816-1 (source amd64 all) into unstable

2014-08-16 Thread Pino Toscano

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 16 Aug 2014 12:49:07 +0200
Source: kradio4
Binary: kradio4 kradio
Architecture: source amd64 all
Version: 4.0.7+git20140816-1
Distribution: unstable
Urgency: medium
Maintainer: Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org
Changed-By: Pino Toscano p...@debian.org
Description:
 kradio - dummy transition package for Wheezy
 kradio4- comfortable radio application for KDE
Closes: 750779
Changes:
 kradio4 (4.0.7+git20140816-1) unstable; urgency=medium
 .
   * New upstream Git snapshot:
 - fix sound playback with Internet radios. (Closes: #750779)
   * Bump Standards-Version to 3.9.5, no changes required.
   * Enable the parallel build.
   * Add myself to Uploaders.
   * Add the libavresample-dev build dependency.
   * Fix removal of empty /usr/sbin.
Checksums-Sha1:
 75b0c555f6e5a62206e42ac8d1a69c9fe347e1b9 1673 kradio4_4.0.7+git20140816-1.dsc
 877f59fd51379d9bbfc4545fecba870d378a5282 1672037 
kradio4_4.0.7+git20140816.orig.tar.bz2
 c027a33e8e630013c90e0c2f308d06d123466f0f 8976 
kradio4_4.0.7+git20140816-1.debian.tar.xz
 a1db815d18877484ec2529ada0e9ff4b6b32b295 1805350 
kradio4_4.0.7+git20140816-1_amd64.deb
 943628783819446cfb0e797157f2d78abd848e2c 21502 
kradio_4.0.7+git20140816-1_all.deb
Checksums-Sha256:
 385bb79e50f2e4606c5f565a7489cb9f7a1780a442e0224d06f11d4b3d4376e3 1673 
kradio4_4.0.7+git20140816-1.dsc
 7226a7c24e0fbca142b7e281596d8267a4ccd2da3980ef7f8d5c8c85ed55a693 1672037 
kradio4_4.0.7+git20140816.orig.tar.bz2
 16c68bf106c208150bb0a28c33e579a2f13d17d0390b4d57ee35de3003a0af70 8976 
kradio4_4.0.7+git20140816-1.debian.tar.xz
 d5f5a2278b8e00e5afedbef1d90d3a5611f38e5a9d6229ece34289a34c213a5e 1805350 
kradio4_4.0.7+git20140816-1_amd64.deb
 69f4b58b171d3e15ad62386f5743b1464334ddd33c028bfcc3f4dc4032e524aa 21502 
kradio_4.0.7+git20140816-1_all.deb
Files:
 1284d32496d20053806952cbf55b7831 1805350 sound optional 
kradio4_4.0.7+git20140816-1_amd64.deb
 ed5d93f72779c2072af6794cdd54a3b5 21502 sound optional 
kradio_4.0.7+git20140816-1_all.deb
 2894460c9da0cef2841a923cbf778cf1 1673 sound optional 
kradio4_4.0.7+git20140816-1.dsc
 6e2dd3d687e045f0aa1028efd09b4930 1672037 sound optional 
kradio4_4.0.7+git20140816.orig.tar.bz2
 87eca1e41c0b93189ee3c96bb3769c98 8976 sound optional 
kradio4_4.0.7+git20140816-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iD8DBQFT7z4STNH2piB/L3oRAudpAKC21a7jQx6n2xuIcQ3z11LidT5tXACg3S1g
dBUvSUuyC0bfKjULSss8SPI=
=BXPt
-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/e1xiceu-00038j...@franck.debian.org

Accepted autodocksuite 4.2.6-1 (source amd64 all) into unstable

2014-08-16 Thread Andreas Tille

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 13 Aug 2014 07:37:23 +0200
Source: autodocksuite
Binary: autodock autogrid autodock-test autogrid-test autodock-getdata
Architecture: source amd64 all
Version: 4.2.6-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:
 autodock   - analysis of ligand binding to protein structure
 autodock-getdata - instructions for getData to collect compounds
 autodock-test - test files for AutoDock
 autogrid   - pre-calculate binding of ligands to their receptor
 autogrid-test - test files for AutoGrid
Changes:
 autodocksuite (4.2.6-1) unstable; urgency=medium
 .
   [ Andreas Tille ]
   * New upstream version (adapt patches)
   * d/copyright: DEP5
   * add autopkgtest
 .
   [ Steffen Moeller ]
   * Weakened build-dependency from csh to csh|c-shell
   * Added link-time compiler optimization (LTO)
Checksums-Sha1:
 bb1b8b99c7d2bfd8cf14cb4da1828c6aeae73116 2422 autodocksuite_4.2.6-1.dsc
 84cc69d93a391544138de138f93a446b48c3f95b 35438010 
autodocksuite_4.2.6.orig.tar.gz
 36af752f8e02ecf27beb5b4d627a929aed389561 11100 
autodocksuite_4.2.6-1.debian.tar.xz
 5e8118e9b28a6b0c420ae5aceaf652ff25e47bdb 156418 autodock_4.2.6-1_amd64.deb
 9bd2d35540ee505ffe906e1a14368814569db109 45672 autogrid_4.2.6-1_amd64.deb
 2d471866618c9270d0393d76dfb5cb238eec49a6 3227388 autodock-test_4.2.6-1_all.deb
 bfb2f5531e2909fea71d8cdbb11693487abf507b 67640 autogrid-test_4.2.6-1_all.deb
 ab44a21316aba368ede0dd1e546341476719b5b2 18500 autodock-getdata_4.2.6-1_all.deb
Checksums-Sha256:
 3b395d14ceaf14d9b44d0d2f95de62152aef8368ac1a7cb7f1228200408155c0 2422 
autodocksuite_4.2.6-1.dsc
 4b24ce4baf216a5e1a6a79bb664eeed684aed17cede64ff0061aa1bcc17874c4 35438010 
autodocksuite_4.2.6.orig.tar.gz
 f5b3aec234bf87e41e7551e1c91ab0b6a2a734d8ce25e5bebb37aa911662ae0e 11100 
autodocksuite_4.2.6-1.debian.tar.xz
 7dfa275f5835deea46890c8abf206b5385ba61b633633d2d0001743c4ac812e0 156418 
autodock_4.2.6-1_amd64.deb
 9e30ffca582e3225e1fdb396767897fdac839d68ed500718d3ca3511473b1dcb 45672 
autogrid_4.2.6-1_amd64.deb
 86b807eee3405e54cad5677ac0fcc8d8d5e8e6721e352d22d8ba0f3b3b493228 3227388 
autodock-test_4.2.6-1_all.deb
 f494ef84f169a5e695d82b7cdd6031580632426dbe660772a00d4e8f8265bbf3 67640 
autogrid-test_4.2.6-1_all.deb
 609839ea6f979370eb6daa3b8ec28c531a1fd4a4cc7b18fb5a52509db57b7b01 18500 
autodock-getdata_4.2.6-1_all.deb
Files:
 c80cfe64da7d3aa496b483ba36f8bbcb 156418 science optional 
autodock_4.2.6-1_amd64.deb
 31bb235d1777c04f220de8ae56164387 45672 science optional 
autogrid_4.2.6-1_amd64.deb
 913f540ef1aa07475a62ccd83fbe766f 3227388 science optional 
autodock-test_4.2.6-1_all.deb
 f4f89d49eeacda7f2acc6877239e4bbf 67640 science optional 
autogrid-test_4.2.6-1_all.deb
 0a8de23577698da5fd4a27e08608bc96 18500 science optional 
autodock-getdata_4.2.6-1_all.deb
 6931975b23461eaab941f82bd5e6aeca 2422 science optional 
autodocksuite_4.2.6-1.dsc
 f4942c8e8c47aca7f3a2ae8794259067 35438010 science optional 
autodocksuite_4.2.6.orig.tar.gz
 68014b6f1233a612e78f578f8b523cdc 11100 science optional 
autodocksuite_4.2.6-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT70eXAAoJEC/YvtrAIO7RYVgP/A0KnHMqA8DVTut9XEF8FwBV
tz84NVQDb3On41i1tqm+ELjtNMvYwViFYrsuCLzwXPbS3f/YTfuuzmF9CoUwDhe8
hVDrApggE9lXzGKusDLdtiGwgaPik2MANDZoPCuLPKM/HDkqRtuK1/ontOfCWXZJ
ZXC+KE59h7NWOxK8FtYnLp/JZS4ibJEq76wqSv8LI60j/e8yaLiJFbs7QGvAHRgJ
8JrNSW8GcMV9dGqNwsVUps7qJlfMFsG0j/4mtdBXJpkmQobN0BphBlU7B0B1L0bk
HIYJD4iXg8ihC1a39v9LNxiW4ii5mIdhygrcnNFYvPXAlrX0UtdUCEpsurmDwY+a
IbczuQbdvkHKKZwZmCMcx5biFiggNtSZRhrOwP7KoVDFPwkLnGv7Bx4+T9nUb/Ea
Jiwi/nfR5qMTEidv3cGRK59QLCyDTXR0xsx5lS3//EJi290M6F7Nyo5vIGAkgkE3
DUDLqfKRPVPkVbvhOasFScXP867Ca6Mm6qq/WSx0N/vJyT/oZHq5WPxE37SP59aY
KZ67mb7yNt9xPsQVSzTfwKfEOygYhK7MbcaZoeZT5oOXfdVwtf74QEEFKvXeMNbs
V1GNpkzSyDM8hIdwyd0lAwIr8SdAQursX8C9GCBcDap2QWSvi/yNJiIaSVjPyIqo
Z2bAIAKwXOLuZlAVHk/Y
=fNek
-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/e1xicwr-0006cm...@franck.debian.org

Accepted mikutter 3.0.5+dfsg-1 (source all) into unstable

2014-08-16 Thread VDR dai

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 21:04:21 +0900
Source: mikutter
Binary: mikutter
Architecture: source all
Version: 3.0.5+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: HIGUCHI Daisuke (VDR dai) d...@debian.org
Changed-By: HIGUCHI Daisuke (VDR dai) d...@debian.org
Description:
 mikutter   - plugin-extensible Twitter client
Changes:
 mikutter (3.0.5+dfsg-1) unstable; urgency=medium
 .
   * New upstream release.
Checksums-Sha1:
 257a8f399cdee738e7cd66d702e230a5682f5f65 1977 mikutter_3.0.5+dfsg-1.dsc
 40ee7453b5623d54af4e5e2e9f2f47e7cd3c50b6 1505272 
mikutter_3.0.5+dfsg.orig.tar.xz
 d77dea7b3914095dc08a029019ac088ef220089e 12116 
mikutter_3.0.5+dfsg-1.debian.tar.xz
 6f24c0c7b301080e6e76902f4ffab9ea6585f68b 1525862 mikutter_3.0.5+dfsg-1_all.deb
Checksums-Sha256:
 100792498746852c7430b3acc5aa635f6c08fc7d343e6420179b39c11a907ece 1977 
mikutter_3.0.5+dfsg-1.dsc
 6b9cd7f8375f58a11093767fad179a76162b61236418bf78abbb662b1da8a019 1505272 
mikutter_3.0.5+dfsg.orig.tar.xz
 84e04483075a9a9595371241543ed33b91e7d0b4426bb4aa9b8efe8d1cda4c76 12116 
mikutter_3.0.5+dfsg-1.debian.tar.xz
 52f1c52d0a103098e39676ae03b7ba4252f61a56f8a60f9b1e4f9f561a4cca44 1525862 
mikutter_3.0.5+dfsg-1_all.deb
Files:
 da594eb62ae1f888617a14dd325d15de 1525862 net optional 
mikutter_3.0.5+dfsg-1_all.deb
 1ebc305b053e2028d764724150cec149 1977 net optional mikutter_3.0.5+dfsg-1.dsc
 52372045a2c9135ce79baa4bf11953b4 1505272 net optional 
mikutter_3.0.5+dfsg.orig.tar.xz
 146ceb5ec53494140a0b0f521c78bb18 12116 net optional 
mikutter_3.0.5+dfsg-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT70nZAAoJEHg5YZ3UOWaOg5MP/jRAa2VCLBNiuoknlfmr3iX7
5Z4SxoQXg9PKCqxUay+q5Uav+nwhkPp0M0pHN0OBibbhEuhq+/ZVzncQgz3968Yv
aBC8NY/djqxDbTaJIGb3Sp0QhMa2buVSbDc4E3XX0cQMqLe9lr4rgzEIrc7o3tZO
8hxa2JHJKE2APohMGF8knPVdl0ZJL1crT0tdPpna0riHogyyKBN4QX5VYZcZ+tVh
0Oe2/qCfOPgGW8YiY2CCjGfdGAlv4rfRbRpdhQvv0PsRf1YFbPOK6bnWTDH+cAzw
UfHD5a3xY0Ooa0opiAQngTyTFzZHy3ogSl1UGOa1v933Nca0Yzm2idP0k9qblfgH
rSBsBvdtRuap0egluhF8UedmsCaUuhKHeWnAk6utvvz90oz/8u8eIcF5HDZrvF9N
JNg1cglkf3mDQXgsLB1HckfiZMpt7eWIvhQ+19kHeofxkU8HisLxYh8+JodvVpr2
02Lz9ECm8bBeAPA+a14e/0VLzNkwuQEOohJuctxhNkSb15A3Vvwo8H8u5ejpxYUn
tLIUGfvHAoWEaJWPgJXPRXAUditYg6kS5Yf4LCAkCMIVe+je7FiyoCoIh91vonoO
26I6YdH54pSi0RAOlGj1ptXkCIvl73ssLoqnZNVv822vPfgvXTQP8aw7rcukPvT6
R/RXIkPUfpLnRV9t7ioi
=V/Fr
-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/e1xicwe-0006es...@franck.debian.org

Accepted lebiniou 3.22-1 (source amd64) into unstable

2014-08-16 Thread Olivier Girondel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 16:04:28 +0200
Source: lebiniou
Binary: lebiniou
Architecture: source amd64
Version: 3.22-1
Distribution: unstable
Urgency: low
Maintainer: Olivier Girondel oliv...@biniou.info
Changed-By: Olivier Girondel oliv...@biniou.info
Description:
 lebiniou   - displays images that evolve with sound
Closes: 758205
Changes:
 lebiniou (3.22-1) unstable; urgency=low
 .
   * New upstream release 3.22.
   * Fix some bugs found with clang.
   * Fix FTBFS against libav11. (Closes: #758205)
Checksums-Sha1:
 1633348fde54b4ef987630696875a7581085e46a 1881 lebiniou_3.22-1.dsc
 7056db6ab946e436f29739d51c10977f48572b67 616570 lebiniou_3.22.orig.tar.gz
 35e53ead95afcd1ddcda9f82647cb1cf8024fd17 3936 lebiniou_3.22-1.debian.tar.xz
 5a1a566630368c9dcadcdd4fab0486bee43d9fd2 292228 lebiniou_3.22-1_amd64.deb
Checksums-Sha256:
 d2ddce97921287a9a717f6896f91aa7d0f810878429add5638ac371d65dc0ec2 1881 
lebiniou_3.22-1.dsc
 29a1bb55fb9a4ed6939c2acf8cfb2d1923255034226feccd8880b115df4d259d 616570 
lebiniou_3.22.orig.tar.gz
 a7df6b3f248c800982b7b5a4efac0181918413498d97fb4b6c94d4dd16b21fde 3936 
lebiniou_3.22-1.debian.tar.xz
 22ead9ae45c16d602b736f392fa5664008e5b3f895e155f65a5a720be69bbd0a 292228 
lebiniou_3.22-1_amd64.deb
Files:
 fbe36f1f056614008d2a8c2a9b9aeac4 292228 graphics extra 
lebiniou_3.22-1_amd64.deb
 4ea24d4cfebba3c5a5bb32c037ccf4ec 1881 graphics extra lebiniou_3.22-1.dsc
 1b084bc973972736f1481512349f550e 616570 graphics extra 
lebiniou_3.22.orig.tar.gz
 ba3768db3677d350b1ce8d5afcdf2d44 3936 graphics extra 
lebiniou_3.22-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT71DdAAoJEGny/FFupxmTpcsQAIFCgHsX2/Qq+WqzGiSgLC6W
k97mBUlKTJQopJyHSe6K9rdsp2kIvZv7OvEUXlZjj/t0nHlTCraYYq+nTgCR7tfi
5VdmC4OmkYJdcX/aUz8i8Hjy9eNnxotcDGq2YXXaxBVudF66umNnexEP1zEXSfTu
xLbE0OH56KT/J2b2fICOfUbSMZLzUx/87yrZ5y8x9SocCv9aiXoGLxDKuo+o79KT
inj6l2hxUC4ei/v55jjY5HpEUcU8St+1b5QekC2hLzBN+YCoovD8CSIa4axG37hN
8gPvJUzSe+uEnXvgbg85Yy1EgOvQa/7q/8QEivsIZlqeHh6oJae/oiHSMDb5hMkk
ieBDYY/oN3LBHhdSsoC14bkVkeWS9naYK3uElKNcV7zjQIyms3rqgfO3UIF0Qn5B
DcO5hEqwtkzkRt4pBJo1Q9n8pBnGKfvJw5arRBdlHzxFU/kaiAMyY2PLjPJavdCH
vnUMVkRoPJRBRI1bxbz58srQWL9dNM2IyfLdYVk/EUqeedyV5kmYp1bib5pdbICb
QWy4nihMoj3PfAozBl0mknhGbUK756feCSxjAH2QhssgUDNOpqh1QVwrUPgRcBsB
fJJ4+sX/c4UoQnAmF11YcicVlpk0c0m+Rw61IF1+B+3LPIpwN92mTkLNxuvShiCP
M/RthAamFS/BUebF/Qc2
=i/xZ
-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/e1xidpk-0001yt...@franck.debian.org

Accepted ruby-rack-google-analytics 1.2.0-1 (source all) into unstable

2014-08-16 Thread Pirate Praveen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 11 Aug 2014 09:09:02 -0400
Source: ruby-rack-google-analytics
Binary: ruby-rack-google-analytics
Architecture: source all
Version: 1.2.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
pkg-ruby-extras-maintain...@lists.alioth.debian.org
Changed-By: Pirate Praveen prav...@debian.org
Description:
 ruby-rack-google-analytics - Simple Rack middleware to inject the Google 
Analytics tracking co
Closes: 751035
Changes:
 ruby-rack-google-analytics (1.2.0-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream release
   * Build-depend on ruby-test-unit (Closes: #751035)
   * Bumped compat, dh to 9
   * Versioned  prettified BDs
Checksums-Sha1:
 e94ca5221f8ebfe3914903a8406cb16dd0fdb6e8 2308 
ruby-rack-google-analytics_1.2.0-1.dsc
 f6fa4de5a65a6a2e810e38951dbde28e6ea21abe 9106 
ruby-rack-google-analytics_1.2.0.orig.tar.gz
 1785cac078f13e41bcb0acc9aa6f771259ce5543 3332 
ruby-rack-google-analytics_1.2.0-1.debian.tar.xz
 75cab9582985562dc4852c81ae71da32d0c90577 7334 
ruby-rack-google-analytics_1.2.0-1_all.deb
Checksums-Sha256:
 448bee0703aec362894ef1e067ccd7f57e661231355ba6ccad9cfe2196eaf0e0 2308 
ruby-rack-google-analytics_1.2.0-1.dsc
 ec936ac993c83e12630d18154b499c666c4d3e2d7306aa3408f916e0f1a5ada3 9106 
ruby-rack-google-analytics_1.2.0.orig.tar.gz
 8fd09c6f702f75b02aee76502b2d0106c5aedd9ea07a3681a805232418a4 3332 
ruby-rack-google-analytics_1.2.0-1.debian.tar.xz
 ad55079298701f4911fcb21f58827e9f17e7c48f542f4607493f3b6bec0551c0 7334 
ruby-rack-google-analytics_1.2.0-1_all.deb
Files:
 8f38a87be1d55c44fa318fd27fa09eda 7334 ruby optional 
ruby-rack-google-analytics_1.2.0-1_all.deb
 4e4bcf33565eb36c5253063c55e57d8f 2308 ruby optional 
ruby-rack-google-analytics_1.2.0-1.dsc
 bf54161d0645e4c23dd11123eb483208 9106 ruby optional 
ruby-rack-google-analytics_1.2.0.orig.tar.gz
 aea2caf8b16eadba72d1efce14e90c89 3332 ruby optional 
ruby-rack-google-analytics_1.2.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT706LAAoJEM4fnGdFEsIqOTsQAI8W75SM9QrSbmHxsV0DhI8N
pO3FUyvwE5XV4yLPwoqXMIxHV/JcdXwgDf35fPi2jCTeLsGAIgSK3rsJHsJPFQgb
Lhpz8sCof7eICecntZj2pXUki0+v+roUgOc6tji7G2VsmixbPGuehozBE1ew/XSU
VDFm7yK+V//eZD3h3Y0cm1TsI+6PCDfHEU90c617pk9vNP/f2OtmnTnjqgcaCd83
SljHvuM52eB6K1TYgcbl+rX+yqCTaU+E2YtIhTdv+LvvHCu/2rc1+xa+VJoGR3BI
6xfJlUZBwS4ehia+7Ui3xRzCz+hVJIcJ/Lphodf27jxXqDRw17rAw2c5E4PcMRKX
BhiwdoiL7koUMWUW49ExTTyaro2nhWkwhfmC/Pkx9CwpVn1akVMznL3cQLQcgArr
CgH7RwO+ueJi4LEnskFoQpOIBeRBuQVcMi8WsIm6KQXhp2t1H87PfHEveWY5BjzD
iyrk9idWBvqanurCi/UCeDq9bHp6wE9pQrZCi7SQJ3X/u5IGkhkuJ+3wpW1QsRXC
nY4CcsDpk2L/ODpSHA6YKAmOM0i0ft4N79PY3KHJWbn14+O1v60mHrSgpLkZ2aAb
MgdQayy80hbhoHfTyPn0Av5/3Cu3TuBdjjMZypGeNyVQWyZtVp+Mj+cQztV6td5A
X8sSyhy8Vk2G8eKQrQYe
=et85
-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/e1xidpt-0001bo...@franck.debian.org

Accepted ruby-rails-autolink 1.1.6-1 (source all) into unstable

2014-08-16 Thread Pirate Praveen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 11 Aug 2014 21:24:55 -0400
Source: ruby-rails-autolink
Binary: ruby-rails-autolink
Architecture: source all
Version: 1.1.6-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
pkg-ruby-extras-maintain...@lists.alioth.debian.org
Changed-By: Pirate Praveen prav...@debian.org
Description:
 ruby-rails-autolink - 'auto_link' method from rails, removed in rails 3.1+
Changes:
 ruby-rails-autolink (1.1.6-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version
   * Revised rails dependencies
   * Revised description
   * Updated copyright
   * Bumped compat, dh to 9
Checksums-Sha1:
 37b1f85fd5cc585835bc4a5c9b61c33773d24814 2147 ruby-rails-autolink_1.1.6-1.dsc
 f28325ab969ad2866fc9e18b7a5cc5a03f97d52e 9916 
ruby-rails-autolink_1.1.6.orig.tar.gz
 260321e6a56733670cbd8d1a588b7bd14a336c50 2700 
ruby-rails-autolink_1.1.6-1.debian.tar.xz
 39fc68f23f3de9a2054c48d56a2a0b9a393fc4d0 6598 
ruby-rails-autolink_1.1.6-1_all.deb
Checksums-Sha256:
 b0285f5c52c6078921bf3489e173c8ab2176b6bf769abb0942ae1606e57949d1 2147 
ruby-rails-autolink_1.1.6-1.dsc
 1d1f113a8e1faf90497768f20effc00ddde4c653f98d744d004aaabc79f44c19 9916 
ruby-rails-autolink_1.1.6.orig.tar.gz
 89217dc29f6db9a10e9a090a94179cbfe17bb132f586c62848ac86015ef648d3 2700 
ruby-rails-autolink_1.1.6-1.debian.tar.xz
 3b15b37fd799e5ac915e4b53c67cbd862ee49b748174b9f0f4ee817304c2015d 6598 
ruby-rails-autolink_1.1.6-1_all.deb
Files:
 f37281576085db5d11ac904bb7c170a0 6598 ruby optional 
ruby-rails-autolink_1.1.6-1_all.deb
 17380738ac23ca2760a4d30dde30527e 2147 ruby optional 
ruby-rails-autolink_1.1.6-1.dsc
 0bf422aca4b7ae51118bb2b713d05dbb 9916 ruby optional 
ruby-rails-autolink_1.1.6.orig.tar.gz
 6afae1d7a11d62c60bbb5bb5b632f428 2700 ruby optional 
ruby-rails-autolink_1.1.6-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT70+zAAoJEM4fnGdFEsIqm+QP/3N00bX7P338NvMytMB5K69T
ub9BwYQR8YSRYXb4qypf2vTeNKQCrnKdLRJvpl12tycx+MIXwxzxyCqvKQhPAnRX
+YJvxcUzKdmVWlPg/NJKb4OFADElzq9PHCQtfbo0QV5CZdVYupVSsmQmQfSbGDLk
HYKhNGUWj3+28n1WpyP/TQUnJXxWxLU7+ZTCItEdu9djyR6AijYCINBb0fX4IUqD
D+FZkle6V7StronYsQ1y+9SJkGN4nNni5R0HDi1cEj6xV+3t6i0aaVBBfQD7TXNC
ONUY/jYjj1m0wji15O4+uFIsCklqZf4thf4PUmDhHKgcag+94NIX3QsuxLixULdC
3wVf7hXJnA0jIegL4e2/ezhSYtBsAPYRpjlRNXosnlNHH6/2pHHS2LJfrvzn5USt
TKV+FYDt3xh0sjta9Mn6OuVp5LvFefNDsnyTjfgZ6UfR/wEy10u7uas79soCBGBI
JTwGJ1Obb0IobICHYDtlMAQJ66ZmjJQXSxpA90dzGfQ6KIGx1zb5xM1ZBKvz/Xrh
VAmtVmT5Zb0as8WEjNL0Zf8PHJFMN9m1ZqEApbQep7xQTDmYuqjLkw2F7lnKQN3i
ey1DCCTIDXwaUIPchtHvasZrXOUacH01pHht1WHZqDUwjl34NJzTwC3fOSsjOcWB
suOd+3sSct6OeXpedd4n
=6NUp
-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/e1xidpa-0001eb...@franck.debian.org

Accepted rygel 0.22.3-1 (source amd64 all) into unstable

2014-08-16 Thread Andreas Henriksson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 16 Aug 2014 14:22:17 +0200
Source: rygel
Binary: rygel rygel-dbg rygel-2.2-dev librygel-core-2.2-2 librygel-server-2.2-2 
librygel-renderer-2.2-2 librygel-renderer-gst-2.2-2 rygel-mediathek 
rygel-tracker rygel-gst-renderer rygel-playbin rygel-gst-launch 
rygel-preferences
Architecture: source amd64 all
Version: 0.22.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Rygel Maintainers ah-ry...@debian.org
Changed-By: Andreas Henriksson andr...@fatal.se
Description:
 librygel-core-2.2-2 - GNOME UPnP/DLNA services - core library
 librygel-renderer-2.2-2 - GNOME UPnP/DLNA services - renderer library
 librygel-renderer-gst-2.2-2 - GNOME UPnP/DLNA services - renderer library
 librygel-server-2.2-2 - GNOME UPnP/DLNA services - server library
 rygel  - GNOME UPnP/DLNA services
 rygel-2.2-dev - GNOME UPnP/DLNA services - plugin development files
 rygel-dbg  - GNOME UPnP/DLNA services
 rygel-gst-launch - GNOME UPnP/DLNA services - gst-launch plugin
 rygel-gst-renderer - transitional dummy package
 rygel-mediathek - GNOME UPnP/DLNA services - Mediathek plugin
 rygel-playbin - GNOME UPnP/DLNA services - GStreamer Media Renderer plugin
 rygel-preferences - GNOME UPnP/DLNA services - preferences tool
 rygel-tracker - GNOME UPnP/DLNA services - Tracker plugin
Changes:
 rygel (0.22.3-1) unstable; urgency=medium
 .
   * Add debian/gbp.conf
   * Imported Upstream version 0.22.3
Checksums-Sha1:
 4e8bd6f359d77c17f9f56d811df3e9eaaaca068a 2548 rygel_0.22.3-1.dsc
 965b223cbb661a95fa16b80b2a600fe93f685627 3373256 rygel_0.22.3.orig.tar.xz
 f8761d56138b756a941a0f292a3d5b5280137a38 10592 rygel_0.22.3-1.debian.tar.xz
 a5a8b9befe55d02f412c14f850b492753d3cc8ba 885316 rygel_0.22.3-1_amd64.deb
 f4f2abf9b9c60c8b01e33aa7b7cfdf9957177f03 2890228 rygel-dbg_0.22.3-1_amd64.deb
 5ab3d3bc6fb69890f21ca849877a95f621aaf583 585814 
rygel-2.2-dev_0.22.3-1_amd64.deb
 77fa79da2bc4d7a0c5b2e6ea092552a7636101c6 522432 
librygel-core-2.2-2_0.22.3-1_amd64.deb
 9fe9428c0cae974028e06e0ab48aac30624d811b 612472 
librygel-server-2.2-2_0.22.3-1_amd64.deb
 d1f89976680d4700b87822f826b089e57b8fa591 490414 
librygel-renderer-2.2-2_0.22.3-1_amd64.deb
 9c6e42331a31cf103da289483c6f1b256f2f43b2 468626 
librygel-renderer-gst-2.2-2_0.22.3-1_amd64.deb
 900453c8e7cfcb986c672810bcc2f1709ce8518b 472774 
rygel-mediathek_0.22.3-1_amd64.deb
 a3b3e688006d1d3fc0fe16319d0d445f99466a8e 505208 
rygel-tracker_0.22.3-1_amd64.deb
 ddbaac72eb072e3aacb68eaf31c319a7552fb6ad 455970 
rygel-gst-renderer_0.22.3-1_all.deb
 d4f4e9f68911f1025fb9c293b74849ac33f92a86 459268 
rygel-playbin_0.22.3-1_amd64.deb
 c03ddf84a43e9dc7bf7238c459aef0a1917e 462712 
rygel-gst-launch_0.22.3-1_amd64.deb
 c78903363e359d9c4686042f97110be598d97483 480076 
rygel-preferences_0.22.3-1_amd64.deb
Checksums-Sha256:
 2038dcd67ec402abec703283dcdf6ebbcbde5d6ce5d26751d3626b793ee29f27 2548 
rygel_0.22.3-1.dsc
 96c272618117aa6c2f6a5edab965f5103d30b52b6742e743dd48274c10c0fddf 3373256 
rygel_0.22.3.orig.tar.xz
 d7da1694d7a401b9e243b6f934999bbe8fb852c622b9d5d7435468f428e4eb27 10592 
rygel_0.22.3-1.debian.tar.xz
 ec462a328aacc14d2e0185c5ffbe0886eb8807a80c933e5f04c435327ef58a28 885316 
rygel_0.22.3-1_amd64.deb
 da0f36e100e3cf6d41eefc278463ed37f79b382eb6018fdd572eab1bed0ff03b 2890228 
rygel-dbg_0.22.3-1_amd64.deb
 1202c582a4081f72b480cc200bb58508bdd6ccd135445c214970851e0373dcd3 585814 
rygel-2.2-dev_0.22.3-1_amd64.deb
 9e705f7275e76b5ac5800894ce896ea76826715c2a20898ee947c3c93c0c9d88 522432 
librygel-core-2.2-2_0.22.3-1_amd64.deb
 3cca8f79ed4116ebaaec783ff34b90a5ed544d3edfe33e8ec292dc7aa01b9c69 612472 
librygel-server-2.2-2_0.22.3-1_amd64.deb
 166baac5fb435ce300fd007c246edbe6e1a422755c6066f3781ef95db6a8b3a7 490414 
librygel-renderer-2.2-2_0.22.3-1_amd64.deb
 d8052449dbe115d033db2bc3f9f90c71ebbd989667a11af9ba7dee9d167b34f1 468626 
librygel-renderer-gst-2.2-2_0.22.3-1_amd64.deb
 34734548613a1e518a32345aa2fce6a8d93c74e9a6dad7cb3cd9cb566941565f 472774 
rygel-mediathek_0.22.3-1_amd64.deb
 c74c03cb4b50237206261374134be7c97a7296202dcb930c774b330bc3e7d829 505208 
rygel-tracker_0.22.3-1_amd64.deb
 99564683836223058569f72ac67894567e11f66c1f6bd0d996367a4bb845fc54 455970 
rygel-gst-renderer_0.22.3-1_all.deb
 ccec8b5d3b2538b46686455cf20699732da858dd0563cf6b25168647e15be953 459268 
rygel-playbin_0.22.3-1_amd64.deb
 9e002a63a70e291533dfb04342c497ac538d22af1b468c12ba4c35b69bc84681 462712 
rygel-gst-launch_0.22.3-1_amd64.deb
 12a891a9fc04ea2b20f1405823157b271cf0fb924c59b8156f3bc4f2511e3326 480076 
rygel-preferences_0.22.3-1_amd64.deb
Files:
 2ab2c727c10c17e782dc192af86f8402 885316 net extra rygel_0.22.3-1_amd64.deb
 a6e39450ba24fc4bf7394fafde84008d 2890228 debug extra 
rygel-dbg_0.22.3-1_amd64.deb
 f70bb7873f6ae5386183b08cd376821e 585814 devel extra 
rygel-2.2-dev_0.22.3-1_amd64.deb
 b39213eed8f318f3ac55744b6c0cad4d 522432 libs extra 
librygel-core-2.2-2_0.22.3-1_amd64.deb
 28e432b13cacf49c862aafac6b49a1c2 612472 libs extra 
librygel-server-2.2-2_0.22.3-1_amd64.deb

Accepted ruby-uglifier 2.5.3-1 (source all) into unstable

2014-08-16 Thread Pirate Praveen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 11 Aug 2014 20:35:02 -0400
Source: ruby-uglifier
Binary: ruby-uglifier
Architecture: source all
Version: 2.5.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
pkg-ruby-extras-maintain...@lists.alioth.debian.org
Changed-By: Pirate Praveen prav...@debian.org
Description:
 ruby-uglifier - Ruby wrapper for UglifyJS JavaScript compressor
Changes:
 ruby-uglifier (2.5.3-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 2.5.3
   * Updated description
Checksums-Sha1:
 7834ab98408ddd34a4e8323d50da994c6a4e4c14 2110 ruby-uglifier_2.5.3-1.dsc
 a2ab1cbf7faeef3fec7edcdff88ebd7e788672af 76138 ruby-uglifier_2.5.3.orig.tar.gz
 f2cafebf7c5b8ae0940c05c33d0dd6d52c176bd2 3296 
ruby-uglifier_2.5.3-1.debian.tar.xz
 8bc48b9cb6f1be034fe33c8727ebbf6f2b007673 61570 ruby-uglifier_2.5.3-1_all.deb
Checksums-Sha256:
 10c1ce43170b4cd08e2de5b10a41946263259c4b374bf8b389cd9cd9ddaf2ace 2110 
ruby-uglifier_2.5.3-1.dsc
 087cd988e994585fced0505525e490e84258ada69a3c9a68e48f6afd477adbb1 76138 
ruby-uglifier_2.5.3.orig.tar.gz
 80dd162767d4ed9a45de96ebd3c6af62f66d3b04afa1e1ba0623a6dc49e6b30f 3296 
ruby-uglifier_2.5.3-1.debian.tar.xz
 843035b2a1dc26458755581562d6809ac639b3dd7ee497f542cb7efee552d960 61570 
ruby-uglifier_2.5.3-1_all.deb
Files:
 04c62d98247d5f8de051a7e8c1b1f916 61570 ruby optional 
ruby-uglifier_2.5.3-1_all.deb
 d2da39abdbb5ec067326f736150d775c 2110 ruby optional ruby-uglifier_2.5.3-1.dsc
 a0d05c3497ec9f67d21e9fe65490692a 76138 ruby optional 
ruby-uglifier_2.5.3.orig.tar.gz
 f5e7e3628421700ca8db3b4b70b1e661 3296 ruby optional 
ruby-uglifier_2.5.3-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT71cAAAoJEM4fnGdFEsIq1IcP/AvxVvcaF4S6IT1DvNal9Pab
KGOp7DgDUkcOf+9gKknf4OsJzGMkhC0EFuQsURdWIqlL2/2/aUf8udN39UZXSAzp
aOj1iEz6YvV7nX1yqAtQrjbAZzyzFtoNcuf20V6iSWkGSFGvwwgyVoo4nO3L1JeF
NbDzCvG0MSOrZvJ8RJ1Gk5tA61zmCaTBBmVPtnXgWN0yJQTRYqtP8auMR67HiHD1
8nzo1WQFj7Zw6vzNrng8Yy1ZIUyxi8tVq+HxiFo4SHyvTyW6GCm8/S9ctPDrq6KB
tV+D32Lk+sWm+pqtYoa//Si5YkZJny0oq3Yhv85Rr3ykv72QKru7aHTjMLGR/HKQ
fMqz/KEnLedCaxPThyO9cMibRqcrKXYmltYVpqVG7DeLlQqxb6zWzvYXoijxBpt9
Vws7q5TGaOg6THVVNRqor65RrTrjGpl+EYsdz9rh0P9E8hfO/sTLcAFyT1Dhokar
ooqUpo8Te/FMwkIyXy2n6LlefjfMJthKwY+00Zn0MiUB1NCOwTc2ZlQLVsmYab+v
IYUnQZKiJW10hJUVrPqcI9ER8irrbw7WoOrlgkfH8alL/XXu4JN8rRsqEIi2SZkw
JaTZoG2YolTBfVQqO2RNg2ESJ1s+AufSzp54/XR4+H6d4kgSBYHYS/mJ/1QYpQRC
v2asRrZzQmfrKfvXjZd0
=i0XY
-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/e1xidsv-0005t0...@franck.debian.org

Accepted libdvdnav 5.0.0-1 (source amd64 all) into unstable

2014-08-16 Thread Reinhard Tartler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 22:52:54 -0400
Source: libdvdnav
Binary: libdvdnav4 libdvdnav-dbg libdvdnav-dev libdvdnav-doc
Architecture: source amd64 all
Version: 5.0.0-1
Distribution: unstable
Urgency: low
Maintainer: Reinhard Tartler siret...@debian.org
Changed-By: Reinhard Tartler siret...@tauware.de
Description:
 libdvdnav-dbg - DVD navigation library (debug)
 libdvdnav-dev - DVD navigation library (development)
 libdvdnav-doc - DVD navigation library (documentation)
 libdvdnav4 - DVD navigation library
Closes: 705379 738811
Changes:
 libdvdnav (5.0.0-1) unstable; urgency=low
 .
   * New upstream release
 - Bugfix:  crashes after source DVD is selected (Closes: #738811)
 - Bugfix: Busy-loop reading main menu for UK release of
   Coco Chanel  Igor Stravinsky (Closes: #705379)
   * Merged all patches, merged upstream
Checksums-Sha1:
 670033cf5559bf54a1c30138f840b67e862b6603 2101 libdvdnav_5.0.0-1.dsc
 9645cd96f02c8fd5796d96f02cb9c6bf3f16606a 354335 libdvdnav_5.0.0.orig.tar.bz2
 2b197222381044c88bf0cae6a2dd3e9e794a21d4 6612 libdvdnav_5.0.0-1.debian.tar.xz
 1c907a42f001631544aecfef9260bd2c5cc4edd0 42936 libdvdnav4_5.0.0-1_amd64.deb
 eefefff40ab92cefcfab5929e2764747d86be541 122780 libdvdnav-dbg_5.0.0-1_amd64.deb
 7adf3d27ebfcda811f5d195cfaae6e1603ad50dd 56284 libdvdnav-dev_5.0.0-1_amd64.deb
 8600f6f0bccbc8e12be265b16f6e3604f0f30760 43390 libdvdnav-doc_5.0.0-1_all.deb
Checksums-Sha256:
 3894d94e0314aadb28082e1283b6bd13cef4eddb4394820d7cb7aed256026e34 2101 
libdvdnav_5.0.0-1.dsc
 058fe641a4535ea3fe3dcfee378d0ca665d3c17d301682b483759057b3d39651 354335 
libdvdnav_5.0.0.orig.tar.bz2
 e6bda011e9d292bbbe91f4a31091921fbe4424e5642f553d345dc7f93dc8b102 6612 
libdvdnav_5.0.0-1.debian.tar.xz
 9d5c9bb722a14aae87bc6d15a2286d07726d993741f609bc9444fd533cc66599 42936 
libdvdnav4_5.0.0-1_amd64.deb
 49897d411b676ceceb714bdeebbcd6fed7c5ff37d03d82ca6a1776944f05c230 122780 
libdvdnav-dbg_5.0.0-1_amd64.deb
 85e23b71cdb6c8693155dd905a73f73b7d9253bf481964cb712f94e18c217b23 56284 
libdvdnav-dev_5.0.0-1_amd64.deb
 a231b1d712f59c4490064ca1f5c303f73a27174c820cebcb4a04c1cdc1d550bc 43390 
libdvdnav-doc_5.0.0-1_all.deb
Files:
 ddac7e2b3e973075c380b7cdc8e5495d 42936 libs optional 
libdvdnav4_5.0.0-1_amd64.deb
 69dac695858d4b9e7c5931261dfe7764 122780 debug extra 
libdvdnav-dbg_5.0.0-1_amd64.deb
 92ff244d000eeaae84de8cc4f7d8cdd4 56284 libdevel optional 
libdvdnav-dev_5.0.0-1_amd64.deb
 905a64fd6cea3f96dc6aa47f11907960 43390 doc optional 
libdvdnav-doc_5.0.0-1_all.deb
 1d4896bf801beddff50f368865b783fe 2101 libs optional libdvdnav_5.0.0-1.dsc
 7af73e8606c7b91bd986ef1b9d6bcb24 354335 libs optional 
libdvdnav_5.0.0.orig.tar.bz2
 de48761c8dce3d751695c42b61b1ff48 6612 libs optional 
libdvdnav_5.0.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCAAGBQJT71vRAAoJEIuAbIZKeKRFo28MAJWMWgCHzsm7CiyJGhSMmRqT
b7cxzq8x3I+GBYO6i48oXKaKV/fMqom7x1iPigG5IWndsnqESOOVRwY1lgza3qWw
Ep4fqKkyMh1AZS0KhYxWljLg++3j8xiw9Vse+Sb6F0Dl0VUCnb6WGaYc2uRjgaKl
3+EVvePFs2PO3zTXj9y2NwPjGdkklUTnd76UE6hr5H+JvqZM6taN6vWqCAUF0L3K
V5UL1TfwcIHopkLh1LmOiKEuoFVsyMxvrAYjDP1XfVDr0F8gA1UI1+XqUxW3VjLF
dLvv0INhbMDYE33XgW26tjB9rxw+YF78C3bEUOuajdiyf2msCPDMcxNMJ2Pm3mq8
jlxWjA6opPTPaXm1IuNT/IjAKd++4XPRoeA7c4gdaCmdNyo3ylcjlBKBLIZHS7hY
RshRl4viurtQmm15R0KSRBZwFJUadXnadwwRFuXxbm93E3cCjFBx5bph6ZdStl/V
3T4JfnntisSZCj0UU6p/Jr41s1T+JU6+qg4DVnu+Qg==
=qpRq
-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/e1xie7i-0007eh...@franck.debian.org

Accepted libdvdread 5.0.0-1 (source amd64) into unstable

2014-08-16 Thread Reinhard Tartler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Aug 2014 22:10:40 -0400
Source: libdvdread
Binary: libdvdread4 libdvdread-dbg libdvdread-dev
Architecture: source amd64
Version: 5.0.0-1
Distribution: unstable
Urgency: medium
Maintainer: Reinhard Tartler siret...@debian.org
Changed-By: Reinhard Tartler siret...@tauware.de
Description:
 libdvdread-dbg - library for reading DVDs (debug)
 libdvdread-dev - library for reading DVDs (development)
 libdvdread4 - library for reading DVDs
Closes: 504256
Changes:
 libdvdread (5.0.0-1) unstable; urgency=medium
 .
   [ Matteo F. Vescovi ]
   * New upstream release
 - debian/patches: patchset re-worked against v4.9.9
   * Imported Upstream version 4.9.9
   * debian/patches: patchset re-worked against v4.9.9
 .
   [ Benjamin Drung ]
   * dvdread-config is gone now.
   * Drop dvdread-config_manpage.patch.
   * DEVELOPMENT-POLICY.txt is gone.
   * debian/rules: Update list of unused files.
   * Add missing pkg-config dependency.
 .
   [ Reinhard Tartler ]
   * Imported Upstream version 5.0.0
 - Fixes libdvdread runs out of memory (LP: #377414)
 - Fixes: libdvdread4 unable to read Wall.e encrypted DVDs (LP: #590983)
 - Fixes: libdvdread: Can't seek to block (LP: #983535, #446664, #1066317)
 - Fixes: Zero check failed in ifo_read.c:904 for pgc-subp_control[i]
  = 0x0001 (LP: #1179913, Closes: #504256)
   * Refresh patches, drop merged patches
Checksums-Sha1:
 92ef4fc79c5324538e7579fa70f26565cd883711 2006 libdvdread_5.0.0-1.dsc
 f1fadbf19fd8d3a9a63ff610ec8ce9021ebc6947 378196 libdvdread_5.0.0.orig.tar.bz2
 52648d47238de03cf96c776ec57b8dc85b679b97 11972 libdvdread_5.0.0-1.debian.tar.xz
 ce286c1afadb451b51a51992c64ad3bf214fe598 77264 libdvdread4_5.0.0-1_amd64.deb
 ee9eeece72319cd37c1851a2ff5aa1d7bcc857e9 136698 
libdvdread-dbg_5.0.0-1_amd64.deb
 8a31eaecae4287995c29e1dc351235cbb68edf7f 90668 libdvdread-dev_5.0.0-1_amd64.deb
Checksums-Sha256:
 b327a1687e8d69730832788eed1b492a3c6e87bba2fe373b8189c74a12841c54 2006 
libdvdread_5.0.0-1.dsc
 66fb1a3a42aa0c56b02547f69c7eb0438c5beeaf21aee2ae2c6aa23ea8305f14 378196 
libdvdread_5.0.0.orig.tar.bz2
 b53130c5a8ea419fe9fff0813256102b74cc3c87803a2d852058e7964dab056a 11972 
libdvdread_5.0.0-1.debian.tar.xz
 5cb3bcefa9b4b2bf6512623acef92adaafb7611e16b76dc0967b034071401acd 77264 
libdvdread4_5.0.0-1_amd64.deb
 fe57049d1a1a639a89ae8e9e90f1ffd2c0534dbb96216edfa15a661fc2c34286 136698 
libdvdread-dbg_5.0.0-1_amd64.deb
 a3bb24e8433fad9bc596326e061387b2877f7f0f6a67c6233cf9608e43d1a282 90668 
libdvdread-dev_5.0.0-1_amd64.deb
Files:
 016414475f32d449989127257c1596b9 77264 libs optional 
libdvdread4_5.0.0-1_amd64.deb
 096e4a80b39c40c0ee799ec0e5d0be5d 136698 debug extra 
libdvdread-dbg_5.0.0-1_amd64.deb
 04b7689be8385d7c805770ac6b22749e 90668 libdevel optional 
libdvdread-dev_5.0.0-1_amd64.deb
 705329100c014f82d240d75d896b4e99 2006 graphics optional libdvdread_5.0.0-1.dsc
 20b964a3fb290b8df45c6b25d37411de 378196 graphics optional 
libdvdread_5.0.0.orig.tar.bz2
 b8cf69c7b7631577b82a77b0e9ebd4e4 11972 graphics optional 
libdvdread_5.0.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQGcBAEBCAAGBQJT71o3AAoJEIuAbIZKeKRFYD4L/2imtZNcDdZqP1/qSSujzMiL
27q/HoQh2Pmt091HEzClPA/2tSzVMgIYPYF9wBxxsBaU/jCV2UiW760gTNQeSgcK
1/r/vK/06XfxVF/Mo9u/eC6pdqffm5jr5YrnSGgZ2qz1mFDlqFOUBq6IomPlxJGi
99zbbXMRVJbooq2pkRHCwQo9GQBN25aDXH5U3y9SMhJcAePNqmUhIs8QV2HzZjEY
Q1Edf0oZG7rpUtEr9wVFbp2lXWAMw8F853MMMwyLugomX9dvhgJ3i41Ah622nXoB
VCx4q+wjrddR5xRxCO1ZspR/gmsVzmRlStGk28pkTI3s6jdQ7E+9yLLbH9kDnU8K
wlJarBqoH2d+wcidK118/A1/mAKmT6Nz7lrZkiz+efV4BmpC73vr+2SpTeBWGDZ+
nm/X67nXC/FN9hLoDNtYvy1s19EGEoPegwvJ2CdtdYRyb+h2ZMD2vW0PRP6y4+Oj
dwckH2yWjizdvICiRLImB+/61q9OIHLTQveNP5W3+g==
=rlyz
-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/e1xie7r-0007ig...@franck.debian.org

Accepted libwfut 0.2.1-3 (source amd64) into unstable

2014-08-16 Thread Tobias Frost

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 12:59:03 +
Source: libwfut
Binary: libwfut-0.2-1 libwfut-0.2-1-dbg libwfut-0.2-dev wfut
Architecture: source amd64
Version: 0.2.1-3
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group packa...@qa.debian.org
Changed-By: Tobias Frost t...@debian.org
Description:
 libwfut-0.2-1 - WorldForge Update Tool (libraries)
 libwfut-0.2-1-dbg - WorldForge Update Tool (debugging libs)
 libwfut-0.2-dev - WorldForge Update Tool (development files)
 wfut   - WorldForge Update Tool (executable)
Closes: 747786
Changes:
 libwfut (0.2.1-3) unstable; urgency=medium
 .
   * QA upload.
   * Setting maintainer to QA-Group
   * add Build-Depends: zlib1g-dev to fix FTBFS (Closes: #747786)
 (Patch from the BTS by Hideki Yamane)
Checksums-Sha1:
 1643fa08b9fc4cabe3999f139bc9993ec029013a 1903 libwfut_0.2.1-3.dsc
 de67d1b9df450d8a3a01ffd498d149b7787787aa 3636 libwfut_0.2.1-3.diff.gz
Checksums-Sha256:
 37a152357cbaeb2774b271e6161914897fbbfd85a6380eee01b223c4d5957967 1903 
libwfut_0.2.1-3.dsc
 61d6fefb07fa58c18ba7094ff4d087ce6e2ed4ccd9f6bf910fd42d9fa8e97ded 3636 
libwfut_0.2.1-3.diff.gz
Files:
 5711745e9c303a4e9e39bac8c77110a5 1903 libs optional libwfut_0.2.1-3.dsc
 059d39d918ea3b0bac3382978806a4cd 3636 libs optional libwfut_0.2.1-3.diff.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT72PuAAoJEJFk+h0XvV02Bf8P/1I/5IdpmyGJKnM6oT/3EB89
Abg3xcf+YvYK7bXeB5vonWTzooWIySwogjuTkQFc5XnNtI2RVbtCIOAmJc+U/Lg0
jMvunfQQnpIsVmf8QUc90g6X4mJSZdt1RmY1oifaHNlsUxoPPGnfH9YZAxGqz7gx
HrOOiUwpafmFpS5hPl0RXv+YIiaHdAhNzb9/olc456eRKft/K9cY3s5Mxo577yem
BUIRA/ocRlmwXifyAfXPIt9mUrmLePSTeLk0nUAqYro3oEMaTkt8DKIJORJ+Rc/N
rBTZ/7q86BZ5dnQ/4yA7nfa4GdPVL2d/2Fu4ahRoB7ixDuA+tUXzPSe25wB3+9Pp
crIbgWRfXTuR8P8ef+eFXEAiA8nP4ewIpa1BA5OJPGqJwPWvk1sMSF/YiRDr7ia3
f26U4W0EBk/Ld3+3ZAA5SFu4OQTl6x3QFQ8/wKcGr8tDKX4dspBriZm0eEIMH9yv
ug0GwA1/h4fUGArElJIRPYMvNhKd4HunV8fHIY+oyZ9O5f66tRI7bhTgqKrB4eTz
UZWN03NAMLOUr+WCFDD1Hf5fqkRgGioVU6ZX+R7k6y74kOHQqaMk+MH8MQXaafHH
1tqnCLs54cjqw02o0MLx7N4BpRYeEI2qHPIGte7ZPF9QiH2hkIyidjJduYu6cHJI
rG7QRIlKYo7k2MKWSuym
=EIVx
-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/e1xifrl-00054x...@franck.debian.org

Accepted tcpdump 4.6.1-3 (source) into unstable

2014-08-16 Thread Romain Francoise

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 17:38:28 +0200
Source: tcpdump
Binary: tcpdump
Architecture: source
Version: 4.6.1-3
Distribution: unstable
Urgency: medium
Maintainer: Romain Francoise rfranco...@debian.org
Changed-By: Romain Francoise rfranco...@debian.org
Description:
 tcpdump- command-line network traffic analyzer
Changes:
 tcpdump (4.6.1-3) unstable; urgency=medium
 .
   * Bump build-dep on libpcap0.8-dev to = 1.5 as the pppoes_id test case
 requires a pcap version that supports PPPoE session ID filtering.
Checksums-Sha1:
 9108b1a24bb9cadc77a44bd36880755f126d6203 1915 tcpdump_4.6.1-3.dsc
 8581ae5bae442d42362bc3b554157bc141010064 11688 tcpdump_4.6.1-3.debian.tar.xz
Checksums-Sha256:
 4655a79a405f4b53bec520be6ecf2b5d03b70e7b7d06d43093537ee4c22123d7 1915 
tcpdump_4.6.1-3.dsc
 6176243d7c80b6f638dbac6d3ba4989e1c64b0198286437a24db62ed8c8b413d 11688 
tcpdump_4.6.1-3.debian.tar.xz
Files:
 ce6f8150ba5a8f63b9c831afffd45f3f 1915 net optional tcpdump_4.6.1-3.dsc
 267a4f7c699a289b411ff97d15c51e94 11688 net optional 
tcpdump_4.6.1-3.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT73wGAAoJEK0V9DXwX5YtWHYP/10PoTe17XJJJset0SuuGrkH
rCnUiTNcFq5qw0dRdzmFDHDZROKpR7ZSO8aZUk1/Ahl5BRJtkVh3nMW0TeCN+9su
X3561+H3tql5ALjeTKsBT4xs9Fg0dOAbk5+5Xk61HDh65I0tGL2kzojPg45ZaKwg
5dtVPGj8s5WgB+c1zoiM+BjzKer3PXlUr1ka1oFuJMAovWwRKFhYDwjIUqsKzh2T
3R4MHiHRL10hjENFmI9QKLd09GWJG8+QuUOTVMDixVL+XaGnDx5BSc6HFXyI3xyE
iVJ7nlBCnUd9YjSHBuI/DJsBGAEgs1rGJgw2KsEuxm90ph4vhmtgBhZFkI1lg4ba
TaEuDNPEF/IGstbON2xiKVIE6kCqyBwN++GyztsqgE5W5Oqcv73Hr36TwTi0TmDx
zyKafMkcD5wys3zMwQbR07JDCeZh9jBvTj0BMDQIWnzifyEXTEzZF+oUF4uei188
HfmwMST0itQABUfjDCK+/XCWt5xYtJTXNRcDXMh5U5qEFoZUKeA4sbHmnm9pQW7D
B5Mc/9aZ+QMzfs24fP2j4pXUGtYenhHOpbESKhnu3xpOdSYaIkhcJPJzZbWtDrEh
K+ad31n8F0JrEw4dMDn1UgGLqowxdkSBw3YpiVM/xWxyizavQ7loEoS1khGkLhvx
j1lmD8/OPd5BeNSzbN85
=pWtk
-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/e1xigdj-00088e...@franck.debian.org

Accepted metastore 1+20080623+debian-4 (source) into unstable

2014-08-16 Thread Romain Francoise

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 18:02:30 +0200
Source: metastore
Binary: metastore
Architecture: source
Version: 1+20080623+debian-4
Distribution: unstable
Urgency: medium
Maintainer: Romain Francoise rfranco...@debian.org
Changed-By: Romain Francoise rfranco...@debian.org
Description:
 metastore  - Store and restore metadata from a filesystem
Changes:
 metastore (1+20080623+debian-4) unstable; urgency=medium
 .
   * Bump Standards-Version to 3.9.5, no changes needed.
   * Set myself as sole maintainer.
   * Mention the word backup in long description (thanks, Eduard Bloch).
Checksums-Sha1:
 39c4b4c22b76b80f62945f989a7e0ef38306366c 1806 metastore_1+20080623+debian-4.dsc
 e51967573c74793efe231c1c82038d57fcd6dc2c 3836 
metastore_1+20080623+debian-4.debian.tar.xz
Checksums-Sha256:
 743dd83a7dd5aa6afb5b5056a7f17f7108336dd011c9603c93495e39938b86ae 1806 
metastore_1+20080623+debian-4.dsc
 249414dd6764ce60a579e872671a011770e17388d29e9d2bb513551d48b9f872 3836 
metastore_1+20080623+debian-4.debian.tar.xz
Files:
 60210c0f2afd6509cb8e93a0527721f4 1806 misc optional 
metastore_1+20080623+debian-4.dsc
 856c5d357dbfb315933f10eb300024e7 3836 misc optional 
metastore_1+20080623+debian-4.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT74FsAAoJEK0V9DXwX5YtRUoP/iEVIA9h2qpJglRHvWCqe+QY
SrvqGW25bXFFZeENohiG0BbHZAQ9dKW0RD6Zoq2qMSvHMbjvKb5phST3BNHdS1/V
RA3954lnih5cQqfq/sFyNPKM1n1diP+UO7uGANXwBZTzRh/Vk97m4/NL8CoLSsPk
gVgxQJxQuYVqcydzM9uPHIxhze9SkYQiWGMsbBUG8fHGCd53UBfLU68k7wg0rNXu
XDfvy6f9gHf12bkqkzoV3dpWzelkhKq4lC5UCSev27ZTJzr5W28CfiYrfCCiEfsX
izreRPQobfP+yZroEkfpflhfMBGW0/18a8dZN3zRixlAPUStgDXuGY3VRWEtAFDs
q5+HmdN2gIRhvAf8p4r1bp7sctvhnZFEseSmvfvWS58dLfPibbhkIuoQLXH/rztw
bJb4j3wiZCvFKaF4bCl8S4nqXgx8AjVEIYY4WCGNUwbuxQ6ZdguWh2lYUq4yV5Tw
3yqlD4lvHZsZL/8n9/cSxyd0mvRwxPFwiuXKhP8HytfMQ1YLt96pwW7B62UUeBoo
w2nJj4YEp3j7Y3D2JDHOB/EnJbI2iax0NK06iVQpnfxy3ApmBf6XT0GolD8WpkmX
3WiMp86bbNnQ7JoZr2fffXs2NQC05s6o2kUf6uLoSQ7+vmOCG7YC5CGZO+m57bxb
OZSpFVO4wQ+94oyHwc7V
=BLOf
-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/e1xigha-0003is...@franck.debian.org

Accepted rpy2 2.4.3-1 (source i386) into unstable

2014-08-16 Thread Dirk Eddelbuettel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 16 Aug 2014 10:57:56 -0500
Source: rpy2
Binary: python-rpy2
Architecture: source i386
Version: 2.4.3-1
Distribution: unstable
Urgency: low
Maintainer: Dirk Eddelbuettel e...@debian.org
Changed-By: Dirk Eddelbuettel e...@debian.org
Description:
 python-rpy2 - Python interface to the GNU R language and environment (version 2
Changes:
 rpy2 (2.4.3-1) unstable; urgency=low
 .
   * New upstream release
 .
   * debian/control: Set (Build-)Depends: to current R version
Checksums-Sha1:
 d3ff0d86a4de623bd9ee54fd702ab799b8de6805 1269 rpy2_2.4.3-1.dsc
 4e9c6ea5cc79224296b66fae48d61a387287f333 159655 rpy2_2.4.3.orig.tar.gz
 1e66bab3ed3bb65acd240690a0fad77d5728afc4 13209 rpy2_2.4.3-1.diff.gz
 8068abb46a512b7992f3ad76c790d4a3df535261 133754 python-rpy2_2.4.3-1_i386.deb
Checksums-Sha256:
 032610de8256ca29b48b7d906d26553c966a80ab0437ba949e25a32bc27d529f 1269 
rpy2_2.4.3-1.dsc
 1d7970d1723d52c4bbd510ee88c0a6b8273a3bba8a05c124fb8be35d75616906 159655 
rpy2_2.4.3.orig.tar.gz
 31f0155e1d8659670a5f4139b17163f0a68e58ae3ace4c768906b2dd692759d4 13209 
rpy2_2.4.3-1.diff.gz
 3d0893064078b40da5def3d2a7f57c2f5a2e48b8f3a325ec2403028c7ea0e8f1 133754 
python-rpy2_2.4.3-1_i386.deb
Files:
 7d531756cd0511c49d0ed2a4389cb2f8 133754 python optional 
python-rpy2_2.4.3-1_i386.deb
 b32f304a210dd2289418ed8cb6ed62e0 1269 python optional rpy2_2.4.3-1.dsc
 57e3fda409226dffb543c913c8553cdc 159655 python optional rpy2_2.4.3.orig.tar.gz
 abe3dd01d13e2bb436008e0095c3daac 13209 python optional rpy2_2.4.3-1.diff.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iD8DBQFT74DFCZSR95Gw07cRArOvAJ9+Dd9OkUyNGYPsowmaY/pdRzYxcACcD1fr
dO5d8hTZY5Z3lp5YwO9p9mE=
=6VfN
-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/e1xighj-0003lm...@franck.debian.org

Accepted maitreya 7.0.7-1 (source i386 all) into unstable

2014-08-16 Thread Jaldhar H. Vyas

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 14 Aug 2014 00:39:46 -0500
Source: maitreya
Binary: maitreya fonts-maitreya
Architecture: source i386 all
Version: 7.0.7-1
Distribution: unstable
Urgency: medium
Maintainer: Paul Elliott pelli...@blackpatchpanel.com
Changed-By: Jaldhar H. Vyas jald...@debian.org
Description:
 fonts-maitreya - Astrological font for Maitreya
 maitreya   - Software for Vedic and western astrology
Closes: 749974
Changes:
 maitreya (7.0.7-1) unstable; urgency=medium
 .
   * upgrade to release 7.0.7 (Closes: 749974)
   * undo NDEBUG hack
Checksums-Sha1:
 9243df55900753b8528602ed70badae117f1341f 1415 maitreya_7.0.7-1.dsc
 737a5ef7c8037f9be74f867c2547ca330749a28d 7904437 maitreya_7.0.7.orig.tar.bz2
 8f719e06a585f39dbe4e0d60e49e565130789823 17028 maitreya_7.0.7-1.debian.tar.xz
 3f09fa345ccf4b8a193b8eca55b0278f7d6d67f2 6543456 maitreya_7.0.7-1_i386.deb
 f91ad1d4d5d3b5142f5a41b7786f1337a0c7c697 20048 fonts-maitreya_7.0.7-1_all.deb
Checksums-Sha256:
 7cfeb9a619ffb7230ae1a037f462e9c6ba7b52066cbb95750dcb2ab85e09fc59 1415 
maitreya_7.0.7-1.dsc
 83a3414ab071958d1eb12768c36936074588c6eea87c4c35bb264f1602a589cc 7904437 
maitreya_7.0.7.orig.tar.bz2
 d3a50741898486b2cd4d458dadd6afe9284715a9947a8a9b30d0338992b3f836 17028 
maitreya_7.0.7-1.debian.tar.xz
 9ea84641bc6cf435d5d66f75f1b73130ccc589917911f652e72693378da52c1e 6543456 
maitreya_7.0.7-1_i386.deb
 d75ea80c61f80118812aa7c2759e547b9912408a4e79c66b4764c9296ee6478c 20048 
fonts-maitreya_7.0.7-1_all.deb
Files:
 066a9877e607179465753240015e1e1f 6543456 misc extra maitreya_7.0.7-1_i386.deb
 4dd0cf270eb9f7f40a5ac2dc7dd6848a 20048 misc extra 
fonts-maitreya_7.0.7-1_all.deb
 1130b809b485e144489d0f863fd4ee0f 1415 misc extra maitreya_7.0.7-1.dsc
 cd5295e0f977d234d907b44911a3638b 7904437 misc extra maitreya_7.0.7.orig.tar.bz2
 5904d46b60b881de27925f1953716250 17028 misc extra 
maitreya_7.0.7-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlPvhJEACgkQ2kYOR+5txmp5vACgoYjVFxAtoubWulAUX6IfYw55
3dMAnihQlaSsA1vZf48YCXauHjRea5yO
=S+hb
-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/e1xihbv-0008dg...@franck.debian.org

Accepted visitors 0.7-10 (source) into unstable

2014-08-16 Thread Romain Francoise

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 18:11:22 +0200
Source: visitors
Binary: visitors
Architecture: source
Version: 0.7-10
Distribution: unstable
Urgency: low
Maintainer: Romain Francoise rfranco...@debian.org
Changed-By: Romain Francoise rfranco...@debian.org
Description:
 visitors   - fast web server log analyzer
Changes:
 visitors (0.7-10) unstable; urgency=low
 .
   * Use canonical locations in Vcs-* fields.
   * Bump Standards-Version to 3.9.5.
Checksums-Sha1:
 b956c980180446e4eb1990f60ce72be4334e1573 1855 visitors_0.7-10.dsc
 4d33d8d2afade4685e4cc6f2f7dec00b656cd90e 4068 visitors_0.7-10.debian.tar.xz
Checksums-Sha256:
 00b244c357094295116034d90817047345f6675b1b10a46f549b7e3250be89fa 1855 
visitors_0.7-10.dsc
 05248a944cd11a71dc86e422338cd6fc9a9e5ce962833c3c2c18b4d138bbc05e 4068 
visitors_0.7-10.debian.tar.xz
Files:
 3b53d9852f6be4d19460c02dadb9bdcb 1855 web optional visitors_0.7-10.dsc
 16db88f631e2e60b2f5ee6a52af56c01 4068 web optional 
visitors_0.7-10.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT74O6AAoJEK0V9DXwX5YthQwP/0l2rm/3dFun9ogzdjLmE9QJ
uvOrBhUXgmS1P+RJrKwlMo8saG8TJ3Dw7qI82S0bzu+d/wSecu3Xqslbh492Ykat
t/JfsCtpdkOKdJs3aoX5a0rKzA+4o1VNyH91Xn3R7aAduXkoPn3Adutn/10aepf/
zkszeslMK5O022ovazPKMbDeb4Pwxn8mk400lUmhkVf/0LlCX/0YTYUZDFgK/ORT
raRAUxXYhf32pDuLtC6qZE5jZjgKt6wT3+uf2bgJCzEoFam06TV+q6OVq6h8Zjr6
wOcSEAFMKsPNftzlkogqWcxw3kBd83lmO84GPXY3g06/Gwx7mbI47wNd2YNHHlWL
p8U8JD0yPMl88u0n+vpSdQaY5OMC0WF7duBLejmxQ5vPe0k2IARrD+QVb2XvqUF8
iSAJy8f2c6hO+kztthteorVsrSyq7y/RGN1SD03hh4rmqpeN3MKn04xAkrv9z+0B
CgGx5X7vfoUOcWIM4YL6GXcBxr0w3HlCvkiz0DllNu4LdorYahfefedREjmdw0FD
YWsd7tx2sO0aMrGTWRcXsRJK6VfXiR4cR+Gh0D43Ye24QPlAdWkB3vrzu4JRWLzl
RL6gHRA+tSNQ0HdsF4RS2gi08Dkd+57YdUyFgay3wSzlevJsJecN785liG4pMvpr
2cexiCJnGDYLQqH5TbKb
=qimu
-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/e1xihck-0008lf...@franck.debian.org

Accepted codelite 6.0.1+dfsg-1 (source amd64) into unstable

2014-08-16 Thread James Cowgill

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 09:41:47 +0100
Source: codelite
Binary: codelite codelite-plugins
Architecture: source amd64
Version: 6.0.1+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: James Cowgill james...@cowgill.org.uk
Changed-By: James Cowgill james...@cowgill.org.uk
Description:
 codelite   - Powerful and lightweight C/C++ IDE
 codelite-plugins - Powerful and lightweight C/C++ IDE - plugins
Closes: 749976
Changes:
 codelite (6.0.1+dfsg-1) unstable; urgency=medium
 .
   * Upload to unstable (Closes: #749976).
   * Drop gcc 4.9 workaround (fixed in wxwidgets)
   * Drop manual dependency on lldb (see #750868).
   * Re-enable lldb on mips.
   * Remove uses of PATH_MAX for hurd.
Checksums-Sha1:
 f787c9f69339ac0e55e464a8a47b7528582e1ca5 2128 codelite_6.0.1+dfsg-1.dsc
 58c93d6711ed8c98765c672754c9c1743fd2a52e 6908025 
codelite_6.0.1+dfsg.orig.tar.gz
 ba24a90674d3e2e3be0ae3ae5377898afe121b44 21032 
codelite_6.0.1+dfsg-1.debian.tar.xz
 07648fc9d2d79cdbbf8f18d646a53ad9e370eb58 4384116 
codelite_6.0.1+dfsg-1_amd64.deb
 8c68c5a950c9d7954f74346e41dc10cdcd8690d0 2431810 
codelite-plugins_6.0.1+dfsg-1_amd64.deb
Checksums-Sha256:
 c99fe4ff7011ec73cf009eacf078ce47c174caef98e84e455cc0e11692ad7124 2128 
codelite_6.0.1+dfsg-1.dsc
 ea1c40173c3488e68cdf0351b03f81f004581a35a5256c3c432f7d0ef34b7c68 6908025 
codelite_6.0.1+dfsg.orig.tar.gz
 efbb4d700d98085279a5875bceace70ded9679081c7175e3ecdf88e169780fc8 21032 
codelite_6.0.1+dfsg-1.debian.tar.xz
 4d37ef5e165f08dae3182f9772322841c3c2e7d7d3c31f046e0ceca3f5f9f1bd 4384116 
codelite_6.0.1+dfsg-1_amd64.deb
 3691e3726ae872ebf880431253317dc2fbd29063d668b57a91fe4a4fcf0b75bf 2431810 
codelite-plugins_6.0.1+dfsg-1_amd64.deb
Files:
 d8641e990c3df3dd7ff1c423e4f75b37 4384116 devel optional 
codelite_6.0.1+dfsg-1_amd64.deb
 3b15d10974f64d2cb4ecd9b0ab74a36a 2431810 devel optional 
codelite-plugins_6.0.1+dfsg-1_amd64.deb
 e9bd4c9c64c3956cad91217756e8869c 2128 devel optional codelite_6.0.1+dfsg-1.dsc
 9889206a7398f332321b8de9856f7ac8 6908025 devel optional 
codelite_6.0.1+dfsg.orig.tar.gz
 46541cf474f210b29bee7a40cd893d7d 21032 devel optional 
codelite_6.0.1+dfsg-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT74vAAAoJEHQmOzf1tfkTVz8QAJnv4+4nZy+H45YQgs5/6XzM
KJJLqj7J3mRkfmvEEqvCy76jt3FEOGJU21JzlG1PRNkjI2ATcpCDyCLTpQzJw4Nj
WKeSuNwyz406HYE00xmS9uYOusEmbQgoX4+7SsZ8QJfcpqozAa/d/5lENbr/r9Cd
u87fKlXJ9lsriNIRPyc5dWhABLPzfnhZC9Z+4u+n4GQoGumgxsDTfLjtt48IFvkq
p9kHmvxRhD3al80EWzF4hs6RJrqDWTuh8O4IqoJTCNEJvQI7P1bHgEyaNze8G6J7
nw22fwkstlV5q5nUPhkHw2O9/DRHjkoF2nhHrZ+6C2hUezLYwoR3vNzfuYf4d6WG
+AwSSqK4ckcOjhQREaleUtR3UMaX3e8o99n8mZgMsOWGtFn/sWEvTqyFmBwLaT82
hC7yDD6i4kI5rhN5gYGM7mBuZzM8V9EVxJ35X0rHvt/kqdEVLhSXnj+A5FNQ0hFe
i7DNPgAKgWSMLWd2WqAC6Ka2sjaHDEcfzoPNQoewCE3SDmN4vEkX6xgWsTmrHLFV
Ai3kxRqOYArOOkQU3coTAOMiTeaxtvFNDyetGa6gJTM670S8+xQkKYNKttjSuFwu
TEAshmsy4cKXrSW4LR6LKgLZsQ6fOupaYWxcxaVkyQGbBYmF4shb9SMFoPZ3OA32
60iu0TOQB4qiIzFZT4eV
=5WMi
-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/e1xihcz-0003o2...@franck.debian.org

Accepted pulseaudio 5.0-9 (source) into experimental

2014-08-16 Thread Felipe Sateler

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 13:01:43 -0400
Source: pulseaudio
Binary: pulseaudio pulseaudio-dbg pulseaudio-utils pulseaudio-utils-dbg 
pulseaudio-esound-compat pulseaudio-esound-compat-dbg 
pulseaudio-module-zeroconf pulseaudio-module-zeroconf-dbg 
pulseaudio-module-jack pulseaudio-module-jack-dbg pulseaudio-module-lirc 
pulseaudio-module-lirc-dbg pulseaudio-module-gconf pulseaudio-module-gconf-dbg 
pulseaudio-module-raop pulseaudio-module-raop-dbg pulseaudio-module-bluetooth 
pulseaudio-module-bluetooth-dbg pulseaudio-module-x11 pulseaudio-module-x11-dbg 
libpulse0 libpulse0-dbg libpulse-mainloop-glib0 libpulse-mainloop-glib0-dbg 
libpulse-dev libpulsedsp libpulsedsp-dbg
Architecture: source
Version: 5.0-9
Distribution: experimental
Urgency: medium
Maintainer: Pulseaudio maintenance team 
pkg-pulseaudio-de...@lists.alioth.debian.org
Changed-By: Felipe Sateler fsate...@debian.org
Description:
 libpulse-dev - PulseAudio client development headers and libraries
 libpulse-mainloop-glib0 - PulseAudio client libraries (glib support)
 libpulse-mainloop-glib0-dbg - PulseAudio client libraries (glib support) 
(debugging symbols)
 libpulse0  - PulseAudio client libraries
 libpulse0-dbg - PulseAudio client libraries (debugging symbols)
 libpulsedsp - PulseAudio OSS pre-load library
 libpulsedsp-dbg - PulseAudio OSS pre-load library detached debugging symbols
 pulseaudio - PulseAudio sound server
 pulseaudio-dbg - PulseAudio sound server (debugging symbols)
 pulseaudio-esound-compat - PulseAudio ESD compatibility layer
 pulseaudio-esound-compat-dbg - PulseAudio ESD compatibility layer (debugging 
symbols)
 pulseaudio-module-bluetooth - Bluetooth module for PulseAudio sound server
 pulseaudio-module-bluetooth-dbg - Bluetooth module for PulseAudio sound server 
(debugging symbols)
 pulseaudio-module-gconf - GConf module for PulseAudio sound server
 pulseaudio-module-gconf-dbg - GConf module for PulseAudio sound server 
(debugging symbols)
 pulseaudio-module-jack - jackd modules for PulseAudio sound server
 pulseaudio-module-jack-dbg - jackd modules for PulseAudio sound server 
(debugging symbols)
 pulseaudio-module-lirc - lirc module for PulseAudio sound server
 pulseaudio-module-lirc-dbg - lirc module for PulseAudio sound server 
(debugging symbols)
 pulseaudio-module-raop - RAOP module for PulseAudio sound server
 pulseaudio-module-raop-dbg - RAOP module for PulseAudio sound server 
(debugging symbols)
 pulseaudio-module-x11 - X11 module for PulseAudio sound server
 pulseaudio-module-x11-dbg - X11 module for PulseAudio sound server (debugging 
symbols)
 pulseaudio-module-zeroconf - Zeroconf module for PulseAudio sound server
 pulseaudio-module-zeroconf-dbg - Zeroconf module for PulseAudio sound server 
(debugging symbols)
 pulseaudio-utils - Command line tools for the PulseAudio sound server
 pulseaudio-utils-dbg - PulseAudio command line tools (debugging symbols)
Changes:
 pulseaudio (5.0-9) experimental; urgency=medium
 .
   * More patches from upstream for kFreeBSD
Checksums-Sha1:
 f3b9e36917b65494eda0639ca340e645016a2a3d 4690 pulseaudio_5.0-9.dsc
 230ac01d62a8d1e4f1588a6b47cc92cf8d7c88f0 38080 pulseaudio_5.0-9.debian.tar.xz
Checksums-Sha256:
 1a4fb6285b5c1c63f28dd1e72ab20a5eba4edf9f2826b96535b2921a1d23f14f 4690 
pulseaudio_5.0-9.dsc
 5e5d440013f9d59865e4b83805e8f7be3d3b0b55c3ff2cf1bad9852e22a6cfab 38080 
pulseaudio_5.0-9.debian.tar.xz
Files:
 056af8be91de151fbf9a1bb36edc2327 4690 sound optional pulseaudio_5.0-9.dsc
 5150b1751f3096c96b1fe2bf4fac91d2 38080 sound optional 
pulseaudio_5.0-9.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT746iAAoJEKO6uuJAjdbPQ3QP/iU7p5C/4QZdkwSQddCLrjyC
5GcYhwB67gaoz0B4fKNT1p6PaXoNyvY1GTo/9xRlqewGb7GXogpQRhfPr/oNkIPg
/XzCl5O9MJUTuNddZUubsip+l4jIUeY6nSnBttOlVq6pq6yhOxefMdq69Fqtixxp
pwa4e2uO2H4ASHgmgUkXh5G66Ew+yAuyaZvWM9+b4Cct/RFo4Fai//UMYtsHwmUN
dNbwXPMVUVpV6hI5yAushh7cFvHPdlBw8P84VvyURbUWZHOSfPy69hERxBvAqdWo
i0GZIFJ8U7oXzUWPuISEKfMBlkCHr0M+4FK11142iIhb4YzHZaPMDSykXU50dRmS
xdJFklgLRT/wBUw4IDLTDq2zTO/D3kiu7DjhDggc9cByR5GKl1VdmyqeumweYYzu
RlUmdWnN/TDh+unujsHPcNktUsevtVKATJMuyh9rDy1kCgWuFJ5cO84FhV/k/+5h
hZU6Nj7YIFhVTGmh6ZAvAACeLWww8GMHAZQ+5V/KInr7ki0Uon/mf5SGwYoaXrgZ
cKqs25XBjD0p5l+oNAOIs8QlimBlBCKEf7Jf0ZyYavQNlP9IPUsDAUdFGDp582XM
Tgcjnes/CD3BBvVbG8Wqy4478J0uLAV4ITuQtZoz8RKXhTeaf7SQKZvrmhMSHTEk
mn2ttKi65qFe0MVlSivp
=h8AM
-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/e1xihdl-0003rn...@franck.debian.org

Accepted network-manager 0.9.10.0-1.1 (source amd64) into unstable

2014-08-16 Thread Micah Anderson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 11 Aug 2014 12:08:31 -0400
Source: network-manager
Binary: network-manager network-manager-dev libnm-glib4 libnm-glib-dev 
libnm-glib-vpn1 libnm-glib-vpn-dev libnm-util2 libnm-util-dev 
network-manager-dbg gir1.2-networkmanager-1.0
Architecture: source amd64
Version: 0.9.10.0-1.1
Distribution: unstable
Urgency: medium
Maintainer: Utopia Maintenance Team 
pkg-utopia-maintain...@lists.alioth.debian.org
Changed-By: Micah Anderson mi...@debian.org
Description:
 gir1.2-networkmanager-1.0 - GObject introspection data for NetworkManager
 libnm-glib-dev - network management framework (GLib interface)
 libnm-glib-vpn-dev - network management framework (GLib interface)
 libnm-glib-vpn1 - network management framework (GLib VPN shared library)
 libnm-glib4 - network management framework (GLib shared library)
 libnm-util-dev - network management framework (development files)
 libnm-util2 - network management framework (shared library)
 network-manager - network management framework (daemon and userspace tools)
 network-manager-dbg - network management framework (debugging symbols)
 network-manager-dev - network management framework (development files)
Closes: 755015
Changes:
 network-manager (0.9.10.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Pull patch from upstream to fix checks for default
 routes (Closes: #755015)
Checksums-Sha1:
 5f61333ffdb1b31ba2569c1acd332e482a49c39c 3520 network-manager_0.9.10.0-1.1.dsc
 b9f012bd35e8a1e71e44653151c944ca8de4b03e 37052 
network-manager_0.9.10.0-1.1.debian.tar.xz
 8f902390dd812c6d848c1cef24ebc167b14acea3 1430818 
network-manager_0.9.10.0-1.1_amd64.deb
 bef2d68b53cd0e07db4302f581bcaf93a61998e2 286576 
network-manager-dev_0.9.10.0-1.1_amd64.deb
 2825cefabe23149bc4a69c6aa865bf27cda9a41d 315554 
libnm-glib4_0.9.10.0-1.1_amd64.deb
 71ed8d07b5fba15ab549a19138ebae52ab3389ea 427116 
libnm-glib-dev_0.9.10.0-1.1_amd64.deb
 579a0ac3547b35e6c6b4188736a5a1e2399efdd4 244238 
libnm-glib-vpn1_0.9.10.0-1.1_amd64.deb
 34424aead82d6c9f9b6f5a6379e6e39db4128299 235848 
libnm-glib-vpn-dev_0.9.10.0-1.1_amd64.deb
 c7fa65e43550cd7d2b6eab337cf6140c17449b90 363410 
libnm-util2_0.9.10.0-1.1_amd64.deb
 239a30653e9f7e043fd21e3d7315c116ef8a6def 420736 
libnm-util-dev_0.9.10.0-1.1_amd64.deb
 4f410223da8c65d4c7d8efbbdb4c83bbde4cdefa 2877748 
network-manager-dbg_0.9.10.0-1.1_amd64.deb
 68797f7c0ed26cae847af1a675c6b2cc47e7706a 269108 
gir1.2-networkmanager-1.0_0.9.10.0-1.1_amd64.deb
Checksums-Sha256:
 0227cffa377c0434b4c88deff6c83d84671ee892072805ab36253f27b53ad7ed 3520 
network-manager_0.9.10.0-1.1.dsc
 9a2b52410d3f230ee203292149d83a529b2d788c7520aa6a36d380d15d21dbbe 37052 
network-manager_0.9.10.0-1.1.debian.tar.xz
 c00d66698fbc8be856c7439841160aadeccfde41f690668a2f461399b47cf0d0 1430818 
network-manager_0.9.10.0-1.1_amd64.deb
 54c33deab659efec39efbee18487d022933c9283a34a16afc54bab9b35d512be 286576 
network-manager-dev_0.9.10.0-1.1_amd64.deb
 c58b5519f5e4dc11a90ed381b3e06a8ca4812e7d93f204855c662fe6baa27e31 315554 
libnm-glib4_0.9.10.0-1.1_amd64.deb
 33607855805d42000d69b907114865072966ef2db486e1b09b263b47bad166d1 427116 
libnm-glib-dev_0.9.10.0-1.1_amd64.deb
 3057ac7c2ece6e624977caa9b92013082a29804f649e957c3c90da6e3637fcf7 244238 
libnm-glib-vpn1_0.9.10.0-1.1_amd64.deb
 ec4ee450be5f734eb1d0d48aab60a1af4064308fa0c1a4b51b73dd1e133787f5 235848 
libnm-glib-vpn-dev_0.9.10.0-1.1_amd64.deb
 ab4d11d0b0831c2a55119b7111057acfa57d03f6b6eadd8be78321518f019729 363410 
libnm-util2_0.9.10.0-1.1_amd64.deb
 7367e593b40026c72167ba2d1fcc616f11f5f320bc6eb71115ea7ef55de10a9f 420736 
libnm-util-dev_0.9.10.0-1.1_amd64.deb
 8c66f652ce8c7ec5d44a95803d89db666c98cbc6627affdd40536125848c6dce 2877748 
network-manager-dbg_0.9.10.0-1.1_amd64.deb
 6d185fcf5814d0bd9658dd5853db1bd59c749713180d1711c39ac4e7f408eb4e 269108 
gir1.2-networkmanager-1.0_0.9.10.0-1.1_amd64.deb
Files:
 666c11b479c327af1f8d99d6efd75a46 1430818 net optional 
network-manager_0.9.10.0-1.1_amd64.deb
 80d30afe9602d413b9b4a225e7cdfcbf 286576 devel optional 
network-manager-dev_0.9.10.0-1.1_amd64.deb
 42c6a7c3e338df82062f003125b952b0 315554 libs optional 
libnm-glib4_0.9.10.0-1.1_amd64.deb
 57a719ffbf446dd6d2fde153733d2401 427116 libdevel optional 
libnm-glib-dev_0.9.10.0-1.1_amd64.deb
 df04103948c4e3edc54b38c05e408913 244238 libs optional 
libnm-glib-vpn1_0.9.10.0-1.1_amd64.deb
 aa4f64ed94614bfa31ddb8d7411c2ae3 235848 libdevel optional 
libnm-glib-vpn-dev_0.9.10.0-1.1_amd64.deb
 3f0f8d167005ae100064285ff9be2fc2 363410 libs optional 
libnm-util2_0.9.10.0-1.1_amd64.deb
 29a81e12fe8e1ec3153e0f338a836668 420736 libdevel optional 
libnm-util-dev_0.9.10.0-1.1_amd64.deb
 12f137f72ed805a6ee45fc3e03d7c44a 2877748 debug extra 
network-manager-dbg_0.9.10.0-1.1_amd64.deb
 ccab49fb7426ac2afa6eb5415afbd67f 269108 introspection optional 
gir1.2-networkmanager-1.0_0.9.10.0-1.1_amd64.deb
 9a678a7af2027ec53dd8689470a18db1 3520 net optional 
network-manager_0.9.10.0-1.1.dsc

Accepted adequate 0.12.1 (source all) into unstable

2014-08-16 Thread Jakub Wilk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 19:07:55 +0200
Source: adequate
Binary: adequate
Architecture: source all
Version: 0.12.1
Distribution: unstable
Urgency: medium
Maintainer: Jakub Wilk jw...@debian.org
Changed-By: Jakub Wilk jw...@debian.org
Description:
 adequate   - Debian package quality testing tool
Closes: 758306
Changes:
 adequate (0.12.1) unstable; urgency=medium
 .
   * Fix “keys/push on reference is experimental” warnings (closes: #758306).
 Thanks to Axel Beckert for the bug report.
Checksums-Sha1:
 f98976145241be378cebac9c00a4f6afc79d9447 1603 adequate_0.12.1.dsc
 5dc69aa3f85070d975d315695bb5f77c96ae1c48 30902 adequate_0.12.1.tar.gz
 4f7cf206f5ba2ebd48987f5f036530b3a2bedd3f 23880 adequate_0.12.1_all.deb
Checksums-Sha256:
 4fd03876f961a2a0d0a1dc80f4ef9efca511e9e7cbbefb753f8022a81d8c0c87 1603 
adequate_0.12.1.dsc
 209a4e8eb448b0b36258b81e4bd1bced97cb030938aea50b132f0d58247cea3c 30902 
adequate_0.12.1.tar.gz
 bdd16755c7a6dc8d1778fcb9860ced6038baf3dfe0332ab5762b56063f0401d4 23880 
adequate_0.12.1_all.deb
Files:
 5d4d67789d9e2d96972a62bb3f9a5037 23880 utils optional adequate_0.12.1_all.deb
 3f75a98e9106954d95c8608b206a1235 1603 utils optional adequate_0.12.1.dsc
 c94408eca1d83f4d79862f77dd262a45 30902 utils optional adequate_0.12.1.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT75DTAAoJEC1Os6YBVHX13ZUP/R24wxfW2UwvMu8M2CkulSbM
gFaxIFEFEQJ0UG+4QfF+5H8nsqweUw5/rJ7Vvpf+5QN1YnIY7y85MIkjw+oknH2Q
dP+ZlHHcHCEy8QVL2LJtGnNixDeBEZ6tJX8jnhM3uiSk3ht2ZzBzH/7JbPttU1IR
msJnXJV/h4KxJqVN724bGYatFV18h+aQDCIn6jHAH9jykLiGHMfJHks1aguxqgn9
c9qDYBbVDIjilSrCRbEDD0A3hX2j7shu2xVb5kBDNQ22actW7QeIgkjYVMxESk+8
T0Qbo+7rtNyqxbPAlssq1C14jjZqJFaBqgTSpd5x0WI9QcixMs7UbfxXeC5QG3rY
U2HZzyQJl7rAWsq38l8fLUgyOa/GAoPDoEM4LpAk2R/dRNgrh7aZhwzmqWzKRTzT
PmGQ7Gj9PKQYxKLHpL4iH6Ey2Re0flV7i0d97rS0TDXD7ov8Gp0S08O/an0VF/7Z
MfNzLu4dACXDrj1JDf1hIqnJyr1E6+SKSawfmhGXjEYuxNC7a4cIkKSq8VIHHCmM
3adZjdMtWSB0FXvRXNmOY4qdYKYC5+Aw961q9zd7EZmCBOq6zSEEb7FWuc/e9s/j
Eiy8ZZFdeeFxqYFHLHDcfjjdZ3REOZ4b0Hbni8151k0hgGMOhk3JzA0lQfvqVmEh
NW5EZLYiIaoleXdS/NQk
=goC/
-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/e1xii5c-0007on...@franck.debian.org

Accepted car 2.0-21-1 (source all) into unstable

2014-08-16 Thread Dirk Eddelbuettel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 16 Aug 2014 12:51:44 -0500
Source: car
Binary: r-cran-car
Architecture: source all
Version: 2.0-21-1
Distribution: unstable
Urgency: low
Maintainer: Dirk Eddelbuettel e...@debian.org
Changed-By: Dirk Eddelbuettel e...@debian.org
Description:
 r-cran-car - GNU R Companion to Applied Regression by John Fox
Changes:
 car (2.0-21-1) unstable; urgency=low
 .
   * New upstream release
 .
   * debian/control: Set Build-Depends: to current R version
Checksums-Sha1:
 40386ef1ff0b69eaf9590427cbc6fee6d3acbad4 1027 car_2.0-21-1.dsc
 652306045419fadd2c2733f50ac4065f7d28b92e 584149 car_2.0-21.orig.tar.gz
 94e756b84db252a196c8ce975505d342daa85c73 3460 car_2.0-21-1.diff.gz
 c9de31670562e8e08541f908d6f1918d7d9371e8 1330498 r-cran-car_2.0-21-1_all.deb
Checksums-Sha256:
 afc02aec1cdb9ed5d4eac4dbe38eeca1e26ff2d628dd495740217e76daf14595 1027 
car_2.0-21-1.dsc
 efd7610fe27f93cc329da48e578ac6692a8e1b719fdc804002105ded3f5fcddc 584149 
car_2.0-21.orig.tar.gz
 3b783c3764675bef876640d2d7fcc69371971a944e3b390d1c66ceec90e849e5 3460 
car_2.0-21-1.diff.gz
 7844efcc6b539ecd6b0c4865bde36d096d5cd9e2a151cdfd73db0d0a7e85d828 1330498 
r-cran-car_2.0-21-1_all.deb
Files:
 7e80a925dd873184ed6cf314d7007088 1330498 gnu-r optional 
r-cran-car_2.0-21-1_all.deb
 1f66f047a604d2e0a1ee357e6b08c3bd 1027 gnu-r optional car_2.0-21-1.dsc
 e2069e153c61f1aa9c8d4f8a17e7681a 584149 gnu-r optional car_2.0-21.orig.tar.gz
 6cf7fd1dcfc41a6d3bb7aba1d2ac93af 3460 gnu-r optional car_2.0-21-1.diff.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iD8DBQFT75qGCZSR95Gw07cRAnkBAJ9l33x0qoBP0iEBRIZ4F2yARNQB7ACffl6H
HQtxYbxWi05fTXr/OO4H7zw=
=22mk
-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/e1xiik7-00014j...@franck.debian.org

Accepted pspp 0.8.3-1.1 (source i386) into unstable

2014-08-16 Thread Ben Pfaff

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 09:41:42 -0700
Source: pspp
Binary: pspp
Architecture: source i386
Version: 0.8.3-1.1
Distribution: unstable
Urgency: low
Maintainer: Friedrich Beckmann friedrich.beckm...@gmx.de
Changed-By: Ben Pfaff pfaff...@debian.org
Description:
 pspp   - Statistical analysis tool
Changes:
 pspp (0.8.3-1.1) unstable; urgency=low
 .
   * debian/rules: Dump testsuite.log to stdout on failure to make
 autobuilder test failures easier to debug.
Checksums-Sha1:
 4333c2364705ffc2b2e9b0f0794a1bbe45613fdc 2068 pspp_0.8.3-1.1.dsc
 803a6896f4a8e1be57852bdb541943ce95369ce9 24848 pspp_0.8.3-1.1.debian.tar.xz
 ad085425a9d2ee36845fbcffa692c00f6d980574 3456348 pspp_0.8.3-1.1_i386.deb
Checksums-Sha256:
 f81e5d5a4cf8d49cefbcf0bf73b9135b5c9d03703d1d240413ea70669b7169dc 2068 
pspp_0.8.3-1.1.dsc
 08f1507ce54b130b3e0d5e760681bf41de8f0b934e1e154ff8deee35a75b1bc3 24848 
pspp_0.8.3-1.1.debian.tar.xz
 0b55f6dad3877d2f9d0202c6617ab418c3cbdd52b6d05c0ecdca97b37bfa20d5 3456348 
pspp_0.8.3-1.1_i386.deb
Files:
 c2be3e117a1db63962ebda26891eadfe 3456348 math optional pspp_0.8.3-1.1_i386.deb
 aaa871133d7e496f90e7f32d47f520e9 2068 math optional pspp_0.8.3-1.1.dsc
 23b2703496792fa3924c948d0a24dd8a 24848 math optional 
pspp_0.8.3-1.1.debian.tar.xz

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

iQIcBAEBCAAGBQJT757IAAoJEIUZnejGZI6Q15IQAJ5tXIrwb5KzBSIMj+RgXKl8
7uX5C2q1k94kODfQTXSInD7S1YEEFDIYPLIbpOOVgaaslL7sj10Ip3D4UwdDoVil
rP9LSqMe35h71Tf1vcpy+3AdhMNVrMdLsrymLPcnJcga6xv/p+ofayCEPF4tcZAR
7Qa6xfduVN7zlR5LCkIiDSStx6+g9BuaosSdFVMWiKtGSvmuD6d0vH0Iu+FEXyC0
HZESOFeDWuArx13zXmL/LKffQexMcMp9o7loCPPFqsjpDZACKPUFaOrnbL/TYFZn
mzDs9lOtPmV1Ti6/gkvEZy6K2zTXkw4m+O+ssFd7+23FLuINjMoUksz5tgb6aD1a
pXf9wVUducj9EGeY5Qj/ikEWc4IsdmV619KGtEkPuypaeBMSMXNpIrpT8K46UEmf
d4wBVfmRPH3GL+OZnLjRyGPbybJk3HGABqB0M46WahI/+naL6sxcvg+/MJnKYWy4
UcDK2QFJLauVetgkprgjLr31rnNXAowcjHitthPQ8Z+WxZEbpUoszOlsTXmqiDG7
oAHNKls8D9pTQ5TeCwVQl+kFut59iBDGql5bB6Fa4vvnzDC5vFcsrf/dtJxBu9Ef
ljBoVWht7LdFeNqBXnqRJA9jEzXpPGX7BlBou0bCMKWn0FD3acgrhprRkxX8hyMj
317jVTtbRtoN/GSZcOTs
=lvPx
-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/e1xiiyp-0003b7...@franck.debian.org

Accepted gpsd 3.10+dev3~d6b65b48-3 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 21:02:49 +0200
Source: gpsd
Binary: gpsd gpsd-dbg gpsd-clients python-gps libgps21 libgps-dev libqgpsmm21 
libqgpsmm-dev
Architecture: source amd64
Version: 3.10+dev3~d6b65b48-3
Distribution: unstable
Urgency: medium
Maintainer: Bernd Zeimetz b...@debian.org
Changed-By: Bernd Zeimetz b...@debian.org
Description:
 gpsd   - Global Positioning System - daemon
 gpsd-clients - Global Positioning System - clients
 gpsd-dbg   - Global Positioning System - debugging symbols
 libgps-dev - Global Positioning System - development files
 libgps21   - Global Positioning System - library
 libqgpsmm-dev - Global Positioning System - Qt wrapper for libgps (development)
 libqgpsmm21 - Global Positioning System - Qt wrapper for libgps
 python-gps - Global Positioning System - Python libraries
Closes: 550964 696020 741186 751746
Changes:
 gpsd (3.10+dev3~d6b65b48-3) unstable; urgency=medium
 .
   * [95fcff8b] Add patch to fix PPS with large offsets.
 Taken from Fedora.
 Thanks to Miroslav Lichvar mlich...@redhat.com
   * [27452a76] Use the Debian package version as gpsd revision.
   * [aca85fbe] Add full systemd hotplug and gpsd options support.
 gpsdctl.service idea taken from Fedora.
 Default gpsd.service file enhanced to read options from
 /etc/default/gpsd.
 Thanks to Miroslav Lichvar, Eduard Bloch (Closes: #741186)
   * [72a6a4af] Disable hotplugging of ftdi/pl2302 usbserial adapters.
 These adapters are too common to hit them with the gpsd hotplug script.
 (Closes: #550964, #696020)
   * [e60cdd47] Remove start/stop options from dh_installinit.
 insserv handles boot ordering these days.
 Thanks to Paul Wise (Closes: #751746)
   * [5ed9e35e] Run dh_systemd_* on the gpsd package only.
 Also start gpsd.service only, not gpsdctl.service.
   * [0e50ca3a] Remove hardening-includes.
 dpkg-buildflags ships the appropriate hardening flags.
   * [631b275e] Listen on ipv4 and ipv6.
Checksums-Sha1:
 4a875929ce527831242d99187649271b14136a40 2619 gpsd_3.10+dev3~d6b65b48-3.dsc
 58416ff209b3ee2775a3d133a18244c5dae53e63 34284 
gpsd_3.10+dev3~d6b65b48-3.debian.tar.xz
 734cdfc5f49278dffb8245b2c2bb1caa12d40325 95056 
gpsd_3.10+dev3~d6b65b48-3_amd64.deb
 bbdecfe186d998c229940112a308f4a5d20d0cfb 1340216 
gpsd-dbg_3.10+dev3~d6b65b48-3_amd64.deb
 286cd212cb2a058e9d234557e6dd7dc9b82d5baa 135526 
gpsd-clients_3.10+dev3~d6b65b48-3_amd64.deb
 0e977df719229dfc158d770e5d7c9c313b2a3560 95910 
python-gps_3.10+dev3~d6b65b48-3_amd64.deb
 4d2321e596cc33ff4f12920f8a971944d8474481 219870 
libgps21_3.10+dev3~d6b65b48-3_amd64.deb
 37fef06e7671babb50bda390a6be25182a3f2141 131504 
libgps-dev_3.10+dev3~d6b65b48-3_amd64.deb
 4a08bef3cc9d0139a290480c31f76f947d70a8aa 91372 
libqgpsmm21_3.10+dev3~d6b65b48-3_amd64.deb
 9677fb3a5f72ef3ad22f93369ed97112c6e3288b 43344 
libqgpsmm-dev_3.10+dev3~d6b65b48-3_amd64.deb
Checksums-Sha256:
 3d220660254df2e4073747e573c8e751a6109be0df98681f67342ffd9f20a351 2619 
gpsd_3.10+dev3~d6b65b48-3.dsc
 56970f96add257839d116133a1d9d813fa3bf41dc82f8baa89b3afa6a58634a1 34284 
gpsd_3.10+dev3~d6b65b48-3.debian.tar.xz
 eb4cc0e38e2a8bb39a1688559b4c44522a043d193c93725007dff3e1ecaf2004 95056 
gpsd_3.10+dev3~d6b65b48-3_amd64.deb
 3298967a4b8c625eb610a83ea044b87a9dab631812b092bd8da25ee58e171090 1340216 
gpsd-dbg_3.10+dev3~d6b65b48-3_amd64.deb
 34feb93b3bd42215b3317db226f6e8e68850948669de15fd4498114ce1e7cbf7 135526 
gpsd-clients_3.10+dev3~d6b65b48-3_amd64.deb
 b02ae8f46affc3bb7117a4818caab6dbeb032d14a4a1ef8662cdd4b8184814c8 95910 
python-gps_3.10+dev3~d6b65b48-3_amd64.deb
 4cbb74f8cd0a2c8004f3f9df2ab916b72aeab0733ecde62f1fa30120fb77f99e 219870 
libgps21_3.10+dev3~d6b65b48-3_amd64.deb
 4056e813aaf2600a59239cb5124aea40b161bee998e324d3403086aa1c283dc2 131504 
libgps-dev_3.10+dev3~d6b65b48-3_amd64.deb
 d3487971e26de7226011ed36a7adb8c65e8dce4eedc99cf59a1e65c6f47fc42e 91372 
libqgpsmm21_3.10+dev3~d6b65b48-3_amd64.deb
 a2e7d97a6130c40e60ab404bf21963cfbb7fb68c6dcdc1a855022b8e79b4f431 43344 
libqgpsmm-dev_3.10+dev3~d6b65b48-3_amd64.deb
Files:
 78f90c359353c9883dc3a78ca9eb8c06 95056 misc optional 
gpsd_3.10+dev3~d6b65b48-3_amd64.deb
 04b7c62fd32fc89d1a552d9f5a181227 1340216 debug extra 
gpsd-dbg_3.10+dev3~d6b65b48-3_amd64.deb
 eb42d7225736332c14b7902fc2c3bcd3 135526 misc optional 
gpsd-clients_3.10+dev3~d6b65b48-3_amd64.deb
 31120d0037eb7fcffcc41aaa76fec3df 95910 python optional 
python-gps_3.10+dev3~d6b65b48-3_amd64.deb
 5cb8f69f9bf0c9f5c3ca7196e88a7439 219870 libs optional 
libgps21_3.10+dev3~d6b65b48-3_amd64.deb
 1ec55083800e1912b4e87751cca1055c 131504 libdevel optional 
libgps-dev_3.10+dev3~d6b65b48-3_amd64.deb
 010c57f8e0181cfad7a91a45caeb8144 91372 libs optional 
libqgpsmm21_3.10+dev3~d6b65b48-3_amd64.deb
 1e50dc78af37d557cb9ca3384c291c64 43344 libdevel optional 
libqgpsmm-dev_3.10+dev3~d6b65b48-3_amd64.deb
 a943b8184c6dc991c97cdc60ca2559d5 2619 misc optional 
gpsd_3.10+dev3~d6b65b48-3.dsc

Accepted sslh 1.16-1 (source amd64) into unstable

2014-08-16 Thread Guillaume Delacour

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 07 Aug 2014 00:06:06 +0200
Source: sslh
Binary: sslh
Architecture: source amd64
Version: 1.16-1
Distribution: unstable
Urgency: medium
Maintainer: Guillaume Delacour g...@iroqwa.org
Changed-By: Guillaume Delacour g...@iroqwa.org
Description:
 sslh   - Applicative protocol multiplexer
Closes: 740560
Changes:
 sslh (1.16-1) unstable; urgency=medium
 .
   * New upstream release: fix some startup problem when interfaces are not
 ready at boot time (IP_FREEBIND support when available) and can use libcap
 for transparent mode
   * Enable libcap and libwrap support at build time
   * Enable dpkg-buildflags: Drop hardening-wrapper Build-Depends and use
 DEB_BUILD_HARDENING instead of DEB_BUILD_MAINT_OPTIONS
   * Remove old .gitignore as upstream has one too
   * debian/sslh.tmpfile: Create /run/sslh for systemd as root because sslh
 write its pid before dropping privileges (Closes: #740560)
   * debian/patches/disable_ip_freebind_test.diff: Remove Can't bind address
 upstream test because IP_FREEBIND is now enabled upstream
   * debian/docs: upstream README is now README.md
   * debian/rules:
 + use DESTDIR in addition of PREFIX as upstream change Makefile
   * Refresh debian/patches/disable_valgrind_launch.diff due to upstream
 changes
   * Stop service in case of purge (to be able to remove the user too)
   * Use DEB_BUILD_OPTIONS to speed the build
   * debian/patches/fixed_version.diff: Fix the version of binaries based on
 debian/changelog (instead of relying on git)
   * Update Description as sslh is not only a ssl/ssh multiplexer but a
 protocol multiplexer
Checksums-Sha1:
 0652d225ae8559ba578516c405c0b9d0cdd373bb 1938 sslh_1.16-1.dsc
 c739e2e5d55fc1b5f57aa9263e1be5e71ceff9c6 36483 sslh_1.16.orig.tar.gz
 91a22760ec326d9310d0c7c75a7cf03fcb3e371b 15964 sslh_1.16-1.debian.tar.xz
 f2e3619c14ed312af112b3285329f59436ad763c 44724 sslh_1.16-1_amd64.deb
Checksums-Sha256:
 5d227e7837847f22af7fe9776673885a43958f07e09c8fd636c2ce6988e2d02f 1938 
sslh_1.16-1.dsc
 e97b3be9f010bc763a7f11c94e54d8ead33cab3f0c93a52bb9a7f708212e5902 36483 
sslh_1.16.orig.tar.gz
 862b31a7552e1e0744fd364d1d542d2c6aa7bc089f52287cd474db3a632c2f11 15964 
sslh_1.16-1.debian.tar.xz
 8bfb3e6680fb4b841ce43354f7046f8cb6c7e71adfe41cf5cc374c7a23d159e0 44724 
sslh_1.16-1_amd64.deb
Files:
 2cfb318cf6196d8eaf6efd8ee70ac52f 44724 net extra sslh_1.16-1_amd64.deb
 35be18f4f5c7b089377613e9c7af858d 1938 net extra sslh_1.16-1.dsc
 1e85b84eb82a96b81de9b1e637a3e795 36483 net extra sslh_1.16.orig.tar.gz
 47e8cb5a1cbfdd0ebdef0b3fbcc8760c 15964 net extra sslh_1.16-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Signed by Ana Guerrero

iQIcBAEBCAAGBQJT77SRAAoJELNGT4lqoVlInmIP/ivttGX4rvzuen3AT9dosWEj
eGGesrxHVq0Prt8+9ollKKQHehtJY/16rMSWMTuTD9D/bTbGlRRFAEikHTptEfG5
J/8os2giwKyPvSU3uqqxKYY+LGI/S45fM/t283XgV40S13Nf6grqIZMXo90n3nCY
RKqROu3fKM0IY3btT4tm5VkaKSa53RA02mDUI2Du3fxhaOmpOB9BAtJgE/JwWSHH
/0Z4W4IH8LIKpJGbqvXIGPKOwgBkk/kGHSQPPXZL5gB4IFqkUtKlrZYj5asIdOfv
rQnV1UAHiwtrSID66Y9h8D/cS1T+h4uiLvaOErjc7PYeJY+P8PK0hrUoDPV0DthM
iskfwNCSA1Fjd3fTgOYd/anb63XQsEbaexu1iyMOgBUfE1RqEq6eEDB06n9sid5+
PYKwLvHypDoS9o+ml+ENI/J2XL4NVtcSLHfCh2/umoRDfijYepuAHf77RoQ5bQOp
jXVVRVanRabqvN3yogB+FJGuVPRTRZGTiK/LDHOscc0sek2bCpLnmoTil2bf3bll
UGUFALJfDgOYH8bnYnjutCzr3n49hbKcB4tvBbuUtHa9X1+JGxM62q9kvCMKuZnH
/f6mPVwe8lwhX8zP9iv1kt8se9W0BVfDGU/kklcOFrCk7C5OlWQ/pPthBr1U9DTu
KggKxAcxFeN8e3IC5gK3
=TwIj
-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/e1xijyd-00057g...@franck.debian.org

Accepted gdisk 0.8.10-1 (source amd64 all) into unstable

2014-08-16 Thread Guillaume Delacour

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 20 Jul 2014 14:52:52 +0200
Source: gdisk
Binary: gdisk gdisk-noicu
Architecture: source amd64 all
Version: 0.8.10-1
Distribution: unstable
Urgency: medium
Maintainer: Guillaume Delacour g...@iroqwa.org
Changed-By: Guillaume Delacour g...@iroqwa.org
Description:
 gdisk  - GPT fdisk text-mode partitioning tool
 gdisk-noicu - transitional dummy package
Changes:
 gdisk (0.8.10-1) unstable; urgency=medium
 .
   * New upstream release:
 - libicu support has been removed by upstream
 - drop all libicu related Debian patches and files.
 - gdisk-noicu is now replaced by gdisk
 - document all this changes in debian/NEWS.
   * Build-Depends on ncurses with wide character support (libncursesw5-dev)
 instead of libncurses5-dev and include ncursesw/ncurses.h instead of
 ncurses.h in cgdisk (debian/patches/ncursesw5.diff)
   * Enable parallel building and use dpkg-buildflags instead of
 DEB_BUILD_HARDENING
   * debian/patches/enable_make_test.diff: Add a test target to upstream
 Makefile instead of overriding dh_auto_test
   * Refresh patch debian/patches/manpages.diff
   * Drop unnecessary debian/patches/gdisk_binary_dir.diff
   * gdisk.lintian-overrides: Re-add as fixparts false positive against fortify
Checksums-Sha1:
 928347290109c851811c09568e84bf5b9e8cd69b 1938 gdisk_0.8.10-1.dsc
 1708e232220236b6bdf299b315e9bc2205c01ba5 190666 gdisk_0.8.10.orig.tar.gz
 4f2bd68eb6275229f9390f656454a082a1edae44 5868 gdisk_0.8.10-1.debian.tar.xz
 89b43a95afcc7723d7363ca98a2ac76d6bf2a33b 197850 gdisk_0.8.10-1_amd64.deb
 29611d0a41efa706588097f386bd994155fe41e2 4202 gdisk-noicu_0.8.10-1_all.deb
Checksums-Sha256:
 30749f53e66275f5048d52204a1c4f14c8a56a30587b6af6c17393c2b7837dab 1938 
gdisk_0.8.10-1.dsc
 73e64151203ae0c347c488358e71ca582bb7fb7f0d66df86b71c42050390eb9b 190666 
gdisk_0.8.10.orig.tar.gz
 1596f18cdc7a75829b11c239fc8e4a69a5418470d3c803dab2094d9fad3fc2d5 5868 
gdisk_0.8.10-1.debian.tar.xz
 09747499487ed156a6d13c060f8761f71627675aa17699027751ecafe2fb7531 197850 
gdisk_0.8.10-1_amd64.deb
 21abaa55e95f06fcf9178ec11eca47b6dd3d89c25e2a8eb5792c67515b31025c 4202 
gdisk-noicu_0.8.10-1_all.deb
Files:
 e737283305595e3be57306bb74e76cce 197850 admin extra gdisk_0.8.10-1_amd64.deb
 3de90fdfa641f9110dc51e59290d59e6 4202 oldlibs extra 
gdisk-noicu_0.8.10-1_all.deb
 f56ef671641b759d95ad2d88e456fc09 1938 admin extra gdisk_0.8.10-1.dsc
 9cf4246c181c324bdbd553fe9b348373 190666 admin extra gdisk_0.8.10.orig.tar.gz
 b54ae0f70bd397451cf688aabb7b7fd6 5868 admin extra gdisk_0.8.10-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Signed by Ana Guerrero

iQIcBAEBCAAGBQJT78bLAAoJELNGT4lqoVlI31QP/jvIEw40DN5TyUbCkBYUU4Cl
Vao34hfBXwp2sNsZMGedbVxE3QXPRXG8XYRtTZ6gSWcOLq9jg0XqQxX1cRusHgkk
XdJsdtsBNTjGQrRzr/l6lraQlJC5Ce+nTr2eFTSiLMWNj/+7rMYaVlZY3dnAtU2W
ZDJrY30FovyTnPtul98hsYk8bdlkyP4QZw+xT8KLC45pRaDoGNlWmtoh2t/T1yj7
zrMmPGD5GKyJ+BMBR0K0TDz9ShqUF/+IB9iJK3sUDkqJTiylx4iU7urE1QhBdJWK
Io8YS9TAKoPr6sDDguFl0moqxUg9vPgf9T7W9+OUhJLWEhaHLDJuab5MBqqpORCP
fXuJFlZLwdJEO9aWGuLlcvdS1pcBOf63D6GwVBaKb/Jk0qVxgKEF77AswXOl1F7z
1Q1Z+lJEgYvJcZf4Qr1GNi0RpUhW49vvWFpVAaxe2KkjNppHOwS7ycIxDPFQ4ZTs
BXqChtNu6NN6tKvl1GMOu9TTFGxEGLfbInqZW+vE4LgsgPpxuvN+Yzi7yimNIemt
vvc0qJ2iujWfT9Yne0PRtTbRTTMyhOapR3SJ2/Rc78jinyPSOlDqs6/6FYovvN8X
IwusuOQfvRXAurPt0TTCe7q8mivRZtPK8GOlZYNehuN2FuLhGmw/xfV7XcZ3I2YU
lUNhf41SU2WthbFw3FEc
=E0FS
-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/e1xilqz-0001hk...@franck.debian.org

Accepted libconfigreader-simple-perl 1.29-1 (source all) into unstable

2014-08-16 Thread Salvatore Bonaccorso

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Aug 2014 22:30:12 +0200
Source: libconfigreader-simple-perl
Binary: libconfigreader-simple-perl
Architecture: source all
Version: 1.29-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Salvatore Bonaccorso car...@debian.org
Description:
 libconfigreader-simple-perl - simple configuration file parser
Changes:
 libconfigreader-simple-perl (1.29-1) unstable; urgency=low
 .
   [ gregor herrmann ]
   * Set Standards-Version to 3.9.1; replace Conflicts with Breaks.
 .
   [ Salvatore Bonaccorso ]
   * Email change: Salvatore Bonaccorso - car...@debian.org
 .
   [ Ansgar Burchardt ]
   * debian/control: Convert Vcs-* fields to Git.
 .
   [ Salvatore Bonaccorso ]
   * Change Vcs-Git to canonical URI (git://anonscm.debian.org)
   * Change search.cpan.org based URIs to metacpan.org based URIs
 .
   [ Axel Beckert ]
   * debian/copyright: migrate pre-1.0 format to 1.0 using cme fix dpkg-
 copyright
 .
   [ gregor herrmann ]
   * Strip trailing slash from metacpan URLs.
 .
   [ Salvatore Bonaccorso ]
   * Update Vcs-Browser URL to cgit web frontend
   * Imported Upstream version 1.29
   * Update copyright years for debian/* packaging
   * debian/copyright: Refer to Debian systems in general.
 Refer to Debian systems in general instead of only Debian GNU/Linuxy
 systems.
   * Explicitly refer to GPL-1 license text in common-licenses
   * Declare compliance with Debian Policy 3.9.5
   * Bump Debhelper compat level to 8.
 Adjust versioned Build-Depends on debhelper to (= 8).
   * Wrap and sort fields in debian/control file
Checksums-Sha1:
 ce9819cb0a81321c41234512e29090b450228940 2299 
libconfigreader-simple-perl_1.29-1.dsc
 d8c3aeeb75cec44d5749cee9c98a43d5cd318b44 15309 
libconfigreader-simple-perl_1.29.orig.tar.gz
 9b317917bae9c710991a0da4e4d0ed7f6dde0911 2392 
libconfigreader-simple-perl_1.29-1.debian.tar.xz
 3211fbcff1954ee39a9e28b3b87bb403b260ada0 17050 
libconfigreader-simple-perl_1.29-1_all.deb
Checksums-Sha256:
 be54079ac3614fec5ce627f79a4464713ad9e4bcf13df114a20164b2d4f8d742 2299 
libconfigreader-simple-perl_1.29-1.dsc
 4de9b25ec4a610c97e13c57ecc9a584643aaffdc4fb047b66b9cde21d86430b7 15309 
libconfigreader-simple-perl_1.29.orig.tar.gz
 1dd7bd3228c3dc41bdf8cfb9f6b1340dd94e568c26abf2883469ace8e673c496 2392 
libconfigreader-simple-perl_1.29-1.debian.tar.xz
 a1d11027ba3c5e81740f7ab8d825a4ac3ca6d588cdabcc9f9fbd104672854431 17050 
libconfigreader-simple-perl_1.29-1_all.deb
Files:
 74bed0e77ab7c4e8dff0c524e480b361 17050 perl optional 
libconfigreader-simple-perl_1.29-1_all.deb
 95c4003beb4099b593f2bebc673d9ae4 2299 perl optional 
libconfigreader-simple-perl_1.29-1.dsc
 7a1893dc9ae9a0692a276249a6a4b97d 15309 perl optional 
libconfigreader-simple-perl_1.29.orig.tar.gz
 2e69be37e28d5581d5c2289867fe2e7b 2392 perl optional 
libconfigreader-simple-perl_1.29-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJT77/mAAoJEAVMuPMTQ89EI3QP/RHLIOg9IhpsvYwgGi8Xxefw
gmG3bZZ8i4p4nytpiAYXmZFN8VMv75EY+oYevtNqixl7tKxcWd43r3yyFKRi9/r4
i3Hy0QQlOdcxldA9mbDWp/A4+/yiW9czalQ3etWPMqJLFTImHE1xxkPaBRm5w9pU
89bKa1o8Lm3NU0MZ+UFLQmmwO/G4ZUYP+L3vLqHKR5iNkUQsvu/mhvbLY+DAYnJo
ai+i6PcWXZidk6o82oy+MGwRLu7xzk65eSm6KLCQi16BJhSVIHvXYF5ROfcInrwc
o8vpL2cp59/tp55kuCrqHeTl9E5BtcdB8BIbqecdco4TMY30l3agpECCZLBD+xZA
eNk2TbfYeZ/0tb+NTEF6oypyUMTprnvyAXBQfDDBsbD/NG5cOZnNtOLlbGvlJmak
Gs6Nj4czYe9fM1b7GHkZZk27VK/hEEdI6jOQknlt7e9bOAU8p95NM6vugCXRe/a3
RIcWDPZKnfvYJORCTHtP0d7QQlf0uGJBUNeAxqsvQ1c1CevCnt3fdzklJjbKq7zV
HuQG+QL4ZJ4SoaSkH3M8TUZzVFXxh3Ld7IKOC1tvjEmZ/8ijdQ+EwRnF/5yOjrLk
1EvuM4TCoEhmF8kyU+YFoS4fUBE0RDnmkKT0ffxn7t9zJkhh2YuuOoNCLkVSqJ9N
RBM6chWhixjytsEtsmmH
=RbB+
-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/e1xilso-0001jm...@franck.debian.org

Accepted gpsd 3.10+dev3~d6b65b48-4 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 16 Aug 2014 22:12:33 +0200
Source: gpsd
Binary: gpsd gpsd-dbg gpsd-clients python-gps libgps21 libgps-dev libqgpsmm21 
libqgpsmm-dev
Architecture: source amd64
Version: 3.10+dev3~d6b65b48-4
Distribution: unstable
Urgency: medium
Maintainer: Bernd Zeimetz b...@debian.org
Changed-By: Bernd Zeimetz b...@debian.org
Description:
 gpsd   - Global Positioning System - daemon
 gpsd-clients - Global Positioning System - clients
 gpsd-dbg   - Global Positioning System - debugging symbols
 libgps-dev - Global Positioning System - development files
 libgps21   - Global Positioning System - library
 libqgpsmm-dev - Global Positioning System - Qt wrapper for libgps (development)
 libqgpsmm21 - Global Positioning System - Qt wrapper for libgps
 python-gps - Global Positioning System - Python libraries
Changes:
 gpsd (3.10+dev3~d6b65b48-4) unstable; urgency=medium
 .
   * [8ae93e0]] Two systemd related changes that were forgotton.
 - do not install the old hotplug wrapper
 - don't forget the @ in gpsdctl@.service.
 Thanks to Jeremy Lainé
Checksums-Sha1:
 066558d1d967c528520f1233dd22b01a7371ff26 2619 gpsd_3.10+dev3~d6b65b48-4.dsc
 3c5f34e03821dada74324c2339debd3da7929e6c 34316 
gpsd_3.10+dev3~d6b65b48-4.debian.tar.xz
 52aaeab2fd203f57cd71bfcad88a45676685ad39 94430 
gpsd_3.10+dev3~d6b65b48-4_amd64.deb
 78478b6e0fe487baff3ba62b2323b47cab2ae437 1340758 
gpsd-dbg_3.10+dev3~d6b65b48-4_amd64.deb
 c46bd92baeceac00d080d90708c9dfc672361b01 135618 
gpsd-clients_3.10+dev3~d6b65b48-4_amd64.deb
 5e5d11ae4f6c3764d2aac952902b170dca413031 95946 
python-gps_3.10+dev3~d6b65b48-4_amd64.deb
 7de0af3e0398f43a218c0ce9cc4373121b0b9e77 219818 
libgps21_3.10+dev3~d6b65b48-4_amd64.deb
 7778aa94bf88380a85ed42299e7691dfc30fd158 131538 
libgps-dev_3.10+dev3~d6b65b48-4_amd64.deb
 6dbb19980c73a631f1add6f7e0d9331c6b7675d1 91454 
libqgpsmm21_3.10+dev3~d6b65b48-4_amd64.deb
 26d5ee3c8a81e7a7b73c719ca5f3a16643c11c90 43418 
libqgpsmm-dev_3.10+dev3~d6b65b48-4_amd64.deb
Checksums-Sha256:
 6ea3c7eaea58d93f8e4478a2f5a3e19da0a9ba753433ecf580923279eef3a96f 2619 
gpsd_3.10+dev3~d6b65b48-4.dsc
 e75abd93bdb0884b58f8b08eeebcff99d1721850ebcc818ac5d724d034ac7e56 34316 
gpsd_3.10+dev3~d6b65b48-4.debian.tar.xz
 90d41fa44e0d5ef680d3066fe6a4f480039b8e7ef24fadf3e382f4c89b0b9cf0 94430 
gpsd_3.10+dev3~d6b65b48-4_amd64.deb
 6e6ecf0986fa8f46e7739bdf2fd5aff5843cb57e5b6515916f1f7b1aab4eebea 1340758 
gpsd-dbg_3.10+dev3~d6b65b48-4_amd64.deb
 6ad777b6da4f81282098c7cb11927dd0f5da8b5c24bb9b2b53b0858581382611 135618 
gpsd-clients_3.10+dev3~d6b65b48-4_amd64.deb
 58ceb36f751e09dbd3932d7facc8eb419f3bb3110ce377f40eef424f5ad25945 95946 
python-gps_3.10+dev3~d6b65b48-4_amd64.deb
 be71682929bcf8ca85bee2d20309186de9a1201457195c21b9cdfcb2bb920f09 219818 
libgps21_3.10+dev3~d6b65b48-4_amd64.deb
 2ca348632f927f42ddbac25f76018e223121dd890c658d57572cea354b809523 131538 
libgps-dev_3.10+dev3~d6b65b48-4_amd64.deb
 c628e072edb0a5fc78091a91008cc0789ba9d0f8bc25a98bb29a52ebb63f85e7 91454 
libqgpsmm21_3.10+dev3~d6b65b48-4_amd64.deb
 2a65021b5734cc91d9ddaedd862844893d0c189cb4c86ede1f95a8da3ccd4a3f 43418 
libqgpsmm-dev_3.10+dev3~d6b65b48-4_amd64.deb
Files:
 b6bdb451a4d89643fd52ae726c9c2eb7 94430 misc optional 
gpsd_3.10+dev3~d6b65b48-4_amd64.deb
 bb30dc38e33055e373d3145cc186c04e 1340758 debug extra 
gpsd-dbg_3.10+dev3~d6b65b48-4_amd64.deb
 e5fa80e0d42f06506cd947234fd932bc 135618 misc optional 
gpsd-clients_3.10+dev3~d6b65b48-4_amd64.deb
 a65f05bce4c2344d45e01cac0162ab11 95946 python optional 
python-gps_3.10+dev3~d6b65b48-4_amd64.deb
 d14a7d3ff931d0c3354d0e7c21c1cfc5 219818 libs optional 
libgps21_3.10+dev3~d6b65b48-4_amd64.deb
 0a22a17d626713ad00cfbdb3666c8002 131538 libdevel optional 
libgps-dev_3.10+dev3~d6b65b48-4_amd64.deb
 bed9e4476cc2c455a0962be015e7d295 91454 libs optional 
libqgpsmm21_3.10+dev3~d6b65b48-4_amd64.deb
 d67e1319e9c6d64d2335f5f4185906e8 43418 libdevel optional 
libqgpsmm-dev_3.10+dev3~d6b65b48-4_amd64.deb
 8de313a4033474f5617609f96020800b 2619 misc optional 
gpsd_3.10+dev3~d6b65b48-4.dsc
 28cf34735d904bda18752f769354769a 34316 misc optional 
gpsd_3.10+dev3~d6b65b48-4.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJT773lAAoJEOs2Fxpv+UNfLqAQAMGt9uNrXgFZFIgwJZb76E6b
VdPkLPdeRYysWVeG/GyVp6WciUcmiaz8xMg3AN8Y15y1yQ8Gx+xuI/OhoN+LPUZf
wPyjIFqLuRNYC+bW8K1LpVAhPqbhKSEXs6IGx0DqleKJokeKcdXRQd7dEvbC/AU6
Gon8HSmdgXAxIeS8Ql3VYCl36aUEmNSe9ag1TuM8uONCKOJGm/isDFUUqW3flOds
qPPukMS1LH2KeLpj5HMgzd9k5bAUJD7+MZP9exJR72c3JB+6GhxArqyJhXKOIeFr
xPwm8pMVtREqYIx7/5JtGH4w241SKtNJloryal9zTGBTNJSrkaBQz1ZQKMmEpdqE
xIWN390/3fRoljgauix+zVJLK8IrqdJB3EeN+uqqHxu6CdgvOTHqMZMf6WksoP++
gUWYK3GYxA87Yijsk8lx+8k2gAh+n0YYCjQdfxbwlrz6kCS5yoINGh2y9eXY9MIb
YYfHCKaj3B7ys+0YT38l7JBkM3LgnII8QT+lzXR6ssVaaDjhH/PpZUvXdTIC1ORB
hlow8+QMJll7IdVHSpHGrqXPxdTd8NnMX2oRSvGkExmymTm6XcOvgjVwDCA5Wjg0
VFEH/U3fpGFUja45UHn43MeRLgeCHXPQxcVMyJf2ZE2nwcw8EjVAIhzoZBYDEmDq
Dnn6y58Elmv72dBPfKkS
=gdrm
-END PGP SIGNATURE-


-- 
To

Accepted libuv 0.10.28-1 (source) into unstable

2014-08-16 Thread Luca Bruno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 16 Aug 2014 21:21:55 +0200
Source: libuv
Binary: libuv-dev libuv0.10 libuv0.10-dbg
Architecture: source
Version: 0.10.28-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Javascript Maintainers 
pkg-javascript-de...@lists.alioth.debian.org
Changed-By: Luca Bruno lu...@debian.org
Description:
 libuv-dev  - asynchronous event notification library - development files
 libuv0.10  - asynchronous event notification library - runtime library
 libuv0.10-dbg - asynchronous event notification library - debugging symbols
Changes:
 libuv (0.10.28-1) unstable; urgency=medium
 .
   * New upstream release
+ Drop patches applied upstream
Checksums-Sha1:
 8d0927c9bbb9ec90467d0e6311a78c4bcf87cdfe 1410 libuv_0.10.28-1.dsc
 21db9f3d89af1ef880f53d85061a038e431c869e 330409 libuv_0.10.28.orig.tar.gz
 98e1606b8d5d37a3c576de0c77ce898145582ad0 6516 libuv_0.10.28-1.debian.tar.xz
Checksums-Sha256:
 e1c9933b30d4cd171d0a2e4cedcc597ccb949fc05b2888175b7b380904f1aa48 1410 
libuv_0.10.28-1.dsc
 6a0b711bef08ffa92899c4014114c8d58a8db5740801a00edbdaa4b4613311af 330409 
libuv_0.10.28.orig.tar.gz
 a5da7e63b0eea1e0f6b104f4000d9517045dc82aadc17cda02f568cd5c8ad4a3 6516 
libuv_0.10.28-1.debian.tar.xz
Files:
 e8a02c1e6429a900477b8c367c13363f 1410 libs optional libuv_0.10.28-1.dsc
 ad96b7a71a637284ea00727bb1379c1f 330409 libs optional libuv_0.10.28.orig.tar.gz
 949866337b3d22e295c3931fc5355057 6516 libs optional 
libuv_0.10.28-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlPvsDUACgkQRqobajv7n7P2EwCgkl0fz7CM6DUdTjjiHuweShzE
ttgAoIK+ClArajB2vYZITmNKQmbAbrgN
=05ri
-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/e1xilse-0001q2...@franck.debian.org

Accepted procenv 0.36-1 (amd64 source) into unstable

2014-08-16 Thread James Hunt

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 16 Aug 2014 20:53:39 +0100
Source: procenv
Binary: procenv
Architecture: amd64 source
Version: 0.36-1
Distribution: sid
Urgency: medium
Maintainer: James Hunt james.h...@ubuntu.com
Changed-By: James Hunt james.h...@ubuntu.com
Description: 
 procenv- Utility to show process environment
Changes:
 procenv (0.36-1) unstable; urgency=medium
 .
   * debian/control: Make libselinux1-dev and libapparmor-dev Build-Depends
 Linux-specific.
   * New upstream release.
Checksums-Sha1: 
 85e30a9794380e8db126dfb0e205f5c7490bcc0b 68010 procenv_0.36-1_amd64.deb
 b2a1a55260fef26fe90d705665aa703938751de0 1997 procenv_0.36-1.dsc
 74709f57c4528f579f924ccbef0eeac52f057d9b 264248 procenv_0.36.orig.tar.gz
 7a7a93f61b1b6a9419d587f0ba7240c9025fc0ab 7400 procenv_0.36-1.debian.tar.xz
Checksums-Sha256: 
 39150aff67bfe5697f4f31a4a7a3f38a7eb8da9b8dcd73fe6e804ec6a99a7e7c 68010 
procenv_0.36-1_amd64.deb
 a4b224b2916d6f1eb341b94155241c1ff0668471495ecb6698bccb075aa4364c 1997 
procenv_0.36-1.dsc
 70550499d0602ffbb4bbbe91c1a6d468d44589ab29b74b5ccc42b9558f970fb4 264248 
procenv_0.36.orig.tar.gz
 5949788016b217b68649df1034a8f1aa2a7456f78a74ef911da422f2ad7135e8 7400 
procenv_0.36-1.debian.tar.xz
Files: 
 1e577bb937f06ca52a5433ceabb492e4 68010 utils optional procenv_0.36-1_amd64.deb
 bd3d071e874affc77f13a220fc7f268f 1997 utils optional procenv_0.36-1.dsc
 0d817922c5b3ec35b3fc73f9fccf8f70 264248 utils optional procenv_0.36.orig.tar.gz
 9d9e77df1f71e04e99b235bd249ee2d5 7400 utils optional 
procenv_0.36-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJT770CAAoJEJ1Q4UTmNXMnGMAP/isM22S04zXIqLejAORz3eO1
rOJUkbyAgX7U1p5zh3TH+RMEEsw/VodyEwaKGKtf+T2LWqW/7A0CtdSSbD5CvjeF
xRKaJVIsJxR0gx/Jc8LngrGZG0EmqJJhgChk4Y07uK/JHTpBmhCqSJadTzTZ2QQC
eVMuT/xKq4zmA3vXKLH6hgclVP9k+G2h2NYgTwgYTj66snz8ACnTJny4TXqf3oc2
e50NYBszQN+n49WSvktdJdRwvfjqpORMWuSvtW2Bh+Tkm37hZOVWobMXIwCHf1iw
pyqXqsu0u6L2FSwuagBzZOHMPios1S3ly79osRWNzhCLocWlM5SKXPx2Myf8iEEW
GNp74IOKJVgw4RLQA7zj4K/qwSzJC5mGTusrgXfJJ/r6qxdTLsNvSfpafsJ0168h
dlDspW9UWSz9515fATnX7i2yGwjZwKgAiPIvkyAYsfuYwyBxRYIaVHXPyzkRWqNH
opes2AnGivEgx0PL6Kub79dMUFCT7E82onUaQIbQljuIlJhV7oKQNwAfql6ngZkI
WFbSM3uGkvw7xiRmCJf41Xjxrjl3Hwbs1r/AX9zZ+jQPgCsohONjz+66cxCwIof+
I211JCljedg6YjgnSc+yONhqGkpIHtRMLq1xgiQBQJ0sqYNofO1AJX1V9Uia5Sn8
kpXNBbyWMKzClGUOpkPR
=apNR
-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/e1xilt6-0001u4...@franck.debian.org

Accepted open-vm-tools 2:9.4.6-1770165-2+exp1 (source amd64 all) into experimental