Re: openresolv vs. resolvconf

2010-11-30 Thread Brian May
On 30 November 2010 22:57, Thomas Hood  wrote:
> An important advantage of openresolv could be that it isn't, like resolvconf, 
> undermaintained[1].  If openresolv is truly a drop-in replacement for 
> resolvconf then migration from resolvconf to openresolv would be one way of 
> solving this undermaintenance problem.

Do we really need two solutions for what appears to be the same
problem? Seems like it might be better to merge them or remove one.
Especially if one is under-maintained. This is one case I don't see
any advantage having two independent implementations.
-- 
Brian May 


--
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/aanlktin-y1ungnjn4hycoe-uvzdsf7ey8cu5mydrb...@mail.gmail.com



Bug#605530: ITP: libcgi-application-plugin-authentication-perl -- CGI::Application authentication module

2010-11-30 Thread Nicholas Bamber
Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber 


* Package name: libcgi-application-plugin-authentication-perl
  Version : 0.19
  Upstream Author : Nicholas Bamber 
* URL : 
http://search.cpan.org/dist/CGI-Application-Plugin-Authentication/
* License : Perl
  Programming Lang: Perl
  Description : CGI::Application authentication module

This module is already in libcgi-application-extra-plugin-bundle-perl.
However this is the largest module in that package and that is a large and
unwieldy package. However this package will still be a bundle
because it will include all the modules on CPAN that are within
the CGI::Application::Plugin::Authentication name space.
To faciliate this it will use the pkg-components tool and in fact will
be the first package to do so.
On account of the complexities inherent in trying to split up a large package
this package will initially be uploaded only to experimental.



-- 
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/20101130222930.11622.25751.report...@leonhartsberger.periapt



Bug#605522: ITP: libcgi-application-plugin-anytemplate-perl -- use any template system from within CGI::Application

2010-11-30 Thread Nicholas Bamber
Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber 


* Package name: libcgi-application-plugin-anytemplate-perl
  Version : 0.18
  Upstream Author : Michael Graham 
* URL : 
http://search.cpan.org/dist/CGI-Application-Plugin-AnyTemplate/
* License : Perl
  Programming Lang: Perl
  Description : use any template system from within CGI::Application

This module is already packaged in libcgi-application-extra-plugin-bundle-perl.
However that is a large and unwieldy package and this is one of the largest
modules in that package and would stand much better on its own. 
However on account of the complexity of splitting packages I will upload to
experimental only.



-- 
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/20101130221140.4900.46111.report...@leonhartsberger.periapt



Bug#605502: ITP: libspark-java -- Java package to draw sparklines

2010-11-30 Thread Andrew Ross
Package: wnpp
Severity: wishlist
Owner: Andrew Ross 


I plan to package the following, as it is a dependency of Gephi.

* Package name: libspark-java
  Version : 1.2
  Upstream Author : Larry Ogrodnek 
* URL : http://www.representqueens.com/spark/
* License : Apache
  Programming Lang: Java
  Description : Java package to draw sparklines

 Sparklines are intense, simple, wordlike graphics. They can 
 be used to convey information in line graph or barchart form 
 within a paragraph.



-- 
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/20101130202321.10040.81397.report...@dolomite



Bug#605492: ITP: fieldtrip -- toolbox for MEG and EEG analysis

2010-11-30 Thread Michael Hanke
Package: wnpp
Severity: wishlist
Owner: Michael Hanke 

* Package name: fieldtrip
  Version : 0.20101101
  Upstream Author : Donders Institute for Brain, Cognition and Behaviour
* URL : http://fieldtrip.fcdonders.nl
* License : GPL-2+
  Programming Lang: Matlab/Octave
  Description : toolbox for MEG and EEG analysis
 The software includes algorithms for simple and advanced analysis of MEG and
 EEG data, such as time-frequency analysis, source reconstruction using dipoles,
 distributed sources and beamformers and non-parametric statistical testing. It
 supports the data formats of all major MEG systems (CTF, Neuromag, BTi) and of
 the most popular EEG systems, and new formats can be added easily. FieldTrip
 contains high-level functions that you can use to construct your own analysis
 protocols in Matlab. Furthermore, it easily allows developers to incorporate
 low-level algorithms for new EEG/MEG analysis methods.


