Bug#727090: ITP: r-cran-dosefinding -- Planning and Analyzing Dose Finding experiments

2013-10-22 Thread Andreas Tille 
Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-dosefinding
  Version : 0.9-9-1
  Upstream Author : Bjoern Bornkamp, Jose Pinheiro, Frank Bretz
* URL : http://cran.r-project.org/web/packages/DoseFinding
* License : GPL
  Programming Lang: R
  Description : Planning and Analyzing Dose Finding experiments
 The DoseFinding GNU R package provides functions for the design and
 analysis of dose-finding experiments (with focus on pharmaceutical Phase
 II clinical trials). It provides functions for: multiple contrast tests,
 fitting non-linear dose-response models (using Bayesian and non-Bayesian
 estimation), calculating optimal designs and an implementation of the
 MCPMod methodology.


The package is maintained in Debian Med team and available in VCS at
  svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-dosefinding/trunk/

Remark: The source contains some RData files which are all documented
inside the according manuals.


-- 
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/20131022084109.10006.90337.report...@mail.an3as.eu

Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Ondřej Surý 
Hi,

there are now couple of quality DNS servers and most of their
maintainers have agreed that it might be useful to have a virtual
package that we can add to Provides: so it's easy to pick one DNS server
if one needs it.

The proposed names are:

authoritative-name-server - authoritative domain name server
recursive-name-server - recursive domain name server

Any objections?

I got +1 from bind9, powerdns, nsd3/4[*] and knot[*]. gdnsd maintainer
don't mind and Robert (unbound maintainer) is probably off-line, but I
doubt he would mind.

* - well, that's me
O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


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

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Jonathan Dowland 

At risk of coming across as a bikeshedder,

On Tue, Oct 22, 2013 at 03:43:03PM +0200, Ondřej Surý wrote:
> authoritative-name-server - authoritative domain name server
> recursive-name-server - recursive domain name server

Is there a need to distinguish between "name server" and "domain name
server"? (I'm just thinking of things like NSS, or directory servers
that serve names…) Is the acronym DNS sufficiently well understood? If
so, would the following address this issue:

authoritative-dns-server
recursive-dns-server


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131022135218.gg28...@bryant.redmars.org

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Simon McVittie 
On 22/10/13 14:43, Ondřej Surý wrote:
> The proposed names are:
> 
> authoritative-name-server - authoritative domain name server
> recursive-name-server - recursive domain name server
> 
> Any objections?

If you depend on one of these, what functionality can you rely on having
"out of the box"? What packages do you expect to benefit from having
these virtual packages to depend on?

For a recursive name server, is the expected functionality "it listens
on port 53, and will resolve DNS names without relying on any non-local,
non-authoritative DNS servers" or something?

For an authoritative name server, all I can think of is "listens on port
53 and does something" - or is there some portable location where
packages are expected to be able to put zone files, or what?

Are simple DNS forwarders like dnsmasq, which have simplistic
authoritative resolution for a LAN and pass the rest to an external
recursive nameserver, expected to provide a virtual package?

S


-- 
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/52668bb8.7040...@debian.org

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Ondřej Surý 
On Tue, Oct 22, 2013, at 16:29, Simon McVittie wrote:
> On 22/10/13 14:43, Ondřej Surý wrote:
> > The proposed names are:
> > 
> > authoritative-name-server - authoritative domain name server
> > recursive-name-server - recursive domain name server
> > 
> > Any objections?
> 
> If you depend on one of these, what functionality can you rely on having
> "out of the box"? What packages do you expect to benefit from having
> these virtual packages to depend on?

Break free from the technical aspect of resolving dependencies. The
virtual package name can be useful for people wanting to install
authoritative name server, so they get a list of package that provide
the functionality.

> For a recursive name server, is the expected functionality "it listens
> on port 53, and will resolve DNS names without relying on any non-local,
> non-authoritative DNS servers" or something?

As far as I know this works now with bind9 and unbound.

> For an authoritative name server, all I can think of is "listens on port
> 53 and does something" - or is there some portable location where
> packages are expected to be able to put zone files, or what?
> 
> Are simple DNS forwarders like dnsmasq, which have simplistic
> authoritative resolution for a LAN and pass the rest to an external
> recursive nameserver, expected to provide a virtual package?

