Bug#836844: fixed in eigen3 3.3.1-2
Sounds working fine - thanks -- __ thf - Thierry Fauck - tfa...@free.fr> /pubkey: 4096R/FCC181CE/ /fingerprint: 5CCF 6B82 DE4E E72A A40B B63E A153 BF4F FCC1 81CE/ -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Processed: librsl: diff for NMU version 1.43-1.1
Processing control commands: > tags 846436 + patch Bug #846436 [src:librsl] librsl: add libfl-dev to Build-Depends Added tag(s) patch. -- 846436: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846436 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#846436: librsl: diff for NMU version 1.43-1.1
Control: tags 846436 + patch Dear maintainer, I've prepared an NMU for librsl (versioned as 1.43-1.1). The diff is attached to this message. Regards. -- WBR, wRAR diff -Nru librsl-1.43/debian/changelog librsl-1.43/debian/changelog --- librsl-1.43/debian/changelog 2013-06-20 15:52:44.0 +0600 +++ librsl-1.43/debian/changelog 2017-01-03 14:27:17.0 +0500 @@ -1,3 +1,10 @@ +librsl (1.43-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add Build-Depends: libfl-dev (Closes: #846436). + + -- Andrey Rahmatullin Tue, 03 Jan 2017 14:27:17 +0500 + librsl (1.43-1) unstable; urgency=medium * New upstream release diff -Nru librsl-1.43/debian/control librsl-1.43/debian/control --- librsl-1.43/debian/control 2013-06-20 15:45:10.0 +0600 +++ librsl-1.43/debian/control 2017-01-03 14:27:17.0 +0500 @@ -2,7 +2,7 @@ Priority: extra Maintainer: Debian Science Maintainers Uploaders: Andy Spencer -Build-Depends: debhelper (>= 9), dh-autoreconf, libhdf4-dev, libjpeg-dev, flex +Build-Depends: debhelper (>= 9), dh-autoreconf, libhdf4-dev, libjpeg-dev, flex, libfl-dev Standards-Version: 3.9.4 Section: science Homepage: http://trmm-fc.gsfc.nasa.gov/trmm_gv/software/rsl/ signature.asc Description: PGP signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Processing of librsl_1.43-1.1_source.changes
librsl_1.43-1.1_source.changes uploaded successfully to localhost along with the files: librsl_1.43-1.1.dsc librsl_1.43-1.1.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org) -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
librsl_1.43-1.1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 03 Jan 2017 14:27:17 +0500 Source: librsl Binary: librsl1 librsl-dev librsl-doc Architecture: source Version: 1.43-1.1 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Andrey Rahmatullin Description: librsl-dev - Development files for RSL librsl-doc - HTML documentation for RSL librsl1- TRMM Radar Software Library Closes: 846436 Changes: librsl (1.43-1.1) unstable; urgency=medium . * Non-maintainer upload. * Add Build-Depends: libfl-dev (Closes: #846436). Checksums-Sha1: ba09308585a6601ad7d062c1297882b22736b18e 2108 librsl_1.43-1.1.dsc 74505d0a1b0fb27e16cb732cccda0800782bb669 7492 librsl_1.43-1.1.debian.tar.xz Checksums-Sha256: 2ec8f4c5d234ce354a9fbf662067f85de0bc9978cacc03631d7bbebc466c5f16 2108 librsl_1.43-1.1.dsc 36b4ef2c10980067ac72ae5c08d19236399c7f80073ab5261df2a8bc668d7db5 7492 librsl_1.43-1.1.debian.tar.xz Files: 5a072b889596f45f450614303824275f 2108 science extra librsl_1.43-1.1.dsc 49b4fb08e47234af655e80089ffb4047 7492 science extra librsl_1.43-1.1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAlhrb4UACgkQM2L3AxpJ kuFC5w/7B9f5sasvwahZn8/krCNFIQhtn8wprsl9FdE90cjLOfpXw+MLvNls9lgy VdKWTH1E/aHiR4y3TDkinxq33Y67YNXdqNW466v54EihIj+SZ4uMEyb34AHi6zfC UqCWUTGIkNiWEdnfCkJ//y5TZtHymxmshJnv/d8L6QvxbqHbuYR795bFSsg6XRdt YYw5gnPU1eHDX96Etq2yn1y9CJUbK6uH30gMaZW25ZICr5gym/bl0cZO4b6mqpyR DiTD+4TWib2QPzNx9SxZFJSSfN4A3RZZhiLGJZjOMmOlCNbPLiTdyOWcRjP85wE4 2AYwDMIC5gI/RkuAMkPNingX38zuMuWpSkmHazHiwp7EY2cYj+XnMialk1cCJg0s TlnsJZNPVMo94Q1CxDm2iXTbNw3qsrvdC7GMUi1a+tUoeG8mzoS7vIMo6+S+z4RQ 3uTbggVB7f13LFciNYrwwNTM9MQ6NLan1bOw6yftsnzFEdq3TO78esaVsXx/wys0 LqhK13nXVMQ9lupbPr5qyNUp2KdK2ALCJeLxh6FKm7BmYJMjqWftbY9CFVP0YdbJ yfpF3KKLHiz8PeM0qTwjWWE8U0V51nagewNF3yrbx9cYXK+tQJQoKIDzk5TQ+/l0 /UKJuo/v9RO6kjiMZYCwX2hg6tQ4+Ohip9J8RNSriXmG+OUsmDQ= =cc22 -END PGP SIGNATURE- Thank you for your contribution to Debian. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#850026: vmtk: transitive B-D on both libssl-dev and libssl1.0-dev
Source: vmtk Version: 1.3+dfsg-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi, vmtk cannot be built any longer, since it transitively Build-Depends on both libssl-dev and libssl1.0-dev which conflict with each other. Andreas -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#846436: marked as done (librsl: add libfl-dev to Build-Depends)
Your message dated Tue, 03 Jan 2017 09:49:39 + with message-id and subject line Bug#846436: fixed in librsl 1.43-1.1 has caused the Debian Bug report #846436, regarding librsl: add libfl-dev to Build-Depends to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 846436: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846436 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: librsl Severity: important User: helm...@debian.org Usertags: libfldep librsl will soon fail to build from source, beause flex drops its dependency on libfl-dev. Since librsl uses parts of libfl-dev (e.g. libl.a, libfl.a or FlexLexer.h), it should add libfl-dev to its Build-Depends. This change was previously announced[1] to debian-devel in accordance with DevRef 7.1.1. Please add the missing dependency. Helmut [1] https://lists.debian.org/debian-devel/2016/03/msg00162.html --- End Message --- --- Begin Message --- Source: librsl Source-Version: 1.43-1.1 We believe that the bug you reported is fixed in the latest version of librsl, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 846...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andrey Rahmatullin (supplier of updated librsl package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 03 Jan 2017 14:27:17 +0500 Source: librsl Binary: librsl1 librsl-dev librsl-doc Architecture: source Version: 1.43-1.1 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Andrey Rahmatullin Description: librsl-dev - Development files for RSL librsl-doc - HTML documentation for RSL librsl1- TRMM Radar Software Library Closes: 846436 Changes: librsl (1.43-1.1) unstable; urgency=medium . * Non-maintainer upload. * Add Build-Depends: libfl-dev (Closes: #846436). Checksums-Sha1: ba09308585a6601ad7d062c1297882b22736b18e 2108 librsl_1.43-1.1.dsc 74505d0a1b0fb27e16cb732cccda0800782bb669 7492 librsl_1.43-1.1.debian.tar.xz Checksums-Sha256: 2ec8f4c5d234ce354a9fbf662067f85de0bc9978cacc03631d7bbebc466c5f16 2108 librsl_1.43-1.1.dsc 36b4ef2c10980067ac72ae5c08d19236399c7f80073ab5261df2a8bc668d7db5 7492 librsl_1.43-1.1.debian.tar.xz Files: 5a072b889596f45f450614303824275f 2108 science extra librsl_1.43-1.1.dsc 49b4fb08e47234af655e80089ffb4047 7492 science extra librsl_1.43-1.1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAlhrb4UACgkQM2L3AxpJ kuFC5w/7B9f5sasvwahZn8/krCNFIQhtn8wprsl9FdE90cjLOfpXw+MLvNls9lgy VdKWTH1E/aHiR4y3TDkinxq33Y67YNXdqNW466v54EihIj+SZ4uMEyb34AHi6zfC UqCWUTGIkNiWEdnfCkJ//y5TZtHymxmshJnv/d8L6QvxbqHbuYR795bFSsg6XRdt YYw5gnPU1eHDX96Etq2yn1y9CJUbK6uH30gMaZW25ZICr5gym/bl0cZO4b6mqpyR DiTD+4TWib2QPzNx9SxZFJSSfN4A3RZZhiLGJZjOMmOlCNbPLiTdyOWcRjP85wE4 2AYwDMIC5gI/RkuAMkPNingX38zuMuWpSkmHazHiwp7EY2cYj+XnMialk1cCJg0s TlnsJZNPVMo94Q1CxDm2iXTbNw3qsrvdC7GMUi1a+tUoeG8mzoS7vIMo6+S+z4RQ 3uTbggVB7f13LFciNYrwwNTM9MQ6NLan1bOw6yftsnzFEdq3TO78esaVsXx/wys0 LqhK13nXVMQ9lupbPr5qyNUp2KdK2ALCJeLxh6FKm7BmYJMjqWftbY9CFVP0YdbJ yfpF3KKLHiz8PeM0qTwjWWE8U0V51nagewNF3yrbx9cYXK+tQJQoKIDzk5TQ+/l0 /UKJuo/v9RO6kjiMZYCwX2hg6tQ4+Ohip9J8RNSriXmG+OUsmDQ= =cc22 -END PGP SIGNATURE End Message --- -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable
Package: libfreeimage3 Version: 3.17.0+ds1-3 Severity: important Hi, the recent libfreeimage update from 3.17.0+ds1-3 to to 3.17.0+ds1-4 breaks rviz. The application fails to start with: terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_M_construct null not valid zsh: abort rviz reverting freeimage to ds1-3 fixes the problem. Relevant upstream rviz bug is: https://github.com/ros-visualization/rviz/issues/1071 greetings, Erik -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Processed: your mail
Processing commands for cont...@bugs.debian.org: > tag 849945 + patch Bug #849945 [src:evolver] evolver: FTBFS on ppc64el - error: initializer element is not constant Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 849945: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849945 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable
Hi Erik, thanks for reporting this issue, freeimage/3.17.0+ds1-4 fixed an issue with the patch used to remove the vendored dependencies and use the system one instead. See #841089 [1]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841089 The updated patch introduces a null-node for plugins which have been disabled (here the G3 fax format). Before this patch, all nodes stored in the plugin map were guaranteed to be non-null but all plugins with IDs over FIF_FAXG3 were wrongly indexed. A fix for your issue in rviz would be to filter the plugin map from non-null nodes prior to registering the codecs. Hope this helps, Ghis -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848137: problem with the upgrade of tango-db
Hello, I would like to discuss about this bug [1] I tryed to reproduce the scenary of piuparts in a virtual machine (gnome-box) installed in 3 steps: jessie base system mysql-server (I need a working database) tango-db (daemon) It works ok, I have a running tango-db daemon (ps aux | grep tango) then replace jessie by stretch in the sources.list apt-get update apt-get install mysql-server (5.5 -> 5.6) the tango-db is still working. Now I installed the new default-mysql-server apt-get install default-mysql-server (5.6 -> mariadb 10.1) the tango-db daemon is still working. Now I upgrade tango-db apt-get install tango-db (tango8 -> tango9) and during this upgrade I have a problem of right that you can see in the bug report. I would like to know how to debug this problem, I tryed to export dbc_debug=1, But I got no real information about the failing mysqldump. I would say that I know almost nothing about sql, but I can learn. What is strange from mmy point of view, is that I created the table and populate it only with dbconfig-common. So I find strange that the dump can not work. Maybe this is a problem of compatibility between mysql/mariadb, because the dabatase was first created with mysql 5.5 and the upgrade is done via mariadb. Are you aware of problem of right due to mariadb ? thanks for your help Fred [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848137 please CC me I am not on the mailing list -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848137: Info received (problem with the upgrade of tango-db)
Thanks to reynald 1) On Jessie with the tango account mysql> use tango; mysql> show create procedure class_att_prop\G I got "Create Procedure": NULL But If I use the root account (mysqladmin) CREATE DEFINER=`root`@`localhost` PROCEDURE `class_att_prop` (IN class_name VARCHAR(255), INOUT res_str BLOB) which shows clearly that on jessie the procédure where created with the admin account 2) On stretch with the tango account > CREATE DEFINER=`tango`@`localhost` PROCEDURE `class_att_prop` (IN class_name > VARCHAR(255), INOUT res_str MEDIUMBLOB) Which shows that the procedures were created with the right tango account. Now the question is how can we fix this ? -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Invito ad un matrimonio? fai un regalo gradito ed originale [P]
Desideriamo inviare le nostre informazioni solo a chi lo desidera: puoi cancellarti dalle nostre liste semplicemente cliccando qui. Se vuoi segnalare questa email come spam CLICCA QUI. Grazie per la collaborazione ! Hai un invito ad un matrimonio ... ... e vuoi fare una sorpresa originale ? Se hai ricevuto un invito ad un matrimonio noi possiamo aiutarti con idee nuove e divertenti ! contattaci per avere indicazioni riguardo le nostre proposte e le ultime novita' per fare un regalo di matrimonio originale, come per esempio : rilascio: centinaia di palloncini che volano in cielo: guarda l'effetto cliccando QUI. colonne con un effetto di palloncini... esplosivo clicca QUI. 100 palloncini personalizzati e gonfiati ad elio da distribuire agli ospiti e da far volare ... all'uscita degli sposi: vedi i dettagli cliccando QUI. Se desideri maggiori informazioni, senza alcun impegno, o desideri ricevere ulteriori dettagli invia la richiesta via email a i...@magicbaloon.com, contatta il numero 393 4033016, 320 5646455 o visita direttamente il nostro sito. Siamo anche su Facebook: vai sulla nostra pagina Facebook e clicca Mi Piace per essere sempre aggiornato, scoprire per primo le novita' e ricevere le promozioni a te riservate. Riceviamo richieste di informazioni da molti anni ed il tuo indirizzo email debian-science-maintainers@lists.alioth.debian.org, classificato come privato, ci e' pervenuto nel corso del tempo direttamente, in seguito a tue richieste di informazioni o in copia ad altri messaggi sempre da noi ricevuti. Lo useremo solo per inviare offerte dei nostri servizi a prezzi scontati. Se non desiderate ricevere ulteriori proposte da MagicBaloon, clicca qui o rispondete con una e-mail, anche vuota, con il soggetto Cancellazione e non verranno inviate ulteriori informazioni. GRAZIE ! -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
eigen3 3.3.1-2 MIGRATED to testing
FYI: The status of the eigen3 source package in Debian's testing distribution has changed. Previous version: 3.3.0-1 Current version: 3.3.1-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
sagemath 7.4-4 MIGRATED to testing
FYI: The status of the sagemath source package in Debian's testing distribution has changed. Previous version: (not in testing) Current version: 7.4-4 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
pybind11 2.0.0~rc1-1 MIGRATED to testing
FYI: The status of the pybind11 source package in Debian's testing distribution has changed. Previous version: 1.8.1-2 Current version: 2.0.0~rc1-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Processing of pybind11_2.0.0-1_source.changes
pybind11_2.0.0-1_source.changes uploaded successfully to localhost along with the files: pybind11_2.0.0-1.dsc pybind11_2.0.0.orig.tar.gz pybind11_2.0.0-1.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org) -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#850065: openfoam: Build runs way more parallel processes than specified by DEB_BUILD_OPTIONS
Source: openfoam Version: 4.1+dfsg1-1 Severity: important When I try building openfoam under pbuilder (on amd64), with DEB_BUILD_OPTIONS="parallel=8", it swaps heavily. By running top I see at least about 30 cc1plus processes trying to run at the same time (it's hard to get an exact count since the swapping makes doing anything painfully slow). -- Daniel Schepler -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
pybind11_2.0.0-1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 03 Jan 2017 15:44:46 + Source: pybind11 Binary: pybind11-dev pybind11-doc python-pybind11 python3-pybind11 Architecture: source Version: 2.0.0-1 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers Changed-By: Ghislain Antony Vaillant Description: pybind11-dev - seamless operability between C++11 and Python pybind11-doc - documentation for pybind11 python-pybind11 - pybind11 helper module for Python 2 python3-pybind11 - pybind11 helper module for Python 3 Changes: pybind11 (2.0.0-1) unstable; urgency=medium . * Remove gbp configuration in favor of git-dpm * Mangle upstream development versions * New upstream release * Add support for the nocheck build profile - Add versioned dependency on dpkg-dev - Mark build dependencies specific to testing as !nocheck - Do not build the test suite if nocheck is requested * Add support for the nodoc build profile - Mark build dependencies specific to the documentation as !nodoc - Add build dependency on sphinx-common for dh_sphinxdoc - Do not build the documentation if nodoc is requested Checksums-Sha1: 3a26bdff430f5852f7a3e7a28212e7d91f27496b 2531 pybind11_2.0.0-1.dsc 1583b3c1d015762845995d99a9101b3f595a4cd7 398189 pybind11_2.0.0.orig.tar.gz 427d419923451fa5397b8704fecb816b811069f2 5156 pybind11_2.0.0-1.debian.tar.xz Checksums-Sha256: f5afc975b8578743eb95c4f6eaacde09a316a8fcf831191ac5930e5fa9e625f0 2531 pybind11_2.0.0-1.dsc 5b8c599416941e62f2452111c9274c22bb1b5fa65bb7fdfd0c405332af656e9a 398189 pybind11_2.0.0.orig.tar.gz 9c401600137dc5a22244e324612b249f13b2a4ff8d630d558392489fd87a7593 5156 pybind11_2.0.0-1.debian.tar.xz Files: a545f9df0bbc14dde505e450f863c8a2 2531 libs optional pybind11_2.0.0-1.dsc d643ddc89dc0f660c4bc19bcc93b4421 398189 libs optional pybind11_2.0.0.orig.tar.gz 37f0c144efdbaa6e605557118564c920 5156 libs optional pybind11_2.0.0-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAlhr5/QACgkQ0+Fzg8+n /wYveg/+KdDihAvL6MN7osGJ3CkRuzvAMFKbzsuC3tnYq4qhcQneTzaZOujq3QtQ 8S89aZf0aJ5Fm/XJ7ez5chanAiGq3p2jlk7YgqDjJsfwEqGFtbTf/E3sfQOznrk/ w2m7AlS4GFC08b4s/IOMwJgDnEhpsM7H5pigUuRcXgIIQwIKdjmNrAJduc9ct2Sh 6sb74VInDAKYr8Rdue0ZotVL4Qmux/R4S68YKxba08IOv59lDyusctxOiIowXvxz I3G1jwmNuOUQLyo2/5+3KFnrPab131sWhruakpfbjf8KDR4Xl0Y+zOLqmBxMgJTL BnJBvBABSS7H12GfBhSs0IdAQqgJ3stMmlg1Wv7rZzIB6Cbty0YGQ8pKf4qEBCky m3TWh+HZJg9DOlSr7ewCl9PkS/QUufv8J4Mt1ujX0X95gNaK1Nci00LNHl4Ky8Db 5YoVDf8lgqGiN1KSbxdh96hSsUe9AJwfT6SB8CoTK63skTJiaGRrlcP15LamuPcS 2XCaR8fs21m97as4aM0rw5HxcKPkrRvwZA2qYAa4t8N9NBG/Qz6R+sfPJ8pF6NNN /1W086y31JYNa+/S7tFYwGc9aE7UKVUgFKUjKYh6M2/oIv99VcqGPMW1gUN/f+57 VWfvfTOzdcuuCSEfxlLNHmvNScfTV0UUTGCQP8geTlRzxgqh0ks= =oewj -END PGP SIGNATURE- Thank you for your contribution to Debian. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
debian-science-maintainers@lists.alioth.debian.org邮件系统备案提醒!
这是一封 HTML 格式的邮件,请以网页方式查看邮件。 -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848137: RE:Bug#848137: Info received (problem with the upgrade of tango-db)
Hi Frederic-Emmanuel, On Tue, 3 Jan 2017 15:02:08 + PICCA Frederic-Emmanuel wrote: > 1) On Jessie > > with the tango account > > mysql> use tango; > mysql> show create procedure class_att_prop\G > > I got "Create Procedure": NULL > > But If I use the root account (mysqladmin) > > CREATE DEFINER=`root`@`localhost` PROCEDURE `class_att_prop` (IN class_name > VARCHAR(255), INOUT res_str BLOB) > > which shows clearly that on jessie the procédure where created with the admin > account > > 2) On stretch > > with the tango account > > > CREATE DEFINER=`tango`@`localhost` PROCEDURE `class_att_prop` (IN > > class_name VARCHAR(255), INOUT res_str MEDIUMBLOB) > > Which shows that the procedures were created with the right tango account. > > Now the question is how can we fix this ? I am not sure that I follow what you are doing, but if you need the code to be run with the dbadmin privileges, you should put the code in: /usr/share/dbconfig-common/data/PACKAGE/upgrade-dbadmin/DBTYPE/VERSION instead of in: /usr/share/dbconfig-common/data/PACKAGE/upgrade/DBTYPE/VERSION Please consult the documentation here: https://www.debian.org/doc/manuals/dbconfig-common/ch-develguide.html#s-updates and (describing the difference): https://www.debian.org/doc/manuals/dbconfig-common/ch-develguide.html#s-bootstrap Paul signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848137: RE:Bug#848137: Info received (problem with the upgrade of tango-db)
> I am not sure that I follow what you are doing, but if you need the code > to be run with the dbadmin privileges, you should put the code in: >/usr/share/dbconfig-common/data/PACKAGE/upgrade-dbadmin/DBTYPE/VERSION > instead of in: >/usr/share/dbconfig-common/data/PACKAGE/upgrade/DBTYPE/VERSION Hello Paul I just try to use dbconfig-common like I did before, (create the tango database, populate it with a few values and create some procedures.) What is strange to me is that with dbconfig-common (jessie version), I end up with procedure owned by root @ localhost but when I use the dbconfig-common of stretch, the procedure are owned by tango @ localhost 5which is right) I always used the non dbadmin script in order to configure my database. This is why I do not understand why the mysqldump does not work anymore. Does the dump changed between the jessie and strecth dbconfig-common ? By change I mean. In jessie it is run as root, but on stretch it is run as tango ? Cheers Fred -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848137: RE:Bug#848137: Info received (problem with the upgrade of tango-db)
Hi Frederic-Emmanuel, On 03-01-17 21:21, PICCA Frederic-Emmanuel wrote: > I just try to use dbconfig-common like I did before, > (create the tango database, populate it with a few values and create some > procedures.) > > What is strange to me is that with dbconfig-common (jessie version), I end up > with procedure owned by > root @ localhost > > but when I use the dbconfig-common of stretch, the procedure are owned by > tango @ localhost 5which is right) > > I always used the non dbadmin script in order to configure my database. > This is why I do not understand why the mysqldump does not work anymore. > Does the dump changed between the jessie and strecth dbconfig-common ? > > By change I mean. > > In jessie it is run as root, but on stretch it is run as tango ? Let me check the (huge) delta between jessie and stretch (hopefully tomorrow). I made major improvements in the code, but I don't specifically remember anything related to this issue. Furthermore, I don't rule out that this is indeed MySQL/MariaDB related. We/you could also ask the maintainers list of those packages if the current behavior rings a bell. Additionally, trying to do the tests as you did so far but sticking to MySQL instead of moving over to MariaDB would be an interesting and insightful exercise. Paul signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848137: RE:Bug#848137: Info received (problem with the upgrade of tango-db)
Hmmm, On 03-01-17 22:07, Paul Gevers wrote: > On 03-01-17 21:21, PICCA Frederic-Emmanuel wrote: >> I just try to use dbconfig-common like I did before, >> (create the tango database, populate it with a few values and create some >> procedures.) >> >> What is strange to me is that with dbconfig-common (jessie version), I end >> up with procedure owned by >> root @ localhost >> >> but when I use the dbconfig-common of stretch, the procedure are owned by >> tango @ localhost 5which is right) >> >> I always used the non dbadmin script in order to configure my database. >> This is why I do not understand why the mysqldump does not work anymore. >> Does the dump changed between the jessie and strecth dbconfig-common ? >> >> By change I mean. >> >> In jessie it is run as root, but on stretch it is run as tango ? > > Let me check the (huge) delta between jessie and stretch (hopefully > tomorrow). I made major improvements in the code, but I don't > specifically remember anything related to this issue. Furthermore, I > don't rule out that this is indeed MySQL/MariaDB related. We/you could > also ask the maintainers list of those packages if the current behavior > rings a bell. Additionally, trying to do the tests as you did so far but > sticking to MySQL instead of moving over to MariaDB would be an > interesting and insightful exercise. I am suspecting that this commit may be related to the current behavior: https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git/commit/?id=acdb99d61abfff54630c4cfba6e4452357a83fb9 I believe I implemented there that the drop of the database is performed with the user privileges instead of the dbadmin privileges because I believed one should always have the rights to drop the db. Apparently I was wrong. We may need to clone or reassign this bug to dbconfig, but I'm not sure yet if there aren't more things, or if tango-db should work around the issue (which may be created by buggy dbconfig-common behavior of the past). Out of time now. Paul signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848859: FTBFS randomly (failing tests)
On Tue, 27 Dec 2016, Ole Streicher wrote: > Hi Santiago, Hello Ole. Thanks for your reply. Please don't forget to Cc: me if you expect your message to be read. > > In particular, if something happens 1 every 20 times on average, the > > fact that it did not happen when you try 10 times does not mean in any > > way that it may not happen. > > > I must however say that I don't see why a package that fails to build > once in 20 builds would have a release critical problem: It's in Release Policy: Packages *must* autobuild *without* failure. If a package fails to build from time to time, that's a failure. > There is nothing in our policy that requires a reproducible or even a > always successful build. Please don't mix "reproducible" with "always successful build". They are different things and nobody is making "reproducible builds" policy yet. But "always successful" has always been release policy: https://release.debian.org/stretch/rc_policy.txt Please read the paragraph saying "packages must autobuild without failure". That paragraph is the very reason FTBFS bugs are serious since a lng time. > I totally agree that catching random failures > is a good quality measure, but this is IMO severity "important" at maximum. Well, would you say it's RC if it fails 99% of the time? I guess you would. Would you say it's RC if it fails 0.001% of the time? I guess you would not, since you have just said that 0.05% does not deserve to be serious. So, you are implicitly saying that packages which FTBFS with a low probability does not deserve a serious bug. However, there is no threshold at all in policy, and if you think about it, any such threshold would be quite arbitrary indeed: Why would 50% of failure be RC while 49% of failure is not? [ To me, the mere fact that we are able to *measure* the probability of failure already means that it is too high ]. Anyway, there will be plenty of time to discuss about this because I'm going to downgrade all the FTBFS-randomly bugs I've detected until Release Managers say something about the subject. Then I expect most (if not all) of them will become serious and RC again. > And it would be nice to have this QA test not just before the release, > but already early in the release cycle. This would help a lot to avoid > stressful bugfixes just before the freeze. Well, if you see my list of FTBFS-randomly bug here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org you will see that I started to report FTBFS-randomly bugs several months ago, not last week, and not last month. What would really help is to have somebody else reporting these bugs, because apparently very few people want to report them. Also, you can't seriously "complain" that a bug reporter didn't not report something earlier! Of course that it would be nice to do this kind of QA stuff at every point in the release cycle, but as the same software that we maintain, my bug reports come with no warranty, not even the warranty that the bug is reported "as soon as it exists"! :-) Thanks. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848859: (no subject)
severity 846116 important severity 680038 important severity 828929 important severity 834686 important severity 834962 important severity 842836 important severity 844083 important severity 844088 important severity 844571 important severity 845164 important severity 846021 important severity 846115 important severity 846300 important severity 846318 important severity 848054 important severity 848055 important severity 848403 important severity 849775 important severity 849217 important severity 832865 important severity 837067 important severity 848063 important severity 849363 important severity 846026 important severity 841904 important severity 847288 important severity 848859 important severity 841098 important severity 843038 important severity 848409 important severity 710696 important thanks Hello. I'm setting the severity of this bug to "important" not because I don't think it is not RC (as Release Policy still says that packages must autobuild *without* failure), but because the Release Managers are considering to decide about RC-ness of this kind of bugs based on the probability of failure. We don't know what kind of threshold there will be for stretch, so I strongly recommend that you act as if this bug was serious and RC, especially if the failures happen very often on any kind of autobuilder which is not misconfigured. Thanks. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Processed: your mail
Processing commands for cont...@bugs.debian.org: > severity 846116 important Bug #846116 [src:libhamcrest-java] libhamcrest-java: FTBFS randomly (error: cannot access Description) Severity set to 'important' from 'serious' > severity 680038 important Bug #680038 [src:kyotocabinet] kyotocabinet: FTBFS randomly (failing test) Severity set to 'important' from 'serious' > severity 828929 important Bug #828929 [src:cairocffi] cairocffi: FTBFS randomly Severity set to 'important' from 'serious' > severity 834686 important Bug #834686 [src:ruby-httpclient] ruby-httpclient: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 834962 important Bug #834962 [src:ruby-diaspora-vines] ruby-diaspora-vines: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 842836 important Bug #842836 [src:golang-github-mxk-go-flowrate] golang-github-mxk-go-flowrate: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 844083 important Bug #844083 [src:openhft-lang] openhft-lang: FTBFS randomly (DataValueGeneratorTest.testGenerateInterfaceWithDateNativeInstace fails) Severity set to 'important' from 'serious' > severity 844088 important Bug #844088 [src:conversant-disruptor] conversant-disruptor: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 844571 important Bug #844571 [src:uncertainties] uncertainties: FTBFS randomly (ERROR: Comparison between function derivatives and numerical derivatives) Severity set to 'important' from 'serious' > severity 845164 important Bug #845164 [src:ruby-spy] ruby-spy: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 846021 important Bug #846021 [src:ruby-webmock] ruby-webmock: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 846115 important Bug #846115 [src:jekyll] jekyll: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 846300 important Bug #846300 [src:ruby-distribution] ruby-distribution: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 846318 important Bug #846318 [src:automake-1.15] automake-1.15: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 848054 important Bug #848054 [src:debci] debci: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 848055 important Bug #848055 [src:golang-github-go-chef-chef] golang-github-go-chef-chef: FTBFS randomly (failing tests) Severity set to 'important' from 'serious' > severity 848403 important Bug #848403 [src:diffoscope] diffoscope: FTBFS randomly (Fatal Python error: deallocating None) Severity set to 'important' from 'serious' > severity 849775 important Bug #849775 [src:emacs24] emacs24: FTBFS randomly (Wrong type argument: number-or-marker-p, nil) Severity set to 'important' from 'serious' > severity 849217 important Bug #849217 [src:jruby] jruby: FTBFS randomly (sbuild hangs) Severity set to 'important' from 'serious' > severity 832865 important Bug #832865 [src:telepathy-python] telepathy-python: FTBFS: will not overwrite just-created '/«PKGBUILDDIR»/debian/python-telepathy//usr/lib/python2.7/dist-packages/telepathy/_generated/errors.py' with '_generated/errors.py' Ignoring request to change severity of Bug 832865 to the same value. > severity 837067 important Bug #837067 [src:libsecret] libsecret: FTBFS - /collection/delete-sync failure Ignoring request to change severity of Bug 837067 to the same value. > severity 848063 important Bug #848063 [src:ri-li] ri-li: FTBFS randomly (Impossible d'initialiser SDL:Couldn't open X11 display) Ignoring request to change severity of Bug 848063 to the same value. > severity 849363 important Bug #849363 [src:libtime-format-perl] libtime-format-perl: FTBFS randomly (race condition in t/time.t) Ignoring request to change severity of Bug 849363 to the same value. > severity 846026 important Bug #846026 [src:strongswan] strongswan: FTBFS randomly (failing tests) Ignoring request to change severity of Bug 846026 to the same value. > severity 841904 important Bug #841904 [src:swift] swift: FTBFS randomly (failing tests) Severity set to 'important' from 'normal' > severity 847288 important Bug #847288 [src:libdbd-firebird-perl] libdbd-firebird-perl: FTBFS randomly (failing tests) Severity set to 'important' from 'normal' > severity 848859 important Bug #848859 [src:getfem++] getfem++: FTBFS randomly (failing tests) Severity set to 'important' from 'minor' > severity 841098 important Bug #841098 [src:rygel] rygel: FTBFS (rygel-media-engine-test fails) Severity set to 'important' from 'wishlist' > severity 843038 important Bug #843038 [src:elki] elki: FTBFS randomly (failing tests) Severity set to 'important' from 'wishlist' > severity 848409 important Bug #848409 [src:libchi-driver-redis-perl] libchi-driver-redis-perl: FTBFS randomly (failing tests) Severity set t
Re: Fyi
Hello , My name is Teresa Danuta I am a financial consultant , I got your contact details in my search for a reliable and neutral company or individual to partner with for profitable Return on Investment (ROI). I know that this mail might come to you as surprise because we neither know each other nor has ever met but accept it with an open and positive mind. We want to partner with you to receive and place an investment funds into viable business ventures in your country that can guarantee a good Return on Investment (ROI) which will be under your control and management. We have obtained certificate of Incumbancy and Certificate of Good Standing for AMIC which are enclosed herewith. We shall firm up our approach on opening of account once I have obtained necessary clarrification of Name of the Bank and Depository of IGE Resources, issuer of shares. I expect to have this information available beginning of Feb. Details of the investment and funding will be furnished to you when I receive your positive response which will also facilitate face to face meeting with the investor. Yours Sincerely, Teresa Danuta -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
sagemath is marked for autoremoval from testing
sagemath 7.4-4 is marked for autoremoval from testing on 2017-02-02 It (build-)depends on packages with these RC bugs: 840823: execnet: testing/test_gateway.py::TestBasicGateway::test_gateway_status_busy[thread-popen] FAILED 846951: execnet: testing/test_gateway.py::TestTracing::test_popen_stderr_tracing FAILED 846952: execnet: testing/test_channel.py::TestStringCoerce::test_2to3 FAILED 848748: blockdiag: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity 849220: ipykernel: FTBFS (failing tests) -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
statsmodels is marked for autoremoval from testing
statsmodels 0.8.0~rc1+git43-g1ac3f11-1 is marked for autoremoval from testing on 2017-01-29 It is affected by these RC bugs: 841610: statsmodels: FTBFS: TypeError: cannot sort an Index object in-place, use sort_values instead It (build-)depends on packages with these RC bugs: 848771: numexpr: FTBFS: Test failures -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848771: marked as done (numexpr: FTBFS: Test failures)
Your message dated Wed, 4 Jan 2017 08:26:56 +0100 with message-id <23458e0e-312a-f6be-fcc3-480d99d1a...@debian.org> and subject line Closing... has caused the Debian Bug report #848771, regarding numexpr: FTBFS: Test failures to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 848771: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848771 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: numexpr Version: 2.6.1-2 Severity: serious Tags: stretch sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20161219 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): > == > ERROR: test_scalar2_long_none_POW_TESTS_4066 (__main__.TestExpressions) > -- > Traceback (most recent call last): > File "numexpr/tests/test_numexpr.py", line 1011, in method > return func() > File "numexpr/tests/test_numexpr.py", line 572, in method > npval = eval(expr, globals(), this_locals) > File "", line 1, in > ValueError: Integers to negative integer powers are not allowed. > > -- > Ran 5441 tests in 5.616s > > FAILED (errors=24) > debian/rules:59: recipe for target 'override_dh_auto_test' failed The full build log is available from: http://aws-logs.debian.net/2016/12/19/numexpr_2.6.1-2_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. --- End Message --- --- Begin Message --- Source: sunpy Version: 0.7.4-1 Since skimage migrated to testing, this bug is obsolete. Cheers Ole--- End Message --- -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#848859: FTBFS randomly (failing tests)
Hi Santiago, On 04.01.2017 01:41, Santiago Vila wrote: > On Tue, 27 Dec 2016, Ole Streicher wrote: > Hello Ole. Thanks for your reply. Please don't forget to Cc: me if you > expect your message to be read. OK, however I usually assume that a bug submitter actually reads the messages for his submitted bugs. >>> In particular, if something happens 1 every 20 times on average, the >>> fact that it did not happen when you try 10 times does not mean in any >>> way that it may not happen. >> >> >> I must however say that I don't see why a package that fails to build >> once in 20 builds would have a release critical problem: > > It's in Release Policy: Packages *must* autobuild *without* failure. > > If a package fails to build from time to time, that's a failure. Packages actually *do* fail from time to time, when I look into my autobuilder. Not due to the package, but due to glitches within the buildd infrastructure. Would you consider this a failure? >> I totally agree that catching random failures >> is a good quality measure, but this is IMO severity "important" at maximum. > > Well, would you say it's RC if it fails 99% of the time? > I guess you would. I would consider a bug RC if it actually doesn't build on our buildds. >> And it would be nice to have this QA test not just before the release, >> but already early in the release cycle. This would help a lot to avoid >> stressful bugfixes just before the freeze. > > Well, if you see my list of FTBFS-randomly bug here: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-randomly;users=sanv...@debian.org > > you will see that I started to report FTBFS-randomly bugs several > months ago, not last week, and not last month. > > What would really help is to have somebody else reporting these bugs, > because apparently very few people want to report them. > > Also, you can't seriously "complain" that a bug reporter didn't not > report something earlier! Of course that it would be nice to do this > kind of QA stuff at every point in the release cycle, but as the same > software that we maintain, my bug reports come with no warranty, not > even the warranty that the bug is reported "as soon as it exists"! :-) What I do complain about is that doing this just before the release adds additional pressure to the package maintainers: The problem for us ordinary people is that most of the time my packages look fine, without serious problems, and just before the release all those RC bugs pop up in bunches, with quite some time pressure to solve them. If the RC bugs were randomly distributed over time, it would be more time to solve them, and the quality of the fixes would be better: for example, in the moment, I would just disable build time tests that randomly fail, while usually I would try to see why they fail and fix that. In the moment, there is no time for this. Doing release QA just before the release leads to quick hacks to keep things there, while a continious QA really solves them. Best regards Ole -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers