date:20130425

Hi,

Nicolas Dandrimont and I are currently working on a project proposal for
the Google Summer of Code to use the messaging system written by Fedora,
fedmsg[0][1], within the Debian infrastructure (some of you might have seen
the various ITPs related to that on -devel).

Tollef kindly pointed out to us that Debian service administrators would
probably have something to say about all this, so here we are.

As a premise, please note that we obviously plan to make fedmsg
distro-agnostic before anything else (than packaging). The original
upstream author seems very enthousiastic about the project, which makes
it probable that we won't have to carry those patches on our own.

The thing itself is based on the ZeroMQ protocol.

To quote Nicolas: 
 One of the key outcomes of getting such a system in place, is that everyone,
 everywhere, can start listening to the messages and using them, opening up 
 lots
 of doors for people to make amazing services based on Debian.
 
 A few ideas:
  - getting a signal from the archive on an accepted package (I'm confusing
binaries and sources for the sake of brevity):
→ Trigger a piuparts run
→ Trigger lintian checks
→ Let any derivative intent a rebuild
→ Signal ports to rebuild
→ Trigger a jenkins job on specific package uploads
→ Post to pump.io/identi.ca/twitter
→ get a notification on your desktop
→ ...
  - one of your pet packages gets a git commit
→ try a rebuild
→ run QA checks
→ ...
 
 (boy, that escalated quickly)
 
 I think the possibilities are quite nice, and, as the fedmsg webpage says, 
 that
 gives new meaning to open infrastructure.

Two features I'd like to implement during this GSoC that are not AFAICT
already present in fedmsg are GPG support and some kind of playback
mechanism for the systems where it is important that all messages are
sent and received (there are some others where the information would
have value only at the time of emitting, I suppose).

Questions, comments?

Cheers,
Simon

[0] http://wiki.debian.org/SummerOfCode2013/StudentApplications/SimonChopin
[1] http://fedmsg.com/

PS: debian-admin, debian-services-admin and soc-coordination Cc-ed for
reference, but further discussion should be on -devel. Upstream author
Ralph Bean rb...@redhat.com also Cc-ed, it would probably be useful to
keep him in the loop.


signature.asc
Description: signature

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

2013-04-25 Thread Wouter Verhelst

On 25-04-13 10:50, Clint Byrum wrote:
 On 2013-04-24 12:43, Guillem Jover wrote:
 All of the things you mention are huge accomplishments, but the scope is
 what I am suggesting has gotten out of hand. Do we really need a high
 level view and QA of the entire system for MongoDB?

We don't need it for MongoDB, but we do need it for Debian.

The difference might seem to be minor, but it isn't.

 It is a daemon
 and some client tools. If I install it from tarball, I know this is
 shocking, but it actually works fine and doesn't interfere with anything
 else.

That's fine, great, and dandy. But it's besides the point.

I would hope that all upstream software works fine and doesn't
interfere with anything else if installed from tarball. If it doesn't,
they seriously need to check what they're doing.

But Debian packages go beyond work fine. They are integrated. If there
are other packages out there that do similar functionality to whatever
it is that MongoDB does (I don't have a clue, but it doesn't matter
for this discussion; I guess it's some sort of database), then it's
reasonable to expect that a MongoDB package would need to behave
similarly to those other packages.

For a database server, this could include things like:
- making sure the data is stored in the right location in the file
system; e.g., postgresql upstream assumes all its stuff (binaries,
configuration, data files) are stored in a single directory. Given their
background (they support way more systems than we do; e.g., they also
support Windows) this makes sense, but that doesn't mean we should, too.
- If it's an SQL database, integrating everything with dbconfig-common.
This is a Debian-specific thing to make installing database-using
packages easier; it makes no sense whatsoever to push this upstream.
- ... probably others, but I'm not very fluent in packaging of database
systems.

 If it does, I will complain to upstream. My suggestion is not to
 stop packaging, but to shift focus from make an awesome package to
 make an awesome upstream that results in an automatically generated
 awesome package. Debhelper and many of the other tools definitely help
 with this, but we can do more.

Yes, we do have a guideline that says you should push improvements
upstream if and when they make sense there, and that is more often the
case than you'd think if you were just looking at the number of patches
that flow upstream.

But making a distribution is so much more than just checking licenses
and converting source into installable packages.

Take, for instance, the apache packages. If you were to just take the
upstream source, compile, and install it, then it would also Just Work.
But it wouldn't have the same flexibility that the Debian packages have.
On Debian, you can just install some libapache-mod-foo package, and due
to how the configuration files are arranged, it will simply work. This
kind of integration isn't something that can (or should!) be done
upstream; it's squarely inside the realm of what a distribution does.

The amount of such integration is part of what makes a distribution
unique; some distributions tend to do this more than others, and at one
extreme of this are Arch and Slackware, who make it a policy to ship
upstream source as pristine as possible. Debian is clearly not at that
extreme, and it should not be, IMO; the high level of integration, the
expectation that I can have from the behaviour of a package that's part
of Debian is what attracted me to Debian in the first place, and if we
ever lose that I'll probably start looking for a different distribution.

 And all this, upstream will never be able to provide (at least not as
 defaults), because each distribution has its own policies, some are
 better, some are worse, and some are just different. In general I'd
 never trust the packaging produced by an upstream for a distribution
 they are not involved in. But most of the time there will be no such
 packages for the desired distribution anyway.

 
 Debian wants to provide end-to-end generalized tight integration. Thus
 packages lagging behind upstream. I'm suggesting that this tight
 integration ideal actually *limits* the scope of Debian.

Sometimes packages are lagging behind, yes, and that's a problem; but I
don't agree that the tight integration lies at the root of that problem.
When done right, this kind of integration consists of just a few files
inside a debian/ directory; they should not interfere with packaging a
new upstream version.

Yes, there are exceptions, and we should strive to eliminate such cases.
Sometimes this is because upstream is no longer active; sometimes this
happens because the maintainer isn't doing a good (enough?) job.
Whatever the reason, it's something we should try to fix. But just
throwing our hands up in the air and saying that we should therefore
give up on trying to integrate isn't the right way forward, I'd say.

[...]
 Although there's been work on creating distribution-neutral specs

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

2013-04-25 Thread Andreas Tille

Hi,

On Thu, Apr 25, 2013 at 12:00:11PM +0200, Jonas Smedegaard wrote:
 Quoting Andreas Tille (2013-04-25 09:20:59)
  I honestly wonder if there is some more general definition for the 
  term app store besides what according to[1] certain companies have 
  made out of it.  Following the logic that app store is crap because 
  some companies provide it as such we are terribly lucky that they did 
  not choose the term distribution for their crap.  I personally can 
  not find something wrong in a *generic* term application store and I 
  would not seriously object if someone would call Debian an app store 
  done the right way.
 
 If by not seriously object you mean that you would object but with a 
 smile and continue your great meal together, rather than leave the 
 party and file a lawsuit, then I agree with you...

It depends with whom I share that great meal.  If it is my father I
would simply say yes.  If it is my son I would mind explaining the
difference.  Rationale:  I have installed Debian on my fathers box and
told him how he can install additional applications.  Once you have a
basic system running the Debian mirror serves as an app store and it
makes actually the point for this kind of user (and a lot of other users
as well).

 To me, calling Debian an app store would be only misleading.

Yes.  That's why I would not call Debian an app store to *you*.

 To me an 
 app store is for topping op a system, not the system itself.

There are actually users who do not see the system but just the
topping.  I would never try to blame the user about this.  For my father
it is even easier to understand what I'm doing in Debian because I spend
most of my time with leaf packages (if I do not care for Blends
infrastructure stuff).  So telling him Debian is an app store and my
work on it is adding apps to the store this is an very easy to
understand explanation which leaves out the part that is not
understandable to him: What is an operating system.  (Hey, also Windows
is no operating system - it is just a kick-starter for Windows, Excel, a
browser and a mail client, right?)

 Debian is no app store: content is not only apps nor app-centric, and 
 aim is not to archive nor to sell, but to streamline and distribute.

If you do not like the selling part:  Store in the sense of some
storage of goods is not necessarily about bying (at least of my
understanding).  Or tweak it like this:  We are selling our stuff but
the price tag says 0€/$.  Feel free to blame me about oversimplification

 When I need an alternative term to describe what distribution means, I 
 use library: Like librarians we care not only about the individual 
 books of software, and not only about the novels, but about 
 long-term cohesive structure of the library as a whole.
 
 Libraries also has the connotation of collecting dust which arguably 
 is descriptive for (stable) Debian as well ;-)

Nice alternative explanation.

Kind regards

 Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425124038.ga7...@an3as.eu

Re: Upstream packaging

2013-04-25 Thread Gergely Nagy

Clint Byrum spam...@debian.org writes:

 Also if people thought that distributions are unneeded, then the
 amount
 of them would reflect that, or start decreasing, which I'm not seeing.
 Distributions will exist as long as there's FLOSS, because by its
 decentralized nature, there's no single coordination point; people
 who are distraught by the amount of distributions or by their mere
 existence might probably only be able to find peace in closed-systems
 instead, with their centralized control points.


 Nobody is distraught. The problem statement was something like
 distributions lag upstreams, how can we solve this? and I'm
 suggesting that its kind of already solved with upstreams who use
 their native packaging format (i.e., autotools, pypi for python, or
 maven for java). Its just that Debian has such strong policies that we
 are unable to consume said packaging, because the upstream packaging
 is less expressive. So, we have to lag while we QA all of our
 specialness.

There's so much more to packaging and *maintaining* a debian package
than wrapping whatever upstream has in a .deb, even if we apply very
few (or none at all) changes during the process.

Just because something uses autotools, it will not mean you can
trivially package it, or upgrade from one version to the other. There
are a million things that can - and sooner or later, will - break even
if upstream only uses standard tools. A new dependency, a new configure
option, changing defaults, and all kinds of incompatible changes make
maintainance neccessary and far more effort than you seem to imply.

Most of these are things upstream do not have to care about: they'll
document it in an UPGRADING file or similar, and delegate the task to
their users. A distribution will most likely wish to automate most of
that in a straightforward and safe manner.

 Where Debian's efforts should be focused is on things like license
 verification and helping bug reports and fixes get to upstream.

 So basically, getting rid of most of the fun stuff and turning it into
 a lawyerish play-ground and support center... I'd venture to say, not
 the most attractive work for most people here if it was the only
 thing to be done, which we do because we think it's important non the
 less.


 I am suggesting that there are a lot of things that are much more fun
 than conforming software to Debian policy.

Wouter said it very well, that the Policy is not a goal, but a tool to
achieve a goal: that of an integrated system. Making packages conform to
policy is pointless, if it is not done to achieve the goal. Creating a
well integrated system on the other hand *is* fun, and something that
can't be delegated to upstream, or anywhere else but the distribution
itself.

 I'm also suggesting that these things don't need to happen in the
 context of Debian.

Where else? Upstreams should not be concerned about integrating their
software into distributions. That's what package maintainers are for:
they know the distribution better, they have the skills and resources to
do the neccessary integration work, they know how their distribution
handles upgrades, and so on and so forth.

Upstreams should provide the tools and documentation to make integration
possible and smooth, but that's where it should end.

As an upstream, I do not wish to care about any single distribution.
I'll provide ample documentation, scripts and whatever else they need,
but I do not wish to play the integrator role. If I start to do that for
one distribution (wit my upstream hat on), I'll have to do it for the
rest too. No, thank you, that is as far from fun as it can ever be.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwsm7pgx.fsf@algernon.balabit

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

2013-04-25 Thread Andreas Tille

On Thu, Apr 25, 2013 at 02:40:38PM +0200, Andreas Tille wrote:
 understandable to him: What is an operating system.  (Hey, also Windows
 is no operating system - it is just a kick-starter for Windows, Excel, a
 browser and a mail client, right?)

s/for Windows, Excel/for Word, Excel/ 

Kind regards

   Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425125614.gb7...@an3as.eu

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

2013-04-25 Thread Ben Armstrong

On 04/25/2013 09:40 AM, Andreas Tille wrote:
 There are actually users who do not see the system but just the
 topping.

Yes, but I don't think we should encourage any users in this skewed view
of the system.

 I would never try to blame the user about this.

Nor would I. However, I would not use this as an excuse not to educate them.

 For my father
 it is even easier to understand what I'm doing in Debian because I spend
 most of my time with leaf packages (if I do not care for Blends
 infrastructure stuff).  So telling him Debian is an app store and my
 work on it is adding apps to the store this is an very easy to
 understand explanation which leaves out the part that is not
 understandable to him: What is an operating system.  (Hey, also Windows
 is no operating system - it is just a kick-starter for Windows, Excel, a
 browser and a mail client, right?)

I understand using app store as an analogy, as long as it is explained
as such, and qualified as being an imperfect analogy. But the common
conception of an app store as involving you solely as consumer and not
as participant in the free software ecosystem encourages poor
relationship between users and producers (or distributors) of free
software. So long as users continue to see themselves as a tiny,
insignificant recipient at the end of the production of the software
with no input into the system, you've stripped them of the power to
change the software to meet their needs. So using the app store
analogy is walking the fine line and really needs to be qualified to
avoid doing damage to the user's relationship to the community.

 If you do not like the selling part:  Store in the sense of some
 storage of goods is not necessarily about bying (at least of my
 understanding).  Or tweak it like this:  We are selling our stuff but
 the price tag says 0€/$.  Feel free to blame me about oversimplification

Honestly, I don't think the selling part is the most offensive part of
the concept of an app store. It's the one-way nature of the
transactions carried out with them.

Ben


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51792a53.7080...@sanctuary.nslug.ns.ca

Re: jpeg8 vs jpeg-turbo

2013-04-25 Thread Steve McIntyre

Riku Voipio wrote:
On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:

 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.

This would be a relevant if some application actually used the
full libjpeg8 ABI . In fact, 100% of debian works fine with
libjpeg-turbo, or even the original libjpeg6b (if the would be
recompiled against it again). 

I find the reason that IJG libjpeg8 fork is so triggerhappy to
repeatedly break the API and ABI (and image format!) rather a reason 
to make libjpeg8 the non-default. 

That *alone* sounds like a good argument for switching, to be honest...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uvnew-xi...@mail.einval.com

Re: jpeg8 vs jpeg-turbo

2013-04-25 Thread Peter Samuelson


[Mathieu Malaterre]
 I do not believe in debian life-span, a package manager ever switch
 an implementation of a package. So libjpeg9 and libjpeg-turbo will
 have to co-live.

It happens.  Look at the source for 'libc6'.  It used to be glibc,
these days it is a fork called eglibc.  Likewise the source for the
'ssh' package was once SSH by Tatu Ylonen, these days it is a fork
called OpenSSH maintained by some OpenBSD hackers.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425152859.ga4...@p12n.org

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Daniel Pocock

On 25/04/13 13:50, Simon Chopin wrote:
 Hi,

 Nicolas Dandrimont and I are currently working on a project proposal for
 the Google Summer of Code to use the messaging system written by Fedora,
 fedmsg[0][1], within the Debian infrastructure (some of you might have seen
 the various ITPs related to that on -devel).

 Tollef kindly pointed out to us that Debian service administrators would
 probably have something to say about all this, so here we are.

 As a premise, please note that we obviously plan to make fedmsg
 distro-agnostic before anything else (than packaging). The original
 upstream author seems very enthousiastic about the project, which makes
 it probable that we won't have to carry those patches on our own.

 The thing itself is based on the ZeroMQ protocol.

 To quote Nicolas: 
 One of the key outcomes of getting such a system in place, is that everyone,
 everywhere, can start listening to the messages and using them, opening up 
 lots
 of doors for people to make amazing services based on Debian.

 A few ideas:
  - getting a signal from the archive on an accepted package (I'm confusing
binaries and sources for the sake of brevity):
→ Trigger a piuparts run
→ Trigger lintian checks
→ Let any derivative intent a rebuild
→ Signal ports to rebuild
→ Trigger a jenkins job on specific package uploads
→ Post to pump.io/identi.ca/twitter
→ get a notification on your desktop
→ ...
  - one of your pet packages gets a git commit
→ try a rebuild
→ run QA checks
→ ...

 (boy, that escalated quickly)

 I think the possibilities are quite nice, and, as the fedmsg webpage says, 
 that
 gives new meaning to open infrastructure.
 Two features I'd like to implement during this GSoC that are not AFAICT
 already present in fedmsg are GPG support and some kind of playback
 mechanism for the systems where it is important that all messages are
 sent and received (there are some others where the information would
 have value only at the time of emitting, I suppose).

 Questions, comments?

ZeroMQ is a very lightweight solution - it is brokerless (like
multicast) so won't necessarily support the requirement for durable
subscriptions (keeping messages queued up for clients that are disconnected)
http://www.zeromq.org/topics:requirements-for-reliability

Some things that are worth looking at:

- do we want to use an AMQP broker? In theory, this is an open standard
like SMTP: the clients and brokers are interchangeable

- as an alternative, could we use something like SIP or XMPP as a
messaging platform? Then people can receive messages in their chat
client. In this case it doesn't appear to be the optimal solution, but
these protocols are quite good for systems that are very widely
distributed over public networks.

- then again, there are plenty of examples of systems like Apache Camel
that can take a message from a traditional broker and deliver it to just
about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
other possible destinations:
http://camel.apache.org/components.html
and it can use Java or XML to describe various filters and transforms



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51794ceb@pocock.com.au

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Paul Tagliamonte

On Thu, Apr 25, 2013 at 05:34:03PM +0200, Daniel Pocock wrote:
 On 25/04/13 13:50, Simon Chopin wrote:
  Hi,
 
  Nicolas Dandrimont and I are currently working on a project proposal for
  the Google Summer of Code to use the messaging system written by Fedora,
  fedmsg[0][1], within the Debian infrastructure (some of you might have seen
  the various ITPs related to that on -devel).
 
  Tollef kindly pointed out to us that Debian service administrators would
  probably have something to say about all this, so here we are.
 
  As a premise, please note that we obviously plan to make fedmsg
  distro-agnostic before anything else (than packaging). The original
  upstream author seems very enthousiastic about the project, which makes
  it probable that we won't have to carry those patches on our own.
 
  The thing itself is based on the ZeroMQ protocol.
 
  To quote Nicolas: 
  One of the key outcomes of getting such a system in place, is that 
  everyone,
  everywhere, can start listening to the messages and using them, opening up 
  lots
  of doors for people to make amazing services based on Debian.
 
  A few ideas:
   - getting a signal from the archive on an accepted package (I'm confusing
 binaries and sources for the sake of brevity):
 → Trigger a piuparts run
 → Trigger lintian checks
 → Let any derivative intent a rebuild
 → Signal ports to rebuild
 → Trigger a jenkins job on specific package uploads
 → Post to pump.io/identi.ca/twitter
 → get a notification on your desktop
 → ...
   - one of your pet packages gets a git commit
 → try a rebuild
 → run QA checks
 → ...
 
  (boy, that escalated quickly)
 
  I think the possibilities are quite nice, and, as the fedmsg webpage says, 
  that
  gives new meaning to open infrastructure.
  Two features I'd like to implement during this GSoC that are not AFAICT
  already present in fedmsg are GPG support and some kind of playback
  mechanism for the systems where it is important that all messages are
  sent and received (there are some others where the information would
  have value only at the time of emitting, I suppose).
 
  Questions, comments?
 
 ZeroMQ is a very lightweight solution - it is brokerless (like
 multicast) so won't necessarily support the requirement for durable
 subscriptions (keeping messages queued up for clients that are disconnected)
 http://www.zeromq.org/topics:requirements-for-reliability
 
 Some things that are worth looking at:
 
 - do we want to use an AMQP broker? In theory, this is an open standard
 like SMTP: the clients and brokers are interchangeable
 
 - as an alternative, could we use something like SIP or XMPP as a
 messaging platform? Then people can receive messages in their chat
 client. In this case it doesn't appear to be the optimal solution, but
 these protocols are quite good for systems that are very widely
 distributed over public networks.
 
 - then again, there are plenty of examples of systems like Apache Camel
 that can take a message from a traditional broker and deliver it to just
 about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
 other possible destinations:
 http://camel.apache.org/components.html
 and it can use Java or XML to describe various filters and transforms
 
 
 
 -- 
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/51794ceb@pocock.com.au
 

Guys, we're *days* into student applications. We should have had this
nailed down weeks ago.

Pick something, go with it, or let's stop this early. Really; we should
be fielding students now, now bikesheading over this stuff.

Cheers,
 Paul

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


signature.asc
Description: Digital signature

Bug#706158: general: Probleme d'affichage

2013-04-25 Thread oxygene

Package: general
Severity: normal

Bonjour,

1°) barre de menu

- probleme d'affichage d'icone, application en cours (same icone)
- un changement de fenetre (ctrl-alt-1) permet au retour sur
L'Interface  X11
   d'afficher les icones,
- probleme de mise a jour, erreur a l'execution,

2 °) MercI

FREDERIC




-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425174913.12504.62653.reportbug@oxygene

Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library

Package: wnpp
Owner: Alessandro Ghedini gh...@debian.org
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libzmq-libzmq2-perl
  Version : 1.07
  Upstream Author : Daisuke Maki dais...@endeworks.jp
* URL : https://metacpan.org/release/ZMQ-LibZMQ2/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl bindings to the libzmq 2.x library

ÃMQ is a library which extends the standard socket interfaces with features
traditionally provided by specialised messaging middleware products.

ÃMQ sockets provide an abstraction of asynchronous message queues, multiple
messaging patterns, message filtering (subscriptions), seamless access to
multiple transport protocols and more.

ZMQ::LibZMQ2 is a thin Perl wrapper around the libzmq 2.x C API.


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

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Paul Tagliamonte

On Thu, Apr 25, 2013 at 11:44:35AM -0400, Paul Tagliamonte wrote:
 On Thu, Apr 25, 2013 at 05:34:03PM +0200, Daniel Pocock wrote:
  On 25/04/13 13:50, Simon Chopin wrote:
   Hi,
  
   Nicolas Dandrimont and I are currently working on a project proposal for
   the Google Summer of Code to use the messaging system written by Fedora,
   fedmsg[0][1], within the Debian infrastructure (some of you might have 
   seen
   the various ITPs related to that on -devel).
  
   Tollef kindly pointed out to us that Debian service administrators would
   probably have something to say about all this, so here we are.
  
   As a premise, please note that we obviously plan to make fedmsg
   distro-agnostic before anything else (than packaging). The original
   upstream author seems very enthousiastic about the project, which makes
   it probable that we won't have to carry those patches on our own.
  
   The thing itself is based on the ZeroMQ protocol.
  
   To quote Nicolas: 
   One of the key outcomes of getting such a system in place, is that 
   everyone,
   everywhere, can start listening to the messages and using them, opening 
   up lots
   of doors for people to make amazing services based on Debian.
  
   A few ideas:
- getting a signal from the archive on an accepted package (I'm 
   confusing
  binaries and sources for the sake of brevity):
  → Trigger a piuparts run
  → Trigger lintian checks
  → Let any derivative intent a rebuild
  → Signal ports to rebuild
  → Trigger a jenkins job on specific package uploads
  → Post to pump.io/identi.ca/twitter
  → get a notification on your desktop
  → ...
- one of your pet packages gets a git commit
  → try a rebuild
  → run QA checks
  → ...
  
   (boy, that escalated quickly)
  
   I think the possibilities are quite nice, and, as the fedmsg webpage 
   says, that
   gives new meaning to open infrastructure.
   Two features I'd like to implement during this GSoC that are not AFAICT
   already present in fedmsg are GPG support and some kind of playback
   mechanism for the systems where it is important that all messages are
   sent and received (there are some others where the information would
   have value only at the time of emitting, I suppose).
  
   Questions, comments?
  
  ZeroMQ is a very lightweight solution - it is brokerless (like
  multicast) so won't necessarily support the requirement for durable
  subscriptions (keeping messages queued up for clients that are disconnected)
  http://www.zeromq.org/topics:requirements-for-reliability
  
  Some things that are worth looking at:
  
  - do we want to use an AMQP broker? In theory, this is an open standard
  like SMTP: the clients and brokers are interchangeable
  
  - as an alternative, could we use something like SIP or XMPP as a
  messaging platform? Then people can receive messages in their chat
  client. In this case it doesn't appear to be the optimal solution, but
  these protocols are quite good for systems that are very widely
  distributed over public networks.
  
  - then again, there are plenty of examples of systems like Apache Camel
  that can take a message from a traditional broker and deliver it to just
  about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
  other possible destinations:
  http://camel.apache.org/components.html
  and it can use Java or XML to describe various filters and transforms
  
  
  
  -- 
  To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
  with a subject of unsubscribe. Trouble? Contact 
  listmas...@lists.debian.org
  Archive: http://lists.debian.org/51794ceb@pocock.com.au
  
 
 Guys, we're *days* into student applications. We should have had this
 nailed down weeks ago.
 
 Pick something, go with it, or let's stop this early. Really; we should
 be fielding students now, now bikesheading over this stuff.

OK. It's not Bikesheading, I read the rest of the thread. I'm a bit out
of order.

I'm still not pleased it's still up for discussion, this puts slot
allocation into a funny place where the GSoC team has to decide if we
can bet on a project with a huge payout but is ill defined.

I'll shut up and get out of this thread, but we should *really* nail
this down, like, in the next few days.

 
 Cheers,
  Paul
 

Sorry!
  Paul

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


signature.asc
Description: Digital signature

Re: GSoC project: fedmsg for the Debian infrastructure

Quoting Daniel Pocock (2013-04-25 17:34:03)
 ZeroMQ is a very lightweight solution - it is brokerless (like
 multicast) so won't necessarily support the requirement for durable
 subscriptions (keeping messages queued up for clients that are disconnected)
 http://www.zeromq.org/topics:requirements-for-reliability
As I mentionned in my original email (granted, without expanding much on
it), I plan to implement a mechanism to solve this very problem by
keeping the messages sent on the emitter side and resending them on
demand.

 Some things that are worth looking at:
 
 - do we want to use an AMQP broker? In theory, this is an open standard
 like SMTP: the clients and brokers are interchangeable

This solution has been already examined by the Fedora folks, and
rejected by lack of scalability WRT the broker. This sort of question is
actually why I think it is a good idea to use fedmsg because its authors
have needs that are quite similar to ours, and virtually the same use
cases.

 - as an alternative, could we use something like SIP or XMPP as a
 messaging platform? Then people can receive messages in their chat
 client. In this case it doesn't appear to be the optimal solution, but
 these protocols are quite good for systems that are very widely
 distributed over public networks.
Correct me if I'm wrong, but isn't SIP specific to VoIP?
I don't know much about XMPP outside of its application in chatting.

 - then again, there are plenty of examples of systems like Apache Camel
 that can take a message from a traditional broker and deliver it to just
 about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
 other possible destinations:
 http://camel.apache.org/components.html
 and it can use Java or XML to describe various filters and transforms
See above.

Cheers,
Simon


signature.asc
Description: signature

Re: GSoC project: fedmsg for the Debian infrastructure

Quoting Paul Tagliamonte (2013-04-25 18:04:26)
 OK. It's not Bikesheading, I read the rest of the thread. I'm a bit out
 of order.
 
 I'm still not pleased it's still up for discussion, this puts slot
 allocation into a funny place where the GSoC team has to decide if we
 can bet on a project with a huge payout but is ill defined.
As far as I'm concerned, this would almost be an all or nothing deal,
I've already done quite a bit of work on fedmsg and I don't really have
the courage to throw it all away and begin again with another software
stack.

/me goes and ask ansgar about the dak test GSoC stuff :-)


signature.asc
Description: signature

Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

2013-04-25 Thread Ben Longbons

Package: general
Severity: wishlist

Introduction:
  This is my attempt at explaining exactly what frustrations prevent me from
  doing anything with Debian packages, and how another distro (Gentoo) does
  it better. The fact that Gentoo is a source-based distro is irrelevant.

  I hope you will seriously consider the issues here for jessie, rather than
  replying we understand our system, if others don't that's their problem.

First some definitions:
  Ordinary Developer:
A debian user who is comfortable enough with command-line to install
programs in /usr/local. They want to perform Simple Tasks.
  Simple Tasks:
quick:
  Given a program that is not packaged for Debian and is not
  sufficiently useful to the general public to be worth the maintenance
  burden, install it such that the package manager knows about it.
distribute:
  Given a completed set of package information for such a package,
  distribute it in a way that is easy for others to install.
patch:
  Given a program with a buggy upstream release, apply a patch.
revert:
  Given a program with buggy Debian packaging, revert a patch.
upgrade:
  Given a program that is packaged in Debian, upgrade to an unpackaged
  version.

The problems with the way Debian does it are:
  - debian/ is a subdirectory of the extracted source tree.
  - Because of the above, debian/rules tries to know about backwards steps.
  - There are too many files that need to be modified.
  - There are too many arcane commands that have to be called.
  - It's not obvious how to build except from apt-get source.
  - It's not obvious how to modify the patch set directly.
  - There is no attempt at managing multiple source versions.

