Bug#645081: marked as done (ITA: clp -- coin-or linear programming solver)

[Debian Bug Tracking System]

Your message dated Thu, 17 Oct 2013 04:00:11 +
with message-id 
and subject line Bug#645081: fixed in clp 1.15.3-1
has caused the Debian Bug report #645081,
regarding ITA: clp -- coin-or linear programming solver
to be marked as done.

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

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


-- 
645081: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645081
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: normal

Due to scarce resources and lack of interest in maintaining packages I
cannot use due to non-GPL compatible licensing I request an adopter for
the clp package.

The package description is:
 Clp (Coin-or linear programming) is an open-source linear programming solver
 written in C++. It is primarily meant to be used as a callable library, but a
 basic, stand-alone executable version is also available. It is designed to
 find solutions of constrained linear mathematical optimization problems.
 .
 This package contains the header files for developers.


--- End Message ---
--- Begin Message ---
Source: clp
Source-Version: 1.15.3-1

We believe that the bug you reported is fixed in the latest version of
clp, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 645...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Miles Lubin  (supplier of updated clp package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 04 Oct 2013 21:24:10 -0400
Source: clp
Binary: coinor-libclp1 coinor-libclp-dev coinor-libclp-doc coinor-libclp1-dbg
Architecture: source amd64 all
Version: 1.15.3-1
Distribution: experimental
Urgency: low
Maintainer: Debian Science Team 

Changed-By: Miles Lubin 
Description: 
 coinor-libclp-dev - Coin-or linear programming solver (developer files)
 coinor-libclp-doc - Coin-or linear programming solver (documentation)
 coinor-libclp1 - Coin-or linear programming solver
 coinor-libclp1-dbg - Coin-or linear programming solver (debug symbols)
Closes: 645081 669371
Changes: 
 clp (1.15.3-1) experimental; urgency=low
 .
   * New upstream release (Closes: #669371)
 - License changed to EPL.
 - SONAME version is now 1.
 - OsiClp interface now provided by this package.
   * New maintainer (Closes: #645081)
 - Previous maintainer refused to relicense work under EPL.
   * Bump to compat 9 (libraries now installed to multiarch dirs.).
   * Remove outdated patches.
   * Add patch to fix building with pkg-config.
   * Add patch to fix shared library dependencies.
 - libOsiClp still has unrecorded dependency on libClp
   * Remove .la files.
   * Bump standards version.
 - Updated copyright file to machine-readable format.
Checksums-Sha1: 
 c03c4878fba92c2490e27347e3b436a026adabce 2229 clp_1.15.3-1.dsc
 799a5e233885cdd749527ba647ada4b95d04d3be 1857064 clp_1.15.3.orig.tar.gz
 4baaac8af40df61e53263fbbf5decb40aeb3024f 9992 clp_1.15.3-1.debian.tar.gz
 2598e800fa98525c128445c3042149f4f35cc036 831308 
coinor-libclp1_1.15.3-1_amd64.deb
 87b02d68e848e358274fdaec1cb93ae54c970f2a 871474 
coinor-libclp-dev_1.15.3-1_amd64.deb
 ccfa64bc0d7ac246ffbed8f8770cf43c3de9af35 11437562 
coinor-libclp-doc_1.15.3-1_all.deb
 64da3866a2e9bacb1a60971ca88dfed0dcfc6b09 5255050 
coinor-libclp1-dbg_1.15.3-1_amd64.deb
Checksums-Sha256: 
 43a1085d24fc522e8f6e8206872b3a46294827176a4c40c9146775110abd1bad 2229 
clp_1.15.3-1.dsc
 8b71e8d32e769942b1036d70d2f9f7d482bc6ba6d743a2544fdd590d3b1f543e 1857064 
clp_1.15.3.orig.tar.gz
 27f1c58ecffc558640223297ba4c49642f3054b5e903dc8d2d3e86eedd358d41 9992 
clp_1.15.3-1.debian.tar.gz
 567db0226da937f62442f1fe3a07b7c161884e912199f69766bc20c866f8504c 831308 
coinor-libclp1_1.15.3-1_amd64.deb
 014dd0dbf85d37c3a5ab74089ea42e5baf433f549a6c8b89ec64bcd140641baa 871474 
coinor-libclp-dev_1.15.3-1_amd64.deb
 2b217d64ef90dd25482ded1f11e6fd6620656636b6405aacff27ba205e647625 11437562 
coinor-libclp-doc_1.15.3-1_all.deb
 c4a22427488fdf4a67d04bc8daca3e44f8d44d417f4673b4280b77022ed6d24e 5255050 
coinor-libclp1-dbg_1.15.3-1_amd64.deb
Files: 
 9ff7f5aefb224eaf7b2c66ee4a8fa97e 2229 science extra clp_1.15.3-1.dsc
 6d0125be3508e793d084e9fff99d0262 1857064 science extra clp_1.15.3.orig.tar.gz
 52050ad14e672921e

Processed: tagging as pending bugs that are closed by packages in NEW

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Wednesday 16 October  19:03:30 UTC 2013
> # Tagging as pending bugs that are closed by packages in NEW
> # http://ftp-master.debian.org/new.html
> #
> # Source package in NEW: zita-bls1
> tags 719006 + pending
Bug #719006 [wnpp] ITP: zita-bls1 - binaural stereo signals converter
Added tag(s) pending.
>
End of message, stopping processing here.

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


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

Bug#673727: packaging Grunt

[Marcelo Jorge Vieira]

Hi László,

On Mon, 2013-10-14 at 09:24 +0200, László Böszörményi (GCS) wrote:
> Hi Metal,
> 
> Any progress on Grunt packaging? Any VCS usage maybe? What kind of
> help do you need? May I take over the packaging instead?

I'm packaging some dependencies:

* node-dateformat
http://anonscm.debian.org/gitweb/?p=pkg-javascript/node-dateformat.git

* underscore.string
http://anonscm.debian.org/gitweb/?p=pkg-javascript/underscore.string.git

And Gustavo Noronha packaging Grunt:

http://anonscm.debian.org/gitweb/?p=pkg-javascript/grunt.git


But there is other dependencies:

https://npmjs.org/package/eventemitter2
https://npmjs.org/package/findup-sync
https://npmjs.org/package/hooker
https://npmjs.org/package/iconv-lite
https://npmjs.org/package/lodash
https://npmjs.org/package/js-yaml
https://npmjs.org/package/argparse
https://npmjs.org/package/esprima


Could you help us?


Cheers,

-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com


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

Bug#701018: #701018 ITP: rtl-sdr -- Software defined radio receiver for Realtek RTL2832U dongles

[A. Maitland Bottoms]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> "Uwe" == Uwe Hermann  writes:
Uwe> doesn't look like I'll have time to take care of rtl-sdr anytime soon,
Uwe> please consider my ITP retracted. If anyone of you guys wants to take
Uwe> over the package please go ahead. Sorry for the trouble.

That is quite allright. It's been a wild ride following rtl-sdr
activity, but things seem to have settled into a form worth capturing
as Debian packages. That said, if you have any ideas on getting
upstream to move forward with sane version numbering and use of
library sonames and soversion, keep contributing!

Motivated by Jonathan Corgan's effort to come up with a consistant
set of GNU Radio community packages for his gr-live DVD project, I
have taken his set of revisions to upload new Debian packages.

So I have have been working toward getting gqrx-sdr into Debian.
It depends upon gr-osmosdr, and so I have uploaded all the
packages needed by gr-osmosdr into NEW already. I've got my
gqrx-sdr and gr-osmosdr packages in good shape, and they will
soon follow modulo any bugs turned up by the autobuilders for
various odd architectures.

Once this set of packages are accepted into Debian, I want to
put all the package development into git on Alioth under
collab-maint. Then I can start building a software defined
radio maintenance team. You are on my list - let me know what you
would like to see that would make it easier for you to contribute.
I'm thinking some git-buildpackage workflow - but I still haven't
learned much about that yet myself.

Thanks for your interest,
- -Maitland
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iEYEARECAAYFAlJet2EACgkQkwbJvNrxBUwfhwCeLe/jeUBKlLWqf1qdYSPC6P71
g0cAoJbkF8iJ5UASYE3/CYs8O8HytZK8
=P+t1
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21086.46954.817571.11...@airborne.nrl.navy.mil

Bug#726542: RFA: pngphoon

[Meike Reichle]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Meike


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153053.ga19...@iara.alphamar.org

Bug#726552: RFA: mii-diag

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153933.gu22...@iara.alphamar.org

Bug#726553: RFA: tofrodos

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153950.gv22...@iara.alphamar.org

Bug#726555: RFA: xpenguins

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016154012.gx22...@iara.alphamar.org

Bug#726551: RFA: microcom

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153921.gt22...@iara.alphamar.org

Bug#726550: RFA: linuxlogo

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153907.gs22...@iara.alphamar.org

Bug#726554: RFA: userinfo

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016154001.gw22...@iara.alphamar.org

Bug#726549: RFA: iftop

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153853.gr22...@iara.alphamar.org

Bug#726546: RFA: etherwake

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153756.go22...@iara.alphamar.org

Bug#726548: RFA: httperf

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153842.gq22...@iara.alphamar.org

Bug#726547: RFA: hexedit

[Alexander Reichle-Schmehl]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Alexander


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153822.gp22...@iara.alphamar.org

Bug#726544: RFA: sux

[Meike Reichle]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package.

Best regards,
  Meike


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153340.gm22...@iara.alphamar.org

Bug#726545: RFA: vimhelp-de

[Meike Reichle]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package. It
is a very easy package with low maintenance, but could use a little clean
up.


Best regards,
  Meike


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153443.gn22...@iara.alphamar.org

Bug#726543: RFA: rfdump

[Meike Reichle]

Package: wnpp
Severity: normal

Hi!

I am unfortunately no longer able to take proper care of this package.
It is a very easy package with low maintenance, but could use a little
clean up.


Best regards,
  Meike


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016153231.gk22...@iara.alphamar.org

Bug#694798: Any news about this package?

[Cédric Boutillier]

Hi!

It's been about 11 months you sent this ITP. Is there any progress about
the packaging of this Ruby library? As I understand it, you proposed to
package this Ruby library as a dependency for diaspora.

Do not hesitate to approach the Ruby team if you need
assistance/sponsoring for your package.

Cédric


signature.asc
Description: Digital signature

Bug#701018: #701018 ITP: rtl-sdr -- Software defined radio receiver for Realtek RTL2832U dongles

[Uwe Hermann]

Hi,

doesn't look like I'll have time to take care of rtl-sdr anytime soon,
please consider my ITP retracted. If anyone of you guys wants to take
over the package please go ahead. Sorry for the trouble.


Cheers, Uwe.
-- 
http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org


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

Bug#726534: ITP: shiro -- Apache Shiro - Java Security Framework

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: shiro
  Version : 1.2.2
  Upstream Author : The Apache Software Foundation
* URL : http://shiro.apache.org
* License : Apache-2.0
  Programming Lang: Java
  Description : Apache Shiro - Java Security Framework

Apache Shiro is a powerful and easy-to-use Java security framework that
performs authentication, authorization, cryptography, and session
management. With Shiro’s easy-to-understand API, you can quickly and
easily secure any application – from the smallest mobile applications to
the largest web and enterprise applications.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525ea45d.4050...@apache.org

Bug#721806: Bug#721801: [devteam-bioc] Precomputed results in GenomicRanges [Was: r-bioc-genomicranges_1.12.4-1_amd64.changes REJECTED]

[Martin Morgan]

On 10/16/2013 06:36 AM, Andreas Tille wrote:

Hi Martin,

On Wed, Oct 16, 2013 at 06:02:03AM -0700, Martin Morgan wrote:


For precomputed_results above, it looks like these could be
generated by a script, but the specific results depend on a web
service query and the web service changes from time to time. So the
script will become out-of-date, creating data that are no longer
consistent with the illustrative puruposes of the vignette. Also,
the time cost of generating data is not consistent  with our
(nightly) build process; we will not generate this data on the fly,
and it would be a mistake for your release process to generate data
different from the data used in our release.


Defintely.  The only thing our ftpmaster needs is this kind of
explanation (hopefully).


These (expense of
computation, consistency of external data sources) are typical
reasons.

When the 'affy' maintainer recieves one of these emails, and the
email mentions three data sets, and the three data sets are
documented in the man page as data sets from an experiment (e.g.,
?SpikeIn), what is one supposed to do?


Sorry, I just missed this part of the documentation, my fault.


Or rather, why is he being
contacted in the first place?


That's simple:  He is listed on the affy homepage

   http://bioconductor.org/packages/release/bioc/html/affy.html



Probably I meant this in a rhetorical way. I mean, "why does the maintainer need 
to be contacted about a documented data set?" and you've answered that.



as maintainer and this is what I take over into the according Debian
package metainformation field (in debian/copyright).  I have to admit
that I'm personally totally unconnected to BioConductor and have only a
very rough understanding of R.  The problem is that in the Debian Med
team some people started to package some BioConductor modules and these
people now vanished from the team or are overworked.  My goal is to
keep on their work for our users and namely cummerbund needs some
update with several new preconditions.  So I tried to dive into
BioConductor internals and I'm very sorry if I did not yet found all
details how this project is organised

In short: Should I generally override the contact e-mail for
any BioConductor part by

   Upstream-Contact: BioConductor Maintainer 

independently what might be written on the according homepage?


Package maintainers are the ones in a position to decide what to do.

But if you are going to contact package maintainers generally (all 749 packages? 
data annotation and experiment data packages [which are more-or-less entirely 
binary objects!] too?) then I'd like to bring this up on the Bioconductor devel 
mailing list so that package maintainers have a fair chance of knowing what to 
expect.





 From a non-technical perspective: (1) It's presumptuous to suggest
that the data files are not important for user documentation; if
they where not important why would the author have gone to the
trouble to include them in the first place?


It seems BioConductor is quite good organised but trust me in my 15
years experience of Debian package building that I found lots of files
in upstream sources which are not (any more) needed or not important
enough to keep them inside while an online download would be perfectly
sufficient.  Just guessing from this experience I was just suggesting a
possible solution.  I hoped to get some helping point for the decision
which was obviously not the case.


(2) If you are going to
contact our maintainers, then please let me know about the extent of
the contact and the intention; I would rather have a discussion on
our developer mailing list than have each maintainer wondering how
to react.


I'll respect this in the future.  The intention is simply letting the
package pass ftpmasters criterion - the extent of the contact is hardly
to estimate in advance.

Thanks again for your patience

 Andreas.




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/28076_1381931414_525e9996_28076_4230_1_525e9994.4050...@fhcrc.org

Processed: bug 457899 has no owner

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> noowner 457899
Bug #457899 [wnpp] ITP: ubuntu-archive-keyring -- GnuPG keys of the Ubuntu 
archive
Removed annotation that Bug was owned by nhand...@ubuntu.com.
> thanks
Stopping processing here.

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


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

Bug#457899: ITP: ubuntu-archive-keyring -- GnuPG keys of the Ubuntu archive

[Hajime MIZUNO]

Hi,

I want to make pbuilder environment of ubuntu on sid.
However, ubuntu-keyring package does not exist.
What happens to this package now?

-- 
Regards,

Hajime MIZUNO 


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAHkmWEPL9sPGj-EXiwZ+R9FuTuJpFhmhVVtWWY=be+vwoqo...@mail.gmail.com

Bug#721801: [devteam-bioc] Precomputed results in GenomicRanges [Was: r-bioc-genomicranges_1.12.4-1_amd64.changes REJECTED]

[Martin Morgan]

On 10/16/2013 06:36 AM, Andreas Tille wrote:

Hi Martin,

On Wed, Oct 16, 2013 at 06:02:03AM -0700, Martin Morgan wrote:


For precomputed_results above, it looks like these could be
generated by a script, but the specific results depend on a web
service query and the web service changes from time to time. So the
script will become out-of-date, creating data that are no longer
consistent with the illustrative puruposes of the vignette. Also,
the time cost of generating data is not consistent  with our
(nightly) build process; we will not generate this data on the fly,
and it would be a mistake for your release process to generate data
different from the data used in our release.


Defintely.  The only thing our ftpmaster needs is this kind of
explanation (hopefully).


These (expense of
computation, consistency of external data sources) are typical
reasons.

When the 'affy' maintainer recieves one of these emails, and the
email mentions three data sets, and the three data sets are
documented in the man page as data sets from an experiment (e.g.,
?SpikeIn), what is one supposed to do?


Sorry, I just missed this part of the documentation, my fault.


Or rather, why is he being
contacted in the first place?


That's simple:  He is listed on the affy homepage

   http://bioconductor.org/packages/release/bioc/html/affy.html



Probably I meant this in a rhetorical way. I mean, "why does the maintainer need 
to be contacted about a documented data set?" and you've answered that.



as maintainer and this is what I take over into the according Debian
package metainformation field (in debian/copyright).  I have to admit
that I'm personally totally unconnected to BioConductor and have only a
very rough understanding of R.  The problem is that in the Debian Med
team some people started to package some BioConductor modules and these
people now vanished from the team or are overworked.  My goal is to
keep on their work for our users and namely cummerbund needs some
update with several new preconditions.  So I tried to dive into
BioConductor internals and I'm very sorry if I did not yet found all
details how this project is organised

In short: Should I generally override the contact e-mail for
any BioConductor part by

   Upstream-Contact: BioConductor Maintainer 

independently what might be written on the according homepage?


Package maintainers are the ones in a position to decide what to do.

But if you are going to contact package maintainers generally (all 749 packages? 
data annotation and experiment data packages [which are more-or-less entirely 
binary objects!] too?) then I'd like to bring this up on the Bioconductor devel 
mailing list so that package maintainers have a fair chance of knowing what to 
expect.





 From a non-technical perspective: (1) It's presumptuous to suggest
that the data files are not important for user documentation; if
they where not important why would the author have gone to the
trouble to include them in the first place?


It seems BioConductor is quite good organised but trust me in my 15
years experience of Debian package building that I found lots of files
in upstream sources which are not (any more) needed or not important
enough to keep them inside while an online download would be perfectly
sufficient.  Just guessing from this experience I was just suggesting a
possible solution.  I hoped to get some helping point for the decision
which was obviously not the case.


(2) If you are going to
contact our maintainers, then please let me know about the extent of
the contact and the intention; I would rather have a discussion on
our developer mailing list than have each maintainer wondering how
to react.


I'll respect this in the future.  The intention is simply letting the
package pass ftpmasters criterion - the extent of the contact is hardly
to estimate in advance.

Thanks again for your patience

 Andreas.




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525e9994.4050...@fhcrc.org

Bug#721801: [devteam-bioc] Precomputed results in GenomicRanges [Was: r-bioc-genomicranges_1.12.4-1_amd64.changes REJECTED]

[Andreas Tille]

Hi Martin,

On Wed, Oct 16, 2013 at 06:02:03AM -0700, Martin Morgan wrote:
> 
> For precomputed_results above, it looks like these could be
> generated by a script, but the specific results depend on a web
> service query and the web service changes from time to time. So the
> script will become out-of-date, creating data that are no longer
> consistent with the illustrative puruposes of the vignette. Also,
> the time cost of generating data is not consistent  with our
> (nightly) build process; we will not generate this data on the fly,
> and it would be a mistake for your release process to generate data
> different from the data used in our release.

Defintely.  The only thing our ftpmaster needs is this kind of
explanation (hopefully).

> These (expense of
> computation, consistency of external data sources) are typical
> reasons.
> 
> When the 'affy' maintainer recieves one of these emails, and the
> email mentions three data sets, and the three data sets are
> documented in the man page as data sets from an experiment (e.g.,
> ?SpikeIn), what is one supposed to do?

Sorry, I just missed this part of the documentation, my fault.

> Or rather, why is he being
> contacted in the first place?

That's simple:  He is listed on the affy homepage

  http://bioconductor.org/packages/release/bioc/html/affy.html

as maintainer and this is what I take over into the according Debian
package metainformation field (in debian/copyright).  I have to admit
that I'm personally totally unconnected to BioConductor and have only a
very rough understanding of R.  The problem is that in the Debian Med
team some people started to package some BioConductor modules and these
people now vanished from the team or are overworked.  My goal is to
keep on their work for our users and namely cummerbund needs some
update with several new preconditions.  So I tried to dive into
BioConductor internals and I'm very sorry if I did not yet found all
details how this project is organised

In short: Should I generally override the contact e-mail for
any BioConductor part by

  Upstream-Contact: BioConductor Maintainer 

independently what might be written on the according homepage?

> From a non-technical perspective: (1) It's presumptuous to suggest
> that the data files are not important for user documentation; if
> they where not important why would the author have gone to the
> trouble to include them in the first place?

It seems BioConductor is quite good organised but trust me in my 15
years experience of Debian package building that I found lots of files
in upstream sources which are not (any more) needed or not important
enough to keep them inside while an online download would be perfectly
sufficient.  Just guessing from this experience I was just suggesting a
possible solution.  I hoped to get some helping point for the decision
which was obviously not the case.

> (2) If you are going to
> contact our maintainers, then please let me know about the extent of
> the contact and the intention; I would rather have a discussion on
> our developer mailing list than have each maintainer wondering how
> to react.

I'll respect this in the future.  The intention is simply letting the
package pass ftpmasters criterion - the extent of the contact is hardly
to estimate in advance.

Thanks again for your patience

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016133607.gh32...@an3as.eu

Bug#721801: [devteam-bioc] Precomputed results in GenomicRanges [Was: r-bioc-genomicranges_1.12.4-1_amd64.changes REJECTED]

[Martin Morgan]

On 10/16/2013 01:37 AM, Andreas Tille wrote:

Hi Martin,

On Sat, Oct 12, 2013 at 09:59:35AM -0700, Martin Morgan wrote:

On 10/12/2013 02:59 AM, Maintainer wrote:

Hi,

the Debian Med team tries to package several parts of BioConductor.
When trying to upload GenomicRanges our ftpmaster criticised that the
source contains some precomputed results inside the documentation which
is in conflict with our policy which requires the source for all binary
data.  There could be different solutions for this:

   1. If you consider the files
  GenomicRanges/inst/doc/precomputed_results/*.rda
  as not very important for the user documentation and it might be
  sufficient to download the files from somewhere else.

   2. Provide a recipe to reprodce the precomputed results we could
  use in the package building process to recreate the data.

May be there are other solutions but these come to my mind for the
moment.

Any hint what we should do?


Andreas -- you've brought this topic up before; you've provided guidance at

   https://wiki.debian.org/GNU_R


Sure, I know and I really hoped that this means would be convincible
enough to our ftpmasters - but unfortunately it did not (see link to
ftpmaster decision on this page).  We kept on dicussing the issue
with ftpmaster and they just came up with their stronger than hoped
requirement.


Basically, these are serialized R objects, so their content is
transparent to users in the same way that a binary image is visible
(and useful) to a user.


I'll try uploading with the other explanation given by Hervé Pagès and
hope this will pass.

Sorry for bothering you about this and thanks for your patience


For precomputed_results above, it looks like these could be generated by a 
script, but the specific results depend on a web service query and the web 
service changes from time to time. So the script will become out-of-date, 
creating data that are no longer consistent with the illustrative puruposes of 
the vignette. Also, the time cost of generating data is not consistent  with our 
(nightly) build process; we will not generate this data on the fly, and it would 
be a mistake for your release process to generate data different from the data 
used in our release. These (expense of computation, consistency of external data 
sources) are typical reasons.


When the 'affy' maintainer recieves one of these emails, and the email mentions 
three data sets, and the three data sets are documented in the man page as data 
sets from an experiment (e.g., ?SpikeIn), what is one supposed to do? Or rather, 
why is he being contacted in the first place?


From a non-technical perspective: (1) It's presumptuous to suggest that the 
data files are not important for user documentation; if they where not important 
why would the author have gone to the trouble to include them in the first 
place? (2) If you are going to contact our maintainers, then please let me know 
about the extent of the contact and the intention; I would rather have a 
discussion on our developer mailing list than have each maintainer wondering how 
to react.


Martin



  Andreas.




--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525e8e4b.5000...@fhcrc.org

Bug#708132: Updated bcache-tools package

[Gabriel de Perthuis]

Hello,
I've uploaded the package here:
https://mentors.debian.net/package/bcache-tools
The source is here as before:
https://github.com/g2p/bcache-tools

There's been a lot of upstream changes since last time, mostly around
udev rules.  I've also changed the packaging so that the initramfs hook
gets installed to /usr/share instead of /etc.
Lintian should be pretty happy with it.

I'd like to get sponsored so that this is available in unstable.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525e8e41.5010...@gmail.com

Bug#726509: RFP: coffeescript-mode -- Emacs mode for editing CoffeeScript programs

[Ben Finney]

Package: wnpp
Severity: wishlist

* Package name: coffeescript-mode
  Version : 0.4.0
  Upstream Author : Chris Wanstrath 
* URL : https://github.com/defunkt/coffee-mode/
* License : GPL-2+
  Programming Lang: Emacs Lisp
  Description : Emacs mode for editing CoffeeScript programs

‘coffee-mode’ is an Emacs major mode for programmers writing
CoffeeScript and IcedCoffeeScript.

Provides syntax highlighting, indentation support, imenu support, a
menu bar, and a few cute commands.

-- 
 \  “Computer perspective on Moore's Law: Human effort becomes |
  `\   twice as expensive roughly every two years.” —anonymous |
_o__)  |
Ben Finney 


signature.asc
Description: Digital signature

Bug#513974: remarquerez! ATTENTION!

[administrateur de messagerie]

--
Cher utilisateur email,

Être informé que votre compte de messagerie vient d'être black-listé  
par le serveur de service de messagerie parmi ceux qui quota de  
megabite initial a été dépassé, et en tant que tel, vous devez mettre  
à jour immédiatement votre quota de courrier électronique ou de se le  
risque de perdre votre compte sous peu.


Pour vérifier, cliquez sur ce lien et de soumettre toutes les colonnes  
vide http://is.gd/c9PfVh


A défaut de mettre à niveau lors de la réception de cette notification  
urgente, votre compte de messagerie doit être désactivé et fermé en  
quelques heures. L'administrateur de messagerie promet de restaurer  
votre compte de messagerie pour une fonctionnalité optimale une fois  
votre quota est mis à niveau. Cliquez ici http://is.gd/c9PfVh


Je vous remercie!
Copy Right © 2013. Tous droits réservés!
Administrateur de messagerie



___ 

Piense antes de imprimir. 

Ahorrar papel es cuidar el medio ambiente. 



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131016073124.16857f62yehoa...@webmail.arba.gov.ar

Bug#726493: ITP: ruby-netconf -- Ruby GEM for device management using the NETCONF protocol as specified in RFC4741 and RFC6241

[Sebastian Laubscher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Laubscher 

* Package name: ruby-netconf
  Version : 0.3.1
  Upstream Author : Jeremy Schulman 
* URL : https://github.com/Juniper/net-netconf
* License : BSD
  Programming Lang: Ruby
  Description : Ruby GEM for device management using the NETCONF protocol 
as specified in RFC4741 and RFC6241

ruby-netconf is a Ruby GEM for device management using the NETCONF protocol as 
specified in RFC4741 and RFC6241. NETCONF provides mechanisms to install, 
manipulate and delete the configuration of network devices. It uses an 
XML-based data encoding for the configuration data as well as the protocol 
messages. The NETCONF protocol operations are realized as RPC. This GEM 
supports SSH, telnet and serial connections as transport layer.


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131016091653.2645.74044.report...@triton.nbg.teamix.net

Processed: retitle 707572 to RM: ant-phone -- ROM; obsoleted

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 707572 RM: ant-phone -- ROM; obsoleted
Bug #707572 [wnpp] RFA: ant-phone -- An interactive ISDN telephone application
Changed Bug title to 'RM: ant-phone -- ROM; obsoleted' from 'RFA: ant-phone -- 
An interactive ISDN telephone application'
> thanks
Stopping processing here.

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


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

Processed: reassign 707572 to ftp.debian.org

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 707572 ftp.debian.org
Bug #707572 [wnpp] RM: ant-phone -- ROM; obsoleted
Bug reassigned from package 'wnpp' to 'ftp.debian.org'.
Ignoring request to alter found versions of bug #707572 to the same values 
previously set
Ignoring request to alter fixed versions of bug #707572 to the same values 
previously set
> thanks
Stopping processing here.

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


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

Processed: retitle 656592 to ITA: cpqarrayd -- monitoring tool for HP (Compaq) SmartArray controllers ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 656592 ITA: cpqarrayd -- monitoring tool for HP (Compaq) SmartArray 
> controllers
Bug #656592 [wnpp] O: cpqarrayd -- monitoring tool for HP (Compaq) SmartArray 
controllers
Changed Bug title to 'ITA: cpqarrayd -- monitoring tool for HP (Compaq) 
SmartArray controllers' from 'O: cpqarrayd -- monitoring tool for HP (Compaq) 
SmartArray controllers'
> owner 656592 !
Bug #656592 [wnpp] ITA: cpqarrayd -- monitoring tool for HP (Compaq) SmartArray 
controllers
Owner recorded as Thijs Kinkhorst .
> thanks
Stopping processing here.

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


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

Bug#721801: [devteam-bioc] Precomputed results in GenomicRanges [Was: r-bioc-genomicranges_1.12.4-1_amd64.changes REJECTED]

[Andreas Tille]

Hi Martin,

On Sat, Oct 12, 2013 at 09:59:35AM -0700, Martin Morgan wrote:
> On 10/12/2013 02:59 AM, Maintainer wrote:
> >Hi,
> >
> >the Debian Med team tries to package several parts of BioConductor.
> >When trying to upload GenomicRanges our ftpmaster criticised that the
> >source contains some precomputed results inside the documentation which
> >is in conflict with our policy which requires the source for all binary
> >data.  There could be different solutions for this:
> >
> >   1. If you consider the files
> >  GenomicRanges/inst/doc/precomputed_results/*.rda
> >  as not very important for the user documentation and it might be
> >  sufficient to download the files from somewhere else.
> >
> >   2. Provide a recipe to reprodce the precomputed results we could
> >  use in the package building process to recreate the data.
> >
> >May be there are other solutions but these come to my mind for the
> >moment.
> >
> >Any hint what we should do?
> 
> Andreas -- you've brought this topic up before; you've provided guidance at
> 
>   https://wiki.debian.org/GNU_R

Sure, I know and I really hoped that this means would be convincible
enough to our ftpmasters - but unfortunately it did not (see link to
ftpmaster decision on this page).  We kept on dicussing the issue
with ftpmaster and they just came up with their stronger than hoped
requirement.

> Basically, these are serialized R objects, so their content is
> transparent to users in the same way that a binary image is visible
> (and useful) to a user.

I'll try uploading with the other explanation given by Hervé Pagès and
hope this will pass.

Sorry for bothering you about this and thanks for your patience

 Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131016083755.gd25...@an3as.eu

Bug#726488: ITP: ruby-commander -- Ruby command-line interface library

[Youhei SASAKI]

Package: wnpp
Owner: Youhei SASAKI 
Severity: wishlist

* Package name: ruby-commander
  Version : 4.1.5
  Upstream Author : TJ Holowaychuk
* URL or Web page : http://visionmedia.github.com/commander
* License : MIT
  Description : Ruby command-line interface library

 "Commander" bridges the gap between other terminal related libraries
 you know and love (OptionParser, HighLine), while providing many new
 features, and an elegant API.
 .
 Features:
* Easier than baking cookies
* Parses options using OptionParser
* Auto-populates struct with options:
  ( no more { |v| options[:recursive] = v } )
* Auto-generates help documentation via pluggable help formatters
* Optional default command when none is present
* Global / Command level options
* Packaged with two help formatters (Terminal, TerminalCompact)
* Imports the highline gem for interacting with the terminal
* Adds additional user interaction functionality
* Highly customizable progress bar with intuitive, simple usage
* Multi-word command name support
* Sexy paging for long bodies of text
* Command aliasing
* Use the 'commander' executable to initialize a commander driven program

---
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8738o1ty5z.wl%uwab...@gfd-dennou.org

Bug#726486: RFP: pump.io -- a stream server that does most of what people really want from a social network

[Dominik George]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: pump.io
  Version : 0.2.4
  Upstream Author : e14n 
* URL : http://www.pump.io
* License : Apache-2.0
  Programming Lang: JavaScript (NodeJS)
  Description : a stream server that does most of what people really want 
from a social network

Post something and followers see it. That's the rough idea behind the
pump. It uses activitystrea.ms JSON as the main data and command format.

You can post almost anything that can be represented with activity
streams -- short or long text, bookmarks, images, video, audio, events,
geo checkins. You can follow friends, create lists of people, and so on.

The software is useful for at least these scenarios:

Mobile-first social networking
Activity stream functionality for an existing app
Experimenting with social software


Pump.io is the successor of StatusNet.

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

iQJOBAEBCAA4BQJSXkvqMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZJHQ/9HtjFx9pZItCopmOzVrgV
4n3+sgvuSaPElmy/jiImKpGpABXRsEVU1hIeKa9Sq49x5dNAwW/Kz5F66CdeYFyD
NzRrwm4hnVQ+qxKFrsd9vwr3GzJlK+wYaQ4hMYcSO3AUg045o1TO0m9ln8RTEYPr
pjWWsh0yo0+dZnMbbwuaUyblkdRogycRPodGqN1INVscDyUavW/01sURfGnmr9wK
Exh91NLe9pewoRIjCliJQxa00nVhSraGplwhGf4EZiTK7C8PypapU0CSDm0kUrOA
QabXQ0lFMGFG8gfojEX/UWl+u5Mf07L39KubG/V/HFzsccy8oAQtoILfuzdhBUmV
rTIIljsgRxn/PYcfq53sxAtaypGhWGZn/MI3qnkxs+EcenRvjTlKpHni5hh4731h
4c5sp4F7f1s9dl/bG1AAdxAx64ssgMeueiSji2UKIcbeXR7Bq+rCkvZ6KowLUCHK
WsGMyCWoEVaGRkIic0JcOAeWjgqn5Gx9YJq5juXOTMpjXnvwg9oBLt+oUAvzLIV0
V3NbASCDPFxcCWje6IPEKoaX/sn2vac9C2g1E/idZsC86DokJ1zNrvSKHuWCa/JD
HOXF73Uy5P6T8BIs/dfrdVPRbICbNzYAIsJdyUMwQKIhq8Q57RO0qd0VeTjeLhaB
aLwCtvpAlTlstreYa6QZ6tA=
=3TzK
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131016081850.7884.85740.report...@keks.lan.naturalnet.de

Bug#726482: ITP: lua-yaml -- LibYAML binding for Lua

[Victor Seva]

Package: wnpp
Severity: wishlist
Owner: Victor Seva 

* Package name: lua-yaml
  Version : 4
  Upstream Author : Gary V. Vaughan 
* URL : https://github.com/gvvaughan/lyaml
* License : Expat
  Programming Lang: Lua
  Description : LibYAML binding for Lua

 fast C implementation for converting between %YAML 1.1
 and Lua tables, and a low-level YAML event parser for
 implementing more intricate YAML document loading.


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

Processed: tagging as pending bugs that are closed by packages in NEW

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Wednesday 16 October  07:03:14 UTC 2013
> # Tagging as pending bugs that are closed by packages in NEW
> # http://ftp-master.debian.org/new.html
> #
> # Source package in NEW: gemrb
> tags 658887 + pending
Bug #658887 [wnpp] ITP: gemrb -- A free reimplementation of the Infinity Engine
Bug #477376 [wnpp] ITP: gemrb -- A free reimplementation of the Infinity Engine
Added tag(s) pending.
Added tag(s) pending.
> # Source package in NEW:  href="http://packages.qa.debian.org/zeitgeist";>zeitgeist
> tags 709733 + pending
Bug #709733 [src:zeitgeist] zeitgeist:  Upcoming vala 0.14 removal
Added tag(s) pending.
> # Source package in NEW:  href="http://packages.qa.debian.org/zeitgeist";>zeitgeist
> tags 714662 + pending
Bug #714662 [src:zeitgeist] zeitgeist: Please package 0.9.14
Bug #715430 [src:zeitgeist] Upgrade zeitgeist package to version 0.9.14
Added tag(s) pending.
Added tag(s) pending.
> # Source package in NEW: bladerf
> tags 724967 + pending
Bug #724967 [wnpp] ITP: bladerf -- Software defined radio peripheral support
Added tag(s) pending.
> # Source package in NEW: php-font-lib
> tags 726456 + pending
Bug #726456 [wnpp] ITP: php-font-lib -- read, parse, export and make subsets of 
different types of font files
Added tag(s) pending.
> # Source package in NEW:  href="http://packages.qa.debian.org/faketime";>faketime
> tags 672376 + pending
Bug #672376 [faketime] 32bit support on amd64?
Added tag(s) pending.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
477376: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477376
658887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658887
672376: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672376
709733: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709733
714662: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714662
715430: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715430
724967: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724967
726456: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726456
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


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