Bug#739080: ITP: tapsim -- Atom probe experiment simulator
Package: wnpp Severity: wishlist Owner: D Haley * Package name: tapsim Version : 1.0b.r766 Upstream Author : Christian Oberforfer http://www.uni-muenster.de/Physik.MP/Schmitz/en/tapsim/ * License : GPL Programming Lang: C, C++ Description : Atom probe experiment simulator Simulation package for Atom Probe measurements of samples with heterogenous evaporation properties. It allows the theoretical analysis of tips with arbitrary shape, with arbitrary atomic structure and well-defined chemical composition. In this regard, practically no limitations exist. Each tip atom is represented by a Wigner-Seitz cell. Sponsor is required. Plan to maintain as part of debian-science. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739080: Acknowledgement (ITP: tapsim -- Atom probe experiment simulator)
Now clonable from: https://bitbucket.org/mycae_gmx/tapsim_debian.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737653: libtet1.5-dev: consider enabling TETLIBRARY define
Package: libtet1.5-dev Version: 1.5.0-1 Severity: normal Dear Maintainer, libtet appears to be compiled without TETLIBRARY defined. The example from upstream ( ) does not compile due to this (aside from other minor upstream errors). TETLIBRARY is required for the library interface, and is located in /usr/include/tetgen.h:23. This is needed to allow for calling using the lib interface mode, as suggested by upstream. Could this be enabled for future releases? Thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-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 Versions of packages libtet1.5-dev depends on: ii libtet1.5 1.5.0-1 libtet1.5-dev recommends no packages. libtet1.5-dev 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#737653: missing URL
Hi
Looks like I left out the upstream URL. The file I am referring to is
here [1] , and the compilation error is:
g++ tetcall.cxx -o tetcall -ltet
...
tetcall.cxx:190:42: error: cannot convert ‘const char*’ to
‘tetgenbehavior*’ for argument ‘1’ to ‘void
tetrahedralize(tetgenbehavior*, tetgenio*, tetgenio*, tetgenio*, tetgenio*)’
tetrahedralize("pq1.414a0.1", &in, &out);
^
...
Forcing a define for TETLIBRARY gives (as to be expected) a link error
from a missing definition.
Thanks!
[1] http://wias-berlin.de/software/tetgen/files/tetcall.cxx
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738339: libqhull-dev: qhull overflows stack with null outputs
Package: libqhull-dev Version: 2009.1-3 Severity: wishlist Dear Maintainer, For qhull>2012, the file pointer arguments for qh_new_qhull can no longer be null - this results in the program going into infinite recursion between qh_fprintf and qh_error, as qh_error tries to print, and qh_fprintf raises calls the error function, as the output pointer is null. The output looks like the following, when running under valgrind, where indicates clipped output: QH6232 Qhull internal error (userprintf.c): fp is 0. Wrong qh_fprintf called. . QH6232 Qhull internal error (userprintf.c): fp is 0. Wrong qh_fprintf called. QH6232 Qhull internal error (userprintf.c): fp is 0. Wrong qh_fprintf called. ==11016== Stack overflow in thread 1: can't grow stack to 0xffef01ff8 For completeness, I am including this link, which states that in previous versions of qhull ( <2011.2) passing NULL triggered a bug. http://permalink.gmane.org/gmane.comp.gnu.octave.maintainers/25693 Thanks. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (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 libqhull-dev depends on: ii libqhull5 2009.1-3 libqhull-dev recommends no packages. libqhull-dev 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#729077: libgl1-mesa-dri: opengl broken due to implicit dependency
Package: libgl1-mesa-dri Version: 9.2.2-1 Severity: important Dear Maintainer, After upgrading from 8.0.5-6 to 9.2.2-1, opengl now fails to work, with glxgears emitting the message: Gen6+ requires Kernel 3.6 or later. glxgears: ../../../../../src/mesa/main/context.c:1501: _mesa_make_current: Assertion `newCtx->Version > 0' failed. perhaps libmesa1-??? should depend on some linux image >= 3.6, if it is required for 3D support? Thanks. -- Package-specific info: glxinfo: name of display: :0.0 X server symlink status: lrwxrwxrwx 1 root root 13 Oct 12 2012 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2044664 Apr 17 2013 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 324 Oct 14 2012 00-compose-key KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-15) ) #1 SMP Debian 3.2.41-2 Xorg X server log files on system: -- -rw-r--r-- 1 root root 34661 Nov 8 20:01 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [41.454] X.Org X Server 1.12.4 Release Date: 2012-08-27 [41.455] X Protocol Version 11, Revision 0 [41.455] Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian [41.455] Current Operating System: Linux minipc 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 [41.455] Kernel command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/minipc-root ro quiet libata.force=noncq [41.455] Build Date: 17 April 2013 10:22:47AM [41.455] xorg-server 2:1.12.4-6 (Julien Cristau ) [41.455] Current version of pixman: 0.30.2 [41.455]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [41.455] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [41.455] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Nov 8 20:00:40 2013 [41.549] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [41.569] (==) No Layout section. Using the first Screen section. [41.569] (==) No screen section available. Using defaults. [41.569] (**) |-->Screen "Default Screen Section" (0) [41.569] (**) | |-->Monitor "" [41.569] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [41.569] (==) Automatically adding devices [41.569] (==) Automatically enabling devices [41.628] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [41.628]Entry deleted from font path. [41.679] (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. [41.679]Entry deleted from font path. [41.679] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [41.679] (==) ModulePath set to "/usr/lib/xorg/modules" [41.679] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [41.679] (II) Loader magic: 0x7f8d34a90ae0 [41.679] (II) Module ABI versions: [41.679]X.Org ANSI C Emulation: 0.4 [41.679]X.Org Video Driver: 12.1 [41.679]X.Org XInput driver : 16.0 [41.679]X.Org Server Extension : 6.0 [41.680] (--) PCI:*(0:0:2:0) 8086:0102:105b:0d7a rev 9, Mem @ 0xf780/4194304, 0xe000/268435456, I/O @ 0xf000/64 [41.680] (II) Open ACPI successful (/var/run/acpid.socket) [41.680] (II) LoadModule: "extmod" [41.717] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [41.777] (II) Module extmod: vendor="X.Org Foundation" [41.777]compiled for 1.12.4, module version = 1.0.0 [41.777]Module class: X.Org Server Extension [41.777]ABI class: X.Org Server Extension, version 6.0 [41.777] (II) Loading extension SELinux [41.777] (II) Loading extension MIT-SCREEN-SAVER [41.777] (II) Loading extension XFree86-VidModeExtension
Bug#730100: 3depict: autopkgtest fails: missing dependencies, and syntax error
Hi, Thanks for the bug report, and sorry for the trouble. I might not be able to totally solve this bug for the next few weeks. I am a little confused about some of these points, and I'll address each individually, so here goes: 1. >There is a syntax error line 26 > 26 $ TOP_LEVEL="" > > should be TOP_LEVEL="" Oops, fixed. [1] 2. > Line 42 if configure never ran then there is > no makefile and make clean fails I'm not clear about what DEP-8 wants here. DEP8 says "The currently defined Features are: no-build-needed The tests can run in an unbuilt tree." This seems to reverse the build onus, as compared to what you say. This sentence seems to imply that I have to use the no-build-needed feature if i want to have an unbuilt tree. Otherwise a fully built tree should be present - or am I misunderstanding? If you have some links to relevant discussion about this, I don't suppose you can post them here? Is this an ubuntu/debian difference? Either way, Ive added a check for the existence of a valid Makefile, which bypasses make clean as needed [1]. This doesn't solve the dependency issue however - i've also add the appropriate Depends. IMHO there is now duplication between control and the unit-tests control file :(. >Alternatively all the configure/make bits of tests/unittest could be >replaced >by the restriction "build-needed" in autopkgtest's control file. Unfortunately not. The build *must* occur during the unit test, as there are different configure flags which enable different code paths - hence the build at all. In the debian/rules compilation (ie the deb package binaries), all internal ASSERTions and TESTs are disabled with --disable-debug-checks. Disabling these run-time checks makes the program noticeably faster during many operations, and allows for more aggressive run-time checking in debug mode. Lastly, there are two versions of the code checked, single-threaded and openmp multithreaded versions. The unit tests currently check both, as either failing could be the result of an implementation error - in the .deb file only the openmp enabled version is present. 4. >And finally it seems the 3Depict -t needs a display to run Yes, a display server is currently required. Here it works, as I am running a display server. DEP8 doesn't seem to be clear on what a minimal environment provides. I only tested this with adt-virt-null on my local machine, and didn't even think about this. Unfortunately, whilst the tests themselves theoretically don't need a display, wx requires it, without some patching in program initialisation. I will work on this for the next upload. Just so you know (if you are filing en-masse?) unfortunately, your links 404/wont resolve (ubuntu-ci is not a valid hostname?) for me. but I think your description is more than adequate to identify the issues in this bug without a build log, so I don't specifically need it. [1] http://anonscm.debian.org/gitweb/?p=debian-science/packages/3depict.git;a=commitdiff;h=386f59a84c325e0f24047d1c4bf074cbe57ccc41 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730100: 3depict: autopkgtest fails: missing dependencies, and syntax error
Hi, Where are you reading this? This feature doesn't exist, just the inverse exists: "Restrictions: build-needed". This is the document I have been working off: http://dep.debian.net/deps/dep8/ So your test builds the .debs and then calls dpkg -i to install them? Please note that this isn't really what autopkgtest is about -- you are supposed to test the packages that are in the *distro*, and their installed version. No, it doesn't have anything to do with the debs. I was just trying to run the numerical tests that the program has builtin from somewhere, and was told this was the latest and greatest method. As the packager and upstream, I don't have the capability of writing a full GUI test harness to do this. I think it is probably easiest to remove autopkgtest. I'll revisit this when autopkgtest is a little more mature. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727768: gpx import fail
Hi, I'm not sure if I should open a separate bug report, but GPX files created from my GPS (igotu) via igotu2pgx fail to import, as they are XML 1.0. I feel this is related as it is similarly pytrainer failing to import GPX files from other sources. I tried hand-modifying the file so it would be accepted, but couldn't hit on the appropriate formula for making this work. Unfortunately this is a show-stopper bug for using pytrainer. To be useful, IMHO pytrainer needs to be more forgiving in attempting to do its best to interpret files, as there is no guarantee that the GPX files coming from physical devices are going to be valid. User's have little control over how files are formatted. Workarounds would be good too! Thanks. tmp.gpx Description: application/gpx
Bug#740553: libqhull: -dev package uninstallable
Package: libqhull6 Version: 2012.1-4 Severity: grave File: libqhull Justification: renders package unusable Dear Maintainer, -dev package appears to contain zero-byte files. Dpkg reports the following (Reading database ... 260712 files and directories currently installed.) Preparing to unpack libqhull-dev_2012.1-4_amd64.deb ... Unpacking libqhull-dev:amd64 (2012.1-4) ... dpkg: error processing archive libqhull-dev_2012.1-4_amd64.deb (--install): unable to open '/usr/include/libqhull/libqhull.h.dpkg-new': No such file or directory Errors were encountered while processing: libqhull-dev_2012.1-4_amd64.deb Attempting to force-all does nothing: LANG=C sudo dpkg --force-all -i libqhull-dev_2012.1-4_amd64.deb (Reading database ... 260712 files and directories currently installed.) Preparing to unpack libqhull-dev_2012.1-4_amd64.deb ... Unpacking libqhull-dev:amd64 (2012.1-4) ... dpkg: error processing archive libqhull-dev_2012.1-4_amd64.deb (--install): unable to install new version of `/usr/include/qhull/user.h': No such file or directory Errors were encountered while processing: libqhull-dev_2012.1-4_amd64.deb -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-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 Versions of packages libqhull6:amd64 depends on: ii libc6 2.17-97 ii multiarch-support 2.17-97 libqhull6:amd64 recommends no packages. libqhull6:amd64 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#745668: Really fixed?
+ layout2->addWidget(_enableUsageStatistics, 1, 0); It looks like it is still enabled by default? I might be wrong, as I am unfamiliar with QT's config file system. But its not clear what the default value is set to. As updates are handled by apt-get/aptitude, this should be disabled by default. There is no need to contact a remote server. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746192: wx3.0-examples: Assertion failure in wxPropGrid tests
Package: wx3.0-examples Version: 3.0.0-2 Severity: normal Dear Maintainer, The wxPropGrid sample fails to execute its unit tests, throwing an assertion failure during test execution. The backtrace is reprouced below, and appears to be related to, but distinct from wx bug 13447 [1]. To reproduce, unpack the propgrid sample, then "make", then run the sample. Under the "Try these!" menu, execute "run unit tests (fast)". The crash occurs (on my system) every time. ASSERT INFO: /usr/include/wx-3.0/wx/strvararg.h(451): assert "(argtype & (wxFormatStringSpecifier::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type BACKTRACE: [1] wxArgNormalizer::wxArgNormalizer(unsigned long, wxFormatString const*, unsigned int) [2] wxArgNormalizerWchar::wxArgNormalizerWchar(unsigned long, wxFormatString const*, unsigned int) [3] wxString wxString::Format(wxFormatString const&, unsigned long, wxCStrData) [4] FormMain::RunTests(bool, bool) [5] FormMain::OnMisc(wxCommandEvent&) [6] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const [7] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [8] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [9] wxEvtHandler::TryHereOnly(wxEvent&) [10] wxEvtHandler::ProcessEventLocally(wxEvent&) [11] wxEvtHandler::ProcessEvent(wxEvent&) [12] wxWindowBase::TryAfter(wxEvent&) [13] wxEvtHandler::SafelyProcessEvent(wxEvent&) [14] wxMenuBase::SendEvent(int, int) [15] g_closure_invoke Thanks! [1] http://trac.wxwidgets.org/ticket/13447 *** 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 lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (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 wx3.0-examples depends on no packages. wx3.0-examples recommends no packages. Versions of packages wx3.0-examples suggests: ii libwxgtk3.0-dev 3.0.0-2 pn wx3.0-doc -- 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#746552: kile: Consider not hardcoding Okular as PDF viewer
Package: kile Version: 4:2.1.3-2 Severity: wishlist Dear Maintainer, It would be great if Kile PDF viewing worked by default on non-KDE installs - particularly as KDE is not the default for testing. Currently, after install kile, in order to view a PDF generated by kile, one has to modify the PDF tool (settings->Conf. Kile->Tools->Build->ViewPDF->Command), or attempts to view the generated PDF fail with a message in the log area "failed to start". Several possible solutions jump to mind * exo-open * A KilePDF script to detect and launch available binaries Either of these would make Kile "work out of the box" as an editor under non-KDE installs! Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kile depends on: ii kde-runtime 4:4.11.3-1 ii konsole 4:4.11.3-1 ii libc6 2.18-4 ii libgcc1 1:4.8.2-16 ii libkdecore5 4:4.11.3-2 ii libkdeui5 4:4.11.3-2 ii libkfile4 4:4.11.3-2 ii libkhtml5 4:4.11.3-2 ii libkio5 4:4.11.3-2 ii libkjsapi4 4:4.11.3-2 ii libkparts4 4:4.11.3-2 ii libkrosscore4 4:4.11.3-2 ii libktexteditor4 4:4.11.3-2 ii libnepomuk4 4:4.11.3-2 ii libnepomukutils44:4.11.3-2 ii libphonon4 4:4.7.1-1 ii libqt4-dbus 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-network 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-script 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-svg 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-xml 4:4.8.5+git242-g0315971+dfsg-2 ii libqtcore4 4:4.8.5+git242-g0315971+dfsg-2 ii libqtgui4 4:4.8.5+git242-g0315971+dfsg-2 ii libsoprano4 2.9.4+dfsg-1 ii libstdc++6 4.8.2-16 ii texlive-latex-base 2013.20140408-1 Versions of packages kile recommends: ii dvipng 1.14-2 ii ghostscript 9.05~dfsg-8+b1 ii imagemagick 8:6.7.7.10+dfsg-1 ii psutils 1.17.dfsg-1 ii texlive 2013.20140408-1 Versions of packages kile suggests: ii aspell0.60.7~20110707-1 pn asymptote pn context pn dblatex ii ispell3.3.02-6 pn kbibtex pn kile-doc pn kile-l10n pn latex2html pn lilypond pn tex4ht pn texlive-doc-base pn texlive-xetex ii zip 3.0-8 -- 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#747211: scilab: Allow scilab gui to start without opengl
Package: scilab Version: 5.5.0-2 Severity: wishlist Dear Maintainer, Currently under testing, using virtualbox there are some problems with the vboxvideo driver, and thus full opengl support is difficult to access (software rendering only). This happens quite frequently on many systems, for various reasons. The module is installed, but cannot be used. https://www.virtualbox.org/ticket/12746 Thus it would be nice if scilab could start, and use opengl when only software rendering is available. I realise that this may be a complex reuquest, as this I am sure reaches deep into gluegen/jogl initialisation. For anyone searching, the following errors occur when launching scilab (scilab-bin, inside the do_scilex function). glxgears runs, but only with low framerates. libGL error: pci id for fd 4: 80ee:beef, driver (null) OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM. libGL error: core dri or dri2 extension not found libGL error: failed to load driver: vboxvideo I've attached a slightly redacted strace log. Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages scilab depends on: ii scilab-cli 5.5.0-2 ii scilab-full-bin 5.5.0-2 Versions of packages scilab recommends: ii scilab-doc 5.5.0-2 Versions of packages scilab suggests: pn scilab-doc-fr pn scilab-doc-ja pn scilab-doc-pt-br -- 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#751474: thunar: Thunar hangs if unable to cleanly terminate SFTP session
Package: thunar Version: 1.6.3-1 Severity: normal Dear Maintainer, Thunar will hang if an SFTP session is terminated uncleanly. The solution is to kill the SSH proces manually. To reproduce, connect to a remote server via SFTP. After successfully logging in, disable your network adaptor. Once done, now attempt to close the connection by pressing the eject symbol next to the SFTP "mount" icon. If you press the close icon on the window, then you are given the option to terminate Thunar, however this does not terminate the connection Thunar will hang until the SSH process is killed. Waiting several minutes doesn't seem to cause any timeout or user feedback to trigger. Expected behaviour is that thunar will offer to kill the SSH session after some time, and that in the interim, some information about an upcoming timemout will be displayed to the user. Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages thunar depends on: ii desktop-file-utils 0.22-1 ii exo-utils 0.10.2-3 ii libatk1.0-0 2.12.0-1 ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii libdbus-1-3 1.8.0-3 ii libdbus-glib-1-20.102-1 ii libexo-1-0 0.10.2-3 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-02.40.0-2 ii libgtk2.0-0 2.24.23-1 ii libgudev-1.0-0 204-8 ii libice6 2:1.0.8-2 ii libnotify4 0.7.6-2 ii libpango1.0-0 1.36.3-1 ii libsm6 2:1.2.1-2 ii libthunarx-2-0 1.6.3-1 ii libxfce4ui-1-0 4.10.0-5 ii libxfce4util6 4.10.1-1 ii libxfconf-0-2 4.10.0-2 ii shared-mime-info1.2-1 ii thunar-data 1.6.3-1 Versions of packages thunar recommends: ii dbus-x111.8.0-3 ii gvfs1.20.0-1+b1 ii libfontconfig1 2.11.0-2 ii libfreetype62.5.2-1 ii thunar-volman 0.8.0-4 ii tumbler 0.1.30-1 ii xdg-user-dirs 0.15-1 ii xfce4-panel 4.10.1-1 Versions of packages thunar suggests: ii thunar-archive-plugin 0.3.1-2 ii thunar-media-tags-plugin 0.2.1-1 -- 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#746609: possible patch
Hi, Thanks for the report. I was not able to exactly reproduce the problem that you describe. The startup tips show for myself, and then the program runs. This is true normally, in valgrind, and under gdb. However, I was able to reproduce the same symptoms, but with the autosave dialog. I have made a patch which fixes the die-on-autosave dialog problem for myself, and have similarly modified the startup tips as well. If you can confirm this fixes the startup problem for yourself (I've updated git [1]), then this would be great. Unless the transition is imminent, I will wait until the next upload to close this. [1] http://anonscm.debian.org/gitweb/?p=debian-science/packages/3depict.git;a=commit;h=1da7709cc8e3d0ecf03b72dd95e4e092a1a0eab1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697899: Fix committed
Hi, Thanks for the report. I did notice an ubuntu user said that the icon was broken under unity, but having no idea how unity works, and that the icon worked for me under XFCE I thought no more of it. The fix is now uploaded to the git repository, and I have sent a message to get a new upload done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690435: xfce4-utils: tighten dependencies for locking
Package: xfce4-utils Version: 4.8.3-2 Severity: minor Having done a fresh testing install of xfce, I installed xfce4-utils (i think via synaptic). Xscreensaver is not installed as it is only recommends, not requires, xflock4 does not work. sh -x xflock4 + pgrep xscreensaver + pgrep -f gnome-screensaver ++ which slock + test x '!=' x + xlock /usr/bin/xflock4: Zeile 29: xlock: Kommando nicht gefunden. + exit 0 Additionally, there is no xlock to be found via apt-file ? So it should not be being used as a fallback (bug 544857)? $ apt-file find xlock | grep bin fvwm: /usr/bin/fvwm-menu-xlock hylafax-server: /usr/sbin/faxlock lxsession: /usr/bin/lxlock $ I think it might be a good idea to require (Xscreensaver | gnome-screensaver ) rather than recommend, that way locking functionality works out of the box, rather than the user having to dig into a terminal to determine that xlock doesn't work, or even exist, and then having to read the shell script (or use tracing) to see that xscreensaver/gnome-screensaver is an option. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/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 xfce4-utils depends on: ii dpkg 1.16.8 Debian package management system ii exo-utils 0.3.107-1 Utility files for libexo ii libc6 2.13-35Embedded GNU C Library: Shared lib ii libdbus-1-3 1.6.8-1simple interprocess messaging syst ii libdbus-glib-1-2 0.100-1simple interprocess messaging syst ii libglib2.0-0 2.32.3-1 GLib library of C routines ii libgtk2.0-0 2.24.10-2 GTK+ graphical user interface libr ii libxfce4ui-1-04.8.1-1widget library for Xfce ii libxfce4util4 4.6.2-1Utility functions library for Xfce ii procps1:3.3.3-2 /proc file system utilities ii x11-xserver-utils 7.7~3 X server utilities ii xfce4-terminal [x-terminal-em 0.4.8-1+b1 Xfce terminal emulator ii xinit 1.3.2-1X server initialisation tool ii xterm [x-terminal-emulator] 261-1 X terminal emulator Versions of packages xfce4-utils recommends: ii dbus-x11 1.6.8-1simple interprocess messaging syst ii thunar1.2.3-4+b1 File Manager for Xfce pn xdg-user-dirs (no description available) ii xfce4-panel 4.8.6-4panel for Xfce4 desktop environmen ii xfwm4 4.8.3-2window manager of the Xfce project pn xinput (no description available) pn xscreensaver | xlockmore | xl (no description available) Versions of packages xfce4-utils suggests: ii xfce4-session 4.8.3-2+b1 Xfce4 Session Manager -- 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#656022: Segfault if ccache called from missing dir
Subject: ccache: Segfault if ccache called from missing dir Package: ccache Version: 3.1.6-1 Severity: normal Dear Maintainer, ccache -s crashes if called from a terminal whose cwd has been deleted. eg $mkdir a $cd a $ccache -s (this is fine) in another terminal: $ rmdir a switch to original terminal $ccache -s segfault. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ccache depends on: ii libc6 2.13-24 ii zlib1g 1:1.2.3.4.dfsg-3 ccache recommends no packages. Versions of packages ccache suggests: pn distcc -- 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#655862: fixed in git
This was caused by qhull/wxwidgets preprocessor conflict. I have fixed it in git by using push/pop preprocessor pragmas. However, I am waiting for an upload to happen. I'll ping debian-science again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658435: cross check changelog against bts for bug status
Package: lintian Severity: wishlist Version: 2.5.4 Hello, I recently made an error in a package I maintain, where I swapped two digits in the bug; i.e. instead of closing 123, I closed 213. Fortunately, the other bug was not affected as it was already closed. I have seen the error before on a mailing list (debian-science), and am thus suggesting that it could be possible for lintian to query the BTS to determine if the following two scenarios exist: 1) Bug exists if closing (Error if not exists) 2) Bug is not closed (Error if already closed) 3) Bug is owned by current package (warning?) Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704828: nsis: CWD taken from symlink target, not symlink itself
Package: nsis
Version: 2.46-7
Severity: normal
I have an nsis file that refers to files using relative referencing, eg
eg:
!insertmacro MUI_PAGE_LICENSE "COPYING"
However if I place my .nsi file outside of the base directory for my project
eg:
/home/user/project/folder/project.nsi
and use a symlink to link the project:
/home/user/project/project.nsi -> /home/user/project/folder/project.nsi
then makensis fails on the call open("COPYING",READ_ONLY), emitting:
LicenseData: open failed "COPYING"
If i replace the symlink with a copy of the file, then the script succeeds.
makensis should not attempt to obtain the working directory from the symlink or
its target, but should use the actual cwd.
-- System Information:
Debian Release: 6.0.6
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nsis depends on:
ii libc62.13-38 Embedded GNU C Library: Shared lib
ii libgcc1 1:4.7.2-5 GCC support library
ii libstdc++6 4.7.2-5 GNU Standard C++ Library v3
ii nsis-common 2.46-7 Nullsoft Scriptable Install System
ii zlib1g 1:1.2.7.dfsg-13 compression library - runtime
nsis recommends no packages.
Versions of packages nsis suggests:
pn mingw-w64 (no description available)
pn nsis-doc (no description available)
pn nsis-pluginapi (no description available)
ii wine 1.4.1-4Windows API implementation - stand
-- 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#704828: nsis: CWD taken from symlink target, not symlink itself
I've solved my problem, as you say the solution is not hard. But felt I should report the bug anyway as, I for one, found it surprising that a symlink is treated differently to a file. most other building systems don't do this. $ mkdir -p tmp/folder $ cd tmp/ $ echo "all:" > folder/Makefile $ echo " pwd" >> folder/Makefile $ ln -s folder/Makefile $ make pwd /home/user/Desktop/tmp If you want to close the bug as invalid, thats fine, as long as I'm clear that its a "would be nice" type scenario > - Original Message - > From: Thomas Gaugler > Sent: 04/07/13 07:19 PM > To: D Haley, 704...@bugs.debian.org > Subject: Re: Bug#704828: nsis: CWD taken from symlink target, not symlink > itself > > If you build your .nsi script in the /home/user/project folder then it > is going to fail as well. > > makensis follows symbolic links. So if you put your .nsi file in the > parent folder then you would need to adapt the file references to this > new base (/home/user/project). > > In your example this means the following adaption: > --- > !insertmacro MUI_PAGE_LICENSE "folder/COPYING" > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687491: concur
Apologies for the "me too", I concur that this does not work under XFCE. It may be specific to XFCE users who have subsequently installed gnome manually, and are missing a package, or service provided by gnome? Or users who may have installed --without-recommends (I often do this for gnome/KDE packages, as they are otherwise exceedingly large downloads). Alternatively, it could be a locale thing? I've tried with both LANG=C and de_DE.UTF-8 locales. If its really needed - I can post a video of it not working ;) $ apt-cache show dconf-tools nautilus Package: dconf-tools Source: d-conf Version: 0.16.0-1 Installed-Size: 1114 Maintainer: Debian GNOME Maintainers Architecture: amd64 Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.4), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.2.4), libdconf1 (>= 0.14.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.35.2), libgtk-3-0 (>= 3.3.16), libpango1.0-0 (>= 1.14.0), libxml2 (>= 2.7.4), dconf-gsettings-backend | gsettings-backend Pre-Depends: dpkg (>= 1.15.7.2) Conflicts: dconf Description-de: Einfaches Konfigurations-Speichersystem - Hilfsprogramme Dconf ist eine einfache Schlüssel-/Wert-Datenbank, die zur Speicherung der Einstellungen von Arbeitsumgebungen entwickelt wurde. . Dieses Paket enthält die Befehlszeilenwerkzeuge. Beachten Sie, dass DConf nicht mit dem alten Debian-Paket dconf in Verbindung steht. Homepage: http://live.gnome.org/dconf Description-md5: 1d5ca74b35414d275ff0579f00176c88 Tag: role::program, uitoolkit::gtk Section: utils Priority: optional Filename: pool/main/d/d-conf/dconf-tools_0.16.0-1_amd64.deb Size: 181792 MD5sum: 59f0e8f84b40333edbcd7469b084d6c2 SHA1: 817adc29d6c70a13ac0786692c60c97d8ce0ad23 SHA256: f3897128a0b97b2a3687847136b78c7c94dd4d4b27dedb6d68d19b6b2f7df91a Package: dconf-tools Source: d-conf Version: 0.12.1-3 Installed-Size: 300 Maintainer: Debian GNOME Maintainers Architecture: amd64 Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.4), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.2.4), libdconf0 (>= 0.5), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.31.18), libgtk-3-0 (>= 3.0.0), libpango1.0-0 (>= 1.14.0), libxml2 (>= 2.7.4), dconf-gsettings-backend | gsettings-backend Conflicts: dconf Description-de: Einfaches Konfigurations-Speichersystem - Hilfsprogramme Dconf ist eine einfache Schlüssel-/Wert-Datenbank, die zur Speicherung der Einstellungen von Arbeitsumgebungen entwickelt wurde. . Dieses Paket enthält die Befehlszeilenwerkzeuge. Beachten Sie, dass DConf nicht mit dem alten Debian-Paket dconf in Verbindung steht. Homepage: http://live.gnome.org/dconf Description-md5: 1d5ca74b35414d275ff0579f00176c88 Tag: role::program, uitoolkit::gtk Section: utils Priority: optional Filename: pool/main/d/d-conf/dconf-tools_0.12.1-3_amd64.deb Size: 74732 MD5sum: fbc97a679d8d25b7ff732c3138dce243 SHA1: 745645ad9598c5961cf33eef58889528badce0c1 SHA256: c7f96c192997a3001bed4528fe26faefa9072f37d65060df076af2aef31b57eb Package: nautilus Version: 3.8.0-1 Installed-Size: 4036 Maintainer: Josselin Mouette Architecture: amd64 Replaces: nautilus-sendto Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.7), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.10.0), libexempi3 (>= 2.2.0), libexif12, libgail-3-0 (>= 3.0.0), libgdk-pixbuf2.0-0 (>= 2.25.2), libglib2.0-0 (>= 2.35.9), libgnome-desktop-3-7 (>= 3.2.0), libgtk-3-0 (>= 3.7.10), libnautilus-extension1a (>= 2.91), libnotify4 (>= 0.7.0), libpango1.0-0 (>= 1.20.0), libselinux1 (>= 1.32), libx11-6, libxml2 (>= 2.7.4), nautilus-data (>= 3.8), nautilus-data (<< 3.9), shared-mime-info (>= 0.50), desktop-file-utils (>= 0.7), gvfs (>= 1.3.2), libglib2.0-data, gsettings-desktop-schemas (>= 3.7.90) Recommends: eject, librsvg2-common, gvfs-backends, gnome-icon-theme-symbolic, gnome-sushi Suggests: brasero (>= 2.26), eog, evince | pdf-viewer, totem | mp3-decoder, xdg-user-dirs, tracker Breaks: gnome-bluetooth (<< 3.0), gnome-session (<< 2.28), gnome-volume-manager (<< 2.24), nautilus-sendto-empathy (<< 3.0), rhythmbox (<< 0.12) Description-de: Dateimananger und grafische Benutzeroberfläche für GNOME Nautilus ist der offizielle Datei-Manager der GNOME-Benutzeroberfläche. Er erlaubt es Ihnen durch Verzeichnisse zu blättern, zeigt Ihnen eine Vorschau für Dateien an und öffnet die mit ihnen verknüpften Anwendungen. Er ist auch für die Symbolverwaltung der GNOME-Oberfläche verantwortlich. Nautilus arbeitet mit lokalen und entfernten Dateisystemen. . Einige Symbolsammlungen und Komponenten zum Anzeigen unterschiedlicher Arten von Dateien sind in anderen Paketen verfügbar. Homepage: http://www.gnome.org/projects/nautilus/ Description-md5: 007268d365c98355ef914766c16ee43f Tag: implemented-in::c, interface::x11, role::program, scope::utility, suite::gnome, uitoolkit::gtk, use::browsing, use::organizing, works-with::file, x11::application Section: gnome Priority: optional Filename: pool/main/n/nautilus/nautilus_3.8.0-1_amd64.deb Size: 3009260 MD5sum: d1c1250add
Bug#589254: Debian packaging
retitle 589254 ITP: mapcatcher -- offline map viewer owner 589254 ! thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589254: Info received (Debian packaging)
Hi, I've uploaded a near-"legal-clean" version of a mapcatcher debian package here: https://gitorious.org/debian-mapcatcher/debian-mapcatcher The only thing to be done from a legal perspective is to confirm that we can use "openanything.py", which uses the "python" licence. Unfortunately, from a user perspective, much functionality is removed. All commercial map providers have been removed (OpenTransportMap has been added) and, more importantly, due to the original code being in probable violation of google's Terms of Service, place searching (which was done via google maps API) has been removed. If someone is able to convert this to use geoNames (I've never tried this, so I don't know what to do), that would be great. Does anyone have any input here? I would welcome some suggestions on package improvements, as I am not a python, nor python packaging guru. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703935: g++-mingw-w64-x86-64: stringstream has different results when using -D_GLIBCXX_DEBUG
Package: g++-mingw-w64-x86-64
Version: 4.6.3-14+8
Severity: normal
x86_64-w64-mingw32-g++ has differing behaviour for stringstream, depending upon
if -D_GLIBCXX_DEBUG is given or not.
builder@builder:~/mingw-debian-cross/code/tmp$ x86_64-w64-mingw32-g++ test.cpp
-o test
builder@builder:~/mingw-debian-cross/code/tmp$ wine64 ./test
attempting to cast :-123 to string
worked
builder@builder:~/mingw-debian-cross/code/tmp$ x86_64-w64-mingw32-g++ test.cpp
-o test -D_GLIBCXX_DEBUG
builder@builder:~/mingw-debian-cross/code/tmp$ wine64 ./test
attempting to cast :-123 to string
failed.
builder@builder:~/mingw-debian-cross/code/tmp$ cat test.cpp
#include
#include
#include
using namespace std;
template bool stream_cast(T1 &result, const T2 &obj)
{
std::stringstream ss;
ss << obj;
ss >> result;
return ss.fail();
}
int main()
{
int i;
std::string s;
i=-123;
std::cerr << "attempting to cast :" << i << " to string" << std::endl;
bool didFail = stream_cast(s,i);
if(didFail)
cerr << "failed." << endl;
else
cerr << "worked" << endl;
}
-- System Information:
Debian Release: 6.0.6
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages g++-mingw-w64-x86-64 depends on:
ii gcc-mingw-w64-base 4.6.3-14+8 GNU Compiler Collection for MinGW-
ii gcc-mingw-w64-x86-64 4.6.3-14+8 GNU C compiler for MinGW-w64 targe
ii libc62.13-38 Embedded GNU C Library: Shared lib
ii libgmp10 2:5.0.5+dfsg-2 Multiprecision arithmetic library
ii libmpc2 0.9-4 multiple precision complex floatin
ii libmpfr4 3.1.0-5 multiple precision floating-point
ii libstdc++6-4.6-dev 4.6.3-14GNU Standard C++ Library v3 (devel
ii zlib1g 1:1.2.7.dfsg-13 compression library - runtime
g++-mingw-w64-x86-64 recommends no packages.
Versions of packages g++-mingw-w64-x86-64 suggests:
pn gcc-4.6-locales(no description available)
-- 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#589254: Progress update
The git repo now has commits that solve the previous issues. * Openanything.py is now removed by a patch, and has been replaced by urllib. * Geonames support has been added, so users will get (a somewhat not-so-great based upon random testing) search. OSM apparently has a better database, but I have no idea about hooking into this API. So the package should be 100% legally clean now. I've posted a package to debian mentors: https://mentors.debian.net/package/mapcatcher -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709234: xfce4-mixer: dependency problems fixed by installing
Package: xfce4-mixer Version: 4.8.0-3+b1 Severity: normal Dear Maintainer, When using xfce4-mixer with gstreamer0.10-alsa uninstalled, right clicking on the mixer icon in the xfce tray and then selecting the properties/settings menu item causes mixer to report that the sound card cannot be found. I see that other users have hit this issue : http://forums.debian.net/viewtopic.php?t=76834 It is indeed fixed (at least on my system) by explicitly installing gstreamer0.10-alsa, and restarting the xfce4-mixer applet. I think, but am unsure (due to my lack of knowledge about the dep resolver), that it is due to aptitude allowing any of the virtual package providers (gstreamer0.10-alsa, gstreamer0.10-plugins-bad, gstreamer0.10-plugins-good, gstreamer0.10-pulseaudio)? Perhaps a more strict dependency is required? Thanks. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (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 xfce4-mixer depends on: ii gstreamer0.10-alsa [gstreamer0.10-audiosink] 0.10.36-1.1 ii gstreamer0.10-plugins-bad [gstreamer0.10-audiosink] 0.10.23-7.1 ii gstreamer0.10-plugins-base 0.10.36-1.1 ii gstreamer0.10-plugins-good [gstreamer0.10-audiosink 0.10.31-3 ii gstreamer0.10-pulseaudio [gstreamer0.10-audiosink] 0.10.31-3+nmu1 ii libc62.13-38 ii libcairo21.12.2-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgstreamer-plugins-base0.10-0 0.10.36-1.1 ii libgstreamer0.10-0 0.10.36-1.2 ii libgtk2.0-0 2.24.10-2 ii libxfce4ui-1-0 4.8.1-1 ii libxfce4util44.8.2-1 ii libxfconf-0-24.8.1-1 ii xfce4-panel 4.8.6-4 xfce4-mixer recommends no packages. xfce4-mixer 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#709249: kdenlive fails to start - undefined symbol
Package: kdenlive Version: 0.9.6-2 Severity: important Dear Maintainer, Launching kdenlive on a system with libmlt*-0.8.0-4 causes kdenlive to immediately abort with: $ kdenlive kdenlive: symbol lookup error: kdenlive: undefined symbol: _ZNK3Mlt7Profile10colorspaceEv updating both libmlt5 and libmlt++3 to 0.8.8 fixes the problem. I assume that this is due to a soname bump being missed? Thanks! -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (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 kdenlive depends on: ii dpkg 1.16.10 ii ffmpeg6:0.8.6-1 ii kde-runtime 4:4.8.4-2 ii kdenlive-data 0.9.6-2 ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libgl1-mesa-glx [libgl1] 8.0.5-4 ii libglu1-mesa [libglu1]8.0.5-4 ii libkdecore5 4:4.8.4-4 ii libkdeui5 4:4.8.4-4 ii libkio5 4:4.8.4-4 ii libknewstuff3-4 4:4.8.4-4 ii libknotifyconfig4 4:4.8.4-4 ii libkrossui4 4:4.8.4-4 ii libmlt++3 0.8.0-4 ii libmlt5 0.8.8-2 ii libnepomuk4 4:4.8.4-4 ii libqjson0 0.7.1-7 ii libqt4-dbus 4:4.8.2+dfsg-11 ii libqt4-network4:4.8.2+dfsg-11 ii libqt4-opengl 4:4.8.2+dfsg-11 ii libqt4-script 4:4.8.2+dfsg-11 ii libqt4-svg4:4.8.2+dfsg-11 ii libqt4-xml4:4.8.2+dfsg-11 ii libqtcore44:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libsolid4 4:4.8.4-4 ii libsoprano4 2.7.6+dfsg.1-2wheezy1 ii libstdc++64.7.2-5 ii libx11-6 2:1.5.0-1 ii libxau6 1:1.0.7-1 ii libxdmcp6 1:1.1.1-1 ii libxext6 2:1.3.1-2 ii melt 0.8.0-4 Versions of packages kdenlive recommends: ii dvdauthor0.7.0-1.1+b2 ii dvgrab 3.5-2 ii frei0r-plugins 1.1.22git20091109-1.2 ii genisoimage 9:1.1.11-2 ii recordmydesktop 0.3.8.1+svn602-1+b1 ii swh-plugins 0.4.15+1-6 kdenlive 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#709547: RFS: mapcatcher/0.8.0.0-1 [put in ITP, ITA, RC, NMU if applicable]
Package: sponsorship-requests Severity: normal Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "mapcatcher", ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589254 Package name: mapcatcher Version : 0.8.0.0-1 Upstream Author : Helder Sepu URL : https://code.google.com/p/gmapcatcher/ License : GPL-3+ Section : web It builds those binary packages: mapcatcher - offline maps viewer. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mapcatcher Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mapcatcher/mapcatcher_0.8.0.0-1.dsc Note that a git repository is here https://gitorious.org/debian-mapcatcher. There are several relevant points for this package. - This is my first python package, and - I have had to make significant changes to remove non-free components from the package. Regards, D. Haley -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564533: Deb source package
Hello Paul, Have you uploaded this to mentors or provided a DSC somewhere? I am happy to have a brows through it -- I maintain one package in debian currently, so I am no expert, but I can run my eye over it if you have a link. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564533: Deb source package
OK, so here are my comments. Feel free to ignore whatever you like, as I am
often not right.
* Lintian is giving native package errors. If you do a quick source build with
debuild (debuild -S -i -I), this will tell you what your tarball should be
called, so as to aid navigating this annoying notation.
:~/Documents/deb/shedskin/shedskin-0.3$ debuild -S -i -I
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
(expected one of shedskin_0.3.orig.tar.gz, shedskin_0.3.orig.tar.bz2,
shedskin_0.3.orig.tar.lzma or shedskin-0.3.orig)
continue anyway? (y/n) n
* I got a warning whilst building source package.. Are you seeing this?
dpkg-source: warning: diff
`~/Documents/deb/shedskin/shedskin_0.3-2.diff.gz.new.Haj083' doesn't contain
any patch
*The permissions from the DSC are a bit odd? Everything in debian/ seems to be
755? should it not be 644 (except rules I think)?
* Shouldn't the description be wrapped at 80 chars in debian/control, with each
new line preceded by a space?
*In debian/copyright, there are some chars that are not showing properly:
75 Copyright (c) 2009 Jérémie Roquet
* Standards version is old school. Should be 3.8.4 (or maybe even later...)
* debina/changelog seems to contain program changes, rather than package
changes? changelog should be package only AFAIK. Any program changes should be
hopefully distributed by upstream
* adding a watchfile is good (debian/watch)
* You may have been alluding to this before, but does the GPL trump the AS-IS
free stuff, as you are building them together? Particularly section 5b
"
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
"
You may need to contact upstream and ask them to sort this out, once a correct
course of action has been identified.
* Keeping this on a VCS somewhere would be nice, makes it easy for other
packagers to pull down your package at some later date. This integrates neatly
with the debian PTS. to do this just set Vcs-Git/Vcs-Svn or whatever in
debian/control
*I get a warning whilst attempting to build the binary version.
dpkg-deb: warning: 'debian/shedskin/DEBIAN/control' contains user-defined field
'Python-Version'
*Make clean still appears to leave files behind (build-python-*,
debian/shedskin.1.gz, ...). I usually use a VCS to help me work out if I have
accidently not done a proper clean (do a commit, then see what changes before
and after clean using fakeroot make -f debian/rules clean ).
* Lintian outputs a good wad of errors and warnings:
N: Setting up lab in /tmp/YnJLKVJw7I ...
N: Processing 2 packages...
N:
N: Processing source package shedskin (version 0.3-2) ...
W: shedskin source: empty-debian-diff
N:
N:The Debian diff of this non-native package appears to be completely
N:empty. This usually indicates a mistake when generating the upstream
N:tarball, or it may mean that this was intended to be a native package
N:and was built non-native by mistake.
N:
N:If the Debian packaging is maintained in conjunction with upstream, this
N:may be intentional, but it's not recommended best practice. If the
N:software is only for Debian, it should be a native package; otherwise,
N:it's better to omit the debian directory from upstream releases and add
N:it in the Debian diff. Otherwise, it can cause problems for some package
N:updates in Debian (files can't be removed from the debian directory via
N:the diff, for example).
N:
N:Severity: normal, Certainty: possible
N:
W: shedskin source: debhelper-but-no-misc-depends shedskin
N:
N:The source package uses debhelper, but it does not include
N:${misc:Depends} in the given binary package's debian/control entry. Any
N:debhelper command may add dependencies to ${misc:Depends} that are
N:required for the work that it does, so recommended best practice is to
N:always add ${misc:Depends} to the dependencies of each binary package if
N:debhelper is in use.
N:
N:Refer to the debhelper(7) manual page for details.
N:
N:Severity: normal, Certainty: possible
N:
W: shedskin source: build-depends-on-python-dev-with-no-arch-any
N:
N:The given package appears to have a Python development package
N:(python-dev, python-all-dev or pythonX.Y-dev) listed in its
N:Build-Depends or Build-Depends-Indep fields, but only "Architecture:
N:all" packages are built by this source package. Python applications and
N:modules do not usually require those dev packages, so you should
N:consider removing them in favour of python, python-all or pythonX.Y.
N:
N:If you are building a Python extension instead, you should have
N:development packages listed in Build-Depends, but nor
Bug#640432: Acknowledgement (libqhull: Qhull requires __POWERPC__ to be defined to a value)
Just so that we are clear, I have to tip my at to the kind people over at debian-mentors who did most of the hard work -- I don't have a PPC arch system. --- On Mon, 9/5/11, Debian Bug Tracking System wrote: > From: Debian Bug Tracking System > Subject: Bug#640432: Acknowledgement (libqhull: Qhull requires __POWERPC__ to > be defined to a value) > To: "mycae" > Date: Monday, September 5, 2011, 10:45 AM > Thank you for filing a new Bug report > with Debian. > > This is an automatically generated reply to let you know > your message > has been received. > > Your message is being forwarded to the package maintainers > and other > interested parties for their attention; they will reply in > due course. > > As you requested using X-Debbugs-CC, your message was also > forwarded to > my...@yahoo.com > (after having been given a Bug report number, if it did not > have one). > > Your message has been sent to the package maintainer(s): > Debian Science Maintainers > > > If you wish to submit further information on this problem, > please > send it to 640...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org > unless you wish > to report a problem with the Bug-tracking system. > > -- > 640432: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640432 > Debian Bug Tracking System > Contact ow...@bugs.debian.org > with problems > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716788: hgsvn: get_svn_info shouldn't fail on stderr output
Package: hgsvn
Version: 0.1.8-1
Severity: normal
Tags: patch
Dear Maintainer,
When attempting to import a remote svn repo, when not using gnome's
keyring management , there is some debugging information printed
to stderr. It does not affect the program operation. hgimportsvn
fails with:
Passwort für »user«:
Traceback (most recent call last):
File "/usr/bin/hgimportsvn", line 9, in
load_entry_point('hgsvn==0.1.8', 'console_scripts',
'hgimportsvn')()
File "/usr/lib/pymodules/python2.7/hgsvn/run/hgimportsvn.py", line
67, in main
svn_info = get_svn_info(target_svn_url, options.svn_rev)
File "/usr/lib/pymodules/python2.7/hgsvn/svnclient.py", line 152,
in get_svn_info
fail_if_stderr=True)
File "/usr/lib/pymodules/python2.7/hgsvn/common.py", line 236, in
run_svn
args=args, bulk_args=bulk_args, fail_if_stderr=fail_if_stderr)
File "/usr/lib/pymodules/python2.7/hgsvn/common.py", line 169, in
run_command
return _run_raw_command(cmd, map(_transform_arg, args),
fail_if_stderr)
File "/usr/lib/pymodules/python2.7/hgsvn/common.py", line 142, in
_run_raw_command
% (pipe.returncode, cmd_string, err))
hgsvn.errors.ExternalCommandFailed: External program failed (return
code 0): svn 'info' '--xml' '
WARNING: gnome-keyring:: couldn't connect to:
/home/user/.cache/keyring-d9y87B/pkcs11: Datei oder Verzeichnis nicht gefunden
The return code is 0, indicating success. Please find with this report a
patch that converts the call to fail_if_stderr to False. With the change, and
occassionaly tapping enter (for unclear reasons), I was able to import with
gnome-keyring disabled.
However, when attempting to subsequently use hgpullsvn, I couldnt get it to
work without the keyring enabled.
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (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 hgsvn depends on:
ii mercurial 2.2.2-3
ii python2.7.3-4
ii python-pkg-resources 0.6.24-1
ii python-support1.0.15
ii subversion1.6.17dfsg-4+deb7u2
hgsvn recommends no packages.
hgsvn suggests no packages.
-- no debconf information
--- svnclient.py.orig 2013-07-12 21:07:13.0 +0200
+++ svnclient.py 2013-07-12 21:07:05.0 +0200
@@ -149,7 +149,7 @@
else:
args = []
xml_string = run_svn(svn_info_args + args + [svn_url_or_wc],
-fail_if_stderr=True)
+fail_if_stderr=False)
return parse_svn_info_xml(xml_string)
def svn_checkout(svn_url, checkout_dir, rev_number=None):
Bug#721261: Prefer SVG over PNG
Hi, Thanks for the patch. I've applied it to the git repository [1], and requested a new upload. The -doc filesize does indeed decrease markedly. [1] http://anonscm.debian.org/gitweb/?p=debian-science/packages/libstxxl1.git;a=commit;h=19f279fcb82d515f3052cffaabda8acbec1c4c1d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721261: Prefer SVG over PNG
Hi, just so we have numbers, the size before and after this change was: 1.3.1-4 : 2,587.1 kB and after: 1.3.1-5 : 1,614.4 kB so you can shave off a good chunk. In retrospect (and I'll do this on the next upload), there is no need to pack the .md5 files, so more could be saved here. Perhaps this is a job for Lintian? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725401: libapt-pkg4.12: Crash in pkgCache::DepIterator::IsIgnorable
Package: libapt-pkg4.12 Version: 0.9.9.4 Severity: important Dear Maintainer, Attempting to use aptitude or apt recently caused both programs to segfault during startup, (normal user, or root). GDB indicate sthe problem lies within the pkgCache handling. pkgCache::DepIterator::IsIgnorable(pkgCache::PrvIterator const&) const () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (gdb) bt #0 0x77af369c in pkgCache::DepIterator::IsIgnorable(pkgCache::PrvIterator const&) const () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 #1 0x77af7175 in pkgDepCache::CheckDep(pkgCache::DepIterator, int, pkgCache::PkgIterator&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 #2 0x77af7be8 in pkgDepCache::DependencyState(pkgCache::DepIterator&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 #3 0x77afff0b in pkgDepCache::Update(OpProgress*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 #4 0x77b0043e in pkgDepCache::Init(OpProgress*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 Examining with strace, I found that the program was crashing after opening the file /etc/apt/sources.list.d/autopkgtest.list. Removing this file prevented the crash. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (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 libapt-pkg4.12 depends on: ii libbz2-1.0 1.0.6-5 ii libc6 2.17-92 ii libgcc11:4.8.1-2 ii libstdc++6 4.8.1-2 ii multiarch-support 2.17-92 ii zlib1g 1:1.2.8.dfsg-1 libapt-pkg4.12 recommends no packages. libapt-pkg4.12 suggests no packages. -- no debconf information deb file:///tmp/tmp.OHeFkZC10D/binaries/ /
Bug#725904: mercurial-common: hg view tags only show last word in tag
Package: mercurial-common Version: 2.6.3-1 Severity: normal Dear Maintainer, The following sequence of commands can produce a bug whereby a tag, such as "release version" will instead only show "version" in the tag view. This appears to be a regression, as this previously worked in earlier versions of hg view. Here is a sesion reproducing the bug: $ hg init . $ hg commit -u "me" -m "commitMesg" $ echo "otherstuff" > file $ hg commit -u "me" -m "yacm" $ hg tag -r 1 -m "commit tag" "Some Tag Here" $ hg view Instead of "Some Tag Here", i simply see "Here" in the tree display. The contents of .hgtags appears to be correct, and so does the output from hg tags. I think *maybe* that it might be related to this change. Ive rarely used tcl.: http://www.selenic.com/pipermail/mercurial-devel/2013-March/049582.html Thanks. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (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 mercurial-common depends on: ii python 2.7.5-4 Versions of packages mercurial-common recommends: ii ca-certificates 20130610 ii mercurial2.6.3-1 Versions of packages mercurial-common suggests: pn python-mysqldb pn python-openssl pn python-pygments ii tk8.5 [wish] 8.5.14-2 -- 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#674779: Noted
I will look into this in the next few days. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#843594: ilmbase: Proprietary licence in halfExport.h
Source: ilmbase Version: 2.2.0-11 Severity: normal Dear Maintainer, It appears that in the current ilmbase package there is a small file that contains code with a proprietary licence. Specifically Half/halfExport.h contains the following: // Copyright (c) 2008 Lucasfilm Entertainment Company Ltd. // All rights reserved. Used under authorization. // This material contains the confidential and proprietary // information of Lucasfilm Entertainment Company and // may not be copied in whole or in part without the express // written permission of Lucasfilm Entertainment Company. // This copyright notice does not imply publication. Is it possible to replace this (tiny) file, or to confirm that this is a non-issue? Thanks! -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#674135: Interest
Hi, I'm using this indirectly in some work I'm doing. I might package this when I have some spare time. It is required for the octopus DFT solver: http://octopus-code.org/wiki/Main_Page If anyone else has some interest in this, please do let me know, such as to minimise overlap.
Bug#824226: openjdk-8-jre: ATK bridge causes segfault when loading JR
Package: openjdk-8-jre Version: 8u91-b14-2 Severity: normal Dear Maintainer, When attempting to launch Jabref after updating openjdk from ( i believe, based upon apt history) 7u91-2.6.3-1 to 8u91-b14-2, i found that the following segfault occured: ** (java:13536): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7fe243798a42, pid=13536, tid=140609524610816 # # JRE version: OpenJDK Runtime Environment (8.0_91-b14) (build 1.8.0_91-8u91-b14-2-b14) # Java VM: OpenJDK 64-Bit Server VM (25.91-b14 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libatk-bridge-2.0.so.0+0x10a42] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/username/hs_err_pid13536.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Aborted This appears to have been reported elsewhere in bug 798131 for freemind. , when following the suggestion to disable the ATK bridge line int /etc/java-8-openjdk/accessibility.properties , the program was able to run successfully. I am running XFCE, as per one commenter in 798131m, however ulike in that bug report, I have assitive technologies in XFCE enabled. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openjdk-8-jre depends on: ii libasound21.1.0-1 ii libatk-wrapper-java-jni 0.33.3-6+b1 ii libc6 2.22-7 ii libgif7 5.1.4-0.1 ii libgl1-mesa-glx [libgl1] 11.1.3-1 ii libgtk2.0-0 2.24.30-1.1 ii libjpeg62-turbo 1:1.4.2-2 ii libpng16-16 1.6.21-4 ii libpulse0 8.0-2+b2 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxinerama1 2:1.1.3-1+b1 ii libxrandr22:1.5.0-1 ii openjdk-8-jre-headless8u91-b14-2 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages openjdk-8-jre recommends: ii fonts-dejavu-extra 2.35-1 ii libgconf-2-43.2.6-3 ii libgnome-2-02.32.1-5 ii libgnomevfs2-0 1:2.24.4-6.1+b1 Versions of packages openjdk-8-jre suggests: pn icedtea-8-plugin -- no debconf information
Bug#793107: octave: Find-replace hang when using regex searches with $
Package: octave Version: 3.8.2-4 Severity: normal Dear Maintainer, Octave will hang (spin) when the following procedure is followed on my system (every time). 1) Launch octave GUI 2) create a new file in the editor window, eg by using the "script" button (top left) 3) in the editor tab, in an unnamed file, enter the following data 1, where is done by tapping enter on the keyboard. 4) Use find-replace (Ctrl+F) , and tick Regular Expressions, then Find "$", replace with "," (no quotations). * What was the outcome of this action? 5) Spin. * What outcome did you expect instead? 5) Replacing $ with , Thanks -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages octave depends on: ii default-jre-headless 2:1.7-52 ii libamd2.3.1 1:4.2.1-3 ii libarpack2 3.1.5-3 ii libatlas3-base [liblapack.so.3] 3.10.2-7 ii libblas3 [libblas.so.3] 1.2.20110419-10 ii libc62.19-18 ii libcamd2.3.1 1:4.2.1-3 ii libccolamd2.8.0 1:4.2.1-3 ii libcholmod2.1.2 1:4.2.1-3 ii libcolamd2.8.0 1:4.2.1-3 ii libcxsparse3.1.2 1:4.2.1-3 ii libfftw3-double3 3.3.4-2 ii libfftw3-single3 3.3.4-2 ii libfltk-gl1.31.3.2-6+b1 ii libfltk1.3 1.3.2-6+b1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3 ii libgcc1 1:5.1~rc1-1 ii libgl1-mesa-glx [libgl1] 10.3.2-1 ii libglpk364.55-1 ii libglu1-mesa [libglu1] 9.0.0-2 ii libgomp1 5.1~rc1-1 ii libgraphicsmagick++3 1.3.20-3+deb8u1 ii libgraphicsmagick3 1.3.20-3+deb8u1 ii liblapack3 [liblapack.so.3] 3.5.0-4 ii liboctave2 3.8.2-4 ii libqhull62012.1-5 ii libqrupdate1 1.1.2-1 ii libqscintilla2-112.8.4+dfsg-1 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libqtgui44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 ii libstdc++6 5.1~rc1-1 ii libumfpack5.6.2 1:4.2.1-3 ii libx11-6 2:1.6.2-3 ii octave-common3.8.2-4 ii texinfo 5.2.0.dfsg.1-6 Versions of packages octave recommends: ii gnuplot-x11 4.6.6-2 ii libatlas3-base 3.10.2-7 ii pstoedit3.62-2+b1 Versions of packages octave suggests: pn octave-doc pn octave-htmldoc pn octave-info -- 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#793107: More info
Sorry, my previous report did not contain enough information. To reproduce the spin "replace all" must be used. "replace" works fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754595: RFP: easymercurial -- Easy to use mercurial GUI
Package: wnpp Severity: wishlist * Package name: easymercurial Version : 1.3.0 Upstream Author : Chris Cannam , Jari Korhonen * URL : http://easyhg.org/ * License : GPL Programming Lang: Python Description : Easy to use mercurial GUI EasyMercurial is a simple user interface for the Mercurial distributed version control system. The program is designed for non-advanced users of distributed version control. I'm happy to put in a bit of effort in getting this Debian-ised, assuming there are no issues i have overlooked. I don't think I can provide stable maintenance, as I am not sufficiently python proficient - particularly . -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746609: Fwd: Re: 3depict: Please update to use wxwidgets3.0
Original Message Subject: Re: 3depict: Please update to use wxwidgets3.0 Date: Thu, 24 Jul 2014 23:18:55 +0100 From: D Haley To: Olly Betts Hi, No it has not been missed. I have been busy over the last few weekends with other non-debian things. I could have done it last week, but was decided to work on the upstream source as a priority (I am upstream). I don't fully understand the corect solution to the problem, as the program will compile against wx2.8 and wx3.0. I needed to do more work to check to see if I can libwxgtk2.8-dev | libwxgtk3.0-dev with these sources (later wx2.8 will be dropped, but not yet). If you are happy to NMU the change yourself, that would actually help. I was deferring it until I actually understood what I was doing, and kept putting it off. Cheers, and apologies for the delay. On 24/07/14 22:59, Olly Betts wrote: On Mon, Jun 16, 2014 at 11:49:42AM +0100, Olly Betts wrote: On Fri, Jun 13, 2014 at 07:06:05AM +, Debian Bug Tracking System wrote: 3depict (0.0.16-2) unstable; urgency=medium . * Add wx 3.0 startup patch (Closes: #746609) You've have indeed included such a patch, but you didn't update "Build-Depends" to use libwxgtk3.0-dev, so this bug isn't actually fixed: | Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), libgl1-mesa-dev | libgl-dev, libpng-dev | libpng15-dev, libqhull-dev, libwxgtk2.8-dev, libftgl-dev, libxml2-dev, libmgl-dev (>= 2.0), automake I'm happy to NMU if that helps. It's been over a month without a response - I'm wondering if my previous message got missed because I only sent it to the ticket? Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785657: RFA: opticalraytracer
Package: wnpp Severity: normal Dear Maintainers/Developers, I am intending to orphan opticalraytracer, as I no longer have the time to develop my java packaging skills, and do not use java in the natural course of my work. If anyone is interested in maintaining this package, please feel free to do so. I am aware that the package has a low popcon score, and thus will be unlikely to find a new maintainer, and so will attempt to perform any work required on this package when I can. This may take some time however. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764814: freecad downloads and executes code
Subject: freecad: Downloads and executes code
Package: freecad
Version: 0.14.3702+dfsg-2
Severity: important
Dear Maintainer,
As per discussions with the security team, I am marking the severity as
grave.
Freecad downloads and executes code (e.g. ArchCommands.py) from the
network, from https. This uses urllib2, which does not check https
certificates. The files that are downloaded occur when attempting to
activate non-present module features, such as via opening a DXF file.
Sample session console output:
DXF libraries not found. Downloading...
downloading
https://raw.github.com/yorikvanhavre/Draft-dxf-importer/master/dxfColorMap.py
...
downloading
https://raw.github.com/yorikvanhavre/Draft-dxf-importer/master/dxfImportObjects.py
...
downloading
https://raw.github.com/yorikvanhavre/Draft-dxf-importer/master/dxfLibrary.py
...
downloading
https://raw.github.com/yorikvanhavre/Draft-dxf-importer/master/dxfReader.py
...
I believe arbitrary code could be (theoretically) injected into these
downloads, then executed. I am not an expert in such matters, and have
not attempted to do so, so please review this for actual vulnerability
(I may be wrong, and this could be mitigated in some other way).
I would hazard that this vulnerability would be minor, due to the
low-ish user base of freecad who are opening dxf files on untrusted
networks.
The file in question i believe to be :
freecad-0.14.3702+dfsg/src/Mod/Arch/ArchCommands.py
I further note that urllib is referenced in the following files:
$ find ./ -type f -name \* -exec grep -H "urllib" {} \; | grep urlopen
./Tools/wiki2qhelp.py:from urllib2 import urlopen, HTTPError
./Tools/generateBase/generateDS.py:implFile =
urllib2.urlopen(implUrl)
./Tools/generateBase/generateDS.py:##implFile =
urllib2.urlopen(implUrl)
./Mod/Arch/ArchCommands.py:response = urllib2.urlopen(url)
./Mod/Start/StartPage/StartPage.py:xml =
parse(urllib.urlopen(url)).getroot()
Looking at generateDS.py, this may also be affected. I do not believe
StartPage.py affected in the scope of this bug.
Thanks!
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages freecad depends on:
ii libboost-filesystem1.55.0 1.55.0+dfsg-2
ii libboost-program-options1.55.0 1.55.0+dfsg-3
ii libboost-regex1.55.01.55.0+dfsg-2
ii libboost-signals1.55.0 1.55.0+dfsg-3
ii libboost-system1.55.0 1.55.0+dfsg-2
ii libboost-thread1.55.0 1.55.0+dfsg-2
ii libc6 2.19-7
ii libcoin80 3.1.4~abc9f50-7
ii libfreeimage3 3.15.4-3+b2
ii libfreetype62.5.2-1
ii libgcc1 1:4.9.0-7
ii libgfortran34.9.0-7
ii libgl1-mesa-glx [libgl1]10.2.4-1
ii libglu1-mesa [libglu1] 9.0.0-2
ii libice6 2:1.0.9-1
ii liboce-foundation8 0.15-4
ii liboce-modeling80.15-4
ii liboce-ocaf-lite8 0.15-4
ii liboce-ocaf80.15-4
ii liboce-visualization8 0.15-4
ii libpyside1.21.2.2-1+b1
ii libpython2.72.7.8-3
ii libqt4-network 4:4.8.6+git49-gbc62005+dfsg-1
ii libqt4-opengl 4:4.8.6+git49-gbc62005+dfsg-1
ii libqt4-svg 4:4.8.6+git49-gbc62005+dfsg-1
ii libqt4-xml 4:4.8.6+git49-gbc62005+dfsg-1
ii libqt4-xmlpatterns 4:4.8.6+git49-gbc62005+dfsg-1
ii libqtcore4 4:4.8.6+git49-gbc62005+dfsg-1
ii libqtgui4 4:4.8.6+git49-gbc62005+dfsg-1
ii libqtwebkit42.2.1-7
ii libquadmath04.9.0-7
ii libshiboken1.2 1.2.2-1+b1
ii libsm6 2:1.2.2-1
ii libsoqt4-20 1.6.0~e8310f-1
ii libspnav0 0.2.2-1
ii libstdc++6 4.9.0-7
ii libx11-62:1.6.2-2
ii libxerces-c3.1 3.1.1-5
ii libxext62:1.3.2-1
ii libzipios++0c2a 0.1.5.9+cvs.2007.04.28-5.1
ii python-collada 0.4-2
ii python-matplotlib 1.3.1-2
ii python-pivy 0.5.0~v609hg-3
ii python-ply 3.4-3
ii python-pyside 1.2.2-1
ii python2.7 2.7.8-3
pn python:any
ii zlib1g 1:1.2.8.dfsg-1
freecad recommends no packages.
Versions of packages freecad suggests:
pn freecad-doc
-- no debconf information
--
To UNSUBSCRIBE, ema
Bug#791173: libstxxl: library transition may be needed when GCC 5 is the default
Hi All, Apologies for being late to fix this bug. I had previously looked into it and from the above instructions, I had seen the bump was needed, but have only just had the time to work on this. I have contacted upstream to see which of the two options they would prefer. My preference is for a soname bump, but this risks being out of sync with upstream. I don’t think that is a major problem, as we can fix that on a future stxxl release, but if someone is willing to correct me here, let me know. Hopefully I will get a response, and should be able to tackle this next weekend. Thanks.
Bug#800460: mathgl: Test program fails to build, syntax error in header
Package: mathgl
Version: 2.3.3-2
Severity: normal
Hi All,
A bit of a note-to-self (and Dimitrios, I guess). This report is due to some
notice on the mathgl mailing list:
https://groups.google.com/forum/?_escaped_fragment_=topic/mathgl/ioV2hTVfhq4#!topic/mathgl/ioV2hTVfhq4
The following program does not compile:
#include
int main()
{
mglGraph gr;
gr.FPlot("sin(pi*x)");
gr.WriteFrame("test.png");
}
$g++ --version
g++ (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ mathgl.cpp -o mathgl -lmgl -std=c++11
In file included from /usr/include/c++/4.9/complex.h:36:0,
from /usr/include/mgl2/define.h:268,
from /usr/include/mgl2/abstract.h:23,
from /usr/include/mgl2/data_cf.h:23,
from /usr/include/mgl2/data.h:23,
from /usr/include/mgl2/mgl_cf.h:24,
from /usr/include/mgl2/mgl.h:23,
from mathgl.cpp:1:
/usr/include/mgl2/define.h:277:19: error: unable to find numeric literal
operator ‘operator""iF’
const mdual mgl_I=_Complex_I;
^
/usr/include/mgl2/define.h:277:19: note: use -std=gnu++11 or
-fext-numeric-literals to enable more built-in suffixes
In file included from /usr/include/mgl2/abstract.h:23:0,
from /usr/include/mgl2/data_cf.h:23,
from /usr/include/mgl2/data.h:23,
from /usr/include/mgl2/mgl_cf.h:24,
from /usr/include/mgl2/mgl.h:23,
from mathgl.cpp:1:
/usr/include/mgl2/data.h: In member function ‘void mglDataV::Fill(mreal, mreal,
char)’:
/usr/include/mgl2/data.h:611:6: error: ‘typeof’ was not declared in this scope
if(mgl_isnum(x2))
^
/usr/include/mgl2/data.h:611:6: error: ‘_a’ was not declared in this scope
if(mgl_isnum(x2))
^
/usr/include/mgl2/data.h:611:6: error: could not convert ‘({...})’ from ‘void’
to ‘bool’
if(mgl_isnum(x2))
^
.
And so on for quite a while. It looks like there are some typing problems in
the headers. We should have a unit test to fix this. It renders the package
relatively unusable.
This may or may not be the cause of bug #798858
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798858
Thanks!
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages mathgl depends on:
ii libc6 2.19-18
ii libgcc1 1:5.2.1-17
ii libgif4 4.1.6-11
ii libgl1-mesa-glx [libgl1] 10.3.2-1
ii libglu1-mesa [libglu1]9.0.0-2
ii libgsl0ldbl 1.16+dfsg-2
ii libhdf4-0 4.2.10-3
ii libhdf5-8 1.8.13+docs-15
ii libhpdf-2.2.1 2.2.1-1.1
ii libjpeg62-turbo 1:1.3.1-12
ii libltdl7 2.4.2-1.11
ii libmgl-qt7.4.02.3.3-2
ii libmgl7.4.0 2.3.3-2
ii libpng12-01.2.50-2+b2
ii libqt5core5a 5.4.2+dfsg-5
ii libqt5gui55.4.2+dfsg-5
ii libqt5printsupport5 5.4.2+dfsg-9
ii libqt5widgets55.4.2+dfsg-5
ii libstdc++65.2.1-17
ii zlib1g1:1.2.8.dfsg-2+b1
mathgl recommends no packages.
mathgl suggests no packages.
-- no debconf information
Bug#798858: Ref: FTBFS against mathgl 2.3.3
Hi, Thanks for the report. A quick glance suggests this may be related to a bug in mathgl (800460) . https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800460 I co-maintain mathgl, so I'll look at this on the weekend, when I have some time.
Bug#764814: freecad downloads and executes code
Hi, and thanks for the quick response. I was unaware of the licensing issue - I don't really have an opinion on the licencing problem, but more the technical issue of unsigned code execution. Whilst you/upstream control the resource, freecad doesn't confirm that the download actually comes from said resource - python will not check this. An attacker can intercept the https initial handshake and impersonate the resource, as no signatures are checked. This is not hard if they control the network (eg public wifi/fake access point). I think there are several possible solutions, in varying orders of difficulty: * Hard-code a given .py git identifier, then check the downloads SHA1 or SHA1 _and_ MD5 after the download. Hard-code the matching SHA1 in the freecad sources. Convert the url stream into a binary stream and pass it to python's SHA1 module, then check the result. The downside is of course, this is not upgradeable. * Implement certificate checking in the freecad source, by locating and finding the debian certificates, parsing them and checking the provider's validity (pretty hard? I'm no python guru, but I understand the next python release will include certificate validation). Upgrades remain, but more complex. Slightly less serious suggestions : * Change freecad to use a different dxf backend (eg librecad's internal (BSD)) * Chance licence ;) Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764814: freecad downloads and executes code
Hi and thanks for the input,
I think this bug is less about licencing, which is a large and complex
issue, than a quick fix for code execution. Upstream can make their
decisions about licencing. This is possibly not a debian question, and i
feel somewhat tangential to this bug, and the issues in the other bug
are still not entirely sorted. We have a technical solution that will
work here.
I think I disagree about the complexity of the SHA1 solution. I think it
is very simple, and looks like the attached, which is incomplete.
Notably, the other files need to be similarly patched, and the SHA1s
need computing.
Otherwise, the SSL solution could be achieved by using eg, the Requests
library. Some discussion on this topic was had a while ago:
https://lwn.net/Articles/582065/
Thanks!
diff -r 58946a488476 src/Mod/Arch/ArchCommands.py
--- a/src/Mod/Arch/ArchCommands.py Sun Oct 12 15:44:26 2014 +0100
+++ b/src/Mod/Arch/ArchCommands.py Sun Oct 12 15:49:30 2014 +0100
@@ -24,6 +24,8 @@
#***
import FreeCAD,Draft,ArchComponent,DraftVecUtils
+import hashlib
+
from FreeCAD import Vector
if FreeCAD.GuiUp:
import FreeCADGui
@@ -562,6 +564,13 @@
FreeCAD.Console.PrintMessage("downloading "+url+" ...\n")
response = urllib2.urlopen(url)
s = response.read()
+ sha = hashlib.sha1(s)
+ sha_found = sha.hexdigest()
+
+ SHA1_EXPECTED_HEX="asdf"
+ if not sha_found = SHA1_EXPECTED :
+ return None
+
f = open(filepath,'wb')
f.write(s)
f.close()
Bug#798858: blocked
Hi, I claim that this bug is blocked by mathgl, as mathgl has enabled c++11 support. I'm not a maintainer on that package anymore. Mathgl's C++11 support has been re-enabled in HEAD after closing 800460 by disabling C++11 support [1] (ie the fix is now reverted in head) . I've contacted the maintainer, should I wait for a response or ask for an NMU? Thanks [1] https://anonscm.debian.org/gitweb/?p=debian-science/packages/mathgl.git;a=commit;h=b10b6b515c426087120d3707997bf57a0807be81
Bug#800460: Ping
Hi Dimitrios, It looks like there is still a problem with the latest git head. It seems that there may have been a mishap with the patching, and the patch has been reversed at some point? I can see in b7027842 that the C++11 has been set back to ON in the CMakeLists file. I personally keep a debian/source/local-options file like so, to enforce patches-unapplied in my other repository: https://anonscm.debian.org/cgit/debian-science/packages/3depict.git/tree/debian/source/local-options?id=7fc15a0ad61ab38f0c1e4c1b2085dadf212d693c Last time I checked this was the recommended thing to do, as quilt + gbp dont play nicely together. I'm not totally clear what is going on here, but removing the .pc directory and going back to a patches-unapplied git seems to fix the problem for me. I dont want to push any changes until we agree on what both the cause of the problem and what the solution is. Thanks!
Bug#800460: Ping
Hi Dmitirios, Thanks for the quick response. My current opinion is that we should lock-step with the C++11 transition in Debian, which occurs with gcc6. https://wiki.debian.org/GCC5#Prepare_for_GCC_6 Otherwise, we are simply risking bugs like 798858, 800460 and 80953, as C++11 is not the Debian default at this time. On 21/01/16 12:00, Dimitrios Eftaxiopoulos wrote: > Hello Dave, > > > Στις Wednesday 20 of January 2016 18:18:28 γράψατε: >> Hi Dimitrios, >> >> >> It looks like there is still a problem with the latest git head. It >> seems that there may have been a mishap with the patching, and the patch >> has been reversed at some point? I can see in b7027842 that the C++11 >> has been set back to ON in the CMakeLists file. > > I did that intentionally, thinking that problems have been solved and we > should apply as many features as we can. It seems that this is not the case. > So I will do a new upload with the C++11 features disablesd in the CMakeLists > file. > >> >> I personally keep a debian/source/local-options file like so, to enforce >> patches-unapplied in my other repository: >> >> https://anonscm.debian.org/cgit/debian-science/packages/3depict.git/tree/deb >> ian/source/local-options?id=7fc15a0ad61ab38f0c1e4c1b2085dadf212d693c >> >> Last time I checked this was the recommended thing to do, as quilt + gbp >> dont play nicely together. >> >> I'm not totally clear what is going on here, but removing the .pc >> directory and going back to a patches-unapplied git seems to fix the >> problem for me. > > I started keeping the .pc directory some time ago, because I noticed that the > deletion of it somehow reverted the effect of the patches. I do not see any > side eefects up to now. > >> >> I dont want to push any changes until we agree on what both the cause of >> the problem and what the solution is. >> >> >> Thanks! > > Best regards > Dimitris >
Bug#876059: ITP: libvd -- Volume Development library
Package: wnpp Severity: wishlist Owner: D Haley * Package name: libvd Version : 1.1.0+svn7 Upstream Author : Herve Lombaert * URL : http://cim.mcgill.ca/~lombaert/libvd-doc/ * License : GPL Programming Lang: C++ Description : Volume Development library A small opengl C++ library for 3D and 4D volume rendering. This is implemented using 3D textures and fragment shaders. The library is relatively simple compared to major frameworks, and is aimed at both learners, and those who wish to integrate this functionality into their own projects. This will be an optional dependence for the upcoming 3Depict 0.0.21 release. This is being maintained as a member of the debian-science team
Bug#876059: ITP: libvd -- Volume Development library
A repository has now been created on alioth: https://anonscm.debian.org/git/debian-science/packages/libvd.git Some lintian errors remain (around triggers).
Bug#876363: octave fetches network resources when network access disabled
Package: octave Version: 4.0.3-3 Severity: minor Dear Maintainer, I was having some network troubles recently, and I was using octave. A short time after launching the program (octave --force, I was greeted with "Octave's community news source seems to be unavailable. For the latest news, please check http://octave.org/community-news.html when you have a connection to the web (link opens in an external browser)." I was a little concerned at this message, as in the settings, the option "Allow Octave to connect to the Octave web site to display current news and information" is unchecked. So it seems that this may not be being honoured? I can't see how octave would know that my network was down (at the router level) without performing a URL request. I admit I have not attempted to locate the code responsible for this, so apologies if there is a mistake on my part. Thanks. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages octave depends on: ii libamd2 1:4.5.4-1 ii libarpack2 3.4.0-1+b1 ii libasound2 1.1.3-5 ii libatlas3-base [liblapack.so.3] 3.10.3-1+b1 ii libblas3 [libblas.so.3] 3.7.0-2 ii libc62.24-11+deb9u1 ii libcamd2 1:4.5.4-1 ii libccolamd2 1:4.5.4-1 ii libcholmod3 1:4.5.4-1 ii libcolamd2 1:4.5.4-1 ii libcxsparse3 1:4.5.4-1 ii libfftw3-double3 3.3.5-3 ii libfftw3-single3 3.3.5-3 ii libfltk-gl1.31.3.4-4 ii libfltk1.3 1.3.4-4 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libglpk404.61-1 ii libglu1-mesa [libglu1] 9.0.0-2.1 ii libgomp1 6.3.0-18 ii liblapack3 [liblapack.so.3] 3.7.0-2 ii liboctave3v5 4.0.3-3 ii libosmesa6 13.0.6-1+b2 ii libportaudio219.6.0-1 ii libqhull72015.2-2 ii libqrupdate1 1.1.2-2 ii libqscintilla2-12v5 2.9.3+dfsg-4 ii libqt4-network 4:4.8.7+dfsg-11 ii libqt4-opengl4:4.8.7+dfsg-11 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui44:4.8.7+dfsg-11 ii libsndfile1 1.0.27-3 ii libstdc++6 6.3.0-18 ii libumfpack5 1:4.5.4-1 ii libx11-6 2:1.6.4-3 ii octave-common4.0.3-3 ii texinfo 6.3.0.dfsg.1-1+b2 Versions of packages octave recommends: ii default-jre-headless 2:1.8-58 ii gnuplot-x11 5.0.5+dfsg1-6+deb9u1 ii libatlas3-base3.10.3-1+b1 ii octave-info 4.0.3-3 ii pstoedit 3.70-3+b2 Versions of packages octave suggests: pn octave-doc pn octave-htmldoc -- no debconf information
Bug#876363: octave fetches network resources when network access disabled
Hello, Thanks for getting back so quickly. That command yields no output (no such line) - the file does however exist. $ grep allow_web_connection ~/.config/octave/qt-settings $ On 21/09/17 17:55, Mike Miller wrote: > On Thu, Sep 21, 2017 at 11:50:24 +0100, D Haley wrote: >> I was a little concerned at this message, as in the settings, the option >> "Allow Octave to connect to the Octave web site to display current news >> and information" is unchecked. > > This is troubling, thanks for reporting it. > > I have looked at the code, and the only way the message you quoted can > appear is indeed if Octave has attempted a web request, either > automatically at startup, or when the menu item under the News menu. > > Can you verify that the option is actually disabled? What does > > grep allow_web_connection ~/.config/octave/qt-settings > > yield? >
Bug#876363: octave fetches network resources when network access disabled
Hi, It looks like the QT UI does not match what happens internally in Octave if the line is absent from the file. If the line "allow_web_connection=true" is present, then the web connection proceeds, and the network tab in settings reflects the setting. If the line "allow_web_connection=false" is present, then the web connection does not occur, and the network tab in settings reflects the setting. However, if the line is entirely absent, then the connection is established, however *the UI does not show this*. The item in the menu for the network connection is unchecked. Here is the testing I performed: $ pwd /home/pcuser/.config/octave $ ls -l qt-settings -rw-r--r-- 1 pcuser pcuser 5507 Sep 21 13:52 qt-settings $ mv qt-settings qt-settings.bak $ ps augxw | grep -i [o]ctave $ octave --force-gui $ grep allow_web_connection ~/.config/octave/qt-settings allow_web_connection=false $ octave --force-gui $ sed -i 's/allow_web_connection=false/allow_web_connection=true/' qt-settings $octave --force-gui $ sed -i 's/allow_web_connection=true//' qt-settings
Bug#876363: octave fetches network resources when network access disabled
P.S. I assume the reason for the line not being present is that it was not written to the file in an earlier version, and I have upgraded to a later version which only writes the line when re-creating the file from scratch. On 21/09/17 18:04, Mike Miller wrote: > On Thu, Sep 21, 2017 at 17:58:04 +0100, D Haley wrote: >> Thanks for getting back so quickly. That command yields no output (no >> such line) - the file does however exist. >> >> $ grep allow_web_connection ~/.config/octave/qt-settings >> $ > > Ok. That indicates that the setting is not actually being saved. It's > possible that Octave is not able to save its settings at all. Can you > check the file permissions and ownership? If you delete the file or move > it out of the way does it work as expected? >
Bug#876363: octave fetches network resources when network access disabled
Thanks for keeping tabs here, I've been using --force-gui for some time now, before it was the default. May or may not be a useful tidbit. > Is it possible the qt-settings file is created by something other than > Octave on your system? I've only been using the current debian packages, and nothing special, so no, I don't think there is any other software altering this file. I've certainly not been playing with it, and this is a single-user system. > Do you think there is any remaining issue here, or do you consider this > resolved by fixing the configuration file on your end? > > Or is the only issue here that the settings dialog implies that the > missing value defaults to 'false', while the actual behavior is to > interpret a missing value as 'true'? I don't think it is resolved - other people could have the same issue and not realise. I think there are two points, the first is more important than the second: 1) The GUI should be clear as to what setting the backend is currently using. I think it is a concern that there are two settings that have the capacity to be "out-of-sync". 2) From a debian user's/policy perspective, I think the GUI should default to not using a network connection for an application where this might be surprising to an end user. Either querying the user again, or defaulting to false would be best Thanks! On 21.09.2017 22:56, Mike Miller wrote: > Is it possible the qt-settings file is created by something other than > Octave on your system?
Bug#869382: libwxgtk3.0-0: Drawing sample line test broken
Package: libwxgtk3.0-0v5 Version: 3.0.2+dfsg-4 Severity: normal File: libwxgtk3.0-0 Dear Maintainer, I was trying to use lines in my application which uses wxGTK. I've found that in the drawing sample shipped with wxGTK, the lines screen doesn't seem to give the correct visual output. In the "Testing lines of width 0", the "dot/short dash/long dash/dot dash" lines appear visually identical. The same is true for the width 1 test. In the width 2 testh however, the lines start ot be visually distinct. It looks like the mapping between wxGTK and the gtk drawing code doesn't quite tee up. To reproduce this install the wx3.0-examples package, navigate to /usr/share/doc/wx3.0-examples/examples/samples, then copy out the drawing example to somewhere writeable, eg ~/tmp/wx/drawing. You need to copy sample.xpm as well, into the immediate parent path (eg ~/tmp/wx/). Then go into ~/tmp/wx/drawing/, and execute make to build the example. Now launch the example (./drawing), then in the file menu, select "Lines screen". Observe the incorrectly drawn lines. I'm unsure if this is an upstream bug or not. Thanks! -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libwxgtk3.0-0v5:amd64 depends on: ii libc6 2.24-11 ii libcairo2 1.14.8-1 ii libgcc1 1:6.3.0-18 ii libgdk-pixbuf2.0-02.36.5-2 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libjpeg62-turbo 1:1.5.1-2 ii libnotify40.7.7-2 ii libpango-1.0-01.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpng16-16 1.6.28-1 ii libsm62:1.2.2-1+b3 ii libstdc++66.3.0-18 ii libtiff5 4.0.8-2 ii libwxbase3.0-0v5 3.0.2+dfsg-4 ii libx11-6 2:1.6.4-3 ii libxxf86vm1 1:1.1.4-1+b2 libwxgtk3.0-0v5:amd64 recommends no packages. libwxgtk3.0-0v5:amd64 suggests no packages. -- no debconf information
Bug#832749: kile: Freeze on close project when using virtualbox mounts
Package: kile Version: 4:2.1.3-4 Severity: normal Dear Maintainer, I am using Debian inside a virtualbox session with a windows host. When working on kile projects who are in the virtualbox shared folders, which are mounted at (say) /media/vbox_share/, any project within /media/vbox_share/ will hang when attempting to close (and thus save) the project. This results in a modest data loss, as any information in the project is not saved. The only way I have found to resolve the hang is to terminate the process. This does not occur when saving within the user's home folder. To reproduce (in virtualbox): - Create a new project. - Set the project's folder as some sub-folder of a virtualbox shared folder. (windows host required?) - Close the project - Hang. I do not have problems with other programs accessing files for write. The resulant backtrace looks like the below - perhaps KLockFile is at fault?: (gdb) info threads Id Target Id Frame * 1Thread 0x7ffe6e585900 (LWP 1474) "kile" 0x7ffe6a3b3f73 in select () at ../sysdeps/unix/syscall-template.S:84 2Thread 0x7ffe5819a700 (LWP 1475) "QInotifyFileSys" 0x7ffe6a3b219d in poll () at ../sysdeps/unix/syscall-template.S:84 3Thread 0x7ffe56b80700 (LWP 1477) "QProcessManager" 0x7ffe6a3b3f73 in select () at ../sysdeps/unix/syscall-template.S:84 4Thread 0x7ffe55c26700 (LWP 1485) "kile" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 (gdb) thread 4 [Switching to thread 4 (Thread 0x7ffe55c26700 (LWP 1485))] #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 185 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory. (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7ffe685a08ba in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #2 0x7ffe685a08e9 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #3 0x7ffe65f8f464 in start_thread (arg=0x7ffe55c26700) at pthread_create.c:333 #4 0x7ffe6a3bb30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) thread 3 [Switching to thread 3 (Thread 0x7ffe56b80700 (LWP 1477))] #0 0x7ffe6a3b3f73 in select () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x7ffe6a3b3f73 in select () at ../sysdeps/unix/syscall-template.S:84 #1 0x7ffe6bce361f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #2 0x7ffe6bbf8e3c in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #3 0x7ffe65f8f464 in start_thread (arg=0x7ffe56b80700) at pthread_create.c:333 #4 0x7ffe6a3bb30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) thread 2 [Switching to thread 2 (Thread 0x7ffe5819a700 (LWP 1475))] #0 0x7ffe6a3b219d in poll () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x7ffe6a3b219d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7ffe656af39c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7ffe656af4ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7ffe6bd39216 in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #4 0x7ffe6bd0717f in QEventLoop::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #5 0x7ffe6bd074e5 in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #6 0x7ffe6bbf6549 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #7 0x7ffe6bce7213 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #8 0x7ffe6bbf8e3c in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #9 0x7ffe65f8f464 in start_thread (arg=0x7ffe5819a700) at pthread_create.c:333 #10 0x7ffe6a3bb30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) thread 1 [Switching to thread 1 (Thread 0x7ffe6e585900 (LWP 1474))] #0 0x7ffe6a3b3f73 in select () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x7ffe6a3b3f73 in select () at ../sysdeps/unix/syscall-template.S:84 #1 0x7ffe6c2af2ab in KLockFile::lock(QFlags) () from /usr/lib/libkdecore.so.5 #2 0x7ffe6c12c254 in ?? () from /usr/lib/libkdecore.so.5 #3 0x7ffe6c11ae8a in KConfig::sync() () from /usr/lib/libkdecore.so.5 #4 0x00542634 in ?? () #5 0x005e0d15 in ?? () #6 0x005e104b in ?? () #7 0x005e1757 in ?? () #8 0x7ffe6bd1cfc0 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #9 0x7ffe6adc9962 in QAction::triggered(bool) () from /usr/lib/x86_64-li
Bug#836551: gitlab: short gpg key used in script
Package: gitlab Version: 8.10.5+dfsg-2 Severity: important Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: Scala.gitlab-ci.yml [2] Please consider upgrading to a full key ID, for example, replace the command: gpg --keyserver --recv-keys with gpg --keyserver --recv-keys eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] https://anonscm.debian.org/cgit/pkg-ruby-extras/gitlab.git/tree/vendor/gitlab-ci-yml/Scala.gitlab-ci.yml
Bug#836553: poretools: short gpg key used in script
Package: poretools Version: 0.5.1-1 Severity: important Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: Dockerfile [2] Its not clear to me that the affected file is actually used in the build script, but it may be referenced somewhere in the package Please consider upgrading to a full key ID, for example, replace the command: gpg --keyserver --recv-keys with gpg --keyserver --recv-keys eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] http://http.debian.net/debian/pool/main/p/poretools/poretools_0.5.1.orig.tar.gz
Bug#836555: kivy: docs describe short gpg key usage
Source: kivy Version: 1.9.1-1 Severity: normal Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: /doc/sources/installation/installation-linux.rst [2] It is not clear to me that this is actually executed anywhere by the package, but may be an upstream issue. If this is the case, perhaps this should be forwarded on. Otherwise, please consider upgrading to a full key ID, for example, replace the command: gpg --keyserver --recv-keys with gpg --keyserver --recv-keys eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] https://anonscm.debian.org/cgit/python-modules/packages/kivy.git/tree/doc/sources/installation/installation-linux.rst
Bug#836557: php-mongodb: gpg short id used in script
Package: php-mongodb Version: 1.1.7-2 Severity: important Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: /mongodb-1.1.7/scripts/ubuntu/mongo-orchestration.sh [2] This is likely not be directly used by the debian component of the package, so this bug may require forwarding upstream. Please consider upgrading to a full key ID, for example, replace the command: gpg --keyserver --recv-keys with gpg --keyserver --recv-keys eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] http://http.debian.net/debian/pool/main/p/php-mongodb/php-mongodb_1.1.7.orig.tar.gz
Bug#836558: sqlkit: gpg key too short in tutorial file
Source: sqlkit Version: 0.9.6.1-2 Severity: normal Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: doc/misc/tutorial.rst [2] This does appear to be in a documentation file, however the instructions are listed under the Debian section of the tutorial. This may be an upstream problem, and may require forwarding on to them. Please consider upgrading to a full key ID, for example, replace the command: gpg --keyserver --recv-keys with gpg --keyserver --recv-keys eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] https://anonscm.debian.org/cgit/collab-maint/sqlkit.git/tree/doc/misc/tutorial.rst?id=2e8775efbc8acf88fb675486464a60c08c44eeb7
Bug#836561: cairo-dock: gpg key in scripts too short
Source: cairo-dock Version: 3.4.0-2 Severity: important Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: data/scripts/help_scripts.sh [2] Please consider upgrading to a full key ID, for example, replace the command: gpg --keyserver --recv-keys with gpg --keyserver --recv-keys eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] git://anonscm.debian.org/pkg-cairo-dock/cairo-dock.git commit 49a9279cb91e91e5064136821b377eb84277d613
Bug#836560: softhsm2: short gpg ids listed in documentation
Source: softhsm2 Version: 2.1.0-3 Severity: normal Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: WIN32-NOTES.md [2] This appears to be a set of build instructions for a windows system, so may require forwarding to upstream, as it may not apply to the debian-built package per-se. Please consider upgrading to a full key ID, for example, replace the command: eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] debian git repository, git://anonscm.debian.org/pkg-nlnetlabs/softhsm2.git commit 63d7b40d72263c2dfff9ded40c4988698670
Bug#836562: python-tosca-parser: gpg key too short in test script
Source: python-tosca-parser Version: 0.1.0-3 Severity: important Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: tests/artifacts/mongodb/create.sh [2] This appears to be an environment setup file for installing mongodb, and may not be executed directly as part of the debian package. As such, this may require forwarding upstream. Please consider upgrading to a full key ID, for example, replace the command: gpg --keyserver --recv-keys with gpg --keyserver --recv-keys eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] https://anonscm.debian.org/cgit/openstack/python-tosca-parser.git/tree/toscaparser/tests/artifacts/mongodb/create.sh?id=9079027c658de670e735d7a60c0c548663f0670d
Bug#836563: acbuild: example script contains too-short gpg id
Package: acbuild Version: 0.4.0+dfsg-1 Severity: important Dear Maintainer, Your package appears to contain commands which use a short gpg-key ID. These have recently been identified as potential security concerns, due to a chance that the wrong key can be imported in the case of a forced key-ID collision [1]. The affected file is: /acbuild-0.4.0/examples/mongodb/build-mongodb.sh [2] It appears that this is an example, and may not be executed as part of the debian package. This may require forwarding upstream. Please consider upgrading to a full key ID, for example, replace the command: gpg --keyserver --recv-keys with gpg --keyserver --recv-keys eg (not specific to your package): gpg --keyserver keyring.debian.org --recv-keys 05C3E651 becomes: gpg --keyserver keyring.debian.org --recv-keys 0x0D59D2B15144766A14D241C66BAF400B05C3E651 (Note the tail bytes are the same) This has previously been forwarded to the security team, who advised to report individual public bugs against each package - hence this bug. [1] http://lwn.net/Articles/697417 [2] http://mirror.vorboss.net/debian/pool/main/a/acbuild/acbuild_0.4.0+dfsg.orig.tar.xz
Bug#1019824: 3depict: Please transition to wxwidgets3.2
Hi, I will address this in a few weeks - I think there are only minor changes required to make the transition. I've patched the upstream repository, but not tested it against the latest wx packages. I will update as soon as I can. Thanks!
Bug#502298: Installer hangs when disk full
Package: debian-installer Version: unknown When installing debian to a 1GB USB key using http://wiki.debian.org/DebianEeePC/HowTo/InstallOnSDcardOrUsbStick , a lack of space on the disk caused the installer to go into a near-perpetual loop, with no option for aborting or otherwise recovering Details (transcribed, may contain errors): Oct 15 11:39:31 in-target Error writing to output file lenny/main openoffice.org-gnome 1:2.4.1-9 This message is repeated contiuously. Some method of stopping the installation is requested. As a new debian user, I was expecting individual package customisation, and as such did not worry about oversize installs until too late. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#502789: (no subject)
I can confirm this bug still exists. I have just installed imageJ after updating my repos, and the crash exists. It shows up when using java version "1.5.0" gij (GNU libgcj) version 4.3.2 The dependency is either broken, or there is an upstream bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525385: ffmpeg segfault png to ogg conversion
Subject: ffmpeg segfault png to ogg conversion Package: ffmpeg Version: 3:0.svn20090303-1 Severity: normal ffmpeg crashes every time when attempting to convert some png files to ogg files. The files were generated from scilab EPS output using imagemagick with convert EPSFILE -depth 8 PNGFILE. The sequence seems to crash somewhere in libgtheora after a given number of png files. Each file is individually openable in gqview. I have provided a link to a script (with png files) which shows this behaviour. Link (2.2MB): http://dhd.selfip.com/427e/ffmpeg-segfault.tar.bz2 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages ffmpeg depends on: ii libavcodec52 3:0.svn20090303-1 ffmpeg codec library ii libavdevice52 3:0.svn20090303-1 ffmpeg device handling library ii libavfilter0 3:0.svn20090303-1 ffmpeg video filtering library ii libavformat52 3:0.svn20090303-1 ffmpeg file format library ii libavutil493:0.svn20090303-1 ffmpeg utility library ii libc6 2.9-4 GNU C Library: Shared libraries ii libpostproc51 3:0.svn20090303-1 ffmpeg video postprocessing librar ii libsdl1.2debian1.2.13-4+b1 Simple DirectMedia Layer ii libswscale03:0.svn20090303-1 ffmpeg video scaling library ffmpeg recommends no packages. ffmpeg suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#492869: (no subject)
This bug still exists in the current paraview. I am using an intel GMA adapter on an EEE901. ~$ apt-cache policy paraview paraview: Installed: 3.4.0-3 Candidate: 3.4.0-3 Version table: *** 3.4.0-3 0 500 ftp://mirror.internode.on.net squeeze/main Packages 100 /var/lib/dpkg/status $ lspci | grep GME 00:00.0 Host bridge: Intel Corporation Mobile 945GME Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540513: ITP: stxxl -- C++ Standard Template Library (STL) for extra large datasets
I a have uploaded a prospective package to Debian mentors. Comments would be most appreciated. http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=libstxxl1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567756: xserver-xorg-input-all: keyboard not working after squeeze upgrade
Hello, I recently have found that an update to something in xorg (it was pulled in by another update) has broken my keyboard & mouse, only in X. However, if I unplug/plug the USB connector after login, it works again. This would be an OK workaround for my external keyboard & mouse, but the laptop keyboard & trackpad (which is internally USB) has been hit by the same problem. Do these symptoms match what is happening to you? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567756: xserver-xorg-input-all: keyboard not working after squeeze upgrade
I found that udev was causing my problems. Updating libudev0 to 150-2 from 146-5 solved the problem. Udev had updated, but did not bring in libudev0. I was able to (without updating libudev) "fix" the problem temporarily by running /sbin/udevadm trigger for each session (using an external keyboard & mouse, which i had to cycle the connector for). Hope this helps --- On Thu, 2/4/10, Alex Bernier wrote: > From: Alex Bernier > Subject: Bug#567756: xserver-xorg-input-all: keyboard not working after > squeeze upgrade > To: 567...@bugs.debian.org > Cc: "Rick Thomas" , "Brice Goglin" > > Date: Thursday, February 4, 2010, 8:49 AM > I have similar problem here (on a > Dell Latitude D630 Laptop). > > First, it seems my laptop's TouchPad doesn't work > (Xorg.0.log). > Removing the "psmouse" module doesn't solve the problem : > there is another one with the keyboard (Xorg1.log). > > Here is the result of "/usr/share/bug/xserver-xorg/script" > (bugxserverxorg.log). > > Regards, > > Alex Bernier > > On Sun, Jan 31, 2010 at 10:49:11AM +0100, Brice Goglin > wrote: > > Rick Thomas wrote: > > > Package: xserver-xorg-input-all > > > Version: 1:7.5+2 > > > Severity: grave > > > Justification: renders package unusable > > > > > > > > > After upgrading my Squeeze system, my keyboard is > non-responsive under X. > > > By changing /etc/X11/default-display-manager > > > from > > > > /usr/bin/gdm > > > to > > > /bin/false > > > thus disabling gnome, I was able to use the > console in text mode. > > > So I'm assuming that it's not a hardware > problem. > > > > > > I'm attaching /var/log/Xorg.0.log > > > > > > > Please send the whole output of > > > /usr/share/bug/xserver-xorg/script > 3>&1 > > > > Brice > > > > > > > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567756: xserver-xorg-input-all: keyboard not working after squeeze upgrade
> Big question: where to find older binary packages, to try a > downgrade? > ftp.debian.org seems to remove the packages "not in a > release"... :-( > I don't think you can. A package must be compiled properly against the appropriate soversions. Maintaining that dependency graph is tricky That said there *used* to be this, but I think it is no longer operational. http://snapshot.debian.net/ --- On Fri, 2/12/10, Ariel Garcia wrote: > From: Ariel Garcia > Subject: Bug#567756: xserver-xorg-input-all: keyboard not working after > squeeze upgrade > To: 567...@bugs.debian.org > Date: Friday, February 12, 2010, 3:21 PM > Same issue here, didn't reboot my > laptop for 20+ days, but somewhen in between > things broke... :-( > > For sure it is not a firmware issue (same self-compiled > kernel since longer). > Also udev and libudev are both version 150-2 > Keyboard works fine in the console. > > Arch x86_64 > > Upgraded packages (relevant ones only) > > xserver-common > 2:1.6.5-1 --> 2:1.7.4-2 > xserver-xorg > > 1:7.4+4 --> 1:7.5+3 > xserver-xorg-core > 2:1.6.5-1 --> 2:1.7.4-2 > xserver-xorg-input-evdev 1:2.2.5-1 > --> 1:2.3.2-3 > > Big question: where to find older binary packages, to try a > downgrade? > ftp.debian.org seems to remove the packages "not in a > release"... :-( > > Thanks, Ariel > > > > -- > To unsubscribe, send mail to 567756-unsubscr...@bugs.debian.org. > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535036: Is bug 535036 still an issue in Inkscape?
This appears to have been fixed in my current installed version of inkscape. eeeu...@planck:~/ox/code/uncontrolled/rawToHits$ aptitude show inkscape Package: inkscape State: installed Automatically installed: no Version: 0.47.0-1 --- On Fri, 2/19/10, Alex Valavanis wrote: > From: Alex Valavanis > Subject: Is bug 535036 still an issue in Inkscape? > To: my...@yahoo.com, 535...@bugs.debian.org, cont...@bugs.debian.org > Date: Friday, February 19, 2010, 8:04 AM > tags 535036 + moreinfo > thanks > > It has been a while since you reported this bug. Do > you still > experience it with the latest (0.47) Debian Inkscape > package? > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570930: ITP: liblemon1 -- Library for Efficient Modeling and Optimization in Networks
Package: wnpp Severity: wishlist * Package name: liblemon1 Version : 1.1.1 Upstream Author : Egervary Research Group on Combinatorial Optimization (EGRES) * URL : http://lemon.cs.elte.hu/ * License : Boost 1.0 Programming Lang: C++ Description : Library for Efficient Modeling and Optimization in Networks This has recently come under the Coin-or banner. Should this be named coinor-liblemon1 ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570930: ITP: liblemon1 -- Library for Efficient Modeling and Optimization in Networks
I have a work-in-progress git repo placed in debian-science: git clone git://git.debian.org/git/debian-science/liblemon1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571605: scilab: please patch testing to fix crash-on-export
According to this you can http://www.debian.org/doc/developers-reference/pkgs.html section: 5.13.3. Direct updates to testing If hdf5 is not going to fix itself any time soon, (I am unsure exactly what the deal is with that -mpich library), then this is *technically* an option. I have no idea as to whether this crash counts enough to allow this style of updating. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555592: Patches
The fedora SRPMs now have patches to fix this. you should be able to just use those. http://cvs.fedoraproject.org/viewvc/F-13/mathgl/mathgl-mglview-ldflags.patch?revision=1.1&view=markup http://cvs.fedoraproject.org/viewvc/F-13/mathgl/mathgl-examples-ldflags.patch?revision=1.1&view=markup -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564422: Updates
Hi, I have updated the debian science repo. The package now builds (although the png dependencies are not quite handled correctly, and cause multiple calls to mathgl_example.). At any rate, the package builds so as far as I am concerned my work is done. Can someone else touch up the package and take maintenance of it? Notes: * texinfo is throwing utf8 errors if I try to build the _ru documentation. I have disabled this for now. * Upstream have committed changes to their repositories to solve the ldflags problem (see bug #92). * I have not made the package lintian clean. Thanks. --- On Fri, 4/23/10, Salvatore Bonaccorso wrote: > From: Salvatore Bonaccorso > Subject: Re: Bug#564422: Updates > To: "D Haley" , 564...@bugs.debian.org > Date: Friday, April 23, 2010, 6:00 PM > Hi D. > > On Mon, Apr 19, 2010 at 03:52:41PM -0700, D Haley wrote: > > I have done some updating to the package, but it is > not in a working > > state (it should be a bit closer than it was). Just as > I was > > committing to debian-science (after i inited a repo), > SSH started > > timing out to alioth. :/ I will try to upload this > tomorrow. > > > > I will, in the coming week, have another crack at this > to get it > > into a clean and working state. > > I saw you arleady commited package to debian-science, > really cool. > Tanks for working on it. > > I have this to forward at you got from Alexey: > > On Mon, Dec 28, 2009 at 01:06:04PM +0300, Alexey Balakin > wrote: > > Dear Salvatore, > > > > I have one more comment. As Jim Hu had noted me, the > GSL library is > > GPL. So, I change a bit license for MathGL (some > corrections were > > already done in web site). The idea is > > > > "Generally MathGL is GPL library. However, you can use > LGPL license > > for MathGL core if you don't use wrapper classes > (don't use file > > mgl_w.h and SWIG-based interfaces) and disable GSL > features (by > > defining NO_GSL for library compilation)." > > > > I think that the MathGL version in DEB-packages should > contain GSL. > > So, it have to be GPL. Can you apply this change for > Debian and Ubuntu > > packages? During few days I'll update win32 binary > packages too. > > > > -- > > All the best, > > Alexey Balakin > > Bests > Salvatore > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564422: Updates
Hello, The version control system used is git, so you can check it out with git pull git://git.debian.org/git/debian-science/packages/mathgl.git I added the man pages too, so that should help simplify solving the lintian errors. Thanks. --- On Thu, 5/6/10, Dimitrios Eftaxiopoulos wrote: > From: Dimitrios Eftaxiopoulos > Subject: Re: Bug#564422: Updates > To: "D Haley" , 564...@bugs.debian.org > Date: Thursday, May 6, 2010, 2:47 AM > Hello, > I am a user of mathgl under Debian unstable. I would like > to see it back in > Debian. I tried to find the package in the debian-science > repository > > http://svn.debian.org/wsvn/debian-science/packages/ > > but I could not find it there. Could you please give me the > address where > mathgl is comitted? I woul like to try to build it. > > Thanks > Dimitris > > > Στις Παρασκευή 30 Απρίλιος 2010 > 23:34:20 γράψατε: > > Hi, > > > > I have updated the debian science repo. The package > now builds (although > > the png dependencies are not quite handled correctly, > and cause multiple > > calls to mathgl_example.). > > > > At any rate, the package builds so as far as I am > concerned my work is > > done. Can someone else touch up the package and take > maintenance of it? > > > > Notes: > > * texinfo is throwing utf8 errors if I try to build > the _ru documentation. > > I have disabled this for now. * Upstream have > committed changes to their > > repositories to solve the ldflags problem (see bug > #92). * I have not > > made the package lintian clean. > > > > > > Thanks. > > > > --- On Fri, 4/23/10, Salvatore Bonaccorso > > wrote: > > > From: Salvatore Bonaccorso > > > Subject: Re: Bug#564422: Updates > > > To: "D Haley" , > 564...@bugs.debian.org > > > Date: Friday, April 23, 2010, 6:00 PM > > > Hi D. > > > > > > On Mon, Apr 19, 2010 at 03:52:41PM -0700, D Haley > wrote: > > > > I have done some updating to the package, > but it is > > > > > > not in a working > > > > > > > state (it should be a bit closer than it > was). Just as > > > > > > I was > > > > > > > committing to debian-science (after i inited > a repo), > > > > > > SSH started > > > > > > > timing out to alioth. :/ I will try to > upload this > > > > > > tomorrow. > > > > > > > I will, in the coming week, have another > crack at this > > > > > > to get it > > > > > > > into a clean and working state. > > > > > > I saw you arleady commited package to > debian-science, > > > really cool. > > > Tanks for working on it. > > > > > > I have this to forward at you got from Alexey: > > > > > > On Mon, Dec 28, 2009 at 01:06:04PM +0300, Alexey > Balakin > > > > > > wrote: > > > > Dear Salvatore, > > > > > > > > I have one more comment. As Jim Hu had noted > me, the > > > > > > GSL library is > > > > > > > GPL. So, I change a bit license for MathGL > (some > > > > > > corrections were > > > > > > > already done in web site). The idea is > > > > > > > > "Generally MathGL is GPL library. However, > you can use > > > > > > LGPL license > > > > > > > for MathGL core if you don't use wrapper > classes > > > > > > (don't use file > > > > > > > mgl_w.h and SWIG-based interfaces) and > disable GSL > > > > > > features (by > > > > > > > defining NO_GSL for library compilation)." > > > > > > > > I think that the MathGL version in > DEB-packages should > > > > > > contain GSL. > > > > > > > So, it have to be GPL. Can you apply this > change for > > > > > > Debian and Ubuntu > > > > > > > packages? During few days I'll update win32 > binary > > > > > > packages too. > > > > > > > -- > > > > All the best, > > > > Alexey Balakin > > > > > > Bests > > > Salvatore > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#580413: opticalraytracer: Unable to access jarfile
Fix uploaded to debian-science git, . jar file should not contain uppercase letters. There is a symlink "opticalraytracer.jar" that is made that should be used. Sylvestre, could you upload. Sorry about the fix, this should have been caught earlier. I have tested -2 on my local VM, and it worked. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564422: Ping
Hello, I am the fedora maintainer for mathgl, but I also maintain a few debian packages. I would be most interested in seeing this back in debian -- has there been any progress on this? Regards, D. Haley -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564422: Ping
I'll pull down the package tomorrow and have a quick look. I am a bit reticent to maintain it for a few reasons, (1) I believe in the ability to compare notes with other distribution's packages and (2) I believe my work is should be checked by someone for what I believe is a moderately important package. I'm quite willing to propose a few patches though. --- On Mon, 4/19/10, Salvatore Bonaccorso wrote: > From: Salvatore Bonaccorso > Subject: Re: Bug#564422: Ping > To: "D Haley" , 564...@bugs.debian.org, "Manuel Prinz" > > Date: Monday, April 19, 2010, 12:59 AM > Hi > > On Sun, Apr 18, 2010 at 05:46:00AM -0700, D Haley wrote: > > I am the fedora maintainer for mathgl, but I also > maintain a few > > debian packages. I would be most interested in seeing > this back in > > debian -- has there been any progress on this? > > I had still not time to work on it, sorry. Would you be > interested to > take it? If so, please note would be a good idea to have it > maintained > in the debian-science Group, IMHO. > > If you would like to work on it, don't worry, you can > change the owner > to you. It would be great to have mathgl finally updated. > I'm sorry > that, I was not able due to my current time constraints to > work at all > on these packages. > > Bests > Salvatore > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564422: Updates
I have done some updating to the package, but it is not in a working state (it should be a bit closer than it was). Just as I was committing to debian-science (after i inited a repo), SSH started timing out to alioth. :/ I will try to upload this tomorrow. I will, in the coming week, have another crack at this to get it into a clean and working state. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#469229: Problem with search : evolution mail module stuck
I can confirm this error for evolution under debian lenny. $ evolution --version GNOME evolution 2.22.3.1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#598069: udav crashes on start up
Hi All, If you install the debug information, and run this under GDB, you can generate a backtrace, which would be invaluable. If you can do that, then a valgrind (valgrind udav) session might also be revealing. Thanks --- On Mon, 9/27/10, Salvatore Bonaccorso wrote: > From: Salvatore Bonaccorso > Subject: Re: Bug#598069: udav crashes on start up > To: "Dimitrios Eftaxiopoulos" , 598...@bugs.debian.org > Cc: cont...@bugs.debian.org, debian-scie...@lists.debian.org > Date: Monday, September 27, 2010, 7:54 PM > tag 598069 + moreinfo unreproducible > thanks > > Hi Dimitrios > > On Sun, Sep 26, 2010 at 09:41:38AM +0300, Dimitrios > Eftaxiopoulos wrote: > > Package: udav > > Version: 0.6.3-1 > > Severity: important > > > > Hello, > > Trying to launch udav from the command line I get the > following error log > > > > > > eftax...@filippos:~$ udav > > (8965) KSharedDataCache::Private::mapSharedMemory: > Opening cache "/var/tmp/kdecache-eftaxiop/icon-cache.kcache" > page size is 4096 > > (8965) KSharedDataCache::Private::mapSharedMemory: > Attached to cache, determining if it must be initialized > > (8965) KSharedDataCache::Private::mapSharedMemory: > Cache fully initialized -- attached to memory mapping > > (8965) KSharedDataCache::Private::mapSharedMemory: > 4419584 bytes available out of 10485760 > > QWidget::setMinimumSize: (/QMdi::ControlLabel) > Negative sizes (-1,-1) are not possible > > QWidget::setMinimumSize: (/QMdi::ControlLabel) > Negative sizes (-1,-1) are not possible > > QWidget::setMinimumSize: (/QMdi::ControlLabel) > Negative sizes (-1,-1) are not possible > > *** glibc detected *** udav: malloc(): memory > corruption: 0x01672610 *** > > === Backtrace: = > > /lib/libc.so.6(+0x71ad6)[0x7f5aac708ad6] > > /lib/libc.so.6(+0x74b6d)[0x7f5aac70bb6d] > > /lib/libc.so.6(__libc_malloc+0x70)[0x7f5aac70d930] > > > /usr/lib/libQtCore.so.4(_ZN7QString17fromLatin1_helperEPKci+0x33)[0x7f5aad491913] > > > /usr/lib/libQtCore.so.4(_ZN7QString16fromAscii_helperEPKci+0xcd)[0x7f5aad49758d] > > udav[0x4327cf] > > udav[0x432a0a] > > udav[0x433ec5] > > > /usr/lib/libQtGui.so.4(_ZN7QWidget5eventEP6QEvent+0x604)[0x7f5aada9f244] > > > /usr/lib/libQtGui.so.4(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0xac)[0x7f5aada4932c] > > > /usr/lib/libQtGui.so.4(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x14b)[0x7f5aada4f80b] > > > /usr/lib/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8c)[0x7f5aad5390bc] > > > /usr/lib/libQtGui.so.4(_ZN14QWidgetPrivate30sendPendingMoveAndResizeEventsEbb+0x19b)[0x7f5aada9e24b] > > > /usr/lib/libQtGui.so.4(_ZN14QWidgetPrivate30sendPendingMoveAndResizeEventsEbb+0x10b)[0x7f5aada9e1bb] > > === Memory map: > > 0040-004a9000 r-xp 08:05 1171503 > > /usr/bin/udav > > 006a8000-006ac000 rw-p 000a8000 08:05 1171503 > > /usr/bin/udav > > 006ac000-006b2000 rw-p 00:00 0 > > 00922000-036b7000 rw-p 00:00 0 > > [heap] > > 7f5a9000-7f5a90021000 rw-p 00:00 0 > > 7f5a90021000-7f5a9400 ---p 00:00 0 > > 7f5a96959000-7f5a9695a000 ---p 00:00 0 > > 7f5a9695a000-7f5a9715a000 rwxp 00:00 0 > > 7f5a98467000-7f5a984e8000 r--p 08:05 > 7226751 > > /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Oblique.ttf > > 7f5a984e8000-7f5a98532000 r--p 08:05 > 6168662 > > /usr/share/fonts/truetype/msttcorefonts/Courier_New.ttf > > 7f5a98532000-7f5a98536000 r-xp 08:05 > 7325145 > > /usr/lib/kde4/plugins/imageformats/kimg_xview.so > > 7f5a98536000-7f5a98735000 ---p 4000 08:05 > 7325145 > > /usr/lib/kde4/plugins/imageformats/kimg_xview.so > > 7f5a98735000-7f5a98736000 rw-p 3000 08:05 > 7325145 > > /usr/lib/kde4/plugins/imageformats/kimg_xview.so > > 7f5a98736000-7f5a98745000 r-xp 08:05 > 7325196 > > /usr/lib/kde4/plugins/imageformats/kimg_xcf.so > > 7f5a98745000-7f5a98945000 ---p f000 08:05 > 7325196 > > /usr/lib/kde4/plugins/imageformats/kimg_xcf.so > > 7f5a98945000-7f5a98946000 rw-p f000 08:05 > 7325196 > > /usr/lib/kde4/plugins/imageformats/kimg_xcf.so > > 7f5a98946000-7f5a9894a000 rw-p 00:00 0 > > 7f5a9894a000-7f5a9894f000 r-xp 08:05 > 7325186 > > /usr/lib/kde4/plugins/imageformats/kimg_tga.so > > 7f5a9894f000-7f5a98b4e000 ---p 5000 08:05 > 7325186 > > /usr/lib/kde4/plugins/imageformats/kimg_tga.so > > 7f5a98b4e000-7f5a98b4f000 rw-p 4000 08:05 > 7325186 > > /usr/lib/kde4/plugins/imageformats/kimg_tga.so > > 7f5a98b4f000-7f5a98b58000 r-xp 08:05 > 7325190 > > /usr/lib/kde4/plugins/imageformats/kimg_rgb.so > > 7f5a98b58000-7f5a98d58000 ---p 9000 08:05 > 7325190 >
Bug#592460: ITP: 3depict -- 3D valued point data visualisation and analysis
Package: wnpp Severity: wishlist Owner: "d.haley" * Package name: 3depict Version : 0.0.1 Upstream Author : D Haley * URL : http://threedepict.sourceforge.net * License : GPL, Programming Lang: C++ Description : 3D valued point data visualisation and analysis Disclosure: I am upstream author -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#589254: RFS - mapcatcher
Hello, I came across your g/mapcatcher package today, I had not heard of the project before. This looks like an excellent lightweight alternative to marble - I have already installed it on my machine (marble wont fit, it has way too many deps). I can't sponsor you, however here are some comments on your debian-mentors package: * Program should use either mapcatcher or gmapcatcher consistently. If upstream wish to rename their project, use mapcatcher, if not, use gmapcatcher. Until I read your mailing list thread, I thought the G was for GTK. This is confusing as some things (eg the program) are labelled mapcatcher, and some things /usr/share/pyshared/* are labelled GMapCatcher. Consistency is key, with or without "G". :) * Although marked as GPL2 or any later, the actual python programs do not have the pre-amble in the source files, as required by the licence. The upstream project website simply says GPL2, not GPL2 or later. This needs to be clarified by the upstream authors. THis is true of both the mapcatcher and mapdownloader python scripts, as well as for /usr/share/pyshared/gmapcatcher/* * Project seems to include its own version of gps.py. Is there any reason that the python-gps package is not being used? Importing sources from upstream projects is not cool, as it means that updates are not sent to users in a timely fashion, and that duplication can be a problem. Secondly, this is a problem as it is unclear which files in the pyshared/gmapcatcher/ directory were actually written by the project, and thus are correctly licenced * During the package build from the DSC, I get the following message: WARNING: Use of XS-Python-Version and XB-Python-Version fields in debian/control is deprecated with pysupport method; use debian/pyversions if you need to specify specific versions. pyversions: missing XS-Python-Version in control file, fall back to debian/pyversions *The installed /usr/share/pyshared/GMapCatcher-0.7.2.2.egg-info contains "UNKNOWN" entries. Please fill in the upstream author's details *According to debian/copyright, there are two real authors, and then a pseudo-author "mapcatcher team". The upstream project states that the authors are : "pi3or...@gmail.com, helders...@gmail.com, maxim.ra...@gmail.com, and standa31...@gmail.com". This should be reflected in debian/copyright Thanks, D. Haley -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519583: Proprosed package
A proposal for review has been uploaded to mentors: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=opticalraytracer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
