Consciously blocking packages and development

2013-09-02 Thread Norbert Preining
Dear maintainers of debian-edu-doc, all of d-d

[short explanation for d-d: debian-edu-doc has a serious bug since it 
build-deps on a not existing package. Instead of transiting to the
new pakcage naming, it keeps the old anme hindering transition)

On Do, 15 Aug 2013, Norbert Preining wrote:
> thanks for fixing it in git, but could you please upload a fixed version
> of the package as soon as possible?

I see that the fix was even reverted in the git repository.

Are you planning to block TeX Live transition for unforeseeable future?
Might I remind you that the packaging is for Debian/sid to go into
testing.

Whatever your ideas and backgrounds concerning Debian Edu are,
your main obligation is *not*to*block*hinder* other packages.

Might I also remind you once more, that the target of development is
*unstable* and *NOT* (!!!) wheezy which is released. Your statement
that it has to be buildable on wheezy is *simply* plain wrong.

It is ridiculous that you not even care for *answering* to 
inquiries on a serious bug, although there is a lot of activity
in the git repository (see below for logs).

Thanks for your understanding

Norbert



commit 2f2fd908a54bc106eebdd21e8260ec4399436c5e
Author: David Prévot 
Date:   Wed Jul 17 13:13:00 2013 -0400

Revert "Build-depend on texlive-lang-danish | texlive-lang-european and 
texlive-lang-norwegian | texlive-lang-european to support building on wheezy 
and sid. (Closes: #709758)"

This reverts commit 34130ece41450e92cea0a007f24a0fcebbc8573b.

commit a2d9ca4796df74cc4dfb1cf4e490fe15a11b4b32
Author: David Prévot 
Date:   Wed Jul 17 13:12:46 2013 -0400

Revert "Change order of alternative depends."

This reverts commit 2bcf0673abe4514deece73502d661c4d888a31c2.

commit 2bcf0673abe4514deece73502d661c4d888a31c2
Author: Holger Levsen 
Date:   Mon Jul 15 14:01:10 2013 +0200

Change order of alternative depends.

Build-depend on texlive-lang-european | texlive-lang-danish and 
texlive-lang-european | texlive-lang-norwegian to support building on wheezy 
and sid.

commit 34130ece41450e92cea0a007f24a0fcebbc8573b
Author: Holger Levsen 
Date:   Mon Jul 15 13:33:40 2013 +0200

Build-depend on texlive-lang-danish | texlive-lang-european and 
texlive-lang-norwegian | texlive-lang-european to support building on wheezy 
and sid. (Closes: #709758)


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



-- 
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/20130903061002.gc29...@gamma.logic.tuwien.ac.at



Re: Less dinstall FTW?

2013-09-02 Thread Steve Langasek
Hi Ansgar,

On Thu, Aug 29, 2013 at 02:39:09PM +0200, Ansgar Burchardt wrote:
> So what's the proposed change?
> --

> The more interesting part of the proposal has so far been ignored by
> most replies: we would make the incoming.d.o archive public. This would
> mean all new uploads are available after ~15 minutes via APT, a lot
> faster than the current interval between dinstall runs.

> The less interesting part is the (optional) change in dinstall
> frequency. As the main reason for a higher frequency falls away as new
> uploads are accessible via incoming.d.o, we could revert back to running
> dinstall twice per day (instead of four times). Or we could stay at four
> times.

> The open question is if having earlier (easy) access to uploads is
> worthwhile or if it would just lead to people running apt-get update in
> a loop to always have the newest packages without any real gains for the
> project.

So for me, that's not the important question.  I think having an aptable
incoming.d.o seems reasonably worthwhile, but I also think it's important
that packages reach the *real* archive as quickly as possible, and not have
end users (incl. developers) pulling from an intermediate "incoming" archive
on any sort of routine basis.

The question for me is, other than the perception that the 4x daily dinstall
is "no longer needed" with an aptable incoming, is there a reason *to*
reduce the dinstall frequency?  If not, I agree with Joey and Ian that
frequent archive publication is useful in its own right for a variety of
reasons.

Cheers,
-- 
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#721664: ITP: ruby-ffi-rzmq -- FFI based Ruby bindings for ZeroMQ (ØMQ) networking library

2013-09-02 Thread Dmitry Borodaenko
Package: wnpp
Severity: wishlist
Owner: Dmitry Borodaenko 

* Package name: ruby-ffi-rzmq
  Version : 1.0.1
  Upstream Author : Chuck Remes
* URL : http://www.zeromq.org/bindings:ruby-ffi
* License : MIT
  Programming Lang: Ruby
  Description : FFI based Ruby bindings for ZeroMQ (ØMQ) networking library

 ØMQ is a library which extends the standard socket interfaces with features
 traditionally provided by specialised messaging middleware products.
 .
 ØMQ sockets provide an abstraction of asynchronous message queues, multiple
 messaging patterns, message filtering (subscriptions), seamless access to
 multiple transport protocols and more.
 .
 This module wraps ØMQ using Ruby FFI (foreign function interface). It is a
 pure Ruby wrapper so it can be used with any Ruby runtime that supports FFI,
 including MRI, Rubinius and JRuby.

-- 
Dmitry Borodaenko


-- 
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/20130902211858.GA14182@localhost



Re: [Pkg-opencl-devel] Bug#719909: ITP: libclc -- Implementation of OpenCL 1.1

2013-09-02 Thread Vincent Danjean
Le 19/08/2013 06:28, Julian Wollrath a écrit :
>>> Is this an ICD? An implementation of libOpenCL.so.1?
>> It is the part, that is needed along with mesa to enable OpenCL
>> support on e.g. AMD GPUs, see [0]. It does not deliver a
>> libOpenCL.so.1
> The needed libOpenCL.so.1 is provided by mesa, when it is build with
> OpenCL support. Bug 717500 is a request to add that support to the
> Debian package of mesa.

  I did not check at the OpenCL implementation by mesa.
But, for the record, if mesa provides an OpenCL implementation,
it needs to do it by providing an ICD, and not the libOpenCL.so.1
library.
  The libOpenCL.so.1 must be a ICD Loader in order to allow the
co-installation of several OpenCL implementations. There exists
several implementation for the ICD Loader. There even is
ocl-icd packaged in main that is a free implementation...

  Best regards,
Vincent

>> Best regards,
>> Julian
>>
>> [0] http://dri.freedesktop.org/wiki/GalliumCompute/
> 
> 


-- 
Vincent Danjean  Adresse: Laboratoire LIG - Bât. INRIA Rhône-Alpes
Téléphone:  +33 4 76 61 55 10655 avenue de l'Europe
Fax:+33 4 76 61 52 52Montbonnot Saint Martin
Email: vincent.danj...@imag.fr   38334 Saint-Ismier cedex


-- 
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/5224fbe6.9060...@free.fr



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

2013-09-02 Thread Philipp Kern
On Mon, Sep 02, 2013 at 11:27:33AM +0200, Tollef Fog Heen wrote:
> ]] Luca Filipozzi 
> > On Sat, Aug 31, 2013 at 12:40:08AM +0200, Michael Stapelberg wrote:
> > > Luca Filipozzi  writes:
> > > > Why do you say that when you haven't even asked?
> > > Because I thought the answer was going to be “not in the Linux kernel,
> > > no chance”.
> > We also run kfreebsd, with some challenge, but we have it.
> It's not really an option for codesearch since codesearch needs systemd,
> though.

