Roll call for porters of architectures in sid and testing

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

As we announced in [LAST-BITS], we would like to get a better idea of
that status of the ports, to make an informed decision about which
port can be released with jessie. One of the steps is to get an
overview of which of the porters are (still) active for each
port. Once the results from the role-call are in, we will request
other information about the status of the ports. In the meantime, feel
free to update and collect info about the ports in the Debian wiki[WIKI].

If you are (or intend to become) an active porter for the lifetime of
jessie, then please send a signed email explaining your involvement in
the port to the Release Team  before
1st of October 2013. Please explain the level of your involvement in
the port.

Feel free to use the following template as your reply:

"""
  Hi,
  
  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:

  For , I
  - test (most|all) packages on this architecture
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - maintain buildds
  - ...
  
  
  
  
"""

Niels, on behalf of the release team

[LAST-BITS] http://lists.debian.org/debian-devel-announce/2013/08/msg6.html

[WIKI] https://wiki.debian.org/ArchiveQualification/Jessie

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

iQIcBAEBCAAGBQJSIu2TAAoJEAVLu599gGRC86EP/j/7FEZ9pxpTEHrBI41GTu6r
nENS5kAZAuxFQHfYLtKexBcgneGd6cgdmr3cIoh1ZL9lJgXq74X8FL5IbWNqUw9S
o9UQWpZJiwIIlH4fqSgFVLIphI0DQr7dXI7xcDIm4kl6Fdruo1tGxX8xqL23jzdP
nQb3jrXv3bj5943MfWeCbODILv2N6qev9VtWeQ6Wmh8PvxRUl7VqgdQaeHtlMsUp
TQT5fz0cw8gc2amlwlOZxaGDV2C8mHboJIKMEsu79BK4SlFSED9rXn4juFPUnAgG
uADsMdBBqEIgSMN42cPHQju+KLfJe/+xScmlzzDS/d7aWWs02TibcQ1ZnPi+bcgp
bd/Wa0lms+Fc2OpcuFle9Lwo+2B+ka1Dd3itm+D0SbmrxoGi6CuMMwydLcQbSJ73
hHw9HJEIQr2x/ZItNPJrSvvj50rwYXcmFbxtVAwv2pFXfQ37iukYgAaaMvnwpNNJ
6dM1coCF9skNkXLO8rkZ+5aupGgjpS9BdKKAEQrPy/aoaW9KNCZrLQeA4C3QySBU
OcCNBv7taSjVAVNszKtRIQpu2gzFGAV0u9Gj41qW1JzDHYrmAvMyGxrndOxTmaFr
p05QWgcMsPhNvdHjd6sWLyzJ5NYUKksCPMRgCc0BEd6moIyrt7UFsp2+guJZPBJ0
pffEJGK2iGtrWmJfElof
=TUeZ
-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/20130901073351.a92862...@thykier.net

Bug#721486: ITP: node-tilelive-bridge -- Tilelive store for generating mapnik vector tiles - Node.js module

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-tilelive-bridge
  Version : 0.0.2
  Upstream Author : MapBox 
* URL : https://github.com/mapbox/tilelive-bridge
* License : BSD-3-clause
  Programming Lang: JavaScript
  Description : Tilelive store for generating mapnik vector tiles - Node.js 
module

node-tilelive-bridge implements the tilelive API and as such is a
registerable tilestore URI protocol handler for generating mapnik
vector tiles from traditional mapnik datasources.
.
node-tilelive is an interface for tile backends for Node.js.
.
mapnik is a C++/Python toolkit for developing GIS applications.
.
Node.js is an event-based server-side javascript engine.


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

Bug#721488: ITP: node-tilelive-vector -- Tilelive store for rendering mapnik vector tiles - Node.js module

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-tilelive-vector
  Version : 0.1.3
  Upstream Author : MapBox 
* URL : https://github.com/mapbox/tilelive-vector
* License : BSD-3-clause
  Programming Lang: JavaScript
  Description : Tilelive store for rendering mapnik vector tiles - Node.js 
module

node-tilelive-vector implements the tilelive API for rendering mapnik vector
tiles to raster images, svg, or json.
.
node-tilelive is an interface for tile backends for Node.js.
.
mapnik is a C++/Python toolkit for developing GIS applications.
.
Node.js is an event-based server-side javascript engine.


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

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Paul Wise]

On Sat, Aug 31, 2013 at 5:57 PM, Michael Gilbert wrote:

> I've been meaning to add more informative info to the security-tracker
> about end-of-lifed packages.  Right now you can see that info in the
> raw tracker data, but the generate web pages don't make that clear at
> all.

Is the raw tracker data you are talking about?

http://anonscm.debian.org/viewvc/secure-testing/data/package-tags?view=co

As far as I can tell users are very unlikely to notice this. The tags
are exported to the Packages files in wheezy but apt doesn't do
anything with that information. debsecan doesn't seem to have support
for these secteam tags and also lacks integration with apt (#431804).
debsecan needs more people helping with it.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6F11mpP2kn_Gn==6m4z-5d85i-qerfsbyuaevvzw-x...@mail.gmail.com

Bug#721511: ITP: oslo.messaging -- OpenStack RPC and notifications

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: oslo.messaging
  Version : 1.2.0~a4
  Upstream Author : OpenStack contributors 
* URL : https://github.com/openstack/oslo.messaging
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack RPC and notifications

 The oslo messaging API supports RPC and notifications over a number of
 different messaging transports.


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

Bug#721517: ITP: python-httpretty -- HTTP client mock for Python

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-httpretty
  Version : 0.6.3
  Upstream Author : Gabriel Falcao
* URL : https://github.com/gabrielfalcao/httpretty
* License : MIT
  Programming Lang: Python
  Description : HTTP client mock for Python

 Once upon a time a python developer wanted to use a RESTful api, everything
 was fine but until the day he needed to test the code that hits the RESTful
 API: what if the API server is down? What if its content has changed ?
 .
 Don't worry, HTTPretty is here for you.


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

Bug#721521: ITP: fonts-urw-base35 -- Set of the 35 PostScript Language Level 2 Base Fonts

[Fabian Greffrath]

Package: wnpp
Severity: wishlist
Owner: Fabian Greffrath 

* Package name: fonts-urw-base35
  Version : 2:20130628-1
  Upstream Author : (URW)++ Design & Development
* URL : http://downloads.ghostscript.com/public/fonts/
* License : GPL (needs clarification, see #720906)
  Programming Lang: fonts
  Description : Set of the 35 PostScript Language Level 2 Base Fonts
 A commercial-quality set of the basic 35 PostScript Type 1 fonts.
 Each font includes .pfb (outlines), .afm (metrics), and .pfm (Windows printer
 metrics) files. The fonts are compatible with general Type 1 manipulation
 tools as well as with Ghostscript.

This package will contain an updated set of the 35 PostScript base fonts, that
has been made available by upstream author URW++ to Artifex, the developers of
Ghostscript, and is already shipped as part of ghostscript 9.09. It is intended
to replace the gsfonts package, which contains a fork of an ancient version of
these fonts with added cyrilic glyphs. However, that fork is long unmaintained
upstream and the glyphs are of reportedly questionable quality, which I cannot
judge for myself, though. The package will also integrate the effort to make
the fonts available to an X server and thus replace the gsfonts-x11 package.
Finally, I am going to convince the texlive maintainers to replace their copy
of these fonts in the texlive-fonts-recommended package (used for the psnfss
latex-package) with this pristine release. All corresponsing package
maintainers are in CC.

I am going to maintain this package under the umbrella of the pkg-fonts team.
The license for the fonts used to be GPL, but a corresponding note has
apparently been forgotten in the current release. This issue is reported as
#720906 in Debian (against the ghostscript package, which already ships an
updated version of these fonts, but not yet this latest update) and has been
brought to the attention of ghostscript upstream who will strive for
clarification with URW++ in the short term.

 - Fabian


-- 
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/20130901150636.9202.70922.report...@hit-nxdomain.opendns.com

Re: Roll call for porters of architectures in sid and testing

[Christoph Egger]

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the jessie release:

For kfreebsd-*, I
- test packages on this architecture

This includes running a Desktop (Notebook) System on testing and am
therefore testing the relevant stack every day

- triage arch-specific bugs

I've been working on regressions for some time and plan to continue
there (in the past I've worked e.g. on libxcb, emacs and the kernel
+ lots of build failures)

- fix arch-related bugs
- maintain buildds

I am a DD

Christoph


pgpzoj7DXbuh_.pgp
Description: PGP signature

Bug#721525: ITP: jspecview -- viewer for spectral data in the JCAMP-DX format

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: jspecview
  Version : 2.0
  Upstream Author : 2002-2013 The University of the West Indies; contact

* URL : svn://svn.code.sf.net/p/jspecview/svn/dev2
* License : LGPL-2.1
  Programming Lang: Java
  Description : viewer for spectral data in the JCAMP-DX format
 JSpecView is a viewer for spectral data in the JCAMP-DX format. The
 program was initially developed at the Department of Chemistry of the
 University of the West Indies, Mona, Jamaica, WI. For a description
 of version 1 see the article published in Chemistry Central Journal
 2007, 1:31 (07Dec2007)


-- 
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/20130901155819.4956.40055.report...@georges.khaznadar.fr

Re: How git performs when you throw all of Debian at it

[Stephen Gran]

This one time, at band camp, Philipp Kern said:
> On Sat, Aug 31, 2013 at 04:12:11PM +, Luca Filipozzi wrote:
> > I'm curious why there's no apparent appetite for hdfs / solr / etc.
> 
> I don't know how far regex matching is with solr these days. This
> implementation is AFAIK based on [1]. But then the tool exists and
> would need to be thrown away completely for no obvious gain. How would
> you store the solr index? How would lookups be faster than a custom
> built index where it's basically known how many seeks you need per
> request?
> 
> It's akin asking you to port everything to Chef just for the sake of
> it, except that the target language would actually be Java, which
> likely consumes even more resources than the Go binary.

That's looking at it upside down, I think.  chef was the new shiny after
we'd already started down the puppet road.  Michael's implementation did
not, in fact, exist before solr.

luca is not asking, "why aren't you using the new shiny", he's asking,
"why hasn't a proposal for a project that does string searching used one
of the already available, off the shelf string searching programs".

Asking someone why they didn't choose off the shelf tools to do a job
that is largely a solved problem is a reasonable thing to do, especially
when being asked to support new, custom code that is certain to come
with its own quirks, bugs, and security issues.

I think the answer here is, "more code could be reused by borrowing work
from google" - the NIH syndrome appears to be google's, rather than
Michael's, if I understand correctly.  That's probably a fine answer,
but the question also needed to be asked.

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


signature.asc
Description: Digital signature

Bug#721545: ITP: python-requests-oauthlib -- python module providing OAuthlib authentication support for requests

[Simon Fondrie-Teitler]

Package: wnpp
Severity: wishlist
Owner: "Simon Fondrie-Teitler" 

* Package name: python-requests-oauthlib
  Version : 0.3.3
  Upstream Author : Kenneth Reitz 
* URL : https://github.com/requests/requests-oauthlib
* License : ISC
  Programming Lang: Python
  Description : Python module providing OAuthlib authentication support for 
requests

requests-oauthlib allows you to interact with OAuth 1 And OAuth 2 in
greatly simplified ways through the requests library for Python. It
will hide the quirks and hacks in OAuth 1, and will interface with all
four of the grant types defined by the OAuth2 RFC.


-- 
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/20130901201129.3286.91343.reportbug@goldman

Bug#721551: ITP: ndpi -- extensible deep packet inspection library

[Ludovico Cavedon]

Package: wnpp
Severity: wishlist
Owner: Ludovico Cavedon 

* Package name: ndpi
  Version : 1.4.0
  Upstream Author : Luca Deri 
* URL : http://www.ntop.org/products/ndpi/
* License : LGPL-3
  Programming Lang: C
  Description : extensible deep packet inspection library

nDPI is a ntop-maintained superset of the popular OpenDPI library.
Released under the LGPL license, its goal is to extend the original
library by adding new protocols that are otherwise available only on the
paid version of OpenDPI.

nDPI has also been modified to be suitable for traffic monitoring
applications, by disabling specific features that slow down the DPI
engine while being them un-necessary for network traffic monitoring.

With nDPI, it is possible to both detect known protocols on non-standard
ports (e.g. detect http non ports other than 80), and also the opposite.


-- 
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/20130901205318.ga21...@palladio.lastline.com

Re: DSA, kFreeBSD, and the Singularity (was: How git performs when you throw all of Debian at it)

[Steven Chamberlain]

Hi Luca!

On Sat, 31 Aug 2013 16:12:11 +, Luca Filipozzi wrote:
> We also run kfreebsd, with some challenge, but we have it.

How can we help with that?

e.g. Do you need it to better suit running as a virtualised guest, on
KVM or Xen for example?  virtio drivers should be forthcoming for jessie
and a XENHVM flavour is possible if it seems worth it.

I can only recall one wishlist bug from DSA at the moment which is
#711247 requesting pflogd.  I'd love to hear more wishlist kfreebsd
ideas from DSA.

I'd like it to be readily available whenever it might be a good fit for
some internal project.  Having as much Debian software as possible
feeding back into Debian development systems, makes the project seem
something of an unstoppable machine approaching the Singularity...

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


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

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Vincent Bernat]

 ❦  1 septembre 2013 12:04 CEST, Paul Wise  :