I think that dnsmasq can provide recursive-name-server, even though I
think the usecases and userbases are different.

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


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

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Ondřej Surý 
On Tue, Oct 22, 2013, at 15:52, Jonathan Dowland wrote:
> 
> At risk of coming across as a bikeshedder,
> 
> On Tue, Oct 22, 2013 at 03:43:03PM +0200, Ondřej Surý wrote:
> > authoritative-name-server - authoritative domain name server
> > recursive-name-server - recursive domain name server
> 
> Is there a need to distinguish between "name server" and "domain name
> server"? (I'm just thinking of things like NSS, or directory servers
> that serve names…) Is the acronym DNS sufficiently well understood? If
> so, would the following address this issue:
> 
> authoritative-dns-server
> recursive-dns-server

I think that the terminology for (at least) authoritative name server is
quite clear:

https://en.wikipedia.org/wiki/Name_server

We might discuss whether recursive-name-server or caching-name-server
would be better match, but I think that not all recursive name server
has to be caching, but all caching name server has to be recursive. And
the IETF (at least the DNSSEC RFC) terminology uses "resolver" as the
term which is pretty close match to "recursive name server".

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


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

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Scott Kitterman 


"Ondřej Surý"  wrote:
>Hi,
>
>there are now couple of quality DNS servers and most of their
>maintainers have agreed that it might be useful to have a virtual
>package that we can add to Provides: so it's easy to pick one DNS
>server
>if one needs it.
>
>The proposed names are:
>
>authoritative-name-server - authoritative domain name server
>recursive-name-server - recursive domain name server
>
>Any objections?
>
>I got +1 from bind9, powerdns, nsd3/4[*] and knot[*]. gdnsd maintainer
>don't mind and Robert (unbound maintainer) is probably off-line, but I
>doubt he would mind.
>
>* - well, that's me
>O.

Should there be default-* too?

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/1b4e7799-0a2a-45fd-baf3-15a729635...@email.android.com

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Russ Allbery 
Ondřej Surý  writes:
> On Tue, Oct 22, 2013, at 16:29, Simon McVittie wrote:
>> On 22/10/13 14:43, Ondřej Surý wrote:

>>> The proposed names are:

>>> authoritative-name-server - authoritative domain name server
>>> recursive-name-server - recursive domain name server

>>> Any objections?

>> If you depend on one of these, what functionality can you rely on
>> having "out of the box"? What packages do you expect to benefit from
>> having these virtual packages to depend on?

> Break free from the technical aspect of resolving dependencies. The
> virtual package name can be useful for people wanting to install
> authoritative name server, so they get a list of package that provide
> the functionality.

I don't think that's a good idea for the authoritative DNS server.  That
sort of application seems better handled through debtags.

The purpose of a virtual package is to satisfy a dependency, which means
it needs to provide some piece of functionality via a standard interface
so that any package that depends (or recommends, etc.) on it knows that,
when it is installed, it can be used according to that interface.
mail-transport-agent is the canonical example, with the requirements of
that interface spelled out in Policy.

While I wouldn't want to reject any virtual package that isn't documented
in Policy, my ideal would be for any virtual package used across the
archive (as opposed to among a cooperating set of packages) to be able to
document the interface provided to the same level of formality that
mail-transport-agent is documented.

This is possible for recursive-name-server.  You can say that, if
installed, it provides a service on UDP (and TCP?  you should say, since
it has implications for what packages can provide this virtual package)
port 53 to at least localhost that's capable of resolving DNS names from
either (by default) the root DNS servers or from locally-configured roots.

However, an authoritative DNS server serves a zone, and the configuration
of that zone has to be part of the interface for a virtual package to be
meaningful.  The only reason I can think of for a package to depend on an
authoritative DNS server is if it needs to publish DNS names, and to do
that it needs to know where to put the zone files, which means that a
virtual package specification would require a standardized location and
format for zone files.  While you could do that if you wished, I think
that's going to be quite a lot of work and of dubious benefit,
particularly since I think packages that want to publish things in DNS are
rare and also a little dubious.  (If anything should stay under the
control of the local system administrator, it's the contents of their DNS
zone.)

Accordingly, I agree in theory with the virtual package for the recursive
DNS server, although it would be ideal if we could document the
specification in Policy at the same time.  But I don't think the virtual
package for an authoritative DNS server makes much sense.  If you just
want to make it easier for users to find an authoritative DNS server to
install, debtags seems like a reasonable solution to that problem.