Also I'm not sure how ZFS would solve the basic constraints of hardware
and be a magic bullet. The index can already be compressed in the application
layer. Deduplication adds the need to use a lot of RAM for the dedup tables.
The L2ARC of ZFS is commonly put on SSDs we don't have. So it'd basically yield
the need to add a lot of RAM to the VM for a reasonably sized ZFS in-memory
cache and the dedup tables for probably not much gain in avoided seeks (if git
delta dedup doesn't even find that much, why would block-level debug work
better). It's not that it wasn't proposed to instead throw RAM onto more page
cache (which could yield similar savings), which was equally considered a bad
choice.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature


Bug#671744: ITP: rutorrent -- a web front-end for the rtorrent client

2013-09-02 Thread Simone
Package: wnpp
Followup-For: Bug #671744
Owner: Simone 

I'd like to step in to the packaging of rutorrent.
The version i'm packaging is now 3.5, instead of the 3.4 that was reported by
the previous owner.


-- 
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/20130902191624.15548.41644.report...@hulk.marvel.lan



Bug#721653: ITP: ssm -- macromolecular superposition library

2013-09-02 Thread Picca Frédéric-Emmanuel
Package: wnpp
Severity: wishlist
Owner: "Picca Frédéric-Emmanuel" 

* Package name: ssm
  Version : 1.3
  Upstream Author : E. Krissinel 