How Simple Tasks are approached:
  quick:
Debian:
  - checkinstall is buggy, quirky, and has no upgrade path.
  - I still haven't figured out how to do this easily. Based on the
'hello' package, which is the simplest possible package, this
requires writing a hundred lines of voodoo. A random sampling of
existing package I've looked at agrees with this as a lower bound.
Gentoo:
  - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo
  - That may look like oversimplification, but the contents of
foo-1.ebuild really are very simple.
  distribute:
Debian:
  - Still haven't figured out the right way.
  - I did find the 'dget' command that does some things. How was I
supposed to know about this obscure command for a common use case?
  - You probably have to ship the whole huge .orig.tar.gz file, even
though it's available on the internet under a different name, or
even if it's really a git snapshot.
Gentoo:
  - Put foo-1.ebuild somewhere online (typically in a git repo)
  - foo-1.ebuild contains the URL of the upstream tarball or git repo.
  patch:
Debian:
  - After trying to make local changes, it said: dpkg-source --commit
  - But it is tedious when you already have a full patch from upstream.
Gentoo:
  - Assume that you're competent enough to get ahold of a patch.
  - Add the patch to files/ (which is shared between all versions of
the package, though you can of course use a different name).
  - Add the filename to the PATCHES=() variable, remanifest.
  revert:
Debian:
  - no clue, it keeps trying to readd the changes and it's not obvious
how to wipe the working tree.
Gentoo:
  - Remove the filename from the PATCHES=() variable, remanifest.
  upgrade:
Debian:
  - Hope it's in experimental.
  - Hope its experimental package is not broken.
  - Hope adding an experimental package won't break dependencies in the
rest of your system.
Gentoo:
  - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest
  - Typically, the source URL will automatically change based on the
version number. If this is not the case, it is very obvious to fix.

In conclusion:
  The current Debian way is complicated. The Gentoo way is simple. This is
  not tied to the fact that Gentoo is a source-based distribution, although
  that does encourage the right mindset.

  For evidence, look at the simplicity of:
- 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/hello/hello-2.8.ebuild?view=markup
- http://devmanual.gentoo.org/eclass-reference/ebuild/index.html

  Do NOT add yet another packaging tutorial or yet another set of helper
  scripts. There are too many as it is - they are just confusing and long.
  For the things that I'm talking about, Gentoo gets along just fine with a
  manpage - though they have a slightly longer guide for official packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130425162202.31360.43414.reportbug@ben-laptop.local

Re: Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library

2013-04-25 Thread Julian Taylor

On 25.04.2013 18:01, Alessandro Ghedini wrote:
 Package: wnpp
 Owner: Alessandro Ghedini gh...@debian.org
 Severity: wishlist
 X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
 
 * Package name: libzmq-libzmq2-perl
   Version : 1.07
   Upstream Author : Daisuke Maki dais...@endeworks.jp
 * URL : https://metacpan.org/release/ZMQ-LibZMQ2/
 * License : Artistic or GPL-1+
   Programming Lang: Perl
   Description : Perl bindings to the libzmq 2.x library
 
 Ã˜MQ is a library which extends the standard socket interfaces with features
 traditionally provided by specialised messaging middleware products.
 
 Ã˜MQ sockets provide an abstraction of asynchronous message queues, multiple
 messaging patterns, message filtering (subscriptions), seamless access to
 multiple transport protocols and more.
 
 ZMQ::LibZMQ2 is a thin Perl wrapper around the libzmq 2.x C API.
 
 


what is the difference to libzeromq-perl that we already have in unstable?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51795b97.7070...@googlemail.com

Re: jpeg8 vs jpeg-turbo

On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
bill.allomb...@math.u-bordeaux1.fr wrote:
 On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
 Hi Bill and Debian Developers,

 My proposal is:
 A. Add libjpeg-turbo to Debian archive (that's easy)
 B. Add required provides/alternatives for libjpeg62-dev and
 libjpeg8-dev (where API/ABI match)
 C. Decide which package should provide default libjpeg-dev library

 1. 
 https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034

 As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more 
 feature.

 I do not see libjpeg-turbo as a suitable replacement. It has
 1) an different license.
 2) much more security issues in a much smaller timeframe.
 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.

Bill,

sorry to barge in, but as a maintainer of the most prominent rev-deps
of libjpeg (libgd2  php5-gd), I would like to have some questions
answered, and I cannot find the answer neither on http://www.ijg.org/
nor http://www.infai.org/jpeg/.

1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
2. What's the legal status of IJG?
3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
4. Is there a (public) bug tracker?
5. Is there a source repository?
6. Is there a mailing list for libjpeg development/users?
7. How do I contribute code to IJG libjpeg?
8. There are new features incorporated to libjpeg? Is that a community
process? Or how are the changes driven? IJG (and the features they
implement in libjpeg) is independent from jpeg.org (the standards
committee).
9. Is there a documentation for new features of libjpeg (DCT,
SmartScale), so independent implementations can be done?
10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
comment rant under: http://blog.kaourantin.net/?p=116)

I haven't been able to find answers at IJG or any linked sites, so as
you are so far the only one taking stand for IJG jpeg implementation,
I would like to to help me to answer those questions.

I wouldn't bother to care about libjpeg in Debian, but it's one of the
core graphics libraries, and I think we should strive for good
compatibility with the rest of the distros, applications and our
users. And the 'new features' of libjpeg seems to contradict this.

Ondrej
--
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg-6u1y0v50zxuzn-2zcgomxy0dg5qb7cqsyc2m1zlz...@mail.gmail.com

Re: Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library

On gio, apr 25, 2013 at 06:36:39 +0200, Julian Taylor wrote:
 On 25.04.2013 18:01, Alessandro Ghedini wrote:
  * Package name: libzmq-libzmq2-perl
Version : 1.07
Upstream Author : Daisuke Maki dais...@endeworks.jp
  * URL : https://metacpan.org/release/ZMQ-LibZMQ2/
  * License : Artistic or GPL-1+
Programming Lang: Perl
Description : Perl bindings to the libzmq 2.x library
 
  [...]

 what is the difference to libzeromq-perl that we already have in unstable?

The ZeroMQ module (libzeromq-perl) is deprecated in favour of ZMQ::LibZMQ2
(libzmq-libzmq2-perl), ZMQ::LibZMQ3 and ZMQ. My intention would be to have
libzeromq-perl removed at some point soon (this is why it's not in wheezy, also
see #690680) but it's been taking me a long time (mostly because of a lack of
free time from my part).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Nicolas Dandrimont

* Daniel Pocock dan...@pocock.com.au [2013-04-25 17:34:03 +0200]:

 On 25/04/13 13:50, Simon Chopin wrote:
  [ description of the fedmsg project ]
  Questions, comments?
 
 ZeroMQ is a very lightweight solution - it is brokerless (like
 multicast) so won't necessarily support the requirement for durable
 subscriptions (keeping messages queued up for clients that are disconnected)
 http://www.zeromq.org/topics:requirements-for-reliability
 
 Some things that are worth looking at:
 
 - do we want to use an AMQP broker? In theory, this is an open standard
 like SMTP: the clients and brokers are interchangeable

As Simon already said, the Fedora people have tested this and rejected it
because it didn't scale.

 - as an alternative, could we use something like SIP or XMPP as a
 messaging platform? Then people can receive messages in their chat
 client. In this case it doesn't appear to be the optimal solution, but
 these protocols are quite good for systems that are very widely
 distributed over public networks.
 
 - then again, there are plenty of examples of systems like Apache Camel
 that can take a message from a traditional broker and deliver it to just
 about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
 other possible destinations:
 http://camel.apache.org/components.html
 and it can use Java or XML to describe various filters and transforms

Those are interesting suggestions, I actually had a look at Camel when it was
suggested to us on another thread, but we will keep going on with fedmsg.

There are several reasons for doing so:
 - It is currently implemented in Fedora, on an infra that is different to ours
   but has similar components

 - This allows for tool interoperability between distros, and why not for
   inter-distro collaboration

 - It's python, which fits very well with most of our stack

 - Upstream has been super, super helpful so far, and I don't see this changing

I wanted Simon to start this thread to gather ideas: I know some people, mostly
in DSA, have thought about such a system for some time, so this was more of a
heads-up than wanting to reconsider the project from scratch. It landed on
-devel because, well, we couldn't find a more appropriate list :)

To get back to your remark, it would definitely be possible to build a
fedmsg-to-xmpp filtering bridge, if there is interest, but that's not really
the scope of this GSoC project.

Cheers,
-- 
Nicolas Dandrimont

BOFH excuse #124:
user to computer ration too low.


signature.asc
Description: Digital signature

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Jonas Smedegaard

Quoting Simon Chopin (2013-04-25 18:07:29)
 Quoting Daniel Pocock (2013-04-25 17:34:03)
  ZeroMQ is a very lightweight solution - it is brokerless (like 
  multicast) so won't necessarily support the requirement for durable 
  subscriptions (keeping messages queued up for clients that are 
  disconnected) 
  http://www.zeromq.org/topics:requirements-for-reliability
 As I mentionned in my original email (granted, without expanding much 
 on it), I plan to implement a mechanism to solve this very problem by 
 keeping the messages sent on the emitter side and resending them on 
 demand.

Hmm - so essentially you will follow a standard for low-level transport 
of messages, but invent something custom for the slightly higher level 
QoS handling. Sounds odd to me.


  Some things that are worth looking at:
  
  - do we want to use an AMQP broker? In theory, this is an open 
  standard like SMTP: the clients and brokers are interchangeable
 
 This solution has been already examined by the Fedora folks, and 
 rejected by lack of scalability WRT the broker. This sort of question 
 is actually why I think it is a good idea to use fedmsg because its 
 authors have needs that are quite similar to ours, and virtually the 
 same use cases.

Fair enough.

Could you perhaps point to the relevant prior discussions - I am curious 
what they found bad about AMQP, and also curious if they had considered 
MQTT which seems the perfect fit for this (simpler than AMQP, yet 
includes simple QoS and simple authentication not in 0MQ).


Good luck with the project - it sounds quite exciting!

 - Jonas

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

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425172009.28196.54...@bastian.jones.dk

Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

2013-04-25 Thread Wouter Verhelst

Hi Ben,

On 25-04-13 18:22, Ben Longbons wrote:
 Package: general
 Severity: wishlist
[...long introduction snipped]
 How Simple Tasks are approached:
   quick:
 Debian:
   - checkinstall is buggy, quirky, and has no upgrade path.
   - I still haven't figured out how to do this easily. Based on the
 'hello' package, which is the simplest possible package,

That's a misconception. The hello package shows how to build a Debian
package *without using any helper programs*. Almost nobody ever does
that anymore; I'm not sure why that package still exists. If you want an
example for how to really do things in practice, you should look at
hello-debhelper. Its debian/rules and debian/rules-dh files are much
simpler.

 this
 requires writing a hundred lines of voodoo. A random sampling of
 existing package I've looked at agrees with this as a lower bound.
 Gentoo:
   - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo
   - That may look like oversimplification, but the contents of
 foo-1.ebuild really are very simple.

By that rationale, building a Debian package simply requires mkdir
debian; vim debian/rules; vim debian/control; dch --create; touch
debian/copyright; dpkg-buildpackage. The contents of debian/rules and
debian/control is really simple, dch helps you when creating a
changelog, and an *empty* debian/copyright file is syntactically valid
(though not semantically, of course).

   distribute:
 Debian:
   - Still haven't figured out the right way.
   - I did find the 'dget' command that does some things. How was I
 supposed to know about this obscure command for a common use case?

dget isn't something we expect people not involved in the development of
Debian to use, so it's not documented in user-level documentation.

For distributing source packages, you put them in a directory and call
dpkg-scansources; users can then use apt-get source on that repository.

Of course, for Debian you don't ship sources, you ship binaries. For
that, there is dpkg-scanpackages. If you need to do a lot more than just
one or two packages, there are other tools, such as reprepro, which
allow you to just put files in a directory somewhere, and it's magically
moved to the right place, with the right index files updated.

If you're not interested in all that, you don't need to ship the .dsc or
.deb files; if as an upstream you just want to ship debian packaging
files, all you need to do is ship the debian/ directory. This Just
Works(TM).

   - You probably have to ship the whole huge .orig.tar.gz file, even
 though it's available on the internet under a different name, or
 even if it's really a git snapshot.

If you want to provide a Debian source package, then yes, that's what
you need to do. However, you don't need to provide a full Debian source
package if all you want to do is to allow people to easily build a .deb
file.

[...too bored to come up with a reply to these...]
   upgrade:
 Debian:
   - Hope it's in experimental.
   - Hope its experimental package is not broken.
   - Hope adding an experimental package won't break dependencies in the
 rest of your system.

- Run apt-get -d source package, fetch the new upstream source, run
uupdate with the right arguments (read the manpage for the details).
Unless it's something very complex, that will almost certainly work.

If, OTOH, it *is* something very complex, then this...

 Gentoo:
   - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest

... won't work either.

   - Typically, the source URL will automatically change based on the
 version number. If this is not the case, it is very obvious to fix.

That's not an issue for Debian, as we ship upstream tarballs ourself,
rather than relying on upstream for that. It has some downsides (as you
correctly point out above), but also some upsides. This is one of them
(there are more)

 In conclusion:
   The current Debian way is complicated. The Gentoo way is simple.

For you.

To this Debian developer who's never done any Gentoo work, the Gentoo
way is complicated and the Debian way is simple.

Put otherwise, going to one distribution and saying you guys are doing
it all wrong, look at how $OTHER distribution is doing it, you should do
it their way!!1! isn't very convincing.

-- 
Copyshops should do vouchers. So that next time some bureaucracy
requires you to mail a form in triplicate, you can mail it just once,
add a voucher, and save on postage.


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

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Luca Filipozzi

On Thu, Apr 25, 2013 at 07:20:09PM +0200, Jonas Smedegaard wrote:
 Quoting Simon Chopin (2013-04-25 18:07:29)
  Quoting Daniel Pocock (2013-04-25 17:34:03)
   ZeroMQ is a very lightweight solution - it is brokerless (like 
   multicast) so won't necessarily support the requirement for durable 
   subscriptions (keeping messages queued up for clients that are 
   disconnected) 
   http://www.zeromq.org/topics:requirements-for-reliability
 
  As I mentionned in my original email (granted, without expanding much 
  on it), I plan to implement a mechanism to solve this very problem by 
  keeping the messages sent on the emitter side and resending them on 
  demand.
 
 Hmm - so essentially you will follow a standard for low-level transport 
 of messages, but invent something custom for the slightly higher level 
 QoS handling. Sounds odd to me.
 
   Some things that are worth looking at:
   
   - do we want to use an AMQP broker? In theory, this is an open 
   standard like SMTP: the clients and brokers are interchangeable
  
  This solution has been already examined by the Fedora folks, and 
  rejected by lack of scalability WRT the broker. This sort of question 
  is actually why I think it is a good idea to use fedmsg because its 
  authors have needs that are quite similar to ours, and virtually the 
  same use cases.
 
 Fair enough.
 
 Could you perhaps point to the relevant prior discussions - I am curious 
 what they found bad about AMQP, and also curious if they had considered 
 MQTT which seems the perfect fit for this (simpler than AMQP, yet 
 includes simple QoS and simple authentication not in 0MQ).

Indeed.  Both MQTT [1] and PZQ [2] seem interesting, which is hard or me to say
given my unabashed bias towards WSO2.

If we are wed to fedmsg and fedmsg is wed to ZeroMQ, then I'd be interested in
leveragingone of MQTT or PZQ for QoS.

[1] http://mqtt.org/
[2] https://github.com/mkoppanen/pzq/wiki/An-Introduction-To-PZQ

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425182408.ga24...@emyr.net

Bug#706162: ITP: luxio -- Posix bindings for Lua

2013-04-25 Thread Lars Wirzenius

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius l...@liw.fi

* Package name: luxio
  Version : 1.0
  Upstream Author : Rob Kendrick rjek+lu...@rjek.com
* URL : http://www.rjek.com/software.html
* License : MIT (Same as Lua)
  Programming Lang: Lua
  Description : Posix bindings for Lua

Lightweight UNIX I/O and POSIX binding for Lua

1. Reasonably good coverage of POSIX and BSD Sockets, including IPv6,
   and some GNU extensions.
2. Meant to be buildable anywhere that is POSIX.1-1996.  If it's not,
   there's a bug.  These are likely, as I have nowhere other than
   Linux to test.
3. Low-level.  You get the return values and the errno for the bound
   functions where possible.  Others take a table to fill in, or
   may return tables.
4. High-level wrapper library providing nice IO access and to misc.
   utility functions.  Generates useful errors in assert()able form,
   and provides meaningful __tostring metamethods to aid debugging.
5. A high-level poll()-based event dispatch library.
6. Sub-process handling library (read/write io.popen with job control).
7. A prototype POSIX Message Queue-based IPC scheme that can serialise
   most simple Lua values.  (No closures, userdata, etc)

This package is needed as a dependency for Gitano, for which an ITP will
be filed later.

I will be co-maintaining this package with Daniel Silverstone.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130425182657.411.13242.report...@havelock.liw.fi

Re: Bug#602034: jpeg8 vs jpeg-turbo

2013-04-25 Thread Mike Gabriel


Hi all,

On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote:


On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
bill.allomb...@math.u-bordeaux1.fr wrote:

On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:

Hi Bill and Debian Developers,

My proposal is:
A. Add libjpeg-turbo to Debian archive (that's easy)
B. Add required provides/alternatives for libjpeg62-dev and
libjpeg8-dev (where API/ABI match)
C. Decide which package should provide default libjpeg-dev library

1.  
https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian

2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034


As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has  
more feature.


I do not see libjpeg-turbo as a suitable replacement. It has
1) an different license.
2) much more security issues in a much smaller timeframe.
3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.


Bill,

sorry to barge in, but as a maintainer of the most prominent rev-deps
of libjpeg (libgd2  php5-gd), I would like to have some questions
answered, and I cannot find the answer neither on http://www.ijg.org/
nor http://www.infai.org/jpeg/.

1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
2. What's the legal status of IJG?
3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
4. Is there a (public) bug tracker?
5. Is there a source repository?
6. Is there a mailing list for libjpeg development/users?
7. How do I contribute code to IJG libjpeg?
8. There are new features incorporated to libjpeg? Is that a community
process? Or how are the changes driven? IJG (and the features they
implement in libjpeg) is independent from jpeg.org (the standards
committee).
9. Is there a documentation for new features of libjpeg (DCT,
SmartScale), so independent implementations can be done?
10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
comment rant under: http://blog.kaourantin.net/?p=116)


All questions are really good questions. Some of them have already  
been answered in the backlogs of #602034 [1] and the-merged-with bug  
#612341 [2].


Reading through both of them is probably a good idea for all who are  
interested in the complete story.


Esp. some statements from Guido Vollbeding [3] make me ask myself:  
hey, what kind of guy is that and what is the stand of the IJG in the  
free software ecosystem. His arguing tends to be somehow aggressive  
and inbalanced. One quote that shows what I mean (taken from [3]):



It seems that Bill Allombert is still one of the few sane people out
there, many others have apparently gone mad.
I don't care for the ignorant people.


@Bill: Unfortunately, I am not an expert with image processing, but  
most of what I have read in this thread speaks for re-thinking the  
current strategy of staying with libjpeg IJG.


Can this be a proposal? Package libjpeg and libjpeg-turbo using an  
alternatives setup and thus, making both libs installable in parallel.  
Packagers can then build-depend on one or the other libjpeg  
implementations.


Greets,
Mike

[1] http://bugs.debian.org/602034
[2] http://bugs.debian.org/612341
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612341#116


--

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

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

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

pgpqfFSaGlVaK.pgp
Description: Digitale PGP-Unterschrift

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Daniel Pocock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/04/13 18:07, Simon Chopin wrote:
 Quoting Daniel Pocock (2013-04-25 17:34:03)
 ZeroMQ is a very lightweight solution - it is brokerless (like 
 multicast) so won't necessarily support the requirement for
 durable subscriptions (keeping messages queued up for clients
 that are disconnected) 
 http://www.zeromq.org/topics:requirements-for-reliability
 As I mentionned in my original email (granted, without expanding
 much on it), I plan to implement a mechanism to solve this very
 problem by keeping the messages sent on the emitter side and
 resending them on demand.

That seems like extra work to do something that can already be done in
a standard way, and it also seems like it is just transferring the
scalability problems from the brokers to the message sources.

 Some things that are worth looking at:
 
 - do we want to use an AMQP broker? In theory, this is an open
 standard like SMTP: the clients and brokers are interchangeable
 
 This solution has been already examined by the Fedora folks, and 
 rejected by lack of scalability WRT the broker. This sort of
 question is actually why I think it is a good idea to use fedmsg
 because its authors have needs that are quite similar to ours, and
 virtually the same use cases.

Red Hat promotes a number of messaging solutions, I've used several of
these things commercially - they publish a very interesting roadmap[1]:
- - HornetQ new ultra high performance enterprise grade messaging
- - MRG Messaging (based on Qpid) Exploits Linux-specific optimizations
for performance
- - Fuse MQ (based on ActiveMQ)
- - JBoss XQ Messaging

and I'm surprised that they ruled them all out and went for ZeroMQ

OpenStack is working with RabbitMQ, it is based on a broker paradigm too

My own feeling is that brokers do scale to some extent: if reliable
delivery is a requirement, then you just have to buy the right
hardware to run the broker at scale.

 - as an alternative, could we use something like SIP or XMPP as
 a messaging platform? Then people can receive messages in their
 chat client. In this case it doesn't appear to be the optimal
 solution, but these protocols are quite good for systems that are
 very widely distributed over public networks.
 Correct me if I'm wrong, but isn't SIP specific to VoIP? I don't
 know much about XMPP outside of its application in chatting.

In practice, that is how they are used, but they are interchangeable
for both purposes. (and please see [2], feedback needed!)

SIP supports methods such as MESSAGE, SUBSCRIBE and NOTIFY which could
provide some very interesting ways to distribute data to
intermittently connected developers in all the odd locations where we
choose to have our workstations.

These protocols may not be at the core of the solution, they could
just be an external interface.


On 25/04/13 19:13, Nicolas Dandrimont wrote:
 * Daniel Pocock dan...@pocock.com.au [2013-04-25 17:34:03
 +0200]:

 - then again, there are plenty of examples of systems like Apache
 Camel that can take a message from a traditional broker and
 deliver it to
just
 about anything: SIP, XMPP, email, IRC channel, syslog, Nagios +
 200 other possible destinations: 
 http://camel.apache.org/components.html and it can use Java or
 XML to describe various filters and transforms
 
 Those are interesting suggestions, I actually had a look at Camel
when it was
 suggested to us on another thread, but we will keep going on with
fedmsg.


I didn't necessarily suggest that Camel would replace fedmsg.  I have
used it in much larger environments where it has been the core
component for mediating messaging workflows, running multiple
instances in parallel off a HA message broker.  As such, I'm confident
it could scale well enough to replace fedmsg, but that is not what I'm
arguing - I'm just suggesting that it is a useful tool.  fedmsg could
well be the core of the solution, and a couple of Camel instances
could be set up to implement custom workflows and deliver messages (or
derivatives of the messages) over transports that fedmsg doesn't
natively support.

 I wanted Simon to start this thread to gather ideas: I know some
people, mostly
 in DSA, have thought about such a system for some time, so this
 was
more of a
 heads-up than wanting to reconsider the project from scratch. It
landed on
 -devel because, well, we couldn't find a more appropriate list :)
 
 To get back to your remark, it would definitely be possible to
 build a fedmsg-to-xmpp filtering bridge, if there is interest, but
 that's
not really
 the scope of this GSoC project.

I agree the GSoC scope needs to be contained, but it would also be
good to have a wider architecture in mind and understand how things
fit together, so please don't feel I'm hijacking that - I just saw the
request for comments and was keen to help.

fedmsg may well be the best way forward, but it would be interesting
to know if we can make the messaging platform interchangeable, perhaps

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Stephen Gran

Hi,

This one time, at band camp, Simon Chopin said:
 Hi,
 
 Nicolas Dandrimont and I are currently working on a project proposal for
 the Google Summer of Code to use the messaging system written by Fedora,
 fedmsg[0][1], within the Debian infrastructure (some of you might have seen
 the various ITPs related to that on -devel).
 
 Tollef kindly pointed out to us that Debian service administrators would
 probably have something to say about all this, so here we are.
 
 As a premise, please note that we obviously plan to make fedmsg
 distro-agnostic before anything else (than packaging). The original
 upstream author seems very enthousiastic about the project, which makes
 it probable that we won't have to carry those patches on our own.
 
 The thing itself is based on the ZeroMQ protocol.

One of the principles, up to now, of system design for the debian.org
infrastructure has been that it can tolerate single nodes being off line
for periods of time.  My understanding of ZeroMQ is that it doesn't do
very well when the sender and the receiver aren't on line at the same
time.  I have not used ZeroMQ in any serious way, so I'm only repeating
what I've heard.  Please correct me if I'm wrong.

It may be time to revisit our assumptions, of course - our hosting is
dramatically better than it was when I joined the project, and even
since I started doing DSA work.

Thanks for looking into it - something like this would be very useful
for us.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

2013-04-25 Thread Philip Hands

Wouter Verhelst wou...@debian.org writes:
...
 Put otherwise, going to one distribution and saying you guys are doing
 it all wrong, look at how $OTHER distribution is doing it, you should do
 it their way!!1! isn't very convincing.

It's particularly unconvincing if one has witnessed the Gentoo BoF at
this year's FOSDEM[1], in which they discussed the deep joy of having
users who patch packages into a state of uselessness, and then report
bugs against the result without mentioning that they broke the package
themselves.

We have a packaging system that rewards people that read up on the tools
we provide for doing the simple tasks one might expect to be able to do
with it.  Conversely, it punishes those that don't.

If those that expect to be able to do this sort of thing without
consulting any documentation are encouraged to go elsewhere by this
fact, then I'd say that's a feature, not a bug.

Cheers, Phil.

[1] I filmed that session:

  http://mirror.be.gbxs.net/video.fosdem.org//2013/crossdistro/Gentoo_BoF.webm

The relevant bit starts at 11:10, with a very salient quote almost
immediately from Petteri Räty (betelgeuse):

  I think user patching should be a _bit_ hard ... it's a support
  nightmare. Unless well thought out, all the bugs coming in to
  gentoo.org, debugging becomes ... complicated

-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpSd9MDsYVYA.pgp
Description: PGP signature

Re: Bug#602034: jpeg8 vs jpeg-turbo

2013-04-25 Thread Ben Hutchings

On Thu, 2013-04-25 at 20:49 +0200, Mike Gabriel wrote:
 Hi all,
 
 On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote:
 
  On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
  bill.allomb...@math.u-bordeaux1.fr wrote:
  On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
  Hi Bill and Debian Developers,
 
  My proposal is:
  A. Add libjpeg-turbo to Debian archive (that's easy)
  B. Add required provides/alternatives for libjpeg62-dev and
  libjpeg8-dev (where API/ABI match)
  C. Decide which package should provide default libjpeg-dev library
 
  1.  
  https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
  2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
  3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034
 
  As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has  
  more feature.
 
  I do not see libjpeg-turbo as a suitable replacement. It has
  1) an different license.
  2) much more security issues in a much smaller timeframe.
  3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.
 
  Bill,
 
  sorry to barge in, but as a maintainer of the most prominent rev-deps
  of libjpeg (libgd2  php5-gd), I would like to have some questions
  answered, and I cannot find the answer neither on http://www.ijg.org/
  nor http://www.infai.org/jpeg/.
 
  1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
  2. What's the legal status of IJG?
  3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
  4. Is there a (public) bug tracker?
  5. Is there a source repository?
  6. Is there a mailing list for libjpeg development/users?
  7. How do I contribute code to IJG libjpeg?
  8. There are new features incorporated to libjpeg? Is that a community
  process? Or how are the changes driven? IJG (and the features they
  implement in libjpeg) is independent from jpeg.org (the standards
  committee).
  9. Is there a documentation for new features of libjpeg (DCT,
  SmartScale), so independent implementations can be done?
  10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
  comment rant under: http://blog.kaourantin.net/?p=116)
 
 All questions are really good questions. Some of them have already  
 been answered in the backlogs of #602034 [1] and the-merged-with bug  
 #612341 [2].
 
 Reading through both of them is probably a good idea for all who are  
 interested in the complete story.
 
 Esp. some statements from Guido Vollbeding [3] make me ask myself:  
 hey, what kind of guy is that and what is the stand of the IJG in the  
 free software ecosystem. His arguing tends to be somehow aggressive  
 and inbalanced. One quote that shows what I mean (taken from [3]):
[...]