> http://anonscm.debian.org/viewvc/secure-testing/data/package-tags?view=co
>
> As far as I can tell users are very unlikely to notice this. The tags
> are exported to the Packages files in wheezy but apt doesn't do
> anything with that information. debsecan doesn't seem to have support
> for these secteam tags and also lacks integration with apt (#431804).
> debsecan needs more people helping with it.

Or a maintainer willing to accept patches:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=470065
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Michael Gilbert]

On Sun, Sep 1, 2013 at 6:04 AM, Paul Wise wrote:
> On Sat, Aug 31, 2013 at 5:57 PM, Michael Gilbert wrote:
>
>> I've been meaning to add more informative info to the security-tracker
>> about end-of-lifed packages.  Right now you can see that info in the
>> raw tracker data, but the generate web pages don't make that clear at
>> all.
>
> Is the raw tracker data you are talking about?
>
> http://anonscm.debian.org/viewvc/secure-testing/data/package-tags?view=co

No, the end-of-life tags in:
http://anonscm.debian.org/viewvc/secure-testing/data/CVE/list?view=co

> As far as I can tell users are very unlikely to notice this. The tags
> are exported to the Packages files in wheezy but apt doesn't do
> anything with that information. debsecan doesn't seem to have support
> for these secteam tags and also lacks integration with apt (#431804).
> debsecan needs more people helping with it.

Yes, this information really needs to be more user visible.
Assistance with the security tracker is welcomed.

debsecan hasn't had a maintainer upload in almost two years, so nmus
fixing its open issues are quite appropriate.

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=MMG2pZsHbMPzFUDFo6vd5MR1L79rcwHJGTEO__R=+p...@mail.gmail.com

Bug#721558: ITP: node-ws -- Fastest RFC-6455 WebSocket implementation for Node.js

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-ws
  Version : 0.4.30
  Upstream Author : Einar Otto Stangvik
* URL : https://github.com/einaros/ws
* License : Expat
  Programming Lang: Javascript
  Description : Fastest RFC-6455 WebSocket implementation for Node.js

 ws is a simple to use websocket implementation, up-to-date against RFC-6455,
 and probably the fastest WebSocket library for node.js.
 .
 ws passes the quite extensive Autobahn test suite.
 .
 Comes with a command line utility, wscat, which can either act as a server
 (--listen), or client (--connect); Use it to debug simple websocket services.


-- 
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/20130901221848.14087.21100.report...@minobo.das-netzwerkteam.de

Bug#721561: ITP: node-nan -- Native Abstractions for Node.js

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-nan
  Version : 0.3.1
  Upstream Author : Rod Vagg 
* URL : https://github.com/rvagg/nan
* License : Expat~no-false-attribs
  Programming Lang: Javascript
  Description : Native Abstractions for Node.js

 A header file filled with macro and utility goodness for making addon
 development for Node.js easier across versions 0.8, 0.10 and 0.11, and
 eventually 0.12.
 .
 Thanks to the crazy changes in V8 (and some in Node core), keeping native
 addons compiling happily across versions, particularly 0.10 to 0.11/0.12,
 is a minor nightmare. The goal of this project is to store all logic
 necessary to develop native Node.js addons without having to inspec
 NODE_MODULE_VERSION and get yourself into a macro-tangle.
 .
 This project also contains some helper utilities that make addon development
 a bit more pleasant.


-- 
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/20130901224034.16892.67051.report...@minobo.das-netzwerkteam.de

Re: Bug#721517: ITP: python-httpretty -- HTTP client mock for Python

[Nick Phillips]

On Sun, 2013-09-01 at 22:17 +0800, Thomas Goirand wrote: 
> Package: wnpp
> Severity: wishlist
> Owner: Thomas Goirand 
> 
> * Package name: python-httpretty
>   Version : 0.6.3
>   Upstream Author : Gabriel Falcao
> * URL : https://github.com/gabrielfalcao/httpretty
> * License : MIT
>   Programming Lang: Python
>   Description : HTTP client mock for Python
> 
>  Once upon a time a python developer wanted to use a RESTful api, everything
>  was fine but until the day he needed to test the code that hits the RESTful
>  API: what if the API server is down? What if its content has changed ?
>  .
>  Don't worry, HTTPretty is here for you.

As someone who might be interested in using this package, that
description needs to be rather more specific. I'm sure I ought to be
terribly reassured that HTTPretty is going to be there for me, but it
would be more helpful to tell me what this package actually does.


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

Re: Roll call for porters of architectures in sid and testing

[Adam Holland]

Hi, sorry I'm not a skilled programmer, I just have a historic SGI O2 to
play around with a bit. If the hardware dies, I won't really have any
reaspn to stay involved with this port.

-Adam


On Sun, Sep 1, 2013 at 3:33 AM, Niels Thykier  wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> As we announced in [LAST-BITS], we would like to get a better idea of
> that status of the ports, to make an informed decision about which
> port can be released with jessie. One of the steps is to get an
> overview of which of the porters are (still) active for each
> port. Once the results from the role-call are in, we will request
> other information about the status of the ports. In the meantime, feel
> free to update and collect info about the ports in the Debian wiki[WIKI].
>
> If you are (or intend to become) an active porter for the lifetime of
> jessie, then please send a signed email explaining your involvement in
> the port to the Release Team  before
> 1st of October 2013. Please explain the level of your involvement in
> the port.
>
> Feel free to use the following template as your reply:
>
> """
>   Hi,
>
>   I am an active porter for the following architectures and I intend
>   to continue this for the lifetime of the jessie release:
>
>   For , I
>   - test (most|all) packages on this architecture
>   - fix toolchain issues
>   - triage arch-specific bugs
>   - fix arch-related bugs
>   - maintain buildds
>   - ...
>
>   
>
>   
> """
>
> Niels, on behalf of the release team
>
> [LAST-BITS]
> http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
>
> [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBCAAGBQJSIu2TAAoJEAVLu599gGRC86EP/j/7FEZ9pxpTEHrBI41GTu6r
> nENS5kAZAuxFQHfYLtKexBcgneGd6cgdmr3cIoh1ZL9lJgXq74X8FL5IbWNqUw9S
> o9UQWpZJiwIIlH4fqSgFVLIphI0DQr7dXI7xcDIm4kl6Fdruo1tGxX8xqL23jzdP
> nQb3jrXv3bj5943MfWeCbODILv2N6qev9VtWeQ6Wmh8PvxRUl7VqgdQaeHtlMsUp
> TQT5fz0cw8gc2amlwlOZxaGDV2C8mHboJIKMEsu79BK4SlFSED9rXn4juFPUnAgG
> uADsMdBBqEIgSMN42cPHQju+KLfJe/+xScmlzzDS/d7aWWs02TibcQ1ZnPi+bcgp
> bd/Wa0lms+Fc2OpcuFle9Lwo+2B+ka1Dd3itm+D0SbmrxoGi6CuMMwydLcQbSJ73
> hHw9HJEIQr2x/ZItNPJrSvvj50rwYXcmFbxtVAwv2pFXfQ37iukYgAaaMvnwpNNJ
> 6dM1coCF9skNkXLO8rkZ+5aupGgjpS9BdKKAEQrPy/aoaW9KNCZrLQeA4C3QySBU
> OcCNBv7taSjVAVNszKtRIQpu2gzFGAV0u9Gj41qW1JzDHYrmAvMyGxrndOxTmaFr
> p05QWgcMsPhNvdHjd6sWLyzJ5NYUKksCPMRgCc0BEd6moIyrt7UFsp2+guJZPBJ0
> pffEJGK2iGtrWmJfElof
> =TUeZ
> -END PGP SIGNATURE-
>
>
> --
> To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20130901073351.a92862...@thykier.net
>
>

Bug#721575: ITP: brackets -- open source code editor for web

[Zlatan Todorić]

Package: wnpp
Severity: wishlist
Owner: "Zlatan Todorić" 

* Package name: brackets
  Version : 0.29
  Upstream Author : Adobe 
* URL : http://brackets.io/
* License : MIT
  Programming Lang: JavaScript, HTML, CSS
  Description : open source code editor for web


-- 
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/20130902001947.15993.10500.reportbug@debian

Re: Roll call for porters of architectures in sid and testing

[Kip Warner]

On Sun, 2013-09-01 at 20:18 -0400, Adam Holland wrote:
> Hi, sorry I'm not a skilled programmer, I just have a historic SGI O2 to
> play around with a bit. If the hardware dies, I won't really have any
> reaspn to stay involved with this port.

Still cool that you have one though!

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com


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

Nitpicking in the NEW queue.

[Charles Plessy]

Answering on a broader audience because I think that there is really a drift
from ensuring archive integrity to massive and arbitrary top-down nitpicking.

Le Mon, Sep 02, 2013 at 01:00:17AM +, Paul Richards Tagliamonte a écrit :
> 
> Hello, maintainer,
> 
> I'm sorry, but I've rejected your package.
[...]
> This package is also really small, is there no other package this fits into?

Hi Paul,

you have to understand how demotivating and infuriating it is to bounce from
people who think that these files should not be in their package to people who
think that these files should be in somebody else's package, with multi-week
waiting times or waiting lines in between the answers.

Earlier this year, I had another rejection email where I was asked to by the
way clean some emacs backups or whatever from the Upstream tarball.  It is a
matter of taste.  How do these comments guide us to undestand if the next
upload will be rejected or not ?

I would like that the FTP team please refrain from giving cheap side comments
or ask cheap questions in its rejection emails (have you noticed that the ITP
bug was originally submitted as a wishlist addition to another package ?) and
stick to what makes the package fit or not fit for our archive.  Is a small
package acceptable, yes or no, where do you draw the line, and please assume
that the uploader acted responsibly, or if not, check first the facts before
asking.

PS: While I apologise for my error in the Debian copyright file, please note
that a quick inspection of the package could have shown you that replacing the
current content of the Files field by "*" would have solved the problem
entirely.  I will re-upload "when I have time".

Cheers,

-- 
Charles Plessy
Illkirch-Graffenstaden, France


-- 
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/20130902025841.gd8...@falafel.plessy.net

Re: Nitpicking in the NEW queue.

[Scott Kitterman]

On Monday, September 02, 2013 11:58:41 Charles Plessy wrote:
> Answering on a broader audience because I think that there is really a drift
> from ensuring archive integrity to massive and arbitrary top-down
> nitpicking.
> Le Mon, Sep 02, 2013 at 01:00:17AM +, Paul Richards Tagliamonte a écrit 
:
> > Hello, maintainer,
> > 
> > I'm sorry, but I've rejected your package.
> 
> [...]
> 
> > This package is also really small, is there no other package this fits
> > into?
> Hi Paul,
> 
> you have to understand how demotivating and infuriating it is to bounce from
> people who think that these files should not be in their package to people
> who think that these files should be in somebody else's package, with
> multi-week waiting times or waiting lines in between the answers.
> 
> Earlier this year, I had another rejection email where I was asked to by the
> way clean some emacs backups or whatever from the Upstream tarball.  It is
> a matter of taste.  How do these comments guide us to undestand if the next
> upload will be rejected or not ?
> 
> I would like that the FTP team please refrain from giving cheap side
> comments or ask cheap questions in its rejection emails (have you noticed
> that the ITP bug was originally submitted as a wishlist addition to another
> package ?) and stick to what makes the package fit or not fit for our
> archive.  Is a small package acceptable, yes or no, where do you draw the
> line, and please assume that the uploader acted responsibly, or if not,
> check first the facts before asking.
> 
> PS: While I apologise for my error in the Debian copyright file, please note
> that a quick inspection of the package could have shown you that replacing
> the current content of the Files field by "*" would have solved the problem
> entirely.  I will re-upload "when I have time".

It would have been nice if you'd done such an inspection before you uploaded 
and wasted the ftp-team's time doing multiple reviews.

Conveniently, you have elided the actual rejection reason from your message to 
-devel and gone off on a rant about about something that was raised as a 
reasonable question.  

If you would prefer we not ask the maintainers questions when we have them, 
perhaps you would like it better if we put such packages aside and leave them 
in New until we have time to fully research them?

I didn't think so.

Please just answer the question, fix your package, and quite harassing someone 
who's trying to do work that's important to the project and doesn't need your 
demotivational speeches.

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/4523068.he7bHlQMSZ@scott-latitude-e6320

Re: Nitpicking in the NEW queue.

[Paul R. Tagliamonte]

On my phone, excuse the Cc and (I'm guessing HTML mail)

Hi, Charles.

On Sep 1, 2013 10:59 PM, "Charles Plessy"  wrote:
>
> Answering on a broader audience because I think that there is really a
drift
> from ensuring archive integrity to massive and arbitrary top-down
nitpicking.
>
> Le Mon, Sep 02, 2013 at 01:00:17AM +, Paul Richards Tagliamonte a
écrit :
> >
> > Hello, maintainer,
> >
> > I'm sorry, but I've rejected your package.
> [...]

This ... Is why I rejected the package. You didn't have copyright noted for
any files in the package (and noted a file that didn't exist)

> > This package is also really small, is there no other package this fits
into?
>
> Hi Paul,
>
> you have to understand how demotivating and infuriating it is to bounce
from
> people who think that these files should not be in their package to
people who
> think that these files should be in somebody else's package, with
multi-week
> waiting times or waiting lines in between the answers.

Respectfully - when we add micro (under Size 100 packages) the amount of
metadata added to every mirror and every users machine is almost as much as
the package contents.

This is a very common request (make sure this really needs to be split out
) and not even the reason for this reject.

>
> Earlier this year, I had another rejection email where I was asked to by
the
> way clean some emacs backups or whatever from the Upstream tarball.  It
is a
> matter of taste.  How do these comments guide us to undestand if the next
> upload will be rejected or not ?
>
> I would like that the FTP team please refrain from giving cheap side
comments

Um..

> or ask cheap questions in its rejection emails (have you noticed that the
ITP
> bug was originally submitted as a wishlist addition to another package ?)
and

These "cheep comments" are intended to be helpful. I'm sorry you don't
appreciate it, but folks are usually thankful for the second pair of eyes
on the changes.

> stick to what makes the package fit or not fit for our archive.  Is a
small
> package acceptable, yes or no, where do you draw the line, and please
assume
> that the uploader acted responsibly, or if not, check first the facts
before
> asking.
>
> PS: While I apologise for my error in the Debian copyright file, please
note
> that a quick inspection of the package could have shown you that
replacing the
> current content of the Files field by "*" would have solved the problem
> entirely.  I will re-upload "when I have time".
>
> Cheers,
>
> --
> Charles Plessy
> Illkirch-Graffenstaden, France
>
>
> --
> 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/20130902025841.gd8...@falafel.plessy.net
>