* URL : http://www.ccp4.ac.uk/
* License : (LGPL-2.1)
  Programming Lang: (C++)
  Description : macromolecular superposition library

 SSM is a macromolecular coordinate superposition library, written by
 Eugene Krissinel of the EBI.
 .
 The library implements the SSM algorithm of protein structure
 comparison in three dimensions, which includes an original procedure
 of matching graphs built on the protein's secondary-structure
 elements, followed by an iterative three-dimensional alignment of
 protein backbone Calpha atoms.
 .
 The algorithm implemented by the software is described in:
 E. Krissinel & K. Henrick (2004) Secondary-structure matching (SSM), a
 new tool for fast protein structure alignment in three dimensions.
 Acta Crystallogr D Biol Crystallogr. 60, 2256-68.


-- 
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/20130902185447.6966.82641.reportbug@mordor



Re: Nitpicking in the NEW queue.

2013-09-02 Thread Paul Tagliamonte
On Tue, Sep 03, 2013 at 12:47:02AM +0800, Thomas Goirand wrote:
> On 09/02/2013 07:38 PM, John Paul Adrian Glaubitz wrote:
> > Adding to this. I know Paul personally very well and I don't think that
> > he'd maliciously reject a package.
> 
> I don't think so either.
> 
> Though what happens is that Charles is being frustrated because of the
> current waiting time in the NEW queue (and it clearly shows in his
> mail). If it was like before November 2012 (eg: less than a week for a
> review), then it wouldn't happen, IMO.
> 
> I've been very happy to see that there was more people accepted in the
> team in order to help solving this problem. Let's just hope that it will
> work out better in the near future, and reduce the frustration of
> everyone facing issues with the current delay. The graph of the NEW
> package count shows there's an ongoing effort for this.

Yes. For the record, this day when Charles sent this mail, I was working
in NEW from early in the morning to about 9:00 at night. I don't want
thanks or even for people to care about such things, but to come home
from the bar to such an email is annoying and makes me want to review
NEW less.

The package count went from over 300 on Friday to under 180 this mornig
(I saw some processing by other ftpteam members too, so that wasn't just
me).

This is being worked on, and the ftpteam is working hard to review
packages in a timely way.

> BTW, we always know who rejects a package. Though it'd be nice to also
> know in the ACCEPTED message who did it (for example we could send
> thanks for the work of reviewing an upload). Has the FTP master team
> thought about that? Or is there reasons why you want to stay anonymous?
> (or perhaps nobody has time to work on that futile feature?)

I don't mind staying anonymous, none of us are doing this to get rich or
famous, we're just here to make sure the archive stays safe & sane.

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

Cheers,
  Paul

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


signature.asc
Description: Digital signature


Re: Nitpicking in the NEW queue.

2013-09-02 Thread Thomas Goirand
On 09/02/2013 07:38 PM, John Paul Adrian Glaubitz wrote:
> Adding to this. I know Paul personally very well and I don't think that
> he'd maliciously reject a package.

I don't think so either.

Though what happens is that Charles is being frustrated because of the
current waiting time in the NEW queue (and it clearly shows in his
mail). If it was like before November 2012 (eg: less than a week for a
review), then it wouldn't happen, IMO.

I've been very happy to see that there was more people accepted in the
team in order to help solving this problem. Let's just hope that it will
work out better in the near future, and reduce the frustration of
everyone facing issues with the current delay. The graph of the NEW
package count shows there's an ongoing effort for this.

BTW, we always know who rejects a package. Though it'd be nice to also
know in the ACCEPTED message who did it (for example we could send
thanks for the work of reviewing an upload). Has the FTP master team
thought about that? Or is there reasons why you want to stay anonymous?
(or perhaps nobody has time to work on that futile feature?)

Thomas


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



Re: DSA, kFreeBSD, and the Singularity

2013-09-02 Thread Gergely Nagy
Peter Palfrader  writes:

> On Sun, 01 Sep 2013, Steven Chamberlain wrote:
>
>> 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.
>
> syslog-ng on kfreebsd doesn't properly reconnect to logservers after
> they went a way for a while or the network dropped.
>
> Would be nice if that could be fixed.