He also says that he is treating his libjpeg as 'reference code' for
JPEG, i.e. for demonstrating and testing extensions to the JPEG
standard.  This does not sound like production code or a suitable
substitute for the established libjpeg which supported JFIF and little
else (i.e. everything that's in common use) and had a very stable API
for that.  Maybe when the ink is dry on JPEG 201x then we will want a
new libjpeg (perhaps an entirely separate library) that supports it.
But we don't need it now.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


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

Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

2013-04-25 Thread Wookey

+++ Ben Longbons [2013-04-25 09:22 -0700]:
 Package: general
 Severity: wishlist
 
 Introduction:
   This is my attempt at explaining exactly what frustrations prevent me from
   doing anything with Debian packages, and how another distro (Gentoo) does
   it better. The fact that Gentoo is a source-based distro is irrelevant.

Not entirely irrelevant, as you admit yourself later. 

And I think you are rather more familiar with gentoo than debian so
stuff seems simpler because you already know what to do. The converse
applies too.

   patch:
 Debian:
   - After trying to make local changes, it said: dpkg-source --commit
   - But it is tedious when you already have a full patch from upstream.

actually this is just the same in Debian as in Gentoo: put the patch in
debian/patches and add its name to debian/patches/series

Applying the patch to the sources first and doing dpkg-source --commit
(*as above) also works (more reliably as it forces you to check that
the patch actually applies here). Neither seems hard to me. 

 Gentoo:
   - Assume that you're competent enough to get ahold of a patch.
   - Add the patch to files/ (which is shared between all versions of
 the package, though you can of course use a different name).
   - Add the filename to the PATCHES=() variable, remanifest.
   revert:
 Debian:
   - no clue, it keeps trying to readd the changes and it's not obvious
 how to wipe the working tree.

Remove the patchname from debian/patches/series. Seems equivalent to your
Gentoo example to me.

 Gentoo:
   - Remove the filename from the PATCHES=() variable, remanifest.


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425190902.ga2...@stoneboat.aleph1.co.uk

Re: Bug#602034: jpeg8 vs jpeg-turbo

2013-04-25 Thread Pau Garcia i Quiles

Hello,

The KDE maintainer in Fedora started an interesting discussion some time
ago in Digikam's mailing list. There was input from the very IJG:

http://mail.kde.org/pipermail/digikam-devel/2013-January/066206.html

It boils down to jpeg6-2 is the only important thing. Forget about jpeg8
and jpeg9, which bring incompatible changes.

http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html

FWIW, Arch and Gentoo also follow the policy that jpeg6-2 (and jpeg-turbo
with 6-2 API/ABI) is the real deal.

On Wed, Apr 24, 2013 at 1:48 PM, Mike Gabriel
mike.gabr...@das-netzwerkteam.de wrote:

Hi Ondřej,

I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW
[1].

On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote:

Debian has already open ITP[3] #602034 for libjpeg-turbo, which
support libjpeg62 API/ABI and also some important bits of libjpeg8. As
libjpeg is one of the base libraries of the system, I think it might
be a good idea to discuss this project wide. Also although I have an
opinion (as you might have guessed from this email) that we should try
to be aligned with other distributions and the reasoning for not going
for , I will be happy with whatever result will end-up.

In an IRC discussion in #debian-devel several weeks ago the consensus was:
the RT team (represented Julien) will probably not want two libjpeg
implementations in Debian. My first packaging approach aimed at having the
compat mode libraries available [2] and allow the user to install them as a
drop-in replacement for libjpeg8.

The IRC discussion lead to the result that the compat packages are not
wanted in Debian, only the native TURBOjpeg ABI. I was asked to ping Bill
Allombert about his opinion to transition from libjpeg8 fully to
libjpeg8-turbo. @Bill: can you repeat your disposition here again? I guess
our earlier mailing was a private mail exchange.

A. Add libjpeg-turbo to Debian archive (that's easy)

Done. Waiting in NEW. Only containing libturbojpeg.so.1

B. Add required provides/alternatives for libjpeg62-dev and
libjpeg8-dev (where API/ABI match)

A packaging example can be seen in [1]. If the packages disappears from
the NEW queue, you can also obtain a libjpeg-turbo version with compat
packages provided here [3].

C. Decide which package should provide default libjpeg-dev library

Last statement from Bill: libjpeg by IJG

Greets,
Mike

[1]
http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-2.**htmlhttp://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-2.html
[2]
http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-1.**htmlhttp://ftp-master.debian.org/new/libjpeg-turbo_1.2.90-1.html
[3]
http://packages.x2go.org/**debian/pool/main/libj/libjpeg-**turbo/http://packages.x2go.org/debian/pool/main/libj/libjpeg-turbo/

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

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

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

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

not co-installable Multi-Arch:same packages (was: Re: Issues with Multi-Arch:same packages on purge)

2013-04-25 Thread Andreas Beckmann

On 2013-04-22 21:38, Andreas Beckmann wrote:
 On 2013-04-22 07:31, Guillem Jover wrote:
 I guess a way to detect those could be piuparts runs that install
 multiple instances of Multi-Arch:same packages, purge just one of
...
 Actually I already tried something similar some time ago, although I
 only focussed on co-installability problems. I didn't look into this
...

I just reran these tests (host: amd64, installing the foreign i386 packages) on 
current wheezy and will provide a short report here:

Many packages marked M-A:same are not co-installable due to unsatisfied 
dependencies (usually not all deps are properly multiarchified).
That's not a problem right now, apt will take care of this.

But there are some packages that qualify as co-installable, but fail to do so:

Uninstallable due to binNMU:
   trying to overwrite shared '/usr/share/doc/libbogl0/changelog.Debian.gz', 
which is different from other instances of package libbogl0:i386
   trying to overwrite shared 
'/usr/share/doc/libclutter-gst-1.0-0/changelog.Debian.gz', which is different 
from other instances of package libclutter-gst-1.0-0:i386
   trying to overwrite shared 
'/usr/share/doc/libclutter-gst-1.0-dbg/changelog.Debian.gz', which is different 
from other instances of package libclutter-gst-1.0-dbg:i386
   trying to overwrite shared '/usr/share/doc/libdmtx0a/changelog.Debian.gz', 
which is different from other instances of package libdmtx0a:i386
   trying to overwrite shared 
'/usr/share/doc/libftdi1-dbg/changelog.Debian.gz', which is different from 
other instances of package libftdi1-dbg:i386
   trying to overwrite shared '/usr/share/doc/libftdi1/changelog.Debian.gz', 
which is different from other instances of package libftdi1:i386
   trying to overwrite shared 
'/usr/share/doc/libftdipp1-dbg/changelog.Debian.gz', which is different from 
other instances of package libftdipp1-dbg:i386
   trying to overwrite shared '/usr/share/doc/libftdipp1/changelog.Debian.gz', 
which is different from other instances of package libftdipp1:i386
   trying to overwrite shared '/usr/share/doc/libmyodbc/changelog.Debian.gz', 
which is different from other instances of package libmyodbc:i386
   trying to overwrite shared '/usr/share/doc/libopenraw1/changelog.Debian.gz', 
which is different from other instances of package libopenraw1:i386
   trying to overwrite shared 
'/usr/share/doc/libopenrawgnome1/changelog.Debian.gz', which is different from 
other instances of package libopenrawgnome1:i386
   trying to overwrite shared '/usr/share/doc/libpano13-2/changelog.Debian.gz', 
which is different from other instances of package libpano13-2:i386
   trying to overwrite shared 
'/usr/share/doc/lua-sql-mysql-dev/changelog.Debian.gz', which is different from 
other instances of package lua-sql-mysql-dev:i386
   trying to overwrite shared 
'/usr/share/doc/lua-sql-mysql/changelog.Debian.gz', which is different from 
other instances of package lua-sql-mysql:i386
   trying to overwrite shared 
'/usr/share/doc/lua-sql-sqlite3-dev/changelog.Debian.gz', which is different 
from other instances of package lua-sql-sqlite3-dev:i386
   trying to overwrite shared 
'/usr/share/doc/lua-sql-sqlite3/changelog.Debian.gz', which is different from 
other instances of package lua-sql-sqlite3:i386
but otherwise dependencies are satisfied, so these might be candidates for 
no-change rebuilds to make them co-installable in wheezy.
Looks like this is a manageable amount of source packages:
  bogl clutter-gst libdmtx libftdi libopenraw libpano13 lua-sql myodbc

Debug packages:
   trying to overwrite shared '/usr/lib/debug/usr/lib/libffi.so.5.0.10', which 
is different from other instances of package libffi5-dbg:i386
Maybe this shouldn't have been MA:same.

Marked as MA:same but ship arch-specific files at shared locations:
   trying to overwrite shared 
'/usr/share/doc/libdmtx-dev/examples/net/Libdmtx.Net.Test/DmtxTest.cs.gz', 
which is different from other instances of package libdmtx-dev:i386
   trying to overwrite shared '/usr/share/doc/libreadline5/examples/Makefile', 
which is different from other instances of package libreadline-gplv2-dev:i386
   trying to overwrite shared 
'/usr/share/doc/libsylph-dev/examples/Makefile.gz', which is different from 
other instances of package libsylph-dev:i386
   trying to overwrite shared '/usr/share/info/udunits2.info.gz', which is 
different from other instances of package libudunits2-0:i386
   trying to overwrite shared '/usr/share/xfce4/helpers/mutt.desktop', which is 
different from other instances of package libexo-helpers:i386
These need to be bugged - what would be the correct severity?


Andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5179839e.6030...@debian.org

Re: [Soc-coordination] GSoC project: fedmsg for the Debian infrastructure

Quoting Stephen Gran (2013-04-25 21:17:29)
 Hi,
 
 This one time, at band camp, Simon Chopin said:
  Hi,
  
  Nicolas Dandrimont and I are currently working on a project proposal for
  the Google Summer of Code to use the messaging system written by Fedora,
  fedmsg[0][1], within the Debian infrastructure (some of you might have seen
  the various ITPs related to that on -devel).
  
  Tollef kindly pointed out to us that Debian service administrators would
  probably have something to say about all this, so here we are.
  
  As a premise, please note that we obviously plan to make fedmsg
  distro-agnostic before anything else (than packaging). The original
  upstream author seems very enthousiastic about the project, which makes
  it probable that we won't have to carry those patches on our own.
  
  The thing itself is based on the ZeroMQ protocol.
 
 One of the principles, up to now, of system design for the debian.org
 infrastructure has been that it can tolerate single nodes being off line
 for periods of time.  My understanding of ZeroMQ is that it doesn't do
 very well when the sender and the receiver aren't on line at the same
 time.  I have not used ZeroMQ in any serious way, so I'm only repeating
 what I've heard.  Please correct me if I'm wrong.

Well, as I understand it, when sender or receiver are not online, there
is simply no message passing. If your concern is about what happens to
the backlog when the consumer comes back online, then I've already
written about that earlier today :-)

 It may be time to revisit our assumptions, of course - our hosting is
 dramatically better than it was when I joined the project, and even
 since I started doing DSA work.
 
 Thanks for looking into it - something like this would be very useful
 for us.
Thanks for your input,

Cheers,
Simon



signature.asc
Description: signature

Re: not co-installable Multi-Arch:same packages (was: Re: Issues with Multi-Arch:same packages on purge)

2013-04-25 Thread Jakub Wilk


* Andreas Beckmann a...@debian.org, 2013-04-25, 21:27:
trying to overwrite shared '/usr/lib/debug/usr/lib/libffi.so.5.0.10', 
which is different from other instances of package libffi5-dbg:i386


#650106


Maybe this shouldn't have been MA:same.


There's no problem with -dbg packages being MA:same. They just need to 
use build-id-based paths. dh_strip does it for you in compat = 9.


trying to overwrite shared 
'/usr/share/doc/libdmtx-dev/examples/net/Libdmtx.Net.Test/DmtxTest.cs.gz', 
which is different from other instances of package libdmtx-dev:i386


I can't reproduce this in unstable.

trying to overwrite shared 
'/usr/share/doc/libreadline5/examples/Makefile', which is different 
from other instances of package libreadline-gplv2-dev:i386


#658850 (someone should reopen it...)

trying to overwrite shared 
'/usr/share/doc/libsylph-dev/examples/Makefile.gz', which is different 
from other instances of package libsylph-dev:i386


#675105

trying to overwrite shared '/usr/share/info/udunits2.info.gz', which is 
different from other instances of package libudunits2-0:i386


#706168

trying to overwrite shared '/usr/share/xfce4/helpers/mutt.desktop', 
which is different from other instances of package libexo-helpers:i386


#680009

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425200916.ga7...@jwilk.net

OpenMAMA?

2013-04-25 Thread Daniel Pocock




I'm just wondering if anybody else has looked at OpenMAMA or seen any
potential problems for packaging it?

http://www.openmama.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51798f5b.3010...@pocock.com.au

Re: not co-installable Multi-Arch:same packages (was: Re: Issues with Multi-Arch:same packages on purge)

2013-04-25 Thread Jakub Wilk


* Andreas Beckmann a...@debian.org, 2013-04-25, 21:27:

what would be the correct severity?


I've been using important (or normal, if only toy^Wexotic architectures 
were affected) for such file conflicts, regardless of whether you were 
able to reproduce the bug in practice by co-installing the packages in 
question.


You might find this script useful:
http://anonscm.debian.org/viewvc/collab-qa/multi-arch/report-multiarch-bug?view=markup

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425202429.ga...@jwilk.net

Re: Bug#602034: jpeg8 vs jpeg-turbo

2013-04-25 Thread Michael Biebl

Am 25.04.2013 20:49, schrieb Mike Gabriel:
 Can this be a proposal? Package libjpeg and libjpeg-turbo using an
 alternatives setup and thus, making both libs installable in parallel.
 Packagers can then build-depend on one or the other libjpeg
 implementations.

Please no. If libjpeg-turbo is the saner implementation, which reading
through the messages posted so far it seems like, let's switch to it fully.

Michael

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



signature.asc
Description: OpenPGP digital signature

Re: GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Wookey

+++ Nicolas Dandrimont [2013-04-25 19:13 +0200]:
 * Daniel Pocock dan...@pocock.com.au [2013-04-25 17:34:03 +0200]:
 
  - do we want to use an AMQP broker? In theory, this is an open standard
  like SMTP: the clients and brokers are interchangeable
 
 As Simon already said, the Fedora people have tested this and rejected it
 because it didn't scale.
 
 we will keep going on with fedmsg.
 
 There are several reasons for doing so:
  - It is currently implemented in Fedora, on an infra that is different to 
 ours
but has similar components
 
  - This allows for tool interoperability between distros, and why not for
inter-distro collaboration
 
  - It's python, which fits very well with most of our stack
 
  - Upstream has been super, super helpful so far, and I don't see this 
 changing
 
 I wanted Simon to start this thread to gather ideas: I know some people, 
 mostly
 in DSA, have thought about such a system for some time, so this was more of a
 heads-up than wanting to reconsider the project from scratch. It landed on
 -devel because, well, we couldn't find a more appropriate list :)

I'm not sure how much this helps, but it seems relevant so I'll add it
to the thoughts: Someone has already written a RabbitMQ (APMQ) based
distributed debian buildd system in python: 
https://github.com/nicholasdavidson/pybit

This seems to cover at least some of the same ground as the proposed
project, but I just thought it should be mentioned in case it helped
as example code or reducing the wheel-reinventing. This one supports
cross-building. I hope fedmsg can too, but they may not have thought
about that as they don't currently do any. But perhaps it's
sufficiently generic and low-level that this is not a relevant point. 


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425203435.gb2...@stoneboat.aleph1.co.uk

Re: Bug#602034: jpeg8 vs jpeg-turbo

2013-04-25 Thread Marco d'Itri

On Apr 25, Michael Biebl bi...@debian.org wrote:

 Please no. If libjpeg-turbo is the saner implementation, which reading
 through the messages posted so far it seems like, let's switch to it fully.
Agreed.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: mis-identification of quotations due to lazy bike-shedding

2013-04-25 Thread Thomas Goirand

On 04/25/2013 03:51 PM, Neil Williams wrote:
 On Thu, 25 Apr 2013 07:08:48 +0800
 Thomas Goirand z...@debian.org wrote:

 On 04/25/2013 01:52 AM, Neil McGovern wrote:
 Perhaps you should go read the bug report first. As you seem to be
 unwilling to actually do research, I'll include the relevant section for
 your benefit:
 When you write:
 This will be my only reply to this particular bike-shed.

 Thomas: Read the bug report. I filed it. Neil McGovern quoted it. I
 wrote the comments as part of a wider critique of the package. You are
 replying to Neil McGovern as if he wrote it. 
Sorry for the confusion.
You have my apologies, if you can accept them.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517995ef.3050...@debian.org

Re: [Soc-coordination] GSoC project: fedmsg for the Debian infrastructure

Quoting Peter Palfrader (2013-04-25 22:49:36)
 On Thu, 25 Apr 2013, Simon Chopin wrote:
 
   One of the principles, up to now, of system design for the debian.org
   infrastructure has been that it can tolerate single nodes being off line
   for periods of time.  My understanding of ZeroMQ is that it doesn't do
   very well when the sender and the receiver aren't on line at the same
   time.  I have not used ZeroMQ in any serious way, so I'm only repeating
   what I've heard.  Please correct me if I'm wrong.
  
  Well, as I understand it, when sender or receiver are not online, there
  is simply no message passing. If your concern is about what happens to
  the backlog when the consumer comes back online, then I've already
  written about that earlier today :-)
 
 Does that imply you expect us to run services on core infrastructure
 machines that listen to the world?

I don't know where you have read this implication, but no that is
certainly not what I meant.

PS: Removing the extra MLs from the Cc list. Please keep Ralph in Cc
though.


signature.asc
Description: signature

Re: mis-identification of quotations due to lazy bike-shedding

2013-04-25 Thread Thomas Goirand

On 04/25/2013 03:51 PM, Neil Williams wrote:
 As with the rest of this ridiculous thread, all the discussion is about
 one element of a much larger problem and it was the entirety of the
 previous packaging which convinced me that there were only two sane
 options for the package: Fix all of the problems or remove the package
 entirely.

 I was not seeking removal merely due to this one quoted part of the bug
 report. There were other, more serious, issues than this one but nobody
 seems to have noticed any of that.

I'm quite tired that people tell me I should read the bug report,
and make sure I'm aware of things.

FYI, I have read the full bug report, and downloaded the package
from snapshot.d.o to see what we were talking about.

What I found was indeed a package that had lots of hacks in the
debian/rules, but at the same time, absolutely all hacks where
carefully commented with the dh_* equivalent. In fact, I found it
very interesting to read, quite fun, and probably a good thing to
show to newbies so that they understand what's behind the dh
automagic deliberate obfuscation. :)

 The bug is now fixed, the package wasn't removed, I will not reply to
 any messages relating to it or this bike-shedding thread either on or
 off list. Anyone who perpetuates this sub-thread invites the moniker of
 troll - unless posting entirely in fun.

Sure, let's move on...

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517999c9.7070...@debian.org

Re: [Soc-coordination] GSoC project: fedmsg for the Debian infrastructure

2013-04-25 Thread Peter Palfrader

On Thu, 25 Apr 2013, Simon Chopin wrote:

  One of the principles, up to now, of system design for the debian.org
  infrastructure has been that it can tolerate single nodes being off line
  for periods of time.  My understanding of ZeroMQ is that it doesn't do
  very well when the sender and the receiver aren't on line at the same
  time.  I have not used ZeroMQ in any serious way, so I'm only repeating
  what I've heard.  Please correct me if I'm wrong.
 
 Well, as I understand it, when sender or receiver are not online, there
 is simply no message passing. If your concern is about what happens to
 the backlog when the consumer comes back online, then I've already
 written about that earlier today :-)

Does that imply you expect us to run services on core infrastructure
machines that listen to the world?

Cheers,
weasel
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425204936.gs23...@anguilla.noreply.org

Bug#706179: ITP: r-cran-rsclient -- R client for the headless Rserve R server

2013-04-25 Thread Dirk Eddelbuettel


Package: wnpp
Owner: Dirk Eddelbuettel e...@debian.org
Severity: wishlist

* Package name: r-cran-rsclient
  Version : 0.7-2
  Upstream Author : Simon Urbanek
* URL or Web page : http://www.rforge.net/RSclient/index.html
* License : GPL-2 plus OpenSSL exception
  Description : R client for the headless Rserve R server

This package extend the 'rserve' package we have had in Debian since 2007.
'rserve' already includes several reference clients, but this package
provides a more extensive version.

The package uses OpenSSL, and at my urging, Simon added the following to his
top-level LICENSE file:

[Summary: GPL-2 with OpenSSL linking exception]

RSclient
Copyright (C) 2002-2013 Simon Urbanek

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

In addition, as a special exception, the copyright holders give
permission to link the code of portions of this program with the
OpenSSL project's OpenSSL library (or with modified versions of
it that use the same license as the OpenSSL library - see
http://www.openssl.org/), and distribute linked combinations
including the two.

You must obey the GNU General Public License in all respects
for all of the code used other than OpenSSL.  If you modify
file(s) with this exception, you may extend this exception to your
version of the file(s), but you are not obligated to do so.  If you
do not wish to do so, delete this exception statement from your
version.  If you delete this exception statement from all source
files in the program, then also delete it here.


which is followed by a full copy of the GPL-2.  I believe that this meets our
standards. 

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjwmxpkb@max.nulle.part

Bug#706180: ITP: node-once -- Run a function only once with this module for Node.js

2013-04-25 Thread Jérémy Lal

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal kapo...@melix.org

* Package name: node-once
  Version : 1.1.1
  Upstream Author : Isaac Z. Schlueter i...@izs.me
* URL : https://github.com/isaacs/once
* License : BSD-2-clause
  Programming Lang: JavaScript
  Description : Run a function only once with this module for Node.js

node-once is useful to make sure a listener for multiple events is
only run once.
.
Node.js is an event-based server-side javascript engine.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130425215929.19037.25318.reportbug@imac.chaumes

Re: Bug#602034: jpeg8 vs jpeg-turbo

I think this might be a good move, since the libjpeg-turbo maintainer
still wants to keep compatibility with libjpeg7/8, and he doesn't want
to implement incompatible changes, which might be introduced when
coding Jpeg2000 or JpegXR.

And if there's and consensus in the community that libjpeg-turbo is
way to go, he might be brave and implement the real standards codified
by the Joint Photographic Experts Group, which would be something I
consider good (adhere to standard for interoperability).

See:
http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/40a03431/
http://sourceforge.net/p/libjpeg-turbo/feature-requests/4/

O.

On Thu, Apr 25, 2013 at 10:43 PM, Marco d'Itri m...@linux.it wrote:
 On Apr 25, Michael Biebl bi...@debian.org wrote:

 Please no. If libjpeg-turbo is the saner implementation, which reading
 through the messages posted so far it seems like, let's switch to it fully.
 Agreed.

 --
 ciao,
 Marco



-- 
Ondřej Surý ond...@sury.org


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg8ws6nbbz2ufig+4uy9bpmg5ms7epfjpydqpkaqkad...@mail.gmail.com

Re: Bug#706078: ITP: base91 -- base91 encoder/decoder

2013-04-25 Thread Andreas Bombe

On Wed, Apr 24, 2013 at 03:40:57PM +0200, Franck wrote:
 basE91 is an advanced method for encoding binary data as ASCII characters. It
 is similar to UUencode or base64, but is more efficient. The overhead produced
 by basE91 depends on the input data. It amounts at most to 23% (versus 33% for
 base64) and can range down to 14%, which typically occurs on 0-byte blocks.
 This makes basE91 very useful for transferring larger files over binary
 insecure connections like e-mail or terminal lines.

That word should be safety, not security. Safety here means the message
does not get mangled, security on the other hand would mean things like
encryption.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425214222.gb8...@amos.fritz.box

Work-needing packages report for Apr 26, 2013

