date:20131029

Thorsten,

On Mon, Oct 28, 2013 at 05:23:33PM +, Thorsten Glaser wrote:
 Lucas Nussbaum leader at debian.org writes:

  I think that it would be a failure of the Debian project if we had to
  have a GR about such a technical decision.  I think that we need to
  trust that the Technical Committee will make the right decision.  A GR
  about this will likely result in splitting and hurting the project even
  more.

 In my perception, it’s the other way round: a CTTE decision will be
 seen as dictated from a small group, and the possible conflict of
 interest has been raised, no matter whether it indeed matters in
 the CTTE decision or not, people are saying it’s fishy.

There is a lot of indirection in your message here: will be seen, some
people.  You don't say that *you* mistrust the Technical Committee's
decision on this issue.  If you do, please come out and say so directly.

As it stands, I don't find your argument here very compelling at all.  Yes,
there will be some people who criticize the TC decision as being that of a
small cabal; but how many of the people levelling that criticism are
actually Debian deveolpers?

I don't think you were around in the years immediately after the
constitutional bugfixing that enabled Debian to start having GRs again after
a long hiatus, but I was.  The experience of that time convinced me more
than anything else that direct democracy is a very poor system of government
for an organization of any size, because it wastes a lot of people's time
and causes a lot of anguish over issues that at the end of the day are not
very important.  GRs on controversial subjects are not healthy for the
project, and we should not go out of our way to pull the trigger on GRs if
we don't have to.

The decisions of the Technical Committee are always subject to review by the
developers at large via the GR process.  If a sufficient number of
developers disagree sufficiently strongly with the decision of the Technical
Committee that they wish to raise a GR, it is always their prerogative to do
so.  But even if this happens, it is a much better process for Debian as a
whole to let the TC do its work first, evolve the pro/con arguments in a
small group, and then present their conclusion to the project rather than to
have all developers immediately pile on and tackle the question directly
from scratch.  In the common case, everyone is reasonably happy with the
TC's conclusion and there's no further need to spend time on a controversial
project-wide discussion.  In the exceptional case, some group of developers
disagree strongly enough with the outcome, and think the majority may
support them, that they will submit a GR to overturn the decision - but in
that case they have specific technical discussions from the TC that they can
refer to instead of having to start the discussion from scratch.  Either
way, it's much less of a time sink for Debian developers as a whole to let
the TC do the hard work first while the rest of the project can continue
being productive elsewhere.

 (Also, do remember that any decisive outcome other than “support
 multiple ones including systemd” and “systemd-only” will need to
 lead to the removal of GNOME from Debian.

Absolutely not true.  As Tollef mentions in his follow-up, one of the
options is to fork logind and maintain it.

This is not an improbable outcome.  Logind is a good interface, and there's
a lot of value in continuing to use it, regardless of what init system we
choose.  If Debian chooses to ship upstart as the default, I will almost
certainly be inteested in making sure that logind continues to be
well-supported on top of upstart, in both Debian and Ubuntu.  The work to do
this on Ubuntu has so far been straightforward; while there are some
technical hurdles in the future for making logind continue to work on
non-systemd systems, these are known issues and not at all insurmountable.

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


signature.asc
Description: Digital signature

Re: Proposal: let’s have a GR about the init system

2013-10-29 Thread Svante Signell

On Fri, 2013-10-25 at 23:45 +0800, Thomas Goirand wrote:

 OpenRC has been waiting in the NEW queue (targeting experimental, as
 this is what it is right now: experimental!) for more than a month. It'd
 be nice if someone from the FTP master team could review it, so that at
 least others can try it. As much as I can tell, it works, though I'm
 sure there's a lot of problems that I didn't see, and having it exposed
 would help (so that others can fill bug reports).

Triggered by the good news about OpenRC for GNU/kFreeBSD
http://lists.debian.org/debian-devel/2013/10/msg00991.html
I would like to try to build it also for GNU/Hurd, save the PATH_MAX
stuff. Where is it? It is not in http://ftp-master.debian.org/new.html


-- 
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/1383033433.9990.5.ca...@g3620.my.own.domain

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Lucas Nussbaum

On 28/10/13 at 18:21 -0700, Russ Allbery wrote:
 Wouter Verhelst wou...@master.debian.org writes:
 
  Also, since all alternative init implementations under consideration do
  support sysv-style init scripts, I think that whatever init system we
  (well, you, the TC) end up choosing, the requirement in policy should be
  that a package should ship either some init configuration for the
  default init system, or a sysv-style init script. In fact, I think we
  should continue to encourage the latter, in cases where it does make
  sense (e.g., when a given daemon doesn't have any init system specific
  features that could be enabled), since that will help our non-Linux
  ports without significantly impacting performance of the new init
  system.
 
 Well, I've said this before, but I think it's worth reiterating.  Either
 upstart or systemd configurations are *radically better* than init scripts
 on basically every axis.  They're more robust, more maintainable, easier
 for the local administrator to fix and revise, better on package upgrades,
 support new capabilities, etc.
 
 I believe that much of the benefit for adopting a new init system is
 dropping init scripts and using a much better configuration language.  If
 we're not going to take advantage of that benefit, it calls into question
 whether we should change init systems at all.

Note that there are two options that could be explored, to remove the
need to maintain init scripts:
- generating sysvinit scripts from systemd service files or upstart job
  files at build time (this was explored, for systemd service files,
  during a GSoC project in 2012, without much success)
- having a .service/job files runtime interpreter (that sounds quite
  promising)

Even if it cannot be used for all services, using such as interpreter
could maybe provide an easy support path for sysvinit on non-linux
platforms for a large number of simple services.

There's a subthread about that starting at
https://lists.debian.org/debian-devel/2013/05/msg01309.html
Helmut Grohne (Cced) did most of the work on analyzing those possibilities.

Lucas


-- 
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/20131029082010.ga17...@xanadu.blop.info

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

On Mon, Oct 28, 2013 at 05:22:14PM +, Wouter Verhelst wrote:
 On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
  Right.  Whichever init system we pick, I do expect the next step to be to
  drop the requirement to maintain sysvinit backwards-compatibility;

 While I'm not sure from your mail whether you meant to suggest otherwise,
 I do think that whatever we decide for jessie, we should continue the
 requirement of sysvinit compatibility for at least one release after we
 ship with some more modern init system.

The point was not about whether the init system would maintain
backwards-compatibility with sysvinit, which is straightforward to conserve
for some time, but whether individual packages providing services need to
maintain compatibility with sysvinit or if they can adopt the native service
definition format.  If we adopt a different init system as the default in
jessie, then certainly by jessie+1 at the latest, maintainers should feel
free to use the native format exclusively and not feel required to maintain
compatibility with sysvinit.

 Also, since all alternative init implementations under consideration do
 support sysv-style init scripts, I think that whatever init system we
 (well, you, the TC) end up choosing, the requirement in policy should be
 that a package should ship either some init configuration for the
 default init system, or a sysv-style init script. In fact, I think we
 should continue to encourage the latter, in cases where it does make
 sense (e.g., when a given daemon doesn't have any init system specific
 features that could be enabled), since that will help our non-Linux
 ports without significantly impacting performance of the new init
 system.

I see no reason that, if upstart were chosen as the default, porters could
not use it for our non-Linux ports as well.  This is a much better outcome
across our distribution as a whole than to require developers to continue
maintaining init scripts just for our non-Linux ports.

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


signature.asc
Description: Digital signature

Re: Proposal: switch default desktop to xfce

2013-10-29 Thread Thorsten Glaser

Olav Vitters olav at vitters.nl writes:

 Most of systemd is not in pid1. This was explained by a blog references

But (by the time of the jessie freeze, at least) it will need systemd to
be pid1 to work. Same thing, really, just picking words.

bye,
//mirabilos


-- 
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/loom.20131029t093636...@post.gmane.org

Re: Proposal: switch default desktop to xfce

2013-10-29 Thread Olav Vitters

On Tue, Oct 29, 2013 at 08:37:02AM +, Thorsten Glaser wrote:
 Olav Vitters olav at vitters.nl writes:
 
  Most of systemd is not in pid1. This was explained by a blog references
 
 But (by the time of the jessie freeze, at least) it will need systemd to
 be pid1 to work. Same thing, really, just picking words.

No, not at all. If you say that everything is in PID1, this implicates
that there is a big potential for bugs. Bugs in PID1 is bad, you don't
want an unreliable init system. Aside from that, having so much code in
PID1 means the memory footprint is pretty big, likely security issues to
be big as well.

If someone suggests that whole of systemd is in PID1, I assume that
*that* is the problem. Not anything else.

What is meant instead is that systemd provides loads of building
blocks. This is in pretty much any systemd talk that Lennart has given
(except initially). That this is meant is not obvious to me, nor do I
understand it.

The PID 1 argument has lead to explanations such as:
http://people.debian.org/~stapelberg/docs/systemd-dependencies.html

A whole list just to explain that things are *not* in PID 1. This was
based on feedback regarding everything being in PID1.

Everything in PID1 I can discuss, because it is not true. But the
building blocks is something entirely different.

-- 
Regards,
Olav


-- 
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/20131029085523.ga18...@bkor.dhs.org

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Helmut Grohne

TL;DR: Thoughts on using systemd .service files on non-Linux ports.

On Tue, Oct 29, 2013 at 09:20:10AM +0100, Lucas Nussbaum wrote:
 Note that there are two options that could be explored, to remove the
 need to maintain init scripts:
 - generating sysvinit scripts from systemd service files or upstart job
   files at build time (this was explored, for systemd service files,
   during a GSoC project in 2012, without much success)
 - having a .service/job files runtime interpreter (that sounds quite
   promising)
 
 Even if it cannot be used for all services, using such as interpreter
 could maybe provide an easy support path for sysvinit on non-linux
 platforms for a large number of simple services.
 
 There's a subthread about that starting at
 https://lists.debian.org/debian-devel/2013/05/msg01309.html
 Helmut Grohne (Cced) did most of the work on analyzing those possibilities.

Thanks for inviting me to speak up here. Lucas asked me to summarize my
analysis of systemd/sysv integration earlier and I'll be giving this
summary (written for Lucas at that time) below.

For better separation of facts and opinion, let me point out my
motivation for working on this aspect. I believe that the declarative
service configuration of systemd and upstart is superior to init shell
scripts. Consequently, dropping the need for init shell scripts is the
only way to improve the situation (imo). Lacking time, I mostly
neglected upstart.

On 23/08/13 at 22:32 +0200, Helmut Grohne wrote:
 The existing converter (GSOC) can be found at
 https://github.com/akhilvij/systemd-to-sysvinit-converter.
 
 My analysis of this project:
 https://lists.debian.org/debian-devel/2013/05/msg01309.html
 This includes a drafted idea on how to do runtime conversion.
 
 Implementation details on runtime conversion: (last pragraph)
 https://lists.debian.org/debian-devel/2013/05/msg01337.html
 
 Random details about service file conversion issues:
 https://lists.debian.org/debian-devel/2013/05/msg01334.html
 Important point over here: In .service files important dependency
 information has been elided by socket activation. Socket activation is
 official part of the dependency tree and any conversion utility that
 does not do socket activation will not produce correct boot ordering.
 
 Statistical analysis of existing .service files in Debian.
 https://lists.debian.org/debian-devel/2013/07/msg00436.html
 
 .service file parser written in C, could be used as a starting point.
 https://lists.debian.org/debian-devel/2013/07/msg00429.html
 
 I presume that you are preparing arguments for a discussion with the
 CTTE about how to move forward with /sbin/init. The question of whether
 or how to support systemd .service files on non-Linux platforms will be
 asked over there.
 
 The biggest issue I see here is the socket activation. It is mandatory
 for syslog, so no service will declare a dependency on syslog and just
 assume it to be present. On a technical level implementing socket
 activation on non-Linux platforms is possible. It would require a super
 server (similar to inetd) to be started early on and it would start
 .service files on request by other interpreted .service files when
 executed as init scripts. This amounts to reimplementing a fair part of
 systemd. The only alternative would be to annotate .service files with
 the missing dependency information, but which would likely be wrong most
 of the time.
 
 I guess that an implementation that allows socket activation would be
 able to support around 50% of the currently existing .service files.
 
 Bear in mind that systemd is a rapidly moving target. When I talked to
 Lennart about the idea of a portable .service file interpreter, he
 summarized future extensions to systemd that would raise the bar. The
 next issue will likely be the tight integration with dbus and later
 kdbus (the kernel implementation of dbus). By the time we would have an
 implementation featuring socket activation, we will likely need it to do
 dbus activation as well.

Having read the parts of the ctte bug, it feels odd to preclude the
option of supporting multiple init systems from discussion or
consideration. If Debian is to support only one init system and that one
init system is systemd, then given my above analysis it will be very
hard for non-Linux ports to catch up. I argue that in this case we
should consider dropping support for non-Linux ports. So if we really
are considering such an outcome, why not consider the outcome of
supporting multiple init systems (but maybe only one per architecture)?
This would become radically easier if gnome were to become Architecture:
linux-any.

In any case, feel free to ask me for answers or help with respect to
possible integration of systemd .service files in a non-Linux
environment.

I hope that this mail moves the discussion/decision forward.

Helmut


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

Re: Re: Proposal: let’s have a GR about the init system

2013-10-29 Thread Steven Chamberlain

Hi Svante,

On Tue, 29 Oct 2013 08:57:13 +0100 Svante Signell wrote:
 Triggered by the good news about OpenRC for GNU/kFreeBSD
 http://lists.debian.org/debian-devel/2013/10/msg00991.html

I wouldn't get too excited just yet;  with more work we might get OpenRC
working on our ports, but some still insist on there being *only*
systemd (and no ports).  *sigh*

I'm so glad for the existence of the ports right now.  Or Debian might
already have made this jump with eyes closed, into some vendor lock-in
type of situation.

 I would like to try to build it also for GNU/Hurd, save the PATH_MAX
 stuff. Where is it? It is not in http://ftp-master.debian.org/new.html

Packages in the NEW queue are not available to download from anywhere
AFAIK.  But you can clone the packaging repo from:
http://anonscm.debian.org/git/git/collab-maint/openrc.git

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.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/526f9392.1010...@pyro.eu.org

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

On 25 October 2013 17:22, YunQiang Su wzss...@gmail.com wrote:

After more than half of a year's hard work, we have the mips64el port
almost done.
Now we have more than 7600 packages build successfully.
The current build status can be found in http://vip.moonux.org/attempted/

Hey! - well done. That's quite some effort!

Now I get a new board and give it 18GiB DDR3 memory and 1TB hardisk.
Most important is that it is running a Debian Unstable, MIPS64EL.

Anyone has need to port package(s) can apply a account.
Please post me your ssh public key signed by a trust-able PGP key.

I also working on make a rootfs to make it easy to install this port.

Here we still have 2 problems:
1. I believe that it is time of use to talk about how to make this
port to debian-ports.org.
Anyone can help us?

One of the issues will be hardware availability. If I can source the above
boards (which it looks like I can), then I can help with that. Also, we are
trying out the Loongson 2F mini-PC's, expanding their RAM to their maximum
(which may only be 1Gbyte, but we hope 2Gbyte), and adding SSD's. If that
works out then they are cheaper, available, and we can relatively easily
build a small farm of those for (donated to) Debian I hope.

2. Which ISA to be used for this port when it is in debian-ports.
Now we use mips64r2 with tune loongson3a.
Should we downgrade ISA requirement to mips3 or mips64?

Much though I would love to say go with MIPS64R2, I suspect for the main
debian-ports.org upload that is not the best single choice. The Loongson 2F
cores are MIPSIII I believe, as are some other platforms. I have a
suspicion that some of the Broadcom chips for instance are MIPS32R1.
I would suggest that we go with MIPSIII for the first mips64le upload, and
then we can work on MIPS32R2 for the 'unofficial ports' to begin with. What
do you think ?

Thanks for all of the people helped me to make this project be realized:
Eleanor Chen, Aron Xu, Anthony Fok, Fuxin Zhang from Lemote and lots
of other people.

You have my thanks as well :-)

--
YunQiang Su

Graham

--
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKcpw6WvRdF-9O7HKZSr_Vr_ZugF4W0VbTsd=cx-3=qawpz...@mail.gmail.com

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

2013-10-29 Thread YunQiang Su

On Tue, Oct 29, 2013 at 7:05 PM, Graham Whaley graham.wha...@gmail.com wrote:
On 25 October 2013 17:22, YunQiang Su wzss...@gmail.com wrote:

Hey! - well done. That's quite some effort!

Now I get a new board and give it 18GiB DDR3 memory and 1TB hardisk.
Most important is that it is running a Debian Unstable, MIPS64EL.

Nice. Can I ask which board that is? I have some boards reserved for me in
Loongson that I am highly likely to purchase, and suspect (but would like to
confirm) that they are the same board that you are using. I will also check
on any further availability. If I can I will donate one/some of these for
Debian as well.
I prefer that you don't purchase this model of board: I can even not
use the power
button of chassis. Maybe that you can purchase a newer model.
If IPMI is available, it will be much better.

Anyone has need to port package(s) can apply a account.
Please post me your ssh public key signed by a trust-able PGP key.

I also working on make a rootfs to make it easy to install this port.

Here we still have 2 problems:
1. I believe that it is time of use to talk about how to make this
port to debian-ports.org.
Anyone can help us?

2. Which ISA to be used for this port when it is in debian-ports.
Now we use mips64r2 with tune loongson3a.
Should we downgrade ISA requirement to mips3 or mips64?

Much though I would love to say go with MIPS64R2, I suspect for the main
debian-ports.org upload that is not the best single choice. The Loongson 2F
cores are MIPSIII I believe, as are some other platforms. I have a suspicion
that some of the Broadcom chips for instance are MIPS32R1.
I would suggest that we go with MIPSIII for the first mips64le upload, and
then we can work on MIPS32R2 for the 'unofficial ports' to begin with. What
do you think ?
It is also my opinion. Use MIPSIII can make more people use it, and we can
work with some of other unofficial ports.

Thanks for all of the people helped me to make this project be realized:
Eleanor Chen, Aron Xu, Anthony Fok, Fuxin Zhang from Lemote and lots
of other people.

You have my thanks as well :-)

--
YunQiang Su

Graham

--
YunQiang Su

--
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/cakcpw6upmbad8xydoovmmslvs5h6mjtagt90bvqvyxyo1s-...@mail.gmail.com

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

2013-10-29 Thread YunQiang Su

On Sat, Oct 26, 2013 at 9:50 AM, Paul Wise p...@debian.org wrote:
On Sat, Oct 26, 2013 at 12:22 AM, YunQiang Su wrote:

After more than half of a year's hard work, we have the mips64el port
almost done.
Now we have more than 7600 packages build successfully.

Congrats!

Please create a page on the Debian wiki and or update the MIPSPort
wiki page about this new architecture. You could also send patches to
update the list of ports on the Debian website:

https://wiki.debian.org/MIPSPort
http://www.debian.org/ports/
http://www.debian.org/ports/mips/
http://www.debian.org/devel/website/
I have update the wiki pages and working on update WML.

The current build status can be found in http://vip.moonux.org/attempted/

Would you like me to register mips64el.debian.net and CNAME it to
vip.moonux.org or another domain?

Now I get a new board and give it 18GiB DDR3 memory and 1TB hardisk.
Most important is that it is running a Debian Unstable, MIPS64EL.

Anyone has need to port package(s) can apply a account.
Please post me your ssh public key signed by a trust-able PGP key.

You should probably talk to DSA about getting it a debian.net domain
and getting it listed in LDAP as a porter machine.

https://db.debian.org/machines.cgi
I have mailed to DSA, and am waiting for their response.

I also working on make a rootfs to make it easy to install this port.

In Debian we usually expect people to either run debootstrap or d-i to
perform Debian installations since otherwise some files that should be
different between installs will be identical. So please just point
people at debootstrap instead. This is a problem with Debian that we
currently have to work around once for every image creation tool; all
of debian-live, cloud images, mips64el rootfs' etc need/have hacks to
remove files like the dbus machine identifier or the openssh host keys
from the system after debootstrap has run.
The patch for loongson 3A has not be in upstream kernel.
The D-I support is not possible for now.
Live system may be a good option.

Here we still have 2 problems:
1. I believe that it is time of use to talk about how to make this
port to debian-ports.org.
Anyone can help us?

http://www.debian-ports.org/contacts

I have heard rumours on IRC that debian-ports.org is having resource
issues so adding new ports there might be hard.

2. Which ISA to be used for this port when it is in debian-ports.
Now we use mips64r2 with tune loongson3a.
Should we downgrade ISA requirement to mips3 or mips64?

That is up to yourself and people who own or otherwise care about MIPS
hardware. Take into consideration what hardware is available
commercially now and will be in the future, as well as what hardware
most people already own. I don't know much about GCC tuning but I
expect that tuning for one specific machine isn't a good idea.

For future the future steps, here are the requirements for adding
mips64el to the archive and getting it officially included in a future
Debian release:

https://ftp-master.debian.org/archive-criteria.html
http://release.debian.org/testing/arch_policy.html
Thanks for you link.

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caktje6en85omcxtdu+3-zj3-k5rgppemiwg6vah1jpbe2sc...@mail.gmail.com

--
YunQiang Su

--
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/CAKcpw6UVzKe5q8fO_02fVYOp04jxVW5y9=cxrn766e6onkf...@mail.gmail.com

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

On 29 October 2013 11:50, YunQiang Su wzss...@gmail.com wrote:
[snip]

Nice. Can I ask which board that is? I have some boards reserved for me
in
Loongson that I am highly likely to purchase, and suspect (but would
like to
confirm) that they are the same board that you are using. I will also
check
on any further availability. If I can I will donate one/some of these for
Debian as well.
I prefer that you don't purchase this model of board: I can even not
use the power
button of chassis. Maybe that you can purchase a newer model.

Thanks for the heads up - but, which board is it? ;-) Do you have a
model/reference number so I can check if the ones I am offered are the same
as the one you have? I have found a few different ones via google. I would
suspect you have athe 3A-RS780 board:
http://www.loongson.cn/product_info.php?id=35

rather than the dual-SoC LS3-CCNUMA-DEV board
http://www.loongson.cn/product_info.php?id=36

but maybe you have something completely different ?

If IPMI is available, it will be much better.

IPMI would be lovely, but I'm not sure we can locate a board right now with
that - so, we may have to fix remote management with a remotely controlled
power/reset box - I believe they exist (something else I've been looking
into). If the DSA already use some then I'd be interested to hear which :-)

[snip]

Much though I would love to say go with MIPS64R2, I suspect for the main
debian-ports.org upload that is not the best single choice. The
Loongson 2F
cores are MIPSIII I believe, as are some other platforms. I have a
suspicion
that some of the Broadcom chips for instance are MIPS32R1.
I would suggest that we go with MIPSIII for the first mips64le upload,
and
then we can work on MIPS32R2 for the 'unofficial ports' to begin with.
What
do you think ?
It is also my opinion. Use MIPSIII can make more people use it, and we can
work with some of other unofficial ports.

Hey, agreement! :-)

Thanks for all of the people helped me to make this project be realized:
Eleanor Chen, Aron Xu, Anthony Fok, Fuxin Zhang from Lemote and lots
of other people.

You have my thanks as well :-)

--
YunQiang Su

Graham

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

http://lists.debian.org/CAKcpw6WvRdF-9O7HKZSr_Vr_ZugF4W0VbTsd=cx-3=qawpz...@mail.gmail.com

--
YunQiang Su

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

On Tue, Oct 29, 2013 at 7:05 PM, Graham Whaley graham.wha...@gmail.com wrote:
On 25 October 2013 17:22, YunQiang Su wzss...@gmail.com wrote:

Hey! - well done. That's quite some effort!

Now I get a new board and give it 18GiB DDR3 memory and 1TB hardisk.
Most important is that it is running a Debian Unstable, MIPS64EL.

It is a development board donated by Lemote, and we were told that it
was used for internal testing.

Anyone has need to port package(s) can apply a account.
Please post me your ssh public key signed by a trust-able PGP key.

I also working on make a rootfs to make it easy to install this port.

Here we still have 2 problems:
1. I believe that it is time of use to talk about how to make this
port to debian-ports.org.
Anyone can help us?

I don't think Loongson 2F mini-PC is a good choice since the limited
amount of DIMMs and its limitation on using DDR2 memory only. It's not
quite cost effective comparing with the 3A server boards. We've found
that even the development board has competent performance for being a
buildd. The board uses DDR3 memory add it performs much better than
any other Loongson 2/3 products (Gdium Liberty, 2E/F mini-PC, 3A
notebook) which uses DDR2 memory.

2. Which ISA to be used for this port when it is in debian-ports.
Now we use mips64r2 with tune loongson3a.
Should we downgrade ISA requirement to mips3 or mips64?

Much though I would love to say go with MIPS64R2, I suspect for the main
debian-ports.org upload that is not the best single choice. The Loongson 2F
cores are MIPSIII I believe, as are some other platforms. I have a suspicion
that some of the Broadcom chips for instance are MIPS32R1.
I would suggest that we go with MIPSIII for the first mips64le upload, and
then we can work on MIPS32R2 for the 'unofficial ports' to begin with. What
do you think ?

It would require much more resource to spend on making more ports,
this means more build machines and man power, which is not sufficient
at mean time.

Thanks for all of the people helped me to make this project be realized:
Eleanor Chen, Aron Xu, Anthony Fok, Fuxin Zhang from Lemote and lots
of other people.

You have my thanks as well :-)

--
YunQiang Su

Graham

--
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/CAMr=8w6xasskt0neb2y2zmyutkc3sdeza0qe78pcwh7dpcr...@mail.gmail.com

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

On Tue, Oct 29, 2013 at 8:13 PM, Graham Whaley graham.wha...@gmail.com wrote:

On 29 October 2013 11:50, YunQiang Su wzss...@gmail.com wrote:
[snip]

Nice. Can I ask which board that is? I have some boards reserved for me
in
Loongson that I am highly likely to purchase, and suspect (but would
like to
confirm) that they are the same board that you are using. I will also
check
on any further availability. If I can I will donate one/some of these
for
Debian as well.
I prefer that you don't purchase this model of board: I can even not
use the power
button of chassis. Maybe that you can purchase a newer model.

rather than the dual-SoC LS3-CCNUMA-DEV board
http://www.loongson.cn/product_info.php?id=36

but maybe you have something completely different ?

What we are running isn't any of them, and the 2-way server board
looks promising.

If IPMI is available, it will be much better.

I don't know if IPMI is available, but there is certain kind of PCI
device that can help with remotely power on/off the machine controlled
by SMS. I'm curious if DSA think IPMI is mandatory for buildd and
porterbox.

[snip]

Much though I would love to say go with MIPS64R2, I suspect for the main
debian-ports.org upload that is not the best single choice. The Loongson
2F
cores are MIPSIII I believe, as are some other platforms. I have a
suspicion
that some of the Broadcom chips for instance are MIPS32R1.
I would suggest that we go with MIPSIII for the first mips64le upload,
and
then we can work on MIPS32R2 for the 'unofficial ports' to begin with.
What
do you think ?
It is also my opinion. Use MIPSIII can make more people use it, and we can
work with some of other unofficial ports.

Hey, agreement! :-)

Thanks for all of the people helped me to make this project be
realized:
Eleanor Chen, Aron Xu, Anthony Fok, Fuxin Zhang from Lemote and lots
of other people.

You have my thanks as well :-)

--
YunQiang Su

Graham

--
Regards,
Aron Xu

--
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/CAMr=8w7-zd77fdzw1zuxmeacapfvcd-u0fyzqzo6+0c-bqd...@mail.gmail.com

Re: Jessie release goal: DNSSEC as default recursive resolver

On 10/29/2013 03:42 AM, Wouter Verhelst wrote:
 Op 28-10-13 19:28, Thomas Goirand schreef:
 So, as per the replies we've read, it seems that the only way to
 implement DNSSEC would be to first check if it works, and if it doesn't,
 fallback to the locally provided recursive DNS server.
 
 There's also no reason why you _need_ a local DNS server to be able to
 do DNSSEC resolving; you can theoretically use a stub resolver (though
 I'm not sure if there's a stub resolver in Debian which supports doing so).

Is there any stub resolver out there (even not in Debian, but of course
free software) that does this? Could you point to an URL of that kind of
upstream software?

Cheers,

Thomas Goirand (zigo)


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

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Ben Hutchings writes (Re: Bug#727708: tech-ctte: Decide which init system to 
default to in Debian.):
 I do.  I think non-Linux ports make more sense as derivative
 distributions.  This gives them the freedom to drop packages that aren't
 worth porting, work around Linux-isms as necessary, improve integration
 with their own kernel, and release on their own schedule - rather than
 trying to make all the crap in Debian build.  (Remember, 90% of
 everything is crap.)

If we drop initscript support and provide only init files for an init
system which cannot sensibly be ported to non-Linux systems, this is a
hollow prescription.

Ian.


-- 
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/21103.49427.534518.126...@chiark.greenend.org.uk

Re: Jessie release goal: DNSSEC as default recursive resolver

2013-10-29 Thread Kristof Provost

On 2013-10-29 22:03:59 (+0800), Thomas Goirand z...@debian.org wrote:
 On 10/29/2013 03:42 AM, Wouter Verhelst wrote:
  There's also no reason why you _need_ a local DNS server to be able to
  do DNSSEC resolving; you can theoretically use a stub resolver (though
  I'm not sure if there's a stub resolver in Debian which supports doing so).
 
 Is there any stub resolver out there (even not in Debian, but of course
 free software) that does this? Could you point to an URL of that kind of
 upstream software?
 
I believe unbound can already do this, if it's configured to.
See unbound.conf(5), specifically the 'Forward Zone Options' bit.

The following config stanza should forward all requests (except the
cached ones) to 1.2.3.4:

name: .
  forward-addr: 1.2.3.4

Regards,
Kristof


-- 
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/20131029142044.gp77...@vega.codepro.be

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

On Tue, Oct 29, 2013, at 5:10, Ben Hutchings wrote:
 I do.  I think non-Linux ports make more sense as derivative
 distributions.  This gives them the freedom to drop packages that aren't
 worth porting, work around Linux-isms as necessary, improve integration
 with their own kernel, and release on their own schedule - rather than
 trying to make all the crap in Debian build.  (Remember, 90% of
 everything is crap.)

