Re: next d-i meeting - 2010.12.01, 20h00 GMT
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
Bug#605456: ITP: gotoblas2 -- GotoBLAS2 is on of the fastest implementations of the Basic Linear Algebra Subroutines.
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: Bug#605009: serious performance regression with ext4
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
Re: Bug#605009: serious performance regression with ext4
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
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
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
openresolv vs. resolvconf
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
Bug#605487: ITP: aac-tactics -- Coq tactics for reasoning modulo AC
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
Bug#605492: ITP: fieldtrip -- toolbox for MEG and EEG analysis
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#605502: ITP: libspark-java -- Java package to draw sparklines
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#605522: ITP: libcgi-application-plugin-anytemplate-perl -- use any template system from within CGI::Application
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#605530: ITP: libcgi-application-plugin-authentication-perl -- CGI::Application authentication module
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
Re: openresolv vs. resolvconf
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
