date:20121025

Steve Langasek vor...@debian.org writes:

 So, what will you do if:
 - previous maintainer goes MIA
 - Somebody wants to hija^W salvage the package and starts the procedure
 - Nobody votes for this to happen...

 Should we then leave the package forever unmaintained?
 I don't think this is reasonable...

 And I don't think this is a realistic scenario.  Why can't you find N other
 DDs who agree with you that the package should be taken over?  This is not a
 high bar.  I don't really have any sympathy for the argument that the entire
 Debian project might decide not to care about the package you're concerned
 about and therefore you need to take matters into your own hands and take it
 over.

Not a high bar, but still far more work than it needs to be. Salvaging
is meant for cases where it is desperately needed, which, I believe, are
quite clear cases. I find it unreasonable to demand ACKs, when one
already went to great lengths to solve the issue without taking over
maintainership.

If there's dispute later, any change can be reverted then, or taken to
the tech-ctte. I do not see any reason to make the process long and
tedious, we should *NOT* punish the salvager for trying to bring a
package back to life. We should make that as easy and painless as
possible, once other options failed.

Would a mistake happen, it can and should be corrected, but that should
be the exception, not the norm. And as such, the process should not
follow the exceptional cases, but the most common ones.

So while I do agree that ACKs/NACKs can be helpful, making them
mandatory would - I believe - be counter productive. If noone cared
enough to respond with neither ACK nor NACK, go ahead. Not voting means
one does not care. It is entirely possible that the vast majority of the
project won't care about a particular package, and that should not be an
obstacle on the path of salvaging it.

-- 
|8]


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Steve Langasek vor...@debian.org writes:

 On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
  I disagree on this point.  If you can't get anyone to ack that you should 
  go
  ahead with the orphaning, then the system is not working as designed and
  consensus has not been achieved.  It's then incumbent on the person looking
  to orphan the package to rattle the cage and get developers to pay
  attention.

 On the other hand, it is already hard to find people willing to review
 other peoples work. Mandating acks means trusting that there will be
 enough manpower to review something potentially unknown. I can't see
 that happening reliably. It also makes the process a whole lot more
 complicated than it needs to be,

 No, it makes the process based on *consensus*, which is a minimum
 requirement.

It also means that the salvager has to do more work. By the time we get
to salvaging, other means of getting the package fixed/updated have
already been exhausted - that's quite a lot of work already, and by that
time, it should be very clear that salvaging is the way to go forward.

I do agree that the salvager should seek consensus, and should make a
reasonable effort to get some feedback on his/her intention, BUT I would
not make that mandatory (seeking acks - yes; not being able to go
forward until N acks - no), as that will stall the process for far too
long in case of less popular packages (and as far as I see, those less
popular packages would benefit most from the salvaging process).

THAT is what I'm concerned about.

And seriously, if noone ACKs or NACKs a salvaging proposal for an
extended period of time, to me, that means noone cares enough. If noone
cares, noone minds, then I would put my trust behind the developer, to
know what he's doing, and let him proceed. Would a mistake be made, that
can always be corrected.

 which in turn allows the package to suffer unmaintainance longer,
 decreasing the distributions overall quality.

 As said elsewhere in the thread, the process needs to be easy and
 efficient. Hunting ACKs is neither easy, nor efficient.

 The debian-qa list served this purpose fine for *years*.  It's not
 acceptable to use handwavy assertions about manpower to justify an
 antisocial process.

If the debian-qa list continues to serve this purpose well, then there
is no issue: we'll never see the case I'm worried about, and I'll be the
happiest person on earth.

If we do end up in such situations, though...

-- 
|8]


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Bart Martens ba...@debian.org writes:

 On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
 Steve Langasek vor...@debian.org writes:
 
  On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote:
   4. When/if consensus has been reached, the package can be orphaned by
  retitling and reassigning the ITO bug accordingly.
 
  I fear a bit the situation nobody care enough to comment, being
  interpreted as lack of consensus. But I do think in that case we should
  _eventually_ allow the orphaning to happen (after all 1/0  3/1 ACK/NACK
  /joke).
  Any suggestion on how to word that properly, without adding yet another
  timeout rule carved in stone?
 
  I disagree on this point.  If you can't get anyone to ack that you should 
  go
  ahead with the orphaning, then the system is not working as designed and
  consensus has not been achieved.  It's then incumbent on the person looking
  to orphan the package to rattle the cage and get developers to pay
  attention.
 
 On the other hand, it is already hard to find people willing to review
 other peoples work. Mandating acks means trusting that there will be
 enough manpower to review something potentially unknown. I can't see
 that happening reliably.

 I think that sufficient DDs will review the ITOs.  Note that most work is
 already done by the ITO submitter.  Sponsoring a package at mentors (review
 other peoples work) is, in my opinion, much more work than reading an ITO and
 sending an ACK.

On the other hand, ACKing an ITO is much more responsibility, becasue
it's not only about a package, but about taking over a package too. An
ITO will also contain quite a lot of info about previous attempts at
updating the package - that's not simple to review either. It is less
technical too, which can be off-putting to some.

 It also makes the process a whole lot more
 complicated than it needs to be, which in turn allows the package to
 suffer unmaintainance longer, decreasing the distributions overall
 quality.

 It's not so complicated to find three DDs to agree with the ITO.

Not terribly so, perhaps. But if the salvager has already gone to great
lengths to save a package, pushing even more work on him is not going to
help.

(Mind you, I'm not against the ACK/NACK system, I'm only arguing for
being able to proceed without N acks after a reasonable amount of time.)

 As said elsewhere in the thread, the process needs to be easy and
 efficient. Hunting ACKs is neither easy, nor efficient.

 The proposed text is quite easy, in my opinion.

Indeed, it is. Partly because as far as I understand it, it only
recommends a 3/1 majority, and does not demand it. That's perfectly
fine.

-- 
|8]


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Andreas Tille

On Thu, Oct 25, 2012 at 10:10:09AM +0200, Lucas Nussbaum wrote:
 However, so far, it seems that the discussion is split between people
 that think it would work, and people that think it would not work.
 Maybe we could try for a few months, and if it does not work, fix it?

+1

Kind regards

   Andreas. 

-- 
http://fam-tille.de


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Scott Kitterman

On Thursday, October 25, 2012 10:15:48 AM Lucas Nussbaum wrote:
 On 24/10/12 at 08:17 -0400, Scott Kitterman wrote:
  That could work either way.  If you're in such a rush to build consensus
  you could change 3/1 ACK/NACK ratio to without objection (objections 
  result in disputes resolved by the tech ctte) and have a +1 from me.
  
  The problem is that once in place these rules are rather harder to change.
   While you have in mind a certain set of packages this rule should be
  applied to, there's nothing preventing it from being applied in incorrect
  cases.
  
  The popularity contest aspect of the current rule creates a risk that
  maintainers that make unpopular, but technically correct, choices will
  have their packages orphaned out from under them.
 I am quite sure that we will find many DDs (me included) willing to NACK
 all proposals of stealing packages from technically-correct, active,
 but unpopular maintainers. And you can even drop technically-correct
 from my sentence. The goal of this proposal is not to substitute for the
 technical committee.
 
 Really, I don't see how a cabal could abuse this recommended procedure
 without enough people to stop it noticing.

It may not be the goal of this proposal to substitute for the technical 
committee, but, in part, it would.  If there is a 3:1 dispute over if a 
package should be orphaned, this process would take that dispute out of the 
hands of the technical committee because the voting ratio was adequate.

I fundamentally disagree with the idea of a popularity contest over the 
adequacy of package maintenance.  In practice, I think people will very rarely 
object when packages are clearly not maintained, so the practical difference 
between 3:1 ratio and without objection or go to the technical committee is 
not much.  Where I believe it will make a difference is in preventing 
misapplication of this process, particularly trying to resolve social issues 
through a process that is supposed to be technical.

Why not start with a without objection standard and see how it works?  If it 
doesn't work, the consequence would be most work for the technical committee.  
If they complain/can't keep up, then we could look into a voting alternative.

Scott K

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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ian Jackson

Scott Kitterman writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
packages):
 Why not start with a without objection standard and see how it
 works?

I absolutely agree with this.

If we adopt a without objection standard then the whole process can
be a lot simpler too.  There is no need for acks if any one nack is
sufficient to stop the process.

I'm also not that keen on the idea that the outcome is to orphan the
package.  The salvager should surely be adding themselves as an
Uploader.

So I would have this process

  1. Package is in the salvager's opinion in need of substantial and
 important attention; maintainer has been inactive on this
 package, and in need of help with it, for some time.
 It doesn't need to be an objective criterion.

  2. Notify various places (-devel and the BTS, at least)

  3. Wait for objections

  4. If no objections, add salvager to Uploaders.

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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ian Jackson

Andreas Tille writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
packages):
 On Thu, Oct 25, 2012 at 10:10:09AM +0200, Lucas Nussbaum wrote:
  However, so far, it seems that the discussion is split between people
  that think it would work, and people that think it would not work.
  Maybe we could try for a few months, and if it does not work, fix it?
 
 +1

I don't think this is a good idea because it may actually restrict
rather than empower.  At the moment much of the stuff in this area is
what you can get away with.  If you can say I asked around and made
sure everyone was aware, and it was clear no-one was objecting then
anyone who comes along later with a grievance is going to get short
shrift from the rest of the project.

Whereas now we're proposing codifying a policy that requires explicit
acks even for unopposed actions.

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

Updating xflr5 with new DMUA interface

2012-10-25 Thread Koichi Akabe

Hi,

I want to update xflr5 package which has the DMUA field. I'll remove
this field, because it will be stopped working [1].
Could you give me a permission to upload this package using the new
interface?

I attached a diff between 6.07-1 and 6.08-1~exp1. Please see it for more
details.

[1] http://lists.debian.org/debian-devel-announce/2012/09/msg8.html

Thanks,
-- 
Koichi Akabe
  vbkaisetsu at {gmail.com, debian.or.jp}
diff -urN ./xflr5-6.07+svn513/debian/changelog ./xflr5-6.08+svn531/debian/changelog
--- ./xflr5-6.07+svn513/debian/changelog	2012-06-29 18:56:49.815997255 +0900
+++ ./xflr5-6.08+svn531/debian/changelog	2012-10-25 21:48:22.862217644 +0900
@@ -1,3 +1,18 @@
+xflr5 (6.08+svn531-1~exp1) experimental; urgency=low
+
+  * New upstream release
+  * debian/control
+   - remove DM-Upload-Allowed
+   - update Standard-Version to 3.9.4
+  * debian/patches/01_set_targetpath.patch
+   - update the file path
+  * debian/xflr5.docs
+   - remove because the upstream ReadMe was removed
+  * debian/watch
+   - move comments from debian/source/lintian-overrides
+
+ -- Koichi Akabe vbkaise...@gmail.com  Thu, 25 Oct 2012 21:48:12 +0900
+
 xflr5 (6.07+svn513-1) unstable; urgency=low
 
   * New upstream release
diff -urN ./xflr5-6.07+svn513/debian/control ./xflr5-6.08+svn531/debian/control
--- ./xflr5-6.07+svn513/debian/control	2012-06-29 08:07:51.0 +0900
+++ ./xflr5-6.08+svn531/debian/control	2012-10-23 15:41:28.861137429 +0900
@@ -2,9 +2,8 @@
 Section: science
 Priority: extra
 Maintainer: Koichi Akabe vbkaise...@gmail.com
-DM-Upload-Allowed: yes
 Build-Depends: debhelper (= 9.20120417), docbook-to-man, libqt4-dev, libgl1-mesa-dev, libqt4-opengl-dev (= 4.6.0), translate-toolkit
-Standards-Version: 3.9.3
+Standards-Version: 3.9.4
 Homepage: http://www.xflr5.com/xflr5.htm
 
 Package: xflr5
diff -urN ./xflr5-6.07+svn513/debian/patches/01_set_targetpath.patch ./xflr5-6.08+svn531/debian/patches/01_set_targetpath.patch
--- ./xflr5-6.07+svn513/debian/patches/01_set_targetpath.patch	2012-06-29 17:14:58.156347166 +0900
+++ ./xflr5-6.08+svn531/debian/patches/01_set_targetpath.patch	2012-10-23 16:01:57.833094035 +0900
@@ -3,8 +3,8 @@
  to set the installation path /usr/bin for the binary.
 Last-Update: 2012-06-21
 
 xflr5-6.07.orig/xflr5_607.pro
-+++ xflr5-6.07/xflr5_607.pro
+--- xflr5-6.08.orig/xflr5_608.pro
 xflr5-6.08/xflr5_608.pro
 @@ -244,7 +244,7 @@ unix {
  
  # MAKE INSTALL
diff -urN ./xflr5-6.07+svn513/debian/rules ./xflr5-6.08+svn531/debian/rules
--- ./xflr5-6.07+svn513/debian/rules	2012-06-29 18:58:35.047993539 +0900
+++ ./xflr5-6.08+svn531/debian/rules	2012-10-23 15:43:38.065132868 +0900
@@ -8,7 +8,7 @@
 	lrelease -nounfinished $(CURDIR)/translations/xflr5v6_fr.ts -qm $(CURDIR)/translations/xflr5v6_fr.qm
 	lrelease -nounfinished $(CURDIR)/translations/xflr5v6_de.ts -qm $(CURDIR)/translations/xflr5v6_de.qm
 	lrelease -nounfinished $(CURDIR)/translations/xflr5v6_ja.ts -qm $(CURDIR)/translations/xflr5v6_ja.qm
-	docbook-to-man debian/xflr5.sgml  debian/xflr5.1
+	docbook-to-man $(CURDIR)/debian/xflr5.sgml  $(CURDIR)/debian/xflr5.1
 
 override_dh_auto_clean:
 	dh_auto_clean
diff -urN ./xflr5-6.07+svn513/debian/source/lintian-overrides ./xflr5-6.08+svn531/debian/source/lintian-overrides
--- ./xflr5-6.07+svn513/debian/source/lintian-overrides	2012-06-29 17:19:55.480336668 +0900
+++ ./xflr5-6.08+svn531/debian/source/lintian-overrides	1970-01-01 09:00:00.0 +0900
@@ -1,3 +0,0 @@
-# The upstream doesn't provide source code tar ball. get-orig-source
-# target on debian/rules describes how to get the source.
-debian-watch-file-is-missing
diff -urN ./xflr5-6.07+svn513/debian/watch ./xflr5-6.08+svn531/debian/watch
--- ./xflr5-6.07+svn513/debian/watch	1970-01-01 09:00:00.0 +0900
+++ ./xflr5-6.08+svn531/debian/watch	2012-10-23 16:29:34.849035525 +0900
@@ -0,0 +1,2 @@
+# The upstream doesn't provide source code tar ball. get-orig-source
+# target on debian/rules describes how to get the source.
diff -urN ./xflr5-6.07+svn513/debian/xflr5.docs ./xflr5-6.08+svn531/debian/xflr5.docs
--- ./xflr5-6.07+svn513/debian/xflr5.docs	2011-06-14 22:23:08.0 +0900
+++ ./xflr5-6.08+svn531/debian/xflr5.docs	1970-01-01 09:00:00.0 +0900
@@ -1 +0,0 @@
-ReadMe.txt


pgprY1qTZVVrZ.pgp
Description: PGP signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Thibaut Paumard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 25/10/2012 15:50, Ian Jackson a écrit :
 I'm also not that keen on the idea that the outcome is to orphan
 the package.  The salvager should surely be adding themselves as
 an Uploader.

Is that in addition to or instead of orphaning the package?

If someone notices that a package is in need of greater attention, but
cannot commit to attending it themselves, it's important that the
packages is marked at least as needing help.

I understand the entire point here is to mark packages which are
effectively abandoned as orphaned, so that others can see them in the
wnpp news for instance.

It's certainly better if a new foster maintainer can be found for the
package right away, but it should IMHO not be mandatory. Prospective
maintainers, those that want to help Debian but don't know were to
start, will be able to adopt an orphaned package, but not to salvage
one in most cases.

Take it as a three body encounter:
 - a package with no effective maintainer;
 - a developer who notices the problem;
 - a prospective maintainer.

Regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQiUq7AAoJEJOUU0jg3ChAS4sP/0VALbDFBRjSNJR1HNWfwpwx
QPx9PJ55Lms5a9xfMDAM2XL8If0RVV77bl3o39WIEGYSDIhwYtQFhiufCigmcK7w
VZE3rvvWUCoayjswEsbZn0LGzA8oQUe6Q6yVlpg7uiD4V8gHX/MFbULt5JageJ6L
a8N+jzJ+NkXxdwhHg9L1B/3+uNm91+7OxwbhFktk7pI9ZjCuTRYyG7c7NOwpJdTk
K11lec/bpensjcfJB3c9Ba5o7BcButys17GucxY2A1m/CpQLB1SDerfl9ZZEYbqx
Dw7poAbqfUbVxNEYnxHCzAKvJ3Apaiat8IoFB/x9XE3FgK0ItGoVdwQt01s/ui3i
4LVNHMZ1HFQX8wSsLhpc0akOQ+pWBskjakFZqwATCOrexhlhFJRUtn7uKXInEm50
K6q1vHakajFyHFG5qFZAWhZxwtRQG4CUDhFSYjqEokSg1xJFm7ZD+ujUj7SOD0Tc
FlzgYZxTuJlTHE2pbySMKVnPuniwyOW+R6Lkl5kkzZWuiKJ0jaHhDAIcG68CgmHn
wWCjenPVI/9QYtNqPLd/2qxJn6j38q7yUCzIwdDcvcqa7MkRvA/VIM263pG8wiqu
COo8ks522s9bdPL5w9LBBAWyfysoNzzs8HGUgJg3Tz011/SdbKpZxnP/E1GejuBT
6DXRNtjCCOGiYpRD8uhD
=5uyj
-END PGP SIGNATURE-


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ian Jackson

Thibaut Paumard writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
packages):
 Le 25/10/2012 15:50, Ian Jackson a écrit :
  I'm also not that keen on the idea that the outcome is to orphan
  the package.  The salvager should surely be adding themselves as
  an Uploader.
 
 Is that in addition to or instead of orphaning the package?

Instead.

 If someone notices that a package is in need of greater attention, but
 cannot commit to attending it themselves, it's important that the
 packages is marked at least as needing help.

Well, no, I don't think so.

Whether a package is in need of greater attention is not a hard and
fast objective thing.  It's to a large part subjective.  Perhaps the
maintainer thinks it's more or less fine, or at least low enough
priority that the problems are tolerable.

It's one thing to say this package is in need of attention which I am
prepared to commit to providing.  It's quite another to say this
package is in need of attention but I'm not going to do anything other
than say it's a problem.

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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Andreas Tille

On Thu, Oct 25, 2012 at 03:00:11PM +0100, Ian Jackson wrote:
 Andreas Tille writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
 packages):
  On Thu, Oct 25, 2012 at 10:10:09AM +0200, Lucas Nussbaum wrote:
   However, so far, it seems that the discussion is split between people
   that think it would work, and people that think it would not work.
   Maybe we could try for a few months, and if it does not work, fix it?
  
  +1
 
 I don't think this is a good idea because it may actually restrict
 rather than empower. ...

My +1 was for try for a few months.  We currently have a set of
theories about different options and we should start some experiment
whether one of it is right or will be proven wrong.  I do not think that
we can find out by pure discussion of those different options.

Kind regards

   Andreas.

-- 
http://fam-tille.de


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Whether a package is in need of greater attention is not a hard and
 fast objective thing.  It's to a large part subjective.  Perhaps the
 maintainer thinks it's more or less fine, or at least low enough
 priority that the problems are tolerable.

Then the maintainer has many options, including but not limited to
NACK-ing the ITO. One has a lot of possibilities even before it comes to
filing an ITO.

 It's one thing to say this package is in need of attention which I am
 prepared to commit to providing.  It's quite another to say this
 package is in need of attention but I'm not going to do anything other
 than say it's a problem.

There is, indeed a difference, but the latter allows someone else
(potentially a non-DD) to take over the package, and make it visible
that the package is in need of a new maintainer. That alone is already a
tremendous improvement compared to papering over the issue.

-- 
|8]


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Scott Kitterman



Gergely Nagy alger...@balabit.hu wrote:

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Whether a package is in need of greater attention is not a hard and
 fast objective thing.  It's to a large part subjective.  Perhaps the
 maintainer thinks it's more or less fine, or at least low enough
 priority that the problems are tolerable.

Then the maintainer has many options, including but not limited to
NACK-ing the ITO. One has a lot of possibilities even before it comes
to
filing an ITO.

AIUI, with the current proposal, as long as three DDs think it should be 
orphaned, the maintainer's objection is irrelevant.

Scott K


-- 
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/73a36e57-0c39-4688-bf88-bc7183ba7...@email.android.com

orphaned packages

2012-10-25 Thread vangelis mouhtsis


Hi,
Can please someone explain why a package should be orphaned
from maintaining? (i hope the reason is not lack of maintainers)

regards
gnugr

ITP: python-icalendar -- iCalendar parser and generator

2012-10-25 Thread Per Andersson

Package: wnpp
Severity: wishlist
Owner: Per Andersson avtob...@gmail.com

* Package name: python-icalendar
  Version : 3.1
  Upstream Author : Plone Foundation
* URL : http://icalendar.readthedocs.org/
* License : BSD
  Programming Lang: Python
  Description : iCalendar parser and generator

 The icalendar package is a parser and generator of iCalendar files
 for use with Python.
 .
 Timezones are fully supported for serialization and deserialization.


--
Per


-- 
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/CABYrXSS9k74+fa-A-RPYr==c-t8c_a4wveazfumwj7u4+5f...@mail.gmail.com

Re: orphaned packages

2012-10-25 Thread Peter Samuelson


[vangelis mouhtsis]
 Can please someone explain why a package should be orphaned
 from maintaining? (i hope the reason is not lack of maintainers)

Yes it is.  Or more precisely, every package needs a maintainer with:

1) the skills to maintain it (familiarity not only with Debian
   packaging in general, but with the implementation language, the
   frameworks, the problem domain, sometimes specific hardware or
   other resources);

2) the time to maintain it;

3) a desire to maintain it.

For any given package in Debian, it is quite possible that there are
people with the appropriate skills and experience, people with time,
and people with interest, but nobody with all three.


-- 
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/20121025181918.gg4...@p12n.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Patrick Ouellette

On Thu, Oct 25, 2012 at 09:51:16AM +0200, Thibaut Paumard wrote:
 
 So yes, I say long silence from the entire community *including the
 package maintainer(s)* probably means it's safer to orphan the package
 than not. I would probably send a few pings during the one month
 period though. I would also be careful during vacation periods,
 especially if the maintainer is not a DD and therefore can not easily
 announce VAC.
 

Can you define in absolute terms what are the vacation periods that
apply to anyone/everyone of all cultures and religious backgrounds in
the world in a way that is acceptable to everyone?

A long silence is defined as how many hours/days/weeks/months/years?

All the pings in the world won't help if you are sending them via
a path that discards them.  I know several large US ISPs that automatically
reject what they consider SPAM without the customer's knowledge.  If
the sender of the ping is on a SPAM list for one of them, the ping
will never get to the maintainer, and *no one* will know.
(From personal experience I can tell you mail from the Debian list addresses
does get caught in these SPAM filters and no, the ISPs won't change the
policy.)

Pat


