Re: Bits from dpkg developers - dpkg 1.16.1
On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote: > Two hardening features are not enabled by default: PIE and bindnow. > If your package supports PIE, you might want to consider enabling it. > If the binaries are long running processes like daemons, and as such > the startup performance penalty of “bindnow” is acceptable, it might > be a good idea to enable it too but only if relro is in effect, > although another option might be to just define LD_BIND_NOW=1 on the > daemon's environment (for example in the init.d script), in which case > the sysadmin can always disable it, something that's not possible with > the build option. Just to be explicit, PIE tends to have small (<1%) performance hits on register-starved architectures (i386) in most cases, for for certain work loads (e.g. python) the hit is large (~15%). On architectures with plenty of registers (amd64) there's virtually no measurable performance hit that I've seen. If your package handles 3rd party data of any kind (renders, network daemons, file parsers, etc), I strongly recommend enabling PIE. And, if you enable PIE, please enable bindnow too. The start-up performance hit of bindnow isn't measurable on most architectures. Some much slower ones can see problems (early ARM). It's possible that PIE and/or bindnow may be enabled by default for certain architectures in the future. If your package is using hardening-wrapper or hardening-includes, you were effectively using "+pie,+bindnow", so when converting, please continue to build with PIE and bindnow. :) Thanks! -Kees -- Kees Cook@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/20110928010154.gh6...@outflux.net
Re: Bug#601596: RFH: festival -- General multi-lingual speech synthesis system
The "forbidden" problem is now fixed. So I plan to chgrp packages soon. I'll use git to make easier migration keeping the history. To have permissions, you should be added to tts group. For this, please request to be added. If you cannot git push anymore, it's because perm will have been changed. So don't worry, only request, you'll be added quickly. Regards, Jean-Philippe MENGUAL Le vendredi 09 septembre 2011 à 17:06 +0200, Jean-Philippe MENGUAL a écrit : > Le vendredi 09 septembre 2011 à 20:03 +0800, YunQiang Su a écrit : > > On Mon, Aug 15, 2011 at 11:03 AM, Kumar Appaiah > > wrote: > > > On Mon, Aug 15, 2011 at 09:33:50AM +0800, YunQiang Su wrote: > > >> Would you found a TTS team? > > >> and invite all TTS packager to join it? > > > > > > This would be the ideal solution. I'd love it for people interested to > > > come forward in this effort. > > > > > done ? > > I'm going to create the team in a few days, as noone in Debian is opposed to > it. It'll contain at least festival and speech-tools. Then it'll be needed to > contact the various maintainers of speech synthetisers to tell them the group > exists and invite them. To know them, only aptitude show and aptitude search > can help, it's very fastidious (that's why I cannot do this immediately). But > you can start sending a message if you want to some maintainers. > > Regards, > > - > Jean-Philippe MENGUAL > > accelibreinfo, votre partenaire en informatique adaptée aux déficients visuels > > Tél.: 06.76.34.93.37 > > Mail: mengualjean...@free.fr > > Site Web: http://www.accelibreinfo.eu > > > signature.asc Description: Ceci est une partie de message numériquement signée
Bug#643595: ITP: snes9x -- Cross-platform SNES emulator
Package: wnpp Severity: wishlist Owner: Michael Moorman * Package name: snes9x Version : 1.53 Upstream Author : Gary Henderson * URL : http://www.snes9x.com * License : Other Programming Lang: C++ Description : Cross-platform SNES emulator The old snes9x package was removed (#617588) due to being orphaned, and not being updated in over a year. However, a new upstream release has appeared since then and I have begun packaging it. The package seems to be non-free, and was listed in non-free previously. The current free alternative in Debian is zsnes, but zsnes is also out-of-date and furthermore is i386 only, whereas snes9x does not have this problem. -- 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/20110927213220.7627.21308.reportbug@localhost6.localdomain6
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
On 09/27/2011 06:39 PM, Alessandro Ghedini wrote: > On Tue, Sep 27, 2011 at 05:24:16PM +0100, Allison Randal wrote: > Quoting from the nqp README: >> is focused on being a high-level way to create compilers and libraries >> for virtual machines (such as the Parrot Virtual Machine) > > It doesn't really sound as intended *only* for Parrot (ok, as of now it > does support only parrot, but in the future this may change). The project leads have the intention to port it to other VMs. But, if/when they do, the packaging will need to distinguish between the libraries for Parrot and the libraries for other languages. Maybe the solution is a source package named nqp, with different binary packages libparrot-nqp, libmono-nqp, etc... It's worth talking to Patrick about his plans. > Also, aren't parrot-nqp and nqp different things? (parrot-nqp is currently > used to build nqp). NQP has been through several major refactors. This is just the latest one. It's a bootstrapping compiler, so using a version of itself to build itself is normal. Allison -- 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/4e823e47.3020...@lohutok.net
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
On Tue, Sep 27, 2011 at 01:17:10PM -0500, Peter Samuelson wrote:
>
> [Alessandro Ghedini]
> > It doesn't really sound as intended *only* for Parrot (ok, as of now it
> > does support only parrot, but in the future this may change).
> >
> > Also, aren't parrot-nqp and nqp different things? (parrot-nqp is currently
> > used to build nqp).
>
> Are you saying one of them is nqp and the other is ... not-quite-nqp?
Uh? One of them is nqp and the other is parrot-nqp. I think the actual
name of the latter is nqp-rx [0] when not bundled with parrot.
>From the upstream README:
> Inside of a Parrot installation NQP-rx is known as C.
Cheers
[0] https://github.com/perl6/nqp-rx
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
--
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/20110927184704.ga26...@pc-ale.fastwebnet.it
Re: Bits from dpkg developers - dpkg 1.16.1
Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> things to be in a users environment, so a package's rules file should
> in my eyes not depend on them not being set or having any values sensible.
This tells us more about the reliability of your opinion than it does
about build systems. In general, upstream build systems cannot be
relied on do to anything sane or predictable if they are run with
these variables in the environment.
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/20098.4075.529503.254...@chiark.greenend.org.uk
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
[Alessandro Ghedini] > It doesn't really sound as intended *only* for Parrot (ok, as of now it > does support only parrot, but in the future this may change). > > Also, aren't parrot-nqp and nqp different things? (parrot-nqp is currently > used to build nqp). Are you saying one of them is nqp and the other is ... not-quite-nqp? -- 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/20110927181710.ga1...@p12n.org
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
On Tue, Sep 27, 2011 at 05:24:16PM +0100, Allison Randal wrote:
> On 09/27/2011 04:38 PM, Alessandro Ghedini wrote:
> > On Tue, Sep 27, 2011 at 04:04:00PM +0200, Dominique Dumont wrote:
> >> On Tuesday 27 September 2011 14:39:22 Alessandro Ghedini wrote:
> >>> * Package name: nqp
> >>
> >> This "nqp" name is a bit terse.
> >
> > That's how it's called. We have many three-letters-acronym packages and I
> > may be wrong, but "nqp" doesn't sound like a frequently used trio of
> > letters.
> >
> > Anyway, perl-nqp seems quite misleading (perl not quite perl??),
> > not-quite-perl, may be ok, but still, I'd rather use the upstream name if
> > possible.
>
> It seems like 'libparrot-nqp' or 'parrot-nqp' might be the best fit. NQP
> is a parsing/matching library, written for Parrot, intended to be used
> as part of the compiler tool chain for languages implemented on top of
> Parrot. Otherwise, 'libperl-nqp'.
Quoting from the nqp README:
> is focused on being a high-level way to create compilers and libraries
> for virtual machines (such as the Parrot Virtual Machine)
It doesn't really sound as intended *only* for Parrot (ok, as of now it
does support only parrot, but in the future this may change).
Also, aren't parrot-nqp and nqp different things? (parrot-nqp is currently
used to build nqp).
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
--
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/20110927173901.ga20...@pc-ale.fastwebnet.it
Re: Bits from dpkg developers - dpkg 1.16.1
* Bernd Zeimetz [110927 15:36]: > > I'm one of the submitters of one of the bugs which requested this > > change. This is a reversion of dpkg to a previous behaviour, and it > > /un/breaks packages. Or at least I think it unbreaks much more than > > it breaks. > > ACtually I think that is true - the exported *FLAGS broke various of the > packages I maintain, mainly due to LDFLAGS breaking the build of Python > extensions or other kinds of plugins. CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal things to be in a users environment, so a package's rules file should in my eyes not depend on them not being set or having any values sensible. So while I think dpkg-buildpackage not setting something there which could cause people to think using the environment in debian/rules for those is OK is better than dpkg-buildpackage setting them, I'd consider a dpkg-buildpackage that sets CFLAGS, CPPFLAGS and LDFLAGS all to "-fyour-rules-file-is-broken" even better. Bernhard R. Link -- 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/20110927163107.gd29...@server.brlink.eu
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
On 09/27/2011 04:38 PM, Alessandro Ghedini wrote: > On Tue, Sep 27, 2011 at 04:04:00PM +0200, Dominique Dumont wrote: >> On Tuesday 27 September 2011 14:39:22 Alessandro Ghedini wrote: >>> * Package name: nqp >> >> This "nqp" name is a bit terse. > > That's how it's called. We have many three-letters-acronym packages and I > may be wrong, but "nqp" doesn't sound like a frequently used trio of > letters. > > Anyway, perl-nqp seems quite misleading (perl not quite perl??), > not-quite-perl, may be ok, but still, I'd rather use the upstream name if > possible. It seems like 'libparrot-nqp' or 'parrot-nqp' might be the best fit. NQP is a parsing/matching library, written for Parrot, intended to be used as part of the compiler tool chain for languages implemented on top of Parrot. Otherwise, 'libperl-nqp'. The 'parrot-devel' package currently Provides 'parrot-nqp', which will have to change if NQP is moving out of the Parrot distribution into a separate distributed tarball and separate source package. Allison -- 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/4e81f8b0.4000...@lohutok.net
Bug#643566: RFP: python-fudge -- Fudge is a Python module for using fake objects (mocks and stubs) to test real ones.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: python-fudge Version: 1.0.3 Upstream Author: Kumar McMillan URL: http://farmdev.com/projects/fudge License: MIT/X Description: a python module for using fake objects to test real ones. . In readable Python code, you declare what methods are available on your fake and how they should be called. Then you inject that into your application and start testing. . This declarative approach means you don’t have to record and playback actions and you don’t have to inspect your fakes after running code. If the fake object was used incorrectly then you’ll see an informative exception message with a traceback that points to the culprit. -- 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/4e81f146.3020...@gmail.com
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
On Tue, Sep 27, 2011 at 04:04:00PM +0200, Dominique Dumont wrote:
> On Tuesday 27 September 2011 14:39:22 Alessandro Ghedini wrote:
> > * Package name: nqp
>
> This "nqp" name is a bit terse.
That's how it's called. We have many three-letters-acronym packages and I
may be wrong, but "nqp" doesn't sound like a frequently used trio of
letters.
Anyway, perl-nqp seems quite misleading (perl not quite perl??),
not-quite-perl, may be ok, but still, I'd rather use the upstream name if
possible.
Any thoughts?
Cheers
--
perl -E'$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
--
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/20110927153802.ga9...@pc-ale.fastwebnet.it
Re: Bug#643469: ITP: nqp -- Not Quite Perl compiler
On Tuesday 27 September 2011 14:39:22 Alessandro Ghedini wrote: > * Package name: nqp This "nqp" name is a bit terse. How about naming this package "perl-nqp" or, spell it out and name it "not- quite-perl" ? All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- 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/201109271604.01626@debian.org
Re: Bits from dpkg developers - dpkg 1.16.1
On 09/24/2011 05:48 PM, Ian Jackson wrote:
> Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
>> Raphael Hertzog wrote:
>>> * dpkg-buildpackage no longer exports
>>> CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
>>
>> | You don't know how many packages are broken or no longer
>> | policy compliant because they were relying on those environment
>> | variables
>>
>> Who said that? Oh, yeah it was you.
>>
>> How are we supposed to deal with packages that have been broken or made
>> policy incompliant by this change to dpkg?
>
> I'm one of the submitters of one of the bugs which requested this
> change. This is a reversion of dpkg to a previous behaviour, and it
> /un/breaks packages. Or at least I think it unbreaks much more than
> it breaks.
ACtually I think that is true - the exported *FLAGS broke various of the
packages I maintain, mainly due to LDFLAGS breaking the build of Python
extensions or other kinds of plugins.
--
Bernd ZeimetzDebian GNU/Linux Developer
http://bzed.dehttp://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
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/4e81ca91.1050...@debian.org
Bug#643469: ITP: nqp -- Not Quite Perl compiler
Package: wnpp Severity: wishlist Owner: Alessandro Ghedini * Package name: nqp Version : 0.1~2011.09 Upstream Author : The NQP Team * URL : https://github.com/perl6/nqp * License : Artistic-2.0 Programming Lang: C, Perl Description : Not Quite Perl compiler Not Quite Perl is a compiler for quickly generating PIR routines from Perl6-like code. The key feature of NQP is that it's designed to be a very small compiler (as compared with, say, perl6 or Rakudo) and is focused on being a high-level way to create compilers and libraries for virtual machines (such as the Parrot Virtual Machine). . Unlike a full-fledged implementation of Perl 6, NQP strives to have as small a runtime footprint as it can, while still providing a Perl 6 object model and regular expression engine for the virtual machine. Note that this is needed by the upcoming version of rakudo. Also, nqp needs parrot v3.8.0, yet to be packaged for Debian. -- 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/20110927123922.2238.4458.report...@pc-ale.fastwebnet.it
Re: Bits from dpkg developers - dpkg 1.16.1
I wrote:
> Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > My concern is that we now have a whole history of ill-considered changes
> > to the build flags. To the point that it's possible to argue that every
> > build flag change save one* has been ill-considered. So why are we
> > continuing to add interfaces where the build flags are changed
> > centrally/globally, with the same processes that have not worked before?
>
> In one sense, yes, we are providing a way to set these flags locally.
should read globally ^^^
> But the new mechanism will make it much easier to locally override
> such settings (where "locally" means either in the package, in the
> build 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/20097.48549.383313.265...@chiark.greenend.org.uk
Re: Bits from dpkg developers - dpkg 1.16.1
Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Ian Jackson wrote:
> > It was always completely wrong of dpkg-buildpackage to set these
> > variables. Source packages are entitled to assume that strange
> > environment variables which cause their tools to do odd things will
> > not be set.
>
> I'm willing to not worry about the likelihood that many packages added
> or updated over the past few years, while dpkg-buildpackage was forcing
> build flags, will not be built properly optimised now. That seems
> unlikely to completely break many of them, and as you say, forced build
> flags were always wrong, and we may just have to suck it up and deal
> with the breakage to get back to sanity.
Right. (Also those forced build flags would sometimes cause the build
to break entirely.)
> My concern is that we now have a whole history of ill-considered changes
> to the build flags. To the point that it's possible to argue that every
> build flag change save one* has been ill-considered. So why are we
> continuing to add interfaces where the build flags are changed
> centrally/globally, with the same processes that have not worked before?
In one sense, yes, we are providing a way to set these flags locally.
But the new mechanism will make it much easier to locally override
such settings (where "locally" means either in the package, in the
build environment).
> The build flags interface either needs some sort of compatability
> versioning, or the default build flags need to be specified in policy,
> and only changed with the same care we take with other policy changes
> that can make massive numbers of packages instabuggy.
I agree that we need a good process for testing default build flags
changes before propagating them. I'm not sure policy is the right
forum, but debian-devel is. Perhaps the policy should be that we
don't change the default flags without consultation here ?
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/20097.46611.997488.647...@chiark.greenend.org.uk
Bug#643329: ITP: hts-voice-nitech-jp-atr503-m001 -- HTS voice NIT ATR503 M001
Package: wnpp Severity: wishlist Owner: Koichi Akabe * Package name: hts-voice-nitech-jp-atr503-m001 Version : 1.04 Upstream Author : Keiichi Tokuda * URL : http://open-jtalk.sourceforge.net/ * License : Creative Commons Attribution 3.0 Description : HTS voice NIT ATR503 M001 HTS voice trained by using the Nitech Japanese Speech Database "NIT ATR503 M001" is released as a part of Open JTalk. This voice consists of HMMs trained by using HMM-based Speech Synthesis System (HTS) version 2.2. -- 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/20110927103226.12197.1092.reportbug@koichi-dynabook-CXE-47LE
Bug#643326: ITP: digraphtools -- Python library for working with directed acyclic graphs
Package: wnpp Severity: wishlist Owner: Steven McDonald -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: digraphtools Version : 0.2.1 Upstream Author : David Basden * URL : http://pypi.python.org/pypi/digraphtools * License : BSD Programming Lang: Python Description : Python library for working with directed acyclic graphs Some tools for working with directed acyclic graphs, partial orders and topological sorting with Python digraphtools was written as a lightweight way of using DAGs and partial ordering to represent, sort and traverse dependency trees. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/kFreeBSD) iQIcBAEBCAAGBQJOgZtVAAoJEKvd3sj2L+2w0l8P/2tHIKb0k3HocHrmXSirZfcS m6SihJeJT3RvHYIRNQSVlkcZhCjG0NZjJUksupf69mZwwqJQfIpKosFUoMBsjIXn u8OmncZ/u/LsHybOv+VE3r28eRLkC4yvcAgFkrwp9k3bFaJrEz40b/q7UHi/Rq0N tdAZTDnejNucAA9hkgdjVWHEPnuCRAznMgDfShMUYHz8cGP5kndac1Oz7wP8pi6M ZCIY4hRbvm47eKIGor0TAlbjUlFVKqz4DbVJJ3Fsc7mOhGz/cDHosmBoFhxxHCBb WxOaFkMIhjNRcATTRay3bwIG++IjZ/ysVTGzrKZHNssdJg7LmwCMvQ5O/u/MzORR wrWQ+QP+SwN00LT3kLBHeo1xWiL6atHI/SQCEhZ6OJaNedgk7ynUrio+Lr3DxaEQ uZq5jVehpou6o7NP2Ad4Exn9upEVMGwWnrUTruPqMjRQe+AU/h0WUwIoUoCXgBHW yHBUu2fWEEnhauUNw4gWK8dRps0LZkY4YIpCWAENawDqWbgpk2TT2v73yRUFhwVy 8EFhTSxbqAbibxpKK23ePTebxS3tZwACdWTwOZJ/czJhz9FC9hpMv1zN1U8qIcTC JGUb6L8n2jiugLh1ui+Q4EeXSXe9gDi7gYcn+rIzWnEttRVdSw81A1jIDJALXQ8F LXmo8Ay2gkirUUPKne/k =r1qV -END PGP SIGNATURE- -- 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/20110927094617.29786.91262.report...@luke.steven-mcdonald.id.au
[info] - The Arabianization of the Internet - news. September 24, 2011 - 1
Greetings, I trust all is well... What are the new revolutionary changes across the Arabic domain names and what role do they play on the Gulf markets and global e-commerce? Here are two interesting articles to provide an overview. Will you grow giant money-trees? http://www.bizcommunity.com/Article/196/82/62162.html The gTLD Metamorphosis http://www.adotas.com/2011/08/the-gtld-metamorphosis/ For a more informative and educational session join us in one of the Webinars. Here's the link to register. http://www.aarm.org/info_igtld.html Robert T. Stacey President - AARM roberttsta...@aarm.org ajo ___ If you have received this email in errror please accept my apologies. Insert removal in the subject line and email to remo...@aarm.org and I'll see that appropriate action is taken. To reach the AARM website <> -- 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/apufvb047u7gyjz6rhdw8szeajgp7zbbxpeku1chx...@aarm.org
Bug#643324: ITP: profphd -- secondary structure and solvent accessibility predictor
Package: wnpp Severity: wishlist Owner: Laszlo Kajan * Package name: profphd Version : 1.0.35 Upstream Author : Laszlo Kajan * URL : http://rostlab.org/ * License : GPL Programming Lang: Perl Description : secondary structure and solvent accessibility predictor Solvent accessibility is predicted by a neural network method rating at a correlation coefficient (correlation between experimentally observed and predicted relative solvent accessibility) of 0.54 cross-validated on a set of 238 globular proteins (Rost & Sander, Proteins, 1994, 20, 216-226; evaluation of accuracy). The output of the neural network codes for 10 states of relative accessibility. Expressed in units of the difference between prediction by homology modelling (best method) and prediction at random (worst method), PROFacc is some 26 percentage points superior to a comparable neural network using three output states (buried, intermediate, exposed) and using no information from multiple alignments. . Transmembrane helices in integral membrane proteins are predicted by a system of neural networks. The shortcoming of the network system is that often too long helices are predicted. These are cut by an empirical filter. The final prediction (Rost et al., Protein Science, 1995, 4, 521-533; evaluation of accuracy) has an expected per-residue accuracy of about 95%. The number of false positives, i.e., transmembrane helices predicted in globular proteins, is about 2%. . The neural network prediction of transmembrane helices (PHDhtm) is refined by a dynamic programming-like algorithm. This method resulted in correct predictions of all transmembrane helices for 89% of the 131 proteins used in a cross-validation test; more than 98% of the transmembrane helices were correctly predicted. The output of this method is used to predict topology, i.e., the orientation of the N-term with respect to the membrane. The expected accuracy of the topology prediction is > 86%. Prediction accuracy is higher than average for eukaryotic proteins and lower than average for prokaryotes. PHDtopology is more accurate than all other methods tested on identical data sets. -- 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/20110927092444.23496.83860.reportbug@n0d.rostclust
Bug#643323: ITP: profphd-utils -- profphd helper utilities convert_seq and filter_hssp
Package: wnpp Severity: wishlist Owner: Laszlo Kajan * Package name: profphd-utils Version : 1.0.7 Upstream Author : Laszlo Kajan * URL : http://rostlab.org/ * License : GPL Programming Lang: Fortran Description : profphd helper utilities convert_seq and filter_hssp The package provides the following binary utilities: convert_seq, filter_hssp. These are used by prof from the profphd package: a secondary structure, accessibility and transmembrane helix predictor from Burkhard Rost. -- 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/20110927091028.23047.72131.reportbug@n0d.rostclust