This software is distributed as a Matlab toolbox. However, the NIMH
distributes a “port” of fieldtrip to Octave (at
http://kurage.nimh.nih.gov/meglab/Meg/Software). It needs to be figured
out who did that, whether this port can be incorporated into the
official version, and to what degree it is complete.

Packaging fieldtrip is required to complete the packaging of SPM8
(#592390).



-- 
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/20101130162700.27581.69786.report...@meiner



Bug#605487: ITP: aac-tactics -- Coq tactics for reasoning modulo AC

2010-11-30 Thread Stéphane Glondu
Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu" 

* Package name: aac-tactics
  Version : 0.1
  Upstream Author : Thomas Braibant, Damien Pous
* URL : http://sardes.inrialpes.fr/~braibant/aac_tactics/
* License : LGPL-3+
  Programming Lang: OCaml, Coq
  Description : Coq tactics for reasoning modulo AC

 This Coq plugin provides tactics for rewriting universally quantified
 equations, modulo associative (and possibly commutative) operators.



-- 
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/20101130152432.10297.63734.report...@aspirine.inria.fr



openresolv vs. resolvconf

2010-11-30 Thread Thomas Hood
I am interested in how openresolv stacks up against resolvconf.

For starters the openresolv home page conveniently compares[0] openresolv with 
resolvconf.

> * Works with POSIX shell and userland

Nice.  Resolvconf requires bash.  But since resolvconf scripts are short, and 
bash is Essential in Debian, this doesn't seem like a major advantage.


> * Does not need awk, grep or sed which means we can work without /usr mounted

Resolvconf does not use awk.  It does use grep and sed but these aren't under 
/usr.  This is no accident: resolvconf was also designed to work without /usr 
mounted.


> * Works with other init systems than Debians' out of the box
> * Available as a 2 clause BSD license

Compatibility with non-Debian systems is an advantage if it has the result that 
most distros can standardize on one package.  Resolvconf has been ported to 
other distros and a quick Google search reveals that openresolv is available 
for several distros, but I don't know
what the adoption statuses of the packages are.

Resolvconf is GPL.


> * Prefer configs via IF_METRIC for dynamic ordering

Sounds like a good idea.  If two addresses are available, put the one available 
via a route with the lowest metric first in the nameserver list.  Resolvconf 
doesn't do this at present.


> * Configures zones for local resolvers other than libc

Resolvconf and openresolv are primarily middleware that mediate between 
interface configurers and name servers and resolvers.  Both can and do support 
alternative resolvers to the glibc resolver, via hook scripts.  Any hook 
scripts for one can presumably be ported quite
easily to the other and vice versa.


An important advantage of openresolv could be that it isn't, like resolvconf, 
undermaintained[1].  If openresolv is truly a drop-in replacement for 
resolvconf then migration from resolvconf to openresolv would be one way of 
solving this undermaintenance problem.


What further pros and cons do people see out there?


[0]http://roy.marples.name/projects/openresolv/wiki/OpenResolvReasons
[1]http://bugs.debian.org/477723
-- 
Thomas Hood


-- 
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/4cf4e6bf.7030...@gmail.com



Re: Bug#605009: serious performance regression with ext4

2010-11-30 Thread Mike Hommey
On Tue, Nov 30, 2010 at 10:35:11AM +0100, Samuel Thibault wrote:
> Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit :
> > On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote:
> > > > What's going on here?  sync_file_range() is a Linux specific system
> > > > call that has been around for a while.  It allows program to control
> > > > when writeback happens in a very low-level fashion.  The first set of
> > > > sync_file_range() system calls causes the system to start writing back
> > > > each file once it has finished being extracted.  It doesn't actually
> > > > wait for the write to finish; it just starts the writeback.
> > > 
> > > Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
> > > instead, skimming over the kernel source seems to indicate it might
> > > end up doing more or less the same thing but in a portable way?
> > 
> > On the other hand, there is no guarantee that other kernels do the same,
> 
> Err, that's posix.

Being posix doesn't guarantee that posix_fadvise(fd, 0, 0,
POSIX_FADV_DONTNEED) is going to start write back, which is the desired
effect, but not what you may actually get, depending on the kernel.

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/20101130103043.ga9...@glandium.org



Re: Bug#605009: serious performance regression with ext4

2010-11-30 Thread Bastian Blank
On Tue, Nov 30, 2010 at 10:35:11AM +0100, Samuel Thibault wrote:
> Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit :
> > On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote:
> > > Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
> > > instead, skimming over the kernel source seems to indicate it might
> > > end up doing more or less the same thing but in a portable way?
> > On the other hand, there is no guarantee that other kernels do the same,
> Err, that's posix.

What is POSIX? What exactly is written in the standard? Please quote.

Okay, here is the quote[1]:
| POSIX_FADV_DONTNEED
| Specifies that the application expects that it will not access the
| specified data in the near future.

sync_file_range is Linux-specific and documented to do exactly what we
want[2]. posix_fadvise with POSIX_FADV_DONTNEED is not documented to do
what we want but only does it as a side-effect (and may hurt others
because it evicts anything of the cache).

Bastian

[1]: http://www.opengroup.org/onlinepubs/9699919799/functions/posix_fadvise.html
[2]: fs/sync.c
-- 
"That unit is a woman."
"A mass of conflicting impulses."
-- Spock and Nomad, "The Changeling", stardate 3541.9


-- 
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/20101130102602.ga22...@wavehammer.waldi.eu.org



Re: Bug#605009: serious performance regression with ext4

2010-11-30 Thread Samuel Thibault
Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit :
> On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote:
> > > What's going on here?  sync_file_range() is a Linux specific system
> > > call that has been around for a while.  It allows program to control
> > > when writeback happens in a very low-level fashion.  The first set of
> > > sync_file_range() system calls causes the system to start writing back
> > > each file once it has finished being extracted.  It doesn't actually
> > > wait for the write to finish; it just starts the writeback.
> > 
> > Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
> > instead, skimming over the kernel source seems to indicate it might
> > end up doing more or less the same thing but in a portable way?
> 
> On the other hand, there is no guarantee that other kernels do the same,

Err, that's posix.

Samuel


-- 
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/20101130093511.ge9...@const.bordeaux.inria.fr



Re: Bug#605009: serious performance regression with ext4

2010-11-30 Thread Mike Hommey
On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote:
> > What's going on here?  sync_file_range() is a Linux specific system
> > call that has been around for a while.  It allows program to control
> > when writeback happens in a very low-level fashion.  The first set of
> > sync_file_range() system calls causes the system to start writing back
> > each file once it has finished being extracted.  It doesn't actually
> > wait for the write to finish; it just starts the writeback.
> 
> Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)
> instead, skimming over the kernel source seems to indicate it might
> end up doing more or less the same thing but in a portable way?

