Bug#1017249: rheolef: FTBFS: ../../include/rheolef/communicator.h:112:25: error: expected initializer before ‘size’
Dear Lucas, Many thanks for reporting this bug. I've just tried to reproduce it with sid (g++ 12.2.0-1) and bookwork (g++ 12.1.0-3): the package built successfully in both cases. I used pbuilder together with all the up-to-date package versions. So, please could you try to rebuild the rheolef package in Debian (I am not DM) and let me known: probably this bug in rheolef was due to another package (g++?) and could now be closed ? Many thanks for your help, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#984965: HELP needed for uploading a new upstream version of the Rheolef package
Hi Nilesh Patra, > From Nilesh Patra: > I'm a bit confused with the branches though, > isn't debian/sid the branch we should be using for uploads? > Atleast I am seeing prev commits on that branch. > Please move your commits there if that's the case. I'm sorry about that: the prev commits was on the "master" git branch, with improvements from Rafael Laboissière and me. Next, new version 7.2 is on the "master" git branch also. I don't known how to move it now on the "debian/sid" one: a git merge will perhaps now lead to a lot of conflicts ? Is it possible to use the "master" branch instead for uploading ? I don't known wich is the best solution. Many thanks for your help, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito De: "Nilesh Patra" À: "PIERRE SARAMITO" , "Andreas Tille" , "debian-science" , "1007118" <1007...@bugs.debian.org>, "984965" <984...@bugs.debian.org>, "bunk" , "byang" , "rafael" Envoyé: Jeudi 2 Juin 2022 09:38:28 Objet: Re: HELP needed for uploading a new upstream version of the Rheolef package On 2 June 2022 11:57:38 am IST, PIERRE SARAMITO wrote: >I just commit with git a new release 7.2-1 of the debianization of the rheolef >package. >This corresponds to a new version 7.2 of the upstream package > >Could you please upload it in debian ? I can do it later today. I'm a bit confused with the branches though, isn't debian/sid the branch we should be using for uploads? Atleast I am seeing prev commits on that branch. Please move your commits there if that's the case. -- Best, Nilesh
Bug#1007118: HELP needed for uploading a new upstream version of the Rheolef package
Hi all Debian Maintainers, I just commit with git a new release 7.2-1 of the debianization of the rheolef package. This corresponds to a new version 7.2 of the upstream package: https://salsa.debian.org/science-team/rheolef This version closes the two pending outstanding bugs: #1007118 and #984965 The upstream version 7.2 integrates some patches thanks to Nilesh Patra The debianization version 7.2-1 integrates various improvements thanks to Raphael Laboissiere Could you please upload it in debian ? Many thanks for your help. Best wishes, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#985224: unblock: rheolef/ 7.1-6
Dear Boyuan Yang, Many thanks for your fast reply and your fix to the Debian files of the Rheolef package. Are these changes merged now in the master branch of the GIT repository of the debianization of Rheolef ? https://salsa.debian.org/science-team/rheolef Many thanks for your help, Pierre Boyuan Yang a écrit : Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: pierre.saram...@imag.fr debian-scie...@lists.debian.org Please unblock package rheolef [ Reason ] The current version of rheolef in Testing has piuparts error (Buster2Bullseye, missing Breaks+Conflicts) as shown in https://bugs.debian.org/984529 . The current version in Sid targets on fixing this RC bug. [ Impact ] If the bug is not fixed, the upgrade from Debian 10 to Debian 11 will fail when both rheolef and librheolef-dev are installed. [ Tests ] Piuparts test failed for package in Testing but succeeded for package in Sid. See: https://piuparts.debian.org/sid/source/r/rheolef.html [ Risks ] No risk expected. [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing unblock rheolef/ 7.1-6 -- Soutenez la sécurité sociale ! Signez la pétition pour l'hôpital public : https://confinesmobilises.wesign.it
Bug#978088: HELP needed for uploading a new debianisation 7.1-3 of the Rheolef package
Hi Anton, > From Anton Gladky: > sure, I will! Please push your changes in master-branch. It looks > only the tags were pushed. Sorry ! Its done now. Many thanks for your help, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#978088: HELP needed for uploading a new debianisation 7.1-3 of the Rheolef package
Hi Anton, hi all, I just commit with git a new release 7.1-3 of the debianisation of the rheolef package: it fixes bug #978088 (see d/changelog) thanks to a patch by Vagrant Cascadian The upstream version is unchanged (7.1). Could you please upload it in debian ? Many thanks for your help. Best regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#978088: rheolef: reproducible builds: date in various .pdf files
Dear Vagrant, Many thanks for your patch: it has just been integrated in a new release 7.1-3 of the debianization of the Rheolef package. It has also been integrated for the next upstream version. Best wishes, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#971933: HELP needed for uploading a new debianisation of the Rheolef package
Hi Andreas, I just commit with git a new release 7.1-2 of the debianisation of the rheolef package: it fixes a FTBFS bug #971933 (see d/changelog). The upstream version is unchanged (7.1). Could you please upload it in debian ? Many thanks for your help. Best regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#944197: HELP needed for uploading a new upstream version of the Rheolef package
Hi Andreas Tille, From Andreas: Currently I can only support Covid-19 related packages (which we try to assemble in Debian Med team currently) Let me known if I could help the Debian Med team ? I remain "confined" at home, but I could help (test pkg, ect) ? please find some other sponsor from Debian Science project. Is there somebody from the Debian science project to just help me for uploading the Rheolef-7.1-1 pkg ? The debianization is ready and well-tested at https://salsa.debian.org/science-team/rheolef It closes the two FTBFS bugs: #944197 and #946116 Best wishes, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#944197: HELP needed for uploading a new upstream version of the Rheolef package
Hi Andreas, I just commit with git a new release 7.1-1 of the debianisation of the rheolef package. This corresponds to a new version 7.1 of the upstream package: https://salsa.debian.org/science-team/rheolef This version closes the two pending FTBFS bugs: #944197 and #946116 Could you please upload it in debian ? Many thanks for your help. Best regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#954436: openmpi segfault on the stretch(oldstable) distrib
Package: libopenmpi-dev
Version: 2.0.2-2
Severity: important
File: openmpi
Dear Maintainer,
Openmpi segfaut on stretch(oldstable) distrib.
Here is an exemple that reproduces the problem:
cat mpi_tst.cc
#include
int main(int argc, char ** argv) {
MPI_Init(&argc, &argv);
MPI_Finalize();
}
mpic++ mpi_tst.cc
./a.out
*** Process received signal ***
Signal: Segmentation fault (11)
Signal code: Address not mapped (1)
Failing at address: (nil)
[ 0]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7f68c4b7c0e0]
[ 1]
/lib/x86_64-linux-gnu/libc.so.6(strlen+0x26)[0x7f68c484c676]
[ 2]
/lib/x86_64-linux-gnu/libc.so.6(__strdup+0xe)[0x7f68c484c3ae]
[ 3]
/usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_rtc_freq.so(+0x2b95)[0x7f68bc422b95]
[ 4]
/usr/lib/x86_64-linux-gnu/libopen-rte.so.20(orte_rtc_base_select+0xeb)[0x7f68c59eef4b]
[ 5]
/usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi/mca_ess_hnp.so(+0x5391)[0x7f68c37a2391]
[ 6]
/usr/lib/x86_64-linux-gnu/libopen-rte.so.20(orte_init+0x235)[0x7f68c599aaa5]
[ 7]
/usr/lib/x86_64-linux-gnu/libopen-rte.so.20(orte_daemon+0x488)[0x7f68c59b9608]
[ 8] orted(+0x8ea)[0x55e95c37b8ea]
[ 9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f68c47ec2e1]
[10] orted(+0x94a)[0x55e95c37b94a]
*** End of error message ***
[[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the
local node in file ess_singleton_module.c at line 575
[[INVALID],INVALID] ORTE_ERROR_LOG: Unable to start a daemon on the
local node in file ess_singleton_module.c at line 165
--
It looks like orte_init failed for some reason; your parallel
process is
likely to abort. There are many reasons that a parallel
process can
fail during orte_init; some of which are due to configuration or
environment problems. This failure appears to be an internal
failure;
here's some additional information (which may only be relevant
to an
Open MPI developer):
orte_ess_init failed
--> Returned value Unable to start a daemon on the local node
(-127) instead of ORTE_SUCCESS
--
--
It looks like MPI_INIT failed for some reason; your parallel
process is
likely to abort. There are many reasons that a parallel
process can
fail during MPI_INIT; some of which are due to configuration or
environment
problems. This failure appears to be an internal failure;
here's some
additional information (which may only be relevant to an Open
MPI
developer):
ompi_mpi_init: ompi_rte_init failed
--> Returned "Unable to start a daemon on the local node" (-127)
instead of "Success" (0)
--
*** An error occurred in MPI_Init
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will
now abort,
***and potentially your MPI job)
Local abort before MPI_INIT completed completed successfully, but am
not able to aggregate error messages, and not able to guarantee that
all other processes were killed!
-- System Information:
Debian Release: 9.12
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to C), LANGUAGE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to
C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages libopenmpi-dev depends on:
ii libc6 2.24-11+deb9u4
ii libhwloc-dev1.11.5-1
ii libhwloc5 1.11.5-1
ii libibverbs-dev 1.2.1-2
ii libopenmpi2 2.0.2-2
ii openmpi-common 2.0.2-2
libopenmpi-dev recommends no packages.
Versions of packages libopenmpi-dev suggests:
pn openmpi-doc
-- no debconf information
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://ljk.imag.fr/membres/Pierre.Saramito
Bug#954329: paraview: opacity incorrectly handled by the debian bullseye(testing) package paraview-5.7
Package: paraview Version: 5.7.0-4+b2 Severity: normal Dear Maintainer, The opacity is not handled correctly by paraview-5.7 binary, as packaged on bullseye(testing) distrib. Here is a unix command that reproduces the bug: paraview --script=paraview-opacity-bug.py where the paraview-opacity-bug.py python script coulbe be downloaded at https://www-ljk.imag.fr/membres/Pierre.Saramito/tmp/paraview-opacity-bug.py This problem is specific to the debian package: the upstream paraview-5.7 version is problem-free when I use the raw binary distributed by kitware: https://www.paraview.org/download/ https://www.paraview.org/paraview-downloads/download.php?submit=Download&version=v5.7&type=binary&os=Linux&downloadFile=ParaView-5.7.0-osmesa-MPI-Linux-Python3.7-64bit.tar.gz This opacity problem could perhaps be due to the mesa/opengl library, as packaged by debian bullseye(testing) ? Best whishes, Pierre -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages paraview depends on: ii libavcodec58 7:4.2.2-1+b1 ii libavformat58 7:4.2.2-1+b1 ii libavutil56 7:4.2.2-1+b1 ii libc6 2.30-2 ii libdouble-conversion3 3.1.5-5 ii libexpat1 2.2.9-1 ii libfreetype6 2.10.1-2 ii libgcc-s1 [libgcc1] 10-20200312-2 ii libgcc1 1:10-20200312-2 ii libgdal26 3.0.4+dfsg-1 ii libgl1 1.3.1-1 ii libglew2.1 2.1.0-4+b1 ii libhdf5-103 1.10.4+repack-11 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblz4-1 1.9.2-2 ii liblzma5 5.2.4-1+b1 ii libopenmpi3 4.0.2-5 ii libpdal-base9 2.0.1+ds-1+b1 ii libpng16-16 1.6.37-2 ii libpython3.7 3.7.7-1 ii libqt5core5a 5.12.5+dfsg-9 ii libqt5gui5 5.12.5+dfsg-9 ii libqt5help5 5.12.5-2+b2 ii libqt5network5 5.12.5+dfsg-9 ii libqt5widgets5 5.12.5+dfsg-9 ii libqt5x11extras5 5.12.5-1 ii libstdc++6 10-20200312-2 ii libswscale5 7:4.2.2-1+b1 ii libtiff5 4.1.0+git191117-2 ii libx11-6 2:1.6.9-2 ii libxml2 2.9.10+dfsg-4 ii libxt6 1:1.1.5-1+b3 ii python3-autobahn 17.10.1+dfsg1-6 ii python3-matplotlib 3.1.2-2 ii python3-mpi4py 3.0.3-4 ii python3-six 1.14.0-2 ii python3-twisted 18.9.0-6 ii tcl [tclsh] 8.6.9+1+b1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages paraview recommends: ii mpi-default-bin 1.13 ii paraview-doc 5.7.0-4 pn paraview-python Versions of packages paraview suggests: pn h5utils ii hdf5-tools 1.10.4+repack-11 -- no debconf information -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#954326: libmumps-ptscotch-dev: segfault on buster(stable): mumps recompilation nedded
Package: libmumps-ptscotch-dev Version: 5.1.2-4+b2 Severity: important Dear Maintainers, The library SEGFAULT on the buster(stable) package libmumps-ptscotch-dev 5.1.2-4+b2 for the amd64 architecture. I used some well-known medium-sized sparse matrix as tests. This problem could be fixed on buster by a simple recompilation of the package: apt-get source mumps cd mumps-5.1.2 dpkg-buildpackage -us -uc -sa -j1 dpkg -i libmumps-5.1.2-4_amd64.deb libmumps-dev-4_amd64.deb libmumps-scotch-5.1.2-4_amd64.deb libmumps-scotch-dev-4_amd64.deb libmumps-ptscotch-5.1.2-4_amd64.deb libmumps-ptscotch-dev-4_amd64.deb On the bullseye (testing) distrib, there is no problem at all. So, perhaps a binanry dependency has change for mumps on buster(stable), and (I dont known why) the package has not been yet recompiled ? Best wishes, Pierre -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmumps-ptscotch-dev depends on: ii libmumps-dev 5.1.2-4+b2 ii libmumps-ptscotch-5.1.2 5.1.2-4+b2 libmumps-ptscotch-dev recommends no packages. libmumps-ptscotch-dev suggests no packages. -- no debconf information -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#939683: HELP needed for uploading a new debianisation of the Rheolef package
Hi Andreas, I just commit with git a new release 7.0-3 of the debianisation of the rheolef package: it fixes the bug #939683 (see d/changelog). The upstream version is unchanged (7.0). Could you please upload it in debian ? Many thanks for your help. Best regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#939683: rheolef: library has invalid mpi default path: fails to compile some examples
Package: rheolef Version: 7.0-2+b1 Severity: important Tags: patch Dear Maintainer, The "mpi.h" header has been moved from /usr/include/openmpi/ to another location. The configuration file of the Rheolef library has not been updated yet: thus applications do not compile cleanly. Example: cp -a /usr/share/doc/rheolef-doc/examples . cd example make dirichlet fatal error: mpi.h: No such file or directory This issue concerns the following Debian versions: sid, bullseye, buster. I have patched the debianization files of the Rheolef package. The patch solves this issue and will transmit it to the maintainers via git for uploading in Debian. The upstream version will be unchanged (7.0). Thanks for considering this bug. Pierre -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/32 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rheolef depends on: ii libamd2 1:5.4.0+dfsg-1 ii libarmadillo9 1:9.200.7+dfsg-1 ii libboost-iostreams1.67.0 1.67.0-13 ii libboost-mpi1.67.0 1.67.0-13 ii libc6 2.28-10 ii libcgal13 4.13-1+b2 ii libgcc1 1:8.3.0-2 ii libgmp10 2:6.1.2+dfsg-4 ii libmumps-ptscotch-5.1.2 5.1.2-4+b2 ii libopenmpi3 3.1.3-11 ii libptscotch-6.0 6.0.6-2 ii librheolef-dev 7.0-2+b1 ii librheolef1 7.0-2+b1 ii libstdc++6 8.3.0-2 ii libumfpack5 1:5.4.0+dfsg-1 ii rheolef-doc 7.0-2 Versions of packages rheolef recommends: ii gmsh 4.1.5+really4.1.3+ds1-1 ii gnuplot-x11 5.2.6+dfsg1-1 ii mayavi2 4.5.0-1 ii paraview 5.4.1+dfsg4-3.1+b2 ii paraview-python 5.4.1+dfsg4-3.1+b2 -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#897846: HELP needed for uploading a new debianisation of the Rheolef package
Hi Andreas, I just commit with git a new release 7.0-2 of the debianisation of the rheolef package: it fixes a FTBS bug #897846 (see d/changelog). The upstream version is unchanged (7.0). Could you please upload it in debian ? Many thanks for your help. Best regards, Pierre -- Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#888879: HELP needed for uploading a new debianisation of the Rheolef package
Hi Andreas, I just commit with git a new release 6.7-6 of the debianisation of the rheolef package: it fixes a FTBS bug #79 It also fixes others issues related to the previous 6.7-5 version: multiarch lib install directory and regeneration of patched autoconf/automake files (see d/changelog). The upstream version is unchanged (6.7). Could you please upload it in debian ? Many thanks for your help. Best regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#888879: Rheolef moved to Git : problem to download/edit the debian files
Hi Andreas, Many thanks for your rewrite and modernization of the Debian files for the Rheolef package in rheolef-6.7-5. For build time tests to run correctly, I have now to patch these files, but I have a technical problem: After the move from SVN to GIT of the package, I am no more able to download & edit the files. I need to download, edit and upload the debian files, but I dont have any account on sources.debian.org Any idea how to solve this in a simple way ? Many thanks for your help for the Debianization of the package, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#888879: rheolef FTBFS on several architectures: test runs forever
Hi Adrian and Andreas, Ok, no poblems, I will check this issue. True, the "make check" test suite was not run before in the Debian enviromnent. This "make check" test suite was developped for managing the upstream version source code: it runs a very long sequence of non-regression test suite. It runs via "mpirun" and could have non-portability issues on some architecture. Some possible patch could be to run the test suite in sequential mode : make MPIRUN="" check Could you please decrease the severity of this bug, e.g. to normal, as there is no obstacle to build the package. I have only access to "amd64" achitectures in my lab: Please could you explain me how to access to access to the others machines/architectures used by the Debian team ? How to have a login on these machines ? Thank you for your help maintaining the Debian package, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito - Mail original - De: "Andreas Tille" À: 888...@bugs.debian.org, "PIERRE SARAMITO" Envoyé: Mardi 6 Février 2018 11:59:19 Objet: Re: Bug#79: rheolef FTBFS on several architectures: test runs forever Hi Pierre, as I mentioned on Debian Science maintainers list[1] this problem does not come unexpected. Pierre, could you please confirm whether you keep on maintaining this package and will check this issue? >From my uneducated perspective the test failures always existed but the test were simply not run before. Thus a first course of action might be to ask ftpmaster for removal of those architectures where rheolef does not build and reduce severity of the bug to say "important". Please note that I do not have any time resources to work on this package. Kind regards Andreas. [1] https://lists.alioth.debian.org/pipermail/debian-science-maintainers/2018-January/057544.html On Tue, Jan 30, 2018 at 10:24:18PM +0200, Adrian Bunk wrote: > Source: rheolef > Version: 6.7-5 > Severity: serious > > https://buildd.debian.org/status/package.php?p=rheolef&suite=sid > > ... > mpirun -np 1 ./form_mass_bdr_tst -app P2 -weight yz -I my_cube_TP-5-v2 > left >/dev/null 2>/dev/null > mpirun -np 2 ./form_mass_bdr_tst -app P2 -weight yz -I my_cube_TP-5-v2 > left >/dev/null 2>/dev/null > mpirun -np 3 ./form_mass_bdr_tst -app P2 -weight yz -I my_cube_TP-5-v2 > left >/dev/null 2>/dev/null > mpirun -np 1 ./form_mass_bdr_tst -app P2 -weight yz -I my_cube_TP-5-v2 > right >/dev/null 2>/dev/null > mpirun -np 2 ./form_mass_bdr_tst -app P2 -weight yz -I my_cube_TP-5-v2 > right >/dev/null 2>/dev/null > E: Build killed with signal TERM after 150 minutes of inactivity > > > I've reproduced this on i386, two processes are running > forever (aborted after 6 hours on a fast CPU) with 100% CPU. > > Backtraces: > > Thread 3 (Thread 0xf50ffb40 (LWP 29032)): > #0 0xf7ed6db9 in __kernel_vsyscall () > #1 0xf70fabd3 in __GI___poll (fds=0xf47005d0, nfds=2, timeout=360) at > ../sysdeps/unix/sysv/linux/poll.c:29 > #2 0xf5caed4a in poll (__timeout=360, __nfds=2, __fds=0xf47005d0) at > /usr/include/i386-linux-gnu/bits/poll2.h:46 > #3 poll_dispatch (base=0x578eb9c0, tv=0xf50f9bfc) at poll.c:165 > #4 0xf5ca59e9 in opal_libevent2022_event_base_loop (base=, > flags=) at event.c:1630 > #5 0xf5c6b3bd in progress_engine (obj=0x578eb950) at > runtime/opal_progress_threads.c:105 > #6 0xf5df6316 in start_thread (arg=0xf50ffb40) at pthread_create.c:465 > #7 0xf7105296 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108 > > Thread 2 (Thread 0xf5ac5b40 (LWP 29031)): > #0 0xf7ed6db9 in __kernel_vsyscall () > #1 0xf71053fa in __GI_epoll_pwait (epfd=7, events=0x578ea930, maxevents=32, > timeout=-1, set=0x0) > at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42 > #2 0xf710569a in epoll_wait (epfd=7, events=0x578ea930, maxevents=32, > timeout=-1) > at ../sysdeps/unix/sysv/linux/epoll_wait.c:30 > #3 0xf5ca199a in epoll_dispatch (base=0x578ea7a0, tv=0x0) at epoll.c:407 > #4 0xf5ca59e9 in opal_libevent2022_event_base_loop (base=, > flags=) at event.c:1630 > #5 0xf5af23eb in progress_engine (obj=0x578ea7a0) at > src/util/progress_threads.c:52 > #6 0xf5df6316 in start_thread (arg=0xf5ac5b40) at pthread_create.c:465 > #7 0xf7105296 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108 > > Thread 1 (Thread 0xf5b4fe00 (LWP 29002)): > #0 0xf7ed67f5 in ?? () > #1 0xf7ed6b43 in __vdso_clock_gettime () > #2 0xf7112961 in __GI___clock_gettime (clock_id=1, tp=0xffb74194) at > ../sysdeps/unix/clock_gettime.c:115 > #3 0xf5cc3297 in opal_timer_linux_get_usec_clock_
Bug#883987: boost1.62: FTBFS error: partial specialization ... after instantiation ... (with patch)
Hi all,
Any news from the boost package maintainers for this bug ?
A patch is available for this bug (see attachement)
and it should be easy to fix it now.
It affects the Rheolef package: there is a BinNMU issue still pending.
Many thanks for your help and reactivity,
Pierre
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://ljk.imag.fr/membres/Pierre.Saramito
// bug description
// https://svn.boost.org/trac10/ticket/12534
// and its fix in boost-dev 1.65:
// https://github.com/boostorg/container/commit/5e4a107e82ab3281688311d22d2bfc2fddcf84a3
// i.e. remove from line 431 to 460 in include/boost/container/detail/pair.hpp
#undef FIX_BUG
#ifdef FIX_BUG
#include
#endif // FIX_BUG
#include
static const bool is_enum = boost::is_enum >::value;
#include
boost::container::flat_map m;
int main() {}
*** /usr/include/boost/container/detail/pair.hpp.orig Tue Dec 12 12:15:26 2017
--- /usr/include/boost/container/detail/pair.hpp Tue Dec 12 12:41:22 2017
***
*** 416,451
} //namespace container_detail {
} //namespace container {
-
- //Without this specialization recursive flat_(multi)map instantiation fails
- //because is_enum needs to instantiate the recursive pair, leading to a compilation error).
- //This breaks the cycle clearly stating that pair is not an enum avoiding any instantiation.
- template
- struct is_enum;
-
- template
- struct is_enum< ::boost::container::container_detail::pair >
- {
-static const bool value = false;
- };
-
- template
- struct is_enum< ::std::pair >
- {
-static const bool value = false;
- };
-
- template
- struct is_class;
-
- //This specialization is needed to avoid instantiation of pair in
- //is_class, and allow recursive maps.
- template
- struct is_class< ::boost::container::container_detail::pair >
- {
-static const bool value = true;
- };
-
#ifdef BOOST_NO_CXX11_RVALUE_REFERENCES
template
--- 416,421
Bug#883987: rheolef: FTBFS error: partial specialization ... after instantiation ...
Hi Graham, > Would you please quote the bug number? I failed to find your bug report. Here is the bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884185 Hummm... I just realize now that I have do a mistake and assign this bug to libcgal-dev instead of libboost-dev package when using Debian "bugreport". > I think the thing to do here is reassign this bug to src:boost1.62 and > mark that it affects src:rheolef. Do you known how to do that with the Debian bug system ? Many thanks for your help solving this issue, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito - Mail original - De: "ginggs" À: "PIERRE SARAMITO" , "883987" <883...@bugs.debian.org> Cc: "Andreas Beckmann" Envoyé: Mardi 12 Décembre 2017 20:26:18 Objet: Re: Bug#883987: rheolef: FTBFS error: partial specialization ... after instantiation ... Hi Pierre (cc-ing Andreas in case he is not subscribed) On 12 December 2017 at 15:13, Pierre Saramito wrote: > Hi Andreas, > > This problem do neither comes from Rheolef-6.7 nor from CGAL-4.11: > it comes from Boost-1.62 combined with g++ 7.2 in Debian sid and testing. > > The bug has already be identified in the upstream version of Boost : > https://svn.boost.org/trac10/ticket/12534 > and it is now fixed in the upstream version Boost-1.65: > > https://github.com/boostorg/container/commit/5e4a107e82ab3281688311d22d2bfc2fddcf84a3 > but this version is not yet available in Debian. > > I've just send a bug report to the Boost package, together with a patch for > Boost-1.62 > and later, until we will get Boost-1.65 in Debian. > > See also in attachment for a small test "pair_tst.cc" and the corresponding > Boost patch "pair_tst.patch" > > I hope it will be fixed soon. > > Best regards, > > Pierre > -- > pierre.saram...@imag.fr > Directeur de Recherche CNRS > Laboratoire Jean Kuntzmann, Grenoble, France > http://ljk.imag.fr/membres/Pierre.Saramito Would you please quote the bug number? I failed to find your bug report. I think the thing to do here is reassign this bug to src:boost1.62 and mark that it affects src:rheolef. Regards Graham
Bug#883987: rheolef: FTBFS error: partial specialization ... after instantiation ...
Hi Andreas,
This problem do neither comes from Rheolef-6.7 nor from CGAL-4.11:
it comes from Boost-1.62 combined with g++ 7.2 in Debian sid and testing.
The bug has already be identified in the upstream version of Boost :
https://svn.boost.org/trac10/ticket/12534
and it is now fixed in the upstream version Boost-1.65:
https://github.com/boostorg/container/commit/5e4a107e82ab3281688311d22d2bfc2fddcf84a3
but this version is not yet available in Debian.
I've just send a bug report to the Boost package, together with a patch for
Boost-1.62
and later, until we will get Boost-1.65 in Debian.
See also in attachment for a small test "pair_tst.cc" and the corresponding
Boost patch "pair_tst.patch"
I hope it will be fixed soon.
Best regards,
Pierre
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://ljk.imag.fr/membres/Pierre.Saramito
// bug description
// https://svn.boost.org/trac10/ticket/12534
// and its fix in boost-dev 1.65:
// https://github.com/boostorg/container/commit/5e4a107e82ab3281688311d22d2bfc2fddcf84a3
// i.e. remove from line 431 to 460 in include/boost/container/detail/pair.hpp
#undef FIX_BUG
#ifdef FIX_BUG
#include
#endif // FIX_BUG
#include
static const bool is_enum = boost::is_enum >::value;
#include
boost::container::flat_map m;
int main() {}
*** /usr/include/boost/container/detail/pair.hpp.orig Tue Dec 12 12:15:26 2017
--- /usr/include/boost/container/detail/pair.hpp Tue Dec 12 12:41:22 2017
***
*** 416,451
} //namespace container_detail {
} //namespace container {
-
- //Without this specialization recursive flat_(multi)map instantiation fails
- //because is_enum needs to instantiate the recursive pair, leading to a compilation error).
- //This breaks the cycle clearly stating that pair is not an enum avoiding any instantiation.
- template
- struct is_enum;
-
- template
- struct is_enum< ::boost::container::container_detail::pair >
- {
-static const bool value = false;
- };
-
- template
- struct is_enum< ::std::pair >
- {
-static const bool value = false;
- };
-
- template
- struct is_class;
-
- //This specialization is needed to avoid instantiation of pair in
- //is_class, and allow recursive maps.
- template
- struct is_class< ::boost::container::container_detail::pair >
- {
-static const bool value = true;
- };
-
#ifdef BOOST_NO_CXX11_RVALUE_REFERENCES
template
--- 416,421
Bug#884185: boost1.62 FTBFS error: partial specialization ... after instantiation ... (with attachment files)
Package: libcgal-dev
Version: 4.11-2
Severity: grave
Justification: renders package unusable
Tags: upstream newcomer
Dear Maintainer,
Boost-1.62 fails to compile the following c++ file :
g++ pair_tst.cc -o pair_tst.cc
in sid and buster (testing) with g++ 7.2.
The output is:
In file included from
/usr/include/boost/container/detail/flat_tree.hpp:29:0,
from /usr/include/boost/container/flat_map.hpp:29,
from pair_tst.cc:16:
/usr/include/boost/container/detail/pair.hpp:433:8: error: partial
specialization of ‘struct boost::is_enum >’ after
instantiation of ‘struct boost::is_enum >’ [-fpermissive]
struct is_enum< ::std::pair >
^~~~
See the "pair_tst.cc" file in attachment for reproducing this bug.
This bug actually causes some debian package build to fail in sid
and testing (see e.g. bug: #883987 ).
The bug has already be identified in the upstream version of Boost :
https://svn.boost.org/trac10/ticket/12534
and it is now fixed in boost-dev 1.65:
https://github.com/boostorg/container/commit/5e4a107e82ab3281688311d22d2bfc2fddcf84a3
The fix simply consists of removing from line 431 to 460
in file include/boost/container/detail/pair.hpp
See also the "pair_tst.patch" file in attachment.
Could you please includes this patch in the debianization of
the Boost package ?
Best regards,
Pierre Saramito
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-1-amd64 (SMP w/32 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libcgal-dev depends on:
ii libboost-dev 1.62.0.1
ii libboost-program-options-dev 1.62.0.1
ii libboost-system-dev 1.62.0.1
ii libboost-thread-dev 1.62.0.1
ii libcgal13 4.11-2
ii libgmp-dev [libgmp10-dev] 2:6.1.2+dfsg-1.1
ii libmpfr-dev 3.1.6-1
ii zlib1g-dev1:1.2.8.dfsg-5
libcgal-dev recommends no packages.
Versions of packages libcgal-dev suggests:
pn libmpfi-dev
pn libntl-dev
pn libtbb-dev
-- no debconf information
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://ljk.imag.fr/membres/Pierre.Saramito// bug description
// https://svn.boost.org/trac10/ticket/12534
// and its fix in boost-dev 1.65:
// https://github.com/boostorg/container/commit/5e4a107e82ab3281688311d22d2bfc2fddcf84a3
// i.e. remove from line 431 to 460 in include/boost/container/detail/pair.hpp
#undef FIX_BUG
#ifdef FIX_BUG
#include
#endif // FIX_BUG
#include
static const bool is_enum = boost::is_enum >::value;
#include
boost::container::flat_map m;
int main() {}
*** /usr/include/boost/container/detail/pair.hpp.orig Tue Dec 12 12:15:26 2017
--- /usr/include/boost/container/detail/pair.hpp Tue Dec 12 12:41:22 2017
***
*** 416,451
} //namespace container_detail {
} //namespace container {
-
- //Without this specialization recursive flat_(multi)map instantiation fails
- //because is_enum needs to instantiate the recursive pair, leading to a compilation error).
- //This breaks the cycle clearly stating that pair is not an enum avoiding any instantiation.
- template
- struct is_enum;
-
- template
- struct is_enum< ::boost::container::container_detail::pair >
- {
-static const bool value = false;
- };
-
- template
- struct is_enum< ::std::pair >
- {
-static const bool value = false;
- };
-
- template
- struct is_class;
-
- //This specialization is needed to avoid instantiation of pair in
- //is_class, and allow recursive maps.
- template
- struct is_class< ::boost::container::container_detail::pair >
- {
-static const bool value = true;
- };
-
#ifdef BOOST_NO_CXX11_RVALUE_REFERENCES
template
--- 416,421
Bug#884184: boost1.62 FTBFS error: partial specialization ... after instantiation ...
Package: libcgal-dev Version: 4.11-2 Severity: grave Justification: renders package unusable Tags: upstream newcomer Dear Maintainer, Boost-1.62 fails to compile the following c++ file : g++ pair_tst.cc -o pair_tst.cc in sid and buster (testing) with g++ 7.2. The output is: In file included from /usr/include/boost/container/detail/flat_tree.hpp:29:0, from /usr/include/boost/container/flat_map.hpp:29, from pair_tst.cc:16: /usr/include/boost/container/detail/pair.hpp:433:8: error: partial specialization of ‘struct boost::is_enum >’ after instantiation of ‘struct boost::is_enum >’ [-fpermissive] struct is_enum< ::std::pair > ^~~~ See the "pair_tst.cc" file in attachment for reproducing this bug. This bug actually causes some debian package build to fail in sid and testing (see e.g. bug: #883987 ). The bug has already be identified in the upstream version of Boost : https://svn.boost.org/trac10/ticket/12534 and it is now fixed in boost-dev 1.65: https://github.com/boostorg/container/commit/5e4a107e82ab3281688311d22d2bfc2fddcf84a3 The fix simply consists of removing from line 431 to 460 in file include/boost/container/detail/pair.hpp See also the "pair_tst.patch" file in attachment. Could you please includes this patch in the debianization of the Boost package ? Best regards, Pierre Saramito -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/32 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libcgal-dev depends on: ii libboost-dev 1.62.0.1 ii libboost-program-options-dev 1.62.0.1 ii libboost-system-dev 1.62.0.1 ii libboost-thread-dev 1.62.0.1 ii libcgal13 4.11-2 ii libgmp-dev [libgmp10-dev] 2:6.1.2+dfsg-1.1 ii libmpfr-dev 3.1.6-1 ii zlib1g-dev1:1.2.8.dfsg-5 libcgal-dev recommends no packages. Versions of packages libcgal-dev suggests: pn libmpfi-dev pn libntl-dev pn libtbb-dev -- no debconf information -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#871811: FTBFS with CGAL 4.11
Dear Joachim, Many thanks for your patch: I am integrating it in the debian files of the Rheolef package in order to support the new CGAL 4.11 version. Sorry for my late response, I was travelling in new zealand for conferences... The path for CGAL will be integrated in the fortcoming Rheolef upstream versions. Kind regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://ljk.imag.fr/membres/Pierre.Saramito
Bug#826960: mumps: Please package with metis and parmetis
Source: mumps Severity: wishlist Dear Adam, It would be nice to have libmumps-metis-dev and libmumps-parmetis-dev as alternatives to libmumps-scotch-dev and libmumps-ptscotch-dev packages: please, could you package mumps with (par)metis also ? Best wishes, Pierre -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.3.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito
Bug#811590: FTBFS with GCC 6: statement indented as if it were guarded by version graph
Dear Martin Michlmayr, Many thanks for your bug report. A new upstream version rheolef-6.7 of the source package should now compile with g++-6 and fix this bug. Best wishes, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito
Bug#824788: FTBFS in sid: recipe for target 'rheolef.pdf' failed
Dear Sébastien Villemot, Many thanks for your bug report. The new upstream version rheolef-6.7 should fix it now. Best wishes, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito
Bug#807861: Help needed for uploading a new version 6.6-2 of the Rheolef package
Dear Anton, dear FTP maintainers, Notice that the same compilation problem occurs with both s390x and armhf archs, which are both official Debian ports. So, both these two archs should be suspended. Thanks, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito - Mail original - De: "Anton Gladky" À: "Pierre Saramito" Cc: 807...@bugs.debian.org Envoyé: Lundi 14 Décembre 2015 08:57:53 Objet: Re: Help needed for uploading a new version 6.6-2 of the Rheolef package Hi Pierre, uploading the new package version with updated list of archs will not help it to migrate to testing, because old version still exists on s390x. It should be removed firstly from archive. Regards Anton 2015-12-14 8:24 GMT+01:00 Pierre Saramito : > Dear Anton, dear FTP masters, > > There is no need to remove this package on s390x-arch.
Bug#807861: Help needed for uploading a new version 6.6-2 of the Rheolef package
Hi Anton, Ok, I've not yet experimented such a pocedure with Debian, so, please do what is required in the Debian procedure. Do you known a way (an access) to test for the compilation of the package on a s390x ? The upstream source package should be probably fixed with some very minor changes for s390x arch (previous source versions was ok). But do not have any access to such architecture in my environment. Many thanks for your help, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito - Mail original - De: "Anton Gladky" À: "Pierre Saramito" Cc: 807...@bugs.debian.org Envoyé: Lundi 14 Décembre 2015 08:57:53 Objet: Re: Help needed for uploading a new version 6.6-2 of the Rheolef package Hi Pierre, uploading the new package version with updated list of archs will not help it to migrate to testing, because old version still exists on s390x. It should be removed firstly from archive. Regards Anton 2015-12-14 8:24 GMT+01:00 Pierre Saramito : > Dear Anton, dear FTP masters, > > There is no need to remove this package on s390x-arch.
Bug#807861: Help needed for uploading a new version 6.6-2 of the Rheolef package
Dear Anton, dear FTP masters, There is no need to remove this package on s390x-arch. The s390x arch, that causes some compilation problem, is already explicitely removed from the arch list in debian/control in the new 6.6-2 debianization file. There is only need to upload the new 6.6-2 debianization files (the rheolef source files 6.6 are unchanged) : see svn://anonscm.debian.org/debian-science/packages/rheolef/trunk/ So, please, clould you close this bug #807861 and upload the new 6.6-2 version ? Many thanks for your help, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito - Mail original - De: "Anton Gladky" À: "Pierre Saramito" Envoyé: Dimanche 13 Décembre 2015 22:08:38 Objet: Re: Help needed for uploading a new version 6.6-2 of the Rheolef package Hi Pierre, you do not need to explicitly remove package from the Arch-list. You just need to file a bug against ftp.debian.org. I did it for you this time. Best regards Anton 2015-12-09 10:16 GMT+01:00 Pierre Saramito : > Dear Anton, > > Here is a glentle remainder, for uploading version 6.6-2 of the rheolef > package. > > > I just commit with svn a new release 6.6-2 of the debianisation > of the rheolef package: it fixes the current problem. > The s390x architecture is temporarily removed for this package. > > The source version is unchanged (6.6). > > Could you please upload it in debian ? > > Many thanks for your help. > > Best regards, > > Pierre > > -- > pierre.saram...@imag.fr > Directeur de Recherche CNRS > Laboratoire Jean Kuntzmann, Grenoble, France > http://www-ljk.imag.fr/membres/Pierre.Saramito > > - Mail original - > De: "Pierre Saramito" > À: "Anton Gladky" > Cc: "Pierre Saramito" > Envoyé: Samedi 21 Novembre 2015 17:59:31 > Objet: Help needed for uploading a new version 6.6-2 of the Rheolef package > > Hi Anton, > > I just commit with svn a new release 6.6-2 of the debianisation > of the rheolef package: the s390x architecture is temporarily > removed for this package. > > The source version is unchanged (6.6). > > Could you please upload it in debian ? > > Many thanks for your help. > > Best regards, > > Pierre > -- > pierre.saram...@imag.fr > Directeur de Recherche CNRS > Laboratoire Jean Kuntzmann, Grenoble, France > http://www-ljk.imag.fr/membres/Pierre.Saramito > > - Mail original - > De: "Anton Gladky" > À: "Pierre Saramito" > Envoyé: Samedi 24 Octobre 2015 10:34:27 > Objet: Re: Help needed for uploading a new version 6.6 of the Rheolef package > > Hi Pierre, > > I have uploaded this package some days ago. It looks like there > is a problem with the build on s390x. One can try to fix it or request > removal rheolef on this platform. Otherwise the package will > not be able to migrate to testing. > > Best regards > > Anton > > 2015-09-29 15:03 GMT+02:00 Pierre Saramito : >> I commit few days ago in svn a new version the debianization of rheolef : >> it fixes the problem related to g++ 5 in sid and testing (bug #778106 ).
Bug#778106: HELP needed for uploading a new version 6.6 of the Rheolef package (english translation)
Here is an english translation of the previous message, for the bug tracker. Hi Sylvestre ! I just commit in svn a new version the debianization of rheolef : it fixes the problem related to g++ 5 in sid and testing (bug #778106 ). This corresponds also to a new version 6.6 of the sources : http://www-ljk.imag.fr/membres/Pierre.Saramito/rheolef/rheolef-6.6.tar.gz Could you please makes the changes in debian ? Many thaks for your help, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito - Mail original - De: "Pierre Saramito" À: "Sylvestre Ledru" , 778...@bugs.debian.org Cc: "Pierre Saramito" Envoyé: Vendredi 25 Septembre 2015 13:20:09 Objet: HELP needed for uploading a new version 6.6 of the Rheolef package Bonjour Sylvestre, Je viens de remonter sous svn une nouvelle version de la debianisation de rheolef : cela corrige le nouveau probleme a propos de g++ 5 sous sid et testing (bug #778106 ). Cela correspond aussi a une nouvelle version 6.6 des sources : http://www-ljk.imag.fr/membres/Pierre.Saramito/rheolef/rheolef-6.6.tar.gz Serait-il possible de faire le chargement dans debian ? En te remerciant par avance, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito
Bug#778106: HELP needed for uploading a new version 6.6 of the Rheolef package
Bonjour Sylvestre, Je viens de remonter sous svn une nouvelle version de la debianisation de rheolef : cela corrige le nouveau probleme a propos de g++ 5 sous sid et testing (bug #778106 ). Cela correspond aussi a une nouvelle version 6.6 des sources : http://www-ljk.imag.fr/membres/Pierre.Saramito/rheolef/rheolef-6.6.tar.gz Serait-il possible de faire le chargement dans debian ? En te remerciant par avance, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito
Bug#748130: scotch autoremoval from jessie not usefull : only stable/amd64 package has RC bug
Dear all, The RC bug #748130 founded in the scotch library causes to mark for autoremoval many packages in the jessie distribution. Notice that the bug do not concern the actual jessie distribution : it is restricted to the stable one on the amd64 architecture. Recall that, in that specific case, the actual stable/amd64 scotch package links to both mipch and openmpi and this produce a segfault at run time. A simple recompilation of the stable scotch packages for amd64 should fix this bug (see bug #748130 for more). So, the jessie scotch packages are not concerned by this bug and all packages that depend one do not need to be marked for autoremoval. Regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#748130: on wheezy/amd64: libscotch-5.1 depends on mpich while mpi-default is openmpi
Package: libscotch-5.1 Version: 5.1.12b.dfsg-2+b1 Severity: serious Hi all, The stable (wheezy) debian package "libscotch-5.1" depends on MPI lib as : dep: libmpich2-3 [amd64, mips, mipsel, s390, s390x] dep: libopenmpi1.3 [not amd64, mips, mipsel, s390, s390x] while the "mpi-default-bin" package has the following dependencies : dep: mpich2 [mips, mipsel, s390, s390x] dep: openmpi-bin [not mips, mipsel, s390, s390x] The same bug occurs for all MPI-dependent packages from the "scotch" source package. Thus, on amd64, the scotch library is not usable: package depending on scotch will compile but segfault at run time. A possible solution should be to recompile the wheezy/amd64 scotch package. -- System Information: Debian Release: wheezy APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libscotch-5.1 depends on: ii libc6 2.13-38+deb7u1 ii libcr0 0.8.5-2 ii libmpich2-31.4.1-4.2 ii zlib1g 1:1.2.7.dfsg-13 libscotch-5.1 recommends no packages. libscotch-5.1 suggests no packages. -- no debconf information Yours sincerely, Pierre Saramito -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714185: rheolef: Vcs-Svn does not work
Hi Sebastian, > From Sebastian: > Sorry, my bad. I always forget that anonscm doesn't need svn in the > URLs. It should be > svn://anonscm.debian.org/debian-science/packages/rheolef/trunk/. > > The rationale for the change is explained in lintian's > vcs-fields-not-canonical tag and the referenced mail there. Many thanks: the debian/control file is now fixed in svn, it will be ready for the next upload together with the forthcoming upstream release rheolef-6.5. Regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#715672: [Mayhem] Bug report on rheolef: bamg crashes with exit status 139
Hi Alexandre, > From Alexandre Rebert: > Package: rheolef > > bamg crashes with exit status 139. We confirmed the crash by > re-running it in a fresh debian unstable installation. Many thanks for your help: the bug is now fixed in the forthcoming rheolef-6.5 that will be available with the next upload. The command now exit cleanly with error status 1. % bamg -g A -H bamg: missing argument for option `-H' HINT: see documentation or enter bamg -h % echo $? 1 Regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716110: [Mayhem] Bug report on rheolef: mkgeo_grid_1d crashes with exit status 139
Hi Alexandre, > From Alexandre Rebert: > Package: rheolef > > mkgeo_grid_1d crashes with exit status 139. We confirmed the crash by > re-running it in a fresh debian unstable installation. Many thanks for your help: the bug is now fixed in the forthcoming rheolef-6.5 that will be available with the next upload. The command now exit cleanly with error status 1. % mkgeo_grid_1d -a ./mkgeo_grid_1d: missing argument for option `-a' usage: ./mkgeo_grid_1d [n=10] [-a float=0] [-b float=1] [-[no]boundary] [-[no]sides] [-[no]region] [-[no]corner] [-v4] [-[dis]ordered] example: ./mkgeo_grid_1d 10 % echo $? 1 Regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714204: rheolef: FTBFS twice in a row
Hi Sebastian, > From Sebastian: > rheolef fails to build twice in a row: > | dpkg-source -b rheolef-6.4 > | dpkg-source: info: using source format `3.0 (quilt)' > | dpkg-source: info: building rheolef using existing ./rheolef_6.4.orig.tar.gz > | dpkg-source: error: cannot represent change to > rheolef-6.4/include/rheolef_seq.h: I've just added a "make distclean" in the debian/rules clean target and all is fine now. The bug will be fixed with the next upload, together with the next upstream version rheolef-6.5. Many thanks for your help, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716547: [Mayhem] Bug report on rheolef: mkgeo_grid_2d crashes with exit status 139
Hi Alexandre, > From Alexandre Rebert: > Package: rheolef > > mkgeo_grid_2d crashes with exit status 139. We confirmed the crash by > re-running it in a fresh debian unstable installation. Many thanks for your help: the bug is now fixed in the forthcoming rheolef-6.5 that will be available with the next upload. The command now exit cleanly with error status 1. % mkgeo_grid_2d -bobound ./mkgeo_grid_2d: invalid command line argument `-bobound' usage: ./mkgeo_grid_2d [-t|-q] [nx=10] [ny=nx] [-a float=0] [-b float=1] [-c float=0] [-d float=1] [-[no]boundary] [-[no]sides] [-[no]region] [-[no]corner] [-rz|-zr] [-v4] example: ./mkgeo_grid_2d -t 10 ./mkgeo_grid_2d -t 10 20 % echo $? 1 Regards, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701347: rheolef: ftbfs with GCC-4.8
Hi Joachim and Matthias, The forthcoming upstream release rheolef-6.5 compiles well with g++-4.8 and boost-1.54: the bug should be fixed soon with the next upload. Many thanks for your help, Pierre On Sun 07 Jul 2013 � 12:37 +0200, Joachim Reichel wrote : > Package: rheolef > Followup-For: Bug #701347 > > I am not able to reproduce this bug with g++ 4.8.1-5. > > Joachim > > -- System Information: > Debian Release: 7.1 > APT prefers stable-updates > APT policy: (810, 'stable-updates'), (800, 'stable'), (700, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.7-trunk-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > -- > debian-science-maintainers mailing list > debian-science-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714185: rheolef: Vcs-Svn does not work
Hi Sebastian, > From Sebastian Ramacher: > The repository declaed in Vcs-Svn does not work: > | % debcheckout rheolef > [...] > | svn co svn://svn.debian.org/svn/debian-science/packages/rheolef/trunk/ > rheolef ... > [...] > | checkout failed (the command above returned a non-zero exit code) I've just tried the same command and it works fine (see attachment). Perhaps a temporary failure of the svn.debian.org sever ? > The host should be anonscm.debian.org instead. After a simple try: % svn co svn://annonscm.debian.org/svn/debian-science/packages/rheolef/trunk/ rheolef svn: E670002: Unable to connect to a repository at URL 'svn://annonscm.debian.org/svn/debian-science/packages/rheolef/trunk' svn: E670002: Nom d'hôte inconnu 'annonscm.debian.org' It seems that this host has no svn server ? A ping at these hosts gives: % ping svn.debian.org PING svn.debian.org (217.196.43.140) 56(84) bytes of data. % ping anonscm.debian.org PING anonscm.debian.org (217.196.43.132) 56(84) bytes of data. Clearly, there are different machines with different IP. Are you sure that anonscm.debian.org is the right host for svn ? Regards Pierre Saramito -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito debcheckout rheolef declared svn repository at svn://svn.debian.org/svn/debian-science/packages/rheolef/trunk/ svn co svn://svn.debian.org/svn/debian-science/packages/rheolef/trunk/ rheolef ... Arheolef/debian Arheolef/debian/control Arheolef/debian/compat Arheolef/debian/shlibs.librheolef1.X Arheolef/debian/changelog Arheolef/debian/docs Arheolef/debian/rheolef.install Arheolef/debian/rules Arheolef/debian/librheolef-dev.install Arheolef/debian/rheolef-doc.install Arheolef/debian/source Arheolef/debian/source/format Arheolef/debian/librheolef1.install Arheolef/debian/watch Arheolef/debian/rheolef-doc.doc-base.usrman Arheolef/debian/copyright Arheolef/debian/rheolef-doc.doc-base.refman Arheolef/debian/README.Debian Révision 46282 extraite. repository only contains the debian directory, using apt-get source Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Note : la maintenance du paquet de « rheolef » est réalisée dans le système de suivi de versions « Svn » à l'adresse : svn://svn.debian.org/svn/debian-science/packages/rheolef/trunk/ Nécessité de prendre 33,4 Mo dans les sources. Réception de : 1 http://www-ljk.imag.fr/membres/Pierre.Saramito/rheolef/source/ ./ rheolef 6.4-2 (dsc) [1 449 B] Réception de : 2 http://www-ljk.imag.fr/membres/Pierre.Saramito/rheolef/source/ ./ rheolef 6.4-2 (tar) [33,4 MB] Réception de : 3 http://www-ljk.imag.fr/membres/Pierre.Saramito/rheolef/source/ ./ rheolef 6.4-2 (diff) [7 675 B] 33,4 Mo réceptionnés en 2s (11,7 Mo/s) dpkg-source: avertissement: extraction d'un paquet source non signé (rheolef_6.4-2.dsc) dpkg-source: info: extraction de rheolef dans rheolef-6.4 dpkg-source: info: extraction de rheolef_6.4.orig.tar.gz dpkg-source: info: extraction de rheolef_6.4-2.debian.tar.gz
Bug#701347: Bug #701347 rheolef: ftbfs with GCC-4.8
Hi Matthias, I have problem to install experimental g++-4.8 in sid as you suggests: apt-get -t experimental install g++ g++-4.7 g++-4.8 libc6-dev Apt reaches depency problems (same also with aptitude). So, I'm waiting for g++-4.8 to be really available in sid or jessie for treating this bug. Cheers, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709155: Debian Bug#709155 [librheolef-dev] librheolef-dev: missing Breaks+Replaces: rheolef (<< 6.4)
Hi Andreas, Many thanks for your patch: its now integrated in the "debian/control" file of the Rheolef package and I've checked that all is now fine when replacing an old version of the package by a new one. The bug should be fixed now and I'll looking for an upload of the new version. Cheers, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690766: Submitted bug: rheolef_6.1-2 is wrongly packaged in sid & wheezy ; a fix, as rheolef_6.1-3, is now available
Package: rheolef Version: 6.1-3 Severity: grave Tags: patch Dear debian maintainers, The rheolef_6.1-2 package is wrongly distributed in sid and wheezy. The rheolef debianization files debian/* are now fixed and the fixed version is available as rheolef_6.1-3 in svn. Please could you upgrade the rheolef package in sid and testing ? Yours sincelery, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/6 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rheolef depends on: ii libboost-iostreams1.49.0 1.49.0-3.1 ii libboost-thread1.49.0 1.49.0-3.1 ii libc6 2.13-35 ii libcgal9 4.0-4 ii libgcc1 1:4.7.1-7 ii libgmp10 2:5.0.5+dfsg-2 ii libopenmpi1.3 1.4.5-1 ii librheolef-dev6.1-3 ii rheolef-doc 6.1-3 Versions of packages rheolef recommends: ii gmsh 2.6.1.dfsg-4 ii gnuplot 4.6.0-8 ii mayavi2 4.1.0-1 ii paraview 3.14.1-6 ii tcl-vtk 5.8.0-13+b1 rheolef suggests no packages. -- no debconf information -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661689: Bad formatting of package description, perhaps improvable wording
Dear Justin and Martin, Many thanks for this carreful reading of the debian description. My mother language is not english but french, so your comments are really important. From: Justin B Rye (By the way, just before sending this I've found https://www.projet-plume.org/fr/fiche/rheolef which looks like the French original version.) Yes, the original description was here and at the Rheolef home page http://www-ljk.imag.fr/membres/Pierre.Saramito/rheolef obWhyTheName: something to do with logiciel and éléments finis... Rheolef means "rheo" + "ef". Rheo is a grec word that meas material that flows (water, mud, blood, etc). EF means "éléments finis". This library was initiated from applications to fluid mechanics with nonlinear and complex behavior (we speak now of Non-Newtonian fluids). Its application is now more general, applied mathematics, but the original name maintains some relations to these origins. so how about: Description: efficient Finite Element environment Ok, it sounds better to me too! Revised version and patch attached. Many thanks, I integrate it for the next release of the package. I was in Edinburgh in February, probably I will come back to travel by bike in Scotland. Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630864: rheolef and freefem++: error when trying to install together
Hi, dear maintainers of Freefem++ ! As maintainer of the rheolef package I also use the bamg mesh generator. Instead of renamming it as ffbamg, coud your consider to separately package bamg ? By this way, both rheolef & ff could share the same bamg package dependency. Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630864: rheolef and freefem++: error when trying to install together
Hi, > Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be slightly out of > sync): > > /usr/bin/bamg Could you consider to create some specific debian package(s) for the bamg mesh generator (bin & lib) ? Then, both freefem++ & rheolef could depend on ? Notice that rheolef depends only upon the binary /usr/bin/bamg Pierre Saramito Maintainer for rheolef -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612621: Bug#619935: Bugs #619935 & #612621 : most debian/* files rewritten + patches
Hello ! > > From Adam: > > Already I can see a few issues: > > * I noticed that you removed -I/usr/include/lam from the CCS and > > CCD commands. I don't remember the exact reasons, but those > > were required for the LAM architectures. /usr/include/mpi > > should be a symlink to /usr/include/lam, but for some reason > > that didn't work. I think it's a worthy goal to try to remove > > that for the next upload, but would rather leave it in for this > > one. I've not tested on lam achitectures. So I'have a question: openmpi does not support yet multi-threads (see eg http://www.open-mpi.org/faq/?category=supported-systems#thread-support ) and we have deleted -DSCOTCH_PTHREAD in CFLAGS. Is lam thread-safe ? There is a FAQ here http://www.lam-mpi.org/faq/category7.php3#question5 but it's not clear for me... > > * In libptscotch-5.1.install, int/lib/libpt*.so is ambiguous: it > > includes both the versioned shared libraries and the symlinks > > which belong in the -dev package. If those file names are > > ambiguous, then only the package order determines which files go > > into which package, and that is not good. Same for > > libscotch-5.1.install. Oups ! yes the symlinks .so should be in libxxx-dev packages. > Are we ready to upload? Let's go ! Thank you for your work, Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619935: src:scotch: FTBFS on several arches due to lex issue
Hi Adam and Johannes, > > From Adam: > > parser_ll.l:123:31: error: 'yylval' undeclared (first use in this function) > From Johannes: > I couldn't (for some unknown reason) reproduce this in a pbuilder I get the last debian/ files from git, then run git-buildpackage and finlay pbuilder, this on two arch (i686 and amd64). I run for each pbuilder on sid, wheezy, sqsueeze and also ubuntu natty, maverick, lucid. The result is the same for all these 12 cases: I couldn reproduce the problem. Also, I dont see any lex problem on debian logs: https://buildd.debian.org/status/package.php?p=scotch despite some logs are out of date. What are the conditions for your run ? - Is it with pbuilder ? - If any, is it on sid ? Could you please give us some details in order to be able to reproduce the bug ? Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612621: ERROR: SCOTCH_dgraphInit: linking with both libScotch and libPTScotch is not allowed
Hi Johannes and Adam, > >> Adam: Thanks for your work on this package! Could you please > >> incorporate this fix in the next upload? > > > > Sure, thanks for the patch. Oh wait -- I think the libscotch$(LIB) > > dependency and -lscotch linkage were needed for binutils-gold, have you > > tested the patch with binutils-gold? I have not yet tested binutils-gold. I recompile scotch-5.11 from original distrib and it works fine for both the two previous tests from Johannes and also from more complex tests together with the pastix solver and the distributed version of the rheolef distribution (large ordering for matrix-vector systems). My machine is a i683 under wheezy: uname -a Linux salsa 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 GNU/Linux Here is a short of the compilation : wget https://gforge.inria.fr/frs/download.php/28043/scotch_5.1.11.tar.gz tar xvzf scotch_5.1.11.tar.gz cd scotch_5.1.11 cp Make.inc/Makefile.inc.i686_pc_linux2.shlib Makefile.inc vi Makefile.inc #1) CFLAGS add : -I/usr/lib/openmpi/include #2) CFLAGS del : -DSCOTCH_PTHREAD since its buggy in openmpi # but conserve -DCOMMON_PTHREAD that is ok make scotch ptscotch -> shared libs *.so Then local install by hand with DESTDIR=$HOME/sys and then run tests: c++ -I/usr/local/include/scotch -o ptscotch_test ptscotch_test.cpp -DSCOTCH_PTSCOTCH -L/usr/local/lib -lptscotch -lptscotcherr -lz ./ptscotch_test -> ok # also with both ptscoth & scotch : mpic++ -I$HOME/sys/include/scotch -o ptscotch_test ptscotch_test.cpp -DSCOTCH_PTSCOTCH -L$HOME/sys/lib -lptscotch -lptscotcherr -lscotch -lz -lrt ./ptscotch_test -> ok ! # also the same with the second test: ptscotch_test2.cpp So, the problem could be in the scotch/debian files: I will try to take a look at these fileb (I dont known about others portability constrainst, such as binutils-golds). Many thanks for your work on the scotch package ! Pierre -- pierre.saram...@imag.fr Directeur de Recherche CNRS Laboratoire Jean Kuntzmann, Grenoble, France http://www-ljk.imag.fr/membres/Pierre.Saramito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612621: ERROR: SCOTCH_dgraphInit: linking with both libScotch and libPTScotch is not allowed
Hello !
Despite the recent patch applied in version 5.1.11.dfgs-4,
the bug seems to be still present on sid/amd64 :
uname -a
Linux mobydick 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011
x86_64 GNU/Linux
apt-cache policy libptscotch-dev
libptscotch-dev:
Installé : 5.1.11.dfsg-4
Candidat : 5.1.11.dfsg-4
Table de version :
*** 5.1.11.dfsg-4 0
500 http://ftp.fr.debian.org/debian/ sid/main amd64 Packages
100 /var/lib/dpkg/status
mpic++ -o ptscotch_test ptscotch_test.cpp -DSCOTCH_PTSCOTCH
-I/usr/include/scotch -lptscotch -lptscotcherr
./ptscotch_test
(0): ERROR: SCOTCH_dgraphInit: linking with both libScotch and
libPTScotch is not allowed
MPI implementation is not thread-safe:
SCOTCH should be compiled without SCOTCH_PTHREAD
Yet, scotch library is unusable...
Any idea to get free from this problem ?
I put back the ptscotch_test.cpp for completness.
Please, see previous mails related to this bug for details.
Thank you for your help,
Pierre
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://www-ljk.imag.fr/membres/Pierre.Saramito
#include
#include
#include
#include
int main() {
int provided;
SCOTCH_Dgraph dgrafdat;
MPI_Init_thread(0, 0, MPI_THREAD_MULTIPLE, &provided);
if (SCOTCH_dgraphInit(&dgrafdat, MPI_COMM_WORLD) != 0) {
if (MPI_THREAD_MULTIPLE > provided) {
std::cout << "MPI implementation is not thread-safe:" << std::endl;
std::cout << "SCOTCH should be compiled without SCOTCH_PTHREAD"
<< std::endl;
exit(1);
}
}
else {
SCOTCH_dgraphExit(&dgrafdat);
}
MPI_Finalize();
return 0;
}
Bug#619837: ITP: pastix -- Parallel sparse matrix package
Package: wnpp Severity: wishlist Owner: Pierre Saramito * Package name: pastix Version : 3184 Upstream Author : Faverge Mathieu , Henon Pascal , Lacoste Xavier , Ramet Pierre * URL : http://pastix.gforge.inria.fr/ * License : CeCILL-C-V2 Programming Lang: C Description : Parallel sparse matrix package PaStiX (Parallel Sparse matriX package) is a scientific library that provides a high performance parallel solver for very large sparse linear systems based on direct and block ILU(k) iterative methods. -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#607038: rheolef: missing include files
Hi Miles,
Thank you for your interest to Rheolef !
The rheolef reference manual is sometimes out-of-date:
please see the rheolef user's manual located, together with many examples,
in the directory :
rheolef-config --docdir
rheolef-config --exampledir
Here, please enter in r0.cc (the reference manual will be fixed in
the next release):
#include "rheolef.h"
using namespace rheolef;
using namespace std;
int main () {
geo g;
cin >> g;
cout << mayavi << full << g;
}
and then :
make r0
mkgeo_grid -t 10 | ./r0
The corresponding Makefile is in attachement (it is also
distributed in the rheolef examples/ directory).
Pierre
--
pierre.saram...@imag.fr
Directeur de Recherche CNRS
Laboratoire Jean Kuntzmann, Grenoble, France
http://www-ljk.imag.fr/membres/Pierre.Saramito
On mar 14 d?c 2010 ? 16:17 +0900, Miles Bader wrote :
> Package: rheolef
> Version: 5.91-1
> Severity: normal
>
> I tried to compile the following example from the rheolef manual:
>
>#include "rheolef/rheolef.h"
>
>void main ()
>{
> geo g;
> cin >> g;
> cout << plotmtv << g;
>}
>
>
>
> Using this command:
>
>g++ -O2 -march=native -o r0 -I/usr/include/rheolef r0.cc
>
> I get the following error output:
>
>In file included from /usr/include/rheolef/tiny_matvec.h:30:0,
> from /usr/include/rheolef/georep.h:29,
> from /usr/include/rheolef/geo.h:147,
> from /usr/include/rheolef/rheolef.h:26,
> from r0.cc:1:
>/usr/include/rheolef/compiler.h:31:62: fatal error: rheolef/config.h: No
> such file or directory
>
> ... and indeed, there is no such file (/usr/include/rheolef/config.h).
>
> [It looks like it may be impossible to compile _any_ programs using
> rheolef, given this situation.]
>
> Thanks,
>
> -Miles
include $(shell rheolef-config --libdir)/rheolef/rheolef.mk
CXXFLAGS = $(INCLUDES_RHEOLEF)
LDLIBS= $(LIBS_RHEOLEF)
default: dirichlet
Bug#599162: installation-reports: /proc/bus/usb/devices file not found
Package: installation-reports Abstract: debian-netinst: /proc/bus/usb/devices file not found Boot method: CD Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso Date: 2010/09/30 11:20 Machine: PC Processor: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz Memory: 3374552 kB Partitions: Sys. fich.Type1K-blocs UtiliséDispo. Uti% Monté sur /dev/sda6 ext314421312 3839772 9848980 29% / /dev/sda5 ext3 432648560 241736804 168934436 59% /home tmpfstmpfs 1687276 0 1687276 0% /lib/init/rw udev tmpfs 1682928 304 1682624 1% /dev tmpfstmpfs 1687276 0 1687276 0% /dev/shm Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller [8086:2e20] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:82d3] 00:01.0 PCI bridge [0604]: Intel Corporation 4 Series Chipset PCI Express Root Port [8086:2e21] (rev 03) Kernel driver in use: pcieport 00:1a.0 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 [8086:3a37] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.1 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 [8086:3a38] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.2 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 [8086:3a39] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.7 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 [8086:3a3c] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ehci_hcd 00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller [8086:3a3e] Subsystem: ASUSTeK Computer Inc. Device [1043:82fe] Kernel driver in use: HDA Intel 00:1c.0 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 [8086:3a40] Kernel driver in use: pcieport 00:1c.5 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 6 [8086:3a4a] Kernel driver in use: pcieport 00:1d.0 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 [8086:3a34] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 [8086:3a35] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 [8086:3a36] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 [8086:3a3a] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ehci_hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 90) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller [8086:3a16] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] 00:1f.2 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller #1 [8086:3a20] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ata_piix 00:1f.3 SMBus [0c05]: Intel Corporation 82801JI (ICH10 Family) SMBus Controller [8086:3a30] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] 00:1f.5 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller #2 [8086:3a26] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ata_piix 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV710 [Radeon HD 4350] [1002:954f] Subsystem: PC Partner Limited Device [174b:e990] Kernel driver in use: radeon 01:00.1 Audio device [0403]: ATI Technologies Inc RV710/730 [1002:aa38] Subsystem: PC Partner Limited R700 Audio Device [Radeon HD 4000 Series] [174b:aa38] Kernel driver in use: HDA Intel 02:00.0 Ethernet controller [0200]: Atheros Communications AR8121
Bug#599156: installation-reports: debian-netinst/grub detects others systems but do not insert it in grub.cfg
Package: installation-reports Abstract: debian-netinst/grub detects others systems but do not insert it in grub.cfg Boot method: CD Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso Date: 2010/09/30 11:20 Machine: PC Processor: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz Memory: 3374552 kB Partitions: Sys. fich.Type1K-blocs UtiliséDispo. Uti% Monté sur /dev/sda6 ext314421312 3839772 9848980 29% / /dev/sda5 ext3 432648560 241736804 168934436 59% /home tmpfstmpfs 1687276 0 1687276 0% /lib/init/rw udev tmpfs 1682928 304 1682624 1% /dev tmpfstmpfs 1687276 0 1687276 0% /dev/shm Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller [8086:2e20] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:82d3] 00:01.0 PCI bridge [0604]: Intel Corporation 4 Series Chipset PCI Express Root Port [8086:2e21] (rev 03) Kernel driver in use: pcieport 00:1a.0 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 [8086:3a37] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.1 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 [8086:3a38] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.2 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 [8086:3a39] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.7 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 [8086:3a3c] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ehci_hcd 00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller [8086:3a3e] Subsystem: ASUSTeK Computer Inc. Device [1043:82fe] Kernel driver in use: HDA Intel 00:1c.0 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 [8086:3a40] Kernel driver in use: pcieport 00:1c.5 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 6 [8086:3a4a] Kernel driver in use: pcieport 00:1d.0 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 [8086:3a34] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 [8086:3a35] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 [8086:3a36] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 [8086:3a3a] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ehci_hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 90) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller [8086:3a16] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] 00:1f.2 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller #1 [8086:3a20] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ata_piix 00:1f.3 SMBus [0c05]: Intel Corporation 82801JI (ICH10 Family) SMBus Controller [8086:3a30] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] 00:1f.5 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller #2 [8086:3a26] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ata_piix 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV710 [Radeon HD 4350] [1002:954f] Subsystem: PC Partner Limited Device [174b:e990] Kernel driver in use: radeon 01:00.1 Audio device [0403]: ATI Technologies Inc RV710/730 [1002:aa38] Subsystem: PC Partner Limited R700 Audio Device [Radeon HD 4000 Series] [174b:aa38] Kernel driver in use: HDA Intel 02:00.0 Ethernet controller [0200]: Ather
Bug#598653: installation-reports: debian squeeze hang at boot time when starting Xwindow: missing firmware for ati radeon card
Package: installation-reports Abstract: squeeze hang at boot time when starting Xwindow: missing firmware for ati radeon card Suggestion: add a menu that propose to download (non-free) firmwares that are required Boot method: CD Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso Date: 2010/09/30 11:20 Machine: PC Processor: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz Memory: 3374552 kB Partitions: Sys. fich.Type1K-blocs UtiliséDispo. Uti% Monté sur /dev/sda6 ext314421312 3839772 9848980 29% / /dev/sda5 ext3 432648560 241736804 168934436 59% /home tmpfstmpfs 1687276 0 1687276 0% /lib/init/rw udev tmpfs 1682928 304 1682624 1% /dev tmpfstmpfs 1687276 0 1687276 0% /dev/shm Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation 4 Series Chipset DRAM Controller [8086:2e20] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:82d3] 00:01.0 PCI bridge [0604]: Intel Corporation 4 Series Chipset PCI Express Root Port [8086:2e21] (rev 03) Kernel driver in use: pcieport 00:1a.0 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 [8086:3a37] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.1 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 [8086:3a38] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.2 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 [8086:3a39] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1a.7 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 [8086:3a3c] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ehci_hcd 00:1b.0 Audio device [0403]: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller [8086:3a3e] Subsystem: ASUSTeK Computer Inc. Device [1043:82fe] Kernel driver in use: HDA Intel 00:1c.0 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 [8086:3a40] Kernel driver in use: pcieport 00:1c.5 PCI bridge [0604]: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 6 [8086:3a4a] Kernel driver in use: pcieport 00:1d.0 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 [8086:3a34] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 [8086:3a35] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 [8086:3a36] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 [8086:3a3a] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ehci_hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 90) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller [8086:3a16] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] 00:1f.2 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller #1 [8086:3a20] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ata_piix 00:1f.3 SMBus [0c05]: Intel Corporation 82801JI (ICH10 Family) SMBus Controller [8086:3a30] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] 00:1f.5 IDE interface [0101]: Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller #2 [8086:3a26] Subsystem: ASUSTeK Computer Inc. Device [1043:82d4] Kernel driver in use: ata_piix 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV710 [Radeon HD 4350] [1002:954f] Subsystem: PC Partner Limited Device [174b:e990] Kernel driver in use: radeon 01:00.1 Audio device [0403]: ATI Technologies Inc RV710/730 [1002:aa38] Subsystem: PC Partner Limited R700 Audio Device [Radeon HD 4000 Series] [174b:aa38
