Bug#823396: ITP: beast2-mcmc -- Bayesian MCMC phylogenetic inference
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: beast2-mcmc Version : 2.4.1 Upstream Author : Alexei Drummond , Andrew Rambaut * URL : https://github.com/CompEvol/beast2 * License : LGPL Programming Lang: Java Description : Bayesian MCMC phylogenetic inference BEAST is a cross-platform program for Bayesian MCMC analysis of molecular sequences. It is entirely orientated towards rooted, time-measured phylogenies inferred using strict or relaxed molecular clock models. It can be used as a method of reconstructing phylogenies but is also a framework for testing evolutionary hypotheses without conditioning on a single tree topology. BEAST uses MCMC to average over tree space, so that each tree is weighted proportional to its posterior probability. Included is a simple to use user-interface program for setting up standard analyses and a suit of programs for analysing the results. . This is no new upstream version of beast-mcmc (1.x) but rather a rewritten version. Remark: This package will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/beast2-mcmc.git
Re: closing bugs against stable versions when a package is RMd from sid
Dear gregor (and others off-list), On Fri, Apr 29, 2016 at 12:17:36PM +0200, gregor herrmann wrote: > The BTS is version-aware and knows/displays that the bug still > affects the version in stable. I am aware that the BTS is version-aware, but where I have got confused is I was assuming that mailing XX-done is "the old way" and did not include version information. I've since discovered that the removed-package closure email does include a fake version in a pseudo-header, so the BTS version feature is being used after all. Thanks again
Re: Packaging of static libraries
* Jakub Wilk , 2016-04-14, 18:06: It would be helpful if we could check if a dynamic binary is linked to a static library from another package; but I'm not aware of any reliable method to implement such check. Maybe we could exploit the fact that static libraries are normally stripped, unlike the freshly built code. So if there's large amount of code that doesn't have corresponding debugging information in the -dbgsym package, it might be because the binary is linked to a static library. -- Jakub Wilk
Bug#823416: ITP: libjs-jquery-migrate -- Migrate older jQuery code to jQuery 1.9+
Package: wnpp Severity: wishlist Owner: "Jean-Michel Vourgère" * Package name: libjs-jquery-migrate Version : 1.2.1 Upstream Author : jQuery Foundation, Inc. and other contributors * URL : https://plugins.jquery.com/migrate/ * License : MIT Programming Lang: Javascript Description : Migrate older jQuery code to jQuery 1.9+ That small javascript library is already used by a few packages: dokuwiki: /usr/share/dokuwiki/lib/scripts/jquery/jquery-migrate.js dokuwiki: /usr/share/dokuwiki/lib/scripts/jquery/jquery-migrate.min.js dotclear: /usr/share/dotclear/web/admin/js/jquery/jquery-migrate-1.2.1.js galette: /usr/share/galette/includes/jquery/jquery-migrate-1.2.1.min.js moodle: /usr/share/moodle/lib/jquery/jquery-migrate-1.2.1.js moodle: /usr/share/moodle/lib/jquery/jquery-migrate-1.2.1.min.js opennebula-sunstone: /usr/share/opennebula-sunstone/public/vendor/4.0/jquery-migrate.min.js otrs2: /var/lib/otrs/httpd/htdocs/js/thirdparty/jquery-migrate-1.2.1/jquery-migrate.js owncloud: /usr/share/owncloud/core/js/jquery-migrate-1.2.1.js owncloud: /usr/share/owncloud/core/js/jquery-migrate-1.2.1.min.js python-xstatic-jquery-migrate: /usr/lib/python2.7/dist-packages/xstatic/pkg/jquery_migrate/data/jquery-migrate.js python-xstatic-jquery-migrate: /usr/lib/python2.7/dist-packages/xstatic/pkg/jquery_migrate/data/jquery-migrate.min.js wordpress: /usr/share/wordpress/wp-includes/js/jquery/jquery-migrate.js wordpress: /usr/share/wordpress/wp-includes/js/jquery/jquery-migrate.min.js
Bug#823425: ITP: chez-scheme -- Implementation of the R6RS Scheme language
Package: wnpp Owner: Barak A. Pearlmutter Severity: wishlist * Package name: chez-scheme Version : 9.4 Upstream Author : R. Kent Dybvig and others * URL or Web page : https://github.com/cisco/ChezScheme * License : Apache 2 Description : Implementation of the R6RS Scheme language Cisco has released Chez Scheme under a free license. All hail our new routing overlords.
EOL of fglrx-driver
Hello Debian community, I would like to announce the end of life of the non-free fglrx-driver in Debian! Before Ubuntu announced it, I'd like to remove it, but I know that still many people are using this driver package and after nearly 7 1/2 years maintainance it is not so easy to give it up.. But it has to be done, radeon and amgpu are on a good way and also developed by AMD itself! Many many thanks especially to Andreas Beckmann and Michael Gilbert for their maintainance in the pkg-fglrx team from me! I were very happy to work with both of you and to support you to become a DD :=) If nobody has got a better plan with the fglrx packages or something like that, I would fill a RM within the next weeks. Cheers
RE:EOL of fglrx-driver
Hello, first thanks for your hard work. I am using fglrx-driver for OpenCL on my W5100 and W7100 amd GPUs. Do you know if there will be a plan in order to support OpenCL on amd for strech ? Cheers Frederic
Re: using whiptail and translated strings from arbitrary scripts
Hi, On Wed, Apr 27, 2016 at 02:28:22PM +0200, Daniel Pocock wrote: > > > On 27/04/16 14:00, Antonio Terceiro wrote: > > On Tue, Apr 26, 2016 at 09:32:02PM +0200, Daniel Pocock wrote: > >> > >> It is well documented how developers should create po files for > >> i18n support in their debconf configuration questions during > >> package install[1]. > >> > >> What about arbitrary scripts that are run from the command line > >> and don't use debconf to store the user responses? How should > >> they interact with whiptail and translated strings? Is there > >> either a document explaining how to do this or any existing > >> script that provides a good example, in a way that makes it easy > >> for Debian translators to support the package containing the > >> script? > > > > the gettext documentation itself? > > > > https://www.gnu.org/software/gettext/manual/html_node/Preparing-Shell-Scripts.html > > > > All you need to do is make sure is that the installed package puts > > the compiled .mo files in the right location so gettext finds > > them. If you are looking for an example code, I have one for you as im-config (*). im-config is an i18n shell script with Gnome/KDE/dialog interface. Most asain localization tasks include this. https://packages.qa.debian.org/i/im-config.html http://anonscm.debian.org/cgit/collab-maint/im-config.git Oops. Aron added the new whiptail support. Time to package a new version :-) *) im-config is not run during the installation since it's configuration system sets the most reasonable choice as default. But user can change it via console/GUI. Osamu PS: If I had more time, I could have written it in Python to be nicer looking ... but the shell approach was simple and light by not introducing many dependencies.
Re: using whiptail and translated strings from arbitrary scripts
Hi, On Wed, Apr 27, 2016 at 02:29:19PM +, Bas Wijnen wrote: > Debian translators just translate packaging texts. Everything else is done by > upstream (which can be the same people, but it is not organized by Debian > AFAIK). I am not sure but my impression is that the i18n team seems to translate not only dbconf but upstream po files too. https://www.debian.org/international/ https://www.debian.org/international/l10n/po/rank https://www.debian.org/international/l10n/po/fr (and similar) As long as po files are organized in the normal place of the source tree and the package is rated interesting enough to be translated for i18n folks, you will get nice i18n bug reports with po files. I usually add such po files as debian changes when I get them and also forward such po files to the upstream. Osamu