On the other hand, there is no guarantee that other kernels do the same,
nor that Linux will keep doing it in the future. Using sync_file_range
and possibly the corresponding BSD syscall seems a better solution.
(and apparently the assumption with fadvise doesn't work with xfs)

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/20101130090755.ga8...@glandium.org



Bug#605456: ITP: gotoblas2 -- GotoBLAS2 is on of the fastest implementations of the Basic Linear Algebra Subroutines.

2010-11-30 Thread Emmanuel QUEMENER
Package: wnpp
Severity: wishlist
Owner: Emmanuel QUEMENER 


* Package name: gotoblas2
  Version : 1.13
  Upstream Author : Emmanuel QUEMENER 
* URL : http://www.tacc.utexas.edu/tacc-projects/gotoblas2/
* License : BSD
  Programming Lang: C
  Description : GotoBLAS2 is on of the fastest implementations of the Basic 
Linear Algebra Subroutines.

The GotoBLAS codes are currently the fastest implementations of the Basic 
Linear Algebra Subroutines (formelly BLAS). Actually, GOTO is the developer's
last name and does not mean "go to." (Nor is it pronounced "go to"; the 
correct pronunciation is "goh-toe.")

The advantage is fast calculation. Note that the actual performance depends in
part on the code from which you call the GotoBLAS subroutine(s) and on the
combination of architecture and operating system under which you are running.
Your own tuning here can make a big difference.



-- 
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/20101130082757.12493.8717.report...@genie.home-sweet-home.zone



Re: next d-i meeting - 2010.12.01, 20h00 GMT

2010-11-30 Thread Christian PERRIER
Quoting Otavio Salvador (ota...@ossystems.com.br):
> On Mon, Nov 29, 2010 at 19:01, Miguel Figueiredo  wrote:
> > next Debian Installer meeting will take place on IRC, OFTC network, #debian-
> > boot, 2 weeks after previous meeting .
> > It is scheduled for next Wednesday - 2010.12.01, 20:00 UTC [1].
> 
> I am very sorry but I won't be able to participate on this meeting.
> 
> I have my "Graduation Thesis" on this day at 19:00 UTC so I won't be
> able to do it and come back to participate of the meeting on time.


I'm very unsure too...:-(




signature.asc
Description: Digital signature