I do as well. I do admire the amount of work required to get those ports
up and running, but I still see them as a toys without real (production)
deployment base. I see a value in non-Linux ports in finding bugs that
won't manifest on Linux ports, but to me they are not mandatory, just
nice to have.

And thus I don't think we should make our decisions based on existence
of our non-Linux ports. E.g. we should not be taken hostage by lowest
common denominator.

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


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

Re: Proposal: s have a GR about the init system

Tollef Fog Heen writes (Re: Proposal: s have a GR about the init system):
 Both Colin and Steve are excellent developers.  I see no need for any of
 them to recuse themselves because of their employer.  Whether Steve
 should recuse himself due to him being the maintainer of one of the
 packages is something I leave to him and the CTTE.

I think he shouldn't recuse himself.

When I wrote the constitutional rules on this, I considered this kind
of question.  The root of my thinking was this: ultimately the same
reasons why a TC member might want to vote in a particular way, are
also reasons why they might get involved in the maintenance of a
particular program.

I haven't spoken to Steve about this in the context of upstart, but it
seems very likely that the (mostly technical) reasons that lead Steve
to prefer upstart for Debian are substantially the same reasons as got
Steve involved in working on upstart in the first place.

Looking at it this way, requiring a recusal from TC members in these
kind of situations would lead to a situation where a TC member who
felt strongly about an impending controversy might avoid applying
their technical skills to software development so that they wouldn't
look biased when the controversy came to the TC.  This seems quite
relevant to the current issue - I think a TC referral has been
foreseeable for some time.

To give another example: should I have avoided writing dgit myself, so
that if it comes to some kind of dispute about how Debian's git
integration should happen, and how dpkg-source should behave, I would
have a clear field to push my views in the TC ?

The constitution makes an exception for votes to overrule, where the
maintainer being overruled doesn't get a vote; otherwise it would be
just too hard to overrule a TC member.  I thought those narrow
criteria for recusal were sufficient, and I still do.

Ian.


-- 
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/21103.51046.250943.72...@chiark.greenend.org.uk

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

2013-10-29 Thread YunQiang Su

On Tue, Oct 29, 2013 at 10:50 PM, Graham Whaley graham.wha...@gmail.com wrote:



 On 29 October 2013 13:34, Aron Xu a...@debian.org wrote:


 It would require much more resource to spend on making more ports,
 this means more build machines and man power, which is not sufficient
 at mean time.


 True. I hopefully have some resource coming online, and I may also have some
 in-house build hardware available to help with any unofficial ports. We will
 just have to be pragmatic, and it will take time...
Let's pull Fuxin Zhang in and ask him about it.
@Fuxin:
Is there a server available to by which support IPMI? How about its precise?
Or is their any something else which is suitable for build machine?
Imgtec may purchase some.

  Graham



-- 
YunQiang Su


-- 
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/CAKcpw6Vm+6t9+TVJ9sZn00Hp8d30AANdye8z91=UF=y9f-c...@mail.gmail.com

Re: Bits from the Release Team (Jessie freeze info)

Niels Thykier writes (Bits from the Release Team (Jessie freeze info)):
 Results of porter roll-call
 ===
...
 Summary table:
 Arch   || DDs || NMs/DMs || Other || Total
 - ---++-++-++---++--
 armel  ||  5  ||   0 || 2 ||7
 armhf  ||  6  ||   1 || 2 ||9
 hurd-i386  ||  5  ||   0 || 3 ||8
 ia64   || *0* ||   0 || 3 ||3
 kfreebsd-amd64 ||  5  ||   0 || 2 ||6
 kfreebsd-i386  ||  5  ||   0 || 2 ||6
 mips   ||  2  ||   0 || 1 ||3
 mipsel ||  2  ||   0 || 1 ||3
 powerpc[1] || (1) ||   0 || 2 ||   2.5?
 s390x  ||  1  ||   0 || 1 ||2
 sparc  ||  1  ||   0 || 0 ||1
...
 Based on the number of porters, we are considering changing the
 current requirements of 5 DDs to better reflect the reality of the
 situation.  We will follow up in a future bits on the changes.

Thanks.

I think it is disappointing to find that we may be dropping
architectures where a significant amount of effort is available,
simply because the volunteers don't have enough status - specifically,
because of a lack of DDs.

I'm keen that Debian should continue to support a wide range of
architectures.  Would it help if I, as a DD, volunteered to sponsor
porter uploads for any architecture ?  That is I guess I'm
volunteering to become a new kind of person - a non-port-specific
porter sponsor.

Obviously I will review the debdiff etc.  I'm an experienced C
programmer with some background in C language lawyering and
portability stuff, so I should usually be able to do a decent review
of a patch even on an unfamiliar architecture.

In fact, regardless of what the release team decide for the policy, I
would be happy to sponsor porter uploads.  Please just email me.

Ian.


-- 
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/21103.52917.876297.985...@chiark.greenend.org.uk

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

On 29 October 2013 13:40, Aron Xu happyaron...@gmail.com wrote:


 What we are running isn't any of them, and the 2-way server board
 looks promising.

 Thanks both. OK, so I've no details from Loongson about the boards they
have for me yet either - I suspect it may be the same as your board.

What we need to consider here is also board price and availability. We can
buy 2f mini-PCs, relatively cheap and easily. If they satisfy a need then
they may be (a mid-term/interim) solution to shortage of hardware right
now. If I find we can source the 3A DDR3 motherboards easily them yippee,
but right now that is less clear than sourcing the 2F mini-PC's.



 I don't know if IPMI is available, but there is certain kind of PCI
 device that can help with remotely power on/off the machine controlled
 by SMS. I'm curious if DSA think IPMI is mandatory for buildd and
 porterbox.

 I think DSA would like to make it a requirement for the future, but they
are pragmatic, and right now many boxes (not just MIPS) do not have good
remote power/reset control. There are external boxes that can do this
though, and we are investigating them already for internal use, and I'll
share any useful findings.


 --
 Regards,
 Aron Xu


 thanks guys - I'll keep you posted with my progress as well.

 Graham

Re: MIPS64EL port box is ready for use (Was: mips64el port build failed list)

On 29 October 2013 13:34, Aron Xu a...@debian.org wrote:


 It would require much more resource to spend on making more ports,
 this means more build machines and man power, which is not sufficient
 at mean time.


True. I hopefully have some resource coming online, and I may also have
some in-house build hardware available to help with any unofficial ports.
We will just have to be pragmatic, and it will take time...

 Graham

Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))

2013-10-29 Thread Daniel Schepler

On Monday, October 28, 2013 12:15:09 PM Emmanuel Bourg wrote:
 Le 27/10/2013 16:30, Daniel Schepler a écrit :
  (To be honest, the
  Java packages are such a tangled mess that I've given up on trying to
  bootstrap that part of the archive for now -- and many of those do get
  pulled into the minimal set of ca. 1473 source packages I get with my
  criteria.)
 Hi Daniel, could you elaborate on the tangled mess of the Java packages?
 As someone who cares about the Java packages in general I'd be
 interested in hearing what could be improved.

(Let's take any more detailed discussions on this off debian-devel and leave it 
just on debian-java.)

The first task would be to bootstrap gcj and then openjdk (and the latter's 
binary dependencies on libatk-wrapper-java-jni, ca-certificates-java, tzdata-
java).  Then I have to bootstrap ant, which is made difficult by the fact that 
there are so many Build-Depends needed before it's possible to build a full 
version of ant-optional.  In the past I've done that by first building just ant 
from that package, and then whenever one of the indirect Build-Depends of ant-
optional has a Build-Depends on ant-optional itself, I build a throwaway 
version of ant-optional against whatever I have available at that point.  But 
now, with libgnumail-java having a Build-Depends on bnd which Build-Depends on 
some packages from eclipse, I don't really have any idea how to handle that, 
other than to drop the call to bnd and cross my fingers hoping nothing needs 
whatever the bnd call adds to that package.

Mixed in with that, I also have to bootstrap maven-repo-helper, and for a few 
packages that I need before I'm able to do that, I do the ugly thing of just 
taking the metadata files from existing packages and installing them by hand 
into bootstrapped packages.  Then, the next major hurdle is that many packages 
that are part of the Maven build system or its binary dependencies have Build-
Depends on maven-debian-helper themselves.  A while ago I figured out a way to 
bootstrap this using maven-ant-helper, but that's a long drawn-out process 
involving probably hundreds of packages.  And I'm not sure that my process 
will still work, as there are even more packages that have switched to using 
maven-debian-helper to build in the meantime, including libjaxen-java which 
has always been a headache because of its circular Build-Depends with dom4j, 
libjdom1-java, xom.  (Also, maven-ant-helper itself isn't necessarily that 
easy to bootstrap, as it Build-Depends on ant-contrib, which Build-Depends on 
ivy, which Build-Depends on libcommons-vfs-java, which needs maven-debian-
helper.)  And yes, maven-debian-helper is part of that set of ca. 1473 source 
packages, for example via the chain x11proto-core - fop - xmlgraphics-
commons - mockito - objenesis - maven-debian-helper.

Anyway, that's just an overview of the main issues I face with a bootstrap of 
the Java packages.  If you want, I could restart my bootstrap process and let 
you know in more detail what Build-Depends cycles I run into (and solutions 
where I've been able to find them in past iterations).

Obviously, though, very little of this will be relevant for the case of 
bootstrapping a new port, using the existing Architecture: all packages.
-- 
Daniel Schepler


--
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/2411641.bXzH0chkUq@frobozz

Re: Bits from the Release Team (Jessie freeze info)

2013-10-29 Thread Niels Thykier

On 2013-10-29 16:05, Ian Jackson wrote:
 Niels Thykier writes (Bits from the Release Team (Jessie freeze info)):
 Results of porter roll-call
 ===
 ...
 Summary table:
 Arch   || DDs || NMs/DMs || Other || Total
 - ---++-++-++---++--
 armel  ||  5  ||   0 || 2 ||7
 armhf  ||  6  ||   1 || 2 ||9
 hurd-i386  ||  5  ||   0 || 3 ||8
 ia64   || *0* ||   0 || 3 ||3
 kfreebsd-amd64 ||  5  ||   0 || 2 ||6
 kfreebsd-i386  ||  5  ||   0 || 2 ||6
 mips   ||  2  ||   0 || 1 ||3
 mipsel ||  2  ||   0 || 1 ||3
 powerpc[1] || (1) ||   0 || 2 ||   2.5?
 s390x  ||  1  ||   0 || 1 ||2
 sparc  ||  1  ||   0 || 0 ||1
 ...
 Based on the number of porters, we are considering changing the
 current requirements of 5 DDs to better reflect the reality of the
 situation.  We will follow up in a future bits on the changes.
 
 Thanks.
 

You are welcome. :)

 I think it is disappointing to find that we may be dropping
 architectures where a significant amount of effort is available,
 simply because the volunteers don't have enough status - specifically,
 because of a lack of DDs.
 

As mentioned we are debating whether the 5 DDs requirement still makes
sense.  Would you say that we should abolish the requirement for DD
porters completely?  I.e. Even if there are no (soon to be) DDs, we
should consider the porter requirements fulfilled as long as they are
enough active porters behind the port[0]?

 I'm keen that Debian should continue to support a wide range of
 architectures.  Would it help if I, as a DD, volunteered to sponsor
 porter uploads for any architecture ?  That is I guess I'm
 volunteering to become a new kind of person - a non-port-specific
 porter sponsor.
 

I suppose that could help ports without a DD if we allowed such to be in
testing.  However, it is my understanding that our main issue with ports
often is that they are not actively maintained (or appears to lack
active maintenance).
  As an example I remember having received several complains from e.g.
the GCC maintainers in regards to the state of gcc on various ports[1].
 Here I would suspect a patch would be sufficient without needing to
actually NMU gcc to get the fix in.
  There are also stuff like the port concerns from DSA that attention.

 Obviously I will review the debdiff etc.  I'm an experienced C
 programmer with some background in C language lawyering and
 portability stuff, so I should usually be able to do a decent review
 of a patch even on an unfamiliar architecture.
 
 In fact, regardless of what the release team decide for the policy, I
 would be happy to sponsor porter uploads.  Please just email me.
 
 Ian.
 
 

:)

~Niels

[0] Leaving the definition of active porter vaguely defined for now.

[1] Obviously, I haven't been keeping track of them so I had to ask for
a reminder.

https://lists.debian.org/debian-release/2013/10/msg00710.html



-- 
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/526fdfe3.7060...@thykier.net

Re: security-aware-resolver virtual package (Was: Two new DNS virtual packages (authoritative-name-server recursive-name-server))

Ondřej Surý writes (security-aware-resolver virtual package (Was: Two new 
DNS virtual packages (authoritative-name-server  recursive-name-server))):
 since the authoritative-name-server idea was rejected by the list, I was
 going to propose alternative:
 
 security-aware-resolver
 
 The definition from RFC4033:
 
Security-Aware Resolver: An entity acting in the role of a resolver
   (defined in section 2.4 of [RFC1034]) that understands the DNS
   security extensions defined in this document set.  In particular,
   a security-aware resolver is an entity that sends DNS queries,
   receives DNS responses, supports the EDNS0 ([RFC2671]) message
   size extension and the DO bit ([RFC3225]), and is capable of using
   the RR types and message header bits defined in this document set
   to provide DNSSEC services.

This is a nice idea in principle but I wonder whether there are in
fact any current packages out there that would find this useful as a
dependency ?

What packages depend (or will depend) on the services of a
security-asware resolver, and will therefore refer to the proposed
virtual package name ?


I think TBH that this is also a concern for the proposed recursive
resolver virtual package.  Pretty much everything network-related
expects that there is a working resolver, but we don't generally
declare this using the dependency system.  What existing dependency
relationships would be supplanted or extended by the new virtual
package name ?

Ian.


--
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/21103.57973.14876.218...@chiark.greenend.org.uk

Re: Jessie release goal: DNSSEC as default recursive resolver

Wouter Verhelst writes (Re: Jessie release goal: DNSSEC as default recursive 
resolver):
 There is nothing in DNSSEC which makes it inherently incompatible with
 using DNS forwarders. Talking to the root DNS servers is fun and all,
 but there's really no good reason why you shouldn't use the large DNS
 cache on your ISP's recursive DNS server.

I'm afraid this is not true.  The way DNSSEC is designed means that
you can't tunnel the DNSSEC data through a forwarding nameserver
which doesn't itself understand DNSSEC at least to a minimal extent.

If your local forwarder doesn't do this, which is quite likely, you
have to fall back to the global infrastructure - and hope it's not
blocked or intercepted.

 Now, if your local DNS server ignores requests for RRSIG records, or
 sabotages DNSSEC in other ways, it might make sense to try to bypass
 them, possibly by running a local caching DNS server. But that should
 not be the first thing to do.

IIRC one of the ways that DNSSEC breaks naive forwarders is that its
rules for what constitutes an RRset are different to normal.  It's a
while since I looked at this but I could go and look at the RFCs
again...

Ian.


-- 
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/21103.58350.86031.655...@chiark.greenend.org.uk

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Hi Helmut,

On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote:
 Having read the parts of the ctte bug, it feels odd to preclude the
 option of supporting multiple init systems from discussion or
 consideration. If Debian is to support only one init system and that one
 init system is systemd, then given my above analysis it will be very
 hard for non-Linux ports to catch up. I argue that in this case we
 should consider dropping support for non-Linux ports. So if we really
 are considering such an outcome, why not consider the outcome of
 supporting multiple init systems (but maybe only one per architecture)?

While other members of the TC may wish to consider this option, I've ruled
it out myself because we would lose most of the benefits of switching away
from sysvinit and instead accrue significant maintenance costs to individual
developers who would then have to support both init systems in their
packages.  What makes switching init systems worth doing is being able to
*simplify* the interfaces between the init system and the services.
Continuing to support different init systems across different architectures
would add complexity instead.  That's a pretty bleak outcome.

There's nothing fundamental that prevents upstart from being ported to
non-Linux ports.  So certainly, if the TC decides for upstart, I see no
reason we would want to support sysvinit on ports instead of expecting the
porters to port upstart to their architecture.

 This would become radically easier if gnome were to become Architecture:
 linux-any.

GNOME may be the trigger for this being raised to the TC, but it's not the
core question that we need to address.

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


signature.asc
Description: Digital signature

Re: Jessie release goal: DNSSEC as default recursive resolver

On Tue, Oct 29, 2013, at 17:35, Ian Jackson wrote:
 Wouter Verhelst writes (Re: Jessie release goal: DNSSEC as default
 recursive resolver):
  There is nothing in DNSSEC which makes it inherently incompatible with
  using DNS forwarders. Talking to the root DNS servers is fun and all,
  but there's really no good reason why you shouldn't use the large DNS
  cache on your ISP's recursive DNS server.
 
 I'm afraid this is not true.  The way DNSSEC is designed means that
 you can't tunnel the DNSSEC data through a forwarding nameserver
 which doesn't itself understand DNSSEC at least to a minimal extent.
 
 If your local forwarder doesn't do this, which is quite likely, you
 have to fall back to the global infrastructure - and hope it's not
 blocked or intercepted.

There are even ways how to tunnel DNS through TLS on top of TCP/443.
(Ugly but effective as last resort.)

  Now, if your local DNS server ignores requests for RRSIG records, or
  sabotages DNSSEC in other ways, it might make sense to try to bypass
  them, possibly by running a local caching DNS server. But that should
  not be the first thing to do.
 
 IIRC one of the ways that DNSSEC breaks naive forwarders is that its
 rules for what constitutes an RRset are different to normal.  It's a
 while since I looked at this but I could go and look at the RFCs
 again...

That's true.

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


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

Re: Bits from the Release Team (Jessie freeze info)

Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)):
 On 2013-10-29 16:05, Ian Jackson wrote:
  I'm keen that Debian should continue to support a wide range of
  architectures.  Would it help if I, as a DD, volunteered to sponsor
  porter uploads for any architecture ?  That is I guess I'm
  volunteering to become a new kind of person - a non-port-specific
  porter sponsor.
...
 I suppose that could help ports without a DD if we allowed such to be in
 testing.

Indeed.

  However, it is my understanding that our main issue with ports
 often is that they are not actively maintained (or appears to lack
 active maintenance).

Right.

 As mentioned we are debating whether the 5 DDs requirement still makes
 sense.  Would you say that we should abolish the requirement for DD
 porters completely?  I.e. Even if there are no (soon to be) DDs, we
 should consider the porter requirements fulfilled as long as they are
 enough active porters behind the port[0]?

I don't have a good feel for the answer to that question.  

It's just that if it is the case that a problem with ports is the lack
of specifically DDs, rather than porter effort in general, then
sponsorship is an obvious way to solve that problem.

If you feel that that's not really the main problem then a criterion
which counts porters of any status would be better.

(Mind you, I have my doubts about a process which counts people
promising to do work - it sets up some rather unfortunate incentives.
I guess it's easier to judge and more prospective than a process which
attempts to gauge whether the work has been done well enough.)

   As an example I remember having received several complains from
 e.g.  the GCC maintainers in regards to the state of gcc on various
 ports[1].  Here I would suspect a patch would be sufficient without
 needing to actually NMU gcc to get the fix in.  There are also stuff
 like the port concerns from DSA that attention.

Right.

Thanks,
Ian.


-- 
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/21103.59120.410686.914...@chiark.greenend.org.uk

Re: MIPS64EL port box is ready for use

2013-10-29 Thread Tollef Fog Heen

]] Aron Xu 

  IPMI would be lovely, but I'm not sure we can locate a board right now with
  that - so, we may have to fix remote management with a remotely controlled
  power/reset box - I believe they exist (something else I've been looking
  into). If the DSA already use some then I'd be interested to hear which :-)
 
 I don't know if IPMI is available, but there is certain kind of PCI
 device that can help with remotely power on/off the machine controlled
 by SMS. I'm curious if DSA think IPMI is mandatory for buildd and
 porterbox.

We would very much like «reasonable remote access».  Whether that's IPMI
onto a BMC or serial console which can interact with the boot loader and
a network-enabled power strip is less important.  Of course, having nice
features like mounting of ISOs over HTTP and such is a nice bonus, but
not a requirement.

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

-- 
Tollef Fog Heen (speaking on behalf of himself, but with a DSA hat)
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m2fvrkf16y@rahvafeir.err.no

Re: MIPS64EL port box is ready for use

2013-10-29 Thread David Kuehling

Hi,

 Graham == Graham Whaley graham.wha...@gmail.com writes:

 What we need to consider here is also board price and availability. We
 can buy 2f mini-PCs, relatively cheap and easily. If they satisfy a
 need then they may be (a mid-term/interim) solution to shortage of
 hardware right now. If I find we can source the 3A DDR3 motherboards
 easily them yippee, but right now that is less clear than sourcing the
 2F mini-PC's.

somewhat related information: just found out that there is (seems to be)
a Loongson 3A based mini-PC:

  http://www.lemote.com/products/computer/fulong/348.html

Price point seems to be RMB 3999, if I understand this shop's page
correctly:

  
http://item.taobao.com/item.htm?spm=a1z10.1.w4004-2611770768.2.DQacwZid=22206048695

Not sure how stable/usable that hardware would be, tough.  I currently
consider getting one to replace my 2f mini-PC.  It may only come with a
single-core version of the 3A (description says LoongSon2G/3A, not sure
what that means).

cheers,

David
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F



pgp4xQlQWK66i.pgp
Description: PGP signature

Re: MIPS64EL port box is ready for use

On Tue, Oct 29, 2013 at 6:15 PM, Tollef Fog Heen tfh...@err.no wrote:
]] Aron Xu

We would very much like «reasonable remote access». Whether that's IPMI
onto a BMC or serial console which can interact with the boot loader and
a network-enabled power strip is less important. Of course, having nice
features like mounting of ISOs over HTTP and such is a nice bonus, but
not a requirement.

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

I thinlk we could hack a low cost arm like a cubiebox to do that. They
are plenty of gpio available and reseting power is only matter or
putting on/off a relay... Bonus point it will run debian :)

Bastien

--
Tollef Fog Heen (speaking on behalf of himself, but with a DSA hat)
UNIX is user friendly, it's just picky about who its friends are

--
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/m2fvrkf16y@rahvafeir.err.no

--
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/cae2spabklsotzisu+6pw4desx5u5t9db2xdcsamfdvj0w6o...@mail.gmail.com

Re: MIPS64EL port box is ready for use

On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Aron Xu

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

If we can find a way of letting Loongson 3A board supports remote
console then you are able to re-install the system because PMON have
networking support and can boot the system from tftp. Power control
can be done by hacking the on-board power button pins.

Thanks,
Aron Xu

--
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/CAMr=8w5zqqkac0k1j9wfmbff5ybq8rc-n7fjq1rx0dqtjhd...@mail.gmail.com

Re: porting OpenRC on kFreeBSD and Hurd (was: Proposal: let’s have a GR about the init system)

On 10/29/2013 03:57 PM, Svante Signell wrote:
 On Fri, 2013-10-25 at 23:45 +0800, Thomas Goirand wrote:
 
 OpenRC has been waiting in the NEW queue (targeting experimental, as
 this is what it is right now: experimental!) for more than a month. It'd
 be nice if someone from the FTP master team could review it, so that at
 least others can try it. As much as I can tell, it works, though I'm
 sure there's a lot of problems that I didn't see, and having it exposed
 would help (so that others can fill bug reports).
 
 Triggered by the good news about OpenRC for GNU/kFreeBSD
 http://lists.debian.org/debian-devel/2013/10/msg00991.html
 I would like to try to build it also for GNU/Hurd, save the PATH_MAX
 stuff. Where is it? It is not in http://ftp-master.debian.org/new.html

It has been rejected because of /sbin/rc.

FYI, if it doesn't FTBFS anymore, it still doesn't work properly in
kFreeBSD: some of the early boot things in /lib/rc/sh/init.sh aren't
working well yet (for example, /run shouldn't be mounted with the nodev
option under kFreeBSD, plus some more). Though I'm working with upstream
on it via IRC (on #openrc on Freenode), and they are very friendly. They
already applied the kFreeBSD patch that was sent to me, if I'm not
mistaking.

If you want to check it out, please git clone:

Vcs-Git: git://anonscm.debian.org/collab-maint/openrc.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/openrc.git

Note also that there's a *new* dependency problem (it wasn't there a
month ago...), with ifupdown, openssh-server plus another one (I can't
remember which one) which insist on having sysv-rc installed. That
prevent from installing OpenRC normally, though with a bit of
--ignore-depends=sysv-rc you will be able to install OpenRC with dpkg
-i. Once you've done that, you pretty much fucked the apt database,
though that's enough for testing a reboot on a VM! :)

I've asked Roger Leigh what went wrong with the sysvinit source package
over this last month, and I'm still waiting for an answer.

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/5270024b.1060...@debian.org

Re: Proposal: let’s have a GR about the init system

On 10/29/2013 06:53 PM, Steven Chamberlain wrote:
 Hi Svante,
 
 On Tue, 29 Oct 2013 08:57:13 +0100 Svante Signell wrote:
 Triggered by the good news about OpenRC for GNU/kFreeBSD
 http://lists.debian.org/debian-devel/2013/10/msg00991.html
 
 I wouldn't get too excited just yet;  with more work we might get OpenRC
 working on our ports, but some still insist on there being *only*
 systemd (and no ports).  *sigh*

Nobody can stop anyone to work on what he wishes in Debian. This has
always been the case. If I am having fun to work on OpenRC, and wish to
have it work on the ports, that's my choice, and my choice only.

I don't think it can go as far as blocking OpenRC from being uploaded,
even if it's just experimental (experimental is there for that). The
only annoying bit would be if we decide that sysv-rc scripts (and OpenRC
runscripts) don't have to be mandatory, and that a bunch of #@(*$ refuse
to apply patches for supporting the ports sent to the BTS. Then only,
you have a problem. Though I really can't believe this will happen and
that we have such extremism within Debian. Let's assume good faith! :)

Cheers,

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/52700489.2000...@debian.org

Re: let's split the systemd binary package

2013-10-29 Thread Kevin Chadwick

previously on this list Philipp Kern contributed:

 I'm not sure why our enterprise users don't count as users as well.

Of course they do even if the couple of people possibly concerned with
it that I know use.. is it Citrix? I was merely pointing out that it
is an extremely small minority of Debian users but possibly? a majority
or major section of RedHats paying customers and even more so it's
revenue stream (pay more).

This should be considered in weighting the pros and cons that's all
especially when terms like real features (largely gone undefined) are
being banded around. As I have said issues that affect many and people
may actually notice have gone are easily fixed as far as I am aware
(certainly the ones mentioned like suspend, as I do so when disabling
polkit very easily without compilation). So how many debian Gnome users
will notice the breakage aside from suspend and ? how many will
continue to use Gnome if the default is changed as has already been
raised.

On top of that, large organisation's should have no problem solving
this and do they use debian or want support from Red Hat/Citrix in
most cases?

I don't need the dbus system bus personally either but I understand the
vast vast majority do in current setups, so that is a real issue of the
future if permitted to land into the kernel as the only option (I doubt
it) and as Canonical/Ubuntu and Google have concerns on multiple fronts
here I think it is certainly worth waiting that out and should not
really be used as an argument currently.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/905842.70346...@smtp101.mail.ir2.yahoo.com

Re: MIPS64EL port box is ready for use

On Tue, Oct 29, 2013 at 7:35 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Aron Xu

IPMI would be lovely, but I'm not sure we can locate a board right now
with
that - so, we may have to fix remote management with a remotely controlled
power/reset box - I believe they exist (something else I've been looking
into). If the DSA already use some then I'd be interested to hear which
:-)

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

It could be done trivally from a chip arm card. Using socat from a tty
to a ssh tunnel
see http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

Thanks,
Aron Xu

--
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/camr8w5zqqkac0k1j9wfmbff5ybq8rc-n7fjq1rx0dqtjhd...@mail.gmail.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/cae2spayt8d49dlzcgggup67dbb4xjbfhgmdblnwhomjs9ij...@mail.gmail.com

Re: MIPS64EL port box is ready for use

On Wed, Oct 30, 2013 at 2:40 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:35 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Aron Xu

IPMI would be lovely, but I'm not sure we can locate a board right now
with
that - so, we may have to fix remote management with a remotely
controlled
power/reset box - I believe they exist (something else I've been looking
into). If the DSA already use some then I'd be interested to hear which
:-)

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

It could be done trivally from a chip arm card. Using socat from a tty
to a ssh tunnel
see http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

Looks really cool, and I think it's doable to support power control
like what you've suggested already.

Cheers,
Aron Xu

--
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/CAMr=8w6R+x2+bQ5JWao_fzynnjHt4Nf=rng+edfpjrk01l+...@mail.gmail.com

Re: let's split the systemd binary package

2013-10-29 Thread Olav Vitters

On Tue, Oct 29, 2013 at 06:37:35PM +, Kevin Chadwick wrote:
 Of course they do even if the couple of people possibly concerned with
 it that I know use.. is it Citrix? I was merely pointing out that it
 is an extremely small minority of Debian users but possibly? a majority

Do you have any references to back up how you know this? Or just merely
guessing? It seems like pure guesswork.

 This should be considered in weighting the pros and cons that's all
 especially when terms like real features (largely gone undefined) are
 being banded around. As I have said issues that affect many and people
 may actually notice have gone are easily fixed as far as I am aware
 (certainly the ones mentioned like suspend, as I do so when disabling
 polkit very easily without compilation). So how many debian Gnome users
 will notice the breakage aside from suspend and ? how many will
 continue to use Gnome if the default is changed as has already been
 raised.

Are you taking up ConsoleKit development or not? Loads of things could
theoretically maybe be done. What matters is something concrete.

 On top of that, large organisation's should have no problem solving
 this and do they use debian or want support from Red Hat/Citrix in
 most cases?