2013-04-25 Thread wnpp

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 523 (new: 8)
Total number of packages offered up for adoption: 145 (new: 1)
Total number of packages requested help for: 64 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   jython (#705825), orphaned 5 days ago
 Description: Python seamlessly integrated with Java
 Reverse Depends: libred5-java libsikuli-script-java
 Installations reported by Popcon: 812

   libconstantine-java (#705826), orphaned 5 days ago
 Description: platform constants for Java
 Reverse Depends: jython libjnr-posix-java
 Installations reported by Popcon: 894

   pppconfig (#705769), orphaned 6 days ago
 Description: A text menu based utility for configuring ppp
 Installations reported by Popcon: 3461

   premail (#705938), orphaned 3 days ago
 Description: An e-mail privacy package.
 Installations reported by Popcon: 38

   screenie-qt (#705914), orphaned 3 days ago
 Description: fancy screenshot composer
 Installations reported by Popcon: 105

   spamprobe (#705824), orphaned 5 days ago
 Description: Bayesian spam filter
 Installations reported by Popcon: 607

   svn-all-fast-export (#705916), orphaned 3 days ago
 Description: fast-import based converter to convert repos from svn
   to git
 Installations reported by Popcon: 111

   tpp (#706041), orphaned 2 days ago
 Description: text presentation program
 Installations reported by Popcon: 104

515 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   pycocuma (#705767), offered 6 days ago
 Description: Pythonic Contact and Customer Management
 Installations reported by Popcon: 74

144 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-file (#703366), requested 38 days ago
 Description: search for files within Debian packages (command-line
   interface)
 Reverse Depends: command-not-found
 Installations reported by Popcon: 13568

   apt-xapian-index (#567955), requested 1179 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 65660

   asymptote (#517342), requested 1518 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 4311

   athcool (#278442), requested 3103 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 61

   balsa (#642906), requested 578 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 808

   bastille (#592137), requested 992 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 171

   cardstories (#624100), requested 731 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 8

   chromium-browser (#583826), requested 1061 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n mozplugger
 Installations reported by Popcon: 13689

   cups (#532097), requested 1419 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cups cups-backend-bjnp cups-bsd
   cups-client cups-dbg cups-filters cups-pdf cups-pk-helper (65 more
   omitted)
 Installations reported by Popcon: 109569

   debtags (#567954), requested 1179 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2475

   doc-central (#566364), requested 1188 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 206

   fbcat (#565156), requested 1198 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 149

   flightgear (#487388), requested 1769 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 785

   freeipmi (#628062), requested 700 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse

Bug#706160: marked as done (general: it should be easier for ordinary developers to work with Debian packages)

2013-04-25 Thread Debian Bug Tracking System

Your message dated Fri, 26 Apr 2013 07:10:37 +0200
with message-id 20130426051037.gg5...@mykerinos.kheops.frmug.org
and subject line Re: Bug#706160: general: it should be easier for ordinary 
developers to work with Debian packages
has caused the Debian Bug report #706160,
regarding general: it should be easier for ordinary developers to work with 
Debian packages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
706160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: general
Severity: wishlist

Introduction:
  This is my attempt at explaining exactly what frustrations prevent me from
  doing anything with Debian packages, and how another distro (Gentoo) does
  it better. The fact that Gentoo is a source-based distro is irrelevant.

  I hope you will seriously consider the issues here for jessie, rather than
  replying we understand our system, if others don't that's their problem.

First some definitions:
  Ordinary Developer:
A debian user who is comfortable enough with command-line to install
programs in /usr/local. They want to perform Simple Tasks.
  Simple Tasks:
quick:
  Given a program that is not packaged for Debian and is not
  sufficiently useful to the general public to be worth the maintenance
  burden, install it such that the package manager knows about it.
distribute:
  Given a completed set of package information for such a package,
  distribute it in a way that is easy for others to install.
patch:
  Given a program with a buggy upstream release, apply a patch.
revert:
  Given a program with buggy Debian packaging, revert a patch.
upgrade:
  Given a program that is packaged in Debian, upgrade to an unpackaged
  version.

The problems with the way Debian does it are:
  - debian/ is a subdirectory of the extracted source tree.
  - Because of the above, debian/rules tries to know about backwards steps.
  - There are too many files that need to be modified.
  - There are too many arcane commands that have to be called.
  - It's not obvious how to build except from apt-get source.
  - It's not obvious how to modify the patch set directly.
  - There is no attempt at managing multiple source versions.

How Simple Tasks are approached:
  quick:
Debian:
  - checkinstall is buggy, quirky, and has no upgrade path.
  - I still haven't figured out how to do this easily. Based on the
'hello' package, which is the simplest possible package, this
requires writing a hundred lines of voodoo. A random sampling of
existing package I've looked at agrees with this as a lower bound.
Gentoo:
  - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo
  - That may look like oversimplification, but the contents of
foo-1.ebuild really are very simple.
  distribute:
Debian:
  - Still haven't figured out the right way.
  - I did find the 'dget' command that does some things. How was I
supposed to know about this obscure command for a common use case?
  - You probably have to ship the whole huge .orig.tar.gz file, even
though it's available on the internet under a different name, or
even if it's really a git snapshot.
Gentoo:
  - Put foo-1.ebuild somewhere online (typically in a git repo)
  - foo-1.ebuild contains the URL of the upstream tarball or git repo.
  patch:
Debian:
  - After trying to make local changes, it said: dpkg-source --commit
  - But it is tedious when you already have a full patch from upstream.
Gentoo:
  - Assume that you're competent enough to get ahold of a patch.
  - Add the patch to files/ (which is shared between all versions of
the package, though you can of course use a different name).
  - Add the filename to the PATCHES=() variable, remanifest.
  revert:
Debian:
  - no clue, it keeps trying to readd the changes and it's not obvious
how to wipe the working tree.
Gentoo:
  - Remove the filename from the PATCHES=() variable, remanifest.
  upgrade:
Debian:
  - Hope it's in experimental.
  - Hope its experimental package is not broken.
  - Hope adding an experimental package won't break dependencies in the
rest of your system.
Gentoo:
  - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest
  - Typically, the source URL will automatically change based on the
version number. If this is not the case, it is very obvious to fix.

In

Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

2013-04-25 Thread Bernhard R. Link

* Ben Longbons brlongb...@gmail.com [130425 18:27]:
 The problems with the way Debian does it are:
   - debian/ is a subdirectory of the extracted source tree.

Why do you think that is a problem?

   - Because of the above, debian/rules tries to know about backwards steps.

What are backwards steps?

   - There are too many arcane commands that have to be called.

./debian/rules build
fakeroot ./debian/rules binary

Everything else is mostly convenience wrappers.

   - It's not obvious how to modify the patch set directly.

modify upstream files, call dpkg-source --commit

   - There is no attempt at managing multiple source versions.

First you say things are too complicated, then you complain about
some obscure missing option I never found any use case for.

 How Simple Tasks are approached:
   Given a program that is not packaged for Debian and is not
   sufficiently useful to the general public to be worth the maintenance
   burden, install it such that the package manager knows about it.
 Debian:
   - checkinstall is buggy, quirky, and has no upgrade path.
   - I still haven't figured out how to do this easily. Based on the
 'hello' package, which is the simplest possible package, this
 requires writing a hundred lines of voodoo. A random sampling of
 existing package I've looked at agrees with this as a lower bound.

You can't have easy and high-quality at the same time. Most of the tools
used for official Debian package have the minimal complexity needed for
some quality. Apart from having someone write tools to simply create
private packages there is not much that can be done here.
(and from what you describe for Gentoo, I do not really see how a
dh_make ; vim debian/* ; dpkg-buildpackage is more complicated than the
Gentoo case).


   Given a completed set of package information for such a package,
   distribute it in a way that is easy for others to install.
 Debian:
   - Still haven't figured out the right way.

There are many ways, because needs are different.

   - I did find the 'dget' command that does some things. How was I
 supposed to know about this obscure command for a common use case?

dget is simply a convenience wrapper. Just have three files to download
for a source package. Anyone can click at three links easily.

   - You probably have to ship the whole huge .orig.tar.gz file, even
 though it's available on the internet under a different name, or
 even if it's really a git snapshot.

Sorry, but this is bullshit. If you want to make it easy for users, put
the .orig.tar.gz there. References too external resources will always go
stale and are and endless source of user frustration.

   Given a program with a buggy upstream release, apply a patch.
 Debian:
   - After trying to make local changes, it said: dpkg-source --commit
   - But it is tedious when you already have a full patch from upstream.

patch -i patchfile ; dpkg-source --commit

I thought it was about users knowing the basic command line utilities?

   Given a program with buggy Debian packaging, revert a patch.
 Debian:
   - no clue, it keeps trying to readd the changes and it's not obvious
 how to wipe the working tree.

The very easy way: just revert the change and add another dpkg-source --commit
The direct way: revert the change, remove the line from debian/patches/series
The complicated way: use quilt or some other high-level tool.

Gentoo:
  - Assume that you're competent enough to get ahold of a patch.
  - Add the patch to files/ (which is shared between all versions of
the package, though you can of course use a different name).
  - Add the filename to the PATCHES=() variable, remanifest.

 Gentoo:
   - Remove the filename from the PATCHES=() variable, remanifest.

Yeah, because every patch can simply be removed without any effects on
the other patches, you can just apply any patches you need to the
version you need. And if it doesn't you can just apply manually, fix it
and produce a new clean patch. NOT, seriously.

That you can just do stuff in your working directory, build and fix
again iteratively in your working directory and finally have some
working package is in my eyes one of the biggest strengths of Debian's
package format w.r.t. low entrance and making it easy for unexperienced
people to use Debian to meed their needs.

 Gentoo:
   - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest
   - Typically, the source URL will automatically change based on the
 version number. If this is not the case, it is very obvious to fix.

your gentoo solution is the equivalent of copying the debian/ directory
around.

 In conclusion:
   The current Debian way is complicated. The Gentoo way is simple. This is
   not tied to the fact that Gentoo is a source-based distribution, although
   that does encourage the right mindset.

In

Accepted visp 2.7.0-1 (source amd64 all)

2013-04-25 Thread Thomas Moulard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Apr 2013 15:03:05 +0900
Source: visp
Binary: libvisp-dev libvisp2 libvisp2-dbg libvisp-doc
Architecture: source amd64 all
Version: 2.7.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Science Maintainers 
debian-science-maintain...@lists.alioth.debian.org
Changed-By: Thomas Moulard thomas.moul...@gmail.com
Description: 
 libvisp-dev - visual servoing library - development files
 libvisp-doc - visual servoing library - documentation
 libvisp2   - visual servoing library
 libvisp2-dbg - visual servoing library - debugging symbols
Closes: 704783
Changes: 
 visp (2.7.0-1) unstable; urgency=low
 .
   * New upstream release.
   * Use pkg-kde-tools to handle library symbols.
   * Depend on OGRE v1.8 instead of 1.7 (Closes: #704783).
   * Backport pkg-config support from upstream to add multiarch support
 for development package (libvisp-dev).
   * Backport from upstream various minors bug fix detected by cppcheck.
   * Depend on libois-dev on Linux only.
   * Remove all patches from 2.6.2-1 as the new upstream release fixes these
 issues.
Checksums-Sha1: 
 46c3304f36d1f81bbd5aa210324587377f68f087 2398 visp_2.7.0-1.dsc
 e4e53e0fa3b8c2aa33e9bb7ba39c6ec41a2efafd 1493940 visp_2.7.0.orig.tar.gz
 143147d2a36cf3ac200096ae40cb40a9889d0fab 43136 visp_2.7.0-1.debian.tar.gz
 4b04c7f8f36fa2e65e353cc8a1a25e0d0f67e37b 360520 libvisp-dev_2.7.0-1_amd64.deb
 7dd8adf9e14da544765dbf656f9fe85ab4acfe99 1077876 libvisp2_2.7.0-1_amd64.deb
 d5b22d340e251854585d4d4f6b9f5ec8b92207cc 7619828 libvisp2-dbg_2.7.0-1_amd64.deb
 b66f8ea6bff66b2a5dc5a8ae6169302da7b6f890 44615758 libvisp-doc_2.7.0-1_all.deb
Checksums-Sha256: 
 8745094705a2b35ec7eaf9c3296ffcd3726e0c334d6526e3afd997202c8586bb 2398 
visp_2.7.0-1.dsc
 b61b1a0b5a473e7cdc4aed09d948bbae9f42a9c2ebfcf5f2d96bf3214f8c0013 1493940 
visp_2.7.0.orig.tar.gz
 661deabd280f0e53fe0ceca32eb761e8ef247850a7ba4abbd5821be39d3fa4e9 43136 
visp_2.7.0-1.debian.tar.gz
 a58b30ae10d5ef9560afb203075ac5e76ce4f7e03aec81ebed4856b7e6f51be9 360520 
libvisp-dev_2.7.0-1_amd64.deb
 8d7cf6e7be3424aa5b8adbbe63e188e64a1d9455c3baf0e17bc696b7bed557bb 1077876 
libvisp2_2.7.0-1_amd64.deb
 a3c3a26606f33c99de25707236a2c0592090bdef7b4dac86eb3902bba1ca9f17 7619828 
libvisp2-dbg_2.7.0-1_amd64.deb
 2371fab568bfad0cf0bb6cb195d7404fdf1b7a00c9c2f038a8aeeec91f48b880 44615758 
libvisp-doc_2.7.0-1_all.deb
Files: 
 548409dcfda691408c661704724fb6e3 2398 libs extra visp_2.7.0-1.dsc
 f5cc121d90708d0dc14c77ebc14be7c7 1493940 libs extra visp_2.7.0.orig.tar.gz
 fbb0f53901bba6a69835d5e2a88c78d2 43136 libs extra visp_2.7.0-1.debian.tar.gz
 af267001d63e1665a49e084d661d1f9e 360520 libdevel extra 
libvisp-dev_2.7.0-1_amd64.deb
 0c61702d5f4f2201e3d3f32ef2122164 1077876 libs extra libvisp2_2.7.0-1_amd64.deb
 32a79a856109649becbedc57050497a9 7619828 debug extra 
libvisp2-dbg_2.7.0-1_amd64.deb
 e7ee35746f531b18cd67055c6cf74716 44615758 doc extra libvisp-doc_2.7.0-1_all.deb

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

iQIcBAEBCAAGBQJReNrfAAoJEDIkf7tArR+mEmAP/1MpthL+cEDgdagTbmwgmjFb
lGUwR6oyKtBwO1cUJfMi4G/wnaA5IRUTvbu/H2H0aBMzJ3cG0vLICjUDJ3WLBxpo
sc7oT/iePPJrysUuYqfXj54LV+CL9oVC0DDEBE45oZDibNcDhJPToJWWM5FRYsLp
JuWrTZKkIgmVsn2xLmEioBUYJabi+fXpIkvdG8y4KDKjmsbUgFsqObuF0CMYrSkV
k8Cqa7NFkijxP41ZkZU9+Avrjg6pd2Qq14sXluctPPO/NzOPIMREURcEm+Za6Ur1
8EAGN2aGLQIg8KqwUa45hd8TtZIB3FIj3dUHBHK8WZ9hawiBwb2we8AvvKoQ2op1
jM3iAEGMXUI7C15KmEm2Hxt5rVoeXVuhWA5UfoI6TPheek8DyRDhE4/0/JUzvc1f
AXQ11ypt2WP82FoH0phK6VSJ2hM6t3H+DJJG2U2fhCqi36hAG12PPQGzXAjyvhPd
yJey7DCYA1nRDWw2puTbp6toNVMeCX0BozcrU4LE8Nw4SqN1noVpU8zLtDqacUyT
jgUkr7B0/giLBqPORaA9Zz7EpMM37542B/kDpk9US1MDXS0ZJVt1HrrycQSk7kuK
I9tyteA0+ya32aN1gVZj8/Wt7FA+KKi/dFc+lZEB67bZ5t+K0ICo4kGsAmPCn93I
ieE6a78lYm3/q/G09t1T
=ERZ8
-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: http://lists.debian.org/e1uvgue-00070k...@franck.debian.org

Accepted tcpflow 1.3.0+dfsg-1 (source amd64)

2013-04-25 Thread Dima Kogan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 02 Feb 2013 02:16:53 -0800
Source: tcpflow
Binary: tcpflow tcpflow-dbg
Architecture: source amd64
Version: 1.3.0+dfsg-1
Distribution: experimental
Urgency: low
Maintainer: Dima Kogan d...@secretsauce.net
Changed-By: Dima Kogan d...@secretsauce.net
Description: 
 tcpflow- TCP flow recorder
 tcpflow-dbg - TCP flow recorder - debug symbols
Closes: 536792 611047 636212 636922 673637
Changes: 
 tcpflow (1.3.0+dfsg-1) experimental; urgency=low
 .
   * New Maintainer (Closes: #673637)
   * Package now follows new upstream:
 http://www.afflib.org/software/tcpflow/ . This fixes several bugs:
 (Closes: #636922, #536792, #611047, #636212)
   * Updated debianization
 - moved to debhelper v9, so debian/rules is now much simpler
 - added watch files
 - expanded debian/copyright
 - now building a tcpflow-dbg package
Checksums-Sha1: 
 23f888af4ce739cdb20686e22e5aade0baf4e736 1955 tcpflow_1.3.0+dfsg-1.dsc
 5e9738da87660cc41b93efe542e0e5948459da5b 128514 tcpflow_1.3.0+dfsg.orig.tar.gz
 6d21b5fa979dbef006427d84e5b53733a999bd23 6293 
tcpflow_1.3.0+dfsg-1.debian.tar.gz
 f93f7849e6e4abebd733b3c14942e408ca685f7b 70100 tcpflow_1.3.0+dfsg-1_amd64.deb
 c148f3efd19778653150580963713f1876ab3211 362688 
tcpflow-dbg_1.3.0+dfsg-1_amd64.deb
Checksums-Sha256: 
 8b36a98916101bfee282bd2fbb6a894f7f1fc454152ca32760a69e242ef2b709 1955 
tcpflow_1.3.0+dfsg-1.dsc
 f90749e358755c30f84cc5202cbca1a83019f39ec8141d8d877aa71e479e412f 128514 
tcpflow_1.3.0+dfsg.orig.tar.gz
 bab0649f6e250f163b817cdb18e0c5c2b881598e5f05a3612158557ab22c5e73 6293 
tcpflow_1.3.0+dfsg-1.debian.tar.gz
 ac4e5bbecfe1e01430df44937c50beed93522633d88d19a42599757837c437e7 70100 
tcpflow_1.3.0+dfsg-1_amd64.deb
 384526676fb73fa4b45e6330e1ece578e702e1627269cfe8e26cc95ebc24340a 362688 
tcpflow-dbg_1.3.0+dfsg-1_amd64.deb
Files: 
 a3892d07de1da9fb92014b8167595cbd 1955 net optional tcpflow_1.3.0+dfsg-1.dsc
 1c34e2693c90d1faf781bd1aa6791266 128514 net optional 
tcpflow_1.3.0+dfsg.orig.tar.gz
 20504a5adf4884519e8e5b78e1eab3e2 6293 net optional 
tcpflow_1.3.0+dfsg-1.debian.tar.gz
 85f2d2b23d309938daaea85d6aa4ac1b 70100 net optional 
tcpflow_1.3.0+dfsg-1_amd64.deb
 8b09e9fd14909510b86be54fe1733317 362688 debug extra 
tcpflow-dbg_1.3.0+dfsg-1_amd64.deb

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

iQIcBAEBAgAGBQJRddswAAoJEHtYWzCAfCqH/1IP/AgWmefWdBCpSQcBgxd/KxsZ
6UNAroeWsoqRBFJqjO7PR5h8wF3CN+JbvG+n2HXOM4adO1FV07DsPA+LzQQJr+hA
8X4h3FGR6mk1DlxMYguH3byWNiQcG+AheNUOVmmIw/LbswiVkHB57elIHSL8WGgp
2AzZu+65o4dm/53lvCaZSDig9NBbt2UyR9Z970fzMY7EzvcSSqIm/FFA68RlgePt
267el9+dz1OJgGsfvBu2/j3ccAfCawXIcj8pM9M+mpa2Li/dTxdTiqf3BlwrKI/C
okd6wuq+vVLQD46YpEoHCRJeRu2vH2pdcpXfNkghSO8veLSRFzSwrPtFocd42hu+
dMHH9U1b9rrFzRZqatHJhPo3YhBuCpfoHeRAtPuVBWmq69Ar/672YpYH9OKRAyYC
dyXRAi3YeEtQiNFeK86sh0oXZiRAWfSNnjTTqX9MELrhB3HjW5Eczqa6/0k1I8qU
Jjew1KIuV6fJ12ELB3loCsMMbUVk8RZ97wUd3Z1opnwmdlsMB3vmhajhkxHhjLkQ
QqfMJ0ES2r0sQTETj1grsSEfi67gI27pWOh4qwOCFknfnXeQDVAMRws3qnvrAVHk
6MZUrsCUQ6bzBgAotxXP8+zFXfaGHU+QGcKbP+yry4Ro3csM8k4QHVvVgF1kf4yr
aEOmiTQlCfCNdGplY5cp
=g00C
-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: http://lists.debian.org/e1uvi29-0007sc...@franck.debian.org

Accepted brailleutils 1.2.1-1 (source all)

2013-04-25 Thread Sebastian Humenda

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 11 Apr 2013 18:45:11 +0200
Source: brailleutils
Binary: libbrailleutils-java libbrailleutils-java-doc brailleutils
Architecture: source all
Version: 1.2.1-1
Distribution: unstable
Urgency: low
Maintainer: Sebastian Humenda shume...@gmx.de
Changed-By: Sebastian Humenda shume...@gmx.de
Description: 
 brailleutils - command-line interface for the brailleutils library
 libbrailleutils-java - cross platform library for embossing/converting 
PEF-files
 libbrailleutils-java-doc - javadoc for brailleUtils for converting/embossing 
PEF files
Changes: 
 brailleutils (1.2.1-1) unstable; urgency=low
 .
   [ Sebastian Humenda ]
   * updated to upstream v1.2.1
   * separate front end for brailleutils (available as command with the same
 name)
   * wrote man page for brailleUtils
   * improved debian packaging: moved installation from debian/rules to
 *.install, *.dirs
 .
   [ Samuel Thibault ]
   * control: Add missing junit4 dependency.
Checksums-Sha1: 
 a8abb827513fee61ca256333b8b9381613c0b280 2015 brailleutils_1.2.1-1.dsc
 b79cc5ab041da3587f1ce27caf50f69ba34a4933 981534 brailleutils_1.2.1.orig.tar.gz
 8947d4398332dfd60ea27575f7d743f0eef83c1e 5162 
brailleutils_1.2.1-1.debian.tar.gz
 4e8baa99821e4d803e36029cb24ee5944b6fa22a 528330 
libbrailleutils-java_1.2.1-1_all.deb
 7c2215fa4b28f4f66a09948570065b9ec0106164 8232 
libbrailleutils-java-doc_1.2.1-1_all.deb
 de30af790953d5e292554de0e16e1f3a60976f58 58540 brailleutils_1.2.1-1_all.deb
Checksums-Sha256: 
 23571c3ee75525a384b0bf3d34526e02859082293705b19a0b28cea5cbfcc19a 2015 
brailleutils_1.2.1-1.dsc
 29a668fc987e67eb3b8955e676ec58887124d3f273f9ecc1227047f08e23b1bd 981534 
brailleutils_1.2.1.orig.tar.gz
 33074eacdd5a785ac08866d788890c7a70e3800a7f4c62a946e9b5c3de398e11 5162 
brailleutils_1.2.1-1.debian.tar.gz
 67acf385f72bc40931ad328c9ad4fa13f8730405889044c91b29fb8f851164d2 528330 
libbrailleutils-java_1.2.1-1_all.deb
 6fcc3c17399b1e040dfafa8767d9eca7823fdd752bf2e770443113ac4cb3c555 8232 
libbrailleutils-java-doc_1.2.1-1_all.deb
 59038c68c44ab76460784ad5e936cf8cc57961fbf0430ceb7f47eff41e9eaaa2 58540 
brailleutils_1.2.1-1_all.deb
Files: 
 b79d903176a442344dec0cc5637170c0 2015 java extra brailleutils_1.2.1-1.dsc
 360d2253c2e84092c853cb370b319fc6 981534 java extra 
brailleutils_1.2.1.orig.tar.gz
 56227d25d5cf417f2ba6599d7ee17bdf 5162 java extra 
brailleutils_1.2.1-1.debian.tar.gz
 eff1d07a41cac4f80e936d59271c2172 528330 java extra 
libbrailleutils-java_1.2.1-1_all.deb
 0949501dc77e2902d32747dfb35a5137 8232 doc extra 
libbrailleutils-java-doc_1.2.1-1_all.deb
 221f041f6f98721fd528555834fc478f 58540 doc extra brailleutils_1.2.1-1_all.deb

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

iQIcBAEBCgAGBQJRdykBAAoJECqpogBB8bdXJTkP/jKwUXVzu1qVYrS2dVyt5JPF
jsX2zVBjd8cELBoMCeX0bm3dtIoBZ8qS7lKI3kGw4Gt6PmxiQdXwzYExX/K70x6U
qNFLG4BFkUXMQqdzpkVgjpfYu8hTAiDr1dmK/fT3hYEUYIVd7qO9FRjhKPK2cxP6
ISEdaIqtNGaY+qIA65fmBSiK5tzxCCvVcEzkIOdHs9fHQ7zjwAwwpNIcMrlYUqg7
BoSMf1TCvSLcTklooAPagHuYxOhuetNxiHDPvdRlrENZcFcxjKva5JHYm1DmLrQ4
XVOpDQSiKqV0twgRL7X7fhGHWupn8IZgQFNAzYrGu9itB6NGkV1PfqJ+uL3fLcRF
eT1X36u7LmDKw7uEzy6++YTjhRAfJLuUs1UW+zbQzyu3fg8/+DEremEWvVw5qCTr
LKmehxse2c+V27NnwEOpvHQpQEKqXoYr1WoEdRUg9HCZ5tEgIA2p2NfMDwsEnVsW
a1xXn/iMKCZpvgbHkWFWmwjk2d6hAHcwQK60XK/iqFbnhpNu8z4kMDTI9L9LnVrp
WDA5Gs/5178DGz3HmCzZT4rl1uKMmOkauH+ExeSVyZPCN+z38D0vKC/eKoShlEk/
M+NljMkD+zhwI18VcKj45eCKPssJmmtEL2hF7FPzvxfR1I4wRWEoyLbAzkCMsCCm
OJxWSM5Uxt1yoR/flCRH
=37sL
-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: http://lists.debian.org/e1uvi2a-0007u0...@franck.debian.org

Accepted mono-basic 3.0~pre20130425.a74642a-1 (source all)

2013-04-25 Thread Jo Shields

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Apr 2013 00:22:29 +0100
Source: mono-basic
Binary: libmono-microsoft-visualbasic8.0-cil 
libmono-microsoft-visualbasic10.0-cil libmono-microsoft-visualbasic11.0-cil 
libmono-cecil-vb0.9-cil mono-vbnc mono-basic-dbg
Architecture: source all
Version: 3.0~pre20130425.a74642a-1
Distribution: experimental
Urgency: low
Maintainer: Debian Mono Group pkg-mono-gr...@lists.alioth.debian.org
Changed-By: Jo Shields direct...@apebox.org
Description: 
 libmono-cecil-vb0.9-cil - Visual Basic 2012 Cecil libraries for Mono
 libmono-microsoft-visualbasic10.0-cil - Visual Basic 2010 runtime libraries 
for Mono
 libmono-microsoft-visualbasic11.0-cil - Visual Basic 2012 runtime libraries 
for Mono
 libmono-microsoft-visualbasic8.0-cil - Visual Basic 2005 runtime libraries for 
Mono
 mono-basic-dbg - Mono Visual Basic, debugging symbols
 mono-vbnc  - Mono Visual Basic Compiler (VB.NET)
Changes: 
 mono-basic (3.0~pre20130425.a74642a-1) experimental; urgency=low
 .
   * [a3bcf78] Imported Upstream version 3.0~git20130424.f5a46b1
   * [c57b8a8] Imported Upstream version 3.0~pre20130424b.f338540
   * [3b7d846] Imported Upstream version 3.0~pre20130425.a74642a
   * [6d60a32] Bump ABI to 2.99, for versioning. We can't use 3.0 here, as
 this is as pre-3.0 git snapshot, and this would encode a requirement
 on 3.0 final
   * [3faddfd] Bump build dependency to Mono 3.0, since we need .NET 4.5
 support
   * [8f6d231] Add VB2012 (.NET 4.5, VB11) packaging data
   * [305bbcb] Refresh debian/copyright with DEP5
Checksums-Sha1: 
 56cb17d7f82779e520ef90d9e481d2492b37940c 2210 
mono-basic_3.0~pre20130425.a74642a-1.dsc
 daa71872c6c44fa28e4f28372377db3a748abd32 1998659 
mono-basic_3.0~pre20130425.a74642a.orig.tar.bz2
 3bf874d46a9877c007a32432d85d8d88aecc10a6 6804 
mono-basic_3.0~pre20130425.a74642a-1.debian.tar.gz
 a31e20baec30aa21fcc5b68dfb7da080541b4a57 123454 
libmono-microsoft-visualbasic8.0-cil_3.0~pre20130425.a74642a-1_all.deb
 521302e8344c91f9f73d1b68452b10d877dd3273 122398 
libmono-microsoft-visualbasic10.0-cil_3.0~pre20130425.a74642a-1_all.deb
 0f7157069d54559c22e95ede92149bc638338396 122396 
libmono-microsoft-visualbasic11.0-cil_3.0~pre20130425.a74642a-1_all.deb
 7a5bd81e9f6940be688401256a8ae958c06ea4d6 186494 
libmono-cecil-vb0.9-cil_3.0~pre20130425.a74642a-1_all.deb
 4539a21aad758eeccf386229ab97c614fb03b235 341040 
mono-vbnc_3.0~pre20130425.a74642a-1_all.deb
 36e7317edbf65a8e367b43970417ea5d21cf61e2 353952 
mono-basic-dbg_3.0~pre20130425.a74642a-1_all.deb
Checksums-Sha256: 
 700c8a1e17a6f8a0e3d4d5802a01eddcdd76237041770d7e5ee78ed7f0067a0a 2210 
mono-basic_3.0~pre20130425.a74642a-1.dsc
 09a2630e10e71b44f009b44587389eee7208631f14d80cc1c75cae4e6d7c5c12 1998659 
mono-basic_3.0~pre20130425.a74642a.orig.tar.bz2
 d8a8267c80b9e5a138613a54704ab3dd67cfdb73f27bb580b590680511928286 6804 
mono-basic_3.0~pre20130425.a74642a-1.debian.tar.gz
 6efad5b5ac1c8d66d72168df6fcbbdadbd0ccff392c8a700cdeb4cd6f19f8ecd 123454 
libmono-microsoft-visualbasic8.0-cil_3.0~pre20130425.a74642a-1_all.deb
 30f709245d21eb08f7cd6853aabafed364a493bb8dadb5e13841e2e94cf4 122398 
libmono-microsoft-visualbasic10.0-cil_3.0~pre20130425.a74642a-1_all.deb
 4fc6abb3c05cc242261d93a9d52c7b90a1c34d4cb3d37038deb55a8058d732b9 122396 
libmono-microsoft-visualbasic11.0-cil_3.0~pre20130425.a74642a-1_all.deb
 3e8d65c3f0b9d05cd1577a1eb9a6117683bcfe25e74ec58635a1beb91a43fa86 186494 
libmono-cecil-vb0.9-cil_3.0~pre20130425.a74642a-1_all.deb
 00427cbb708ab13f15c865aabf720f957545136255fb56a0ba366ee913f096ff 341040 
mono-vbnc_3.0~pre20130425.a74642a-1_all.deb
 77881f9a40ad80f9e425b381b524cd4c8a4bd3d021b5caedbfdc2acb7e44f884 353952 
mono-basic-dbg_3.0~pre20130425.a74642a-1_all.deb
Files: 
 594595a87fdd73d72a8b03c9f1a4aa4e 2210 devel optional 
mono-basic_3.0~pre20130425.a74642a-1.dsc
 ffa2a0c9b153125328ede9cff6c55627 1998659 devel optional 
mono-basic_3.0~pre20130425.a74642a.orig.tar.bz2
 d869b04ade1272d93ef827f65603cc70 6804 devel optional 
mono-basic_3.0~pre20130425.a74642a-1.debian.tar.gz
 0d6e0d89d7cecca58ccc8adab761ee6f 123454 libs optional 
libmono-microsoft-visualbasic8.0-cil_3.0~pre20130425.a74642a-1_all.deb
 adc58d6fddc098af89022e4ed5a23be4 122398 libs optional 
libmono-microsoft-visualbasic10.0-cil_3.0~pre20130425.a74642a-1_all.deb
 db1d292134f4ca0cbdeaead8cb415c6f 122396 libs optional 
libmono-microsoft-visualbasic11.0-cil_3.0~pre20130425.a74642a-1_all.deb
 7642a161e133947f8d0b9ac512cccf4a 186494 libs optional 
libmono-cecil-vb0.9-cil_3.0~pre20130425.a74642a-1_all.deb
 830d992b3d498b5f987a5cfac4ce2253 341040 devel optional 
mono-vbnc_3.0~pre20130425.a74642a-1_all.deb
 0e311355329f83450cb7a5dcee8da8eb 353952 devel extra 
mono-basic-dbg_3.0~pre20130425.a74642a-1_all.deb

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

iQEcBAEBCAAGBQJReHHzAAoJEMkPnLkOH60MXnoH/Ro1k2V674kyD7iRW5lav5S+
aMn9X5Qb8CgHzcfwpFcYqvM4iJii+UJAoF1X/hdZ+EjmhYY3u3rL+6Ab4gKpqZTJ

Accepted nginx 1.4.0-1 (source all amd64)

2013-04-25 Thread Kartik Mistry

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 12:51:45 +0530
Source: nginx
Binary: nginx nginx-doc nginx-common nginx-full nginx-full-dbg nginx-light 
nginx-light-dbg nginx-extras nginx-extras-dbg nginx-naxsi nginx-naxsi-dbg 
nginx-naxsi-ui
Architecture: source all amd64
Version: 1.4.0-1
Distribution: experimental
Urgency: low
Maintainer: Kartik Mistry kar...@debian.org
Changed-By: Kartik Mistry kar...@debian.org
Description: 
 nginx  - small, powerful, scalable web/proxy server
 nginx-common - small, powerful, scalable web/proxy server - common files
 nginx-doc  - small, powerful, scalable web/proxy server - documentation
 nginx-extras - nginx web/proxy server (extended version)
 nginx-extras-dbg - nginx web/proxy server (extended version) - debugging 
symbols
 nginx-full - nginx web/proxy server (standard version)
 nginx-full-dbg - nginx web/proxy server (standard version) - debugging symbols
 nginx-light - nginx web/proxy server (basic version)
 nginx-light-dbg - nginx web/proxy server (basic version) - debugging symbols
 nginx-naxsi - nginx web/proxy server (version with naxsi)
 nginx-naxsi-dbg - nginx web/proxy server (version with naxsi) - debugging 
symbols
 nginx-naxsi-ui - nginx web/proxy server - naxsi configuration front-end
Closes: 696440 700857 702923 706127
Changes: 
 nginx (1.4.0-1) experimental; urgency=low
 .
   [ Kartik Mistry ]
   * New upstream release (Closes: #706127).
   * debian/rules, debian/modules/:
 + Removed chunkin-nginx-module as it no longer supported for nginx 1.3.9+
 + Updated nginx-lua module to 0.8.0
 + Patched nginx-upload module as described in modules/README file.
   * Refreshed debian/patches/perl-use-dpkg-buildflags.patch
   * debian/logrotate:
 + Set default log to keep for 52 weeks instead of 52 days. Thanks to
   RjY r...@users.sourceforge.net for patch (Closes: #696440)
   * debian/rules:
 + Added cache purge module to nginx-extras.
   * debian/control:
 + Suggests: nginx-docs. Thanks to colliar colliar4e...@aol.com for
   reporting bug (Closes: #702923)
   * debian/copyright:
 + Updated copyright year.
 + Fixed broken license text.
 .
   [ Michael Lustfield ]
   * debian/conf/sites-available/default:
 + Added ipv6_only=on to default server block. (Closes: #700857)
 + Added default_server to ipv4 default server block. Now matches ipv6.
   * debian/rules:
 + Removed obsolete --with-md5 and --with-sha1
Checksums-Sha1: 
 677f9ef66fc7ff513ab5a7d39809318291671b12 2092 nginx_1.4.0-1.dsc
 a4343ed201b99d93ff06843600f3175270cb0a94 773451 nginx_1.4.0.orig.tar.gz
 7f3270de55ffc969c7afd4eb8f86122877a9787d 1476787 nginx_1.4.0-1.debian.tar.gz
 b42d211ff3ec4bfdada275fe23424faa01a8b770 64910 nginx_1.4.0-1_all.deb
 698c59cd5cfcb3975e5d5f7b72ad6d5e3ce090d9 78498 nginx-doc_1.4.0-1_all.deb
 bb21e5e41bebe3fb61c082b684e88ae06074e6d4 76674 nginx-common_1.4.0-1_all.deb
 c9e0211d1b466b3bae278b7498fb813fd1cca039 356494 nginx-naxsi-ui_1.4.0-1_all.deb
 0a644423e253dd5ac4265d2c4cea4d9ff0ce00e1 457034 nginx-full_1.4.0-1_amd64.deb
 2aa7d69358b4d668510571f4ac485b2a2cf81e4c 3209140 
nginx-full-dbg_1.4.0-1_amd64.deb
 5f69f40bd3b6bf7b04603329acb64680d5658324 337982 nginx-light_1.4.0-1_amd64.deb
 5fea22fdc3a360b5bdccfadd79d78d510584ce29 2236446 
nginx-light-dbg_1.4.0-1_amd64.deb
 b6bc43661e045c75c0203cb2f0ac329b021f5dc7 650310 nginx-extras_1.4.0-1_amd64.deb
 bb63aeccfd5a2e56ccd9c0f3d90945f6a01f9bbf 4938484 
nginx-extras-dbg_1.4.0-1_amd64.deb
 5c36c25062d3eba943fd03a78c852e67c905108e 379658 nginx-naxsi_1.4.0-1_amd64.deb
 0854d36ac1cb0032457ed142f586e779ae88a3bc 2395216 
nginx-naxsi-dbg_1.4.0-1_amd64.deb
Checksums-Sha256: 
 9feea6c571861e0f0c6e67dc4fd1f7003f914ee2b4bd728276cc94f2c84f21f6 2092 
nginx_1.4.0-1.dsc
 84aeb7a131fccff036dc80283dd98c989d2844eb84359cfe7c4863475de923a9 773451 
nginx_1.4.0.orig.tar.gz
 eb5f3436bab516e90825c998a32c67b9f2fda78b0d12244e4c08072ede0f30d2 1476787 
nginx_1.4.0-1.debian.tar.gz
 ddfcb17ce6392b262eb0a9c47903222317f395e71995d8059a9854dfce6e069d 64910 
nginx_1.4.0-1_all.deb
 9342bd36df2d83856a901cf42dd0ccf2cc18bbd4d8d3a5c71a458d6e1d1e090b 78498 
nginx-doc_1.4.0-1_all.deb
 a1327b979e0e73503b003146525da6a0c6ff95e4036daf9507914d1a594bc93b 76674 
nginx-common_1.4.0-1_all.deb
 d6200666412b8ec2cf0d08cbc1bd9fcf502636eaaccea932986f4796d379106c 356494 
nginx-naxsi-ui_1.4.0-1_all.deb
 7af7f380110f2a446929ea2d48ed62aaf8f9e1c348ef2c649c83241bc48d3395 457034 
nginx-full_1.4.0-1_amd64.deb
 06b4d1e0ea81872250668cfed6f329f246ea8d3ec79ccb38d28449f7a41f67c9 3209140 
nginx-full-dbg_1.4.0-1_amd64.deb
 13ae55bdb16f07b72bb298508b1e6a301e02382d7c22afe598998630a18b5abd 337982 
nginx-light_1.4.0-1_amd64.deb
 1d4db9d86a365f0885f1d23ded564ecaa2be1c4f3397eeac24162e19194d4d03 2236446 
nginx-light-dbg_1.4.0-1_amd64.deb
 74f41e5cce5981f4d1e060d0bee50b053c4fd2c0cfc9c5cbb0208219c3c3a4c4 650310 
nginx-extras_1.4.0-1_amd64.deb
 da5c3811439b189b28678b60844c43d59de122c5ef78723ce28ec08024a2d168 4938484

Accepted opendnssec 1:1.4.0-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 09:46:06 +0200
Source: opendnssec
Binary: opendnssec-common opendnssec opendnssec-doc opendnssec-enforcer 
opendnssec-enforcer-mysql opendnssec-enforcer-sqlite3 opendnssec-signer 
libhsm-bin opendnssec-dbg-mysql opendnssec-dbg-sqlite3
Architecture: source all amd64
Version: 1:1.4.0-1
Distribution: experimental
Urgency: low
Maintainer: Ondřej Surý ond...@debian.org
Changed-By: Ondřej Surý ond...@debian.org
Description: 
 libhsm-bin - library for interfacing PKCS#11 Hardware Security Modules
 opendnssec - dependency package to install full OpenDNSSEC suite
 opendnssec-common - common configuration files for OpenDNSSEC suite
 opendnssec-dbg-mysql - Debug symbols for OpenDNSSEC (Enforcer with MySQL 
support)
 opendnssec-dbg-sqlite3 - Debug symbols for OpenDNSSEC (Enforcer with SQLite3 
support)
 opendnssec-doc - documentation for OpenDNSSEC suite
 opendnssec-enforcer - tool to prepare DNSSEC keys (common package)
 opendnssec-enforcer-mysql - tool to prepare DNSSEC keys (mysql backend)
 opendnssec-enforcer-sqlite3 - tool to prepare DNSSEC keys (sqlite3 backend)
 opendnssec-signer - daemon to sign DNS zone files periodically
Changes: 
 opendnssec (1:1.4.0-1) experimental; urgency=low
 .
   * Imported Upstream version 1.4.0
   * debian/rules, debian/control:
+ Use dh-autoreconf instead of manual autoreconf invocation
   * debian/patches/:
+ Refresh patches for 1.4.0 release
   * Fix couple of lintian warnings
Checksums-Sha1: 
 ade39488e2694edbf286aca02dc95c4d0d55afce 2023 opendnssec_1.4.0-1.dsc
 111a6de4bb8f13bcedc31880c87588ce07eecc31 985512 opendnssec_1.4.0.orig.tar.gz
 9ba2c643e7927c09b2ab526417b5fc1ba7388d6e 18547 opendnssec_1.4.0-1.debian.tar.gz
 e38fdac41af40aff39bea5f62c524728732172e5 50042 
opendnssec-common_1.4.0-1_all.deb
 a7385a0f1fe66d0cef4a17418c97dff0d22f1156 23988 opendnssec_1.4.0-1_all.deb
 a452d59bae6d6a06fc8ad91f2842555b70caf1b1 60468582 
opendnssec-doc_1.4.0-1_all.deb
 54c28880ea97854b4c13eddbaa7ca7c3dca613b1 36124 
opendnssec-enforcer_1.4.0-1_all.deb
 5b442ce46a5fd9be95ee8d0cf261da97cbd4a3f7 185968 
opendnssec-enforcer-mysql_1.4.0-1_amd64.deb
 276729804e9ce26a454ad14e67ed5e376ddad3e6 172496 
opendnssec-enforcer-sqlite3_1.4.0-1_amd64.deb
 107d0a8fde05ac2e6f81a60ea01202c62428191b 194646 
opendnssec-signer_1.4.0-1_amd64.deb
 74a3f98b0b2940d107c061b63154b768e0be2fb4 74674 libhsm-bin_1.4.0-1_amd64.deb
 fc4110ff23f39382aa2f0e939630b3fdde16241a 1193974 
opendnssec-dbg-mysql_1.4.0-1_amd64.deb
 893ced5b250a1103f8b4b2a315aaf139a715f3b6 1131286 
opendnssec-dbg-sqlite3_1.4.0-1_amd64.deb
Checksums-Sha256: 
 b5d68c1074030dd2a776caffc3068a637d2b515f08b230f2594b4e9d1362b4f5 2023 
opendnssec_1.4.0-1.dsc
 36d4926dcdf351a527ad7600b151ab6cc56d0a472a7eb8871eecd70afef9e101 985512 
opendnssec_1.4.0.orig.tar.gz
 97cc186d415f2aa8d1272563658c4b6c7bf790933d8f2faa032c552c5f74142b 18547 
opendnssec_1.4.0-1.debian.tar.gz
 9f7fc2c2b95102478e9e948dabd642e08ee8fb3e590011711f399a185b7cd2a1 50042 
opendnssec-common_1.4.0-1_all.deb
 57994d0a106c529c57ea2c9164f724e64cd1b7ab249d78aa2e71188c6707a51c 23988 
opendnssec_1.4.0-1_all.deb
 0d20a9d8ccef3544bb5eafec206123b912a5e4310b0ea6e3ceb06604527cac10 60468582 
opendnssec-doc_1.4.0-1_all.deb
 b3f5c82b9382fe9dc9cc30e14aceedb9f0d0569760eb34c3e9c16d4454f6f4c4 36124 
opendnssec-enforcer_1.4.0-1_all.deb
 17e3d26d783396c672227b6473f1dd239b97a4e6640e103f747e01401e23a6a0 185968 
opendnssec-enforcer-mysql_1.4.0-1_amd64.deb
 35187ce032d12686139c514ec7c30762f2d4fea87f93124ac1f9ae546b1c19b0 172496 
opendnssec-enforcer-sqlite3_1.4.0-1_amd64.deb
 48ec4f6f2206a23eb14d0186d86cadea9abba644fd61439dbb1e82a935828a46 194646 
opendnssec-signer_1.4.0-1_amd64.deb
 64a6199e91e05efe59949e3c213d6e7788670c8b63efb319842e1d83408a8d2b 74674 
libhsm-bin_1.4.0-1_amd64.deb
 bafd02c7e03391d502fe41ef605c4cf163fce732afe5d737fcd8c869daae1e3b 1193974 
opendnssec-dbg-mysql_1.4.0-1_amd64.deb
 1d4c586351bdcfd2ae2ce0719872c5d79fc7c894c75cbd4713f38076d633ee9d 1131286 
opendnssec-dbg-sqlite3_1.4.0-1_amd64.deb
Files: 
 407cf4ae6a030124d60b175d0e81de34 2023 admin extra opendnssec_1.4.0-1.dsc
 96399851f16cf68de53c974c0d07aa5b 985512 admin extra 
opendnssec_1.4.0.orig.tar.gz
 b9ea2cbc3e638a9f78a110d47924ee5a 18547 admin extra 
opendnssec_1.4.0-1.debian.tar.gz
 7b4fdc22ae67aa629bc9c3f6eae394fd 50042 misc extra 
opendnssec-common_1.4.0-1_all.deb
 9d2a17fded18477aa5fbd9271193daef 23988 misc extra opendnssec_1.4.0-1_all.deb
 228569d8acdc4151584577fc6f19f913 60468582 doc extra 
opendnssec-doc_1.4.0-1_all.deb
 1dc8453ec5cfa594150947ac6931c951 36124 admin extra 
opendnssec-enforcer_1.4.0-1_all.deb
 d35a8bc3f129cca62af4caedc05cd0e1 185968 admin extra 
opendnssec-enforcer-mysql_1.4.0-1_amd64.deb
 b0bb0b521fd29aaeb726444169657600 172496 admin extra 
opendnssec-enforcer-sqlite3_1.4.0-1_amd64.deb
 204022d7e27c11f2d454fa65dae55e10 194646 admin extra 
opendnssec-signer_1.4.0-1_amd64.deb
 e9881e16a18171d664470403db58abc1 74674 misc extra

Accepted jxrlib 1.0-2 (source amd64)

2013-04-25 Thread Mathieu Malaterre

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 11:17:36 +0200
Source: jxrlib
Binary: libjxr0 libjxr-dev libjxr-tools
Architecture: source amd64
Version: 1.0-2
Distribution: unstable
Urgency: low
Maintainer: Mathieu Malaterre ma...@debian.org
Changed-By: Mathieu Malaterre ma...@debian.org
Description: 
 libjxr-dev - JPEG-XR lib - dev files
 libjxr-tools - JPEG-XR lib - command line apps
 libjxr0- JPEG-XR lib - libraries
Changes: 
 jxrlib (1.0-2) unstable; urgency=low
 .
   * Fix man page typos
   * Remove broken d/watch file
Checksums-Sha1: 
 e72b072f61cf62f7e5ecb609166aadaea7c483ae 1930 jxrlib_1.0-2.dsc
 a1205047ab9b01bbf7168e058818ac966bac73b8 9753 jxrlib_1.0-2.debian.tar.gz
 d4868c5f4198082a7a66c9f857c8b3a855072577 164392 libjxr0_1.0-2_amd64.deb
 7a68d6b1e9a06bdfbbe5c22f3c7389fdac7e367c 34656 libjxr-dev_1.0-2_amd64.deb
 8ffa6f1a2dd69fe78b2f6bd3406c7e9b52e70abc 19012 libjxr-tools_1.0-2_amd64.deb
Checksums-Sha256: 
 f210105f271e67fcf2e13cd8a2b8b1dd430a8dc185e7f8d610e0a3f44c63774e 1930 
jxrlib_1.0-2.dsc
 8e05ac72f7425439a373e942b79377e1e985c8242d6f2a1613e882ee1f199120 9753 
jxrlib_1.0-2.debian.tar.gz
 1aa6270f48b97607df4084c94c535ed4356252938033e334699f1b77d203bab2 164392 
libjxr0_1.0-2_amd64.deb
 5855a939682f2658d5d1a62e3f29d1a7fb19acffbfe97e329b9b5deb0fe7957b 34656 
libjxr-dev_1.0-2_amd64.deb
 77378c7956976538b598667bed6a8309da38ccb37edfdd6565eb7fb6d8f1d669 19012 
libjxr-tools_1.0-2_amd64.deb
Files: 
 a7919bfcf47910725e2405faa77e2b09 1930 graphics optional jxrlib_1.0-2.dsc
 3fc8a1eecd12eac2b3530031d75b7026 9753 graphics optional 
jxrlib_1.0-2.debian.tar.gz
 ed572af8fe7a58a583d1c9cea218bb55 164392 libs optional libjxr0_1.0-2_amd64.deb
 e16605704086dcccd49b4982c32d3598 34656 libdevel optional 
libjxr-dev_1.0-2_amd64.deb
 9914451636aa3578fc1493c81c111784 19012 utils optional 
libjxr-tools_1.0-2_amd64.deb

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

iQIcBAEBAgAGBQJRePkhAAoJEAFx4YKK4JNF95wP/R9pujFSvXi3Hcl+2aSeMfVp
8E34xXZdcMCG4XNES4OhaG95aFuwQe51BBfnChDBv1Iw2wLJnru1KBmc4pi3kQW7
f34/jTNPqAcMkKalJd5CC0q6FTiuslyUH65wz5vipPE/qMKsqV9uX7966aEVaHyf
gMRsbbPABpdcwoEhHyEhC3lklYD0Q1Eol7Yn2wk95MueAQpYhTkLoLerERRYP9QB
fYqgkeS6BoXlcKqEU1OHT37rG9IzD/PFtPPNWPK5Iz20WRaNfoDZA3Xx/vIDOP/4
vy2G5PD1R58Znh10WFKbtlISs8hqkKq+sW19DhpxCTlpoQRo5S1JiHhKErlEViti
GmpV3+zuJIfKcs66CyDgs3e3fMyEJWtSzBdQKj//598TsQ5dKfB6bfgcr0/HeQtI
VqWoV5FwJwnqD1psz8ytEsvowNEqhBqsDsx00s0dD2WXcqjrodNKE/QlGhGsz72F
BCiacXGedCZaDbmAdc3uI4C/sKKcDPI5otnvib7Gsn7XTb0wHeqMfBueXigLduQo
/Mm9SJ9paQn/LoShy1GFFarxF4fAvy/UPBT/IUrJSCRaekNaN+2xF9AjXiX9GGMs
fbgmxU3XxC0rClA69HveYuyviJkb6AsVm1VCAvMi8l4IHyHK2vBeo7K3BwUBhOM9
xVMDzo8oWlxmKsvVOT0z
=ftFM
-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: http://lists.debian.org/e1uvimn-0001jq...@franck.debian.org

Accepted live-build 3.0.2-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 12:41:54 +0200
Source: live-build
Binary: live-build live-build-cgi
Architecture: source all
Version: 3.0.2-1
Distribution: unstable
Urgency: low
Maintainer: Debian Live Project debian-l...@lists.debian.org
Changed-By: Daniel Baumann dan...@debian.org
Description: 
 live-build - Live System Build Scripts
 live-build-cgi - Live System Build Scripts (CGI frontend)
Closes: 647607 648861 702537
Changes: 
 live-build (3.0.2-1) unstable; urgency=low
 .
   [ Daniel Baumann ]
   * Allowing to use parted its automatic offset handling at the beginning
 of a disk, rather than to harcode it to first block (Closes: #647607).
   * Aborting with error if hdd label has a whitespace (Closes: #648861).
   * Updating d-i suite symlink for wheezy release.
   * Correcting typo in grub2 config template.
   * Synchronise grub and grub2 splashes with internal live-build splash
 for syslinux bootloaders.
   * Removing non-existent --apt-indices none references.
   * Also showing distribution in lb config initial messages.
   * Making messages about reading system conffiles in lb config more
 accurate.
   * Harmonize handling of pre-existing gnupg dotfiles in chroot when
 handling fake signing keys for local repository.
   * Making some more debian source-selections conditional on certain image
 options.
   * Adding source_hooks for hooks on source images like already supported
 on binary images.
 .
   [ Richard Nelson ]
   * Add sanity check on config type to build for l-b-cgi.
   * Add _CGI_CONFIG_APPEND varialbe for appending options to lb config
 call on l-b-cgi frontend.
   * Change _CGI_CONFIG_APPEND to front of the lb config call on l-b-cgi
 frontend.
   * Removing quotes around _CGI_CONFIG_APPEND to handle multiple
 parameters correctly on l-b-cgi frontend.
   * Adding binary image type to config call on l-b-cgi frontend.
   * Add log information of git:://url for l-b-cgi frontend.
   * Append to log file on errors and not truncate the file on l-b-cgi
 frontend.
 .
   [ Daniel Baumann ]
   * Correcting spelling typos, thanks to Adam D. Barratt adam@adam-
 barratt.org.uk.
 .
   [ Raphaël Hertzog ]
   * Fixing win32-loader.ini by including the GTK related entries.
 .
   [ Daniel Baumann ]
   * Correcting typo directory when dereferencing syslinux symlinks when
 building chrooted, thanks to Luigi Capriotti l.caprio...@xbmc.org.
   * Using dpkg-divert in chroot_upstart script to handle upgrades of
 upstart during the build (Closes: #702537).
   * Using dpkg-divert for other diversions too to handle upgrades of the
 diverted stuff during build.
   * Adding generic live-build handle in chroot_dpkg for other live
 packages to act upon.
   * Updating fallback help message in live-build pseudo-command.
   * Correcting grammer error in live-build description.
   * Adding set -e in example auto scripts.
 .
   [ Richard Nelson ]
   * Converting l-b-cgi frontend to process forms with post.
 .
   [ Daniel Baumann ]
   * Cleaning up installer file locations for progress-linux.
   * Stripping out comments in package lists.
   * Updating derivatives archive-key signature validiation to look by
 default at both debian and debian-maintainers keyrings.
   * Updating bootstrap mirror for progress-linux.
Checksums-Sha1: 
 0c6211614ff468bf6fc583634615d4d77e111c5a 1315 live-build_3.0.2-1.dsc
 1997f9db87d78dc73085259b97b302bc4abe2bb4 163316 live-build_3.0.2.orig.tar.xz
 3d74f8215977cea8daff0687c2ebbbf0256fc1a1 52128 live-build_3.0.2-1.debian.tar.xz
 2378ed16be8f187bf467b4c23d8f944868dff816 211656 live-build_3.0.2-1_all.deb
 64df26e41e5dacef43cbc915e7408e182fc4343c 76994 live-build-cgi_3.0.2-1_all.deb
Checksums-Sha256: 
 d9d35ab75037d64a3a634f730b7b507682607828ccb326583a051789c183de24 1315 
live-build_3.0.2-1.dsc
 5c264f718999cff1e29507365df4373542b334385a88efaa979137e8e118a6c9 163316 
live-build_3.0.2.orig.tar.xz
 22c89f823fceb2f4b0afa567e217d1ac0310ca7ecb07ab75c90739b2327b3c13 52128 
live-build_3.0.2-1.debian.tar.xz
 098154a635b18b44f13a72f437aec7ee389ff639496e1a75d0aabe94b8e7 211656 
live-build_3.0.2-1_all.deb
 f1c7e59207af13a8f0a5d2d2a6e43c47eb22fcd54c2fd6acbd7c8f40517a771d 76994 
live-build-cgi_3.0.2-1_all.deb
Files: 
 44b4fe4783e1cd302ee42ea45fe11fba 1315 misc optional live-build_3.0.2-1.dsc
 93f4d6277839683e0d3c19d59a4b6c93 163316 misc optional 
live-build_3.0.2.orig.tar.xz
 13ae530f3e31b512c85f40b160c5a485 52128 misc optional 
live-build_3.0.2-1.debian.tar.xz
 62dcd49ffcb47d6581c5a97d7bb24f01 211656 misc optional 
live-build_3.0.2-1_all.deb
 2365b627f2aac5a2454a75a395428e3f 76994 misc optional 
live-build-cgi_3.0.2-1_all.deb

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

iEYEARECAAYFAlF5CU8ACgkQ+C5cwEsrK55fMACeLSqU5bEHJlUrYMoUpcnQMLM8
QiAAn1+TT6//uK72Mb1Spvx0chOxNm+y
=ocYY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to

Accepted live-images 4.0~a15-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 12:57:33 +0200
Source: live-images
Binary: live-images live-image-gnome-desktop live-image-kde-desktop 
live-image-lxde-desktop live-image-rescue live-image-standard 
live-image-xfce-desktop
Architecture: source all
Version: 4.0~a15-1
Distribution: unstable
Urgency: low
Maintainer: Live Systems Maintainers debian-l...@lists.debian.org
Changed-By: Daniel Baumann m...@daniel-baumann.ch
Description: 
 live-image-gnome-desktop - live-build configuration for the GNOME desktop live 
images
 live-image-kde-desktop - live-build configuration for the KDE live images
 live-image-lxde-desktop - live-build configuration for the LXDE desktop live 
images
 live-image-rescue - live-build configuration for the rescue live images
 live-image-standard - live-build configuration for the standard live images
 live-image-xfce-desktop - live-build configuration for the Xfce desktop live 
images
 live-images - live-build configurations (metapackage)
Changes: 
 live-images (4.0~a15-1) unstable; urgency=low
 .
   * Including i965-va-driver for wheezy now too.
   * Dropping conflicts/replaces to live-image-all again.
Checksums-Sha1: 
 b64ef8679a0579c48c10cb2ef81fdd4bad3ff49f 1694 live-images_4.0~a15-1.dsc
 b97336d58d0a6bf171dbb48598deb9b13df2c9f4 26384 live-images_4.0~a15.orig.tar.xz
 f2758ed8435c50dc72f36d560d74f4d5c91039ed 3988 
live-images_4.0~a15-1.debian.tar.xz
 42d146b95e15a354fdd906de297302dee727ba54 6166 live-images_4.0~a15-1_all.deb
 fb148385fbb9e673623a32ba1c0f519afd122457 10702 
live-image-gnome-desktop_4.0~a15-1_all.deb
 89c1b0f106e93b71150475fcde96f507ec08c3d6 10662 
live-image-kde-desktop_4.0~a15-1_all.deb
 5fa5b31ecdb8c829d15d36eedec56fb4f48cb493 10676 
live-image-lxde-desktop_4.0~a15-1_all.deb
 04e3f27ca666adb942ffca1bac83ef858fd668fb 12328 
live-image-rescue_4.0~a15-1_all.deb
 ad62d391a49641af72796f42bd284aea442a14dc 10152 
live-image-standard_4.0~a15-1_all.deb
 a5a119872866c650155a0495fd4542575cf13bd8 10656 
live-image-xfce-desktop_4.0~a15-1_all.deb
Checksums-Sha256: 
 a57f555e57729e60583d2a3679f85641746ad1c839a2ecd962d151220df76112 1694 
live-images_4.0~a15-1.dsc
 215981be5de9b59ad7f3aaebf67bda60846c638fc8046d599050ec5f890b1292 26384 
live-images_4.0~a15.orig.tar.xz
 ea600dacab8f2646a49dfb5899de0743dd8fca87dd5c9d714d254ed06d9d2c83 3988 
live-images_4.0~a15-1.debian.tar.xz
 d1d772e426e57fca592108944de9e5243c85fda53d41fc1dbadddaeecdeaac7b 6166 
live-images_4.0~a15-1_all.deb
 3dcd09d4a866592de535584e2a4e26098ed944a93e71973489b4fbb7386726fa 10702 
live-image-gnome-desktop_4.0~a15-1_all.deb
 e6dea5b6c6737eeb602be695d3031831115401671c50941780a66850475d5504 10662 
live-image-kde-desktop_4.0~a15-1_all.deb
 4eb6b5ada23d30116ca3a18a07e431d8312386d3e30edc3a74372369723ece40 10676 
live-image-lxde-desktop_4.0~a15-1_all.deb
 101cde5f8e081df745888ac37931b93b4b604df9be4b26e3b66ee63d0f27fae2 12328 
live-image-rescue_4.0~a15-1_all.deb
 b991d2a96b4c9116a486838b0f182abedcd0887e1d0f16652510198045763530 10152 
live-image-standard_4.0~a15-1_all.deb
 9359e43d3a7798248914761e1268160ee7ee26e2070432b7d13921b983b0af30 10656 
live-image-xfce-desktop_4.0~a15-1_all.deb
Files: 
 5f09fc0121c53d93b4070e995eb3361c 1694 misc optional live-images_4.0~a15-1.dsc
 0f7c343bedb135df1b3349dfa61c55b5 26384 misc optional 
live-images_4.0~a15.orig.tar.xz
 8c449e2b101c6f68ebc8ec2d5d412e16 3988 misc optional 
live-images_4.0~a15-1.debian.tar.xz
 8fda8b338e7b67033c40dd5271d393e4 6166 metapackages optional 
live-images_4.0~a15-1_all.deb
 d853e946288dd75c47fbbe3eec520445 10702 misc optional 
live-image-gnome-desktop_4.0~a15-1_all.deb
 32170db83a6a614d219094dbbcf65a35 10662 misc optional 
live-image-kde-desktop_4.0~a15-1_all.deb
 9cd720b448e9d73988249ba8ff30e8d9 10676 misc optional 
live-image-lxde-desktop_4.0~a15-1_all.deb
 71210084d3666993302074b1961c0058 12328 misc optional 
live-image-rescue_4.0~a15-1_all.deb
 5ec174cd61c2f9b49d44e0897d37687f 10152 misc optional 
live-image-standard_4.0~a15-1_all.deb
 39e632d96574ea61f5b047eadc2dd933 10656 misc optional 
live-image-xfce-desktop_4.0~a15-1_all.deb

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

iEYEARECAAYFAlF5DGkACgkQ+C5cwEsrK5795wCdGHvaXJtZs9z+b0ibE+3K/Jre
hNUAnjEWVScIvRvNE2Rpb/6wyaAhe1Gn
=/6ao
-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: http://lists.debian.org/e1uvjwl-0006sr...@franck.debian.org

Accepted live-tools 3.0.20-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 12:53:45 +0200
Source: live-tools
Binary: live-tools
Architecture: source all
Version: 3.0.20-1
Distribution: unstable
Urgency: low
Maintainer: Debian Live Project debian-l...@lists.debian.org
Changed-By: Daniel Baumann dan...@debian.org
Description: 
 live-tools - Live System Support Scripts
Closes: 706100
Changes: 
 live-tools (3.0.20-1) unstable; urgency=low
 .
   * Detect being run in a live system being built on a live system by
 looking for the /.live-build handle provided by live-build in live-
 update-initramfs.
   * Correcting symlink to point to the correct section for live-update-
 initramfs manpage (Closes: #706100).
Checksums-Sha1: 
 94d8916014713e57c6b2a90e6309a02a335ec846 1266 live-tools_3.0.20-1.dsc
 380483b71f45ac3fba377c1456ec7d9b7de9fefa 26504 live-tools_3.0.20.orig.tar.xz
 6e994d85d1c8f109f9e02ff1113815369f6c579f 5304 live-tools_3.0.20-1.debian.tar.xz
 1d1224b419fef6c98b33658cfc4502d285b0706a 27196 live-tools_3.0.20-1_all.deb
Checksums-Sha256: 
 4ff03457808ccb0de2dd983650150eb03290257e99b250e4a925c1710676f917 1266 
live-tools_3.0.20-1.dsc
 32bca88d52f80b26909f12dbe556cad25b9a66e9705092e4451539c2b62ec835 26504 
live-tools_3.0.20.orig.tar.xz
 2a4b6a46f70f86ad1a0a565a46d052b283c0c66527db5c95d0f6e3cd6f4b021f 5304 
live-tools_3.0.20-1.debian.tar.xz
 77f97744828c3b92df4c957c32635a8d905435e07e13873d54b504bb5fe102fe 27196 
live-tools_3.0.20-1_all.deb
Files: 
 c6728fe1d5a48adbc3b7e3be919f17e1 1266 misc optional live-tools_3.0.20-1.dsc
 115264b9e69a71b5b2f4c743a5686868 26504 misc optional 
live-tools_3.0.20.orig.tar.xz
 bffc9366cbbf4723700fb541213e3ff8 5304 misc optional 
live-tools_3.0.20-1.debian.tar.xz
 9243fb687e31c4d3f0a2cc5c50b36bde 27196 misc optional 
live-tools_3.0.20-1_all.deb

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

iEYEARECAAYFAlF5C48ACgkQ+C5cwEsrK5488QCeIU3rP2hLKVnDo39YS+dKJJoH
9cYAn2E4Kt3SuoWlvWLA6s3wqAQKdiUT
=7iyB
-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: http://lists.debian.org/e1uvjwq-0006wh...@franck.debian.org

Accepted soundkonverter 2.0.1-1 (source amd64)

2013-04-25 Thread Michael Meskes

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 12:56:10 +0200
Source: soundkonverter
Binary: soundkonverter
Architecture: source amd64
Version: 2.0.1-1
Distribution: unstable
Urgency: low
Maintainer: Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org
Changed-By: Michael Meskes mes...@debian.org
Description: 
 soundkonverter - audio converter frontend for KDE
Changes: 
 soundkonverter (2.0.1-1) unstable; urgency=low
 .
   * Imported Upstream version 2.0.1
Checksums-Sha1: 
 989d2356555cc5d2d6e5afbf045983780ec6dec9 1508 soundkonverter_2.0.1-1.dsc
 3922d68550f472bee6765cdd9d23742cc1099cbe 565860 
soundkonverter_2.0.1.orig.tar.gz
 57184d4a39f40aed322725e71bf35f2808f69bb2 4291 
soundkonverter_2.0.1-1.debian.tar.gz
 41d779a53ca5b369b514a722e89561415a92aff2 1059708 
soundkonverter_2.0.1-1_amd64.deb
Checksums-Sha256: 
 cfbb330c5dd5f3b0ec88a1212da7fcd197c8e9511afb3a502ed5b1190659e916 1508 
soundkonverter_2.0.1-1.dsc
 7a529c783a95b258b38ae63f2b24a46b2feb535421dde06af4156b2f32c9473d 565860 
soundkonverter_2.0.1.orig.tar.gz
 99d8959c683b0481984ee331cc1fca0e28d0940b445c0a35c618ea735e008caf 4291 
soundkonverter_2.0.1-1.debian.tar.gz
 58344b69fa9674a853c218a681803ef7b9f4508c9e75f6106f39c1d9d09c6e26 1059708 
soundkonverter_2.0.1-1_amd64.deb
Files: 
 d21867ffc15a096c2f4bbb99be945a85 1508 kde optional soundkonverter_2.0.1-1.dsc
 d4f039003954c5279e56113237f608ca 565860 kde optional 
soundkonverter_2.0.1.orig.tar.gz
 1bb27eb1c0f52cede664a13213b3bf32 4291 kde optional 
soundkonverter_2.0.1-1.debian.tar.gz
 30ca1d1421f77ee9eaf5916e2cf80869 1059708 kde optional 
soundkonverter_2.0.1-1_amd64.deb

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

iD8DBQFReQ3NVkEm8inxm9ERArZ/AJ0dY+IVIsEVSByYX0khQe9puQbn1QCfVW9s
pjyr2udqvgAgowpjU7fbeXg=
=hgCT
-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: http://lists.debian.org/e1uvkba-0001yq...@franck.debian.org

Accepted cinnamon 1.7.4-2 (source amd64 all)

2013-04-25 Thread Nicolas Bourdaud

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 13:12:41 +0200
Source: cinnamon
Binary: cinnamon cinnamon-common cinnamon-dbg
Architecture: source amd64 all
Version: 1.7.4-2
Distribution: unstable
Urgency: low
Maintainer: Nicolas Bourdaud nicolas.bourd...@gmail.com
Changed-By: Nicolas Bourdaud nicolas.bourd...@gmail.com
Description: 
 cinnamon   - Innovative and comfortable desktop
 cinnamon-common - Innovative and comfortable desktop (Common data files)
 cinnamon-dbg - Innovative and comfortable desktop (Debugging symbols)
Closes: 705903
Changes: 
 cinnamon (1.7.4-2) unstable; urgency=low
 .
   * Fix dependency on python-gi-cairo (Closes: #705903)
Checksums-Sha1: 
 839a1d7dd3f5caac7cdcf790249a2a0703129187 3168 cinnamon_1.7.4-2.dsc
 5e19bd8a5b6054dec922b787deb830398fc0996f 47557 cinnamon_1.7.4-2.debian.tar.gz
 2f6f7293328f3e170c9c5d63dcb97978a0e968db 625430 cinnamon_1.7.4-2_amd64.deb
 9bb6b17846aec2a408f7604780d3fc25fee1754d 1918368 
cinnamon-common_1.7.4-2_all.deb
 75f5a796cabe6c5f5cb4759d195f6e055e372320 1012394 cinnamon-dbg_1.7.4-2_amd64.deb
Checksums-Sha256: 
 b718fcb8c24d3fa2d926e916bd85c9af46a8b4b9fa81cbf38ecad733e90190e5 3168 
cinnamon_1.7.4-2.dsc
 0079b384795de659201dfe1dd48f018d500594bf294f95780a83c761cf2121c0 47557 
cinnamon_1.7.4-2.debian.tar.gz
 ef59b5ac7ecddac76deae56d21e541746ca4f2ce19a50ff2a85d47ab0e593542 625430 
cinnamon_1.7.4-2_amd64.deb
 fb764255cd06932b555ee0a3027d749a6d02719e83483f0d11855b1b3e4dd074 1918368 
cinnamon-common_1.7.4-2_all.deb
 f66be3e704d47e6754ea603a068e492b561337f82cf32900a86efdb35212c45d 1012394 
cinnamon-dbg_1.7.4-2_amd64.deb
Files: 
 e0ffbc2dc64f8207b19dc880f4e93c51 3168 x11 optional cinnamon_1.7.4-2.dsc
 dc8ca5f8d75ea6736d19155385a27927 47557 x11 optional 
cinnamon_1.7.4-2.debian.tar.gz
 b28f1dde662eb4b04b690c84975c6325 625430 x11 optional cinnamon_1.7.4-2_amd64.deb
 f7b50e0841e6142f4c5eb9587fb6dc71 1918368 x11 optional 
cinnamon-common_1.7.4-2_all.deb
 18d98ddaa96dff6a2ad9756fb27b83f2 1012394 debug extra 
cinnamon-dbg_1.7.4-2_amd64.deb

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

iQIcBAEBAgAGBQJReRLcAAoJEMTcslrXGlly6t4P+gOM/+KtWTl/TTlvx3cdyvc9
8Do3CjvDwzdqFF/UIAK+lEuPjmTw49qFj4DDlYqBRX2VU4icfyepgr073g4OJJhj
YaDaE/ZJD1MTvZm7gunjoje5fwicvsGzYEuUQx4Cix0zYL0x/VDFgpCB55KHvpop
Unr1GTG8RD/PF1l8YWJ0PpY8aB/pGW7ahP8FiVKIOplV0y9K2kTgT0SS2ezSp/gl
CSfe/R/RRTQ3XnlD6QHmJefBo0t7nPKxu3Mc++2LjvgNeP7qLSC/wjScyEBPdD+A
8QdBdZyrHDk01VajTI0kKTbRZOZl0PE/SAxdGPPYf6YsFMvWckk3RSSzUjTc2vaj
aGTjY9cWC+XRvAyzDy4vxnB98zp0TiTdysxtrdJFfpaxW58HZT2UKfDnGhJorq+c
VCruKgRXQslRXOX4EiqvppHCiaxdF8STloFMxmtQQPmU/wAgadAOqlDSbIvJOQMf
hrOu6zV8sKWSLB2qfYKGOEV8jUGD46mSz26GQRLR3YQ3jl/aFxxuAUaXmRpTsEpe
HIQEKuTxg/+SWgSW/xkd9OLrxhzvWMK2aoSnkZl0s3ZvzL3jW8usyMiY7D40gG/f
cGYgEaENjriUu38I8oj2FBwIk6BpdVADBEjqgDWHB7o0e4yxAg2P1Yu/jy0KBMBA
uSe1tRZbeieFWPRCzcmQ
=5dO3
-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: http://lists.debian.org/e1uvkpl-0005wd...@franck.debian.org

Accepted wims-moodle 4.0-3 (source all)

2013-04-25 Thread Georges Khaznadar

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 14:08:02 +0200
Source: wims-moodle
Binary: wims-moodle
Architecture: source all
Version: 4.0-3
Distribution: unstable
Urgency: low
Maintainer: Georges Khaznadar georg...@debian.org
Changed-By: Georges Khaznadar georg...@debian.org
Description: 
 wims-moodle - module for Moodle featuring Wims mini-classes
Closes: 705992
Changes: 
 wims-moodle (4.0-3) unstable; urgency=low
 .
   * suppressed the postinstallation subroutine about languages, which
 became obsoleted (the fixed file had not been correctly saved in
 the previous revision). Closes: #705992
   * removed the file localwims.template which was installed under
 /usr/share/docs. The contents of this file is now part of the
 postinst script
Checksums-Sha1: 
 954728f7cc088ced4389038675ebe7ebcfaf26ef 1112 wims-moodle_4.0-3.dsc
 cb187d3d9359709fca70b3f3aa3bfc41e8a9510e 9072 wims-moodle_4.0-3.debian.tar.gz
 d3998368b5ecab8d5446d6ebde26e30683531d6d 27164 wims-moodle_4.0-3_all.deb
Checksums-Sha256: 
 a9165769e9e3f75eff41498253ac9beeaedd63f5b925f7849405773e16387aa3 1112 
wims-moodle_4.0-3.dsc
 dfc718469bd1c188e6bfb02944e8298bb6bdd5fd0692bce186d886389c5a56e8 9072 
wims-moodle_4.0-3.debian.tar.gz
 342ce140ec6a51f300a9963da2e70327a6faae3e1604a44d721e6c7c45b43623 27164 
wims-moodle_4.0-3_all.deb
Files: 
 149dc3d975eb1291200f24fe62f91eae 1112 web extra wims-moodle_4.0-3.dsc
 8fb30e7167bc01886aa454169e9e2a5f 9072 web extra wims-moodle_4.0-3.debian.tar.gz
 f1e120ba1c3080447e0a8a3bb8aa6a26 27164 web extra wims-moodle_4.0-3_all.deb

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

iD8DBQFReSGqnfmb2hFpETARAu9lAJwLcgaMYv+RoVNwx83U+qHDzdNnWwCff6qZ
lLXUlGe2IKGdhKqW0uYT/T8=
=bmTj
-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: http://lists.debian.org/e1uvllv-0003cb...@franck.debian.org

Accepted openjdk-6 6b27-1.12.5-1 (source amd64 all)

2013-04-25 Thread Matthias Klose

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 13:04:27 +0200
Source: openjdk-6
Binary: openjdk-6-jdk openjdk-6-jre-headless openjdk-6-jre openjdk-6-jre-lib 
openjdk-6-demo openjdk-6-source openjdk-6-doc openjdk-6-dbg icedtea-6-jre-cacao 
icedtea-6-jre-jamvm openjdk-6-jre-zero
Architecture: source amd64 all
Version: 6b27-1.12.5-1
Distribution: unstable
Urgency: low
Maintainer: OpenJDK Team open...@lists.launchpad.net
Changed-By: Matthias Klose d...@ubuntu.com
Description: 
 icedtea-6-jre-cacao - Alternative JVM for OpenJDK, using Cacao
 icedtea-6-jre-jamvm - Alternative JVM for OpenJDK, using JamVM
 openjdk-6-dbg - Java runtime based on OpenJDK (debugging symbols)
 openjdk-6-demo - Java runtime based on OpenJDK (demos and examples)
 openjdk-6-doc - OpenJDK Development Kit (JDK) documentation
 openjdk-6-jdk - OpenJDK Development Kit (JDK)
 openjdk-6-jre - OpenJDK Java runtime, using ${vm:Name}
 openjdk-6-jre-headless - OpenJDK Java runtime, using ${vm:Name} (headless)
 openjdk-6-jre-lib - OpenJDK Java runtime (architecture independent libraries)
 openjdk-6-jre-zero - Alternative JVM for OpenJDK, using Zero/Shark
 openjdk-6-source - OpenJDK Development Kit (JDK) source files
Changes: 
 openjdk-6 (6b27-1.12.5-1) unstable; urgency=low
 .
   * IcedTea 1.12.5 release.
   * Security fixes:
 - S6657673, CVE-2013-1518: Issues with JAXP.
 - S7200507: Refactor Introspector internals.
 - S8000724, CVE-2013-2417: Improve networking serialization.
 - S8001031, CVE-2013-2419: Better font processing.
 - S8001040, CVE-2013-1537: Rework RMI model.
 - S8001322: Refactor deserialization.
 - S8001329, CVE-2013-1557: Augment RMI logging.
 - S8003335: Better handling of Finalizer thread.
 - S8003445: Adjust JAX-WS to focus on API.
 - S8003543, CVE-2013-2415: Improve processing of MTOM attachments.
 - S8004261: Improve input validation.
 - S8004336, CVE-2013-2431: Better handling of method handle
   intrinsic frames.
 - S8004986, CVE-2013-2383: Better handling of glyph table.
 - S8004987, CVE-2013-2384: Improve font layout.
 - S8004994, CVE-2013-1569: Improve checking of glyph table.
 - S8005432: Update access to JAX-WS.
 - S8005943: (process) Improved Runtime.exec.
 - S8006309: More reliable control panel operation.
 - S8006435, CVE-2013-2424: Improvements in JMX.
 - S8006790: Improve checking for windows.
 - S8006795: Improve font warning messages.
 - S8007406: Improve accessibility of AccessBridge.
 - S8007617, CVE-2013-2420: Better validation of images.
 - S8007667, CVE-2013-2430: Better image reading.
 - S8007918, CVE-2013-2429: Better image writing.
 - S8009063, CVE-2013-2426: Improve reliability of ConcurrentHashMap.
 - S8009305, CVE-2013-0401: Improve AWT data transfer.
 - S8009699, CVE-2013-2421: Methodhandle lookup.
 - S8009814, CVE-2013-1488: Better driver management.
 - S8009857, CVE-2013-2422: Problem with plugin.
 - RH952389: Temporary files created with insecure permissions.
   * Backports;
 - S7197906: BlockOffsetArray::power_to_cards_back() needs to handle
32 bit shifts
 - S7036559: ConcurrentHashMap footprint and contention improvements.
 - S5102804: Memory leak in Introspector.getBeanInfo(Class) for custom
   BeanInfo: Class param (with WeakCache from S6397609).
 - S6501644: Sync LayoutEngine *code* structure to match ICU.
 - S6886358: Layout code update.
 - S6963811: Deadlock-prone locking changes in Introspector.
 - S7017324: Kerning crash in JDK 7 since ICU layout update.
 - S7064279: Introspector.getBeanInfo() should release some resources
   in timely manner.
 - S8004302: javax/xml/soap/Test7013971.java fails since jdk6u39b01.
 - S7133220: Additional patches to JAXP 1.4.5 update 1 for 7u4 (partial
   for S6657673).
 - S8009530: ICU Kern table support broken.
   * Bug fixes:
 - OJ3: Fix get_stack_bounds memory leak (alternate fix for S7197906).
 - PR1362: Fedora 19 / rawhide FTBFS SIGILL.
 - PR1338: Remove dependency on libXp.
 - PR1339: Simplify the rhino class rewriter to avoid use of concurrency.
 - PR1319: Correct #ifdef to #if
 - Give xalan/xerces access to their own internal packages.
Checksums-Sha1: 
 4c91e8de4669e5d395fa887454587b9c07c6a773 3010 openjdk-6_6b27-1.12.5-1.dsc
 2c3059930b08aaa75b104f3d4778cc21815552a8 62969523 
openjdk-6_6b27-1.12.5.orig.tar.gz
 8236c582937e9ac625808997b012416923efb914 165709 openjdk-6_6b27-1.12.5-1.diff.gz
 a47d3fc16535b700a6cf5d3a2a269a119e31f596 11060792 
openjdk-6-jdk_6b27-1.12.5-1_amd64.deb
 05a813ae9a21dbe11e448dca0e554bdcc3ac3dd9 25463938 
openjdk-6-jre-headless_6b27-1.12.5-1_amd64.deb
 f2b0b881739f1b767178761fb334f80ccf9b 237402 
openjdk-6-jre_6b27-1.12.5-1_amd64.deb
 e165b765a34b1849e00844745eec0b7d8edc74bc 2303644 
openjdk-6-demo_6b27-1.12.5-1_amd64.deb
 07c5a92970f9a3bbb8943cc0633b18420bf52bd5 145819776

Accepted rsyslog 7.3.12-1 (source amd64 all)

2013-04-25 Thread Michael Biebl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Apr 2013 15:14:37 +0200
Source: rsyslog
Binary: rsyslog rsyslog-doc rsyslog-mysql rsyslog-pgsql rsyslog-mongodb 
rsyslog-gssapi rsyslog-gnutls rsyslog-relp
Architecture: source amd64 all
Version: 7.3.12-1
Distribution: experimental
Urgency: low
Maintainer: Michael Biebl bi...@debian.org
Changed-By: Michael Biebl bi...@debian.org
Description: 
 rsyslog- reliable system and kernel logging daemon
 rsyslog-doc - documentation for rsyslog
 rsyslog-gnutls - TLS protocol support for rsyslog
 rsyslog-gssapi - GSSAPI authentication and encryption support for rsyslog
 rsyslog-mongodb - MongoDB output plugin for rsyslog
 rsyslog-mysql - MySQL output plugin for rsyslog
 rsyslog-pgsql - PostgreSQL output plugin for rsyslog
 rsyslog-relp - RELP protocol support for rsyslog
Changes: 
 rsyslog (7.3.12-1) experimental; urgency=low
 .
   * New upstream release.
   * Disable log file encryption support for now.
Checksums-Sha1: 
 ef3ec86741d4dae537e9a05521bce7bcbbcf0491 2436 rsyslog_7.3.12-1.dsc
 9e96ea42c75f3e547cf0140d94a5415fc5dc4f70 2891091 rsyslog_7.3.12.orig.tar.gz
 cbe165ad3bb978feef9b2cdd61afbbba592b05ed 29163 rsyslog_7.3.12-1.debian.tar.gz
 006418f978980e54f971fc837c92819de28d7846 702136 rsyslog_7.3.12-1_amd64.deb
 5fa42a3249dc238cf5a1d93e94b12d72655013d4 1197022 rsyslog-doc_7.3.12-1_all.deb
 a1f691cb428f8e6e6192481a17ebd812f2320fcf 146054 
rsyslog-mysql_7.3.12-1_amd64.deb
 dbad6c808aa63e502002dc420d07ce3165bd45e3 144316 
rsyslog-pgsql_7.3.12-1_amd64.deb
 f3d5a47a176695848246ef78751c5de3a76c1a04 146318 
rsyslog-mongodb_7.3.12-1_amd64.deb
 2becd436662092a2d84e6c9570347bbd243f104a 152446 
rsyslog-gssapi_7.3.12-1_amd64.deb
 97ec11088b10f8aeae13ceedab21751935abc329 151284 
rsyslog-gnutls_7.3.12-1_amd64.deb
 b6ae8954017ed1d7e6993bc45a22918aa770b91c 147536 rsyslog-relp_7.3.12-1_amd64.deb
Checksums-Sha256: 
 563edf2947daf0cef6499b858a1d02f7490f29175e0fd0a03469294ad084aa1f 2436 
rsyslog_7.3.12-1.dsc
 0d795de5866c173d144a72bcbf7983fce47d1e91a0f48c50a0359dce3ca21e0a 2891091 
rsyslog_7.3.12.orig.tar.gz
 6c80d0b7b7eefd849fab01b5d55c89de0e666cc3caf0186d955953fd0334b3e2 29163 
rsyslog_7.3.12-1.debian.tar.gz
 38dc0e95456478a81f9c1b3cbe3baf8fe3357edbf5ec2bb7cc346cf7a89a13ba 702136 
rsyslog_7.3.12-1_amd64.deb
 02185e385e1a4ec3c78322ce06780c2d1cd07df96ff903c0ea7a00ae9c324569 1197022 
rsyslog-doc_7.3.12-1_all.deb
 2b34b02ab660e32c586060e48777008e719f5fda12f0686bc8ecd3fdeef06ba6 146054 
rsyslog-mysql_7.3.12-1_amd64.deb
 9161be352dfd7fac8a1f03710fffe9332467e9f89cc6c3ba1c72b4be0fd4c0c9 144316 
rsyslog-pgsql_7.3.12-1_amd64.deb
 fa6f3bc8d64055e406d1f040b718534af94b1ecef45639bded6d3155946f2229 146318 
rsyslog-mongodb_7.3.12-1_amd64.deb
 a233a7a3ae015a0790b84633a29761c51167e8f2c745b084786bd4a5b14cef18 152446 
rsyslog-gssapi_7.3.12-1_amd64.deb
 c84b23de3a547bfe0d00d7b5043b0b5e03718faa5d22e2b7102cd61d953b198c 151284 
rsyslog-gnutls_7.3.12-1_amd64.deb
 ebd22f61df28e7ea652235ea77e1cc15e38ffc2df9e70bd742f9a1fe0f8fbc0e 147536 
rsyslog-relp_7.3.12-1_amd64.deb
Files: 
 df779fa81795c1bd202da4048c27f770 2436 admin important rsyslog_7.3.12-1.dsc
 07fb94bc76eb2025c2a10f4fab9a9c02 2891091 admin important 
rsyslog_7.3.12.orig.tar.gz
 526cc832ca30e0fb82c743f9f12549d0 29163 admin important 
rsyslog_7.3.12-1.debian.tar.gz
 01435e400226691aab641e11d959b04a 702136 admin important 
rsyslog_7.3.12-1_amd64.deb
 404565a6b57da0d254b53820e26f00ef 1197022 doc extra rsyslog-doc_7.3.12-1_all.deb
 e7b068bd46a3fd35f519ed4f293526c8 146054 admin extra 
rsyslog-mysql_7.3.12-1_amd64.deb
 f94be8b1258d6cbf6729b7d9c89e17dc 144316 admin extra 
rsyslog-pgsql_7.3.12-1_amd64.deb
 c5d354cc07a1b2baa9607df799636004 146318 admin extra 
rsyslog-mongodb_7.3.12-1_amd64.deb
 bb00ca21fa6e771a392b6da3a0e5dd34 152446 admin extra 
rsyslog-gssapi_7.3.12-1_amd64.deb
 7cf368669fd58ed3308d6880cccf38b6 151284 admin extra 
rsyslog-gnutls_7.3.12-1_amd64.deb
 a5e84120971619f978dfea6b704765bb 147536 admin extra 
rsyslog-relp_7.3.12-1_amd64.deb

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

iQIcBAEBCAAGBQJReS1WAAoJEGrh3w1gjyLcSEIQAJfcVKJBOwBqEL5SU5V5b81C
jXb6a4fxocQDQWPb4S6/SEr1W/Tz+YnkqQFJnnmy0FyH/1GZ3OyIK8YJs09dp/Dk
0j5mFy6ayHzoz2aZ0hKRJ9RPU6IS6Cwktv8kjtKhhBImePNcVeSTvEJjx9LMoCxU
uOVYseMXcMDUgK2jInc0Gdy4UdkP96Ybug9TsJmUOWKP642JoB5SmagAOclxqd1O
msP+HVHs5mvzUWnNEkUFRzkxJtjEyWJlVtNGhBz1d2k/VUbiglAdvQa6V2Tk340s
wLz595Nz9MN0VJ48a2VGepRk0aiH3xNlsHtosSqz+se3J1oUy2JQiFG72Iz6fMx8
gQxaPsX9KXwbIN1LgPYr5GbLOy0neVHkNzu+Q79O6yPJ/2jeRHY7OC61l1LMvuyB
vl+CqtqBVsaLrFOZIGVVIHwWUSBaIMPek8OtnEEdKvNxfQHXHEkrEe2anStR85HF
83nzpAStwlDZ7xe8hIzG4zGixlohQZdmBeNVpJwsovpnnxjZvRFvnGOiS+dlEWmo
ymC0iucabYoHUuKBSLYgOO1SqX70qsnNUMV6dGCaUCV9qgCTV9KLpmBrsJ7NAp45
sW0sbVIGnatjM3d5zWHOtsxoc7gv3cT4tBz9qIxESEi5LyDIrLTNgz9J1syXKS4v
M0/1qof+WQrA8B3+wmub
=qo0a
-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:

Accepted antlr 2.7.7+dfsg-5 (source all amd64)

2013-04-25 Thread Emmanuel Bourg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Apr 2013 10:13:14 +0200
Source: antlr
Binary: antlr libantlr-java libantlr-dev libantlr2.7-cil antlr-doc python-antlr
Architecture: source all amd64
Version: 2.7.7+dfsg-5
Distribution: unstable
Urgency: low
Maintainer: Debian Java Maintainers 
pkg-java-maintain...@lists.alioth.debian.org
Changed-By: Emmanuel Bourg ebo...@apache.org
Description: 
 antlr  - language tool for constructing recognizers, compilers etc
 antlr-doc  - language tool for constructing recognizers, compilers etc
 libantlr-dev - language tool for constructing recognizers, compilers etc
 libantlr-java - language tool for constructing recognizers, compilers etc 
(java l
 libantlr2.7-cil - language tool for constructing recognizers, compilers etc
 python-antlr - language tool for constructing recognizers, compilers etc
Changes: 
 antlr (2.7.7+dfsg-5) unstable; urgency=low
 .
   * Team upload.
   * Updated the watch file (contributed by Bart Martens)
   * Bumped Standards-Version to 3.9.4 (no changes)
   * debian/copyright: Updated the Format URL
   * debian/copyright: Fixed a typo reported by Lintian
   * debian/copyright: Removed the GPL header
Checksums-Sha1: 
 71dfeb82f6b6bbb0ac4b78e83e86573c3278e155 2368 antlr_2.7.7+dfsg-5.dsc
 8724e1388fbcda71225467db57fad92ededdde4a 15421 antlr_2.7.7+dfsg-5.debian.tar.gz
 048114d059f8ee5166732aad2658573a25a8b90f 51340 
libantlr2.7-cil_2.7.7+dfsg-5_all.deb
 6c2e7948e2eea03f1e9e87a3ac6b3d6715ee4a23 901504 antlr-doc_2.7.7+dfsg-5_all.deb
 872488712d1b9332a3dc9f897d4b47d7337d946c 12240 antlr_2.7.7+dfsg-5_all.deb
 96368144d9aa1aa530d2196ff98aca43925cce56 433952 
libantlr-java_2.7.7+dfsg-5_all.deb
 f2377811487adb8169b1b4516fc23fc7a60c795a 27250 
python-antlr_2.7.7+dfsg-5_all.deb
 a999f5b724ee5981db42ab14f5d5cb97bdf2116d 353934 
libantlr-dev_2.7.7+dfsg-5_amd64.deb
Checksums-Sha256: 
 fd6bc39915bcbfff7815f6b9d3ca4da8fa2931d9606cb025fb50a257c18e87db 2368 
antlr_2.7.7+dfsg-5.dsc
 c3d8066d4f07fdf4dc19bd82e74a3975e76eeab18a95e7c9cc6098b530a8b804 15421 
antlr_2.7.7+dfsg-5.debian.tar.gz
 9d24cbb8ddcafb4c42755e261c75e0dfd84fa2d67bfdeed47e0b1a3b9b447e7e 51340 
libantlr2.7-cil_2.7.7+dfsg-5_all.deb
 a7e5cfffa42bffb9cc31625421efcec2d44dbfe10911df1f1b9a1f2bd85ed8f1 901504 
antlr-doc_2.7.7+dfsg-5_all.deb
 b354e6c657ba953bb4a44fc27fca1fdbfa5908b7623cb6c8ab03366c21d62d4e 12240 
antlr_2.7.7+dfsg-5_all.deb
 29710be30500197638ce320a44f84431f5b536ee77de1db567a6fa477399add9 433952 
libantlr-java_2.7.7+dfsg-5_all.deb
 4f656c3250a44f180779d348dbf611990815c8b77713d9dd15fb4cc1f3f2de45 27250 
python-antlr_2.7.7+dfsg-5_all.deb
 e2394b1a7e647f702fceee8a84c4c5af87dd4bbf619452bbf6ac9f683febed28 353934 
libantlr-dev_2.7.7+dfsg-5_amd64.deb
Files: 
 be0ce2f02b36d2c6e4c7758511b0c3b0 2368 java optional antlr_2.7.7+dfsg-5.dsc
 294f7e6aed2c4af58cc7fb0bc73c8759 15421 java optional 
antlr_2.7.7+dfsg-5.debian.tar.gz
 f87b6d17dd617a0bd14b7db42cd0563b 51340 cli-mono optional 
libantlr2.7-cil_2.7.7+dfsg-5_all.deb
 ebc6ae5b245786422a09e5554fdb7bb9 901504 doc optional 
antlr-doc_2.7.7+dfsg-5_all.deb
 f77a59bad2639fd2fc3f2ba2e8002b73 12240 java optional antlr_2.7.7+dfsg-5_all.deb
 33673c73cf204fc773ff3e82c93cc982 433952 java optional 
libantlr-java_2.7.7+dfsg-5_all.deb
 e1d137974eb46da7c15020d8b2eb77db 27250 python optional 
python-antlr_2.7.7+dfsg-5_all.deb
 3f2fb637efb14ac5afaf8f7edc5dccfb 353934 libdevel optional 
libantlr-dev_2.7.7+dfsg-5_amd64.deb

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

iQIcBAEBCAAGBQJReUmAAAoJEAVLu599gGRCNGgQAIQKFLtaLNFRaqnu2oA5/RhD
hQFCqF+ETp67ouI1ed5kHwTTvIttnNpIcgQgGBkUoOtGzZU+bHl1eCLfrkAa6i+T
vXu43ht2etFwohj+79X7f0SdwrbXmgOvLrjrQd9CcXg4I90Qd1mzK7heN5LKEeBe
mtpfByg4eqfZCOeCUjBqGkovgOpyGAQpWg59ndUd/pEmRkByVfzGlrkzPWlTXR7k
BmTBvHDy8xuwt4ShWZDt0C9J4fBh7z6rNAI5VdQvHFKNU3mKn5JT4FbmSAmXOz1K
pjW0Um1x1GdHbBPqREI3VWzu4U2kLgtU1D7xtBD4TED+W7Vq8R1rVvac7RNsL4YI
2IHNv8gyYqyACHiF5ReTQT8QRvs+F7Ib7YcVvcswVAeK5Um+3pVKx/gImRPh2SgP
cKm2WQ2yYGl8TdZs60mKIF3MraTZDl3U8SvH29q2HzLfXRpGuu0QYvr14MUU0PzM
TfyGzHZ+8vC8Jot4FL6ldKKVbxKGQ/iaHdC8v5McFM8V0Vtlhsfkf3wD27MhWyFg
dk1MrqW/fOp6znIMHmaNsWng/IPQxBMvFwIpD+YlEttHRctT1hBQglwjWcJWYTyf
t9beQMq/+0IeUTuz9M7NEm7OdaSrKC6C/gbi0UPL7el+R5H355IGkFG0FDrGfflf
4xP5k4UUp/SbKuipWWqb
=aHLF
-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: http://lists.debian.org/e1uvoa4-0002tr...@franck.debian.org

Accepted distro-info-data 0.14 (source all)

2013-04-25 Thread Stefano Rivera

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 25 Apr 2013 17:11:17 +0200
Source: distro-info-data
Binary: distro-info-data
Architecture: source all
Version: 0.14
Distribution: unstable
Urgency: low
Maintainer: Benjamin Drung bdr...@debian.org
Changed-By: Stefano Rivera stefa...@debian.org
Description: 
 distro-info-data - information about the distributions' releases (data files)
Changes: 
 distro-info-data (0.14) unstable; urgency=low
 .
   * Add Ubuntu 13.10, Saucy Salamander. Thanks Iain Lane.
Checksums-Sha1: 
 434bf255dfb8afac98777bcbc35e3b3e84397849 1640 distro-info-data_0.14.dsc
 7a6c01e98801db8ba36f99ad20065cf3ea7fee71 5685 distro-info-data_0.14.tar.gz
 66e4b1baa9cb5d3be24734682f2e7bf1fdbbc81d 4808 distro-info-data_0.14_all.deb
Checksums-Sha256: 
 3e759d5bb02568433435364e78a125b55e694c57930f69a6f703e0ddc9012c8c 1640 
distro-info-data_0.14.dsc
 40802b5d593fb550a5017ffa70aa8158d79ca86694f5312d4b9b9ef30239d969 5685 
distro-info-data_0.14.tar.gz
 310074cc7a7b193abc0a900274cf124a32a2c94fc19500ee5f6ed25165ef5af6 4808 
distro-info-data_0.14_all.deb
Files: 
 791773698897a921e34755990d9b7de5 1640 devel optional distro-info-data_0.14.dsc
 4785076f8131bcf7996255e26d0f1107 5685 devel optional 
distro-info-data_0.14.tar.gz
 a6225769e1ff5caa28ef42a7a9df1ea9 4808 devel optional 
distro-info-data_0.14_all.deb

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

iQIcBAEBCgAGBQJReUgzAAoJEACQ/CG1zRrM6vMP/RnYuD6TtZulvmmqHxW5wC55
3ajaSS68lkxnV8FPYtzAL5a3iF5I7105GW7DhrQI20Mxjd5acAKPkctkYdjAfP2x
tKX3YiHtgtIUqvD7huBCe2cN8oVZSNGiErlMyIWyBE4HC1hUnYFrsMjndC9/NgoR
mAkLLvPVeZKFwy5bSwuKsY+ce7UlOah+YBDS+Kyo5w2KE0chHhr6BpkdpaRnjKD+
X2jHnGK+Ne2Oz3LC/YJz3jol59TA0yYftHp3wFoIbhPWW1dxJL3TgTlK6/yN7dAZ
gIygiEggEr5lCG6aP3gZz+bs0MvvCyIwbWBVlguKkkhWZuR1syKibh2JQa1+R6c6
4e/4qGaCQRoT2Hh+4HIeNQstO872+6jPbuIV1Fo/Mk6Ox+LDfXfaM2CYd6QxoIYl
NPf9cJr8FoF9/0+rFiXQLKSAh/hqj0ecPt/m5OgZGu3hMxVcgILRppz72ABIwx+s
fB3Vi4trZhdutuW2uS5b5mId4CMu4rixg4lXMg2gc6HNzkGnbAmxoCzEJw9eH/5h
btboZrb0ehs6+uSOxR+f/32WsvSX7XvAvJzHS1QTysi8jBzfnyqdaslWeBExa+61
fn05zKw5gw1SvCNPmoiLO0PzmQNSFNaG1XW71/kNvy8Q2l4qE+Q2pqMt33aYLRMe
qoKzY6H6Jz5H/1rRsB1o
=mAp1
-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: http://lists.debian.org/e1uvoa8-0002wc...@franck.debian.org

Accepted libcpan-uploader-perl 0.103004-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 17:25:23 +0200
Source: libcpan-uploader-perl
Binary: libcpan-uploader-perl
Architecture: source all
Version: 0.103004-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Alessandro Ghedini gh...@debian.org
Description: 
 libcpan-uploader-perl - module to upload packages to the CPAN
Changes: 
 libcpan-uploader-perl (0.103004-1) unstable; urgency=low
 .
   [ Salvatore Bonaccorso ]
   * Change search.cpan.org based URIs to metacpan.org based URIs
 .
   [ Alessandro Ghedini ]
   * New upstream release
   * Update upstream copyright years
   * (Build-)Depends on libfile-homedir-perl and liblwp-protocol-https-perl
   * Add myself to Uploaders
Checksums-Sha1: 
 d558a171200578349b57b48dda8b63c4df93fbba 2378 
libcpan-uploader-perl_0.103004-1.dsc
 6876e56f50c7f9b977b70de8a9bff8ebc16e85f6 16581 
libcpan-uploader-perl_0.103004.orig.tar.gz
 fda1cfc9abd628db6e79cbe07bdb9bebead5c807 2518 
libcpan-uploader-perl_0.103004-1.debian.tar.gz
 94b0b61c0323c7dec9fd05d4bf54622b33f29982 14018 
libcpan-uploader-perl_0.103004-1_all.deb
Checksums-Sha256: 
 030ba5a2b9afa4846d34f8e7fd10162560774957c05745385481e182b81d0fe4 2378 
libcpan-uploader-perl_0.103004-1.dsc
 cfaf6d4ad32a92cdefabb3abaf1f43c7c11aca5afd5561ea6f691065ac396e97 16581 
libcpan-uploader-perl_0.103004.orig.tar.gz
 2e96ebee7d25e22f32309dd3eab8ee17572f5f3b44132f3a682be0f563b610dd 2518 
libcpan-uploader-perl_0.103004-1.debian.tar.gz
 c8d8e2036e4544631a9bf06bdabd335e721415196680a276d26ee3311aca95d5 14018 
libcpan-uploader-perl_0.103004-1_all.deb
Files: 
 751d4a664583733a7360aec9a2ee8e46 2378 perl optional 
libcpan-uploader-perl_0.103004-1.dsc
 b0fdd7b1a204dc14522eb4a23045c305 16581 perl optional 
libcpan-uploader-perl_0.103004.orig.tar.gz
 06560b408f9cfb1cb57b74eb327817fb 2518 perl optional 
libcpan-uploader-perl_0.103004-1.debian.tar.gz
 f3d5cff2aee75f0ee38c7cc1023f5847 14018 perl optional 
libcpan-uploader-perl_0.103004-1_all.deb

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

iQIcBAEBAgAGBQJReUuMAAoJEK+lG9bN5XPLavAP/2/CBHPBxGAn7S7zHrK6P3hB
w7N+bpiMMTAb3mCgrnhr5yalZeYsWdsVfioDnqZsbRfW+c8yfNM/f84xfxK2YnyW
dxyL30ld5ACbCUaDSLun88eEAPpU5blni/mL1cmRoVozh9FwRM4/AbBl6yxvuoQ3
Gzw3+Ay+/ueV5mJKeqo1BZd1mdHNgdP3YH8FS8oC8HUtMI18dNZxVS+0nyFX/h8d
3KhUilIG6Po7Lz9Q3KnYMeyvyTd/uWGel2nZ5uSPY9t1rsNnUZgoSbgRX8lLJXzX
Ag1+f6cCE+GJD9aZFBRK4+Ydsz7vpESQD93ThHebmneKA6gA7NN036d31Y1FBF1T
AlZ/je0/glT5JNCKrz0Tnny8tkAkrS/eK0YQ8G7+XPe1uTaCQGMCwNdnfAIlnGnf
bqyoB65y05zaGT2Mqd+U8VMzr/BX4lRpMwnnfIKdQ33X4HvzfZJylE5CAaiRm/8T
gxcBbWjZvV5XUBGmGGFfbLjbHTrrgsknZ9zMSxT40YdqYX+x8SlkSfTKJXtGldVN
xvgNsgVC2dCb8lP6itWXAi1s8/OxUwN343y4EWSsmQGpdfNqazCER4hiczsms4Hr
n6h3/98iVrKCEdWrXXIBoVXuqUJNSfM6mfbYNy6BfkV7WtT//LK2Ct3oks4O3XHO
LF9BAUxLLs31H51lBJl6
=aEtu
-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: http://lists.debian.org/e1uvoad-0002z8...@franck.debian.org

Accepted libdist-zilla-plugin-git-perl 2.013-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 17:37:03 +0200
Source: libdist-zilla-plugin-git-perl
Binary: libdist-zilla-plugin-git-perl
Architecture: source all
Version: 2.013-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Alessandro Ghedini gh...@debian.org
Description: 
 libdist-zilla-plugin-git-perl - Dist::Zilla plugins to update your git 
repository after release
Changes: 
 libdist-zilla-plugin-git-perl (2.013-1) unstable; urgency=low
 .
   * New upstream release
Checksums-Sha1: 
 2edd1f675635d36ed1650eb59f1c90355ea095dc 2888 
libdist-zilla-plugin-git-perl_2.013-1.dsc
 7b21559e40dcbc661fd24d8bc946d83735c524c5 48791 
libdist-zilla-plugin-git-perl_2.013.orig.tar.gz
 32718250681393455e1d7d0e6f1a182872260f3a 3048 
libdist-zilla-plugin-git-perl_2.013-1.debian.tar.gz
 61d9f022d3ae573c2f6befcdad96a38a682973f2 58636 
libdist-zilla-plugin-git-perl_2.013-1_all.deb
Checksums-Sha256: 
 7986fa408a0ea0e7839d05c6adde56ca498c86f86aa70b63c8e6e3dfd1291116 2888 
libdist-zilla-plugin-git-perl_2.013-1.dsc
 ca3a25732cca3a7d0368f48bd7f2bad7f74803ac9468377dda87326ed266ea8c 48791 
libdist-zilla-plugin-git-perl_2.013.orig.tar.gz
 2d5a1495117ed544a181fb72237117e9250bf9f48376f37d5ab2e11bfe277ca9 3048 
libdist-zilla-plugin-git-perl_2.013-1.debian.tar.gz
 2a7b8aca6b97f85c84a47f135f8f539d1a8ffa5ff64dc8c83af273bd8e4f30f1 58636 
libdist-zilla-plugin-git-perl_2.013-1_all.deb
Files: 
 48be348b0c2cd162a385357e2ec13106 2888 perl optional 
libdist-zilla-plugin-git-perl_2.013-1.dsc
 b86ca469d2745302c5eca1be8a8c95ef 48791 perl optional 
libdist-zilla-plugin-git-perl_2.013.orig.tar.gz
 3a0b4e5b0da13d5e704ed743f156b6db 3048 perl optional 
libdist-zilla-plugin-git-perl_2.013-1.debian.tar.gz
 08a6dfa22adbb34548219df7509b8604 58636 perl optional 
libdist-zilla-plugin-git-perl_2.013-1_all.deb

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

iQIcBAEBAgAGBQJReU6LAAoJEK+lG9bN5XPLHtgQAJ7aa3PDHtTppASuCi3pVX/s
fglcoU4UXcaASPM6+M5BRROQ9tgz/saXsJxn6qQO2ACW/m6bNqCewxJhymF71HRy
CYadBtnh1Nna22fI0gjcAB+j7diA2K/UyjRU9BQ5Tzxg43m9ba/NZPQEqby/qDUs
d+VOro5DxP69Uxb5EenJUL4sfRZn/oxZg+D1/VBusUpVw99jO8Rz0FkQOP9lkW2P
3Gi3Dfb+cQYiTD4jbVz5OAzDEi6DIw8My7wvVDMHaF/9uRrAPpW0oqubVp8A+ioF
2ruK7e24ca0TFoBEwXlbZrdSOv3H2oAfBNShvbM2zHPkIMeufoFbloHa4gcagBWa
YrJ5ZGoy/eU+HJs1zMxWPJ7ED8S2C6IsGCY+DVO4xZnqlkG9QIUPZxH1s0l4uV0m
Arewj9AWP72jUT2MlPBLvMk8Ys6dTL8XSBRtysHB7zc3I6nshLKopwgilwtfDbaS
X2Ev1wdBoCk497U8mvlyieocGJe6EO/VzwIpmKnGvJnt1jttSf5k+3sN0zoc5kP6
3yPr0VpTAqiedCPV8y4orb1EVZfrCPmmk2MtYOyDl76uF8NZ3nz6cCCq5689jEin
d/q+37Rz7v8j9qhn36/CzkMJKmHQ8ybYhph0gLZJ/qXsts3e4ywrZQB1Kudeid86
VnOHDC3YDuMebzmSSBb7
=q1N7
-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: http://lists.debian.org/e1uvoow-0005v4...@franck.debian.org

Accepted live-build 3.0.3-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 17:39:31 +0200
Source: live-build
Binary: live-build live-build-cgi
Architecture: source all
Version: 3.0.3-1
Distribution: unstable
Urgency: low
Maintainer: Debian Live Project debian-l...@lists.debian.org
Changed-By: Daniel Baumann dan...@debian.org
Description: 
 live-build - Live System Build Scripts
 live-build-cgi - Live System Build Scripts (CGI frontend)
Changes: 
 live-build (3.0.3-1) unstable; urgency=low
 .
   * Updating debian-backports mirrors for wheezy.
   * Enabling release updates (formerly known as volatile) for wheezy.
Checksums-Sha1: 
 d65fb7a58b888944159db8a9168de48912b66def 1315 live-build_3.0.3-1.dsc
 33633977157db4e6c12d70866cc9c883df329d72 163224 live-build_3.0.3.orig.tar.xz
 bb9255c3dff39e0fdd68aa09ad133adaad7d785d 52144 live-build_3.0.3-1.debian.tar.xz
 773ba03024cca3ab9f82a96223830f202fe7ad8f 211714 live-build_3.0.3-1_all.deb
 f04319687992df61c1e3fc6407c13ac072141023 77064 live-build-cgi_3.0.3-1_all.deb
Checksums-Sha256: 
 1e4dda4733a806abdb5b4e63ca1924db7936dc8d6b4c7c1f181b3887df59aaac 1315 
live-build_3.0.3-1.dsc
 e57bade591d4c0e8c69fa089e8d7a863881cbad494c1be2054c7eb67a8a9b8a2 163224 
live-build_3.0.3.orig.tar.xz
 52434c69db62e0b35af49c14c7175ab6254e68fc66d89726641892d7d9ecc6ef 52144 
live-build_3.0.3-1.debian.tar.xz
 0069b101d7e4f7e63d8d60e078c58ca43c7cda98560099db58fa39b6581471b5 211714 
live-build_3.0.3-1_all.deb
 f193dd3fd0974b898a094691d984b9f3463279947867d09b57519343fe4975c1 77064 
live-build-cgi_3.0.3-1_all.deb
Files: 
 a05142e9edf4a9197bfc9f83e58c3b29 1315 misc optional live-build_3.0.3-1.dsc
 fc1f5f1c013aaa7bdd2cb9a34506064c 163224 misc optional 
live-build_3.0.3.orig.tar.xz
 5ee9aa500a19bc06ec5847bc2e29638d 52144 misc optional 
live-build_3.0.3-1.debian.tar.xz
 2ef0a8b3ab7683ed449f297431095ed8 211714 misc optional 
live-build_3.0.3-1_all.deb
 654b7ff7b29e7cf6d5cde38d79ff75ad 77064 misc optional 
live-build-cgi_3.0.3-1_all.deb

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

iEYEARECAAYFAlF5TssACgkQ+C5cwEsrK57rfACg1Bz7oQ84tYe0Jq6DaJm424lQ
oekAoK11LR4xn6n1hPb2tnUUkjxz2dpx
=zFiH
-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: http://lists.debian.org/e1uvooc-00061a...@franck.debian.org

Accepted dbus 1.7.2-1 (source amd64 all)

2013-04-25 Thread Simon McVittie

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Apr 2013 13:46:10 +0100
Source: dbus
Binary: dbus dbus-x11 libdbus-1-3 dbus-1-doc libdbus-1-dev dbus-1-dbg
Architecture: source amd64 all
Version: 1.7.2-1
Distribution: experimental
Urgency: low
Maintainer: Utopia Maintenance Team 
pkg-utopia-maintain...@lists.alioth.debian.org
Changed-By: Simon McVittie s...@debian.org
Description: 
 dbus   - simple interprocess messaging system (daemon and utilities)
 dbus-1-dbg - simple interprocess messaging system (debug symbols)
 dbus-1-doc - simple interprocess messaging system (documentation)
 dbus-x11   - simple interprocess messaging system (X11 deps)
 libdbus-1-3 - simple interprocess messaging system (library)
 libdbus-1-dev - simple interprocess messaging system (development headers)
Changes: 
 dbus (1.7.2-1) experimental; urgency=low
 .
   * New upstream development release
   * Do the debug build --with-valgrind on mipsel, too
Checksums-Sha1: 
 23f74c21ca2a63a86d8ec12278b75cd3ab453bcc 2574 dbus_1.7.2-1.dsc
 6e1828dded661183cd5e852d2f50d1e45c23dcff 1853734 dbus_1.7.2.orig.tar.gz
 fabb3d0fb38a3ff10ebd3db7891d1896d7539854 34923 dbus_1.7.2-1.debian.tar.gz
 dcf333e1d443b97974a67a5fe2831cf7d6ded698 403858 dbus_1.7.2-1_amd64.deb
 6b8ca6b2ee308e0dd5f6adfa05098ad9a3d8e4e6 61930 dbus-x11_1.7.2-1_amd64.deb
 7e6d1e0cc1092f6bffa69ce0410adfb7cce8f38e 175406 libdbus-1-3_1.7.2-1_amd64.deb
 ccc3668de8016d5dd84eec5d9afd0c1f7ebc 2411996 dbus-1-doc_1.7.2-1_all.deb
 fb3ea9af36cb575cc37624f104514f2b2199b49e 249244 libdbus-1-dev_1.7.2-1_amd64.deb
 4c52446ea000d745910f28d1b6a97b5d7bbe 8314302 dbus-1-dbg_1.7.2-1_amd64.deb
Checksums-Sha256: 
 fcf8020f4a6ce41ff51ee524078fcf350c9a65078d365de0a40422591157c27f 2574 
dbus_1.7.2-1.dsc
 212677cc01e63419ef6487e0b394fe3ddbc1e1131b4b3b137e500dd8ea9867d8 1853734 
dbus_1.7.2.orig.tar.gz
 96fd32ca807a6de365d493a673fee23f2c22c8916e28e28597c1f9a0f4535acc 34923 
dbus_1.7.2-1.debian.tar.gz
 e56d66b698d73fb4745abcea774ed0c70e91eb14aca0a88e81d54b2444ca5ebf 403858 
dbus_1.7.2-1_amd64.deb
 f0fd1445b45ae35405d6b03d9a6f359cfbdaad59419b13d58959e0ea662ecce2 61930 
dbus-x11_1.7.2-1_amd64.deb
 e818d594b3ebe3964482b80e0d5188eadcac43a5a231c551e19639e402d0c30e 175406 
libdbus-1-3_1.7.2-1_amd64.deb
 473bcec2d0ce66c145b9ec4c6cf090ae97b51a24513b9aa0209df12c86a83e0e 2411996 
dbus-1-doc_1.7.2-1_all.deb
 66ba55f9a3a603a46d55003c0601dbf3f69479472da83cfa00507b9f713211e8 249244 
libdbus-1-dev_1.7.2-1_amd64.deb
 382523d9d68be29a9c720190f54d8b501cf6c17dfb213264147c2b42c82a6c46 8314302 
dbus-1-dbg_1.7.2-1_amd64.deb
Files: 
 3fdf26249680fa9e76d7b01f4ed80778 2574 admin optional dbus_1.7.2-1.dsc
 72b38f1ee0b60d45fbb4d43a96ee3262 1853734 admin optional dbus_1.7.2.orig.tar.gz
 8cf33da53cd7c625da1865727e24f045 34923 admin optional 
dbus_1.7.2-1.debian.tar.gz
 a60bb7c49be6009a9905f370432e3040 403858 admin optional dbus_1.7.2-1_amd64.deb
 a5822e844861e441b4960bcf1d9fdb71 61930 x11 optional dbus-x11_1.7.2-1_amd64.deb
 078c0b231f8c90fca3db1dc5ee8da755 175406 libs optional 
libdbus-1-3_1.7.2-1_amd64.deb
 3ae3e2f71f810d77ad37c580a94e9383 2411996 doc optional 
dbus-1-doc_1.7.2-1_all.deb
 fcc81e74f370eed4e997e05beee8223e 249244 libdevel optional 
libdbus-1-dev_1.7.2-1_amd64.deb
 89def10dffea267260185a2be6ed7677 8314302 debug extra 
dbus-1-dbg_1.7.2-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIVAwUBUXlYKk3o/ypjx8yQAQj/UQ//dgpxppZckmUVTKyGwyNduUSfjdAWG0kA
AEjfz0WnXoXwRvGrI6G5JZ2H65r3uH5xWDNk2FiRO6dzFCShAkVmuhsM71dI/x9n
RZuBk3COrt1rfhkwcZ1ZzV4p5N9z4bVt1Am8A19zFhDPjP6q9YJbaJvN9qunCg+x
PKEQcuHjRazeUy17a/ZyWOcTrIi9TPUl47SA1ZQtCsNBfrbDMIp1R2SUBIoKuDAO
LNt2Q5jbaaySc/PiHD5ycVfCrOGTO/zngy8q1GkeVotDdnnKHeS+iJrx9iEXBBSQ
e/+WZqJ4PPQaW+UNme+4NuDnCaSMBL+8j7Rd1z7kN/cPK4U40Stj336/obpKibnO
5cnGRZS3PgpLRzqWR9VRYBk2gNzByfHJy8ZCF5HtS4vj6TX7y2atfgZXO81pDGDN
44PkS/kHJ5yKJ0vTo93adT/cO3KB2P2KHmPe5eUIXynVNHAwECCBsQKQ2jqVhKJB
hvtb+JvqtMzpZA2VDaZUe9sBdPhPM3G1LBwNFg069+wYP1cDQTVLLuHTiGl44Cgw
YdtqrdoRFh4qozPn8QmK2qfyIyNyYDo2AVQ7+4JZXWJ8ROZfu1noOQlXzStFysUU
wq65Nw40cKLPAKMw6LsEWVohVkPD2VUKJ4+EVuEMIJx+9hIiM7pLLaMBj4oQRbwW
VcMYwLnsMUA=
=OTv6
-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: http://lists.debian.org/e1uvp67-tp...@franck.debian.org

Accepted matlab2tikz 0.3.3-1 (source all)

2013-04-25 Thread Sébastien Villemot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Apr 2013 18:25:06 +0200
Source: matlab2tikz
Binary: matlab2tikz
Architecture: source all
Version: 0.3.3-1
Distribution: unstable
Urgency: low
Maintainer: Debian Octave Group pkg-octave-de...@lists.alioth.debian.org
Changed-By: Sébastien Villemot sebast...@debian.org
Description: 
 matlab2tikz - converter of Octave plots to TikZ figures (for integration into L
Changes: 
 matlab2tikz (0.3.3-1) unstable; urgency=low
 .
   * Imported Upstream version 0.3.3
   * debian/copyright: reflect upstream changes
Checksums-Sha1: 
 d78bc2fb68d67b2012f8ab3a9a86aabcbeeed978 1941 matlab2tikz_0.3.3-1.dsc
 eb0a0991d34543e133256a17c6fc6f96112c8c5a 123583 matlab2tikz_0.3.3.orig.tar.gz
 8861555c58a3408613b40e92b69fe2f9463269e3 3187 matlab2tikz_0.3.3-1.debian.tar.gz
 bf56626c261f93278be31e81d6ec25c8c633726b 90896 matlab2tikz_0.3.3-1_all.deb
Checksums-Sha256: 
 09cb20acc16a1ba6a58108d3ee6e5fa140968163385150c66862783625c63dd6 1941 
matlab2tikz_0.3.3-1.dsc
 d470f50b0016a326596b68dac20e187eccd88b51a89746915b0e9bd4a1c349da 123583 
matlab2tikz_0.3.3.orig.tar.gz
 df0becd23e45e89a5f5357bd115e81e1c0a3c98a13f9bf419674f525cbbdfcd6 3187 
matlab2tikz_0.3.3-1.debian.tar.gz
 6496039d5ab1b0e558be614785c05bd6bf55ac832028c757944e67e137428029 90896 
matlab2tikz_0.3.3-1_all.deb
Files: 
 5a1f7abb1fd523da7263b307a4381385 1941 math extra matlab2tikz_0.3.3-1.dsc
 9c097b9983ec8f09478520bdfe063a93 123583 math extra 
matlab2tikz_0.3.3.orig.tar.gz
 1326d9a089e583e8b3b53f4ca859e066 3187 math extra 
matlab2tikz_0.3.3-1.debian.tar.gz
 74c95132e1226240cb40ff917d046ca2 90896 math extra matlab2tikz_0.3.3-1_all.deb

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

iQIcBAEBCAAGBQJReVlnAAoJECzs6TUOzr5KiHMQAJCInGNVRWiMLAC4r86KClD1
fZiW45nU50fX3UsLQMUoINMZNHW60w3DYu4cUs2Xe7ak0ezmnz7DN6hotmL8yxRb
2YlgP3zz9exNrvCCtcbLpUFVkh4q6CB0KARu0ua61IAqL1IbupEZonTj7YcfV8nJ
jkPFTe/VvCG8XLRwqZiW2vM9UXpVxdnVtcMb6wkjxgDc45UzG0K0mBknI6lRjZRq
glJ6oJQgsX+DTLvVHXZUJbqjIayCGN9Sl2Bv53bc8yTRDprPT3QMq8w4r12N1HkG
KGNYNrScnvEMIZHnK1Z8m/mxnTJ/p/y4T/GvLSNKHAqcmQ/oH2VjPbM0em5Aceq8
/FCXIW8gy2/UTNPG3vNY+AaogveTlCTHdKo1VtMSFo7AoYXIEIiwuyqsJQvGiuru
lgNZYPBWwiJcsegjxczpwzGmlQIj3EnKNT5n80gX/0zm6hgUcDIOB9u7mKARtRlg
bKFj/4rCpAq5np+AWkiuWPZpS4czsFmHhFue6BG8IAieALRC58HXvI5E53/S9fgD
M190Uwza4R346t9L+uS4VwtC4TmbtJcXfWY4iTpNEsQ2SM3rhtgr/4azjaRQ1mrw
J5YWvHk8mC8zsjy0BuH/qcxDiUizKEbUqrzz7CLALALueV7+ZNmqAp2W/cvvgkF+
9+9Z2+GHNl4wOo2fb2Aw
=4A6P
-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: http://lists.debian.org/e1uvp6c-wt...@franck.debian.org

Accepted live-config 3.0.23-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 19:18:33 +0200
Source: live-config
Binary: live-config live-config-doc live-config-systemd live-config-sysvinit 
live-config-upstart
Architecture: source all
Version: 3.0.23-1
Distribution: unstable
Urgency: low
Maintainer: Debian Live Project debian-l...@lists.debian.org
Changed-By: Daniel Baumann dan...@debian.org
Description: 
 live-config - Live System Configuration Scripts
 live-config-doc - Live System Configuration Scripts (documentation)
 live-config-systemd - Live System Configuration Scripts (systemd backend)
 live-config-sysvinit - Live System Configuration Scripts (sysvinit backend)
 live-config-upstart - Live System Configuration Scripts (upstart backend)
Changes: 
 live-config (3.0.23-1) unstable; urgency=low
 .
   * Loading fglrx module with --ignore-install like the nvidia ones too.
   * Making module loading for fglrx and nvidia not fail.
Checksums-Sha1: 
 88582c54897c45874ce679a57a4be2a4167f2808 1547 live-config_3.0.23-1.dsc
 339121c1e0066c3df024ad1c8b70fa2f160b8fe5 64732 live-config_3.0.23.orig.tar.xz
 94f19d9eac2d5219901b895e615b22476ef649e5 13740 
live-config_3.0.23-1.debian.tar.xz
 e3410421835f619a3b0038851563abd1977a8e6f 27222 live-config_3.0.23-1_all.deb
 239d590288f77c23990e8502922f8439d11d7921 50898 live-config-doc_3.0.23-1_all.deb
 7276c864a3270a3fce5f5e59d467828410f2dd6f 14784 
live-config-systemd_3.0.23-1_all.deb
 cf42032f3a053c191b0daa3ecdf4ede9b5449170 15938 
live-config-sysvinit_3.0.23-1_all.deb
 5521f446dfe1f96301813017980b81095a1b4974 15578 
live-config-upstart_3.0.23-1_all.deb
Checksums-Sha256: 
 d443de2f73ed4a2e3bc18a8fa46f15cde95fb8a1168f3101ef0328bdc34cbfa9 1547 
live-config_3.0.23-1.dsc
 3486474b081477aada3d519683fd20ccb65fb7e3b67a5873113f14ac6d433da2 64732 
live-config_3.0.23.orig.tar.xz
 10f1a3ae4755351462a0f83925e5c1e27d85a2292ba7a5cac033d1cb58ac20b7 13740 
live-config_3.0.23-1.debian.tar.xz
 1e1ff8fb8636950b0e67a36c09b53d486c6b049866f0721e2785963ef5607723 27222 
live-config_3.0.23-1_all.deb
 53b46bdedb3b7b6a02071f663d6353f71bfcd9b9c76e35fc357b3a0afbdf2f88 50898 
live-config-doc_3.0.23-1_all.deb
 ab05fce6e2f0158053b5dfd3f33c413150a49deea8472499940867ae24e33451 14784 
live-config-systemd_3.0.23-1_all.deb
 89a4ab42f259deacf3cfb9ef4000a580942f34ff75824ae406d632448f1e1a02 15938 
live-config-sysvinit_3.0.23-1_all.deb
 dbcf521f80c7a7123bb2cfdafed83f69cd3a1e17d833b792102bb2e39d69308d 15578 
live-config-upstart_3.0.23-1_all.deb
Files: 
 c29ae1e3763bb227d6c45f157814adbb 1547 misc optional live-config_3.0.23-1.dsc
 4815ff0bd5a6d7a5cd6914b9038ac8aa 64732 misc optional 
live-config_3.0.23.orig.tar.xz
 fcc77a41d2cfcfcdc3123f1f1b2ab116 13740 misc optional 
live-config_3.0.23-1.debian.tar.xz
 bc5a4103f722966fcf24d3d56f005578 27222 misc optional 
live-config_3.0.23-1_all.deb
 fabf71a7e86f361397d5c6d179e4b465 50898 doc optional 
live-config-doc_3.0.23-1_all.deb
 67d7fce6075e747a20e7695298bc5b66 14784 misc optional 
live-config-systemd_3.0.23-1_all.deb
 0064a8cc6a3d41bff39a259707a12715 15938 misc optional 
live-config-sysvinit_3.0.23-1_all.deb
 1bfa36dce1a7e0551676fe25a6d96a84 15578 misc optional 
live-config-upstart_3.0.23-1_all.deb

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

iEYEARECAAYFAlF5amUACgkQ+C5cwEsrK54ETgCgpRGJfGplp3wVY8GeexHh1aYz
kDoAoNcN1GC8TFtCjWqxtDLSG+i7QvIJ
=FSz3
-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: http://lists.debian.org/e1uvqgi-0007bq...@franck.debian.org

Accepted rsyslog 7.3.12-2 (source amd64 all)

2013-04-25 Thread Michael Biebl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Apr 2013 23:44:03 +0200
Source: rsyslog
Binary: rsyslog rsyslog-doc rsyslog-mysql rsyslog-pgsql rsyslog-mongodb 
rsyslog-gssapi rsyslog-gnutls rsyslog-relp
Architecture: source amd64 all
Version: 7.3.12-2
Distribution: experimental
Urgency: low
Maintainer: Michael Biebl bi...@debian.org
Changed-By: Michael Biebl bi...@debian.org
Description: 
 rsyslog- reliable system and kernel logging daemon
 rsyslog-doc - documentation for rsyslog
 rsyslog-gnutls - TLS protocol support for rsyslog
 rsyslog-gssapi - GSSAPI authentication and encryption support for rsyslog
 rsyslog-mongodb - MongoDB output plugin for rsyslog
 rsyslog-mysql - MySQL output plugin for rsyslog
 rsyslog-pgsql - PostgreSQL output plugin for rsyslog
 rsyslog-relp - RELP protocol support for rsyslog
Changes: 
 rsyslog (7.3.12-2) experimental; urgency=low
 .
   * Fix build when libgcrypt support is disabled to not pick up an unnecessary
 libgcrypt dependency.
Checksums-Sha1: 
 3d4d4074c03fa6c6293467f49bfd6edd6b4c878d 2436 rsyslog_7.3.12-2.dsc
 e4d816ba86f011215b3e9697df540bfd15faf494 30272 rsyslog_7.3.12-2.debian.tar.gz
 83768ac394d05a03159685d3401118f4b28da3cd 702122 rsyslog_7.3.12-2_amd64.deb
 87f34a68d7f9de588d2e27dea8adc2997cdabadd 1197068 rsyslog-doc_7.3.12-2_all.deb
 974a25b4e96085d24478008eb7a567788944c2ac 146094 
rsyslog-mysql_7.3.12-2_amd64.deb
 0fd0083aef26c0be5c927ab1fd1b6e743021b4d2 144366 
rsyslog-pgsql_7.3.12-2_amd64.deb
 76eced1f37706d660946880021f52d0ef54b6d43 146370 
rsyslog-mongodb_7.3.12-2_amd64.deb
 7496add9b544dd274018e9c162238507bd06920f 152506 
rsyslog-gssapi_7.3.12-2_amd64.deb
 58522756026413116bb882104e1fadc14f722f4b 151342 
rsyslog-gnutls_7.3.12-2_amd64.deb
 9fc4a54d967b6b6d7128f206c5c4385772956bf8 147588 rsyslog-relp_7.3.12-2_amd64.deb
Checksums-Sha256: 
 597b072a24928ad5ad85211aa39c49fecbe483eb3968f5b0d0e22ed30a1b0457 2436 
rsyslog_7.3.12-2.dsc
 270b1eb905ad3837cdd67e3c4e99e627794a3d63e44c733d1d9f831d647d58cb 30272 
rsyslog_7.3.12-2.debian.tar.gz
 a4a0819820bca91d35ed55c52f2321951646e3d6e4e65e0f2182bb06dfa954da 702122 
rsyslog_7.3.12-2_amd64.deb
 32b4b05de0923aa530e97e62b0404997d5f7ae64ff24bd39186c119d1b433771 1197068 
rsyslog-doc_7.3.12-2_all.deb
 76757348d61fc08a6bf72fdd9872d08c5f36f10d587818e99f942ad9829fa3fe 146094 
rsyslog-mysql_7.3.12-2_amd64.deb
 d30b74631255f238cb82e6b9e3b65f6c268953072501719fa80eba924473de64 144366 
rsyslog-pgsql_7.3.12-2_amd64.deb
 fa5135131419228ff0c8ca0e6ec2af8c8a4361bc07d2f7273040239109a0ceba 146370 
rsyslog-mongodb_7.3.12-2_amd64.deb
 1b72a7da00c8f643404ff2b2f94ccfb6e86f64d3b0673a61eb723ac609c01e80 152506 
rsyslog-gssapi_7.3.12-2_amd64.deb
 630ecb80735ea8cf958c403c933486a04f310f5cf1c7698dcca70ae6312717d7 151342 
rsyslog-gnutls_7.3.12-2_amd64.deb
 c9cbe362c226f25f6f7cf6194dce6abe38bf52742bdfa2fb4b659b2ace4b80e9 147588 
rsyslog-relp_7.3.12-2_amd64.deb
Files: 
 d27f40626e93f3da78db1936f6b58f26 2436 admin important rsyslog_7.3.12-2.dsc
 1ff9fc50bf50e691a31592eb494ab666 30272 admin important 
rsyslog_7.3.12-2.debian.tar.gz
 f42631cc546a03f7795c6fcaef8d585d 702122 admin important 
rsyslog_7.3.12-2_amd64.deb
 40a67c32494c3bb44c5246e3e07ec3a7 1197068 doc extra rsyslog-doc_7.3.12-2_all.deb
 f30c792ba87fdf1ef974f422576b842a 146094 admin extra 
rsyslog-mysql_7.3.12-2_amd64.deb
 419b172fd08de89db65c3d14f909b3a7 144366 admin extra 
rsyslog-pgsql_7.3.12-2_amd64.deb
 244bfa41ca3b5bced0eed12b52a1b855 146370 admin extra 
rsyslog-mongodb_7.3.12-2_amd64.deb
 b8cfd52946f686d059a47d92750ccc94 152506 admin extra 
rsyslog-gssapi_7.3.12-2_amd64.deb
 7658818a91765298d4bd0a82d15584d4 151342 admin extra 
rsyslog-gnutls_7.3.12-2_amd64.deb
 7a4c9a69ff7b169cd078666b8dea6152 147588 admin extra 
rsyslog-relp_7.3.12-2_amd64.deb

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

iQIcBAEBCAAGBQJReaU2AAoJEGrh3w1gjyLcpT8QAJqidrmjm4r151nf/jBYYs8Z
DlyeluThlSDuAiLgoT5kqybbh1HwHhbEtnjRaNFv+mfFIY3gcudMiOdouSgQs15b
vJngDwn0gsgFKIarBglOqn3JaORx/ebKx+bAUq4rZ8o4XFxlocFzh9jlCgotiNkR
KWJODFaPHDvXAf2aVrW44QFfnlDilZMLntq1jxrLBncSNSXKbTx8V1+wnSG1CofX
0II14FZlrbFY3Zlq+7TZbtUEOvZXPVrsyD4pwemfBHN2Rtj6T+K1Wii1b7Z2vUbC
A78CvX7EhdqpUbpqaM0xYHKxE5aLQf8NHDBiDUlqAG3kj3tU5XpZMNa1P1a8Jamn
RVQWkypa++wPGCXiJn1+3lqkkblCLAN+JodJw6sjWI4p3cjDmqq0Uez25SBvHP1C
YT9q3omzOt9dRB24Bqc41uG1QK71Rlq2lTCO2wX6YGF0sWMgPC6mCDU3mhIsuTGX
DRMyQmUB693FDyKvgYIK/BNMFdHQy4mXTjFqyRihX5A2NDX/kxA9aXtUpEk2E6Hv
1DnpCdLBlN6UzwPrf1wxeEsqhSFn2O21ZON00UL2LJX8Q1p58SYG/xcUcdgavPYt
jt1MY/xu9p5uXWsrv1K4NS779bhyWfZvujhYpy2BAYAt4x3vJNKdw3CResvYab0e
xD1jPmoC8XqGhxpkXin6
=2E3w
-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: http://lists.debian.org/e1uvufz-0001fj...@franck.debian.org

Accepted libdist-zilla-perl 4.300034-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 26 Apr 2013 00:20:37 +0200
Source: libdist-zilla-perl
Binary: libdist-zilla-perl
Architecture: source all
Version: 4.300034-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org
Changed-By: Alessandro Ghedini gh...@debian.org
Description: 
 libdist-zilla-perl - Perl distribution builder
Changes: 
 libdist-zilla-perl (4.300034-1) unstable; urgency=low
 .
   * New upstream release
   * Add versioned (Build-)Depends on libcpan-uploader-perl
Checksums-Sha1: 
 3df24dc27cf6ffa8207a312d4fd6a4a62b71fb73 3619 libdist-zilla-perl_4.300034-1.dsc
 060a6433db7b593cc84817016190535fac60bfbd 138519 
libdist-zilla-perl_4.300034.orig.tar.gz
 1036ab2cd9150fb1478229793329a2c5a475861d 5873 
libdist-zilla-perl_4.300034-1.debian.tar.gz
 1053b0fcdd96c5da5ad00524d0f241b0d7929b6c 396002 
libdist-zilla-perl_4.300034-1_all.deb
Checksums-Sha256: 
 ebac00f8fb206b3d43f0465c766c2b9a09700281d0c4f11c467b215fda5a99ff 3619 
libdist-zilla-perl_4.300034-1.dsc
 ef8880083613438ebf83b8a2221d80a623c0fbd0897e32ffb750cf851e7ed579 138519 
libdist-zilla-perl_4.300034.orig.tar.gz
 cc3cddd49b338a097627b131ffadc42ad507a1b8aa64e789de5b2ce53a857b6b 5873 
libdist-zilla-perl_4.300034-1.debian.tar.gz
 50d950eb95d9c4dd625a5e5c996d4195ef9dc73587535ee45b81a99ed1d6abc8 396002 
libdist-zilla-perl_4.300034-1_all.deb
Files: 
 e652a5f3757882fd12c13fddc1c2164a 3619 perl optional 
libdist-zilla-perl_4.300034-1.dsc
 80c96dcb5c70884d73ba2d1e50e88920 138519 perl optional 
libdist-zilla-perl_4.300034.orig.tar.gz
 fa58f449f660b10eb439ae5262a6cb72 5873 perl optional 
libdist-zilla-perl_4.300034-1.debian.tar.gz
 ed9eecfa5d29e429cfb3b73c6eda4dda 396002 perl optional 
libdist-zilla-perl_4.300034-1_all.deb

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

iQIcBAEBAgAGBQJRea37AAoJEK+lG9bN5XPLds0P/2EWqoGoqPrjCmvkVsRdMLXh
jui7Bww6fuLT2B/4e0t1OsyywSw97fdpU5IKRs4Ls1ktgWC/SMSVbFH6CScoBE2r
wPEDGYL7yRBAlfeXeP4NmQwVVssfKwY1ve7GHk3qrVUSxYfFN0arp5UTSNHKKanT
vWwMKTCwGa+VBWKMViy3A+9myzpPsT56i6tL88LsPjyAPJoB8ezLTLUZEWd66wBr
ub05+m0gWeYwXDMnPujiI4W56CX0UJwv++hn/N5VvpvKULiZ7yE9klJQrYwn/rw1
LiqNbp1zCPgQjNrIB0hr4Nctb0Tnt/FkT0iFbgRSRjiPLppGYAaEbHzdAA3j4ZJ4
v4bVrHoIBBZTIqT/PVIhOIbJdq9a//Jh7HjXyF7uj8h3DtUMVO7WA1mlzk+nRkhy
DsK2JdWWV85GuIjx9F1QZOXv5/084zfWReG74R7Q8JN+szzqMbIVnD7KwaJOGd8c
w7zS2ZiF5dLsNvuXIaNEvet1+BCq9kvVkaW94cqtem3c8iO0N88FRQ5PvrWfxpeE
CVAcn5u/+WrEbZPyCBbfROMK8ioPcdF5blLwL/f97rAr4k1Lo3EMO0/eJjW8I0iV
TY9yDM8lVh+RHrbsAd8vB8F9kUNvFhsM69zaGV+gTl8BpdiGH74KxvihW6WbhIZo
4CIshApVQqwyl/qpkpNO
=rC9j
-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: http://lists.debian.org/e1uvuip-0001oz...@franck.debian.org

Accepted pisg 0.73-1 (source all)

2013-04-25 Thread Julien Danjou

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 22:51:47 +0200
Source: pisg
Binary: pisg
Architecture: source all
Version: 0.73-1
Distribution: unstable
Urgency: low
Maintainer: Julien Danjou a...@debian.org
Changed-By: Julien Danjou a...@debian.org
Description: 
 pisg   - Perl IRC Statistics Generator
Changes: 
 pisg (0.73-1) unstable; urgency=low
 .
   * New upstream release
   * Bump standards version
   * Fix license file reference in copyright file
Checksums-Sha1: 
 c47d6705265200658eb32216a4aff1ff9686dae2 1639 pisg_0.73-1.dsc
 49995094e05c339a720985ef6efa271aa41c8afb 236539 pisg_0.73.orig.tar.gz
 c06a0154692ca99e37c135480427a7101ba05b86 2747 pisg_0.73-1.diff.gz
 ba479f3f32c2d6d4d8c18c505088c69621581659 224338 pisg_0.73-1_all.deb
Checksums-Sha256: 
 57eff87a38ded985c0ce6435b658025b9c2e7eaf1ec7da1dc6a4ed03e78d4bed 1639 
pisg_0.73-1.dsc
 979efdd489114c10360dff9c7c8fdc287c126508e65790dfd0d0aa6fdf7d7c3b 236539 
pisg_0.73.orig.tar.gz
 4133626726a3f551b86b08a94d2329fa998679205c122c8738db1f5b23399509 2747 
pisg_0.73-1.diff.gz
 1db29346bd41ce82252a1adb7104096afcd426058daba281ed78dc219a2f0c9d 224338 
pisg_0.73-1_all.deb
Files: 
 e38939fa9d809ef201780fdc82b8d27b 1639 net optional pisg_0.73-1.dsc
 e0d43082c0bc20e19978743ebf2fcf8b 236539 net optional pisg_0.73.orig.tar.gz
 73ccc8638a5d2255df957d87de0c900a 2747 net optional pisg_0.73-1.diff.gz
 5b321b673259c5d3fe96e96d6c222b43 224338 net optional pisg_0.73-1_all.deb

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

iQIcBAEBAgAGBQJReZ/tAAoJEGEbqVCLeKXCKqQQAIyeU9PzdbHHnJ1NOKMElDn3
uDp6UyCVXB3q4+B4J6bLv6m3PSX0Wvde2sTV4nMJmmSspO9d9GYxTeVcGZubpyn0
Vt+JDKIxEFZJCMuE34q0jc+N544If/5Y69luhYNo6KH+lIj3HrihEbtOng/0iPXM
3w1cs79BHpBUB7+gfWwe+EECMWCmMxhTk8NG8O180dxPEjmOJUGWlieRX4ZaaQiE
wTvVYTz8WnEIVla3SnNHoykA3lj4S9JGEmJjXbR/Tnmgwz3hC5y9ht73tucQd1Wn
BdHdkThBWv6I3JDvlHvrT52QXqWU186V4w0r6gXDpAc/BaUHfmNY4i//dMDS7fV4
5fnhpqELYtgslQw+413AAA4c/atOINIuLXm9EN4Eau6ev82y1Y8nFfoOygP553gI
AL3JrSHUqOsmecN2rsDty2LFyAiemFlQEG+FGmkzLf9tFhHe0se7gFed8H1lZ78m
+kYRoy6rL3hIt9J/rQI7dgSaqnTAAOSnWqjrL6sec+XTrB91/YvyHQH4VmiLKklz
wVjO2s5JiLcfTaIA34Br+Pk1BRzX7IAek7iijHtdA3mrPE5cuEvnzPHBMWnSPl+W
9gycIR71NRTM5DgOnv8IwXoxy5Tj7gkBup7HayF+11UyIz+Xs4AQcx5v2VxNkUom
dOr8s/v6UukInF/8exUD
=lZxU
-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: http://lists.debian.org/e1uvuwt-00080p...@franck.debian.org

Accepted libgd2 2.1.0~alpha~4+cf9d7f-1 (source amd64 all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Apr 2013 12:17:06 +0200
Source: libgd2
Binary: libgd-tools libgd2-dev libgd2-3 libgd2-xpm-dev libgd2-noxpm-dev
Architecture: source amd64 all
Version: 2.1.0~alpha~4+cf9d7f-1
Distribution: experimental
Urgency: low
Maintainer: GD team pkg-gd-de...@lists.alioth.debian.org
Changed-By: Ondřej Surý ond...@debian.org
Description: 
 libgd-tools - GD command line tools and example code
 libgd2-3   - GD Graphics Library version 2
 libgd2-dev - GD Graphics Library version 2 (development version)
 libgd2-noxpm-dev - Description: GD Graphics Library version 2 (transitional 
package)
 libgd2-xpm-dev - Description: GD Graphics Library version 2 (transitional 
package)
Changes: 
 libgd2 (2.1.0~alpha~4+cf9d7f-1) experimental; urgency=low
 .
   * Imported Upstream version 2.1.0~alpha~3
   * Imported Upstream version 2.1.0~alpha~4+cf9d7f
   * Disable jpeg_read test which is broken with libjpeg8
   * Add couple of new symbols and remove gdImageAntialias, that didn't
 make it to 2.1.0; add Breaks: php5 ( 5.5.0~beta4)
Checksums-Sha1: 
 54af89f69ddd524d4b8fcb00bb60a6a72e91c118 1773 libgd2_2.1.0~alpha~4+cf9d7f-1.dsc
 464a8aaff1f353ad931c4d39908f38ae6a6fdecc 1314972 
libgd2_2.1.0~alpha~4+cf9d7f.orig.tar.xz
 8e0dc625cdc26c14c1c79707685b224a73322a33 23415 
libgd2_2.1.0~alpha~4+cf9d7f-1.debian.tar.gz
 cc4ef9fd09ec1b6a1085a59101fb3db99bb9fb01 45490 
libgd-tools_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 3a4aa4e28e239dc329d37eb05ea40440f3c878da 321430 
libgd2-dev_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 b9186413d87a734ba840db52b67cde9d1c8e8c01 171554 
libgd2-3_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 2ebefba8368c86aefd6c46c68bdd28bb87511e02 816 
libgd2-xpm-dev_2.1.0~alpha~4+cf9d7f-1_all.deb
 09ca917e96714c2380dffe7de3fa11d74e8b1b30 816 
libgd2-noxpm-dev_2.1.0~alpha~4+cf9d7f-1_all.deb
Checksums-Sha256: 
 5f42b39dc6f9e78351052f1beef4d382a483ded0bfb8ddb65d235c37a188fc84 1773 
libgd2_2.1.0~alpha~4+cf9d7f-1.dsc
 dadb550c5de96866606670de531a6c6019c2ebfafd13fe9e8a38641e16c3cd39 1314972 
libgd2_2.1.0~alpha~4+cf9d7f.orig.tar.xz
 1725d82954f19e381e8375bccde37547051c03d9b4099d0209a0212655bcf77a 23415 
libgd2_2.1.0~alpha~4+cf9d7f-1.debian.tar.gz
 adcdf5a080ee9102e0e9975ddc86477586c5887047c6c5e2da9792455a3d1979 45490 
libgd-tools_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 55a178c88c897101990a482bb9f98c41e3ef78438cef7082c399d782e83a82ad 321430 
libgd2-dev_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 3f1bdcaa865994c8db01ea2d2cd962327996ed76fffdd4577ae464dc4cb68a67 171554 
libgd2-3_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 774d680eff671f6a28bf25517225d7183270f5125f9b9593df1410c1748fa63a 816 
libgd2-xpm-dev_2.1.0~alpha~4+cf9d7f-1_all.deb
 bb046d934911896905bf9359acbc8e72e97404c67f927fea99166bc047018b5b 816 
libgd2-noxpm-dev_2.1.0~alpha~4+cf9d7f-1_all.deb
Files: 
 1821e0934e511224991c0e7081995b6f 1773 graphics optional 
libgd2_2.1.0~alpha~4+cf9d7f-1.dsc
 40809fe1a9a6a664b39701efdf1807bf 1314972 graphics optional 
libgd2_2.1.0~alpha~4+cf9d7f.orig.tar.xz
 e1a4486a2692c116b5ebd77b2d7571e6 23415 graphics optional 
libgd2_2.1.0~alpha~4+cf9d7f-1.debian.tar.gz
 c21745eb8408060c9685031f7fd442bc 45490 graphics optional 
libgd-tools_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 53d82a5c489271c4a56ba9cbddbbfdb3 321430 libdevel optional 
libgd2-dev_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 b4222cf2448db47498ceefd7d6ddcc98 171554 libs optional 
libgd2-3_2.1.0~alpha~4+cf9d7f-1_amd64.deb
 3af62bf52b5c804a60f4d42817172c58 816 oldlibs extra 
libgd2-xpm-dev_2.1.0~alpha~4+cf9d7f-1_all.deb
 5cab8e0af1bbb465241a0039b1ec1f71 816 oldlibs extra 
libgd2-noxpm-dev_2.1.0~alpha~4+cf9d7f-1_all.deb

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

iEYEARECAAYFAlF5tykACgkQ9OZqfMIN8nOy1gCeKEd/dnFzNZpXRMgrTh/YQO/0
Nx4An0MVZl81G9Id3FtU8tgC1Jt3NpkO
=dj3a
-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: http://lists.debian.org/e1uvvq0-0006on...@franck.debian.org

Accepted php5 5.5.0~beta4-1 (source amd64 all)