-- 
Russ Allbery (r...@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/87wql5tiph@windlord.stanford.edu

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Arturo Borrero Gonzalez 
On 22 October 2013 15:43, Ondřej Surý  wrote:
> Hi,
>
> there are now couple of quality DNS servers and most of their
> maintainers have agreed that it might be useful to have a virtual
> package that we can add to Provides: so it's easy to pick one DNS server
> if one needs it.
>
> The proposed names are:
>
> authoritative-name-server - authoritative domain name server
> recursive-name-server - recursive domain name server
>

I think is a good idea. Some packages may suggest using a caching name
server (thats my case).

I would suggest: caching-name-server

-- 
Arturo Borrero González


--
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/CAOkSjBgEtawuahomt+k9dnd_q2yvqjmyobrgcs-yxreh...@mail.gmail.com

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Marc Haber 
On Tue, 22 Oct 2013 16:41:30 +0200, Ond?ej Surý 
wrote:
>We might discuss whether recursive-name-server or caching-name-server
>would be better match, but I think that not all recursive name server
>has to be caching, but all caching name server has to be recursive. And
>the IETF (at least the DNSSEC RFC) terminology uses "resolver" as the
>term which is pretty close match to "recursive name server".

Other literature recommends the name "full service resolver" to
distinguish from the "resolver" part of libc. The PowerDNS community,
OTOH, just says "recursor".

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1vyekq-0008pb...@swivel.zugschlus.de

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Russ Allbery 
Arturo Borrero Gonzalez  writes:
> On 22 October 2013 15:43, Ondřej Surý  wrote:

>> there are now couple of quality DNS servers and most of their
>> maintainers have agreed that it might be useful to have a virtual
>> package that we can add to Provides: so it's easy to pick one DNS
>> server if one needs it.

>> The proposed names are:

>> authoritative-name-server - authoritative domain name server
>> recursive-name-server - recursive domain name server

> I think is a good idea. Some packages may suggest using a caching name
> server (thats my case).

> I would suggest: caching-name-server

That's basically what a recursive-name-server is.  I don't think the
application should care whether it caches locally or not; that's up to the
local administrator.

-- 
Russ Allbery (r...@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/87hac9tgkt@windlord.stanford.edu

Re: Moving conf file from one package to another

2013-10-22 Thread Henrique de Moraes Holschuh 
On Tue, 22 Oct 2013, Ondřej Surý wrote:
> Also thanks for the *.maintscript, I have missed that the dh_installdeb
> can use it.

Yeah, it is pretty cool!

What I can't find is the information of the required versioned
build-dependency on debhelper itself (or debhelper compatibility level) to
ensure the package builds correctly :(

This is usually listed in the debhelper manpages, but in this case either
that detail was forgotten, or I am failing to look at the right place for
the information (other than hunting it down in the debhelper change logs, I
suppose).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20131022170310.ga...@khazad-dum.debian.net

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Henrique de Moraes Holschuh 
On Tue, 22 Oct 2013, Russ Allbery wrote:
> > I would suggest: caching-name-server
> 
> That's basically what a recursive-name-server is.  I don't think the
> application should care whether it caches locally or not; that's up to the
> local administrator.

Almost every recursive resolver does caching, to the point that anything
that needs a remote caching namerserver can expect it to just exist.
Usually, the worst you can expect is two levels: local-system -> crap SOHO
device DNS proxy -> DNS recursive server with caching.

When something actually bothers to specify that it wants a caching
name-server, it means a close-by (latency-wise) caching name-server, or an
exclusive caching nameserver.

Heck, mail clusters often need an hierarchy of a local high-performance
caching resolver per node AND a cluster-wide pair of full-blown
high-performance caching recursive resolvers and private authoritative
resolvers (for the RBL feeds).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20131022172329.gb...@khazad-dum.debian.net

Bug#727146: ITP: dooble -- WebKit based light browser

2013-10-22 Thread Richard Sellam 
Package: wnpp
Severity: wishlist
Owner: Richard Sellam 

* Package name: dooble
  Version : 1.45
  Upstream Author : Alexis Megas 
* URL : http://dooble.sourceforge.net
* License : GPL
  Programming Lang: C++
  Description : WebKit based light browser
 Dooble, a light browser created in qt to create a safe browsing environment.


-- 
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/20131022173529.5035.72762.reportbug@eeepc

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Octavio Alvarez 

On 22/10/13 09:18, Arturo Borrero Gonzalez wrote:

I would suggest: caching-name-server


*-dns-server would be better, as it is specific enough to avoid name 
collision in the future.



--
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/5266c0ef.1050...@alvarezp.ods.org

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Arturo Borrero Gonzalez 
On 22 October 2013 20:16, Octavio Alvarez  wrote:
> On 22/10/13 09:18, Arturo Borrero Gonzalez wrote:
>>
>> I would suggest: caching-name-server
>
>
> *-dns-server would be better, as it is specific enough to avoid name
> collision in the future.

Good point.

Thanks.
-- 
Arturo Borrero González


--
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/CAOkSjBifXZZasbJ07jEqCuDQC3LCFPBjX=QcscKYUj_=r+t...@mail.gmail.com

Bug#727158: ITP: node-cookie-signature -- Sign and unsign cookies using hmac - module for Node.js

2013-10-22 Thread Jérémy Lal 
Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-cookie-signature
  Version : 1.0.1
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/node-cookie-signature
* License : Expat
  Programming Lang: JavaScript
  Description : Sign and unsign cookies using hmac - module for Node.js

Small module to help signing and unsigning strings using hmac
signature with a secret.
It is used by connect middleware to secure session cookies.
.
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/20131022192529.9500.11167.reportbug@imac.chaumes

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

2013-10-22 Thread Steven Chamberlain 
Hi Niels,

This was quite interesting as it seems to tie in with some other
projects that are already being pursued...

On 21/10/13 16:42, Niels Thykier wrote:
> I would love for us to have an automated system to give us a
> "weather-report" on the toolchain for each architecture.  It would be
> nice both for us to see how ports are doing and for porters to spot and
> fix problems early.

That sounds a lot like the purpose of Jenkins[0], but I'm not sure if
it's exactly suitable.  It seems a little heavy, that someone could more
easily be able to script some cron jobs for a task than learn how to use it.

And Jenkins isn't available yet on all arches;  some ports may not have
hardware powerful enough to run it.  Maybe that doesn't matter - a
single Jenkins instance might be able to launch jobs via remote shells
to other boxes, running the actual test suite there, or maybe just to
fetch, analyse and report on the resulting log files.

Ideally I'd like to see a set of command-line scripts runnable either
from cron, or maybe someday by Jenkins jobs if someone wants to set that
up.  And packaged up for people to use at home!

[0]: http://jenkins.debian.net/

> Which implies "a set of packages" being "the current version of the
> overwhelming part of the archive" plus all of d-i.  However, that is not
> something you "just build", so having a smaller set as a basic test
> would probably be way more useful.  I am not aware of such a "basic test
> set", so feel free to propose one.

Some people have been trying to identify small sets of essential
packages already, in the context of bootstrapping an architecture[1].  I
wonder if that's likely to overlap with this?  It encompasses toolchain
and essential arch-specific packages.

I imagine a healthy port should be able to bootstrap itself with only
current package versions.  If this was being tested regularly it could
let porters know if circular dependencies are introduced, for example.

[1]: https://wiki.debian.org/DebianBootstrap#Toolchain

I would maybe take that a little further and say that a system is only
stable if it can bootstrap itself, install and boot into the resulting
system, and repeat the whole process again...

> I like the "toolchain nightly" thing as well. I don't think it is
> "required", but it sounds like the kind of thing that would help people
> spot issues sooner rather than later!

And this also ties in with the reproducible-builds project[2] (not sure
if you were hinting at that before).  The 'toolchain' is of particular
concern because the security of the whole system depends on it.
Differences in the output of builds needs to be avoided, or otherwise
explained.  It would help greatly if there were frequent builds
happening so we could see unexpected changes occurring.

[2]: https://wiki.debian.org/ReproducibleBuilds

So if something can make something that fulfills all the above goals it
would certainly be beneficial :)

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/5266df9d.9040...@pyro.eu.org

Bug#727169: RFP: lua-stdlib -- Standard Lua libraries

2013-10-22 Thread Axel Beckert 
Package: wnpp
Severity: wishlist

* Package name: lua-stdlib
  Version : v35
  Upstream Author : Reuben Thomas et al.
* URL or Web page : https://github.com/rrthomas/lua-stdlib
* License : MIT
  Description : Standard Lua libraries

Upstream description:

  This is a collection of Lua libraries for Lua 5.1 and 5.2. The
  libraries are copyright by their authors 2000-2013 (see the AUTHORS
  file for details), and released under the MIT license (the same
  license as Lua itself). There is no warranty.

  Stdlib has no prerequisites beyond a standard Lua system.

I maintain GNU Zile in Debian. Upstream currently works on a
reimplementation of Zile in Lua which seems to become "Zile 3".

This library seems to be a dependency for that rewrite.


-- 
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/877gd4uc63@c-crosser.deuxchevaux.org

Bug#727170: RFP: lua-alien -- Pure Lua extensions

2013-10-22 Thread Axel Beckert 
Package: wnpp
Severity: wishlist

* Package name: lua-alien
  Version : 0.7.0
  Upstream Author : Fabio Mascarenhas
* URL or Web page : http://mascarenhas.github.io/alien/
* License : MIT
  Description : Pure Lua extensions

Upstream description:

  Alien is a Foreign Function Interface (FFI) for Lua. An FFI lets you
  call functions in dynamic libraries (.so, .dylib, .dll, etc.) from Lua
  code without having to write, compile and link a C binding from the
  library to Lua. In other words, it lets you write extensions that call
  out to native code using just Lua.

I maintain GNU Zile in Debian. Upstream currently works on a
reimplementation of Zile in Lua which seems to become "Zile 3".

This library seems to be a dependency for that rewrite.


-- 
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/874n88ubvg@c-crosser.deuxchevaux.org

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

2013-10-22 Thread Stewart Smith 
Steven Chamberlain  writes:
> On 21/10/13 16:42, Niels Thykier wrote:
>> I would love for us to have an automated system to give us a
>> "weather-report" on the toolchain for each architecture.  It would be
>> nice both for us to see how ports are doing and for porters to spot and
>> fix problems early.
>
> That sounds a lot like the purpose of Jenkins[0], but I'm not sure if
> it's exactly suitable.  It seems a little heavy, that someone could more
> easily be able to script some cron jobs for a task than learn how to
> use it.

It's actually a pretty low barrier to entry, if you know what commands
you need to run, it's pretty easy to get started with jenkins (create
job, have it execute shell commands, write shell in box, hit build).

I'd say that it's about 10 times more likely you'll get it right in
Jenkins before you get it right in cron.

> And Jenkins isn't available yet on all arches;  some ports may not have
> hardware powerful enough to run it.  Maybe that doesn't matter - a
> single Jenkins instance might be able to launch jobs via remote shells
> to other boxes, running the actual test suite there, or maybe just to
> fetch, analyse and report on the resulting log files.

Jenkins can have slaves on remote hosts, via SSH. It runs a small java
app there, so as long as the arch has a JVM then you're pretty right.

-- 
Stewart Smith


pgpK9r2igtQxx.pgp
Description: PGP signature

Servidores Ilimitados para Correos Masivos

2013-10-22 Thread Su Empresa 

La mejor herramienta para aumentar sus ventas exponencialmente.

El mejor directorio empresarial con funciones adicionales como 
son:

- Servidores de envio masivo ilimitados con actualizaciones 
mensuales.
- Suites de software para la gestion y envio de sus campañas 
publicitarias.
- Soporte tecnico ilimitado.

Se incluyen mas de 10 millones de registros asi como 765 mil 
empresas
con datos adicionales actualizados a Octubre 2013.

Sin duda la mejor herramienta para dar a conocer su empresa o 
negocio.

Todos los detalles en el siguiente enlace: http://x.co/21WoD





Mensaje enviado a debian-devel@lists.debian.org En caso de no ser 
de su interes favor de reenviarlo a quien pueda interesarle.



--
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/20131023003142.d89e1b560b56f...@lists.debian.org

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

2013-10-22 Thread Geert Uytterhoeven 
On Wed, Oct 23, 2013 at 12:36 AM, Stewart Smith
 wrote:
> Jenkins can have slaves on remote hosts, via SSH. It runs a small java
> app there, so as long as the arch has a JVM then you're pretty right.

For whatever definition of small. I've seen it consuming 1 GiB of memory...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


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

Re: Two new DNS virtual packages (authoritative-name-server & recursive-name-server)

2013-10-22 Thread Ryan Hiebert 
On Tue, Oct 22, 2013 at 9:29 AM, Simon McVittie  wrote:
>
> If you depend on one of these, what functionality can you rely on having
> "out of the box"? What packages do you expect to benefit from having
> these virtual packages to depend on?

I'm wondering the same thing. In particular, I'm not convinced that a
definition as simple as "it's an authoritative dns server running on
port 53" is a useful enough interface for using as a package
dependancy.

Perhaps, for the authoritative server, if the requirement was
something that allowed the application to update the zones, perhaps
through dynamic updates on port 53.

Or even "has BIND zone files and provides a common command to run to
reload them". The command and files would have to be in a common
location instead of just in the package's /etc/ directory, and the
command would have to be a well-know command, similar to what the mail
server has in the 'sendmail' binary. Which all sounds like a pain to
attempt to standardize, so the already standard dynamic updates over
port 53 is probably better anyway...

Ryan


-- 
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/CABpHFHRppZMThNnYMk9QiGoF-7AkLkXbcYC_EZzi=sjktya...@mail.gmail.com