Bug#1065599: gcc-14-offload-nvptx: openmp offload compile fails due to missing libgomp.spec
Package: gcc-14-offload-nvptx Version: 14-20240303-1 Severity: grave Justification: renders package unusable Dear Maintainer, due to a different organisation in file installation with respect to gcc-12-offload-nvptx, compiling code to offload openmp to nvptx fails with the following: x86_64-linux-gnu-accel-nvptx-none-gcc-14: fatal error: cannot read spec file 'libgomp.spec': No such file or directory compilation terminated. nvptx mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-14 returned 1 exit status compilation terminated. lto-wrapper: fatal error: /usr/libexec/gcc/x86_64-linux-gnu/14//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed While gcc-12-offload-nvptx installed executables, includes, and libs under /usr/lib/gcc/x86_64-linux-gnu/12/accel/nvptx-none, and found them, gcc-14-offload-nvptx does not appear to install them anywhere, nor to depend on any other separate package that does. This effectively renders the package unusable. Thanks in advance, best regards Giacomo Mulas *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-14-offload-nvptx depends on: ii gcc-14 14-20240303-1 ii gcc-14-base14-20240303-1 ii libc6 2.37-15.1 ii libc6-dev 2.37-15.1 ii libgmp10 2:6.3.0+dfsg-2+b1 ii libgomp-plugin-nvptx1 14-20240303-1 ii libmpc31.3.1-1+b2 ii libmpfr6 4.2.1-1+b1 ii libzstd1 1.5.5+dfsg2-2 ii nvptx-tools0.20230904-1 ii zlib1g 1:1.3.dfsg-3.1 gcc-14-offload-nvptx recommends no packages. gcc-14-offload-nvptx suggests no packages. -- no debconf information
Bug#1065598: gcc-13-offload-nvptx: openmp offload compile fails due to missing libgomp.spec
Package: gcc-13-offload-nvptx Version: 13.2.0-18 Severity: grave Justification: renders package unusable Dear Maintainer, due to a different organisation in file installation with respect to gcc-12-offload-nvptx, compiling code to offload openmp to nvptx fails with the following: x86_64-linux-gnu-accel-nvptx-none-gcc-13: fatal error: cannot read spec file 'libgomp.spec': No such file or directory compilation terminated. nvptx mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-13 returned 1 exit status compilation terminated. lto-wrapper: fatal error: /usr/libexec/gcc/x86_64-linux-gnu/13//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed While gcc-12-offload-nvptx installed executables, includes, and libs under /usr/lib/gcc/x86_64-linux-gnu/12/accel/nvptx-none, and found them, gcc-13-offload-nvptx does not appear to install them anywhere, nor to depend on any other separate package that does. This effectively renders the package unusable. While the gcc-12 offload still works, gcc-13 is now the default compiler on sid, meaning that trying to compile openmp to offload to nvptx with the default compiler fails. Thanks in advance, best regards Giacomo Mulas -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-13-offload-nvptx depends on: ii gcc-13 13.2.0-18 ii gcc-13-base13.2.0-18 ii libc6 2.37-15.1 ii libc6-dev 2.37-15.1 ii libgmp10 2:6.3.0+dfsg-2+b1 ii libgomp-plugin-nvptx1 14-20240303-1 ii libmpc31.3.1-1+b2 ii libmpfr6 4.2.1-1+b1 ii libzstd1 1.5.5+dfsg2-2 ii nvptx-tools0.20230904-1 ii zlib1g 1:1.3.dfsg-3.1 gcc-13-offload-nvptx recommends no packages. gcc-13-offload-nvptx suggests no packages. -- no debconf information
Bug#1021660: gcc-12-offload-nvptx: offloading to nvidia via nvptx fails with cuda version 11 (default in sid)
On Thu, 13 Oct 2022, Thomas Schwinge wrote: It does work, but only for the code that GCC/nvptx generates in that 'gcc-12' invocation, but not for the support libraries that it linkes in, which are built for sm_30. Does this mean then that the support libraries of gcc-11-offload-nvptx include both support for sm_30 and sm_35? Is it possible to compile such support libraries so that they do support more than one cuda arch level, instead of having, as in the case of GCC 12 support libraries, _only_ sm_30 as available option (if I understood you correctly)? However, that doesn't really help you as a user of GCC, as long as the distributions don't (have an easy way to) build more variants for several sm_[...]. More work is necessary in GCC/nvptx upstream to make that feasible. well, debian in itself does support this kind of setup, doesn't it? With alternatives, provides in dpkg... Of course, I gather that putting together the machinery to build a number of versions of the same package would be somewhat of a pain to set up and maintain. But anyway, given all you said, can this issue be solved at all, even acting on nvptx-tools? If the issue lies in the support libraries, that problem would still remain regardless of what you do on nvptx-tools, wouldn't it? Thanks, bye Giacomo -- _ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "It's just a shadow of the man you should be Like a garden in the forest that the world will never see You have no thought of answers only questions to be filled" (Big Country) _
Bug#1021660: gcc-12-offload-nvptx: offloading to nvidia via nvptx fails with cuda version 11 (default in sid)
On Thu, 13 Oct 2022, Thomas Schwinge wrote: Aha, that's a legit question to wonder about: the reason is that GCC 11 defaulted to sm_35 code generation (which CUDA 11 still does support): <https://gcc.gnu.org/gcc-11/changes.html#nvptx>, just then GCC 12 again reverted to sm_30: <https://gcc.gnu.org/gcc-12/changes.html#nvptx>. but then, wouldn't the most straightforward fix to change again GCC 12 to generate sm_35 code by default? And also, is there some oscure command line option to explicitly request GCC 12 to generate code of some specific sm level (possibly even higher than sm_35)? I did try using gcc-12 -fopenmp -foffload=nvptx-none -foffload-options="-misa=sm_35" but it still does not work, while in principle it should. Why doesn't it? On the other hand, if I use gcc-11 -fopenmp -foffload=nvptx-none="-misa=sm_30" then I get the same error message I get with gcc-12. Is there something wrong in how GCC 12 handles nvptx code generation options? bye Giacomo -- _________ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "It's just a shadow of the man you should be Like a garden in the forest that the world will never see You have no thought of answers only questions to be filled" (Big Country) _
Bug#1021660: gcc-12-offload-nvptx: offloading to nvidia via nvptx fails with cuda version 11 (default in sid)
On Thu, 13 Oct 2022, Thomas Schwinge wrote: Debian need to update nvptx-tools to a version that includes <https://github.com/MentorEmbedded/nvptx-tools/pull/33> "as: Deal with CUDA 11.0, "Support for Kepler 'sm_30' and 'sm_32' architecture based products is dropped" ok, but I am puzzled by this: if the issue is with nvptx-tools and not with gcc-12-offload-nvptx, why does gcc-11-offload-nvptx work, producing working executables that target sm_35 if I compile with gcc-11 on the same laptop? Thanks, bye Giacomo -- _________ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "It's just a shadow of the man you should be Like a garden in the forest that the world will never see You have no thought of answers only questions to be filled" (Big Country) _
Bug#1021660: gcc-12-offload-nvptx: offloading to nvidia via nvptx fails with cuda version 11 (default in sid)
Package: gcc-12-offload-nvptx
Version: 12.2.0-5
Severity: grave
Justification: renders package unusable for nvidia
Dear Maintainer,
the nvptx plugin for gcc-12 currently available for sid mandates a
cuda level sm_30, which is no longer available in cuda 11 (the one
now in sid). This means that even a trivial example code like
#include
#include
int main(int argc, char **argv){
#pragma omp target parallel
{
int i, j;
i = omp_get_thread_num();
j = omp_get_num_threads();
printf("Hello world! I am thread %d out of %d\n", i, j);
}
}
fails to compile with
capitanata:~/test$ gcc-12 -fopenmp test_openmp_2.c
ptxas fatal : Value 'sm_30' is not defined for option 'gpu-name'
nvptx-as: ptxas returned 255 exit status
mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-12 returned 1
exit status
compilation terminated.
lto-wrapper: fatal error:
/usr/lib/gcc/x86_64-linux-gnu/12//accel/nvptx-none/mkoffload returned 1 exit
status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
even trying to set a specific target gpu arch does not seem to work, e.g.
gmulas@capitanata:~/test$ gcc-12 -fopenmp -foffload-options="-misa=sm_35"
test_openmp_2.c
ptxas fatal : Value 'sm_30' is not defined for option 'gpu-name'
nvptx-as: ptxas returned 255 exit status
mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-12 returned 1
exit status
compilation terminated.
lto-wrapper: fatal error:
/usr/lib/gcc/x86_64-linux-gnu/12//accel/nvptx-none/mkoffload returned 1 exit
status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
On the other hand, gcc-11 appears to have sm_35 as default, meaning it works,
both with and without the -misa option:
capitanata:~/test$ gcc-11 -fopenmp -foffload="-misa=sm_35" test_openmp_2.c
/usr/bin/ld: /tmp/user/1000/ccY5a4YE.crtoffloadtable.o: warning: relocation
against `__offload_vars_end' in read-only section `.rodata'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
capitanata:~/test$ gcc-11 -fopenmp test_openmp_2.c
/usr/bin/ld: /tmp/user/1000/ccHibGBc.crtoffloadtable.o: warning: relocation
against `__offload_vars_end' in read-only section `.rodata'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
and the resulting code runs:
capitanata:~/test$ ./a.out
Hello world! I am thread 4 out of 8
Hello world! I am thread 1 out of 8
Hello world! I am thread 6 out of 8
Hello world! I am thread 7 out of 8
Hello world! I am thread 0 out of 8
Hello world! I am thread 5 out of 8
Hello world! I am thread 2 out of 8
Hello world! I am thread 3 out of 8
Would it be possible to change the default -misa of gcc 12 to sm_35,
to enable gpu offloading to nvidia to work with gcc-12? And/or, is there
some undocumented, or poorly documented, way to actually specify on the
command line the requested cuda level architecture so that it works with
cuda 11 libraries?
Thanks in advance
Best regards
Giacomo Mulas
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gcc-12-offload-nvptx depends on:
ii gcc-12 12.2.0-5
ii gcc-12-base12.2.0-5
ii libc6 2.35-3
ii libc6-dev 2.35-3
ii libgmp10 2:6.2.1+dfsg1-1.1
ii libgomp-plugin-nvptx1 12.2.0-5
ii libmpc31.2.1-2
ii libmpfr6 4.1.0-3
ii libzstd1 1.5.2+dfsg-1
ii nvptx-tools0.20180301-1
ii zlib1g 1:1.2.11.dfsg-4.1
gcc-12-offload-nvptx recommends no packages.
gcc-12-offload-nvptx suggests no packages.
-- no debconf information
Bug#980225: lvm2-lockd: lvmlockd.service fails to start as of the latest update to 2.03.11-1 in sid
Package: lvm2-lockd Version: 2.03.11-1 Severity: grave Justification: renders package unusable Dear Maintainer, after the update of lvm2 packages to version 2.03.11-1 in sid, the lvmlockd.service fails to start and just hangs till systemctl times out and exits with an error. The previous version worked flawlessly on my laptop. Please let me know if there are any checks I can do to help nailing down the problem, and/or any relevant configuration details that I can provide. Thanks in advance, best regards Giacomo Mulas -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.4-jak (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it_IT,en_EN Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lvm2-lockd depends on: ii libc6 2.31-9 ii libdlm3 4.0.9-2 ii libsanlock-client1 3.8.2-1+b2 ii libselinux1 3.1-2+b2 ii libudev1247.2-4 ii lvm22.03.11-1 lvm2-lockd recommends no packages. lvm2-lockd suggests no packages. -- no debconf information
Bug#972974: [Pkg-clamav-devel] Bug#972974: Bug#972974: clamav-freshclam start faild.
On Thu, 29 Oct 2020, Sebastian Andrzej Siewior wrote: The bug report is about freshclam not clamd. yes, but both freshclam and clamd, starting from the same package version, have exactly the same behaviour, failing to start with exactly the same error message. So the above information is likely pertinent to freshclam as well. What is the appropriate debian policy in this case? File another, more or less identical, bug report for the clamav-daemon package? Or can the same bug id refer to two different packages, if they are both simultaneously affected in the same way and originate from the same source package? Or should it be duplicated, even if it probably is indeed the same bug affecting two packages? I'm asking so that I know what to do in such a case, should it happen again. thanks, best regards Giacomo Mulas -- _ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#956709: libglom-1.30-0: upgrade of boost packages makes libglom-1.30-0 uninstallable
Package: libglom-1.30-0 Version: 1.30.4-6 Severity: grave Justification: renders package unusable Dear Maintainer, the upgrade of libboost-python1.67.0 breaks a dependency of libglom-1.30-0, thereby making it uninstallable. To fix this, it must be rebuilt with the new libraries _and_ with python 3.8 instead of 3.7. Thanks in advance, best regards Giacomo Mulas -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.13-jak (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libglom-1.30-0 depends on: ii libarchive133.4.0-2 ii libboost-python1.67.0 [libboost-python1.67.0-py37] 1.67.0-17 ii libc6 2.30-4 ii libepc-1.0-30.4.6-2 ii libgcc-s1 10-20200411-1 ii libgda-5.0-45.2.9-2 ii libgdamm-5.0-13 4.99.11-3 ii libgettextpo0 0.19.8.1-10 ii libglib2.0-02.64.1-1 ii libglibmm-2.4-1v5 2.64.2-1 ii libpython3.83.8.2-1+b1 ii libsigc++-2.0-0v5 2.10.2-1 ii libstdc++6 10-20200411-1 ii libxml++2.6-2v5 2.40.1-3 ii libxml2 2.9.10+dfsg-5 ii libxslt1.1 1.1.34-4 libglom-1.30-0 recommends no packages. libglom-1.30-0 suggests no packages. -- no debconf information
Bug#956578: libcasa-python3-4: package became uninstallable with update of libboost-python1.67.0
On Mon, 13 Apr 2020, Sebastian Ramacher wrote: This is caused by the ongoing effort to remove Python 3.7. casacore needs to be rebuilt against the new libboost-python1.67.0 version. But this build fails with: | -- Looking for python3 specific environment... | -- Found PythonInterp: /usr/bin/python3.7 (found version "3.7.7") | -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found version "3.8.2") | -- Found Boost: /usr/include (found version "1.67.0") In the source dir, find python3/CMakeLists-older-cmake.txt, in there you'll find: # Detect the python properties set(Python_ADDITIONAL_VERSIONS 3.7 3.6 3.5 3.4) add 3.8 before 3.7, so that it now reads: # Detect the python properties set(Python_ADDITIONAL_VERSIONS 3.8 3.7 3.6 3.5 3.4) then, when I run fakeroot debian/rules build it detects and tries to use python3.8. Please, see if this is enough to get the package to compile correctly with the new boost libraries. Thanks again, bye Giacomo -- _________ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#956578: libcasa-python3-4: package became uninstallable with update of libboost-python1.67.0
On Mon, 13 Apr 2020, Sebastian Ramacher wrote: This is caused by the ongoing effort to remove Python 3.7. casacore needs to be rebuilt against the new libboost-python1.67.0 version. But this build fails with: | -- Looking for python3 specific environment... | -- Found PythonInterp: /usr/bin/python3.7 (found version "3.7.7") | -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found version "3.8.2") | -- Found Boost: /usr/include (found version "1.67.0") I found that the CMake build of casacore recognises these environment variables: PYTHON3_EXECUTABLE PYTHON3_LIBRARY PYTHON3_INCLUDE_DIR Did you try to explicitly set e.g. one or more of PYTHON3_EXECUTABLE=/usr/bin/python3.8 PYTHON3_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython3.8.so PYTHON3_INCLUDE_DIR=/usr/include/python3.8 ? If not, could you try that and let me know? I would try myself but, as I said in my report, I pinned the boost library, so I cannot do it in the proper up to date sid environment. Bye Giacomo -- _________ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#956578: libcasa-python3-4: package became uninstallable with update of libboost-python1.67.0
On Mon, 13 Apr 2020, Sebastian Ramacher wrote: This is caused by the ongoing effort to remove Python 3.7. casacore needs to be rebuilt against the new libboost-python1.67.0 version. But this build fails with: | -- Looking for python3 specific environment... | -- Found PythonInterp: /usr/bin/python3.7 (found version "3.7.7") | -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.8.so (found version "3.8.2") | -- Found Boost: /usr/include (found version "1.67.0") | CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message): | Could NOT find Boost (missing: python37) (found version "1.67.0") | Call Stack (most recent call first): | /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE) | /usr/share/cmake-3.16/Modules/FindBoost.cmake:2179 (find_package_handle_standard_args) | python3/CMakeLists-older-cmake.txt:37 (find_package) | python3/CMakeLists.txt:4 (include) I guess this depends on CMake finding and trying to use python 3.7 instead of 3.8, even if python 3.8 libraries are then found and selected. Isn't there a way to force CMake to use python 3.8? I confess I am more familiar with autotools than with CMake, but I would be very surprised if there were not a switch in its config to explicitly select the python to use. I will try to have a look at the source package and let you know if I find it out. Thanks anyway, bye Giacomo -- _________ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#956580: aoflagger: boost update makes aoflagger uninstallable
Package: aoflagger Version: 2.15.0-1+b1 Severity: grave Justification: renders package unusable Dear Maintainer, the recent update of boost libraries to version 1.67.0-17+b1, in particular probably of libboost-python1.67.0, apparently broke some dependency of aoflagger, forcing its removal and making it uninstallable. I suspect it is a mere packaging problem but cannot investigate it in detail, since I need aoflagger and thus pinned the version of boost till this is sorted out. It is even possible that this is a problem on the side of boost libraries, if suitable please feel free to contact their maintainer about this. Or it may be due to similar problems simultaneously making libcasa-python3-4 uninstallable as well. Thanks in advance, best regards Giacomo Mulas -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.13-jak (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aoflagger depends on: ii libaoflagger0 2.15.0-1+b1 ii libatkmm-1.6-1v52.28.0-2 ii libboost-date-time1.67.01.67.0-17 ii libboost-python1.67.0 [libboost-python1.67.0-py37] 1.67.0-17 ii libboost-system1.67.0 1.67.0-17 ii libc6 2.30-4 ii libcairomm-1.0-1v5 1.12.2-4 ii libcasa-casa4 3.2.1-4+b2 ii libcasa-ms4 3.2.1-4+b2 ii libcasa-tables4 3.2.1-4+b2 ii libgcc-s1 10-20200411-1 ii libglibmm-2.4-1v5 2.64.2-1 ii libgtkmm-3.0-1v53.24.2-1 ii libpython3.83.8.2-1+b1 ii libsigc++-2.0-0v5 2.10.2-1 ii libstdc++6 10-20200411-1 aoflagger recommends no packages. Versions of packages aoflagger suggests: ii aoflagger-dev 2.15.0-1+b1 -- no debconf information
Bug#956578: libcasa-python3-4: package became uninstallable with update of libboost-python1.67.0
Package: libcasa-python3-4 Version: 3.2.1-4+b2 Severity: grave Justification: renders package unusable Dear Maintainer, The update of libboost-python1.67.0 to 1.67.0-17+b1 on sid apparently broke the dependencies of libcasa-python3-4, thus making it uninstallable. I am almost sure this is a mere packaging problem, but I am not sure whether it should be fixed in casa or in boost packages. At the moment I cannot check in detail, since I pinned the version of boost on my laptop to avoid the removal of libcasa-python3-4 and all packages that depend on it. If suitable, please feel free to relay this report to the maintainer of the boost packages. Thanks in advance, best regards Giacomo Mulas -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.13-jak (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcasa-python3-4 depends on: ii libboost-python1.67.0 [libboost-python1.67.0-py37] 1.67.0-17 ii libc6 2.30-4 ii libcasa-casa4 3.2.1-4+b2 ii libgcc-s1 10-20200411-1 ii libpython3.83.8.2-1+b1 ii libstdc++6 10-20200411-1 libcasa-python3-4 recommends no packages. libcasa-python3-4 suggests no packages. -- no debconf information
Bug#910795: libopal3.10.10: package uninstallable
Package: libopal3.10.10 Severity: grave Justification: renders package unusable Dear Maintainer, now that libx264-152 is not available anymore, libopal3.10.10 became uninstallable. It can only be used by people retaining on their system a copy of an unmaintained version of an old library. Please recompile libopal3.10.10 against newer libraries. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.10-jak (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libopal3.10.10 depends on: pn libavcodec57 | libavcodec-extra57 ii libavutil557:3.4.3-1 ii libc6 2.27-6 ii libcapi20-31:3.27-3 ii libgcc11:8.2.0-7 ii libgsm11.0.13-4+b2 ii libogg01.3.2-1+b1 ii libpt2.10.11 2.10.11~dfsg-2.1 ii libspandsp20.0.6+dfsg-0.1 ii libspeex1 1.2~rc1.2-1+b2 ii libspeexdsp1 1.2~rc1.2-1+b2 ii libsrtp0 1.4.5~20130609~dfsg-2 ii libssl1.0.21.0.2o-1 ii libstdc++6 8.2.0-7 ii libtheora0 1.1.1+dfsg.1-14+b1 ii libtiff5 4.0.9-6 pn libx264-152 libopal3.10.10 recommends no packages. libopal3.10.10 suggests no packages.
Bug#910794: ekiga uninstallable, please recompile against more recent libs
Package: ekiga Severity: grave Justification: renders package unusable Dear Maintainer, ekiga became uninstallable now that libx264-152 is not available anymore. Please recompile against more recent libs (same for libopal), otherwise ekiga will only work for those that retained an old, unmaintained library no longer available. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.10-jak (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ekiga depends on: ii gconf-service 3.2.6-5 ii gconf2 3.2.6-5 ii gnome-icon-theme3.12.0-3 ii libatk1.0-0 2.30.0-1 ii libavahi-client30.7-4+b1 ii libavahi-common30.7-4+b1 ii libavahi-glib1 0.7-4+b1 ii libboost-signals1.62.0 1.62.0+dfsg-10 ii libc6 2.27-6 ii libcairo2 1.15.12-1 ii libdbus-1-3 1.12.10-1 ii libdbus-glib-1-20.110-3 ii libfontconfig1 2.13.1-1 ii libfreetype62.8.1-2 ii libgcc1 1:8.2.0-7 ii libgconf-2-43.2.6-5 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-02.58.1-2 ii libgtk2.0-0 2.24.32-3 ii libldap-2.4-2 2.4.46+dfsg-5 ii libnotify4 0.7.7-3 pn libopal3.10.10 ii libpango-1.0-0 1.42.4-3 ii libpangocairo-1.0-0 1.42.4-3 ii libpangoft2-1.0-0 1.42.4-3 ii libpt2.10.112.10.11~dfsg-2.1 ii libsasl2-2 2.1.27~rc8-1 ii libspeexdsp11.2~rc1.2-1+b2 ii libstdc++6 8.2.0-7 ii libx11-62:1.6.7-1 ii libxext62:1.3.3-1+b2 ii libxml2 2.9.4+dfsg1-7+b1 ii libxv1 2:1.0.11-1 Versions of packages ekiga recommends: ii gvfs 1.38.0-2 ii yelp 3.30.0-1 Versions of packages ekiga suggests: pn asterisk pn ekiga-plugin-evolution pn gnugk pn mediaproxy pn rtpproxy pn ser pn siproxd pn yate
Bug#904779: openmpi-bin: any program hangs on first MPI call (e.g. MPI_Init())
instead, although this may result in lower performance. NOTE: You can disable this warning by setting the MCA parameter btl_base_warn_component_unused to 0. -- and then hangs there forever. Now, I think it has _always_ been the default of openmpi to try to use infiniband first, if available, and then fall back on slower tcp. The question is: why does it apparently hang on trying to use some faster interconnection instead of gracefully faling and moving on to the next available slower one, as it did before? Second question, a practical one: how should I configure mpiexec.openmpi so that it uses self, tcp by default directly, when called without arguments? This would at least make openmpi usable (with some configuration) and demote the bug from grave to important or even normal, perhaps putting some info about this problem and how to deal with it in a README.debian file. Of course it's a workaround, not a real solution, but way better than nothing :) thanks! Giacomo -- _________ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#904779: openmpi-bin: any program hangs on first MPI call (e.g. MPI_Init())
bpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f94cc2e8000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f94cc12b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f94cc126000) libopen-rte.so.40 => /usr/lib/x86_64-linux-gnu/libopen-rte.so.40 (0x7f94cc06f000) libopen-pal.so.40 => /usr/lib/x86_64-linux-gnu/libopen-pal.so.40 (0x7f94cbfc2000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f94cbfb6000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f94cbe22000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f94cbe1d000) libhwloc.so.5 => /usr/lib/x86_64-linux-gnu/libhwloc.so.5 (0x7f94cbddc000) libevent-2.1.so.6 => /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6 (0x7f94cbb86000) libevent_pthreads-2.1.so.6 => /usr/lib/x86_64-linux-gnu/libevent_pthreads-2.1.so.6 (0x7f94cb983000) /lib64/ld-linux-x86-64.so.2 (0x7f94cc4a8000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x7f94cb776000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x7f94cb56c000) Please let me know whatever I can do to help pinpoint this. I need to be able to use my computer to develop my MPI codes, and I cannot understand at all why it abruptly stopped working. Also, if you tell me it does work properly on another current sid system, I'd like to find out what makes the difference. Thanks in advance Giacomo Mulas -- _________ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180255 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#904779: openmpi-bin: any program hangs on first MPI call (e.g. MPI_Init())
Package: openmpi-bin
Version: 3.1.1.real-4+b1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
since the latest wave of package updates (gnu compilers big version switch +
new openmpi package) even the simplest code, compiled by mpicc.openmpi (or
mpif90.openmpi) hangs forever on first initialisation of MPI. Even the
following "hello world" does it on my machine:
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv){
int nprocs=0, myrank=0, ierr=0;
ierr = MPI_Init( , );
ierr = MPI_Comm_rank(MPI_COMM_WORLD, );
ierr = MPI_Comm_size(MPI_COMM_WORLD, );
printf("MPI_Init call ok\n");
printf("My rank is = %d\n", myrank);
printf("number of procs is = %d\n", nprocs);
printf("\n");
ierr = MPI_Finalize();
printf("MPI_Finalize call ok, returned %d\n", ierr);
return 0;
}
Of course, this makes the package completely unusable for me. I don't know
whether this can be related to bug #584699: in fact my laptop is not really
multihomed. Please let me know if there is something I can do to help
pinpoint this. By the way, the above snippet of code works perfectly if
compiled and run under mpich.
Best regards
Giacomo Mulas
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (401, 'unstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.17.8-jak (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to it_IT.utf8), LANGUAGE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to
it_IT.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages openmpi-bin depends on:
ii libc62.27-5
ii libevent-2.1-6 2.1.8-stable-4
ii libevent-pthreads-2.1-6 2.1.8-stable-4
ii libhwloc51.11.10-3
ii libopenmpi3 3.1.1.real-4+b1
ii openmpi-common 3.1.1.real-4+b1
ii openssh-client [ssh-client] 1:7.7p1-3
openmpi-bin recommends no packages.
Versions of packages openmpi-bin suggests:
ii gfortran 4:8.1.0-1
-- no debconf information
Bug#889148: am-utils: incorrect installation installs scripts instead of executables
Package: am-utils Version: 6.2+rc20110530-3.2+b1 Severity: grave Justification: renders package unusable Dear Maintainer, I just updated the am-utils package and it became unusable with the update. Any command in the am-utils package would fail with a message like: herschel:~# amq /usr/sbin/amq: error: '/usr/sbin/.libs/amq' does not exist This script is just a wrapper for amq. See the libtool documentation for more information. I was able to recover a working am-utils by recompiling from sources and manually installing the actual binaries from the files created by the build, e.g. in my case A.x86_64-unknown-linux-deb9.3/amq/.libs/pawd and similarly for the others. For some reason the make does not install the real binaries but libtool wrapper scripts, an the latter are then included in the deb package, resulting in an unusable package altogether. Best regards Giacomo Mulas -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.13-jak (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8), LANGUAGE=it_IT,en_EN (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages am-utils depends on: ii debconf1.5.65 ii debianutils4.8.4 ii libamu46.2+rc20110530-3.2+b1 ii libc6 2.26-6 ii libwrap0 7.6.q-27 ii rpcbind [portmap] 0.2.3-0.6 ii ucf3.0036 am-utils recommends no packages. Versions of packages am-utils suggests: pn am-utils-doc pn nis
Bug#865526: closed by Gianfranco Costamagna <locutusofb...@debian.org> (Re: libpetsc3.7.5-dev: uninstallable on current sid)
On Thu, 29 Jun 2017, Debian Bug Tracking System wrote: if you want it being installable, just stop using sid. sid is meant for transitions, so stuff is uninstallable from time to time. does this mean bug reports are undesireable for packages in sid? I had a different impression. Like testing sid and reporting bugs and helping to fix them contributes to make debian better. You can email release team if you want openmpi to migrate faster No, I did something simpler: a recompile of the petsc package from the source package did the trick. Like: apt-get build-dep petsc-dev (did nothing in my case, all build-depends were already installed) apt-get --compile source petsc-dev dpkg -i resulting packages. It worked and I reported about it, just to help others since my problem was fixed already and I did not need to do anything more about it. So, question: what is the point being rude to someone that politely reports about a bug and actually even suggests how to fix it? And a remark: I may understand that you think the bug is not yours to fix, so you may tag it "wontfix" or move it to openmpi (by the way, that's fixed now). But closing the bug is just plain wrong, since the bug is there and the package is still uninstallable. regards Giacomo -- _____ Giacomo Mulas <gmu...@oa-cagliari.inaf.it> _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#865526: recompiled from source
Just to follow up: after fixing the mess in my openmpi environment (replacing the links to the shared libraries that were missing even if registered in the package manager) I was able to recompile the petsc packages from source with just a plain "fakeroot debian/rules binary". I installed them, they appear to work, at least with my home-developed software. Therefore, unless I overlooked something important, it should be trivial for you to just bump the package version and trigger a recompile. Best regards Giacomo -- _____ Giacomo Mulas <gmu...@oa-cagliari.inaf.it> _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _
Bug#865526: libpetsc3.7.5-dev: uninstallable on current sid
Package: libpetsc3.7.5-dev Version: 3.7.5+dfsg1-4+b1 Severity: grave Justification: renders package unusable Dear Maintainer, since openmpi was upgraded in sid, libpetsc3.7.5-dev and libpetsc3.7.6-dev became uninstallable on sid, since they depend on libopenmpi-dev (< 2.0.3). I tried compiling the package from source but it gets stuck precisely when checking mpi. Upon further checking it looks like the openmpi development environment on my laptop is broken, despite all packages appear to be correctly installed: many libs are installed only under /usr/lib/x86_64-linux-gnu/openmpi/lib, with no soft links to /usr/lib/x86_64-linux-gnu (even if running dpkg -L libopenmpi2 says they should be!). Any chance to have petsc-dev installable again soon? petsc and slepc are key dependencies of my quite a bit of my home-developed scientific software. Any suggestion for a quick-n-dirty fix to get it to compile with the newer openmpi? Thanks in advance. I'll let you know if/when I can compile a working petsc package from source. Bye Giacomo -- System Information: Debian Release: 9.0 APT prefers buildd-unstable APT policy: (400, 'buildd-unstable'), (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.25-jak (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8), LANGUAGE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpetsc3.7.5-dev depends on: ii gfortran 4:6.3.0-4 ii libblacs-mpi-dev 1.1-40 ii libfftw3-dev 3.3.6p2-1 ii libfftw3-mpi-dev 3.3.6p2-1 ii libhdf5-mpi-dev 1.10.0-patch1+docs-3 ii libhypre-dev 2.11.1-3 ii libmumps-dev 4.10.0.dfsg-4+b2 ii libopenmpi-dev2.1.1-4 ii libpetsc3.7.5 3.7.5+dfsg1-4+b1 ii libptscotch-dev 5.1.12b.dfsg-2.1 ii libscalapack-mpi-dev 1.8.0-14 ii libspooles-dev2.2-12+b1 ii libssl-dev1.1.0f-3 ii libsuitesparse-dev1:4.5.5-1 ii libsuperlu-dev5.2.1+dfsg1-2 ii python2.7.13-2 Versions of packages libpetsc3.7.5-dev recommends: ii csh [c-shell] 20110502-2.2+b1 ii ksh 93u+20120801-3.1 ii mksh54-2+b4 ii tcsh [c-shell] 6.20.00-7 ii zsh 5.3.1-5 Versions of packages libpetsc3.7.5-dev suggests: pn libluminate-dev pn libpetsc3.7.5-dbg pn petsc-dev ii petsc3.7.5-doc 3.7.5+dfsg1-4
Bug#830715: musescore: just rebuilding from source package fixes this
Package: musescore Version: 2.0.2+dfsg-2 Followup-For: Bug #830715 Dear Maintainer, musescore became uninstallable when qtquick1 was removed. However, it builds flawlessly from the source package: I just did it locally and obtained an installable and perfectly working musescore package. Please just rebuild it ignoring (or removing) the build-depends: qtquick1-5-dev and you will get a working package. Thanks, bye Giacomo
Bug#764448: mate-applets 1.8.1+dfsg1-1 tries to overwrite files in gnome-applets 3.8.1-1
On Thu, 9 Oct 2014, Mike Gabriel wrote: Hi Giacomo, Hi Mike Thanks for reporting this. This needs to be fixed upstream+downstream. What are the files that trouble you (and us all)? (Asking, because I can't check right now, because I am at a customer). Manpages. I had a look at the contents of the package, apparently everything else has a unique (full) filename, meaning that at least some part of the path is unique, even if the final filename duplicates something in gnome, so this is ok. Instead, most manpages in man1 in the package have exactly the same name as their gnome counterparts, so these should be changed/fixed. E.g. cdplayer_applet.1.gz, charpick_applet.1.gz, cpufreq-selector.1.gz, drivemount_applet.1.gz, geyes_applet.1.gz, gkb_applet.1.gz, ... Perhaps they should all be prefixed with mate- or suffixed with -mate or something similar to make their names unique. This should be relatively painless, apart from having to do some script-fu to rename the manpages before building the deb binary package... Could be done by awk probably, or even with some pipeing of commands like cd $INSTALL/usr/share/man/man1 ; for i in `ls *.1.gz` ; mv $i mate-$i ; done or something along these lines. Cheers Giacomo -- _ Giacomo Mulas gmu...@oa-cagliari.inaf.it _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752749: [cpl-plugin-xshoo-calib] uninstallable: wrong directory name in wget command in postinst
Package: cpl-plugin-xshoo-calib
Version: 2.5.0+dfsg-1
Severity: serious
--- Please enter the report below this line. ---
in the postinst script, the package attempts to download
ftp://ftp.eso.org/pub/dfs/pipelines/${PIPELINE}/${KIT}.tar.gz
which after variable substitution becomes
ftp://ftp.eso.org/pub/dfs/pipelines/xshoo/xshoo-kit-2.5.0.tar.gz
while the correct URL would be
ftp://ftp.eso.org/pub/dfs/pipelines/xshooter/xshoo-kit-2.5.0.tar.gz
This makes the package uninstallable. This bug has been present for several
releases of the package, I am surprised nobody filed this bugreport before.
The fix appears trivial.
Bye
Giacomo
--- System information. ---
Architecture: amd64
Kernel: Linux 3.14.5-jak
Debian Release: jessie/sid
500 all liveusb.info
401 unstablewww.deb-multimedia.org
401 unstablemi.mirror.garr.it
401 unstableftp.debian.org
401 unstabledownload.jitsi.org
399 stable dl.google.com
399 stable deb.opera.com
10 experimentalftp.debian.org
10 experimentalcdn.debian.net
--- Package information. ---
Depends (Version) | Installed
===-+-===
cpl-plugin-xshoo| 2.5.0+dfsg-1
wget| 1.15-1+b1
Package's Recommends field is empty.
Package's Suggests field is empty.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742971: [Pkg-utopia-maintainers] Bug#742971: Not NM managed interfaces
qOn Mon, 31 Mar 2014, Michael Biebl wrote: I did test with an unmanaged interface wlan0 in /e/n/i and couldn't reproduce the bug. I will try to see if the existence of a bridge config makes a difference. Thanks for the hint. I also have an unmanaged interface, a dummy one. I use it to develop some software that depends on having the interface always up and routed. In /etc/modules I have a dummy line to load the dummy module. In /etc/network/interfaces I have: # The dummy network interface auto dummy0 iface dummy0 inet static address 192.167.8.254 netmask 255.255.255.255 broadcast 192.167.8.254 network 192.167.8.254 name Ethernet LAN card and in /etc/NetworkManager/NetworkManager.conf I have [ifupdown] managed=false after a standard boot sequence I have a dummy0=dummy0 line in /run/network/ifstate and, lo and behold, network-manager segfaults. I have to hand-edit /run/network/ifstate and remove the dummy0=dummy0 line, in order to be able to start network-manager and have a working wifi. Please try to see if you can reproduce the segfault of nm with my setup, which requires little modification on a working system. If yes, you are in a position to debug this nasty issue; if not, it means there must be some funny interaction with something else. I remember a similar issue happened some time ago with another package, and it turned out that the developer had some library from experimental on his system that had slightly different definitions of internal structures, so that it worked for him, it was broken for almost everybody else... Let me know Giacomo -- _ Giacomo Mulas gmu...@oa-cagliari.inaf.it _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655424: mistake in debian/rules?
After stumbling on the same problem, I tried recompiling the hplip source package from scratch on my sid box. Apparently hpcups and hpcupsfax _are_ compiled all right, _but_ they are _not_ installed in any package. After compilation, they are both in debian/tmp/usr/cups/filter, but they are placed neither in debian/hplip/usr/cups/filter (where all other filters are installed, so that they end up in the hplip package) nor in debian/printer-driver-hpcups/usr/lib/cups/filter (where perhaps they were supposed to go, guessing from changelog). So this appears to be a bug in the debian packaging. I don't know where the maintainer planned to put the necessary install commands, there may be several possibilities, but apparently (s)he just forgot to add them. A quick and dirty fix would be to put two lines in debian/rules, in the install-arch-stamp stanza, like install -m 755 hpcups $(CURDIR)/debian/printer-driver-hpcups/usr/lib/cups/filter/ install -m 755 hpcupsfax $(CURDIR)/debian/printer-driver-hpcups/usr/lib/cups/filter/ or install -m 755 hpcups $(CURDIR)/debian/hplip/usr/lib/cups/filter/ install -m 755 hpcupsfax $(CURDIR)/debian/hplip/usr/lib/cups/filter/ or something along these lines depending on which package the two executables are supposed to be in. Of course, there may be nicer alternatives, in any case I am sure the maintainer will very quickly and easily fix this as soon as (s)he finds out about it. Bye Giacomo -- _ Giacomo Mulas gmu...@oa-cagliari.inaf.it _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517005: unresolved symbol
I was hit by the same problem. Upon booting in single-user mode, I tried manually loading the fglrx module, and it failed to load due to an unresolved symbol, namely flush_tlb_page. I looked it up in the source code, and apparently it is found in firegl_public.c, where there is some preprocessor logic to avoid calling that function in recent kernels, which do not export it anymore. I am not familiar enough with kernel programming to understand exactly what is wrong, but apparently it does not work as intended, at least not on a 2.6.28 kernel. I hope this helps, bye Giacomo Mulas -- _ Giacomo Mulas gmu...@ca.astro.it _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476352: openoffice.org-core: depends on experimental libcairo2
Package: openoffice.org-core Version: 1:2.4.0-4 Severity: grave Justification: renders package unusable -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) The new version of openoffice.org-core (2.4.0-4), just recompiled against new python and uploaded, was compiled (on amd64) against an experimental version of libcairo2 (= 1.5.0). Therefore it depends on a version which is currently unavailable on sid, making the package (and almost all of openoffice.org, which depends on it) uninstallable. Please recompile it (for amd64) against the version of libcairo2 which is currently available in sid (which is 1.4.14-1 at the moment), unless a new version of cairo fixing this is already scheduled for imminent upload. Thanks, bye Giacomo Mulas -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375701: ftp.debian.org: errors in Packages file in sid/main/binary-amd64 and sid/main/binary-m68k
Package: ftp.debian.org Severity: grave Justification: renders package unusable The Packages file in sid/main/binary-amd64 and binary-m68k contain sintax errors in the Filename: field for some packages, namely apcd, battery-stats, beep-media-player, beep-media-player-dev, diald, k3d, k3d-dev, oss-preserve. For each of these packages the Filename: field contains the version of the package spuriously added in the path, i.e. pool/main/a/apcd (0.6b.nr-2)/apcd_0.6b.nr-2+b1_amd64.deb instead of pool/main/a/apcd/apcd_0.6b.nr-2+b1_amd64.deb This in turn causes all apt frontends to fail when they try to parse the list of available packages. Until this is fixed, dselect, aptitude etc. will not be able to update the list of available packages and will be therefore largely unusable. I have no idea as to what produced the bogus Packages file nor why this happened only for the amd64 and m68k architecture. For some of the packages with corrupted Filename: entry binary-only updates were recently uploaded, I don't know whether this may or may not be related to it. Thanks Giacomo Mulas -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-turion64-jak Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
