Bug#820854: ITP: fsm-lite -- frequency-based string mining (lite)
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: fsm-lite Version : 1.0 Upstream Author : Niko Välimäki * URL : https://github.com/nvalimak/fsm-lite * License : GPL Programming Lang: C Description : frequency-based string mining (lite) A singe-core implementation of frequency-based substring mining used in bioinformatics to extract substrings that discriminate two (or more) datasets inside high-throughput sequencing data. Remark: This package will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/fsm-lite.git
Bug #820811: ITP: python-fitsio -- Python wrapper on the CFITSIO library
Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org,debian-pyt...@lists.debian.org * Package name: python-fitsio Version : 0.9.8 Upstream Author : Eric Sheldon * URL : https://github.com/esheldon/fitsio * License : GPL-2+ Programming Lang: Python Description : Python library to read from and write to FITS files Fitsio is a Python wrapper on the CFITSIO library. It allows direct access to the columns of a FITS binary table which can be useful for reading large fits files. This package will maintained within the Debian Astronomy Working Group. A git repository will be created on alioth: https://anonscm.debian.org/cgit/debian-astro/packages/python-fitsio.git Best regards Ole
Re: Packaging of static libraries
Vincent Lefevre writes ("Re: Packaging of static libraries"):
> On 2016-04-12 14:52:33 +0100, Ian Jackson wrote:
> > I'm afraid that LTO is probably too dangerous to be used as a
> > substitute for static linking. See my comments in the recent LTO
> > thread here, where I referred to the problem of undefined behaviour,
> > and pointed at John Regehr's blog.
>
> This is not specific to LTO at all. Other form of optimization can
> yield "non-working" code (not expected by the developers).
Yes, indeed. But as I wrote before:
I worry that LTO will exacerbate this problem, by extending the
categories of technical non-compliance (with rules which are very
difficult to fully comply with) which are detected by compilers and
transformed into actual non-working code.
> Note that by default, shared libraries would still be used, so that
> this would affect only users with specific applications, who would
> want to optimize as much as possible.
This assumption, that someone using static libraries wants to
"optimizse as much as possible" (ie, that they would prefer a fast
non-working program to a slow working one) is completely unfounded.
> And code should also be tested with an UB sanitizer (which could
> possibly enabled by default in cases where it is shown that it does
> not slow things down[*]); this would allow one to detect most UB
> related bugs.
IMO we should be compiling almost all our code with what you are
calling `UB sanitisation' and what I would call `traditional
semantics'.
Ian.
Re: Packaging of static libraries
Adam Borowski writes ("Re: Packaging of static libraries"):
> On Tue, Apr 12, 2016 at 02:52:33PM +0100, Ian Jackson wrote:
> > I'm afraid that LTO is probably too dangerous to be used as a
> > substitute for static linking. See my comments in the recent LTO
> > thread here, where I referred to the problem of undefined behaviour,
> > and pointed at John Regehr's blog.
>
> LTO is no different from just concatenating all source files and making
> functions static. If your code blows after this, it is your fault not
> LTO's. LTO just allows interprocedural optimizations to work between
> functions that were originally in different source files.
This narrative of `fault' has two very serious problems.
Firstly, it is hopelessly impractical. As I have already observed
here:
Recently we have seen spectacular advances in compiler optimisation.
Spectacular in that large swathes of existing previously-working code
have been discovered, by diligent compilers, to be contrary to the
published C standard, and `optimised' into non-working machine code.
In fact, it turns out that there is practically no existing C code
which is correct according to said standards (including C compilers
themselves).
Real existing code does not conform to the rules now being enforced by
compilers. Indeed often it can be very hard to write new code which
does conform to the rules, even if you know what the rules are and
take great care.
Two examples showing how C has been turned into a puzzle language:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_event.c;h=02b39e6da8c65c033c99a22db4784de8d7aeeb7a;hb=HEAD#l458
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_internal.h;h=005fe538c6b5529447185797cc23d898c219e897;hb=HEAD#l294
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03340.html
http://lists.xenproject.org/archives/html/xen-devel/2015-11/threads.html#00112
The second problem is that it is based on the idea that the C
specification is by definition right and proper.
There are two ways to evaluate the the C specification's rightness and
properness.
The first is to ask what the the nominal remit of the C standards
bodies is. Well, it is and was to standardise existing practice.
Existing practice was to use C as a kind of portable assembler; the
programmer was traditionally entitled to do the kind of things which
are nowadays forbidden. So the C committee has failed at its
task. [1]
The second is to ask what is most useful. And there again the C
committee have clearly failed.
We in Debian are in a good position to defend our users from the
fallout from this problem. We could change our default compiler
options to favour safety, and provide more traditional semantics.
We would have influence upstream (for example to further advance the
set of available safety options) if we cared to use it. But sadly it
seems that the notion that our most basic and widely-used programming
language should be one that's fit for programming in is not yet fully
accepted.
At the very least we should fiercely resist any further broadening of
the scope of the C UB problem.
Sorry if I seem cross in this email. But that's because I am.
Thanks for listening.
Ian.
[1] Consider for example the divergence between the C89 rationale
http://www.lysator.liu.se/c/rat/a.html#1-1
and what C89 actually did (initially, only on paper, but now being
enforced by compilers).
Bug#820896: ITP: python-hashids -- Python implementation of hashids
Package: wnpp Severity: wishlist Owner: Edward Betts * Package name: python-hashids Version : 1.1.0 Upstream Author : David Aurelio * URL : https://github.com/davidaurelio/hashids-python * License : MIT Programming Lang: Python Description : Python implementation of hashids A python port of the JavaScript hashids implementation. It generates YouTube-like hashes from one or many numbers. Use hashids when you do not want to expose your database ids to the user. I plan to maintain this package as part of the Debian Python Modules Team. -- Edward.
Bug#820898: ITP: pyramid-multiauth -- An authentication policy for Pyramid that proxies to other authentication policies
Package: wnpp Severity: wishlist Owner: David Douard * Package name: pyramid-multiauth Version : 0.8.0 Upstream Author : Mozilla * URL : https://github.com/mozilla-services/pyramid_multiauth * License : MPL 2 Programming Lang: Python Description : An authentication policy for Pyramid that proxies to other authentication policies The pyramid_multiauth package provides MultiAuthenticationPolicy: a Pyramid authentication policy that proxies to a stack of other IAuthenticationPolicy objects, to provide a combined auth solution from individual pieces.
Re: Packaging of static libraries
On 2016-04-13 12:40:39 +0100, Ian Jackson wrote:
> Vincent Lefevre writes ("Re: Packaging of static libraries"):
> > Note that by default, shared libraries would still be used, so that
> > this would affect only users with specific applications, who would
> > want to optimize as much as possible.
>
> This assumption, that someone using static libraries wants to
> "optimizse as much as possible" (ie, that they would prefer a fast
> non-working program to a slow working one) is completely unfounded.
For libraries with a good testsuite (good coverage...) and checked
with an UB sanitizer, the program would be working. At least the
remaining bugs should not be related to UB.
> IMO we should be compiling almost all our code with what you are
> calling `UB sanitisation' and what I would call `traditional
> semantics'.
Yes, especially for software dealing with external data (e.g. web
browsers, mail software, etc.), but for computations that need to
run for weeks / months / years, full optimization is important
(after doing tests with UB sanitization).
--
Vincent Lefèvre - Web:
Re: Packaging of static libraries
On Apr 13, Ian Jackson wrote: > We in Debian are in a good position to defend our users from the > fallout from this problem. We could change our default compiler > options to favour safety, and provide more traditional semantics. Which would not solve any problem in this case, because then the HPC users will just not use Debian or use custom optimized builds. > We would have influence upstream (for example to further advance the > set of available safety options) if we cared to use it. But sadly it > seems that the notion that our most basic and widely-used programming > language should be one that's fit for programming in is not yet fully > accepted. While I believe that your campaign has a merit and I wish you best luck with it, providing useful software to users should be a more pressing concern for Debian. -- ciao, Marco signature.asc Description: PGP signature
Re: Packaging of static libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 13, 2016 at 05:17:54PM +0200, Marco d'Itri wrote: > On Apr 13, Ian Jackson wrote: > > We in Debian are in a good position to defend our users from the > > fallout from this problem. We could change our default compiler > > options to favour safety, and provide more traditional semantics. > Which would not solve any problem in this case, because then the HPC > users will just not use Debian or use custom optimized builds. If users have such specialized needs, I think it is not only reasonable that they build their own versions of their libraries; I expect them to prefer that. So we should make that as easy as possible. I can imagine that Gentoo also seems attractive to them, and it may be a good (or even better) solution. But as Debian, I think the best we can do to help them is to make it easy to build our packages from source with custom build flags. I'm guessing that we're probably talking less than 100 people in the world, maybe less than 10, that need this. It makes no sense to put a package in the archive just for them. And changing the default compiler settings to fit their needs makes even less sense. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJXDomkAAoJEJzRfVgHwHE6QfoP/R1gfb7vdZhPmICpevBc5/4O th5FSmNMb1W65gaVlOZlDhmIjoacL6Rgj0hJQuw7zMa7YUKE2O30/Hce+DPKaNiM OB7IEI5yywkyUUP5h9wMIXZP8LV+tsr9M77tgon+QBuJ2nURczvPqwtoKP/+/NEI PkzWnmbzixFaRPeBGQA76Iqn8/4YfhUN2aPTqDnVvZNCQyi9SxNLMbN/K5FYe8bB /vxx3tEfVDulPNeu0eHhx/n2lULJocCMiRWhkpyfGhMPtV+NkjYPI9hNpdhPIbIn MIqYP3rF9BIfabL9aLlcY/8FxlH/DmwR5cSzt9PtKLd0hL1mBRZ5+ef/L8QbkK/r 6nZDPh5/AYjnFXfZ5YJIj8+op2MCxQlcKnStvIAsXbC120mgxAOpERfWn+/j4QBQ g3NSoLqgWb0Eoo15TvtrQGHeHCtuE0o/vRECq4QGVFaD2pgaMfvFsM7ZRU6TR7El ilBqY4Ri/ct8msxAQ1NQLTsbzm9p2Dc9NnupiugT3or0OPRt4HDg7PO1xEZps4pV tjA49GKD9dqmHtZUSpV7nsaa+40KQzOQxqNtbi+6fryB3UgTColBjlVp5fcXBzYZ zD7zy5GN7LZimxYV8NeM92y9zcbS+CHMdTPayqeW2vH6MYUIAv6zDHijxpF67fld ZTNHMlLur4tFUWTrwtkg =atJe -END PGP SIGNATURE-
Re: ask github to encourage signed git tags
Hi Thomas, On 21 August 2015 at 04:51, Thomas Koch wrote: > Hi, > > we want upstream to sign releases. Nowadays a lot of software is on github and > a release is just a git tag. - An unsigned git tag ... :-( > > Github has a site that shows tags[1] but it does not give any indication > whether the tag is signed or not. > [1] e.g. https://github.com/Flameeyes/unpaper/tags > > Github should add visual feedback on this tags page: grey for unsigned, yellow > for signed and green for signed and connected to the web-of-trust. Next to a > grey or yellow tag there should be links to help texts. Looks like they answered your request. Since last week GitHub now shows[1] whether commits or tags are signed. They didn't followed your color scheme, as the signatures are verified against the public key configured in your profile (and then marked as green) and not a web-of-trust. On 21 August 2015 at 05:10, Timo Weingärtner wrote: > While I think signed tags are enough, many things rely on signed tarballs. > github should thus also allow uploading signatures for the tarball generated > from the (signed) tags and provide instructions for how to generate the > tarballs yourself. This feature went missing. The help section regarding GPG[2] doesn't say anything about uploading tarball signatures. Unfortunately, this is the part that would interest Debian most. Regards, Tiago. [1]: https://github.com/blog/2144-gpg-signature-verification [2]: https://help.github.com/categories/gpg/ -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: ask github to encourage signed git tags
On 13 April 2016 at 21:17, Tiago Ilieve wrote: > This feature went missing. The help section regarding GPG[2] doesn't > say anything about uploading tarball signatures. Unfortunately, this > is the part that would interest Debian most. Actually the possibility of attaching a tarball signature exists for a while[1]. Found it less than five minutes after sending this message. :-) [1]: https://wiki.debian.org/Creating%20signed%20GitHub%20releases -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: ask github to encourage signed git tags
On Thu, Apr 14, 2016 at 8:23 AM, Tiago Ilieve wrote: > Actually the possibility of attaching a tarball signature exists for a > while[1]. Found it less than five minutes after sending this message. > :-) > > [1]: https://wiki.debian.org/Creating%20signed%20GitHub%20releases This relies on github either storing the tarballs forever (rather than regenerating from the git repo) or never changing their gzip and git archive implementations. -- bye, pabs https://wiki.debian.org/PaulWise