I'd be happy to fix, if there's a bug filed (if there is one, and I
didn't notice, apologies!). The problem should be fixed in later
upstream versions, but I have not had the chance to test it yet, and we
need to upload something more recent anyway. This will happen Real Soon
Now(tm).

But if there's a bug filed, I can likely find and backport the fix to
wheezy too. (or provide a backport of the new syslog-ng upstream version
on backports.d.o)

-- 
|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/87li3f1gqj.fsf@algernon.balabit



Re: Nitpicking in the NEW queue.

2013-09-02 Thread Andreas Tille
Hi Paul,

On Mon, Sep 02, 2013 at 12:12:09AM -0400, Paul R. Tagliamonte wrote:
> > 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.

Please keep up with your helpful comments even when nitpicking!  While
lacking the full context (no quote of the original mail) I just can wild
guess that possibly a similar thing might have happened as it was some
time ago in one of my packages:  In the first place I was overlooking
the real problem which was mentioned in a short sentence after a more
verbose minor comment about spelling.

While I really like your comments it might perhaps cause less friction
(and avoid mails like those from Charles) when you would "tag" your mail
like:

  Rejection reason / major problem:
 ...

  Additional hint (not relevant for accepting):
 ...


or something like this.

Thanks for your work on the NEW queue

  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/20130902130338.gi21...@an3as.eu



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

2013-09-02 Thread Philipp Kern
On Sun, Sep 01, 2013 at 09:07:47PM +0100, Stephen Gran wrote:
> 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.

Fair point. My personal guess is that Solr's support for regex search
was not up to par at that point. codesearch is not about simple string
searching, but about regex as well, which was long something that wasn't
very performant because it couldn't be indexed efficiently.

The few bits I read up about Solr + regex seem to imply that your
indices somewhat explode in size (because it has to look at more context
than for simple strings), but that may or may not be true anymore.

Kind regards
Philipp Kern


-- 
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/20130902125357.ga10...@hub.kern.lc



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

2013-09-02 Thread Peter Palfrader
On Sun, 01 Sep 2013, Steven Chamberlain wrote:

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

syslog-ng on kfreebsd doesn't properly reconnect to logservers after
they went a way for a while or the network dropped.

Would be nice if that could be fixed.
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


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



Re: DSA, kFreeBSD, and the Singularity

2013-09-02 Thread Steven Chamberlain
On 02/09/13 13:16, Peter Palfrader wrote:
> syslog-ng on kfreebsd doesn't properly reconnect to logservers after
> they went a way for a while or the network dropped.

Was that on squeeze or wheezy?  The versions of syslog-ng are quite
different I think.

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/52248217.1000...@pyro.eu.org



Re: Nitpicking in the NEW queue.

2013-09-02 Thread John Paul Adrian Glaubitz

Hi!

On 09/02/2013 06:04 AM, Scott Kitterman wrote:

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.


I fully agree. I don't think it's a bad thing at all to thoroughly
check the package, even for minor problems. I do that myself when
sponsoring packages from mentors and I am very glad for the
hard work the FTP team does actually reviewing that huge list of
packages that is constantly in NEW and not just passing them
through.


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.


Yep, this is otherwise just an unbalanced, unreflected rant. If you want
to kick off a discussion, please let us actually know what the FTP
team's answer was.


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?


Absolutely. People who think that packages in NEW should just be passed
through and accepted into the archive haven't really understood the
point of the NEW queue.


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.


Adding to this. I know Paul personally very well and I don't think that
he'd maliciously reject a package. He takes his job as an FTP master
very seriously and I am pretty sure that he is also not leaving "cheap
comments" but rather suggestions to help improve the package and
get it into shape for the archive. If he rejects a package, there is
a very good reason why he did so and there is certainly also a
reasonable explanation that he provided.

Cheers,

Adrian

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


--
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/52247898.90...@physik.fu-berlin.de



Bug#721611: ITP: libjs-tinycon -- Library to manipulate the favicon by adding an alert bubble

2013-09-02 Thread Ben Armstrong
Package: wnpp
Severity: wishlist
Owner: Ben Armstrong 

* Package name: libjs-tinycon
  Version : 0.5
  Upstream Author : Tom Moor 
* URL : https://github.com/tommoor/tinycon
* License : MIT
  Programming Lang: Javascript
  Description : A small library to manipulate the favicon

Tinycon adds an alert bubble to the favicon containing a small amount of
text. It also supports numeric contents up to 2 digits, automatically
truncating using a metric suffix (k, M, G) when it gets too large to
fit.


-- 
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/20130902112734.29752.92174.reportbug@shade.edennet



Bug#721610: ITP: rutorrent -- a web front-end for the rtorrent client

2013-09-02 Thread Simone
Package: wnpp
Severity: wishlist
Owner: Simone 

* Package name: rutorrent
  Version : 3.5
  Upstream Author : Alexander Moskalets 
* URL : http://code.google.com/p/rutorrent/
* License : GPLv3
  Programming Lang: PHP
  Description : a web front-end for the rtorrent client

 ruTorrent is a web frontend for rtorrent designed to emulate the look and feel
of µTorrent WebUI so it's appearance is quite similar to the "parent". The
name "RuTorrent" is the combination of µTorrent and rTorrent.

 Features:
  * lightweight server side, so it can be installed on old and low-end servers
and even on some SOHO routers;
  * customizable - a bunch of plugins available including geoip, RSS feeds
support, cpu and disk monitoring, schedulers and others
  * nice look


-- 
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/20130902110713.4421.57237.report...@hulk.marvel.lan



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

2013-09-02 Thread Ian Jackson
Tollef Fog Heen writes ("Re: How git performs when you throw all of Debian at 
it"):
> ]] Luca Filipozzi 
> > We also run kfreebsd, with some challenge, but we have it.
> 
> It's not really an option for codesearch since codesearch needs systemd,
> though.

