Bug#760931: scilab: ftbfs with OpenJDK 8
Package: src:scilab
Version: 5.5.0-3
Severity: important
User: debian-j...@lists.debian.org
Usertags: openjdk-8-transition
The package fails to build in a test rebuild on at least amd64 with
openjdk-8 as the default java version, but succeeds to build with
openjdk-7.
The full build log can be found at:
http://people.debian.org/~doko/logs/java8-20140908/logs-failed-ref/scilab_5.5.0-3_unstable_ref.log
The last lines of the build log are at the end of this report.
To build with openjdk-8 explicitly, install the openjdk-8-jdk package
from experimental,
apt-get -t experimental install g++
and install the default-jdk package from
deb https://people.debian.org/~doko/tmp/20140820 ./
[...]
[javac]^
[javac]
/«PKGBUILDDIR»/modules/scirenderer/src/org/scilab/forge/scirenderer/implementation/jogl/JoGLCanvas.java:274:
warning: [deprecation] GLPbuffer in javax.media.opengl has been deprecated
[javac] ((GLPbuffer) autoDrawable).destroy();
[javac] ^
[javac]
/«PKGBUILDDIR»/modules/scirenderer/src/org/scilab/forge/scirenderer/implementation/jogl/JoGLCanvas.java:294:
warning: [deprecation]
createGLPbuffer(AbstractGraphicsDevice,GLCapabilitiesImmutable,GLCapabilitiesChooser,int,int,GLContext)
in GLDrawableFactory has been deprecated
[javac] return factory.createGLPbuffer(null, capabilities, null,
width, height, null);
[javac] ^
[javac]
/«PKGBUILDDIR»/modules/scirenderer/src/org/scilab/forge/scirenderer/ruler/graduations/TinyIntervalFormat.java:24:
warning: [serial] serializable class TinyIntervalFormat has no definition of
serialVersionUID
[javac] public class TinyIntervalFormat extends DecimalFormat {
[javac]^
[javac]
/«PKGBUILDDIR»/modules/scirenderer/src/org/scilab/forge/scirenderer/ruler/graduations/UserDefinedFormat.java:26:
warning: [serial] serializable class UserDefinedFormat has no definition of
serialVersionUID
[javac] public class UserDefinedFormat extends DecimalFormat {
[javac]^
[javac] 9 warnings
noversion:
[echo] Using:
[echo] ${thirdparty.dir}
[echo] /usr/share/java/jogl2.jar
[echo] /usr/share/java/gluegen2-rt.jar
[echo] /usr/share/java/jlatexmath.jar
init:
compile:
jar:
[jar] Building jar:
/«PKGBUILDDIR»/modules/scirenderer/jar/scirenderer.jar
localization:
[taskdef] Could not load definitions from resource checkstyletask.properties.
It could not be found.
init:
BUILD FAILED
/«PKGBUILDDIR»/modules/prebuildjava/build.xml:83: The following error
occurred while executing this line:
/«PKGBUILDDIR»/build.incl.xml:88: JDK 1.6 or 1.7 required. Found 1.8
Total time: 9 seconds
make[3]: *** [java] Error 1
Makefile:718: recipe for target 'java' failed
make[3]: Leaving directory '/«PKGBUILDDIR»/modules/prebuildjava'
make[2]: *** [all-recursive] Error 1
Makefile:796: recipe for target 'all-recursive' failed
make[2]: Leaving directory '/«PKGBUILDDIR»/modules'
make[1]: *** [all-recursive] Error 1
Makefile:1534: recipe for target 'all-recursive' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
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#760936: BLAS: not Multi-Arch safe
Package: libblas3 Version: 1.2.20110419-7 Severity: important libblas3 Provides: libblas.so.3 libatlas3-base Provides: libblas.so.3 The problem here is that I can install, for example, libblas3:amd64 and libatlas3-base:i386, and they are managed by the same alternative. Helmut and I think you need to move the libblas.so.3 symlink into arch-qualified subdirectories and manage multiple alternatives, one per architecture. Helmut suggested to just add Conflicts: libblas.so.3 to all providers of the libblas.so.3 virtual package, so they are not coïnstallable, then drop the alternatives Geraffel and just use normal M-A coïnstallability. Please do enlighten us to the reason of this alternatives system ☺ Related is #760821 which is an error (partially) caused by this problem. -- System Information: Debian Release: jessie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages libblas3 depends on: ii libc6 2.19-10 ii libgcc1 1:4.9.1-12 ii libgfortran3 4.9.1-12 ii libquadmath0 4.9.1-12 libblas3 recommends no packages. libblas3 suggests no packages. -- no debconf 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
Bug#760936: BLAS: not Multi-Arch safe
On Tue, Sep 09, 2014 at 11:11:39AM +0200, Thorsten Glaser wrote:
The problem here is that I can install, for example,
libblas3:amd64 and libatlas3-base:i386, and they are
managed by the same alternative.
Let me sketch a scenario to make the projected breakage explicit:
Let's say my package foo Depends on libblas3 | libblas.so.3. Now
foo:i386 is installed, but the alternative is chosen to be served from
libblas3:amd64. Since libatlas3-base:i386 provides libblas.so.3:i386, I
can install foo that way, but it will fail to work. This is exactly what
happened on #760821.
Helmut and I think you need to move the libblas.so.3
symlink into arch-qualified subdirectories and manage
multiple alternatives, one per architecture.
By managing per-architecture alternatives libblas.so.3 is only provided
when it is actually available. I am not sure how much code this
transition would break. From a quick glance, all providers (atlas, blas,
...) need to be updated. In addition, python-scipy will have its test
suite broken. Probably more.
Helmut suggested to just add Conflicts: libblas.so.3
to all providers of the libblas.so.3 virtual package,
so they are not coïnstallable, then drop the alternatives
Geraffel and just use normal M-A coïnstallability. Please
do enlighten us to the reason of this alternatives system ???
Dropping the alternatives handling is optional here (, but after adding
conflicts there can only be one provider at any one time, so it is kinda
useless). This is the quick and dirty solution that will make the
breakage go away now.
There is yet another workaround to the issue at hand. The blas providers
could provide an additional package (for internal consumption only)
named libblas.so.3-${DEB_HOST_ARCH} and conflict this particular
package for all other (release) architectures. That would ensure that
all blas providers would always use the same architecture without
sacrificing the ability to install multiple providers for the same
architecture.
Further down the road, replacing the update-alternatives mechanism with
tiny meta packages containing just the symbolic link would also work.
The existing packages would drop their provides libblas.so.3 and new
packages shipping just that symlink would provide and conflict
libblas.so.3. Sadly, this introduces quite a few small packages.
Helmut
--
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#760936: BLAS: not Multi-Arch safe
Le mardi 09 septembre 2014 à 11:11 +0200, Thorsten Glaser a écrit : Helmut and I think you need to move the libblas.so.3 symlink into arch-qualified subdirectories and manage multiple alternatives, one per architecture. I think this is the way to go. It will have to wait for the release of Jessie though, because we are too late in the current cycle to make that change. Helmut suggested to just add Conflicts: libblas.so.3 to all providers of the libblas.so.3 virtual package, so they are not coïnstallable, then drop the alternatives Geraffel and just use normal M-A coïnstallability. Please do enlighten us to the reason of this alternatives system ☺ Because it is useful to be able to switch between Netlib BLAS, ATLAS and OpenBLAS without using the package manager. So, introducing conflicts between the various implementations is a regression from my POV, and I won't do that. Thanks for your feedback, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part -- 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 adolc_2.5.2-1_amd64.changes
adolc_2.5.2-1_amd64.changes uploaded successfully to localhost along with the files: libadolc-dev_2.5.2-1_amd64.deb libadolc2_2.5.2-1_amd64.deb adolc_2.5.2-1.dsc adolc_2.5.2.orig.tar.gz adolc_2.5.2-1.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.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#760936: BLAS: not Multi-Arch safe
S�bastien Villemot dixit: Le mardi 09 septembre 2014 à 11:11 +0200, Thorsten Glaser a écrit : Helmut and I think you need to move the libblas.so.3 symlink into arch-qualified subdirectories and manage multiple alternatives, one per architecture. I think this is the way to go. It will have to wait for the release of Jessie though, because we are too late in the current cycle to make that change. This is a very bold statement, considering we are dealing with realistic application breakage (as M-A is projected as “the solution” by more and more people) here. bye, //mirabilos -- emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;) Hallo, ich bin der Holger (Hallo Holger!), und ich bin ebenfalls ... pine-User, und das auch noch gewohnheitsmäßig (Oooohhh). [aus dasr] -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
adolc_2.5.2-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 09 Sep 2014 13:30:02 +0100 Source: adolc Binary: libadolc-dev libadolc2 Architecture: source amd64 Version: 2.5.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Science Maintainers debian-science-maintainers@lists.alioth.debian.org Changed-By: Barak A. Pearlmutter b...@debian.org Description: libadolc-dev - ADOLC development libs and headers libadolc2 - ADOLC automatic differentiation system, runtime libs Changes: adolc (2.5.2-1) unstable; urgency=medium . * New Upstream Version Checksums-Sha1: 10fa7bda8feffda8e409fee45f976773f38da163 2032 adolc_2.5.2-1.dsc 6a17cb179dcbc59edc45c97b8928a2ebfa1e2c38 2320010 adolc_2.5.2.orig.tar.gz 07b62d17865fd1acb3a5e350bef4e694d84dee5b 10460 adolc_2.5.2-1.debian.tar.xz df0f5d964392043d782f5235b2e2de6f26ccef2a 1002730 libadolc-dev_2.5.2-1_amd64.deb d8e0353587192deafeb1685de384ef7209f9192f 227130 libadolc2_2.5.2-1_amd64.deb Checksums-Sha256: 67ee29791f58f0a8f33c6fbde5f5189ca23f374225406b3929d5df9e5dd18a5e 2032 adolc_2.5.2-1.dsc 2fa514d9799989d6379738c2bcf75070d9834e4d227eb32a5b278840893b2af9 2320010 adolc_2.5.2.orig.tar.gz 714b5399866030fd1c07ba13281978b8bf1d0bf8d0f20af71ac7f9f017f3bc83 10460 adolc_2.5.2-1.debian.tar.xz 5108bcd829bb7c60c3209181dfa85cf9a099b2e5654d3246652e0a51589e16a9 1002730 libadolc-dev_2.5.2-1_amd64.deb 8312d213cf7b1f12dc07a0eb2c62286f7bb99a2175f2b4a0520f713e8aab3d54 227130 libadolc2_2.5.2-1_amd64.deb Files: 74569f1463296b5b789c041e1e97e48e 1002730 libdevel optional libadolc-dev_2.5.2-1_amd64.deb d57d7b9faae0bfb6394d35f998b8b188 227130 libs optional libadolc2_2.5.2-1_amd64.deb 1d635143f175ad8bb9bdf778ec4f1f31 2032 libs optional adolc_2.5.2-1.dsc 96f81b80e93cca57398066ea4afe28f0 2320010 libs optional adolc_2.5.2.orig.tar.gz 34c9638377f2d671b6c5ed8d5c7f3bc6 10460 libs optional adolc_2.5.2-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUDvPyAAoJEBJbV0deGQ0Yy6sP/ivUtlqdVjU0LwKlZs9IO8j1 7RcpmzimNCwCh4rAXWBqzPnSJqYhQcDhc6e2fMBV3nILBgW0UvkdJVktm1tz+iRx d9XhviXJMoVbRbzAoK/bqhGzQILcrtpBJDUEHo9uXOKrsWGomOC/WuyVFCuKnkeU epcqrYlPTRYfhgXLYtGllcQhteBBUNbh7d9n6dbn/nsMck8lwH9O7BsejPIcLUey Y9Zd//kggttXleYcdd1LtB/6tRK1pjuc7vnI3ybuC6/uNKKVwMhvNwfBD3l3J44/ Qlkzwixhwp14aoLgGQrORUI0RTye6RyUT+J02ltWfHPeoUqS42odRSjKf+iOURTJ +40UEnJmGIKQNklHypep6FJvQX4IYFOI5TQ9YOwpPrlVHGub3atjkAIShXWYyMLD 0yIZJYEhFezQCYGDQCaXTm4VE9wCoMOhqT6o17zZt0eyamDPBoJcZ8OT9kJomoUU YB7qdigaiqI3fsQBC5J6D7ukhGc7yWP56wFh7pnKpVCR0o9kTqrn0ZFTk6+OaVkE qwZIUEUNOV3p8YJf8YiW91QSY73+23M4x6eNlw7lYEyYarUsSoWqpfk1lIWrrcUU fcsgAmhEp27XmtTmz9NRLwEfJuJPT8vg4JTkLBDpxrkyOkwvjgkkOXY+4/PT5WY9 z7Bls3eiP4QvPh5Iej60 =OT/W -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#760936: BLAS: not Multi-Arch safe
Le mardi 09 septembre 2014 à 12:37 +, Thorsten Glaser a écrit : Sbastien Villemot dixit: Le mardi 09 septembre 2014 à 11:11 +0200, Thorsten Glaser a écrit : Helmut and I think you need to move the libblas.so.3 symlink into arch-qualified subdirectories and manage multiple alternatives, one per architecture. I think this is the way to go. It will have to wait for the release of Jessie though, because we are too late in the current cycle to make that change. This is a very bold statement, considering we are dealing with realistic application breakage (as M-A is projected as “the solution” by more and more people) here. Essentially this is a wishlist bug, because BLAS implementations have never been multi-arch safe (and the packages are not marked as M-A:same). The particular situation that you are describing is due to someone using one BLAS implementation on one arch and another implementation on the other arch, which is essentially an attempt to circumvent the fact that BLAS packages are not M-A:same. So far nobody has complained about the non availability of multi-arch for BLAS. You are now rightfully raising this issue, and it will be dealt with, but it does not make it automatically urgent. Given that transitions are now frozen for Jessie, and given that the freeze is less than 2 months ahead, I think that this is too big a change to be implemented now, for several reasons: it involves multiple packages (blas, lapack, atlas, openblas); it needs coordinated changes in those packages, which means that they must all transition to testing at the same time; the change is tricky because it involves lots of code in maintainer scripts, with possible problems on upgrade paths; I will have almost no time in October for Debian. If you come up soon with working patches for these 4 packages, I will do my best to review and upload them. Otherwise I don't think that this move is realistic before the freeze. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part -- 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 mlpack_1.0.10-1_amd64.changes
mlpack_1.0.10-1_amd64.changes uploaded successfully to localhost along with the files: libmlpack-dev_1.0.10-1_amd64.deb libmlpack1_1.0.10-1_amd64.deb mlpack-bin_1.0.10-1_amd64.deb mlpack-doc_1.0.10-1_all.deb mlpack_1.0.10-1.dsc mlpack_1.0.10.orig.tar.gz mlpack_1.0.10-1.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.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#760936: BLAS: not Multi-Arch safe
I think you are getting this wrong. On Tue, Sep 09, 2014 at 02:06:37PM +0100, Sébastien Villemot wrote: Essentially this is a wishlist bug, because BLAS implementations have never been multi-arch safe (and the packages are not marked as M-A:same). The particular situation that you are describing is due to The Multi-Arch spec tried to make all packages Multi-Arch safe by default. In particular, most packages that are not M-A:same are Multi-Arch safe. libblas3 is not. It can lead to a situation where dependencies are satisfied, but the resulting installation is non-functional. someone using one BLAS implementation on one arch and another implementation on the other arch, which is essentially an attempt to circumvent the fact that BLAS packages are not M-A:same. This doesn't have to be an active choice of the user. It can just happen that you enabled i386 on your amd64 box (as is recommended in the release notes for running software like skype), that apt will pull in a foreign-arch implementation of blas, because the meta data tells that this would work, while it doesn't. This bug is not about making blas M-A:same (which would be wishlist), but about blas not breaking after adding a foreign architecture. Given that transitions are now frozen for Jessie, and given that the freeze is less than 2 months ahead, I think that this is too big a change to be implemented now, for several reasons: it involves multiple packages (blas, lapack, atlas, openblas); it needs coordinated changes in those packages, which means that they must all transition to testing at the same time; the change is tricky because it involves lots of code in maintainer scripts, with possible problems on upgrade paths; I will have almost no time in October for Debian. I agree that any way to solve this issue involves severe changes, which may be unsuitable for jessie. But for jessie we do not have to Multi-Arch blas. It suffices to make it Multi-Arch safe. If you come up soon with working patches for these 4 packages, I will do my best to review and upload them. Otherwise I don't think that this move is realistic before the freeze. Let me propose another funky workaround for jessie: Introduce a new, empty arch:any package (whose sole purpose is to exist). Do not mark it as Multi-Arch anything (this is crucial and why you cannot reuse things like libc6 or dpkg for this). Then have all blas implementations depend on this package. Any blas implementation being installed will pull in the new package for the architecture. Any other blas implementation will only be installable for the same architecture now. Even though, this goes through NEW and has to touch at least four packages, it does not cause a transition. It also does not cause the update-alternatives handling to change. What do you think? Helmut -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
scscp-imcce 1.0.1+ds-1 MIGRATED to testing
FYI: The status of the scscp-imcce source package in Debian's testing distribution has changed. Previous version: 1.0.0+ds-2 Current version: 1.0.1+ds-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
What Can You Learn From Apple Just Before Their Event
What Digital Publishers Can Learn From Apple Before Their Event = PressPad’s lead iOS developer Simon Fortuna gives a glimpse at what to expect from Apple’s special event and the introduction of iOS 8... KEEP READING » ( http://bit.ly/1Av1uBK ) Thank you for your time reading this article. If you like our newsletters give us a little bit of love on Social Media. Thanks for all your Likes ( https://www.facebook.com/presspad ) and Follows ( https://twitter.com/presspadapp )! - Michael Opydo To unsubscribe please click here ( http://email.presspadmail.com/wf/unsubscribe?upn=GA3tWWLb1-2FLi-2BYT1t27j3JLLUFaQ4VTCTdtdpdIIUs-2B9uIMZ4SpZMTx-2BzOVitvDxgDk1OVWnoj1arnOrt1GnDIzmdudrOuA96p-2BVdlwq0igvnfOs7FHKhFJni2zwIcTHT8KxwgUsRk54BpktXBDEhMa2I-2BzUF2PeILXOQPPg0ahBjPucxfw6P3-2BAQ10nXBL2c5lRU-2BZ8rOGA9Q3cugELuB-2B4qhsPvrJbR531gbL3qdqs6BJyqZRw-2BGJTGsbojzIG4Alp2qkjcwlRGBH7jNSeCaI-2FYV-2BNG6zJ7GC208r4PCnZjns0h2Eu7Zbw8a8GOuq9gwwK80SejGMSD9w9HM0aQpDp5-2BbxyX64YLkVG-2FQsRByxG3qsp7YNkIIf-2BjSSSQ8uqhvgIIpt-2BRBpsQcefBB8iQac9jhawfPWilSuUklg5gPmC4z7lJzDV3RHsNXRfOlN ) Michael from PressPad Kupa 3/12, Krakow, 31-057 In case you are here by mistake, please feel free to unsubscribe...-- 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#760936: BLAS: not Multi-Arch safe
Le mardi 09 septembre 2014 à 15:17 +0200, Helmut Grohne a écrit : Given that transitions are now frozen for Jessie, and given that the freeze is less than 2 months ahead, I think that this is too big a change to be implemented now, for several reasons: it involves multiple packages (blas, lapack, atlas, openblas); it needs coordinated changes in those packages, which means that they must all transition to testing at the same time; the change is tricky because it involves lots of code in maintainer scripts, with possible problems on upgrade paths; I will have almost no time in October for Debian. I agree that any way to solve this issue involves severe changes, which may be unsuitable for jessie. But for jessie we do not have to Multi-Arch blas. It suffices to make it Multi-Arch safe. If you come up soon with working patches for these 4 packages, I will do my best to review and upload them. Otherwise I don't think that this move is realistic before the freeze. Let me propose another funky workaround for jessie: Introduce a new, empty arch:any package (whose sole purpose is to exist). Do not mark it as Multi-Arch anything (this is crucial and why you cannot reuse things like libc6 or dpkg for this). Then have all blas implementations depend on this package. Any blas implementation being installed will pull in the new package for the architecture. Any other blas implementation will only be installable for the same architecture now. Even though, this goes through NEW and has to touch at least four packages, it does not cause a transition. It also does not cause the update-alternatives handling to change. What do you think? Thanks for suggesting this alternative solution, which I think is a good compromise for jessie. It is a bit ugly, but I don't see any other way of forbidding M-A co-installability of two different packages. Hopefully the ftpmasters won't oppose this. I'll try to implement this soon. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Un chauffage l'hiver et une climatisation l'été
La pompe à chaleurLa solution chauffage / climatisation économique et écologique Vous recevez cet email car vous êtes inscrit à la base Net-Lead. Si le message ci-dessous ne s'affiche pas correctement, vous pouvez consulter la version en ligne. (http://front.netlead-email.com/php/emailing/view_mail.php?CODE=687KXP23_52811HASH=51caf38266da667724a3cab8ada47581) La pompe à chaleurLa solution chauffage / climatisationéconomique et écologique FAITES VOTRE DEMANDE SUR LE SITE (http://id218.r.netlead-email.com/clic2/index.php?m=PACclic_netl09_0914email=debian-science-maintainers@lists.alioth.debian.org) NOUS CIBLONS LES PROS PRES DE CHEZ VOUS (http://id218.r.netlead-email.com/clic2/index.php?m=PACclic_netl09_0914email=debian-science-maintainers@lists.alioth.debian.org) VOUS RECEVEZ JUSQU'A 4 DEVIS (http://id218.r.netlead-email.com/clic2/index.php?m=PACclic_netl09_0914email=debian-science-maintainers@lists.alioth.debian.org) (http://id218.r.netlead-email.com/clic2/index.php?m=PACclic_netl09_0914email=debian-science-maintainers@lists.alioth.debian.org) Prenez 1 minute pour faire votre demande. Et si vous installiez une pompe à chaleur? NOUVEAU : 1 minute suffit pour réaliser votre demande interactive sans engagement Profitez des conseils des professionels pour tout savoir sur les pompes à chaleur: Economies réalisables, délai de mise en place, qualité des produits, cout d'une installation ... Vous pourrez ainsi comparer les offres et faire le bon choix. La nouvelle ergonomie de ce site, permet de formuler votre demande personnelle en un temps record ... Cliquez icipour Commencer (http://id218.r.netlead-email.com/clic2/index.php?m=PACclic_netl09_0914email=debian-science-maintainers@lists.alioth.debian.org) (http://id218.r.netlead-email.com/clic2/index.php?m=PACclic_netl09_0914email=debian-science-maintainers@lists.alioth.debian.org) En application de la loi «Informatique et Liberté», vous disposez d'un droit d'accès, de rectification et d'opposition sur les données vous concernant. Si vous souhaitez accéder à vos données personnelles, les rectifier ou ne plus recevoir de propositions commerciales par l'intermédiaire de Net-Lead, il vous suffit de le signaler à NET-LEAD 12, avenue Maurice Thorez 94200 Ivry sur Seine ou sur cette page. (http://id12.r.netlead-email.com) Si vous voulez vous deacute;sinscrire, a href=http://front.netlead-email.com/php/emailing/u.php?CODE=687KXP23_52811HASH=51caf38266da667724a3cab8ada47581;suivre ce lien/a-- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