Please don't turn this into a Canonical vs Red Hat thread.

 I don't need the dbus system bus personally either but I understand the
 vast vast majority do in current setups, so that is a real issue of the
 future if permitted to land into the kernel as the only option (I doubt
 it) and as Canonical/Ubuntu and Google have concerns on multiple fronts
 here I think it is certainly worth waiting that out and should not
 really be used as an argument currently.

GNOME relies on d-bus for various things. Not liking d-bus doesn't
change that fact.

-- 
Regards,
Olav


-- 
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/20131029190755.ge25...@bkor.dhs.org

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

On 10/29/2013 10:27 AM, Brian May wrote:
 On 29 October 2013 12:21, Russ Allbery r...@debian.org
 mailto:r...@debian.org wrote:
 
 In other words, I don't think it would make any sense at all to
 standardize on upstart or systemd and then ask people to continue to
 write
 init scripts in the long run (transition issues aside).  Getting rid of
 init scripts is not the whole point, but it's a huge part of it.
 
 
 My understanding is that init scripts will still be required for FreeBSD
 and The Hurd.

Not if OpenRC gets enough attention from the porters. We could
completely get rid of sysv-rc scripts, switch to Upstart or Systemd, and
still have OpenRC as a backup solution for compatibility with our
non-linux ports. OpenRC has a declarative language as well avoiding the
huge sysv-rc init scripts.

I spent a lot of time on it already, but I wont be able to do it all
alone: I got to work to feed my family too... :(

 If the majority switched to systemd, then it would be up to the minority
 to maintain the initd scripts. I don't see this working very well.

If it's still sysv-rc scripts, me neither.

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/52700b4e.9060...@debian.org

Re: MIPS64EL port box is ready for use

On Wed, Oct 30, 2013 at 3:11 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:56 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 2:40 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:35 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Aron Xu

IPMI would be lovely, but I'm not sure we can locate a board right now
with
that - so, we may have to fix remote management with a remotely
controlled
power/reset box - I believe they exist (something else I've been
looking
into). If the DSA already use some then I'd be interested to hear
which :-)

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

It could be done trivally from a chip arm card. Using socat from a tty
to a ssh tunnel
see http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

Looks really cool, and I think it's doable to support power control
like what you've suggested already.

What are the safety specification appliable by DSA ? Main tension ?
Does the board have a power brick ?

I'm not sure about DSA's opinion, and here is the information about
the board. It is an almost standard ITX one, and we've put it in an
ITX chassis retired from a ~2006 Lenovo PC, using its power supply.
The board has some pins for connecting power bottons (Power and
Reset), though we are not using it because it looks not fit to the
connector of the chassis. There is a dedicate button on the board to
power on/off the machine as well. We used the on board button and no
hard reset needed/conducted since successful installation of hardware.
The mentioned ITX machine (6100 model) available for purchase is just
a complete PC box.

Thanks,
Aron Xu

--
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/CAMr=8w72n5gqjuzez8tgw+_r+z0e6ur7kvtt0vv5m3fogtx...@mail.gmail.com

Re: MIPS64EL port box is ready for use

On Tue, Oct 29, 2013 at 7:56 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 2:40 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:35 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Aron Xu

IPMI would be lovely, but I'm not sure we can locate a board right now
with
that - so, we may have to fix remote management with a remotely
controlled
power/reset box - I believe they exist (something else I've been looking
into). If the DSA already use some then I'd be interested to hear which
:-)

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

It could be done trivally from a chip arm card. Using socat from a tty
to a ssh tunnel
see http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

Looks really cool, and I think it's doable to support power control
like what you've suggested already.

What are the safety specification appliable by DSA ? Main tension ?
Does the board have a power brick ?

Bastien

Cheers,
Aron Xu

--
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/cae2spabpc2o9+f55vot9vrnmuowmn0jgkkt7zrt9vvwmhl-...@mail.gmail.com

Re: systemd effectively mandatory now due to GNOME

On Thu, Oct 24, 2013 at 10:29:10PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Oct 24, 2013 at 12:13:34PM -0700, Steve Langasek wrote:
  And this is not just an issue because of people not wanting to use systemd
  init, but also because systemd init *can't* run in a container.
 Whoah, that's not true:

 sudo systemd-nspawn -bD ~/images/fedora-19

 works just fine :)

My understanding, which may be based on dated information, is that
systemd-nspawn doesn't fully contain the system in the way most others (e.g.
users of lxc) talk about when they speak of containers: MAC, cgroups support
inside the container, and possibly other things.

If you use lxc-start instead of systemd-nspawn, does your Fedora image work?
Last I knew, the answer was no.

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


signature.asc
Description: Digital signature

Re: MIPS64EL port box is ready for use

On Tue, Oct 29, 2013 at 8:25 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 3:11 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:56 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 2:40 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:35 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Aron Xu

IPMI would be lovely, but I'm not sure we can locate a board right
now with
that - so, we may have to fix remote management with a remotely
controlled
power/reset box - I believe they exist (something else I've been
looking
into). If the DSA already use some then I'd be interested to hear
which :-)

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

It could be done trivally from a chip arm card. Using socat from a tty
to a ssh tunnel
see http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

Looks really cool, and I think it's doable to support power control
like what you've suggested already.

What are the safety specification appliable by DSA ? Main tension ?
Does the board have a power brick ?

The mini itx does not specify a power connector So if you use an
atx power control do something like this
http://www.mupuf.org/blog/2013/05/11/wtrpm-a-web-based-wt-suite-to-power-up-slash-down-your-computers/

Thanks,
Aron Xu

--
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/CAE2SPAZ�ek9ml4ygcsxlxzhfu_qq98y9o5gkeftwnpjne...@mail.gmail.com

Re: MIPS64EL port box is ready for use

On Tue, Oct 29, 2013 at 8:46 PM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 8:25 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 3:11 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:56 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 2:40 AM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Tue, Oct 29, 2013 at 7:35 PM, Aron Xu a...@debian.org wrote:
On Wed, Oct 30, 2013 at 1:15 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Aron Xu

IPMI would be lovely, but I'm not sure we can locate a board right
now with
that - so, we may have to fix remote management with a remotely
controlled
power/reset box - I believe they exist (something else I've been
looking
into). If the DSA already use some then I'd be interested to hear
which :-)

We haven't really talked about how and when it should be enforced, but
I'm reluctant to take on more porter hardware that lacks reasonable
remote management.

It could be done trivally from a chip arm card. Using socat from a tty
to a ssh tunnel
see http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

Looks really cool, and I think it's doable to support power control
like what you've suggested already.

What are the safety specification appliable by DSA ? Main tension ?
Does the board have a power brick ?

Note that I do not recommand to do that this guy has done due to
galvanic isolation problem. You could fry your board with something
like this!
Always use optocoupled MOS, not directly MOSFET

Thanks,
Aron Xu

--
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/CAE2SPAbsCCniEmq2p4eDoNGGrUkGFDeY2JSgKh=qwdzbrki...@mail.gmail.com

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Marco d'Itri

On Oct 29, Russ Allbery r...@debian.org wrote:

 There are various other options, including not changing away from sysvinit
 or someone porting the necessary support to Hurd and kFreeBSD.  Or, of
 course, dropping Hurd and kFreeBSD, although I'm sure that no one wants
 that outcome.
Well. If the choice is between Hurd and kFreeBSD and a modern Linux 
system, then I will be first in the line trying to kill them.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd effectively mandatory now due to GNOME

2013-10-29 Thread Ben Hutchings

On Tue, Oct 29, 2013 at 12:15:10PM -0700, Steve Langasek wrote:
 On Thu, Oct 24, 2013 at 10:29:10PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
  On Thu, Oct 24, 2013 at 12:13:34PM -0700, Steve Langasek wrote:
   And this is not just an issue because of people not wanting to use systemd
   init, but also because systemd init *can't* run in a container.
  Whoah, that's not true:
 
  sudo systemd-nspawn -bD ~/images/fedora-19
 
  works just fine :)
 
 My understanding, which may be based on dated information, is that
 systemd-nspawn doesn't fully contain the system in the way most others (e.g.
 users of lxc) talk about when they speak of containers: MAC, cgroups support
 inside the container, and possibly other things.

Indeed; Lennert has described it as an enhanced chroot rather than a
container.  The new process is in the same user namespace and inherits
most capabilities.  It can optionally run in a new network namespace.

Ben.

 If you use lxc-start instead of systemd-nspawn, does your Fedora image work?
 Last I knew, the answer was no.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.


-- 
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/20131029204700.ga3...@decadent.org.uk

Bug#728246: ITP: libmoosex-types-stringlike-perl -- Moose type constraints for strings or string-like objects

2013-10-29 Thread Damyan Ivanov

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov d...@debian.org

* Package name: libmoosex-types-stringlike-perl
  Version : 0.001
  Upstream Author : David Golden dagol...@cpan.org
* URL : https://metacpan.org/release/MooseX-Types-Stringlike
* License : Apache-2.0
  Programming Lang: Perl
  Description : Moose type constraints for strings or string-like objects

MooseX::Types::Stringlike provides a more general version of the Str type. If
coercions are enabled, it will accepts objects that overload stringification
and coerces them into strings.

Moose is an extension of the Perl 5 object system.

