silx is marked for autoremoval from testing
silx 0.12.0+dfsg-1 is marked for autoremoval from testing on 2020-08-10 It (build-)depends on packages with these RC bugs: 957694: pocl: ftbfs with GCC-10 963818: numpy, src:python-fabio: numpy breaks python-fabio autopkgtest: fabio.test.codecs.test_brukerimage.TestBrukerLinear fails -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
binoculars is marked for autoremoval from testing
binoculars 0.0.4-1 is marked for autoremoval from testing on 2020-08-10 It (build-)depends on packages with these RC bugs: 957694: pocl: ftbfs with GCC-10 963818: numpy, src:python-fabio: numpy breaks python-fabio autopkgtest: fabio.test.codecs.test_brukerimage.TestBrukerLinear fails -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
python-fabio is marked for autoremoval from testing
python-fabio 0.10.2+dfsg-1 is marked for autoremoval from testing on 2020-08-10 It is affected by these RC bugs: 963818: numpy, src:python-fabio: numpy breaks python-fabio autopkgtest: fabio.test.codecs.test_brukerimage.TestBrukerLinear fails -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
sleef is marked for autoremoval from testing
sleef 3.4.1-3 is marked for autoremoval from testing on 2020-08-21 It is affected by these RC bugs: 957809: sleef: ftbfs with GCC-10 -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
pyfai is marked for autoremoval from testing
pyfai 0.19.0+dfsg1-3 is marked for autoremoval from testing on 2020-08-10 It (build-)depends on packages with these RC bugs: 957694: pocl: ftbfs with GCC-10 963818: numpy, src:python-fabio: numpy breaks python-fabio autopkgtest: fabio.test.codecs.test_brukerimage.TestBrukerLinear fails -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
hello
Hello how are you doing ? please did you get my mail to you? am waiting for your reply? Hallo, wie geht es dir ? hast du bitte meine mail bekommen Ich warte auf deine Antwort? -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#966125: marked as done (x13as: FTBFS with GCC 10: Error: More actual than formal arguments in procedure call)
Your message dated Fri, 24 Jul 2020 11:24:13 + with message-id and subject line Bug#966125: fixed in x13as 1.1-B39-2 has caused the Debian Bug report #966125, regarding x13as: FTBFS with GCC 10: Error: More actual than formal arguments in procedure call 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.) -- 966125: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966125 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: x13as Version: 1.1-B39-1 Severity: serious Tags: ftbfs sud bullseye Justification: fails to build from source User: debian-...@lists.debian.org Usertags: ftbfs-gcc-10 Hi, x13as started to FTBFS when GCC 10 was made the default compiler: [...] gfortran -g -O2 -fdebug-prefix-map=/build/x13as-1.1-B39=. -fstack-protector-strong -c -o gtinpt.o gtinpt.f gfortran -g -O2 -fdebug-prefix-map=/build/x13as-1.1-B39=. -fstack-protector-strong -c -o gtinvl.o gtinvl.f gfortran -g -O2 -fdebug-prefix-map=/build/x13as-1.1-B39=. -fstack-protector-strong -c -o gtmdfl.o gtmdfl.f gtinpt.f:709:72: 709 | & 'same input file.',T) |1 Error: More actual than formal arguments in procedure call at (1) gtinpt.f:819:72: 819 | & 'same input file.',T) |1 Error: More actual than formal arguments in procedure call at (1) make[2]: *** [: gtinpt.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/build/x13as-1.1-B39' make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2 make[1]: Leaving directory '/build/x13as-1.1-B39' make: *** [debian/rules:12: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 More information about the corresponding GCC changes can be found here: https://gcc.gnu.org/gcc-10/porting_to.html Andreas x13as_1.1-B39-1.log.gz Description: application/gzip --- End Message --- --- Begin Message --- Source: x13as Source-Version: 1.1-B39-2 Done: =?utf-8?q?S=C3=A9bastien_Villemot?= We believe that the bug you reported is fixed in the latest version of x13as, 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 966...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sébastien Villemot (supplier of updated x13as 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: Fri, 24 Jul 2020 12:56:44 +0200 Source: x13as Architecture: source Version: 1.1-B39-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Team Changed-By: Sébastien Villemot Closes: 966125 Changes: x13as (1.1-B39-2) unstable; urgency=medium . * Add -std=legacy to FFLAGS, needed since gfortran 10 (Closes: #966125) * Bump to debhelper 13 * Bump S-V to 4.5.0 Checksums-Sha1: 13e6e453f7bc585274f0509ae5a05c24a27937e3 1950 x13as_1.1-B39-2.dsc e23b040feb13e6f4af2fe5908eb90a8ae539bae3 5012 x13as_1.1-B39-2.debian.tar.xz dc6af3fcc4861aab285a3bbad1d40443efac4a21 5884 x13as_1.1-B39-2_amd64.buildinfo Checksums-Sha256: fabc195d93611d8b4fa0d7d0b6edc21825192a80ef1428205f472e43373a7841 1950 x13as_1.1-B39-2.dsc 3062640d4ae7c4efe29cae916bcf13ee1e7fde8a27df85c8d21580a928838342 5012 x13as_1.1-B39-2.debian.tar.xz 5d22ef22de5cf34320618b3ba6e855029b77e4b0fc83674fd564c8b6bc14fc6a 5884 x13as_1.1-B39-2_amd64.buildinfo Files: 5a7a3816410ac7c2cad9fa4817abe423 1950 non-free/science optional x13as_1.1-B39-2.dsc d39c76868a988996afa5592469dc6df2 5012 non-free/science optional x13as_1.1-B39-2.debian.tar.xz 7eef0dcfa1d9019fba65a85cc94d36a8 5884 non-free/science optional x13as_1.1-B39-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEU5UdlScuDFuCvoxKLOzpNQ7OvkoFAl8avyUACgkQLOzpNQ7O vkrkHA//c7y+l0A7q/DL+quU758OWur6Gsd6WndW8ka0hJIKC6DyV/QMerub23zF pFpngJwEoGUBYZbOuHMyUtPcKXmI/1+51atAu4RpPJjzzoysA5fweRUZdBfiMVUQ LjpJHmGgw9Q7tBa0qOZQ5tGXvzDYihlP36qb4Z2uun600FWvYKKjfesVM0wlnlLF 6O1ww7sAyEcx1NqQ6D7AQVCj97je1MlS1j0ObQMbTyTRFFARsXYSGMTnVH5cBjO8 57DySW39JTTxBo04BW34Uk+NLjDcp8ObwWy7Z98s0Dw7SimmCR8ibf2/GI7YINMx
x13as_1.1-B39-2_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 24 Jul 2020 12:56:44 +0200 Source: x13as Architecture: source Version: 1.1-B39-2 Distribution: unstable Urgency: medium Maintainer: Debian Science Team Changed-By: Sébastien Villemot Closes: 966125 Changes: x13as (1.1-B39-2) unstable; urgency=medium . * Add -std=legacy to FFLAGS, needed since gfortran 10 (Closes: #966125) * Bump to debhelper 13 * Bump S-V to 4.5.0 Checksums-Sha1: 13e6e453f7bc585274f0509ae5a05c24a27937e3 1950 x13as_1.1-B39-2.dsc e23b040feb13e6f4af2fe5908eb90a8ae539bae3 5012 x13as_1.1-B39-2.debian.tar.xz dc6af3fcc4861aab285a3bbad1d40443efac4a21 5884 x13as_1.1-B39-2_amd64.buildinfo Checksums-Sha256: fabc195d93611d8b4fa0d7d0b6edc21825192a80ef1428205f472e43373a7841 1950 x13as_1.1-B39-2.dsc 3062640d4ae7c4efe29cae916bcf13ee1e7fde8a27df85c8d21580a928838342 5012 x13as_1.1-B39-2.debian.tar.xz 5d22ef22de5cf34320618b3ba6e855029b77e4b0fc83674fd564c8b6bc14fc6a 5884 x13as_1.1-B39-2_amd64.buildinfo Files: 5a7a3816410ac7c2cad9fa4817abe423 1950 non-free/science optional x13as_1.1-B39-2.dsc d39c76868a988996afa5592469dc6df2 5012 non-free/science optional x13as_1.1-B39-2.debian.tar.xz 7eef0dcfa1d9019fba65a85cc94d36a8 5884 non-free/science optional x13as_1.1-B39-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEU5UdlScuDFuCvoxKLOzpNQ7OvkoFAl8avyUACgkQLOzpNQ7O vkrkHA//c7y+l0A7q/DL+quU758OWur6Gsd6WndW8ka0hJIKC6DyV/QMerub23zF pFpngJwEoGUBYZbOuHMyUtPcKXmI/1+51atAu4RpPJjzzoysA5fweRUZdBfiMVUQ LjpJHmGgw9Q7tBa0qOZQ5tGXvzDYihlP36qb4Z2uun600FWvYKKjfesVM0wlnlLF 6O1ww7sAyEcx1NqQ6D7AQVCj97je1MlS1j0ObQMbTyTRFFARsXYSGMTnVH5cBjO8 57DySW39JTTxBo04BW34Uk+NLjDcp8ObwWy7Z98s0Dw7SimmCR8ibf2/GI7YINMx VdoxKR7mPPxb+zgD1x7jX6cZhiXpUX+WKmvggP5feFZ5oXzop3bHeeNVuD3aa44l IsG+H91CQL5TYAHbiYzpxn4kWMJ41IzKuWopVXE88eGvjW/0WzFnQKsAr14SrjCv Vbw5UzG25SJw5jvP1lNohcxQ92HNYc3YsBwVqs+iAwcYrBdTWb6Cgvy/QvNyLKnn pX9ju6csaZZYbDJmLQtfP9s9J3sjKVDILn+xwxGVBfh9udAYM0OzSGbgrdkcu7xW 2KbAgvB8rwZiRY5iqs9xONiylsOTwc5+zGZXmS0txTyu2iC5cheMSfcgp9SJTnPs opP515bmntInnj+2WCWtCJk0+gr0vJcJlB/XnY1R9IQZdZNCtKI= =5QLJ -END PGP SIGNATURE- Thank you for your contribution to Debian. -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#966175: libopenblas0-pthread: segfault in scipy tests: calls Haswell
Le vendredi 24 juillet 2020 à 19:00 +0800, Drew Parsons a écrit : > On 2020-07-24 18:46, Sébastien Villemot wrote: > > Haswell is 4th generation Intel core, while Whiskey Lake is 8th/9th > > generation, hence much more recent. So Whiskey Lake is perfectly able > > to run Haswell assembly code. The cause of the bug must lie somewhere > > else. > > OK. > > BTW it does pass with selected values of OPENBLAS_CORETYPE (cf. > Bug#930482) > > This does pass: >OPENBLAS_CORETYPE=core2 python3 -m pytest > /usr/lib/python3/dist-packages/scipy/cluster/tests/test_vq.py -k > "krandinit" -v Thanks. So that might indicate that the problem lies in the Haswell kernel (which is used on all Intel CPUs that have AVX2 but not AVX512, which means most recent CPUs). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#966175: libopenblas0-pthread: segfault in scipy tests: calls Haswell
On 2020-07-24 18:46, Sébastien Villemot wrote: Haswell is 4th generation Intel core, while Whiskey Lake is 8th/9th generation, hence much more recent. So Whiskey Lake is perfectly able to run Haswell assembly code. The cause of the bug must lie somewhere else. OK. BTW it does pass with selected values of OPENBLAS_CORETYPE (cf. Bug#930482) This does pass: OPENBLAS_CORETYPE=core2 python3 -m pytest /usr/lib/python3/dist-packages/scipy/cluster/tests/test_vq.py -k "krandinit" -v -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Processing of x13as_1.1-B39-2_source.changes
x13as_1.1-B39-2_source.changes uploaded successfully to localhost along with the files: x13as_1.1-B39-2.dsc x13as_1.1-B39-2.debian.tar.xz x13as_1.1-B39-2_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org) -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#966179: jskeus: please make the build reproducible
Source: jskeus
Version: 1.2.4+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0] we noticed that
jskeus could not be built reproducibly.
This is because it generates a different usr/share/euslisp/irteus/test.c
depending on whether /bin/sh is dash or bash:
-#include "eus.h"
-#undef defun
-pointer TEST();
-void test(void) {register context *ctx; pointer mod;
defun(ctx,"TEST",mod,TEST,NULL);}
+#include "eus.h"\n#undef defun\npointer TEST();\nvoid test(void) {register
context *ctx; pointer mod; defun(ctx,"TEST",mod,TEST,NULL);}
(Patch attached that uses printf instead.)
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 01:00:00.0
+0100
--- b/debian/patches/reproducible-build.patch 2020-07-24 11:45:11.440551173
+0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2020-07-24
+
+--- jskeus-1.2.4+dfsg.orig/irteus/Makefile
jskeus-1.2.4+dfsg/irteus/Makefile
+@@ -177,7 +177,7 @@ MKDIR:
+
+ .PHONY: defun.h
+ defun.h:
+- echo '#include "eus.h"\n#undef defun\npointer TEST();\nvoid test(void)
{register context *ctx; pointer mod; defun(ctx,"TEST",mod,TEST,NULL);}' > test.c
++ printf '#include "eus.h"\n#undef defun\npointer TEST();\nvoid
test(void) {register context *ctx; pointer mod;
defun(ctx,"TEST",mod,TEST,NULL);}\n' > test.c
+ echo "// redefine defun for update defun() API ()
https://github.com/euslisp/EusLisp/pull/116; > defun.h
+ echo "#undef defun" >> defun.h
+ $(CC) $(CFLAGS) $(WFLAGS) -c test.c $(OBJOPT) test.o || echo "#define
defun(a, b, c, d, e) defun(a, b, c, d) // for EusLisp < 9.24" >> defun.h
--- a/debian/patches/series 2020-07-24 11:29:15.620084291 +0100
--- b/debian/patches/series 2020-07-24 11:45:10.440537576 +0100
@@ -2,3 +2,4 @@
makefile-for-debian.patch
fix-make-clean.patch
+reproducible-build.patch
--
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#966175: libopenblas0-pthread: segfault in scipy tests: calls Haswell
Hi Drew, Thanks for the report. Le vendredi 24 juillet 2020 à 18:28 +0800, Drew Parsons a écrit : > So looks like the bug is that libopenblas0-pthread is invoking haswell > code on non-haswell systems. cpu.userbenchmark.com tells me that > i5-8365U is Whiskey Lake not Haswell Haswell is 4th generation Intel core, while Whiskey Lake is 8th/9th generation, hence much more recent. So Whiskey Lake is perfectly able to run Haswell assembly code. The cause of the bug must lie somewhere else. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#966175: libopenblas0-pthread: segfault in scipy tests: calls Haswell
Package: libopenblas0-pthread Version: 0.3.10+ds-1 Severity: normal Two (or at least 2) tests in scipy are segfaulting specifically with libopenblas0-pthread. If I configure alternatives to set libblas.so.3-x86_64-linux-gnu and liblapack.so.3-x86_64-linux-gnu to generic reference blas then the tests pass. The libblas.so segfault occurs with both scipy 1.4.1-2 (unstable) and 1.5.2-1 (experimental). The liblapack.so segfault occurs with scipy 1.5.2-1 but passes in 1.4.1-2 The segfaults can be reproduced manually (with python3-scipy installed and blas/lapack configured to libopenblas0-pthread): python3 -m pytest /usr/lib/python3/dist-packages/scipy/cluster/tests/test_vq.py -k "krandinit" -v python3 -m pytest /usr/lib/python3/dist-packages/scipy/linalg/tests/test_decomp.py -v (the second test here is the one that fails with scipy 1.5.2-1 in test_orth_memory_efficiency, passes with 1.4.1-2. It also passes when run on its own with -k "test_orth_memory_efficiency") gdb backtraces show libopenblas0-pthread is inculpated: $ gdb python3 > run -m pytest /usr/lib/python3/dist-packages/scipy/cluster/tests/test_vq.py > -k "krandinit" -v ../../../../../../usr/lib/python3/dist-packages/scipy/cluster/tests/test_vq.py::TestKMean::test_krandinit Thread 2 "python3" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x74b6a700 (LWP 1589273)] 0x75c8d284 in dgemm_oncopy_HASWELL () from /lib/x86_64-linux-gnu/libblas.so.3 (gdb) bt #0 0x75c8d284 in dgemm_oncopy_HASWELL () from /lib/x86_64-linux-gnu/libblas.so.3 #1 0x74d2a7c5 in ?? () from /lib/x86_64-linux-gnu/libblas.so.3 #2 0x74e3098d in ?? () from /lib/x86_64-linux-gnu/libblas.so.3 #3 0x77f62ea7 in start_thread (arg=) at pthread_create.c:477 #4 0x77cf7daf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 $ gdb python3 > run -m pytest > /usr/lib/python3/dist-packages/scipy/linalg/tests/test_decomp.py -v ... ../../../../../../usr/lib/python3/dist-packages/scipy/linalg/tests/test_decomp.py::TestOverwrite::test_svd PASSED [ 92%] ../../../../../../usr/lib/python3/dist-packages/scipy/linalg/tests/test_decomp.py::TestOverwrite::test_svdvals PASSED [ 92%] ../../../../../../usr/lib/python3/dist-packages/scipy/linalg/tests/test_decomp.py::test_orth_memory_efficiency Thread 9 "python3" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe0e10700 (LWP 1589405)] 0x7fffe27cc284 in dgemm_oncopy_HASWELL () from /lib/x86_64-linux-gnu/liblapack.so.3 (gdb) bt #0 0x7fffe27cc284 in dgemm_oncopy_HASWELL () from /lib/x86_64-linux-gnu/liblapack.so.3 #1 0x7fffe18aeb62 in ?? () from /lib/x86_64-linux-gnu/liblapack.so.3 #2 0x7fffe1943c4d in ?? () from /lib/x86_64-linux-gnu/liblapack.so.3 #3 0x77f62ea7 in start_thread (arg=) at pthread_create.c:477 #4 0x77cf7daf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 In both cases the segfault happens at dgemm_oncopy_HASWELL. Probably worth mentioned I'm not using a haswell system: $ cat /proc/cpuinfo | grep 'model name' | uniq model name: Intel(R) Core(TM) i5-8365U CPU @ 1.60GHz So looks like the bug is that libopenblas0-pthread is invoking haswell code on non-haswell systems. cpu.userbenchmark.com tells me that i5-8365U is Whiskey Lake not Haswell For completeness I tested other BLAS: openblas-openmp: FAIL (calls dgemm_oncopy_HASWELL) openblas-serial: PASS blis-pthread: PASS blis-openmp: PASS atlas:PASS -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU threads) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libopenblas0-pthread depends on: ii libc6 2.31-2 ii libgfortran5 10.1.0-6 libopenblas0-pthread recommends no packages. libopenblas0-pthread suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Twój profil na Facebooku, zobacz.
Witam, kreowanie wizerunku orazpozyskiwanie, klientów na Facebookuto nasza specjalność. Dobra reklama jest dźwignią handlu - zwłaszcza we współczesnym świecie. Wyślij odpowiedź o treścizgoda w odpowiedzi na ten e-mail abyśmy mogli przedstawić szczegóły naszej oferty. - Pozdrawiamy, Profesjonalne Social Media Aby nie otrzymywać od nas więcej wiadomości odpisz na tego maila, słowem: wypisz w temacie wiadomości oraz wypisz w treści. Ewentualnie przejdź tutaj -- debian-science-maintainers mailing list debian-science-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
