Bug#824716: ITP: mshr -- generates simplicial DOLFIN meshes in 2D and 3D
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: mshr Version : 1.6.0 Upstream Author : Benjamin Kehlet * URL : http://fenicsproject.org/ * License : GPL3+, LGPL Programming Lang: C++, Python Description : generates simplicial DOLFIN meshes in 2D and 3D mshr is the mesh generation component of FEniCS. It generates simplicial DOLFIN meshes in 2D and 3D from geometries described by Constructive Solid Geometry (CSG) or from surface files, utilizing CGAL and Tetgen as mesh generation backends. . Maintained by the Debian Science Team Upstream source: https://bitbucket.org/fenics-project/mshr Debian source: https://anonscm.debian.org/git/debian-science/packages/fenics/mshr.git/
Re: Debian i386 architecture now requires a 686-class processor
Ian Jackson writes: > IMO the way to read "is a bug RC" is "if the bug is not fixed, would > Debian be better without the package, than with the buggy package". > This calls for weighing the harm caused by the bug to the people > affected, against the benefit of the package to other users. > > In this case I think the class of affected users is big enough - and > there are generally enough alternatives - that the bug ought to be RC. > If the packages are removed from Debian, then those users will be > guided by our installation and package selection tools to other, > working, software. If we treated architectures in the same way, I wonder if we would have any architecture other than amd64... After all that will guide our users to other, working, architectures. (No, I don't find "let's just drop Qt/GNOME/X11/ncurses" a very useful approach and I don't think it is very productive to suggest to do so. More the opposite.) Ansgar
Re: Debian i386 architecture now requires a 686-class processor
Guillem Jover writes ("Re: Debian i386 architecture now requires a 686-class
processor"):
> On Wed, 2016-05-18 at 16:57:48 +, Sune Vuorela wrote:
> > On 2016-05-18, Julien Cristau wrote:
> > > Why aren't those bugs RC?
>
> That's indeed a good question! It would probably be best if a neutral
> party would do that. :)
I have an answer to the RC question. I'm not sure if I count as
neutral, now that I have posted my other message, but:
> > Either we give both users on old hardware a bad experience or all the
> > users on new hardware a bad experience.
This comment is a bit opaque, to me.
> I don't follow, as I mentioned on the bug report, the patches I
> proposed use the JIT if the CPU supports SSE2, otherwise they fallback
> to use the interpreter, so no bad experience for anyone (because I
> consider silent failure to run at all, way worse than possibly running
> but slowly). And I'd probably characterize i386 as being there precisely
> to support old hardware by definition.
IMO the way to read "is a bug RC" is "if the bug is not fixed, would
Debian be better without the package, than with the buggy package".
This calls for weighing the harm caused by the bug to the people
affected, against the benefit of the package to other users.
In this case I think the class of affected users is big enough - and
there are generally enough alternatives - that the bug ought to be RC.
If the packages are removed from Debian, then those users will be
guided by our installation and package selection tools to other,
working, software.
ISTM there is definitely room for disagreement on this tradeoff. I
guess these libraries may be dependencies for some programs which do
not have good alternatives, and of course imposing a UI change (by
switching to different programs) for a reason like this would be
rather poor.
So I hope that we can find a way to improve the technical situation
rather than escalating the disagreement to our slow-moving governance
arrangements (or, worse, ranting about it while everyone gets more
annoyed).
Thanks,
Ian.
Bug#824712: RFH: smokeping
Package: wnpp Severity: normal I need help maintaining the smokeping package. I do not really use it anymore and i'd be happy to help people to sponsor it. There's a bunch of obscure bugs all over the place, and while I think the package mostly works, it's just a wild guess since well, I'm not using it right now.
Bug#824692: ITP: amazon-dsstne -- deep scabale sparse tensor network engine
Package: wnpp
Severity: wishlist
Owner: Daniel Stender
* Package name: amazon-dsstne
Version : 0.0~git20160518.a6cbac6
Upstream Author : Cheng-Yu Hsu
* URL : https://github.com/amznlabs/amazon-dsstne
* License : Apache-2.0
Programming Lang: C++
Description : deep scabale sparse tensor network engine
DSSTNE ("Destiny") is Amazon's own deep learning tool for training and deploying
deep (multi layered) neural networks for building machine learning models,
recently
published under a free license. The main characteristics are support of
multi-GPU
acceleration, large layers and being effective on sparse data sets. It uses
NetCDF
data format, converters are included.
It appears the needed deps are available yet instead of CUB. This depends on
the CUDA
Toolkit, so it is going into contrib.
Thanks,
DS
Re: Bug#824057: ITP: bitkeeper -- source code management system
On 12.05.2016 01:34, Ole Streicher wrote: > Jakub Wilk writes: >> I strongly recommend against packaging software you don't personally >> use. This never goes well. (I say this as someone who did this mistake >> in the past, multiple times.) > > I don't use most of my packages myself, and I don't think it was a > mistake to package them. The reason to package it was that I think they > are important to the community, and I feel competent enough to support > them. > > Cheers > > Ole It could be argued that Bitkeeper is only available to get freely used to a little time and more people have become the chance to get familiar with it, begin to use it for own private projects. But it turned out that packaging this is in fact a no-option, anyway. We've got a little deeper into the source tarball now working on if it could be packaged at least for experimental, but there are many problems (tries to update itself, passes unknown arguments to the command line), most significantly, it doesn't build with Tcl/TK, libtommath and libtomcrypt in the archive. As a matter of fact the revisions of libtommath and libtomcrypt which are still build on/shipped with are extremely outdated (10/6 years). So, I'm closing the ITP now. Cheers, DS -- 4096R/DF5182C8 http://www.danielstender.com/blog/
Re: Debian i386 architecture now requires a 686-class processor
Hi! On Wed, 2016-05-18 at 16:57:48 +, Sune Vuorela wrote: > On 2016-05-18, Julien Cristau wrote: > > Why aren't those bugs RC? That's indeed a good question! It would probably be best if a neutral party would do that. :) > Either we give both users on old hardware a bad experience or all the > users on new hardware a bad experience. I don't follow, as I mentioned on the bug report, the patches I proposed use the JIT if the CPU supports SSE2, otherwise they fallback to use the interpreter, so no bad experience for anyone (because I consider silent failure to run at all, way worse than possibly running but slowly). And I'd probably characterize i386 as being there precisely to support old hardware by definition. Regards, Guillem
Re: Debian i386 architecture now requires a 686-class processor
On 2016-05-18, Julien Cristau wrote: > Why aren't those bugs RC? Either we give both users on old hardware a bad experience or all the users on new hardware a bad experience. /Sune
Re: Debian i386 architecture now requires a 686-class processor
On Wed, May 18, 2016 at 02:41:51 +0200, Guillem Jover wrote: > Hi! > > On Tue, 2016-05-10 at 19:17:15 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > On Saturday 07 May 2016 13:23:30 Ben Hutchings wrote: > > > Last year it was decided to increase the minimum CPU features for the > > > i386 architecture to 686-class in the stretch release cycle. This > > > means dropping support for 586-class and hybrid 586/686 > > > processors[1].(Support for 486-class processors was dropped, somewhat > > > accidentally, in squeeze.) > > > > > > This was implemented in the Linux kernel packages starting with Linux > > > 4.3, which was uploaded to unstable in December last year. > > > > I guess the answer is "no", but just to be sure: does this means that i386 > > supported processors need to implement SSE2? > > I suppose this is related to unconditional SSE2 requirement in new Qt > libraries, (bugs #792594, #794739), for which I thought I had clarified > the conditions and for which I've provided patches already, but also for > which I'm not willing to sign the CLA. > > This means that Qt and any application using those specific bits, will > not run at all (silently) in Stretch on any AMD-based i386 CPUs, nor on > older Intel ones, which I'd assume is a pretty big percent of the i386 > park. > Why aren't those bugs RC? Cheers, Julien
Carrying downstream patches where bugfix submitter declines CLA
Guillem Jover writes ("Re: Debian i386 architecture now requires a 686-class
processor"):
> I suppose this is related to unconditional SSE2 requirement in new Qt
> libraries, (bugs #792594, #794739), for which I thought I had clarified
> the conditions and for which I've provided patches already, but also for
> which I'm not willing to sign the CLA.
I went and looked at the bug report for #792594. (Added to CC,
Subject line changed.)
AFAICT the objection from the maintainer is that they do not want to
do the work to forward-port the patch to new versions. But it seems
that Guillem is willing to do this work - and has indeed done it for
several versions.
To the QT maintainers: would you please reconsider applying this
patch, on the understanding that if it fails to apply you are of
course at liberty to drop it again, and reopen this bug (so that
Guillem and others know that the patch needs to be reworked) ?
That would avoid us having to have a big argument about what I think
is an important point of principle.
(Context:
I think Guillem is right not to want to sign the QT CLA. I wouldn't
sign that CLA either. I don't think Debian contributors should be
required to submit to such asymmetric licensing setups.
Software that Debian is not able to modify without submitting to
asymmetric licensing is not DFSG-Free. And by "able to modify" I mean
"able to modify, in practice, in the usual way".
Licensing should not be a barrier to proper development of the code by
Debian's contributors.
As a consequence I think that where a package's upstream insists on a
CLA we dislike, it is the responsibility of those who sponsor the
package's inclusion in Debian to carry, and forward port, good patches
which are provided by non-CLA-signing Debian contributors.
So IMO what I suggest above is actually quite a big compromise.)
> I think the same is affecting Chromium, which I'll need to fix too.
> I've got local packages for the Qt Declarative stuff which I could
> publish if there's demand.
Thanks for your work. I hope we can get it into Debian.
Thanks,
Ian.
Bug#824664: ITP: python-measurement -- unit-aware measurement objects
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-measurement Version : 1.8.0 Upstream Author : Adam Coddington * URL : https://github.com/coddingtonbear/python-measurement * License : Expat Programming Lang: Python Description : unit-aware measurement objects Easily use and manipulate unit-aware measurement objects in Python. . django.contrib.gis.measure has these wonderful Distance objects that can be used not only for storing a unit-aware distance measurement, but also for converting between different units and adding/subtracting these objects from one another. . This module not only provides those Distance and Area measurement objects (courtesy of Django), but also other measurements including Weight, Volume, and Temperature. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJXPICzAAoJEGlMre9Rx7W2T6IP/2Mhu86pd4jTMsSzWmqE9DE2 T4kWz4QTEYvfp8mpj5wk8xKPvlPFrOvK9b/Sq9mD6tf8zKur2Z12OfviypUx+5g+ 4fNLAtSVx6gWb+iVon9LFMYEvPqZ5iaMyKygXILhe9EhBOXnBIyjgBxJrnkTWI5j xW98A+YaxubbPFRH3og0NHzjwTM9KQ1omIrfvFznKBkwBmhz2W1NGP0quh17HHsS i9LW7Deg0DER3SB/dyHa/ZF+j3dKZ+nTrkEVcyaMWxN8CAQn5P26CuOdydTnKZJR gjwqAbxTA6t1pj2xi8LX7Ewna3wP2rnnCyzxKKBTKl8SfdI7xLPf+sqGjB4spwji /4y8gaNaJL7NM4zldxdkBh+mHSpOWkCd0OnbWXZyI51e4HrsKUxcxu2p+valMjV6 bSkE4RFNFWx6sBwleaFVDpCO7V0i/yFdJxJsc0MyclIE8Z5fCwmKGclH5o5H7mAi qa9uiR6Xdd4amkfOrwaahcnLviN42a+degwyNiyJkRRgkqzTt5fEJpgl6GgzcWCw TMQUu4956grst8MxrDwvZOdK+NOx+uapmA787Jz7BE82KvxibYp8GXG0QsA9BUcW n0IMp3sqV6cKkqJF3rxUORBWaCGvtD/Z1ElP2pYzpXzjdIx9WYe8hiBU81KzIB7v +kCfJLNcZAbIb7crVUaE =0fqZ -END PGP SIGNATURE-
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Hi! Iustin Pop writes: > - that bug seems to have been opened in the context of custom patches to > GCC, back in 2009-2012 > - the CTTE seems to have made an informal decision (see last update > #272) on that topic And most importantly - the tech-ctte primarily refused to override the maintainer. And the maintainer's primary objection was the patch not being upstream. Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer
Bug#824659: ITP: python-public -- @public decorator for adding names to __all__
Package: wnpp Severity: wishlist Owner: Barry Warsaw -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-public Version : 0.2 Upstream Author : Barry Warsaw * URL : https://pypi.python.org/pypi/atpublic * License : ASL2 Programming Lang: Python Description : @public decorator for adding names to __all__ I plan to maintain this package within the DPMT, although I will be the Maintainer and DPMT will be in Uploaders. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJXPHgEAAoJEBJutWOnSwa/ATAQAIv3xL2OvPQopDY5aLqQ1+hL Fwr43Rcr/MfSWUariNBBYaSi49TAEvuiWyjYBA/igoGjwcO9H18gDzBU0d53KADQ R+ifn2wQAFY+EPFEyIoSTLqFXnqkRALefM5KVkUZoOB1n6O6SQz7vkWqTqq0gpxm wGS57qu+CAHluQep5wjS10Aca6NWc0MTg+kneqIrThbSMZYAo/QkTeiEADeCvJK2 eq+Jug0AJc9vvTVDfq+WqcOzVnZ/vDkXjDDazdk+GC2jZHSdI8sIPYZGoll0OLIK ZlhYGufjlKLgt4iguFaqMDgrk7wpCohtMiqQ5HMjC5lSRPDPeBXTMkJKm9VHCBlJ e4bLEYXcTjiCll/vpFx8CGSIvNlTDT4kb7JkFnrOPlEblocozOsCl2HYWWg1xNHk sC/bEPeM6IhVJf7StesXaZRRI/oxZe8XqcRXwmMCfBF5Gjf5Riv9+9Ddwb2XigXw 9KkunjRyu7+v9Sgz7rRjk89VkOaE8syPoU0QXKZsYJ8k0wGM9t76ycjUjezog3Zl iKJZnbTmk7nnCufhEkLbQ7b6QpGmnzwb61jX9xrY0yuN14l+nMWR5rTkqhClmLlb 9/CUqPbhldBoDxeP2ARJ56V/z45TxoaogidyV8/URiHhlyAIL3Pcn3n0+XPr4tTw 7OBQSp21mUdvqLzOuiOR =GdOR -END PGP SIGNATURE-