This module is a dependency of libmoosex-types-path-tiny-perl (ITP#727300) and 
will be maintained by pkg-perl.

Yes, it contains only 17 (seventeen) lines of code (and lots of documentation), 
but bundling it in the modules that depend on it is not something I want to do.


-- 
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/20131029211021.8193.90676.reportbug@dltp

Re: let's split the systemd binary package

2013-10-29 Thread Kevin Chadwick

previously on this list Olav Vitters contributed:

 On Tue, Oct 29, 2013 at 06:37:35PM +, Kevin Chadwick wrote:
  Of course they do even if the couple of people possibly concerned with
  it that I know use.. is it Citrix? I was merely pointing out that it
  is an extremely small minority of Debian users but possibly? a majority  
 
 Do you have any references to back up how you know this? Or just merely
 guessing? It seems like pure guesswork.
 

Until someone points out some new functionality I have missed, this is
surely obvious especially if the *buntus are included.

  This should be considered in weighting the pros and cons that's all
  especially when terms like real features (largely gone undefined) are
  being banded around. As I have said issues that affect many and people
  may actually notice have gone are easily fixed as far as I am aware
  (certainly the ones mentioned like suspend, as I do so when disabling
  polkit very easily without compilation). So how many debian Gnome users
  will notice the breakage aside from suspend and ? how many will
  continue to use Gnome if the default is changed as has already been
  raised.  
 
 Are you taking up ConsoleKit development or not? Loads of things could
 theoretically maybe be done. What matters is something concrete.
 

I have no use for consolekit and it doesn't run on my systems and none
of my users notice, so why would I?. What I don't agree with is this
ultimatum that something must be done and making a mountain out of a
trench. Worst case is holding systemd back or using consolekit and all
this may be solved in x number of unknown ways by the time it matters to
stable. I'm also sure those that need session tracking could easily
afford to sponsor the work if they need it and use Debian.


  On top of that, large organisation's should have no problem solving
  this and do they use debian or want support from Red Hat/Citrix in
  most cases?  
 
 Please don't turn this into a Canonical vs Red Hat thread.
 

I am not, I have spotted and cited trends and made statements perhaps
without citing other annoying trends in detail that may alter my tone
to only parts of RedHat (such as documentation, configuration
methods...). I respect the company as a whole and don't forget many
Redhat employees have publicly spoken out against systemd. I was merely
responding to the post of lennart's that may make many think there is no
alternative, when they specifically have been talked about recently.
There are always alternatives. Who knows even linux itself may fork one
day but I hope not.

  I don't need the dbus system bus personally either but I understand the
  vast vast majority do in current setups, so that is a real issue of the
  future if permitted to land into the kernel as the only option (I doubt
  it) and as Canonical/Ubuntu and Google have concerns on multiple fronts
  here I think it is certainly worth waiting that out and should not
  really be used as an argument currently.  
 
 GNOME relies on d-bus for various things. Not liking d-bus doesn't
 change that fact.

Who said I didn't like dbus. I even said the session bus should be used
where it is best suited. I do think it is often used when it shouldn't
be and do disagree with parts of dbus. dbus has atleast 3 major distinct
functions that I can think of. Running programs as root is one I
completely disagree with and with evidential good reason.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/908332.97162...@smtp144.mail.ir2.yahoo.com

Re: Proposal: switch default desktop to xfce

2013-10-29 Thread Emilio Pozuelo Monfort

On 24/10/13 18:31, Lucas Nussbaum wrote:
 What's the the status of XFCE regarding accessibility?
 
 That was a big strengh of GNOME for a long time, though I've heard
 rumors (sorry not to be more specific) that gnome-shell has some
 unsolved issues in that regard, which is a problem since GNOME
 classic/fallback mode is gone in 3.8.

What are those problems? AFAIK a11y status in GNOME is pretty good. There were
some issues in the early days of GNOME 3 but those are long solved.

Emilio


-- 
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/52702bc9.7060...@debian.org

Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Steven Chamberlain

On Mon, 28 Oct 2013 19:38:09 -0700, Russ Allbery wrote:
 Brian May br...@microcomaustralia.com.au writes:
 My understanding is that init scripts will still be required for FreeBSD
 and The Hurd.
 
 I would not assume that.  At least, I personally don't think that
 switching to upstart or systemd as a default but requiring that everyone
 provide both files for that system and init scripts for Hurd and kFreeBSD
 to be a good outcome, since I don't think that will be something at which
 Debian will be successful.

But that seems like the easiest way to not break what is already working
in GNU/kFreeBSD, Hurd - and on users' own Linux systems if they have
non-Debian software using SysV init scripts.

Do systemd/Upstart intend to rewrite inits cripts for all of the
estimated up to 1200 packages that provide them currently?  Or could
they just as easily keep using some of those SysV scripts and keep them
around?

Dismissing the ports as toy projects is not a compelling argument to me.
 Not least because I think of a toy as something fun, educational and
certainly not without any meaning;  I wouldn't want commercial desires
to get too much in the way of that.

I could equally dismiss the plans for GNOME+systemd+Linux integration as
hype/fantasy.  But actually, I welcome people to try it and show us what
it can do, as long as they do so without harming the rest of us.

Having some fallback is beneficial not only to the ports but to Linux
users who may not want, or are unable to use, the new init system.

Just wondering, if systemd upstream cares only for Linux and that's
considered okay, might they also start dropping support for
architectures they stop caring about (or for commercial reasons)?  Say
MIPS, s390, SPARC.  In that case, permanently ditching SysV init could
put even some Linux ports in jeopardy.  Perhaps Upstart carries the same
risk if Ubuntu releases only for i386/amd64/arm.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.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/52702ed2.5060...@pyro.eu.org

Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Matthias Klumpp

2013/10/29 Steven Chamberlain ste...@pyro.eu.org:
 [...]

 Just wondering, if systemd upstream cares only for Linux and that's
 considered okay, might they also start dropping support for
 architectures they stop caring about (or for commercial reasons)?  Say
 MIPS, s390, SPARC.  In that case, permanently ditching SysV init could
 put even some Linux ports in jeopardy.  Perhaps Upstart carries the same
 risk if Ubuntu releases only for i386/amd64/arm.
systemd upstream made clear some time ago that they aim to support
every architecture Linux is running on, and also aim for mobile and to
some extend embedded devices.
So I wouldn't worry about that. Patches for architecture support are
also welcomed.
Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny_NWfsy=ch1jmifpukggm_hz4kzrp_zzfx85w1npxa...@mail.gmail.com

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Russ Allbery

Steven Chamberlain ste...@pyro.eu.org writes:

 But that seems like the easiest way to not break what is already working
 in GNU/kFreeBSD, Hurd - and on users' own Linux systems if they have
 non-Debian software using SysV init scripts.

The last is unrelated.  Both systemd and upstart support SysV init scripts
just fine.

However, I, as a packager, want to stop writing and maintaining SysV init
scripts because they're awful.  One of the huge benefits of adopting a new
init system would be the ability to replace 100+ lines of buggy and tricky
shell code with 20 lines of straightforward, descriptive configuration,
which would be the case for many of the init scripts in Debian.

 Dismissing the ports as toy projects is not a compelling argument to me.

I intensely dislike that phrasing and don't use it.

However, making all package maintainers continue to go through the pain of
maintaining SysV init scripts to support Hurd and kFreeBSD doesn't strike
me as a good outcome.  One, I very much doubt that would actually happen
if such scripts were not required to make Debian on the major platforms
like amd64 and arm work properly.  And, two, making packaging harder
because of missing capabilities inside Debian is just fundamentally not
how we should be attempting to operate as a project.  We should instead
aim to bring the best technology to bear on the problem and move ahead as
a project.

 Just wondering, if systemd upstream cares only for Linux and that's
 considered okay, might they also start dropping support for
 architectures they stop caring about (or for commercial reasons)?  Say
 MIPS, s390, SPARC.  In that case, permanently ditching SysV init could
 put even some Linux ports in jeopardy.  Perhaps Upstart carries the same
 risk if Ubuntu releases only for i386/amd64/arm.

Most upstreams in Debian only care about and only test on amd64 and i386.
This is a problem that we've dealt with for years by porting, providing
patches, and encouraging maintainers to fix issues in the name of better
portability.  This by and large works provided that those architectures
can meet upstream halfway.

Where the architectures have not met upstream halfway by chronic lack of
such key components as effective threading systems or toolchain support,
we have dropped those architectures in the past.  See, for example, hppa
and alpha.

I expect that pattern to continue: we will try our best to port Debian as
broadly as possible, and we will occasionally give up on a porting target
(at least outside of the secondary debian-ports infrastructure) because
there's too much work to do and insufficient resources.

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


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

Re: Proposal: switch default desktop to xfce

2013-10-29 Thread Nikolaus Rath

Olaf Titz o...@bigred.inka.de writes:
 Aeh, are you sure? I think you missed my point. I'm not involved with
 any init system, nor a Debian developer, yet by developing some random
 app and having it depend on a specific init system, I could (according
 to you) make that init system unsuitable for Debian?

 You would surely make _your app_ unsuitable for use as a default.

That's what I would expect, but that's not what Neil is saying. Unless
my English has abandoned my completely, he explicitly says it would make
the depended-on init system unsuitable as a default for Debian.


Best,
Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«


--
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/87iowfohsh@rath.org

Bug#728251: ITP: volatility -- advanced memory forensics framework

2013-10-29 Thread Joao Eriberto Mota Filho

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho eribe...@eriberto.pro.br

* Package name: volatility
  Version : 2.3
  Upstream Author : Volatility Foundation volatil...@volatilityfoundation.org
* URL : https://code.google.com/p/volatility
* License : GPL2
  Programming Lang: Python
  Description : advanced memory forensics framework

 The Volatility Framework is a completely open collection of tools for the
 extraction of digital artifacts from volatile memory (RAM) samples. It is
 useful in forensics analysis. The extraction techniques are performed
 completely independent of the system being investigated but offer
 unprecedented visibilty into the runtime state of the system.
 .
 Volatility supports memory dumps from all major 32- and 64-bit Windows
 versions and service packs including XP, 2003 Server, Vista, Server 2008,
 Server 2008 R2, and Seven. Whether your memory dump is in raw format, a
 Microsoft crash dump, hibernation file, or virtual machine snapshot,
 Volatility is able to work with it.
 .
 Linux memory dumps in raw or LiME format is supported too. There are several
 plugins for analyzing 32- and 64-bit Linux kernels and distributions such as
 Debian, Ubuntu, OpenSuSE, Fedora, CentOS, and Mandrake.
 .
 Volatility support 38 versions of Mac OSX memory dumps from 10.5 to 10.8.3
 Mountain Lion, both 32- and 64-bit. Android phones with ARM processors are
 also supported.
 .
 These are some of the data that can be extracted:
.
- Image information (date, time, CPU count).
- Running processes.
- Open network sockets and connections.
- OS kernel modules loaded.
- Memory maps for each process.
- Executables samples.
- Command histories.
- Passwords, as LM/NTLM hashes and LSA secrets.
- Others.


-- 
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/20131029222129.4808.99268.report...@canopus.eriberto.pro.br

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Svante Signell

On Tue, 2013-10-29 at 00:51 -0700, Steve Langasek wrote:

  (Also, do remember that any decisive outcome other than “support
  multiple ones including systemd” and “systemd-only” will need to
  lead to the removal of GNOME from Debian.
 
 Absolutely not true.  As Tollef mentions in his follow-up, one of the
 options is to fork logind and maintain it.
 
 This is not an improbable outcome.  Logind is a good interface, and there's
 a lot of value in continuing to use it, regardless of what init system we
 choose.  If Debian chooses to ship upstart as the default, I will almost
 certainly be inteested in making sure that logind continues to be
 well-supported on top of upstart, in both Debian and Ubuntu.  The work to do
 this on Ubuntu has so far been straightforward; while there are some
 technical hurdles in the future for making logind continue to work on
 non-systemd systems, these are known issues and not at all insurmountable.


Some more systemd-login0 dependencies: 
apt-cache rdepends libsystemd-login0
weston
gnome-disk-utility

build-rdeps libsystemd-login-dev
(not only [linux-any])
gnome-disk-utility

gnome-disk-utility also depends on libudisks2-dev which depends on udev,
which is linux-any/built from systemd?, so this one might be impossible
outside linux anyway.

weston is Architecture: linux-any but
isn't it supposed to run on other architectures in the future?

Looks like systemd is creping in everywhere.

See also the problems with gdm3 not starting #724731, systemd-login0 and
libpam-systemd. That bug hit me too, on a brand new box as reported
earlier.


-- 
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/1383087069.11925.29.ca...@g3620.my.own.domain

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Carlos Alberto Lopez Perez

On 28/10/13 20:14, Christoph Anton Mitterer wrote:
 For those who haven't seen it, Lennart has posted some of his comments
 about all this on G+:
 https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf

And here is the reply from Gentoo developer Patrick Lauer:

http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt



signature.asc
Description: OpenPGP digital signature

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Russ Allbery

Carlos Alberto Lopez Perez clo...@igalia.com writes:
On 28/10/13 20:14, Christoph Anton Mitterer wrote:

For those who haven't seen it, Lennart has posted some of his comments
about all this on G+:
https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf

And here is the reply from Gentoo developer Patrick Lauer:

http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt

This, sadly, was not particularly useful or interesting. As near as I can
tell, the core content was that he doesn't think cgroup management is
particularly difficult (fine, but I don't think that was the point; the
point, instead, was that it's important to have a single arbitrator, which
if true poses specific technical challenges) and he believes that the
components to systemd would be easy to implement as separate daemons if
they were properly documented.

I'm one of those people who thinks that nearly everything in Linux is
horribly underdocumented, so I'm not going to argue with that point, but
it's not a very useful statement from a practical viewpoint. systemd
offers specific pieces of integrated functionality. By and large, no one
seems to question that the operations enabled by that functionality are
useful (although there is some debate over how useful). GNOME is not
depending on systemd out of some nefarious plot. It's depending on
systemd because GNOME wants to use those pieces of functionality systemd
provides.

Therefore, I think it's important for arguments against using systemd to
somehow engage directly with the questions about functionality. Either
there needs to be an argument that the functionality is not important and
can be done without (which raises questions about how one would build
GNOME in such an environment), or there needs to be some sort of plan for
how equivalent functionality to systemd will be provided.

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

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

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread John Paul Adrian Glaubitz

(Removing the ctte bug from CC to reduce noise)

On 10/29/2013 11:59 PM, Carlos Alberto Lopez Perez wrote:
 On 28/10/13 20:14, Christoph Anton Mitterer wrote:
 For those who haven't seen it, Lennart has posted some of his comments
 about all this on G+:
 https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf
 
 And here is the reply from Gentoo developer Patrick Lauer:
 
 http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt

People, I understand that this is quite heated discussion, but I do not
think it's a good idea to post such flame baits, both the one from
Lennart as well as Patrick's answer, to the tech-ctte bug report.

It's not really helping in making an unbiased decision, is it?

I think enough has been said on the topic already and the committee
should maybe left alone.

Cheers,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-10-29 Thread Steven Chamberlain

On 29/10/13 01:34, Steven Chamberlain wrote:
 Actually quite amazing how painless that was, though I most certainly
 don't expect it to be functional yet.

I have tested it now.  It's actually running and doing 'something'!  And
it is colourful.

I'm testing it inside of a BSD jail currently.  This is a remarkably
easy environment for debugging.  I can alternatively enter a fully
working bash shall or prod in the jail's chroot directly.

 # jail -J /var/run/jail/$JID.jid -c jid=$JID   name=jail$JID   
 path=/srv/jail/$JID   host.hostname=$HOSTNAME   ip4.addr=$IP   
 command=/sbin/rc sysinit
 
OpenRC 0.10.9429351 is starting up GNU/kFreeBSD 9.0-2-amd64-xenhvm (x86_64)
 
 mdconfig: ioctl(/dev/mdctl): Device or resource busy
 /libexec/rc/sh/init.sh: 18: /libexec/rc/sh/init-common-post.sh: newfs: not 
 found
 mount: /dev/md0 : Operation not permitted

I think it was trying to create a FreeBSD-style ramdisk, which is
probably not possible inside a jail.  May need to skip whatever it is
trying to do there, or pre-create a tmpfs inside the jail before I try
to boot it.

# jail -J /var/run/jail/$JID.jid -c jid=$JID   name=jail$JID
path=/srv/jail/$JID   host.hostname=$HOSTNAME   ip4.addr=$IP
command=/sbin/rc boot
  * Checking local filesystems  ...
 /libexec/rc/sh/runscript.sh: 90: /libexec/rc/sh/runscript.sh: fsck: not found
  * Filesystems couldn't be fixed  
   
[ !! ]
  * rc: Aborting!
  * fsck: caught SIGTERM, aborting

Indeed I do not have an fsck, since util-linux depends on initscripts
depends on sysv-rc so it disappeared.  This is unnecessary inside a jail
anyway.

That's as far as I got with this tonight, but just to let you know that
OpenRC is somewhat alive on GNU/kFreeBSD.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.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/527055be.6090...@pyro.eu.org

Re: porting OpenRC to Debian GNU/kFreeBSD (was: Bug#727708: tech-ctte: Decide which init system to default to in Debian.)

On 10/29/2013 09:34 AM, Steven Chamberlain wrote:
 Hi,
 
 On Sun, 27 Oct 2013 02:47:56 +0800 Thomas Goirand wrote:
 Note that OpenRC already works on some (non-Debian) BSD platforms, and
 that it should be trivial to have it to build on kFreeBSD and Hurd,
 
 And so I came up with the attached patch which gets it building on
 GNU/kFreeBSD, and it passed whatever tests are run during build.  I
 actually chose Linux implementations for most things, which are really
 provided by GNU libc or /proc.
 
 Actually quite amazing how painless that was, though I most certainly
 don't expect it to be functional yet.  (For example, I expect it still
 needs to know about linprocfs, linsysfs, tmpfs and maybe devfs).
 
 I look forward to seeing OpenRC in the Debian archive.  Thanks!
 
 Regards,

Hi,

Thanks a lot for this patch, it's been very helpful. I'm currently
working with upstream on #openrc on Freenode, trying to figure out how
to fix the build.

Indeed, the patch helps fixing the FTBFS, though that's not enough. It
fails to mount /run, because of a wrong (build) configuration which
makes it pick-up the Linux type of init.sh in /lib/rc/sh. I'm currently
working with upstream authors in #openrc (on Freenode) to fix this.

Feel free to join if you want.

Cheers,

Thomas Goirand (zigo)


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

Accepted tclgeoip 0.2-1.1 (source amd64)

2013-10-29 Thread Sergei Golovan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 09:40:56 +0400
Source: tclgeoip
Binary: tclgeoip
Architecture: source amd64
Version: 0.2-1.1
Distribution: unstable
Urgency: low
Maintainer: Djihed Afifi dji...@gmail.com
Changed-By: Sergei Golovan sgolo...@debian.org
Description: 
 tclgeoip   - Tcl extension implementing GeoIP lookup functions
Closes: 725259
Changes: 
 tclgeoip (0.2-1.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Build afeter the default Tcl/Tk version instead of the deprecated 8.4.
   (Closes: #725259)
Checksums-Sha1: 
 816d687bc88dff1fe21cd88da44743c936ba275f 1026 tclgeoip_0.2-1.1.dsc
 594bfb8ea0fbf6102166eb58459fcd1badcdd997 25769 tclgeoip_0.2-1.1.diff.gz
 e140b831178f232aee3829be909b05bf7fe2853d 9362 tclgeoip_0.2-1.1_amd64.deb
Checksums-Sha256: 
 3bc96c58eccc6fdf94042c3d1232ad3b6fc3c1caf923b04dc6ce9cacfa9dbc2a 1026 
tclgeoip_0.2-1.1.dsc
 67e641a9cf23f0cfe5c55aeb5435a849f11395f6247d4f4a659881bda6545a12 25769 
tclgeoip_0.2-1.1.diff.gz
 291736be29dc70443566a97182627aa1902d51768826e423fc0e5167e9bbfc38 9362 
tclgeoip_0.2-1.1_amd64.deb
Files: 
 b0d27fa15c3232e1dccb8a7958c8ddef 1026 interpreters optional 
tclgeoip_0.2-1.1.dsc
 1264f4ff758b2ee3354dd06dbd655fb7 25769 interpreters optional 
tclgeoip_0.2-1.1.diff.gz
 1830e0e570481ab593f034bfb7a4fc0e 9362 interpreters optional 
tclgeoip_0.2-1.1_amd64.deb

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

iD8DBQFSb014IcdH02pGEFIRAnZrAJ0REgXYg1FTETgDqABC6WYHjkOyLwCgmJ9t
t7217Gi1YMrr0a4gXkiPYN8=
=NARm
-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/e1vb2oh-0005jb...@franck.debian.org

Accepted emacspeak-ss 1.12.1-4 (source amd64)

2013-10-29 Thread Sergei Golovan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 10:09:19 +0400
Source: emacspeak-ss
Binary: emacspeak-ss
Architecture: source amd64
Version: 1.12.1-4
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group packa...@qa.debian.org
Changed-By: Sergei Golovan sgolo...@debian.org
Description: 
 emacspeak-ss - Emacspeak speech servers for several synthesizers
Closes: 725368
Changes: 
 emacspeak-ss (1.12.1-4) unstable; urgency=low
 .
   * QA upload.
   * Switched to the default Tcl version from deprecated 8.4 (Closes: #725368).
Checksums-Sha1: 
 d4c86700c7ada1f994e85c1a91b42e7f5a5fe0c8 1217 emacspeak-ss_1.12.1-4.dsc
 0f820be88ecec26387a7d8b06f5c1af970e7cc23 27841 
emacspeak-ss_1.12.1-4.debian.tar.gz
 a86f1092c67673a1854454872a7ff6eda653c805 51012 emacspeak-ss_1.12.1-4_amd64.deb
Checksums-Sha256: 
 3f34e533ce7458508e81fad5c024b971c8226644321f36a766d33b8db3c28138 1217 
emacspeak-ss_1.12.1-4.dsc
 d61edea89e2034c52fa18947fe7a6c1bc7d42804679cbb8f4a72ae1fd00da0e8 27841 
emacspeak-ss_1.12.1-4.debian.tar.gz
 0aafccb98097600abc75869292f7f18e90dfb2ddcf04b30f27a6477b655fe6ce 51012 
emacspeak-ss_1.12.1-4_amd64.deb
Files: 
 2e10438420619c8671f5e161fb6046a6 1217 editors extra emacspeak-ss_1.12.1-4.dsc
 e3f8ff408acde25ac48ca5ba4e1a5b79 27841 editors extra 
emacspeak-ss_1.12.1-4.debian.tar.gz
 e3faab5f06c26578f67304e08b5db1e4 51012 editors extra 
emacspeak-ss_1.12.1-4_amd64.deb

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

iD8DBQFSb1MsIcdH02pGEFIRAqL0AKCAdG7rzJ6Mb/zTKG0Rj8gy+rwnywCeM828
ezs0tIiPx87PmKn5vRa3mt0=
=e9Lt
-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/e1vb2re-0002ad...@franck.debian.org

Accepted netmaze 0.81+jpg0.82-14.1 (source amd64)

2013-10-29 Thread Sergei Golovan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 10:44:22 +0400
Source: netmaze
Binary: netmaze
Architecture: source amd64
Version: 0.81+jpg0.82-14.1
Distribution: unstable
Urgency: low
Maintainer: John Goerzen jgoer...@complete.org
Changed-By: Sergei Golovan sgolo...@debian.org
Description: 
 netmaze- 3-D Multiplayer Combat Game
Closes: 726040
Changes: 
 netmaze (0.81+jpg0.82-14.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Replace tk8.4 by tk8.5 in dpendencies and call wish8.5 instead of
 wish8.4 or wish. Closes: #726040.
   * Fix loading the Tix library.
Checksums-Sha1: 
 1aefb87ae8be793fc16a93ae4e374bfff1aad401 1121 netmaze_0.81+jpg0.82-14.1.dsc
 93909741ca57e8938c28352c7bc3b9356ca31cea 41271 
netmaze_0.81+jpg0.82-14.1.diff.gz
 2c0598321a8c4e101fc6eed894b6193d5d50a48e 262094 
netmaze_0.81+jpg0.82-14.1_amd64.deb
Checksums-Sha256: 
 9f913eb66dd2d40cafb9d7fe10263a329258737731ff979d11f8398ca6a54b75 1121 
netmaze_0.81+jpg0.82-14.1.dsc
 df41248af1e8664443c9c20ec7aaa4fa79afe28ad85a0fb24b4e5e09ada8cdee 41271 
netmaze_0.81+jpg0.82-14.1.diff.gz
 b4151fde012a8d4403b0cfb19c28cf2456b29ca322d4593656ea0a16ee227add 262094 
netmaze_0.81+jpg0.82-14.1_amd64.deb
Files: 
 0c44537fd8c976c99299a3828bbf16fb 1121 games optional 
netmaze_0.81+jpg0.82-14.1.dsc
 1031248bec653cf3524fff6655dfe2f2 41271 games optional 
netmaze_0.81+jpg0.82-14.1.diff.gz
 9110e4191ccd88c170263bf734bdd89c 262094 games optional 
netmaze_0.81+jpg0.82-14.1_amd64.deb

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

iD8DBQFSb1psIcdH02pGEFIRAue3AKCVvcguL+OsdnH8wJWZlLgIL4ePBQCfX8KM
kXX/+YI3psMSh6vvgtK1haM=
=7xGB
-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/e1vb3kr-0002an...@franck.debian.org

Accepted yade 1.05.0-1 (source amd64 all)

2013-10-29 Thread Anton Gladky

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 28 Oct 2013 20:55:21 +0100
Source: yade
Binary: yade libyade python-yade yade-doc
Architecture: source amd64 all
Version: 1.05.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Science Maintainers 
debian-science-maintain...@lists.alioth.debian.org
Changed-By: Anton Gladky gl...@debian.org
Description: 
 libyade- Platform for discrete element modeling. Libraries
 python-yade - Platform for discrete element modeling. Python bindings
 yade   - Platform for discrete element modeling
 yade-doc   - Platform for discrete element modeling. Documentation
Changes: 
 yade (1.05.0-1) unstable; urgency=low
 .
   * [8448883] Imported Upstream version 1.05.0
   * [82b3047] Do not use clang explicitly.
   * [2f28ccc] Remove -ftrack-macro-expansion=0 option.
Checksums-Sha1: 
 488563503fd763d39da095de6e1ab7132685dbdc 2882 yade_1.05.0-1.dsc
 cdb8fcc47102a692711fe7fa3e258d3b1679dacb 4762952 yade_1.05.0.orig.tar.gz
 04f6f4bf8dc2baa4b95aa505036e25eb39379efc 20459 yade_1.05.0-1.debian.tar.gz
 4ca1c85f76a0e262733355fc001ae3cd282a9c0e 1430008 yade_1.05.0-1_amd64.deb
 80426790db2c09a9b34260281a2251bbb60212b6 8100662 libyade_1.05.0-1_amd64.deb
 7d0eef907da368311f5a39fea182b60a33d73841 1870846 python-yade_1.05.0-1_amd64.deb
 176ca3b766498182dfd02174716d6292d775a575 6751984 yade-doc_1.05.0-1_all.deb
Checksums-Sha256: 
 67079d9214127d01152fa0e223923a58c8b45c28382d546fb486fa41d6346c63 2882 
yade_1.05.0-1.dsc
 94864ac0162eb645b76eeeda774fa1ca4a66fab1a4b7a7dbdd1926d0b4503bbe 4762952 
yade_1.05.0.orig.tar.gz
 c7ab3461044905cdcdd2ff6b733cfe95543652d007760bca1403868a4e70ec7f 20459 
yade_1.05.0-1.debian.tar.gz
 d528b9d71f619383ab0dc7f914fa593e1f93b9604abf4d6af50855460a002b2b 1430008 
yade_1.05.0-1_amd64.deb
 83cfde6c283c666545d962398df1a6cd7eed8a51d0ba1013be54c3ffbc7e26e6 8100662 
libyade_1.05.0-1_amd64.deb
 7a078f0c656f0840ee1d65651dd14e35e3619f14c3d791190f33f250ef889b2e 1870846 
python-yade_1.05.0-1_amd64.deb
 6db81e54c9a793c3a0b3006163c4e0de87e224bbcb9aa3fc64f10f805d9553ab 6751984 
yade-doc_1.05.0-1_all.deb
Files: 
 8651610f4505effe8d9338ef66b75868 2882 science extra yade_1.05.0-1.dsc
 d286686970b224ff9ee2e17952225576 4762952 science extra yade_1.05.0.orig.tar.gz
 d2579e0168e4aa214ab85de5f4e881d3 20459 science extra 
yade_1.05.0-1.debian.tar.gz
 15df126f15063ef6e85c1105d8f1f8c7 1430008 science extra yade_1.05.0-1_amd64.deb
 022fb68f1b30aebc854a1a891e7ef189 8100662 science extra 
libyade_1.05.0-1_amd64.deb
 77306e1145774937d71512726eebb035 1870846 python extra 
python-yade_1.05.0-1_amd64.deb
 056c05da2385a4b3d484879b2e00d6d1 6751984 doc extra yade-doc_1.05.0-1_all.deb

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

iQIcBAEBAgAGBQJSb1sLAAoJENPhc4PPp/8GivIP/A0iTJwPsIiCzr2adczPwGIT
H+Jtlbz8mBGgQ0DUujwH2HManrQ4qR0Zd3RDMkgTlxC2tBemY9uwfMlk+TNbXc7T
F2mIPd6gkIkjNfDKPi3dY5YMawtbYC6w7Ik1SdCcE/bBoE30tnEwaI6gyVeWIVF9
aOj5nW7NltHURc6uyZDDoMLn+vX24/XCqz0vodDQbiyLyrOLgVEZMvMh3KLOLFdr
ro1fx41j4imepHL3x7Z7tA/l3oAsZjr7QGKMDvzDeR6Q7qrX69J4wk0vAx7YDyF2
yBzHmCraGt1cQOK7PddfbWbS6bMw9Vo4ksYsy68cRAqBkLNfX7W7OXONnG6Czww6
/BLLRj/d3QAseiLeN92EmiLzXvChalX8Cl9upwb5BzQ81iQU9wLgd/j8GK29gCV6
pCbUA8D8Ca8Q/dadFnyZx/XeHK/ILbG5RhkYGoq5vyLOKhb/dQoZfa7SxwIM/Q5D
pgBTyaxqVXlTwFFqyyWeHqZ1hYprle+X4zXMPXQzu80qBtKCb76Yno8/omZaLRPJ
1UqhkKTQ4VZOFvkkHqKpWHD27E0atoZf/jOfz4ZweghIaR6IMsmWYvQ6kgGomk6h
ROh9xdPKuqvCTAdQjy8i41cf9ePE/aI0dX1FlRtdIFaSwnHXTgjdKkQhDWY4NcLg
XkMxOLUsojCqmQEUXZvH
=QTd6
-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/e1vb3lq-0002m2...@franck.debian.org

Accepted haskell-derive 2.5.13-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 28 Oct 2013 16:53:53 -0300
Source: haskell-derive
Binary: libghc-derive-dev libghc-derive-prof libghc-derive-doc 
haskell-derive-utils
Architecture: source all amd64
Version: 2.5.13-1
Distribution: unstable
Urgency: low
Maintainer: Debian Haskell Group 
pkg-haskell-maintain...@lists.alioth.debian.org
Changed-By: Raúl Benencia r...@kalgan.cc
Description: 
 haskell-derive-utils - Deriving instances for data types in Haskell
 libghc-derive-dev - Deriving instances for data types in 
Haskell${haskell:ShortBlurb}
 libghc-derive-doc - Deriving instances for data types in 
Haskell${haskell:ShortBlurb}
 libghc-derive-prof - Deriving instances for data types in 
Haskell${haskell:ShortBlurb}
Changes: 
 haskell-derive (2.5.13-1) unstable; urgency=low
 .
   [ Joachim Breitner ]
   * Adjust watch file to new hackage layout
 .
   [ Raúl Benencia ]
   * New upstream release
   * Depend on haskell-src-exts 1.14
Checksums-Sha1: 
 52e666061d574e60287cb898b400ebfbdb844208 2266 haskell-derive_2.5.13-1.dsc
 d69602031389a146486e9fa2914be3d24eb12f60 60968 
haskell-derive_2.5.13.orig.tar.gz
 1ffaf59a8d0835fe460972ee7482f4e26565bce6 3375 
haskell-derive_2.5.13-1.debian.tar.gz
 f537954e6531c7dce03c39a3c1f23936faadff1e 164390 
libghc-derive-doc_2.5.13-1_all.deb
 b22950d56a55d0d4d8f29d59626b346abe4fdd36 1118856 
libghc-derive-dev_2.5.13-1_amd64.deb
 a860b730e32eb54c2edb6fcb2f20db8b270cca2e 1087686 
libghc-derive-prof_2.5.13-1_amd64.deb
 fef26dfff415f4f0336c87b68d259dd1bb032063 1299670 
haskell-derive-utils_2.5.13-1_amd64.deb
Checksums-Sha256: 
 058de6abc7c1eca71084d1e6c2e3df1bdcbdfcca9c1f0891bf3a72bb4322d2de 2266 
haskell-derive_2.5.13-1.dsc
 91a9b2e2ab2faa1e7cddcfd28d3dac6411392c1bcccf8a7112304fa28d91bc52 60968 
haskell-derive_2.5.13.orig.tar.gz
 5c1b236f31e0232b1325c7e9652a0c66aaea914b28a9064ddf7e4b89d8a2e5c7 3375 
haskell-derive_2.5.13-1.debian.tar.gz
 b8e0763f36cfc8439606e7d1a801e39af8df84c871621ab899b576fb4b3a75af 164390 
libghc-derive-doc_2.5.13-1_all.deb
 217c0008ee233d3ea630cde4aaed45043ddeb0725ea5ee2e7b5a1ff87af2efbc 1118856 
libghc-derive-dev_2.5.13-1_amd64.deb
 1500448ab031851827ca213ea6794d45e4f460b7d2c8e1bbc08c8cb9842919b4 1087686 
libghc-derive-prof_2.5.13-1_amd64.deb
 581b53385ec828706aaba301ec1e62cd96171a314c940ced40a11c692d822f5b 1299670 
haskell-derive-utils_2.5.13-1_amd64.deb
Files: 
 b2d1e865184176f68a9da549d5268aa4 2266 haskell extra haskell-derive_2.5.13-1.dsc
 8ab68b1dc2ed081f0050807f7f2ec518 60968 haskell extra 
haskell-derive_2.5.13.orig.tar.gz
 9b2aa6a774157b0bc7487a8d9a525219 3375 haskell extra 
haskell-derive_2.5.13-1.debian.tar.gz
 8945de9073faae375096551427860c4a 164390 doc extra 
libghc-derive-doc_2.5.13-1_all.deb
 b7bd43df0a812f03443be0ced7f4d833 1118856 haskell extra 
libghc-derive-dev_2.5.13-1_amd64.deb
 b1f17a92a189e2e6d1543d7d37f38451 1087686 haskell extra 
libghc-derive-prof_2.5.13-1_amd64.deb
 8c436f01d5c66c8dcadbdfbcbd8579f5 1299670 misc extra 
haskell-derive-utils_2.5.13-1_amd64.deb

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

iEYEARECAAYFAlJvdcgACgkQ9ijrk0dDIGzYxQCfYW4A4zEybxP7LTd8EbVcGp6l
xPEAnAgZoXj6b8wOUWzxd9C+4jftZorI
=uDs8
-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/e1vb5rk-0002uv...@franck.debian.org

Accepted haskell-hoogle 4.2.23-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 28 Oct 2013 16:36:14 -0300
Source: haskell-hoogle
Binary: libghc-hoogle-dev libghc-hoogle-prof libghc-hoogle-doc hoogle
Architecture: source all amd64
Version: 4.2.23-1
Distribution: unstable
Urgency: low
Maintainer: Debian Haskell Group 
pkg-haskell-maintain...@lists.alioth.debian.org
Changed-By: Raúl Benencia r...@kalgan.cc
Description: 
 hoogle - Haskell API Search for Debian system
 libghc-hoogle-dev - Haskell API Search
 libghc-hoogle-doc - Haskell API Search; documentation
 libghc-hoogle-prof - Haskell API Search; profiling libraries
Changes: 
 haskell-hoogle (4.2.23-1) unstable; urgency=low
 .
   [ Joachim Breitner ]
   * Adjust watch file to new hackage layout
 .
   [ Raúl Benencia ]
   * New upstream release
   * Remove obsolete DM-Upload-Allowed control field
   * Add fix-extract-tarball.patch
   * Depend on haskell-src-exts 1.14
Checksums-Sha1: 
 7b4d3eb779d13f7e54b03644dc6911a21f1a2f9d 2820 haskell-hoogle_4.2.23-1.dsc
 579959e1f3fed0aea9a24733927454aa2db7e1b7 124408 
haskell-hoogle_4.2.23.orig.tar.gz
 8cf5c3484ac08e90176b1e41bbb293a1565d432e 177704 
haskell-hoogle_4.2.23-1.debian.tar.gz
 055da17ee5b8696aea42d16e1227db0b2b8bbf3d 112312 
libghc-hoogle-doc_4.2.23-1_all.deb
 33dd0670c23bbb11fb4a88e20eaa39aab7e134b8 737016 
libghc-hoogle-dev_4.2.23-1_amd64.deb
 9640fb9d2c475d514f6f5f27c9f5183eb210dec3 765036 
libghc-hoogle-prof_4.2.23-1_amd64.deb
 c36c9da348a56f663b1fe2c032b8daa2295b9a02 2335692 hoogle_4.2.23-1_amd64.deb
Checksums-Sha256: 
 af0f9275224691a8b688e3a7750bca8f2d878d24776d58b61f168451b05ebbcd 2820 
haskell-hoogle_4.2.23-1.dsc
 27463ff9d8f8d5368a43ccdd37fa15521124bb1d4577d87ed6ff0e66387072fa 124408 
haskell-hoogle_4.2.23.orig.tar.gz
 49127660b52cc0ab90e16a4254f1762882525de284653258b5b34b348ca442ad 177704 
haskell-hoogle_4.2.23-1.debian.tar.gz
 e8ca7ddbe49c33d85bffabbe9a494cf4fda3b78c258ef7992dad5619e0071227 112312 
libghc-hoogle-doc_4.2.23-1_all.deb
 f33db3bc6ea22a138581fa5523a1a5607d4f255e0c35a4bc5c7af526babe150b 737016 
libghc-hoogle-dev_4.2.23-1_amd64.deb
 7d753ae774b689bd51aca81ccef22c0d49f556369371941c73938f2c8299336b 765036 
libghc-hoogle-prof_4.2.23-1_amd64.deb
 d5fc4703c96cd7fcad8d64ce8e4477ed6969a33b3d0aa07a44d8f82bd71a87ad 2335692 
hoogle_4.2.23-1_amd64.deb
Files: 
 d5c6bfdd298a666bc6a6b56cfe8086a5 2820 haskell extra haskell-hoogle_4.2.23-1.dsc
 67429a201d7acbeb396cad125d0e9528 124408 haskell extra 
haskell-hoogle_4.2.23.orig.tar.gz
 93dc1aecd60f323fd848f5c7b5513dd9 177704 haskell extra 
haskell-hoogle_4.2.23-1.debian.tar.gz
 d25bcfc374a9a2f1001f8ca0e04dd7ff 112312 doc extra 
libghc-hoogle-doc_4.2.23-1_all.deb
 649bbf35b5e1a16b681dd277fc251a99 737016 haskell extra 
libghc-hoogle-dev_4.2.23-1_amd64.deb
 be149beb7a0c590c95c8c8708c793219 765036 haskell extra 
libghc-hoogle-prof_4.2.23-1_amd64.deb
 8cfd7f4bd13ff211b18953365a4b20ab 2335692 misc extra hoogle_4.2.23-1_amd64.deb

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

iEYEARECAAYFAlJvddoACgkQ9ijrk0dDIGxX5QCfYmoIAsRcIW1gmrkADhCJ3Gvp
+2cAnj5Ld8kzVwaowvMzwbCoUVIiiv05
=BXod
-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/e1vb5rv-00032c...@franck.debian.org

Accepted hlint 1.8.53-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 28 Oct 2013 16:58:34 -0300
Source: hlint
Binary: hlint libghc-hlint-dev libghc-hlint-prof libghc-hlint-doc
Architecture: source all amd64
Version: 1.8.53-1
Distribution: unstable
Urgency: low
Maintainer: Debian Haskell Group 
pkg-haskell-maintain...@lists.alioth.debian.org
Changed-By: Raúl Benencia r...@kalgan.cc
Description: 
 hlint  - Haskell source code suggestions
 libghc-hlint-dev - Haskell source code suggestions${haskell:ShortBlurb}
 libghc-hlint-doc - Haskell source code suggestions${haskell:ShortBlurb}
 libghc-hlint-prof - Haskell source code suggestions${haskell:ShortBlurb}
Closes: 727301
Changes: 
 hlint (1.8.53-1) unstable; urgency=low
 .
   [ Joachim Breitner ]
   * Adjust watch file to new hackage layout
   * Fix typo in descriptions, thanks to Marco Bodrato for spotting (Closes:
 #727301)
 .
   [ Raúl Benencia ]
   * New upstream release
   * Depend on haskell-src-exts 1.14
   * debian/control: Remove upper bound version constraints of some
 build dependencies
Checksums-Sha1: 
 436cc53da4f6c2383946b19d3ea6f7da8a372dae 1864 hlint_1.8.53-1.dsc
 c4410640a4cf6798f2a4d654400372f187acf116 70856 hlint_1.8.53.orig.tar.gz
 182c52778330b2052f1751035c2884fcff9306e0 4030 hlint_1.8.53-1.debian.tar.gz
 20688aa46514d7b1d502558d8b79a2d978adf15e 115088 
libghc-hlint-doc_1.8.53-1_all.deb
 17b8395bd3f7052cecfcc3d1c3711d238538f816 1411612 hlint_1.8.53-1_amd64.deb
 bd8d4035a34b12ba6573ed4b0b05591325b9e4f7 648192 
libghc-hlint-dev_1.8.53-1_amd64.deb
 e788c50c34ea9ce148fa9af6306a10328d911f30 656986 
libghc-hlint-prof_1.8.53-1_amd64.deb
Checksums-Sha256: 
 018923ac4cfcb9f20807d37514bcd95a7730bd72ef781ed6b8bebcee9dde2dc4 1864 
hlint_1.8.53-1.dsc
 009fe2817504c9d62de1be72dac7fd14397543aec99c751740eee104124cdbbe 70856 
hlint_1.8.53.orig.tar.gz
 5f0b6286e0b35ec3720cf517eaa145c14570fdc065dfc7cc73e7a6ad4644c96c 4030 
hlint_1.8.53-1.debian.tar.gz
 3fe49c14ec005674e4d544f733e5ce2d82d2b6bd2506458f6944914ec26f0820 115088 
libghc-hlint-doc_1.8.53-1_all.deb
 889361dc1bcd4952de88a40bee0b6484eb75606e599c79d20d8ce9446046494d 1411612 
hlint_1.8.53-1_amd64.deb
 0540175ec746eb70091ea0799ef0f9683c2c9e4f65e1975b3bc2571f2219 648192 
libghc-hlint-dev_1.8.53-1_amd64.deb
 bb144b4960ae5dd4da891e1550bd6f3823bcb0cfaa8b03acf56abfa44107b567 656986 
libghc-hlint-prof_1.8.53-1_amd64.deb
Files: 
 789192adffedbfdeb15ec014c8032e77 1864 haskell extra hlint_1.8.53-1.dsc
 9e6f4754f5ab74b59f9b763cf65d196b 70856 haskell extra hlint_1.8.53.orig.tar.gz
 800f023c1eb3d281f3a1aba4ed0c47e4 4030 haskell extra 
hlint_1.8.53-1.debian.tar.gz
 9bb6ae2832a1b0abb052ed11266834b6 115088 doc extra 
libghc-hlint-doc_1.8.53-1_all.deb
 125397b23eb003591df2c92ee6eabdcc 1411612 haskell extra hlint_1.8.53-1_amd64.deb
 27a616ef58a63f52c70eae46320240d8 648192 haskell extra 
libghc-hlint-dev_1.8.53-1_amd64.deb
 d39067365646c4d3fb164764bca534ab 656986 haskell extra 
libghc-hlint-prof_1.8.53-1_amd64.deb

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

iEYEARECAAYFAlJvdgYACgkQ9ijrk0dDIGwooQCgmqyDFqvikZxSyBKstRn+Yvp7
rrwAn18PkaXkjnErrGuz9CLQ48DQXax3
=FOIQ
-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/e1vb5sr-0003m1...@franck.debian.org

Accepted knot 1.3.3-1 (source amd64 all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 28 Oct 2013 11:40:13 +0100
Source: knot
Binary: knot knot-dbg knot-dnsutils knot-host knot-doc
Architecture: source amd64 all
Version: 1.3.3-1
Distribution: unstable
Urgency: low
Maintainer: Ondřej Surý ond...@debian.org
Changed-By: Ondřej Surý ond...@debian.org
Description: 
 knot   - authoritative domain name server
 knot-dbg   - Debug symbols for Knot DNS
 knot-dnsutils - Clients provided with Knot DNS (kdig, knslookup, knsupdate)
 knot-doc   - Documentation for Knot DNS
 knot-host  - Version of 'host' bundled with Knot DNS
Changes: 
 knot (1.3.3-1) unstable; urgency=low
 .
   * New upstream version 1.3.3
Checksums-Sha1: 
 62551acd549fe6e55da87d7ea8485fe0b361c79c 1390 knot_1.3.3-1.dsc
 5890f5f64b3960ab1b2e5a91813fd49b963700a4 801764 knot_1.3.3.orig.tar.xz
 9907085176a048fbe2b09ceda3049d30c0d27b06 12501 knot_1.3.3-1.debian.tar.gz
 11b70abeaf3e21538d244eb8f2782992f044d5f3 364660 knot_1.3.3-1_amd64.deb
 bea88288a0c3bee6b2528fd1f18d61c88f6f0c56 3011284 knot-dbg_1.3.3-1_amd64.deb
 1a0b05dd5c03779e7ec189a51d955ccef5e50add 227470 knot-dnsutils_1.3.3-1_amd64.deb
 58f37990b5a4bd0e3d584ce3259b814b8f89ee1c 194654 knot-host_1.3.3-1_amd64.deb
 c24b0e747d7f3bcf098345923bc457fb1472aef1 298262 knot-doc_1.3.3-1_all.deb
Checksums-Sha256: 
 40dbc67be78b62b6997021e81e86f27b7bcb29ef613970f79db297ed1edeb032 1390 
knot_1.3.3-1.dsc
 003f38ff9f2246a2a72c67291e8ba1305bf903758f0a234298045b203ad5be47 801764 
knot_1.3.3.orig.tar.xz
 90a3e6e5aa829c6d3ac38959658f998df7b6d6a9a94bd36efe8145b46ea5b9c1 12501 
knot_1.3.3-1.debian.tar.gz
 a0ba6b7b623f2fdb2992615f4210cdb9b1511401d29675309a17c3aa55041372 364660 
knot_1.3.3-1_amd64.deb
 9e5b14cb09e9d6c535e84cca698063ba702d733801100b9dcfc8f172a0f59d78 3011284 
knot-dbg_1.3.3-1_amd64.deb
 6ff26a4be3d3132b3bee4ade1941502877dcb93526290b131fb46a29fbdefd53 227470 
knot-dnsutils_1.3.3-1_amd64.deb
 838a91524dbf082434cbd1fa4048ce13ac6a7f87688b2402e7b1ba8a7f5c6f6a 194654 
knot-host_1.3.3-1_amd64.deb
 c20ed9b4e2550ad6fb86ba3dc976c12935bf408f81886be5155457cf9130c647 298262 
knot-doc_1.3.3-1_all.deb
Files: 
 f56cbc196c7ef1cf7c89b7ec8c222528 1390 net extra knot_1.3.3-1.dsc
 4ebdd30d29bbeb4d0d2eb403202007fb 801764 net extra knot_1.3.3.orig.tar.xz
 65f03aa17751b145728d2dce33b6e74a 12501 net extra knot_1.3.3-1.debian.tar.gz
 decacd6e763528ab0e7dcd937b27a173 364660 net extra knot_1.3.3-1_amd64.deb
 65a901b987a525cf855df4e4ab272989 3011284 debug extra knot-dbg_1.3.3-1_amd64.deb
 9b06ca59cbdb4477866b7b94272dea52 227470 net optional 
knot-dnsutils_1.3.3-1_amd64.deb
 b97984ed53c6ef8d864c0dec5758052a 194654 net optional 
knot-host_1.3.3-1_amd64.deb
 a74ef63152e433d744409e3b2354be06 298262 doc optional knot-doc_1.3.3-1_all.deb

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

iEYEARECAAYFAlJvc8cACgkQ9OZqfMIN8nMF7wCgnOLZ8uaGLtk4Y+WhrbCSm14G
zLIAnRoeXigSrO9pxcWQlnK2I0KPPXmO
=mnEf
-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/e1vb5se-0003u9...@franck.debian.org

Accepted haskell-src-meta 0.6.0.4-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 28 Oct 2013 16:50:07 -0300
Source: haskell-src-meta
Binary: libghc-src-meta-dev libghc-src-meta-prof libghc-src-meta-doc
Architecture: source all amd64
Version: 0.6.0.4-1
Distribution: unstable
Urgency: low
Maintainer: Debian Haskell Group 
pkg-haskell-maintain...@lists.alioth.debian.org
Changed-By: Raúl Benencia r...@kalgan.cc
Description: 
 libghc-src-meta-dev - ${haskell:ShortDescription}${haskell:ShortBlurb}
 libghc-src-meta-doc - ${haskell:ShortDescription}${haskell:ShortBlurb}
 libghc-src-meta-prof - ${haskell:ShortDescription}${haskell:ShortBlurb}
Changes: 
 haskell-src-meta (0.6.0.4-1) unstable; urgency=low
 .
   [ Joachim Breitner ]
   * Adjust watch file to new hackage layout
 .
   [ Raúl Benencia ]
   * New upstream release
   * Depend on haskell-src-exts 1.14
Checksums-Sha1: 
 20301aa61e7c1c025e73fc387587e3de81db5ba6 1915 haskell-src-meta_0.6.0.4-1.dsc
 980912c8b30bb981b3964a26d5ca3486c442b100 19187 
haskell-src-meta_0.6.0.4.orig.tar.gz
 c1fd8dd4aa1d11724d306355f48da48464ec7f1a 2603 
haskell-src-meta_0.6.0.4-1.debian.tar.gz
 3ccdc03e8e598bcdcd18dfb8aee2a2ed5333cde1 58282 
libghc-src-meta-doc_0.6.0.4-1_all.deb
 419941907b539b2cc37f635879ed0d6f0294c2fa 108108 
libghc-src-meta-dev_0.6.0.4-1_amd64.deb
 d393641a21048391531a42db2b17a384702a73c1 111206 
libghc-src-meta-prof_0.6.0.4-1_amd64.deb
Checksums-Sha256: 
 34cf140c8231a6a378bbd533795b1b1b51b95854d47234c57120f9d19a30c874 1915 
haskell-src-meta_0.6.0.4-1.dsc
 3db0c08642fbf99bca23fda8ce0120a130a8c26d7cb819b9550ccca584ebb181 19187 
haskell-src-meta_0.6.0.4.orig.tar.gz
 9e7864e813b091279a69cf1254647373f1036a3465786e4c8b583c44366a33f0 2603 
haskell-src-meta_0.6.0.4-1.debian.tar.gz
 838c9669b60267d13f6621a826cea24dccc41b194c1cecf5378444b390e09e2b 58282 
libghc-src-meta-doc_0.6.0.4-1_all.deb
 8605e383f6ce5237f76725bcfcc6c160c4b6643fa343f27bd8f090ca28d3c627 108108 
libghc-src-meta-dev_0.6.0.4-1_amd64.deb
 071eb9207cd4ee9f896b00dfc523d38de12536f3ff639812c039d4968362df92 111206 
libghc-src-meta-prof_0.6.0.4-1_amd64.deb
Files: 
 e9488583f76bfdd08bd7dc1da6ae2192 1915 haskell extra 
haskell-src-meta_0.6.0.4-1.dsc
 8c72b4afc69a1d8746c5862fe0fc2f2e 19187 haskell extra 
haskell-src-meta_0.6.0.4.orig.tar.gz
 315b16d539def658aeb2d98ceb7a1b9b 2603 haskell extra 
haskell-src-meta_0.6.0.4-1.debian.tar.gz
 07ef27de5b20b390bfb74b209c534962 58282 doc extra 
libghc-src-meta-doc_0.6.0.4-1_all.deb
 e45a80ec2890c30d8b11f4f949c24338 108108 haskell extra 
libghc-src-meta-dev_0.6.0.4-1_amd64.deb
 c1ce9df1e95c21a6e4095409a42e6be0 111206 haskell extra 
libghc-src-meta-prof_0.6.0.4-1_amd64.deb

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

iEYEARECAAYFAlJvdf0ACgkQ9ijrk0dDIGziAwCg1kL1pe25ELEHfykiJFMpiNsv
we4AnAvARonNhVJekf+2UmhQs1QDOuct
=IK1z
-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/e1vb5sh-0003fc...@franck.debian.org

Accepted haskell-src-exts 1.14.0-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 28 Oct 2013 15:45:46 -0300
Source: haskell-src-exts
Binary: libghc-src-exts-dev libghc-src-exts-prof libghc-src-exts-doc
Architecture: source all amd64
Version: 1.14.0-1
Distribution: unstable
Urgency: low
Maintainer: Debian Haskell Group 
pkg-haskell-maintain...@lists.alioth.debian.org
Changed-By: Raúl Benencia r...@kalgan.cc
Description: 
 libghc-src-exts-dev - Haskell-Source with eXtensions library for 
GHC${haskell:ShortBlur
 libghc-src-exts-doc - API documentation of the haskell-src-exts 
library${haskell:ShortB
 libghc-src-exts-prof - Haskell-Source with eXtensions library for 
GHC${haskell:ShortBlur
Changes: 
 haskell-src-exts (1.14.0-1) unstable; urgency=low
 .
   [ Joachim Breitner ]
   * Adjust watch file to new hackage layout
 .
   [ Raúl Benencia ]
   * New upstream release
Checksums-Sha1: 
 c846d4e0626c78bbdffe307b939684277be62637 1671 haskell-src-exts_1.14.0-1.dsc
 cd16ed18f18fd83083be9ce44ba7851426b1ec43 291256 
haskell-src-exts_1.14.0.orig.tar.gz
 fa40eda83e2783de3b4ce2ef7c29366a2422d1f0 6571 
haskell-src-exts_1.14.0-1.debian.tar.gz
 1ee9bca09b3a6a486a0818d42af05d8d84a03931 388500 
libghc-src-exts-doc_1.14.0-1_all.deb
 2287b7a8a5a818e7908f259450a6969f87686efa 3943908 
libghc-src-exts-dev_1.14.0-1_amd64.deb
 ac7dfb67c924bd65ffcfe86f1adade09de63485a 4172632 
libghc-src-exts-prof_1.14.0-1_amd64.deb
Checksums-Sha256: 
 5d5cbd0f8c15630295066e0248318597bdb88afae3ed0a0c5d40d49c1c714f67 1671 
haskell-src-exts_1.14.0-1.dsc
 0de416845e5ccc284aef029cbde25f5d289be464bcecaa28cb9e7753b886131c 291256 
haskell-src-exts_1.14.0.orig.tar.gz
 acc836f78ac4eda2cefed0590e58cd6a43ff3087e24866d9cd14167a399b94f8 6571 
haskell-src-exts_1.14.0-1.debian.tar.gz
 529a5ed2fc969ae992ae75a92ac5ceea5c4b5aa7eace530892c2c186d2f19540 388500 
libghc-src-exts-doc_1.14.0-1_all.deb
 6546347d7f72d3c062b1142488063fc85fb0b2e38f02e9c709946a8c93f2d229 3943908 
libghc-src-exts-dev_1.14.0-1_amd64.deb
 d18de6982aa5965738497bc32a1342189cda8724fe3f0b87d85ab5dd8534bdd6 4172632 
libghc-src-exts-prof_1.14.0-1_amd64.deb
Files: 
 ae103e70f89dfbde1803b48d20607813 1671 haskell extra 
haskell-src-exts_1.14.0-1.dsc
 84161d1a446c2ddfd1013e9a7b60b03c 291256 haskell extra 
haskell-src-exts_1.14.0.orig.tar.gz
 4265c57d2ccb795d02a61cca57315452 6571 haskell extra 
haskell-src-exts_1.14.0-1.debian.tar.gz
 2681a1e1504116b2f7b09486d5d3a3a0 388500 doc extra 
libghc-src-exts-doc_1.14.0-1_all.deb
 c4c9847eb519e0215b9362071fe1a43e 3943908 haskell extra 
libghc-src-exts-dev_1.14.0-1_amd64.deb
 075b21770fe65c923bd2f7e92a179b6f 4172632 haskell extra 
libghc-src-exts-prof_1.14.0-1_amd64.deb

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

iEYEARECAAYFAlJvdesACgkQ9ijrk0dDIGwVIQCgirgXY8CzMOmhztLY8/fFm6zk
HkMAoJdhD7nyCTdiGofuYJjVuGJ04LPj
=Xp23
-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/e1vb5s7-00039q...@franck.debian.org

Accepted tofrodos 1.7.13+ds-1 (source i386)

2013-10-29 Thread Markus Koschany

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 29 Oct 2013 09:22:17 +0100
Source: tofrodos
Binary: tofrodos
Architecture: source i386
Version: 1.7.13+ds-1
Distribution: unstable
Urgency: low
Maintainer: Markus Koschany a...@gambaru.de
Changed-By: Markus Koschany a...@gambaru.de
Description: 
 tofrodos   - Converts DOS - Unix text files, alias tofromdos
Closes: 645830 692421 726553
Changes: 
 tofrodos (1.7.13+ds-1) unstable; urgency=low
 .
   [ Alexander Reichle-Schmehl ]
   * Fix last changelog entry, remove the NOT RELEASED YET entry.
 (Closes: #645830) Thanks to Josh Triplett for noticing!
 .
   [ Markus Koschany ]
   * New Maintainer. (Closes: #726553)
   * New upstream release. (Closes: #692421)
 - Drop FTBFS_non-linux.patch. Merged upstream.
   * Switch to source format 3.0.
   * Bump compat level to 9 and require debhelper = 9.
   * Bump Standards-Version to 3.9.5, no changes.
   * Improve watch file. Thanks to Bart Martens.
   * Drop README.source and build dependency on quilt. Source format 3.0 uses
 quilt by default.
   * Drop NEWS file because it is obsolete.
   * Register tofrodos.html with doc-base.
   * Switch to dh sequencer.
   * Add a get-orig-source target to debian/rules.
   * Enable all hardening build flags.
   * debian/control:
 - Maintain tofrodos in a Git repository. Change VCS-fields accordingly.
 - Drop Conflicts field in debian/control. It is obsolete.
   * Update debian/copyright to copyright format 1.0.
Checksums-Sha1: 
 d7e94cd5ea483d239caa3772692dcb518cd19bb1 1880 tofrodos_1.7.13+ds-1.dsc
 2945fb5d933bde933ad2c2b7f8de8c0d266d88d4 31972 tofrodos_1.7.13+ds.orig.tar.xz
 d3cf48e4cac49d29980308fc40e100dc5b332b11 6247 
tofrodos_1.7.13+ds-1.debian.tar.gz
 5918ee427cd160d8f6a855462d9332f249d35321 22208 tofrodos_1.7.13+ds-1_i386.deb
Checksums-Sha256: 
 e1929352a5746c5afef5fb4ac8b0fa538a0b4943acf80dc30bd3425d5ffb47ce 1880 
tofrodos_1.7.13+ds-1.dsc
 c1c33f3f0b9e8152aa5790d233e8f1e8de14510433a6143ec582eba0fb6cbfaa 31972 
tofrodos_1.7.13+ds.orig.tar.xz
 fed49e4e35a213f800489501e2411f2b1e8f2ee134f0e7b09ea81fc59b6bae45 6247 
tofrodos_1.7.13+ds-1.debian.tar.gz
 c74e7fe0aa5fa7bfbf0d3f9ae322fef232e4749ffa45447e3d5689941f32c544 22208 
tofrodos_1.7.13+ds-1_i386.deb
Files: 
 4552498edb5af2eb2648ecad178e50b1 1880 utils optional tofrodos_1.7.13+ds-1.dsc
 bd2ebcc426ab59216b6a95c2945c909c 31972 utils optional 
tofrodos_1.7.13+ds.orig.tar.xz
 3d666b4bbed119c941331490dbab2092 6247 utils optional 
tofrodos_1.7.13+ds-1.debian.tar.gz
 b5150c6af77ba98d6433ad1d4a52eef8 22208 utils optional 
tofrodos_1.7.13+ds-1_i386.deb

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

iQIcBAEBCAAGBQJSb34uAAoJEG6k0jEaLSaNKEEQAI0tTD8/JCK8KOBubiC9ielI
PKiTuqhL69AMP3bfuZekskb+tVStYocIJsR2Gr7x+lVGUsST+xSE7hTM3I8Wil7b
iYEu44tGWusKRkSpwf2By4KUVosNvFnrSjoXS8WFHy7gTVPI/0Mkx8B1jYsgn6I7
kV4JpM6RVXUniKTjD1CKt70i8zIbesXPOMO+D36xEJTxXKrMb9wuq+buu9Txt20x
Xzx4VarWjy89vX8zFL0m0GTkDuFusLNqzyDthPLfekP6pSax21pRT20Rr/LzQcSr
BM6uRMKxMF8h+XmdXDq7CghJCRR+1NtgS+RNLVWNYQXeZtO9KqrHlFUGq319E9/U
cGMLrNlScieaP+rpd7HkdU11zosJvaygB9i1Y04A/vpo9kk6RAPL0DqWCUHrcpvX
dU2F5XMIdGk4ycVeEibxosk7AxtILqzuue8Hi0zT2kW6jBrS0h53NWVeZd5pBr5H
cI3FKa1q6JxmtwjgrSUCb8yVgZ0+YdTU+5N7FYBDH2heaep8MpdPX/cY+sMy/PlV
t2hzqBEsCiw7w6WSL7VkuWEfq2+yOnX5TE+FEfmjOMM6FxS+CL9W+Q1qWJNvMoJg
QOysEseokyPxbo4ubpLkUHUVuwiGiCKBRWugSxsfw9xOpYsygto1ruDvGXLVnsnR
8Y7m2x8FymKK+/qdp8dC
=HXtq
-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/e1vb5gk-9j...@franck.debian.org

Accepted r-cran-rcppeigen 0.3.1.2.3-1 (source i386)

2013-10-29 Thread Dirk Eddelbuettel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 06:30:00 -0500
Source: r-cran-rcppeigen
Binary: r-cran-rcppeigen
Architecture: source i386
Version: 0.3.1.2.3-1
Distribution: unstable
Urgency: low
Maintainer: Dirk Eddelbuettel e...@debian.org
Changed-By: Dirk Eddelbuettel e...@debian.org
Description: 
 r-cran-rcppeigen - GNU R package for Eigen templated linear algebra
Changes: 
 r-cran-rcppeigen (0.3.1.2.3-1) unstable; urgency=low
 .
   * New upstream release
 .
   * debian/control: Set Build-Depends: to current R version
   * debian/control: Set Standards-Version: to current version
 .
   * debian/control: Update Build-Depends: to r-cran-matrix (= 1.1-0)
Checksums-Sha1: 
 30242bfb9ebc2b945028be128aadcb60f14f6861 1162 r-cran-rcppeigen_0.3.1.2.3-1.dsc
 11ce6ceb4ca3d5a643da88868f271f213fda2f84 1123499 
r-cran-rcppeigen_0.3.1.2.3.orig.tar.gz
 1d29248e57fb6e140bd80500df8266c7fe1d41c7 9630 
r-cran-rcppeigen_0.3.1.2.3-1.diff.gz
 866c85dc70a27ec03c7adb1f6ccbbc60ee426cea 954424 
r-cran-rcppeigen_0.3.1.2.3-1_i386.deb
Checksums-Sha256: 
 40dac9e6fa447a42ca993217037d158b39912147cd2a3a8191bddc60cdadd837 1162 
r-cran-rcppeigen_0.3.1.2.3-1.dsc
 7f9a7ab0b45dfd49f1fabef1cd88d6d7942db7d37fce6d7528099efcf28a0f7b 1123499 
r-cran-rcppeigen_0.3.1.2.3.orig.tar.gz
 df56623dfa3970730fc408bca421cecd308206c5559211082430691b370a8ac4 9630 
r-cran-rcppeigen_0.3.1.2.3-1.diff.gz
 9575dd1ef0d82fa6f8ea0512027659743c1a119dcf9aa542cbd9935f47e459d2 954424 
r-cran-rcppeigen_0.3.1.2.3-1_i386.deb
Files: 
 460cd3d2b4f038d18bccd42c07588da6 1162 gnu-r optional 
r-cran-rcppeigen_0.3.1.2.3-1.dsc
 5747cd8ba2b8651b097e024ba7fd4c6c 1123499 gnu-r optional 
r-cran-rcppeigen_0.3.1.2.3.orig.tar.gz
 37476e6ba646351a87ce179d3749208f 9630 gnu-r optional 
r-cran-rcppeigen_0.3.1.2.3-1.diff.gz
 c4001f7066ec9a0992f291d46b653dd8 954424 gnu-r optional 
r-cran-rcppeigen_0.3.1.2.3-1_i386.deb

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

iD8DBQFSb5yICZSR95Gw07cRAlfWAJ9c4chEn559sGAKSLcUiyvqf6CywwCfZI2L
SS9Hk1S37Ju0ntEW5OQg7yI=
=f0gZ
-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/e1vb7ma-0005wn...@franck.debian.org

Accepted knot 1.4.0~beta-1 (source amd64 all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 12:25:49 +0100
Source: knot
Binary: knot knot-dbg knot-dnsutils knot-host knot-doc
Architecture: source amd64 all
Version: 1.4.0~beta-1
Distribution: experimental
Urgency: low
Maintainer: Ondřej Surý ond...@debian.org
Changed-By: Ondřej Surý ond...@debian.org
Description: 
 knot   - authoritative domain name server
 knot-dbg   - Debug symbols for Knot DNS
 knot-dnsutils - Clients provided with Knot DNS (kdig, knslookup, knsupdate)
 knot-doc   - Documentation for Knot DNS
 knot-host  - Version of 'host' bundled with Knot DNS
Changes: 
 knot (1.4.0~beta-1) experimental; urgency=low
 .
   * New upstream version 1.4.0~beta
   * Update patches for 1.4.0~beta release
   * Disable fastparser since the ragel is broken in one test
   * Add knsec3hash to knot package
Checksums-Sha1: 
 032c22379780f93ce295b9e215ad6dbdc37113ad 1425 knot_1.4.0~beta-1.dsc
 4659d1b22d34d8cfd75124cba640f51702458c94 823300 knot_1.4.0~beta.orig.tar.xz
 79a16ee472bea5f427490c82f50555472c1f8114 12664 knot_1.4.0~beta-1.debian.tar.gz
 8508c02068b2cf064cc0b0cbed7485908d8250d9 302228 knot_1.4.0~beta-1_amd64.deb
 be959443ef67ab5b6421ce8cd2d7c92f920856df 2247148 
knot-dbg_1.4.0~beta-1_amd64.deb
 22eef1e6840444717c29498667fbac3e64d443e2 126144 
knot-dnsutils_1.4.0~beta-1_amd64.deb
 c64090e0e8f1849aab6c9cfefee4c2d72ce43135 106298 
knot-host_1.4.0~beta-1_amd64.deb
 9f203fb1f1ae54ce0a6d02145f562b553507cd3b 307570 knot-doc_1.4.0~beta-1_all.deb
Checksums-Sha256: 
 41c878b85b554966ba4f81c028ec697e70cd347d57ee439f6e169da6fadf8411 1425 
knot_1.4.0~beta-1.dsc
 bba4e39f9d02b6f74b46c75312a762d59ea29f1f2b2f5660dc8db998d3d3233c 823300 
knot_1.4.0~beta.orig.tar.xz
 186759cd1cfe242acbfb13b0b2f224148e3a5f3c83089d3a5e04a0d3a2610ae9 12664 
knot_1.4.0~beta-1.debian.tar.gz
 460475b3b2baf4556109bdbde8ac4a02137904944455e2d6ee36d7bc22978ce6 302228 
knot_1.4.0~beta-1_amd64.deb
 225486a77b177a2987b3f7b4a4ddbfd715a8b29ee9e6c0f5ff7343a6accd54c9 2247148 
knot-dbg_1.4.0~beta-1_amd64.deb
 d2d62888dec3b93e1aa30891ea8c2691f73cc8175b7d9c07ec2f167018440199 126144 
knot-dnsutils_1.4.0~beta-1_amd64.deb
 ed43ed6cde6f2fa9a80924c353add5e63b528f0c5b16c0b0a7b43a7be670b648 106298 
knot-host_1.4.0~beta-1_amd64.deb
 e80be22a9dccbc55baed59ef9e6dc736581aa7b694de44124bb15ee774e9a95c 307570 
knot-doc_1.4.0~beta-1_all.deb
Files: 
 6407c3063efba2c63facc9e4551c595d 1425 net extra knot_1.4.0~beta-1.dsc
 c52f8f4bc95b490a7f747eac357454ce 823300 net extra knot_1.4.0~beta.orig.tar.xz
 36e7110258d81aa6494f5ad1527444fe 12664 net extra 
knot_1.4.0~beta-1.debian.tar.gz
 fd5f118fbb45cb278df293c2f14f5042 302228 net extra knot_1.4.0~beta-1_amd64.deb
 b8823f36e79fd7e30f4a127a903dc282 2247148 debug extra 
knot-dbg_1.4.0~beta-1_amd64.deb
 0c7fb3922329f43a563ceffd90a3d8d8 126144 net optional 
knot-dnsutils_1.4.0~beta-1_amd64.deb
 71914aede3b005a8a6804a359e8cefb8 106298 net optional 
knot-host_1.4.0~beta-1_amd64.deb
 8c1bd875b1b796713cbb4881525a24e5 307570 doc optional 
knot-doc_1.4.0~beta-1_all.deb

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

iEYEARECAAYFAlJvoz8ACgkQ9OZqfMIN8nODGgCfRjfm2x6POYILwYnj1R/2wCzL
OUcAn1suzuHwCjP1qikhzVpbYyIVJu+v
=XYr/
-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/e1vb8fd-0002r2...@franck.debian.org

Accepted ekg2 1:0.4~pre+20120506.1-2 (source amd64 all)

2013-10-29 Thread Marcin Owsiany

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 29 Oct 2013 13:17:10 +0100
Source: ekg2
Binary: ekg2-core ekg2 ekg2-api-docs ekg2-dbg ekg2-gnupg ekg2-jabber 
ekg2-scripting-python ekg2-scripting-perl ekg2-ui-gtk ekg2-ui-ncurses
Architecture: source amd64 all
Version: 1:0.4~pre+20120506.1-2
Distribution: experimental
Urgency: low
Maintainer: Marcin Owsiany porri...@debian.org
Changed-By: Marcin Owsiany porri...@debian.org
Description: 
 ekg2   - instant messenger and IRC client for UNIX systems
 ekg2-api-docs - instant messenger and IRC client for UNIX systems - API 
documenta
 ekg2-core  - instant messenger and IRC client for UNIX systems - main program
 ekg2-dbg   - instant messenger and IRC client for UNIX systems - debugging sym
 ekg2-gnupg - instant messenger and IRC client for UNIX systems - GnuPG
 ekg2-jabber - instant messenger and IRC client for UNIX systems - Jabber/XMPP
 ekg2-scripting-perl - instant messenger and IRC client for UNIX systems - Perl 
scriptin
 ekg2-scripting-python - instant messenger and IRC client for UNIX systems - 
Python script
 ekg2-ui-gtk - instant messenger and IRC client for UNIX systems - GTK+ interfac
 ekg2-ui-ncurses - instant messenger and IRC client for UNIX systems - ncurses 
inter
Closes: 618716
Changes: 
 ekg2 (1:0.4~pre+20120506.1-2) experimental; urgency=low
 .
   * Fix varargs handling to build on arm (Closes: #618716)
Checksums-Sha1: 
 3dc08c4e74b4066453768706f70a4c7a30ed24da 2679 ekg2_0.4~pre+20120506.1-2.dsc
 cf6ac3110473bc91c6253de167c20a441027a03e 21040 
ekg2_0.4~pre+20120506.1-2.debian.tar.gz
 d020dd38eb9b5cac5adad02632b97867cd226623 449452 
ekg2-core_0.4~pre+20120506.1-2_amd64.deb
 59a764647be99c9164b65d667be9e08eb72353c1 1324 
ekg2_0.4~pre+20120506.1-2_amd64.deb
 27254de1db1d7afd41ba2d230ffc288890690fb3 1145134 
ekg2-api-docs_0.4~pre+20120506.1-2_all.deb
 2ed1c2e0ab0b805a85aa736d4ecb8c22ed9de2a7 1153986 
ekg2-dbg_0.4~pre+20120506.1-2_amd64.deb
 a96e0d1d016e448d58642e3ea6f15e28952fff4d 9816 
ekg2-gnupg_0.4~pre+20120506.1-2_amd64.deb
 7b3fdb25bca39b1f61967233495a711ba688a130 78876 
ekg2-jabber_0.4~pre+20120506.1-2_amd64.deb
 807c04ceef5c81298bfc7a5b4b2bb60ee586b74c 18642 
ekg2-scripting-python_0.4~pre+20120506.1-2_amd64.deb
 66d961b751ec416ae8edc5af9711c3bc16b3ece5 51620 
ekg2-scripting-perl_0.4~pre+20120506.1-2_amd64.deb
 99290b56e2c3f6788c983b1f0a3b2e833f380823 71062 
ekg2-ui-gtk_0.4~pre+20120506.1-2_amd64.deb
 f218fa368ae9183a00f4f24933a81cef5f8a8398 76642 
ekg2-ui-ncurses_0.4~pre+20120506.1-2_amd64.deb
Checksums-Sha256: 
 a8e4cd587678527efcd6ea06bc112f9cdf1fb30350f84c89e91dd5934091ace5 2679 
ekg2_0.4~pre+20120506.1-2.dsc
 0fe56e0953e26817de1018897b6b5ffb38278bc467b844f318f73d1a6925c7da 21040 
ekg2_0.4~pre+20120506.1-2.debian.tar.gz
 d7aa626423d80977a1d35a04261777dc97fb7a43480c1091cefecfdfb5b98ac1 449452 
ekg2-core_0.4~pre+20120506.1-2_amd64.deb
 d1755334b8cf40b9d4da01ed7605c905a3214a35df75d897ee226e52ac3ce7ec 1324 
ekg2_0.4~pre+20120506.1-2_amd64.deb
 2f6fa69d529c239c3299f0df4f40c8d097813116d207755d934fae043c0909e2 1145134 
ekg2-api-docs_0.4~pre+20120506.1-2_all.deb
 0061a5b17807f1b19cc8f087ef6ad6d3bc79f8e5e49149d37497b4ebfec11d10 1153986 
ekg2-dbg_0.4~pre+20120506.1-2_amd64.deb
 bc204673d63f94fcbd731bc45e00f733399d51cc7e49d3467d6d9dfab44a5b97 9816 
ekg2-gnupg_0.4~pre+20120506.1-2_amd64.deb
 2b231a6fd749259105f02367e3d4ec6834fbda04340deeec8a65d78eb768848b 78876 
ekg2-jabber_0.4~pre+20120506.1-2_amd64.deb
 9170f2a5a818d7c316ec248d9d01f041c52cebdad1ed74730ad9c31f9fd5b5cc 18642 
ekg2-scripting-python_0.4~pre+20120506.1-2_amd64.deb
 41754f077a70d6af2f4f434a49e712ddbe23442effda93e66aa58cc6b52a0143 51620 
ekg2-scripting-perl_0.4~pre+20120506.1-2_amd64.deb
 5490fbcc2cd87d4a4d57dec74a3e7dfe924d3e11a06301b9168258c3252a7f4d 71062 
ekg2-ui-gtk_0.4~pre+20120506.1-2_amd64.deb
 410f0f7eb3adeeac1e044e1cea5a3820026e3f4aa9da739acff1220ef60a7d54 76642 
ekg2-ui-ncurses_0.4~pre+20120506.1-2_amd64.deb
Files: 
 0b666d5d5094297c69e0982b3af17d33 2679 net optional 
ekg2_0.4~pre+20120506.1-2.dsc
 d1713a807a88efd05a7cc12331a3c444 21040 net optional 
ekg2_0.4~pre+20120506.1-2.debian.tar.gz
 41def1f958ace464c945deaede8ed179 449452 net optional 
ekg2-core_0.4~pre+20120506.1-2_amd64.deb
 51a824ab1b4966112b1e27329601705f 1324 net optional 
ekg2_0.4~pre+20120506.1-2_amd64.deb
 e63530958682aec6ca666b4e34257872 1145134 doc optional 
ekg2-api-docs_0.4~pre+20120506.1-2_all.deb
 2045b8713f24ff737dfeb65686574ba1 1153986 debug extra 
ekg2-dbg_0.4~pre+20120506.1-2_amd64.deb
 7e56542420103a8287fa58a5a1b630b8 9816 net optional 
ekg2-gnupg_0.4~pre+20120506.1-2_amd64.deb
 414c376f2aafbaedc0b1cea20c30490c 78876 net optional 
ekg2-jabber_0.4~pre+20120506.1-2_amd64.deb
 7e4e10a246adc8a26c71e991e99c9207 18642 net optional 
ekg2-scripting-python_0.4~pre+20120506.1-2_amd64.deb
 03206f80fb3035f236d8bca168a7a779 51620 net optional 
ekg2-scripting-perl_0.4~pre+20120506.1-2_amd64.deb
 3122920e57516b9b9720e252f5a80a25 71062 net optional

Accepted verbiste 0.1.39-1 (source amd64 all)

2013-10-29 Thread Tomasz Buchert

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 29 Oct 2013 09:40:18 +0100
Source: verbiste
Binary: verbiste verbiste-gnome verbiste-el libverbiste-0.1-0 libverbiste-dev
Architecture: source amd64 all
Version: 0.1.39-1
Distribution: unstable
Urgency: low
Maintainer: Tomasz Buchert tomasz.buch...@inria.fr
Changed-By: Tomasz Buchert tomasz.buch...@inria.fr
Description: 
 libverbiste-0.1-0 - French and Italian conjugator - shared library
 libverbiste-dev - French and Italian conjugator - development files
 verbiste   - French and Italian conjugator
 verbiste-el - French and Italian conjugator - emacs extension
 verbiste-gnome - French and Italian conjugator - GNOME interface
Closes: 716651 727519
Changes: 
 verbiste (0.1.39-1) unstable; urgency=low
 .
   * Imported Upstream version 0.1.39 (Closes: #716651)
   * Updated build process (Closes: #727519)
   * Added 3 lintian overrides
   * Add --parallel to dh
   * Fixed URLS in debian/control
Checksums-Sha1: 
 a3dfa0f118a07e4efd6562d4e907c0e800ee08d9 2153 verbiste_0.1.39-1.dsc
 0fcb5c48d7b89e9f4329a71b7731c1dcc957adac 706555 verbiste_0.1.39.orig.tar.gz
 ae6010eb4b83c883ed6f737ac452bf883ae1d7c1 9306 verbiste_0.1.39-1.debian.tar.gz
 3674c1e7842a64c87e0f06cea3f5d42fb9f82363 78896 verbiste_0.1.39-1_amd64.deb
 1528554d57c6db9fd045c15a7504a060cb2e11cf 80050 
verbiste-gnome_0.1.39-1_amd64.deb
 52f3ed48eb1d7d39dfcfc2ad32aa7188dc581c30 14522 verbiste-el_0.1.39-1_all.deb
 18a01486fd4278682e7cfcf1b5dc3cd56eddeda9 49896 
libverbiste-0.1-0_0.1.39-1_amd64.deb
 4329b93a75ed93d5e794a0d908344697562c0136 21636 
libverbiste-dev_0.1.39-1_amd64.deb
Checksums-Sha256: 
 23ca66c1c5ebde9e34ac602fdc14e6ace563118885d6913b21c67136c1c308ef 2153 
verbiste_0.1.39-1.dsc
 15d76e3217366441e0b66a0e7c7cca78d199f836673c9ac32b2b1b7c6bc6d4db 706555 
verbiste_0.1.39.orig.tar.gz
 322be835f4ff4f694100d122ec9eb2f30610a894009932cd0939d4b7f32e1ea3 9306 
verbiste_0.1.39-1.debian.tar.gz
 b7a021bc6c6f78b3a68ca019ad60845d0d83a6ebca08749a4b068f0a2afd5afb 78896 
verbiste_0.1.39-1_amd64.deb
 ace1c2d86740f9dfc63ae0359e50524b4573665824ba5189b1fd5d48a78906ad 80050 
verbiste-gnome_0.1.39-1_amd64.deb
 b52e93b82a5dde516a2a7c6a5d7f88db0cad5cdae690642d3c662632932ed7ff 14522 
verbiste-el_0.1.39-1_all.deb
 62fb126869eda9ab93d97c04c72fd0baf7922062a25d37149cdd0b91539caf5c 49896 
libverbiste-0.1-0_0.1.39-1_amd64.deb
 c5673f10de19c37c736b0c677905664d262a8dfe547abd42384bb4c2c8d9cd67 21636 
libverbiste-dev_0.1.39-1_amd64.deb
Files: 
 4439665b3a8cf2df967c569c67179666 2153 text optional verbiste_0.1.39-1.dsc
 c372d8db070b8b4fd908f72a32f6 706555 text optional 
verbiste_0.1.39.orig.tar.gz
 5301f0bda02f6206f379117eeb36a5fe 9306 text optional 
verbiste_0.1.39-1.debian.tar.gz
 7f6ade8be0465ed7e833471bc2bed5aa 78896 text optional 
verbiste_0.1.39-1_amd64.deb
 7c7fe381aaf5aa7b48f1b0a7f4185c6f 80050 gnome optional 
verbiste-gnome_0.1.39-1_amd64.deb
 f1a25aaea12ee5ff4cf7666187472f36 14522 lisp optional 
verbiste-el_0.1.39-1_all.deb
 f88b422d28744fe0384085231584c938 49896 libs optional 
libverbiste-0.1-0_0.1.39-1_amd64.deb
 611b8fa9e16c01d37b8b68eebe436d46 21636 libdevel optional 
libverbiste-dev_0.1.39-1_amd64.deb

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

iQIcBAEBCgAGBQJSb6+nAAoJEJ+5JicksX0pjHcP/ihjRMPfTGd5sTG9PUHsXtif
DnQcIxflDrwxCdC6kdxnFiL1ORI8O5OTFYlKqo4bnKTEAylRf4K1O0k919CYNp9/
XYEGKYSGXsKfhdcht86iOryabhxY6xKHt4MNkdyND1oj3L4lOjgQTAT5MX3l5Fla
tBc2gTfTwLyK36pEzrA/sBzfNnkxzahVV4lDxsm1OcnbNgyRTzzU4QUhvGDdOcIC
zehNfkdi5+fKa5vibS0wZ/+/KYFmdRFY6vkKRkFvrUTA0CvZbJMhSjYQ1zAtq05d
+cBkkp9DghPXvsQ/Gzu0nEeBHC/aG/DGJcwWvx0tl2UKyEVivSxfIU+YiKTeyizq
vMdS39al+/ELKro1Q5ZtDeuUNhMkL0cXm2HW3d5qQS8tc3N1sqf58dqvkmDso/4h
SRSMqKXRrBpjcFQr9hl7+9UA2TSa8TNFATx8Eh47GPVJYHBBZL6IlCqgVI26F09x
c9e1vXI44CIXfaoMUorFdVMZ30Ksorvzg66fUbnk4IsOyuz8pyCidzToGBs0PQyg
afUCjKyCztYMIGBQK9c+CQXsAFYEEthDvCZjDDfPATVqbhuCN5qQiQOQnxh462BD
SgccWrow70Bpfe76LIJ1UEMDwwIaPUHQjNRhtqUj6LUayG4d6WgQr4ojZki8hzOO
fPHSZRBqewEN7BKGqNCY
=HLU7
-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/e1vb8xm-0002sy...@franck.debian.org

Accepted libvistaio 1.2.16-1 (source amd64)

2013-10-29 Thread Gert Wollny

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 22 Oct 2013 11:30:11 +0200
Source: libvistaio
Binary: libvistaio-dev libvistaio14 libvistaio14-dbg
Architecture: source amd64
Version: 1.2.16-1
Distribution: unstable
Urgency: low
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Gert Wollny gw.foss...@gmail.com
Description: 
 libvistaio-dev - Development files for the libvistaio library
 libvistaio14 - Library for loading and storing various types of binary data
 libvistaio14-dbg - Debug information for the libvistaio library
Closes: 726778
Changes: 
 libvistaio (1.2.16-1) unstable; urgency=low
 .
   * new upstream release
   * corrected debian/copyright entries (Closes: #726778)
Checksums-Sha1: 
 3abee689ba499bd593aff63cb6b4bf384f8c460f 1423 libvistaio_1.2.16-1.dsc
 0bec83415f98e4d78de5ba5706243e6285c1ba73 98132 libvistaio_1.2.16.orig.tar.xz
 368030d69fc6eea11ad09810378ba23ef0da3d73 3310 libvistaio_1.2.16-1.debian.tar.gz
 c88b36192190726b7c8f82c0f1433cd16607a51d 108022 
libvistaio-dev_1.2.16-1_amd64.deb
 de390b2af302cc061d2c9697cd579712a621e485 36694 libvistaio14_1.2.16-1_amd64.deb
 43f300cbfc425b89656b156a32ff5afe61cbf733 80132 
libvistaio14-dbg_1.2.16-1_amd64.deb
Checksums-Sha256: 
 eaf8312ceda189060792bd4f861395f2316bc86d1b4a970bc108dbeee40e9109 1423 
libvistaio_1.2.16-1.dsc
 aa720027db71268afea3a6cd43ba1818a3f2900238b951217dea87c9de6ff857 98132 
libvistaio_1.2.16.orig.tar.xz
 04ab717dcbc919189abe06e6f9787eb168ae86b503ecfda9ce3cbf218838dc6d 3310 
libvistaio_1.2.16-1.debian.tar.gz
 b424abf3a6230c25fbf8c88000b493b3cb2e9c2a9538f7da27340858ef969216 108022 
libvistaio-dev_1.2.16-1_amd64.deb
 22dbbb07f1d14e4e725571a80904ba7cee5b61429ada199ccb7324bd8656738e 36694 
libvistaio14_1.2.16-1_amd64.deb
 66674362ece26e29540a5e75ab391dc0fb3491c310c6af54f9aa5c134cd6dae5 80132 
libvistaio14-dbg_1.2.16-1_amd64.deb
Files: 
 451dee0f103f42dadb644958c24dc32a 1423 science optional libvistaio_1.2.16-1.dsc
 aa41955e8f701b9304f4804861f09c05 98132 science optional 
libvistaio_1.2.16.orig.tar.xz
 c202914337e1e3e44350152f433f742b 3310 science optional 
libvistaio_1.2.16-1.debian.tar.gz
 1cfb74fefacbdd36eff37bacf2884830 108022 libdevel optional 
libvistaio-dev_1.2.16-1_amd64.deb
 631a16ec05372ed58e640e1be7b23b2f 36694 libs optional 
libvistaio14_1.2.16-1_amd64.deb
 dcafd60f1d5c74813c53275ac83ab67b 80132 debug extra 
libvistaio14-dbg_1.2.16-1_amd64.deb

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

iEYEARECAAYFAlJvsjkACgkQYDBbMcCf01p4GgCfW2Zcx4Bi0dh1UdaJfZbZG/ry
I7wAoLTyHocEjDzfrJQq1nCvwah7FIAg
=CofC
-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/e1vb9bi-0005ut...@franck.debian.org

Accepted curlpp 0.7.3-4 (source amd64)

2013-10-29 Thread Ximin Luo

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 13:40:09 +
Source: curlpp
Binary: libcurlpp0 libcurlpp-dev
Architecture: source amd64
Version: 0.7.3-4
Distribution: unstable
Urgency: low
Maintainer: Ximin Luo infini...@gmx.com
Changed-By: Ximin Luo infini...@gmx.com
Description: 
 libcurlpp-dev - c++ wrapper for libcurl (development files)
 libcurlpp0 - c++ wrapper for libcurl
Closes: 728097
Changes: 
 curlpp (0.7.3-4) unstable; urgency=low
 .
   * Don't mess with quilt patches during clean; it's more properly taken care
 of by dpkg-source instead. (Closes: #728097)
Checksums-Sha1: 
 c8dab717246cdc0f2c4ce59efab7b2571aa08ed7 1601 curlpp_0.7.3-4.dsc
 15fc2df95b4a58ca358a517b0eec402327b5fe86 6530 curlpp_0.7.3-4.debian.tar.gz
 19bc34e826afe62589d476fcc604f83cfa73c05b 59944 libcurlpp0_0.7.3-4_amd64.deb
 38c6d1644aca0cbeed09b22bf3e3dee45ed90b4e 88664 libcurlpp-dev_0.7.3-4_amd64.deb
Checksums-Sha256: 
 078c88c4af39685835fee4e90226c449daa8757b21483821ff2cd92c6c42f6da 1601 
curlpp_0.7.3-4.dsc
 9b5014aa5187e5343d84f2a98fe428f60e2ba6fc61812ae65bef08613a50d663 6530 
curlpp_0.7.3-4.debian.tar.gz
 a2767613f8c80766e2093dd049ec3a0a477f7368d637548ecb46ef07bbdaeff5 59944 
libcurlpp0_0.7.3-4_amd64.deb
 e511898419fff2eda85b7c8fc5e20134c21658c07a56b5643f305ac8fbff7b97 88664 
libcurlpp-dev_0.7.3-4_amd64.deb
Files: 
 6687b856c9ceda9af255f151d6748d2d 1601 libs extra curlpp_0.7.3-4.dsc
 b60a44fd252aa9b692fc5b6552473b5e 6530 libs extra curlpp_0.7.3-4.debian.tar.gz
 cdb9eb6a7ed39a438d8bd6aa8e73b44b 59944 libs extra libcurlpp0_0.7.3-4_amd64.deb
 390627048486ef8d44ed85202d6edef4 88664 libdevel extra 
libcurlpp-dev_0.7.3-4_amd64.deb

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

iQEcBAEBAgAGBQJSb8KwAAoJEFb2GnlAHawEu+AH/3uyTJSx/79IU2Vw8+GurRZi
A53jC0CIV3xsw4FUHxzOWOUfogv+5H5g9nSLI7k+df+E5Vb6fPwvATMAI0HndqWR
ze+lJgeucufnbPkDlwhO06in/5KL07CtR9PQRx5Cp8vJipJvFTbQzTZpLrxtXC9M
je9e/+QCqtx2bf2MasnOCwUHwu9J2Y1TVG70b7FDdQVgMgLb/UQ3fG2OD2jC0WqS
N2Dgy3H2K7Pa4BiQrFL4GRBeg/W49plf9Pe63BmxbR06swUQ8+tHhJEVMdzUeuJS
HkA47hCo6LACkrk8h91x8GmSTshRO2j5/k7HxTWoP9bi5ebnYqzbzhU37T2LglU=
=8XNw
-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/e1vbb4i-0003ro...@franck.debian.org

Accepted plexus-containers1.5 1.5.5-6 (source all)

2013-10-29 Thread Emmanuel Bourg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 29 Oct 2013 11:10:33 +0100
Source: plexus-containers1.5
Binary: libplexus-containers1.5-java libplexus-containers1.5-java-doc
Architecture: source all
Version: 1.5.5-6
Distribution: unstable
Urgency: low
Maintainer: Debian Java Maintainers 
pkg-java-maintain...@lists.alioth.debian.org
Changed-By: Emmanuel Bourg ebo...@apache.org
Description: 
 libplexus-containers1.5-java - Plexus' inversion-of-control (IoC) container
 libplexus-containers1.5-java-doc - Plexus' inversion-of-control (IoC) 
container - documentation
Closes: 728171
Changes: 
 plexus-containers1.5 (1.5.5-6) unstable; urgency=low
 .
   * Team upload.
   * Added a patch to fix the source incompatibility with plexus-classworlds 2.5
 (Closes: #728171)
   * Updated Standards-Version to 3.9.5 (no changes)
   * Build depend on debhelper = 9
Checksums-Sha1: 
 6ee99354e8d0173466ad40d9005aa4a36fc93503 2453 plexus-containers1.5_1.5.5-6.dsc
 5b2268bb477eb7e756b132a228ba49a4e32d34cd 8024 
plexus-containers1.5_1.5.5-6.debian.tar.gz
 e39f50e726c33a96a6ecd1ecb03b8d1329b95b7a 285074 
libplexus-containers1.5-java_1.5.5-6_all.deb
 42ed65a7e0ec2a7f20710e3958cf7b8e11351e76 202070 
libplexus-containers1.5-java-doc_1.5.5-6_all.deb
Checksums-Sha256: 
 65980d7817232dea8116084fdf454c9a6af027022577926e678e53c260ce42a6 2453 
plexus-containers1.5_1.5.5-6.dsc
 da9072c626c56a8c015abca21651b88c00a72db00b494917c33e47014d9b9f06 8024 
plexus-containers1.5_1.5.5-6.debian.tar.gz
 71bb3f5abd51c1588d7f48f50bff848b150f5a85fa4e1b02d42a5f0879d99c2f 285074 
libplexus-containers1.5-java_1.5.5-6_all.deb
 9f240211cc2c5585f07677ce324f8982b4b6a6db3a990b674b8d72c3bd316b2b 202070 
libplexus-containers1.5-java-doc_1.5.5-6_all.deb
Files: 
 9b93fc21ba9d3561e1756a4bf2bc5258 2453 java optional 
plexus-containers1.5_1.5.5-6.dsc
 b568dde64df2156dcc912c5f31f09cd0 8024 java optional 
plexus-containers1.5_1.5.5-6.debian.tar.gz
 3c546f9236e9b307d9aa67af020da45d 285074 java optional 
libplexus-containers1.5-java_1.5.5-6_all.deb
 0ffa8aacae500a73116f5d93f5cdc664 202070 doc optional 
libplexus-containers1.5-java-doc_1.5.5-6_all.deb

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

iQIcBAEBCgAGBQJSb8dHAAoJECHSBYmXSz6WZE8QANB71MFSLJt4nse3oBj0mlg6
j8IWvAwBdoVvznjcMOOBaOT/EONxQ+j9yXlwy1iFIkD+5MPz51qFIpQxVAOH1J5l
+esgDIDcJghoz/HY4casXusbZQv57T71S33FAqlUBq6fQMjFONksxw0bB/wzQrwy
Ra7zyc8vXFavAd3y8t9nqd8nZwqxmqkYtTxjeApRk6pTc67mKXbSJZSFy7uL5DF5
90FIhUOUhreMi4r6RRK0sVtSN1puyN+TL89LO3K1B68wRJ4g20gjdF/nv2cYMLrs
5ipm5GsFlzxgotdXDnTbfgE2KSPEAggQGZvzu16ielxejsPokucvuh96fdPg75qs
0RS0lI3KsasNxoP/uZbYSbtBETtfuJXOwJoig2L78RWash5MNgF/TAlCu6BWc6dW
igcihRzXF1iSba629SHNYDhddLF4wlfth75ksfHW5gbOcGB20nQYYR3QDBBkuEix
YloFHHxETe2w4AtVfc+fU4wVcIDEG5mvRKTW3g/BhXYku3SgInLE35zO0bFrqw75
/+R53y5WR4VA1lVJw2o1i24jQeOlUZ7bFmAZbSFBEmCLTYm1vF8Y6E0dCLIQI2jD
M3G8FxN6fSlmi5ZIsmn22dx8bLVIxUiiCTiwx1hUn8GYW3iZWGYIxBb6e5bZPe9h
dqrc9v4VMVjk0x+KCbhw
=P55a
-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/e1vbb63-0003yg...@franck.debian.org

Accepted rcpp 0.10.6-1 (source i386)

2013-10-29 Thread Dirk Eddelbuettel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 09:42:30 -0500
Source: rcpp
Binary: r-cran-rcpp
Architecture: source i386
Version: 0.10.6-1
Distribution: unstable
Urgency: low
Maintainer: Dirk Eddelbuettel e...@debian.org
Changed-By: Dirk Eddelbuettel e...@debian.org
Description: 
 r-cran-rcpp - GNU R package for Seamless R and C++ Integration
Changes: 
 rcpp (0.10.6-1) unstable; urgency=low
 .
   * New release
   * debian/control: Set Build-Depends: to current R version
   * debian/control: Set Standards-Version: to current version
   * debian/control: Add 'r-cran-codetools' to Build-Depends (as it is
 used at preparation for LazuyLoading stage)
Checksums-Sha1: 
 4da428bcf70b8a4939d40f119c0a75a680133942 1083 rcpp_0.10.6-1.dsc
 16dc98129d7c04def9d48e39bf9246236cad8917 1951998 rcpp_0.10.6.orig.tar.gz
 4c57d73d8e69f7a903acacedfee3c9342a75611c 31615 rcpp_0.10.6-1.diff.gz
 99b03b08b2439e1dcea291baedc27aaf21fd1263 2243038 r-cran-rcpp_0.10.6-1_i386.deb
Checksums-Sha256: 
 ed586d3f8d122c5d93187344a160197f62d55c0393d050191752d16efa751dcd 1083 
rcpp_0.10.6-1.dsc
 2357bcd4fdbb87fdc6f1188f18615bb0e487e1f071462fd3b8f7196d7402fd51 1951998 
rcpp_0.10.6.orig.tar.gz
 82848cfc20e8d3aec9faec5b9bcc92d61f48d6c56635863f8a1ec8fa2aa3ca8c 31615 
rcpp_0.10.6-1.diff.gz
 355774432cfc9e7e30bbd35543e07c2199421db9bcde81be30968741d8096e85 2243038 
r-cran-rcpp_0.10.6-1_i386.deb
Files: 
 0cd24e07ae23a044465f4df917239b44 1083 gnu-r optional rcpp_0.10.6-1.dsc
 0210c2a76cae6cec1eb206edd1240a7a 1951998 gnu-r optional rcpp_0.10.6.orig.tar.gz
 0b7e2ff53855dd04b68a7cd095befb04 31615 gnu-r optional rcpp_0.10.6-1.diff.gz
 6a842883573a922f83cc956a01b9844b 2243038 gnu-r optional 
r-cran-rcpp_0.10.6-1_i386.deb

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

iD8DBQFSb8ojCZSR95Gw07cRAkPyAJ4ugYqTrubefTHnL3N46MGRp2GZRACaAkah
KJBmALhQeJQgP7oNVV+jOm0=
=4U7E
-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/e1vbb6d-00042i...@franck.debian.org

Accepted libace-perl 1.92-3 (source amd64)

2013-10-29 Thread Andreas Tille

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 11:08:14 +0100
Source: libace-perl
Binary: libace-perl
Architecture: source amd64
Version: 1.92-3
Distribution: unstable
Urgency: low
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Andreas Tille ti...@debian.org
Description: 
 libace-perl - Object-Oriented Access to ACEDB Databases
Changes: 
 libace-perl (1.92-3) unstable; urgency=low
 .
   * debian/source/format: 3.0 (quilt)
   * debian/control:
  - added myself to Uploaders
  - cme fix dpkg-control
  - debhelper 9
  - canonical Vcs fields
   * debian/README.Debian: Remark about hard coding of build directory
 in probably unused file.
   * debian/rules:
  - use short dh
  - enable propagation of hardening options
   * debian/upstream: Take over content of reference (DOI was wrongly
 specified at URL so I decided to remove)
   * debian/ace.1: automatically created manpage was broken - use help2man
 to create some valid ace.1
   * debian/copyright: DEP5
Checksums-Sha1: 
 0e758c5d63e2f011de70a1cdd7bedc0bcddda3ef 1375 libace-perl_1.92-3.dsc
 c2dafbc57272389300511420722bcd05ba92b28a 5765 libace-perl_1.92-3.debian.tar.gz
 26a994570b2af0ce411b6d496b443d6597b48aa0 310296 libace-perl_1.92-3_amd64.deb
Checksums-Sha256: 
 768363eabaa17221b04e033dfec5b546f43371d803b382576f6837f6c7f4322e 1375 
libace-perl_1.92-3.dsc
 e03de0d3457a3e1f8d41b22aa6ecd1d99f81030afdc2dbee8244b0dfe882c823 5765 
libace-perl_1.92-3.debian.tar.gz
 972ebe03fd9dbd6b922fa975ab67947221a190be26180e8908bb9dbd69934640 310296 
libace-perl_1.92-3_amd64.deb
Files: 
 6354180039343fc679269c6390b27c4b 1375 perl optional libace-perl_1.92-3.dsc
 063a596e0cdc115c3c4de0625388aac1 5765 perl optional 
libace-perl_1.92-3.debian.tar.gz
 3fb5d43a116afb6c99304f3b3d348338 310296 perl optional 
libace-perl_1.92-3_amd64.deb

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

iEYEARECAAYFAlJvw6YACgkQYDBbMcCf01pIeQCgrkaSeOHcRG5q703JHtGDDKEY
2FcAn3qxyuXpjC2d/82oD9ZtU4bBYHJl
=9wlO
-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/e1vbb4q-0003zx...@franck.debian.org

Accepted vagalume 0.8.6-1 (source amd64)

2013-10-29 Thread Alberto Garcia

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 28 Oct 2013 23:53:42 +0200
Source: vagalume
Binary: vagalume
Architecture: source amd64
Version: 0.8.6-1
Distribution: unstable
Urgency: low
Maintainer: Alberto Garcia be...@igalia.com
Changed-By: Alberto Garcia be...@igalia.com
Description: 
 vagalume   - GTK+-based client for Last.fm and compatible radio services
Closes: 727997
Changes: 
 vagalume (0.8.6-1) unstable; urgency=low
 .
   * New upstream release.
   * Drop all patches, they're already included in this release.
   * Update my e-mail address in debian/control and debian/copyright.
   * Build with autoreconf (Closes: #727997):
 - debian/rules: run dh --with autoreconf.
 - debian/control: add build dependency on dh-autoreconf.
   * debian/rules: don't force GTK+ 3 build, it's the default version now.
   * debian/copyright: update copyright years.
   * debian/control:
 - Remove obsolete DM-Upload-Allowed flag.
 - Replace gstreamer 0.10 with gstreamer 1.0.
 - Update Standards-Version to 3.9.4 (no changes).
 - Depend on dbus-x11.
Checksums-Sha1: 
 657cd1cfd5e6c605eb9861902f00e83455b76c26 1845 vagalume_0.8.6-1.dsc
 19500a254e706dd9d5b9f25f197f6b40cc2e9b51 796190 vagalume_0.8.6.orig.tar.gz
 a4c89f377b8d6e6334cdd52be0d4332b0658695a 4192 vagalume_0.8.6-1.debian.tar.gz
 6fff7b1645cebd82d80ee0bc810648578658aa2b 243780 vagalume_0.8.6-1_amd64.deb
Checksums-Sha256: 
 bfdbebcbfa43bc80903e4a8f5e1ef205792f1a8bfcd2db40aea059a55ac6c49a 1845 
vagalume_0.8.6-1.dsc
 d09aa893965a7632aec30a31d69abe5bebf17420f10e440521a070146c166141 796190 
vagalume_0.8.6.orig.tar.gz
 42afca9068e49f7fb41fee9d30d841cbcf0029c4c455e03a3f3bc313ee141842 4192 
vagalume_0.8.6-1.debian.tar.gz
 b2b02021ead16f3a908c867facf2412fc105be9e8351f332e09801b93377ffd9 243780 
vagalume_0.8.6-1_amd64.deb
Files: 
 1cd8ac6ca36b466b318275056baad59d 1845 sound optional vagalume_0.8.6-1.dsc
 18cc4a935ddfb019791b1a64be2ab95e 796190 sound optional 
vagalume_0.8.6.orig.tar.gz
 ba0ed34053a87504f990aecff900a096 4192 sound optional 
vagalume_0.8.6-1.debian.tar.gz
 2ccf72f55c6920338307e41e387fa95c 243780 sound optional 
vagalume_0.8.6-1_amd64.deb

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

iQIVAwUBUm/XIb4yGa8+1BNBAQjD1xAAwiuzVvzQJtuiw5WGeebrkDkrMCUPqC1o
ls3n/NVlLRYPhnT2PYoykPkn3xOsfvxDdY/WqeQQEFOg0vCgmdedJOO4vhqTjdZH
hCsLfOb0+mZfKv78NDMU9OnjjKHfEntkUTl23/EWopDpyb5/8Oxf5XcsvC4Xgkor
SM+BLyl5rdK5uBqm/tLbOaa8JCEUb7hW7oyWf/iJyL6ioKkQKVzfwgS7a7axeeIe
LbikoGHeaLlFrbugeZPnx+8rkTI+BjYeee04vCMoll5f7L4bA5T84I2Vltrkqq0b
JQVSZoKB+NKHcZGI2F9kQu1tL/ARJExRv7NPSeMlXnak3tllNeRQcWGP3DnhdnGZ
At18RuuGzs+6B4Lwuho/RbOYGyRntwhtwaEOVnks4QC3l6y5ojRv6ly6bX0aLymv
3Oz76IAkPKPzo7S8yHTFmnRyUglMLAytmxH/8X4YLOtxMgUzhLCukPMtfYn7PX7R
OBZtCkHP1KZEDVtFj2L1euD9+u5LGdzWWMgULz9VfvRSOmoWm+HYfGQZVUzRyzRs
S+u//sK6ctvDJlhDALvOTFAmj5DoTE90xamBaA0J7QAI6q3R+V7LPkHaCdnD+ELg
OyntpdBN75cV0DhnS9KKhsWx58BAt4ltrRqSGvzF5Ol//jKc5+eeRPhlE9Z5VFyu
eiW9bbmlsmI=
=xOux
-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/e1vbbxf-000105...@franck.debian.org

Accepted uhd 3.5.4-3 (source amd64)

2013-10-29 Thread A. Maitland Bottoms

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 09:30:06 -0400
Source: uhd
Binary: uhd-host libuhd003 libuhd-dev
Architecture: source amd64
Version: 3.5.4-3
Distribution: unstable
Urgency: low
Maintainer: A. Maitland Bottoms bott...@debian.org
Changed-By: A. Maitland Bottoms bott...@debian.org
Description: 
 libuhd-dev - universal hardware driver for Ettus Research products
 libuhd003  - universal hardware driver for Ettus Research products
 uhd-host   - universal hardware driver for Ettus Research products
Changes: 
 uhd (3.5.4-3) unstable; urgency=low
 .
   * Fix syntax to avoid failing test on powerpc
Checksums-Sha1: 
 4e1fe47d0206fb60d4a2a979f8a1c328c4eeea18 1451 uhd_3.5.4-3.dsc
 8cf0cae9a2bb21c908d80792dbdb3594c292619e 16429 uhd_3.5.4-3.debian.tar.gz
 4821de62cfeb8951acdc03b98ff8beb74b27c520 868112 uhd-host_3.5.4-3_amd64.deb
 a0a18813d2c8eafd5e9b70b614f596018cce7971 862824 libuhd003_3.5.4-3_amd64.deb
 2a4d2b90ccce217c8014868d0aaa5e6540aef4d8 287912 libuhd-dev_3.5.4-3_amd64.deb
Checksums-Sha256: 
 e262f81ac0afd658cbab29636d43957c9135ea383611b1adaf819f93fd0a8ef2 1451 
uhd_3.5.4-3.dsc
 1f3456d30f2e9a663450cbd2cc82b7626aabc1475fd2daa5a91e7bae43602fc0 16429 
uhd_3.5.4-3.debian.tar.gz
 ec275bbfba125056af0d5d380a6af8df721f4b911d216b53b09292f1abd187f8 868112 
uhd-host_3.5.4-3_amd64.deb
 8ae82729cdae0ceed9dc37149879423f934753881098d0f6f2c4d3208441d4b4 862824 
libuhd003_3.5.4-3_amd64.deb
 b5d2c283fa99b4fb22aa6ac90d18528c6ce1eda2a176b487ac15116382232c35 287912 
libuhd-dev_3.5.4-3_amd64.deb
Files: 
 2468f7fb26f17ae5332c20ae3ffbc7f7 1451 science optional uhd_3.5.4-3.dsc
 3f688918015017d0b6dbb94070a25e5c 16429 science optional 
uhd_3.5.4-3.debian.tar.gz
 4937d4fa494fa596677222992d43dc09 868112 science optional 
uhd-host_3.5.4-3_amd64.deb
 c29c20c3dd5df9427f75fe129cc879f5 862824 libs optional 
libuhd003_3.5.4-3_amd64.deb
 a467a22767bf23b2673e208207113625 287912 libdevel optional 
libuhd-dev_3.5.4-3_amd64.deb

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

iEYEARECAAYFAlJv1TMACgkQkwbJvNrxBUwboACfXtq/s4vatE3zyOFS4oKJfcbc
y8YAnjN12j8kKmiKU/8KRfsVsNirIyZM
=qchR
-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/e1vbbxx-xg...@franck.debian.org

Accepted dime 0.20030921-4 (source amd64 all)

2013-10-29 Thread A. Maitland Bottoms

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 11:52:41 -0400
Source: dime
Binary: dime libdime1 libdime-dev libdime-doc
Architecture: source amd64 all
Version: 0.20030921-4
Distribution: unstable
Urgency: low
Maintainer: A. Maitland Bottoms bott...@debian.org
Changed-By: A. Maitland Bottoms bott...@debian.org
Description: 
 dime   - DXF Import, Manipulation, and Export programs
 libdime-dev - DXF Import, Manipulation, and Export library - devel
 libdime-doc - DXF Import, Manipulation, and Export library - devel
 libdime1   - DXF Import, Manipulation, and Export library
Closes: 728212
Changes: 
 dime (0.20030921-4) unstable; urgency=low
 .
   * Use override_dh_auto_build-indep for doxygen docs (Closes: #728212)
Checksums-Sha1: 
 4f58bfd2e82fb9491b976d6a1d1b9251c07516e9 1280 dime_0.20030921-4.dsc
 728b0983b646351033a286c829e4525d088655e0 5074 dime_0.20030921-4.debian.tar.gz
 4803ac78f3b007a45c882d832561d4757a9a7725 9590 dime_0.20030921-4_amd64.deb
 81a196ad17f09aead6b396beb0e238dddf9d80e2 95874 libdime1_0.20030921-4_amd64.deb
 3baddb62abf4092937ed2c37bca1d9478f78cc21 25150 
libdime-dev_0.20030921-4_amd64.deb
 b0c5f1b47b244df8f4899146216b8df6d5745df4 245696 
libdime-doc_0.20030921-4_all.deb
Checksums-Sha256: 
 d0e77073d740a6d0bcbdf423b28248617d1b08ca5de95afb3821c23b703d42ec 1280 
dime_0.20030921-4.dsc
 5d643489f09a92f7122a4ace57a0f3a38395d585c85670a817504169397fb043 5074 
dime_0.20030921-4.debian.tar.gz
 4caba68f94ac4dbc7cd6f9753a4d0eae447855efd15a7a2ffd7ec61ab4db90be 9590 
dime_0.20030921-4_amd64.deb
 c79603967d09cb64c61e81af44aa51eb5badc76cc940815e9ad98a4171d7494c 95874 
libdime1_0.20030921-4_amd64.deb
 9577a35121a1503454e82a53f337cf4a2e6ed9a88f5084e09d6ecd6db1da1bbf 25150 
libdime-dev_0.20030921-4_amd64.deb
 11889704526215d79b96c483998cb96527f0e439e502c8390665a36274fc0299 245696 
libdime-doc_0.20030921-4_all.deb
Files: 
 95f437263eb7d3408580f6c27071b845 1280 graphics optional dime_0.20030921-4.dsc
 5dfefeb328c071ca9544b09339b04796 5074 graphics optional 
dime_0.20030921-4.debian.tar.gz
 a7c80d77d015f83cf93b928bfa9dc7b9 9590 graphics optional 
dime_0.20030921-4_amd64.deb
 ca17677f699c349dda904cba45fe3068 95874 libs optional 
libdime1_0.20030921-4_amd64.deb
 3f6c361b142abbecaccb6b3d64a1041f 25150 libdevel optional 
libdime-dev_0.20030921-4_amd64.deb
 f57216700c4d92fc4d76957f11630da6 245696 doc optional 
libdime-doc_0.20030921-4_all.deb

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

iEYEARECAAYFAlJv2yoACgkQkwbJvNrxBUwkkgCfZxhUDmJ/uWg+dXERcchwm/3x
PysAn2lBVA2soR5BsPzpRRvwV8McTAKA
=v0RU
-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/e1vbc03-000379...@franck.debian.org

Accepted openvswitch 1.9.3+git20131029-1 (source i386 all)

2013-10-29 Thread Ben Pfaff

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 29 Oct 2013 08:31:55 -0700
Source: openvswitch
Binary: openvswitch-datapath-source openvswitch-datapath-dkms 
openvswitch-common openvswitch-switch openvswitch-ipsec openvswitch-pki 
openvswitch-controller openvswitch-brcompat openvswitch-dbg python-openvswitch 
ovsdbmonitor openvswitch-test
Architecture: source i386 all
Version: 1.9.3+git20131029-1
Distribution: unstable
Urgency: low
Maintainer: Open vSwitch developers d...@openvswitch.org
Changed-By: Ben Pfaff pfaff...@debian.org
Description: 
 openvswitch-brcompat - Open vSwitch bridge compatibility support
 openvswitch-common - Open vSwitch common components
 openvswitch-controller - Open vSwitch controller implementation
 openvswitch-datapath-dkms - Open vSwitch datapath module source - DKMS version
 openvswitch-datapath-source - Open vSwitch datapath module source - 
module-assistant version
 openvswitch-dbg - Debug symbols for Open vSwitch packages
 openvswitch-ipsec - Open vSwitch GRE-over-IPsec support
 openvswitch-pki - Open vSwitch public key infrastructure dependency package
 openvswitch-switch - Open vSwitch switch implementations
 openvswitch-test - Open vSwitch test package
 ovsdbmonitor - Open vSwitch graphical monitoring tool
 python-openvswitch - Python bindings for Open vSwitch
Changes: 
 openvswitch (1.9.3+git20131029-1) unstable; urgency=low
 .
   * New upstream release.
 - Fixes opening Unix sockets with very long names from Python.
Checksums-Sha1: 
 aae2e62a8c9a84361b5173a6875ab1730ef4bd3b 2728 
openvswitch_1.9.3+git20131029-1.dsc
 cd3e31eb98914187f9e7b583175526fdacfc019e 1572432 
openvswitch_1.9.3+git20131029.orig.tar.xz
 fb1b5f75829203781b5b812ec2ad2558b3edcc8b 60109 
openvswitch_1.9.3+git20131029-1.debian.tar.gz
 16b551bf9817917cf3dab4963d3419887c5002ea 423764 
openvswitch-common_1.9.3+git20131029-1_i386.deb
 aadbeebf32e6708785d93a92186643530a00ab50 764578 
openvswitch-switch_1.9.3+git20131029-1_i386.deb
 e17dbf74a5caa0c3226d8fe8e60068650c2549e8 32288 
openvswitch-ipsec_1.9.3+git20131029-1_i386.deb
 e245f2473fa4acb98c2e23b110557f2f3ad73dd4 255674 
openvswitch-controller_1.9.3+git20131029-1_i386.deb
 75acb054b0dfad3afb8c17ee2dd48db8e6ba4aa7 235100 
openvswitch-brcompat_1.9.3+git20131029-1_i386.deb
 2f05baf9a1e36427e53521eed3db2997f3f6208a 3072892 
openvswitch-dbg_1.9.3+git20131029-1_i386.deb
 06d5fa38d8a1adb2b2e375fa8df71e94897a17e4 2404382 
openvswitch-datapath-source_1.9.3+git20131029-1_all.deb
 2e67711b5e6af01e489dff01dc4601d1fa767920 1603592 
openvswitch-datapath-dkms_1.9.3+git20131029-1_all.deb
 5be51d3a124220c47bca7568665a6d2f5ba79891 26192 
openvswitch-pki_1.9.3+git20131029-1_all.deb
 93b7a867f37c54d2c47710da461228bd47ee22b8 74732 
python-openvswitch_1.9.3+git20131029-1_all.deb
 3d652188c28b5fc4559d7078e43b7734dbe7311e 45280 
ovsdbmonitor_1.9.3+git20131029-1_all.deb
 20e68b8039fc07699cdf89653aee2cd30cec972a 41954 
openvswitch-test_1.9.3+git20131029-1_all.deb
Checksums-Sha256: 
 2da5d8b5d04e1a8d8949aa97ea8c291102aa1d4bc206e6cd82e9c00e056ea8e1 2728 
openvswitch_1.9.3+git20131029-1.dsc
 f1658f1abaf1d9f6c8696e76773dc956d7d7bbd7b7c0f9f1aeb3f359bcc8409e 1572432 
openvswitch_1.9.3+git20131029.orig.tar.xz
 6a5b988c5798eca6625a71b303cc047f5d01c5e9f55c7d59156b85082a57ecc5 60109 
openvswitch_1.9.3+git20131029-1.debian.tar.gz
 f364b2e2214d05b318236d2aea210efeae5ea6b0a3b50b9f718c4eaeea58e04e 423764 
openvswitch-common_1.9.3+git20131029-1_i386.deb
 c9a19e55e6e50f6e33da5f5bb63acff1006dda76c2e0b8a204d727258ac4622f 764578 
openvswitch-switch_1.9.3+git20131029-1_i386.deb
 aa9859aac9dfef507269ce63e728e59a5f212b3b50916ede49d22fcee9c526d7 32288 
openvswitch-ipsec_1.9.3+git20131029-1_i386.deb
 0a42ec4131c2a8c78fe83e82e8ab8fa072af23e1170a6805b863e0f8bd96ee9e 255674 
openvswitch-controller_1.9.3+git20131029-1_i386.deb
 4465e455b6cea416ac6265ec10671e2f48d96a6d574986f53944d16ee692fb7b 235100 
openvswitch-brcompat_1.9.3+git20131029-1_i386.deb
 73ffe77edd6ce6e0fc7e31c3c9aa3b4983cad9a59b35cbc476bf48153b8817fb 3072892 
openvswitch-dbg_1.9.3+git20131029-1_i386.deb
 f1120045ead554a4b589a118c4f5b9448ec1c417898b96b6823285d8dc89baa8 2404382 
openvswitch-datapath-source_1.9.3+git20131029-1_all.deb
 67dd2c35b7bc2eb112b3222733652023299fb3921ba6ee068fa295a9537f20ce 1603592 
openvswitch-datapath-dkms_1.9.3+git20131029-1_all.deb
 6055b3d56cbb2720409bdc0675d53d01be4dbe37b95f2a02b932ddd08cbde395 26192 
openvswitch-pki_1.9.3+git20131029-1_all.deb
 ab29a9ce510f3f512d4a2d70db2b5a27705c86a4827efb0542bbdbacb9cf78b5 74732 
python-openvswitch_1.9.3+git20131029-1_all.deb
 d62a9b7d58f2090184aa6da5074f106a143276d8f1880cc842f1ca4fdfb13940 45280 
ovsdbmonitor_1.9.3+git20131029-1_all.deb
 78d597e39693662eec88b320e40b0c97f0725eaacc59eec8d972c00478390bc7 41954 
openvswitch-test_1.9.3+git20131029-1_all.deb
Files: 
 13d539a721ee8bceaa8f00971c7555cd 2728 net extra 
openvswitch_1.9.3+git20131029-1.dsc
 ada5ce14033a5913df46db4ce0fbc503 1572432 net extra 
openvswitch_1.9.3+git20131029.orig.tar.xz

Accepted python-markdown 2.3.1-2 (source all)

2013-10-29 Thread Dmitry Shachnev

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 29 Oct 2013 20:14:29 +0400
Source: python-markdown
Binary: python-markdown python3-markdown python-markdown-doc
Architecture: source all
Version: 2.3.1-2
Distribution: unstable
Urgency: low
Maintainer: Debian Python Modules Team 
python-modules-t...@lists.alioth.debian.org
Changed-By: Dmitry Shachnev mity...@gmail.com
Description: 
 python-markdown - text-to-HTML conversion library/tool (implemented in Python 
2)
 python-markdown-doc - text-to-HTML conversion library/tool (documentation)
 python3-markdown - text-to-HTML conversion library/tool (implemented in Python 
3)
Closes: 728134
Changes: 
 python-markdown (2.3.1-2) unstable; urgency=low
 .
   * Update man page:
 - Correctly escape hyphens.
 - Make DESCRIPTION section come after SYNOPSIS and remove
   AUTHOR section.
   * Really remove suggestion of python-utidylib, HTML Tidy extension
 has been removed in 2.3.
   * debian/watch: use HTTPS, and correctly escape dots.
   * Update debian/copyright (closes: #728134, thanks Luke Faraone).
Checksums-Sha1: 
 f358a8721ae54e5b66ba796f44dda3ebfb7e1b0b 2337 python-markdown_2.3.1-2.dsc
 7499171701bb20be29fb834aa02a12b6323ea88c 267131 
python-markdown_2.3.1.orig.tar.gz
 e7fddbbe98813caaffc6bc594e3fe74fd9e10176 6774 
python-markdown_2.3.1-2.debian.tar.gz
 2e6b47d9559063ca747410660771051483cc2074 51034 python-markdown_2.3.1-2_all.deb
 5ee08c18e13a7b56f3fad773117047b2e0c84f2b 49628 python3-markdown_2.3.1-2_all.deb
 5a8c26f2d84b5eab1392c9937add0489de4b9b1d 62926 
python-markdown-doc_2.3.1-2_all.deb
Checksums-Sha256: 
 9eb0a16d150ac67451443a039d2ae286a8329d097b81f84b11bd81a0f27a4b9f 2337 
python-markdown_2.3.1-2.dsc
 ffebd9385717aba00ff4e95b705b7693ddf12a7d483483d441218b6d3f4cf290 267131 
python-markdown_2.3.1.orig.tar.gz
 081691b155ed6bd8e91684af657225bb2cbcd481920192ebb86a2ee7475cbf42 6774 
python-markdown_2.3.1-2.debian.tar.gz
 0bbbf889c6c430601f54e537bff551b4e9940420cb7c8dc7b9cc169616dbfec2 51034 
python-markdown_2.3.1-2_all.deb
 681ae3cf4581ba3693c3810a1c644e6fc63e136aab87cbba310cde80a929d058 49628 
python3-markdown_2.3.1-2_all.deb
 fd5d1ee10adf775a1103b9aafc7d6b38d4cea78df6523cfcdb45393b19476b3f 62926 
python-markdown-doc_2.3.1-2_all.deb
Files: 
 eaa37ba262d5f609c8000e67f95e6009 2337 python optional 
python-markdown_2.3.1-2.dsc
 82f6828ec2292dda52fc38b743776bc6 267131 python optional 
python-markdown_2.3.1.orig.tar.gz
 5811985931859f778eb45cff81bd19bf 6774 python optional 
python-markdown_2.3.1-2.debian.tar.gz
 78bd2c9961fc8882bea76efa76775c99 51034 python optional 
python-markdown_2.3.1-2_all.deb
 e739a0725d461263201e2974b31cf1d0 49628 python optional 
python3-markdown_2.3.1-2_all.deb
 4035179cbb6abc73664b7543974ab2e0 62926 doc optional 
python-markdown-doc_2.3.1-2_all.deb

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

iQIcBAEBCAAGBQJSb99DAAoJEGAmk20vHIrgfjkP/1rdUJi4JEdVFfT6+9mDsy0f
Nf7k3Kg4WkehwAbR7WvQHbnel8YTKp8MuIplK3wVwAst5GJPS9iFeAgXPzyRrb8v
N8Mbj4Ht6wT4x49qOQlHVTV0i2zSK1dkACY+EksKt+UCpY6O29EzOi0BBwAAr7ki
TV1fARS3Qv7smt8eSbUYgM3yHyuai5tsRr1ntOzner4dU+06Gv+it80wF4KHdAeV
nFbSXY+amhMwoWbdE5NeC3ZbmF7gNyxsef2Y/XmfRbsl1n5xPz7KegtMFjB7f0yR
AWUnNw1mN373FpAqYkHTYqXjTP8Ao4y0TgYEKn3G8Ts4sQOenfhDESFO68m/ogNe
wOh/mbKpDTZKnsmkBxe3ywktSOFn/qXV+8pdHyHYujR2QRSBhaAq9HPdrZdnW5sz
+lD76x3zCdjC8YE5moyLGeWBm0lOn2aMgSMMwiJ/LUq6OXQspmdTNrGNnGYMCuof
b9hxX4ze2nQw1Au6WH1MalfSDhdBv6y5t/NAEf1qUq7HU3Qp2YF5yw/gBVAkG9mJ
NaOXGrnzlmFJuPnWcITp5Tx6zKlBxXt+1hmUydVA7d7TyrlQsa9EAwHQ0poDTsIs
x3duJ9M5p8MSTYaSToheLm+DvqaNVEhhlNjoLP/5FvXcQWPtnC6kJrJ9e5utYX8c
zH4tQfoUFEYryqOMhsyI
=MVXS
-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/e1vbcem-00062z...@franck.debian.org

Accepted autocutsel 0.9.0-3 (source amd64)

2013-10-29 Thread Elmar S. Heeb

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 17:13:24 +0100
Source: autocutsel
Binary: autocutsel
Architecture: source amd64
Version: 0.9.0-3
Distribution: unstable
Urgency: low
Maintainer: Elmar S. Heeb el...@heebs.ch
Changed-By: Elmar S. Heeb el...@heebs.ch
Description: 
 autocutsel - Keep the X clipboard and the cutbuffer in sync
Closes: 727775
Changes: 
 autocutsel (0.9.0-3) unstable; urgency=low
 .
   * fix cutsel segfault for empty cut buffer (Closes: #727775)
 Thanks: Jurij Smakov ju...@wooyd.org
 .
   * increase debhelper compatibility level to 9
   * refactor debian/rules:
 * convert to dh_auto_* style
 * rewrite for debhelper compatibility level 9
 * finally convert to dh style
Checksums-Sha1: 
 382c112a8c7d88149e8d42020448268f264adb59 1279 autocutsel_0.9.0-3.dsc
 eb0034ddb89aa7b28e3e05b038e4fff014e3db26 3725 autocutsel_0.9.0-3.debian.tar.gz
 050e75ab8556a39e813c87687f6c381e0dbdbff1 14470 autocutsel_0.9.0-3_amd64.deb
Checksums-Sha256: 
 1258976352d5c46757d22bd64922d5339437c43e13bf6abdb09b311ea0629b5f 1279 
autocutsel_0.9.0-3.dsc
 e2f604daf4afce62e753a844e72ab9f43c7c9f786bc555027d4b9f3f60a26baa 3725 
autocutsel_0.9.0-3.debian.tar.gz
 91b1eb52625cf4cb3d519aec1935a72e4e4ef44353ca265a50bd5e52fc23 14470 
autocutsel_0.9.0-3_amd64.deb
Files: 
 97f432adb79279d6c7b3c4b389a7ca24 1279 x11 optional autocutsel_0.9.0-3.dsc
 dbbcecb1d00651224c8ab28b1e438f34 3725 x11 optional 
autocutsel_0.9.0-3.debian.tar.gz
 434217cfc50340b3ceb25d72a29fc9ff 14470 x11 optional 
autocutsel_0.9.0-3_amd64.deb

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

iEYEARECAAYFAlJv4Q8ACgkQwJ4diZWTDt4BXACeJilWlqhG5HFpiBClqr6ddBzi
whQAnAydKwARIaNbVHQgLoA/xYD0UVTt
=TkX6
-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/e1vbcsr-em...@franck.debian.org

Accepted libsdl2-net 2.0.0+dfsg1-2 (source amd64)

2013-10-29 Thread Manuel A. Fernandez Montecelo

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 29 Oct 2013 16:40:22 +
Source: libsdl2-net
Binary: libsdl2-net-2.0-0 libsdl2-net-dbg libsdl2-net-dev
Architecture: source amd64
Version: 2.0.0+dfsg1-2
Distribution: unstable
Urgency: low
Maintainer: Debian SDL packages maintainers 
pkg-sdl-maintain...@lists.alioth.debian.org
Changed-By: Manuel A. Fernandez Montecelo m...@debian.org
Description: 
 libsdl2-net-2.0-0 - Network library for Simple DirectMedia Layer 2, libraries
 libsdl2-net-dbg - Network library for Simple DirectMedia Layer 2, debugging
 libsdl2-net-dev - Network library for Simple DirectMedia Layer 2, development 
files
Closes: 727436
Changes: 
 libsdl2-net (2.0.0+dfsg1-2) unstable; urgency=low
 .
   * Build-Depends on pkg-config
   * Do not call dh_autoreconf with ./autogen.sh as parameter, to force
 using new config.{sub,guess} files, which important when having new
 architectures (Closes: #727436)
Checksums-Sha1: 
 a9cf5a682773f620bea73f95f761d8055abee019 2200 libsdl2-net_2.0.0+dfsg1-2.dsc
 1ee4976cec8ace3ab6fe66f41417bf537c4be4cd 2827 
libsdl2-net_2.0.0+dfsg1-2.debian.tar.gz
 8af87a33748d455ad60742056b6051539a5a482e 10974 
libsdl2-net-2.0-0_2.0.0+dfsg1-2_amd64.deb
 edcc8d2f35346e62682cad26ee2875584faf46a6 22852 
libsdl2-net-dbg_2.0.0+dfsg1-2_amd64.deb
 cc88ef5feec52142945017486c10ce8a8c2d60bd 19140 
libsdl2-net-dev_2.0.0+dfsg1-2_amd64.deb
Checksums-Sha256: 
 dfa0833ae82ffee51415722aee57afd801accf1d069ad7978dfd0d4076cbdd32 2200 
libsdl2-net_2.0.0+dfsg1-2.dsc
 4fb9bc721e535a5eefd51f82fda5c72bd710994a89655e109ef5c6bf75725f1c 2827 
libsdl2-net_2.0.0+dfsg1-2.debian.tar.gz
 fca69e1ab3f248d76564f206c962f3ec84983435cae5c3ad2b06cceff9294611 10974 
libsdl2-net-2.0-0_2.0.0+dfsg1-2_amd64.deb
 512ffaeef95aa5988bcca8e4a393af2858e25320d9d3191af6a402c4a0373950 22852 
libsdl2-net-dbg_2.0.0+dfsg1-2_amd64.deb
 4c7492a48991e9cc608f0ac8d2b8eb7e3bcada1910c4dd78f0b102dc4a2def51 19140 
libsdl2-net-dev_2.0.0+dfsg1-2_amd64.deb
Files: 
 4216892bbb8311c7a6af03e446ed048d 2200 libs optional 
libsdl2-net_2.0.0+dfsg1-2.dsc
 b22f98757c5cf51dd7c8e8ea0a9392f9 2827 libs optional 
libsdl2-net_2.0.0+dfsg1-2.debian.tar.gz
 fefd76c5cc8ad3f79884b328c5a9ba22 10974 libs optional 
libsdl2-net-2.0-0_2.0.0+dfsg1-2_amd64.deb
 270a2f884d4d342308542af8d1e6f5b2 22852 debug extra 
libsdl2-net-dbg_2.0.0+dfsg1-2_amd64.deb
 fcf5c041688761bbe9845c2cd80e9cb6 19140 libdevel optional 
libsdl2-net-dev_2.0.0+dfsg1-2_amd64.deb

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

iQIcBAEBCgAGBQJSb+a7AAoJEH92BqRF3KgOMbUP/3mQYDTZjjfmiUfMij0L2dYJ
wfiXfXFa1+QzS0eQYAOsE1ZApOhUwgUNeApt3Hk8idzVgERgtJEde5dqiStkzpzh
HJCZF6WFNqj6rzW5HKNTiaClVGXlqdl4139U+OFEMx9E4rgY7fdpc4R1Xjld1pLB
pRAYVJVkV15/e3CxHB9KsfR5GWJaiKx+sZh0twjCPKCpijJd6WdRa7gSZVRJuhCF
z0maMdchffpsUHXgqf6S5yoKa9rNAcKHjSWy2+hxwla8B3ntL3c9PCKT67MkQTZn
bDGupXOX4dnJkBG046hsKbEiPggeuEEsLIQNFi+vQt9eAGL4JgidCGmniHSj4acq
zIlLqIkdjZA3TPtQGhavqgq+cPC9/rD1ygk6lJDLPKEIMjf7pih0gUSHnEJV9m4W
VFDl1qrmHQtquT70chk+paVMIU7BKypjVGlggoAfbITyFWvIycFJ98VFWQ1e6bV8
O8ZY2L2R3dkJPA+ATvZaXOSWdkVsTCejOdKCQUpaiaBNtkbHCnBu/UbaBR/u5qJy
dUuOObTFHHhbJxM5eHVWR7TDgwGbai7GDBhAt0QH7+8bx9hCeDeT2rzoS99htlDh
Kg1Eo5e/Ti0/bBDU3imCBusYpahTSb9f6b4LAa1mpWWzjjDkhC8QRNaCboBCr0Y+
3GZRSGuQzHmizp7GwPCn
=tM4Q
-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/e1vbchx-0003fi...@franck.debian.org

Accepted ploop 1.9-3 (source i386)

2013-10-29 Thread Ola Lundqvist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 18:24:50 +0100
Source: ploop
Binary: ploop libploop-dev libploop1
Architecture: source i386
Version: 1.9-3
Distribution: unstable
Urgency: low
Maintainer: Ola Lundqvist o...@debian.org
Changed-By: Ola Lundqvist o...@debian.org
Description: 
 libploop-dev - ploop API development library
 libploop1  - ploop API library
 ploop  - tools to work with ploop devices and images
Closes: 728172 728174
Changes: 
 ploop (1.9-3) unstable; urgency=low
 .
   * Added dependency on pkg-config to make sure it builds in a minimal
 build environment. Closes: #728172.
   * Limited the architectures to i386 ia64 amd64 powerpc sparc which is
 the same as vzctl is limited to. Closes: #728174.
Checksums-Sha1: 
 5a4ea29ab8c6ca486da607dcc74aec9a5f172a63 1293 ploop_1.9-3.dsc
 220fe46b501dbec164ac1999d97e39c8c469676b 5344 ploop_1.9-3.debian.tar.gz
 a96ef725af3dab6f06f3a38d5dfaf3bd94d3ae15 34016 ploop_1.9-3_i386.deb
 e8018806506e11855acfafa4a8a5b7906f45a879 119634 libploop-dev_1.9-3_i386.deb
 01c90fcf33e2a26ae3dafbf3b17b24942a36338c 87306 libploop1_1.9-3_i386.deb
Checksums-Sha256: 
 f88f20f257764a1fee6c835056d31b53c01e84bc6268caea4be7b91b42808fcd 1293 
ploop_1.9-3.dsc
 8ae51fbd4f3cbb4e19f9c353d90e42d2c892a85c0d7f6b38b19c4017fbd57149 5344 
ploop_1.9-3.debian.tar.gz
 7dee0d042b0c6b6348b68b73c185c31d10d84065b18215dd592ffec0bbe57916 34016 
ploop_1.9-3_i386.deb
 bb62cb0d361e97813a9ea6a82f5cb9acfb1f27098c231fcb6491f1d0a1b0ab19 119634 
libploop-dev_1.9-3_i386.deb
 5779968109512be9ff3fc1f4bdcc21af1a27dc8b2a36aefe27b2b3ce0a495a85 87306 
libploop1_1.9-3_i386.deb
Files: 
 80919fd5bec480c9cea7e79660edda5f 1293 libs extra ploop_1.9-3.dsc
 6216a2f2f9c7529560ffbbbc53a209c0 5344 libs extra ploop_1.9-3.debian.tar.gz
 c0a82029e7439e8a977937e634e36827 34016 libs extra ploop_1.9-3_i386.deb
 531fe85d0ceb85f07da68fcc2411a6f7 119634 libdevel extra 
libploop-dev_1.9-3_i386.deb
 c355a1f32e54313386e090111b4d89e8 87306 libs extra libploop1_1.9-3_i386.deb

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

iEYEARECAAYFAlJv7/AACgkQGKGxzw/lPdks7QCgiJcxYGL48rzTnaf998c3tiPD
UaMAnjs9CTHMbYc37AdG9gEGoZRSoWPX
=vnzR
-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/e1vbdak-8r...@franck.debian.org

Accepted scim-chewing 0.3.4-4.1 (source amd64)

2013-10-29 Thread gregor herrmann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 27 Oct 2013 18:22:36 +0100
Source: scim-chewing
Binary: scim-chewing
Architecture: source amd64
Version: 0.3.4-4.1
Distribution: unstable
Urgency: low
Maintainer: Andrew Lee (李健秋) ajq...@debian.org
Changed-By: gregor herrmann gre...@debian.org
Description: 
 scim-chewing - Chewing IM engine module for SCIM
Closes: 707442
Changes: 
 scim-chewing (0.3.4-4.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Fix FTBFS: conftest.c:68: undefined reference to `shl_load':
 add patch 0001-Change-libchewing-requirement-to-0.3.5.patch from upstream
 git: change version check to '='.
 Additionally change the check in ./configure as well.
 (Closes: #707442)
Checksums-Sha1: 
 510c51cc48a4f3ac697fde94ea01a4fc60fb8550 2072 scim-chewing_0.3.4-4.1.dsc
 d4d6e97bc45549a447fcb2998136a1d655b2343d 10808 
scim-chewing_0.3.4-4.1.debian.tar.xz
 b3c3f9f03ccdd2285655196286d06869577b155c 53546 scim-chewing_0.3.4-4.1_amd64.deb
Checksums-Sha256: 
 b5e0bcc1c50973edec74c1e6a7a7c3e67d8cd6e627b68494edcfcb2c7f8c5f62 2072 
scim-chewing_0.3.4-4.1.dsc
 93dedaecae3bd2a8c2a431b28f36509a3e785c3af4d9e28c7f48bee0e1c9cc84 10808 
scim-chewing_0.3.4-4.1.debian.tar.xz
 89d800b1144808c71480dcd5a19de31331387cd6fd9332782ed3576b192e43cf 53546 
scim-chewing_0.3.4-4.1_amd64.deb
Files: 
 a5fb0eae698bf999cd1149fa15be51c5 2072 utils optional scim-chewing_0.3.4-4.1.dsc
 2956d79d3fc9e4fbf21f078f89bd5417 10808 utils optional 
scim-chewing_0.3.4-4.1.debian.tar.xz
 a0fdc20fee3f3fc607c7f169d7d84fc2 53546 utils optional 
scim-chewing_0.3.4-4.1_amd64.deb

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

iQIcBAEBCAAGBQJSbUxbAAoJELs6aAGGSaoGveQP/ix0iC6lAQ8bOYCBpEIU+mXG
2VEe8IGN7X5n/5NMg5wG3R7nRf7ibo7BN6XzR6ww1UIwEWg6zz2KRnNSy1/Sp9HY
9WqgqnuJ/UD9Kwj4/AVuRb7G9ovvfCkQ+oDzv4FaeQD130YYw9yvvjkIcSOXkMr5
QpxtQQrHwitj7bzUK1r4udMnVAFCRkH6rXq9l57MMKXrDKyFKq2aI01r3Mm6JADU
GYlRMF6JO1HTGon/VOKwWXrABOCSw8JgxPeRUB5k8y1iViFbCNBlkbkcZlBuyn9d
mWu9Qs4TSURXamtxzHpEc2Vhp0E0IStGK6qVv5cLSTl/AqdrH/YINT1RS9hjqQBz
lMdVgALPBWiVf0of9zDzP9O3xI2lG/hdM8ryLTNznTMr/vuCAgp7VZvuv1GY0JIw
M6h2BPMhNPcPIek9vekj9Cme8VP8l+EJBf1V1Qzouhh+Z5+vTwHLf6aiSXWmCdlr
zLbp94uhjRsUwxuZWebuTW9ZjPpBSGgE6DbfYgnZi9IxfCt7I96GbpeEikFiCLhy
JX2/yKglWIPhSsmVqapttSm+LqFR5kzPKc8Wv53QFUMrWjlIdTi9zuzd8o3MQ8kN
tgGp4MghkBktQpd4qIL1t5T6CliIH+YmhkkIC9Vs0k6pAgegoQDFreqwn+PukuVK
UQzB13T9Fl1ckbAUfjmK
=HNhT
-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/e1vbdp8-0003mi...@franck.debian.org

Accepted foreign 0.8.57-1 (source i386)

2013-10-29 Thread Dirk Eddelbuettel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 12:31:14 -0500
Source: foreign
Binary: r-cran-foreign
Architecture: source i386
Version: 0.8.57-1
Distribution: unstable
Urgency: low
Maintainer: Dirk Eddelbuettel e...@debian.org
Changed-By: Dirk Eddelbuettel e...@debian.org
Description: 
 r-cran-foreign - GNU R package to read/write data from other stat. systems
Changes: 
 foreign (0.8.57-1) unstable; urgency=low
 .
   * New upstream release
 .
   * debian/control: Set Standards-Version: to current version
Checksums-Sha1: 
 6bbbfc759f6078731ee09e752a428a97c8a7f3e4 1032 foreign_0.8.57-1.dsc
 af2ef075e493b2f346cb85c646dc922f2cb5cd30 329099 foreign_0.8.57.orig.tar.gz
 7446db5d67d67bcbc80ca0773daf1a70ac8f3913 3622 foreign_0.8.57-1.diff.gz
 ae570e82703cf37ba89bacbba4ea8b55430a6c86 207646 
r-cran-foreign_0.8.57-1_i386.deb
Checksums-Sha256: 
 59c7f80bd47f8404d2e25558df54372702f4b9b76e97b5b00c017108cbdffa0f 1032 
foreign_0.8.57-1.dsc
 a8fdea3e1f00be5da1eba2823cc573110f1ac6ff1a61a133473841c63961210b 329099 
foreign_0.8.57.orig.tar.gz
 6322f398ee3be8cfde2d184c6b365b5f75ba1a1be709e520b257295a3a22d83c 3622 
foreign_0.8.57-1.diff.gz
 49178bfbce708a544c858affdbbb8f3567e91feda4ffb167faca683f9da59510 207646 
r-cran-foreign_0.8.57-1_i386.deb
Files: 
 4aabaa348a7566783001d32b06f4acef 1032 gnu-r optional foreign_0.8.57-1.dsc
 549088213919a8c96671eb28e3b081fb 329099 gnu-r optional 
foreign_0.8.57.orig.tar.gz
 38986c29ce072abb0f5287c818dc391d 3622 gnu-r optional foreign_0.8.57-1.diff.gz
 a267fc432288e5e13fa5dc4c91ac6135 207646 gnu-r optional 
r-cran-foreign_0.8.57-1_i386.deb

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

iD8DBQFSb/E2CZSR95Gw07cRAnirAJ9VaxhryLa2HeTkMcof8P7cJuTAQQCePtTo
mALqM6WfqCePaEmUVqJ1e3g=
=x8Kr
-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/e1vbdou-0003ht...@franck.debian.org

Accepted libimobiledevice 1.1.5-2 (source amd64 all)

2013-10-29 Thread Chow Loong Jin

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Wed, 30 Oct 2013 01:42:21 +0800
Source: libimobiledevice
Binary: libimobiledevice4 libimobiledevice-dev libimobiledevice4-dbg 
python-imobiledevice libimobiledevice-utils libimobiledevice-doc
Architecture: source amd64 all
Version: 1.1.5-2
Distribution: unstable
Urgency: low
Maintainer: gtkpod Maintainers pkg-gtkpod-de...@lists.alioth.debian.org
Changed-By: Chow Loong Jin hyper...@debian.org
Description: 
 libimobiledevice-dev - Library for communicating with iPhone and iPod Touch 
devices
 libimobiledevice-doc - Library for communicating with iPhone and iPod Touch 
devices
 libimobiledevice-utils - Library for communicating with iPhone and iPod Touch 
devices
 libimobiledevice4 - Library for communicating with the iPhone and iPod Touch
 libimobiledevice4-dbg - Library for communicating with iPhone and iPod Touch 
devices
 python-imobiledevice - Library for communicating with iPhone and iPod Touch 
devices
Closes: 728151
Changes: 
 libimobiledevice (1.1.5-2) unstable; urgency=low
 .
   * [0052e46] Drop hal fdi file.
 That stuff doesn't work anymore. (Closes: #728151)
Checksums-Sha1: 
 ff0a990f4e09a89270cd054c19aa143bb556b7ad 2648 libimobiledevice_1.1.5-2.dsc
 a7c758c20559aa7142a176ae1c8adb687e0da4c0 13840 
libimobiledevice_1.1.5-2.debian.tar.gz
 26d8e5dda4585dd001a6899cb37bf25610f7b925 50862 
libimobiledevice4_1.1.5-2_amd64.deb
 4cfc7c62f100cf130f8ea4e9a8739cd0472e55de 53648 
libimobiledevice-dev_1.1.5-2_amd64.deb
 e756ebdfbff121f076b010dff5cba3cc2f7e40d7 638568 
libimobiledevice4-dbg_1.1.5-2_amd64.deb
 69eadc5c09ec6a2d1dc6b1f902da6ca4d65470e0 111430 
python-imobiledevice_1.1.5-2_amd64.deb
 0cfcfb3c6720ecac8ed4542366249da220c1e90c 64514 
libimobiledevice-utils_1.1.5-2_amd64.deb
 61538ca4334ffea69e75c3b93287c9e6e92fb3ad 78232 
libimobiledevice-doc_1.1.5-2_all.deb
Checksums-Sha256: 
 b846bbbaedfb039e8378da843f808ea785d59b7f14f70867cd234d9976c9ae07 2648 
libimobiledevice_1.1.5-2.dsc
 79e636e8a3913d1e36587a85243eb830d57e361d86532f37c64f31dfacb7e3ab 13840 
libimobiledevice_1.1.5-2.debian.tar.gz
 2fc4197667fa2b590c28981eda197695112fe8e0655a43b10180705600818efd 50862 
libimobiledevice4_1.1.5-2_amd64.deb
 f63c25e9bda2700949b19c385d9762344d34bbd7bf6317e21baa80c773f72b9e 53648 
libimobiledevice-dev_1.1.5-2_amd64.deb
 749dea7581b7627da95acbfbe7252858084a9be78ae0b07b31f038336160eb40 638568 
libimobiledevice4-dbg_1.1.5-2_amd64.deb
 de21b49902b102b448c6d302f8b883435464546c0690dea70e771fcc024142e2 111430 
python-imobiledevice_1.1.5-2_amd64.deb
 014b939068f6be914c5aca7ccb4aca48d1b8a31bf31beebb732de2d3c582f072 64514 
libimobiledevice-utils_1.1.5-2_amd64.deb
 dae870825f1e8dd2a4a62ebdb6200c722ca4399455d415f84f58a4dfb7fe0ffa 78232 
libimobiledevice-doc_1.1.5-2_all.deb
Files: 
 1de61fc1cdffa47903e66f7a28e8a01d 2648 libs optional 
libimobiledevice_1.1.5-2.dsc
 d5c5960cf926043ff73fa703a0735775 13840 libs optional 
libimobiledevice_1.1.5-2.debian.tar.gz
 d3df8f1c0c39377d73aeaab6ca27e904 50862 libs optional 
libimobiledevice4_1.1.5-2_amd64.deb
 836a844aa6409bf97817e45269980e31 53648 libdevel optional 
libimobiledevice-dev_1.1.5-2_amd64.deb
 7d4419c54a052aa24850bd1adcdfc8ea 638568 debug extra 
libimobiledevice4-dbg_1.1.5-2_amd64.deb
 737d89b476d529e3f3e0c472f8b80f94 111430 python optional 
python-imobiledevice_1.1.5-2_amd64.deb
 1898507093a9378cf9509aa8d0ba4b31 64514 utils optional 
libimobiledevice-utils_1.1.5-2_amd64.deb
 ef88f5ccb76de25c30ea2d5c33b6b81d 78232 doc optional 
libimobiledevice-doc_1.1.5-2_all.deb

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

iQIcBAEBAgAGBQJSb/Q/AAoJEPvVIltYh1Kh7fkP/06ywPuV/wzczrLG0o3YHWm5
tUTWxsHJXR1Gtb/M7mMg2hWZdoqPVe7o8pZfkUTMXQdgOYIXWA+mJoGn2wET8Z9S
E11sRTRVJ8DN5EZHnOhAyEInruV6iEKx9lXVJtkZx0uQ74Yf2RNGyk5bliZAUvz9
EzaodJZtb9ufS17pwM3TlJgqry3YjGVP346JaX2mep43fSpEFXqMYSIlomPFh3u+
YtFFjbnZ6ll7JuI9Ap9QBQTAdTCtMDBIvznN9ijXn5vvD6cluQwkPxigE4sf4lER
uz0Eui5oL3wjG253mGnhpXt2Tg3eIFPEiwwXIZA/K9cRf457Bg42CMteb0u2vHDN
bjSOmbw+hppkiMGTuiDWRHsi3qy9RmXqO2//vZBS9M90FT3FivCoPqaBhvXNSNSS
ukxLVgPzFnY72QLHdGyrieF/v3L1kPVdwaLhu0HfA2POUsJ+F08krrE+7ekkqyy+
ShEzbrJeAN0AW3J3hO62mkRLY0b+7pKFbGjATvcn6lxQz4Ti89FsyZNz9U1DZTKy
9xVxHsqP/3M6/CwrQvqoWAeCccbMo50byZEnrZXtG7QC/lxFWHlDwWSqFPtJCgxC
P8PnNlkANuOaX9yCUlxWzEruCvZ7nVZq0IH+8AcaGrTI6KPpaJkV8/81y+5DJ433
xUthX4CfZ5qw/Ch5f6PW
=YzWe
-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/e1vbddv-0006cb...@franck.debian.org

Accepted php-horde-css-parser 1.0.3-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 19:10:08 +0100
Source: php-horde-css-parser
Binary: php-horde-css-parser
Architecture: source all
Version: 1.0.3-1
Distribution: unstable
Urgency: low
Maintainer: Horde Maintainers pkg-horde-hack...@lists.alioth.debian.org
Changed-By: Mathieu Parent sath...@debian.org
Description: 
 php-horde-css-parser - ${phppear:summary}
Changes: 
 php-horde-css-parser (1.0.3-1) unstable; urgency=low
 .
   * New upstream version 1.0.3
Checksums-Sha1: 
 4680027722e2ea4d6beef14a1b7fd561f24eee9f 1429 php-horde-css-parser_1.0.3-1.dsc
 48708e692e5ae84e1e0a7d0ca9d95585b3052f24 28194 
php-horde-css-parser_1.0.3.orig.tar.gz
 c4d88e99b62935701b51abe92934f16258fd80d2 2034 
php-horde-css-parser_1.0.3-1.debian.tar.gz
 5aaf48bb6c2282ec031b62992878d9b4de4ce72c 26954 
php-horde-css-parser_1.0.3-1_all.deb
Checksums-Sha256: 
 161982a7e99cb5645f3d3930de855e3a498e15b2bae3953683c55b9fc4929598 1429 
php-horde-css-parser_1.0.3-1.dsc
 d0f7f6c854861c6f5bff8ae7bd39ce8b17e09674bebb3967c5f30598f410b0c8 28194 
php-horde-css-parser_1.0.3.orig.tar.gz
 bc36531eadcb8d9e83ca78d0c146f5eaf89bdcea69b83d2bcde1331715653f57 2034 
php-horde-css-parser_1.0.3-1.debian.tar.gz
 e18c022971d990413dfc748ca3214aa5b9b068048d4bdce72dc832fa11d955b2 26954 
php-horde-css-parser_1.0.3-1_all.deb
Files: 
 d3ac85cfa58afb1267657fcafbb183b4 1429 php extra 
php-horde-css-parser_1.0.3-1.dsc
 b8bb87fafc6320921b23567a26bb029d 28194 php extra 
php-horde-css-parser_1.0.3.orig.tar.gz
 58d50c094670290d47ee3f77234bb3bc 2034 php extra 
php-horde-css-parser_1.0.3-1.debian.tar.gz
 963fe597322f810489cd777ad61f6907 26954 php extra 
php-horde-css-parser_1.0.3-1_all.deb

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

iEYEARECAAYFAlJv+jMACgkQOW2jYf5fHX+vNACghsT5hcBJH0jALFaqG5RVdHud
HToAniFQIILofUePCoOgVyp9zOWanDKq
=d62G
-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/e1vbdsu-yd...@franck.debian.org

Accepted php-horde-core 2.10.2-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 19:07:25 +0100
Source: php-horde-core
Binary: php-horde-core
Architecture: source all
Version: 2.10.2-1
Distribution: unstable
Urgency: low
Maintainer: Horde Maintainers pkg-horde-hack...@lists.alioth.debian.org
Changed-By: Mathieu Parent sath...@debian.org
Description: 
 php-horde-core - ${phppear:summary}
Changes: 
 php-horde-core (2.10.2-1) unstable; urgency=low
 .
   * New upstream version 2.10.2
Checksums-Sha1: 
 0f3089a7bf133f04a4afe3027bd5fa27752a6876 1392 php-horde-core_2.10.2-1.dsc
 184f6103c863921ce84b4ab91f96a4cbc75234c8 1578488 
php-horde-core_2.10.2.orig.tar.gz
 8d4c06748778822a060b66d496ef8a07e6a1d07c 3627 
php-horde-core_2.10.2-1.debian.tar.gz
 ba523c8c3f65018e83adf90730dd99188a325835 1301768 
php-horde-core_2.10.2-1_all.deb
Checksums-Sha256: 
 11423b878af7740febc511760c9275ac9995ed89fae37ebafdf5f1bb764920d1 1392 
php-horde-core_2.10.2-1.dsc
 acf85147ea81f5ce61bc34e4628235b4cbac7c265b7cf3a6a71bef050cc0fc3e 1578488 
php-horde-core_2.10.2.orig.tar.gz
 cebcafedad5580d3837c7e3cf23fdbfb29c2cd6196ac8dfb80a604171d413225 3627 
php-horde-core_2.10.2-1.debian.tar.gz
 c82c01e74ea59a143519a6ad352680bb9f45d8a57db7eb656045ae1dbd301b61 1301768 
php-horde-core_2.10.2-1_all.deb
Files: 
 c2aa6af092442f079856737414c93707 1392 php extra php-horde-core_2.10.2-1.dsc
 72b82350937273091e2e208c615ccdc4 1578488 php extra 
php-horde-core_2.10.2.orig.tar.gz
 61f3bbe1598176d32b5d06c438d69cd5 3627 php extra 
php-horde-core_2.10.2-1.debian.tar.gz
 697c7bfd152de171eca765ab2ceb67ca 1301768 php extra 
php-horde-core_2.10.2-1_all.deb

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

iEYEARECAAYFAlJv+Y0ACgkQOW2jYf5fHX/1YQCfUAWpXqBJBxTY0Yx1WsHvHMyj
dKsAnA8d5MGlYn+oFP1+5avJ6urX2tfd
=hIvm
-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/e1vbdso-vm...@franck.debian.org

Accepted php-horde-prefs 2.5.1-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 19:12:05 +0100
Source: php-horde-prefs
Binary: php-horde-prefs
Architecture: source all
Version: 2.5.1-1
Distribution: unstable
Urgency: low
Maintainer: Horde Maintainers pkg-horde-hack...@lists.alioth.debian.org
Changed-By: Mathieu Parent sath...@debian.org
Description: 
 php-horde-prefs - ${phppear:summary}
Changes: 
 php-horde-prefs (2.5.1-1) unstable; urgency=low
 .
   * New upstream version 2.5.1
Checksums-Sha1: 
 cab4e0eda58eb429ffcc2c4afd5974da56222830 1374 php-horde-prefs_2.5.1-1.dsc
 b515f43d8f591de5314b61743c944c59fa5465e3 52746 
php-horde-prefs_2.5.1.orig.tar.gz
 59773c571e5cd5e602b13aea5240598e7db59157 2238 
php-horde-prefs_2.5.1-1.debian.tar.gz
 51e63f9c0dc3779e51c00c4867b6a6f90220482e 67270 php-horde-prefs_2.5.1-1_all.deb
Checksums-Sha256: 
 34764e89b7613eb58386babda91bd6e3999b9cd3399b51f70ffe9ed9ac664ca7 1374 
php-horde-prefs_2.5.1-1.dsc
 7765d04227ce6ffd298e653b346b1150f3b3e4487cd7de0d29c3582992b9d38e 52746 
php-horde-prefs_2.5.1.orig.tar.gz
 cf61896ddeda36540ad0a1f20bef2e54b256191838c751e75b9afb51a90c0c80 2238 
php-horde-prefs_2.5.1-1.debian.tar.gz
 e2f15fae1b1c086a309d8663083411a2b32ee4121cd2f60206c01f1317209383 67270 
php-horde-prefs_2.5.1-1_all.deb
Files: 
 a78582a4cf666826c065e156967f1bd7 1374 php extra php-horde-prefs_2.5.1-1.dsc
 1ce0d0f97fc3692ed8b8503262a2c453 52746 php extra 
php-horde-prefs_2.5.1.orig.tar.gz
 e2ae75af6b34d1bbe90151680e8c605d 2238 php extra 
php-horde-prefs_2.5.1-1.debian.tar.gz
 5082f649d27cf40d165ff537c4b7c6a0 67270 php extra 
php-horde-prefs_2.5.1-1_all.deb

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

iEYEARECAAYFAlJv+qgACgkQOW2jYf5fHX+AGgCggelT0W4Dsu5VakXEji7q0CKP
sKgAnjaBU1qm6OkziUpcyuJZ5ueC1r0N
=zPRM
-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/e1vbdsb-au...@franck.debian.org

Accepted firetray 0.4.7~rc1-1 (source all)

2013-10-29 Thread David Prévot

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 29 Oct 2013 12:57:58 -0400
Source: firetray
Binary: xul-ext-firetray
Architecture: source all
Version: 0.4.7~rc1-1
Distribution: unstable
Urgency: low
Maintainer: Debian Mozilla Extension Maintainers 
pkg-mozext-maintain...@lists.alioth.debian.org
Changed-By: David Prévot taf...@debian.org
Description: 
 xul-ext-firetray - system tray extension for Iceweasel, Icedove, etc.
Closes: 719438 719544
Changes: 
 firetray (0.4.7~rc1-1) unstable; urgency=low
 .
   [ David Prévot ]
   * New upstream version
   * Do not display release notes after installation
   * Add upstream changelog
   * Update packaging documentation
   * Bump standards version to 3.9.5
   * Update Homepage
   * Fix Depends (s/shlibs/xpi/)
   * Fix GPL-2 path
 .
   [ Sascha Girrulat ]
   * Update description in d/control (Closes: #719544)
   * Switch log level to info (Closes: #719438)
   * Naming of patches are now pq compatible
Checksums-Sha1: 
 900a090e2f41789b1eccaa2a675bc144e28f3bba 1707 firetray_0.4.7~rc1-1.dsc
 ededf1540856c9c4070eef6b0358b2d842545eb7 173188 firetray_0.4.7~rc1.orig.tar.xz
 8b0a2f93d4b19df7694b1f313b3d4825e44855ec 27239 
firetray_0.4.7~rc1-1.debian.tar.gz
 75f814094479aef5a746182421a3216f5512edbc 108426 
xul-ext-firetray_0.4.7~rc1-1_all.deb
Checksums-Sha256: 
 654adf6d0d2144bba3accb8dc4da34d21a76665159bfe6aca224a6ae37038e31 1707 
firetray_0.4.7~rc1-1.dsc
 435c5ae44d7e01cc78180922b99261f618bdd78f6168f058053a68f182e7d7f2 173188 
firetray_0.4.7~rc1.orig.tar.xz
 23e50d5f5bc0efa7a6fd045f58be126601ef85a82e4826e46f25cd91073fb931 27239 
firetray_0.4.7~rc1-1.debian.tar.gz
 3e1e66f80243f57873f34b8093528da29a823e224e50be3b45f6c9757ecd4429 108426 
xul-ext-firetray_0.4.7~rc1-1_all.deb
Files: 
 064c19664e86023f81b1dfdc91e543f2 1707 web extra firetray_0.4.7~rc1-1.dsc
 4ff5ad3458cd55e08a8d250bfb9f271d 173188 web extra 
firetray_0.4.7~rc1.orig.tar.xz
 dec055d488658a79cd24f4844e4c0aa3 27239 web extra 
firetray_0.4.7~rc1-1.debian.tar.gz
 c0b4a5303cb3278fe257aabd9839914c 108426 web extra 
xul-ext-firetray_0.4.7~rc1-1_all.deb

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

iQEcBAEBCAAGBQJSb/iPAAoJEAWMHPlE9r08Ij8IAK6NCxWUYl2WUyVujD0Pdhev
6GQtVoVhsEndMnbbVmXw+Vmdo8K+WDNsgMCnHBVDJwemWFEc+KYn82mXnk6fPIj8
vdLCJ/2DU4UiYQ3f6Uja9VWh4q7qSAuvqpWcPUusZrwwa7k+puD1490zdRkVKVJY
ojre1C54szsjSOCBjFM6bpyk6hICr/dOpHZQeFrLzr7hrFEp7/3GCVQmQ1NNRUFk
KivrUDNWpLlILuF7veRiHZ6bPvKHwwbJJEhvH/PyxHa693yyvYXzTcHYMQj1ez4R
ZIpuHWvD5M1NFSsYdCMl5SaEH4sSjj63ZRehgO+f/Hk/JxhPcA1gontZBQa8C/E=
=OJw2
-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/e1vbe6q-0003gy...@franck.debian.org

Accepted libsdl2-ttf 2.0.12+dfsg1-2 (source amd64)

2013-10-29 Thread Manuel A. Fernandez Montecelo

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 29 Oct 2013 18:18:49 +
Source: libsdl2-ttf
Binary: libsdl2-ttf-2.0-0 libsdl2-ttf-dbg libsdl2-ttf-dev
Architecture: source amd64
Version: 2.0.12+dfsg1-2
Distribution: unstable
Urgency: low
Maintainer: Debian SDL packages maintainers 
pkg-sdl-maintain...@lists.alioth.debian.org
Changed-By: Manuel A. Fernandez Montecelo m...@debian.org
Description: 
 libsdl2-ttf-2.0-0 - TrueType Font library for Simple DirectMedia Layer 2, 
libraries
 libsdl2-ttf-dbg - TrueType Font library for Simple DirectMedia Layer 2, 
debugging
 libsdl2-ttf-dev - TrueType Font library for Simple DirectMedia Layer 2, 
development
Closes: 727437
Changes: 
 libsdl2-ttf (2.0.12+dfsg1-2) unstable; urgency=low
 .
   * Build-Depends on pkg-config
   * Do not call dh_autoreconf with ./autogen.sh as parameter, to force
 using new config.{sub,guess} files, which important when having new
 architectures (Closes: #727437)
Checksums-Sha1: 
 c5e4dc75560f651afa449ab2b1fcbc87885506cf 2225 libsdl2-ttf_2.0.12+dfsg1-2.dsc
 425b5223aa48ea3788423b58751c797e19ea2ab8 2923 
libsdl2-ttf_2.0.12+dfsg1-2.debian.tar.gz
 1509b7c8c444d2d8124cd2da97e6ed1c552013ee 14740 
libsdl2-ttf-2.0-0_2.0.12+dfsg1-2_amd64.deb
 7c02d165a0054556dc1ae50fc4f2095d4daccf71 36576 
libsdl2-ttf-dbg_2.0.12+dfsg1-2_amd64.deb
 d23fd697973ae44483fb2a4e259a43daf3e0fb9d 20272 
libsdl2-ttf-dev_2.0.12+dfsg1-2_amd64.deb
Checksums-Sha256: 
 ce0b9c457d34d344f099a4b64dfea3781751def27e143b34b8fb8b9bb7d57aa6 2225 
libsdl2-ttf_2.0.12+dfsg1-2.dsc
 ce28c93952bfa59bf0f8fdff9bb97d9b3cb1f76e0c45469d38b03bc7d3a53031 2923 
libsdl2-ttf_2.0.12+dfsg1-2.debian.tar.gz
 00fa2a83da4932699a13364ab95d667344df1c3c645efdbce281ce712a3e0208 14740 
libsdl2-ttf-2.0-0_2.0.12+dfsg1-2_amd64.deb
 6d249930853058bec0152f9d8385fcebc474324355ec5c8e03b43bcb7ec6b74e 36576 
libsdl2-ttf-dbg_2.0.12+dfsg1-2_amd64.deb
 c0f26d49cfc523d402e7b12238a4cce8368811484cc181452dca6e932c6c69ad 20272 
libsdl2-ttf-dev_2.0.12+dfsg1-2_amd64.deb
Files: 
 7c11ba3d2a53707a51c1835cd36d5d6f 2225 libs optional 
libsdl2-ttf_2.0.12+dfsg1-2.dsc
 52a1290a2ebac76f55d1b75856e247b5 2923 libs optional 
libsdl2-ttf_2.0.12+dfsg1-2.debian.tar.gz
 fda7680e504f6d721afaf01d130f0584 14740 libs optional 
libsdl2-ttf-2.0-0_2.0.12+dfsg1-2_amd64.deb
 49626558ad95416183f1938ae333eae8 36576 debug extra 
libsdl2-ttf-dbg_2.0.12+dfsg1-2_amd64.deb
 49e00f705217454bab43c02189f335fb 20272 libdevel optional 
libsdl2-ttf-dev_2.0.12+dfsg1-2_amd64.deb

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

iQIcBAEBCgAGBQJSb/ynAAoJEH92BqRF3KgOshAQAJuXPClevFxuUdWPV4Jc+vLh
+a98zfp4wYoL3cgVhqRJjb8CghRogZEajJGBaSmn5wFeg/TvVBRqzEe4uKB2YhX0
7/WL+clK/9xBC1xmyPZla2Sarf0nQx4Hed0VZgtWcYYYpcbXC46aQoyzkrnoGFaa
L+UM2aQWaM6y96P23UYCXzBSdya+x/xCWO05GC7LyAk+WYAN2J5ckFhUOMTsQT6F
F80Z1Wrlj89S3dAKA7Uob5E2/iI5iQUw9A1o8tihVcnhwP8z6IMRYAhLk3EPOk4j
DhL7Ob4BT6ADtnXqxqj8lQwjK43hxgivthOQtuaFmjqzJdMJYRsNrUOYC/RQG7Of
cJ6G0bjk+ON4QY3gkpAzscywKLfveyRwtRfjh9cqWuVkbVcJwBOIJRMTlR9QuEVf
nKU1enHLEUk0+ubNsYn/ETqzvc4VG627f3Kunf7mD0bqZgsaAvVtxhPFvqK3mj1+
2jAEo1tChmWkb/CmlYJLHIbjydtqYSp9OaoCbapdnjfWTrdc/31rVOg3eopxwUZu
joOpl6PjmHLpyDpiTdsabR7xfmCedQFPCZvjYrxQTgQCZGPkVP8mPFRijVg2QVDA
vSufqKoMecTitEr6C86jbhUR9tg+js0stB3b/d7BrZkBjpsUShYIqkHsgYBESr3r
vIQm1fvcpPW6UYC5KpSz
=0CMA
-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/e1vbe73-0003rb...@franck.debian.org

Accepted php-horde-vfs 2.1.2-1 (source all)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 29 Oct 2013 19:24:00 +0100
Source: php-horde-vfs
Binary: php-horde-vfs
Architecture: source all
Version: 2.1.2-1
Distribution: unstable
Urgency: low
Maintainer: Horde Maintainers pkg-horde-hack...@lists.alioth.debian.org
Changed-By: Mathieu Parent sath...@debian.org
Description: 
 php-horde-vfs - ${phppear:summary}
Changes: 
 php-horde-vfs (2.1.2-1) unstable; urgency=low
 .
   * New upstream version 2.1.2
Checksums-Sha1: 
 b11816f49823a636cc330c127f041b1ca1f1b0d5 1352 php-horde-vfs_2.1.2-1.dsc
 02467f5a6d09098021e64a6335cdab68b9a976f7 73025 php-horde-vfs_2.1.2.orig.tar.gz
 d796b92bd08ecbc9410d91a1c6b09bb882598dcd 2304 
php-horde-vfs_2.1.2-1.debian.tar.gz
 4971dccad0ae82777be4a80d55c1ca2e75799736 89590 php-horde-vfs_2.1.2-1_all.deb
Checksums-Sha256: 
 a7d5d3ed72b909c75ea27cf2f85f89e4861c255a117cd97bdaccb520f007a77f 1352 
php-horde-vfs_2.1.2-1.dsc
 47cb7e4f91cc726417e74d97fef1f2e89cb63dbfc43f16beabf8cb21bdafc5a7 73025 
php-horde-vfs_2.1.2.orig.tar.gz
 a43537412043cf8458d7e7096e012fd4523a742a12eab014bac2fcf52d2ba5ec 2304 
php-horde-vfs_2.1.2-1.debian.tar.gz
 177ceeb6575d15e1c34df6c6b6f8e14592ff8ce5f28722aaa842c06fe3a85b7f 89590 
php-horde-vfs_2.1.2-1_all.deb
Files: 
 c456a4eb9e499aeb4270f2d2852c77c9 1352 php extra php-horde-vfs_2.1.2-1.dsc
 af581eed8a2e49cd6bca80ce35b4a1e3 73025 php extra 
php-horde-vfs_2.1.2.orig.tar.gz
 df552e65845770e9a142bd44c2ed466f 2304 php extra 
php-horde-vfs_2.1.2-1.debian.tar.gz
 fa5a82a250692822e4595ea8d65896b5 89590 php extra php-horde-vfs_2.1.2-1_all.deb

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

iEYEARECAAYFAlJv/V0ACgkQOW2jYf5fHX+qAwCfSD6KN+fsQI64uIeZoNX4qSYm
k8gAn3gJGBqFHSnp1WboII6YmfSgE5Pp
=tbhZ
-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/e1vbe7i-0003gk...@franck.debian.org

Accepted php-horde-timezone 1.0.4-1 (source all)