-- 
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/20121025174752.gb19...@flying-gecko.net

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 9:50 AM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
Scott Kitterman writes (Re: [SUMMARY/PROPOSAL] Orphaning another
maintainer's packages):
Why not start with a without objection standard and see how it
works?

I absolutely agree with this.

If we adopt a without objection standard then the whole process can
be a lot simpler too. There is no need for acks if any one nack is
sufficient to stop the process.

I'm also not that keen on the idea that the outcome is to orphan the
package. The salvager should surely be adding themselves as an
Uploader.

So I would have this process

1. Package is in the salvager's opinion in need of substantial and
important attention; maintainer has been inactive on this
package, and in need of help with it, for some time.
It doesn't need to be an objective criterion.

2. Notify various places (-devel and the BTS, at least)

3. Wait for objections

4. If no objections, add salvager to Uploaders.

I would prefer to see even more autonomy for the salvager and less
bugging of various lists (ITPs on -devel are already distracting
enough). With that, I would like to suggest rewriting steps 2-4 as:

2. Salvager uploads liberal (10-day delayed) nmus as needed to bring
the package into a better maintained state.

3. After a period of 3 months of contributing as an nmuer or with
maintainers approval prior to that, salvager is free to add
himself/herself as a package uploader.

4. After 6 more months without contribution from the original
maintainer, the salvager is free at his or her discretion to
remove the original maintainer.

5. The salvager should do his/her best to address original mantainer's
concerns in a manner that would please them, and any unresolvable
conflicts should be deferred to the Technical Committee.

Note that this process was pretty much the one I followed to salvage
wine. Also, the python maintainer Tech Committee decision would have
been much easier if the people complaining had been following this
kind of process where there would have been evidence that their nmus
were contributing to a better package. It eliminates the complaints
without action issue.

Best wishes,
Mike

--
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/CANTw=MOC+7rn9jk=xoye_vrycr+ykcmfzyxohdxrreawgqb...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Dmitry Smirnov

On Fri, 26 Oct 2012 06:09:55 Michael Gilbert wrote:
 I would prefer to see even more autonomy for the salvager and less
 bugging of various lists (ITPs on -devel are already distracting
 enough).  With that, I would like to suggest rewriting steps 2-4 as:
 
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.
 
 3.  After a period of 3 months of contributing as an nmuer or with
 maintainers approval prior to that, salvager is free to add
 himself/herself as a package uploader.
 
 4.  After 6 more months without contribution from the original
 maintainer, the salvager is free at his or her discretion to
 remove the original maintainer.
 
 5.  The salvager should do his/her best to address original mantainer's
 concerns in a manner that would please them, and any unresolvable
 conflicts should be deferred to the Technical Committee.
 
 Note that this process was pretty much the one I followed to salvage
 wine.  Also, the python maintainer Tech Committee decision would have
 been much easier if the people complaining had been following this
 kind of process where there would have been evidence that their nmus
 were contributing to a better package.  It eliminates the complaints
 without action issue.
 

Thanks Michael, this is clear, straightforward and effective strategy.
I like it. The only question is what to do (and how long to wait) before first 
NMU upload.

Regards,
Dmitry.


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

Re: Discarding uploaded binary packages

2012-10-25 Thread Abou Al Montacir

On Sat, 2012-10-20 at 20:10 +0200, Joerg Jaspert wrote:
  But my point was: if we're going to be dropping the uploaded binary
 in the first
  place, why do we have to upload it? Source-only uploads would make
 so much more
  sense.
 
 Only theoretical. Practical it would mean we will have many more build
 failures.

Hi,

You cant set a ranking system counting failures. Then queue uploads
according to the rank of the uploader. This way persons get responsible
by constraint, even if I think majority do not need this, but those will
never suffer from this ranking.

Of course you can keep this information internal to the system so that
only few admins should access it. You can also give the possibility for
DDs to ask resetting the ranking or make it so that it looses memory
after x uploads (could be implemented as an IIR filter).

Cheers,


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ben Hutchings

On Thu, Oct 25, 2012 at 01:47:52PM -0400, Patrick Ouellette wrote:
[...]
 All the pings in the world won't help if you are sending them via
 a path that discards them.  I know several large US ISPs that automatically
 reject what they consider SPAM without the customer's knowledge.  If
 the sender of the ping is on a SPAM list for one of them, the ping
 will never get to the maintainer, and *no one* will know.
 (From personal experience I can tell you mail from the Debian list addresses
 does get caught in these SPAM filters and no, the ISPs won't change the
 policy.)
 
Given that Debian lists are 'open' and haven't always had good spam
filtering, it is not too surprising that they are sometimes treated
as spam sources.

In general, anything that needs to reach the maintainer(s) of a
specific package should not be sent to the maintainer address, not to
some general mailing list.  (The maintainer address may itself be a
mailing list, but if the maintainer(s) no longer read mail sent to it
then that's a further reason to orphan/salvage the package!)

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20121025205853.gg13...@decadent.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ben Hutchings

On Thu, Oct 25, 2012 at 09:58:54PM +0100, Ben Hutchings wrote:
 On Thu, Oct 25, 2012 at 01:47:52PM -0400, Patrick Ouellette wrote:
 [...]
  All the pings in the world won't help if you are sending them via
  a path that discards them.  I know several large US ISPs that automatically
  reject what they consider SPAM without the customer's knowledge.  If
  the sender of the ping is on a SPAM list for one of them, the ping
  will never get to the maintainer, and *no one* will know.
  (From personal experience I can tell you mail from the Debian list addresses
  does get caught in these SPAM filters and no, the ISPs won't change the
  policy.)
  
 Given that Debian lists are 'open' and haven't always had good spam
 filtering, it is not too surprising that they are sometimes treated
 as spam sources.
 
 In general, anything that needs to reach the maintainer(s) of a
 specific package should not be sent to the maintainer address, not to

Delete the first 'not'. ;-)

 some general mailing list.  (The maintainer address may itself be a
 mailing list, but if the maintainer(s) no longer read mail sent to it
 then that's a further reason to orphan/salvage the package!)

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20121025210019.gh13...@decadent.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Dmitry Smirnov

I think this proposal is a little bit too complicated and not straightforward 
enough.

Clearly we have two different situations:

  * Maintainer is not active and we want to orphan a particular package.
(just to orphan without adoption)

For this case filing a bug please orphan this package with CC to QA team 
seems reasonable mostly because MIA may be an overkill (what if maintainer 
just don't have enough time with the absence of co-maintainers? Also consider 
the case of prioritising when active maintainer may be working hard on more 
important issues).
Also MIA procedure (if applicable) may take too long -- it is not unusual when 
it takes 6 months or more to complete MIA checks and orphan all packages.

If please orphan this package bug is answered (or closed) by maintainer it 
clarifies the situation immediately.

Obviously anyone can update the bug with objections in which case we need some 
form of consensus to proceed. I would leave the decision to QA team as they 
are handling orphaning anyway.

If bug was unanswered for let's say two months the package is free to orphan 
by QA team. I believe one month won't be enough: maintainer might be without 
connectivity while changing internet providers, attending funeral overseas, 
being on long vacation, on maternity leave, relocating, changing jobs etc. 
Such reasons can easily keep maintainer offline for a month.

This will work if QA team won't hesitate to orphan in obvious cases.



Another (second) situation:

  * Maintainer is not active and somebody intended to take over the package.

I think proposal is addressing this case in order to protect package 
ownership. I believe generally we should trust developers (DDs) and avoid 
unnecessary bureaucracy. If DD is going to snatch the package without waiting, 
asking or following the procedure it would be a case for technical committee 
to investigate.

Practically speaking taking over the package often bypasses orphaning.
Either developers decide between themselves or new maintainer declares (her|
him)self as such.

The question is whenever we want package to be orphaned first, which I believe 
is unnecessary as long as new maintainer publicly announce ITA.

Also I think we should trust DDs to decide how long to wait for maintainer to 
reply. One month seems reasonable but it depends: timing may be important 
before freeze or if package is blocking other packages. Proposal can recommend 
to wait one month, ideally two.

As for DMs or non-members they would have to find sponsor to review their work 
anyway so we don't need a procedure to protect package ownership from 
hijacking by non-DDs.

I like the idea of filing ITA against the package in question. It clearly mark 
the intention to work on the package and notifies the maintainer 
automatically. It doesn't have to be called ITA -- we can call it co-
maintainership intent or whatever.

Consensus 3 to 1 will be only needed if there are any objections but that's 
common sense. In obvious cases a single developer's decision should be just 
enough for adoption.

I believe we're all respect each others work and our intentions are good so we 
need only little clarification how to adopt a package respectfully.
For example I would mention to keep old maintainer in Uploaders unless 
(she/he) agreed to retire from maintenance.

All the best,
Dmitry.


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Jean-Michel Vourgère

On Thursday 25 October 2012 19:09:55 Michael Gilbert wrote:
 (...)
 I would prefer to see even more autonomy for the salvager and less
 bugging of various lists (ITPs on -devel are already distracting
 enough).  With that, I would like to suggest rewriting steps 2-4 as:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.
 3.  After a period of 3 months of contributing as an nmuer or with
 maintainers approval prior to that, salvager is free to add
 himself/herself as a package uploader.
 (...)

I feel that would make it quite difficult for a non-DD to salvage a package.

Remember finding a sponsor can be hard.

When fixing non important bugs, or improving the package quality, like
switching to format 3 source, arranging the rules file, and so on, I fear
it will be very difficult to find a sponsor for these nmus.

Having 3/1 (1/0?) *DD* approving the orphaning will be more easy in these
cases. After it's done, one can work on more radical changes, that are more
likely to get sponsored.

I find it sad to see patches hanging for years in the bug tracker.

Cheers.

Jean-Michel Vourgère, sponsored only DM


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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 6:05 PM, Jean-Michel Vourgère wrote:
 On Thursday 25 October 2012 19:09:55 Michael Gilbert wrote:
 (...)
 I would prefer to see even more autonomy for the salvager and less
 bugging of various lists (ITPs on -devel are already distracting
 enough).  With that, I would like to suggest rewriting steps 2-4 as:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.
 3.  After a period of 3 months of contributing as an nmuer or with
 maintainers approval prior to that, salvager is free to add
 himself/herself as a package uploader.
 (...)

 I feel that would make it quite difficult for a non-DD to salvage a package.

 Remember finding a sponsor can be hard.

I will make myself available as a salvaging sponsor, and we can add a
tag like SV or something like that to sponsorship-requests to help
salvaging sponsors find packages.  That should significantly lower the
barrier.

 When fixing non important bugs, or improving the package quality, like
 switching to format 3 source, arranging the rules file, and so on, I fear
 it will be very difficult to find a sponsor for these nmus.

That is because those changes are not allowable in an nmu, and that
wouldn't change given any proposal so far anyway.  Those choices are
up to the maintainer and uploaders, not an nmuer.

 Having 3/1 (1/0?) *DD* approving the orphaning will be more easy in these
 cases. After it's done, one can work on more radical changes, that are more
 likely to get sponsored.

That also adds more bureaucracy, and I don't think Debian needs any
more of that.

Best wishes,
Mike


--
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/CANTw=mn2gufe4jb5dsxdnoj0xw_+q2zbtt9sxpvk65qkage...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 6:15 PM, Michael Gilbert  wrote:
 When fixing non important bugs, or improving the package quality, like
 switching to format 3 source, arranging the rules file, and so on, I fear
 it will be very difficult to find a sponsor for these nmus.

 That is because those changes are not allowable in an nmu, and that
 wouldn't change given any proposal so far anyway.  Those choices are
 up to the maintainer and uploaders, not an nmuer.

I was a bit unclear here.  Fixing non-important bugs and in fact any
issue in a liberal NMU will be ok.  Changes to packaging style like
source format changes, rearranging rules, etc. will not as is
currently the case (see current NMU rules).

Best wishes,
Mike


-- 
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/CANTw=MOKN0Hzn__9NMh=hp7kikd3apoo1suuo5cesgq9h2c...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Arno Töll

On 25.10.2012 21:09, Michael Gilbert wrote:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.

Please let's not go that road. Mixing-up the concept of a bad maintained
package and the concept of NMUs together does not help. They do not
belong together, and only blur both concepts, so that we only can loose.

You NMU because you aren't the maintainer, that's the Non Maintainer
in Non Maintainer Upload and a fundamental difference. Developer's
reference clearly states for good reasons that the concept of NMU is
house-keeping in someone else's house. It's not your house (yet), so
please respect that. We have too many people already, continuously
ignoring NMU guidelines and are uploading NMUs with cosmetic changes
(e.g. 3.0 conversions) instead. Let's not endorse this.

However, what you are proposing is right that: Make your footprints in
someone else's package first, and find out later if someone complains
loud enough. That's everything but respectful and eventually not going
to help finding a way to head over a package to a new maintainer in a
way which is a not prone to conflicts.


I am not saying you should not NMU packages. People should not be afraid
to NMU - but do it an respectful, minimally invasive way. Do the
cosmetic perfectionist stuff later, when you are the official maintainer.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 6:50 PM, Arno Töll wrote:
 On 25.10.2012 21:09, Michael Gilbert wrote:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.

 Please let's not go that road. Mixing-up the concept of a bad maintained
 package and the concept of NMUs together does not help. They do not
 belong together, and only blur both concepts, so that we only can loose.

The term better probably led to that interpretation.  By better, I
mean improving the situation in an under-maintained package, not that
the packaging was somehow bad.  That wording can be improved to
clarify that confusion.  How about:

 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  an under-maintained package into a more maintained state.

 You NMU because you aren't the maintainer, that's the Non Maintainer
 in Non Maintainer Upload and a fundamental difference. Developer's
 reference clearly states for good reasons that the concept of NMU is
 house-keeping in someone else's house. It's not your house (yet), so
 please respect that. We have too many people already, continuously
 ignoring NMU guidelines and are uploading NMUs with cosmetic changes
 (e.g. 3.0 conversions) instead. Let's not endorse this.

As I've said many times now, the liberal NMU would not be a license
for packaging style changes.  In fact, no NMU is allowed to make those
changes (the fact that people are doing it is apparently a social
issue, and solutions to those are hard).  It is instead more of a
license to go ahead and fix real issues with the package including new
upstreams.

 However, what you are proposing is right that: Make your footprints in
 someone else's package first, and find out later if someone complains
 loud enough. That's everything but respectful and eventually not going
 to help finding a way to head over a package to a new maintainer in a
 way which is a not prone to conflicts.

That is why the 10-day delay and bug report patch is important.  The
salvager prepares their changes and gives the existing maintainer
those 10 days to review and possibly reject them.  If the maintainer
does reject them, hopefully he does so in a constructive manner
indicating how to prepare an appropriate upload to meet his/her
requirements.

If that process somehow breaks down, only then does the Tech committee
need to get involved.  But at least at that point, there is real
activity that they can judge.

Best wishes,
Mike


--
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/CANTw=mp5ve5b3q+kw3r-1crqjq-f6bkrzknjarprhvuobnj...@mail.gmail.com

Bug#691466: ITP: python-django-mezzanine-events -- event pages for the Mezzanine CMS

2012-10-25 Thread Per Andersson

Package: wnpp
Severity: wishlist
Owner: Per Andersson avtob...@gmail.com

* Package name: python-django-mezzanine-events
  Version : 0.1~pre
  Upstream Author : St Barnabas Theological College
* URL : http://github.com/stbarnabas/mezzanine-events
* License : Other, BSD-like
  Programming Lang: Python
  Description : event pages for the Mezzanine CMS

 This package provides two page types for Mezzanine: Event Container and
 Event. The Event Container page type is the 'Events' (note plural) page on
 your website; you'll probably want it to have a list of events. The Event page
 type represents a single event.
 .
 Features:
  * Show your visitors where to go
  * Embed a map of the location in one line of code with the Google Static Maps
template tag
  * Provide a Get Directions link so users can go there in one click
  * Let your visitors add a single event or subscribe to all future events in
Google Calendar, Outlook, iCal and more with Google Calendar and webcal://
URLs and iCalendar files
  * The usual stuff - dates, times, speakers, rsvp


--
Per


-- 
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/20121025231110.2756.90405.report...@pong.oshw.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert mgilb...@debian.org writes:

 As I've said many times now, the liberal NMU would not be a license for
 packaging style changes.  In fact, no NMU is allowed to make those
 changes (the fact that people are doing it is apparently a social issue,
 and solutions to those are hard).  It is instead more of a license to go
 ahead and fix real issues with the package including new upstreams.

I don't think adoption via liberal NMUs will work in the volume that we'd
like because they invert the natural workflow involved in improving a
package.  When I take over an unmaintained or undermaintained package, the
*last* thing I'm going to start with is upgrading it to a new upstream
release.  Usually there are stray patches that have to be analyzed,
usually the workflow is unclear, the tools used are out of date, and the
package structure isn't efficient, all of which will make the process of
updating to a new upstream release tedious, complex, and unnecessarily
difficult and make it even more of a hairball than it usually already is.

The first thing I want to do when adopting is to clean up the package,
modernize the packaging, sort through the patches and figure out which
ones are unnecessary or already merged, and get the package into a
maintainable state.  *Then* I'd update to the latest upstream.

Of course, people's mileage varies, and I have no objection to people
working the way that you describe instead.  But I think it's quite a high
bar to ask of people adopting effectively orphaned packages, so I don't
think it's the right approach to use as our default process.

-- 
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/871ugmw352@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 7:19 PM, Russ Allbery wrote:
 As I've said many times now, the liberal NMU would not be a license for
 packaging style changes.  In fact, no NMU is allowed to make those
 changes (the fact that people are doing it is apparently a social issue,
 and solutions to those are hard).  It is instead more of a license to go
 ahead and fix real issues with the package including new upstreams.

 I don't think adoption via liberal NMUs will work in the volume that we'd
 like because they invert the natural workflow involved in improving a
 package.

I think this is where language is important.  In my opinion, the term
adoption will continue to mean taking on full responsibility for a
package as its new maintainer.  The term salvage, in my opinion, we
can define as a process for becoming a co-maintainer on a package with
a long-term possibility of becoming its maintainer.

For adoption, the existing adoption processes will continue for those
who prefer that approach.  For salvaging, the new procedures will be
available.

 The first thing I want to do when adopting is to clean up the package,
 modernize the packaging, sort through the patches and figure out which
 ones are unnecessary or already merged, and get the package into a
 maintainable state.  *Then* I'd update to the latest upstream.

Again, I think it comes down to language.  If we view salvaging as a
process that is initially meant to help the existing maintainer, then
it makes sense to continue to work with the package as he/she
intended.  When the 3 month clock expires, and the salvager becomes an
uploader, then any change becomes allowable.  It may be that some
salvagers will start out with some more minor work for the 3 months
before becoming an uploader and jumping to a new upstream and at the
same time they change packaging style, but then again some may want
bump upstreams right away, and this process makes it possible for the
person actually doing the work to decide their own fate.  I think
autonomy is incredibly important.

That's what we did with wine, and it was entirely possible although
not as pleasant (for us salvagers) than if we could have redesigned
the packaging style.  We wanted to work as well as we could with the
existing maintainer to avoid conflict arising from changes that would
modify the way things work that he was familiar with.

Best wishes,
Mike


-- 
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/CANTw=MMUgQf0JGfTCRioPErQqAvcbgSbgbSCAT8aVOw=+jf...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert mgilb...@debian.org writes:

 Again, I think it comes down to language.  If we view salvaging as a
 process that is initially meant to help the existing maintainer, then it
 makes sense to continue to work with the package as he/she intended.
 When the 3 month clock expires, and the salvager becomes an uploader,
 then any change becomes allowable.  It may be that some salvagers will
 start out with some more minor work for the 3 months before becoming an
 uploader and jumping to a new upstream and at the same time they change
 packaging style, but then again some may want bump upstreams right away,
 and this process makes it possible for the person actually doing the
 work to decide their own fate.  I think autonomy is incredibly
 important.

I certainly have no objection to people doing this, but I'm not sure
that's really what we're discussing here.  I think the thread is more
about the ongoing issue that we seem to have in Debian where the existing
procedure for orphaning packages is perceived as too heavy-weight and we
believe that there are packages that aren't being cared for, aren't
orphaned, and that someone else would work on if the status were clearer.

(I'm not entirely convinced that this is as common as people think; I
think a lot of the largely unmaintained packages are in that state because
no one else is really motivated to do anything with them either.  But it's
certainly the case that the existing process for orphaning feels murky,
ill-defined, and open-ended, which is going to tend to scare away people
who want to be helpful but who don't want to subject someone else to what
can be perceived as a sanction and who don't want to create conflict.)

The process you describe sounds more appropriate for a situation like the
WINE packages were in, where the existing maintainer was overwhelmed but
still wanted to stay deeply involved in the packaging.

-- 
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/87objqun33@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert michael.s.gilb...@gmail.com writes:
 On Thu, Oct 25, 2012 at 7:52 PM, Russ Allbery wrote:

 I certainly have no objection to people doing this, but I'm not sure
 that's really what we're discussing here.  I think the thread is more
 about the ongoing issue that we seem to have in Debian where the
 existing procedure for orphaning packages is perceived as too
 heavy-weight and we believe that there are packages that aren't being
 cared for, aren't orphaned, and that someone else would work on if the
 status were clearer.

 It is a proposed solution to the above issue, so it is intimately
 apropos to the discussion at hand in my opinion.

Okay, well, I guess I return to my previous statement, then.  I don't
think your proposed solution will work for the more common cases.  It's
certainly fine for people to try it, though, and I don't think it requires
any changes to any procedures for people to do so.

-- 
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/87d306ului@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote:
Michael Gilbert writes:
On Thu, Oct 25, 2012 at 7:52 PM, Russ Allbery wrote:

I certainly have no objection to people doing this, but I'm not sure
that's really what we're discussing here. I think the thread is more
about the ongoing issue that we seem to have in Debian where the
existing procedure for orphaning packages is perceived as too
heavy-weight and we believe that there are packages that aren't being
cared for, aren't orphaned, and that someone else would work on if the
status were clearer.

It is a proposed solution to the above issue, so it is intimately
apropos to the discussion at hand in my opinion.

Okay, well, I guess I return to my previous statement, then. I don't
think your proposed solution will work for the more common cases.

I respect your opinion, so I'm just curious which part do you believe
won't work in common cases? It's just applying existing NMU rules
with a little more liberalism to increase activity in under-maintained
packages, so I personally can't see where it would break down.

It's
certainly fine for people to try it, though, and I don't think it requires
any changes to any procedures for people to do so.

A procedure change is important because it empowers salvagers; giving
them a clear set of steps to follow while also giving them the
confidence that their actions are the approved/correct ones; just like
the existing NMU rules. It also makes it clear who is in the right if
the issue does blow up to the Tech Committee.

Best wishes,
Mike

--
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/CANTw=mmblomn8q9zs9p8foybyhawx35wp0mvydmqu2o67ze...@mail.gmail.com

Work-needing packages report for Oct 26, 2012

2012-10-25 Thread wnpp

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

Total number of orphaned packages: 474 (new: 3)
Total number of packages offered up for adoption: 136 (new: 1)
Total number of packages requested help for: 64 (new: 0)

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



The following packages have been orphaned:

   coherence (#691229), orphaned 2 days ago
 Description: Python UPnP framework
 Installations reported by Popcon: 29520

   gnome-alsamixer (#691265), orphaned 2 days ago
 Description: ALSA sound mixer for GNOME
 Installations reported by Popcon: 3095

   openclipart2 (#691126), orphaned 4 days ago
 Description: Open Clip Art Library
 Installations reported by Popcon: 258

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



The following packages have been given up for adoption:

   ksh (#691199), offered 3 days ago
 Description: Real, ATT version of the Korn shell
 Installations reported by Popcon: 2641

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



For the following packages help is requested:

   apt-xapian-index (#567955), requested 997 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 58772

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

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

   balsa (#642906), requested 396 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 266

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

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

   chromium-browser (#583826), requested 879 days ago
 Description: Chromium browser
 Installations reported by Popcon: 10758

   debtags (#567954), requested 997 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2507

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

   elvis (#432298), requested 1935 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Installations reported by Popcon: 385

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

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

   freeipmi (#628062), requested 518 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 1937

   gnat-4.4 (#539633), requested 1654 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 1628

   gnat-gps (#496905), requested 1519 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 423

   gnokii (#677750), requested 131 days ago
 Description: Datasuite for mobile phone management
 Installations reported by Popcon: 2366

   gnupg (#660685), requested 248 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 127238

   golang (#668870), requested 193 days ago
 Description: Go programming language compiler - metapackage
 Installations reported by Popcon: 350

   gpa (#663405), requested 229 days ago
 Description: GNU Privacy Assistant (GPA)
 Installations reported by Popcon: 510

   gradle (#683666), requested 84 days ago
 Description: Groovy based build system
 Installations reported by Popcon: 26

   grub2 (#248397), requested 3090 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 118360

   hfsprogs (#557892), requested 1065 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1247

   horde4 (#686007), requested 59 days ago
 Description: web-based groupware and other applications

   hotkey-setup (#483107), requested 1612 days ago
 Description: auto-configures laptop hotkeys

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert michael.s.gilb...@gmail.com writes:
 On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote:

 Okay, well, I guess I return to my previous statement, then.  I don't
 think your proposed solution will work for the more common cases.

 I respect your opinion, so I'm just curious which part do you believe
 won't work in common cases?  It's just applying existing NMU rules with
 a little more liberalism to increase activity in under-maintained
 packages, so I personally can't see where it would break down.

Well, that's what I was trying to get at: I think your method puts too
many barriers in the way of someone who wants to take over an effectively
abandoned package.  It also requires *more* skill than adopting the
package would otherwise, since you have to be good enough at Debian
packaging to make minimal chnages within some arbitrary packaging scheme.
In other words, it requires as much or more skill than doing NMUs, whereas
adopting a traditionally orphaned package is much easier.

-- 
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/87bofquj99@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 9:14 PM, Russ Allbery wrote:
 I respect your opinion, so I'm just curious which part do you believe
 won't work in common cases?  It's just applying existing NMU rules with
 a little more liberalism to increase activity in under-maintained
 packages, so I personally can't see where it would break down.

 Well, that's what I was trying to get at: I think your method puts too
 many barriers in the way of someone who wants to take over an effectively
 abandoned package.  It also requires *more* skill than adopting the
 package would otherwise, since you have to be good enough at Debian
 packaging to make minimal chnages within some arbitrary packaging scheme.
 In other words, it requires as much or more skill than doing NMUs, whereas
 adopting a traditionally orphaned package is much easier.

Don't we expect the same adaptability of anyone trying to become a
co-maintainer of any other package?  Once someone has jumped all the
hurdles to become a DD, at that point, aren't they expected to be of
sufficient caliber and skill to be able to learn quickly and apply
themselves to hard(er) problems?

At one point, there were arguments on -devel against using git for
packages because it increased the learning curve and thus may reduce
potential contributors.  This argument strikes me as quite similar.

I think we have to be able to expect ourselves to be able to adapt and
learn.  If we can't do that, then we really weren't qualified, and we
should get out of the way of those who can.

Best wishes,
Mike


-- 
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/CANTw=MMkenFta5+bH5o=DkU_Kc554jOb-G=+1a2bbftb9uo...@mail.gmail.com

Re: Discarding uploaded binary packages

2012-10-25 Thread Peter Miller

It may be possible to address both concerns in a different way.

1. Implement PPAs.  The code is open source, get it working first, and
enhance it later.

2. DDs and DMs upload source-only to their individual PPA(s).  The PPA
build farm builds the package on all the architectures Debian cares
about.

3. When a DD or DM wants to place a package to testing or experimental,
it is done as a *copy* from a PPA (no upload required).  If the package
in the PPA didn't build, no copy happens.

This means folks who pay $$$ for uploads don't have to upload the binary
package that is discarded.  But it also means the package is known to
build (on all architectures) before being copied into testing or
experimental.


-- 
Regards
Peter Miller pmil...@opensource.org.au
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://pgp.mit.edu/ or any PGP keyserver for public key.

It's hard enough to find an error in your code when you're
looking for it; it's even harder when you've assumed your code
is error free. -- Steve McConnell, Code Complete


--
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/1351210388.3139.41.ca...@hawk.miller.emu.id.au

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert mgilb...@debian.org writes:

 Don't we expect the same adaptability of anyone trying to become a
 co-maintainer of any other package?

No, because in the typical comaintenance situation, the other maintainers
will teach the newcomer how to package according to the team standards,
rather than having them have to reverse-engineer the intention behind the
packaging setup.  With an effectively orphaned package, that's unlikely;
usually the current maintainer doesn't have the time to do anything as
time-intensive as mentoring or training.  It's way easier, in general, to
maintain the package yourself than to teach someone else how to do it, so
if they don't have time to maintain the package, they're almost certainly
not going to be able to teach someone else.

 Once someone has jumped all the hurdles to become a DD, at that point,
 aren't they expected to be of sufficient caliber and skill to be able to
 learn quickly and apply themselves to hard(er) problems?

That's not, for me, the point.

One of the problems people are concerned with when looking at the overall
quality of the Debian archive, and on our releasability, is that we tend
to keep adding new packages without taking good care of the ones already
in the archive.  I think this is one of the main motivations for the
persistant discussions of finding a better way to deal with effectively
orphaned packages.  Frequently, people will ask or hope for new
contributors to start by fixing a package already in the archive rather
than adding yet another new package to the archive, or at least do some
combination of both.

I think orphaned packages are one of our best opportunities to attract new
developers, rather than serving as an additional obligation for existing
developers.  If the package is fully orphaned, then the new maintainer
doesn't have to try to fit in with an existing packaging style without
help and explanation, and can experiment (which is how people learn).  A
lot of orphaned or poorly-maintained packages aren't horribly important,
so the new maintainer doesn't have to worry about breaking something
vital, but they still have existing work to start from and don't have the
intimidating problem of starting from scratch.  And often they have a
personal incentive for fixing that package; perhaps it's a relatively
obscure piece of software they personally use, and they were drawn to
contribute to Debian because they wanted to make it better.

Adopting orphaned packages was one of the ways I personally got started in
Debian.

But to take full advantage of that opportunity, we need to do two things.
First, we need to officially orphan packages that are effectively orphaned
but don't officially have that status.  New contributors are unlikely to
want to do that, since they don't want to insult the existing developer
and they don't have any social capital and will be worried about starting
a confrontation.  I think that's where a new orphaning process could fit
in; existing Debian developers who have the social capital to be able to
tell another developer no, really, you're not maintaining your package,
let someone else take a crack at it can get the package into a state
where a newcomer feels safe in taking it over.

And, secondly, the package needs to be in a status where the new developer
can experiment and learn.  While one *can* learn a lot by fitting within
the framework that's already in place, I think that's a learning path best
done as part of an active maintenance team so that one has mentors and
assistance.  Orphaned packages can provide a great source of material for
one's personal experimentation as one learns how to package because one
can make as large or small of changes to the packaging as one wants to
attempt and then see how well the results work without breaking any team
rules or getting in anyone else's way, but also without having to
introduce yet another new package into the archive.

-- 
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/87pq46neie@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Steve Langasek

On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
 I think this is where language is important.  In my opinion, the term
 adoption will continue to mean taking on full responsibility for a
 package as its new maintainer.  The term salvage, in my opinion, we
 can define as a process for becoming a co-maintainer on a package with
 a long-term possibility of becoming its maintainer.

This is an unhelpful redefinition of the term.  The term salvage was
introduced to *mean* orphaning/adopting a package when the maintainer is no
longer fulfilling their responsibilities.

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

Bug#691473: ITP: trac-translatedpages -- Show translated versions of wiki page in the Trac web application

2012-10-25 Thread Daniel Kahn Gillmor

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor d...@fifthhorseman.net

* Package name: trac-translatedpages
  Version : 1.0~r11919
  Upstream Author : Mikhail Gusarov dotted...@dottedmag.net
* URL : http://trac-hacks.org/wiki/TranslatedPagesMacro
* License : BSD
  Programming Lang: Python
  Description : Show translated versions of wiki page in the Trac web 
application

The TranslatedPagesMacro provides a simple way to deal with
translating wiki pages on a wiki of a Trac installation.  It presents
links to corresponding versions of the current page in different
languages, and indicates when the revision of a translation page gets
out of sync with the latest version of the source page.


-- 
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/20121026050607.20172.43412.report...@pip.fifthhorseman.net

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 01:41:25PM +0200, Gergely Nagy wrote:
 Steve Langasek vor...@debian.org writes:
  On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
  Someone wrote:
   I disagree on this point.  If you can't get anyone to ack that you 
   should go
   ahead with the orphaning, then the system is not working as designed and
   consensus has not been achieved.  It's then incumbent on the person 
   looking
   to orphan the package to rattle the cage and get developers to pay
   attention.
 
  On the other hand, it is already hard to find people willing to review
  other peoples work. Mandating acks means trusting that there will be
  enough manpower to review something potentially unknown. I can't see
  that happening reliably. It also makes the process a whole lot more
  complicated than it needs to be,
 
  No, it makes the process based on *consensus*, which is a minimum
  requirement.
 
 It also means that the salvager has to do more work.

I expect the cc to debian-qa to draw sufficient DD's attention.  And the ACKs
are about agreeing on marking a package as orphaned.  That's the easy part.

The salvaging part goes via the existing ITA procedure.  That's the hard part.

Regards,

Bart Martens


-- 
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/20121026050907.gb10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 01:50:10PM +0200, Gergely Nagy wrote:
 Bart Martens ba...@debian.org writes:
  On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
  Steve Langasek vor...@debian.org writes:
  
   On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote:
4. When/if consensus has been reached, the package can be orphaned by
   retitling and reassigning the ITO bug accordingly.
  
   I fear a bit the situation nobody care enough to comment, being
   interpreted as lack of consensus. But I do think in that case we should
   _eventually_ allow the orphaning to happen (after all 1/0  3/1 ACK/NACK
   /joke).
   Any suggestion on how to word that properly, without adding yet another
   timeout rule carved in stone?
  
   I disagree on this point.  If you can't get anyone to ack that you 
   should go
   ahead with the orphaning, then the system is not working as designed and
   consensus has not been achieved.  It's then incumbent on the person 
   looking
   to orphan the package to rattle the cage and get developers to pay
   attention.
  
  On the other hand, it is already hard to find people willing to review
  other peoples work. Mandating acks means trusting that there will be
  enough manpower to review something potentially unknown. I can't see
  that happening reliably.
 
  I think that sufficient DDs will review the ITOs.  Note that most work is
  already done by the ITO submitter.  Sponsoring a package at mentors (review
  other peoples work) is, in my opinion, much more work than reading an ITO 
  and
  sending an ACK.
 
 On the other hand, ACKing an ITO is much more responsibility, becasue
 it's not only about a package, but about taking over a package too.

No, it is not.  See the two activities explained here:
http://lists.debian.org/debian-devel/2012/10/msg00261.html

 An
 ITO will also contain quite a lot of info about previous attempts at
 updating the package - that's not simple to review either. It is less
 technical too, which can be off-putting to some.

No, an ITO should just enumerate the reasons why the package should be marked
as orphaned.

 (Mind you, I'm not against the ACK/NACK system, I'm only arguing for
 being able to proceed without N acks after a reasonable amount of time.)

OK thanks for clarifying that.  Well, also for clarity, I expect every ITO to
get sufficient ACKs or NACKs (thanks to the cc to debian-qa).

 
  As said elsewhere in the thread, the process needs to be easy and
  efficient. Hunting ACKs is neither easy, nor efficient.
 
  The proposed text is quite easy, in my opinion.
 
 Indeed, it is. Partly because as far as I understand it, it only
 recommends a 3/1 majority, and does not demand it. That's perfectly
 fine.

I guess it's a recommendation because it would go in developers-reference.
That doesn't mean that it would be OK to randomly orphan packages ignoring the
recommended procedure in developers-reference.

Regards,

Bart Martens


-- 
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/20121026052546.gc10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 09:51:12PM -0700, Steve Langasek wrote:
 On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
  I think this is where language is important.  In my opinion, the term
  adoption will continue to mean taking on full responsibility for a
  package as its new maintainer.  The term salvage, in my opinion, we
  can define as a process for becoming a co-maintainer on a package with
  a long-term possibility of becoming its maintainer.
 
 This is an unhelpful redefinition of the term.  The term salvage was
 introduced to *mean* orphaning/adopting a package when the maintainer is no
 longer fulfilling their responsibilities.

I agree with Steve on this.  Let's not redefine the term now, since it would
introduce more confusion, and it would not bring us closer to a consensus on
the proposal.

The proposal is about an intent to orphan, which is in obvious cases easy to
find a consensus on.  The real salvaging (the hard work) happens via the
existing ITA procedure.

Regards,

Bart Martens


-- 
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/20121026053726.gd10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Steve Langasek

On Fri, Oct 26, 2012 at 05:09:07AM +, Bart Martens wrote:
 On Thu, Oct 25, 2012 at 01:41:25PM +0200, Gergely Nagy wrote:
  Steve Langasek vor...@debian.org writes:
   On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
   Someone wrote:
I disagree on this point.  If you can't get anyone to ack that you 
should go
ahead with the orphaning, then the system is not working as designed 
and
consensus has not been achieved.  It's then incumbent on the person 
looking
to orphan the package to rattle the cage and get developers to pay
attention.
  
   On the other hand, it is already hard to find people willing to review
   other peoples work. Mandating acks means trusting that there will be
   enough manpower to review something potentially unknown. I can't see
   that happening reliably. It also makes the process a whole lot more
   complicated than it needs to be,

   No, it makes the process based on *consensus*, which is a minimum
   requirement.

  It also means that the salvager has to do more work.

 I expect the cc to debian-qa to draw sufficient DD's attention.  And the
 ACKs are about agreeing on marking a package as orphaned.  That's the easy
 part.

 The salvaging part goes via the existing ITA procedure.  That's the hard
 part.

Exactly.  Anyone who can't be bothered to find N other DDs to agree with him
that a package should be orphaned (for some value of N = 3 - as far as I'm
concerned, 1 or 2 acks w/ 0 nacks is sufficient) shouldn't be considering
themselves a candidate for maintaining the package anyway.

-- 
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: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - delay for maintainer to react

On Fri, Oct 26, 2012 at 08:06:57AM +1100, Dmitry Smirnov wrote:
 If bug was unanswered for let's say two months the package is free to orphan 

Some prefer no delay, some prefer one month, some prefer two months.  I
originally wanted one month, but I got convinced by others to drop the delay.
Now my opinion is that I trust the DDs reviewing the ITO to judge the package's
situation before sending an ACK or NACK.  One possible judgement on an ITO can
be NACK until 2 months have passed or the maintainer has agreed to orphan the
package.  Another possible judgement on an ITO can be ACK because this
package has clearly not been maintained for years, so please proceed without
further delay.

 Another (second) situation:
 
   * Maintainer is not active and somebody intended to take over the package.

This situation can be broken down in the two activities as explained here:
http://lists.debian.org/debian-devel/2012/10/msg00261.html

Regards,

Bart Martens


-- 
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/20121026055602.ge10...@master.debian.org

Accepted icinga 1.8.1-1 (source amd64 all)

2012-10-25 Thread Alexander Wirt

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 07:04:55 +0200
Source: icinga
Binary: icinga-common icinga-cgi icinga-idoutils icinga icinga-core icinga-doc 
icinga-dbg
Architecture: source amd64 all
Version: 1.8.1-1
Distribution: experimental
Urgency: low
Maintainer: Debian Nagios Maintainer Group 
pkg-nagios-de...@lists.alioth.debian.org
Changed-By: Alexander Wirt formo...@debian.org
Description: 
 icinga - host and network monitoring system - metapackage
 icinga-cgi - host and network monitoring system - CGI scripts
 icinga-common - host and network monitoring system - support files
 icinga-core - host and network monitoring system - core files
 icinga-dbg - host and network monitoring system - debug files
 icinga-doc - host and network monitoring system - documentation
 icinga-idoutils - host and network monitoring system - icinga-dataobjects 
support
Changes: 
 icinga (1.8.1-1) experimental; urgency=low
 .
   * [5947e03] Remove useless echo in do_stop of icingas initscript
   * [fb9c4cb] Imported Upstream version 1.8.1
Checksums-Sha1: 
 fbb151a123f6d07a89a77896ca2953e9b869338c 1671 icinga_1.8.1-1.dsc
 b11b0e27e0bd2b3b71b4d36a9e979fda138171d5 7543668 icinga_1.8.1.orig.tar.gz
 f0558526038435615da13001849837fe805088d0 46894 icinga_1.8.1-1.diff.gz
 9f2d02151dfcf9e5d9baaf3b5498f59c9acfc25d 1875244 icinga-cgi_1.8.1-1_amd64.deb
 6742ee48ffb9142646ee5bd2953509e82e3a568e 273524 
icinga-idoutils_1.8.1-1_amd64.deb
 67775876397763c7c043c112adb456f9d78af7f5 1304 icinga_1.8.1-1_amd64.deb
 7d9728b524c66c100550f5b0651fe8ed01f8a62f 297298 icinga-core_1.8.1-1_amd64.deb
 e26a7a95d10dcbfa4f5fbfba3a7b46a95564b051 5172448 icinga-dbg_1.8.1-1_amd64.deb
 59120a158e5ab43d58700d4e333126237dc7cdae 115894 icinga-common_1.8.1-1_all.deb
 3e2b4fad019531a586f3f23860cbae44eba91664 6114016 icinga-doc_1.8.1-1_all.deb
Checksums-Sha256: 
 e81d62f11f3dde5a254efbb4928d00dd0a0e5cf820b2762a5c62e93957018bbc 1671 
icinga_1.8.1-1.dsc
 3d02d80bdefc2518ab8517be6930a518b77747e0243fa594731fb1f95dbab916 7543668 
icinga_1.8.1.orig.tar.gz
 cea05b1aa9175ea43b841b4150dd5c2e96c157a9b04ccc9786fa8e46ae9693c2 46894 
icinga_1.8.1-1.diff.gz
 4a0d286be2193525a0c46a73bbcac672b3c1bd2dee00ebf76a0d5209829f4a1b 1875244 
icinga-cgi_1.8.1-1_amd64.deb
 eace171c54a5948c2ede963080bbba1827ebd5e6028bdc68044f2a7ac0053711 273524 
icinga-idoutils_1.8.1-1_amd64.deb
 5a2ef36a8f29a451ea7b7c816f3fc0a5da897ac4a197ddf75af421fca3b42b7d 1304 
icinga_1.8.1-1_amd64.deb
 966413113cc024cd76aa85f1ebc6469e6e76945f1ef146e28437f812012223ae 297298 
icinga-core_1.8.1-1_amd64.deb
 a8355ceca1d6e197abeaa55df7b86fdab7897e6618089fc638a21e8681765c66 5172448 
icinga-dbg_1.8.1-1_amd64.deb
 794221d0ad42bf66bc411fe9a2877f2f2d1e5f57183e27d67c861443f9a1056a 115894 
icinga-common_1.8.1-1_all.deb
 378d79bcf2378021de20f841769dc5c91e5364f58555a53d7fc22b9e69b158df 6114016 
icinga-doc_1.8.1-1_all.deb
Files: 
 97a0ccb51f90b6544a3e740badf3e032 1671 net optional icinga_1.8.1-1.dsc
 8180933f1388fd61e816c409e8fec746 7543668 net optional icinga_1.8.1.orig.tar.gz
 4d2ca0ff165e0d2ec42d9dd2cfb24091 46894 net optional icinga_1.8.1-1.diff.gz
 955a6ff23872a6342a1f84466d15cd51 1875244 net optional 
icinga-cgi_1.8.1-1_amd64.deb
 f5e36a64b7a3eae212bb81140a0e1727 273524 net optional 
icinga-idoutils_1.8.1-1_amd64.deb
 964c2c58aa33ce8204f95b0e9b1999d0 1304 net optional icinga_1.8.1-1_amd64.deb
 ff9ec904e6baa6d37fd8830975862ab3 297298 net optional 
icinga-core_1.8.1-1_amd64.deb
 eb6b6717428625710212f6dbb1f9248d 5172448 debug extra 
icinga-dbg_1.8.1-1_amd64.deb
 ee7b1a33831be45d4c5803f26ee2159e 115894 net optional 
icinga-common_1.8.1-1_all.deb
 6f0a814009a95599bc266e3848fefd52 6114016 doc optional 
icinga-doc_1.8.1-1_all.deb

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

iEYEARECAAYFAlCIy6EACgkQ01u8mbx9AgreLgCaAoqGDHEOcFWR36NMDtKoyCnP
TNgAoOK0MnhbQZad0QPP/ftroaXGZJcP
=TWcJ
-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/e1trgwa-0001a2...@franck.debian.org

Accepted gcc-4.6-doc 4.6.3-2 (source all)

2012-10-25 Thread Guo Yixuan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 25 Oct 2012 14:03:28 +0800
Source: gcc-4.6-doc
Binary: gcc-4.6-doc cpp-4.6-doc gfortran-4.6-doc gnat-4.6-doc gcj-4.6-doc 
gccgo-4.6-doc
Architecture: source all
Version: 4.6.3-2
Distribution: unstable
Urgency: low
Maintainer: Guo Yixuan culu@gmail.com
Changed-By: Guo Yixuan culu@gmail.com
Description: 
 cpp-4.6-doc - documentation for the GNU C preprocessor (cpp)
 gcc-4.6-doc - documentation for the GNU compilers (gcc, gobjc, g++)
 gccgo-4.6-doc - documentation for the GNU Go compiler (gccgo)
 gcj-4.6-doc - documentation for the GNU Java tools (gcj, gij)
 gfortran-4.6-doc - documentation for the GNU Fortran Compiler (gfortran)
 gnat-4.6-doc - documentation for the GNU Ada 95 Compiler (gnat)
Changes: 
 gcc-4.6-doc (4.6.3-2) unstable; urgency=low
 .
   * New maintainer.
   * Thanks to Samuel Bronson for his work on this package. I kept him in
 uploaders as credit.
   * Removed DMUA flag, as it's being deprecated. Thanks to Steffen for
 adding that.
   * Improved README.source, and added a helper script, check_gcc_patches.
   * Synced patches with gcc-4.6, 4.6.3-12, no changes needed.
   * Added a patch, alpha-ieee-doc-clarification.diff, to state that
 changes in from-debian-gcc-alpha-ieee-doc.diff are specific to the alpha
 architecture.
   * Updated copyright.
Checksums-Sha1: 
 0d3a84469588e72654d4b114369f634a2ba2634d 2325 gcc-4.6-doc_4.6.3-2.dsc
 a1adb8b19fcf85c09208ac119478c1a2230f8047 118878 
gcc-4.6-doc_4.6.3-2.debian.tar.gz
 7c19f1282effa4f4d730d371e83e42188b8fccce 6943270 gcc-4.6-doc_4.6.3-2_all.deb
 d61069232565b1785885bed5c4822375c8a42853 887704 cpp-4.6-doc_4.6.3-2_all.deb
 454dd05b8cd590eb7dc535bb55c73f176ff2f242 1304418 
gfortran-4.6-doc_4.6.3-2_all.deb
 9c5692c57180ac94c95611f226d7fcb93ef83ed6 3627104 gnat-4.6-doc_4.6.3-2_all.deb
 630bb583f507d1ef34666c72334dbfaf05337ad2 480326 gcj-4.6-doc_4.6.3-2_all.deb
 5d0c3ee707170f680dae2b72f5b153abdd1b8fd7 264820 gccgo-4.6-doc_4.6.3-2_all.deb
Checksums-Sha256: 
 39807b3a9ed4b4b9d89126f3c631388a4a24998cac1a70e0f3b1a9c688e752d8 2325 
gcc-4.6-doc_4.6.3-2.dsc
 e3de106ce64988c2a335790371029d0096587bb719d3e3ebfb84006e731a45f2 118878 
gcc-4.6-doc_4.6.3-2.debian.tar.gz
 08d044c30f03351cc6e4c50da6036ee7779d1fed6de2e96ea64d67fc60d60576 6943270 
gcc-4.6-doc_4.6.3-2_all.deb
 61974552fe0f5054b11f46ed826022ad94952047365c6a6105adaf9d6b56c942 887704 
cpp-4.6-doc_4.6.3-2_all.deb
 41ceb4d4ddb80516296a2d9466e3bb23965edaa70279878e9c4255f7621e0eca 1304418 
gfortran-4.6-doc_4.6.3-2_all.deb
 8fc206a2bdc788fa501bc15b796c61218b5f1d9ac7900d25aa498e06920671de 3627104 
gnat-4.6-doc_4.6.3-2_all.deb
 03dba01d98cb937eefced0d3b0d09a491c16b98e3c49587747045ba5e6ed758d 480326 
gcj-4.6-doc_4.6.3-2_all.deb
 a27488b6a1d82e1f99d769c659775623d5ef991cb193c1502e1276da8a7a2ec5 264820 
gccgo-4.6-doc_4.6.3-2_all.deb
Files: 
 c31caab8ac93ee318e1d169b43a266ee 2325 non-free/doc optional 
gcc-4.6-doc_4.6.3-2.dsc
 8bb445b36b234f9d4049b8a8e37964f4 118878 non-free/doc optional 
gcc-4.6-doc_4.6.3-2.debian.tar.gz
 4b09eedab7d29ec2a811dfb83ee438f4 6943270 non-free/doc optional 
gcc-4.6-doc_4.6.3-2_all.deb
 bce38da69cf6cd0bd4ea4d05d3e9fc49 887704 non-free/doc optional 
cpp-4.6-doc_4.6.3-2_all.deb
 51fb30a46b6602a8b29ee692eba259f3 1304418 non-free/doc optional 
gfortran-4.6-doc_4.6.3-2_all.deb
 b851b89034146867bdfd2f534c489f0c 3627104 non-free/doc optional 
gnat-4.6-doc_4.6.3-2_all.deb
 10dbe78b9022c2911afb61b76f1da8a9 480326 non-free/doc optional 
gcj-4.6-doc_4.6.3-2_all.deb
 0861518b43f4e3c6c4652de870200148 264820 non-free/doc optional 
gccgo-4.6-doc_4.6.3-2_all.deb

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

iQIcBAEBCgAGBQJQiNoVAAoJEN1xpgAgL7gzppUQAKxOjhzMF/OvWQLpqorwLsiZ
5p3/121ntg7Tw2WJnuOM+jMr1Mcm6FFgRh+GV/0eY/2Kw/DdQ5YX9CGMATK6fJhT
HoGuU+Ft3H8YC7lYvrLZaZD0AuU+xfW5QA15WCbmGjmnfx9TGFfLK7j6+V/QuqtE
4Rl3/9O39TltXTh1OmTQG/yu9zOmY889twW3wKKSR1Dg3+Ey5iF1VPK78e1WJxKP
bXAuzSPyKrx0ZoioW/r6Erh8YQQ+h3p8H5hlEm628cGzQi8qvLuH5nSI7P4RYDWj
xaS383ZbGZj3Zp6JcZzlvJvMzl1Dn+hUlMaOhAHIyhUxjQWwMVfLkTL1fKVuWfhj
BXGnXxcG9gaxfQNdqdJn2L0lxKgiAchBedVrRUn7Out/3JtD7PLw3tjp5yIjLoDd
HBiu754j6QHp2L1avNxvoDbBcNXBt8odQRMIS7b3LSnNiffC42+U4LaBwmIqE0Zm
qpSPhsrTqGd3UXbPyAh7UeOjD2jnm2pQb+eNARUktON9d+KiwRulEE6RQFYLZhtc
q8FT/WS9U09YEUoogDSgqjPPWIOTHg/wzMG3rYIYowYTyti9dxnXpRXETjN3spou
pR9XzLhJXtjOPvsyrRMqhoMhLLsdN/DOdwsCzYd5kXNi8YKi82aDsrUiPR8fQ8gQ
XMKZ+/QGALIR6ASoBku7
=Qam8
-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/e1trh07-0007ev...@franck.debian.org

Accepted cups 1.5.3-2.4 (source all amd64)

2012-10-25 Thread Didier Raboud

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 08:56:29 +0200
Source: cups
Binary: libcups2 libcupsimage2 libcupscgi1 libcupsdriver1 libcupsmime1 
libcupsppdc1 cups cups-client libcups2-dev libcupsimage2-dev libcupscgi1-dev 
libcupsdriver1-dev libcupsmime1-dev libcupsppdc1-dev cups-bsd cups-common 
cups-ppdc cups-dbg cupsddk
Architecture: source all amd64
Version: 1.5.3-2.4
Distribution: unstable
Urgency: low
Maintainer: Debian CUPS Maintainers pkg-cups-de...@lists.alioth.debian.org
Changed-By: Didier Raboud o...@debian.org
Description: 
 cups   - Common UNIX Printing System(tm) - server
 cups-bsd   - Common UNIX Printing System(tm) - BSD commands
 cups-client - Common UNIX Printing System(tm) - client programs (SysV)
 cups-common - Common UNIX Printing System(tm) - common files
 cups-dbg   - Common UNIX Printing System(tm) - debugging symbols
 cups-ppdc  - Common UNIX Printing System(tm) - PPD manipulation utilities
 cupsddk- Common UNIX Printing System (transitional package)
 libcups2   - Common UNIX Printing System(tm) - Core library
 libcups2-dev - Common UNIX Printing System(tm) - Development files CUPS library
 libcupscgi1 - Common UNIX Printing System(tm) - CGI library
 libcupscgi1-dev - Common UNIX Printing System(tm) - Development files for CGI 
libra
 libcupsdriver1 - Common UNIX Printing System(tm) - Driver library
 libcupsdriver1-dev - Common UNIX Printing System(tm) - Development files 
driver librar
 libcupsimage2 - Common UNIX Printing System(tm) - Raster image library
 libcupsimage2-dev - Common UNIX Printing System(tm) - Development files CUPS 
image li
 libcupsmime1 - Common UNIX Printing System(tm) - MIME library
 libcupsmime1-dev - Common UNIX Printing System(tm) - Development files MIME 
library
 libcupsppdc1 - Common UNIX Printing System(tm) - PPD manipulation library
 libcupsppdc1-dev - Common UNIX Printing System(tm) - Development files PPD 
library
Closes: 508941 668662 670042 670224 677180 690982
Changes: 
 cups (1.5.3-2.4) unstable; urgency=low
 .
   * Non-maintainer upload on behalf of the Printing Team.
 .
   [ Till Kamppeter ]
   * Correctly install language-private.h as /usr/include/cups/i18n.h,
 .install file entries cannot rename files (LP: #1013470).
 .
   [ Martin Pitt ]
   * Tighten cups' and cups-client's dependency to libcups2 to current binary
 version. They use private symbols from the libraries which the automatic
 dependencies from the .symbols files don't cover.
 (Closes: #668662, #677180)
   * manpage-translations.patch: Update German manpage translations, thanks
 Helge Kreutzmann! (Closes: #670042)
   * manpage-translations.patch: Update French manpage translations, thanks
 Julien Patriarca! (Closes: #670224)
   * debian/README.Debian: Explain how to enable cups-lpd, thanks Vincent
 McIntyre. (Closes: #508941)
 .
   [ Didier Raboud ]
   * Backport upstream quirks for the libusb backend (Closes: #690982).
   * Packaging repository moved to Git, change VCS-* fields accordingly.
Checksums-Sha1: 
 b5a385f8c459445993c9ea9e164e350f034eb09d 3265 cups_1.5.3-2.4.dsc
 5d2eef3595367e5a41734a52c79f49dae6ae 344175 cups_1.5.3-2.4.debian.tar.gz
 bd8d2cdff38fe7e5a28efc08598ccb37acb45bcb 901372 cups-common_1.5.3-2.4_all.deb
 b75c63367be568e88e4b698ff17da2fed26bb1e1 84910 cupsddk_1.5.3-2.4_all.deb
 85c0da7e2ce57d9f457f1c6bfb7327bffbaaf82d 253788 libcups2_1.5.3-2.4_amd64.deb
 da8a3c7bce037b9942854ebd71d4b6bace9128fe 135836 
libcupsimage2_1.5.3-2.4_amd64.deb
 896074e139cf083ef67efa4e6dc86146a8e02732 114260 libcupscgi1_1.5.3-2.4_amd64.deb
 af4176172c5538d954028a859c473bbf05ee6530 102402 
libcupsdriver1_1.5.3-2.4_amd64.deb
 45604c58c76069fde894fc24b7e3f9cdebcb3f48 97284 libcupsmime1_1.5.3-2.4_amd64.deb
 5bafce10ee1271a657a6fd3a372b6a166cb65d6f 137316 
libcupsppdc1_1.5.3-2.4_amd64.deb
 814a8a6295aa5387aabdf75692acfc37d2b2531a 1379414 cups_1.5.3-2.4_amd64.deb
 4be8fd8f779d15550bad6a4b8b6bdbbc8536fbf9 180238 cups-client_1.5.3-2.4_amd64.deb
 0c866e80ef6cb2cb9d5eeec99bfdbf1e93544e27 325510 
libcups2-dev_1.5.3-2.4_amd64.deb
 a0072bfc1e98784d3050d92154e3c18b71a9b44d 65318 
libcupsimage2-dev_1.5.3-2.4_amd64.deb
 279be02361c730095139241a1b6470f18833b773 120102 
libcupscgi1-dev_1.5.3-2.4_amd64.deb
 0e68aa2b2c43e40ea95f1388dc3fae3a69957293 105338 
libcupsdriver1-dev_1.5.3-2.4_amd64.deb
 3817ffc558dc7a0bb6cb82f0acc65721bce54ef0 98106 
libcupsmime1-dev_1.5.3-2.4_amd64.deb
 a1e6e4128038f4a962ddab10077b96c613a54d73 154578 
libcupsppdc1-dev_1.5.3-2.4_amd64.deb
 b13da4fe01c333a82135e8c81a88129ced25292d 45622 cups-bsd_1.5.3-2.4_amd64.deb
 9c5d09687ea855893edd35116eec404d47701117 114708 cups-ppdc_1.5.3-2.4_amd64.deb
 6038d74c07b0220557c691284221d2fa66a8e1a5 2208184 cups-dbg_1.5.3-2.4_amd64.deb
Checksums-Sha256: 
 419ea67e2335881fd8140cebf8ff44e64355a0f82ec5a76bd2e706d06b2f4990 3265 
cups_1.5.3-2.4.dsc
 b9fbac2bf83ad061d2bcbca9353caf5629ffcb0a5ba4d2f4343eab52686f01bd 344175 
cups_1.5.3-2.4.debian.tar.gz

Accepted apt-setup 1:0.75 (source all)

2012-10-25 Thread Christian Perrier

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 06:12:12 +0200
Source: apt-setup
Binary: apt-setup-udeb apt-mirror-setup apt-cdrom-setup
Architecture: source all
Version: 1:0.75
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team debian-b...@lists.debian.org
Changed-By: Christian Perrier bubu...@debian.org
Description: 
 apt-cdrom-setup - set up a CD in sources.list (udeb)
 apt-mirror-setup - set up a mirror in sources.list (udeb)
 apt-setup-udeb - Configure apt (udeb)
Changes: 
 apt-setup (1:0.75) unstable; urgency=low
 .
   [ Updated translations ]
   * Amharic (am.po) by Tegegne Tefera
   * Asturian (ast.po) by ivarela
   * Welsh (cy.po) by Dafydd Tomos
   * Kannada (kn.po) by Prabodh
   * Serbian (sr.po) by Karolina Kalic
   * Tamil (ta.po) by Dr.T.Vasudevan
   * Ukrainian (uk.po) by Yuri Chornoivan
Checksums-Sha1: 
 96233cceaed897968c96e18211a64f53139cafa1 1728 apt-setup_0.75.dsc
 25ed6d1c11d0d185f8143bc4737ca963dee0c236 298571 apt-setup_0.75.tar.gz
 3b0cc0f564a91b4b6d630ac6cfa33da32404acdc 64786 apt-setup-udeb_0.75_all.udeb
 9f9c3207126e40d5f827f868faad4957bf06d658 72864 apt-mirror-setup_0.75_all.udeb
 bd3020ab1b71f9cd8394d10ed17d7f657c8c7eb5 95526 apt-cdrom-setup_0.75_all.udeb
Checksums-Sha256: 
 5505a9657401fec44308dc5b5eac20e093f20f91f37a4e1c2ad4714817a9da46 1728 
apt-setup_0.75.dsc
 2e5c56a02a0401d57849c6ff83a7526319cd8f1c75b0342334eb2c927de225e7 298571 
apt-setup_0.75.tar.gz
 cf684619ccafbedff58c8c025aab4a6499923d54e1d3d0f91d7e55be912b3a72 64786 
apt-setup-udeb_0.75_all.udeb
 13464786cfbff179f98dc32375dc58dddb2bb7c1b2e42a99dc8bd46e98606769 72864 
apt-mirror-setup_0.75_all.udeb
 32325a7e945ed9659d8446ec536ba7ee28bf16ec33f4884968faa6e7f25e19ce 95526 
apt-cdrom-setup_0.75_all.udeb
Files: 
 4eb97f4364abb9f76fbe6cb7db46275d 1728 debian-installer extra apt-setup_0.75.dsc
 fda252119ccb48504a019e7203f66050 298571 debian-installer extra 
apt-setup_0.75.tar.gz
 6bbb142c2dcbfc0d29ea9a8b8d3df098 64786 debian-installer standard 
apt-setup-udeb_0.75_all.udeb
 a54fe6abc70f9d19ba8ed34d4baf9068 72864 debian-installer extra 
apt-mirror-setup_0.75_all.udeb
 cbf79442fdd263d7e4f66a62622f41c5 95526 debian-installer extra 
apt-cdrom-setup_0.75_all.udeb

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

iQIVAwUBUIj/QocvcCxNbiWoAQIbHg/+JTNV6E7mWhbsQaAJbh3kNuWePIfvpFXq
DSMELwS0WknpAQR/nam2LSJuQ7B4ArcGFzN9vNjQR+fMsx/f4rUu2jqOGAOPlSU+
93tcmTnAOz95tHGakOYWYOHctsvGpL2GmIOVIU/6NLwtzy5mq8D+WpN9YTdVbRzX
3T/L+YLIDouWKP61FYjNfJYnIREZ9sbmPAYSkcR0+eWdLvNoaYaQQB9WPigowLhx
g3ZjWdNYxEWaRIdU5b4Tf8n4F/Q7BGzZN1ySS3VTw+RRbkMX6BQmhueRVsXFp3Qn
IQ1BZFnD6azVsiBc6JyLD19BasNmoWmv4fAAliLQxOXJcIxHtDNFLBM++L65M1Na
+Rd8vKX7CzFTaKcXJl40wT66SoqPcyowUlQZ0g15dKoeqaNhzO5N65Qk0gMXaB46
POA+QfFtnLlmCWoy+W2Insl2IsXzFWyh6sRwuwz/cTPlEs5baLerNZIwXzK4r7/u
/5LKnU/uXZTxAvgm8nlIMIw57mABXJQc7vo6tHU/JfRIsXTfi33c8GN9iMTuTV2m
iwrInui0LC11V+vnN91PdXVHMmIt2PUPpTwRiW/2O65MTiwAHHtJpl8ucI/d2Usn
M0yFv9eSY6tVdpsFfm/UJpXuL9Gwo7AosVcBov4OtVLr4RgvJ/dRqY4I66PkaIuT
1oJYQqH2cWI=
=kLTO
-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/e1trjzb-ys...@franck.debian.org

Accepted tryton-meta 17 (source all)

2012-10-25 Thread Mathias Behrle

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 11:33:37 +0200
Source: tryton-meta
Binary: tryton-modules-all
Architecture: source all
Version: 17
Distribution: experimental
Urgency: low
Maintainer: Debian Tryton Maintainers maintain...@debian.tryton.org
Changed-By: Mathias Behrle mathi...@m9s.biz
Description: 
 tryton-modules-all - Tryton Application Platform (modules metapackage)
Changes: 
 tryton-meta (17) experimental; urgency=low
 .
   * Bumping version to 17, 16 still hangs in unstable.
Checksums-Sha1: 
 2cd8a61cb69bf46b02b93f4f664dbefa4b49ddb8 1711 tryton-meta_17.dsc
 6a3a9b0bfb3b9385dc314a5e2ae1c11cbd5d960f 2748 tryton-meta_17.tar.xz
 f1c5fcf4a286932e6f968455c70e015a23df7c6a 3246 tryton-modules-all_17_all.deb
Checksums-Sha256: 
 7e12ba2ac6c577d7b4352eb98de8ca964f5be689c42dcfa8d5f651a8e2e45588 1711 
tryton-meta_17.dsc
 43dbc04c152ff9699088342db35d1153a602be09960df3b2791f7f06444fd615 2748 
tryton-meta_17.tar.xz
 277ac9a90b606b23034c6cfc9a07707847a9169917fdea6c0885a2aadaec12dc 3246 
tryton-modules-all_17_all.deb
Files: 
 b017ecad964d29a4dc344dec444dad5b 1711 metapackages optional tryton-meta_17.dsc
 30f7b433d072020ee1c94a146c166e59 2748 metapackages optional 
tryton-meta_17.tar.xz
 e9782ef22ed43207725e5ec7056f8bc7 3246 metapackages optional 
tryton-modules-all_17_all.deb

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

iQIcBAEBCAAGBQJQiQgGAAoJENbQm+SEBbv2DZwP/RU/amPOOu01QvvNq4rCMJbW
Xf7B1/VmDobcc9UkY0il3G8xnu/GnS0zM+n0qUB8LTSZaPdZm4Jj9rzeIg2NTHCT
ykK6UBfX81VRkkdc9jqmf6tAipykoCjK76i5AUDsHmmIsESKZkwXr+TsaBP3HaWH
HShOgZG3qfP39l1lLuI4wJwXoffaz+z0toct2hcH4rAwWBBgRiPiIPD2JRo3LZGV
Pcd8vBExa6mbuiLV2Ir4xqaSJVUFcrpD24n6JSJQCm790wf46TcBgf6DnHvSTTRM
ULvqH4kPRHMr87a9GF59ZxvPGy0f5p5dRRtgFPYyn+Agj9meGXLu+2eg6Z3Elvhw
cVDXpWE0cacKSfoElC7PlN2Khbw/IiBqwAWOaaN/3tllklnduA9Sxs4IJky9nnjr
ORiJjkR/Sr7DDEv3P1q8yZK0mnRZ+9nbRay0sw/QY2HQxewU8n8/8SiUGkzYqMee
1jBhoU0uESnpaC1XDAxb1fclKtQAR7N6oyxoTC+OgZjvHi785TvQGBT866NWotUy
zq23o3FpTsy+CNghckJBwFJ5z/mvNP6tnOy5/laZgudH4a+bkyZn+QO/lshytXkx
WB9UMdP6FlujgOVg3/UIsDh/NbYrI0v+7qpfBcHvYYGghiOnLGyUUq7vDOIqI0mW
yduJYUv3DaYqCAJd8rwU
=cwZh
-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/e1trk2m-00046c...@franck.debian.org

Accepted fuse-exfat 0.9.8-2 (source amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 12:41:07 +0200
Source: fuse-exfat
Binary: exfat-fuse
Architecture: source amd64
Version: 0.9.8-2
Distribution: experimental
Urgency: low
Maintainer: Sven Hoexter hoex...@debian.org
Changed-By: Sven Hoexter hoex...@debian.org
Description: 
 exfat-fuse - read and write exFAT driver for FUSE
Changes: 
 fuse-exfat (0.9.8-2) experimental; urgency=low
 .
   * Build without -fPIE - hardening flags -pie.
Checksums-Sha1: 
 373adc6977c2b4056b6449ec2dff996a767ff084 1862 fuse-exfat_0.9.8-2.dsc
 144d392c6adc887bcdbc753ba57fdfa723b1c80b 2220 fuse-exfat_0.9.8-2.diff.gz
 76080efd5f35071c2ef6b7f24dbb87b293f0004e 25762 exfat-fuse_0.9.8-2_amd64.deb
Checksums-Sha256: 
 bf6db704d4c6c604e943a6eb7a986eabb7aeb3598088d24fb679a10ca4be7259 1862 
fuse-exfat_0.9.8-2.dsc
 cfca8b499f156b8dee197cf8ab22d1ba0033e3562f9181ba5826c77a44d13eb3 2220 
fuse-exfat_0.9.8-2.diff.gz
 d5b260a96b1495c2ae3c873cb819536f979f0870ee8af8a09d6d659d320d6a86 25762 
exfat-fuse_0.9.8-2_amd64.deb
Files: 
 42d4c16d806545867d9a0d5cf5241e1d 1862 otherosfs optional fuse-exfat_0.9.8-2.dsc
 e85d7a85a84e999169927151ead36171 2220 otherosfs optional 
fuse-exfat_0.9.8-2.diff.gz
 57cdeb23ffb31c83b1123714bb578cbf 25762 otherosfs optional 
exfat-fuse_0.9.8-2_amd64.deb

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

iQIcBAEBCAAGBQJQiRn5AAoJEKbcJNnaJJPRQDUQAJTnucOnMDgg4Or/ie07PgFx
SqUiG2Rbyk1RNnaGvjFcRt+KrHjY9elmpY6FcyDQAVEP3MHPL2aDGq4lVKBz3W13
n954bqen44ady/2LqInSkczH8RRAaJq3aQVuNwJ/RpfKuoQIZzBEyEh3Uj0a1F/l
VBFhsH3kmJn2AdLYxGelqqdIxp6YgAPPk/ljUqRxEeri0qtPN1dzfC77+yEombEz
WH2cWpzYfNNAWg65CF01pOdzQORMyn3kbl2WG2IxszluFE0CqZ+jxcMquGWKIBjs
Z+nKRdWrQ3apa9A4yJXfMwlxzvHhrW5A71D9hHtaGjQKXKIX0R66eI0c10r+WB+z
fom4OwsdykpXX6zLtsozuigo5PALchrs5ypSkOtu39Z0sqRBWpuNn+kC2bGXAhkc
77BlONHR0l5kg/PE+AZVCHNoR7EQ8TITDoai2nG15H4u0zmacvif0L2iISw2XTbL
nu+GiZVUbDtpdLyxMC1/maGwkyNkENdF8Gn4Ygg1R/w3HDetPl0crUS/TD3NfD2t
KF1nXlVofTHxJNy/y6xzoLjt0MlcZGl3w+9RXavobS8zOUtOQXqXjHBfwbpseqg6
IIZS+2xyaBcpLEjrbKWy8mStXD4XwUFi3p6hBBYKtkKSdRCWrpTUQAWFT/buAgGm
eWyHX/eOYYR2ypMEgi7e
=+yLc
-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/e1trlcp-pj...@franck.debian.org

Accepted exfat-utils 0.9.8-2 (source amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 12:46:46 +0200
Source: exfat-utils
Binary: exfat-utils
Architecture: source amd64
Version: 0.9.8-2
Distribution: experimental
Urgency: low
Maintainer: Sven Hoexter hoex...@debian.org
Changed-By: Sven Hoexter hoex...@debian.org
Description: 
 exfat-utils - utilities to create, check, label and dump exFAT filesystem
Changes: 
 exfat-utils (0.9.8-2) experimental; urgency=low
 .
   * Build without -fPIE - hardening flags -pie.
Checksums-Sha1: 
 f5986ddc8d2a8da07202cdd0d21c808b960232a1 1841 exfat-utils_0.9.8-2.dsc
 9ff4437ec35152a4f6dd0df1deef122e28d04c56 2325 exfat-utils_0.9.8-2.diff.gz
 c31001a3640e00fd462c2ea6e90a726b6b120da7 82492 exfat-utils_0.9.8-2_amd64.deb
Checksums-Sha256: 
 8e7da5f2658fe00fa1e60ba7fb9bcfd50d0b471f61c4c66c31175dd894f80cee 1841 
exfat-utils_0.9.8-2.dsc
 141e71fe363dbf53d7cbcc6b7f972abb0f0c8a7b647951f112d25e153a12d677 2325 
exfat-utils_0.9.8-2.diff.gz
 b806883a61d34102a791e63878afb851653f70b04faec0561210cfbc4c70d055 82492 
exfat-utils_0.9.8-2_amd64.deb
Files: 
 8a60f124e4e45deff8cadb03948f324a 1841 otherosfs optional 
exfat-utils_0.9.8-2.dsc
 e045bb974cc4f476cd0b1414495a149b 2325 otherosfs optional 
exfat-utils_0.9.8-2.diff.gz
 595e32fbf2745d5506734247e7683f9a 82492 otherosfs optional 
exfat-utils_0.9.8-2_amd64.deb

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

iQIcBAEBCAAGBQJQiRnuAAoJEKbcJNnaJJPR3EYP/3BfGlPEN7/voHDhLRmFXo4B
FRg+ZgivLuB7aMJWwjWSkHKuklt8EF2eGqlOAK4hxRzUD3GhWIamiq661JmBkPOf
z7Yws4FvAs0TSbsAY+92VdUA1B9nRq8vE73AjzhEtdmzq5JquLDz26p3OyovjKYt
tl4+8lPR0FTzpHIaPO1apHA4hJj7pRQ1N+OfBtV5hJ4m4JhMDpuIumuVnT6FQLKM
w0R/DAuMA5aoX9SFvbZ7kQj4QqS14V4v0hZL6sUNlqa3WlQ9nMjm/00kxVck9PkJ
JHVprndMgwKBGrSdyAVQsYr1UUNpHeDNVmAyiwhRq9vaZU6ehDBtu1Jn7fEytGg2
0moLr8Z/V3TdBRBhVijeWhSNkR5xpRBL3BGUu3k6lFeBG0rMiJXND7KxjR1IyU49
Q223BizfWXTmMwBKVipU4/sqoahvAPkPy/MjcVwkSENMQEQ3hQq5Xoi2AnCb/g0P
wpis2Sg0GT+3Y9vNv3sKAsq9btPRwX2PA4VSQ0aPotJaLzPG4Ycv9aZrTLnTd5Iz
XKO5f0+5q7ckRr9LeCTpG0q6D0D5kTvtzQRf7ohopd35RpaVzZx2UQZEQ1R4wxt3
xlf1WKEAUXnFsWUGMcviRf9uvRHipfLzCezQ1/uu+3IBR7mlq9La80oikBbJ7lX5
3HIFtjzSKJTb/MyY7a8y
=Esfo
-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/e1trlcl-mr...@franck.debian.org

Accepted rpm 4.10.1-2 (source amd64 all)

2012-10-25 Thread Michal Čihař

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 12:40:59 +0200
Source: rpm
Binary: rpm rpm2cpio rpm-common rpm-i18n librpm-dbg librpm3 librpmio3 
librpmbuild3 librpmsign1 librpm-dev python-rpm
Architecture: source amd64 all
Version: 4.10.1-2
Distribution: unstable
Urgency: low
Maintainer: Michal Čihař ni...@debian.org
Changed-By: Michal Čihař ni...@debian.org
Description: 
 librpm-dbg - debugging symbols for RPM
 librpm-dev - RPM shared library, development kit
 librpm3- RPM shared library
 librpmbuild3 - RPM build shared library
 librpmio3  - RPM IO shared library
 librpmsign1 - RPM signing shared library
 python-rpm - Python bindings for RPM
 rpm- package manager for RPM
 rpm-common - common files for RPM
 rpm-i18n   - localization and localized man pages for rpm
 rpm2cpio   - tool to convert RPM package to CPIO archive
Closes: 691342
Changes: 
 rpm (4.10.1-2) unstable; urgency=low
 .
   * Do not overwrite installed manpages by (wrong) symlinks
 (Closes: #691342, LP: #1018372).
   * Correctly pass dpkg-buildflags LDFLAGS.
Checksums-Sha1: 
 9d41bc39c3be86c79bbc15cb1b6abaed420f7a10 2690 rpm_4.10.1-2.dsc
 63b357154fb4de32c968e26fd38187f80f59a65f 35508 rpm_4.10.1-2.debian.tar.gz
 75990f922ba8cd119cbf97ec892ff4af52d28d23 1075414 rpm_4.10.1-2_amd64.deb
 4a0cd42b4050b784b6669211ec41077dc0fdf110 928856 rpm2cpio_4.10.1-2_amd64.deb
 7f09698125558410d7be24e9039d3f608fba5e3f 947932 rpm-common_4.10.1-2_amd64.deb
 fb18aa9936b10699104a1a8fc6f597712c95e6b3 1443274 rpm-i18n_4.10.1-2_all.deb
 0dec904b8eda9df8c4ec95d7ad6a0b83d82fcec5 2321118 librpm-dbg_4.10.1-2_amd64.deb
 2b7a1a352ed7ab7ee92d7c9cfe6bd61406fc461a 1107804 librpm3_4.10.1-2_amd64.deb
 d5beb89f05e4874870dd096d4627a270c9641d1d 1002416 librpmio3_4.10.1-2_amd64.deb
 51294f53007c0916a1a76621662649a0c214ca94 993238 librpmbuild3_4.10.1-2_amd64.deb
 b39ffdfd834b5e9078e1476914d6ea13daf3ee93 932460 librpmsign1_4.10.1-2_amd64.deb
 f1a09a5f1989f7dc052f77d53ecd91054c972624 985626 librpm-dev_4.10.1-2_amd64.deb
 26089cf5e50741802ca3d58b300c555645b8b99d 1006992 python-rpm_4.10.1-2_amd64.deb
Checksums-Sha256: 
 9aafabaf135c4d3cd30d5d0a41382bff2ea541f226f4a8800496261b6ec053ad 2690 
rpm_4.10.1-2.dsc
 71dc05031cb4544cdf99f0d5cd12550d6e98ab16af5407eb519620873834f560 35508 
rpm_4.10.1-2.debian.tar.gz
 a9e1c9174a34a09373824fdf0eef3499e6f1c257dc368a604a02dc40dd6de799 1075414 
rpm_4.10.1-2_amd64.deb
 d6f9da0646f916b8c4ccef65c3d9e702efcc65d1a376eeb7fc38cf7bf4d721b0 928856 
rpm2cpio_4.10.1-2_amd64.deb
 a6553dce119a00924704a22ad89a05eef04263882ea199d83978a304ed0c7bbb 947932 
rpm-common_4.10.1-2_amd64.deb
 3483ca0a06af9a93efde123022bd255259f27f9ea9ee96869c350ac98936a5fc 1443274 
rpm-i18n_4.10.1-2_all.deb
 9d7a579e1b8a5ecc239b8e329bbcb4c155df00e29340b5fbe8f1a39f6661a550 2321118 
librpm-dbg_4.10.1-2_amd64.deb
 ccdcbf281c9bc546d9ffce7ededeb324d9605f5cbb6f2c87780005128a642dac 1107804 
librpm3_4.10.1-2_amd64.deb
 e7226723fcf44eb7e4112adee49740a488722256e8c1a838c056610affe67654 1002416 
librpmio3_4.10.1-2_amd64.deb
 78017a1d1fe915ab279a43ef36fa6b15022e39e9085afde1ff99dc9f3bf781a7 993238 
librpmbuild3_4.10.1-2_amd64.deb
 8b5a3563457d5b569f862be122e1297b1191a0149cc982abd40711aa7cf9db44 932460 
librpmsign1_4.10.1-2_amd64.deb
 7ef6c7317475132cdf50efeb4ce53ab64ff2c78015eed1afb7298712797a2e1e 985626 
librpm-dev_4.10.1-2_amd64.deb
 425bd206b989c2889ae7246ba78b4c860b2693f334c1b364c5bf607ebdb1080c 1006992 
python-rpm_4.10.1-2_amd64.deb
Files: 
 84d1dec4899eac1944f2a91e70b3f699 2690 admin optional rpm_4.10.1-2.dsc
 01bfe644a8446711f0b4e68f7a3f556d 35508 admin optional 
rpm_4.10.1-2.debian.tar.gz
 09bfed26110f1ce53fb80a4bf776af38 1075414 admin optional rpm_4.10.1-2_amd64.deb
 4102141a190e397628c4fcc2c2b8de2b 928856 admin optional 
rpm2cpio_4.10.1-2_amd64.deb
 2fed42c1303c3a1a044902d8c8f81c83 947932 admin optional 
rpm-common_4.10.1-2_amd64.deb
 3483189e641c8495d1e2bcc818cfa3c8 1443274 localization optional 
rpm-i18n_4.10.1-2_all.deb
 1d113c29c5772b057f890a8e469d45e1 2321118 debug extra 
librpm-dbg_4.10.1-2_amd64.deb
 e17487b68dfe9fc448c5dd0f8e3b3e22 1107804 libs optional 
librpm3_4.10.1-2_amd64.deb
 2a921f887903b3d74602a0889478a4ca 1002416 libs optional 
librpmio3_4.10.1-2_amd64.deb
 69d24631451a60e7a9a6e320aed684ca 993238 libs optional 
librpmbuild3_4.10.1-2_amd64.deb
 57adaa3c96bef21b479f473f3698f6c7 932460 libs optional 
librpmsign1_4.10.1-2_amd64.deb
 26a012eebbbaaac4bf7b691f10521a0d 985626 libdevel extra 
librpm-dev_4.10.1-2_amd64.deb
 7e65847b2bde5b74dda366507a8789e6 1006992 python extra 
python-rpm_4.10.1-2_amd64.deb

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

iQIcBAEBCAAGBQJQiRi3AAoJEGo39bHX+xdN0/wQAJAwpypJc5Sg1ixFZcPMXLxV
IT56zH01np9lKim490tmfuAkRuzrspZJ2PjORT1SX4g09ZfDQ5w44iYyR1gZoSzx
24FRkuyj0c3HvIHtvgejxs6HE4OkYJAjRSpzrkXuY5tj0+Eb6hax117Cebmm/Z2D
ydZvelPHM63Jm5j5UeoEIAv4b8r2GM9Rp7bDWi/Xzk3Yu4A4h3XQzhF/M3yDQqeV
xrZRiFICyt1KVyUnYAjd73O97dnQyuTJ8OXlLtMNaes6ZLhzgBFuKgomTiZOuplq

Accepted libphone-ui 1:0.0.1+git20110825-3 (source amd64 all)

2012-10-25 Thread Sebastian Reichel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 13:04:18 +0200
Source: libphone-ui
Binary: libphone-ui-20110825 libphone-ui-20110825-dbg libphone-ui-common 
libphone-ui-dev
Architecture: source amd64 all
Version: 1:0.0.1+git20110825-3
Distribution: unstable
Urgency: low
Maintainer: Debian freesmartphone.org Team 
pkg-fso-ma...@lists.alioth.debian.org
Changed-By: Sebastian Reichel s...@debian.org
Description: 
 libphone-ui-20110825 - SHR library for user interface
 libphone-ui-20110825-dbg - SHR library for user interface (debug symbols)
 libphone-ui-common - SHR library for user interface (configuration files)
 libphone-ui-dev - SHR library for user interface (development files)
Closes: 690150
Changes: 
 libphone-ui (1:0.0.1+git20110825-3) unstable; urgency=low
 .
   [ Gregor Herrmann ]
   * Fix missing copyright file after upgrade from squeeze:
 change docdir in libphone-ui-dev.postinst from non-existant
 libphone-ui to libphone-ui-common (same as in debian/rules
 for new installs). (Closes: #690150)
Checksums-Sha1: 
 6fbade08f3ff7b4579607c551dc46bb0331ad273 2471 
libphone-ui_0.0.1+git20110825-3.dsc
 7029dc863cdba5bf09f4a4f8d1ead1d8a1deb555 5046 
libphone-ui_0.0.1+git20110825-3.debian.tar.gz
 957ecba7422c95632d926897661e7b5ee7bf6ca8 45850 
libphone-ui-20110825_0.0.1+git20110825-3_amd64.deb
 9245429c44b529ac6c02d84bf087a2c27cac888c 101844 
libphone-ui-20110825-dbg_0.0.1+git20110825-3_amd64.deb
 972751edf021ecbb674850b28d924e093047d48f 3990 
libphone-ui-common_0.0.1+git20110825-3_all.deb
 0690f5c1b685ea94c570becd6472a02550df9b25 6390 
libphone-ui-dev_0.0.1+git20110825-3_amd64.deb
Checksums-Sha256: 
 4adddb88b67da99b6f5a221d46cbdf7059b7579ca0c6196e18cd89ad37d068e8 2471 
libphone-ui_0.0.1+git20110825-3.dsc
 4cf98c81e75a1030a84c35f66e6d911b69eb8ab2bea681fa696a597b54383db0 5046 
libphone-ui_0.0.1+git20110825-3.debian.tar.gz
 193bd8b846b6efb0e0cafc1e22151f8410b0a7068aab2d7b5647ebb3b1de773e 45850 
libphone-ui-20110825_0.0.1+git20110825-3_amd64.deb
 10de1bd776624163efd7f5ca7c37df1580758e6c076c39693b7c9809d0a04cfc 101844 
libphone-ui-20110825-dbg_0.0.1+git20110825-3_amd64.deb
 29f5a57cc9310c2923f5abca319b0858a2f54517773f9f6a797736feaf6467c3 3990 
libphone-ui-common_0.0.1+git20110825-3_all.deb
 52adefad45e070f1e36dd68c564838c59bcc7c3d12818c603138cf58a7f0f2c5 6390 
libphone-ui-dev_0.0.1+git20110825-3_amd64.deb
Files: 
 d800d107b67dd184c0548e33cecb9c4c 2471 libs extra 
libphone-ui_0.0.1+git20110825-3.dsc
 55ee4fb8718a999e0ba059ca3a471218 5046 libs extra 
libphone-ui_0.0.1+git20110825-3.debian.tar.gz
 2414e4f29167b773561b5cdd38cfe953 45850 libs extra 
libphone-ui-20110825_0.0.1+git20110825-3_amd64.deb
 823f36077fb621b7c60c29ea5448e481 101844 debug extra 
libphone-ui-20110825-dbg_0.0.1+git20110825-3_amd64.deb
 42ee075ea27771e7e527f6cccea4937d 3990 misc extra 
libphone-ui-common_0.0.1+git20110825-3_all.deb
 70eafcc5d3c58905362382e2adfc3669 6390 libdevel extra 
libphone-ui-dev_0.0.1+git20110825-3_amd64.deb

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

iQIcBAEBCAAGBQJQiR1qAAoJENju1/PIO/qal4EP/jueD12nqxyWlGoneG2KWnxz
GzSzqWbSt1OrINwG5T1pe8vvuVuveJzAK+QRbrvFf7KAZOyeE0bZmet2hhBNhhfm
G+AsCh8mxkfK4ACpXCb3CAGfBQMB+FlNt+bXV1yepTmmurItBIzY5twLjot5qZdY
/t/rQJGDClqFGSQ0C1Rt90dPlviF59YFvOyKji4B5Fo52wuxmCDEpOZpGMhH0uos
Nc/0WFag0MJwLYTdoN9+l3tuxehaahmnsaZv/hyq/OGxbqzblYtzC91365fo7b0Q
WSsaKjV6cd2e85khBZd+nuDm6zBrL/OTZ6hogt6djlX5c+GtBrgnzICik5/3YUj6
S2vwqlAAsaLeLTlHjEckp+MAeUcdmxqXb9i1GfOaz211moKX0A8Ar0fYwwcmVbQu
pIyY+PVh15eCK2dHWdIhrtY7L+Yz2wzrddjXGS5OMYr1k4rXhKUoAAu92NNYL4Pf
OhUWtclkN37lBJez0PN7L64zqyLP16r3C3IEFs/GLS3zWulkhm8J//w7UeMts7as
sZF24McjkeDY0vLTEI1Bv/es1XCQSh7Wy+ksXJkjnJKWkWPHfOgId3S+KwXLmdRO
y4E26wtU23uU9wdD7vQ47lmrVfoxHZ0hFfbwcPWwgpMkwF8bUeYZGTKQZ6CbXcwO
rjzp6aKsWEEEb1dsMAWS
=8heF
-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/e1trlrj-00046m...@franck.debian.org

Accepted gssdp 0.13.1-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 12:42:20 +0200
Source: gssdp
Binary: libgssdp-1.0-3 gir1.2-gssdp-1.0 libgssdp-1.0-dev libgssdp-1.0-dbg 
libgssdp-doc gssdp-tools
Architecture: source all amd64
Version: 0.13.1-1
Distribution: experimental
Urgency: low
Maintainer: Ross Burton r...@debian.org
Changed-By: Andreas Henriksson andr...@fatal.se
Description: 
 gir1.2-gssdp-1.0 - GObject introspection data for the GSSDP library
 gssdp-tools - GObject-based library for SSDP (tools)
 libgssdp-1.0-3 - GObject-based library for SSDP
 libgssdp-1.0-dbg - GObject-based library for SSDP (debug symbols)
 libgssdp-1.0-dev - GObject-based library for SSDP (development files)
 libgssdp-doc - GObject-based library for SSDP (documentation)
Changes: 
 gssdp (0.13.1-1) experimental; urgency=low
 .
   * Imported Upstream version 0.13.1
Checksums-Sha1: 
 1c3341fef4e0ff023599c4a2c7d40821287842f6 1659 gssdp_0.13.1-1.dsc
 49ed88d6859cbc6b661f488d4ab155e80d3024e8 273028 gssdp_0.13.1.orig.tar.xz
 34ef8d9b76305c7954eb1fd897b1b17b701ada67 4611 gssdp_0.13.1-1.debian.tar.gz
 d2c7ed9a6fb6faa90bea6140bf341fba1293d0f4 23542 libgssdp-doc_0.13.1-1_all.deb
 e7d373a99d5c0d1524c5081b8ca755106fc6ac36 31046 
libgssdp-1.0-3_0.13.1-1_amd64.deb
 be79f12094d70d993e68e22e36ef8c281e1c11c7 10236 
gir1.2-gssdp-1.0_0.13.1-1_amd64.deb
 ee904e191dc0becb3e8a4b7d415829a6a7aff23e 39204 
libgssdp-1.0-dev_0.13.1-1_amd64.deb
 d4d2b18d88cf41687603654316e347e2bfa5 102870 
libgssdp-1.0-dbg_0.13.1-1_amd64.deb
 cf86f8fbc1f988c605937b4108b530d805902a33 19804 gssdp-tools_0.13.1-1_amd64.deb
Checksums-Sha256: 
 0d015841f4fbab0a7c44b3bd1839bf3fd1ff91d78ba458ceb86e70ab3fc9ac69 1659 
gssdp_0.13.1-1.dsc
 c950bb5e7d0d4a8e73afaab03fdb8ed4bcab5e33479a455b5168b23c920dc146 273028 
gssdp_0.13.1.orig.tar.xz
 eeddcce05c715cdd763692b8b86ea6dec0cd94643e798a20d287d0d8cbda947f 4611 
gssdp_0.13.1-1.debian.tar.gz
 2b0ae1f2da77351a6487cb90525b889c283322847e523f729009e1e4307658bc 23542 
libgssdp-doc_0.13.1-1_all.deb
 05fc2a8248d924e564a5b7738278178679fc6fc31204fc09dafed70e1a3509d5 31046 
libgssdp-1.0-3_0.13.1-1_amd64.deb
 c8707e07584ffede03cf727d9bea7ff36a75e032a627b40c4dda273b7f10721d 10236 
gir1.2-gssdp-1.0_0.13.1-1_amd64.deb
 756e38725643af4b044b38f3888fad5810b30def77e233b916f814dd9c5edb8a 39204 
libgssdp-1.0-dev_0.13.1-1_amd64.deb
 2c9a7cd8eb7b00ef20507d611877692a81690ed489a3266baabd1701875ad5aa 102870 
libgssdp-1.0-dbg_0.13.1-1_amd64.deb
 9a4b04c0b77cbac261f8b074f1f69d3165fc6542b307d09f5897ce27a14192fc 19804 
gssdp-tools_0.13.1-1_amd64.deb
Files: 
 1bf06da38508276e7bd92540b07cb6e6 1659 libs optional gssdp_0.13.1-1.dsc
 fc51e72b532d8ca2716ec456cb83e142 273028 libs optional gssdp_0.13.1.orig.tar.xz
 b5626560f0eb05a63aea82e8ccfe5c11 4611 libs optional 
gssdp_0.13.1-1.debian.tar.gz
 fcdad3f3ebb9cf4286df63bbf4fbb924 23542 doc optional 
libgssdp-doc_0.13.1-1_all.deb
 4f6e7f95d05a704d688d270ba8ab9162 31046 libs optional 
libgssdp-1.0-3_0.13.1-1_amd64.deb
 43c3f2f6329181c56e37c3ce9488cdcf 10236 introspection optional 
gir1.2-gssdp-1.0_0.13.1-1_amd64.deb
 1389abefd82ada4a02a86cf229eec3ca 39204 libdevel optional 
libgssdp-1.0-dev_0.13.1-1_amd64.deb
 0c3cda69e39c30c55e83d8e47d9f1691 102870 debug extra 
libgssdp-1.0-dbg_0.13.1-1_amd64.deb
 bbeedd01dc813606534ad39b90834996 19804 net optional 
gssdp-tools_0.13.1-1_amd64.deb

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

iEYEARECAAYFAlCJIJIACgkQcgQ2cL3l8e6a9QCeLxeT4uYFSPXylt7pm2Bif8LX
H4gAmgMbaGdV5Zn8mkQJ0nhAbCmf4b2a
=2omj
-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/e1trlfx-0007n0...@franck.debian.org

Accepted osc 0.136.0-1 (source all)

2012-10-25 Thread Michal Čihař

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 13:08:20 +0200
Source: osc
Binary: osc
Architecture: source all
Version: 0.136.0-1
Distribution: unstable
Urgency: low
Maintainer: Michal Čihař ni...@debian.org
Changed-By: Michal Čihař ni...@debian.org
Description: 
 osc- OpenSUSE (buildsystem) commander
Changes: 
 osc (0.136.0-1) unstable; urgency=low
 .
   * New upstream release.
Checksums-Sha1: 
 c37d1034d75c6b6f88f7b08a000ab66ece2e2024 1967 osc_0.136.0-1.dsc
 428eb9b6836afd9090ca7b3ac7ca9983a42c5cc5 282525 osc_0.136.0.orig.tar.gz
 47dd6d851e3078e733ec6c23ab6da1b44da31225 4655 osc_0.136.0-1.debian.tar.gz
 65834249a4ec744baa3c88e3b4394302e736ed33 228376 osc_0.136.0-1_all.deb
Checksums-Sha256: 
 44e4b01bf606101c82327d8bf1ee4c6b675efb3df4c28cf7ac14b8497b13218e 1967 
osc_0.136.0-1.dsc
 ea3188b4c29d4507bfb03ff2690a3eee6f0e63390f72ed3f67a7856b10bd1b88 282525 
osc_0.136.0.orig.tar.gz
 1ab77807b630f01a22a69193b9d5ecda8e6dd3f9f607cfb1e906e1b458284830 4655 
osc_0.136.0-1.debian.tar.gz
 f423348a63170e9af3766fa3b9146258c717ef5a48fee1a2e58238ce73ff99ea 228376 
osc_0.136.0-1_all.deb
Files: 
 660dffd08c6195eb48e665d81f15da7c 1967 devel extra osc_0.136.0-1.dsc
 84bc216ea230e602406dc8e53f54694e 282525 devel extra osc_0.136.0.orig.tar.gz
 3029768d79ad3d2c644d0d9e0b7c1ec1 4655 devel extra osc_0.136.0-1.debian.tar.gz
 b50ce7521812fd07511acbfc9297e047 228376 devel extra osc_0.136.0-1_all.deb

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

iQIcBAEBCAAGBQJQiR7GAAoJEGo39bHX+xdNL2QP/0R9mozdwmaYoDww8clkZtRv
SzFUBJS4IzzH0TYrvuVKQPn6zeFri5xZQjIkVDdPqK7JvznzHB6tgsiUkW9Ho9Xp
DlLRWyB/FOVO0tIjyAtiXyiT7C2F/JxChGvOkeyErjO0gS1f0arzNdrsE3yfWl3I
ZApr4pXZW1stGAd4qTYEQhjacwOV/9aw4K8C4beZZWyTnVm5V4IdBltTTjLTEpoO
eV9XNAcqXPJmK3WeKLIhZj+oOzsRIFuz78GamYZs1bsfqjyiq/QmlSEMiwMutCAJ
6Ldu9ViTkcrd3aWm10173lqeQCwDWXOHYMI87moqtNXFj813SolvLBos+iDfdJUS
3H3KwnwKDbWnxFSXSEV274ssKfAoW3O74U/03gmQBi4Ur0wfNNQkHFyEo1DTDgAb
pVFqe1WdQsBNQbJC1VsyvIONotYnhs5AnpQxqBi8+y32rmL8AgYyMCMk2a8eS32Z
zDSFBPOxj2YBF83b3LjIeo0RaTwSa9mmUoWZxHy3Lh6T+wknlxjFc265eFZKQd0S
OHcBXyi0PBPRkbBNbI7XkEWGpT0yS/SnbKF+0t4GipRqH7OW6hYtaGWZvVdEErLM
usFlGiMdfz63Wdds9Buq3N5MHBSDYZ4CoElb/hpq72FiDNjjl01Kf5gthT1ulLtF
tuK5S1cHLxRPVLvurSjL
=LYMn
-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/e1trlg9-0007tk...@franck.debian.org

Accepted tint2 0.11+svn20121014-1 (source amd64)

2012-10-25 Thread Sebastian Reichel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 13:35:15 +0200
Source: tint2
Binary: tint2 tint2-dbg
Architecture: source amd64
Version: 0.11+svn20121014-1
Distribution: unstable
Urgency: low
Maintainer: Sebastian Reichel s...@debian.org
Changed-By: Sebastian Reichel s...@debian.org
Description: 
 tint2  - lightweight taskbar
 tint2-dbg  - lightweight taskbar (debug symbols)
Closes: 672840 678918
Changes: 
 tint2 (0.11+svn20121014-1) unstable; urgency=low
 .
   * New upstream checkout (Closes: #678918)
- Fix for no task cycling if all windows are minimized
- Fix for incorrect task cycling when windows visible on
  all desktops are present
- Adding startup-notification support
- Drag and drop support for launchers
- Localize launcher tooltips
- Launcher: add icon lookup in ~/.local and /usr/local
- Disable mouse hover events when the launcher tooltip
  is disabled
   * Do not install tint2conf (Closes: #672840)
   * Add libstartup-notification dependency
   * Bump Debian Standards Version to 3.9.4
   * Bump compat level to 9
Checksums-Sha1: 
 1c675173a399437947c7d6048b1f1cebd3b11b1b 2095 tint2_0.11+svn20121014-1.dsc
 31ac13f389c20951deb1f4dc7cb71aaafd1447f3 112617 
tint2_0.11+svn20121014.orig.tar.bz2
 435457e37ea16305ab71fff8d311d236c2e368cb 67880 
tint2_0.11+svn20121014-1.debian.tar.gz
 f2a647d88d99a3cc30ef6ac792091c9dfbd495ad 158820 
tint2_0.11+svn20121014-1_amd64.deb
 271b16de759cdf1414d600e4bf3a61bcc5e49314 189122 
tint2-dbg_0.11+svn20121014-1_amd64.deb
Checksums-Sha256: 
 022fd6a3e3c329b03a3369ce164b951393346b3a5338fdb0ee61d2754fb3f424 2095 
tint2_0.11+svn20121014-1.dsc
 9fb65488a892ed07cb9c79ee171b43ac7cadb87a6d1cd5d1c44241140114925d 112617 
tint2_0.11+svn20121014.orig.tar.bz2
 409749be62ebe8e061112b7d2bb2a9043f2ca0e00c4d88e11e6db17ccce125c6 67880 
tint2_0.11+svn20121014-1.debian.tar.gz
 17f3e118db9f267961c6b120f51a4c43f2c8377f13d8a4c4218794ff538e5b43 158820 
tint2_0.11+svn20121014-1_amd64.deb
 f294e086527529529e3e495848237a7378d45fb2a50e061a3447e3075f4bd4f8 189122 
tint2-dbg_0.11+svn20121014-1_amd64.deb
Files: 
 73184551da35ff55bcc97380b3be3d1d 2095 x11 optional tint2_0.11+svn20121014-1.dsc
 d1fc4c65e4e8233772e76010302bfdfd 112617 x11 optional 
tint2_0.11+svn20121014.orig.tar.bz2
 fa6fe6e79e16b43e7e83773d66cb 67880 x11 optional 
tint2_0.11+svn20121014-1.debian.tar.gz
 9975b732297d563afaf8e57f46bf7567 158820 x11 optional 
tint2_0.11+svn20121014-1_amd64.deb
 b2b2277423409c1cb62f3a696964c777 189122 debug extra 
tint2-dbg_0.11+svn20121014-1_amd64.deb

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

iQIcBAEBCAAGBQJQiSjyAAoJENju1/PIO/qafAEP/2C7sLayc5FiZlGmu7NTLEvT
2Vf2W0QPmxY9c9ZbZwFewG74JxZUlQDo94CoIafKonsmQ5KA4TBDOBnidqicUN6S
9/Hp+iMvyK2TRJVBaTsLvFfTCkm+M3LmM2EBoHvVxL+n59+RuX1Rg1S9HQo0szlo
Mj84sTK0c3rQRMkzWiC49zCJjo7fXXcM6osKvYO6BwUhG8dZEqCpn+gxf1JedPrA
0K8SaoyuYX+AEc3QLtN7FpJ2DJ+Az8meWVfcF/jLon44PjYlQNDUVIJqU5a6Qt/5
xJx+F/MWnKnoWGJ1m/hXBtp7iYE7qLXNB9Ws4zjWJKy6oFQdDdONDNRr25olxuYU
aSspwgiAQhje1A26fRi0cvC1ntZ5uVr8LksenNr6DGYq4F1mT8PRgVtB05tsDFcu
U2wpyUKmlys0dkqDcH8QSkTwDNDy2Con1n4Y4kqH0IwnwOGwmKdOjbFb/ehPr92H
vVFlyJL67Mls44+52oU+HuLtE3FxzuBAaE9C6scgNyNhAZSfmRMp3Jw4jFoWLXX5
4TYpvKemUoQ6/KoL257/8aD55Q3I2sFXL86Gi7RJ5K+6grKc+5AsO/B2UZHOSXMf
w3b4Fwby+gL2glzVKNQEZ7pJF6bi+hWkEJz4YDhWDh0dOVX4tBA5kQnMcM0xtvk1
VwRYjSNNggbmatmTjsCC
=t8Q6
-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/e1trm9o-00044s...@franck.debian.org

Accepted gupnp 0.19.1-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 13:43:57 +0200
Source: gupnp
Binary: libgupnp-1.0-4 gir1.2-gupnp-1.0 libgupnp-1.0-dev libgupnp-1.0-dbg 
libgupnp-doc
Architecture: source all amd64
Version: 0.19.1-1
Distribution: experimental
Urgency: low
Maintainer: Ross Burton r...@debian.org
Changed-By: Andreas Henriksson andr...@fatal.se
Description: 
 gir1.2-gupnp-1.0 - GObject introspection data for the GUPnP library
 libgupnp-1.0-4 - GObject-based library for UPnP
 libgupnp-1.0-dbg - GObject-based library for UPnP (debug symbols)
 libgupnp-1.0-dev - GObject-based library for UPnP (development files)
 libgupnp-doc - GObject-based library for UPnP (documentation)
Changes: 
 gupnp (0.19.1-1) experimental; urgency=low
 .
   * Replace gupnp-vala before 0.10.5 to avoid conflicts
   * Imported Upstream version 0.19.1
   * Revert Bump gobject-introspection build-dep to 1.33.4 ...
 - upstream lowered the requirement again in 0.19.1.
   * Revert Add vapigen-m4-macro.patch from upstream
 - now included in upstream release.
   * Update symbols file with new gupnp_context_manager_get_port
Checksums-Sha1: 
 cc8f3adca9e597f4a81eead5f8e49f3e675df21a 1774 gupnp_0.19.1-1.dsc
 566edab2038eb886475cf984ee6809d6598bacb1 364128 gupnp_0.19.1.orig.tar.xz
 1302d7f1950c1547dd0bd8308df97c455ee9c30c 6954 gupnp_0.19.1-1.debian.tar.gz
 2c07614ae105bd705ea67017ccebf7e9e2b0ba7b 87036 libgupnp-doc_0.19.1-1_all.deb
 7ced01ef44a851fd157199f7ba0643232d1ff940 76844 
libgupnp-1.0-4_0.19.1-1_amd64.deb
 ab08cc1dd3e39f115f1e58e76e12edf80d6a538e 20640 
gir1.2-gupnp-1.0_0.19.1-1_amd64.deb
 3dbc2a7460003fcfc75135546e167d250eef6d28 137560 
libgupnp-1.0-dev_0.19.1-1_amd64.deb
 13f01fdaf0d4b4563c5ec013ed66da1e59326c7a 225980 
libgupnp-1.0-dbg_0.19.1-1_amd64.deb
Checksums-Sha256: 
 b5040389864f2a412208af36bc7907f7290af9de2bc5e9968af98a78c41052d9 1774 
gupnp_0.19.1-1.dsc
 26898b9ac56482635c8d9c8bd43e30e95ae8ed9e189892678c6ee0ab82b6eafc 364128 
gupnp_0.19.1.orig.tar.xz
 40be00b21ece6e71f9a2923ec85f3465b034ad7eac38de4dc038aebe1ac74fe1 6954 
gupnp_0.19.1-1.debian.tar.gz
 c733747e3d5385bcfcf7f01e6da836f64705e1338883bac17b37bf7bdc30b3be 87036 
libgupnp-doc_0.19.1-1_all.deb
 7778ede943510cbb9dd7722d2948aa741a0389c4d804a1e3f1448e73df386d02 76844 
libgupnp-1.0-4_0.19.1-1_amd64.deb
 9ad3ea338ec7618b8937feb0208a85f777bd44608f7e790ea72a957321b2fbba 20640 
gir1.2-gupnp-1.0_0.19.1-1_amd64.deb
 73c433c8db1800b66558d615a6c937bd1f1f2ba8d941ef256d16476d7b878ca3 137560 
libgupnp-1.0-dev_0.19.1-1_amd64.deb
 c027e8246456d86cf5a853d0b9796f94b3c316aba1aa88533388a89c8f938c38 225980 
libgupnp-1.0-dbg_0.19.1-1_amd64.deb
Files: 
 c0f9abc1b6cf9c71dd8bad3de0a18abe 1774 libs optional gupnp_0.19.1-1.dsc
 ccb74a2e1d378ed3cfa06e2e458162d3 364128 libs optional gupnp_0.19.1.orig.tar.xz
 48d5fe3f14c6db0fc73463fa658d66f9 6954 libs optional 
gupnp_0.19.1-1.debian.tar.gz
 4054624803b27631877fa385e5781c9e 87036 doc optional 
libgupnp-doc_0.19.1-1_all.deb
 743aebac12bdd6713d2bdf2b0a5d832e 76844 libs optional 
libgupnp-1.0-4_0.19.1-1_amd64.deb
 7de54c6790cb9d293c8419f75ef99c0b 20640 introspection optional 
gir1.2-gupnp-1.0_0.19.1-1_amd64.deb
 c6b1bf951b9648a8002d53fad5443ff9 137560 libdevel optional 
libgupnp-1.0-dev_0.19.1-1_amd64.deb
 618da877dd1904de98e42ef6bf8d26e8 225980 debug extra 
libgupnp-1.0-dbg_0.19.1-1_amd64.deb

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

iEYEARECAAYFAlCJK4kACgkQcgQ2cL3l8e59DQCfdIhWWLleDER3t0hG/417hJhc
ZusAoKVJkJOzAt6uLIK+ATmToXne+olA
=ZdfP
-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/e1trmny-0007hz...@franck.debian.org

Accepted gst-libav1.0 1.0.2-1 (source amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 14:31:28 +0200
Source: gst-libav1.0
Binary: gstreamer1.0-libav gstreamer1.0-libav-dbg
Architecture: source amd64
Version: 1.0.2-1
Distribution: unstable
Urgency: low
Maintainer: Maintainers of GStreamer packages 
pkg-gstreamer-maintain...@lists.alioth.debian.org
Changed-By: Sebastian Dröge sl...@debian.org
Description: 
 gstreamer1.0-libav - FFmpeg plugin for GStreamer
 gstreamer1.0-libav-dbg - FFmpeg plugin for GStreamer (debug symbols)
Changes: 
 gst-libav1.0 (1.0.2-1) unstable; urgency=low
 .
   * New upstream bugfix release.
Checksums-Sha1: 
 2a593aba1cb1be5bbbf1cd7908838dd566150d3b 1746 gst-libav1.0_1.0.2-1.dsc
 7306127f33b0a8681dd49b2b219306f631474617 4234220 gst-libav1.0_1.0.2.orig.tar.xz
 5a12e1b36b821c5eae355389f65977f70ef77968 11005 
gst-libav1.0_1.0.2-1.debian.tar.gz
 f9f0c17186c7b7dd29e22dd239ed93cdd8ad3f88 160934 
gstreamer1.0-libav_1.0.2-1_amd64.deb
 505221864210aacb74be0c79d42f90a555110234 439638 
gstreamer1.0-libav-dbg_1.0.2-1_amd64.deb
Checksums-Sha256: 
 f9f5c7431198fbe02dc1d36f3522f5a638498de24175cab36b7e4064f0db4e09 1746 
gst-libav1.0_1.0.2-1.dsc
 143099eb7b099d52f764b7ce74ad6de2c4261aadd74dd2a315011a568b18a1e9 4234220 
gst-libav1.0_1.0.2.orig.tar.xz
 a54b9b3cf81aa9dd4d8b2b00b921c5ec9f629ce223675b9e66be4f8314bb5d0c 11005 
gst-libav1.0_1.0.2-1.debian.tar.gz
 3b47a19e7f66d57585e8b2211e0d58904c34a2c674edb7da76698e7278a5bf38 160934 
gstreamer1.0-libav_1.0.2-1_amd64.deb
 4de9fa225baedab90bc0d7c28a3e61b3416c8a7c21b618c05c30bee782d93d08 439638 
gstreamer1.0-libav-dbg_1.0.2-1_amd64.deb
Files: 
 9362e2d884f42a763c21ae219b0c276b 1746 libs optional gst-libav1.0_1.0.2-1.dsc
 b932d386711a1b14d08c3b7d3021934b 4234220 libs optional 
gst-libav1.0_1.0.2.orig.tar.xz
 932735ddf8750a38dee424067069 11005 libs optional 
gst-libav1.0_1.0.2-1.debian.tar.gz
 a56eba33c8f8de914a0f8343dc2c360e 160934 libs optional 
gstreamer1.0-libav_1.0.2-1_amd64.deb
 b53cb77d5b25407525757968539b6964 439638 debug extra 
gstreamer1.0-libav-dbg_1.0.2-1_amd64.deb

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

iEYEARECAAYFAlCJMssACgkQBsBdh1vkHyHp9gCeLIq9cKS0nVNLDJUoAOQjxcv0
DzQAn1n2BVpln90A2si+9KKoUMLJkAGG
=A1LU
-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/e1trmqv-00054r...@franck.debian.org

Accepted gst-plugins-bad1.0 1.0.2-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 14:13:33 +0200
Source: gst-plugins-bad1.0
Binary: gstreamer1.0-plugins-bad-doc gstreamer1.0-plugins-bad 
gstreamer1.0-plugins-bad-dbg libgstreamer-plugins-bad1.0-0 
libgstreamer-plugins-bad1.0-dev
Architecture: source all amd64
Version: 1.0.2-1
Distribution: unstable
Urgency: low
Maintainer: Maintainers of GStreamer packages 
pkg-gstreamer-maintain...@lists.alioth.debian.org
Changed-By: Sebastian Dröge sl...@debian.org
Description: 
 gstreamer1.0-plugins-bad - GStreamer plugins from the bad set
 gstreamer1.0-plugins-bad-dbg - GStreamer plugins from the bad set (debug 
symbols)
 gstreamer1.0-plugins-bad-doc - GStreamer documentation for plugins from the 
bad set
 libgstreamer-plugins-bad1.0-0 - GStreamer development files for libraries from 
the bad set
 libgstreamer-plugins-bad1.0-dev - GStreamer development files for libraries 
from the bad set
Changes: 
 gst-plugins-bad1.0 (1.0.2-1) unstable; urgency=low
 .
   * New upstream bugfix release:
 + debian/gstreamer-plugins-bad.install:
   - Add subenc and fieldanalysis plugins.
Checksums-Sha1: 
 e8d758b023aec91e289db657a2e8a494639d3a26 3269 gst-plugins-bad1.0_1.0.2-1.dsc
 c144fd00833b9945287204d614cfccb06ca9625e 3139260 
gst-plugins-bad1.0_1.0.2.orig.tar.xz
 d5642f882900d25ce98de33a8908ef97fd33d420 34572 
gst-plugins-bad1.0_1.0.2-1.debian.tar.gz
 1c522b8608ddbbc1aa2cbe9db024e1de090fb0c7 867756 
gstreamer1.0-plugins-bad-doc_1.0.2-1_all.deb
 78be349ec8e3a870f6af09f56bbddb7a3cfd71dd 1449160 
gstreamer1.0-plugins-bad_1.0.2-1_amd64.deb
 4b3f82bd8e874fe432f6f4b0c2076b95edb7f4d0 4117054 
gstreamer1.0-plugins-bad-dbg_1.0.2-1_amd64.deb
 e0656a9c95234f9f8bcc62365becb534864db398 831698 
libgstreamer-plugins-bad1.0-0_1.0.2-1_amd64.deb
 9319e6a86981917bc6048753da7438d90df90ba2 771988 
libgstreamer-plugins-bad1.0-dev_1.0.2-1_amd64.deb
Checksums-Sha256: 
 a805fbd795334b1fa402a17d2da09235ff71a21bcd354d197e6f249ec16f0581 3269 
gst-plugins-bad1.0_1.0.2-1.dsc
 9e503305799a2b6eb9d0b77c59b8aa8bbe9e6eb815a0635bd013560c73996579 3139260 
gst-plugins-bad1.0_1.0.2.orig.tar.xz
 03b260f2f9962c25052045e0a559b19a908a02b58cab756f82c8b9442b5e19d1 34572 
gst-plugins-bad1.0_1.0.2-1.debian.tar.gz
 1387021a04c4c08927784e41c6bcf278c9d71422ffbe4a9340220df46c2d3d6c 867756 
gstreamer1.0-plugins-bad-doc_1.0.2-1_all.deb
 39c83bb3d4a3ea7c5f4b6aa34fa8616341bf4a82d834c1cdd45656a13b5b9deb 1449160 
gstreamer1.0-plugins-bad_1.0.2-1_amd64.deb
 4a1a51bef8a38b65f6fcbca3d924f5333bce190154185dda0142b59340db553e 4117054 
gstreamer1.0-plugins-bad-dbg_1.0.2-1_amd64.deb
 cb455b03c056125944fc55327c6d891d282554f5dfd0a085016b2e4fd4f5 831698 
libgstreamer-plugins-bad1.0-0_1.0.2-1_amd64.deb
 ecce2f0f1bd55ef8e96d110d879ee5d3aecb7b58d3ffb47fb99d017383535d77 771988 
libgstreamer-plugins-bad1.0-dev_1.0.2-1_amd64.deb
Files: 
 e6a8f57211153dc8e3ae1770cab13199 3269 libs extra gst-plugins-bad1.0_1.0.2-1.dsc
 17f2ba1b51347061f8f81436d6c7b65e 3139260 libs extra 
gst-plugins-bad1.0_1.0.2.orig.tar.xz
 38dd0290f4122a49d87ad18382bb2523 34572 libs extra 
gst-plugins-bad1.0_1.0.2-1.debian.tar.gz
 7a5b33bea9ed7f0e18b6ca614e1309b1 867756 doc extra 
gstreamer1.0-plugins-bad-doc_1.0.2-1_all.deb
 87eafc57bb641b67a6830d002b2feb64 1449160 libs extra 
gstreamer1.0-plugins-bad_1.0.2-1_amd64.deb
 bf400e16344e9e9a96e0b23d3033712b 4117054 debug extra 
gstreamer1.0-plugins-bad-dbg_1.0.2-1_amd64.deb
 8b6a712cb14d0afda87e68562f7472de 831698 libs extra 
libgstreamer-plugins-bad1.0-0_1.0.2-1_amd64.deb
 24f1afdc2846502c8f7e834ec68765d6 771988 libdevel extra 
libgstreamer-plugins-bad1.0-dev_1.0.2-1_amd64.deb

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

iEYEARECAAYFAlCJMssACgkQBsBdh1vkHyGUmwCghU51H7zxOMcdtlBKdUpg8Ogf
gt8AoKk4o7xWkTen0eHm5/vp8AsZDQtl
=k5rc
-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/e1trmqk-0005x0...@franck.debian.org

Accepted gst-plugins-base1.0 1.0.2-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 13:30:04 +0200
Source: gst-plugins-base1.0
Binary: gstreamer1.0-plugins-base-apps gstreamer1.0-plugins-base-doc 
libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev 
gstreamer1.0-alsa gstreamer1.0-plugins-base gstreamer1.0-plugins-base-dbg 
gstreamer1.0-x gir1.2-gst-plugins-base-1.0
Architecture: source all amd64
Version: 1.0.2-1
Distribution: unstable
Urgency: low
Maintainer: Maintainers of GStreamer packages 
pkg-gstreamer-maintain...@lists.alioth.debian.org
Changed-By: Sebastian Dröge sl...@debian.org
Description: 
 gir1.2-gst-plugins-base-1.0 - Description: GObject introspection data for the 
GStreamer Plugins
 gstreamer1.0-alsa - GStreamer plugin for ALSA
 gstreamer1.0-plugins-base - GStreamer plugins from the base set
 gstreamer1.0-plugins-base-apps - GStreamer helper programs from the base set
 gstreamer1.0-plugins-base-dbg - GStreamer plugins from the base set
 gstreamer1.0-plugins-base-doc - GStreamer documentation for plugins from the 
base set
 gstreamer1.0-x - GStreamer plugins for X11 and Pango
 libgstreamer-plugins-base1.0-0 - GStreamer libraries from the base set
 libgstreamer-plugins-base1.0-dev - GStreamer development files for libraries 
from the base set
Changes: 
 gst-plugins-base1.0 (1.0.2-1) unstable; urgency=low
 .
   * New upstreal bugfix release.
Checksums-Sha1: 
 e7547e9943f33488c5f76de802167a57d2d12fa8 2845 gst-plugins-base1.0_1.0.2-1.dsc
 a4539c78820ad764b666385ae312f7a2e5eb60d6 2341760 
gst-plugins-base1.0_1.0.2.orig.tar.xz
 36fedf7f0fecbda248a14dd26ab63f3b37c6bd08 45554 
gst-plugins-base1.0_1.0.2-1.debian.tar.gz
 f1d78e5770e3db17fc0324033c1cbdeaf8363efa 949432 
gstreamer1.0-plugins-base-doc_1.0.2-1_all.deb
 0fcf618a635a97378c0420070be2154bad39a5bb 670212 
gstreamer1.0-plugins-base-apps_1.0.2-1_amd64.deb
 c75a5ec5670ca0a1fec99b160b945ae0feb9156d 1125162 
libgstreamer-plugins-base1.0-0_1.0.2-1_amd64.deb
 81164607d4d03ef291d38109a83cf9490efb39e3 834092 
libgstreamer-plugins-base1.0-dev_1.0.2-1_amd64.deb
 15308591778da0d2421579d24b5f2d2b16a1f0b8 685132 
gstreamer1.0-alsa_1.0.2-1_amd64.deb
 bb545320e341b5cbb8cdb05df004b64d0a59d5b2 1137542 
gstreamer1.0-plugins-base_1.0.2-1_amd64.deb
 1370935230be510ce6e10ad6bb2251948d1e1cbf 3983548 
gstreamer1.0-plugins-base-dbg_1.0.2-1_amd64.deb
 ccae7f94e088fa56b0aa1de146c874b540bbd93f 719404 
gstreamer1.0-x_1.0.2-1_amd64.deb
 a8def417bba0563c773574223bdd32bb17f88b93 708808 
gir1.2-gst-plugins-base-1.0_1.0.2-1_amd64.deb
Checksums-Sha256: 
 0a488ced93f8d09d96b52d427694d1b41f07f14793f9b37e36d44c9f67c47ef2 2845 
gst-plugins-base1.0_1.0.2-1.dsc
 7ce2c4462ff89f62a82b4503a3788ce2e5077f886e535796fecc223397acf78d 2341760 
gst-plugins-base1.0_1.0.2.orig.tar.xz
 55c73981d14a35d0ef638740df857fd071d5fb661b398e64e2de4ad8ba47f243 45554 
gst-plugins-base1.0_1.0.2-1.debian.tar.gz
 4a9f8436f72368187afc5f32375446a40413eba706869664a84b1e7623da9f80 949432 
gstreamer1.0-plugins-base-doc_1.0.2-1_all.deb
 61362e0854386806ab5e95adc5ca3dc4ccd68fb1794f8a59193d11edec36968a 670212 
gstreamer1.0-plugins-base-apps_1.0.2-1_amd64.deb
 155be5cd283cd29814fbc7e1eaf7fb3460bc0aa79c51b5bdad2b17bf9cef5f81 1125162 
libgstreamer-plugins-base1.0-0_1.0.2-1_amd64.deb
 f6fcf047fbe7b31a5348e129f5120db5f825b579f8d97d2835b226d2460e7803 834092 
libgstreamer-plugins-base1.0-dev_1.0.2-1_amd64.deb
 626423696d3e271bd4c5aa90549bea4520528e3b2db8a60ac94ce37a027b965e 685132 
gstreamer1.0-alsa_1.0.2-1_amd64.deb
 fa89e848702df77b6230877c39b69b8220a1bd8e787563509fd5f45e8b83 1137542 
gstreamer1.0-plugins-base_1.0.2-1_amd64.deb
 1f8e2f05044d0dbba80013bbf4b93f5d51e4f41ad8ce955ae022fc0fa7cdb80d 3983548 
gstreamer1.0-plugins-base-dbg_1.0.2-1_amd64.deb
 cf5d65faa076cfab9f80bbe1c65f5d221bce8a1e7c9c6e306a25ff0161188f17 719404 
gstreamer1.0-x_1.0.2-1_amd64.deb
 df326ec1fc5d8479a12cc0d73005ddbf5329963f2431b31bc23d29811a9376cb 708808 
gir1.2-gst-plugins-base-1.0_1.0.2-1_amd64.deb
Files: 
 15022f9ffd7c7b3605d39831869dd214 2845 libs optional 
gst-plugins-base1.0_1.0.2-1.dsc
 57cff96bfbb5e6f06c4226b141e1f990 2341760 libs optional 
gst-plugins-base1.0_1.0.2.orig.tar.xz
 88e3763292fc0c918ac45f9368ed4ed5 45554 libs optional 
gst-plugins-base1.0_1.0.2-1.debian.tar.gz
 81889356dbb33d9879e012c70f16fb55 949432 doc optional 
gstreamer1.0-plugins-base-doc_1.0.2-1_all.deb
 6115ec28d19b3bb1e187a99ed19a2801 670212 utils optional 
gstreamer1.0-plugins-base-apps_1.0.2-1_amd64.deb
 c7f870fb98c28ece1ac70e320bd284a3 1125162 libs optional 
libgstreamer-plugins-base1.0-0_1.0.2-1_amd64.deb
 8739a2dfabc4e73e16260af1a93595e8 834092 libdevel optional 
libgstreamer-plugins-base1.0-dev_1.0.2-1_amd64.deb
 8dc1b8439f122db3c2522bfebc61a062 685132 libs optional 
gstreamer1.0-alsa_1.0.2-1_amd64.deb
 5412c05af3071aeae4ddd8133b47c369 1137542 libs optional 
gstreamer1.0-plugins-base_1.0.2-1_amd64.deb
 88d882fce2d83f36dfec6adc0a54d9c6 3983548 debug extra 
gstreamer1.0-plugins-base-dbg_1.0.2-1_amd64.deb
 6231a24704fa819d4092f1e35770f2fa 719404 libs

Accepted gst-plugins-good1.0 1.0.2-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 13:33:47 +0200
Source: gst-plugins-good1.0
Binary: gstreamer1.0-plugins-good-doc gstreamer1.0-pulseaudio 
gstreamer1.0-plugins-good gstreamer1.0-plugins-good-dbg
Architecture: source all amd64
Version: 1.0.2-1
Distribution: unstable
Urgency: low
Maintainer: Maintainers of GStreamer packages 
pkg-gstreamer-maintain...@lists.alioth.debian.org
Changed-By: Sebastian Dröge sl...@debian.org
Description: 
 gstreamer1.0-plugins-good - GStreamer plugins from the good set
 gstreamer1.0-plugins-good-dbg - GStreamer plugins from the good set
 gstreamer1.0-plugins-good-doc - GStreamer documentation for plugins from the 
good set
 gstreamer1.0-pulseaudio - GStreamer plugin for PulseAudio
Changes: 
 gst-plugins-good1.0 (1.0.2-1) unstable; urgency=low
 .
   * New upstream bugfix release.
Checksums-Sha1: 
 1c51add0e7bc90cea69186eb7edf7a4a4855d664 2532 gst-plugins-good1.0_1.0.2-1.dsc
 d4bc3ef109948d25ff8f7aa2159b4f46deadcd1a 2713852 
gst-plugins-good1.0_1.0.2.orig.tar.xz
 48be20f8794e70812d24952d422c7103cd2d4934 40521 
gst-plugins-good1.0_1.0.2-1.debian.tar.gz
 1338ad9a9cc07a1ed8738ec92ef89464db217f89 914050 
gstreamer1.0-plugins-good-doc_1.0.2-1_all.deb
 72b4c2865edb06d41e977d5cf6077d0c9160940f 784592 
gstreamer1.0-pulseaudio_1.0.2-1_amd64.deb
 47e6636701f81cb18b092e3c542dda5506073184 1969872 
gstreamer1.0-plugins-good_1.0.2-1_amd64.deb
 e8759280aabbd27650e7faa5df27bfe437817d3d 5863614 
gstreamer1.0-plugins-good-dbg_1.0.2-1_amd64.deb
Checksums-Sha256: 
 da734043842ab9808356873d487da7d753f0114cda848121982db54ce3822de8 2532 
gst-plugins-good1.0_1.0.2-1.dsc
 34762dbd1462dd31b6ca2a01cf6477843c9dc7112e5819cc9d6dd7396b79244c 2713852 
gst-plugins-good1.0_1.0.2.orig.tar.xz
 cdeb701b7465c75e4f07d12f95561e234ed1622bb285f5bd45fcddabe43a79f7 40521 
gst-plugins-good1.0_1.0.2-1.debian.tar.gz
 27028a831d5addd07f775f5dc6c3268e9356ff6e0eb2e2a27a98fa983ae53573 914050 
gstreamer1.0-plugins-good-doc_1.0.2-1_all.deb
 e5374d92ae61b4bd9691156f02961165fe8f477d0988785fbd4d9b94862a070b 784592 
gstreamer1.0-pulseaudio_1.0.2-1_amd64.deb
 b4d454167e834da5b90db2d96515971c8eb95da0bccc9a0422a6f3901ac06892 1969872 
gstreamer1.0-plugins-good_1.0.2-1_amd64.deb
 7bcff4246aa904a0206c5f741cb3d0b0b4eeab808480309698169f728847c9e4 5863614 
gstreamer1.0-plugins-good-dbg_1.0.2-1_amd64.deb
Files: 
 faaec15b550e725775257371ac0153ac 2532 libs optional 
gst-plugins-good1.0_1.0.2-1.dsc
 13e487127d80fe20c868b3bbb2a17d9e 2713852 libs optional 
gst-plugins-good1.0_1.0.2.orig.tar.xz
 399b931ba636f45d50cb5e378a506491 40521 libs optional 
gst-plugins-good1.0_1.0.2-1.debian.tar.gz
 27db2be28f7621bc7edc84abd5ec5d1b 914050 doc optional 
gstreamer1.0-plugins-good-doc_1.0.2-1_all.deb
 a49c63c64dabf496cb1a4cd7361f343d 784592 sound optional 
gstreamer1.0-pulseaudio_1.0.2-1_amd64.deb
 4e8c81d6d7481cb371abcaa6190e7bbc 1969872 libs optional 
gstreamer1.0-plugins-good_1.0.2-1_amd64.deb
 89688dc5116b09240feec9a54eb8d4cd 5863614 debug extra 
gstreamer1.0-plugins-good-dbg_1.0.2-1_amd64.deb

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

iEUEARECAAYFAlCJMssACgkQBsBdh1vkHyGv4gCYqlMWhz4U9ukxBKJLYdMSX4rb
sQCgqRH7nIE2cxyCZr4gD5L97UpkJSU=
=lEfH
-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/e1trn5h-00029c...@franck.debian.org

Accepted gst-plugins-ugly1.0 1.0.2-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 14:01:36 +0200
Source: gst-plugins-ugly1.0
Binary: gstreamer1.0-plugins-ugly-doc gstreamer1.0-plugins-ugly 
gstreamer1.0-plugins-ugly-dbg
Architecture: source all amd64
Version: 1.0.2-1
Distribution: unstable
Urgency: low
Maintainer: Maintainers of GStreamer packages 
pkg-gstreamer-maintain...@lists.alioth.debian.org
Changed-By: Sebastian Dröge sl...@debian.org
Description: 
 gstreamer1.0-plugins-ugly - GStreamer plugins from the ugly set
 gstreamer1.0-plugins-ugly-dbg - GStreamer plugins from the ugly set (debug 
symbols)
 gstreamer1.0-plugins-ugly-doc - GStreamer documentation for plugins from the 
ugly set
Changes: 
 gst-plugins-ugly1.0 (1.0.2-1) unstable; urgency=low
 .
   * New upstream bugfix release.
Checksums-Sha1: 
 6721c87953b680b885455628fe5bb295ebee8bdf 2325 gst-plugins-ugly1.0_1.0.2-1.dsc
 89a6892b437e817b776b269ed7edb89208803ea3 822488 
gst-plugins-ugly1.0_1.0.2.orig.tar.xz
 e6c413dc60c276817c0b796afb67a748084408a3 27397 
gst-plugins-ugly1.0_1.0.2-1.debian.tar.gz
 b021a1a8bfe7db25a6395d5a07cecdf13ee87602 179512 
gstreamer1.0-plugins-ugly-doc_1.0.2-1_all.deb
 e3c565c1ff1ef6f1d4be7101a7fa950b989ebb84 346286 
gstreamer1.0-plugins-ugly_1.0.2-1_amd64.deb
 05807f999c7ecd695d0f9616aa575dbb36d3dce0 835884 
gstreamer1.0-plugins-ugly-dbg_1.0.2-1_amd64.deb
Checksums-Sha256: 
 740c49dc6a656cf86ba18059bf07ca8f4cdcb3290691d5f1daae73f4f0be1848 2325 
gst-plugins-ugly1.0_1.0.2-1.dsc
 6f74dfbe9a18220a6a5961043676ff639bab7ea376335ea5aa9c95934c535c6d 822488 
gst-plugins-ugly1.0_1.0.2.orig.tar.xz
 50207e322e117ed1da1d0dfd96526fb72234f418f28846453541b09c433cc617 27397 
gst-plugins-ugly1.0_1.0.2-1.debian.tar.gz
 36b40093568a3b7b27f6313c83aea6b540ac60bdd5168d9ae932f63acbb1f877 179512 
gstreamer1.0-plugins-ugly-doc_1.0.2-1_all.deb
 2b1734780749d297812781b53f3e79cb2e56ceadca81a22971dac760fa86914e 346286 
gstreamer1.0-plugins-ugly_1.0.2-1_amd64.deb
 38266475228daa1c7514d1c95533211f9d5bb83f90b9dd5150ab89c1f0522527 835884 
gstreamer1.0-plugins-ugly-dbg_1.0.2-1_amd64.deb
Files: 
 545c2847bdd189f07125500187ba33a2 2325 libs optional 
gst-plugins-ugly1.0_1.0.2-1.dsc
 c72d307b37742d2ba1efd4d04884f56b 822488 libs optional 
gst-plugins-ugly1.0_1.0.2.orig.tar.xz
 91d804661443c30260f4952bd3ce9ebc 27397 libs optional 
gst-plugins-ugly1.0_1.0.2-1.debian.tar.gz
 6d5cbe0acb5bb8eef97ddae3cec6d354 179512 doc optional 
gstreamer1.0-plugins-ugly-doc_1.0.2-1_all.deb
 6b1d532cd908701a1ff36896101c13bf 346286 libs optional 
gstreamer1.0-plugins-ugly_1.0.2-1_amd64.deb
 428f66525c15dee527bff56d5b267488 835884 debug extra 
gstreamer1.0-plugins-ugly-dbg_1.0.2-1_amd64.deb

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

iEYEARECAAYFAlCJMssACgkQBsBdh1vkHyEzRwCfdYtPc8kusQyCS8QgIoGM1k6X
VMQAn354VNhtXUhxfW7BBoMf+BAck4Rl
=dkHL
-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/e1trn5p-0002kj...@franck.debian.org

Accepted gstreamer1.0 1.0.2-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 13:23:04 +0200
Source: gstreamer1.0
Binary: libgstreamer1.0-0 libgstreamer1.0-0-dbg libgstreamer1.0-dev 
gstreamer1.0-doc gstreamer1.0-tools gir1.2-gstreamer-1.0
Architecture: source all amd64
Version: 1.0.2-1
Distribution: unstable
Urgency: low
Maintainer: Maintainers of GStreamer packages 
pkg-gstreamer-maintain...@lists.alioth.debian.org
Changed-By: Sebastian Dröge sl...@debian.org
Description: 
 gir1.2-gstreamer-1.0 - Description: GObject introspection data for the 
GStreamer library
 gstreamer1.0-doc - GStreamer core documentation and manuals
 gstreamer1.0-tools - Tools for use with GStreamer
 libgstreamer1.0-0 - Core GStreamer libraries and elements
 libgstreamer1.0-0-dbg - Core GStreamer libraries and elements
 libgstreamer1.0-dev - GStreamer core development files
Changes: 
 gstreamer1.0 (1.0.2-1) unstable; urgency=low
 .
   * New upstream stable release.
Checksums-Sha1: 
 73876b2ba998c81f2bfd7bc54364458e6f71c505 2290 gstreamer1.0_1.0.2-1.dsc
 9bf31a7dfa388ba17a388edf688621ebc3a35d6d 3118740 gstreamer1.0_1.0.2.orig.tar.xz
 a5536e55893c30df2b4301218d9b44f27fbd9b92 46073 
gstreamer1.0_1.0.2-1.debian.tar.gz
 1e0dabd6a4db3c6f7087a1e702673930d6a8d031 4909772 
gstreamer1.0-doc_1.0.2-1_all.deb
 36568b34c9deb136c893119c7bddec4be0d35fee 1808480 
libgstreamer1.0-0_1.0.2-1_amd64.deb
 526f6e828d111804d773ecda66baa198fdd7b5a3 2717254 
libgstreamer1.0-0-dbg_1.0.2-1_amd64.deb
 6c4bcbadb24f22561602542c243fe5963ce33f75 1128504 
libgstreamer1.0-dev_1.0.2-1_amd64.deb
 2164020517f108f87261ba8a509a750fc7b3db21 772626 
gstreamer1.0-tools_1.0.2-1_amd64.deb
 3410ff1894a316ccabd13880df539ce338483658 802864 
gir1.2-gstreamer-1.0_1.0.2-1_amd64.deb
Checksums-Sha256: 
 970243dd9f197aaecdf641fb1abe24c2dff303e64146b297e82a20e36fc694cf 2290 
gstreamer1.0_1.0.2-1.dsc
 10c59112bb01a274eb33950300da13d25fd23a7494781bf1b2328372fdb6ee06 3118740 
gstreamer1.0_1.0.2.orig.tar.xz
 b6c0c32922d7d3729ebbe9eb2560b5b5c14b62426433f18769cf0f1e8e8a876b 46073 
gstreamer1.0_1.0.2-1.debian.tar.gz
 95ae80f36f3963b6e90d98268c957a93790987c2e299de05b9451002688dc0f8 4909772 
gstreamer1.0-doc_1.0.2-1_all.deb
 22ccf162e25fcd5db2957acce557fe5ecbeeb94ed7a71eccf08acda0a423c810 1808480 
libgstreamer1.0-0_1.0.2-1_amd64.deb
 7e2b8552c037cb7f6b16b21be5501a72a441f9783f67e72535fa781df58f7c9d 2717254 
libgstreamer1.0-0-dbg_1.0.2-1_amd64.deb
 ab54f900a9f2f3a4fbd7becb930dfcef35f9c4b9919d682014fa8fceeb4f7863 1128504 
libgstreamer1.0-dev_1.0.2-1_amd64.deb
 0d5130bc509f480b9791de3cb0f03ec6061a767a74eb30f8ce008b48c7cd2df2 772626 
gstreamer1.0-tools_1.0.2-1_amd64.deb
 64da17937fc5148fc3a3f358e688927adab2fecb15b7944555a2a3b7c681316f 802864 
gir1.2-gstreamer-1.0_1.0.2-1_amd64.deb
Files: 
 309b369674f909b49dde46eb91216436 2290 libs optional gstreamer1.0_1.0.2-1.dsc
 1faa5a86feddf87af57e72f42d060b3d 3118740 libs optional 
gstreamer1.0_1.0.2.orig.tar.xz
 e6b2abf29ca4e6af253932ccc6307194 46073 libs optional 
gstreamer1.0_1.0.2-1.debian.tar.gz
 fe20bbb02fb843dd4c1ea7bb63fd2180 4909772 doc optional 
gstreamer1.0-doc_1.0.2-1_all.deb
 c8bb968eecbf1082616e257b137b9bb5 1808480 libs optional 
libgstreamer1.0-0_1.0.2-1_amd64.deb
 b56f4c9a3503668f89d32dfd5374c603 2717254 debug extra 
libgstreamer1.0-0-dbg_1.0.2-1_amd64.deb
 d33486cc66b68b5019faf73e42cb0efa 1128504 libdevel optional 
libgstreamer1.0-dev_1.0.2-1_amd64.deb
 141b51ae0cca649e1a55651875564259 772626 utils optional 
gstreamer1.0-tools_1.0.2-1_amd64.deb
 22c5bae1c8f7a1413e7ffd911999e7a1 802864 introspection optional 
gir1.2-gstreamer-1.0_1.0.2-1_amd64.deb

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

iEYEARECAAYFAlCJMssACgkQBsBdh1vkHyHdegCgpUzBZXO4Y3/aZu1ZsGt8sEn4
668AnjbZu1/AeO/pdJ0j04ILJ72sFmfx
=QoQc
-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/e1trn5c-0002ab...@franck.debian.org

Accepted stardict-english-czech 20121001-1 (source all)

2012-10-25 Thread Michal Čihař

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 13:14:09 +0200
Source: stardict-english-czech
Binary: stardict-english-czech
Architecture: source all
Version: 20121001-1
Distribution: unstable
Urgency: low
Maintainer: Michal Čihař ni...@debian.org
Changed-By: Michal Čihař ni...@debian.org
Description: 
 stardict-english-czech - Stardict package for English-Czech dictionary
Changes: 
 stardict-english-czech (20121001-1) unstable; urgency=low
 .
   * New upstream release.
Checksums-Sha1: 
 8f109babba23ab87584c1860dcb74478fc050838 2046 
stardict-english-czech_20121001-1.dsc
 6819a1c17dfcdf1372e283370f767b5b854d842b 4298054 
stardict-english-czech_20121001.orig.tar.gz
 7c0ce6116c04dd7ce51c44498ef3337bc338c7d1 9568 
stardict-english-czech_20121001-1.debian.tar.gz
 67dc5e46dcd980676f768a92aae80973f04fbb28 4296052 
stardict-english-czech_20121001-1_all.deb
Checksums-Sha256: 
 e00f2ceecc4ce655e84b238452aab9a9380e16f02edd0feb4274a7e34fc70cf3 2046 
stardict-english-czech_20121001-1.dsc
 d178685729230c777b822a0f3e05991be4b859b7e915ac946e5c3156507d1894 4298054 
stardict-english-czech_20121001.orig.tar.gz
 ce9c9097f4d64bc8b05260c4f4e18c01fb8cdc3e4383d957dfdfb0c91fdd8290 9568 
stardict-english-czech_20121001-1.debian.tar.gz
 b20b179f15d1b512f1feb1466c285ae6886b34c64e5dce7ccee3b1f84dde7b50 4296052 
stardict-english-czech_20121001-1_all.deb
Files: 
 f92396425335de0256b7973f3c72e16c 2046 non-free/text optional 
stardict-english-czech_20121001-1.dsc
 cc43e6e4cf3248f045b610a47b7eb4a8 4298054 non-free/text optional 
stardict-english-czech_20121001.orig.tar.gz
 fb36b21e7d48663ebc69584b6769e684 9568 non-free/text optional 
stardict-english-czech_20121001-1.debian.tar.gz
 c227dda31bdd877a0a4a666fbc1fc4c5 4296052 non-free/text optional 
stardict-english-czech_20121001-1_all.deb

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

iQIcBAEBCAAGBQJQiR9nAAoJEGo39bHX+xdNgaEP/0z4qaiFY2yugHBwjLfgUgRO
oM3KL3IxaKL5C2TYimh3z+niK2VoaJT2Q37/M7iqIBjcgTQTRfzvOj3maSaqXn6O
ZTIdI9rbs2lXGpKYVZXZHCK86UpTGl+zBD+US16+3sz7g0G0LUq8r5YnUnRA6fX5
IhI1SJrAtwu0QJq7Av9wv1PZWnctG4/OJgJZFOs9dUIIsoEoTClfIWxl8gPW4Okk
Rxr9zRdHxqlp61V/q5khNDjvNoRTgcabRIZtwxE/ycSPJJv+ADX5Vk6RUMFRwdH5
BLzEEdok2qmAUEepCX3DJGU/fi/2FzvUkFpxB+0wwH7MPJj2CkvwHRkqOLodyA6k
li2k8VLe8rg12/McSsPEdz0zCTRZexZeUGqFjxfEoDXKedfyQKASLqzwwbm/1IVp
/gVqJx9Um7EY/g0ZlMc3DOnixlTfKQPnRFkRo26lXR4E6L4wF8Q/CohtLVqlWgrM
P3AhFHpgJSRAuTDiuI5kJdKsn8eoS5kj9H2XOqtlRTSnpLNyEtWC95+6MqSdj/xV
h6FrYngVm4HQFaAmV685A/mS0moEXLjVJDTXVhA2Y0RyXXglZ1xlssFNufEBexNB
fCqL5C0up93Hdy0wJryIBsNCdfwNEmXyRWAwZmzRdTNLpE4Aq79MxQdc1vUhgmnA
rQ/9J5KyBPlQbCUnOK0I
=AaGX
-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/e1trnyl-px...@franck.debian.org

Accepted gupnp-av 0.11.1-1 (source all amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 25 Oct 2012 15:27:58 +0200
Source: gupnp-av
Binary: libgupnp-av-1.0-2 gir1.2-gupnp-av-1.0 libgupnp-av-1.0-dev 
libgupnp-av-1.0-dbg libgupnp-av-doc
Architecture: source all amd64
Version: 0.11.1-1
Distribution: experimental
Urgency: low
Maintainer: Ross Burton r...@debian.org
Changed-By: Andreas Henriksson andr...@fatal.se
Description: 
 gir1.2-gupnp-av-1.0 - GObject introspection data for the GUPnP-AV library
 libgupnp-av-1.0-2 - Audio/Visual utility library for GUPnP
 libgupnp-av-1.0-dbg - Audio/Visual utility library for GUPnP (debug symbols)
 libgupnp-av-1.0-dev - Audio/Visual utility library for GUPnP (development 
files)
 libgupnp-av-doc - Audio/Visual utility library for GUPnP (documentation)
Changes: 
 gupnp-av (0.11.1-1) experimental; urgency=low
 .
   * Replace gupnp-vala versions before 0.10.5 to avoid file conflicts
   * Imported Upstream version 0.11.1
   * Revert Add patches from upstream
 - now included in upstream release.
   * Revert Bump gobject-introspection build-dep to (= 1.33.4) ...
 - upstream release lowered the requirements again in 0.11.1
   * Update symbols file for new symbols in 0.11.1
Checksums-Sha1: 
 1cc930c4d3a5f14ebc92160cc3d67eef5927e659 1767 gupnp-av_0.11.1-1.dsc
 32545bf55b6d119cdae4d42b962d10cc5c6f8414 298432 gupnp-av_0.11.1.orig.tar.xz
 21c76a58bb588c9a4af3e320dd0ba82a99200f65 5957 gupnp-av_0.11.1-1.debian.tar.gz
 27b15d251b9780f79251a812665bb992129d701d 56894 libgupnp-av-doc_0.11.1-1_all.deb
 f992f635ef7bd22f72c8d22a486d843bdbc8c520 57430 
libgupnp-av-1.0-2_0.11.1-1_amd64.deb
 ce0f12e32cefc0ae7f0354780c72d5018b496ae8 18268 
gir1.2-gupnp-av-1.0_0.11.1-1_amd64.deb
 8f3748257907c6b22e2de226c8fc700c9e7e00bb 93726 
libgupnp-av-1.0-dev_0.11.1-1_amd64.deb
 5e444a2f992335516668c19682dc8f2683f01362 159934 
libgupnp-av-1.0-dbg_0.11.1-1_amd64.deb
Checksums-Sha256: 
 b9aabc77bb0a9dfcd03e72ac25fce3d18aebb2cf6042b25b1e91cb4182d7cfcb 1767 
gupnp-av_0.11.1-1.dsc
 dbd8a2ca5ee0ead67614afbb698325a08375095af24c3e30e90db9f1d9cf3edf 298432 
gupnp-av_0.11.1.orig.tar.xz
 808759cc381f754ba86fbb29c937066f54806e0ef98946713abf152e3a8c5078 5957 
gupnp-av_0.11.1-1.debian.tar.gz
 ed8eec8fd767cf2b0700c727b829bae0cde280ae5190fed92f03e306d4356e6a 56894 
libgupnp-av-doc_0.11.1-1_all.deb
 07284dd17a9f087bfdad06d9943558b146bd1bc53464a58d6e764a36aa7d89f7 57430 
libgupnp-av-1.0-2_0.11.1-1_amd64.deb
 81575b14351ddb989924258b83be601520732f67ae1cbf1caf1d9f8b6d1a4300 18268 
gir1.2-gupnp-av-1.0_0.11.1-1_amd64.deb
 928fcd260cd25fd38990a9f1cc8d0d5d3355dc0bbe823753380b53f9c35eef56 93726 
libgupnp-av-1.0-dev_0.11.1-1_amd64.deb
 3995fcc866d39f334b97369686c3f120cc70ead9599d73b57a527a18ca79133b 159934 
libgupnp-av-1.0-dbg_0.11.1-1_amd64.deb
Files: 
 90313253abf801fdf13cb3a37b54fdc2 1767 libs optional gupnp-av_0.11.1-1.dsc
 1fd63be8ef7a5c304b20962f1bc127ac 298432 libs optional 
gupnp-av_0.11.1.orig.tar.xz
 7f58ddf6658373a59b2fdd74aaacd3c1 5957 libs optional 
gupnp-av_0.11.1-1.debian.tar.gz
 cea69790d82691eed1a583562324c3a1 56894 doc optional 
libgupnp-av-doc_0.11.1-1_all.deb
 560d503529830197f0c213c83d14249c 57430 libs optional 
libgupnp-av-1.0-2_0.11.1-1_amd64.deb
 f792277ccb7890d05f433ebf9b62da92 18268 introspection optional 
gir1.2-gupnp-av-1.0_0.11.1-1_amd64.deb
 1552952efa0fc109dcee8580f091bf3f 93726 libdevel optional 
libgupnp-av-1.0-dev_0.11.1-1_amd64.deb
 6c20df0be789524f1ed9f87b874917d9 159934 debug extra 
libgupnp-av-1.0-dbg_0.11.1-1_amd64.deb

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

iEUEARECAAYFAlCJRHIACgkQcgQ2cL3l8e7j2gCeKVixxqZ4P5FHb9EHeDOwfCjx
fXMAliXX4UtTbEdsvLn4dHa2Nlb1YZE=
=HMyM
-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/e1trojm-0004gh...@franck.debian.org

Accepted gupnp-vala 0.10.5-1 (source amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 12 Oct 2012 14:31:28 +0200
Source: gupnp-vala
Binary: gupnp-vala
Architecture: source amd64
Version: 0.10.5-1
Distribution: experimental
Urgency: low
Maintainer: Ross Burton r...@debian.org
Changed-By: Andreas Henriksson andr...@fatal.se
Description: 
 gupnp-vala - GObject-based library for UPnP (Vala bindings)
Changes: 
 gupnp-vala (0.10.5-1) experimental; urgency=low
 .
   * Imported Upstream version 0.10.5
   * Artificially bump gupnp and gupnp-av dependencies.
 This makes sure the vala api for gupnp and gupnp-av are not built.
 (gupnp = 0.19.0 and gupnp-av = 0.11.0 builds vala api themselves.)
Checksums-Sha1: 
 bd0fe204559d1997604507f6438c2d0782d68de8 1432 gupnp-vala_0.10.5-1.dsc
 b944bf02810d456f962f16bc669a80f5ef54b386 91108 gupnp-vala_0.10.5.orig.tar.xz
 e626da45412050b9c899698896e1208d7972e8ad 2681 gupnp-vala_0.10.5-1.debian.tar.gz
 f61b20e94e7ac1f668048007c3c848823a1517b0 6730 gupnp-vala_0.10.5-1_amd64.deb
Checksums-Sha256: 
 bc2fa8ef5c05ad3d37171868efd88bf758a6c6da245e01d32d9ebdc6e683 1432 
gupnp-vala_0.10.5-1.dsc
 dab44184557f925be546c9d475b24a263808a6fd1eb27025b823c5e1f6fe9192 91108 
gupnp-vala_0.10.5.orig.tar.xz
 7aa306acf5864e525c8f062e9465d6139772de06f9a0c9e2e6800478da7f0046 2681 
gupnp-vala_0.10.5-1.debian.tar.gz
 57ab5896d494a011c1c4c3b5cc46f6793b2aff2302f6cc1ce1c36b00f725d73c 6730 
gupnp-vala_0.10.5-1_amd64.deb
Files: 
 38c8509b557b335105a8a864bef01fe9 1432 libs optional gupnp-vala_0.10.5-1.dsc
 ab35180fccaa52dc30859f62f66edac1 91108 libs optional 
gupnp-vala_0.10.5.orig.tar.xz
 a8a40ef8d4bd0d7d1a86db0436914ef5 2681 libs optional 
gupnp-vala_0.10.5-1.debian.tar.gz
 3b70f91683d13dff833ff5cf7234bdd0 6730 libs optional 
gupnp-vala_0.10.5-1_amd64.deb

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

iEYEARECAAYFAlCJSlsACgkQcgQ2cL3l8e5Y+QCgqRA9asmLL94hwfDM+MAHPY51
GnMAn1aJ9ihezCykrtIga/a3ZFyfvTMq
=50OQ
-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/e1trojr-0004iz...@franck.debian.org

Accepted scuttle 0.7.4-8 (source all)

2012-10-25 Thread metal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 22 Oct 2012 02:18:10 -0200
Source: scuttle
Binary: scuttle
Architecture: source all
Version: 0.7.4-8
Distribution: unstable
Urgency: high
Maintainer: Marcelo Jorge Vieira (metal) me...@debian.org
Changed-By: Marcelo Jorge Vieira (metal) me...@debian.org
Description: 
 scuttle- Web-based social bookmarking system
Closes: 688500
Changes: 
 scuttle (0.7.4-8) unstable; urgency=high
 .
   * Fixed configuration file in /var (policy 10.7) (Closes: #688500)
 - Moving config_debconf.inc.php from /var/lib to /etc
Checksums-Sha1: 
 6f63492057d60bce3846883c7486de96b58e64f6 1827 scuttle_0.7.4-8.dsc
 b85aa2e89020ecb1c06aab39406a32dbcc959274 13015 scuttle_0.7.4-8.diff.gz
 7bdd3c0944a3ba9563b391a61189f52d7fa79017 181378 scuttle_0.7.4-8_all.deb
Checksums-Sha256: 
 fae08dee7cab3112455405df3226669a45bb90adeddeb4f67a67f8352b5e89e0 1827 
scuttle_0.7.4-8.dsc
 7198fedc6bbde084b82ebf7c10ec68ea13cf8dda181324ec8d671c769354cd60 13015 
scuttle_0.7.4-8.diff.gz
 5375d7a86dae0ec92907c5059ac010f3e9e6145919093eb5034388d29ae2cf1d 181378 
scuttle_0.7.4-8_all.deb
Files: 
 5b4bd4aec193b341957c0ac5c21db8e8 1827 web optional scuttle_0.7.4-8.dsc
 3d581596e42245eaa88b24dfb4ebc520 13015 web optional scuttle_0.7.4-8.diff.gz
 2f220c85751922fda9b53e6e911acef8 181378 web optional scuttle_0.7.4-8_all.deb

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

iQIcBAEBCAAGBQJQiU4JAAoJEAGffgcyZKXEklsP/Ax0FawY8Ye9xLGHJjOj4VQ1
qk+oBBE1spXG+YWL7uQtQNmwmpWEjaqFqEKyMukSCBXx2ILmvwe9a6eCW8tBjVQN
MltXGgpIrgwlpzFDcFhjzyRUPBoNdfDM0qgwKuz9h+alvf/rQQ3rhQdv+mXZj68R
VzWAGVDocgeSlnd4uNuQcjXyR2Sy/yu0W/LIT/C+EIJI9m72g2ftCzY8LqDvU71g
gWR6QevTB344GvGlhVtVe8rtF9sjKjiPUxL+S5QmxgTQo89VjKdbscXn+Oqxgeim
M+NeTu5YUY15Gfumr7JS/12izqdbsBI5wWbKzZP6sS79SoEEh2Csm26fOwfhiH72
n5ZaC89YhSJpmhLM4teSoTjK/26FI0+RefAFFTQQzjP7MZX1WjYMa5HXYgEn/NWd
x2yr8XABgYGYW3ZkX1wHm9jU5pFy8Vw/s4BwCuEz9WYbAhnXor96f4bvB5JQ7H2k
UigfAxFrirD7UJpxaDMFV9Ie4+6ypCNJE7ZoIYBHH3CROjzoyqQpKKmql8PzZxRJ
ZvvvQsEjF6Sfyos+3Zb20amIWAIxbuzEPICKdlxgCXG9kXgvR9rM7MMdSxhVZwgo
3ZbvOYQM8+Jo9QQ5PRFXZxi5nVSvktBU06tEWMXF79J+Syb2i2G72T3Fl58ES9//
G4VtulVlOXwDi7fJMdFR
=LwfY
-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/e1trokn-0005l5...@franck.debian.org

Accepted startup-notification 0.12-2 (source amd64)

2012-10-25 Thread Simon McVittie

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 13:18:31 +0100
Source: startup-notification
Binary: libstartup-notification0 libstartup-notification0-dev
Architecture: source amd64
Version: 0.12-2
Distribution: experimental
Urgency: low
Maintainer: Josselin Mouette j...@debian.org
Changed-By: Simon McVittie s...@debian.org
Description: 
 libstartup-notification0 - library for program launch feedback (shared library)
 libstartup-notification0-dev - library for program launch feedback 
(development headers)
Changes: 
 startup-notification (0.12-2) experimental; urgency=low
 .
   * Team upload
   * Upgrade to debhelper 9, for compressed debug symbols (when added)
   * Convert to multi-arch (based on Riku Voipio's work in Ubuntu; LP: #910856)
   * Use 3.0 (quilt) format instead of CDBS simple-patchsys
 (there are currently no patches anyway)
Checksums-Sha1: 
 37386515b3f40d664f95277321d228148ee696cd 2276 startup-notification_0.12-2.dsc
 3517bc26e668e54b9d6e5085ea69ae0cb3143d75 5503 
startup-notification_0.12-2.debian.tar.gz
 04b6d07e667bf1b755e8052247ab65eb2a82af2e 22418 
libstartup-notification0_0.12-2_amd64.deb
 e3dde31bfbaf63933e2c4292dde16fa807630f2e 23554 
libstartup-notification0-dev_0.12-2_amd64.deb
Checksums-Sha256: 
 4f2ac90e997b467e03a1ad93c1d93652c98a7b915122afc04ea379b6f1e4251a 2276 
startup-notification_0.12-2.dsc
 d830d2df332838f0a14e58c311dd46dc685354d46539a4d9fdda1e206d211fac 5503 
startup-notification_0.12-2.debian.tar.gz
 70dc7c65281c8b7d0b07febf8d556fff1f86e0116e910b9873e092e8524e1e10 22418 
libstartup-notification0_0.12-2_amd64.deb
 1761657d0073cf761bd574d9cb120cda7de76c1babcb4f5000ae14433cd023e6 23554 
libstartup-notification0-dev_0.12-2_amd64.deb
Files: 
 fd3bcc68839ea854fc528eb90f7c6480 2276 x11 optional 
startup-notification_0.12-2.dsc
 3173ddd6f8c5bb5965807e9348d9282c 5503 x11 optional 
startup-notification_0.12-2.debian.tar.gz
 01ba01e6ad92907c9507f16f1736a0ef 22418 libs optional 
libstartup-notification0_0.12-2_amd64.deb
 f6feb06fa158b13eccf6059603d0dc0a 23554 libdevel optional 
libstartup-notification0-dev_0.12-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQIVAwUBUIlIbU3o/ypjx8yQAQizKg//fgveigJZcaCc3Mvx9b6cmZJM7bCaN3RE
8s4JLNlppOPth7Ytl/vmtrq6MyvwnYBAlHNvoKPgDB7GdgYkvejA/h9IH0aR5KRx
HbWqPlwjkFFl01YOM6Cl8W8758DUalNRH0cuARUMkBnSqCGWyv7QkeMEEihboL0+
NFKd97+UQHURsmWLaCCPNWFzmkBPbVjx6657IV54kL9CeEkHXY0ubyl6kZfYcoLI
rPUgDCIIQAH+eLYfLHTJDfhG04e53q3ze6QC86D8o5WGoamQ0qCHpEhMTgdShbIE
PQqpKXGp1/VT3jUhb0pjcZCw63eNc1RinB8RDFZD0lyhM7F7QMtZdnGeenLWAKN7
7COMdgB1N7fPWvfXcQbBPHWMW8B9z7TAgduQ47CqOCkr/lA09klB6iGpEcySQJaw
i/S15TjEn30l5JGsVq2owGlwIcUZhy/NGmBZwyVjOupZbmcRG87aKVPmjF6hTgat
tIOJYWiAJ294Dzw3z62paKxJBOS56esnAB8+kjB5TkCOZ3Vd0iKqnSvivDHhkEq3
x407jZXFp2BzR576xCVpOMMhAQiWVSsOQ1Ls1DC7OcgASC78V2Z1/zRWsSJerluX
zsDNW6pniIQ9enT5asYYoPaQMS7mVbKmE8TVqVgk+iEfg7zusxppjz2qFrbYOcoy
CmCNUd1vF3I=
=5r2c
-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/e1trokt-0005pq...@franck.debian.org

Accepted fuse-exfat 0.9.8-3 (source amd64)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Oct 2012 17:09:19 +0200
Source: fuse-exfat
Binary: exfat-fuse
Architecture: source amd64
Version: 0.9.8-3
Distribution: experimental
Urgency: low
Maintainer: Sven Hoexter hoex...@debian.org
Changed-By: Sven Hoexter hoex...@debian.org
Description: 
 exfat-fuse - read and write exFAT driver for FUSE
Changes: 
 fuse-exfat (0.9.8-3) experimental; urgency=low
 .
   * Revert the change from 0.9.8-2, the correct fix is
 to assign CFLAGS to CCFLAGS so the correct set of common
 flags will be picked up by scons.
Checksums-Sha1: 
 f94763942679715f2220a4c1834f643d247b894d 1862 fuse-exfat_0.9.8-3.dsc
 9590597e65f5a49b5b0093c8f51cb5bc387f7c64 2305 fuse-exfat_0.9.8-3.diff.gz
 82c48b7dcbe430bf06ef600f8f8b1ba3f6585768 26530 exfat-fuse_0.9.8-3_amd64.deb
Checksums-Sha256: 
 d21de286ceaa51d216133df8f2c7d1080f681622dcac731dec8bc08a9f149e9d 1862 
fuse-exfat_0.9.8-3.dsc
 02550a85db075016679aeba188357832108c5b84290c763aca34a7448473ac89 2305 
fuse-exfat_0.9.8-3.diff.gz
 99d115a5cd6f5e332adb1b0f6dde3ed7913889e0f5c8cff29bc6bd5c28c52cfb 26530 
exfat-fuse_0.9.8-3_amd64.deb
Files: 
 771a69106eb08f32af003eb08bdd3599 1862 otherosfs optional fuse-exfat_0.9.8-3.dsc
 7140d8807fe2adb26c9ba54a2daf99ff 2305 otherosfs optional 
fuse-exfat_0.9.8-3.diff.gz
 ce2e272c3c56a990ec41493ccf1efccc 26530 otherosfs optional 
exfat-fuse_0.9.8-3_amd64.deb

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

iQIcBAEBCAAGBQJQiVk4AAoJEKbcJNnaJJPR6+IQAISo0DT6RqL7RF5HBjxxk3SW
VOw7bYaus4J+itKvGmAy1nFai77J/MJ+byOWB2ogsYqyl0xY64grUAxiSb6aHqDz
kiMawL7dbet++UbqQxveS63uwqJV2tYAMlFMSV4s4uhrpH8z3Wf3F/8eARQ8NLLU
5Ub8AgZq2s7A06wfeMy70YfbEtRiDU+9vft7NOko884pNhTYwzOtTANGGlweDafl
l4Kf4CdoP/3EkPJxd89NIAm74lzP9hRCiSJcydXkNN+b2L+kp8d23LMiTnU9ZTSW
xNDRD4n4ozTn+eAMJ9sSlBmNsYRPjl4JhycJUQCMgWLw1gJ3sccIFkOIKKxNBv+4
rzVpYUg096xUC/lfo32CgD+WjmqcfiQxOj3uDA0yeFV0j7RU2IRu41kKJ2DK8NV5
2nagrb1Yk74en+zrHSqK+vePA+x+t7nOc3RzbElJVY+pVFEZMMcVFShTBjkAk73a
KO6x0mRjK2c+dOW0bFIN+UdCKOA/1trkwGfXAmpI2FjP9eaGNU7o9qDpsJAbcShJ
D43lWjxfZ3URdLQGMrbh224vE3DdEBtoxAQUTaIUWzFzI5QeKvwLnuPieARLEDWv
qpXVv7D1uQ1c/DYmOLFm5nZf9sfciG7jjRcza2rkaXxD/eApKzp15W5X3n6M7iai
by9sQ9Yr6fS3V0tW7xCn
=Cesh
-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/e1trpq7-0007nf...@franck.debian.org

Accepted exfat-utils 0.9.8-3 (source amd64)