Why is that, JOOI ?

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



Bug#721604: ITP: python-troveclient -- Client for OpenStack Database as a Service

2013-09-02 Thread Thomas Goirand
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-troveclient
  Version : 0.3.0
  Upstream Author : Nick Vlku
* URL : https://pypi.python.org/pypi/TroveClient
* License : MIT
  Programming Lang: Python
  Description : Client for OpenStack Database as a Service

 Trove is Database as a Service for OpenStack. It's designed to run entirely on
 OpenStack, with the goal of allowing users to quickly and easily utilize the
 features of a relational database without the burden of handling complex
 administrative tasks. Cloud users and database administrators can provision
 and manage multiple database instances as needed.
 .
 The TroveClient lets you access Trove 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/20130902093248.22540.42020.report...@buzig.gplhost.com



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

2013-09-02 Thread Tollef Fog Heen
]] Luca Filipozzi 

> On Sat, Aug 31, 2013 at 12:40:08AM +0200, Michael Stapelberg wrote:
> > Luca Filipozzi  writes:
> > > Why do you say that when you haven't even asked?
> > Because I thought the answer was going to be “not in the Linux kernel,
> > no chance”.
> 
> We also run kfreebsd, with some challenge, but we have it.

It's not really an option for codesearch since codesearch needs systemd,
though.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gezefp6@qurzaw.varnish-software.com



Re: Less dinstall FTW?

2013-09-02 Thread Tollef Fog Heen
]] Kurt Roeckx 

> On Fri, Aug 30, 2013 at 09:13:59AM +0200, Tollef Fog Heen wrote:
> > > 
> > > I could see a *huge* load on this pool for this reason.
> > 
> > If so, so what?  We are not short of bandwidth and we do have contacts
> > and offers from CDNs which will make serving this Not A Problem(TM).
> 
> So should we take that as an official statement from DSA, and
> just do it?

Yes, you can take it as an official statement from DSA.  Whether we
should do it or not does not, AIUI, only depend on bandwidth, so not
commenting on that bit.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bo4befxr@qurzaw.varnish-software.com



Bug#721598: ITP: python-vcs -- Various version control systems management abstraction layer

2013-09-02 Thread Mike Gabriel
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: python-vcs
  Version : 0.4.0
  Upstream Author : Marcin Kuźmiński 
* URL : https://github.com/codeinn/vcs/
* License : Expat
  Programming Lang: Python
  Description : Various version control systems management abstraction layer

 Python vcs is an abstraction layer on top of various (Mercurial, Git, as extra
 backends: SVN, Bazaar) version control systems. It is designed as a
 feature-rich Python library with a clear API Reference.
 .
 Features
- Common API for SCM backends
- Fetching repositories data lazily
- Simple caching mechanism so we don’t hit repo too often
- In-memory commits API
- Command-line interface
 .
 Incoming
- Full working directories support
- Extra backends: Subversion, Bazaar


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



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

2013-09-02 Thread Luca Filipozzi
On Sun, Sep 01, 2013 at 09:49:30PM +0100, Steven Chamberlain wrote:
> 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?

http://dsa.debian.org/ports/kfreebsd/

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

We use ganeti (kvm) for virtualization.  Yes, better guest support would be
great.

More equivalency between linux and kfreebsd userland, at least as far as puppet
is concerned, would help.  For example, we like ferm, but ferm is iptables
only.

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

See above url with incomplete list.

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


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