Re: Lenny 5.05 and Squeeze
On Thu, Jun 24, 2010 at 04:38:31PM -0300, William F. wrote: > When comes Lenny 5.05 Cd and/or Debian Squeeze release?? The Lenny point release is planned for this coming weekend, 26th June 2010. See http://lists.debian.org/1276720762.11196.604.ca...@kaa.jungle.aubergine.my-net-space.net -- Jonathan Wiltshire 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: Improve support for installing 32-bit libraries on 64-bit systems
Hi Michael Tsang (and hi d...@l.d.o) 2010/6/24 Michael Tsang : > I have a recommendation for 32-bit libraries on 64-bit systems: > > Now, some libraries are available on 64-bit systems as lib32* but these are > very few. To improve this situation, I think that we can organise the library > packages as follows: Some problems with this approach are: a) we have multiple 32-bit architectures - i386, arm(el), mips(el), … and even hurd-i386 and kfreebsd-i386 so the naming is ambitious. a1) if you name the packages differently you need to add A LOT of alternatives depending on the architecture to the dependency lines. This not only complicates all these lines but make it also harder to insert new libraries and/or archs as they will slowly propagated in the pool. (Beside that i am not complete sure that an arch depending alternative option is even allowed currently: Depends: lib | lib32 [amd64 sparc64] ) a2) with a different name you avoid the file "conflicts" in at least /usr/share/doc/ - aka changelog, copyright and stuff -- but do they really differ for the same library which is just build for different architectures? So you have a lot of duplicates, right? b) a lot of "duplicated" packages are created: In which way will lib:i386 differ in your (and current) approach from lib32:amd64 expect of the name? c) These lib32, ia32, whatever42 packages tend to be a hell to maintain… (how big is the "source" of ia32-libs currently, 370 MB ? Just a library? *) d) what will happen with the release of a 96bit or 128bit architectures? > This should be implemented as a build template to make all library packages > use this organisation scheme. I think this should be implemented after the > release of Squeeze. If you look closer, MultiArch was at least for squeeze on the goal list. I guess it is pretty unlikely that we will make it, but i think it was more on the list to get a bit of noise and some progress - and some progress is visible. The biggest showstoppers are as far as i know that a) dpkg doesn't support it b) APT doesn't support it c) (not many) packages use it (last time i check ~24) c) is likely caused by a) and b) which in fact decreases the motivation for a) and b) to implement it as nobody use it… *** dependency loop detected *** But don't worry, Debian has found a victi… äh, i mean a volunteer to work on b) [0] - and the good thing is, you can even try and play with it already - you just need an apt/experimental build (, a bit of luck) and the right configuration options. See also README.MultiArch, but (yes, correct, shameless self-advertisement). Best regards, David Kalnischkies [0] http://wiki.debian.org/SummerOfCode2010/APT-MultiArch/DavidKalnischkies which is an accepted proposal and implements it according to the https://wiki.ubuntu.com/MultiarchSpec * yes, that are trick questions. -- 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/aanlktinjwuf_ptvymcwrulur2zjy2ie2knseddluv...@mail.gmail.com
add psl
add pls
Bug#587161: ITP: python-cogent -- framework for genomic biology
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-cogent Version : 1.4.1 * URL : http://pycogent.sourceforge.net/ * License : GPL Programming Lang: Python Description : framework for genomic biology PyCogent is a software library for genomic biology. It is a fully integrated and thoroughly tested framework for: controlling third-party applications; devising workflows; querying databases; conducting novel probabilistic analyses of biological sequence evolution; and generating publication quality graphics. It is distinguished by many unique built-in capabilities (such as true codon alignment) and the frequent addition of entirely new methods for the analysis of genomic data. -- 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/20100625161019.10872.46354.report...@moeller-desktop
Re: Essentiality of Bash
On Wed, 23 Jun 2010 16:58:58 +0200, Goswin von Brederlow wrote: >I think for that goal it would be good for lintian to add an exception >to the (build-)depends-on-essential-package-without-using-version check. >That does not mean that bash should stop being essential in Debian any >time soon. I have never understood that rule in the first place. Why am I not allowed to depend on an essential package, it's just clearer documentation, and doesn't hurt. What am I missing? 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/e1osfo5-0006hb...@swivel.zugschlus.de
Re: Essentiality of Bash
On Fri, Jun 25, 2010 at 10:20:33PM +0200, Marc Haber wrote: > On Wed, 23 Jun 2010 16:58:58 +0200, Goswin von Brederlow > wrote: > >I think for that goal it would be good for lintian to add an exception > >to the (build-)depends-on-essential-package-without-using-version check. > >That does not mean that bash should stop being essential in Debian any > >time soon. > I have never understood that rule in the first place. Why am I not > allowed to depend on an essential package, it's just clearer > documentation, and doesn't hurt. > What am I missing? The footnote to Policy 3.5, where this is written out? -- 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#587189: ITP: python-nast -- alignment of short DNA sequences
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-nast Version : 1.1 * URL : http://pynast.sf.net * License : GPL Programming Lang: Python Description : alignment of short DNA sequences The package provices a reimplementation of the Nearest Alignment Space Termination tool in python. It was prepared for next generation sequencers. . Given a set of sequences and a template alignment, PyNAST will align the input sequences against the template alignment, and return a multiple sequence alignment which contains the same number of positions (or columns) as the template alignment. This facilitates the analysis of new sequences in the context of existing alignments, and additional data derived from existing alignments such as phylogenetic trees. Because any protein or nucleic acid sequences and template alignments can be provided, PyNAST is not limited to the analysis of 16s rDNA sequences. . Since version 1.1, PyNAST no longer exactly matches the output of the origianl NAST program. Instead it focuses on getting better alignments. Users who wish to exactly match the results of NAST should download PyNAST 1.0. . PyNAST: a flexible tool for aligning sequences to a template alignment. J. Gregory Caporaso, Kyle Bittinger, Frederic D. Bushman, Todd Z. DeSantis, Gary L. Andersen, and Rob Knight. January 15, 2010, DOI 10.1093/bioinformatics/btp636. Bioinformatics 26: 266-267. -- 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/20100625224832.15386.66645.report...@toshiba.siemens
